声明:此文档针对天津大学24251学期《软件工程》课程重点知识整理,仅供个人参考。

1.2 软件及其特点

★软件的组成

程序
数据: 程序的加工处理对象和结果。
文档: 记录软件开发活动和阶段性成果、软件配置及变更的阐述性资料。

★软件的生命周期

软件从提出开发开始到最终灭亡所经历的时期。
需求分析、软件设计、编码实现、软件测试、部署运行、使用维护。

★软件的分类

应用软件
系统软件
支撑软件

★开源软件的优势

1. 开源软件的好处
源代码可自由传播
激发创作者的热情
免费使用降低成本
2. 开源软件的优势
采购和开发的成本更低:开源软件通常是免费的,即使要付费,其费用也非常低廉
软件质量更高、更安全:核心代码都在公众的视野之中,代码问题(如缺陷、安全漏洞等)很容易被人发现
软件研制和交付的更快:基于开源软件的项目开发可以更为快速地给用户交付软件产品
软件功能更为强大:大量的软件开发者不仅参与软件开发,贡献他们的代码,而且还参与软件的创新,提出和构思软件需求,不断完善软件功能

★软件质量要素

正确性、可靠性、健壮性、有效性、安全性、可维护性、可移植性、可重用性、可理解性、可信性、持续性、可用性、互操作性。

2 软件工程概述

★软件危机的表现

1. 软件危机的表现:
开发成本高
进度难以控制
质量难以保证
软件维护困难
失败风险很大
2. 软件危机的产生根源:
① 对软件这样一类复杂和特殊系统的认识不清
② 没有找到支持软件系统开发的有效方法
③ 缺乏成功软件开发实践以及相应的开发经验
3. 如何来解决软件危机?
策略:采用敏捷项目管理,强化风险控制。
方法:实施敏捷开发和持续集成/部署。
理论:深化软件工程理论,推广系统思维。
技术:利用自动化测试和代码审查工具。

★软件工程的要素

★软件工程的原则

抽象和建模、模块化、软件重用、信息隐藏、关注点分离、分而治之、双向追踪原则、工具辅助。
信息隐藏?
模块内部信息(如内部的语句、变量等)对外不可见或不可访问,模块间仅仅交换那些为完成系统功能所必需交换的信息(如接口)
模块设计时只对外提供可见的接口,不提供内部实现细节。信息隐藏原则可提升模块的独立性,减少错误向外传播,支持模块的并行开发

3.1 软件过程模型

★典型软件过程模型

瀑布模型
增量模型
迭代模型
原型模型
螺旋模型
基于构件的过程模型
UP模型
瀑布模型
过程: 需求分析->概要设计->详细设计->编码实现->集成测试->确认测试
特点:
与软件生命周期相互一致
每个活动结束后需要评审
相邻活动间存在因果关系
优点: 简单,一目了然,易理解、掌握、应用和管理
不足: 需求确定,过于理想化、缺乏变通,难应对变化
改进的瀑布模型:带反馈和回溯
优点: 后期活动发现有问题后,可返回到前面活动加以解决、提高了过程模型的灵活性
不足: 软件开发处于动荡之中、需等到所有功能实现后,才能得到可运行软件

3.2 敏捷软件开发方法 - Agile

★敏捷开发的概念和观点

概念
一种轻量级软件开发方法
主张软件开发要以代码为中心,快速、轻巧和主动应对需求变化,持续、及时交付可运行的软件系统
提供了一组思想和策略,指导快速响应用户需求的变化,快速交付可运行的软件制品
观点
较之于过程和工具,应更加重视人和交互的价值
较之于面面俱到文档,应更加重视可运行软件系统的价值
较之于合同谈判,应更加重视客户合作的价值
较之于遵循计划,应更加重视响应用户需求变化的价值

★敏捷准则

尽早和持续地交付有价值的软件,以使用户满意
即使到了软件开发后期,也欢迎用户需求的变化
不断交付可运行的软件系统,交付周期可以从几周到几个月
在整个软件项目开发期间,用户和开发人员最好能每天一起工作
积极主动的人来承担项目开发,给他们提供所需环境和支持,信任他们的能力
团队内部最有效的信息传递方式是面对面的交谈
可运行软件作为衡量软件开发进度的首要标准
可持续性的开发,出资方、开发方和用户方应当保持长期、恒定的开发速度
关注优秀的技能和良好的设计会增强敏捷性
简单
最好的架构、需求和设计出自于自组织的团队
软件开发团队应定期就如何提高工作效率的问题进行反思,并进行相应的调整

★敏捷开发代表方法

极限编程
测试驱动开发方法
Scrum方法

4 软件需求分析基础

★利益相关方

用户
客户
系统
开发者

★软件需求的类别

软件功能性需求
软件质量方面的需求(外部质量属性、内部质量属性)
软件开发约束性需求

★面向对象的需求分析方法

1.对象、类、继承、多态、覆盖、重载、消息、聚合和组合等概念需要记忆
2.面向对象需求分析步骤
明确问题边界,获取软件需求,建立用例模型
开展用例分析,精化软件需求,建立分析模型
汇总需求模型,撰写需求文档,评审软件需求
3.面向对象需求分析方法的优势和特色
自然建模
统一的概念和抽象

5 获取软件需求

★获取软件需求的方法

访谈和会议
调查问卷
现场观摩
分析业务资料
软件原型
群体化方法
成立需求分析的联合工作小组

★用例图

用例间的关系
包含(Include)
扩展(Extend)
继承(Inherit)

6 分析软件需求

★顺序图

描述对象间的消息交互序列

★类图

描述系统的类构成,刻画系统的静态组成结构

★状态图

描述实体(对象、系统)在事件刺激下的反应式动态行为及其导致的状态变化
刻画了实体的可能状态、每个状态下可响应事件、响应动作、状态迁移

★分析软件需求过程

★软件需求文档

撰写软件需求文档的注意事项
遵循规范
图文并茂
完整表述
共同参与
语言简练
前后一致

7 软件设计基础

★软件设计的质量要求

正确性:正确实现所有的软件需求项;设计元素间无逻辑冲突;在技术平台和软件项目的可用资源约束条件下,采用程序设计语言可完整地实现设计模型
充分性:所有的设计元素已充分细化,模型易于理解,编程人员勿需再面对影响软件功能和质量的技术抉择或权衡
优化性:以合理的、充分优化的方式实现软件需求模型,目标软件产品能够表现出良好的软件质量属性,尤其是正确性、有效性、可靠性和可修改性
简单性:模型中的模块的功能或职责尽可能简明易懂,模块间的关系简单直观,模型的结构尽可能自然地反映待解软件问题的结构

★软件设计原则

①抽象与逐步求精
②模块化,高内聚度、低耦合度
③信息隐藏
④多视点和关注点分离
⑤软件重用
⑥迭代设计
⑦可追踪性
高内聚度:指该模块内各成分间彼此结合的紧密程度,越高越好,高内聚
信息隐藏:模块应该设计得使其所含的信息对那些不需要这些信息的模块不可访问;模块间仅仅交换那些为完成系统功能所必需交换的信息

8 软件体系结构设计

★常用软件体系结构风格

分层风格
管道与过滤器风格
黑板风格
MVC风格
SOA风格
总线风格

10 软件详细设计

★详细设计过程

★活动图

描述实体为完成某项功能而执行的操作序列,其中某些操作或其子序列存在并发和同步

★用例设计

★类设计

★数据设计

13 软件测试

★软件测试过程

★软件测试原则

软件测试原则
测试应该有计划
所有的测试都应该追溯到用户需求
将Pareto原则应用于软件测试
测试应该从“微观”开始,逐步转向“宏观”
穷举测试是不可能的
每个测试用例都必须定义预期的输出或结果
尽量避免程序的开发人员来测试他自己编写的代码
尽量避免程序开发组织测试其自己开发的程序
应详细检查每次测试的结果。
测试用例中不仅要说明合法有效的输入条件,还应该描述那些不期望的、非法的输入条件。
检查一个程序没有完成希望它做的事情只是测试的一半任务,还应检查程序是否执行了不希望它做的事情。
避免随意舍弃任何测试用例,即使非常简单的测试用例。
不应在事先假设不会发现错误的情况下来制定测试计划。
一个程序模块存在更多错误的可能性与该模块已经发现的错误数量成正比。
测试是一个具有相当创新性和智力挑战的活动。

★软件测试技术

白盒测试技术:基于程序内部的执行流程来设计测试用例









黑盒测试技术:基于程序的外在功能和接口来设计测试用例
等价分类法
边界值分析法






15 软件维护和演化

★软件维护的形式

1. 纠正性维护: 纠正软件中的缺陷和错误。
2. 完善性维护: 对软件进行改造以增加新的功能、修改已有的功能。
3. 适应性维护: 对软件进行改造以便适应新的运行环境和平台。
4. 预防性维护: 对软件结构进行改造以便提高软件的可靠性和可维护性等。

★软件维护技术

1. 代码重组
2. 逆向工程
3. 设计重构
4. 再工程

影响软件可维护性的因素:
1. 软件开发方法(结构化、OO)
2. 软件文档是否齐全
3. 文档结构是否标准化
4. 软件是否易于扩展
5. 软件结构是否清晰易于理解
6. 是否采用标准的程序设计语言
7. 程序代码是否易于理解