《面向对象的系统分析与设计》UML开发案例.ppt

1: 第二次迭代所开发的用例 ——管理商品 管理商品详细用例图 基础信息类设计方法：－－(1)添加 基础信息类设计方法：－－(2)修改 2.管理商品界面设计 详细设计时序图 2.管理货币界面设计 系统操作 可以为系统操作定义操作契约－－ 系统操作是作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定。 SSD展示了系统事件，即涉及系统的事件或IO消息。输入的系统事件意味着系统具有用来处理该事件的系统操作，正如OO消息（一种事件或信号）要由OO方法（一种操作）来处理那样。 涉及所以用例的系统操作的完整集合将系统视为一个构件或类，定义了公共的系统接口。 在UML中，作为整体的系统可以表示成名称为某个类的一个对象。 后置条件 后置条件（postcondition）描述了领域模型内对象状态的变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。 后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果，当操作完成后，这些结果为真。 后置条件可以分为以下三种类型： 创建或删除实例。 属性值的变化。 形成或消除关联（精确地讲，是UML链接）。 如何创建和编写契约 注意：大部分契约将在细化阶段进行编写，这时已经编写了大部分的用例。 创建契约时可以应用以下指导： 1）从SSD中确定系统操作 2）如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约。 3）使用以下几种类别来描述后置条件： 创建和删除实例。 修改属性。 形成和清除关联。 最常见的问题是遗漏了关联的形成。特别是当创建了新实例时，通常需要建立与若干对象的关联。 3：系统设计：投币部分 3：系统设计：投币——物理特征 3：系统设计：投币——检测面值 3：系统设计：投币——检测面值new 3：系统设计：投币——累加投币额 命令——查询分类原则 CQS （ Command-Query Separation Principle ）是针对方法的经典 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：系统设计方案的优化--New 3：系统设计方案的优化—New类图 4：销售界面设计 4：销售界面初始化时序图 4：销售界面层－－（界面初始化） 注意：单向关联 （1）获取对控制器的感知 VendingMachine VM; CVMDlg dlg(VM); （2）从控制器获取必要的业务数据完成界面的初始化 CArrayGDeliver*, GDeliver* * pGDs; pGDs=VM-getGoodsDeliv(); ……. （3）向业务层注册监听器 控制器 4：销售界面层－－（定义监听器） /* CVMDlg .h*/ #define WM_TOTALPAYMENT_MESSAGE (WM_USER+100) #define WM_MAKECHANGE_MESSAGE (WM_USER+101) #define WM_DELIVERGOODS_MESSAGE (WM_USER+102) // Generated message map functions //{{AFX_MSG(CVMDlg) afx_msg LRESULT OnPaymentChange(WPARAM wParam, LPARAM lParam); //投币总金额变化消息映射函数 afx