[转载]基于UML的需求分析和系统设计（完整案例和UML图形演示）

小序：

从学生时代就接触到UML，几年的工做中也没少使用，各类图形的概念、图形的元素和属性，以及图形的画法都不能说不熟悉。可是怎样在实际中有效地使用UML使之发挥应有的做用，怎样捕捉用户心中的需求并转换成明确的UML图形，怎样把本身心中的设计意图经过UML图形准确地表达出来，以及各职责人员如何经过UML图形进行有效沟通，关于这些，却深感迷茫。

最近有幸获得了一个台湾人赖信仁写的《UML团队开发流程与管理》这本书，才拜读了前两章，就已经爱不释手了，很有点欣喜若狂的感受，看了半本书以后，上述的种种疑惑均已雾开云散了。

这本书与我以前看到过的任何一本UML的书籍都不一样，它并无详细介绍每种UML图形的各类元素和属性，而是重点讲述每种UML图形的使用场景，以及具体项目过程当中如何进行分析和设计，并使用相应的UML图形精确传达设计意图。也就是说，它不是讲述UML是什么，而是结合具体项目实战讲述UML图形应该什么时候用、以及怎么用。

这本书细读下来，反复琢磨，着实受益不浅，终于感到UML真正强大之处，同时深感有必要将书中的精华部分整理成一篇文章，既有利于之后随时翻阅恢复记忆，又能达到快乐分享的目的，故有此文。http://yunzhu.iteye.com

 

概要：

书中共有三个部分，第一部分结合一个完整的按钮“信仁医院住出院系统”逐个讲解UML2.0的14个图形，讲解每一个图形的最佳使用场景以及如何构思和绘制图形；第二部分结合另外一个完整的案例“电子化采购系统”，讲解以UML驱动的整个从分析到设计到编码到测试的全过程；第三部分则是关于如何将UML应用于团队合做当中。

 

本文摘录书中主要脉络和精华部分，按照本身的想法系统地串接起来，主要讲解如何在项目过程各阶段采用合适的UML图形进行分析和设计，重点关注如下问题：

• 怎样在实际中有效地使用UML使之发挥应有的做用
• 怎样捕捉用户心中的需求并转换成明确的UML图形
• 怎样把本身心中的设计意图经过UML图形准确地表达出来
• 怎样经过UML进行项目各阶段的平稳推动（分析→设计→编码）

本文将采用两个案例进行实例演示：

【电子化采购系统】案例背景介绍
客户企业是一家大型家电制造商，主要业务是制造和销售家电产品。客户企业的信息系统包括了一个大型ERP。由于想要厂商提供更加即时快捷的服务，客户企业委托设计一个电子化采购系统。

 

【信仁医院住出院系统】案例背景介绍
信 仁医院是一家区域医院，共有200张病床，医院的只能科室包括内科、外科以及皮肤科。该医院在2000年采购了一套医院内部的医院管理系统，其中包括门诊 系统、挂号系统、收费管理系统、医保申报系统以及财会系统。以往，信仁医院在办理住院出院时都必须使用人工填表的方式，只有在医保给付、门诊医嘱以及收费 管理方面，才能进入医院管理系统进行记录。但为了实现“e化医院项目”，信仁医院须要从新设计一整套住院、出院系统。

 

书本以及本文使用的UML绘制工具是：Enterprise Architect，官方网址：http://www.sparxsystems.com

 

 

1、项目开始阶段

这个阶段，也就是至关于传统软件工程中的问题定义和可行性研究，这个阶段主要是经过与用户的访谈，以确认待开发系统“要作什么”，并进行可行性研究，简单来讲就是从企业的角度出发研究这个项目是否能作、是否能盈利，不然最终项目失败那对企业就会形成损失了。

 

项目开始阶段的初期访谈须要抓住如下几个重点：

• 项目的范围：先找出目前已存在的系统，了解该系统是否提供了相关的集成接口，这一点与你所要开发的项目的复杂度有至关大的关系。
• 必要的业务流程：在摸索业务流程时，初期应该尽量只捕捉就“必要的”业务流程，在该业务流程中，尽可能避免对细节的研究。
• 项目的技术限制：包括使用的技术以及其余系统间的交流接口规范。
• 项目的成功关键因素：要充分了解利益相关方对于总体项目成功与否最关切的问题是什么，而且评估问题和项目成败的风险是否相关。

上述四个重点，其实在一开始就决定了项目是否会成功，若是在项目开始时就落入了细节性的讨论，反而容易形成项目的失败，对于开发团队来讲不可不慎。

 

本阶段结束以后，若是正式立项，那么便进入下一个阶段——需求分析。

 

2、需求分析阶段

需求分析阶段，主要是跟客户（领域专家）沟通，进行需求的收集和分析，而后经过标准的文书准确地表达出来，并造成需求规格说明书之类的文档，交由设计人员进行后续的系统设计工做。

UML中的用例图正是用于需求收集和表达的有力工具，可是如何找出用例并不是易事，这是由于从用户那里收集来的信息极可能是零散的、没有系统性的，要直接从中找出正确的用例很是困难。

所以在分析用例以前，能够先对企业级的业务流程进行规划和设计，抓住企业的本质工做流，为后续进行详细的需求收集和用例分析作好准备。

 

一、业务流程设计

对于企业的经营管理团队来讲，业务流程规划与企业的永续经营之间存在着密切关系。简单来讲，业务流程就是为了服务客户而执行的一连串业务内部活动。业务流程分析的目的在于了解总体流程对企业目标的支持分别有何贡献，进而对流程的细节进行规划。

那 么如何进行业务流程的设计呢？Jacbson认为，利用“用例”的“目标导向”特性，能够经过一个“企业级的用例”来完善工做流程的规划与设计。不过衡量 实际情况，大部分领域专家对“用例”的接受度较差，所以可使用另外一个工具来进行企业的建模，这个工具是由Erickson和Penker所提出的一个活 动图的构造型，称为“Eriksson-Penker业务扩展模型”。

 

1）业务流程规划——Eriksson-Penker业务扩展模型

Eriksson-Penker业务扩展模型是一种“目标导向”的流程分析方式，主要是将与业务流程相关的重要人、事、物以及这个业务流程所要实现的目标作一个连接，描述了企业中重要的人、事、物与流程的关系，这个图中一般不会过多地介绍业务流程的内部细节。在项目开始阶段，需求分析人员能够经过“Eriksson-Penker业务扩展模型”找出要开发系统的重要性，利用“目标导向”方式，对业务流程进行适当的切割。

关于Eriksson-Penker业务扩展模型，详细请看Enterprise Architect官方网站的介绍：业务过程建模→「Eriksson-Penker 业务建模 Profile」节

 

★ Eriksson-Penker业务扩展模型示例

针对一家大型家电制造商要开发的电子化采购系统的业务流程：http://yunzhu.iteye.com

※　图中之因此分红两个不一样的流程，是由于两个流程有不一样的“实现目标”。

2）业务流程分析——活动图

在 与领域专家进一步沟通后，就能够对“Eriksson-Penker业务扩展模型”中的每个“处理”绘制一个对应的活动图，在绘制活动图时，应该将重点 放在“活动”自己，而不须要加入其余因素（文件、数据、表单等）。在活动图中，这些因素应该要在上层的“Eriksson-Penker业务扩展模型”就 表达完成。

 

活动图最适合用来描述企业的本质工做流。在绘制活动图时千万不要去研究活动的细节，活动图所要捕捉的是总体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才须要捕捉。

活动图的使用场景：

• 项目起始阶段，需求分析人员可使用活动图，针对与项目相关的企业活动，与领域专家一块儿设计流程
• 项目上线阶段，能够用利用起始阶段的活动图做为集成测试的重要参考依据
• 项目维护阶段，企业管理人员能够经过活动图了解企业现行的流程以及将来能够改善的方向

 

在设计活动图时须要遵循如下原则：

• 活动图的目的在于表达“流程完整性”而非活动细节。
• 活动图中的元素（主要是活动）没必要考虑复用性。
• 若是在活动图中绘制了一个“分叉点“，则必定要有一个”会合点“与之对应。
• 活动图中尽可能不要表达”文件“或”数据“。

 

关于设计活动图时的两点重要建议：

• 绘制活动图时，最好和领域专家直接当面沟通，最好在访谈过程当中直接绘制活动图，并根据活动图附属一次在访谈中所收集到的相关信息。这样，活动图所收集到的信息将更加贴近实际。
• 在绘制活动图时千万不要去研究活动的细节，活动图所要捕捉的是总体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才须要捕捉。

 

★ 表达业务流程的活动图示例

针对上面的电子化采购系统业务流程图中的——“请购流程”，在与领域专家详细沟通后，能够绘制出以下请购流程的活动图。http://yunzhu.iteye.com

在完成各主要业务流程的分析，绘制出活动图之后，即可以开始下个分阶段的工做——从业务流程中找出用例，进行需求收集，完成用例模型。

 

二、需求收集——用例图

1）关于用例的相关介绍

用例是一个系统中所进行的一连串的处置活动，该活动主要是要可以知足系统外部的执行者对于系统的某种指望。
每个信息系统的用例表明着用户对于系统的“某一个完整指望”。
一般来讲，用例是“需求收集及整理”的工具，经过用例与执行者的关系，可让需求分析人员“聚焦”在特定的“相关人员”（也就是执行者）与”主题“（也就是用例）中。

 

2）找出用例的三个步骤

根据前面所绘制的业务流程的活动图，能够经过如下三个步骤找出用例：

 

① 利用与用户的对话找出信息系统的用例

将活动图中的每一个“活动”看成“用例”的候选，接着针对每一个”活动“询问用户如下几个问题：

• 在这个活动中谁是主要参与者？
• 这个活动的进行中须要系统提供服务吗？
• 系统须要提供什么服务？
• 系统须要其余信息系统的支持吗？

而后对候选用例进行必要的合并和关系（好比“包含”）分析， 从而得出业务流程相关的用例图。

 

★ 业务流程相关的用例图示例

针对上面请购流程的活动图进行上述分析，能够得出如下用例图：http://yunzhu.iteye.com

② 完成用例的正常流叙述

编写用例叙述时遵循的原则：

• 每一个叙述都必须是确定句
• 在叙述中，切记不要描述过多细节

③ 完成用例的替代流及意外处理叙述

替 代流自己仅仅只是正常流的“分支”而非“主干”。举例来讲，若是在正常流2有三个替代流，则在替代流的区块中，就会有2a、2b、2c三个分支，而在这三 个分支的编写中，仍然必须遵循着每一句都是“确定句”的原则。若是在其中又有替代流，则同样必需要利用分支的方式来编写。这样，因为每一个叙述都是简短的肯 定句，天然而然增长了将来的扩展空间。

 

配合“迭代增量”的开发方式，这三个步骤不是一次就所有完成，而必需要分批完成。

• 项目开始阶段（一般是一到两个星期）必须完成第一个步骤，也就是找出六成用例，在这个部分，切记要保留将来增长用例的空间。
• 接着，针对用例进行开发顺序的权重排序，这个排序主要针对“复杂度”、“与外部系统的关系”以及“重要性”来进行，权重越高的用例应该要越早开发。
• 在每一个用例中，第二个步骤（找出用例正常流叙述）必须是开发的第一个迭代，在该开发迭代进行到系统设计以及编码阶段时，需求分析师才须要进行第三个步骤的分析，也就是收集更详细的信息以及相关的替代流。

 

3）关于用例的用例叙述

用例的叙述通常来讲至少分红四种：

• 用例的简述：一般是用一两句话来讲明这个用例的目的是什么。
• 用例的正常流：在这个流程中，必须说明执行者与系统交互的过程，不过在这个交互过程当中，必须假设整个流程都必须实现，也就是说这是一个“快乐路径”，在这个流程描述中，全部句子都必须是“确定句”。
• 用例的替代流：在正常流中，若是有“替代路径”，必需要利用另外的替代流来讲明，而不是直接在正常流中写“if-then-else“。
• 用例的意外处理：一般指系统例外状态的处理，与替代流不一样，替代流每每是执行者对于流程有不一样的指示，由于将流程导向不一样的结束点，而意外处理则一般是系统发生错误致使的正常流的意外情况。

用例的叙述是很是关键的部分，必须可以准确地把握用户的真正指望是什么，后续的设计工做都将围绕用例特别是用例叙述来展开。

 

4）编写用例的测试案例

通常来讲，在找出用例后就应该编写用例的测试案例，测试案例的编写主要利用“输入→预期产出“的方式来描述，每一个测试案例都须要准备对应的测试数据。

 

 

3、系统设计阶段

前一阶段的主要产物是用例图，后续的设计和开发阶段都将以用例驱动，围绕用例展开，而系统设计阶段的主要工做，即是实现用例。

 

一、实现用例

实现用例的目的在于保证系统的设计能够知足用户的功能性需求，在实现用例的过程当中，应该利用Jacobson所分类的三种分析类：

• 控制对象（Control Object）     ：控制对象包装了一个或多个用例的功能性需求，属于功能性对象，并且这个功能与用例有至关密切的关系。
• 实体对象（Entity Object）        ：实体对象管理了信息及其衍生资源的存取，是属于系统本质面的概念性对象，这类对象并不会随着用例的增多而有所变更。
• 边界对象（Boundary Object）  ：边界对象是属于与外部桥接的对象，这类对象将与外部直接接轨，直接受到外部的限制。（注意：这里的“对象”并不是指类的实例那种对象）

 

1）勾勒用例的控制对象

①  针对每一个用例提供一个“控制对象”
②  明确这个控制对象的责任（Responsibility）是什么
      从“主执行者”在正常流的叙述中出现的次数来决定系统要提供几个服务；
      再从每个“对话块”中，“系统”当主语的最后一句话，找出这个责任的名称。
③  明确这个服务的输入输出
      判断这个服务中，是否须要“主执行者”提供什么信息，而“系统”又须要回复主执行者什么信息
④  进入到服务内部，审视服务的实现方式
      在控制对象的内部，每个以“系统”当主语的叙述均可以独立成一个新的功能函数；
      只是该功能函数并不是是提供给主执行者的，所以是一个“私有”的函数，只提供给控制对象使用。

 

勾勒用例的控制对象示例过程

针对前面用例图中的第一个用例“产生请购需求（RFP）”，咱们能够提供一个“产生请购需求（RFP）控制对象”。

 

“产生请购需求（RFP）”的“正常流”叙述：

(1) ERP系统提供[年度物料采购计划]给系统。
(2) 系统根据[BR1]产生[厂商询价推荐名单]。
(3) 系统依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商。

 

分析过程以下：

从（1）得知“主执行者”是：ERP系统；

“主执行者”总共出现了1次，也就是所只有一个“对话块”，因此系统要提供1个服务；

“对话块”中“系统”当主语的最后一句（3），可得知系统所需提供的服务是：产生厂商询价推荐名单；

从（1）可知服务的输入是：年度物料采购计划；

从（3）可知服务的输出是：厂商询价推荐名单；

从（2）可知服务内部必须完成的第一件事：根据[BR1]产生[厂商询价推荐名单]；

从（3）可知服务内部必须完成的第二件事：依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商；

因此从上面两步可知控制对象内部须要两个“私有函数”。

 

★ 控制对象的类图示例http://yunzhu.iteye.com

2）针对控制对象绘制序列图

前面探讨了如何找出信息系统中所需的控制对象，但这样仍然不够，由于前面并无完整描述出究竟对象与对象之间是如何通力协做，来知足用例所描述的用户需求。所以，必需要使用序列图来讲明这个交互过程。

 

在绘制序列图时，能够采用两阶段序列图绘制法：

① 把信息系统当黑箱，利用用例叙述找出系统所应负责的服务。

     这个步骤能够先绘制一个序列图，而后把用例叙述放在该序列图的右方（这样便于对比），而后参照用例图，把相对应的用例转换为一个叫作“系统”的对象。

② 把黑箱打开，加入找出的分析对象，并把系统所需实现的责任分配给适当的对象。

     把上个步骤获得的“黑箱”序列图中的“系统”换成实际的控制对象，而且依据找出的控制对象的责任，看看是否一致，这样就完成了序列图的设计了。

 

★ 控制对象的“黑箱”序列图示例

针对上面的产生请购需求的控制对象，根据步骤①，把信息系统看成一个“黑箱”，即可获得如下序列图：http://yunzhu.iteye.com

3）找出用例的实体对象

可 以经过Peter Coad的“交易模式”找出用例的实体对象，这个模式的假设是：当发现企业所关心的问题领域存在必需要记录的某些事件时，这表明着这个事件是一个交易。而 系统设计人员能够从交易出发，依次去找出与这些交易相关的企业概念（人、地、物），如此就能够迅速地得出这个企业的概念模型。

总之，实体对象主要是根据对于问题领域的理解来找出问题领域中的重要概念，对于实体对象的分析，不管是对于进行“实体关系图的”的数据库设计，或是利用“对象模型”作的“结构分析”来讲，都是至关重要的设计准则。

实体对象属于领域模型的重要概念，将在下一节“创建领域模型”中重点讲解。

 

4）系统设计阶段的开发流程

①  经过对用例的理解以及对用例叙述的分析，找出系统的控制对象及其操做。

②  经过与领域专家的访谈过程，找出系统的实体对象以及重要熟悉。

③  设计人员利用两阶段绘制的序列图，验证前述的控制对象及操做的正确性。

 

前面经过三种分析类实现用例的方式，会从用例出发分别找出控制对象、实体对象和边界对象，在找出这些“对象”（这里的对象并不是指类的实现，而是指一种分析类）以后，即可以创建完整的“领域模型”了。

 

二、创建领域模型

1）“领域模型”的概念

要了解领域模型，就要先了解何为软件的“本质”：“本质”指得就是要想办法直指想要解决的问题的“核心”。

从软件结构的层面来看，“本质”指的就是你所要解决的问题领域中的重要“概念”在抽象层次的呈现。通常来讲，这样的呈现方式的会经过“概念模型”来表示。
“概念模型”就是可以用最简化的方式表达一个完整的“问题领域”的抽象表示法。概念模型的原始定义是表达问题领域中的概念，所以，一般将概念模型称为“领域模型”。

 

2）使用类图表达领域模型

在UML中一般建议使用“类图”做为表达领域模型的图形。
类图主要表达的是问题领域的“抽象概念”，在这个抽象概念中，除了表达该抽象概念的名称外，另外须要表达该抽象概念的“属性”与”行为”。
类图的主要目的是在进行软件开发前，先对软件所需面对问题领域的本质做一个通盘性的了解，但类图在软件设计之初并不彻底正确，必须经过后续的检查才可以逐渐趋近于真实世界的领域模型。

 

3) 信仁医院住出院管理系统案例演示

接下来将采用信仁医院住出院管理系统的案例来进行演示，为了分析和设计流程的连贯性，将从业务流程分析的部分开始。

 

（1）住出院系统业务流程

在项目立项以后，需求分析师与医院的领域专家经过面对面的访谈，整理出了医院实际上的住院出院流程，并绘制成活动图。http://yunzhu.iteye.com

 

（2）住出院系统用例模型

需求分析师基于企业的业务流程图，与领域专家经过进一步沟通，进行需求的收集，最终绘制出用例图。固然下图中没有包含用例叙述。http://yunzhu.iteye.com

（3）住出院系统领域模型

在获得用例图以后，便进入实现用例的阶段，能够经过上一节所介绍的三种分析类找到问题领域中的重要概念，从而获得领域模型，而后经过类图来表达。

好比针对上一节用例图中的“登记出院记录”用例，经过分析能够获得一个控制对象（登记出院记录BPO）和多个实体对象（病床、病人、医生、护士、病症等），并绘制成以下的类图。http://yunzhu.iteye.com

4）包图

一般领域模型中会包含不少的类，必须对这些类进行分类，放置在不一样的命名空间中，利用命名空间之间的关系图，来限制住不一样分类对象之间的访问，这就是“包图”的使用场景。

“包图”是一个高阶的视图，因为全部的类都必须属于某一个包，所以当包之间的关系被限定时，该包内部全部的类，都会受到包图中设置的影响。

 

★ 住出院系统包图

好比最基本的分类就是按照上面所说的三种分析类，对上面的领域模型，按照这种方式进行分类，即可以绘制出以下包图：http://yunzhu.iteye.com

 

 

三、表达对象交互

通常来讲，咱们在用例分析中将系统应该知足的用户指望找出来了；而在类图中则将系统的架构构造出来。可是，针对每一个特定的用例的场景，要如何利用类图所规范的对象，经过交互协做来完成用例所交付的任务，就必需要用序列图来表达。

 

1）序列图

序列图的主要目的在陈述用例的正常事件流中，对象彼此之间的交互关系。也就是说，序列图的主要来源是用例的叙述。

 

序列图的主要任务包括：

• 表达设计人员心中关于未来程序在运行时的对象协做模型
• 验证软件领域模型的正确性
• 为程序员提供编码的蓝图

绘制序列图的两点重要建议：

• 在绘制序列图时，要首先打破一个迷思：序列图并不须要“务求精细”，由于它毕竟只是一个“蓝图”，并不是是完整的“施工计划”。
• 在设计“序列图”时，要遵循一个原则：一个序列图的大小，最好可以限制在一张A4纸能够打印的范围内，最大也不要超过一张A3纸的打印范围。超过这个范围的序列图一般是无效的产出。为了达到这一点，最好把正常流与替代流分开来绘制不一样的序列图，每一个序列图有本身的重点，不要把全部的逻辑都表达在同一个序列图中。

 

★ 登记出院记录序列图

针对“登记出院记录”的用例，根据用例叙述，获得如下序列图。http://yunzhu.iteye.com

 

验证领域模型正确性

从前面的类图来看，“登记出院记录BPO”是与“住院事件”想关联的，但在序列图中，“登记出院记录BPO”倒是和“病床”有消息传递，这彷佛并不符合类图所表达的领域模型。咱们能够进一步经过另外一个表达对象交互协做的通讯图来进行验证。

 

2）通讯图

通讯图与序列图其实都是在表达同一件事情：对象相互合做，以实现用例的“事件流”。

 

为何要使用通讯图进一步验证呢？

因为序列图是以时间作横轴，所以对将来的程序设计而言，序列图具备“蓝图”的效果，但若是须要同时表达对象的结构与彼此间的协做关系，则只有通讯图才能较为完整地进行呈现。

究竟项目设计人员在设计序列图时，心中是否对象模型，所以但愿项目设计人员能利用“通讯图”来从新审视本身对对象模型的理解，来确认序列图有没有违反领域模型。

 

★ 登记出院记录通讯图http://yunzhu.iteye.com

 

3）交互概述图

在绘制序列图和通讯图等交互图时，须要注意：

• 不能“务求精细”过于详尽，由于交互图只须要描述一个“蓝图”而不是完整的“”施工计划；
• 一张交互图不能太大，最好能在一张A4纸的能够打印的范围内，顶多一张A3纸，不然会成为无效的产出；
• 每一个交互图应该有表达的重点，不要在一个图中表达全部的逻辑，若是有替代流，那么就针对一个替代流再绘制一个单独的交互图。

那么，这些分散的交互图怎么才能组合在一块儿呢？这时能够利用交互概述图。

交互概述图主要是利用活动图做为基础，只是在“控制流”间链接的UML元素并不是活动，而是交互图（包括：序列图、通讯图、时间图以及交互概述图）。

 

四、表达微观设计

 

1）对象图

对象图旨在描述特定时间点中全部对象在系统中的结构；所以，能够将对象图当成系统在某一个时间点的快照。

对象图表达的是在某一个特定时间点中，系统所存在的全部对象的快照，其主要目的是验证设计师设计的类图是否符合实际情况。

对象图的使用场景：
当与领域专家沟通时，能够用对象图解释类图的设计，以验证类图的正确性。
当与编码人员沟通时，能够利用部分的对象图，来解释类图中的复杂结构。

 

★ 住出院系统对象图

针对前面设计的信仁医院住出院系统的领域模型，能够参考日剧《白色巨塔》做为范本，将该剧中最重要的一个“佐佐木先生”住院事件转换为对象图。http://yunzhu.iteye.com

 

2）状态机图

类图中某一个实体对象，它的状态迁移分散在不一样的用例中，须要在这些状态和事件之间进行一番整理，才能让项目开发人员更简便地完成设计，这时可使用状态机图来表达。
为了成功地设计软件，将“状态”分配到不一样的“领域模型”中，并利用“状态机图”来表达这些状态的迁移情形。

 

★ 病床状态机图

在信仁医院住出院系统的领域模型中，有一个“病床”实体对象，它的状态迁移分散在不一样的用例中，可使用以下状态机图统一表达这些状态的迁移。http://yunzhu.iteye.com

 

3）时间图

若是在状态迁移中牵涉到时间因素，则能够利用时间图来强调事件因素的重要性。设计人员能够把时间图当成状态机图的辅助说明工具。

 

★ 过时取消预约时间图

关于前面病床的撞他，若是病人预约了病床，可是后来一直没有去使用病床，那么这个病床该怎么办呢？总不能直接空着吧？关于这一点，信仁医院的处理是这样的：超过半小时病床状态要自动迁移到Empty。这个设计内容很难在状态机图中表达，这时可使用时间图。http://yunzhu.iteye.com

 

总结和展望

到此为止，本文已经讲解了需求分析阶段和系统设计阶段使用的主要UML图形，除了这些图形以外，还有如下UML图形，本文不作详细介绍：

• 总则图         ：UML2.4规范新增，主要用于将团队开发中重要的观念或技术使用“构造型”加以整理，让全部团队成员能够共享这些共同的知识，其主要目的在于聚集团队成员的共同词汇，以求在总体上畅通地进行沟通。
• 组合结构图  ：UML2.4规范新增，主要用于表达要开发系统与外部系统间的关系，很是适合让架构师在初期阶段做为评估系统复杂度的工具，也可做为将来系统维护的参考图形。
• 组建图         ：从系统实现的角度进行绘制，主要目的是呈现系统在实现时如何把设计的类分配给不一样的物理组件。
• 部署图         ：描述物理组件与实体计算机之间的关系，整体上是规划物理组件的实际位置的一个图。通常来讲，当开发一个大型系统时，会比较须要组建图和部署图这两个图。

后记

总 算写完了，从拿到这本书开始，看了整整一个月，写这篇博客又花了半个月，从未在一本书上花过这么的时间，但仍是以为很值。一个字一个字的敲出来，一个图一 个图的画出来，虽然说耗时甚多，但也使得印象更加深入了。加上反复琢磨反复钻研，对UML终于有了深入的认识，对于UML的实际应用，也有了了然于胸的感 觉。同时也殷切地但愿这篇文章可以对您有所帮助。真心以为这本书值得一看。

在此感谢亲爱的老婆在生活和精神上的鼎立支持，也感谢即将出生的亲爱的小宝宝

 

博客同步发布地址：http://yunzhu.iteye.com/blog/1914288