UML之用例图

一、概述

    用例是需求分析阶段最重要的概念。需求获取(Requirement Elicitation)是需求分析阶段的主体，其主要工作是建立待开发系统的模型，而用例就是用于建立这种模型的良好方法。用例最初由Ivar Jackboson博士提出，后被综合到UML规范之中，成为需求表述的标准化体系。

 

    用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的功能，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点。设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

    用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

    总之，由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图称为用例图。

二、用例图所包含的元素：

　　1. 参与者(Actor)

　　Actor不是人，而是指参与用例时担当的角色。用一个小人表示。

    怎样识别参与者呢？

1. 是谁向系统提供的信息.
2. 谁向系统获取信息。
3. 谁操作系统。
4. 系统使用哪些外部资源
5. 系统是否和已经存在的系统交互

　　2. 用例(Use Case)

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

   怎样确定用例的粒度呢？

用例的粒度（用例的大小）可大可小，一般一个系统易控制在20个左右。用例是系统级的抽象的描述，不是细化的（是做什么，非怎样做）。对复杂系统可以划分为若干个子系统处理。

  怎样获取用例呢？

参与者希望系统执行什么任务？

参与者在系统中访问哪些信息（创建、存储、修改、删除等）？

需要将外界的哪些信息提供给系统？

需要将系统的那个事件告诉参与者？

如何维护系统？

　　3. 子系统(Subsystem)

　　用来展示系统的一部分功能，这部分功能联系紧密。

　　4. 关系

　　用例图中涉及的关系有：关联、泛化、包含、扩展。

　　如下表所示：

　　a. 关联(Association)

　　表示参与者与用例之间的通信，任何一方都可发送或接受消息。

　　【箭头指向】：指向消息接收方

　　b. 泛化(Inheritance)

　　就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

　　【箭头指向】：指向父用例

　　c. 包含(Include)

　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

　　【箭头指向】：指向分解出来的功能用例

　　d. 扩展(Extend)

　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

　　【箭头指向】：指向基础用例

　　e. 依赖(Dependency)

　　以上4种关系，是UML定义的标准关系。但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

　　【箭头指向】：指向被依赖项

　　5. 项目(Artifact)

　　用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。

　　用依赖关系把某个用例依赖到项目上：

　　然后把项目-》属性 的Hyperlink设置到你的文档上；

　　这样当你在用例图上双击项目时，就会打开相关联的文档。

　　6. 注释(Comment)

 

　　包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

　　条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

　　直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

　　对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

　　对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；

　　一个用例图示例：

 

　　牢骚：

　　感觉用例图还不成熟，并不能很好地表达系统的需求， 没有UML背景的用户几乎不知道画的是些什么。

　　其次，包含关系、扩展关系的箭头符号竟然是同样的箭头，仅靠上方写个文字来加以区别，翻译成其他语言的话，几乎就不知道代表什么意思。扩展关系的箭头朝向也很难理解，为何要指向基用例，而不指向扩展用例。

　　VS2010添加的“项目”元素，是个很好的创新，能够在用例图中关联word, excel这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。 

三、用例描述

描述用例，有时仅用例图是不够的，还需要用例描述。它可以更详细地描述用例的功能。

1.用例描述的组成

用例名称，简要说明/描述，优先级，参与者，前置条件，基本事件流，其他事件流，异常事件流，后置条件。

部分组成的解释：

事件流：就是用例执行时，由一序列活动组成的控制流。

基本事件流：对用例中常规、预期路径的描述。

异常事件流：主要是对一些异常情况、选择分支进行描述。

前置条件：在用例启动时参与者（actor）与系统应置于什么状态。

后置条件：用例结束时系统应置于什么状态。

例子：

 

大家还可以参考这个博客：http://xhf123456789plain.blog.163.com/blog/static/172880482201192221826110/