一、业务分析与需求收集

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

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

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

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

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

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

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

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

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

　　用例的特征：

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

　　用例的粒度：

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

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

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

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

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

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

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

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

Tags：郑州成人计算机培训学校有哪些,郑州北大青鸟支持你成为专业的软件开发人才,河南郑州北大青鸟翔天信鸽网,南阳北大青鸟电脑学校好不好,河南省郑州哪里的大数据计算机学校好,郑州职业高中有哪些专业