|
通过用例来捕获系统需求，然后结合参与者进行系统功能需求的分析和设计。由参与者、用例及它们之间关系构成的用于描述系统功能的动态视图称为用例图。 一个椭圆，用例的名字可以放在椭圆的中心或椭圆下方的中间位置表示一个用例。参与者用人型符号表示。两者之间的关系用带箭头的线段描述，其中箭头所指方为被动接受者（可以用不带箭头的线段描述不带主被动关系）。要注意的是：箭头的方向并不是指信息流的方向。参与者与用例之间的信息流默认存在，是双向的。 （一）用例图的作用 用例图的主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统功能。 传统的需求表述方式是Software Requirment Specification（软件需求规约，SRS），采用功能分解方式来描述系统功能，将系统功能分解到各个系统功能模块中，然后通过描述每个模块的功能来达到描述整个系统功能的目的。 软件需求规约容易混淆需求和设计的界限，导致需求分析包含部分概要设计；通过分割了的系统功能难于表现实现一个完整的系统服务。用例图可视化的表达了系统的需求，且把需求与设计分离开。 （二）用例图构成 （1）参与者（Actor） 参与者指存在于系统外部且直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。通过人形图来表示参与者，参与者的名字在图的下方。参与者是一种角色，而不是具体的人或事物本身。参与者之间的关系主要是泛化关系，也就是继承关系。继承关系通过空心三角箭头的实线段表示。 （2）用例（Use Case） 用例是参与者可以感受到的系统服务或功能单元。它是以用户的角度上来描述系统功能。参与者与用例之间的关系是关联关系，也称为通信关联。参与者是一种角色，用例不是具体实例，而是表示一个类。 用例包含的系统功能有大有小，这就是用例的粒度，粒度大，用例包含的功能多。用例的粒度重要的是一个度。它决定了用例模型级的复杂度，也决定了每个用例内部的复杂度。 用例图是对系统的一个总体描述，此外还需要详细的描述信息。这些详细信息包含在用例规约中。用例规约包含： 简要说明：描述用例的作用和目的。 前置条件：执行用例前系统必须所处的状态。 后置条件：执行完毕用例后系统可能处于的一组状态。 用例场景：用例在实际执行时的多种情况。 事件流：用例正常运行时的场景的基本流程和执行过程中可能发生的异常或偶然场景的备选流。 特殊需求：一个用例的非功能性需求和设计约束。 （三）关联 （1）包含关系（Include） 用例包含其它用例具有的行为，且把被包含的用例的行为作为自身行为的一部分。包含关系用带箭头的虚线段表示，且加上<<include>>字样。有箭头的一方为被包含的被动方，无箭头的一方为主动包含的基础用例。 （2）扩展关系（Extension） 为用例添加新的行为，获取的新用例就是扩展用例，原用例为基础用例。扩展关系通过带箭头的虚线段加<<extend>>字样表示。箭头所指方为基础用例。 （3）泛化关系 泛化关系也就是继承关系。在泛化关系中，子用例继承了父用例的行为、结构和关系。泛化关系通过带空心三角箭头的实线段表示，箭头所指方向为父用例。 例子：
|
|
|
