软件|软件分析与设计：分析什么？如何设计？( 二 ) 软件

拉曼《UML和模式应用》一书中，对分析与设计概括成：分析是做正确的事；设计是正确地做事，之前看到这2句话挺迷糊，并没有领会到这两句的精髓，后面经历了一些系统的设计之后，重新去看发现这2句话高度概括出了分析与设计的本质内涵。

二到底要分析什么 1 分析全景图
分析的起点是问题本身，比如现象、痛点、挑战、价值等，从这些基础点去分析，如分析一个业务时，我喜欢从业务愿景和业务目标去看这个业务有哪些利益相关者，也即有哪些角色在使用这个业务，从这些利益相关者的角度去思考他们的本质诉求，正是他们的诉求构成了我们要做什么的输入，不管外部怎么变化，他们的本质诉求是不变的，如对于消费者来讲，他们的诉求是花最短的时间、最少的钱、更好的体验买到心仪的商品；对于商家来讲，他们的诉求是怎么卖出更多的货、怎样获得更大的利润。反而如果我们不去关注利益关注点的本质诉求，而只是自己凭空想出来的，自以为有价值，结果一落地就出现了问题。
当明确了要做什么(What)之后，接下来就要思考业务流程以及业务中包含的要素(业务对象)、业务模型以及业务能力(How) ，实际上这部分就是提供一个解决方案去实现前面提到的诉求。分析的阶段，一定要非常细，在软件分析中，有一些分析的工具帮助我们更好地理解事物本身，具体地在下一节中讲到。分析的产物是业务模型和业务能力地图，通过业务模型可以看出业务是什么、有什么，通过业务能力地图可以看出具体的业务能力有哪些，可以支撑哪些业务场景。
分析往上看一层，就是要分析商业价值链和商业模式，虽然这一块并不是开发同学负责的范畴，了解一些还比较好，能让我们对业务有更深刻的认识，商业模式决定商业结构，商业结构决定交易结构，交易结构决定业务组成结构。利益相关者也是从业务组成结构中推导出来的，这一部分是最顶层的分析，分析业务的可行性，也即我们常说的Why 。

2 具体分析方法
在实际中，我们会看到各种各样的分析方法，这些方法本身并不重要，重要的是它能给我们带来什么的帮助，为什么需要它，个人的观点是分析方法不要贪多，真正融汇到实际中，有那么1、2个方法就足已，不要迷失在各种各样的分析方法中，真正还是要了解分析的本质是什么，在第一部分中，已经提到分析的本质是要洞察出事物的组成，包含组成结构和运行机制，你再去看各种各样的分析方法，它们都是为了找出事物的组成结构和运行机制。如黄金圈分析方法，它就包含了三层（Why、What、How），分析事物不断从宏观到微观、从目的到实现；再比如5W2H ，真正的把一件事分析得非常仔细，什么人在什么时间什么地点因为什么做了什么事。
再回到软件分析本身，之前在大学里我们我们学习软件工程、UML等课程，由于当时并没有多少实际的研发、设计的经验，学习的时候觉得这些内容比较空洞，反正老师让我们这样做就这样做，缺乏对这些UML图的理解。
用例图：用户对系统最直接的交互，要表达出用户需要怎样的能力去满足他们的诉求，它的关键是用户、目的、价值。活动图：用户在某一类场景中，要表达出业务流程是怎样的，它的关键是业务活动、流程交互（仅是业务层面，不是系统流程）。模型图：屏蔽业务细节，抽象出业务关键要素以及它们之间的联系，它的关键是业务抽象出来的实体以有实体之间的关联。我们现在反过来去想想当时学习的UML课程，里面各种图都是为了帮助我们更好去认识、理解项目需求，画这些图并非是做做样子，而是真正地挖掘出业务能力有哪些、系统能力有哪些、业务模型是怎样的、要有哪些对象、对象之间的关系是怎样的。在实际工作中，有些人在分析阶段在这一块落实得并不那么好，其实问几个问题很容易暴露出来，比如设计的类图的出发点是什么、这个类的职责为什么有这些、这个职责为什么在这个类而不是在另外一个类中。如果我们分析阶段做得不扎实，设计阶段的输入就会比较少，或者是浅层次的输入，设计的质量也不会高，因为并没有真正洞察出问题。