阿里规范

2. 【强制】在需求分析阶段，如果与系统交互的 User 超过一类并且相关的 User Case 超过 5

个，使用用例图来表达更加清晰的结构化需求。

 

笔记：

参考：http://www.woshipm.com/pd/2602941.html

产品经理必学UML（二）：用例图

3. 【强制】如果某个业务对象的状态超过 3 个，使用状态图来表达并且明确状态变化的各个触

发条件。

说明：状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换

关系，再明确触发状态转换的条件是什么。

正例：淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两

种状态之间是不可能有直接转换关系的。

 

 笔记：

参考：https://www.jianshu.com/p/2d88c7f71fa7

UML状态图(state model)

4. 【强制】如果系统中某个功能的调用链路上的涉及对象超过 3 个，使用时序图来表达并且明

确各调用环节的输入与输出。

说明：时序图反映了一系列对象间的交互与协作关系，清晰立体地反映系统的调用纵深链路。

笔记：

参考：https://www.jianshu.com/p/718382b58c82

【UML】 之时序图

6. 【强制】如果系统中超过 2 个对象之间存在协作关系，并且需要表示复杂的处理流程，使用

活动图来表示。

说明：活动图是流程图的扩展，增加了能够体现协作关系的对象泳道，支持表示并发等。

 

笔记：

参考：https://www.jianshu.com/p/b9fdae942ffe

UML之活动图

 

7. 【推荐】需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。

反例：用户在淘宝付款过程中，银行扣款成功，发送给用户扣款成功短信，但是支付宝入款时由于断网演

练产生异常，淘宝订单页面依然显示未付款，导致用户投诉。

 

==

面向对象编程的六大原则 部分：

参考：https://www.cnblogs.com/silencer/p/10812417.html

 

8. 【推荐】类在设计与实现时要符合单一原则。

说明：单一原则最易理解却是最难实现的一条规则，随着系统演进，很多时候，忘记了类设计的初衷。

 

9. 【推荐】谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现。

说明：不得已使用继承的话，必须符合里氏代换原则，此原则说父类能够出现的地方子类一定能够出现，

比如，“把钱交出来”，钱的子类美元、欧元、人民币等都可以出现。

 

笔记：

参考：https://blog.csdn.net/u012564117/article/details/92684298

UML(3)——聚合与组合

 

10.【推荐】系统设计时，根据依赖倒置原则，尽量依赖抽象类与接口，有利于扩展与维护。

说明：低层次模块依赖于高层次模块的抽象，方便系统间的解耦。

 

11.【推荐】系统设计时，注意对扩展开放，对修改闭合。

说明：极端情况下，交付线上生产环境的代码都是不可修改的，同一业务域内的需求变化，通过模块或类

的扩展来实现。

  

14.【参考】系统设计主要目的是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。

说明：避免为了设计而设计，系统设计文档有助于后期的系统维护，所以设计结果需要进行分

类归档保存。

全链路跟踪的思想  可溯源 易回滚    

软件工程 考虑后期维护

 

15.【参考】设计的本质就是识别和表达系统难点，找到系统的变化点，并隔离变化点。

说明：世间众多设计模式目的是相同的，即隔离系统变化点。

感觉很多人 可以做到第一点 识别和表达系统难点  

第二点 找到系统的变化点，并隔离变化点 设计模式  艺术 灵感  创造力