一、UML简介

1.1什么是UML

UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。它：

ü  不是一种可视化的程序设计语言，而是一种可视化的建模语言；

ü  不是工具或知识库的规格说明，而是一种建模规格说明，是一种表示的标准。

UML的目标是：

ü  易于使用、表达能力强，进行可视化建模；

ü  与具体的实现无关，可应用于任何语言平台和工具平台；

ü  与具体的过程无关，可应用于任何软件开发的过程。

ü  简单并且可扩展，具有扩展和专有化机制，便于扩展，无需对核心概念进行修改；

ü  为面向对象的设计与开发中涌现出的高级概念（例如协作、框架、模式和组件）提供支持，强调在软件开发中，对架构、框架、模式和组件的重用；

ü  与最好的软件工程实践经验集成；

ü  可升级，具有广阔的适用性和可用性。

ü  有利于面对对象工具的市场成长。

1.2 UML的架构

UML是由图和元模型组成的。图是UML的语法，而元模型则给出图的意思，是UML的语义。UML的语义是定义在一个四层（或四个抽象级）建模概念框架中的，这四个层分别是：

ü  元元模型（meta-metamodel）层，组成UML的最基本的元素“事物”，代表要定义的所有事物；

ü  元模型（metamodel）层，组成了UML的基本元素，包括面向对象和面向组件的概念。这一层的每个概念都是元元模型中“事物”概念的实力（通过版类化）；

ü  模型（model）层，组成了UML的模型，这一层中的每个概念都是元模型中概念的一个实例，这一层的模型通常叫做类模型（class model）或者类型模型（type model）;

ü  用户模型（user model）层，这层中的所有元素都是UML模型的例子。这一层中的每个概念都是模型层的一个实例，也是元模型的一个实例。这一层的模型通常叫做对象模型或实例模型。

1.3 UML的模型、视图、图与系统架构建模

UML是用来描述模型的，它用模型来描述系统的结构或静态特征、以及行为或动态特征。它从不同的视角为系统的架构建模，形成系统的不同视图（view），包括：

ü  用例视图（use case view），强调从用户的角度看到的或需要的系统功能，这种视图也叫做用户模型视图（use model view）或想定视图（scenario view）；

ü  逻辑视图（logical view），展现系统的静态或结构组成及特征，也称为结构模型视图（structural model view）或静态视图（static view）；

ü  并发视图（concurrent view），体现了系统的静态或行为特征，也称为行为模型视图（behavioral model view）、过程视图（process view）协作视图（collaborative）、动态视图（dynamic view）；

ü  组件视图（component view）,体现了系统实现的结构和行为特征，也称为实现模型视图（implementation model view）和开发视图（development view）；

ü  展开视图（deployment view），体现了系统实现环境的结构和行为特征，也称为环境模型视图（environment model view）或物理视图（physical view）；

在必要的时候，还可以定义其他架构视图。

每一种UML的视图都是由一个或多个图（diagram）组成的，一个图就是系统架构在某个侧面的表示，它与其它图是一致的，所有的图一起组成了系统的完整视图。UML提供了九个不同的图，可以分成大致两大类：一类是静态图，包括用例图、类图、对象图、组件图、配置图；另一类是动态图，包括序列图、协作图、状态图和活动图。也可以根据它们在不同架构视图的应用，把它们分成：

ü  在用户模型视图：用例图（use case diagram），描述系统的功能；

ü  在结构模型视图：类图（class diagram），描述系统静态结构；对象图（object diagram），描述系统在某个时刻的静态图；

ü  在行为模型视图：序列图（sequence diagram），按时间顺序描述系统元素间的交互；协作图（Collaboration diagram）,按照时间和控件顺序描述系统元素间的交互和它们之间的关系；状态图（state diagram），描述了系统元素的状态条件和响应；活动图（activity diagram），描述了系统元素的活动；

ü  在实现模型视图：组件图（component diagram），描述了实现系统的元素的组织；

ü  在环境模型视图：展开图（deployment diagram）， 它描述了环境元素的配置，并把实现系统的元素映射到配置上。

 

二、   UML概述

2.1  

2.2图

图（diagram）由图片（graph）组成，图片时模型元素的符号化。把这些符号有机的组织起来形成的图表示了系统的一个特殊部分或某个方面。一个典型的系统模型应有多个各种类型的图。图示一个具体视图的组成部分，在画一个图时，就相当于把这个图分配给某个视图了。依据图本身的内容，有些图可能是多个视图的一部分。

         Uml中包含用例图、类图、对象图、状态图、序列图、协作图、活动图、组件图、展开图共九种。

2.2.1用例图

         用例图（use-case diagram）用于显示若干角色（actor）以及这些角色与系统提供的用来之间的连接关系。用例是系统提供的功能（既系统的具体用法）的描述。

         通常一个实际的用例采用普通的文字描述，作为用来符号的文档性质。当然，实际的用例图也可以用活动图描述。用例图仅仅从角色（触发系统功能的用户等）使用系统的角色描述系统中的信息，也就是站在系统外部察看系统的功能需求。

 

2.2.2 类图

         类图（class diagram）用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述。

         类用来表示系统中需要处理的事物。类与类之间有多种连接方式（关系），比如：关联（彼此间的连接）、依赖（一个类使用另一个类）、通用化（一个类是另一个类的特殊化）或打包（packageed）（多个类聚合成一个基本元素）。类与类之间的这些关系都体现在类图的内部结构中，通过类的属性（attribute）和操作（operation）这些术语反映出来。在系统的生命周期中，类图所描述的静态结构在任何情况下都是有效的。

         一个典型的系统中通常有若干个类图。一个类图不一定包含系统的所有的类，一个类还可以加到几个类图中。

 

2.2.3 对象图

         对象图是类图的变体。两者之间的差别在于对象图表示的是类的对象实例，而不是真实的类。对象图是类图的一个范例（example），它及时具体地反映了系统执行到某处时，系统的工作状况。

对象图中使用的图示符号与类图几乎完全相同，只不过对象图中的对象名加了下划线，而且类与类之间的所有实例都画了出来。图a的类图抽象地显示各个类及它们之间的关系，图b的对象图则是图a类图的一个实例表示。

 

2.2.4 状态图

         一般说来，状态图是对类所描述事物的补充说，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件。如下图所示。事件可以是给它发送消息的另一个对象或者某个任务执行完毕（比如，指定时间到）。状态的变化称作转移（transition）。一个转移可以有一个与之相连的动作（action），这个动作指明了状态转移时应该做些什么。

         并不是所有的类都有相应的状态图。状态图仅用于具有下列特点的类：具有若干个确定状态，类的行为在这些状态下会受到影响且被不同的状态改变。

        

 

2.2.5 序列图

         序列图用来反映若干个对象之间的动态协作关系，也就是随着时间的流逝，对象之间是如何交互的。图下图所示。序列图主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一个具体位置将会发生有什么事件发生。

         序列图由若干个对象组成，每个对象用一个垂直的虚线表示（线上方是对象名），每个对象的正下方有一个矩形条，它与垂直的虚线相叠，矩形条表示该对象随时间的流逝的过程（从上至下），对象之间传递的消息用消息箭头表示，它们位于表示对象的垂直线条之间。时间说明和其他的注释作为脚本放在图的边缘。

 

2.2.6 协作图

         协作图和序列图的作用一样，反映的也是动态协作。除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关）。由于协作图或序列图都反映对象之间的交互，所以建模者可以任意选择一种反映对象间的协作。如果需要强调时间和序列，最好选择序列图；如果需要强调上下文相关，最好选择协作图。

         协作图与对象图的画法一样，图中含有若干个对象及它们之间的关系（使用对象图或类图中的符号），对象之间流动的消息用消息箭头表示，箭头中间用标签标识消息被发送的序号、条件、迭代方式、返回值等等。通过识别消息标签的语法，开发者可以看出对象者的协作，也可以跟踪执行流程和消息的变化情况。

         协作图也能包含活动对象，多个活动对象可以并发执行。

 

2.2.7 活动图

         活动图（activity diagram）反映一个连续的活动流，相对于描述活动流（比如，用例或交互）来说，活动图更常用于描述某个操作执行时的活动状况。

         活动图由各种动作状体（action state）构成，每个动作状体包含可执行动作的规范说明。当某个动作执行完毕，该动作的状态就会随着改变。这样，动作状体的控制就从一个状态流向另一个与之相连的状态。

         活动图中还可以显示决策、条件、动作状态的并行执行、消息（被动作发送或接收）的规范说明等内容。

 

2.2.8 组件图

         组件图（component diagram）用来反映代码的物理结构。

代码的物理结构用代码组件表示。组件可以是源代码、二进制文件或可执行文件组件。

组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系。组件之间也存在依赖关系，利用这种依赖关系可以方便很容易地分析一个组件的变化会给其他的组件带来怎样的影响。

         组件可以与公开的任何接口（比如，OLE/COM接口）一起显示，也可以把它们组合起来形成一个包（package），在组件图中显示这种组合包。实际编程工作中经常使用组件图。

 

2.2.9 展开图

         展开图（deployment diagram）用来显示系统中软件和硬件的物理架构。通常展开图中显示实际的计算机和设备（用结点表示），以及各个结点之间的关系（还可以显示关系的类型）。每个结点内部显示的可执行的组件和对象清晰地反映出哪个软件运行在哪个结点上。组件之间的依赖关系也可以显示在展开图中。

         正如前面所述，展开图用来表示展开视图，描述系统的实际物理结构。用例视图是对系统应具有的功能的描述，?二者看上去差别很大，似乎没有什么联系。然而，如果对系统的模型定义明确，那么从屋里结构的结点出发，找到它含有的组件，再通过组件到达它实现的类，再到达类的对象参与的交互，直至最终到达一个用例也是可能的。从整体来说，系统的不同视图给系统的描述应当是一致的。

 

2.3模型元素

         可以在图中使用的概念统称为模型元素。模型元素用语义、元素的正式定义或确定的语句所代表的准确含义来定义。模型元素在图中用其相应的视图元素（符号）表示。利用视图元素可以把图形象直观地表示出来。一个元素（符号）可以存在于多个不同类型的图中，但是具体以怎样的方式出现在哪种类型的图中药符合（依据）一定的规则。

         下图中给出了类、对象、状态、结点、包（package）和组件等模型元素的符合图例。

 

模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、通用化（generalization）、依赖（dependency）和聚合（aggregation），其中聚合是关联的一种特殊形式。这些关系的图示符合如下图：

 

除了上述的模型元素外，模型元素还包括消息、动作和版类（stereotype）。

2.4通用机制

UML语言利用通用机制为图附加一些信息，这些信息通常无法用基本的模型元素表示。常用的通用机制有修饰（adornment）、笔记（note）和规格说明（specification）等。

2.4.1修饰

         在图的模型元素上添加修饰为模型元素附加一定的语义。这样，建模者就可以方便地把类型与实例区别开。

         当某个元素代表一个类型时，它的名字被显示成黑体字；当用这个元素代表其对应类型的实例时，它的名字下面加下划线，同时还要指明实例的名字和类型的名字。

         比如，类用长方形表示，其名字用黑体字书写

 

。如果类的名字带有下划线，它则代表该类第一个对象

 

。对结点的修饰方式也是一样的，结点的符号既可以是用黑体字表示的类型，也可以是结点类型的一个实例。其他的修饰有对各种关系的规范说明。比如重数（multiplicity），重数是一个数值或一个范围，它指明涉及到关系的类型的实例个数。修饰紧靠着模型元素书写。

2.4.2 笔记

         无论建模语言怎样扩展，它不可能应用于描述任何事物。为了在模型中添加一些额外的模型元素无法表示的信息，UML语言提供了笔记能力。笔记可以放在任何图的任意位置，并且可以含有各种各样的信息。信息的类型时字符串（UML语言不能解释）。

         如果某个元素需要一些解释或说明信息，那么就可以为该元素添加笔记。通常用虚线把含有信息的笔记与图中的一些元素联系起来。如下图：

 

2.4.3 规格说明

         模型元素含有一些性质，这些性质以数值方式体现。一个性质用一个名字和一个值表示，又称作加标签值（tagged value）。加标签值用整数或字符串等类型详细说明。UML中有许多预定义的性质，比如：文档（documentation）、响应（responsibility）、持续性（persistence）和并发性（concurrency）。

         性质一般作为模型元素实例的附加规格说明，比如，用一些文字逐条列举类的响应和能力。这种规范说明方式是非正式的，并且也不回直接显示在图中，但是在某些CASE工具中，通过双击建模元素，就可以打开含有该元素所有性质的规格说明窗口，通过该窗口就可以方便的读取信息了。

2.5扩展机制

         UML语言具有扩展性，因此也适用于描述某个具体的方法、组织或用户。这里我们介绍三种扩展机制；版类（stereotype）、加标签值（tagged value）和约束（constrains）。

2.5.1版类

         版类扩展机制是指在已有的模型元素基础上建立一种新的模型元素。版类与现有的元素相差不多，只不过比现有的元素多一些特别的语义罢了。版类与产生该版类的原始元素的使用场所是一样的。版类可以建立在所有的元素类型上，比如：类、结点、组件、比较、关系（关联、通用化和依赖）。UML语言中已经预定义了一下版类，这些预定义的版类可以直接使用，从而免去了再定义新版类的麻烦，使得UML语言用起来比较简单。

         版类的表示方法是在元素名称旁边添加一个版类的名字。版类的名字用字符串（用双尖角括号括起来）表示。版类也可以用一个图形表示（比如，图标）。

         具体的版类元素的图示方法有三种：第一种在元素名称之上写版类名，这是一般的表示法；第二种是在元素名称旁画出版类的图标（图形化表示）；第三种是把元素名称和版类图标合在一起。

 

当一个元素与版类连接在一起后，该元素称为“指定版类的元素类型”。比如，与版类《window》相连的类就称为“window版类的类”，这意味着该类是window类型的了。