1.软件工程引论
软件的概念与特征
概念
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合
特征
1）软件是一种逻辑实体，具有抽象性
2）软件的生产与硬件不同
3）软件产品不会“磨损”
软件危机
软件工程的产生及其发展
软件工程是指导软件开发和维护的工程学科
核心思想：采用工程的概念、原理、技术和方法开发和维护软件
软件工程三要素：方法、工具和过程
软件工程七项基本原则
1）用分阶段的生命周期严格管理软件工程过程
2）坚持在软件工程过程中进行阶段评审
3）实行严格的产品控制
4）采用现代的开发技术进行软件的设计与开发
5）工作结果应当是能够清楚审查的
6）开发小组人员应“少而精”
7）承认不断改进软件工程实践的必要性
软件工程技术基础
软件工程是一种层次化技术：
工具层、方法层、过程层和质量焦点
软件工程过程
用以开发或维护软件及其相关产品的一系列活动
软件工程过程包括4种基本的活动过程
1）软件规格说明
2）软件开发
3）软件确认
4）软件演进
软件过程模型
线性顺序模型
原型模型
快速开发应用模型
演化软件过程模型
1）增量模型
2）螺旋模型
过程技术
软件重用技术
“重用”是提升软件财富的有效途径
层次
知识重用
方法重用
软件成分重用
1）分析结果重用
2）设计结果重用
3）代码重用
2 系统工程基础与软件可行性研究
计算机系统工程
硬件和硬件工程
软件和软件工程
人与人机工程（人机交互工程）
数据库与数据库工程
可行性研究与分析
主要从4个方面考虑可行性
1）经济可行性
2）技术可行性
3）法律可行性
4）对不同的方案进行评估抉择
3结构化需求分析与建模
需求分析
步骤
1）通过调查研究，获取用户的需求
2）去除非本质因素，确定系统真正的需求
3）描述需求，建立系统的逻辑模型
4）书写需求说明书，进行需求复审
原则
1）能表达和理解问题的数据域和功能域
2）复杂问题简单化
3）能够给出系统的逻辑表示和物理表示
数据建模
实体--关系模型（E--R模型）
功能建模
数据流图
作用
描述系统中数据流从输入到输出的移动变换过程
清晰地反映系统必须完成的逻辑功能
数据流模型
建立原则
1）每个加工至少应有一个输入数据流和一个输出数据流
2）数据流图中各构成元素的名称必须具有明确的含义，且能够代表对应元素的功能和内容
3）分层数据流图中任意对应的父图和子图的输入/输出数据保持一致
4）按照层次对内个加工编号
5）父图中不要出现子图中涉及的局部数据存储文件
6）数据流图只能由4种基本符号组成，说明系统应该“做什么”，而不是“怎么做”
7）数据流图的分解速度保持适中
行为建模
状态迁移图
Petri网
数据字典
作用
准确地定义数据流图中各组成成分的具体含义，使得系统模型的描述更加清晰准确，有利于系统分析员和用户的共同理解
条目
1）数据流条目
2）数据项条目
3）数据文件条目
4）数据加工条目
加工逻辑的描述
1）结构化语言
优点：能够使用有限的语句较为严格地描述加工逻辑
缺点：加工逻辑复杂时难以描述清楚
2）判定树
优点：能够完整清晰地表达复杂的条件组合与由此产生的动作之间的对应关系
缺点：很难用于描述顺序或循环结构
3）判定表
优点：比判定树更加直观，易于理解和掌握
缺点：逻辑没有判定树严格，容易造成个别条件的遗漏
4.结构化软件设计
体系结构设计
根本目的
将需求分析得到的软件需求规格说明书转换为计算机可以实现的目标系统
任务
1）软件体系结构设计
2）数据结构和数据库设计
3）系统可靠性、安全性设计
4）编写文档，参加复审
原则
1）降低模块的耦合性
2）模块规格适中
3）模块应具有高扇入和适当的扇出
4）软件结构中的宽度和深度不宜过大
5）模块的作用域处于可控范围
6）降低模块的接口复杂度
面向数据流的体系结构设计方法
数据流图
1）变换型数据流图
特点
由输入、变换中心和输出三部分组成
反映的是顺序结构的加工过程
变换分析设计
（1）划分边界，区分系统的输入、变换中心和输出部分
（2）完成第第一级分解，设计系统的上层模块
（3）完成第二层分解，设计输入、变换中心和输出部分的中、 下 层模块
2）事务型数据流图
特点
输入流在经过某个被称为“事务中心”的加工时被分离成多个发散的输出流，形成多个平行的加工处理路径
事务分析设计
（1）划分边界，明确数据流图中的接收路径、事务中心和加工路径
（2）建立事务型结构的上层模块
（3）分解、细化接收路径和加工路径，得到事务型结构的下层模块
体系结构详细设计
任务
1）确定每个模块的具体算法
2）确定每个模块内部的数据结构以及数据库的物理结构
3）确定模块接口的具体细节
4）为每个模块设计一个测试用例
5）编写文档，参加复审
原则
1）程序的清晰度放在首位
2）设计过程采用逐步细化的实现方式
3）选择适当的表达工具
6.软件测试技术
软件测试
基本原则
1）尽早地并不断地进行软件测试
2）避免测试自己设计的程序
3）测试用例不仅要有输入数据，还应有预期结果
4）测试用例不仅要有合法数据，还要有非法数据
5）对修改过的程序进行回归测试
6）保留测试计划、全部测试用例、出错统计和最终分析报告
7）对每一个测试结果做全面检查
8）严格执行测试计划，排除测试的随意性
方法
1）静态分析技术
2）动态分析技术
白盒测试技术
概念
如果已知产品的内部活动方式，就可以测试它的内部活动是否符合设计要求
白盒测试用例设计
1）语句覆盖
2）判定覆盖
3）条件覆盖
4）判定/条件覆盖
5）条件组合覆盖
6）点覆盖
7）边覆盖
8）路径覆盖
黑盒测试技术
概念
已知产品应具有的功能的情况下，通过测试检验每个功能是否正常使用
黑盒测试用例设计
1）等价类及其划分
1.具有数据测试等效性的一组数据成为一个等价类
2.数据测试的等效性是指子集中的一个数据能够测试出软件的错误，则子集中的其他数据也能够测试出错误，反之，子集中的一个数据不能测试出软件的错误，则子集中的其他数据也不能测试出错误
3.等价类划分是把程序的数据数据集合按照输入条件划分为若干等价类，每一个等价类相对于输入条件表示为一组有效或无效的输入，然后为每一个等价类设计一个测试用例
2）边界值分析
3）因果图法
检查各种输入条件的组合
4）错误推测法
软件测试策略
1）单元测试
2）集成测试
3）确认测试
4）系统测试
7.面向对象技术总论
面向对象方法论
非结构化分析方法
非结构化分析方法就是要把问题域或现实世界中的概念和处理，其基本元素是变量和语句，即所谓的数据结构+算法。
结构化技术
结构化技术的基本元素是定义良好的程序结构元素，程序=数据结构+函数结构+函数调用。
面向对象技术
面向对象技术阶段，程序的基本元素是数据结构和函数结构的统一体“类”，程序=类结构+对象+消息。
面向对象技术的基本概念
类
类是具有相同结构特征的对象的结构抽象
对象
现实世界或概念世界中的具体事物就是对象
对象三要素
（1）确定的标识，能够被唯一的确认；
（2）具有一定的属性，表示其性质或状态；
（3）具有一定的行为能力或操作能力，可给外界提供服务或者通过操作改变其状态。
消息机制
在面向对象程序中，调用一个对象的方法或操作叫做向该对象发消息
面向对象技术的基本特点
封装性
将变量和方法私有化，从程序外部不能直接访问，必须通过对外公开的方法访问
继承性
子类自动拥有父类的所有代码并可以任意覆盖和填充
多态性
同一种事物可以有多种不同的含义或状态
抽象性
抽象类、接口
面向对象分析方法
把现实世界或者问题中的事物、概念、过程等抽象成概念模型中的对象或类，然后转换成程序语言中的对象或类。
面向对象技术与程序结构
重构
不改变程序外在功能的前提下重新设计已有的代码，以获取代码新的特性
重构方法
1）提取方法
2）引入父类或接口
3）属性和方法的上移或下移
面向对象软件工程
设计模式与框架
设计模式
模式是对经常出现的某些问题的优秀解决方案模板
设计模式是在系统设计中为了获得更好的可重用性和可扩充性而被不断重复使用的设计方案
框架
框架是整个或部分系统的可重用设计（可被应用开发者定制的应用系统骨架）
设计模式只解决某个问题，框架解决某一方面问题
分类
白盒与黑盒框架
白盒框架：基于继承的框架
黑盒框架：基于对象构件组装的框架
“热点”、“食谱”以及“好莱坞”原则
“热点”：扩展槽，可以看做抽象类，开发者通过重写抽象方法获得
“食谱”：描述如何使用框架方法的文档
“好莱坞”原则：用户定义的方法经常被框架调用
8.业务模型
业务模型概述
业务模型是建立软件系统时所依据的现实世界或者问题域模型，是建立软件系统的基础
业务建模
目的
（1）理解组织的目标，明细目前存在的问题，标示出潜在的改进措施；
（2）评估组织业务变化的可能性和这种变化的影响范围；
（3）保证客户、用户、开发者和相关人员对组织有一直的理解；
（4）导出支持目标组织的软件系统需求；
（5）理解将要部署的软件系统怎样才能适合于组织的需求。
内容
在RUP的业务模型过程中，除了建立业务用例模型和业务分析模型之外，还需要建立：
（1）业务愿景：包括业务目标、范围、前景等；
（2）业务体系结构：包括组织结构和业务结构；
（3）补充的业务规格说明：主要的业务规格外的非关键的业务要求；
（4）业务规则：包括了业务进行的约束和条件；
（5）业务字典：包含了业务系统中的主要业务术语及解释。
业务建模流程
1）评估企业状态
2）描述目前企业的业务状态、定义企业的业务体系结构
3）对业务体系进行细化，建立域模型，为定义自动过程化做准备
9.需求分析与用例模型
需求分析
Actor（参与者）及其关系
用例及其关系
用例
用户为了获取有价值的目标，对系统功能的执行过程
注意：
1）用例必须获取有价值的目标或达到一定目的
2）通过一个或多个交互活动序列来完成目标
用例之间的关系
包含关系
包含关系连接一个基本用例和包含用例，被包含用例描述了将被插入到基本用例中的行为片段。基本用例控制包含关系，并且依赖于被包含用例的执行结果，但基本用例和被包含用例都不能互访其属性。被包含用例封装了可以多个用例中重用的行为。使用包含关系可以从基本用例中分解出公共行为，该公共行为的实现方法对理解基本用例的目的而言是无关的，基本用例仅仅依赖于其结果，也可以将两个或者两个以上用例的公共部分分离出来，经封装后形成被包含用例。
扩展关系
扩展关系用来把一个扩展用例连接到基本用例，可以定以基本用例中的扩展点。其目的或者是表示基本用例的一部分行为是可选的，将可选部分和必须部分分离开来；或者表示扩展用例代表的子工作流仅在某个条件满足才被执行；或者表示有一组行为片段，其中一个或多个被插入到基本用例的扩展点。
泛化关系
泛化关系是一般和特殊、共性和个性、抽象和具体之间的关系。该关系具有普遍性，在UML中可以应用于参与者、用例和类之间。泛化关系应用于用例时，具有一般性的用例称为父用例，具有特殊的用例称为子用例。父用例可以被一个或多个子用例具体化。父用例一般定义成抽象的，子用例继承了父用例所有的结构、行为和关系。
用例规格说明
从用例的执行过程来进一步描述用例的具体细节
10.分析设计与对象模型
类和对象的定义
类的定义
类是一组对具有相同属性、操作、关系、语义的对象结构的描述
类的高级概念
1）类元
2）可见性
3）范围
4）抽象
5）多重性
6）属性
7）操作
8）模板类
9）标准元素
对象、类之间的关系
泛化
关联
聚集
依赖
抽象类和接口
分析模型
边界类
控制类
实体类
设计模型
抽象类和接口的设计原则
缺省抽象原则
在接口和实现类之间插入一个抽象类，将与子类无关的，可实现的操作接口实现，将变化和不变的部分分离开
接口设计原则
接口只提供操作接口，不需要考虑在接口中实现某个方法
黑盒原则
进行对象关系的设计时，多选用类的聚合，少选用类的继承（继承会破坏类的封装性 ）
类图
领域设计
面向对象设计原则
1）单一职责原则
2）开闭原则
3）Lislov替换原则
4）依赖倒置原则
5）接口分离原则
对象模型与关系模型
11.系统结构与关系模型
包的概念
包是一种分组机制或命名空间，也可以认为是一种集合元素或容器元素，其中包含不同类型的产品
包之间的依赖关系
某一个包中的元素和另一个包中的元素存在依赖关系，则这两个包存在依赖关系
包的版型
用包表示的系统高级层次
设计包的原则
1）重用等价原则
2）共同闭包原则
3）共同重用原则
4）非循环依赖原则
5）稳定依赖原则
6）稳定抽象原则
12.系统动态特征与抽象模型
动态模型概述
系统的静态模型描述了系统的组成关系及其结构，包括元素及其关系
系统的动态模型则表示了系统对外表现的功能、性能、特性等实现过程
交互图
1.概述
交互图描述了系统功能的执行过程，参与实现对象之间的交互（消息和响应）情况，包括顺序图和通信图
2.顺序图
1）顺序图描述的是针对系统功能一次执行过程中，系统对象的交互情况。 顺序图中只能出现对象实例
2）消息是对象间的通信（传递消息或触发任务）
顺序图中的消息用水平实线箭头表示
3）建立顺序图的方法和步骤
（1）确定参与用例执行或实现的对象，在顺序图中建立它们
（2）根据用例描述的活动流顺序描述对象的交互，标识信息，检查一致性和完整性
（3）将对象对应到系统的类，消息对应到类的操作，再次检查一致性和完整
3.通信图
1）通信图用于描述对象如何通过交互或通信来实现用例的功能
2）通信图的元素
对象实例
联系
消息
4.顺序图和通信图比较
顺序图强调交互的过程性和顺序性，适合系统设计阶段
通信图强调对象之间的关系，适合分析阶段
状态图
活动图
