高中信息技术《交互实验系统架构》单元教案

高中信息技术《交互实验系统架构》单元教案

一、教学背景分析

（一）课标要求与学科定位

本单元依据《普通高中信息技术课程标准（2017年版2020年修订）》模块2“信息系统与社会”研制，对应内容要求“3.1理解信息系统的组成与功能，能描述信息系统的分层架构”“3.3通过设计与开发简单的信息系统，体验系统开发过程，掌握模块化设计方法”。课标在学业质量水平3-2中明确指出：学生应能基于实际问题，设计信息系统的逻辑架构，并使用适当的开发工具实现原型。本设计以交互实验系统为学科载体，将物理实验需求转化为信息技术学科问题，精准落实信息意识、计算思维、数字化学习与创新、信息社会责任四维核心素养。

（二）教材二次开发思路

现行主流教材（教科版必修2第四章、粤教版第三章）均以商业信息系统（如图书管理系统、在线购物网站）为主要案例，侧重数据库操作与网络应用开发，对科学实验类、实时交互类信息系统涉及较少。本单元对教材进行结构化增补：保留教材中“三层架构”“接口设计”等核心概念，置换案例情境为物理单摆仿真、化学滴定模拟等跨学科实验，同时引入p5.js实时可视化、MongoDB非结构化存储等适配实验场景的技术栈，形成“理论—架构—编码—测试”的完整学材链条。

（三）学情精准画像

授课对象为高中二年级选考理科或技术方向学生，具备以下特征：

1.知识储备：已完成Python程序设计基础（变量、分支、循环、函数），了解HTTP协议基本概念，能读懂简单HTML/CSS代码。约30%学生通过社团接触过传感器或物联网设备。

2.思维特征：擅长算法细节实现（如解物理题时写出运动方程），但缺乏系统级抽象能力，常将界面代码与业务逻辑混杂，对“分层”“接口”“耦合”等术语仅停留在字面理解。

3.典型困难：【难点】从“编写函数解决问题”向“设计模块服务他人”的角色转换困难；【难点】对异步非阻塞通信存在认知冲突（认为代码应从上到下顺序执行）。

4.学习偏好：对可视化、可操作的实验类应用有强烈兴趣，乐于通过“改参数看效果”的方式试错。

（四）教学目标体系

【基础】能复述交互实验系统三层架构（表示层、业务逻辑层、数据访问层）的名称与核心职责。

【重要】能根据给定的实验需求，绘制包含模块划分、接口标注的高层架构流程图。

【非常重要】能使用Flask框架将物理公式封装为API，供前端调用；能使用p5.js实现滑块交互与画布实时绘制；能通过MongoDB实现实验数据的持久化存储与回放。

【高频考点】区分同步请求与异步请求对用户体验的影响；列举至少三种API设计规范（URL命名、状态码、错误处理）。

【热点】能针对典型性能瓶颈（高频请求、大数据量传输）提出优化策略（防抖、索引、数据压缩）。

【难点】能在团队协作中依据架构图进行分工，并通过接口文档实现前后端并行开发。

（五）教学重点与难点

【教学重点】三层架构模型中各层职责及层间接口定义方法。

【高频考点】RESTfulAPI设计、JSON数据交换格式、fetch异步请求。

【难点】业务逻辑层中复杂实验算法的模块化封装与扩展性预留；异步编程中Promise状态流转与错误捕获。

【非常重要】贯穿全程的系统化思维——从“写代码”到“建系统”的观念跃迁。

二、教学实施过程

（一）第一课时：系统架构初探——从需求到模块（45分钟）

1.导入环节（5分钟）

教师启动本地运行的“三维单摆可视化模拟器”，该模拟器具备参数滑块、实时波形、实验记录导出三大功能区。教师依次将摆长从0.5米拖拽至1.5米，摆球摆动频率明显减慢；切换重力加速度为月球重力1.6m/s²，摆动愈发舒缓。教师提问：“这个看似神奇的软件，其实由三大‘部门’协作完成。大家猜猜是哪三个部门？”学生回答“界面部门”“计算部门”“存储部门”。教师顺势将学生回答提炼为专业术语：表示层、业务逻辑层、数据访问层，并板书核心问题——“如何划分才能使三个部门高效又不互相干扰？”

2.概念建模与类比迁移（10分钟）

教师放弃直接讲授定义，转而采用“校园一卡通充值系统”组织类比推理。设问：“你去人工窗口充值，谁负责接待你？（前台）谁负责确认金额并记账？（财务）谁负责把新余额存进卡片芯片？（数据写入）”学生快速匹配三层角色。教师进一步追问：“如果财务人员请假，前台能否自己决定给你加100元？”学生大笑：“不行，权限不对！”——由此自然导出【非常重要】“职责分离”原则。教师总结：软件架构的核心不是技术栈，而是职责边界。

3.案例拆解与反向工程（15分钟）

分组（4人/组）发放“神秘代码盲盒”，每组获得一个完整交互实验系统的部分源代码片段（故意混合HTML、Python、SQL语句）。任务1：将15张写有代码行的卡片按层分类，贴在大白纸的相应区域。任务2：用红色箭头标出跨层函数调用关系，用蓝色箭头标出数据返回路径。【重要】教师提供“数据字典”卡片辅助识别（如“render_template”属于表示层，“db.session.execute”属于数据访问层）。巡视中发现普遍争议：部分学生认为所有数学计算都属于业务逻辑层，教师以“前端JavaScript也可能执行Math.sqrt”为例，阐明“物理位置”与“逻辑职责”的区别——即使计算写在HTML的<script>标签内，从架构视角仍应视作表示层的一部分，业务逻辑层特指服务器端封装的领域服务。【难点突破】

4.架构图绘制与互评（10分钟）

各组针对本组案例绘制高层架构图，必须包含至少三个功能模块、模块间数据流方向及接口协议（HTTP、SQL、文件I/O）。教师提供半结构化画纸，左侧预留“用户故事”区域，要求学生先写下一句典型用户操作（如“学生拖动滑块观察振幅衰减”），再从该操作出发绘制数据穿越三层的完整路径。【基础】展示环节采用画廊漫步法：每组留一人驻守讲解，其余成员流动观摩，使用便利贴在别组图纸上写“我发现……”与“我建议……”。教师抓拍典型架构图（如把数据库画在业务层内部、遗漏表示层等），在最后5分钟集中辨析。

5.作业与预习定向（5分钟）

观看教师自制微课《从面包板到系统板——分层架构演化简史》，在云班课提交一段60秒语音，回答：“如果没有分层，开发单摆模拟器会遇到哪些麻烦？”预习Flask官方文档中关于路由（route）的最简示例，思考@app.route背后的设计意图。

（二）第二课时：业务逻辑层——实验算法的服务化封装（45分钟）

1.复习与认知冲突创设（5分钟）

教师展示两段代码：代码A将周期计算写在HTML的<buttononclick>属性里，代码B将相同计算写在Flask的@app.route装饰函数中。运行对比：代码A修改公式需同时修改20个按钮，代码B只需修改一处。教师追问：“两种写法都能算出周期，为什么行业共识抛弃代码A？”学生立即联系上节课“高内聚低耦合”原则，回答：“代码A把计算逻辑分散了，维护成本高。”教师肯定并板书本课核心命题——【非常重要】业务逻辑层即“可复用的领域服务层”。

2.API设计原理与Flask路由精讲（12分钟）

教师以“餐厅后厨”为隐喻展开：表示层是点餐Pad，业务逻辑层是厨师团队，API则是窗口递出的点菜单。菜单必须格式规范（JSON）、菜品名称明确（URL端点）、口味要求清晰（请求参数）、出菜顺序可控（HTTP方法）。教师现场编写FlaskAPI三步曲：

（1）导入Flask，实例化app；

（2）定义函数，上方装饰@app.route('/api/period',methods=['POST'])；

（3）从request.get_json()提取参数，计算后jsonify返回。

同时展示错误版本：忘记设置methods=['POST']导致405错误；直接返回字符串而非jsonify导致前端解析失败。学生第一次亲眼看到“接口返回的不是纯JSON”时引发的fetch报错，对API格式严谨性产生深刻印象。【高频考点】

3.脚手架编程：从物理公式到API端点（15分钟）

学生获得以下项目骨架：

pendulum_backend/

├──app.py#Flask主程序（含空路由）

├──physics.py#空文件，待补充公式

└──test_requests.py#本地测试脚本

任务阶梯：

[1]在physics.py中实现calculate_period(length,gravity)，使用math.sqrt返回浮点值。完成单个函数单元测试（assert几乎相等）。

[2]在app.py中导入该函数，完善/api/period路由：解析JSON，捕获KeyError返回400及错误信息，正常时返回{"period":value}。

[3]使用ThunderClient模拟POST请求，验证不同参数下的输出正确性。

教师巡视发现三类典型错误：①混淆请求体格式——发送了FormData而非RawJSON；②忘记jsonify，直接returnstr(period)导致前端无法解析；③未处理零或负数，产生复数周期（math.sqrt(-1)抛出ValueError）。教师立即组织2分钟“bug急救会”，邀请两位学生演示调试过程：在VSCode终端查看Flask实时日志，添加print(data)定位参数接收情况。【重要】集体总结：API的第一要务不是实现功能，而是稳健地处理异常输入。

1.拓展思辨：算法升级对架构的冲击（8分钟）

教师抛出挑战：“假如王老师要求模拟真实空气阻力，运动方程变成二阶非线性微分方程，无法写出解析解，必须每帧数值积分。我们的业务逻辑层会变成什么样？”小组讨论后形成共识：原有单函数膨胀为数十行数值求解类；可能引入SciPy等外部库；单一API路由可能分拆为“初始化仿真”“步进计算”“终止仿真”等多个端点。教师进而引入【热点】微服务概念——当业务逻辑层过重时，可将数值引擎独立部署为计算微服务，通过RPC或消息队列与主业务层通信。本课虽不实现，但学生已理解架构演进的必然性。

2.形成性测验与即时反馈（5分钟）

问卷星推送4道选择题，重点检测：

（1）RESTful风格中更新资源应使用（PUT/POST）——混淆项辨析。

（2）Flask中获取请求体JSON的正确方法——干扰项request.args、request.form。

（3）业务逻辑层不应包含以下哪项职责？（数据表结构定义/科学公式计算/事务脚本执行/输入合法性校验）——正确答案是数据表结构定义，应属于数据访问层。

全班正确率86%，对（1）的错误集中在“更新操作用POST”，教师当即补充：虽然POST也可更新，但PUT幂等性更符合REST规范，并预告下节课幂等性在重试机制中的价值。

（三）第三课时：表示层与数据访问层——双向交互与记忆留存（45分钟）

1.表示层交互范式：从“能看”到“好用”（10分钟）

教师并行展示两个单摆前端：A版仅画布+滑块，无任何数值标签；B版滑块上方实时显示当前摆长/重力值，画布坐标轴随数据范围自动缩放，按钮有按下状态反馈。学生通过投票器一致选择B版。教师归纳三条【重要】黄金法则：

（1）状态可见：用户随时知道系统在做什么（正在计算/等待网络/完成保存）。

（2）符合预期：滑块移动与摆球摆动方向、幅度成合理映射，不反直觉。

（3）容错引导：输入负数时不清屏崩溃，而是弹出非模态提示并回退到上次合法值。

随后教师引入p5.js，现场编写20行代码——setup创建画布，draw绘制摆球，mouseDragged改变摆长，瞬时完成简易物理模拟。学生惊叹于可视化门槛之低，对后续任务充满期待。

2.异步心脏：fetch与await实战（12分钟）

教师以“现场电话订餐”情境剧演绎同步与异步：学生A（客户）致电餐厅，必须等厨师做完菜挂电话才能再打电话给别人（同步阻塞）；学生B（客户）下订单后挂断，厨师做好后回电通知（异步非阻塞）。学生立即领悟异步对UI流畅性的关键作用。接着展示fetch核心范式：

javascript

asyncfunctiongetPeriod(){

try{

constres=awaitfetch('/api/period',{method:'POST',body:...});

constdata=awaitres.json();

period=data.period;

}catch(err){

console.error('网络故障',err);

}

}

教师拆解：await暂停函数执行但不阻塞主线程，res.json()亦返回Promise；try/catch是防御性编程必须。学生对照半成品前端（sketch.js），在滑块事件中调用该函数，并通过requestAnimationFrame驱动画布更新。【非常重要】

1.联调攻坚：打通前端与业务层（10分钟）

各组前端项目与Flask后端首次握手。典型问题爆发：

1.跨域（CORS）：浏览器拒绝从localhost:5500向localhost:5000发请求。教师演示安装flask-cors扩展，三行代码解决问题，并简述CORS是浏览器安全策略而非服务器限制。

2.数据格式不匹配：前端发送{length:1.0,gravity:9.8}，后端request.get_json()解析正常，但有些组误写JSON.stringify({length,gravity})时未指定同名变量，产生{length:undefined}。教师引导对比Network面板的请求负载与后端打印，学生自行发现变量未定义错误。

3.画布不更新：已成功获取周期，但draw()中依旧使用初始周期。根源在于period变量未在全局作用域更新，或更新后未触发重绘（p5.js自动每帧执行draw，但周期未参与运动计算）。教师提示在fetch回调末尾添加redraw()（p5.js强制重绘函数）。【难点】这一环节耗时最多，但学生通过真实踩坑，对异步状态同步建立了肌肉记忆。

1.数据访问层：从内存到硬盘（8分钟）

教师提问：“我现在关机重启，刚才保存的实验记录还在吗？”学生齐答“不在了”。教师引出数据库，并采用“非结构化实验数据天然适合NoSQL”的观点，简介MongoDB文档模型。现场演示：通过pymongo插入一条实验记录，然后立刻查询并打印。学生看到字典结构随意增减字段（如添加“备注”），无需事先建表，立刻理解文档数据库对科研原型验证的优势。【基础】教师提供封装好的db.py，包含save_experiment(doc)与list_experiments()函数，学生只需在app.py新增两个路由调用它们。约80%组在5分钟内完成保存接口并从前端成功调用。

2.完整闭环展示与同伴诊断（5分钟）

每组轮流演示“参数调节→保存实验→刷新页面→从历史列表加载→波形复原”全流程。教师采用课堂应答系统发起快速投票：“哪组的加载速度最快？”“哪组的错误提示最友好？”同伴互评数据实时生成词云，学生自发关注到异常处理细节（如未开启MongoDB服务时的友好提示）。教师总结：今日不仅给系统装上了“手”（交互）和“脑”（算法），更赋予了“记忆”（持久化）。

（四）第四课时：系统集成与发布——从原型到最小可行性产品（45分钟）

1.测试文化浸润（8分钟）

教师不急于发布，先提出“无测试，不交付”。展示2018年欧洲核子研究中心控制界面因浮点数精度导致实验数据异常的真实案例，学生肃然。随后实践轻量级测试策略：

（1）单元测试：在physics.py末尾添加ifname=='main':块，写入assert语句验证边界条件（摆长=0应触发异常，周期公式输入极大值不溢出）。

（2）集成测试：提供Checklist，含8条手工测试用例（如“保存空参数”“极速拖动滑块100次”“数据库断连时点击保存”），小组逐项执行并记录PASS/FAIL。【重要】学生发现，自己编写时从未考虑后端未启动时前端的报错信息竟是一串英文堆栈，立即添加catch提示语。

2.性能与安全：工程师的进阶修养（8分钟）

（1）性能：【热点】教师使用ChromePerformance面板录制滑块拖动过程，发现每100ms发一次请求，大量请求Pending。学生提出两种优化：①将滑块事件从input改为change（松手触发）；②引入lodash.debounce，延迟到停止滑动200ms后发送。教师演示debounce实现原理（定时器清除与重设），学生修改一行代码即解决卡顿。

（2）安全：【非常重要】业务逻辑层当前无条件信任前端传参。教师构造恶意请求：POST{"length":-2,"gravity":0}，后端崩溃（ZeroDivisionError）。学生紧急修复：在API入口校验参数范围，若非正数则返回{"error":"长度和重力必须为正数"}，状态码422。教师引申：输入校验是第一道防线，绝不可省略。

（3）隐私：【高频考点】讨论本系统存储实验记录是否侵犯隐私。结论：记录仅含实验参数和时间戳，不涉及个人身份信息，符合数据最小化原则。教师预告高二下学期“信息安全与法律”模块将深入GDPR等法规。

3.敏捷迭代：应对真实用户反馈（15分钟）

教师扮演物理教师“张老师”，提出三条尖锐反馈：

（1）画布波形线太细，投影仪看不清楚；

（2）历史记录按照保存时间升序，最新实验反而在列表最下面；

（3）想导出实验数据为CSV，以便在Excel中画图。

各组进入“极限编程”模式，限时12分钟完成至少两项改进。现场气氛热烈：一组迅速将p5.js的strokeWeight调至3像素；二组修改后端list_experiments路由，添加.sort('timestamp',-1)；三组增加“导出CSV”按钮，在前端将实验数组拼接为Blob并触发download。教师巡回，鼓励组间技术援助。倒计时结束，近半数组完成全部三项，并现场演示导出功能，其他组观摩学习。教师总结：产品没有终点，只有不断响应变化的版本。【热点】

4.产品发布与文档归档（10分钟）

每组选择发布形式：

（1）桌面版：使用PyInstaller将Flask应用打包成单exe，连同前端静态文件生成便携包。

（2）局域网服务：使用ngrok暴露本地5000端口，生成临时公网URL，组间互扫访问。

教师强调发布不等于结束，必须撰写README.md，包含以下章节：

1.项目背景：一句话说明“本系统为高中物理单摆实验提供交互仿真”；

2.架构全景：复用第一课时绘制的架构图，标注技术栈（Flask、p5.js、MongoDB）；

3.快速开始：列举依赖安装命令（pipinstall-rrequirements.txt）；

4.操作演示：截取关键界面动图（LICEcap录制）；

5.团队分工与反思。

教师展示往届优秀文档范例，学生随即开工。由于课时紧张，文档主体作为课后团队作业，下节课前提交至GitLab仓库。

1.单元收官：概念图编织与自我评价（4分钟）

每位学生领取空白A4纸，独立绘制本单元概念图，必须包含：三层架构、API、JSON、异步、持久化、测试六个核心节点，并用连接词阐明关系。教师拍摄部分作品投影，差异性显著：学困生呈线性排列（表示层→API→业务层→数据层），学优生出现循环依赖标注、非功能性需求分支等。教师不做评分，仅强调“每个人的知识图谱都是独特的，看见自己的成长更重要”。最后，扫描二维码填写单元反思单，内含两道元认知问题：“你在哪个时刻感到最困惑？后来如何解决的？”“如果重新设计单摆系统，你会在哪一层做不同选择？”

三、教学评价设计

（一）过程性评价框架

本单元摒弃传统“平时分+卷面分”模式，构建基于学习分析技术的多模态评价：

1.代码仓库贡献度：通过GitInspector统计每名学生四次课的代码提交行数、文件修改范围、commit信息质量。重点关注【难点】异步编程阶段单人长时间无提交的“僵持期”，记录为后续辅导依据。

2.课堂会话分析：使用讯飞听见课堂转录系统，将小组讨论语音转为文本，通过词频分析捕捉“接口”“耦合”“请求”等术语出现频率，绘制小组概念建构热力图。

3.同伴反馈质量：在画廊漫步、互测环节，学生每一条便利贴评论均拍照上传至班级相册，教师从“具体性”“建设性”两个维度点赞优质反馈，积分纳入团队总分。

（二）终结性表现评价

项目作品评价量规（总分40分，占单元成绩60%）：

1.架构合理性（10分）：是否清晰遵循三层分离原则，业务逻辑层有无混入表示层代码；API设计是否符合RESTful风格。【非常重要】

2.功能完整性（12分）：参数交互、实时绘图、保存记录、回放历史四项基础功能是否稳健运行；是否实现至少一项拓展功能（如CSV导出、波形缩放）。

3.交互体验（8分）：滑块操作是否流畅无卡顿；错误提示是否通俗易懂（不显示Python异常堆栈）；界面布局是否适配不同分辨率