UML笔记(2):用例图、User Case View
产生背景：需求分析是软件开发的第一步，如果走的不好，那后果不堪设想，但要做好这一步，其实是很难得，因为需求分析往往是两个互不相干领域的人沟通的产物，由于领域不同，他们很少有“共同语言”。对于开发人员来说，如何清晰的获取用户的需求，从而避免以后的返工（和加班），是个难题。同时，对于大的项目来说，定义各期的开发边界，从而避免开发费用纠纷，也是个难题。对于用户来说，按时获得自己想要的东西也是个难题。
这些难题的根本原因是：开发人员和最终用户处于两种“语系”中，他们无法很好的沟通，开发人员总是会先想到如何去实现，实现是否困难；而最终用户往往先想到的是我想要什么东西，要花多少钱，可见，他们的沟通往往是没有什么基础可循的，牛头不对马嘴，这就为以后的加班和费用纠纷埋下了伏笔。
为了解决这些问题，用例图应运而生，它生来就是开发人员和最终用户的“共同语言”，双方都能够用它来表达意愿，而且对方都可以很容易的理解。
发展历程：
1986年，Ivar Jacobson博士在一篇文章中提到了用例的概念，之后Alistair Cockburn写了一本书：《编写有效用例》，该书是定义用例和书写用例最重要、最有影响力也是最全面的书籍。
概念：
用例图是这样一种视图，它清晰的描述了用户的各种需求，向用户展示了其所需要的系统的整体结构及其边界。
要素说明：
用例图包含三个要素：活动者、用例、关系。
活动者：
活动者是指向软件系统发出请求，或享受系统服务的事物。
活动者可以是人，也可以是外部系统。
活动者的标记：
用例：
用例是指系统的一个功能模块。
用例的命名一般用动宾结构的词。
用例的标记是：
关系：
用例图中的关系有四种：关联、泛化、包含、扩展
关联：
关联用于描述活动者与用例之间的交互。
关联的标记如下：
例如：
泛化：
泛化用于表达父类与子类的关系，与编程中的继承含义一致。
泛化的标记如下：
例如：
包含：
包含是指一个用例的执行必须要用到另一个用例。
包含的标号如下：
例如：
扩展：
扩展用于描述功能的可选功能。
扩展的标记如下：
例如：
画用例图的一般步骤：
1. 确定系统边界，找出所有的活动者。
2. 从抽象到具体，对系统进行细化，确定各个功能点
3. 对功能点进行优化，提前共通功能点和扩展功能点，
4. 确认活动者与功能点的关系。
作用：
1. 便于用户与开发人员沟通
2. 便于对系统复杂度、开发周期等的评估。
3. 便于新员工对系统整体结构的了解。
4. 便于测试人员开展ST。
注意事项：
用例图中要尽量避免使用编程相关的技术术语，而应该使用最终用户或领域专家的语言。
用例图应该有最终用户和开发人员共同完成。（或者至少需要经过双方确认。）
