《uml案例_超市进销存系统》由会员分享，可在线阅读，更多相关《uml案例_超市进销存系统（38页珍藏版）》请在金锄头文库上搜索。
1、练习:请对超市进销存系统进行UML建模,系统需满足的基本需求如下： 1、销售： 售货员接受顾客订购，输入顾客购买的商品，计算总价 顾客付款并接受清单 售货员保存顾客购买的商品记录 2、库存： 库存管理员每天进行盘点 库存管理员每天发现库存商品有损坏时，及时到相关部门报损 供应商的商品到货时，超市人员首先检查商品是否合格，并将合格商品入库处理 经理、统计分析员根据需要进行相关商品的模糊查询或详细查询 3、订货： 订货员用新商品供应商信息更新供应商数据库的信息 订货员统计库存商品是否低于库存下限，然后制作订货单 4、经理： 经理在促销期间或节日期间，注明相关商品的促销价格和手段 经理按市场情况经常
2、变动商品价格,练习:请对超市进销存系统进行UML建模,绘出整个用例图 绘出几个用例的顺序图 绘出基于上述顺序图得出的类图 给出“订货单”对象的状态图,分析1,1、销售： 售货员接受顾客订购，输入顾客购买的商品，计算总价 顾客付款并接受清单 售货员保存顾客购买的商品记录,1、销售： 1.售货员接受顾客订购 2.售货员输入顾客购买的商品 3.售货员计算总价 4.顾客付款 5.顾客接受清单 6.售货员保存顾客购买的商品记录,问题： 1. 接受顾客订购是什么意思？就是打开相关的业务处理界面，开始一次新业务 2.输入商品是可以多次重复的 3.计算总价系统计算 4.顾客付款系统接受或确认付款 5.顾客接受
3、清单清单哪里来的？应该是前面某一步骤中打印出来的(付款后),分析1,销售： 1.打开业务界面，开始一次新的销售； 2.输入顾客购买的商品(可重复多次) 3.计算总价 4.接受付款 5.打印清单并交给顾客 6.保存购买记录？,1、销售,本场景中可能比较特殊的步骤： 1.付款 系统会支持什么样的支付方式未知 如果只收现金，则系统中只需要售货员确认已收款 如果支持刷卡，系统需要有支付接口 详细情况 2.保存购买记录,1、销售,可能特殊的步骤，与重复的步骤一样，可用包含关系列出：,1、销售,本场景中可能存在的实体类有： 商品：应该会有ID、名称、单价等属性 总价：应该是清单和购买记录的一项数据。 清单
4、：给顾客看的纸 购买记录：与清单的内容应该是一致的（是一致，不是一样）,最终结果：商品，购买记录,2、库存,需求描述： 库存管理员每天进行盘点 库存管理员每天发现库存商品有损坏时，及时到相关部门报损 供应商的商品到货时，超市人员首先检查商品是否合格，并将合格商品入库处理 经理、统计分析员根据需要进行相关商品的模糊查询或详细查询,提到的业务： 1.盘点(库存管理员) 盘点时，如果发现有损坏则报损 2.入库(超市人员?也可能就是库存管理员) 入库时先检查商品是否合格 3.查询(经理、统计分析员) 以上三种业务相对独立,2、库存,3、订货,需求描述： 订货员用新商品供应商信息更新供应商数据库的信息
5、订货员统计库存商品是否低于库存下限，然后制作订货单,提到的业务： 1.更新供应商数据库 2.订货 条件：某商品的库存低于下限 制作订货单是一个步骤 应该会有选择供应商这个步骤 以上两种业务虽然有关联，但相对独立,3、订货,有关的类：供应商数据库，订货单,4、统计,需求描述： 经理在促销期间或节日期间，注明相关商品的促销价格和手段 经理按市场情况经常变动商品价格,提到的业务： 1.促销： 条件：特殊时期 2.调整商品价格 条件：根据市场变动 促销有可能也是调整商品价格的一种，但是还有个“手段”不详，所以暂按二者是不同业务来处理,4、统计,结合刚才已定义的查询业务：,初步类图,“销售”场景的时序,
6、已知参与者：售货员 已知实体：商品，购买记录 需要构造一个边界类：销售UI 可输入商品 可计算总价 可确认顾客已付款 可打印清单,“销售”场景的时序,“销售”场景的时序,如果要求边界类与控制类分离，则： 再增加一个控制类； 读取商品信息和保存购买记录这两项要求不应由UI直接向实体类提出，而是向控制类提出，由控制类再调用实体类的操作。,“销售”场景的时序,“订货”场景的时序,相关业务： 条件：某商品的库存低于下限即需要先统计各商品的数量 制作订货单是一个步骤 应该会有选择供应商这个步骤 已知参与者：订货员 已知实体：供应商DB，订货单，商品,问题：库存数量,怎么得知某商品的库存数量？ 最简单有效
7、的方法：“商品”类增加一个“数量”属性； “商品”类还应该有一个“统计库存”操作，功能是把库存数低于某数量的商品都找出来。,问题：库存数量,哪些业务与此属性有关？ 订货时，要参考此属性； 货到后，入库，要相应增加数量； 每日盘点，发现损坏，要相应减少数量； 销售时，售出的商品要相应减少数量；,以上可总结为同一操作！-更新库存(),问题：库存数量,哪些业务与此属性有关？ 入库，盘点，销售这三个用例都要用到“更新库存”操作，可考虑提取出一个子用例。 销售时，售出的商品要相应减少数量，所以，前面的时序图中，应该加上此项操作。,更新用例图,更新“销售”时序图,回到“订货”场景,已知参与者：订货员 已知
8、实体：供应商DB，订货单，商品 需要构造一个边界类：订货UI 可要求统计商品库存，并列出库存低于下限的商品； 对满足条件的商品，可以要求制作(创建)订货单； 针对商品可列出供应商，供订货员选择。 可构造一个控制类，来跟相关的实体类打交道。,“订货”场景的时序,研究一下“订货单”的状态,对象-订货单： 订货时创建，创建后到提交给供货商之间，都可以改变（更换供货商，更改订货数量等） 提交后，等待所订商品到货； 到货后，检查并办理入库手续； 入库完成后，该订单完成。,待定状态 等货状态 入库中 已完成,研究一下“订货单”的状态,对象-订货单： 订货时创建，创建后到提交给供货商之间，都可以改变（更换供
9、货商，更改订货数量等） 提交后，等待所订商品到货； 到货后，检查并办理入库手续； 入库完成后，该订单完成。,当然，入库时若发现有问题，可能还会有个“投诉状态”或是“退货状态”之类,“订货单”,所以， “订货单”类应该有一个“状态”属性,相关活动,加上对象流,此时的类图,对实体类进行数据库设计(1),商品： 商品编号，名称，类别，单价，数量 供应商： 需增加一个OID-供货商编号 名称，地址，商品编号，价格 订货单： 需增加一个OID订单编号 商品编号，数量，供货商编号，状态,商品：,供应商：,订货单：,对实体类进行数据库设计(2),购买记录： 需要增加一个对象OID记录编号 “所购商品”有多个商品，可以另开一个表“购买清单”： 记录编号，商品编号，数量 记录表与清单表是一对多的关系,购买记录：,购买清单：,或：,
