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

当明确了要做什么(What)之后，接下来就要思考业务流程以及业务中包含的要素(业务对象)、业务模型以及业务能力(How) ，实际上这部分就是提供一个解决方案去实现前面提到的诉求。分析的阶段，一定要非常细，在软件分析中，有一些分析的工具帮助我们更好地理解事物本身，具体地在下一节中讲到。分析的产物是业务模型和业务能力地图，通过业务模型可以看出业务是什么、有什么，通过业务能力地图可以看出具体的业务能力有哪些，可以支撑哪些业务场景。
分析往上看一层，就是要分析商业价值链和商业模式，虽然这一块并不是开发同学负责的范畴，了解一些还比较好，能让我们对业务有更深刻的认识，商业模式决定商业结构，商业结构决定交易结构，交易结构决定业务组成结构。利益相关者也是从业务组成结构中推导出来的，这一部分是最顶层的分析，分析业务的可行性，也即我们常说的Why 。

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

3 1个分析案例
用2.1节中提到的分析方法，我当时分析一个分销业务也是用了上面的方法，从下面这张图中可以看出业务发展思路是怎样，用了几个关键词进行概括：打基础、拓渠道、夯能力、搭体系、数据化。当有了这些认识之后，再去推导技术侧要做哪些就比较容易，以拓展渠道为例，当多个渠道接入进来时就暴露了一些问题，比如答疑成本比较高，因此就有一个重要的方面就是渠道接入保障，怎么减少渠道接入成本、答疑成本就是技术侧要思考的问题。

三到底要怎样设计 【软件|软件分析与设计：分析什么？如何设计？】1 设计全景图
如果说分析阶段是把事物打散，那么设计就是把打散的事物更好地组合起来。设计最为核心的是从分析中提炼出问题，即定义技术问题，这个是非常难的，比如你觉得某个设计不好，但又讲不出来为什么不好，说明对问题的理解程度还不高。常见的技术问题有：性能、扩展性、稳定性、安全、效能、体验、成本、数据一致性等。
当定义好了技术问题，接下来就要调研业界对这个问题有哪些方案，每个方案的优缺点是什么，比如数据一致性，有事务型解决方案，也有补偿型解决方案，结合业务本身去做选择，这个选择就包含了决策，决策就意味着取舍和平衡，并不是随意的决策，而是有决策的依据来支撑，比如经验、原则、数据等。