电影售票系统.docx

电影售票系统.docx

《电影售票系统.docx》由会员分享，可在线阅读，更多相关《电影售票系统.docx（21页珍藏版）》请在冰豆网上搜索。

电影售票系统

电影售票系统

————————————————————————————————作者：

————————————————————————————————日期：

一设计目的和任务

1.1设计目的

通过自身对电影院的了解和经历、分析以及实际的市场调查，要求本系统具有以下功能：

（1）、统一友好的操作界面，能保证系统的易用性。

（2）、规范、完善的基础信息设置。

（3）、影片分类详尽，可按不同类别查看影片信息。

（5）、实现轻松便捷购买影票。

为了影院售票系统更完善；为了影院对售票的管理更方便。

二开发环境

2.1硬件环境

微机一台、打印机一台、扫描仪一台

2.2软件环境

操作系统：

WindowsXP；

数据库：

MYSQL。

三.设计题目

3.1题目详细描述

售票管理系统是一个基于电影院工作人员的系统，不同类型的用户在系统中有不同的权限。

主要有两种用户：

购票者：

可以查询电影的上映时间，场次，并选择自己所需要的电影票，向售票员购买电影票。

管理员：

主要负责将电影信息增加，修改，删除，并导入数据库。

3.2功能要求

（1）系统总体的功能需求

影院售票系统是一个复杂的电子商务系统，它必须提供用户的接口以供用户登录并选择影票；同时还必须提供系统的管理接口以供管理员和一般的网站工作人员处理客户订单并维护网站正常运作。

图3-3-1系统总体功能需求框图

（2）用户接口模块

用户接口是网站用户使用影院售票系统服务的入口，所有的在线用户都通过浏览登录网站，并进行一系列的查询，订购操作。

用户接口模块包括了用户信息维护、商品查询、订购商品和订单维护4个部分。

用户登录系统后，用户ID将会被保存在服务器的缓存中，用户在系统中所做的操作，包括查询、订购等都将被系统存储在数据库中，以供系统那个进行销售情况以及销售走势分析。

（3）管理员接口模块

这是系统提供给网站维护和管理人员的接口。

管理员接口模块包括商品信息维护、内部员工信息维护、订单处理、销售情况查询、报表维护5个部分。

网站的一般工作人员通常只具有订单处理的权限，他们获得用户提交的订单，并根据库存情况来决定发货或者推迟发货。

网站的管理员具有所有的管理权限，可以处理客户的订单，可以阅览网站商品的销售情况、销售走势，以便根据不同的情况及时的调整经营战略，将库存成本和资金占有用率降到最低的限度。

（4）数据服务模块

数据服务器模块是系统正常运行的基础，包括客户的查询，定单的保存；网站工作人员的定单处理；网站管理员的销售情况查询与分析。

四相关技术及知识点

4.1用例建模

用例建模是需求工程的一种形式，是抽取和文档化需求的补充方法

相对于“传统”SRS方法

用例是Jacobson在面向对象的软件工程中提出的，但它实际上是独立于面向对象的。

典型用例建模方法：

找出系统边界。

找出参与者。

找出用例（包括说明用例，创建场景）

4.2用例的定义

定义：

由系统执行的一个动作序列，并能产生可观测的结果值给特定的角色。

如：

从ATM机提取现金；

定购一个商品；

从学校选课系统注册选课；

从文本编辑器中检查一个文档的拼写错误；

用例命名：

（状语＋）动词＋（定语＋）宾语

4.3构造用例图的步骤

1.确定系统的上下文：

1.1确定参与者与它们的责任；

1.2确定用例，即确定带有某种目的或产生特定结果的系统行为。

2.对参与者和用例进行权衡，以便精化模型，例如拆分和合并定义。

3.衡量用例以找出包含关系。

4.衡量用例以找出扩展关系。

5.对参与者和用例进行研究，查找是否存在泛化关系。

4.4RUP的核心工作流

（1）6个核心工程工作流：

需求工作流

分析和设计工作流

实现工作流

测试工作流

分发工作流

（2）3个核心支持工作流：

项目管理工作流

配置和变更控制工作流

环境工作流

4.5概念模型

概念模型：

展现了问题域中有意义的概念，是OOA中要得到的最重要的制品。

是真实世界中各个事物的代表，而不是软件中各个构件的代表。

概念模型包括：

1、一组概念；

2、概念之间的关联；

3、概念的属性；

4.6概念模型作用

概念模型的作用：

将问题域空间分解成小的单元（概念）；帮助澄清领域中的术语和词汇（有哪些重要术语、以及术语之间的关系如何）。

4.7类图

类图描述了系统中的类及其相互之间的各种关系。

类之间的关系表示了对象之间的通信能力。

类之间有三种关系：

－关联（包括聚合和组合）

－继承

－依赖

4.8类的三个层次

－Conceptual：

概念层。

描述问题域中的概念，不考虑或很少考虑实现上的细节－NoSoftware。

只考虑属性，在分析阶段使用。

－Specification：

说明层。

LookingintoSoftware,butonlyinterfaceofthesoftware,nottheimplementation.Onlytype,notclass。

增加操作定义，在设计阶段使用。

－Implementation:

实现层。

只有当使用某一具体技术进行设计时使用。

在设计阶段使用。

4.9如何建立关联

添加关联应细到什么程度

1、在建立概念模型时主要时间花费在识别问题域概念上，而不是识别关联上。

2、关联太多不仅不能有效展示概念模型，反而会使模型混乱。

3、概念模型概念间的关联是从纯分析角度声明有意义的概念间的联系，不需要考虑如何实现关联。

4、分析阶段得到的关联可能在设计阶段发现是无用的；设计阶段有可能发现分析阶段遗漏了有些概念间的关联。

4.10系统行为

在进行系统逻辑设计之前，必须先调查系统的行为，即将系统看作一个黑盒子，描述系统要“做什么”，而不是“怎么做”。

定义系统行为的两种手段：

系统顺序图和契约。

4.11图

展示了一个特殊的用例场景中外部参与者发起的事件以及事件的顺序。

在顺序图中，所有的系统都被当成黑盒子对待，顺序图的重点是参与者发起的跨越系统边界的事件。

建立系统顺序图要依赖于前面已经建立起来的用例描述。

4.12契约

契约是一个文档，描述系统操作对系统状态的影响，属于系统行为建模的一部分。

契约强调发生了什么而不是怎么发生。

流程：

用例描述－》系统顺序图－》系统操作－》契约

契约文本描述中强调操作的职责和后置条件

实用的契约后置条件分为以下三类：

1、实例的创建和销毁。

2、属性的修改。

3、关联的形成和破裂。

后置条件的表达要符合概念模型的语境，通过后置条件能发现概念模型遗漏的概念、属性或关联，从而进行补充。

4.13协作图

1、每一个系统操作建立一张协作图，其中每个系统操作作为这张单独的图的起始消息。

2、若所绘出的图太复杂，那么可以将这个大图分成若干小图。

3、使用操作契约和契约的后置条件以及用例描述文档作为起点来设计系统。

识别对象、给对象分配职责、利用GRASP和系统模式来优化设计。

4.14三层结构的优势

1．便于统一安装和维护，客户端几乎零维护。

2．表示层、应用逻辑层、存储层比较独立，可以分别进行修改和升级。

3．便于组件共享和升级。

4．方便对应用逻辑单独进行升级和修改。

5．可以采用中间件技术，实现负载平衡。

6．在复杂情况下具有很高的运行效率和稳定性。

7．完整的事物处理能力和简单的编程接口。

8．简化应用逻辑的编程，不关心存储的细节。

五面向对象分析与设计

5.1用例图

（1）管理员用例图

5-1-1管理员用例图

用例说明

1.简要说明

本用例描述管理人员管理电影院的过程

2.时间流

1.基本流

1.管理人员在数据服务器上管理电影信息（修改，添加，删除）

2.将管理人员所做的改动返回数据服务器

3.系统保存管理人员所做改动，并备份原数据

2.备选流

无

2.特殊要求

无

3.前置条件

执“登陆”用例

4.后置条件

无

5.扩展点

无

6.相关数据

（2）购票者用例图

5-1-2购票者用例图

1.简要说明

本用例描述购票者购票的过程

2.事件流

1.基本流

1.购票者查看电影信息来确认电影的名字，价格，上映时间。

2.购票者通过购票系统来选择电影与剩余可选的座位。

3.购票者通过购票系统向售票者购买电影票。

4，系统确认购票者的请求并由售票员收取费用。

7.备选流

2a如果购票者想要购买的电影场次票已售完，给出提示，并返回。

4a如果售票者确认购票者的请求失败，给出提示，并返回。

3.特殊需求

无

4前置条件

无

5后置条件

无

6扩展点

无

7,相关数据.

电影信息

5.2概念模型

5-2-1系统概念模型

购票者与电影信息和电影票之间有关联；电影信息和管理员之间有关联。

5.3系统类

购票者类管理员类电影信息类电影票类

购票者的属性：

姓名，年龄，电话

管理员的属性：

IDPASSWORD

电影信息的属性：

名称，导演，主演，价格，时间

电影票的属性：

名称，价格，时间

5.4契约

（1）订购电影票的契约

5-4-1订购电影票的系统顺序图和系统操作

契约1

名称

初始化

职责

让用户登录系统

交叉引用

用例：

订购电影票

注释

异常

输出

前置条件

后置条件

提示用户成功登录

契约2

名称

查询

职责

显示各种影片信息供购票者选择

交叉引用

用例：

订购电影票

注释

异常

输出

前置条件

用户成功登录

后置条件

提示是否订购

契约3

名称

订购

职责

生成电影票

交叉引用

用例：

订购电影票

注释

异常

输出

前置条件

用户成功登录

后置条件

提示订购成功

契约4

名称

保存退出

职责

把数据存入数据库，退出系统

交叉引用

用例：

订购电影票

注释

异常

输出

前置条件

订购成功

后置条件

提示订票成功

（2）管理电影信息的契约

5-4-2管理电影信息的系统顺序图和系统操作

1契约

名称

初始化

职责

供管理员登入系统

交叉引用

用例：

管理电影信息

注释

异常

输出

前置条件

后置条件

提示成功登录

2契约

名称

修改增加删除

职责

让管理员可以对现有的电影信息进行修改，增加，删除

交叉引用

用例：

管理电影信息

注释

异常

输出

前置条件

管理员成功登录系统

后置条件

提示是否保存

3契约

名称

保存退出

职责

把修改后的数据存入数据库，退出系统

交叉引用

用例：

管理电影信息

注释

异常

输出

前置条件

管理员成功登录系统

后置条件

提示电影信息修改成功

5.5系统协作图

（1）购票者协作图

5-5-1购票者协作图

Title：

相关电影信息

Item：

更新后的电影信息

显示相互合作的对象之间的交互和链接关系：

1：

用户登录系统

2：

订票系统查询已有的电影信息

3：

订票系统处理订票信息

4：

检查该电影座位数是否减少

5：

订票

6：

更新座位信息

（2）管理员协作图

5-5-2管理员协作图

Title：

相关电影信息

Item：

更新后的电影信息

显示相互合作的对象之间的交互和链接关系：

1:

管理员验证购票者身份信息

2：

售票系统查询订单信息

3：

找到订购电影票的信息

4：

出售电影票

5：

检查是否超过最大座位

6：

售票

7：

更新电影信息

5.6系统类图

5-6-1系统类图

一个管理员可以处理多个电影信息；

一个购票者可以购买多张电影票；

一个购票者对应一个付款记录；

多个订购单对应多个电影信息。

5.7状态图

（1）订票状态图

5-7-1订票状态图

NewFILM:

新电影

Available：

处于可购买状态

Delete：

删除

Time_out：

超过时间

Cancle：

购票者取消

Reserve：

保存信息

Bought：

购买

（2）售票状态图

5-7-2售票状态图

Newbuyer：

新的购买者

Newstate：

新的数据

Accountunavailable：

订单不可交易

Deleteaccount：

删除订单

5.8系统组件图

5-8-1系统组件图

5.9部署图

5-9-1部署图

Database：

数据库服务器

Webapplication：

网络应用

Businessoperation：

交易操作

Informationmaintenance：

信息维护

5.10数据库表

（1）电影信息数据库表

字段名称

数据类型

字段属性

字段大小

名称

必填字段

是否主键

name

Nvarchar

50

电影名称

是

是

director

Nvarchar

50

导演

否

performer

Nvarchar

50

主演

否

5-10-1电影信息数据库表

（2）电影票数据库表

字段名称

数据类型

字段属性

字段大小

名称

必填字段

是否主键

name

Nvarchar

50

电影名称

是

是

director

Nvarchar

50

导演

否

performer

Nvarchar

50

主演

否

price

float

8

价格

是

seatnumber

smallint

2

座位号

是

5-10-2电影票数据库表