企业领域中任何一项必须遵守的条件（Conditions）、约束（Constraints）或政策（Policies）都算是业务规则。

可以将业务规则分为两大类，分别为：约束规则（Constraint Rules）与衍生规则（Derivation Rules）。

约束规则主要用来约束对象结构和行为；衍生规则主要是推论约束和计算公式。细分类如下：

1） 约束规则（Constraint Rules）

a） 刺激/反应规则（Stimulus/ Response Rules）

b） 操作规则（Operation Constraint Rules）

c） 结构规则（Structure Constraint Rules）

2） 衍生规则（Derivation Rules）

a） 推论规则（Inference Rules）

b） 计算规则（Computation Rules）

刺激/反应规则

当（WHEN）某个重要的外界事件发生，而且（and）对象如果（IF）恰好处于某种状态下时，（THEN）对象就会做出某种事先约定好的行为。简言之，WHEN and IF条件成立时，对象就会有THEN的反应。

操作规则

操作规则（Operation Constraint Rules）用来保证操作会正确执行，通常又分为“操作前规则”（Operation Precondition Rules）及“操作后规则”（Operation Postcondition Rules）。

只要（ONLY IF）……且（and）……执行（Execute）

结构规则

结构规则（Structure Constaints Rules）用来约束对象种类或关联关系必须永远遵守规则。在类图里，最容易表达结构规则。

推论规则

推论规则（Inference Rules）指出某事实（Facts）为真（True）时，结论（Conclusion）可被推论得出。

IF …… THEN ……

计算规则

计算规则（Computation Rules）就是一般所谓的计算公式。

业务规则散落四处，系统分析员可以通过不同的的UML图，重新组织且呈现业务规则，如下：

a） PIM-1的系统用例叙述，以系统流程为主，记录约束流程的业务规则。

b） PIM-2的状态图，以对象行为为主，记录刺激对象反应的业务规则。

c） PIM-3的类图，以静态结构为主，记录约束对象种类或关联关系的业务规则。

在进行PIM-1时，系统分析员已经广泛地记下一些重要的业务规则了。接着，系统分析员可以从中找出涉及多项业务规则的业务对象（Business Object），并于此处的PIM-2，再进一步通过状态图，组织且记录更多重要的业务规则。

同时，系统分析员经过了建立状态图的思考过程之后，可以对重要业务对象的状态变化更加清楚。系统分析员可以用一张状态图呈现某一种重要对象一生的行为。从对象诞生到灭亡期间，它会对哪些事件（Event）有所反应，因而转换（Transition）其内在状态（State），和执行某些特定的动作（Action）。

针对对象一生中可能执行的一组动作，系统分析员使用状态来分组这些动作。因此，对象一旦转换进入某一个状态之后，其可执行的动作就会被约束，直到发生了重要事件之后，对象才会转换到另一个状态，同时也执行新状态内部规定好的动作。

 
随后，项目正式进入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文档：例如会议记录、表设计等。

其他事项

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

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

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

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

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

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

MDA（Model-Driven Architecture）与UML（Unified Modeling Language）同为OMG（Object Management Group）机构之标准。
MDA主要将生成的UML模型，分为下列三个阶段：
● CIM（Computation Independent Model）——聚焦于系统环境及需求，但不涉及系统内部的结构与动作细节。

● PIM（Platform Independent Model）——聚焦于系统内部细节，但不涉及实现系统的具体平台（Platform）。

● PSM（Platform Specific Model）——聚焦于系统落实于特定具体平台的细节。例如，Spring、EJB2或.NET都是一种具体平台。

最后，程序员会依据PSM的UML模型内容，按图施工，编写出适用于特定具体平台的代码。

MDA提出的解决方法——将企业及应用系统与实现技术平台分离，且以统一建模语言UML来表达与平台无关的PIM，然后再设计出适用于特定平台的模型PSM。如此一来，因为分隔且封装了企业与技术两方面的变化，所以降低了两者之间的牵动。

MDA主张将设计切分成PIM和PSM。

MDA项目开发的第一步骤从CIM开始，不同于PIM和PSM，CIM试图表达信息系统的应用环境，而非信息系统本身。

在进行CIM时，关切的是与企业相关的营运目标、实现条件及运作流程等，先了解信息系统的应用环境，才有可能为企业量身打造出完善的信息系统。

在经历构建CIM的过程中，除了可以逐步了解企业，同时也建立与业务人员之间的沟通方式及默契，还让业务人员可以参与信息系统的开发。

CIM旨在记录企业领域里的重要需求与概念。

PIM和PSM之间的界限，比较容易混淆，两者所关切的主体都是信息系统，分别的界限在于“平台”（Platform）一词。

简言之，PIM与PSM的界限在于，是否支持特定的具体平台。前者与具体平台无关，后者则得适合某一个特定的具体平台。

分析步骤参考：（CIM、PIM阶段）

CIM-1：定义业务流程，产生业务用例模型。

CIM-2：分析业务流程，产生活动图。

CIM-3：定义系统范围，产生系统用例图。

PIM-1：分析系统流程，产生系统用例叙述。

PIM-2：分析业务规则，产生状态图

PIM-3：定义静态结构，产生类图。

PIM-4：定义操作及方法，生成序列图。