UML

开始学习UML建模语言，从用例图入手。建模工具选择visio（博主学习的时候用的是StarUML)

一，用例图

 　　用例图描述的是参与者所理解的系统功能，主要元素是用例和参与者，是帮助开发团队以一种可视化的方式理解系统的功能需求。这时处于项目初始，分析用户需求的阶段，不用管怎么实现具体的功能，只要能向客户形象化的表述项目的功能就行。

用例图有四个部分：用例（Use Case), 参与者（Actor),系统边界，关系。

1.参与者

　　概念：参与者是与系统交互的人或物，不是系统的一部分。参与者是从现实事物中抽象出来的一种形式，却不一定确切地对应现实中的某个特定对象。首先当然包括我们的开发系统用户，除此之外，与我们开发的系统有关联的其他系统也算是参与者。

       表示方法：（1）在UML图中我们用一个小人表示。习惯用来表示人。

                         （2）  可以使用带有<<actor>>构造型的类符号表示。习惯用来表示事物  。   

2.用例

 　　   用例是参与者可以感受到的系统服务或功能单元。我理解的就是用户可以使用我们开发的项目去做的任何事情

任何用例都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要有与之关联的用例。在UML图中我们用椭圆表示：

3.系统边界

　　指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。

在UML图中我们用一个矩形表示。

 4.关系

　　用例图中的关系有4种：关联、泛化、包含、扩展。

　　关联：表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息。

       表示方法：带箭头的实线，指向接收方。

       泛化：用例的泛化指的是一个父用例可以被特化形成多个子用例，用我们熟悉的语言来说就是继承关系。 

       表示方法：用空心箭头实线，指向父用例。

       包含：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就是不完整的。包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中，将程序的某一段算法封装成一个子过程，然后在从主程序中调用这一子过程（这么说好像懂了点）

        表示方法：带箭头的虚线+《include》，指向被包含的用例。

       扩展：扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。

      表示方法：带小箭头的虚线+《extend》，指向基用例。

 

 

我画的用例图示例

二、类图

虚线箭头指向依赖；

实线箭头指向关联；

虚线三角指向接口；

实线三角指向父类；

空心菱形能分离而独立存在，是聚合；

实心菱形精密关联不可分，是组合；

上面是UML的语法。

在画类图的时候，理清类和类之间的关系是重点。类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。其中关联又分为一般关联关系和聚合关系(Aggregation)，合成关系(Composition)。下面我们结合实例理解这些关系。

1.基本概念

类图（Class Diagram）: 类图是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。

类图的3个基本组件：类名、属性、方法。 

泛化(generalization)：表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。

实现（Realization）:在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。

 

依赖(Dependency)：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。

关联(Association) : 对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向。

聚合(Aggregation) : 表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体。

组合(Composition) : 表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。

多重性(Multiplicity) : 通常在关联、聚合、组合中使用。就是代表有多少个关联对象存在。使用数字..星号（数字）表示。如下图，一个割接通知可以关联0个到N个故障单。

聚合和组合的区别

这两个比较难理解，重点说一下。聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。 

实例分析

联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。

大家可以参照着类图，好好理解。 

1． 通知分为一般通知、割接通知、重保通知。这个是继承关系。

2． NoticeService和实现类NoticeServiceImpl是实现关系。

3． NoticeServiceImpl通过save方法的参数引用Notice,是依赖关系。同时调用了BaseDao完成功能，也是依赖关系。

4． 割接通知和故障单之间通过中间类(通知电路)关联，是一般关联。

5． 重保通知和预案库间是聚合关系。因为预案库可以事先录入，和重保通知没有必然联系，可以独立存在。在系统中是手工从列表中选择。删除重保通知，不影响预案。

6． 割接通知和需求单之间是聚合关系。同理，需求单可以独立于割接通知存在。也就是说删除割接通知，不影响需求单。

7． 通知和回复是组合关系。因为回复不能独立于通知存在。也就是说删除通知，该条通知对应的回复也要级联删除。

经过以上的分析，相信大家对类的关系已经有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。

PS：还是那句话：以上类图用Enterprise Architect 7.5所画，在此推荐一下EA,非常不错。可以替代Visio和Rose了。Visio功能不够强大，Rose太重。唯有EA比较合适。 

三、活动图

活动图概述

•活动图和交互图是UML中对系统动态方面建模的两种主要形式

•交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流

•活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模

•UML 2.0而言，去除了“活动图是状态图的一种特例”这一规定

【用途】活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。

 

1、活动图的组成元素 Activity Diagram Element

1、活动状态图（Activity）——活动状态用于表达状态机中的非原子的运行

　　活动状态图特点如下：

　　(1)、活动状态可以分解成其他子活动或者动作状态。

　　(2)、活动状态的内部活动可以用另一个活动图来表示。

　　(3)、和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。

　　(4)、动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。

　　UML中活动状态和动作状态的图标相同，但是活动状态可以在图标中给出入口动作和出口动作等信息。

　　【图形】平滑的圆角矩形

                          

2、动作状态（Actions）—— 动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。

　　动作状态有如下特点：

　　(1)、动作状态是原子的，它是构造活动图的最小单位。

　　(2)、动作状态是不可中断的。

　　(3)、动作状态是瞬时的行为。

　　(4)、动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关。

　　(5)、动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。

　　(6)、在一张活动图中，动作状态允许多处出现。

　　【图形】平滑的圆角矩形

                           

3、动作状态约束（Action Constraints）——动作状态约束：用来约束动作状态。

　　【图形】如下图展示了动作状态的前置条件和后置条件

                     

4、动作流（Control Flow）——动作之间的转换称之为动作流活动图的转换

　　【图形】用带箭头的直线表示，箭头的方向指向转入的方向。

                    

5、开始节点（Initial Node）——活动开始节点
　　【图形】实心黑色圆点

                   

6、终止节点（Final Node）——分为活动终止节点（activity final nodes）和流程终止节点（flow final nodes）

　　(1)、活动终止节点表示整个活动的结束

　　【图形】圆圈+内部实心黑色圆点

                                

　　(2)、而流程终止节点表示是子流程的结束。

　　【图形】圆圈+内部十字叉

                               

7、对象（Objects）

　　【图形】矩形方框　　

　　　　　　　　　　　　　

8、数据存储对象（DataStore） ——使用关键字«datastore»

 　　【图形】矩形方框，内含关键字

                                

9、对象流（Object Flows）——对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。

　　用活动图描述某个对象时，可以把涉及到的对象放置在活动图中并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象流。

　　对象流中的对象有以下特点：

　　(1)、一个对象可以由多个动作操作。

　　(2)、一个动作输出的对象可以作为另一个动作输入的对象。

　　(3)、在活动图中，同一个对象可以多次出现，它的每一次出现表面该对象正处于对象生存期的不同时间点。

　　【图形】用带有箭头的虚线表示。如果箭头是从动作状态出发指向对象，则表示动作对对象施加了一定的影响。施加的影响包括创建、修改和撤销等。如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。

　　状态图中的对象用矩形表示，矩形内是该对象的名称，名称下的方括号表明对象此时的状态。

              

10、分支与合并（Decision and Merge Nodes）——选择分支
　　【图形】分支与合并用菱形表示，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。

                                         

11、分叉与汇合（Fork and Join Nodes）——分叉用于将动作流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。

　　对象在运行时可能会存在两个或多个并发运行的控制流，为了对并发的控制流建模，UML中引入了分叉与汇合的概念。

　　【图形】分为水平风向和垂直方向。

12、时间信号

　　                           

13、发送信号

                         

14、接收信号

                       

14、泳道（Partition）——泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。
在活动图中，泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中，每个活动只能明确地属于一个泳道。

泳道是用垂直实线绘出，垂直线分隔的区域就是泳道。在泳道的上方可以给出泳道的名字或对象的名字，该对象负责泳道内的全部活动。泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。

               

2.活动图案例分析

例1.购物用例图

1、  泳道分为：会员泳道和系统泳道。会员选择商品并加入购物车，系统完成订单生成及其支付完毕。

2、  开始节点：会员添加商品到购物车，点击【订单确认】，开始交于系统处理订单流程

3、  结束节点：商品发送完毕和付款成功，订单处理流程结束

4、  活动状态：产生订单、Check Credit Cart核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart付款

5、  分叉与汇合：【产生订单】份叉为检查库存量和会员支付金额是否足够，如果不足，取消订单，如过库存量和支付金额足够，发送商品和付款，最后汇合为订单完成。

 

例2. 带有发送信号与接收信号的活动图

 

例3.带对象流的活动图

 

 

例4.辅助活动图

四、对象图与类图

类图的概念

1、概述

类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。类图是定义其他图的基础，在类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。

类图包括7个元素：类（Class）、接口（Interface）、协作（collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）以及实现关系（Realization）。

2、类

类定义了一组有着状态和行为的对象。其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用有身份的对象之间的关系表示。行为由操作来描述，方法是操作的实现。对象的生命期则由附加给类的状态机来描述。

1、 名称：类的名称是每个类中所必有的构成元素。

2、 属性（Attribute）

（1） 可见性：类中属性的可见性主要包括公有（public）、私有（Private）和受保护（Protected）。在UML中，公有类型的用“+”表达，私有类型用“-”表达，而受保护类型则用“#”表达。UML的类中不存在默认的可见性，如果没有显示任何一种符号，就表示没有定义该属性的可见性。

（2） 属性名：按照UML的约定，单字属性名小写。如果属性名包含多个单词，这些单词要合并，且除了第一个单词外其余单词的首字母要大写。

（3） 属性字符串。属性字符串用来指定关于属性的其他信息，例如某个属性应该是永久的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。

（4） 类属性。属性也可以作为一个类属属性来定义，这就意味着此属性被该类的所有对象共享。在类图中，类属性带有一条下划线。

3、 操作。类的操作是对类的对象所能做的事务的抽象，相当于一个服务的实现。

4、 职责：在操作部分下面的区域，可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本，写一个短语，一个句子等。在UML中，把职责列在类图底部的分隔栏中。

5、 约束。说明类的职责是消除二义性的一种非形式化的方法，形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个花括号括起来的自由文本。

3、接口

接口包含操作但不包含属性，且它没有对外界可见的关联。

4、类之间的关系

类之间的关系最常见的有四种：依赖关系、泛化关系、管理关系、实现关系。

1、 依赖关系（Dependency）

依赖表示两个或多个模型元素之间语义上的关系。它表示了这样一种情形，对于一个元素（提供者）的某些改变可能会影响或提供消息给其他元素（客户），即客户以某种形式依赖于其他类元。根据这个定义，关联、实现和泛化都是依赖关系，但是它们有更特别的语义。在UML中，依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类。

UML定义了4种基本依赖类型，分别是使用（Usage）依赖、抽象（Abstraction）依赖、授权（Permission）依赖和绑定（Binding）依赖。

（1）、使用依赖。使用依赖都是非常直接的，通常表示客户使用提供者提供的服务以实现它的行为。以下列出了5种使用依赖关系.

（2）、抽象依赖。抽象依赖用来表示客户与提供者之间的关系，依赖于在不同抽象层次上的事物。

（3）、授权依赖。授权依赖表示一个事物访问另一个事物的能力。提供者通过规定客户的权限，可以控制和限制对其内容访问的方法。

（4）、绑定依赖。绑定依赖是较高级的依赖类型，用于绑定模板以创建新的模型元素。

2、泛化关系（Generalization）

泛化关系是一种存在于一般元素和特殊元素之间的分类关系，它只使用在类型上，而不是实例上。在类中，一般元素被称为超类或父类，而特殊元素被称为子类。在UML中，泛化关系用一条从子类指向父类的空心三角箭头表示

3、关联关系（Association）

关联关系是一种结构关系，它指明一个事物的对象与另一个事物的对象之间的联系。也就是说，关联描述了系统中对象或实例之间的离散连接。在UML中，关联关系用一条连接两个类的实线表示

关联关系有6种对应的修饰，它们分别是：名称、角色、多重性、聚合、组合和导航性。

（1）、名称（Name）。名称用来描述关联的性质，通常使用一个动词或动词短语来命名关联。名称以前缀或后缀一个指引阅读的方向指示符以消除名称含义上可能存在的歧义，方向指示符用一个实心的三角形箭头表示。

（2）、角色（Role）。角色是关联关系中一个类对另一个类所表现出来的职责。角色名称是名词或名词短语，以解释对象是如何参与关联的。

（3）、多重性（Multiplicity）。约束是UML三大扩展机制之一，多重性是其中使用最广泛的一种约束。关联的多重性是指有多少对象可以参与该关联，多重性可以用来表达一个取值范围、特定值、无限定的范围或一组离散值。

（4）、聚合（Aggregation）。聚合关系表示整体和部分关系的关联。聚合关系描述了“has a”的关系。在UML中聚合关系用带空心的实线来表示，其中头部指向整体。

（5）、组合关系(Composition)。组合关系是聚合关系中的一种特殊情况，是更强形式的聚合，又被称为强聚合。在组合中，成员对象的生命周期取决于聚合的生命周期，聚合不仅控制着成员对象的行为，而且控制着成员对象的创建和析构。在UML中，组合关系用带实心菱头的实线来表示，其中头部指向整体。

（6）、导航性(Nevigation)。导航性描述的是一个对象通过链（关联的实例）进行导航访问另一个对象，即对一个关联端点设置导航属性意味着本端的对象可以被另一端的对象访问。可以在关联关系上加箭头表示导航方向。只在一个方向上可以导航的关联称为单向关联(Unidirection Association),用一条带箭头的实线来表示。在两个方向上都可以导航的关联称为双向关联(Bidirection Association),用一条没有箭头的实线来表示。另外使用导航性可以降低类之间的耦合度，在也是好的面向对象分析与设计的目标之一。

4、实现关系（Realization）

实现是规格说明和其实现之间的关系，它将一种模型元素与另一种模型元素连接起来，比如类和接口。

泛化和实现关系都可以将一般描述与具体描述联系起来。泛化将同一语义层上的元素连接起来，并且通常在同一模型内。实现关系则将不同语义层内的元素连接起来，通常建立在不同的模型内。

实现关系通常在两种情况下被使用：在接口与实现该接口的类之间；在用例以及实现该用例的协作之间。

在UML中，实现关系的符号与泛化关系的符号类似，用一条带指向接口的空心三角箭头的虚线表示。下图所示的是实现关系的一个示例，描述的是Keyboard保证自己的部分行为可以实现Typewriter的行为

实现关系还有一种省略的表示方法，即接口表示为一个小圆圈，并和实现接口的类用一条线段连接，如图

类图建模技术

一、对简单协作建模

类不是单独存在的，而是要与其他类协同工作。协作是动态交互在静态视图上的映射，协作的静态结构通过类图来描述。

对协作建模要遵循如下策略

1、识别要建模的机制。一个机制描述了正在建模的部分系统的一些功能和行为，这些功能和行为是由类、接口和一些其他元素的相互作用产生的。

2、对每种机制，识别参与协作的类、接口和其他协作，并识别这些事物之间的关系。

3、用协作的脚本检测事物，通过这种方法可以发现模型中被遗漏的部分和有明显语义错误的部分。

4、把元素和它们的内容聚合在一起。对于类，首先平衡好职责，随着时间的推移，将它们转换成具有的属性和操作。

二、对逻辑数据库模式建模

通用的逻辑数据库建模工具是“实体-关系（E-R）”图，传统的E-R图只针对数据，而UML的类图还允许对行为建模。在物理数据库中，类图一般要把逻辑操作转化成触发器或存储过程。

对模式建模要遵循如下策略：

1、在模型中识别的类，其状态必须超过其应用系统的生命周期。

2、创建包含这些类的类图，并把它们标记为永久（persistent）。对于特定的数据库细节，可以定义自己的标记值集合。

3、展开这些类的结构性细节，即详细描述属性的细节，并注重于关联和构造类的基数。

4、观察系统中的公共模式（如循环关联、一对一关联和n元关联），它们常常造成物理数据库设计的复杂化。

5、考虑这些类的行为，扩展对数据库存储和数据完整性来说重要的操作。一般情况下，与对象集的操作相关的业务规则应该被封装在永久类的上一层。

三、正向工程和逆向工程

1、正向工程（Forward Engineering）

正向工程是通过实现语言的映射把模型转换为代码的过程。由于UML中描述的模型在语义上比当前的任何面向对象语言要丰富，所以正向工程会导致一定信息的损失，这也是需要模型的原因。

对类图进行正向工程，要遵循如下的策略

(1)、识别映射到所选择的实现语言的规则

(2)、根据所选择的语言的语义，可能会限定一些对UML特性的使用

(3)、用标记值详细描述目标语言，若需要精确的控制，该操作可以在单个类的层次上进行，也可以在较高的层次(如协作或包)上进行

(4)、使用工具对模型进行正向工程

2、逆向工程（Reverse Engineering）

逆向工程是通过从特定实现语言的映射，把代码转换为模型的过程。逆向工程会导致大量的冗余信息同时逆向工程又是不完整的。

对类图进行逆向工程，要遵循如下的策略

(1)、识别从实现语言或所选的语言进行映射的规则

(2)、使用工具，指向要进行逆向工程的代码，用工具生成新的模型或修改以前进行正向工程时已有的模型。

(3)、使用工具，通过查询模型创建类图。

对象图

一、概述

对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。

在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类，连线表示对象之间的关系：

二、类图和对象图的区别

类图	对象图
类具有3个分栏：名称、属性和操作	对象只有两个分栏：名称和属性
在类的名称分栏中只有类名	对象的名称形式为“对象名：类名”，匿名对象的名称形式为“：类名”
类的属性分栏定义了所有属性的特征	对象则只定义了属性的当前值，以便用于测试用例或例子中
类中列出了操作	对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的
类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义。类代表的是对对象的分类所以必须说明可以参与关联的对象的数目	对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性。

对象图建模技术

一、对对象结构建模

对系统的设计视图建模时，可以使用一组类图完整地描述抽象的语义以及它们之间的关系。但是使用对象图不能完整地描述系统的对象结构。对于一个个体类，可能存在多个实例，对于相互之间存在关系的一组类，对象间可有的配置可能是相当多的。所以，在使用对象图时，只能在一定意义上显示感兴趣的具体或原型对象集。这就是对对象结构建模，即一个对象图显示了某一时刻相互联系的一组对象。

对对象结构建模，要遵循以下策略：

(1)、识别将要使用的建模机制。该机制描述了一些正在建模的部分系统的功能和行为，它们由类、接口和其他元素的交互而产生。

(2)、对于各种机制，识别参与协作的类、接口和其他元素，同时也要识别这些事物之间的关系。

(3)、考虑贯穿这个机制的脚本。冻结某一时刻的脚本，并且汇报每个参与这个机制的对象。

(4)、按照需要显示出每个对象的状态和属性值，以便理解脚本。

(5)、显示出对象之间的链，以描述对象之间关联的实例。

二、正向工程和逆向工程

1、正向工程

对对象图工程进行正向工程在理论上是可行的，但是在实际上却是受限制的。

2、逆向工程

对对象图进行逆向工程是非常困难的。当对系统进行调试时，总要依靠开发人员或工具来进行。

五、顺序图与通信图

六、包图

七、部署图

八、构件图