软件工程-软件设计作业
机票预订系统软件设计
2013599 田佳业
系统概述
参考现实中机票预订系统的设计，结合实际本系统设计与题目所述有所优化：将付款放在预订机票环节而非取票环节，因为若预订机票后再付款，容易导致恶意抢占预订名额的现象，而付款后再占据预订名额能够增加成本，尽可能的避免这种情况发生。
用例图
下面通过用例图从总体上描述描述机票预订系统的功能性需求。
| 登录 | |
------------------------------- | | 用例ID： 1 | |
参与者： 旅客，工作人员 | | 简要说明：
用户登录航班预订系统 | | 前置条件： 无 | |
基本事件流：
1.用户进入主界面点击“登录/注册”按钮
2.进入登录界面，用户填写登录信息(用户名，手机号，密码)
3.系统校验登录信息成功，用户登录成功
| |
其他事件流：
1.用户进入主界面点击“登录/注册”按钮，跳转至登录界面
2.进入登录界面，用户填写登录信息(用户名，手机号，密码)
3.系统未检索到该手机号，提示用户进行注册，进入注册页面
| |
异常事件流：
1.用户信息填写格式不正确->前端校验，给予提示
2.用户名或密码与手机号不匹配，提示用户重新进行输入
3.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面
| | 后置条件：登录成功，返回首页供用户选择其他操作 | |
注释：实际生活中手机号唯一，往往登录和注册的功能进行合并，可减小用户操作成本。
|
| 注册 |
|---|
| 用例ID： 2 |
| 参与者： 未注册旅客，未注册工作人员 |
| 简要说明： 未注册用户进入注册页面进行注册 |
| 前置条件： 用户手机号未注册 |
| 基本事件流： 1.用户由登录界面跳转至注册界面 2.出现注册页面，默认用户名为登录时输入用户名，手机号为登录时输入手机号。用户完善个人信息。 3.系统发送手机验证码，用户填写验证码，校验正确后完成注册 |
| 其他事件流： 无 |
| 异常事件流： 1.用户信息填写格式不正确->前端校验，给予提示 2.用户手机号已被注册->提示进入登录页面 3.用户验证码不正确->提示用户重新填写 3.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：注册成功，系统添加完成用户信息，登录当前新注册账号 |
| 注释：从登录部分拓展 |
| 查询航班信息 |
|---|
| 用例ID： 3 |
| 参与者： 旅客，工作人员 |
| 简要说明： 用户进入航班查询页面进行航班查询 |
| 前置条件： 无 |
| 基本事件流： 1用户点击搜索框搜索航班 2.系统获取用户查询条件，执行查询，并进入新的页面展示查询结果 |
| 其他事件流： 1..用户点击查看当前航班页面 2。系统获取24小时内起飞的所有航班信息，进入新的页面展示查询结果 |
| 异常事件流： 1.未输入查询条件->前端提示用户输入查询条件 2.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：无 |
| 注释：航班信息管理包含查询航班信息，且查询航班信息不需要用户登录 |
| 预订机票 |
|---|
| 用例ID： 4 |
| 参与者： 已注册旅客 |
| 简要说明： 旅客进行机票预订 |
| 前置条件： 已登录并选择了希望预订的航班 |
| 基本事件流： 1用户点击座位充裕的航班 2.选择座位等次和位置，提交预订机票请求 3.预订机票成功，提示用户进行付款 4.用户支付机票金额，系统生成取票凭据及账单，并提示用户及时查看已订机票信息并打印取票凭据。 |
| 其他事件流： 无 |
| 异常事件流： 1.用户选择航班时未登录->跳转至登录页面提示用户登录或注册 2.提交请求时由于优先级低，被其他旅客预订->提示机票已被预订，让旅客重新选择 3.预订机票后15分钟内未付款->系统收回用户预订机票 4.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：用户拥有在线机票，该航班信息更新 |
| 注释：系统并不强制旅客必须在预订机票后查询已订机票，尽管系统建议旅客时查看已订机票信息并打印取票凭据。 |
| 查询已订机票 |
|---|
| 用例ID： 5 |
| 参与者： 已注册旅客 |
| 简要说明： 旅客进行已订机票的查看 |
| 前置条件： 已登录 |
| 基本事件流： 1用户点击“我”->已订机票 2.系统根据用户ID查询该用户已订购机票，并返回机票信息 |
| 其他事件流： 无 |
| 异常事件流： 1.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：用户得知已订购机票，在该页面进行后续操作，如获取取票凭据，退票等 |
| 注释：系统并不强制旅客必须在预订机票后查询已订机票，尽管系统建议旅客时查看已订机票信息并打印取票凭据。 |
| 退票 |
|---|
| 用例ID： 6 |
| 参与者： 已注册旅客 |
| 简要说明： 旅客在查询页面选择进行退票 |
| 前置条件： 已登录 |
| 基本事件流： 1用户在查询已订机票页面点击退票 2.系统提示用户确认后，取消用户航班。 |
| 其他事件流： 1.若用户已取票，更新票据状态为无效 2.若用户已付款，退回已付金额 |
| 异常事件流： 用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：用户已订机票信息和航班信息更新，该用户航班取消。 |
| 注释：无 |
| 获取取票凭据 |
|---|
| 用例ID： 7 |
| 参与者： 已注册旅客 |
| 简要说明： 旅客保存或打印取票凭据 |
| 前置条件： 已预订成功机票 |
| 基本事件流： 1用户保存取票凭据页面选择保存电子版凭据或打印纸质版凭据 2.系统生成凭据二维码或打印取票通知 |
| 其他事件流：无 |
| 异常事件流： 1.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 2.无法打印->提示用户保存电子版凭据或等待 |
| 后置条件：用户获得取票凭据 |
| 注释：获取取票凭据为起飞前取票做准备 |
| 取票 |
|---|
| 用例ID： 8 |
| 参与者： 已注册旅客 |
| 简要说明： 旅客凭取票凭据取票 |
| 前置条件： 旅客已获得取票凭据 |
| 基本事件流： 1.用户输入个人信息(如手机号和验证码)，系统进行身份校验 2.系统读取用户电子版或纸质凭据，并进行校验 3.校验通过，打印票据给旅客 |
| 其他事件流：无 |
| 异常事件流： 1.系统校验失败(如身份校验不通过，用户票据无效等)->根据情况提示用户错误信息 2.无法打印->提示用户等待，并向管理员报告错误 3.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：用户获得机票，准备乘机 |
| 注释：即使取票依赖取票凭据，但取票并不与获取取票凭据有包含或拓展的关系，因为取票并不是获取取票凭据的特殊化，因此不是拓展关系；并不是取票时必须调用获取凭据操作，因此不是包含关系。 |
| 个人信息管理 |
|---|
| 用例ID： 9 |
| 参与者： 已注册旅客，已注册管理员 |
| 简要说明： 旅客和管理员个人信息管理 |
| 前置条件： 旅客或管理员已注册 |
| 基本事件流： 1.用户点击个人信息管理按钮，系统校验用户名和密码以及验证码 2.修改个人信息，并进行保存 |
| 其他事件流：无 |
| 异常事件流： 1.系统校验失败(如身份校验不通过，用户票据无效等)->根据情况提示用户错误信息 2.用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：用户个人信息发生改变 |
| 注释：无 |
| 航班信息管理 |
|---|
| 用例ID： 10 |
| 参与者： 已注册管理员 |
| 简要说明： 管理员进行航班信息的管理，如增加航班，修改航班信息等 |
| **前置条件：管理员已登录 |
| 基本事件流： 管理员进入航班信息管理页面，进行航班信息的操作，如增加航班，修改航班信息等 |
| 其他事件流：无 |
| 异常事件流： 用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：航班信息被修改 |
| 注释：航班信息管理包含查询航班信息，因为管理航班信息必定要先查看。同时在用例图中不分解出CURD操作，会造成冗余 |
| 账单管理 |
|---|
| 用例ID： 11 |
| 参与者： 已注册管理员 |
| 简要说明： 管理员对账单进行手动管理，如调整旅客已订航班等 |
| 前置条件：管理员已登录 |
| 基本事件流： 1.管理员输入旅客ID(可通过旅客信息管理获取)，查看旅客账单信息 2.视情况对该旅客的账单进行调整 |
| 其他事件流： 管理员根据筛选条件对符合条件的账单进行批量调整 |
| 异常事件流： 用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：管理员查看到账单信息，可能对其有修改 |
| 注释：该功能主要针对系统出现异常或应对航班出现的特殊情况，增加手动管理旅客账单的功能。 |
| 旅客信息管理 |
|---|
| 用例ID： 12 |
| 参与者： 已注册管理员 |
| 简要说明： 管理员进行旅客个人信息的查看，修改等 |
| 前置条件： 管理员已登录 |
| 基本事件流： 1.管理员根据筛选条件(如旅客姓名，航班信息等)，查询旅客信息 2.视情况对旅客信息进行调整 |
| 其他事件流：无 |
| 异常事件流： 用户或服务器网络异常/服务器内部数据错误->根据状态码跳转对应页面 |
| 后置条件：管理员查看到旅客信息，可能对其有修改 |
| 注释：针对旅客个人信息的管理模块，该部分不应包含旅客账单相关内容 |
活动图
活动图中的每个圆角矩形中为动作状态，描述原子性的行为。登录和注册部分的用例较为复杂，在这里用活动图来较为详细的描述登录和注册的流程。
用户未登录或注册完成时，随时可以点击取消结束该用例流程。用户进入登录页面，输入用户名，手机号，密码。系统会查找该用户的手机号是否已完成注册。若用户未注册，系统会自动为用户进行注册，提示用户输入个人信息，通过验证码验证手机号可用后即可完成注册。由于注册时用户有可能改变手机号信息，因此注册阶段也需要验证手机号。确定用户使用手机号注册后系统生成手机验证码，并提示用户输入。用户正确输入验证码后系统接受注册信息，存储新用户信息并自动登录，前端通知用户并结束用例流程，供用户选择后续操作。
类图
类图是系统的概念基础。下面将整个订票系统涉及的实体和控制类通过类图描述。
类图部分事实上是在整个设计过程中考虑和修改次数最多的部分。
由于管理员课执行操作较多，不同管理员除了权限等级差距外执行的具体操作并无差距，我们可以将管理员可以执行的操作提取为静态的方法类。实体类及其方法均需与用例描述对应。
考虑到类图整体的简洁，图中省略了方法参数。
顺序图
顺序图能够体现类与类之间的交互关系。最重要的是，顺序图能够实现某个功能的必要步骤。因此下面分别在细粒度和粗粒度上给出个人信息管理和旅客乘机全过程的顺序图。
前面已经给出了注册登录部分的活动图，在下面的图示中默认提及到的用户均已登录。
个人信息管理
下面展示了用户个人信息管理的顺序图。
用户可查看个人信息，修改个人信息是可选的。同时用户选择结束个人信息管理时前端页面关闭，处理该事务的DAO关闭，数据库需要持续运行。这个过程中所有的消息都是同步消息。
→查询个人信息请求(用户→系统前端)
→提交查询请求(系统前端→DAO)
→根据用户ID查询用户信息(DAO→DB)
→返回用户信息(DB→DAO)
→传送用户信息(DAO→系统前端)
→展示用户信息(系统前端→用户）
→选择需修改的信息(用户→系统前端）
→判断修改的信息，提交修改请求(系统前端→DAO)
→执行修改信息计划(DAO→DB)
→返回执行状态(DB→DAO)
→ 判断是否修改成功，传送修改状态(DAO→系统前端)
→展示修改状态(系统前端→用户）
→结束个人信息管理(用户→系统前端)
→销毁当前DAO(系统前端→DAO)
旅客乘机全过程
旅客乘机包含查询航班信息，预订机票，查看已订机票，获取取票凭据，取票几个阶段。为清晰的表示各阶段之间的关系，不再表示出具体前后端交互的过程，转而强调各个类之间的关系。
查询航班信息(旅客→Flights类）
→返回航班信息(ight类>旅客)
→ 订票请求(旅客→Bi类）
→根据用户所选FlightlD获取用户所选机票价格(Bill类→Flight类)
→ 返回航班价格(Flight类→Bill类)
→生成账单(Bill类→Bill类)
→ 要求用户付款(Bill类>旅客)
→[15分钟内]付款(旅客→Bill类）
→[opt]销毁账单(Bill类→Bill类)
→返回预订成功信息(Bl类→旅客)
→ 获取取票凭据(旅客→CredentialGenerator类）
→ 根据用户所选航班获取账单(CredentialGeneratora类→Bill类)
→ 返回账单ID(Bill类→CredentialGenerator类)
→要求用户选择凭据类型(CredentialGenerator类→旅客)
→用户选择凭据类型(旅客→CredentialGenerator类）
→ 生成凭据(CredentialGenerator类→CredentialGenerator类)
→返回凭据给用户(CredentialGenerator类→旅客)
→取票(旅客→TicketGenerator类）
→ 获取账单信息(TicketGenerator类→Bill类)
→获取航班信息(TicketGenerator类→Flight类)
→等待账单信息和航班信息准备好(TicketGenerator类→TicketGenerator类
→返回账单信息(Bil类→TicketGenerator类)
→返回航班信息(Flight类→TicketGenerator类)
→生成票据(TicketGenerator类→TicketGenerator类)
→打印票据(TicketGenerator类→TicketGenerator类)
→返回机票给旅客(TicketGenerator类→旅客)
这个顺序图展示了旅客乘机所需要经历的完整流程，比较复杂。其中需要着重注意的过程是用户预定后生成的账单是未付款的状态，需要提醒用户进行付款。15分钟未付款账单被销毁。同时，产生机票的过程中需要同时获取账单信息和航班信息，这个过程是无依赖的，因此可以采用异步的方式并行执行。但取票机需要两个信息都获取后才能打印机票，因此需要等待。
协作图
协作图相比顺序图，更强调类与类之间在空间上的交互。事实上，协作图和顺序图是等价的，可以相互转化。
下面给出用户退票用例的协作图。
→查询已订机票(旅客→系统前端)
→提交查询请求(系统前端→DAO)
→执行查询计划(DAO→DB)
→返回已订机票列表(DB→DAO)
→传送已订机票列表(DAO→系统前端
→展示已订机票(系统前端→旅客)
→选择欲退票对应账单(旅客→系统前端)
→发起退票请求(系统前端→DAO)
→查询是否付款及账单金额(DAO→DB)
→返回账单信息(DB→DAO)
→传送账单信息(系统前端→DAO)
→[opt]发起退款(系统前端→支付系统)
→[opt]退款给用户(支付系统→旅客）
→[opt]返回退款结果(系统前端→支付系统)
→展示退票成功消息(系统前端→旅客)
这一部分与用户个人信息管理部分类似。额外的部分主要是账单有已付款和未付款两种状态，如果账单已付款，我们还需要将账单金额退还给用户。
状态图
状态图与活动图相似，只是顾名思义，状态图更多的强调一个对象在不同情形下的状态变化。
下面给出管理员整个工作流程的状态图：
这一部分结合实际比较容易理解。管理员进入系统后可以选择进行个人信息管理，或进行系统其他部分的管理。当进行其他部分管理时均为工作状态。管理员对航班、旅客或账单进行常规的增删改查后，完成工作，注销账号。在已登录状态注销账号进入未登录状态。管理员不管完成工作与否随时可注销账号。
构件图
构件图通过模块和接口，能够很好的呈现和理清模块之间的依赖关系，有助于实现整个系统的高内聚低耦合。
圆圈代表接口，连接圆圈的模块实现该接口，包围圆圈的模块依赖该接口。
下面是整个预订系统的构件图。
可以看到整个系统的依赖关系还是较为复杂的。一定程度上构件图是对类图依赖关系的强化。
部署图
部署图描述了一个系统运行时的硬件特点和在这些节点上运行的软件构件。部署图贴近“落地”，关注物理的运行，以及它们之间如何彼此通信。
下面是该预订系统的部署图。
我们的系统是前后端分离的，通过TCP/IP协议进行信息交互。同时采用MariaDB作为数据库。软件开发商需要提供前端WebAPP，以及后端的实现，还要设计数据库模式。硬件上我们需要存储数据信息以及运行应用的服务器，应对高并发我们还要加设防火墙，并设置负载均衡节点。当然，为了让用户取票据和纸质凭据，我们还需要嵌入式系统和打印机。
总结
不同的UML图示有不同的特点和适用场景。以上为各个场景根据不同种类的图示特点选取了不同的描述方式，总体上从各种粒度和各个角度覆盖了整个机票预订系统最需要我们关注的地方，对整个系统有了更加清晰的了解，为敏捷开发，DevOps等活动打下较好的基础。