UML简介

 一、UML概述

1. 可视化建模有助于：

¨         捕获商业流程 --> 捕获系统结构或行为

¨         描述如何将系统元素整合在一起 --> 定义软件构架

¨         保持设计和实现的一致性

¨         适当的隐藏或暴露细节 --> 管理复杂性

¨         使人员间的交流更明确 --> 促进沟通

¨         UML为所有开发者提供了一种表示语言

可视化的建模帮助开发组形象化，详细说明，构造并且文档化一个系统的体系结构和行为。

2. 标准建模语言UML的出现是面向对象技术发展的必然

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

二、UML关系

1. 常用关系

依赖（Dependencies）            ；

关联（Association）                

一般化（generalization）             ；

2. 依赖、一般化

1)依赖关系：依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在我们想显示一个事物使用另一个事物时使用依赖关系。通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数（如图）。

2)一般化：一般化是继承关系，是“is-a-kind-of”的关系。人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中一般将前者称为父元素,将后者称为子元素。继承定义了父元素和子元素之间的分类关系。例如将客户进一步分类成个体客户和团体客户,使用的就是继承关系。

在UML定义中对继承有三个要求：

¨         子元素应与父元素完全一致,父元素所具有的关联、属性和操作,子元素也都隐含性地具有;

¨         子元素还应包含额外信息;

¨         允许使用父元素实例的地方,也应能使用子元素.

3. 关联

1) 关联表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。

关联有两元关系和多元关系。两元关系是指一种一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。当我们想要表示结构化关系时使用关联。

2) 关联的方向：关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航。我们将只在一个方向上存在导航表示的关联,称作单向关联，在两个方向上都有导航表示的关联,称作双向关联。

3) 关联的命名：既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。

4) 角色：关联两头的类以某种角色参与关联。例如,"公司"以"雇主"的角色, "人"以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没有标出角色名，则隐含地用类的名称作为角色名。

角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。多重性表示参与对象的数目的上下界限制。"*"代表0～∞,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。

5)聚集和组成：聚集是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关系。

聚集可以进一步划分成共享聚集和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员，即部分可以参加多个整体，我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。

需要注意的是,对聚集的定义并不都一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。

三、模型，视图，和图表

¨         图表是模型的视图

¨         表现给投资者看的,详细的描述;

¨         针对系统的局部,提供了详细描述;

¨         和别的视图保持语义一致;

1. 用例图-----捕获系统中用户能够看见的功能

1)角色：任何一个与系统发生相互作用的事物都可以表现为一个角色。角色可以是人也可以是物。

2) 一个用例定义了一组系统要做的有序的动作序列，并且这个动作序列要产生一个可观测的结果，返回给某一个特定的角色。

单个执行者可与多个用例联系；反过来，一个用例可与多个执行者联系。对同一个用例而言，不同执行者有着不同的作用:他们可以从用例中取值，也可以参与到用例中。

2. 类图-----捕获系统的词汇表

1) 类是具有相同属性、操作、关系的对象集合的总称。通常在UML中类被画成矩形。

2) 类图：描述类和类之间的静态关系,在系统的整个生命周期都是有效的。与数据模型不同，它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上，状态图、协作图等进一步描述了系统其他方面的特性。

3) 名称：每个类都必须有一个名字,用来区分其它的类。类名是一个字符串,称为简单名字。

4) 属性：是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。可以只写上属性名，也可以在属性名后跟上类型甚至缺省取值。根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为: "可见性属性名 :　类型 =缺省值　{约束特性}"。

常用的可见性有Public、Private和Protected三种,在UML中分别表示为"+"、"-"和"#"。     类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等，也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。约束特性则是用户对该属性性质一个约束的说明。例如"{只读}"说明该属性是只读属性。

5) 操作：是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。该项可省略。操作用于修改、检索类的属性或执行某些动作。它们被约束在类的内部，只能作用到该类的对象上。UML规定操作的语法为：可见性操作名 (参数表): 返回类型 {约束特性}。

6)约束：在UML中，可以用约束表示规则。约束是放在括号"{ }"中的一个表达式,表示一个永真的逻辑陈述。

7) 组织属性和方法：在画类图的时候没有必要将全部的属性和操作都画出来.实际上，在大部分情况下我们也不可能在一个图中将类的属性和操作都画出来。在画类图时可以只将感兴趣的属性和操作画出来就可以了。可以用”...”表示还有属性或方法没有画出来。

8) 使用类图进行建模的几个建议：

¨         不要试图使用所有的符号。从简单的开始，例如,类、关联、属性和继承等概念。在UML中，有些符号仅用于特殊的场合和方法中，只有当需要时才去使用。

¨         根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。

¨         不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。

¨         使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。

3. 对象图-----捕获实例和连接

UML中对象图与类图具有相同的表示形式。

对象图可以看作是类图的一个实例。对象是类的实例。

对象之间的链是类之间的关联的实例。链的图形表示与关联相似。

对象与类的图形表示相似，均为划分成两个格子的长方形（下面的格子可省略）。上面的格子显示对象名和类。

对象名格式为对象名: 类名，类名和对象名下面有下划线；下面的格子记录对象的属性以及值的列表，格式为“属性: 类型=值”。类型可以省略。对象图常用于表示复杂的类图的一个实例。

4. 组件图-----捕获实现的物理结构

1）组件图：组件图显示代码本身的结构,显示软件组件之间的依赖关系。组件图是指用依赖关系链接起来的组件集合，可以描述与特定语言相关的编译时刻的依赖关系。

2）组件：一般来说,软件组件就是一个实际文件，可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时组件之间的依赖关系。

3）在面向对象方法中，类和组件等元素并不是所有的属性和操作都对外可见。它们对外提供可见操作和属性，称之为类和组件的接口——可以表示为一头是小园圈的直线。

5. 分布图-----捕获系统硬件的拓扑结构

1）分布图：描述系统硬件的物理拓扑结构以及在此结构上执行的软件。分布图显示系统运行时刻的结构；可以显示计算节点的拓扑结构和通信路径、节点上运行的软件组件、软件组件包含的逻辑单元（对象、类）等。分布图常常用于帮助理解分布式系统。

2)节点：代表一个物理设备以及其上运行的软件系统,如一台Unix主机、一个PC终端、一台打印机、一个传感器等。节点表示为一个立方体。

3)连接：结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接。

6. 时序图-----捕获系统的动态行为(面向时间的)

时序图用来描述对象之间动态的交互关系，着重体现对象间消息传递的时间顺序。时序图存在两个轴：水平轴表示不同的对象，垂直轴表示时间。时序图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。

当收到消息时，接收对象立即开始执行活动，即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。消息可以用消息名及参数来标识。消息也可带有顺序号，但较少使用。在时序图的左边可以有说明信息，用于说明消息发送的时刻、描述动作的执行情况以及约束信息等。一个对象可以通过发送消息来创建另一个对象，当一个对象被删除或自我删除时，该对象用"X"标识。

7. 协作图-----捕获系统的动态行为 (面向消息的)

1）协作图用于描述相互合作的对象间的交互关系和链接关系。虽然时序图和协作图都用来描述对象间的交互关系，但侧重点不一样。时序图着重体现交互的时间顺序，协作图则着重体现交互对象间的静态链接关系。协作图中对象的外观与时序图中的一样。对象间的链接关系类似于类图中的联系。通过在对象间的连接上标志带有消息串的消息来表达对象间的消息传递。

2）链接用于表示对象间的各种关系。各种连接关系与类图中的定义相同，在连接的端点位置可以显示对象的角色名。

3）消息流：在协作图的连接线上，可以用带有消息串的消息来描述对象间的交互。消息的箭头指明消息的流动方向。消息串说明要发送的消息、消息的参数、消息的返回值以及消息的序列号等信息。

8. 状态图-----捕获系统动态行为(面向事件的)

1）状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常，状态图是对类图的补充。在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类的对象画状态图。状态图只是对单个对象建立模型。

2）事件和活动可以对状态转换线添加一些细节。可以指明引起转移发生的事件和引起状态变化所需执行的计算(活动)。添加的事件和活动写在转换线上，事件和活动名之间用"/"隔开。

3）防护：当满足这个防护条件时,转换才能发生。

4）嵌套状态。子状态以两种形式出现：顺序子状态和并发子状态。并发状态之间用虚线隔开。

9. 活动图-----捕获动态行为(面向活动的)

1）活动图的应用非常广泛，它既可用来描述操作（类的方法）的行为，也可以描述用例和对象内部的工作过程。活动图是由状态图扩展而来的，它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作（将要执行的工作或活动）与动作的结果，突出了活动。活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的变迁可能需要事件的触发）。

2）活动和转移：一项操作可以描述为一系列相关的活动。活动仅有一个起始点，但可以有多个结束点。一个活动可以顺序地跟在另一个活动之后，这是简单的顺序关系。如果在活动图中使用一个菱形的判断标志，则可以表达条件关系，判断标志可以有多个输入和输出转移，但在活动的运作中仅触发其中的一个输出转换。活动图中，使用一个称为同步条的水平粗线可以将一条转移分为多个并发执行的分支，或将多个转换合为一条转换。此时，只有输入的转换全部有效，同步条才会触发转换，进而执行后面的活动。

3）泳道：用矩形框来表示，属于某个泳道的活动放在该矩形框内，将泳道的角色名放在矩形框的顶部。

4）对象：在活动图中可以出现对象。对象可以作为活动的输入或输出，,对象与活动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响，则可用不带箭头的虚线来连接对象与活动

 

 

 

1.1.  UML的基本构造块(Building Blocks)

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

1.1.1.  UML中的事物(Things)

构成模型图的一些基本图示符号，它们表示一些面向对象的基本概念

1.1.1.1.   结构事物

1.      类(class)：类是对一组具有相同属性、方法、关系和语义的对象的描述，一个类实现一个或多个接口

2.      接口(interface)：接口描述了一个类或构件的一个服务的操作集，接口仅仅是定义了一组操作的规范，它并没有给出这组操作的具体实现

3.      协作(collaboration)：协作定义了一个交互，它是由一组共同工作以提供某协作的角色和其它元素构成的群体，这些协作行为大于所有元素的各自行为的总和。因此，协作所有结构、行为和维度。一个给定的类可以参与几个协作

4.      用例(use case)：用例是对一组动作序列的描述，系统执行这些动作将产生一个对特定的参与者(actor)有价值且可观察的结果

5.      主动类(activeclass)：主动类是这样的类，其对象至少拥有一个进程或线程，因此它能启动控制活动

6.      构件(component)：构件是系统中物理的、可替代的部件，它遵循且提供一组接口的实现

7.      节点(node)：节点是在运行是存在的物理元素，它表示了一种可计算的资源，它通常至少有一些记忆能力处理能力。一个构件集可以驻留在一个节点内，也可以从一个节点迁移到另一个节点

1.1.1.2.  行为事物

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

1.      交互(interaction)：交互是这样一种行为，他由在特定语境中共同完成一定特定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可用一个交互来描述。

交互涉及一些其他元素，包括消息、动作序列(由一个消息所引起的行为)、links(对象间的连接)

2.      状态机(statemachine)：状态机是这样一种行为，描述了一个对象或一个交互在生命周期内响应事件所经历的状态序列，单个类或一组类之间协作的行为可以用状态机来描述，一个状态机涉及到一些其他元素，包括状态转换(从一个状态到另一个状态的流) 事件(发转换的事物)和活动(对一个转换的响应)

1.1.1.3.  分组事物

分组事物是UML模型的组织部分

1.        包(package)：包是把元素组织成组的机制

包是UML中唯一的组织机制

包可以拥有其他元素，这些元素可以是类、接口、构件、节点、协作、用例和图，甚至可以是其他包

一个包形成了一个命名空间，在一个包中同一种元素的名称必须是唯一的，不同包中的元素可以有相同的名称

1.1.1.4.   注释事物

注释事物是UML模型的解释部分，这些注释事物用来描述、说明和标注模型的任何元素，有一种主要的注释事物，称为注解

1.        注解(note)：注解是一个依附于一个元素或一组元素之上，对它进行约束或解释的简单符号

1.1.2.  UML中的关系(Relationgships)

表示基本图示符号之间的关系

1.        关联(Association)：描述了两个或多个类之间的结构性关系。在图形上，把关联关系画成一条带箭头的实线

2.        依赖(Dependency)：依赖是两个事物间的语义关系，其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义，在图形上，把依赖画成一条可能有方向的虚线

3.        泛化(Generalization)：泛化是一种特殊/一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象，用这种方法，子元素共享了父元素的结构和行为，在图形上，把泛化关系画成一条带有空心箭头的实线，它指向父元素

4.        实现(Realization)：实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约在两种地方要用到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把实现关系画成一个带空心箭头的虚线

1.1.3.  UML中的图(Diagrams)

特定的视角对系统所作的抽象描述

1.        用例图(use case diagrams)：用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能

2.        类图(class diagrams)：用于定义系统中的类，包括描述类的内部结构和类之间的关系，类图主要用于描述系统的静态结构

3.        对象图(object diagrams)：对象图是类图的一个实例，描述了系统在具体时间点上所包含的对象以及各个对象之间的关系

4.        状态图(statechart diagrams)：用来描述类的对象所有可呢的状态以及事件发生时状态的转移条件

5.        活动图(activity diagrams)：用来描述满足用例要求所要进行的活动以及活动时间的约束关系，使用活动图有利于识别系统的并行活动

6.        序列图(sequence diagrams)：描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序，同时也显示对象之间的交互过程

7.        协作图(collaboration diagrams)：描述对象之间的合作关系，更侧重于说明哪些对象之间有消息的传递

序列图和协作图可以相互转化

8.        组件图(component diagrams)：用来描述代码组件的物理结构以及各组件之间的依赖关系，一个组件可以是一个资源文件、一个二进制文件或者一个可执行文件

9.        部署图(deployment diagrams)：定义了系统硬件的物理体系结构，用来描述实际的物理设备以及它们之间的连接关系

静态图：类图、对象图；行为图：状态图、活动图、交互图(序列图、协作图)；实现图：组件图、部署图

1.2.  UML的规则

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

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

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

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

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

1.3.  UML中的公共机制

1.3.1.  规格说明

规格说明提供了对构造块的语法和语义的文字叙述，

对系统进行了可视化，用来描述系统的细节

提供了一个语义底板，包含了一个系统的各种模型的所有部分，并且各个部分相互联系，并保持一致，因此UML图只不过是对底板的简单视觉投影，每一个图展现了系统的一个特定的方面

1.3.2.  修饰

UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上

1.3.3.  通用划分

类/对象二分法：类是一个抽象；对象是这种抽象的一个具体形式。UML顶的每一个构造块几乎都存在像类/对象这样的二分法，例如：用例和用例实例(场景)，构件和构件实例，节点和节点实例等

接口/实现二分法：接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实实现接口的完整语义。几乎每一个UML的构造块都有像接口/实现这样的二分法

1.3.4.  扩展机制

对UML图示符号的扩展，包括构造型Stereotype、标注值Taggedvalue、约束Constraint