设计学习---《大象》之系统分析

系统分析

1、 系统用例

（1）系统用例是用来定义系统范围、获取功能性需求的。是软件开发的全部范围，是我们得到的最终需求。

（2）系统用例视图

一般的系统用例视图是以业务用例为单位展开的，系统用例视图即是系统的开发范围。

（3）系统用例实现视图

描述系统用例一种或多种实现方式。

（4）系统用例模型

为系统既定功能及系统环境的模型。主要包括：业务用例，概念用例，用例视图，用例规约，补充规约，业务规则，用例实现，用例场景，分析对象。

业务用例à系统用例à用例实现à用例场景à分析对象

2、 获取系统用例

推导系统用例的基本方法是获取业务用例场景图，尤其是活动图。采用活动图绘制业务用例时讲业务主角和业务工人作为泳道，方便观察他们的职责。系统用例可以从这些职责里抽取出来。

从业务用例场景中抽象出备选的系统用例并且被纳入系统的基本方法：

映射，抽象，合并，拆分，演绎

3、 描述系统用例

与业务用例相同，采用的工具仍然是用例场景，用例规约，对象模型，用例实现，用例实现场景。视角和建模的目的已经从原来的描述业务，理解业务变成了理解系统，描述系统。

（1）       从业务需求到系统需求

系统用例的确定是从业务用例场景开始，采用映射，抽象，合并，拆分，演绎等方法，从业务用例场景中找到系统用例，从而确定了系统范围。再针对系统用例进行建模，通过用例场景和用例规约得到系统需求。

（2）       颗粒度问题

在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即描述一项完整的业务流程。

在概念建模阶段，用例的粒度以每个用例能表述一个完整的事件流为宜，完整业务中的一个步骤。

在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。

4、 分析业务规约

业务规约：顾名思义就是业务上的一些规定。分析业务规约时，按照三类进行：

（1）       全局规约：

对系统大部分业务或系统设计都起约束作用的那些规约。分析人是架构师。

（2）       交互规约

活动、状态或对象，他们在活动转移、状态变化或对象交互时会有一些限制性的条件。

交互规约产生于用例场景当中。可以在业务用例场景、业务用例规约、系统用例场景、系统用例规约中找。

（3）  内禀规则

业务对象本身所具备的，不会因为外面的交互而该变化的规约。个人理解就是业务对象的某些特性。

5、 用例实现

用例实现是将系统用例进行实现，目的就是实现系统的需求。

用例场景和用例规约是我们实现用例的基础，采用的工具则是分析模型。

为了用例实现建模，需要以下步骤：

（1）       需要在用例场景当中发现和定义实体对象。

（2）       需要用控制对象来操作和处理实体对象中的数据。

（3）       需要用边界对象来构建接收外部指令界面。

6、 软件架构

对软件结构组成的规则和职责设定。

软件框架是软件架构的一种实现，它通常针对一个软件架构当中某一个特定的问题提供解决方案和辅助工具。

7、 分析模型

（1）       建立分析模型

将分析类和软件架构结合起来，确定这些类在软件架构中是哪一层。

将分析类在各个层次的情况分析清楚后，需要在每一个层次上在软件框架的规范内来实现用例场景。

通过用例确定系统需求。

通过用例实现，得到系统需求的计算机视角理解。

规定软件架构，确定软件层次。

在每一个层次上决定了适用的软件框架。

分析用例实现在每个软件层次上是如何动作的。

根据每个软件层次上所使用的软件框架并使用分析类来实现用例。

综合各个软件层次得到的分析类，形成分析模型。

得到实现了系统需求最基本的类和类方法。

（2）       优化分析模型

应该关注这样几个关键点：

容易变化的需求：使设计模型带有一定的可扩展能力，适应变化。

结构化和耦合度调整：尽量采用树状结构，对象之间的依赖是单向的，不是交叉的。

交互集中点调整：如果一个对象的交互多，它依赖或关联到很多类，这个对象就需要调整。可以采用的方法有：重新规划职责、增加冗余对象、增加中间调合对象等方法。