UML建模语言入门-视图,事物,关系,通用机制

原文：

[置顶] UML建模语言入门-视图,事物,关系,通用机制

链接：http://blog.csdn.net/shulianghan/article/details/16880717

分类： UML 2013-12-01 00:16 5805人阅读 评论(7)收藏举报

UML架构视图图通用机制

目录(?)[+]

一. UML视图

1. Rational Rose浏览器中的四个视图

用例视图(Use Case View) : 用例视图中包括 参与者, 用例, 用例图, 时序图 和 协作图, 用例视图与代码实现无关, 该视图关注系统的高层, 不关注如何具体实现.

逻辑视图(Logical View) : 逻辑视图中包括需要的特定类, 类图 和 状态图; 逻辑视图关注如何实现用例视图中的具体功能, 将组件之间的关联, 系统如何运作的详细图形画出来.

组件视图(Component View) : 组件视图包括模型代码库, 可执行文件, 运行库等组件信息; 组件是代码的实际模块, 组件 和 组件图在组件视图中显示, 组件视图显示代码模块之间的关系.

配置视图(Deployment View) : 配置视图 相当于 系统的实际配置, 与逻辑结构有所不同, 系统结构是三层的, 但是对应的配置视图可能是两层的.

2. RUP 4+1 视图

四种视图之间的关系 :用例视图(Use Case View)是系统的核心, 其它的四个视图都要基于Use Case View展开;逻辑视图(Logical View)中包括静态结构和动态行为,实现视图(Implementation View)依赖逻辑视图的静态结构,进程视图(Process View)依赖逻辑视图的动态行为;配置视图依赖进程视图 与 实现视图;

(1) 逻辑视图(Logical View)

使用者 : 设计人员, 开发人员.

实现需求 : 系统功能.

作用 : 揭示系统的内部设计和协作情况, 逻辑视图实现系统功能角度 : 静态结构 , 动态行为.

静态结构 : 描述 类, 对象, 关系.

动态行为 : 描述对象之间发动消息产生的动态协作, 一致性, 并发.

UML对等视图: 逻辑视图(Logical View).

(2) 实现视图(Implementation View)

使用者 : 码农

实现需求 : 系统的可扩展性, 可移植性, 可重用性, 易用性, 易测试性.

作用 : 描述软件的静态结构, 显示代码之间的组织方式, 通过系统输入输出关系的模型图 和 子系统图, 来描述实现模块之间的依赖关系. 

内部需求 : 开发难易程序, 重用可能性, 通用性, 局限性等; 层次越低的组件通用性越好.

UML对等视图 : 组件视图(Component View). 

(3) 进程视图(Process View)

使用者 : 系统集成.

实现需求 : 稳定性, 安全性, 伸缩性, 鲁棒性.

作用 : 显示系统并发性, 解决在并发系统中存在的通信和同步问题, 该视图显示进程, 线程, 对象等运行时状态, 以及相关同步, 并发, 通信等问题.

进程视图与实现视图关系 : 实现视图显示的是编译时的静态关系, 进程视图显示的是编译完之后运行时的对象, 线程, 进程之间的交互问题.

UML对等视图 : 并发视图(Concurrency View).

(4) 配置视图(Deployment View)

使用者 : 运维

实现需求 : 拓扑结构, 系统安装, 通信.

作用 : 软件到硬件的映射, 目标程序及其依赖的运行库和系统软件部署到物理机器上去, 以及部署机器和网络配合软件系统的可靠性,可伸缩性等要求. 配置视图综合考虑软件系统和整个IT系统相互影响的架构视图.

配置视图与进程视图关系 : 进程视图关注程序的动态执行情况, 配置视图关注程序的静态位置.

UML对等视图 : 配置视图(Deployment View).

(5) 用例视图(Use Case View)

使用者 : 全部人员

作用 : 描述用户需要的系统功能. 用例是客户要求的系统中的一个功能单元, 相当于参与者与系统之间的一次交互. 用例模型列出系统中的用例和参与者, 显示哪个参与者执行哪个用例.

核心 : 用例视图是其它四种视图的核心, 其作用是驱动其它视图开发.

二. UML中的事务

UML中事务是模型中首要成分的抽象,关系把事务结合在一起,图聚集了相关事务.

事务是UML中面向对象的基本模块, UML中事务包括 结构事务,行为事务,组织事务,辅助事务. 事务在模型中属于静态部分, 代表物理上或概念上的元素.

1. 结构事物(Structure Things)

      

结构事务是模型中的 静态事务, 主要包括7种, 类 接口 用例 协作 活动类 组件 节点.

(1) 类 (Class)

类具有相同属性, 方法, 语义, 关系的集合; 一个类可以实现一个或者多个接口, UML中, 类包括类名, 属性名, 方法;

(2) 接口 (Interface)

接口是类或组件提供的可以完成特定功能的操作集合, 接口描述了类或者组件对外的可见的操作. 一个类可以实现多个接口.

(3) 用例 (Use Case)

用例定义了系统的一组操作, 特定的用户可以执行该操作.

(4) 协作 (Collaboration)

协作是交互的操作, 角色和其它元素一起工作, 提供一些合作的动作 . 类可能是协作的组成部门, 协作代表构成的系统的实现.

(5) 活动类 (Active Class)

类对象有一个或多个进程或线程的类是活动类, 活动类与类相似, 活动类对象代表的元素的行为与其它的元素同时存在.

(6) 组件(Component)

组件是物理上可替换的, 实现一个或多个接口的系统元素. 

(7) 节点(Node)

节点是物理元素, 运行时存在, 代表一个可计算的资源, 例如服务器, 进程等. 

2. 行为事物(Behavior Things)

行为事务又叫动作事务, 与结构事务不同, 是UML模型中的动态部分, 代表时间和空间上的动作, 结构事务是UML模型中的静态部分.

行为事务有两种 : 交互 ,状态机. 它们是UML模型中最基本的两个动态事务元素, 

(1) 交互(Interaction)

交互是在特定上下文中的一组对象, 这一组对象为共同完成一定的任务进行一系列消息交换所组成的动作就是交互. 交互包括消息,动作序列(消息产生的动作),对象之间的连接组成. 交互中的消息通常画成带箭头的直线.

(2) 状态机(State Machine)

状态机是对象一个或多个状态的集合.

3. 组织事物 (Grouping Things)

组织事物又叫分组事物, 只有一种, 就是 包(Package).

组织事物是UML模型中组织部分, 相当于一个盒子, 每个盒子中的对象关系比较复杂;盒子与盒子之间的关系相对简单.

包是一种将一系列元素分组的机制;组件也是元素分组的机制; 

包与组件区别 : 包是一种概念上的东西, 仅存在与开发阶段, 组件是一种物理元素,存在于运行时.

4. 辅助事务(Annotation Things)

辅助事务就是注释.

三. UML中的关系(Relationship)

UML中的关系主要有5种 : 关联关系, 聚合关系, 依赖关系, 泛化关系, 实现关系.

(1) 关联关系(Association)

关联关系是结构化关系, 指一种对象和另一种对象有关联. 两个对象有关联就是从一个对象中可以访问到另一个对象, 即就是在类中将另一个类的对象声明为成员变量. 

双向关联 : 如果两个类互相声明对方对象为成员变量, 那么这个关联就是双向关联; 

单向关联 : 如果两个类中只有一个类声明另一个类对象为成员变量, 那这个关联成为单向关联.

关联关系表示 : 关联关系用一条实线表示.

(2) 聚合关系

聚合概念 : 类之间的关系是整体与部分之间的关系, 一个表示整体的模型元素可能由多个表示部分的模型元素聚合而成, 如汽车由发动机, 轮胎聚合而成.

共享聚合 : 如果聚合中表示部分的模型还参与其它整体对象的聚合, 那么该聚合是共享聚合;

复合聚合 : 如果聚合中表示部分的模型只隶属于整体类, 那么该聚合就是复合聚合.

复合聚合表示 : 聚合关系用一端带空心菱形的直线表示, 菱形端连接表示整体事物的模型元素.

组合关系 : 组合关系是比聚合关系更紧密的耦合关系, 部分类需要整体类才能存在, 整体类被销毁, 部分类也要随之销毁.

组合关系表示 : 一端带有实心的小菱形直线表示, 小菱形端连接表示整体事物的模型元素.

(3) 依赖关系 (Dependency)

依赖关系描述两个模型元素之间的语义关系 : 一个模型元素是独立的, 另一个不是独立的, 非独立的模型元素依赖于独立模型元素, 独立模型改变将影响依赖于其的非独立模型. 

关联关系与依赖关系区别 : 依赖关系的对象间表现非固定关系, 如手机与充电器, 手机不是时刻都需要充电器的, 但是没有充电器, 手机就玩不转.

4. 泛化关系 (Generalization)

泛化关系定义了一般元素和特殊元素之间的分类关系, 泛化类似于继承关系. 可以分为普通泛化 和受限泛化.

普通泛化 : 没有给泛化添加约束, 普通泛化用一条带空心箭头的实线表示.

受限泛化 : 给泛化附加约束条件, 说明泛化关系的使用方法和扩充方法. 预定义的约束有4种 : 多重, 不相交, 完全, 不完全.

5. 实现关系 (Realization)

将一种模型元素(类)与另一种模型元素(接口)连接起来, 接口只是行为的说明, 不是结构或者实现.

两种实现关系 :接口与实现它的类之间的关系,用例和实现它的协作之间的关系.

实现关系表示 : 实现关系用一条带空心的虚线箭头表示.

四. UML 中的图

UML中的图分为两类, 结构行为图 和动态行为图. 

结构行为图 :类图 ,对象图 ,用例图 ,组件图 ,配置图 .

动态行为图 :状态图 ,活动图 ,时序图 ,协作图 .

每个图中的概念 

类图 : 类 , 关联 , 泛化 , 依赖关系 , 实现 , 接口 .

用例图 : 用例 , 参与者 , 关联 , 扩展 , 包括 , 用例泛化 .

组件图 : 组件 , 接口 , 依赖关系 , 实现 .

配置图 : 

状态图 : 

活动图 : 

时序图 : 

协作图 : 

1. 用例图 (Use Case Diagram)

用例图展现了一组 用例  参与者 它们之间的关系. 可以描述系统的静态使用情况. 

下面的用例图中 : 用户 和 ATM机 是参与者, 插入卡 输入密码是用例.

2. 类图 (Class Diagram)

类图展示了 类  接口  协作 之间的关系, 一个系统有多个类图, 高层建模给出类的主要职责, 底层建模给出类的属性和操作. 

下图中 人民币账户 美元账户 从账户类继承, 它们是泛化关系. 账户与ATM机 , 用户与两种账户是关联关系.

3. 对象图 (Object Diagram)

对象图 是 类图的变体, 对象图使用与类图相似的符号描述. 

对象图与类图的区别 : 

表示的概念 : 对象图显示的是类的多个对象, 而非实际的类. 对象图是类的一个例子, 显示系统执行时的一个快照, 即在某一个时间点上系统可能呈现的样子. 

表示不同 : 对象图使用带下划线的对象名称来表示对象, 显示一个关系中的所有实例.

4. 组件图

组件图 由 组件接口 组件之间的关系组成. 组件 可以是 源码 二进制码 可执行程序. 组件图表示系统不同的物理部件及其关系.

下图中, 组件1 和 组件3 都依赖于 组件2.

5. 配置图 (Deployment Diagram)

定义 : 配置图展现运行时处理节点(服务器,主机) 以及 其中组件的配置(打印机,扫描仪). 配置图可以说明系统结构的静态配置图, 即 分布 交付 安装 的物理系统. 

描述硬件 : 配置图描述系统硬件的物理拓扑结构, 即网络布局和组件在网络中的位置; 

描述软件 : 描述在设备上执行的软件, 即运行时软件在节点中的分布情况. 

6. 时序图 (Sequence Diagram)

时序图含义 : 

a. 动态协作 : 时序图显示多个对象间的动态协作, 主要是显示对象之间发送消息的时间顺序. 

b. 时间点预测 : 时序图也显示对象之间的交互, 即在系统执行的时候,某个时间点将会发生的事情. 

时序图用途 :表示用例中的行为顺序, 当执行一个用例行为的时, 时序图中每一条消息对应了一个类操作, 或状态机中引起装换的触发事件.

7. 协作图 (Collaboration Diagram)

组织结构建模 : 协作图对交互中有意义的对象和对象之间的连接建模, 强调收发消息对象的组织结构, 按照组织结构对控制流建模.

显示关系 : 除了显示消息的交互之外, 协作图还显示对象 及对象之间的关系.

8. 状态图 (Statechart Diagram)

状态图定义 : 状态图显示一个对象所有可能的状态 , 以及各种事件发生而引起的状态转移.

状态图的作用 : 状态图描述了一个状态机, 用状态图说明系统的动态视图. 

状态图建模 : 状态图对接口,类, 协作的行为建模很重视, 可以用来描述实例的生命周期.

开始结束分别用实心圈和带环的圈表示.

9. 活动图 (Activity Diagram)

活动图是状态图的变体, 显示系统从一个活动到另一个活动的流程, 活动图显示了一些活动, 强调是对象之间的流程控制. 

五. 通用机制

UML中的通用机制, 使UML变得简单, 易于使用. 使用通用机制可以为模型元素提供额外的注释,信息或语义. 

1. 修饰

修饰表示 : UML建模时, 可以将图形修饰附加到UML图形的模型元素上. 通常修饰写在相关元素旁边, 所有对修饰的描述与它们所影响的元素的描述放在一起.

修饰作用 : 为图形中的元素增加语义. 

修饰例子 : 当一个元素代表一个类型的时候, 名称可以用粗体来表示; 当一个元素代表一个类型的实例的时候, 名称可以用下划线表示; 当一个元素代表接口的时候, 那么其名称用斜体表示. 表示类的方法的时候 : "-"表示私有, "+"表示公有, "#"表示保护类型.

2. 注释

注释用一条虚线连接到其解释的元素上, 注释可以使模型更加清晰.

注释使用技巧 : 

a. 依赖 : 将注释放在需要注释的元素旁边, 使用依赖关系连接, 注释依赖于元素.

b. 隐藏 : 注释平时可以隐藏;

c. 嵌入 : 如果注释很长, 可以放到外部文本中, 然后嵌入到模型中.

3. 规格说明

模型元素具有许多用于维护该元素的数据值特性, 特性用名称和被称为标记值的值定义.

标记值 : 标记值是一种特定的类型, 如整型, 字符串.

名称 : UML中特性是预定义的, 如文档(Documentation), 职责(Responsibility), 永久性(Persistence), 并发性(Concurrency).

4. 通用划分 (General Division)

(1) 型-实例

定义 : 型-实例(Type-Instance)描述了一个通用描述符与单个元素之间的对应关系. 通用描述符成为型元素, 它相当于类, 单个元素是实例元素, 相当于类的实例; 一个型元素可以对应多个实例元素.

表示 : 实例元素使用与通用描述符相同的表示图形, 但是名称的表示不同. 实例元素名称带有下划线, 并且实例元素名称后面还要加上冒号和通用描述符.

举例 : 类 与 对象 相当于一种 型-实例划分, 数据类型 与 数据值 .

(2) 接口-实现

接口生命了一个规定了服务的约定, 实现负责执行接口的全部语义, 并实现该项服务.

5. 扩展机制

UML扩展机制允许UML使用人员根据需要自定义一些构造型语言, 扩展机制既可以扩展UML功能, 还可以使语言用户化.

20140106增订：

原文：

UML类图关系中关联 聚合 依赖关系及其区别

链接：http://developer.51cto.com/art/201007/210467.htm

本文和大家重点讨论一下UML类图关系方面的内容，UML类图关系主要有关联，聚合/组合，依赖，泛化等几种，这里向大家介绍一下关联，聚合和依赖这三种关系及其区别。

UML类图关系

1、关联

双向关联：

C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。

在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。
双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值。

单向关联:

C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。
单向关联的代码就表现为C3有C4的指针，而C4对C3一无所知。

自身关联（反身关联）：

自己引用自己，带着一个自己的引用。就是在自己的内部有着一个自身的引用。

2、聚合/组合

当类之间有整体-部分关系的时候，我们就可以使用UML类图关系中的组合或者聚合。

聚合：表示C9聚合C10，但是C10可以离开C9而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解，请看下面组合里的解释）。

组合（也有人称为包容）：一般是实心菱形加实线箭头表示，如上图所示，表示的是C8被C7包容，而且C8不能离开C7而独立存在。但这是视问题域而定的，例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的，因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里，就算轮胎离开了汽车，它也是有意义的，这就可以用聚合了。在《敏捷开发》中还说到，A组合B，则A需要知道B的生存周期，即可能A负责生成或者释放B，或者A通过某种途径知道B的生成和释放。

3、依赖

UML类图关系中的依赖指C5可能要用到C6的一些方法，也可以这样说，要完成C5里的所有功能，一定要有C6的方法协助才行。C5依赖于C6的定义，一般是在C5类的头文件中包含了C6的头文件。ROSE对依赖关系不产生属性。

注意，要避免双向依赖。一般来说，不应该存在双向依赖。

虽然ROSE不生成属性，但在形式上一般是A中的某个方法把B的对象作为参数使用(假设A依赖于B)。如下：
#include"B.h"
classA
...{
voidFunc(B&b);
}

那UML类图关系中依赖和聚合\组合、关联等有什么不同呢？

关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。这种关系是非常明显的，在问题领域中通过分析直接就能得出。

依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。

组合是一种整体-部分的关系，在问题域中这种关系很明显，直接分析就可以得出的。例如轮胎是车的一部分，树叶是树的一部分，手脚是身体的一部分这种的关系，非常明显的整体-部分关系。
上述的几种关系（关联、聚合/组合、依赖）在代码中可能以指针、引用、值等的方式在另一个类中出现，不拘于形式，但在逻辑上他们就有以上的区别。

原文：

图例解析四大UML关系图使用

链接：http://developer.51cto.com/art/201007/209644.htm

本文和大家重点讨论一下UML关系图，UML中有五类图，共有九种图形，UML类之间的UML关系图你是否熟悉，这里就向大家介绍一下，希望通过本文的介绍你对类之间的UML关系图软件开发有一定的认识。
 

类之间的UML关系图软件开发

类间关系有很多种，在大的类别上可以分为两种：纵向关系、横向关系。
纵向关系就是继承关系，它的概念非常明确，也成为OO的三个重要特征之一，这里不过多的讨论。

横向关系较为微妙，按照UML的建议大体上可以分为四种：

1.依赖（Dependency）

2.关联（Association）

3.聚合（Aggregation）

4.组合（Composition）

它们的强弱关系是没有异议的：依赖<关联<聚合<组合

然而它们四个之间的差别却又不那么好拿捏，需要好好体会。

1.依赖：

UML表示法：虚线+箭头

 

关系："...usesa..."

UML关系图中的依赖关系最为简单，也最好理解，所谓依赖就是某个对象的功能依赖于另外的某个对象，而被依赖的对象只是作为一种工具在使用，而并不持有对它的引用。

释义：一个人自创生就需要不停的呼吸，而人的呼吸功能之所以能维持生命就在于吸进来的气体发挥了作用，所以说空气只不过是人类的一个工具，而人并不持有对它的引用。

 

2.关联：

UML表示法：实线+箭头

关系："...hasa..."

UML关系图中所谓关联就是某个对象会长期的持有另一个对象的引用，而二者的关联往往也是相互的。关联的两个对象彼此间没有任何强制性的约束，只要二者同意，可以随时解除关系或是进行关联，它们在生命期问题上没有任何约定。被关联的对象还可以再被别的对象关联，所以关联是可以共享的。

释义：人从生至死都在不断的交朋友，然而没有理由认为朋友的生死与我的生死有必然的联系，故他们的生命期没有关联，我的朋友又可以是别人的朋友，所以朋友可以共享。

 

3.聚合：

UML表示法：空心菱形+实线+箭头

 

关系："...ownsa..."

UML关系图中的聚合是强版本的关联。它暗含着一种所属关系以及生命期关系。被聚合的对象还可以再被别的对象关联，所以被聚合对象是可以共享的。虽然是共享的，聚合代表的是一种更亲密的关系。

释义：我的家和我之间具有着一种强烈的所属关系，我的家是可以分享的，而这里的分享又可以有两种。其一是聚合间的分享，这正如你和你媳妇儿都对这个家有着同样的强烈关联；其二是聚合与关联的分享，如果你的朋友来家里吃个便饭，估计你不会给他配一把钥匙。

 

4.组合：

UML表示法：实心菱形+实线+箭头

 

关系："...isapartof..."

UML关系图中的组合是关系当中的最强版本，它直接要求包含对象对被包含对象的拥有以及包含对象与被包含对象生命期的关系。被包含的对象还可以再被别的对象关联，所以被包含对象是可以共享的，然而绝不存在两个包含对象对同一个被包含对象的共享。

 

释义：组合关系就是整体与部分的关系，部分属于整体，整体不存在，部分一定不存在，然而部分不存在整体是可以存在的，说的更明确一些就是部分必须创生于整体创生之后，而销毁于整体销毁之前。部分在这个生命期内可以被其它对象关联甚至聚合，但有一点必须注意，一旦部分所属于的整体销毁了，那么与之关联的对象中的引用就会成为空引用，这一点可以利用程序来保障。心脏的生命期与人的生命期是一致的，如果换个部分就不那么一定，比如阑尾，很多人在创生后的某个时间对其厌倦便提前销毁了它，可它和人类的关系不可辩驳的属于组合。
在UML中存在一种特例，就是允许被包含对象在包含对象销毁前转移给新的对象，这虽然不自然，但它给需要心脏移植的患者带来了福音。

原文：

UML元素和UML关系图符号简介

链接：http://developer.51cto.com/art/201007/209527.htm

本文和大家重点讨论一下UML元素和UML关系图符号。开发Java应用程序时，开发者要想有效地利用统一建模语言（UML），必须全面理解UML元素以及这些元素如何映射到Java。本文重点讨论UML类图中的元素和UML关系图符号。

UML元素简介

类图是最常用的UML图，它用于描述系统的结构化设计。其中包括类关系以及与每个类关联的属性及行为。类图能出色地表示继承与合成关系。为了将类图作为一种高效的沟通工具使用，开发者必须理解如何将类图上出现的元素转换到Java中。下面来进一步探索这一转换过程。
在后面的小节中，分别讲解了类图的各个元素及其在Java中相应的表示。我会列出元素名，后续简短的代码片断和一幅图来表示元素在类图上的样子。每一节的最后简要总结了该元素。

类（Class）

类（图A）是对象的蓝图，其中包含3个组成部分。第一个是Java中定义的类名。第二个是属性（attributes）。第三个是该类提供的方法。

属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型，如图A的“Java”区域所示。
图A

　C#:
第一行:类名,如果是抽象类,则用斜体显示.
第二行:字段或属性.
第三行:类的操作(方法或者行为).
+:表示public;-:表示:private;#:表示protected;

包（Package）

包（图B）是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。进行建模时，你通常拥有逻辑性的包，它主要用于对你的模型进行组织。你还会拥有物理性的包，它直接转换成系统中的Java包。每个包的名称对这个包进行了惟一性的标识。
图B

接口（Interface）

接口（图C）是一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口既可用图C的那个图标来表示，也可由附加了<<interface>>的一个标准类来表示。通常，根据接口在类图上的样子，就能知道与其他类的关系。
图C

C#:
它表示一个接口图，与类图的区别主要是顶端有<<interface>>显示。第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了‘讲人话’的接口。”

UML关系图符号

后面的例子将针对某个具体目的来独立地展示各种关系。虽然语法无误，但这些例子可进一步精炼，在它们的有效范围内包括更多的语义。

依赖（Dependency）

实体之间一个“使用”关系暗示一个实体的规范发生变化后，可能影响依赖于它的其他实例（图D）。更具体地说，它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量，对通过方法调用而获得的一个对象的引用（如下例所示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）。也可利用“依赖”来表示包和包之间的关系。由于包中含有类，所以你可根据那些包中的各个类之间的关系，表示出包和包的关系。
图D

“动物几大特征，比如有新陈代谢，能繁殖。而动物要有生命力，需要氧气、水以及食物等。也就是说，动物依赖于氧气和水。他们之间是依赖关系（Dependency），用虚线箭头来表示。”

关联（Association）

实体之间的一个结构化关系表明对象是相互连接的。UML关系图符号中关联关系的箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。在Java中，关联（图E）转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样。可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示着实例之间的关系。在示范代码中，Employee可以有0个或更多的TimeCard对象。但是，每个TimeCard只从属于单独一个Employee。
图E

聚合（Aggregation）

UML关系图符号中聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系。聚合暗示着整体在概念上处于比局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别。聚合也转换成Java中的一个实例作用域变量。

关联和聚合的区别纯粹是概念上的，而且严格反映在语义上。聚合还暗示着实例图中不存在回路。换言之，只能是一种单向关系。
图F

合成（Composition）

合成（图G）是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责。合成也是非共享的。所以，虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局部的存活状态，要么负责将其销毁。局部不可与其他整体共享。但是，整体可将所有权转交给另一个对象，后者随即将承担生存期职责。
Employee和TimeCard的关系或许更适合表示成“合成”，而不是表示成“关联”。
图G

泛化（Generalization）

泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系。UML关系图符号中泛化是用于对继承进行建模的UML元素。在Java中，用extends关键字来直接表示这种关系。
图H

实现（Realization）

实例（图I）关系指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。对Java应用程序进行建模时，实现关系可直接用implements关键字来表示。
图I

原文：

UML中各种UML图形的建立步骤简明介绍

链接：http://developer.51cto.com/art/201006/204811.htm

在学习UML的过程中，你经常会遇到UML图的问题，本节向大家介绍一下UML中各种UML图形的建立步骤，希望通过本节的学习，你对如何建立各种UML图形有一定的了解。

UML中各种UML图形的建立步骤

关于UML中各种图形的建立步骤，在学习过程中总结出来的笔记，希望对大家能有帮助。

1．UML图中用例图的建立步骤：

1〉找出系统外部的活动者和外部系统，确定系统的边界和范围。
2〉确定每一个活动者所希望的系统行为。
3〉把这些系统行为命名为用例。
4〉把一些公共的系统行为分解为一批新的用例，供其它的用例引用。把一些变更的行为分解为扩展用例。
5〉编制每一个用例的剧本。
6〉绘制用例图。
7〉区分主业务流和例外情况的事件流。可以把表达例外的情况的事件流的用例图画成一个单独的子用例图。
8〉精化用例图，解决用例见得重复与冲入问题，简化用例中的对话序列，用力图可以有不同的层次，高层次系统的用例可以分解为若干个下属子系统中的子用例。

2．UML图中对象类图的建立步骤：

1〉研究分析问题领域，确定系统的需求。
2〉发现对象和对象类，明确他们的含义和责任，确定属性和操作。
3〉发现类之间的静态联系。着重分析找出对象类之间的一般和特殊关系，部分与整体关系，研究类的继承性和多态性，把类之间的静态联系用关联、泛化、聚合、组合、依赖等联系表达出来，虽然对象类图表达的是系统的静态结构特征，但是应当把对系统的静态分析与动态分析结合起来，更能准确地了解系统的静态结构特征。
4〉设计类与联系。调整和精化已得到的对象类和类之间的联系，解决诸如命名冲突、功能重复等问题。
5〉绘制对象类图并编制相应的说明。上述做法是直接从领域分析抽取对象和对象类开始的，这是常规的面向对象的系统分析与设计的做法。Rational统一过程主张采用用例驱动的系统分析与设计方法。从业务领域的分析中先抽取活动者和用例，建立业务模型。业务模型包括业务用例模型、设计模型、实现模型和测试模型。

3．系统中的例外情况建模：

1〉对于每一个对象类和接口，找出可能发生的例外情况和出现例外情况的条件。
2〉把每一个例外情况用一个信号类描述，类名前冠有构造型“exception”。
3〉建立例外情况的层次结构，把一般性的例外情况置于高层，把特殊性的例外情况置于低层。
4〉对于每一个操作确定可能发生的例外情况。在操作和其例外情况的信号图表之间有一条虚箭线连接，其上标出构造型“send”，表示从操作到其例外情况的send依赖。

4．UML图中顺序图的建立步骤：

1〉确定交互的上下文。
2〉找出参与交互的对象类角色，把他们横向排列在顺序图的顶部，最重要的对象安置在最左边，交互密切的对象尽可能相邻。在交互中创建的对象在垂直方向应安置在其被创建的时间点处。
3〉对每一个对象设置一条垂直的向下的生命线。
4〉从初始化交互的信息开始，自顶向下在对象的生命线之间安置信息。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层还是属于实例层，给出消息标签的内容，以及必要的构造型与约束。
5〉在生命线上绘出对象的激活期，以及对象创建或销毁的构造型和标记。
6〉更具消息之间的关系，确定循环结构及循环参数和出口条件。

5．UML图中协同图的建立步骤：

1〉确定交互的上下文。
2〉找出参与交互的对象类角色，把他们作为图形的节点安置在协同图中。最重要的对象安置在图的中央，与其有直接交互的对象安置在邻近。
3〉设置对象的初始性质。
4〉说明对象之间的链接。首先给出对象之间的关联连接，然后给出其它连接，并且给出必要的装饰，如构造型“global”，“local”等。
5〉从初始化交互的消息开始，在链接上安置相应的消息，给出消息的序号。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层还是属于实例层，给出消息标签的内容，以及必要的构造型和约束。
6〉处理一些特殊情况，如循环、自调用、回调、多对象等。

20140106结束