UML用例图(转)

前些时间参加了潘加宇老师的技术讲 座， UML 建模技术受益匪浅。我也把平时的一些积累和上次的 收获总结在这篇文章中，主要讲解用例图相关的知识。
      用例图是软件需求分析到最终实现的第一步，它描述用户如何使用系统及使用系统什么样的功能。用 例图从业务角度上体现谁来使用系统、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，也便于软件开发人员最终实现这些功能。用例图在开发中 被广泛的应用，但是它最常用来描述系统提供了什么样的功能给什么样的用户使用。

       在官方文档中用例图包 含六个元素，分别是：执行者 (Actor) 、用例 (Use Case) 、关联关系 (Association) 、包含关系 (Include) 、扩展关 系 (Extend) 以及泛化关系 (Generalization) 。但是有些 UML 的绘图工具多提供了一种直接关联关系 (DirectedAssociation) 。

        用例图可一个包含注 释和约束，还可一个包含包，用于将模型中的元素组合成更大的模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，执行者用人形图标来标识，用例 用椭圆来表示，连线表示它们之间的关系。

一、执行者（ Actor ）

       1 、执行者概念

     是指用户在系统中扮演的角 色。如图 1-1 是一个用户管理的用例图，图中的用户、管理员 就是用例的执行者。

                     图 1-1

         2 、 从业务中找出执行者

     获取系统用例首先要找出系统的执行者。我们可以通过用户回答一些问题的答案来识别执行者。可以参考以下问题：

扫描二维码关注公众号，回复： 1187669 查看本文章

1. 谁使用系统的主要功能（主要使用者）？
   
2. 谁需要系统支持他们日常工作？
   
3. 谁来维护、管理系统使其正常工作（辅助使用者）？
   
4. 系统需要控制哪些硬件？
   
5. 系统需要其他哪些系统交互？这里包含其他计算机系统或者应用程序。
   
6. 对系统产生结果感兴趣的是哪些人和哪些事物？
   

       3 、 执行者之间关系

因为执行者是类，所以多个执行者之间可以具有与类相同的关系。在 用例图中，使用了泛化关系来描述多个执行者之间的公共行为。如果系统中存在几个执行者，它们既扮演自身的角色，同时也扮演更具一般化的角色，那么就用泛化 关系来描述它们。这种情况往往发生在一般角色的行为在执行者超类中描述的场合。特殊化的执行者继承了该超类的行为，然后在某些方面扩展了此行为。执行者之 间的泛化关系用一个三角箭头来表示，指向扮演一般角色的超类。这与 UML 中类之间的返还关系符号相同。图1-2

                     图1-2

二、用例（ Use Case ）

         1 、 用例概念

     用例就是外部可见的系统功 能，对系统提供的服务进行描述。

         2 、 从业务中找出用例

     找出系统的用例，我们从执行 者入手，对每个执行者提出一些问题，然后从执行者对这些问题的答案中获取用例。可以参考以下问题：

1. 执行者要求系统提供哪些功能（执行者需要做什么）？
   
2. 执行者需要读、产生、修改、删除或者存储系统中的信息有哪些类型？
   
3. 执行者必须提醒系统事件有哪些？把这些事件表示成系统用例。
   

         3 、 用例之间关系

二、用例之间关系

        1 、 关联关系（ Association ）

关联关系是连接执行者和用例，表示该执行者代表的外部系统实体与该用例描述的系统需 求有关。

图1-3

        2 、包含关系（Include ）

包含关系是来自于用例的抽象，即从数个不同的Use Case中，分离出公共的部分，而成为可以复用的用例。

图 1-4

        3 、扩展关系（Extend ）

     扩展关系表示某一个用例的对话流程中，可能会根据条件临时插入另外一个 用例，而前者称为基础用例后者称为扩展用例。

    

                图1-5

4、泛化关系（Generalization ）

     一个用例可以被特别列举为一个或多个用例，这被称为用例泛化，如果系统 中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。

    

转载自：http://www.alisdn.com/wordpress/?p=1161

                图1-6