设计中体现艺术家的气质，我们程序员就是天生的艺术家。自从买了《阿里巴巴 Java 开发手册》老四就一直爱不释手，最后发现纸质书中多了一个章节，主要讲解软件设计过程中UML(Unified Modeling Language:标准建模语言)设计准则以及基本的架构理念。所以老四开始为这本书挖坑，精心整理，附上些许不成熟的、更多的示例和说明，希望对看到的人有所帮助。如果您发现文中内容有误或者本人只是不够专业，请您不吝啬的指点批评出来，我们共同进步。
1.[强制] 存储方案和底层数据结构的设计获得一致评审通过，并沉淀文档。
说明:有缺陷的底层数据结构容易导致系统风险高、可扩展性差，重构成本因历史数据迁移、系统平滑过渡也会陡然增加。所以，对存储方案和数据结构需要进行认真的设计和评审，生产环境提交执行后，团队成员需要进行double check。
正例:评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型等;数据结构变更(如在原有表中新增字段)也需要进行评审通过后再上线。
老四附言:
没啥好说的，无论的你身处成熟体系的公司还是初创公司，业务、技术文档是开发之前必不可少的，对于系统的评估无论是数据库层面还是项目架构层面都要做充分、尽可能全面的评估并沉淀为文档。这个很重要，否则以后你都不知道你曾经做了什么。
2.[强制] 在需求分析阶段，如果与系统交互的User超过1类，并且相关的User Case超过5个，那么使用用例图来表达结构化需求会更加清晰。
用例图:用例图，展现了一组用例(User Case)、参与者（actor）以及它们之间的关系。从用户角度描述系统的静态使用情况，从而建立需求模型。
老四附言:
用例图的要素:
- 参与者:与当前系统交互的角色
- 用例:椭圆表示，代表系统提供的服务或者功能单元
- 子系统:将前两者结合起来形成一个功能服务体系。
- 关系:包括关联、泛化、包含、扩展，可以理解为参与者与用力之间联系的四种关系
用例图示例:
3.[强制] 如果某个业务对象的状态超过3个，那么应使用状态图来表达并且明确状态变化的各个触发条件。
说明:状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触状态转换的条件是什么。
正例:淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货两种状态之间是不可能有直接转换关系的。
老四附言:
状态图:描述一个对象所处的可能状态以及状态之间的转移。用状态图建模可以帮助开发人员分析复杂对象的各种状态的转换，以及对象何时执行怎样的动作。
状态图的符号:
- 状态-重要
- 转移-重要
- 初始状态
- 最终状态
- 历史状态
- 判定
根据孤尽的描述与扩展，老四做一个状态图的示例如下:
4.[强制] 如果系统中某个功能的调用链路上涉及的对象超过3个，则应使用时序图来表达并且明确各调用环节的输入与输出。
说明:时序图反映了一系列对象间的交互与协作关系，可以清晰立体地反映系统的调用纵深链路。
老四附言:
时序图:描述系统中类和类之间的交互，将这些交互建模成消息交换，每条消息都代表了类的一个操作或者状态机改变的触发事件
组成的元素:
- 对象(Object)
- 生命线(LifeLine)
- 激活(Activate)
- 消息(Message)
- 实例
老四附一张自己画的时序图示例以供参考:
5.[强制] 如果系统中模型类超过5个，并且存在复杂的依赖关系，则应使用类图来表达并且明确类之间的关系。
说明:类图就像建筑领域的施工图，如果搭平房，可能不需要，但如果建造”蚂蚁Z空间”大楼，则肯定需要详细的施工图。
老四附言:
类图:显示了一组类、接口、协作以及他们之间的关系。
类图中常见的几种关系:
- 泛化 – 一种继承关系
- 实现 – 类与接口的关系
- 关联 – 拥有的关系
- 聚合 – 整体与部分的关系，部分可以离开整体而单独存在。
- 组合 – 整体与部分的关系，部分不能离开整体而单独存在。
- 依赖 – 使用的关系，一个类的实现需要借助另一个类来实现
- 泛化=实现>组合>聚合>关联>依赖
老四附类图示例一张:
更博不易，喜欢的老铁有能力烦请赞助盒烟钱，点我去赞助。抱拳。
