用例图元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。
包括：角色之间的关系、用例之间的关系、用例和角色之间的关系。
角色之间的关系由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例之间的关系：(1)包含关系:基本用例的行为包含了另一个用例的行为。
基本用例描述在多个用例中都有的公共行为。
包含关系本质上是比较特殊的依赖关系。
它比一般的依赖关系多了一些语义。
在包含关系中箭头的方向是从基本用例到包含用例。
简单的理解就是用例可以包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分。
(2)泛化关系：代表一般于特殊的关系。
它的意思和面向对象程序设计中的继承的概念是类似的。
不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。
在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
泛化（Generalization）在面向对象的技术中无处不在，下图给出了一个使用泛化的用例图：在用例图中，角色和用例都能够泛化。
角色的泛化/继承很容易理解，因为角色本来就是类（Class），它是一种版型（stereotype）为Actor的类，所以角色的继承直观而自然。
但是用例的继承实际上分为两种情况，并不是简单的使用泛化，而是使用扩展（extended）和包含（include）两种泛化的特例。
扩展用于子用例的动作步骤基本上和父用例的动作步骤相同，只是增加了另外的一些步骤的情况下。
包含用于子用例包含了所有父用例的动作，它将父用例作为了自己的一个大步骤，子用例常常包含一个以上的父用例。
(3)扩展关系：扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
与包含关系一样，扩展关系也是依赖关系的版型。
在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。
在以下几种情况下，可使用扩展用例：a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；b.表明只在特定条件（如例外条件）下才执行的分支流；c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。
所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。
图中的第二个例子中，在还书的过程中，只有在例外条件（读者遗失书籍）的情况下，才会执行赔偿遗失书籍的分支流。
用例与角色之间的关系用例由角色发起，一个用例必须至少与一个执行者关联。
如何画UML用例图Tag: UML , 包含 , 用例 , 用例图 , 用例描述 , 统一建模 , 范化 | Author: bts |UML用例图是非常有用的一种图，在需求分析中，可以让人们从繁重的文档中解脱出来，并且促使人们在做需求时能够更加准确、直观的表现自己的意思。
常用的语言文字往往是不能将一种事物表达得秀清晰，这时候就需要用其它的方式来进行表达，用例图就是其中一种很好的方法，当然用例图不仅仅只是做为需求分析专用，他强大的应用性还可以用于其它很多地方，这里就不详细说明了。
画UML的工具有很多，个人首推IBM的ROSE，建议大家用这款工具来画例图，如果有时间，我会写一篇初级教程。
接下来还是介绍一下用例图吧。
1.首先简单介绍一下UML.UML（统一建模语言，Unified Modeling Language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。
它融入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
在系统分析阶段，我们一般用UML来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。
其实简单的理解，也是个人的理解，UML的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。
2.用例建模是UML建模的一部分，它也是UML里最基础的部分。
用例建模的最主要功能就是用来表达系统的功能性需求或行为。
用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
3.用例图的说明这里得说明一下参与者.参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。
还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。
参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
如下图接下来就是用例了，用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
这是UML对用例的正式定义，初学者可能有点难懂。
我们可以这样去理解，用例是参与者想要系统做的事情。
对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。
用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
如下图系统边界是用来表示正在建模系统的边界。
边界内表示系统的组成部分，边界外表示系统外部。
系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。
因为系统边界的作用有时候不是很明显。
（在画图时可省略）箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。
箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
4.接下来就是要说说用例描述了，可以说好的用例描述直接决定工程的质量。
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。
用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。
下面说说各个部分的意思：简要描述：对用例的角色、目的的简要描述；前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；异常事件流：表示发生了某些非正常的事情所要执行的流程；后置条件：用例一旦执行后系统所处的状态；话说最近接触到了不少实用的新知识，今天先来说下对用例图的最新理解吧，改明儿再好好的写一篇关于RUP的文章。
虽然从07年就开始接触用例图这一概念，但确从来没有写过用例文本，在以前做过的项目中更多的是对着用例图写概要设计报告或其它文档。
曾经也疑惑过既然公司引入了UML用例图，用例描述作为用例图中最关键的存在，为什么在项目中确不需要写用例文本，反而用其它形式的文档来代替。
现在我大概明白了一些，原因很可能是在前公司中没有人知道怎么画出精确的用例图，怎样的用例文本才是合格的。
所以在没有标准的情况下，很难把UML 的一套给推行起来，只能取其中的一部分进行应用。
首先看用例图，以前在画的时候，只要表示出了大概的意思，那么就算是“合格”的，而且经常被告知用例图没有绝对的对与错。
以至于让我一直认为用例图的画法就真的是那么的灵活。
但事实是我错了，用例图还是有其严格的一面。
新手最容易犯的错误之一，就是把大大小小的功能项都列为了用例，这点在我之前用例中出现得很多，比如把类似“删除”，“修改”这样的东西都画成用例。
事实上，用例主要描述的事有意义的行为。
就是“有意义”这三个字，决定了并不是所有的行为都必须画成用例的，这就为我们在选择用例的时候，提供了一个很好的参考依据，告诉我们什么时候该点到为止。
之前犯过的错误还有很多，比如没有对主要角色与辅助角色之间进行细节上的区分。
现在看起来这些都是一些在概念上的细节区分，但在UML上，就是这节细节上的准确区分与把握，才决定着你的用例图在整个项目应用中是不是能发挥出应用的效果。
比如我现在使用的一套基于RUP模式的EA管理系统，只用将这些项都关注到了，它生成的报告才有很实用的价值，才能起到关键的控制作用。
再说说用例文本，那简直比八股文还要八股，很多人只知道按照事件流来写，那么在描写的时候难道只要把事件写清楚了就对了么？答案显然是错误的。
真正的用例文本，在写的时候有其严格的“规矩”，那就是其中不能涉及任何关于“界面”的字眼，如“用户可以点击XX按钮，在弹出界面中……”，这就是非常大的错误，像“按钮”，“弹出界面”这种能够反映出界面的词语，是绝对不允许出现在用例文本中的。
说用例文本很八股，还有一个原因就是他更多的时候描述的是人与系统之间的交互，所以在写的时候经常会出现这样的描述文本：事件流一.基本流：1. 用户进行文章列表时，用列开始。
2.系统提供所选文章的列表目录，并自动排序与分页。
3.用例点击列表中的文章标题。
4. 系统显示所选文章的详细内容。
…….这就是用例文本了，如果你还没什么感觉的话，那么请你认认真真的写上一上午这样的文本，相信你也会体会得更多的。
也许，之前我真的并不懂什么是用例图吧，但现在，大门既然已向我敞开，岂能轻易放过！一个画用例图的实例Tag: 例子 , 信息 , 学生 , 实例 , 家教 , 用例 , 用例图 , 角色 | Author: bts |这里用一个家教网站来简单的分析用例图的画法和用例描述的写法。
这个网站我用UML完整的分析一下，以下我提取了用例图和用例描述的部分。
这个家教网站分为前台客户系统和后台管理系统。
前台客户系统的用例图如下：后台管理系统用例图如下：对于用例描述，这里只列了后台管理系统中的网站公告发布这个用例的描述。
如下：用例名称：网站公告发布用例标识号：202参与者：负责人简要说明：负责人用来填写和修改家教网站首页的公告，公告最终显示在家教网站的首页上。
基本事件流:1．负责人鼠标点击“修改公告”按钮2．系统出现一个文本框，显示着原来的公告内容3．负责人可以在文本框上修改公告，也可以完全删除，重新写新的公告4．负责人编辑完文本框，按“提交”按钮，首页公告就被修改5．用例终止其他事件流A1：在按“提交”按钮之前，负责人随时可以按“返回”按钮，文本框的任何修改内容都不会影响网站首页的公告异常事件流：1．提示错误信息，负责人确认2．返回到管理系统主页面后置条件：网站首页的公告信息被修改注释：无。
