本篇文章介绍UML的相关知识。参考《UML从入门到精通》

一、UML综述

1. UML简介

统一建模语言（UML）是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。UML描述了一个系统的静态结构和动态行为。 UML将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定功能的模型结构。静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。从不同但相互联系的角度对系统建立的模型可用于不同的目的。UML不是一门程序设计语言，但可以使用代码生成器工具将 U M L模型转换为多种程序设计语言代码，或使用反向生成工具将程序源代码转换为UML。

2. UML的目标

UML语言的开发有多个目标。首先，最重要的目标是使 U M L成为一个通用的建模语言，可供所有建模者使用。其次，我们希望UML 尽可能地采用源自OMT Booch, Objectory及其他主要方法的表示法，即使它能够很好地支持设计工作，如封装、分块、记录模型构造思路。此外，我们希望UML能准确表达当前软件开发中的热点问题，比如大规模、分布、并发、方式和团体开发等。

二、模型的性质与用途

1. 什么是模型

软件系统的模型用建模语言来表达，如UML。模型包含语义信息和表示法，可以采取图形和文字等多种不同形式。建立模型的目的是因为在某些用途中模型使用起来比操纵实物更容易和方便。

2. 模型的用途

软件系统的不同模型可以捕获关于这个软件的应用领域、使用方法、度量手段和构造模式等方面的需求信息。在编写程序代码以前，软件系统的模型可以帮助软件开发人员方便地研究软件的多种构架和设计方案。软件系统的一类模型可以说明这个系统的外部行为和系统中对应于真实世界的有关信息，另一类模型可以展示系统中的类以及实现系统外部行为特性所需要的内部操作。实现这些行为有多种方法。利用软件系统的模型，可以获得类的声明、过程体、用户界面、数据库、合法使用的说明、配置草案以及与其他单位技术竞争情况的对比说明。软件系统用视图来组织信息：静态结构视图、状态机视图、交互视图、反映需求的视图等等。

三、UML初览

本章使用的例子是计算机管理的戏院售票系统。

1. UML视图

在最上一层，视图被划分成三个视图域：结构分类、动态行为和模型管理。

UML视图和图

不同视图元素间的部分关系

四、静态视图

1. 概述

静态视图是UML的基础。模型中静态视图的元素是应用中有意义的概念，这些概念包括真实世界中的概念、抽象的概念、实现方面的概念和计算机领域的概念，即系统中的各种概念。

静态视图说明了对象的结构。一个面向对象的系统使数据结构和行为特征统一到一个独立的对象结构中。静态视图包括所有的传统数据结构思想，同时也包括了数据操作的组织。数据和操作都可量化为类。

静态视图将行为实体描述成离散的模型元素，但是不包括它们动态行为的细节。静态视图将这些行为实体看作是将被类所指定、拥有并使用的物体。

静态视图中的关键元素是类元及它们之间的关系。类元是描述事物的建模元素。有几种类元，包括类、接口和数据类型。包括用例和信号在内的其他类元具体化了行为方面的事物。实现目的位于像子系统、构件和节点这几种类元之后。

对象是从建模者理解和构造的系统中分离出来的离散单元。它是类的实例—即，它是一个其结构和行为都由类来描述的具有身份的个体。对象是一个可识别的状态，该状态的行为能被激发。

类元之间的关系有关联、泛化及各种不同的依赖关系，包括实现和使用关系。

2. 类元

3. 关系

类元之间的关系有关联、泛化、流及各种形式的依赖关系，包括实现关系和使用关系。

关联关系描述了给定类的单独对象之间语义上的连接。关联提供了不同类间对象可以相互作用的连接。其余的关系涉及到类元自身的描述，而不是它们的实例。

泛化关系使父类元（超类）与更具体的后代类元（子类）连接在一起。泛化有利于类元的描述，可以不用多余的声明，每个声明都需加上从其父类继承来的描述。继承机制利用泛化关系的附加描述构造了完整的类元描述。泛化和继承允许不同的类元分享属性、操作和它们共有的关系，而不用重复说明。

实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类之中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。

流关系将一个对象的两个版本以连续的方式连接起来。它表示一个对象的值、状态和位置的转换。流关系可以将类元角色在一次相互作用中连接起来。流的种类包括变成（同一个对象的不同版本）和拷贝（从现有对象创造出一个新的对象）两种。

依赖关系将行为和实现与影响其他类的类联系起来。除了实现关系以外，还有好几种依赖关系，包括跟踪关系（不同模型中元素之间的一种松散连接） 、精化关系（两个不同层次意义之间的一种映射） 、使用关系（在模型中需要另一个元素的存在） 、绑定关系（为模板参数指定值） 。使用依赖关系经常被用来表示具体实现间的关系，如代码层实现关系。在概括模型的组织单元，例如包时，依赖关系很有用，它在其上显示了系统的构架。例如编译方面的约束可通过依赖关系来表示。

4. 关联

在关联中如果同一个类出现不止一次，那么一个单独的对象就可以与自己关联。

一个类的关联的任何一个连接点都叫做关联端，与类有关的许多信息都附在它的端点上。关联端有名字（角色名）和可见性等特性，而最重要的特性则是多重性，即一个类的多个实例与另一个类的一个实例相关。

如果一个关联既是类又是关联，即它是一个关联类，那么这个关联可以有它自己的属性。

如果一个关联的属性在一组相关对象中是唯一的，那么它是一个限定符，限定符是用来在关联中从一组相关对象中标识出独特对象的值。

聚集和组成。聚集表示部分与整体关系的关联，它用端点带有空菱形的线段表示，空菱形与聚集类相连接。组成是更强形式的关联，整体有管理部分的特有的职责，它用一个实菱形物附在组成端表示。

5. 泛化

泛化关系是类元的一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并对其进行了扩展。泛化用从子指向父的箭头表示，指向父的是一个空三角形。

泛化的用途。泛化有两个用途。第一个用途是用来定义下列情况：当一个变量（如参数或过程变量）被声明承载某个给定类的值时，可使用类（或其他元素）的实例作为值，这被称作可替代性原则（由 Barbara Liskov提出）；泛化的另一个用途是在共享祖先所定义的成分的前提下允许它自身定义增加的描述，这被称作继承。继承是一种机制，通过该机制类的对象的描述从类及其祖先的声明部分聚集起来。继承允许描述的共享部分只被声明一次而可以被许多类所共享，而不是在每个类中重复声明并使用它，这种共享机制减小了模型的规模。

6. 实现

实现关系将一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说明而不是结构或者实现。实现关系用一条带封闭空箭头的虚线来表示。

7. 依赖

依赖表示两个或多个模型元素之间语义上的关系。根据这个定义，关联和泛化都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。

依赖用一个从客户指向提供者的虚箭头表示：

8. 约束

约束用大括弧内的文字表达式来表示，可以使用形式语言或自然语言。文字字符串可以写成注释或附加在依赖关系的箭头旁。

五、用例视图

1. 概述

当用例视图在外部用户前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者(即系统的理想用户)有用的需求。而交互功能部分被称作用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交互作用。参与者可以是人,也可以是外部计算机系统和外部进程。

2. 参与者

参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的理想化概念。每个参与者可以参与一个或多个用例。参与者可以是人、另一个计算机系统或一些可运行的进程。

3. 用例

用例是外部可见的一个系统功能单元 ,这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例除了与其参与者发生关联外，还可以参与系统中的多个关系：

一个用例也可以被定义为基用例的增量扩展 ,这叫做扩展关系。同一个基用例的几个扩展用例可以在一起应用。基用例的扩展增加了原有的语义 , 此时是基用例而不是扩展用例被作为例子使用。

包含和扩展关系可以用含有关键字《 i n c l u d e》和《e x t e n d》的带箭头的虚线表示。包括用例关系箭头指向被包含的用例，扩展关系箭头指向被扩展的用例。

一个用例也可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。用例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指向父用例。

六、状态机视图

1. 概述

状态机视图通过对类对象的生存周期建立模型来描述对象随时间变化的动态行为。状态是给定类的对象的一组属性值 ,这组属性值对所发生的事件具有相同性质的反应。状态机用于描述类的行为，但它们也描述用例、协作和方法的动态行为。

2. 状态机

状态机是展示状态与状态转换的图。通常一个状态机依附于一个类，并且描述一个类的实例对接受到的事件所发生的反应。状态机也可以依附于操作、用例和协作并描述它们的执行过程。

3. 事件

事件是发生在时间和空间上的一点的值得注意的事情。它在时间上的一点发生，没有持续时间。如果某一事情的发生造成了影响，那么在状态机模型中它是一个事件。

4. 状态

状态描述了一个类对象生命期中的一个时间段。它可以用三种附加方式说明：在某些方面性质相似的一组对象值；一个对象等待一些事件发生时的一段时间；对象执行持续活动时的一段时间。状态用具有圆形拐角的矩形表示。

5. 转换

动作。当转换被引起时，它对应的动作被执行。动作是原子性的，一般是一个简短的计算处理过程，通常是一个赋值操作或算术计算。

6. 组成状态

一个简单状态没有子结构，只带有一组转换和可能的入口和出口动作。组成状态是一个被分解成顺序的或并发的子状态的状态。

七、活动视图

1. 概述

活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模。活动图中的状态表示计算过程中所处的各种状态，而不是普通对象的状态。

2. 活动图

活动图是活动视图的表示法。

泳道。将模型中的活动按照职责组织起来通常很有用。对象流。活动图能表示对象的值流和控制流。对象流状态表示活动中输入或输出的对象。如下图：

八、交互视图

1. 概述

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

2. 顺序图

顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示；当对象的过程处于激活状态时，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

3. 协作图

协作图是一种类图，它包含类元角色和关联角色，而不仅仅是类元和关联。可以将对象标识成四个组：存在于整个交互作用中的对象；在交互作用中创建的对象（使用约束{ n e w }）；在交互作用中销毁的对象（使用约束 { d e s t r o y e d }）；在交互作用中创建并销毁的对象（使用约束 { t r a n s i e n t }） 。设计时可以首先表示操作开始时可得的对象和连接，然后决定控制如何流向图中正确的对象去实现操作。

九、物理视图

1. 概述

系统模型的大部分内容反映了系统的逻辑和设计方面的信息，并且独立于系统的最终实现单元。然而，为了可重用性和可操作性的目的，系统实现方面的信息也很重要。UML使用两种视图来表示实现单元：实现视图和部署视图。实现视图将系统中可重用的块包装成具有可替代性的物理单元，这些单元被称为构件。部署视图表示运行时的计算资源（如计算机及它们之间的连接）的物理布置。

2. 构件

构件用一边有两个小矩形的一个长方形表示，它可以用实线与代表构件接口的圆圈相连。

构件图表示了构件之间的依赖关系。每个构件实现（支持）一些接口，并使用另一些接口。如果构件间的依赖关系与接口有关，那么构件可以被具有同样接口的其他构件替代。（构件图）

3. 节点

节点是表示计算资源的运行时的物理对象，通常具有内存和处理能力。节点可能具有用来辨别各种资源的构造型，如C P U、设备和内存等。节点可以包含对象和构件实例。（部署图）

十、模型管理视图

1. 概述

任何大的系统都必须被分成几个小的单元，这使得人们可以一次只处理有限的信息，并且分别处理这些信息的工作组之间不会互相干扰。模型管理由包及包之间的依赖关系组成。

2. 包

包是模型的一部分，模型的每一部分必须属于某个包。建模者可以将模型的内容分配到包中。但是为了使其能够工作，分配必须遵循一些合理的原则，如公用规则、紧密耦合的实现和公用观点等。U M L对如何组包并不强制使用什么规则，但是良好的解组会很大地增强模型的可维护性。

3. 包间的依赖关系

十一、扩展机制

1. 概述

UML提供了几种扩展机制。包括约束、标记值和构造型。一定要记住扩展是违反UML的标准形式的，并且使用它们会导致相互影响。在使用扩展机制之前，建模者应该仔细权衡它的好处和代价，特别是当现有机制能够合理工作时。

2. 约束

约束用大括弧内的字符串表达式表示。约束可以附加在表元素、依赖关系或注释上。

3. 标记值

标记值是一对字符串—一个标记字符串和一个值字符串—存储着有关元素的一些信息。标记值用字符串表示，字符串有标记名、等号和值。它们被规则地放置在大括弧内。

4. 构造型

构造型是在一个已定义的模型元素的基础上构造的一种新的模型元素。构造型的信息内容和形式与已存在的基本模型元素相同，但是含义和使用不同。