UML用例建图

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完 成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪 些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用 户），对应的是软件的结构和功能分解。
用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的 服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间 可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
1、包含(include)
   包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

   例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)
扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展 点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。   

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

3、泛化(generalization)

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

    上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
    (1)系统整体用例图
    

    (商品用例图)

   
   
    （购买信息用例）
  
   
 
    (用户资料用例)

   

    
按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

---

用例建模技巧

从参与者的角度并以主动语态编写用例。
应该以主动语态：“学生表明参加研习班意向”，而不是被动语态“研习班意向被学生表明”来编写用例。而且，应该从参与者的角度来编写用例。毕竟，用例的目的是理解用户如何对系统进行操作。

编写方案文本，而非功能需求。
用例描述的是对参与者来说有价值的一系列行动，而不是特性集。例如，“招收研习班的学生”用例描述的是学生如何与系统交互来参加 研习班。它没有描述用户界面看上去是什么样子，或者它是如何工作的。有一些其它的模型来描述这些重要的信息，例如用户界面模型和增补规范。面向对象分析非 常复杂，因此需要对它使用几种模型，并且应该适当地应用每一种模型。

用例只记载行为需求。
用例既不是类规范，也不是数据规范。这是应该由概念性模型捕捉的一种信息，在对象世界中，它是通过 UML类模型建模的。您往往会引用概念性模型中描述的类，例如，“参加研习班”用例包括了“研习班”和“学生”等概念，它们都将由概念性模型描述。

不要忘记用户界面。
系统用例经常引用主用户界面 (UI)元素，这些元素常常称为“边界”或“用户界面”项，例如 HTML页面和报表。用例有时也引用一些次要的 UI元素，例如按钮或数据输入字段，但这种级别的细节并不太常见。

创建用例模板。
用例包含了相当数量的信息，这些信息可以轻易地以常见格式记载。您应该考虑开发自己的模板（请参阅技巧“ 记载用例”）。

始终如一地组织用例图。
一般的做法是垂直地绘制继承 (inheritance) 和扩展 (extend)关联，在父／基本用例下面绘制继承／扩展用例。同样，通常水平绘制包含(include) 关联。请注意，这些是简单的经验法则 --只要始终遵循这些法则，产生的图将很容易理解。

不要忘记系统对参与者行动的响应。
用例既应该描述参与者是如何与系统交互的，也应该描述系统如何响应这些交互。例如，在“参加研习班”用例中，如果系统在学生表明他们希望参加研习班时没有做出响应，学生就会很沮丧地离开。

备选行动过程非常重要。
如果一切顺利，使用的将是基本行动过程 --但也不要忘记备选过程。引入备选过程是为了描述潜在的使用错误以及商业逻辑错误和异常。这些重要的信息对于驱动系统的设计来说很有必要，因此不要忘记在用例中对它们建模。

不要被 <> 和 <>关联所困扰。
我不是很确定到底发生了什么事，但我总是在想包含 (include) 和扩展(extend) 关联，以及旧版本 UML 中使用 (uses) 和扩展 (extends)关联的正确使用从来没有得到很好的描述。结果，用例建模小组往往在这些关联的正确应用上争论不休，在整个建模技术中一些有趣但次要的部 分上浪费了惊人的时间。我曾在一个组织中工作，这家组织居然取缔了<> 和 <>原型的使用，几个星期后，当意识到公司仍然需要这些概念时不得不撤消了这种极端的解决方案，而这时该组织对 它们的正确使用还没有达成共识。

让用例带动用户文档。
用户文档的目的是描述如何使用系统。每个用例都描述了参与者通过使用系统所采取的一系列动作。简而言之，用例包含从中开始编写问党用户稳当的信息。例如，可以使用“参加研习班”用例作为基础来编写系统用户文档的“如何参加研习班”一节。

让用例带动演示。
软件开发过程中的一部分是向项目资金管理者通报工作成果，因此有时需要提供演示。因为用例是从用户的角度编写的，它们包含了演示中对资金管理者可能希望听到的事物的有价值的深刻见解。换句话说，用例通常包含制定演示稿所需的逻辑。