学生宿舍分配系统系统设计说明书剖析

第一篇：学生宿舍分配系统系统设计说明书剖析

系统设计说明书模板 1.引言 1.1 编写目的

本设计说明是在学生宿舍分配软件需求规格说明书的基础上，详细描述系统的概要设计结果，作为详细设计的基础资料，为系统开发人员提供设计和开发依据。

1.2 背景

a.待开发的软件系统的名称：学生宿舍分配系统 b.本项目的任务提出者：宿舍管理中心 c.本项目的任务开发者：学校技术人员

d.本项目的任务用户：学生、班主任、辅导员、宿舍负责人、校领导、院领导。

1.3 术语

本文当中涉及的专业术语定义或解释，一般用表格形式给出，如表2-1所示。表2-1 术语定义或解释表

1.4 参考资料

学生宿舍分配系统需求规格说明书

马小军 张玉祥，《软件开发实训教程》，中国人民大学出版社，2015年8月

2.系统总体设计 2.1设计约束

2.1.1本系统应遵循的标准和规范

易用性、高效性、可靠性、可扩展性、安全性 2.1.2软硬件运行环境约束 Windows XP/win7/win8, Sql server 2008数据库 数据库服务器一台，CPU:Pentium900M，内存容量>512M 2.1.3接口约束 数据库访问接口

2.1.4用户界面约束 交互方式：人机交互

界面空间尺寸：可随浏览器大小自行调整 硬件级网络带宽：校园网带宽>10M 2.2体系结构设计

（系统的体系结构模型，如下）

2.3系统功能结构 主功能清单

2.4模块设计

2.4.1 学生住宿申请子系统——填报申请模块程序设计 2.4.1.1功能描述 学生在线填写住换宿申请，填写后提交。该模块提供住换宿申请的保存和提交功能。2.4.1.2性能 提交时间<1s 2.4.1.3输入项

住宿申请表内容包括：姓名、学号、性别、学院、班级、家庭地址、联系电话、电子邮件、申请日期、特殊说明。

2.4.1.4输出项

提交状态的宿舍申请表 2.4.1.5流程逻辑与算法描述（住宿申请顺序图，如下）

2.4.1.6接口 数据库访问接口 2.4.1.7单元测试计划 按照住宿申请顺序图即程序执行流程设计测试用例

2.4.2 学生住宿申请子系统——申请查询模块程序设计 2.4.2.1功能描述 针对学生在线提交的住换宿申请，实现申请书所处状态的具体查询并显示查询结果。2.4.2.2性能 提交时间<2s 2.4.2.3输入项 学号 2.4.2.4输出项

住宿申请表审核或批准的状态。2.4.2.5流程逻辑与算法描述(申请查询顺序图，如下）

2.4.2.6接口 数据库访问接口 2.4.2.7单元测试计划 按照申请查询顺序图即程序执行流程设计测试用例

2.4.3 辅导员审核子系统 2.4.3.1 功能描述 实现辅导员对接收到的学生住宿申请进行审核意见标注的操作 2.4.3.2 性能 审核提交时间<1s 2.4.3.3 输入项 学生住宿申请表 2.4.3.4 输出项 审核后的的住（换）宿舍申请表 2.4.3.5 流程逻辑与算法描述（辅导员审核顺序图，如下）学生 住（换）宿舍申请查询界面 住（换）宿舍申请审核界面 住（换）宿舍申请书 数据库 辅导员编号 查询辅导员负责班级的住宿申请表 显示全部申请 查询提交状态的申请 显示列表结果 选择列表中申请 查询结果列表 查询未审核的住宿申请列表 查询结果列表 调取申请表详情 申请表详情 查询 查询结果 调用审核界面 置审核标记 持久化 审核完成 返回成功 返回，关闭审核界面 标注审核信息 刷新页面 审核完成，退出 界面关闭

2.4.3.6 接口 数据库访问接口 2.4.3.7 单元测试计划 按照辅导员审核顺序图即程序执行流程设计测试用例 2.4.4 宿舍负责人工作子系统——批准住宿模块程序设计

2.4.5 宿舍负责人工作子系统——住宿统计程序设计 2.4.6 公共服务子系统——用户登录模块程序设计 2.4.7 公共服务子系统——住宿查询模块程序设计 2.4.8 系统管理子系统——用户管理模块程序设计 2.4.9 系统管理子系统——基础信息维护模块程序设计 3．数据结构设计（详细类图，如下）

用户 +用户 : string +用户编号 : string +用户类型 : char-口令 : string-有效标记 : bool +增加用户(: string +修改信息(+删除(-修改口令(教师-所在学院 : string 宿舍管理人员 系统管理员 领导 班主任-管理班级 : string 1 * 辅导员 +管理班级 : string 1 班级-班级编号 : string +班级信息维护(1 * 学生 1 * * * * 1-所在班级 : string * 1 宿舍负责人 宿舍管理员 校领导 院领导-所在学院 : string * 1 住宿记录-学生姓名-班级-床位号-房间号-楼号-宿舍名称-入住日期 +增加(+维护(+查询(+统计(* 1 * 宿舍检查记录 0..* 0..* 0..*-检查地点-检查内容-记录人 +新增(+维护(设备-所在房间-设备名称-设备编号-使用者 1* +新增(+维护(* 0..* 1 住（换）宿舍申请-申请人姓名 : string-联系方式 : string-家庭住址 : string-辅导员审核意见 : char-宿舍负责人批准意见 : char-辅导员姓名 : string-宿舍负责人姓名 : string +新建(+保存(+提交(+审核(+批准(床位 *-所在房间-床位号 +新增(+维护(0..* 1 * * 1 楼栋-楼号 +新增(+维护(1 房间-房间号-朝向-床位数 +新增(+维护(*1 0..* 宿舍-名称 : string +新增(+维护(

第二篇：留言板系统 设计说明书

留 言 板 系 统 设 计 说 明 书

电商141 魏巍 2016.06.2

4本留言板系统基于Windows操作系统平台，web服务器为IIS，数据库服务器为Microsoft access。

其工作流程为：所有人都可以在该系统留言，并且能查看留言，管理员在通过登录验证后，可以发表留言，查看留言，并且能对用户的留言进行回复和删除。

该留言板具有的主要功能如下：

1、可以按照留言的id进行排序；

2、友好简洁的管理界面，便于管理员维护留言板；

3、管理员具有回复和删除留言的权限；

4、管理员可以修改留言板页面的名称和网址以及每页显示的留言数；

5、拥有更多留言者的信息，包括昵称、主题、邮箱等；

6、具有防止留言客户非法进入管理界面功能；

一、利用Microsoft access创建一个数据库liuyanban.mdb并建立两个数据库表，一个是留言信息表liuyan，另一个是用来存放用户账户和密码信息的表user

二、在编写ASP脚本进行数据库操作前，必须先给数据库建立一个基本ADO对象的连接，代码如下：

三、建立一个留言板首页index.asp，所有用户都可以进入此系统，可以看到留言的主题、内容、留言的时间，还有留言被浏览的次数。这些信息都是来自于数据库liuyanban.mdb，此页面还可以连接到发表留言页面guestbok.asp和后台管理页面admin.asp

四、建立一个所有用户都可进入，用来留言的页面guestbook.asp，在页面内可输入留言主题，留言内容，留言者昵称，和电子邮箱，点提交以后，所输入的记录会显示在留言板首页index.asp，同时也会保存至数据库表liuyan中

五、建立一个管理员登录页面login.asp。对于一个留言板系统来说，必不可少的是管理员的登录系统，此系统只有管理员可以登录，普通用户无法登陆，用来管理留言。在输入正确的用户名和密码以后才可以进入到后台管理页面admin.asp，如果密码或用户名输入错误或者是未输入，则会由登录检验界面cklogin.asp检验后转入静态的错误提示页面error.html。如果点击此页面中的“放弃登录”，则而会跳转到留言板首页index.asp

六、建立登录检验界面cklogin.asp用于检验登陆的用户是不是管理员，如果不是，则会跳转至错误提示页面error.html

七、建立一个后台管理的系统admin.asp.在这个页面中，管理员可以直接看到每条留言的id，主题，内容，留言时间。点击每条留言记录后面“回复”链接到回复页面reply.asp，点击“删除”可以将这条留言直接删除掉，上方的“退出管理”可以直接跳转到留言板的首页index.asp

八、建立回复页面reply.asp便于管理员对留言进行回复，可以通过后台管理页面跳转到此页面，并且会在下方通过now（）函数显示回复的时间

九、建立删除界面del.asp，通过request对象取出数据库表liuyan中的id，在后台管理页面将留言信息删除后，直接跳转至留言板首页index.asp

十、建立一个静态的错误提示页面error.html，在管理员登录错误，或者非管理员用户登录时跳转到此页面用来提醒。

十一、有一个将记录写入数据库的文件save.asp，在发表留言的时候而将留言的信息写入到数据库liuyanban.mdb

第三篇：人事管理系统概要设计说明书范文

概要设计说明书

1． 引言

1．1 编写目的

在人事管理系统项目的前一阶段，也就是需求分析阶段中，已经将系统用户对本系统的需求做了详细的阐述，本阶段已在系统的需求分析的基础上，该文档的目的是描述企业人事管理系统项目的概要设计,其内容包括: 系统功能简介 系统结构设计 系统接口设计 数据设计 模块设计 界面设计

本文档的预期的读者是：

XX有限公司的领导

技术人员

XX有限公司的领导 相关项目组的所有成员

1．2 项目背景

国外企业关于人事信息的管理，主要是利用人力资源方面管理系统来实现的因为这类系统同IT、通信等领域技术的发展存在密切的联系，因此在计算机、网络等技术发展相对快的国家，基本上创建了一套人力资源管理系统，人力资源方面的信息能够在其本国范围内被授权查阅。无论人才流动到哪里，在人们进行求职、贷款以及办理保险之时，具备查阅权限的机构都能够查阅该人的信息，以衡量为该人办理有关手续的潜在风险，或者是否可以录用。

1．3 定义

1．3．1 专门术语

C/S：Client/Server客户机/服务器。

可修改性：容许对系统进行修改而不增加原系统的复杂性。

有效性：软件系统能有效地利用计算机的时间资源与空间资源的能力。

可适应性：软件在不同的系统约束条件下使用户需求得到满足的难易程度。可移植性：软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。主键：数据库表中的关键域。

1．3．2 缩写

系统：若未特别指出，统指本机票预定系统。

SQL: Structured Query Language（结构化查询语言）。ATM: Asynchronous Transfer Mode(异步传输模式)。

1．4 参考资料

以下列出在概要设计过程中所使用到的有关资料：

[1]韩万江 《软件工程案例教程》机械工业出版社 [2]李金勇 曹军生，《SQL sever 2000实用教程》，北京理工大学出版社 [3]林邓伟 等，《JAVA程序设计项目教程》，北京理工大学出版社 [4]孙峰，《数据库原理及应用》。天津大学出版社 [5]软件工程文档编制国际标准：GB8567—88 2． 总体设计

2．1 需求规定

数据库分析是数据库管理系统开发周期中的一个重要的阶段，也是工作量比较大的一 项活动。随着现代软件的发展，手工分析方式已经很难满足数据库管理系统数据库分析的要 求，必须借助相应的工具。

设计数据库系统时应首先充分了解用户各个方面的需求，包括现有的以及将来可能增

加的需求。用户需求具体体现在各种信息的提供、保存、更新和查询，这就要求数据库结构 能充分满足各种信息的输入和输出。通过对书店管理工作过程的内容和数据流程分析，设计 数据项和数据结构。

通过与企业的沟通和需求分析，要求系统具有以下功能。1.新员工资料的添加、修改、删除和查询。2.部门信息的添加、修改、删除和查询。3.自动分配员工编号和部门编号。

4.人事调动的详细记录，包括部门、职位和职称的调整，以及人员离职。

5.添加/修改日常出勤记录，这里重点实现可按全体员工、部门员工和所选员工添加/修改 日常出勤记录，以方便用户操作。员工日常公出/请假信息的添加、修改、删除和查询。每月工资信息的批量添加、修改、删除和查询。

2．2 运行环境

2．2．1 设备

1．Web服务器1台 2．数据库服务器1台 3．备份服务器1台 4．开发服务器1台

5．软件防火墙服务器1台 6．千兆路由器1台

7． 10M网络宽带1条

2.2.2 软件环境

本系统的的软件环境如下

1.My Eclipese 10开发工具 2．SQL Server2008数据库系统 3．Windows xp操作系统;4．防火墙，杀毒软件

2.3 基本设计概念和处理流程

概念模型是对信息世界的建模，所以概念模型应该能够方便、准确的表示出信息世界 中的常用概念。实体--关系模型（Entity-Relationship Module,简称E-R图）是数据库结构设计常用的方法。得到了数据项和数据结构以后，就可以设计出能够满足用户需求的各种实体以及它们之间的关系，为后面逻辑结构设计打下基础。这些实体包含各种具体信息，通过相互之间的作用形成数据的流动。根据需求分析和功能分析，规划出本系统中使用的数据库实体分别为员工实体，部门实体，工资实体，出勤实体，公出请假实体，人事调动实体，福利实体，员工离职实体等员工实体包括ID、编号、姓名、性别、身份证号、出生年月、年龄、民族、婚姻状况、政治面貌、如党团时间、籍贯、联系电话和手机号码等属性。员工实体E-R图如图2.1所示：

部门实体包括部门编号、部门名称、部门经理、部门地址和部门电话属性。

部门实体E-R图如图2.2所示：。

公出实体包括ID、所属工资月份、员工编号、员工姓名、基本工资、加班费、工龄工

资、全勤奖、奖励总额、职务津贴、请假扣除等属性。工资实体E-R图如图2.3所示：

2．4 结构

本系统的实现采用典型的三层模式、B/S结构来实现，不同的客户端程序共同访问中心数据库，系统结构如图1：

图1：系统结构

系统基本功能图解体系基本结构图

2.5功能需求与系统模块的关系 各项功能需求的实现同各个块程序的分配关系：

2.5.1登录页面

需要登陆的人员，对于不同的身份，他们的权限是不一样 的。当用户输入ID 和密码时，查询数据库，若用户名和密

码正确，则进入相应的员工信息页面，若不正确，则提示用户名或密码错误，人显示当前页面。

功能描述： 用户管理 配置管理 数据备份 数据维护 1.2.3.4.2.5.2员工注册 功能描述：

新员工注册，输入员工的注册信息，包括（登录账号，登录密码，核对密码，联系电话，联系地址，电子邮箱）。

注册信息的修改。

用例图

2.5.3员工的登录和登出

功能描述：

员工登陆

员工退出 用例图：

2.5.4信息查询 功能描述：

查看公司内部相关信息 查看个人信息

查看其他员工的部分信息 用例图

2.5.5人事档案

1增加员工档案信息 2修改员工档案信息

3删除员工档案信息 4查询员工档案信息

5打印员工档案信息 用例图

2.5.6工资信息管理 功能描述：

1.工资信息模块

2.计发工资信息

3.查询工资信息

4.保险/福利

5.打印工资信息 用例图

2.5.7员工培训 功能描述：

1.员工培训模块主要包括：

2.培训信息的录入 3.培训信息的删除 4.培训信息的修改 5.培训信息的查询 6.履历表的打印 用例图

2.5.8公司招聘

功能描述：

1.录入招聘信息

2.查询招聘信息

3.修改招聘信息

4.删除招聘信息

5.查询应聘者信息

6.删除应聘者信息

用例图

2．6 人工处理工程

创建用户（注册新用户）：用户信息需要手工输入计算机。更新部门、员工资料：需要手动输入更新内容。

2．7 尚未解决的问题

由于数据的传输上需要通过网络传输，为了客户资料进行保密，需要在网络的传输过程中对数据进行加密。

这个工作主要是在准备网络包，及解开网络包这两个模块完成，它们各对数据进行加密及解密还原工作。

在加密算法选择上将使用RSA 加密算法。具体算法可参照参考资料中《Computer Network》p.598。

3.接口设计 3.1用户接口设计

3.2外部接口

3.3内部接口

4．运行设计 4.1运行模块组合

施加不同的外界运行控制时所引起的各种不同的运行模块组合如下表所示：

4.2运行控制

5.系统数据结构设计 5.1逻辑结构设计要点

根据设计好的E-R图在企业人事管理系统中创建各表。

员工信息表用于储存员工基本信息和单位相关信息，改数据表结构如表2.1所示：

部门表用于存储部门编号、部门名称等信息，该数据表结构如表2.2所示。

工资表用于存储每月每个员工的详细工资信息该数据表结构如表2.3所示。

6.系统出错处理设计 6.1出错信息

程序在运行时主要会出现两种错误：

1、由于输入信息，或无法满足要求时产生的错误，称为软错误。

2、由于其他问题，如网络传输超时等，产生的问题，称为硬错误。

对于软错误，须在定票/领票操作成功判断及输入数据验证模块由数据进行数据分析，判断错误类型，再生成相应的错误提示语句，送到输出模块中。

对与硬错误，可在出错的相应模块中输出简单的出错语句，并将程序重置。返回输入阶段。

6.2补救措施

所有的客户机及服务器都必须安装不间断电源以防止停电或电压不稳造成的数据丢失的损失。若真断电时，客户机上将不会有太大的影响，主要是服务器上：在断电后恢复过程可采用 SQL SERVER 的日志文件，对其进行ROLLBACK 处理，对数据进行恢复。

在网络传输方面，可考虑建立一条成本较低的后备网络，以保证当主网络断路时数据的通信。

在硬件方面要选择较可靠、稳定的服务器机种，保证系统运行时的可靠性。

6.3系统维护设计

维护方面主要为对服务器上的数据库数据进行维护。可使用 SQL SERVER 的数据库维护功能机制。例如，定期为数据库进行Backup，维护管理数据库死锁问题和维护数据库内数据的一致性等。

第四篇：餐饮管理系统设计说明书

餐饮管理系统

[编辑本段]餐饮管理系统的功能及选择

中国是举世闻名的美食大国，拥有五千年的饮食文化和巨大的餐饮市场，随着人民生活水平和生活方式的转变，餐饮业具有巨大的投资市场，被称为中国的黄金产业，但同样也应看到，餐饮业不仅面临着巨大的发展机遇，也面临着前所未有的挑战和考验。这些挑战主要来源于以下几方面：

1.人才的专业化程度不够导致内功不足：因餐饮业门坎较低，中国的大多数餐饮企业的老板是从小店发展起来的，家族式管理的居多，还没有发展到聘请职业经理人，许多还是“人治”，并没有一套现代企业制度和监督管理体制，所以从观念意识、经营思想和管理水平还有待专业化。

2.变能力差，缺乏先进的信息工具：现在的餐饮市场火爆，许多以前做电子、房地产等其他行业的老板都凭借雄厚的资金实力挤进餐饮市场，争先恐后的上规模、上档次、比菜品、比服务、拼价格，使餐饮市场竞争激烈，但是许多餐饮企业缺乏对市场的应变能力和灵敏的信息工具，在现今网络经济的时代，许多餐饮企业还处在手工及半手工状态，即使有计算机也只是实现了POS系统(点菜收银环节),当个点菜器和计算器用，并没有真正通过计算机系统来实现改造流程、强化管理、降低成本、堵漏节流等作用。

3.缺乏科学和标准的管理体系：国外著名的快餐连锁经过上百年的探索都形成了标准化的工作流程和方法。中餐因其菜品的多样化和特色化的服务很难实现标准化管理，这使中餐企业的成本控制很难实现，但近两年也出现了引进快餐式经营特点的中餐企业，例如全聚德集团和天津的家和海鲜巨无霸，从流程、服务、出品都开了中餐标准化的先河。

当然经营特色、规模、出品这些因素不同的餐饮业态有不同的标准，上面所提到的人才专业化和管理体系两点可以通过引进管理人才来实现，但是提高餐饮企业核心竞争力的管理信息工具也越来越受到餐饮老板的重视，因此许多公司都陆续推出了餐饮管理系统，但由于自身经验的缺乏或对酒店餐饮行业管理理解的不够，至使市场上的产品良莠不分。目前市场上的餐饮管理系统大致有手工单据集中上传、PDA点菜和手持POS点菜三种类型。

一.手工单据集中上传类型：顾名思义，集中上传就是点菜员用手工开单后，统一到前台的计算机,POS机或触摸屏POS机来进行统一录入上传。很明显，这将导致效率的非常低下。在营业高峰时经常出现录入菜单排队现象，相信随着当前餐饮管理的发展，这种效率低下的管理模式将逐渐遭到淘汰。另外，没有条码划菜系统，无法统计上菜的时间，一旦出现问题，在厨师和传菜员之间无法追究明确责任。

应用范围：

1、计算机银台录入菜单投资低廉，使用者大多是中低档家常菜馆，营业面积一般为几百平米，基本上为粗放式管理流程。

2、触摸屏录入点菜软硬件投资高，因开发者多是海外的软件公司，往往偏重于为西餐厅点菜模式，此类系统设计过于简单，很难满足中餐品种繁多、经营管理理念、复杂的业务流程等等，所以用户以客流量不大的高档粤菜酒楼或西餐厅、茶餐厅、咖啡厅居多，此系统的特点：图片化，操作容易，可以防水，由服务员手工写单后到触摸屏上录入，但繁忙时会发生点菜员排队等录入的现象。

二.PDA点菜类型：PDA点菜上传，其主要是通过无线传输技术(802.11b)来进行数据传输。PDA用于点菜机,优点有:可实现触摸界面,手写识别字体,这对一些不懂拼音又记不住编码的点菜员有吸引力.但缺点是:

1、用手写触摸屏写单速度慢,如果是无按键的PDA，操作繁琐、点菜速度慢、在输入数量、附加项时必须用笔触式界面，对比较潦草的字难以识别，易出错、修改麻烦，损坏频率高，2、如果是完全触屏的PDA点菜,服务员必须双手操作操作，影响为客人介绍菜品及服务；

3、时间短,电池充电麻烦；

4、个头和重量大，点菜员多为女孩子，拿着非常不方便；

所以在选择硬件时,建议选择触摸,按键一体机来用于点菜.三.手持无线POS点菜类型：使用餐饮专用的手持POS点菜系统是拥有众多用户群的一套系统，其系统着重流程管理，针对中餐酒店的所有环节采用信息手段进行整合，从预订、接待、点菜、菜品上传、厨房分单打印、条码划菜、收银、经理查询等全方位计算机管理信息系统。是目前业内较为先进的，非常适合中大型酒楼的管理系统，根据重点调研目前国内应用比较广泛的手持POS点菜餐饮管理系统的开发者—北京辰森世纪计算机系统有限公司的用户情况分析，其系统的特性有以下几点：

1.数据准确、无丢单漏单现象

它用手持无线POS机(433频率技术)进行点菜，可随点随发送,从点菜到上传至厨房出单只需几秒钟即可完成，上菜速度快捷准确.2.全程计算机跟踪管理，无一张手工单据，数据准确无误，各种权限设置，避免人为的失误，从源头上杜绝了跑冒滴漏现象。

3.上传速度快、提高翻台率;

4.厨房打印菜单，条码划菜，便于统计菜品和厨师业绩,并有多级备份和日志可查。

5.日清日结，实时查询统计、核算清楚准确。ü 每天由收银出日营业报表，财务审核非常轻松。

6.灵活而准确高效的收银结帐系统

客人用餐完毕结帐时，结帐由台面服务员同收款员配合完成。并可由收银POS打印出结算单；收银系统支持集团消费、会员卡、挂帐、现金、支票、礼卷等等多种付款方式，可根据酒店管理要求和在收银员权限范围内进行折扣和服务费等的使用。

7.辅助酒店老板的监控和决策的工具

其总经理查询决策系统的功能非常强大，可以查询营业收入统计、员工业绩统计、人均消费额、翻台率等；可以以图形或表格形式进行各种分析：财务状况分析、营销决策分析、营业收入分析等；能对餐饮企业的经营起到全面的辅助决策作用，另外这套系统还有针对餐饮连锁集团所开发的总部远程查询系统使酒店管理者可以异地监控和查询分店的营业情况。专用点菜POS机硬件性能指标优点：

1、点菜,上传速度快;

2、操作键大、功能键简单、可简拼、编码点菜，服务员容易上手

3、功能多：点菜、加菜、退菜、催菜、缓菜、口味、制作方法、查询买单、套餐、储存、可简拼点菜，可输中文，可以应附客人特殊要求；

4、内存大，个头小；

5、锂电电池，无需更换电池，服务员休息时即可充电；

综上所述，从中餐行业的复杂性和从业人员的素质考虑，推荐餐饮企业使用现今应用比较广泛也是比较稳定成熟的餐饮专用的手持无线POS点菜技术。如百年老字号全聚德集团、向阳渔港餐饮连锁集团、宁波石浦大酒店,武汉三五醇餐饮集团,武汉艳阳天餐饮集团，北京大东北餐饮集团,如一坊连锁集团,.太原江南餐饮, 四川成都文杏大酒楼, 安徽黄山一楼餐饮连锁,海天一色大酒店, 南昌独一处,北京金鼎轩,.北京渔公渔婆,南昌名人大酒楼,山西晋城金和餐饮,包括国内面积最大和最豪华的南京向阳渔港店紫金店(单店3万8千平米)等等都在广泛运用这套辰森餐饮管理系统。

餐饮管理系统软件方面应该具有的功能:

以辰森餐饮软件为例,功能实现:预订、点菜系统(手持无线点菜/触摸屏点菜/PDA点菜)、出品打印、送单、结帐、收银、厨房打印、财务监控、会员管理、后台采购、库存管理、结算管理、员工管理、客户关系管理，总经理查询监控系统；能做到方便高效的菜单录入、精确的出品打印、强大的参数设置、灵活的营销设置、完善的成本核算、详尽的营业报表。上面只是简单介绍了一下餐饮管理系统软硬件方面的应具有的功能,技术指标等等,下面我们谈一下如何选择一个好的餐饮管理系统:

一、选择一家好的软件企业对餐饮企业能够起到事半功倍的效果，否则损失是不可估量的。餐饮企业的经营特点具有多样性，而流程又有相当的复杂性。需要软件开发商熟悉具备相当高的餐饮专业知识，否则开发的产品经受不住市场的考验。而选择不合适的软件属于决策性的失误，将极大困绕、滞碍企业的经营和发展。所以软件企业要具备高经验度，这样才可以快捷借鉴先进企业的管理经验，把自己的风险降至最低。

选择软件不象选择其他的产品，使用不好可以随时更换。它将充分体现管理者的思想和管理核心。

每个餐饮企业要想成功无论从经营上还是管理上都要有自身鲜明的特色和长远的规模发展战略。有实力的公司才可以根据企业的要求，做出准确的二次开发，满足将来的软件升级。不断调整软件的模块内容，使软件可以更好的为企业服务。

软件企业良好的技术维护队伍、专门的维护部门、定期回访等能够实际解决客户的后顾之忧，而目前代理公司能力参差不齐、注重短期经济效益和对客户不负责任的态度令人堪忧。

二、餐饮企业如何选择餐饮软件。除了可以根据企业自身的规模和特点选择不同的软件产品以外，还要注意一下几点：

（一）要选择成熟稳定的产品。多家客户特别是连锁企业连续的使用软件一定是经受了市场的考验，也必将是可靠的。

（二）要选择适应性强的产品。任何好的软件产品都有很强的适应能力。任何特点鲜明的餐饮企业的基本管理流程是大同小异的。如果软件只针对一家或几个客户开发的，将不能满足大多数企业的要求。

（三）要选择同一家公司软件产品的关联性、多样组合性。有的企业由于经营的需要，可能需要多种形式的点菜系统，如果选择多家产品进行组合几乎是不可以实现的，而使用一种产品又不可能完全适合自己的需要。这样就要求软件公司可以提供多样性组合的产品。

（四）要选择产品的拓展性和升级。任何好的产品都需要不断的完善和技术发展。选择软件一定要充分考虑到该产品的拓展性和技术升级。

现在餐饮软件公司不胜枚举，我们建议餐饮企业选择一家有良好业界口碑的软件公司或是具有实际能力的代理公司为餐饮企业的信息化管理锦上添花。

餐饮企业在向规模化、规范化前进的道路上需要好的软件来支持，而软件公司也将根据行业特点实现自己产品的进步。他们紧密相连，市场优胜劣汰是不二的法则，通过先进的软件管理工具必将实现餐饮和软件IT行业的双赢。

第五篇：信息采集系统设计说明书

信息采集系统概要设计

整体网络拓扑

信息采集系统的总体网络拓扑如下图所示：

工程师站服务器公网采集站1采集站2...网络结构说明

设备与采集站属于厂区内的同一个私有网络。

采集站/工程师站与公网直连，或者通过路由器间接地与公网连接。

终端状态管理

工程师站可以看到采集站的在线状态。选择采集站后，可以看到采集站下各个终端的在线状态。如果网络连接正常，所有采集站和终端都应该是在线的状态。采集站和终端注册

为了显示采集站和终端的在线状态，用户需要在工程师站上注册所有的采集站以及采集站下的终端信息。

用户在注册采集站时，需要填写采集站的标识符，该标识符不可重复，目的是让用户区分不同的采集站，且该标识符需要在采集站和工程师站上保持一致。

用户注册完采集站后，就可以在该采集站下添加终端信息。添加终端时需要填写终端的标识符和描述信息。其中，唯一标识符应当是终端内部可以取到的，可以区分同一个采集站下的不同终端；描述信息的目的是帮助用户区分不同的终端。

采集站和终端信息注册完成后，需要上传到服务器。当其他工程师站连接上服务器时，可以读取到这些信息，无需重复注册。

数据采集过程

本系统采集的数据有三种类型，分别是组态数据，运行数据和故障报警。其中，故障报警又分为实时故障和历史故障。下面分别阐述这三种类型数据的采集过程。

组态数据

每个终端都有一份组态数据，用户可以在终端上直接修改该组态。工程师站可以实时查看终端的最新组态信息，也可以修改并下发该组态信息。

查看终端组态

工程师站可以查询某个终端的最新组态。查询的详细过程如下：

1.2.3.4.5.6.工程师站发送查询命令给服务器

服务器从查询命令中解析出目的采集站，并将查询命令发送给采集站 采集站收到查询命令后向指定终端查询最新组态数据 终端回复最新组态数据

采集站将得到的组态数据回复给服务器

服务器将组态数据回复给发起查询的工程师站

数据流如下所示：

1.工程师站发送组态查询命令6.返回最新组态服务器工程师站2.服务器转发组态查询5.采集站返回最新组态采集站4.终端返回最新组态3.采集站向终端查询最新组态终端

修改终端组态

工程查询到终端的最新组态后，可以修改某些参数，然后将修改好的组态下发到终端设备。查询的详细过程如下：

1.工程师站发送写组态的消息给服务器，消息中需要包含组态和终端标识，可以有多个终端，这些终端的组态将更新为同一份组态。注意，多个终端必须属于同一个厂区，即由同一个采集站管理。

2.服务器从写组态消息中解析出目的采集站，并将写组态消息转发给采集站。3.采集站收到写组态的消息后，将组态下发给指定终端。4.终端回复组态更新结果给采集站。5.采集站将更新结果回复给服务器

6.服务器将组态更新结果转发给工程师站 数据流如下所示：

1.发送写组态消息6.返回组态更新结果服务器工程师站2.服务器转发写组态消息5.采集站返回写组态结果采集站3.采集站向终端写组态4.终端返回组态更新结果终端

运行数据

工程师站可以查询指定终端的当前运行数据，以了解终端的运行状态。查询过程与组态查询过程类似，此处不再赘述。

故障数据

终端运行过程中，如果发生故障，则需要将故障信息发送给采集站。采集站收到故障数据后，需要将此数据保存到本地数据库中。如果采集站此时能连接上服务器，则需要将故障信息发送给服务器。服务器接收到此故障报警后，需要将此故障报警推送给当前在线的工程师站。如果没有工程师站在线，则丢弃此条报警。

从上面的描述可知，工程师站被动接收到的故障报警都是实时故障报警。工程师站也可以通过历史报警功能查询历史报警信息。

实时故障

实时故障由终端主动上报给在线的工程师站，故障上报流程如下： 1.终端检测到故障，上报故障给采集站

2.采集站收到故障后，将故障信息发送给服务器

3.服务器查看是否有在线的工程师站，如果有，则将故障信息推送给工程师站，如果没有在线的工程师站，则丢弃该条故障报警。数据流如下图所示：

3.服务器推送故障报警服务器工程师站2.采集站上报该条故障报警采集站1.上报故障信息给采集站终端

历史故障

用户可以通过工程师站查询终端的历史故障信息，以了解终端的历史运行状态。历史故障查询时需要指定采集站和查询的时间范围，查询得到的结果为指定采集站下所有终端的某一时间段内的历史报警。

历史故障查询的详细过程如下：

1.工程师站向服务器发起历史故障查询，查询消息中包含了待查询的采集站和查询时间段。

2.服务器将查询消息转发到指定的采集站。

3.采集站根据查询消息中的时间范围查询本地数据库，采集站将查询到的结果返回给服务器

4.服务器将查询到的历史故障转发给发起查询的工程师站 数据流如下图所示：

2.将查询命令转发给采集站1.发起历史故障查询工程师站服务器3.服务器转发查询结果3.采集站返回查询结果采集站 各组件功能设计

工程师站

操作界面

需要展示的信息有：

1.已注册的采集站和终端的在线状态 2.终端的组态数据、运行数据和故障数据 需要编辑的数据有：

1.采集站和终端的注册信息 2.终端的组态数据

历史故障查询时需要指定时间范围，时间范围太长有可能会导致网络响应缓慢。

信息读写和接收

用户可以通过工程师站主动查询指定设备的各类数据，包括组态数据、运行数据和历史故障。可主动查询的信息有：

1.2.3.4.5.各采集站的在线状态

采集站下的终端的在线状态 指定终端的组态数据 指定终端的运行数据 指定采集站下的历史故障

实时故障由于对实时性要求比较高，需要由服务器主动推送给工程师站，工程师站接收到实时故障后，需要给用户提示，用户可以查看工程师站接收到的实时故障的详细信息。终端信息注册和组态修改

用户编辑好后终端和采集站的信息后，通过网络模块将组态保存到服务器上。组态修改完成后，通过网络模块将组态下发到各个终端上。

采集站

采集站标识符

采集站的功能生效之前，需要在界面上输入该采集站的标识符。该标识符需要与工程师站注册采集站时所用的标识符保持一致，这样工程师站才能将该采集站的信息正确的显示出来。

终端状态管理

采集站在启动后，需要根据采集站标识符从服务器上下载该采集站下面所有的终端信息。采集站监测各终端的在线状态，当状态发生变化时，需要将此状态更新到服务器，以便工程师站上可以实时反应出各终端的在线状态。

故障报警

采集站收到终端的故障报警时，需要将此条故障报警保存在本地数据库中，以备后续的历史故障查询。

组态模板

当工程师站向采集站下的某个终端发起过组态查询时，采集站需要将此终端的组态保存到本地数据库中，后续可能需要导出此组态信息，用于其他厂区的组态模板信息。

查询响应

采集站需要响应服务器的查询和下发命令。查询的信息类型有：组态数据、运行数据和历史故障。如果是组态数据和运行数据，采集站需要从终端中取得最新的结果，然后返回。历史故障数据从数据库中根据一定的条件返回。采集站还需要下发组态给终端。采集站与终端之间的交互接口

服务器

查询中转

工程师站查询终端信息时，需要服务器将这些查询指令转发给对应的采集站；采集站将结果返回给服务器时，服务器需要再将结果转发给工程师站。

报警推送

服务器接收到采集站的故障报警时，需要检查当前是否有在线的工程师站，如果有，则需要推送故障报警到工程师站。如果没有，则丢弃此条故障报警。

采集站注册信息管理

工程师站上注册好采集站和终端的信息后，需要保存到服务器中。当其他工程师站开启时，需要从服务器上获取到最新的采集站和终端注册信息。

采集站状态管理

每个厂区的采集站在上线时都要向中转服务器汇报在线状态，并开启保活机制，一段时间后，如果保活失败，则判定采集站的状态为离线。

采集站下的终端在线信息发生变化时，需要将此信息发送给服务器。

网络组件的接口

与工程师站之间的接口

工程师站的UI层通过网络组件来实现数据采集和下发。网络组件主要提供的功能包括终端在线状态管理、组态读写、运行数据查询、历史故障查询和实时故障接收这几个方面，下面是这几类功能的主要接口：

终端在线状态管理

1.增删采集站及终端信息 2.获取所有采集站的在线状态

3.获取指定采集站中所有终端的在线状态

组态读写

1.获取指定终端的组态

2.写入组态，可以指定采集站下的一个或者多个终端

运行数据查询

1.获取指定终端的运行数据

历史故障查询

1.获取指定采集站下的历史故障，查询条件是时间范围

实时故障接收

1.设置故障接收的回调对象（该回调对象有可能被频繁调用，需要确认终端的故障推送间隔时间）

与终端之间的接口

采集站与终端之间的通信有下面四种：

1.2.3.4.采集站向终端读取组态数据 采集站向终端写入组态数据 采集站向终端读取运行数据 终端推送故障报警给采集站

具体的通信协议待定。