设计和UML的那点事
Posted 中生代技术
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了设计和UML的那点事相关的知识，希望对你有一定的参考价值。
设计的目的是什么？
它和UML是怎样的关系？
程序猿（媛）的工作中，设计是如何开展的？
这些疑问，各位看官在本文中细细品尝，相信大家能够从作者的思想中找到答案
1、设计的目的
设计的目的在于从现实世界中发现问题，经过抽象转化，变成机器世界理解的需求，最终由软件程序来完成。
而设计的过程，我们期望是可以模型化的（可复用），而描述这个模型的方法，我们称之为建模语言。在百家争鸣的初期，建模语言超过50种。
2、设计和UML的关系
UML：Unified Model Language，统一建模语言。分久必合，建模语言经过多年的发展，逐渐向统一演进，UML逐步成为设计建模的首选方法。
上图是UML常用的几个设计图形，通过这几个图形，我们是如何完成设计建模的工作的？
3、设计建模三部曲
经典的设计建模过程是4+1模型，感兴趣的大家可以在网上查阅一下。本文中根据作者自身的设计经历，将设计建模过程稍作修改，变成上述三个过程：业务建模、领域建模、行为建模。
4、业务建模
业务建模一般指的是描述需求的模型，为了描述需求，我们需要重点把握两条主线：价值动机和价值假设。福特汽车创始人亨利福特说过一句经典名言“如果问用户要什么？那用户希望是更快的马车，而不是汽车”这句话说明了两个内容，需求是需要挖掘，而不是用户告诉你（这里需要挖掘需求的价值动机是更快的速度），另一方面则是在产品未开发之前，你需要领域专家来假设产品是能够满足需求的（这里的价值假设是汽车比马车更快），根据这两条主线，我们如何开展业务建模？
用例图是描述需求最常用的方法，此处忽略系统边界要素（作者认为这个不是很难）。
使用用例图描述需求首先需要识别产品的用户角色，然后根据用户角色来挖掘其价值动机，并赋予实际场景（功能）来假设满足角色的需求。同时还需要识别假设的场景（功能）对外部的依赖性，决策其是否可行（依赖因素越多，其代价越大，可行性越低）。
分享：京东需求模型是由市场评估需求的价值，由研发评估需求实现的成本，最终根据性价比来决定需求的优先级。
上述描述的业务建模中，经常会犯以下几个错误
1)描述功能，而不是描述价值。价值是能被直接理解的，而功能还需要进一步启发。例如一个查询告警的功能，对研发人员，它的价值是定位问题，对统计人员，它的价值是统计故障率。因此用例图中尽量描述价值。
2)过早细化需求。业务建模除了用例图，一般还可以辅助序列图、活动图来描述需求，然而这需要根据业务情况来分析，我们只需抓住一点：是否有利于识别价值？对于ERP系统来说，业务流程的每个节点都有重要的用户角色参与，则其辅助序列图描述对价值识别是非常有用的。对于一些整机产品来说，用户角色一般不知道产品内部的构造，因此细化需求大可不必。
3)用例图流程化。例如一个异常场景，会读取告警，再读取日志，那么则可以用一条语句描述清楚，或者辅助序列图、活动图来描述。不建议分出多个子用例来描述这个过程（它会对价值识别产生干扰，特别是用例比较多的时候）
5、业务模型转变开发模型
上图描述的是两种转换方法，简单的说，我们希望是先识别领域模型，然后根据领域模型分析其行为过程，最终再反馈到领域模型中（类图）。
6、领域建模
上图描述领域建模过程主要从领域知识源（实际的对象），经过领域分析，最后转换成系统、包、类等分析模型（领域对象）。
本处作者的建议是多开阔眼界，学习已有的领域模型（例如分层架构、设计模式，帮后面的培训做个广告^_^），并思考这些领域模型是否可以解决我们的问题。
当前的领域模型经过多年的发展，工作中大部分的问题都能寻找到好的模型解决。因此作者更鼓励“微创新”，例如设计模式应用到解决问题中，这是“微创新”；多种设计模式组合应用，这是“微创新”；将已有的领域模型结合项目情况形成新的领域模型，这同样是“微创新”（作者曾经有过一个阶段，总想自己创造一个模型，借用一句话，简单的事情，想复杂了，最后觉得自己很低能-_-!）
7、行为建模
行为建模包括序列图、活动图，除此之外，作者还加入了状态图，这主要是因为如果没有交互关系模型的建立，需要直接识别出状态关系，会十分困难，而且容易出错（如果业务建模有流程图，则可以先识别状态关系）。
回到行为建模，在设计层次上一般分为概要和详细设计。但是工作中，往往觉得写两种设计比较冗余，结果会将两个层次的设计混在一起，实际上这是存在风险的，作者对这种文档的评价是基本没人看。
曾经有开发人员对设计人员建议“先别设计与xx系统的交互流程，现在还无法确定xx系统准备怎么做”，结果设计文档把内部的流程设计完了，空留下外部接口未设计。然后。。。就没有然后了，等xx系统的交互流程确定后，原来的流程也需要更改，但基本没人会返工修改，这篇设计文档经过设计、评审、归档等大量人力代价，结果变成一篇废文档。
对于这种现象，作者的建议是先在业务建模时确定好依赖关系，确定要不要做。确定要做以后，则在概要层面使用序列图分析好系统级别的交互关系，经评审确认可行后，最后进行系统内的详细设计。详细设计作者建议使用活动图，其灵活性更大，更易于描述细节。
8、心得
1) 实践出真理，设计能力的提升是基于不断的锻炼。曾经有位设计的同事说过“设计缺少的不是知识，缺少的是锻炼”。在工作中，程序员往往不被要求写设计文档，但这不是借口。作者过往接触到非常多的由SE完成的概要设计文档，但是作为特性的owner，作者有强烈的想法，想用自己的语言将其描述出来，因此形成了对应的详细设计文档。而这个过程就是不断的重复前面的过程，让自己的设计能力得到不断的锻炼提升。
2) 那些年我们追过的优秀设计，扩展眼界，站在巨人的肩膀才能看的更远。简单的看书是枯燥的，学以致用才能培养兴趣。（用不到怎么办？自己想办法创造，例如多和同学们沟通，到技术论坛上发帖，更多碰撞让眼界更开阔）
3) 时不时重温一下自己写过的设计，优化归纳，扎实的向上走。（这点真的很难，但是看到自己写的设计文档变成废物会让作者更加难受，正是这点强迫作者不断的更新维护自己写过的设计，而这个过程也是在不断的为自己创造锻炼的机会）
关于中生代技术
友直、友谅、友多闻；群好、群真、群多妹子。架构、开发、运维、DBA、前端一网打尽，做中国最好的中生代！
我们不叫架构师群的原因是现在架构师群已经不少了，我们不仅仅讨论高大上的概念，我们还会讨论类似于[开发应该懂多少运维，开发应该掌握DBA基础7日谭等基础性话题]，特别高大的群，有些问题憋着不敢问，怕被认为是low到爆呢，我们这里有专家、也有对于新领域而言的菜鸟，让我们重温老夫子的训诫[三人行，必有我师焉]，更多精彩请持续关注freshmanTechnology微信订阅号！
连接技术大咖的桥梁
促进科技技术的交流
长按右边二维码
关注中生代技术
以上是关于设计和UML的那点事的主要内容，如果未能解决你的问题，请参考以下文章