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 泛化关系

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

                

                  

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

                

转载： http://blog.youkuaiyun.com/happyunbound/article/details/8118974