用例建模

用例建模
用例建模是需求工程的一种形式
用例建模是抽取和存档需求的不同和补充方法

 

典型的用例建模过程
   找出备选系统边界
   找出参与者
   找出用例
        －说明用例
        －识别主要附流
   迭代直到用例、参与者以及系统边界稳定下来

 

这些活动的输出是用例模型，该模型具有四个部分：
系统边界：说明正在建模系统的边界
参与者：人们或者使用系统的物件所扮演的角色
用例：参与者与系统交互的物件
关系：参与者与用例之间有意义的联系

 

用例模型为对象和类提供了基本来源，它是类建模的主要输入。这样，研发人员也就继承了需求分析师的成果。

 

 

系统边界
当你考虑构造系统时，第一件事情是确定系统的边界在哪儿。
系统边界是定义由谁或什么（即，参与者）使用系统，系统能够为哪些参与者提供什么特定利益（即，用例）。

 

 

参与者
参与者说明与系统直接交互时，一些外部实体采用的角色。它可以表示用户角色或者由其他系统或者硬件所扮演的角色，它触及系统边界。

为了识别参与者，需要考虑：
谁或者什么使用该系统？
交互中，它们扮演什么角色？
谁安装系统？
谁或者什么启动和关闭系统？
谁维护该系统？
与该系统交互的是什么其他系统？
谁从该系统获取信息，谁向系统提供信息？
什么事情发生在固定时间？

 

容易犯错的地方，提醒大家注意：
1、参与者表示人和事物同系统发生交互时所扮演的角色，而不是特定的人和特定事务。
2、一个人或事物在与系统发生关系时，同时或不同时扮演多种角色。
3、每个参与者需要一个具有业务意义的简短名称。
4、系统、时间均可做为参与者。
5、参与者分为：
     第一参与者，触发用例
     第二参与者，用例被触发后，同用例进行交互

 

 

用例
用例是系统、子系统或类能够与外部参与者交互所执行的动作序列，包括各种序列以及出错序列的规格说明。

 

用例是参与者想要系统做的事情，它是特定参与者对于系统的“使用情况”：
用例总是由参与者开始
用例总是从参与者的角度来书写

 

识别用例的最好方法是从参与者列表开始，然后考虑每个参与者如何使用系统。
每个用例必须被赋予一个简短的、描述性的名称（动词短语），毕竟，用例描述的是正在做什么。

 

当你试图识别用例时，以下是有帮助的提问：
特定参与者系统提供什么功能？
系统存储和遍历信息吗？如果有，哪个参与者触发这个行为？
当系统改变状态时，会发生什么？通知的参与者是谁？
存在影响系统的外部事件吗？是谁通知系统有关这些事情的？
该系统同其他外部系统交互吗？
该系统产生报告吗？

 

关系
包括：依赖、泛化、关联。（另起一篇，专门详述）