Case Study Practical Exercise | 案例分析实战演练

📚 Case Study Practical Exercise | 案例分析实战演练

In AQA A‑level Computer Science Paper 2, you will often encounter scenario‑based questions that require you to apply your theoretical knowledge to a practical context. These case study questions test your ability to analyse a problem, design solutions, and justify choices. This article walks you through a systematic approach to tackling such exercises effectively.

在 AQA A‑level 计算机科学第二卷中，你经常会遇到基于场景的问题，要求你将理论知识应用于实际情境。这些案例研究题目考察你分析问题、设计解决方案并证明选择合理性的能力。本文将引导你系统地掌握应对此类练习的方法。

1. Understanding Case Study Requirements | 理解案例研究要求

Begin by reading the case study carefully, highlighting the functional and non‑functional requirements. Identify the stakeholders, the scope of the system, and any constraints such as hardware limitations or legal requirements. Distinguish between what the system must do and what it should achieve qualitatively (e.g. response time under 2 seconds). This distinction helps you prioritise features later.

首先仔细阅读案例研究，标出功能性和非功能性需求。识别利益相关者、系统范围以及任何约束条件，如硬件限制或法律要求。区分系统必须做什么与应定性达成的目标（例如响应时间低于 2 秒）。这种区分有助于你之后安排功能的优先级。

Think about the context: is it a web application, a mobile app, or an embedded system? The technical environment dictates the appropriate tools, languages, and data storage. Also note any data protection issues (GDPR) that may influence design decisions, especially when handling personal information.

思考上下文：是一个 web 应用、移动 app 还是嵌入式系统？技术环境决定了合适的工具、语言和数据存储方式。同时注意可能影响设计决策的数据保护问题（如 GDPR），尤其是在处理个人信息时。

2. Decomposing the Problem | 分解问题

• Break down the overall system into manageable modules: input processing, core logic, data persistence, user interface, and output generation. Use a structure diagram or a simple list to show the hierarchy of functions.

• 将整个系统分解为可管理的模块：输入处理、核心逻辑、数据持久化、用户界面和输出生成。用结构图或简单列表展示功能层次。

• For each sub‑problem, specify the inputs, the process, and the expected outputs. This is known as the IPO (Input‑Process‑Output) model. Applying IPO helps you check completeness and identify missing details.

• 对每个子问题，明确输入、处理和期望输出。这称为 IPO（输入‑处理‑输出）模型。运用 IPO 有助于检查完整性并发现遗漏的细节。

• Avoid jumping straight to code; instead, write clear, step‑by‑step English descriptions of what each part does. This approach mirrors the ‘abstraction’ skill required by AQA and makes your solution easier to justify.

• 避免直接跳到代码；相反，用清晰的、逐步的英文描述每个部分的功能。这种方法反映了 AQA 所要求的“抽象”技能，并使你的解决方案更容易论证。

3. Identifying Data Types and Structures | 识别数据类型与结构

Look at the data mentioned in the scenario. Is it numeric, textual, Boolean, date/time, or a composite type like a record? Decide which built‑in types (Integer, Real, String, Char, Boolean) are most suitable and which structured data types (arrays, lists, records, queues, stacks, graphs) will be needed.

查看场景中提到的数据。它是数字、文本、布尔、日期/时间，还是像记录这样的复合类型？决定哪种内置类型（整数、实数、字符串、字符、布尔）最合适，以及需要哪些结构化数据类型（数组、列表、记录、队列、栈、图）。

When data must be stored permanently, choose between a flat file, a relational database, or a combination. Justify your choice with reference to volume, concurrency, and the need for complex queries. For example, a library system with thousands of users would benefit from a relational database to avoid data redundancy and support simultaneous access.

当数据需要永久存储时，在平面文件、关系数据库或组合之间进行选择。参考数据量、并发性和复杂查询的需求来证明你的选择。例如，一个拥有数千用户的图书馆系统将受益于关系数据库，以避免数据冗余并支持并发访问。

Define appropriate data structures using pseudocode or diagrams. For instance, a patient record might be represented as:
RECORD Patient
   ID : Integer
   Name : String
   DOB : Date
   Allergies : Array of String
END RECORD

用伪代码或图表定义合适的数据结构。例如，一个患者记录可以表示为：
RECORD Patient
   ID : Integer
   Name : String
   DOB : Date
   Allergies : Array of String
END RECORD

4. Algorithm Design and Pseudocode | 算法设计与伪代码

Design algorithms for the key operations identified in your decomposition. Concentrate on search, sort, insertion, deletion, and update operations that are explicitly or implicitly required by the case study. Always state any assumptions about data being sorted or not.

为分解中确定的关键操作设计算法。集中在案例研究明确或隐含要求的搜索、排序、插入、删除和更新操作上。始终说明关于数据是否已排序的假设。

Use the AQA pseudocode style: meaningful variable names, indentation, and control structures such as WHILE, FOR, IF‑ELSE. Ensure your pseudocode is detailed enough to be translated into a high‑level language without ambiguity. An example for linear search:

使用 AQA 的伪代码风格：有意义的变量名、缩进以及 WHILE、FOR、IF‑ELSE 等控制结构。确保伪代码足够详细，能被无歧义地翻译成高级语言。线性搜索的示例：

found ← false
i ← 1
WHILE i ≤ n AND NOT found DO
   IF A[i] = target THEN
     found ← true
   ELSE
     i ← i + 1
ENDWHILE

也分析算法的时间和空间复杂度。使用大 O 符号表示（如 O(n)、O(log n)、O(n²)），并讨论在实际数据规模下的可行性。例如，对于待处理的小型数据集，O(n²) 可能足够，但大型数据集则不行。

5. Applying Abstraction | 应用抽象

Abstraction is about hiding unnecessary detail. In a case study answer, show how you would create abstract data types (ADTs) such as a stack, queue, or priority queue to simplify the solution. For instance, a print spooler can be modelled with a queue, abstracting away the physical printer details.

抽象是关于隐藏不必要的细节。在案例研究答案中，展示如何创建抽象数据类型（ADT），如栈、队列或优先队列来简化解决方案。例如，打印队列可以用一个队列建模，将物理打印机的细节抽象掉。

Also consider functional abstraction: group related operations into procedures or functions with clear interfaces. Define preconditions and postconditions to specify what each routine expects and guarantees. This makes your design modular and testable.

还要考虑功能抽象：将相关操作分组为具有清晰接口的过程或函数。定义前置条件和后置条件来指定每个例程期望什么和保证什么。这使你的设计模块化且可测试。

When the case study involves a real‑world entity, use object‑oriented abstraction if appropriate. Identify classes, their attributes, and methods. A class diagram (even sketched in words) can demonstrate inheritance, encapsulation, and polymorphism where relevant.

当案例研究涉及现实世界实体时，如适用，使用面向对象的抽象。识别类、它们的属性和方法。即使在文字中勾画的类图也可以展示继承、封装和多态。

6. Database and File Considerations | 数据库与文件注意事项

If the solution requires persistent storage, design a logical database schema. List the tables needed, their primary keys, foreign keys, and the relationships (one‑to‑many, many‑to‑many). Normalise to third normal form (3NF) to eliminate insertion, update, and deletion anomalies.

如果解决方案需要持久存储，设计一个逻辑数据库模式。列出所需的表、它们的主键、外键以及关系（一对多、多对多）。规范化到第三范式（3NF）以消除插入、更新和删除异常。

Explain how you would maintain data integrity: entity integrity (primary keys not null), referential integrity (foreign keys match existing primary keys), and domain integrity (data types and CHECK constraints). Describe any validation rules that should be enforced at the application level.

解释如何维护数据完整性：实体完整性（主键非空）、参照完整性（外键与现有主键匹配）、域完整性（数据类型与 CHECK 约束）。描述应在应用层强制的任何验证规则。

For file‑based storage, define the file organisation (serial, sequential, indexed sequential, or random) and justify it. If you choose indexed sequential files, mention the use of an index to speed up retrieval, and explain how overflow blocks are handled.

对于基于文件的存储，定义文件组织方式（串行、顺序、索引顺序或随机）并证明理由。如果选择索引顺序文件，提及使用索引加速检索，并解释溢出块如何处理。

7. Testing and Validation | 测试与验证

Develop a test plan that covers normal, boundary, and erroneous data. For each test case, specify the input, expected outcome, and a brief rationale. Normal tests use typical values, boundary tests explore the limits of acceptable ranges, and erroneous tests use invalid inputs to check robustness.

制定一个涵盖正常、边界和错误数据的测试计划。对于每个测试用例，指定输入、预期结果和简要理由。正常测试使用典型值，边界测试探索可接受范围的极限，错误测试使用无效输入来检查健壮性。

Consider validation techniques such as presence check, range check, format check, and check digit. Show how you would implement them in pseudocode. For example, a range check for an exam mark (0–100):

考虑验证技术，如存在检查、范围检查、格式检查和校验位。展示如何在伪代码中实现它们。例如，对考试分数（0–100）的范围检查：

IF mark < 0 OR mark > 100 THEN
OUTPUT “Invalid mark”
ELSE
CONTINUE
ENDIF

Also discuss test drivers and stubs in the context of incremental testing. When modules are developed independently, stubs simulate the behaviour of called modules, allowing top-down testing and early detection of interface mismatches.

在增量测试的背景中还讨论测试驱动程序和桩程序。当模块独立开发时，桩程序模拟被调用模块的行为，允许自顶向下测试并早期发现接口不匹配。

8. Evaluation and Critical Analysis | 评价与批判性分析

After proposing a solution, step back and evaluate it against the original requirements. Are all functional requirements met? Does the design respect the constraints? Discuss trade‑offs: for instance, a binary search tree gives fast lookups but may become unbalanced; an AVL tree fixes this at the cost of complexity.

在提出解决方案后，退一步并对照原始需求进行评价。所有功能需求都满足了吗？设计遵守约束了吗？讨论权衡：例如，二叉搜索树查找快速但可能变得不平衡；AVL 树解决了这个问题，但以复杂性为代价。

Consider the ethical, social, and legal implications. If the system processes personal data, explain the measures taken to ensure GDPR compliance, such as data minimisation, encryption, and the right to erasure. Acknowledge any user accessibility needs and how your interface addresses them.

考虑伦理、社会和法律影响。如果系统处理个人数据，解释为保障 GDPR 合规所采取的措施，如数据最小化、加密和删除权。承认任何用户的无障碍需求以及你的界面如何满足这些需求。

Finally, suggest realistic future improvements. Distinguish between short‑term enhancements (adding a new input validation) and long‑term scalability changes (migrating to a cloud‑based microservice architecture). This demonstrates a mature, forward‑thinking mindset.

最后，提出现实的未来改进。区分短期增强（增加新的输入验证）和长期可扩展性变更（迁移到基于云的微服务架构）。这展示了一种成熟、前瞻的思维方式。

9. Common Mistakes to Avoid | 常见错误避免

• Mistake: Ignoring non‑functional requirements such as usability, performance, or security. Always address at least two such requirements explicitly, even if the question focuses on functionality.

• 错误：忽略非功能性需求，如可用性、性能或安全性。即使问题集中在功能上，也要明确处理至少两个这样的需求。

• Mistake: Presenting pseudocode that is too vague. Avoid statements like ‘process the data’ without defining what the process entails. Use specific variable names and show iteration step by step.

• 错误：给出的伪代码过于模糊。避免像“处理数据”这样的语句而不定义处理过程包含什么。使用具体的变量名并逐步展示迭代。

• Mistake: Overcomplicating the solution with advanced data structures that are not needed. If a simple array and linear search suffice for a dataset of 50 items, do not propose a hash table unless specifically justified by the requirements.

• 错误：使用不需要的高级数据结构使解决方案过于复杂。如果简单数组和线性搜索对 50 项的数据集足够，除非需求特别证明，否则不要提出哈希表。

• Mistake: Neglecting to label diagrams or explain them in the text. Any diagram you sketch in an answer must be accompanied by a clear explanation of what it represents and how it supports your design.

• 错误：忽略为图表添加标签或在正文中解释它们。你在答案中画的任何图表都必须附有清晰的解释，说明它代表什么以及它如何支持你的设计。

10. Worked Example: Healthcare Appointment System | 实战示例：医疗预约系统

Let’s apply the above principles to a sample scenario: ‘A local clinic wants a system where patients can book, cancel, and view appointments online. Receptionists should manage doctor schedules and generate daily reports. The system must run on existing low‑spec computers and comply with data protection laws.’

让我们将以上原则应用到一个示例场景：“一家当地诊所想要一个系统，患者可以在线预约、取消和查看预约。接待员应管理医生排班并生成每日报告。系统必须在现有低配置计算机上运行，并遵守数据保护法。”

First, we identify stakeholders (patients, receptionists, doctors), functional requirements (booking, cancelling, viewing, scheduling, reporting), and non‑functional requirements (performance on low‑spec hardware, data privacy). A key constraint is the existing hardware, so the solution should be lightweight – perhaps a web application with a server‑side SQLite database.

首先，我们识别利益相关者（患者、接待员、医生）、功能需求（预约、取消、查看、排班、报告）和非功能性需求（在低配硬件上的性能、数据隐私）。一个关键约束是现有硬件，因此解决方案应轻量级——也许是一个带有服务器端 SQLite 数据库的 web 应用。

We decompose the system into modules: User Authentication, Patient Appointment Manager, Doctor Schedule Manager, Report Generator, and a central Database Access Layer. For data, we define tables: Patients(PatientID, Name, DOB, NHS_No), Doctors(DoctorID, Name, Specialty), Appointments(ApptID, PatientID, DoctorID, DateTime, Status). Note the foreign keys and the Status field that can be ‘Booked’, ‘Cancelled’, or ‘Completed’.

我们将系统分解为模块：用户认证、患者预约管理器、医生排班管理器、报告生成器和一个中央数据库访问层。对于数据，我们定义表：Patients(PatientID, Name, DOB, NHS_No)、Doctors(DoctorID, Name, Specialty)、Appointments(ApptID, PatientID, DoctorID, DateTime, Status)。注意外键以及可以为 ‘Booked’、‘Cancelled’ 或 ‘Completed’ 的 Status 字段。

A crucial algorithm is checking for double‑booking. Before inserting an appointment, we search existing appointments for the same doctor and overlapping time. Pseudocode:

一个关键算法是检查重复预约。在插入预约前，我们搜索同一位医生时间重叠的现有预约。伪代码：

FUNCTION IsSlotFree(doctorID, requestedDateTime)
   FOR each appointment IN Appointments DO
     IF appointment.DoctorID = doctorID AND
       appointment.DateTime = requestedDateTime AND
       appointment.Status ≠ ‘Cancelled’ THEN
       RETURN FALSE
     ENDIF
   ENDFOR
   RETURN TRUE
END FUNCTION

For testing, we design cases: normal booking, cancel booking, attempt to book a slot already taken, enter an invalid date format, and test boundary times like 00:01 and 23:59. We also plan a stub for the database layer so that the appointment manager can be tested independently with hard‑coded data.

对于测试，我们设计用例：正常预约、取消预约、尝试预约已被占用的时间段、输入无效日期格式，以及测试边界时间，如 00:01 和 23:59。我们还计划为数据库层准备一个桩程序，以便可以用硬编码数据独立测试预约管理器。

In evaluation, we note that the system meets all functional requirements but on very old machines, CSS transitions may need to be disabled to maintain responsiveness. A future improvement could be adding SMS reminders, which would require integrating with an external API and handling failure gracefully.

在评价中，我们注意到系统满足所有功能需求，但在非常老的机器上，可能需要禁用 CSS 过渡以保持响应性。未来的改进可以增加短信提醒，这将需要集成外部 API 并优雅地处理故障。

This systematic approach, practised regularly, builds confidence and ensures you address every aspect of the mark scheme, turning case study questions from a challenge into an opportunity to demonstrate deep understanding.

这种系统性的方法，经过反复练习，可以建立信心并确保你处理评分方案的每个方面，将案例研究问题从挑战转变为展示深刻理解的机会。

Published by TutorHao | Computer Science Revision Series | aleveler.com

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

Case Study Practical Exercise | 案例分析实战演练