学生成绩管理系统uml大连理工大学软件工程大作业.docx
《学生成绩管理系统uml大连理工大学软件工程大作业.docx》由会员分享，可在线阅读，更多相关《学生成绩管理系统uml大连理工大学软件工程大作业.docx（13页珍藏版）》请在冰点文库上搜索。
学生成绩管理系统uml大连理工大学软件工程大作业
学生成绩管理系统设计
2019-4-24
第1章需求分析
1.1功能需求
（1）学生成绩管理系统能够为学生提供查询成绩、计算绩点等服务。
每个学生拥有唯一的账号，每一个账号包括学号、姓名、密码等个人信息。
（2）学生成绩管理系统允许教师对学生的成绩进行录入、查询、修改或删除。
每个教师拥有唯一的账号，每一个账号包括教工号、姓名、密码等个人信息。
（3）教学管理员能够新建学生信息和课程信息，能够查询、修改或删除这些信息，并且管理员能够对本系统设置权限。
每个管理员拥有唯一的账号，每一个账号包括管理员号、姓名、密码等个人信息。
1.2用例模型
采用用例驱动的分析方法，识别出系统中的参与者和用例，并建立用例模型。
1.2.1识别参与者与用例
●参与者可确定为：
学生、教师和教学管理员。
●用例可确定为：
登陆系统、找回密码、查询成绩、计算绩点、修改成绩、删除成绩、录入成绩、新建（查询/修改/删除）学生信息、新建（查询/修改/删除）课程信息。
1.2.2用例图
学生用例图：
教师用例图：
管理员用例图：
1.2.2用例规约
Ø用例名：
用户登录。
用例描述：
用户使用自己的账户名和密码登录系统。
参与者：
学生，教师，管理员。
事件流：
常规流：
1.用户进入成绩管理系统登录界面
2.用户输入用户名和密码
3.系统检查用户的账户是否有效，检查密码与账户是否匹配
4.系统记录登录信息
5.用户进行权限范围内的相关操作
备选流：
1.用户的账户不存在则显示“账户不存在”。
2.用户密码错误显示“密码错误”，用户找回密码。
前置条件：
成绩管理系统正常运行。
系统识别用户权限为学生。
后置条件：
登陆成功，用户可进行权限范围内的操作；登录失败，用户可以选择放弃登录，重新输入密码或者找回密码。
Ø用例名：
查询成绩
用例描述：
学生选中一门课程，查询该课程成绩
参与者：
学生
事件流：
常规流：
1.系统确认用户登录信息以及权限
2.学生选择一门课程，系统显示该课程成绩
3.学生查询成绩结束，关闭窗口
前置条件：
系统正常运行
后置条件：
查询结束后，学生关闭查询成绩窗口
Ø用例名：
教师添加学生成绩
用例描述：
教师添加一门课程学生的成绩
参与者：
教师
事件流：
常规流：
1.系统确认用户登录信息以及权限
2.教师选择一门课程
3.教师根据该课程的学生名单信息进行成绩录入
4.录入结束后，教师保存成绩单，成绩单保存至系统数据库。
5.系统显示成绩信息录入成功
前置条件：
系统正常运行，系统识别用户权限为教师。
后置条件：
保存成功，更新系统数据库，返回用户界面。
保存失败则返回录入界面要求再次尝试。
Ø用例名：
教师查询学生成绩
用例描述：
教师查询一门课的成绩单
参与者：
教师
事件流：
常规流：
1.系统确认用户登录信息以及权限
2.教师选择一门课程
3.系统从数据库中调出该科目的成绩单，并显示。
4.教师查看成绩信息，确认无误后关闭窗口
备选流：
1.教师查看成绩信息后发现成绩信息有误，则修改成绩信息；
2.教师查看成绩后发现有多余的成绩信息，则删除成绩信息。
前置条件：
系统正常运行，系统识别用户权限为教师。
后置条件：
教师发现成绩信息有误，则修改成绩信息；教师发现成绩信息多余，则删除成绩信息。
Ø用例名：
修改学生成绩
用例描述：
教师发现学生成绩信息有误，修改学生成绩
参与者：
教师
事件流：
常规流：
1.教师发现学生成绩信息有误
2.教师选择修改学生成绩，进入成绩修改界面
3.教师对学生成绩进行修改
4.修改完毕后，保存学生成绩，
5.系统数据库更新学生成绩信息
6.系统显示修改学生成绩成功
7.系统显示修改之后的学生成绩信息
前置条件：
系统正常运行，系统确认账户权限为教师；教师进入成绩查询界面。
后置条件：
若用例执行成功，则学生成绩信息被更新，否则系统状态不变。
Ø用例名：
教师删除学生成绩信息
用例描述：
教师发现学生成绩信息多余，删除学生成绩信息
参与者：
教师
事件流：
常规流：
1.教师发现学生成绩信息多余
2.教师选择删除学生成绩信息，进入成绩信息删除界面
3.教师选择若干条学生成绩信息
4.教师删除选中的学生成绩信息
5.删除结束后，保存学生成绩
6.系统数据库更新学生成绩信息
7.系统显示删除学生成绩信息成功
8.系统显示更新之后的学生成绩信息
前置条件：
系统正常运行，系统确认账户权限为教师；教师进入成绩查询界面。
后置条件：
若用例执行成功，则学生成绩信息被更新，否则系统状态不变。
第2章建立静态模型
2.1确定对象类和关联
根据对名词和用例中出现的实体筛选，得到以下5个类：
学生类student、教师类teachers、课程类courses、管理员类manage、成绩类grades
2.2添加属性和操作
Ø学生类students
个人信息应包括：
姓名、密码、入学时间、学号。
使用系统进行的操作应包括：
登录、查询成绩。
Ø教师类teachers
个人信息应包括：
姓名、密码、教工号、所教课程。
使用系统进行的操作应包括：
登录、录入成绩、查询成绩、修改成绩、删除成绩。
Ø课程类courses
属性应包括：
课程号、课程名、任课教师。
可提供的操作应包括：
学生选课
Ø管理员类manage
个人信息应包括：
姓名、密码、管理员号。
使用系统进行的操作应包括：
登录、新增学生信息、查询学生信息、修改学生信息、删除学生信息、新增课程信息、查询课程信息、修改课程信息、删除课程信息、。
Ø成绩类grades
属性应包括：
课程号、学号、成绩。
可提供的操作应包括：
录入成绩、查询成绩、修改成绩、删除成绩。
2.3寻找继承关系
学生类，教师类，管理员类可泛化出一个父类：
用户
共同的属性：
姓名、密码
共同的操作：
登录、修改姓名、密码等个人信息
2.4类图
注：
manage类中的新增、查询、修改、删除函数应该有两套，一套是对学生、课程、教师的信息修改，一套是对成绩修改。
泛化关系
边界类图
第3章建立动态模型
系统的动态行为模型由交互作用图（时序图和协作图）、状态图、活动图描述。
3.1序列图
序列图用于描述对象间的交互行为，着重体现时间顺序。
在学生成绩管理系统中，每个用例都可以建立一个时序图，将用例执行中各个参与的对象之间的消息传递过程表现出来。
下面是三个用例的序列图：
Ø学生查询成绩序列图：
Ø教师修改学生成绩的序列图：
Ø管理员删除学生信息的序列图：
3.2状态图
状态图用来描述一个特定对象的所有可能状态和引起状态转移的事件。
在本系统中，有明确状态转换的是数据所处状态，数据既可以指学生成绩，又可以指学生信息，用一张状态图画出，图中统称为数据状态。
状态图有五个状态：
录入数据状态，检查数据状态，修改数据状态，删除数据状态和保存数据状态。
第4章物理模型
4.1创建系统构件图
构件图用来反映代码的物理结构。
从构件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的关系。
4.2创建系统配置图
配置图表示运行时的计算资源（如计算机及它们之间的连接）的物理布置。
构件和对象的分配可以是静态的，也可以在节点间迁移。
如果含有依赖关系的构件实例放置在不同节点上，部署视图可以展示出执行过程中的瓶颈。
第5章分工小结
此次设计让我们完整的回顾了一遍面向对象分析的过程。
在这次大作业中遇到了一些问题：
对系统功能的分析和系统职责的分割有一些模糊，但是收获也有很多，我们重新学习了很多平时忽视的细节，并且应用uml建模语言完成了对一个问题较完整的建模。
总体而言，还是比较顺利地完成了这次学生成绩系统地设计工作，意识到的不足将及时进行改正和修补。
升级会员 