(第7章面向对象软件开发过程细化阶段2.pptVIP

第七章面向对象软件开发过程（3) 细化迭代1：设计 提纲 §7c2.1 交互图表示法 §7c2.2 GRASP：根据职责设计对象 §7c2.3 设计模型：GRASP模式与用例实现 §7c2.4 设计模型：决定可见性 §7c2.5 设计模型：创建设计类图 §7c2.6 实现模型：将设计映射成代码 §7c2.1 交互图表示法 交互图展示对象之间如何通过消息交互，从而展示对象之间是如何协作完成系统行为的。（交互图的重要性可见一斑） 顺序图 协作图 §7c2.1 交互图表示法 协作图基本表示法注意点 §7c2.1 交互图表示法 §7c2.1 交互图表示法 §7c2.1 交互图表示法 顺序图基本表示法注意点 §7c2.1 交互图表示法 §7c2.1 交互图表示法 §7c2.2 GRASP：根据职责设计对象 领域模型描述了概念类、属性、关联，用例模型表达了系统功能需求、系统事件和系统契约。那么谁来完成系统的功能呢？ 概念类转化到设计类（包括属性和关联） 设计类的职责是什么？ 设计类如何协作处理系统事件，满足系统契约，并最终实现系统功能。 其中设计对象的职责非常关键。 GRASP（General Responsibility Assignment Software Patterns）是对象职责分配模式。 §7c2.2 GRASP：根据职责设计对象 职责和方法 对象的职责分为两种类型： 了解型（knowing）： 了解私有的封装数据； 了解相关联的对象； 了解能够派生或者计算的事物。 行为型（doing）： 自身执行一些行为，如创建一个对象或者进行计算； 启动其他对象中的动作； 控制或协调其他对象中活动。 方法是对象操作的实现，是完成对象职责的手段。职责既可以由一个方法实现，也可以与其他方法或者对象协作实现。 §7c2.2 GRASP：根据职责设计对象 职责和交互图 交互图体现了如何为对象分配职责：一个对象接收了某条消息，表明该对象具备了处理该条消息的职责。 职责的分配来源于交互图 §7c2.2 GRASP：根据职责设计对象 GRASP1：信息专家（information expert）模式 解决方案：将职责分配给拥有履行一个职责所必需信息的类—即信息专家。换言之，对象处理自己拥有信息的事务。 案例问题：谁应该负责获取一次销售的总额？ 设计模型中还没有软件类，怎么办？ 查看领域模型，找出拥有相关信息的概念类，将其应用或扩展到设计模型，形成软件类。 按照信息专家原则，我们找到了概念类Sale。 §7c2.2 GRASP：根据职责设计对象 §7c2.2 GRASP：根据职责设计对象 优点： 维持了信息封装性，因为对象使用自己的信息完成任务。支持了低耦合，提高了系统的健壮性和可维护性。 系统行为分散在不同的类中，这些类提供处理自己信息的能力，使得这些类易于理解和维护。 注意： 当一个类按照信息专家模式得到的职责有很多种类型的时候，类的内聚性就有问题了。 需要利用隔离原则，将不同逻辑方面的职责进行隔离，分配给不同的软件对象，以提高内聚性。 相关模式：低耦合模式、高内聚模式 §7c2.2 GRASP：根据职责设计对象 GRASP2：创建者（creator）模式 解决方案：如果符合下面的一个或者多个条件，则可将创建类A的职责分配给类B。 B聚合（aggregate）对象A； B包含（contain）对象A； B记录（record）对象A的多个实例； B密切使用对象A； B拥有创建对象A所需要的初始化数据。（B是创建对象A的信息专家） 案例问题：谁负责产生SalesLineItem类的实例？ Sale类包含了SalesLineItem类的实例?Sale类 §7c2.2 GRASP：根据职责设计对象 §7c2.2 GRASP：根据职责设计对象 §7c2.2 GRASP：根据职责设计对象 案例问题：创建Payment实例，谁负责？ §7c2.2 GRASP：根据职责设计对象 TypeX和TypeY耦合的常见形式： TypeX具有引用TypeY实例或者TypeY本身的属性； TypeX调用TypeY对象中的服务； TypeX的方法中有TypeY类型（参数或返回） TypeX是TypeY的直接或间接子类 TypeY是一个接口，TypeX实现了这个接口。 耦合的权衡原则： 尽量降低耦合，但耦合是不可避免的，因为系统的任务是通过关联对象之间的协作完成的； 耦合一个高稳定的系统元素不是一个问题，因为不会发生变更。 更多地考虑与系统不稳定元素之间的耦合，尽量降低这种耦合。 §7c2.2 GRASP：根据职责设计对象 GRASP4：高内聚（cohesion）模式 解决方案：分配一个职责给对象时，要保持对象本身功能的高内聚度。 对象内聚度：是对象职责联系的紧密程