细化迭代基础章.pptxVIP

第三部分 细化迭代1 —— 基础（3）;主要内容;第17章 GRASP：基于职责设计对象; 引言;17.1 UML与设计原则;17.2 对象设计：输入、活动和输出的示例;对象设计中的活动 对具有创造性、最苦难的部分建模。 运用各种OO设计原则给协作中的对象分配职责 对象设计的输出： 针对设计中的难点创建UML交互图、类图和包图 UI的草图和原型 数据库模型 报表的草图和原型;17.3 职责和职责驱动设计;职责方法;17.5职责、GRASP和UML图之间的联系;17.6 什么是模式;成为一个软件设计大师;模式优点;注意点;GOF关于设计模式的著作;17.8 使用GRASP进行对象设计的简短示例;创建者(Creator);从领域模型中获取灵感，使Board软件对象包含Square软件对象。;运用创建者模式;信息专家(Information Expert);为了能够检索和表示任何Square，s= getSquare（name） ，某个对象必须知道所有Square信息（持有其信息） Board聚集所有Square对象，因此Board具有履行此职责所必需的信息，所以将获知特定Square的职责分配给Board对象;低耦合(Low Coupling);为什么是Board而不是Dog?;信息专家模式支持低耦合;控制器;问题：怎样将UI层连接到应用逻辑层？从UI层接收playGame消息的第一个对象是Board吗？或者其他对象？ 控制器(Controller)模式定义 ;应用控制器模式——使用MonopolyGame;高内聚(High Cohesion);名称：高内聚(High Cohesion) 问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？ 解决方案（建议）：职责分配应该保持高内聚，以此来评估备选方案。;17.9 在对象设计中应用GRASP;17.10 创建者（Creator）;解决方案;示例;;讨论;禁忌;优点;17.11 信息专家（专家）;示例;部分领域模型;确定总额需要哪些信息？;SalesLineItem.quantity 信息专家：SalesLineItem ProcuctionDescription.price 信息专家：ProcuctionDescription;三个对象的设计类分配了如下职责：;讨论;禁忌;优点;17.12 低耦合;示例;方案1 (创建者模式）;方案2：;讨论;禁忌;权衡利弊;17.13：控制器（Controller）;示例;代表整个系统，设备或子系统 Register，POSSystem 代表一个与系统事件相对应的用例场景 ProcessSaleHandler,ProcessSaleSession;讨论;外观控制器;用例控制器;;优点;问题和解决方案;;;17.14：高内聚;示例;解决???案2;讨论;另外一个经典原则：模块化设计;内聚和耦合： “阴”和“阳”;禁忌;第18 使用GRASP的对象设计示例;18.1 用例实现;18.2 制品注释;通信图用于显示用例实现;顺序图用于显示用例实现 ;用例和用例实现;操作契约和用例实现;对于每一个契约，我们会依据对相关用例文本的 思考，完成后置条件的状态变更，并设计消息的交互以满足需求。;领域模型和用例实现;18.3 下一步工作;18.4 NextGen迭代的用例实现;设计启动之前探讨处理销售 用例实现;选择控制类;创建新的Sale;;如何设计enterItem;选择控制类;是否要显示商品项目的描述和价格;创建新的SalesLineItem;寻找ProductDescription;信息专家模式：表明持有完成职责所需信息的对象应该负责上述职责。 谁知道所有ProductDescription对象呢？ 依据领域模型，ProductCatalog 逻辑上包含所有的ProductDescription. ProductCatalog是实现查找ProductDescription职责的最佳候选者。 使用名为getProductDescription的方法实现这项查找工作。;ProductCatalog的可见性;enterItem最终设计——协作图;enterItem最终设计——类图;从数据库中检索ProductDescription;如何设计endSale;选择控制类;设置Sale.isComplete 属性;计算销售总额;分析过程：;谁应该负责计算总额？ 信息专家：因为Sale知道计算销售总额所必需的所有SaleLineItem实例，所以Sale将承担获知总额的职责。 销售条目小计？ 信息专家：因为SaleLineItem知道其数量和与之关联的ProductDescription，所以SaleLineItem 承担获知小计的职责。