基于UML的学校后勤报修管理系统的设计与实现毕业论文.docx

基于UML的学校后勤报修管理系统的设计与实现毕业论文.docx

《基于UML的学校后勤报修管理系统的设计与实现毕业论文.docx》由会员分享，可在线阅读，更多相关《基于UML的学校后勤报修管理系统的设计与实现毕业论文.docx（46页珍藏版）》请在冰豆网上搜索。

基于UML的学校后勤报修管理系统的设计与实现毕业论文

基于UML的学校后勤报修管理系统的设计与实现毕业论文

第一章绪论

1.1问题提出

随着高校每年的扩大招生，学校人数越来越多，学校后勤报修管理的工作量也越来越繁重。

使用传统的管理手段和方法，很难完成大量的信息分析和处理。

因此，充分利用网络资源和信息化技术，建设一套基于校园网的学校后勤报修管理系统，提高后勤管理水平、效率和质量，使学校后勤管理科学化、信息化、现代化，是新时期学校后勤管理工作面临的一个新的课题。

设计开发学校后勤报修管理系统，主要有一下几方面的原因：

1、传统的报修、维修环节，存在着方法落后、手续烦琐、工作量大的缺点，以不能适应新形势的要求；

2、高校不断扩招，学校的设备也不断增多，需利用现代化手段进行管理；

3、赶上新时代的步伐，实现后勤报修管理的规化、信息化，提高后勤报修管理的服务质量和服务效率。

基于以上的原因，原有的后勤报修维修手段，以不能适应新情况要求，为提高后勤管理效率和质量，降低后勤管理的人力、物力和财力，方便广大师生生活和学习，开发一个学校后勤报修管理系统十分重要。

1.2研究背景及现状

在信息化社会迎来知识经济的时代，校园的信息化和数字化建设成为国外高校建设的热点。

它的基本特征体现为高起点、高投资和快速，相对于国高校而言，还存在起步早的特点。

在一个多世纪以前，美国的一所大学就提出了数字化校园的概念，随后美国的麻省理工学院对这个概念，经过多年的努力研究，设计、构建出一个比较成熟的数字化校园的模型。

调查显示，在西方的发达国家中一些著名的世界大学，已经于上世纪末成功地建设好了数字化校园。

此外，我国在现阶段的信息数字化方面的工作，也开始进入一个全新的发展时期。

尤其是在信息化高校的建设方面，已经步入了全面的发展阶段。

许多高校都意识到信息化建设，是提高管理手段和水平，保证管理效率和质量的重要渠道。

然而，就信息化高校建设的整体上而言，我国的高等教育信息化、数字化、现代化，仍然处于社会主义初级阶段。

1.3论文组织结构

本文设置了六个章节：

第一章：

绪论。

对建设学校后勤报修管理系统问题的提出进行了简要的说明；对项目背景及研究现状作了简单介绍；对论文的容进行概要说明。

第二章：

系统需求分析。

这一章，主要对课题《基于UML的学校后勤报修管理系统》的功能需求和技术需求进行介绍；利用Rose工具对系统功能进行建模。

第三章：

总体设计。

本章的大体容是：

说明系统总体设计方案，确定功能模块，对模块进行详细设计，设计系统功能业务流程，数据库设计。

第四章：

系统实现。

对数据库的具体实现给出关键代码，对系统的功能实现进行展示并给出部分关键代码。

第五章：

系统测试。

对系统的功能进行测试，对测试结果进行分析。

第六章：

总结与展望。

总结全文，展望未来。

第二章系统需求分析

系统开发的第一步，就是要对系统进行需求分析，这是开发应用系统中最举足轻重且不可缺少的一项工作[1]。

需求分析的好坏程度，决定着系统开发的速度。

系统需求分析工作做得越精细，开发系统的过程就越快。

做需求分析的时候，一般需要了解本系统开发的背景，在信息收集的基础上，决定系统开发的技术、经济和操作可行性，进行业务调查和分析，了解用户的功能需求和工作流程，确定开发系统的总体方案，明确系统开发的总体思路和系统要达到的目标，以及系统开发所需要的时间和资金等问题。

通过对问题的理解和分析，将需求整理成规格说明书，为问题涉及的信息建立模型，描述如何实现系统。

2.1技术需求分析

本课题为《基于UML的学校后勤报修管理系统的设计与实现》，在系统开发之前，首先利用UML建模语言和RationalRose工具对系统功能进行分析建模，得出相应的模型图。

本系统采用B/S架构实现系统功能。

系统的前台设计与实现，主要使用JSP技术和Java语言处理完成；系统的后台则利用MySQL数据库作为数据库服务器。

按照前台与后台的区别，还应该细分为业务逻辑和表现逻辑。

即前端的JSP页面调用JAVABEAN来实现数据库操作的功能。

程序采用固定的布局，每个页面的固定部分都单独实现成为一个JSP程序，然后在每个具体的页面中包含他们，这样既保证了程序的布局统一，又能简化程序设计和调试。

系统的开发利用MyEclipse工具完成代码编写、调试和运行，利用本机作为服务器模拟实现系统功能。

2.2功能需求分析

根据调查，发现原有的学校设备报修的方法，都是通过手工登记信息、人工传递信息、人工通知维修人员、人工处理结果，手段落后，过程繁杂，效率低下。

鉴于此，我决定设计建设的学校后勤报修管理系统，应该具有一下功能：

（1）首先，系统需要设置三种权限的用户：

系统管理员、维修人员和普通用户。

（2）管理员的功能设置：

管理员可以审核新用户注册申请，可以对所有用户进行管理；可以对设备信息进行管理；能对设备维修结果发布通知公告，可更改个人密码。

（3）维修人员的功能设置：

可以查询和修改个人信息，能进行设备维修管理。

（4）普通用户的功能设置：

可以查询和修改个人信息，可以对故障设备进行报修。

（5）注册新用户与登录：

系统应提供注册新用户的功能，注册的用户可以注册为普通用户，也可以注册为维修人员，注册的用户需通过管理员审核后，才能登录系统，进行相关操作。

所有的系统用户都可以进行故障报修操作。

（6）系统存放学校所有设备信息，并提供可见。

管理员在系统录入学校所有的设备信息，为所有用户提供查询服务。

（7）外连通，时刻关注外界动态。

管理员定时更新站新闻，获取外界最新资讯；随时发布校通知公告，造福广大学生。

（8）设置服务指南、友情，方便用户上网；提供在线留言功能。

2.3系统功能建模

开发基于UML的学校后勤报修管理系统，首先要做的，就是在需求分析阶段绘制系统的功能用例图[2]。

用例图的建立是系统开发人士和用户经常反复讨论的结果，表明开发者和用户对系统需求达成一致的共识。

我们知道，用例图首先是描述了将要开发的系统的功能需求；接着，用例图将系统看着一个黑盒，从外部执行者的角度去理解系统；再者，用例图将驱动需求分析之后各阶段的系统开发工作，保证系统功能的实现，而且还可以用于检验所开发的系统，进而影响到系统开发的各个阶段的工作和UML的其他的图形。

2.3.1确定系统边界和围

确定系统边界和系统围，就是要确定在系统之中有什么，在系统外面又有什么。

系统的边界就是表明系统由谁来使用，就是要确定系统的参与者；系统能够为参与者提高什么样的功能，即确定参与者的用例。

在基于UML的学校后勤报修管理系统中，系统的参与者有三种。

参与者及其用例的说明，将在下一节进行分析。

随着参与者和用例的不断确定，系统的边界也将变得越来越明显。

2.3.2定义参与者并创建用例图

系统分析和设计的第一步工作就是创建用例图。

用例图是描述系统的用户或系统参与者行为的图，在系统的需求分析阶段非常重要，系统的整个开发过程，都是围绕着系统的用例需求进行的[3]。

创建学校后勤报修管理系统用例，找出系统的参与对象是要做的的第一步工作。

参与者，是代表系统接口的所有事物或人，它是一种有特定功能的角色，可以这么说，参与者是一个虚拟的概念，它既可以是人，还可以是外部设备或系统[4]。

经过分析，确定了以下系统的参与者：

管理员：

管理员主要对用户、设备信息进行维护，对新闻、公告、指南、友情等信息进行操作。

维修人员：

维修人员主要对个人信息进行管理，可以查询修改个人信息，还可以对设备进行维修。

普通用户：

普通用户主要是对故障设备进行报修以及对个人信息进行管理。

（1）管理员用例图

经过深思熟虑，确定了管理员能在系统中进行的活动：

①登录系统：

通过验证的管理员可以进入系统。

②修改密码：

成功登录系统后，管理员可以修改登录密码。

③审核用户：

管理员可以对注册申请进行审核。

④删除用户：

对不适合留在系统的用户，管理员可以将其踢出系统。

⑤添加普通管理员：

超级管理员可以根据需要添加普通管理员，共同管理系统。

⑥添加设备信息：

当有新设备时，管理员可以将其添加到系统中。

⑦删除设备信息：

当设备寿终正寝时，管理员可将其删除。

⑧添加站新闻：

为造福广大用户，管理员可添加最新资讯新闻。

⑨删除站新闻：

管理员可对新闻进行删除。

⑩添加通知公告：

为学生服务，发表学校最新的通知公告。

⑪回复留言：

对用户的在线留言进行回复。

⑫添加友情：

为方便用户上网，管理员可适当添加其他。

⑬返回前台：

在后台界面，管理员可以直接回到前台。

根据以上描述，画出管理员的用例图，如图2-1所示：

图2-1管理员用例图

（2）维修人员用例图

通过再三思索，对维修人员在系统中的活动设置如下：

①登录系统：

通过验证后，维修人员有权进入系统。

②修改密码：

对于个人密码，想改就改。

③修改个人信息：

系统提供维修人员修改个人信息的权力。

④查询个人信息：

个人信息对于个人不是秘密，当然要能查询。

⑤故障维修：

维修人员可将设备维修结果登入系统。

⑥故障报修：

有维修的能力，也有报修的权利。

⑦返回前台：

维修人员可从后台跳回前台。

根据以上描述，画出维修人员的用例图，如图2-2所示：

图2-2维修人员用例图

（3）普通用户用例图

考虑再三，也敲定了普通用户的系统活动：

①登录系统：

登录系统是每个用户的必不可少的活动。

②修改密码：

密码很重要，但是还是可以改变的。

③修改个人信息：

普通用户可以不普通，可以修改处亮瞎眼的个人信息。

④查询个人信息：

对于个人信息，用户想看就看。

⑤故障报修：

普通用户可以对故障设备进行报修。

⑥返回前台：

可以从后台直接转到前台。

根据以上描述，画出普通用户的用例图，见下图2-3：

图2-3普通用户用例图

2.4系统运行环境

1、硬件环境

本系统对CPU、存和硬盘容量等硬件环境没有特别的要求。

2、软件环境

本系统具备良好的平台无关性，无论是在Windows系统，还是Linux系统，或是其他操作系统上，并不需要修改任何代码都可以运行。

但是，要求系统的应用服务器具备支持Java组件运行的功能，系统的客户端运行环境，在IE5及以上浏览器运行，效果更佳。

第三章系统设计

3.1总体设计

3.1.1系统总框架设计

从系统功能的角度上面看，本系统主要设计了两大模块：

客户端，即系统前台；管理端，即系统后台。

在系统前台，设计了站新闻、通知公告、设备查询、用户注册、服务指南等功能模块；在系统后台，设计了三种权限的管理用户：

管理员、维修人员和普通用户。

每种用户都有属于自己的后台界面，每种用户的后台设计及模块说明如下：

1、管理员后台

在管理员的后台，设计了8个功能模块，分别是：

用户管理模块、站新闻管理模块、设备信息管理模块、报修管理模块、通知公告管理模块、服务指南管理模块、系统管理模块、系统操作模块。

2、维修人员后台

维修人员后台设计了3个模块：

个人资料管理模块、报修管理模块和系统操作模块。

3、普通用户后台

在普通用户后台，也设计了3个功能模块：

个人资料管理模块、我的报修模块和系统操作模块。

系统前台的功能结构图和后台功能结构分别如图3-1和图3-2所示：

图3-1前台功能结构图

本系统前台对游客开发，进入系统前台首页后，无须登录，便可以查看系统简介、新闻、公告、设备等信息。

但是，如果要对故障设备进行报修操作，必须先登录系统才能操作。

图3-2后台功能结构图

3.1.2系统后台功能模块设计

在上一节，已经对系统的总框架进行了设计和分析，得出了系统的前台和后台的功能结构图。

在这一节主要对系统的后台三个不同角色的功能模块进行设计和分析。

具体的设计如下：

1、管理员功能模块

（1）用户管理模块

管理员也有两种不同权限：

超级管理员和普通管理员。

超级管理员可以在这里添加普通管理员，普通管理员没有这个权限；超级管理员也可以对普通