画用例图步骤

 

用例图

用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。
用例图包含六个元素，分别是：参与者 (Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。

一．参与者（Actor）
确定参与者
在获取用例前首先要确定系统的参与者， 开发人员可以通过回答以下的问题来寻找系统的参与者。
（1）         谁将使用该系统的主要功能。
（2）         谁 将需要该系统的支持以完成其工作。
（3）         谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4）         系 统需要处理哪些硬件设备。
（5）         与该系统那个交互的是什么系统。
（6）         谁或什么系统对本系统产生的结果感兴趣。

 

本系统的参与者:

1.录入人员 2.会计 3.
二、用例（Use Case）
识别用例
用例图对整个系统建模过程非常重要，在绘 制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个 问题。识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系 统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程 中，通过回答以下几个问题，系统分析者可以获得帮助。
（1）         特定参与者希望系统提供什么功能。
（2）         系 统是否存储和检索信息，如果是，由哪个参与者触发。
（3）         当系统改变状态时，是否通知参与者。
（4）         是 否存在影响系统的外部事件。
（5）         哪个参与者通知系统这些事件。

 

三、用例间的关系
  1．关联关系（Association）

２．包含关系（Include）
包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。 用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。
包含关系使一个用例的功能可以在另一个用例中使用，如下所述。
（1）         如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。
（2）         一个用例的功能太多时，可以用包含关系建模两个小用例。
要使用包含关系，就 必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。

３．扩展关系（Extend）
相对于包含关系一定要执行的特性，扩展关系（extend）则是一种可选择执行的关系。以自动柜员机（ATMSystem）为例，打印收 据（print receipt）与提款之间的关系就比较适合采用扩展关系，如下图所示。在提款流程结束之前，会询问顾客是否需要打印收据，所以打印收据不是一段必要的流程，而是一段可选择的流程。

４．泛化关系（Generalization）
一个用例可以被特别列举为一个或多个用例，这被 称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。
在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是 某个一般用例的特殊化时，就需要使用用例的泛化关系。