UML总结之（用例图）

用例图是有软件需求分析阶段到最终实现的第一步，用于描述人们希望如何使用一个系统。用例图显示了谁将是相关的用户、用户希望系统提供什么服务，以及用户需求为系统提供的服务，以便使系统的用户更容易的理解这些元素的用途，也便于软件开发人员最终实现这些元素。

用例图是由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图。它是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。

用例图的主要目的就是帮助人们了解系统功能，便于开发人员和用户之间的交流。

参与者：是指存在于系统外部并直接与系统进行交互的人、系统、子系统、或类的外部实体的抽象。在使用用例图时需要注意的是：参与者虽然可以代表人或事物，但参与者不是指人或是事物本身，而是表示人或事物当时所扮演的角色，直接或间接地与系统交互的任何人或事都是参与者。

用例：是参与者可以感受到的系统服务或功能单元。它定义了系统是如何被参与者使用，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。用例最大的特点是站在用户的角度（从系统外部）来描述系统的功能。它表达了整个系统对外部用户可见的行为。

参与者之间的关系：由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间的主要是泛化关系（或称为“继承关系”）。

用例除了与参与者有关联关系外，用例之间也存在着一定的关系。但在明确用例间的关系前，必须先识别用例，确定用例的粒度和规约，然后才能明确他们之间的各种关系。

识别用例：任何用例都不能在缺少参与者的情况下独立存在，同样，任何参与者也必须要有与之关联的用例，所以识别用例最好的方法是从分析系统参与者来确定系统的用例。

用例粒度：指的是用例所包含的系统服务或功能单元的多少。用例粒度越大，用例包含的功能越多，反之则功能越少，它不仅不决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。用例的粒度很小，得到的用例数就会太多，反之用例的粒度越大，得到的用例数就会很少。

用例规约：用例图知识在总体上大致描述一下系统所提供的各种服务，让我们对系统有一个总体的认识。但对于每一个用例，还需要详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息就包含在规约中，而用例模型指的也仅仅是用例图，而是有用例图和每一个用例的详细描述————用例规约所组成的。每一个用例规约都包含以下内容：简要说明、事件流、用例场景、特殊需求、前置条件、后置条件。

用例间的关系模型：用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和变体。

系统边界：所谓系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身可以使另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分。我们把系统边界以外的同系统相关联的其他部分称之为“系统环境”。用例图中的系统边界是用来表示正在建模系统的边界。边界内部分表示系统的组成部分，边界外表示系统外部。