软件设计过程中画用例图的步骤

用例图用例图(UseCaseDiagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例图包含六个元素，分别是：参与者(Actor)、用例(UseCase)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。一．参与者（Actor）确定参与者在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。（1）        谁将使用该系统的主要功能。（2）        谁将需要该系统的支持以完成其工作。（3）        谁将需要维护、管理该系统，以及保持该系统处于工作状态。（4）        系统需要处理哪些硬件设备。（5）        与该系统那个交互的是什么系统。（6）        谁或什么系统对本系统产生的结果感兴趣。二、用例（UseCase）识别用例用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。（1）        特定参与者希望系统提供什么功能。（2）        系统是否存储和检索信息，如果是，由哪个参与者触发。（3）        当系统改变状态时，是否通知参与者。（4）        是否存在影响系统的外部事件。（5）        哪个参与者通知系统这些事件。三、用例间的关系  1．关联关系（Association）２．包含关系（Include）包含关系把几个用例的公共步骤分离成一个单独的被包含用例。被包含用例称作提供者用例，包含用例称作客户用例，提供者用例提供功能给客户使用。用例间的包含关系允许包含提供者用例的行为到客户用例的事件中。包含关系使一个用例的功能可以在另一个用例中使用，如下所述。（1）        如果两个以上用例有大量一致的功能，则可以将这个功能分解到另外一个用例中。其它用例可以和这两个用例建立包含关系。（2）        一个用例的功能太多时，可以用包含关系建模两个小用例。要使用包含关系，就必须在客户用例中说明提供者用例行为别包含的详细位置。这一点同功能调用有点类似。事实上，它们在某种程度上具有相似的语义。３．扩展关系（Extend）相对于包含关系一定要执行的特性，扩展关系（extend）则是一种可选择执行的关系。以自动柜员机（ATMSystem）为例，打印收据（printreceipt）与提款之间的关系就比较适合采用扩展关系，如下图所示。在提款流程结束之前，会询问顾客是否需要打印收据，所以打印收据不是一段必要的流程，而是一段可选择的流程。４．泛化关系（Generalization）一个用例可以被特别列举为一个或多个用例，这被称为用例泛化。当父用例能够被使用时，任何子用例也可以被使用。在UML中用例泛化与其它泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加、覆盖或改变继承的行为。如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。