如何设计和建模？
极客时间编辑部
讲述：丁婵大小：6.99M时长：05:05
你好，欢迎收听极客视点。
设计和建模分为几个部分：
业务建模：关注业务，不关注具体的实现；
系统建模：关注所建设系统的边界，找准在业务中的系统的职责和约束；
分析与设计：定位核心领域，找到实际的类，厘清类的职责和类之间的关系，通过设计使得代码抽象复用。
业务建模
总体来说，业务建模主要聚焦于分析涉众利益，厘清业务流程。在工具方面，主要是用例图、流程图；在内容方面，主要是找人（利益涉众，系统执行者）、找业务实体（其余系统，相关的重要对象）。
分析涉众利益
分析涉众利益之前，需要找到涉众，一般要经历以下步骤：
找到软件产品的愿景，愿景表达了软件产品带来的核心意义；
找到利益相关的涉众和其利益诉求；
分析涉众利益需要进行详细的调研，研发人员可以根据产品的调研看到对应的涉众，及其利益。
业务用例图
知道了涉众的利益之后，就要分析业务流程，并对现有的流程进行改进。软件产品没诞生之前，业务是如何被处理的，找到原来业务的处理方式则可以梳理出业务用例。
业务流程分析
了解了涉众的利益并且画出用例之后，需要分析业务流程，找到软件系统能够改进的流程片段。完整的业务流程图可能很庞大，需要关注的是其中最有可能影响涉众利益的流程片段。
业务流程分析是一件很复杂的事情，研发人员可以利用需求中的信息，同时加上自己跟涉众的日常沟通和调研，把握核心的涉众利益、业务用例和业务流程，就可以解决大部分在需求上的理解偏差问题。
系统建模
系统建模关注的是系统与外部的边界和系统自身的职责，需要画出系统用例并写出用例规约。
系统用例图
系统用例图是业务流程中，系统执行者与系统发生的有价值的交互。系统执行者可以是人，可以是外部系统，甚至可以是时间。系统用例要体现系统的价值，系统会做很多事情来实现业务价值。有些是低层次的职责，没有体系具体价值。
系统用例规约
有了业务流程图和系统用例图，需要进一步细化系统边界上的约束，保证系统的稳定性。系统执行者与系统的交互细化了详细的约束，系统的稳定性才能提高，如果没有仔细列出约束，有可能会忽略一些边界条件，导致系统的故障。
类的分析与设计
这可能是大多数研发人员比较熟悉的领域，经典的设计模式、类之间的关系、泛化、组合等。但是类从哪里来呢？是从需求之中凭空产生？又或者突然灵光一闪，有了类的雏形？对类的进行设计与分析之前，需要做的是找到它。
识别类
大众熟知的类有三种，边界类、控制类和实体类。边界类是外部系统在系统内部的映射，借由边界类，系统和外部系统交互。所以一些接口请求，输入输出都属于边界类的职责。控制类往往是体现用例流程，一般而言，一个用例就是一个控制类。实体类则是系统的核心，实体类良好设计能够提高系统的复用程度，减低系统的复杂性。
找实体名词
知道了有这三个类还不足以让你识别具体的类，识别具体的类需要去找业务流程、系统流程、系统规约中经常出现的名词。
找到属性
类的属性也不是凭空产生的，需要对业务实现有价值，找到那些对于系统实现必不可少的属性，放到正确的类中。
找职责
从业务规则和约束中，可以找到一些实体应当有的职责，有些对象看起来信息很富裕，但是却没有什么职责，说明它是一个值对象。
状态机
找到类和对应的职责，对于一些主要的实体类，还需要设计出它的状态机，清晰的状态机能有效地厘清系统内的一些事件和状态，增强系统整体的健壮性。
总结
总而言之，在多人协作的项目中，不断提高项目质量，除了依靠代码之外的工程手段，还要依靠设计建模。从具体实践的角度来看，设计建模在不同的环境中，调整具体的流程和侧重具体的节点，也能够实现快速高效，不会导致繁琐和低效能的现象。希望今天的内容对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
雪花神剑👍归属地：广东
收起评论