Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,1-1,练习:请对超市进销存系统进行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订单编号,商品编号，数量，供货商编号，状态,商品编号,名称,类别,单价,库存数量,P,商品：,供货商编号,名称,地址,商品编号,价格,P,F,供应商：,订单编号,商品编号,数量,供货商编号,状态,P,F,F,订货单：,对实体类进行数据库设计(2),购买记录：,需要增加一个对象OID记录编号,“所购商品”有多个商品，可以另开一个表“购买清单”：,记录编号，商品编号，数量,记录表与清单表是一对多的关系,。
