软件工程实验报告（机票预订系统）

《软件工程实验》实验指导书

一、课程目标：

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.3 相关文档（Related Documents）

无

2．问题初始分析（Early Analysis）

2.1 用户需求描述（User Requirement Description）

采用 自然语言 对系统的功能及约束进行概要描述。

系统功能：

（1）乘客根据个人信息（比如：姓名、性别、工作单位、身份证号等）注册登入该系统

（2）乘客能够通过网络在该系统上查询航班信息（比如：目的地、起飞时间、航班班次）

（3）乘客和旅行社能够根据乘客的个人信息及对机票的要求在该系统预定机票。

（4）如果是乘客自己订票，则乘客应收到该系统发出的取票通知和账单，如果乘客按要求缴费则在飞机起飞24小时前系统校对取票通知和交款单后，打印机票给旅客。

（5）乘客可以通过该系统退票。如果乘客是自己购票，则自行登录系统进行退票，如果是通过旅行社订票，则由旅行社向系统提出退票要求。

（6）乘客可以升级成为会员，成为会员之后，乘客可以享有折扣价，在抢票时可以进行优先抢票，再一年之内有五次免费升舱的机会。

系统约束：

1. 界面需求：定义产品如何与用户进行交互。用户交互界面要求简洁明了，要求成可能偶在短时间内熟悉系统，并能够进行简单的操作。
2. 性能要求：系统响应时间应该在50ms以内，如果网络有所卡顿响应时间也应尽量保持在1-3秒；同时该系统应该在大量人一同访问时不发生卡顿，最好保持在一天能够处理150万条交易；在软件运行过程中要减少缺陷和避免暴露，把软件的门关起来，不让错误进来造成缺陷，也不让故障出去导致失效。
3. 安全性需求：用户在登入该系统时需要对用户进行身份验证，比如使用身份证号或者其他的生物验证方法或者是账号密码等，并且确保用户的进行验证所需要的信息不被盗用，我们要对其进行加密，比如使用SSL对数据流进行加密；我们仅要求必须的授权访问，不过多要求乘客进行多余的访问权限；保持用户信息的安全性和完整性，用户信息不得泄露或遗漏；如果一旦面临风险，我们将使用我们创建的危险模型来抵御该风险。
4. 操作性需求：在用户第一次是同该系统时应该进行用户指导；并且系统分为几个必要的模块，这样我们在进行系统维护时会省力许多。
5. 政策和法律需求：我们需要严格遵守相关的法律法规，对各种政策有一个清楚的研读，绝不触碰法律和政策底线。所有使用的技术都要经过授权，所有的软件选择正版和免费。

2.2 初始功能提取（Early Function Distill）

用如表2-1所列，逐项叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出。

表2-1  功能需求点列表

3．系统用例分析（System Use Case Analysis）

3.1 角色分析（Actor Analysis）

采用列表的方式说明系统的每一个角色，包括角色名称、所属部门并简要描述该角色需要应用系统完成的工作。

表2-2  角色列表

3.2 用例分析（Actor Analysis）

采用列表的方式列出系统的每一个用例（基本用例，不包括精化后的扩展用例），包括用例名、角色、优先级、描述，如表2-3。

表2-3 用例列表

注：1）注意此表要能够覆盖表2-1所列的全部功能点；

2

）优先级分为高、中、低三等。

3.3 用例建模（Use Case Modeling）

以子系统（模块）为单位画出各部分用例图、用例表、部分活动图（对于事件流复杂的用例画活动图）和用户界面原型。

3.3.1 会员子系统（模块）用例模型

（1）用例图

1. 用例表与活动图

（3）界面原型

图3-1 选票界面

图3-2 购票页面

3.3.2 个人订票子系统（模块）用例模型

（1）用例图

（2）用例表与活动图

（3）界面原型

3.3.3 航班票务系统子系统（模块）用例模型

（1）用例图

（画出精化后的用例图）

（3）用例表与活动图

用例表3.3.3-1

用例表3.3.3-2

用例表3.3.3-3

用例表3.3.3-4

用例表3.3.3-5

用例表3.3.3-6

用例表3.3.3-7

活动图如图所示：

（3）界面原型

图3-1

图3-2

3.3.4 旅行社订票子系统（模块）用例模型

（1）用例图

(2) 用例表与活动图

（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卡和类图。

名词短语分析：

用CRC卡记录关键抽象

域模型：

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.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  子系统清单

2.3 模块设计（Module Design）

2.3.1 用例实现

1. 依据用例模型，设计实现各用例的模块及其关联，要求用 鲁邦图 和 序列图 表示；

（注意：设计模型要标明和哪个用例相对应）

2.3.2 实现类清单

表3-3  实体类清单

表3-4  控制类清单

表3-5  边界类清单

2.3.2 关键程序逻辑设计

详细描述关键类的关键操作的程序逻辑，要求采用流程图描述。

（注意：选择3-5个程序模块即可，设计的程序逻辑后面测试部分要进行模块测试）

3．数据结构设计（Design of Data Structure）

3.1 数据库表名清单（DB Table List）

数据库表名清单，如表3-4所示。

表3-4  数据库表名清单

3.2 数据库表之间关系说明（Relation of DB Table）

用E-R图表示。

3.3 数据库表的详细清单（Particular List of DB Table）

每个表的详细清单内容包括：表名、字段中文名、字段英文名、字段的类型、宽度、精度、主键/外键、空否、取值约束（默认值、最大值、最小值）、索引否。同时要指出该表的索引：索引文件名、索引字段名、索引特性（主键索引、惟一索引unique、聚集索引clustered）。详细清单可以用列表给出，如表3-5所示。

表名：航班信息

表名：旅客信息

三、源程序清单

（注意：选择关键模块代码，不超过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  模块***测试记录

3．功能测试(Function Test)

3.1 系统功能需求（Function Request of Target System）

由《需求规格说明书》拷贝到的功能需求点列表，如表5-3所示。

表5-3  功能需求点列表

3.2. 功能测试报告(Report for Function Test)

按照功能点列表内容，结合等价类划分法设计测试用例（输入/输出内容），进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式，如表5-4所示。

表5-4  功能测试记录

4. 测试结论(Test Verdict)

当测试完成之后，测试人员应对本次测试做出结论。格式如下：

测试日期：

测试地点：

测试环境：

列出系统的强项：

列出系统的弱项：

列出不符合项的统计结果：

测试人员签字：

68747470733a2f2f62:6c6f672e6373646e2e6e65742f6d305f35343334383832332f:61727469636c652f64657461696c732f313332393137353637