仓库设备管理系统Word文档格式.docx
- 文档编号:16545125
- 上传时间:2022-11-24
- 格式:DOCX
- 页数:29
- 大小:1.13MB
仓库设备管理系统Word文档格式.docx
《仓库设备管理系统Word文档格式.docx》由会员分享,可在线阅读,更多相关《仓库设备管理系统Word文档格式.docx(29页珍藏版)》请在冰豆网上搜索。
(4)按照一定的条件查询、统计符合条件的设备信息;
查询功能至少应该包括设备基本信息的查询、按时间段(如在2004年1月1日到2004年10月10日购买、借出、维修的设备等)查询、按时间点(借入时间,借出时间,归还时间)查询等,统计功能至少包括按时间段(如在2004年1月1日到2004年10月10日购买、借出、维修的设备等)统计、按设备基本信息的统计等;
(5)对查询、统计的结果打印输出。
2.2.2性能需求
1.时间特性
查询服务部分:
用户通过电脑提交查询命令到返回结果不超过5秒钟。
数据管理部分:
提交某一数据录入到结果返回不超过5秒钟。
2.系统实用性:
为了提高系统效率,系统提供了多种形式的对话框,并在设计过程中考虑尽量减少用户的输入。
为了提高查询效率,系统提供了多种组合查询及模糊查询。
3.安全可靠性
操作员口令应采用加密存放方式,不同权限的用户对数据有不同层次的访问:
禁止、浏览、修改等;
要设计好系统的差异或增量备份以及操作日志。
4.可扩充性
(1)编码要尽可能采用行业标准,自行编码也应合乎规范。
(2)设计应考虑可扩充性,以适应今后能对数据库中的所有信息进行及时更新。
(3)使用字典数据,建立字典表,一方面减少数据存储,另一方面维护容易。
5.环境规定
(1)硬件环境
服务器端的最低配置是由建立站点所需的软件来决定的,在最低配置的情况下,服务器的性能往往不尽如人意,现在的硬件性能已经相当出色,而且价格也很便宜,因此通常应给服务器端配置高性能硬件。
而客户端主要用于浏览和操作数据,所以对客户端的硬件要求不高,不过现在的电脑都有很好的配置,所以一般都是没有太大问题,假如遇到问题,那应该提升下电脑的配置。
本网络服务器端的配置如下:
CPU:
InterPentium42.4GHz或者更高.
内存:
256MB.
硬盘大小:
80GB.
光驱:
CD-ROM52X.
显卡:
SVGA显示适配器.
(2)软件环境
操作系统:
WindowsXP.
JRE:
JDK1.5.
Web服务器:
Tomcat5.0.
数据库:
MSSQLServer2000.
浏览器:
Maxthon2.0.
7.其它专门需求
在程序的开发过程中,应遵循结构化的程序设计原则,设立运行日志,加强系统的可维护性;
注重系统的界面友好性、各程序模块界面的统一
2.3系统需求建模
在进行用例建模之前,我们首先了解到用例模型描述的是外部执行者(Actor)所理解的系统功能。
它主要用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。
它的重要作用对于我们住院管理系统的分析和设计主要体现在以下几个方面:
首先,它描述了待开发系统(仓库设备管理系统)的功能需求;
其次,它将系统看作黑盒,从外部执行者的角度来理解系统;
再次,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和UML的各个模型。
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。
在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。
几乎在任何情况下都会使用用例。
用例用来获取需求,规划和控制项目。
用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。
大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。
2.3.1确定参与者
在分析过程开始的时候,我们考虑到获取用例首先要找出系统的执行者。
,有鉴于此,我们通过用户回答一些问题的答案来识别执行者。
1.谁使用系统的主要功能(主要使用者)。
2.谁需要系统支持他们的日常工作。
3.谁来维护、管理使系统正常工作(辅助使用者)。
4.系统需要操纵哪些硬件。
5.系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
6.对系统产生的结果感兴趣的人或事物。
通过回答这六个问题以后,再进一步分析可以识别出本系统的两个角色:
用户和仓库管理员。
2.3.2确定用例
在对现行住院管理系统的分析过程中,在我们获取了执行者之后,我们就对每个执行者提出以下问题以获取用例。
1.执行者要求系统提供哪些功能(执行者需要做什么)。
2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。
3.必须提醒执行者的系统事件有哪些,或者执行者必须提醒系统的事件有哪些,怎样把这些事件表示成用例中的功能。
4.为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现。
除了以上考虑到的问题之外,我们还考虑了一些不针对具体执行者问题(即针对整个系统的问题),以使自己的分析结果更加准确。
1.系统需要何种输入输出,输入从何处来,输出到何处。
2.当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题。
因为系统比较大,因此不可能给出全部的分析过程,因此列举出在住院分系统中一部分比较有代表性的过程。
通过分析可以初步识别出系统的用例为:
借设备、还设备、查询设备、打印设备信息、删除设备信息、统计功能、维修设备、登录。
2.3.3系统用例建模
针对HIS系统的流程的分析,我们采用的是面向对象的分析方法(OOA)。
使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图,在此模型中列出了系统中的用例和参与者,并显示哪个参与者参与了哪个用例的执行。
住院管理系统的用例图如图2.1所示。
2.3.4用例描述
1.借设备
概述:
该用例说明用户如何借用仓库的设备。
前置条件:
设备管理员登录系统,用户提出借用设备请求。
后置条件:
设备管理员登记用户借用设备情况并录入系统中。
实现过程:
(1).用户来的仓库,查询设备情况,提出所要借用的设备。
(2).管理员登录,记录用户借用设备情况并录入系统。
(3)管理员收取一定的押金。
(4).如果没有用户所要的设备,则退出系统。
2.还设备
该用例说明用户归还仓库设备。
用户借用仓库设备。
设备管理员记录用户归还设备情况,录入系统。
实现过程(事件流):
(1)用户来到仓库向管理员提出归还设备申请。
(2)设备管理员登录系统,修改用户借用设备情况。
(3)设备管理员收取一定数额的租金。
3.查询设备信息
该用例说明用户和管理员查询仓库设备的信息。
设备信息已登记入系统。
用户和管理员查询设备信息。
4.打印设备信息
用户和管理员想更清楚的了解设备信息,打印出设备信息的详细明细表。
完成设备的查询。
更加清楚设备情况,有利于用户借用设备。
(1).用户申请查询设备。
(2).管理员登录系统进行查询。
(3).打印设备信息表。
5.删除设备信息
设备管理员删除报废的设备或已不存在的设备信息。
设备报废不存在。
设备信息的到更新。
管理员登录系统删除已没有的设备信息。
6.统计
随时统计现有设备的详细信息。
管理员登录系统。
设备信息统计更新数据库。
7.新设备信息录入
管理员往系统中录入新设备的详细信息
新设备入库。
更新设备信息数据库。
(1).设备入库。
(2).管理员将设备信息录入的系统中。
图2.1仓库设备管理系统用例图
3.仓库设备管理系统分析
3.1系统用例建模
由于此系统是一个独立的小系统所以整个系统的用例模型与前面的用例需求的用例模型是一样的,则系统的用例图如图3.1
图3.1系统的用例图
3.2静态结构模型
3.2.1类的识别
进一步分析系统需求,发现类以及类之间的关系,确定它们的静态结构和动态行为,是面向对象分析的基本任务。
系统的静态结构模型主要用类图和对象图描述系统中主要的类。
在系统分析过程中,要严格考察每个候选对象,从中去掉不正确的或不必要的,仅保留确实应该记录其信息或需要其提供服务的那些对象。
筛选类时主要依据冗余、无关性、笼统、属性、操作和实现等标准,删除不正确或不必要的类与对象
1.找出候选的类与对象
根据给出的需求陈述,从陈述中找出下列名词,可以把它们作为类与对象的初步的候选者:
中央计算机,分计算机,管理员,设备,设备信息,仓库,新增设备信息,统计情况,还设备信息,接设备信息,删除设备信息,用户,访问,登陆。
通常,在需求陈述中不会一个不漏地写出问题域中的所有有关的类与对象,因此,分析员应该根据领域知识或常识进一步把隐含的类与对象提取出来。
2.筛选出正确的类与对象
通过一个简单、机械的过程不可能正确地完成分析工作。
非正式分析仅仅帮助人们找到一些候选的类与对象,接下来应该严格考察每个候选对象,从中去掉那些不必要的,仅仅保留确实应该记录其信息或需要其提供服务的那些对象。
筛选时主要依据下列标准,删除不正确或不必要的类与对象。
(1)冗余
如果两个类表达了同样的信息,则应该保留在此问题域中最富于描述力的名称。
(2)无关
现实世界中存在许多对象,不能够把它们都纳入到系统中去,仅需要把与问题密切相关的类与对象放进目标系统中。
(3)笼统
在需求陈述中常常使用一些笼统的、泛指的名词,虽然在初步分析中把它们作为候选的类与对象列了出来,但是,要么系统无须记忆有关它们的信息,要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务,因此通常把这些笼统的或模糊地类去掉。
在该系统中就出现了一些笼统含糊的名词。
总之在本例中应该去掉“访问”、“登录”“访问”等候选类。
(4)属性
在需求陈述中有些名词实际上描述的是其他对象的属性,应该把这些名词从候选类与对象中去掉。
该系统中的“登录密码”应作为属性对待。
综上所述,在成绩管理系统中,进过初步筛选,剩下的类与对象包括用户,管理员,设备信息,新增设备信息,删除设备信息,统计情况,还设备信息,借设备信息。
3.2.2类的关联分析
多数人习惯于在初步分析确定了问题域中的类与对象之后,接下来就分析确定类与对象之间存在的关联关系。
当然这样的工作顺序并不是绝对必要的。
由于在整个开发过程中面向对象概念和表示符号的一致性,分析员在选取自己习惯的工作方式时拥有相当大的灵活性。
在需求陈述中使用的描述性动词或者动词词组,通常表示关联关系。
因此,在初步确定关联时,大多数关联可以通过提取需求陈述中的动词词组而得出。
通过分析需求陈述,还能发现一些隐含的关联。
在此系统中:
1.用户与还的设备之间存在“一对多”关系。
2.用户与设备信息之间存在“一对多”关系。
3.设备管理员与要借的设备之间存在“一对多”关系。
4.设备管理员与设备信息信息之间存在“一对多”关系。
5.设备管理员与维修设备信息之间存在“一对多”关系。
6.设备管理员与新增设备信息之间存在“一对多”关系。
7.设备管理员与删除设备信息存在“一对多”关系。
8.用户与要借的设备之间存在“一对多”关系。
3.2.3类的属性描述
属性是对象的性质,通过对象类和结构有更深入,更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关,也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性,不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性,以后在逐渐把其余属性添加进去。
此次分析过程中,我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性,从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下:
用户——编号、姓名、所在单位、地址、身份证号。
设备管理员——编号、姓名、。
设备信息——设备编号、设备型号、功能、租金、价格。
统计情况——统计报表编号。
还的设备——编号、借时间、还时间、价格。
借的设备——编号、借时间、还时间、价格。
维修设备信息——编号、所出的问题、维修时间。
新增设备信息——编号、功能。
删除设备信息——编号、原因。
3.2.4类图的构建
经过以上各个过程的分析可得出系统的类图如图3.2,
图3.2仓库设备管理系统类图
3.3系统动态模型
3.3.1系统执行顺序分析
顺序图建模元素有对象(参与者的实例也是对象)、生命线(lifeline)、控制焦点(focusofcontrol)、消息(message)等。
下面对系统各个顺序图进行详细介绍。
1.根据对用户登录用例的分析,当设备管理员进行增加设备信息、删除设备信息等操作时,系统会验证是否登录,所以设备管理员在进行操作前,需要先登录系统。
登录顺序图如图3.3
图3.3登录顺序图
2.当有新设备入库时,由管理员利用本系统本功能将设备信息添加到设备信息表中。
新设备录入顺序图如图3.4
图3.4新设备录入顺序图
3.当用户或者管理员想查询设备信息时,可以利用此功能。
此功能又分为:
①输入设备名称,查询设备基本信息;
②按时间段查询:
输入要查询的时间段,选择要查询的功能(比如选择“购买”、“借出”、“维修”的设备等)查询示例:
如查询在2004年1月1日到2004年10月10日购买的设备的详细信息等
③按时间点查询:
输入要查询的时间点,选择要查询的功能(比如选择“借入时间”,“借出时间”,“归还时间”)。
则查询设备顺序图如图3.5
图3.5查询设备顺序图
4,当有用户要借设备时,用户向设备管理员提出申请,设备管理员利用此系统进行借出登记。
借设备顺序图如图3.6
图3.6借设备顺序图
5,当用户所借设备时间到时,归还设备时,由设备管理员利用此系统归还设备,删除用户的借设备记录,并将设备信息表中相应设备状态更改为能借出。
还设备顺序图如图3.7。
图3.7还设备顺序图
6.设备管理员可以利用此功能进行设备信息的统计。
细分为:
①设备基本信息的统计:
输入设备名或者设备ID,再根据设备名或者设备ID进行设备详细信息的统计,可对统计结果进行打印。
②按时间段统计:
输入要统计的时间段,选择要统计的方面(购买、借出、维修)(比如:
统计在2004年1月1日到2004年10月10日期间购买的设备)。
统计顺序图如图3.8。
图3.8统计顺序图
7.当有设备需要维修时,设备管理员先利用此功能将设备信息表中相应设备的状态修改为维修中,并将此设备添加到维修表中,然后再将相应设备拿去维修。
设备维修顺序图如图3.9
图3.9设备维修顺序图
8,当有设备报费时,设备管理员利用此功能将相应设备记录从设备信息表中删除。
删除设备信息顺序图如图3.10
图3.10删除设备信息顺序图
3.3.2系统的协作分析
合作图也称为协作图,用于描述相互合作的对象间的交互关系和链接关系。
与顺序图一样,合作图也展示了对象间的动态协作关系。
它除了说明信息的交换外,还显示对象间的连接关系,描述信息在连接的对象之间的传递。
根据以上对仓库设备管理系统各模块的分析得出的顺序图,可以得出该系统各模块的协作图如下:
1.登录协作图如图3.11
图3.11登录协作图
2.新设备信息录入协作图如图3.12
图3.12新设备信息录入协作图
3.查询设备协作图如图3.13
图3.13查询设备协作图
4.借设备协作图如图3.14
图3.14借设备协作图
5.还设备协作图如图3.15
图3.15还设备协作图
6.统计功能协作图如图3.16
图3.16统计功能协作图
7.设备维修协作图如图3.17
图3.17设备维修协作图
8.删除设备信息协作图如图3.18
图3.18删除设备信息协作图
3.3.3系统状态分析
状态图描述了事件和对象状态的关系。
顺序图和协作图都属于交互图,主要用来描述系统对象之间的动态协作关系,以及写作过程中的行为次序。
交互图常用来描述一个用例中的几个对象协作工作的行为,显示该用例中所涉及的对象和这些对象之间的消息传递情况,但是并不对这些对象的行为,就应该使用状态图。
根据对各模块的用例分析得出各模块的状态图如下:
1.登录状态图如图3.19
图3.19登录状态图
2.增加设备信息状态图如图3.20
图3.20增加设备信息状态图
3.借设备状态图如图3.21
图3.21借设备状态图
4.还设备状态图如图3.22
图3.22还设备状态图
5.查询设备信息状态图如图3.23
图3.23查询设备信息状态图
6.统计设备信息状态图如图3.24
图3.24统计设备信息状态图
3.3.4活动分析
活动图是由状态图转化而来的,它描述了系统中各种活动执行的顺序,刻画了一个系统中所要进行的各项活动的执行流程。
根据上文中绘制得出的顺序图以及合作图,对两图中相互交互的对象进行分析可以得出系统各主要模块的活动图:
1.登录活动图如图3.25
图3.25登录活动图
2.增加新设备活动图如图3.26
图3.26.增加新设备活动图
3.借设备活动图如图3.27
图3.27借设备活动图
4.还设备状态图如图3.28
图3.28还设备状态图
5.查询设备信息活动图如图3.29
图3.29.查询设备信息活动图
6.统计设备信息活动图如图3.30
图3.30统计设备信息活动图
4.仓库设备管理系统设计与实现
4.1UML体系结构设计
住院管理子系统采用面向对象技术对系统进行总体的设计和实现,用UML及其集成环境RationalRose对系统进行分析和建模,采用PowerBuilder’s完成组件平台建设,后端数据存储是当前流行的Oracle9i数据库。
本系统基于PowerBuilder’s构建三层C/S结构,数据库服务器运行数据库管理系统软件,COM+组件运行在应用服务器上,客户机运行住院管理系统客户端软件。
4.1.1硬件体系结构设计
本系统采用C/S结构开发,三层C/S结构是在客户和服务器之间引入应用层的概念,即在客户端与数据库之间加入了一个“中间层”。
它将应用逻辑移到应用层完成,而客户端弱化为一个图形用户接口,成为一个瘦客户机。
其解决方案是:
对这三层进行明确分割,并在逻辑上使其独立形成三层软件结构。
在这种结构中,表示层、业务逻辑层和数据访问层在逻辑上是彼此分离的,表示层向用户提供数据,并有选择地允许用户使用逻辑数据。
对于基于PC的应用程序来说,本机用户和基于Web的用户接口是其两个主要的用户接口。
本机用户接口使用底层操作系统服务,基于Web的用户以HTML为基础,可通过任何平台的浏览器来阅读。
本系统的三层C/S结构如图4.1所示。
图4.1三层硬件体系结构图
4.1.2软件体系结构设计
信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架,一般呈现多层次结构模式。
子系统是对软件进行分解的一种中间形式,也是组织和描述软件的一种方法。
软件结构设计就是把软件分解成多个子系统,并确定各子系统及其接口之间的相互关系。
软件体系结构设计是一个从较高层次进行的设计,用来定义包(子系统),描述包之间的依赖性及通信机制。
目的是要设计一个清晰简单的体系结构,具有很少的依赖性,而且尽可能避免双向依赖。
仓库设备管理系统系统包图如图4.2所示。
图4.2软件体系结构图
4.2系统实现
本章使用UML建模技术,对住院管理系统进行了建模设计,使的开发出的产品在面对不同的客户时方便修改和维护,大大减少了投入的人力和时间,同时大大缩小了产品的成本。
在UML中,描述实现的视图称为组件视图。
它对模型中的组件建模,描述应用程序搭建的软件单元以及组件之间的依赖,从而可以估计更改的影响。
它还对类及其他元素在组件中的分配建模。
布局视图包括组件图、配件图以及配置图,他们分别从不同的角度反映并显示了本系统的软件和硬件的物理配置。
4.2.1组件分析
组件可以看作包与类对应的物理代码模块,逻辑上与包、类对应,它实际上是一个文件,可以有源代码构件、二进制构件、可执行构件。
构件对外提供的可见操作和属性称为构件的界面。
在UML中,组件图描述了组件及组件之间的关系,表示了组件之间的组织和依赖关系。
组件图是用来为面向对象系统的物理方面建模的图形之一。
经过分析,仓库设备管理系统的组件图如图4.3所示
图4.3仓库设备管理系统的组件图
4.2.2配置分析
配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件,即系统运行时刻的结构。
可以显示计算机结点的拓扑结构和通信路径,结点上执行的软构件,软构件包含的逻辑单元等,特别对于分布式系统,配置图可以清楚的描述系统中硬件设备的配置,通信以及在各硬件设备上各种软构件和对象的配置。
配置图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具,仓库设备管理系统的配置图如图4.4所示。
图4.4配置图
在本系统中,用PC机作为客端,中间服务器为数据库服务器,部分客户端如结算、缴款需打印票据的则需要连接打印机。
5.课程设计体会
我们进行了为期一周的课程设计。
通过这次课程设计我们拓宽了知识面,锻炼了能
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 仓库 设备管理 系统
![提示](https://static.bdocx.com/images/bang_tan.gif)