UML建模.docx

UML建模.docx

《UML建模.docx》由会员分享，可在线阅读，更多相关《UML建模.docx（50页珍藏版）》请在冰点文库上搜索。

UML建模

一、为什么要学习UML

UML是UnifiedModelingLanguage（统一建模语言）的简称。

UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。

制品{Artifact}是指软件开发过程中产生的各种各样的产物，如模型、源代码、测试用例等。

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

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

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

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

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

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

二、UML的历史

1997年，OMG组织（ObjectManagementGroup对象管理组织）发布了统一建模语言（UnifiedModelingLanguage，UML）。

UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。

UML提出了一套IT专业人员期待多年的统一的标准建模符号。

通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。

2003年，UML已经获得了业界的认同。

在所见过的专业人员的简历中，75%都声称具备UML的知识。

然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。

通常地，他们将UML用作一个术语，或对UML一知半解。

大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML1.4的快速入门文章。

当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。

三、UML的特点

UML的主要特点包括：

统一的标准

面向对象。

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

可视化、表现能力强

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

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

四、UML中的视图

UML中的视图包括用例视图（UseCaseView）、逻辑视图（LogicalView）、实现视图（ImplementationView）、进程视图（ProcessView）、部署视图（DeploymentView）等，这5个视图被称作”4+1”视图.如下图所示：

逻辑视图。

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

开发视图。

开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。

开发视图和逻辑视图之间可能存在一定的映射关系：

比如逻辑层一般会映射到多个程序包等。

处理视图。

处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。

处理视图和开发视图的关系：

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

物理视图。

物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

物理视图和处理视图的关系：

处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。

五、UML建模工具

市面上UML建模工具很多，比较流行的有RationalRose，MicrosoftVisio、EnterpriseArchitect、VisualUML等。

《UML建模-面向对象设计》系列文章使用的UML建模工具是EnterpriseArchitect7.0，此工具还是比较好用的。

六、UML的应用领域

UML具有很广泛的应用领域，其中最常用的是为软件系统建模，主要领域有：

企业信息系统、银行金融系统、电信、交通、国防、航空、零售领域、科学计算、分布式的基于Web的服务。

UML还可以用来描述其他非软件系统，比如一个机构的组成和机构的工作流程等等。

七、UML的构成

《UML建模-面向对象设计》系列文章描述了常见的一些UML图，主要包括了用例图（UseCaseDiagram）、类图（ClassDiagram）、活动图（ActivityDiagram）、时序图（SequenceDiagram）、状态图（StatechartMachineDiagram）、部署图（DeploymentDiagram）、业务处理模型（BusinessProcessModel）、数据建模（DataModelingDiagram）等等。

1如何书写UseCase

什么是UseCase

用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。

是后期时序图和实际开发的重要依据。

也可以对作为项目估算的依据，以及根据UC复杂度和开发周期来衡量开发人员的工作效率。

因此UC的书写规范及其重要，就工作用的一些经验，比如书写格式、书写内容及其注意事项与大家分享。

大纲图：

一、前期准备

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

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

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

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

  根据需求生成ＵＩ界面

二、UseCase内容

首先有用例名称：

一般是模块名称或者模块中功能点的名称。

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

1、基本描述（BriefDescription）

描述用例在系统中的作用。

比如此用例的使用者是谁、使用者所要做的操作。

2、前置条件（Precodition）

描述该用例执行前所要满足的条件。

比如用例B执行前，必须先执行A，则用例的前置条件是执行A。

3、事后保证（PostCodition）

此用例执行完毕后的条件

4、主要流程（BasicFlows）

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

5、选择性流程（AlternativeFlows）

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

6、特别需求（SpecialRequirement）

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

7、使用界面（UserInterface）

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

8、附加资讯（AdditionInformation）

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

三、总结

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

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

一、概述

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

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

二、术语解释

1、Extends用例扩展关系

扩展关系一般用来描述一个元素延伸为另外一种行为。

UseCase中的扩展表示一个UC有可能扩展到另外一个UC的功能。

UseCase中的扩展通常暗示一个选择性流程。

2、Include用例包含关系

包行关系表示源元素包行目标元素的行为，UC中的包含关系就是一个UC中包行另外一个ＵＣ的行为功能。

用包行关系可以防止在多个ＵＣ中同时定义共同的功能模块，有些像委托delegation

3、角色（Actor）

系统中的用户根据系统分为多个角色，每个角色都会与系统有交互。

一个用户可以具有一个或者多个角色。

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

比如：

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

三、如何画UseCase用例视图

 Note:

设计工具是EA（EnterpriseArchitect7.0）

 假设目前的功能需求是：

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

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

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

1、新建工程

   【File】->【NewProject】->填写工程名称：

Example.eap

2、新建UseCaseView用例视图

   右击上面新建的Project->选择【NewView】->弹出对话框，选择【UseCse】如下图

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

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

弹出如下对话框：

选择【UMLBehavioral】->UseCase,单击【OK】

这样，一个空的UseCase新建完成。

接下来我们需要向空的UseCase添加内容。

3、根据业务需求画UseCase视图

Note：

从左侧的ToolBox工具栏中

选择一些UseCase的元素，直接拖曳左边的Element，到右边的工作区，就可以把Element放到咱们的UseCase试图中。

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

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

如下图所示：

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

至此，商品提报场景的UseCase图已经画完。

一个UseCase视图会对应一个或者多个UseCase用例。

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

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

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

五、总结

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

是客户和开发人员全貌理解项目需求功能比较好的一个方式，也是后续功能迭代的依据和方向。

3、类与类之间的关系图（ClassDiagram,UML图）

一、简介

类是对象的集合，展示了对象的结构以及与系统的交互行为。

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

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

二、类的构成

类主要有属性和方法构成。

比如商品属性有：

名称、价格、高度、宽度等；商品的方法有：

计算税率，获得商品的评价等等。

如下图

三、类之间的关系（Relationship）

关联（Association）

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

1、单向关联

A1->A2:

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

场景：

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

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

C#代码:

PublicclassOrder

{

      PublicListorder;

Public void AddOrder（Productproduct）

      {

             order.Add（product）;

}            

}

PublicClassProduct

{

}

代码表现为：

Order（A1）中有Product（A2）的变量或者引用

2、双向关联

B1-B2:

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

场景：

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

类与类之间的双向关联图

C#代码

PublicclassUser

{

      PublicListGetOrder（）

      {

}     returnnewList（）;

}

PublicClassOrder

{

      PublicUserGetUserByOrderID（stringOrderId）

      {

             ReturnnewUser（）;

}

}

3、自身关联

同一个类对象之间的关联

类与类之间自身关联图

4、多维关联（N-aryAssociation）

多个对象之间存在关联

场景：

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

类与类之间的多维关联图：

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建模之活动图介绍（ActivityDiagram）

活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。

活动图在本质上是一种流程图。

活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。

一、活动图的组成元素ActivityDiagramElement

1、活动状态图（Activity）

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

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

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

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

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

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

2、动作状态（Actions）

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

动作状态有如下特点：

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

（2）、动作状态是不可中断的。

（3）、动作状态是瞬时的行为。

（4）、动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。

动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关。

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

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

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

3、动作状态约束（ActionConstraints）

动作状态约束：

用来约束动作状态。

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

4、动作流（ControlFlow）

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

5、开始节点（InitialNode）

开始节点：

表示成实心黑色圆点

6、终止节点（FinalNode）

分为活动终止节点（activityfinalnodes）和流程终止节点（flowfinalnodes）。

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

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

7、对象（Objects）

8、数据存储对象（DataStore）

使用关键字«datastore»

9、对象流（ObjectFlows）

对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。

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

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

（1）、一个对象可以由多个动作操作。

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

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

对象流用带有箭头的虚线表示。

如果箭头是从动作状态出发指向对象，则表示动作对对象施加了一定的影响。

施加的影响包括创建、修改和撤销等。

如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。

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

10、分支与合并（DecisionandMergeNodes）

分支与合并用菱形表示

11、分叉与汇合（ForkandJoinNodes）

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

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

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

12、异常处理（ExceptionHandler）

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

13、活动中断区域（InterruptibleActivityRegion）

活动中断区域围绕一些可被中断的动作状态图。

比如下图，正常情况下【ProcessOrder】顺序流转到【CloseOrder】，订单处理流程完毕；但在【ProcessOrder】过称中，会发送【CancelOrder】请求，这时会流转到【CancelOrder】，从而订单处理流程结束

14、泳道（Partition）

泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。

在活动图中，泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。

在包含泳道的活动图中，每个活动只能明确地属于一个泳道。

泳道是用垂直实线绘出，垂直线分隔的区域就是泳道。

在泳道的上方可以给出泳道的名字或对象的名字，该对象负责泳道内的全部活动。

泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。

二、活动图案例分析

1、 泳道分为：

会员泳道和系统泳道。

会员选择商品并加入购物车，系统完成订单生成及其支付完毕。

2、 开始节点：

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

3、 结束节点：

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

4、 活动状态：

产生订单、CheckCreditCart核对信用卡、CheckStock核对库存量、DeliverGoods发送商品、ProcessCreditCart付款

5、 分叉与汇合：

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

三、总结

活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。

活动图能够表示并发活动的情形，活动图是面向对象的。

5、UML建模之状态图（StatechartDiagram）

一、状态图简介（Briefintroduction）

状态图（StatechartDiagram）主要用于描述一个对象在其生存期间的动态行为，表现为一个对象所经历的状态序列，引起状态转移的事件（Event），以及因状态转移而伴随的动作（Action）。

一般可以用状态机对一个对象的生命周期建模，状态图用于显示状态机（StateMachineDiagram），重点在与描述状态图的控制流。

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

状态有Opened、Closed、Locked。

事件有Open、Close、Lock和Unlock。

注意：

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

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

二、状态图元素（StateDiagramElements）

1、状态（States）

   指在对象的生命周期中的某个条件或者状况，在此期间对象将满足某些条件、执行某些活动活活等待某些事件。

所有对象都有状态，状态是对象执行了一系列活动的结果，当某个事件发生后，对象的状态将发生变化。

状态用圆角矩形表示

初态和终态（InitialandFinalStates）

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

2、转移（Transitions）

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

事件标记（Trigger）：

是转移的诱因，可以是一个信号，事件、条件变化（achangeinsomecondition）和时间表达式。

警界条件（GuardCondition）：

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

结果（Effect）：

对象状态转移后的结果。

3、动作（StateActions）

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

在上例中，对象状态转移后的结果显示在转移线上，如果目标状态有许多转移，而且每个转移有相同的