您好,欢迎访问三七文档
当前位置:首页 > 高等教育 > 大学课件 > 第7章面向对象软件开发过程细化阶段2
1第七章面向对象软件开发过程(3)细化迭代1:设计2提纲§7c2.1交互图表示法§7c2.2GRASP:根据职责设计对象§7c2.3设计模型:GRASP模式与用例实现§7c2.4设计模型:决定可见性§7c2.5设计模型:创建设计类图§7c2.6实现模型:将设计映射成代码3§7c2.1交互图表示法交互图展示对象之间如何通过消息交互,从而展示对象之间是如何协作完成系统行为的。(交互图的重要性可见一斑)顺序图协作图可以清楚地表示消息的顺序,但占用水平空间,作为简单表示法使用难以观察消息的顺序,但可以较好地展现复杂的分支、迭代以及并发行为,作为较复杂表示法使用。4§7c2.1交互图表示法协作图基本表示法注意点1.消息顺序号表示在当前控制线程下消息的传递顺序。2.第一条消息不编号;3.嵌套消息的序号跟在被嵌套消息序号后。发给自己的消息显式地创建实例的消息create带条件的消息5§7c2.1交互图表示法互斥消息:1a和1b迭代消息6§7c2.1交互图表示法多对象:用来指一系列实例……一个集合。两个*号表示消息getSubtotal循环发给多对象中的每个成员。发送给类的消息7§7c2.1交互图表示法顺序图基本表示法注意点对象的创建与销毁自反消息控制焦点位于激活箱中。条件与互斥消息8§7c2.1交互图表示法单条消息迭代系列消息迭代9§7c2.1交互图表示法发给多对象的消息发给类的消息10§7c2.2GRASP:根据职责设计对象领域模型描述了概念类、属性、关联,用例模型表达了系统功能需求、系统事件和系统契约。那么谁来完成系统的功能呢?–概念类转化到设计类(包括属性和关联)–设计类的职责是什么?–设计类如何协作处理系统事件,满足系统契约,并最终实现系统功能。–其中设计对象的职责非常关键。–GRASP(GeneralResponsibilityAssignmentSoftwarePatterns)是对象职责分配模式。11§7c2.2GRASP:根据职责设计对象职责和方法–对象的职责分为两种类型:了解型(knowing):–了解私有的封装数据;–了解相关联的对象;–了解能够派生或者计算的事物。行为型(doing):–自身执行一些行为,如创建一个对象或者进行计算;–启动其他对象中的动作;–控制或协调其他对象中活动。–方法是对象操作的实现,是完成对象职责的手段。职责既可以由一个方法实现,也可以与其他方法或者对象协作实现。12§7c2.2GRASP:根据职责设计对象职责和交互图–交互图体现了如何为对象分配职责:一个对象接收了某条消息,表明该对象具备了处理该条消息的职责。–职责的分配来源于交互图13§7c2.2GRASP:根据职责设计对象GRASP1:信息专家(informationexpert)模式–解决方案:将职责分配给拥有履行一个职责所必需信息的类—即信息专家。换言之,对象处理自己拥有信息的事务。–案例问题:谁应该负责获取一次销售的总额?设计模型中还没有软件类,怎么办?–查看领域模型,找出拥有相关信息的概念类,将其应用或扩展到设计模型,形成软件类。–按照信息专家原则,我们找到了概念类Sale。14§7c2.2GRASP:根据职责设计对象部分领域模型按照信息专家模式找出软件类Sale的getTotal操作销售总额=销售量×销售价格SalesLineItem.quantityProductSpecification.price注意:职责的实现需要信息,信息往往分布在不同的对象中,一个任务需要多个对象(信息专家)协作来完成。15§7c2.2GRASP:根据职责设计对象–优点:维持了信息封装性,因为对象使用自己的信息完成任务。支持了低耦合,提高了系统的健壮性和可维护性。系统行为分散在不同的类中,这些类提供处理自己信息的能力,使得这些类易于理解和维护。–注意:当一个类按照信息专家模式得到的职责有很多种类型的时候,类的内聚性就有问题了。需要利用隔离原则,将不同逻辑方面的职责进行隔离,分配给不同的软件对象,以提高内聚性。–相关模式:低耦合模式、高内聚模式16§7c2.2GRASP:根据职责设计对象GRASP2:创建者(creator)模式–解决方案:如果符合下面的一个或者多个条件,则可将创建类A的职责分配给类B。B聚合(aggregate)对象A;B包含(contain)对象A;B记录(record)对象A的多个实例;B密切使用对象A;B拥有创建对象A所需要的初始化数据。(B是创建对象A的信息专家)–案例问题:谁负责产生SalesLineItem类的实例?Sale类包含了SalesLineItem类的实例Sale类17§7c2.2GRASP:根据职责设计对象另外:工厂方法模式也是创建对象的指导原则18§7c2.2GRASP:根据职责设计对象GRASP3:低耦合(couple)模式–解决方案:分配一个职责给对象时,要保持对象间的低耦合度。减少对象间的依赖性,从而减少变更带来的影响,提高对象的重用性。耦合:测量一个元素连接、了解或者依赖其他元素的强弱尺度。使用高耦合性的类会出现的问题ABCD如果类A和其他的类之间关系简单一些就好了!修改A,会影响B,C,D?想重用A,太麻烦!19§7c2.2GRASP:根据职责设计对象案例问题:创建Payment实例,谁负责?创建者模式:Register记录了一次Payment。Register和Payment耦合。目的是:创建Payment实例,并和Sale进行关联。回顾领域模型,Sale和Payment有直接的关联Register和Payment之间解耦20§7c2.2GRASP:根据职责设计对象TypeX和TypeY耦合的常见形式:–TypeX具有引用TypeY实例或者TypeY本身的属性;–TypeX调用TypeY对象中的服务;–TypeX的方法中有TypeY类型(参数或返回)–TypeX是TypeY的直接或间接子类–TypeY是一个接口,TypeX实现了这个接口。耦合的权衡原则:–尽量降低耦合,但耦合是不可避免的,因为系统的任务是通过关联对象之间的协作完成的;–耦合一个高稳定的系统元素不是一个问题,因为不会发生变更。–更多地考虑与系统不稳定元素之间的耦合,尽量降低这种耦合。21§7c2.2GRASP:根据职责设计对象GRASP4:高内聚(cohesion)模式–解决方案:分配一个职责给对象时,要保持对象本身功能的高内聚度。对象内聚度:是对象职责联系的紧密程度。一个低内聚的对象会执行许多互不相干的功能,会导致下列问题:–难于理解、难于重用、难于维护;–系统脆弱,常常受到变化的影响。–大粒度对象,承担了本该委托给其他对象完成的职责。–经验:一个具有高内聚的类具有数目相对较少的方法和紧密相关的功能,但是它并不完成太多的工作。任务过大时,寻求与其他对象协作完成。现实生活中的类推:如果一个人完成太多的本应委托给别人完成的毫不相关的职责,这个人就不会有高效率。22§7c2.2GRASP:根据职责设计对象GRASP5:控制器(controller)模式–解决方案:把接收或者处理系统事件的职责分配给这样一个类:它代表整个系统、设备或者子系统(外观控制器Façadecontroller)它代表一个发生系统事件的用例场景,这个类通常命名为“用例名控制器”。(用例或者会话控制器usecase/sessioncontroller)–在相同的用例场景中使用同一个控制器类处理所有的系统事件;–一次会话是与一个角色进行交谈的一个实例。一个控制器是负责接收或者处理系统事件的非用户接口对象,它定义系统操作的方法。23§7c2.2GRASP:根据职责设计对象Actor1BoundaryClassUseCase124§7c2.2GRASP:根据职责设计对象一般的交互关系:Actor-边界类-控制类-实体类只是25§7c2.2GRASP:根据职责设计对象哪个对象应负责接收这个系统事件?有时称它为控制器或协调者。它通常不实现职责,而是将职责委托给其他对象控制器是从界面层到领域层的外观对象两种选择:外观控制器、用例控制器26§7c2.2GRASP:根据职责设计对象使用控制器的一些指导原则:–当一个系统不具有“太多”的系统事件,或者用户接口不可能将事件消息重定向到其他控制器时,选择外观控制器是合适的。这时,外观控制器相当于一个应用的封面,隔离了用户接口和应用逻辑。–如果在外观控制器中由于过多的职责而变得“臃肿”的时候,应该选择用例控制器。如果选择了用例控制器,那么每一个用例都有一个不同的控制类,而且只有一个,以便维护用例的状态。用例控制器可以实现有一定执行顺序的系统操作。–不论是外观控制器还是用例控制器,它们只是接收系统事件消息,并没有实现系统操作的职责,系统操作应该委托给领域对象处理。27§7c2.2GRASP:根据职责设计对象28§7c2.2GRASP:根据职责设计对象29§7c2.3设计模型:GRASP模式与用例实现用例实现:是在设计模型中用协作的对象描述如何实现一个特定用例[RUP]。–一个用例实现就是一个特定场景的对象协作。回忆前面所学的内容:1.用例模型使用用例表达角色希望系统达到的目标,用SSD表达角色发送给系统的事件,并建议将用例还没有表达清楚的系统操作效果在系统契约中描述。2.系统事件是角色激活系统执行系统操作的消息,系统执行一个用例场景,这就是一个用例实现。3.交互图中的对象是由领域模型中的概念类启发命名的软件对象,也包括为了设计而引入的纯虚构对象,交互图描述这些对象协作完成任务的交互过程。30§7c2.3设计模型:GRASP模式与用例实现项目相关人员眼中值得注意的领域概念对象开发者可以从现实世界领域获得启发而创建软件类。所以,项目相关人员所想像的领域与软件实现的领域之间的表示差距就降低了。从领域模型中的概念类到设计模型中的软件类。31§7c2.3设计模型:GRASP模式与用例实现对象设计:makeNewSale操作makeNewSale()交叉引用用例:ProcessSale前置条件无后置条件1.创建一个Sale实例s(实例创建)2.s和Register建立关联(关联形成)3.初始化s的属性(属性修改)选择Register作为控制类32§7c2.3设计模型:GRASP模式与用例实现注意:这不是一个SalesLineItem实例,而是一个容纳SalesLineItem对象的集合对象。(如list)33§7c2.3设计模型:GRASP模式与用例实现对象设计:enterItem操作enterItem(itemID:ItemID,quantity:integer)交叉引用用例:ProcessSale前置条件有一个销售正在进行后置条件1.创建一个SalesLineItem实例sli(实例创建)2.sli和当前的Sale建立关联(关联形成)3.sli.quantity变成参数quantity(属性修改)4.实例sli在itemID匹配的基础上与ProductSpecification建立关联(关联形成)思考:谁拥有ProductSpecification?Store?ProductCatalog?34§7c2.3设计模型:GRASP模式与用例实现35§7c2.3设计模型:GRASP模式与用例实现对象设计:endSale操作endSale()交叉引用用例:ProcessSale前置条件有一个销售正在进行后置条件1.Sale.isComplete变为真(属性修改)36§7c2.3设计模型:GRASP模式与用例实现处理销售的成功场景:–主要成功场景:1.顾客携带商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录单件商品,并显示该商品的描述、价格、累加值。价格可以根据一套定价规则来计算。收银员重复3~4步,直到商品输入结束。5.系统显示总值并计算税金。endSale后,销售总额应该生成并显示给客户。(
本文标题:第7章面向对象软件开发过程细化阶段2
链接地址:https://www.777doc.com/doc-8686890 .html