ARTICLE · 1296034
AI赋能软件工程教学探索:时序图与协作图的多轮迭代实践
AI赋能软件工程教学探索:时序图与协作图的多轮迭代实践在软件工程教学中，时序图和协作图是理解系统动态行为的核心工具。但传统教学有一个长期痛点：学生往往把大量时间花在绘图工具的语法细节上，比如箭头怎么画、生命线怎么对齐、控制焦点多长合适。真正应该花时间的业务逻辑分析、消息粒度推敲、对象职责分配，反而被挤占了。 大模型的出现，让这件事有了重新设计的可能。它不是替代学生思考，而是把"绘图员"的工作接过去，让学生腾出手来扮演"设计师"和"审查者"。 本文介绍一套基于大模型的实践教学方案，以注塑车间生产工单执行系统为贯穿案例，展示"生成—审查—选择—细化—转换"的完整闭环。 某电子配件工厂的注塑车间，每天根据ERP下发的生产工单进行生产。工单包含产品型号、计划数量、用料规格、工艺参数等信息。车间现场有操作工、注塑机、质检员、仓库等角色，系统需要协调这些资源完成生产任务。 从前期完成的用例图中，选取一个核心用例作为本次实践的绘制对象： 用例名称：执行生产工单 外部参与者：车间操作工、注塑机、质检员、仓库管理员 简要描述：操作工领取工单后，从仓库领料，在注塑机上执行生产，过程中记录产量和异常，生产完成后提交质检。 主路径业务逻辑： 操作工登录系统，查看当日待执行工单 操作工选择工单，系统校验工单状态是否为"已下达" 操作工发起领料申请，系统向仓库发送领料请求 仓库管理员确认出库，系统扣减库存并生成领料记录 操作工在注塑机上加载工单，系统向设备下发工艺参数 注塑机确认参数接收，开始生产 生产过程中，操作工每完成一批次，上报产量 系统累计产量，达到工单数量时自动标记工单完成 操作工提交完工报检，系统生成质检任务并通知质检员 这个案例的价值在于：它不是纯软件系统，涉及人和设备的交互。学生必须思考"注塑机作为参与者，消息是主动上报还是被动查询""设备故障时系统如何感知"这类真实问题，比"用户点击按钮，系统返回结果"的纯CRUD场景更有训练价值。 学生回顾前期完成的用例图，提取三个关键要素作为提示词输入： 同时，教师需要提供一份标准时序图的格式参考，包括对象命名规范、消息方向、生命线与控制焦点的画法等。学生将上述要素连同格式参考一并提交给大模型，生成初始时序图。 提示词案例： 你是一名资深软件架构师。请根据以下用例信息生成一份标准UML时序图。 用例名称：执行生产工单 外部参与者：车间操作工、注塑机、质检员、仓库管理员 简要描述：操作工领取工单后，从仓库领料，在注塑机上执行生产，过程中记录产量和异常，生产完成后提交质检。 主路径业务逻辑： 操作工登录系统，查看当日待执行工单 操作工选择工单，系统校验工单状态是否为"已下达" 操作工发起领料申请，系统向仓库发送领料请求 仓库管理员确认出库，系统扣减库存并生成领料记录 操作工在注塑机上加载工单，系统向设备下发工艺参数 注塑机确认参数接收，开始生产 生产过程中，操作工每完成一批次，上报产量 系统累计产量，达到工单数量时自动标记工单完成 操作工提交完工报检，系统生成质检任务并通知质检员 输出要求： 约束： 生成结果不能直接使用。学生需要要求大模型切换角色，以资深软件架构师的身份对时序图进行审查，重点检查： 比如大模型可能会指出："向设备下发工艺参数这条消息的接收对象是注塑机，但注塑机作为设备参与者，应该有一个接收工艺参数的同步调用和参数确认的返回消息，当前图中缺少返回分支。" 这一步的目的不是让大模型"改对"，而是让学生看到审查的维度，学会用架构师的视角审视自己的设计。 提示词案例： 你现在是一名资深软件架构师。请审查下面这份UML时序图。 用例名称：执行生产工单 外部参与者：车间操作工、注塑机、质检员、仓库管理员 时序图内容： 在此粘贴上一轮生成的时序图 请按以下维度逐项审查： 输出要求： 约束： 一个用例往往不止一条执行路径。大模型可以列出"执行生产工单"的所有可能路径： 多业务路径对比 学生需要从中选择与自身认知最接近的一条，作为当前时序图的细化方向。这个选择本身就是对业务理解的检验。如果学生选错了路径，说明他对用例的理解存在偏差。 提示词案例： 请基于用例"执行生产工单"，列出该用例所有可能的业务执行路径。 输出要求： 约束： 选定路径后，学生需要对时序图中的消息进行逐层细化。以"设备故障"路径为例： 每细化一轮，就重新提交给大模型进行审查，形成"细化—审查—再细化"的迭代循环。每一轮迭代，学生都要回答三个问题： 最终形成的不是一张"看起来对的图"，而是一张学生能逐条解释每一条消息存在理由的图。 提示词案例： 我选择了"设备故障"这条异常路径进行细化。请基于当前时序图，对以下消息进行逐层细化： 当前消息： 输出要求： 约束： 在整个过程中，学生不是被动接受大模型的输出，而是需要主动完成以下检查： 学生检查清单 提示词案例： 请根据以下检查清单，对当前时序图进行最终核查： 对象完整性：参与者、边界对象、控制对象、实体对象是否齐全 命名规范性：对象和消息命名是否符合小驼峰和动词短语约定 路径覆盖度：主路径、备选路径、异常路径是否都有对应时序图 消息粒度：消息是否过粗或过细 逻辑一致性：时序图与用例描述是否一致 设计可解释性：关键消息是否能回溯到用例步骤或类图关系 输出要求： 约束： 时序图定稿后，进入协作图环节。学生把前面完成的完整类图提交给大模型，类图包含以下核心类： 类图要素 WorkOrder 工单：存储工单信息、状态 ProductionRecord 生产记录：记录产量、工时、异常 MaterialIssue 领料单：记录领料明细 WarehouseStock 库存：管理物料库存 InjectionMachine 注塑机：接收工艺参数、上报状态 QualityInspection 质检任务：记录质检结果 Operator 操作工：发起操作，关联工单与生产记录 大模型根据类图中的类、关联关系、聚合或组合关系，生成对应的协作图，并将时序图中确定的消息流映射到协作图的对象链接上。然后以软件架构师标准审查： 对象链接是否都有对应的类关系？ 消息编号顺序是否与时序图一致？ 是否存在"孤岛对象"，即在协作图中没有参与任何消息交互的类？ 最后由学生做最终决策：协作图中的对象组织方式是否合理，哪些链接可以合并或拆分。 这个环节最关键的思考是：时序图强调时间顺序，协作图强调对象间的结构关系。让学生对比两张图——时序图中"操作工→系统→设备"的时间流，在协作图中变成了"Operator—WorkOrder—InjectionMachine"的对象链接结构，哪种视图更能体现"设备是独立参与者"这一设计意图？这种对比本身就是对两种建模视角的深度理解。 提示词案例： 请根据以下类图和时序图，生成对应的UML协作图。 类图内容： 在此粘贴学生完成的类图 时序图内容： 在此粘贴上一环节定稿的时序图 输出要求： 约束： 错误1：参与者与类混淆 表现：把操作工、注塑机直接画成系统内部类。 纠正方法：先区分外部参与者和系统内部对象，参与者只出现在用例边界之外。 错误2：消息命名模糊 表现：使用"处理""管理""负责"等动词。 纠正方法：改为"提交领料申请""确认出库""下发工艺参数"等具体动作。 错误3：只有调用没有返回 表现：同步调用后缺少返回消息。 纠正方法：补上返回消息，并说明返回内容，如"返回库存不足提示"。 错误4：控制对象承担过多职责 表现：某个控制器包揽所有业务逻辑。 纠正方法：把职责拆分到实体对象或专门的服务对象，避免上帝对象。 错误5：异常路径缺失 表现：只在文字里写异常，时序图中不体现。 纠正方法：为关键异常路径单独绘制或扩展时序图。 错误6：协作图链接无依据 表现：对象之间有消息，但类图中没有对应关系。 纠正方法：回到类图补全关联、聚合或组合关系。 错误7：消息粒度过粗或过细 表现：一条消息涵盖整个业务，或拆成过多琐碎调用。 纠正方法：以"一次完整交互"为单位调整粒度。 错误8：上帝对象 表现：某个对象与几乎所有对象通信。 纠正方法：检查是否可以通过中间对象或服务拆分职责。 让大模型生成好版本和有缺陷版本，学生找差异。 提示词：请根据同一用例"执行生产工单"，生成两份时序图：一份是符合规范的高质量版本，另一份包含至少3处常见设计缺陷，如消息命名模糊、对象职责混淆、遗漏返回消息等。不要标注哪份有问题，让学生自行找出缺陷并说明原因。 学生互评，再由大模型做第三方仲裁。 提示词：以下是两位学生分别提交的时序图，请以软件架构师身份进行第三方评审，指出各自优点和问题，并给出评分和修改建议。 给时序图，让学生反推用例描述和类图。 提示词：以下是某系统的时序图，请根据这张时序图，反推该用例的名称、外部参与者、简要描述和主路径业务逻辑，并列出可能对应的类图。 教师在提示词中埋漏洞，看学生能否发现。 提示词：以下是我故意埋入缺陷的时序图，请找出其中至少5处问题，包括对象命名、消息方向、控制焦点、路径覆盖和职责分配方面的问题。 记录每轮修改理由，让思考过程可追溯。 提示词：请根据以下三轮时序图修改记录，整理一份迭代日志，列出每一轮修改的内容、修改理由和尚未解决的问题。 优秀：参与者、边界/控制/实体对象齐全，职责清晰 合格：主要对象齐全，个别职责模糊 待改进：遗漏关键对象或混淆参与者与类 优秀：对象和消息命名准确、一致，符合约定 合格：命名基本规范，偶有模糊 待改进：命名随意，无法反映职责 优秀：消息方向、类型、粒度均正确，返回消息完整 合格：主路径消息正确，偶有遗漏 待改进：消息方向错误或大量遗漏 优秀：主路径、备选路径、异常路径均有覆盖 合格：主路径完整，备选路径部分覆盖 待改进：仅有主路径，无异常处理 优秀：控制焦点起止准确，反映对象活跃时段 合格：控制焦点基本完整，个别不准确 待改进：控制焦点缺失或位置错误 优秀：时序图与用例描述、类图完全一致 合格：基本一致，偶有偏差 待改进：与用例或类图存在明显矛盾 优秀：能清晰解释每条关键消息的存在理由和设计选择 合格：能解释大部分设计，少数说不清 待改进：无法说明设计依据 优秀：对象齐全，链接均有类图依据，无孤岛对象 合格：主要对象和链接正确，偶有无依据链接 待改进：遗漏关键对象或链接无类图支撑 优秀：消息编号连续，顺序与时序图一致，嵌套清晰 合格：编号基本正确，偶有跳跃 待改进：编号混乱或与时间顺序矛盾 优秀：消息方向、参数、返回值均正确 合格：主路径消息正确，个别参数缺失 待改进：消息方向错误或大量遗漏 优秀：对象组织清晰，链接无冗余，职责分配合理 合格：结构基本合理，偶有冗余链接 待改进：结构混乱，存在明显冗余或缺失 优秀：所有链接都能在类图中找到对应关系 合格：大部分链接有依据，个别缺失 待改进：大量链接无法回溯到类图 优秀：能清晰解释对象组织和消息流向的设计理由 合格：能解释大部分设计，少数说不清 待改进：无法说明设计依据 前面的教学流程解决了"怎么画"的问题，但还有一个更深层的问题：怎么知道学生真的在进步？ 传统作业批改只能看到最终结果，看不到学生的思考过程。而多轮迭代恰好留下了痕迹——每一轮学生提交的修改理由、每一轮大模型指出的问题、学生最终采纳或拒绝哪些建议，这些都是思维成长的证据。 我们可以让大模型扮演"学习诊断者"，在每一轮迭代后自动分析学生当前的思维水平。下面以"执行生产工单"用例的时序图迭代为例，展示三轮迭代中学生思维的演进过程。 学生典型表现 第一轮学生提交的时序图往往存在以下特征： 对象命名随意，比如用"系统""页面""数据库"这种模糊名称 消息命名使用"处理""管理""负责"等笼统动词 只有主路径，没有考虑异常分支 同步调用后缺少返回消息 把操作工、注塑机等外部参与者直接画成系统内部类 大模型诊断提示词 以下是学生第一轮提交的时序图。请作为学习诊断者，分析该学生当前的思维水平。 用例名称：执行生产工单 时序图内容： 在此粘贴学生第一轮时序图 请从以下维度分析： 该学生是否理解参与者与系统内部对象的区别 该学生是否理解消息的方向和类型 该学生是否具备路径覆盖意识 该学生当前最需要突破的一个问题是什么 输出要求： 先给出总体判断 再逐条分析 最后给出一条最优先的改进建议 语气以鼓励为主，指出问题但不打击信心 思维特征 这一轮学生的核心任务是建立规范意识。他们往往凭直觉画图，不清楚UML的语法规则，也不清楚时序图与用例图、类图之间的约束关系。大模型的价值在于快速指出"哪里不对"，让学生从"画出来"进入"画对"的阶段。 学生典型表现 经过第一轮修改后，学生基本能画出语法正确的时序图，但设计质量仍然不高： 消息粒度不合理，一条消息涵盖整个业务流程 控制对象承担了过多职责，出现"上帝对象" 对象之间的职责分配不清晰，比如库存扣减由谁负责说不清 能画出主路径，但异常路径的处理过于简化 大模型诊断提示词 以下是学生第二轮提交的时序图。请作为学习诊断者，分析该学生当前的设计能力水平。 用例名称：执行生产工单 时序图内容： 在此粘贴学生第二轮时序图 请从以下维度分析： 消息粒度是否合理，是否存在过粗或过细的问题 对象职责分配是否合理，是否存在上帝对象 异常路径的处理是否完整 该学生是否开始关注设计质量而非仅仅是语法正确 输出要求： 指出学生相比第一轮的进步 指出当前最影响设计质量的1-2个问题 给出具体的改进方向，而不是笼统地说"需要优化" 如果学生已经表现出良好的设计意识，要明确肯定 思维特征 这一轮学生的核心任务是建立设计意识。他们开始意识到"画对"只是底线，"画好"才是目标。关键转变是从"这条消息怎么画"转向"这条消息该不该存在""这个对象该不该承担这个职责"。这是从绘图员思维向设计师思维的过渡。 学生典型表现 第三轮的学生已经能画出质量不错的时序图，但还差最后一步：能解释自己的设计选择。比如： 为什么选择同步消息而不是异步消息 为什么把库存扣减放在领料单对象上而不是仓库对象上 为什么这条异常路径需要单独处理而另一条不需要 能画出来但说不清楚，说明理解还不够扎实。 大模型诊断提示词 以下是学生第三轮提交的时序图及其修改说明。请作为学习诊断者，评估该学生的设计可解释性。 用例名称：执行生产工单 时序图内容： 在此粘贴学生第三轮时序图 学生修改说明： 在此粘贴学生对本轮修改的理由说明 请从以下维度分析： 学生能否清晰解释每条关键消息的存在理由 学生能否说明对象职责分配的依据 学生能否说明路径选择的理由 学生的解释是真正理解还是套用模板 输出要求： 给出设计可解释性评分（1-5分） 指出哪些解释体现了真正的理解 指出哪些解释是套用模板或含糊其辞 给出提升可解释性的具体建议 思维特征 这一轮学生的核心任务是建立论证能力。软件工程没有唯一正确答案，好的设计需要能说明"为什么这样选"。能清晰解释设计选择的学生，说明他已经内化了建模思维，而不是在机械套用规则。 核心任务：掌握UML语法规则，区分参与者与系统内部对象 学生典型问题：语法错误、概念混淆、命名随意 大模型角色：纠错者，快速指出不符合规范的地方 教师介入：仅在出现集中性共性问题时做简要提示，不做逐份批改 核心任务：关注消息粒度、对象职责分配、路径覆盖完整性 学生典型问题：上帝对象、职责不清、异常处理简化 大模型角色：审查者，从设计质量角度给出改进建议 教师介入：鼓励学生自主判断大模型的建议是否合理，不直接给答案 核心任务：能清晰解释自己的设计选择及其依据 学生典型问题：能画但说不清、套用模板、解释含糊 大模型角色：诊断者，评估设计可解释性并指出薄弱环节 教师介入：可选环节，对少数存在明显困惑的学生做个别交流 建议要求每位学生在提交最终成果时，附带一份迭代日志，记录三轮修改的过程。模板如下： 初始问题：大模型指出的主要问题 我的修改：我做了什么修改 我的困惑：我还不清楚的地方 上一轮遗留问题：哪些问题没有解决 本轮新问题：大模型新指出的问题 我的设计选择：我为什么这样改 我的困惑：仍然不确定的地方 最终设计说明：我为什么选择这个方案 放弃的备选方案：我考虑过但没采用的方案及原因 仍然存疑的问题：如果还有时间，我想继续探索什么 这份日志本身就是评分的重要依据。它让教师看到学生的思考轨迹，也让大模型的诊断有据可依。 这套教学方案在实践中暴露出几个值得深入反思的问题。 最容易被误解的一点是：这套方案会不会让学生过度依赖大模型，离开大模型就不会画图了？ 实际观察到的情况恰恰相反。当大模型承担了"绘图员"的工作后，学生反而需要更多地思考"为什么要这样画"。因为大模型生成的图不是最终答案，而是审查和讨论的起点。学生必须判断大模型给出的建议是否合理，必须为自己的设计选择辩护。这个过程比"照着教材画一张标准答案"要费脑子得多。 关键不在于用不用大模型，而在于怎么定义作业的目标。如果目标是"画出一张正确的时序图"，大模型确实可以代劳。但如果目标是"理解为什么这张时序图是正确的"，大模型反而是一个高效的陪练——它能在几秒钟内给出三种不同视角的审查意见，这是传统课堂做不到的。 "注塑车间生产工单执行系统"这个案例的价值，不在于它有多复杂，而在于它逼学生面对真实世界的模糊性。 纯软件系统的用例往往太干净：用户点击按钮，系统返回结果，结束。学生不需要思考"如果设备故障了怎么办""如果库存数据不一致怎么办"。而注塑车间这个场景天然涉及人和设备的协作，涉及物理世界的约束——设备可能离线、参数可能下发失败、物料可能缺料。这些不确定性不是教师硬塞进去的，而是业务本身自带的。 这带来一个启示：软件工程教学的案例，不应该追求"大而全"，而应该追求"有摩擦"。有摩擦的案例才能逼出真实的设计思考。一个涉及设备交互的简单用例，比一个纯CRUD的复杂系统更有训练价值。 本文给出的评分量规是一个参考框架，但实际使用时需要注意两个问题： 第一，量规不能替代教师判断。 大模型可以按量规打分，但分数背后的原因需要教师来解读。比如两个学生都得了75分，一个是因为路径覆盖不全，一个是因为设计可解释性不足，他们需要的帮助完全不同。 第二，量规本身需要迭代。 不同学校、不同专业方向的学生基础不同，量规的权重和标准需要调整。建议教师在使用一两个学期后，根据实际数据适当调整量规，不必一开始就追求完美。 这套方案最终指向一个更大的问题：软件工程教学到底在教什么？ 如果只教"怎么画时序图"，那本质上是在教一种符号语言。学生学会了UML的语法，但未必理解建模的本质。建模的本质是用抽象的方式刻画系统的关键结构和行为，以便在动手实现之前发现设计问题。 时序图和协作图只是载体，真正的目标是让学生具备以下能力： 能从一段模糊的业务描述中识别出关键对象和职责 能判断一个设计是否合理，而不是凭感觉 能用结构化的方式表达自己的设计思路 能在多种备选方案中做出有依据的选择 大模型在这个过程中的角色，不是"教会学生画图"，而是加速学生从"会画"到"会想"的转变。它把机械性的工作接过去，把思考性的工作留给学生。 这套方案并不要求教师全程深度介入。相反，它的设计初衷就是让教师从重复性劳动中解放出来。 大模型承担了初筛、诊断、建议的大部分工作，学生通过多轮自主迭代逐步完善设计。教师只需要在关键节点做轻量级的介入——比如发现全班普遍卡在某个概念上时，用几分钟集中说明一下；或者对个别学生明显走偏时，给一两句点拨。 这意味着教师可以把更多精力放在案例设计和流程编排上，而不是陷在逐份批改的作业堆里。短期看需要适应新的节奏，但流程跑通之后，整体负担是下降的。 AI赋能教学不是一句口号，而是一套需要精心设计、反复调试的实践方案。本文介绍的这套方法，核心思路很简单：把大模型放进教学流程里，让它做它擅长的事，让学生做学生该做的事。 它不完美，还在迭代中。但它提供了一个可操作的起点——从一张用例图出发，经过多轮生成、审查、选择、细化、转换，最终让学生不仅画出一张时序图和协作图，更重要的是，画出了自己对系统设计的理解。 这大概就是软件工程教学最该追求的东西。 提示词案例： 请根据以下类图和时序图，生成对应的UML协作图。 类图内容： 在此粘贴学生完成的类图 时序图内容： 在此粘贴上一环节定稿的时序图 输出要求： 约束：
一、引言：为什么动态建模教学需要AI
二、贯穿案例：注塑车间生产工单执行系统
三、教学流程：从用例图到时序图的闭环
环节一：基于用例图生成初始时序图
外部参与者：谁在触发这个用例 用例名称与简要描述：要完成什么业务 业务处理逻辑：用例中的主要步骤
使用标准UML时序图表示 对象命名采用小驼峰，如 operator、injectionMachine、workOrder 区分参与者、边界对象、控制对象和实体对象 同步消息用实线箭头，返回消息用虚线箭头 标注生命线和控制焦点 消息命名使用动词短语，如"提交领料申请""确认出库" 先输出时序图，再用列表说明每个对象承担的职责
不得臆造用例中未出现的业务对象 如果信息不足，必须列出假设，而不是直接补全 每条消息必须标注调用方、接收方和消息类型 不得把外部参与者直接当作系统内部类
环节二：以资深软件架构师标准进行审查
对象命名是否准确反映系统职责，是否存在命名模糊或职责混淆 消息命名是否使用动词短语、是否清晰表达了调用意图 控制焦点是否完整，是否遗漏关键活跃时段 消息顺序是否符合业务逻辑的因果关系 返回消息和异常分支是否必要、是否遗漏
对象命名是否准确，是否存在职责混淆 消息命名是否清晰，是否使用动词短语 消息方向是否正确，调用方和接收方是否合理 控制焦点是否完整，是否遗漏了关键活跃时段 消息顺序是否符合业务因果 是否遗漏了异常分支或返回消息
先列出发现的问题 再给出修改建议 最后输出修改后的时序图 不要直接说"没有问题"，必须至少提出3条改进意见
每条问题必须说明依据，来自用例描述、类图关系还是业务规则 修改前必须先指出问题，不能直接给新版本 不得新增用例和类图中未出现的对象，除非明确列为假设 如果存在多种合理设计，必须列出备选方案并说明取舍
环节三：多业务路径分析与选择
主路径：一切顺利，正常完工 备选路径：库存不足 → 提示缺料，工单挂起，通知采购 备选路径：工艺参数校验失败 → 设备拒绝接收，通知工艺工程师 异常路径：设备故障 → 暂停工单计时，生成维修工单 异常路径：质检不合格 → 标记批次不合格，触发返工或报废
区分主路径、备选路径和异常路径 每条路径给出触发条件 每条路径说明系统应如何处理 用列表形式输出
不得臆造用例中未出现的参与者或系统对象 如果某条路径依赖未给出的业务规则，必须标注为假设 每条路径必须能回溯到用例描述中的某个业务环节
环节四：消息级细化与多轮迭代
同步消息与异步消息是否正确区分？设备故障是主动上报还是系统轮询？ 返回消息是否必要、是否遗漏？ 条件分支是否完整覆盖？ 是否存在可以合并或拆分的消息？
这条消息为什么存在？能不能删？ 这个消息的粒度对不对？是不是太粗或太细？ 这个对象是不是承担了不该承担的职责？职责分配是否合理？
操作工上报设备故障 系统暂停工单计时 系统生成维修工单
区分同步消息和异步消息 补充必要的返回消息 补充条件分支，如"故障是否可自动恢复" 说明每条消息的调用方、接收方和消息类型 输出细化后的时序图 最后列出本轮新增或修改的消息，并说明修改理由
每条新增消息必须说明依据，来自用例、类图、业务规则还是合理假设 不得把外部参与者直接当作系统内部类 如果存在多种实现方式，必须列出备选方案 修改后必须说明本轮改动对对象职责分配的影响
环节五：学生检查清单
对象完整性：参与者、边界对象、控制对象、实体对象是否齐全 命名规范性：对象和消息命名是否符合约定 路径覆盖度：主路径、备选路径、异常路径是否都有对应时序图 消息粒度：消息是否过粗或太细 逻辑一致性：时序图与用例描述、类图是否一致 设计可解释性：每条关键消息能否说明存在理由
逐项给出检查结果 对不满足的项说明原因 给出修改建议 最后给出一个总体评价
不得为了"看起来完整"而补造不存在的对象 如果某项无法判断，必须说明缺少哪些信息 所有建议必须能回溯到用例、类图或业务规则
四、从时序图到协作图：基于类图的转换
列出协作图中的对象及其对应类 列出对象之间的链接，并说明对应的类关系 按消息编号顺序列出消息流 检查是否存在孤岛对象 输出协作图 最后对比时序图和协作图，说明两种视图各自更适合表达什么信息
协作图中的每个对象链接必须能在类图中找到对应关系 不得新增类图中未出现的类 如果时序图中的消息无法映射到类关系，必须说明原因 如果存在多种映射方式，必须列出备选方案
五、常见错误对照与进阶策略
学生常见错误对照
五个提升学生能力的进阶策略
策略1：对比学习
策略2：交叉审查
策略3：反向推导
策略4：错误注入
策略5：迭代日志
六、评分量规：时序图与协作图
时序图评分量规（满分100分）
维度一：对象完整性（权重15%）
维度二：命名规范性（权重10%）
维度三：消息正确性（权重25%）
维度四：路径覆盖度（权重20%）
维度五：控制焦点（权重10%）
维度六：逻辑一致性（权重10%）
维度七：设计可解释性（权重10%）
协作图评分量规（满分100分）
维度一：对象与链接（权重20%）
维度二：消息编号与顺序（权重20%）
维度三：消息正确性（权重25%）
维度四：结构合理性（权重15%）
维度五：与类图一致性（权重10%）
维度六：设计可解释性（权重10%）
七、学生能力成长分析：用大模型做思维诊断
第一轮：从"画出来"到"画对"
第二轮：从"画对"到"画好"
第三轮：从"画好"到"说得清"
三轮迭代的思维演进总结
第一轮：建立规范意识
第二轮：建立设计意识
第三轮：建立论证能力
迭代日志模板
迭代日志
第一轮
第二轮
第三轮
八、教学反思
反思一：大模型是拐杖还是引擎
反思二：案例选择决定训练深度
反思三：评分量规的局限性
反思四：从"教画图"到"教建模"
反思五：对教师角色的重新定位
结语
列出协作图中的对象及其对应类 列出对象之间的链接，并说明对应的类关系 按消息编号顺序列出消息流 检查是否存在孤岛对象 输出协作图 最后对比时序图和协作图，说明两种视图各自更适合表达什么信息
协作图中的每个对象链接必须能在类图中找到对应
