大型仓库信息系统的开发.docx
《大型仓库信息系统的开发.docx》由会员分享，可在线阅读，更多相关《大型仓库信息系统的开发.docx（29页珍藏版）》请在冰豆网上搜索。
大型仓库信息系统的开发
大型仓库信息系统的开发
一：
系统概述：
〝仓库信息系统〞是一套功能强大而又操作简便、使用的仓库治理软件，包括用户登录、仓库治理、业务查询和系统设置4大治理功能。
本系统在功能设计上具有前瞻性，吸取和借鉴了国际上先进的仓储治理思想。
通过供应商、仓库及客户三者之间信息的沟通与指令的有效传递，将制造商和供应商的库存成本与资金占有率降到最低限度。
本系统要紧适用于第三方物流企业的仓储治理。
二：
需求分析：
在软件开发的初期，开发人员以及用户往往忽略信息沟通，导致软件开发完成后，不能专门好的满足实际的需要。
而返工不仅在技术上给开发人员带来庞大的苦恼，还会造成人力、物力的白费。
因此，只有弄清晰客户的需求，才能真正开发出满足客户需求的治理信息系统，才能够让整个系统发挥其相应的作用。
2.1系统总体功能需求
一个功能完善的仓库信息治理系统，必须包括以下的几个模块。
（1）用户登录
由用户登录、用户注销、退出系统3个部分组成。
用户能够用两种身份登录本系统：
一般操作员或经理〔治理人员〕；不同身份登录被系统授予不同的使用权限，如此提高了本系统的安全性，幸免了无关人员猎取不在他权限范畴内的信息。
用户在登录后能够不退出本系统，而采纳用户注销的方式使系统不存在激活状态下的用户。
（2）仓库治理
仓库治理系统中，包括仓库进货、仓库退货、仓库领料、仓库退料、商品调拨和仓库盘点6个功能模块组成。
仓库治理系统是整个仓库信息系统的核心，是所有数据的来源。
用户通过本系统的使用，能够使仓库的空间得以优化，减低无效和冗余的作业，使库存精度更准确，库存周转率提高及库存资金占用减少。
〝仓库进货—>仓库领料—>仓库盘点〞组成了仓库治理的重要过程。
（3）业务查询
业务查询系统，包括库存查询、销售查询和仓库历史记录3个功能模块组成。
库存查询实时提供库存变化的信息，随时应不同客户的要求得到其当前的库存。
销售查询提供了一个完整的出货查询平台：
用户能够依照物资的ID号查询某个时刻段里该物资的销售情形，该功能能够使企业的治理人员能够以最快的速度了解仓库的出货情形和与仓库相配套的商场的销售情形，方便企业治理人员依照不同的情形及时的调整经营战略。
仓库历史记录查询功能模块：
在本系统中仓库进货、仓库退货、仓库领料、仓库退料、商品调拨和仓库盘点的任一个操作都储存在数据库中，本功能模块确实是查询任意一条操作记录。
由此可知，本仓储治理漠视通过供应商、仓库及客户间的信息沟通与指令的及时有效传递，将制造商和供应商的库存成本与资金占压降到最低限度。
（4）系统设置
系统设置包括供应商设置和仓库设置两个部分。
供应商是物资的提供者，在供应商设置中：
用户能够输入详细的供应商信息，包括联系方法、供应商名称和要紧经营项目等信息，方便企业治理查询和爱护。
仓库设置：
在本系统中，用户能够将整个仓库虚拟的分成数个仓库，每个仓库储存不同类型的物资，如此方便仓库物资的分类治理，也有利于提高仓库进货、出货的效率。
综上所述，系统的功能需求可用如图1琐事的框图简要表示。
2.2用户需求
用户登录所包括的具体功能模块如图2所示。
（1）用户登录
用户进入本仓库信息治理系统的入口，没有得到身份验证的用户只能拥有最低的使用权限，即只能选择退出系统或用户登录。
本系统的使用者能够用两种身份登录到系统：
一般操作员或经理〔治理人员〕，不同的身份意味着不同的使用权限，这一个稳固、安全的系统所必须具备的。
（2）用户注销
本系统中引入了类似Windows操作系统的用户注销功能，当用户在短时刻内不适用本系统，他不必退出，只需要选择用户注销，如此能够使系统中不存在处于激活状态的用户，以便其他用户使用本系统。
（3）退出系统
用户在完成工作后，点击推出系统按钮能够安全的推出，以免不安全退出导致数据丢失情形的发生。
2.3仓库治理
仓库治理包括的具体功能模块如图3所示。
仓库治理系统是整个仓库信息系统的核心，是所有数据的来源。
依照详细的需求分析，企业在库存中面临的要紧问题表达在：
库存量较大，库存资金周转慢；不能及时统计库存物料；库房人员重复工作多，效率低；不明白库存物资挤压时刻长短。
本系统从最初的采购到储备和交货，仓库治理将决定企业是否兑现了其承诺。
从仓储打算到仓库操作和交叉运输，优化的仓储将有助于大幅减少企业的存货量和存货成本，因为企业将能保持较低的仓库存货水平，优化入库，保管和出库活动，同时和谐载货量。
（1）仓库进货
在本仓库信息系统中，仓库进货模块要求操作员输入商品号、进货数量、单价和供应商，系统会自动的将当前系统时刻作为进货时刻更新到数据库，同时会自动统计总进货金额。
该操作完成后，响应物资的数量为原先数量加进货的数量，并更新数据库。
仓库进货功能如图4所示
（2）仓库退货
仓库退货功能如以下图所示。
需求分析说明，企业仓库中的物资离开仓库要紧有两种缘故：
企业无法销售某商品，将其退还给供应商；企业销售了一部分某商品，再从仓库调出部分库存的该种商品。
在本仓库信息系统中，仓库进货模块是为了第一种缘故而设计的，它要求操作员输入退货商品号、退货熟料、单价和供应商，系统会自动的将当前系统时刻作为退货时刻更新到数据库，同时会自动统计总退货金额。
该操作完成后，相应物资的数量为原数量减退货的数量，并更新数据库。
（3）仓库领料
依照上述仓库退货中列举的缘故，在本仓库信息系统中，仓库领料模块是为了第二种缘故而设计的，它要求操作员输入领取商品号、领料数量、领料人和仓库治理员，系统会自动将当前系统时刻座位退货时刻更新到数据库，同时会自动统计总领料数量。
在打印的单据中将会给出上述的所有信息。
该操作完成后，相应物资的数量为原数量减领料的数量并更新数据库。
（4）仓库退料
仓库退料功能如以下图所示。
依照需求分析，企业工恩能够遇到下述问题：
企业销售部门在某段时刻内没有销售出某件商品，这可能会造成销售部门的物资积压，因此部门就需要将该件商品返回一部分到仓库，这确实是所谓的仓库退料。
在本仓库信息系统中，仓库退料模块要求操作员输入退料商品号、退料数量、退料人和仓库治理员，系统会自动的将当前系统时刻作为退料时刻更新到数据库，同时会自动统计总退料数量。
在打印的单据中将会给出上述的所有信息。
该操作完成后，相应物资的数量为原数量加退料的数量并更新数据库。
（5）商品调拨
商品调拨功能如以下图所示。
企业中专门可能不止一个销售部门，而哥哥销售部门销售业绩也不相同。
按照传统的仓库物流治理模式，业绩不行的销售部门要将其积压的商品退回仓库，业绩好的销售部门从仓库领取一定数量的商品。
本系统中引入了商品调拨的概念，即业绩不行的销售部门能够直截了当将其积压的商品移交一部分给业绩好的销售部门，不必通过仓库中转。
该功能具有较大的灵活性和可扩展性，能够满足客户在仓储治理方面更多个性化的需求。
仓库调拨要求操作员输入退料商品号、调拨数量、调拨人和仓库治理员，系统会自动的将当前系统时刻作为调拨时刻更新到数据库，同时会自动统计总调拨数量。
在打印的单据中将会给出上述的所有信息。
（6）仓库盘点
仓库盘点功能如以下图所示。
仓库盘点的目的是为了更好地了解仓库准确的库存信息。
盘点的周期和盘点的方式，企业能够依照自身的情形加以选择，不合理的仓库盘点，将会降低仓库库存信息的准确性、物料打算的准确性；不必要的仓库盘点将白费企业的人力和物力。
仓库盘点一样能够按照周期盘点、循环盘点和零点盘点3种方式进行，企业采纳周期盘点这种方式的情形较多。
操作员能够在仓库盘点中任意增加或减少某件商品的库存数据，因此，出于安全性方面的考虑，本功能模块需要治理者〔部门经理〕能使用，同时所有的修改信息将会被储备到数据库中。
仓库盘点模块哟哀求治理员输入某商品号、该商品实际数量，系统会自动的将当前系统时刻作为盘点时刻更新到数据库，同时会自动统计总盘点过程中修改的数量。
在打印的单据中将会给出上述的所有信息。
2.4业务查询
业务查询包括的具体功能模块如以下图所示。
随着客户要求的不断提高，仓储治理在整个供应链治理当中占有专门重要的地位。
以单据打印和数据记录为生计目标的传统仓储治理软件已远远无法适应现代仓储进展的要求。
用户所需要的是仓储企业在实现信息化治理的基础上，不但能够向客户报告其产品的实时动态信息，还能够站在更高层面上为客户制定生产和销售打算，及时调整市场策略等方面提供连续、综合的参考信息，版主仓储企业成为客户在整个供应链上最为紧密的合作伙伴。
业务查询功能模块确实是为用户提供了传统仓库治理系统以外的一些功能。
（1）库存查询
库存查询如以下图所示。
库存的可见性是决定企业的分销战略是否成功的最重要的一点。
假如库存水平和组成，或所打算的对这些水平和组成的更新是模糊地、不正确的、过时的或完全不可信的，那么所有的仓储，运输和供应链治理活动都专门有可能失败。
换句话说，假如企业拥有清晰地、正确的、最新的和可靠的库存信息，将能更好地保证仓储，运输和供应链治理的成功。
在本系统的库存查询功能模块中，用户能够查询所有的商品的库存，也能够输入某件商品的ID号从而得到该商品的库存。
总之，用户能够通过本查询模块轻松得到即使的库存信息。
（2）销售查询
销售查询如以下图所示。
功能模块要紧为企业治理者的经营决策提供参考的信息，更高层面上为客户在制定生产和销售打算，及时调整市场策略等方面提供连续、综合的参考信息。
在销售查询功能模块中，用户只需要选择某个时刻段，运算机就会依照数据库中的资料给出该时刻段中所有商品的销售情形。
企业的经营者能够参考如此的信息来做出一些营销策略。
由于本功能模块涉及到企业的经营信息，考虑到商业信息的安全性，需要治理员级的用户才能够使用本模块。
2.5系统设置
系统设置包括供应商设置和仓库设置两个功能模块组成。
供应商设置要紧是提供一些供应商的信息以方便用户查询和适用。
仓库设置的要紧功能是用户能够将整个仓库虚拟的分成数个仓库，每个仓库储存不同类型的物资，如此方便仓库物资的分类治理，也有利于提高仓库进货、出货的效率。
仓库治理包括的具体功能模块如以下图所示。
（1）供应商治理
供应商治理如下图。
在本功能模块中，用户能够增加新的供应商，需要输入供应商的一些信息，包括供应商号、名称、联系人、联系、、地址和邮政编码。
用户也能够对差不多输入的供应商信息进行修改和查询。
（2）仓库设置
仓库设置如下图。
三：
系统用例模型
前面的章节差不多对本系统的任务和需求做了详细的说明。
接下来，将对系统的流程和各个参与者之间的相互作用做详细的说明，将以RationalRose作为UML建模的工具，使用用例图、时序图、协作图和类图等对整个系统进行描述、构造、可视化和文档编制。
用例视图是被称为参与者的外部用户所能观看到的系统功能的模型图。
用例是系统中的一个功能单元，能够被描述为参与者与系统之间的一次交互作用。
用例模型的用途是列出系统中的用例和参与者，并现实哪个参与者参与了哪个用例的执行。
本章的要紧内容是熟悉建模的顺序，把握UML建模的一些差不多方法，领会面向对象的实质。
3.1角色的确定
在UML中，Actors代表位于系统之外和系统进行交互的一类对象。
用它能够对软件系统与外界发生的交互进行分析和描述。
在仓库信息系统中，能够归纳出来的要紧问题有：
■购买的商品入库；
■将积压的商品退给供应商；
■将商品移送到销售部门；
■销售部门将商品移送到仓库；
■治理员盘点仓库；
■供应商提供各种物资；
■用户查询销售部门的营销记录；
■用户查询仓库中的所有变动记录。
从上面所归纳的问题能够看出，本系统所涉及的操作要紧是仓库信息的治理、爱护以及各种信息的分析查询。
在本系统UML建模中，能够创建一下角色〔Actors〕；
■操作员；
■治理员；
■供应商；
■商品领料人；
■商品退料人。
使用RationalRose的UseCaseView中建立Actors如图17所示。
图17在UseCaseView中创建角色
3.2创建用例
用例本身是指一个用户或其他系统与要设计的系统进行的而一个交互，那个交互是为了达到某个目标〔goal〕。
角色用来表述该有目标的人或系统。
那个术语强调了任何人或系统拥有目标的事实。
目标本身是一个动词短语，入〝客户：
下订单〞，〝店员：
记录库存〞。
作为用例的一部分，有必要记录目标成功和失败关于活动者和系统的含义。
在下订单的实例中，目标达成可能包括物资交给活动者和公司受到相应的货款。
认真定义目标成败是定义系统范畴〔scope〕的基础。
因为关于一个简易的订单输入系统，目标达成可能仅仅一位这订单差不多通过验证同时交货差不多排定日程。
仓库信息系统依照业务流程能够分为以下的几个用例〔UseCases〕：
■仓库进货；
■仓库退货；
■仓库领料；
■仓库退料；
■商品调拨；
■仓库盘点；
■库存查询；
■业务分析；
■仓库历史记录查询；
■供应商信息爱护；
■仓库信息爱护；
■用户登录；
■用户注销；
■退出系统。
使用RationalRose的UseCaseView中建立用例〔UseCases〕如下图。
3.3创建角色用例关系图
用例图〔UseCaseDiagram〕采纳了面向对象的思想，又是基于用户视角，绘制专门容易，简单的图形表示便于让人们明白得。
用例图表示了角色和用例以及他们之间的关系。
塔描述了系统、子系统和类的一致的功能集合，表现为系统和一个或多个外部交互者〔角色〕的消息交互作序列。
也确实是角色〔用户或为不系统〕和系统〔要设计的系统〕的一个交互，为了实现一个目的，那个目的的描述通常是一个动词短语，例如，开立信用证，给客户回单等。
操作员的用例关系如下图。
操作员的用例关系图
治理员的用例关系如下图。
治理员的用例关系图
商品供应商的用例关系图如下图。
商品供应商的用例关系图
下面给出整个系统的用例关系图如下图。
整个系统的UseCases关系图
4.系统动态模型
4.1活动图
活动图是一种专门形式的状态图，用于对运算流程建模。
活动图中的状态表示运算过程中所处的各种状态，而不是一般对象的状态。
通常，活动图假定在整个运算处理的过程中没有外部事件引起的中断，否那么，一般的状态机更适合于描述这种情形。
活动图是对状态图的扩展。
状态图突出显示的状态，状态之间的转移箭头代表的是活动。
而活动图突显现实的是活动。
每个活动的图表示为圆角矩形，比状态图标更接近椭圆。
活动图的起始点和中止点图标与状态图一样。
进货的活动图
在图中，治理员、操作员还有供应商三者发生了相互的关系。
第一治理员查看销售记录判定商品销售状况，然后查看商品库存情形。
假如发觉仓库中商品库存充足那么操作完毕，假如发觉仓库中某商品库存显现不足，那么通知操作员缺货商品清单，操作员领取清单后赶忙联系相应的供应商，供应商提供相应是商品，操作员同意物资，更新书库，操作完成。
4.2时序图
时序图〔SequenceDiagram〕表示对象之间传送消息的时刻顺序。
时序图能够用来进行一个场景的说明，即一个事物的历史过程。
时序图中每一个类元角色用一条生命线来表示〔用垂直线代表整个交互过程中对象的生命期〕。
生命线之间的箭头连接代表消息。
时序图能够用来进行一个场景说明，即一个事物的历史过程。
时序图的用途是用来表示用例中行为的时刻顺序。
当执行一个用例行为时，时序图中的每条消息对应一个类操作或状态机中引起转换的动身事件。
（1）治理员盘点过程时序图如下图。
仓库盘点过程时序图
（2）商品治理时序图如下图。
商品治理时序图
（3）仓库历史记录查询时序图如下图。
仓库历史记录查询时序图
4.3协作图
协作图〔CollaborationDiagram〕用于再一次交互中对有意义的对象和对象间的链建模。
对象和关系只有在交互时才有意义。
类元角色描述了一个对象，关联角色描述了协作关系中的一个链。
协作图的用途时表示一个类操作的实现，协作图能够说明类操作中用到的参数和局部变量以及操作中类之间的关联。
当实现一个行为时，消息编号对应程序中的嵌套调用结构和信号传递过程。
（1）治理员盘点过程协作图如下图。
仓库盘点过程协作图
（2）商品治理协作图如下图。
商品治理协作图
（3）仓库历史记录查询协作图如下图。
仓库历史记录查询时序图
协作图和时序图都能够表示各对象间的交互关系，但他们的侧重点不同。
时序图用消息的几何排列关系来表达消息的时刻顺序，各角色之间的相互关系是隐含的。
协作图用各角色的几何排列图形来表示角色之间的关系，并用消息来说明这些关系。
在实际中能够依照需要选用这两种图。
五：
创建系统包图
包是模型的一部分，模型的每一部分必须属于某个包。
建模者能够将模型的内容分配到包中。
然而为了使其能够工作，分配必须遵循一些合理原那么，如公用规那么、紧密耦合的实现和公用观点等。
UML对如何组包并不强制使用什么规那么，然而良好的解组会专门大的增强模型的可爱护性。
一个包能够包含其他包，根包间接的包含系统的整个模型。
组织系统中的包有几种可能的方式，能够用视图、功能或建模者选择的其他差不多原那么来规划包。
包是UML模型中一样的层次组织单元，他们能够被用来进行储备、访问操纵、配置治理和构造可重用模型部件库。
假如包的规划比较合理，那么能够反映系统的高层框架——先管系统由子系统和它们之间的依靠关系组合而成。
包之间的依靠关系概述勒包的内容之间的依靠关系。
5.1仓库治理系统包图
在定义具体的类之前，先在宏观的角度上将整个系统分割成多个独立的包，在那个地点把整个仓库治理系统分成的包如下图。
系统包图
5.2人员信息〔peopleinformation〕包内的类
人员信息〔peopleinformation〕包内的类组织如下图。
人员信息包内的类
在人员信息包内，有以下5块内容：
■操作员；
■治理员；
■供应商；
■商品领料人；
■商品退料人。
5.3事物包〔business〕包内的类
事物包〔business〕包内的类组织如下图。
事务包内的类
5.4接口包〔interfaces〕包内的类
接口〔interfaces〕包内的类组织如下图。
接口包内的类
在接口包内，有以下4块内容：
■仓库治理；
■系统设置；
■业务查询；
■用户登录。
六：
系统类模型
类图是面向对向系统的建模中最常见的图。
类图显示了一组类、接口、协作以及他们之间的关系。
类图用于对系统静态设计视图建模。
其大部分涉及到对系统的词汇建模、对协作建模或对模式建模。
类图也是两个相关〔组件图和配置图〕的基础。
类图不仅对结构模型的可视化、详述和文档化专门重要，而且对通过正向与逆向工程构造可执行的系统也专门重要。
6.1Logical
Logical视图关注的焦点是系统的逻辑结构。
重复使用是一个要紧目的。
通过认确实指定类的信息和行为、组合类，以及检查类和包之间的关系，就能够确定能够重复使用的类和包。
完成多个项目后，就能够将新类和包加进重复使用库中。
今后的项目能够组装现有的类和包，而不必一切从头开始。
Logical视图如下图。
Logica视图
6.2类图
类图中的类是针对时序图和协作图中没中对象创建的。
以下图所示分别显示了人员信息包，借口包和事务包中类的类图。
人员信息包内的类图
接口信息包内的类图
系统事务信息包内的类图
七：
系统部署
仓库治理系统部署是整个项目实施过程中最后的时期，确实是把该系统中涉及到的硬件软件、整合到一起，同时能够让系统运行起来。
配置图
配置图〔Deployment〕视图考虑应用程序的物理部署，如网络布局和组件在网络上的位置等问题，进一步还需要考虑以下几个问题：
具有多少网络带宽；期望显现多少并发用户；服务器关闭如何办等。
仓库治理系统的Deployment视图如下图。
仓库治理系统的Deployment视图
如下图是仓库治理系统的Deployment框图。
仓库治理系统的Deployment框图
八：
实训小结
通过了一周的UML实训，使我对RationalRose有了初步的了解。
明白了用例图是由角色和用例组成的，其中角色确实是参与那个系统的参与者，而用例确实是能够完成的活动。
还有时序图，活动图，协作图，配置图共同组成了整个系统。
从开始的不明白如何使用RationalRose那个软件，如何画图，用哪个工具能够达到要求，到后来的能够差不多了解如何使用那个软件。
其中还遇到了困难，因为开始进入Rose选择的模版不合适，以至于我做完的系统太大，压缩完成后和一个班的同学的大小差不多，通过老师和同学的指导和关心，终于顺利的完成了这次实训内容。
升级会员 