软件体系结构第3章——统一建模语言UML

大学 / 大三 / 软件体系结构
Word count: 8.2k   |   Reading time≈ 28 min

第三章 统一建模语言UML==（20分）==

软件：powerDesigner 16.6

四种交互图：\textcolor{blue}{四种交互图：}

  1. 顺序图

  2. 通信图（与顺序图同构）

  3. 定时图

  4. 交互概览图（细化的活动图，采用顺序图来细化）

面向对象系统的物理方面建模的两种图：\textcolor{blue}{面向对象系统的物理方面建模的两种图：}

  1. 组件图

  2. 部署图

UML结构

视图(View)
image-20220928190818136

结构、实现、行为、环境视图

图(Diagram)
image-20220928190858031

红色和绿色必须完全掌握，黑色的则要能够看懂。

模型元素(Model element)

  1. 模型元素包括事物以及事物与事物之间的联系

  2. 每一个模型元素都有一个与之相对应的图形元素

  3. 同一个模型元素可以在不同的UML图中使用

  4. 无论在哪个图中，同一个模型元素都保持相同的意义和符号

通用机制(General mechanism)

  • 额外的注释、修饰和语义等

  • 包括规格说明、修饰、公共分类和扩展机制四种

  • 允许用户对UML进行扩展

UML的特点==（6个特点）==

  • 工程化

  • 规范化

  • 可视化——图的可视化

  • 系统化——多种UML图从不同角度描述同一功能

  • 文档化——使文档更易理解

  • 智能化

UML构造需求模型

重点：用例图、状态图、活动图、顺序图、用例文档

−−−用例图UseCaseDiagram−−−\textcolor{red}{---用例图Use Case Diagram---}

用例建模

重点：用例图、用例文档

考试：考试时，用例数量在10个左右\textcolor{red}{考试：考试时，用例数量在10个左右}

主要内容：

  • 用例图(Use Case Diagram)

  • 用例描述文档 (Use Case Specification)

术语表是为开发人员解释业务专业名词，而非面向用户

image-20220928194250542

用例建模步骤==（5步骤）==

  • 识别执行者

  • 识别用例

  • 绘制用例图

  • 书写用例文档

  • 检查用例模型

识别执行者
image-20220928194442951

执行者：直接操作系统的任何事物；

执行者包含三类：人、其它系统（比如：支付宝支付系统）、自动发生的事件（比如：时间）；

功能相同的执行者之间可以合并，但是具有不同执行功能的执行者之间就不能合并，如若合并则会导致真正的业务被覆盖

image-20220928200307684

用户在手机上买票⟶\longrightarrow用户是执行者；用户在车站买票⟶\longrightarrow用户不是执行者，售票员才是执行者（售票员直接与系统进行交互）。

image-20220928200504887

执行者与执行者之间只有继承关系\textcolor{red}{执行者与执行者之间只有继承关系}：

image-20220928200527380
识别用例
image-20220928200614839

用例要点：

  • 有意义的目标

  • 价值结果由系统生成

  • 业务语言——用户观点⟶\longrightarrow不要有技术语言（MVC，JDBC，分布式集群等等），用户不能理解

  • 注意用例的命名⟶\textcolor{red}{\longrightarrow}用户观点而非系统观点，即在命名用例时要以用户为主语

  • 用例的“粒度”

⭕️形式检查\textcolor{blue}{形式检查}

执行者通过（使用）系统来用例：

比如：会员通过（使用）系统来查询商品信息，这句话是通顺的，所以用例（查询商品信息）的取名可行。

1️⃣用例命名：

image-20220928201657020

慎用弱动词弱名词：

image-20220928201758262

2️⃣用户的“粒度”

粒度原则：

  • 用例要有路径，路径要有步骤。而这一切都是“可观测”的

    • 路径：正常路径+扩展路径

  • 用户和系统的步骤都不能作为用例

执行者之间的关联关系
image-20220928203647567
执行者之间的泛化关系（继承）
image-20220928203735811
包含关系
image-20220928204022864

依赖关系：一个事物使用了另一个事物

扩展关系
image-20220928204128837

比如“现金支付”的扩展点就是“支付”，因此可以围绕“支付”得到新的扩展用例——信用卡支付

注意：

“支付”只是一个抽象出来的行为，而不是说两个用例之间一定要有相同的字

泛化关系
image-20221005191535414
实例：
image-20221005191739294

分两步：

  1. 识别执行者
  2. 识别用例

要求：不漏掉用例、不产生歧义。

image-20221005191937370

1️⃣用例是文本文档，而非图形

2️⃣用例建模主要是编写文本的活动，而非制图

书写用例文档

用例的内容
image-20221005193923898

红色**（6个必须有）**必须有，其他可以有

实例：
image-20221005194018599
前置、后置条件
image-20221005194429632

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

前置条件、后置条件必须是系统能检测的。

涉众利益

⟶\longrightarrow观众没有参与，但是用例结果与观众的利益息息相关。

基本路径

  • 只书写“可观测”的（说人话）

  • 使用主动语句

  • 句子必须以执行者或系统作为主语

  • 每一句都要朝目标迈进

  • 分支和循环

  • 不要涉及界面细节

用例交互四步曲：

image-20221005200447673
扩展路径
image-20221005200706074

  1. 替换路径

  2. 异常路径

补充约束
image-20221005200812608

用例实例：

image-20221105112322378 image-20221005201238950

检查用例模型

主要可以从以下几个方面来进行检查：

  • 功能需求的完备性

  • 模型是否易于理解

  • 是否存在不一致性

  • 避免语义二义性

用例追踪矩阵：

image-20221105112416870

用例模型完成之后，需要对用例模型进行检查，看看是否有遗漏或错误之处。

−−−状态图StatechartDiagram−−−\textcolor{red}{---状态图Statechart Diagram---}

定义：用来描述一个特定**对象的所有可能状态及其引起状态转移的事件**

状态图通常用来描述单个对象的行为

只有那些具有重要交互行为的类，才会使用状态图来描述；一个状态图包括一系列对象的状态及状态之间的转换。

image-20221010192638748

状态图中只有一个初始状态，而可以有多个结束状态。

image-20221010192712261

image-20221010192729391

守护条件：事件名[条件]/动作名

状态图组成元素

  • 初始状态

  • 终止状态

  • 状态

  • 转移

  • 守护条件

  • 事件

  • 动作

image-20221010192855708
状态图高级技巧

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

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

复合状态：
image-20221010194319307

行驶状态时复合状态，其内有3个简单状态

带同步条的状态图：

image-20221010194536450

状态图的绘制

在绘制对象的状态图时，要考虑以下因素（5个）：

  • 对象有哪些有意义的状态；

  • 对象的哪些状态之间可以相互转换；

  • 对象状态之间何时发生转换；

  • 对象在不同状态下有哪些行为；

  • 对象的状态图和其他模型之间如何进行映射。

技巧：

  • 状态图适合用于表述在不同用例之间的对象行为。

  • 系统设计中可能有多个对象，但并不需要给出每个对象的状态图，实际的做法是把注意力集中在整体系统或少数关键的对象上，特别是那些状态比较多的对象。

状态模式

状态图与类图相结合共同描述

image-20221010200716354

增加状态时直接增加子类即可

状态图实例分析：

image-20221010201202654

−−−活动图ActivityDiagram−−−\textcolor{red}{---活动图Activity Diagram---}

定义：

  • 表示系统中各种活动的次序，可用来描述用例的工作流程，也可以用来描述类中某个方法的操作行为。

  • 活动图依据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果。活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。

In UML,Activity diagramgives a simplified representation of a process,showing control flows between actions performed in the system

control flows：控制流

应用：

  1. 利用文本描述用例的事件流是很有用的，但如果事件流的逻辑复杂且有许多其他事件流，则文本形式可能较难阅读和理解，这时可使用活动图来描述事件流。

  2. 活动图是UML中的流程图，它是事件流的另一种建模方式。活动图用于以图形化的方式描述一个业务过程或者一个用例的活动的顺序流，它也可以用于建模一个操作要执行的动作，以及那些动作的结果。

  3. 活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么（对象状态改变）、何时发生（动作序列）以及在何处发生（泳道）。

作用：

  • 描述业务流程\textcolor{red}{描述业务流程}（主要应用）

  • 描述用例路径

  • 描述方法执行流程（程序流程图）

活动图实例分析：

image-20221010202430272

活动图组成元素

  • 起始活动(Start Activity)

  • 终止活动(End Activity)

  • 活动(Activity)

  • 转移(Transition)或流(Flow)

  • 决策(Decision)

  • 守护条件(Condition)

  • 同步条(Synchronization)

  • 泳道(Swimlane)

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

image-20221010202855285

在活动图中，对象流使用带箭头的虚线表示，对象用矩形表示，矩形内是该对象的名称，名称下的方括号表示该对象此时的状态。

image-20221010203141748

B to B实例

image-20221010203305166
泳道

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

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

image-20221010203431594

泳道的加入不一定能够简化活动图，可能使得活动图更复杂。

活动图的绘制技巧

  • 使用活动图来描述用例路径更加直观。

  • 对面向对象建模而言，用活动图描述业务流程并不是对每个系统都必不可少的工作。

  • 不要把描述业务流程的活动图看成可编程的模型，它与系统的实际构造情况和执行情况有很大的差距。

  • 首先要对主要的业务流建模，然后再标出分支、合并和对象流。

  • 尽量减少交叉线，如果图形较为复杂，适当使用颜色和注释。

实例：
image-20221012191357064

−−−顺序图SequenceDiagram−−−\textcolor{red}{---顺序图Sequence Diagram---}

image-20221012191605666

sequence Diagram

顺序图实例
image-20221012191958998

以上绘制的顺序图不是特别的严谨，因为小王和小张都需要一台电话，但是上图很好的展示了顺序图的时间顺序特点

顺序图组成元素
image-20221012192209175 image-20221012192300054
对象
生命线

对象就是一个类对象，或是类型定义的变量；

生命线就是一个代码语句或是函数的从开始执行到结束花费的时间过程。

image-20221012192523494
实例：
image-20221012192601501

激活一般随着return结束

image-20221026184557410
调用消息
image-20221012192918606

调用消息只能是从左边向右边发送，或者一个对象自己想自己发送调用消息==？==

在源代码层面上：call 一个函数

自身消息

在源代码层面上：call 一个函数

返回消息
image-20221012193649713

返回消息必须逐个对象地向左返回，不能出现跨对象的消息返回==？==（不一定，特别是在绘制源代码的顺序图时）

在源代码层面上：return 结果

发送消息
image-20221012193709104
创建消息

一条生命线的开始

在源代码层面上：new 一个新的对象（当然也不只new，如：Money subTotal = null;也相当于创建了一个对象，Money是一个类型）

销毁消息

一条生命线的结束

image-20221012193453795

绘制方法：

image-20221026202651990

在源代码层面上：对象销毁

同步消息
异步消息
image-20221012193817042
交互片段
image-20221012200229504

image-20221012200546412

alt：类似于if…else

opt：表示一个可能存在又可能不存在的消息通信过程

par：表示对象生命线中并行进行消息通信的部分

loop：类似于for

critical：

实例：
image-20221012200722072
顺序图作用

  1. 对于业务人员，顺序图可显示不同的业务对象如何交互，对于交流当前业务如何进行很有用。除记录组织的当前事件外，一个业务级的顺序图能被当作一个需求文件使用，为实现一个未来系统传递需求。

  2. 对于需求分析人员，顺序图能通过提供一个深层次的表达，把用例带入下一层次。通常用例被细化为一个或者更多的顺序图。顺序图的主要用途之一，是把用例表达的需求，转化为进一步、更深层次的精细表达。

  3. 对于技术人员，顺序图在记录一个未来系统的行为应该如何表现时非常有用。在设计阶段，架构师和开发者能使用顺序图挖掘出系统对象间的交互，进一步完善整个系统的设计。

顺序图绘制技巧

  • 以用例为单位创建顺序图，针对每个用例，考察为完成它所描述的功能需要哪些对象的操作参与执行，并且进一步考察这些操作的执行需要通过消息而引起其他哪些对象操作的执行。把这些对象以及参与交互的执行者组织到一个顺序图中。

  • 理论上需要为每一个用例创建一个顺序图，但是如果一个用例的交互对象很简单可以不需要创建顺序图。

image-20221012201012194

用例图、状态图、活动图以及顺序图联系

image-20221012201150564

顺序图：多个对象的行为（用例中）

状态图：单个对象的行为

活动图：跨用例或跨线程的行为

需求分析阶段的顺序图：

主要用于描述用例中对象之间的交互，可以使用自然语言来绘制，用于细化需求。从业务的角度进行建模，用描述性的文字叙述消息的内容。

image-20221012201310859
系统设计阶段的顺序图：

确切表示系统设计中对象之间的交互，考虑到具体的系统实现，对象之间通过方法调用传递消息。

image-20221012201320452
实例：
image-20221012201607292 image-20221012201715385

UML构造设计模型

教学内容：

  • 类与类图（考试：40分）：类与类之间的关系

  • 正向工程与逆向工程：

  • 包图：包与包之间的关系

  • 组件图：文件与文件之间的关系

  • 部署图

image-20221012202957477
定义属性
image-20221012203114976

+：public

#：protected

-：private

定义操作
image-20221012203322475

构造函数没有返回类型（连空类型也没有）

重要的提示：

  1. 有抽象方法的类一定是抽象类

  2. 抽象类中可以有实体类

实验日期：10月26日−18：30——21：30\textcolor{red}{实验日期：10月26日-18：30——21：30}

−−−类图ClassDiagram−−−\textcolor{red}{---类图Class Diagram---}

类之间的关系

内容：

  • 关联关系

    • 双向关联
    • 自关联
    • 多重性关联

  • 聚合关系

  • 组合关系

  • 依赖关系

  • 泛化/继承关系

  • 接口与实现关系

  • 注释(Comment)

关联关系

  • 关联关系(Association)是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。

  • 在UML类图中，用实线连接有关联的对象所对应的类，在使用Java、C#和C++等编程语言实现关联关系时，通常将一个类的对象作为另一个类的属性。

  • 在使用类图表示关联关系时可以在关联线上标注角色名。

image-20221019192539945

在LoginFrom类里面实例化了JButton的对象，并将JButton的对象作为自己的属性，所以说：LoginFrom类关联JButton类

双向关联
image-20221019192739848
自关联
image-20221019192918485
多重性关联 （重数性关联关系）
image-20221019193004253 image-20221019193329939
聚合关系

  • 聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。

  • 在聚合关系中，成员类是整体类的一部分，即成员对象是整体对象的一部分，但是成员对象可以脱离整体对象独立存在。在UML中，聚合关系用带空心菱形的直线表示。

image-20221019193526272

注入，类似于将多个部分装配在一起，形成整体，但部分可以单独存在。

组合关系

  • 组合关系(Composition)也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。

  • 在组合关系中，成员类是整体类的一部分，而且整体类可以控制成员类的生命周期，即成员类的存在依赖于整体类。在UML中，组合关系用带实心菱形的直线表示。

image-20221019193703268

显然，聚合关系的耦合度要小于组合关系。

month = new Mouth()，在整体类的构造函数中实例化了成员类的对象

依赖关系

  • 依赖关系(Dependency)是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。

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

1️⃣

image-20221019194116349

依赖关系体现在某个类的方法使用另一个类的对象作为参数；

由依赖的一方指向被依赖的地方：Driver依赖Car。

2️⃣

image-20221019194627683

3️⃣

image-20221019200241641 image-20221019200205602

既有关联又有依赖，此时与聚合关系有些相同

泛化/继承关系

  • 泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。

  • 在代码实现时，使用面向对象的继承机制来实现泛化关系，如在Java语言中使用extends关键字、在C++/C#中使用冒号“：”来实现。

image-20221019200429950 image-20221019200503026

泛化/继承关系是为了实现扩展

接口与实现关系

接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。

image-20221019200852726

一个非抽象类需要实现接口的所有方法；\textcolor{red}{一个非抽象类需要实现接口的所有方法；}

抽象类可以只实现接口中的部分方法，剩下的方法可以由抽象类的子类实现。\textcolor{blue}{抽象类可以只实现接口中的部分方法，剩下的方法可以由抽象类的子类实现。}

缺省适配器模式：

假设一个接口中的方法很多，可以创建一个抽象类来实现该接口(该抽象类可以没有抽象方法)，然后将其中所有的方法空实现（函数体均为空），之后想要实现该接口中的内容时只需要让子类继承抽象类并覆盖想要实现的方法即可。由此避免了直接实现该接口的所有的方法。

常量接口模式：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
//常量接口
public interface MyConstants {
    public static final double MATH_PI = 3.1415926;
    public static final double MATH_E = 2.71828;

}
//MyConstants.*的方式进行调用
public class Circle {
    private double r;//半径
    public Circle(double r){
        this.r = r;
    }
    public double getCircumference(){
        return 2 * r * MyConstants.MATH_PI;
    }
}
依赖倒转原则

参考：(77条消息) 设计模式-依赖倒转原则_Pastthewind的博客-CSDN博客

各关系之间的耦合程度

虚线代表耦合程度低于实线的耦合程度；线型箭头的耦合程度要低于三角箭头的耦合程度。⟶\longrightarrow不一定正确

  • 依赖关系：虚线线型箭头
  • 关联关系：实线线型箭头
  • 接口实现关系：虚线三角箭头
  • 泛化/继承关系：实线三角箭头
  • 聚合关系：空心菱形实线线型箭头
  • 组合关系：实心菱形实线线型箭头

泛化（继承）=实现>组合>聚合>关联>依赖（耦合程度？）

注释(Comment)
image-20221019202133822
实例分析
image-20221019202428659

image-20221019202803274

DTO（Data Transfer Object）：数据传输对象，减少了参数的数量

UserDAO：实现对数据库的增删查改操作

正向工程与逆向工程

适配器模式之加密算法适配
image-20221019203216526

绘图技巧\textcolor{red}{绘图技巧}

在正向工程生成代码时如果出现错误可以将类中的属性删去，因为类图中的属性与关联图线上的描述出现冲突；

−−−包图Packagediagram−−−\textcolor{red}{---包图Package diagram---}

概念：

  • 包是一种把元素组织到一起的通用机制，包可以嵌套于其他包中。

  • 包图用于描述包与包之间的关系，包的图标是一个带标签的文件夹。

Package diagrams are structural diagrams used to show the organization and arrangement of various model elements in the form of packages.

引入关系

一个包中的类可以被另一个指定包（以及嵌套于其中的那些包）中的类引用。

引入关系是依赖关系的一种，需要在依赖线上增加一个<>衍型，包之间一般依赖关系都属于引入关系。

image-20221024191612181
泛化关系

表示一个包继承了另一个包的内容，同时又补充自己增加的内容。

image-20221024191634328
嵌套关系

一个包中可以包含若干个子包，构成了包的嵌套层次结构。

image-20221024191737056
包图绘制技巧

  1. 两种组包方式：

    • 根据系统分层架构组包（推荐使用）；
    • 根据系统业务功能模块组包。

  2. 参照类之间的关系确定包之间的关系；

  3. 减少包的嵌套层次，一般不超过三层；

  4. 每个包的子包控制在7±2个；

  5. 可通过包图来体现系统的分层架构。

包图体现体系结构
image-20221024191925576
包图实例（基于B/S的OA系统）
image-20221024191954538

包图有利于查看项目的层次

−−−组件图ComponentDiagram−−−\textcolor{red}{---组件图Component Diagram---}

用于表示文件之间的关系\textcolor{red}{用于表示文件之间的关系}

存在泛化和依赖关系

组件图定义

1、组件图又称为构件图(Component Diagram) 。组件图中通常包括组件、接口，以及各种关系。组件图显示组件以及它们之间的依赖关系，它可以用来显示程序代码如何分解成模块或组件。

一般来说，组件就是一个实际文件，可以有以下几种类型：

  • 源代码组件：一个源代码文件或者与一个包对应的若干个源代码文件。

  • 二进制组件：一个目标码文件，一个静态的或者动态的库文件。

  • 可执行组件：在一台处理器上可运行的一个可执行的程序单位，即所谓可执行程序。

这里的构件指的就是文件，区别于体系结构三要素中的构件。

2、组件图可以用来显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。

image-20221024193534495

3、组件间的关系有两种：泛化关系和依赖关系，如果两个不同组件中的类存在泛化关系或依赖关系，那么两个组件之间的关系就表示为泛化关系或依赖关系。

4、对于由多个组件组成的大系统来说，组件图非常重要。

实例：
image-20221024194425279
组件图组成元素

组件：系统中可以替换的部分，一般对应一个实际文件，如exe、jar、dll等文件，它遵循并提供了一组接口的实现。

接口：一组操作的集合，它指明了由类或组件所请求或者所提供的服务。

部件：组件的局部实现。

端口：被封装的组件与外界的交互点，遵循指定接口的组件通过它来收发消息。

连接件：在特定语境下组件中两个部件之间或者两个端口之间的通信关系。

实例：
image-20221024195659233
组件图绘制技巧
image-20221024200124495
组件图实例分析
image-20221024200242114 image-20221024200256001

−−−部署图DeploymentDiagram−−−\textcolor{red}{---部署图Deployment Diagram---}

描述硬件之间的关系\textcolor{red}{描述硬件之间的关系}

部署图定义

部署图(Deployment Diagram)，也称为实施图，它和组件图一样，是面向对象系统的物理方面建模的两种图之一。组件图是说明组件之间的逻辑关系的，而部署图则是在此基础上更进一步，描述系统硬件的物理拓扑结构及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、节点上运行的软件组件。

在UML中，部署图显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。部署图通常被认为是一个网络图或者物理架构图。

实例：
image-20221024201102067
部署图组成元素
image-20221024201204897

连接是没有箭头的实线，表示的是信息的双向通信。

部署图绘制技巧
image-20221024201237102
部署图实例分析
image-20221024201648903

1️⃣

image-20221024201656562

2️⃣

image-20221024201708537

3️⃣

image-20221024201750835

更多图（要求能够看懂）：

image-20221024202811148
对象图(Object diagram)

image-20221031191956313

组合结构图(Combined structure diagram)
组合结构图的注意事项：

image-20221024204401865

通信图(Communication diagram)

  • 与顺序图同构（通信图在UML1.0时也称为协作图）

  • 通信图与顺序图可以相互转换

  • 当需要了解消息的先后顺序时选择通信图

通信图由以下基本元素组成：执行者(Actor)、对象(Object)、连接(Link，也称为链)、消息(Message)和守护条件(Condition)。

在UML中，使用实线表示两个对象之间的连接；通信图中的消息，由在连接上方的带有标记的箭头表示，同时可以用数字注明消息的次序。

image-20221031192048386 image-20221031192157721

守护条件：以“[条件表达式]”格式表示

image-20221031192322425
通信图绘制技巧

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

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

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

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

image-20221031192628451
通信图实例分析

某电梯控制系统：Elevator（电梯）、Queue（命令队列）、Order（指令）、Elevator Control（电梯控制器）、Button（按钮）

image-20221031192920138
通信图与领域建模

image-20221031193308758

定时图(Timing diagram)
定时图定义

定时图采用一种带数字刻度的时间轴来精确地描述消息的顺序，而不是像顺序图那样只是指定消息的相对顺序，而且它还允许可视化地表示每条生命线的状态变化，当需要对实时事件进行建模时，定时图可以很好地满足要求。

定时图的焦点集中于生命线内部以及它们之间沿着时间轴的条件变化。

定时图可以把状态发生变化的时刻以及各个状态所持续的时间具体地表示出来。如果把多个对象放在一个定时图中，还可以把它们之间发送和接收消息的时刻表示出来。在这方面，定时图与其他几种交互图相比具有独到的优势。

定时图来自于电子工程领域，在需要明确定时约束一些事件时可以使用它们。

image-20221031193915106

image-20221031193950667

image-20221031194032296

  1. 增加了生命线的时间刻度；

定时图绘制技巧

  1. 定时图用于表示不同对象上状态改变之间的定时约束，如果需要对交互时间进行控制可使用定时图。

  2. 对于那些时间指标要求很高或者时序关系复杂而又敏感的系统（例如嵌入式实时系统和通信领域的某些系统）而言，定时图是一种有力的描述手段。

  3. 在大部分应用系统的建模中，一般不需要用定时图来描述对象的行为以及它们之间的交互，但是可能需要用它描述系统中某些局部对象的交互情况。

image-20221031195141690

定时图练习

有一个咖啡壶，它由抽水泵和加热板所组成。它的规则是：在抽水泵打开和加热板打开之间必须至少隔10秒钟。当储水容器变空时，抽水泵就要关闭，而加热板继续保持加热，但不能超过5分钟。试使用定时图来表示上述规则。

交互概览图(Interaction overview diagram)

活动图与顺序图的组合\textcolor{red}{活动图与顺序图的组合}

交互概览图定义

  • 交互概览图是交互图（有4种）与活动图的混合物，可以把交互概览图理解为**细化的**活动图，在其中的活动都通过一些小型的顺序图来表示；也可以将其理解为利用标明控制流的活动图分解过的顺序图。

  • 交互概览图用于将一些零散的顺序图组织在一起，它采用了活动图的构造方式，利用了活动图的各种控制节点，并把活动图的每个活动结点替换为一个交互或者交互使用。每个交互或者交互使用都使用一个顺序图表示。

实例之一：

image-20221031200433652

实例之二：

image-20221031200458992
交互概览图绘制步骤：

  1. 选择策略（对工作流建模或对操作建模）

  2. 理清主线（绘制活动图）

  3. 表述细节（用顺序图来表述详细细节）

UML扩展机制

image-20221031201027489

实例：使用标记值增加模式标注信息

image-20221031201321773

图总结

image-20221031201637614

图名 概述 使用频率
用例图 描述用户与系统如何交互 ★★★★★
类图 描述类、类的特性以及类之间的关系 ★★★★★
包图 描述类的层次结构 ★★★★☆
顺序图 描述对象之间的交互，重点在于强调顺序 ★★★★☆
状态图 描述事件如何改变对象状态 ★★★☆☆
活动图 描述过程行为及其并发行为 ★★★☆☆
组件图 描述组件的结构与连接 ★★★☆☆
部署图 描述各个节点上组件的部署情况及节点间的连接 ★★★☆☆
通信图 描述对象之间的交互，重点在于连接 ★★☆☆☆
对象图 描述一个时间点上系统中各个对象的一个快照 ★★☆☆☆
组合结构图 描述类结构的分解 ★☆☆☆☆
交互概览图 顺序图与活动图的混合 ★☆☆☆☆
定时图 描述对象之间的交互，重点在于定时 ★☆☆☆☆

活动图：

image-20221031202105651

UML建模原则

  1. 适当增加注释，用于对图形和符号进行说明

  2. 画图的目的是简化对系统的理解，而不是增加工作量

  3. 注意折衷，既不能将图画得太复杂，同时也不能遗漏重要信息

  4. 保持图的一致性

  5. 需要什么就画什么，不需要就坚决不画，不要画多余的图

  • Copyright： Copyright is owned by the author. For commercial reprints, please contact the author for authorization. For non-commercial reprints, please indicate the source.
  • Copyrights © 2023-2024 Guijie Wang
  • Visitors: | Views:

请我喝杯咖啡吧~

支付宝
微信