仓库管理系统UML建模分析Word文档下载推荐.docx

仓库管理系统UML建模分析Word文档下载推荐.docx

《仓库管理系统UML建模分析Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《仓库管理系统UML建模分析Word文档下载推荐.docx（25页珍藏版）》请在冰豆网上搜索。

（4）删除商品信息：

管理员根据消费者反馈的信息对一些商品进行删除。

2.2.2基本业务模块

基本数业务模块图如2.3所示。

图2.3基本业务模块图

（1）出库：

处理出库业务。

（2）入库：

处理入库业务。

（3）查询：

管理员可以查询商品的销售情况，顾客可以查询商品的类别。

（4）保质期管理：

将已过保质期的商品全部清除，检测所有商品的质量。

（5）金额管理：

管理员可以通过商品的销售金额对商品的供给做出重新安排。

2.2.3数据库模块

数据库模块图如2.4所示。

图2.4数据库模块图

（1）出库信息管理：

出库信息包括商品的类别、ISBN、出库时间等。

（2）入库信息管理：

入库信息包括商品的类别、ISBN、入库时间等。

（3）商品信息管理：

商品信息包括商品的类别、出入库时间、销售量、保质期、商品总数等；

（4）库存信息管理：

商品数目的更新，通知管理员商品供给量等。

2.2.4信息查询模块

信息查询模块图如2.2所示。

图2.5信息查询模块图

（1）查询商品信息：

负责商品信息的查询。

（2）查询库存信息：

负责库存信息的查询。

2.2非功能性描述

2.2.1可行性性分析

可以从以下四方面对能否实现新系统目标进行可行性分析：

（1）技术可行性

根据客户提出的系统功能、性能及实现系统的各项约束条件，根据新系统目标来衡量所需的技术是否具备，本系统是一个数据库管理和查询的系统，现有的技术以较为成熟，硬件、软件的性能要求、环境条件等各项条件良好，估计利用现有技术条件应完全可以达到该系统的功能目标。

同时，考虑给予的开发期限也较为充裕，预计系统是可以在规定期限内完成开发。

（2）经济可行性

估算新系统的成本效益分析，其中包括估计项目开发的成本，开发费用和今后的运行、维护费用，估计新系统将获得的效益，估算开发成本是否回高于项目预期的全部经费。

并且，分析系统开发是否会对其它产品或利润带来一定影响。

系统的效益可以从经济效益和社会效益两方面考虑。

对于仓库管理系统则应着重分析其社会效益。

例如，系统投入运行后可以使仓库管理实现科学化、规范化。

曾强了工作人员对仓库管理能力、提高了工作效率。

（3）运行可行性

新系统的研制和开发是充分得考虑工作人员对仓库的易于管理，管理者方便查询设备信息效率。

从而能完全满足使用者的要求。

本系统操作简单,有机算计基础的人无需培训即可使用,即使是没有计算机基础的人只需经过简单的培训就可以很熟练的使用本系统。

系统运行后，就用户方而言，由于用户使用本系统时，不会也不必关心系统内部的结构及实现方法，即对用户来说是透明的，所以本系统对用户而言，是定位在界面友好、操作方便、功能齐全的原则上的，用户只需简单的用鼠标点击各界面上的选项卡或按钮就能执行相应的功能，就管理者而言，关心的是如何处理各种数据，只要把用户的信息输入计算机，管理者就可运行相应的后台程序进行处理。

而以上的这些功能都能在所选择的开发环境中用所选择的开发工具来实现。

所以说本系统在用户使用可行性上是没有问题的。

（4）法律可行性

新系统的研制和开发，将不会侵犯他人、集体和国家的利益，不会违反国家政策和法律。

2.2.2环境要求

（1）本系统运行的硬件环境如下：

客户机：

普通PC，满足：

CPU：

P41.8GHz以上；

内存：

256M以上；

（2）本系统运行的软件环境如下：

操作系统：

Windows2000以上的操作系统；

数据库：

SQLServer2005；

开发工具包：

JAVA，EXCLIPS。

3用例需求分析

3.1系统的用例需求文档

3.1.1基本信息管理模块

本系统的功能大致可分为以下几个部分：

（1）商品信息模块

商品信息模块主要是记录商品的各类信息，其中包括商品编号、商品名称、商品类型、商品价格、商品数量等信息。

实现了商品的录入、修改、删除查询等功能。

（2）客户基本模块

客户基本情况模块主要是记录客户的各种信息，共中包括客户编号、客户名称，所属客户的商品名称、库存数量、商品规格、商品的入库时间、联系人、联系电话，实现对客户信息的录入、删除、修改和查询等功能。

（3）信息汇总模块

信息汇总模块包括金额汇总和库存预警。

金额汇总模块主要包括仓库内各个客户存储货物的金额汇总。

库存预警主要包括各个客户的库存预警信息查询。

（4）身份验证

在用户进入系统前，首先要求用户身份验证，登录时要对输入的用户名和密码进行验证是否匹配，验证通过后允许用户进入本系统进行操作，并根据本用户现有的权限来进行特定的操作。

（5）用户注册

在用户未进行相应的登录设置时需要先进行注册个人的信息和相关的管理权限等，填写完毕提交后在进行登录操作。

3.1.2参与者

从以上分析中，可以得出以下参与者

（1）系统管理员。

（2）仓库管理员。

（3）普通用户。

（4）销售员。

3.2用例图分析

3.2.1系统管理员用例图

（1）用例模型的执行者：

系统管理员。

（2）包括：

身份验证、权限管理、信息维护、数据恢复。

（3）信息维护包含出库管理、商品信息管理；

权限验证包括身份验证。

如图3.1所示。

图3.1系统管理员用例图

3.2.2仓库管理员用例图

仓库管理员。

查询统计、入库管理、出库管理、信息配置。

（3）入库管理包括商品信息录入、入库一览表、入库单据管理；

出库管理包括出库一览表、出库单据查询、商品出库；

信息配置包括修改密码、商品管理、单位管理；

查询统计包括库存预警、金额汇总。

如图3.2所示。

图3.2仓库管理员用例图

3.2.3普通用户用例图

普通用户。

金额汇总、库存预警、商品查询、商品出库、商品调拨、身份验证。

如图3.3所示。

图3.3普通用户用例图

3.2.4销售员用例图

如图3.4所示。

图3.4销售员用例图

4类图设计建模

4.1总体描述

对象模型是对模拟客观世界实体的对象及对象之间的关系进行映射，它是以对象为主而非系统功能，主要描述了系统的静态特征。

类图由系统中使用的类以及它们之间的关系组成，对象图是类图的一个实例，它描述了系统具体对象以及某一时刻这些对象之间的关系。

UML用各种模型元素表示图中的概念，如表示类和对象的模型元素，类和类之间的关系包括关联、泛化、依赖、聚集等。

本系统用类图来建立对象模型。

4.2查询统计类图

（1）Client类是客户模型类。

（2）AmountSummaryAction类是系统数据提交处理类，在类中调用Client类实例化对象接受数据。

（3）InventoryWarningService类主要功能是实现仓库预警的业务处理。

（4）InventoryWarningAction类是接受用户提交的相关数据后，调用对应的Service类中的方法进行业务处理。

（5）AmountSummaryAction类和InventoryWarningAction类继承ActionSupport类实现相应的action方法。

如图4.1所示。

图4.1查询统计类图

4.3出库管理类图

（1）SpInfo类是商品模型类。

（2）Stock_removal_Action类是系统数据提交处理类，在类中调用Stock_removal_service类中的selectlist方法来实现相关的业务处理。

（3）Stock_removal_service类主要功能是商品出库的相关业务处理。

（4）stockRemovalQueryAction类是接受用户提交的相关数据后，调用对应的Service类中的方法进行查询业务处理。

（5）SRQueryService类主要实现商品出库查询的功能。

（6）AllotQueryAction类通过实例化AllotQueryService类后，调用相关的方法，来实现商品调拨的相关业务功能。

（7）Collect_Action类通过实例化Collect_Service类调用list（）方法，完成出库一览表的查询业务功能。

（8）图中的action类都是通过集成ActionSupport类后，实现各个action类的对应方法。

如图4.2所示。

图4.2出库管理类图

4.4入库管理类图

（1）SpInfo类是商品模型类，Client类是客户模型类。

（2）luru_Action类是系统数据提交处理类，在类中通过实例化Sp_Info_service类后，调用Sp_Info_service类中的insert方法来实现相关的业务处理。

（3）Sp_Info_service类主要功能是通过实例化Client类和SpInfos类，接受由luru_Action类传递的参数来实现商品出库的相关业务处理。

（4）Document_Manage_Action类是接受用户提交的相关数据后，调用对应的Service类中的方法进行逻辑业务处理。

（5）Document_Manage_service类主要实现商品退货、以及商品调价、查询等功能。

如图4.3所示。

图4.3入库管理类图

4.5信息配置类图

（1）SpInfo类是商品模型类，Client类是客户模型类，User类是用户模型类。

（2）changewd_service类通过实例化User类后，通过实现changewd方法来实现相关的用户修改密码的服务。

（3）changewd_Action类主要功能是通过实例化changewd_service类来实现修改密码的功能。

（4）jurisdiction类通过实例化jurisdictionService类，调用对应的Service类中的方法进行相应的权限修改以及验证功能。

（5）Kh_ManageAction类主要实现对客户信息插入、修改、查询、删除等功能。

（6）Sp_ManageAction类通过实例化Sp_ManageService类后，调用相关的方法，来实现商品信息的插入、修改、查询、删除等功能。

（7）图中的action类都是通过集成ActionSupport类后，实现各个action类的对应方法。

如图4.4所示。

图4.4信息配置类图

5顺序图设计模型

5.1系统的顺序图

（1）仓库管理员用自己的用户名和密码登录系统，经验证用户填写的用户名及密码正确后，进入主界面。

（2）点击单据管理界面，填写单据的相关信息后，单击查询按钮提交查询信息，系统自动反馈提交状态，提示是否提交成功，提交成功后等待后台审核。

（3）审核由系统后台来完成，审核通过后，返回查询结果集对象给单据管理action类，然后action类会将相关信息反馈到单据管理界面上。

（4）仓库管理员点击界面上的退货按钮跳转到商品退货界面，填写完退货信息后点击提交按钮，单据管理action类审核提交信息通过后会返回审核结果，然后向单据管理service类提出退货申请，单据管理service类就会实现相应的业务功能，之后service类会返回退货成功的“success”信号。

（5）仓库管理员点击界面上的调拨按钮跳转到商品调拨界面，填写完调拨信息后点击提交按钮，单据管理action类审核提交信息通过后会返回审核结果，然后向单据管理service类提出退货申请，单据管理service类就会实现相应的业务功能，之后service类会返回调拨成功的“success”信号。

如图5.1所示。

图5.1单据管理顺序图

5.2商品信息录入顺序图

（1）普通用户用自己的用户名和密码登录系统，经验证用户填写的用户名及密码正确后，进入主界面。

（2）点击商品信息录入界面，填写商品及用户的相关信息后，单击添加商品按钮提交相关的信息，系统自动反馈提交状态，提示是否提交成功，提交成功后等待后台审核。

（3）审核由系统action来完成，审核通过后，会生成对应的spinfo对象，并将该对象传递给Sp_Info_Service类实例化的service对象。

（4）Sp_Info_Service类的service对象调用insert（）方法将用户提交的商品信息入库，并返回一个spinfos结果集对象。

（5）luru_Action类通过实例化spinfos并调用getSpinfos方法获得Sp_Info_Service类返回的结果及对象通过调用list（）方法，将提交成功的信息返回商品信息录入界面。

如图5.2所示。

图5.2商品信息录入顺序图

5.3商品出库顺序图

（2）点击商品出库界面，填写商品出库的相关信息后，单击查询单据按钮提交相关的信息，系统自动反馈提交状态，提示是否提交成功，提交成功后等待后台审核。

（3）审核由系统removal_action来完成，审核通过后，调用execute方法会生成对应的spinfo对象，并将该对象传递给removal_Service类实例化的service对象，并进行出库操作。

（4）removal_Service类的service对象调用list（）方法查询用户提交的单据查询信息，并返回一个list结果集对象。

（5）luru_Action类通过实例化list并调用getList方法获得removal_Service类返回的结果及对象，并将查询结果返回到商品出库界面。

如图5.3所示。

图5.3商品出库顺序图

5.4调拨单据查询顺序图

（2）点击调拨单据查询界面，填写相关信息后，单击查询单据按钮提交相关的信息，系统自动反馈提交状态，提示是否提交成功，提交成功后等待后台审核。

（3）审核由系统action来完成，审核通过后，调用query方法会生成对应的spinfo对象，并将该对象传递给Service类实例化的service对象，执行查询操作。

（4）removal_Service类的service对象调用list（）方法查询用户提交的单据查询信息，并返回一个spinfos结果集对象。

（5）调拨Action类通过实例化list并调用getSpinfos方法获得Service类返回的结果及对象，并将查询结果返回到上调拨单据查询界面。

如图5.4所示。

图5.4调拨单据查询顺序图

6协作图设计建模

6.1协作图含义

协作图着重体现交互对象间的静态链接关系。

作者完成了所有用例的动态模型，这里列举部分用例进行说明。

协作图（CollaborationDiagram）用于描述相互合作的对象间的交互关系和链接关系。

虽然顺序图和合作图都用来描述对象间的交互关系，但侧重点不一样。

顺序图着重体现交互的时间顺序，合作图则着重体现交互对象间的静态链接关系。

6.2用户登录协作图

（1）用户首先填写用户信息到仓库管理系统。

（2）等待仓库管理系统返回验证。

（3）仓库管理系统验证登录信息并跳转到系统主界面后，用户才选择具体的用户界面进行操作并且返回相应信息给用户。

如图6.1所示。

图6.1用户登录协作图

6.3商品出库协作图

（1）普通用户首先提交商品缺货登陆信息到仓库管理系统。

（2）仓库管理员认真审核提出商品补充信息到仓库，仓库将请求的商品返回给仓库管理员，由仓库管理员转交用户。

（3）最后仓库管理员填写出库日志。

如图6.2所示。

图6.2商品出库协作图

6.4商品调拨顺序图

（1）仓库管理员填写调拨商品信息提交给仓库管理系统审核，并等待审核信息。

（2）仓库管理员审核返回的信息，并向出库仓库提出调拨申请。

（3）出库仓库向系统返回剩余库存量，并向入库仓库转移调拨商品。

（4）仓库管理员将调拨的商品信息入库到对应的数据库中。

如图6.3所示。

图6.3商品调拨协作图

6.5系统管理协作图

（1）系统管理员登陆仓库管理系统，首先是在输入用户名和密码到登陆界面，并验证成功的情况下才能实现的。

（2）系统管理员进行修改记录操作到信息管理并返回修改成功信息到系统管理员，是必须在成功登陆仓库管理系统之后才能实现。

（3）系统管理员进行重新设置管理权限操作到权限管理并返回设置成功信息到系统管理员。

（4）系统管理员进行仓库管理系统的数据备份和恢复并返回操作成功的信息到系统管理员。

如图6.4所示。

图6.4系统管理协作图

6.6商品入库协作图

（1）仓库管理员清点商品获得商品数量信息并向系统提交库存预警。

（2）系统向普通用户发出预警提醒，普通用户将商品入库，并向仓库管理员发出入库提醒。

（3）最后仓库管理员填写入库日志。

如图6.5所示。

图6.5入库日志协作图

7活动图设计建模

7.1商品出库活动图

（1）销售员通过填写销售表单，在将此表单提交给仓库管理员进行审核。

（2）仓库管理员进行修改、删除和审核通过的判断后，查询仓库中是否有符合要出库的商品。

（3）若没有则提示仓库无此货物；

若有则判断仓库中是否有满足所需要的商品的数量，若没有则提示商品不足；

若有则将所需要的商品出售。

如图7.1所示。

图7.1商品出库活动图

7.2商品调拨活动图

（1）仓库管理员填写所要调拨商品的表单并进行审核，然后仓库管理员修改、删除调拨表单和调拨表单的审核通过判断。

（2）判断出库中是否有所调拨的商品，若没有则提示仓库没有此商品；

若有则判断出库中是否有满足调拨该商品的数量，若没有则提示库存不足；

若有则判断入库中是否有该商品，若没有则插入此商品；

若有则与入库最后哦昂的此商品进行相加完成商品的调拨操作。

如图7.2所示。

图7.2商品调拨活动图

7.3商品入库活动图

（1）在一批物资要入库时，首先仓库管理员登录系统，超过三次退出。

（2）进入入库窗体，然后进行入库单的审核，如果入库项有填写错误时，不能进入下一步的操作。

（3）如果在填写入库项时发现仓库内此类物资正在盘点，则此批物料此时是不能进行入库的，需退出。

（4）扩展发挥：

当所有条件都符合时，系统自动检查物资的库存量，但超出仓库最大库存时，退出所有操作；

反之进行正常操作。

如图7.3所示。

图7.3商品入库活动图

7.4用户登录活动图

（1）用户利用系统管理员分配给的用户名、密码、权限以及验证码来进行登录。

（2）验证用户名和密码是否为空，若为空则重新录入在进行验证；

若不为空则验证验证码是否通过验证，若没有通过身份验证则重新录入；

若通过身份验证后完成用户登录操作。

如图7.4所示。

图7.4用户登录活动图

8状态图设计模型

8.1商品状态图

（1）当商品处于上架状态时，会因为商品超过保质期而使商品改变为下架状态。

（2）当上架商品缺货时，商品会从上架状态改变为商品入库状态，而处于商品库存状态的商品会因为货架商品缺货而使状态改变为上架状态。

（3）处于下架状态的商品因为退货请求而使状态改变为出库状态。

如图8.1所示。

图8.1商品状态图

8.2仓库库存状态图

（1）当仓库库存处于正常状态时会因为库存数量达到最大阀值而使状态改变为商品库存最高预警状态。

（2）当库存处于正常状态时，会因为库存数量达到最小阀值而使状态改变为商品库存最低预警状态。

（3）当库存处于最低预警状态时，会因为商品入库而使状态改变为商品库存最高预警状态。

如图8.2所示。

图8.2商品入库状态图

8.3商品单据状态图

（1）一般单据处于单据保护状态，当系统收到修改单据请求时，被修改单据状态改变为单据锁定状态。

（2）处于锁定状态的单据当用户权限验证通过后，单据由锁定状态改变为修改状态，修改完成后，单据由修改状态转换为单据保护状态。

如图8.3所示。

图8.3商品单据状态图