简介《学生成绩管理系统软件结构图》是一份面向软件工程课程设计、系统分析与设计学习者的结构图文档适合正在完成课程作业、撰写设计报告或梳理成绩管理模块划分的读者参考。压缩包内共1个docx文件约235KB集中呈现软件功能层次图、以数据为中心的体系结构、数据流图以及教师服务子系统和学生服务子系统结构图便于按章节对照理解模块关系。已有5765人学习说明其在同类课程资料中具有一定参考价值。文档围绕身份验证、成绩录入查询、排序处理、统计分析与系统初始化等模块展开可帮助读者掌握从需求分析到软件结构图绘制的表达方式并用作报告插图、结构梳理和设计思路借鉴。1. 学生成绩管理系统软件结构图画不出来问题往往不在代码很多人做学生成绩管理系统的课设代码能跑、登录能进、成绩能查可一到要交软件结构图这一步就卡住了功能层次图上列出的模块软件结构图里找不到对应数据流图里画的数据存储数据库表里没有对应字段教师端和学生端画得像两份不同的系统。答辩时被问一句“这个模块扇入是几、为什么放在这一层”就答不上来。这套方案要解决的其实只是从需求分析到四张图的完整推演路径即“怎么让需求条目、数据流、模块调用三层彼此对得上”这个问题并非“怎么写出一个能跑的系统”。它适合正在做软件工程课设、需要交一整套结构设计文档的人也适合接手一个以数据为中心的管理系统、想先把结构拆干净再动手写代码的开发者。2. 功能层次图教师与大学生的权限边界怎么划功能层次图是第一张要交的图也是最容易被判“层级混乱”的一张。它只回答一个问题这个系统由哪些功能组成、这些功能怎么分层归属。它不涉及调用顺序也不涉及数据怎么流动。很多人画错是因为把后面结构图的模块调用关系提前塞了进来结果图上出现了“查询成绩调用排序成绩”这种带方向的箭头。功能层次图通常用树形结构表达父节点是上层功能子节点是它的细化同一层节点之间是并列关系不表达先后。2.1 需求条目到功能分解的三层落法拿到需求文字后先不要急着画矩形框。我的习惯是逐句把需求拆成“角色 动作 对象”的短句再往上归并。成绩管理系统的需求大致能拆出这么几条教师输入账号密码登录系统验证身份无效提示原因学生输入账号密码登录系统验证身份无效提示原因教师按学号插入学生信息和成绩教师按学号查询学生信息和成绩教师对成绩做排序处理教师横向比较、分析学生成绩学生按学号查询本人信息和成绩学生查看本人成绩的排序结果与自身统计系统启动时完成运行环境搭建系统向不同角色展示对应菜单这十条落到功能层次图上按“系统级—子系统级—功能级”三层归并。系统级只有一层学生成绩管理系统。子系统级按角色切两块教师服务子系统、学生服务子系统外加一块不属于任何角色的公共支撑身份验证、系统初始化、菜单显示。功能级就是上面每条短句对应的具体动作。三层的好处是粒度自洽子系统级的节点是“给谁用”功能级的节点是“能干什么”两层职责不重叠。这里有一个反直觉的点身份验证不放在子系统里而是提到公共层。原因是教师和学生走的是同一套验证逻辑只是校验后的分支不同。如果把它复制进两个子系统功能层次图上就会出现两个完全相同的子树这在评审里是典型的冗余扣分项。通常的做法是画成公共支撑节点两个子系统通过一条无箭头的归属线挂在它下面表示“共用”。2.2 教师端与学生端的功能差异用一张表压住功能层次图画完紧接着要解释“为什么教师有、学生没有”。这张差异表我每次都会附在图的后面它比图上任何一条线都更能说明设计的合理性。功能点教师端学生端设计依据身份验证支持支持公共模块按角色分流学生信息插入支持不支持学生无建档权限成绩录入支持不支持录入是教师专属写操作成绩查询任意学号仅本人学号数据范围由登录态决定成绩排序按课程、班级仅本人成绩序列学生端不需要横向对比成绩分析平均分、及格率、分段分布本人总分、均分、排名分析维度不同共用统计内核系统初始化不感知不感知启动阶段执行角色无感菜单显示教师菜单学生菜单菜单项由角色动态生成表格里“数据范围由登录态决定”这一行很关键它把权限控制从“功能有没有”变成了“同一功能的数据边界不同”。这样做的好处是功能层次图上教师端和学生端可以共用“成绩查询”这个功能节点只是标注不同的数据范围图面干净也不会被质疑“两个子系统为什么长得一模一样”。2.3 层级判定的三个自查问题功能层次图画完拿这三个问题过一遍基本能挡住大部分返工。第一每个叶子节点是不是一个可独立测试的动作。“成绩管理”不是叶子它下面还得拆出插入、查询、修改“成绩查询”是叶子因为它对应一次完整的输入输出。如果叶子上出现“处理”“管理”“操作”这类词说明粒度还不够细。第二有没有跨层调用。父节点直接调用孙节点、或者孙节点反向调用父节点都会让层级失效。系统初始化归公共层它只负责建连接、加载配置、初始化菜单不参与任何成绩业务一旦它去调成绩查询整棵树就乱了。第三同一层节点的粒度是否一致。“成绩管理”和“成绩排序”并列是错的前者是集合后者是子集。要么都写成“成绩插入”“成绩查询”“成绩排序”要么统一收在“成绩管理”之下。这个错误在课设里出现频率极高答辩时几乎必被点出来。把这三条落到图上功能层次图的骨架大致是根节点下挂三个分支教师服务子系统下挂身份验证入口、学生信息维护、成绩录入、成绩查询、成绩排序、成绩分析、菜单展示学生服务子系统下挂身份验证入口、个人信息查询、本人成绩查询、本人成绩排序、个人统计、菜单展示公共支撑下挂系统初始化、数据库连接、日志记录。到这里第一张图才算立住。3. 数据为中心的体系结构数据流图为什么要用事务分析功能层次图解决“有什么”软件体系结构解决“靠什么串起来”。成绩管理系统的特点很明确教师录、学生查两边操作的是同一份成绩数据业务逻辑之间几乎没有直接调用关系。插入成绩不需要通知查询模块查询也不依赖排序模块的执行结果。所有模块围绕同一份数据存储协调工作这就是典型的以数据为中心的体系结构。它的优点是模块之间松耦合新增一个“成绩导出”模块时不用改任何已有模块只要它能读这张表就行代价是数据模型必须先设计稳定一旦成绩表的粒度变了所有模块都得跟着改。所以后面的数据流图和表结构必须一次对齐。3.1 从顶层数据流到事务分支的分解数据流图要分层画。顶层图只有三个元素外部实体教师、学生、加工学生成绩管理系统、数据存储成绩库。教师和学生分别向系统提交登录凭证和业务请求系统返回结果。这一层不展开任何内部细节。到了 0 层就要引入身份验证这个环节了。原文在这里做了一个很关键的处理在原有数据流之上增加用户身份验证然后对关联图做细化和修改。这一步的实质是把“一个入口”改成“带分支的入口”也就是事务分析。事务分析适用于数据流图里存在一个明显的事务中心它根据输入数据的类型选择一条处理路径。在这个系统里验证模块就是事务中心它接收登录请求判断角色然后分派到教师处理路径或学生处理路径。两条路径后续互不交叉直到最后写回同一份数据存储。用文字描述这个 0 层图的结构是这样的加工 P1 身份验证输入为登录请求账号、密码、角色声明输出为验证结果和角色标识加工 P2 教师业务处理输入为教师请求和角色标识访问学生信息存储与成绩存储输出教师视图数据加工 P3 学生业务处理输入为学生请求和角色标识只读访问成绩存储输出学生视图数据数据存储 D1 学生信息表、D2 成绩表、D3 用户表数据流登录请求 → P1P1 的验证结果 → P2 或 P3二选一这是事务分支P2 ↔ D1/D2P3 → D2单向读需要强调的是数据流图里不要出现判断菱形和循环箭头。事务分支在 DFD 里表现为同一个加工的多条输出流各自标注条件而不是流程图的控制结构。把 DFD 画成流程图的是课设里第二常见的翻车点评审一眼就能看出来。3.2 数据字典与表结构的对齐图上的每一个数据存储和数据流都要在数据字典里有条目并且能落到具体的表字段。成绩管理系统的最小表集合是四张学生表、课程表、成绩表、用户表。下面这段建表语句可以直接拿去改字段顺序和命名我都按数据流的方向排过。-- 学生成绩管理系统核心表结构与数据流图中的 D1/D2/D3 一一对应 CREATE TABLE student ( stu_id VARCHAR(12) PRIMARY KEY, -- 学号同时是查询入口参数 stu_name VARCHAR(32) NOT NULL, class_id VARCHAR(16) NOT NULL, -- 班级教师端排序和统计的分组依据 major VARCHAR(32) ); CREATE TABLE course ( course_id VARCHAR(12) PRIMARY KEY, course_name VARCHAR(48) NOT NULL, credit DECIMAL(3,1) NOT NULL ); CREATE TABLE score ( stu_id VARCHAR(12) NOT NULL, course_id VARCHAR(12) NOT NULL, score DECIMAL(5,1) CHECK (score BETWEEN 0 AND 100), term VARCHAR(16) NOT NULL, -- 学期区分同一门课的多次修读 PRIMARY KEY (stu_id, course_id, term), FOREIGN KEY (stu_id) REFERENCES student(stu_id), FOREIGN KEY (course_id) REFERENCES course(course_id) ); CREATE TABLE sys_user ( user_id VARCHAR(12) PRIMARY KEY, -- 教师工号或学生学号与业务表同源 password VARCHAR(64) NOT NULL, -- 存加盐哈希不落明文 role CHAR(1) NOT NULL CHECK (role IN (T,S)) -- T 教师S 学生 );几点说明。第一score 表用(stu_id, course_id, term)做联合主键而不是另加自增 id原因是“一个学生一门课一学期只有一条成绩”这条业务约束本身就是主键用联合主键可以省掉一次唯一性校验也让数据流图上“按学号查询”能直接走主键索引。第二score 表不加冗余的姓名和课程名字段展示时靠连接查询取避免数据流图上出现两个来源的同一数据。第三sys_user 的 role 字段是事务分析的物理落点P1 加工判断角色时读的就是它不用去两张业务表里猜身份。第四成绩字段加了 0 到 100 的检查约束这条约束在数据字典里要写成“成绩取值范围 0 到 100越界由 DBMS 拒绝”不要写成“由程序判断”。把校验放在数据库层是让数据流图上的加工不必重复承担校验职责图面会更干净。3.3 数据流图与表结构的双向校验画完图和表做一次双向校验能省掉答辩现场一半的追问。正向看每一条数据流它的组成项能不能在表字段里找到落点。比如“成绩查询请求”的组成是学号加学期对应 score 表的 stu_id 和 term能找到通过“教师分析请求”如果只写了课程号却要输出分段分布那就得再补一个学期参数否则同一门课多个学期的成绩会混在一起统计。反向看每一张表的每个非空字段是不是至少有一条数据流会写入它。class_id 由学生信息插入流写入通过如果某张表里有个字段既不被任何流写入也不被任何流读取那它就是冗余字段要么删掉要么在图上补一条流说明它的来源。这个校验做下来通常会暴露两类问题一类是图上画了但表里没建的存储另一类是表里建了但图上没画的数据流。前者补建表后者要么补流要么删字段二选一不要留着。我一般会在文档里附一张对照表左边是数据流名右边是涉及的表和字段一眼就能看出哪里断了。4. 软件结构图从数据流图映射到模块调用关系软件结构图也叫 SC 图是四张图里唯一直接对应代码组织方式的一张。它由模块、调用关系、数据信息和控制信息构成衡量指标是扇入、扇出、深度和宽度。从数据流图到结构图的映射有两条路变换分析适合“输入—处理—输出”串行的部分事务分析适合“根据类型分流”的部分。这个系统两种都要用身份验证之后是按角色分流的属于事务型进入各自子系统后成绩录入、查询、排序、分析是围绕数据的串行加工属于变换型。4.1 变换映射与事务映射的分工先处理事务部分。数据流图上的事务中心是身份验证结构图上对应的就是一个调度模块它接收登录信息校验然后调用教师主控或学生主控。这个模块的扇出是 2扇入是 1由顶层主控调用职责单一不带任何业务逻辑。再处理变换部分。以教师端为例从数据流上能识别出三段输入段接收学号、课程号、成绩值、变换中心写入成绩、计算统计量、输出段格式化展示。映射到结构图上是三层教师主控负责协调下面挂录入、查询、排序、分析四个业务模块再下面挂一个公共的数据访问模块。这里要特别注意数据访问模块的扇入会很高四个业务模块都要调它。扇入高本身不是坏事它意味着复用充分真正要控制的是扇出一个模块直接调用的下级模块不要超过七个超过就说明它承担的职责太多需要拆。结构图的深度和宽度也要看一眼。这个系统合理的深度是四层顶层主控 → 角色主控 → 业务模块 → 数据访问再加一层叶子级的工具函数就是五层。如果画出来只有两层说明分解不足如果超过六层多半是中间加了没有实际职责的转发模块这种模块在评审里叫“空壳模块”是扣分项。4.2 教师服务子系统的模块划分与接口定义把教师端拆成模块每个模块给出编号、职责、输入、输出和扇入扇出这张表比图更耐看也方便后面写代码时对号入座。编号模块名职责输入输出扇入扇出M1系统主控初始化、调度角色主控启动信号主界面12M2身份验证校验账号密码返回角色账号、密码角色标识、提示21M3教师主控接收教师指令并分派角色标识、菜单指令业务结果14M4成绩录入按学号写入或更新成绩学号、课程号、分数、学期写入结果11M5成绩查询按条件检索成绩记录学号或课程号、学期成绩记录集21M6成绩排序对记录集排序记录集、排序键有序记录集11M7成绩分析计算均分、及格率、分段分布课程号、学期统计结果11M8数据访问统一封装增删改查SQL 参数结果集40M8 的扇入是 4说明它是这个子系统里复用最充分的模块也意味着它一旦出问题四个业务模块全挂。所以数据访问模块要做两件事参数化查询禁止拼字符串统一异常转换把数据库异常翻译成业务层能识别的错误码。这两件事写在结构图下面的注释里评审看了会加分。对应的接口骨架大致如下函数名和表里的模块名一一对应参数里凡是带operator_id的都是为了在业务层做一次数据范围校验# 教师服务子系统接口骨架一个函数对应结构图上的一个业务模块 def verify_user(user_id: str, password: str) - dict: M2 身份验证返回 {ok: bool, role: T/S, msg: str} def insert_score(operator_id: str, stu_id: str, course_id: str, score: float, term: str) - bool: M4 成绩录入operator_id 用于确认调用者具备教师角色 def query_score(operator_id: str, stu_id: str None, course_id: str None, term: str None) - list: M5 成绩查询教师可传任意学号参数为空表示按课程批量查 def sort_score(records: list, key: str score, reverse: bool True) - list: M6 成绩排序稳定排序同分时保持原始录入顺序 def analyze_score(course_id: str, term: str) - dict: M7 成绩分析返回均分、最高分、最低分、及格率、分段人数参数设计上有两个点值得说。第一query_score的学号做成可选参数教师不传学号就按课程批量查这是教师端“整体宏观比较”的需求落点如果做成必填教师想看全班分布就得循环调用接口和需求对不上。第二sort_score接收的是记录集而不是查询条件排序和查询彻底解耦这样学生端也能复用同一个排序模块只是传进去的记录集不同。这就是结构图上“扇入”设计的实际价值复用不是靠复制代码而是靠把模块的输入抽象成数据本身。4.3 学生服务子系统的裁剪与公共模块复用学生端的功能是教师端的子集但直接复用会带来一个隐蔽的越权问题。假设学生端也调query_score而这个函数接受外部传入的学号那么只要改一下请求参数学生就能查到别人的成绩。这类问题在课设里不一定会被发现但一旦被问到“你怎么保证学生只查到自己的”答不上来就很难看。我的处理方式是在学生端加一层薄封装把学号来源从“外部传参”改成“登录态取值”# 学生服务子系统不新增业务模块复用公共模块并收紧数据范围 def student_query_score(operator_id: str, term: str) - list: # 学号直接取自登录态函数签名里根本不给外部传学号的机会 return query_score(operator_id, stu_idoperator_id, termterm) def student_view_rank(operator_id: str, course_id: str, term: str) - dict: # 先查本人成绩再在课程范围内算排名排名只返回名次不返回他人明细 mine query_score(operator_id, stu_idoperator_id, termterm) return build_rank_view(course_id, term, mine)这段代码的价值不在实现而在它体现的结构决策学生端在结构图上不新增独立模块只增加一个“范围约束”层。反映到 SC 图上就是学生主控的扇出比教师主控少且所有业务调用最终都汇入同一个数据访问模块。好处是公共逻辑只有一份改一处全生效代价是每次调用都要多一次角色校验性能上有微小开销。对成绩管理这种数据量在万级以内的系统这点开销可以忽略但如果哪天要扩到全校十几万条记录就该考虑把角色校验提到数据访问层统一拦截。5. 避坑与排查结构图文档里五个高频翻车点结构设计文档不像代码跑不起来会报错它的问题往往要到答辩现场才暴露。下面这五条是我见过的、也是自己踩过的按“现象—原因—解决”写照着排查一遍能省不少返工。5.1 功能层次图和软件结构图画成了同一张现象两张图几乎一样都是树形都有“成绩查询”“成绩排序”这些节点只是箭头画法略有差别。原因没分清两张图的语义。功能层次图表达的是“系统具备哪些功能、怎么分层归属”节点之间是组成关系软件结构图表达的是“模块之间谁调用谁、传什么数据”节点之间是调用关系还带数据信息和控制信息。解决功能层次图上不出现任何带方向的调用箭头同一层节点互不调用软件结构图上必须有调用箭头箭头上标注数据流名称模块旁标注编号。最省事的验证办法是把结构图上的每个模块名念一遍如果念出来是“查询成绩”这种动宾短语说明它更像功能而非模块模块名应该是“成绩查询模块”这种名词性结构并且能在代码里找到一个函数或类与之对应。5.2 数据流图里混进了判断和循环现象图上出现菱形判断框、回到上一步的循环箭头甚至画出了“输入错误则重新登录”的回环。原因把 DFD 当成了流程图。DFD 描述的是数据流动和加工不描述控制流程和执行顺序分支在 DFD 里表现为同一个加工的多条输出流各自标注条件而不是判断符号。解决删掉所有菱形和回环。事务分支改成从一个加工引出两条带条件标注的数据流比如“验证通过教师”“验证通过学生”“验证失败”三条流其中失败流指向一个提示加工提示加工只输出信息、不写数据存储。如果确实需要表达“重新输入”那属于界面交互不该出现在 DFD 层放到模块实现里说就行。5.3 漏掉系统初始化和菜单显示主控模块悬空现象结构图顶层的主控模块下面没有可调用的下级或者下级直接就是业务模块启动过程无处安放。原因只盯着业务功能忘了非功能性模块。系统要连数据库、要读配置、要按角色渲染菜单这些都是实实在在的模块漏了它们结构图在启动阶段就是断的。解决在公共支撑层补两个模块——系统初始化和菜单显示。初始化模块负责建立连接、加载配置、检查表结构扇出指向数据访问模块菜单显示模块接收角色标识返回对应菜单项被教师主控和学生主控共同调用所以它的扇入是 2。补完之后再检查一遍从顶层主控出发能不能沿调用链走到每一个叶子模块走不到的就是悬空模块。5.4 扇出失控一个模块挂十几个下级现象某个主控模块下面直接挂了录入、查询、排序、分析、导出、打印、备份、权限、日志一大串图面像把扇子。原因把“主控”当成了万能入口所有请求都从它分派。扇出过大意味着这个模块的职责不单一任何新功能都要改它违反开闭原则。解决按角色或按业务域二次分解。教师主控的合理扇出是四到五超出的部分先归并成组比如把导出、打印合并成“报表输出”再由它往下分。经验值是单个模块扇出控制在七以内超过就拆一层中间主控。拆的时候注意别拆出空壳模块——如果一个中间模块只是原样转发调用、不加工任何数据那就不要拆宁可让上级多一个扇出。5.5 学生端直接复用教师端查询越权却查不出来现象功能上一切正常学生登录后也能查到成绩测试时用自己的账号试也没问题。原因测试只用了本人账号没试过篡改参数。学生端如果直接调用了接受外部学号的查询接口把请求里的学号改成别人的就能拿到他人成绩。解决在学生端和公共查询模块之间加一层范围约束学号从登录态取函数签名里不暴露这个参数同时在数据访问层加一条规则凡是学生角色的查询SQL 必须带stu_id 当前登录学号的条件两个条件同时成立才放行。验证方法是构造三条用例查本人应成功、查他人应拒绝、不传学号应拒绝。这三条过了才算真正测过。6. 验收与答辩用一张“图—表—码”对照清单自证设计成立结构设计文档的验收标准其实很朴素别人拿着你的图能不能不问你一句话就把系统搭起来。答辩现场最有效的自证方式是准备一张三列对照表左列是图上的元素中列是对应的数据表或字段右列是对应的代码位置。评审随手点一个模块你能在三秒内指出它落在哪张表、哪个函数可信度立刻不一样。图纸元素数据结构落点代码落点检查方法功能层次图叶子节点无直接对应每个叶子对应一个函数数叶子数和函数数是否一致数据流图数据存储student / score / sys_user数据访问模块每个存储能否找到建表语句数据流图数据流字段组合函数入参与返回值每条流能否找到字段来源SC 图模块无直接对应类或函数模块编号与函数注释是否对齐SC 图调用箭头无直接对应函数内部调用扇出是否与代码实际调用数一致这张表我建议在答辩前一晚逐行过一遍尤其是最后一行。图上的扇出是 4代码里实际调了 6 个函数这种不一致一旦被翻出来前面所有图的严谨性都会被打折扣。反过来如果你能主动说“这里图上标 4实际代码里多调了一个日志模块因为日志不算业务模块我在图里合并到公共支撑了”这就是加分项说明你想过边界。还有一个小技巧准备一页“变更记录”。结构设计不是一次成型的数据流图从初版到加了身份验证、结构图从三层拆到四层这些改动本身就是设计过程的证据。把每次改动的原因写清楚比如“增加身份验证环节因为原始数据流图没有区分角色导致教师和学生共用一条加工路径”比单纯展示最终版更有说服力。评审问“为什么这么设计”时你答的是演进逻辑而不是事后解释。从那以后我每次交结构设计文档都强制走一遍“图—表—码”三向核对图上的每个模块要在表里找到数据落点在代码里找到函数落点三者缺一个就补。这套习惯救过我两次一次是发现数据流图里有个“成绩修改”加工代码里根本没有对应函数另一次是结构图上标了扇入 2 的模块实际只有一个地方调用。希望帮到你。本文还有配套的精品资源点击获取
