用例图的基本概念及其使用方式(包含案例)

news2024/9/24 5:32:13

一、引言

用例(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父用例)。例如，

四、总结

在大学读书的时候我们平时画的都是简单、普通的用例图，时常没有理解拓展关系和包含关系之间的联系和区别。现在再重新温习了用例图的知识，有一种温故知新的感觉。扩展关系看上去像一个程序分支，而包含关系看上去像一个函数调用另一个函数。我感觉如果能够将用例图画好，很多软件需求的业务逻辑都可以捋得很顺。希望博客能够帮助到你，不懂的地方咱们评论区见。

备注：该博客参考了书籍《基于用例的面向方面软件开发》，不懂的同学也可以自行下载、阅读。