在线票务系统解析：功能、流程与架构

### 在线票务系统解析：功能、流程与架构 在当今数字化时代，在线票务系统为观众提供了便捷的购票途径。本文将详细解析一个在线票务系统的各项特性，包括系统假设、范围限制、交付计划、用户界面等方面的内容。 #### 系统假设与范围限制 - **系统假设** - **Cookie 接受情况**：互联网用户不强制接受 Cookie，但预计大多数用户会接受。 - **座位类型与价格**：每场演出的座位分为一种或多种类型，如高级预留座。座位类型划分与演出相关，而非个别场次。同一演出同一类型的座位价格相同，但不同场次的价格结构可能不同，例如日场可能比晚场便宜以吸引家庭观众。 - **座位预订规则**：用户可请求特定演出的指定类型和数量的座位，但不能指定具体座位，也不能提供座位分配的“提示”。用户默认希望预订相邻座位，若无法提供足够相邻座位，则提供现有可分配座位，过道分隔的座位不算相邻。 - **取消预订**：互联网用户在支付处理后不能自行取消预订，需联系票务处，票务处将根据曼陀罗中心的取消和退款政策处理。 - **范围限制** - **信用卡安全**：示例应用未实现信用卡购买的安全措施，实际应用会使用 HTTPS，但不同 J2EE 服务器的设置细节不同。 - **支付处理**：示例应用用虚拟组件代替外部支付处理系统，该组件会随机决定是否批准交易。 - **特殊座位需求**：未考虑特殊座位需求，如轮椅通道，尽管这在大多数票务系统中是重要考虑因素。 #### 交付计划 曼陀罗中心管理层将实现真正的在线票务解决方案作为业务优先事项，制定了分三个阶段的交付计划： - **阶段 1**：核心互联网用户界面和票务处界面。 - **阶段 2**：管理界面。在阶段 1 中，管理员用户无法使用图形用户界面，需使用数据库工具操作数据库。 - **阶段 3**：更复杂的互联网界面，为注册用户提供高级服务并添加国际化支持。 示例应用仅涵盖阶段 1，需定义一个为后续阶段提供基础的架构，提前考虑已知的后续阶段需求。 #### 互联网用户界面 - **基本工作流程** - 用户首先看到“欢迎”屏幕，显示所有演出类型和演出信息。用户可进入“显示演出”屏幕，查看特定演出的所有场次、座位类型、价格和可用性。该屏幕仅显示座位是否售罄，不显示剩余座位数量，以保护业务敏感信息。 - 用户可请求特定演出的指定类型和数量的座位，系统会预留这些座位以便用户进行在线信用卡支付。系统区分预订和确认/购买的概念，用户可在一段时间内（通常 5 分钟）预订座位，预订信息存储在数据库和用户会话状态中。 - 预订有三种结果：通过确认转为正式预订；若用户未在规定时间内购买，预订过期，座位将重新可供其他用户预订；若用户进行除继续购买外的其他操作，预订将被清除。 - **错误处理** - 系统出现错误（如 J2EE 服务器无法连接数据库）时，用户将看到与当前品牌一致的内部“错误”屏幕，建议用户稍后重试。严重问题时，支持人员将通过电子邮件和日志文件记录收到通知。用户不应看到包含堆栈跟踪、“500 内部错误”或其他技术特定错误信息的屏幕。 - 用户请求无效 URL 时，将看到与当前品牌一致的屏幕，提示请求的页面未找到并提供返回“欢迎”页面的链接。 - **应用屏幕** - **欢迎屏幕** - **目的**：显示所有演出类型和演出信息，无当前演出的类型不显示。 - **URL**：/welcome.html，用户未指定 URL 时为默认页面。 - **数据显示**：动态显示数据库中的演出类型和演出列表，以及静态信息。 - **会话状态**：不需要现有会话状态，对现有会话状态无影响。 - **刷新/重新提交**：页面可被浏览器缓存 1 分钟，服务器请求将生成新页面。 - **后退按钮**：无关紧要，用户无应用会话状态。 - **参数**：无，无效参数将被忽略。 | 屏幕名称 | 目的 | 替代屏幕 | URL | 数据显示 | 是否需要现有会话状态 | 对现有会话状态的影响 | 刷新/重新提交的影响 | 后退按钮的