APP简介及开发方案
1
第一章 项目背景
开发的APP可以在Android两大操作系统中安装，使用移动互联网下的手机和平板端软件。APP应用开发中的功能皆与饭馆/酒店/餐厅相关联，能帮助饭馆/酒店/餐厅更好的推广自身品牌，帮助客人更好的享受服务。目前着手开发一款撮合信息的APP软件已成为当重之急，他们认识到，这样才能帮助饭馆/酒店/餐厅更好的服务于客户，拉近饭馆/酒店/餐厅与客户间的距离。从而提高顾客对于饭馆/酒店/餐厅的忠诚度，帮助饭馆/酒店/餐厅创收。
第二章 开发工具
操作系统：Android手机操作系统,浏览器登陆 数 据 库：sql server 开发工具：
后台主要是进行数据的管理，采用的数据库为sqlserver，并配合使用分布式缓存技术。
开发环境： 运行环境： 开发框架：
2
第三章 APP功能简介
2.1功能总现
用户可以通过手机在任何地方、任何时间浏览饭馆/酒店/餐厅等信息，了解饭馆/酒店/餐厅的信息情况。
2.2会员积分管理
积分来源：
用户通过APP平台首页的“签到”功能即可获取积分。 积分明细查询：
用户登录“我的”后，可以查询积分信息，包括积分增长以及消费明细。
2.3 GPS定位
基于客户端内嵌的高德地图或者百度地图API，系统能为顾客提供饭馆/酒店/餐厅名称及地址信息，方便顾客轻松找到餐厅位置，节省时间。周边数据调用API获取数据，周边信息来源于地图API。
定位对于现在的手机来说，是一个分常见的功能。本软件采用的是高德定位，实现GPS、基站、网络三种混合式定位。
3
2.4 APP相关接口说明
系统在功能模块的设计上，以“高内聚、低耦合”为设计目标。内部接口方面，各模块之间采用函数调用、参数传递、返回值的方式进行信息传递。具体参数的结构将在下面数据结构设计的内容中说明。接口传递的信息将是以数据结构封装的数据、参数传递或返回值的形式在各模块间传递。
平台应包括但不限于以下接口：
与LBS的接口：系统应具备与LBS的标准接口。定位用户位置，以便于进行导航。
与高德或其他地图系统的接口：系统具备与高德或其他地图的标准接口，方便用户使用地图功能查看酒店位置。
与手机支付系统的接口：系统具备与手机支付的标准接口，方便用户使用手机支付。通过调用第三方支付平台，可以实现在手机端的购物支付功能。
与即时通讯系统的接口：系统具备登录用户实时聊天的功能，方便用户信息沟通。通过即时通信技术，可以让使用者在网络上建立某种私人聊天室（chatroom）的实时通讯服务。
注册，登陆，注销，修改密码，忘记密码功能通过邮箱找回，自动定位，根据位置显示周边商家信息，可以查看商家详细信息，单独部署的业务逻辑模块，成功地订单扣除几分，并推送到手机客户端，查看订单详情，用户聊天，聊天里面提供系统客服，签到送积分 ，支付宝充值积分，商家信息排序，收藏商家信息，搜索商家功能。
4
第三章 APP业务流程简述
3.1 APP整体建设结构
系统建设结构图
5
3.2 APP系统业务逻辑层和架构技术
SJSPActionServiceDao 系统流程导向图
S
表示请求的开始
JSP表示jsp页面部分。
表示处理Http请求的Action。 表示对业务进行封装的部分。 表示执行数据库操作部分。 HTTP请求。 服务器端内部调用。 Action处理后返回的页面。
ActionServiceDao
action层是第一层，主要用来及接受客户端传上来的数据并且做数据的非空和格式是否正确的验证，如是否为空、是不是安全字符串之类的。service层一般是用来做一个业务逻辑的实现，这时候将会对上传的数据进实例化、处理、验证。DAO层就是与数据库交互层，也就是读写数据库，根据逻辑层得到的条件得到数据库的数据。
本系统采用的框架是spring+webwork+ibatis 。
APP内的信息进行条件撮合时，业务逻辑进行单独部暑。这一部分对数据处理量较大，应用高处理的务服器，同时也能提高并发量。
可以动态更新的Active Directory 架构。应用程序可以使用新的属性和类扩展该架构，并能立刻使用该扩展。通过在Active Directory 中
6
创建或修改存储在 Active Directory 中的架构对象来完成架构的更新。与Active Directory 中的所有对象一样，架构对象能访问控制列表，因此只有授权的用户才可以更改架构。
3.3 APP系统压力承载及并发性能
性能重点就是大量手机调用接口对服务器的压力，所以重点是在服务器上。主要是利用接口对服务器施加压力，重点关注响应时间、吞吐量、并发数、事物通过率等。
代码书写方面，我们会严格按照标准化代码格式书写代码。
7
前台使用流程说明
8
3.4 APP
3.5 APP后台信息录入使用流程说明
流程 相关说明 开始不成功运营人员登录后台运营人员登录后台：运营人员登录后台，登录成功，则进入后台录入、修改、删除、下线、发布相关信息。 成功登录不成功则重新登录，直到登录成功为止。不成功的原因包括用户名、密码不正确。 上传相关信息失败发布相关信息上传相关信息：运营管理人员可上传、修改相关信息的名称、介绍等内容。 产品上传不成功则重新上传，上传不成功包括文字超过限制，图片大小，质量等规格不符合限条件成功展示在APP中完成 等内容。 发布相关产品：运营管理人员可发布相关信息，发布后该信息显示在APP中。 ➢ 后台管理
网站应具有操作简便、使用高效的内容管理系统（CMS），网站管理员能够开设多个管理员帐户，为每个管理员分别设置管理权限，系统根据权限自动为某个管理员
9
配置管理后台，后台只允许该管理员管理其具有管理权限的栏目。这样使整个网站运行起来有条不紊，做到专人专职，责权分明，管理高效。
技术要求
1. 页面应支持800*600及以上分辨率，充分考虑IE和其他浏览器兼容问题； 2. 页面应符合XHTML 2.0及WEB 2.0标准，所有样式均采用CSS2.0标准，不可出
现垃圾代码；
3. 页面最大K数为100K，图片及其他多媒体文件大小也应限制在较小范围内； 4. 通常情况下，客户访问速度在1秒内，正式上线前须通过W3C的检测； 页面采用静态页面和动态JSP相结合方式。对于经常需要更新的项目，采用数据库动态发布及修改，一般页面采用静态即可，使网站能很好适用.
设计要求
➢ 符合国家的有关规定、标准
➢ 方案设计要体现面向用户的整体解决方案 ➢ 软件开发须遵循软件工程规范 ➢ 系统的安全性高 ➢ 系统的扩展性强 ➢ 强大的检索引擎功能 ➢ 操作简单 易用性强
高度的模块化设计
采用高内聚、低耦合原则进行模块划分。模块间提供相应的接口，当系统的业务或功能要求发生变化时，可以通过简单的对相应模块的修改来实现功能扩展。 多层体系结构
多层体系结构分为客户端、应用服务器和数据库服务器。其中，客户端提供统一的用户界面，完成对用户请求的收集与结果显示；应用服务器主要是处理用户请求，实现应用系统功能；数据库服务器则是为应用服务器提供数据。基于这样的体系结构，更有利于功能扩展与修改。
10
2.1.7 容错性设计
系统的容错性设计是指设计软件时能够保证用户输入的正确性和对系统非法的和破坏性的输入有很强的容错能力。当用户进行正常的数据输入时，系统对输入的数据要做有效性检查和完整性检验，保证将正确的数据存入数据库，对于用户错误的输入，不但拒绝接受，而且要给出明确的错误提示，供操作者改正；对于用户输入非法的和对系统具有破坏性的数据，系统能够加以识别，并做出相应的处理，避免造成系统的死机和瘫痪。
2.1.8 快速恢复设计
在系统使用过程中，由于硬件出现故障或其它原因造成系统暂时性的中断后系统重新启动时，能够保证系统将原有的数据快速恢复，使继续运行下去。在数据库设计时，有软件自动（默认）或人工对重要的数据进行定期的备份，并做有备份日志，系统的功能中专门设计数据备份和恢复功能，使用户能够快速地自动地将数据从故障处恢复。
在系统正常运行时，定期地将数据库中的数据备份到磁带机，在系统硬盘里保存一段时间内的数据（如5年），如果超出这个时间区段，则将超出时间区段的数据全部导出到磁带机上保存，避免数据库里的数据过于庞大，也保证数据的安全。当用户查询以前的数据超出当前硬盘存储的数据范围，则随时从磁带机中调出相应时间段的数据库供使用。
建设原则 1、扩展性
系统应便于新业务的生成和实现供动态页面定制工具，能够有效的帮助生成数据表单，方便管理人员扩充分类目录等信息，并在权限管理、会员管理上有高度的灵活性。 2、安全性
在系统规划和设计时应充分考虑系统安全性问题，防止非法操作和恶意入侵造成
11
系统灾难，给使用平台的企业带来损失，对应用软件进行安全设计、数据库安全设计、网络安全设计来提高网站的安全性，。 3、先进实用
系统规划和设计理念可对照现有技术先进、成熟的产品，提高用户体验，以减少系统开发的周期和成本；功能定位充分考虑平台服务对象的需求。 4、扩充性
保证已有平台和系统的兼容性及对未来发展的适应性，使系统可在原有的基础升级改造和更新，并应当充分考虑技术进步因素的影响。 5、开放性
在网站建设中应充分考虑与外界信息系统交换的需求，保证既能满足基本功能的需要，有具有与外界系统进行信息交换与处理的能力。 6、可靠性
公司提供365×24×7不间断服务，在系统规划和设计时充分考虑系统可靠性问题，采用备份方案或其它管理和技术手段提高系统可靠性，避免由于系统崩溃而造成灾难性后果。
12
因篇幅问题不能全部显示，请点此查看更多更全内容