UML 用例简介
静态视图有助于分析员和客户交流
动态视图，有助于系统分析与开发小组交流，并且能帮助开发组编制程序
客户和开发组是系统风险承担人的重要组成部分。然而不应该遗漏另一个同样重要的组成部分——用户。
不论是静态视图还是动态视图都不能从用户的观点说明系统所具有的行为
从用户的观点出发对系统建立模型是用例要完成的任务
什么是用例
用例分析（use case analysis）
用户对系统的使用方式决定了系统如何设计和构造
用例是能够帮助分析员和用户确定系统使用情况的 UML 组件，一组用例就是从用户的角度出发对如何使用系统的描述。
可以认为用例是系统的一组使用场景
每个场景描述了一个事件的序列
每个序列是由一个人、另一个系统、一台硬件设备或者某段时间的流逝所发起
这些发起事件序列的实体叫做参与者（actor）
事件序列的结果是由发起这个序列的参与者或者另一个参与者对系统某种形式的使用所引起的
用例的重要性
类图是一种能够帮助客户以自己的观点考察系统的好的方法
用例是一个能促进系统可能的用户以他们自己的观点看待系统的优秀工具
包含用例
消除用例中的重复步骤
从各个步骤序列中抽取出公共步骤形成一个每个用例都要使用的附加用例
用例的复用技术被称作包含用例（include a use case）
UML 的早期版本将包含（include）用例称为使用（use）用例
使用包含（include）这个术语有两个优点：
首先，含义明确，一个用例中的执行步骤“包含”了另一个用例中的执行步骤
第二，可以避免和通常的“使用”相混淆
扩展用例
通过对已有用例增加一些额外的步骤来建立新的用例
新用例是对原用例的扩展，这种技术叫做扩展用例（extend a use case）
开始用例分析
在进行用例分析之前必须遵循一套规程
首先从与客户交谈开始，这样可以分析得出系统的初步类图，在这个过程中可以让你对系统有个概念性认识并逐步熟悉将要使用的术语
与用户交谈时，要向他们询问他们准备如何使用系统的所有事情，位设计做准备，根据他们的回答就能得到一组候选用例
要简要地描述出这些用例，导出一个参与者列表，这些参与者或者发起了候选用例或者从候选用例中获益
在开发过程中不断发现新的用例
它们有助于设计系统的用户界面，还能帮助开发者做出编程中的决策，并且用例也是对新构造出的系统进行测试的基础
注：本笔记出自《UML 基础、案例与应用》一书的 第六章 介绍用例
微信中搜索 “码农UP2U” 关注我的公众号吧！！！
