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，到了设计阶段
本文地址：http://com.8s8s.com/it/it16392.htm