机房管理系统毕业设计.docx

上传人:b****2 文档编号:23240823 上传时间:2023-05-15 格式:DOCX 页数:27 大小:470.85KB
下载 相关 举报
机房管理系统毕业设计.docx_第1页
第1页 / 共27页
机房管理系统毕业设计.docx_第2页
第2页 / 共27页
机房管理系统毕业设计.docx_第3页
第3页 / 共27页
机房管理系统毕业设计.docx_第4页
第4页 / 共27页
机房管理系统毕业设计.docx_第5页
第5页 / 共27页
点击查看更多>>
下载资源
资源描述

机房管理系统毕业设计.docx

《机房管理系统毕业设计.docx》由会员分享,可在线阅读,更多相关《机房管理系统毕业设计.docx(27页珍藏版)》请在冰豆网上搜索。

机房管理系统毕业设计.docx

机房管理系统毕业设计

第1章项目描述

1.1项目背景

随着计算机的普及,学校的计算机规模的扩大,学校机房的硬件设施越来越好,如何实现机房的效能,最大限度的为机房管理服务,通过提高机房管理的效率,使机房管理更加有序、规范。

我们必须设计出一个既方便又有序的机房管理系统。

计算机机房几乎担任了学校全部的计算机公共课程的上机实践工作,同时也是学生在课余时间上机的重要场所。

为了方便学校的管理,机房信息管理系统,是针对学生的上机信息,上课内容,以及上机时间、教师管理、预定机房、教师端与学生端发送信息功能,学生端可以查看自己的上机记录。

机房管理系统的开发也是在这种要求下应运而生的,机房管理系统的开发有助于方便机房的统一管理提高机房管理的效率,同时也方便老师和同学的上机。

项目开发为学校的业务管理人员服务,已明确用户有:

在校任课老师和就读学生、及相关的管理人员。

潜在用户有:

学生、任课老师。

机房上机管理信息系统是一套专门针对学校计算机机房管理的高科技产品。

机房管理信息系统是现代企业和学校机房管理工作不可缺少的一部分,是适应现代企业、学校机房制度要求、推动机房管理走向科学化、规范化的必要条件。

机房管理分析的是机房上机具体的工作过程,分析“做什么”应“如何做”的问题。

主要调查了解用户的需求,尽量满足并使用户和设计系统的人员意见相一致。

1.2问题描述

本系统是机房上机管理信息系统,是一个依靠组内人员共同的力量完成的各项任务。

要求要有较强的分析、设计、编程能力。

在老师的指导下使该系统更加完善、可靠。

开发出一个适合用户单位需要的系统,并方便维护和扩充。

它主要实现管理员如何对普通用户进行授权,学生业余上机只能通过输入会员卡号、密码方可使用该计算机。

如何修改所有会员的信息,也可通过输入查询条件,显示符合条件的会员记录以及显示这个会员的全部信息,并由管理员对其进行相应的操作。

建立一个“机房上机管理信息系统”,使用计算机对学校学生上机信息的管理。

要求不仅可用于一般的上机情况查询,而且可以对这些上机信息进行各种必要的数学统计和分析。

1.3捕获需求

机房信息管理,是针对学校人事处的大量业务处理工作而开发的管理软件,主要用于学校的学生信息管理,总体人物是实现学生信息管理的系统化、科学化、规范化、和自动化,其主要任务是使用计算机对学生的各种信息进行日常管理,如:

查找、删除、修改、增加、和按某一属性排序。

根据实际需求本系统需要解决的问题主要有以下几方面:

(1)用户的权限登录,依次为管理员、教师、学生三种权限。

(2)系统管理员检索各种信息;

(3)机房管理员和学生端之间的通信;

(4)机房管理员查看在线学生的上机情况;

(5)在线学生可以查看自己的上机学时;

(6)在线学生可以检索上机机房号;

(7)教师预定机房;

(8)系统管理员检索机房的预定情况;

(9)系统管理员对预约信息的修改、删除。

1.4开发坏境

开发环境:

操作系统为WindowsXP。

数据库管理系统为SQLServer2000个人版。

开发工具为PowerBuilder。

第2章需求分析

采用面向对象的分析方法,使用统一建模语言进行系统用例模型的建立,创建系统功能模型。

用例图强调用户希望看到的系统功能,用例图建模需要三个步骤:

参与者的确定;用例的创建;系统用例图的建模。

2.1系统功能需求分析

2.2主要参与者

1、系统管理员

系统管理员主要职责就是维护系统的正常运行,对系统的定期维护。

同时他们掌控着系统的各个功能,是此系统的真正操纵者。

还可以对如何操作系统进行讲解和加以说明。

他们不仅可以对预定机房进行管理、对机房管理员进行管理以及查看各个机房的情况。

2、机房管理员

机房管理员是机房的的管理人员,同时也是此系统的操纵者,他们有自己的系统登录模块,有自己的登录权利和自己的登录后的使用空间,他们可以检索机房的预定情况,还可以查看在线学生的上机情况。

他们是系统的违纪、锁屏、通信等模块的真正操作者。

3、教师

教师也是该系统的一个操作者,该系统的一个便利就是老师对机房预定,教师可以登录该系统后直接进行机房,也可以取消预定,因此教师是该系统的使用对象。

4、学生

学生对该系统的某些功能也有使用权力,系统同时也为学生提供了许多便利,学生登录之后可以根据教师名和课程名检索上机机房号,还可以查看自己的上机学时、以及跟机房管理员进行通信。

参与者符号如下图:

(1)图

(2)图(3)图(4)

2.3用例图

2.3.1系统用例图

用例图就是系统、用例以及它们之间的关系构成的图,主要显示用户对系统的需求,其主要功能有:

需求、测试、对系统起到指导作用。

经分析:

用户有教师、学生、机房管理员、系统管理员。

教师主要可以预约机房、查看自己信息、检索机房信息、进行广播等功能;学生主要有查看自己信息、与管理员进行通讯、查看上机学时等功能;机房管理员主要有查看自己信息、监控学生等功能;系统管理员主要有数据库管理、查看教师预约机房情况、查看机房信息等功能。

以下是该系统用例图,如图2.1所示:

图2.1系统用例图

2.4用例规约

用例规约主要是对用户的需求的描述,对功能的使用作进一步的讲解,使用户对系统功能了如指掌,才不会再使用时出错。

根据系统需求分别对教师预约机房用例、学生查看个人信息用例、检索机房信息用例、查看上机学时用例、通讯用例做了用例规约

表2.2预约机房用例规约

用例编号

Uc-1

用例名称

预约机房

用例描述

参与者可登录该系统进行机房预约

参与者

教师

前置条件

参与者登录该系统

后置条件

如果该用例成功,则预约机房成功

涉众利益

教师先检索机房是否被预约

教师可以正确预约机房

可以取消预约

 

基本路径

1参与者根据机房号、周次、节次对机房进行检索

2系统显示相关机房信息

3参与者查看某机房的信息

4系统显示该机房信息

5参与者预定该机房

6系统显示预订成功

扩展点

字段列表

机房号、周次、节次、教师姓名、教师所教科目

业务规则

 

表2.3查看个人信息用例规约

 

用例编号

Uc-2

用例名称

查看个人信息

用例描述

参与者可登录该系统进行机房预约

参与者

学生

前置条件

参与者登录该系统

后置条件

如果该用例成功,则查看机房信息成功

涉众利益

学生可以查看自己信息

进行修改个人信息

 

基本路径

1参与者根据填写个人信息进入个人界面

2系统显示个人信息

3参与者查看个人的信息

扩展点

字段列表

姓名、学号、班级、

表2.4检索机房信息用例规约

用例编号

Uc-3

用例名称

检检索机房信息

用例描述

参与者可登录该系统进行机房检索

参与者

教师

前置条件

参与者登录该系统

后置条件

如果该用例成功,则检索机房成功

涉众利益

教师先检索机房是否被预约

之后教师可以正确预约机房

 

基本路径

1参与者根据机房号、周次、节次对机房进行检索

2若该机房已被预约,则系统显示相关机房信息

3若该机房未被预约,参与者可以填写基本信息对机房进行预约

扩展点

字段列表

机房号、周次、节次、

业务规则

 

表2.5查看上机学时用例规约

用例编号

Uc-4

用例名称

查看上机学时

用例描述

参与者可登录该系统进行学时查询

参与者

学生

前置条件

参与者登录该系统

后置条件

如果该用例成功,则学时查询成功

涉众利益

学生只能查询不能修改

可以根据自己的上机学时决定以后的上机频率

 

基本路径

1参与者根据自己的信息登录该系统

2系统显示个人的相关信息

3参与者查看个人信息

扩展点

字段列表

姓名、学号、班级、机房号、周次、节次、教师姓名、课程名

业务规则

表2.6通讯用例规约

用例编号

Uc-5

用例名称

通讯用例

用例描述

参与者可登录该系统进行通讯

参与者

学生

前置条件

参与者登录该系统

后置条件

如果该用例成功,则通讯成功

涉众利益

学生希望可以俩人之间进行发送消息

可以收到消息

可以查看历史记录

 

基本路径

1参与者点开对话宽框

2系统显示对话框

3参与者编辑内容及文件

4系统显示该信息内容及文件

5参与者发送信息及文件

6系统显示发送成功

扩展点

字段列表

对话记录、全部记录、闪屏振动

业务规则

 

第3章系统设计

3.1系统实体总类图

根据系统分析,机房管理系统中应有实体类:

学生、教师、机房管理员、系统管理员,还应有控制类:

预约机房、查看上机学时、与管理员进行通讯、中断违纪进程、检索机房等,边界类:

界面.下面是实体类的方法和属性,教师与课表是关联关系,学生与班级是关联关系,其余是依赖关系,如图3.1所示:

图3.1实体类图

3.2系统实体时序图

根据以上分析该系统的实体有教师、学生、教师、机房管理员、系统管理员,所以教师时序图就是:

根据教师登录要进行的操作,教师登录后可查到自己信息、可对信息进行修改、也可预约机房、预约机房时必须先检索机房信息、才能进行预约。

下面是教师预约机房的时序图,如图3.2所示:

图3.2实体教师预定机房时序图

学生登录系统后首先看到的是个人信息、可进行修改、其次是查看上机学时,与管理员进行通讯,下面是学生登录后的操作的时序图,如图3.3所示:

图3.3实体学生查看信息时序图

3.3系统实体活动图

3.3.1实体教师预定机房活动图

活动图就是说明用例实现的流程,说明了系统主要提供的需求价值。

教师对系统的首要需求就是:

登录成功,教师根据自己的登录名、密码、登录成功后便可进行预约机房需求,下面是教师登录时的活动图,如图3.4所示:

图3.4实体教师登录活动图

 

教师登录成功后可进行机房预约,但在预约之前必须进行机房检索,看机房是否被预约,若未被预约则可进行预约,若以被预约,只能预约期其他机房。

下面是教师预约机房的活动图,如图3.5所示:

图3.5实体教师预定机房活动图

3.3.2实体学生查看信息、通讯活动图

学生登录该系统后,可查看自己的信息,对自己的信息进行修改、查看上机学时下面是学生查看自己信息的活动图,如图3.6所示:

图3.6实体学生查看信息活动图

学生登录该系统后,可查看与管理员进行通讯,下面是学生与管理员进行通讯的活动图,如图3.7所示:

图3.7实体学生与管理员通讯活动图

 

3.4数据库设计

3.4.1总体系统分析图

根据需求分析及总体设计,数据库设计有以下几个实体:

机房管理员、系统管理员、学生、教师,以及实体的各项功能,如图3.8所示:

图3.8机房管理系统分析图

3.5关系模式

数据库实体关系模式如下:

用户(用户名,密码,权限)

学生(学号,姓名,性别,班级,专业,密码,是否为管理员)

教师(教师号,姓名,性别,授课名称,专业)

管理员(姓名,密码)

3.6数据库的逻辑模型

根据该系统的需求,基于SQLServer2000数据库最后数据库主要的表有机房信息表、预约机房表、教师信息表、学生信息表、机房管理员信息表、系统管理员信息表、学生个人上机机时表。

以下将给出系统数据库设计的逻辑模型,即各数据表的结构以及该属性的数据类型。

表3.9学生信息表

字段名

含义

数据类型

数据宽度

NULL

备注

Xuhao

学号

Char

10

No

主键

Sex

性别

Char

20

Yes

Name

姓名

Char

12

Yes

Class

班级

Char

Yes

Zhuanye

专业

Char

50

Yes

Code

密码

Char

20

Yes

 

表3.10机房管理员信息表

字段名

含义

数据类型

数据宽度

NULL

备注

Glyzh

管理员账号

Char

10

No

主键

Glymm

管理员密码

Char

20

No

表3.11系统管理员信息表

字段名

含义

数据类型

数据宽度

NULL

备注

Glyzh

管理员账号

Char

10

No

主键

Glymm

管理员密码

Char

20

No

 

表3.12教师信息表

字段名

含义

数据类型

数据宽度

NULL

备注

jiaoshihao

教师号

Char

10

No

主键

Sex

性别

Char

20

Yes

Name

姓名

Char

12

Yes

Skmc

授课名称

Char

Yes

Zhuanye

专业

Char

50

Yes

Code

密码

Char

20

Yes

表3.13预约机房表

字段名

含义

数据类型

数据宽度

NULL

备注

Xm

姓名

Char

20

Yes

外键

Xh

教师号

Char

20

No

主键

Zhuanye

专业

Char

20

Yes

Class

课程名

Date

50

Yes

Jfh

机房号

Int

30

No

主键

Zhouci

周次

Int

20

Yes

Xingqi

星期

Int

20

Yes

Jieci

节次

Int

10

Yes

表3.14学生个人上机机时表

字段名

含义

数据类型

数据宽度

NULL

备注

Xh

学号

Char

10

No

外键

Xm

姓名

Char

20

No

外键

Shangjitime

上机时间

Jfh

机房号

Char

20

3.7界面设计

在进入系统前,我们需要经过简单的认证才能进入,因此需要提供一个简单的登录界面,

界面上我们有权限选定(教师、学生、管理员)。

当输入用户名和密码都正确时,就可以进入系统。

需要建立的登录界面,如图3.15所示:

图3.15机房管理系统登陆界面

教师登陆成功首先看到自己的信息。

图3.16所示:

图3.16教师工作界面

 

教师登陆成功后可进行预约机房,但在预约之前必须先检索机房是否已被预约,若该机房已被预约。

则该教师不能进行预约。

若机房未被预约。

则教师可进行预约。

教师预约机房时必须填入相关的信息才能进行预约。

预约机房界面,如图3.17所示:

图3.17教师预约机房界面

 

教师可对自己信息进行修改,教师修改密码界面,如图3.18所示:

图3.18教师修改密码界面

教师查看学生出勤记录界面,如图3.19所示:

图3.19教师查看学生出勤记录界面

学生登陆成功后,首先显示的是全部学生信息。

学生可以点击查看个人信息按钮查看自己信息,也可以查看上机学时:

如图3.20所示:

图3.20学生登录后的界面

学生登陆成功后,可在个人信息界面上点击修改密码按钮,进入以下界面,如图3.21所示:

图3.21学生修改密码界面

学生登陆成功后,可在个人信息界面上点击发送消息按钮,进入与管理员通讯界面,如图3.22所示:

图3.22学生与管理员通信界面

 

第四章系统测试

4.1测试的目的与任务

目的:

测试的根本目的就是为了发现尽可能多的缺陷。

这里的缺陷是一种泛称,它可以指功能的错误,也可以指性能低下,易用性差等等。

因此,测试是一种“破坏性”行为。

测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错。

即软件测试是为了“证伪”而非“证真”。

把证明程序无错当作测试目的不仅是不正确的,完全做不到的,而且对做好测试没有任何益处,甚至是十分有害的。

软件测试要设法使软件发生故障,暴露软件错误,能够发现错误的测试是成功的测试,否则是失败的测试。

软件测试的目的决定了如何去组织测试。

如果测试的目的是为了尽可能多地找出错误,那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。

 任务:

通过在计算机上执行程序,暴露程序中潜在的错误。

测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构,精心设计一组“高产”的测试用例(一组输入数据和与之对应的预期的输出结果,在设计测试用例时,应包括合理的输入数据和不合理的输入数据),利用这些用例执行程序,找出软件潜在的缺陷一个好的测试用例很可能找到至今为止尚未发现的缺陷的用例;一个成功的测试则是指揭示了至今为止尚未发现的缺陷的测试。

主观上由于开发人员思维的局限性,客观上由于目前开发的软件系统都由相当的复杂性,决定了在开发过程中出现软件错误是不可避免的。

若能及早排除开发中的错误,就可以排除给后期工作带来的麻烦,也就避免了付出高昂的代价,从而大大地提高了系统开发过程的效率,因此,软件测试在整个软件开发生命周期各个环节中都是不可缺少的。

 

4.2测试用例设计与测试结果

表4-4登录密码测试用例LO01

项目名称

机房管理系统

序号

版本号

1.0

说明

登录必须输入正确的密码

模块

登录

优先级

1

测试目的

验证:

必须输入正确的密码才能访问系统

初始条件

登录系统,进入系统主界面或其他界面

步骤

1.输入正确的登录名后,再输入正确的密码即可登录

2.系统打开其他页面

期望输出

在输入密码错误时希望提示:

密码错误,请重新输入!

的提示信息并出现“确定”按钮。

用户单击确定按钮后,即可重新输入密码。

实际输出

测试状态

编制人

XXX

编制时间

年月日

备注

表4-5登录权限测试用例LO02

项目名称

机房管理系统

序号

LO10

版本号

1.0

说明

登录时根据人员类别设置权限

模块

登录

优先级

1

测试目的

验证:

登录时根据人员类别设置权限,如果权限名与自己不符则不能登录。

初始条件

以学生身份登录系统

步骤

1.进入系统主界面或其他界面

2.执行系统学生权限范围的所有操作

期望输出

在权限错误的情况下希望提示:

请重新选择权限!

的提示信息并出现“确定”按钮。

用户单击确定按钮后,即可重新选择权限。

实际输出

测试状态

编制人

XXX

编制时间

年月日

备注

表4-6教师预约机房测试用例LO03

项目名称

机房管理系统

序号

LO07

版本号

1.0

说明

必须先正确登录

模块

登录

优先级

1

测试目的

验证:

教师预定机房

初始条件

进入登录界面

步骤

1.在登录名文本框中输入已存在的登录名

2.在教室工作界面上点击预约机房按钮

3.单击检索按钮

4.该机房未被预约输入相关信息进行预约

5.点击预约按钮

期望输出

检索机房时提示:

该机房已被预约!

和:

该机房未被预约!

请进行预约!

的提示信息并出现“确定”按钮。

用户单击确定按钮后,系统关闭提示框。

预约成功后提示:

预约成功!

实际输出

测试状态

编制人

XXX

编制时间

年月日

备注

表4-7学生修改信息测试用例LO04

项目名称

机房管理系统

序号

LO05

版本号

1.0

说明

先成功登录后,学生修改信息

模块

登录

优先级

1

测试目的

验证:

学生修改信息是否成功

初始条件

进入登录界面

步骤

1.在登录名文本框中输入已存在的登录名

2.在学生界面上点击修改信息按钮

3.输入原密码和新密码

4.点击修改按钮

期望输出

提示:

修改成功!

实际输出

测试状态

编制人

XXX

编制时间

年月日

备注

第五章总结

在为期一学期的课程设计之后,我感到自己的写文档能力有所提高,刚开始虽然觉得软件工程是一门很难的课,但后来对软件开发流程的了解,激发了我对它的兴趣。

软件工程课程虽已结束,但我对于软件工程的学习才刚刚开始。

我体会到项目管理的重要性,随着软件规模、复杂度的不断增加,项目开发中更多的是协作、管理和控制。

我学习到很多一般性的方法,例如:

需求获取、模块化、计划等等。

同时,我也认识到使用计算机解决实际问题的复杂性,人们认识表达的过程不断反复、逐步深化,软件工程方法要提供给程序员们一种更加有效的对客观世界问题域进行形式化的过程方法。

刚开始我认为:

需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。

对需求的获取往往有错误的认识:

用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,需求分析我现在还不能去问用户需要什么,想要什么,只能问同学和查阅资料,让他和我一起分析,他就当是用户,可以对我提任何有关这个系统的需求。

就这样我完成了该系统的需求分析。

其次是对问题的理解,用户对机房管理统的能力和限制缺乏了解,任何一个系统都会有不同类型的用户,每个用户只知道自己需要,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,用户与开发人员之间的交流很重要,但又往往忽略了那些被认为是"很明显"的信息。

那就是需求,需求往往随着时间的推移产生变动,使之难以确认。

所以我还是觉得需求分析很关键。

最后,在老师的指导下我们小组完成了这次作业。

“一个好的文档就是整个系统成功的一半”所以在今后的学习中,我一定会注意文档的格式和细节,在写程序的过程中,逐步规范形成自己的风格。

既方便自己的修改,又方便别人的阅读。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 经管营销 > 销售营销

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1