实验室设备管理系统实验报告.docx
《实验室设备管理系统实验报告.docx》由会员分享，可在线阅读，更多相关《实验室设备管理系统实验报告.docx（9页珍藏版）》请在冰豆网上搜索。
实验室设备管理系统实验报告
朋犬聽
个人课程设计报告
院系计算机与通信工程学院—
专业—计算机（中加）
学号20106098
姓名
角色_A_
日期2013/6/20_
个人课程设计报告
一项目概述
1.1目的
因为现在各个高校内教学设备众多但自动管理水平相比过低，很多高校
管理设备都采用在设备购进以后将设备的基本情况和相关信息登记存档。
存
档以后，档案基本就没人记录与维护，至于以后设备的变迁或损坏都不会记录在设备档案中，即不能体现设备的即时状态。
而有些即使有设备管理系统的单位，就算是能把设备的即时信息体现在设备档案上，但设备的缺陷处理及设备缺陷等功能没有实施，设备检修的备品备件情况和检修成本核算没有实现，整个学校教学设备管理信息化仍处于较低水平。
将管理任务分成小
块，落实到个人并能随时查询设备当前情况和历史情况，对设备的可靠性分析有直接作用，使管理人员从手工计算、统计工作中解脱出来。
同时基于实验室管理者对设备的的使用情况进行统计和更新提供轻松快捷的管理方式，利用计算机管理系统管理我校的实验设备势在必行，也方便广大用户可以随
时随地的借用实验设备进行学习和研究。
1.2任务
对项目进行可行性研究，需求分析，项目开发计划，以及中期的总控模块开发，参与软件的设计和测试。
1.3开发环境
♦硬件环境：
建议硬件配置PII以上256M内存60G硬盘空间。
♦软件环境：
需要安装MicrosoftAccess4.0以上的版本，基本上
MicrosoftWindows系统用户都有。
♦数据库：
MicrosoftAccess4.0以上
1.4参考资料
《C#数据库精通》作者：
王华杰清华大学出版社出版
《C#程序设计教程》作者：
李春葆清华大学出版社出版
二项目中本人参与实现的部分
1.描述所参与阶段的内容
2.1.1概述
我主要参与到分析部分和设计、测试。
开发软件系统最为困难的部分就是准确说明开发什么。
最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。
同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
这就是需求分析。
在设计时，把各模块详细化设计，初步定义将要使用的基本函数，要使用的
变量，全局变量，局部变量，SQL语句的函数执行（传人的语句为参数，然后操作语句），用户登录的验证，权限设置，数据库表的导入与导出，打印输出显示表，通过对表的操作，修改反馈回数据库等。
2.1.2开发目标
系统实现前，人力与费用相对减少；处理速度提高（短时间内显示查询结果）；查询的绝对精度，并在限定时间内尽可能完成目标。
系统实现后，能够及时反映实验室的设备情况，能够让实验室管理员及时做好对实验室的布置，从而提高了工作运行效率和效果和资金的节省。
2.1.3对现有系统的分析
现有系统大多采用SQL乍为数据库，而ACCESS据库相对于SQ来说，更多的用户都安装有，而且速度，效率一点不比SQL#，而且不需要服务器，缺点是存储大量数据（100M以上）的时候效率下降。
本软件采用ACCESS据库，对于实验室的设备信息存储，一年大约存1KB勺大小，所以ACCESS据库非常适合。
2.1.4技术可行性分析
顶层数据流图
登录信息
设备管理员
>
卓无效登录信息
申请/维修/报废/查询操作-
实验室设备管理系统
审核结果
上级领导
*处理结果
0层数据流图
1层数据流图
用户
1
合法信息
1
222.32.4
2.1
D1
设备基本
D2
维修记录
D3
申请表
D4
新设备表
D5
报废记录
表
表
本实验室设备管理系统，要求对实验室设备进行统计查询，对设备维修、报废情况的处理记录，能够申请购买新设备、更像申请表等。
本系统还要求用户登入具有一定的权限，能执行相关的操作。
当设备需要报废和购买还需要得到上级领导的审核批准。
现有系统大多采用SQL乍为数据库，而ACCESS据库相对于SQ来说，更多的用户都安装有，且不需要服务器。
本软件采用ACCESS据库，对于实验室的设备信息存储，一年大约存1KB勺大小，所以ACCESS据库非常适合。
2.1.5数据描述一一静态数据
1）基础信息设备信息表结构:
ID
类别
设备名
型号
规格
单价
购置日期
生产厂家
经办人
状态
设备信息表各字段具体描述:
字段名称
类型
长度
是否为NULL
备注
ID
int
2
否
主键，自动添加
类别
varchar
20
是
设备名
varchar
20
是
型号
varchar
20
是
规格
varchar
20
是
单价
double
4
是
购置日期
date
4
是
生产厂家
varchar
30
是
经办人
varchar
10
是
状态
varchar
6
否
设备申请表结构:
ID
类别
设备名
型号
规格
单价
申请日期
数量
经办人
状态
设备申请表各字段具体描述:
字段名称
类型
长度
是否为NULL
备注
ID
int
2
否
主键，自动添加
类别
varchar
20
是
设备名
varchar
20
是
型号
varchar
20
是
规格
varchar
20
是
单价
double
4
是
申请日期
date
4
是
数量
int
2
是
经办人
varchar
10
是
状态
varchar
6
否
设备修理表结构:
修理号
ID
类别
设备名
型号
规格
修理费用
修理日期
修理厂家
经办人
状态
设备修理表各字段具体描述:
字段名称
类型
长度
是否为NULL
备注
修理号
int
2
否
主键，自动添加
ID
int
2
否
参照设备表ID
类别
varchar
20
是
设备名
varchar
20
是
型号
varchar
20
是
规格
varchar
20
是
修理费用
double
4
是
修理日期
date
4
是
修理厂家
varchar
30
是
经办人
varchar
10
是
状态
varchar
6
否
2.1.6E-R图
密码
用户
登入权限
管理
名称
类别
实验室
存放
设备名称
故障
型号
生产厂
类别
豕
购买日期
购买人
单价
规格
数量
数量
规格
型号
维修人或者修理厂家
维修费用
修理日期
维修报表
设备编号
设备
2.描述此部分实现的具体过程。
2.1.1分析部分
需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。
它的另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。
有些需求分析专家拓展了这个概念：
“从系统外部能发现系统所具有的满足于用户的特点、功能及属性等”。
这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。
所以我从它的定义（从用户需要进一步转移到了系统特性）为出发点撰写：
需求是指明必须实现什么的规格说明。
它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
不难发现：
并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。
系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。
任何文档形式的需求仅是一个模型，一种描述。
而这次试验，我们既是客户，又是受委托人，除了题目中一些硬性的要求，其他如语言，环境，界面设计等都是我们主观的去写，这样还是比较简单的。
2.1.2设计部分
1.软件初运行状态，数据库未链接，用户权限为游客。
升级会员 