电影售票系统Word格式.docx

资源描述

电影售票系统Word格式.docx

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

电影售票系统Word格式.docx

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

（3）管理员接口模块

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

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

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

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

（4）数据服务模块

数据服务器模块是系统正常运行的基础，包括客户的查询，定单的保存；

网站工作人员的定单处理；

网站管理员的销售情况查询与分析。

四相关技术及知识点

用例建模

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

相对于“传统”SRS方法

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

典型用例建模方法：

找出系统边界。

找出参与者。

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

用例的定义

定义：

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

如：

从ATM机提取现金；

定购一个商品；

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

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

用例命名：

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

构造用例图的步骤

1.确定系统的上下文：

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

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

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

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

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

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

RUP的核心工作流

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

需求工作流

分析和设计工作流

实现工作流

测试工作流

分发工作流

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

项目管理工作流

配置和变更控制工作流

环境工作流

概念模型

概念模型：

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

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

概念模型包括：

1、一组概念；

2、概念之间的关联；

3、概念的属性；

概念模型作用

概念模型的作用：

将问题域空间分解成小的单元（概念）；

帮助澄清领域中的术语和词汇（有哪些重要术语、以及术语之间的关系如何）。

类图

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

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

类之间有三种关系：

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

－继承

－依赖

类的三个层次

－Conceptual：

概念层。

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

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

－Specification：

说明层。

LookingintoSoftware,butonlyinterfaceofthesoftware,nottheimplementation.Onlytype,notclass。

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

－Implementation:

实现层。

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

在设计阶段使用。

如何建立关联

添加关联应细到什么程度

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

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

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

4、分析阶段得到的关联可能在设计阶段发现是无用的；

设计阶段有可能发现分析阶段遗漏了有些概念间的关联。

系统行为

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

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

系统顺序图和契约。

图

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

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

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

契约

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

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

流程：

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

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

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

1、实例的创建和销毁。

2、属性的修改。

3、关联的形成和破裂。

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

协作图

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

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

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

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

三层结构的优势

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

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

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

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

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

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

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

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

五面向对象分析与设计

用例图

（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-1系统概念模型

购票者与电影信息和电影票之间有关联；

电影信息和管理员之间有关联。

系统类

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

购票者的属性：

姓名，年龄，电话

管理员的属性：

IDPASSWORD

电影信息的属性：

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

电影票的属性：

名称，价格，时间

（1）订购电影票的契约

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

契约1

名称

初始化

职责

让用户登录系统

交叉引用

用例：

订购电影票

注释

异常

输出

前置条件

后置条件

提示用户成功登录

契约2

查询

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

用户成功登录

提示是否订购

契约3

订购

生成电影票

提示订购成功

契约4

保存退出

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

订购成功

提示订票成功

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

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

1契约

供管理员登入系统

管理电影信息

提示成功登录

2契约

修改增加删除

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

管理员成功登录系统

提示是否保存

3契约

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

提示电影信息修改成功

系统协作图

（1）购票者协作图

5-5-1购票者协作图

Title：