luqingfei@C++

 
随后，项目正式进入PIM阶段，也是正式进入分析阶段，系统分析员将针对首期的系统用例详述细节规格，作为正式需求文件的一部分，也作为业务人员与开发人员之间的沟通文件。

PIM-1~PIM-4的UML产生结果，将作为需求文件中的一部分，而其余非UML产生的结果，系统分析员视项目规定或以往经验自行产生。

在PIM阶段中，系统分析员负责生成PIM-1~PIM-4，至于其余的PIM或PSM，则由其他开发人员负责生成。

PIM-1~PIM-4的产生结果如下：

PIM-1：分析系统流程（系统用例叙述）

PIM-2：分析业务规则（状态图）

PIM-3：定义静态结构（类图）

PIM-4：定义操作及方法（序列图）

在进入PIM阶段之后，系统分析员将所有系统用例依相关性分成若干组，以组别方式生成该组系统用例涉及的PIM-1~PIM-4产生的结果，随后交给后续的开发人员进行设计，编码及测试。然后逐步生成一组一组的PIM-1~PIM-4产生结果，跟CIM的生成方式不同。

系统分析员逐步生成PIM的可能情况：

第一阶段，进行CIM-1，生成业务用例

第二阶段，进行CIM-2，生成活动图

第三阶段，进行CIM-3，生成系统用例

第四阶段，决策人员从CIM-3挑选出一些系统用例，作为首期系统范围。接着，系统分析员将挑选出来的系统用例，以其领域知识的相关性分组。

第五阶段，生成第一组系统用例相关的PIM-1~PIM-4分析文件，并交由后续的开发人员进行设计、编码及测试。

第六阶段：依次生成其它组的系统用例相关的PIM-1~PIM-4分析文件，并交由后续的开发人员进行设计、编码及测试。

PIM-1：系统用例叙述

针对每一个系统用例，系统分析员分析其内部细节，并编写成系统用例叙述（UC Description）。

一份用例叙述格式里头包含多项字段，系统分析员可以从中挑选适用的字段组成自己的用例叙述格式。

1、 用例基本数据

     ●用例名称

     ●用例编号

     ●用例简述

     ●用例图

     ●系统

     ●执行者

     ●相关用例

2、 执行流程

     ●主要流程（Basic Flow）

     ● 替代流程（Alternate Flows）

     ● 例外流程（Exception Flows）

3、 条件及规则

     ●启动事件或条件（Triggers）

     ●前置条件（Preconditions）

     ●后置条件（Post conditions on Success）

     ●失败时状态（Status on Failure）

     ●业务规则（Business Rule）

4、 相关文档

     ● 用例叙述的历史版本

     ●UML图

     ●参考画面

     ●其他非UML文档

5、 其他事项

     ●优先性（Priority）

     ●迭代等级（Iteration）

     ●待解决问题（Issues）

     ● 基本假设（Assumptions）

     ●相关人员

     ●特殊需求（Special Requirements）

相关用例：常见的相关性有两方面，其一是执行用例前必须先行执行过某相关用例，其二是执行用例期间可能驱动其他的包含用例（Inclusion Use Case），或是因条件符合驱动其他的扩展用例（Extension Use Case）。

就系统内部而言，各用例在其幕后都是共享同一群对象。也就是说，UC之间自然就具有“共享对象”之关系。但是，由于用例图只呈现系统外观，所以在用例图里看不到这种关系。在外观方面，UC之间有两种关系，分别是“包含”（Include）和“扩展”（Extend）关系。

两个用例之间可以有“包含”关系，用以表示某一个用例的对话流程中，包含着另一个用例的对话流程。一旦出现数个用例都有部分相同的对话流程时，将相同的流程记录在另一个用户中；前者称为“基用例”（Base UC），后者称为“包含用例”（Inclusion UC）。

如此一来，这些基用例就可以共享包含用例了。

简言之，包含关系是来自于抽象（Abstraction），即从数个不同的用例之中，抽离出共同的部分，而成为可以重用的用例。

两个用例之间还可以有“扩展”关系，用以表示某一个用例的对话流程，可能会依条件临时插入另一个用例的对话流程中。前者称为“扩展用例”（Extension UC），后者称为“基用例”（Base UC）。

简言之，扩展关系来自于用例内执行活动的过程分为主要过程（Main Course）及可选择性过程（Alternative Course）。

执行流程

主要流程：这是用例叙述最核心的部分，其记载了整个用例正常的执行过程。

替代流程：一个用例叙述里面，通常会包含一段主要流程，同时可以包含数段替代流程。

例外流程：用例执行失败的情况。

用例成功执行的过程中，正常流程就是主要流程，期间出现的小插曲就是替代流程。但是，例外流程处理的是，用例执行失败的情况。

条件及规则

启动事件或条件：记录启动用例的重要事件或条件。

前置条件：这是执行用例之前的检验，唯有在满足某些重要条件时，才会执行该用例，以确保用例可以正确执行。

后置条件：相对于前置条件，后置条件代表用例执行完毕时，可以通过后置条件自行检验是否执行成功。

失败时状态：记录用例执行失败时的状态。

业务规则：重要的业务规则或计算公式都要记录下来。

业务人员在执行业务流程时，会使用到许多重要的业务规则或计算公式，这些也都是系统必须遵守的条件及规则，所以必须记录下来。

相关文档

由于用例驱动（Use Case Driven）是当今软件开发的基础模型，所以用例叙述常作为系统开发文件的汇集点，同它链接到相关的文档。

用例叙述的历史版本：用例改版时，用例叙述也跟着同步改版。用例叙述是参与人员的智慧成果，也是业务组织的重要资产。所以如果有需要保留用例叙述的历史版本时，可以在现行版本里多加一个字段，以链接旧有的历史版本及改版说明。

UML图：跟该用例相关的业务用例图、活动图、系统用例图、状态图、类图或序列图，等等。

参考画面：有时候附上画面设计的图片，让阅读者可以对该用例有更具体的想象。

其他非UML文档：例如会议记录、表设计等。

其他事项

优先性：替用例标示其重要度或优先性，可以协助订定开发用例的顺序，越重要的越优先开发。

迭代等级：替用例标示其细致度或迭代等级，方便开发人员经过多次迭代的过程逐步定义出用例的细节。

待解决问题：在用例分析与开发期间，可能会出现还没有定论的问题，这时候通过用例叙述把问题记录起来，方便指派负责人员以及日后查阅。

基本假设：如果该用例是基于某个基本假设而设计出来的，记下这个重要的基本假设。

相关人员：每一份用例叙述都涉及几种不同身份的相关人员，包括制作者、阅读者和审核者，等等。

特殊需求：跟该用例相关的非功能性需求等特殊需求，都可以记录在这个字段中。