UML 用例图

需求：系统必须满足的条件或具备的能力，以用例为中心组织需求

 

1.角色（谁来做）：

     （1）角色是群体概念，即角色代表一类能使用某个功能的人或外部系统、外因素、外时间，不是指某个个体

    （2）每个角色可以参与一个或多个用例

    （3）在系统的实际运作中，一个实际用户可能对应系统的多个角色

              

 

如何识别角色：    

&谁使用系统的主要功能

&谁改变系统的数据

&谁从系统获取信息

&谁需要系统的支持以完成日常工作任务

&谁负责日常维护、管理并保证系统正常运行

&谁使用或删除系统中的信息

&谁（或什么）对系统运行产生的结果（值）感兴趣

&系统需要应付（处理）那些硬设备

&系统需要和那些外部系统交互

&在预定时间，是否有事件自动发生

&时间、气温等内部外部条件

2.用例（做什么）：

     为完成一个相对完整的一种功能，系统执行的一系列动作的集合

    用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图或非正式的文字描述来表     示

区别：

1. 活动图：适合描述多个对象跨越多个用例时的总面貌
2. 交互图（顺序图、协作图）：适合描述单个用例中多个对象之间的协作行为
3. 状态图：适合描述跨越多个用例的单个对象的行为，不适合描述多个对象之间的协作行为

 简洁识别用例：参与者使用系统达到目标

3.识别用例要点：

      3.1可观测→用例止于系统边界               

     

      3.2结果值→用例是有意义的目标

                  

      3.3系统执行→结果值由系统生成

     

      3.4由参与者观测→业务语言、用户观点

                   

      3.5一组用例实例→用例的粒度：

      3.5.1过细的粒度，一般都会导致技术语言的描述，而不再是业务语言

            

   3.5.2 创建用例容易导致关心数据的存储和维护，反而忽略了用户的目的，如下图：

            

 

   3.5.3 不管是C、R、U、D，都是为了完成“管理”目标；

      甚至很多种的基本数据管理都可以用一个用例表示

          

              

 

  3.6 用例命名

               

 

4.0 用例关系

                 

 4.1 关联关系：

    关联关系描述参与者与用例之间的关系，描述它们之间的通信

 

             

  4.2 包含关系：

    用例与用例间的关系

    肯定有的，非可选，不写不完整，可以简单认为源代码中的函数调用或操作调用

                

                 

  4.3 扩展关系

   用例与用例间的关系

     4.3.1 在前一个事例的多种选择中选择，将导致不同的结果

                  

    4.3.2 存在评定点（特定条件是超期，如果满足特定条件，将执行“交纳罚金”这个扩展用例）

                      

  4.4 泛化关系

     在前一个事例的多种选择中选择，将导致相同的结果（ 父用例能够被使用的时候，任何子用例也能够被使用，      子用例之间是一种平行关系）：

               

                  

     还有就是参与者之间的泛化关系，它们之间通常不需要特殊条件触发，所以很明显用泛化而不是拓展