《面向对象的分析与设计》讲义2

面向对象的分析与设计 Unified Process elaboration-2 Xiao ding tsEg

面向对象的分析与设计 Unified Process Elaboration - 2 Xiao ding TSEG

细化阶段:迭代2 设计模型 ■领域模型描述了概念类、属性、关联 用例模型表达了系统功能需求、系统事件和系统操作契约。 那么谁来完成系统的功能呢? 概念类转化到设计类(包括属性和关联) 设计类的职责是什么? 〉设计类如何协作处理系统事件、满足系统操作契约,并最终实现 系统功能来满足用例的需求? ■其中设计对象的职责非常关键。 GRaSP (General Responsibility Assignment Software Patterns) 是一种软件设计模式,称为对象职责分配模式

细化阶段：迭代2 设计模型 ◼ 领域模型描述了概念类、属性、关联 ◼ 用例模型表达了系统功能需求、系统事件和系统操作契约。 ◼ 那么谁来完成系统的功能呢？ ➢ 概念类转化到设计类（包括属性和关联） ➢ 设计类的职责是什么？ ➢ 设计类如何协作处理系统事件、满足系统操作契约，并最终实现 系统功能来满足用例的需求？ ◼ 其中设计对象的职责非常关键。 ◼ GRASP（General Responsibility Assignment Software Patterns） 是一种软件设计模式，称为对象职责分配模式

细化阶段:迭代2 GRASP基于职责设计对象 ■职责和方法:职责是抽象,方法实现了职责 对象的职责分为两种类型: 了解型( knowing) 了解私有的封装数据; 了解相关联的对象; 了解能够派生或者计算的事物。Sale具有了解其销售总额的职责 行为型( doing) 自身执行一些行为,如创建一个对象或者进行计算; 启动其他对象中的动作 ·控制或协调其他对象中活动。Sale具有创建 Salelineltem对象的职责 方法是对象操作的实现,是完成对象职责的手段。职责既 可以由一个方法实现,也可以与其他方法或者对象协作实 现

细化阶段：迭代2 GRASP 基于职责设计对象 ◼ 职责和方法：职责是抽象，方法实现了职责 ➢ 对象的职责分为两种类型： ◼ 了解型（knowing） ⚫ 了解私有的封装数据； ⚫ 了解相关联的对象； ⚫ 了解能够派生或者计算的事物。 ◼ 行为型（doing） ⚫ 自身执行一些行为，如创建一个对象或者进行计算； ⚫ 启动其他对象中的动作； ⚫ 控制或协调其他对象中活动。 ◼ 方法是对象操作的实现，是完成对象职责的手段。职责既 可以由一个方法实现，也可以与其他方法或者对象协作实 现。 Sale具有了解其销售总额的职责 Sale具有创建SaleLineItem对象的职责

细化阶段:迭代2 职责与顺序图 顺序图体现了如何为对象分配职责:一个对象接收了某条 消息,表明该对象具备了处理该条消息的职责 职责的分配来源于顺序图,也就是说当绘制顺序图的时候 就是在决定职责的分配。 POS机 make Payment(cashTendered) create(cashTendered) :付款 “POS”机使用 makePayment 消息向“销售”发出请求,“销 售”在相应的 makePayment方 法中进行处理;完成这个职责还 职责 需要通过协作创建“付款”对象, 并调用其构造器

细化阶段：迭代2 职责与顺序图 ◼ 顺序图体现了如何为对象分配职责：一个对象接收了某条 消息，表明该对象具备了处理该条消息的职责。 ◼ 职责的分配来源于顺序图，也就是说当绘制顺序图的时候 就是在决定职责的分配。 “POS”机使用makePayment 消息向“销售”发出请求，“销 售”在相应的makePayment方 法中进行处理；完成这个职责还 需要通过协作创建“付款”对象， 并调用其构造器 : POS机 : Sale : 付款 makePayment(cashTendered) 抽象，表示“销售”对 象具有创建“付款”的 职责 create(cashTendered)

细化阶段:迭代2 GRASP设计模式 ■创建者( Creator) ■信息专家( nformation Expert) ■控制器( Controller) ■低耦合( LoW Coupling) ■高内聚( High Cohesion) 多态( Polymorphism) ■纯虚构( Pure fabrication) ■间接性( Indirection) ■防止变异( Protected variations)

细化阶段：迭代2 GRASP 设计模式 ◼ 创建者（Creator） ◼ 信息专家（Information Expert） ◼ 控制器（Controller） ◼ 低耦合（Low Coupling） ◼ 高内聚（High Cohesion） ◼ 多态（Polymorphism） ◼ 纯虚构（Pure Fabrication） ◼ 间接性（Indirection） ◼ 防止变异（Protected Variations）

细化阶段:迭代2 GRASP创建者 问题来源:谁该负责创建某类的实例 解决方案:如果满足以下的条件之亠(越多越好),则可将创建类A 的职责分配给类B。 ■B聚合( aggregate)对象A; B包含( contain)对象A; ■B记录( record)对象A的多个实例; ■B密切使用对象A; ■B拥有创建对象A所需要的初始化数据(B是创建对象A的信息专家) 那么,B是对象A的创建者;如果有多个选项满足的情况下,首选聚 集或包含A的类B。 创建者模式的意图是寻找在任何情况下都与被创建者对象具有连接的 创建者,且具有低耦合的特点。 ■案例问题:谁应当负责创建 Salelineltem实例?

细化阶段：迭代2 GRASP 创建者 ◼ 问题来源：谁该负责创建某类的实例 ◼ 解决方案：如果满足以下的条件之一（越多越好），则可将创建类A 的职责分配给类B。 ◼ B聚合（aggregate）对象A； ◼ B包含（contain）对象A； ◼ B记录（record）对象A的多个实例； ◼ B密切使用对象A； ◼ B拥有创建对象A所需要的初始化数据（B是创建对象A的信息专家） ◼ 那么，B是对象A的创建者；如果有多个选项满足的情况下，首选聚 集或包含A的类B。 ◼ 创建者模式的意图是寻找在任何情况下都与被创建者对象具有连接的 创建者，且具有低耦合的特点。 ◼ 案例问题：谁应当负责创建SaleLineItem实例？

细化阶段:迭代2 GRASP创建者 ■在领域模型或用例说明中去寻找聚合、包含 SalelineItem实例的类。 发现概念类Sale包含多个 Salelinelte对象,为此根据创建者模式 Sale是具有创建 SalelineItem实例职责的候选者,进而可产生以下顺 序图 这个模式的优点在于支持低耦合 Sale 这个职责的分配要求在Sale makeLineItem(quantity) create(quantity) Salehi te中定义 Makelinelter方法。 强调:在绘制顺序图时考虑和 决定这些职责的分配

细化阶段：迭代2 GRASP 创建者 ◼ 在领域模型或用例说明中去寻找聚合、包含SaleLineItem实例的类。 ◼ 发现概念类Sale包含多个SaleLineItem对象，为此根据创建者模式， Sale是具有创建SaleLineItem实例职责的候选者，进而可产生以下顺 序图 ◼ 这个模式的优点在于支持低耦合 : POS机 : Sale : SaleLineItem makeLineItem(quantity) create(quantity) 这个职责的分配要求在Sale 中定义MakeLineItem方法。 强调：在绘制顺序图时考虑和 决定这些职责的分配

细化阶段:迭代2 GRASP信息专家 问题来源:给对象分配职责的原则是什么? 解决方案:将职责分配给拥有履行一个职责所必需信息的类,即信息 专家。换言之,对象处理自己拥有信息的事务。 案例问题:谁应该负责获取一次销售的总额? 在具体案例中,某个类需要知道一次销售的总额。即,谁应当了解销售 的总额? 设计模型中还没有软件类,怎么办? 此时,“信息专家”就是领域模型。 查看领域模型,找出拥有相关信息的概念类,将其应用或扩展到设计模 型,形成软件类 按照信息专家原则,我们找到了概念类Sale。 在设计模型中加入Sale软件类,为其分配获取总额的职责并以名为 get Total的方法来表示

细化阶段：迭代2 GRASP 信息专家 ◼ 问题来源：给对象分配职责的原则是什么？ ◼ 解决方案：将职责分配给拥有履行一个职责所必需信息的类，即信息 专家。换言之，对象处理自己拥有信息的事务。 ◼ 案例问题：谁应该负责获取一次销售的总额？ ➢ 在具体案例中，某个类需要知道一次销售的总额。即，谁应当了解销售 的总额？ ➢ 设计模型中还没有软件类，怎么办？ ➢ 此时，“信息专家”就是领域模型。 ➢ 查看领域模型，找出拥有相关信息的概念类，将其应用或扩展到设计模 型，形成软件类。 ➢ 按照信息专家原则，我们找到了概念类Sale。 ➢ 在设计模型中加入Sale软件类，为其分配获取总额的职责并以名为 getTotal的方法来表示

Salelinelte Records-salerof Item time ItemId 1:t tTotal( 1. 部分领域模型」1 法 getTotal0 Sale ProductDescription ItemID 按照信息专家模式找出软件类Sale的 get Tota橾操作 SalesLineltemquantity 销售总额=销售量x销售价格」 Productspecification price 1:1: t=getTotal o date ;PQS机 Sale etTotal o 注意:职责的实现需要分布 在不同的对象中的信息, 2: 2*[more items] st=getSubTotalO m个任务需要多个对象(信息 专家)协作来完成。 lineltems[i] Sale Descripti 3:2.1: getPriceo ItemID 为了实现获知和回答销售总 description price 额的职责,找到了三个对象 tRice o 并分配了三个职责

Sale date time SaleLineItem quantity Item ItemID ProductDescription ItemID description price 1..n 1 Contained-in 0..1 1 Records-sale-of 1 n describes 部分领域模型 按照信息专家模式找出软件类Sale的getTotal操作 销售总额＝销售量×销售价格 SalesLineItem.quantity ProductSpecification.price 注意：职责的实现需要分布 在不同的对象中的信息，一 个任务需要多个对象（信息 专家）协作来完成。 为了实现获知和回答销售总 额的职责，找到了三个对象 并分配了三个职责。 Sale date time getTotal() 添加一个新方 法getTotal() : POS机 : Sale 1: t = getTotal( ) : POS机 : Sale lineItems[i] : SaleLineItem : Product Description 1: 1:t=getTotal() 2: 2*[more items]:st=getSubTotal() 3: 2.1:getPrice() Sale date time getTotal() SaleLineItem quantity getSubTotal() Product Description ItemID description price getPrice()

细化阶段:迭代2 GRASP信息专家的优点 优点 >维持了信息封装性;因为对象使用自已的信息完成任务。支持了 低藕合,提高犭紧f的健狂裡和可暈护 >系统行为分散在不同的类中,这些类提供处理自己信息的能力, 使得这些类易于理解和维护。 注意: 个类按照信息专家模式得到的职责有很多种类型的时候,就 生了类的内聚性问题。 需要利用隔离原则,将不同逻辑方面的职责进行隔离,分配给不 同的软件对象,以提高内聚性。 ■相关模式:低耦合模式、高内聚模式

细化阶段：迭代2 GRASP 信息专家的优点 ◼ 优点： ➢ 维持了信息封装性，因为对象使用自己的信息完成任务。支持了 低耦合，提高了系统的健壮性和可维护性。 ➢ 系统行为分散在不同的类中，这些类提供处理自己信息的能力， 使得这些类易于理解和维护。 ◼ 注意： ➢ 当一个类按照信息专家模式得到的职责有很多种类型的时候，就 产生了类的内聚性问题。 ➢ 需要利用隔离原则，将不同逻辑方面的职责进行隔离，分配给不 同的软件对象，以提高内聚性。 ◼ 相关模式：低耦合模式、高内聚模式