UML案例-超市进销存系统.ppt

UML案例-超市进销存系统.ppt

《UML案例-超市进销存系统.ppt》由会员分享，可在线阅读，更多相关《UML案例-超市进销存系统.ppt（38页珍藏版）》请在冰豆网上搜索。

练习:

请对超市进销存系统进行UML建模,系统需满足的基本需求如下：

1、销售：

售货员接受顾客订购，输入顾客购买的商品，计算总价顾客付款并接受清单售货员保存顾客购买的商品记录2、库存：

库存管理员每天进行盘点库存管理员每天发现库存商品有损坏时，及时到相关部门报损供应商的商品到货时，超市人员首先检查商品是否合格，并将合格商品入库处理经理、统计分析员根据需要进行相关商品的模糊查询或详细查询3、订货：

订货员用新商品供应商信息更新供应商数据库的信息订货员统计库存商品是否低于库存下限，然后制作订货单4、经理：

经理在促销期间或节日期间，注明相关商品的促销价格和手段经理按市场情况经常变动商品价格,练习:

请对超市进销存系统进行UML建模,绘出整个用例图绘出几个用例的顺序图绘出基于上述顺序图得出的类图给出“订货单”对象的状态图,分析1,1、销售：

售货员接受顾客订购，输入顾客购买的商品，计算总价顾客付款并接受清单售货员保存顾客购买的商品记录,1、销售：

1.售货员接受顾客订购2.售货员输入顾客购买的商品3.售货员计算总价4.顾客付款5.顾客接受清单6.售货员保存顾客购买的商品记录,问题：

1.接受顾客订购是什么意思？

就是打开相关的业务处理界面，开始一次新业务2.输入商品是可以多次重复的3.计算总价系统计算4.顾客付款系统接受或确认付款5.顾客接受清单清单哪里来的？

应该是前面某一步骤中打印出来的（付款后）,分析1,销售：

1.打开业务界面，开始一次新的销售；2.输入顾客购买的商品（可重复多次）3.计算总价4.接受付款5.打印清单并交给顾客6.保存购买记录？

1、销售,本场景中可能比较特殊的步骤：

1.付款系统会支持什么样的支付方式未知如果只收现金，则系统中只需要售货员确认已收款如果支持刷卡，系统需要有支付接口详细情况2.保存购买记录,1、销售,可能特殊的步骤，与重复的步骤一样，可用包含关系列出：

1、销售,本场景中可能存在的实体类有：

商品：

应该会有ID、名称、单价等属性总价：

应该是清单和购买记录的一项数据。

清单：

给顾客看的纸购买记录：

与清单的内容应该是一致的（是一致，不是一样）,最终结果：

商品，购买记录,2、库存,需求描述：

库存管理员每天进行盘点库存管理员每天发现库存商品有损坏时，及时到相关部门报损供应商的商品到货时，超市人员首先检查商品是否合格，并将合格商品入库处理经理、统计分析员根据需要进行相关商品的模糊查询或详细查询,提到的业务：

1.盘点（库存管理员）盘点时，如果发现有损坏则报损2.入库（超市人员?

也可能就是库存管理员）入库时先检查商品是否合格3.查询（经理、统计分析员）以上三种业务相对独立,2、库存,3、订货,需求描述：

订货员用新商品供应商信息更新供应商数据库的信息订货员统计库存商品是否低于库存下限，然后制作订货单,提到的业务：

1.更新供应商数据库2.订货条件：

某商品的库存低于下限制作订货单是一个步骤应该会有选择供应商这个步骤以上两种业务虽然有关联，但相对独立,3、订货,有关的类：

供应商数据库，订货单,4、统计,需求描述：

经理在促销期间或节日期间，注明相关商品的促销价格和手段经理按市场情况经常变动商品价格,提到的业务：

1.促销：

条件：

特殊时期2.调整商品价格条件：

根据市场变动促销有可能也是调整商品价格的一种，但是还有个“手段”不详，所以暂按二者是不同业务来处理,4、统计,结合刚才已定义的查询业务：

初步类图,“销售”场景的时序,已知参与者：

售货员已知实体：

商品，购买记录需要构造一个边界类：

销售UI可输入商品可计算总价可确认顾客已付款可打印清单,“销售”场景的时序,“销售”场景的时序,如果要求边界类与控制类分离，则：

再增加一个控制类；读取商品信息和保存购买记录这两项要求不应由UI直接向实体类提出，而是向控制类提出，由控制类再调用实体类的操作。

“销售”场景的时序,“订货”场景的时序,相关业务：

条件：

某商品的库存低于下限即需要先统计各商品的数量制作订货单是一个步骤应该会有选择供应商这个步骤已知参与者：

订货员已知实体：

供应商DB，订货单，商品,问题：

库存数量,怎么得知某商品的库存数量？

最简单有效的方法：

“商品”类增加一个“数量”属性；“商品”类还应该有一个“统计库存”操作，功能是把库存数低于某数量的商品都找出来。

问题：

库存数量,哪些业务与此属性有关？

订货时，要参考此属性；货到后，入库，要相应增加数量；每日盘点，发现损坏，要相应减少数量；销售时，售出的商品要相应减少数量；,以上可总结为同一操作！

-更新库存（）,问题：

库存数量,哪些业务与此属性有关？

入库，盘点，销售这三个用例都要用到“更新库存”操作，可考虑提取出一个子用例。

销售时，售出的商品要相应减少数量，所以，前面的时序图中，应该加上此项操作。

更新用例图,更新“销售”时序图,回到“订货”场景,已知参与者：

订货员已知实体：

供应商DB，订货单，商品需要构造一个边界类：

订货UI可要求统计商品库存，并列出库存低于下限的商品；对满足条件的商品，可以要求制作（创建）订货单；针对商品可列出供应商，供订货员选择。

可构造一个控制类，来跟相关的实体类打交道。

“订货”场景的时序,研究一下“订货单”的状态,对象-订货单：

订货时创建，创建后到提交给供货商之间，都可以改变（更换供货商，更改订货数量等）提交后，等待所订商品到货；到货后，检查并办理入库手续；入库完成后，该订单完成。

待定状态等货状态入库中已完成,研究一下“订货单”的状态,对象-订货单：

订货时创建，创建后到提交给供货商之间，都可以改变（更换供货商，更改订货数量等）提交后，等待所订商品到货；到货后，检查并办理入库手续；入库完成后，该订单完成。

当然，入库时若发现有问题，可能还会有个“投诉状态”或是“退货状态”之类,“订货单”,所以，“订货单”类应该有一个“状态”属性,相关活动,加上对象流,此时的类图,对实体类进行数据库设计

（1）,商品：

商品编号，名称，类别，单价，数量供应商：

需增加一个OID-供货商编号名称，地址，商品编号，价格订货单：

需增加一个OID订单编号商品编号，数量，供货商编号，状态,商品：

供应商：

订货单：

对实体类进行数据库设计

（2）,购买记录：

需要增加一个对象OID记录编号“所购商品”有多个商品，可以另开一个表“购买清单”：

记录编号，商品编号，数量记录表与清单表是一对多的关系,购买记录：

购买清单：

或：