UML 建模

UML是Unified Modeling Language（统一建模语言）的简称。UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。制品{Artifact}是指软件开发过程中产生的各种各样的产物，如模型、源代码、测试用例等。

  UML建模可以达到以下目的：

  使用模型可以更好地理解问题

 使用模型可以加强人员之间的沟通

 使用模型可以更早地发现错误或疏漏的地方

 使用模型可以获得设计结果

 模型为最后的代码提供依据

二、UML的历史

1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。

2003年，UML已经获得了业界的认同。在所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 1.4的快速入门文章。当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。

三、UML的特点

 UML的主要特点包括：

 统一的标准

 面向对象。UML是支持面向对象软件开发的建模语言。

 可视化、表现能力强

 于过程，UML不依赖于特定的软件开发过程。

 概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。

四、UML中的视图

UML中的视图包括用例视图（Use Case View）、逻辑视图（Logical View）、实现视图（Implementation View）、进程视图（Process View）、部署视图（Deployment View）等，这5个视图被称作”4+1”视图.如下图所示：

逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。

开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。

处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。

物理视图。物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。 

五、UML建模工具

市面上UML建模工具很多，比较流行的有Rational Rose ，Microsoft Visio、Enterprise Architect 、Visual UML等。《UML建模-面向对象设计》系列文章使用的UML建模工具是Enterprise Architect 7.0，此工具还是比较好用的。 

六、UML的应用领域

UML具有很广泛的应用领域，其中最常用的是为软件系统建模，主要领域有：企业信息系统、银行金融系统、电信、交通、国防、航空、零售领域、科学计算、分布式的基于Web的服务。UML还可以用来描述其他非软件系统，比如一个机构的组成和机构的工作流程等等。 

七、UML的构成

《UML建模-面向对象设计》系列文章描述了常见的一些UML图，主要包括了用例图（Use Case Diagram）、类图（Class Diagram）、活动图（Activity Diagram）、时序图（Sequence Diagram）、状态图（Statechart Machine Diagram）、部署图(Deployment Diagram)、业务处理模型(Business Process Model)、数据建模(Data Modeling Diagram)等等。

1如何书写Use Case

什么是Use Case

用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据，以及根据UC复杂度和开发周期来衡量开发人员的工作效率。因此UC的书写规范及其重要，就工作用的一些经验，比如书写格式、书写内容及其注意事项与大家分享。

大纲图：

一、前期准备

   对用户的问题要有非常深刻完善的理解

   确保能够解决用户的所有问题

   把用户的需求真正地反应到商业模型

   对以后的设计和开发过程提供说明和框架

   根据需求生成ＵＩ界面

二、Use Case内容

首先有用例名称：一般是模块名称或者模块中功能点的名称。

其次文档变更记录（Revision History），具体内容如下：

1、基本描述（Brief Description）

描述用例在系统中的作用。比如此用例的使用者是谁、使用者所要做的操作。

2、前置条件（Precodition）

描述该用例执行前所要满足的条件。比如用例B执行前，必须先执行A，则用例的前置条件是执行A。

3、事后保证（PostCodition）

此用例执行完毕后的条件

4、主要流程（Basic Flows）

用户操作该用例的基本流程，是后期时序图的主要参考

5、选择性流程（Alternative Flows）

在操作主要流程过程中，出现的一些分支流程，是后期时序图的主要参考

6、特别需求（Special Requirement）

对一些细微功能点进行描述，比如用户身份验证规则、订单号码产生规则、是否需要SSL加密等等

7、使用界面（User Interface）

美工根据需求制作的UI，及其对UI中栏位进行的说明。

8、附加资讯（Addition Information）

一些商务逻辑的描述，可以把系统逻辑试图（Logic View）放到这里

三、总结

在阅读UC的过程中主要遇到以下问题“基本流程和选择性流程描述的不够清楚或者不够详细”的问题，主要是因为系统分析人员对需求理解的不够透彻，分析的不够彻底。

2、设计阶段如何画用例视图（Use-Case View） 

一、概述

用例试图描概括了用例中角色和系统之间的关系，描述了系统功能需求，角色和系统的交互以及系统的反应。

    会员具有浏览商品类别、根据关键字产讯商品和选择商品加入购物车的功能。

二、术语解释

1、Extends 用例扩展关系

扩展关系一般用来描述一个元素延伸为另外一种行为。Use Case中的扩展表示一个UC有可能扩展到另外一个UC的功能。Use Case中的扩展通常暗示一个选择性流程。

2、Include 用例包含关系

包行关系表示源元素包行目标元素的行为，UC中的包含关系就是一个UC中包行另外一个ＵＣ的行为功能。用包行关系可以防止在多个ＵＣ中同时定义共同的功能模块，有些像委托delegation

3、角色（Actor）

系统中的用户根据系统分为多个角色，每个角色都会与系统有交互。一个用户可以具有一个或者多个角色。

系统中用到的角色如果细分，可以分为主要角色和辅助角色

比如：在电子商务网站中主要角色有供应商、前台会员、系统管理员等等；辅助角色有Email Sender、物流系统、金流系统等等。

三、如何画Use Case 用例视图

 Note: 设计工具是EA（Enterprise Architect 7.0）

 假设目前的功能需求是： 

A、供应商需要填写Form表单提报商品

B、供应商通过导入CSV文档提报商品

C、商品开发人员需要对供应商提报的是商品进行审核

1、新建工程

   【File】->【New Project】->填写工程名称：Example.eap

2、新建Use Case View 用例视图

   右击上面新建的Project->选择【New View】->弹出对话框，选择【Use Cse】如下图

单击【OK】，在Model工程下，这样就新建了一个Package。

右击Package【商品提报上架】->选择【Add】->选择【Add Diagram】，如下图所示

弹出如下对话框：选择【UML Behavioral】->Use Case,单击【OK】

这样，一个空的Use Case新建完成。接下来我们需要向空的Use Case添加内容。

3、根据业务需求画Use Case视图

Note：从左侧的ToolBox工具栏中 选择一些Use Case的元素，直接拖曳左边的Element，到右边的工作区，就可以把Element放到咱们的Use Case试图中。

A、拖曳两个Actor 元素到工作区，分别命名为“供应商”“商品开发人员”

B、拖曳三个Use Case元素到工作区，分别命名为“商品提报”“CSV档导入商品” “商品审核”

如下图所示：

C、通过关联关系 链接角色与系统功能，如下图：

至此，商品提报场景的Use Case图已经画完。一个Use Case视图会对应一个或者多个Use Case用例。

关于什么是Use Case 请参照《需求阶段如何书写Use Case》

四、Use Case 在实际项目中的组织结构

这是一个使用UC描述的系统需求功能目录图，每一个UC描述了Actor使用使系统时，与系统的交互行为。

五、总结

用例试图描概括了用例中角色和系统之间的关系，描述了系统功能需求，角色和系统的交互以及系统的反应。是客户和开发人员全貌理解项目需求功能比较好的一个方式，也是后续功能迭代的依据和方向。

3、类与类之间的关系图(Class Diagram,UML图) 

一、简介

类是对象的集合，展示了对象的结构以及与系统的交互行为。类主要有属性（Attribute）和方法（Method）构成,属性代表对象的状态，如果属性被保存到数据库，此称之为“持久化”；方法代表对象的操作行为，类具有继承关系，可以继承于父类，也可以与其他的Class进行交互。

       类图展示了系统的逻辑结构，类和接口的关系。

二、类的构成

类主要有属性和方法构成。比如商品属性有：名称、价格、高度、宽度等；商品的方法有：计算税率，获得商品的评价等等。如下图

三、类之间的关系（Relationship）

关联(Association)

两个相对的对象，当一个对象的实例与另外一个对象的特定实例存在固定关系时，这两个对象之间就存在关联关系。

1、单向关联

A1->A2: 表示A1认识A2，A1知道A2的存在，A1可以调用A2中的方法和属性

场景：订单和商品，订单中包括商品，但是商品并不了解订单的存在。

类与类之间的单向关联图:

C#代码:

Public class Order

{

       Public List order;

Public void AddOrder(Product product )

       {

              order.Add(product);

}             

}

Public Class Product

{

}

代码表现为：Order(A1)中有Product(A2)的变量或者引用

2、双向关联

B1-B2: 表示B1认识B2，B1知道B2的存在，B1可以调用B2中的方法和属性；同样B2也知道B1的存在，B2也可以调用B1的方法和属性。

场景：订单和客户，订单属于客户，客户拥有一些特定的订单

类与类之间的双向关联图

C#代码

Public class User

{

       Public List GetOrder()

       {

}      return new List();

}

Public Class Order

{

       Public User GetUserByOrderID(string OrderId )

       {

              Return new User();

}

}

3、自身关联

同一个类对象之间的关联

类与类之间自身关联图

4、关联(N-ary Association)

多个对象之间存在关联

场景：公司雇用员工，同时公司需要支付工资给员工

类与类之间的关联图：

5、泛化(Generalization)

类与类的继承关系，类与接口的实现关系。

场景：父与子、动物与人、植物与树、系统使用者与B2C会员和B2E会员的关系

类与类之间的泛化图：

系统的使用者包括：B2C会员、B2B会员和B2E会员。

接口的实现，动物都有吃的行为，而人是动物的一个具体实例,实现具体Eat的动作 

6、依赖(Dependency)

类A要完成某个功能必须引用类B，则A与B存在依赖关系，依赖关系是弱的关联关系。C#不建议双相依赖，也就是相互引用

场景：本来人与电脑没有关系的，但由于偶然的机会，人需要用电脑写程序，这时候人就依赖于电脑。

类与类的依赖关系图

在程序中一般为 using 引用。

7、聚合(Aggregation)

当对象A被加入到对象B中，成为对象B的组成部分时，对象B和对象A之间为聚合关系。聚合是关联关系的一种，是较强的关联关系，强调的是整体与部分之间的关系。

场景：商品和他的规格、样式就是聚合关系。

类与类的聚合关系图

8、组合（Composite）

       对象A包含对象B，对象B离开对象A没有实际意义。是一种更强的关联关系。人包含手，手离开人的躯体就失去了它应有的作用。

场景： Window窗体由滑动条slider、头部Header 和工作区Panel组合而成。

类与类的组合关系图

四、总结

　　 本文针对类之间常用的关系进行了简单的描述，主要有：关联关系、泛化、依赖、聚合和组合。

4、UML建模之活动图介绍（Activity Diagram） 

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

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

1、活动状态图（Activity）

活动状态用于表达状态机中的非原子的运行，其特点如下：

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

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

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

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

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

2、动作状态（Actions）

动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。动作状态有如下特点：

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

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

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

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

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

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

UML中的动作状态图用平滑的圆角矩形表示，如下：

3、动作状态约束（Action Constraints）

动作状态约束：用来约束动作状态。如下图展示了动作状态的前置条件和后置条件

4、动作流（Control Flow）

动作之间的转换称之为动作流，活动图的转换用带箭头的直线表示，箭头的方向指向转入的方向。

5、开始节点（Initial Node）

开始节点：表示成实心黑色圆点

6、终止节点（Final Node）

分为活动终止节点（activity final nodes）和流程终止节点（flow final nodes）。

活动终止节点表示整个活动的结束

而流程终止节点表示是子流程的结束。

7、对象（Objects）

8、数据存储对象（DataStore）

使用关键字«datastore»

9、对象流（Object Flows）

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

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

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

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

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

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

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

10、分支与合并（Decision and Merge Nodes）

分支与合并用菱形表示

11、分叉与汇合（Fork and Join Nodes）

分为水平风向和垂直方向。

对象在运行时可能会存在两个或多个并发运行的控制流，为了对并发的控制流建模，UML中引入了分叉与汇合的概念。分叉用于将动作流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。

12、异常处理（Exception Handler）

当受保护的活动发生异常时，触发异常处理节点。

13、活动中断区域（Interruptible Activity Region）

活动中断区域围绕一些可被中断的动作状态图。比如下图，正常情况下【Process Order】顺序流转到【Close Order】，订单处理流程完毕；但在【Process Order】过称中，会发送【Cancel Order】请求，这时会流转到【Cancel Order】，从而订单处理流程结束

14、泳道（Partition）

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

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

二、活动图案例分析 

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

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

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

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

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

三、总结

活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。活动图能够表示并发活动的情形，活动图是面向对象的。

5、UML建模之状态图（Statechart Diagram） 

一、状态图简介（Brief introduction）

状态图（Statechart Diagram）主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机（State Machine Diagram），重点在与描述状态图的控制流。

如下图例子，状态机描述了门对象的生存期间的状态序列，引起转移的事件，以及因状态转移而伴随的动作（Action）.

状态有Opened、Closed、Locked。

事件有 Open、Close、Lock和Unlock。

注意：

1、             并不是所有的事件都会引起状态的转移，比如当门是处于【Opened】状态，不能进行【Lock】事件。

2、             转移（Transition）有警备条件（guard condition），比如只有doorWay->isEmpty 条件满足时，才会响应事件。

二、状态图元素（State Diagram Elements）

1、状态（States）

    指在对象的生命周期中的某个条件或者状况，在此期间对象将满足某些条件、执行某些活动活活等待某些事件。所有对象都有状态，状态是对象执行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。

状态用圆角矩形表示 

初态和终态（Initial and Final States）

初态用实心圆点表示，终态用圆形内嵌圆点表示。

2、转移（Transitions）

    转移（Transitions）是两个状态之间的一种关系，表示对象将在源状态（Source State）中执行一定的动作，并在某个特定事件发生而且某个特定的警界条件满足时进入目标状态（Target State）

    事件标记（Trigger）：是转移的诱因，可以是一个信号，事件、条件变化（a change in some condition）和时间表达式。

    警界条件（Guard Condition）：当警界条件满足时，事件才会引发转移（Transition）。

    结果（Effect）：对象状态转移后的结果。

3、动作（State Actions）

动作（Actions）是一个可执行的原子操作,也就是说动作是不可中断的，其执行时间是可忽略不计的。

在上例中，对象状态转移后的结果显示在转移线上，如果目标状态有许多转移，而且每个转移有相同的结果，这时把转移后的结果（Effect）展示在目标状态中（Target State）更好一些，可以定义进入动作（Entry Action ）和退出动作（Exit Action），如下图

4、自身转移（Self-Transitions）

    状态可以有返回自身状态的转移，称之为自身转移（Self-Transitions） 

2S后，Poll input事件执行，转移到自己状态【Waiting】

5、组合状态（Compound States）

    嵌套在另外一个状态中的状态称之为子状态（sub-state）,一个含有子状态的状态被称作组合状态（Compound States）. 如下图，【Check PIN】是组合状态，【Enter PIN】是子状态。

也可用以下方式进行描述

如上图，状态机【Check PIN】的细节被分割到另外一个图中了。

6、进入节点（Entry Point）

    如下图所示，由于一些原因并不会执行初始化（initialization），而是直接通过一个节点进入状态【Ready】，则此节点称之为进入节点（Entry Point）

7、退出节点（Exit Point）

8、历史状态（History States）

    历史状态是一个伪状态（Pseudostate）,其目的是记住从组合状态中退出时所处的子状态，当再次进入组合状态，可直接进入这个子状态，而不是再次从组合状态的初态开始。

在上图的状态图中，正常的状态顺序是:【Washing】- >【Rinsing】->【Spinning】。

如果是从状态【Rinsing】突然停电（Power Cut）退出，,洗衣机停止工作进入状态【Power Off】，当电力恢复时直接进入状态【Running】。

9、并发区域（Concurrent Regions）

    状态图可以分为区域，而区域又包括退出或者当前执行的子状态。说明组合状态在某一时刻可以同时达到多个子状态。如下图刹车系统，同时进入前刹车【Applying Front Brakes】状态和后刹车【Applying Rear Brakes】状态。

三、状态图案例分析（State Diagram Example Analysis）

按照blink518的建议（“出货中”是属于条件分支应该使用Decision），改成如下图也是很好的做法：

订单成立状态主要有：

订单成立

订单取消（Guard:会员订单-缴款期限已过期）

备货中（Guard:已付款、订单成立、库存量足够）

出货中（Effect:扣除商品可接单量及移除购物车中的购买资料）

出货确认（Guard:实际配达日及代码、号码均不为空值）

出货完毕（Guard:实际配达日不为空）

出货失败

订单成立（Guard:出货完毕，已付款、鉴赏期结束日期 小于等于 [系统日期]）

分析：

1、购物车生成订单进入状态【订单成立】

2、系统检测订单已经付款并且库存量足够，则进入状态【备货中】

3、物流发货，进入状态【发货中】，状态转移为【发货中】后，需要做的操作有“扣除商品可接单量及移除购物车中的购买资料”

4、发货完毕后，状态分为【出货确认】和状态【出货失败】，如果状态是【出货失败】，则【结束】，如果状态为【出货确认】，则进入下一步。

5、配货人员填写实际配达日期，进入状态【出货完毕】。

6、如果”已付款、鉴赏期结束日期 小于等于 [系统日期]”,则【订单成立】。

四、总结（Summary） 

    状态图重点在于描述对象的状态及其状态之间的转移，状态图的基本元素主要有：状态、转移、动作、自身转移、组合状态、进入节点、退出节点、历史状态、并发区域等，状态中的事件分为调用事件（Call）、变化事件（Change）、时间事件（Time）和信号事件(Singal)。最后以实例对状态对进行了分析。

6、UML建模之时序图（Sequence Diagram） 

一、时序图简介（Brief introduction）

    时序图（Sequence Diagram）是显示对象之间交互的图，这些对象是按时间顺序排列的。顺序图中显示的是参与交互的对象及其对象之间消息交互的顺序。时序图中包括的建模元素主要有：对象（Actor）、生命线（Lifeline）、控制焦点（Focus of control）、消息（Message）等等。

二、时序图元素（Sequence Diagram Elements）

  角色（Actor）

   系统角色，可以是人、及其甚至其他的系统或者子系统。

  对象（Object）

  对象包括三种命名方式：

  第一种方式包括对象名和类名；

  第二中方式只显示类名不显示对象名，即表示他是一个匿名对象；

  第三种方式只显示对象名不显示类明。

  生命线（Lifeline）

  生命线在顺序图中表示为从对象图标向下延伸的一条虚线，表示对象存在的时间，如下图

  控制焦点（Focus of Control）

  控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将执行相应的操作。用小矩形表示，如下图。

  消息（Message）

  消息一般分为同步消息（Synchronous Message），异步消息（Asynchronous Message）和返回消息（Return Message）.如下图所示：

  同步消息=调用消息（Synchronous Message）

  消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。

  异步消息（Asynchronous Message）

  消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。

  返回消息（Return Message）

  返回消息表示从过程调用返回

  自关联消息（Self-Message）

  表示方法的自身调用以及一个对象内的一个方法调用另外一个方法。

  Combined Fragments

∙Alternative fragment（denoted “alt”） 与 if…then…else对应

∙Option fragment (denoted “opt”) 与 Switch对应

∙Parallel fragment (denoted “par”) 表示同时发生

∙Loop fragment(denoted “loop”) 与 for 或者 Foreach对应

三、时序图实例分析（Sequece Diagram Example Analysis）

  时序图场景

完成课程创建功能，主要流程有：

1、请求添加课程页面，填写课程表单，点击【create】按钮

2、添加课程信息到数据库

3、向课程对象追加主题信息

4、为课程指派教师

5、完成课程创建功能

时序图实例

时序图实例分析

1、序号1.0-1.3  完成页面的初始化

2、序号1.4-1.5  课程管理员填充课程表单

3、序号1.6-1.7  课程管理员点击【Create】按钮，并响应点击事件

4、序号1.8     Service层创建课程

5、序号1.9-1.10 添加课程到数据库，并返回课程编号CourseId

6、序号1.11-1.12 添加课程主题到数据库，并返回主题编号topicId

7、序号1.13        给课程指派教师

8、序号1.14        向界面抛创建课程成功与否的消息

四、总结（Summary）

    时序图（Sequence Diagram）是显示对象之间交互的图，这些对象是按时间顺序排列的。顺序图中显示的是参与交互的对象及其对象之间消息交互的顺序。时序图中包括的建模元素主要有：对象（Actor）、生命线（Lifeline）、控制焦点（Focus of control）、消息（Message）等等。最后，以课程创建功能演示一时序图实例。

7、UML建模之业务处理模型（Business Process Model,BPM） 

一、业务处理模型简介（Brief introduction）

二、业务处理模型元素（Elements）

1、目标（Goal）

2、消息（Information）

3、资源（Resource）

4、输出（outputs）

三、业务处理模型案例分析（Business Process Model Example Analysis）

    四、总结（Summary）

一、业务处理模型简介（Brief introduction）

业务处理模型是一组活动的集合，描述了活动从开始到结束在时间或者空间上的顺序，以及输入和输出。业务处理模型最终输出要能够满足业务需要。

业务处理模型一般包括：

1、目标（Goal）

2、特定的输入（specific inputs）

3、特定的输出（Specific outputs）

4、有一定顺序的活动（Activities in some order）

5、消息（Information）

6、资源（Resource）

二、业务处理模型元素（Elements）

1、目标（Goal）

每一个业务处理流程都有一些将要达到的目标，这些目标需要能够满足业务需求。

2、消息（Information）

使用消息完成活动（Activities）。在业务处理过程中，消息并不没有消耗，只是作为转化流程的一部分。消息可以来自于外部资源、客户、内部组织单元甚至是其他处理流程。比如订单模版，之前用来提供某一种样式的订单，现在作为活动的一部分并没有被消耗和用尽。

3、资源（Resource）

资源是一种输入，与消息（Information）不同的是，资源是被消耗和可以被用尽的。

4、输出（outputs）

每个业务流程都会产生一些满足业务需要的输出。输出可以是物理对象（例如报表和），也可以是整个业务流程的结束（例如完成订单）。

三、业务处理模型案例分析（Business Process Model Example Analysis）

事件（Event）有客户要生成的订单Cutomer Order

输入（inputs）有客户数据库Customer Database 和库存（Inventory）

业务处理（Process）是Order handling Process

输出（outputs）是生成的订单Completed Customer Order

四、总结（Summary）

业务处理模型是一组活动的集合，描述了活动从开始到结束在时间或者空间上的顺序，以及输入和输出。业务处理模型最终输出要能够满足业务需要。包括输入、输出、资源、消息和目标等元素。最后以实例进一步说明了业务逻辑模型。

8、UML建模之数据建模（Data Model Diagram） 

一、数据建模简介

数据建模不仅可以对象的属性建模（比如E-R图），也可以对数据的行为建模（比如触发器Trigger、存储过程Stored Procedure）.在进行数据库设计时，设计到如下几个概念：

模式 Schema、主键 Primary、外键 Foreign key、关系 Relationship、约束 constraint、索引 Index、触发器 Trigger、存储过程 Stored Procedure、视图 View。

二、数据建模元素

1、表（Table）

表是关系数据库最基本的模型结构。如下图

表的主键：InventoryID

表的外键：WarehouseId，关联到表Warehouse的主键

可以设置Table的数据库类型，如下图

也可以设置表空间，如下图

2、表索引（Table Index）

指按表文件中某个关键字段或表达式建立记录的逻辑顺序。它是由一系列记录号组成的一个列表，提供对数据的快速访问。索引不改变表中记录的物理顺序

3、表触发器（Table Trigger）

当对某一表进行诸如UPDATE、 INSERT、 DELETE 这些操作时，SQL Server 就会自动执行触发器所定义的SQL 语句，从而确保对数据的处理必须符合由这些SQL 语句所定义的规则。 

    触发器的主要作用就是其能够实现由主键和外键所不能保证的复杂的参照完整性和数据的一致性

4、表约束（Table Constraint） 

通过对列的约束，保证数据的有效性。

5、视图（View）

视图是从一个或多个表或视图中导出的表，其结构和数据是建立在对表的查询基础上的。如下图：

6、存储过程（Stored Procedure）

将常用的或很复杂的工作，预先用SQL语句写好并用一个指定的名称存储起来, 那么以后要叫数据库提供与已定义好的存储过程的功能相同的服务时,只需调用execute,即可自动完成命令。 

三、数据建模实例

1、表有仓库Warehouse、库存Inventory以及书Book

2、主键分别为WarehouseID，InventoryID,ISBN

3、外键，表Iinventory的外键是WarehouseID，同时也是Warehouse的主键

   表Book的外键是InventoryID，同时也是Inventory的主键

4、关系，表Warehouse与表Inventory是一对多的关系

   Inventory与表Book是一对多的关系。

四、总结

本文主要介绍了数据库建模所涉及建模元素，主要包括模式 Schema、主键 Primary、外键 Foreign key、关系 Relationship、约束 constraint、索引 Index、触发器 Trigger、存储过程 Stored Procedure、视图 View等等，并配以实例加以说明。

本篇文章比较简单，也是《UML建模-面向对象技术》系列文章的最后一篇建模文章。对此系列文章，后期抽个时间再写个总结，使的UML建模系列文章知识性更连贯，内容更加清晰。

八、总结

至此，《UML建模-面向对象设计》系列文章已经写完，UML建模也就告一段落，在整理这些文中的过程中，参考了许多国内外有价值的文章，在此对这些文章的作者表示感谢。在写这些文章的过程中也得到园子里朋友的鼓励和支持，是你们的支持和鼓励使的我写文章更加有士气和信心，在此表示感谢。希望《UML建模-面向对象设计》系列文章对园子里的朋友有帮助，并希望园子里的朋友批评指正。后续还会发布一些《Net设计模式》系列的文章，主要是以设计原理,实例,源码的方式说明各个设计模式，请大家关注，再此感谢。

最后以一本UML书中的一个例子结束：

如果以建造房子比喻，那么学习UML的过程，就是学习如何从建筑工人成长为建筑师的过程。一个软件工程师不能简单地只是掌握堆砌砖瓦的技术，还应该有设计高楼大厦的能力。