面向对象软件工程实践指南 第3章统一建模语言UML 面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮。 从1989年到1994年，其数量从不到十种增加到了五十多种。Booch86,GOOD(通用面向对 象的开发)，HOOD(层次式面向对象的设计)、OOSD(面向对象的结构设计)等一批OOD (面向对象的设计或面向对象的开发)相继出现。 在面向对象方法学的应用与推广的过程中，急需要采用统一的方式进行相关概念和方 案的表达。在此过程中，UML(Unified Modeling Language)就应运而生了。UML得到了软 件行业的广泛认可，因此，己经成为标准的建模语言。 本章对UML进行了综述，在后续章节中，也将结合各个阶段的具体工作，进一步介绍 相关的UML模型。 3.1UML简介 3.1.1UML产生与发展 随着面向对象方法学的流行，截至1994年，公开发表并具有一定影响的OOA&D方法 己达50多种，Rational公司的G.Booch和J.Rumbaugh决定将他们各自的方法结合起来成为 一种方法，并于1995年10月发布了第一个版本，称作统一方法(Unified Method0.8)。OOSE 的作者L.Jacobson后来也加入了公司，于是也参加了统一行动，发布了第二个版本UML0.9。 鉴于统一行动的产物是一种建模语言，而不是一种建模方法，因此称为统一建模语言(UML, Unified Modeling Language)。在此过程中，Rational公司发起成立了UML伙伴组织，开始 时有12家公司参加，共同推出了UML1.0版，并在1997年1月提交给对象管理联盟(Object Management Group,OMG),其他几家分头向OMG提交提案的公司纳入进来后，1997年 11月推出了UMLl.1版。UML不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而 且对其作了进一步的发展，支持面向对象的技术和方法，并最终统一为大众所接受的标准建 模语言。 UML还在继续发展之中，UML2.4.1被国际标准化组织ISO接纳为2012年的新标准。 目前UML的最新版本已经到2.5。 3.1.2UML是什么 UML是为软件系统的制品进行描述(specifying)、可视化(visualizing)、构造 (constructing)、文档化(documenting)的一种语言。它同样适用于商业模块和其他非软件 系统。在大型和复杂系统的建模中，UML成功地描述了一些优秀的工程实施。UML是OOAD 最主要的工具。 22
面向对象软件工程实践指南 22 第 3 章 统一建模语言 UML 面向对象的分析与设计(OOA＆D)方法的发展在 80 年代末至 90 年代中出现了一个高潮。 从 1989 年到 1994 年，其数量从不到十种增加到了五十多种。Booch86, GOOD(通用面向对 象的开发)，HOOD(层次式面向对象的设计)、OOSD（面向对象的结构设计）等一批 OOD （面向对象的设计或面向对象的开发）相继出现。 在面向对象方法学的应用与推广的过程中，急需要采用统一的方式进行相关概念和方 案的表达。在此过程中，UML（Unified Modeling Language）就应运而生了。UML 得到了软 件行业的广泛认可，因此，已经成为标准的建模语言。 本章对 UML 进行了综述，在后续章节中，也将结合各个阶段的具体工作，进一步介绍 相关的 UML 模型。 3.1 UML 简介 3.1.1 UML 产生与发展 随着面向对象方法学的流行，截至 1994 年，公开发表并具有一定影响的 OOA&D 方法 已达 50 多种，Rational 公司的 G.Booch 和 J.Rumbaugh 决定将他们各自的方法结合起来成为 一种方法，并于 1995 年 10 月发布了第一个版本，称作统一方法（Unified Method 0.8）。OOSE 的作者 I. Jacobson 后来也加入了公司，于是也参加了统一行动，发布了第二个版本 UML0.9。 鉴于统一行动的产物是一种建模语言，而不是一种建模方法，因此称为统一建模语言（UML， Unified Modeling Language）。在此过程中，Rational 公司发起成立了 UML 伙伴组织，开始 时有 12 家公司参加，共同推出了 UML1.0 版，并在 1997 年 1 月提交给对象管理联盟（Object Management Group，OMG），其他几家分头向 OMG 提交提案的公司纳入进来后，1997 年 11 月推出了 UML1.1 版。UML 不仅统一了 Booch、Rumbaugh 和 Jacobson 的表示方法，而 且对其作了进一步的发展，支持面向对象的技术和方法，并最终统一为大众所接受的标准建 模语言。 UML 还在继续发展之中，UML2.4.1 被国际标准化组织 ISO 接纳为 2012 年的新标准。 目前 UML 的最新版本已经到 2.5。 3.1.2 UML 是什么 UML 是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造 （constructing）、文档化（documenting）的一种语言。它同样适用于商业模块和其他非软件 系统。在大型和复杂系统的建模中，UML 成功地描述了一些优秀的工程实施。UML 是 OOAD 最主要的工具
面向对象软件工程实践指南 3.2UML与软件体系结构 3.2.1软件体系结构 为了可以更好的表达不同的软件开发人员在软件开发周期的不同时期看待软件产品的 不同侧重面，需要对模型进行分层。UML根据软件产品的体系结构(architecture)对软件进 行分层。 软件体系结构包含如下内容： (1)软件系统的组织： (2) 构成软件系统的结构元素的结构及它们之间的接口： (3)结构元素的行为及元素之间的协同(collaboration): (4)结构元素不断组合以构成日渐完备的子系统的过程： (5)指导软件建造过程的软件构筑风格(architectural style)以及静态和动态元素之 间的接口、协同、构成(composition)。 软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的用途、功能、性能、应 变性(resilience)、可重用性、经济和技术方面的限制和折衷，以及美学考虑(aesthetic concern)。 3.2.2UML五大视图 UML将软件的体系结构分解为五个不同的侧面，称为视图(view)。如图3-1所示，五 个视图分别是用例视图(use case view)、设计视图(design view以进程视图(process view)、 实现视图(implementation view)、部署视图(deployment view)。其中设计视图和进程视图又可 被统一称为逻辑视图logical view)。 每个视图分别关注软件开发的某一侧面。视图由一种或多种模型图(diagram)构成。模 型图描述了构成相应视图的基本模型元素(element)及它们之间的相互关系。 设计词汇、功能描述 系统组装、配置管理 设计视图 实现视图 动态行为 用例视图 进程视图 部署视图 性能、稳定、吞吐率 系统拓扑、分布、分发、安装 图3-1软件体系结构的五种视图 23
面向对象软件工程实践指南 23 3.2 UML 与软件体系结构 3.2.1 软件体系结构 为了可以更好的表达不同的软件开发人员在软件开发周期的不同时期看待软件产品的 不同侧重面, 需要对模型进行分层。UML 根据软件产品的体系结构（architecture）对软件进 行分层。 软件体系结构包含如下内容： （1） 软件系统的组织； （2） 构成软件系统的结构元素的结构及它们之间的接口； （3） 结构元素的行为及元素之间的协同（collaboration）； （4） 结构元素不断组合以构成日渐完备的子系统的过程； （5） 指导软件建造过程的软件构筑风格（architectural style）以及静态和动态元素之 间的接口、协同、构成（composition）。 软件体系结构不仅仅决定软件的结构和行为，而且还决定软件的用途、功能、性能、应 变性(resilience)、可重用性、经济和技术方面的限制和折衷，以及美学考虑（aesthetic concern）。 3.2.2 UML 五大视图 UML 将软件的体系结构分解为五个不同的侧面，称为视图(view)。如图 3-1 所示，五 个视图分别是用例视图（use case view）、设计视图(design view)、进程视图（process view）、 实现视图(implementation view)、部署视图(deployment view)。其中设计视图和进程视图又可 被统一称为逻辑视图(logical view)。 每个视图分别关注软件开发的某一侧面。视图由一种或多种模型图(diagram)构成。模 型图描述了构成相应视图的基本模型元素（element）及它们之间的相互关系。 设计视图 实现视图 进程视图 部署视图 动态行为 用例视图 设计词汇、功能描述 系统组装、配置管理 性能、稳定、吞吐率 系统拓扑、分布、分发、安装 图 3-1 软件体系结构的五种视图
面向对象软件工程实践指南 1.用例视图 用例视图(use case view)用来支持软件系统的需求分析，它定义了系统的边界，关注的 是系统的外部功能的描述。它从系统的使用者的角度，描述系统的外部的静态的功能和动态 行为。系统的动态行为可以由UML中的交互图(interaction diagram)、状态图(state-chart diagram)和活动图(activity diagram)三种模型图来描述。 2.逻辑视图 逻辑视图(logical view)包含设计视图和进程视图，其定义系统的实现逻辑，描述了为实 现用例图描述的功能以及在对软件系统进行设计时所产生的设计概念（又称软件系统的设计 词汇，vocabulary)。逻辑视图定义了设计词汇的逻辑结构、存在于它们之间的语义联系以及 设计词汇包括系统的类协同/接口及其关系。 对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的 电原理图。逻辑视图包含的模型图有：类图(class diagrams)、对象图(object diagrams)、 交互图(interaction diagrams)、状态图(state-chart diagrams)和话动图(activity diagrams)。 3.实现视图 当系统的逻辑结构在逻辑视图里被定义之后，需要定义逻辑结构的物理实现，比如设 计元素对应的源代码文件、各物理文件之间的关系、存放路径，等等。实现视图 (implementation view)就是定义这些内容的地方，它当于电子产品的印刷电路板的布线图。 实现视图描述组成一个软件系统的各个物理部件，这些部件以各种方式组合起来，（如：不 同的源代码经过编译，构成一个可执行系统：或者不同的软件组件配置成为一个可执行系统： 以及不同的网页文件以特定的目录结构组成一个网站，等等)构成了一个可实际运行的系统。 实现视图包含的模型图有：部件图(Component diagram)、交互图(Interaction Diagram)、 状态图(state-.chart diagram)和活动图(activity diagram)。 4.部署视图 软件产品将运行在计算机硬件系统上，如果软件产品是面向网络的应用系统，则有可能 同时运行在多个计算机上。部署视图(deployment view)用来描述软件产品在计算机硬件系统 和网络上的安装、分发(delivery)、分布(distribution)。在部署视图中，系统的静态特性可 以通过部署图(deployment diagram)来描述，动态特性的描述可以用交互图(interaction diagram)、状态图(state-chart diagram)和活动图(activity diagram)。 3.3UML的构成 作为UML的完整的概念模型，UML的构成包括其成员和建模规则，即： UML=UML成员+UML建模规则 UML的成员包含了模型元素(Model Element)、模型图(Diagram)和公共机制(Common 24
面向对象软件工程实践指南 24 1. 1.用例视图 用例视图(use case view)用来支持软件系统的需求分析，它定义了系统的边界，关注的 是系统的外部功能的描述。它从系统的使用者的角度，描述系统的外部的静态的功能和动态 行为。系统的动态行为可以由 UML 中的交互图(interaction diagram) 、状态图(state-chart diagram)和活动图(activity diagram)三种模型图来描述。 2. 逻辑视图 逻辑视图(logical view)包含设计视图和进程视图，其定义系统的实现逻辑, 描述了为实 现用例图描述的功能以及在对软件系统进行设计时所产生的设计概念（又称软件系统的设计 词汇，vocabulary）。逻辑视图定义了设计词汇的逻辑结构、存在于它们之间的语义联系以及 设计词汇包括系统的类/协同/接口及其关系。 对逻辑视图的描述在原则上与软件系统的实现平台无关。它相当于电子产品生产中的 电原理图。逻辑视图包含的模型图有：类图（class diagrams）、对象图（object diagrams）、 交互图（interaction diagrams）、状态图（state-chart diagrams）和活动图（activity diagrams）。 3. 实现视图 当系统的逻辑结构在逻辑视图里被定义之后， 需要定义逻辑结构的物理实现，比如设 计元素对应的源代码文件、各物理文件之间的关系、存放路径，等等。实现视图 (implementation view)就是定义这些内容的地方，它当于电子产品的印刷电路板的布线图。 实现视图描述组成一个软件系统的各个物理部件，这些部件以各种方式组合起来，（如：不 同的源代码经过编译，构成一个可执行系统；或者不同的软件组件配置成为一个可执行系统； 以及不同的网页文件以特定的目录结构组成一个网站，等等）构成了一个可实际运行的系统。 实现视图包含的模型图有：部件图（Component diagram）、交互图（Interaction Diagram）、 状态图（state-chart diagram）和活动图（activity diagram）。 4. 部署视图 软件产品将运行在计算机硬件系统上, 如果软件产品是面向网络的应用系统，则有可能 同时运行在多个计算机上。部署视图(deployment view)用来描述软件产品在计算机硬件系统 和网络上的安装、分发（delivery）、分布（distribution）。在部署视图中，系统的静态特性可 以通过部署图（deployment diagram）来描述，动态特性的描述可以用交互图（interaction diagram）、状态图（state-chart diagram）和活动图（activity diagram）。 3.3 UML 的构成 作为 UML 的完整的概念模型，UML 的构成包括其成员和建模规则，即： UML = UML 成员 + UML 建模规则 UML 的成员包含了模型元素(Model Element)、模型图(Diagram)和公共机制(Common
面向对象软件工程实践指南 Mechanism),即： UML成员=模型元素十模型图十公共机制 3.3.1UML模型元素 UML模型元素，类似于电子产品原理图里的集成电路符号，是模型图上包含的基本符 号。基本模型元素可分为四类，结构模型元素(structural element)、行为模型元素(behavioral element)、成组模型元素(grouping element)和注解元素(annotational element),即： UL模型元素=结构模型元素十行为模型元素十成组模型元素+注解元素 l.结构模型元素(structural element) 结构模型元素（基础包）是UML模型里的名词，是模型的静态组成部分，代表软件系 统的概念的、或物理的存在。例如：类是最常用的一个结构模型元素，代表一系列共享同样 的属性(attributes),操作(operation),关系和语义的对象(objects)。 UML模型的静态组成部分不是孤立存在的，它们被组合在一起互相协作以完成某项任 务。因此，结构模型元素之间存在着某种语义上的联系。在UML中，这种联系是关系 (relationship).UML中共有4种关系，它们是：关联关系(association)、依赖关系(dependency)、 泛化关系(generalization)和实现关系(realization)。 2.行为模型元素(behavioral element) 行为模型元素(behavioral element)(行为元素包)是UML模型的动态组成部分，它 是模型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类：交互 (interaction)和状态机(state machine)。 3.成组模型元素(grouping element) 在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决，这 就是分治原则。UML提供了支持分治原则的语言成份，即成组模型元素(grouping things)(模 型管理包)。成组模型元素只有一类，即模型包(package),模型包一个通用的手段，用来组 织多种语言成份，其中可包含：结构模型元素、行为模型元素和成组模型元素自身。模型包 是纯概念性的，只存在于软件系统的开发阶段。 4.注解元素(annotational element) 注解大量存在于机械图和电子线路图中，被用来标示产品的工艺要求等。UML中，也 存在着相似的语言成分，这就是注解元素(annotation things)。注解元素只有一种，即标注 (ote)。标注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明。 标注的图形表示是一个折了角的长方形，在长方形中写标注的内容。标注的内容可以是形式 的文本，或非形式的文本，甚至可以是图形。 25
面向对象软件工程实践指南 25 Mechanism)，即： UML 成员＝模型元素＋模型图＋公共机制 3.3.1 UML 模型元素 UML 模型元素，类似于电子产品原理图里的集成电路符号，是模型图上包含的基本符 号。基本模型元素可分为四类，结构模型元素（structural element）、行为模型元素（behavioral element）、成组模型元素（grouping element）和注解元素（annotational element），即： UML 模型元素＝结构模型元素＋行为模型元素＋成组模型元素＋注解元素 1. 结构模型元素（structural element） 结构模型元素（基础包）是 UML 模型里的名词，是模型的静态组成部分，代表软件系 统的概念的、或物理的存在。例如：类是最常用的一个结构模型元素，代表一系列共享同样 的属性（attributes），操作（operation），关系和语义的对象（objects）。 UML 模型的静态组成部分不是孤立存在的，它们被组合在一起互相协作以完成某项任 务。因此，结构模型元素之间存在着某种语义上的联系。在 UML 中，这种联系是关系 （relationship）。UML 中共有 4 种关系，它们是：关联关系（association）、依赖关系(dependency)、 泛化关系(generalization) 和实现关系(realization)。 2. 行为模型元素（behavioral element） 行为模型元素（behavioral element）（行为元素包）是 UML 模型的动态组成部分，它 是模型的动词，代表软件系统在空间和时间上的行为。行为模型元素包括两类: 交互 （interaction）和状态机（state machine）。 3. 成组模型元素（grouping element） 在为复杂的软件系统建模的时候，将大的问题分解为多个子问题分别描述和解决，这 就是分治原则。UML 提供了支持分治原则的语言成份，即成组模型元素(grouping things)（模 型管理包）。成组模型元素只有一类，即模型包（package），模型包一个通用的手段, 用来组 织多种语言成份，其中可包含：结构模型元素、行为模型元素和成组模型元素自身。模型包 是纯概念性的，只存在于软件系统的开发阶段。 4. 注解元素（annotational element） 注解大量存在于机械图和电子线路图中，被用来标示产品的工艺要求等。UML 中，也 存在着相似的语言成分，这就是注解元素（annotation things）。注解元素只有一种，即标注 （note）。标注用来描述施加于一个或多个模型元素的限制，或对模型元素的语义加以说明。 标注的图形表示是一个折了角的长方形，在长方形中写标注的内容。标注的内容可以是形式 的文本, 或非形式的文本，甚至可以是图形
面向对象软件工程实践指南 3.3.2UML模型图 UML基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图(diagram)。 在UML中，模型图是一组UML基本模型元素的图形表示，它通常由一组节点(UML基本 模型元素)，及节点之间的连线（关系）组成。一般地说，一个UML基本模型元素既可以 出现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现。 模型图可以表达软件系统体系结构的五个视图的内容，详细的模型图介绍见3.4和3.5章节。 3.3.3公共机制 在模型图上对UML成员进行描绘时，存在着共同的描绘方式，它们被称为UML公共 机制(UML common mechanism)。使用公共机制，可以使得建模的过程易于掌握，模型易 于被理解。公共机制可被分解为四个方面的内容：规格说明(Specification)、通用划分(Common Division)、修饰(Adornment)和扩展机制(Extensibility)。即： UML公共机制=规格说明+通用划分+修饰+扩展机制 1.规格说明 规格说明体现了UML规则的省略性原则。模型图可以省略某些不重要的内容，但是另 一方面，软件模型必须是完备的，以便于软件系统的建造，这就意味着此模型必须具备足够 的详细信息以供软件建造之用，这些构成一个完备模型的详细信息就是模型的规格说明 (specification)。所有UML模型元素都包含规格说明。在模型图上被省略的内容并不代表 它不存在于模型之中，模型的完整的或完备的信息是可以被保存在模型的规格说明中的。 2.通用划分 在面向对象的设计中，有许多事物可以划分为抽象的描绘(class)和具体的实例 (instance)。UML提供了事物的这种两分法(dichotomy)表达。几乎每种UML成员都有 这种类对象的两分法划分，通常对象和类使用同样的图符，在对象的名字下面加下划线以 示区别。还有一种两分法是接口和实现的两分法划分：接口定义了一种协议，实现是此协议 的具体实施方法。UML里这样的接口/实现两分法划分包括：接口/类或组件、用例和协同， 操作和方法。 3.修饰和扩展机制 UML提供了一系列的图形化的标准建模元素，可用于描述软件系统的大多数侧面的特 性。但也有可能在某些情形下，由于应用领域特殊性，标准的UML建模元素，无法完整而 准确地描述软件系统的分析和设计，这时，需要对UML的标准建模元素进行扩充，以提高 模型的表达能力。UML的修饰和扩展机制就是为这个目的而设置的。 标注是UML修饰机制的一个重要组成部分。当用UML的各种建模元素为软件系统建 模时，将遇到关于这些建模元素的复杂的语法、语义、原理、约束、注释等，这些内容对表 26
面向对象软件工程实践指南 26 3.3.2 UML 模型图 UML 基本模型元素及其关系必须通过某种载体表示，这种载体就是模型图（diagram）。 在 UML 中，模型图是一组 UML 基本模型元素的图形表示，它通常由一组节点（UML 基本 模型元素）, 及节点之间的连线（关系）组成。一般地说，一个 UML 基本模型元素既可以 出现在所有的模型图中，又可以出现在某些模型图中，甚至可以不在任何一个模型图上出现。 模型图可以表达软件系统体系结构的五个视图的内容, 详细的模型图介绍见 3.4 和 3.5 章节。 3.3.3 公共机制 在模型图上对 UML 成员进行描绘时，存在着共同的描绘方式，它们被称为 UML 公共 机制（UML common mechanism）。使用公共机制，可以使得建模的过程易于掌握，模型易 于被理解。公共机制可被分解为四个方面的内容：规格说明(Specification)、通用划分(Common Division)、修饰(Adornment)和扩展机制(Extensibility)。即： UML 公共机制＝规格说明＋通用划分＋修饰＋扩展机制 1. 规格说明 规格说明体现了 UML 规则的省略性原则。模型图可以省略某些不重要的内容，但是另 一方面，软件模型必须是完备的，以便于软件系统的建造，这就意味着此模型必须具备足够 的详细信息以供软件建造之用，这些构成一个完备模型的详细信息就是模型的规格说明 （specification）。所有 UML 模型元素都包含规格说明。在模型图上被省略的内容并不代表 它不存在于模型之中，模型的完整的或完备的信息是可以被保存在模型的规格说明中的。 2. 通用划分 在面向对象的设计中，有许多事物可以划分为抽象的描绘（class）和具体的实例 （instance）。UML 提供了事物的这种两分法（dichotomy）表达。几乎每种 UML 成员都有 这种类/对象的两分法划分，通常对象和类使用同样的图符，在对象的名字下面加下划线以 示区别。还有一种两分法是接口和实现的两分法划分：接口定义了一种协议，实现是此协议 的具体实施方法。UML 里这样的接口/实现两分法划分包括：接口/类或组件、用例和协同， 操作和方法。 3. 修饰和扩展机制 UML 提供了一系列的图形化的标准建模元素，可用于描述软件系统的大多数侧面的特 性。但也有可能在某些情形下，由于应用领域特殊性，标准的 UML 建模元素, 无法完整而 准确地描述软件系统的分析和设计, 这时，需要对 UML 的标准建模元素进行扩充, 以提高 模型的表达能力。UML 的修饰和扩展机制就是为这个目的而设置的。 标注是 UML 修饰机制的一个重要组成部分。当用 UML 的各种建模元素为软件系统建 模时，将遇到关于这些建模元素的复杂的语法、语义、原理、约束、注释等，这些内容对表