📚 Case Study Practice and Analysis | 案例分析实战演练
In Year 13 Cambridge A-Level Computer Science, the case study paper requires you to analyse a realistic scenario and propose a computing solution. This article presents a hands-on practice with a ‘College Club Management System’, guiding you step-by-step through requirement analysis, design, implementation, testing and evaluation. By working through this example, you will learn how to apply the theoretical knowledge from the syllabus to a structured case study answer.
在 Year 13 剑桥 A-Level 计算机科学中，案例分析试卷要求你分析一个真实场景并提出计算解决方案。本文以“高校社团管理系统”为案例进行实战演练，逐步指导你完成需求分析、设计、实现、测试和评估。通过这个例子，你将学会如何将课程中的理论知识应用到结构化的案例分析答案中。
1. Understanding the Case Study Scenario | 理解案例场景
The management of a college wants to digitise its club administration. Currently, all club registrations, member applications, event announcements and attendance tracking are done using paper forms and spreadsheets. You have been asked to develop a desktop or web-based system that allows students to browse clubs, apply for membership, and receive notifications. Club presidents need to approve applications, schedule events, and view member lists. The system must store data persistently and support multiple users simultaneously.
某高校管理层希望将社团管理数字化。目前，所有的社团注册、成员申请、活动公告和出勤统计都通过纸质表格和电子表格完成。你被要求开发一个桌面或Web系统，让学生可以浏览社团、申请入会并接收通知。社团主席需要审批申请、安排活动并查看成员名单。系统必须持久存储数据并支持多用户同时访问。
Key constraints from the client: the system must be accessible on campus computers and student mobiles, data must be backed up daily, and only authorised users can modify membership records. The budget is limited, so open-source tools are preferred.
客户提出的关键约束：系统必须能在校园电脑和学生手机上访问，数据必须每日备份，且只有授权用户可以修改成员记录。预算有限，因此优先使用开源工具。
2. Problem Decomposition and Requirements Analysis | 问题分解与需求分析
We can break the overall problem into several manageable sub-problems using a top-down approach. First, identify the main functional requirements: register/log in users, manage club profiles, handle membership applications, schedule events, send notifications, and generate reports. Non-functional requirements include response time under 2 seconds, support for 500 concurrent users, and data encryption for personal information.
我们可以使用自顶向下的方法将整个问题分解为几个可管理的子问题。首先，识别主要功能需求：用户注册/登录、管理社团资料、处理入会申请、安排活动、发送通知和生成报告。非功能需求包括响应时间低于2秒、支持500名并发用户以及对个人信息进行数据加密。
Use a context diagram to show external entities: Student, Club President, Admin, and Email Server. Data flows: membership application, approval decision, event details, notification content. This helps clarify the system boundary.
使用上下文图表示外部实体：学生、社团主席、管理员和邮件服务器。数据流：入会申请、审批决定、活动详情、通知内容。这有助于厘清系统边界。
A prioritisation using MoSCoW can be applied: Must have – user accounts, club browsing, apply/approve membership, events. Should have – notification system. Could have – attendance analytics, chat feature. Won’t have – social media integration in this phase.
可以使用 MoSCoW 方法进行优先级排序：必须有的——用户账户、社团浏览、申请/审批入会、活动；应该有的——通知系统；可以有的——出勤分析和聊天功能；不会有——本阶段不集成社交媒体。
3. Data Structures and Algorithm Design | 数据结构与算法设计
For fast club search and membership look‑ups, appropriate data structures are essential. We can store the list of clubs in a hash table with club ID as the key, allowing O(1) average retrieval. Each club object contains a list of members, which can be implemented as a dynamic array or linked list. Since membership applications require sequential processing (first‑come, first‑served), a queue ADT is suitable for pending applications for each club.
对于快速的社团搜索和成员查找，合适的数据结构至关重要。我们可以使用哈希表存储社团列表，以社团ID为键，实现O(1)平均检索。每个社团对象包含一个成员列表，可以用动态数组或链表实现。由于入会申请需要按顺序处理（先到先得），队列ADT适用于每个社团的待处理申请。
For event scheduling, we need to detect time clashes. A simple algorithm: given a new event with start time Eₛ and duration D, compute end time Eₑ = Eₛ + D. Iterate through existing events for the same club; if (Eₛ < existing.Eₑ) and (Eₑ > existing.Eₛ) then conflict. This check runs in O(n) per club where n is the number of events – acceptable for typical club event loads.
对于活动安排，我们需要检测时间冲突。一个简单算法：给定新活动的开始时间 Eₛ 和持续时间 D，计算结束时间 Eₑ = Eₛ + D。遍历同一社团的现有活动；如果 (Eₛ < 现有.Eₑ) 且 (Eₑ > 现有.Eₛ) 则冲突。此检查对每个社团以 O(n) 运行，其中 n 是活动数量——对典型的社团活动负载来说是可接受的。
When generating a report of most active clubs, we can sort clubs by member count using merge sort O(m log m), where m is number of clubs. If the report is requested frequently, maintain a max‑heap based on member count for O(1) retrieval of top clubs.
当生成最活跃社团报告时，我们可以使用归并排序按成员数量排序俱乐部，复杂度 O(m log m)，其中 m 为社团数量。如果报告请求频繁，可基于成员数量维护一个最大堆，实现 O(1) 获取最活跃社团。
4. Object-Oriented Design Considerations | 面向对象设计考虑
Using OOP principles, we model key entities as classes. A User abstract class holds attributes like userID, name, email, and passwordHash. Two subclasses inherit from User: Student (with additional attributes such as enrolledYear, list of memberships) and President (extends Student, adding methods like approveApplication()).
使用面向对象原则，我们将关键实体建模为类。一个 User 抽象类包含 userID、name、email 和 passwordHash 等属性。两个子类继承自 User：Student（附加属性 enrolledYear、memberships 列表）和 President（扩展 Student，添加 approveApplication() 等方法）。
A Club class contains clubID, name, description, a list of Event objects, and a reference to the President object. The Membership class represents the association between Student and Club with status (pending/approved/rejected) and joinDate. This prevents tight coupling and respects the Single Responsibility Principle.
一个 Club 类包含 clubID、name、description、Event 对象列表以及对 President 对象的引用。Membership 类表示 Student 与 Club 之间的关联，具有状态（pending/approved/rejected）和 joinDate。这避免了紧耦合并遵循单一职责原则。
Encapsulation is enforced by making attributes private and providing public getters/setters. For example, setPassword() will hash the plain text before storing, ensuring data integrity. Polymorphism allows the system to call notify() on a User reference, which differently sends an email to Student or an approval alert to President.
通过将属性设为私有并提供公开的 getter/setter 来实施封装。例如，setPassword() 在存储前会对明文进行哈希处理，确保数据完整性。多态性允许系统在 User 引用上调用 notify()，它会根据对象类型向 Student 发送邮件或向 President 发送审批提醒。
5. Database Design and Normalization | 数据库设计与规范化
We choose a relational database because of the structured nature of the data and the need for ACID transactions (e.g. when a student applies for a club, we must update both Membership and Club member count atomically). The initial unnormalised table might contain all columns together, leading to redundancy.
我们选择关系型数据库，因为数据结构化且需要 ACID 事务（例如学生申请社团时，必须原子性地更新 Membership 和 Club 成员数）。起初的非规范化表可能将所有列放在一起，导致冗余。
Applying normalisation to 3NF:
| Table (表) | Attributes (属性) | Primary Key (主键) |
|---|---|---|
| Student | studentID, name, email, passwordHash, year | studentID |
| President | presidentID, studentID (FK), clubID (FK) | presidentID |
| Club | clubID, name, description, foundedDate | clubID |
| Membership | membershipID, studentID (FK), clubID (FK), joinDate, status | membershipID |
| Event | eventID, clubID (FK), title, startDateTime, duration, venue | eventID |
Each table has no repeating groups, no partial dependencies on a composite key, and no transitive dependencies. The Membership table bridges the many-to-many relationship between Student and Club. Foreign keys are indexed for join performance.
每个表都没有重复组，没有对组合键的部分依赖，也没有传递依赖。Membership 表桥接了 Student 和 Club 之间的多对多关系。外键被索引以提高连接性能。
6. User Interface and Usability | 用户界面与可用性
The system must cater to users with varying technical skills. We adopt a clean dashboard layout with a navigation bar showing logged‑in user’s name and role. For students, the main screen displays a searchable list of clubs using card components; for presidents, an extra “Manage Club” menu appears. Consistent colour coding: green for approved, amber for pending, red for rejected.
系统必须满足不同技术水平的用户需求。我们采用简洁的仪表板布局，导航栏显示登录用户的姓名和角色。对学生而言，主屏幕使用卡片组件显示可搜索的社团列表；对主席，则额外出现“管理社团”菜单。统一颜色编码：绿色代表已批准，琥珀色代表待处理，红色代表已拒绝。
Usability principles: minimise clicks – apply to a club in three steps (browse, click apply, confirm). Provide feedback after every action via toast messages. Support keyboard navigation and ensure colour is not the only cue for status (include text labels). A responsive design using CSS media queries makes the system usable on smartphones.
可用性原则：最少点击——通过三个步骤申请社团（浏览、点击申请、确认）。每次操作后通过 toast 消息提供反馈。支持键盘导航，并确保状态不仅用颜色表示（包含文字标签）。使用 CSS 媒体查询的响应式设计使系统在智能手机上也可用。
For accessibility, we include ARIA landmarks and proper alt text for images (e.g., club logo). Input forms have clear validation messages next to fields, reducing user errors.
对于无障碍访问，我们包含 ARIA 地标并为图片（如社团徽标）提供适当的替代文本。输入表单在字段旁边提供清晰的验证消息，以减少用户错误。
7. Security and Data Protection | 安全与数据保护
Storing personal information imposes legal obligations under data protection laws. All passwords are hashed using a strong algorithm like bcrypt with a salt; we never store plaintext passwords. User sessions are managed using a randomly generated token stored in an HttpOnly cookie to mitigate XSS attacks.
存储个人信息产生了数据保护法下的法律义务。所有密码使用强算法（如带盐的 bcrypt）进行哈希处理；我们绝不存储明文密码。用户会话使用存储在 HttpOnly cookie 中的随机生成令牌进行管理，以减轻 XSS 攻击。
To prevent SQL injection, all database queries use parameterised statements / prepared statements whether in PHP PDO, Python psycopg2, or Java JDBC PreparedStatement. Input validation is implemented both client-side (for quick feedback) and server-side (for security).
为防止 SQL 注入，所有数据库查询均使用参数化语句/预编译语句，无论使用 PHP PDO、Python psycopg2 还是 Java JDBC PreparedStatement。输入验证在客户端（用于快速反馈）和服务器端（用于安全）均实施。
Role‑based access control ensures that a student cannot access president functions directly via URL manipulation. Each request checks the user’s role from the session. The database connection uses a limited‑privilege account that only has INSERT, SELECT, UPDATE, DELETE on relevant tables, never DROP or ALTER.
基于角色的访问控制确保学生不能通过 URL 操纵直接访问主席功能。每个请求都会从会话中检查用户角色。数据库连接使用仅具有相关表 INSERT、SELECT、UPDATE、DELETE 权限的限制权限账户，绝不具有 DROP 或 ALTER 权限。
8. Testing Strategies and Quality Assurance | 测试策略与质量保证
A robust testing plan covers unit, integration, and system testing. Unit tests check individual functions: e.g., test that a membership application with a duplicate studentID and clubID is rejected, test password hashing produces different digests for same input with different salts. We use a framework like JUnit (Java) or pytest (Python).
一个健全的测试计划涵盖单元测试、集成测试和系统测试。单元测试检查单个函数：例如，测试重复的 studentID 和 clubID 的入会申请被拒绝，测试密码哈希对相同输入使用不同 salt 产生不同的摘要。我们使用 JUnit（Java）或 pytest（Python）等框架。
Integration testing ensures the database layer interacts correctly with application logic. For example, when a president approves a membership, verify that the status updates in the database and the member count in Club table increments in the same transaction. We use a test database seeded with known data.
集成测试确保数据库层与应用逻辑正确交互。例如，当主席批准一个会员资格时，验证数据库中状态更新并且 Club 表中的成员计数在同一事务中增加。我们使用填充了已知数据的测试数据库。
System testing evaluates the whole product against requirements: can 500 users browse clubs simultaneously without exceeding the 2‑second response time? Acceptance testing involves the client – college administration – performing tasks like creating a new club and checking if the workflow matches their expectation.
系统测试根据需求评估整个产品：500 名用户能否同时浏览社团而不超过 2 秒响应时间？验收测试由客户——高校管理层——执行任务，如创建新社团并检查工作流是否符合他们的期望。
9. Evaluation and Maintenance | 评估与维护
After deployment, we evaluate the system against success criteria. Have the paper forms been eliminated? Is the average membership processing time reduced from 3 days to under 1 hour? Feedback from a student survey can be quantified on a Likert scale. Any performance bottlenecks identified during load testing should be documented and addressed, e.g., by adding caching for club lists.
部署后，我们根据成功标准评估系统。纸质表格是否已消除？平均入会处理时间是否从 3 天减少到 1 小时以内？学生调查的反馈可用李克特量表量化。负载测试中发现的任何性能瓶颈都应记录并解决，例如通过为社团列表添加缓存。
Maintenance includes corrective (fixing bugs reported by users), adaptive (modifying the system to work with a new college authentication API), and perfective (adding features like event reminders based on usage patterns). A version control system like Git is essential, along with a documented changelog.
维护包括纠正性维护（修复用户报告的缺陷）、适应性维护（修改系统以配合新的高校认证 API）和完善性维护（根据使用模式添加活动提醒等功能）。像 Git 这样的版本控制系统以及文档化的变更日志至关重要。
We also consider a backup strategy: daily incremental backups of the database and weekly full backups stored off‑site. The system logs all data modifications for auditing purposes.
我们还考虑备份策略：每日增量备份数据库，每周完整备份并异地存储。系统记录所有数据修改以供审计。
10. Exam-Style Questions and Model Answers | 考试风格问题与模型答案
Question (a): Explain why a relational database is more suitable than a flat file system for this case study. [4 marks]
问题 (a)：解释为什么在本案例中关系型数据库比平面文件系统更合适。[4 分]
Model answer: A relational database provides data independence, allowing the application to change without reorganising files. It enforces referential integrity through foreign keys, preventing orphan records (e.g., a membership referencing a deleted student). ACID transactions ensure atomicity when updating both membership status and club count concurrently. It also supports concurrent access via locking, which is necessary for 500 users. Flat files would suffer from data redundancy, inconsistency, and lack of efficient querying for reports. [4]
模型答案：关系型数据库提供数据独立性，允许应用在不重组文件的情况下更改。它通过外键强制参照完整性，防止孤立记录（例如引用已删除学生的会员记录）。ACID 事务在同时更新会员状态和社团计数时确保原子性。它还通过锁定支持并发访问，这对 500 名用户是必要的。平面文件系统会存在数据冗余、不一致，且无法高效查询生成报告。[4]
Question (b): Describe the steps you would take to ensure the security of member passwords. [3 marks]
问题 (b)：描述你为确保成员密码安全而采取的步骤。[3 分]
Model answer: Passwords are never stored in plaintext. Upon account creation, a random salt is generated and concatenated with the password; the combination is hashed using bcrypt. The salt and the resulting hash are stored in the database. During login, the same salt is retrieved, the entered password is hashed, and the hash is compared with the stored one. Use parameterised queries to prevent SQL injection when retrieving the hash. [3]
模型答案：密码绝不存储为明文。创建账户时，生成随机盐值并与密码连接；使用 bcrypt 对组合进行哈希。盐值和生成的哈希值存储在数据库中。登录时检索相同盐值，对输入密码哈希，将哈希值与存储值比较。检索哈希时使用参数化查询以防止 SQL 注入。[3]
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导Cancel reply