学生选课系统UMLWord文件下载.docx

学生选课系统UMLWord文件下载.docx

《学生选课系统UMLWord文件下载.docx》由会员分享，可在线阅读，更多相关《学生选课系统UMLWord文件下载.docx（22页珍藏版）》请在冰豆网上搜索。

学校采取手工方式对学生选课情况进行人工管理，由于信息比较多，选课信息的管理工作混乱而又复杂；

一般选课情况是记录在文件上，课程的数目和代号也记录在文件中，学校的工作人员也只是当时对它比较清楚，时间长了，如再要进行查询，就得在众多的资料中翻阅、查找了，造成查询费时、费力。

如要对很长时间以前的选课进行更改就更加困难了。

基于这些问题，我认为有必要建立一个学生选课系统，使选课管理工作规范化，系统化，程序化，避免选课管理的随意性，提高信息处理的速度和准确性，能够及时、准确、有效的查询和修改选课情况。

1.2、学生选课系统开发的可能性

经过详细的分析和调查，应用本学期《信息系统分析与设计》这门课程所学习的知识，本设计采用面向对象的方法，使用UML建模语言进行建模。

UML是完全面向对象的，是图形化的，它为系统开发的不同参与者（包括客户）提供不同层次和角度的图；

它鼓励客户参与，这样，开发出来的软件是一个能符合设计之初的设想的软件。

其特点是从用户的角度使用“用例图”出发来设计软件系统，这就避免了开发者开发出的系统虽然具有很多很好的功能，但确不能很好的符合客户真正的需求。

二、需求工作流

2.1.问题域

2.1.1问题

试设计一选修课程系统，使之能提供以下功能：

（1）系统以菜单方式工作

（2）课程信息录入功能（课程信息用文件保存）－－输入

（3）课程信息浏览功能－－输出

（4）查询功能：

（至少一种查询方式）－－算法

ⅰ按学分查询

ⅱ按课程性质查询

（5）学生选修课程（可选项）

2.1.2问题的解决方案

根据系统功能要求，可以将问题解决分为以下步骤：

（1）分析系统中的各个实体之间的关系及其属性和行为；

（2）根据问题描述，设计系统的类层次；

（3）完成类层次中各个类的描述（包括属性和方法）；

（4）完成类中各个成员函数的定义；

（5）完成系统的应用模块；

（6）功能调试；

（7）完成系统总结报告以及系统使用说明书

2.2.领域模型

2.2.1系统参与者

使用学生选课系统的参与者有学生、老师和管理员。

2.2.2用例

（1）用例图

图2-1学生用例图

图2-2管理员、老师用例图

（2）用例描述

图2-3登录学生选课系统用例的描述

间短描述

登录学生选课系统用例使学生或老师能够进入系统进行相应权限下的操作

逐步描述

1、学生可以选课。

2、老师可以进行相应的增加、删除等操作。

3、管理员可以执行老师能执行的所有操作，而且权限更多，比如授予权限、更改系统等

图2-4选课用例的描述

简短描述

选课用例使学生能够选定自己喜欢的课程

1、学生可以根据自己的兴趣、专业方向选定自己喜欢的课程

图2-5修改用例的描述

修改用例使学生能更改自己的选定课程

1、学生可以根据自身情况更改自己的选课

2、学生不能一次确实要学什么课程，所以要能修改

图2-6保存用例的描述

保存用例使学生选课信息保存在系统中

1、学生选课信息得以保存，方便查阅、使用

图2-7提交用例的描述

提交用例使学生能将自己的选课信息提交上去

1、提交后不能更改

2、提交即选课成功

图2-8退出学生选课系统的描述

退出学生选课系统用例是系统用户完成操作后可以退出

1、完成操作后退出学生选课系统

图2-9增加学生用例的描述

增加学生用例使老师可以增加学生

1、新转来的学生应该由老师增加进来

2、漏掉的学生应该由老师增加进来

图2-10删除学生用例的描述

删除学生用例使老师可以删除那样应该被删除的学生

1、退学的、转走的学生应该由老师删除掉

图2-11增加课程用例的描述

增加课程用例使老师可以增加新开的课程

1、老师可以根据需要增加新开的课程

图2-12删除课程用例的描述

删除课程用例使老师能够删除那些选课人数太少的课程

1、选课人数太少的课程应该由老师删除

2、由于特殊原因不再开设的课程予以删除

图2-13修改学分用例的描述

修改学分用例使老师能够合理安排每门课程的学分

1、学分应该适当修改，合理安排

图2-14查看选课情况用例的描述

查看选课情况用例使老师能够查看学生的选课情况

1、老师可以查看学生选课情况，做出相应操作，比如如果人数不够，应删除该课程等

图2-15保存数据用例的描述

保存数据用例使老师可以把操作后更改的信息保存在系统中

1、所做修改信息应保存

三、分析工作流

3.1.类图

图3-1用户类图

图3-2登录类图

3.2.状态图

图3-3状态图

3.3、顺序图

3.3.1、用户登录

（1）用户在登录界面输入用户名和密码后，若登录信息正确，则依据用户权限，用户分别进入学生、老师和管理员界面。

（2）用户可以在登录界面进行密码的修改，密码修改后会保存在用户权限表中。

可能出现的情况：

输入用户名或密码错误，系统提示非法用户登录，需要重新输入正确的用户名和密码。

图3-4用户登录顺序图

3.3.2、学生选定课程

学生选定课程，修改已经选定的课程，保存，提交，退出系统。

图3-5学生选定课程顺序图

3.3.3、老师做出相应操作

老师根据相应情况对学生进行增删，增加某些课程，删除某些课程，修改学分等。

图3-6老师做出相应操作顺序图

3.3.4、老师查看学生选课情况

老师想看学生的选课情况，系统要返回学生选课情况。

图3-7老师查看学生选课情况顺序图

四、设计工作流

4.1细化类图

图4-1细化用户类图

图4-2细化各种类图

4.2数据库设计

4.2.1概念模型

（1）学生课程联系E-R图

图4-3学生课程联系E-R图

一个学生可以选修多么课程，一个课程可以被多个学生选修。

所以学生和课程是m:

n的关系。

学生的属性有姓名、学号、登录密码和所属院系。

课程的属性有课程号、课程名、课时和学分。

（2）教师课程关系E-R图

图4-4教师课程关系E-R图

一个老师可以讲授多门课程，一个课程可以有多个老师上，比如很多专业班级要少C语言，全校肯定不止一个C语言老师，所以老师和课程的关系是n:

m.

老师的属性有姓名、教师号、密码和所属院系，课程的属性有课程号、课程名、课时和学分。

（3）管理员教师关系实体E-R图

图4-5管理员老师E-R图

一个管理员可以管多个老师，所以管理员和老师是1:

（4）全局E-R图

图4-6学生选课全局E-R图

一个学生可以选修多个课程，一个课程可以被多个学生选修，所以学生和课程是n:

m的关系；

一个老师可以任教多个班级，所以老师和班级是1:

n的关系；

一个课程可以在多个班级开始，所以课程和班级是1:

4.2.2逻辑模型

学生（学号（主键），姓名，密码，院系）

课程（课程号（主键），课程名，课时，学分）

选修（学生，课程，（都是主键））

老师（教师号（主键），姓名，密码，院系）

讲授（老师，课程，（都是主键））

五、界面设计

5.1用户登陆界面

用户登陆界面是每一个用户，在登陆本系统时出现的界面，如要用户输入用户名、密码和验证码，以及确定用户身份。

其界面如下图：

图5-1用户登陆界面

六、总结

通过《信息系统分析与设计》这么课程的学习和这次课程设计，熟练掌握了面向对象思想和UML设计。

深刻体会到UML设计的关键不是怎样使用ROSE，关键是思想，面向的对象的思想，然后用UML把思想表达出来。

我感觉如果UML是编程语言，那么面向对象的思想就是算法。

由于我将来走的计算机软件开发这条路，所以这次课程设计对我还是有帮助的，虽然做的不是很好，但是这是第一次做关于UML面向对象的课程设计。

其中碰到不太会的问题，咨询了吴老师和同学，在这表示感谢。

七、参考文献

1．黄梯云，冯玉强．管理信息系统．北京：

高等教育出版社，2006。

2.StephenR.Schach.面向对象分析与设计导论.北京：

高等教育出版社，2004。

3.赵文涛，张静，刘艳霞.数据库系统原理.中国矿业大学出版社，2006。

4.郭盈发.数据库原理与应用.西安电子科技大学出版社，2005。