管理信息系统毕业设计Word下载.docx
《管理信息系统毕业设计Word下载.docx》由会员分享，可在线阅读，更多相关《管理信息系统毕业设计Word下载.docx（45页珍藏版）》请在冰豆网上搜索。
（5）系统管理主要是执行数据库备份和恢复、数据库表的维护等工作，保证系统的正常运行。
学生管理信息系统作为典型的数据库项目应用的一种，其开发流程包括需求分析、UML系统建模、确定系统集成方案、数据库分析和设计以及各功以模块的开发等。
下面介绍一个学生管理信息系统的详细开发过程。
需求分析
需求分析是数据库系统开发的第一步，也是最重要的一步。
需求分析可以分为两个过程：
一是理解需求，二是分析需求。
下面分别分析这两个过程。
理解需求
只有通过对学生管理信息系统的终端用户和客户进行大量的调研，才能真正理解终端用户和客户的需求，才能开发出合理的、实用的管理系统，才能满足各大、中、小学校的管理需要。
基于大量的调研数据，下面列出对最典型、最关键的需求。
（1）每年开学时，新生来报琶，要对每位新生的信息建立个人档案，这部分工作由学籍科的管理人员进行维护和操作。
学生个人档案包括学生学号、姓名、性别、出生日期、所属班级、所属院系、籍贯等。
（2）考试结束时，教务科的管理人员将学生各科的成绩录入数据库，以备随时查询。
当然录入成绩也有出错的可能，所以，必须具有校对修改成绩的功能。
（3）当学生的表现出色或差的时候，学生科的管理人员应对其进行奖励或处罚，相应的奖项（或处罚）和奖励（或处罚）时间的数据都应该入库。
（4）当学生因为疾病、学业修完等原因学籍需要变更的时候，学籍科的管理人员应该对其进行学籍变更手续。
（5）学生应该具有查询个人信息和成绩的权力和权限。
（6）系统还应提供强大的数据统计、查询、报表生成以及打印等功能。
（7）系统客户端运行在Windows平台下，服务器端可以运行在Windows平台或者Unix平台下。
（8）系统应该有很好的可扩展性。
在本系统中主要提供新生信息录入、学籍变更、成绩管理和奖惩管理等相关的功能。
分析需求
分析需求就是描述系统的需求，通过定义系统中的关键域类来建立模型。
分析的根本目的是在开发者和提出需求的人之间建立一种理解和沟通的机制，因此学生管理信息系统的需求分析是开发人员和学校管理人员一起完成的。
分析需求的第一步是描述学生管理信息系统的功能，即定义用例，以此确定系统的功能需求。
一所学校的主要成员就是学生和学校的管理人员、教师、系统管理员等，管理人员主要指学籍科、学生科和教务科的人员，他们是学生管理信息系统的主要使用者。
学生也是学生管理信息系统的重要使用者，只是具备的管理权限没有管理人员那么广。
系统管理员也是其中一个管理人员，这不影响本系统的功能。
学生管理信息系统的用例包括以下内容。
·
新生信息
学生成绩（包括录入和校对）
学籍变更
学生奖励
学生处罚
学生信息查询修改
需要注意的是，学生信息查询修改用例包括学生对个人基本信息和查询和修改，这些信息指的是新生入学时被录入的基本信息。
此外，学生还具有查询和打印成绩的权限，查询奖惩情况、学籍变更记录等权限。
学生管理信息系统的分析可以用UML的用例图来描述。
每个用例还可以以文本的方式描述，描述的内容包括用例以及用例与角色交互的更详细的信息，文本的内容是通过和用户讨论后确定的。
下面给出上述用例的描述。
（1）新世界生信息
增加学生记录→标记学生学号→确定学生院系→确定学生班级
（2）学生成绩
增加学生成绩记录→校对学生成绩
（3）学籍变更
增加学籍变更记录→标记变更原因→标记变更时间
（4）学生奖励
增加学生奖励记录→标记奖励项目→标记奖励时间
（5）学生处罚
增加学生处罚记录→标记处罚等级→标记处罚时间
（6）学生信息查询修改
查询个人信息→修改个人信息→保存个人信息→查询奖惩情况→查询学籍变更情况→打印成绩单
UML系统建模
完成需求分析后，就需要对系统进行UML建模。
UML建模是对需求分析结果的模型建立过程。
下面进行学生管理信息系统的UML建模过程。
学生管理信息系统的用例分析
在上一节需求分析中列出了学生管理信息系统的全部用例：
新生信息、学生成绩、学籍变更、学生奖励、学生处罚、学生信息查询修改。
这里，使用权用Rose软件进行UML建模，其用例如图3所示。
图3学生管理信息系统用例图
该用例图标记了所有的学生管理住处系统的用例，从中可以得知，学生管理信息系统的角色可以划分为两类。
学校管理人员：
用例包括学生管理信息系统的所有用例。
学生：
用例只有学生信息查询修改。
要注意的是，学校管理人员具有查询和修改所有数据的权限，处于高权限位置，而学生只有修改个有基本信息、查询奖惩情况、查询学籍变更情况和打印成绩单的权限，处于低权限位置。
学生管理信息系统的域类分析
UML建模的第二步就是域类分析。
实际开发学生管理信息系统时，域类分析是建立在用例分析基础上的。
要了解系统要处理的概念，最好奖学校的管理人员组织起来开个讨论会，详细谈论和列举所需要包含水量的用例，了解概念和概念之间的关系。
学生管理信息系统中的域主要包括：
学生（Student）、成绩（Score）、学籍变更（Change）、奖励（Encourage）、处罚（Punish）。
可以在类图中将上面这些域以及它们之间的关系表示出来，如图4所示。
图4学生管理信息系统域草图
需要说明的是，这里的域类还是处于“草图”状态，定义的操作和属性不是最后的片本，只是在现阶段看来这些操作和属性是比较合适的，有些操作奖在时序图的草图中定义，而不晨用例哪定义。
有些类可以用UML状态图来显示类的对象的不同状态以及改变状态的事件。
在本系统中有状态图的类是学生，该类的状态图将在后面的内容中介绍。
为了描述域类的动态行为，可以使用权UML的时序图、协作图或者活动图来描述。
本文选用时序图。
时序图的基础是用例。
在时序图中要说明域类是如何协作以操作该系统中的用例。
当然，在建立时序图时，将会发现新的操作，并将其加入类中，这将在后面看到所建立的时序图模型。
用时序图建模时，需要窗口或对话框作为角色界面。
显然，这里需要操作界面的有基本信息、奖励、处罚、学籍变更、修改查询等，此外维护也需要一个操作界面。
学生管理信息系统的设计
在设计阶段，首先要设计类的状态的图。
类的状态图说明了可能的状态以及需要被处理的过渡期，使用状态图可以揭示单个对象在整个系统中的变化细凶，对了解和实现关键类有较大的帮助。
不是所有的类都有状态图，在本系统中，有状态图的类是学生。
学生的状态图如图5所示。
图5学生的状态图
设计阶段的最后一步是设计UML模型，也就是将前面设计的模型进竽扩展和细化。
下面给出各个用例的时序图。
设计的目的是产生一个可以使用的解决方案，并且可以容易地将方案转换成程序代码。
学生的时序如图6所示
图6学生时序图
成绩的时序如图7所示。
图7成绩时序图
学籍变更的时序如图8所示。
图8学籍变更时序图
奖励的时序如图9所示。
图9奖励时序图
处罚的时序如图10所示。
图10处罚时序图
查询修改的时序如图11所示。
图11查询修改时序图
时序图设计完成后，开始进行学生管理信息系统的架构设计和细节设计。
在架构设计中将定义包（子系统）、包间的相关性和基本的通信机制。
设计架构时，应该将应用逻辑和技术逻辑分割。
应用逻辑是需要编码设计的，而技术逻辑，主要包括用户界面、数据库或者通信一般是已经有的。
学生管理信息系统中的包（或者为子系统、层）有如下几个，如图9-12所示。
图9-12包和包间关系
用户界面包（UserInterfacePackage）：
为通用用户界面类，调用业务对象包中的操作检索和插入数据，可以简单地把它们看成将来用户要操作的界面。
业务对象包（BusinessObjectPackage）：
业务对象包包含上面设计的分析模型的域类。
业务对象包同数据库包协同完成任务。
数据库包（DatabasePackage）：
数据库包向业务对象数据包提供服务。
应用包（UtilityPackage）：
应用包向其他包提供服务。
至此，UML系统建模完成。
系统配置
优秀的数据库系统必有一个相对最优的系统配置方案。
系统配置要根据用户的实际情况设计，主要依据就是系统的吞吐量和系统对稳定性的要求，此外，用户的维护水平也是一个重要的方面。
9.4.1软件配置
软件配置主要包括数据库的选择和操作系统的选择。
学生管理信息系统的软件配置要根据用户对系统的稳定性要求、系统的容量以及用户的维护水平来确定。
（1）数据库选择
可以根据数据量的大小选择不同的数据库，如表1所示。
数据量是指数据库中需存放的单表的最大记录数。
表1学生管理信息系统数据库的选择
用户
数据量（记录表）
稳定性要求
维护水平
备选数据库
社区小学
100~500
低
差
Access、Foxpro
公立小学或社区小学
500~5000
公立中学或社区大学
5000~50000
中
一般
SQLServer
专业型大学
50000~200000
较高
较好
SQLServer、Oracle
综合型大学
200000
高
好
Oracle
在本系统中，选择Access2000数据库。
（2）操作系统选择
可以根据用户量的大小选择不同的操作系统。
操作系统的选择如表2所示。
表2学生理管信息系统操作系统的选择
每秒数据库并发
数据访问记录数
稳定性
要求
维护
水平
备选操作系统
10~50
Windows2000Professional
公立小学或社区中学
50~500
WindowsNT
Windows2000Server
500~2000
Windows2000Server
Linux、UNIX
专业型大
升级会员 