Pre-U CAIE Computer Science Case Study Walkthrough | Pre-U CAIE 计算机案例分析实战演练

📚 Pre-U CAIE Computer Science Case Study Walkthrough | Pre-U CAIE 计算机案例分析实战演练

In the Cambridge Pre-U Computer Science curriculum, case study tasks require students to apply system lifecycle skills to realistic scenarios. This walkthrough demonstrates a complete problem-solving journey—from initial requirements gathering to final evaluation—using a course registration system as a worked example. By stepping through each phase with paired English and Chinese explanations, learners can familiarise themselves with the structured approach expected in high‑stakes examinations.

在剑桥 Pre‑U 计算机科学课程中，案例分析任务要求学生将系统生命周期技能应用于实际场景。本文以课程注册系统为范例，展示了从初始需求分析到最终评估的完整问题解决过程。通过每阶段配套的中英文讲解，学习者可以熟悉高风险考试中要求的规范化分析方法。

1. Case Introduction & Problem Statement | 案例介绍与问题陈述

Greenfield High School currently manages course enrolments through paper forms, spreadsheets, and email chains. This manual process leads to data duplication, version conflicts, and delays when students attempt to add or drop courses. The headteacher has commissioned a web‑based course registration system that must serve three user roles: students, teachers, and administrators. The primary goal is to automate the entire registration workflow while enforcing business rules such as class capacity limits and timetable conflicts.

绿原高中目前通过纸质表格、电子表格和邮件链来管理课程注册。这一手工流程导致数据重复、版本冲突以及学生在加退课时出现延误。校长委托开发一个基于网络的课程注册系统，须服务于学生、教师和管理员三种用户角色。主要目标是自动化整个注册流程，同时强制执行班级容量限制和时间表冲突等业务规则。

Key constraints include a limited budget, an eight‑week development window, and the requirement that the system must be accessible from both desktop browsers and mobile devices. The existing school database stores basic student and teacher profiles, so the new system must integrate with this legacy data while maintaining data integrity and privacy. All sensitive information must be encrypted in transit and at rest.

关键约束包括预算有限、八周开发期限以及系统必须兼顾桌面浏览器与移动设备访问。现有学校数据库存储了基本的学生和教师档案，因此新系统必须与该遗留数据集成，同时保持数据完整性和隐私。所有敏感信息在传输和静止状态下都必须加密。

2. Requirements Analysis: Functional & Non‑functional | 需求分析：功能与非功能需求

Functional requirements capture what the system should do. For students, the core capabilities are: view a catalogue of available courses with descriptions, prerequisites, and available seats; register for one or more courses while respecting timetable clashes; drop a course within a defined add‑drop period; and receive immediate confirmation via on‑screen message and email. Teachers must be able to create and edit course sections, set capacity limits, view their class rosters, and export attendance lists. Administrators need user management panels to add, disable, or reset accounts and to oversee system‑wide statistics.

功能需求描述了系统应该做什么。对于学生，核心能力包括：查看包含描述、先修要求和剩余名额的可用课程目录；在不违反时间冲突的前提下注册一门或多门课程；在规定加退课期限内退选课程；并通过屏幕消息和电子邮件立即收到确认。教师必须能够创建和编辑课程班次、设定容量限制、查看班级名册并导出考勤表。管理员需要用户管理界面，用于添加、停用或重置账户，以及查看系统级统计数据。

Non‑functional requirements define quality attributes. The system must support 200 concurrent users during peak registration periods with a page load time under two seconds. Availability should reach 99.9 % during the enrolment window. Security demands role‑based access control, HTTPS encryption, and parameterised database queries to prevent injection attacks. Usability requires a responsive web interface compliant with WCAG 2.1 Level AA accessibility standards. Maintainability is also critical: the system must allow easy configuration of academic terms, capacity thresholds, and notification templates without code changes.

非功能需求定义了质量属性。系统必须在注册高峰期支持200名并发用户，页面加载时间不超过两秒。注册窗口期间可用性应达到99.9%。安全方面要求基于角色的访问控制、HTTPS 加密以及参数化数据库查询以防止注入攻击。可用性要求响应式网页界面符合 WCAG 2.1 Level AA 无障碍标准。可维护性同样关键：系统必须允许在不修改代码的情况下轻松配置学术学期、容量阈值和通知模板。

3. System Modelling: Use Case Diagram & DFD | 系统建模：用例图与数据流图

A use case diagram identifies actors and their interactions with the system. The primary actors are Student, Teacher, and Admin. Key use cases include Register for Course, Drop Course (Student), Create Course Section, View Roster (Teacher), Manage Users, and Generate Reports (Admin). The << include >> relationship links Register for Course to Check Prerequisites and Validate Timetable, ensuring these sub‑processes are reused. The << extend >> relationship connects Register for Course with Notify on Waiting List, triggered when a course is full but a waiting‑list option exists.

用例图确定了参与者及其与系统的交互。主要参与者为学生、教师和管理员。关键用例包括注册课程、退选课程（学生），创建课程班次、查看名册（教师），管理用户和生成报表（管理员）。<< include >> 关系将注册课程与检查先修条件、验证时间表关联，确保这些子过程可重用。<< extend >> 关系将注册课程与等待名单通知关联，当课程已满但存在等待名单选项时触发。

Data flow diagrams (DFDs) model the movement of information. The context diagram shows the Course Registration System as a single process interacting with external entities: Student, Teacher, Admin, and the legacy School Database. Data flows include course list requests, registration confirmations, and user account updates. The level‑0 DFD decomposes the system into five processes: Authentication Service, Course Catalogue Manager, Registration Engine, Notification Service, and Reporting Module. Data stores represent User Accounts, Course Data, Enrolment Records, and Audit Logs.

数据流图 (DFD) 对信息流动进行建模。上下文图将课程注册系统显示为一个与外部实体交互的单一过程：学生、教师、管理员和遗留学校数据库。数据流包括课程列表请求、注册确认和用户账户更新。0层 DFD 将系统分解为五个过程：身份验证服务、课程目录管理器、注册引擎、通知服务和报表模块。数据存储代表用户账户、课程数据、注册记录和审计日志。

4. Data Design & Entity‑Relationship Diagram | 数据设计与实体关系图

The logical data model centres on four main entities. The Student entity has attributes: student_id (PK), full_name, email, year_group, and account_status. The Teacher entity includes teacher_id (PK), full_name, email, department, and office_location. The Course entity stores course_id (PK), title, description, credit_hours, and prerequisite_course_id (FK referencing Course). The Section entity represents an actual offering and contains section_id (PK), course_id (FK), teacher_id (FK), academic_term, max_capacity, and schedule_block. A weak entity Enrolment resolves the many‑to‑many relationship between Student and Section; it holds enrolement_id (PK), student_id (FK), section_id (FK), status (‘enrolled’, ‘waitlisted’, ‘dropped’), and timestamp.

逻辑数据模型以四个主要实体为中心。Student 实体属性包括：student_id（主键）、full_name、email、year_group 和 account_status。Teacher 实体包含 teacher_id（主键）、full_name、email、department 和 office_location。Course 实体存储 course_id（主键）、title、description、credit_hours 和 prerequisite_course_id（外键，引用 Course）。Section 实体表示实际开课班次，包含 section_id（主键）、course_id（外键）、teacher_id（外键）、academic_term、max_capacity 和 schedule_block。弱实体 Enrolment 解决 Student 与 Section 之间的多对多关系，包含 enrolement_id（主键）、student_id（外键）、section_id（外键）、status（’enrolled’、’waitlisted’、’dropped’）和 timestamp。

Referential integrity is enforced through foreign keys, and all updates follow ACID principles. Indexing is planned on frequently queried columns such as student_id, section_id, and academic_term. A normalisation check ensures the schema reaches third normal form, eliminating transitive dependencies—for example, teacher contact details are stored only in the Teacher table, not repeated in Section.

通过外键强制参照完整性，所有更新遵循 ACID 原则。计划在 student_id、section_id 和 academic_term 等常用查询列上建立索引。规范化检查确保模式达到第三范式，消除传递依赖——例如，教师联系方式仅存储在 Teacher 表中，不在 Section 中重复。

5. Algorithm Design: Course Registration Logic | 算法设计：课程注册逻辑

At the heart of the system lies the registration algorithm. When a student submits a course section request, the server must verify prerequisites and timetable feasibility, check capacity, and either confirm enrolment or add to a waiting list. A simplified version of the logic can be expressed in structured English:

FUNCTION Register(studentId, sectionId)
IF NOT UserIsActive(studentId) THEN RETURN “Account disabled”
IF NOT CheckPrerequisites(studentId, sectionId) THEN RETURN “Prerequisite not met”
IF HasTimetableClash(studentId, sectionId) THEN RETURN “Time conflict”
SET enrolled = CountEnrolled(sectionId)
SET capacity = GetCapacity(sectionId)
IF enrolled < capacity THEN
INSERT Enrolment(studentId, sectionId, ‘enrolled’)
RETURN “Successfully enrolled”
ELSE
INSERT Enrolment(studentId, sectionId, ‘waitlisted’)
RETURN “Added to waiting list”
END IF
END FUNCTION

在系统核心是注册算法。当学生提交课程班次请求时，服务器必须验证先修条件和时间表可行性、检查容量，然后确认注册或加入等待名单。可以用结构化英语表达简化逻辑：

FUNCTION Register(studentId, sectionId)
IF NOT UserIsActive(studentId) THEN RETURN “账户已禁用”
IF NOT CheckPrerequisites(studentId, sectionId) THEN RETURN “先修条件未满足”
IF HasTimetableClash(studentId, sectionId) THEN RETURN “时间冲突”
SET enrolled = CountEnrolled(sectionId)
SET capacity = GetCapacity(sectionId)
IF enrolled < capacity THEN
INSERT Enrolment(studentId, sectionId, ‘enrolled’)
RETURN “注册成功”
ELSE
INSERT Enrolment(studentId, sectionId, ‘waitlisted’)
RETURN “已加入等待名单”
END IF
END FUNCTION

To avoid race conditions when multiple students attempt to grab the last seat simultaneously, the capacity check and insert must be wrapped in a database transaction with an appropriate isolation level (e.g., SERIALIZABLE). Additionally, the algorithm must handle the drop‑and‑reassign flow: when a student drops a course, if a waiting‑listed student is eligible, the system automatically promotes the first waiting entry and sends a notification.

为避免多名学生同时抢最后一个名额时出现竞态条件，容量检查和插入必须用数据库事务封装，并设置适当的隔离级别（例如 SERIALIZABLE）。此外，算法必须处理退选重新分配流程：当学生退选课程时，如果有符合条件的等待学生，系统自动将第一个等待条目提升并发送通知。

6. User Interface Prototyping | 用户界面原型设计

Wireframes were sketched for three key screens. The Student Dashboard shows a summary card of current enrolments, a ‘Browse Courses’ search bar, and a notification area. The Course Catalogue displays searchable tiles with course title, instructor name, available seats, and a ‘Register’ button that is greyed out if the course is full or if prerequisites are not satisfied. Clicking a tile expands a detail panel with schedule, syllabus bullet points, and a visual indicator of timetable clashes.

为三个关键页面绘制了线框图。学生仪表板显示当前注册的摘要卡片、“浏览课程”搜索条和通知区域。课程目录展示可搜索的卡片，显示课程名称、教师姓名、剩余座位和一个“注册”按钮，如果课程已满或先修条件未满足，按钮变为灰色。点击卡片会展开详情面板，显示时间安排、教学大纲要点和可视化时间冲突指示器。

The Teacher Class Roster screen presents a table with student names, email links, enrolment status (enrolled or waitlisted), and a quick‑action menu for exporting data to CSV. All screens adopt a responsive grid layout: three columns on desktop, single column on mobile. Navigation uses a sticky sidebar on large screens and a hamburger menu on small screens. Colour contrast and font sizes were chosen to comply with AA accessibility standards.

教师班级名册页面以表格形式呈现学生姓名、电子邮件链接、注册状态（已注册或等待）以及可将数据导出为 CSV 的快捷菜单。所有页面采用响应式网格布局：桌面端三列，移动端单列。大屏使用粘性侧边栏导航，小屏使用汉堡菜单。颜色对比度和字号均选择符合 AA 无障碍标准。

7. Test Strategy: Black‑Box & White‑Box Testing | 测试策略：黑盒与白盒测试

Black‑box testing validates functional behaviour without knowledge of internal code. Using equivalence partitioning, inputs for the registration form are categorised. For the course section capacity field, valid classes are positive integers between 1 and 999; invalid classes include zero, negative numbers, non‑numeric strings, and values exceeding 999. Boundary value analysis adds test cases at 0, 1, 999, and 1000. Decision table testing is applied to the combination of prerequisite status, timetable clash, and capacity—resulting in eight distinct rules. Representative test cases are captured in a bilingual table.

黑盒测试在不了解内部代码的情况下验证功能行为。使用等价类划分法，对注册表单的输入进行分类。对于课程班次容量字段，有效类为 1 到 999 的正整数；无效类包括零、负数、非数字字符串以及超过 999 的值。边界值分析增加 0、1、999 和 1000 的测试用例。决策表测试应用于先修条件状态、时间冲突和容量的组合，产生八条不同规则。代表性测试用例以双语表格呈现。

Test ID	Input Condition (English)	输入条件 (中文)	Expected Outcome (English)	预期结果 (中文)
TC‑01	Valid student, open section, no clash	有效学生，有空位，无冲突	Enrolment confirmed	注册确认
TC‑02	Valid student, section at max capacity	有效学生，班次已满	Waitlist message displayed	显示等待名单消息
TC‑03	Prerequisite not met	未满足先修条件	Error: prerequisite required	错误：需要先修条件
TC‑04	Timetable clash detected	检测到时间冲突	Error: time conflict shown	错误：显示时间冲突

White‑box testing targets the internal code structure. Statement coverage requires that every line of the registration function is executed at least once. Test cases are selected to cover each return path: account disabled, prerequisite fail, clash, normal enrolment, and waitlist. Branch coverage additionally demands that both true and false outcomes are exercised for each conditional, such as the capacity check. Cyclomatic complexity of the registration function is calculated as V(G) = E − N + 2P = 5, indicating 5 independent paths, all of which must be tested.

白盒测试针对内部代码结构。语句覆盖要求注册函数的每一行至少执行一次。选择测试用例覆盖每个返回路径：账户禁用、先修条件未通过、冲突、正常注册和等待名单。分支覆盖还要求对每个条件判断的真假结果都进行测试，例如容量检查。注册函数的圈复杂度计算为 V(G) = E − N + 2P = 5，指出有 5 条独立路径，全部需要测试。

8. Security & Error Handling | 安全与错误处理

Security begins at authentication. The system uses bcrypt‑hashed passwords and issues JWT access tokens with a 15‑minute expiry. All token exchanges occur over HTTPS. Role‑based middleware checks authorisation before every sensitive endpoint. Input validation is applied both client‑side (for immediate feedback) and server‑side (for robust enforcement): student IDs are checked against a regex pattern, and free‑text fields are sanitised to strip HTML tags, preventing cross‑site scripting (XSS).

安全始于身份验证。系统使用 bcrypt 哈希密码，并签发有效期为 15 分钟的 JWT 访问令牌。所有令牌交换均通过 HTTPS 进行。在每个敏感端点之前，基于角色的中间件检查授权。客户端（用于即时反馈）和服务器端（用于强力执行）均应用输入验证：学号根据正则表达式模式检查，自由文本字段经过清理以去除 HTML 标签，防止跨站脚本攻击 (XSS)。

Error handling follows the principle of never exposing internal details to users. A global exception handler catches runtime errors and returns a generic “An unexpected error has occurred” message while logging the full stack trace to a secure audit log. For expected errors—such as account disabled, duplicate registration, or capacity exceeded—the API returns distinct HTTP status codes (403, 409, 422) and descriptive yet safe error messages. A custom error page is displayed for 404 and 500 statuses, guiding users back to the dashboard.

错误处理遵循不向用户暴露内部细节的原则。全局异常处理器捕获运行时错误，返回通用的“系统发生意外错误”消息，同时将完整堆栈跟踪记录到安全审计日志中。对于预期错误——例如账户禁用、重复注册或容量超额——API 返回不同的 HTTP 状态码（403、409、422）和描述性但安全的错误消息。404 和 500 状态会显示自定义错误页面，引导用户返回仪表板。

9. Implementation Considerations & Deployment | 实施考虑与部署

The frontend is built with a component‑based JavaScript framework such as React, enabling reusable UI elements and efficient state management. The backend uses a Python Flask RESTful API, chosen for its lightweight nature and strong ecosystem of authentication libraries. PostgreSQL serves as the relational database due to its ACID compliance and support for SERIALIZABLE isolation. The technology stack ensures clear separation of concerns: the presentation layer never communicates directly with the database.

前端使用基于组件的 JavaScript 框架（如 React）构建，可实现可重用 UI 组件和高效的状态管理。后端采用 Python Flask RESTful API，选择它是因其轻量特性及强大的认证库生态。PostgreSQL 作为关系型数据库，因其符合 ACID 并支持 SERIALIZABLE 隔离级别。技术栈确保了清晰的关注点分离：表示层绝不直接与数据库通信。

Deployment follows a CI/CD pipeline. Code is hosted on GitHub, and each push triggers automated unit and integration tests via GitHub Actions. On passing, a staging environment is deployed on a cloud platform (e.g., AWS Elastic Beanstalk) for manual acceptance testing. After sign‑off, the production environment is updated with zero‑downtime rolling deployment. Environment variables hold all secrets, and database migrations are scripted to ensure schema sync across environments. Monitoring tools track response times, error rates, and CPU utilisation, sending alerts to the operations team when thresholds are breached.

部署遵循 CI/CD 流水线。代码托管在 GitHub，每次推送都会通过 GitHub Actions 触发自动化的单元与集成测试。通过后，生成环境部署到云平台（如 AWS Elastic Beanstalk）供人工验收测试。签署确认后，生产环境通过零停机滚动部署进行更新。所有机密通过环境变量保存，数据库迁移通过脚本化确保跨环境模式同步。监控工具追踪响应时间、错误率和 CPU 利用率，并在超过阈值时向运维团队发送告警。

10. Evaluation & Future Improvements | 评估与未来改进

Post‑implementation evaluation measures the system against non‑functional requirements. Load testing with 200 simulated concurrent users confirmed an average response time of 1.2 seconds, well within the two‑second target. Accessibility audits using Lighthouse scored 96/100. Security penetration testing uncovered no high‑risk vulnerabilities. However, usability feedback

Published by TutorHao | Pre-U Computer Science Revision Series | aleveler.com

更多咨询请联系16621398022（同微信）

Pre-U CAIE Computer Science Case Study Walkthrough | Pre-U CAIE 计算机案例分析实战演练