基于安卓设备的景区导览系统设计.docx

基于安卓设备的景区导览系统设计.docx

《基于安卓设备的景区导览系统设计.docx》由会员分享，可在线阅读，更多相关《基于安卓设备的景区导览系统设计.docx（30页珍藏版）》请在冰豆网上搜索。

基于安卓设备的景区导览系统设计

基于安卓设备的景区导览系统

需求说明书

一、引言

1、编写目的

本说明书用于明确要开发的软件的具体需求，规的描述出软件需要实现的各种功能和所要达到的性能。

2、项目背景

随着人民生活水平的提高，以及我国休假制度的完善，人们拥有了更长更多的假期，而假期外出旅游成为了越来越多的人们度过假期的第一选择。

在这样的背景前提下，各大旅游景区更是成为了热门中的热门，这也造成了在旅游高峰期部分旅游景点人流过大导致拥堵，从而影响到游客旅游体验的问题。

不过从根本上来说，并不主要是因为游客数量的过大，往往是因为景区的服务不够全面细致，管理不够科学，效率不高所造成的，例如景区部的地标不够详细或者是不够完整都可能会影响的游客游玩时的顺畅性。

另一方面来说，游客人数的急剧增长所带来的安全问题，如游客的人生安全，景区的设施安全等也日益明显突出起来，系统化、电子化、网络化、智能化的景区管理系统也成为了日益迫切的需求，本项目就是在这样的背景下提出的，旨在开发出一个能够方便游客、便于景区管理的景区导览系统。

二、任务概述

1、任务目标

该系统将要完成的是旅游景区的导览功能。

这里提到的导览，是指景区向游客提供的一种服务，这种服务的目的是让游客能够方便的获取景区的各种介绍信息以及景区的实时状态，例如景区各个分景点的人流是否拥挤、分景点的游览车的数量等等，还要提供相应的查询功能，例如查询欲知景点的位置信息，当前位置到该景点的距离及绘制出最合适的路径轨迹信息等等。

在游客拥有自己的PDA设备的前提下，利用手持设备的wifi功能，向游客的设备传输对应景区的导览文件（如视频介绍，文字介绍，以及查询服务）。

并且完成提供导览文件资源的服务器资源数据的管理，例如日常维护，更新文件资源等，并且提供对客户终端请求的处理。

客户端的开发是基于谷歌android操作系统平台的，该操作系统是目前最火热的几大主流操作系统之一，具有巨大的市场和发展潜力，有望在未来几年成为移动电子设备上占有量最大的操作系统，因此本软件选择在之上进行开发，另外，编程语言选择Java，因此具有较好的可移植性。

服务端采用微软的MFC框架进行开发，MFC（MicrosoftFoundationClasses），是一个微软公司提供的类库（classlibraries），以C++类的形式封装了Windows的API，并且包含一个应用程序框架，使用MFC可以加快软件的开发流程。

2、用户特点

对于客户端的使用会涉及到各种类型的游客人群，虽然android操作系统刚刚退出不久尚未在国普及，对部分人群可能会比较生疏，但是凭借其简洁明了的UI和快捷的操作特性，并不要求用户对其特别的熟悉，因此可以做到让使用方法简单易懂，操作方法尽量浅显明了，使用户能够在短时间借助简易的说明快速上手。

为了提高系统的实用性，要求具有较强的可靠性和较大的吞吐量。

对于服务端的操作人员，由于软件设计的提供给操作人员的接口仅仅会涉及到简单的文件新建、修改、复制、删除等操作，因此仅仅需要操作人员熟悉简单的电脑操作即可，不需要专门进行培训。

用户需求框图如下图所示：

图2-1系统角色图

3、假定条件和约束限制

1）、硬件约束

需求名称

详细要求

服务器硬件要求

支持Intel平台、AMD平台。

双CPU2.0G以上，存2.0G以上，100M网卡、硬盘250G以上，带液晶显示。

服务器系统平台

WindowsXP/Windows7及以后

客户端硬件要求

支持android操作系统的嵌入式平台，支持wifi功能，支持GPS定位，带触摸屏功能，具有音频输出

客户端系统平台

Android操作系统2.1及以后

2）、用户约束

需求名称

详细要求

客户端用户（游客）

会简单的触摸屏操作

服务端用户（管理员）

会基本的计算机操作

三、功能需求

1、功能用例图

图31功能用例顶层用例图

图22用户获取服务用例图

图23景区实时监控用例图

图24景区导览资源管理用例图

2、用户获取服务

用例标识和历史

需求ID:

1001

用例名称:

用户获取服务

版本号:

V1.00

目的:

描述整个系统中，用户所能进行的相关操作，如用户的登入登出、查询景点、定位，用户获取景区导览信息等

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

较高

前提条件:

见下级用例

结束条件:

见下级用例

非功能性需求:

假设,问题:

系统（客户端、服务器）正常运行

步骤:

该用例为组合用例，包含以下用例：

登陆服务器、缩放地图（放大/缩小）、定位、查询并定位景点、获取各景点多媒体信息（文字信息/音频信息/视频信息）、计算当前位置与指定景点的路程、获取当前各景点状况（人数、车辆数）

2.1.1用户登录服务器

用例标识和历史

需求ID:

1002

用例名称:

用户登录服务器

版本号:

V1.00

目的:

为了防止导览资源服务器带宽被非游客所占用，故需要设定一级用于验证用户身份的密码，用于控制可以使用资源服务器的客户端，该密码可以简单的设定为门票上的唯一ID编码。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

较高

前提条件:

程序完成安装，网络连接无异常

结束条件:

服务器被关闭

非功能性需求:

提供有条件的强制登录（当密码意外无效时，需要向管理人员申请，获得批准）

假设,问题:

系统（客户端、服务器）正常运行；且门票ID清晰可见并唯一

步骤:

用户登录流程图：

2.1.2缩放地图

用例标识和历史

需求ID:

1003

用例名称:

缩放地图

版本号:

V1.00

目的:

为了能够使用户在客户端设备的屏幕上更合适的显示自己关心的一部分区域，设置了缩放地图功能。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

较高

前提条件:

程序正常运行

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户端正常运行

步骤:

缩放地图流程图：

2.1.3定位

用例标识和历史

需求ID:

1004

用例名称:

定位

版本号:

V1.00

目的:

利用GPS或者依靠景区部署的阅读器返回用户当前的地理信息，可供实时定位和位置、路径跟踪使用。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

总是

前提条件:

GPS卫星信号正常，设备硬件正常

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户设备功能正常

步骤:

定位流程图：

2.1.4查询并定位景点

用例标识和历史

需求ID:

1005

用例名称:

查询并定位景点

版本号:

V1.00

目的:

使游客能够根据景点的名称查询到景点的位置，方便游客顺利的到达自己希望参观的景点。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

一般

前提条件:

程序正常运行，供查询的服务器工作正常

结束条件:

查询超时或者查询成功

非功能性需求:

模糊查询

假设,问题:

客户端正常运行

步骤:

查询并定位景点流程图：

2.1.5获取各景点多媒体信息

用例标识和历史

需求ID:

1006

用例名称:

获取各景点多媒体信息

版本号:

V1.00

目的:

为了能够使用户更加了解某个景点的一些详细资料例如景点的主要观赏点、景点的历史典故、景点的一些实景拍摄等来决定自己的游玩方案，用户可以通过客户端了解到相关景点丰富的多媒体介绍信息。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

较高

前提条件:

程序正常运行，网络连接正常，资源服务器工作正常

结束条件:

程序崩溃或关闭相关多媒体窗口

非功能性需求:

多媒体信息保持及时更新

假设,问题:

客户端正常运行

步骤:

获取各景点多媒体信息流程图：

2.1.6计算当前位置与指定景点的路程

用例标识和历史

需求ID:

1007

用例名称:

计算当前位置与指定景点的路程

版本号:

V1.00

目的:

为了能够使用户能够直观的看出自己距离想去的一个景点的路程，该功能使得客户可以通过客户端得到当前位置到一个目的景点的距离并且绘制出最短的轨迹。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

一般

前提条件:

程序正常运行

结束条件:

程序崩溃或设备故障

非功能性需求:

绘制出的轨迹尽量合理

假设,问题:

客户端正常运行

步骤:

计算当前位置与指定景点的路程流程图：

2.1.7获取当前各景点状况

用例标识和历史

需求ID:

1008

用例名称:

获取当前各景点状况

版本号:

V1.00

目的:

由于各分景点的人数容量有限，如果游客进入到了一个过度拥挤的景点，不仅游玩质量会受到影响，而且还可能耽误行程，本功能需求就是基于这样一个事实考虑得出的，为了游客能够时刻对各景点的状态有所掌握，从而做出最好的游玩选择。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（游客）

业务所有者:

联系信息:

触发者:

用户（游客）

参考资料:

使用频度:

可设置刷新频率

前提条件:

程序正常运行，与服务器通讯正常

结束条件:

程序崩溃或设备故障

非功能性需求:

要求

假设,问题:

客户端正常运行

步骤:

获取当前各景点状况流程图：

2.2景区实时监控

用例标识和历史

需求ID:

2001

用例名称:

景区实时监控

版本号:

V1.00

目的:

为了能够使景区管理人员能够全面的、方便的掌控景区的实时状态，以便能够对景区的人流和车流进行适当的管理，另外还提供了景区的事故模拟疏散模型，增加景区事故发生后响应的处理到达的效率。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（景区管理员）

业务所有者:

联系信息:

触发者:

用户（景区管理员）

参考资料:

使用频度:

始终运行

前提条件:

程序正常运行

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户主机正常运行

步骤:

该用例为组合用例，包含以下用例：

景区实时状态、查询数据、分析数据、模拟疏散模型等。

2.2.1景区实时状态

用例标识和历史

需求ID:

2002

用例名称:

景区实时状态

版本号:

V1.00

目的:

将当前的景区各景点、各地区的实时信息同意搜集并上传到用于显示和分析景区实时状态的主机上并进行显示。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（景区管理员）

业务所有者:

联系信息:

触发者:

用户（景区管理员）

参考资料:

使用频度:

始终使用

前提条件:

程序正常运行

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户主机正常运行

步骤:

景区实时状态流程图：

2.2.2查询数据

用例标识和历史

需求ID:

2003

用例名称:

查询数据

版本号:

V1.00

目的:

通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的查询功能，可以方便的查询到各景点状态的历史信息，用于分析。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（景区管理员）

业务所有者:

联系信息:

触发者:

用户（景区管理员）

参考资料:

使用频度:

一般

前提条件:

存储数据正常

结束条件:

完成一次查询

非功能性需求:

无

假设,问题:

客户主机正常运行

步骤:

查询数据流程图：

2.2.3分析数据

用例标识和历史

需求ID:

2004

用例名称:

分析数据

版本号:

V1.00

目的:

通过编号2002的需求获得的实时状态数据将会被存档保存，用于此处的分析功能，通过用例2003可以方便的查询到各景点状态的历史信息，用于对景区日常运营状况的分析，帮助景区管理人员对景区进行管理。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（景区管理员）

业务所有者:

联系信息:

触发者:

用户（景区管理员）

参考资料:

使用频度:

一般

前提条件:

存储数据正常

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户主机正常运行

步骤:

分析数据流程图：

2.2.4模拟疏散模型

用例标识和历史

需求ID:

2005

用例名称:

模拟疏散模型

版本号:

V1.00

目的:

为了在景区发生一些意外事故的时候能够有效的疏散人流，构造了模拟疏散模型来模拟人流的疏散效果，生成一系列的疏散预案，以便当景区真正发生意外情况时，能够采取最有效的措施。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（景区管理员）

业务所有者:

联系信息:

触发者:

用户（景区管理员）

参考资料:

使用频度:

一般

前提条件:

程序正常运行

结束条件:

程序崩溃或设备故障

非功能性需求:

无

假设,问题:

客户主机正常运行

步骤:

模拟疏散模型流程图：

2.3景区导览资源管理

用例标识和历史

需求ID:

3001

用例名称:

景区导览资源管理

版本号:

V1.00

目的:

本用例目的在于方便对各景点所关联的导览资源进行统一的、高效的管理。

考虑到各景点信息的更新，增加或删除等。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（导览资源管理员）

业务所有者:

联系信息:

触发者:

用户（导览资源管理员）

参考资料:

使用频度:

一般

前提条件:

数据库服务器工作正常

结束条件:

程序崩溃或服务器故障

非功能性需求:

无

假设,问题:

服务端、客户端正常运行

步骤:

该用例为组合用例，包含以下用例：

新增导览信息、删除导览信息、更新导览信息、定期维护导览信息等。

2.3.1新增导览信息

用例标识和历史

需求ID:

3002

用例名称:

新增导览信息

版本号:

V1.00

目的:

在系统初始化设置的时候，需要录入各景点的导览信息供客户使用，同时，在新增景点时，也需要通过此用例录入新增景点的导览信息。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（导览资源管理员）

业务所有者:

联系信息:

触发者:

用户（导览资源管理员）

参考资料:

使用频度:

较高

前提条件:

数据库服务器工作正常

结束条件:

程序崩溃或服务器故障

非功能性需求:

无

假设,问题:

服务端、客户端正常运行

步骤:

新增导览信息流程图：

2.3.2删除导览信息

用例标识和历史

需求ID:

3003

用例名称:

删除导览信息

版本号:

V1.00

目的:

在需要删除景点的导览信息供客户使用。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（导览资源管理员）

业务所有者:

联系信息:

触发者:

用户（导览资源管理员）

参考资料:

使用频度:

较高

前提条件:

数据库服务器工作正常

结束条件:

程序崩溃或服务器故障

非功能性需求:

无

假设,问题:

服务端、客户端正常运行

步骤:

删除导览信息流程图：

2.3.3更新导览信息

用例标识和历史

需求ID:

3004

用例名称:

更新导览信息

版本号:

V1.00

目的:

为了给游客更好的服务，需要及时的更新导览信息，以便让游客能够掌握最新的、有效的导览资料，避免导览资料的过期所带来的一系列问题例如给误导、引发混乱、纠纷等情况。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（导览资源管理员）

业务所有者:

联系信息:

触发者:

用户（导览资源管理员）

参考资料:

使用频度:

较高

前提条件:

数据库服务器工作正常

结束条件:

程序崩溃或服务器故障

非功能性需求:

无

假设,问题:

服务端、客户端正常运行

步骤:

更新导览信息流程图：

2.3.4定期维护导览信息

用例标识和历史

需求ID:

3005

用例名称:

定期维护导览信息

版本号:

V1.00

目的:

为了保证导览服务的可靠性，需要定期对导览信息进行维护，避免导览资源的失效而引发导览系统的缺陷。

上一次更新:

On（日期）:

批准人:

On（日期）:

用户/行为人:

用户（导览资源管理员）

业务所有者:

联系信息:

触发者:

用户（导览资源管理员）

参考资料:

使用频度:

较高

前提条件:

数据库服务器工作正常

结束条件:

程序崩溃或服务器故障

非功能性需求:

无

假设,问题:

服务端、客户端正常运行

步骤:

定期维护导览信息流程图：

四、界面功能

1、查询功能

系统需要方便的使用查询功能，考虑到此功能的使用频度较高，因此将其设计于主界面的正上方，首先在查询的文本框中输入需要查询的景点名称，然后点击右边的查询按钮即可搜索出对应的景点并在地图上绘制一个标记而且定位到该景点。

2、查看导览资源

要查看某景点的导览资源，首先在地图上点击地图标记，将弹出一个用于显示导览资源的气泡，如图4-7所示，气泡中直接显示的是该景点对应的文字介绍，在气泡的右上角有三个按钮，分别是播放音频、播放视频、关闭气泡，通过点击它们可以实现各自的功能。

例如，点击地图上的景区标记D，将会弹出一个气泡，可以看到气泡的文字信息。

点击播放视频按钮将转到播放视频的界面，然后可以观看该景区的导览视频，类似地，点击播放音频按钮则可直接收听该景区的导览音频。

3、资源管理界面

提供给景区导览资源管理人员使用的资源管理界面如图4-9所示，提供所需的新建、删除、编辑等功能。

从图中看，界面通过一些操作用的按钮和一个显示导览资源信息的表格组成。

五、性能需求

1、响应需求

响应时间必须满足如下需求：

●文字资源获取速度：

≤5秒（待定）；

●音视频资源缓冲时间：

≤10秒（待定）；

2、可靠性需求

系统可靠性应满足如下需求：

●在旅游高峰期时，500个并发连接请求的一次性成功率不能低于90%；

3、可用性需求

系统应满足如下可用性需求：

●能够在景区开放时段提供服务；

4、精度需求

系统应满足如下精度要求：

●景点定位精确度在±50米以；