软件工程 期末复习资料

结构化分析：数据流图、er图、状态转换图、数据字典

结构化设计：流程图、盒图、pad图、IPO图、判定表、判定树、软件结构图

面向对象分析：用例图、活动图、包图、类图、顺序图、协作图、状态图

面向对象设计：三层架构、构件图、部署图

软件生存周期模型

1)瀑布模型
瀑布模型是把每一个阶段都划分的很独立。
自上而下、相互衔接的固定次序。

2)增量模型

我们通常可以先以某个核心需求作为初始，然后按照瀑布模型的活动组织方式，去完成这个需求。后面如果还有新的需求，可以通过增量的方式，再按照瀑布模型的方式完成增量的开发，从而最终完成所有的用户需求。

而软件的功能实际上是为了实现某种需求，软件的功能可以分解，因此需求也是可以分解的。

分类：增量构造模型、演化提交模型

3)演化模型（原型模型）
定义：是一种有弹性的过程模式，由一些小的开发步组成，每一步需要经历需求分析、设计、实现和验证。

特点：通过迭代，完成最终软件产品的开发。需要快速的迭代，经历从需求到最后测试的过程，形成一个可运行的雏形，给用户反馈。

适用：适用于不能预先确切定义需求的软件项目
验证你的项目的可行性，原型模型是比较适用的
就是在你不确定的需求，甚至当其他阶段比如采用的实现手段、技术不确定的时候，都可以使用原型模型，尽快的开发出一个可运行的版本

上诉三种模型的本质区别：主要在于需求是否明确。瀑布模型是需求十分明确，增量模型是部分明确，原型模型通常是需求不太明确的

4)喷泉模型（生鱼片模型）
迭代、无缝。即软件开发各个阶段中没有明确界限。

5)螺旋模型

从内到外看，每一次迭代都经历了四个象限，旋转了一周，依次获得的原型是概念、需求、设计以及最后的可运行原型产品，产出的是瀑布模型的一个阶段的产品。

而且每一个开发阶段前引入风险分析，每迭代一次，软件开发阶段前进一个层次。每迭代一次，都是瀑布模型的一个阶段的活动，就是说瀑布模型的每一个阶段的活动，螺旋模型都经历了一个周期。

螺旋模型的风险分析实际上是为了商业大型软件的开发，所以螺旋模型也是风险驱动的模型。

面向对象软件过程模型

1）构件集成模型
整个系统模块化
复用构件库中的软件构件

2）统一过程模型
统一过程模型RUP（Rational Unified Process)把软件开发的各个阶段整合在一个统一的框架之中。

统一过程模型是一个二维的软件开发模型

统一过程模型驼峰图：

RUP的工作流（纵轴）和开发流程的各个阶段（横轴），图中的阴影面积代表不同角色在各个阶段的参与程度。

四个阶段：

总结：
1）瀑布模型是一种线性模型，文档驱动的模型。
2）增量模型采用一系列的增量方式开发系统。
3）螺旋模型结合瀑布模型和快速原型，是一种风险驱动的开发模型
4）构件集成模型利用模块化方法将整个系统模块化，复用构件库中的软件构件，通过组合手段提高应用软件系统过程的效率和质量。
5）统一过程模型是以用例驱动的，以架构为中心，迭代和增量的过程。
6）瀑布模型是需求十分明确，增量模型是部分明确，原型模型通常是需求不太明确的

需求分析

1）定义：
是指在开发一个新的或升级一个已有的软件系统时描写新系统的目的、范围、定义和功能时所要做的所有工作。

2）作用：
需求分析是软件开发的工作基础。它将作为后面软件设计活动的基础，同时又是最终软件验收评估的依据。

3）目的：
要求开发人员准确的理解用户需要什么，进行细致的调查分析，将用户的需求陈述转化为完整的需求定义，再转化为相应的软件需求规格说明。

【需求分析最终的目的就是从业务需求、用户需求那里获取到我们项目系统软件开发的需求，即系统到底要做什（what），然后将需求用更精确的，半形式化的方式描述出来，形成需求规约说明书。】

4）分类：
A.业务需求：
从组织机构或客户角度，对系统、产品高层次的目标需求。

B.用户需求：
从使用产品的用户的角度，即用户的目标或用户要求系统必须能完成的任务。

C.功能需求：
从产品本身的角度，即产品要具备怎样的功能，才能满足相应的业务需求和用户需求。

D.非功能需求：
非功能需求包括性能、外部接口、设计约束、质量属性等。

【业务需求和用户需求是用来推导出软件功能需求和软件非功能需求的。】

例子：用户自动寄件
业务建设方：某快递公司
需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。
业务需求：用户自助寄件，减少人力成本、高效、准确无误。
用户需求：自助寄件，而且简单、易用，高效、快捷。
功能需求:
场景阶段：填单，放件，支付
填单：电子表格方式；
服务定位：发现柜子、导航；
找到空闲柜子：柜子忙闲资源管理
打开柜子：通过扫描、验证码等方式
计量：按体积
支付：提供多种支付方式

5）获取需求的方法：
①自悟 ②交谈 ③观察 ④小组会 ⑤提炼
【会谈技术、调查技术、场景分析技术、快速原型法】

场景分析技术 案例：
场景名：取款
参与者：银行客户
场景描述：
1．插入有效的银行卡；
2．ATM机验证该银行卡；
3．系统要求输入银行卡密码，用户输入密码；
4．系统通过网络向银行内部系统请求验证密码；
5．若验证通过，系统请求选择业务，选择取款；
6．系统要求输入取款金额，比如1000元；
7．系统验证是有足够的现金，并请求验证银行内部服务器处理取款；
8．若处理成功，系统计算钞票数目，并送出现金；
9．用户取走现金；
10．系统打印凭条，用户取走凭条；
11．系统退出银行卡，用户取走银行卡。

快速原型法 案例1：图书馆系统
图书流通管理：负责图书借还工作。
用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。
编目管理员：负责图书的管理、用户管理和处理罚金等
图书借出：管理员完成一次借书过程。
图书归还：管理员完成一次还书过程。
图书预约：用户查询要借的图书，若不能借，可预约该图书。
图书续借：用户可以将图书的归还日期延长一段时间。
图书管理：添加新书。更新图书馆信息，销毁图书。
用户管理：注册新用户，更新用户信息，注销用户。
处理罚金：用户缴纳罚金，系统将罚金数额清零。

快速原型法 案例2：ATM系统
银行客户: 接受系统服务；
银行的代表: 银行间自动柜员机有互惠协议；
支行管理者: 从该系统中获得管理信息；
支行柜台职员: 负责系统日常运转和处理客户意见；
数据库管理者: 负责系统和客户数据库集成；
银行信息安全管理者: 负责保证系统信息安全；
银行市场开发部: 将该系统视为银行市场开拓手段；
硬件和软件工程师: 负责硬件和软件维护及升级。
存款：从ATM机上存钱到指定账户上。
取款：从指定账户上取一定数量的货币。
转账：从一个账户取出一定数量的货币，然后转存到另一个账号上。
查询余额：察看指定账户的余额。
修改密码：修改账户密码。

6）需求规约（又叫 需求规格说明 或 需求规约文档，即 SRS）：
A.概念：需求规约是一种规范，形式化或半形式化的描述了系统的功能，性能，设计约束，数据，验收标准等所有与需求相关的信息。通常以软件需求规格说明书的形式存档。

B.作用：
a.作为软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现；
b.对于项目的其余大多数工作，是一个管理控制点；
c.对于产品的设计，是一个正式的、受控的起始点；
d.是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档-----初始测试计划和用户系统操作描述。

C.软件需求和软件需求规约的区别：软件需求规约即为软件需求的规范化描述。

D.需求分析的一般过程：
采用需求获取技术从用户等人员获取需求，确定功能、性能、设计约束、外部接口、质量属性等，然后选用合适的软件开发方法学（如结构化方法学，面向对象方法学），采用其需求分析方法建立模型（即对需求进行精确建模），然后将编写SRS草案，评审形成最终的SRS，将作为软件设计的基础，作为用户和开发人员之间软件最终验收的标准。

结构化分析

1.定义：一种适用于大型数据处理系统的、面向数据流的需求分析方法。
1）面向数据流的建模方法
数据流图（DFD）-功能域
2）面向数据的建模方法
实体关系图（E-R图）—信息域
3）面向状态的建模方法
状态转换图（STD）-行为域

2.结构化需求分析建模方法：
1）面向数据流的建模方法：数据流图（DFD, Data Flow Diagram）-功能域

A. 建模元素：

B. 附加符号：

C.构建DFD的过程：自顶向下，逐层分解

① 构建顶层数据流图（系统的输入输出）
顶层数据流图体现系统的应用领域及系统与外界的主要接口。具体内容由以下三部分组成：
 ◆一个加工，标识被开发的系统
◆与系统有关的全部外部实体**（即数据源点、终点）**。
 ◆与外部实体相关的系统主要输入、输出数据流。

注：顶层数据流图只包含一个处理，即标识被开发的系统

② 构建0层数据流图 （细化顶层数据流图）
0层数据流图体现系统主体功能及各项功能与外部的接口情况，主体功能体现系统框架。由四部分组成：
 ◆加工。每个主体功能用一个加工表示。
 ◆主体功能相关的输入、输出数据流。
 ◆外部实体。这些外部实体分别通过输入数据流引发各主体功能执行，并接收执行后的输出结果。
 ◆数据存储。体现主体功能执行后产生的、需要保留在系统内部的结果数据的去处。

③ 逐层细化数据流图
首先细化0层图，将一个主体加工分解为不同的加工，每个操作环节分别由一个加工表示。如果主体功能复杂，难于在1层图中全部细化完成，则可以再次细化，产生2层图。以此类推，直到内部的执行逻辑十分简明、不能再细化为止。

数据流图 案例1：
设一个工厂采购部每天需要一张订货报表。
订货的零件数据有：零件编号、名称、数量、价格、供应者等。
零件的入库、出库事务通过计算机终端输入给订货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次订货。
（顶层->0层->1层）

数据流图 案例2： 图书预订系统
书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查并对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后系统将所处理的订单汇总，并按出版社要求发给出版社。

（按层给加工编号）

（保持父图与子图的平衡

）

2）面向数据的建模方法：实体关系图（E-R图）—信息域

实体（矩形）、实体属性（椭圆形）、关联（菱形）、基数（一对一、一对多、多对的）
ERD（Entity-Relationships Diagram实体关系图）

案例：
【例】假定一个生产销售产品的管理系统包括以下信息
职工的信息：职工编号、姓名、住址、所在部门编号。
销售部门的信息：销售部门编号、部门名称、部门经理。
产品的信息：产品编号、产品名称、价格、型号。
制造商的信息：制造商编号、制造商名称、地址、法人代表。
其中，一个销售部门有若干个职工，但一个职工只属于一个销售部门，一个销售部门可以销售多种产品，一种产品可以在多个销售部门销售，一种产品可以由多个制造商供应，一个制造商可以供应多种产品。
试画出该系统的ER图。

3）面向状态的建模方法：状态转换图（STD）-行为域
（1）状态机建模方法步骤：
①系统状态、行为与事件分析
②构建状态图

（2）状态模型一般采用状态转换图（简称状态图）的标记方法

（3）表示
①状态是可观察的行为模式，用圆角矩形表示。初态用实心圆表示，终态用一对同心圆表示；
②变迁表示状态的转换，用箭头表示；
③事件是引发变迁的消息，用箭头上的标记（事件表达式）表示。
事件表达式的语法如下：
事件说明[守卫条件]/动作表达式
（4）案例：
【例】某汽车停车场欲建立一个信息系统，需求如下：
a．在停车场的入口和出口分别安装一个自动栏杆、一台停车卡打印机、一台读卡器和一个车辆通过传感器。
b．当汽车到达入口时，驾驶员按下停车卡打印机的按钮获取停车卡。当驾驶员拿走停车卡后，系统命令栏杆自动抬起；汽车通过入口后，入口处的传感器通知系统发出命令，栏杆自动放下。
c．在停车场内分布着若干个付款机器。驾驶员将在入口处获取的停车卡插入付款机器，并缴纳停车费。付清停车费之后，将获得一张出场卡，用于离开停车场。
d．当汽车到达出口时，驾驶员将出场卡插入出口处的读卡器。如果这张卡是有效的，系统命令栏杆自动抬起；汽车通过出口后，出口传感器通知系统发出命令，栏杆自动放下。若这张卡是无效的，系统不发出栏杆抬起命令而发出告警信号。
e．系统自动记录停车场内空闲的停车位的数量。若停车场当前没有车位，系统将在入口处显示“车位已满”信息。这时，停车卡打印机将不再出卡，只允许场内汽车出场。

请画出停车场入口护栏的状态图。

3.数据字典
1）定义：数据字典是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述

2）作用：①它是所有名字信息管理的有效机制
②作为连接软件分析、设计、实现和进化阶段的开发机构的信息存储

3）数据字典应该由四类元素的定义组成：
数据流条目
数据存储条目
数据项条目（数据流或数据存储分量）
加工条目

4）数据字典定义中的符号

5）案例：订货系统
（1）数据流条目
通常列出该数据流的各组成数据项。

（2） 数据项条目
数据流的组成成员是数据项，数据项条目是不可再分解的数据单位。其定义格式及举例如下。

（3）数据存储条目
与数据流条目一样。对存储数据的定义用数据存储条目。数据存储条目主要内容及举例如下。

（4）处理加工条目

（通常采用输入—处理—输出（IPO，Input-Process-Output）视图描述）

【总结】
（1）结构化分析方法是一种自顶向下，逐步分解的面向数据和数据流的建模方法。
（2）面向数据的建模以实体、关系和属性三个基本元素描述系统，涉及数据及其它们之间的关系，用ERD表示。
（3）基于数据流的方法用于描述数据如何在系统中流动或被变换，用数据流图DFD、数据字典、加工规程等形式表示。
（4）面向状态的建模用于描述系统对内部或者外部事件响应的行为，用状态图表示。

结构化设计

1 . 概念: 软件系统设计是把软件需求“变换”为用于构造软件的蓝图。
“输入”是需求分析各种模型元素
“输出”是软件设计模型和表示

2 . 目的: 软件设计的目标是对将要实现的软件系统的体系结构、系统的数据、系统模块间的接口，以及所采用的算法给出详尽的描述。

软件模块化设计的指导思想：分解、抽象、逐步求精、信息隐蔽和模块独立性

3 . 分类:

1. 总体设计，也称为概要设计，软件结构设计，或高层设计。 【 总体设计的一般过程：将DFD变换到初始的MSD，然后根据一些设计原则对MSD进行精化、优化 】
   分析需求规格说明
   模块划分，形成具有预定功能的模块组成结构
   表示出模块间的控制关系
   给出模块之间的接口

（1）主要任务（即 功能模块化）
将系统划分成模块；
决定每个模块的功能；
决定模块的调用关系；
决定模块的接口，即模块间传递的数据。

（2）在概要设计阶段，结构化设计 主要采用 面向数据流的设计方法。
（面向数据流分析（DFA，Data Flow Analysis）的设计是一种结构化的软件体系结构设计方法。）
（这一设计技术是从数据流图（DFD）分析模型映射为软件模块组成结构设计的描述，所以也称为结构化设计（SD，Structured Design）方法。）

（3）三种数据流类型：变换流、事务流、混合流
变换流

事务流

混合流（将事务流和变换流组合出现）

（4）数据流设计方法：变换设计方法、事务设计方法、混合流设计方法
变换设计方法

事务设计方法

案例：

混合流设计方法
①主图是变换型，子图是事务型

②主图是事务型，子图是变换型

2） 软件详细设计，也称为（模块）过程设计，或低层设计。
· 设计模块细节
· 确定模块所需的算法和数据结构等
（1）三种基本结构：顺序、选择、循环结构

（2）设计工具
2.1 图形工具
2.1.1 流程图
①符号

②基本控制结构

③举例
【例】现有一个短信监听系统，工作流程如下：
a．打开监听程序监听短信接收。
b．如果收到短信，就读取短信内容并显示在文本框内；如果没有收到短信，就继续监听。
c．显示完短信后，如果想结束监听，就关闭监听程序退出系统。
根据上述的工作流程画出短信监听系统的程序流程图。

2.1.2 盒图（N-S图）
①符号

②举例

2.1.3 PAD图（问题分析图（Problem Analysis Diagram））
①符号

②举例

2.1.4 HIPO图（Hiberarchy Plus Input-Process-Output,层次加输入-处理-输出）
①HIPO图由两部分组成：
可视目录表给出程序的层次关系
体系框图：又称层次图（H图），是可视目录表的主体，用它表明各个功能的隶属关系
图例：图形符号说明
描述说明：每一功能框图的补充说明
IPO图则为程序各部分提供具体的工作细节

②举例
盘存／销售系统工作流程图

可视目录表

概要IPO图

详细IPO图

2.2 列表工具
2.2.1 判定表
①结构

②举例：在PPT中

2.2.2 判定树
判定树是判定表的变形，一般情况下它比判定表更直观，且易于理解和使用

2.3语言工具：PDL语言（过程描述语言）

【软件结构、软件结构图、软件结构优化区别】

4.表现形式:模块结构图（简称MSD，或软件结构图SC）
模块结构图来表示软件体系结构。
软件结构图建模要素:模块、调用（控制）、信息传递
模块：模块用带有名字的方框表示，名称应体现模块的功能。
控制关系（调用包括选择调用和循环调用）：控制关系用单向箭头或直线表示模块间的调用关系。
信息传递：用带注释的短箭头表示模块调用过程中传递的信息。

5.模块独立性
1）度量标准：内聚（块内联系 或 模块强度）、耦合（块间联系）
2）内聚（又称 块内联系 或 模块强度）：一个模块之内各成分之间相互依赖程度的度量。
分类：

3）耦合（又称 块间联系）：不同模块之间相互依赖程度的度量
分类：

4）模块设计遵循的原则：高内聚、低耦合（即 块内联系越强，块间联系越弱）

6.软件结构的形态特征准则
深度：指结构图控制的层次，即模块的层数。
宽度：指一层中最大的模块个数。
扇出：指一个模块直接下属模块的个数。如模块M的扇出为3。
扇入：指一个模块直接上属模块的个数。如模块T的扇入为4。
例：

深度：5 宽度：8 T的扇入数：4 M/C的扇出数：3

7.软件模块结构图的优化原则
1） 改进软件结构，提高模块独立性
2) 模块规模适中-每页60行语句
3) 深度、宽度、扇入和扇出适中
4) 模块的作用域力争在控制域之内
5) 降低模块接口的复杂性
6) 模块功能应该可以预测

【1. 模块的规模最终还是应该由模块的功能来决定，不违背模块的单一职责原则。一个模块具体多少句这个不定。当然如果过长会影响可读性。
2. 软件模块结构图的形态特征：一般顶层扇出数较高一些，中间层扇出数较低一些，底层扇入数较高一些。当然，也不能过分追求底层扇入数，不能违背模块高内聚特性。】

面向对象分析

1.基础
面向对象分析（OOA，Object-Oriented Analysis）
面向对象设计（OOD）
面向对象实现(OOP)
面向对象测试(OOT)

2.统一建模语言UML
统一建模语言（UML，Unified Modeling Language）是一种基于面向对象的可视化建模语言。
UML用丰富的图形符号隐含表示了模型元素的语法，并用这些图形符号组成元模型表达语义，组成模型来描述系统的结构（或称为静态特征）以及行为（或称为动态特征）。
UML的模型元素：
一类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等；
另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖、聚集（表示整体与部分的关系）等。
面向对象分析阶段的主要任务是获取用户的需求，并构建系统初步的逻辑模型。

3.用例建模
1）用例图
（1）建模元素
参与者：与系统交互的用户或其他软硬件系统，用小人形表示。
用例：系统中执行的一系列动作，用椭圆表示。
关系：参与者与用例、参与者之间、用例之间的联系。
主题：一组用例描述的系统或子系统，用矩形框表示。
（2）例子

（3）关系
参与者之间的关系--------------泛化关系

参与者与用例之间的关系-------------关联关系

（带箭头的实线表示，箭头指向用例）

用例之间的关系-------------包含关系、扩展关系、泛化关系
包含关系（<> ）：一个用例（基础用例）的行为包含另外一个用例（被包含用例）的行为。
箭头的方向是从基础用例 指向 被包含的用例。

扩展关系（<>）：扩展用例可以在基础用例之上添加新的行为。
箭头方向由扩展用例指向基础用例。

泛化关系：

（4）案例1 酒店订房系统
(1)顾客可以选择在线预订，也可以直接去酒店通过前台服务员预订；
(2) 前台服务员可以利用系统直接在前台预订房间；
(3) 不管采用哪种预订方式，都需要在预订时支付相应订金；
(4) 前台预订首选通过现金形式进行订金支付，若现金不足，则只能通过信用卡形式进行订金支付，但是网上预订只能通过信用卡进行支付；
(5) 利用信用卡进行支付时需要和信用卡系统进行通信；
(6) 客房部经理可以随时查看客房预订情况和每日收款情况。
构造该系统的用例模型。

（5）用例描述

例子：
用例名称：处理一次销售
范围：POS机应用
级别：用户目标
主要参与者：收银员
涉众及其关注点：
收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。
售货员：希望自动更新销售提成
顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。
公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。
经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。
前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付授权的批准。

2）活动图
（1）基本元素
初始节点和活动终点：实心圆表示初始节点（只有一个），圆圈内加一个实心圆来表示活动终点（可有多个）。
活动节点：表示一个活动。

转换：
分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。

分叉与汇合：

（2）例子

3）泳道图
（1）例子 处理订单泳道图示例

（2）带对象流的活动图

4.领域与业务建模
分析类（边界类、控制类、实体类）
边界类：边界类用于建立系统与其参与者之间交互的模型，表示用户界面、系统接口、硬件接口。

实体类：

控制类：类似于设计模型中的控制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。

5.包图

6.系统顺序图（System Sequence Diagram,SSD）
7.UML顺序图（面向时间的，也叫时序图、序列图）
【区别】系统顺序图是用例的可视化表述，而顺序图是对象方法的可视化表述。
系统顺序图的研究对象是参与者以及系统，而顺序图的研究对象是对象。
（1）从左到右、从上到下可以很好地表示出系统数据的流向
（2）时序图用于描述对象之间的传递消息的时间顺序, 即用例中的行为顺序
（3）生命线是一条垂直的虚线. 表示时序图中的对象在一段生命周期内存在. 每个对象底部中心的位置都带有生命线。
在 UML 中, 对象激活时将对象的生命线拓宽为矩形来表示的. 矩形称为计划条或控制期. 对象就是在激活条的顶部被激活的. 对象在完成自己的工作后被钝化（指对象处于空闲状态, 等待消息）。
（4）思维导图

（5）案例1 ATM 用户成功登陆的时序图

（6）案例2 机房收费系统关于上机的顺序图

（7）案例3 孙中山

8.协作图（又叫 通信图）
（1）协作图的组成元素包括对象、消息、链(连接器)。消息表示了对象间的通信，对象通过链连接在一起。
（2）通信图和顺序图之间的语义是等价的，只是它们的关注点有所不同而已，可以很容易的完成从顺序图到通信图的转换。
（3）通信图强调参与交互的对象的组织结构; 顺序图强调消息的时间顺序。

（4）案例1

（5）案例2 机房收费系统关于上机的协作图

（6）区别：时序图主要侧重于对象间消息传递在时间上的先后关系,
而协作图表达对象间的交互过程及对象间的关联关系，或者说为空间上的关系。

9.状态图
POS机状态图

【总结】
用例驱动的面向对象分析：UML用例图、辅以其他UML动态模型（重点，难点）
OOA的领域与业务建模：UML类图（分析类），包图（重点，难点）
OOA的系统行为建模：（顺序图，协作图，活动图，状态图）（重点，难点）

面向对象设计

1.软件体系结构数据
（1）系统逻辑体系结构
描述系统的逻辑结构（例如分层的体系结构）
UML包图、类图提供建模支持
通常以设计模式为指导，优化结构
（2）系统物理体系结构
描述系统的物理组成和运行时拓扑结构
UML构件图和部署图提供建模支持

2.三层架构
界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）

三层架构并不是按功能来分解软件系统，而是按类和对象进行分层，将完成同一职责的类和对象分为一层。

3.MVC模式的Web体系结构
模型(Model)－视图(View)－控制器(Controller)
POS机系统三层架构图：

4.类间关系
（1）依赖
【依赖关系】：即一个类的实现需要另一个类的协助。
【箭头及指向】：带箭头的虚线，指向被使用者

（2）关联
【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者。

【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体

【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。
组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
【代码体现】：成员变量
【箭头及指向】：带实心菱形的实线，菱形指向整体

（3）泛化
【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。
【箭头指向】：带三角箭头的实线，箭头指向父类

（4）实现
【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.
【箭头指向】：带三角箭头的虚线，箭头指向接口

【总结】依赖< 关联（拥有的关系） < 聚合（整体与部分的关系，且部分可以离开整体而单独存在） < 组合（是整体与部分的关系，但部分不能离开整体而单独存在） < 泛化 （（继承关系），实现（类与接口的关系））

【例题 1】

【例题 2】

5.构件图
（1）主要元素：构件、接口和依赖关系
构件：可以是源代码构件、二进制构件或一个可执行的构件。在UML中，构件用一个左侧带有突出两个小矩形的矩形来表示。

接口：提供（provided）接口和所需（required）的接口

依赖：构件间的关系以依赖的形式表达。把提供服务的构件称为提供者，把使用服务的构件称为客户。
在UML中，构件图中依赖关系的表示方法与类图中依赖关系相同，都是一个由客户指向提供者的虚线箭头。

（2）基本语法

【说明】
1、构件图用于描述系统中某一功能模块。
2、构件图之间可以提供服务和获得服务。
3、构件图常见的类型有五种：
1）可执行的：表示像exe这类可执行文件及模块。
2）文档：像java这类文件。
3）表：像关系数据库中的表形式。
4）文件：普通的文件。
5）库：像C语言中的函数库，Java里面的API接口库。

（3）构件的特点
①能实现一定功能，或提供一些服务。
②不能单独运行，要作为系统的一部分来发挥作用。
③是物理上的概念，不是逻辑上的概念。
④可单独维护、可独立升级、可替换而不影响整个系统。

（4）案例1

（5）案例2

6.部署图
（1）组成元素：节点、节点间的连接
节点：节点用一个立方体来表示

按照节点是否有计算能力，把节点分为两种类型：处理器节点和设备节点，分别用构造型《Processor》和构造型《Device》表示处理器和设备。

节点间的连接
节点之间的连接表示节点之间物理连接以及其上用的通信协议。用直线表示。

构件分配到节点
当某些构件驻留在某个节点时，可以在该节点的内部描述这些构件。

（2）基本语法

【说明】
1、实际环境中的一台电脑、服务器等硬件设备，在部署图中用节点来表示，节点是一个立体矩形，这也是UML中唯一一个立体图形。
2、节点和节点之间如果有物理连接，则可以用通信路径连接，在路径上写上连接方式，常用的方式有Internet和LAN。
3、标记是用来详细说明节点的配置情况的。
4、制品是可独立运行的软件。

（3）案例

软件测试

1.定义：检测和评价软件以确定其质量的过程和方法，即评价软件或程序的属性和能力，已确定它是否满足所需要的过程和方法。

2.按技术方法进行划分：
静态测试：人工检测和计算机辅助静态分析（不运行被测程序，仅通过分析或检查源程序的语法、结构等来检查程序的正确性）
动态测试：包含黑盒测试（功能测试）和白盒测试（结构测试）

黑盒测试和白盒测试方法是设计测试用例的最基本最重要的两种方法，也是我们软件测试学习的重点。

测试用例的英文是TestCase。测试用例由一组输入和期望结果组成。

通常我们需要基于黑盒测试和白盒测试设计合适的测试用例，作为测试计划。

当我们编写完软件程序之后，我们就拿这组设计好的测试用例进行程序的测试。将测试用例的输入作为程序的输入，然后运行程序，检验程序结果，如果具体的结果与测试用例的期望结果一致，则程序通过当前测试用例的测试。

3.目标：预防错误和发现错误，找到bug。

4.软件测试的基本原则
①所有的测试都应当追朔到用户需求
②在测试工作开始前，要进行测试计划的设计
③测试应从小规模开始，逐步转向大规模
④穷举测试是不可能的
⑤为了尽可能的发现错误，应由独立的第三方来测试
⑥测试只能保证尽可能多地发现错误，无法保证能够发现所有的错误。

5.黑盒测试技术
1）概念
黑盒测试又称功能测试，把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只根据程序的功能和需求规格说明，检查程序的功能是否符合它的需求规格说明。

2）特点
完全不考虑程序内部结构和内部特性只测试接口，检测是否正确输出和输出完整 是穷举输入测试。

3）黑盒测试能发现的错误
功能错误或遗漏；
在接口上，输入接收错误或输出结果错误；
数据结构错误或外部信息（如数据库）访问错误；
性能错误；
初始化或终止错误。

4）具体方法
（1）事务流测试
（2）等价类划分
①等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。
②分为两类：有效等价类（各种正确的输入数据），无效等价类（各种错误的输入数据
）
③设计测试用例步骤
A.划分等价类，并为每一个等价类规定一个唯一的编号；
B.设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
C.设计一个新的测试用例，使其覆盖一个无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

（2）边界值分析

6.白盒测试
1）概念
白盒测试把被测软件看成一个透明的盒子，测试人员完全知道程序的内部结构和处理过程，对程序内部尽可能多的逻辑路径进行测试。通常又称为逻辑覆盖法。

2）测试技术
（1）逻辑覆盖法
语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能执行一次

判定覆盖：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分支至少都通过一次

条件覆盖：执行足够的测试用例，使得判定中每个条件获得各种可能的结果

判定／条件覆盖：执行足够的测试用例，同时满足判定覆盖和条件覆盖的要求

条件组合覆盖：执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次

（2）基本路径测试法
①基本路径测试法是根据程序的控制流路径设计测试用例的一种最基本的白盒测试技术。
②考察测试路径的有用工具：程序控制流图

（3）循环测试方法

软件的维护与管理

1.软件的维护
1）软件可维护性
（1）特性
（2）提高可维护性
结构化维护、技术途径

2）软件维护类型
纠错性维护（纠正修改软件系统中潜伏的错误）、完善性维护（占50%，完善一些新的功能与性能要求）、适应性维护（适应外部新的硬件和软件环境的更新）、预防性维护

3）软件维护申请报告
4）维护流程

2.软件的管理
1）软件
2）软件配置管理