统一建模语言（UML）：是面向对象分析的主要模型技术。
UML是很多种技术的综合体，包括类图、用例图、交互图（顺序图）、状态图和对象约束语言（OCL）。
本篇只介绍用例图与用例描述，首先认识一下UML定义的用例“在系统（或者子系统或者类）和外部对象的交互中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务。”【Rumbaugh2004】。换言之，每个用例是对相关场景的集合，这些场景是用户和系统之间的交互行为序列，帮助实现用户的目的。
用例图
用例模型就是以用例为基本单位建立的一个系统功能展示模型，它是系统所有用例的集合，以统一、图形化的方式展示系统的功能和行为特性。
1.基本元素
用例图的基本元素有4种：用例、参与者、关系和系统边界。
用例：水平的椭圆表示，是用例模型最重要的元素。
参与者：图示是一个小人，是发起或参与一个用例的外部用户以及其他软件系统等角色。代表同系统进行交互的角色，不是一个人或者工作职务；也不必非得是实际用户，也可以是一个组织、另一个系统、外部设备、时钟等。
关系：关联、泛化、包含、扩展。
1）关联：表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
2）泛化：一个用例可以被特别列举为一个或多个子用例，类似通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
3）包含：用来把一个较复杂用例所表示的功能分解成较小的步骤；基础用例可以看到包含用例，并依赖于包含用例的执行结果。但是二者不能访问对方的属性。
【箭头指向】：指向分解出来的功能用例（即被包含的用例）。
表示方法：虚线箭头+<<include>>字样。
4）扩展：指用例功能的延伸，把新行为插入到已有用例，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例（即被扩展的用例）
表示方法：虚线箭头+<<extend>>字样。
系统边界：一个矩形框表示，来显示系统的上下文环境，是指一个系统所包含的系统成分与系统外事物的分界线。
2.建立用例图步骤
a. 进行目标分析与确定解决方向。
进行目标分析，确定项目的目标，定义高层次解决方案的系统特性。
b. 寻找参与者。
根据a中确定的目标与系统特性，发现与系统功能相关的参与者。
c. 寻找用例。
可根据找到的参与者来寻找用例，每个参与者的一个目标（或任务）就是一个系统用例。参与的目标（或任务）必须与项目的目标与系统特性相一致，否则就不能为其建立用例。该步骤会将系统所有用例都表示在一个用例图中，即系统用例图。如下图所示：
d. 细化用例。
简单情况，c步骤就可以结束了；复杂系统开发中，往往因为系统用例图中用例粒度不适宜而需要进一步细化用例。用例粒度合适的判断标准：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。【Larman2002】
以上面系统用例图为例，“特价策略制定”、“赠送策略制定”两个用例的业务目的、发起源和过程基本相同的，仅仅业务数据不同的可以合并成一个用例；“会员管理”用例有两个明显不同的业务事件，可以被细化为“发展会员”和“礼品赠送”两个更细粒度的用例；“库存处理”有三个不同业务目标：出库、入库、库存分析。最终调整和细化后如下图：
细化时注意点：
1）不要将粒度细化得过小，不要将用例细化为单个操作，因为它们联合起来才能体现出业务价值；
2）不要将同一业务目标细化为不同用例；
3）不要将没有业务价值的内容作为用例，常见错误有“登录”（应描述为安全性质量需求）、“数据验证”（应描述为数据需求）、“连接数据库”（属于软件内部实现而不是需求）等。
用例描述
用文本的方式将用例的参与者、目标、场景等信息描述出来。
在描述用例时一定要注意：
1）围绕“交互”进行场景描述。
2）保持“规格说明”级别，尽可能不要涉及界面、按钮、方法等软件系统的内部构造机制。
3）正常流程中，注意交互序列的完整性，用户操作与系统反应都应该写出来。
参考文献
[1] 软件工程与计算（卷二） 北京：机械工程出版社
[2] 软件工程与计算（卷三） 北京：机械工程出版社
