UMl——用例图

用例图：主要用于为系统的功能需求建模，它主要描述系统功能，也就是从外部用户的角度观察，系统应该完成哪些功能，有利于开发人员以一种可视化的方式理解系统的功能需求；有利于用户和软件开发人员之间的沟通。

用例图是对系统功能的一个宏观描述，画好用例图是由软件需求到最终实现的第一步，也是最重要的一步。

作用：

1. 系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
2. 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。
3. 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。
4. 用例图清楚地描述了使用者及它们之间的泛化关系，用例及用例之间的泛化、扩展关系，用例和参与者之间的关联关系，可从用例图中得到对于被定义系统的一个总体印象。

4个组成要素：

• 角色
• 用例
• 系统边界
• 关联

角色（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。

系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。

用例是参与者可以感受到的系统服务或功能单元。它定义了系统是如何被参与者使用的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

用例的特征：

1. 用例必须由某一个参与者触发激活后才能执行，即每个用例至少涉及一个参与者。
2. 用例表明的也是一个类，而不是某个具体实例。
3. 用例描述的是它代表的功能的各个方面，包含了用例执行期间可能发生的各种情况。
4. 用例是一个完整的描述。若其被分解成多个小用例，则仅当所有的小用例完成后才代表整个用例的完成。

用例最大的优点：

站在用户的角度上（从系统的外部）来描述系统的功能。它把系统当作一个黑箱子，并不关心系统内部是如何完成它所提供的功能，表达了整个系统对外部用户可见的行为。

关系：

关联：为了减少模型维护的工作量、保证用例模型的可维护性和一致性，可以在用例之间抽象出包含、扩展和泛化这几种关系。

这几种关系都是从现有的用例中抽取出公共信息，再通过不同的方法来重用这部分公共信息。

包含：

包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。

优点：

• 提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与其有关的用例。
• 不但可以避免在多个用例中重复描述同一段行为，还可以避免在多个用例中对同一段行为描述的不一致。

扩展：

在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。

扩展关系和包含关系的不同：

• 在扩展关系中，基础用例提供了一个或多个插入点，扩展用例为这些插入点提供了需要插入的行为。而在包含关系中插入点只能有一个。
• 基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执行。而在包含关系中，当基础用例执行后，被包含用例是一定会被执行的。

• 即使没有扩展用例，扩展关系中的基础用例本身也是完整的；而对于包含关系，基础用例在没有被包含用例的情况下就是不完整的存在。

泛化：

当发现系统中有两个或者多个用例在行为、结构和目的方面存在共性时，就可以使用泛化关系。用新的用例来描述这些共有部分，这个新的用例就是父用例。

泛化关系与包含关系异同：

• 相同：都可用来复用多个用例中的公共行为。
• 区别：
  • 在泛化关系中，所有的子用例都有相似的目的和结构，它们是整体上的相似。
  • 在包含关系中，基础用例在目的上可以完全不同，但它们都有一段相似的行为，它们的相似只是部分的相似。

粒度：

• 用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
• 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。
• 在确定用例粒度时应该根据每个系统的具体情况，具体问题具体分析，在尽可能保证整个用例模型的易理解性的前提下决定用例的大小和数目。

下面机房收费系统的用例图：

角色之间的关系：

一般用户：

操作员：

管理员：