大二打卡（12.25）

uml作业：

系统分析报告：

1.1编写目的

校园卡管理系统软件设计说明书旨在详细阐述校园卡管理系统的设计理念、功能需求、技术实现等方面的内容。这份说明书的主要目的是为软件开发团队提供一个明确的开发指导，确保所有相关人员对项目的目标和要求有统一的理解。同时，它也是项目进度和质量控制的重要依据。

 

预期的读者范围主要包括以下几类人员：

 

软件开发团队：需要了解整个系统的设计细节，以便能够准确实现各项功能。

项目管理人员：需要全面了解项目进展情况，以便进行有效的项目管理和协调。

系统用户：需要了解系统的功能和使用方法，以便能够更好地使用系统。

维护人员：需要了解系统的内部结构和维护方法，以便在系统出现问题时能够及时解决。

总之，校园卡管理系统软件设计说明书旨在为项目相关人员提供一个全面的开发和使用指导，确保项目能够顺利完成并达到预期的目标。

 

1.2项目背景

根据之前的讨论，我们将要开发的软件系统名称为“校园卡管理系统”。该系统的主要作用是管理校园卡的相关业务，包括卡片的发行、充值、挂失、解挂、补办以及消费记录查询等功能。

 

以下是关于该软件系统的作用范围的详细说明：

 

发行和激活校园卡：系统能够接受新用户注册，生成唯一的校园卡卡号，并将相关信息存储在数据库中。同时，系统能够为新用户激活校园卡，使其具备使用系统的权限。

 

充值和消费管理：系统支持用户对校园卡进行充值，并能够根据用户消费情况自动扣费。同时，系统能够提供实时的消费记录查询，方便用户了解自己的消费情况。

 

挂失和解挂服务：当校园卡丢失或被盗用时，用户可以通过系统进行挂失操作，以避免卡内资金流失。如果校园卡被找回，用户还可以通过系统进行解挂操作，重新启用卡片。

 

补办服务：当校园卡损坏或遗失时，用户可以通过系统进行补办申请。系统将重新生成一张新的校园卡，并将相关信息更新到数据库中。

 

消费记录查询：系统支持用户查询自己的消费记录，包括消费时间、地点、金额等信息。这有助于用户了解自己的消费情况，便于管理和规划自己的财务。

 

身份认证门禁解锁服务：用户在校园内的门禁处，将校园卡靠近读卡器或使用手机APP进行身份验证系统通过读卡器或手机APP获取用户的校园卡信息，并与数据库中的信息进行比对，确认用户的身份。如果用户信息匹配成功，系统将自动解锁门禁，允许用户进入。如果用户信息不匹配或出现异常情况，系统将拒绝解锁门禁，并提示用户重新验证或联系管理人员处理。系统会自动记录每次门禁解锁的时间、地点和用户信息，以便后续审计、考勤和查询。用户可以通过手机APP查看自己的门禁解锁记录，了解自己的进出情况和历史记录。管理人员可以通过系统后台查看门禁解锁的统计数据和日志，以便监控和管理校园内的安全情况。

 

除此之外，该软件系统还有以下不涉及的范围：

 

个人信息管理：本系统主要关注于校园卡的管理和相关业务处理，不涉及用户的个人信息管理。用户的个人信息存储在其他相应的系统中。

财务管理：本系统只负责执行校园卡的充值、扣费等操作，不涉及具体的财务管理和账务处理。这些任务由学校财务部门负责。

校园内其他服务：本系统主要服务于校园卡的业务处理，不涉及校园内的其他服务或设施。例如，图书馆借阅、宿舍管理等其他相关业务由相应的管理系统处理。

 

综上所述，本软件系统旨在提供一个全面、便捷的校园卡管理平台，方便用户进行卡片管理、查询和相关业务操作。同时，也确保了系统的功能范围明确，与其他管理系统保持清晰的边界划分。

1.3术语定义

无

 

 

 

2软件产品的一般性描述

 

2.1运行环境

一、软件运行环境：

 

操作系统：考虑到校园卡管理系统的稳定性和安全性，建议采用成熟、稳定的操作系统，如Windows Server 2016或更高版本。

数据库：为了存储和管理大量的用户信息和交易记录，需要使用关系型数据库管理系统，如MySQL或SQL Server。

应用服务器：选用Tomcat或Nginx等应用服务器软件，提供Web服务、API接口等功能。

其他软件：为确保系统的正常运行，可能还需要一些常用的开发工具、中间件和其他软件组件。

二、网络运行环境：

 

网络架构：校园卡管理系统应具备稳定、高效的网络架构，包括核心交换机、汇聚交换机、接入交换机等设备，以确保数据传输的可靠性和速度。

网络协议：建议采用TCP/IP协议，确保数据传输的稳定性和安全性。

网络安全：应采取相应的网络安全措施，如防火墙、入侵检测系统等，以保护系统的安全和用户的隐私。

三、硬件运行环境：

 

服务器：选用高性能的服务器，配置适当的CPU、内存和存储资源，以满足系统的处理能力和数据存储需求。

存储设备：考虑采用分布式存储或集中式存储方案，以满足海量数据的高效存储和管理。

其他硬件：根据实际需求，可能还需要UPS电源、机柜、打印机等相关硬件设备。

2.3系统业务需求用例描述

校园卡管理系统业务需求用例描述

 

一、开户用例

 

执行者：普通用户

类型：基本的、主要的

前置条件：用户需要提供有效的身份证明

基本路径：

a. 用户通过系统提供的注册界面输入必要的信息，包括姓名、学号、联系方式等。

b. 系统验证用户输入的信息是否完整、准确。

c. 如果信息验证通过，系统将为用户生成唯一的校园卡卡号，并将其保存到数据库中。

d. 系统向用户发送确认邮件或短信，通知其开户成功并告知其初始密码。

e. 用户收到确认信息后，可以使用自己的学号和初始密码登录系统。

二、充值用例

 

执行者：普通用户

类型：扩展的、常见的

前置条件：用户已登录系统，账户余额不足

基本路径：

a. 用户在系统中选择充值操作。

b. 系统显示充值页面，要求用户输入充值金额。

c. 用户输入充值金额后，系统验证金额是否符合限制条件（例如，不得超过账户余额上限）。

d. 系统处理充值请求，将充值金额存入用户账户。

e. 系统更新用户账户余额，并显示新的账户余额。

f. 系统记录充值记录，以便后续查询和审计。

三、消费用例

 

执行者：普通用户

类型：扩展的、常见的

前置条件：用户已持有校园卡，并在有效期内使用。

基本路径：

a. 用户在校园内支持校园卡消费的场所（例如，食堂、超市、图书馆等）进行消费。

b. 用户将校园卡靠近读卡器或使用手机APP进行身份验证。

c. 系统验证用户身份，并获取卡内余额。

d. 系统验证消费金额是否符合限制条件（例如，不得超过账户余额上限）。

e. 系统处理消费请求，扣除相应金额，并更新账户余额。

f. 系统显示消费成功信息，并打印消费凭证（如果需要）。

g. 系统记录消费记录，以便后续查询和审计。

四、挂失与解挂用例

 

执行者：普通用户

类型：扩展的、常见的

前置条件：用户已登录系统，校园卡丢失或被盗用。

基本路径：

a. 用户在系统中选择挂失操作。

b. 系统验证用户身份并确认挂失请求。

c. 系统将校园卡状态标记为挂失状态，并冻结账户。

d. 系统提示操作成功，并告知用户尽快补办新卡。

e. 如果用户找到自己的校园卡，可以申请解挂操作。系统验证用户身份并确认解挂请求。

f. 系统将校园卡状态标记为正常状态，并恢复账户功能。

g. 系统提示操作成功，并更新校园卡状态。

h. 系统记录挂失与解挂记录，以便后续查询和审计。

五、补办用例

 

执行者：普通用户、系统管理员

类型：扩展的、常见的

前置条件：用户已挂失校园卡或校园卡损坏。

基本路径：

a. 用户在系统中选择补办操作。

b. 系统验证用户身份并确认补办请求。

c. 系统生成新的校园卡卡号，并将相关信息更新到数据库中。

六、身份识别与认证

 

执行者：普通用户、系统管理员

类型：扩展的、常见的

前置条件：用户已持有校园卡

基本路径：

a. 用户在需要进行身份验证的场所（例如，图书馆、实验室、会议室等）进行身份验证。

b. 用户将校园卡靠近读卡器或使用手机APP进行身份验证。

c. 系统验证用户身份，并与数据库中的信息进行比对，确认用户的身份。

d. 如果用户信息匹配成功，系统允许用户进入相应场所。

e. 如果用户信息不匹配或出现异常情况，系统拒绝用户进入，并提示重新验证或联系管理人员处理。

f. 系统记录每次身份验证的时间、地点和用户信息，以便后续审计和查询。

g. 管理员可以通过系统后台查看身份验证的统计数据和日志，监控和管理校园内的安全情况。

七、门禁控制

 

执行者：普通用户、系统管理员

类型：扩展的、常见的

前置条件：用户已通过身份验证

基本路径：

a. 用户在门禁处通过读卡器或手机APP进行身份验证。

b. 系统验证用户身份并获取门禁权限。

c. 如果用户拥有相应的门禁权限，系统自动解锁门禁，允许用户进入。

d. 如果用户没有相应的门禁权限或出现异常情况，系统拒绝解锁门禁，并提示用户联系管理人员处理。

e. 系统自动记录每次门禁控制的时间、地点和用户信息，以便后续审计和查询。

f. 管理员可以通过系统后台查看门禁控制的统计数据和日志，监控和管理校园内的安全情况。

八、考勤

 

执行者：普通用户、系统管理员、教师等教职员工

类型：扩展的、常见的

前置条件：用户已通过身份验证并到达考勤地点

基本路径：

a. 用户在考勤地点通过读卡器或手机APP进行考勤操作。

b. 系统验证用户身份并记录考勤时间。

c. 如果用户按时到达考勤地点，系统将其标记为正常考勤。

d. 如果用户迟到或未到达考勤地点，系统将其标记为异常考勤。

e. 系统自动记录每次考勤的时间和地点，并将考勤数据保存到数据库中。

f. 教师等教职员工可以通过系统后台查看学生的考勤记录，以便对学生的出勤情况进行管理和评估。

 

 

3系统结构分析

3.1系统静态结构关系分析说明

校园卡管理系统类图模型说明如下：

1. 用户类（User）：
• 属性：用户ID、姓名、学号、联系方式等。
• 方法：登录、充值、消费、挂失、解挂等操作。
2. 管理员类（Administrator）：
• 属性：管理员ID、姓名、联系方式等。
• 方法：用户管理、账户管理、挂失管理、数据管理等操作。
3. 校园卡类（Card）：
• 属性：卡号、卡片状态（挂失/正常）、余额等。
• 方法：充值、消费、挂失、解挂等操作。
4. 数据库类（Database）：
• 属性：数据库连接信息。
• 方法：查询、更新、插入、删除等操作。
5. 系统类（System）：
• 属性：系统配置信息。
• 方法：系统初始化、系统登录、系统退出等操作。
6. 界面类（Interface）：
• 属性：界面元素（如按钮、文本框等）。
• 方法：响应用户操作、显示结果等。
7. 日志类（Log）：
• 属性：日志信息。
• 方法：记录日志、查询日志等操作。
8. 安全类（Security）：
• 属性：加密算法、身份验证方式等。
• 方法：加密、解密、身份验证等操作。
9. 通知类（Notification）：
   一卡通管理系统实际是在在线数据操作实现校园数据共享的一个平台，为校园管理人员的管理工作提供方便，管理员网上办公对信息进行相应操作及信息获取，提高利用率及工作效率。使校园一卡通管理信息系统的管理更规范化、系统化、自动化，更加方便客户查询、账户挂失、充值等功能。

 

3.2系统体系结构分析说明

校园卡管理系统结构包图主要包括以下几个部分：

 

一、用户管理模块

 

此模块主要负责管理校园卡用户的基本信息，包括但不限于用户注册、用户登录、信息修改等功能。

 

二、账户管理模块

 

此模块负责对校园卡账户的管理，如账户余额查询、充值、消费记录查询等。

 

三、消费管理模块

 

此模块主要负责管理校园卡用户的消费记录，包括：

 

消费场所管理：记录和管理校园内的消费场所信息，如食堂、超市、图书馆等。

消费操作：用户在消费场所进行消费时，通过刷卡或手机APP进行支付，系统自动扣除账户余额或与支付平台对接完成支付。

消费记录查询：用户可以查询自己的消费记录，了解消费明细和消费场所。

数据分析与报告：系统可以对消费数据进行统计和分析，生成消费报告，为学校管理层提供决策支持。

 

四、充值模块

 

充值方式：用户可以通过现金、银行卡转账、第三方支付等方式为校园卡账户充值。系统应支持多种充值方式以满足不同用户的需求。

 

充值记录查询：用户可以查询自己的充值记录，了解充值时间和金额等信息。

 

充值限额与通知：系统可以根据用户的需求设置充值限额和通知功能。当账户余额低于一定值时，系统可以发送提醒通知给用户或管理员。同时，为了确保资金安全，系统还可以设置单次充值最高限额和日充值累计限额等限制条件。

 

五、门禁管理模块

 

此模块主要负责管理校园卡用户的门禁权限，如门禁开启、关闭、进出记录查询等。

 

六、挂失解挂模块

 

此模块主要处理校园卡用户的挂失和解挂请求，包括挂失申请、解挂申请等操作。

 

七、身份识别与认证模块

 

此模块是校园卡管理系统的重要组成部分，主要负责用户的身份验证和识别。具体功能如下：

 

身份认证：用户在使用校园卡进行各种操作时，系统会通过读卡器读取校园卡信息，并通过与数据库中存储的用户信息进行比对，确认用户的身份。同时，系统还可以通过生物识别技术（如指纹识别、面部识别等）进行双重身份验证，提高系统的安全性。

 

权限管理：基于用户的身份和角色，系统可以对其开放不同的权限。例如，学生可能只有门禁进出和食堂消费的权限，而教师可能拥有更多的权限，如图书馆借阅、实验室管理等。系统会根据用户的身份和角色，为其分配相应的权限，确保系统的安全性和可靠性。

 

记录查询：系统可以记录每次身份验证的时间、地点和用户信息，并保存在数据库中。管理员可以通过后台查询这些记录，了解校园卡的使用情况和管理情况，以便进行审计和安全管理。同时，用户也可以通过系统查询自己的身份验证记录，了解自己的使用情况。

 

报警功能：当系统检测到异常情况时，如未经授权的人员进入敏感区域、多次尝试密码错误等，系统会触发报警功能，并通过声光电等方式提醒管理人员和用户，以便及时处理和解决。

 

这些模块相互协作，共同构成了校园卡管理系统的整体结构。通过结构包图，可以清晰地展示各个模块之间的关系和依赖，有助于对系统进行整体规划和设计。同时，结构包图也有助于后续的开发和维护工作，提高了系统的可维护性和可扩展性。

3.3系统部署分析说明

校园卡管理系统部署图分析

 

一、系统架构

 

校园卡管理系统采用三层架构设计，包括数据层、业务逻辑层和用户界面层。数据层负责存储和处理数据，业务逻辑层负责实现校园卡管理的各项业务逻辑，用户界面层负责与用户进行交互。

 

二、硬件部署

 

服务器：部署数据库服务器和应用程序服务器，用于存储和处理校园卡数据、处理用户请求等。

网络设备：部署路由器、交换机、防火墙等网络设备，保障校园卡管理系统的网络安全和数据传输速度。

读卡器：在各个消费场所和门禁通道设置读卡器，用于读取校园卡信息。

终端设备：包括PC、移动设备等，用于管理人员和用户进行操作和管理。

三、软件部署

 

数据库软件：选择合适的数据库管理系统，如MySQL、Oracle等，用于存储和处理校园卡数据。

应用程序软件：开发或购买适合校园卡管理的应用程序软件，用于处理用户请求、管理校园卡数据等。

操作系统：选择适合服务器和终端设备的操作系统，如Windows Server、Linux等。

中间件：选择适合系统架构的中间件，如Tomcat、WebSphere等，用于实现跨平台通信和集成。

四、安全部署

 

防火墙：设置防火墙规则，限制外部访问和攻击，保障校园卡管理系统的网络安全。

数据加密：对敏感数据进行加密存储，保证数据的安全性。

权限控制：对不同用户设置不同的权限，保证系统的安全性。

备份与恢复：定期备份数据，并制定相应的恢复方案，确保数据安全。

五、部署流程

 

需求分析：对校园卡管理需求进行详细分析，明确系统功能和性能要求。

设计规划：根据需求分析结果，进行系统架构设计、硬件和软件选型等工作。

部署实施：按照设计规划进行硬件和软件的安装与配置，确保系统的稳定性和安全性。

测试验收：对系统进行全面测试，确保各项功能正常并符合要求；对不合格部分进行整改和完善。

上线运行：系统正式上线运行，管理人员和用户可以正常使用校园卡管理系统。

维护升级：定期对系统进行维护和升级工作，保证系统的稳定性和安全性；对用户提供技术支持和服务。

 

 

4系统功能行为分析

4.1系统业务流程说明

校园卡管理系统业务流程说明

 

一、概述

 

校园卡管理系统是学校为了方便师生在校园内的消费、身份认证和门禁管理而建立的一套信息化管理系统。该系统通过校园卡这一介质，实现了对师生在校园内各项活动的管理和服务。

 

二、业务流程

 

制卡与发卡

学校根据新生录取信息和教职工入职信息，制作相应的校园卡，并在新生报到和教职工入职时发放。校园卡内包含持卡人的基本信息和账户信息。

 

充值与退款

持卡人可以通过现金、银行卡转账等方式为校园卡账户充值。当持卡人需要退款时，可以向卡务中心提出申请，经审核后办理退款手续。

 

消费与结算

持卡人在校园内的消费场所（如食堂、超市、图书馆等）使用校园卡进行消费。消费时，系统通过读卡器读取校园卡信息，并从账户中扣除相应金额。消费记录会实时上传至校园卡管理系统，供持卡人查询和核对。

 

身份认证与门禁管理

校园卡也是师生在校园内的身份凭证。持卡人可以使用校园卡进行身份认证，如进入图书馆、实验室等需要身份验证的场所。同时，校园卡还可以作为门禁卡使用，持卡人通过刷卡进出校门和宿舍楼等区域。

 

挂失与补办

当持卡人遗失校园卡时，应及时到卡务中心办理挂失手续，防止卡片被他人冒用。挂失后，持卡人可以申请补办新卡，原卡将作废。补办新卡需要支付一定的工本费。

 

退卡与注销

当持卡人毕业、离职或不再需要使用校园卡时，可以到卡务中心办理退卡手续。退卡时，持卡人需要归还校园卡并结清账户余额。同时，系统会将持卡人的相关信息进行注销处理。

 

三、系统支持与服务

 

为了确保校园卡管理系统的正常运行和服务质量，学校设立了专门的卡务中心负责管理和维护工作。同时，系统还提供了在线客服、电话咨询等多种服务渠道，方便师生随时咨询和解决问题。

4.2系统交互说明

校园卡管理系统交互说明

 

一、交互界面与操作方式

 

终端界面：提供友好的用户界面，支持触摸、刷卡、密码输入等多种交互方式。

移动应用界面：通过手机APP或微信公众号，用户可以随时查看账户信息、进行充值和挂失等操作。

自助服务终端：提供自助充值、查询等功能的终端设备，方便用户自行操作。

网页管理界面：为管理员提供后台管理界面，实现对校园卡系统的全面管理。

二、数据交互流程

 

读卡器读取数据：当用户使用校园卡进行消费、门禁等操作时，读卡器会读取卡片信息并传输至系统。

数据验证与处理：系统对接收到的数据进行验证，确保数据的真实性和有效性。根据操作类型（消费、门禁等）进行相应处理，如扣款、开锁等。

记录与反馈：系统记录操作日志，并将结果反馈给用户或管理员，如显示扣款金额、门禁状态等。

数据同步与备份：系统实时同步数据至数据库，确保数据安全。同时，定期对数据进行备份，防止数据丢失。

三、系统间交互

 

与财务系统交互：校园卡消费数据与财务系统对接，实现自动对账和结算。

与身份认证系统交互：校园卡身份信息与学校身份认证系统对接，实现统一身份认证。

与其他管理系统交互：如图书馆管理系统、宿舍管理系统等，实现数据共享和互操作。

四、安全与隐私保护

 

数据加密传输：所有敏感数据在传输过程中均进行加密处理，确保数据安全。

多层次验证机制：采用多因素认证方式（如密码、指纹、动态短信等）确保操作安全。

访问控制与权限管理：对不同用户设置不同的访问权限，确保数据不被非法访问或篡改。

隐私保护：在合法合规的前提下，严格控制敏感数据的收集和使用，保护用户隐私。

通过以上说明，可以明确校园卡管理系统在交互方面的需求和特点，为系统的设计与实现提供依据。在实际应用中，还需根据具体情况进一步细化和完善交互设计，以满足不同用户的需求和提高用户体验。

4.3系统对象状态演化说明

校园卡管理系统主要对象的状态机图模型说明

 

一、状态机图模型概述

 

状态机图（State Diagram）是UML中的一种图形表示法，用于描述对象的状态转换和行为。在校园卡管理系统中，主要对象的状态转换和行为对于系统的运作至关重要。通过状态机图模型，可以清晰地展示主要对象的状态变化和事件触发条件。

 

二、主要对象与状态

 

用户账户：包括正常状态、挂失状态、冻结状态等。

消费终端：包括开启状态、关闭状态、故障状态等。

门禁设备：包括开启状态、关闭状态、故障状态等。

管理员账户：包括登录状态、注销状态等。

三、状态转换与事件触发

 

用户账户：

正常状态 -> 挂失状态：用户发起挂失请求。

挂失状态 -> 正常状态：用户发起解除挂失请求，且验证通过。

正常状态 -> 冻结状态：系统检测到异常消费行为或管理员手动冻结。

消费终端：

开启状态 -> 关闭状态：终端设备自动关闭或管理员远程关闭。

关闭状态 -> 开启状态：管理员远程开启或用户触摸开启。

门禁设备：

开启状态 -> 关闭状态：门禁设备自动关闭或管理员远程关闭。

关闭状态 -> 开启状态：用户刷卡或管理员远程开启。

管理员账户：

登录状态 -> 注销状态：管理员发起注销请求。

注销状态 -> 登录状态：管理员再次登录。

四、注意事项

 

事件触发条件：确定触发对象状态转换的事件或条件，如用户发起挂失请求、管理员远程关闭终端等。

复合状态：对于某些对象，其状态可能包含多个子状态，需要使用嵌套的状态机图进行描述。

动态交互：考虑不同对象之间的动态交互，如用户账户状态的改变如何影响消费终端的行为。

安全考虑：确保状态机图模型中涉及的安全措施和权限控制符合实际需求，如管理员账户的登录与注销操作需要身份验证。

实际应用调整：根据实际校园卡管理系统的需求和功能，对状态机图模型进行适当调整和完善。。