案例-旅游业务申请系统用例图和用例文档

UML建模之旅：“旅游业务申请”系统分析与设计建模案例使用说明书编写单位：北京航空航天大学软件学院编写人：谭火彬，林广艳编写时间：2018年10月目录1.案例说明 (3)2.案例教学目标 (3)3.案例准备 (3)4.案例教学要点 (3)4.1需求建模 (3)4.1.1识别参与者 (4)4.1.2识别用例 (4)4.1.3构造用例图 (5)4.1.4编写用例文档 (6)4.1.5重构用例模型 (9)4.2系统分析 (10)4.2.1架构分析 (11)4.2.2识别分析类 (11)4.2.3构造用例实现 (12)4.2.4构造分析类图 (15)4.3系统设计 (16)4.3.1架构设计 (16)4.3.2构件设计 (17)5.案例教学组织方式 (19)6.案例小结 (20)1.案例说明本案例完整地展示如何利用UML开展系统分析和设计。

借助于UML所提供的各种模型，可以有效地处理系统分析和设计中的各类问题。

目前，该案例主要用于“面向对象分析与设计”课程教学，贯穿课程教学的各个阶段。

该案例可以用于课程教学阶段，也可用于学生实践。

该案例总共包括3个组成部分，分别是需求建模、系统分析和系统设计；这三部分是软件系统编码前的三个核心过程，也是软件工程专业学生必备的专业技能。

本案例通过利用UML完成三部分的工作，通过带领学生完成UML建模之旅，从而向学生全面展示了如何利用UML建模技术来构建系统的需求、分析和设计模型。

教师可根据理论授课的进度，逐步完成案例教学内容。

2.案例教学目标本案例适用于软件工程专业的高年级本科生和研究生，其的目标是就是针对前面提出的三个方面的问题，引入UML建模技术，引导学生通过UML建模完成需求定义、需求分析和系统设计这三个软件系统开发。

具体的教学内容包括以下三个方面的建模工作：（1）基于UML用例模型的需求定义方法。

通过利用UML用例图、用例文档等技术，引导学生构建目标系统的需求模型，以完成需求定义工作。

第一章需求分析和总体设计系统需求分析1 总体需求概述根据旅游信息管理的需求，对景点、住宿、交通、旅游常见问题等旅游相关信息的进行管理。

主要包括景点信息的管理、住宿信息管理、交通信息管理以及旅游服务信息管理等几个方面的内容。

这几方面内容中包括信息的录入和查询，以及信息的实时更新。

管理员针对信息的变更，对相关信息进行管理，保证信息的最新性和准确性，易于日常的操作和维护。

2 需求的具体分析根据总体功能需求特将具体功能需求描述如下：（1）旅游信息、公交信息的功能需求：当查询到了景点的相关内容后，根据乘车路线，可以对景点的公交信息进行互动查询，在公交信息模块中，也可以根据线路经由景点对景点信息进行查询。

根据景点信息的更新或者是公交信息的变更，进行添加、修改和删除的操作。

（2）酒店的功能需求：酒店信息作为旅游行业中不可分割的一部分，在系统中可以做相应的查询和管理，系统中列出酒店级别，以及酒店相关信息，并可以查询就近的景点信息。

根据酒店信息变更及时更新，保证最新性。

（3）信息服务的功能需求：因为本系统是针对屯溪地区的旅游系统，所以为方便信息查询，在本系统中提供了相应的交通信息，对于航班信息、长途客运信息和火车信息都做了具体介绍，对于旅游常见问题和旅游疑问解答也在此功能中得到解决。

3系统数据流图数据流图是在系统分析员在系统设计阶段，对实际构建的系统分析综合后，提取逻辑模型的一个过程，它更关注于过程内数据的处理，而把具体处理数据的物理过程，物理分布忽略。

(1)顶层图(2) 1层图4数据字典的作用是对数据流图中的各种成分进行详细说明，作为数据流图的细节补充，和数据流图一起构成完整的系统需求模型。

数据字典一般应包括对数据项，数据流、数据存储和数据处理的说明。

以下列出本系统的主要数据字典条目。

数据流条目：（1）景点信息=景点编号+景点名称+类型+门票价格+乘车路线+简介+图片（2）公交信息=线路名称+全程站点+始末车时间+价格+全程信息+景点名数据项条目：景点名称：类型：可变字符型长度：50处理条目：处理名：查询处理1；编号：1；输入：景点关键字；输出：景点对应记录信息；处理名：查询处理2；编号：2；输入：线路关键字；输出：公交对应记录信息；处理名：查询处理3；编号：3；输入：问题关键字；输出：解答；处理名：查询处理4；编号：4；输入：酒店关键字；输出：酒店对应记录信息；处理名：查询处理5；编号：5；输入：相关地点关键字；输出：长途客运对应记录信息；处理名：查询处理6；编号：6；输入：航程关键字；输出：航班对应记录信息；处理名：统计处理；编号：7；输入：票价、发车时间关键字；输出：长途统计信息；数据存储条目：文件名：景点记录组成：景点编号+景点名称+类型+门票价格+乘车路线+简介+图片组织方式：索引文件，以景点名称为关键5 系统的总体系统的模块划分根据对系统需求的分析，可以把系统划分：系统登录模块、主界面模块、系统管理模块、信息查询模块、高级查询与管理模块、管理员信息管理模块、小工具与娱乐和退出系统模块。

旅游管理系统用例文档一．参与人员 (1)二．用例总图 (1)三．具体用例说明 (1)3.1 UCHL01 (1)3.2 UCHL02 (1)3.3 UCHL03 (1)一．参与人员班级学号姓名七班 54100727 常瑞娟七班 54100728 陈玉城七班 54100729 荣春雨七班 54100730 王彬彬二．用例总图三．具体用例说明UCHL02:预定客房⏹用例名称预订客房⏹涉及的参与者旅客，旅店信息库⏹用例描述：旅客进入旅店管理系统的网站，按己所需，预订客房，登记个人信息⏹前置条件旅客必须已经登录到网上预订页面⏹后置条件旅客完成网上预订客房，旅店客房信息库更新⏹正常事件流：1.旅客进入旅店管理系统；2.查看旅店按季节和每周不同时间公布的价目表和空余的客房信息；3.旅客选择需要的客房档次，输入自己的姓名，地址，联系电话，有效证件号，房间类型和预订天数；4.旅客提交预订信息；5.旅客支付预定金；6.旅店信息库更新这个信息，并在以后的视图中看到这个数据。

⏹备选事件流1：旅客更改预订信息1.旅客查看当前预订信息；2.旅客选择更改条目；3.旅客重新输入预订信息；4.旅店信息库更新这个信息，并在以后的视图中都可以看到。

⏹非功能性需求无⏹涉及约束无⏹部署约束旅客可以从个人电脑或服务台访问”预订客房”用例，如果是从客户端访问，则要考虑到客户端的防火墙⏹未解决的问题采用何种费用支付方式UCHL03:”管理旅客信息”用例文档⏹用例名称:管理旅客信息⏹用例标识: UCHL03⏹涉及的参与者:旅店工作人员,客房信息库⏹描述:旅店工作人员利用”管理旅客信息”用例来对旅客的要求进行增删改。

客房信息库用这个用对所有旅客订房信息进行统一管理。

⏹前置条件：旅店工作人员必须登录到这个系统⏹后置条件：系统将旅客订房信息准确的记录到数据库中。

⏹正常事件流：1.旅店工作人员查看当前时间之前输入的数据。

2.旅店工作人员录入用电话等方式预定的旅客的信息。

旅游网需求分析设计
功能概述
本游旅游网的会员需要使用系统提供的如下功能：
浏览景点信息；
登陆或注册；
留言
更新本身的相关信息；
此外，会员在使用系统提供的上述功能之前需要进行登录。

当会员不需要使用系统的上
述功能时，也可退出系统。

需求分析
1、实现功能
系统用例图
这里将系统的每个最基本的有价值的业务功能，如登录、浏览景点信息、留言等，
称为用例。

图一：“E起游旅游网”系统的用例图
用例图中，使用一个椭圆表示用例，里面的文字描述了用例的名称。

会员可以使用或访问系统的部分功能，在图一中使用一个“火柴人”表示用户的身份，称为用例的参与者，系统有游客、会员、管理员三个参与者。

此外，图一中从参与者到用例的单向箭头表示二者之间的关联关系，例如会员可以使用或访问这些功能。

功能清单
2、时序说明
登录
参与者打开浏览器，输入应用系统的URL，浏览器中显示首页界面。

在登陆框输
入用户名称和口令后，提交页面。

系统验证会员的登录：若用户名称或口令不正
确，系统显示“登录失败,用户名或口令不正确”，系统返回上一页，会员可再次登
录；若用户名称和口令正确，会员登录成功，系统显示登陆成功的首页。

退出
会员登录系统之后，点击“退出”链接，系统销毁与会员的会话有关的资源，可
供其再次登录系统。

浏览景点信息
注册；
更新本身的相关信息； 购买景点票；
提交定单
生成定单；
修改定单的相关信息； 可以继续购买景点票； 查看购买的景点票； 留言；。

——需求分析报告目录1 引言 (3)1.1 编写目的 (3)1.2 开发目的及意义 (3)1.3 预期读者和阅读建议 (3)2 术语、定义和缩略语 (4)2.1 文档约定 (4)2.2 术语、定义 (4)2.3 缩略语 (5)3 系统功能需求 (5)3.1 系统功能 (5)3.2 用户特点 (13)3.3 设计和实现上的限制 (13)4 外部接口与运行环境需求 (13)4.1 用户界面 (13)4.2 硬件接口 (14)4.3 软件接口 (14)4.4 通讯接口 (14)4.5 运行环境 (14)5 其它非功能需求 (15)5.1 性能需求 (15)5.2 安全性需求 (15)5.3 用户文档 (15)需求分析1 引言由于时下大多数人生活优越，交通工具方便快捷，信息获取方便，导致旅游业迅猛发展。

为了方便旅游爱好者在网上获取信息，有效地掌握各大旅游景点的详细情况，我们多方听取意见、追加和完善大量实用功能，开发出一套适合于旅游者在网络上快速获取信息的管理系统。

通过本系统，出行者可以查看青城山的全部景点列表，了解其详细情况，自驾车、公交线路，获取景区内的旅游地图等。

该系统为游客提供全面的旅游景点查询服务。

1.1 编写目的在深入考察了已有的旅游景点网站，同时与多位软件使用者进行了全面深入地探讨和分析的基础上，提出了这份软件需求规格说明书。

此需求规格说明书对《旅游景点综合信息查询系统》软件做了全面细致的用户需求分析，明确所要开发的软件应具有的功能、性能与界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上进一步提出概要设计说明书、详细设计说明书及完成后续设计与开发工作。

本说明书的预期读者为客户、业务或需求分析人员、测试人员、用户文档编写者、项目管理人员。

1.2 开发目的及意义本系统提供对各旅游景点综合信息（景点介绍、出行线路查询、景点图片视频展示、景区餐饮分布、博客与论坛等）的查询与管理，可以作为旅游出行综合信息查询的门户。

实验一软件需求分析软件需求分析实验目的：1）掌握系统的功能描述、性能描述方法；2）掌握需求分析工具数据流程图、数据字典等；3）掌握系统需求分析的步骤和方法。

实验内容：用结构化数据流分析技术进行软件系统需求分析，得出系统的数据流程图和数据字典。

实验步骤：1)到相关单位进行需求分析2)综合利用网和相关书籍整理并完善需求分析。

3)画出系统数据流图（分析系统是事务型还是变换型）4)得出系统数据字典1.软件系统需求描述：（从功能，性能上进行描述）2.软件系统数据流程图（由加工、数据流、数据存储、源点和终点四种元素组成）：1）顶层数据流图2）1层数据流图3）2层数据流图3.软件系统数据字典1）数据流条目数据流：旅游地别名：描述：用来存储旅游地点信息定义：旅游地=区号+名称+人数位置：数据库数据流：游客别名：描述：用来存储游客信息定义：游客=身份证号+姓名+性别位置：数据库2）加工条目加工名：旅游管理系统加工编号：0层描述：对管理员添加旅游地点进行管理输入数据流：旅游地，游客输出数据流：旅游地，游客加工逻辑：若管理员输入密码正确则可以进行操作否则重新输入3）文件条目数据文件名：游客信息表简述：用于存放游客信息输入数据：游客信息输出数据：游客信息数据文件组成：游客信息表=身份证号+姓名+性别存储方式：关键码存取频率：经常数据文件名：旅游地点表简述：用于存放旅游地点信息输入数据：旅游地点信息输出数据：旅游地点信息数据文件组成：旅游地点表=区号+名称+人数存储方式：关键码存取频率：经常4. 实验小结实验二软件概要设计实验项目名称：软件概要设计实验目的：1）掌握系统总体结构的设计；2）掌握系统接口设计、数据结构设计等；3）掌握系统概要设计的步骤和方法。

实验内容主要解决实现该系统需求的程序模块设计问题（包括如何把该系统划分成若干个模块、决定各个模块之间的接口、模块之间传递的信息，以及数据结构、模块结构的设计等）。

实验步骤1）首先确定系统总体设计方案（分清系统是事物型还是加工型）。

一.旅店管理系统用例图
二．用例规约
1.预定房间
1 .1简要说明
本用例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。

1.2 先置条件
客户进入旅店管理系统，并选择预订房间功能。

1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双人间或单人间。

B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显示，供客户查询。

C 客户选定房间，并输入要预订的天数。

（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提示客户，该类型房间已全部被预订，询问客户是否选择另一类型的房间。

B 用户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发生冲突，则系统提示，该房间在哪些日期里已被预订，并询问当前客户是更换房间还是修改预订天数。

1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输入客户信息，包括客户的姓名、地址、联系电话、有效证件号。

另外，系统将计算出客户需要缴纳的定金和总费用，并显示出来。

B 客户重新选择房间类型，或修改天数，则刷新用户界面。