软件工程课程设计学生信息管理系统Word格式.docx
- 文档编号:17668688
- 上传时间:2022-12-08
- 格式:DOCX
- 页数:14
- 大小:200.69KB
软件工程课程设计学生信息管理系统Word格式.docx
《软件工程课程设计学生信息管理系统Word格式.docx》由会员分享,可在线阅读,更多相关《软件工程课程设计学生信息管理系统Word格式.docx(14页珍藏版)》请在冰豆网上搜索。
1.2.2功能需求
学生管理系统的目的是实现学生信息录入、查看、调用等业务的自动化管理,以提高工作效率。
学生信息管理系统主要包括以下几个功能模块:
1.学生信息管理:
有关学籍等信息的录入、查询和修改,包括学生基本信息,所在学院,专业班级等。
2.课程信息管理:
学生已学课程和正在学习课程。
3.成绩信息管理:
学生课程成绩查询。
4.学生选课管理:
学生选课系统。
5.任课老师查询:
查询正在学习课程的老师信息。
系统功能模块:
1.2.3数据流图
学生信息管理系统
学生
登陆
学生信息
学生成绩
任课老师
查询
查询修改
顶层数据流层图
对顶层数据流图进行分解,分离出两个加工:
读者要求处理和管理员要求处理,分别编号为1和2.由于加工分离出来,原先属于内部数据流(文件)的部分(如期刊目录文件、期刊登记文件和期刊内容文件)这里就变成了外部数据流,它们被标在第二层数据流图上,“读者要求处理”加工分别从期刊内容文件、期刊登记文件和期刊目录文件读数据,“管理员要求处理”加工不仅从期刊目录文件读数据,当数据处理完成后,还要向期刊目录文件写入数据。
分解后的第二层数据流图如图1-5所示。
图1-5第二层数据流图
接下来对加工1和2继续分解。
同理,加工1进一步分解五个子加工:
加工1.1读者要求分类,加工1.2变动处理,加工1.3借阅处理,加工1.4归还处理,加工1.5查询要求处理。
加工2进一步分解成三个子加工:
加工2.1管理要求分类,加工2.2期刊登记,加工2.3期刊征订。
原先的内部数据流:
读者文件和借阅文件变成了外部数据流,第三层数据流图如图1-6所示。
加工1.5包含多种查询,可以进一步分解,变成三个加工:
加工1.5.1查询要求分类,加工1.5.2查询期刊去向,加工1.5.3查询期刊内容,第四层数据流图如图1-7所示
图1-6第三层数据流图
图1-7第四层数据流图
1.2.4数据字典
1.文件条目
用户=[学生|管理员]
用户文件={用户名}
期刊目录文件={刊号+刊名+邮发代号+主办单位+出版周期}
期刊登记文件={刊号+年+(卷)+期}
期刊借阅文件={用户名+刊名+年+(卷)+期+借阅日期+归还日期}
期刊内容文件={刊号+年+(卷)+期+文章题目+作者单位+作者姓名+关键词1+关键词2+关键词3+关键词4+关键词5}
2.数据条目
征订单={刊号+邮发代号+单价+数量+金额}
期刊去向信息={刊名+年+(卷)+期+读者姓名}
期刊内容信息={关键词1+关键词2+关键词3+关键词4+关键词5+刊名+年+(卷)+期}
变动要求={添加|更改|删除}
借阅要求={用户名+刊名+年+(卷)+期}
归还要求={用户名+刊名+年+(卷)+期}
按关键词查询要求={(关键词1)+(关键词2)+(关键词3)+(关键词4)+(关键词5)}
查询期刊去向要求={刊号+刊名+年+(卷)+期}
1.2.5E-R图
系统的E-R图如图所示。
性别
姓名
民族
籍贯
入校日期
学院
专业
学号
选课
成绩
课程
上课时间
课程类别
授课教师
课程名
课程号
图1-8期刊管理系统的E-R图
1.2.6性能要求
在性能方面,要求系统的查询和更新时间不超过一秒。
其他一些要求如下:
系统最小寿命:
系统应该能在无重大改动的条件下正常运行5年以上。
设备要求:
计算机稳定性良好,整套系统经济实惠。
在使用上:
要求系统易理解,易学习,易操作。
在安全性上:
要求系统安全可靠,容错,易恢复。
在数据集中上:
要求用统一的数据库实现数据的完整性和实时性。
在可维护性上:
要求系统可修改,可测试,可扩充,可移植。
1.2.7运行环境
对本系统运行环境没有特殊要求,以下硬件配置就可以满足要求:
服务器CPU为PentiumII300或更高配置,内存128MB以上,硬盘至少为500MB,网络适配器10Mbps或更快的网卡,一个CD-ROM驱动器,打印机一台,UPS(选配),客户机CPU为Pentium200或更高配置,内存64MB以上,硬盘至少100MB。
二概要设计
2.1设计思想
(1)系统分成几个相对独立的模块。
(2)分层的模块化程序设计思想,整个系统采用模块化设计结构,作为应用程序有较强的可操作性和可扩展性。
(3)合理的数据流设计,在应用系统设计中,相对独立的模块间的数据流相互连接,使各模块间的耦合性较低,方便系统运行,提高系统安全性。
2.2功能需求
随着管理信息系统应用的深入,学校可以逐步建立起一套科学的管理应用系统。
首先,可以通过这样的系统更深入的了解学生信息,直接建立合理管理学生信息的数据系统,如:
(1)学生登录可以使用查阅本人的基本情况、查阅本人所学课程成绩情况、查阅课程的任课老师情况、修改本人的基本信息以及对本人的登录密码进行编辑等权限;
(2)教务人员登录可以查看教师本人的基本信息、所教课程成绩、所教课程的基本信息、成绩的发布与录入以及登录密码编辑等权限;
(3)管理人员登录可以查看登录人员的账户信息、对学生信息进行管理、对教师信息进行管理、对课程进行各种管理等。
将这样的系统和已有的管理和业务系统联系起来,构筑成能够及时反应的教务系统。
从而更加快捷地达到与学生信息交互,提高教务教学管理运作效率。
将这样的系统同时提供给学校内各班级内部使用,能够极大地提高学校教务管理水平。
而学生信息管理系统作为教务管理的中间环节,有着尤为重要的意义。
完善的学生信息管理是学校健康运作的一个重要标志。
然而,完善的学生信息管理需要学校许多的资源,如何简化教务的管理而不失其完整性和科学性是许多学校头痛的问题,也是本系统在功能上力求解决的一个问题。
随着学校教务的扩展和工作量的增加,数据量不断扩大。
为了满足工作需要,必须实现各子系统之间能够共享数据,实现需要的统一管理和自动化数据传递,结合学生信息管理要点提出以下主要功能需求。
包括学生信息的管理、班级信息的管理、教师信息的管理、课程信息的管理、学生选课管理以及成绩管理,并具有严格的系统用户及分级权限控制,保证了教学数据的严格保密性。
2.3性能需求
一般的性能需求是指相互消息传递顺利,协议分析正确,界面友好,运行时间满足使用需要,安全性得到完全保证。
就实际情况,在高系统配置、高网络带宽很容易得到保证的情况下,最需要考虑的性能需求就是系统安全性问题。
在开发系统的每个阶段,均需要考虑彼此间的认证与授权。
尤其要注意认证,简单地说就是确定谁是特定用户,并针对安全源验证该用户的身份。
在处理完识别用户的方法之后,必须开发一种方法以向用户授权,从而能够使用系统的特定功能。
也就是说,需要一种方法来决定允许特定用户进行什么样的操作。
这些都是进行下一步系统设计时需要考虑的性能方面内容[7]。
2.4系统框架
本系统的框架如下图3.1所示:
图3.1系统框架图
2.4.1系统流程分析
用户首先登录系统初始页面,进行身份选择后,输入账号密码进行登录,如果身份选择的是学生,那么登录之后将会面对的选项有基本信息查询、学生成绩查询、成绩排名、任课老师查询、修改密码、修改基本信息,最后选择注销退回登录初始界面;
若选择教师身份登录,那么将会面对的选项有查看基本信息、查看课程成绩、密码修改、查看课程信息、成绩修改、成绩录入,最后依然是注销回到登录初始界面;
最后便是管理员身份登录,登录之后还会面对四个模块,首先是账户信息管理,包括显示个人信息、修改账户信息、修改备注、增加账户、删除账户以及用户信息浏览;
其次是学生信息管理,包括学生信息浏览、学生信息查询、学生信息修改、学生信息删除已经学生信息插入;
然后便是教师信息管理,这个模块与学生信息管理模块较为相似,功能包括教师信息浏览、教师信息查询、教师信息修改、教师信息删除以及教师信息插入;
最后是成绩课程管理,包括有课程信息浏览、任课信息查询、任课修改删除、修改删除科目,课程安排以及添加科目。
2.4.2系统功能模块分析
用户管理(管理员与教师管理和学生管理)课程信息管理、教师信息管理、成绩信息管理、课程信息管理、学生选课管理。
3.2学生登录模块功能图
3.3教师登录模块功能图
3.4管理员登录模块功能图
(1)学生登录模块
该模块主要由六个子模块构成。
分别是基本信息查询、学生成绩查询、成绩排名、任课老师排名、修改密码、修改基本信息六个模块。
主要功能包括学生的学籍和成绩查询以及个人信息的相关修改。
(2)教师登录模块
该模块主要负责教师对自己所教课程的成绩进行相关管理以及查看课程信息。
当以教师身份登录进来之后,可以修改教师本人所教课程的成绩,录入该门课程成绩等功能,另外可以查看个人信息,课程成绩以及课程信息。
(3)管理员登录模块
该模块相对于学生与教师模块属于后台模块,是对于学生和教师以及课程信息的一个综合性管理模块。
该模块又分为四个模块,分别为账户信息管理、学生信息管理、教师信息管理和课程成绩管理,在账户信息管理中,可以显示管理员本人的信息,可以修改管理员账户的密码,可以修改管理员的个人备注,可以增加和删除超级用户的人数,也可以对用户信息进行浏览;
在学生管理模块与教师管理模块中,可以对学生以及教师的信息进行浏览、查询、修改、删除以及插入;
而在成绩课程管理模块中包括课程信息浏览,可以统一的浏览学校的各门课程的情况,任课信息查询则可以通过教师姓名或者课程姓名进行查询,在任课修改删除模块中,可以通过选择相关课程的课名,然后实施修改或者删除该门课程的任课老师,在修改删除科目选项中,可以先通过课程号对课程进行选择,然后再进行修改或删除,课程安排选项里,可以对授课时间进行统一的插入与删除操作,而在最后的添加科目中,可以添加新的课程,并且任命授课老师。
三、系统详细设计
3.1管理员用例图
用例图是用来描述系统与参与者之间的相互作用的,也可以说它是从管理员的角度出发对如何使用系统的描述。
用例图可以比较直观的反映系统的构造,在本系统中对管理员的用例分析如下图5.1所示:
图5.1管理员用例图
用例描述如下:
(1)学生信息管理
此模块只有管理员才能用来浏览,查询,修改,删除和插入学生的有关信息。
(2)用户信息管理
该模块用来对超级用户的信息进行添加,修改,查看,删除等,此模块只有管理员才能使用。
(3)教师信息管理
此模块只有管理员才能用来浏览,查询,修改,删除和插入教师的有关信息。
(4)课程信息管理
该模块用来对所罗列的课程进行查看,删除等,此模块只有管理员才能使用。
3.2用户状态图
状态图是描述一个实体基于事件反应的动态行为,显示了该实体如何根据当前所处的状态对不同的事件做出反应的[10]。
通常创建一个UML状态图是为了以下的研究目的:
研究类、角色、子系统或组件的复杂行为。
本系统的的状态图如图5.2所示:
登录
状态=成功
提交
查询信息
状态=登录
增删改查
更新
登录请求
状态=未登录
填写账号密码
状态=填写
图5.2用户状态图
状态图用于显示状态机(它指定对象所在的状态序列)、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
状态机用于对模型元素的动态行为进行建模,更具体地说,就是对系统行为中受事件驱动的方面进行建模。
状态机专门用于定义依赖于状态的行为(即根据模型元素所处的状态而有所变化的行为)。
其行为不会随着其元素状态发生变化的模型元素不需要用状态机来描述其行为(这些元素通常是主要负载管理数据的被动类)。
状态机由状态组成,各状态由转移链接在一起。
状态是对象执行某项活动或等待某个事件时的条件。
转移是两个状态之间的关系,它由某个事件触发,然后执行特定的操作或评估并导致特定的结束状态。
3.3用户活动图
活动图(ActivityDiagram)在UML里,活动图本质上就是流程图,它描述系统的活动,判断点和分支等。
状态图描述一个对象的状态以及状态改变,而活动图除了描述对象状态之外,更突出了它的活动。
一个活动结束自动引发下个活动,则两个活动之间用带箭头的连线连接,连线的箭头指向下一个活动。
本系统用户活动图如下图5.4所示:
否
是
成功
验证失败
显示信息
重登
存在
退出
生成新信息
图5.4用户活动图
3.4用户协作图
协作图是一种交互图,强调的是发送和接收消息的对象之间的组织结构。
一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。
对象通常是命名或匿名的类的实例,也可以代表其他事物的实例,例如协作、组件和节点。
使用协作图来说明系统的动态情况。
显示某组对象如何为了由一个用例描述的一个系统事件而与另一组对象进行协作的交互图。
使用协作图可以显示对象角色之间的关系,协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为。
设计员使用协作图和序列图确定并阐明对象的角色,这些对象执行用例的特定事件流。
它们是主要的信息来源,用于确定类的职责和接口。
协作图的格式决定了它们更适合在分析活动中使用。
它们特别适合用来描述少量对象之间的简单交互。
随着对象和消息数量的增多,理解协作图将越来越困难。
此外,协作图很难显示补充的说明性信息,例如时间、判定点或其他非结构化的信息,而在序列图中这些信息可以方便地添加到注释中。
协作图强调参与一个交互对象的组织,它由以下基本元素组成:
活动者(Actor)、对象(Object)、连接(Link)和消息(Message)。
在UML中,使用实线标记两个对象之间的连接。
本系统的协作图如下图5.5所示:
使用者
验证数据
输入信息
发送请求
返回数值
调用数据
活动类
客户类
数据类
图5.5用户协作图
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 课程设计 学生 信息管理 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)