UML面向对象的与设计概述.pptVIP

* 5.1 职责驱动设计 5.2 GRASP 创建者(Creator) 信息专家(Information Expert) 低耦合(Low Coupling) 控制器(Controller) 高内聚(High Cohesion) 5.3 用例实现 5.4 NextGenPOS迭代的用例实现 教材CH17, 18 5 细化迭代1—GRASP1 * 图17-1 制品关系（强调了对OO设计的影响 * UML定义职责(Responsibility)为“类元的契约或义务”。 方法(Method)用来实现（履行）职责。 一个职责可能要许多类和方法(method)来实现，也可能只要很少方法来实现，这是由职责的粒度(granularity)来决定的。 职责和方法 * 职责可分成两类： “认知”责（knowing） “知道”私有的封装数据 “知道”相关联的对象 “知道”能够派生或计算出的事物 “行为”职责（doing） “做”自身的一些事情。如创建一个对象或进行一次计算。 “做”其它对象的初始化操作。 控制和协调其它对象的活动。 * 在UML制品（Artifacts）中，通常是在建立交互图的语境来考虑对象的职责分配，通过方法来实现职责。 图17-2 职责与方法是相关的 职责和交互图 * 为解决某些问题而设计的解决方案，可作为通用原则(General Principles)和惯用法(Idioms)，用于指导软件设计。 以结构化的形式加以描述，给出问题和解决方案，然后起一个名字。这就是设计模式(Patterns)。 模式名：信息专家（Information Expert） 问题：为了获取某些信息，分配职责给对象的基本原则是什么？ 解决方案：将职责分配给信息专家 -- 含有满足职责所需信息的类。 设计模式是一些针对特定问题的成功的解决方案 设计模式（Patterns） * GRASP 作为设计模式来描述对象设计和职责分配的基本原则。 GRASP模式： 创建者(Creator) 信息专家(Information Expert) 低耦合(Low Coupling) 控制器(Controller) 高内聚(High Cohesion) General Responsibility Assignment Software Pattern GRASP：职责分配通用原则 * 模式名：创建者 问题：谁创建了A？ 解决方案：如果以下条件之一成立，则可以将创建类A实例的职责分配给类B。 B包含或组成聚集了A； B记录了A； B紧密地使用A； B具有A的初始化数据 1.创建者（Creator） * 图17-12 部分领域模型 创建者模式示例：谁该负责创建SalesLineItem？ * 图17-13 创建SalesLineItem Sale，因为它包含了SalesLineItem * 模式名：信息专家（或专家） 问题：给对象分配职责的基本原则是什么？ 解决方案：将职责分配给具有完成该职责所需信息的那个类 2. 信息专家(Information Expert) * 图17-14 Sale的关联 答案：查找具有完成职责所需信息的类。 1）如果DCD中存在相关类，则在DCD中查找 2）否则查看领域模型，并尝试利用(或扩充)它的表示，以激发相应设计类的创建 示例：谁应当负责了解销售的总额 * 图17-15 部分交互图和类图 Sale的新职责 * 图17-16 计算Sale的总额 SalesLineItem的新职责 * 图17-17 计算Sale的总额 ProductDescription的新职责 * 模式名：低耦合 问题：如何减少因变化产生的影响？ 解决方案：分配职责以使(不必要的)耦合保持在较低的水平。使用该原则对可选方案进行评估 低耦合能够减少修改软件所需的时间、工作量和缺陷。 3. 低耦合（Low Coupling） * 图17-18 Register创建Payment Register记录了Payment Sale具有初始化Payment的数据（支付总额），另外支付是针对Sale进行的 方案一（创建者模式）： 示例：谁负责创建Payment * 图17-19 Sale创建Payment 结论：方案二耦合度更低。 禁忌：高耦合对于稳定和普遍使用的元素而言不是问题。如Java库。 方案二（创建者模式）： * 模式名：控制器 问题：在UI层之上首先接收和协调(控制)系统操作的对象是什么？ 解决方案：将接收或处理系统事件消息的职责分派给代表下列事务的类： 代表全部“系统”或“根对象”，如MonopolyGame对象 代表运行软件的设备，如Phone，BankCashMachine 代表用例或会话出现。通常命名为用例名Handler