在线剧院预订系统的设计

摘 要本文对在线剧院预订系统进行了分析研究。

【关键词】剧院 预订系统 数据库

罗德莎剧团是一个地区性的演员团体，通常在一个剧院里演出，而且在三个州的邻近城市的几个剧院里演出戏剧和综艺节目。这个剧团每年有几十个活跃的演员，数百个捐助者和近20个新的节目，发现自己需要一个数据库应用程序。但是，像许多艺术机构一样，它几乎没有钱。事实上，有几种商业系统可以处理票务销售，但是主要的剧院仍然依靠票房销售票据，因为业务经理不愿花钱购买电子系统。如果它能够以合理的成本建立起来，并且可以在最小干预的情况下可靠运行，那么业务经理就有兴趣谈论一个简单的基于Web的系统来销售演出门票。但是，目前最重要的项目是跟踪个人演出，演员和时间表的系统。

这个剧团是一个非盈利性的公司，由一个总经理来管理，由一个董事会来管理。大多数董事会成员都是对剧院感兴趣的捐助者，但是其中包括商界人士。业务经理负责处理金钱和会计。公司还设有营销经理，与新闻界保持联系，帮助设计宣传活动，并与其他影院进行互动。每个节目都会雇佣个人制片人和导演。在这个组织中，制片人负责组织业务细节，并帮助将该项目推广到其他影院。

对于一个小剧场来说，每个表演可以以不同的价格处理200个座位的销售，这可能是一件非常乏味的事情。考虑到绩效销售，一个错位的机票存根可能会造成严重破坏。适当的电脑使用可以减少完成这些工作所需的时间，并减少人力成本，使剧场更具竞争力。

1 传统的剧院预订系统

剧院提供基础设施和演出设施，同时让观众享受这个收费。预订系统用于确保顾客可以提前购买特定演出的门票，并避免在最后一刻被拒绝。剧院管理层也希望门票尽早出售，无论是出于经济原因（Hillenbrand 2001），还是为了避免表演即将开始前的长长的队伍。剧院票房是预定的部分，是剧院与公众之间的第一个联系点（Schneider&Ford; 1993；Grippo 2002，Hillenbrand 2001）。

前电子时代票房包括一个剧院售票点，一个顾客可以购买一张或多张门票，并有一些座位位置的偏好。票房掌柜会为每场演出制作一个票房的纸质图纸，并附有相应的票券。赞助人可以获得剧院图表来指示优选的座位，但是通常不允许实际看到司库的计划，因为司库的一部分工作是在剧场周围分发观众以增加舒适感（并非所有的顾客在同一个角落，而其他许多席位空缺），并为了宣传的原因给人印象深刻的演出（即使剧场不满）（Reid 1983；Langley 1980）。在这个过程中，财务主管会首先嘗试出售高价位的座位（Langley，1980）。以这种方式预订座位并购买机票将是顾客和掌柜之间的面对面谈判。财务主管也应该对所涉及的表现有所了解，以便能以积极的态度处理顾客的问题（Sweeting 1969）。赞助者最终将支付商定的座位，并获得印有各自座位号的票。司库必须仔细标记出售的每张票的剧院座位计划上的座位，以避免错误地出售两次同一座位的可能性。

2 软件模块设计

2.1 用例设计说明

2.1.1 用于注册的用例

用例名称：注册；

参与者：终端用户；

用例说明：用户在访问系统之前使用的用例；

常规事件流程：

（1）用户点击链接注册会员；

（2）会员在屏幕上输入会员资格；

（3）系统检查用户名的可用性；

（4）系统生成会员ID；

（5）系统在数据库中记录会员信息；

备用流程：如果用户没有填写所有必填字段，则会提示填写；

前提：用户未登录剧院预订网站；

后置条件：系统必须记录新成员的会员信息。

2.1.2 用于登录的用例

用例名称：登录；

参与者：管理员/终端用户；

用例说明：这个用例被参与者用来访问系统；

常规事件流程：

（1）管理员/用户通过单击“登录”按钮来调用用例；

（2）管理员/用户输入登录名和密码；

（3）系统验证并验证登录名和密码；

（4）用例实例终止；

备用流程：如果登录名和密码无效，则管理员/用户必须重新输入有效的用户名或密码；

前提：管理员/用户必须是注册了的；

后置条件：管理员/用户可以访问系统或只是退出；

假设：管理员不在线。

2.1.3 验证帐户的用例

用例名称：验证账户

参与者：终端用户；

用例说明：这个用例被参与者用来验证创建的帐户；

常规事件流程：

（1）用户需要点击验证帐户链接；

（1）用户将使用创建的电子邮件地址和密码；

（3）系统验证并验证电子邮件和密码；

（4）用例实例将查看帐户详细信息；

备用流程：用户需要记住注册的细节，尤其是电子邮件地址，以验证帐户；

前提：用户已经创建了了一个帐户；

后置条件：用户需要验证帐户才能确认并激活帐户；

假设：用户完成注册。

2.1.4 查看节目的用例

用例名称：查看节目；

参与者：终端用户；

用例说明：这个用例被参与者用来查看显示细节；

常规事件流程：

（1）用户必须正确输入用户名和密码；

（2）系统验证并验证登录名和密码；

（3）系统将显示显示菜单的主页；

（4）用户现在可以选择显示可用并查看显示详细信息；

备用流程：如果用户还没有选择节目，系统会提示错误信息或系统终止；

前提：用户必须注册并成功创建了一个帐户；

后置条件：系统必须在会员登录时显示“显示详细信息”；

假设：用户不在线；

2.1.5 查看演员的用例

用例名称：查看演员；

参与者：终端用户；

用例说明：这个用例被参与者用来查看演员的详细信息；

常规事件流程：

（1）用户必须正确输入用户名和密码；

（2）系统验证并验证登录名和密码；

（3）系统将显示显示菜单的主页；

（4）用户现在可以选择演员并查看演员计划和演出；

备用流程：如果用户还没有选择演员，系统会提示错误信息或系统终止；

前提：用户必须注册并成功创建了一个帐户；

后置条件：用户现在可以继续观看或只是退出；

假设：用户在线。

2.1.6 查看时间表的用例

用例名称：查看时间表；

参与者：终端用户；

用例说明：这个用例被参与者用来查看时间表；

常规事件流程：

（1）用户必须正确输入用户名和密码；

（2）系统验证并验证登录名和密码；

（3）系统将显示显示菜单的主页；

（4）用户现在可以选择特定的时间表和相应的演员；

备用流程：如果用户选择了时间表，用户现在将进入查找剩余的座位；

前提：用户必须注册并成功创建了一个帐户；

后置条件：系统必须在用户登录时显示计划；

假设：用户在线。

2.1.7 查找剩余座位的用例

用例名称：查找剩余座位；

参与者：终端用户；

用例说明：这个用例可以被参与者用来查找剩余座位；

常规事件流程：

（1）用户必须正确输入用户名和密码；

（2）系统验证并验证登录名和密码；

（3）系统将显示显示菜单的主页；

（4）用户现在将寻找剩余的座位；

备用流程：如果用户选择了座位，则用户现在将继续支付票据；

前提：用户必须是注册了的；

后置条件：确认座位后，继续支付车票；

假设：用户在系統上并选择一个时间表。

2.1.8 购买票的用例

用例名称：购买票；

参与者：终端用户；

用例说明：这个用例可以被参与者用来对购买的票进行查看；

常规事件流程：

（1）用户必须正确输入用户名和密码；

（2）系统验证并验证登录名和密码；

（3）用户将通过点击“购买”按钮选择付款方式；

（4）系统将在付款后显示票务详情；

备用流程：如果用户已经核实了所有的细节，票将被发送和打印；

前提：用户必须注册并创建了一个帐户；

后置条件：系统必须在采购单中显示详细信息；

假设：用户正在系统上确认一个剩余的座位。

2.1.9 用于注销的用例

用例名称：注销；

参与者：终端用户；

用例说明：这个用例可以被参与者用来注销系统账户；

常规事件流程：

（1）用户通过单击“注销”按钮调用用例；

（2）用户将关闭所有使用的窗口；

（3）系统确认用户是否继续注销；

（4）用例实例终止；

备用流程：用户只需点击注销按钮，系统会确认用户是否继续注销；

前提：用户必须是注册了的；

后置条件：用户将离开系统；

假设：用户在线。

2.1.10 修改节目的用例

用例名称：修改节目；

参与者：管理员；

用例说明：这个用例被参与者用来在系统中修改节目；

常规事件流程：

（1）管理员选择修改节目选项；

（2）管理员现在将更改节目详细信息；

（3）系统验证对节目的更改，如果有效，它将被保存；

（4）系统更新节目，并从详细信息中更改；

备用流程：节目的任何改变将被保存在数据库中；

前提：管理员必须通过身份验证；

后置条件：节目被修改并保存在数据库中；

假设：管理员在线。

2.1.11 修改参与者的用例

用例名称：修改参与者；

参与者：管理员；

用例说明：这个用例可以被参与者用来修改参与者信息；

常规事件流程：

（1）管理员选择修改参与者选项；

（2）管理员现在将更改参与者的详细信息；

（3）系统验证对参与者的更改，如果有效，它将被保存；

（4）系统更新从参与者的详细信息中更改；

备用流程：任何对参与者数据的更改都会保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假设：管理员在线。

2.1.12 修改时间表的用例

用例名称：修改时间表；

参与者：管理员；

用例说明：这个用例可以被参与者用来修改时间表；

常规事件流程：

（1）管理员选择修改计划选项；

（2）管理员现在将更改计划详细信息；

（3）系统验证对时间表的更改，它将被保存；

（4）系统将更新计划详细信息中的更改；

备用流程：任何对时间表的修改都会保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假设：管理员在线。

2.1.13 修改价目表的用例

用例名称：修改价目表；

参与者：管理员；

用例说明：参与者使用该用例来修改节目的价目表；

常规事件流程：

（1）管理员选择每个节目的修改价格列表；

（2）管理员现在将更改价目表详情；

（3）系统验证价目表的变化，它将被保存；

（4）系统将更新价目表详细信息；

备用流程：价目表的任何更改都将保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假设：管理员在线。

2.1.14 修改费用的用例

用例名称：修改费用；

参与者：管理员；

用例说明：这个用例被参与者用来访问系统；

常规事件流程：

（1）管理员选择每个节目的修改费用；

（2）管理员现在将更改费用明细；

（3）系统验证费用的变化，它将被保存；

（4）系统将更新费用明细的更改；

备用流程：费用的任何变化都将被保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假设：管理员在线。

2.1.15 修改捐助者的用例

用例名称：修改捐助者；

参与者：管理员；

用例说明：这个用例被参与者用来访问系统；

常规事件流程：

（1）管理员选择每个节目的修改捐助者；

（2）管理员现在将更改捐助者的详细信息；

（3）系统验证捐助者的变化，它将被保存；

（4）系统将更新来自捐赠者详细信息的更改；

备用流程：捐助者的任何变化将被保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假设：管理员在线。

2.1.16 修改员工的用例

用例名称：修改员工；

参与者：管理员；

用例说明：这个用例可以让参与者来修改员工信息；

常规事件流程：

（1）管理员选择每个节目的修改人员；

（2）管理员现在将更改员工详细信息；

（3）系统验证员工的变化，并将被保存；

（4）系统将更新员工详细信息中的更改；

备用流程：工作人员细节的任何变化都将被保存在数据库中；

前提：管理员必须是注册了的；

后置条件：管理员可以访问系统或只是退出；

假設：管理员在线。

2.1.17注销用例（管理员端）

2 数据E-R图

如图1所示。

3 结论及概要

对于功能齐全的剧院预订系统，数据库表格设计需要进一步的工作。已经发现易于使用和有效的查询和报告应该保留，尽管在调整表格结构时必须对其进行修改。应该保持精简有效程序的努力。只有这样，系统才能适合试用实际的实施。

尽管在这种情况下不能充分表现出来，但从前面章节讨论的工作中可以得出结论，一个200座的剧院预订系统可以使用MYSQL数据库来构建。数据库设计原则必须实施，以确保所有表间关系的正确和充分建立，以便所有MYSQL功能可以不受限制地执行。剧院座位的合适的图形表示可能超出了Access的能力，因此不构成系统的一部分，因此仍然必须使用传统的纸面计划。由于它使用了一个通用的，低成本的数据库软件包，以及快速和准确的信息输出，结合在线预订功能，预算有限的小型剧院通过实施完整的系统版本将有很大的收获。

作者简介

石泽宏，男，河北省保定市人。江西省南昌大学软件学院学生。主要研究方向为机器学习和数据挖掘。

作者单位

南昌大学 江西省南昌市 330031