【软件工程】知识点总结（下）

目录

 第六章：结构化开发方法

6.1结构化分析方法概述

6.2 数据流图

6.3 数据字典

6.4 E-R图

6.5 状态转换图

6.6 结构化设计目标和任务

6.7结构化设计的概念和原理

6.8面向数据流的设计方法

6.9 详细设计（过程设计）

6.10概要设计

第七章：面向对象开发方法

7.1 概要

7.2需求模型——用例图

7.3静态建模——类图和对象图

7.4动态建模——状态图、顺序图、通讯图、

7.5物理建模——组件图、部署图

第八章：软件测试

---

 第六章：结构化开发方法

【掌握结构化分析的概念；掌握数据流图和数据字典；掌握ER图；掌握状态图】

6.1结构化分析方法概述

【掌握结构化分析的概念；掌握和理解数据流图、数据字典、ER图、状态图】

1、结构化分析方法概述：
（1）一种考虑数据和处理的需求分析方法被称为结构化分析（SA）方法，又称面向数据流需求分析方法，20世纪70年代E.Yourdon提出，应用广泛。

（2）
1）功能模型： 数据流图（DFD）表达。

描绘数据在软件中移动、变换及相应功能
模型核心是数据字典。描述软件使用和产生的所有数据对象

2）数据模型：ER图表达
描述数据对象间关系

3）行为模型：状态转换图
描绘系统状态和在不同状态间转换方式

6.2 数据流图

6.3 数据字典

 1、数据字典概念：是关于数据信息的集合，也就是对数据流图中所包含元素的定义的集合。

2、数据字典包括4类条目：

（1）数据流

（2）数据项（数据流分量，数据基本项）

（3）数据存储（文件）

（4）数据加工（处理）

3、数据字典定义方法

数据字典中还应该包含关于数据的一些其他信息。典型的情况是，在数据字典中记录数据元素的下列信息：

（1）一般信息（名字，别名，描述等等）；

（2）定义（数据类型，长度，数据结构）；

（3）使用特点（值的范围，使用频率）；

（4）使用方式一一输入、输出、条件值等等）；

4、数据字典-数据流的描述

（1）格式

数据流名：

说明：简要介绍作用即它产生的原因和结果。

数据流来源：即该数据流来自何方。

数据流去向：去向何处。

数据流组成：数据结构。

（2）例子：

数据流名：发票

说明：用作学生已付书款的依据

数据流来源：来自处理“审查并开发票”

数据流去向：流向处理“开领书单”。

数据流组成：学号+姓名+书号+单价总价+书费合计

5、数据字典-数据项（元素）的描述

（1）格式

数据元素名（数据项名）：

类型：数字（离散值、连续值），文字（编码类型）

长度：

取值范围：

相关的数据元素及数据结构：

（2）例子

数据元素名：学号

类型：数字 （离散），1、2位表示分院、3、4位表示专业、5、6位表示年级 7、8位表示班级、9、10位表示序号

长度：10位

取值范围：0000000000~9999999999

相关的数据元素及数据结构：购书单、发票、领书单

6、数据子典-数据存储的描述

（1）格式

数据存储名：

简述：存放的是什么数据。

输入数据：

输出数据：

数据文件组成：数据结构。

存储方式：顺序，直接，关键码。

（2）例子

数据存储名：各班学生用书表

简述：各班学生用书信息

输入（输出）数据：各班学生用书信息

数据文件组成：班级编号+书号+用量

存储方式：按班级编号从小到大排列

7、数据字典-数据处理的描述

（1）格式

处理名：

处理编号：反映该处理的层次

简要描述：加工逻辑及功能简述

输入数据流：

输出数据流：

加工处理逻辑：处理频率

（2）例子

处理逻辑编号：P03-01；

处理逻辑名称：验收订货单

简述：确定用户的订货单是否填写正确

输入的数据流：订货单

输出的数据流：合格的订货单，

处理频率：50次/天

6.4 E-R图

6.5 状态转换图

1、状态转换图(Status Transfer Diagram, STD)是一种描述系统对内部或者外部事件响应的行为模型。描述系统状态和事件，事件引发系统在状态间的转换，而不是描述系统中数据的流动。适用于描述实时系统。

2、状态转换图的组成

（1）状态：代表系统的一种行为模式，状态规定了系统对事件的响应方式。有初态（即初始状态） 、终态（即最终状态）和中间状态。

单程生命周期：有初始与终点状态

循环运动过程：一般不考虑初始状态与最终状态

（2）事件：在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象，用箭头上的标记表示。

3、状态图中使用的主要符号

（1）状态变量：是状态所显示类的属性。

（2）活动：列出该状态时要执行的时间和动作。

①entry事件：用于指明进入状态时的特定动作

②exit事件：用于指明退出状态时的特定动作

③do事件：用于指明在该状态时执行的动作

4、其他图形：

层次方框图：层次方框图用来描述数据的层次结构

6.6 结构化设计目标和任务

1、软件设计阶段做什么

问题定义-“要解决什么问题”

可行性分析“能不能实现”

软件需求分析-“系统需要实现什么功能”

软件设计“怎么实现”

2、软件设计任务

软件设计可分为：

概要设计：体系结构设计、数据设计和接口设计

详细设计：过程设计。

3、软件设计的意义和目标

（1）软件设计在软件开发过程中处于核心地位，它是保证质量的关键步骤。

设计为我们提供了可以用于质量评估的软件表示，

设计是我们能够将用户需求准确地转化为软件产品或系统的唯一方法

软件设计是所有软件工程活动和随后的软件支持活动的基础。

（2）软件设计是一个迭代的过程，通过设计过程，需求被变换为用于构建软件的“蓝图”。McGlaughlin提出了可以指导评价良好设计演化的3个特征：

1)设计必须实现所有包含在分析模型中的明确需求，而且必须满足用户期望的所有隐含需求。

2)对于程序员、测试人员和维护人员而言，设计必须是可读的、可理解的指南。

3)设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域以上每一个特征实际上都是设计过程应该达到的目标。

6.7结构化设计的概念和原理

1、软件设计的概念与原理-抽象和逐步求精

（1）抽象：抽出事物的本质特性，暂不考虑细节。

（2）逐步求精：为了能集中精力解决主要问题，尽量推迟对细节问题的考虑。

1）实际上是一个细化过程，与抽象是互补的概念。

2）抽象使得设计者能够说明过程和数据，同时却忽略底层细节；求精帮助设计者在设计过程中揭示底层细节。软件设计的概念与原理-模块化

2、模块化

（1）把软件按照规定的原则，划分为一个个较小的，相互独立的但有相互关联的部件。

（2）为什么要模块化?

1)模块化是为了使一个复杂的大型程序能被人的智力所管理；

2)如果一个大型程序仅由一个模块组成，它将很难被人所理解

（3）模块化的作用：

采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解；

模块化使软件容易测试和调试，因而有助于提高软件的可靠性；

模块化能够提高软件的可修改性；

模块化也有助于软件开发工程的组织管理。

（4）模块是数据说明、可执行语句等程序对象的集合。面向过程设计方法中过程、函数、子程序、宏都可以作为模块，面向对象设计中，对象是模块、

对象中的方法是模块。

如：过程、函数、子程序、类、构件等。

3、软件设计的概念与原理-模块独立

（1）

C(P1+P2)>C(P1)+C(P2)——》C(P1)>C(P11)+C(P12)

E(P1+P2)>E(P1)+E(P2)——》E(P1)>E(P11)>E(P12)

（2）好处

1）容易分工合作

2）容易测试和维护

（3）两个定性度量标准： 耦合和内聚。

4、模块独立-耦合性

（1）定义：不同模块之间相互依赖程度的度量

（2）耦合的等级划分

（3）非直接耦合

（4）

1）数据耦合：两个模块传递参数时如果只是数据值，而不是结构数据

模块A：完成两个数的输入。

模块B：完成两个数的比较，求出最大并返回。

2）标记耦合：使用一个复杂的数据结构从一个模块向另一个模块传送参数，并且传送的是引用类型，如高级语言的数组名、记录名、文件名等这些名字即为标记，其实传递的是这个数据结构的地址。

模块A ：学生信息查询

模块B：选课查询

模块C：成绩查询

数据结构：学号+院系+ 课程

3）控制耦合(control coupling)：指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等)，被调模块通过该控制变量的值有选择地执行块内某一功能。这种耦合对系统的影响较大，它影响接收控制流模块的内部运行。这种模块严格说不是“黑箱”模块，不利于模块的修改与维护。虽然控制联结的耦合度高于数据耦合，但这种联结有时是必要的。特别对某些反映状态标志的控制信息传递是必须的。控制信息不同于数据信息，是控制处理过程的一些参数。

4）公共环境耦合

公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合。

公共数据环境可以是全程变量或数据结构共享的通信，内存的公共覆盖区及任何存储介质上的文件，物理设备等（也有将共享外部设备分类为外部耦合）。

5）内容耦合

•一个模块修改了另一个模块的内部数据项

•一个模块内的分支转移到另一个模块中

•两个模块代码重叠（汇编语言）

•一个模块有多个入口

6）降低耦合

软件设计时，开发人员应该使用数据耦合，较少使用控制耦合， 限制公共耦合的使用，坚决避免使用内容耦合。

降低耦合的举措：

①采用简单的数据传递。

②尽量使用整型等基本数据类型作为接口参数的数据类型。

③限制接口参数的个数。

5、模块独立-内聚

（1）定义：模块内各元素彼此结合紧密程度。

（2）高内聚

1）功能内聚：模块内所有元素共同完成一个功能，缺一不可，因此模块不能再分割。

2）顺序内聚：如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

（3）中内聚

1）通信内聚：如果一个模块的所有成分都操作同一数据集或生成同一数据集

2）过程内聚：按次序执行功能，构件或者操作的组合方式时，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。

（4）低内聚

1）时间内聚：和时间有关的功能，如果一个模块完成的功能必须在同一时间内执行（如系统初始时间 T+t化），但这些功能只是因为时间因素关联在一起，则称为时间内聚。

2）逻辑内聚：几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。相似的功能，如一个模块读取各种不同类型外设的输入。

3）偶然内聚：如果一个模块的各成分之间毫无关系，则称为偶然内聚。

6、体系结构

（1）体系结构设计：确定每个程序由哪些模块组成，确定每个模块的功能，及模块和模块之间的接口，调用关系等，所有的这些都不涉及具体的模块内部实现过程。

（2）体系结构设计图形工具-层次图

1）在层次图(hierarchy Chart)中一个矩形框代表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块）。

2）注意区别于层次方框图

3）注意区别于功能模块图

（3）体系结构设计图形工具-HIPO图

1）HIPO 图(Hierarchy plus Input-Process-Output, HIPO) 是美国 IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了使HIPO图具有可追

踪性，在H图（即层次图）里除了顶层的方框之外，每个方框都加了编号。

2）和H图中的每个方框相对应，应该有一张IPO图描绘这个方框代表的模块的处理过程。

7、软件结构图

（1）软件结构图是软件系统的模块层次结构，用来表达软件的组成模块及其调用关系。由Yourdon等人提出。

（2）基本符号：

方框：代表一个模块；

方框之间的直线：表示模块的调用关系。

箭头表示模块调用过程中来回传递的信息

（3）软件结构图示例

（4）软件结构图附加符号

循环调用：模块A循环调用模块B、C、D；

选择调用：判定为真时调用模块T1，为假时调用模块T2。

8、结构化方法中体系结构设计以需求分析阶段得到的数据流图为依据来设计软件的结构

6.8面向数据流的设计方法

1、面向数据流设计方法

面向数据流的设计要解决的任务，就是将软件需求分析阶段生成的逻辑模型数据流图映射(Mapping)表达软件系统结构的软件结构图。

2、数据流图的类型

（1）变换型数据流图是指把输入的数据处理后转变成另外的输出数据。信息沿输入路径流入系统，在系统中经过加工处理后又离开系统，当信息流具备这种特征时就是变换流。

（2）事务型数据流图，是指非数据变换的处理，它将输入的数据流分散成许多数据流，形成若干个加工，然后选择其中一个路径来执行。

（3）数据流图类型举例

1）变换型数据流

2）事务型数据流

（4）交换流案例分析

1）案例：

将具有交换流特点的数据流图映射成软件结构

例如：开发一个带有微处理器的汽车数字仪表板控制系统，汽车仪表板将完成下述功能：

2）变换流设计步骤

第1步 复查基本系统模型。

第2步 复查并精化数据流图。

第3步 确定数据流图的类型。

输入有两条通路进入系统，然后沿着5条通路离开，没有明显的事务中心。因此它属于变换型结构的数据流图。

第四步 确定输入、变换和输出边界。

输入流、输出流的边界的确定具有一定的任意性，因为不同的人对系统的理解不同。

3）变换型分析设计

1.确定逻辑输入和逻辑输出的边界，找出变换中心

2.设计软件结构的顶层和第一层

位于软件结构最顶层的主模块协调下述从属的控制

功能:

输入模块：协调对所有输入数据的接受；

变换中心：管理对内部形式的数据的所有操作；

输出模块：协调输出信息的产生过程。

完成一级分解

上层的模块结构有两层，顶层是系统模块，第一层由输入模块、变换模块和输出模块三个模块组成。

数字仪表板系统的第一级分解

完成二级分解

输入部分下层模块的设计，从变换中心的输入流边界开始沿着输入通路向外移动，把输入通路中每个处理映射成软件结构中输入模块控制下的一个低层模块。

输出部分的下层模块设计从变换中心输出流边界开始然后沿输出通路向外移动，把输出通路中每个处理映射成系统结构中输出模块控制的一个低层模块；

二级分解-变换结构

变换部分的映射是把变换中心内的每个处理，映射成系统结构中变换模块控制下的若干个模块。

精化模块结构

在二级分解后，得到系统的初步结构图，根据模块独立性原理和启发规则进行精化，通过分析对本例中的一些模块做如下修改：

在输入结构中，模块“转换成rpm”和“收集sps”可以合并；

在变换结构中，模块“确定加速/减速”可以放在模块“计算mph”下面，以减少耦合；

在输出结构中，模块“加速/减速显示”可以相应地放在模块“显示mph”的下面

数据流图类型-事务流

在事务型数据流图，数据项沿着输入同路到达一个处理T，T根据输入。数据的类型在若干动作序列中选出一个来执行。处理T称为事务中心。

6.9 详细设计（过程设计）

1、过程设计概念

确定模块算法

确定模块使用数据结构

确定模块接口 （系统外部接口、用户界面、内部模块间接口细节、输入数据和输出数据)

2、过程设计工具

3、程序流程图符号

（1）顺序结构

（2）选择型：

由某个判定的取值决定选择两个加工中一个。

（3）当型循环型

当循环控制条件成立时，重复执行特定的加工。

（4）直到型循环型：重复执行特定的加工，直到循环控制条件成立时。

（5）多情况选择型：列出多种加工情况根据控制变量的取值，选择执行其一

（6）程序流程图标准化图符

（7）计算n阶乘的程序流程图

4、N-S图（盒图）

（1）常见

（2）计算n阶乘的N-S图

5、PAD图

（1）常见

（2）计算n阶乘的PAD图

（3）PAD特点分析

1）表示的程序结构的执行顺序是自最左边的竖线的上端开始，自上而下，自左向右。

2）表示的程序片断结构清晰，层次分明。

3）支持自顶向下、逐步求精的设计方法。

4）只能用于结构化的程序设计。

5）不仅可以表示程序逻辑，还能表示数据结构。

6、过程设计语言

（1）过程设计语言PDL(Procedure DesignLanguage)也称为结构英语或伪码，是所有正文形式的过程设计工具的统称。

（2） PDL经常表现为一种“混杂”的形式，允许自然语言（如英语）的词汇与某种结构化程序设计语言（如Pascal、C、Ada等)的语法结构交织在一起。

（3）伪码语法规则

在伪代码中，每一条指令占一行(else if 例外，)，指令后不跟任何符号

书写上的“缩进”表示程序中的分支程序结构。同一模块的语句有相同

的缩进量，次一级模块的语句相对与其父级模块的语句缩进；

符号△后的内容表示注释；

在伪代码中变量不需要声明；

变量名和关键字不区分大小写

赋值语句用符号一表示，x-exp表示将exp的值赋给x，其中×是一个

变量，exp 是一个与×同类型的变量或表达式（该表达式的结果与χ同

类型)；

顺序

选择

循环

（4）计算n的阶乘的伪代码

7、PLD优缺点

优点：PDL不仅可以作为设计工具，而且可作为注释工具，直接插在源程序中间，以保持文档和程序的一致性，提高了文档的质量。

缺点：

1. 不如图形工具那样形象直观.

2.当描述复杂的条件组合与动作间的对应关系时，不如判定表和判定树那样清晰简单。

6.10概要设计

1、数据库设计

（1）数据库结构设计包括概念结构设计、逻辑结构设计和物理结构设计

（2）数据库的概念结构设计是设计数据库的概念模型，普遍采用实体-关系图(ER图)的方法。

2、逻辑结构设计

（1）实体的映射：一个实体可以映射为一个表或多个表

关系的映射：1：1的关系映射

班级（班级编号，院系，专业，人数，正班长学号）

（2）关系的映射：1:N的关系映射

班级（班级编号，院系，专业，人数）

学生（学号，姓名，年龄，性别，班级编号）

（3）关系的映射：M:N的关系映射

学生（学号，姓名，专业，班级，性别，出生日期）

课程（课程编号，课程名称，课程类别，学分）

选课（学号，课程编号，成绩）

3、物理结构设计

4、接口设计主要包括三个方面：

（1）人机界面的交互设计

（2）软件与其它软硬件系统之间的接口设计

（3）模块或软件构件间的接口设计

5、总体设计说明书主要包括以下内容。

（1）引言：编写目的、项目背景、定义、参考资料：

（2）任务概述：目标、运行环境、需求概述、条件与限制；

（3）总体设计： 处理流程、总体结构和模块外部设计（给出软件系统的结构图）、功能分配（表明各项功能与程序的关系）

（4）接口设计：外部接口（用户界面、软件与硬件接口）、内部接口（模块之间的接口）；

（5）数据结构设计：逻辑结构设计、物理结构设计、数据结构与程序的关系；

（6）运行设计：运行模块的组合、运行控制、运行时间：

（7）出错处理设计：出错输出信息、出错处理对策（如设置后备、性能降级、恢复及再启动等）；

（8）安全保密设计

（9）维护设计：说明为方便维护工作的设施，如维护模块等。

---

---

---

---

---

---

---

---

---

---

第七章：面向对象开发方法

7.1 概要

1、结构化VS面向对象

（1）结构化：自顶向下，逐步细分；

（2）面向对象：以对象为基础，以消息（或事件）来驱动对象执行处理

2、面向对象技术基础概念

（1）面向对象技术是一系列指导软件构造的原则（如抽象、封装、多态等），并通过语言、数据库和其它工具来支持这些原则。

从本质上讲，对象技术对一系列相关原则的应用

面向对象技术=类+对象+抽象+封装+继承+多态+消息…

（2）类和对象

1）

2）类和对象的构成

（3）消息与事件

1）所谓消息(Message)是指描述事件发生的信息，是对象间相互联系和相互作用的方式。

2）一个消息主要由5部分组成：消息的发送对象、消息的接收对象、消息传递方式、消息内容（参数）、消息的返回。传入的消息内容的目的有两个，一个是让接受请求的对象获取执行任务的相关信息，另一个是行为指令。

（4）面向对象概念-封装

封装(Encapsulation)是把对象的属性(状态)和操作（行为）绑到一起的机制，把对象形成一个独立的整体，并且尽可能的隐藏对象的内部细节。

（5）面向对象概念-继承

继承(Inheritance)是一种连接类与类的之间的层次模型。继承是指特殊类的对象拥有其一般类的属性和行为

（6）面向对象概念——多态

对于相同的消息，让各个对象产生不同的行为面向对象的软件工程方法

3、面向对象的软件工程方法

（1）贯穿软件生存周期全过程的一致性从OOA开始使用现实世界的概念、词汇、原则及表示法，这种一致性保持到设计、编程、测试、维护等各个阶段。

（2）

4、面向对象方法学的发展

（1）在软件工程领域，面向对象的发展历史大致可以划分为3 个阶段：

1)初期阶段(20 世纪60年代开始)：由挪威计算中心和奥斯陆大学共同研制Simula 语言

2)发展阶段(20世纪80年代)：以面向对象程序设计语言C++为代表；

3)成熟阶段(20 世纪80年代末)：OOP-> 面向对象方法( Booch,Coad/Yourdon， OMT, OOSE);

（2）面向对象方法发展

1）Booch方法

Booch 方法把系统的开发工作分为“微观过程”和“宏观过程”两个部分。

Booch 方法所采用的对象模型要素包括封装、模块化、层次类型、并发等，其重要的概念模型是类和对象、类和对象的特征、类和对象之间的关系。使用的图形文档包括6种：类图、对象图、状态转换图、交互图、模块图和进程图。

2）Coad-Yourdon 方法(OOAD)

Coad 方法主要由面向对象分析OOA和面向对象设计OOD构成，强调OOA和OOD 采用完全一致的概念和表示法，使分析和设计之间不需要表示法的转换

3）Jacobson 方法(OOSE)

面向对象软件工程(Object Oriented Software Engineering, OOSE) 方法是 lvar Jacobson在1992年提出的一种用例驱动的面向对象开发方法，也称为Jacobson 方法。OOSE 开发过程中会建立以下5种模型，这些模型是自然过渡和紧密耦合的。

(1)需求模型，包括由领域对象模型和界面描述支持的参与者和用例。

(2)分析模型，主要目的是要建立在系统生命期中可维护、有逻辑性、健壮的结构，包括3种对象，界面对象刻画系统界面；实体对象刻画系统要长期管理的信息和信息上的行为；按特定的用例做面向事务的建模的对象，这3种对象使得需求的改变总是局限于其中一种。

(3)设计模型，进一步精化分析模型并考虑当前的实现环境。

(4)实现模型，主要包括实现块的代码。

(5)测试模型，包括不同程度的保证，这种保证从低层的单元测试延伸到高层的系统测试。

4）Rumbaugh 方法(OMT)Booch 方法

对象模型化技术OMT(Object Modeling Technique)最早是由 Loomis 、Shan 和Rumbaugh在1987 年提出的，曾扩展应用于关系数据库设计。Jim Rumbaugh 在1991年正式把OMT 应用于面向对象的分析和设计。

该方法是在实体关系模型上扩展了类、继承和行为而得到的，开发工作的基础是对真实世界的对象建模，然后围绕这些对象使用分析模型来进行独立于语言的设计。

（3）各种面向对象方法的比较

1）Booch 方法并不是一个开发过程，只是在开发面向对象系统时应遵循的一些技术和原则。Booch方法是从外部开始，逐步求精每个类，直到系统被实现。因此，它是一种分治法，支持循环开发，它的缺点在于不能有效地找出每个对象和类的操作。

2）在 OOAD 方法中，OOA 把系统横向划分为5个层次，OOD 把系统纵向划分为4个部分，从而形成一个清晰的系统模型。OOAD适用于小型系统的开发。

3）OMT 方法覆盖了应用开发的全过程，是一种比较成熟的方法，用几种不同的观念来适应不同的建模场合，它在许多重要观念上受到关系数据库设计的影响，适用于数据密集型的信息系统的开发，是一种比较完善和有效的分析与设计方法。

4）OOSE 能够较好地描述系统的需求，是一种实用的面向对象的系统开发方法，适用于商务处理方面的应用开发。

5、UML

（1）

（2）UML 诞生记

1995年，Grady Booch、James Rumbaugh和lvarJ acobson在Rational公司创立UML 。

1997年11月，在Ivar Jacoboson、Grady Booch 以及James Rumbaugh的共同努力下，UML1.1版本提交给OMG （对象管理组织）并获得通过，UML1.1成为业界标准的建模语言。

1998年秋季，UML1.3版本发布。

2003年6月，OMG技术会议上 UML 2.0获得正式通过

（3）统一建模语言(UML)(Unified Modeling Language)

★ 统一的含义

★ 建模：可视化—一图形表示法，以图形化的方法构建系统分析与软件设计模型

★ 语言

UML是一种标准的图形化建模语言，是面向对象分析与设计的标准表示，它：

①不是一种程序设计语言，而是一种可视化的建模语言（用于分析设计）；

②不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种模型表示的标准；

③不是过程，也不是方法，但允许任何一种过程和方法使用它；

（4）很多情况下，推荐使用UML：

1）OO方法是项目决定采用的方法论，是整个项目或产品成功的关键

2）开发人员感觉用源码说明不了真正的问题，希望提高交流效率

3）系统的规模和设计都比较复杂，需要用图形抽象地表达复杂概念，降低开发风险

4）组织希望记录已成功项目、产品的设计方案，在开发新项目时可以参考、复用过去的设计

5）有必要采用一套通用的图形语言和符号体系描述组织的业务流程和软件需求，促进业务人员、开发人员之间一致、高效的交流

（5）UML体系结构——图

1）UML元素-用例图

主要使用场合：需求获取、定义、分析

用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系，以及系统内用例之间的关系。

2）UML元素-类图

类图显示了系统的静态结构，表示了不同的实体（人、事物和数据）是如何彼此相关联起来。类图可用于表示逻辑类，逻辑类通常就是用户的业务所谈及的事物，比如说学生、学校等。类图还可用于表示实现类，实现类就是程序员处理的实体。

3）UML元素-对象图

4）UML元素 - 顺序图

顺度图是了一个具体用例或者用例的一部分的一个详细流程。

5）UML元素-状态图

状态图表示某个类所处的不同状态及该类在这些状态中的转换过程

6）UML元素-活动图

活动图是用来表示两个或者更多的对象之间在处理某个活动时的过程控制流程。

7）UML元素-部署图

部署图是用于表示该软件系统如何部署到硬件环境中，它是显示在系统中的不同的构件在何处物理地运行，以及如何进行彼此的通信。

部署图对系统的物理运行情况进行了建模，因此系统的生产人员就能够很好地利用这种图来部署实际的系统

（6）UML体系结构——架构

UML 是用模型来描述系统的结构或静态特征以及行为或动态特征的，从不同的视角为系统的架构建模形成系统的不同视图(view)。

视图是表达系统某一方面特征的UML建模构件的子集。

UML 语言中的视图大致分为如下5种：

（1）用例视图：用例视图强调从系统的外部参与者（主要是用户）的角度看

到的或需要的系统功能。

作用：描述系统的功能需求，找出用例和执行者；

适用对象：客户、分析者、设计者、开发者和测试者；

描述使用的图：用例图和活动图：

重要性：系统的中心，它决定了其他视图的开发，用于确认和最终验证系统。

（2）逻辑视图：逻辑视图从系统的静态结构和动态行为角度显示如何实现系

统的功能。

逻辑视图

作用：描述如何实现系统内部的功能；

适用对象：分析者、设计者、开发者；

描述使用的图：类图和对象图、状态图、顺序图、协作图和活动图；

重要性：描述了系统的静态结构和因发送消息而出现的动态协作关系 。

（3）组件视图：组件视图显示代码组件的组织结构。

构件视图

作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系；

适用对象：设计者、开发者；

描述使用的图：构件图，包图：

重要性：描述系统如何划分软件构件，如何进行编程 。

（4）进程视图：并发视图显示系统的并发性，解决在并发系统中存在的通信和同步问题。

作用：描述系统的并发性，并处理这些线程间的通信和同步

适用对象：开发者和系统集成者；

描述使用的图：状态图、顺序图、协作图、活动图、构件图和配置图；

重要性：将系统分割成并发执行的控制线程及处理这些线程的通信和同步 。

（5）部署视图：配置视图显示系统的具体部署。部署是指将系统配置到由计算机和设备组成的物理结构上。

作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接；

适用对象：开发者、系统集成者和测试者；

描述使用的图：部署图；

重要性：描述硬件设备的连接和哪个程序或对象驻留在哪台计算机上执行 。

（7）UML体系结构-事物

事物是对模型中最具有代表性的成分的抽象

（1）结构事物： UML 中的名词，它是模型的静态部分，描述概念或物理元素。

类(class)和对象(object)

 接口(interface)

主动类(active class)

用例(use case)

协作(collaboration)

构件(component)

节点(node)

（2）行为事物：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。

1）交互(interaction)：是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合

2）交互的表示法很简单，就是一条有向直线，并在上面标有操作名

3）状态机(state machine)：是一个对象或交互在生命周期内响应事件所经历的状态序列

4）在UML模型中将状态画为一个圆角矩形，并在矩形内写出状态名称及其子状态

（3）分组事物： UML 中的容器，用来组织模型，使模型更加的结构化。

对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。在UML中，提供了“包(Package)”来完成这一目标

（4）注释事务： UML 中的解释部分，和代码中的注释语句一样，是用来描述模型的。

结构事物是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分关系

（8）UML体系结构-关系

1）UML 模型是由各种事物以及这些事物之间的各种关系构成的。关系是指支配、协调各种模型元素存在并相互使用的规则。

2）UML 中主要包含四种关系，分别是依赖、关联、泛化和实现。

依赖关系：依赖关系指的是两个事物之间的一种语义关系，当其中一个事物（独立事物）发生变化就会影响另外一个事物（依赖事物）的语义

关联关系：关联关系是一种事物之间的结构关系，我们用它来描述一组链，链是对象之间的连接。

泛化关系：泛化关系是事物之间的一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象，也就是我们在面向对象学中常常提起的继承。

实现关系：实现关系也是 UML 元素之间的一种语义关系，它描述了一组操作的规约和一组对操作的具体实现之间的语义关系。

（9）UML 建模工具

Rational Rose

Microsoft Visio

Startuml

Powerdesign

processon.cn

6、面向对象方法学习的目标

（1）三大目标：

OO：建立对象的思维方式，对面向对象思想和理论有进一步的理解

UML：能够熟练地使用UML表达面向对象的设计思想

Model：运用对象技术的一般原则和模式进行应用系统的分析和设计建模

（2）三大目标之间的关系

Model：建模是最终目的

OO：面向对象技术是一种建模理论

UML：统一建模语言是一种体现OO的建模语言，是将OO理论转化为实践的工具

7.2需求模型——用例图

1、用例建模流程

（1）获取原始需求

（2）开发一个用户可以理解的需求

1）识别参与者

2） 识别用例

3） 绘制用例图

（3）详细、完整地描述需求

编写用例文档

（4）重构用例模型

1）识别用例间的关系

2） 对用例进行分包和分级用例文档

2、参与者（执行者）——Actor

（1）参与者定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物（任何事物：人、外系统、硬件设备、定时器等）

（2）参与者的图形表示

参与者是人，用“小人图”

参与者是某个系统时用方框图

参与者命名：名词

（3）参与者（执行者）

1)参与者位于系统边界之外，而不是系统的一部分。

2)参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。

3)一个现实中的对象可以根据对系统的不同目的抽象成多个参与者，多个现实中的对象也可以按照对系统的相同目的而抽象为一个参与者（抽象）。

4)参与者可以认为是外部对象相对于系统而言所扮演的角色的抽象。

（4）参识别参与者

通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。确定参与者可以从以下几个角度来考虑：

①为系统提供输入的人或事物

②接收系统输出的人或事物

③需要接入的第三方系统或设备

④时间是否会触发某些事件

⑤负责支持或维护系统中信息的人

①②③④⑤⑥⑦⑧⑨⑩

（5）参与者之间的关系

1）泛化

多个参与者之间可以具有与类之间相同的关系。

在用例图中，可以使用泛化关系来描述多个参与者之间的公共行为。

3、用例

（1）定义：系统为响应参与者引发的一个事件，而执行的一系列的处理/动作，而这些处理应该为参与者产生一种有价值结果

（2）用例的表示：椭圆

用例命名：短小精悍的“动名词”

（3）用例的粒度

在业务建模阶段，用例的粒度以每个用例描述一个完整的事情为宜。

在概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。

在系统建模阶段，用例的粒度以一个用例能够描述参与者与计算机的一次完整交互为宜。

（4）用例与其参与者之间的关联

1）用例与参与者之间存在关联关系。关联关系表示参与者和用例之间的通信。

2）一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。

3）任何用例都不能在缺少参与者的情况下存在；任何参与者也必须要有与之关联的用例。

4）主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。

5）用例与其参与者之间的关联关系用带箭头的直线表示

（5）用例的特征

用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。

>用例是动宾短语

>用例是相对独立的

>用例是由参与者启动的

>用例要有可观测的执行结果

>一个用例是一个单元识别用例

（6）识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者。具体可以通过查找事件的方式来识别用例：

（7）绘制用例图误区

1）用例是一个完整的交互

2）用例之间没有顺序的关系

（8）用例和用例之间的关系

用例除了与其参与者发生关联外，用例之间具有多种关系，

1）用例之间的关系-泛化关系

在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

2）用例之间的关系-包含关系

描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<<include>>构造型来表示的。

3）用例之间的关系-扩展关系

扩展用例可以在基用例之上添加新的行为

扩展关系是通过在依赖关系上应用<<extend>>来表示取钱

4）包含关系与扩展关系对比

4、用例图替代数据流图

5、用例文档

（1）定义：描述用例以及与外界交互的规格说明书

（2）一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。用例图是骨架，而用例文档则是其内在的肉

（3）用例文档的组成

用例名、简要描述

参与者涉众

相关用例

前置条件、后置条件

事件流【基本路径、扩展路径】

补充约束【字段列表、业务规则；非功能需求、设计约束】

相关图【活动图、顺序图】

（4）前置条件

1）前置条件：开始使用用例前必须满足的条件，非必需

前置条件约束在用例开始前系统的状态

作为用例的入口限制，它阻止参与者触发该用例，直到满足所有条件

说明在用例触发之前什么必须为真

前置条件要点

必须是系统能检测到的

前置条件必须是系统在用例开始前能检测到的

2）后置条件：用例一旦执行后系统所处的状态

后置条件约束用例执行后系统的状态

用例执行后什么必须为真

对于存在各种分支事件流的用例，则可以指定多个后置条件

（5）事件流

1）事件流是对用例在使用场景下的交互动作的抽象，应该包括用例何时以及怎样开始和结束，用例何时与参与者交互，该行为的基本流（基本事件流）和可选择的流（扩展事件流）。

2）基本事件流：用例的正常流程。必需

用例的主路径、愉快路径(Happy Path)

通常用来描述一个理想世界，即没有任何错误发生的情况

复杂的基本流可以分解成多个子流

基本事件流要点

基本路径：只书写“可观测”的

句子必须以参与者或系统作为主语

不要涉及界面细节

3）扩展事件流：其他异常情况

基本事件流中的分支或异常情况

注意如何与基本流衔接

4）主事件流分支和循环的描述

分支：放到扩展事件流中

循环：直接描述

（6）补充约束

1）用例重点在于描述功能需求，也可以描述其它方面的补充

约束：

与特定用例相关的补充约束，作为该用例文档中一部分来描述

一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档

2）补充约束——数据需求

数据需求：描述与用例相关的数据需求

3）补充约束：业务规则

描述业务逻辑和操作规则

>事实：设备是资产的一种!

>推理：如果过了计划中的交互日期，货物还没有送到，即为“未按时送货”

>约束：合同总金额不能超出买方的信用额度

>表达业务规则

>文字说明

>决策表

4）补充约束：非功能需求

①一开始，功能需求决胜；类似产品多了，非功能需求决胜

②四类非功能需求：

性能

质量

对外接口

约束

5）补充约束：设计约束

（7）用例文档实例

7.3静态建模——类图和对象图

1、面向对象的分析概要

(Object-orientedanalysis ，OOA）

（1）OOA的基本任务：

运用面向对象方法，对问题域（被开发系统的应用领域）和系统责任（所开发系统应具备的职能）进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域和系统责任所需的类和对象，定义这些类和对象的属性和操作，以及它们之间所形成的各种关系·最终目的是产生一个符合用户需求，并能够直接反映问题域和系统责任的OOA模型及其规约

（2）OOA模型

（3）OOA 过程

2、类图基础知识

（1）类图表示

 类图（逻辑类、实现类）的建模贯穿系统的分析和设计阶段的始终

类图中只有类名是必须的，其余部分可以省略

（2）类图之间的关系

1）泛化关系

①泛化关系也就是继承关系，泛化关系描述了超类与子类之间的关系，超类又叫做基类。

②在UML中，泛化关系用带空心三角形的直线来表示。

2）依赖关系

①依赖关系是一种使用关系，即一个类(A)的实现需要用到另一个类(B)

②依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。

③尽量不要使用双向依赖

④依赖关系代码1：一般表现为类A中的方法需要类B的实例作为其参数或变量，但是类A本身并不需要引用类B的实例作为其成员变量。

使用虚线箭头表示，类A指向类B。

⑤依赖关系代码实现2

3）关联关系

①关联关系

关联是一种比依赖的关系更强，类A使用类B的实例作为自己本身的一个成员变量。

关联关系用实线箭头（单箭头表示单向关联，无箭头或双箭头表示双向关联）

关联有聚合关联和组合关联两种特例。

聚合关系指的是整体与部分的关系。在聚合关系中，类A是类B的一部分，但是类A可以独立存在，

是一种更强的关联关系，关联关系的特例。在UML中，聚合关系用带空心菱形的实线箭头表示。

4）实现关系

接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系，在这种关系中，类实现了接口，类中的操作实现了接口中所定义的操作。

在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。

3、对象图基础知识

（1）类图vs对象图

（2）对象图定义

对象是指某个事物，大多对应于真实世界中的某个客观实体，所有的对象都是有唯一标识的独立实体。对象之间的区别是由它们固有的存在性所决定的，任何对象都是某个类的实例。

对象图是类图在某一时刻的一个实例。

（3）对象图表示

在UML对象图中的对象表示为一个有两栏的矩形框。

>第一栏表示对象和类的名

> 第二栏表示对象的属性和值

（4）对象图和类图的区别

7.4动态建模——状态图、顺序图、通讯图、

0、动态建模概述

①UML动态建模对应于系统的行为视图，它用于对系统的行为随时间变化而进行的建模和描述

②系统中的对象能够相互通信，通信是通过调用这些对象的方法来实现的，把对象间的通信和传递信息的方式称为系统的动态特征。系统中对象的相互作用，可以理解为系统中动态实体之间的通信

③可以使用UML中的状态图、活动图、顺序图、通信图、定时图和交互概览图来表示

1、状态图

（1）状态图通过建立类对象随时间变化的动态行为。

（2）状态图用来描述一个特定对象的所有可能状态及其引起状态转移的事件。

（3）状态图组成元素

1）状态图——初始状态

每个状态图都应该有一个初始状态，此状态代表状态图的起始位置。

初始状态只能作为转换的源，而不能作为转换的目标。

起始状态用一个实心的圆表示。

2）状态图——终止状态

终止状态是模型元素的最后状态，是一个状态图的终止点。

终止状态只能作为转换的目标，而不能作为转换的源。

终止状态用一个含有实心圆的空心圆表示。

3）状态图——一般状态表示

一般状态：指在对象的生命周期中满足某些条件的状态

4）状态图——一般状态入口动作

入口动作表示进入某个状态所要执行的动作。

入口动作用“entry/要执行的动作”表达。

5）状态图——一般状态出口动作

出口动作表示退出某个状态所要执行的动作。

出口动作用“exit/要执行的动作”表达。

6）状态图——一般状态活动

活动：系统处于该状态时要发生的活动，

前面加上do和“/”。

活动发生时，对象状态不会发生改变

7）状态图——一般状态-发送事件

发送事件：在活动、进入和退出操作的动作中可以是对象内部发生的行为，也可能是向另外一个对象发送消息。

8）状态图-转换（迁移）

①转换指的是两个不同状态之间的一种关系，表明对象将在第一个状态中执行一定的动作，并且在满足某个特定条件下由某个事件触发进入第二个状态。

②转换用带箭头的直线表示，箭尾一端连接源状态，即转出的状态；箭头一端连接目标状态，即转入的状态。

③在箭线上可以标示与该转移有关的选项：事件、保护（警戒）条件和动作（结果列表）。

9）状态图-特殊转换类型

自身转换：是指那些源状态与目标状态是同一状态的转移。

自动转换：每个状态都可能有一个不由事件触发迁移，它是根据该状态内的动作完成而自动触发的。

10）状态图-判定

①判定用来表示一个事件依据不同的监护条件有不同的影响。

②在实际建模的过程中，如果遇到需要使用判定的情况，通常用监护条件来覆盖每种可能，使得一个事件的发生能保证触发一个转换。

③在UML中判定用空心菱形表示。

（4）状态图的组成要素

1）复合转移(Compound-Transition)：复合转移由简单转移组成，这些简单转移通过分支判定、分叉组成。

2）状态图主要由状态（始状态、终止状态、一般状态，组合状态）、转移（复合转移，判定）、事件、动作和活动5部分组成。

3）状态图-状态嵌套

①状态图中的状态有两种：简单状态和组合状态

②简单状态是指不包含其他状态的状态，简单状态可以具有内部转换、入口动作和退出动作等，但是没有子结构

③状态还可以包含嵌套状态图的状态，称为组合状态

4）状态图-状态

①简单状态：不包含其他状态的状态称为简单状态。

②复合状态：又称为组合状态，可以将若干状态组织在一起可以得到一个复合状态，包含在一个复合状态中的状态称为子状态。

5）状态图——并发状态

并发状态：指一个对象在同一时刻可以处在多种状态

2、活动图

（1）活动图VS状态图

①活动图是状态图的一种扩展形式。如果在一个状态图中的大多数状态是表示操作的活动，而转移是自动转移，就演化为活动图。

②状态图是描述某一对象的状态和状态的转移。

③活动图可以描述系统在执行某一用例时的具体步骤，描述的是整个系统的

（2）活动图概述

1）活动图(Activity Diagram)是UML的动态建模机制之一，用来表

达系统动态特性的图。

2）活动图是描述一系列具体动态过程的执行逻辑，展现活动和活动之间的转移的控制流，并且它采用一种着重逻辑过程的方式来描述。

3）但事实上是在流程图的基础上添加了大量软件工程术语而形成的改进版。

4）表达能力包括逻辑判断、分支甚至并发，所以活动图的表达能力要远高于流程图。

5）活动图的主要作用就是用来描述工作流，使用活动图能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同来满足前面使用用例图建模的商务需求。

（3）活动图概念

1）活动图描述活动的顺序，展现从一个活动到另一个活动的控制流。

2）活动图描述活动的序列，并且支持带条件的行为和并发行为的表达。

3）活动图可以描述系统在执行某一用例时的具体步骤，也描述的是整个系统的活动。

（4）活动图案例

UML中，活动图中的活动既可以是手动执行的任务，也可以是自动执行的任务，用圆角矩形表示。

（5）活动图组成元素

1）活动图组成元素-活动

①起始活动表示活动图工作流程的开始，用实心圆饼来表示，在一个活动图中，只有一个起始活动。

②终止活动表示了一个活动图的最后和终结，一个活动图中可以有0个或多个终止活动，终止活动用实心圆点外加一个小圆圈来表示。

③活动用一个圆角矩形表示，活动是指一组动作，它是实现操作的一个步骤

2）活动图组成元素-转移

活动之间的转移用箭头来表示，用带有箭头的实线表示。

箭头上可能还带有守护条件

守护条件用来约束转移，守护条件为真时转移才可以开始

3）活动图组成元素-判断节点

①判断节点是活动图中进行逻辑判断、并创造分支的一种方法。

②判断节点具有一个进入控制流和至少两个导出控制流。

③判断节点具有多个导出流，对于每条导出流而言，应当在表示该控制流的箭头上附加控制条件。

4）活动图组成元素-合并节点

①合并节点将多个控制流进行合并，并统一导出到同一个离开控制流。

②合并节点仅有逻辑意义而没有时间和数据上的意义：几个动作都指向同一个合并节点也并不意味着这些动作要在进入之后互相等待或进行同步数据之类的操作。

5）活动图组成元素-判定

用菱形符号来表示判定，判定符号可以有一个或多个进入转移，两个或更多的带有守护条件的发出转移。

6）活动图组成元素-同步条

分叉：将一个活动转移分解成两个或多个活动，从而导致并发的动作。

汇合：用于将两个或多个活动通过转移形成一个活动，符号与分叉相同。

7）活动图组成元素-泳道

①泳道用于分割活动图，有助于更好地理解执行活动的场所。泳道划分负责活动的对象，明确地表示哪些活动是由哪些对象进行的，每个活动只能明确地属于一个泳道。

②在活动图中，泳道一般用垂直实线绘出，垂直线分隔的区域就是泳道。

8）活动图组成元素-对象流

对象流是UML为填补活动图与面向对象思想之间的疏离而出现的。如果需要在活动图中表现对象流，则首先需要绘制出泳道，且对象应该作为泳道的负责对象出现。

9）活动图组成元素-扩展区域

①扩展区域是表示过程中的某个活动片段的模型。

②扩展区域可以将一个需要体现在活动图中的循环过程进行提取（不需要体现在活动图中的，可以直接使用活动节点来略写）。

（6）活动图总结

1）描述一个操作执行过程中所完成的工作。说明角色、工作流、组织和对象是如何工作的。

2）活动图对用例描述尤其有用，它可建模用例的工作流，显示用例内部和用例之间的路径。它可以说明用例的实例是如何执行动作以及如何改变对象状态。

3）显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象。

4）活动图对理解业务处理过程十分有用。活动图可以画出工作流用以描述业务，有利于与领域专家进行交流。通过活动图可以明确业务处理操作是如何进行的，以及可能产生的变化。

5）描述复杂过程的算法，在这种情况下使用的活动图和传统的程序流程图的功能是差不多。

3、顺序图

（1）顺序图定义

1）顺序图是按时间顺序显示对象交互的图。它显示了参与交互的对象和所交换信息的先后顺序，用来表示用例中的行为，并将这些行为建模成信息交换。

2）顺序图主要包括四个元素：对象、生命线、激活和消息。在UML中，顺序图将交互关系表示为一张二维图。其中纵向是代表时间维度，时间向下延伸，按时间依次列出各个对象所发出和接收的消息。水平方向是代表对象的维度，排列着参与交互的各个独立的对象。

（2）顺序图作用

顺序图的三种主要作用：

1）细化用例的表达。本章前面我们已经提到，使用顺序图的一大用途，就是将用例所描述的需求与功能转化为更加正式、层次更加分明的细化表达。

2）有效地描述类职责的分配方式。我们可以根据顺序图中各对象之间的交互关系和发送的消息来进一步明确对象所属类的职责。

3）丰富系统的使用语境的逻辑表达。系统的使用语境即为系统可能的使用方式和使用环境。

（3）顺序图元素

1）顺序图元素-生命线和对象

生命线用一条纵向虚线表示。

对象表示为一个矩形，其中对象名称标有下划线。

对象的左右顺序并不重要，通常应遵循一下两个原则：

(1)把初始化整个交互活动的对象(有时是一个参与者）放置在最左边。

(2)把交互频繁的对象尽可能地靠拢。

2）顺序图-激活和消息

①激活是过程的执行，包括等待过程执行的时间。在顺序图中激活部分替换生命线，使用长条的矩形表示。

②消息是对象之间的通信，是两个对象之间的单路通信，是从发送者到接收者之间的控制信息流。消息在顺序图中由有标记的箭头表示，箭头从一个对象的生命线指向另一个对象的生命线，消息按时间顺序在图中从上到下排列。

③消息分类：

同步消息

异步消息

返回消息

3）顺序图-同步消息

消息的发送者把进程控制传递给消息的接收者，然后暂停活动，等待消息接收者的回应消息

带有实心箭头的实线来表示同步消息

4）顺序图-异步消息

消息的发送者将消息发送给消息的接受者后，不用等待回应的消息，即可开始另一个活动。

带有普通箭头的实线来表示异步消息

5）顺序图-返回信息

返回信息表示从过程调用返回

带有虚线箭头表示返回信息

6）顺序图-交互片段

一个复杂的顺序图可以划分为几个小块，每一个小块称为一个交互片段。每个交互片段由一个大方框包围，其名称显示在方框左上角的间隔区内，表示该顺序图的信息。常用操作符如下：

①alt：多条路径，条件为真时执行。

抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if..else..…

抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。else 的临界指示其他任何临界都不为True 时应运行的片段。如果所有临界都为False 并且没有else，则不执行任何片段。

②opt：任选，仅当条件为真时执行。

③par：并行，每一片段都并发执行。并行处理。片段中的事件可以交错

④loop：循环，片段可多次执行。

4、通讯图

（1）在UML1.0中，通信图称为协作图。通信图强调参与一个交互对象的组织。它与顺序图是同构图，也就是它们包含了相同的信息，只是表达方式不同而已，通信图与顺序图可以相互转换。

（2）通讯图实例

（3）通信图组成元素

用实线表示两个对象之间的连接；

消息由在连接上方的带有标记的箭头表示，同时可以用数字注明消息的次序。

（4）执行者通信图绘制技巧

1）通信图中的对象与顺序图中的对象对应；

2）通信图中无法表示对象的生命线，因此无法显示表示对象的创建和销毁；

3）通信图中的消息添加了顺序号，用于说明交互过程中消息的时间顺序。

4）通信图用于表示对象之间的协作关系，即强调参与交互的对象的组织。

（5）通信图VS顺序图

1）虽然通信图和顺序图均显示了交互，但它们强调了不同的方面。顺序图清晰地显示了时间次序，但没有显式指明对象间关系。通信图清晰地显示了对象间关系，但时间次序必须从顺序号来获得。

2）顺序图常用于用例场景描述，通信图更适合显示过程设计细节。

3）采用哪种图，一般可以根据这种原则：当对象及其连接有利于理解交

互时，选择通信图；当只需了解交互的次序时，选择顺序图。

7.5物理建模——组件图、部署图

0、使用组件图和部署图来表示物理图形

•构造一个面向对象的软件系统的时候，不光要考虑到系统的逻辑部分，也要考虑到系统的物理部分。

•在UML中，使用组件图和部署图来表示物理图形。这两种图用于建立系统的实现模型。

组件图描述业务过程

部署图描述业务过程中的组织机构和资源

1、组件图

（1）组件图的基本概念

①组件图是用来描述组件与组件之间关系的一种UML图，组件图在宏观层面上显示了构成系统某一特定方面的实现结构。它是一种结构型图表。

②在组件图中，我们将系统中可重用的模块封装成为具有可替代性的物理单元，我们称之称为组件，它是独立的，在一个系统或子系统中的封装单位，提供一个或多个接口，是系统高层的可重用的部件。包括软件代码、脚本、命令行文件、运行时的对象、文档、数据库等

（2）组件的组成元素

1）组件

①组件，是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组接口。

②组件是一个封装完好的物理实现单元它具有自己的身份标示和定义明确的接口。并且由于它对接口的实现过程与外部元素独立，所以组件具有可替性。

③组件在系统中一般存在三种类型，分别为部署组件、工作产品组件和执行组件。

④配置组件是构成系统所必要的组件，是运行系统时需要配置的组件。

⑤工作产品组件主要是开发过程的产物，是形成配置组件和可执行文件之前必要的工作产品，是部署组件的来源。工作产品组件并不直接参与到可执行系统中，而是用来产生系统的中间产品。

⑥执行组件代表可运行的系统最终运行产生的运行结果，并不十分常见。

2）接口

①对于一个组件而言，它有两类接口，提供接口与需求接口。

②提供接口：又被称为导出接口或供给接口，是组件为其他组件提供服务的操作的集合。

③需求接口：又被称为引入接口，是组件向其他组件请求相应服务时要遵循的接口。

3）端口

端口(port)是一个被封装的组件的对外窗口。在封装的组件中，所有出入组件的交互都要通过端口。组件对外可见的行为恰好是它端口的综合。端口允许把组件的接口划分为离散的并且可以独立使用的几部分。端口提供的封装性和独立性更大程度上保证了组件的封装性和可替换性。

（3）组件的内部结构

在UML 2规范中，组件允许通过套结构来表现组件的内部结构。

子组件之间通过接口建立关系。图中组件边缘的小矩形被称为端口，端口可以理解为组件的入口与出口，组件通过端口与外部元素相互协作。端口上可以添加提供接口或需求接口来使组件得以扩展。

（4）组件图中的关系

1）依赖关系

①组件与需求接口之间建立依赖关系

③组件与组件之间建立依赖关系：说明在运行过程中A在某些行为上依靠组件B的支持

④依赖关系使用在一端带有开放箭头的短划线表示。

⑤箭头从依赖的对象指向被依赖的对象。

2）实现关系

组件与提供接口之间建立实现关系

（4）组件图的作用

1）组件图通过显示系统的组件以及接口等之间的接口关系，形成系统的更大的一个设计单元。

2）在以组件为基础的开发CBD（基于组件开发）中，组件图为架构设计师提供了一个系统解决方案模型的自然形式。

3）组件图能够呈现整个系统的早期设计，使系统开发的各个小组由于实现不同的组件而连接起来。

4）组件图呈现系统的高层次架构视图，开始建立系统的各个里程碑，决定开发需求。

（5）类与组件的区别

1）类是逻辑抽象，组件是物理抽象

2）组件是对其它逻辑元素（如类或协作）的物理实现，即组件是软件系统的一个物理单元（如文件）

3）类可以有属性和操作；组件通常只有操作，而且这些操作只能通过组件的接口才能使用

2、部署图

（1）部署图概述

 部署图(Deployment Diagram)描述了：

1）一个系统运行时的硬件节点

2）节点上运行的软件组件将在何处物理地运行

3）它们将如何彼此通信的静态视图。

（2）在一个部署图中，包含了两种基本的模型元素：

节点(Node)和节点之间的连接(Connection)

在每一个模型中仅包含一个部署图。

（3）Rational Rose 2003中的节点类型

Rational Rose 2003中可以表示的节点类型包括两种，分别是处理器(Processor)和设备(Device)。

（4）部署图的基本概念

1）连接(Connection)用来表示两个节点之间的硬件连接

2）通常是双向的，UML中用一条实线表示，可以添加连接名或构造型

√物理媒介

√ 传输协议

3）连接的名称和构造型都是可选的。如图所示，节点客户端和服务器通过HTTP方式进行通信

（5）常用的通信协议

---

---

---

---

---

---

---

第八章：软件测试