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