UML 用例图

【前言】

          学习UML也有一个月了，仔细的学习了一下UML的9种图，今天让我来给说一说用例图

【内容】

一、用例图

          1、用例图：用来描述用户的需求

          2、用例图的基本元素：

            （1）用例：就是功能的描述

            （2）角色：一种人员的角色，用来指明这个用例跟哪一个角色相关

            （3）关系：指明用例和执行者之间的关系

          3、用例图中间的关系：依赖关系、泛化关系、关联关系

          4、用例的主要属性：

                          

             5、用例的注意点：

               （1）应该清晰的定义系统边界

               （2） 防止用例过多

               （3）应该从执行者的角度来命名用例

               （4）用例描述正规程度

               （5）避免执行者的名字不一致

               （6）避免执行者和用例之间的关系太复杂

               （7）注意用例的大小是否恰当

               （8）避免用例描述混乱 

                （9）区分用例分解和功能分解

               （10）避免客户不能理解用例的情况发生 

                 （11）有些场合用用例来描述需求是不合适的    

  二、用例图中依赖关系中include与extend的区别

             include是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分，而extend则恰好相反。 include是指用例中的包含关系，通常发生在多个用例中，有可以提取出来的公共部分（就象提取公因式一样），例如UseCaseA中包括了a和b两个流程，而UseCaseC中包含了c和b两个流程。为了提高复用性，可以把b提取出来，形成另一个用例UseCaseB，此时，UseCaseAincludeUseCaseB（表现为一条指向UseCaseB的虚线，箭头在UseCaseB侧），UseCaseC也includeUseCaseB。因而，当有include关系时，被include的用例通常会有两个以上的其他用例include（否则就不需要重用，也就不需要提取出来了）， 在include关系中，“UseCaseA和UseCaseC知道UseCaseB的存在，而UseCaseB根本不知道有UseCaseA和UseCaseC； UML用例图如 下：

                    

  

         extend则恰好相反。假设UseCaseA的功能描述为“发送一条通知”，可是，发送通知的方式可能有许多种，例如通过邮件发送、通过短信发送等。在需求分析阶段，可能无法明确到底有多少种方式，在用例分析阶段，UseCaseA需要留出扩展接口，然后把已知的发送方式作为扩展用例给出，例如UseCaseB是“通过短信发送”，而UseCaseC是“通过邮件发送”，此时，UseCaseB和UseCaseCextend了UseCaseA，表现为两根虚线，箭头指向UseCaseA。在extend关系中，UseCaseA不知道UseCaseB和UseCaseC的存在，但UseCaseB和UseCaseC却是知道UseCaseA并且知道如何在UseCaseA中作扩展的。UML用例图如下： 

                                   

三、机房收费系统 用例图

        

      这是自己画的用例图 ，第一次画觉得还是有点不好，以后多多改进吧，欢迎大神们的指点.

[总结]

       剩下的UML图欢迎大家继续跟下去。。。