一个UML建模实例

需求获取

1.需求获取

n系统开发的第一步工作就是进行需求收集。

n需求收集从调查开始。

n调查是为了发现了系统中的参与者和高层用例。

建立用例图

n为了能够准确的描述用户的需求，就要使用用例。

n首先需识别用例，然后才能建立用例。

⑴确定系统边界

n在确定参与者和用例的过程中也就确定的了系统的边界，

n用例是系统之中的，

n参与者是系统外部的。

（1）识别参与者

 

一般地，可以通过以下问题去寻找用例图中的参与者：

n谁是系统的主要使用者？

n谁从系统获取信息？

n谁向系统输入信息？

n谁从系统中删除信息？

n谁需要系统支持他们的日常工作？

n谁来维护、管理系统使其能正常工作？

n系统需要控制哪些硬件？

n系统需要与其他哪些系统交互？

n对系统产生的结果感兴趣的是哪些人或哪些事物？

n除把直接使用系统的人员确认为参与者外。

n凡是与系统进行信息交换（包括数据信息和控制信息交换）的外部事物均可被确认为参与者。

n外部事物指的是：人员、设备、外部系统、事件。

⑵识别用例

基于参与者识别用例

nl）识别出与系统有关的参与者。

n2）对每个参与者，识别出他们发起或参加的过程。

n3）对每个参与者，识别出向他们传递信息的过程。

可列一个表

为编制用例准备一个表

 

参与者	向参与者传递信息的服务或事件	用例名	简短的描述	业务目标

参与者→职责→用例

 

n参与者名：

¨customer（客户）

n参与者职责：

¨定货、退还定货、查询定单。

n参与者检查问题：

¨使用系统主要功能；

¨对系统运行结果感兴趣。

 

从发货者（Shipper）识别

n发货者要求系统提供什么功能？

¨仓库存储物品的管理；

¨发货处理。

n发货者需要做什么？

¨从所有的定单中按顺序挑选出优先级较高的定单来发货；

¨在发货单上签上发货的品名、数量。

nl 发货者需要阅读、创建、销毁、更新或存储系统的某些信息吗？

¨是，发货者需要阅读、更新仓库存储物品信息和顾客信息。

nl 系统中的事件一定要告知发货者吗？

¨仓库有关物品短缺（发货者报告）

识别用例

 

n通常，在确定用例前应考虑以下问题：

n参与者需要使用系统吗？

n对于各个参与者，哪些任务会涉及到系统？

n系统与参与者之间有哪些交互？

n系统需要何种输入输出？输入从何处来？输出到何处去？

 

n用例将支持和维护的系统功能是什么？

n必须提醒参与者的系统事件有哪些？

n参与者必须提醒系统事件有哪些？怎样把这些事件表示成用例中的功能？

用例的粒度

 

n不要把用例划分的过大，也不要把用例划分得过于琐碎细小。

n通常,用例的行为都是用事件流描述，并且会产生显著的目标。这是用例粒度的底线。

n即每个用例都应当是一个完成有意义的业务目标的事件流集合。

⑷确定关系 

 

n确定用例的最后一个步骤就是描述关系。

n关系包括：

¨参与者与用例之间的关系

¨用例之间的关系

¨参与者之间的关系。

n关系类型包括：

¨关联关系、包含关系、扩展关系和泛化关系。

发现包含关系

n系统分析员应该检查模型中的每个用例，提炼出公共的部分，创建单独的用例，并用包含关系与基本用例连接。

n这样会降低原来的用例复杂性，增加用例的复用性。