第六章 图

前言

建模实际上是对真实世界进行简化，从而可以更好地理解你要开发的系统。使用UML中基本的建筑块如：类、接口、关系、协作、组件、依赖、继承等，可以建立你想要的模型。还可以利用第五章介绍的机制扩充UML来表达问题领域独特的东西。

图是你组织这些建筑块的方式。图代表着一系列的元素，这些元素常常被画成用点（事物）和弧（关系）相连的图。利用图来从不同的视角来观察系统。由于没有一个复杂的系统可以从一个透视图弄明白，UML定义了一些图使得我们可以独立地从几个不同的视角来了解系统。

好的图使得你要开发的系统是易于理解和可以接近的。选择好的图对系统建模让你找到系统中真正要问的问题，帮助你阐述清楚你的系统。

术语和概念

系统是组织起来完成特定目标的一组子系统。系统可以用一组模型，可能来自不同的视角，进行描述。子系统是一组元素，其中一些通过包含的另外的元素组成特定的行为。模型是对系统进行语义上的抽象，它是整个真实系统的简化，为了更好地理解系统而创建的。图是一系列的元素，这些元素常常被画成用点（事物）和弧（关系）相连的图。利用图来从不同的视角来观察系统。

系统代表着你要开发的事物，通过不同的模型从不同的透视图来观察系统，这些透视图以图的形式表达。

在对真实世界进行建模的时候，你可以发现不管你的问题处于什么样的领域，你都会创建相同的图，因为他们代表着通用的模型的通用的视。通常，你利用下面的图来观察系统的静态部分：

1.         类图(Class Diagram)

2.         对象图(Object Diagram)

3.         组件图(Compoment Diagram)

4.         分布图(Deployment Diagram)

使用下面的五种额外的图来观察系统动态的方面：

1.         Usecase图

2.         序列图(Sequence Diagram)

3.         协作图(Collaboration Diagram)

4.         状态图(Statechart Diagram)

5.         活动图(Activity Diagram)

UML定义了这五种图。

结构化图（Structural Diagrams）

1.         类图(Class Diagram)          类、接口和协作

2.         对象图(Object Diagram)       对象

3.         组件图(Compoment Diagram)   组件

4.         分布图(Deployment Diagram)   节点（Notes）

类图 类图显示了一组类、接口和协作以及它们之间的关系。类图在面向对象的建模设计中是很常用的。利用类图阐明系统的静态的设计。包含活动类（active classes）的类图通常用来说明看到的系统静态过程。

对象图 对象图显示了一组对象和他们之间的关系。使用对象图来说明数据结构，类图中的类或组件等的实例的静态快照。对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。

组件图 组件图显示了一些组件和它们之间的关系。使用组件图来说明系统的静态实现。组件图和类图是有联系的，通常一个组件可以映射成一个或多个类，接口或协作。

分布图 分布图显示了一些节点和它们之间的关系。使用分布图来说明系统的静态结构。分布图和组件图是有联系的，通常一个节点封装了一个或多个组件。

动作图（Behavioral Diagrams）

UML中定义的动作图包括：

1.         Usecase图

2.         序列图(Sequence Diagram)

3.         协作图(Collaboration Diagram)

4.         状态图(Statechart Diagram)

5.         活动图(Activity Diagram)

Usecase图 Usecase图显示了一些Usecase和角色（特殊的类）和他们的关系。使用usecase图来描述系统静态的功能场景。Usecase图对于组织和模型化系统的动作是很重要的。

序列图 序列图是一种交互图（interaction diagram），强调的是时间和消息的次序。一个序列图显示了一系列的对象和在这些对象之间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用序列图来说明系统的动态情况。

协作图 协作图是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。

注意：序列图和协作图是同构的，它们相互之间可以转化而不损失信息。

状态图 状态图显示了一个状态机，由状态、转换、事件和活动组成。使用状态图说明系统动态情况。状态图对于建模接口的动作、类的动作或协作的动作是重要的。状态图强调的是事件驱动的对象的动作，这在对反应式系统的建模是相当重要的。

活动图：活动图显示了系统中从一个活动到另一个活动的流程。活动图显示了一些活动，他们很象传统的流程图有序列或分支。活动图对于给系统的功能建模是很重要的。活动图强调的是对象之间的流程控制。

通用建模技巧

1.         对系统的不同视进行建模

l         决定采用哪个视才能最好地表达系统的结构，以及暴露出项目的技术风险。前面讨论的五种图是很好的开始点。

l         对每一种视图决定要画那些图，通常一个视图会对应多个图

l         作为你的过程计划的一部分，决定那些图是要作为项目文档保存。

l         不要认为一次能够将图画好，最好准备一个装废纸的房间。

例如，如果你为一个简单的应用建模。你可能只需要其中一部分视图。

如果你是一个反应式的系统或系统的重点在处理流程上，你可能想包括状态图和活动图来建立系统的动作模型。

同样的，如果你是一个Client/Server系统，你可能想用组件图和分布图来为你的系统的物理细节进行建模。

最后，如果你是要对一个复杂的、分布式的系统建模，你需要使用所有的UML的图来表达系统的结构和项目的技术风险，如下所示：

1.         不同抽象层次建模

你不仅要从不同的视角观察系统，还要系统进行不同层次的抽象，因为参加项目开发的人可能对同一个系统的视图需要不同的抽象层次。对于程序员来说，他希望看到的是类的属性、方法，而对于一个系统分析员使用usecase场景来说只要看到存在这么个类就可以了，这里程序员要求的抽象层次较底层。可以通过隐藏或显示不同层次的细节来实现不同抽象层次的模型，或者创建不同层次抽象的图。

l         考虑你的读者的需要，从一个给定的模型开始

l         如果你的读者使用模型是构造一个实现，他需要的是较低层的抽象，也就是说他需要更多的细节。如果他利用概念模型只是为了和最终用户交流，他需要的是高层次的抽象，不需要细节的东西。

2.         复杂视图建模

l         首先确信没有更好的方法可以利用高层次的抽象表达要表达的信息，即便是删除一部分图或保留细节到另外一部分。

l         如果你隐藏了你所能隐藏的细节而你的图还是很复杂，考虑将一部分元素分组放到包里或放到较高层次的协作中，然后在你的图中只画这些包和协作。

l         如果你的图还是很复杂，使用注释或颜色来钩出你的重点好引起读者的注意

l         如果你的图依然很复杂，哈哈，打印出来，贴到墙上，将读者叫来亲自讲解给他听吧。希望他能明白……其实你可以自己慢慢研究，最后发现简化还是可以的。

联系本文作者：21newtimes@163.net
如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。