用例建模

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

 

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

 

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

 

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

 

 

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

 

 

参与者参与者说明与系统直接交互时，一些外部实体采用的角色。它可以表示用户角色或者由其他系统或者硬件所扮演的角色，它触及系统边界。 为了识别参与者，需要考虑：谁或者什么使用该系统？交互中，它们扮演什么角色？谁安装系统？谁或者什么启动和关闭系统？谁维护该系统？与该系统交互的是什么其他系统？谁从该系统获取信息，谁向系统提供信息？什么事情发生在固定时间？

 

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

 

 

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

 

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

 

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

 

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

 

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

转载于:https://www.cnblogs.com/mianshibaodian/archive/2010/10/20/1856563.html

相关资源：各显卡算力对照表！