课程设计题目七：票务公司网上订票系统
https://download.csdn.net/download/qq_45037155/87364367
点击此链接免费下载原文章！
第1章 绪论
1.1 引言
在当今社会，速度决定了很多商业机构的成败。为了顺应时代发展，提高效率，节省时间，在零售行业的范畴之内，我们提出了一个大胆的但并非遥不可及的畅想:无纸化购票。这里的“票”，包括汽车票，电影票，门票等等。该项目主要是以互联网为主要平台，将实际生活中传统而费时的购票程序简化，转为网上购票，以网上支付方式，获取一份具有完整信息的二维码，并以此代替原有的纸质票而作为凭证，并执行其原有的全部功能。同时通过一定的加密，提高购票的安全性，有效打击了黄牛票的出现。
1.2 研究内容
随着网络的普及人们对网上购物的趋向日益明显。购票也不止单单的局限于购票点中的传统模式，现在购票网作为网上购物的一种形式,类似于网店的程序，有详细的车票分类、网上订购、网上支付、送货上门，就像一个小型的B2G在这种虚拟“网上购票点”中我们体会到了其中的方便。如:大多数的同学都利用课余时间订购车票，有些时候又正好是碰到节假日，小长假之类的情况，这样节约了不少的时间和精力。学生离购票点比较远，买票不方便。于是选择网络购票，这样不用跑腿就可以买到及时的车票了。
战略
作为一个新兴的，首先我们要把精力花在建设上面。将会实行会员注册模式，我们公司会有专业人员在线为注册会员提供各类免费的咨询服务，并且定期为服务做一个评测。如此，我们也可以吸引更多的商家来与我们合作，当然，我们会一直坚守着宁缺毋滥的原则，务必做到能让消费者满意。其次，我们还会建立网上博客、论坛等以顾客为主题的界面，从而积累我们网页的人气，从而更快的达到我们第一阶段的目标。其次突破宣传这一关。我们会利用各种渠道，比如，传单，宣传海报，在学校贴吧里发帖等让在校学生尽可能了解我们的的操作方法并且成为我们的会员。
项目概况
随着网络的普及人们对网上购物的趋向日益明显。购票也不止单单的局限于购票点中的传统模式，现在购票网作为网上购物的一种形式，类似于网店的程序，有详细的车票分类、网上订购、网上支付、送货上门，就像一个小型的B2G在这种虚拟“网上购票点”中我们体会到了其中的方便。如:大多数的同学都利用课余时间订购车票，有些时候又正好是碰到节假日，小长假之类的情况，这样节约了不少的时间和精力。学生离购票点比较远，买票不方便。于是选择网络购票，这样不用跑腿就可以买到及时的车票了。
1.3 本文结构
本文通过 8 部分来设计在线票务管理系统。
第一章 绪论：主要讲述该系统开发的背景、目的、内容及其发展的趋势等。
第二章 需求分析：主要对该系统的各种需求进行分析。
第三章 概要设计：主要讲述设计思想、设计的内容、设计原则及其各个需要实现的功能模块的层次图和例图。
第四章 数据库设计：比较几种数据库的区别以及该系统的数据表的结构设计软件工程课程实践设计报告。
第五章 详细设计：各个功能模块的设计思路及其设计的 N-S 图。
第六章 系统实现：通过编码实现出票务公司网上订票系统。
第七章 测试报告：根据预想情况和实际情况给出测试结果说明。在系统实现后，通过设计相应的覆盖测试，对系统进行相应的测试。
最后，总结本系统的不足之处，以及对将来的期望。
第2章 需求分析
2.1 用户需求
本系统是一个面向用户的在线票务管理系统。此系统是一种比较智能化的管理系统，它面向所有大众的的系统，具有比较高的安全性能。它能够实现在线订票的基本功能，包括新演唱会信息的录入、订阅、查询等操作以及后台数据库的备份和恢复。用户合法注册后必须输入有效密码才能成功进入此系统，可以进行在线选票，查询信息，统计信息等操作。对于非法操作，系统有识别和防护措施。
网上订票的特点是门票信息处理量比较大,所管理的票类种类繁多,而且订票单、编辑单的发生量特别大,关联信息多,查询和统计的方式各不相同。因此在管理上实现起来有一定因难。
本系统在设计过程中,为了克服这些困难,需要使程序代码标准化,软件统一化,确保软件的可维护性和实用性；删除不必要的管理冗余,实现管理规范化、科学化；界面友好、简单化,做到实用、方便,尽量满足管理员的需要。
2.2 可行性分析
在开发系统之前要进行系统可行性分析，目的是在用最简单的方法去解决最大的问题，程序一旦开发出来满足了用户的需要，所带来的利益也很多。下面我们将从技术、操作、经济等方面来选择这个系统最终是否开发。
2.2.1 技术可行性
本系统开发选择Java技术，Java是一个完全面向对象的语言，Java为开发者提供了丰富的类库，大大减少了使用windows编程的难度，减少开发人员在设计算法上的难度，它友好的界面，以及强大的功能，给程序开发人员带来了很多方便，加上环境简单，转移方便，无疑使此系统最佳的选择。所以后台设计选择使用MySQL数据库主要用来的建立和维护信息。对于前台开发要求应具备功能完善、易于操作等优点，后台数据库的要求则是能够建立和维护数据信息的统一性和完整性。依据上述目标来分析本系统的硬件如下：奔腾3的处理器；内存是 2G；硬盘是50G；操作系统是Window 10；在软件方面的话，应用Idea和MySQL数据库开发工具。根据以上的软件与硬件要求，得到这个系统的技术是可行的。
2.2.2 经济可行性
基于SSM的影院购票系统，该系统软件开发仅需要一台普通的计算机便可完成实现开发，其成本很低。另外，作为毕业设计作品来讲，开发成本基本上可以忽略不计，且该系统软件的投入使用，可以实现更加快速高效的影院购票系统，同时还能实现对人力资源和管理资源的有效节约，该影院管理系统在经济上完全可行。
2.2.3 操作可行性
现在随着科技的飞速发展，计算机早已经进入了人们的日常生活中，这使得人们的工作效益有了很大的提高。操作的多样性也变高了。因此，管理的计算机化，智能化是社会发展而带来的必然趋势，各种智能的软件层出不穷，不同的软件能完成用户不同的需求，这不仅提高了工作效率还能完成一些客户特定的一些需求。本系统不仅界面简洁明了还采用可视化界面，用户只要用鼠标和键盘就可以完成对相关信息的修改，删除，添加等操作。因为这个系统的操作十分简单，方便上手，对于第一次使用系统的人，只需要很少的时间就可以上手操作。由此可见，本系统在操作上是可行的。
2.3 系统功能分析
该系统主要实现了管理员信息、网站用户信息、新闻公告信息、电影类型信息、电影信息、订单信息、功能模块。具体功能如下所示：
1.管理员信息：可以查看到所有的管理员信息列表，对现有订单信息进行搜索、编辑、删除的操作。
2.网站用户信息：管理员可以对全部网站用户信息进行搜索、编辑、删除，查看用户信息列表。
3. 新闻公告信息：管理员可以对新闻公告信息进行编辑、删除的操作，可以查看到新闻公告的点击量。
4. 电影信息：管理员可以查找到所有电影信息列表，并对已有的电影信息进行编辑、删除的操作。
5. 订单信息：管理员可以查找到所有订单信息列表，并对已有的订单信息进行编辑、删除的操作。
2.4 系统模块分析
（1）门票商家模块
用户管理：进行南家的登记注册、密码管理、以及演唱会公开信息的发布。
门票管理：进行空缺门票的信息发布和更新，以及修改其中的门票内容，到货时间，门票属性（某某某的演唱会门票）等。
门票查询：设置搜素条件进行现有门票的查询，查找满足门票属性要求的购物者。
门票处理：对针对当前门票的需求进行筛选。
订单功能：实现订单的各项功能。
（2）个人模块
用户管理:进行购票人员的注册登记管理以及密码建立。查找和修改的管理。
门票管理:完成购票人员的个人信息的输入和保存，更改等。
门票搜索:按所设置的搜索条件进行符合要求的门票进行搜索，帮助购票人员及时发现合适的门票机会。
门票收藏:对于多个意向演唱会门票可以建立个人的商品收藏夹。进行保存。
求购投递:对所需的门票进行求购。
订单管理:对门票的订单添加、删除、生成。
（3）管理员模块
用户管理:进行管理员的注册登记管理及密码和相关权限的建立。
管理商家信息:对门票商家进行删除，修改和添加功能。
管理个人信息:对个人用户进行删除，添加和修改功能。
管理购票信息:对购物信息的删除，添加和修改。
订单功能:对订单信息进行删除，添加和修改功能。
第3章 概要设计
3.1 总体设计
总体设计阶段应该确定系统的物理配置方案，并且进而确定组成系统的每个 程序的结构。因此，总体设计阶段主要由两个小阶段组成。首先需要进行系统设 计，从例图触发设想完成系统的功能的合理方案。然后进行软件结构的设计，确定软件由哪些模块组成，层次图是描绘软件结构的常用工具。
3.1.1 设计思想
（1）将系统先分成几个独立的模块，然后依次实现每个模块的功能。
（2）使用分层的模块化程序设计思想，整个系统都采用模块化结构设计， 这样可以是系统具有较强的可读性、易扩展性和操作性。
（3）合理设计各个模块间的依赖程度，应尽可能做到高内聚，低耦合。
3.1.2 设计原则
为了使本系统功能齐全完备，操作简便，最大限度的提高软件的质量， 从而满足管理人员的实际需要，在设计开发过程中应遵循以下原则：
（1）合理性原则：依据影院购票系统的工作规定及要求，参照实际工作情况，进行功能设计；
（2）实用性原则：应考虑管理人员的切实需要来进行系统设计，所设计的 功能应是具有实际意义的；
（3）易操作原则：要求设计的系统功能齐全，接口友好，操作方便，必要的地方进行提示；
（4）可维护原则：为了便于其他修改维护，在设计时，进尽可能的做好说明，化繁为简，增加可读性；
（5）安全性原则：应杜绝合法用户的非法操作或非法用户的一切操作，以保障系统的安全性；
3.2 体系结构设计
本系统采用的是 B/S 结构。B/S 结构是基于 WEB 技术与客户机/服务器结构 的结合而提出来的一种多层结构,其中 B 是指 WEB 浏览器，S 是指应用服务器与 数据服务器。目前该结构被广泛的应用于商场商品管理系统种。B/S 结构是基 于浏览器、服务器模式的，因此布局限于局域网，且进行系统的维护和升级时一般只要完成服务器端的相关工作即可，工作量相对较小。工作模式如图 3.1 所示。
图 3.1 B/S结构工作模式
3.3 系统总体设计框架
本系统主要面向购票人员和买票商家两个群体。可分为系统包括管理员、 买票用户和买票商家人员三种角色，如图 3.2 所示。
图3.2 系统总体设计框架
3.4 系统类的设计
3.4.1 类的划分
本系统划分为六个类，分别为订单实体类(Order)、商品实体类(Commodity)、店铺实体类(Shop)、商品类别实体类(Commodity category)、 用户实体类(User)和文件实体类(File)。
订单实体类(Order)如图3.3所示
图3.3订单实体类
商品实体类(Commodity) 如图3.4所示
图3.4商品实体类
店铺实体类(Shop) 如图3.5所示
图3.5店铺实体类
商品类别实体类(Commodity category) 如图3.6所示
图3.6商品类别实体类
用户实体类(User) 如图3.7所示
图3.7用户实体类
文件实体类(File) 如图3.8所示
图3.8文件实体类
3.4.2 类间关系的确定
订单实体类(Order)、商品实体类(Commodity)、店铺实体类(Shop)、商品类别实体类(Commodity category)、 用户实体类(User)和文件实体类(File)之间的关系是： 一个店铺可以有零个或多个订单、有零个或多个商品、有零个或多个商品类别；一个用户可以有零个或多个订单；用户能购买必定存在商品信息；店铺收到订单信息必定存在用户购买商品，如图3.9所示。
图3.9 类间的关系
第4章 数据库设计
4.1 数据库选型
数据库选型是指在创建或者运用数据库时，选择适当的数据库管理系统。这一选择非常重要，因为不同的数据库管理系统有不同的特性和性能，因此选择适当的数据库管理系统可以提高数据库的性能和效率，并使得数据库更适合应用于特定的业务场景。
在进行数据库选型时，需要考虑以下要素：
1.数据库的性能和可伸缩性，包括处理大量数据和高并发请求的能力。
2.数据库支持的数据模型和查询语言，以及它们对于特定应用的适用性。
3.数据库的安全性和可维护性，包括数据备份和恢复、故障恢复、权限管理等功能。
4.数据库的许可证费用和支持模式，以及与其他系统的集成能力。
5.开发团队的技术水平和熟悉程度，以及现有的技术栈是否与选定的数据库相匹配。
6.数据库的发展趋势和市场占有率，以及它们的社区支持情况。
4.1.1 几种数据库比较
中型数据库：MySQL、SQL Server
Mysql 是一个开源的完全免费的数据库系统，是一个快速的、可靠的易于使用的数据库服务器。
SQL Server 是由微软开发的数据库管理系统，它只能在 Windows 上运行，它已经广泛用于电子商务、银行、保险、电力等与数据库有关的行业。
大型数据库：oracle
Oracle 能在所有主流平台上运行，它是目前世界流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的，适应高吞吐量的数据库解决方案。
4.1.2 MySQL数据库
MySQL是一种关系型数据库管理系统（RDBMS），用于存储和组织大量信息。它使用 SQL（结构化查询语言）来执行数据库操作，如插入、更新和删除记录。
MySQL可以运行在多种操作系统上，包括 Windows、Linux、macOS 和 Unix。它是一个流行的选择，因为它是免费的、易于使用，并且可以处理大量数据。 MySQL也可以作为网站后端数据库使用，用于存储用户信息、商品信息等。SQL 函数使用高度优化的类库实现，运行速度极快。所以本系统是采用MySQL 来开发的。
4.2 数据库设计
数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
4.2.1 数据库概念设计
基本项构思ERD的四条基本原则：
原则1（确定实体）：能独立存在的事物，例如人、物、事、地、团体、机构、活动、事项等等，在其有多个由基本项描述的特性需要关注时，就应把它作为实体。
原则2（确定联系）：两个或多个实体间的关联与结合，如主管，从属，组成，占有，作用，配合，协同等等，当需要予以关注时，应作为联系。实体间的联系可分为一对一、一对多、多对多等三类，在确定联系时还要确定其类型。
原则3（确定属性）：实体的属性是实体的本质特征。实体应有标识属性（能把不同个体区分开来的属性组），并指定其中一个作为主标识。联系的属性是联系的结果或状态。
原则4（一事一地）：信息分析中得到的基本项要在且仅在实体联系图中的一个地方作为属性出现。
经过上述系统功能分析和需求总结，设计如下面所示的数据项和数据结构：
文件表（file）：用于存放网页内部分文件的地址，如网页内图片的url等。
产品表（product）：用于存放演出的名称、价格、封面以及演唱会图片等。
演出类别表（product_category）：用于存放演出的类型，包括演唱会、音乐会、曲苑杂坛等。
订单表（product_order）：用于存放订票订单信息。
店铺表（shop）：用于存放店铺信息。
用户表（user）：用于存放用户的用户名、密码、昵称、头像等。
根据上面的设计规划出来的实体有订单实体、演出实体、商店实体、演出类别实体以及用户实体。
4.2.2数据库逻辑设计
一般逻辑模型设计：
关系模型的逻辑结构是一组关系模式的集合。将E-R图转换为关系模型就是要将实体型、实体的属性和实体型之间的联系转换为关系模式。
由ERD导出一般关系模型的四条原则；
一个1：1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果软换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式何明，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。
一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
一个m：n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
3个或3个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系项链呢的各实体的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分。
根据以上原则，数据库的关系模式如下：
文件（文件名、文件地址、文件描述、文件更新日期、文件位置）
演出（演出名、演出价格、最高价、最低价、封面、图片、标题、描述、售卖量、收藏数量、时间、折扣、分类id、服务、推荐类型、链接、商店id）
演出类型（类型名、pid、封面）
订单（订单名、价格、支付状态、用户id、演出id、创建时间、评论、评论时间）
用户（用户昵称、用户名、密码、头像）
具体逻辑设计
文件表设计，如表4.1
表4.1 文件表
| 表名 | 文件表 File | |||
| 说明 | 存放网页内部分文件的地址 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 文件唯一标志号 |
| Name | VARCHAR(255) | Y | N | 文件名 |
| Url | VARCHAR(500) | Y | N | 文件转跳路径 |
| Describe | VARCHAR(255) | Y | N | 文件描述 |
| Date | TIMESTAMP | Y | N | 文件上传时间 |
| Type | VARCHAR(255) | Y | N | 文件类型 |
| Position | VARCHAR(255) | Y | N | 文件转跳路径 |
演出表设计，如表4.2
表4.2 演出表
| 表名 | 演出表 Product | |||
| 说明 | 存放演出信息 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 演出唯一标志号 |
| Name | VARCHAR(255) | Y | N | 演出名 |
| Price | DECIMAL(10,3) | Y | N | 演出价格 |
| MaxPrice | DECIMAL(10,3) | Y | N | 演出最大价格 |
| MinPrice | DECIMAL(10,3) | Y | N | 演出最小价格 |
| Covers | VARCHAR(1000) | Y | N | 演出封面 |
| Phontos | VARCHAR(1000) | Y | N | 演出照片 |
| Tittle | VARCHAR(255) | Y | N | 演出标题 |
| Describe | VARCHAR(500) | Y | N | 演出描述 |
| Sales | VARCHAR(255) | Y | N | 演出销售数量 |
| Collect | VARCHAR(255) | Y | N | 演出收藏数量 |
| SendTime | VARCHAR(10) | Y | N | 演出时间 |
| Discount | INTEGER | Y | N | 演出折扣 |
| CategoryID | INTEGER | Y | N | 演出分类ID |
| Services | VARCHAR(100) | Y | N | 演出的保证ID |
| RecommendType | VARCHAR(11) | Y | N | 演出推荐类型 |
| Link | VARCHAR(500) | Y | N | 演出链接 |
| ShopID | INTEGER | Y | N | 店铺ID |
演出类型表设计，如表4.3
表4.3 演出类型表
| 表名 | 演出类型表 Product_category | |||
| 说明 | 存放演出类型相关信息 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 商品唯一标志号 |
| Name | VARCHAR(255) | Y | N | 分类 |
| PID | INTEGER | Y | N | 二级分类ID |
| Cover | VARCHAR(500) | Y | N | 分类封面 |
演出订单表设计，如表4.4
表4.4 演出订单表
| 表名 | 演出订单表 Product_order | |||
| 说明 | 存放演出订单相关信息 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 演出订单唯一标志号 |
| Name | VARCHAR(255) | Y | N | 订单名 |
| Price | DECIMAL(10,2) | Y | N | 订单价格 |
| IsPay | VARCHAR(10) | Y | N | 是否支付 |
| UserID | INTEGER | Y | N | 订单用户ID |
| ProductID | INTEGER | Y | N | 订单演出ID |
| CreateDate | TIMESTAMP | Y | N | 订单创建时间 |
| Judge | VARCHAR(500) | Y | N | 商品评价 |
| JudgeDate | TIMESTAMP | Y | N | 商品评价时间 |
店铺表设计，如表4.5
表4.5 店铺表
| 表名 | 店铺表 Shop | |||
| 说明 | 存放店铺相关信息 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 店铺唯一标志号 |
| Name | VARCHAR(255) | Y | N | 店铺名 |
| Cover | VARCHAR(500) | Y | N | 店铺封面 |
| Describe | VARCHAR(255) | Y | N | 店铺描述 |
| Price | VARCHAR(10) | Y | N | 单价 |
| Scales | VARCHAR(255) | Y | N | 销量 |
| ProductNumber | VARCHAR(255) | Y | N | 库存总量 |
用户表设计，如表4.6
表4.6 用户表
| 表名 | 用户表 User | |||
| 说明 | 存放用户的相关信息 | |||
| 字段名 | 数据类型 | 是否为空 | 是否为主键 | 说明 |
| ID | INTEGER | N | Y | 用户唯一标志号 |
| Name | VARCHAR(255) | Y | N | 用户昵称 |
| Username | VARCHAR(255) | Y | N | 用户名 |
| Password | VARCHAR(255) | Y | N | 用户密码 |
| Url | VARCHAR(255) | Y | N | 用户头像链接 |
4.2.3数据库物理设计
设计索引：
我们可以在最经常查询的列上建立索引以提高查询效率，建立的三个视图如下所示。
用户信息视图，如图4.1。
图4.1 文件信息视图
演出信息视图，如图4.2。
图4.2 演出信息视图
用户信息视图，如图4.3
图4.3 用户信息视图
在有多个用户操作时，考虑用户授权与安全性控制。
因为这个演出订票系统由多个用户使用，分为管理员和用户，他们拥有不同的权限和安全性控制。所以在权限设置方面，采用管理员和用户分别使用用户名和密码进入他们能使用权限范围里的界面。管理员登陆系统后，可以添加、修改用户和演出的信息，可以对订单进行查询和统计，并且可以把查询统计的结果进行预览和打印出来，还要对数据库系统进行维护，适时备份数据库，一旦数据库遇到问题，可以恢复到最近备份的状态，减少不必要的损失。
用户登录，用户使用该系统前需要进行注册，注册成功后，登录到系统，可以修改自己的信息还可以做出查看演出、订票等行为，但由于权限的限制，他只能查看和统计自己的订单信息。
第5章 详细设计
5.1 系前台设计
详细设计分为系统前台设计和系统后台设计。
软件包配合用户完成的请求顺序如图5.1所示。
图5.1 请求顺序图
5.1.1 网站首页模块
系统前台设计是为了方便用户了解有关影片信息和进行订票。在网站首页我们可以看到演唱会列表、演唱会分类、以及网站的有关信息。网站首页界面如图5.2所示。
图5.2 网站首页界面
点击上方的各个按钮就可以跳转到相关的信息页面。点击站内新闻列表可以直接跳转到该新闻的详细信息页面，点击展示的演唱会可以进入该票的详情页，其中下方的tab栏使用了css的定位功能。主要代码如下:
| #tab-bar[data-v-b2b16564] { position: fixed; bottom: 0; left: 0; right: 0; display: flex; justify-content: space-around; background: #e8e8e8; box-shadow: 0 -1px 1px rgb(100 100 100 / 10%); } |
5.1.2 用户登录模块
此模块主要功能是用于登录本系统，首先将从前台页面提交的用户名和密码进行接受，之后在后台进行处理，按照用户名在数据库中进行查询如果查到该用户则将该用户的密码取出来赋给一个字符串变量，判断从数据库中读出的密码与登录时输入的密码是否配比上，若两个密码相同则进入相应的页面，否则输出密码错误。登录顺序图如图5.3所示
图5.3 登录顺序图
点击下方的我的进入个人信息界面
图5.4 个人信息页面
图5.5 用户名密码错误页面
用户要想订票就得先注册再订票。如果没有注册就不能执行订票功能。
注册流程:用户填写用户注册页面的表格，然后点击注册按钮，系统验证用户输入的注册信息是否合法，如果合法就把用户输入的注册信息保存到系统的数据库中。如果注册信息不合法就提示出错。用户注册顺序图如图5.6所示
图5.6 注册顺序图
图5.7 用户注册界面
5.1.3 订票模块
用户可以通过点击展示在主页的演唱会场次进入订票模块界面，可以加入购物车和立即购买，可以在该界面查看商品的详细信息。加入购物车后会在购物车模块显示商品信息。
图5.8 商品信息界面
购物车可以对加入购物车的订单信息进行付款操作。购买成功之后订单会提示成功，并从购物车列表内删除订单，订票模块顺序图如图5.9所示。
图5.9 订单状态更新顺序图
图5.10 购物车界面
此外，在订票界面，还可以通过上方tab切换当前选择的状态，一共分三种状态，分别是流行、热门和精选。
图5.11 主页tab栏
5.1.4 分类模块
在底部导航栏中，有分类一栏，点击后可以进入演唱会的分类查询。点击左侧导航栏的不同分类可以查看不同的类型的演唱会。
图5.12 演唱会分类
分类查询的顺序图如图5.13所示。
图5.13 查询顺序图
第6章 系统实现
6.1 开发框架
6.1.1 后端开发的框架
后端是使用 Spring Boot 框架的，Spring Boot 实现了分层开发，其结构图如图 6.1 所示。
图 6.1 Spring Boot 结构图
使用 Spring Boot 最为后端的框架的原因是：
（1）使编码变得简单
（2）使配置变得简单
（3）使部署变得简单
（4）使监控变得简单
6.1.2 前端开发的框架
前端是使用 Vue 框架的，Vue 是一套用于构建用户界面的渐进式框架。与其他大型框架不同的是，Vue 被设计为可以自底向上逐层应用。Vue 的所有组件如图 6.2 所示。
图 6.2 Vue 的所有组件
使用 Vue 最为前端的框架的原因是：
（1）易于上手，便于与第三方库或既有项目整合
（2）遵循 MVVM 模式
（3）编码简洁、体积小、运行效率高，且适合移动端/PC 端
（4）只关注 UI，可以轻松引入 Vue 插件或其他第三方库开发项目
（5）采用自底向上增量开发的设计，通过简单的 API，实现响应的数据绑定和组合的视图组件
（6）实现数据双向绑定，使数据保持一致
6.2 准备工作
6.2.1 建立开发环境
开发工具：IntelliJ IDEA 2021.1 x64 和 WebStorm 2021.2.1
操作系统：Windows 11
6.2.2 开发软件配置
开发语言：JDK 1.8
服务器：Tomcat 9.5.6
数据库：MySQL 5.6.4
基于 Spring 的构建：Spring 5 的新特征都可以在 Spring Boot 2.0 中使用。
项目管理工具：Maven 3.5.2
主开发框架：Spring Boot 2.0 和 Vue 3.4.0
6.2.3 建立数据库及表结构
使用 Navicat Premium 15 工具连接 MySQL，创建 sellticket数据库。根据第四章的表创建 file、product、product_category、product_order、shop、user表。
6.3 注册登录功能模块实现
在我的页面点击注册登录进入注册登录页面，输入注册信息：用户名#{name}、用户账户#{username}、密码#{password}、用户头像#{url}。在点击注册按钮时，数据库会对改信息进行校验，审核通过会弹出注册成功的消息框，注册失败则告知失败原因并返回重新注册。
图6.3注册登录接口
6.4 网站首页模块实现
网站首页上部展示促销或热门的演出小广告轮播图，中间部分展示演唱会火爆类别上映，下部分为三类：流行、热门、精选，每一分类都呈现即将售卖的演唱会门票，点击它跳转到订票购买模块展示具体内容。
内容展示主要是商品推荐类型为：流行pop、新款new、精选sell、本周推荐week。然后就是分页显示，统计每页数量size和页数page来按照类型分页查询商品。
图6.4首页页面接口
6.5 商品分类模块实现
点击页面底部分类部分进入商品分类模块页面，左侧是具体不同类别展示，右侧是每一类别的内容合集。分类按照等级1,2,3...进行数据库分类，每一类关联的id号存入每一类具体的商品内容。
图6.5商品分类模块接口
6.6 订票购买模块实现
选中想要查看门票进去后，页面上部轮播图呈现广告和门票内容展示，大致分为四类：商品、参数、评论、推荐。商品展示门票价格，促销活动折扣，销量，收藏量，观看时长。参数展示总销量，描述相符度，价格合理度等。评论展示图片和视频以及文字的描述。推荐还会展示相关分类别的火爆演出。
可以先加入购物车增加订单，isPay：-1是购物车，0是未支付，1是支付成功。直接购买下单即可isPay=1。
图6.6订单购买模块接口
6.7 项目管理方法及实施过程说明
1、确立项目的整体目标。在指定项目组织的战略，以长期发展为目标来实现短期项目内容设计计划。
2、责任清楚，合理分工，指定团队各位的任务目标。以前后端分离并行开发编写项目代码，然后再进行数据库的分析填写，再由各组员们完成项目报告撰写，最后协同合并任务实现总体目标。
3、目标实现，完善报告。各组员畅所欲言，吸收总结完善报告内容排版美化。检查分析报告漏洞并解决。
第7章 测试报告
7.1 测试概述
7.1.1 测试对象
本次的测试对象为票务公司网上订票系统，该系统的设计实现主要由平台管理员、商家用户和消费者用户这三类人员来进行操作，管理员主要是对信息管理、商家和消费者用户进行管理;消费者用户操作主要是搜索演出门票、浏览演出详情、搜索演员歌手、购买及收藏演出等;商家用户主要是发布招演出信息和定价信息等。该系统的设计与实现使得双方信息尽可能的共享，为双方提供便利，有其存在的社会价值和实用价值。
7.1.2 测试目的
本次测试主要是测试该系统它的并发操作时的测试(负载能力)、具体功能测试、组合操作的测试、系统的兼容性、某种特定情况下的系统运行(实时响应)和后台功能等。
7.2 测试方法
7.2.1 测试用例设计
对于本系统的测试包括对系统的用户界面测试和功能性测试,测试的范围涉及系统的各个功能模块的测试，其中重要且量大的便是测试用例的设计,对于测试用例的设计主要是对各个功能进行边界值设计、正常数据的输入等，便于测试和查看测试结果。
7.2.2 测试环境
测试环境如表7-1所示。
| 软件环境（相关软件、操作系统等） |
| 操作平台：Windows 10 64位 |
| 数据库：Mysql |
| 服务器：Tomcat |
| 浏览器：Edge |
| 硬件环境 |
| CPU：2.0GHZ及以上 |
| 内存：2.0GB及以上 |
表7-1 测试的系统环境表
7.3 功能测试及用户界面测试
7.3.1 测试范围
测试的范围涉及系统的各个功能模块的测试,下面对系统的功能测试进行测试需求分析,确定测试范围,其功能测试和界面测试概要表分别见表7-2、表7-3。
| 测试目标 | 保证系统系统能够正确、稳定运行 |
| 测试范围 | 系统的各个功能模块 |
| 技术 | 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容: 在使用有效数据时得到预期的结果。 在使用无效数据时显示相应的错误消息或警告消息。 各业务规则都得到了正确的应用 |
| 初始标准 | 系统正常启动运行 |
| 完成标准 | 系统的所有功能均与预期相符，通过测试 |
| 测试重点和优先级 | 根据用户需求，系统主要功能模块的优先程度如下: 1.注册登录模块 2.信息管理模块 3.用户管理模块 4.演出信息发布模块 |
表7-2 功能测试概要表
| 测试目标 | 通过测试进行的浏览可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法(Tab 键、鼠标移动、和快捷键)的使用 窗口的对象和特征(例如，菜单、大小、位置、状态和中心)都符合标准。 |
| 测试范围 | 系统管理的各个界面 |
| 技术 | 为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确地进行浏览，并处于正常的对象状态。 |
| 开始标准 | 系统界面可以正常载入，用户可以登录进入主界面 |
| 完成标准 | 成功的核实出界面整齐，或符合可接受标准 |
| 测试重点和优先级 | 根据用户需求和系统设计，系统界面测试的重点如下: 1.不同浏览器下页面是否引起样式问题 2.窗口的对象和特征是否符合标准或是否可接受 |
表7-3 用户界面测试概要表
7.3.2 测试功能
功能测试是用于测试系统的功能需求的黑盒测试方法。根据产品特征、操作描述和用户方案,测试产品的特性和可操作行为以确定它们满足设计需求。功能测试用于验证应用程序对用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。如7-4测试需求表。
| 需求编号 | 功能分类第一层 | 功能分类第二层 | 功能点测试 | 优先级 |
| 1 | 启动条件 | 联网状态 | 登陆 | 高 |
| 2 | 登陆成功 | 常规 | 登陆成功 | 高 |
| 3 | 必须输入项 | 用户名与密码 | 高 | |
| 4 | 登陆失败 | 失败原因 | 检查数据库连接 | 高 |
| 5 | 检查web服务连接 | 高 | ||
| 6 | 检查网络连接是否超时 | 中 | ||
| 检查用户名密码是否正确 | 高 |
表7-4 测试需求表
对登录功能进行等价类划分(如表7-5)后，下面将对其测试用例进行设计，设计的测试用例应该覆盖各个有效等价类和无效等价类，由此可以设计出如下表7-5、7-6所示的测试用例。
| 输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
| 账号密码 | 字符正确 | 1 | 密码或账号无输入 | 2 |
| 密码或账号输入非法字符 | 3 | |||
| 账号密码输入错误 | 4 |
表7-5 灯等价类划分表
| Case ID | 功能点测试项 | 操作步骤 | 方法 | 测试数据 | 优先级 | 正确结果 |
| 1 | 登陆 | 1、输入账号密码 2、点击登陆 | 等价类 | 输入正确密码 | 高 | 登陆成功 |
| 2 | 等价类 | 输入错误密码 | 高 | 登陆失败 | ||
| 3 | 等价类 | 输入非法字符 | 高 | 登陆失败 | ||
| 4 | 等价类 | 账号密码无输入 | 高 | 登陆失败 |
表7-6 测试用例表
7.3.3 用户界面测试
用户页面测试也即是UI(UserInterface)测试，UI测试的目的是确保用户页面会通过测试对象的功能来为用户提供相应的访问或浏览功能,也是通过浏览测试对象可正确反映业务的功能和需求，这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法的使用窗口的对象和特征都符合标准。测试页面图为登录页面，如图7.1所示。
图7.1 登陆界面
用户界面测试规范，如表7-7.
| 测试目标 | 确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循软件行业的标准。用户界面要友好，符合用户需要。 |
| 测试范围 | 涵盖操作界面中所有的反应广大用户需求和习惯的能够得到改进的部分 |
| 技术 | 触发系统所有超链接和按钮事件，查看页面的跳转目标网页，页面的响应时间;对那些需要频繁显示的网页进行反复测试，测试其异常处理能力和界面的美观程度。极少使用的网页保证不出错误。 以核实以下内容: 大部分网页界面是很符合用户要求的，页面的响应能力符合用户需求 在用户登录页面中有用户反映界面不美观，需要改进 |
| 开始标准 | 系统正确运行 |
| 完成标准 | 用户对页面操作时，满足用户需求，如点击连接或按钮时，页面响应时间快。界面的设计符合绝大多数用户的审美需求，具有友好的用户界面 |
| 测试重点和优先级 | 系统页面设计优先 |
表7-7 用户界面测试规范表
7.4 性能测试
性能测试即软件的一种非功能性能,它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展现出来的及时性。通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。本测试报告对网上人才招聘系统的性能测试主要通过压力测试、负载测试、稳定性测试、连接速度测试等。
7.4.1 测试环境
系统：Windows 10 64位
浏览器：Edge
服务器：Tomcat
7.4.2 测试方法
将系统放到Tomcat上进行运行，执行相关操作，进行程序的测试
7.4.3 测试结果
经过多次反复的测试，系统运行正常，请求与回馈响应时间迅速，基本符合系统的性能特征，其主要的性能测试如下7-8表所示。
| 测试点 | 测试说明 | 注解 |
| 压力测试 | 多次反复的进行操作，测试系统资源是否占用异常 | 该系统某项功能反复进行操作 |
| 负载测试 | 该系统在各种边界压力情况下，检查系统是否可以正常相应 | 如内存满时浏览，电脑欠电时安装，运行时出现网络异常等 |
| 响应测试 | 测试系统的各项操作是否满足响应时间需求 | 例如系统的浏览、功能的响应时间等 |
| 基础测试 | 用户的应用场景下，系统资源的使用情况 | |
| 对比测试 | 宇同款产品的对比测试 |
表7-8主要的性能测试
7.5 兼容性测试
7.5.1 测试环境
系统： Windows 10 64位
浏览器：Edge，QQ浏览器，火狐浏览器，百度浏览器，360浏览器等等
服务器：Tomcat
7.5.2 测试方法
在成功运行之后，分别使用不同的浏览器进行登陆操作，测试该系统功能是否可以正常使用。
7.5.3 测试过程
在不同的浏览器运行结果如表7-9 所示。
表7-9 各浏览器运行情况表
| 测试使用的浏览器 | 期望结果 | 测试结果 |
| 360浏览器 | 正确运行 | 正确运行 |
| Edge | 正确运行 | 正确运行 |
| 火狐浏览器 | 正确运行 | 正确运行 |
| 百度浏览器 | 正确运行 | 正确运行 |
| QQ浏览器 | 正确运行 | 正确运行 |
| 谷歌浏览器 | 正确运行 | 正确运行 |
其中，Edge浏览器的测试结果如图7.2所示
图7.2 Edge浏览器访问系统图
7.5.4 测试结果
通过使用360安全浏览器、Google chrome、 火狐浏览器等多种不同的浏览器登录测试，该系统都可正常的运行，系统的兼容性良好。
7.6 异常设计方法测试
异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析,依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。简单一-点说就是人为让系统出现故障,然后检查系统的故障恢复能力。这些故障包含软件和硬件方面的故障，常见的故障有:断电、断网、硬件损坏、数据损坏、内存不够。需要多查看用户反馈的故障报告，多深入了解被测的系统。
第8章 商业规划设计
8.1 用途规划与市场分析
随着人们生活水平的提高，工作节奏的加快，简单、方便的出行方式日益受到人们的重视，同时人们对于出行时快捷度的要求越来越高，但往往事与愿违。比较而言，传统的方式已经不能满足生活节奏加快的人们。我们的数字化交通系统，就是通过网络和软件的密切配合，替代了原有的繁琐的购票程序，以生成二维码的方式，将一张虚拟的车票发送到顾客手机里，从而实现快速、高效、安全的“无票式”购票。这样既迎合了人们对于安全、快捷等多方面的要求，又是符合时代发展潮流的新产品。
从市场分析来看，线上购票在中国出现后，发展十分迅速，国民的认可度较高，大大提升了用户的体验，减少了大量的取票抢票时间。电子票务网站由此来看已经具有非常大的影响力。综合来看，电子票务的市场前景不容小觑。
8.2 成本与预期效益分析
创业团队一般在初创时期对流动资金需求量都较大,尤其是像这种数字化产品的投入，到后期运营成功之后成本就相对较少了。这需要有一个预先周详的理解和计划以及进行过程中的严格控制来。主要是购买设备和正常管理运营耗费较大等。它的初始投资成本包括需要二维码扫描器，身份证扫描系统，网银接口，电脑硬软件以及服务器等来进行调试，这将需要一大笔流动资金。
成本效益分析如下：
用于正常管理运营:调查成本，交通费，通讯费，差旅费，注册登记费，宽带费，时间人力成本等，需要4000块的流动资金来进行日常活动。
研究开发支出:作为一个创业创新型团队这次主要研究的是把高新技术运用于社会生活中，使得人们的生活更加方便快捷，而设计出一个新的系统，并配合销售策略把技术和设备绑定一起销售出去。
销售收入预测的方法运用本量利分析法,是在成本划分为变动成本和固定成本的基础上，根据销售成本、销售量与利润三者之间的内在联系，假定已知其中两个因素，来推测另一个因素，以寻求最佳方案。运用这种方法，既可以预测保本点销售量和销售收入，也可以预测为实现目标利润需要达到的销售量和销售收入。
销售收入估算表：
| 产品 | 预计销售收入(万元) | ||
| 第一年 | 第二年 | 第三年 | |
| 销售价格 | 15 | 10 | 10.8 |
| 销售次数（次） | 2 | 5 | 7 |
| 合计 | 30 | 50 | 76 |
表8-1销售收入估算表
运营费用表：
| 项目 | 第一年 | 第二年 | 第三年 |
| 管理费用 | 20000 | 25000 | 30000 |
| 财务费用 | 2000 | 2500 | 3000 |
| 合计 | 22000 | 27500 | 3000 |
表8-2运营费用表
8.3 市场推广措施设计
在销售渠道方面,我们选择的是短渠道营销,直接面对合作方进行事宜洽谈。这种方式从总体上节省流通费用;有利于开展售后服务，利于我们和中间商建立直接、密切的合作关系，维护我们的信誉。
项目价格产品服务：在产品推广初期，由于面对的客户类型十分单一，所以我们在定价方面采取一事同仁的策略;在产品与服务方面，我们会做到技术水平稳定、产品价格合理，并且提供未来一定时期内的技术支持。
营销计划：在初期的营销计划中，我们想以一线城市（苏州市）作为项目开展的第一个落脚点，以高校的师资力量、资金能力作为自身优势，用产品演示的方式，赢得买方信任，进而寻求合作关系。初期对我们系统有疑问，则可以进行一段时间的试用。在客运站获得示范效应之后,我们下一步的计划是寻求更多的合作后，将业务范围扩展到电影票、门票等其他售票业务中。在一线城市的推广初见成效后，首先要稳定我们在市场中的地位，将市场做牢固。随后可以将业务逐渐推广至二三线城市。
结 论
票务公司的网上订票系统是一种便捷的方式，可以让您通过网络在线订购机票、火车票、汽车票或其他交通工具的票。这种系统通常通过网站或手机应用程序提供服务，您可以轻松查询票价、选择座位、支付费用并打印或收到电子票。
使用票务公司的网上订票系统可以节省时间和精力，因为您不需要亲自前往售票点或等待排队。此外，网上订票系统通常提供更多的选择和方便的功能，如自动提醒、多种支付方式和退票选项。然而，在使用票务公司的网上订票系统时，您需要注意一些事项，以避免潜在的风险。例如，在输入个人信息或支付费用时，应确保使用安全的网络连接，以防止信息泄露或欺诈。此外，您还应确保您订购的票是真实有效的，并且在使用时遵守交通工具的规定。
总的来说，票务公司的网上订票系统是一种方便和实用的工具，应该谨慎使用。
参考文献
[1] 吴艳 曹平编著，《软件工程导论》清华大学出版社，2021.4
[2] 梁灏编著，《Vue.js 实战》清华大学出版社，2017.10.1
[3] 杨开振编著，《深入浅出 Spring Boot 2.x》人民邮电出版社，2018.8.1
[4] 王珊 萨师煊编著，《数据库系统概论(第五版)》北京高等教育出版社，2014.9
[5] 陈昊鹏 郭嘉，译《Java 编程思想(第 4 版)》北京 机械工业出版社，2007.5
[6] 杨开振编著，《深入浅出 MyBatis 技术原理与实践》电子工业出版社，2016.8.1
[7] 刘何秀 王琳 王建编著，《Web 前端开发技术》北京 人民邮电出版社，2019.9
[8] 元燕辉等编著，《浏览器/服务器应用开发》科学出版社
[9] 王富强编著，《SpringBoot 揭秘》机械工业出版社，2016.5
[10] 王富强编著，《Spring 揭秘》人民邮电出版社，2009.9.1
[11] 曹旭东译，《深入剖析 Tomcat》机械工业出版社华章公司，2011.12.31
[12] 宁海元 周振兴刘辉译《高性能 MySQL(第 3 版)》电子工业出版社，2013.5.1
