06 第六讲 UML简介.pptx

第1页：第六章UML简介目录

第六章 UML 简介：

• §6.1 UML 概述
• §6.2 UML 的静态建模机制
• §6.3 UML 的动态建模机制

第2页：6.1 UML概述 章节标题页

§6.1 UML 概述：本小节介绍什么是 UML、为什么需要 UML、UML 的主要内容、发展历史、特点与应用范围。

第3页：什么是UML

§6.1.1 UML 的主要内容 —— 什么是 UML：

• UML 表示 Unified Modeling Language（统一建模语言）
• UML 把下面一些先进的技术结合起来：数据建模概念（实体关系图）、商业建模（工作流）、对象建模、组件建模、行为建模
• UML 是用来对软件相关系统进行可视化、规范、创建和建立文档的标准语言
• UML 可以用在所有的过程中，贯穿整个开发周期，并跨越不同的实现技术

第4页：为什么需要UML

为什么需要 UML：

• 面对众多的建模语言，用户由于没有能力区别不同语言之间的差别，因此很难找到一种比较适合其应用特点的语言
• 众多的建模语言实际上各有千秋
• 虽然不同的建模语言大多类同，但仍存在某些细微的差别，极大地妨碍了用户之间的交流
• 因此在客观上，极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其精华、去其糟粕、求同存异，统一建模语言

第5页：UML的表示法与语义

§6.1.1 UML 的主要内容：

• UML 表示法：UML 的符号、文本语法、图形机制，用来表达应用问题在需求、设计和实现级的模型
• UML 语义：用 UML 表示法描述 UML 的元模型，元模型为 UML 的所有语法元素的语义提供定义性说明
• UML 的可视化建模机制分为静态和动态：静态机制包括用例图、类图、对象图、包图、构件图、配置图；动态机制包括顺序图、合作图、状态图、活动图

第6页：UML的发展历史

§6.1.2 UML 的历史：

• 80 年代末期到 90 年代，各种 OO 软件开发方法纷纷涌现：OOA/OOD、Booch、OMT、OOSE 等
• 1994 年 10 月，Booch 和 Rumbaugh 统一 Booch93 和 OMT2，发布 UML 0.8
• 1995 年秋，Jacobson 加盟 Rational；1996 年 6 月发布 UML 0.9，1996 年 10 月发布 UML 0.91
• 1997 年 UML 获众多著名软件公司的支持，11 月被 OMG 接纳为标准
• 1998 年 UML 发展到 UML 1.4，相应的软件开发环境 Rational Rose 正式推出
• 2003 年 UML 发展到 UML 2.0

第7页：UML的演化脉络图

§6.1.2 UML 的历史：图示 Booch、OMT、OOSE 等方法经 Unified Method 0.8（OOPSLA´95）汇合，依次演化为 UML 0.9、UML 1.0、UML 1.1、UML 1.3 直至 UML 2.0 的过程。

第8页：UML的特点

§6.1.3 UML 的特点：

• 集成众多 OO 软件开发方法的表示机制的优点，统一化、标准化、系统化
• 用宽谱语言机制支持软件开发全过程
• 具有较完善、配套的软件开发环境（如 Rational Rose）
• 已成为 OO 建模语言的事实上的工业标准，发展前景广阔

第9页：UML的应用范围

§6.1.4 UML 的应用范围：

• UML 适用于软件开发全过程
• 可以对任何具有静态结构和动态行为的系统进行建模（如机械系统、信息系统、企业结构等）
• 广泛地用于管理信息系统、通信与控制系统、嵌入式实时系统、分布式系统、系统软件等建模
• 近几年还被运用于软件再工程、质量管理、过程管理、配置管理等方面
• 不仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模

第10页：6.2 UML静态建模机制 章节标题页

§6.2 UML 静态建模机制：本小节依次介绍用例图、类图、对象图、包图、构件图与配置图，并说明系统架构的概念与分类。

第11页：用例的概念

§6.2.1 用例图 —— 1. 用例：

• 用户与计算机之间一次典型的交互作用，引发系统执行一系列动作，动作执行的结果能被用户（或外部实体）觉察到
• 用例描述某种用户（或外部实体）可见的动作，实现一个具体的完整的用户目标
• 用例不同于用户与软件系统的交互动作序列

第12页：用例图的概念

§6.2.1 用例图 —— 2. 用例图：用例图描述执行者（Actor）与用例，以及用例与用例之间的关系。

第13页：用例图的示例

§6.2.1 用例图：本页以图示方式给出用例图的画法，展示执行者、用例以及二者之间的关联连线。

第14页：用例图中的关系

§6.2.1 用例图 —— 3. 用例图中的关系：

• Actor 与用例之间的关系：触发执行，交换信息
• 扩展关系：用例 A 与 B 相似，但 B 的动作较 A 多，含有 A 所不具备的一些特殊情况下的处理动作，则将 B 作为 A 的扩展
• 使用关系：如果多个用例 A1,…,An 中存在公共的动作 B，可将 B 抽出，Ai 使用 B（i=1,2,…,n）

第15页：扩展与使用关系对比

§6.2.1 用例图：本页以图示方式对比扩展关系与使用关系在用例图上的表示方式。

第16页：扩展与使用的差异

§6.2.1 用例图 —— 3. 用例图中的关系：

• 扩展关系主要用来描述对正常处理行为的变异
• 使用关系主要用来避免重复
• 扩展与使用的差异：Actor 可与扩展的用例关联，但一般不与使用中的公共用例相连接

第17页：获取执行者的方法

§6.2.1 用例图 —— 4.1 获取 Actor：

• 谁使用系统的各项功能
• 谁需要系统支持其工作
• 谁来维护、管理、配置系统
• 谁对系统产生的结果感兴趣
• 系统需要与哪些外部实体交互
• 观察用户的工作流程
• 标识外部事件并观察用户的反映

第18页：对执行者提问以获取用例

§6.2.1 用例图 —— 4.2 对 Actor 提问以获取用例：

• 要求系统提供哪些功能
• 系统需要哪些输入／输出以完成上述功能，输入源和输出目标是什么
• Actor 要存取、修改的信息有哪些
• Actor 与系统之间相互提醒的事件有哪些

第19页：标识用例间关系与约束

§6.2.1 用例图 —— 4.3 标识 Actor 及用例之间的关系、4.4 约束：

• 利用「扩展」表示变异处理行为
• 利用「使用」抽取公共行为，简化用例图
• 每个用例必须至少与一个 Actor 相连接
• 4.4 约束：对用例模型附加约束条件

第20页：类图概述

§6.2.2 类图 —— 1. 类图：类图是 UML 中 OO 模型的基础，它们描述系统的静态结构。类图主要描述：

• 对象的类型、属性与操作
• 类之间的静态关系：关联、子类型、聚集和构成、依赖等
• 作用于上述关系之上的约束
• 包图描述系统的分治结构

第21页：类与关联的表示

§6.2.2 类图：本页给出类的表示方式（分栏显示类名、属性与操作）与关联的表示方式（类之间的实线连接）。

第22页：聚集与子类型的表示

§6.2.2 类图：本页给出聚集和构成的表示（菱形端指向整体）与子类型（继承）的表示（三角形指向一般类）。

第23页：类图综合示例

§6.2.2 类图：综合示例如订单系统，给出 Order、Order Line、Customer、Personal Customer、Corporate Customer、Employee、Product 等类，标注属性、操作、角色名（sales rep、line items）、多重性（0..1、1、*）、关联、泛化与约束（如「若 Order.customer.creditRating 为 poor，则 Order.isPrepaid 必须为 true」）。

第24页：类图的三个抽象层次

§6.2.2 类图 —— 2. 类图的抽象层次：

• 概念层：描述问题域中的概念及它们之间的静态关系
• 规范层：描述类型（去除方法体之后的类）及其关系，即软件结构
• 实现层：描述类及其关系

第25页：属性的定义

§6.2.2 类图 —— 3. 属性：

• 概念层：同 OOA/OOD，描述问题域中的概念的属性
• 规范层：隐含 get/set 方法
• 实现层：隐含类中成员变量的说明
• 定义形式：可见性 属性名：类型 = 缺省值 {约束特性}

第26页：操作的定义

§6.2.2 类图 —— 4. 操作：

• 概念层：问题域中的任务描述
• 规范层：操作的接口描述
• 实现层：方法体
• 定义形式：可见性 操作名（参数表）：返回类型 {约束特性}

第27页：关联及其层次含义

§6.2.2 类图 —— 5. 关联：关联表示两个类之间语义上的联系，关联具有两个角色（Roles），可以对角色命名，匿名角色使用目标类作为名字。

• 概念层：两个概念之间的联系
• 实现层：隐含两个类在各自的成员变量中相互包含或引用，例如 class Order 中包含 Customer 与 ItemVector，class Customer 中包含 OrderVector
• 规范层：隐含类型之间的查询职责和关系维护职责，例如 Order 提供 getCustomer()、enumOrderItems() 等

第28页：关联关系画法

§6.2.2 类图 —— 5. 关联：本页以图示方式展示两个类之间的关联连线及其语义联系。

第29页：关联的方向与导航性

§6.2.2 类图 —— 5.1 关联的方向：导航（Navigability）：

• 单向关联与双向关联
• 无向关联可视为双向关联，或未确定

第30页：关联类的概念

§6.2.2 类图 —— 5.2 关联类：

• 关联类用来记录与关联有关的信息，提供与关联有关的操作
• UML 规定：两个被关联对象之间，最多只存在一个关联对象
• 示例：Person 与 Company 之间的 Employment 关联类，带 period: dataRange 属性，多重性为 * 对 0..1

第31页：关联类画法

§6.2.2 类图 —— 5.2 关联类：本页以图示方式展示关联类通过虚线连接到关联连线上的表示法。

第32页：雇佣关联类示例

§6.2.2 类图 —— 5.2 关联类：示例给出 Person 与 Company 之间的 Employment 关联类，标注 period: dataRange 属性，两端多重性分别为 * 对 0..1。

第33页：聚集与构成

§6.2.2 类图 —— 5.3 聚集和构成（Composition）：

• 共享聚集：部分可参加多个整体
• 构成：每个部分类的对象只参加一个整体类对象，部分与整体共存亡
• UML 将聚集区分为共享聚集和构成
• 示例：Polygon 由 Point 构成（多重性 3..*，约束 {ordered}），Circle 含 Color、isFilled、Style、radius 等属性

第34页：继承及其层次含义

§6.2.2 类图 —— 6. 继承：

• 概念层：一般类具有的属性、操作及关联，特殊类也隐含地具有；特殊类还应包含额外的属性或操作
• 实现层：特殊类是一般类的子类（在 OOPL 的意义上）
• 规范层：特殊类的接口与一般类的接口相一致

第35页：依赖关系

§6.2.2 类图 —— 7. 依赖：如果对 X 的修改将导致 Y 必须修改，则称 Y 依赖于 X。依赖关系的起因包括：

• 一个类的对象是另一个类的对象的数据成员
• 发送消息
• 一个类的对象是另一个类的操作参数等

第36页：约束的定义与表示

§6.2.2 类图 —— 8. 约束：

• 约束可作用于关联、属性、操作和类
• 定义形式：{字符串}
• 在代码实现时，可用断言来实现约束

第37页：类别模板与扩充机制

§6.2.2 类图 —— 9. 类别模板（Stereotype）：

• UML 通过类别模板提供扩充机制
• 类别模板是对类、关联等 UML 语法元素的元级分类，用来描述它们之间不同的语义类别
• 例如，在操作定义时可附加以下类别模板：《get_op》、《set_op》、《inquiry_op》、《modifier_op》

第38页：多重分类与动态分类

§6.2.2 类图 —— 10. 多重分类与动态分类：

• UML 允许一个对象随属性值的改变而改变类型
• UML 允许一个对象具有多个类型
• 尽量避免在规范层和实现层使用多重分类与动态分类

第39页：多重分类与动态分类示例

§6.2.2 类图：示例给出 Person 按 sex（mandatory）分为 Female 与 Male，按 Job 分为 Manager、Engineer、Salesman，并以《dynamic》标注动态分类。

第40页：派生属性与派生关联

§6.2.2 类图 —— 11. 派生属性与派生关联：

• 概念层：派生属性和派生关联均可省略；如果需要，可显式强调两个类之间的派生关联，但应与原始关联保持一致
• 规范层：派生属性可视为类的属性之间的约束
• 实现层：派生属性可视为内部 Cache
• 示例：Employment 关联类中 period 与 /employer 派生关联

第41页：抽象类与接口

§6.2.2 类图 —— 12. 抽象类与接口：

• 抽象方法：仅含方法头，没有方法体
• 抽象类：含有抽象方法的类
• 接口：只含抽象方法的类
• UML 分别用 {abstract} 和《interface》表示抽象类与接口；示例给出 InputStream{abstract}、DataInput《interface》、DataInputStream、OrderReader 之间的泛化、精化与依赖关系

第42页：类图综合画法

§6.2.2 类图：本页以图示方式给出类图中类、关联、依赖等元素的综合画法。

第43页：窗口类的继承与依赖示例

§6.2.2 类图：示例给出抽象类 Window{abstract}（含 toFront()、toBack()）派生出 X11 Window、Mac Window、Windows Window 三个子类，DetailAccount 对 Window 存在依赖关系。

第44页：接口与实现类示例

§6.2.2 类图：示例给出 Interface DataInput 与 DataInputStream、InputStream、OrderReader 之间的依赖与实现关系。

第45页：精化关系

§6.2.2 类图 —— 13. 精化（Refinement）：B 为 A 的精化，即 A、B 描述同一事物，B 在 A 的基础上有更详细的描述或实现细节。示例给出 InputStream{abstract}、DataInput《interface》、OrderReader、DataInputStream 之间的泛化、精化与依赖关系。

第46页：引用对象与值对象

§6.2.2 类图 —— 14. 引用对象和值对象：

• 概念层：不要区分引用对象与值对象
• 规范层与实现层：对构成使用值对象；属性可使用引用或值对象；其它关联一般使用引用对象

第47页：多值角色的多重性标注

§6.2.2 类图 —— 15. 多值角色：

• 如果有多个实例对象参与关联，UML 假定这些实例对象构成的集合无序且无重复
• 可使用 {ordered} 表示有序的实例对象集合
• {bag} 表示允许重复

第48页：参数化类

§6.2.2 类图 —— 17. 参数化类：

• 参数化类主要用来简化模型，简化实现，提高可重用性
• 避免在概念模型中使用参数化类
• 示例：模板类 Set（含 insert(T)、remove(T)）通过《bind》〈Employee〉绑定得到 EmployeeSet

第49页：类图的创建方法

§6.2.2 类图 —— 类图的创建方法：

• 根据项目所处的不同开发阶段，在不同的抽象层次上创建类图
• 仅当必要时，才使用较复杂的语法机制

第50页：对象图的概念

§6.2.3 对象图：

• 类图表示类和类与类之间的关系，对象图则表示在某一时刻这些类的具体实例和这些实例之间的具体连接关系
• 对象图可以看作类图的实例，帮助人们理解一个比较复杂的类图；也可用于显示类图中的对象在某一时刻的连接关系
• 对象的图示方式与类的图示方式几乎是一样的，主要差别在于对象的名字下面要加下划线

第51页：对象图的示例

§6.2.3 对象图：本页以图示方式给出对象图中对象及其连接的表示。

第52页：类图与对象图的对比

§6.2.3 对象图：本页对照展示同一结构在类图与对象图中的表示差异，对象名下方加下划线。

第53页：包图的概念与划分原则

§6.2.4 包（Package）图：

• 包类似于 OOA/OOD 中的主题词，用于结构化划分，分而治之
• 包的划分原则：强内聚，松耦合；根据依赖关系确定耦合度
• 包图的内容：包间依赖（如果包中的类之间存在依赖关系，则包间应存在依赖关系）；包间继承（专用包必须符合通用包的接口）；包的构成关系（包可由一些子包构成）

第54页：包图依赖示例

§6.2.4 包图：示例给出 Order Capture UI、Mailing List UI、Mailing List Application、Order Capture Application 等包，UI 包对 AWT 包存在依赖，应用包之间存在包依赖。

第55页：分层包图的示例

§6.2.4 包图：示例给出 Domain 层含 Order、Customer 包，Database Interface 层含 Sybase Interface、Oracle Interface 与 {abstract} Database Interface，Common 包含 Quantity、Money、DateRange 并以 {global} 标注。

第56页：包与接口

§6.2.4 包图：包也可以拥有接口，用于对外声明其提供的服务集合。

第57页：系统架构的概念

架构的概念：

• 系统架构是构成系统的各部分（结构、接口、通信机制）的框架性描述
• 通过定义一个合适的架构，使得更容易完成下述工作：浏览系统；找到一个特殊功能的位置或概念；标志加入一个新功能或概念的位置使其更适合总的系统架构
• 架构不仅要容易浏览、足够详细，而且还要具有可伸缩性，即能够从不同的级别上了解它

第58页：架构的分类

架构的分类：

• 可以用很多视图来描述架构，每一张视图集中描述系统的某一个方面
• 一个较广的分类方法将架构分解成逻辑和物理架构
• 逻辑架构主要指定系统的功能特点，通过系统的功能需求来描述
• 物理架构则描述系统的非功能部分，如可靠性、兼容性、资源使用和系统分布

第59页：逻辑架构

逻辑架构：

• 逻辑架构处理系统的功能，将功能分配到系统的各个部分，详细说明它们是如何工作的
• 逻辑架构包括应用逻辑，但不是将逻辑物理上分布到不同的进程、程序或计算机
• 逻辑架构有助于更清楚地了解系统的结构，使得更容易管理和协调工作（尽可能有效地利用人力开发资源）
• 并不是逻辑架构的所有部分都需要在工程中开发（如类库、二进制构件和模式只需购买）

第60页：逻辑架构解决的问题

逻辑架构解决下面的问题：

• 系统提供什么样的功能？
• 哪一个类存在，类之间是如何联系在一起？
• 类和对象是如何协作来完成系统功能？
• 什么是系统功能的时间约束？
• 许多开发人员在开发架构时都遵循的一个合适的计划是什么样？

第61页：UML中的逻辑架构元素

UML 中的逻辑架构由以下元素构成：用例、类、包、状态、活动、协作、序列。

第62页：物理架构

物理架构：

• 物理架构详细描述系统的软件、硬件
• 描述硬件结构，包括不同的节点以及节点间如何连接
• 说明实现逻辑架构中定义的概念的代码模块的物理结构和相关性
• 软件运行时进程程序和其它组件的分布
• 物理架构试图有效地利用软硬件资源

第63页：物理架构解决的问题

物理架构解决下面的问题：

• 类和对象物理上分布在哪一个程序或进程中？
• 程序和进程在哪台计算机上运行？
• 系统中有哪些计算机和其它的硬件设备？它们是如何连接在一起？
• 不同的代码文件之间有可关联？如果某一文件被改变，其它的文件是否需要重新编译？

物理架构描述软硬件的分解，将逻辑架构映射到物理架构，逻辑架构中的类和机制被映射到物理架构中的组件、进程和计算机；这种映射允许开发者根据逻辑架构中的类找到它的物理实现，反之亦然。

第64页：物理架构中的软件概念

物理架构 — 软件，描述软件的主要概念：

• 组件：在 UML 中，组件是指「在一组模型元素实例的物理打包时可重用的部分」
• 进程和线程：进程表示重量控制流，而线程则代表轻量控制流
• 对象

第65页：物理架构中的硬件概念

物理架构 — 硬件，物理架构中的硬件概念可以分为：

• 处理器：执行系统中的程序的计算机
• 设备：指的是支持设备，如打印机、路由器、读卡机等，它们一般被连接到控制它们的处理器上
• 连接：处理器之间有连接，处理器与设备之间也有连接。连接表示两个节点间的通信机制，可以用物理媒体（如光纤）和软件协议（如 TCP/IP）来描述

第66页：构件图的概念

§6.2.5 构件（Component）图：

• 构件图表示实现层的软件结构
• 构件：软件项目中的具有相对独立意义的单元（如源文件、二进制代码文件、DLL 等）
• 构件图用来显示编译、链接或执行时构件之间的依赖关系

第67页：软件构件的分类

§6.2.5 构件图 —— 软件构件可以是：

• 源构件：源构件只在编译时是有意义，典型情况下它是实现一个或多个类的源代码文件
• 二进制构件：典型情况下，二进制构件是对象代码，它是源构件的编译结果。它应该是一个对象代码文件、一个静态库文件或一个动态库文件
• 可执行构件：可执行构件是一个可执行的程序文件，它是链接（静态链接或动态链接）所有二进制构件所得到的结果

第68页：构件图的示例

§6.2.5 构件图：本页以图示方式给出构件及构件间依赖关系的表示。

第69页：编译时的构件

编译时的构件：

• 编译时的构件是包含工程中产生的代码的源构件
• 其它的构件，如链接时和运行时的构件是从编译时的构件中产生的
• 可被编译时的构件使用的某些版类为：《file》表示包含源代码的文件；《page》表示 Web 页；《document》表示文档
• 从一个编译时的组件到其它的编译时的构件的相关性显示了它需要其它的构件中的哪一个才能得到完整的定义

第70页：编译时构件画法

编译时的构件：本页以图示方式给出编译阶段源文件之间的依赖（编译依赖）关系。

第71页：链接时的构件

链接时的构件：

• 链接时组件用于链接系统时
• 典型情况下，链接时的组件代表编译时的组件所得到的结果，或表示编译一个或多个编译时的组件所得到的库
• 动态链接库（DLL）是一种特殊情况，它是在运行时而不是在编译时被链接到一个运行时的组件

第72页：运行时的构件

运行时的构件：

• 运行时的组件表示在执行系统时使用的组件
• 它是通过链接时的组件（从对象代码和库）产生的
• 版类《application》表示一个可执行的程序，版类《table》表示一个数据库表

第73页：配置图的概念

§6.2.6 配置（Deployment）图：

• 配置图描述系统硬件的物理拓扑结构以及在此结构上执行的构件
• 结点：物理设备以及在此结构上执行的构件
• 连接：结点间的通信及通信类型（通信协议，网络类型等）
• 配置图中的构件在逻辑上可对应包、类及对象，因此配置图将显示运行时刻包、类及对象在物理平台上的分布情况

第74页：配置图的示例

§6.2.6 配置图：本页以图示方式给出配置图中结点、连接以及构件在结点上的分布。

第75页：配置图中的结点

§6.2.6 配置图 —— 结点：

• 节点是拥有某些计算资源的物理对象（设备），这些资源包括带处理器的计算机，一些设备如打印机、读卡机、通信设备等
• 在查找或确定实现系统所需的硬件资源时标识这些节点，主要描述节点两方面的内容：能力（如基本内存、计算能力、二级存储器）；位置（在所有必须的地理位置上均可得到）
• 可以将节点作为类型（节点是一个类）和实例来显示，类型描述处理器或设备类型的特点，实例表示类型的真正出现（机器）

第76页：配置图中的连接

§6.2.6 配置图 —— 连接：

• 节点间通过通信关联连接在一起
• 通信关联用一条直线表示，说明在节点间存在某类通信路径，节点通过这条通信路径交换对象或发送消息
• 通信类型用版类来表示，定义通信协议或使用的网络

第77页：配置图连接画法

§6.2.6 配置图 —— 连接：本页以图示方式展示节点之间的通信关联及其通信类型标注。

第78页：构件在结点上的分配

§6.2.6 配置图：本页以图示方式展示构件在结点上的分配关系，说明运行时构件被部署到哪些物理节点。

第79页：6.3 UML动态建模机制 章节标题页

§6.3 UML 动态建模机制：本小节依次介绍顺序图、合作图、状态图与活动图，最后给出动态建模的方法建议。

第80页：顺序图的概念

§6.3.1 顺序（Sequence）图：顺序图和合作图统称为交互图。交互图通常描述单个用例中的行为。顺序图用来描述对象之间动态的交互关系，主要强调对象间消息传递的时间序及并发。

第81页：顺序图的构成元素

§6.3.1 顺序图：

• 顺序图的左边可带有描述信息，以阐明消息发送的时刻、动作执行情况及约束信息等
• 顺序图的 X 轴表示不同的对象，Y 轴表示时间；对象间的通信表示为对象生命线之间的消息传递
• 消息有简单、同步、异步之分；消息用消息名及参数标识；消息可带有条件表达式，以表示条件或分支
• 一个对象可通过发送消息来创建或删除另一对象；顺序图可显式表示对象生命的终结

第82页：顺序图的示例

§6.3.1 顺序图：本页以图示方式给出对象生命线、激活期与消息箭头的基本画法。

第83页：订单处理顺序图

§6.3.1 顺序图：示例给出订单录入窗口、订单、订单行、库存项、交付项、补货项之间的消息序列：Prepare() 触发 *[for all order lines] prepare()、hasStock:=check() 条件判断、[hasStock] remove() 自委托、[needsReorder] new 创建对象以及返回值。

第84页：并发顺序图的示例

§6.3.1 顺序图：示例给出事务（Transaction）与事务协调器、两个事务检查器之间的异步消息与激活期，展示对象自行删除（object deletes itself）与并发处理过程。

第85页：顺序图中的分支

§6.3.1 顺序图：本页以图示方式展示顺序图中由条件表达式产生的消息分支路径。

第86页：顺序图中的约束

§6.3.1 顺序图：本页以图示方式展示顺序图中对消息时刻与执行区间附加的约束。

第87页：顺序图中的约束（续）

§6.3.1 顺序图：本页继续展示顺序图中的约束标注方式，包括时间间隔约束与控制焦点（激活期）的画法。

第88页：合作图的概念

§6.3.2 合作（Collaboration）图：合作图描述相互合作的对象间的交互和链接关系。

• 合作图中的消息可以编号，以表达它们之间的时序
• 如果对象在交互中被创建／删除，可在对象名后加 {new}／{destroy}
• 对象间的链接类似于类图中的关联（但没有多重性表示），链接关系包括构成链接、聚集链接、限定链接等
• 消息标于链接之上

第89页：合作图的示例

§6.3.2 合作图：本页以图示方式给出合作图中对象、链接与带序号消息的画法。

第90页：合作图与顺序图的对照

§6.3.2 合作图：本页以图示方式展示同一交互过程在合作图中的表达，便于与顺序图对照理解。

第91页：订单处理合作图

§6.3.2 合作图：示例给出订单录入窗口、订单、订单行、库存项、交付项、补货项之间的带序号消息序列：1:prepare()、2*[for all order lines]:prepare()、3:hasStock:=check()、4:[hasStock]:remove()、5:needsRecorder:=needToRecorder()、6[needsReorder]:new、7[hasStock]:new。

第92页：层次编号的合作图

§6.3.2 合作图：示例给出用小数编号表达嵌套层次的合作图，如 1:prepare()、1.1*[for all order lines]:prepare()、1.1.1:hasStock:=check()、1.1.2:[hasStock]:remove()、1.1.2.1:needsRecorder:=needToRecorder()、1.1.2.2[needsReorder]:new、1.1.3:[hasStock]:new。

第93页：状态图的概念

§6.3.3 状态图：状态图刻划特定对象所有可能的状态及状态变迁。

• 结点：包含状态名与活动（Activity）。entry 活动：一旦对象进入该状态，相应的活动被触发执行；Exit 活动：一旦从该状态离去，相应的活动被触发执行；Do 活动：当对象位于该状态时，执行相应的活动，状态不变
• 状态转移：状态转移由事件触发；如果状态转移边上没有事件，那么当状态中的所有活动执行完成之后，自动立刻进行状态转移
• 状态转移动作（action）具有原子性，活动则不然

第94页：状态图的示例

§6.3.3 状态图：本页以图示方式给出状态结点、转移箭头与初始、终止状态的画法。

第95页：完成迁移

§6.3.3 状态图 —— 完成迁移：没有直接事件的状态转移，当每一个状态下的活动被实现时状态发生转移。

第96页：订单状态图的示例

§6.3.3 状态图：示例给出订单的 Waiting、Checking（do/check item）、Dispatching（do/initiate delivery）、Delivered、Cancelled 等状态，迁移条件包括 [Not all items checked]/get next item、[all items checked && all items available]、[All items checked && some items not in stock] 以及 Item Received 事件。

第97页：含超状态的状态图

§6.3.3 状态图：示例在订单状态图基础上给出 Active 超状态（Superstate），将 Checking、Dispatching 等子状态组合为复合状态。

第98页：状态图的结构化

§6.3.3 状态图 —— 状态图的结构化：

• 或关系：将子状态经「或」关系合成后得到 Superstate
• 与关系：用来描述对象中的并发状态变迁

第99页：并发状态图的示例

§6.3.3 状态图：示例给出含并发子状态的状态图，包括 Waiting、Checking、Authorizing、Authorized、Rejected、Dispatching、Delivered、Cancelled 等状态及其并发组合。

第100页：状态图综合示例

§6.3.3 状态图：本页以图示方式给出状态图的综合示例，展示状态、迁移、事件与动作的配合使用。

第101页：状态图中的事件说明

§6.3.3 状态图 —— 事件说明：本页说明状态图中事件的描述形式（事件名及参数）及其触发状态迁移的时机。

第102页：状态图中的守卫条件

§6.3.3 状态图 —— 守卫条件：本页说明守卫条件以方括号标注于迁移边之上，只有条件成立时该状态迁移才会发生。

第103页：状态图中的动作表达式

§6.3.3 状态图 —— 动作表达式：本页说明迁移发生时执行的动作表达式写法，动作具有原子性，通常紧跟在事件之后标注。

第104页：活动图的概念

§6.3.4 活动（Activity）图：活动图描述某一行为的动作过程（例如类的方法、用例、对象内部工作流程等）。

• 活动：在概念模型中，活动是某项任务或子任务；在规范和实现层，活动对应于类的方法
• 活动完成后由 Trigger 引发后续活动，Trigger 是活动图的边，Trigger 中可以包含条件
• 活动图用并发条（synchronization bar）表示并发和同步，多重 Trigger 也可以表示并发
• 对象可以出现在活动图中，作为活动的输入／输出，或表示对象与活动之间的相关性

第105页：冲咖啡活动图

§6.3.4 活动图：示例以冲咖啡过程给出活动图，包括 Find Beverage、Put Filter in Machine、Put Coffee in Filter、Add Water to Reservoir、Turn On Machine、Brew Coffee、Pour Coffee、Drink Beverage、Get Cups、Get can of Cola 等活动，以及 Decision、Guard [no coffee]、[found coffee]、[no cola]、[found cola] 与 Synchronization Bar。

第106页：活动图中的泳道

§6.3.4 活动图：Swimlanes 用来表示类／对象相对于活动图中各项活动的职责，将活动按承担者划分到不同泳道。

第107页：订单处理活动图

§6.3.4 活动图：示例给出订单处理活动图，含 Order Processing、Finance、Stock Manager 三条泳道，活动包括 Receive Order、Authorize Payment、Check Line Item、Assign to Order、Reorder Item、Dispatch Order、Add Remainder to Stock、Receive Supply、Cancel Order，并以 [failed]、[succeeded]、[in stock]、[need to reorder] 等条件分支。

第108页：活动图的逐级分解

§6.3.4 活动图：类似于 DFD，活动图可以逐级分解，需保持父子活动图之间的一致性。

第109页：活动图与商业建模

§6.3.4 活动图 —— 活动图与商业建模：

• 在商业建模时下列方面是模型要着重描述的：资源、规则、目的和动作（工作流）
• 有两类资源：物质和信息。工人（商业活动中的角色）就是资源的例子，他们是物理对象；其它的物理对象可能是生产的、消费的或处理的物品；信息对象通常是被信息系统处理的对象，信息对象携带与商务有关的信息
• 商务规则约束资源的使用，包括物品和信息
• 这些资源的使用是真正的工作，称为工作流

第110页：活动图与商业建模（续）

§6.3.4 活动图 —— 活动图与商业建模（续）：

• 商务的目的是推进工作流；在工作流中，根据指定的规则使用资源
• 在商业建模中有一点非常重要，即将物理对象和信息对象分开：物理对象是存在于现实世界中的对象（如汽车、客户和合同），信息对象承载与工作或物理对象有关的信息
• 当对象被处理、产生或消费时，对象的状态发生改变，可以用活动图来描述这些改变

第111页：商业建模活动图的示例

活动图与商业建模：本页以图示方式给出商业模型中资源、规则与工作流的活动图表示。

第112页：动态建模方法的选择

§6.3.5 动态建模方法：

• 不要对系统中所有类的对象绘制状态图，状态图只用于描述行为复杂的对象
• 顺序图和合作图适于描述单个用例中多个对象的行为
• 状态图适于描述跨越多个用例中单个对象的行为
• 活动图适于描述并发的、较复杂的行为

第113页：对UML的批评

对 UML 的批评：UML 在取得巨大成功的同时，也不断地受到批评。

• 来自工业界的批评主要是：它过于庞大和复杂，用户很难全面、熟练地掌握它，大多数用户实际上只使用它一少部分的概念；它的许多概念含义不清，使用户感到困惑
• 来自学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题

第114页：本章小结

本章小结：

• UML 集成众多 OO 软件开发方法的表示机制的优点，统一化、标准化、系统化；用宽谱语言机制支持软件开发全过程
• UML 的静态建模机制：用例图、类图、对象图、包图、构件图和配置图
• UML 的动态建模机制：顺序图、合作图、状态图、活动图