高校奖学金评定系统.docx
《高校奖学金评定系统.docx》由会员分享，可在线阅读，更多相关《高校奖学金评定系统.docx（25页珍藏版）》请在冰豆网上搜索。
高校奖学金评定系统
课程设计报告
学生姓名:
学号：
学院:
班级:
题目:
高校奖学金评定系统
指导教师：
职称:
2011年7月15日
目录
1.选题背景1
2.高校奖学金评定系统需求分析2
2.1高校奖学金评定系统的需求陈述2
2.2需求分析2
2.2.1功能需求2
2.2.2性能需求3
2.3.3系统用例建模5
2.3.4用例描述6
3.高校奖学金评定系统系统分析10
3.1系统用例建模10
3.2静态结构模型11
3.2.1 类的识别12
3.2.2类的关联分析12
3.2.3类的属性描述13
3.2.4类图的构建13
3.3系统动态模型14
3.3.1系统执行顺序分析14
3.3.2系统的协作分析17
3.3.3系统状态分析19
3.3.4系统活动分析20
4.高校奖学金评定管理系统系统设计与实现22
4.1UML体系结构设计22
4.1.1硬件体系结构设计22
4.1.2软件体系结构设计22
4.2对象模型设计23
4.3系统实现24
4.3.1组件分析24
4.3.2配置分析25
5.课程设计心得体会26
参考文献27
1.选题背景
随着快速发展和不断扩建，目前在学生的教务管理上，学分制管理已取代了过去的学年制管理。
学生数量也逐年增加，给院系的学生管理工作带来了沉重的压力，原先基于文档的管理工作模式已经适应不了这种负担，且极其容易产生错误如信息的不一致性等，而且降低了信息的交换速度，降低了整个学生管理工作的效率。
在高校学生管理部门的日常工作中，奖学金评定是一项繁琐而又重要的工作，而且是每年必须重复的工作。
奖学金的评定,一方面要根据学生各个科目的学习成绩，同时还要结合每每位学生的具体表现和实际情况，包括学生的德育、体育及某方面的突出表现等，对于不同学生给与不同项目的奖学金，涉及的范围很广，需要纪录和处理的数据也很庞大，由此看来要根据不同情况评定出不同的奖学金获得者并不是一件容易的事情。
原先的奖学金手工评审方法已不能满足现在的需求，使用以前的评定方法不但增加了用户的工作量，更主要的是在执行中会有一些不良因素来影响结果的可靠性，因此实现奖学金管理的信息化是十分必要的。
并且，当前，很多高校应用的奖学金评定系统仍存在着许多缺点,如:
技术水平低、保密性差。
要想使学生奖学金信息管理的方式具有以往管理方式所无法比拟的优势，如：
检索迅速、查找方便、可靠性高、存储量大、保密性好等，开发新的学生奖学金管理信息系统就是非常必要的。
这将极大地提高高校学生成绩管理的效率,也是高校实现管理现代化的重要条件。
2.高校奖学金评定系统需求分析
2.1高校奖学金评定系统的需求陈述
某高校拟建一个奖学金评定系统，该系统需求陈述如下：
在奖学金评定系统中，学生在进入学校时申请用户，登录密码，建立学生档案，并按时上课参与考试和学校及学院组织的各项课外活动，根据自己的学习成绩和活动成绩，查询自己是否获得奖学金。
如果有机会获得奖学金，要进行信息的反馈，并将反馈的信息及时的上报。
教务处要为每一位学生建立学生信息档案，并计划每个学生好每学期的课程安排，并下发到各个学院里。
更新学生一学期的上课考试相关信息，及时更新学生档案。
教学干事和学办则安排任课教师及上课地点，并及时更新相关信息。
教学干事记录教学过程，并且安排课程考试，记录学生成绩，提供相关数据进行奖学金评定。
学办根据教务处提供的课程安排记录相关信息，并组织学生参加课外活动，记录参加活动学生的信息。
根据各部门提供的成绩信息及奖学金评定系数，综合学生信息交与学工部。
学工部根据各部门的综合信息确定奖学金获得者名单，回馈给各学办及教务处，并下发到每个学生手中。
申请奖学金金额，按名次并发放到获奖者手中。
2.2需求分析
2.2.1功能需求
本系统是基于高校学生奖学金评定的系统，该系统主要包括成绩管理模块、活动管理模块、课程管理模块和奖学金评定模块。
这几个个模块既相互联系又相互独立的.
1．成绩管理：
根据每一个学期每个带课老师提供的成绩单，对每个学生的成绩进行录入，并且根据学期、系部、专业、班级、学号来查询个人的成绩等并且可以在此基础上根据相应的规则计算出平均成绩，综合成绩等并按照一定的要求排序，最终可以形成需要的各种报表打印出来。
2．活动管理：
根据每一个学期学院对学生参加各类活动情况的统计，对每个学生的活动进行录入，并且根据学期、系部、专业、班级、学号来查询个人参加活动的情况等并且可以在此基础上根据相应的规则计算出活动得分，以分类得分的方式加入到综合成绩，最终可以形成需要的各种报表打印出来。
3．课程管理：
根据学校制定的相关专业教学培养计划，对学生所必修和选修课程的名称、学期、学分加以统计。
4．奖学金评定管理：
根据学校学生管理规定奖学金评定细则的要求，将评定奖学金所需的各项成绩加以汇总，并按照要求对同一年级同同专业学生的成绩进行排序，并评出学生所获得奖学金等级。
2.2.2性能需求
1.时间响应特性
查询服务部分：
用户通过电脑提交查询命令到返回结果不超过5秒钟。
数据管理部分：
提交某一数据录入到结果返回不超过5秒钟。
2.数据量大
系统要记录每个学生成绩和活动的记录，因此，整个系统对信息量的要求相对较高，开发者应采取相应措施，解决存储量大的问题，同时还要兼顾信息的方便利用。
3.系统实用性：
为了提高系统效率，系统提供了多种形式的对话框，并在设计过程中考虑尽量减少用户的输入。
4.安全可靠性
本系统运行在Internet上，前端通过windows的浏览器进行使用，要考虑可能会受到外来的安全威胁；操作员口令应采用加密存放方式，不同权限的用户对数据有不同层次的访问；要适当的对系统数据进行备份存档，避免数据的丢失带来不便。
5.环境规定
（1）硬件环境
服务器端为一台标准服务器。
客户端包括多媒体电脑、PC客户机等。
（2）软件环境
学生网上选课系统的设计与运行基于采用C/S结构。
后台操作系统为MicrosoftWindowsXP，数据库为MicrosoftSQLServer2000；浏览器为IE6.0以上版本。
2.3.1确定参与者
参与者是指与系统交互的人或其他系统，它代表外部实体。
使用用例并且与系统交互的任何人或物都是参与者。
通过对系统的分析，得到该系统有以下几个参与者：
（1）教务处:
制定教学计划，安排教学任务，记录更新学生信息。
（2）教学干事：
安排教学任务，安排学生考试，记录学生成绩信息。
（3）学办：
组织学生课外活动，并记录活动信息，和学生进行信息反馈。
（4）学生：
参加学生考试以及课外活动，查询综合学生信息，获得奖学金。
（5）学工部：
综合学生信息，发放奖学金等。
2.3.2确定用例
一个用例是可以被参与者感受的、系统的一个完整的功能。
用例通过关联与参与者连接，关联指出一个用例与哪些参与者交互，这种交互是双向的。
通过以上的分析得到该系统的用例如下：
1.成绩管理
概述：
该用例可以录入、删除、修改和保存学生成绩。
前置条件：
系统中已经存入学生的基本信息
后置条件：
系统记录学生成绩并保存，并且形成相应报表给学办及教务处。
实现过程：
（1）.学生参加考试，得出成绩。
（2）.系统对学生成绩进行录入，并进行核查，如有错误则进行修改，并将原来错误信息删除，保留最终信息。
（3）.生成报表，交与学办和教务处
在上面的实现过程中，学生成绩信息已经录入完成，等奖学金评定时可以直接查询使用。
2.课程管理
概述：
该用例提供学生学习的课程名称、学分等信息，为奖学金评定提供必要数据。
前置条件：
教务处已经安排教学计划，各部门也进行相应的管理。
后置条件：
课程开始后，要不断收集和反馈学生教师上课信息，并及时进行教学计划的修改和更新
活动基本过程：
（1）安排教学计划
（2）增删改课程
（3）制定奖学金评定系数
（4）进行信息反馈和修改
3.活动管理
概述：
该用例提供学生参加课外活动的信息，从侧面体现学生的综合能力。
前置条件：
学办已经计划组织相应的课外活动。
后置条件：
学生参加完活动，要进行信息的详细记录。
活动基本过程：
（1）学办组织学生课外活动
（2）学生参见完，要进行信息的详细记录
（3）综合成绩信息，进行奖学金评定
（4）进行信息反馈和修改
4.奖学金评定
概述：
该用例综合各部门反应的信息评定出奖学金，并发放给获得者。
前置条件：
各部门已将相关信息综合报到学工部。
后置条件：
确定获奖者名单后，进行核对与奖学金的发放。
活动基本过程：
（1）综合信息，评定奖学金。
（2）进行核对及信息反馈
（3）发放奖学金
5.查询
概述：
该用例可以进行成绩查询及奖学金获得情况的查询。
前置条件：
系统数据库中已存入相关信息。
后置条件：
保存信息，并生成报表。
实现过程（事件流）：
（1）.学生登录自己的账户，输入密码。
（2）.密码正确，则可以查询信息。
（3）.可以打印信息报表。
2.3.3系统用例建模
在构造系统的过程中，几乎任何情况下都需要使用用例，通过用例可以获取用户需求，规划和控制项目。
获取用例是需求分析阶段的主要任务之一，而且是首先要做的工作。
大部分用例将在项目的需求分析阶段产生，并且随着开发工作的深入还会发现更多用例，这些新发现的用例都应该及时补充进已有的用例集中。
用例集中的每一个用例都是对系统的一个潜在的需求。
一个用例模型由若干幅用例图组成。
创建用例模型的工作包括：
定义系统，寻找行为者和用例，描述用例，定义用力之间的关系，确认模型。
根据以上分析结果得到以下用例模型
1.奖学金评定系统顶层图
图2-1奖学金评定系统顶层用例图
2.奖学金评定系统一级用例图
图2-2奖学金评定系统用例图
2.3.4用例描述
1.成绩管理
成绩管理用例描述如表2-1
表2-1成绩管理用例描述
用例名称：
成绩管理
用例标识号：
1
参与者：
教学干事
简要说明：
教学干事可以进行学生成绩的录入、保存等
前置条件：
系统中已经存入学生的基本信息
基本事件流：
（1）.学生参加考试，得出成绩。
（2）.系统对学生成绩进行录入，并进行核查，如有错误则进行修改，并将原来错误信息删除，保留最终信息。
（3）.生成报表，交与学办和教务处
其他事件流A1：
在按“提交”按钮之前，教学干事随时可以按“返回”按钮，返回到浏览页面
异常事件流：
后置条件：
系统记录学生成绩并保存，并且形成相应报表给学办及教务处。
注释：
无
2．查询
查询用例如表描述2-2
表2-2查询用例描述
用例名称：
查询
用例标识号：
2
参与者：
学生
简要说明：
学生通过该用例可以查询奖学金信息。
前置条件：
系统数据库中已存入相关信息。
基本事件流：
（1）.学生登录自己的账户，输入密码。
（2）.密码正确，则可以查询信息。
（3）.可以打印信息报表。
其他事件流A1：
突发性终止，或者学生点击返回，返回到主页
异常事件流：
1．提示错误信息用户确认
2．返回主页
后置条件：
保存信息，并生成报表。
注释：
无
3．课程管理
课程管理用例描述如表2-3
表2-3课程管理用例描述
用例名称：
课程管理
用例标识号：
3
参与者：
教务处
简要说明：
教务处安排教学计划，建立学生信息档案。
前置条件：
教务处已经安排教学计划，各部门也进行相应的管理。
基本事件流：
（1）安排教学计划
（2）增删改课程
（3）制定奖学金评定系数
（4）进行信息反馈和修改
其他事件流A1：
无
异常事件流：
1．提示错误信息教务处确认
2．返回主页
后置条件：
课程开始后，要不断收集和反馈学生教师上课信息，并及时进行教学计划的修改和更新
注释：
无
4.活动管理
活动管理用例描述如表2-4
表2-4活动管理用例描述
用例名称：
活动管理
用例标识号：
4
参与者：
学办
简要说明：
学办组织学生活动，并记录活动信息。
前置条件：
学办已经计划组织相应的课外活动。
基本事件流：
（1）学办组织学生课外活动
（2）学生参见完，要进行信息的详细记录
（3）综合成绩信息，进行奖学金评定
（4）进行信息反馈和修改
其他事件流A1：
无
异常事件流：
后置条件：
学生参加完活动，要进行信息的详细记录。
注释：
无
5.奖学金评定
奖学金评定用例描述如表2-5
表2-5奖学金评定用例描述
用例名称：
奖学金评定
用例标识号：
5
参与者：
学工部
简要说明：
学工部根据各部门反映的信息评定奖学金。
前置条件：
各部门已将相关信息综合报到学工部。
基本事件流：
（1）综合信息，评定奖学金。
（2）进行核对及信息反馈
（3）发放奖学金
其他事件流A1：
无
异常事件流：
后置条件：
确定获奖者名单后，进行核对与奖学金的发放。
注释：
无
3.高校奖学金评定系统系统分析
3.1系统用例建模
在需求分析中，我们已经确定了系统主要用例，以下是对与奖学金评定管理相关的用例的细化，得到以下几个细化图。
1.成绩管理用例模型
图3-1成绩管理用例图
2.课程管理用例模型
图3-2课程管理用例图
3.活动管理用例模型
图3-3活动管理用例
4.查询用例模型
图3-4查询用例图
3.2静态结构模型
3.2.1 类的识别
1．找出候选的类与对象
根据第一章中给出的需求陈述，从陈述中找出下列名词，可以把它们作为类与对象的初步的候选者：
教务处，学生，学生档案，学习成绩，综合成绩，活动成绩，用户，密码，学校，教师，上课地点，学工部，学办，教学干事，奖学金信息。
通常，在需求陈述中不会一个不漏地写出问题域中的所有有关的类与对象，因此，分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。
2．筛选出正确的类与对象
通过一个简单、机械的过程不可能正确地完成分析工作。
非正式分析仅仅帮助人们找到一些候选的类与对象，接下来应该严格考察每个候选对象，从中去掉那些不必要的，仅仅保留确实应该记录其信息或需要其提供服务的那些对象。
筛选时主要依据下列标准，删除不正确或不必要的类与对象。
（1）冗余
如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。
在该系统的类的候选对象中，其中“综合成绩”与“活动成绩”、“学习成绩”分别描述了相同的两类信息，因此仅保留“综合成绩”这个类。
（2）无关
现实世界中存在许多对象，不能够把它们都纳入到系统中去，仅需要把与问题密切相关的类与对象放进目标系统中。
因此，应该去掉候选类中的“上课地点”。
（3）笼统
在需求陈述中常常使用一些笼统的、泛指的名词，虽然在初步分析中把它们作为候选的类与对象列了出来，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此通常把这些笼统的或模糊地类去掉。
在该系统中就出现了一些笼统含糊的名词。
总之在本例中应该去掉“登录”等候选类。
（4）属性
在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。
该系统中的“登录密码”应作为属性对待。
综上所述，在成绩管理系统中，进过初步筛选，剩下的类与对象包括教学干事，学工部，学生，学办，教务处，奖学金信息，综合成绩信息。
3.2.2类的关联分析
多数人习惯于在初步分析确定了问题域中的类与对象之后，接下来就分析确定类与对象之间存在的关联关系。
当然这样的工作顺序并不是绝对必要的。
由于在整个开发过程中面向对象概念和表示符号的一致性，分析员在选取自己习惯的工作方式时拥有相当大的灵活性。
在需求陈述中使用的描述性动词或者动词词组，通常表示关联关系。
因此，在初步确定关联时，大多数关联可以通过提取需求陈述中的动词词组而得出。
通过分析需求陈述，还能发现一些隐含的关联。
（1）可以通过分析用例图确定类及其关联。
通过用例图分析，可以确定奖学金信息和综合成绩信息两个类。
（2）通过用例图中的参与者名称，可以确定学生，学工部，教学干事，教务处，学办两个附加类。
（3）创建类之间的关联：
1学办统计综合成绩信息
2教学干事提供综合成绩信息
3学工部提供奖学金信息
4教务处保留综合成绩信息和奖学金信息
5学生查询信息
3.2.3类的属性描述
属性是对象的性质，通过对象类和结构有更深入，更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关，也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性，以后在逐渐把其余属性添加进去。
此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下：
（1）学生类，它的属性很多，包括学号，姓名，班级，成绩等
（2）奖学金类，属性包括奖学金金额，名次，获奖者姓名等。
（3）综合信息类，属性包括学生学习成绩，课程名称，学分，活动成绩等。
3.2.4类图的构建
系统类图如图3-5所示，
图3-5系统类图
3.3系统动态模型
3.3.1系统执行顺序分析
顺序图是显示对象之间交互的图，这些对象是按时间顺序排列的。
顺序图建模元素有对象（参与者的实例也是对象）、生命线（lifeline）、控制焦点（focusofcontrol）、消息（message）等。
根据以上分析得出该系统的以下几个顺序图。
1.根据对奖学金评定用例的分析，实现奖学金评定有以下说明：
（1）学办输入用户名和密码
（2）如果信息有误，要重新输入用户名和密码
（3）学办要统计学生信息
（4）根据奖学金计算函数计算出分数
（5）系统更新奖学金信息
（6）显示奖学金信息
（7）打印学生综合成绩
（8）生成奖学金报表
奖学金评定用例额顺序图如图3-6所示，
图3-6奖学金评定顺序图
2.用户登录顺序图,有以下说明：
（1）用户输入用户名和密码
（2）验证用户名和密码
（3）系统返还错误信息
（4）重新输入用户名和密码
（5）验证用户名和密码
（6）登陆成功
用户登录书序图如图3-7所示，
图3-7登录顺序图
3.查询顺序图，有以下说明：
（1）学生输入学号进入登陆界面
（2）系统显示登陆成功
（3）学生输入学生号
（4）系统统计信息
（5）系统返回到查询信息
查询顺序图如图3-8所示，
图3-8查询顺序图
3.3.2系统的协作分析
在系统的协作分析中，我们主要通过协作图来对系统进行分析。
协作图描述的是和对象结构相关的信息。
协作图对交互中有意义的对象和对象之间的链建模。
与顺序图一样，协作图也展示对象之间的交互关系。
它绘制出对象与对象之间的消息连接。
在UML中，协作图用几何排列来表示交互作用中的对象和链。
1.奖学金评定合作图
图3-9奖学金评定合作图
2.用户登录合作图
图3-10登录合作图
查询合作图
图3-11查询合作图
3.3.3系统状态分析
顺序图和协作图都属于交互图，主要用来描述系统对象之间的动态协作关系，以及写作过程中的行为次序。
交互图常用来描述一个用例中的几个对象协作工作的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况，但是并不对这些对象的行为，就应该使用状态图。
系统状态图说明：
学办首先查询学生成绩，学出成绩合格者，不合格者就退出评定，结束评定；合格者则进行成绩活动的统计，综合学生成绩信息，核对信息，如有错误则要进行信息反馈，继续统计；如果无误，则确定获奖者，并下达通知，发放奖学金，结束评定。
图3-12系统状态图
3.3.4系统活动分析
活动图描述的是某流程中的任务的执行，活动图描述活动是如何协同工作的，当一个操作必须完成一系列事情，而又无法确定以什么样的顺序来完成这些事情时，活动图可以更清晰地描述这些事情。
用户首先要注册成为学生或管理员，以便进行接下来的操作，注册信息将直接记入到数据库中予以保存。
图3-13系统注册活动图
4.高校奖学金评定管理系统系统设计与实现
4.1UML体系结构设计
4.1.1硬件体系结构设计
（1）该系统使用的硬件设备有：
利用一台高性能计算机作为网络数据库服务器，两台计算机作为终端机。
数据库服务器与终端机采用internet方式连接。
数据库服务器，终端与工作站采用Internet方式连接。
（2）连接：
数据库服务器与终端机采用Internet方式连接，数据库服务器，终端与工作站采用Internet方式连接。
该系统的硬件体系结构如下，
图4-1硬件配置图
4.1.2软件体系结构设计
包图描述系统整体体系结构，奖学金评定系统由成绩管理子系统，活动管理子系统，课程管理子系统，评定系统组成。
图4-2系统包图
4.2对象模型设计
面向对象分析的首要任务就是建立对象模型。
对问题的陈述，文字形式的或图形形式的需求陈述是建立对象模型的主要信息来源，另外涉及的相关应用领域的专业知识也很重要。
本系统根据对象模型设计原则，设计优化和结构求精的启发规则。
具有将分析模型转变为设计模型的机制。
建立了成绩管理、课程管理等系统模块，同时建立了教务处、学生、学工部、学办、教学干事等对象模型。
在教务处这个对象中，教务处根据教学计划，安排课程。
在学生这个对象中，学生运用登陆功能，查询信息。
在学工部这个对象中，综合学生信息，确定奖学金获得者。
在学办这个对象中，学办组织并记录学生参加活动的信息，综合学生信息。
在教务干事这个对象中，记录学生成绩信息。
经分析，该系统的对象模型如图4-3所示。
图4-3系统对象模型
4.3系统实现
4.3.1组件分析
构件图描述构件及其之间的相互依赖，构件是逻辑体系结构（类、对象、它们间的关系和协作）中定义的概念和功能在物理体系结构中的视线，它通常是开发环境中的实现性文件。
通过分析得到该奖学金评定系统的组件图如图4-4所示，
图4-4组件图
4.3.2配置分析
配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。
可以显示计算机节点的拓扑结构和通信路径，结点上执行的软构件，软构件包含的逻辑单元等。
经分析，该系统的配置图如图4-5所示，
图4-5系统配置图
5.课程设计心得体会
通过两周的课程设计，让我们更多的了解了面向对象的分析方法及设计方法，基于uml的各种模型的分析和建立。
可能我们在刚开始的时候，分析系统功能以及划分类的时候，分析不是很全面，总是拉掉一些功能和类，经过老师的指导和同学们的帮助，我们分析的范围越来越广泛，内容越来越丰富。
不仅提高了思考和分析的能力，也提高了动手实践的能力。
经过这次课程设计，我和其他同学都受益匪浅，相信以后我们会越做越好。
参考文献
1.王欣《管理信息系统》中国水利水电出版社2004（2007年重印）
2.谭云杰等编著.《大象--ThinkinginUML》.中国水利水电出版社，2009
3.邵维忠，杨芙清著.面向对象的系统分析.北京：
清华大学出版社，1998
4.张友生等编著.《软件体系结构》.北京：
清华大学出版社，2006
5.吴洁明，袁山龙编著．
升级会员 