【软件工程实验报告】校园卡管理系统

多吃青菜吧

已于 2024-11-06 10:54:54 修改

阅读量2.3k

点赞数 38

分类专栏：软件工程文章标签：软件工程

于 2024-06-28 17:28:04 首次发布

本文链接：https://blog.csdn.net/weixin_54735966/article/details/140047082

版权

软件工程专栏收录该内容

1 篇文章

订阅专栏

内容包括：软件项目计划、结构化系统分析、结构化系统设计、面向对象分析与设计。

详细内容可下载文档查看。

1 软件项目计划

1.1 过程模型的选择

采用RAD（快速应用程序开发）模型作为校园卡管理系统的开发方法。

理由如下：

快速交付：RAD模型以迭代和增量的方式开发软件，能够更快地交付原型和最终产品。对于校园卡管理系统，快速交付意味着可以更快地满足用户需求，并及时调整和改进系统功能。
灵活性：在校园卡管理系统中，用户需求可能会随着时间和使用情况的变化而变化。RAD模型允许在开发过程中根据用户反馈和需求进行灵活调整。
减少风险：RAD模型通过频繁的原型演示和用户反馈，可以及早发现和解决问题，从而降低项目失败的风险。在校园卡管理系统中，及时发现和解决问题可以避免系统故障对学生和教职员工的影响。

1.2 项目范围的描述

1.2.1 现状描述

近年来随着高校的扩招，高校的食堂、超市等也变得越来越多。要对大学校园中的各项消费业务进行统一控制，实现校园卡的一卡通用，就需要借助现代的更加先进的技术和科技，比如说：电子信息管理系统、射频技术、网络技术、计算机技术等以实现更加方便、快捷、有效的消费管理。

校园卡管理系统的建设，将有效缓解校务管理和后勤服务的繁重的业务，提高学校的管理水平、提高后勤的服务质量，成为广大师生员工工作、学习和生活中不可或缺的一部分。

1.2.2 系统目标

该校园卡管理系统要实现的功能如下：

（1）办理新卡。学生在系统中输入个人信息，管理员根据系统中的学生信息管理中心的资料审核学生信息，若审核通过，给予学生办理新校园卡。

（2）交易功能。

1）交易处理：学生通过系统向校园卡账户充值或在指定地点进行消费。

2）交易信息：管理员输入消费金额数，系统记录消费信息。

3）交易管理：系统向校园卡实时更新余额，保存交易结果。

（3）校园卡状态管理。

1）状态处理：学生可通过系统请求挂失或解挂校园卡以及注销校园卡。
2）状态管理：管理员审核请求后，系统更新卡片状态进行状态更改并返还余额和押金，且系统将信息从数据库中删除。

（4）个人账户管理。

1）密码信息：学生通过系统修改校园卡的访问密码，管理员审核通过后给予密码修改操作，系统记录并验证新密码。

2）消费信息：用户可以通过系统查询自己的消费记录。

1.2.3可行性分析

对于本系统的可行性分析，我们主要从技术、经济和管理三个维度上进行可行性分析。

（1）技术可行性

随着计算机网络技术的飞速发展，我们见证了信息技术在各个行业领域的广泛应用和深度融合。C/S（客户端/服务器）开发模式因其成熟稳定、易于维护和扩展的特性，被广泛采用。同时，COM（组件对象模型）和DCOM（分布式组件对象模型）技术也因其跨平台、高效率的特点，在国内各行各业的信息管理系统开发中占据了重要地位。这些技术不仅能够满足校园卡管理系统的基本需求，还能确保系统的稳定性、安全性和可扩展性。因此，从技术的角度来看，本系统的开发是完全可行的。

（2）经济可行性

校园卡管理系统所涉及的主要应用场景包括学校中的食堂、超市等，这些场所由于学校、政府和其他支持者的支持，具有相当的可靠性和盈利性。通过引入校园卡消费信息管理系统，学校可以更加高效、精准地管理学生的消费信息，降低管理成本，提高服务质量。同时，该系统还能帮助商家更好地了解消费者的消费习惯和需求，优化商品结构，提高销售额和利润。因此，从经济的角度来看，本系统的开发也是完全可行的。

（3）管理可行性

在管理上，主要分为基础管理模块。学生的个人信息模块，刷卡消费信息模块，卡务管理所包括的信息（挂失/解挂、注销、办理新卡、查询、冲值等模块），系统数据模块。这些是在系统规划设计阶段所原本包括的内容，在设计后期试运行期间的主要工作是新信息的补充和输入，在管理上把这一部分放入前期的准备工作可以节省很多的时间，以及使工作中出现的差错率降低。

此外，在人员管理方面，本系统也实现了人员的最少化。例如，在浴室刷卡环节，由于采用了自动化技术，基本不需要人工操作。在食堂刷卡环节，也只需要打卡人员输入数据，无需额外的监督管理。同时，我们还配备了少数充值中心的工作人员，以满足学生的充值需求。这种人员配置方式既保证了系统的正常运行，又降低了人力成本，从管理的角度来看，本系统的开发也是完全可行的。

1.3软件成本和工作量计算

1.3.1 采用LOC方法进行软件成本和工作量的估算

该系统的功能包括注册登录、交易功能、校园卡状态管理、个人账户管理，每个功能的乐观值、可能值、悲观值以及通过计算得出的期待值，如表1-1所示，为基于LOC的分析表。

表 1-1 基于LOC的分析表

功能	乐观值	可能值	悲观值	期望值
办理新卡	160	210	260	210
交易功能	350	420	490	420
校园卡状态管理	330	380	430	380
个人账户管理	380	440	500	440
总计：				1450

平均一个劳动力价格是每月4000元人民币，根据历史数据得知生产率为200(LOC/PM)

工作量=总LOC/生产率=1450/200 =7.25

成本=工作量×劳动力价格= 7.25×4000 = 29000元

1.3.2 采用FP方法进行软件成本和工作量的估算

该系统的五个信息域为外部输入、外部输出、内部逻辑、外部接口、外部查询，每个信息域的复杂性都有简单，中等和复杂三个等级。如表1-2所示，为功能复杂性影响参数表。

表 1-2 功能复杂性影响参数

复杂性信息域	各功能条目数	简单	中等	复杂
外部输入	18	3	4	6
外部输出	9	4	5	7
内部逻辑	7	5	7	10
外部接口	6	4	5	7
外部查询	1	3	4	6

假定以上功能均为中等的复杂性，因此得到未调节功能点：

UFP=18*4+9*5+7*7+6*5+1*4=200

该系统的系统特征分别为数据通讯、分布数据处理、性能要求、系统配置要求、事务率、联机数据录入、最终用户效率、联机更新、复杂的处理逻辑、可复用性、易安装性、易操作性、多工作场所、设施变更，每个系统特征的因子值，如表1-3所示，为影响因子取值表。

表 1-3 影响因子取值表

序号	系统特性	因子值
1	数据通讯	3
2	分布数据处理	3
3	性能要求	5
4	系统配置要求	3
5	事务率	4
6	联机数据录入	4
7	最终用户效率	5
8	联机更新	3
9	复杂的处理逻辑	2
10	可复用性	3
11	易安装性	3
12	易操作性	5
13	多工作场所	3
14	设施变更	1
总计：		47

CAF（复杂度调节因子）=0.65+0.01*47=1.12

FP（交付功能点）=CAF*UFP=200*1.12=224

劳动力价格是每月4000元人民币，根据历史数据得知生产率为30(FP/PM)

工作量=总FP/生产率=224/30=7.47

成本=工作量x劳动力价格=29880元

1.4 分析项目风险

风险表给项目管理者提供了一种简单风险预测方法。该系统的风险市场竞争大、用户信息泄露、技术选型不合适、用户需求变化、项目成本超出预算、开发者经验不足。每个风险的所属类别，发生的可能性，影响以及RMMM。如表1-4所示，为项目风险表。

表 1-4 项目风险表

风险	类别	可能性	影响	RMMM
市场竞争大	2	70%	2	加强市场推广、优化产品策略、提高服务质量。
用户信息泄露	3	60%	1	定期进行安全漏洞扫描和渗透测试，及时修复发现的安全问题。
技术选型不合适	5	80%	2	选择成熟且适合项目需求的技术方案。在开发过程中进行多次技术评审和重构，确保系统性能满足要求。
用户需求变化	3	50%	3	定期收集用户反馈、持续迭代优化产品、灵活调整项目方向。
项目成本超出预算	4	70%	1	在保证项目质量的前提下尽可能的把握进度和效率，减少不必要的支出，合理资源分配。
开发者经验不足	6	85%	2	定期进行员工的技能培训和知识分享。根据项目需要进行人员的任务分配和调整，确保团队的协作和执行效率。

类别：1-产品规模 2-商业影响 3-客户环境 4-过程定义 5-技术 6-人员数量及经验

影响值：1-灾难性的 2-严重的 3-轻微的 4-可忽略的

1.5 甘特图活动安排

进度安排表是以表格的方式形象地表示出任何特定项目的工期、开始时间、结束时间、前置任务及所需资源名称。图1-1所示，为该系统的进度安排表截图。

图 1-1 进度安排表截图

甘特图是以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。甘特图可以很便利地弄清项目还剩下哪些工作要做，并可以评估工作进度。如图1-2所示，为甘特图。

图 1-2 甘特图

2 结构化系统分析

2.1 需求分析

随着社会信息化的蓬勃发展，校园的管理也进入了一个信息化的时代，先进的信息管理系统成为建设世纪一流大学的重要标志。在信息网络高速发展的今天，越来越多的信息均以数字形式进行交换和管理。伴随着智能技术的高速发展和计算机应用的普遍推广，校园卡管理系统的建设正逐步成为一种趋势。

学校的食堂、超市非常的分散，要实现如此之多的食堂、超市的良好、协调、统一的管理，就需要借助现代的更加先进的技术和科技，比如说：电子信息管理系统、射频技术、网络技术、计算机技术等以实现更加方便、快捷、有效的管理。

此外消费信息的爆炸性增长也急需一个强大的信息系统的管理，校园卡管理系统需求甚广。

2.2 建立数据流图（DFD）

校园卡管理系统有三个实体，分别是学生、管理员、校园卡。

学生在系统中提供：个人信息、交易请求、确认交易信息、挂失/解挂请求、注销请求、密码修改请求、消费查询请求；

系统给学生显示：新卡办理状态、交易结果、交易金额、挂失/解挂状态、注销结果、密码修改结果、消费清单；

管理员在系统中提供：学生信息审核、消费金额录入、挂失/解挂处理、注销处理、密码修改审核；

系统给管理员反馈：学生信息审核结果、消费记录更新、挂失/解挂处理结果、注销处理结果、系统运行状态；

校园卡在系统中提供：状态信息、交易信息、输入密码；

系统给校园卡提供：状态更新、更新余额、密码结果。

如图2-1所示，为该系统的顶层数据流图。

图 2-1 顶层数据流图

该校园卡管理系统由办理新卡、交易功能、校园卡状态管理、个人账户管理四个加工组成。

学生在办理新卡时将个人信息提供给'办理新卡'；'办理新卡'把新卡办理状态发送给学生。'办理新卡'把个人信息存储在学生信息表中，把校园卡信息存储在校园卡信息表中。管理员向'办理新卡'发送学生信息审核，'办理新卡'把学生信息审核结果发送给管理员。

'交易功能'把交易结果存储在财务信息表中，并将财务信息表中的余额存储到校园卡信息表，财务信息表把交易信息发送给'个人账户管理'。学生将交易请求、确认交易信息发送给'交易功能'；'交易功能'将交易金额、交易结果提供给学生。'校园卡'向'交易功能'发送输入密码，'交易功能'把密码结果发送给校园卡。管理员将消费金额录入发送给'交易功能，'交易功能'将消费记录更新发送给管理员。

'校园卡状态管理'把挂失/解挂结果、注销结果存储在校园卡信息表中，校园卡信息表把校园卡状态发送给'个人账户管理'。学生将挂失/解挂请求、注销请求发送给'校园卡状态管理'；'校园卡状态管理'把挂失/解挂结果、注销结果发送给学生。'校园卡'向'校园卡状态管理'发送输入密码、状态信息，'校园卡状态管理'把密码结果、状态更新发送给校园卡。管理员将挂失/解挂处理、注销处理发送给'校园卡状态管理'；'校园卡状态管理'把挂失/解挂结果、注销结果发送给管理员。

'个人账户管理'把密码修改存储在校园卡信息表中、将消费清单存储在财务信息表中。'个人账户管理'将系统运行状态发送给管理员，管理员向'个人账户管理'发送密码修改审核。学生将密码修改请求发送给'个人账户管理'，'个人账户管理'将密码修改结果返回给学生。

如图2-2所示，为该校园卡管理系统的0层数据流图。

图 2-2 0层数据流图

该校园卡管理系统交易功能由交易处理、交易信息、交易管理三个加工组成。

学生发送交易请求给'交易处理'，'交易处理'给学生交易结果；校园卡将输入密码发送给'交易处理'，'交易处理'给校园卡提供密码结果。

'交易信息'向学生发送交易金额，然后学生向'交易信息'发送确认交易信息；管理员向'交易信息'提供消费金额录入，'交易信息'将消费记录更新给管理员。

校园卡向'交易管理'发送交易信息；'交易管理'向校园卡更新余额。'交易管理'将交易结果存储到财务信息表，并将财务信息表中的余额存储到校园卡信息表。

如图2-3所示，为该校园卡管理系统的交易功能的1层数据流图。

图 2-3 交易功能的1层数据流图

该校园卡管理系统的校园卡状态管理由状态处理、状态管理两个加工组成。

学生向'状态处理'发送挂失/解挂请求、注销请求，'状态处理'向学生发送挂失/解挂结果、注销结果。校园卡向'状态处理'输入密码，'状态处理'将密码结果发送给校园卡。

校园卡向'状态管理'发送状态信息，'状态管理'将状态更新给校园卡。'状态管理'向管理员发送挂失/解挂处理、注销处理，管理员将挂失/解挂结果、注销结果发送到'状态管理'。'状态管理'将挂失/解挂结果、注销结果存储到校园卡信息表。

如图2-4所示，为该校园卡管理系统的校园卡状态管理的1层数据流图。

图 2-4 校园卡状态管理的1层数据流图

该校园卡管理系统的个人账户管理由密码信息、消费信息两个加工组成。

学生向'密码信息'发送密码修改请求，'密码信息'将密码修改结果发送给学生。'密码信息'将密码修改审核发送给管理员，并将密码修改存储到校园卡信息表中。

学生向'消费信息'发送消费查询请求，'消费信息'将消费清单发送给学生。'消费信息'将系统运行状态发送给管理员，并将消费清单存储到财务信息表。

如图2-5所示，为该校园卡管理系统的个人账户管理的1层数据流图。

图 2-5个人账户管理的1层数据流图

2.3 建立数据字典（DD）

数据流便于用户表达功能需求、数据需求和联系。

学生信息数据流的来源是学生，去处是办理新卡，数据流结构为学生信息={学号+姓名+年级+所在院系+专业+班级+联系方式}所有使用学生。如表2-1所示，为学生信息数据流表。

表 2-1 学生信息数据流表

数据流
系统名：校园卡管理系统		编号：
条目名：个人信息		别名：
来源：学生		去处：办理新卡
数据流结构：学生信息={学号+姓名+年级+所在院系+专业+班级+联系方式}所有使用学生
简要说明：学生在办理新卡时对自己的基本信息进行录入。
修改记录：	编写：蔡安琪		日期：2024.6.2
	审核：陆徐瑛		日期：2024.6.3

学生学号属于交易请求、确认交易信息、挂失/解挂请求、注销请求、密码修改请求、消费查询请求数据流，存储在校园卡信息表和财务信息表中，其中学生学号是学生的识别符，每个学生都有唯一的学生学号，而且每张校园卡对应唯一一个学生。如表2-2所示，为学生学号数据元素表。

表 2-2 学生学号数据元素表

数据元素
系统名：校园卡管理系统		编号：
条目名：学生学号		别名：
属于数据流：交易请求、确认交易信息、挂失/解挂请求、注销请求、密码修改请求、消费查询请求		存储处：D1 学生信息表 D2 校园卡信息表 D3 财务信息表
数据元素结构：代码类型取值范围意义字符型 S0000000000-S9999999999 S XX XX XX XX XX 表示学生入学年份学院代码专业代码班级号数
简要说明：学生学号是学生的识别符，每个学生都有唯一的学生学号。
修改记录：	编写：何晨烨		日期：2024.06.03
	审核：蔡安琪		日期：2024.06.03

学生信息数据存储表的存储组织为每个学生一条记录，记录数约25000，主关键字为学生学号，其中记录组成的项名和近似长度如表2-3所示，为学生信息数据存储表。

表 2-3 学生信息数据存储表

数据存储
系统名：校园卡管理系统			编号：D1
条目名：学生信息表			别名：
存储组织：每个学生一条记录	记录数：约25000			主关键字：学生学号
记录组成：项名：学生学号姓名年级所在院系专业班级联系方式近似长度：（字节） 11 5 2 8 12 2 11
简要说明：学生的基本信息情况。
修改记录：		编写：蔡安琪			日期：2024.06.03
		审核：何晨烨			日期：2024.06.04

校园卡信息数据存储表的存储组织为每张校园卡一条记录，记录数约25000，主关键字为学生学号，记录组成如表2-4所示，为校园卡信息数据存储表。

表 2-4 校园卡信息数据存储表

数据存储
系统名：校园卡管理系统			编号：D2
条目名：校园卡信息表			别名：
存储组织：每张校园卡一条记录	记录数：约25000			主关键字：学生学号
记录组成：项名：学生学号姓名专业有效期状态余额密码近似长度：（字节） 11 5 12 20 2 9999 8
简要说明：学生学号是校园卡的识别符，每张校园卡都有唯一的学生学号
修改记录：		编写：蔡安琪			日期：2024.6.4
		审核：陆徐瑛			日期：2024.6.4

财务信息数据存储表的存储组织为每张校园卡的每次消费一条记录，记录数约9999999，主关键字为学生学号，如表2-5所示，为财务信息数据存储表。

表 2-5 财务信息数据存储表

数据存储
系统名：校园卡管理系统			编号：D3
条目名：财务信息表			别名：
存储组织：每次消费一条记录	记录数：约9999999			主关键字：记录编号
记录组成：项名：记录编号学生学号姓名交易时间类型交易金额余额近似长度：（字节） 11 11 5 14 2 9999 9999
简要说明：学生消费与充值记录情况汇总
修改记录：		编写：蔡安琪			日期：2024.6.4
		审核：何晨烨			日期：2024.6.5

办理新卡数据加工表的输入数据流为个人信息、学生信息审核，输出数据流为新卡办理状态、学生信息审核结果。加工逻辑分别为学生在办理新卡时填写个人信息，提交成功后显示新卡办理状态，由管理员进行学生信息审核。学生新卡办理成功后，将学生个人信息存储到学生信息表中，并将校园卡信息存储到校园卡信息表中。如表2-6所示，为办理新卡数据加工表。

表 2-6 办理新卡数据加工表

数据加工
系统名：校园卡管理系统		编号：
条目名：办理新卡		别名：
输入数据流：个人信息、学生信息审核。		输出数据流：新卡办理状态、学生信息审核结果。
加工逻辑： 1.学生在办理新卡时填写个人信息。 2.提交成功后显示新卡办理状态。 3.管理员进行学生信息审核。审核通过后，新卡办理成功。 4.将学生个人信息存储到学生信息表中。 5.将校园卡信息存储到校园卡信息表中。
简要说明：获取学生以及校园卡的基本信息。
修改记录：	编写：陆徐瑛		日期：2024.6.5
	审核：何晨烨		日期：2024.6.5

交易功能数据加工表的输入数据流为交易请求、确认交易信息、输入密码、消费金额录入，输出数据流为交易金额、交易结果、密码结果、消费记录更新。加工逻辑分别为学生在使用交易功能时发送交易请求，管理员向系统进行消费金额录入后，系统向学生提示交易金额，学生通过校园卡输入密码，密码结果输出正确即学生确认交易信息后，系统返回交易结果，同时系统向管理员进行消费记录更新。将交易结果存储到财务信息表中，并将其中的余额存储到校园卡信息表。如表2-7所示，为交易功能数据加工表。

表 2-7 交易功能数据加工表

数据加工
系统名：校园卡管理系统		编号：
条目名：交易功能		别名：
输入数据流：交易请求、确认交易信息、输入密码、消费金额录入。		输出数据流：交易金额、交易结果、密码结果、消费记录更新。
加工逻辑： 1.学生在充值/消费时向系统发送交易请求。 2.管理员向系统进行消费金额录入后。 3.系统向学生提示交易金额。 4.学生通过校园卡输入密码。 5.密码结果输出正确，即学生确认交易信息后，系统返回交易结果。 6.系统向管理员进行消费记录更新。 7.将交易结果存储到财务信息表，并将其中的余额存储到校园卡信息表。
简要说明：对校园卡进行充值/消费。
修改记录：	编写：何晨烨		日期：2024.6.5
	审核：陆徐瑛		日期：2024.6.6

学生外部项表的输入数据流为新卡办理状态、交易结果、交易金额、挂失/解挂状态、注销结果、密码修改结果、消费清单；输出数据为个人信息、交易请求、确认交易信息、挂失/解挂请求、注销请求、密码修改请求、消费查询请求。其中本系统中的学生主要特征为：学生学号、姓名、年级、所在院系、班级、联系方式。如表2-8所示，为学生外部项表。

表 2-8 学生外部项表

外部项
系统名：校园卡管理系统	编号：
条目名：学生	别名：
输入数据流：新卡办理状态、交易结果、交易金额、挂失/解挂状态、注销结果、密码修改结果、消费清单。	输出数据：个人信息、交易请求、确认交易信息、挂失/解挂请求、注销请求、密码修改请求、消费查询请求。
主要特征：本系统中的学生主要特征为：学生学号、姓名、年级、所在院系、班级、联系方式。
简要说明：本系统负责为学生提供新卡办理状态、交易结果、交易金额、挂失/解挂状态、注销结果、密码修改结果、消费清单。
修改记录：		编写：陆徐瑛	日期：2024.6.6
		审核：何晨烨	日期：2024.6.6

校园卡外部项表的输入数据流为状态更新、更新余额、密码结果；输出数据为状态信息、交易信息、输入密码。其中本系统中的校园卡主要特征：学生学号、姓名、专业、有效期、状态、余额、密码。如表2-9所示，为校园卡外部项表。

表 2-9 校园卡外部项表

外部项
系统名：校园卡管理系统	编号：
条目名：校园卡	别名：
输入数据流：状态更新、更新余额、密码结果。	输出数据：状态信息、交易信息、输入密码。
主要特征：本系统中的校园卡主要特征为：学生学号、姓名、专业、有效期、状态、余额、密码。
简要说明：本系统负责为校园卡提供状态更新、更新余额、密码结果。
修改记录：		编写：蔡安琪	日期：2024.6.6
		审核：陆徐瑛	日期：2024.6.6

2.4 判定表

由于办卡、挂失、解挂、充值、改密、查询的处理逻辑较为简单，在数据字典中已做说明，这里就刷卡消费和注销作出处理逻辑说明。

校园卡消费判定表的条件由余额≧刷卡金额和密码是否正确组成，动作为扣费成功、扣费失败，发出警报。只有当学生余额≧刷卡金额且密码正确时，才能扣费成功，其余情况均无法扣费成功。如表2-10所示，为校园卡消费判定表。

表 2-10 校园卡消费判定表

		1	2	3
条件	余额≧刷卡金额	×	√	√
条件	密码是否正确	×	×	√
动作	扣费成功	×	×	√

校园卡注销判定表的条件由余额>0和校园卡是否完好组成，动作为返还余额、返还卡费、直接注销。只有当余额>0且校园卡完好时，才能返还余额且返还卡费。如表2-11所示，为校园卡注销判定表。

表 2-11 校园卡注销判定表

		1	2	3	4
条件	余额>0	×	×	√	√
条件	校园卡是否完好	×	√	×	√
动作	返还余额	×	×	√	√
	返还卡费	×	√	×	√
	直接注销	√	×	×	×

3 结构化系统设计

3.1 概要设计

3.1.1 建立模块结构图（SC）

模块结构图可以清楚地反映出软件模块之间的层次调用关系和联系，严格地定义了各个模块的名字，功能和接口。校园卡管理系统有办理新卡模块、交易功能模块、校园卡状态管理模块和个人账户模块。

其中办理新卡模块分为办理和登录模块；交易功能模块分为交易处理、交易信息、交易管理；校园卡状态管理模块分为状态处理、状态管理；个人账户模块分为密码信息、消费信息。如图3-1所示，为校园卡管理系统模块结构图。

图 3-1 校园卡管理系统模块结构图

3.2 详细设计

3.2.1 数据库设计

该系统是一个学生可以使用一张校园卡，多个管理员可以管理多个学生和校园卡。学生有学生学号、姓名、年级、所在院系、班级、联系方式、密码的属性。校园卡有学生学号、姓名、专业、有效期、状态、余额、密码的属性。管理员有管理员工号、密码、姓名和联系方式、工种的属性。如图3-2所示，为校园卡管理系统ER图。

图 3-2 校园卡管理系统ER图

学生信息表，用于存储后台学生的基本信息。Userid为学生学号，由学校分配，为主键；Username为学生姓名；Usergrade为学生年级；Userdepartment为学生所在院系；Usermagors为学生专业；Userclass为学生班级;Userphone为学生的联系方式；Userpassword为学生的密码，以上字段都不能为空。如表3-1所示，为学生信息表。

表 3-1 学生信息表

字段	中文描述	数据类型	是否为空	备注
Userid	学生学号	Varchar(15)	Not null	主键
Username	学生姓名	Varchar(30)	Not null
Usergrade	年级	Varchar(30)	Not null
Userdepartment	所在院系	Varchar(30)	Not null
Usermagors	学生专业	Varchar(30)	Not null
Userclass	班级	Varchar(30)	Not null
Userphone	联系方式	Varchar(30)	Not null
Userpassword	密码	Int	Not null

校园卡信息表，用于存储后台校园卡的信息。Userid为学生学号，由学校分配，为主键；Username为学生姓名；Usermagors为学生专业；Cardperiod为校园卡有效期；Cardstate为校园卡状态；Cardmoney为余额；Cardpassword为校园卡密码，以上字段都不能为空。如表3-2所示，为校园卡信息表。

表 3-2 校园卡信息表

字段	中文描述	数据类型	是否为空	备注
Userid	学生学号	Varchar(15)	Not null	主键
Username	学生姓名	Varchar(30)	Not null
Usermagors	学生专业	Varchar(30)	Not null
Cardperiod	有效期	Varchar(30)	Not null
Cardstate	状态	Varchar(15)	Not null
Cardmoney	余额	Varchar(15)	Not null
Cardpassword	密码	Int	Not null

财务信息表，用于存储后台校园卡的消费信息。Tradeid为自增长的记录编号。Userid为学生学号，为主键；Username为学生姓名；Tradetime为交易时间；Tradetype为交易类型；Trademoney为交易金额；Cardmoney为余额，以上字段都不能为空。如表3-3所示，为财务信息表

表 3-3 财务信息表

字段	中文描述	数据类型	是否为空	备注
Tradeid	记录编号	Varchar(10)	Not null
Userid	学生学号	Varchar(15)	Not null	主键
Username	学生姓名	Varchar(30)	Not null
Tradetime	交易时间	Varchar(30)	Not null
Tradetype	交易类型	Varchar(30)	Not null
Trademoney	交易金额	Varchar(15)	Not null
Cardmoney	余额	Varchar(15)	Not null

管理员信息表，用于存储后台管理员的账号信息。Adid为主键是管理员的工号；Adname为管理员的姓名；Adphone为管理员的联系方式；Adpassword为管理员的登录密码；Adjob为管理员工种，以上字段都不能为空。如表3-4所示，为管理员信息表。

表 3-4 管理员信息表

字段	中文描述	数据类型	是否为空	备注
Adid	管理员工号	Varchar(10)	Not null	主键
Adname	姓名	Varchar(30)	Not null
Adphone	联系方式	Varchar(30)	Not null
Adpassword	管理员密码	Varchar(30)	Not null
Adjob	管理员工种	Varchar(30)	Not null

3.2.2 界面设计

学生或管理员在进入校园卡管理系统是可选择登录或办理新卡的功能。

如图3-5所示，为系统首页图。

学生在办理新卡时需要输入学生学号、姓名、年级、所在院系、专业、班级、联系方式、密码。

如图3-6所示，为学生办理新卡界面图。

学生/管理员登录时需输入学号/工号、密码。如图3-7所示，为登录界面图。

学生登录成功后的首页有充值、交易清单、修改密码、校园卡挂失、解挂、注销的功能。如图3-8所示，为学生主界面图。

学生在使用充值功能时，可以选择需要充值的校园卡、充值金额、交易方式。如图3-9所示，为学生充值界面图。

学生使用交易清单功能时，显示学生在不同类型的消费曲线，可以通过选择月份，筛选交易类型，显示具体交易信息。如图3-10，为学生交易清单界面图。

学生在使用修改密码功能时，需要输入原密码、新密码、确认密码。如图3-11所示，为修改密码界面图。

学生在进行校园卡挂失、解挂、注销操作时，需要确认校园卡的姓名、学号、校园卡当前状态，并输入密码。如图3-12所示，为校园卡状态修改界面图。

管理员在登录成功后显示待处理请求：办理新卡、密码修改、个人信息、状态更新。如图3-13所示，为管理员主界面图。

管理员在处理请求信息的审核时，可以点击一键通过、通过、出错。如图3-14所示，为管理员审核界面图。

学生和管理员都有“我的”界面，显示校园卡信息、个人信息、常见问题、设置、退出登录。如图3-15所示，为“我的”界面图。图 3-15 “我的”界面图

3.2.3 过程设计【建立流程图（TFD）】

在设计学生使用校园卡进行一系列功能的主界面时先判断学生点击的按钮值，当按钮值为1时，跳转到充值页面，然后向学生显示校园卡信息、金额、充值方式，再判断是否点击充值按钮，如点击充值按钮，对充值信息进行验证，若验证通过，则完成充值，如验证失败，则回到充值界面，之后从系统中的财务信息表取出交易信息，将取出的信息更新到余额中，跳转到主界面。

当按钮值为2时，跳转到交易清单页面，显示消费分类曲线、消费具体条目，判断是否点击月份按钮，以及判断是否点击筛选按钮，若判断为否，则显示默认消费分类曲线以及消费具体条目，有一个为是，则从财务信息表中取出对应的交易记录，将取出的记录显示在条目中，跳转到主界面。

当按钮值为3时，跳转到修改密码页面，等待学生输入原密码、新密码信息，判断是否点击提交按钮，若为是则进行原密码验证，验证失败，等待学生重新输入，验证通过，则显示密码修改成功，跳转到主界面。

当按钮值4、5、6时，分别跳转到校园卡挂失、校园卡解挂、校园卡注销页面，显示学生姓名，学号和当前状态，等待学生输入密码，判断是否点击提交，若判断为是，对学生密码进行验证，密码验证失败则回到显示学生姓名，学号状态页，密码验证成功，则从校园卡信息表中取出状态信息，将取出的状态信息更新到状态栏，跳转到主界面，若没有点击提交按钮，直接跳转到主界面。

当按钮值为7时，跳转到“我的”页面，显示校园卡信息、个人信息、常见问题、设置，判断是否单击退出登录按钮，若为否跳转到主界面，若为是，程序结束。

如图3-16所示，为该校园卡管理系统中学生使用功能程序流程图。

图 3-16 学生使用功能程序流程图

在设计学生办理新卡界面时，先定义学生办理新卡的相关信息，再读入学生填写的个人信息，判断输入的学生信息是否正确，如果信息正确的话，继续判断学生信息表中是否已经存在这条信息记录，信息不正确，则返回继续读入个人信息，判断校园卡信息表是否已经存在，如果存在，则返回继续读入个人信息，不存在，则办理成功，将学生的相关信息存储到校园卡信息表。

如图3-17所示，该校园卡管理系统中学生办理新卡功能程序流程图。

图 3-17 学生办理新卡功能程序流程图

在设计学生/管理员登录界面时，先读入学生的登录信息，然后判断该信息与数据库中的信息比较是否匹配，如果信息一致的话，继续判断该信息是否在管理员信息表，如果信息不匹配的话，提示学生信息输入错误，然后返回登录界面；如果该信息在管理员信息表中，则跳转到管理员界面，如果没有在管理员信息表中，则跳转到用户界面。

如图3-18所示，为该校园卡管理系统中学生登录功能程序流程图。

图 3-18 学生登录功能程序流程图

设计管理员主界面时，先判断管理员选择按钮值，当按钮值为1时，跳转到办理新卡审核页面，读取用户信息表并显示，然后继续判断是否点击通过按钮，如果点击按钮，则显示绿色通过，如果不点击按钮，则显示红色出错，后跳转到主界面。

当按钮值为2时，跳转到密码修改审核页面，读取学生输入的密码格式表并显示，然后继续判断是否点击通过按钮，如果点击按钮，则显示绿色通过，如果不点击按钮，则显示红色出错，后跳转到主界面。

当按钮值为3时，跳转到个人信息修改审核页面，读取学生个人信息表并显示，然后继续判断是否点击通过按钮，如果点击按钮，则显示绿色通过，如果不点击按钮，则显示红色出错，后跳转到主界面。

当按钮值为4时，跳转到校园卡状态管理审核页面，读取学生校园卡信息表并显示，然后继续判断是否点击通过按钮，如果点击按钮，则显示绿色通过，如果不点击按钮，则显示红色出错，后跳转到主界面。

当按钮值为5时，跳转到“我的”页面，显示管理员信息、常见问题、设置，判断是否单击退出登录按钮，若为否跳转到主界面，若为是，程序结束。

如图3-19所示，为该校园卡管理系统中管理员使用功能程序流程图。

图 3-19 管理员使用功能程序流程图

4 面向对象分析与设计

4.1 用例图

管理员是用户的泛化，管理员和交易信息、个人账户管理、校园卡状态管理是双向关联关系。学生和办理新卡、交易功能、校园卡状态管理是双向关联关系。校园卡和校园卡状态管理、状态处理、交易管理是双向关联关系。办理新卡包含办理和登录模块；交易功能包含交易处理、交易信息、交易管理；校园卡状态管理包含状态处理、状态管理；个人账户包含密码信息、消费信息。如图4-1所示，为校园卡管理系统用例图。

图 4-1 校园卡管理系统用例图

4.2 类图

该系统有Student类，Card类和Admin类。其中User类有Userid、Username、Usergrade、Userdepartment、Usermajors、Userclass、Userphone、Userpassword属性，有register()、login()、manager_userinfo()、verifyRequest()、query_result()、display_table()方法。Card类中有Userid、Username 、Usermajors、Cardperiod、Cardstate、Cardmoney、Cardpassword属性，有register()、payment()、verifyRequest()、query_result()、display_table()方法。Admin类有Adid、Adname、Adphone、Adpassword、Adjob属性，有register()、login()、change_password()、manager_admininfo()、verifyRequest()、query_result()、display_table()方法。如图4-2所示，为校园卡管理系统类图。