一种校园卡考勤签到系统设计.doc

一种校园卡考勤签到系统设计 　　[摘要]文章针对大学中使用校园卡进行考勤、签到的需求，描述了一种较为通用的考勤签到系统设计。读卡的硬件采用成熟通用的产品，软件开发利用流行的平台或框架技术。系统整体具有成本低、开发周期短、高可靠性等特点 [关键词]考勤；签到；校园卡；Java；Android；Play framework [DOI]1013939/jcnkizgsc201650224 1项目背景及概述 在大学中，经常出现学生活动签到、早锻炼考勤、上课点名之类的考勤签到应用场景。使用校园卡进行刷卡考勤签到是一种低成本，简单可靠的方法。本文描述的系统，现已应用于南京邮电大学早锻炼考勤，部分活动及课堂的考勤。由于早锻炼考勤与活动签到的业务逻辑有细微不同，总体架构高度一致，本文仅以早锻炼考勤为例进行描述 在针对早锻炼考勤需求的开发过程中，读卡环节需要的硬件为采购获得，手持读卡器软件，后台数据接口，管理端网站，学生查询网站，数据库程序均为自行开发 2背景技术要点 第一，Mifare S50、S70校园卡。Mifare非接触式智能卡作为校园卡，是学校师生在校园生活中不可缺少的一部分。消费和身份的识别等功能均集成在一卡通系统内。通过物理卡号，可以在一卡通系统和学校现有学生数据库中获得学生的基本信息 第二，Play Framework。Play框架是基于Java的Web全线式开发框架。开发效率高，使用灵活，能够满足本系统快速上线的需求 第三，RESTful。使用REST风格的软件架构，帮助数据在不同环节高效流转，系统各个部分低耦合，方便维护和后期升级 第四，Android系统。读卡器手持机为内置Android系统。开发一个Android应用，实现读卡，数据存储、上传和校验的功能。现在内置读卡器的Android手持机在市场上选择很多，广泛应用于物流、仓储等场景，是很成熟的产品 3需求分析 第一，读卡部分。读卡器读取校园卡物理卡号，并发出提示音。读卡器能从NTP同步时间。读卡器在读卡后存储物理卡号、读卡时间信息。刷卡记录在有网络连接时能实时上传。如果离线刷卡，能在获得网络连接后将没有上传的数据传送至服务器 第二，后台服务部分。数据库定期从一卡通数据库和学生数据库获得学生最新的物理卡号和信息。提供数据接口，接收读卡器上传的数据。提供数据接口，接收数据查询请求。业务逻辑提供早锻炼次数统计功能 第三，操作管理部分。用户界面提供?到信息、时间、地点、记录人查询。在有基础数据支持情况下，能精确显示学生学号、姓名、学院等信息，并提供筛选机分类查询服务，查询条件可按学院、专业、班级、时间段。也可根据校园卡号进行单个学生晨练出勤情况查询。每天晨练的出勤人数，出勤率可实时统计，界面上有相应的展现模块。并可提供Excel导出 第四，非功能需求。一是可用性：操作简单，界面简洁；二是安全性：部分学生基础信息和数据涉及防止泄漏和防止篡改；三是可靠性：软件长期在线运行，访问量大，需保证服务不下线，刷卡数据不丢失；四是性能：一般操作响应时间不能大于2s；五是标准化要求：采用UTF8字符集，按照学校信息化标准执行 4设计 41系统框架 读卡器将物理卡号和刷卡时间发送给后台服务。后台服务将刷卡数据进行持久化，同时将刷卡信息中的物理卡号和一卡通数据及学校数据库中的学生信息进行关联。Web服务从后台的功能接口进行各个业务逻辑的调用，包括数据的管理和查询等。同时，Web服务也提供多个入口，给类似于微信、网页、App等多种应用接入。详见下图 结构图 42设计思路 本次开发在实际实施过程中，用户对开发周期提出了高要求。从硬件选型、采购、软件开发到上线的周期在一周左右。所以本系统在实施时，以完成业务逻辑，可靠实现功能为出发点，用户体验和可用性的优化放在后期进行 读卡器是整个系统中关键的一环。读卡器的稳定可靠关系到数据源的准确性和学生刷卡的实际体验。选择成熟的Android手持机是一个比较稳妥的方案，采购选型也较为容易。在实际使用中，不同版本的手持机应用代码兼容性也比较好，升级和更新设备所带来的开发量在可控范围内 数据库方面，应用对数据库类型没有特别要求，但考虑到数据集成的便利性和可靠性，使用和一卡通等系统一致的数据库，可减少对ETL工具的依赖。在本系统中，仅靠少量存储过程即能满足数据同步和匹配的需求 在后台和Web架构的选择上，考虑到开发团队规模和经验，选取Java平台，使用Play framework 是一种比较合理的技术方案。基于以上架构进行敏捷开发，能够符合项目初期的功能需求和可靠性需求 本系统设计方案中其他技术路线，也更多基于已有的项目经验和成熟案例 5实施要点