uml各种图例及说明(摘录)

1、用例图

描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

2、类图

类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。

3、对象图

与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。

4、活动图

描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

5、状态图

描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事 件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的 类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。

6、序列图（顺序图）

序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图

和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。

 

8、构件图 （组件图）

描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。

9、部署图 （配置图）

是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。

-------------------------------------------------------------------------------------------------------------

一：这九种模型图各有侧重，

1:用例图侧重描述用户需求，

2:类图侧重描述系统具体实现；

二：描述的方面都不相同，

1:类图描述的是系统的结构，

2:序列图描述的是系统的行为；

三：抽象的层次也不同，

1：构件图描述系统的模块结构，抽象层次较高，

2：类图是描述具体模块的结构，抽象层次一般，

3：对象图描述了具体的模块实现，抽象层次较低。

 

将这九种模型图分为三大类：

结构分类、动态行为和模型管理：

1：结构分类包括用例图、类图、对象图、构件图和部署图，

2：动态行为包括状态图、活动图、顺序图和协作图，

3：模型管理则包含类图。

 

 

--------------------------

UML(统一建模语言)：是面向对象的可视化建模的一种语言。是数据库设计过程中，在E-R图（实体-联系图）的设计后的进一步建模。
UML中有3种构造块：事物、关系和图，事物是对模型中最具有代表性的成分的抽象；关系是把事物结合在一起；图聚集了相关的的事物。具体关系图标如下：

 

说明：
构件事物是名词，是模型的静态部分。
行为事物是动态部分，表示行为。
分组事物是组织部分。
注释事物是解释部分。

依赖：一个事物变化会引起另一个事物变化。
聚集：特殊的关联，描述整体与部分的组合关系。
泛化：是一种特殊与一般的关系，如子元素（特殊）与父元素（一般），箭头指向父元素。
实现：类元之间的关系，其中一个类元指定了由另一个类元保证执行的契约。一般用在接口和实现他们的类之间或用例和实现它们的协作之间。

UML提供9种视图：类图、对象图，用例图，序列图、协作图，状态图、活动图，构件图和部署图。

在UML系统开发中有三个主要的模型：

功能模型: 从用户的角度展示系统的功能，包括用例图。
对象模型: 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图。
动态模型: 展现系统的内部行为。 包括序列图，活动图，状态图。

下面具体说明：

1.类图：描述一组对象、接口、协作等事物之间的关系。如下图(摘自网络)：

 

注：#表示protected，+表示Public，-表示private

 

2.对象图：描述一组对象之间的关系，是具有具体属性值和行为的一个具体事物，其是类图中所建事物实例的静态快照，其与类图的主要区别是一个是抽象的,而对象图是具体的。如下图(摘自网络)：

 

3.用例图：描述一组用例、参与者以及它们之间的关系，其展示的是该系统在它的外面环境中所提供的外部可见服务。如下图(摘自网络)：

 

4.交互图：包括序列图（顺序图）和协作图，两者对应，顺序图是强调消息时间顺序，有对象生命线和控制焦点。协作图是强调接收和发送消息的对象的结构组织，有路径和顺序号。如下图(摘自网络)：

序列图：

 

协作图：

 

5.状态图：展示了一个状态机，由状态、转换、事件和活动组成。强调事件行为的顺序。如下图(摘自网络)：

 

6.活动图：是一种特殊的状态图，实现一个活动到另一个活动的流程。如下图(摘自网络)：

 

7.构件图和部署图：构件图展示一组构件之间的组织和依赖关系，并以全局的模型展示出来。部署图是构件的配置及描述系统如何在硬件上部署。如下图(摘自网络)：

 

-------------------

在很大程度上，UML是一种图形语言，用来描述、记录、设计和构造解决方案。UML的强大作用体现在：为用户、开发人员、分析师、客户和软件开发过 程中的其他股东提供了一种公共语言，使所有成员可以理解并由此进行交流。进一步讲，UML独立于编程语言，故使用面广，采用这种语言时，开发团队不需要在 分析、描述和同意要求、工作流和约束前作出技术决策。

这些模型有一个共同点，要设计和描述软件解决方案，单个模型无法满足要求。任何一个模型都不足以描述问题或设计解决方案，总需要一组模型。UML新 手经常会提这样一个问题，该使用哪种模型？对于这个问题，实在给不出明确的答案，因为这取决于解决方案的复杂性，以及股东的特点。如果解决方案的问题简单 明了，例如构建的一个软件解决方案显示一个Web 页(ASP)，描述有关小卖部开张时间的信息，而另一个解决方案计算所有个人或单位的年纳税额，则前者的模型肯定没有后者多，也不如后者详细。本书的案例 研究将讨论在什么时候使用什么模型。凭经验判断，模型的数量和明细级别应达到所有股东能够处理解决方案的程度。

UML中包含的模型,分为三类：功能、行为和实现。功能类别模型用来收集要求和描述功能。行为类别模型用于描述解决方案的对象和用户的行为。实现类别模型用于解决方案功能和行为的物理实现。

功能： 用例图、类图
行为：交互图（顺序图和协作图）、状态图、活动图
实现：、组件图、部署图

一、功能图
功能图构建解决方案功能的模型。换言之，如果要弄清解决方案能做什么，则查看功能图。功能图是用例图和类图。查看这些图，将准确了解解决方案的作用及开发方式。顺序图也显示功能，但将顺序图归入行为类别，因为它们的面向行为特性更明显。

1. 用例图
一般首先构建用例图，该图用来收集用户要求。用例图是从用户角度查看的解决方案。应该使用用户能够理解的语言讨论解决方案。在这一阶段，不应提及触发器和数据库约束等。用例模型由行动者和用例，及它们之间的关系组成。

行动者(actor)指与系统交互的某人或某事。行动者要么从解决方案接收信息，要么将信息传给系统。行动者的图形是一个人形。行动者经常表示人 (如用户)，也表示另一个IT系统。例如，企业资源规划(Enterprise Resource Planning，简写ERP)系统可从电子商务解决方案接收数据，换言之，ERP系统是电子商务解决方案的一个行动者。人员行动者的例子如从自动取款机 (ATM)取钱的客户。此处的客户是一个与ATM系统相关的行动者。

用例是一个过程，其表示符号是一个椭圆

2. 类图
类图用于收集要求阶段。它提出问题，如可能发生什么，并验证系统确能完成要求。一般从项目团队和开发人员的角度查看类图。

在类图中，绘制逻辑和物理实体，以及解决方案中对象的关系。换言之，构建用例图中识别的类的模型。本例的候选对象包括Customer和 Order。故在类图中构建Customer类和Order类的模型。这些可能是传统的面向对象的类，也可能是诸如ASP页、数据库表或COM+组件的非 面向对象的类。

UML类的表示符号是一个矩形，如图3-6所示。由图可知，该类有一些属性(CustomerID和Date等)和一些方法(New、PlaceOrder和Delete)。
在类图中，类相互之间具有关系。例如，Customer可将若干个Order放入系统。类之间的关系用实线表示，如图3-7所示。

二、 行为图
行为图描述解决方案的行为或交互。此类图构建解决方案中发生的事情。只有了解这些内容才能开发解决方案。

1. 交互图
UML有两类交互图：顺序图和协作图。这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而协作图显示任务 和信息(对象)的交互方式。在协作图中，时间以编码形式显示，很难选取。虽然存在这些根本区别，但这两类图有相同之处：都用于显示对象和用户如何交互以执 行任务。

对UML新手而言，很难记住该使用哪一种交互图。幸运的是，可以用一个简单方法来解决这个问题。可从图的名称中加以判断。顺序图描述如何按时间顺序 执行交互。协作图显示信息和任务的交互方式，不过分强调时间。有时要同时使用这两种类型，但在构建交互模型时，要使用一些策略：

if 基于时间 then

顺序图

else (注重于组织方面)

协作图

end if

2. 状态图
在设计面向对象的解决方案中，用状态图来显示对象的生命期。

用实框符号表示状态，实线箭头表示转换。另外，实心圈指示起点，实心圈外加一个空圈表示终点。

注意：

状态图只用来显示对象的各种可能状态，以及如何从一个状态转换到另一个状态。换言之，对象的生命期用状态图来表示。

3. 活动图
初看起来，活动图很难理解。但是，活动图只是描述工作流以及谁完成工作的方式，与流行的数据流程图类似。实际上，可将活动图视为数据流程图。

活动图使用的符号与状态图使用的符号相近。在活动图中，用拉长的椭圆表示活动，用圆角框表示状态。顾名思义，“活动”是执行的动作，如验证订单 (validate order)。“状态”表示对象的可能状态；例如，在验证订单后，订单进入Validated Order(已验证订单)状态。活动图的有趣部分是泳道(swimlane)，由竖线表示。使用泳道，可大体了解系统中的各个行动者/部门，以及它们执行 的任务。如果有过多行动者参与，或在泳道间频繁切换，则可能导致错误或延迟，通过活动图，可发现这些问题。此分析有助于优化业务过程。

通过活动图，可概览系统和工作流程；有时，活动图也用于过程建模。
三、 实现图
实现图描述如何打包和实现解决方案。这非常有助于实现和恢复解决方案。

1. 组件图
顾名思义，组件图指在解决方案中构建实际物理组件模型的方式。组件图可显示源代码组件、COM+组件及其他二进制和可执行组件。组件图还显示组件接口。

接口是组件间的通信方式。例如，小汽车的接口是仪表板和踏板。可通过“接口”与小汽车通信。Order组件可包含一个方法来取消订单，接口指定执行这个操作需要订单ID；换言之，要使Order对象删除订单，必须为要删除的订单传输订单ID。

组件图用来设计解决方案

2. 部署图
部署图显示解决方案的部署方式，由处理器、设备和连接器构成。“处理器”是可执行组件的硬件项。“设备”是不具备执行组件能力的硬件设备，如调制解调器和打印机。“连接器”是处理器和设备之间的关系。

部署图用来描述组件运行在哪些物理计算机上，以及解决方案如何与硬件交互。通过部署图，还可指定解决方案中各个节点类型的数目。

符号是一个显示物理部分的箱。

 

类之间的关系

UML把类之间的关系分为以下5种.

● 关联：类A与类B的实例之间存在特定的对应关系

● 依赖：类A访问类B提供的服务

● 聚集：类A为整体类，类B为局部类，类A的对象由类B的对象组合而成

● 泛化：类A继承类B

● 实现：类A实现了B接口

关联（Association）

关联指的是类之间的特定对应关系，在UML中用带实线的箭头表示。按照类之间的数量对比，关联

可以分为以下三种：

● 一对一关联

● 一对多关联

● 多对多关联

注意：关联还要以分为单向关联和双向关联

依赖（Dependency）

依赖指的是类之间的调用关系，在UML中用带虚线的箭头表示。如果类A访问类B的属性或者方法，

或者类A负责实例化类B，那么可以说类A依赖类B。和关联关系不同，无须在类A中定义类B类型的属性。

聚集（Aggregation）

聚集指的是整体与部分之间的关系，在UML中用带实线的菱形箭头表示。

聚集关系还可以分为两种类型：

● 被聚集的子系统允许被拆卸和替换，这是普通聚集关系。

● 被聚集的子系统不允许被拆卸和替换，这种聚集称为强聚集关系，或者组成关系。

注：强聚集（组成）可用带实线的实心菱形箭头表示。

泛化（Generalization）

泛化指的是类之间的继承关系，在UML中用带实线的三角形箭头表示。

实现（Realization）

实现指的是类与接口之间的关系，在UML中用带虚线的三角形箭头表示。

以下是GOF设计模式中的描述：

箭头和三角表示子类关系。

虚箭头线表示一个类实例化另一个类的对象，箭头指向被实例化的对象的类。

普通的箭头线表示相识（acquaintance也叫关联或者引用），意味着一个对象仅仅知道另一个对象。相识的对象可能请求彼此的操作，但他们不为对方负责，它只标示了对象间较松散的耦合关系。

尾部带有菱形的箭头线表示聚合（aggregation），意味着一个对象拥有另一个对象或者对另一个对象负责。一般我们称一个对象包含另一个对象，或者是另一个对象的一部分。聚合意味着聚合对象和其所有者具有相同的生命周期。
抽象类名以斜体表示，抽象操作也以斜体表示。图中可以包括实现操作的伪代码，代码将出现在带有褶角的框中，并用虚线将该褶角框与代码所实现的操作相连。

简单说明

Package
包。用来聚集和组织模型中的一个部分（Use Case，类，等等）。
Actor
参与者。它代表一个用户或者其他外部的激励器。
Use Case
用例。Use Case描述了系统某一部分的行为。一般地，Use Case记录对某个系统功能的需求，而这个功能由对动作或者事件的应答示范。
<> Relationship
包含关系。标注为<>关系的Use Case关系能够引入其他Use Case的功能。这是一种方便的分割Use Case、避免单个Use Case过于庞大的方法。
<> Relationship
扩充关系。标注为<>关系的Use Case关系能够在不重复现有Use Case的各种描述和需求的情况下，使现有Use Case的行为特殊化。
Dependency
依赖。正如其字面意义，它表示一个事物依赖另一个事物。这意味着一个事物了解另一个事物，并需要另外一个事物才能发挥功能。
Note
注解。在UML图中提供注解的目的是以简短的说明阐明图表的内容。
Component
构件。构件一般代表一个软件单元，它可能是一个DLL、一个执行文件，或者是一个数据库。
Node
节点。节点一般代表一台机器，这台机器具有运行一个或者多个系统构件的能力。
Class
类。UML中的类与面向对象编程中的类一样，即它定义并封装了一组行为和属性。类在运行时被实例化从而创建出对象。
Object
对象。对象是类的实例。例如，“MyClass myObj = new MyClass; ”创建了一个myObj对象。