重构机房收费系统需求分析之用例图

         上篇博客和大家分享了，机房收费系统的数据库是怎样思考和构建出来的，有了数据库就要考虑整个系统的架构，而架构之前必需要进行需求分析，怎样将需求分析的结果展示出来，是个问题，当然你能够写文档，可是唯独文字说明是不够的，如此一来，UML的Use Case Diagram就显得十分重要了。

         本次我们主要谈机房收费系统的用例图，我们先来了解一下用例图的基础知识，一个是方便大家阅读，还有一个就是帮大家复习一下用例图的知识，由于长时间不用，有的人就会淡忘，比方本人。

         所谓的用例图，就是由主角、用例以及它们之间的关系构成的用于描写叙述系统功能的静态视图。

         用例图主要由參与者（Actor）、用例（Use Case）、系统边界和箭头组成。

         用例图中元素的关系主要实用例之间的关系、角色之间的关系以及用例和角色之间的关系。

         角色之间的关系类似于类之间的关系，主要是泛化关系。用例之间的关系主要有include、generalize、extend三种关系。当中generalize就是泛化关系，类似于面向对象中的继承，这里就不多说了。我们主要来辨析一下包括和扩展这两个easy混淆的关系。

         所谓包括是指基本用例的行为包括了还有一个用例的行为。简单理解就是用例能够包括其它用例具有的行为，并把它所具有的用例的行为作为自身行为的一部分。

         而扩展是指对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例的參与，也能够完毕一个完整的功能操作。扩展关系中的基本用例中存在一个扩展点，扩展用例仅仅能在扩展点上添加新的行为和含义。

         以下我们结合机房收费系统来加深理解一下扩展和包括这两种关系。

        

         在这个系统中，用户有非常多的查询功能，我们作为一个用例抽象出来，然而在查询页面还有导出查询结果的功能，这样又一个用例被抽象出来，那么这两个用例之间应该是什么关系呢？我们来分析一下，对于查询而言能不能导出查询结果和查询本身并没有不论什么关系，换句话说这两个操作相对独立，导出是对查询功能的扩展，当然我们还能够加入打印的功能。因此这两个用例之间是扩展关系。

         而对于用户管理功能来说，AddUser和DeleteUser是用户管理功能的组成部分，假设没有了加入和删除用户这两个子用例，那么用户管理这个用例就变成了空壳，没有了不论什么意义。用户管理和其子用例是相互依存的，具有非常强的依赖关系，因此他们之间是包括的关系。

         以上是我个人对用例之间的扩展和包括关系的理解，如有不妥之处，还请知情人指教。