Table of contents
2. Introduction to system functions
3.1 Identify business participants
4.5 Writing use case documentation
4.6 Refactoring the use case model
5.2 Identification analysis class
Preface
Briefly record, the final UML modeling course design on the electricity bill management system.
1. Task requirements
Refer to the "4+1" view model and use UML tools to perform view modeling of the selected system:
1. The main steps of business modeling: identify business participants, identify business use cases, draw activity diagrams, etc.).
2. The main steps of use case modeling: analyze requirements, identify participants, identify use cases, draw use case diagrams, write use case documents, reconstruct use case models, etc.
3. The main steps of use case analysis: analyze use cases, improve use case documents, identify analysis classes, draw sequence diagrams, draw class diagrams, etc.
4. Reconstruct and summarize the design based on object-oriented design principles and common design patterns.
5. Complete the major assignment design report.
2. Introduction to system functions
Electricity fee management system, in terms of management saved time, saving a lot of manpower and material resources for the department; and it is convenient for owners Transparency, efficiency and convenience, adapt to the efficiency and convenience requirements of today's society. According to the functional requirements of this system, its functional modules are divided as shown in Figure 2.1
Figure 2.1 Basic functions of the power company’s charging management system
2.1 Payment function
Users can choose to go to the business hall to pay offline, or they can choose to pay online.
Figure 2.2 Payment function diagram
The specific functions are as follows:
①Offline payment: According to the electricity bill card provided by the user, the user's electricity usage status is inquired, including the current month's and historical arrears, etc., and the electricity bill is collected on site.
②Online payment: After checking the electricity consumption information online, the user pays through the WeChat applet or mobile APP.
2.2 Query function
The query function can query the user's electricity consumption, payment records, user personal information, and operation records through the system.
Figure 2.3 Query function diagram
The specific functions are as follows:
①Power usage query: Query the user’s power usage information.
② Payment record query: Query all historical payment time, location and amount of the user.
③User personal information query: Query the user’s basic information, including account name, account number, table number, address,
Opening bank, account number, etc.
④ Operation record query: Query system operation status by time, that is, administrator operation trace records.
2.3 Management functions
As a functional module that mainly modifies system data, it includes the entry of basic information of users, basic information of electricity meters, and information such as electricity costs and electricity.
Figure 2.4 Management function diagram
The specific functions are as follows:
①Manage user information: Maintaining user information includes adding and deleting user operations.
②Manage electric meter information: The electric meter information mainly includes the specifications and factory serial number of the electric meter.
③Manage electricity bill information: The main function is to enter the user's electricity bill index, modify the electricity bill price, etc.
2.4 System management
System management mainly focuses on some operational management of data and operational security of the charging system.
Figure 2.5 System management diagram
The specific functions are as follows:
①Data backup: Set the time interval for automatic backup of the system and back up the data to the specified location.
②Data recovery: In the event of data damage, restore system data to the previous safe point.
3. Business modeling
3.1 Identify business participants
Briefly analyze the business participants, as shown in Table 3-1
Table 3-1 Description of business participants in the electricity bill management system
Participant name |
describe |
synonyms |
user |
Electricity user, bill payer |
Head of household |
administrator |
People who manage user information, electricity consumption information, and meter information |
operator |
meter reader |
Meter installation, meter transcriber |
transcriber |
Electricity policy |
Basis for adjusting electricity prices |
Electricity regulations |
payment system |
An external system that provides a payment interface to the system |
WeChat, bank, Alipay |
3.2 Identify use cases
- User management personal information
- User queries electricity bill information
- Users pay electricity bills
- Meter reader installs electricity meter
- Meter reader transcribes electricity usage information
- Administrator manages user information
- Administrator manages meter information
- Administrator manages electricity bill information
- Administrator performs system maintenance
3.3 Draw activity diagram
Figure 3.1 Activity diagram of user management personal information business process
Figure 3.2 Business flow chart for users to query electricity bill information
Figure 3.3 Activity diagram of user payment business process for electricity bills
Figure 3.4 Activity diagram of the meter reader installation business process
Figure 3.5 Activity diagram of the business process of the meter reader copying electricity consumption information
Figure 3.6 Activity diagram of administrator’s business process of managing user information
Figure 3.7 Activity diagram of administrator’s business process for managing meter information
Figure 3.8 Business process activity diagram for administrators to manage electricity bill information
Figure 3.9 Activity diagram of administrator’s system maintenance business process
4. Use case modeling
4.1 Analyze requirements
1. Find business improvement points
Find business improvement points from four aspects: process control, complex business logic, use of business objects, and automated business
2. Define the project vision
This system is an electricity bill management system. The vision is as follows:
① The user can log in to the system normally.
② Users can manage personal information, including account name, table number, address, etc.
③Users can query electricity consumption records and electricity bill payment.
④Administrators can manage user information.
⑤The administrator can manage electricity usage information, including electricity usage records and payment records.
⑥The administrator can maintain the system, backup and restore data.
3. Export system requirements
Combining business improvement points and project vision to derive system requirements, user information query requirements, management information requirements, payment requirements, administrator query requirements, management requirements, and maintenance system requirements.
4.2 Identifying participants
Obtain the participants of the system from the original requirements, as shown in Table 4-1
Table 4-1 Obtain system participants
Extract angle |
types of external things |
Use content from the target system |
participants |
Related users |
Employees who operate the system backend |
Manage user information, electricity usage records, and payment records |
administrator |
On-the-ground staff |
Meter installation, repair, and transcription |
meter reader |
|
system users |
Check electricity usage records and pay bills |
user |
|
other external things |
payment system |
External interface for payment |
payment system |
time |
System is used regularly |
time |
|
Policies and regulations |
Basis for electricity price adjustment |
Policies and regulations |
As can be seen from Table 4-1, there are 6 participants in this system. The participant view is drawn through the modeling tool as shown in 4.1
Figure 4.1 "Electricity Bill Management System" participant view
4.3 Identify use cases
Define use cases starting from the responsibilities of participants using the system, as shown in Table 4-2
Table 4-2 Obtaining use cases from the perspective of participants
participants |
The main work |
Whether to use the system |
Example |
administrator | Enter and modify user information |
yes |
Manage user information |
administrator | Enter and modify meter information |
yes |
Manage meter information |
administrator | Query the user’s electricity consumption record |
yes |
Query electricity consumption records |
administrator | Query the user's payment record, time, platform, and amount |
yes |
Check payment records |
administrator | Adjust electricity prices in accordance with policies and regulations |
yes |
Electricity price adjustment |
administrator |
System data backup and data recovery |
yes |
system maintenance |
meter reader |
Install electricity meters for users |
yes |
Meter installation |
meter reader |
Record users’ electricity usage every month |
yes |
Electricity consumption entry |
user |
Processing of personal information |
yes |
Manage personal information |
user |
Check power usage |
yes |
Query electricity consumption information |
user |
Pay electricity bills |
yes |
Pay electricity bill |
payment system |
An external interface for users to make payments |
yes |
Electricity bill payment |
time |
Export operational data records regularly |
yes |
Export data records |
Other auxiliary use cases |
The system distinguishes between different account identities |
yes |
Log in |
4.4 Drawing use case diagrams
Figure 4.2 Top-level use case diagram of "Electricity Bill Management System"
4.5 Writing use case documentation
"Manage User Information" use case document |
|
Use case name |
Manage user information |
A brief description |
Managers enter and modify user information through the system |
participants |
administrator |
Stakeholders |
none |
Related use cases |
none |
Preconditions |
Whether the user's personal information exists in the system |
Postcondition |
The user information after the operation is saved in the system |
Basic event flow:
|
|
Alternative event flow:
|
|
Supplementary constraints - data requirements: User information includes (account name, account number, table number, address, etc.) |
|
Issues to be resolved:(none yet) |
|
Saikan picture:(暂无) |
"Manage meter information" use case document |
|
Use case name |
Manage meter information |
A brief description |
Administrator enters and modifies meter information |
participants |
administrator |
Stakeholders |
none |
Related use cases |
none |
Preconditions |
Does the meter information exist in the system? |
Postcondition |
After the operation, the meter information will be saved in the system. |
Basic event flow: (1) The administrator queries the meter information through the system (2) The administrator enters the meter information (3) Administrator modifies meter information (4) The meter information is stored in the system |
|
Alternative event flow:
(3) Failed to save meter information |
|
Supplementary constraints - data requirements: Meter information includes (meter specifications, factory number, meter installation address, etc.) |
|
Issues to be resolved:(none yet) |
|
Saikan picture:(暂无) |
"Query Power Consumption Records" use case document |
|
Use case name |
Query electricity consumption records |
A brief description |
Perform combined or fuzzy queries based on the selected data items to display the user's electricity consumption information |
participants |
administrator |
Stakeholders |
none |
Related use cases |
none |
Preconditions |
The user has registered information in the system, and the relevant meter information has been saved in the system. |
Postcondition |
Query operation data is saved |
Basic event flow:
|
|
Alternative event flow: (1) Failed to obtain data |
|
Supplementary constraints - data requirements: Electricity consumption information includes (electricity usage time, electricity consumption quota, etc.) |
|
Issues to be resolved:(none yet) |
|
Related pictures: |
"Query payment record" use case document |
|
Use case name |
Check payment records |
A brief description |
Query all historical payment status of a single user |
participants |
administrator |
Stakeholders |
none |
Related use cases |
none |
Preconditions |
User information is stored in the system |
Postcondition |
Query operation data is saved |
Basic event flow: (1) The administrator selects data items to query user payment information (2) Obtain payment status |
|
Alternative event flow: (1) Failed to obtain data |
|
Supplementary constraints - data requirements: 缴费记录包括(缴费时间、缴费平台、缴费金额) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“电费价格调整”用例文档 |
|
用例名 |
电费价格调整 |
简要描述 |
管理员依据政策法规调节电力价格 |
参与者 |
管理员 |
涉众 |
政策法规 |
相关用例 |
无 |
前置条件 |
系统中存在电费信息,有相关政策法规 |
后置条件 |
调整后的电力价格将告知用户 |
基本事件流:
|
|
备选事件流:
|
|
补充约束-数据需求: 电费价格信息包括(价格梯度等) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“系统维护”用例文档 |
|
用例名 |
系统维护 |
简要描述 |
管理员对系统的数据进行备份、恢复 |
参与者 |
管理员 |
涉众 |
无 |
相关用例 |
无 |
前置条件 |
系统中存在数据 |
后置条件 |
操作后的数据将被保存 |
基本事件流:
|
|
备选事件流:
|
|
补充约束-数据需求: (暂无) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“电表安装”用例文档 |
|
用例名 |
电表安装 |
简要描述 |
抄表员通过系统获取用户安装电表的需求后,为户主进行电表安装 |
参与者 |
抄表员 |
涉众 |
用户 |
相关用例 |
无 |
前置条件 |
用户在系统中提出安装电表需求 |
后置条件 |
电表信息被录入系统 |
基本事件流:
|
|
备选事件流:
|
|
补充约束-数据需求: 电表信息包括(电表的规格、出厂编号、安装地址等) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“用电录入”用例文档 |
|
用例名 |
用电录入 |
简要描述 |
抄表员每月定期前往用户住址进行用电情况记录 |
参与者 |
抄表员 |
涉众 |
用户 |
相关用例 |
无 |
前置条件 |
用户信息、电表信息保存在系统中 |
后置条件 |
用电情况录入系统 |
基本事件流:
|
|
备选事件流: (1)抄表员联系不到户主 |
|
补充约束-数据需求: 用电信息包括(用电额度、用电时间) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“管理个人信息”用例文档 |
|
用例名 |
管理个人信息 |
简要描述 |
用户对个人信息进行查询,修改操作 |
参与者 |
用户 |
涉众 |
无 |
相关用例 |
无 |
前置条件 |
用户信息已保存在系统中 |
后置条件 |
操作后的数据保存在系统中 |
基本事件流:
|
|
备选事件流:
|
|
补充约束-数据需求: 用户信息包括(户名、户号、表编号、地址等) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
“缴纳电费”用例文档 |
|
用例名 |
缴纳电费 |
简要描述 |
用户了解用电情况后缴纳相应的电费 |
参与者 |
用户 |
涉众 |
支付系统 |
相关用例 |
无 |
前置条件 |
用户的用电记录保存在系统中 |
后置条件 |
缴费情况保存在系统中 |
基本事件流:
|
|
备选事件流:
|
|
补充约束-数据需求: 缴费信息包括(缴费时间、地点、金额) |
|
待解决的问题:(暂无) |
|
相关图:(暂无) |
4.6 重构用例模型
1.用例分包
按照参与者将用例分包,如图所示4.3所示
图4.3 “电费管理系统”顶层分包用例图
2.用例分级
用例 |
优先级 |
分级原因 |
管理用户信息 |
高 |
项目主要远景,代表系统核心业务流程 |
管理电表信息 |
高 |
项目主要远景,代表系统核心业务流程 |
用电录入 |
高 |
项目主要远景,代表系统核心业务流程 |
缴纳电费 |
高 |
项目主要远景,代表系统核心业务流程 |
系统维护 |
高 |
项目主要远景,代表系统核心业务流程 |
电表安装 |
高 |
项目主要远景,代表系统核心业务流程 |
查询用电信息 |
中 |
重要流程,保证主要流程完整性 |
查询用电记录 |
中 |
重要流程,保证主要流程完整性 |
查询缴费记录 |
中 |
重要流程,保证主要流程完整性 |
导出数据记录 |
中 |
重要流程,保证主要流程完整性 |
登录 |
中 |
影响系统权限机制,存在安全性架构机制 |
电费价格调整 |
低 |
独立于其它用例,且对系统架构影响较小 |
五、用例模型分析
5.1 分析用例
要对用例模型进行分析,应该从两个方面入手:重新规划和完善本次迭代需要分析的用例和为需要分析的用例定义用例实现。
1.用例迭代开发
对缴费功能、信息查询功能、信息管理功能、系统维护功能进行首次迭代周期用例图如下所示:
图5.1 “缴费功能”首次迭代周期用例图
图5.2 “信息查询功能”首次迭代周期的用例图
图5.3 “信息管理功能”首次迭代周期的用例图
图5.4 “系统维护功能”首次迭代周期的用例图
2.用例实现
用例实现是分析的要素,应该放在分析模型中。而按照UML“4+1”视图的要求,分析模型是面向分析设计人员描述软件结构和行为的,属于逻辑视图,绘制跟踪关系图如下所示:
图5.5 “缴费系统”首次迭代的跟踪关系图
图5.6 “信息查询系统”首次迭代的跟踪关系图
图5.7 “信息管理系统”首次迭代的跟踪关系图
图5.8 “系统维护”首次迭代的跟踪关系图
5.2 识别分析类
架构分析中所定义的B-C-E三层备选架构为识别分析类提供了很好的思路。按照该备选架构,系统中的类相应地对应三个层次,即边界类、控制类、实体类。绘制相关图如下所示:
图5.9 “电费管理系统”初始边界类
图5.10 “电费管理系统”初始控制类
图5.11 “电费管理系统”初始实体类
5.3 绘制顺序图
图 5.12 用户登录-用例实现的基本场景顺序图
图5.13 管理用户信息-用例实现的基本场景顺序图
图5.14 管理电表信息-用例实现的基本场景顺序图
图5.15 管理电费信息-用例实现的基本场景顺序图
图5.16 系统维护-用例实现的基本场景顺序图
图5.17 电费缴纳-用例实现的基本场景顺序图
图5.18 管理个人信息-用例实现的基本场景顺序图
5.4 绘制类图
图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绘制而成。