1 系统概述
1.1编写目的
针对智能养老APP的研发，目的是对该产品进行详细设计，在需求分析的基础上进一步明确系统结构，详细地介绍系统的设计思路、各类架构及数据库设计等，为该产品的开发、测试提供设计参考以及为进行后续的设计和完善提供方便。
1.3产品目标
本APP的目标用户是年龄到一定程度的父母和子女，其中父母方面可能由于某些特殊原因并不能熟练使用智能手机中繁复的APP界面。
因此需要满足以下目标：
（1）产品能够提供友好的用户界面，使操作人员的工作量最大限度的减少。
（2）产品具有良好的运行效率，及时进行信息反馈，不因为卡顿等其他技术方面的问题影响用户的体验感。
（3）产品的整体风格要契合用户审美，设计过程中代码的重用性要高。
1.4设计约定
四种适用于不同尺寸设备屏幕的方案
- 超小屏幕 手机 = 750px
- 小屏幕 平板 = 720px
- 中等屏幕 桌面显示器 = 940px
- 大屏幕 大桌面显示器 = 1140px
2 概要设计
2.1设计思路
根据系统需求分析报告，进行系统设计。根据相关功能要求，结合实际条件，具体设计实现逻辑模型、物理模型以及最终系统。
系统设计包括总体设计和模块设计。按功能不同进行技术层次划分，使各层功能相对独立。同时以接口形式来描述各层之间的调用关第，以达到层次之间的松散耦合。各层所提供功能不依赖于一种具体的技术或产品实现，应该提供一定范围的技术选择。技术架构不和具体的应用架构绑定，应具备较宽的使用范围，适合未来应用的扩展。
成果将以系统设计说明书为主。
2.2功能设计
根据需求分析说明书，“牵伴”分为父母版本、子女版本和管理员管理。
父母版本有3个主要模块，分别是：账户管理模块（个人注册、个人登陆、注销）、亲情互动模块（查看子女动态、语音交流）、收听电台等功能模块。
子女版本有6个主要模块，分别是：账户管理模块（个人注册、个人登陆、注销）、亲情互动模块（上传照片、语音交流、闹钟设置）、GPS定位模块（最新位置、历史轨迹）、论坛模块（发帖、评论）、推文模块（查看推文、历史推文）、其他模块（用户通知、意见反馈、检查更新、关于我们）等功能模块。
管理员版本有5个主要模块，分别是：用户管理模块（添加用户、搜索用户、修改用户信息、删除用户）、管理员管理模块（添加角色、修改角色信息、删除角色、权限管理）、推文管理模块（添加推文、搜索推文、删除推文等）、用户通知模块、系统管理（图片管理、数据字典）。
2.2.1用例描述
1、父母用例
图2.2.1.1 参与者父母用例图
参与者父母表示使用“牵伴”的老年人群体。
2、子女用例图
图2.2.1.2 参与者子女用例图
参与者子女表示使用“牵伴”的子女群体。
3、管理员用例图
图2.2.1.2 参与者管理员用例图
参与者管理员表示 “牵伴”的后台管理员。
2.2.2功能视图
1、父母用例
图2.2.2.1 父母用例图
父母用例图由1个参与者“父母”和8个不同用例组成。其中账户管理包含个人注册、个人登陆和注销，亲情互动包含查看子女动态和语音交流，收听电台不包含任何用例。
| 功能模块 | 功能名称、标识符 | 描述 |
| 账户管理 | 个人登录 | 用于用户登陆。 |
| 个人注册 | 用于新用户注册。 | |
| 用户注销 | 用于用户注销。 | |
| 亲情互动 | 查看子女动态 | 父母可以查看子女上传的照片。 |
| 语音交流 | 父母可以跟子女进行语音交流。 | |
| 收听电台 | 收听电台 | 父母用于收听电台、广播等节目。 |
2、子女用例图
图2.2.2.2 子女用例图
子女用例图由1个参与者“子女”和22个不同用例组成。其中账户管理包含个人注册、个人登陆和注销，亲情互动包含上传照片、语音交流和闹钟设置，GPS定位包含最新位置和历史轨迹，论坛包含发帖和评论，推文包含查看推文和历史推文，其他包含用户通知、意见反馈、检查更新和关于我们。
| 功能模块 | 功能名称、标识符 | 描述 |
| 账户管理 | 个人登录 | 用于用户登陆。 |
| 个人注册 | 用于新用户注册。 | |
| 用户注销 | 用于用户注销。 | |
| 亲情互动 | 上传照片 | 子女可以上传照片给父母看。 |
| 语音交流 | 子女可以跟父母进行语音交流。 | |
| 闹钟设置 | 子女可以设置闹钟提醒父母吃药等。 | |
| GPS定位 | 最新位置 | 子女可以查看父母最新的位置信息。 |
| 历史轨迹 | 子女可以查看父母走动的历史轨迹。 | |
| 论坛 | 发帖 | 子女可以在论坛发帖交流赡养父母的心得。 |
| 评论 | 子女可以评论交流赡养父母的心得。 | |
| 推文 | 查看推文 | 子女可以查看父母相关的美文。 |
| 历史推文 | 子女可以查看历史推文。 | |
| 其他 | 用户通知 | 用户可以查看系统通知。 |
| 意见反馈 | 用户可以反馈对“牵伴”的意见。 | |
| 检查更新 | 用于系统更新的检查。 | |
| 关于我们 | “牵伴”及开发团队介绍。 |
3、管理员用例
图2.2.2.3 管理员用例图
管理员用例图由1个参与者“管理员”和22个不同用例组成。其中用户管理包含添加用户、搜索用户、修改用户信息和删除用户，管理员管理包含添加角色、修改角色信息、删除角色和权限管理，推文管理包含添加推文、搜索推文和删除推文，系统管理包含图片管理和数据字典，用户通知不包含任何用例。
| 功能模块 | 功能名称、标识符 | 描述 |
| 用户管理 | 添加用户 | 用于管理员添加新用户。 |
| 搜索用户 | 用于管理员搜索用户信息。 | |
| 修改用户信息 | 用于管理员修改用户信息。 | |
| 删除用户 | 用于管理员删除用户信息。 | |
| 管理员管理 | 添加角色 | 用于管理员添加新角色。 |
| 修改角色信息 | 用于管理员修改角色信息。 | |
| 删除角色 | 用于管理员删除角色信息。 | |
| 权限管理 | 用于管理员对各角色进行权限的管理。 | |
| 系统管理 | 图片管理 | 用于管理员对系统内图片进行管理。 |
| 数据字典 | 用于管理员对系统内数据进行管理。 | |
| 推文管理 | 删除推文 | 管理员可以删除已发出的推文。 |
| 添加推文 | 管理员可以发送新推文。 | |
| 搜索推文 | 管理员可以搜索已发出的推文。 | |
| 用户通知 | 用户通知 | 对用户进行系统通知。 |
2.3逻辑架构
系统逻辑架构设计如下图：
图2.3 逻辑架构图
系统的逻辑架构由用户层、门户层、代理层、应用层、管控层、计算存储层共6 层组成。管控层和计算存储层构成了系统的平台层，应用层的主要功能是支撑系统业务应用的开发和各子节点的后台管理。
（1）用户层
用户层是所有访问大数据系统的用户集合，根据用户职能的不同，大数据系统的用户可划分为3 类：普通人员、分析人员和系统管理人员。
（2）门户层
门户层是用户访问大数据系统的统一入口，用户经应用层管理系统统一认证后，门户子系统按照用户身份的不同分别提供相应的个性化门户，用户只能查阅和操作系统授权的数据信息和应用功能。
（3）代理层
代理层是门户层和应用层各应用系统之间的统一代理，代理层由统一代理子系统构成。统一代理子系统由统一用户管理、统一应用资源管理、统一权限管理三个核心模块构成。代理层向门户层开放出WebService 服务，供门户层的系统调用。当WebService 服务接收到门户层发来的请求信息时，会向应用层的应用系统发出调用请求。
（4）应用层
应用层由数据应用类、数据采集类、后台管理类三类子系统构成。应用类子系统包括MR 定制子系统、Pig 分析子系统和Hive 数据仓库子系统，主要为普通用户和分析人员提供大数据分析和挖掘服务。数据采集类子系统包括Chukwa 采集子系统和数据抓取子系统，主要是从企业现有系统、大数据应用系统和外部应用系统中采集数据并存储在大数据系统中。后台管理类子系统主要是对大数据系统的用户信息、节点设备信息和节点运行状态进行管理。
（5）管控层
管控层主要由NameNode 子系统、JobTracker 子系统、HBase 的Master 子系统、ZooKeeper子系统和SecondNameNode 子系统构成。
NameNode 子系统是HDFS 系统的重要组成部分，主要提供目录和文件的元数据管理，是分布式文件读写的统一入口。SecondNameNode 子系统是其备份子系统。
JobTracker 子系统是分布式作业系统的重要组成部分，是MapReduce 分布式程序的服务器端，主要是对作业的任务进行调度分配和运行状态的管理。
HBase 的Master 子系统是HBase 系统的主要组成部分，它主要负责引导初始安装，为Region 域数据分别注册到HBase 集群中的域服务器HRegionServer，监控HRegionServer 的运行，并在出现故障时进行恢复。
ZooKeeper 子系统主要是为HMaster 和HRegionServer 提供共享信息的统一协同服务。
（6）计算存储层
计算存储层由HDFS 系统的DataNode 和分布式作业系统的TaskTracker 组成的子系统、HRegionServer 子系统和关系型数据库管理子系统构成。
HDFS 系统的DataNode 和分布式作业系统的TaskTracker 组成的子系统共同部署在一个机器节点上，为分布式文件提供数据块存储和数据块计算服务。
HRegionServer 子系统主要是为客户端提供分布式数据库系统的访问服务。
关系型数据库子系统主要是存储应用层后台管理系统和Hive 数据仓库系统提供用户信息、机器设备信息、元数据、运行状态监测信息的存储服务。
2.4 物理架构
物理架构的目的是确定物理节点和物理节点的拓扑结构；其中物理节点包括服务器、PC机、专用机、软件安装部署以及系统软件的选型；拓扑结构明确物理节点的关系。本软件采用的物理架构如图：
图2.4 物理架构图
2.5开发架构
本次开发使用经典的三层架构，即表示层(UI)、业务逻辑层(BLL)和数据访问层(DAL)。其中表示层(UI)是向用户展现特定业务数据，采集用户的输入信息和操作。本着用户至上，兼顾简洁和不包含任何业务相关的逻辑处理这一原则；
业务逻辑层(BLL)是从DAL中获取数据,在UI显示,从UI中获取用户指令和数据,执行业务逻辑或通过DAL写入数据源，本层作为U层与Ｄ层的桥梁,目的在于展现清晰的函数结构,只负责数据处理传递,不涉及SQL语句和ADO.NET;数据访问层(DAL)是直接操作数据库，针对数据的增添 删除、修改、查找，具体为业务逻辑层或表示层提供数据服务；这一层是专门操作数据库,不考虑数据合法性.数据库错误返回－1,逻辑错误返回0,并告知错误原因,成功返回1。分层架构如下：
图2.5开发架构图
2.6运行环境设计
硬件环境：
1） 客户机：普通Android手机
l Android Version: Android 4.0以上
l Memory ：1024MB以上
l 分辨率：推荐使用768*1280-320dpi
l Data disk capacity：8192MB以上
2） Web服务器
l CPU： P4 2.4GHz
l Memory ：1GB以上
l HDD：80GB以上
l 网卡：KMb/s速度网卡
3） 数据库服务器
l CPU： P4 2.4GHz
l Memory ：1GB以上
l HDD：80GB以上
软件环境是指操作系统，数据库系统以及一些开发工具的选用。本系统开发所需要的软件环境如下：
操作系统：Windows2000或以上版本
数据库：MySQL5.6
开发工具包：JDK Version 1.7
开发环境：MyEclipse6.0
Web服务器：Tomcat7.0
浏览器：IE6.0或以上版本
2.7架构设计
2.7.1系统分层
项目分为了四个层级：模型层、接口层、核心层、界面层。模型层定义了所有的模型；接口层封装了服务器提供的API；核心层处理所有业务逻辑；界面层就处理界面的展示。几个层级之间的关系如下图所示：
图1.1系统分层图
2.7.2系统包、资源规划的准备工作
（1）服务器端的开发：
图1.2.1服务器端架构设计
相关包及主要类如下：
com.znufe.qianban.action包：负责响应手机端发出的请求。该包下共有6个action，类及类的功能如下：
UsersAction.java负责用户登录请求；
MessageAction.java负责语音及闹铃类的请求，请求分别为添加语音、闹铃以及查询。
ImageAction.java负责图片类的请求，请求分别为添加图片和图片查询。
LocationAction.java负责地理位置类的请求，请求分别为最新位置信息查询以及历史路线信息查询。
ForumAction.java负责帖子及评论类的请求，请求分别为添加帖子及评论及查询帖子和评论列表。
NotifyAction.java负责通知类的请求，请求系统通知列表。
com.znufe.qianban.biz包：负责业务处理。该包下的类及类的功能如下：
UserBIZ.java负责用户的业务处理，该类有负责用户登录UserLogin()和注销UserLogout()的方法；
MessageBIZ.java负责语音及闹铃的业务处理，该类有四个方法，分别是根据用户名及接收人获取语音列表getVoiceListByURid()和添加新语音addVoice()的方法,和根据用户名（子女）获取闹铃列表getClockListByUid()和添加闹铃addClock()的方法；
ImageBIZ.java负责图片的业务处理，该类有根据用户名（子女）获取图片列表getImageListByUid()和添加新图片addImage()的方法；
LocationBIZ.java负责地理位置信息的业务处理，该类有根据用户名（父母）和时间查询信息getLocationByUT()的方法；
ForumBIZ.java负责论坛的业务处理。该类有根据发帖人获取帖子列表getPostBySend()和根据标题获取帖子列表getPostByTitle()和getAllPost()以及添加新帖子addPost()根据帖子编号获取评论列表getCommentByPid()和添加新评论addComment()的方法等；
NotifyBIZ.java负责系统通知的业务处理。该类有获取所有系统通知getAllNotification()的方法。
com.znufe.qianban.dao包负责数据处理，主要是对数据库的操作。共有6个DAO，命名分别为UsersDAO，MessageDAO，ImageDAO，LocationDAO，ForumDAO，NotifyDAO。
（2）客户端开发：
图1.2.2客户端架构设计
相关包及类的内容如下：
com.znufe.qianban.entities包包含本项目涉及的实体类。
子女用户类SonsUser.java，属性有cname是子女的用户名、cpwd是子女的登录密码、ctel是子女的联系方式、csex是子女的性别、cage是子女的年龄、cimg是子女的头像；
父母用户类ParentsUser.java，属性有pname是父母的用户名、ppwd是父母的登录密码、ptel是父母的联系方式、psex是父母的性别、page是父母的年龄、pimg是父母的头像、padd是父母的地址、pbirth是父母生日的时间；
管理员类Admin.java属性有aname是管理员用户名、apwd是管理员密码；
闹钟类Clock.java，属性clday是星期几、clhour是小时、clmin是分钟；
消息推送基类ReqBaseMessage.java，属性有tousername，fromusername，creattime，messagetype，msgid；
图片消息ReqImageMessage.java继承基类ReqBaseMessage.java,属性有图片链接picurl；
地理位置消息ReqLocationMessage.java继承基类ReqBaseMessage.java，属性有纬度location_x,经度location_y，地图缩放大小scale，地理位置信息label；
语音消息ReqVoiceMessage.java继承基类ReqBaseMessage.java,属性有语音识别码MediaId，语音格式format；
推文Tweets.java继承基类ReqBaseMessage.java,属性有标题twtitle；
评论Comments.java继承基类ReqBaseMessage.java；
系统通知消息Notification.java继承基类ReqBaseMessage.java；
帖子Posts.java，属性有pmtitle是贴子标题，pmsendid是发帖人id，pmtime是发帖时间，pmcontent发帖内容。
com.znufe.qianban.utils包提供了客户端所用到的工具类，有编码转换类CodeUtil.java，客户端请求服务端的类ConnectWeb.java。
com.znufe.qianban.activity包包含了本项目中出现的窗体类。
欢迎窗体类Welcome.java，登录窗体类ViewLogin.java，注册窗体类ViewSignUP.java，主窗体类ViewMain.java，聊天窗体类ViewMessage.java，闹铃列表窗体类ClockListView.java，闹铃详情窗体类DetailClockView.java，添加老人窗体类AddOlderView.java,，照片列表窗体类ImageListView.java，地理信息窗体类ViewLocation.java，帖子列表窗体类PostListView.java，帖子详情窗体类PostDetailView.java，评论列表窗体类CommentListView.java，电话列表窗体类PhoneListView.java。
3 详细设计
3.1 流程设计
1、用户总体业务流程
首先启动系统，用户进行登录，系统对用户的用户名密码进行验证，通过后用户进入系统，可对系统进行相应操作，最后退出系统，流程结束。流程图如下：
图3.1.1用户总体业务流程
2．用户注册流程
...
...
...
3.2功能设计
3.2.1模块设计
1、父母版本模块设计
图3.2.1.1父母角色功能
父母版本有3个主要模块，分别是：账户管理亲情互动和收听电台。在账户管理模块中，用户进入账户界面，新用户先注册再登录。在亲情互动模块中，父母可以查看子女发布的照片同时也可以进行语音交流。在收听电台模块中可以进行电台收听，避免无聊。
2、子女版本模块设计
...
...
...
3.2.2界面设计
1、用户注册登陆
图3.2.2.1.1 用户登陆界面
下载APP后，打开“牵伴”APP后出现该界面，新用户点击注册按钮进行注册，已注册过的用户点击登录进行登录。
图3.2.2.1.2 用户角色选择界面
点击注册按钮，跳转到角色选择界面，进行角色选择，选择“我是父母”或者“我是子女”。
图3.2.2.1.3 父母注册界面
选择父母角色进行信息填写，填写完成后点击完成注册。
图3.2.2.1.3 子女注册界面
选择子女角色进行信息填写，填写完成后点击完成注册。
2、父母版本界面
图3.2.2.2.1 父母版本主界面
上图是父母角色功能界面，包含打电话、听电台、查看动态和实时聊天等功能。
图3.2.2.2.2 查看日历界面
点击日历按钮，可以看到今日日期。
图3.2.2.2.3 一键通讯界面
点击电话图标，可以与已预存的联系人“一键通讯”。
图3.2.2.2.4 添加号码界面
点击添加号码，可以进行号码添加。
图3.2.2.2.5 语音聊天界面
点击聊天图标，可以与子女语音聊天。
图3.2.2.2.6 查看子女动态界面
点击图片图标，可以查看子女上传动态。
图3.2.2.2.7 电台界面
点击FM图标，可以实时听广播。
...
...
...
6 接口描述
6.1百度地图接口
名称：百度地图API
说明：百度地图API是为开发者免费提供的一套基于百度地图服务的应用接口。
定义：此百度地图API为Android版，为Android设备地图应用开发提供基本地图、定位等服务。用户使用该套SDK，需要先申请key。
6.2闹钟接口
名称：AlarmManager
说明：在Android系统中，闹钟和唤醒功能都是由Alarm Manager Service控制并管理的。
定义：此API为Android系统的Framework层把底层细节做了封装并统一提供的API，为Android设备的应用开发提供设置一次性闹钟或重复闹钟等服务。
6.3相册接口
名称：UploadFileServlet
说明：在Android系统中， UploadFileServlet为图片上传接口（Servlet实现）支持参数和多张图片的上传。
定义：此API为Android系统应用程序层本身就集成的API，为Android设备的应用开发提供上传照片等文件的服务。
6.4 通讯接口
名称：SendCallClickListener
说明：在Android系统中，打电话功能都是由SendCallClickListener控制并管理的。
定义：此API为Android系统应用程序层本身就集成的API，为Android设备的应用开发提供打电话的服务。用户使用时应在AndroidManifest.xml中进行权限配置：<uses-permission android:name="android.permission.CALL_PHONE" />
7 出错处理设计
7.1 错误异常处理机制和原则
由Try代码块保护的代码所发生的任何异常，甚至包括在不含Try代码块的被调函数或方法以内的异常都将被Catch代码块内的代码处理。当然，除非catch代码块自己也扔出了异常，而在这种情况下异常会被扔到下一个级别更高的try代码块，哪怕那意味着从当前正在执行的函数中扔出异常。
异常的4条重要规则：
- 如果catch块有若干个，那么异常将根据其类型被扔给最适当的一个catch接受处理。
- 如果没有找到可接受的catch块，则异常被从当前的try块扔到从调用顺序链中找到的下一个可用的catch块。
- 异常对象的类型给出了发生错误本质的重要信息。
- 异常可以通过throw关键词显式扔出。
代码就可以选择性地只处理那些有能力处理的错误，同时相信其他问题都会统统交给调用堆栈，哪怕至少作为通知处理。在实际应用中，因为让CLR观察扔出的异常对性能有一定的影响，所以使用单个try块同时对应多个特殊异常的catch语句是检查代码多个特定错误的最佳方式。
根据系统应用，常见错误异常分为数据存储部分，应用部分，核心库部分，商业层部分。
数据存储部分：主要系统在与数据库产品交互时，常见的一些错误。比如数据库连接错误，数据库对象不存在或数据字符过多。
应用部分：主要是反映用户在键盘输入操作时，可能引起的数据类型错误，字符长度超过限制等，使用鼠标或键盘可能引起的操作错误等。
核心库部分：主要反映系统框架中的一些错误。比如数组下标越界，数字超出范围等。
商业层部分：主要反映系统中的一些如权限被拒绝,输入参数错误等。
7.2 出错信息
在软件系统的开发过程中，需要对软件中存在的漏洞立即进行处理，即使一个很小的漏洞，也会造成整个软件开发系统的垃圾资源无限增多，最终可能会导致系统的瘫痪。因此在系统设计中，对拟开发系统要注意数据的约束性。为了进行数据统一收集和规范数据统一格式方便管理者的处理，针对安全隐患，本项目组进行了统一约束规范。同时，项目组也应该解决服务器端的信息安全问题，这样才能更好的运用管理系统，从而减少系统的维修次数，确保系统的安全使用。
图7.2 出错图
对于客户端不符合系统设计预期的错误输入，应该在客户端给以提示，以避免错误的请求数据对后端产生影响。而对于服务端可能产生的异常或错误，系统应该以有好的方式告知用户，不应直接将系统抛出的异常信息等呈现给用户。
具体如下表所示：
表7.2 错误表
| 错误层次 | 错误类型 | 解决方案 |
| 客户端错误 | 用户输入与数据类型不相符的数据 | 客户端以有好的方式提示用户对输入数据进行检查 |
| 无网络连接 | 提示用户恢复网络连接 | |
| 重复注册或空登陆 | 提示用户用户名不存在或者用户已注册 | |
| 用户名和密码出错 | 提示输入不正确，检查信息是否正确，并返回 | |
| 验证码输入错误 | 登陆失败，应重新输入 | |
| 密码与确认密码不同 | 提示密码与确认密码不同 | |
| 提交信息失败 | 提示失败信息，并建议检查错误信息类型 | |
| 联系方式具有的格式输入错误 | 提示不是其所拥有的格式，重新输入 | |
| 标题为空，或标题大于规定字数 | 提示标题不能为空且应该小于X字，应重新输入 | |
| 服务端错误 | 数据库连接失败 | 及时恢复数据库连接 |
| 服务器访问压力过大 | 采取服务器负载均衡技术，同时调整服务器性能 | |
| 程序运行中抛出的异常信息 | 将请求数据和错误异常记录到Log日志，同时告知客户端 | |
| 不合法的URL请求 | 提示错误，返回登录界面，Struts的请求错误控制 | |
| 数据访问量过大 | 返回请求失败信息，针对需求重新选择服务器 |
7.3 补救措施
所有的系统，不管采用哪种开发方式，都不可避免的存在弱点。所以不但在信息管理系统这一级而且在计算中心这一级(如果适用，也包括远程设备)都要审核并提出设计到安全性的问题。通过识别系统的弱点来减少侵犯安全性的危险，以及采取必要的预防措施来提高安全水平，这是用户和信息服务管理部门可做得到的。
（1）后备技术
由于现代计算机科学技术的快速发展，以往的数据备份已经不能满足用户和管理者对现有系统的要求，现在的技术一般是进行系统数据库的实时备份和备份服务器。当数据库瘫痪时，通过快速进行系统库的切换，这样可以有效的减少数据的丢失。当用户量大时，也可以使用备用服务器，两个服务器进行同步数据存储，如果一台服务器出错时，可以转换到另一台进行相同的操作，让用户不需要因瘫痪而面临网页打不开、数据丢失等相关问题。
（2）降效技术
通常情况下系统的管理员都不是专业的计算机人员，对计算机专业的知识了解相对较少。在面对系统瘫痪等错误时，都不知道如何去解决问题。如今，随着计算机科学技术的飞速发展，为了让系统用户能够自行解决运行过程中遇到的问题，大多采取小型服务器作为后备技术。这项技术在现有的开发系统中使用很广泛，当然备用的服务器从价格上考虑，可能不如主服务器，也可能会降低工作效率，但是从数据的完整性和安全出发，可以让维修人员有更多时间进行系统的维护。
（3）恢复及再启动技术
由于采取的是低端服务器，同时进行数据库的实时备份。这样在系统维护好完成后，可以很快的进行数据同步，同时也可以很快的进行系统的运行。
7.4 系统维护设计
信息管理系统不同于其他系统，它并不是一劳永逸的最终系统。在它的运行过程中，还有大量运行管理、系统维护、系统设置等工作要做。交付使用的信息管理系统跟工业产品不同，工业产品可以先生产一个样品，经过试验、改进再正式投入批量生产，而信息管理系统它需要在用户使用过程中不断完善。系统维护包括程序的维护、数据文件的维护、代码的维护等，而且系统的修改，往往会造成系统程序、文件、代码的修改。因此，系统的修改必须通过批准。
完整方案及源码地址：
174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
