\(^_^)/ 用例图

参考： http://pengfeng.iteye.com/blog/642661

参考: http://wgq837051.iteye.com/blog/960613

参考： http://www.iteye.com/topic/1122586

参考： http://gqsunrise.iteye.com/blog/1257466

参考： http://housen1987.iteye.com/blog/1319309

 

 

用例图是除开发人员以外的用户所能看到的系统功能模型图，展示了一些用户和用例以及它们之间的联系。

主要作用有三个：

a.获取需求；

b.指导测试；

c.在整个过程的其他工作流起到作用。

 

 

用例图所包含的元素如下：

1.参与者（Actor）

参与者不单单是指人，而是指系统以外的，在使用系统或与系统交互过程中所扮演的角色。因此参与者可以是人，也可以是事物或者子系统等等。参与者用简笔画的小人表示：

2.用例（UseCase）

用例可以理解为参与者需要系统做的工作，也就是系统的外部可见功能。用一个椭圆形表示：

3.关系

用例图中涉及到四种关系：

 

 

 

 
 

 

 

 

 

 

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点。

设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。

用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。

从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛化(generalization)几种关系。

 

 

 

 

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

 

 

UML中扩展和泛化的区别 

         泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

         ●泛化侧重表示子用例间的互斥性；

         ●包含侧重表示被包含用例对Actor提供服务的间接性；

         ●扩展侧重表示扩展用例的触发不定性；详述如下：

 

         发生按照发生条件可分为如下两种情况：

⒈无条件发生：肯定发生的；(泛化，包含)

⒉有条件发生：未必发生，发生与否取决于系统状态；(扩展)

 

用例提供服务的方式：

a.直接服务：泛化中的子用例，扩展用例(有条件) -- 可以作为基本用例事件的备选择流而存在。

b.间接服务：包含中的被包含用例

 

 

 

 

1、包含关系(include)

   使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。

   基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。

   基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 

   

   包含关系对典型的应用就是复用。

   但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

   基本用例可以包含包含用例具有的的行为，并把它所包含的用例行为作为自身用例的一部分，这种关系就叫作包含。

 

 

   例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

 

 

 

 

2、扩展关系(extend) 

   将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。

   扩展用例为基用例添加新的行为。

   扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。

   但是扩展用例对基用例不可见。

   对于一个扩展用例，可以在基用例上有几个扩展点。

   一个用例可以定义为基本用例的增量扩展，这种关系便成为扩展关系。扩展关系可以有控制条件，当用例实例执行到一个扩展点时，控制条件便可以决定是否执行扩展。比如消费者购物，如果货物质量出现问题就可以退货，如果未出现质量问题就没必要退货。  

 

 

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

 

 

 

3、泛化关系(generalization)

   子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。

   子用例可以使用父用例的一段行为，也可以重载它。

   父用例通常是抽象的。

   在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

   泛化关系通常有叫继承关系。子用例是父用例的特殊形式，子用例继承了父用例的所有行为和属性，也可以增加新的特性或覆盖父用例的行为。

 

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

 

 

 

 

4）关联（association）

关联描述的是参与者与用例之间的关系。

 

 

 

实例：