简介适合软件工程课程设计使用的医院在线预约系统完整报告面向计算机相关专业学生及需要完成类似课题的开发者用于理解需求分析、结构化设计与面向对象设计的全流程。资源为一份 Word 文档压缩包内共 1 个 doc 文件整体大小 762KB内容按设计目的、可行性分析、需求分析、结构化设计、面向对象设计、测试方案等章节展开覆盖系统流程图、数据流图、数据字典、E-R图、软件结构图、Jackson图、用例图、类图和顺序图等关键设计产物可作为课程设计报告撰写与系统设计的直接参考。目前已有1014人学习下载。通过这份文档读者可以掌握从可行性分析到测试方案的软件工程规范步骤并借鉴医院预约场景下的模块划分、数据结构设计和接口表达方式节省从头搭建报告框架的时间提升课程设计完成质量。1. 一次挂号的业务只有几步文档的检查链路却超过十张图一个“医院在线预约”业务落地到数据库就是一条 insert病人选科室、选医生生成挂号单收费闭环。但放到软件工程课程设计里同样的动作要拆成五层文档可行性分析要有系统流程图、数据流图DFD和数据字典需求分析要有 E-R 图结构化设计要有软件结构图和 Jackson 图面向对象设计要补用例图、类图、顺序图和状态图最后还必须有一份测试方案。真正让课设难产的通常不是画图本身而是同一份数据在系统流程图里叫“病人姓名”到数据字典里叫 name到类图里变成 patientName三张图对不上答辩时每个不一致都会被翻出来。这篇文章以医院在线预约系统课程设计为主线从可行性分析、需求建模、结构化设计到面向对象设计和测试方案逐层拆开每一步都给出能直接抄的步骤、参数和自查方法。2. 可行性分析三件套系统流程图、数据流图和数据字典的对齐方法2.1 系统流程图与 DFD物理视图和逻辑视图必须分开画课设原文里系统流程图画的是挂号全过程开始输入病人姓名、性别、编号确认挂号后开启新的挂号单界面初始化资料再判断专家是否有时间有时间则执行挂号并缴纳专家费用没时间则改天再来或转普通会诊最后退出挂号。这一层的重点是物理动作谁在哪个界面操作、分支怎么走用 StarUML 的基本流程图就能画完不需要引入数据流专用符号。DFD 则必须与系统流程图分开画它属于逻辑模型不关心界面只关心数据从哪里来到哪里去。课程设计报告里常见的第一个扣分点是 DFD 只画一层直接从一个整体框跳进细节缺少上下文图。上下文图也叫 DFD 第 0 层规则很简单整个系统画成一个加工病人、工作人员、医生作为外部实体放在图外外部实体与系统之间的数据流标清楚。这一层画的不是功能而是系统边界——哪些数据进、哪些数据出评审第一眼看的就是这个。画完第 0 层再拆第 1 层。“挂号系统”这个加工通常拆成下面 4 个加工加工编号加工名称主要输入主要输出1.1接收病人信息病人姓名、性别、年龄、病历号格式化病人记录1.2生成挂号单病人记录、科室、医生信息挂号单草稿1.3收费处理挂号单草稿、费用标准缴费结果1.4打印挂号单缴费结果挂号单凭证这里必须做一次对齐检查DFD 第 0 层与第 1 层的数据流名称一致。比如第 1 层加工 1.4 输出“挂号单凭证”在第 0 层里就应该有同名输出流流向病人如果第 0 层写的是“预约信息”而第 1 层所有加工里都没有这个名字的数据流说明需求阶段漏了“预约记录”这个数据存储后续画 E-R 图时就会少一张表。2.2 数据字典用脚本生成条目不靠 Word 里手敲数据字典是为 DFD 服务的词典DFD 里出现的每个数据流、数据存储和加工都应该在数据字典里找到对应定义。课设原文给的三个典型条目很能说明问题Shu-004年龄字符型3 位范围 0~999Shu-005科室字符型4 位Shu-006挂号类型字符型2 位取值普通、专家、主任。但数据项分散写在文档里很容易出现同一个“科室”在结构化设计里变成 8 位在类图里又变成 varchar(20)。我一般会建议用一段小脚本管理这些条目而不是在 Word 里手动维护。下面这段 Python 能按统一模板输出条目改起来也快。# data_dict_gen.py # 把数据项定义集中在一个列表里按统一模板输出字典条目 entries [ {id: Shu-004, name: 年龄, alias: , type: 字符型, width: 3, range: 0~999}, {id: Shu-005, name: 科室, alias: , type: 字符, width: 4, range: 内科,外科,儿科,妇产科}, {id: Shu-006, name: 挂号类型, alias: , type: 字符, width: 2, range: 普通,专家,主任}, ] for entry in entries: print([{}] {}类型 {}, 宽度 {}, 取值范围 {}.format( entry[id], entry[name], entry[type], entry[width], entry[range] ))参数说明id是数据项编号对应报告中的 Shu-XXXname是对外名称必须与 DFD 数据流名或数据存储字段同名alias留空时也照常输出保证格式统一width用来和数据库字段长度对照。脚本跑完把输出与 DFD 的数据流名做一次集合比对缺失和改名的情况立刻暴露。提示如果学校要求“数据字典用 Excel 写插入——对象——由文件创建”不要把控制台纯文本直接粘进 Word。先导出 .xlsx 再用 Word 的对象功能嵌入否则评阅老师看到的是一段没有表格结构的字符串。2.3 E-R 图实体收敛到四个联系只保留三条主线E-R 图的作用是确定数据存储层。医院挂号系统最怕把实体画成一团病人、医生、科室、挂号单、费用、排班、病历全揉在一起。一个课设周期的合理做法是先收敛实体围绕“挂号”这个核心业务保留四个实体实体关键属性病人病人编号、姓名、性别、年龄、病历号科室科室编号、科室名称、楼层位置医生医生编号、姓名、职称、科室编号挂号单挂号单编号、挂号日期、挂号类型、病人编号、医生编号、费用状态联系方面只保留三组 1:N 关系病人与挂号单是 1:N医生与挂号单是 1:N科室与医生是 1:N。如果出现 M:N 关系比如一个专家在多个科室出诊就要拆出关联实体课设周期内一般不必进入这一步。E-R 图的正确用法是直接支撑后面的库表设计挂号单表以病人编号和医生编号作为外键挂号类型字段与数据字典 Shu-006 的取值范围保持一致。属性个数太多时把键属性放在实体框左上角非键属性按业务分组避免画到两页 A4 纸还放不下。3. 结构化设计从数据流图到模块与过程的两次映射3.1 软件结构图把 DFD 的加工节点改造成调用层次结构化设计的核心工作是把 DFD 转换成软件结构图这一步在课程设计中通常叫变换分析。做法是先识别 DFD 里的传入路径、变换中心和传出路径再把这三段映射成结构图中的输入模块、中心转换模块和输出模块。以第 1 层 DFD 为例加工 1.1“接收病人信息”是传入路径1.2“生成挂号单”是变换中心1.3“收费处理”和 1.4“打印挂号单”是传出路径。转换后的软件结构图顶层是“挂号系统”第二层分别是模块编号模块名职责对应 DFD 加工M-1获取病人信息接受输入并格式校验1.1M-2构造挂号单组装病人与医生数据1.2M-3计费处理按挂号类型计算费用1.3M-4输出挂号单生成打印凭证1.4M-5存储预约记录写病人信息与预约信息数据存储 D1、D2这里要强调一个常见的判断错误软件结构图不是把 DFD 原样换个方向放而是要把“数据流”变成“调用关系”。DFD 里的箭头表示数据流动结构图里的箭头表示模块调用和返回。模块划分之后还需要用内聚和耦合检查一遍M-3 计费处理的内聚类型应该是功能内聚因为它只做一件事如果 M-3 里同时塞了“判断专家是否有时间”的逻辑那它就是逻辑内聚答辩时评审会直接点出来。3.2 Jackson 图用顺序、选择、重复描述挂号单的数据结构Jackson 图的目的是让程序结构直接映照数据结构核心只有三种结构顺序、选择、重复。课程设计报告里出现 Jackson 图时常见的错误是画成普通的树状图没有区分这三种图元。以挂号单的数据结构为例顺序一张挂号单 挂号单标识 病人信息 挂号信息选择挂号类型是普通、专家或主任中的一种重复一个医生名下挂着多张挂号单。顺序结构用直线依次排列选择结构用右上角画圈的判断节点重复结构用右上角画星号表示循环。Jackson 图的价值在于它能直接指导程序写法。比如按下面这段 JavaScript 骨架就能把三种结构对应到代码路径。// jackson_register.js // 与 Jackson 图对应的挂号单生成逻辑骨架 function createTicket(patient, doctor, type) { const ticket { id: generateId(), date: new Date() }; // 顺序单标识 // 选择按挂号类型确定费用路径 if (type 专家) { ticket.fee 50; } else if (type 主任) { ticket.fee 80; } else { ticket.fee 10; // 普通 } // 重复把新挂号单加入医生名下的列表 doctor.tickets.push(ticket); ticket.doctorId doctor.doctorId; return ticket; }逻辑说明ticket先被赋予编号和日期完成“顺序”中的挂号单标识随后if/else结构对应 Jackson 图的“选择”每个分支设置不同费用最后push动作对应“重复”把当前单挂载到医生列表尾部。参数type对应数据字典 Shu-006 的取值如果传入的字符串不在“普通、专家、主任”范围内调用方应该在进入createTicket之前拦截而不是在这里兜底不然 Jackson 图上的三个分支就覆盖不到异常路径了。4. 面向对象设计用例图、类图、顺序图与状态图的闭环4.1 用例图参与者画错后面全是白做用例图是面向对象设计的入口它回答“系统为谁提供什么价值”。医院在线预约系统里参与者至少有三个病人、工作人员、医生。课设原文用例图里出现的“登录系统、挂号系统、挂号单结束并退出、输入病人姓名性别、输入科别信息、输入医生信息、收取挂号费、保存信息、产生挂号单、打开新界面”这些用例需要按参与者归组参与者用例前置条件主事件流病人创建挂号单选择科室和医生提交基本信息生成挂号单工作人员登记病人信息已登录系统输入姓名、性别、病历号并保存工作人员收取挂号费挂号单已生成按类型计费并更新费用状态医生查看当日挂号已登录系统查询科室名下挂号单列表画用例图时要注意两个点。第一用例名必须是动词短语不能写“挂号单”三个字要写“创建挂号单”或“打印挂号单”第二参与者之间的关系用泛化比如“收费员”泛化自“工作人员”不要画成两个孤立角色同时连接同一批用例那样用例图会被拉宽且没有信息量。4.2 类图从用例事件流里提取类而不是从 E-R 图抄表类图常见误区是从 E-R 图直接映射成数据库表然后宣称这就是类图。正确做法是从用例的事件流里找名词和动词名词是候选类动词是候选方法。比如“病人提交基本信息生成挂号单”候选类是病人、挂号单、医生“收费处理”对应挂号单上的计费方法。下面用 Python dataclass 演示核心类的定义属性名与数据字典条目对应。# class_design.py from dataclasses import dataclass, field from datetime import date dataclass class Patient: patient_id: str # 病历号对应 E-R 图中的主键 name: str gender: str # 性别 age: int # 年龄对应数据字典 Shu-004 dataclass class Doctor: doctor_id: str name: str title: str # 职称普通/专家/主任判断依据 dataclass class Registration: ticket_id: str # 挂号单编号测试环节要求 5 位数字 patient: Patient doctor: Doctor ticket_type: str # 挂号类型取值普通/专家/主任 fee: float 0.0 status: str created # 初始状态与状态图保持一致 def charge(self, price_table: dict) - None: # 按挂号类型查价目表更新费用与状态 self.fee price_table.get(self.ticket_type, 0.0) self.status paid逻辑说明Patient、Doctor、Registration三个类构成聚合关系——挂号单聚合病人和医生而不是继承它们。charge方法从price_table字典里查价格这样新增挂号类型时只需要改价目表不需要改方法内部满足开闭原则。status字段从初始值created变更为paid这个状态迁移必须和 4.4 状态图完全对得上否则类和状态图就是各画各的。4.3 顺序图用时间轴检验类图里的调用次序顺序图画的是对象之间按时间展开的消息传递。医院的挂号顺序图里至少应有四条生命线工作人员、挂号单界面、挂号单对象、医生对象。消息顺序大致是工作人员输入病人信息界面调用 Patient 构造方法界面读科室和医生列表返回匹配的 Doctor 对象界面创建 Registration 对象并关联 Patient、Doctor收费模块调用 charge()根据挂号类型计算费用系统返回挂号单编号工作人员打印输出。画顺序图时最容易犯的错是消息名与类图方法名不一致。类图里写了charge(price_table)顺序图里却画成calculate_fee()两处名称不同在评审时会被视为设计不同步。建立一条简单的规则顺序图中的每个消息名都必须在类图中某个类的方法列表里找得到。如果calculate_fee()在类图中不存在说明需要补到类图上而不是反过来改顺序图。4.4 状态图挂号单从创建到退号的六个状态迁移状态图刻画单个对象的生命周期。对挂号单对象来说常见状态包括已创建created、已支付paid、已退号cancelled、已就诊served。状态迁移如下当前状态触发事件目标状态created收费成功paidpaid病人申请退号工作人员确认cancelledpaid医生完成接诊servedcancelled无终态served无终态状态图的画法是每个状态一个圆角矩形初态用实心圆点终态用圆点加圆圈。迁移箭头上的标签是触发事件比如“收费成功”“退号确认”。这里有一个隐藏点paid 状态到 cancelled 的迁移在实际业务里还要判断退费规则比如专家号开诊前 2 小时之外才允许退。如果测试方案或用例图里没有覆盖这个分支就属于需求不完整状态图反而把这个缺口暴露出来了。状态图画完之后把每个迁移与用例事件流对照补上缺失的异常分支这是面向对象四张图里最有价值的一次检查。5. 测试方案基于边界值的挂号单输入规则推导5.1 先从三组用例反推业务规则课设原文的测试方案只有三组输入输出输入10021预期输出“通过”输入nobody预期输出“有误”输入1234j预期输出“有误”。从这三组结果反推被测字段很可能是挂号单编号或病历号校验规则是“5 位数字不允许字母和混合串”。10021刚好 5 位且纯数字通过nobody是 6 位字母失败1234j是数字与字母混合失败。这个规则用正则表达式描述就是^\d{5}$。5.2 边界值分析不能只取合法点如果测试报告只写这三条用例评审大概率会追问边界在哪里对“5 位数字”这个规则边界值是长度 4、长度 5、长度 6以及纯数字与非纯数字的切换点。下面这段脚本把边界用例一次性跑完输出与预期对照。# boundary_test.py import re def validate_ticket_id(code: str) - str: # 挂号单编号必须是 5 位数字这是从测试方案反推的规则 return 通过 if re.fullmatch(r\d{5}, code) else 有误 cases [ (1234, 有误), # 下邻4 位 (12345, 通过), # 合法5 位 (123456, 有误), # 上邻6 位 (nobody, 有误), # 全字母 (1234j, 有误), # 数字加字母 ] for code, expected in cases: actual validate_ticket_id(code) print(f输入 {code:6} 预期 {expected} 实际 {actual} f{PASS if actual expected else FAIL})参数说明code是被测输入expected是测试方案定义的预期输出。脚本里用了fullmatch而不是match因为fullmatch要求整个字符串完全匹配match只要开头匹配就会放过12345j这类的混合串。三组原始用例只覆盖了场景 2、3、5补上场景 1、4 后测试方案的完整度会明显提高而且这两组是纯手工能想出来的边界。5.3 测试用例表与回归顺序课程设计里的测试方案不要求自动化测试但要求设计文档里有一张能对应需求的测试用例表。这张表可以这样列用例编号输入预期输出确认的动作状态T-00110021通过挂号单进入已创建状态T-0021234有误提示编号格式错误不生成挂号单T-003123456有误同上T-004nobody有误同上T-0051234j有误同上回归顺序也有讲究先跑合法边界 T-001再跑非法长度 T-002、T-003最后跑混合类型 T-004、T-005。如果实现代码在验证时能通过前两个却在 T-005 失败问题多半出在用了isdigit()判断而不是完整正则因为isdigit()对1234j判断为 False但正则能明确告诉你错在位置 5。这一层分析写进测试报告比只贴三条输入输出有说服力得多。6. 收尾技巧图表编号、OLE 对象与交稿前的自检方式6.1 用一张交叉表排查图表不一致所有图都画完之后可以建一张“图表元素——源头文档”的交叉表把每个关键数据项在系统流程图、DFD、数据字典、E-R 图、类图和测试用例表里的出现位置列出来逐行核对名称数据项系统流程图DFD数据字典E-R 图类图测试用例病人姓名出现数据流“病人信息”Shu-001病人实体name 属性用例输入挂号类型分支条件数据流“挂号信息”Shu-006挂号单实体ticket_type 属性合法/非法取值挂号单编号不涉及输出流BRD01-02挂号单主键ticket_id边界值 5 位数字核对方法很简单从 DFD 里挑一条核心数据流“病人信息”沿着数据字典找到定义再看 E-R 图的病人实体有没有对应字段最后看类图和测试用例是否使用同一名称。只要某一行在任意两列里对不上就是需要修订的地方。这一步花 15 分钟能规避答辩时一半的质疑。6.2 在 Word 里嵌入 Excel 数据字典的正确方式学校如果要求“数据字典用 Excel 写”正确的动作是把数据字典按编号、名称、别名、类型、宽度、取值范围六列整理成 xlsx在 Word 中定位到数据字典章节选择“插入 → 对象 → 由文件创建”浏览选中 xlsx 文件勾选“显示为图标”则文档里不占版面双击可展开取消勾选“链接到文件”避免文件移动后 Word 里的对象失效。如果直接把 Excel 表格截图放进去评阅老师双击无法编辑会被认定文档编制不规范。还有一个小问题嵌入前把 Excel 的网格线关掉打印出来会更干净“插入——对象——由文件创建——浏览——插入——确定”这条菜单路径在 Word 2016 之后仍适用旧版 Word 的位置在“插入 → 对象”里的“新建”和“由文件创建”两个页签之间切换。6.3 交稿前最后过一遍的五处细节每张图下方加“图 X-XX 系统流程图”和图号正文里第一次出现该图时必须引用同一个图号DFD 第 0 层和第 1 层的数据流名逐一对照测试用例表里的输入值必须能在数据字典的取值范围里找到依据图里的文字注释统一用中文避免一部分英文一部分中文造成歧义StarUML 生成的图导出为高分辨率图片再插入 Word避免打印后线条发虚。图表编号本身应该贯穿始终系统流程图编号从第 5 章开始排E-R 图从第 6 章排面向对象四张图按小节号排如果报告修改过程中删掉一张图所有后续编号都要顺延。最后把代码、建模文件和 PDF 版报告放进同一个文件夹压缩包命名格式建议是“医院在线预约系统_学号_姓名_课设”这样不管是线上提交还是打印装订都省去再次沟通的时间。本文还有配套的精品资源点击获取 医院在线预约系统课程设计全流程：从数据流图到测试方案
简介适合软件工程课程设计使用的医院在线预约系统完整报告面向计算机相关专业学生及需要完成类似课题的开发者用于理解需求分析、结构化设计与面向对象设计的全流程。资源为一份 Word 文档压缩包内共 1 个 doc 文件整体大小 762KB内容按设计目的、可行性分析、需求分析、结构化设计、面向对象设计、测试方案等章节展开覆盖系统流程图、数据流图、数据字典、E-R图、软件结构图、Jackson图、用例图、类图和顺序图等关键设计产物可作为课程设计报告撰写与系统设计的直接参考。目前已有1014人学习下载。通过这份文档读者可以掌握从可行性分析到测试方案的软件工程规范步骤并借鉴医院预约场景下的模块划分、数据结构设计和接口表达方式节省从头搭建报告框架的时间提升课程设计完成质量。1. 一次挂号的业务只有几步文档的检查链路却超过十张图一个“医院在线预约”业务落地到数据库就是一条 insert病人选科室、选医生生成挂号单收费闭环。但放到软件工程课程设计里同样的动作要拆成五层文档可行性分析要有系统流程图、数据流图DFD和数据字典需求分析要有 E-R 图结构化设计要有软件结构图和 Jackson 图面向对象设计要补用例图、类图、顺序图和状态图最后还必须有一份测试方案。真正让课设难产的通常不是画图本身而是同一份数据在系统流程图里叫“病人姓名”到数据字典里叫 name到类图里变成 patientName三张图对不上答辩时每个不一致都会被翻出来。这篇文章以医院在线预约系统课程设计为主线从可行性分析、需求建模、结构化设计到面向对象设计和测试方案逐层拆开每一步都给出能直接抄的步骤、参数和自查方法。2. 可行性分析三件套系统流程图、数据流图和数据字典的对齐方法2.1 系统流程图与 DFD物理视图和逻辑视图必须分开画课设原文里系统流程图画的是挂号全过程开始输入病人姓名、性别、编号确认挂号后开启新的挂号单界面初始化资料再判断专家是否有时间有时间则执行挂号并缴纳专家费用没时间则改天再来或转普通会诊最后退出挂号。这一层的重点是物理动作谁在哪个界面操作、分支怎么走用 StarUML 的基本流程图就能画完不需要引入数据流专用符号。DFD 则必须与系统流程图分开画它属于逻辑模型不关心界面只关心数据从哪里来到哪里去。课程设计报告里常见的第一个扣分点是 DFD 只画一层直接从一个整体框跳进细节缺少上下文图。上下文图也叫 DFD 第 0 层规则很简单整个系统画成一个加工病人、工作人员、医生作为外部实体放在图外外部实体与系统之间的数据流标清楚。这一层画的不是功能而是系统边界——哪些数据进、哪些数据出评审第一眼看的就是这个。画完第 0 层再拆第 1 层。“挂号系统”这个加工通常拆成下面 4 个加工加工编号加工名称主要输入主要输出1.1接收病人信息病人姓名、性别、年龄、病历号格式化病人记录1.2生成挂号单病人记录、科室、医生信息挂号单草稿1.3收费处理挂号单草稿、费用标准缴费结果1.4打印挂号单缴费结果挂号单凭证这里必须做一次对齐检查DFD 第 0 层与第 1 层的数据流名称一致。比如第 1 层加工 1.4 输出“挂号单凭证”在第 0 层里就应该有同名输出流流向病人如果第 0 层写的是“预约信息”而第 1 层所有加工里都没有这个名字的数据流说明需求阶段漏了“预约记录”这个数据存储后续画 E-R 图时就会少一张表。2.2 数据字典用脚本生成条目不靠 Word 里手敲数据字典是为 DFD 服务的词典DFD 里出现的每个数据流、数据存储和加工都应该在数据字典里找到对应定义。课设原文给的三个典型条目很能说明问题Shu-004年龄字符型3 位范围 0~999Shu-005科室字符型4 位Shu-006挂号类型字符型2 位取值普通、专家、主任。但数据项分散写在文档里很容易出现同一个“科室”在结构化设计里变成 8 位在类图里又变成 varchar(20)。我一般会建议用一段小脚本管理这些条目而不是在 Word 里手动维护。下面这段 Python 能按统一模板输出条目改起来也快。# data_dict_gen.py # 把数据项定义集中在一个列表里按统一模板输出字典条目 entries [ {id: Shu-004, name: 年龄, alias: , type: 字符型, width: 3, range: 0~999}, {id: Shu-005, name: 科室, alias: , type: 字符, width: 4, range: 内科,外科,儿科,妇产科}, {id: Shu-006, name: 挂号类型, alias: , type: 字符, width: 2, range: 普通,专家,主任}, ] for entry in entries: print([{}] {}类型 {}, 宽度 {}, 取值范围 {}.format( entry[id], entry[name], entry[type], entry[width], entry[range] ))参数说明id是数据项编号对应报告中的 Shu-XXXname是对外名称必须与 DFD 数据流名或数据存储字段同名alias留空时也照常输出保证格式统一width用来和数据库字段长度对照。脚本跑完把输出与 DFD 的数据流名做一次集合比对缺失和改名的情况立刻暴露。提示如果学校要求“数据字典用 Excel 写插入——对象——由文件创建”不要把控制台纯文本直接粘进 Word。先导出 .xlsx 再用 Word 的对象功能嵌入否则评阅老师看到的是一段没有表格结构的字符串。2.3 E-R 图实体收敛到四个联系只保留三条主线E-R 图的作用是确定数据存储层。医院挂号系统最怕把实体画成一团病人、医生、科室、挂号单、费用、排班、病历全揉在一起。一个课设周期的合理做法是先收敛实体围绕“挂号”这个核心业务保留四个实体实体关键属性病人病人编号、姓名、性别、年龄、病历号科室科室编号、科室名称、楼层位置医生医生编号、姓名、职称、科室编号挂号单挂号单编号、挂号日期、挂号类型、病人编号、医生编号、费用状态联系方面只保留三组 1:N 关系病人与挂号单是 1:N医生与挂号单是 1:N科室与医生是 1:N。如果出现 M:N 关系比如一个专家在多个科室出诊就要拆出关联实体课设周期内一般不必进入这一步。E-R 图的正确用法是直接支撑后面的库表设计挂号单表以病人编号和医生编号作为外键挂号类型字段与数据字典 Shu-006 的取值范围保持一致。属性个数太多时把键属性放在实体框左上角非键属性按业务分组避免画到两页 A4 纸还放不下。3. 结构化设计从数据流图到模块与过程的两次映射3.1 软件结构图把 DFD 的加工节点改造成调用层次结构化设计的核心工作是把 DFD 转换成软件结构图这一步在课程设计中通常叫变换分析。做法是先识别 DFD 里的传入路径、变换中心和传出路径再把这三段映射成结构图中的输入模块、中心转换模块和输出模块。以第 1 层 DFD 为例加工 1.1“接收病人信息”是传入路径1.2“生成挂号单”是变换中心1.3“收费处理”和 1.4“打印挂号单”是传出路径。转换后的软件结构图顶层是“挂号系统”第二层分别是模块编号模块名职责对应 DFD 加工M-1获取病人信息接受输入并格式校验1.1M-2构造挂号单组装病人与医生数据1.2M-3计费处理按挂号类型计算费用1.3M-4输出挂号单生成打印凭证1.4M-5存储预约记录写病人信息与预约信息数据存储 D1、D2这里要强调一个常见的判断错误软件结构图不是把 DFD 原样换个方向放而是要把“数据流”变成“调用关系”。DFD 里的箭头表示数据流动结构图里的箭头表示模块调用和返回。模块划分之后还需要用内聚和耦合检查一遍M-3 计费处理的内聚类型应该是功能内聚因为它只做一件事如果 M-3 里同时塞了“判断专家是否有时间”的逻辑那它就是逻辑内聚答辩时评审会直接点出来。3.2 Jackson 图用顺序、选择、重复描述挂号单的数据结构Jackson 图的目的是让程序结构直接映照数据结构核心只有三种结构顺序、选择、重复。课程设计报告里出现 Jackson 图时常见的错误是画成普通的树状图没有区分这三种图元。以挂号单的数据结构为例顺序一张挂号单 挂号单标识 病人信息 挂号信息选择挂号类型是普通、专家或主任中的一种重复一个医生名下挂着多张挂号单。顺序结构用直线依次排列选择结构用右上角画圈的判断节点重复结构用右上角画星号表示循环。Jackson 图的价值在于它能直接指导程序写法。比如按下面这段 JavaScript 骨架就能把三种结构对应到代码路径。// jackson_register.js // 与 Jackson 图对应的挂号单生成逻辑骨架 function createTicket(patient, doctor, type) { const ticket { id: generateId(), date: new Date() }; // 顺序单标识 // 选择按挂号类型确定费用路径 if (type 专家) { ticket.fee 50; } else if (type 主任) { ticket.fee 80; } else { ticket.fee 10; // 普通 } // 重复把新挂号单加入医生名下的列表 doctor.tickets.push(ticket); ticket.doctorId doctor.doctorId; return ticket; }逻辑说明ticket先被赋予编号和日期完成“顺序”中的挂号单标识随后if/else结构对应 Jackson 图的“选择”每个分支设置不同费用最后push动作对应“重复”把当前单挂载到医生列表尾部。参数type对应数据字典 Shu-006 的取值如果传入的字符串不在“普通、专家、主任”范围内调用方应该在进入createTicket之前拦截而不是在这里兜底不然 Jackson 图上的三个分支就覆盖不到异常路径了。4. 面向对象设计用例图、类图、顺序图与状态图的闭环4.1 用例图参与者画错后面全是白做用例图是面向对象设计的入口它回答“系统为谁提供什么价值”。医院在线预约系统里参与者至少有三个病人、工作人员、医生。课设原文用例图里出现的“登录系统、挂号系统、挂号单结束并退出、输入病人姓名性别、输入科别信息、输入医生信息、收取挂号费、保存信息、产生挂号单、打开新界面”这些用例需要按参与者归组参与者用例前置条件主事件流病人创建挂号单选择科室和医生提交基本信息生成挂号单工作人员登记病人信息已登录系统输入姓名、性别、病历号并保存工作人员收取挂号费挂号单已生成按类型计费并更新费用状态医生查看当日挂号已登录系统查询科室名下挂号单列表画用例图时要注意两个点。第一用例名必须是动词短语不能写“挂号单”三个字要写“创建挂号单”或“打印挂号单”第二参与者之间的关系用泛化比如“收费员”泛化自“工作人员”不要画成两个孤立角色同时连接同一批用例那样用例图会被拉宽且没有信息量。4.2 类图从用例事件流里提取类而不是从 E-R 图抄表类图常见误区是从 E-R 图直接映射成数据库表然后宣称这就是类图。正确做法是从用例的事件流里找名词和动词名词是候选类动词是候选方法。比如“病人提交基本信息生成挂号单”候选类是病人、挂号单、医生“收费处理”对应挂号单上的计费方法。下面用 Python dataclass 演示核心类的定义属性名与数据字典条目对应。# class_design.py from dataclasses import dataclass, field from datetime import date dataclass class Patient: patient_id: str # 病历号对应 E-R 图中的主键 name: str gender: str # 性别 age: int # 年龄对应数据字典 Shu-004 dataclass class Doctor: doctor_id: str name: str title: str # 职称普通/专家/主任判断依据 dataclass class Registration: ticket_id: str # 挂号单编号测试环节要求 5 位数字 patient: Patient doctor: Doctor ticket_type: str # 挂号类型取值普通/专家/主任 fee: float 0.0 status: str created # 初始状态与状态图保持一致 def charge(self, price_table: dict) - None: # 按挂号类型查价目表更新费用与状态 self.fee price_table.get(self.ticket_type, 0.0) self.status paid逻辑说明Patient、Doctor、Registration三个类构成聚合关系——挂号单聚合病人和医生而不是继承它们。charge方法从price_table字典里查价格这样新增挂号类型时只需要改价目表不需要改方法内部满足开闭原则。status字段从初始值created变更为paid这个状态迁移必须和 4.4 状态图完全对得上否则类和状态图就是各画各的。4.3 顺序图用时间轴检验类图里的调用次序顺序图画的是对象之间按时间展开的消息传递。医院的挂号顺序图里至少应有四条生命线工作人员、挂号单界面、挂号单对象、医生对象。消息顺序大致是工作人员输入病人信息界面调用 Patient 构造方法界面读科室和医生列表返回匹配的 Doctor 对象界面创建 Registration 对象并关联 Patient、Doctor收费模块调用 charge()根据挂号类型计算费用系统返回挂号单编号工作人员打印输出。画顺序图时最容易犯的错是消息名与类图方法名不一致。类图里写了charge(price_table)顺序图里却画成calculate_fee()两处名称不同在评审时会被视为设计不同步。建立一条简单的规则顺序图中的每个消息名都必须在类图中某个类的方法列表里找得到。如果calculate_fee()在类图中不存在说明需要补到类图上而不是反过来改顺序图。4.4 状态图挂号单从创建到退号的六个状态迁移状态图刻画单个对象的生命周期。对挂号单对象来说常见状态包括已创建created、已支付paid、已退号cancelled、已就诊served。状态迁移如下当前状态触发事件目标状态created收费成功paidpaid病人申请退号工作人员确认cancelledpaid医生完成接诊servedcancelled无终态served无终态状态图的画法是每个状态一个圆角矩形初态用实心圆点终态用圆点加圆圈。迁移箭头上的标签是触发事件比如“收费成功”“退号确认”。这里有一个隐藏点paid 状态到 cancelled 的迁移在实际业务里还要判断退费规则比如专家号开诊前 2 小时之外才允许退。如果测试方案或用例图里没有覆盖这个分支就属于需求不完整状态图反而把这个缺口暴露出来了。状态图画完之后把每个迁移与用例事件流对照补上缺失的异常分支这是面向对象四张图里最有价值的一次检查。5. 测试方案基于边界值的挂号单输入规则推导5.1 先从三组用例反推业务规则课设原文的测试方案只有三组输入输出输入10021预期输出“通过”输入nobody预期输出“有误”输入1234j预期输出“有误”。从这三组结果反推被测字段很可能是挂号单编号或病历号校验规则是“5 位数字不允许字母和混合串”。10021刚好 5 位且纯数字通过nobody是 6 位字母失败1234j是数字与字母混合失败。这个规则用正则表达式描述就是^\d{5}$。5.2 边界值分析不能只取合法点如果测试报告只写这三条用例评审大概率会追问边界在哪里对“5 位数字”这个规则边界值是长度 4、长度 5、长度 6以及纯数字与非纯数字的切换点。下面这段脚本把边界用例一次性跑完输出与预期对照。# boundary_test.py import re def validate_ticket_id(code: str) - str: # 挂号单编号必须是 5 位数字这是从测试方案反推的规则 return 通过 if re.fullmatch(r\d{5}, code) else 有误 cases [ (1234, 有误), # 下邻4 位 (12345, 通过), # 合法5 位 (123456, 有误), # 上邻6 位 (nobody, 有误), # 全字母 (1234j, 有误), # 数字加字母 ] for code, expected in cases: actual validate_ticket_id(code) print(f输入 {code:6} 预期 {expected} 实际 {actual} f{PASS if actual expected else FAIL})参数说明code是被测输入expected是测试方案定义的预期输出。脚本里用了fullmatch而不是match因为fullmatch要求整个字符串完全匹配match只要开头匹配就会放过12345j这类的混合串。三组原始用例只覆盖了场景 2、3、5补上场景 1、4 后测试方案的完整度会明显提高而且这两组是纯手工能想出来的边界。5.3 测试用例表与回归顺序课程设计里的测试方案不要求自动化测试但要求设计文档里有一张能对应需求的测试用例表。这张表可以这样列用例编号输入预期输出确认的动作状态T-00110021通过挂号单进入已创建状态T-0021234有误提示编号格式错误不生成挂号单T-003123456有误同上T-004nobody有误同上T-0051234j有误同上回归顺序也有讲究先跑合法边界 T-001再跑非法长度 T-002、T-003最后跑混合类型 T-004、T-005。如果实现代码在验证时能通过前两个却在 T-005 失败问题多半出在用了isdigit()判断而不是完整正则因为isdigit()对1234j判断为 False但正则能明确告诉你错在位置 5。这一层分析写进测试报告比只贴三条输入输出有说服力得多。6. 收尾技巧图表编号、OLE 对象与交稿前的自检方式6.1 用一张交叉表排查图表不一致所有图都画完之后可以建一张“图表元素——源头文档”的交叉表把每个关键数据项在系统流程图、DFD、数据字典、E-R 图、类图和测试用例表里的出现位置列出来逐行核对名称数据项系统流程图DFD数据字典E-R 图类图测试用例病人姓名出现数据流“病人信息”Shu-001病人实体name 属性用例输入挂号类型分支条件数据流“挂号信息”Shu-006挂号单实体ticket_type 属性合法/非法取值挂号单编号不涉及输出流BRD01-02挂号单主键ticket_id边界值 5 位数字核对方法很简单从 DFD 里挑一条核心数据流“病人信息”沿着数据字典找到定义再看 E-R 图的病人实体有没有对应字段最后看类图和测试用例是否使用同一名称。只要某一行在任意两列里对不上就是需要修订的地方。这一步花 15 分钟能规避答辩时一半的质疑。6.2 在 Word 里嵌入 Excel 数据字典的正确方式学校如果要求“数据字典用 Excel 写”正确的动作是把数据字典按编号、名称、别名、类型、宽度、取值范围六列整理成 xlsx在 Word 中定位到数据字典章节选择“插入 → 对象 → 由文件创建”浏览选中 xlsx 文件勾选“显示为图标”则文档里不占版面双击可展开取消勾选“链接到文件”避免文件移动后 Word 里的对象失效。如果直接把 Excel 表格截图放进去评阅老师双击无法编辑会被认定文档编制不规范。还有一个小问题嵌入前把 Excel 的网格线关掉打印出来会更干净“插入——对象——由文件创建——浏览——插入——确定”这条菜单路径在 Word 2016 之后仍适用旧版 Word 的位置在“插入 → 对象”里的“新建”和“由文件创建”两个页签之间切换。6.3 交稿前最后过一遍的五处细节每张图下方加“图 X-XX 系统流程图”和图号正文里第一次出现该图时必须引用同一个图号DFD 第 0 层和第 1 层的数据流名逐一对照测试用例表里的输入值必须能在数据字典的取值范围里找到依据图里的文字注释统一用中文避免一部分英文一部分中文造成歧义StarUML 生成的图导出为高分辨率图片再插入 Word避免打印后线条发虚。图表编号本身应该贯穿始终系统流程图编号从第 5 章开始排E-R 图从第 6 章排面向对象四张图按小节号排如果报告修改过程中删掉一张图所有后续编号都要顺延。最后把代码、建模文件和 PDF 版报告放进同一个文件夹压缩包命名格式建议是“医院在线预约系统_学号_姓名_课设”这样不管是线上提交还是打印装订都省去再次沟通的时间。本文还有配套的精品资源点击获取