用例建模简介
用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。用例图重点描述用户需求。 它描述需求、用户和主要组件之间的关系。 它不会详细描述用户需求；在可链接到每个用例的其他关系图或文档中可详细描述这些需求。用例图是UML的九个图中较为重要和常用的一种图。常常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。简单的来说，用例图是描述系统的外部视图，为了搞清某个项目的大概需求，我们往往要问两个问题，
1． 这个系统有什么用？有哪些人参与?
2． 这些人通过这个系统能做些什么事？
通过这两个问题，一般就能比较清楚地表达系统的需求了，用例图就是用来回答这两个问题的，它能从比较清晰的角度来表达系统的需求，而且不涉及到技术用语。
用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
1． 参与者(Actor)
在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想想我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
2． 用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
3．系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
4．箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
一：用例之间的关系
1角色的继承
2： 用例的包含(Include) 包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用例(Base) 指向被包含用例(Inclusion)
在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：
A） 第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。
B） 第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。
3: 扩展关系 在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension) ，原有的用例叫做基础用例(Base) ，从扩展用例到基础用例的关系就是扩展关系。一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。
二． 用例描述
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
下面是一个用例描述模板：
|
编号 |
[用例编号,如 UC-01] |
名称 |
[用例名称,即用例图中用例的描述] |
|
执行者 |
[用户，角色等] |
|
|
|
描述 |
[简单的描述本用例，重点说明执行者的目标] |
||
|
前置条件 |
[列出执行本用例前必须存在的系统状态，如：必须录入什么数据，须选实现其他什么用例等。注意除非情况特殊，不要写类似”登录系统”等每个用例几乎都需要具备的前置条件。] |
||
|
基本流程 |
[说明在“正常”的情况下，最常用的流程，通常是执行者和系统之间交互的文字描述] |
||
|
结束状态 |
[列出在“正常”结束的情况下的用例的结果] |
||
|
可选流程1 |
[说明 和基本流程不同的其他可能的流程] |
||
|
可选流程N |
[说明 和基本流程不同的其他可能的流程] |
||
|
异常流程 |
[说明出现错误或其他异常情况时和基本流程的不同之处] |
||
|
说明 |
[对本用例的补充说明，如：业务概念，业务规则等] |
||
三． 用例图和用例描述设计实例
这里以之前的那个考勤系统为例来简单分析一个用例图的画法。
经分析系统中涉及的角色有如下： 普通员工、行政部员工、财务部员工、部门经理、总经理。
角色的继承关系如下：
普通员工的用例：
下面是关于普通员工的”提出请假申请”的用例描述
|
编号 |
1.1 |
名称 |
提出请假申请 |
|
执行者 |
普通员工 |
|
|
|
描述 |
普通员工录入请假的信息，能成功提出请假申请 |
||
|
前置条件 |
无 |
||
|
基本流程 |
1: j显示请假申请表单。 2：填写请申请单，选择请假类型 3：提交申请 4:显示成功提交的申请信息并返回列表。 |
||
|
结束状态 |
系统保存请假申请数据，并提示成功提交申请的信息 |
||
|
可选流程1 |
3：取消请假申请 4：返回列表 |
||
|
异常流程 |
2：填写请申请单，选择请假类型为”年假” 3：提交申请 4：提示可休年假不足，显示相应信息。 5： 修改请假申请单，或取消请假申请. |
||
|
说明 |
请假申请单有以下内容：申请者，开始时间，结束时间，请假事由，请假类别。 申请假默认为当前的用户，不可修改。 请假的类别为：事假，病假，婚 嫁，产假，年假，只能而且必须选其一 |
||
其它的用述描述不再赘述。
以上内容来自于 【火球UML大战需求分析】中，作为学习笔记记录一下