案例-旅游业务申请系统用例图和用例文档
旅游资源管理UML图
返回“注册成功”或“注册失败”页面
名称、标识符
登录系统
功能描述
用户通过账号和密码验证进入个人主页
性能
当用户访问个人主页时等待页面时间<5s
输入
用户的账号，密码
限制条件
1.必须连接数据库，否则会出现无法连接数据库错误
2.必须为已注册用户
输出
返回登录成功后的用户个人主页或是“登录失败”的提示信息
名称、标识符
名称、标识符
留言
功能描述
用户发表意见
性能
当用户点击“留言”按钮时响应时间<2s
输入
留言
限制条件
1.必须连接数据库，否则会出现无法连接数据库错误
2.必须为已登录用户
输出
返回“成功”或“失败”提示信息
名称、标识符
处理订单
功能描述
旅行社管理员处理用户提交的订单
性能
当管理员点击“处理”按钮时响应时间<2s
输入
2.旅游资源管理系统的用例：
查询景点信息、预定缴费、游客留言、注册登录、信息发布、订单处理
3.用例图：
4.用例描述
名称、标识符
注册账号
功能描述
通过输入用户基本信息，注册个人账号
性能
当用户点击“注册”按钮时响应时间<5s
输入
用户基本信息
限制条件
1.必须连接数据库，否则会出现无法连接数据库错误
2.用户昵称不可与已注册的用户昵称重复
限制条件
1.必须连接数据库，否则会出现无法连接数据库错误
2.必须为已登录用户
输出
返回“处理成功”或“处理失败”提示信息
5.时序图
注册登录
预订
UML建模之旅：旅游业务申请系统分析与设计建模案例使用说明书
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用例图、用例文档等技术，引导学生构建目标系统的需求模型，以完成需求定义工作。
(完整word版)旅游管理信息系统(word文档良心出品)
第一章需求分析和总体设计系统需求分析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 系统的总体系统的模块划分根据对系统需求的分析，可以把系统划分：系统登录模块、主界面模块、系统管理模块、信息查询模块、高级查询与管理模块、管理员信息管理模块、小工具与娱乐和退出系统模块。
旅游公司管理系统测试用例文档
3
游客信息修改
查询需要修改的游客
显示需要修改的游客信息
点击“修改游客信息”
显示游客信息
修改“会员登录名”5-15个英文或数字字符，支持中文，必填
显示修改后的游客信息
修改登录“密码”，6-16位，区分大小写
再输入一次密码，必填
修改“手机号”，11位数字，必须是有效的手机号码，必填
返回条件选择界面
选择若干项筛选条件（区域、单位、时间中的一项或几项）
显示符合搜索条件的案件
输入若干项案件审查信息
显示相应的结果信息
输入统计条件（其中的一项或多项）
以列表形式显示相应的统计结果
38
接54、55，点击打印
显示结果导出到Excel中
39
告知决定统计
以管理人员身份登陆系统后选择
一级菜单：统计信息
票务信息修改
查询修改线路信息
显示需要修改的票务信息
填写修改的“线路名称”
显示修改后的票务信息
在下拉菜单中选择新的“线路分类”（数据库中默认了的线路类型）
填写修改后的“订购价格”必须是人民币格式
在单选框中选择修改后的“过期状态”永不过期或在规定时间内有效（选填）
旅游时间（选填）在时间下拉框选择框里面输入修改后的起始时间和截止时间（选填）
序号
测试项
输入说明（操作）
输出说明（预期结果）
25
立案统计
以管理人员身份登陆系统后选择
一级菜单：统计信息
二级菜单：立案统计
显示提示用户输入案件的基本信息（其中一项或多项）（选项中包含对全部地区的统计，全部地区是默认值）
26
不输入任何案件信息点击查询按钮
软件工程UML,旅店管理系统,用例图建模,用例分析,设计过程
�求要业作 一
模建图例用
一业作
。面界户用新刷则�数天改修或�型类间房择选新重户客 B 。来出示显并�用费总和金定的 纳缴要需户客出算计将统系�外另。号件证效有、话电系联、址地、名姓的户客 括包 �息信户客入输户客求要统系 �后认确并数天订预和间房择选户客 A 件条置后 4 。数天订预改修是还间房换 更是户客前当问询并�订预被已里期日些哪在间房该�示提统系则�突冲生发段 间时的户客他其的 间房该了订预经已与段间时的间房的订预择选户用 B 。间房的型类一另择选否是户客问询�订预被 部全已间房型类该 �户客示提则�订预被部全已间房的型类要需所户客 A 流件事选备�2� 。数天的订预要入输并�间房定选户客 C 。询查户客供�示显表列息信的间房些这将 �间房的定预被未选筛 �中间房型类该有所从 �型类间房的择选户客据根 B 。间人单或间人双�型类的间房的订预要择选户客 A 流件事本基�1� 流件事 。能功间房订预择选并�统系理管店旅入进户客 件条置先 3
求要业作 一
程过计设 三业作
noitamrofnI noitavreseR droceR :4
eeF latoT tnuoC :3
epyT mooR esoohC :2 yrtnE :1 ecafretnI esabataD noitavreseR eeF noitamrofnI noitavreseR IU tneilC tneilC
)(etaerc// .1.1.2
)gn irts(evreseReraperp .1.2 间房定 预定选 // .2 )tsil(tsiLmooRyalpsid .2.1
ts il moor elbaliava// .1.1.1 )gnirts(mooRl iavAdn if .1.1 息信间房定预 可询查 // .1
旅游管理系统用例文档
旅游管理系统用例文档一．参与人员 (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）首先确定系统总体设计方案（分清系统是事物型还是加工型）。
UML旅店管理系统用例图、用例规约
一.旅店管理系统用例图
二．用例规约
1.预定房间
1 .1简要说明
本用例允许客户预订旅店的未被预订的房间，系统提供未被预订的房间的信息列表。
1.2 先置条件
客户进入旅店管理系统，并选择预订房间功能。
1.3 事件流
（1）基本事件流
A 客户选择要预订的房间的类型，双人间或单人间。
B 根据客户选择的房间类型，从所有该类型房间中，筛选未被预定的房间，将这些房间的信息列表显示，供客户查询。
C 客户选定房间，并输入要预订的天数。
（2）备选事件流
A 客户所需要类型的房间已全部被预订，则提示客户，该类型房间已全部被预订，询问客户是否选择另一类型的房间。
B 用户选择预订的房间的时间段与已经预订了该房间的其他客户的时间
段发生冲突，则系统提示，该房间在哪些日期里已被预订，并询问当前客户是更换房间还是修改预订天数。
1.4 后置条件
A 客户选择房间和预订天数并确认后，系统要求客户输入客户信息，包括客户的姓名、地址、联系电话、有效证件号。
另外，系统将计算出客户需要缴纳的定金和总费用，并显示出来。
B 客户重新选择房间类型，或修改天数，则刷新用户界面。
计算机软件——UML旅游管理系统
计算机软件——U M L旅游管理系统(总22页)本页仅作为文档封面，使用时可以删除This document is for reference only-rar21year.March2013级金融信息化1班雷洋 20137710126目录一、项目概述 (4)二、需求分析 (4)1、需求陈述： (4)2、数据库： (5)三、项目用例分析及系统建模创建系统用例模型 (6)1、游客用例 (6)2、旅行社用例 (8)3、系统管理员用例 (9)系统的静态模型 (12)系统的动态模型 (12)1、创建序列图和协作图 (12)2、创建状态图 (18)系统的部署模型 (22)旅游预订系统项目需求分析一、项目概述随着社会的发展，人们的生活质量也越来越好，外出旅游也成了人们日常生活不可或缺的一项活动。
而伴随着紧张的生活节奏，人们更渴望能便捷的，省时的完成各项旅游前的规划准备。
因此我们的“旅游预订系统”便可以为大家提供便捷的途径。
各地的旅行社都可以在这里注册，发布路线。
而旅客只需轻点鼠标，便可在这里查询想要的旅游路线，预订旅游。
希望我们的系统能让您满意。
二、需求分析适用群体：所有规范的旅行社，全体市民。
可行性分析：技术可行性，操作可行性，经济可行性。
1、需求陈述：1)前台管理：前台作为与用户直接交互的可视化界面，必须简洁明化，不仅要让前台服务员一目了然，而且没有压迫感，方便好用，能将系统的各个功能提供给服务员，以帮助前台服务员进行管理。
这样做的目的是让大多数客户能够轻松地享受系统给他们带来的便利。
2)后台管理：为了确保游客和旅行社的信息具有更好的安全性，前台管理和后台管理是分离的。
前台、后台的各管理模块需要经过权限授权才可以使用，前台的主要角色是旅行社和游客，而后台的主要角色即是系统管理人员。
3)旅行社：旅行社注册，发布旅游线路。
确认预订客户信息。
4)游客：游客可以查询路线，填写预订信息。
5)系统管理员：分别按照价格、日期、旅行社、旅游地区等类别分类数据，数据库更新。
案例-旅游业务申请系统用例图和用例文档
旅游申请系统用例图
表1给出了旅游申请系统中“办理申请手续”用例的文档。
由于该用例中并没有明确的非功能需求，因此在文档中也没有体现。
表1 “办理申请手续”用例文档
表2给出了“管理参加人”用例文档，与前一个用例文档不同的是，该用例文档的基本事件流被划分成三个子流程，通过子流程的方式可以使该用例文档的结构更加清晰。
表2 “管理参加人”用例文档
表3给出了“完成支付”用例文档。
从用例文档可以看出，该用例文档和“管理参加人”用例文档的基本事件流中存在很多相似的地方，即都需要查询申请的信息；在下一节将介绍如何处理这种情况。
表3 “完成支付”用例文档
表4给出了系统中另一个参与者“收款员工”参与的用例“打印旅游确认书和余额交款单”的用例文档，注意在该用例文档的基本事件流的第3步中如何表示循环操作。
表4 “打印旅游确认书和余额交款单”用例文档
户，所以事件流中全是系统的动作。
此外，由于问题陈述中并没有提及有关财务系统的相关细节，因此与财务系统的交互模式也无法表示清楚。
表5 “导出财务信息”用例文档。
案例旅游业务申请系统用例图和用例文档.doc
案例旅游业务申请系统用例图和用例文档文件编号UML-T02 版本号 1.1 创建日期2009-11-11 作者thbin 更新日期2010-10-29 北京航空航天大学软件学院“面向对象分析与设计”案例文档旅游业务申请系统用例文档旅游申请系统用例图表1给出了旅游申请系统中“办理申请手续”用例的文档。
由于该用例中并没有明确的非功能需求，因此在文档中也没有体现。
表1 “办理申请手续”用例文档用例名办理申请手续简要描述前台服务员通过该用例为申请人办理申请旅游团的手续参与者前台服务员涉众申请人、前台服务员相关用例暂无前置条件前台服务员登录到系统后置条件申请信息被正确保存，相关旅游团可申请人数减少基本事件流 1. 该用例起始于旅客需要办理申请手续； 2. 前台服务员录入要申请的旅游团旅行路线代码和出发日期； 3. 系统查询要申请的旅游团信息（A-1）； 4. 系统显示查询到的旅游团和相关路线信息（D-1）（A-2、A-3）；5. 前台服务员录入本次申请信息（D-2）； 6. 系统显示旅行费用的总额和申请订金金额；7. 前台服务员提交该申请信息；8. 系统保存该申请信息（A-4），用例结束。
备选事件流A-* 前台服务员在提交该申请前，随时都可能中止该申请 1. 系统显示中止确认的消息； 2. 前台服务员可以结束该用例，也可以选择继续录入下一个申请。
A-1 无法查询到所需的旅游团信息1. 系统显示录入的旅游线路代码或者出发日期有误信息； 2. 前台服务员再次录入旅游路线代码和出发日期，也可以结束用例。
A-2 旅行已超过申请截止日期1. 系统提示已超过申请截止日期，不能申请； 2. 前台服务员重新输入旅游线路代码和新的出发日期，也可以结束用例。
A-3 可以申请的人数为0人1. 系统提示旅游团人数已满；2. 前台服务员重新输入新的旅游线路代码和出发日期，也可以结束用例。
A-4 保存信息失败1. 系统显示保存失败，并提示用户需要再次提交； 2. 前台服务员可以重新提交该申请，也可以结束用例。
旅游系统详细设计说明书【模板范本】
旅游系统详细设计说明书作者：完成日期：签收人：签收日期：修改情况记录:目录2 程序系统的结构 (1)1.安全登陆模块 (1)1。
1 程序描述 (1)1。
2 功能 (1)1。
3 性能 (2)1.4 输入项 (2)1。
5 输出项 (2)1.6 算法 (3)1.7 流程逻辑 (3)1.8 接口 (4)1.9 存储分配 (5)1.10 注释设计 (5)1。
11 限制条件 (5)1。
12 测试计划 (5)1。
13 尚未解决的问题 (5)2.景区查询设计说明 (5)2.1 程序描述 (5)2。
2 功能 (6)2。
3 性能 (6)2.4 输入项 (6)2.5 输出项 (7)2。
6 算法 (7)2.7 流程逻辑 (8)2。
8 接口 (9)2.9 存储分配 (9)2.10 注释设计 (9)2.11 限制条件 (10)2。
12 测试计划 (10)2.13 尚未解决的问题 (10)3.详细查询设计说明 (10)3.1 程序描述 (10)3。
2 功能 (10)3。
3 性能 (10)3.4 输入项 (11)3.5 输出项 (11)3.6 算法 (11)3。
7 流程逻辑 (12)3.8 接口 (12)3.9 存储分配 (12)3。
10 注释设计 (13)3.11 限制条件 (13)3.13 尚未解决的问题 (13)4。
预算计算3（标识符）设计说明 (13)4。
1 程序描述 (13)4.2 功能 (14)4。
3 性能 (14)4。
4 输入项 (14)4。
5 输出项 (14)4。
6 算法 (15)4.7 流程逻辑 (15)4.8 接口 (16)4.9 存储分配 (16)4.10 注释设计 (16)4.11 限制条件 (16)4。
12 测试计划 (16)4。
13 尚未解决的问题 (17)5.景区热度4（标识符）设计说明 (17)5.1 程序描述 (17)5.2 功能 (17)5.3 性能 (17)5.4 输入项 (17)5.5 输出项 (17)5。
开发一组旅游景点系统需求规格书
查询：city Idint11是非空
city Namevarchar100否非空
发表：messagevarchar255否可为空
注册：uesrNamevarchar100否非空
passwdvarchar100否非空
2.5.
数据库名：travel
userinfo:
city Namevarchar100否非空
city Descrivarchar255否可为空
scenIdint11否非空
控制类（Control）：
登录：显示登录界面，输入正确的用户名和密码后点击确定。
注册：没有账号的用户点击后填写新的用户名和密码及密码的确认点击确定。
查询：在请输入要查询的城市中输入要查询的城市名字，如果存在就显示该城市信息，不存在就重新输入。
只有1周的时间搞定需求！请紧迫点…拒绝没有自身内容的照搬照抄的应试教育痕迹…谢谢！
5
开发需求：参照示例系统，逆向追溯需求，按需求去开发
不能只重视技术学习，业界经验：目标清晰的需求，更会拉动技术成长。
6
现场指导：近期安排1、2次现场讲解，以指导需求开发
周三以后…
3.1.
3.1.1.
用户登录手机客户端，可以查询江苏13个市的旅游景点的图片，并且可以对这13个城市的风景进行点评，但是点评需要用户登录，如果没有用户名可以进行注册，发表评论后可以到相对应的评论栏查看评论。
……
4.
4.1.
响应时间需求
无论是客户端还是管理端，当用户登录，进行任何操作时，系统应及时响应，反映的时间在5秒以内。系统应能监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，以免出现长时间等待甚至无响应。
旅游863拓扑图
数字旅游服务系统应用层（发布层）
搜索引擎 常规营销活动 游客工具 优惠信息 计算机 客户营销 视频动画营销 旅游活动 周边咨讯 呼叫中心 目的地城市 产品预定（多渠道 产品预定（多渠道） 反馈信息更新 智能行程安排 旅游搜索 触摸屏系统 交通查询
三网融合 的在线旅 游服务发 布系统
系统结构图
地址：北京市来广营西路5号森根国际2E座 | 电话：(86-10)8492 6666 | 传真:(86-10)8490 0069 | Βιβλιοθήκη 其他终端设备 通讯终端 电视
Web Service
数字旅游服务层（控制层）
智能信息服务 地理信息服务 多媒体资源组织 决策支持 分布式信息服务 路线规则 通信服务 旅游产品信息接口 交易服务 发布渠道接口
数据资源层
目的地宣传数据库 目的地基础信息数据库 旅游产品数据库
地址：北京市来广营西路5号森根国际2E座 | 电话：(86-10)8492 6666 | 传真:(86-10)8490 0069 |
旅游管理系统SQL
1. 朱如龙.《SQL Server 2000 数据库应用系统开发技术》.机械工业出版社
2.(美)巴尔特.《SQL Server 2000 数据库开发指南》.人民邮电出版社
3.杨继萍/孙岩.《SQL Server 2000数据库应用与开发》.清华大学出版社
八、设计心得和体会
（需要描述个人在小组设计中承担的任务和完成情况；个人小结）
游客表（游客号，游客姓名，性别，出生日期，电话，旅行团号#）主键：游客号 外键：引用旅行团表的旅行团号
旅游纪念品表（商品号，商品名，价格） 主键：商品号
购买表（游客号，商品号）主键：游客号和商品号 外键：引用游客表的游客号，引用旅游纪念品表的商品号
五、物理模型设计
旅游线路表
列名
数据类型
长度
约束
描述
RID
Varchar
10
主键
线路号
RName
varchar
10
非空
线路名
RDay
varchar
2
非空
天数
RDate
varchar
10
非空
日期
RInf
varchar
10
非空
景点信息
旅行团表
列名
数据类型
长度
约束
描述
PID
Varchar
10
主键
旅行团号
PCap
varchar
10
非空
联系人
PNum
varchar
7
insert into 旅游线路表 values('R4','北京五日游','5','2013-4-12','游北京景点')
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
旅游申请系统用例图
表1给出了旅游申请系统中“办理申请手续”用例的文档。
由于该用例中并没有明确的非功能需求，因此在文档中也没有体现。
表1 “办理申请手续”用例文档
用例名办理申请手续
简要描述前台服务员通过该用例为申请人办理申请旅游团的手续
参与者前台服务员
涉众申请人、前台服务员
相关用例暂无
前置条件前台服务员登录到系统
后置条件申请信息被正确保存，相关旅游团可申请人数减少
基本事件流
1. 该用例起始于旅客需要办理申请手续；
2. 前台服务员录入要申请的旅游团旅行路线代码和出发日期；
3. 系统查询要申请的旅游团信息（A-1）；
4. 系统显示查询到的旅游团和相关路线信息（D-1）（A-2、A-3）；
5. 前台服务员录入本次申请信息（D-2）；
6. 系统显示旅行费用的总额和申请订金金额；
7. 前台服务员提交该申请信息；
8. 系统保存该申请信息（A-4），用例结束。
备选事件流
A-* 前台服务员在提交该申请前，随时都可能中止该申请
被划分成三个子流程，通过子流程的方式可以使该用例文档的结构更加清晰。
表2 “管理参加人”用例文档
表3给出了“完成支付”用例文档。
从用例文档可以看出，该用例文档和“管理参加人”用例文档的基本事件流中存在很多相似的地方，即都需要查询申请的信息；在下一节将介绍如何处理这种情况。
表3 “完成支付”用例文档
用例文档，注意在该用例文档的基本事件流的第3步中如何表示循环操作。
表4 “打印旅游确认书和余额交款单”用例文档
表5给出了“导出财务信息”用例文档。
由于该用例的参与者是时间和财务系统，没有外部用户，所以事件流中全是系统的动作。
此外，由于问题陈述中并没有提及有关财务系统的相关细节，因此与财务系统的交互模式也无法表示清楚。
表5 “导出财务信息”用例文档。