简介《信息系统分析与设计课程设计报告》是一份围绕高校成绩查询信息系统开发的完整课程设计文档适合信息管理与信息系统、计算机等相关专业学生参考。报告以西安理工大学工商管理学院为背景针对传统成绩公布方式效率低、易出错等问题给出了系统化的分析与设计方案内容涵盖设计背景、可行性分析、用例建模、数据库设计、功能结构设计、界面设计与测试方案等完整开发流程所涉及的用例图、活动图、序列图和类图等建模方法可帮助读者理解信息系统分析与设计的具体实践。资源为单个doc格式文档压缩包大小约2.09MB虽然只有一份文件但内容体系完整总页数充足。该文档既可作为课程设计报告的写作范例也可为成绩管理系统的开发提供需求分析与功能设计参考。目前已有352人学习浏览对正在完成信息系统课程设计或需要撰写类似报告的学生具有较强参考价值。1. 一份课程设计报告看懂高校成绩系统的完整建模流程期末成绩张贴在教学楼橱窗里学生挤在玻璃窗前从几十张成绩单里翻找自己班级的那一张好不容易找到成绩单可能已经被替换或者某科成绩因为放假前没录完而查不到——这是西安理工大学工商管理学院曾经的日常。这份《信息系统分析与设计课程设计报告》就是针对这个真实痛点完成的成绩查询信息系统设计技术栈是 ASP VBScript SQL 2000覆盖了从可行性分析、UML 用例图/活动图/序列图/类图到数据库表设计、功能结构设计和系统实施测试的完整流程。如果你正在写信息系统分析与设计课设或者想学 UML 建模怎么落到实际项目里这份报告是很好的结构参考和答辩素材。2. 从张贴成绩单到在线查询把业务痛点翻译成系统边界2.1 可行性分析不是走过场三项检查直接决定课设能不能立项报告在第二章做了三方面可行性分析经济可行性、技术可行性、社会可行性。这个顺序是有讲究的。经济可行性先算成本报告明确指出“西安理工大学工商管理学院已有自己的网站所以网站建设费用是很小的”软件开发因为只做成绩查询功能也很小结论是开发值得。技术可行性部分写得很克制“程序实现语言是 ASPVBScript”并且点出关键难点是“与成绩数据库的连接以及查询功能的实现”。这两个难点判断得很准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(12)否否学生信息表班级Varchar(20)否否学生信息表密码Varchar(8)否否管理员信息表账号Char(10)否是管理员信息表密码Varchar(8)否否课程信息表课程编号Char(10)否是课程信息表课程名称Varchar(20)否否课程信息表任课老师Varchar(12)否否学期信息表学期编号Char(10)否是学期信息表学期Char(10)否否班级信息表班级编号Char(10)否是班级信息表班级名称Varchar(20)否否班级信息表班主任Varchar(12)否否学生成绩信息表学号Char(10)否是学生成绩信息表学期编号Char(10)否是学生成绩信息表课程编号Char(10)否是学生成绩信息表成绩Int否否这里有两个设计决策值得说明。一是学号用 Char(10) 而不是 Varchar(10)因为学号是定长 10 位用 Char 定长类型可以避免变长字段的存储开销和索引效率问题这是 SQL 2000 时代的常见选择。二是成绩表用学号、学期编号、课程编号三字段联合主键从业务上保证了“同一学生同一学期同一课程只能有一条成绩记录”同时这三列分别是学生表、学期表、课程表的主键天然构成外键关系。物理设计阶段还要为这三个字段建联合索引否则成绩表数据量上去后按学号查成绩的查询会全表扫描。4.3 功能结构设计管理员和学生看到的界面为什么不同功能结构设计的核心是权限分流。管理员登录后的功能有成绩管理添加、删除、修改、查询和用户管理添加用户、删除用户、修改用户、查询用户学生登录后的功能只有本人成绩查询、本班成绩查询、修改个人信息、修改登录密码、退出系统。管理员可以按班级或学号查询所有学生成绩学生只能查自己的成绩和本班成绩单。这里的关键约束在前面用例分析里已经出现了功能设计阶段又重申一遍已存在的成绩只能修改、删除、查询不能添加不存在的成绩只能添加不能修改、删除、查询。这个规则直接决定代码里的执行顺序——添加成绩前必须先查是否存在修改成绩前也必须先查是否存在。对应到 5.1.3 管理员添加学生成绩界面设计它的核心逻辑就是“先查重再插入”这一点在避坑章节会细说。5. 系统实施与测试登录、查询、录入的关键实现与避坑记录5.1 用户登录系统界面设计会话控制与权限分流报告的 5.1.1 节描述了用户登录系统界面设计这是整个系统实施的第一块界面。登录页的后端逻辑是 ASP VBScript按这个场景下最常见的实现方式登录验证会拆成两个文件一个登录表单页一个处理页。处理页的伪代码如下% LanguageVBScript CodePage936 % % 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 页面没有声明 CodePage936页面编码和 SQL 2000 数据库的排序规则Collation不一致中文在传递过程中被转成不当编码。解决ASP 页面头部加“% LanguageVBScript CodePage936 %”数据库字段排序规则设置为 Chinese_PRC 系列两个地方对齐后乱码消失。坑三直接改 URL 绕过登录访问后台页面。现象学生登录后把地址栏改成 admin_main.asp竟然能打开管理员页面。原因后台页面对每个请求都信任没有读取 Session(usertype) 做权限验证。解决每个后台页面开头强制校验 Session如果 usertype 不是 admin 就 Response.Redirect 回登录页同时在 Session 过期时也要做同样的跳转。坑四重复添加成绩触发联合主键冲突。现象管理员把某个学生的成绩录了两遍第二次提交时数据库报“主键冲突”或程序直接崩溃。原因成绩表的主键是学号学期编号课程编号三列联合业务上不允许同一学生同一学期同一课程出现两条记录前端却没有先查重。解决按 5.2 的写法插入前先执行 COUNT 查询存在则提示用户改用修改功能不存在才允许 INSERT。6. 验证这套建模是否完整用追踪矩阵检查课设报告写完用例图、活动图、序列图、数据库表怎么确认整套设计没有漏东西一个好用的方法是做需求追踪矩阵把每一层的产物映射起来。一张追踪矩阵至少包含四列业务需求、用例/活动图分支、数据表/字段、功能实现界面。比如“学生查询本人成绩”这一行关联的用例是学生用例图里的“成绩查询”活动图是学生查询成绩活动图的正常流路径数据库是学生成绩信息表按学号查询界面是学生成绩查询页面。逐行核对任何一行缺了某一层的对应就说明设计存在断点。业务需求用例/活动图数据表字段实现界面学生登录验证登录活动图 A1/A2/A3学生信息表.学号/密码登录界面管理员按班级查成绩管理员查询成绩活动图学生信息表.班级 成绩表管理员查询界面录入成绩且不允许重复管理员添加成绩活动图 A1/A2成绩表联合主键管理员添加界面学生查本班成绩单学生查询成绩活动图班级信息表 成绩表学生查询界面修改登录密码学生用例图“修改密码”学生信息表.密码个人信息修改界面这个矩阵的用途有两个。一个是自查报告写到最后拿矩阵逐行扫描发现某行没有对应的数据库字段或界面就回去补设计。另一个是答辩演示老师问“你这个设计怎么保证需求全覆盖”直接把矩阵展示出来比口头解释“我们都画了图”要直观得多。那年做完这份课设以后我养成了一个习惯凡是接手的系统不管大小先逼自己把业务需求拆成一行行的条目再让用例、字段、界面层层对应上。后来做企业项目时这个习惯帮我发现了不止一次“需求写了但数据库没字段”的设计漏洞。希望这份报告的拆解过程也能帮你在写课设时少走几步弯路。本文还有配套的精品资源点击获取
从UML建模到数据库设计：高校成绩查询系统课设全流程解析
简介《信息系统分析与设计课程设计报告》是一份围绕高校成绩查询信息系统开发的完整课程设计文档适合信息管理与信息系统、计算机等相关专业学生参考。报告以西安理工大学工商管理学院为背景针对传统成绩公布方式效率低、易出错等问题给出了系统化的分析与设计方案内容涵盖设计背景、可行性分析、用例建模、数据库设计、功能结构设计、界面设计与测试方案等完整开发流程所涉及的用例图、活动图、序列图和类图等建模方法可帮助读者理解信息系统分析与设计的具体实践。资源为单个doc格式文档压缩包大小约2.09MB虽然只有一份文件但内容体系完整总页数充足。该文档既可作为课程设计报告的写作范例也可为成绩管理系统的开发提供需求分析与功能设计参考。目前已有352人学习浏览对正在完成信息系统课程设计或需要撰写类似报告的学生具有较强参考价值。1. 一份课程设计报告看懂高校成绩系统的完整建模流程期末成绩张贴在教学楼橱窗里学生挤在玻璃窗前从几十张成绩单里翻找自己班级的那一张好不容易找到成绩单可能已经被替换或者某科成绩因为放假前没录完而查不到——这是西安理工大学工商管理学院曾经的日常。这份《信息系统分析与设计课程设计报告》就是针对这个真实痛点完成的成绩查询信息系统设计技术栈是 ASP VBScript SQL 2000覆盖了从可行性分析、UML 用例图/活动图/序列图/类图到数据库表设计、功能结构设计和系统实施测试的完整流程。如果你正在写信息系统分析与设计课设或者想学 UML 建模怎么落到实际项目里这份报告是很好的结构参考和答辩素材。2. 从张贴成绩单到在线查询把业务痛点翻译成系统边界2.1 可行性分析不是走过场三项检查直接决定课设能不能立项报告在第二章做了三方面可行性分析经济可行性、技术可行性、社会可行性。这个顺序是有讲究的。经济可行性先算成本报告明确指出“西安理工大学工商管理学院已有自己的网站所以网站建设费用是很小的”软件开发因为只做成绩查询功能也很小结论是开发值得。技术可行性部分写得很克制“程序实现语言是 ASPVBScript”并且点出关键难点是“与成绩数据库的连接以及查询功能的实现”。这两个难点判断得很准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(12)否否学生信息表班级Varchar(20)否否学生信息表密码Varchar(8)否否管理员信息表账号Char(10)否是管理员信息表密码Varchar(8)否否课程信息表课程编号Char(10)否是课程信息表课程名称Varchar(20)否否课程信息表任课老师Varchar(12)否否学期信息表学期编号Char(10)否是学期信息表学期Char(10)否否班级信息表班级编号Char(10)否是班级信息表班级名称Varchar(20)否否班级信息表班主任Varchar(12)否否学生成绩信息表学号Char(10)否是学生成绩信息表学期编号Char(10)否是学生成绩信息表课程编号Char(10)否是学生成绩信息表成绩Int否否这里有两个设计决策值得说明。一是学号用 Char(10) 而不是 Varchar(10)因为学号是定长 10 位用 Char 定长类型可以避免变长字段的存储开销和索引效率问题这是 SQL 2000 时代的常见选择。二是成绩表用学号、学期编号、课程编号三字段联合主键从业务上保证了“同一学生同一学期同一课程只能有一条成绩记录”同时这三列分别是学生表、学期表、课程表的主键天然构成外键关系。物理设计阶段还要为这三个字段建联合索引否则成绩表数据量上去后按学号查成绩的查询会全表扫描。4.3 功能结构设计管理员和学生看到的界面为什么不同功能结构设计的核心是权限分流。管理员登录后的功能有成绩管理添加、删除、修改、查询和用户管理添加用户、删除用户、修改用户、查询用户学生登录后的功能只有本人成绩查询、本班成绩查询、修改个人信息、修改登录密码、退出系统。管理员可以按班级或学号查询所有学生成绩学生只能查自己的成绩和本班成绩单。这里的关键约束在前面用例分析里已经出现了功能设计阶段又重申一遍已存在的成绩只能修改、删除、查询不能添加不存在的成绩只能添加不能修改、删除、查询。这个规则直接决定代码里的执行顺序——添加成绩前必须先查是否存在修改成绩前也必须先查是否存在。对应到 5.1.3 管理员添加学生成绩界面设计它的核心逻辑就是“先查重再插入”这一点在避坑章节会细说。5. 系统实施与测试登录、查询、录入的关键实现与避坑记录5.1 用户登录系统界面设计会话控制与权限分流报告的 5.1.1 节描述了用户登录系统界面设计这是整个系统实施的第一块界面。登录页的后端逻辑是 ASP VBScript按这个场景下最常见的实现方式登录验证会拆成两个文件一个登录表单页一个处理页。处理页的伪代码如下% LanguageVBScript CodePage936 % % 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 页面没有声明 CodePage936页面编码和 SQL 2000 数据库的排序规则Collation不一致中文在传递过程中被转成不当编码。解决ASP 页面头部加“% LanguageVBScript CodePage936 %”数据库字段排序规则设置为 Chinese_PRC 系列两个地方对齐后乱码消失。坑三直接改 URL 绕过登录访问后台页面。现象学生登录后把地址栏改成 admin_main.asp竟然能打开管理员页面。原因后台页面对每个请求都信任没有读取 Session(usertype) 做权限验证。解决每个后台页面开头强制校验 Session如果 usertype 不是 admin 就 Response.Redirect 回登录页同时在 Session 过期时也要做同样的跳转。坑四重复添加成绩触发联合主键冲突。现象管理员把某个学生的成绩录了两遍第二次提交时数据库报“主键冲突”或程序直接崩溃。原因成绩表的主键是学号学期编号课程编号三列联合业务上不允许同一学生同一学期同一课程出现两条记录前端却没有先查重。解决按 5.2 的写法插入前先执行 COUNT 查询存在则提示用户改用修改功能不存在才允许 INSERT。6. 验证这套建模是否完整用追踪矩阵检查课设报告写完用例图、活动图、序列图、数据库表怎么确认整套设计没有漏东西一个好用的方法是做需求追踪矩阵把每一层的产物映射起来。一张追踪矩阵至少包含四列业务需求、用例/活动图分支、数据表/字段、功能实现界面。比如“学生查询本人成绩”这一行关联的用例是学生用例图里的“成绩查询”活动图是学生查询成绩活动图的正常流路径数据库是学生成绩信息表按学号查询界面是学生成绩查询页面。逐行核对任何一行缺了某一层的对应就说明设计存在断点。业务需求用例/活动图数据表字段实现界面学生登录验证登录活动图 A1/A2/A3学生信息表.学号/密码登录界面管理员按班级查成绩管理员查询成绩活动图学生信息表.班级 成绩表管理员查询界面录入成绩且不允许重复管理员添加成绩活动图 A1/A2成绩表联合主键管理员添加界面学生查本班成绩单学生查询成绩活动图班级信息表 成绩表学生查询界面修改登录密码学生用例图“修改密码”学生信息表.密码个人信息修改界面这个矩阵的用途有两个。一个是自查报告写到最后拿矩阵逐行扫描发现某行没有对应的数据库字段或界面就回去补设计。另一个是答辩演示老师问“你这个设计怎么保证需求全覆盖”直接把矩阵展示出来比口头解释“我们都画了图”要直观得多。那年做完这份课设以后我养成了一个习惯凡是接手的系统不管大小先逼自己把业务需求拆成一行行的条目再让用例、字段、界面层层对应上。后来做企业项目时这个习惯帮我发现了不止一次“需求写了但数据库没字段”的设计漏洞。希望这份报告的拆解过程也能帮你在写课设时少走几步弯路。本文还有配套的精品资源点击获取