UML教室管理系统设计.docx

UML教室管理系统设计.docx

《UML教室管理系统设计.docx》由会员分享，可在线阅读，更多相关《UML教室管理系统设计.docx（13页珍藏版）》请在冰点文库上搜索。

UML教室管理系统设计

2017届结课论文

《UML基础与ROSE建模实用教程》

－教室管理系统设计

学生姓名

学号

所属学院

专业

班级

塔里木大学教务处制

基于UML的教室管理系统设计

1.需求分析

随着计算机技术、网络技术和信息技术的发展，现在办公系统更趋于系统化、科学化和网络化。

网络办公自动化系统是计算机技术和网络迅速发展的一个办公应用解决方案，它的主要目的是实现信息交流和信息共性，提供协同工作的手段，提高办公的效率，让人们从繁琐的有纸办公中解脱出来。

现在许多的机关单位的人事管理水平还停留在纸介质的基础上，这样的机制已经不能适应时代的发展，因为它浪费了许多的人力和物力，在信息时代这种传统的管理方法必然被计算机为基础的信息管理所取代。

1.1性能要求概述

（1）保证数据安全性，针对写入和修改数据库有数据安全锁；

（2）保证系统安全性，有访问权限的设置；

（3）优化客户操作界面，面向非专业人士。

1.2词汇分析

通过简单的词汇分析，对设计有初步的构想，同时有助于进行初步的设计分析。

教室管理系统

教师：

教师编号教室名称教室查询教室申请

学生：

学生编号学生名称教室查询教室申请

管理员：

教室查询添加修改删除审核

教室：

教室信息（教室编号、教室名称）

查询：

查询人教室信息查询日期

申请：

申请人教室信息申请日期（申请表）

审核：

审核通知审核时间审核编号（审核表）

通知：

通知编号通知时间通知对象（通知表）

1.3功能要求概述

（1）基本功能：

使用该系统有三个角色：

教师，学生，管理员。

系统应当完成以下的信息处理：

a、教室基本信息管理：

包含教室信息的录入、修改等功能。

b、教室使用信息管理：

包含教室查询功能。

c、教室申请信息管理：

包含教室申请功能。

（2）系统主要功能模块

系统可分为4个模块：

①用户信息管理

②教室基本信息管理

③教室查询

④教室申请

1.4安全性与完整性要求

安全性要求：

1、系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用； 

2、系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和容； 

3、系统应对不同用户设置不同的权限，区分不同的用户，如学生、教师和管理员。

学生（只能查询教室、教师和课程信息以及提出借用教室申请），教师（只能查询教室、课程信息，以及提出借用教室申请），管理员（可进行日常事务的处理，如增加、删除、更新课程、教室、教师信息，并批准或拒绝借用教室的申请）。

完整性要求：

1、各种信息记录的完整性，信息记录容不能为空； 

2、各种数据间相互的联系的正确性； 

3、相同的数据在不同记录中的一致性。

2.用例模型及实体类图描述

2.1系统用例图

1、用户信息管理模块：

验证用户身份，确认为合法用户后进入相应界面进行相关操作（如对用户信息进行添加，删除，修改，查询），如如图

（1）所示。

图

（1）学生信息管理用例图

2、教室基本信息管理模块：

对教室信息进行添加，删除，修改，查询，如图

（2）所示。

图

（2）教室信息管理用例图

3、教室查询模块

查询相关教室的基本信息以及该教室在任一天任一个时段的使用情况，如图（3）所示

教室查询：

教室信息

使用装态

图（3）教室查询用例图

4、教室申请模块

申请获得教室在某段时间的使用权，如图（4）所示

（1）非管理员：

申请教室、提出申请

（2）管理员：

查询教室、审核申请

图（4）教室申请用例图

2.2教室信息维护模块用例图

系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用。

如下图2.2所示

图2.2教室信息维护模块图

3.创建系统静态模型

3.1实体类图分析

名词：

教师类：

教师编号教师名称学生类：

学生编号学生名称

学生类：

学生编号学生名称管理员类：

教室查询管理员名称

教室类：

教室信息（教室编号、教室名称、类型）

动词：

查询类：

查询人教室信息查询日期

申请类：

申请人教室信息申请日期

审核类：

审核通知审核时间审核编号

通知类：

通知编号通知时间通知对象

3.2实体联系图

总体设计思路，学生和老师通过查看数据库，查看存在能够正常使用教室的占用情况来填写申请表，申请表经过管理员审核后，生成一审核通过的表，并通知同学或老师申请结果。

根据各信息之间的关系，建立如下实体关系图，如图3.2所示。

图3.2实体联系图

4.创建系统动态模型

4.1序列图

序列图是对对象之间传送消息的时间顺序的可视化表示。

序列图的主要用途是把用例表达的需求，转化为进一步、更加正式层次的精细表达。

用例常常被细化为一个或者更多的序列图。

同时序列图更有效地描述如何分配各个类的职责以及各类具有相应职责的原因。

下图描述申请人查看存在数据库上教室的信息的序列图，如图4.1所示。

1：

请求信息

2：

获取信息

3：

加载教室信息

图4.1查询教室信息的时序图

4.2活动图

（1）对学生申请教室活动图中的数据说明如下图4.2

（1）：

1：

查询教室

2：

审核申请

3：

填写申请

4：

提交申请表

5：

退出申请

4.2

（1）学生申请教室活动图

（2）对管理员处理申请活动图中的数据说明如下图4.2.

（2）：

1：

查询教室是否为空，教室不为空，重新进行查询

2：

选择教室申请，填写并提交教室申请表

3：

移交至管理员处等待审核

4：

查看申请表，审核意见回复

5：

在已提交的申请表查看审核意见

6：

退出申请

4.2.

（2）管理员处理申请活动图

5.创建系统部署模型

5.1系统构件图

构件图是用来表示系统中构件与构件之间，类或接口与构件之间的依赖关系图。

其中，构件图之间的关系表现为依赖关系。

教室管理系统的构件图通过构件映射到系统的实现类中，说明该构件物理实现的逻辑类，在本系统中，学生类、教室类、界面类，数据控制类和系统管理员分别创建

对应的构建进行映射。

教室管理系统构件图如图5.1所示。

图5.1系统构件图

5．2系统部署模型

教室管理系统的部署图描绘的是系统节点上运行资源的安排，包括4个节点，分别是：

客户浏览器、http服务器、数据库服务器和打印机。

创建的部署图如图5.2所示。

图5.2系统部署模型

6.总结

通过本次课程能够让我大胆的设计与猜想，翱翔在思想的蓝天里，加上不断地收集资料和整理，完成了简单的教室信息管理系统设计。

系统还存在许多不足之处，还需要不断地完善和优化，但是通过本次设计，我体会到一个设计有最初的一个框架到完整的部分，这个过程需要我们多去思考，不断地改良。

实现教室信息管理的功能，各模块也能够达到指定所指定的要求。

系统可以实现教室信息的集中管理、分散操作、检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。

这些优点能够极大地提高教室信息管理的效率,也是学校的科学化、正规化管理,与世界接轨的重要条件。

通过系统的设计，学会实现在各种实用的数据库型软件的开发，以及了解了信息管理的一些流程，也更加深入理解了UML设计中常见问题和其设计的意义。

本文在详细分析了教室信息管理的各功能模块基础上，设计并实现了教室信息管理系统的简易版本。

本文的主要工作包括以下几个方面：

经过不断地的设计和修改，教室管理系统基本开发完毕，但是由于设计开发时间较短，所以该系统还有许多不尽如人意的地方，比如存在正常教室授课管理、系统出错处理等一些问题。

在今后的进一步学习中，我将对这些问题进行完善。