火龙果软件-UML开发案例汇编

统一建模语言开发案例：自动售货机系Part1

初步确定需求1、自动售货机系统是一种无人售货系统，其主要部件有：投币器、货币存储器和货物分配器。2、接收5角、1元硬币和10元及5元纸币。系统检测投入货币真伪及面值。假币退出，真币送入货币存储器。货币存储器记录顾客投入的货币金额（累加）。

3、拥有多个货物分配器，每个货物分配器管理一种货物（记录价格和数量）。顾客通过选择货物分配器来选择货物。如果分配器中有货物，且顾客支付的货币金额不小于其价格时，分配器将顾客选择的货物通过传送孔送给顾客。如果顾客支付的货币值小于所选择的分配器中货物的价格，机器将提示并等待顾客投入更多的货币。在选购完一种货物后，如果付款还有剩余则顾客可以继续购物。自动售货机系统需求概述4、每次投币时间有限制，设定每次投币时间不超过30秒，在时间到时，总币值不足顾客购买的商品单价时，自动售货机按钱数不足处理，退还全部货币。5、当顾客完成一次购买后或按错按钮后，显示余额等待继续输入或者找回余额。6、顾客购物完毕后，按下货币存储器的“找零钱”按钮，剩余的零钱将会返回到退币孔。自动售货机系统需求概述1:确定系统边界

具备自助售货功能的无人售货机。顾客自动售货机目标：购买商品2:寻找主要用例和目标明显的参与者：顾客，目标为购买商品潜在的参与者：

谁来启动、停止系统？谁来完成用户管理和安全管理？谁来完成系统管理？

“时间”是参与者吗？当系统失败时，是否存在监控进程将系统启动？

软件升级如何处理？是否有其他软件或系统调用该系统的服务谁来考查日志？是否支持远程检索？系统发生错误或故障时应通知谁？售货机管理员目标：（1）管理货物（2）管理货币2:寻找主要用例和目标参与者目标顾客购买商品管理员启动系统关闭系统管理货物管理货币3:绘制用例模型4:描述用例用例名称：购买商品执行者：顾客目的：完成一次购买商品的完整过程类型：主要的、基本的级别：一级前置条件：机器处于运行状态，有所选货物且零钱足够后置条件：系统送出所选货物并找零；更新货款帐务和剩余商品数量。4:描述用例用例名称：购买商品主成功场景（基本流程）：1.顾客投入货币。2.系统识别货币面值，记录并显示顾客投入的货币总额。

顾客重复1～2步直到投币结束。3.顾客选择商品。4.系统处理购买请求。5.系统更新货款帐务和剩余商品数量，并显示余额。6.系统送出顾客所选货物。

顾客重复3～6步直到购物结束。7.顾客按下找零按钮。8.系统吐出零钱（如果有）。9.顾客携带商品和找出的零钱离开（如果有）。4:描述用例用例名称：购买商品扩展（替代流程）：2a.无效货币。

(1)系统提示用户“无效货币”

(2)系统将投入的假币从退币口退出。4-6a.顾客的投币额为零。(1)系统提示用户“请先投币再选购货物”。4-6b.顾客选择的货物已售完。

(1)系统提示用户“此货物已售完，请选择其他货物或按下找零按钮返回您投入的货币。”。4-6c.零钱不能满足顾客所购商品的找零。

(1)系统提示用户“系统不够对该商品的选购找零，请选择其他商品”。4:描述用例用例名称：管理商品执行者：管理员目的：完成一次商品管理的完整过程类型：主要的、基本的级别：一级前置条件：机器已开启后置条件：更新出售商品的信息（名称、数量、价格）4:描述用例用例名称：管理商品主成功场景（基本流程）：1.管理员打开自动售货机。2.系统进入维护状态，此时不能售货。3.管理员选择一个需要更新的货物分配器并放入货物。4.管理员设置货物的名称、数量和价格。5.系统记录并显示货物的名称、数量和价格信息。

管理员重复2～4步直到管理结束。6.管理员关闭自动售货机。7.系统自动进入运行状态。5：领域业务建模领域中潜在的对象：顾客、管理员、自动售货机、货币、商品、投币器、货物分配器、货币存储器。Step5：领域业务建模领域模型：Part2

系统分析与设计Part2初步系统分析1:选择本次迭代所开发的用例——购买商品购买商品用例描述用例名称：购买商品执行者：顾客目的：完成一次购买商品的完整过程类型：主要的、基本的级别：一级前置条件：机器处于运行状态，有所选货物且零钱足够后置条件：系统送出所选货物并找零；更新货款帐务和剩余商品数量。用例名称：购买商品主成功场景（基本流程）：1.顾客投入货币。2.系统识别货币面值，记录并显示顾客投入的货币总额。

顾客重复1～2步直到投币结束。3.顾客选择商品。4.系统处理购买请求。5.系统更新货款帐务和剩余商品数量，并显示余额。6.系统送出顾客所选货物。

顾客重复3～6步直到购物结束。7.顾客按下找零按钮。8.系统吐出零钱（如果有）。9.顾客携带商品和找出的零钱离开（如果有）。用例名称：购买商品扩展（替代流程）：2a.无效货币。

(1)系统提示用户“无效货币”

(2)系统将投入的假币从退币口退出。4-6a.顾客的投币额为零。(1)系统提示用户“请先投币再选购货物”。4-6b.顾客选择的货物已售完。

(1)系统提示用户“此货物已售完，请选择其他货物或按下找零按钮返回您投入的货币。”。4-6c.零钱不能满足顾客所购商品的找零。

(1)系统提示用户“系统不够对该商品的选购找零，请选择其他商品”。2：系统时序图(SSD)：主场景2：系统时序图(SSD):主场景（续）2：系统时序图：扩展场景—假币2：系统时序图：扩展场景—缺货2：系统时序图：全部场景2：系统时序图：全部场景（续）操作契约在UP中，用例和系统特性是用来描述系统行为的主要方式，并且足以满足要求。有时需要对系统行为进行更为详细和精确的描述。操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化，并作为系统操作的结果。操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。UP制品的影响UP制品的相互影响强调了操作契约。该契约的主要输入是SSD中确定的系统操作（例如“投入货币”）、领域模型和领域专家的见解。该契约也可以作为对象设计的输入，因为它们描述的变化很可能是软件对象或数据库所需要的。契约下面对契约中的每个部分进行了描述：操作：操作的名称和参数。交叉引用：会发生此操作的用例。前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。这些假设比较重要，应该告诉读者。后置条件：最重要部分。完成操作后，领域模型对象的状态。后续章节将详细论述这个问题。契约－－示例操作：enterMoney(money:int)交叉引用：用例：购买货物前置条件：正在购买货物后置条件：※检测货币的物理特征数据，识别货币的真伪和面值。若货币面值非0，则在crcContainer.curPayment中累加顾客投币总额。其中crcContainer为货币存储器CurrencyContainer的实例。系统操作可以为系统操作定义操作契约－－系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。SSD展示了系统事件，即涉及系统的事件或IO消息。输入的系统事件意味着系统具有用来处理该事件的系统操作，正如OO消息（一种事件或信号）要由OO方法（一种操作）来处理那样。涉及所以用例的系统操作的完整集合将系统视为一个构件或类，定义了公共的系统接口。在UML中，作为整体的系统可以表示成名称为某个类的一个对象。后置条件后置条件（postcondition）描述了领域模型内对象状态的变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果，当操作完成后，这些结果为真。后置条件可以分为以下三种类型：创建或删除实例。属性值的变化。形成或消除关联（精确地讲，是UML链接）。如何创建和编写契约注意：大部分契约将在细化阶段进行编写，这时已经编写了大部分的用例。创建契约时可以应用以下指导：1）从SSD中确定系统操作2）如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约。3）使用以下几种类别来描述后置条件： 创建和删除实例。 修改属性。 形成和清除关联。最常见的问题是遗漏了关联的形成。特别是当创建了新实例时，通常需要建立与若干对象的关联。3：系统设计：投币部分3：系统设计：投币——物理特征3：系统设计：投币——检测面值3：系统设计：投币——检测面值new3：系统设计：投币——累加投币额命令——查询分类原则CQS（Command-QuerySeparationPrinciple）是针对方法的经典OO设计原则[Meyer88]。该原则指出，任何方法都可能使如下情况之一：

执行动作（更新、调整，……）的命令方法，这种方法通常具有改变对象状态等副作用，并且是void的（没有返回值）。向调用者返回数据的查询，这种方法没有副作用，不会永久性的改变任何对象的状态。一个方法不应该同时属于以上两种类型。3：系统设计：投币——当前的类图3：系统设计：投币——完整协作图3：系统设计：投币——完整顺序图3：系统设计：选购货物3：系统设计：选购——有货物判定3：系统设计：选购——销售条件判定根据信息专家模式：1）“判断投币额是否够”责任应该分配给“货币存储器”。2）“判断是否能够找零”该如何设计？（1）每种货币的面值、数量。（2）按照数量最小原则计算。3：系统设计：选购——销售货物3：系统设计：选购——当前的类图3：系统设计：选购——完整时序图3：系统设计：退币(找零)3：系统设计：退币——当前的类图3：系统设计：退币——完整的时序图3：系统设计方案的优化控制器VendingMachine存在的问题：做了太多的事情。内聚比较低。控制器涉及太多业务处理，与控制器的设计目标相背离。改进方案类似于CurrencyContainer，引入一个类专门用于管理所有的货物分配器GoodsDeliver。该类命名为GoodsDeliContainer。3：系统设计方案的优化--New3：系统设计方案的优化—New类图4：销售界面设计4：销售界面初始化时序图4：销售界面层－－（界面初始化）注意：单向关联（1）获取对控制器的感知VendingMachineVM;CVMDlgdlg(&VM);（2）从控制器获取必要的业务数据完成界面的初始化CArray<GDeliver*,GDeliver*>*pGDs;pGDs=VM->getGoodsDeliv();…….（3）向业务层注册监听器控制器4：销售界面层－－（定义监听器）/*CVMDlg.h*/#defineWM_TOTALPAYMENT_MESSAGE(WM_USER+100)#defineWM_MAKECHANGE_MESSAGE(WM_USER+101)#defineWM_DELIVERGOODS_MESSAGE(WM_USER+102)//Generatedmessagemapfunctions//{{AFX_MSG(CVMDlg)afx_msgLRESULTOnPaymentChange(WPARAMwParam,LPARAMlParam);//投币总金额变化消息映射函数afx_msgLRESULTOnMakeChange(WPARAMwParam,LPARAMlParam);//此处为找零消息映射函数afx_msgLRESULTOnDeliverGoods(WPARAMwParam,LPARAMlParam);//此处为吐出货物消息映射函数//}}AFX_MSGDECLARE_MESSAGE_MAP()4：销售界面层－－（定义监听器）/*CVMDlg.cpp*/BEGIN_MESSAGE_MAP(CVMDlg,CDialog)//{{AFX_MSG_MAP(CVMDlg)ON_MESSAGE(WM_TOTALPAYMENT_MESSAGE,OnPaymentChange)ON_MESSAGE(WM_MAKECHANGE_MESSAGE,OnMakeChange)ON_MESSAGE(WM_DELIVERGOODS_MESSAGE,OnDeliverGoods)//}}AFX_MSG_MAPEND_MESSAGE_MAP()LRESULTCVMDlg::OnPaymentChange(WPARAMwParam,LPARAMlParam){intdata=*(int*)(wParam);CStringstr=*(CString*)wParam;if("TotalPayment"==str){m_TotalPayment.Format("总金额：%.2f￥",*(float*)(lParam));UpdateData(false); }return0;}4：销售界面层－－（注册监听器）/*CVMDlg.cpp*/VM->registListener(this);/*VendingMachinecpp*/VendingMachine::registListener(CW