软件工程课程设计
-----学生信息管理系统
学院：计算机科学与技术学院
专业：
姓名：
学号
指导老师：
目录
一、学生管理系统需求分析
1.2.1系统任务概述 (3)
1.2.2 功能需求 (3)
1.2.3数据流图 (4)
1.2.4数据字典 (7)
1.2.5 E-R图 (7)
1.2.6性能要求 (8)
1.2.7运行环境 (8)
二、概要设计
2.1 设计思想 (9)
2.2 功能需求 (9)
2.3 性能需求 (10)
2.4 系统框架 (10)
2.4.1 系统流程分析 (10)
2.4.2 系统功能模块分析 (11)
三、系统详细设计
3.1 管理员用例图 (13)
3.2 用户状态图 (14)
3.3 用户活动图 (15)
3.4用户协作图 (15)
一、学生管理系统需求分析
1.2.1系统任务概述
学生信息管理系统是针对学校人事处的大量业务处理工作而开发的管
理软件，主要用于学校学生信息管理，总体任务是实现学生信息关系的系统化、科学化、规范化和自动化，其主要任务是用计算机对学生各种信息进行日常管理，如查询、修改、增加、删除，另外还考虑到学生选课，针对这些要求设计了学生信息管理系统。推行学校信息管理系统的应用是进一步推进学生学籍管理规范化、电子化、控制辍学和提高义务教育水平的重要举措。
在以前，学校处理学生学籍档案等信息，需要人工收集数据信息，填写表格等，然后加以保存。但是，长此以往，随着学生人数不断地增加，学生信息量比较大，学校对于学生信息的保存等更加困难。这就使得必须有一种简洁快速的方法，方便学生信息的存储和调用。学生管理系统就此应运而生。
由此可以看出，人工操作效率太慢，而且容易出错。更加浪费时间。因此，利用计算机来处理这些流程无疑会极大程度地提高效率和处理能力。学生信息的录入，调用和查看更加方便，快捷。而且，各种流程出错率大大降低。由此，计算机对于人工的优势显而易见。
1.2.2功能需求
学生管理系统的目的是实现学生信息录入、查看、调用等业务的自动化管理，以提高工作效率。
学生信息管理系统主要包括以下几个功能模块：
1. 学生信息管理：有关学籍等信息的录入、查询和修改，包括学生基本信息，所在学院，专业班级等。
2. 课程信息管理：学生已学课程和正在学习课程。
3. 成绩信息管理：学生课程成绩查询。
4. 学生选课管理：学生选课系统。
5. 任课老师查询：查询正在学习课程的老师信息。
系统功能模块：
学生登录
基本信息查询修改密码
修改基本信息
注销
任课老师查询
学生成绩查询
1.2.3数据流图
学生信息管理系统
学生
登陆
学生信息
学生成绩
任课老师
查询 查询
查询
查询 修改
顶层数据流层图
对顶层数据流图进行分解，分离出两个加工：读者要求处理和管理员要求处理，分别编号为1和2.由于加工分离出来，原先属于内部数据流（文件）的部分（如期刊目录文件、期刊登记文件和期刊内容文件）这里就变成了外部数据流，它们被标在第二层数据流图上，“读者要求处理”加工分别从期刊内容文件、期刊登记文件和期刊目录文件读数据，“管理员要求处理”加工不仅从期刊目录文件读数据，当数据处理完成后，还要向期刊目录文件写入数据。分解后的第二层数据流图如图1-5所示。
读者
管理员
1读者要求处理2管理员要求处理
期刊目录文件
期刊登记文件
处理结果
管理员要求读者要求期刊订单
期刊内容文件
图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.1读者分类要求1。5查询要求处理
1.2变动处理
1.3借阅处理1.4归还处理
变动要求
借
阅
要
求
归
还
要
求
读者查询要求
期刊目录文件
期刊借阅文件
职工文件
期刊目录文件
用户文件
期刊借阅文
件
期刊借阅文件
管理员要求
2.3期刊征订2.2期刊登记
2.1管理要求分类
管理员要
求
期刊
登记
征订
征订
单
期刊登记文
件
期刊内
容文件
期刊目录文
件
图1-6第三层数据流图
1.5.1查询要求分类 1.5.2查询期刊去向
1.5.3查询期刊内容读者
查询期刊去向要
求
按
关
键
词
查
询
要
求
期刊内容
信息
期
刊
去
向
信
息
用户文件
期刊借阅文件期刊内容
期刊登记文件
期刊目录文件
图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 为Pentium II 300或更高配置，内存128MB 以上，硬盘至少为500MB ，网络适配器10Mbps 或更快的网卡，一个CD-ROM 驱动器，打印机一台，UPS （选
学生
性别
姓名 民族
籍贯
入校日期
学院
专业
学号
选课
成绩
课程
上课时间
课程类别
授课教师
课程名
课程号
配），客户机CPU为Pentium 200或更高配置，内存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 用户活动图
活动图(Activity Diagram) 在UML 里，活动图本质上就是流程图，它描述系统的活动，判断点和分支等。状态图描述一个对象的状态 以及状态改变，而活动图除了描述对象状态之外，更突出了它的活动。一个活动结束自动引发下个活动，则两个活动之间用 带箭头的连线连接，连线的箭头指向下一个活动。本系统用户活动图如下图5.4所示：
登录 状态=成功
提交 状态=成功
查询信息 状态=登录 增删改查 状态=成功 更新 状态=成功 登录请求 状态=未登录
填写账号密码 状态=填写
图5.4 用户活动图
3.4用户协作图
协作图是一种交互图，强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。显示某组对象如何为了由一个用例描述的一个系统事件而与另一组对象进行协作的交互图。使用协作图可以显示对象角色之间的关系，协作图用于显示对象之间如何进行交互以执行特定用例或用例中特定部分的行为。设计员使用协作图和序列图确定并阐明对象的角色，这些对象执行用例的特定事件流。它们是主要的信息来源，用于确定类的职责和接口。
协作图的格式决定了它们更适合在分析活动中使用。它们特别适合用来描述少量对象之间的简单交互。随着对象和消息数量的增多，理解协作图将越来越困难。此外，协作图很难显示补充的说明性信息，例如时间、判定点或其他非结构化的信息，而在序列图中这些信息可以方便地添加到注释中。
协作图强调参与一个交互对象的组织，它由以下基本元素组成：活动者（Actor ）、对象（Object ）、连接（Link ）和消息（Message ）。在UML 中，使用实线标记两个对象之间的连接。本系统的协作图如下图5.5所示：
否
是
成功
验证失败
登录
显示信息
重登
查询信息
存在
更新
退出
生成新信息
图5.5 用户协作图
使用者
验证数据
输入信息
发送请求
返回数值
调用数据
活动类
客户类
数据类