UserCase..docx

用例图用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来描述系统及子系统。当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来标识，用例用椭圆来表示，连线表示它们之间的关系。一．参与者（Actor）1． 参与者的概念参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来表示。在UML中，参与者用名字写在下面的人形图标表示。每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定义其状态的属性充分的描述参与者。参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。第三了参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个事件时，时间就成了参与者。２．确定参与者在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。（1） 谁将使用该系统的主要功能。（2） 谁将需要该系统的支持以完成其工作。（3） 谁将需要维护、管理该系统，以及保持该系统处于工作状态。（4） 系统需要处理哪些硬件设备。（5） 与该系统那个交互的是什么系统。（6） 谁或什么系统对本系统产生的结果感兴趣。在对参与者建模的过程中，开发人员必须要牢记以下几点。（1） 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。（2） 参与者可以直接或间接的与系统交互，或使用系统提供的服务以完成某件事务。（3） 参与者表示人和事物与系统发生交户时所扮演的角色，而不是特定的人或者特定的事物。（4） 每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似“新参与者”的名字。（5） 每一个参与者要必须有简短的描述，从业务角度描述参与者是什么。（6） 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。（7） 和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用的不频繁。３．参与者之间的关系因为参与者是类，所以多个参与者之间可以具有与类相同的关系。在用例视图中，使用了泛化关系来描述多个参与者之间的公共行为。如果系统中存在几个参与者，它们既扮演自身的角色 ，同时也扮演更具一般化的角色，那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在参与者超类中描述的场合。特殊化的参与者继承了该超类的行为，然后在某些方面扩展了此行为。参与者之间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。二 用例（Use Case）1．用例的概念用例是外部可见的系统功能单元，这些系统功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例的用途是，在不揭示系统内部构造的前提下定义连贯的行为。用例的定义包含它所必须的所有行为——执行用例的主线次序、标准行为的不同变形、一般行为下的所有异常情况及其预期反应。从用户的角度来看，上述情况很可能是异常情况；从系统的角度来看，它们是必须被描述和处理的附加情况。更确切地说，用例不是需求或功能的规格说明，但是也展示和体现其所描述的过程中的需求情况。在UML中，用例用一个椭圆表示。在模型中，每个用例的执行都独立与其它用例，尽管在执行一个用例时由于用例之间共享对象的原因可能会在用例之间产生隐含的依赖关系。每个用例都表示一个纵向的功能块，这个功能块的执行会和其它用例的执行混合在一起。用例的动态执行过程可以用UML的交互来说明，可