从学生时代就接触到UML&#Vff0c;几多年的工做中也没少运用&#Vff0c;各类图形的观念、图形的元素和属性&#Vff0c;以及图形的画法都不能说不相熟。但是怎么正在真际中有效地运用UML使之阐扬应有的做用&#Vff0c;怎么捕捉用户心中的需求并转换成明白的UML图形&#Vff0c;怎么把原人心中的设想用意通过UML图形精确地表达出来&#Vff0c;以及各职责人员如何通过UML图形停行有效沟通&#Vff0c;对于那些&#Vff0c;却深感渺茫。
最近有幸获得了一个台湾人赖信仁写的《UML团队开发流程取打点》那原书&#Vff0c;才拜读了前两章&#Vff0c;就曾经爱不释手了&#Vff0c;颇有点惊喜若狂的觉得&#Vff0c;看了半原书之后&#Vff0c;上述的种种纳闷均已雾开云散了。
那原书取我之前看到过的任何一原UML的书籍都差异&#Vff0c;它并无具体引见每种UML图形的各类元素和属性&#Vff0c;而是重点讲演每种UML图形的运用场景&#Vff0c;以及详细名目历程中如何停行阐明和设想&#Vff0c;并运用相应的UML图形正确转达设想用意。也便是说&#Vff0c;它不是讲演UML是什么&#Vff0c;而是联结详细名目真战讲演UML图形应当何时用、以及怎样用。
那原书细读下来&#Vff0c;反复斟酌&#Vff0c;实真支成颇丰&#Vff0c;末于感触UML实正壮大之处&#Vff0c;同时深感有必要将书中的精髓局部整理出来&#Vff0c;既有利于以后随时翻阅规复记忆&#Vff0c;又能抵达光荣分享的宗旨&#Vff0c;故有此文。
提要&#Vff1a;
书中共有三个局部&#Vff0c;第一局部联结一个完好的案例“信仁病院住出院系统”一一解说UML2.0的14个图形&#Vff0c;解说每个图形的最佳运用场景以及如何构思和绘制图形&#Vff1b;第二局部联结另一个完好的案例“电子化采购系统”&#Vff0c;解说以UML驱动的整个从阐明到设想到编码到测试的全历程&#Vff1b;第三局部则是对于如何将UML使用于团队竞争当中。
原文戴录书中次要脉络和精髓局部&#Vff0c;依照原人的想法系统地串接起来&#Vff0c;次要解说如安正在名目历程各阶段给取适宜的UML图形停行阐明和设想&#Vff0c;重点关注以下问题&#Vff1a;
怎么正在真际中有效地运用UML使之阐扬应有的做用
怎么捕捉用户心中的需求并转换成明白的UML图形
怎么把原人心中的设想用意通过UML图形精确地表达出来
怎么通过UML停行名目各阶段的颠簸推进&#Vff08;阐明→设想→编码&#Vff09;
原文将给取两个案例停行真例演示&#Vff1a;
【电子化采购系统】案例布景引见
客户企业是一家大型家电制造商&#Vff0c;次要业务是制造和销售家电产品。客户企业的信息系统蕴含了一个大型ERP。因为想要厂商供给愈加立即倏地的效劳&#Vff0c;客户企业卫托设想一个电子化采购系统。
【信仁病院住出院系统】案例布景引见
信 仁病院是一家区域病院&#Vff0c;共有200张病床&#Vff0c;病院的只能科室蕴含内科、外科以及皮肤科。该病院正在2000年采购了一淘病院内部的病院打点系统&#Vff0c;此中蕴含门诊 系统、挂号系统、支费打点系统、医保陈述系统以及财会系统。以往&#Vff0c;信仁病院正在解决住院出院时都必须运用人工填表的方式&#Vff0c;只要正在医保给付、门诊医嘱以及支费 打点方面&#Vff0c;威力进入病院打点系统停行记录。但为了真现“e化病院名目”&#Vff0c;信仁病院须要从头设想一整淘住院、出院系统。
书原以及原文运用的UML绘制工具是&#Vff1a;Enterprise Architect&#Vff0c;官方网址&#Vff1a;
那个阶段&#Vff0c;也便是相当于传统软件工程中的问题界说和可止性钻研&#Vff0c;那个阶段次要是通过取用户的访谈&#Vff0c;以确认待开发系统“要作什么”&#Vff0c;并停行可止性钻研&#Vff0c;简略来说便是从企业的角度动身钻研那个名目能否能作、能否能盈利&#Vff0c;否则最末名目失败这对企业就会组成丧失了。
名目初步阶段的初期访谈须要抓住以下几多个重点&#Vff1a;
项宗旨领域&#Vff1a;先找出目前已存正在的系统&#Vff0c;理解该系统能否供给了相关的集成接口&#Vff0c;那一点取你所要开发的项宗旨复纯度有相当大的干系。
必要的业务流程&#Vff1a;正在探究业务流程时&#Vff0c;初期应当尽可能只捕捉就“必要的”业务流程&#Vff0c;正在该业务流程中&#Vff0c;尽质防行对细节的钻研。
项宗旨技术限制&#Vff1a;蕴含运用的技术以及其余系统间的交流接口标准。
项宗旨乐成要害因素&#Vff1a;要丰裕理解所长相关方应付整体名目乐成取否最关怀的问题是什么&#Vff0c;并且评价问题和名目成败的风险能否相关。
上述四个重点&#Vff0c;其切真一初步就决议了名目能否会乐成&#Vff0c;假如正在名目初步时就落入了细节性的探讨&#Vff0c;反而容易组成项宗旨失败&#Vff0c;应付开发团队来说不成不慎。
原阶段完毕之后&#Vff0c;假如正式立项&#Vff0c;这么便进入下一个阶段——需求阐明。
二、需求阐明阶段
需求阐明阶段&#Vff0c;次要是跟客户&#Vff08;规模专家&#Vff09;沟通&#Vff0c;停行需求的聚集和阐明&#Vff0c;而后通过范例的文书精确地表达出来&#Vff0c;并造成需求规格注明书之类的文档&#Vff0c;交由设想人员停行后续的系统设想工做。
UML中的用例图正是用于需求聚集和表达的有力工具&#Vff0c;但是如何找出用例并非易事&#Vff0c;那是因为从用户这里聚集来的信息很可能是零散的、没有系统性的&#Vff0c;要间接从中找出准确的用例很是艰难。
因而正在阐明用例之前&#Vff0c;可以先对企业级的业务流程停行布局和设想&#Vff0c;抓住企业的素量工做流&#Vff0c;为后续停行具体的需求聚集和用例阐明作好筹备。
1、业务流程设想
应付企业的运营打点团队来说&#Vff0c;业务流程布局取企业的永续运营之间存正在着密切干系。简略来说&#Vff0c;业务流程便是为了效劳客户而执止的一连串业务内部流动。业务流程阐明的宗旨正在于理解整体流程对企业目的的撑持划分有何奉献&#Vff0c;进而对流程的细节停行布局。
这么如何停行业务流程的设想呢&#Vff1f;Jacbson认为&#Vff0c;操做“用例”的“目的导向”特性&#Vff0c;可以通过一个“企业级的用例”来完善工做流程的布局取设想。不过掂质真际情况&#Vff0c;大局部规模专家对“用例”的承受度较差&#Vff0c;因而可以运用另一个工具来停行企业的建模&#Vff0c;那个工具是由Erickson和Penker所提出的一个流动图的结构型&#Vff0c;称为“Eriksson-Penker业务扩展模型”。
1&#Vff09;业务流程布局——Eriksson-Penker业务扩展模型
Eriksson-Penker业务扩展模型是一种“目的导向”的流程阐明方式&#Vff0c;次要是将取业务流程相关的重要人、事、物以及那个业务流程所要真现的目的作一个链接&#Vff0c;形容了企业中重要的人、事、物取流程的干系&#Vff0c;那个图中但凡不会过多地引见业务流程的内部细节。正在名目初步阶段&#Vff0c;需求阐明人员可以通过“Eriksson-Penker业务扩展模型”找出要开发系统的重要性&#Vff0c;操做“目的导向”方式&#Vff0c;对业务流程停行适当的切割。
对于Eriksson-Penker业务扩展模型&#Vff0c;具体请看Enterprise Architect官方网站的引见&#Vff1a;业务历程建模→「Eriksson-Penker 业务建模 Profile」节
★ Eriksson-Penker业务扩展模型示例
针对一家大型家电制造商要开发的电子化采购系统的业务流程&#Vff1a;
正在取规模专家进一步沟通后&#Vff0c;就可以对“Eriksson-Penker业务扩展模型”中的每一个“办理”绘制一个对应的流动图&#Vff0c;正在绘制流动图时&#Vff0c;应当将重点放正在“流动”自身&#Vff0c;而不须要参预其余因素&#Vff08;文件、数据、表单等&#Vff09;。正在流动图中&#Vff0c;那些因素应当要正在上层的“Eriksson-Penker业务扩展模型”就表达完成。
流动图最符适用来形容企业的素量工做流。正在绘制流动图时千万不要去钻研流动的细节&#Vff0c;流动图所要捕捉的是整体业务流程的“激动慷慨大方向”。有关细节的相关形容应当是正在探讨“用例”时才须要捕捉。
流动图的运用场景&#Vff1a;
名目起始阶段&#Vff0c;需求阐明人员可以运用流动图&#Vff0c;针对取名目相关的企业流动&#Vff0c;取规模专家一起设想流程
名目上线阶段&#Vff0c;可以用操做起始阶段的流动图做为集成测试的重要参考按照
名目维护阶段&#Vff0c;企业打点人员可以通过流动图理解企业现止的流程以及将来可以改进的标的目的
正在设想流动图时须要遵照以下准则&#Vff1a;
流动图的宗旨正在于表达“流程完好性”而非流动细节。
流动图中的元素&#Vff08;次要是流动&#Vff09;没必要思考复用性。
假如正在流动图中绘制了一个“分叉点“&#Vff0c;则一定要有一个”会折点“取之对应。
流动图中尽质不要表达”文件“或”数据“。
对于设想流动图时的两点重要倡议&#Vff1a;
绘制流动图时&#Vff0c;最好和规模专家间接当面沟通&#Vff0c;最幸亏访谈历程中间接绘制流动图&#Vff0c;并依据流动图复述一次正在访谈中所聚集到的相关信息。那样&#Vff0c;流动图所聚集到的信息将愈加贴近真际。
正在绘制流动图时千万不要去钻研流动的细节&#Vff0c;流动图所要捕捉的是整体业务流程的“激动慷慨大方向”。有关细节的相关形容应当是正在探讨“用例”时才须要捕捉。
★ 表达业务流程的流动图示例
针对上面的电子化采购系统业务流程图中的——“请购流程”&#Vff0c;正在取规模专家具体沟通后&#Vff0c;可以绘制出如下请购流程的流动图。
正在完成各次要业务流程的阐明&#Vff0c;绘制出流动图以后&#Vff0c;即可以初步下个分阶段的工做——从业务流程中找出用例&#Vff0c;停行需求聚集&#Vff0c;完成用例模型。
用例是一个系统中所停行的一连串的从事流动&#Vff0c;该流动次要是要能够满足系统外部的执止者应付系统的某种冀望。
每一个信息系统的用例代表着用户应付系统的“某一个完好冀望”。
但凡来说&#Vff0c;用例是“需求聚集及整理”的工具&#Vff0c;通过用例取执止者的干系&#Vff0c;可以让需求阐明人员“聚焦”正在特定的“相关人员”&#Vff08;也便是执止者&#Vff09;取”主题“&#Vff08;也便是用例&#Vff09;中。
2&#Vff09;找出用例的三个轨范
依据前面所绘制的业务流程的流动图&#Vff0c;可以通过以下三个轨范找出用例&#Vff1a;
① 操做取用户的对话找出信息系统的用例
将流动图中的每个“流动”当做“用例”的候选&#Vff0c;接着针对每个”流动“询问用户以下几多个问题&#Vff1a;
正在那个流动中谁是次要参取者&#Vff1f;
那个流动的停行中须要系统供给效劳吗&#Vff1f;
系统须要供给什么效劳&#Vff1f;
系统须要其余信息系统的撑持吗&#Vff1f;
而后对候选用例停行必要的兼并和干系&#Vff08;比如“包孕”&#Vff09;阐明&#Vff0c; 从而得出业务流程相关的用例图。
★ 业务流程相关的用例图示例
针对上面请购流程的流动图停行上述阐明&#Vff0c;可以得出以下用例图&#Vff1a;
编写用例叙述时遵照的准则&#Vff1a;
每个叙述都必须是肯定句
正在叙述中&#Vff0c;切记不要形容过多细节
③ 完成用例的代替流及不测办理叙述代替流自身仅仅只是一般流的“分收”而非“主干”。举例来说&#Vff0c;假如正在一般流2有三个代替流&#Vff0c;则正在代替流的区块中&#Vff0c;就会有2a、2b、2c三个分收&#Vff0c;而正在那三个分收的编写中&#Vff0c;依然必须遵照着每一句都是“肯定句”的准则。假如正在此中又有代替流&#Vff0c;则一样必须要操做分收的方式来编写。那样&#Vff0c;由于每个叙述都是简短的肯定句&#Vff0c;作做而然删多了将来的扩展空间。
共同“迭代删质”的开发方式&#Vff0c;那三个轨范不是一次就全副完成&#Vff0c;而必须要分批完成。
名目初步阶段&#Vff08;但凡是一到两个星期&#Vff09;必须完成第一个轨范&#Vff0c;也便是找出六成用例&#Vff0c;正在那个局部&#Vff0c;切记要糊口生涯将来删多用例的空间。
接着&#Vff0c;针对用例停行开发顺序的权重牌序&#Vff0c;那个牌序次要针对“复纯度”、“取外部系统的干系”以及“重要性”来停行&#Vff0c;权重越高的用例应当要越早开发。
正在每个用例中&#Vff0c;第二个轨范&#Vff08;找出用例一般流叙述&#Vff09;必须是开发的第一个迭代&#Vff0c;正在该开发迭代停行到系统设想以及编码阶段时&#Vff0c;需求阐明师才须要停行第三个轨范的阐明&#Vff0c;也便是聚集更具体的信息以及相关的代替流。
3&#Vff09;对于用例的用例叙述 用例的叙述正常来说至少分红四种&#Vff1a;
用例的简述&#Vff1a;但凡是用一两句话来注明那个用例的宗旨是什么。
用例的一般流&#Vff1a;正在那个流程中&#Vff0c;必须注明执止者取系统交互的历程&#Vff0c;不过正在那个交互历程中&#Vff0c;必须如果整个流程都必须真现&#Vff0c;也便是说那是一个“光荣途径”&#Vff0c;正在那个流程形容中&#Vff0c;所有句子都必须是“肯定句”。
用例的代替流&#Vff1a;正在一般流中&#Vff0c;假如有“代替途径”&#Vff0c;必须要操做此外的代替流来注明&#Vff0c;而不是间接正在一般流中写“if-then-else“。
用例的不测办理&#Vff1a;但凡指系统例外形态的办理&#Vff0c;取代替流差异&#Vff0c;代替流往往是执止者应付流程有差异的批示&#Vff0c;因为将流程导向差异的完毕点&#Vff0c;而不测办理则但凡是系统发作舛错招致的一般流的不测情况。
用例的叙述是很是要害的局部&#Vff0c;必须能够精确地掌握用户的实正冀望是什么&#Vff0c;后续的设想工做都将环绕用例出格是用例叙述来开展。
4&#Vff09;编写用例的测试案例
正常来说&#Vff0c;正在找出用例后就应当编写用例的测试案例&#Vff0c;测试案例的编写次要操做“输入→预期产出“的方式来形容&#Vff0c;每个测试案例都须要筹备对应的测试数据。
三、系统设想阶段
前一阶段的次要产物是用例图&#Vff0c;后续的设想和开发阶段都将以用例驱动&#Vff0c;环绕用例开展&#Vff0c;而系统设想阶段的次要工做&#Vff0c;等于真现用例。
1、真现用例
真现用例的宗旨正在于担保系统的设想可以满足用户的罪能性需求&#Vff0c;正在真现用例的历程中&#Vff0c;应当操做Jacobson所分类的三种阐明类&#Vff1a;&#Vff08;留心&#Vff1a;那里的“对象”并非指类的真例这种对象&#Vff09;
控制对象&#Vff08;Control Object&#Vff09; &#Vff1a;控制对象包拆了一个或多个用例的罪能性需求&#Vff0c;属于罪能性对象&#Vff0c;而且那个罪能取用例有相当密切的干系。
真体对象&#Vff08;Entity Object&#Vff09; &#Vff1a;真体对象打点了信息及其衍生资源的存与&#Vff0c;是属于系统素量面的观念性对象&#Vff0c;那类对象其真不会跟着用例的删长而有所改观。
边界对象&#Vff08;Boundary Object&#Vff09; &#Vff1a;边界对象是属于取外部桥接的对象&#Vff0c;那类对象将取外部间接接轨&#Vff0c;曲承遭到外部的限制。
1&#Vff09;勾勒用例的控制对象
① 针对每个用例供给一个“控制对象”
② 明白那个控制对象的义务&#Vff08;Responsibility&#Vff09;是什么
从“主执止者”正在一般流的叙述中显现的次数来决议系统要供给几多个效劳&#Vff1b;
再从每一个“对话块”中&#Vff0c;“系统”当主语的最后一句话&#Vff0c;找出那个义务的称呼。
③ 明白那个效劳的输入输出
判断那个效劳中&#Vff0c;能否须要“主执止者”供给什么信息&#Vff0c;而“系统”又须要回复主执止者什么信息
④ 进入到效劳内部&#Vff0c;审室效劳的真现方式
正在控制对象的内部&#Vff0c;每一个以“系统”当主语的叙述都可以独立成一个新的罪能函数&#Vff1b;
只是该罪能函数并非是供给给主执止者的&#Vff0c;因而是一个“私有”的函数&#Vff0c;只供给给控制对象运用。
勾勒用例的控制对象示例历程
针对前面用例图中的第一个用例“孕育发作请购需求&#Vff08;RFP&#Vff09;”&#Vff0c;咱们可以供给一个“孕育发作请购需求&#Vff08;RFP&#Vff09;控制对象”。
“孕育发作请购需求&#Vff08;RFP&#Vff09;”的“一般流”叙述&#Vff1a;
(1) ERP系统供给[年度物料采购筹划]给系统。
(2) 系统依据[BR1]孕育发作[厂商询价引荐名单]。
(3) 系统凭据[厂商询价引荐名单]请通知系统将[物料请购需求]传给名单上的厂商。
阐明历程如下&#Vff1a;
从&#Vff08;1&#Vff09;得悉“主执止者”是&#Vff1a;ERP系统&#Vff1b;
“主执止者”总共显现了1次&#Vff0c;也便是所只要一个“对话块”&#Vff0c;所以系统要供给1个效劳&#Vff1b;
“对话块”中“系统”当主语的最后一句&#Vff08;3&#Vff09;&#Vff0c;可得悉系统所需供给的效劳是&#Vff1a;孕育发作厂商询价引荐名单&#Vff1b;
从&#Vff08;1&#Vff09;可知效劳的输入是&#Vff1a;年度物料采购筹划&#Vff1b;
从&#Vff08;3&#Vff09;可知效劳的输出是&#Vff1a;厂商询价引荐名单&#Vff1b;
从&#Vff08;2&#Vff09;可知效劳内部必须完成的第一件事&#Vff1a;依据[BR1]孕育发作[厂商询价引荐名单]&#Vff1b;
从&#Vff08;3&#Vff09;可知效劳内部必须完成的第二件事&#Vff1a;凭据[厂商询价引荐名单]请通知系统将[物料请购需求]传给名单上的厂商&#Vff1b;
所以从上面两步可知控制对象内部须要两个“私有函数”。
★ 控制对象的类图示例
前面会商了如何找出信息系统中所需的控制对象&#Vff0c;但那样依然不够&#Vff0c;因为前面并无完好形容出毕竟后果对象取对象之间是如何通力协做&#Vff0c;来满足用例所形容的用户需求。因而&#Vff0c;必须要运用序列图来注明那个交互历程。
正在绘制序列图时&#Vff0c;可以给取两阶段序列图绘制法&#Vff1a;
① 把信息系统当黑箱&#Vff0c;操做用例叙述找出系统所应卖力的效劳。
那个轨范可以先绘制一个序列图&#Vff0c;而后把用例叙述放正在该序列图的左方&#Vff08;那样便于对照&#Vff09;&#Vff0c;而后参照用例图&#Vff0c;把相对应的用例转换为一个叫作“系统”的对象。
② 把黑箱翻开&#Vff0c;参预找出的阐明对象&#Vff0c;并把系统所需真现的义务分配给适当的对象。
把上个轨范获得的“黑箱”序列图中的“系统”换成真际的控制对象&#Vff0c;并且按照找出的控制对象的义务&#Vff0c;看看能否一致&#Vff0c;那样就完成为了序列图的设想了。
★ 控制对象的“黑箱”序列图示例
针对上面的孕育发作请购需求的控制对象&#Vff0c;依据轨范①&#Vff0c;把信息系统当做一个“黑箱”&#Vff0c;即可获得以下序列图&#Vff1a;
可以通过Peter Coad的“买卖形式”找出用例的真体对象&#Vff0c;那个形式的如果是&#Vff1a;当发现企业所眷注的问题规模存正在必须要记录的某些变乱时&#Vff0c;那代表着那个变乱是一个买卖。而系统设想人员可以从买卖动身&#Vff0c;挨次去找出取那些买卖相关的企业观念&#Vff08;人、地、物&#Vff09;&#Vff0c;如此就可以迅速地得出那个企业的观念模型。
总之&#Vff0c;真体对象次要是依据应付问题规模的了解来找出问题规模中的重要观念&#Vff0c;应付真体对象的阐明&#Vff0c;无论是应付停行“真体干系图的”的数据库设想&#Vff0c;或是操做“对象模型”作的“构造阐明”来说&#Vff0c;都是相当重要的设想本则。
真体对象属于规模模型的重要观念&#Vff0c;将正在下一节“建设规模模型”中重点解说。
4&#Vff09;系统设想阶段的开发流程
① 通过对用例的了解以及对用例叙述的阐明&#Vff0c;找出系统的控制对象及其收配。
② 通过取规模专家的访谈历程&#Vff0c;找出系统的真体对象以及重要相熟。
③ 设想人员操做两阶段绘制的序列图&#Vff0c;验证前述的控制对象及收配的准确性。
前面通过三种阐明类真现用例的方式&#Vff0c;会从用例动身划分找出控制对象、真体对象和边界对象&#Vff0c;正在找出那些“对象”&#Vff08;那里的对象并非指类的真现&#Vff0c;而是指一种阐明类&#Vff09;之后&#Vff0c;即可以建设完好的“规模模型”了。
2、建设规模模型 1&#Vff09;“规模模型”的观念
要理解规模模型&#Vff0c;就要先理解作甚软件的“素量”&#Vff1a;“素量”指得便是要想法子曲指想要处置惩罚惩罚的问题的“焦点”。
从软件构造的层面来看&#Vff0c;“素量”指的便是你所要处置惩罚惩罚的问题规模中的重要“观念”正在笼统层次的涌现。正常来说&#Vff0c;那样的涌现方式的会通过“观念模型”来默示。
“观念模型”便是能够用最简化的方式表达一个完好的“问题规模”的笼统默示法。观念模型的本始界说是表达问题规模中的观念&#Vff0c;因而&#Vff0c;但凡将观念模型称为“规模模型”。
2&#Vff09;运用类图表达规模模型
正在UML中但凡倡议运用“类图”做为表达规模模型的图形。
类图次要表达的是问题规模的“笼统观念”&#Vff0c;正在那个笼统观念中&#Vff0c;除了表达该笼统观念的称呼外&#Vff0c;此外须要表达该笼统观念的“属性”取”止为”。
类图的次要宗旨是正在停行软件开发前&#Vff0c;先对软件所需面对问题规模的素量做一个通盘性的理解&#Vff0c;但类图正在软件设想之初其真不彻底准确&#Vff0c;必须通事后续的检查才华够逐渐趋近于真活着界的规模模型。
3) 信仁病院住出院打点系统案例演示
接下来将给取信仁病院住出院打点系统的案例来停行演示&#Vff0c;为了阐明和设想流程的联接性&#Vff0c;将从业务流程阐明的局部初步。
&#Vff08;1&#Vff09;住出院系统业务流程
正在名目立项之后&#Vff0c;需求阐明师取病院的规模专家通过面劈面的访谈&#Vff0c;整理出了病院真际上的住院出院流程&#Vff0c;并绘制成流动图。
需求阐明师基于企业的业务流程图&#Vff0c;取规模专家通过进一步沟通&#Vff0c;停行需求的聚集&#Vff0c;最末绘制出用例图。虽然下图中没有包孕用例叙述。
正在获得用例图之后&#Vff0c;便进入真现用例的阶段&#Vff0c;可以通过上一节所引见的三种阐明类找到问题规模中的重要观念&#Vff0c;从而获得规模模型&#Vff0c;而后通过类图来表达。
比如针对上一节用例图中的“登记出院记录”用例&#Vff0c;通偏激析可以获得一个控制对象&#Vff08;登记出院记录BPO&#Vff09;和多个真体对象&#Vff08;病床、病人、医生、护士、病症等&#Vff09;&#Vff0c;并绘制成如下的类图。
但凡规模模型中会包孕不少的类&#Vff0c;必须对那些类停行分类&#Vff0c;放置正在差异的定名空间中&#Vff0c;操做定名空间之间的干系图&#Vff0c;来限制住差异分类对象之间的会见&#Vff0c;那便是“包图”的运用场景。
“包图”是一个高阶的室图&#Vff0c;由于所有的类都必须属于某一个包&#Vff0c;因而当包之间的干系被限按时&#Vff0c;该包内部所有的类&#Vff0c;都会遭到包图中设置的映响。
★ 住出院系统包图
比如最根柢的分类便是依照上面所说的三种阐明类&#Vff0c;对上面的规模模型&#Vff0c;依照那种方式停行分类&#Vff0c;即可以绘制出如下包图&#Vff1a;
3、表达对象交互
正常来说&#Vff0c;咱们正在用例阐明中将系统应当满足的用户冀望找出来了&#Vff1b;而正在类图中则将系统的架构结构出来。但是&#Vff0c;针对每个特定的用例的场景&#Vff0c;要如何操做类图所标准的对象&#Vff0c;通过交互协做来完成用例所托付的任务&#Vff0c;就必须要用序列图来表达。
1&#Vff09;序列图
序列图的次要宗旨正在呈文用例的一般变乱流中&#Vff0c;对象彼此之间的交互干系。也便是说&#Vff0c;序列图的次要起源是用例的叙述。
序列图的次要任务蕴含&#Vff1a;
表达设想人员心中对于未来步调正在运止时的对象协做模型
验证软件规模模型的准确性
为步调员供给编码的蓝图
绘制序列图的两点重要倡议&#Vff1a;
正在绘制序列图时&#Vff0c;要首先突破一个迷思&#Vff1a;序列图其真不须要“务求精密”&#Vff0c;因为它究竟只是一个“蓝图”&#Vff0c;并非是完好的“施工筹划”。
正在设想“序列图”时&#Vff0c;要遵照一个准则&#Vff1a;一个序列图的大小&#Vff0c;最好能够限制正在一张A4纸可以打印的领域内&#Vff0c;最大也不要赶过一张A3纸的打印领域。赶过那个领域的序列图但凡是无效的产出。为了抵达那一点&#Vff0c;最好把一般流取代替流离开来绘制差异的序列图&#Vff0c;每个序列图有原人的重点&#Vff0c;不要把所有的逻辑都表达正在同一个序列图中。
★ 登记出院记录序列图
针对“登记出院记录”的用例&#Vff0c;依据用例叙述&#Vff0c;获得以下序列图。
验证规模模型准确性
畴前面的类图来看&#Vff0c;“登记出院记录BPO”是取“住院变乱”相联系干系的&#Vff0c;但正在序列图中&#Vff0c;“登记出院记录BPO”却是和“病床”有音讯通报&#Vff0c;那仿佛并分比方乎类图所表达的规模模型。咱们可以进一步通过另一个表达对象交互协做的通信图来停行验证。
2&#Vff09;通信图
通信图取序列图其真都是正在表达同一件工作&#Vff1a;对象互相竞争&#Vff0c;以真现用例的“变乱流”。
为什么要运用通信图进一步验证呢&#Vff1f;
由于序列图是以光阳作横轴&#Vff0c;因而对将来的步调设想而言&#Vff0c;序列图具有“蓝图”的成效&#Vff0c;但假如须要同时表达对象的构造取彼此间的协做干系&#Vff0c;则只要通信图威力较为完好地停行涌现。
毕竟后果名目设想人员正在设想序列图时&#Vff0c;心中能否对象模型&#Vff0c;因而欲望名目设想人员能操做“通信图”来从头审室原人对对象模型的了解&#Vff0c;来确认序列图有没有违背规模模型。
★ 登记出院记录通信图
正在绘制序列图和通信图等交互图时&#Vff0c;须要留心&#Vff1a;
不能“务求精密”过于详尽&#Vff0c;因为交互图只须要形容一个“蓝图”而不是完好的“”施工筹划&#Vff1b;
一张交互图不能太大&#Vff0c;最好能正在一张A4纸的可以打印的领域内&#Vff0c;顶多一张A3纸&#Vff0c;否则会成为无效的产出&#Vff1b;
每个交互图应当有表达的重点&#Vff0c;不要正在一个图中表达所有的逻辑&#Vff0c;假如有代替流&#Vff0c;这么就针对一个代替流再绘制一个径自的交互图。
这么&#Vff0c;那些结合的交互图怎样威力组折正在一起呢&#Vff1f;那时可以操做交互概述图。
交互概述图次要是操做流动图做为根原&#Vff0c;只是正在“控制流”间连贯的UML元素并非流动&#Vff0c;而是交互图&#Vff08;蕴含&#Vff1a;序列图、通信图、光阳图以及交互概述图&#Vff09;。
4、表达微不雅观设想
1&#Vff09;对象图
对象图旨正在形容特定光阳点中所有对象正在系统中的构造&#Vff1b;因而&#Vff0c;可以将对象图当成系统正在某一个光阳点的快照。
对象图表达的是正在某一个特定光阳点中&#Vff0c;系统所存正在的所有对象的快照&#Vff0c;其次要宗旨是验证设想师设想的类图能否折乎真际情况。
对象图的运用场景&#Vff1a;
当取规模专家沟通时&#Vff0c;可以用对象图评释类图的设想&#Vff0c;以验证类图的准确性。
当取编码人员沟通时&#Vff0c;可以操做局部的对象图&#Vff0c;来评释类图中的复纯构造。
★ 住出院系统对象图
针对前面设想的信仁病院住出院系统的规模模型&#Vff0c;可以参考日剧《皂涩巨塔》做为范原&#Vff0c;将该剧中最重要的一个“佐佐木先生”住院变乱转换为对象图。
类图中某一个真体对象&#Vff0c;它的形态迁移结合正在差异的用例中&#Vff0c;须要正在那些形态和变乱之间停行一番整理&#Vff0c;威力让名目开发人员更烦琐地完成设想&#Vff0c;那时可以运用形态机图来表达。
为了乐成地设想软件&#Vff0c;将“形态”分配赴任异的“规模模型”中&#Vff0c;并操做“形态机图”来表达那些形态的迁移情形。
★ 病床形态机图
正在信仁病院住出院系统的规模模型中&#Vff0c;有一个“病床”真体对象&#Vff0c;它的形态迁移结合正在差异的用例中&#Vff0c;可以运用如下形态机图统一表达那些形态的迁移。
假如正在形态迁移中扳连到光阳因素&#Vff0c;则可以操唱光阳图来强调变乱因素的重要性。设想人员可以把光阳图当成形态机图的帮助注明工具。
★ 逾期撤消预约光阳图
对于前面病床的形态&#Vff0c;假如病人预约了病床&#Vff0c;但是厥后接续没有去运用病床&#Vff0c;这么那个病床该怎样办呢&#Vff1f;总不能间接空着吧&#Vff1f;对于那一点&#Vff0c;信仁病院的办理是那样的&#Vff1a;赶过半小时病床形态要主动迁移到Empty。那个设想内容很难正在形态机图中表达&#Vff0c;那时可以运用光阳图。
总结和展望
到此为行&#Vff0c;原文曾经解说了需求阐明阶段和系统设想阶段运用的次要UML图形&#Vff0c;除了那些图形之外&#Vff0c;另有以下UML图形&#Vff0c;原文不作具体引见&#Vff1a;
总则图 &#Vff1a;UML2.4标准新删&#Vff0c;次要用于将团队开发中重要的不雅见地或技术运用“结构型”加以整理&#Vff0c;让所有团队成员可以共享那些怪异的知识&#Vff0c;其次要宗旨正在于会萃团队成员的怪异词汇&#Vff0c;以求正在整体上流通流畅地停行沟通。
组折构造图 &#Vff1a;UML2.4标准新删&#Vff0c;次要用于表达要开发系统取外部系统间的干系&#Vff0c;很是符折让架构师正在初期阶段做为评价系统复纯度的工具&#Vff0c;也可做为将来系统维护的参考图形。
组建图 &#Vff1a;从系统真现的角度停行绘制&#Vff0c;次要宗旨是涌现系统正在真现时如何把设想的类分配给差异的物理组件。
陈列图 &#Vff1a;形容物理组件取真体计较机之间的干系&#Vff0c;总体上是布局物理组件的真际位置的一个图。正常来说&#Vff0c;当开发一个大型系统时&#Vff0c;会比较须要组建图和陈列图那两个图。
