从UML建模到数据库设计：高校成绩查询系统课设全流程解析

简介：《信息系统分析与设计课程设计报告》是一份围绕高校成绩查询信息系统开发的完整课程设计文档，适合信息管理与信息系统、计算机等相关专业学生参考。报告以西安理工大学工商管理学院为背景，针对传统成绩公布方式效率低、易出错等问题，给出了系统化的分析与设计方案，内容涵盖设计背景、可行性分析、用例建模、数据库设计、功能结构设计、界面设计与测试方案等完整开发流程，所涉及的用例图、活动图、序列图和类图等建模方法可帮助读者理解信息系统分析与设计的具体实践。

资源为单个doc格式文档，压缩包大小约2.09MB，虽然只有一份文件，但内容体系完整，总页数充足。该文档既可作为课程设计报告的写作范例，也可为成绩管理系统的开发提供需求分析与功能设计参考。目前已有352人学习浏览，对正在完成信息系统课程设计或需要撰写类似报告的学生具有较强参考价值。

1. 一份课程设计报告，看懂高校成绩系统的完整建模流程

期末成绩张贴在教学楼橱窗里，学生挤在玻璃窗前从几十张成绩单里翻找自己班级的那一张，好不容易找到，成绩单可能已经被替换，或者某科成绩因为放假前没录完而查不到——这是西安理工大学工商管理学院曾经的日常。这份《信息系统分析与设计课程设计报告》，就是针对这个真实痛点完成的成绩查询信息系统设计，技术栈是 ASP + VBScript + SQL 2000，覆盖了从可行性分析、UML 用例图/活动图/序列图/类图，到数据库表设计、功能结构设计和系统实施测试的完整流程。如果你正在写信息系统分析与设计课设，或者想学 UML 建模怎么落到实际项目里，这份报告是很好的结构参考和答辩素材。

2. 从张贴成绩单到在线查询：把业务痛点翻译成系统边界

2.1 可行性分析不是走过场：三项检查直接决定课设能不能立项

报告在第二章做了三方面可行性分析：经济可行性、技术可行性、社会可行性。这个顺序是有讲究的。经济可行性先算成本，报告明确指出“西安理工大学工商管理学院已有自己的网站，所以网站建设费用是很小的”，软件开发因为只做成绩查询功能也很小，结论是开发值得。技术可行性部分写得很克制，“程序实现语言是 ASP+VBScript”，并且点出关键难点是“与成绩数据库的连接以及查询功能的实现”。这两个难点判断得很准，ASP 时代连接 SQL 2000 数据库的套路就那么几种，查询逻辑也不复杂，技术路线完全走得通。社会可行性则是从“操作方式符合工作人员和学生的日常习惯”“与国家政策法规无冲突”两个角度论证。

做课设时这三项可行性最后都要落到答辩问题里，最常见的问题是“你的系统为什么不用 Java 而用 ASP”。这时候要回答的不是哪个语言更好，而是“在这个成本约束和团队能力下，ASP 能最快实现需求”。报告里每个可行性结论都带依据，不是空喊“可行”，这一点值得照着写。

2.2 用例图和角色识别：谁是系统的“人”，谁负责哪些事件流

用例分析的起点是角色识别。报告把系统的活动者定为三个：学生、管理员，以及一个很容易被忽略的角色——数据库。这里有一个值得学习的点：数据库在整个系统中虽然不主动操作，但它响应所有事件流，是“提供服务接口”的外部实体，因此在用例建模时被明确列为活动者。很多课设在这一步只画两个角色就完事，数据库角色的缺失会导致序列图和类图里“数据库对象”没有来源，逻辑上站不住。

学生对应的用例有四个：本人成绩查询、本班成绩查询、修改基本信息、修改登录密码。管理员对应的用例有八个：学生成绩的添加、修改、删除、查询，以及学生用户的添加、修改、删除、查询。这里区分得很清楚——成绩是一个用例集，用户信息是另一个用例集，二者不要混在一起画。事件流方面，学生侧限制“不能输入他人学号查询成绩”，管理员侧限制“已存在的成绩不能添加，只能修改删除查询；不存在的成绩不能修改删除查询，只能添加”。这类业务规则属于系统约束，写进用例描述里比画在用例图上更清晰，后续做活动图和功能设计时直接引用。

2.3 活动图里的分支逻辑：A1/A2/A3异常流才是评分重点

报告里的活动图全部采用事件流编号配合分支描述的方式，这个习惯很好。以登录系统活动图为例：用户选择登录模式（管理员或学生）→输入账户密码→验证是否输入完全（A1:未输入完全）→创建用户对象→数据库查询用户名是否存在（A2:用户名不存在）→查询密码→判断密码正确性（A3:密码不正确）→登录成功。严格说这里应该用泳道划分“用户-系统-数据库”三个责任域，但课设报告用事件流编号的方式也能把逻辑讲清楚，属于常见的简化处理。

管理员删除成绩的活动图有一个细节：①输入要删除的成绩基本信息→②判断成绩框中是否为数字（A1:不是数字）。也就是说，删除操作也要先做输入校验，不是直接执行。这个细节体现了“输入合法性检查是一切数据库操作的前置条件”，在后续代码实现里会以 IsNumeric 函数体现出来。活动图的另一个作用是倒推出系统的分支路径数量——每个 A 分支都是一条独立路径，测试方案设计时要把这些路径全部覆盖，报告 5.2.1 的测试方案就是从这些分支展开的。

提示：如果你也在写课设，建议先画活动图再写用例描述。活动图能帮你把正常流和异常流拆干净，用例描述和后续的序列图、测试用例都可以直接复用这些分支编号。

3. 序列图与类图：把对象间的消息传递画明白

3.1 五个类协作：管理员操作背后的对象生命周期

序列图是这门课最容易被扣分的部分，很多同学画出来的序列图其实就是流程图的竖版，完全没有体现“对象间消息传递”。报告里管理员添加学生用户序列图涉及的五个类分别是：管理员、窗体、用户、控制对象、数据库。这条消息链是：管理员输入基本信息→窗体获取信息→创建用户对象→控制对象检查信息合法性→数据库查询用户是否存在→控制对象判断是否可添加→数据库添加用户→窗体显示成功信息→控制对象删除所创建的用户信息。

注意最后一步“控制对象删除所创建的用户信息”——这是对象生命周期的收尾。很多课设序列图里对象画出来就没有销毁动作，答辩时被问“你这个对象什么时候释放”就答不上来。报告在管理员修改学生信息、删除学生用户两组序列图里，消息链和对象销毁步骤完全一致，说明写报告的人已经形成了固定套路：创建对象→校验→查询→操作→反馈→销毁。这个套路可以直接套用到你的课设里，不光是用户管理，成绩管理的序列图也是同构的。

用户查询成绩序列图则是另一种消息模式：用户选择查询方式（按学号或按班级）→输入条件→控制对象检查合法性→判断查询权限→数据库查询→创建成绩列表→窗体显示结果。这里多了一个“检查权限”的步骤，对应业务规则里“学生不能查他人成绩”的约束。序列图的价值在于把“谁发起、谁处理、谁存储”讲清楚，为你后面写代码时的分层调用提供依据。

3.2 系统类图的属性与操作分配：控制类为什么单独存在

报告的系统类图把类分成四组：用户（管理员、学生）、数据库、控制对象、窗体，外加成绩类。属性设计如下：学生的属性是学号、姓名、班级、密码；管理员是账号、密码；数据库是存储路径；成绩是学号、课程编号、学期、分数。操作分配上，窗体的操作全是显示类——显示成绩不存在信息、显示查询结果、显示添加成功/失败、显示修改成功/失败、显示删除成功/失败；数据库的操作全是数据类——查询成绩、删除成绩、修改成绩、检查成绩是否存在、检查用户是否存在、查询密码、查询用户、删除用户、修改用户；控制类的操作全是检查类——检查成绩合法性、检查是否可以删除成绩、检查是否可以添加成绩、检查是否可以修改成绩、检查是否可以查询成绩、检查学生信息合法性。

为什么要单独设一个控制类而不是让窗体直接操作数据库？这是为了把“业务规则校验”从界面逻辑和数据访问逻辑中剥离出来。窗体的职责是输入输出，数据库的职责是存储，那“这个成绩能不能被添加”这种规则判断放哪里？放窗体里，界面代码会越来越臃肿；放数据库里，逻辑散落在 SQL 语句中难以复用。控制类就是中间的规则执行者。对应到代码层面，控制类的方法就对应 ASP 页面里的处理逻辑，比如检查学号是否已存在、判断成绩输入是否为数字等。答辩时你能把这一层讲清楚，比单纯贴代码要加分得多。

4. 数据库逻辑结构设计：六张表定下成绩查询系统的数据底座

4.1 概念结构到逻辑结构：E-R 模型怎么落成 SQL 2000 表

数据库概念结构设计阶段，报告识别出六个实体：学生、管理员、班级、课程、学期、成绩，并给每个实体固定了数据项。学生信息是学号、姓名、班级、密码；班级信息是班级编号、班级、班主任；课程信息是课程编号、课程名称、任课老师；学期信息是学期编号、学期；成绩信息是学号、课程编号、学期编号、成绩；管理员信息是账号、密码。

实体间关系可以推断为：一个学生属于一个班级，一个班级有多个学生；一个班级开设多门课程，每门课程有任课老师；一个学生在某个学期选修某门课程产生一条成绩记录。所以成绩实体是学生、课程、学期三者关联的产物，这也是为什么成绩表要以学号、学期编号、课程编号三个字段作为联合主键。概念结构设计阶段不写字段类型，只确定实体和属性，逻辑结构设计阶段再把这些属性映射为 SQL 2000 的数据类型。

4.2 六张核心表的字段设计与主键策略

逻辑结构设计直接落成六张表，下面按报告里的表结构整理：

这里有两个设计决策值得说明。一是学号用 Char(10) 而不是 Varchar(10)，因为学号是定长 10 位，用 Char 定长类型可以避免变长字段的存储开销和索引效率问题，这是 SQL 2000 时代的常见选择。二是成绩表用学号、学期编号、课程编号三字段联合主键，从业务上保证了“同一学生同一学期同一课程只能有一条成绩记录”，同时这三列分别是学生表、学期表、课程表的主键，天然构成外键关系。物理设计阶段还要为这三个字段建联合索引，否则成绩表数据量上去后，按学号查成绩的查询会全表扫描。

4.3 功能结构设计：管理员和学生看到的界面为什么不同

功能结构设计的核心是权限分流。管理员登录后的功能有成绩管理（添加、删除、修改、查询）和用户管理（添加用户、删除用户、修改用户、查询用户）；学生登录后的功能只有本人成绩查询、本班成绩查询、修改个人信息、修改登录密码、退出系统。管理员可以按班级或学号查询所有学生成绩，学生只能查自己的成绩和本班成绩单。

这里的关键约束在前面用例分析里已经出现了，功能设计阶段又重申一遍：已存在的成绩只能修改、删除、查询，不能添加；不存在的成绩只能添加，不能修改、删除、查询。这个规则直接决定代码里的执行顺序——添加成绩前必须先查是否存在，修改成绩前也必须先查是否存在。对应到 5.1.3 管理员添加学生成绩界面设计，它的核心逻辑就是“先查重再插入”，这一点在避坑章节会细说。

5. 系统实施与测试：登录、查询、录入的关键实现与避坑记录

5.1 用户登录系统界面设计：会话控制与权限分流

报告的 5.1.1 节描述了用户登录系统界面设计，这是整个系统实施的第一块界面。登录页的后端逻辑是 ASP + VBScript，按这个场景下最常见的实现方式，登录验证会拆成两个文件：一个登录表单页，一个处理页。处理页的伪代码如下：

<% @Language="VBScript" CodePage="936" %> <% Dim usertype, userid, userpwd, rs, sql usertype = Request.Form("usertype") ' 获取登录角色：student 或 admin userid = Request.Form("userid") userpwd = Request.Form("userpwd") If userid = "" Or userpwd = "" Then Response.Write "账号和密码不能为空" Response.End End If ' 根据角色拼不同的表和 SQL，避免学生账号直接查管理员表 If usertype = "student" Then sql = "SELECT 学号, 密码 FROM 学生信息表 WHERE 学号='" & userid & "'" Else sql = "SELECT 账号, 密码 FROM 管理员信息表 WHERE 账号='" & userid & "'" End If ' 省略数据库连接和查询代码 ' 如果记录存在且密码匹配，写入 Session 并跳转 Session("userid") = userid Session("usertype") = usertype If usertype = "student" Then Response.Redirect "student_main.asp" Else Response.Redirect "admin_main.asp" End If %>

这段代码的核心是两个校验：第一，账号密码非空判断必须在数据库查询之前做，把无效请求挡在外面；第二，根据 usertype 拼不同的查询表，避免学生账号被拿去查管理员表。SQL 语句里变量直接拼接是 ASP 时代的经典写法，但在实际开发时需要用参数化查询或存储过程来替代，否则容易被注入攻击。

注意：Session("usertype") 这个变量非常关键，后续每一个页面都要读取它来判断访问权限，否则就出现 5.4 里说的“直接改 URL 绕过登录”问题。

5.2 管理员查询与添加成绩界面设计：SQL 拼接与合法性校验

管理员查询成绩界面提供两个查询维度——按班级和按学号。对应的 SQL 写起来不复杂：

-- 按班级查询：先通过班级名称找到该班所有学生，再关联成绩表 SELECT 学生信息表.学号, 学生信息表.姓名, 课程信息表.课程名称, 学期信息表.学期, 学生成绩信息表.成绩 FROM 学生成绩信息表 INNER JOIN 学生信息表 ON 学生成绩信息表.学号 = 学生信息表.学号 INNER JOIN 课程信息表 ON 学生成绩信息表.课程编号 = 课程信息表.课程编号 INNER JOIN 学期信息表 ON 学生成绩信息表.学期编号 = 学期信息表.学期编号 WHERE 学生信息表.班级 = '会计2003' ORDER BY 学生信息表.学号

管理员添加成绩界面的逻辑要更小心，因为报告里明确说了“已存在成绩不能添加”。所以添加成绩的流程是：先按学号、学期编号、课程编号三个字段查询成绩表，如果记录已存在就提示用户改用修改功能，不存在才执行插入：

<% Dim stu_id, term_id, course_id, score, check_sql stu_id = Request.Form("stu_id") term_id = Request.Form("term_id") course_id = Request.Form("course_id") score = Request.Form("score") ' 成绩框必须为数字，非数字直接拦截 If Not IsNumeric(score) Then Response.Write "成绩必须为数字" Response.End End If ' 先查重，再插入，避免联合主键冲突 check_sql = "SELECT COUNT(*) FROM 学生成绩信息表 " & _ "WHERE 学号='" & stu_id & "' AND 学期编号='" & term_id & _ "' AND 课程编号='" & course_id & "'" ' 执行查询，若 count > 0 则提示已存在，否则执行 INSERT If count > 0 Then Response.Write "该学生此学期此课程的成绩已存在，请使用修改功能" Else ' INSERT INTO 学生成绩信息表 (学号, 学期编号, 课程编号, 成绩) VALUES (...) End If %>

两个关键点：IsNumeric(score) 负责类型校验，先查重后插入负责避免复合主键冲突。这两个操作在报告的活动图里都是单独的分支步骤，代码实现时一个不能少。

5.3 测试方案与切换方式设计：模块测试饱和了吗

测试方案设计这块，报告 5.2.1 的思路是从活动图的分支路径入手。每一个 A 分支都是一条异常流测试用例，比如登录系统的 A1（未输入完全）、A2（用户名不存在）、A3（密码不正确），添加成绩的 A1（不是数字）、A2（成绩已存在）、A3（添加不成功）。模块测试覆盖单个活动图的全部分支，集成测试再验证跨模块的数据传递，比如管理员添加完成绩后，学生端能否马上查到这条记录。这样规划测试用例，数量是可以数出来的：每个活动图的正常流 1 条 + 异常流 N 条，全部路径走一遍就是满覆盖。

切换方式设计上，报告提出三种切换方式的比较：直接切换、并行切换、逐步切换。对成绩查询系统来说，最稳妥的是并行切换——新系统上线后，成绩单继续张贴一个学期，同时开放网上查询，等数据验证无误后再停掉橱窗张贴。这是一种保守但安全的切换策略，教务科不会因为系统故障而完全失去成绩公布的渠道。

5.4 避坑记录：成绩查询系统开发中的四个典型坑

坑一：成绩框输入非数字，SQL 直接报错。现象：添加成绩页面输入“abc”或“9十”，提交后页面 500 错误。原因：成绩字段在数据库里是 Int 类型，SQL 拼接时直接把非数字字符串写入，数据库报转换失败。解决：在执行 INSERT 前加 IsNumeric(score) 判断，非数字直接返回提示，不进数据库。这是最简单也最容易被忽略的一道校验。

坑二：中文乱码。现象：页面上显示的学生姓名、班级名称全是“???”。原因：ASP 页面没有声明 CodePage=936，页面编码和 SQL 2000 数据库的排序规则（Collation）不一致，中文在传递过程中被转成不当编码。解决：ASP 页面头部加“<% @Language="VBScript" CodePage="936" %>”，数据库字段排序规则设置为 Chinese_PRC 系列，两个地方对齐后乱码消失。

坑三：直接改 URL 绕过登录访问后台页面。现象：学生登录后，把地址栏改成 admin_main.asp，竟然能打开管理员页面。原因：后台页面对每个请求都信任，没有读取 Session("usertype") 做权限验证。解决：每个后台页面开头强制校验 Session，如果 usertype 不是 admin 就 Response.Redirect 回登录页，同时在 Session 过期时也要做同样的跳转。

坑四：重复添加成绩触发联合主键冲突。现象：管理员把某个学生的成绩录了两遍，第二次提交时数据库报“主键冲突”或程序直接崩溃。原因：成绩表的主键是学号+学期编号+课程编号三列联合，业务上不允许同一学生同一学期同一课程出现两条记录，前端却没有先查重。解决：按 5.2 的写法，插入前先执行 COUNT 查询，存在则提示用户改用修改功能，不存在才允许 INSERT。

6. 验证这套建模是否完整：用追踪矩阵检查课设报告

写完用例图、活动图、序列图、数据库表，怎么确认整套设计没有漏东西？一个好用的方法是做需求追踪矩阵，把每一层的产物映射起来。一张追踪矩阵至少包含四列：业务需求、用例/活动图分支、数据表/字段、功能实现界面。比如“学生查询本人成绩”这一行，关联的用例是学生用例图里的“成绩查询”，活动图是学生查询成绩活动图的正常流路径，数据库是学生成绩信息表按学号查询，界面是学生成绩查询页面。逐行核对，任何一行缺了某一层的对应，就说明设计存在断点。

这个矩阵的用途有两个。一个是自查：报告写到最后，拿矩阵逐行扫描，发现某行没有对应的数据库字段或界面，就回去补设计。另一个是答辩演示：老师问“你这个设计怎么保证需求全覆盖”，直接把矩阵展示出来，比口头解释“我们都画了图”要直观得多。

那年做完这份课设以后，我养成了一个习惯：凡是接手的系统，不管大小，先逼自己把业务需求拆成一行行的条目，再让用例、字段、界面层层对应上。后来做企业项目时，这个习惯帮我发现了不止一次“需求写了但数据库没字段”的设计漏洞。希望这份报告的拆解过程也能帮你在写课设时少走几步弯路。

本文还有配套的精品资源，点击获取