高中信息技术选择性必修一《抽象数据类型》教学设计-以“图书馆预约系统”为情境的单元重构教学

高中信息技术选择性必修一《抽象数据类型》教学设计——以“图书馆预约系统”为情境的单元重构教学一、教材分析与课标定位本节内容选自浙教版2019年版普通高中教科书《信息技术》选择性必修1“数据与数据结构”第四单元“数据结构与算法”中的4.3节。课标对本节的要求是“理解抽象数据类型的基本概念，能够用抽象数据类型描述具体问题中的数据组织方式”。教材在编排上，将抽象数据类型安排在数组、链表、栈、队列等具体数据结构之前，具有明显的“总起”功能。然而，教材文本对抽象数据类型的定义较为精炼，学生首次接触时容易陷入“概念记住了，但不知道有什么用”的困境。基于此，本设计对教材内容进行二次开发，以“图书馆预约系统”为贯穿全课的真实项目情境，将抽象数据类型的三要素（数据对象、数据关系、基本操作）放在具体问题中让学生自主建构。本课不是简单地把抽象数据类型作为“名词解释”来教，而是让学生经历“从现实问题中抽象出数据类型、用基本操作描述问题求解过程”的完整思维历程。学情方面，本课授课对象为高二年级选修信息技术的学生。学生在必修1中已学习过数据的采集、存储与编码，能够使用Python语言编写简单的程序，对“数据”有直观感知，但尚未形成“数据组织方式决定问题求解效率”的计算思维。抽样访谈显示，约65%的学生能举出“整数、字符串”等基本数据类型，但几乎无人能说清“自定义复合数据类型”的含义。这正是本课需要突破的认知难点。二、教学目标与重难点确定基于课标要求与学情分析，本课设定如下教学目标。素养目标层面，在信息意识维度，学生能认识到同一现实问题可以用不同的数据类型进行建模，数据的组织方式直接影响问题求解的复杂度。在计算思维维度，学生能采用“抽象”与“封装”的思想，将一个现实问题中的数据对象、数据关系及其基本操作提炼为抽象数据类型的描述。在数字化学习与创新维度，学生能利用Python中的类或命名元组实现抽象数据类型，并应用于简单问题的求解。知识与技能层面，学生能说出抽象数据类型的三要素，能区分抽象数据类型与具体实现（如类、结构体）之间的层次关系，能运用抽象数据类型的描述方法分析教材中“图书预约”案例及教师提供的扩展案例。教学重点确定为：抽象数据类型的三要素及其描述方法。教学难点确定为：从现实问题中准确识别数据对象之间的关系，并据此设计基本操作集合。为突破难点，本课采用“脚手架渐进”策略。第一环节，教师提供完整的抽象数据类型描述范例；第二环节，教师给出半成品，学生补充数据关系部分；第三环节，学生独立完成一个新的完整抽象过程。三个环节难度递进，使不同层次的学生均能获得成功体验。三、教学策略与学习方法本课采用“项目驱动+问题链引导”的复合策略。全课以“为学校图书馆设计一个预约系统”为核心项目，分解为三个子任务：任务一“描述图书数据”，任务二“描述预约行为”，任务三“验证抽象结果”。三个任务分别对应抽象数据类型的三要素，形成清晰的认知梯度。学习方法上，强调“做中学”与“说中学”并重。学生以四人小组为单位开展协作学习，每组配备一张“抽象数据类型描述卡”，卡上印有描述模板。学生在小组内围绕教师设计的核心问题展开讨论，经历“观察现象—提炼数据—辨析关系—设计操作—交流修正”的完整过程。讨论过程中，每位学生须在小组内用自然语言描述自己的抽象思路，再由组长汇总形成小组方案。教学环境方面，本课在计算机机房授课，每台机器预装Python3.8及以上版本，并准备好两个程序文件：一个是演示用的“图书预约抽象数据类型示例.py”，另一个是供学生填空的“预约系统骨架.py”。此外，教师准备一套实体卡片，卡片上分别印有“书名”“作者”“ISBN号”“预约者学号”“预约日期”等数据项，供学生在脱离计算机的情况下先行进行抽象操作。课堂评价采用“过程性评价+成果评价”相结合的方式。过程性评价依托教师课堂观察量表，从参与度、合作性、思维深度三个维度对小组讨论进行记录。成果评价则依据各小组提交的“抽象数据类型描述卡”和程序实现结果，从正确性、完整性、简洁性三个维度进行评判。评价结果不排名，而是以“通过”“良好”“优秀”呈现，并附上针对性的改进建议。四、教学过程（一）情境导入：从一次真实的“预约失败”开始上课伊始，教师出示一张真实的图书馆预约失败截图。截图内容为：某同学于前一天晚上预约了一本《人类简史》，第二天到馆取书时被告知“预约信息不存在”。学生看到这一情境后，教师提问：“你觉得问题可能出在哪些环节？”学生七嘴八舌，有人说可能预约时输入错了书号，有人说可能系统把预约记录覆盖了，还有人说可能是数据库没保存成功。教师不急于给出结论，而是继续追问：“如果让你来设计这个预约功能，你觉得需要记录哪些信息？这些信息之间又有什么关系？”此时，学生自然地开始列举：需要书名、书号、预约人、预约时间。教师将这些答案写在黑板左侧，并追问：“只记录这四条信息就够了吗？如果你预约的书被借走了，是不是还要记录书当前的状态？”学生点头。教师顺势揭题：“同学们刚才讨论的这些内容，其实就是在做‘抽象数据类型’的设计。今天这节课，我们就来学习如何用规范的方法，把一个现实问题中的数据组织方式描述清楚。”随后板书课题：4.3抽象数据类型——为图书馆预约系统建模。设计意图：将教材中泛化的概念引入到真实的失败案例中，让学生体会到“数据组织不好就会出问题”，从而产生学习的内在需求。同时，学生自主列举的预约信息，为后续提炼“数据对象”提供了直接的感性材料。（二）第一环节：拆解三要素——从生活语言到形式化描述1.从实体卡片到数据对象教师展示一组实体卡片，每张卡片上印有一条预约记录的一部分。教师请两名学生上台，将卡片中属于“书”的卡片和属于“人”的卡片分别摆放在两个圆圈中。一名学生将“书名”“作者”“ISBN号”放入“书”的圆圈，另一名学生将“学号”“姓名”“预约日期”放入“人”的圆圈。教师提问：“为什么你们会把‘预约日期’放到‘人’这边？它难道不是预约行为的属性吗？”学生思考后回答：“因为预约日期是跟着预约人走的，不同的人有不同的预约日期。”教师追问：“那如果同一个人借了三本书，有三条预约记录，每条记录的预约日期可能不同，这又怎么理解？”课堂陷入短暂沉默。教师适时引导：“大家注意，我们这里说的‘数据对象’其实是一个群体的名称，而不是具体的某一条记录。‘借阅人’是一个数据对象，它包含了全体借阅者的数据；‘图书’是另一个数据对象。而‘预约’这个行为本身，其实也可以看成一个数据对象。”说着，教师将卡片重新分为三堆，中间一堆卡片上印着“预约编号”“借阅人学号”“图书ISBN号”“预约日期”。教师板书：抽象数据类型第一要素：数据对象，即具有相同性质的数据元素的集合。这里我们识别出了三个数据对象：图书、借阅人、预约记录。2.从连线游戏到数据关系教师发给每组一张大白纸，纸上已经画好三个椭圆，分别标注“图书”“借阅人”“预约记录”。教师要求学生在椭圆之间画线，并用文字说明线两端的关系。各组经过讨论后，呈现出两种不同画法。第一种画法是在“借阅人”和“预约记录”之间画了一条线，标注“1对多”；在“图书”和“预约记录”之间也画了一条线，标注“1对多”。第二种画法则是在“借阅人”和“图书”之间直接画了一条线，标注“多对多”。教师组织两组学生进行辩论。主张第一种画法的学生说：“预约记录起到了桥梁作用，书和人不直接发生关系。”主张第二种画法的学生反驳：“可是我们平时说‘张三预约了某本书’，就是人和书之间的关系。”教师不评判对错，而是在白板上写下两种方案，然后提问：“如果图书馆规定一本书只能被一个人预约，哪种画法更有利于实现这个规则？”学生在比较中发现，第一种画法将约束关系放在预约记录中，更容易进行“是否已被预约”的校验。教师板书：抽象数据类型第二要素：数据关系。数据关系描述了数据元素之间的逻辑联系。在本案例中：一个借阅人可有多条预约记录（1对多）；一本图书可被多条预约记录关联（1对多）；但同一时刻一本图书只能存在一条有效预约记录（约束条件）。3.从使用场景到基本操作教师提出新问题：“现在我们已经有了三个数据对象和它们之间的关系。但如果要真正完成‘预约’这个功能，我们需要对数据做什么操作？”学生纷纷应答：“增加一条预约”“查询这本书有没有被预约”“取消预约”“查看某人名下的所有预约”。教师将这些回答归为四类，并板书：抽象数据类型第三要素：基本操作。创建一个新的预约记录根据图书ISBN号查询当前是否可预约取消指定编号的预约列出某借阅人的全部预约教师进一步追问：“如果我们要把这个抽象数据类型用到其他场景，比如‘会议室预约系统’，这三个要素会怎样变化？”学生发现，数据对象从“图书”“借阅人”换成了“会议室”“借用部门”，而关系从“1对1”变成了“1对多”，操作也从“查书”变成了“查时段”。教师总结：“抽象数据类型的价值，就在于把具体数据内容剥离掉，只保留结构性的特征。这就是‘抽象’二字的含义。”（三）第二环节：用三元组规范描述——形成本课核心知识结构教师在白板上完整写出图书预约系统的抽象数据类型描述：ADT图书预约系统{数据对象：D={图书b|b=(ISBN号,书名,作者,出版年份)}∪{借阅人r|r=(学号,姓名,班级)}∪{预约记录s|s=(预约号,学号,ISBN号,预约日期,状态)}数据关系：R={<借阅人,预约记录>，1对多}∪{<图书,预约记录>，1对多}∪{约束：同一ISBN号下至多有一条状态为“有效”的预约记录}基本操作：Create()创建空预约集合Reserve(r,b)借阅人r预约图书b，返回预约号Cancel(n)取消预约号n对应的预约Query(b)查询图书b当前是否可预约List(r)列出借阅人r的全部预约记录}教师逐行解释这个描述的结构，强调三个关键词：ADT标记、数据对象中的“∪”表示集合的并、数据关系中的“约束”条件如何体现领域规则。随后，教师请学生对照自己小组刚才的讨论结果，找出教师描述中他们没想到的部分。有的学生说没想到要加“状态”字段，有的学生说没想到约束条件要单独列出来。教师指出：“这些遗漏正是‘从问题到模型’之间的差距，也是我们这节课要训练的能力。”此时，教师抛出本课的核心概念定义，并请学生在笔记本上记录：抽象数据类型（AbstractDataType，ADT）是指一个数学模型以及定义在该模型上的一组操作。它由三要素构成：数据对象、数据关系、基本操作。抽象数据类型强调的是“做什么”而不是“怎么做”，它与具体的存储结构和实现语言无关。教师进一步辨析：“我们学过的整数类型也是一种抽象数据类型，它的数据对象是所有整数，数据关系是大小顺序关系，基本操作包括加、减、乘、除、比较等。但我们在初中就熟悉它，所以不觉得它‘抽象’。其实，任何数据类型都是抽象数据类型，只是有些太常见了，我们就忘记了它的抽象本质。”（四）第三环节：迁移运用——从图书预约到“班级图书角管理”4.半成品补全练习教师下发“半成品抽象数据类型描述卡”，上面已经写好了数据对象部分和基本操作部分，但数据关系部分留白。卡上描述的案例为“班级图书角管理”：班级图书角的书可以在本班同学之间借阅，每本书一次只能借给一个人。学生需要补充数据关系部分。各组讨论后给出不同的答案。有的组直接写“图书与借阅人：多对多”，有的组则进一步补充“但需约束为同一时刻每本书至多有一条有效借阅记录”。教师在巡视中注意到，后一种描述明显比前一种更接近真实规则。教师请做出后一种描述的小组代表分享思考过程，该学生说：“我们宿舍讨论的时候，有人问如果张三还了书，李四马上借走，这算不算同一时刻？后来我们觉得应该用‘有效借阅记录’来限定，这样就不会产生歧义。”教师抓住这个生成性资源，追问：“‘有效’这两个字意味着什么？”学生回答：“意味着借阅记录要有状态属性，比如‘借出中’和‘已归还’。”教师总结：“一个好的抽象数据类型描述，不是机械地罗列对象和关系，而是要深入理解业务规则。状态字段的引入，就是为了支持规则中的‘有效’二字。”5.完整独立建模练习紧接着，教师布置本课的核心任务：以小组为单位，为“图书馆预约系统”中的“预约”部分独立完成一份完整的抽象数据类型描述，要求必须包含数据对象、数据关系和基本操作，并且操作不少于4个。教师提供了描述模板，但允许学生自由发挥。各小组开始协作。教师巡视过程中发现，大部分小组能正确写出数据对象和基本操作，但数据关系部分的表达方式各不相同。有的小组用文字叙述，有的小组用集合表达式，有的小组则画了ER图加上文字。教师没有强制统一格式，而是在小组汇报时引导全班比较各种格式的优缺点。约8分钟后，教师请三个不同小组的代表上台展示。第一组的数据关系部分写的是“借阅人1对多预约记录，图书1对多预约记录”，但缺少约束条件。第二组在约束部分补充了“同一本书不能同时存在两条有效预约”。第三组则在操作中增加了“GetByDate(d)按日期查询所有预约”这一教师未提示的操作，说明该组考虑到了管理员的查询需求。教师引导学生对三份作品进行评价，评价标准有两个：一是是否完整包含三要素，二是操作是否覆盖了问题域中的关键行为。学生在评价中发现，第三组增加“按日期查询”的操作后，系统对管理员的支撑才完整。这让学生意识到，基本操作的设计不是随意的，而是要围绕应用程序的使用场景来确定。6.程序实现验证：让抽象“落地”教师演示Python中如何定义一个表示预约记录的命名元组，然后展示如何使用类来实现上述抽象数据类型。教师强调：“抽象数据类型是设计层面的抽象，而类是实现层面的映射。同一个抽象数据类型，可以用不同的语言、不同的方式来实现。”教师运行一个预先准备好的演示程序，程序实现了预约、查询、取消三个操作。学生通过命令行交互验证功能的正确性。随后，教师要求学生在小组内完成一项“挑战任务”：为“班级图书角管理”系统定义一个名为BorrowRecord的类，要求类中包含借阅人姓名、书名、借出日期、归还日期四个属性，并实现borrow()和return_book()两个方法。学生在完成这项任务时，需要将从抽象数据类型到类的映射显式化。教师提供“映射对照表”作为脚手架，表格如下：抽象数据类型要素|类实现中的对应内容数据对象|类的属性（实例变量）基本操作|类的方法数据关系|通过属性间的引用关系或集合容器体现约束条件|在方法内部的判断语句中体现这张表帮助学生建立了“设计层”与“实现层”的桥梁。教师特别提醒学生注意：约束条件在实现中体现为“判断”，而不是新的属性。只有在存储状态时才有必要新增属性，如“预约记录”中的“状态”字段就是为了存储业务上的“有效/无效”信息。（五）第四环节：深度辨析——抽象数据类型与数据结构的关系教师出示一道辨析题：有人说“栈是一种抽象数据类型”，也有人说“栈是一种数据结构”，这两种说法冲突吗？学生小组讨论后，教师请一位学生回答。该学生说：“我觉得不冲突。栈的描述包括数据对象（一系列元素）、数据关系（线性关系）和基本操作（入栈、出栈、判空），这是抽象数据类型。而用数组或者链表实现出来的栈，就是数据结构。”教师追问：“那‘数据结构’和‘抽象数据类型’的区别到底在哪里？”该生回答：“抽象数据类型只看逻辑，不看存储；数据结构包含了存储方式。”教师在白板上画出一个两层结构图。上层写着“ADT：只关心逻辑结构和操作”，下层写着“实现：数组实现/链表实现/其他实现”。教师指出：“抽象数据类型屏蔽了底层实现细节，为我们提供了一种‘分层设计’的思维方式。你可以先用ADT描述问题，再选择具体的实现方式。这就是软件工程中‘高内聚、低耦合’思想的数据层面体现。”教师进一步举例：“在日常生活中，我们使用空调时只需要按遥控器上的按键，不需要知道压缩机的工作原理。这个遥控器上的操作界面，就相当于抽象数据类型；而内部的压缩机、电路板，则相当于具体实现。抽象数据类型让我们可以站在更高的层次思考问题，而不被琐碎的细节绑架。”这一环节虽然时间不长，但为学生后续学习栈、队列、树、图等具体数据结构提供了方法论指导。当以后学习到各种数据结构时，学生知道每一种结构都可以从“逻辑结构+操作”的角度去理解。（六）第五环节：课堂总结与形成性评价教师引导学生用“一句话+一个例子”的方式总结本课收获。教师先示范：“我今天最大的收获是——抽象数据类型是数据世界的契约，它规定了有哪些数据、数据之间如何关联、可以对数据做什么。我们这个契约的实例就是图书预约系统。”随后请几位学生回答。一名学生说：“我以前觉得数据类型就是int、float这些，今天才知道自己也可以定义数据类型。”另一名学生说：“我学会了先想清楚‘要对数据做什么操作’，再想‘怎么存储数据’，顺序反过来的话容易乱。”教师对每位学生的回答都给以具体回应，不是简单地说“很好”，而是复述学生的观点并将之与本节课的知识点关联。随后，教师下发一份形成性评价单，内容分为两部分。第一部分是三道客观题，检测三要素的识别与基本操作的判断。第二部分是一道开放题：“请选择你身边的一个生活场景（如社团活动报名、食堂菜品管理、运动会成绩记录），用抽象数据类型的描述方式将其中的数据组织方式表示出来。”开放题要求学生课后完成，下节课进行组间互评。教师最后展示一张课前课后概念对比图。课前，学生的认知是“数据类型=变量类型”；课后，认知更新为“数据类型=数据对象+数据关系+基本操作”。教师引导学生对比课前与课后的概念图，指出认知升级的发生过程。这一步骤的目的在于让学生“看见”自己的思维变化，从而增强元认知能力。（七）教学反思与二次备课预设本课在教学预设中特别注意了以下三个可能的生成性问题及应对策略。第一，学生在初次进行数据关系描述时，极易将“借阅人与图书”直接建立多对多关系，而忽略预约记录这一中间实体。此时，教师不直接纠正，而是通过“约束条件如何表达”的反问，让学生自己发现中间实体的必要性，从而理解“关系也可以建模为数据对象”这一深层概念。第二，学生在定义基本操作时，往往遗漏“查询”类操作，只关注“增删改”。教师通过“管理员需要查看某天所有预约”这一场景引导，使操作集合的完整性得到保证。如果学生仍不能主动想到查询操作，教师会提供“角色扮演”的策略，让学生分别扮演用户、图书管理员、系统管理员三种角色，从各自需求出发列举操作，这样操作集合就会更加丰富。第三，在程序实现环节，部分编程基础薄弱的学生可能无法独立完成类的定义。对此，教师准备了“代码补全”形式的支架，将类定义中的属性部分写出来，学生只需要补全方法体中的逻辑。同时，小组内实行“互助配对”，每组的编程能力较强的学生与较弱的学生搭配，既能保证任务完成，也能促进同伴间的知识传递。从整体上看，本课将抽象数据类型这一看似抽象的概念，落地为“描述图书预约系统”这一具体任务。学生在完成任务的过程中，经历了从现实问题到逻辑模型、再到程序实现的完整旅程。这既符合“从具体到抽象”的认知规律，也切合选择性必修课程“深入理解数据、提升计