对于大部分程序员来说，基本都是拿到需求，在自己脑子里构思好，然后就撸起袖子上手。然后在做的过程中，会遇到各种一开始没有发现的问题。也有可能代码写到一半的时候，发现之前的思路有无法解决的问题，只能换个方案。这时候有两种选择：延迟需求或者自己加班。对于程序员来说，前期的系统设计分析越好，编码中遇到的问题就越少。加班的机会也会大大减少。相比之下，过程是可控的。但是，就设计而言，程序员基本上停留在脑袋的层面上。更多的，一般是通过流程图，对整个代码逻辑进行一个设计分析。最近对自己之前写的模块进行回归分析，换个角度审视自己之前的代码。作为旁观者，分析之前的代码，整理系统设计分析相关的文档，给团队以后参考。通过分析系统，绘制相关图表，我发现了系统设计分析文档的重要性。如果当时有系统设计文档，就可以提前发现我在编码过程中遇到的问题。系统设计分析分为以下几个方面：1.识别相关系统。确定当前需求涉及哪些系统2.识别不同的对象角色。不同的对象角色有不同的操作内容3.分析业务状态变化。分析复杂业务状态的变化4.分析业务流程如果以上几个方面都能搞清楚，那么对于业务需求来说已经很好了。系统设计分析可以使用以下UML图进行分析：1.用例图用例图主要用来描述角色以及角色与用例之间的连接关系。描述谁将使用该系统以及他们可以用它做什么。使用用例图，可以梳理出当前的需求场景是什么？正在使用哪些角色？每个角色将使用什么功能？2.时序图时序图通过描述动态协作对象之间发送消息的时间顺序来表示多个对象之间的时间顺序。它可以表示用例的行为序列。当一个用例行为被执行时，每条消息对应一个类操作或一个触发事件，引起状态机的转换。时序图可以梳理出需求需要关联哪些系统和模块，需要在哪个操作节点上操作哪些系统和模块。3.状态图描述实体基于事件响应的动态行为，展示实体如何根据当前状态响应不同的事件。通常我们创建UML状态图用于以下研究目的：研究类、角色、子系统或组件的复杂行为。状态图可以分析每个状态的流程，确定哪些状态可以直接相互改变。比如一个商品订单，有下单、付款、发货、确认收货、申请退款、退款中、退款完成。4.活动图活动图说明了业务用例实现的工作流程。业务工作流描述了企业必须做什么才能为其服务的业务参与者提供所需的价值。类似于流程图。可用于分析业务流程。在画图的过程中，不必拘泥于UML的规则，只要图的意思正确即可。上图作为一种工具，可以更直观的展示业务系统，帮助程序员分析当前需求中业务系统之间的关系、业务流转的时机、状态变化、业务运行流程等。有了上面的分析，就相当于提前预演了编码过程，可以在很大程度上找出编码中可能遇到的问题。画图是整理需求，形成简单文档的过程；梳理核心流程、异常流程和状态，方便与其他团队成员沟通，快速上手业务逻辑。
