《软件工程实验》实验指导书
一、课程目标：
1、使学生能够按照特定的软件选题调研分析相关软件的系统需求，并应用UML建立软件分析模型。
2、使学生能够结合数据库等相关知识设计并实现能够满足问题描述和约束条件的软件系统解决方案，能够应用UML建立软件设计模型并依据模型描述进行系统开发。
3、通过实验分组安排，使学生具有通过团队配合进行有效的分工，并能协调合作共同完成软件项目目标的能力。
4、通过规范的实验报告撰写要求，使学生了软件科技文档的书写要求，并能够准确规范的撰写分析设计文档。
二、实验环境：
1、Microsoft Office 2010及以上版本；
2、Rational Rose7.0及以上版本或其他UML建模工具；
3、Eclipse、Java EE 或其他开发工具；
4、SQL server2012及以上版本。
三、背景知识:
从理论上而言，软件生存期一般都可分为计划、需求分析、设计、编码、测试、运行维护六个步骤。根据软件工程实施过程中的各阶段活动，我们可以把它归结为不同的软件生存期模型，并归结出每一阶段的实施的行为特征。在软件工程的实施过程中，需要制做相应的文档。
1．计划阶段
计划阶段指技术人员辅助管理人员或市场部人员根据项目意向，做出初步需求调查、进行可行性论证，在论证通过后做系统方案，如委托开发，还需签定项目开发合同，并制定项目开发计划。
2．需求分析阶段
需求分析阶段,管理人员提出需求分析阶段计划，分析人员制作软件需求说明书，包括软件需求子系统需求说明书、数据要求说明书、子系统数据要求说明书、系统数据流图、子系统数据流图及其相应的词典。系统需求说明书完成后应通过项目需求评审，经用户确认后出具需求分析验收报告。初步制定测试计划。
3．设计阶段
在设计阶段需要制定系统实现方案，设计阶段计划，填写数据库设计说明书、详细设计说明书，详细设计应通过详细设计评审、出具详细设计验收报告，设计阶段完成后应开始制做用户手册、管理员手册、测试计划与测试案例设计。
4．编码阶段
在编码阶段应有数据库编程规范、编程语言编程规范、内部公用函数（模块）目录等。设计和执行模块测试。
5．测试阶段
设计完成后，就应该进入测试阶段，测试阶段中，应该制定测试规范、填写测试计划与测试说明，测试过程中应填写软件测试报告。
6．运行维护阶段
测试阶段完成后，应进行系统交付，进入运行维护阶段。系统维护阶段，用户发现问题时，应填写计算机软件问题报告单，提交信息部主管或根据合同约定向设计单位提交。
四、实验要求：
每班分为5-6个小组，每组从实验题目中任选一题，也可自选题目作为课程实践题目。每组指定一名组长，负责分工和制定标准等管理工作。
1．项目开发过程建议采用原型式开发与增量开发相集合的模式，在基本明确需求的情况下建立系统原型供需求的讨论和确定。在需求讨论与总体解决方案设计过程中要特别关注软件在社会、安全、法律、文化等方面的影响因素。在需求和系统架构确定后，对具有代表性或系统核心部分的子系统进行详细的设计。开发方式要求采用面向对象方法。
2．实验内容包括进行需求分析、系统设计、系统实现与验证和文档交付。每个组员以某种角色参加这个系统开发过程的部分工作， 建立部分模型并书写部分实验报告。
3．实验报告要求包括需求规格说明书、设计规格说明书、源程序清单、测试报告。全组文档格式、内容参照附件中模板，提交一份完整的实验报告（提交打印和电子两种形式）。
五、实验题目：
2. 机票预定系统
为方便旅客，某航空公司拟开发一个机票预定系统。旅客可通过网络在该系统查询航班情况（按目的地、起飞时间、航班班次等）、注册个人信息、预订机票、查询订单等。也可通过旅行社进行预定，旅行社可以把预定机票的旅客信息（姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等）输入该系统，为旅客选择航班，并可打印取票通知和帐单，旅客在收到取票通知和帐单后可交费并于飞机起飞前24小时凭取票通知和交款单经系统校对无误后打印机票给旅客。旅客也可通过旅行社向系统提出退票要求，系统针对具体情况计算手续费后进行相应退票处理。具体功能细节可由学生根据调研情况自行确定。
课程实验报告要求：
以组为单位严格按附件中所给出的内容和格式要求书写实验报告。组长要做好开发计划，确定每个同学的任务，建议软件需求和设计方案要全组同学合作协商完成，分析设计模型可按模块分工完成，系统实现与测试按组内同学的开发能力合理分工。
详细要求见附件。
目 录
1 软件需求规格说明书………………………………………………（页码）
2 设计规格说明书……………………………………………………（页码）
3 源程序清单………… ……………………………………………（页码）
4 测试报告……………………………………………………………（页码）
5 实验总结……………………………………………………………（页码）
- 需求规格说明书
1．概述（Summary）
1.1项目的目的与目标（Purpose and Aim of Project）
此项目旨在开发一个“机票预订系统”，细化为四个子系统分别为“个人订票”、“旅行社订票”、“航班票务系统”、“会员系统”，各个子系统分别针对不同的使用对象，“个人订票”部分可实现注册、登录、查询信息、订票、取票、退票、支付等，“旅行社订票”部分可实现旅行社工作人员注册、登录、查询信息、订票、打印取票通知和账单、打印机票、退票等，“航班票务系统”可实现对于航班信息的增加删除修改、机票价格的改动、机票座位的调整、向用户发布通知等，“会员系统”可实现普通用户升级为会员、机票打折、优先抢票、升舱等。
1.2 术语定义（Terms Glossary）
| 序 号 | 术 语 名 称 | 术 语 定 义 |
| 1 | 注册 | 各方用户使用系统前需要真实信息来注册成为系统用户。 |
| 2 | 登录 | 各方用户在使用系统时，同时保证在已经注册的前提下，登录系统方可使用系统。 |
| 3 | 查询信息 | 用户可通过系统查询航班的信息。 |
| 4 | 订票 | 用户登陆系统后，在输入旅客信息后，获得可选航班，随后进行订票。 |
| 5 | 支付 | 订票之后，用户需要确定信息之后进行支付，方可完成机票的购买。 |
| 6 | 取票 | 在已经完成缴费后，自行订购的用户需要取票，随后在上飞机前使用。 |
| 7 | 退票 | 用户在多方原因之下，可以取消已经预定的航班，完成退票。 |
| 8 | 打印取票通知和账单 | 旅行社进行订票，将取票通知和账单发给用户，便于用户支付和之后的取票。 |
| 9 | 打印机票 | 通过旅行社订票时，旅行社需要打印好机票交由旅客。 |
| 10 | 向用户发布通知 | 由于其他因素影响到有关于旅客所选定的航班，将变更信息发通知给旅客。 |
| 11 | 系统 | 即若干部分相互联系、相互作用，形成的具有某些功能的整体。 |
| 12 | 子系统 | 即若干部分相互联系、相互作用，形成的具有某些功能的整体。 |
| 13 | 用例 | 是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。 |
| 14 | 角色 | 系统角色并不是指具体的外部实体和参与者，而是系统中相互交互的对象。 |
| 15 | 优先级 | 是计算机分时操作系统 在处理多个作业程序时，决定各个作业程序接受系统资源的优先等级的参数。 |
| 16 | 界面原型 | 是需求的一种呈现方式，是当下沟通需求的主要方式。 |
1.3 相关文档（Related Documents）
无
2．问题初始分析（Early Analysis）
2.1 用户需求描述（User Requirement Description）
采用自然语言对系统的功能及约束进行概要描述。
系统功能：
（1）乘客根据个人信息（比如：姓名、性别、工作单位、身份证号等）注册登入该系统
（2）乘客能够通过网络在该系统上查询航班信息（比如：目的地、起飞时间、航班班次）
（3）乘客和旅行社能够根据乘客的个人信息及对机票的要求在该系统预定机票。
（4）如果是乘客自己订票，则乘客应收到该系统发出的取票通知和账单，如果乘客按要求缴费则在飞机起飞24小时前系统校对取票通知和交款单后，打印机票给旅客。
（5）乘客可以通过该系统退票。如果乘客是自己购票，则自行登录系统进行退票，如果是通过旅行社订票，则由旅行社向系统提出退票要求。
（6）乘客可以升级成为会员，成为会员之后，乘客可以享有折扣价，在抢票时可以进行优先抢票，再一年之内有五次免费升舱的机会。
系统约束：
- 界面需求：定义产品如何与用户进行交互。用户交互界面要求简洁明了，要求成可能偶在短时间内熟悉系统，并能够进行简单的操作。
- 性能要求：系统响应时间应该在50ms以内，如果网络有所卡顿响应时间也应尽量保持在1-3秒；同时该系统应该在大量人一同访问时不发生卡顿，最好保持在一天能够处理150万条交易；在软件运行过程中要减少缺陷和避免暴露，把软件的门关起来，不让错误进来造成缺陷，也不让故障出去导致失效。
- 安全性需求：用户在登入该系统时需要对用户进行身份验证，比如使用身份证号或者其他的生物验证方法或者是账号密码等，并且确保用户的进行验证所需要的信息不被盗用，我们要对其进行加密，比如使用SSL对数据流进行加密；我们仅要求必须的授权访问，不过多要求乘客进行多余的访问权限；保持用户信息的安全性和完整性，用户信息不得泄露或遗漏；如果一旦面临风险，我们将使用我们创建的危险模型来抵御该风险。
- 操作性需求：在用户第一次是同该系统时应该进行用户指导；并且系统分为几个必要的模块，这样我们在进行系统维护时会省力许多。
- 政策和法律需求：我们需要严格遵守相关的法律法规，对各种政策有一个清楚的研读，绝不触碰法律和政策底线。所有使用的技术都要经过授权，所有的软件选择正版和免费。
2.2 初始功能提取（Early Function Distill）
用如表2-1所列，逐项叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出。
表2-1 功能需求点列表
| 编 号 | 功 能 名 称 | 使 用 人 | 功 能 描 述 | 输 入 内 容 | 输 出 内 容 |
| 1 | 升级会员 | 普通用户 | 能够将普通客户升级为会员 | 会员验证激活码 | 会员信息 |
| 2 | 设置会员折扣 | 会员系统管理员 | 能够在原定票价基础上设置折扣价格 | 会员折扣 | 会员折扣价 |
| 3 | 设置会员优先抢票时限 | 会员系统管理员 | 能够在面向普通客户开发购票前使会员用户优先购票 | 会员优先时间 | 会员优先剩余时间 |
| 4 | 设置会员免费升舱次数 | 会员系统管理员 | 能够使会员用户享有一定次数的免费升舱机会 | 会员免费升舱次数 | 会员系统管理员剩余次数 |
| 5 | 注册 | 旅客 | 在系统中注册用户 | 自己设定的用户名密码 | 新账号注册成功 |
| 6 | 登录 | 旅客 | 登录机票预订系统 | 所登账号的用户名密码 | 登录成功 |
| 7 | 查询 | 旅客 | 查询旅客所需航班情况 | 起落机场、预计出行日期 | 符合要求的航班信息 |
| 8 | 订票 | 旅客 | 预订所需航班 | 预订航班信息 | 预订成功 |
| 9 | 取票 | 旅客 | 取出实体机票 | 订单信息 | 机票 |
| 10 | 退票 | 旅客 | 取消所订航班并退款 | 订单信息 | 退票成功 |
| 11 | 支付 | 旅客 | 为所选航班付款 | 所选航班信息 | 生成对应订单 |
| 12 | 增加航班 | 系统后台工作人员 | 增加航班信息 | 航班号、起点、终点、始发机场、到达机场、起发时间、到达机场时间、头等舱价格、商务舱价格、经济舱价格 | 增加后的航班信息 |
| 13 | 删除航班 | 系统后台工作人员 | 删除航班信息 | 航班号、起点、终点、始发机场、到达机场、起发时间、到达机场时间 | 删除后的航班信息 |
| 14 | 航班信息改动 | 系统后台工作人员 | 改动航班信息 | 航班信息 | 改动后的航班信息 |
| 15 | 航班信息查看 | 系统后台工作人员 | 查看航班信息 | 航班信息 | |
| 16 | 价格改动 | 系统后台工作人员 | 改变航班价格 | 航班信息 | 价格修改过后的航班信息 |
| 17 | 座位数量改变 | 系统后台工作人员 | 改变座位数量 | 航班信息、座位信息 | 修改过后的航班信息、座位信息 |
| 18 | 发布通知 | 系统后台工作人员 | 在航班信息修改完成后发布修改信息 | 向用户发布通知 | |
| 19 | 注册 | 旅行社 | 注册账号 | 名称、密码、 手机号 | 登录界面 |
| 20 | 登录 | 旅行社 | 登录系统 | 名称、密码或者手机号、验证码 | 系统主界面 |
| 21 | 查询航班信息 | 旅行社 | 查询符合条件的航班信息 | 起始地、日期 | 查询结果显示界面 |
| 22 | 订票 | 旅行社 | 预订机票 | 预订航班信息 | 订单界面 |
| 23 | 打印取票通知和账单 | 旅行社 | 打印取票通知和账单 | 订单信息 | 订单界面 |
| 24 | 支付 | 旅行社 | 支付订单 | 订单信息 | 订单界面 |
| 25 | 打印取票通知和交款单 | 旅行社 | 打印取票通知和交款单 | 订单信息 | 订单界面 |
| 26 | 打印机票 | 旅行社 | 打印机票 | 取票通知和账单 | 订单界面 |
| 27 | 退票 | 旅行社 | 退票 | 订单信息 | 订单界面 |
| 28 | 取消预订 | 旅行社 | 取消订单 | 订单信息 | 订单界面 |
3．系统用例分析（System Use Case Analysis）
3.1 角色分析（Actor Analysis）
采用列表的方式说明系统的每一个角色，包括角色名称、所属部门并简要描述该角色需要应用系统完成的工作。
表2-2 角色列表
| 编 号 | 角色名 | 所属部门 | 简要描述 |
| 1 | 乘客 | 个人 | （1）乘客根据个人信息（比如：姓名、性别、工作单位、身份证号等）注册登入该系统 （2）乘客能够通过网络在该系统上查询航班信息（比如：目的地、起飞时间、航班班次） （3）乘客能够根据乘客的个人信息及对机票的要求在该系统预定机票。 （4）乘客收到该系统发出的取票通知和账单，如果系统检测到乘客按要求缴费则在飞机起飞24小时前系统校对取票通知和交款单后，打印机票给旅客。 （5）乘客如果自己购票，需要退票，则自行登录系统进行退票 （6）如果乘客升级成为会员，则乘客可以享有折扣价，在抢票时可以进行优先抢票，再一年之内有五次免费升舱的机会。 |
| 2 | 旅行社 | 集体订票部门 | （1）旅行社可以根据乘客提供的信息帮助乘客订票。 （2）旅行社能够通过该系统查询航班信息（比如：目的地、起飞时间、航班班次）。 （3）旅行社为乘客打印取票通知和账单。 （4）如果乘客需要退票，旅行社应该通过该系统进行退票。 |
| 3 | 后台维护人员 | 维护部门 | （1）定时定期对该系统进行维护，保证系统的正常运行。 （2）面对出现的风险，及时作出反应，尽可能不影响用户使用 |
3.2 用例分析（Actor Analysis）
采用列表的方式列出系统的每一个用例（基本用例，不包括精化后的扩展用例），包括用例名、角色、优先级、描述，如表2-3。
表2-3 用例列表
| 编号 | 用例名称 | 角色 | 优先级 | 描述 |
| 1 | 升级会员 | 普通用户 | 低 | 普通用户缴纳每年3万会员费或上一年消费达到200万享受免费升级为会员 |
| 2 | 会员折扣 | 会员 | 低 | 会员用户可享受九折票价 |
| 3 | 优先抢票 | 会员 | 高 | 会员用户可享受优先选票抢票 |
| 4 | 升舱 | 会员 | 高 | 会员用户每年有五次免费升舱机会 |
| 5 | 注册账户 | 旅客 | 低 | 在系统中注册用户 |
| 6 | 登录账户 | 旅客 | 低 | 登录机票预订系统 |
| 7 | 查询航班 | 旅客 | 中 | 查询旅客所需航班情况 |
| 8 | 订票 | 旅客 | 中 | 预订所需航班 |
| 9 | 取票 | 旅客 | 中 | 取出实体机票 |
| 10 | 退票 | 旅客 | 中 | 取消所订航班并退款 |
| 11 | 支付订单 | 旅客 | 高 | 为所选航班付款 |
| E1 | 增加航班 | 系统后台工作人员 | E | 这个用例使得系统后台工作人员增加航班信息 |
| E2 | 删除航班 | 系统后台工作人员 | E | 这个用例使得系统后台工作人员删除航班 |
| E3 | 航班信息改动 | 系统后台工作人员 | E | 这个用例使得系统后台工作人员改变航班信息 |
| H1 | 航班信息查看 | 系统后台工作人员 | H | 这个用例使得系统后台工作人员查看航班信息 |
| E4 | 价格改动 | 系统后台工作人员 | E | 这个用例使得系统后台工作人员改变机票价格 |
| E5 | 座位数量改变 | 系统后台工作人员 | E | 这个用例使得预订系统中某次航班的座位数量改变 |
| F1 | 发布通知 | 系统后台工作人员 | F | 这个用例使得用户和旅行社可以看到航班改动的信息 |
| 1 | 注册 | 旅行社 | 低 | 注册账号 |
| 2 | 登录 | 旅行社 | 低 | 登录系统 |
| 3 | 查询航班信息 | 旅行社 | 中 | 查询符合条件的航班信息 |
| 4 | 订票 | 旅行社 | 高 | 预订机票 |
| 5 | 打印取票通知和账单 | 旅行社 | 中 | 打印取票通知和账单 |
| 6 | 支付 | 旅行社 | 高 | 支付订单 |
| 7 | 打印取票通知和交款单 | 旅行社 | 中 | 打印取票通知和交款单 |
| 8 | 打印机票 | 旅行社 | 高 | 打印机票 |
| 9 | 退票 | 旅行社 | 高 | 退票 |
| 10 | 取消预订 | 旅行社 | 高 | 取消订单 |
注：1）注意此表要能够覆盖表2-1所列的全部功能点；
2）优先级分为高、中、低三等。
3.3 用例建模（Use Case Modeling）
以子系统（模块）为单位画出各部分用例图、用例表、部分活动图（对于事件流复杂的用例画活动图）和用户界面原型。
3.3.1 会员子系统（模块）用例模型
（1）用例图
- 用例表与活动图
| 描述 | 此用例表示会员用户购票 |
| 参与者 | 主要：Users（客户） 次要：System（系统） |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 用户已注册 |
| 触发事件 | 普通用户缴纳会员费或上一年消费达一定额度 |
| 主事件流 |
|
| 可选事件流 | 第2步中如果没有查找到心仪的班次可以重新查找，继续第2步，同时可在第四步中选择是否使用升舱特权 |
| 后置事件流 | 点击支付选项，进入支付界面。 |
| 非功能性需求 | 选票页面的交互性强，方便顾客使用，不能太过复杂。 |
（3）界面原型
图3-1 选票界面
图3-2 购票页面
3.3.2 个人订票子系统（模块）用例模型
（1）用例图
（2）用例表与活动图
（3）界面原型
3.3.3 航班票务系统子系统（模块）用例模型
（1）用例图
（画出精化后的用例图）
（3）用例表与活动图
用例表3.3.3-1
| 用例标识和名称 | E1：增加航班 |
| 描述 | 这个用例使得系统后台工作人员增加航班信息 |
| 参与者 | 主要：系统后台工作人员 次要：用户、旅行社 |
| 优先级 | 基本的（Essential） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息系统已打开 |
| 触发条件 | 有需要增加的航班 |
| 主时间流 | 1.工作人员根据航班信息查找航班 2.工作人员打开航班信息增加页面如图所示3-2 3.工作人员根据航班信息增加航班 |
| 可选事件流 | 第1步未如果已经查找到航班信息则不用执行第2、3步 |
| 后置条件 | 增加的航班信息信息被存入数据库，增加航班信息页面关闭。 |
用例表3.3.3-2
| 用例标识和名称 | E2：删除航班 |
| 描述 | 这个用例使得系统后台工作人员删除航班 |
| 参与者 | 主要：系统后台工作人员 次要：用户、旅行社 |
| 优先级 | 基本的（Essential） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息界面已打开 |
| 触发条件 | 有需要删除的航班信息 |
| 主时间流 | 1.工作人员输入航班信息查找航班 2.工作人员删除航班 |
| 可选事件流 | 第1步未如果已经查找到航班信息则不用执行第2步 |
| 后置条件 | 数据库中的航班信息被删除，返回航班信息界面 |
用例表3.3.3-3
| 用例标识和名称 | E3：航班信息改动 |
| 描述 | 这个用例使得系统后台工作人员改变航班信息 |
| 参与者 | 主要：系统后台工作人员 次要：用户、旅行社 |
| 优先级 | 基本的（Essential） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息界面已打开 |
| 触发条件 | 有航班的信息需要改变 |
| 主时间流 | 1.工作人员输入航班信息查找航班 2.根据需要改变航班信息 |
| 可选事件流 | 第1步未如果已经查找到航班信息则不用执行第2步 |
| 后置条件 | 航班信息被存入数据库 |
用例表3.3.3-4
| 用例标识和名称 | H1：航班信息查看 |
| 描述 | 这个用例使得系统后台工作人员查看航班信息 |
| 参与者 | 工作人员 |
| 优先级 | 基本的（High-value） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息页已打开 |
| 触发条件 | 有想要查看详细情况的航班 |
| 主时间流 | 1.工作人员输入航班信息查找航班 2.进入航班信息详情页面查看信息 |
| 可选事件流 | |
| 后置条件 | 退出查看详情页面 |
用例表3.3.3-5
| 用例标识和名称 | E4：价格改动 |
| 描述 | 这个用例使得系统后台工作人员改变机票价格 |
| 参与者 | 工作人员 |
| 优先级 | 基本的（Essential） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息页面已打开 |
| 触发条件 | 机票价格需要改变 |
| 主时间流 | 1.工作人员输入航班信息查找航班 2.根据需要改变机票价格 |
| 可选事件流 | 第1步未如果已经查找到航班信息则不执行第2步 |
| 后置条件 | 机票信息被存入数据库 |
用例表3.3.3-6
| 用例标识和名称 | E5：座位数量改变 |
| 描述 | 这个用例使得预订系统中某次航班的座位数量改变 |
| 参与者 | 工作人员 |
| 优先级 | 基本的（Essential） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息页面已打开 |
| 触发条件 | 座位数量需要改变 |
| 主时间流 | 1.工作人员输入航班信息查找航班 2.根据需要改变座位数量 |
| 可选事件流 | 第1步未如果已经查找到航班信息则不执行第2步 |
| 后置条件 | 座位信息被存入数据库 |
用例表3.3.3-7
| 用例标识和名称 | F1：发布通知 |
| 描述 | 这个用例使得用户和旅行社可以收到航班改动的通知 |
| 参与者 | 主要：系统后台工作人员 次要：用户、旅行社 |
| 优先级 | 基本的（Follow-on） |
| 非功能需求 | 安全性 |
| 前置条件 | 航班信息页面已打开 |
| 触发条件 | 航班信息有改动 |
| 主时间流 | 1.工作人员更改航班信息 2.发布改动通知 |
| 可选事件流 | |
| 后置条件 | 用户、旅行社已知晓航班信息改变 |
活动图如图所示：
（3）界面原型
图3-1
图3-2
3.3.4 旅行社订票子系统（模块）用例模型
（1）用例图
(2)用例表与活动图
| 表格要素 | 描述 |
| 用例标识和名称 | E1：注册 |
| 描述 | 此用例用于旅行社注册旅行社账号 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社进入系统登录界面 |
| 触发条件 | 旅行社点击“注册账号”，进入注册界面（图3-1） |
| 主事件流 |
|
| 可选事件流 | 若第二步再次输入的密码与第一次输入的密码不同，则返回第二步重新输入密码 |
| 后置条件 | 注册界面关闭，回到登录界面（图3-2） |
| 非功能性需求 | 页面简洁，便于注册 |
| 表格要素 | 描述 |
| 用例标识和名称 | E2：登录 |
| 描述 | 此用例用于旅行社登录旅行社账号 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已注册账号 |
| 触发条件 | 进入系统登录界面（图3-3） |
| 主事件流 |
|
| 可选事件流 | 第一步也可选择手机号登录，则第二步为输入手机号（图3-2） |
| 后置条件 | 进入系统主界面（图3-4） |
| 非功能性需求 | 页面简洁，便于登录 |
| 表格要素 | 描述 |
| 用例标识和名称 | E3：查询航班信息 |
| 描述 | 此用例用于旅行社查询航班信息 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社进入系统主界面（图3-4） |
| 触发条件 | 旅行社输入查询条件 |
| 主事件流 |
|
| 可选事件流 | 若第三步的查询结果是无航班，则返回第一步 |
| 后置条件 | 查询界面关闭，回到主界面 |
| 非功能性需求 | 页面简洁，显示航班起止时间、航班号以及所余座位数量，显示符合所有查询条件的航班后，再显示其余起始地符合的航班和可中转航班 |
| 表格要素 | 描述 |
| 用例标识和名称 | E4：订票 |
| 描述 | 此用例用于旅行社订票 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已查询航班信息 |
| 触发条件 | 选择合适的航班（图3-6） |
| 主事件流 |
|
| 可选事件流 | 若所选航班剩余座位不够，预订次航班的票后，继续选择其余航班，返回第一步 |
| 后置条件 | 进入订单界面 |
| 非功能性需求 | 页面简洁 |
| 表格要素 | 描述 |
| 用例标识和名称 | E5：打印取票通知和账单 |
| 描述 | 此用例用于旅行社打印取票通知和账单 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已预订航班 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若无未支付订单，则返回系统主界面 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁，便于显示订单 |
| 表格要素 | 描述 |
| 用例标识和名称 | E6：支付 |
| 描述 | 此用例用于旅行社支付订单 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已打印取票通知和账单 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若第二步支付前重新选择支付订单，则返回第一步 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁 |
| 表格要素 | 描述 |
| 用例标识和名称 | E8：打印取票通知和交款单 |
| 描述 | 此用例用于旅行社打印机票通知和取款单 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已支付订单 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若第一步无未打印取票通知和交款单的订单，则返回订单界面 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁 |
| 表格要素 | 描述 |
| 用例标识和名称 | E7：打印机票 |
| 描述 | 此用例用于旅行社打印机票通知和取款单 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已打印取票通知和交款单 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若第一步无未打印机票的订单，则返回订单界面 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁 |
| 表格要素 | 描述 |
| 用例标识和名称 | E9：退票 |
| 描述 | 此用例用于旅行社退票 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已支付机票 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若第一步无可退票订单，则返回系统主界面 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁 |
| 表格要素 | 描述 |
| 用例标识和名称 | E10：取消预订 |
| 描述 | 此用例用于旅行社退票 |
| 参与者 | 旅行社 |
| 优先级 | 基本的（Essential） |
| 风险 | 低风险 |
| 前置条件和假设 | 旅行社已预订机票 |
| 触发条件 | 进入订单界面 |
| 主事件流 |
|
| 可选事件流 | 若第一步无可取消的订单，则返回系统主界面 |
| 后置条件 | 返回系统主界面 |
| 非功能性需求 | 页面简洁 |
（3）界面原型
图3-1 图3-2
图3-3 图3-4
图3-5 图3-6
图3-7 图3-8
图3-9
3.4 数据建模（Data Modeling）
采用名词短语法结合CRC分析建立系统的分析类模型（域模型），要求按步骤画出关键抽象表、CRC卡和类图。
名词短语分析：
| 候选的关键对象 | 排除的原因 | 选定的名字 |
| 旅客 | Customer | |
| 航班情况 | Flight_information | |
| 目的地 | 航班情况子类 | |
| 起飞时间 | 航班情况子类 | |
| 航班班次 | 航班情况子类 | |
| 个人信息 | 旅客子类 | |
| 机票 | Ticket | |
| 订单 | 机票子类 | |
| 旅行社 | Travel_agency | |
| 旅客信息 | 旅行社子类 | |
| 姓名 | 旅客信息子类 | |
| 性别 | 旅客信息子类 | |
| 工作单位 | 旅客信息子类 | |
| 身份证号码 | 旅客信息子类 | |
| 旅行时间 | 旅客信息子类 | |
| 旅行目的地 | 旅客信息子类 | |
| 取票通知 | 旅行社子类 | |
| 账单 | 旅客子类 | |
| 手续费 | 旅客子类 |
用CRC卡记录关键抽象
| 旅客（Customer） | |
| 职责 | 协作者 |
| 旅客注册系统个人信息 登录系统 查询航班信息 退票以及收回扣除手续费的退回资金 支付账单 | 旅客（Customer） 旅行社（Travel_agency） 航班情况（Flight_information） |
| 航班情况（Flight_information） | |
| 职责 | 协作者 |
| 航班信息增删改 机票价格变动 座位变动 发布通知 | 旅客（Customer） 旅行社（Travel_agency） 航班情况（Flight_information） |
| 机票（Ticket） | |
| 职责 | 协作者 |
| 旅客或旅行社进行订票 旅客或者旅行社进行退票 旅客自行取机票 旅行社打印机票交由旅客 | 旅客（Customer） 旅行社（Travel_agency） |
| 旅行社（Travel_agency） | |
| 职责 | 协作者 |
| 旅行社工作人员注册系统 旅行社工作人员登录系统 旅行社向系统输入旅客信息查询航班 旅行社对旅客发送取票通知和账单 | 旅客（Customer） 旅行社（Travel_agency） 航班情况（Flight_information） |
域模型：
4．非功能需求（No-Functional Requirement）
4.1 系统性能目标（Performance of Target System）
时间要求（响应时间、更新处理时间、数据的转换和传送时间等方面的要求）和空间要求（支持的终端数、支持的并行操作的使用者数、处理的文件和记录数、处理任务的数量、对输入和输出数据的精度要求等
时间要求：该系统的响应时间应该保持在50ms以内，更新处理时间应该在2000ms以内，数据传送时间应该在1000ms以内，数据转换时间3000ms以内。
空间要求：支持的终端数10万个每秒，支持的并行操作的使用者数量10万个每秒，处理的文件和记录数15万每秒对输入输出的精度要求：要保持数据的准确性和完整性。
4.2 安全性（Security）
4.3 可靠性（Dependability）
4.4 灵活性（Agility）
4.5 特殊需求（Special Requirements）
（1）运行环境需求： APP客户端要求安卓系统的webview版本大于37。
后台管理系统运行在支持ECMAScript6的浏览器下。
服务器运行在node.js、MySQL8.0的环境。
APP客户端要求手机系统版本在Android 5.0及以上，支持GPS定位，可联网，至少拥有50MB的存储空间。
（2）培训需求：在用户第一次使用该系统时有操作步骤的介绍及指南。
（3）推广需求：通过抖音短视频、或者是请b站的up主进行推广，并且营销设计理念。
4.6 目标系统假设与约束条件（Suppose and Restriction of Target System）
（1）严格遵守法律和政策的相关要求
（2）在运行过程中如果出现版本不兼容问题，我们要进行改进并经过严格测试。
（3）在使用技术方面，我们尽可能使用免费正版的技术，支持正版。
（4）系统投入使用的最晚日期：2023年6月7日。
二、设计规格说明书
1．引言（Introduction）
本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。
1.1 目的（Purpose）
本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的概要设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。
1.2 命名规则（Naming Rule）
变量对象命名规则：申明全局变量、局部变量对象的命名规则。
数据库对象命名规则：申明数据库表名、字段名、索引名、视图名等对象的命名规则。
1.3 术语定义（Terms Glossary）
术语定义或解释一般用表格形式给出，如表3-1所示。
表3-1 术语定义或解释表
| 序 号 | 术 语 名 称 | 术 语 定 义 |
| 1 | 总体结构 | 软件系统的总体逻辑结构。按照不同的设计方法，有不同的总体逻辑结构。若采用面向功能或面向数据的设计方法，则总体逻辑结构为一树形的功能模块结构图。若采用面向对象或面向部件（构件）的设计方法，则总体逻辑结构为部件（构件）的组装图 |
| 2 | 外部接口 | 本软件系统与其他软件系统之间的接口，接口设施可以是中间件。接口描述包括：传输方式、带宽、数据结构、传输频率、传输量、传输协议 |
| 3 | 数据结构 | 数据结构包括：数据库表的结构、其他数据结构等 |
| 4 | 概念数据 模型CDM | 关系数据库的逻辑设计模型，叫做概念数据模型。主要内容包括一张逻辑E-R图及其相应的数据字典 |
| 5 | 物理数据 模型PDM | 关系数据库的物理设计模型，叫做物理数据模型。主要内容包括一张物理表关系图及其相应的数据字典 |
| 6 | 视图 | 在基表或其他视图之上建立的一张虚表，叫做视图，它具有物理表的许多性质，在数据处理和授权上很有用 |
| 7 | 角色 | 数据库中享有某些特权操作的用户，叫做角色。角色的权利通过授权来实现 |
| 8 | 子系统 | 具有相对独立功能的小系统叫做子系统。一个大的软件系统可以划分为多个子系统，每个子系统可由多个模块或多个部件组成 |
| 9 | 模块 | 具有功能独立、能被调用的信息单元叫做模块。模块是结构化设计中的概念 |
| 10 | 内部接口 | 软件系统内部各子系统之间、各部件之间、各模板之间的接口，叫做内部接口。接口描述包括：调用方式、入口信息、出口信息等 |
| 11 | 相关文件 | 相关文件是指当本文件内容变更后，可能引起变更的其他文件。如需求分析报告、详细设计说明书、测试计划、用户手册 |
| 12 | 参考资料 | 参考资料是指本文件书写时用到的其他资料。如各种有关规范、模板、标准、准则 |
1.4 参考资料（References）
[1] 用户需求报告
[2] 数据库设计规范
[3] 命名规范
1.5 相关文档（Related Documents）
[1] 源程序清单
[2] 测试计划及报告
2．总体设计（Design of Collective）
2.1 体系结构设计（Design of Architecture）
对软件体系结构方案的设计依据进行分析说明，要求至少分析两种以上的软件架构方案，分析不同方案对软件开发约束条件的支持程度，并进行方案的选择。
2.1.1 系统逻辑架构
采用包图画出系统的逻辑架构模型。
2.1.2 系统物理架构
采用部署图画出系统的物理架构模型。
2.2 子系统清单（Subsystem List）
子系统清单，如表3-2所示。
表3-2 子系统清单
| 子系统编号 | 子系统英文名 | 子系统功能简述 | 子系统之间的关系 |
| SS1 | |||
| SS2 | |||
| SS3 |
2.3 模块设计（Module Design）
2.3.1 用例实现
- 依据用例模型，设计实现各用例的模块及其关联，要求用鲁邦图和序列图表示；
（注意：设计模型要标明和哪个用例相对应）
2.3.2 实现类清单
表3-3 实体类清单
| 编 号 | 类名（英文名） | 功能简述 | 接口简述 |
| E-1 | |||
| E-2 | |||
| E-3 | |||
| ... |
| 编 号 | 类名（英文名） | 功能简述 | 接口简述 |
| C-1 | |||
| C-2 | |||
| C-3 | |||
| ... |
表3-5 边界类清单
| 编 号 | 类名（英文名） | 功能简述 | 接口简述 |
| B-1 | |||
| B-2 | |||
| B-3 | |||
| ... |
2.3.2 关键程序逻辑设计
详细描述关键类的关键操作的程序逻辑，要求采用流程图描述。
（注意：选择3-5个程序模块即可，设计的程序逻辑后面测试部分要进行模块测试）
3．数据结构设计（Design of Data Structure）
3.1 数据库表名清单（DB Table List）
数据库表名清单，如表3-4所示。
表3-4 数据库表名清单
| 序号 | 中文表名 | 英文表名 | 表功能说明 |
| 1 | 航班信息 | flight | 包括一系列航班的信息 |
| 2 | 旅客信息 | customer | 包括了旅客的所有信息 |
| 3 |
3.2 数据库表之间关系说明（Relation of DB Table）
用E-R图表示。
3.3 数据库表的详细清单（Particular List of DB Table）
每个表的详细清单内容包括：表名、字段中文名、字段英文名、字段的类型、宽度、精度、主键/外键、空否、取值约束（默认值、最大值、最小值）、索引否。同时要指出该表的索引：索引文件名、索引字段名、索引特性（主键索引、惟一索引unique、聚集索引clustered）。详细清单可以用列表给出，如表3-5所示。
表名：航班信息
| 序号 | 字段中文名 | 字段英文名 | 类型、宽度、精度 | 取值约束 | 空否 | 默认值 | 主键/外键 | 索引否 |
| 1 | 航班号 | flight_num | Char[10] | 否 | 主键 | |||
| 2 | 起飞时间 | start_time | Char[10] | 否 | ||||
| 3 | 抵达时间 | end_time | Char[10] | 否 | ||||
| 4 | 起飞城市 | start_place | Char[20] | 否 | ||||
| 5 | 抵达城市 | end_place | Char[20] | 否 | ||||
| 6 | 空座数 | left | Int | 否 | ||||
| 7 | 票价 | price | Int | 否 | ||||
| 8 | 票价折扣 | price_discount | Float | 否 | ||||
| 9 | 航班是否满仓 | Full | int | 否 |
表名：旅客信息
| 序号 | 字段中文名 | 字段英文名 | 类型、宽度、精度 | 取值约束 | 空否 | 默认值 | 主键/外键 | 索引否 |
| 1 | 身份证号 | Id | Char[20] | 否 | 主键 | |||
| 2 | 航班号 | flight_num | Char[10] | 否 | 外键 | |||
| 3 | 姓名 | name | Char[10] | 否 | ||||
| 4 | 性别 | gender | Char[10] | 否 | ||||
| 5 | 目的地 | end_city | Char[20] | 否 | ||||
| 6 | 工作单位 | work_place | Char[20] | 否 |
三、源程序清单
（注意：选择关键模块代码，不超过5页！）
1 #####（Module Name）
1.1 描述（Description）
（简要描述该模块（类）的主要功能、处理的数据、产生的结果）
1.2 代码(Program)
2 #####（Module Name）
2.1 描述（Description）
2.2 代码(Program)
.
.
.
四、测试报告
1. 概述(Summary)
1.1 项目简介(Project Synopsis)
在本章节中简介项目的基本情况。
1.2 术语定义(Terms Glossary)
将该测试报告中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.3 参考资料(References)
说明该测试报告使用的参考资料，如：
[1] 《需求规格说明书》
[2] 《设计规格说明书》
2. 组件测试(Module Test)
选择《设计规格说明书》中经过程序逻辑设计的模块，应用基本路径法设计测试用例，进行测试。要求按照程序的程序流程图，标识每条基本路径，记录测试数据，评定测试结果。测试活动的记录格式，如表5-2所示。
表5-2 模块***测试记录
| 编号 | 路径标识 | 输入 | 期望输出 | 输出内容 | 发现问题 | 测试结果 | 测试时间 | 测试人 |
| 1 | √ | |||||||
| 2 | √ | |||||||
| 3 | √ | |||||||
| 4 | × |
3．功能测试(Function Test)
3.1 系统功能需求（Function Request of Target System）
由《需求规格说明书》拷贝到的功能需求点列表，如表5-3所示。
| 编 号 | 功 能 名 称 | 使 用 人 | 功 能 描 述 | 输 入 内 容 | 输 出 内 容 |
| 1 | |||||
| 2 | |||||
| 3 | |||||
| ... |
3.2. 功能测试报告(Report for Function Test)
按照功能点列表内容，结合等价类划分法设计测试用例（输入/输出内容），进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式，如表5-4所示。
表5-4 功能测试记录
| 编号 | 功能名称 | 输入内容 | 期望输出 | 输出内容 | 发现问题 | 测试结果 | 测试时间 | 测试人 |
| 1 | √ | |||||||
| 2 | √ | |||||||
| 3 | √ | |||||||
| 4 | × |
4. 测试结论(Test Verdict)
当测试完成之后，测试人员应对本次测试做出结论。格式如下：
测试日期：
测试地点：
测试环境：
列出系统的强项：
列出系统的弱项：
列出不符合项的统计结果：
测试人员签字：