UML从零开始之用例图

 1.定义

   用例图是用来描述用户的需求，从用户的角度描述系统的功能，并指出各功能的执行者，强调谁在使用系统，系统为执行者完成哪些功能。

 2.构成及其表示

   用例图包括用例、参与者、关系和系统边界

   2.1 Use Case

   用例是构成系统单元提供的外部可感知的功能单元，表达成系统单元和与之相交互的一个或多个活动者的消息序列。用例的目的是定义清晰的行为块而不解释系统的内部结构。用一个椭圆来表示，用例名标在椭圆中或或下方，用实线与跟自身通信的活动者相连接。

     

          

   2.2 Actor

    参与者是在系统外部与系统直接交换的人或事物。

    它是角色role而不是具体的人，它代表了参与者在与系统打交道过程中扮演的角色。系统实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应一个参与者，从而代表同一参与者的不同实例。

      

   2.3 关系

   2.3.1 Actor与Use Case之间的关联

    参与者与用例之间的交互，通信途径。用带箭头的实线表示。

        

   2.3.2 Use Case之间的 包含和扩展

    用例可以简单的合并其它的用例作为自身行为的片段，成为包含。箭头指向的用例为包含用例，箭头出发的为基本用例。包含用例是必选的，如果缺少包含用例，基本用例就不完整。包含用例必须被执行，不需要满足某种条件，其执行不会改变基本用例的行为。

    

     用例还可以被定义为基本用例的增量扩展，称为扩展关系。扩展关系是把新的行为插入到已有的用例中的方法。箭头指向的用例为扩展用例，出发的为基本用例。扩展用例是可选的，如果缺少扩展用例不会影响到基本用例的完整性，扩展用例在一定条件下才会执行，并且其执行会改变基本用例的行为。

     例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

     

      

    2.3.3 Actor之间的 泛化

     一般和特殊的关系，发出箭头的一方代表特殊方指向一般方。特殊一方继承了一般方的特性并增加了新特性。子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。发出箭头的事物“is a”箭头指向的事物。

    例如，业务中可能存在许多需要各级部门领导审批的事情，但是领导审批的流程都是很相似的，这时可以做成泛化关系表示：

   

    

   2.4系统边界

        系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。在画图时可省略。