第5章 用例图精要.ppt

第五章 用例图 学习内容 用例图的概念 用例的确定 用例之间的关系 绘制用例图 5.1 用例图的概念 用例图是由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图。 它是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。 借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。 5.1 用例图的概念 5.1.1 参与者 参与者是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面，如下图所示。 5.1 用例图的概念 5.1.2 用例 用例是参与者（角色）可以感受到的系统服务或功能单 元。用例定义了系统是如何被参与者使用，描述了参与者 为了使用系统所提供的某一完整功能而与系统之间发生的 一段对话。 用例最大的优点就是站在用户的角度上来描述系统的功能 的。它把系统当作一个黑箱子，并不关心系统内部是如何 完成它所提供的功能，表达了整个系统对外部用户可见的 行为。 UML中通常用如下图所示的一个椭圆图形来表示用例，用 例名称书写在椭圆下方。 5.2 参与者之间的关系 由于参与者实质上也是类，所以它拥有与类相同的关系描 述，即参与者与参与者之间主要是泛化关系。 泛化关系的含义是把某些参与者的共同行为提取出来表示 成通用行为，并描述成超类。泛化关系表示的是参与者之 间的一般/特殊关系 在UML图中，使用如下图所示带空心三角箭头的实线表示 泛化关系，箭头指向超类参与者。 5.3 用例的确定 5.3.1 识别用例 任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。 可以通过以下问题来寻找用例： 1. 参与者希望系统提供什么功能？ 2. 参与者是否会读取、创建、修改、删除、存储系统 的某种信息？如果是的话，参与者又是如何完成这 些操作的？ 3. 参与者是否会将外部的某些事件通知给系统？ 4. 系统中发生的事件是否通知参与者？ 5. 是否存在影响系统的外部事件。 5.3 用例的确定 5.3.2 用例粒度 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。 5.3 用例的确定 例如在网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。 5.3 用例的确定 5.3.3用例规约 对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。 每一个用例的用例规约都应该包含以下内容： 1.简要说明 2.事件流 3.用例场景 4.特殊需求 5.前置条件 6.后置条件 5.3 用例的确定 5.3.4 用例间的关系类型 包含 包含指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 在UML中，包含是通过带箭头的虚线段加include字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。 5.3 用例的确定 5.3.4 用例间的关系类型 在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系： 1. 多个用例用到同一段的行为，则可以把这段共同的 行为单独抽象成为一个用例，然后让其他用例来包含这一用例。 2. 某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。 5.3 用例的确定 5.3.4 用例间的关系类型 扩展 在一定条件下，把新的行为加入到已有的用例中，获得的新用例称为“扩展用例”(Extension)，原有的用例称为“基础用例”(Base)，从扩展用例到基础用例的关系就是扩展关系。 一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。 5.3 用例的确定 5.3.4 用例间的关系类型 泛化 用例的泛化指的是一个父用例可以被特化形成多个子