学生成绩管理系统用例模型
学生成绩管理系统需求分析
实验一：需求分析项目名称：学生成绩管理系统一、用例视图1.用例图如下图 1—12，用例描述图1—1主要描述了学生成绩管理系统的主要参与者在系统中各自的角色和各自可以进行的操作，明确了每个人的基本权限，任何人员都不可以进行自己权限以外的操作。
管理员：管理员参加的操作主要有登录，打开关闭对系统的操作，录入、查看、修改每个使用人员的信息，查看学生成绩并对学生的成绩进行排名。
登陆系统的时候，要选择自己的身份，输入正确的账号和密码登陆进入系统。
在不需要开放系统的时候，管理员要将系统关闭，并对系统进行维护等工作，在期末教师需要录入成绩的时候和开学时学生要查看自己成绩的时候将系统开放使用，让身份为学生和教师的账号也可以进入系统，其他非系统开放时间只有管理员可以进入系统。
录入人员信息主要是在学校新生入学的时候和学校招聘新教师的时候将老师和学生的信息录入系统，并为添加的每一个人分配一个登陆账号和密码，不同的身份的人员具有不同的操作权限。
例如学生只可以查看自己的成绩和自己的排名，不能够修改添加删除自己或别人的成绩，不能够修改自己的基本信息。
老师只能够为自己所教的课程和选择了这门课的学生录入成绩，而不能为别的课程录入信息，不能够修改自己的操作权限和基本信息。
在学生毕业并对自己在校的任何信息都没有异议之后，在学生离校以后，老师离职以后将已经录入的老师和学生信息删除，相应的账号和密码将不能够再登陆系统。
对出现了错误的账号密码等进行修改，解决学生或老师不能登录系统的问题。
管理员可以查看所有学生的成绩，但是没有权利对学生的成绩进行修改。
对学生的成绩按照单科成绩从高到低，总成绩从高到低，按学号顺序给学生成绩进行排名，并把排名结果公布到系统到系统中，每个学生只能够看到自己的排名。
教师人员：教师人员参与的操作主要有登录系统，添加、删除、修改、查找学生成绩。
登陆系统的时候，要选择自己的身份，输入正确的账号和密码登陆进入系统。
教师只能添加删除修改查看自己所教的课程的学生的成绩，在处理完学生的试卷后将相应的学生的成绩录入到系统中去，不能录入不是自己学生的和不是自己教学的学生成绩。
学生信息管理系统分析及用例图
学生信息管理系统需求分析具备学生学籍管理系统Status 学生成绩管理系统Scores学生档案管理系统archives学生缴费信息系统Expends.等多种功能方便管理员登陆查询增加删除修改学生信息管理员能够增删用户能够使学生登陆查询自己的信息教师登陆能够查询所有的学生信息。
用户表userinfo 字段名数据类型长度主键否描述允许空Account varchar 11 是账号否Username varchar 4 否姓名否Password varchar 25 否密码否permit varchar 3 否权限否缴费信息表expends 字段名数据类型长度主键否描述允许空Account VARCHAR 11 是账号否Username VARCHAR 4 姓名否Money Int 缴费金额Whether VARCHAR 1 是否交完学籍信息表statusinfo 字段名数据类型长度主键否描述允许空Account varchar 11 是账号否Username varchar 4 姓名否sex varchar 1 性别否relation varchar 2 党团关系college varchar 6 学院educ varchar 5 学制level Int 级department varchar 15 系别depart varchar 11 专业成绩信息表scores 字段名数据类型长度主键否描述允许空Account varchar 11 是账号否Username varchar 4 姓名否Oracle Int principle Int 组成原理English Int 英语UML Int XML Int 档案信息表archives 字段名数据类型长度主键否描述允许空Account VARCHAR 11 是账号否Username VARCHAR 4 姓名否sex VARCHAR 1 性别否ID VARCHAR 18 身份证号Address VARCHAR 25 详细地址phone VARCHAR 11 电话In VARCHAR 6 现居地。
学生成绩管理系统测试用例
预期结果 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过 通过
实际结果 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 通过 通过 通过
是否通过 否 否 否 否 否 否 否 否 否 否 否 否 是 是 是
用例 ID TC001 TC002 TC003 TC004
Stu5465464 通过
Stu211456 通过
Studgfhd 通过
Stu85456 通过
实际结果 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过
是否通过 否 否 否 否 否 否 否 否 否 否
TC011 TC012 TC013 TC014 TC015 TC016 TC017 TC018 TC019
姓名
预期结果
小小
通过
小王
通过
Sdf
通过
Asdfj212654 通过
Asdfa789 通过
美美
通过
红红
通过
丽丽
通过
莉莉
通过
王二小
通过
实际结果 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过 不通过
是否通过 否 否 否 否 否 否 否 否 否 否
TC011 TC012 TC013 TC014 TC015 TC016 TC017 TC018 TC019
Stu5646
通过
Stu123456 通过
Stu0147
通过
Stu878901 通过
Stu012364 通过
stst0000001 通过
stst0000002 通过
uml图例讲解剖析
证，验证通过后，数据库注销相应存款，返回注销完成信息，
银行系统在存折上打印取款记录。 请根据以上信息绘制顺序图。
UML图例讲解
(6)在某一学生指纹考勤系统中，有一个用例名为“上课登记”。此用例允 许学生在上课前使用系统识别自己的指纹信息进而识别自己的身份，同时 系统可以将登录信息存储在数据库中。 “上课登记”用例的主要事件流如下： 学生从系统菜单中选择“上课登记”； 系统显示指纹识别界面； 学生将手指放置于界面上； 系统捕获并识别学生的指纹，向学生返回识别的身份信息； 学生选择“确认”按钮； 系统生成一个关于该登记学生及当前日期、时间的新记录，并将该记录 保存到数据库中。 请根据以上描述绘制“上课登记”用例的顺序图。
UML图例讲解
(2)某银行储蓄系统需求说明如下。 ①开户：客户可填写开立账户申请表，然后交由工作人员验证并输入系统。 系统会建立账户记录，并会提示客户设置密码(若客户没做设置，则会有一 个缺省密码)。如果开户成功，系统会打印一本存折给客户。 ②密码设置：在开户时客户即可设置密码。此后，客户在经过身份验证后， 还可修改密码。 ③存款：客户可填写存款单，然后交由工作人员验证并输入系统。系统将建 立存款记录，并在存折上打印该笔存款记录。 ④取款：客户可按存款记录逐笔取款，由客户填写取款单，然后交由工作人 员验证并输入系统。系统首先会验证客户身份，根据客户的账户、密码，对 客户身份进行验证。如果客户身份验证通过，则系统将根据存款记录累计利 息，然后注销该笔存款，并在存折上打印该笔存款的注销与利息累计。 请根据以上信息绘制出系统的用例图。
②用户选择其中一种汽水，系统处理后将该种汽水释放。
请绘制此交互过程的协作图。
UML图例讲解
(9)医院拟引入一款患者监护系统。基本要求是随时接收每个 病人的生理信号(脉搏、体温、血压、心电图等)，定时记录病
教务管理系统UML模型
§1 建立系统用例模型
(1)角色的确定
UML中，角色代表位于系统之外和系统 进行交互的一类对象，本系统中创建主要 的角色有： 教务员 教师 学生
(2)创建用例 教务管理系统根据运行流程可分为以下的几个用
例： 用户登录 学籍管理 排课管理 成绩管理 选课管理 教学管理 系统维护
§1.1建立用例图
建立如下四个用例图 （一）顶层用例图 （二）学生角色用例图 （三）教师角色用例图 （四）教务员角色用例图
顶层用例图
学 生 角 色 用 例 图
教 师 角 色 用 例 图
教 务 员 角 色 用 例 图
§2 建立系统动态模型
2.1活动图 经过活动图的建模可以比较清楚地了
解整个进程过程的操作过程，本系统中 主要的活动图有如下几个：学生成绩查 询活动图、教务员修改学生资料活动图、 学生选课活动图以及教师成绩录入活动 图
学 生 成 绩 查 询 活 动 图
教 务 员 学 生 资 料 修 改 活 动 图
学 生 选 课 活 动 图
教 师 成 绩 录 入 活 动 图
§2建立动态模型
2.2顺序图 主要包括如下几个顺序图 ①教务学籍管理顺序图 ②学生注册顺序图 ③学生选课顺序图 ④教师成绩录入顺序图
教 务 成 绩 录 入 协 作 图
§3系统类模型
3.1系统包图 将整个教务管理系统划分为人员信息、 接口和事务3个包，分别控制不同的应 用。
系统包图
§3系统类模型
3.2类图 根据系统划分的三类包图，分别讨论
人员信息包，接口包和事务包中的类图 分别为： 1、人员信息包内的类图 2、接口包内的类图 3、事务包内的类图
问题概述
在高校日常管理中，教务管理模式的科学 化与规范化，管理手段的信息化与自动化 对于学校的总体发展产生深远的影响，由 于管理内容过多，处理的过程也非常复杂， 随着学校人员的增加，教务管理系统的信 息量大幅上升，因此往往很难及时准确地 掌握教务信息的运作状态，所以迫切需要 现代化管理要求的教务管理系统。
教务管理系统UML模型
11级计科2班 李江慧090511233 沈良慧090511237 符 鹤090511231
分工情况：
前期--------李鸣：主要负责资料的收集和准备工作。
李江慧：主要负责用例图、对象图、类图、状态 图和部分协作图的绘制； 沈良慧：主要负责时序图、协作图、活动图的绘 制。
中期
23
返回
24
学生选课时序图
返回
25
返回
26
教师成绩录入时序图
返回
27
协作图
教务学生学籍管理协作图
学生注册协作图
学生选课协作图
教师成绩录入协作图
动态图首页
28
教务学生学籍管理协作图
返回
29
学生注册协作图
返回
30
学生选课协作图
返回
31
教师成绩录入协作图
返回
32
状态图
成绩录入 状态图
动态图首页
教师 学生 管理员
7
静态图
动态图
流程
8
静态图
用例图 类图 组件图 配置图
目錄
9
系统的用例图
教师进行教学管理的用例图 学生学习活动用例图 管理员进行系统维护的用例图
静态图首页
10
返回
11
返回
12
返回
13
人员信息类图
系统中的总类图
静态图首页
14
人员信息类图
返回
15
返回
16
组件图
返回
39
学生成绩查询活动图
返回
40
系 统 管 理 员 修 改 学 生 资 料 活 动 图
返回
41
学生成绩管理系统的建模与分析
7. 收获和体会
最常用的UML图包括:用例图，类图，顺序 图,状态图,活动图等，对我们来说最大的 收获就是自己动手实践进行UML统一建模,
掌握了面向对象UML统一建模语言
实现了"学生成绩管理系统"的设计和建模
随着教育信息化的不断深入，学校对学生成绩的管理需求日益增加 学生成绩管理系统必须能够处理大量的学生数据，提供快速的成绩录入、查询、修改和删 除功能 同时，系统还应当能够进行成绩的统计分析，为教师、学生和教务管理人员提供决策支持
功能需求主要包括 (1)学生拥有唯一的个人账户及密码 (2)教师对学生的成绩进行录入，查看学生的成绩 (3)教学管理员可以修改教师基本信息，修改学生基本信息，添加教师基本信 息，添加学生基本信息，删除教师基本信息，删除学生基本信息 对学生的成绩进行修改、删除
9
3.1 定义系统对象类
3.1 定义系统对象类
01
(1)学生类
02
(2)课程类
03
(1) 教师类
04
(2) 成绩类
05
(3) 系统管理员
类
10
3.2界面类
3.2界面类
(1)类MainWindow MainWindow是系统的主界面 (2)类studentDialog 界面类studentDialog是进行操作"添加学生"、"修改学生"或"删除学生"时所需的对话框
2.3.2 成绩录入的活动图
若成绩无效，系统会提示错误并要求重新录 入 有效则进入下一步 系统将录入的成绩数据保存至数据库，并可 能同步更新学生的总评成绩 成绩录入完成后，用户可以选择继续录入其 他课程的成绩或者退出成绩录入界面 整个成绩录入活动最终在所有操作结束后终 止于"结束"节点
学生成绩查询系统用例图
一、学生成绩查询系统用例图用例图在需求分析阶段有很重要的作用，它主要描述人们希望如何使用一个系统，作为参与者的外部用户所能观察到的系统功能的模型图。
开发的全过程都是围绕需求阶段的用例图进行的。
我们所开发的学生成绩查询系统内容十分丰富，用户包括学生、老师、教务人员，其角色层次图如图所示:学生老师教务人员角色层次图授权用户通过学生成绩查询系统的身份认证后享有系统规定的资源，教师可以输入学生的成绩，也可以查询其对应所教的科目的学生的成绩情况；学生可以查看所有科目的成绩结果以及对自己成绩核实并针对该情况申请错误信息；教务人员可以核实学生的成绩情况并分类各科的成绩。
管理员经过系统的身份验证后可以对系统进行相应的管理和维护，包括授权用户、添加用户和删除用户等。
经过以上分析，得出系统的用例模型如图所示:学生成绩查询系统的用例模型图作为学生成绩查询系统的参与者有：学生、老师、教务人员、系统管理员。
（1）参与者首先是学生，学生可以登录系统，并可以根据自己的情况修改密码，然后通过登陆系统查看自己的成绩，并可以对自己的成绩提出申请错误信息。
（2）其次是作为参与者的教师，教师可以输入学生的成绩，也可以查询其对应所教的科目的学生的成绩情况。
（3）第三参与者就是教务人员，教务人员就是核实学生的成绩情况并分类各科的成绩。
（4）整个系统的管理都是由系统管理员进行的，如用户的授权、用户的添加与删除等情况。
所以系统管理员的角色也非常重要。
1、学生的用例图包含如下的用例：（1）登录系统。
（2）查看自己的成绩情况。
（3）申请错误信息。
（4）修改密码。
学生的用例图2、教师的用例图包含如下的用例：（1）登录系统。
（2）输入学生成绩。
（3）查看学生该科目的成绩。
老师的用例图3、教务人员的用例图包含如下的用例：（1）登录系统。
（2）核实学生成绩。
（3）分类各科成绩。
教务人员的用例图4．系统管理员的用例图包含如下的用例：（1）授权用户。
（2）添加用户。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
实验三：用例模型
题目：学生成绩管理系统
一、用例图
二、用例描述
（一）.用例名称：登录。
参与者：使用者。
1.1 简要说明
对登录的流程进行描述，操作者输入用户名、密码、选择用户类型进行登录。
1.2 事件流
1.2.1 基本流
(1) 用户：进入登录页面，用例开始；
系统：显示登录界面；
(2) 用户：输入登录信息，登录信息包括：用户名、密码、用户类型；
系统：显示输入信息；
(3) 用户：可能进行下面两种操作：
(a) 用户：选择登录，则执行基本流(4)；
(b) 用户：选择重置，则返回到基本流(1)；
(4) 系统：验证用户的登录信息，可能有下边两种情况；
(a) 登录成功：执行基本流(5)；
(b) 登录失败：执行备选流(1)；
(5) 登录成功，结束此用例。
1.2.2 备选流
(1) 登录失败：如果系统检测到用户名、密码不存在或错误，则提示用户输入的登录信息不正确，系统返回到选择登录前的状态，用户可以重新输入/修改登录信息，重新执行基本流(3)。
1.3特殊需求(约束和非功能性需求)
1.3.1 第一特殊需求
要求用户密码安全。
1.4 前置条件
1.4.1 第一前置条件
系统已启动到登录界面。
1.5 后置条件
1.5.1 第一后置条件
用户登录成功后，根据用户类型进入到相应界面。
Administrator用户进入到管理员界面，Employee用户进入到个人用户界面。
1.5.2 第二后置条件
用户登录失败，返回到登录界面。
（二）.用例名称：添加成绩。
参与者：老师。
2.1 简要说明
对添加成绩的流程进行描述，老师对学生的各科成绩进行添加。
2.2 事件流
2.2.1 基本流
(1)用户：老师选择进入添加成绩界面，用例开始；
系统：显示添加成绩界面；
(2)用户：新添加一条成绩；
系统：显示添加信息；
(3) 用户：可能进行下面两种操作：
(a) 用户：选择提交添加的成绩信息，则执行基本流(4)；
(b) 用户：选择重置添加成绩信息，则返回到基本流(1)；
（c）用户：选择退出，则返回老师管理界面；
(4)系统：显示是否提交添加信息：
（a）选择是，执行基本流（5）；
（b）选择否，则执行备选流（1）；
(5) 添加成绩成功，结束此用例。
2.2.2 备选流
(1)选择否：如果不想添加成绩，执行备选流（2）；继续对成绩进行操作，执行事件流（2）；
（2）退出添加成绩界面，返回主界面。
2.4 前置条件
第一前置条件
老师成功进入添加成绩的界面。
2.5 后置条件
第一后置条件
完成了对成绩的添加，返回主界面。
（三）.用例名称：管理信息。
参与者：管理员
3.1 简要说明
对管理信息的流程进行描述，管理员对学生、老师进行增、删、改、查的操作。
3.2 事件流
3.2.1 基本流
(1)用户：管理员进入信息管理界面，用例开始；
系统：显示管理信息界面；
（2）用户：选择对信息的管理；
(3) 用户：提交对信息的操作；
系统：显示是否提交信息；
(4) 用户可能进行下面操作：
（a）选择是：提交对信息的操作，则执行基本流(5)；
（b）选择否：执行备选流（1）；
(5) 信息操作成功，返回管理员界面，结束此用例。
3.2.2 备选流
(1)选择否：如不再对信息进行操作，执行备选流（2）；如果继续操作。
则执行事件流（2）；
（2）返回管理员界面。
3.4 前置条件
第一前置条件
老师成功进入添加成绩的界面。
3.5 后置条件
第一后置条件
完成了对成绩的添加，返回主界面。
（四).用例名称：查看成绩信息
参与者：学生
4.1 简要说明
对学生查看成绩信息的流程进行描述，学生对自己的各科成绩进行查看。
4.2 事件流
4.2.1 基本流
(1)用户：学生输入登录信息，用例开始；
系统：显示登录界面，系统提示输入验证信息；
（2）用户：可能进行下面两种操作：
（a）验证成功，执行基本流（3）；
（b）验证失败，执行备选流（1）；
(3) 用户：进入查看成绩界面，选择要查看的成绩；
系统：根据要求显示成绩；
(5) 查看结束，返回主界面，结束此用例。
4.2.2 备选流
(1)验证失败：如果不想继续查看成绩，执行备选流（2）；继续查看成绩，执行事件流（1）；
（2）退出系统。
4.4 前置条件
第一前置条件
学生成功进入查看成绩的界面。
4.5 后置条件
第一后置条件
完成了对成绩的查询，返回主界面。