项目3用电管理系统.docx

项目3用电管理系统.docx

《项目3用电管理系统.docx》由会员分享，可在线阅读，更多相关《项目3用电管理系统.docx（23页珍藏版）》请在冰豆网上搜索。

项目3用电管理系统

用电系统架构分析

计软0802赵海亮（23）朱林军（20）

A．1业务需求

A．1．1客户的需求描述

下面是南京工业大学学生关于用电系统的描述：

从去年开始，象山苑实行了用电的统一管理----通过在学生宿舍安装电表来管理学生用电，当学生用电超过学校给定的度数，由学生自己支付用电费用，这在一定程度上对于培养学生的节约用电的观念和限制学生玩通宵游戏起到了一定的效果。

但是，有时这种不透明的用电管理给我们学生带来了一定的困扰，比如节假日突然断电，无法及时充电费，即使可以缴费，也有时间和地点的制约。

所以，我们学生想如果能在internet上实现用电的管理，可以随时随地的查询每个宿舍的用电情况和缴纳电费那该是多么幸福的一件事呀！

这不仅能减少学校的财政支出，也方便了学生的校园生活。

所以，通过这个管理系统，实现学生随时随地缴费查询，以达到虚拟电力部门的最终目标。

A．1.2参与者列表

●管理员：

管理用电的情况，负责处理学生的缴费，管理用电学生申请人信息。

如添加和删除，更新学生信息。

●学生（以宿舍为单位）：

用电的主体，进行用电查询和缴费。

A．1.3用例列表

●A1：

学生查询：

学生登录系统进行用电情况查询。

●A2：

学生缴费：

学生登录系统进行超额缴费。

●A3：

学生申请退款：

当学生要毕业时，还有用电余额，这时学生向管理员申请退款请求。

●A4：

管理员管理学生信息：

添加和删除，更新学生信息。

●A5：

管理员收费：

处理学生交费。

●A6：

管理员处理学生退款申请。

●A7：

管理员查看学生用电：

管理员查询全校用电概况和每个宿舍的用电情况，以制定相关的措施。

如用电高峰期和违章电器严打期。

A．1．4用例的通信图

A．1．5用例的活动图

A．1．6用例的细节

A1：

学生查询

1．学生首先进入系统进行注册，以宿舍为单位，填完详细信息。

2．学生登录系统，输入用户名和密码，进行查询。

A2：

学生缴费

1．学生可以到交费点人工交费，由管理员通过本系统处理交费事宜。

2．学生可以通过上网登录用电管理系统进行网上交款。

3．所交的费用一律通过校园卡扣款。

4．如果校园卡的费用不足支付所需的电费，则返回交款失败。

5．如果校园卡里的余额足以支付所需的电费，则交款成功。

A3:

学生申请退款

1.如果学生毕业时电费还有余额，则可以先登录系统，填写申请退款的请求。

2.经过管理员的审核，如果通过，管理员通过发短信或电话或发邮件的方式联系学生，进行退款。

A4：

管理员管理学生信息

1.新学年开始，管理员删除大四学生相应宿舍学生的信息，用来储存大一新生的信息。

A5:

管理员收费

1.管理员登录系统，如果有学生缴费，那么更改用电的状态。

A6：

管理员处理学生退款申请

1.管理员登录系统，查收接到退款申请

2.经过相应的审核，如果通过，则打款到申请人的校园卡中，并通知其本人。

3.如果审核不通过，则联系申请人，说明拒绝理由。

A7:

管理员查看学生用电

1.管理员登录系统

2.查看全校用电的总量

3.查看每个宿舍的用电情况

A．1．7用例的细节

A．2系统需求

A．2.1数据库设计

字段

类型

主键

为空

描述

sid

string

是

否

Id号，有递增功能

username

string

否

用户名

password

string

否

密码

role

int

否

角色

grade

string

否

年级

roomNumber

string

否

宿舍号

phoneNumber

string

否

手机号

realname

string

否

真实姓名

Email

string

否

邮件

（图2..1.1学生表）

字段

类型

主键

为空

描述

aid

string

是

否

Id号，有递增功能

username

string

否

用户名

password

string

否

密码

role

int

否

角色

phoneNumber

string

否

手机号

realname

string

否

真实姓名

Email

string

否

邮件

（图2..1.2管理员表）

字段

类型

主键

为空

描述

sid

string

是

否

学生id号，有递增功能

amount

int

否

用电度数

（图2..1.3管理员表）

A．2.1界面设计草图

用电管理系统

用户名：

注册

密码：

找回密码

管理员学生

登录重置

（图A.2.1.1登录界面）

你好！

欢迎使用用电管理系统！

退出

证件信息

XXX你好！

一卡通号：

xxx姓名：

xxx

宿舍：

xxx学院班级：

xxx

手机：

xxxemail：

xxx

修改个人密码修改联系信息

用电账单

申请退款

我要充值

（图A.2.1.2学生页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

修改密码

原密码：

xxx

新密码：

xxx

确认密码：

xxx

确认返回

用电账单

申请退款

我要充值

（图A.2.1.3修改学生登录密码页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

修改联系信息

手机：

xxx

Email：

xxx

确认返回

用电账单

申请退款

我要充值

（图A.2.1.4修改学生联系信息页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

XXX你好！

！

Xxx宿舍，已用xx度电，

还剩xx度电！

清单查询

用电账单

申请退款

我要充值

（图A.2.1.5学生用电账单页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

查询月份

2010-072010-082010-92010-102010-11

2010-12当用准实时查询

用电账单

宿舍：

xxx

当月用电量：

xxx剩余电量：

xxx

申请退款

我要充值

（图A.2.1.6学生用电账单清单查询页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

申请退款

申请人姓名：

申请人宿舍：

申请理由：

保存重置

用电账单

申请退款

我要充值

（图A.2.1.7学生申请退款页面）

你好！

欢迎使用用电管理系统！

退出

证件信息

电费充值

充值金额：

确定缴费

用电账单

申请退款

我要充值

（图A.2.1.8学生充值页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

学生缴费

宿舍区：

单元号：

宿舍号：

充值金额：

确定返回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.9人工充值页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

宿舍区：

xxx单元：

xxx宿舍号：

xxx查询

宿舍

负责人

手机

Email

操作

删除

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.10用户信息页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

退款申请处理：

申请人姓名：

申请人宿舍：

申请理由：

同意驳回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.11用户退款申请页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

余额共xxx已经返还到xxx帐户！

请查看！

返回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.12用户退款申请同意草图页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

驳回理由：

对不起，你不符合退款条件！

XXXXXXXX………

提交返回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.13用户退款申请驳回草图页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

宿舍区：

xxx单元：

xxx宿舍号：

xxx查询

宿舍

负责人

已用电量

剩余电量

上月电量

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.14用户退款申请驳回草图页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

XXX您好！

用户名：

xxx姓名：

xxx

手机：

xxxemail：

xxx

修改个人密码修改联系信息

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.15管理员信息草图页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

修改密码

原密码：

xxx

新密码：

xxx

确认密码：

xxx

确认返回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.16管理员修改密码草图页面）

您好！

欢迎使用用电管理系统！

退出

学生缴费

修改联系信息

手机：

xxx

Email：

xxx

确认返回

用户信息

退款申请

电量查询

管理员信息

（图A.2.1.17管理员修改联系方式草图页面）

A．2.2辅助需求

●客户小程序必须运行在JavaPlugin1.2上（或更新的版本）；

●用电管理系统必须有相应的硬件给予大力支持；

●用电管理系统必须能处理50000个用户的能力；

A．2.3类图分析

本系统的大多数类都出现在下面的类图模型中：

A．2.4操作列表分析

●Students:

—register（）－在系统中注册学生信息，包括姓名，密码，帐号等等。

—recorverPassword（）－找回密码

—modifyPasword（）－修改密码

—modifyInform（）－修改用户的联系方式

—query（）－输入学生宿舍，查看当月或其他月份的用电情况

—payFees（）－登录本系统，通过校园卡支付电费

—payBack（）－大四学生离开校园，申请退费。

—getUsername（）－返回用户的用户名对象

—setUsername（）－设置用户的用户名

—getPassword（）－返回用户的密码对象

—setPassword（）－设置用户的密码

—getRole（）－返回用户的角色对象

—setRole（）－设置用户的角色

—getGrade（）－返回用户的所在年级对象

—setGrade（）－设置用户的年级

—getRoomNumber（）－返回用户的宿舍号对象

—setRoomNumber（）－设置用户的宿舍号

—getPhoneNumber（）－返回用户的手机对象

—setPhoneNumber（）－设置用户的手机号

—getEmail（）－返回用户的Email对象

—setEmail（）－设置用户的Email地址

—getRealname（）－返回用户的真实姓名对象

—setRealname（）－设置用户的真实姓名

●Administer:

—register（）－在系统中注册管理员信息，包括姓名，密码，帐号等等。

—recorverPassword（）－找回密码

—modifyPasword（）－修改密码

—modifyInform（）－修改用户的联系方式

—query（）－输入学生宿舍，查看当月或其他月份的用电情况

—handleFees（）－登录本系统，人工收取电费

—handlePayBack（）－大四学生离开校园，处理申请退费。

同意返回true，否则返回false

—getUsername（）－返回管理员的用户名对象

—setUsername（）－设置管理员的用户名

—getPassword（）－返回管理员的密码对象

—setPassword（）－设置管理员的密码

—getRole（）－返回管理员的角色对象

—setRole（）－设置管理员的角色

—getSex（）－返回管理员的性别

—setSex（）－设置管理员的性别

—getPhoneNumber（）－返回管理员的手机对象

—setPhoneNumber（）－设置管理员的手机号

—getEmail（）－返回管理员的Email对象

—setEmail（）－设置管理员的Email地址

—getRealname（）－返回管理员的真实姓名对象

—setRealname（）－设置管理员的真实姓名

●Electricity：

—Sum（）－返回总电量

●Dormitory:

—getNumber（）－返回宿舍门牌号

—setNumber（）－设置宿舍门牌号

—getUnitNumber（）－返回宿舍所在的单元

—setUnitNumber（）－设置宿舍所在的单元

—getAreaCode（）－返回宿舍所在的区域

—setAreaCode（）－设置宿舍宿舍所在的区域

●CampusCard

—getSid（）－返回校园卡帐号

—setSid（）－设置校园卡帐号

—getPassword（）－返回校园卡密码

—setPassword（）－设置校园卡密码

A．2.5系统的时序图

A．2.5．1系统时序图

A．2.5．2业务时序图

A．2.6系统的部署图

A．3测试计划概况

A．3.1引言

本系统的测试是不间断的，开发人员，同学，测试人员都要参与进来。

●开发人员在开发过程中要测试他们的结果

●同学也要参与本系统的验证、接受测试和beta测试

●同行要评估开发人员开发出来的产品

●构建小组负责第一个递增版本之后的构建测试

A．3.2螺旋式递增的作用

在开发的每次螺旋式上升过程中，都由开发人员进行测试。

每个制品都要进行同行评附带条件是，正式的同行评估对于第一次螺旋式上升过程是没有必要的。

对于第二次之后的螺旋式上升过程，正式的同伴评估主要考虑对制品进行修改，以避免重复。

同样，同行评估业应主要考虑上一次评估之后进行的修改。

在完成了完整的螺旋式上升过程后，测试小猪就接管测试阶段，直到发布下一个递增版本为止。

在第一个递增版本之后，衰退测试应该确保电量查询系统至少与上一个递增版本有相同的功能。

非代码制品的测试

用例和uml图是由我们利用管理员和同学的输入生成的。

在早期的开发过程中，开发小组的成员会相互评估彼此的工作，并立即修改。

在递增版本发布之前的螺旋式开发过程中，要与不直接参与项目的相关老师进行正式的同行评估。

这些评估用于验证制品，从用例到基于类的规范，都要进行测试。

开发人员、同行和项目经理要负责确保制品是相容的。

在每个递增版本的最后编码阶段之后，要与不参与项目的同行一起进行正式的代码评估。

在这些评估过程中，将使用手工的百合子测试和衡量工具来判断需要进行的调整。

在设计的实现过程中，程序员将在juint的帮助下对自己的工作进行补阶段的测试。

这些程序员开发的测试包括类级别的单元测试和对开发人员的所有类进行的完整性测试。

每个开发人员在公开其代码之前，都必须修改代码中的错误。

在每个螺旋式开发过程的最后，开发人员都要是由junit，进行非正式的完整性测试和子系统测试，其目标是在正式的测试阶段之前，尽可能地减少错误。

此时，开发小组要在下一个螺旋式过程或测试阶段之前，修改查询出来的错误。

如果这个测试计划后面所述，程序员要在代码中添加断言，并在开发过程中使这些断言其作用。

在测试阶段，断言最初用于使错误的查找更容易。

所有的测试都成功通过后，这些测试就要在禁用断言的情况下再次运行，来检查是否已没有断言在起作用。

它还可以比较代码在有断言和没有断言时的性能。

在发布时，断言是禁用的，但仍保留在代码中，这样就可以再次激活它们，以帮助诊断故障。

所以，实时系统不会因禁用断言而受损失，并可以采取进一步的措施来保护系统。

为了在禁用断言的状态下保护服务器不被偶然或者恶意攻击，要在服务器层上实现应用程序防火墙。

这个防火墙一般会强制满足服务器层的前提条件，使检查枪支进行。

为了减少到达服务器层的不正确的信息量，要在用户界面的下面防止另一个应用程序防火墙，以拒绝用户无效的请求。

另外，web服务器放在非军事区，位于两个常规应用程序防火墙的中间，以拒绝一般的internet攻击。

客户防火墙有两种样式。

对于基于html的客户，防火墙在服务小程序内部实现，并使防止无效请求的标准web技术。

对于基于gui的客户，防火墙应在控制层上实现，使用标准的cui技术来防止无效请求。

A．3.3分阶段的测试活动

下面是开发的各个阶段进行的测试活动。

第一个螺旋式开发过程可以放松正式同行评估的要求。

同行应从同学中选择。

●需求阶段：

业务用例、用户界面草图、用例图、系统用例、用例优先级、辅助要求和活动图由开发人员、顾客来评估。

●分析阶段：

分析类图、状态机图、通信图由开发人员、同行和顾客来评估、

●系统设计阶段：

部署图、技术选择、层图、层交互策略、并发策略和安全策略由开发人员和同行来评估。

●实现阶段：

这个阶段的测试包括三个部分：

---给方法添加断言，其他类型的断言实可选的。

但推荐使用。

例如检查循环结束，避免不可能的条件。

---创建JUnit测试案例和JUnit测试套件。

每个类至少有一个测试案例，每个包至少有一个测试套件。

---由开发人员和同行进行代码评估

●测试阶段：

测试阶段由测试小组负责。

测试小组开发的测试案例和测试过程要经过同行评估。

测试包括：

---JUnit测试，确保修改所有已知的错误。

---系统测试，基于用例

---应力测试，确认系统会优雅地失败

---安全测试

---接受测试，一般基于生产率标准

---衡量标准，基于系统性能和编码样式

---说明文档测试，由最终用户和系统管理员帮助完成

---beta测试，在选中的顾客站点上

●维护阶段：

测试小组在项目小组的帮助下，负责管理报告、修改发布后发现的错误，在递增版本中，由测试小组决定是否修改错误，进行衰退测试，最后发布。

衰退测试包括：

---JUnit测试

---系统测试

用户对改进的电力管理系统的反馈将传送给开发小组，并合并到下一个递增版本中。