实验一 需求规格说明书
1 产品介绍
1.1 项目来源
黑龙江大学是一所师生人数庞大的高校，总校设在哈尔滨南岗区，在呼兰区有分校区，全校接近2w名学生。鉴于学生和老师在学校的不方便，为了提升整体使用效率，我们准备开发一套一卡通管理系统，取代原来的人工处理方式。
1.2 项目需要解决的问题
在本次项目的酝酿和前期准备阶段，为了使项目的开发目的和范围更加明确，我们多次进行内部会议，并与项目开发小组多次以项目需求初步获取为目的进行讨论，对公司目前的业务流程和工作模式中存在的问题进行了讨论，总结出了如下需要解决的问题：
原来手工的支付方式效率低。
财务部门等各个部门间需要大量的信息交流，许多业务流程需要各个部门协同处理，共同完成信息处理和新信息生成的工作。
而在实际的工作过程中，由于交流沟通的缺乏及部门间工作步调和工作安排的不统一，部门间的协同工作总是存在各种困难。此外，一些不可避免的临时变动造成的突发状况也使部门间的合作难上加难。
由于没有寻求到很好的部门间合作的工作机制和工作方法，常常导致协同工作效率是单个部门工作效率的一半甚至更低，工作的质量和准确率也大大降低，常常需要多次协调和修改才能达到预期的目的。
1.3 项目概念
产品用途：本产品主要是为了方便同学和老师更好的在学校生活
产品性质：本产品是基于B/S架构的java网络应用系统；
产品的使用领域：完成服务同学的管理工作。
产品内容：本产品包含一个大系统，一卡通管理系统
1.4 项目目标
本项目的开发目标是帮助学校：
使信息处理复杂化的现状得以改观，从而有效地提高学校各地方管理效率；
通过制定详细合理的业务流程，规范的工作流程，统一各部门的工作步调，协调部门间的工作；
通过信息系统，为学校提供高效高质的工作机制和方法，帮助其更好的进行信息交流，优质的完成预期的工作。
2 产品面向的用户群体
本软件的最终用户为黑龙江大学所有工作师生，其主要构成同学及教学人员和学校工作人员，因此本软件在提供完善的业务处理功能的同时，将提供友好、易用、便捷的用户操作界面和简单的使用流程，以方便使用人员更好的进行操作，提高工作效率和质量。
3 产品应当遵循的标准或规范
平台约束：
本项目的开发平台为Windows操作系统（windows xp、windows vista、windows 7）；
客户端应用平台：windows操作系统；
语言约束：
本项目的开发语言为java；国际化语言系统支持中文和英语两种语言；
时间约束：
项目开发周期：6周（2016-5-8 ~ 2016-6-14）
为了使产品更好更全面的发挥其作用，其他项目可能会与本项目并行或在本项目结束后对产品的其他子系统进行开发。
4 产品的功能性需求
管理员：
办理校园卡：用户可以申请办理校园卡，软件提供学生输入注册信息的基本格式，管理员将学生信息导入数据库记录。
充值：用户需要对校园卡进行充值，学生选择充值金额，管理员对用户校园卡进行充值服务。
修改基本信息：用户需要修改基本信息，软件提供需要修改的验证和信息格式，管理员进行审核修改数据库中信息。
挂失：用户可能发生校园卡丢失，被盗。用户通过软件提交挂失申请，管理员核对信息，进行挂失，冻结其所有功能。
解挂：当用户找到校园卡时，需要恢复校园卡的基本功能，用户提交解挂申请，管理核对为其解冻，恢复其功能。
用户：
查询基本信息:学生想要查看自己的一些基本信息，软件提供个人身份信息和卡片基本信息显示：包括，账号，身份证号码，学号，余额等。
消费事务：用户需要在校园中进行各种消费事务，如餐厅，超市，洗浴等。
查询消费记录：学生每次消费完成都会留有记录，包括充值时的充值记录，软件为其提供消费记录，包括消费金额，消费时间等等。
5. 功能模型
5.1 系统总用例图
图1系统总用例图
5.2 报账系统用例描述
5.2.1 登录
用例名 | 登录 | 用例类型 业务需求 |
用例ID | MSM1101 | |
主要业务参与者 | 每个用户 | |
其他参与者 | 人员管理数据库 | |
项目相关人员兴趣 | 每个用户：希望能够方便使用ID和密码登录系统。 | |
描述 | 该用例描述了一个用户登录的过程 | |
前置条件 | 用户已经拥有了该系统的ID | |
后置条件 | 用户在该用例完成后可以进行对自己信息的管理。 | |
触发条件 | 用户开始登录时该用例被触发 | |
基本流程 | 1.用户填入登录信息 2.系统验证用户信息 3.系统向用户显示其主页。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.用户登录信息错误 1.系统向用户提示登录信息错误，询问用户是否需要密码找回服务 1a.用户选择密码找回，该用例退出转入密码找回用例 1b.用户不选择密码找回，系统退回登陆页面。 | |
结束 | 当用户成功登录，放弃登录或者选择密码找回时该用例结束。 | |
实现约束和说明 | “登录”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
用例名 | 密码找回 | 用例类型 业务需求 |
用例ID | MSM1102 | |
主要业务参与者 | 每个用户 | |
其他参与者 | 人员管理数据库、内部电子邮件系统 | |
项目相关人员兴趣 | 用户：希望能够使用该功能进行密码找回。 内部邮件系统：希望能够正确地给用户使用的邮箱发送验证码。 | |
描述 | 该用例描述了当用户忘记自己的密码后找回密码的过程。 | |
前置条件 | 用户记得自己的邮箱和用户ID但是忘记了密码。 | |
后置条件 | 用户完成修改密码 | |
触发条件 | 用户准备申请密码找回该用例被触发。 | |
基本流程 | 1.用户点击密码找回 2.系统给用户发送邮件。 3.用户收到邮件得到验证码。 4.用户输入验证码验证成功后，输入想要修改成的密码并确定。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.用户邮件地址错误 1.系统提示用户邮件地址错误。 3a.用户输入验证码时错误 1.系统提示验证码错误，请重新输入验证码。 | |
结束 | 用户完成修改密码或者放弃该操作。 | |
实现约束和说明 | “密码找回”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.2 查找消费记录
用例名 | 查找消费记录 | 用例类型 业务需求 |
用例ID | MSM1201 | |
主要业务参与者 | 用户 | |
其他参与者 | 人员管理数据库、流水管理数据库 | |
项目相关人员兴趣 | 用户：希望能够看到自己近期的消费记录。 流水管理数据库：希望能够成功反馈给用户想要查看的消费记录。 | |
描述 | 该用例描述了用户查找消费记录的过程。 | |
前置条件 | 用户成功登录系统，通过身份验证。 | |
后置条件 | 系统反馈给用户想要查看的消费记录。 | |
触发条件 | 当用户选择查找消费记录时该用例被触发。 | |
基本流程 | 1．登录系统，通过身份验证 [用户]：用户选择进入“查找消费记录”功能。 [系统]：检查用户卡的状态是否为正常，若正常则获得该用户最近的50条消费记录。 2.系统反馈给用户上个过程中获得的消费记录。 | |
替代流程 | 1a.用户卡状态为冻结 1.系统提示卡为冻结状态无法提供查找消费记录服务，请用户解挂后再进行该项业务。 2a.用户消费记录不足50条 1.系统获得全部消费记录并反馈给用户。 | |
结束 | 用户查看到自己的消费记录。 | |
实现约束和说明 | “查找消费记录”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.3 办卡
用例名 | 办卡 | 用例类型 业务需求 |
用例ID | MSM1301 | |
主要业务参与者 | 用户 | |
其他参与者 | 管理员，人员管理数据库 | |
项目相关人员兴趣 | 用户：希望能够成功办卡，用于各种事务。 管理员：希望能成功给用户办卡。 人员管理数据库：希望能够成功录入用户信息。 | |
描述 | 该用例描述了用户办卡的过程。 | |
前置条件 | 无 | |
后置条件 | 用户通过该流程完成校园卡的办理。 | |
触发条件 | 当用户选择办卡时该用例被触发。 | |
基本流程 | 1.用户选择进入办卡功能。 2.系统提示用户输入基本信息，完成注册。 3.用户输入基本信息。 4.人员管理数据库检索登记用户表中是否存在该用户的学号，如果有则进行下一步检索。 5.人员管理数据库检索办卡用户表中是否存在该用户，若不存在，则将该用户添加到办卡用户表中。 6.用户完成办卡业务。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.人员管理数据库检索不到用户的学号 1.系统提示用户学号输入有误，请重新输入。 3a.人员管理数据库检索到办卡用户表中已经存在该用户 1.系统提示用户该学号已经开通校园卡，无需再次开通。 | |
结束 | 用户完成校园卡的办理。 | |
实现约束和说明 | “办卡”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.4 解挂与挂失
用例名 | 解挂与挂失 | 用例类型 业务需求 |
用例ID | MSM1401 | |
主要业务参与者 | 用户 | |
其他参与者 | 管理员、内部电子邮件系统 | |
项目相关人员兴趣 | 用户：希望能够改变自己卡的状态。 管理员：希望能成功给用户改变卡的状态。 内部电子邮件系统：希望能够成功给用户的邮箱发送验证码。 | |
描述 | 该用例描述了用户对卡进行解挂或挂失的过程。 | |
前置条件 | 用户成功登录系统，通过身份验证。 | |
后置条件 | 用户通过该流程完成对卡的解挂或者挂失。 | |
触发条件 | 当用户选择解挂或者挂失时该用例被触发。 | |
基本流程 | 1．登录系统，通过身份验证 [用户]：用户选择进入“挂失”（“解挂”）功能。 [系统]：检查用户卡的状态是否为冻结（正常）。 2.内部电子邮件系统向用户的邮箱发送验证码。 3.用户接到验证码并输入验证码。 4.验证码验证成功后，选择对卡进行挂失（解挂）。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.用户卡状态为冻结（正常） 1.系统提示卡为冻结（正常）状态无法继续进行挂失（解挂）。 3a.用户邮箱输入错误 2.系统提示用户邮箱输入错误请重新输入。 4a.用户验证码输入错误 1.系统提示验证码输入错误请重新输入验证码。 | |
结束 | 用户完成改变自己卡的状态。 | |
实现约束和说明 | “解挂”模块与“挂失”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.5 修改基本信息和查询基本信息
用例名 | 修改基本信息 | 用例类型 业务需求 |
用例ID | MSM1501 | |
主要业务参与者 | 用户 | |
其他参与者 | 管理员、人员管理数据库 | |
项目相关人员兴趣 | 用户：希望能够修改自己的基本信息。 管理员：希望能成功给用户修改基本信息。 人员管理数据库：希望能够成功修改用户信息。 | |
描述 | 该用例描述了用户修改基本信息的过程。 | |
前置条件 | 用户成功登录系统，通过身份验证。 | |
后置条件 | 用户通过该流程完成对基本信息的修改。 | |
触发条件 | 当用户选择修改基本信息时该用例被触发。 | |
基本流程 | 1．登录系统，通过身份验证 2.用户选择进入“修改基本信息”功能。 3.系统提示用户选择修改哪个基本信息。 4.用户修改完成后人员管理数据库将修改后的该用户的数据导入用户登记表中。 5.用户完成修改基本信息。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 | |
结束 | 用户完成修改基本信息。 | |
实现约束和说明 | “修改基本信息”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
用例名 | 查询基本信息 | 用例类型 业务需求 |
用例ID | MSM1502 | |
主要业务参与者 | 用户 | |
其他参与者 | 管理员、人员管理数据库 | |
项目相关人员兴趣 | 用户：希望能够查询到自己的基本信息。 管理员：希望能成功给用户查询基本信息。 人员管理数据库：希望能够成功查询到用户信息并反馈给系统。 | |
描述 | 该用例描述了用户查询基本信息的过程。 | |
前置条件 | 用户成功登录系统，通过身份验证。 | |
后置条件 | 用户通过该流程完成对基本信息的查询。 | |
触发条件 | 当用户选择查询基本信息时该用例被触发。 | |
基本流程 | 1．登录系统，通过身份验证 2.用户选择进入“查询基本信息”功能。 3.人员管理数据库检索该用户并通过系统将其基本信息反馈给用户。 4.用户完成查询基本信息。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 | |
结束 | 用户完成查询基本信息。 | |
实现约束和说明 | “查询基本信息”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.6 充值
用例名 | 充值 | 用例类型 业务需求 |
用例ID | MSM1601 | |
主要业务参与者 | 用户 | |
其他参与者 | 管理员、流水管理数据库、银行系统 | |
项目相关人员兴趣 | 用户：希望能够往自己卡中充值。 管理员：希望能辅助用户完成充值。 流水管理数据库：希望能记录用户充值金额。 银行系统：希望能检测卡号是否正确和密码是否输入正确。 | |
描述 | 该用例描述了用户充值的过程。 | |
前置条件 | 用户成功登录系统，通过身份验证。 | |
后置条件 | 用户通过该流程完成对校园卡的充值。 | |
触发条件 | 当用户选择充值时该用例被触发。 | |
基本流程 | 1．登录系统，通过身份验证 2.用户选择进入“充值”功能。 3.系统提示用户输入银行卡号。 4.用户输入卡号，银行模块校验卡号是否存在。 5.系统提示用户选择充值金额。 6.用户选择充值金额，并输入银行卡密码。 7.银行模块检测卡号与密码是否匹配。 8.流水管理数据库把此次用户充值金额记录在用户充值记录表中。 9.系统提示充值完成。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.用户输入的银行卡号不存在 1.系统提示卡号不存在请重新输入。 3a.用户输入的密码不正确 1.系统提示密码错误请重新输入。 4a.银行卡中余额不足 1.系统提示卡中余额不足无法完成充值。 | |
结束 | 用户完成充值操作。 | |
实现约束和说明 | “充值”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.2.7消费事务
用例名 | 消费事务 | 用例类型 业务需求 |
用例ID | MSM1701 | |
主要业务参与者 | 用户 | |
其他参与者 | 流水管理数据库 | |
项目相关人员兴趣 | 用户：希望能使用卡完成消费事务。 流水管理数据库：希望能记录用户每次的消费情况。 | |
描述 | 该用例描述了用户使用校园卡消费的过程。 | |
前置条件 | 用户卡处于正常状态。 | |
后置条件 | 用户通过该流程完成使用校园卡进行消费。 | |
触发条件 | 当用户选择消费时该用例被触发。 | |
基本流程 | 1.用户进入“消费”功能。 2.系统检测用户卡的状态是否为正常。 3.系统获取待支付金额并反馈给用户。 4.检测用户卡中余额是否足够支付当前金额。 5.卡中余额减少，完成支付。 | |
替代流程 | 1a.任何时刻发生以下情况，系统将会自动退出 1.用户电脑断电。 2.用户网络中断。 2a.用户卡状态为冻结状态 1.系统提示卡处于冻结状态，暂时无法使用，请解挂后再用。 3a.用户中余额不足 1.系统提示用户余额不足，无法继续付款。 2.付款中止。 | |
结束 | 用户完成消费事务。 | |
实现约束和说明 | “消费事务”模块为Java图形界面，内部工作人员也为Java图形界面。 | |
5.3 登录用例活动图
登录活动图
5.4 密码找回用例活动图
密码找回活动图
5.5 办卡用例活动图
办卡活动图
5.6 充值用例活动图
充值活动图
5.7 查询基本信息用例活动图
查询基本信息活动图
5.8 挂失用例活动图
挂失活动图
6 产品的非功能需求
6.1 软硬件环境需求
6.1.1 硬件环境
分类 | 推荐配置 | 最低配置 | |
数据库服务器 | CPU | 英特尔迅驰双核处理器 | 英特尔酷睿2双核处理器 |
内存 | 2GB | 1GB | |
硬盘 | 160GB | 120GB | |
网卡 | 100M | 10M | |
应用服务器 | CPU | 英特尔酷睿2双核处理器 | 英特尔酷睿1处理器 |
内存 | 3GB | 1GB | |
硬盘 | 120GB | 80GB | |
网卡 | 100M | 10M | |
网络 | 带宽 | 100M | 10M |
客户端 | CPU | 英特尔酷睿2双核处理器 | 英特尔奔腾3处理器 |
内存 | 2GB | 1GB | |
硬盘 | 160GB | 120GB | |
网卡 | 100M | 10M | |
6.1.2 软件环境
分类 | 名称 | 版本 | 语种 |
操作系统 | Windows | XP | 中文 |
操作系统的附加功能 | ODBC数据源管理工具 | 中文 | |
数据库平台 | Microsoft SQL Server | 2000 | 中文 |
数据库平台补丁 | — | sp4 | — |
数据库驱动 | SQL Server Driver For JDBC | sp4 | — |
应用平台 | Windows | XP/Vista | 中文 |
浏览器 | 各种功能完善、运行稳定的浏览器 | eg. IE、遨游等 | 中文 |
客户端软件 | Windows | XP/Vista | 中文 |
邮件系统 | SMTP POP3 | — |
6.2 产品质量需求
6.2.1 精度
本系统中输入的各种数据均要求精确到小数点后2位。
6.2.2 时间特性的要求
搜索查询时间最大不超过7秒。
页面平均处理及响应时间在3—10秒以内，最大不超过10秒。
页面平均更新响应时间为3秒左右，最大不超过7秒。
6.2.3 灵活性
操作方式的变化：如果公司的业务情况或业务逻辑出现变化，导致本系统需求发生变化，在可接受的范围内，要求本系统能够及时完成需求变更及各项相关的处理工作，实现新的需求。
运行环境的变化：本系统支持各种功能完善、成熟的电脑系统，精度和有效时限的变化：如果公司提出要求改变精度和有效时限，在可接受的范围内，接受并实现其需求变更。
开发计划的变化或改进：在可接受的范围内，本系统的开发工作将积极开发配合计划的变化或改进。
6.2.4 输入输出要求
本系统的输入数据类型主要是整形、浮点型和字符串类型；输出以字符串、整形、浮点型及各类3D图表为主。
7 词汇表
名称 | 描述 |
用户 | 一卡通的正式用户 |
管理员 | 负责审批用户功能和请求的管理者，是较高级别的用户。 |
流水管理数据库 | 与用户消费有关的某一项具体的花费，包括消费发生的时间、地点、客户名称（可选）、原因以及费用金额和种类（交通、餐饮、会议、通信和杂项）。 |
报销单 | 员工在一个（自然）月内的所有报销记录的集合。 |
人员管理数据库 | 该数据库中记录了有关用户的相关信息 |
内部邮件系统 | 该邮件系统负责收发与公司业务有关的电子邮件信息。 |
实验二 领域模型
1 概念类分析
1.1 登录用例概念类分析
概念类名 | 属性 | 描述 |
用户 | 卡号 密码 | 用户可通过卡号密码登录系统进行修改基本信息，查询记录等操作 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.2办卡用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 姓名 卡号 密码 学号 余额 状态 | 描述用户个人信息，包括用户的姓名，学号以及用户校园卡的卡号。 校园卡基本信息，包括卡中当前余额，所处状态（冻结或正常） |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.3 充值用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 卡号 学号 余额 | 向卡中的余额充值，记录充值记录。用户登录后对卡进行充值 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.4挂失用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 卡号 学号 状态 | 将卡的状态设置成冻结，无法进行消费等事务 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.5 解挂用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 卡号 学号 状态 | 将卡的状态设置成正常，可以进行消费等事务 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.6查询消费记录用例概念类分析
概念类名 | 属性 | 描述 |
消费记录 | 消费时间 消费类型 消费金额 | 记录用户消费明细，方便用户查询。当用户查找消费记录时选择查找时间段的消费记录，系统反馈给用户对应的消费类型--消费金额--消费时间。 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.7 消费事务用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 卡号 余额 消费记录 | 用户进行消费时使用卡中余额消费，记录当前的消费类型，消费金额，消费时间 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
1.8 密码找回用例概念类分析
概念类名 | 属性 | 描述 |
用户 校园卡 | 卡号 密码 | 用户通过电子邮件收到的验证码修改自己的密码 |
管理员 | 姓名 管理员编号 | 管理员基本信息 |
2 领域模型（概念类图）
2.1 登录
登录概念类图（领域模型图）
2.2 密码找回
密码找回概念类图（领域模型图）
2.3 充值
充值概念类图（领域模型图）
2.4 办卡
办卡概念类图（领域模型图）
2.5 挂失解挂
挂失解挂概念类图（领域模型图）
2.6 查询基本信息
查询基本信息概念类图（领域模型图）
2.7 消费系统
消费系统概念类图（领域模型图）
3 系统顺序图
3.1 登录系统顺序图
3.2 消费系统顺序图
3.3 充值系统顺序图
3.4 密码找回系统顺序图
3.5 办卡系统顺序图
3.6 修改基本信息系统顺序图
3.7 解挂与挂失系统顺序图
3.8 查询消费记录系统顺序图
实验三 详细设计报告
1 提交报销申请—系统实现
1.1 顺序图
提交报销申请用例实现之顺序图
1.2 类图
实现提交报销申请的类图如图所示。
提交报销申请用例实现之设计类图
类图说明：
模块名 | 类名 | 说明 |
报账管理—提交报销申请 | Claim_report | 报销单类，存储报销的信息，需长期保存 |
Claim_record | 报销记录类，存储存储一次报销的各个分享，需长期保存 | |
Employee | 员工类，信息从人事管理数据库提取 | |
Valid_rule | 校验规则类，信息需长期保存 | |
Submit_claim | 控制器类，起协调作用 | |
SubmitClaimForm | 界面类，实现时是界面的抽象 | |
I_HRDatabase | 接口—负责从人事管理数据库提取信息 | |
HRDatabase | 实现类—实现I_HRDatabase接口 | |
I_Mailsystem | 实现类—实现I_Mailsystem |
2 系统管理—日常维护—系统实现
略。
若觉得有帮助，欢迎点赞关注，一起成长进步~
声明：本文仅供学习交流，禁作商用；禁篡改、歪曲及有偿传播，引用需标明来源。侵权必究。
