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

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

XXX USE CASE

PRIMARY ACTOR:
LEVEL: Summary, Use goal, Sub function
STAKE HOLDER:其他对此感兴趣的人或者系统
Precondition[/b]
当前use case发生的前提条件。比如在一个网络即时通讯的系统中，网络会议的case前提可能是由于需要服务器中转信息，服务器的网络必须要处于正常状态。而对于某些case的前提可能是必须系统某组成部分处于异常状态。
Flow of Events:[/b]
A. Primary Scenario:[/b][/b]
描述的是basic path。就像前面提到的EBP原则那样，好像是个流水账。按照1、2、3、4……来把事情描述清楚
B. Secondary Scenarios:[/b]
[/b]在这里要对Primary 场景下发生的个别例外描述清楚，要带着Primary Scenario中的编号，清楚的说明在哪个步骤或者从哪到哪可能会发生什么问题，并且发生了问题后要如何处理，这里着重要描述的是逻辑上的错误
Exception Scenarios:[/b]
[/b]格式同上，可以将发生的违例描述清楚，包括发生后应该如何处理。这里着重要描述的是程序中可能会发生的各项违例，如：网络中断，发生IO违例……
Post condition:[/b]
整个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:[/b]
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，到了设计阶段