一、业务分析与需求收集

　　1、重点梳理主业务流程，逐步完善分支流程。整理和发现业务流程中的涉众以及他们的业务目标和系统目标，显式目标以及隐式目标；

　　2、整理涉众们在系统中所承担的角色以及各自的职责；

　　3、在流程的运转过程中，发现和查找业务实体、他们之间的关系以及关键实体的生命周期（由谁在什么场景下创建、中间状态的变化以致后的消亡）；

　　4、在流程的运转过程中，有哪些业务规则以及各种隐式的规则；

　　5、不断的提问和验证流程的正确性和完整性（即使是边界以外的流程也不要放过，少要做到心中有数）。是否有遗漏的涉众？是否有遗漏的职责或者行为？是否有遗漏的实体？是否有遗漏或者未被发现的实体关系？实体的生命周期是否完整？收集的需求或者信息能否支撑整个流程的运转，需求与需求是否有相互矛盾之处？是否有履行同样职责的人或者物（需要合并或者抽象）？多退少补！

　　6、划分业务边界与系统边界，哪些是需要由系统来完成的职责，哪些是由别的系统或者人工完成的职责。

　　7、可借助UML的组件图或者时序图、活动图、状态图来完成High Level层面的流程整理和业务建模。

　　二、概要设计（用例驱动功能需求，认真对待非功能性需求）

　　1、整理系统用例以及他们的参与者与系统边界。系统用例与服务为密切，通常会演变为后的服务接口。可借助UML用例图来完成用例建模。

　　用例的特征：

　　用例具有相对独立性；用例的执行结果对于参与者来说是可观测的和有意义的；用例必须由一个参与者发起的；用例必然是以动宾短语的形式出现的；用例是一个需求单元、分析单元、设计单元、开发单元、测试单元甚至是一个部署单元。

　　用例的粒度：

　　在概念建模阶段：粒度以能描述一个完整的事件流为宜；

　　在系统建模阶段：粒度以能描述操作者与计算机的一次完整交互为宜；

　　用例不是功能，用例是参与者对系统的期望以及目标，功能则是达成这个目标的步骤而已。

　　2、用活动图或者时序图描绘重点用例及其场景。

　　设计目标：为了完成该用例，需要由哪些角色介入协作完成，他们各自的职责是什么？只关注做什么，当前阶段不需要关注怎么做（不同阶段不同视图所关注的问题是不一样的。不分阶段不分视图的天马行空式的混沌思维，不是科学的分析方法，只会把问题复杂化）。

　　3、完成当前用例有哪些规则，以及需要建立哪些实体，之后需要明确实体与实体之间的关系（关联？聚合？一对一？一对多？）。

　　4、只需要针对核心和关键的用例建模，循环迭代。

　　5、划分高层职责、确立彼此之间的交互方式及其主要交互数据。

　　三、详细设计（在概要设计的基础上演进与精化，只需要针对核心和关键的用例建模）

　　1、根据之前的用例设计，定义服务接口并确定接口参数与返回值。

　　2、根据概要设计过程中的活动图和时序图，将完成相应职责的角色或者对象设计为相应职责的类或者接口，并将关键步骤定义为该类或接口的方法，并确定方法参数与返回值，可借助UML类图来完成接口、类的建模。

　　3、分析模型的变化点，对于清晰明确的变化点，建立抽象模型以适应变化并设计已知实现。对于相对模糊不清的变化点，建立抽象模型，隔离变化，将问题集中到一个局部的点，可在之后变化点明朗化之后重构（只影响某个局部的点）。概要设计阶段我们思考“做什么？”，当前阶段我们需要思考“怎么做？”，或者是技术选型，或者是架构模式，需要做出决策。

　　4、认真思考类或者接口中的每一个属性、方法以及方法参数。精炼、精炼、再精炼！

　　取一个好名字；

　　方法的设计应当具备原子性与职责单一性，方法参数列表也应当尽量精炼，越是简单的方法越容易被组合与重用。

　　只暴露需要暴露的服务与接口方法，不多暴露一个不需要暴露的服务与接口方法。没暴露的方法可以随意重构与扩展，方法一旦暴露出去，需要一直维护并保持其兼容性。

　　5、不要考虑实体的储存形式，我们需要思考的是设计一个类，该类当中应该有哪些属性与方法，以及每个属性的适用场景与业务含义。

　　任何形式的数据都应该能转换为OO设计中的类对象。可存储可配置的场景也应该可以通过API来实现，JAVA是程序语言，任何形式的数据表现形式，后还是通过相应的类及其方法调用来完成相应的职责。

　　6、只需要针对核心和关键的用例建模，循环迭代。

　　7、划分高层职责、确立彼此之间的交互方式，建立高层接口以及通讯方式，确定通讯协议以及报文格式。

　　注意：

　　A、实体建模时，需要认真思考实体的每一个属性，明确其使用场景与业务含义。同一个人在不同的场景下可能扮演不同的角色，角色的不同决定了其属性也不同。Jack在家是父亲的角色，他同时也是一个教师，因此“课程”是教师的属性而不是父亲的属性，即使他们都属于Jack这个维度。请参考DCI的设计理论。

　　B、实体建模时，即使需求方没有提出有关需求，但仍需要维护某些关系。实体与实体关系是在某个业务场景下客观存在的，如果因为需求方暂时没有提出相关需求，而放弃或者丢失客观存在的实体关系，一旦今后提出相关需求，可能会带来相当大的重构代价。