一、引言
用例(Use Case)，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。此概念“用例”的提出者为Ivar Jacobson。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
用例图(Use Case Diagram)，描述用例的图形。用例图包含一组用例。每一用例用椭圆表示，放置在矩形框中；矩形框表示整个系统。矩形框外画如图所示的小人，表示参与者。参与者不一定是人，可以是其他软件、硬件等等。某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。
之所以写这一份博客是因为网上有许多人都在博客中总结，但是，总结得并不是十分到位，同时也没有达成统一的标准(例如，参与者与用例之间的关系，一些博客用直线加箭头描述，而另一些箭头用直线描述，其实这是两种规范，前者是Alistair Cockburn风格、在书籍Writing Effective Use Cases中被使用，而后者是原始的风格。所以本篇博客浅浅记录一下基本的概念，以及正确的使用案例，方便自己日后的开发工作更高效、正确地开展。
二、用例图的基本概念及其正确使用方式
| 图标 | 描述 | 说明 |
 |
软件系统 | 用于框选用例，也有些为了方便没画的，因为用例实在太多。比较规范的画法是需要加上。 |
 |
参与者 | 参与者名称一般写在小人下面。 |
 |
参与者与用例的关系 | 有些没有箭头，有些有箭头(指向用例)，但都是正确的。 |
 |
用例 | 用例名称可写在椭圆内或椭圆下面。 |
 |
用例扩展关系 | 虚直线+箭头+<<extend>> |
 |
用例包含关系 | 虚直线+箭头+<<include>> |
 |
用例泛化关系 | 直线+小等腰三角形 |
三、用例图案例
1、普通用例图：酒店管理系统。这里简单地说明一下，参与者一般不只有一个。一个用例可以理解为一个功能需求。这上面的图存在两个参与者，分别是Customer(顾客)和Hotel Counter Staff(酒店柜台员工)；存在三个功能，分别是Reserve Room(预订房间)、Check In Customer(办理入住)和Check Out Customer(结账)。
2、扩展关系。扩展用例可以在原有用例中添加新的行为。用例技术能够简洁地把新的行为描述从基用例中完全独立出来，因而，基用例不会受到新行为细讲的影响。例如，下面给出了一个简单的扩展用例，
这里对上面的这个用例图进行一下说明。关系关系，一定是某某和某某之间的二者关系。而这里值得注意的是，Handle Waiting List是Reserve Room的扩展(同时注意看箭头，谁箭头指出去，谁就是扩展)。其中，执行的时候会在Reserve Room里面的某个步骤(更细粒度地看)调用Handle Waiting List，然后当Handle Waiting List执行完毕时，整体也就执行完毕了。大概的执行步骤为：
3、包含关系。包含关系是最好理解的。两个用例A和B，要么是A包含B，或者是B包含A，二者的区别在于谁指向谁。比如下面这个例子，
这个例子是Reserve Room和Check In Customer这两个用例同时包含Check Room Details。这里请注意一下箭头的方向哈。然后包含关系的执行步骤大概是这样子的，
大概绕了一个圈。(上面这个图有个小error，就是Details没带s，书本印刷错误)
4、泛化关系。用例泛化是对用例模型结构化的另一种技术。它与类的泛化含义相同，意味着用例之间存在“is-a-kind-of”的关系(子用例is-a-kind-of父用例)。例如，
四、总结
在大学读书的时候我们平时画的都是简单、普通的用例图，时常没有理解拓展关系和包含关系之间的联系和区别。现在再重新温习了用例图的知识，有一种温故知新的感觉。扩展关系看上去像一个程序分支，而包含关系看上去像一个函数调用另一个函数。我感觉如果能够将用例图画好，很多软件需求的业务逻辑都可以捋得很顺。希望博客能够帮助到你，不懂的地方咱们评论区见。
备注：该博客参考了书籍《基于用例的面向方面软件开发》，不懂的同学也可以自行下载、阅读。
五、参考资料
1、维基百科
2、百度百科
3、Ivar Jacobson、Pan-Wei Ng，基于用例的面向方面软件开发(徐锋译)