航空售票系统Word下载.docx

航空售票系统Word下载.docx

《航空售票系统Word下载.docx》由会员分享，可在线阅读，更多相关《航空售票系统Word下载.docx（22页珍藏版）》请在冰豆网上搜索。

查询航线等信息：

根据旅客提出的终点站名输出下列信息：

航班号、飞机号、星期几飞行，最近一天航班的日期和余票额；

承办订票业务：

根据客户提出的要求（航班号、订票数额）查询该航班票额情况，若尚有余票，则为客户办理订票手续；

退票业务：

根据客户提供的情况（日期、航班），为客户办理退票手续，然后查询该航班是否有人排队候补，首先询问排在第一的客户，若所退票额能满足他的要求，则为他办理订票手续，否则依次询问其他排队候补的客户。

旅行社把预订机票的旅客信息（姓名、工作单位、身份证号码、旅行时间、旅行目的地等）输入该系统，系统为旅客安排航班，印出取票通知和账单。

旅客在飞机起飞的前一天凭取票通知和账单到旅行社交款取票，系统校对无误即出机票给旅客。

2.2需求分析

2.2.1功能需求

1.查询功能：

旅客预订机票前可以进行机票的查询，查询机票的具体信息以为机票预定做好准备。

2.预定功能：

旅客可以到旅行社进行预订，旅行社将旅客的信息输入并打印通知单和账单，以便用户取票时用到。

3.取消预定：

旅客可以向机场售票人员取消预定，售票人员将扣除后剩余的金额打回到用户的visa卡上。

4.取票：

旅客向机场售票人要求取票，机场售票人员凭旅客的取票通知和账单为旅客打印机票。

5.退票：

旅客向机场售票人要求退票，机场售票人员登录系统为旅客退票，扣除费用后返回给旅客相应的费用。

2.2.2性能需求

新系统应该尽可能地解决现有系统存在的问题。

例如：

减少手工操作和重复劳动，提高计算机管理程度，尽可能的杜绝信息遗漏现象，方便查询、统计，方便数据的管理和备份等等。

鉴于管理工作的要求，从硬件及软件上都要考虑到有良好的数据量处理能力。

系统应具备较好的可维护性，较长的生存期，避免较短的时间内被推倒重来的情况发生。

在系统设计实现过程中应该使用标准规范的符号语言，这样才能保证大量数据的存储不发生冗余过大的情况。

其次应用系统界面设计应该良好的人机交互，在开发中应重视良好人机交互性能的设计，包括更好的引导性界面，更简单的操作方法，更易学、快捷的汉字信息录入等，尽力减少用户文字信息的键盘输入。

本系统客户端拟采用分布-集中式结构及windowsxp现在市场上常用版本均可，服务器端采用WindowsNT或Windows2000操作系统，前端开发语言使用c++,使用MicrosoftSQLServer数据库管理系统。

由于现在c++技术比较成熟，系统的开发不会存在困难。

2.3系统需求建模

在进行用例建模之前，我们首先了解到用例模型描述的是外部执行者（Actor）所理解的系统功能。

它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。

它的重要作用有以下几个方面：

首先，它描述了航空售票系统的功能需求；

其次，它将系统看作黑盒，从外部执行者的角度来理解系统；

再次，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。

2.3.1确定参与者

首先，经过调查得到用户对航空售票系统的需求为：

收取顾客机票定金。

机场管理员调整票价，

查询航线：

退票业务：

进一步分析可以识别出本系统的角色：

售票员、旅客、旅行社、银行。

2.3.2确定用例

在对现行航空售票系统的分析过程中，在我们获取了执行者之后，我们就对每个执行者提出以下问题以获取用例：

1.执行者要求系统提供哪些功能（执行者需要做什么）。

2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。

3.必须提醒执行者的系统事件有哪些，或者执行者必须提醒系统的事件有哪些，怎样把这些事件表示成用例中的功能。

可以通过分析初步识别出系统的用例为：

取票、预订、取消预订、查询航班、收费等。

外部执行者系统用例用例关系

2.3.3系统用例建模

针对企业人事管理系统的流程的分析，我们采用的是面向对象的分析方法（OOA）。

使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图，在此模型中列出了系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。

系统的用例图如图2.1所示。

图2.1系统的用例图

2.3.4用例描述

1.查询

概述：

该用例说明顾客在打算旅行或出差时对机票和航线信息进行查询

前置条件：

旅客进行网上业务登陆航空系统主页

后置条件：

航空公司或者旅行社的航班安排

实现过程：

1.旅客点击主界面上的查询按钮，进入查询界面

2.旅客输入目的地、起飞时间、航班号为可选项

3.旅客点击查询按钮，系统开始查询并将符合条件的信息一一列在屏幕上

4.旅客关闭查询界面，返回主界面

2.预定

该用例说明顾客在查询后进行机票预订的行为

已在系统中进行航线、航班或机票查询

预订后顾客应进行取票或当不要票时必须取消预订

1.机场售票人员和旅行社等待旅客订票系统处于主界面

2.旅客来订票说明自己想要的航班信息

3.工作人员进入查询界面，输入航班信息，点击查询

4.系统显示符合条件的航班

5.询问旅客想要的航班，点击新建订单

6.旅客说明自己的个人信息（包括信用卡号等），想订的票数

7.工作人员填写订单，无误点击确定

8.弹出交付成功对话框，点击打印，系统打印帐单和取票通知单

9.返回系统

3.取票

该用例说明顾客在订票后到指定地点领取机票的行为

已进行机票预订

取票后售票员应进行收费，银行则进行结算

1.旅客到来要求取票

2.售票人员点击主界面上的取票按钮进入取票界面

3.售票人员向旅客索要取票通知和账单

4.售票人员在账单号栏里填入旅客提供的账单号，点击确认

5.系统搜索订单并在屏幕上显示此账单的信息并核对时间是否在24小时内

6.售票人员与账单约人无误后点击打印机票按钮，系统开始打印机票

4.取消预定

该用例说明顾客在订票后到指定地点取消预订机票的行为

取消预订后售票员必须修改机票信息和退还旅客预定金

1.旅客打来电话要求取消预定

2.售票人员点击主界面上取消预定按钮，进入取消预定界面

3.售票人员索要旅客信息，包括（旅客姓名，订单号，旅行目的地）

4.售票人员输入订单号，点击确定，系统自动搜索并将旅客的账单信息显示在屏幕上

5.售票人员点击确认取消，系统显示应退还旅客的金额

6.售票人员点击确认，将退款存入旅客信用卡里

7.售票人员关闭取消预定窗口返回主界面

5.退票

该用例说明顾客在订票后需要进行退票到指定退还机票的行为

已领取机票

退票后售票员必须修改机票信息和退还旅客预定金

1.机场售票人员看着主屏幕等待旅客到来

2.旅客带来机票要求退票

3.机场售票人员向旅客所要机票

4.机场售票人员点击退票按钮，进入退票窗口

5.机场售票人员输入机票号码点击确认

6.系统将相应机票状态改为待售并计算应返还旅客费用

6.收费

该用例说明旅行社在顾客订票后需要收取定金，且售票员在用户取票时应收取机票费用

已订票或领取机票

收费后售票员必须修改机票信息和记录管理顾客信息

2.旅客到来要求取票或订票

3.机场售票人员打印机票并交给旅客

4.机场售票人员核算机票费用并告知用户

5.机场售票人员要求顾客给票价

6.系统将相应机票状态改为已售并记录登记用户信息

7.银行结算

该用例说明银行根据在顾客订票后信息登记情况统计后进行核算

3.航空售票系统系统分析

3.1系统用例建模

由于此系统是一个独立的小系统所以整个系统的用例建模和前面的需求分析用例建模相同，则系统用例图如图3.1所示。

图3.1航空售票系统用例图

3.2静态结构模型

3.2.1类的识别

我们对以上需求进行初步处理之后，经过非正式分、析得出系统的的初始类为：

旅行社、机票、旅客、航班号、账单、机场管理员、售票员、定金、客户订单、飞机、取票通知、系统、航线、终点、信息、余票额、订票数额、业务、日期、候补客户、工作单位、机票数额、目的地等。

对候选类进行严格的考察筛选，去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。

把与问题密切相关的类与对象放到目标系统中，飞机、系统、终点、工作单位、目的地与本系统要实现功能关系不大。

因此，应该去掉候选类飞机、系统、终点、工作单位、目的地。

删除不正确的或不必要的类与对象，根据冗余标准，余票额、订票数额分别描述了相同的几类信息，应保留在此问题域中最富于描述力的名称，因此，保留机票数额类就行。

还有的名词表示的是类的属性和操作，如航班号、日期等应删去。

综上所述，在航空售票系统中，经过初步筛选，剩下下列类与对象：

机场售票员、机场管理员、旅客、机票、账单、通知单、定金、旅行社、客户订单。

3.2.2类的关联分析

在上文中我们将待开发的住院管理系统的对象和类识别了出来，随后，我们通过提取动词词组初步得出它们之间的关联，通过分析前文中的需求陈述，我们找出了陈述中隐含的关联，经过分析之后（如删除已删去类之间的关联：

旅客凭取票通知和账单到旅行社交款取票、瞬时关联：

售票员打印机票）确定出下列关联：

机场售票员可以进行客户订单的管理（查询修改、删除等）。

机场管理员可以修改机票价格。

旅行社收取旅客订金。

旅行社可以对客户信息进行管理。

旅行社识别顾客订单。

旅行社打印通知单。

机场管理员和旅行社安排航班，制定航班计划。

列出所有的主动类之后发现所有的对象类都是多对多的关系。

3.2.3类的属性描述

属性是对象的性质，通过对象类和结构有更深入，更具体的认识。

一般来说确定属性的过程包括分析和选择两个步骤。

属性的确定既与问题有关，也和目标系统的任务有关。

应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。

在分析过程中应该首先找出最重要的属性，以后在逐渐把其余属性添加进去。

此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。

只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。

部分对象类的属性描述如下：

机场售票员：

工作号、姓名、职务

旅客：

姓名、身份证号、信用卡号、工作单位

旅行社：

名称、地点、业务

客户订单：

客户号、客户名、机票号、信用卡号

账单：

票价、手续费、票号、日期

通知单：

票价、打印时间、过期时间、票号

3.2.4类图的构建

类图元素基本符号如下。

类关联关系

图3.2航空售票系统类图

3.3系统动态模型

3.3.1系统执行顺序分析

为了实现一个合适的系统，第一步应对医院目前情况进行调研分析，掌握现有的工作模式和工作流程。

用UML进行系统建模时用顺序图表示。

在顺序图中，一条竖线代表一个对象，每个时间用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象，时间从上向下递增，箭头线在垂直方向上的相对位置表示事件发生的先后。

可以绘制出如下图所示的航空售票管理系统的顺序图（图3.3查询顺序图、图3.4取票顺序图、图3.5预定顺序图、图3.6取消预定顺序图、图3.7退票顺序图）。

图3.3查询顺序图

图3.4取票顺序图

图3.5预定顺序图

图3.6取消预定顺序图

图3.7退票顺序图

3.3.2系统的协作分析

UML进行系统建模时用协作图（也称为合作图）进行系统协作分析，用于描述相互合作的对象间的交互关系和链接关系。

与顺序图一样，合作图也展示了对象间的动态协作关系。

它除了说明信息的交换外，还显示对象间的连接关系，描述信息在连接的对象之间的传递。

根据对航空售票系统的业务流程进行分析得出的顺序图，可以得出该系统的协作图如下（图3.8查询协作图图、3.9取票协作图图、3.10取消预定协作图图、3.11预定协作图图、3.12退票协作图）。

图3.8查询协作图

图3.9取票协作图

图3.10取消预定协作图

图3.11预定协作图

图3.12退票协作图

3.3.3系统状态分析

UML中用状态图描述了事件和对象状态的关系，做系统状态分析。

根据前面的顺序图和交互行为可以得出系统状态图如下（图3.13系统查询状态图、图3.14系统订票状态图）。

图3.13系统查询状态图

图3.14系统订票状态图

3.3.4系统活动分析

活动图是由状态图转化而来的，它描述了系统中各种活动执行的顺序，刻画了一个系统中所要进行的各项活动的执行流程。

根据上文中绘制得出的顺序图以及合作图，对两图中相互交互的对象进行分析可以得出系统主要的活动图如下（图3.15系统取票活动图、图3.16系统退票活动图）。

图3.15系统取票活动图

图3.16系统退票活动图

4.航空售票系统系统设计与实现

4.1UML体系结构设计

航空售票系统采用面向对象技术对系统进行总体的设计和实现，用UML及其集成环境RationalRose对系统进行分析和建模，采用PowerBuilder’s完成组件平台建设，后端数据存储是当前流行的SQLSEVER数据库。

本系统基于PowerBuilder’s构建三层C/S结构，数据库服务器运行数据库管理系统软件，COM+组件运行在应用服务器上，客户机运行售票系统客户端软件。

4.1.1硬件体系结构设计

本系统采用C/S结构开发，三层C/S结构是在客户和服务器之间引入应用层的概念，即在客户端与数据库之间加入了一个“中间层”。

它将应用逻辑移到应用层完成，而客户端弱化为一个图形用户接口，成为一个瘦客户机。

其解决方案是:

对这三层进行明确分割，并在逻辑上使其独立形成三层软件结构。

在这种结构中，表示层、业务逻辑层和数据访问层在逻辑上是彼此分离的，表示层向用户提供数据，并有选择地允许用户使用逻辑数据。

对于基于PC的应用程序来说，本机用户和基于Web的用户接口是其两个主要的用户接口。

本机用户接口使用底层操作系统服务，基于Web的用户以HTML为基础，可通过任何平台的浏览器来阅读。

本系统的三层C/S结构如图4.1所示。

图4.1三层硬件体系结构图

4.1.2软件体系结构设计

信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架，一般呈现多层次结构模式。

子系统是对软件进行分解的一种中间形式，也是组织和描述软件的一种方法。

软件结构设计就是把软件分解成多个子系统，并确定各子系统及其接口之间的相互关系。

航空售票系统的软件结构如图4.2所示。

图4.2软件体系结构图

4.2对象模型设计

根据前文的分析得到的主动对象类有：

对象类的属性描述如下：

对象类的服务描述如下：

取票、退票、打印机票、核对、取消预订、返回旅客金额

查询、付款、核对账单信息、取票、退票

预订、打印通知单、打印账单、收费、退还旅客订金

机场管理员：

调整价格、提示确定、维护系统

由以上的分析过程，建立的对象模型如图4.3所示。

图4.3对象模型图

4.3系统实现

本章使用UML建模技术，对航空售票系统进行了建模设计，使的开发出的产品在面对不同的客户时方便修改和维护，大大减少了投入的人力和时间，同时大大缩小了产品的成本。

在UML中，描述实现的视图称为组件视图。

它对模型中的组件建模，描述应用程序搭建的软件单元以及组件之间的依赖，从而可以估计更改的影响。

它还对类及其他元素在组件中的分配建模。

布局视图包括组件图、配件图以及配置图，他们分别从不同的角度反映并显示了本系统的软件和硬件的物理配置。

4.3.1组件分析

组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，它实际上是一个文件，可以有源代码构件、二进制构件、可执行构件。

构件对外提供的可见操作和属性称为构件的界面。

在UML中，组件图描述了组件及组件之间的关系，表示了组件之间的组织和依赖关系。

组件图是用来为面向对象系统的物理方面建模的图形之一。

经过分析，航空售票系统的组件图如图4.4所示。

图4.4系统组件图

4.3.2配置分析

UML建模时用配置图来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。

可以显示计算机结点的拓扑结构和通信路径，结点上执行的软构件，软构件包含的逻辑单元等，特别对于分布式系统，配置图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种软构件和对象的配置。

配置图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，航空售票系统的配置图如图4.5所示。

在本系统中，用PC机作为客端，中间服务器为数据库服务器，售票员为旅客打印机票需要连接专用打印机。

图4.5系统配置图

5.课程设计心得体会

开始学习软甲工程相关知识由于对软件工程的了解不够深入，感觉蛮难的，所以收获不是很大，很多的概念都比较模糊，等到开始做详细的课程设计时，真是茫然无从下手，自从拿到设计主题后，我就像热锅上的蚂蚁，一个字“急”。

最后实在没有办法，逼着自己去学习，查资料，总算对软件工程有了浅层理解。

通过本次实验，我感觉收获还是蛮多的。

可能我对于软件工程的知识学习的还是不太多，但是这之外的东西收获颇丰。

它让我学会了如何通过自己的努力去认知一个新事物，更重要的是端正自己的学习态度，只有真正下功夫去学习，才能有收获，正所谓“一份耕耘，一份收获。

”没有付出，何谈回报呢？

再者，通过本次实验，我也学会了如何去分析问题，如何找出自己设计中的不足，继而去排除解决问题，这就是一个自我学习的过程。

当我们通过实验去学习理论知识时，自己动手得出的结论，不仅能加深我们对软件工程的理解，更能加深我们对此的记忆。

最后得感谢老师悉心的教导，和严厉的批评指正，让我收获更多的知识。

参考文献

[1]王欣.管理信息系统.北京.中国水利水电出版社.2004

[2]张海藩.软件工程.北京.清华大学出版社.2009

[3]刘天时.软件案例分析.北京.清华大学出版社.2008

[4]刘鲁.信息系统：

原理、方法与应用.北京.高等教育出版社.2007

[5]郑人杰,陶永雷《使用软件工程》,清华大学出版社,1997

[6]谭云杰等编著.《大象--ThinkinginUML》.中国水利水电出版社，2009

[7]吴洁明，袁山龙编著．软件工程应用实践教程．北京：

清华大学出版社，2003