第5章用例图-修订.pptVIP

用例图 主要内容 概述 参与者 用例 概述 用例图的含义 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的视图称为用例图。 概述 用例图的作用 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 概述 用例图特点 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。 概述 当用例视图在外部用户前出现时，它捕获到系统、子系统或类的行为。 用例视图将系统功能划分成对参与者(即系统的理想用户)有用的需求。 交互功能部分被称作用例。 概述 用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交互作用。 参与者可以是人,也可以是外部计算机系统和外部进程。 概述 下图表述了一个电话销售的用例视图。 概述 在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。 参与者 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他系统的理想化概念。 作为外部用户与系统发生交互作用，这是参与者的特征。 参与者 在系统的实际运作中，一个实际用户可能对应系统的多个参与者。 不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。 参与者 每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用（因此也与用例所在的系统或类发生了交互作用） 参与者的内部实现与用例是不相关的,参与者可以被一组定义它的状态的属性充分描述。 参与者 参与者可以通过泛化关系来定义。 在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享。 参与者可以是人、另一个计算机系统或一些可运行的进程。 参与者 在图中，参与者用一个名字写在下面的小人表示。 用例 用例是外部可见的一个系统功能单元。 这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。 用例 用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。 用例的定义包含用例所必需的所有行为 执行用例功能的主线次序 标准行为的不同变形 一般行为下的所有异常情况及其预期反应 用例 从用户角度来看,上述情况很可能是异常情况。 从系统角度来看,它们是必须被描述和处理的附加情况。 用例 在模型中,每个用例的执行独立于其他用例 虽然在具体执行一个用例功能时由于用例之间共享对象的缘故可能会造成本用例与其他用例之间有这样或那样的隐含的依赖关系。 每一个用例都是一个纵向的功能块，这个功能块的执行会和其他用例的执行发生混杂。 用例 用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图或非正式的文字描述来表示。 用例功能的执行通过类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用例。 用例 在系统层，用例表示整个系统对外部用户可见的行为。 一个用例就像外部用户可使用的系统操作。 用例 用例也可以被像子系统和独立类这样的小单元所应用。 一个内部用例表示了系统的一部分对另一部分呈现出的行为。 例如，某个类的用例表示了一个连贯的功能，这个功能是该类提供给系统内其他有特殊作用的类的。 一个类可以有多个用例。 用例 用例用一个名字在里面的椭圆表示，用例和与它通信的参与者之间用实线连接。 用例 识别用例 任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 用例 可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。 用例 用例的粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。 用例 例如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信