第三篇UML建模语言

UML的组成部分：
– 视图（views） – 图（Diagrams） – 模型元素（Model elements） – 通用机制（General mechanism）
8
软件设计模式
3.1.4 UML概述(2/5)——视图

视图只是表达系统某一方面特征的UML建模组件的子 集。在每一类视图中使用一种或两种特定的图来可视 化地表示系统中的各种概念。 用例视图 (Use-case view)：参与者(外部用户)所能观 察到的系统功能的模型图。 逻辑视图 (Logical view)：描述系统内部功能的设计 思路。 组件视图 (Component view)：显示代码组件的组织 方式，描述系统实现模块及模块间的依赖关系。 部署视图 (Deployment view)：表示系统的物理架构
17
软件设计模式
3.2.1用例图(5/7)——用例表示
<<extend>>
ATM
<<include>> <<include>> <<include>>
取款请求
查询
转账
取款
RMB 提款
美元提款
18
软件设计模式
3.2.1用例图(6/7)——用例描述

用例的描述本质上是一个关于参与者与系统进行交互的规格说 明。
用例的正常结束：指出用例的结束条件以及用例结束时对于参与 者的影响。
19
软件设计模式
3.2.1用例图(7/7)——测试用例

用于测试系统的正确性和有效性。正确性表明系统 的实现符合规格说明；有效性保证所开发的系统时 用户真正需要的系统。 有效性检查一般在系统开发之前进行。当用例构造 完成后，开发人员将所有用例交给用户进行讨论， 用户检查这些用例是否满足他们的要求。在有效性 检查过程中，往往会有双方理解的问题和用户新的 想法。开发方和用户最终达成共识。 用例也是系统测试的基本依据之一，测试人员据此 来测试系统是否达到预先设计的功能。随着测试技 术的发展，用例已成为自动测试的主要模型。

4
U M L 的 形 成 过 程
软件设计模式
3.1.3 什么是UML (1/2)

统一建模语言（UML）是一个通用的可视化建模语 言，用于对软件进行描述、可视化处理、构造和建立 软件系统的文档。 UML 适用于各种软件开发方法、软件生命周期的各 个阶段、各种应用领域以及各种开发工具，是一种总 结了以往建模技术的经验并吸收当今优秀成果的标准 建模方法。 UML不是程序设计语言，但可以使用代码生成器工 具将UML模型转换为多种程序设计语言代码，或使 用反向生成工具将程序源代码转换为UML。
用例的目标：明确用例的最终任务和想要得到的结果。
用例的激发：用例是怎样被激活的——每个用例的执行，都需要 某个参与者来启动，需要描述参与者启动用例的原因。
参与者与用例之间的消息：哪些消息是帮助用例作决定的，每个 消息所描述的问题，消息对系统实体的影响等。 用例的多种执行方案：某些用例在不同的条件下或特殊情况下， 能够选择合适的执行方案——这可以在动作的不同流程中予以描 述。


6
软件设计模式
3.1.3 什么是UML (2/2)

作为一种建模语言，UML的定义包括UML语义和 UML表示法两个部分。
– UML语义： 描述基于UML的精确元模型定义。元模型为 UML的所有元素在语法和语义上提供了简单、一致、通用的 定义性说明，使开发者能在语义上取得一致，消除了因人而 异的最佳表达方法所造成的影响。此外UML还支持对元模型 的扩展定义。 – UML表示法： 定义UML符号的表示法，为开发者或开发工 具在系统建模时使用这些图形符号和文本语法提供标准。这 些图形符号和文字所表达的是应用级的模型，在语义上它是 UML元模型的实例。
9


软件设计模式
3.1.4 UML概述(3/5)——图

UML中的图由图片（graph）组成，图片是模型元素 的符号的有机组合体。 图表示了系统的一个特殊部分或者某个方面。在系统 中，包含有多个各种类型的图。 UML中包含了用例图、类图、对象图、状态图、顺序 图、协作图、活动图、组件图、部署图九种。 按照机制分类，UML的建模机制分为静态建模机制和 动态建模机制。
– 用例图、类图、对象图、组件图和部署图属于静态建模机制
– 状态图、顺序图、协作图和活动图属于动态建模机制
10
软件设计模式
3.1.4 UML概述(4/5)——模型元素

模型元素是在图中可以使用的所有概念。
模型元素在图中用相应的符号表示。
利用视图元素可以把图形象并且直观地表示出来。 一个符号可以在多个不同类型的图中出现。
15
软件设计模式
3.2.1用例图(3/7)——用例

用例是外部可见的一个系统功能单元，这些功能由系 统单元所提供，并通过一系列系统单元与一个或多个 参与者之间交换的消息来表达。 用例的特征：
– 用例由参与者初始化：用例所代表的功能必须由参与者发起 ，用例才得以执行；参与者需要系统完成的功能，都是通过 用例具体完成的。 – 用例为参与者提供值：用例必须为参与者提供具体的并且能 被参与者识别的值。 – 用例具有完全性：只有返回了最终提供给用户的值后，整个 用例才执行完毕。
订单追踪
监督人员
13
软件设计模式
3.2.1用例图(1/7)——系统

系统是用例模型的一个组成部分，代表某个活 动或者某个实体，而不是软件系统。系统的边 界用来说明所构建用例模型的应用范围。 例如，网络购物系统提供查看订单状态、订单 处理、发货、订单追踪功能，这些功能仅限于 该网络购物系统。 用例图中的系统用一个长方框来表示，系统名 一般写在方框上部。系统内部（方框内）是系 统中的用例。
14


软件设计模式
3.2.1用例图(2/7)——参与者

参与者是与系统、子系统或类发生交互作用的外部用户 、进程或其他系统。 一个用户可能对应多个参与者。不同的用户也可以只对 应于一个参与者，代表同一参与者的不同实例。 每个参与者可以参与一个或多个用例，通过交换信息与 用例发生交互作用。 参与者可以是人、另一个计算机系统或一些可以运行的 进程。 参与者用小人图形表示。
20

wk.baidu.com
软件设计模式
3.2.2 顺序图(1/4)

对象间的相互作用体现了对象的行为。这种相互作用可以 描述成两种互补的方式，一种以独立的对象为中心进行考 察，另一种以互相作用的一组对象为中心进行考察。

为了描述一组对象的整体行为，UML采用对象间协作关系 模型—交互视图来表达。协作包括结构和行为两个方面， 结构方面包含一个角色集合和它们之间的关系；行为方面 是一个消息集合，这些消息在对象之间进行传递。



22
软件设计模式
3.2.2 顺序图(3/4)——对象的建立和删除
23
软件设计模式
3.2.2 顺序图(4/4)——异步消息
: Actor
OrderClient
Server
CreditServer
1: InsertCard 2: InputDate 3: ChooseSeat 4: Select 5: Submit 6: IsValid 8: OrderOK 9: PrintTicket 7: authorize
第三章 UML建模语言
软件设计模式
3.1 UML简介

同传统的面向过程的软件工程相比，面向对象 的软件工程在需求的获取、系统分析、设计和 实现方面存在很大区别。 然而，过去数十种面向对象的建模语言都是相 互独立的，使得设计跟用户需求之间存在一些 潜在的不必要的差异，混淆用户的真实目的。 需要统一的、易理解的工具来对整个软件开发 过程进行描述。
消息是两个对象之间的单路通信，从发送者到接受者的控 制信息流。消息具有用于在对象间传值的参数，可以是信 号（一种明确的、命名的、对象间的异步通信）或调用（ 具有返回控制机制的操作的同步调用）。 消息可用两种图来表示：顺序图和协作图。
21


软件设计模式
3.2.2 顺序图(2/4)

顺序图也称为时序图，描述系统中对象间通过消息进行的交互 ，强调消息在时间轴上的先后顺序。 顺序图的作用：顺序图常用来描述用例的实现，它表明了由哪 些对象，通过消息相互协作来实现用例的功能，在顺序图中， 标识了消息发生交互的先后顺序。 顺序图中的水平轴表示不同的对象，垂直轴表示时间。顺序图 中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和 类名。垂直虚线是对象的生命线，用于表示某段时间内对象是 存在的。对象间的通信用在对象的生命线间画消息来表示。 一个对象可以通过发送消息来创建另一个对象，当一个对象被 删除或自我删除时，用“X”标识。


笔记可以描述模型元素无法表示的信息，通常在需 要用较多的文字来说明某个特征时使用，笔记可以 放在图的任何位置。
12
软件设计模式
3.2 经常使用的模型 3.2.1用例图

用例位于系统边界内部，用椭圆形表示，名字写在椭圆下方，用 例和参与者之间用一条直线表示。
网上购物系统
订单状态检查 销售员
顾客
订单处理 货运 发货
7
软件设计模式
3.1.4 UML概述(1/5)

统一建模语言（UML）的应用领域十分广泛，可以用于商业 建模（business modeling）、软件开发过程中的各个阶段建 模等。

它是一种通用的建模语言，可以对系统进行全方位的建模， 包含系统的静态结构模型、动态行为模型等多种结构模型。
UML语言本身比较通俗易懂，具有可扩展性和通用性。


2
软件设计模式
3.1.1 面向对象的开发方法

利用传统程序设计语言的软件开发方法出现于 20 世 纪 70 年代，在 80 年代被广泛采用 —— 其中最重要的 是结构化分析和设计方法及其变体。 1967年Simula-67是第一个面向对象的程序设计语言 ，但它没有后继的版本。 80 年代初，面向对象的程序设计语言 Smalltalk 被广 泛使用，随之诞生了Objective C、C++等语言。



Smalltalk出现5年后，出现第一批介绍面向对象软件 开发方法的书籍，第一阶段在1990年末完成。
在以后的5年中，大批面向对象的书籍问世，各有一 套概念、定义、表示法、术语和适用的开发过程。
3
软件设计模式
3.1.2 UML的发展

从二十世纪八十年代初期开始，众多的方法学家都在尝试用不同的方 法进行面向对象的分析与设计。但是：


常见的模型元素包括对象、类、包、结点、状态、 组件等。
模型元素与模型元素之间的关系也是模型元素，比 如关联、依赖、聚合、泛化等。
11
软件设计模式
3.1.4 UML概述(5/5)——通用机制

在建模过程中，某些信息无法通过基本模型元素来 表示。UML利用通用机制为图添加附加信息，通常用 的通用机制有修饰、笔记、规格说明。 为了使建模者能很好地区分开类型和实例，通常利 用修饰为模型元素附加一定语义。修饰的位置一般 紧靠着模型元素。
– 建模语言各有千秋。
– 用户往往并不了解不同建模语言的优缺点及差异，因而很难根据应用特点选 择合适的建模语言。 – 不同的建模语言大多雷同，但仍存在细微差别，妨碍了用户之间的交流。

Booch、Rumbaugh和Jacobson三人共同努力，在比较不同建模语言优 缺点及总结面向对象技术应用的基础上，于1996年6月和10月发布 UML0.9和UML0.91。 1997年1月，UML1.0被提交给OMG组织，作为软件建模语言标准化的 候选，很多著名软件公司积极使用UML并提出反馈意见。 1997年9月再次提交给OMG组织，1997年11月7日被OMG采纳为业界 标准。

16
软件设计模式
3.2.1用例图(4/7)——用例表示

用例之间存在包含、扩展和泛化关系：
包含：一个用例可以简单地包含其它用例具有的行为，并把它所包 含的用例行为作为自身行为的一部分。包含用含有<<include>>的带 箭头的虚线表示，箭头指向被包含的用例。 扩展：一个用例也可以被定义为基用例的增量扩展。同一个基用例 的几个扩展用例可以在一起应用，扩展增加了原有的语义。扩展关 系可以用含有关键字<<extend>>的带箭头的虚线表示，关系箭头指 向被扩展的用例。 泛化：一个用例可以被特别列举为一个或多个子用例，这被称为用 例泛化。当父用例能够被使用时，任何子用例也可以被使用。用例 泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指 向父用例。