复建机房收费系统需求分析之用例图
上篇博客和大家分享了，机房收费系统的数据库是如何思考和构建出来的，有了数据库就要考虑整个系统的架构，而架构之前必须要进行需求分析，如何将需求分析的结果展示出来，是个问题，当然你可以写文档，但是仅仅有文字说明是不够的，如此一来，UML的Use Case Diagram就显得十分重要了。
本次我们主要谈机房收费系统的用例图，我们先来了解一下用例图的基础知识，一个是方便大家阅读，另一个就是帮大家复习一下用例图的知识，因为长时间不用，有的人就会淡忘，比如本人。
所谓的用例图，就是由主角、用例以及它们之间的关系构成的用于描述系统功能的静态视图。
用例图主要由参与者（Actor）、用例（Use Case）、系统边界和箭头组成。
用例图中元素的关系主要有用例之间的关系、角色之间的关系以及用例和角色之间的关系。
角色之间的关系类似于类之间的关系，主要是泛化关系。用例之间的关系主要有include、generalize、extend三种关系。其中generalize就是泛化关系，类似于面向对象中的继承，这里就不多说了。我们主要来辨析一下包含和扩展这两个容易混淆的关系。
所谓包含是指基本用例的行为包含了另一个用例的行为。简单理解就是用例可以包含其他用例具有的行为，并把它所具有的用例的行为作为自身行为的一部分。
而扩展是指对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能操作。扩展关系中的基本用例中存在一个扩展点，扩展用例只能在扩展点上增加新的行为和含义。
下面我们结合机房收费系统来加深理解一下扩展和包含这两种关系。
在这个系统中，用户有很多的查询功能，我们作为一个用例抽象出来，然而在查询页面还有导出查询结果的功能，这样又一个用例被抽象出来，那么这两个用例之间应该是什么关系呢？我们来分析一下，对于查询而言能不能导出查询结果和查询本身并没有任何关系，换句话说这两个操作相对独立，导出是对查询功能的扩展，当然我们还可以添加打印的功能。因此这两个用例之间是扩展关系。
而对于用户管理功能来说，AddUser和DeleteUser是用户管理功能的组成部分，如果没有了添加和删除用户这两个子用例，那么用户管理这个用例就变成了空壳，没有了任何意义。用户管理和其子用例是相互依存的，具有很强的依赖关系，因此他们之间是包含的关系。
以上是我个人对用例之间的扩展和包含关系的理解，如有不妥之处，还请知情人不吝赐教。