枫桦楼食堂信息管理系统

范文一：枫桦楼食堂信息管理系统

编号:

MIS课程设计报告

题目: 桂林电子科技大学

枫桦楼食堂管理信息系统分析与设计

学院: 商学院

专业: 人力资源管理

学生姓名: 梁进、黄贵富、徐倩菊

学号: 1100540120

1100540118

1100540113

指导教师: 董雄报

2013年 6 月 17 日

系统介绍 ?????????????????????????? 2 1 系统规划?????? ???????????????????2 1.1 开发背景??????????????????????????2 1.2 系统目标??????????????????????????2 1.3 总体功能???? ????????????????????? 3 1.4 调查分析????? ???????????????????? 3 1.5 可行性分析??? ????????????????????? 4 2 系统分析????????????????????????? 6 2.1 业务流程图…………………………………………………………………6 2.2 数据流程图…………………………………………………………………8 2.3 数据字典………………………………………………………………… 10 3 系统分设计????????????????????????14 3.1 主要工作………………………………………………………………… 14 3.2 功能结构图……………………………………………………………… 15 3.3 系统构架………………………………………………………………… 15 3.4 代码设计………………………………………………………………… 17 3.5 输入输出设计…………………………………………………………… 17 3.6 数据库设计……………………………………………………………… 22 3.7 物理配置方案设计……………………………………………………… 39 4 总结报告?????????????????????????30 5 参考文献?????????????????????????31

系统介绍

本食堂管理信息系统是在计算机技术、网络技术、面向对象的新数据库技术以及其他相关的科学技术的支持下形成的。它主要是从以下几个管理方面:学生信息管理、食堂信息管理、订餐管理、库存管理、成本管理等来进行相关的分析与研究。通过此系统能够很好的处理大量的相关的食堂相关信息。 1 系统规划

1.1 开发背景

学校食堂管理信息系统是一个实用并且是与我们的学校生活密切相关的一个管理信息系统;如果能够很好的研究、开发并加以利用，那么就会提高食堂的效益，降低食堂的成本，降低食堂的饭、菜价从而能够给学校的学生带来莫大的利益和好处。

同时随着高校的扩招，高校的食堂也变得越来越多。有的学校的食堂非常的分散，要实现如此之多的食堂的良好、协调、统一的管理，就需要借助现代的更加先进的技术和科技，比如说:电子信息管理系统、射频技术、网络技术、计算机技术等以实现更加方便、快捷、有效的食堂管理。

我们所选的食堂管理信息系统是在以学校现行的运行结构上进行的更加详细的设计和说明。

1.2系统目标

食堂托管作为一个新兴的行业，也需要一定要规章制度来制约学生的言行，保证学生的饮食健康。以桂林电子科技大学枫桦楼食堂为例，简单说明一下食堂托管的一些管理制度:

1.目的

为了提高食堂管理的整体水平，为全体学生提供卫生、放心、舒适、优质的用餐环境和氛围，维护和确保学生的身体健康，特制定本制度。 2.范围

食堂工作人员和全体学生。

3.采购制度及存储制度

(1)严把采购质量关，预防和杜绝病从口入，不得采购霉变、腐败、虫蛀、有毒、超过保质期的或卫生法禁止供应的其他食品。防止食物中毒。

(2) 采购大批主食或副食要求供货单位提供卫生许可证，以便查验，不得采购三无产品。

(3)严格执行食品卫生制度，对存放的各类食品实行“隔离”，以免串味、走味或变质。

(4)食堂库房整齐清洁，分类存放，防鼠防潮。

(5)食品存放冰箱或冰柜时间不得多于48小时，严禁销售隔夜饭菜。 4.卫生管理制度

(1)树立全心全意为职工服务的思想,讲究职业道德.文明服务,态度和蔼,主动热情,礼貌待人,热爱本职,认真负责.做到饭熟菜香,味美可口,食品足量,达到学生,教师的满意.

(2)坚持实物验收制度,学校成立的质管监督小组将按期对副食的采购进行检查,与票据进行核对,做到票物相符. 定期公布帐目,接受职工监督.

(3)爱护公物.食堂的一切设备,餐具有登记,有帐目,对放置在公共场所内的任何物件,不得随便搬动或拿作它用.不得无故损坏各类设备,餐具,否则按价赔偿.

事人员要讲究卫生.做到勤洗手,勤剪指甲,勤换,洗工作服,工作时间 (4)炊

要穿戴工作衣帽.炊事人员每年进行一次健康检查,无健康合格证,不准在食堂工作.

(5)按计划到卫生防疫合格场所采购(学校指定采购地点为让胡路商场和金锣肉类食品加工厂),并索要发票,严禁采购腐烂,变质食物,严防食物中毒,特别是要将副食的采购渠道向职工公开,由食堂管理委员会检查验收. 1.3 总体功能

本系统主要运用于:1.学生信息管理:(1)学生信息(2)内部员工管理;2.成本核算:(1)食堂运营成本查询(2)效益查询;3.库存管理:(1)入库商品管理(2)库存余额查询。食堂管理信息系统图如图1-1所示。 1.4 调查分析

1(学生需求调查:了解桂电东区学生吃饭时间段，倾向于哪种食品以及其口感满意程度，桂电东区枫桦楼是否能满足广大同学们吃饭需求，一切以同学需求为中心展开问卷与现场调查。食堂管理信息图如图1-1所示。

学生信息添加

学生信息修改

食学生信息学生信息查询

学生信息删除堂

成本查询管成本核算效益查询理

信库存余额查询

库存管理息入库商品管理

系出库商品管理

统预订信息查询

预订信息修改

预定信息管理

预订信息添加

座位信息查询

图1-1 食堂管理信息系统图

2(食堂使用情况调查:桂电东区共有3家食堂，生乐餐厅，东园餐厅，枫桦楼，学校餐厅是为了方便师生用膳，节省生活费用的消费场所。

3(经济效益调查:学校的规模不断扩大，学生数量不断增加，学生信息量也成倍增长，食堂管理工作成为学校各项管理工作的一个重要部分。同时由于学校食堂管理复杂性给学校食堂的人工管理带来了相当大的难度，不管是在菜价的制定还是库存的控制方面都是现有的人工所处理不过来的数据，或者是处理起来难度非常大。

1.5 可行性分析

可行性分析是系统分析阶段的重要活动，是对系统进行全面、概要的分析。它的任务是确定项目开发是否必要和可行。它的主要目标是:进一步明确系统的

目标、规模和功能，对系统开发背景、必要性和意义进行调查分析，并根据需要和可能提出拟开发系统的初步方案和计划，明确问题，对所提供系统大致规模和目标的几个有关约束条件进行论证，并且提出系统的逻辑模型和各种可能的方案，从而为系统开发项目的决策提供科学依据。

其主要从三个方面进行研究:

1.技术可行性:对现有技术进行评价，以明确能否利用现有技术进行系统开发及系统实施。计算机网络技术的发展和计算机硬件性价比的不断提升，使计算机全面应用于医院管理的各个环节成为可能。C/S开发模式、COM、DCOM技术在国内各行各业的信息管理系统开发中已经被广泛采用，实践证明这些技术都非常适合食堂管理系统的开发。

2.经济可行性:对组织的经济状况和投资能力进行分析，对系统建设、运行和维护费用进行评估，对系统建成后可能取得的社会及经济效益进行估计。学校食堂在学校和政府以及其他支持者的支持下能够保证有相当的可靠的可盈利性，另外食堂管理信息系统能够很好的对食堂的相关的方面进行相关的管理和控制，能够有效的降低成本，提高营业利润。

3.营运可行性:指系统对组织机构的影响，对现有人员和机构、设施、环境等的适应性以及进行人员培训补充计划的可行性。食堂系统的计算机信息管理人才、计算机硬件设备、操作员的计算机应用能力都为系统的运行过程提供了可靠保证。学校是高科技技术的研发地，计算机学院以及其他相关学院的科学技术的发展能够保证管理信息系统的有效的开发和利用。

从以上可行性分析可知，该系统开发具备技术上、经济上和营运上的可行性。可行性分析功能图如图1-2所示。

需求分析析问题定义技术可行性

析分析

综合测试管理可行性经济可行性

分析分析

评估结果完成文档

图1-2 可行性分析功能图

2 系统分析

2.1 子模块功能分析

学生信息管理:主要是对学生的信息管理进行管理，主要的方面主要是学生信息的查询、修改、添加等。学生信息管理图如图2-1所示

学生信息查询

学生

信息学生信息修改管理

学生信息添加

学生信息删除

图2-1 学生信息管理图

食堂成本核算管理:

对成本利润的综合分析。成本包括固定成本(人员工资、水电、税等)+变动成本(菜、酒、米等的采购成本);收入指每天的销售收入。能核算每天、每月、每年、以及任何一段时间的成本，利润;算机系统核计每天各单位、各窗

2所示口的收益情况并将结果送入数据库供管理层查询。成本核算管理图如图2-

总成本

单位总成

本

加权成本

成本查询成单位加权成本本核总效益算

管单位效益效益查理

询加权总效益

单位加权效益

图2-2 成本核算管理图

成本查询:总成本=各项成本的综合

单位平均成本=总成本/单位总数

加权成本=根据各部门、单位的重要性从而为其赋予一定的权数*本单位的成本

单位加权平均成本=加权成本/单位总数

效益查询:总效益=各部们、单位的效益的总和

单位平均效益=总效益/单位、部门总数

加权效益=根据各部门、单位的重要性从而为其赋予一定的权数*本单位的效益

单位加权平均效益=加权效益/单位、部门总数

预订信息管理:采购部负责订购食品用材，其他部门向其提交申请，对于已达货物可采取签名接受。预定信息管理图如图2-3所示

预订信息查询

预

定预订信息修改

信

息预订信息添加管理

座位信息查询

图2-3 预定信息管理图

在该系统中，把从学生预定信息输入单元输入的多种学生预定信息(学生的预定和工作人员的学生访问预定)存储到学生预定信息存储单元中，学生日程安排单元从存储在学生预定信息存储单元中的学生预定信息中选择出规定日中的规定种类的学生预定信息，自动生成学生日程表。由此，不需要通过手工操作来从种类繁多的学生预定信息中挑选出规定日中的学生预定信息和挑选出规定种类的学生预定信息，可以向工作人员提供使用方便的学生日程表，节省工作时间，从而可提高工作效率，使得整个工作进度能够保持预先目标，学生和工作人员都能保持足够精力完成各个工作环节。

系统整体功能管理模块:系统整体流程如图2-4所示

学生信息添加

学生信息修改

学生信息学生信息查询

学生信息删除

成本查询系成本核算统效益查询

整

库存余额查询

体库存管理入库商品管理

功出库商品管理

能

预订信息查询

预订信息修改

预定信息管理

预订信息添加

座位信息查询

图2-4 系统整体功能图

2.2 数据流图

数据流图(Data Function Diagram):又名数据功能图表，简称DFD，就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。它是SA方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型。数据流图的主要作用是: 1、便于用户表达功能需求和数据需求及其联系;2、便于两类人员共同理解现行系统和规划系统的框架;3、清晰表达数据流的情况;4、有利于系统建模。

学生校园卡使用流程图如图2-5所示

学生校园卡学生学

生刷卡学生信息校

园

卡

使

用

流学生卡信息系统

程

相关学校合作银行

结算信息

输入

协助食堂的消费自助机，用

于将学生的消费，从银行转

结算管理到食堂相关的经营者手中

图2-5 学生校园卡功能图

预定管理流图和库存管理数据流图如图2-6、2-7所示

学生

订餐

确认预订信息管理

消费查收款管理

询

成本结算管理预定信息

图2-6 预定管理流程图

成本结算管理

采购员使用资源

库存管理

入库管理出库管理

库存判断

2-7库存管理数据流图

2.3 数据字典:

数据字典(Data dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录。主动数据字典是指在对数据库或应用程序结构进行修改时，其内容可以由DBMS自动更新的数据字典。被动数据字典是指修改时必须手工更新其内容的数据字典。

数据字典是一个预留空间，一个数据库，这是用来储存信息数据库本身。数据字典可能包含的信息，例如:

1.数据库设计资料

2.用户权限

3.用户统计

4.数据库的过程中的信息

5.数据库增长统计

6.数据库性能统计

数据字典则是系统中各类数据描述的集合,是进行详细的数据收集和数据分析所获得的主要成果。

数据字典通常包括数据项\数据结构\数据流\数据存储和处理过程五个部分。

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

1.数据结构名称:卡信息。包括的数据项有:

(1)卡号(学生使用的用来付款的卡的编号，与学生办卡的先后顺序有关也

有可能是与学院有关的别名Card_number 字符型长度6)

(2)余额(学生卡中所剩的金钱数量，别名Balance 字符型长度 6)

(3)卡日期(学生办卡的日期，别名Card_date 日期型长度 8)

(4)持卡者姓名(拥有信息卡的学生的名称，别名 Person_name 字符型长度 10)

(5)花费(学生所消费的金钱数量别名Consume 字符型长度 20) 2. 数据结构名称:学生信息

包括的数据项有:

(1)学号(学生在校所编的号码别名 S_number 字符型长度6)

(2)系别(学生所在的系的名称别名 S_system 字符型长度 16)

(3)班级(学生所在的班级的班号别名class 字符型长度 20)

(4)姓名(学生的姓名别名 S_name 字符型长度 10)

别名 S_sex 字符型长度 4) (5)性别(学生的性别

(6)宿舍(学生所在宿舍名称别名 S_dorm 字符型长度 20)

(7)联系方式(学生的手机号码别名 S_tel 字符型长度 20) 3. 数据结构名称:教师信息

包括的数据项有:

(1)教师号(教师的编号别名 T_number字符型长度 6)

(2)系别(教师所在的系的名称别名 T_system 字符型长度 10)

(3)姓名(教师的姓名别名 T_name 字符型长度 6)

(4)性别(教师的性别别名 T_sex 字符型长度 4)

(5)家庭住址(教师的家庭住址别名 Address 字符型长度 50)

(6)联系方式(教师的手机号码别名 T_tel 字符型长度 20)

4. 数据结构名称:学生

包括的数据项有:

(1)消费序号(学生来消费的序号别名 Consumer_number 字符型长度 6)

(2)姓名(学生的姓名别名 Consumer_name 字符型长度 10)

(3)性别(学生的性别别名 Consumer_sex 字符型长度 10)

(4)消费类别(学生消费的类别，其中包括卡消费和现金消费别名

Consume_sort字符型长度 10)

(5)学生类别(学生的类别，这里指学生或教师别名 Consumer_sort

字符型长度 10)

5. 数据结构名称:消费情况

包括的数据项有:

(1)一号窗口(一号窗口一天内收入总和别名 Floor_one 字符型长度 6)

(2)二号窗口(二号窗口一天内收入总和别名Floor_two 字符型长度 6)

(3)三号窗口(三号窗口一天内收入总和别名 Floor_three 字符型长度 6)

(4)一天消费总额(一天内在食堂用餐的学生所花费的总额，它的数值等于

别名 Total 长整型长度 6) 所有窗口的收入与学生在餐位所花费的总额

(5)日期(记录的日期别名 Date 日期型长度 8) 6. 数据结构名称:管理员信息

包括的数据项有:

(1)管理员编号(管理员在食堂的编号别名 Manager_number 字符型长

度 6)

(2)姓名(管理员的姓名别名Manager_name 字符型长度 6)

(3)性别(管理员的性别别名 Manager_sex 字符型长度 4)

(4)家庭住址(管理员的家庭住址别名Manager_address 字符型长度 50)

(5)联系方式(管理员的联系方式别名 Manager_tel 字符型长度20)

(6)工资(管理员每个月的收入别名 Income 整型长度 20) 7. 数据结构名称:库存信息

包括的数据项有:

(1)商品编号(商品的编号别名 Trade_no 字符型长度20)

(2)商品名称(商品的名称别名Trade_name 字符型长度 20)

(3)商品价格(商品所入库时的价格别名price 整型长度 4)

(4)入库商品数量(入库时商品的数量别名Enter_number 整型长度 4)

(5)库存商品数量(现在库存的商品的数量别名 Stock_number 整型长

度 4) (6)入库时间(商品入库的时间别名 entertime 日期型长度 8)

(7)出库时间(商品出库的时间别名 outtime 日期型长度 8)

8. 数据结构名称:餐位信息

包括的数据项有: (1)餐位编号(学生订餐餐位所在的编号别名 Room_number 字符型

长度 6) (2)餐位位置(学生订餐餐位所在的餐位位置别名 Room_address字符

长度 20)

9. 数据结构名称:订餐信息包括的数据项有: (1)订餐编号(学生订餐的编号，以便管理别名 Beat_number 字符型

长度 6) (2)学生姓名(学生的姓名别名 Consumer_name 字符型长度 10)

(3)联系方式(学生的联系方式(手机号码) 别名 Consumer_tel 字符型

长度 20) (4)约定时间(学生订餐时所约定的吃饭时间别名Booktime 日期型

长度 8) (5)备注信息(在订餐时其他的信息别名 Remark_info 文本型长

度 50)

3 系统设计

3.1 主要工作

1.将系统划分成模块;2.决定每个模块的功能; 3.决定模块的调用关系;4.决定模块的界面。其系统功能模块图如图3-1所示

系统

子系统子系统子系统

模块模块

模块模块模块

图 3-1 系统功能模块图

模块说明:

学校的食堂管理信息系统是由学生信息管理、成本核算、库存管理、预定信息管理三个子模块功能构成。

学生信息---------主要有学生信息添加、修改、查询、删除。它主要负责在校生的管理，由于校园卡是学生在校的一个重要的消费卡。所以，学生信息管理子模块是整个学校食堂管理的中心和基础。

成本核算---------主要是指学校的食堂在盈利与亏损方面管理。食堂是以一个以盈利为目的的企业，如果食堂达不到它想要的利润目标那么他就容易崩溃，就会影响学生的相关的伙食供应，影响学校的安定。所以说，成本核算是至关重要的一项。

库存管理---------主要是指学校食堂的相关的库存。库存管理是至关重要的，因为它关系到学校的相关的利益和食堂利益。库存管理在现代社会中显的尤为的重要，库存管理的成本降到最低则会大大提高食堂的毅力成本。

预定信息管理---------主要是指预订信息查询、修改、添加以及座位信息的查询等。学校的食堂会提供一些高级的餐饮供应，比如中国矿业大学一、二食堂的3楼，在这种情况下，预定信息管理的就极为重要。

以上的几项内容最后均汇至一台中央的处理计算机，然后由中央处理的计算

机向外延伸出各个不同地方的终端负责各个地方的刷卡消费、商品管理等。最终再将各个终端计算机的相关信息汇总到中央处理计算机，最终实现系统化管理，实现食堂信息管理。其功能图结构图如图3-2所示。

3.2 功能结构图

学生信息添加

学生信息修改

学生信息学生信息查询食

学生信息删除堂

成本查询

管成本核算

效益查询理

信库存余额查询

库存管理息入库商品管理

出库商品管理系

预订信息查询统

预订信息修改

预定信息管理

预订信息添加

座位信息查询

图3-2 食堂功能结构图

3.3 系统架构

系统架构属于系统设计阶段中重要的一个方面，系统架构只是这个阶段一个产物，要正确的、合理的画系统架构需要全面的理解用户需求以及业务流程，当理解了这些东西后，剩下的就是如何进行表达了，一般而言，可以参照RUP的用例驱动来进行逻辑架构，开发架构等设计工作。本系统选用C/ S + B/ S新型体系架构。

C/ S + B/ S新型体系架构:在B/ S + C/ S 新型体系架构中，一些需要

通过Web 处理的，满足大多数访问者请求的功能(如信息发布查询界面)采用 B/ S 架构，而后台只需少数人使用的功能(如数据库管理、维护)则采用 C/ S架构。组件位于 Web 应用程序中，客户端发出HTTP请求到 Web服务器，Web服务器将请求传送给 Web应用程序，Web应用程序再将数据请求传送给数据库服务器，数据库服务器将数据返回 Web 应用程序，然后由 Web 服务器将数据传送给客户端对于一些较难实现的功能或一些需要丰富的HTML 页面，则可通过在页面中嵌入 ActiveX控件来实现。

这种体系架构分布结构图如图3-3所示

图3-3 体系架构分布结构图

采用这种新型架构的优点在于:

1.采用了B/ S与 C/ S体系架构的优势，弥补了二者的不足;

2.客户请求和信息发布采用B/ S架构，保持了瘦客户端的优点，客户机只利用浏览器即可完成所有的应用需求;

3. 数据库请求响应采用 C/ S 架构，通过在Web应用程序和数据库之间建立 ODBC/ JDBC连接来完成数据库的连接和请求响应，能完成大量数据的批量录入请求;

4.系统维护、数据更新方便，不存在完全采用 C/ S 结构带来的客户端维护工作量大等缺点;

5.将服务器端划分为 Web 服务器和 Web应用程序两部分。 Web 应用程序采用组件技术实现三层体系结构中的商业逻辑部分，达到封装源代码，保护知识产权的目的;

6. 对基于 C/ S 体系架构的应用，可以保留原有的某些子系统，只需开发用于发布的 WWW界面，就能很容易地升级到这种体系架构，使得原有系统或资源无需大的改造即

可连接使用。

3.4 代码设计

代码是用来表征客观事物实体类型与属性的一个或一组易于计算机识别和处理的特定符号，它可以是字符、数字、某些特殊符号或它们的组合。代码设计就是要把系统中要处理的事物用特定的代码来描述，便于计算机系统识别、处理，便于数据的共享，提高用户使用数据的效率。代码设计表如表1-1所示

表1-1 代码设计表

编号: 填表人: 填表日期:

编码对象学生学号

代码种类层次码代码位数 8

代码结构 00 00 00 00

学院代码入学年份班级代码班级内顺序号检验位无

备注

编号: 填表人: 填表日期:

编码对象商品编号

代码种类层次码代码位数 6

代码结构 00 00 00

公司地点购买渠道产品名称

检验位无

备注

3.5 输入、输出设计

输入输出设计的意义

输入输出设计是管理信息系统与用户的界面，一般而言，输入输出设计对于系统开发人员并不重要，但对用户来说，却显得尤为重要。

1. 它是一个组织系统形象( Cooperation Identify System, CIS ) 的具体体现;

2. 它能够为用户建立良好的工作环境，激发用户努力学习、主动工作的热情;

3. 符合用户习惯，方便用户操作，使目标系统易于为用户所接受。

4. 为用户提供易读易懂的信息形态。

输入设计

输入界面是管理信息系统与用户之间交互的纽带，设计的任务是根据具体业务要求，确定适当的输入形式，使管理信息系统获取管理工作中产生的正确的信息。

输入设计的目的是提高输入效率，减少输入错误

设计工具

1. IPO图

IPO(Input-Process-Output)图就是用来表述每个模块的输入，输出和数据加工的重要工具。

IPO图是由IBM公司发起并逐渐完善起来的一种工具。在由系统分析阶段产生数据流图，经转换和优化形成系统模块结构图的过程中，产生大量的模块，开发者应为每个模块写一份说明。

系统的IPO图如图3-4所示

图3-4 系统IPO图

IPO图的主体是处理过程说明。为简明准确地描述模块的执行细节，可以采用上一章介绍的判定树/判定表，以及下面将要介绍的问题分析土、控制流程图以及过程设计语言等工具进行描述。

IPO图中的输入/输出来源或终止与相关模块、文件及系统外部项，并需在数据字典中描述。局部数据项是指本模块内部使用的数据，与系统的其他部分无关，仅有本模块定义、存储和使用。注释是对本模块有关问题做必要的说明。

IPO图是系统设计中一种重要的文档资料。

2. 控制流程图

控制流程图(Flow Chart，FC)又称框图，是经常使用的程序细节描述工具。

框图包括三种基本成分:

框图的特点是清洗易懂，便于初学者掌握。

在结构化程序设计出现之前，框图一直可用箭头实现向程序任何位置的转移(即GOTO语句)，往往不能引导设计人员用结构化方法进行详细设计。箭头的使用不当，会使框图非常难懂，维护的成本高，而且极难维护。因此框图的使用有减少的趋势。

3. 问题分析图

问题分析图(Problem Analysis Diagram， PAD)由日立公司于1979年提出，是一种支持结构化程序设计的图形工具，可取代前述的控制流程图。

问题分析图仅仅具有顺序、选择、和循环三种基本成分，如下图，正好与结构化程序设计中的基本成分相对应。常见问题分析图如图3-5所示

图3-5 问题分析图

下图为排序的控制流程图和问题分解图，分别表示将n个数从大到小排序的过程。常见问题分解图如图3-6所示

图3-6 问题分解图

问题分析图的独到之处在于:以问题分析图为基础，按照一个机械的变换规则就可编写计算机程序。问题分析图有着逻辑结构清晰，图形化标准化与人们所熟悉的控制流程图比较相似等优点。更重要的事，它引导设计人使用结构化程序设计方法，从而提高程序的质量。

库存管理信息的输入与输出如图3-7所示

成本核算的输入与输出如图3-8所示

开始

库存结算信息

是否达到警戒

进货线退出系统

进货继续使用

图3-7 库存管理输入输出图

开始

C=成本统计统计数据有问

题 I=收入统

计各

N A=I-C

进价销价

A>0 格高低

Y Y

Y N 调整

A<>

利的最调整

高界限)

Y 调整相应的

价格

继续使用进货

和销售价格

退出系统

图3-8 成本核算输入输出图

预定信息系统在日常生活中给以我们很大帮助，我们再利用好预订信息系统后，无论是哪方面的事情都容易事先预定并予以实现目标。其预定信息子系统的输入与输出图如图3-9所示

团体预定

信息 N

是否有餐位预定Y 剩余餐个人预定信管理信息

位息系统

是否等待

团体、个人信息录

入

N 预定成

功

退出系

统

图3-9预定信息子系统的输入与输出

3.6 数据库设计

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

数据库设计(Database Design)是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和建立数据库的过程。就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。一般，数据库的设计过程大致可分为6个步骤:

1.需求分析;调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2.概念设计;对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等)，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以扩充的实体—(E-R模型)联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的局部描述(在数据库中称为用户的局部视图)。第二步再将前面得到的多个用户的局部视图集成为一个全局视图，即用户要描述的现实世界的概念数据模型。

3.逻辑设计;主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

4.物理设计;根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物

包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法理存储结构(

和存取路径等。这一步设计的结果就是所谓“物理数据库”。

5.验证设计;在上述设计的基础上，收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。一般，一个大型数据库的设计过程往往需要经过多次循环反复。当设计的某步发现问题时，可能就需要返回到前面去进行修改。因此，在做上述数据库设计时就应考虑到今后修改设计的可能性和方便性。

6.运行与维护设计;在数据库系统正式投入运行的过程中，必须不断地对其进行评调整与修改。

至今，数据库设计的很多工作仍需要人工来做，除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外，尚缺乏一套完善的数据库设计理论、方法和工具，以实现数据库设计的自动化或交互式的半自动化设计。所以数据库设计今后的研究发展方向是研究数据库设计理论，寻求能够更有效地表达语义关系的数据模型，为各阶段的设计提供自动或半自动的设计工具和

集成化的开发环境，使数据库的设计更加工程化、更加规范化和更加方便易行，使得在数据库的设计中充分体现软件工程的先进思想和方法。根据本食堂管理信息管理系统各个子模块之间的关系，数据库设计如下: 创建库存信息表Stock如表1-2所示

创建管理员信息表Manager 如表1-3所示

创建消费情况表ConsumeSituati如表1-4所示

学生表Consumer如表1-5所示

订餐信息表book_eat如表1-6所示

表1-2 库存信息表Stock

列名数据类型可否为空说明声明 Trade_no 数字 NOT NULL 商品编号主键 Trade_name 文本 NULL 商品名称建立

聚簇索

引

price 货币 NULL 商品价格 Enter_numbe数字 NULL 入库商品数

r 量

Stock_numbe数字 NULL 库存商品数建立

r 量聚簇索引 entertime 日期/时间 NULL 入库时间建立

唯一索引 outtime 日期/时间 NULL 出库时间 Manager_num数字 NOT NULL 管理员编号外键

ber

表1-3 管理员信息表Manager

列名数据类型可否为空说明声明 Manager_number 数字 NOT NULL 管理员编号主键 Manager_name 文本 NOT NULL 姓名 Manager_sex 是/否 NULL 性别 Manager_addres数字 NULL 家庭住址

Manager_tel 数字 NULL 联系方式

Income 货币 NULL 工资

表1-4 消费情况表ConsumeSituation

列名数据类型可否为空说明声明

Date 日期/时NOT NULL 日期主键

间建立

唯一索引

Total 数字 NULL 一天消费总额建立

聚簇索引

Floor_one 数字 NULL 一号窗口

Floor_two 数字 NULL 二号窗口 Floor_three 数字 NULL 三号窗口 Consumer_number 数字 NOT NULL 消费序号外键

表1-5 学生表Consumer

列名数据类型可否为空说明声明 Consumer_number 数字 NOT NULL 消费序号主键 Consumer_name 文本 NOT NULL 姓名

Consumer_sex 是/否 NULL 性别

Consume_sort 文本 NULL 消费类别

Consumer_sort 文本 NULL 学生类别

7.创建E-R图的要素: 实体型、属性和联系

实体型:具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体;在E-R图中用矩形表示，矩形框内写明实体名;属性:实体所具有的某一特性，一个实体可由若干个属性来刻画。在E-R图中用椭圆形表示，并用无向边将其与相应的实体连接起来;联系:联系也称关系，信息世界中反映实体内部或实体之间的联系。实体内部的联系通常是指组成实体的各属性

之间的联系;实体之间的联系通常是指不同实体集之间的联系，其创建的枫桦楼管理信息系统实体联系模型(E-R)图如图3-10所示。

表1-6 订餐信息表book_eat

列名数据类型可否为空说明声明 Beat_number 数字 NOT NULL 订餐编号主键 Consumer_name 文本 NOT NULL 学生姓名建立

聚簇索引 Consumer_tel 数字 NULL 联系方式 Booktime 日期/时间 NULL 约定时间建立

聚簇索引

Remark_info 文本 NULL 备注信息

Consumer_number 数字 NOT NULL 消费序号外键

建立唯一索引 Room_number 数字 NOT NULL 餐位编号外键

商品价格。。。。。。

出库时间库存信息商

品

管名订餐编联系方理称号式管理所家庭住员编在址约定时号间订餐信息工管理员联系资备注信信息方式息姓学生姓性名名别管理查订餐询一号窗学生类消费二号口别类别窗口消学生消费情

姓费况名一天的消费总额三号性消费序窗口

别号日

属于组期成教师姓名学

号班号名系别级系学生信教师信家庭别息息姓住址

联系名联系宿方式性方式舍使用别持有性

用别

花

卡信息费持卡人

卡号姓名

余办卡日额期

图3-10 枫桦楼管理信息系统实体E-R图

3.7 物理配置方案设计

鉴于经费、用途等方面考虑，本系统采用C/S的计算模式。Client(客户端)负责提供表达逻辑、显示用户界面信息访问数据服务器;Server(服务器端)则用于提供数据服务。物理配置方案图如图3-11所示

图3-11物理配置方案图

4 结束语

管理信息系统(Management Information Systems 简称MIS)在现代社会已深入到各行各业，由于计算机技术的迅速发展和普及，MIS 事实上已成为计算机MIS。

目前，由于开发高质量 MIS 的能力大大落后计算机硬件日新月异的进展，加上社会对MIS 发展和完善需求的增加以及对MIS开发过程中出现的错误认识和行为而导致MIS开发的失败,这些情况已严重妨碍了计算机技术的进步。因此对MIS 有关的内容进行深入研究，提高工作效率，提高MIS开发成功率已变得十分重要。

随着技术的进步，经营管理方式发生了转变，从而使面向管理的信息系统的内容和形式都在发生着变化，当前可以充分利用网络技术和数据库技术的发展，形成一种全新的运行方式。同样，网格技术的发展也使学校食堂管理信息系统在现代高新技术发展的时期使用变得很简单，通过企业内部的局域网，可以实现整个资源共享的同时，更可以方便、快捷、有效的更好服务同学、老师，从而实现学校食堂管理的信息化、智能化、高效化这样更有助于学校食堂在宏观上进行安全决策和风险评价分析。

学校食堂管理信息系统必须根据时代要求，走网络化道路，要不断完善其网络功能，真正实现信息化管理，并朝着信息化方向不断发展。

经过四个星期的努力，我们终于完成了学校食堂管理信息系统课程设计报告。总体来讲，我们对自己在这三个星期内所做的工作及获得的成果还是比较满意的。系统运行基本达到了预期目标，课程设计报告通过系统可行性分析报告、系统分析报告、系统设计报告三部分详细完整地记录了系统开发的过程。

5 主要参考文献

1.管理信息系统樊世清中国矿业大学出版社

2.管理信息系统黄梯云李一军高等教育出版社

3.陈圣国.信息系统分析与设计.西安:西安电子科技大学出版社，2001

4.王珊等.数据仓库技术与联机分析处理.北京:科学出版社，1998

范文二：食堂信息管理系统

食堂信息管理系统

—— 09电商 1班 16号林庆锋 1. 系统功能分析

系统开发的总体任务是受用计算机信息管理技术, 实现食堂各种信息的系统化,规范化,自动化,提高食堂管理的效率。

对应用系统项目的开发,首先要对程序要实现的功能和目标进行整体分析和规划, 确保在后期开发中不会出现遗漏或重大缺陷。因此在软件开发中, 要严格按照软件工程的流程进行系统的分析和设计

系统功能分析是在系统开发的总体任务的基本上完成的。

主要功能 :

1、消费者信息管理

2、预订信息管理

3、成本核算管理

4、库存管理

其中主要任务为消费者信息管理和结算信息管理。

总的功能特点:

●完善、全面的综合查询

●报表翔实,实用性强

2. 系统功能模块设计

对上述各项功能进行集中、分块分析,按照结构化程序设计的要求,得到如图所示的这个系统的功能模块图

3. 系统功能管理模块

4. 数据结构名称:学生信息

含义说明:消费者群体之一,可以自由选择消费方式,办过卡用卡交易或者用现金交易

包括的数据项有:

1) 学号

(学生在校所编的号码别名 S_number字符型长度 6) 2) 系别

(学生所在的系的名称别名 S_system字符型长度 16) 3) 班级

(学生所在的班级的班号别名 class 字符型长度 20)

4) 姓名

(学生的姓名别名 S_name字符型长度 10)

5) 性别

(学生的性别别名 S_sex字符型长度 4)

6) 宿舍

(学生所在宿舍名称别名 S_dorm 字符型长度 20)

7) 联系方式

(学生的手机号码别名 S_tel字符型长度 20)

●数据结构名称:消费者

含义说明:来到食堂消费的人,这里指的是学生和教师

包括的数据项有:

1) 消费序号

(消费者来消费的序号别名 Consumer_number 字符型长度 6) 2) 姓名

(消费者的姓名别名 Consumer_name 字符型长度 10) 3) 性别

(消费者的性别别名 Consumer_sex字符型长度 10) 4) 消费类别

(消费者消费的类别,其中包括卡消费和现金消费别名 Consume_sort字符型长度 10)

5) 消费者类别

(消费者的类别,这里指学生或教师别名 Consumer_sort

字符型长度 10)

●数据结构名称:消费情况

含义说明:消费者在食堂的消费总体情况, 用于管理员的审查工作以及预算, 计算成本利润的工作。

包括的数据项有:

1) 一楼窗口

(一楼所有窗口一天内收入总和别名 Floor_one 字符型长度 6) 2) 二楼窗口

(二楼所有窗口一天内收入总和别名 Floor_two 字符型长度 6) 3) 三楼窗口

(三楼所有窗口一天内收入总和别名 Floor_three 字符型长度 6) 4) 一天消费总额

(一天内在食堂用餐的消费者所花费的总额,它的数值等于所有楼层的收入与消费者在包房所花费的总额别名 Total 长整型长度 6)

5) 日期

(记录的日期别名 Date 日期型长度 8)

5. 整体 E -R 图

范文三：面向对象设计-食堂信息管理系统

第 1章基于校园网的食堂管理系统的需求分析

需求分析是指理解用户需求, 就软件功能与客户达成一致, 估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程。在这个过程中, 用户的确是处在主导地位,需求分析工程师和项目经理要负责整理用户需求, 为之后的软件设计打下基础。需求分析阶段结束后,要求得到 SRS 文档 (SystemRequirement Specification)、 DRM 文档、 Acceptance Plan。从广义上理解:需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程,如图 1.1所示。

图 1.1广义的需求分析

狭义上理解:需求分析指需求的分析、定义过程。软件工程的历史中, 很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤, 但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话, 那么最后的软件实际上不可能达到顾客的需要, 或者软件无法在规定的时间里完工。需求分析之所以重要,就因为它具有决策性、方向性、策略性的作用,它在软件开发的过程中具有举足轻重的地位。在一个大型软件系统的开发中, 它的作用要远远大于程序设计。进行面向对象的系统分析, 首先, 要对该系统的主要功能进行描述明确系统实现的目标, 从而确定系统的功能需求; 再确定系统业务事件, 形成数据流程图; 最后识别出系统中的所有用例、角色以及各角色和用例问的联系,勾勒出用例图。

1.1系统实现目标

随着企事业单位后勤改革的深入, 食堂管理在企事业管理中的重要性同益突出。由于后勤管理的特殊性,食堂涉及的管理工作分支多、业务复杂、信息量大,而且变动频繁,使得其系统开发具有开发周期长、功能复杂、参加人员多、需求难以一次完全确定等特点。食堂用户主要由采购员、菜价核算员、饭菜销售员、送饭录入员、菜票登记员、客饭票制作员、部门负责人、经理、总经理等组成。

首先, 由采购人员到市场上采购做菜的原材料, 录入系统保存, 并且能随时增加、修改、

删除、查询、统计、打印清单。再由部门负责人、经理,审查清单。若无异议,在核对清单后进行电子签名, 此清单就作为这一天账目支出的一部分。同时, 系统能提供一些常用原料的相关信息。

在食堂做好菜后,提供每种菜的名称、单价等内容,录入系统保存,并且能随时增加、修改、删除、查询、统计、打印清单。这些清单在部门负责人、经理核对无误签名后,就成为饭菜销售的依据。系统能提供一般常用菜的相关信息,并能直接导入,以加快录入速度。现在, 销售人员可以根据上面提供的菜名直接对客户进行饭菜出售, 并且能随时增加、修改、删除、查询、统计、打印清单。这些清单在部门负责人、经理核对无误签名后,就成为这一天账目收入的一部分。食堂还考虑到给外面工地的班组进行送饭的情况, 先提出外出送饭申请 (包括日期、工程名称、工地名称、送饭总份数、联系人等内容 ) , 再进行外出送饭登记 (包括日期、送饭单位、送饭地点、送饭人员、通知人、通知时间、总份数、总价格等内容 ) 。这些清单仍需部门负责人、经理的审核,此清单就作为这一天账目收入的一部分。

另外, 系统还要进行了一般性的记录保存工作,如菜票登记、制订客饭票等。在菜票登记项目中, 菜票的销售清单作为这一天账目收入的一部分; 菜票的退还清单作为这一天账目支出的一部分。

终于到月底了, 系统能生成本月的销售总账与明细账, 并分别提交给部门负责人、经理与总经理等人进行审核,在全部审核通过后方可成为正式财务报表。

1.2系统基本功能需求

功能需求是描述系统必须支持的功能和过程的系统需求, 是系统必须完成的活动, 也就是系统将要投入的商业应用。功能需求直接来自计划阶段确定的系统功能。例如, 如果你正在开发一个工资系统, 那么需要的商业应用也许包括这样一些功能:书写支票、计算佣金数量、计算工资税、维护雇员的相关信息和向 IRS 报表年终税费减免。这些就是新系统的功能。确定和描述所有这些商业应用需要花费大量的时问和精力。功能列表和有关特性可能变得非常复杂。

1.2.1总体需求

功能需求是根据组织进行商业交易的过程和商业规则确定的。本系统要实现主要功能有: 1、用户能通过自己设置的用户名和密码登录系统,并能根据不同的用户级别进行相应操作。

2、在审核过程中,只有前一级别的人员审核通过后才能提交给后一级别的人员。若审核有异议的,可以加以说明提交给前一级别的人员要求重新进行审核。

3、系统能提供良好的界面,用户能直观地对此用户有关的信息直接操作,打开系统后立即就出现需要操作的相关信息, 比如需要他审核的内容、有异议要求重新审核的内容等信息。

4、系统管理员有权审核用户的合法性。

5、系统能记录用户操作日志,并能随时提供帮助。

1.2.2基本功能

l 、采购销售管理

(1)采购管理

采购员对原料可以进行增加、修改、删除、查询、统计、预览、打印等操作。在输入原料记录后,可以提交记录。提交可以是一条或多条记录。

(2)菜单管理

可以增加、修改、删除、查询、统计、预览、打印菜单。系统提供一些常用菜,以方便用户操作。

(3)销售管理

销售员可以增加、删除、修改、保存、查询、统计、预览、统计饭菜销售记录。系统提供菜单以便用户选取。

(4)送饭申请管理

客户可以增加、修改、删除、保存、查询、预览、打印送饭申请记录。并能增加、修改、删除送饭班组记录,能统计班组的总价格、总份数。

(5)送饭登记管理

销售员可以增加、插入、修改、删除、保存、查询、预览、打印送饭登记记录。并能增加、修改、删除送饭班组记录,能统计班组的总价格、总份数。

(6)菜票管理

销售员可以增加、插入、删除、保存、预览、打印菜票登记。

(7)客饭票管理

销售员可以增加、插入、删除、保存、预览、打印客饭票记录。

2、审批管理

(1)部门负责人可以查询未审批报表、已审批报表与正在审批报表,即可以查询报表的审批状态。

(2)在审核过程中,部门负责人审批后才能提交给后一级别的人员。若审批有异议的, 可以加以说明提交给前一级别的人员要求重新进行审批。

(3)只有全部审批完成后,才能正式提交成为财务报表。

3、系统管理

(1)可以对用户进行权限设置,以供用户根据不同的级别进行相应操作。

(2)可以设置审批流程,确定审批人员的审批顺序。

(3)对系统数据进行初始化, 对重要数据进行备份和复制, 确保系统的稳定性和安全性。 4、日志管理

(1)主要包括同志统计和对用户访问的统计。

(2)对行踪日志进行查询和对模块访问进行查询。

1.3系统主要业务流程图

1.3.1确定业务事件

事件是指可以描述、值得记录的在某一特定时间和地点发生的事情。系统的所有处理过程都是由事件驱动或触发的, 因此当你定义系统需求时把所有事件罗列出来并加以分析是很有意义的。

当为一个系统定义需求时, 先调查清楚能对该系统产生影响的事件是十分有用的。更准确地说, 什么事件发生时需要系统做出响应通过询问对系统产生影响的事件, 你可以把注意力集中在外部环境上, 而把整个系统看成一个黑盒。这最初的调查帮助你主要从高层次上全面考察系统, 而不是集中在系统内部工作上. 这也使你把注意力集中在系统和外界用户其他系统的接口上。最终用户, 即真正使用系统的人, 也习惯于按照那些影响他们工作的事件来描述系统需求。因此,当用户使用系统时,把重点集中在事件上也是非常恰当的。最后,把重点集中在事件上也提供了一种划分 (或分解 ) 系统需求的方法, 这样你就可以分别研究各个部分了。复杂的系统需要分解成易处理并能更好理解的小单元, 而按照事件来划分系统是实现这种分解的一种方法。

事件主要有三种类型:外部事件、临时事件和状态事件。分析员开始工作时要尽可能多地识别和列出这些事件,在与系统用户的交谈中不断细化这些事件列表。

1、外部事件

外部事件是指系统之外发生的事件, 通常都是由外部实体或动作参与者触发的。外部实体 (或动作参与者 ) 是一个人或组织单位, 它为系统提供数据或从系统获取数据。为了识别关键的外部事件, 分析员首先要确定所有可能需要从系统获取信息的外部实体。根据系统需求确定系统的外部事件包括以下几种:采购员采购菜原料、菜价员制定菜价、销售员销售饭菜、客人申请送饭、销售员登记送饭、销售员登记菜票、销售员制订客饭票、部门负责人审批只

报表、部门负责人审批月报表、部门负责人查询报表审批状态、系统管理员权限管理、系统管理员维护系统、系统管理员开志管理等。

2、临时事件

临时事件是由于达到某一时刻所发生的事件。许多信息系统在事先定义的时间间隔产生一些输出结果, 例如系统每同 (每月 ) 要生成统计报表。有时输出结果是部门需要定期获取的报表, 例如业绩报表或异常报表等。这些事件和外部事件不同, 因为系统是自动产生所需要的输出结果而不需要用户进行操作。换句话说, 没有外部实体或动作参与者下达命令, 而是系统自己在需要的时候产生所需的信息或其他输出。

分析员通过询问系统必须完成任务的具体时限来确定临时事件。在最后期限之前应该生成哪些输出结果 ? 在这期限到达时需要系统完成哪些处理任务分析员常常通过定义当时系统需要产生的结果来确定这些事件。在食堂管理系统中的一些临时事件。这些事件大多数为有关部门生成周期性报表:如生成日报表、生成月报表等。

3、状态事件

状态事件是指当系统内部发生了需要处理的情况时所引发的事件。例如, 产品的销售导致了库存记录的变化, 当库存降到了需要重新订货点之下时, 就有必要重新订货。该状态事件可以被命名为“到达订货点”。通常状态事件作为外部事件的结果而发生。有时,状态事件和临时事件相似, 惟一不同的地方在于, 状态事件无法定义事件发生的时刻。订货事件也可以被命名为“库存该重新订货了”,这样听起来就像临时事件。

1.3.2识别参与者

系统功能需求信息的主要来源是新系统的各种系统参与者。系统参与者是指对系统的成功实施感兴趣的人。通常,我们把系统参考者分为三类:第一类是用户,那些实际使用系统处理同常事务的人:第二类是客户, 购买和拥有系统的人;第三类是技术人员,确保系统运行在组织的计算机环境下的人。第四类是外部实体,例如食堂的顾客。图 1.2显示了对新系统感兴趣的各种系统相关者。在分析阶段, 分析员也需要考虑技术人员。在决定系统需求时最重要的步骤之一就是确定各种系统相关者。过去, 由于在项目中只包括了一些系统相关者, 并且系统仅仅是为这些人所设计,因此随着新系统的建立产生了一些问题。

图 1.2 对新系统开发感兴趣的各种系统相关者

l 、用户

用户角色,也就是系统用户的类型,应该从两个方向进行定义:水平方向和垂直方向。在水平方向上的意思是说分析员必须在商业部门中寻找信息流。例如, 一个新系统也许将要影响采购部门、销售部门和审批部门。你必须确保这些部门的每个人向你讲述他们的需求。销售部门可能提供一些需求信息束帮助你确定系统什么时候以及如何更新系统。审批部门也许需要系统的信息束审批报表。水平方向表明许多不同的部门, 甚至那些看起来和新系统无关的部门,都应该包括在系统需求定义中。

在垂直方向上, 我们需要操作用户、部门负责人员等提供信息需求。这些系统相关者中的每一个都将对系统有不同的信息需求,因此我们必须在设计时把这些信息需求包括在内。

通过对食堂管理系统的需求分析,可以确定系统中有六个参与者; 采购员、菜价员、销售员、部门负责人、客人和系统管理员。

(1)采购员:可以查询采购的录入信息、导入/导出采购计划、采购信息的统计和打印统计报表等。

(2)菜价员:可以制定菜价的录入信息、导入/导出常用菜单、菜单的统计、打印等。

(3)销售员:可以查询饭菜销售的录入信息、以及销售信息的统计、打印。

(4)部门负责人:可以获取账目报表、打印报表以及实行分级审批等。

(5)客人:可以进行申请送饭、以及菜票的登记、查询、打印等。

(6)系统管理员:系统管理员维护系统,可以添加、修改、删除数据库内的信息;可以添加、编辑,删除采购等信息:添加、修改和删除用户信息。

2、客户

尽管项目小组必须满足用户的信息处理需求, 但它也有责任满足客户的需求。

在许多情

况下, 客户和主管用户是同一组入。然而,客户也可能是单独的一组人。我们把客户包括在重要的系统相关者列表中, 这是因为项目小组必须在项目的整个开发过程中始终向客户提供项目进展的概要情况。

3、技术人员

尽管技术人员并不是真正的用户群, 但他们是许多技术需求的来源。技术人员包括建立和维护食堂计算机环境的人。这些人在诸如编程语言、计算机平台和其他设备方面对项目提供帮助。对某些项目来说,项目小组始终包括一组技术人员。而对另外一些项目来说, 只在需要时才把技术人员包括在内。

1.3.3确定系统的输入输出

确定系统的输入或输出主要包含两部分内容:

l 、找到与进入或离开系统事件相关联的信息。

2、对输入和输出命名。

一般来说, 输入和输出都被当作数据流。在面向对象系统中输入用消息表示; 输出可以用消息或输出对象来表示。当确定了事件、参与者和系统输入、输出后,用事件表列出它们是很有用的。确定事件列表时, 分析员要注意每个事件附加的信息,以备将来使用。这些信息被填入事件表中。一个事件表包括行和列, 行代表事件,列是事件的详细信息。事件表中的每行都记录了一个事件的信息。表中的每列代表了事件的一个关键信息。表 1.1给出了食堂管理系统的事件表。

表 1. 1食堂管理系统的完整事件表

对每个事件来说,系统怎么知道某一事件发生了呢 ? 用来通知系统某一事件发生了的信号称为系统输入。对于一个夕 }部事件,系统输入就是系统必须处理的数据到达了。例如, 当部门负责人发出审批同报表时, 同报表的详细信息就可以作为输入数据。知道数掘的来源也很重要。在本例中, 饭菜销售的信息来源是销售员一一个外部实体或参与者。对于临时事件,系统输入是某一个时间点。例如,在每 F1结束时系统就知道到了生成同报表的时刻了。目的地就是系统发送响应 (输出结果 ) 的地方, 也就是外部实体或参与者。有时实体根本不需要响应。例如, 如果采购员想修改采购信息, 那么新信息被记录在数据库中,但不需要产生任何输出结果。在数据库中记录信息就是活动或者用例的一部分。

1.3.4确定数据流程图

业务调查过程中绘制的管理业务流程图和表格分配图等虽然形象地表达了管理中信息的流动和存储过程, 但仍没有完全脱离一些物质要素 (如货物、产品等 ) 。为了用计算机进行信息管理, 还必须进一步舍去物质要素, 收集有关资料, 绘制出原系统的数据流程图, 为下一步分析做好准备。

1、数据流程图概述

数据流程图 (Data Flow Diagram ,简称 DFD) ,它是描述数据处理过程的有力工具。数据流程图从数据传递和加工的角度, 以图型的方式刻画数据处理系统的工作情况。数据流程图是一种能全面地描述信息系统逻辑模型的主要工具, 它可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况。数据流程图具有抽象性和概括性。抽象性表现在它完全舍去了具体的物质, 只剩下数据的流动、加工处理和存储; 概括性表现在它可以把信息中的各种不同业务处理过程联系起来, 形成一个整体。无论是手工操作部分还是计算机处理部分,都可以用它表达出来。因此,我们可以采用 DFD 这一工具来描述管理信息系统的各项业务处理过程。

2、数据流程图的绘制

(1)数据流程调查。数据流程调查过程中收集的资料包括:

①收集原系统全部输入单据 (如入库单、收据、凭证 ) 、输出报表和数据存储介质 (如账本、清单 ) 的典型格式。

②弄清各环节上的处理方法和计算方法。

③在上述各种单据、报表、账本的典型样品上或用附页注明制作单位、报送单位、存放地点、发生频度 (如每月制作几张 ) 、发生的高峰时日及发生量等。

④在上述各种单据、报表、账册的典型样品上注明各项数据的类型 (数字、字符 ) 、长度、取值范围 (指最大值和最小值 ) 。

(2)绘制数据流程图步骤。

绘制数据流程图的一般步骤如下:

① 定与本系统有关的外部实体,即确定与本系统有关的单位、部门和人。

② 定系统的处理单元,即确定系统中需要保存的文件和数据。

③ 确定系统的存储单元,即确定系统中需要存储的文件和数据。

④定合理布局。数据流程图各种符号要布局合理、分布均匀、整齐、清晰,使读者一目了然。这才便于交流,消除误解。一般系统数据主要来源的外部实体尽量安排在左方, 而数据主要去处的外部实体尽量安排在右边,数据流的箭线尽量避免交叉或过长。

⑤自顶向下逐层扩展。管理信息系统庞大而复杂, 具体的处理逻辑 (加工 ) 可能成百上千, 关系错综复杂, 不可能用一两张数据流程图明确具体地描述整个系统的逻辑功能, 自顶向下的原则为我们绘制数据流程图提供了一条清晰的思路和标准化的步骤。

⑥组织用户领导、管理人员和业务人员等各方面代表反复讨论、分析、比较, 直到得到一个用户和开发人员都能理解的、满意的数据流程图。

绘制数据流程图的过程是系统分析的主要过程, 同时也是一个多次反复的过程。一个数据流程图往往需要经过多次修改和讨论.才能最终确定。

按照数据流程图的步骤, 首先确定与本系统有关的外部实体一操作员。绘制顶层的数据流程图, 表示用户根据进行相应的食常管理处理, 经过一系列管理系统处理后, 再决定向用户发送清单,如图 1.3所示。

图 1.3 顶层数据流程图

然后, 绘制下一层的数据流程图。对顶层数据流程图的分解从 “处理逻辑 (加工 ) ” 开始, 将“食堂管理系统”分解为十四个主要的处理逻辑,如图 1.4所示。此外,根据具体情况还

应该对低层数据流程图再进行细分和分解, 并考虑处理过程中的例外情况。系统的主要处理逻辑功能描述如表 1.2所示。

图 1.4 系统数据流程图

表 1.2处理功能描述表

该表根据系统流程总图从编号、加工名称、参与者、功能概述等几方面描述了每个处理逻辑的详细信息,为进一步建立系统数据字典提供依据。

1.4系统数据字典

数据字典 (Data Dictionary, DD) 的作用就是对数据流程图上的每个成分给以定义和说明。数据字典描述的主要内容包括数据元素、数据结构、数据流、数据存储、处理功能和外部实体等,其中数据元素是组成数据流的基本成分。

数据字典是数据流程图的辅助资料, 对数据流程图起注解作用。数据字典, 在系统开发的各个阶段都具有重要作用。在分析阶段用束发现遗漏的数据, 在设计阶段用来进行数据库设计, 在运行阶段是系统维护的必要依据。数据字典中的数据构成如图 1.5所示的层次关系。

图 1.5 数据字典中数据的层次关系

这些数据元素的定义通常用定义式的形式给出。根据所考虑问题的大小, 一个数据处理系统的数据字典可能有几十、几百甚至几千个定义式,本系统的数据字典见附录 A 。

这些列表描述了系统数据字典的大部分内容, 它对系统中数据做出详尽的描述, 提供对数据库数据的集中管理。

1.5构建系统用例

依据系统的数据流程图以及系统中涉及的各级操作人员, 通过分析, 识别出系统中的所有用例和角色,描述出业务的用例和执行者,并建立相应的用例图 (Use Case) 。本系统中有如下用例存在:采购员采购菜原料、菜价员制定菜单、销售员销售饭菜、客人申请送饭、销售员登记送饭、销售员登记菜票、销售员制订客饭票、部门负责人审批同报表、部门负责人审批月报表、部门负责人查询报表审批状态、系统管理员权限管理、系统管理员维护系统、系统管理员日志管理等用例。

当具有许多用例时, 通常较为方便的做法对它们进行打包, 用例包可以代表一个系统或子系统。如果用例图中只显示了一个系统, 则就不需要代表系统边界的矩形了, 通常将其省略。在食堂管理系统中,将系统分别打包为“采购销售子系统”、“审批子系统”、“管理维护子系统”。

系统的用例图模型如图 1. 6到 1. 8所示。

图 1.6 采购销售子系统的用例建模图 1.7审批子系统的用例建模

图 1.8 管理维护子系统的用例建模

采购销售子系统包括采购员采购菜原料、菜价员制定菜单、销售员销售饭菜、客人申请送饭、、销售员登记送饭、销售员登记菜票、销售员制订客饭票;审批子系统包括部门负责人审批报表、部门负责人审批月报表、部门负责人查询报表审批状态; 管理维护子系统包括系统管理员权限管理、系统管理员维护系统、系统管理员日志管理等。

第 2章基于校园网的食堂管理系统设计

系统设计是系统开发过程中第二个重要阶段。在这一阶段中我们将要根据前一阶段系统分析的结果, 在已经获准的系统分柝报告的基础上, 进行新系统设计。系统设计包括两个方面,首先是总体结构的设计,其次是具体物理模型的设计。系统设计阶段的主要任务是:在科学、合理的设计和总体模型的基础上, 尽可能提高系统的运行效率、可变性、可控性和工作质量。充分利用并合理投入各类可以利用的人、财、物资源,使之获得较高的综合效益。系统设计是开发人员进行的工作, 他们将系统设计阶段得到的目标系统的逻辑模型转换为目标系统的物理模型, 该阶段得到工作成果一一系统设计说明书是下一个阶段系统实施的工作依据。

2.1设计原则

l 、简单性:在达到预定的目标、具备所需要的功能前提下,系统应尽量简单,这样可减少处理费用,提高系统效益,便于实现和管理。

2、灵活性和适应性:以便适应外界的环境变化。可变性是现代化企业的特点之一,是指其对外界环境的变化的适应能力。作为企业的管理信息系统也必须具有相当的灵活性, 以便适应外界环境的不断变化, 而且系统本身也需不断修改和改善。因此, 在这里系统的可变性是指允许系统被修改和维护的难易程度。一个可变性好的系统, 各个部分独立性强, 容易进行变动, 从而可提高系统的性能, 不断满足对系统目标的变化要求。此外,如果一个信息系统的可变性强可以适应其它类似企业组织的需要, 无疑地, 这将比从新开发一个新系统成本要低得多。

3、一致性和完整性:一致性是指系统中信息编码、采集、信息通信要具备一致性设计规范应标准;完整性是指系统作为一个统一的整体而存在,系统功能应尽量完整。

4、可靠性:系统的可靠性指系统硬件和软件在运行过程中抵抗异常情况的干扰及保证系统正常工作的能力。衡量系统可靠性的指标是平均故障间隔时间和平均维护时间。前者指平均的前后两次发生故障的时问, 反映了系统安全运行时间, 后者指故障后平均每次所用的修复时间, 反映系统可维护性的好坏。只有可靠的系统, 才能保证系统的质量并得到用户的信任,否则就是没有使用价值。

提高系统可靠性的途径主要有:

(1)选取可靠性较高的主机和外部设备;

(2)硬件结构的冗余设计,即在高可靠性的应用场合,应采取双机或双工的结构方案;

(3)对故障的检测处理和系统安全方面的措施,如对输入数据进行校检,建立运行记录

和监督跟踪,规定用户的文件使用级别,对重要文件的拷贝等。

5、经济性:系统的经济性是指系统的收益应大于系统支出的总费用。系统支出费用包括系统开发所需投资的费用与系统运行维护费用之和; 系统收益除有货币指标外, 还有非货币指标。

系统应该给用户带来相应的经济效益。系统的投资和经营费用应当得到补偿。需要指出的是, 这种补偿有时是间接的或不能定量计算的。特别是对于管理信息系统, 它的效益当中, 有很大一部分效益不能以货币来衡量。

2.2系统架构设计

一个项目的开始之初的系统构架决定了一个项目的成败。 “好的系统构架就等于成功的一半。 ”好的系统设计既利于维护, 有利于开发过程中的事务处理。要做好系统构架不是一朝一夕的事情, 要经过项目的考验。必须做到这几方面:熟练掌握设计模式, 并能灵活运用; 架构设计是骨架, 设计模式就是肉; 设计模式是支撑架构的重要组件; 时刻牢记架构设计的目标。

为此,我们将信息系统中比较关心的对象分层,可分为三层:用户界面层、业务层、数据访问层,再把各层中的一些公共部分提出来:权限管理、异常处理,这样得到包图 2.1如下。

图 2.1 总体设计包图

总体设计包图主要由三层结构包图和权限管理、错误处理包图构成。

1、用户界面包 (如图 2.2所示 )

图 2.2用户界面包

用户界面层的职责是:

(1)与用户的交互,接收用户的各种输入以及输出各种提示信息或处理结

(2)对于输入的数据进行数据校验,过滤非法数据。

(3)向业务处理对象发送处理请求。

根据用户界面的职责,设定如下包含类,如图 2. 3所示。

图 2.3 用户界面类

输入界面和输出界面继承了用户晃面类的方法, 通过用户界面类来实现数据校验、业务处理。

、业务处理包 (如图 2. 4所示 )

图 2.4 业务处理包

3、处理层的职责是:

(1) 实现各种业务处理逻辑或处理算法。

(2) 验证请求者的权限。

(3) 向数据访问对象发送数掘持久化操作的请求。

(4) 向用户界面层返回处理结果。

根据业务处理层的职责设计包含类,如图 2.5所示。

图 2.5 业务代理类

这里使用了代理 (Proxy)模式,用户界面对象只能通过业务代理对象来向业务对象发送请求。业务代理对象首先判断请求者的权限,然后转发合法请求者的请求。

3、数据访问包 (如图 2.6所示 )

图 2.6 数据访问包

数据访问层的职责是:

(1)实现数据的持久化操作

(2)实现事务处理。根据数据访问层的职责设计包含类,如图 2.7所示。

图 2.7 包含类

对于每一个业务处理中需要持久化操作的对象都可以对应为一个数据库访问对象, 在很多业务处理中需要请求多个数据库访问对象来进行数据的读写操作, 而这些操作又必须在同一个事务中, 这时需要用同一个数掘库连接对象来进行统一的事务处理。这罩的数据库连接类的创建用到了单件 (Singleton)模式,保证一个类仅有一个实例,一个客户在同一时刻只能用一个数据库连接对象。

4、权限管理包 (如图 2.8所示 )

图 2.8 权限管理包

权限管理的主要职责是:

(1)验证请求者的请求权限。

(2)提供请求者的权限列表。

根据权限管理的职责设计包含类,如图 2.9所示。

图 2.9 权限管理类

业务处理对象通过权限管理对象来验证权限, 权限管理通过操作员来获取权限列表, 操作员通过角色对象表获取角色名。

5、异常处理包 (如图 2.10所示 )

图 2.10 异常处理包

异常处理的职责:

(1) 汇报运行时的详细异常信息。

(2) 记录异常处理日志。

根据异常处理的职责设计包含类。如图 2.11所示。

图 2.11 异常处理类

因为异常处理类型比较多,如:系统异常、数据库异常、业务逻辑异常等,针对不同类型的异常处理方式也容易变,如:显示错误,记录文本日志,记录数据库同志等,所以这里使用了桥接 (Bridge)模式来实现,使各部分的变化比较独立。

6、架构的类图

将包图展开, 得到类图 (如图 2.12所示 ) , 它是架构的静态结构图, 表达了各个类之间的静态联系。

图 2.12 架构类图

该架构类图展现整个架构模型中存在的类、类的内部结构以及它们与其他类的关系等。输入界面和输出界面通过继承用户界面类来实现数据校验、业务处理等方法; 用户界面类通过调用业务代理类业务处理向权限管理类验证权限; 操作员类通过角色类构建权限列表; 业务对象类通过业务获取对数据持久化操作, 通过访问数据库访问对象进行操作, 在这期间的任何异常都交给异常处理对象处理; 异常处理类通过异常实现类实现系统异常、数据库异常、业务逻辑异常等。

7、架构的动态图

它是对象的动态结构图,表达了类对象之问的动态协助关系,如图 2.13所示。

该架构顺序图的流程:

1、界面对象在接收了用户的输入请求后,向业务代理对象发送处理请求。

2、业务代理对象接收到请求后,向权限管理对象发送验证权限请求。

3、权限管理对象验证权限后将验证结果返回给业务代理对象。

4、业务代理对象根据验证结果进行以下处理:对于不符合权限的请求则返回提示信息; 对于符合权限的请求,则将请求转发给业务对象。

5、业务对象进行业务处理。对于业务处理中的数据持久化操作,通过访问数据库访问对象进行操作, 期间的任何异常都交给异常处理对象处理。最后返回处理结果信息给业务代理对象。

6、业务代理对象将处理结果信息返回给用户界面。

2.3系统功能结构设计

管理信息系统的各子系统可以看作是系统目标下层的功能。系统功能分解的过程就是一个由抽象到具体、由复杂到简单的过程。所谓功能结构图就是按功能从属关系画成的图表, 图中每一个方框称为一个功能模块。分解得最小的功能模块可以是一个程序中的每个处理过程,而较大的功能模块则可能是完成某一任务的一组程序。

经过层层分解, 可以把一个复杂的系统分解为多个功能较单一的功能模块。这种把一个信息系统设计成若干模块的方法称为模块化设计方法。模块化是一种重要的设计思想, 这种思想把一个复杂的系统分解为一些规模较小、功能较简单的、更易于建立和修改的部分, 一方面, 各个模块具有相对独立性,可以分别加以设计实现,另一方面, 模块之间的相互关系 (如信息交换、调用关系 ) 则通过一定的方式予以说明。各模块在这些关系的约束下共同构成一个统一的整体,完成系统的功能。

功能结构设计的特点在于有很好的高内聚性和低耦合性。内聚性好的程序具有好的可变性和可维护性。修改执行独立功能的内聚性模块, 对程序中其它功能模块的影响很小。甚至根本没有影响。系统模块之间的相互联系程度叫偶合,如果是紧密偶合,系统将难以维护。因此, 功能结构设计的另一特点在于提高重用性。所谓的 “封装” 模块设计目的之一就是提高系统的可重用性。

根据食堂业务的管理系统的完成功能和如前所示的数据流程图, 可得到如下的系统结构功能图,如图 2.14所示。

图 2.13 架构顺序图

该系统功能结构图主要包括采购管理、菜单管理、销售管理、申请送饭管理、登记送饭管理、菜票管理、客饭票管理、报表管理、审批管理、权限管理、同志管理、系统管理等十二个子系统,每个子系统又有若干功能模块。

2.4系统的功能模块设计

系统逻辑模型中数据流图中的模块是逻辑处理模块, 模型中没有说明模块的物理构成和实现途径, 同时也看不出模块的层次分解关系, 为此在系统结构设计中要将数据流图上的各个逻辑处理模块进一步分解, 用模块结构图确定系统的层次结构关系, 并将系统的逻辑模型转变为物理模型。

图 2.14 食堂管理系统功能结构图

2.4.1模块分解的原则

在设计中, 将系统分解成为一些相对独立、功能单一的模块。如何度量模块之间的独立性昵 ? 在一个管理信息系统中,系统的各组成部分之间总是存在着各种联系的,将系统或子系统划分成若干模块, 则一个模块内部的联系就是块内联系, 而穿越模块边界的联系就是块间联系。由于模块之间的互相联系越多, 模块的独立性就越少,因此, 引入模块耦合和内聚的概念。耦合表示模块之间联系的程度。紧密耦合表示模块之问联系非常强,

松散耦合表示

模块之问联系比较弱, 非耦合则表示模块之间无任何联系, 是完全独立的。内聚表示模块内部各成分之间的联系程度。一般说来,在系统中各模块的内聚越大,则模块间的耦合越小。但这种关系并不是绝对的。耦合小使得模块间尽可能相对独立, 从而各模块可以单独开发和维护。内聚大使得模块的可理解性和维护性大大增强。因此, 在模块的分解中应尽量减少模块的耦合,力求增加模块的内聚。

2.4.2功能子模块设计

在以上得到系统结构功能图后, 并对其进行抽象处理后重新组合, 它大致表示出了本系统的功能模块情况,如图 2.15所示。

图 2.15系统功能模块图

该图显示了基本数据维护模块:主要针对一些基本数据, 如部门数据、员工数据、单位数据、常用菜数据等进行初始化。

数据处理模块:对数据进行一般性的编辑操作,如添加、插入、删除、提交等。

数据查询模块:主要对当闩数据、历史数据进行查询。报表审批打印模块:主要对日报表、月报表进行预览打印,并对其进行审批。在对图 2.15中的各个功能模块分别细分, 如图 2.16至图 2.19所示。

图 2.16 基本数据维护功能模块示意图

图 2.17 数据处理功能模块示意图

图 2.18 数据查询功能模块示意图

图 2.19 报表审批打印功能模块示意图

基本数据维护模块主要包括部门数据、员工数据、单位数据、常用菜数据、单位设置、类型数据和关系权限等。数据处理模块主要包括数据的添加、插入、

删除、提交、统计等。数据查询模块主要包括系统权限、报表查询、历史统计、历史数据、当同数据、日志数据等,其中历史统计模块又包括各种分类汇总信息。报表审批打印模块主要包括每同统计、报表审批、每月统计, 其中每日统计主要是统计一些表单, 每月统计主要是进行总支出与总收入的统计。

2.5系统的类设计

运用 UML 进行面向对象的系统设计,还要清晰描述所有的类,根据类转换成数据库,从而确定数据库的 ER 图。

2.5.1类设计原则

l 、开闭原则 (the Open Closed Principle, OCP)

一个模块在扩展性方面应该是开放的, 而在更改性方面是封闭的。在进行面向对象设计时,要尽量考虑接口封装机制、抽象机制和多胎技术。

2、替换原则 (the Liskov Substitution Principle, LSP)

子类应该可以替换父类, 并出现在父类能够出现的任何地方。是由 Liskov 在 1987年提出

的设计原则。

3、依赖原则 (the Dependency Inversion Principle, DIP)

在进行业务设计时, 与特定业务有关的依赖关系应该尽量依赖接口和抽象类, 而不是依赖于具体类, 具体类只负责相关业务的实现, 修改具体类不影响与特定业务有关的依赖关系。 4、接口分离原则 (the Interface Segregation Principle, ISP)

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口更好。 5、其他原则:

(1)类的结构层次以三到四层为宜;

(2)类的职责明确化 (一个类对应一个职责 ) 。

2.5.2创建设计类图

类图描述系统中类的静态结构。不仅定义系统中的类, 表示类之间的联系如关联、依赖、聚合等, 也包括类的内部结构 (类的属性和操作 ) 。类图描述的是一种静态关系, 在系统的整个生命周期都是有效的,如图 2.20所示

图 2.20系统的类图

该类图描述了菜原料类、饭菜类、菜单类、菜票类、客饭票类、报表类、送饭申请类、送饭登记类、报表审批状态类等的属性和方法, 以及它们之间的关系。报表类依赖于菜原料类,饭菜类、菜票类,客饭票类、送饭登记类、报表审批状态类,饭菜类依赖于菜单类,送饭登记类依赖于送饭申请类。

2.6数据库设计

数据库设计 (Database Design) 是指对于一个给定的应用环境, 构造最优的数据库模式, 建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求 (信息要求和处理要求 ) 。

数据库设计通常是在一个通用的 DBMS 支持下进行, 即利用现成的 DBMS 为基础。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。

2.6.1数据库和信息系统

信息系统是提供信息, 辅助人们对环境进行控制和决策的系统。数据库是信息系统的核心。它把信息系统中大量的数据按一定的模型组织起来, 提供存储、维护、检索数据的功能, 使信息系统可以方便、及时、准确地从数据库中获得所需的信息。

信息系统它分为三类:数据处理系统 (EDP)、信息管理系统 (MIS)、决策支持系统 (DSS)。数掘库和信息系统之间的关系有:

l 、数掘库是信息系统的核心和基础, 把信息系统中大量的数据按一定的模型组织起来, 提供存储、维护、检索数据的功能,使信息系统可以方便、及时、准确地从数据库中获得所需的信息。

2、数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。

3、数据库设计是信息系统开发和建设的重要组成部分。

4、数据库设计人员应该具备的技术和知识:数据库的基本知识和数据库设计技术、计算机科学的基础知识和程序设计的方法和技巧、软件工程的原理和方法应用领域的知识等。 2.6.2数据库设计的特点

1、数据库设计是硬件和软件的结合。

2、数据库应用系统的设计包括两部分:

(1)结构设计就是设计各级数据库模式,决定数据库系统的信息内容。

(2)行为设计它决定数据库系统的功能,是事务处理等应用程序的设计。

根据系统的结构和行为两方面特性, 系统设计开发分为两个部分, 一部分是作为数据库应用系统核心和基石的数据库设计, 另一部分是相应的数据库应用软件的设计开发。这两部分是紧密相关、相辅相成的,组成统一的数据库工程,如图 2.21所示。

图 2.21结构设计和行为设计示意图

传统的软件工程忽视对应用中数据语义的分析和抽象, 只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究,忽视了对行为的设计。

2.6.3面向对象的关系数据库设计

1、概念的区分。

有些人把面向对象的数据库设计 (即数据库模式 ) 思想与面向对象数据库管理系统

(OODBMS)理论混为一谈。其实前者是数据库用户定义数据库模式的思路, 后者是数据库管理程序的思路。用户使用面向对象方法学可以定义任何一种 DBMS 数据库,即网络型、层次型、关系型、面向对象型均可, 甚至文件系统设计也照样可以遵循面向对象的思路。面向对象的思路或称规范可以用于系统分第 4章基于校同网的食堂管理系统设计析、系统设计、程序设计,也可以用于数据结构设计、数据库设计。自上至下、自始至终地贯彻面向对象思路,是一个一气呵成的统一体。面向对象的数据库设计只是 OOSE 的一个环节。

2、应用对象模型与 RDMS 模型的映射。数据库设计 (模式 ) 是否支持应用系统的对象模型, 这是判断是否是面向对象数据库系统的基本出发点。由于应用系统设计在前, 数据库设计随后,所以应用系统对象模型向数据库模式的映射是面向对象数据库设计的关键。

(1)三层数据库模式面向对象模型的扩展。

一般数据库设计多参照 ANSL /SPARC 关于数据库模式的 3层标准结构提案。最接近物理数据库的内部模式由 DBMS 提供的 SQL 来描述。概念模式可以由若干个内部模式聚集而成,它是由数据库用户规范的一些表的集合。一般的概念模式是数据库物理模式作用域的边界。

它能

实现数据库的物理意义、特定 D 阴 S 的特殊操作对外部应用程序的信息隐蔽。外部模式是从特定用户应用角度看待的数据库模式, 从不同的应用出发对同一概念模式可以给出多种不同的外部模式。当外部应用系统以对象模型进行抽象时, 从各个应用出发抽象出的对象模型可以映射到外部模型上, 对此我们不妨称之为外部对象模型。但是, 外部模型只是概念模型的子集, 所以面向对象的数据库设计核心在于系统对象模型 (不妨称之为概念对象模型 ) 向数据库概念模型的映射。

(2)对象模型向数据库表的映射规则。

由于 RDBMS 是以二维表为基本管理单元的,所以对象模型最终是由二维表及表问关系来描述的。换言之, 对象模型向数据库概念模型的映射就是向数据库表的变换过程。有关的变换规则简单归纳如下:

①础类可以采用一类一表制或一类多表制的映射原则;

②当类之间有一对多关系时,一个表也可以对应多个类;

③存在继承关系的类可以映射为一个表, 用属性来区别不同的子类, 也可以是不同的子类分别映射一个表;

④ 属性映射为表字段,类之间的关联也用表字段来表示;

⑤ 关系数据库规范化原则来调整表结构。

根据数据库映射原则,将类图 2.20转换为系统的 ER 图如 2.22所示。

图 2.22 系统的 ER 图

按照系统的基本业务流程设计的主要数据库有:菜原料、菜票、客饭票、饭菜、菜单、送饭申请、送饭登记、报表、报表审批状态等。系统还对每个数据库设置了主键与外键。

范文四：食堂信息管理系统分析与设计

食堂信息管理系统分析与设计

一、系统开发的目的与意义

(一) 开发目的

由于当前学校的规模不断扩大，学生数量不断增加，学生信息量也成倍增长，食堂管理工作成为学校各项管理工作的一个重要部分。面对庞大的信息量，如何有效在提高食堂管理工作的效率是学校急需解决的问题。这样不仅提高了工作效率，也避免了以前手工作业的麻烦，从而使得管理者能够准确，有效的管理餐饮。

(二) 开发意义

为了满足食堂管理人员对菜谱信息、学生信息、学生存款、刷卡信息以及食堂物料物流进行高效的挂历，从而提高学生食堂的工作效率。

二、求分析与详细调查

(一)可行性分析

可行性分析是系统分析阶段的重要活动，是对系统进行全面、概要的分析。它的任务是确定项目开发是否必要和可行。它的主要目标是:进一步明确系统的目标、规模和功能，对系统开发背景、必要性和意义进行调查分析，并根据需要和可能提出拟开发系统的初步方案和计划，明确问题，对所提供系统大致规模和目标的几个有关约束条件进行论证，并且提出系统的逻辑模型和各种可能的方案，从而为系统开发项目的决策提供科学依据。

其主要从三个方面进行研究:

(1)技术可行性:对现有技术进行评价，以明确能否利用现有技术进行系统开发及系统实施。计算机网络技术的发展和计算机硬件性价比的不断提升，使计算机全面应用于医院管理的各个环节成为可能。C/S开发模式、COM、DCOM技术在国内各行各业的信息管理系统开发中已经被广泛采用，实践证明这些技术都非常适合食堂管理系统的开发。

(2)经济可行性:对组织的经济状况和投资能力进行分析，对系统建设、运行和维护费用进行评估，对系统建成后可能取得的社会及经济效益进行估计。连锁餐饮企业整体规模庞大，个体规模小而营管理相对简单统一，开发成本不高，一旦开发成功，即能直接应用在所有同种食堂。

(3)营运可行性:指系统对组织机构的影响，对现有人员和机构、设施、环境等的适应性以及进行人员培训补充计划的可行性。连锁餐饮企业整体规模庞大，个体规模小而营管理相对简单统一。所以食堂系统的计算机信息管理人才、计算机硬件设备、操作员的计算机应用能力都为系统的运行过程提供了可靠保证。

(二)调查组织结构

1、组织结构如下图所示

学生食堂管理系

用户登录刷卡管理销售管理

销售管理

预计销售排队管理服务态度

三、数据流程的生成

四、数据字典的编写

, 数据结构名称:卡信息

1)卡号(消费者卡的编号，与消费者办卡的先后顺序有关，字符型长度6)

2)余额(消费者卡中所剩的金钱数量，字符型长度 6) 3)办卡日期(消费者办卡的日期，日期型长度 8) 4)持卡者姓名(拥有信息卡的消费者的名称，字符型长度 10) 5)花费(消费者所消费的金钱数量，字符型长度 20)

, 数据结构名称:学生信息

1) 学号(学生在校所编的号码字符型长度 6) 2) 系别(学生所在的系的名称字符型长度 16) 3) 班级(学生所在的班级的班号字符型长度 20) 4) 姓名(学生的姓名字符型长度 10) 5) 性别(学生的性别字符型长度 4) 6) 宿舍(学生所在宿舍名称字符型长度 20) 7) 联系方式(学生的手机号码字符型长度 20)

, 数据结构名称:教师信息

1) 教师号 (教师的编号字符型长度 6)

2) 系别 (教师所在的系的名称字符型长度 10)3) 姓名 (教师的姓名字符型长度 6) 4) 性别 (教师的性别字符型长度 4) 5) 家庭住址(教师的家庭住址字符型长度 50) 6) 联系方式(教师的手机号码字符型长度 20)

, 数据结构名称:订餐信息

1) 订餐编号(消费者订餐的编号，以便管理字符型长度 6) 2) 顾客姓名(消费者的姓名字符型长度 10) 3) 联系方式(消费者的联系方式(手机号码) 字符型长度 20) 4) 约定时间(消费者订餐时所约定的吃饭时间日期型长度 8) 5) 备注信息(在订餐时其他的信息文本型长度 50)

, 数据结构名称:管理员信息

1) 管理员编号(管理员在食堂的编号字符型长度 6) 2) 姓名(管理员的姓名字符型长度 6)

3) 性别 (管理员的性别字符型长度 4) 4) 家庭住址 (管理员的家庭住址字符型长度 50) 5) 联系方式(管理员的联系方式字符型长度20) 6) 工资(管理员每个月的收入整型长度 20)

五、运行平台

a. CPU:最低 400MZ b.内存:64M

c.输入输出设备:键盘，鼠标 d.100M以上硬盘空间

e.操作系统:win XP f.开发工具:Delphi

六、系统功能结构图

食堂管理系统

消预成费订本库者信核存信息算管息管管理管理理理

消消消消预预预预入出费费费费成效订订订订库库者者者者信信信信本益商商信信信信查查息息息息品品息息息息查修添删询询查查查修添删询改加除询询询改加除

七、输入/输出设计

登陆成功后可进入系统进行相应的操作:软件对数据输入输入设计:输入用户名，密码,均进行数据有效性检查。输出设计:常用的输出设备:显示终端、打印机等。

输出介质:有纸张、磁盘、光盘、多媒体介质等;除指明提供打印输出外，其余数据输出

均不考虑打印输出。

八、E-R图

商品名称商品价格房间编号房间位置

出库时间库存信息

包房信息

管理订餐编号联系方式

管理员编所在家庭住址号约定时间订餐信息工资管理员信息联系方式备注信息

姓名顾客姓名性别

管理查询订餐

一楼窗口消费者类别消费类别二楼窗口

消费消费情况消费者

姓名

三楼窗口一天的消费总额

性别消费序号

日期

属于组成

教师号学号姓名

班级系别系别学生信息教师信息家庭住址

姓名

联系方式联系方式宿舍性别

使用持有性别

花费卡信息

持卡人姓名

卡号

余额办卡日期

九、程序流程图的绘制

食堂业务查

询

选择是哪种付款

方式

按学生录入按学生编号按学生名称顺序排序顺序排序顺序排序

是

输入或选择查选择查询

询条件条件

否

查看当前学生应显示查询付款明细结果

是应付款报表打印打印

否

退出

范文五：食堂信息管理系统分析与设计

----------------------------精品word文档值得下载值得拥有----------------------------------------------

食堂信息管理系统分析与设计

一、系统开发的目的与意义

(一) 开发目的

(二) 开发意义

为了满足食堂管理人员对菜谱信息、学生信息、学生存款、刷卡信息以及食堂物料物流进行高效的挂历，从而提高学生食堂的工作效率。

二、求分析与详细调查

(一)可行性分析

其主要从三个方面进行研究:

(二)调查组织结构

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

1、组织结构如下图所示

学生食堂管理系

用户登录刷卡管理销售管理

销售管理

预计销售排队管理服务态度

三、数据流程的生成

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

四、数据字典的编写

, 数据结构名称:卡信息

1)卡号(消费者卡的编号，与消费者办卡的先后顺序有关，字符型长度6)

2)余额(消费者卡中所剩的金钱数量，字符型长度 6)

3)办卡日期(消费者办卡的日期，日期型长度 8)

4)持卡者姓名(拥有信息卡的消费者的名称，字符型长度 10)

5)花费(消费者所消费的金钱数量，字符型长度 20)

, 数据结构名称:学生信息

1) 学号(学生在校所编的号码字符型长度 6)

2) 系别(学生所在的系的名称字符型长度 16)

3) 班级(学生所在的班级的班号字符型长度 20)

4) 姓名(学生的姓名字符型长度 10)

5) 性别(学生的性别字符型长度 4)

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

6) 宿舍(学生所在宿舍名称字符型长度 20)

7) 联系方式(学生的手机号码字符型长度 20)

, 数据结构名称:教师信息

1) 教师号 (教师的编号字符型长度 6)

2) 系别 (教师所在的系的名称字符型长度 10)

3) 姓名 (教师的姓名字符型长度 6)

4) 性别 (教师的性别字符型长度 4)

5) 家庭住址(教师的家庭住址字符型长度 50)

6) 联系方式(教师的手机号码字符型长度 20)

, 数据结构名称:订餐信息

1) 订餐编号(消费者订餐的编号，以便管理字符型长度 6)

2) 顾客姓名(消费者的姓名字符型长度 10)

3) 联系方式(消费者的联系方式(手机号码) 字符型长度 20)

4) 约定时间(消费者订餐时所约定的吃饭时间日期型长度 8)

5) 备注信息(在订餐时其他的信息文本型长度 50)

, 数据结构名称:管理员信息

1) 管理员编号(管理员在食堂的编号字符型长度 6)

2) 姓名(管理员的姓名字符型长度 6)

3) 性别 (管理员的性别字符型长度 4)

4) 家庭住址 (管理员的家庭住址字符型长度 50)

5) 联系方式(管理员的联系方式字符型长度20)

6) 工资(管理员每个月的收入整型长度 20)

五、运行平台

a. CPU:最低 400MZ

b.内存:64M

c.输入输出设备:键盘，鼠标

d.100M以上硬盘空间

e.操作系统:win XP

f.开发工具:Delphi

六、系统功能结构图

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

食堂管理系统

消预成费订本库者信核存信息算管息管管理管理理理

七、输入/输出设计

输入设计:输入用户名，密码,登陆成功后可进入系统进行相应的操作:软件对数据输入均进行数据有效性检查。

输出设计:常用的输出设备:显示终端、打印机等。

输出介质:有纸张、磁盘、光盘、多媒体介质等;除指明提供打印输出外，其余数据输出均不考虑打印输出。

八、E-R图

商品价格商品名称房间编号房间位置

出库时间库存信息

包房信息

----------------------------精品word文档值得下载值得拥有---------------------------------------------- 管理 ----------------------------------------------------------------------------------------------------------------------------- 联系方式订餐编号

管理员编所在家庭住址号约定时间

订餐信息

----------------------------精品word文档值得下载值得拥有----------------------------------------------

九、程序流程图的绘制

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

----------------------------精品word文档值得下载值得拥有----------------------------------------------

食堂业务查

询

选择是哪种付款

方式

按学生录入按学生编号按学生名称

顺序排序顺序排序顺序排序

是

输入或选择查选择查询

询条件条件

否

查看当前学生应显示查询付款明细结果

是

应付款报表打印打印

否

退出

----------------------------精品word文档值得下载值得拥有----------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------

转载请注明出处范文大全网 » 枫桦楼食堂信息管理系统