毕业设计(文)管理系统设计与实现

摘 要：为了解决高校毕业设计（论文）管理系统的功能不足和扩展性低等问题,采用基于角色的访问控制模型实现了资源管理和多角色一次性登录；使用泛化和组合技术,降低了“用户”对象与不同类型“参与者”对象之间的耦合；提供了毕业设计题目在不同专业享及督导员业务的解决方案；系统具有良好的可扩展性,为毕业设计管理系统的开发提供了有益的参考.测试表明,系统界面友好,功能完全满足预期要求,各用户的工作效率均得到了不同程度的提高.

关 键 词：管理信息系统；毕业设计；Ja；角色；访问控制

中图分类号：TP319文献标识码：A文章编号文章编号：1672-7800（2013）012-0106-03

基金项目：山东省高等学校优秀青年教师国内访问学者项目（2011）

作者简介：佀同光（1972-）,男,硕士,山东建筑大学管理工程学院副教授,研究方向为信息分析技术、系统分析与设计.

0引言

毕业设计（论文）（以下简称毕业设计）是高等学校教学综合实践体系的重要环节[1].

近年来一些单位开发了毕业设计管理系统,多数文献中涉及的系统向管理员、教师、学生3种类型的用户提供怎么写作[3-5].王娜等[6]开发的系统设置了学生、教师、设计管理小组和教务管理人员4种用户,解决了学生、导师信息的采集,导师出题、学生选题,有关毕业设计的各种文档的上交与审核,答辩成绩的录入与公布,导师、学生、管理员之间信息的交流等问题.梁金明[7]的设计为学生、指导教师、专业系或教研室主任、教学院长、二级学院教务管理员和教务处教务管理员等6种用户（角色）提供怎么写作,实现了课题申报、论文提交、论文在线评审以及毕业设计资料的归档等功能.

上述系统实现了在线选题、在线指导和部分管理统计等基本功能,但是随着实践教学环节规范化的加强,校企合作的加深和专业融合的深入,企业导师逐渐成为毕业设计指导中的重要补充力量,一些学生还需要跨专业、甚至跨学院接受毕业设计指导；另外,毕业设计系统中一个用户往往会拥有多个角色,用户希望一次登录即获得所有的怎么写作,而不是以每个角色分别登录系统.

这些功能在已有文献中均未体现,本研究试图为上述功能提供一种可行的解决方案,为毕业设计管理系统开发提供有益的参考.

1需求分析

1.1组织机构及用户角色

山东建筑大学是一所教学研究型的地方院校,近年来致力于教学管理规范化建设.该校的毕业设计工作在分管教学校长的统一领导下,由教务处进行宏观管理,各学院通过教研室具体实施.共有指导教师、教研室主任、学生、院级管理员、校级管理员、评阅人、答辩教师、校级督导员、院级督导员等9个不同角色参与毕业设计工作,其中指导教师可以是校外人员,其余角色均为校内人员.

1.2业务流程

实际业务流程中,毕业设计管理活动由几个主要环节构成,活动图如图1所示.

①教师提交题目,学生所在的教研室主任审核；

②合格的题目发放给学生,学生申报题目；

③教师选择学生,必要时教研室主任分配未被选中的学生；

④教师与学生确定指导关系后,开始进行指导活动；

⑤学生提交设计成果后,指导教师填写“指导教师评审表”；

⑥评阅人填写“评阅人评审表”；

⑦院级管理员安排答辩,学生和答辩教师参加答辩；

⑧指导教师“答辩小组意见”和答辩成绩；

⑨教研室主任推荐校级优秀人选；

⑩院级管理员确定校级优秀人选及推荐省级优秀人选；

B11校级管理员确定省级优秀人选.

督导员用户不定期地抽查指导情况,故其活动不在流程中.

1.3主要用户的顶级用例

图2所示的用例描述了指导教师、教研室主任和评阅人的主要功能.指导教师是主要角色,其主要业务是“指导流程管理”,包含“查看往届论文（设计）明细表”、“我申报的题目”、“录取学生”、“维护合作导师”等.教研室主任也有较多的业务,如“审核题目”、“审核论文进度”、“分配未选题学生”、“维护评阅人”、“维护答辩分组”、“推选校优毕业论文（设计）”等.评阅人的业务较少,只有“我评阅的题目”这一功能.3种角色都具有接收和发布通知的业务.

2系统设计

2.1权限相关的设计方案

系统有3类用户：学生、校内员工和校外员工,这些用户需要承担9种角色.学生用户比较单一,仅承担学生角色.一般情况下,一个教师会承担指导教师和评阅人两个角色,而担任教研室主任的教师则会拥有3个角色.如果为每个用户的所有角色都分配一个登录权限,必然会导致同一个用户多次以不同身份登录系统,比较繁琐.

2.1.1基于角色的访问控制模型

基于角色的访问控制（RBAC,role-basedaccesscontrol）的基本思想是“用户—角色—权限”关系角色的定义事先由各级管理员根据企业规程和用户岗位对权限进行注册,并给角色授予权限[8].

如图3所示,用户与角色、角色与资源多对多关系被分解为两对一对多的关系.用户与资源没有直接关联,它的角色决定它的权限,动态指定角色即可实现用户的动态授权.无论用户拥有多少个角色,只需要使用一套用户名和,登录后即可动态访问自己当前所有角色所拥有的资源.

2.1.2用户与具体参与者对象的解耦方案

学生、校内员工和校外员工是完全不同的实体,使用“参与者”类对其进行泛化.“用户”类拥有“用户名”和“”属性,以一对一的方式组合“参与者”类（图3）,耦合度较低.

由于“用户类”是独立的,在实现权限相关操作时,可以不加载其关联对象“参与者”,以获得较高的性能.指导教师可能来自校外单位,故使用“教师”类泛化校内员工和校外员工,在语法上屏蔽了校外指导教师与校内指导教师的差异（见图3、图4）,具有较强的可扩展性.

2.2以毕业设计为核心的实体之间的关联

如图4所示,指导教师直接关联毕业设计,形成“报题”,题目审核后可供学生选报,指导教师录取学生,学生一对一地承担课题.由于毕业设计可能有多个教师指导,教师通过“指导论文”类间接关联毕业设计.基于同样的道理,教师通过“评阅论文”、“答辩组”两个类间接关联毕业设计.

由于毕业论文比毕业设计多了开题报告属性,故前者设计为后者的子类.

2.3跨专业指导的解决方案

一般情况下,教师指导本专业的毕业设计,但随着学科间融合加速,一些教师开始尝试指导其它专业的学生.手工业务中,指导教师如果需要指导其它专业的学生,要向学生专业所在教研室提出申请,该教研室主任将核准后的题目向本专业学生公布,学生选题后形成跨专业的指导关系.从工作流程上看,学生答辩应由指导教师所在的单位安排,但考虑到成绩平衡问题及传统的工作习惯,学生答辩仍然由其所在专业安排.

实体设计中,“限选专业”类与“专业”、“毕业设计”两个类各形成一对多的关联,用属性“审批人”和“审批状态”来支持教研室主任的审批业务实现（见图5）.

指导教师报题时,需要选择“限选专业”（多选）,与之关联的专业所在的教研室主任对其“审批状态”进行设置,通过审批的毕业设计可以被该专业学生选报.

该设计方案支持指导教师向校内任意专业的学生提供指导（管理员可以根据需要限制专业范围）,还能够支持“学生答辩由指导教师所在单位安排”这一功能的实现,扩展性较强.

2.4督导员业务的设计方案

督导员对毕业设计的各种资料具有完全的阅读权限.院级管理员创建“用户-角色”类的一个对象,即可指定一个院级督导员,默认地对所在学院所有学生承担的毕业设计进行检查,故无须为其设计新的实体类.

校级督导员由校级管理员指定,负责对某些学院的毕业设计资料进行检查.所以,除了为相关用户添加“校级督导员”角色外,还需要一个“校级督导”类描述督导员和被督导学院的关系.该类有两个关联属性,其中supervisor表示督导者,schoolToSupervise表示哪些学院的毕业设计可以被其检查（图6）.

2.5结构化与非结构化表示

系统尽可能地对各种信息进行结构化表示,以下3个类是例外情况,以文档形式进行管理（见图4）.

外文文献和开题报告：形式统一,但字节数较大且可能配图,故设计为附件形式,同时记录题目和文件名,开题报告还需要记录审批属性.

任务书：字节数较少,但各专业均可以自行制订任务格式,动态结构化成本较高,故设计为附件形式,记录文件名和审批属性.

3系统实现

系统采用B/S三层结构设计,最大限度地保证数据的唯一性和安全性[9].Spring是分层的JaSE/EE应用一站式的轻量级开源框架,以IoC（InverseofControl,反转控制）和AOP（AspectOrientedProgramming,面向切面的编程）为内核,提供了展示层SpringMVC和持久层SpringJDBC以及业务层事务管理等众多的企业级应用技术[10-11].

表现层采用SpringMVC框架和jQuery来保证简洁的分发控制和友好的用户界面,数据访问层采用Hibernate进行“对象-关系”映射,数据库管理系统采用MySQL5.5.采用Unitils构建单元测试、使用ApacheJMeter用来完成系统功能和性能测试任务.

4结语

系统采用RBAC模型实现资源管理,避免了同一用户为切换角色多次登录系统,提高了系统的灵活性和用户体验.系统中适当使用了泛化和组合,提高了系统组件的通用性及系统的可扩展性.跨专业指导和督导员功能满足了用户单位的实际需要.试点反馈表明：毕业设计各参与者的工作效率均得到了不同程度的提高,具有广泛的经济和社会意义.本系统暂时还没有提供答辩分组智能编排的功能,有待于以后解决.