UML建模

一．建模概述

建模的重要性：

建模是开发优秀软件的所有活动中的核心部分，其目的是把所要设计的结构和系统的行为沟通起来．并对系统的体系结构进行可视化和控制。建模是为了更好地理解正在构造的系统，并经常提供简化和复用的机会，同时建模还可以管理风险。

不成功的软件项目失败败原因各不相同，而所有成功的项目的成功原因在很多方面都是相似的：一个成功的软件组织有很多成功的因素，其中共同的一点就是对建摸的采用。

建模是一项经过检验并被广为接受的工程技术：我们建立的房屋和大厦的建筑模型能帮助用户得到实际建筑物的印象：为了分析大风或地震对建筑物造成的影响，我们甚至可以建立数学模型。

人对复杂问题的理解能力是有限的、通过建模，缩小所研究问题的范围。一次只着重研究它的一个方面。这就是Edsger Dijkstra几年前讲的“各个击破”的基本方法，即先把一个要解决的难题划分成一系列小问题，解决了这些小问题也就解决了这个难题。此外，通过建模可以增强人的智力，一个适当选择的模型可以使建模人员在较高的抽象层次上工作。

各种工程学科部有其丰富的建模使用历史。这些经验形成了建模的四项基本原理，分别叙述如下:

第一，选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响。

第二，每一种模型可以在不同的精度级别上表示。

第三，最好的模型是与现实相联系的。

对软件领域的结构化分析的致命的缺点就是分析模型与系统设计模型没有基本的联系。

第四，单个模型是不充分的。对几个重要的系统最好用一组几乎独立的模型去处理。

根据系统的性质．一些模型可能比另一些模型要重要，例如，对于数据密集型系统．表达静态设计视图的模型将占主导地位；对于图形用尸接口密集型系统，静态和动态用况视图就显得相当重要；在实时系统中，动态进程视图尤为重要；在分布式系统中，例如web密集型的应用，实现模型和实施模型是最重要的。

建模的种类

对于软件，有几种建模的方法：最普遍的两种方法是从算法的角度建模和面向对象的角度建模。

传统的软件开发是从算法的角度进行建模，所有的软件都用过程或函数作为其主要构造块。这种观点导致开发人员把精力集中在控制流程和对大的算法进行分解上。除了用这种方法建立的模型是瞻弱的之外，采用这种方法没有其他本质上的坏处．当需求发生变化以及系统增长时，用这种方法建造的系统就变得难以维护。

现代的软件开发采用面向对象的角度进行建模，所有软件系统采用对象或类作为其主要构造块。简单地讲，通常要从问题空间或解空间的词汇中找出对象：类是讨具确共同性质的一组对象的描述。每一个对象都有标识(你能够对它命名，以区别于其他付象)，状态(通常有一些数据与它相联系)和行为(使你能够该对象做某些事，它也能为其他对象做某些事)。

对面向对象系统进行可视化、详述、构造和文档化正是统一建模语言UML的目的。

二、UML概述

UML仅仅是一种用于构件软件蓝图的标准语言，并且仅仅是软件开发方法的一部分。UML是独立于过程的，但它贯穿于软件开发生命期，并能表达系统体系结构的各种不同视图，最好把它用于以用况为驱动，以体系结构为中心、迭代及增量的过程中。

像UML这样的语言的词汇表和规则可以告诉你如何创建或理解结构良好的模型，但它没有告诉你应该庄什么时候创建什么样的模型，因为这是软件开发过程的工作，一个定义明确的过程会绐出如下的指导：决定生产什么制品；由什么样的活动相人员来创建和管理这些制品；怎样采用这些制品从整体上去度量和控制项目。

UML不仅是一种可视化的、可用于详细描述的语言，还是一种构造语言，它虽然不是一种可视化的编程语言，但用UML描述的模型可与各种编程语育直接相连，这意味着一种可能性，即可把用UML描述的模型映射成编程语言，如Java：c++、和visuaI Basic等。甚至映射成关系数据库的表或面向对象数据库的永久存储。对一个事物，如果表示为图形方式最为恰当，则用UML，而如果表示为文字方式最为恰当，则用编程语言。这种映射允许进行正向工程：从UML模型到编程语言的代码生成，也可以进行逆向过程：由编程语言代码重新构造UML模型。逆向工程并不是魔术：除非你对实现中的信息编码，否则从模型到代码全丢失这些信息。逆向工程需要工具支持和人的干烦：把正向代码生成和逆向工程这两种方式结合起来就町以产生双向工程。这意味着既能在图形视图下工作，又能在文字视图下工作，这需要用工具来保持二者的一致性。

UML不限于对软件建摸。事实上，它的表达能力对非软件系统连摸也是足够的。例如，立法系统的工作流程，病人保健系统的结构和行为以及硬件设计等。

要学习UML，一个有效的出发点是形成下述语言的概念模型，这要求学习三个要素：（Brian Kernighan和Dennis Ritchie是编程语言c的作者，他们指出学习一门新的编程语言的唯一方法是用它编写程序，学习UML也是如此，学习UML的唯一方法是用它绘制模型）

u UML的基本构造块：

事物是对模型中最具有代表性的成分的抽象，关系把事物结合在一起，图聚集了相关的事物。

1. 事物

ü 结构事物（structrual thing）

它们通常是模型的静态部分，描述概念或物理元素，共有7种结构事物。这7种元素，即类．接口、协作、用况、主动类、构件和节点，是UML模型中可以包含的基本结构事物，它们也有变体，如参与者、信号、实用程序(一种类)、进程和线程(两种主动类)、应用、文档、文件、库、页和表(一种构件)等。

² 类（class）

² 接口（interface）

² 协作(collaboration)

² 用况（或成为用例 use-case）

² 主动类（active class）

是这样的类，其对象至少拥有一个进程或线程，因此它能够启动控制活动。主动类的对象所描述的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的-在图形上，主动类很像类，只是它的外框是粗线，通常它包含名称．属性和操作。

² 构件（component）

构件和节点是物理事物，前面五种是描述概念和逻辑事物。构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现。在一个系统中，你将遇到不同类型的部署构件,如COM+、构件和JavaBeans，以及在开发过程中所产生的制品构件，如源代码文件。通常构件是一个描述了一些逻辑元素(如类、接口和协作)的物理包。在图形上，把一个构件画成一个带有小方框的距形，通常在矩形中只写该构件的名称。

² 节点（node）

节点是在运行时存在的物理元素，它表示一种可计算的资源，它通常至少有一些记忆能力和处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点。在图形上，把一个节点画成一个立方体，通常在立方体中只写它的名称。

ü 行为事物（behavioral thing）

行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为，共有两类主要的行为事物：

² 交互（interaction）

它由在特定语境中共同完成一定任务的一组对象之间交换的消息组成，一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列(由一个消息所引起行为)和链(对象间的连接)。

² 状态机（status mechine）

它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间动作的行为可以用状态机来描述，一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）和事件(触发转换的事物和活动(对一个转换的响应)，在图形上把一个状态画成—个圆角矩形。通常在圆角矩形中含有状态的名称及其子状态。

ü 分组事物（grouping thing）

分组事物是UML模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包。包(package)是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件(仅在远行时存在)，它纯粹是概念上的，即它仅在开发时存在。在图形上，把一个包画成一个左上角带有一个小矩形的大矩形，在矩形中通常仅含有包的名称，有时还有内容。包是用来组织UML模型的基本分组事物：它也有变体，如框架．模型和子系统等(它们是包的不同种类)。

ü 注释事物（annotation thing）

是UM模型的解释部分，这些注释事物用来描述．说明和标注模型的任何元素。有一种主要的注释事物，称为注解，注解(note)是一个依附于一个元素或一组元素之上、对它进行约束或解释的简单符号、在图形上，把一个注解画成一个右上角是折角的矩形，其中带有文字或图形解释。

1. 关系

ü 依赖（dependency）

是两个事物间的语义关系，其中一个事物(独立事物)发生变化时会影响另一个事物(依赖事物)的语义。变体有精化、跟踪、包含和延伸。

ü 关联（association）

是一种结构关系．它描述了一组链。链是对象之间的连接。聚合是一种特殊类型的关联．它描述了整体和部分间的结构关系。在图形上，把一个关联画成一条实线，它可能有方向，偶尔在其上还有—个标记，而且它经常还含有诸如多重性和角色名这样的修饰。

ü 泛化（generalization）

它是特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素)的对象，用这种方法子元素共享父元素的结构和行为。

指向父元素

ü 实现（raalization）

它是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在按口和实现它们的类或构件之间；另一种是在用况和实现它们的协作之间。

1. 图（diagram）：UML包括9种图

ü 类图（class diagram）

类图表现了一组对象、接口、协作和它们之间的关系。在对面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图，包含主动类的类图给出系统的静态进程视图。

ü 对象图（object diagram）

对象图展观了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。

ü 用况图（use case diagram）

用况图展现了一组用况、参与昔(一种特定的类及其它们之间的关

系，用况图给出系统的静态用况视图。这些图对于系统的行为进行组织和建模是非常重要的。

ü 顺序图（sequence diagram）

ü 协作图（collaboration diagram）

顺序图和协作图都是交互图。交互图(interaction diagram)展现了一种交互。它由一组对象和它们之间的关系组成，包括在它们之间可能发送的消息。交互图专注于系统的动态视图。顺序图是一种强调消息的时间顺序的交互图；协作图也是一种交互图，它强凋收发消息的对象的结构组织。顺序图和协作图是同构的，这意崃着它们是可以相互转换的。

ü 状态图（statechart diagram）

状态图体现了一个状态机，它由状态、转换、事件和活动组成。状态图专注于系统的动态视图，它对于接口、类或协作的行为建模尤为重要，而且它强调对象行为的事件顺序，这非常有助于对反应式系统建模。

ü 活动图（activity diagram）

活动图是一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的过程。活动图专注于系统的动态视图、它对于系统的功能建模特别重要，并强调对象间的控制流程。

ü 构件图(component diagram)

构件图展现了一组构件之间的组织和依赖，构件图专注于系统的静态实现视图。它与类图相关，通常吧构件映射成一个或多个类。

ü 实施图（或部署图 deployment diagram）

实施图展现了对运行时处理节点以及其中的构件的配置。实施图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构件。

u 支配这些构造块如何放置在一起的规则

一个结构良好的摸型在语义上是前后一致的，并且与所有的相关模型协调一致，UML有用于描述如下事物的语义规则：

1. 命名为事物、关系和图起名

2. 范围给一个名称以特定含义的语境

3. 可见性怎样让其他人使用或看见名称

4. 完整性事物如何正确一致地相互联系

5. 执行运行或模拟动态模型的含义是什么

在软件密集型系统的开发期间所建造的模型往往需要发展变化的方式、在不同的时间进行观察。由于这个原因，下述的情况是常见的，一些结构良好的模型，也要建造一些这样的模型：

1. 省略隐藏某些元素以简化视图

2. 不完全性可以遗漏某些的元素

3. 不一致性不保证模型的完整性

随着系统细节的展开和变动，不可麿免地要出现这些不太规范的模型。UML的规则鼓励(不是强迫)你专注于最重要的分析、设计和实现问题，这些问题将促使模型随着时间的推移而具有良好的结构。

u 运用于整个语言的一些公共机制。

由于在UML中有4种贯穿整个语言且一致应用的公共机置使得UML变得较为简单，这4种机制是：

1. 规格况明

UML不只是一种图形语言，实际上，在它的图形表示法的每部分背后都有一十规格说明．这个规格说明础供了对构造块的语法和语义的文字叙述；例如，在一个类的图符背后就有一个规格说明：它提供了类所拥有的属性，操作(包括完整的特征标记)和行为的全面描述。在视觉上，类的图符可能展示了这个规格说明的一小部分。此外，可能存在着该类的另一个视图，其中提供了一个完全不同的部件集台，但是它仍然与该类的基本规格说明相一致。UML的图形表示法用来对系统进行可视化，UML的规格说明用来描述系统的细节，假定把二芒分开，就可能进行增量式的建模。还可以通过以下方式完成：先画图，然后对这个模型的规格说明增加语义，或直接创建规格说明，也可能对一个已经存在的系统近行逆向工程，然后再创建作为这些规格说明的投影图。

1. 修饰

2. 通用划分

第一种方法是对类和对象的划分:UML的每一个构造块几乎都存在像类

与对象这样的二分法，例如，可以有用况和用况实例，构件和构件实例，

节点和节点实例。在图形上，UML刚与类同样的图形符号来表示对象，只是简单地在对象名的下边画一道线，以示与类的区别。

——>三个不同的Customer对象

第二种方法是接口和实现的分离。接口声明了一个契约，而实现则表示对该契约的具体实施，正负责如实地实现接口的完整语义，UML中，可以既对接口又对它们的实现建摸。几乎每一个UML的构造块都有象接口和实现这样的二分法。例如，用况和实现它们的协作，操作和实现它们的方法。

实现接口Iunknown和Ispelling

1. 扩展机制

UML提供了一种绘制软件蓝图的标准语言，但是一种闭合的语言即使表达能力再丰富，也难以表示出各种领域中的各种模型在不同时刻所有可能的细微差别，由亍这个原因．UML是可扩展的，可以以受控的方式扩展该语言，UML的扩展机制包括：

ü 构造型（stereotype）

构造型扩展了UML的向汇，它允许你创造新的构造块，这个新构造块既可从现有的构造块派生，又专门针对你要解决的问题。

Overflow异常类

ü 标记值（tagged value）

标记值扩展了uML构造块的特性．允许你创建上述元素的颗新信息。见上图的EventQuene类中的vertion＝3.2 author＝egt。

ü 约束（constraint）

约束扩展了UML构造块的语义，它允许增加新的坝则或修改现有的觇则。如上图的给方法add()增加的约束（ordered）。

三、体系结构和开发生命周期

软件体系结构不仅关心结构和行为，而且还关心用法、功能、性能、弹性、复用、可理解性、经济技木约束及其折衷，以及审美的考虑。最终用户、分析人员、开发人员、系统集成人员、测试人员、技术资料作者和项目管理者——他们各自带着项目的不同日程，而且在项目的生命周期内各自在不同的时间、以不同的角度来看系统。所以要开发不同的系统视图。

u 系统的用况视图（use case diagram）

由专门描述可被最终用户、分析人员和测试人员看到的系统行为的用况组成。用况视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。在UML中，该视图的静态方面由用况图表现，动态方面由交互图、状态图和活动图表现。

u 系统的设计视图（design diagram）

u 系统的进程视图（process diagram）

u 系统的实现视图（implementation diagram）

u 系统的实施视图（deployment diagram）

体系结构是—组有关下述内容的重要决策：

u 软件系统的组织

u 对组成系统的结构元索及其接口的选择

u 如元素间的协作中所描述的那样的行为

u 将这些结构和行为元素组合到逐步增大的子系统

u 指导这种组织的体系结构风格：静态和动态元素及其他们的接口

5种视图中的每一种视图都可单独使用，使不同的人员能专注十他们最为关心的体系结构问题。这5种视图也可相互作用，如实施视图中的节点拥有实现视图的构件，而这些构件又表示了设计视图和进程视图中的类、接口、协作以及主动类的物理实现。UML允许表达这5种视图中的任何一种视图，也允许表达它们之间的交互。

UML在很大程度上是独立于过程的，这意味着它不依赖于任何特殊的软件开发生命周期，然而，为了从UML中得到最大的收益，应该考虑这样的过程：

u 用况驱动的（use case driven）

u 以体系结构为中心的（architecture centric）

u 迭代的和增量的（iterative and incremental）

初始inception、细化elaboration、构造construct、移交transition等四个部分迭代。

四、用UML绘制模型图，详细描述各个构造块及其组合应用

<一>类class

对系统建模涉及到识别出对于你的特定视图来说是重要的事物，这些事物形成了正在建模的系统的词汇表。例如：如果正在建造一所房子，那么像墙、门、窗户、柜厨和灯对于房主来说就是重要的事物。在UML中，所有的这些事物都被建摸为类，一个类是对作为词汇表一部分的一些事物的抽象。类不是个体对象，而是描述一群对象的一个完整集合。它是一组具有相同属性、操作、关系和语义的对象的描述。

类名有简单名与路径名两种，见上图，一般第一个字母大写，属性名和操作名一般除了第一个单词的第一个字母不大写，其他单词的首个字母大写，如localAddress、displayResult（）。一个类可以有多个属性也可以没有属性，操作也是如此。属性还可以表明的类型以及初始值，以及只读、共享等特性。操作的特征标记可以标识参数名称、类型、缺省值以及返回类型。

当画一个类时，不必马上把每个属性和操作部显示出来。事实上，在大多数情况下不能这样做(有太多的属性和操作以至于不能把它们放在一张图中，也可能不应该这样做，可能只有一些些属性和操作的一个子集与特定的视图相关。由于这些原因，可以对一个类进行省略，这意味着可以有选择地仅显示类的一些属性和操作，甚至也可以不显示任何属性和操作。空栏并不一定意味着没有属性或操作，只是没有选样要显示它们。通过在列表的末尾使用省略号(“…”)，可以明确地表示出实际的属性和操作比所显示的要多。为了更好地组织属性和操作的长列表，可以利用构造型在每一组属性和操作之前加一个描述其种类的前缀。

职责是类的契约或责任（功能），它是构造型的一个例子。在图形上，把职责列在类图符底部的分隔的栏中，如下图。责职是自由形式的文本，实际上，可以把类的职责写成一个短语，一个句子或一段短文。属性、操作和职责是创建抽象听需要的最常见的特征，事实上，对于大多数要建造的模型，这3种特征的基本形式足以传达类的最重要的语义。然而，有时需要可视化或详述其他特征，例如，（对个体的属性和操作进行可视化，对与特定语言相关的操作特性(如多态性或一致性进行可视化，甚至对类的对象可能产生或操纵的异常事件进行可视化)在UML中能够表达这些特征以及很多其他特征，但它们被作为高级概念处理。因为有些类是经常出现的，这些抑类的炎是很常见的，并且它们招述了重要的体系结构抽象，所以UML提供了主动类（表示进程和线程）、构件(表尔物理软件构件)和节点(表示硬件代备等)。最后说明的是类很少单独存在。确切地讲当建造模型时，通常要注重于相互作用的那些类群，—般在UML中，这些类的街体形成了协作，它们常在类图中被可视化。

为了对系统的词汇建模．需做如下工作：

u 识别用户或实现者用于描述问题或解决问题的那些事物，用CRC卡(class-responsibility-)和基于用况分析的技术帮助用户发现这些抽象；

u 对于每个抽象，识别一个职责集。确信要清楚地定义每个类，而且这些职责要在所有的类之间很好地均衡；

u 提供力实现每个类的职责所需的属性和操作。

一旦开始对大量的类建模，就要保证你的抽象提供了一个均衡的职责集。这意味着不能让任何类过大或过小，每一个类应该做好一件事。若抽象出来的类过大，你会发现模型堆以变化且很不容易复用：若抽象出来的类过小，则最后抽象会过多，难以合理地管理和理解。可以使用UML来帮助你可视化和详述这种职责的均衡。

为了对系统中的职责分布进行建模，要做如下工作：

u 识别一组为了完成某些行为而紧密地协同工作的类；

u 对上述的每一个类识别出一组职责；

u 整体上观察这些类，把职责过多的类分解成轻小的抽象，把职责过于琐碎的小类组合成一个大的类，重新分配职责以使每一个抽象合理地存在。

u 考虑这些类的相互协作方式，相应地重新分配它们的职责，以使得协作中没有哪个类的职责过多或过少。

对非软件事物建模，应该：

u 对被抽象为类的事物建模．

u 如果要将这些非软件事物与UML已定义的构造型相区别，就要创建一个新的构造型，并用这个构造型详述这些新语义，并给出明确的可视化提示。

u 如果破建模的事物是某种本身包合软件的硬件，考虑把它建模力一种节点，以便能进一步扩充它的结构。

UML主要用于对软件密集型系统建模，但将它与文本型硬件建模语言(如VHDL)相结合，对硬件系统建模也很有表达力。系统外部的事物通常被描述为参与者。

对简单类型进行建模，应该：

u 对被抽象为类型或枚举的事物建模，这可以用带有适当构造型的类表示符来表示；

u 若需要详述与该类型相联系的值域，可以使用约束。

用约束显示值域，用属性显示枚举值

提示与技巧：

在UML中对类建模时要记住：对最终用户或实现者来说，各个类都应该映射到某个真实或概念性的抽象：一个结构良好的类，要遵循如下的策略：

u 为取自问题域或解城的词汇中的事物提供明确的抽象。

u 嵌入一个小的、明确定义的职责集，并且能很奸地实现它们。

u 把抽象的规格说明和它的实现清楚地分开。

u 简单而且可理解，并具有可适应性和可扩展性。

当用UML绘制一个类时，要遵循如下的策略：

u 仅显示在该类的语境中对于理解抽象较为重要的类的特性。

u 通过按种类对属性和操作的长列表分组，来进行组织。

u 把相关的类显示在相同的类图中。

类元(classfier)是描述结构特征和行为特征的机制。类元包括类、接口、数据类型、信号构件、节点、用况和子系统。UML中的一些事物没有实例，例如包和泛化关系就没有实例。一般而言，有实例的建模元素被称为类元(关联和消息有实例，但与类的实例不完全一样)。更重要的是类元有结构特征(以属性的形式)和行为特征(以操作的形式)。一个给定的类

元的每个实例共享相同的特征。

属性的可见性：

<二>关系relation

在UML中，事物之间相互联系的方式．无沦是逻辑上的还是物理上的，都被建模为关系，在面向对象的建模中，有三种景重要的关系：依赖、泛化和关联都是定义在类这一级的静态事物。在UML中，通常在类图中对这些关系进行可视化。还有其他两种关系：链（它是关联的实例，描述可能发送消息的对象间的连接）和转换 (它是状态机中不同状态间的连接)。

u 依赖（包括精化、跟踪和绑定）：类之间的使用关系。箭头指向被依赖的事物。依赖可

以带有一个名称，但很少使用，除非模型有很多依赖，并且要引用它们或作出区别，在一般情况下，用构造型区别依赖的不同含义。

u 泛化：父子继承关系。通常（但不总是）子类除了具有父类的属性和操作外，还具有别

的属性和操作，若子类的操作与父类的操作的特征标记相同，则它重载父类的操

作，这称为多态性。一个类可以有0个、1个或多个父类。把没有父类且最少有

一个子类的类称为根类或基类，把没有子类的类称为叶子类。可以说只有一个父

类的类使用了单继承，也可以说有多个父类的类使用了多继承。泛化很少有名称，

但很少使用。除非模型有很多泛化，而且要引用它们或要加以区别，才需要使用

泛化的名称。

不想让它有任何对象的非叶子类，通常把这样的类称为抽象类(abstract class)。在UML中，通常把抽象类名写为斜体，以指明这个类是抽象的，如上图中类Security就是如此。这种规定也适用于操作，如presentValue（），这意味着这样的操作提供了一种特征标记，但它是不完全的，因此必须在较低的抽象层次用一定的方法实现。

u 关联：实例之间的结构关系。给定一个连接两个类的关联，可以从一个类的对象导航到

另一个类的对象，反之亦然。关联的两端都连到同一个类是合法的。这意味着，从一个类的给定对象能连接到该类的其他对象。恰好连接两个类的关联叫做二元关联。尽管不普遍，但可以有连接多于两个类的关联，这种关联叫做n元关联。

依赖是使用关系．泛化是“is a kind of”关系，它们都是单向的，而关联描述了类的对象间相互作用的结构路径，关联在缺省的情况下是双向的，但也可以限制它们的方向。

关联有四个修饰：

名称：关联可以有一个名称，用以描述该关系的性质。为了消除名称含义的歧义，可提供一个指引读名称方向的三角形，给名称一个方向。虽然是联可以有名称，但通常不需要给出名称。当要明确地给关联提供角色名时，

或当一个模型有很多关联，且需要对这些关联进行查阅或区别时，则要给出关联的名称。特别是在有多个关联连接相同类的情况下，更要给出关联的名称。

角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色。角色是关联中靠近它的一端的类对另外一端的类呈现的职责。可以显式地命名类在关联中所扮演的角色。相同类可以在其他的关联中扮演相同或不同的角色。

多重性：关联表示了对象间的结构关系，在很多连接问题中，指明一个关联的实例中有多少个相互连接的对象是很重要的，这个“多少”被称为关联角色的多重性，把它写成一个表示取值范围的表达式或写成一个具体值。就是说明：在关联另一端的类的每个对象要求在本端的类必须有多少个对象，可以精确地表示多重性为1(1)、0或1(0．．1)、很多（0…）、1个或很多(1…)，甚至可以精确地指定多重性为一个数值如（3）。还可以使用象(0．．1．．3．．4．6．．*)这样的列表来描述更为复杂的多重性，该例的含义是“除了2或5外的任意数目的对象”。关联的实例叫做链。

聚合：两个类之间的简单关联表示了两个同等地位类之间的结构关系，这意味着这两个类在慨念上是同级别的，一个类并不比另一个类更重要。有时要对一个“整体／部分”关系建摸，其中一个类描述了一个较大的事物(“整体”)，它由较小的事物(”部分”)组成，把这种关系称为聚合。它描述了“has a”的关系，意思是整体对象拥有部分对象。其实聚合是一种特殊的关联，它被表示为在整体的一端用一个空心菱形修饰的简单关联。

Department 和School之间的关系为组合聚合关系。表明一个或多个系只能属于一个学校。

提示与技巧：

在UML中对关系建模时，要遵循如下策略：

仅当被建摸的关系不是结构关系时，才使用依赖；

仅当关系是“is a kind of”的关系时，才使用泛化；

小心不要引入循环的泛化关系；

往往可以用聚合代替多继承；

一般要保持泛化关系的平衡，继承的层次不道太深，大约多于5层就应该想一想。太宽(代之以寻找可能的中间抽象类)

在对象间有结构关系的地方，要以使用关联为主。

在UML中绘制关系时，要遵循如下策略：

要一致地使用直线或斜线，直线给出的可视化提示强固了相关事物之间的连接都集中到一个共同争物。在复杂的图中斜线则经常有更好的空间效果。在同一个图甲使用两种线形有助于把人们的注意力引导到不同的关系组。

避免线段文又；

仅显示对理解特定的成组事物必不可少的关系，应该省略多余的关系，特别是多余的关联。

<三>公共规范

u 注解（note）是附加在元素或元素集上用来表示约束或解释的图形符号，在图形上，把注解画成带有摺角的矩形，在矩形中填写文字或图形注释。表示注释的注解对模型没有什么语义影响，这意味着它的内容不会改变它所依附的模型的含义，这是为什么用注解描述像需求、观察资料、评论和解释之类事物的原因，也是用注解表示约束的原因。

u 构造型（stereotype)是UML的词汇的扩展，允许创建与已有的构造块相加而针对特定问题的新种类的构造块。在图形上，把构造型表示成用书名号括起来的名称，并把它画在其他的元素名之上。作为一种选择，可以用一种与构造型相联系的新图形表示被构造形化的元素。新构造块有自己的具体特性（各构造型可以提供自己的标记值集）、语义(各构造型可以提供目己的约束)和表示法(各构造型可以提供自己的图标)。

u 标记值（tagged value）是对UML元素的特性的扩展，允许在元素的规格说明中创建新的信息。在图形上，把标记值表示成用花括号括起来的字符串，并把它放在其他的元素名之下。最简单的形式是把标记值表示成一个由括号括起来的串，并放在另一个元素的名称之下，这个串包括一个名称(标记)、一个分隔符(=)和一个（标记的）值。

u 约束(constraint)是对UML元素的语义的扩展，允许增加新的规则或修改已有的规则，在图形上，把约束表示成用大括号括起来的字符串，并把它J真在关联的元素跗近，或者通过依赖关系连接到这个（或这些元素）。作为一种选择，可以在注解中表示约束。可以把约束写咸自由形式的文本。若要更精确地详细语义，可以使用UML的对象约束语言(OCL)。如下图：

u 修饰: 大多数修饰是通过在感兴趣的元素附近放—些文字或对基本表示法增加图形符号表示的。然而，有时要用比简单文本或图形符号更能提供细节的事物来修饰元素，诸如类、构件和节点这佯的事物，可以在它们通常的分隔栏的底部增加分隔栏，以填写这种信息。除非分隔拦的内容很明显，否则最好对任何分隔栏都显式地命名，以避免含义混淆。此外还建议尽量少使用分隔栏、因为若过度地使用，会造成图形混乱。

要对注释建模，要遵循如下策略：

u 把注释文本放人注解内，并把该注解放于它所对应的元素附近。可以用依赖关系把注解与对应的元素相连接，以更明确地表明关系。

u 要记住，可以按需要隐藏或显示模型中的元素。这意味着不必到处显示可视化的元素上

的注释，而只有在语境中需要交流这种信息时才显示图中的注释。

u 如果注释冗长或者包含比纯文本更复杂的事物，可考虑把注释放在外部的文档中，并把文档连接或嵌入到依附于模型的相应注解中。

u 当建模演化时，保持那些有意义的记录结果，并且这些结果不能从模型本身导出，无保留价值的注释。

当绘制构造型、标记值或约束时，要遵循如下策略：

u 要确认用基本的UML无法表达你要做的事情，如果是常见的建模问题，可能已存在一些标准的构造块、标记值或约束可满足你的需要，如果确信没有已经存在的方法能表达这些语义，才创造新的构造型、标记值或者约束。

u 要少用图形构造型，你可以用构造型完全改变UML的基本表示法，但这样做可能会使其他任何人都不理解你的模型；

u 对图形构造型，可以考虑使用简单的颜色或阴影，也可使用较复杂的图标，简单的表示法一般来说是最好的，即使是最单薄的可视化提示对于理解其含义也大有帮助。

<四>图diagram

图是观察类、接口、构件等基本构造块的方式。图是一组元素的图形表示，经常把大多数图表示成顶点(事物)和弧（关系）的连通图。用来从不同的角度对系统进行可视化，因为没有哪个复杂的系统能仅从一个角度理解其全局，所以UML定义多种图，使你能分别独立地注重于系统的不同方面。优秀的图使得正在开发的系统易于理解和处理，选样一组正确的图来对系统进行建模，能促使你对系统提出正确的问题，并有助于表明决策的含义。

在软件方面，对软件体手结构进行可视化、详述、构造和文档化，有5种最重要的互补视图：用况视图、没计视图、进程视图、实现视图和实施视图，每一种视图都包含结构建模(对静态事物建模)和行为建模（对动态事物建模）。当用UML从任一角度观察软件系统时，要用图去组织感兴趣的元素。UML定义了9种图，可以混合和组配它们来汇集成各种视图-例如，系统的实现视图的静态方面可以用构件图可视化；同一个实现视图的动态方面可以用交互图可视化。类似地，系统数据库的静态方面可以用类图可视化；动态方面可以用协作图可视化。当然，你可以不限于这9种图，在UML中，定义这9种图是因为它们表示了被观察元素的最常见的组合。为了适应项目或组织的需要，可以创建你自己所需种类的图，从而以不同的方式对UML元素进行观察。

静态图：类图、对象图、构件、实施图

动态图：用况图、顺序图、协作图、状态图、活动图

---

在实践中创建的所有图都是两维的，这意味着它们都是绘制在纸上、白板上、信封的背面或计算机显示器上的，节点和弧的平面图。UML允许创建三维图，即有深度的三维图，允许在模型中“漫游”，一些虚拟现实研完组己显示了这种UML的高级用法。UML许创建动态图，并且允许使用颜色和其他的可视提示去“运行”图，一些工具已经展示UML的这种高级的用法。

系统、子系统、模型、视图、图的概念（要仔细品味区别）：系统(system)是一个为完成一定的目的而被组织起来的子系统的集合，这些子系统由一组可能来自不同观点的模型描述；子系统(subsystem)是一组元素的组合，其中的一些元素构成了其他被包含的元素所提供的行为规格说明；模型(model)是系统的语义闭合的佃象，这意味着它表示对现实的简化，这种简化既是完整的又是自相容的，这是力更好地理解系统而建立的。在体系结构的语境中；视图(view)是对系统模型的组织和结构的投影，注重于系统的一个方面。图{diagram}是一组元素的图形表示，通常表示成由顶点(事物)和弧(关系)组成的连通图。

l 构建类图

类图显示了一组类、接口、协作以及它们之间的关系，是面向对象系统建模中最常见也最重要的一种图，是构件图和实施图的基础，它对系统的静态设计进行建模，大部分涉及系统的词汇建模、协作建模和模式建模。类图不仅对结构模型的可视化、详述和文档化很重要，而且对通过正向与逆问工程构造可执行的系统也很重要。

类图一般包含：

ü 类

ü 接口

ü 协作

ü 依赖、泛化和关联等关系

ü 包

ü 子系统

ü 有时还有实例

设计视图主要在三个方面使用类图：

对系统的词汇建模

对简单的协作建模

对逻辑数据库的模式建模

使用UML的某些功能，所创建的模型将永远不会映射成代码：刨如，若用活动图对业务过程建模，则很多被建模的活动要涉及列人员而下是汁算机，另一种情况是你所建模的系统的组成部份在你的抽象层次上只是一些硬件(虽然在另一个抽象层次上看，也可以说该硬件包含了嵌入的计算机的软件)

在大多数情况下，要把所创建的模型映射成代码。UML没有指定对任何面向对象编程语言的映射，但UML还是考虑了映射间题。特别是对类图，可以把类图的内容清楚地映射到各种工业化的面向对象的语言，如Java．C＋＋，Smalltalk，Effile，Ada，ObiectPascal和Forter。UML也可以被设计得可映射到各种商用的基于对象的语言，如VisicalBasic。

正向上程(forward engineering)是通过到实现语言的映射而把模型转换为代码的过程。由于用UML描述的模型在语义上比当前的任何面向对象编程语言都要丰富，所以正向工程将

导致一定信息的损失。事实上，这是为什么除了代码之外还需要模型的主要原因，像协作这

样的结构特征和交互这样的行为特征，在UML中能被清晰地可视化，但源代码就不会如此清晰。

逆向工程(reverse engineering)是通过从特定实现语言的映射而把代码转换为模型的过程。逆向工程会导致大量的多余信息，其中的一些信息属于细节层次，对建造有用的模型来说过于详细。同时，逆向工程是不完整的。由于在正向工程中产生的代码丢失了一些信息，

所以，除非所使用的工具能对原先注释中的信息(这超出了实现语言的语义)进行编码，否则就不能再从代码创建一个完整的模型。

对类图进行正向工程，要遵循如下的策略：

u 识别映射到所选择的实现语言的规则，这是你要为整个项目或组织做的事情。

根据所选择语言的语义，可能要限定对一些UML特性的用法。例如，UML允许对多继承建模，但smalltalk和JAVA都仅允许单继承。可以选择禁止开发人员用多继承建模(这使得模型依赖于语言)，也可以选择把这些丰富的特征转化为实现语言的惯用方法(这样使得映射更为复杂)。

u 用标记值详述目标语言。如果需要精确的控制，可以在单个类的层次上做这些事情，也可以在较高的层次上(如协作或包)这样做。

u 使用工具对模型进行正向工程。

对类图进行逆向工程，要遵循如下的策略：

u 识别从实现语言或所选的语言进行映射的规则。这是你要为整个项目或组织做的事。

u 使用工具，指向要进行逆向工程的代码，用工具生成新的模型或修改以前进行正向工程时已有的模型。

u 使用工具，通过查询模型创建类图。例如，可以从一个或几个类开始，然后通过追踪特定的关系或其他相邻的类扩展类图。根据表达你的意图的需要，显示或隐藏类的内容的细节。

为了由不同的视图对系统建模，要遵循如下的策略：

u 决定你需要哪些视图才能最好地表达系统的体系结构．并暴露项目的技术风险，上面描述的5种体系结构视图是一个好的开始点。

u 对这样的每种视图，决定需要创建哪些制品来捕获该视图的基本细节，在大多数情况下，这些制品由各种UML图组成。

u 作为你的过程策划的一部分，决定你将把哪些图置于某种形式或半形式的控制之下。对这些图要安排复审，并把它们作为项目的文档保存。

u 允许保留废弃的图，这些临时图仍然有助于探究决策的意图，也有助于用情况变化进行实验。

可以对同一模型或不同的模型创建几种图，每种图掩盖或显露不同的元素集，并显示不同层次上的细节，即抽象层次，以达到不同的参与者之间交流目的（比如，程序员工作在较低的抽象层，而系统分析员和用户工作在较高的抽象层）。

在不同的抽象层次对象统建模，要遵循如下的策略：

u 考虑读者的需要，从给定的模型开始；

u 如果读者要用这个模型构造实现，就需要较低抽象层次的图，这意味着需要揭示许多细节；如他们用这个模型向最终用户提供概念模型，就需要较高抽象层次的图，这意味着需要隐藏许多细节。在不同的抽象层次的模型之间进行跟踪依赖。

用况及其实现：用况模型中的用况要跟踪到设计模型中的协作；

协作及其实现：协作要跟踪到共同工作以完成协作的一组类；

构件及其设计：实现模型中的构件要跟踪到设计模型中的元素；

节点及其构件：实施模型中的节点要跟踪到实现模型中的构件；

u 根据你在这个从低到高的抽象层次谱系中所处的位置，通过隐藏或揭示模型中的如下4种事物，而在恰当的抽象层次上创建图：

构造块和关象：把与图的内容无关的或读者不需要的构造块和关系隐藏起来；

修饰：仅仅显示对于理解意图是必要的构造块和关系的修饰；

流：在行为图的语境中，仅展开对于理解意图是必要的那些消息或转换。

构造型：在用于属性和操作等单物的分类列表的构造型的语境中，仅显示对于理解意图是必要的那些构造块的项。

参看下列两个不同抽象级别的交互图：

对于复杂视图建摸．要遵循如下的策略：

u 首先要确定不存在任何没有意义的方法，能用于在较高的抽害层次上表达这种信息，或许要省略一部分图，并抑制其他部分的细节；

u 如果已经隐藏了能够隐藏的细节，但图仍然是复杂的，就考虑把一些元素组织到—些包或者层次较高的协作中，然后仅把这些包或协作画在图中；

u 如果图仍然是夏杂的，就用注解和色彩作为可视化提示，以将用户的注意力引导到你所强调的重点上

u 如果图还是复杂的，把它全部打印出来，挂在适宜的大墙上。虽然丧失了联机形式所带来交互性，但能够退后—步研究它的公共模式。