【毕业学位论文】（Word原稿）高校后勤管理系统的设计与实现-软件工程

中图分类号： 学校代码： 10055 密级： 硕 士 专 业 学 位 论 文 高校后勤管理系统的设计与实现 要 I 摘 要 本文以天津市高校的显示应用需求为背景，充分运用软件工程领域的方法和技术，针对后勤管理这一教育信息化难题进行系统性的研究和实践，以期有效补充现有数字化校园软件系统的功能，同时有利于提升高校后勤管理信息化的水平，进而服务于高校现 代化发展。 本文运用软件工程领域的方法和技术，针对高校后勤管理系统中的业务建模和数据建模问题进行研究，遵循 念，基于模式系统的思想对高校后勤管理系统进行系统架构设计，并针对若干性能优化问题进行研究。本文主要完成以下工作： 1. 使用 求分析模型和 范， 使用 型设计工具， 对高校后勤管理中的核心业务进行数据建模和业务建模 。 2. 遵循 统架构方法并使用 统架构模式 ，并运用层次化模式、类工厂模式、观察者模式、代理者模式等多种系统架构模式，针对高校后勤管理系统进行体系架构设计，实 现具有高扩展性和易修改性的通用化高校后勤管理系统的架构设计。 3. 遵循软件测试的基本方法和流程 ， 使用 能测试工具和陷管理工具， 对本文所实现的高校后勤管理系统进行完整的功能和性能测试 ， 并进行高质量的 理，同时 制定并实施合理的系统部署服务规范 。 本文工作成果已在天津市三所高校内进行有效实施 ，在真实应用环境下进行了实用性和稳定性的验证，本文工作成果可作为高校数字化校园建设中的有益补充，同时为其他管理领域的信息化建设提供参考。 关键词 ： 教育信息化 需求建模 软件系统架构 设计 后勤管理 I 容与中文摘要 相对应 。 2 磅，行距 20 磅，段前段后 0 磅 录 录 第一章 内容要求 (引言或绪论 ) . 1 第 二 章 格式要求 . 6 第一节 中文封面 . 6 第二节 学位论文版权使用授权书 . 错误 !未定义书签。 第三节 学位论文原创性声明 . 错误 !未定义书签。 第四节 中文摘要 . 错误 !未定义书签。 第五节 . 错误 !未定义书签。 第六节 目录 . 错误 !未定义书签。 第七节 符号说明 . 错误 !未定义书签。 第八节 正文 . 错误 !未定义书签。 第九节 参考文献 . 错误 !未定义书签。 第十节 致谢 . 错误 !未定义书签。 第十一节 附录 . 错误 !未定义书签。 第十二节 个人简历 在学期间发表的学术论文与研究成果 错误 !未定义书签。 第三章 书写要求 . 31 第一节 文字、标点符号和数字 . 31 第二节 密级 . 39 第三节 层次标题 . 错误 !未定义书签。 第四节 篇眉和页码 . 错误 !未定义书签。 第五节 有关图、表、表达式 . 错误 !未定义书签。 图 . 错误 !未定义书签。 . 错误 !未定义书签。 达式 . 错误 !未定义书签。 第六节 参考文献 . 错误 !未定义书签。 第七节 量和单位 . 错误 !未定义书签。 第四章 排版及印刷要求 . 40 第一节 纸张要求及页面设置 . 40 第二节 中文封面（已经定型，只须填入相关内容） . 40 第三节 书脊 . 40 第四节 中、英文摘要 . 40 目 录 五节 目录 . 错误 !未定义书签。 第六节 正文 . 错误 !未定义书签。 第七节 其它 . 错误 !未定义书签。 第八节 印刷及装订要求 . 错误 !未定义书签。 第五章 总结与展望 . 41 第一节 主要工作 . 41 第二节 展望 . 41 参考文献 . 42 致谢 . 43 个人简历 在学期间发表的学术论文与研究成果 . 44 第 一 章 绪论 1 第一章 绪论 随着 高等院校 管理规模的扩展，管理方式和管理效率的矛盾日渐突出。在后勤管理方面，手工管理方式和文档 系统管理方式在管理质量和管理效率上，从根本上不能适应大规模的管理要求。而随着 信息技术 的发展与进步， 数字化的管理方式 ，不管在管理效率还是在管理质量上都显示出了可靠性和优越性。更为重要的是，对高校后勤管理工作进行信息化建设，以专用的信息管理系统支撑复杂的后勤管理业务，在 人力、物力 、资金等 资源 消耗 方面都比以前的管理模式有 很大 的节省 ，同时通过对业务数据的实时记录和历史统计分析，可以有效提升后勤管理决策的质量。 本文以天津市高等院校的后勤管理工作 为背景，在认真调研和分析了学校后勤管理现状之后，根据教师及后勤工作人员的 需求和各个功能的关系， 进行了完整的需求建模、系统架构设计、详细设计和技术实施工作。为完善高等院校的数字化校园建设，提升高等院校的现代化管理水平，提供了重要的工具。 第一节 本文工作背景 内教育信息化发展现状 图要精选，要具有自明性，切忌与表及文字表述重复。 勤管理信息化的发展现状 图要精选，要具有自明性，切忌与表及文字表述重复。 第 一 章 绪论 2 第二节 本文主要工作内容 求建模与业务建模 行业信息化面临着诸多挑战，从软件工程的角度来看，其最大的挑战在于如何有效的管理和控制需求 并开展深入的业务建模工作。这方面的工作不仅需要软件工程领域或 面的知识和能力，更需要项目管理乃至行业业务管理的深厚背景。 高校后勤管理是一项业务内容繁杂 、 管理分支多样的复杂管理工作 ，其复杂性体现于每一项管理业务与其他管理业务在数据模型、 管理过程和用户角色设计方面都有着非常明显的差别，将十余项相互独立的管理业务功能整合在一个软件系统中，为同一个管理员用户提供不同业务功能的权限和角色，这是实现后勤管理信息化目标的最大挑战，一不小心就会陷入到业务细节的泥潭中，因此，必须遵循软件工程的理念和方法，首先对高校后勤 管理信息化进行完整的需求建模和业务建模。 本文选择使用 求建模过程作为高校后勤管理信息化的需求建模参考 ， 将需求建模与后续的系统分析 （ 概要设计 、 详细设计 ） 进行了有效的区分 ，同时借助高保真原型方法对需求内容进行详细完整的描述，为后续的技术实现提供准确稳定的参考。 业务建模是需求建模过程的核心内容，需要特别注意的是，业务建模不等于单纯的工作流建模，工作流建模主要从软件技术的角度对业务过程进行描述，而业务建模则涵盖了管理和 个方面，特别倾向于以业务过程为导向，进行流程建模（描述业务运行的动态特征）和 业务组织建模（业务目标、业务组织结构、业务角色、业务工件等静态特征） 。 本文遵循 范对高校后勤管理系统中的不同业务功能进行了完整的业务建模，使用用例图描述应用场景，使用数据流图描述不同业务 子系统 中的关键业务数据流转情况，使用高保真原型对关键业务功能进行完整的描述。 统架构设计与技术实现 高校后勤管理系统是一个非常复杂的软件系统 ， 需要较为庞大的软件团队第 一 章 绪论 3 和多种角色的工作人员相互协同才能有效实现系统建设的目标 ， 在进行系统架构设计时 ， 本文从以下三个角度开展系统架构的设计工作 ： 1. 业务系统架构设计 高校后勤管理的业务复杂性使得软件工程的配置管理工作非常复杂 ， 为保证系统实施的进度和质量 ， 需要在逻辑上对不同的业务功能 子系统 进行有效的分离 ， 以松散耦合的架构开展系统实施工作 。 这样做的好处在于能够使得多个不同的技术小组同时开展独立的业务系统建设 ，并在“需求分析人员、系统设计人员、技术实施人员、评测人员和技术支持人员”等不同的技术角色之间实现有效的工程流水线，从而保证系统建设的效率和质量。 2. 技术系统架构设计 遵循 式的 统框架是行业信息化的主流技术设计方法 ， 本文同样使用这样的系统架构思路开展技术设计工 作 ， 特别注重在以下几个方面保证技术系统架构设计的高质量 ： 层次化系统架构的贯彻：许多技术团队在进行软件工程实践的过程中，名义上遵循着 式，但是在具体实现过程中，由于编码不规范或技术人员的懒惰，经常出现违背层次化系统架构模型的工作习惯，例如在 面中直接编写调用底层数据库的代码，例如将业务逻辑代码与数据库读写代码直接封装成某个特定的数据库接口等。这些习惯虽然在一定程度上提高了工作进度，但是对软件系统的演进极为不利。本文在过程中过程中严格遵守层次化系统架构模型，对三层 B/S 架构中相邻层次之间接口均进行 了封装 ， 确保对 统框架规范的遵守 ， 并保证了 式的实现质量 。 类工厂模式的应用 ：高校后勤管理系统虽然有不同类型的业务，但是许多业务只有逻辑形式的差别，在技术实现的模式上却有相似之处，因此本文在进行技术设计的过程中，遵循类工厂模式进行了完整的类图定义，通过对所有业务功能的类图设计进行汇总抽象，实现了稳定通用的底层技术实施架构。 针对出错 、 异常等状态的控制 ： 软件系统在运行过程中 ， 由于数据错误 、用户误操作 、 系统环境故障等原因会发生各种类型的出错和异常情况 ，对此应有明确的定义和控制机制 。 本文在设计阶段即限 定了各类错误的处理方法 ， 保证了 系统运行的稳定 ， 为系统部署后的技术支持工作提供第 一 章 绪论 4 了有效支撑 。 3. 数据库系统架构的设计 无论是业务系统架构设计 ， 还是技术系统架构设计 ， 最终都需要依赖数据库的良好设计 ， 因此在系统架构设计的过程中 ， 必须特别注重数据库系统架构的设计和实施工作 。 本文遵循松散耦合的观点 ， 在数据库设计方面遵循业务逻辑分离的原则 ，进行了数据库垂直分区设计 ， 不同业务功能将使用相互独立的数据表集合 ， 对于用户权限 、 组织机构等公共数据表进行了统一设计 。 这样做的好处有两点 ，首先在系统实施过程中 ， 垂直分区的设计理念有利于同 时实现多个相互独立的业务功能 ， 提升系统实施的工作效率 ；其次在系统的技术维护及演进过程中，有利于迅速的针对特定功能进行底层数据库的优化或改进，实现对新需求的快速响应。 能性能评测与系统部署实施 软件评测是保证软件系统功能正常和性能稳定的关键工作，也是许多小型软件团队缺失的 工作环节。高校后勤管理系统需要对高校内大量的 固定资产进行管理，需要对资源调配、使用情况、维修保养等需要消耗人力和资金的工作过程进行管理，因此系统的稳定性直接影响到后勤管理工作的开展，甚至直接影响到高校教学科研工作的稳定，因此，必 须以较高的技术标准实现对高校后勤管理系统的评测。 在本文工作中 ， 重点从以下几个方面开展与评测有关的工作 ： 1. 义与跟踪管理。高校后勤管理系统的业务复杂性和技术复杂性使得实施过程中必然存在各种原因造成的 保证系统实施的质量，需要首先定义 类型和级别，并执行有效的 踪管理。 2. 功能评测计划与测试案例设计。本文针对高校后勤管理系统的 所有功能，进行了完整的功能评测计划设计，并编制了数千个针对性的功能测试案例，特别重要的是，由于在需求建模阶段使用了高保真原型方法，因此在技术实现之前，就启动了功能 评测计划编制与测试案例设计工作，通过并行工作的方式大大提升了软件测试工作的效率。 3. 性能评测计划 。本文针对高校后勤管理系统在实际运行过程中面临的访第 一 章 绪论 5 问压力和系统兼容性问题，编写了完整的性能评测计划并进行了有效的实施。 第三节 本文使用的主要方法和技术 求建模方法与 范 图要精选，要具有自明性，切忌与表及文字表述重复。 架与 统架构设计方法 图要精选，要具有自明性，切忌与表及文字表述重复。 分类号：暂空 第四节 本文内容组织 本文第一章简要介绍了论文工 作背景 和主要工作内容，并对本文所使用的技术方法与规范进行了简要介绍。 本文第二章阐述了高校后勤管理系统的需求分析与系统架构设计工作 ， 重点针对需求建模过程 、 业务系统架构设计 、 技术系统架构设计和数据库系统架构设计进行了阐述 。 本文第三章阐述了高校后勤管理系统的技术实现过程 ， 对核心业务功能的详细技术设计进行了阐述 ， 对若干关键技术问题进行了分析 。 本文第四章阐述了高校后勤管理系统的评测过程和系统部署实施过程 ， 对功能和性能评测 、 理 、 系统部署实施的过程进行了描述 。 本文第五章对全文工作进行了总结和展望 。 第 二 章 需求分析与系统架构设计 6 第 二 章 需求分析与系统架构设计 本章重点介绍 高校后勤管理系统的需求分析工作与系统架构设计工作，这是开展技术实施的前提基础，如果没有良好完备的需求分析，就无法为后续的系统设计和技术实现提供稳定明确的参照。 第一节 后勤管理信息化的需求建模 求建模的过程控制 本文 中简要描述了 求过程及控制方法，在本章中将详细说明如何 遵循 求模型开展需求分析工作。 图 述了完整的 求过程。 图 整需求过程 第 二 章 需求分析与系统架构设计 7 在进行 需求建模的过程中，必须注重以下几个关键点的控制，这是确保需求分析过程能够获得良好效果，并且为后续的系统分析、技术设计和实施工作提供有效参考的关键所在。 1. 控制需求范围：在图 ，“网罗需求”这一环节的主要目标是经过详实的需求调研（通过客户交流实现）和应用环境的上下文分析，确认项目的基本功能范围，并通过完整的客户方组织结构分析与业务背景分析，确认项目的核心业务过程，最终以用例图的形式形成对项目工作范围的确定。 2. 需求模板控制 ： 在完成了基础需求内容的调研搜集和总结分析之后 ， 开展正式的需求规格描述工作 ， 这方面需要 有效结合高保真原型设计方法 、 人机交互方法以及 范 ， 对每一项功能需求进行完整的描述 ，本文使用了 “ 用例图 +高保真原型 面集合 （ 静态原型 ） +业务操作过程描述 ” 的方法 ， 实现对功能需求的详细描述 。 3. 需求审查与变更控制 ： 复杂软件系统在实施过程中面临的最大困难就是需求变更 ， 造成需求变更的原因有很多 ， 但最为主要的原因是软件团队完成的需求规格说明书并未经过客户方严格的审查 ， 由此导致在技术实施过程中 ， 客户方发现软件团队的需求描述规格不够严谨清晰 ， 因此提出大量的细化修改意见 ， 这样导致的需求变更要比增补新需求造成的需求 变更多的多 。 因此在执行需求建模的过程中 ， 必须严格控制需求审查工作 ， 经过客户方严格明确的审查之后 ， 需求规格会更加准确和稳定 ，后续的需求变更概率也会降低 。 保真 原型设计方法的应用 在开展需求建模的工作中，需要使用原型方法描述预期实现的软件系统的界面效果和操作过程， 以直观的方式帮助客户确认由技术团队规划的功能需求，高保真原型的设计可以采用较为复杂的技术工具进行 面静态原型开发的方法，也可以采用专用的高保真原型设计工具（本文使用 型设计工具）实现快速度原型开发。 为什么需要使用高保真原 型呢 ？ 因为在许多管理信息系统中 ， 客户方的需求都是模糊的 ， 单纯用文字 、 业务流程图等形式虽然能够把握客户需求的主干 ，第 二 章 需求分析与系统架构设计 8 但是对用户交互体验 、 数据呈现样式以及 面跳转流程等问题缺乏深入地阐述 ， 而这些问题恰恰是影响软件开发进度和质量的关键因素 。 本文作者专门进行了这方面的对比试验 ， 试验过程如下 ： 无高保真原型技术实施 ： 作者在完成对客户需求的调研总结后 ， 以文字的形式描述了客户对某个业务功能的需求 ， 并描述了客户期望的 端页面的样式 和操作过程。以此为参考，技术团队进行工作量 10 人天的技术实施工作，并将结果交付客户 确认。客户对 面的样式、操作模式、页面流转过程提出了大量的需求细化和变更，由此涉及到美工人员、 端开发人员、后台业务开发人员的多次返工，最终该功能在消耗了 40 人天工作量之后达到客户期望。 有高保真原型技术实施 ： 作者选择另外一个具有同样业务复杂度的功能 ， 对其进行需求调研和文字总结后 。 通过 5 人天工作量完成了高保真原型的开发和客户确认，在此基础上，技术团队进行了工作量 7 人天的技术实施工作，并将结果交付客户确认，直接获得客户通过，工作总量为 12 人天。 两相对比 ， 有高保真原型的需求建模在项目总体实施上能够 大幅提升项目工作的进度和客户满意度 。高保真原型不但能够帮助需求分析人员更为深入准确的把握客户需求，同时也能帮助美工设计人员直接确定 面样式和美工风格，帮助系统设计人员快速确定业务过程和底层数据库接口，进而有效提升技术设计与实现的工作效率。 基于此，本文 遵循 求模型，使用 型工具，对高校后勤管理系统进行了完整的需求建模，下文将重点描述高校后勤管理系统的需求规格。 心业务功能的需求规格说明 一、 主要功能概述 高校后勤管理系统是 独立软件系统，在 高校内部专用的 境中运行，遵循 B/S 系统模式 ， 供后勤管理部门的全体教师和领导使用 ， 同时为其他相关部门和全校师生提供必要的信息查询 、 服务申请与在线交流功能 。 第 二 章 需求分析与系统架构设计 9 高校后勤管理系统主要包括十个功能子系统 ： 能耗管理、基建维修管理、招标采购管理、物业管理、餐饮管理、入住企业管理、宿舍管理、安全管理、其他管理及系统管理。各个子系统的简要功能描述如下： 1. 能耗管理：记录每月全院全区域各电表、水表、供冷（供热）数据，能够对数据进行汇总统计分析，并以柱状图、曲线图等图表形式显示出统计结果。 2. 基建维修管理：记录每天维修的基本情况，包括维修的原因，维修时间、状态、费用、结果等基本信息，并提供查询统计分析功能。 3. 招标采购管理：跟踪记录每次采购的基本信息及进展情况，包括：采购计划、采购预算、采购清单、实际成交金额等信息，并提供查询统计分析功能，并以柱状图、曲线图等图表形式显示出统计结果。 4. 物业管理：主要用于对两区物业工作的跟踪和统计汇总工作，功能包括：检查计划安排，检查结果记录汇总统计，物业各类基础数据及工作情况上报，图形显示统计结果。 5. 餐饮管理：主要用于对两区餐厅餐饮工作的跟踪和统计汇总工作，功能包括：检查计划安排，检查结果记录汇总统计，餐厅各类营业数据及工作情 况上报，图形显示统计结果。 6. 入住企业管理：主要用于对入驻企业和各类费用情况的管理，功能包括：企业收费情况管理、企业安全情况管理、相关工作安排及提示。 7. 宿舍管理：主要对学校公寓的住宿、退宿、调宿等情况的记录管理，并以图形显示统计结果。 8. 安全管理：安全检查情况记录、安全宣传情况记录、突发情况及应急处理措施记录。 9. 其他管理：临时场地审批管理、底商审批及营业情况管理、学术交流中心营业情况管理。 10. 系统管理 ： 针对本系统所需要的人员角色权限 、 组织结构 、 通用性业务规则等进行管理的专用技术模块 。 系统的总体用例图如图 示。 通过用例图可以看出，高校后勤管理系统中对应着不同的业务管理功能，后勤管理工作人员在不同的业务管理子系统中有不同的角色和权限，需要进行高质量的用户访问权限控制。 第 二 章 需求分析与系统架构设计 10 图 校后勤管理系统用例图 二、 系统 业务流程图描述 在不同的后勤业务管理流程中 ， 大量的后勤管理业务被抽象为直观的数据采集录入和报表分析流程 ， 也有一些极为复杂的后勤管理业务需要完整的管理业务流程支持 ， 因此在进行有效的高保真原型设计之前 ， 需要对高校后勤管理系统中各项核心功能进行业务流程描述 ， 便于实现管理业务的逻 辑分离 ， 对组织后续的实施工作提供参考 。 图 述了本文所设计的高校后勤管理系统的基本业务流程 （ 按功能子系统进行逻辑分离 ）。 由于 篇幅有限，本节只列出了较为复杂的 业务 流程描述， 其中招标 采购管理 是 流程最为复杂的子系统，宿舍管理需要较为复杂的数据报表统计功能，其他管理模块 相对 简单，因此下文中重点对较为复杂的功能子系统的需求设计进行阐述。 第 二 章 需求分析与系统架构设计 11 第 二 章 需求分析与系统架构设计 12 图 校 后勤管理系统核心业务 流程 描述 第 二 章 需求分析与系统架构设计 13 三、 关键 业务子系统 高保真 原型设计描述 在 本文 中，针对使用高保真原型的设计方法进行了阐述， 基于 本方法 ， 可对高校后勤管理系统中的所有功能子系统进行完整 详细 的需求规格说明，由于篇幅有限， 本节只 选择 “ 招标采购管理 ” 作为示例 ， 阐述如何使用高保真原型进行深入完整的需求分析 。本文所设计的高校后勤管理系统，共完成高保真 面原型 315 个，最终完成版的需求规格书的篇幅达 140 页，为节省论文篇幅，以下只节选“招标采购管理”子系统中“采购计划管理”子模块进行高保真原型描述。 （一）“招标采购管理”子系统的功能模块 划分 招标采购管理 子系统共 包括六个子模块： 采购计划子模块：部门采购计划、采购预算科目、校月采购计划； 采购申请子模块：部门采购申请、校级采购申请； 采购安排子模块：上报计划； 合同执行子模块：合同执行情况记录表、付款情况记录表、采购列表； 基本维护子模块：采购方式维护、采购分类维护、二级分类维护； 统计报表子模块：采购分类比例报表、二级分类采购比例报表、合同付款情况报表、预算完成情况报表。 经需求调研与高保真原型设计 ，“ 招标采购管理 ” 子系统共包含 51 个 中“采购计划子模块”包括 9 个 面，以下简要说明其高保真原型设计。 （二）采购计划管理子模块的高保真原型设计 在进行需求调研的基础上 ， 本文针对采购计划管理进行了完整的高保真原型设计 ， 对其中的用户操作 、 数据输入输出等均进行了完整的描述 ， 经客户确认后 ， 形成最终版本的需求规格说明 。 在采购计划管理子模块中 ， 又进一步细分为 “ 部门采购计划首页 ”、“ 新增部门采购月计划 ”、“修改部门采购月计划、查看部门采购月计划”、“上传签批凭证”、“采购预算科目”、“新增采购预算科目、修改采购预算科目”、“校月采计划”等 9 个独立的原型界面。为节省篇幅，图 述了采购计划管理子模块中两个关键原型界面的需求规格。 第 二 章 需求分析与系统架构设计 14 （ 1） 部门采购计划 （ 2）新增部门采购月计划 图 保真原型示例 第 二 章 需求分析与系统架构设计 15 仅仅提供高保真原型页面还不能完整描述需求规格 ， 针对页面中的数据格式 、 数据来源以及页面交互操作进行完整的描述 ， 表 图 两个高保真原型界面中的数据输入输出进行了详细描述。 表 保真原型对应的数据输入输出描述示例 （ 1）部门采购计划 新增 （修改同新增，申请计划编号不变化， *为必填） 序号 输入 数据 名称 数据项说明 及特殊约束 来源说明 1 申请计划编号 20 字符以内， 系统自动生成 录入 2 *是否属于集采目录 标志位 录入 3 *采购项目名称 60 字符以内， 必填 录入 4 *计量单位 10 字符以内 录入 5 *采购数量 整数 点选 6 *采购项目详细参数 附件上传 文件 7 *采购预算科目 下拉选择 点选 8 *采购预算金额 8 位数字，保留两位小数 录入 9 预算价格依据 500 字符以内 录入 10 *采购方式 下拉选择 点选 11 *填报人 人员树选择 点选 12 *联系电 话 30 字符以内 录入 （ 2）部门采购计划 查询 输出类型 输出信息 正常输出 输入申请计划编号、采购项目名称， 下拉选择 采购预算科目后 进行精确查询 ，列表显示查询信息（ 申请计划编号、采购项目名称、计量单位、采购数量、采购预算科目、采购预算金额、上传签批凭证 ） ，每页显示 10 条数据。 异常输出 查询无结果或结果错误 （ 3）部门采购计划 查看 输出类型 输出信息 正常输出 显示查看信息（ 填 报部门 、 填报日期 、 金额单位：万元 、 申请计划编号、是否属于集采目录、采购项目名称、计量单位、采购数量、采购项目详细参 数、采购预算科目、采购预算金额、预算价格依据、采购方式、填报人、联系电话 ） 异常输出 无法查看或查看显示数据错误 （ 4）部门采购计划 导出 输出类型 输出信息 正常输出 将查询结果列表导出为 式； 异常输出 无法导出，或导出结果错误 第 二 章 需求分析与系统架构设计 16 基于 端页面原型，完成了详细的数据输入输出的格式规范之后，可进一步描述页面中各个按钮或元素的人机交互操作过程，针对图 描述的页面原型，在需求规格中设定的操作流程如下： 点击“ ”按钮，进入新增页面。点击“保存”，将新增或修改的记录保存。 点击“ ”按钮，根据查询条件进行查询。点击“ ”，进入导出界面。 点击“ ”，进入修改页面，点击“ ”，删除此记录，点击“ ”，进入查看页面。点击“ ”按钮，上传签批凭证 基于本节描述的需求规格工作流程 ， 可对高校后勤管理系统中的所有功能进行详细完整的需求规格描述 ， 一方面为后续的系统架构设计提供指导 ， 另一方面 ， 以此为参照 ， 可直接开展测试计划的编写和测试案例准备工作 ， 在总体上提升软件系统的实施工作效率 。 统的静态 /动态 数据需求 在需求规格说明中，系统的静态数据需求和动态数据需求也是很重要的内容，其 中静态数据作为 预先设定好的参数，直接为各类应用操作过程提供数据内容，动态数据则要求系统必须提供完备的后台数据字典控制，便于管理人员可以随时调整基础业务数据，支撑整个系统的正常运行。 （一） 高校后勤管理系统中的静态数据 支持并发连接的访问终端个数： 100；支持的同时操作的用户数 :30； 用于各类 静态下拉列表 中的静态数据： 状态 /维修状态：完成、未完成； 项目状态 ：活跃、冻结、取消； 整改状态：无需整改、整改已完成、整改未完成； 星级评估：一星、二星、三星、四星、五星； 分数： （意为：未检查）、 1、 2、 3、 4、 5、 6、 7、 8、 9、 10； 房间：二人间、四人间； 第 二 章 需求分析与系统架构设计 17 （二） 高校后勤管理系统中的动态数据 能耗管理：电表测量 区域维护、地点维护；水表测量 区域维护、地点维护；供冷 (热 )测量 区域维护 、 楼名维护 、 测试点维护 。 基建维修管理：基建维修 维修项目管理；区域维护。 招标采购管理：采购计划 采购预算科目维护；基本维护。 物业管理：基本维护 餐饮管理：统一采购 物品名称维护 ；商铺记录 楼层维护 、位置维护、 状态维护 ；菜品比较 菜品名称维护 ；餐厅管理 处罚原因维护 、 处罚类型维护 。 入住企业收费管理： 星级评估维护 。 其他管理：商铺管理 商铺检查项维护 ；学术交流中心 学术交流中心检查项维护 。 第二节 后勤管理信息化的系统架构设计 体 业务框架设计 根据 高校后勤管理系统的 需求 规格描述 ，依据 高校后勤管理部门的不同职能 将系统分为八个业务模块。除此之外，系统还应包含组织结构人员管理和账户权限管理两个基础服务模块。经过需求分析得出结论，八个业务模块之间彼此互不关联，但都需要同人员组织结构关联以及被权限模块管理和限制。系统业务总体设计如 图 示 ， 系统分为十个模块，其中业务模块之间不存在任何依赖，只和组织机构进行 关联，体现为使用组织机构中的部门和人员信息。用户和权限管理与组织机构关联，体现为直接使用组织机构中的人员信息。 第 二 章 需求分析与系统架构设计 18 图 统业务架构设计 体技术框架设计 系统采用 B/S 架构设计。本应 用主要面向后勤管理部门工作人员使用，且在 校园 内部局域网中运行，有并发量小、网络传输速度快等特征，因此系统将采用中低端的开源路线，传统的“视图 业务 数据处理”三层架构实现。系统的整体技术架构如图 示： 第 二 章 需求分析与系统架构设计 19 图 校后勤管理系统技术架构图 1. 视图层 视图层主要体现为 源，用作和用户交互内容的展现。视图层具体结构如 图 示 ： 图 图层架构设计 第 二 章 需求分析与系统架构设计 20 如图 示，系统中的 包含 达式等 的基本元素。除此之外， 面可能会引用四种元素如下： 1） 端脚本以 基础，包含如下四类内容 控件：页面用到的日历控件等。 方法：页面的公共方法和个性方法，包含封装在公共方法文件中的通用脚本和每个页面中编写的个性脚本。 样式处理：可能会使用到的第三方样式框架提供的对样式的控制脚本。 报表组件：第三方提供的系统中所有图形报表 2） 面中使用的各类图片静态资源。 3） 合 系规范的标签技术，通常体现 为 C 标库。 4） 己编写或第三方提供的 式表。 2. 控制层 控制层主要体现为 相关的配置项，负责完成数据格式转换、数据双向封装和传递、业务调用和视图层资源调用。控制层的结构如图 示 。 图 制层架构设计 控制层基于 现，使用 配置文件完成数据的封装和传递。 第 二 章 需求分析与系统架构设计 21 控制层中通过调用业务层的 成业务操作，业务数据的封装、报表数据的封装也在控制层中进行。 1） 业务数据封装 创建消息 及如有必要，定义并将返回的数据转换为 2） 报表数据封装 将各类数据封装成报表需要的格式。 3） 业务层 过全局容器获取业务层 成方法调用。 4） 于 现的 架以及框架中各类 配置文件。 3. 业务逻 辑层 业务逻辑层主要体现为 相关配置项，负责完成接收前端的数据并处理每个功能的业务逻辑。系统中的业务逻辑层结构如图 示 。 图 务逻辑层 架构设计 业务逻辑层本身包含文件处理 和调用数据层 功能。同时，事务控制在业务层，通过 声明式事务管理实现。 1） 文件处理 完成对上传文件的路径创建保存； 完成对下载文件的查找和读取； 2） 数据层 过全局容器获取数据访问层 成方法调用。 3） 二 章 需求分析与系统架构设计 22 基于 现的事务管理和注入、注册接口。 4. 数据访问层 数据访问层主要体现为 相关配置项，负责整个项目对数据库的各类操作。数据访问层结构如图 示 。 图 据访问层 架构设计 数据访问层包含如下内容： 1） 基础访问工具包 提供 到数据库会话的基础功能包。 2） 于 现的 类映射的配置、解析以及相关的 合。 本节对高校后勤管理系统的技 术框架进行了概要设计描述 ， 依次设计为参考 ， 在后续的详细设计过程中 ， 可更为精细的设计各个功能子系统的类图与接口 ， 为高质量的技术实现提供保证 。 用业务处理规则设计 在高校后勤管理系统的技术实现过程中，经常需要在业务逻辑中实现数据的新增和删除操作， 由于技术实现工作由多人并行完成，因此在代码实现的风格上会有不可控制的差别，为保证系统代码的规范性，同时有利于未来系统的技术维护和演进发展，需要定义通用业务处理规则。 第 二 章 需求分析与系统架构设计 23 本文针对高校后勤管理系统中最常见的数据增删处理 ， 定义了三条通用的处理规则 ， 所有功能子系统在 技术实施的过程中 ， 均需要遵守这三条最基本的业务处理规则 。 1. 新增业务数据通用规则 高校后勤管理系统中有大量的数据录入界面 ， 用户在录入数据时 ， 系统需要对数据的合法性进行检查 ，需要将数据保存到数据库中，同时需要向用户反馈数据保存的结果，以确定数据被真正更新到底层业务数据库中，为此，针对所有 端页面中的数据录入项，均遵循如图 示的新增数据处理流程。 图 增数据处理流程 2. 物理删除数据通用规则 物理删除是指在数据库中使用 句删除记录。除记录本身以外，可能作为关联关系中的一端出现 ，为保证实体关系的稳定和正确，在业务流程中执行物理删除数据操作时，必须同时对与其相关的实体关系进行维护，表 体关系的影响。 表 理删除数据时实体关系的维护规则 场景 记录 本身 对端 备注 在一对多关系中充当一的一端 物理删除 解除关系 在一对多关系中充当多的一端 物理删除 无操作 在多对多的关系中充当多的一端 物理删除 无操作 需要物理删除关系端 第 二 章 需求分析与系统架构设计 24 3. 逻辑删除数据通用规则 逻辑删除是为满足用户对于删除的需求，兼顾数据完整性，通过设置逻辑删除标志位的方法删除数据。被逻辑删除的数据对用户来说视为永久删除，不提供相应的用户 行恢复。 除被逻辑删除的数据作为维度的历史信息查询，页面将不会出现被逻辑删除的信息。 第三节 后勤管理信息系统的数据库设计 数据库设计是高校后 勤管理系统的关键设计工作 ， 本文开展工作过程中 ，遵循了层次化渐进设计的思路 ， 立足于各个功能子系统的逻辑分离设计，对单一功能子系统进行了独立的实体关系分析，在此基础上对各个功能子系统的数据库表单进行了分区设计，并依托于用户权限表和系统公共基础数据字典实现不同功能子系统之间的数据关联。 一功能模块的实体关系分析 本文遵循 范描述每一个功能 子系统 内部的实体关系，对各个功能 子系统 的实体关系分析总结如下。 1. 权限管理子系统 权限采用基于“用户 角色 资源（菜单）”为模型进行设计与开发。规定角色具有 的权限以及使用户持有角色完成对用户具体权限的定义。账户可持有多个角色，同一角色可持有多个菜单，实体关系如图 示。 图 限管理子系统 实体关系 第 二 章 需求分析与系统架构设计 25 2. 组织结构管理子系统 组织结构管理 子系 统 为后勤部门中的各个子部门及部门下人员提供管理，人员要有所属职位和归属的部门，部门下可以包含多个人员的管理 ，实体关系如图 示。 图 织结构管理 实体关系 3. 招标采购管理子系统 该子系统管 理了从计划开始一直到合同履行完毕各个环节的数据状态，按照一定流程依次维护，实体关系如图 示。 图 标采购管理实体关系 4. 入住企业管理子系统 包含入驻企业、宿舍管理和投诉管理三个部分，实 体关系如图 示。 图 驻企业 管理 实体关系 第 二 章 需求分析与系统架构设计 26 5. 基建维修管理子系统 该 子系统包括基建工程、基建维修和区域维护三个方面的内容，实体关系如图 示。 图 建维修管理 实体关系 6. 餐饮管理子系统 该子系统包括食堂管理、物品采购、餐厅管理记录、日常检查记录、商铺维护和菜品比对等模块。其中食堂管理是对食堂情况的单表维护。采购情况是对食堂指定物品采购的记录。餐厅管理记录管理对餐厅的触发 结果。日常检查记录对餐饮日常检查记录的单表维护。商铺维护记录了商铺的合同情况，以及具体位置和状态。菜品管理是对指定菜品的价格和销售方式进行单表维护。实体关系如图 示。 图 饮管理 实体 关系 7. 能耗管理子系统 包括电耗、水耗和供冷供热三个部分，实体关系如图 示。 第 二 章 需求分析与系统架构设计 27 图 耗管理实体关系 8. 物业管理 子系统 物业管理 子系统 需要维护很多检查项，并记录检查结果。每一个检查项项目归 属某个大类，某一个检查记录对应相应的检查项。每一个检查记录可有多次复查结果，实体关系如图 示： 图 业管理实体关系图 9. 安全管理子系统 安全管理 子系统 负责对教育活动和安全检查两类数据的 录入 ， 并无实体关联 。 因此无需描述实体关系图 。 10. 其他管理子系统 包括对商铺管理、交流中心两类检查进行管理。商铺管理针对不同的商铺列出多个检查项，并维护对这些商铺每个检查项的检查记录。 第 二 章 需求分析与系统架构设计 28 交流中心只针对交流中心维护检查项目并维护交流中心每个检查项的记录。 实体关系如图 示 。 图 他管理 实体关系 循功能分类的数据表分区设计 在完成各个功能子系统的实体关系分析后 ， 可针对每一个功能子系统进行独立的数据表设计 ， 高校后勤管理系统有复杂的功能体系 ， 为实现系统的松散耦合 ， 同时便于今后针对各个子系统进行独立的技术维护 ， 本文采取了垂直分区的理念进行数据库设计 ， 亦即针对每一个功能子系统设计相应的数据库表单，同时实现该功能子系统的数据库接口独立封装，不同的功能子系统之间明确实体关系 ，在技术实施过程中， 严禁独立调用其他功能模块的数据库表单。通过这样的设计，