会议室管理系统的设计与实现.docx
- 文档编号:16348085
- 上传时间:2023-07-12
- 格式:DOCX
- 页数:50
- 大小:1.28MB
会议室管理系统的设计与实现.docx
《会议室管理系统的设计与实现.docx》由会员分享,可在线阅读,更多相关《会议室管理系统的设计与实现.docx(50页珍藏版)》请在冰点文库上搜索。
会议室管理系统的设计与实现
会议室管理系统的设计与实现
摘要
高校是学生和教师最常组织会议的场所,比如教师教学研讨会、行政工作安排会议、科研活动、社团活动等等,而组织这些必不可少的便是会议室。
截至目前,很多高校的会议室还没有一个系统化的管理。
存在预约和取消会议室程序复杂等问题,导致需要使用会议室的老师同学们只能用传统的方式去指定的办公室预定,有时候甚至需要人肉抢占会议室,给生活带来了极大的不便。
所以我们需要建立起完善的会议室管理系统,满足师生对于会议室预定的需求,让使用会议室成为足不出户即可预定,到约定时间即可使用的方便大众的事情,从而提高资源的利用率,降低会议室管理运营成本。
本文设计并且实现了一个B/S架构的会议室管理系统。
使用MicrosoftVisualStudioCode作为本次系统的开发工具,数据存储采用MySQL5.7关系型数据库,应用结构前后端分离,使用RestfulAPI进行前后端交互,整体采用比较先进的前后端技术。
网站功能包括用户注册、用户登录、预定会议室、取消会议室、抢占会议室、通知与会人员等功能,通过线上会议室管理,解决了人力资源浪费的问题,使得高校的各种会议活动能够更加高效地开展。
关键词:
B/S架构,会议室管理系统,RestfulAPI设计
Designanddevelopmentofconferenceroommanagementsystem
ABSTRACT
Universitiesarethemostcommonplacesforstudentsandteacherstoorganizemeetings,suchasteachers'teachingseminars,administrativeworkarrangementmeetings,scientificresearchactivities,communityactivities,andsoon.Meetingroomsareindispensable.Uptonow,theconferenceroomofalotofuniversitiesstilldoesnothaveasystematicmanagement.Therewillbecomplicatedproceduresfortheappointmentandcancellationoftheconferenceroom,resultinginteachersandstudentswhoneedtousetheconferenceroomcanonlyusethetraditionalwaytoreserveinthedesignatedoffice,andsometimesevenneedtooccupytheconferenceroombythemselves,whichbringsgreatinconveniencetolife.Therefore,weneedtoestablishasoundconferenceroommanagementsystemtomeettheneedsofteachersandstudentsforthereservationofconferencerooms,sothattheuseofconferenceroomscanbebookedwithoutleavinghomeandcanbeusedattheagreedtime,soastoimprovetheutilizationofresourcesandreducethecostofmanageandoperateconferencerooms.
ThispaperdesignsandimplementsaconferenceroommanagementsystembasedonB/Sarchitecture.Microsoftvisualstudiocodeisusedasthedevelopmenttool,andMySQL5.7isadoptedfordatastorage.Thefront-endandback-endoftheoverallstructureareseparated,usingRestfulAPIdesign,andadvancedtechnologiesareadopted.Thefunctionsofthewebsiteincludeuserregistration,userlogin,reservationofmeetingroom,cancellationofmeetingroom,preemptionofmeetingroom,notificationofparticipants,etc.Throughonlinemeetingroommanagement,theproblemofwasteofhumanresourcescanbesolved,sothatvariousmeetingactivitiesinuniversitiescanbecarriedoutmoreefficiently.
Keywords:
B/Sarchitecture,Conferenceroommanagementsystem,RestfulAPIdesign.
第1章绪论
本章中主要交代了会议室管理系统的背景和意义,调研并分析了国内外的相关产品的现状,从而总结出了本次课题所研究的主要内容,进而提出了最后期望达到的目标。
§1.1会议室管理系统的背景及意义
目前学校预定会议室极其不方便,会议组织者需要去指定办公室登记才能完成预约,到达会议指定时间还需要再去领钥匙才能使用会议室,这样的效率其实是非常低下的,会出现预约和修改预约会议室不方便,以及两个时间连续的会议室预约可能会因为各种原因无法正常衔接等等不合理现象。
而且雇佣人力来手动管理会议室,是一件费时费力、容易出错且浪费资源的事情。
所以实现会议室管理的数字化、科学化、网络化、标准化是非常必要的。
当然会议室管理系统的适用范围除了校园以外还适用于很多其他环境,比如企业,公共图书馆等等,该系统可以为用户提供了一个方便的平台,能够自主地对于会议室进行查询和预约,节约了人力成本和企业开销。
把互联网技术与我们的日常生活连接起来,体现了计算机技术在智能生活中的重要作用[1]。
§1.2会议室管理系统的现状和存在的问题
随着计算机科学技术日益发展,企业、政府等都在发展数字化管理,高校当然也不例外。
会议室数字化管理也是数字化管理的一部分,目前高校的会议室数字化管理较其他的方面仍有些落后,因此,建设一套全面且标准的高校会议室管理系统是非常重要且非常必要的,下面我将会阐述目前的研究现状以及存在的难点和问题。
§1.2.1研究现状
目前我国的会议室管理平台还在不断发展的阶段,我在校园、小企业和大企业都有生活和工作过,据自己的亲身经历,发现一个现象:
学校的会议室预定是需要去会议室管理办公室预约登记的;小型企业一般没有完善的会议室管理系统,如果需要会议室则需要自己抢占;而大型企业都具有非常全面的会议室预定和参会系统,为会议组织者节省了很多的时间和精力。
所以学校要进行会议室管理系统升级,可以向大企业的会议室管理系统学习交互视觉设计以及引用部分功能。
本次我重点调研了两个会议室管理系统,种类分别是校园级别和企业级别,二者在我的日常生活中使用频率都非常高:
一个是上海大学图书馆研习室预定系统,另一个是阿里巴巴的会议室预订系统。
上海大学图书馆研习室是目前学校最为先进的类会议室管理系统,我们可以在系统上直接选择需要预定的研习室以及预定的时间,非常方便。
当然还是存在一定的问题:
首先是和刷卡机器强耦合,需要将系统和每个研习室的刷卡机连接起来,才能完成打卡,扩展校园内其他会议室会比较困难,需要安装同样的刷卡机器并接入应用,成本较高;其次是只可选择与会人员,却无法通知对应的与会人员参与会议,很多情况下都是需要会议组织者通过其他渠道发送会议邀请通知;最后就是界面预览起来不够直观,有些同学需要长时间预定会议室来做科学研究或者研习讨论,可以推出类似于时间轴的界面,方便用户筛选所需要的会议室。
阿里巴巴的会议室预订系统整体是非常智能且商业化的会议室预订系统,功能十分全面,包括会议室预定、取消、抢占、通知与会人员以及线上会议等,整体的界面设计美观、使用感受流畅、应用功能强大。
总的来说,企业级会议室管理系统要比校园级别的会议室管理系统覆盖面更广、功能更齐全,所以校园级会议室管理系统还有许多需要向企业级会议室管理系统学习的地方。
本次的会议室管理系统开发与设计将秉承着向企业级会议室管理系统靠拢的原则,尽最大努力完成各项优化。
§1.2.2会议室管理系统的问题
经过了上面的调研,我总结了校园会议室管理系统目前存在的一些问题:
(1)与打卡机耦合严重,扩展成本较高。
(2)无法通知参会人员。
(3)时间线的预览不够直观,无法使用户一眼获取信息。
希望本次的课题研究能够将这些问题一一攻破,有质量地升级整个会议室管理系统。
§1.2.3会议室管理系统的难点
本次会议室管理系统的设计与实现会有以下难点:
(1)本系统将采用业内非常先进的技术架构,学习和设计成本较高。
(2)整个系统的交互和视觉都需要重新设计,相比传统的会议管理系统会有一定的不同。
(3)会议室预定功能的时间和状态的处理逻辑比较复杂。
(4)与会人员交互部分需要引入邮件交互。
§1.3主要研究内容
本文主要描述会议室管理系统的设计和实现,针对校园级会议室管理系统目前存在的一些问题,希望能够逐一解决,且在此基础上能够将用户体验进一步优化,更加完善整个会议室管理系统,为校园会议室管理数字化提供技术支持。
§1.4本文组织结构
本文一共分为六个章节。
第一章介绍了本课题的研究背景和意义,分析了会议室管理系统目前现状,对比了企业级别和校园级别的会议室管理系统之间的差距,整理出目前存在的问题以及研究课题会出现的难点,总结出本次的研究内容,最后提出最终希望达到的目标。
第二章介绍本次会议室管理系统开发中的技术架构,并对于其中所用到的部分比较新颖的技术做简略介绍,并和传统的类似技术进行对别研究,整理其优缺点以及最终选择本技术的原因,最后做出总结,并整理出完整的技术架构图。
第三章主要是对整个系统的需求进行分析整理,画出相应的用例图,并对本次开发的经济和技术可行性进行分析,最后做出总结。
第四章描述了整个课题应用的概要设计,包括整体流程设计、数据结构设计以及功能架构设计,整体流程设计利用流程图将用户的行为进行全面梳理,为开发时的用户交互设计打好基础,数据结构设计画出数据库E-R图的同时将数据库的实体结构设计也整理完成,功能架构设计整理出整个会议室管理系统将要实现的功能,并画出详细的功能架构图。
第五章详细介绍了整个应用的实现方式,从开发环境到系统的每部分功能都进行了详细的说明,系统功能实现部分以模块维度进行了从采用技术到细节代码的详细描述。
第六章总结了本课题会议室管理系统设计与开发所做的主要工作,同时归纳了本次课题的创新点,也指出一些仍需改进以及优化的地方,并对未来会议室管理相关行业的发展进行展望。
第2章技术架构介绍
本章主要介绍会议室管理系统的技术架构,包括应用的整体架构,和前后端以及数据库的技术介绍。
调研并对比新兴技术和传统技术,整理出二者的优缺点,并说明选取这些技术架构的原因。
§2.1整体架构
本次会议室管理系统主要采用了B/S架构、前后端分离架构,全程遵循RestfulAPI设计规范。
以上均为当下比较流行的架构模式,三者关系层层递进,越来越细化,本节将会逐一介绍这些架构并且阐述选择这些架构的原因[7]。
§2.1.1B/S架构
我们的计算机网络应用经历了几次更新迭代,从集中式计算,到C/S架构,到当下非常流行的B/S架构[5]。
其中C/S架构是技术成熟稳定性极好的架构模式,B/S则是从C/S架构中派生出来的新生代有潜力的新型架构,它们的简易对比图如下:
图2-1C/S架构和B/S架构的对比
传统的C/S架构有以下缺点:
(1)整体应用功能比较单一。
(2)对于网络速度的依赖性比较强,需要较好的网速,才能流畅地使用应用。
(3)安装步骤非常繁琐,在使用之前一般都需要再电脑或者手机安装客户端,不能做到即时可用,后续升级扩展起来也非常困难。
(4)对于不同的应用系统,比如Window、MacOS等,需要针对其分别编写不同的程序,工作量陡增。
(5)开发的人力和物理成本都很高,需要极高素质人才以及完备的初始好的客户端和服务器。
(6)后期维护成本同样很高,系统的维护升级会遇到非常多的瓶颈,且需要投入大量的人力财力物力。
所以本次会议室管理系用的基础架构我采用的是B/S架构,此架构对比C/S架构有以下优点:
(1)使用起来非常方便,只需要有一个浏览器,输入相应的网址即可。
(2)页面的更新扩展非常迅速,用户无需做任何操作,每次访问都可以直接访问最新版本。
(3)随着用户量增加,服务器负载加重,可以使用集群服务器,以平滑增加服务器的个数以保证负载均衡。
(4)开发成本和后期维护成本都比较低。
总的来说,C/S的体量太重,适合大型且功能强大的企业级应用,而本次的课题应用主要目标人群为高校老师和学生,而且应用的具体功能内容较少,体量较轻,且需要即插即用,故采用B/S架构更合适一些。
§2.1.2前后端分离
基于上面的B/S架构进行开发时,我们在应用层面更进一步需要引入前后端分离架构,前端和后端分别为不同的项目,在不同的服务器上进行独立部署,前端主要关注页面展示和数据的获取及处理,后端则主要处理复杂的业务逻辑,前端页面和后端服务器仅使用Json数据格式的API接口来进行交互。
B/S架构出现地初期,比较流行做JavaWeb项目[2],整个项目里面前端和后端内容逻辑黏着在一起,这样会出现一系列问题:
(1)代码耦合严重,整个开发项目体量过大,维护和扩展都比较困难。
(2)故障几率大大提升,所有代码部署在一起,一个小小的错误则可以导致整个系统瘫痪,由此可能会损失一大部分用户,甚至可能让公司造成巨大损失,后果十分严重。
(3)对于开发人员要求较高,前后端均得精通才可以完成整个开发,人力成本较高。
后来随着前端组件化、工程化的出现,前端体系的逐渐壮大,很多工程师开始专攻某一方向,逐渐就出现了前后端分离架构。
采用这种方式有很多优点:
(1)人力成本大大降低,前端工程师和后端工程师们各司其职,前端专注页面展示和产品效果开发,后端则专注数据存储和业务逻辑开发。
(2)适配性增强,后端的接口内容可以在各个平台复用,而前端相关的页面,只需要有浏览器即可,且已经出现了跨浏览器兼容的前端技术。
§2.1.3RestfulAPI设计
上面的前后端分离架构中有提到一下RestfulAPI设计规范,前后端交互的接口都是需要遵循RestfulAPI设计规范的,在目前业内是非常流行的。
RestfulAPI设计主要包括以下三部分内容:
(1)URL请求的整体结构,一般采用动宾结构。
动词也就是我们最常使用的四个HTTP请求方法:
GET、POST、PUT、DELETE。
宾语一般为我们需要查询的内容,比如文章:
article。
最后我们URL设计出来的查询文章接口的结构则为GET/article。
(2)状态码,每次请求服务端,服务端给出的回应包括状态码和数据。
我们可以根据状态码初步判断当前的请求状态,详情如下图:
图2-2HTTP状态码
(3)返回数据结构,在标准的RestfulAPI中,数据结构应该是json格式。
总的来说,在Rest设计规范中,每个请求地址代表着一种资源,使用RestfulAPI能够更好地帮助我们贯彻B/S架构和前后端分离架构。
§2.2前端技术介绍
在采用以上架构的基础上,便可以开始搭建整个应用的环境,前端技术方面我采用当前社区非常流行的开发模式与框架,本节将会介绍在本次研发过程中使用的前端相关技术。
§2.2.1React
React是目前非常流行的前端开发JavaScript库,主要功能为构建用户界面,它的主要特点为组件化和声明式。
图2-3React简介
目前使用此框架的公司有:
Facebook、雅虎、Alibaba、Instagram等等,有很优厚的社区资源,相应的配套设施也很全面,能够满足各种场景中的各类开发需求。
§2.2.2ReactRouter
路由管理是每个B/S架构的应用程序开发中必不可少的一环,一般路由存在两种模式:
Hash模式和History模式。
Hash模式(前端路由):
此模式每次路由切换改变的是我们URL中“#”号后面的部分,每次改变会触发HashChange事件,请求时不会带“#”后面的内容,不会造成后端匹配不到资源返回404。
但是它也有一定的缺点:
(1)首先是以前的页面中“#”后的锚点值都是用来做页面定位的,由于hash路由占掉了这个值,以前的锚点定位功能就不能再正常使用了。
(2)其次是由于hash路由的传参都是基于URL的,会存在一定的长度和体积限制,如果想要传递比较复杂的数据结构则会出现性能瓶颈。
History模式(后端路由):
History模式和Hash模式最大的区别就是URL中没有“#”号,URL整体看起来会更加美观一些,可以使用history.pushState()等等API来操作改变URL,不过使用过程中还是要注意每个路由都需要在后端做备案匹配,因为点击刷新时如果后端没有相应路由的资源可能会造成返回404。
总的来说,为了观赏美观和操作方便,本次会议室管理系统中所采用的路由模式为History模式,并结合ReactRouter这个JavaScript库来进行整个系统的路由管理。
§2.2.3AntDesign
Antdesign是基于React的UI组件库。
图2-4AntDesign和React图标
在我们日常的前端开发中,一个简单的select下拉选择和取值操作,需要我们写很多HTML、CSS、JavaScript代码,最终组合起来才能完成这一简单的功能。
我们的应用中有很多复杂的交互,如果所有的内容全部都原生实现,代码量会十分庞大,且整个架构也难以理清晰,容易出现各种隐含漏洞。
故我们可以采用目前已有的开源UI库,选择质量高且开箱即用的组件库,使得在开发过程中我们不用过于关注交互样式,而将重心转移到业务逻辑中去,能够大大提升我们的开发效率。
其实目前国内的大型互联网公司都有沉淀适合自己风格的UI组件库,这样能够极大地迎合自己的业务,且能够做到快速开发。
所以我们在日常开发中也可以学习这种精神,如果有精力自己写一个组件库最好,如果实在没有那么多时间,多学习并使用大型开源UI组件库也是一个不错的选择。
§2.2.4Webpack
图2-5webpack功能简图
前面我们采用的JavaScript库React以及我们后面要说的Less,它们的语法是jsx语法和Less语法,而我们的浏览器只认识HTML、CSS、JavaScript,那如何让这些语法能够在浏览器中运行呢?
需要将它们转换成浏览器能理解的JavaScript和CSS语法,这就需要使用我们的webpack打包工具。
当然这只是webpack众多功能中的小功能,它的整个功能远远比上述强大。
对于webpack来说,所有的内容都是模块,模块之间会有互相依赖关系,webpack通过跟踪里面的依赖,将一个个小模块最终打包成一个大的浏览器可以理解的app.js中,这只是webpack默认的行为,里面还有很多可以优化的地方,比如开放多个include入口,做treeShaking等等,这些优化都是可以自己写webpack配置来实现的,如何写配置这个问题涉及的内容就比较繁多,可以参考webpack官网上面的内容来进行学习。
§2.2.5Less
写CSS时是会遇到这种情况,兄弟节点、父子节点之间的CSS控制,由于CSS不支持嵌套语法,我们需要写很多重复的代码,十分繁琐,这个时候我们就可以引入Less,它的主要功能是对CSS进行预处理,并对其进行扩展,增加一些特性,最常用的有以下几个:
(1)变量特性,我们可以方便地统一一些数据,将变量集中在一个全局文件中进行保存。
比如想要统一所有矩形的宽高。
(2)Mixins(混入),很多模块的CSS样式有公共的内容,但也有很多特殊的地方,这个时候就可以公共的引入我们的Mixins,将公共部分提取出来,需要的时候导入即可,同时也能继续书写CSS,对于每个模块进行特殊化处理。
(3)NestedRules(嵌套规则),这便是前面提到的嵌套语法,我们可以直接在父组件的CSS内部书写子组件的嵌套CSS,形成继承关系,减少冗余的代码。
使用Less之后,我们开发过程中写CSS的效率就可以大大提高。
§2.3后端技术介绍
本次课题采用的后端技术也和前端技术一样是当前社区非常流行的开发模式与框架,本节我将会重点介绍其中的一部分技术。
§2.3.1Nodejs
本次后端语言我采用的是Nodejs,因为我以后将会成为一名前端工程师,学习Nodejs语言是我的必修课,它时基于chromev8引擎的,使得JavaScript可以运行在服务端环境中。
Nodejs运行模型的特点是:
事件驱动和非阻塞。
相较于其他语言其实更加适合我们的前后端分离场景,事件驱动其中的事件也就是前端页面发来请求,非阻塞是因为Nodejs有固定的事件循环模型,不会产生棘手的阻塞情况[3]。
具体事件循环模型如下:
图2-6Nodejs事件循环模型图
§2.3.2Express
虽然直接使用Nodejs是可以完成服务端的功能,但是会存在一些问题:
(1)所有的内容都需要自己编码,包括各种请求链路细节,容易出现难以发现的逻辑问题。
(2)和其他开源库融合可能会存在一些问题,因为很多开源库是转为某一框架定制的。
基于以上问题,最终决定引入一个Nodejs框架方便我们的服务端开发,目前比较流行的Nodejs框架有eggjs、koa、express,egg属于大型企业级Nodejs框架,整体搭建起来比较费时费力,虽然最终性能会更好,但是整体投入/产出比不够高,koa和express作者虽为同一个人,但是其中的差异是非常大的:
(1)体量差异较大。
koa主要采用中间件机制,轻量且易扩展。
express将很多常用插件封装在内部,使得搭建起来非常容易,可以做到即插即用。
(2)ECMAScript版本有差异。
express采用的还是旧版的ES5,异步处理只能使用回调函数的方式,而koa则可以采用async/await语法。
(3)中间件调用机制不同。
express采用线性执行的方式,每个中间件只能获取请求一次,比如错误处理中间件,需要在代码的最后进行调用才能正确捕获到所有的错误,而koa采用的是洋葱模型,每个中间件可以在请求进入和请求出来时分别获取到请求对象,并作出相应的处理。
图2-7Koa洋葱圈模型图
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 会议室 管理 系统 设计 实现