赞
踩
目录
简单记录一下,期末关于电费管理系统的UML建模课程设计。
参考“4+1”视图模型,利用UML工具对所选定系统进行视图建模:
1、业务建模主要操作步骤:识别业务参与者、识别业务用例、绘制活动图等)。
2、用例建模主要操作步骤:分析需求、识别参与者、识别用例、绘制用例图、编写用例文档、重构用例模型等。
3、用例分析主要操作步骤:分析用例、完善用例文档、识别分析类、绘制顺序图、绘制类图等。
4、根据面向对象的设计原则和常用设计模式对设计进行重构并进行总结。
5、完成大作业设计报告。
电费管理系统,在管理方面节省了时间,为部门节省了大量的人力和物力;并且方便业主对自己相关信息的了解,真正做到电费管理的透明化、高效性、方便性,适应了当今社会高效、便捷的要求。根据本系统的功能要求,其功能模块划分如图2.1所示
图2.1 电力公司收费管理系统基本功能
用户可以选择线下去营业厅缴费,也可以选择在网上进行缴费。
图2.2 缴费功能图
具体功能如下:
①线下缴费: 根据用户提供的电费卡,查询用户的用电情况,包括当月的,历史欠费等,现场收取电费。
②线上缴费: 用户在网上核对用电信息后,通过微信小程序,或移动APP进行缴费。
查询功能可以通过系统查询用户的用电量、缴费记录、用户个人信息、操作记录查询。
图2.3 查询功能图
具体功能如下:
①用电查询:查询用户的用电信息。
②缴费记录查询: 查询用户的所有历史缴费时间、地点、金额。
③用户个人信息查询:查询用户的基本信息,包括户名、户号、表编号、地址、
开户行、帐号等。
④操作记录查询:按时间查询系统操作情况,即管理员操作痕迹记录。
作为主要对系统数据修改的功能模块,包括用户的基本信息、电表的基本信息,以及电费用电量等信息的录入。
图2.4 管理功能图
具体功能如下:
①管理用户信息: 维护用户信息包括增加、删除用户操作。
②管理电表信息: 电表信息主要有电表的规格、出厂编号等。
③管理电费信息: 主要功能是用户电费指数的录入,电费价格的修改等。
系统管理主要针对收费系统的数据和操作安全的一些操作管理。
图2.5 系统管理图
具体功能如下:
①数据备份: 设定系统自动备份的时间间隔,把数据备份到指定位置。
②数据恢复:在数据被破坏的情况下,将系统数据恢复到上一个安全点。
简要分析业务参与者,如表3-1所示
表3-1 电费管理系统业务参与者说明
参与者名称 | 描述 | 同义词 |
用户 | 电量使用者,缴费者 | 户主 |
管理员 | 对用户信息,用电信息,电表信息进行管理的人 | 操作员 |
抄表员 | 电表安装,电量表抄录人员 | 抄录员 |
用电政策 | 调整电价的依据 | 用电条规 |
支付系统 | 为该系统提供支付接口的外部系统 | 微信,银行,支付宝 |
图3.1 用户管理个人信息业务流程的活动图
图3.2 用户查询电费信息的业务流程图
图3.3 用户缴纳电费业务流程的活动图
图3.4 抄表员安装电表业务流程活动图
图3.5 抄表员抄录用电信息业务流程的活动图
图3.6 管理员管理用户信息业务流程的活动图
图3.7 管理员管理电表信息业务流程的活动图
图3.8 管理员管理电费信息业务流程活动图
图3.9 管理员进行系统维护业务流程的活动图
1.寻找业务改进点
从流程控制、复杂业务逻辑、使用业务对象、自动化业务四个方面寻找业务的改进点
2.定义项目远景
本系统是电费管理系统,远景说明有如下几点:
①用户能够正常登录系统。
②用户能够管理个人信息,包括户名,表编号,地址等。
③用户能够进行用电记录查询,电费缴纳查询。
④管理员能够管理用户信息。
⑤管理员能够管理用电信息,包括用电记录,缴费记录。
⑥管理员能够对系统进行维护,数据备份与恢复。
3.导出系统需求
结合业务改进点和项目远景导出系统需求,用户查询信息的需求、管理信息的需求、缴费需求,管理员的查询需求,管理需求,维护系统需求。
从原始需求中获取系统的参与者,如表4-1所示
表4-1 获取系统参与者
抽取角度 | 外部事物种类 | 使用目标系统的内容 | 参与者 |
相关用户 | 系统后台操作的员工 | 管理用户信息,用电记录、缴费记录 | 管理员 |
实地操作的员工 | 电表安装,维修,抄录 | 抄表员 | |
系统的使用者 | 查询用电记录,缴费 | 用户 | |
其它外部事物 | 支付系统 | 缴费的外部接口 | 支付系统 |
时间 | 系统定期使用 | 时间 | |
政策法规 | 电费价格调整的依据 | 政策法规 |
从表4-1中可以看出,该系统存在6中参与者,通过建模工具绘制参与者视图如4.1所示
图4.1 “电费管理系统”参与者视图
从参与者使用系统的职责入手来定义用例,如表4-2所示
表4-2 从参与者的角度获取用例
参与者 | 主要工作 | 是否使用系统 | 用例 |
管理员 | 对用户信息进行录入、修改 | 是 | 管理用户信息 |
管理员 | 对电表信息进行录入、修改 | 是 | 管理电表信息 |
管理员 | 查询用户的用电记录 | 是 | 查询用电记录 |
管理员 | 查询用户的缴费记录,时间,平台、金额 | 是 | 查询缴费记录 |
管理员 | 依据政策法规进行电费价格调整 | 是 | 电费价格调整 |
管理员 | 系统的数据备份、数据恢复 | 是 | 系统维护 |
抄表员 | 为用户进行电表安装 | 是 | 电表安装 |
抄表员 | 每月记录用户的用电情况 | 是 | 用电录入 |
用户 | 对个人信息进行处理 | 是 | 管理个人信息 |
用户 | 查询电力使用情况 | 是 | 查询用电信息 |
用户 | 对电费进行缴纳 | 是 | 缴纳电费 |
支付系统 | 用户进行支付的一种外部接口 | 是 | 电费缴纳 |
时间 | 定期导出操作数据记录 | 是 | 导出数据记录 |
其它辅助用例 | 系统区分不同的账号身份 | 是 | 登录 |
图4.2 “电费管理系统”顶层用例图
“管理用户信息”用例文档 | |
用例名 | 管理用户信息 |
简要描述 | 管理者通过系统对用户信息进行录入、修改 |
参与者 | 管理员 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 用户个人信息是否存在于系统中 |
后置条件 | 操作后的用户信息保存在系统中 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: 用户信息包括(户名、户号、表编号、地址等) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“管理电表信息”用例文档 | |
用例名 | 管理电表信息 |
简要描述 | 管理员录入、修改电表信息 |
参与者 | 管理员 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 系统中是否存在电表信息 |
后置条件 | 操作后系统中将保存电表信息 |
基本事件流: (1)管理员通过系统查询电表信息 (2)管理员录入电表信息 (3)管理员修改电表信息 (4)电表信息保存在系统中 | |
备选事件流:
(3)电表信息保存失败 | |
补充约束-数据需求: 电表信息包括(电表规格、出厂编号、电表安装地址等) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“查询用电记录”用例文档 | |
用例名 | 查询用电记录 |
简要描述 | 根据提供选择的数据项进行组合或模糊查询,显示用户的用电信息 |
参与者 | 管理员 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 用户在系统中注册了信息,相关电表信息已保存在系统中 |
后置条件 | 查询操作数据被保存 |
基本事件流:
| |
备选事件流: (1)获取数据失败 | |
补充约束-数据需求: 用电信息包括(用电时间,用电额度等) | |
待解决的问题:(暂无) | |
相关图: |
“查询缴费记录”用例文档 | |
用例名 | 查询缴费记录 |
简要描述 | 查询单个用户的所有历史缴费情况 |
参与者 | 管理员 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 用户信息保存在系统中 |
后置条件 | 查询操作数据被保存 |
基本事件流: (1)管理员选择数据项查询用户缴费信息 (2)获得缴费情况 | |
备选事件流: (1)获取数据失败 | |
补充约束-数据需求: 缴费记录包括(缴费时间、缴费平台、缴费金额) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“电费价格调整”用例文档 | |
用例名 | 电费价格调整 |
简要描述 | 管理员依据政策法规调节电力价格 |
参与者 | 管理员 |
涉众 | 政策法规 |
相关用例 | 无 |
前置条件 | 系统中存在电费信息,有相关政策法规 |
后置条件 | 调整后的电力价格将告知用户 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: 电费价格信息包括(价格梯度等) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“系统维护”用例文档 | |
用例名 | 系统维护 |
简要描述 | 管理员对系统的数据进行备份、恢复 |
参与者 | 管理员 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 系统中存在数据 |
后置条件 | 操作后的数据将被保存 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: (暂无) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“电表安装”用例文档 | |
用例名 | 电表安装 |
简要描述 | 抄表员通过系统获取用户安装电表的需求后,为户主进行电表安装 |
参与者 | 抄表员 |
涉众 | 用户 |
相关用例 | 无 |
前置条件 | 用户在系统中提出安装电表需求 |
后置条件 | 电表信息被录入系统 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: 电表信息包括(电表的规格、出厂编号、安装地址等) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“用电录入”用例文档 | |
用例名 | 用电录入 |
简要描述 | 抄表员每月定期前往用户住址进行用电情况记录 |
参与者 | 抄表员 |
涉众 | 用户 |
相关用例 | 无 |
前置条件 | 用户信息、电表信息保存在系统中 |
后置条件 | 用电情况录入系统 |
基本事件流:
| |
备选事件流: (1)抄表员联系不到户主 | |
补充约束-数据需求: 用电信息包括(用电额度、用电时间) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“管理个人信息”用例文档 | |
用例名 | 管理个人信息 |
简要描述 | 用户对个人信息进行查询,修改操作 |
参与者 | 用户 |
涉众 | 无 |
相关用例 | 无 |
前置条件 | 用户信息已保存在系统中 |
后置条件 | 操作后的数据保存在系统中 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: 用户信息包括(户名、户号、表编号、地址等) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
“缴纳电费”用例文档 | |
用例名 | 缴纳电费 |
简要描述 | 用户了解用电情况后缴纳相应的电费 |
参与者 | 用户 |
涉众 | 支付系统 |
相关用例 | 无 |
前置条件 | 用户的用电记录保存在系统中 |
后置条件 | 缴费情况保存在系统中 |
基本事件流:
| |
备选事件流:
| |
补充约束-数据需求: 缴费信息包括(缴费时间、地点、金额) | |
待解决的问题:(暂无) | |
相关图:(暂无) |
1.用例分包
按照参与者将用例分包,如图所示4.3所示
图4.3 “电费管理系统”顶层分包用例图
2.用例分级
用例 | 优先级 | 分级原因 |
管理用户信息 | 高 | 项目主要远景,代表系统核心业务流程 |
管理电表信息 | 高 | 项目主要远景,代表系统核心业务流程 |
用电录入 | 高 | 项目主要远景,代表系统核心业务流程 |
缴纳电费 | 高 | 项目主要远景,代表系统核心业务流程 |
系统维护 | 高 | 项目主要远景,代表系统核心业务流程 |
电表安装 | 高 | 项目主要远景,代表系统核心业务流程 |
查询用电信息 | 中 | 重要流程,保证主要流程完整性 |
查询用电记录 | 中 | 重要流程,保证主要流程完整性 |
查询缴费记录 | 中 | 重要流程,保证主要流程完整性 |
导出数据记录 | 中 | 重要流程,保证主要流程完整性 |
登录 | 中 | 影响系统权限机制,存在安全性架构机制 |
电费价格调整 | 低 | 独立于其它用例,且对系统架构影响较小 |
要对用例模型进行分析,应该从两个方面入手:重新规划和完善本次迭代需要分析的用例和为需要分析的用例定义用例实现。
1.用例迭代开发
对缴费功能、信息查询功能、信息管理功能、系统维护功能进行首次迭代周期用例图如下所示:
图5.1 “缴费功能”首次迭代周期用例图
图5.2 “信息查询功能”首次迭代周期的用例图
图5.3 “信息管理功能”首次迭代周期的用例图
图5.4 “系统维护功能”首次迭代周期的用例图
2.用例实现
用例实现是分析的要素,应该放在分析模型中。而按照UML“4+1”视图的要求,分析模型是面向分析设计人员描述软件结构和行为的,属于逻辑视图,绘制跟踪关系图如下所示:
图5.5 “缴费系统”首次迭代的跟踪关系图
图5.6 “信息查询系统”首次迭代的跟踪关系图
图5.7 “信息管理系统”首次迭代的跟踪关系图
图5.8 “系统维护”首次迭代的跟踪关系图
架构分析中所定义的B-C-E三层备选架构为识别分析类提供了很好的思路。按照该备选架构,系统中的类相应地对应三个层次,即边界类、控制类、实体类。绘制相关图如下所示:
图5.9 “电费管理系统”初始边界类
图5.10 “电费管理系统”初始控制类
图5.11 “电费管理系统”初始实体类
图 5.12 用户登录-用例实现的基本场景顺序图
图5.13 管理用户信息-用例实现的基本场景顺序图
图5.14 管理电表信息-用例实现的基本场景顺序图
图5.15 管理电费信息-用例实现的基本场景顺序图
图5.16 系统维护-用例实现的基本场景顺序图
图5.17 电费缴纳-用例实现的基本场景顺序图
图5.18 管理个人信息-用例实现的基本场景顺序图
图5.19 “电费管理系统”基本类图
根据面向对象的设计原则和常用设计模式对设计进行重构并进行总结。
1.面向对象的设计原则
面向对象的设计原则主要有Liskov替换原则、开放-封闭原则、单一职责原则、接口隔离原则、依赖倒置原则等。
将不同的操作界面顶层抽象出一个界面抽象类来,各操作界面类为该界面类的具体类
图6.1 抽象界面类
图6.2 抽象查询类
图6.3 定义抽象接口
2.常用设计模式
一共有23种GoF设计模式,在此用状态模式对电费缴纳进行重构设计
图6.4 应用状态模式后的设计方案
面向对象的UML语言具有简单、可视化、标准统一等特点,可以统一团队开发中队员之间的沟通标准,使系统开发变得更加简单、高效。同时, UML语言能够使系统拥有更高的可维护性、可拓展性、可移植性、可重用性,使系统发挥更大的作用。
通过本次的UML建模结课大作业让我收获匪浅,本次主要完成的内容有业务建模、用例建模、用例模型分析和面向对象设计重构,这四个部分的内容相互联系,缺一不可。
总得来说这次大作业花费了大概两周的时间,在这期间巩固了书本上的知识,同时自己又上网查阅了大量资料,对UML系统建模有了充分的了解,其次在手动绘制各中图形时也了解到了什么叫做知易行难,书本上的概念容易理解,但是真正绘制图形时却充满了各种小细节,首先是对需求的理解不够彻底,导致绘图过程中反复调整修改,又或者是绘制用例图时又重新去调整前面的活动图,不过在一番努力之下总归是把所需的各种图形给绘制出来了。
[1] 严悍,刘冬梅,赵学龙.UML 2 软件建模:概念、规范与方法[M].北京:国防工业出版社,2009.
[2] Michael Blaha,James Rumbaugh.UML 面向对象建模与设计[M].车皓阳,杨眉,译.2版.北京:人民邮电出版社,2011.
[3] Martin Flower.UML 精粹:标准建模语言简明指南[M].潘加宇,译.3版.北京:清华大学出版社,2012.
[4]刘超,张莉.可视化面向对象建模技术:标准建模语言UML教程[M].北京:北京航空航天大学出版社,1999.
[5]张龙祥.UML 与系统分析设计[M].第2版,北京:人民邮电出版社,2007.
[6]谭火彬.UML2面向对象分析与设计(第二版)[M].北京:清华大学出版社,2013
以上内容就是关于《电费管理系统》所做的UML建模课程设计了,在课设期间翻阅书籍和网上查询了大量资料,但由于本人学识疏浅,其中难免有错误纰漏之处,仅以此作为记录,欢迎大家一起交流学习。
文中所有图片均由本人通过StarUML绘制而成。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。