软件工程导论实验报告——成绩管理系统（黑龙江大学）-深圳市維司達科技有限公司

面向对象分析与设计

实验一软件需求分析

1.1 业务需求描述

本系统主要包括系统管理员、教师、学生三种类型用户。学生可以查看个人成绩，查询学分和挂科数目以及学业预警。教师可以添加学生成绩，删除学生成绩，修改学生成绩，查看学生成绩查询挂科数目。教务处可以使用系统，输入学生信息、教师信息、课程信息，参与修改成绩审核，查询学生学分，对学生进行学业预警。

1.2 系统功能性需求分析

各科教师登录系统后可以查询和修改个人信息、修改自己的账号密码，查询自己的授课课程，实现对选修了自己课程的学生的成绩进行查询、录入和修改，各科老师可以对自己学生选修课程结束后给予分数。

每个学生登录系统后可以查询和修改个人信息、修改自己的账号密码，同时在课程结束后可以查询在校期间各个时间段选修课程的成绩与学分，以及学业预警。

教务处人员登录系统后可以查询和修改个人信息、修改自己的账号密码，在课程开始前输入学生信息、教师信息、院系信息、课程信息，参与修改成绩审核，查询学生学分，对学生进行学业预警。

1.3用例分析

1.3.1 系统参与者

学生：使用系统的目的是查询所学课程的成绩，查询学分和挂科数目以及学业预警。教师：完成学生成绩的录入、修改、查询、删除，查询挂科数目。教务处：输入学生信息、教师信息、课程信息，参与修改成绩审核，查询学生学分，对学生进行学业预警。

1.3.2 系统用例图

系统总用例图如图1-1所示。

图1-1 系统总用例图

1.3.3 用例描述

1.3.3.1 修改学生成绩用例描述

修改学生成绩用例描述如表1-1所示。

表1-1 修改学生成绩用例描述

用例名	修改学生成绩
主要业务参与者	教师（任课教师）
其他参与者	教务管理员、学生（间接）、成绩管理系统
描述	允许教师在成绩提交截止前或经教务批准后，对已录入的学生成绩进行修改，并记录修改日志以确保可追溯性。
前置条件	1. 教师已成功登录成绩管理系统。 2. 该教师是当前课程的任课教师。 3. 成绩已录入但尚未最终归档，或已获得教务管理员的修改授权。
后置条件	1. 学生成绩被成功更新。 2. 系统记录成绩修改的时间、操作人及修改前后值。 3. 相关学生可能收到成绩变更通知（如系统配置启用）。
触发条件	教师发现已提交的成绩存在录入错误，或因补考、作业补交等原因需调整成绩。
基本流程	1. 教师进入“成绩管理”模块，选择对应课程。 2. 系统显示该课程所有学生的成绩列表。 3. 教师选择需要修改的学生，点击“编辑成绩”。 4. 教师输入新的成绩值并提交。 5. 系统验证成绩格式和范围（如0–100分或等级制）。 6. 系统保存新成绩，并自动记录修改日志。 7. 系统提示“成绩修改成功”。
替代流程	A1：成绩已归档且无修改权限若成绩已归档且未获教务授权，系统提示“成绩已锁定，无法修改”，并建议联系教务管理员。 A2：成绩格式无效若输入的成绩超出有效范围或格式错误，系统提示错误信息，并要求重新输入。 A3：需教务审批的修改若处于成绩归档期后，教师提交修改申请，系统将请求转至教务管理员审批；审批通过后方可修改。
结束	成绩成功更新并记录日志，或操作被拒绝并给出明确原因。
实现约束和说明	- 成绩修改仅限于任课教师本人所授课程。 - 所有修改必须留痕，不可覆盖原始记录。 - 系统应支持百分制、等级制等多种评分体系。 - 修改操作需符合学校成绩管理规定（如截止日期、审批流程等）。 - 日志信息应包括：操作人、时间、课程、学生、原成绩、新成绩。
待解决问题	- 是否允许批量修改成绩？若允许，如何保证操作安全？ - 成绩修改通知机制是否需学生确认或反馈？ - 跨学期/跨学年成绩修改的权限与流程尚未明确。 - 与第三方系统的数据同步机制需进一步设计。

1.3.3.2 查询学分用例描述

查询学分用例描述如表1-2所示。

表1-2 查询学分用例描述

用例名	查询学分
主要业务参与者	查询学分
其他参与者	成绩管理系统、教务系统、辅导员（间接）
描述	允许学生通过系统查询本人当前已获得的总学分、各课程类别（如必修、选修、实践等）的学分完成情况，以及毕业所需学分要求的对比信息。
前置条件	1. 学生已成功登录校园信息系统或成绩管理系统。 2. 系统中已存在该学生的注册信息和课程成绩记录
后置条件	1. 学生成功获取个人学分统计信息。 2. 系统可记录查询日志（可选，用于审计或分析）。
触发条件	学生需要了解自己的学分完成进度，例如在选课前、申请毕业或学业规划时。
基本流程	1. 学生登录系统后，进入“学分查询”或“学业进度”模块。 2. 系统自动加载该学生所属专业、年级及培养方案。 3. 系统根据已修课程成绩，计算并展示：已获得总学分必修课、选修课、实践环节等分类学分毕业要求总学分及各类别最低要求学分缺口或超额情况 4. 学生查看结果，操作结束。
替代流程	A1：无有效成绩数据若学生尚未修读任何课程或成绩未录入，系统显示“暂无学分记录”，并提示联系教务。 A2：培养方案未配置若系统无法匹配学生的专业培养方案，提示“培养方案未配置，请联系辅导员或教务处”。 A3：跨专业/转专业学生系统尝试根据最新学籍信息加载对应培养方案；若存在冲突，提示“学分认定可能存在差异，请咨询教务”。
结束	学生成功查看个人学分信息，或系统给出明确错误提示并建议后续操作。
实现约束和说明	- 学分计算必须严格依据学校现行培养方案和成绩管理规则。 - 系统应支持实时或准实时更新（如成绩发布后24小时内反映在学分统计中）。 - 不同专业、年级可能对应不同培养方案，系统需准确匹配。 - 界面应清晰区分“已修学分”“在修学分”“未修学分”和“毕业要求”。 - 敏感信息（如他人学分）不得泄露，权限严格限定为本人查询。
待解决问题	- 如何处理因课程替代、学分置换等特殊情况导致的学分认定？ - 是否支持导出学分报告（PDF/Excel）供学生打印或提交？ - 国际学生或联合培养项目的学分规则是否兼容？ - 系统能否提供“预计毕业时间”或“选课建议”等智能辅助功能？

1.3.3.3 录入学生成绩用例描述

录入学生成绩用例描述如表1-3所示。

表1-3 录入学生成绩用例描述

用例名	录入学生成绩
主要业务参与者	教师（任课教师）
其他参与者	成绩管理系统、教务管理员、学生（间接）
描述	允许任课教师在课程结束后，在规定时间内将学生的课程成绩录入成绩管理系统，并提交审核或直接生效，确保成绩数据的准确性和及时性。
前置条件	1. 教师已成功登录成绩管理系统。 2. 当前课程教学任务已结束（如期末考试已完成）。 3. 系统已开放该课程的成绩录入权限（处于成绩录入时间段内）。 4. 学生名单已由教务系统同步至该课程。
后置条件	1. 学生成绩被成功保存至系统数据库。 2. 成绩状态标记为“已提交”或“待审核”（依学校流程而定）。 3. 学生可在规定时间后查看成绩（若系统配置为公开）。 4. 系统记录操作日志（操作人、时间、课程等）。
触发条件	课程考核（如期中、期末、实验、论文等）完成，教师需将评定后的成绩正式录入系统。
基本流程	1. 教师进入“成绩管理”模块，选择需要录入成绩的课程。 2. 系统显示该课程的学生名单及对应考核项（如平时分、期末分、总评等）。 3. 教师逐项输入或批量导入学生成绩。 4. 教师检查成绩数据完整性与合理性（如无空值、分数范围合规）。 5. 教师点击“提交成绩”。 6. 系统验证数据格式和规则（如总评是否在0–100之间，等级制是否合法）。 7. 验证通过后，系统保存成绩并更新状态为“已提交”。 8. 系统提示“成绩提交成功”。
替代流程	A1：成绩录入时间已截止系统提示“成绩录入窗口已关闭”，建议联系教务管理员申请延期。 A2：成绩格式或范围错误系统高亮错误项（如负分、超过100分、非等级字符），要求教师修正后重新提交。 A3：部分学生成绩缺失若存在未填成绩的学生，系统提示“仍有X名学生成绩未填写”，教师可选择继续提交（若允许缺考/缓考标记）或返回补充。 A4：需教务审核流程提交后成绩状态为“待审核”，教务管理员审核通过后才对学生可见。
结束	成绩成功提交并保存，或因不符合条件被拒绝并给出明确提示。
实现约束和说明	- 仅课程指定的任课教师可录入该课程成绩。 - 支持多种评分体系（百分制、五级制、二级制等），需按课程设置匹配。 - 应支持Excel模板导入与手动录入两种方式。 - 成绩一旦提交，在未解锁情况下不可直接修改（需走“修改成绩”用例流程）。 - 系统应防止重复提交覆盖，保留提交时间戳。 - 缺考、缓考、作弊等特殊情况需有专用标记字段，不能以“0分”简单代替。
待解决问题	- 如何处理合班课、跨院系课程的多教师协同录分？ - 是否支持自动计算总评成绩（如按权重公式）？ - 成绩提交后是否允许教师撤回（在审核前）？ - 与学业预警、奖学金评定等下游系统的实时联动机制尚未明确。

1.3.3.4 查询成绩用例描述

查询成绩用例描述如表1-4所示。

表1-4 查询成绩信息用例描述

用例名	查询成绩信息
主要业务参与者	学生
其他参与者	成绩管理系统、教务系统、辅导员（间接）
描述	允许学生登录系统后查询本人已发布的课程成绩信息，包括各门课程的成绩详情、学分、绩点、考核方式及成绩状态（如正常、缺考、缓考等）。
前置条件	1. 学生已成功登录校园统一身份认证系统或成绩管理系统。 2. 相关课程成绩已由任课教师录入并经系统发布（对学生可见）。 3. 学生具有有效的学籍状态（如在读、未被冻结）。
后置条件	1. 学生成功查看个人成绩信息。 2. 系统可记录查询日志（用于安全审计或使用分析，可选）。
触发条件	学生需要了解自己某学期或全部课程的成绩情况，例如期末结束后、申请奖学金、转专业或学业复盘时。
基本流程	1. 学生登录系统，进入“成绩查询”模块。 2. 系统默认显示当前学期或最近学期的成绩列表；学生也可选择学年/学期进行筛选。 3. 系统展示每门课程的以下信息：课程名称、课程代码考核方式（考试/考查）成绩（如85、A、通过等）学分、绩点成绩状态（正常/缺考/缓考/作弊等） 4. 学生可查看总平均绩点（GPA）、累计学分等汇总信息。 5. 查询结束。
替代流程	A1：无已发布成绩若所选学期无成绩数据，系统提示“暂无成绩信息”，可能因教师未提交或成绩未发布。 A2：成绩尚未发布对于已录入但未发布的成绩，系统不显示具体分数，仅提示“成绩未公布”。 A3：学籍异常若学生处于休学、退学或账号冻结状态，系统提示“无权访问成绩信息，请联系教务处”。 A4：跨校区/联合培养课程部分课程成绩来自外部系统，若同步延迟，系统标注“数据同步中”或提供来源说明。
结束	学生成功查看成绩信息，或系统给出明确提示说明无法查询的原因。
实现约束和说明	- 严格限制为本人查询，禁止越权访问他人成绩。 - 成绩仅在教师提交并经系统/教务审核后对学生开放。 - 支持多种成绩表示形式（百分制、等级制、二级制），需与录入格式一致。 - 界面应清晰区分“已发布”与“未发布”状态。 - 建议提供成绩导出功能（如PDF成绩单），但需符合学校信息安全规范。 - 成绩信息应与学分、绩点规则联动，确保计算准确。
待解决问题	- 是否支持按课程类型（必修/选修）、成绩区间等条件筛选？ - 历史成绩修改后，是否向学生推送变更通知？ - 成绩单导出是否需数字签名或防伪水印以供正式使用？ - 国际学生多语言成绩显示（如中英文课程名）如何实现？

1.3.3.5 查询挂科科目用例描述

查询挂科科目用例描述如表1-5所示。

表1-5 查询挂科科目用例描述

用例名	查询挂科科目
主要业务参与者	学生
其他参与者	成绩管理系统、教务系统、辅导员（间接）
描述	允许学生查询本人所有未通过（挂科）的课程信息，包括课程名称、学分、考核方式、成绩及补考/重修状态，以便及时安排补考或重修计划。
前置条件	1. 学生已成功登录校园信息系统或成绩管理系统。 2. 系统中已存在该学生的课程成绩记录。 3. 相关课程成绩已发布且判定规则（如及格线）已在系统中配置。
后置条件	1. 学生成功获取本人所有挂科课程列表及相关信息。 2. 系统可记录查询日志（用于审计或学业预警分析，可选）。
触发条件	学生在学期结束后希望了解自己未通过的课程，或在选课前确认是否需要重修。
基本流程	1. 学生登录系统，进入“学业信息”或“成绩管理”模块，选择“挂科科目查询”。 2. 系统根据学生的成绩数据和学校及格标准（如60分、D以上等），自动筛选出所有未通过课程。 3. 系统展示每门挂科课程的以下信息：课程名称、课程代码开课学期考核方式（考试/考查）实际成绩与及格线对比学分补考/重修状态（如“未安排”“已报名”“已通过”） 4. 系统可提供“是否影响毕业”“建议重修学期”等辅助提示（若功能支持）。 5. 查询结束。
替代流程	A1：无挂科记录系统显示“恭喜！您目前无挂科课程。” A2：部分成绩未发布对于成绩未发布的课程，系统不纳入挂科判断，并提示“部分课程成绩尚未公布，结果可能不完整”。 A3：挂科判定规则不明确若某课程采用特殊评分标准（如实践课“通过/不通过”），系统依据预设规则判断；若规则缺失，标记为“状态待定”，建议联系教务。 A4：已通过补考但原记录仍显示系统应优先显示最新有效成绩；若仍显示挂科，提示数据同步延迟或需人工核实。
结束	学生成功查看挂科科目列表，或系统明确告知无挂科记录/数据不完整。
实现约束和说明	- 挂科判定必须基于学校官方及格标准（可按课程类型差异化配置）。 - 仅显示学生本人数据，严格权限控制。 - 应区分“首次挂科”“补考未过”“重修中”等状态，便于学业规划。 - 若学校有学业预警机制，该用例可与预警系统联动。 - 不得将缓考、缺考直接等同于挂科，需单独标识。
待解决问题	- 如何处理因成绩修改（如加分、申诉成功）导致的挂科状态变更？ - 是否支持一键跳转至重修报名页面？ - 多次重修同一门课程，是否只显示最新一次结果？ - 跨校/联合培养课程的挂科认定标准如何统一？

1.3.3.6 学业预警用例描述

学业预警用例描述如表1-5所示。

表1-5学业预警用例描述

用例名	学业预警
主要业务参与者	学生、辅导员（或学业导师）
其他参与者	教务系统、成绩管理系统、学院教务
描述	系统根据预设的学业风险规则（如挂科门数、GPA过低、学分不足等），自动识别存在学业困难的学生，并向学生本人及辅导员发送预警通知，促使其及时干预和调整学习计划。
前置条件	1. 学生成绩、学分、注册状态等数据已在教务系统中完整记录。 2. 学校已配置学业预警规则（如：一学期挂科≥2门、累计GPA<2.0、未修满最低学分等）。 3. 预警功能已启用，相关人员联系方式已维护。
后置条件	1. 符合预警条件的学生被标记为“学业预警对象”。 2. 系统自动发送预警通知（站内信、短信、邮件等）给学生和辅导员。 3. 预警记录存入学生学业档案，供后续跟踪使用。 4. 辅导员可在系统中查看预警名单并记录干预措施。
触发条件	每学期成绩发布后，或学生学籍/成绩数据发生变更（如补考成绩录入、重修退课等），系统自动运行学业预警评估任务。
基本流程	1. 系统在成绩发布完成后（或定时任务触发时）启动学业预警分析。 2. 系统遍历所有在籍学生，依据预设规则逐项比对：挂科课程数量累计/学期GPA 已获学分 vs 培养方案要求出勤率、选课异常等（若数据支持） 3. 对满足任一预警条件的学生，生成预警等级（如黄色/橙色/红色）。 4. 系统向学生推送预警通知，内容包括：预警原因建议措施（如联系导师、申请辅导、重修安排） 5. 同时向对应辅导员发送预警名单及详情。 6. 预警信息写入学生学业档案，状态为“已预警，待跟进”。
替代流程	A1：无学生触发预警系统记录“本轮无预警对象”，流程正常结束。 A2：学生信息不全（如无辅导员分配）系统记录异常，并将该生预警信息转至学院教务秘书处理。 A3：学生处于休学/保留学籍状态系统跳过该生，不纳入预警评估。 A4：家长通知开关开启若学校政策允许且家长联系方式有效，系统同步向家长发送简化版预警通知。
结束	所有符合条件的学生完成预警通知发送，预警记录入库，辅导员可开始人工干预。
实现约束和说明	- 预警规则应支持按年级、专业、培养层次（本科/专科）差异化配置。 - 预警等级与响应机制需明确（如黄色预警由学生自查，红色预警需面谈）。 - 必须保护学生隐私，预警信息仅限授权人员访问。 - 系统应支持手动解除预警（如学生后续成绩达标）。 - 预警历史应可追溯，用于学业帮扶效果评估。
待解决问题	- 如何动态调整预警阈值以适应不同专业特点？ - 是否支持学生申诉预警结果？ - 预警后的干预措施（如心理辅导、学习支持）如何与系统联动？ - 能否基于机器学习预测潜在学业风险（而非仅事后判断）？

1.4 用例活动图描述

1.4.1 录入学生成绩用例活动图

录入学生成绩用例描述如图1-2所示。

图1-2 录入学生成绩用例活动图

1.4.2 修改学生成绩用例活动图

修改学生成绩用例描述如图1-3所示。

图1-3 修改学生成绩用例活动图

1.4.3 查询成绩用例活动图

查询成绩用例描述如图1-4所示。

图1-4查询成绩用例活动图

1.4.4 学业预警用例活动图

学业预警用例描述如图1-5所示。

图1-5 学业预警用例活动图

1.4.5 查询学分用例活动图

查询学分用例描述如图1-6所示。

图1-6查询学分用例活动图

1.4.6 查询挂科科目用例活动图

查询挂科科目用例描述如图1-7所示。

图1-7 查询挂科科目用例活动图

1.5 系统非功能需求

1.5.1 硬件环境

设备1
处理器	11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
机带	RAM 16.0 GB (15.6 GB 可用)
设备ID	3A4EBDEE-3DD2-4436-A128-8608A0AEE925
产品 ID	00342-36262-33467-AAOEM
系统类型	64 位操作系统, 基于 x64 的处理器
设备2
处理器	11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz 2.69 GHz
机带	RAM 16.0 GB (15.7 GB 可用)
设备 ID	EC7F63BD-5158-4686-AD93-E50F8ECADEAA
产品 ID	00342-36273-37396-AAOEM
系统类型	64 位操作系统, 基于 x64 的处理器

1.5.2 软件环境

分类	名称
数据库	Navicat Premium 15
编译器	IntelliJ IDEA 2020.3.4 x64
浏览器	Microsoft Edge浏览器

1.6本次实验小结

本次实验围绕“面向对象分析与设计”课程中的软件需求分析展开，通过对学生成绩管理系统的业务场景进行深入剖析，明确了系统涉及的三类核心用户（学生、教师、教务处）及其各自的功能需求。在用例分析阶段，详细描述了包括“修改学生成绩”“查询学分”“录入学生成绩”等关键用例的前置条件、基本流程、替代流程及实现约束，为后续系统建模奠定了坚实基础。同时，通过识别非功能性需求（如硬件配置、开发环境），进一步确保了系统设计的可行性与实用性。整体而言，本次实验有效锻炼了从现实业务到软件需求的抽象转化能力，强化了对用例驱动开发方法的理解与应用。

实验二领域模型

2.1 概念类分析

2.1.1修改成绩用例概念类分析

修改成绩用例概念类分析，如表2-1所示。

表2-1 修改成绩用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息

2.1.2 查询挂科科目用例概念类分析

查询挂科科目用例概念类分析，如表2-2所示。

表2-2查询挂科科目用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息

2.1.3录入成绩用例概念类分析

录入成绩用例概念类分析，如表2-3所示。

表2-3 成绩录入用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息

2.1.4 学业预警用例概念类分析

学业预警用例概念类分析，如表2-4所示。

表2-4学业预警用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息
学业预警单	颜色，挂科数

2.1.5查询学分用例概念类分析

查询学分用例概念类分析，如表2-5所示。

表2-5 学分查询用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息
学分	数字

2.1.6 查询成绩用例概念类分析

查询成绩用例概念类分析，如表2-6所示。

表2-6 查询成绩用例概念类分析

名词	属性
教师	姓名，科目，教工号，课程
学生	姓名，班级，学号，性别
课程	科目，编号，学分
成绩	科目，分数
学生列表	序号，学生信息

2.2 领域模型（概念类图）

2.2.1 修改成绩用例领域模型

2.2.2 录入成绩用例领域模型

2.2.3 查询挂科科目用例领域模型

2.2.4 学业预警用例领域模型

2.2.5 查询成绩用例领域模型

2.2.6 查询学分用例领域模型

2.3 系统领域模型

2.4 本次实验小结

本次实验通过深入分析成绩管理系统中的多个用例，包括修改成绩、查询挂科科目、录入成绩、学业预警、查询成绩和查询学分等，识别并定义了各个用例中的核心概念类及其属性。我们发现，尽管不同用例的功能各异，但它们共享许多相同的核心概念类，如教师、学生、课程和成绩等，这表明在设计系统时应重视这些基础实体的设计与实现，以确保系统的稳定性和扩展性。此外，通过构建领域模型（概念类图），不仅帮助我们更清晰地理解各用例间的内在联系和数据流动方式，而且为后续的系统设计和开发提供了宝贵的指导。本次实验强化了我们对领域驱动设计的理解，即通过专注于业务领域的核心概念来指导软件开发过程，从而提高软件质量和开发效率。同时，我们也认识到了在实际应用中灵活运用面向对象分析方法的重要性，这将有助于我们在未来的项目中更好地捕捉用户需求，并转化为有效的软件解决方案。

实验三软件设计

3.1 成绩录入用例详细设计

3.1.1 成绩录入用例顺序图

成绩录入用例顺序图如图3-1所示。

图3-1 成绩录入用例顺序图

3.1.2 成绩录入用例类图

模块名	类名	说明
成绩录入	Teacher	教师类，信息从教师信息文件提取
	Frame	录入成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Result	主要用于成绩例如系统的各种方法的实现，具体有成绩录入，文件读取保存，显示信息等
	graed	课程类，信息从课程文件地区
	controller	控制器类，起协调作用
	grade	成绩类，从成绩文件信息提取，其中可以判断成绩的格式

成绩录入用例类图如图3-2所示。

图3-2 成绩录入用例类图

3.2 成绩查询用例详细设计

3.2.1 成绩查询用例顺序图

成绩查询用例顺序图如图3-3所示。

图3-3 成绩查询用例顺序图

3.2.2 成绩查询用例类图

模块名	类名	说明
成绩查询	student	学生类，信息从学生信息文件提取
	Interface	查询成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Graed_list	主要用于成绩例如系统的各种方法的实现，具体有文件读取保存，显示成绩等
	Teacher	教师类，信息从教师信息文件地区
	Controller	控制器类，起协调作用
	Grade_note	成绩单类，从成绩文件信息提取

成绩查询用例类图如图3-4所示。

图3-4 成绩查询用例类图

3.3成绩修改审核用例详细设计

3.3.1 成绩修改审核用例顺序图

成绩修改审核用例顺序图如图3-5所示。

图3-5 成绩修改审核用例顺序图

3.3.2 成绩修改审核用例类图

模块名	类名	说明
成绩修改审核	Teacher	教师类，信息从教师信息文件提取
	Frame	查询成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Grade_list	主要用于成绩例如系统的各种方法的实现，具体有申请单的显示，读取，记录的备份等
	Administrator	管理员类，信息从管理员信息文件地区
	Controller	控制器类，起协调作用
	Grade_note	成绩单类，从成绩文件信息提取

成绩修改审核用例类图如图3-6所示。

图3-6 成绩修改审核用例类图

3.4 查询学分用例详细设计

3.4.1 查询学分用例顺序图

查询学分用例顺序图如图3-7所示。

图3-7 学分查询用例顺序图

3.4.2 查询学分用例类图

模块名	类名	说明
查询学分	Student	学生类，信息从学生信息文件提取
	Interface	查询成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Grade_list	主要用于成绩例如系统的各种方法的实现，具体有申请单的显示，读取，记录的备份等
	Administrator	管理员类，信息从管理员信息文件地区
	Controller	控制器类，起协调作用
	graed	学分类，从成绩文件信息提取

查询学分用例类图如图3-8所示。

图3-8 查询学分用例类图

3.5 学业预警用例详细设计

3.5.1 学业预警用例顺序图

学业预警用例顺序图如图3-9所示。

图3-9 学业预警用例顺序图

3.5.2 学业预警用例类图

模块名	类名	说明
学业预警	Student	学生类，信息从学生信息文件提取
	Interface	查询成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Schoolwork	主要用于成绩例如系统的各种方法的实现，具体有申请单的显示，读取，记录的备份等
	Administrator	管理员类，信息从管理员信息文件地区
	Controller	控制器类，起协调作用
	grade	成绩类，从成绩文件信息提取

学业预警用例类图如图3-10所示。

图3-10 学业预警用例类图

3.6 成绩修改用例详细设计

3.6.1 成绩修改用例顺序图

成绩修改用例顺序图如图3-11所示。

图3-11 成绩修改用例顺序图

3.6.2 成绩修改用例类图

模块名	类名	说明
成绩修改	Frame	查询成绩界面前端显示，主要用于界面之间的显示跳转关闭
	Grade_list	主要用于成绩例如系统的各种方法的实现，具体有申请单的显示，读取，记录的备份等
	Teacher	教师类，信息从教师信息文件地区
	Controller	控制器类，起协调作用
	graed	成绩类，从成绩文件信息提取

成绩修改用例类图如图3-12所示。

图3-12 成绩修改用例类图

3.7 系统类图

3.8 本次实验小结

本次实验通过对成绩管理系统中多个关键用例的详细设计，包括成绩录入、查询、修改审核、学分查询、学业预警以及成绩修改等功能模块的设计与实现，深化了我们对软件设计过程的理解。通过绘制顺序图和类图，明确了各功能模块内部及其相互之间的交互流程和结构关系，不仅提升了我们在实际项目中运用面向对象设计方法解决具体问题的能力，也为后续的系统开发提供了清晰的设计蓝图。同时，强调了控制器类在协调不同模块间工作的重要性，确保了系统的高内聚低耦合，为构建一个灵活、可扩展的成绩管理系统奠定了坚实的基础。此外，通过本次实验，我们也认识到了数据一致性和安全性在成绩管理系统中的重要性，这将指导我们在未来的工作中更加注重这些问题。

结构化分析与设计

实验四成绩管理系统需求分析

4.1 系统相关者

学生、教师、系统管理员。

4.2 数据流分析

（1）顶层DFD

成绩管理系统顶层数据流图如图4-1所示。

图4-1 成绩管理系统顶层DFD

（2）功能层DFD如图4-2所示。

图4-2 功能层DFD

（3）细节层DFD

录入成绩层的细节层如图4-3所示。

图4-3 录入成绩层DFD分解

修改成绩层DFD分解层如图4-4所示。

图4-4 修改成绩层DFD分解

查询成绩层DFD分解层如图4-5所示。

图4-5 查询成绩层DFD分解

4.3 数据字典

（1）数据项定义

姓名的数据项定义如表4-1所示。

表4-1 数据项“姓名”的条目

数据项名：姓名

别名：用户姓名

取值范围及含义：2{汉字}5

备注：代表的是用户姓名

学号的数据项定义如表4-2所示。

表4-2 数据项“学号”的条目

数据项名：学号

别名：学生学号

取值范围及含义：“0000 001”..”9999 999”

备注：代表的是学生唯一识别学号

密码的数据项定义如表4-3所示。

表4-3 数据项“密码”的条目

数据项名：密码

别名：用户密码

取值范围及含义：2{字符}10

备注：代表用户登录的密码

入学时间的数据项定义如表4-4所示。

表4-4 数据项“入学时间”的条目

数据项名：入学时间

别名：入学年份

取值范围及含义：年+月+日

备注：代表的是学生入学的时间

（2）数据流定义

学生信息的数据流定义如表4-5所示。

表4-5 数据流“学生信息”的字典条目

数据流名：学生信息

别名：学生基本信息

数据流的来源：教师、学生、系统管理员、加工2.1审核信息

数据流的去向：加工2.1审核信息、加工2.2修改信息、加工3.1检查学生信息合法性

数据流组成：{学号+姓名+密码+入学时间}

备注：学生基本信息

学生成绩的数据流定义如表4-6所示。

表4-6 数据流“学生成绩”的字典条目

数据流名：学生成绩

别名：学生成绩详情

数据流的来源：教师、加工1.1检查成绩合法性、加工3.3检验用户身份

数据流的去向：加工1.1检查成绩合法性、加工1.2录入成绩、加工3.4统计成绩、加工3.5筛选挂科科目

数据流组成：{学生id + 平时分 + 期中考试分 + 期末考试分 + 总成绩 + 考试卷子详情}

备注：学生成绩详情

（3）数据存储

学生信息表如表4-7所示。

表4-7 数据存储“学生信息表”的字典条目

数据存储名称：学生信息表

编号：F1

简述：是存储学生个人基本信息的明细表

流入的数据流：加工2.1审核信息

流出的数据流：加工2.1审核信息、加工3.1检查学生信息合法性

数据流组成：{学号+姓名+密码+入学时间}

备注：学生基本信息表

学生成绩表如表4-8所示。

表4-8 数据存储“成绩信息表”的字典条目

数据存储名称：成绩信息表

编号：F2

简述：是通过过学生基本信息统计学生成绩的明细表

流入的数据流：来源于教师成绩的录入

流出的数据流：去向是用户查询、统计、修改成绩

数据流组成：{学生id+(姓名)平时分+期中考试分+期末考试分+总成绩+考试卷子详情}

备注：学生成绩信息表

4.5 加工逻辑

（1）加工1.1检查成绩合法性的加工逻辑

输入学生成绩

检索“成绩信息表”文件上的学生成绩，获得成绩信息表中的成绩，判断输入的成绩精度是否与成绩信息表一致。

Begin

如果成绩不合法

则需要教师重新输入成绩

否则

退出录入成绩系统

End

（3）加工1.2录入成绩的加工逻辑

Begin

如果成绩合法

则将学生成绩插入到”成绩信息表中”

否则

系统提示成绩不合法

End

4.6 软件非功能需求

4.6.1 硬件需求

设备1
处理器	11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
机带	RAM 16.0 GB (15.6 GB 可用)
设备ID	3A4EBDEE-3DD2-4436-A128-8608A0AEE925
产品 ID	00342-36262-33467-AAOEM
系统类型	64 位操作系统, 基于 x64 的处理器
设备2
处理器	11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz 2.69 GHz
机带	RAM 16.0 GB (15.7 GB 可用)
设备 ID	EC7F63BD-5158-4686-AD93-E50F8ECADEAA
产品 ID	00342-36273-37396-AAOEM
系统类型	64 位操作系统, 基于 x64 的处理器

4.6.2 软件需求

分类	名称
数据库	Navicat Premium 15
编译器	IntelliJ IDEA 2020.3.4 x64
浏览器	Microsoft Edge浏览器

4.7 本次实验小结

本次实验通过对成绩管理系统进行详细的需求分析，涵盖了从系统相关者的确定到数据流分析、数据字典的定义，再到加工逻辑和非功能需求的明确等多个方面。我们首先识别了系统的主要参与者，包括学生、教师和系统管理员，并通过数据流图（DFD）对系统的顶层结构、功能层以及细节层进行了全面剖析，从而清晰地展现了成绩管理系统的数据处理流程和各组件之间的交互关系。此外，通过数据字典明确了系统中涉及的数据项、数据流及数据存储的具体定义，确保了数据的一致性和准确性。加工逻辑部分则进一步规范了成绩录入与审核的具体操作流程，为后续的程序开发提供了明确指导。最后，针对硬件和软件的非功能需求进行了详细的规划，为系统的实现奠定了坚实的基础。通过这次实验，我们不仅深化了对成绩管理系统设计的理解，还提升了在实际项目中应用需求分析技术的能力。

实验五成绩管理系统设计

5.1 软件结构设计

将功能层数据流图化分边界，如图5-1所示。

图5-1划分边界的数据流图

按SD方法将数据流图转换为软件结构图，如图5-2所示。

图5-2 功能层的SC图

录入层SC图，这一层的数据流图为变换型，画分边界的DFD如图5-3所示。

图5-3 化分边界的录入层DFD

根据化分边界的DFD画出的SC图如图5-4所示。

图5-4 录入层的SC图

其中：

OC1为获取操作命令

D1为学生成绩

D2为合法学生成绩

D3为响应结果

修改成绩层的SC图这一层的数据流图为变换型，画分边界的DFD如图5-5所示。

图5-5 化分边界的修改成绩的DFD

根据化分边界的DFD画出的SC图如图5-6所示。

图5-6修改成绩层的SC图

其中：

OC2为获取操作命令

OC3为请求修改成绩

D1为学生信息

D2为有效学生信息

D3为同意请求

D4为学生成绩

5.2 详细设计-程序流程图

（1）录入成绩程序流程图，如图5-7所示。

图5-7 录入成绩流程图

（2）修改成绩程序流程图，如图5-8所示。

图5-8 修改成绩流程图

5.3 本次实验小结

本次实验主要围绕成绩管理系统的软件结构设计与详细设计展开，通过将数据流图转换为软件结构图（SC图），并进一步细化到程序流程图的设计过程，深入理解了结构化设计（SD）方法在实际软件开发中的应用。实验中，我们首先分析了功能层、录入层以及修改成绩层的数据流图，并据此绘制了相应的软件结构图，明确了各个模块之间的关系和数据流动方向。接着，通过具体的程序流程图设计，如录入成绩和修改成绩的流程，我们掌握了如何从系统层面逐步细化至具体程序逻辑的设计思路。此次实验不仅增强了对软件开发过程中不同设计阶段的理解，还提升了将理论知识应用于实践的能力，为今后参与更复杂的软件项目奠定了坚实的基础。

若觉得有帮助，欢迎点赞关注，一起成长进步~
声明：本文仅供学习交流，禁作商用；禁篡改、歪曲及有偿传播，引用需标明来源。侵权必究。