UML（二）用例图

1、定义：

         用例图主要用来描述用户需求，从用户角度分析功能和功能执行者，强调谁在使用系统，系统为执行者完成了哪些功能。

用例模型一般出现在软件开发过程中的需求分析阶段，表明开发者和用户共同制定对需求模型达到的共识。

2、组成：

         

         用例。符号为椭圆，表示功能的描述；

         角色。符号为一个小人，表示用例与谁相关；可以是人（开发、维护、使用等各种人员）或事物（如外设、关联系统）。

         在这里，我们说明一下怎么寻找执行者，也就是角色。方法：（1）、看谁使用系统 ；（2）、谁需要系统支持日常行为工作；  （3）、谁维护；（4）、系统要操作哪些硬件；（5）、系统要需要与哪些系统交互；（6）、还有哪些人、物对系统产生的结果产生兴趣。

         关系。包括用例间、执行者间、用例和执行者之间的关系。分为依赖、泛化、关联、包含和扩展这五种关系，这是我们分析的重点。

         关联关系：只表示两个用例之间有关系，具体是什么关系并未说明，所以该关系在用例图中要尽量少用或不用；      

         依赖关系：依赖关系描述两个模型元素（类、用例等）之间的语义连接关系。其中模型元素A是独立的，另一个模型元素B不是独立的，B依赖于A。如果A改变了，将影响依赖于它的B。简明的说就是一种单方面的使用关系：如人看书，书损坏了人受到影响，而人出了问题书不会受到影响。

                

         泛化关系：泛化关系不仅用例之间存在，角色之间也有。它实际上一种继承关系，子用例继承抽象的父用例中所有的结构、行为和关系，但子用例可以表现出更特殊的行为，且这些特殊行为都可以作为父用例的备选流存在。子用例可以使用父用例的一段行为，也可以重载它。

         

         包含关系：包含用例来封装一组跨越多个用例的动作或行为，以便多个基用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

         包含关系最典型的应用就是复用，某个用例会复用子用例，主要用来避免重复。

         当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；另外，当用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。

         这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

         注意：包含关系中，父用例包含的子用例必须随父用例一起得到执行！比如你想进淘宝买东西，必须输入账号和密码。

          

         扩展关系：假设基用例中存在已封装好的一段相对独立的行为或动作，扩展用例在其声明好的扩展点上进行扩展，为基用例添加新的行为而这就形成了扩展关系。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

简言之，扩展用例扩展了一个基用例的Code,主要用来描述对正常处理行为的变异。

         注意，与包含关系不同，父用例包含的子用例不必随父用例一起得到执行！比如你获得了一份电子账单，可以选择打印，也可以不打。

         

3、规范：

（1）、用例图应该清晰地定义系统边界，用例止于系统边界（边界可想象成界面或对外接口）；

（2）、执行者的名字应保持一致，用例命名也要从执行者的角度考虑，还要避免执行者与用例之间的关系太复杂；

（3）注意用例大小要适当，避免用例过多导致描述过于混乱。

4、用例粒度：

         一般来讲，用例的粒度包括概述级、用户目标级和子功能级三种。

         概述级：人---饭店，这样的用例很大，无法实现，一般是帮助用户理解整体需求用的。

         

         用户目标级：有的是对概述级的细化，有的是扩充。人---点餐；付账

         

         子功能级：一般来说，用例粒度越小越好。在需求阶段，则需求的粒度越细，后期设计越踏实，因需求不明确而返工的可能性越小，设计越有的放矢，质量越有保障，项目成功的可能性越大。但在实际项目中，由于时间成本、用户观点各不相同等因素，追求细致的用例难以实现，具体做到多细还需要看实际情况。人---点餐，付账---去前台

        

5、主要属性：

           用例图有许多属性，在这里主要介绍几种典型的，供大家参考。

         （1）、事件流：描述一个用例在执行时执行者与系统的交互过程。这个过程包含多个分支：

                   基本流：对用例中常规和预期路径的描述；

                   备选流：由于受到其他因素的影响，用例执行了其他的路径。

         （2）、前置条件：是该用例执行的前置条件，用来描述在什么条件下可以开始执行一个事件流。

         （3）、后置条件：说明用例结束时系统的状态。

       前置条件和后置条件可以用于用例的验证和评审。

6、小结：

       用例图是描述需求最重要的图，是系统分析人员与用户交流的重要工具之一。它重在应用、重在交流、重在事件流的描述。做好系统的分析工作，明确较为详细、准确的用户需求对软件的后期工作尤为重要，良好的用例分析能大大降低软件修改甚至重新设计的费用，促进软件快速成型和投入使用。