📚 A-Level Edexcel Computer Science Case Study: Cinema Booking System | A-Level Edexcel 计算机科学案例分析实战：影院订票系统
In the Edexcel A-Level Computer Science specification, students are required to apply their knowledge to real-world scenarios through case study analysis. This article presents a detailed walkthrough of a cinema booking system case study, covering all stages from requirements gathering to evaluation, to help you master the skills needed for the exam.
在 Edexcel A-Level 计算机科学考试中，学生需要将所学知识应用于真实场景进行案例分析。本文通过一个影院订票系统的案例详细演练，覆盖从需求收集到方案评估的全过程，帮助你掌握考试所需的分析技能。
1. Understanding the Scenario | 理解场景
A local cinema chain wants to develop an online ticket booking system. The cinema has five screens, each showing up to four films per day. Every screen has a fixed seating layout with numbered rows (A–J) and seat numbers (1–20). Customers must be able to browse film schedules, select a showing, choose specific seats, and pay securely. The system must prevent double-booking and handle high traffic during peak release periods.
一家本地连锁影院希望开发一个在线购票系统。影院拥有五个放映厅，每个厅每天最多放映四场电影。每个放映厅有固定的座位布局，排号从 A 到 J，每排 1 至 20 个座位。顾客需要能够浏览电影排期、选择场次、挑选具体座位并安全支付。系统必须防止重复订座，并能在热门影片上映的高峰期处理高并发访问。
2. Identifying Stakeholders and Requirements | 识别利益相关者与需求
Key stakeholders include customers, cinema staff, managers, and the payment provider. Customers need a fast, intuitive booking experience; staff require tools to override bookings and check in customers; managers want sales reports and film performance analytics; the payment provider demands secure transaction handling. All these needs must be captured in the analysis phase to ensure the system meets its intended purpose.
关键利益相关者包括顾客、影院员工、管理层以及支付服务提供商。顾客需要快速、直观的订票体验；员工需要能够修改预订和为顾客检票的工具；管理层需要销售报表和影片表现分析；支付服务商则要求安全的交易处理。所有这些需求都必须在分析阶段记录下来，以确保系统满足其预定目标。
3. Functional and Non-Functional Requirements | 功能与非功能需求
Functional requirements define what the system should do. For this case study, they include: allow customers to create accounts, search for films by date or title, view available seats in real time, select multiple seats, complete payment, receive e-tickets, and cancel bookings with refunds. Non-functional requirements describe how the system performs, such as response time under two seconds, 99.9% uptime, support for 500 concurrent users, GDPR-compliant data handling, and an accessible interface for users with disabilities.
功能需求定义系统应该做什么。本案例中包括：允许顾客创建账户、按日期或片名搜索电影、实时查看可选座位、选择多个座位、完成支付、接收电子票以及取消订单并退款。非功能需求描述系统性能表现，例如响应时间低于两秒、99.9% 的正常运行时间、支持 500 个并发用户、符合 GDPR 的数据处理方式，以及为残障用户提供可访问的界面。
4. Designing Data Structures | 设计数据结构
A robust database design is crucial. We need tables for Film, Screen, Show, Seat, Booking, and Customer. The Seat table records each physical seat with attributes: SeatID (primary key), ScreenID, Row, Number, and a Boolean IsAccessible. The Show table links a film to a screen and time. Bookings are stored with a BookingID, CustomerID, ShowID, BookingTime, and Status. A separate BookingSeat junction table resolves the many-to-many relationship between Booking and Seat, containing BookingID, SeatID, and Price.
稳健的数据库设计至关重要。我们需要 Film（影片）、Screen（放映厅）、Show（场次）、Seat（座位）、Booking（订票）和 Customer（顾客）表。Seat 表记录每个物理座位，属性包括 SeatID（主键）、ScreenID、Row、Number 以及布尔值 IsAccessible。Show 表将电影与放映厅和时间关联。订票记录存储 BookingID、CustomerID、ShowID、BookingTime 和 Status。独立的 BookingSeat 联结表解决订票与座位之间的多对多关系，包含 BookingID、SeatID 和 Price。
| Table | Key Fields |
|---|---|
| Seat | SeatID (PK), ScreenID (FK), Row, Number, IsAccessible |
| Show | ShowID (PK), FilmID (FK), ScreenID (FK), DateTime, PriceFactor |
| BookingSeat | BookingID (FK), SeatID (FK), Price -- composite PK |
This normalised structure avoids data redundancy and ensures consistency when multiple users attempt to book the same seat.
这种规范化的结构避免了数据冗余，并确保在多个用户试图预订同座位时的一致性。
5. Algorithm Design for Seat Reservation | 座位预订算法设计
The critical algorithm is the seat locking mechanism. When a customer selects seats and clicks 'confirm', the system must atomically check that all chosen seats are still available for that show. Using pseudocode, the process is: begin transaction; for each selected seat, check if a record exists in BookingSeat joined to a confirmed Booking for the same ShowID; if any seat is taken, rollback and inform the user; otherwise, insert the Booking and associated BookingSeat rows, then commit. A timeout mechanism releases locked seats if payment is not completed within 10 minutes.
关键算法是座位的锁定机制。当顾客选好座位并点击“确认”时，系统必须原子性地检查该场次所有选定座位是否仍然可用。伪代码描述的过程是：开始事务；对每个选定座位，检查 BookingSeat 表中是否已有与该 ShowID 关联且状态为已确认的预订记录；如果任何座位被占，则回滚并通知用户；否则，插入 Booking 及相关的 BookingSeat 记录，然后提交。还需设置超时机制，如果 10 分钟内未完成支付则释放被锁定的座位。
loop for each seat in selectedSeats
if seat already booked (SELECT ...) then set conflict = true
if conflict then ROLLBACK else INSERT new booking; COMMIT
Implementing this with database transactions and row-level locking guarantees data integrity, a key requirement for any booking system.
使用数据库事务和行级锁来实现该逻辑，能保证数据完整性，这是任何订票系统的关键要求。
6. User Interface Design Principles | 用户界面设计原则
n (grey) seats. The confirmation button should only become active when valid seat(s) are chosen. Navigation should follow a linear flow: film selection → date/time → seats → payment → confirmation. Consistent use of colour, clear text labels, and feedback messages reduce user errors. Accessibility features include high-contrast mode and keyboard navigation for screen readers.
用户界面必须直观且响应迅速。基于网格的座位图用绿色表示可选、橙色表示已选、灰色表示已占，让顾客一目了然。仅当选择了有效座位时“确认”按钮才变为可用。导航应遵循线性流程：选择影片 → 日期/时间 → 选座 → 支付 → 确认。一致使用颜色、清晰的文字标签和反馈信息可减少用户犯错。无障碍功能包括高对比度模式和供屏幕阅读器使用的键盘导航。
7. Validation and Error Handling | 验证与错误处理
Both client-side and server-side validation are necessary. Client-side JavaScript checks ensure all required fields are filled, email format is valid, and at least one seat is selected before submission. Server-side validation verifies that the show has not started, the selected seats haven't been taken in the milliseconds since the page loaded, and the payment token is authentic. If a conflict occurs, the system must display a clear error message such as 'Seat A12 is no longer available – please choose another seat'. All exceptions should be logged for auditing.
客户端和服务器端验证缺一不可。客户端 JavaScript 检查确保必填字段已填、邮箱格式有效且在提交前至少选择了一个座位。服务器端验证则确认场次尚未开场、自页面加载后所选座位未被占用，以及支付令牌是真实的。如果发生冲突，系统必须显示明确的错误信息，如“座位 A12 已不可用 – 请另选座位”。所有异常都应记录日志以备审计。
8. Testing Strategies | 测试策略
A comprehensive test plan for this system would include unit testing, integration testing, and system testing. Unit tests verify individual functions, such as the seat availability check returning the correct Boolean. Integration tests ensure the booking module correctly interacts with the payment gateway. System tests simulate user journeys from login to e-ticket delivery. Additionally, load testing with simulated concurrent users must confirm the system can handle peak demand without race conditions.
针对本系统的全面测试计划应包括单元测试、集成测试和系统测试。单元测试验证单个函数，例如座位可用性检查返回正确的布尔值。集成测试确保订票模块与支付网关正确交互。系统测试模拟从登录到接收电子票的完整用户旅程。此外，使用模拟并发用户的负载测试必须确认系统能够处理峰值需求且不出现竞争条件。
| Test Type | Example Test Case | Expected Result |
|---|---|---|
| Unit | isSeatAvailable(Show=401, SeatID=203) | True if not booked; False otherwise |
| Integration | Book two seats, pay via mock gateway | Booking status 'Confirmed', payment ID returned |
| Load | 200 users attempt to book the same seat simultaneously | Only one succeeds, all others see 'seat taken' |
9. Evaluation of Solution | 方案评估
An effective solution balances functionality with real-world constraints. The chosen relational database design ensures data consistency but may require careful indexing to meet performance targets under load. The transaction-based seat locking prevents overbooking but could frustrate users if many seats are held in pending payment states. Adding a tiered timeout (e.g. 5 minutes for non-members) might improve user satisfaction. The user interface is simple and effective, but could be enhanced with a 'recommended seat' feature based on user preference history. Overall, the prototype meets the core requirements while offering pathways for future expansion such as loyalty programmes and dynamic pricing.
一个优秀的方案需要在功能与现实约束之间取得平衡。所选的关系数据库设计确保了数据一致性，但在大负载下可能需要小心设计索引以达到性能目标。基于事务的座位锁定防止超售，但如果许多座位因待支付而被持有，可能会令用户沮丧。增加分级超时（例如对非会员设定 5 分钟）或许能提高用户满意度。用户界面简洁有效，但可以加入基于用户偏好历史的“推荐座位”功能。总体而言，原型满足了核心需求，同时为未来的扩展（如会员积分与动态定价）预留了路径。
10. Documentation and Maintenance | 文档与维护
Technical documentation should include an entity-relationship diagram, data dictionary, algorithm explanations, and API specifications for the payment integration. User documentation needs a step-by-step guide and troubleshooting FAQ. Maintenance considerations involve monitoring server logs for failed transactions, applying security patches to the payment module, and regularly optimising database queries as the volume of bookings grows. A clear maintenance handover ensures the system remains reliable after deployment.
技术文档应包括实体关系图、数据字典、算法说明以及支付集成的 API 规范。用户文档则需要分步指南和故障排除常见问题。维护工作包括监控服务器日志以发现失败交易、为支付模块打安全补丁，以及随订票量增长定期优化数据库查询。清晰的维护交接可确保系统部署后持续可靠运行。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图