OOA/D的统一构建(UP)过程之二：需求分析阶段之Domain model

1．4、一个USE CASE的书写范例：

XXX USE CASE

PRIMARY ACTOR:

LEVEL: Summary, Use goal, Sub function

STAKE HOLDER:其他对此感兴趣的人或者系统

Precondition

    当前use case发生的前提条件。比如在一个网络即时通讯的系统中，网络会议的case前提可能是由于需要服务器中转信息，服务器的网络必须要处于正常状态。而对于某些case的前提可能是必须系统某组成部分处于异常状态。

Flow of Events:

A. Primary Scenario:

描述的是basic path。就像前面提到的EBP原则那样，好像是个流水账。按照1、2、3、4……来把事情描述清楚

B. Secondary Scenarios:

   在这里要对Primary 场景下发生的个别例外描述清楚，要带着Primary Scenario中的编号，清楚的说明在哪个步骤或者从哪到哪可能会发生什么问题，并且发生了问题后要如何处理，这里着重要描述的是逻辑上的错误

Exception Scenarios:

  格式同上，可以将发生的违例描述清楚，包括发生后应该如何处理。这里着重要描述的是程序中可能会发生的各项违例，如：网络中断，发生IO违例……

Post condition:

  整个use case执行完毕后系统应当处于什么样的状态下，需要特别说明

 

这样整个use case就完成了,可以发现use case实际上是围绕actor的。在实际的工作中可能会发生由于需求的改变或者细化，将某个use case拆分为几个use case的情况。

 

 

1.5 DOMAIN MODEL

Domain model本质上就是Conceptual Class，特征是：

1、名词；

2、每个object映射到现实世界中的对应物；

3、描述的是彼此之间的关联；

4、不包含方法

Domain model是从use case中直接得到的，下面是从use case中如何得到Domain model的规则：

Conceptual Classes Category in perfect scenario:

1．  physical objects:

2．  specification ,design or description：

3．  places：

4．  transaction:

5．  transaction line items:

6．  role of people:

7．  container:

8．  things in the container:

9．  other extend systems interacted:

10．              organization:

11．              Events:

12．              process:

13．              rules and policy:

14．              records:

 

这样就可以得到Domain model。在当前阶段得到的Object越多越好，在下一步的设计中才不会有遗漏。这是一个例子：系统报警case 的domain model：

下一次我们以上面的domain model为例，介绍ssd和ccd，到了设计阶段