下面是我这两天对用例的一小部分总结。。

UML unified modeling language 统一建模语言

1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。
UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。

用例建模是UML建模的一部分，它也是UML里最基础的部分。

用例建模的最主要功能就是用来表达系统的功能性需求或行为。

用例是从用户的观点对系统行为的描述。不是功能实现的过程，所以跟代码几乎没有关系。

用例图（user case)一般由三大部件：角色（actor),系统边界（用 System Boundary)，用例（user case)组成。

角色：与系统交互的人或事（比如与系统通过用例进行交互的硬件设备）

系统：在用例模型中，可以把"系统"当作实现各种功能的“黑匣子”,并不需要关系这写功能是如何实现的。

用例：用例代表一个完整的功能。

组成用例的各个元素之间的各种关系如下：
1.通用化也称为泛化或者继承(generalization),
2.依赖(dependency),
3.关联,
4.聚合(aggregation)，聚合属于关联的一种。

用例与用例之间有：
1.扩展，
2.使用，
3.组合（package）。

引入用例的目的
1.确定系统的功能，以及是否满足用户的需求。（调研员与客户确认了的需求）
2.为系统的开发，提供清晰的描述，保证软件的正确性。（系统开发）
3.为系统的验证打下基础。（系统测试）

如何快速创建用户实例
个人采用化整为零的方法，逐一确定角色，用例，然后建立系统边界。
1.确认角色
通过回答下面的问题可以确认系统的角色。
  1>使用系统的主要功能的是谁？（Main Actor）
  2>谁需要借助这个系统来完成日常工作的？
  3>谁负责维护，管理这个系统的？
  4>系统控制的硬件设备有那些？
  5>系统需不需要与其他系统进行交互？
  6>对系统结果感兴趣的人或事有哪些？

回答完上面的问题后，应该对系统角色有个比较清晰的了解了。

2.发现用例
  1>角色需要从系统中获取那些功能？角色需要做什么？
  2>角色需要操作系统中的某种信息么？
  3>系统中发生的事件需要通知用户么？这些功能是干什么的？
  4>系统新功能是将用户的工作简单化了，还是提高效率了？
  5>系统中当前的这种实现方法要解决的问题是什么？（也许是自动代替手工操作)

3.定义系统边界
  定义某一用例系统边界，需要遵循：该系统的全部用例的作用域都在当前系统的角色内。之外的不给予考虑

用例建模技巧

1.从参与者角度并以主动语态编写用例。
用例的目的是理解用户如何操作系统。

2.编写方案文本，而非功能需求。
用例是描述对参与者有价值的一系列行动，而不是描述功能特性。

3.用例只记载行为需求。
用例不是类规范，也不是数据规范，就类似抽象类的概念——只描述要实现的功能，而不做功能。只是一些概念性的东西。
例如：抽象一台电脑，他必须要能看电影，玩儿游戏，编辑文字。。。但抽象中我们只是提出他应该有这些东西，但我们不回去实现它。

4.始终如一的组织用例图。
垂直方向绘制：继承 和 扩展 的关联，在父类 或 基本用例下面绘制继承 或扩展用例。
水平方向绘制：包含（include）关联。

5.不要忘记系统最参与者动作的回应。
用例既要描述参与者如何跟系统交互，也要描述系统如何响应这些交互的。
例如：用户点击注册提交按钮，系统会作出验证注册信息，数据正确则发出激活信件，或者进入用户个人信息管理页面等等的响应方式。

6.备选行动过程。
参与者操作系统如果一切顺利的话，使用的将是基本行动过程，但我们也应该尽可能的引入备选过程，描述潜在的使用错误和逻辑错误和异常。

关联：
*：许多，more，many。
..：或，or。
1..*：1个或者多个。