中生代技术 + 关注
手机版

建模:设计和UML的那点事

  1. 云栖社区>
  2. 中生代技术>
  3. 博客>
  4. 正文

建模:设计和UML的那点事

jurassic_1 2016-06-08 23:32:05 浏览1884 评论0

摘要: 作为架构师或者产品经理甚至是开发团队的负责人,你不仅需要知道如何正确地“搬砖”,也要知道如何正确地设计模型,如何借助UML等工具画出你的“图纸”。本文就带你走进设计和UML的那点事。

41c82743ad03aa4f4cf975af4cd313ff727456dc

设计的目的是什么?它和UML是怎样的关系?在程序猿(媛)的工作中,设计是如何开展的?
带着这些疑问,请各位在本文中细细品尝,相信大家能够从作者的思想中找到答案。


1.设计的目的d72a70fc291643d18b1e3e8e7db4f327e41f777f

设计的目的在于从现实世界中发现问题,经过抽象转化,变成机器世界理解的需求,最终由软件程序来完成。

而设计的过程,我们期望是可以模型化的(可复用),而描述这个模型的方法,我们称之为建模语言。在百家争鸣的初期,建模语言超过50种。


2.设计与UML的关系

9dbe2786a1f8966c8df8d23197ae199b372df18e

UML:Unified Model Language,统一建模语言。分久必合,建模语言经过多年的发展,逐渐向统一演进,UML逐步成为设计建模的首选方法。

上图是UML常用的几个设计图形,通过这几个图形,我们是如何完成设计建模的工作的?


3.设计建模三部曲

787f2096c9c638b93223a2351e04ec9aa27ad4e0

经典的设计建模过程是4+1模型,感兴趣的大家可以在网上查阅一下。本文中根据作者自身的设计经历,将设计建模过程稍作修改,变成上述三个过程:业务建模、领域建模、行为建模。


4.业务建模

业务建模一般指的是描述需求的模型,为了描述需求,我们需要重点把握两条主线:价值动机和价值假设。福特汽车创始人亨利福特说过一句经典名言“如果问用户要什么?那用户希望是更快的马车,而不是汽车”这句话说明了两个内容,需求是需要挖掘,而不是用户告诉你(这里需要挖掘需求的价值动机是更快的速度),另一方面则是在产品未开发之前,你需要领域专家来假设产品是能够满足需求的(这里的价值假设是汽车比马车更快),根据这两条主线,我们如何开展业务建模?

用例图是描述需求最常用的方法,此处忽略系统边界要素(作者认为这个不是很难)。

7ceb79dae5a48796badeb8f79b0c45e165da101c

使用用例图描述需求首先需要识别产品的用户角色,然后根据用户角色来挖掘其价值动机,并赋予实际场景(功能)来假设满足角色的需求。同时还需要识别假设的场景(功能)对外部的依赖性,决策其是否可行(依赖因素越多,其代价越大,可行性越低)。

分享:京东需求模型是由市场评估需求的价值,由研发评估需求实现的成本,最终根据性价比来决定需求的优先级。

上述描述的业务建模中,经常会犯以下几个错误

1)描述功能,而不是描述价值。价值是能被直接理解的,而功能还需要进一步启发。例如一个查询告警的功能,对研发人员,它的价值是定位问题,对统计人员,它的价值是统计故障率。因此用例图中尽量描述价值。

2)过早细化需求。业务建模除了用例图,一般还可以辅助序列图、活动图来描述需求,然而这需要根据业务情况来分析,我们只需抓住一点:是否有利于识别价值?对于ERP系统来说,业务流程的每个节点都有重要的用户角色参与,则其辅助序列图描述对价值识别是非常有用的。对于一些整机产品来说,用户角色一般不知道产品内部的构造,因此细化需求大可不必。

3)用例图流程化。例如一个异常场景,会读取告警,再读取日志,那么则可以用一条语句描述清楚,或者辅助序列图、活动图来描述。不建议分出多个子用例来描述这个过程(它会对价值识别产生干扰,特别是用例比较多的时候)


5.业务模型转变开发模型

1a6cf6ce4d0bdab5b7a1979fa229ad5bc8627a97


6.领域建模

cd0c84ef2427e71b0cdf34d564b5b78e819e03f5

上图描述领域建模过程主要从领域知识源(实际的对象),经过领域分析,最后转换成系统、包、类等分析模型(领域对象)。

本处作者的建议是多开阔眼界,学习已有的领域模型(例如分层架构、设计模式,帮后面的培训做个广告^_^),并思考这些领域模型是否可以解决我们的问题。

当前的领域模型经过多年的发展,工作中大部分的问题都能寻找到好的模型解决。因此作者更鼓励“微创新”,例如设计模式应用到解决问题中,这是“微创新”;多种设计模式组合应用,这是“微创新”;将已有的领域模型结合项目情况形成新的领域模型,这同样是“微创新”(作者曾经有过一个阶段,总想自己创造一个模型,借用一句话,简单的事情,想复杂了,最后觉得自己很低能-_-!)


7.行为建模

行为建模包括序列图、活动图,除此之外,作者还加入了状态图,这主要是因为如果没有交互关系模型的建立,需要直接识别出状态关系,会十分困难,而且容易出错(如果业务建模有流程图,则可以先识别状态关系)。

回到行为建模,在设计层次上一般分为概要和详细设计。但是工作中,往往觉得写两种设计比较冗余,结果会将两个层次的设计混在一起,实际上这是存在风险的,作者对这种文档的评价是基本没人看。

曾经有开发人员对设计人员建议“先别设计与xx系统的交互流程,现在还无法确定xx系统准备怎么做”,结果设计文档把内部的流程设计完了,空留下外部接口未设计。然后。。。就没有然后了,等xx系统的交互流程确定后,原来的流程也需要更改,但基本没人会返工修改,这篇设计文档经过设计、评审、归档等大量人力代价,结果变成一篇废文档。

对于这种现象,作者的建议是先在业务建模时确定好依赖关系,确定要不要做。确定要做以后,则在概要层面使用序列图分析好系统级别的交互关系,经评审确认可行后,最后进行系统内的详细设计。详细设计作者建议使用活动图,其灵活性更大,更易于描述细节。


8.心得

1) 实践出真理,设计能力的提升是基于不断的锻炼。曾经有位设计的同事说过“设计缺少的不是知识,缺少的是锻炼”。在工作中,程序员往往不被要求写设计文档,但这不是借口。作者过往接触到非常多的由SE完成的概要设计文档,但是作为特性的owner,作者有强烈的想法,想用自己的语言将其描述出来,因此形成了对应的详细设计文档。而这个过程就是不断的重复前面的过程,让自己的设计能力得到不断的锻炼提升。


2) 那些年我们追过的优秀设计,扩展眼界,站在巨人的肩膀才能看的更远。简单的看书是枯燥的,学以致用才能培养兴趣。(用不到怎么办?自己想办法创造,例如多和同学们沟通,到技术论坛上发帖,更多碰撞让眼界更开阔)


3) 时不时重温一下自己写过的设计,优化归纳,扎实的向上走。(这点真的很难,但是看到自己写的设计文档变成废物会让作者更加难受,正是这点强迫作者不断的更新维护自己写过的设计,而这个过程也是在不断的为自己创造锻炼的机会)


                                                    中生代技术分享群微信公众号

                                                da9312524921e637b684eed7bf3249db58f7badc

本文作者 鼎桥通信  符章文


【云栖快讯】一站式开发者服务,海量学习资源免费学  详情请点击

网友评论