学生信息管理系统Word格式文档下载.docx
《学生信息管理系统Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《学生信息管理系统Word格式文档下载.docx（14页珍藏版）》请在冰豆网上搜索。
转系、休学、复学、退学和毕业离校。
（3）成绩管理是数据量比较大的管理工作，每次考试结束后负责对学生各个科目的成绩入库工作和对数据库成绩出错的校对工作。
（4）奖惩管理是针对学生在校的表现情况，对学生进行相应的处理工作，奖励的项目有各种奖学金和文体奖励，处罚的项目有通报批评、警告、严重警告、记过、留校查看、开除等。
（5）系统管理主要是执行数据库备份和恢复、数据库表的维护等工作，保证系统的正常运行。
学生管理信息系统作为典型的数据库项目应用的一种，其开发流程包括需求分析、UML系统建模、确定系统集成方案、数据库分析和设计以及各功以模块的开发等。
下面介绍一个学生管理信息系统的详细开发过程。
2需求分析
需求分析是数据库系统开发的第一步，也是最重要的一步。
需求分析可以分为两个过程：
一是理解需求，二是分析需求。
下面分别分析这两个过程。
2.1理解需求
只有通过对学生管理信息系统的终端用户和客户进行大量的调研，才能真正理解终端用户和客户的需求，才能开发出合理的、实用的管理系统，才能满足各大、中、小学校的管理需要。
基于大量的调研数据，下面列出对最典型、最关键的需求。
（1）每年开学时，新生来报琶，要对每位新生的信息建立个人档案，这部分工作由学籍科的管理人员进行维护和操作。
学生个人档案包括学生学号、姓名、性别、出生日期、所属班级、所属院系、籍贯等。
（2）考试结束时，教务科的管理人员将学生各科的成绩录入数据库，以备随时查询。
当然录入成绩也有出错的可能，所以，必须具有校对修改成绩的功能。
（3）当学生的表现出色或差的时候，学生科的管理人员应对其进行奖励或处罚，相应的奖项（或处罚）和奖励（或处罚）时间的数据都应该入库。
（4）当学生因为疾病、学业修完等原因学籍需要变更的时候，学籍科的管理人员应该对其进行学籍变更手续。
（5）学生应该具有查询个人信息和成绩的权力和权限。
（6）系统还应提供强大的数据统计、查询、报表生成以及打印等功能。
（7）系统客户端运行在Windows平台下，服务器端可以运行在Windows平台或者Unix平台下。
（8）系统应该有很好的可扩展性。
在本系统中主要提供新生信息录入、学籍变更、成绩管理和奖惩管理等相关的功能。
2.2分析需求
分析需求就是描述系统的需求，通过定义系统中的关键域类来建立模型。
分析的根本目的是在开发者和提出需求的人之间建立一种理解和沟通的机制，因此学生管理信息系统的需求分析是开发人员和学校管理人员一起完成的。
分析需求的第一步是描述学生管理信息系统的功能，即定义用例，以此确定系统的功能需求。
一所学校的主要成员就是学生和学校的管理人员、教师、系统管理员等，管理人员主要指学籍科、学生科和教务科的人员，他们是学生管理信息系统的主要使用者。
学生也是学生管理信息系统的重要使用者，只是具备的管理权限没有管理人员那么广。
系统管理员也是其中一个管理人员，这不影响本系统的功能。
学生管理信息系统的用例包括以下内容。
•新生信息
•学生成绩（包括录入和校对）
•学籍变更
•学生奖励
•学生处罚
•学生信息查询修改
需要注意的是，学生信息查询修改用例包括学生对个人基本信息和查询和修改，这些信息指的是新生入学时被录入的基本信息。
此外，学生还具有查询和打印成绩的权限，查询奖惩情况、学籍变更记录等权限。
学生管理信息系统的分析可以用UML的用例图来描述。
每个用例还可以以文本的方式描述，描述的内容包括用例以及用例与角色交互的更详细的信息，文本的内容是通过和用户讨论后确定的。
下面给出上述用例的描述。
（1）新世界生信息
增加学生记录→标记学生学号→确定学生院系→确定学生班级
（2）学生成绩
增加学生成绩记录→校对学生成绩
（3）学籍变更
增加学籍变更记录→标记变更原因→标记变更时间
（4）学生奖励
增加学生奖励记录→标记奖励项目→标记奖励时间
（5）学生处罚
增加学生处罚记录→标记处罚等级→标记处罚时间
（6）学生信息查询修改
查询个人信息→修改个人信息→保存个人信息→查询奖惩情况→查询学籍变更情况→打印成绩单
3UML系统建模
完成需求分析后，就需要对系统进行UML建模。
UML建模是对需求分析结果的模型建立过程。
下面进行学生管理信息系统的UML建模过程。
3.1学生管理信息系统的用例分析
在上一节需求分析中列出了学生管理信息系统的全部用例：
新生信息、学生成绩、学籍变更、学生奖励、学生处罚、学生信息查询修改。
这里，使用权用Rose软件进行UML建模，其用例如图3所示。
该用例图标记了所有的学生管理住处系统的用例，从中可以得知，学生管理信息系统的角色可以划分为两类。
•学校管理人员：
用例包括学生管理信息系统的所有用例。
•学生：
用例只有学生信息查询修改。
要注意的是，学校管理人员具有查询和修改所有数据的权限，处于高权限位置，而学生只有修改个有基本信息、查询奖惩情况、查询学籍变更情况和打印成绩单的权限，处于低权限位置。
9.3.2学生管理信息系统的域类分析
UML建模的第二步就是域类分析。
实际开发学生管理信息系统时，域类分析是建立在用例分析基础上的。
要了解系统要处理的概念，最好奖学校的管理人员组织起来开个讨论会，详细谈论和列举所需要包含水量的用例，了解概念和概念之间的关系。
学生管理信息系统中的域主要包括：
学生（Student）、成绩（Score）、学籍变更（Change）、奖励（Encourage）、处罚（Punish）。
可以在类图中将上面这些域以及它们之间的关系表示出来，如图4所示。
需要说明的是，这里的域类还是处于“草图”状态，定义的操作和属性不是最后的片本，只是在现阶段看来这些操作和属性是比较合适的，有些操作奖在时序图的草图中定义，而不晨用例哪定义。
有些类可以用UML状态图来显示类的对象的不同状态以及改变状态的事件。
在本系统中有状态图的类是学生，该类的状态图将在后面的内容中介绍。
为了描述域类的动态行为，可以使用权UML的时序图、协作图或者活动图来描述。
本文选用时序图。
时序图的基础是用例。
在时序图中要说明域类是如何协作以操作该系统中的用例。
当然，在建立时序图时，将会发现新的操作，并将其加入类中，这将在后面看到所建立的时序图模型。
用时序图建模时，需要窗口或对话框作为角色界面。
显然，这里需要操作界面的有基本信息、奖励、处罚、学籍变更、修改查询等，此外维护也需要一个操作界面。
3.3学生管理信息系统的设计
在设计阶段，首先要设计类的状态的图。
类的状态图说明了可能的状态以及需要被处理的过渡期，使用状态图可以揭示单个对象在整个系统中的变化细凶，对了解和实现关键类有较大的帮助。
不是所有的类都有状态图，在本系统中，有状态图的类是学生。
...............................
**************************毕业设计文件**************************
D0007Delphi学生信息管理系统毕业设计（含毕业论文、程序源码）（1folders,2files,19.86MB,24.50MBintotal.）
│ │ 复件论文20080227.doc9.90MB
│ │ 论文20080227.doc9.97MB
│ └─源代码（2folders,2files,1.86MB,4.63MBintotal.）
│ │ Readme.doc1.86MB
│ │ readme.txt76bytes
│ ├─DataBase（0folders,1files,272.00KB,272.00KBintotal.）
│ │ Stu.mdb272.00KB
│ └─Stu（2folders,28files,2.23MB,2.51MBintotal.）
│ │ 0.BMP5.60KB
│ │ 1.BMP5.60KB
│ │ 2.BMP5.60KB
│ │ 3.BMP5.60KB
│ │ 4.BMP5.60KB
│ │ 5.BMP5.60KB
│ │ 6.BMP5.60KB
│ │ 7.BMP5.60KB
│ │ Admini.cfg8bytes
│ │ Login.dcu5.76KB
│ │ Login.ddp51bytes
│ │ Login.dfm1.41KB
│ │ Login.pas2.41KB
│ │ Stu.mdb276.00KB
│ │ student.cfg8bytes
│ │ Student.dcu28.41KB
│ │ Student.ddp51bytes
│ │ Student.dfm66.94KB
│ │ student.mdb276.00KB
│ │ Student.pas19.06KB
│ │ Student.~ddp51bytes
│ │ Student.~dfm66.96KB
│ │ Student.~pas19.06KB
│ │ StuMain.cfg434bytes
│ │ StuMain.dof1.97KB
│ │ StuMain.dpr290bytes
│ │ StuMain.exe1.44MB学习是成就事业的基石
│ │ StuMain.res876bytes
│ ├─DataBase（0folders,1files,276.00KB,276.00KBintotal.）
│ │ Stu.mdb276.00KB
│ └─ReportPages（0folders,1files,4.53KB,4.53KBintotal.）
│ StuInfo.rav4.53KB
升级会员 