小序:从学生时代就接触到UML,几年的工作中也没少使用,各种图形的概念、图形的元素和属性,以及图形的画法都不能说不熟悉。但是怎样在实际中有效地使用UML使之发挥应有的作用,怎样捕捉用户心中的需求并转换成明确的UML图形,怎样把自己心中的设计意图通过UML图形准确地表达出来,以及各职责人员如何通过UML图形进行有效沟通,关于这些,却深感迷茫。 最近有幸得到了一个台湾人赖信仁写的《UML团队开发流程与管理》这本书,才拜读了前两章,就已经爱不释手了,颇有点欣喜若狂的感觉,看了半本书之后,上述的种种疑惑均已雾开云散了。 这本书与我之前看到过的任何一本UML的书籍都不同,它并没有详细介绍每种UML图形的各种元素和属性,而是重点讲述每种UML图形的使用场景,以及具体项目过程中如何进行分析和设计,并使用相应的UML图形精确传达设计意图。也就是说,它不是讲述UML是什么,而是结合具体项目实战讲述UML图形应该何时用、以及怎么用。 这本书细读下来,反复琢磨,着实受益匪浅,终于感到UML真正强大之处,同时深感有必要将书中的精华部分整理成一篇文章,既有利于以后随时翻阅恢复记忆,又能达到快乐分享的目的,故有此文。http://yunzhu.
概要:书中共有三个部分,第一部分结合一个完整的按钮“信仁医院住出院系统”逐个讲解UML2.0的14个图形,讲解每个图形的最佳使用场景以及如何构思和绘制图形;第二部分结合另一个完整的案例“电子化采购系统”,讲解以UML驱动的整个从分析到设计到编码到测试的全过程;第三部分则是关于如何将UML应用于团队合作当中。
本文摘录书中主要脉络和精华部分,按照自己的想法系统地串接起来,主要讲解如何在项目过程各阶段采用合适的UML图形进行分析和设计,重点关注以下问题:
本文将采用两个案例进行实例演示: 【电子化采购系统】案例背景介绍
【信仁医院住出院系统】案例背景介绍
书本以及本文使用的UML绘制工具是:Enterprise Architect,官方网址:http://www.
一、项目开始阶段这个阶段,也就是相当于传统软件工程中的问题定义和可行性研究,这个阶段主要是通过与用户的访谈,以确认待开发系统“要做什么”,并进行可行性研究,简单来说就是从企业的角度出发研究这个项目是否能做、是否能盈利,否则最终项目失败那对企业就会造成损失了。
项目开始阶段的初期访谈需要抓住以下几个重点:
上述四个重点,其实在一开始就决定了项目是否会成功,如果在项目开始时就落入了细节性的讨论,反而容易造成项目的失败,对于开发团队来说不可不慎。
本阶段结束之后,如果正式立项,那么便进入下一个阶段——需求分析。
二、需求分析阶段需求分析阶段,主要是跟客户(领域专家)沟通,进行需求的收集和分析,然后通过标准的文书准确地表达出来,并形成需求规格说明书之类的文档,交由设计人员进行后续的系统设计工作。 UML中的用例图正是用于需求收集和表达的有力工具,但是如何找出用例并非易事,这是因为从用户那里收集来的信息很可能是零散的、没有系统性的,要直接从中找出正确的用例非常困难。 因此在分析用例之前,可以先对企业级的业务流程进行规划和设计,抓住企业的本质工作流,为后续进行详细的需求收集和用例分析做好准备。
1、业务流程设计对于企业的经营管理团队来说,业务流程规划与企业的永续经营之间存在着密切关系。简单来说,业务流程就是为了服务客户而执行的一连串业务内部活动。业务流程分析的目的在于了解整体流程对企业目标的支持分别有何贡献,进而对流程的细节进行规划。 那 么如何进行业务流程的设计呢?Jacbson认为,利用“用例”的“目标导向”特性,可以通过一个“企业级的用例”来完善工作流程的规划与设计。不过衡量 实际状况,大部分领域专家对“用例”的接受度较差,因此可以使用另一个工具来进行企业的建模,这个工具是由Erickson和Penker所提出的一个活 动图的构造型,称为“Eriksson-Penker业务扩展模型”。
1)业务流程规划——Eriksson-Penker业务扩展模型Eriksson-Penker业务扩展模型是一种“目标导向”的流程分析方式,主要是将与业务流程相关的重要人、事、物以及这个业务流程所要实现的目标做一个链接,描述了企业中重要的人、事、物与流程的关系,这个图中通常不会过多地介绍业务流程的内部细节。在项目开始阶段,需求分析人员可以通过“Eriksson-Penker业务扩展模型”找出要开发系统的重要性,利用“目标导向”方式,对业务流程进行适当的切割。 关于Eriksson-Penker业务扩展模型,详细请看Enterprise Architect官方网站的介绍:业务过程建模→「Eriksson-Penker 业务建模 Profile」节
★ Eriksson-Penker业务扩展模型示例 针对一家大型家电制造商要开发的电子化采购系统的业务流程:http://yunzhu. 2)业务流程分析——活动图在 与领域专家进一步沟通后,就可以对“Eriksson-Penker业务扩展模型”中的每一个“处理”绘制一个对应的活动图,在绘制活动图时,应该将重点 放在“活动”本身,而不需要加入其他因素(文件、数据、表单等)。在活动图中,这些因素应该要在上层的“Eriksson-Penker业务扩展模型”就 表达完成。
活动图最适合用来描述企业的本质工作流。在绘制活动图时千万不要去研究活动的细节,活动图所要捕捉的是整体业务流程的“大方向”。有关细节的相关描述应该是在讨论“用例”时才需要捕捉。
在设计活动图时需要遵循以下原则:
关于设计活动图时的两点重要建议:
★ 表达业务流程的活动图示例 针对上面的电子化采购系统业务流程图中的——“请购流程”,在与领域专家详细沟通后,可以绘制出如下请购流程的活动图。http://yunzhu. 在完成各主要业务流程的分析,绘制出活动图以后,便可以开始下个分阶段的工作——从业务流程中找出用例,进行需求收集,完成用例模型。 2、需求收集——用例图1)关于用例的相关介绍用例是一个系统中所进行的一连串的处置活动,该活动主要是要能够满足系统外部的执行者对于系统的某种期望。
2)找出用例的三个步骤根据前面所绘制的业务流程的活动图,可以通过以下三个步骤找出用例:
① 利用与用户的对话找出信息系统的用例将活动图中的每个“活动”当作“用例”的候选,接着针对每个”活动“询问用户以下几个问题:
然后对候选用例进行必要的合并和关系(比如“包含”)分析, 从而得出业务流程相关的用例图。
★ 业务流程相关的用例图示例 针对上面请购流程的活动图进行上述分析,可以得出以下用例图:http://yunzhu. ② 完成用例的正常流叙述编写用例叙述时遵循的原则:
③ 完成用例的替代流及意外处理叙述替 代流本身仅仅只是正常流的“分支”而非“主干”。举例来说,如果在正常流2有三个替代流,则在替代流的区块中,就会有2a、2b、2c三个分支,而在这三 个分支的编写中,仍然必须遵循着每一句都是“肯定句”的原则。如果在其中又有替代流,则一样必须要利用分支的方式来编写。这样,由于每个叙述都是简短的肯 定句,自然而然增加了未来的扩展空间。
配合“迭代增量”的开发方式,这三个步骤不是一次就全部完成,而必须要分批完成。
3)关于用例的用例叙述用例的叙述一般来说至少分成四种:
用例的叙述是非常关键的部分,必须能够准确地把握用户的真正期望是什么,后续的设计工作都将围绕用例特别是用例叙述来展开。
4)编写用例的测试案例一般来说,在找出用例后就应该编写用例的测试案例,测试案例的编写主要利用“输入→预期产出“的方式来描述,每个测试案例都需要准备对应的测试数据。
三、系统设计阶段前一阶段的主要产物是用例图,后续的设计和开发阶段都将以用例驱动,围绕用例展开,而系统设计阶段的主要工作,便是实现用例。
1、实现用例实现用例的目的在于保证系统的设计可以满足用户的功能性需求,在实现用例的过程中,应该利用Jacobson所分类的三种分析类:
1)勾勒用例的控制对象① 针对每个用例提供一个“控制对象”
勾勒用例的控制对象示例过程针对前面用例图中的第一个用例“产生请购需求(RFP)”,我们可以提供一个“产生请购需求(RFP)控制对象”。
“产生请购需求(RFP)”的“正常流”叙述: (1) ERP系统提供[年度物料采购计划]给系统。
分析过程如下: 从(1)得知“主执行者”是:ERP系统; “主执行者”总共出现了1次,也就是所只有一个“对话块”,所以系统要提供1个服务; “对话块”中“系统”当主语的最后一句(3),可得知系统所需提供的服务是:产生厂商询价推荐名单; 从(1)可知服务的输入是:年度物料采购计划; 从(3)可知服务的输出是:厂商询价推荐名单; 从(2)可知服务内部必须完成的第一件事:根据[BR1]产生[厂商询价推荐名单]; 从(3)可知服务内部必须完成的第二件事:依照[厂商询价推荐名单]请通知系统将[物料请购需求]传给名单上的厂商; 所以从上面两步可知控制对象内部需要两个“私有函数”。
★ 控制对象的类图示例http://yunzhu. 2)针对控制对象绘制序列图前面探讨了如何找出信息系统中所需的控制对象,但这样仍然不够,因为前面并没有完整描述出究竟对象与对象之间是如何通力协作,来满足用例所描述的用户需求。因此,必须要使用序列图来说明这个交互过程。
在绘制序列图时,可以采用两阶段序列图绘制法: ① 把信息系统当黑箱,利用用例叙述找出系统所应负责的服务。 这个步骤可以先绘制一个序列图,然后把用例叙述放在该序列图的右方(这样便于对比),然后参照用例图,把相对应的用例转换为一个叫做“系统”的对象。 ② 把黑箱打开,加入找出的分析对象,并把系统所需实现的责任分配给适当的对象。 把上个步骤得到的“黑箱”序列图中的“系统”换成实际的控制对象,并且依据找出的控制对象的责任,看看是否一致,这样就完成了序列图的设计了。
★ 控制对象的“黑箱”序列图示例 针对上面的产生请购需求的控制对象,根据步骤①,把信息系统当作一个“黑箱”,便可得到以下序列图:http://yunzhu. 3)找出用例的实体对象可 以通过Peter Coad的“交易模式”找出用例的实体对象,这个模式的假设是:当发现企业所关心的问题领域存在必须要记录的某些事件时,这代表着这个事件是一个交易。而 系统设计人员可以从交易出发,依次去找出与这些交易相关的企业概念(人、地、物),如此就可以迅速地得出这个企业的概念模型。 总之,实体对象主要是根据对于问题领域的理解来找出问题领域中的重要概念,对于实体对象的分析,无论是对于进行“实体关系图的”的数据库设计,或是利用“对象模型”做的“结构分析”来说,都是相当重要的设计准则。 实体对象属于领域模型的重要概念,将在下一节“建立领域模型”中重点讲解。
4)系统设计阶段的开发流程① 通过对用例的理解以及对用例叙述的分析,找出系统的控制对象及其操作。 ② 通过与领域专家的访谈过程,找出系统的实体对象以及重要熟悉。 ③ 设计人员利用两阶段绘制的序列图,验证前述的控制对象及操作的正确性。
前面通过三种分析类实现用例的方式,会从用例出发分别找出控制对象、实体对象和边界对象,在找出这些“对象”(这里的对象并非指类的实现,而是指一种分析类)之后,便可以建立完整的“领域模型”了。
2、建立领域模型1)“领域模型”的概念要了解领域模型,就要先了解何为软件的“本质”:“本质”指得就是要想办法直指想要解决的问题的“核心”。 从软件结构的层面来看,“本质”指的就是你所要解决的问题领域中的重要“概念”在抽象层次的呈现。一般来说,这样的呈现方式的会通过“概念模型”来表示。
2)使用类图表达领域模型在UML中通常建议使用“类图”作为表达领域模型的图形。
3) 信仁医院住出院管理系统案例演示接下来将采用信仁医院住出院管理系统的案例来进行演示,为了分析和设计流程的连贯性,将从业务流程分析的部分开始。
(1)住出院系统业务流程在项目立项之后,需求分析师与医院的领域专家通过面对面的访谈,整理出了医院实际上的住院出院流程,并绘制成活动图。http://yunzhu. (2)住出院系统用例模型需求分析师基于企业的业务流程图,与领域专家通过进一步沟通,进行需求的收集,最终绘制出用例图。当然下图中没有包含用例叙述。http://yunzhu. (3)住出院系统领域模型在得到用例图之后,便进入实现用例的阶段,可以通过上一节所介绍的三种分析类找到问题领域中的重要概念,从而得到领域模型,然后通过类图来表达。 比如针对上一节用例图中的“登记出院记录”用例,通过分析可以得到一个控制对象(登记出院记录BPO)和多个实体对象(病床、病人、医生、护士、病症等),并绘制成如下的类图。http://yunzhu. 4)包图通常领域模型中会包含很多的类,必须对这些类进行分类,放置在不同的命名空间中,利用命名空间之间的关系图,来限制住不同分类对象之间的访问,这就是“包图”的使用场景。 “包图”是一个高阶的视图,由于所有的类都必须属于某一个包,因此当包之间的关系被限定时,该包内部所有的类,都会受到包图中设置的影响。
★ 住出院系统包图 比如最基本的分类就是按照上面所说的三种分析类,对上面的领域模型,按照这种方式进行分类,便可以绘制出如下包图:http://yunzhu.
3、表达对象交互一般来说,我们在用例分析中将系统应该满足的用户期望找出来了;而在类图中则将系统的架构构造出来。但是,针对每个特定的用例的场景,要如何利用类图所规范的对象,通过交互协作来完成用例所交付的任务,就必须要用序列图来表达。
1)序列图序列图的主要目的在陈述用例的正常事件流中,对象彼此之间的交互关系。也就是说,序列图的主要来源是用例的叙述。
序列图的主要任务包括:
绘制序列图的两点重要建议:
★ 登记出院记录序列图 针对“登记出院记录”的用例,根据用例叙述,得到以下序列图。http://yunzhu. 验证领域模型正确性 从前面的类图来看,“登记出院记录BPO”是与“住院事件”想关联的,但在序列图中,“登记出院记录BPO”却是和“病床”有消息传递,这似乎并不符合类图所表达的领域模型。我们可以进一步通过另一个表达对象交互协作的通信图来进行验证。
2)通信图通信图与序列图其实都是在表达同一件事情:对象相互合作,以实现用例的“事件流”。
为什么要使用通信图进一步验证呢? 由于序列图是以时间做横轴,因此对未来的程序设计而言,序列图具有“蓝图”的效果,但如果需要同时表达对象的结构与彼此间的协作关系,则只有通信图才能较为完整地进行呈现。 究竟项目设计人员在设计序列图时,心中是否对象模型,因此希望项目设计人员能利用“通信图”来重新审视自己对对象模型的理解,来确认序列图有没有违反领域模型。
★ 登记出院记录通信图http://yunzhu.
3)交互概述图在绘制序列图和通信图等交互图时,需要注意:
那么,这些分散的交互图怎么才能组合在一起呢?这时可以利用交互概述图。 交互概述图主要是利用活动图作为基础,只是在“控制流”间连接的UML元素并非活动,而是交互图(包括:序列图、通信图、时间图以及交互概述图)。
4、表达微观设计
1)对象图对象图旨在描述特定时间点中所有对象在系统中的结构;因此,可以将对象图当成系统在某一个时间点的快照。
★ 住出院系统对象图 针对前面设计的信仁医院住出院系统的领域模型,可以参考日剧《白色巨塔》作为范本,将该剧中最重要的一个“佐佐木先生”住院事件转换为对象图。http://yunzhu. 2)状态机图类图中某一个实体对象,它的状态迁移分散在不同的用例中,需要在这些状态和事件之间进行一番整理,才能让项目开发人员更简便地完成设计,这时可以使用状态机图来表达。
★ 病床状态机图 在信仁医院住出院系统的领域模型中,有一个“病床”实体对象,它的状态迁移分散在不同的用例中,可以使用如下状态机图统一表达这些状态的迁移。http://yunzhu. 3)时间图如果在状态迁移中牵涉到时间因素,则可以利用时间图来强调事件因素的重要性。设计人员可以把时间图当成状态机图的辅助说明工具。
★ 过期取消预定时间图 关于前面病床的撞他,如果病人预定了病床,但是后来一直没有去使用病床,那么这个病床该怎么办呢?总不能直接空着吧?关于这一点,信仁医院的处理是这样的:超过半小时病床状态要自动迁移到Empty。这个设计内容很难在状态机图中表达,这时可以使用时间图。http://yunzhu.
总结和展望到此为止,本文已经讲解了需求分析阶段和系统设计阶段使用的主要UML图形,除了这些图形之外,还有以下UML图形,本文不做详细介绍:
后记 总 算写完了,从拿到这本书开始,看了整整一个月,写这篇博客又花了半个月,从未在一本书上花过这么的时间,但还是觉得很值。一个字一个字的敲出来,一个图一 个图的画出来,虽说耗时甚多,但也使得印象更加深刻了。加上反复琢磨反复钻研,对UML终于有了深刻的认识,对于UML的实际应用,也有了了然于胸的感 觉。同时也殷切地希望这篇文章能够对您有所帮助。真心觉得这本书值得一看。 |
|