《第7章面向对象软件开发过程细化阶段2》由会员分享，可在线阅读，更多相关《第7章面向对象软件开发过程细化阶段2（66页珍藏版）》请在金锄头文库上搜索。
1、第七章面向对象软件开发过程（3) 细化迭代1：设计1提纲提纲7c2.1 交互图表示法7c2.2 GRASP：根据职责设计对象7c2.3 设计模型：GRASP模式与用例实现7c2.4 设计模型：决定可见性7c2.5 设计模型：创建设计类图7c2.6 实现模型：将设计映射成代码27c2.1 7c2.1 交互图表示法交互图表示法交互图展示对象之间如何通过消息交互，从而展示对象之间是如何协作完成系统行为的。（交互图的重要性可见一斑）顺序图协作图可以清楚地表示消息的顺序，但占用水平空间，作为简单表示法使用难以观察消息的顺序，但可以较好地展现复杂的分支、迭代以及并发行为，作为较复杂表示法使用。37c2.1
2、 7c2.1 交互图表示法交互图表示法协作图基本表示法注意点1.消息顺序号表示在当前控制线程下消息的传递顺序。2.第一条消息不编号；3.嵌套消息的序号跟在被嵌套消息序号后。发给自己的消息显式地创建实例的消息create带条件的消息47c2.1 7c2.1 交互图表示法交互图表示法互斥消息：1a和1b迭代消息57c2.1 7c2.1 交互图表示法交互图表示法多对象：用来指一系列实例一个集合。两个*号表示消息getSubtotal循环发给多对象中的每个成员。发送给类的消息67c2.1 7c2.1 交互图表示法交互图表示法顺序图基本表示法注意点对象的创建与销毁自反消息控制焦点位于激活箱中。条件与互斥
3、消息77c2.1 7c2.1 交互图表示法交互图表示法单条消息迭代系列消息迭代87c2.1 7c2.1 交互图表示法交互图表示法发给多对象的消息发给类的消息97c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象领域模型描述了概念类、属性、关联，用例模型表达了系统功能需求、系统事件和系统契约。那么谁来完成系统的功能呢？概念类转化到设计类（包括属性和关联）设计类的职责是什么？设计类如何协作处理系统事件，满足系统契约，并最终实现系统功能。其中设计对象的职责非常关键。GRASP（General Responsibility Assignment Software Patte
4、rns）是对象职责分配模式。107c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象职责和方法对象的职责分为两种类型：了解型（knowing）：了解私有的封装数据；了解相关联的对象；了解能够派生或者计算的事物。行为型（doing）：自身执行一些行为，如创建一个对象或者进行计算；启动其他对象中的动作；控制或协调其他对象中活动。方法是对象操作的实现，是完成对象职责的手段。职责既可以由一个方法实现，也可以与其他方法或者对象协作实现。117c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象职责和交互图交互图体现了如何为对象分配职责：一个对象接收了
5、某条消息，表明该对象具备了处理该条消息的职责。职责的分配来源于交互图127c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象GRASP1：信息专家（information expert）模式解决方案：将职责分配给拥有履行一个职责所必需信息的类即信息专家。换言之，对象处理自己拥有信息的事务。案例问题：谁应该负责获取一次销售的总额？设计模型中还没有软件类，怎么办？查看领域模型，找出拥有相关信息的概念类，将其应用或扩展到设计模型，形成软件类。按照信息专家原则，我们找到了概念类Sale。137c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象部分
6、领域模型按照信息专家模式找出软件类Sale的getTotal操作销售总额销售量销售价格SalesLineItem.quantityProductSpecification.price注意：职责的实现需要信息，信息往往分布在不同的对象中，一个任务需要多个对象（信息专家）协作来完成。147c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象优点：维持了信息封装性，因为对象使用自己的信息完成任务。支持了低耦合，提高了系统的健壮性和可维护性。系统行为分散在不同的类中，这些类提供处理自己信息的能力，使得这些类易于理解和维护。注意：当一个类按照信息专家模式得到的职责有很多种类型的
7、时候，类的内聚性就有问题了。需要利用隔离原则，将不同逻辑方面的职责进行隔离，分配给不同的软件对象，以提高内聚性。相关模式：低耦合模式、高内聚模式157c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象GRASP2：创建者（creator）模式解决方案：如果符合下面的一个或者多个条件，则可将创建类A的职责分配给类B。B聚合（aggregate）对象A；B包含（contain）对象A；B记录（record）对象A的多个实例；B密切使用对象A；B拥有创建对象A所需要的初始化数据。（B是创建对象A的信息专家）案例问题：谁负责产生SalesLineItem类的实例？Sale类
8、包含了SalesLineItem类的实例Sale类167c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象另外：工厂方法模式也是创建对象的指导原则177c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象GRASP3：低耦合（couple）模式解决方案：分配一个职责给对象时，要保持对象间的低耦合度。减少对象间的依赖性，从而减少变更带来的影响，提高对象的重用性。耦合：测量一个元素连接、了解或者依赖其他元素的强弱尺度。使用高耦合性的类会出现的问题ABCD如果类如果类A A和其他的类之间和其他的类之间关系简单一些就好了！关系简单一些就好了！修改A
9、，会影响B,C,D？想重用A，太麻烦！187c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象案例问题：创建Payment实例，谁负责？创建者模式：Register记录了一次Payment。Register和Payment耦合。目的是：创建Payment实例，并和Sale进行关联。回顾领域模型，Sale和Payment有直接的关联Register和Payment之间解耦197c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象TypeX和TypeY耦合的常见形式：TypeX具有引用TypeY实例或者TypeY本身的属性；TypeX调用Typ
10、eY对象中的服务；TypeX的方法中有TypeY类型（参数或返回）TypeX是TypeY的直接或间接子类TypeY是一个接口，TypeX实现了这个接口。耦合的权衡原则：尽量降低耦合，但耦合是不可避免的，因为系统的任务是通过关联对象之间的协作完成的；耦合一个高稳定的系统元素不是一个问题，因为不会发生变更。更多地考虑与系统不稳定元素之间的耦合，尽量降低这种耦合。207c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象GRASP4：高内聚（cohesion）模式解决方案：分配一个职责给对象时，要保持对象本身功能的高内聚度。对象内聚度：是对象职责联系的紧密程度。一个低内聚的
11、对象会执行许多互不相干的功能，会导致下列问题：难于理解、难于重用、难于维护；系统脆弱，常常受到变化的影响。大粒度对象，承担了本该委托给其他对象完成的职责。经验：一个具有高内聚的类具有数目相对较少的方法和紧密相关的功能，但是它并不完成太多的工作。任务过大时，寻求与其他对象协作完成。现实生活中的类推：如果一个人完成太多的本应委托给别人完成的毫不相关的职责，这个人就不会有高效率。217c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象GRASP5：控制器（controller）模式解决方案：把接收或者处理系统事件的职责分配给这样一个类：它代表整个系统、设备或者子系统（外观
12、控制器 Faade controller）它代表一个发生系统事件的用例场景，这个类通常命名为“控制器”。（用例或者会话控制器 use case/session controller）在相同的用例场景中使用同一个控制器类处理所有的系统事件；一次会话是与一个角色进行交谈的一个实例。一个控制器是负责接收或者处理系统事件的非用非用户接口户接口对象，它定义系统操作的方法。227c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象237c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象一般的交互关系一般的交互关系一般的交互关系一般的交互关系：Actor
13、边界类控制类实体类只是只是247c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象哪个对象应负责接收这个系统事件？有时称它为控制器或协调者。它通常不实现职责，而是将职责委托给其他对象控制器是从界面层到领域层的外观对象两种选择：外观控制器、用例控制器257c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象使用控制器的一些指导原则：当一个系统不具有“太多”的系统事件，或者用户接口不可能将事件消息重定向到其他控制器时，选择外观控制器是合适的。这时，外观控制器相当于一个应用的封面，隔离了用户接口和应用逻辑。如果在外观控制器中由于过多的职责而变得“
14、臃肿”的时候，应该选择用例控制器。如果选择了用例控制器，那么每一个用例都有一个不同的控制类，而且只有一个，以便维护用例的状态。用例控制器可以实现有一定执行顺序的系统操作。不论是外观控制器还是用例控制器，它们只是接收系统事件消息，并没有实现系统操作的职责，系统操作应该委托给领域对象处理。267c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象277c2.2 GRASP7c2.2 GRASP：根据职责设计对象：根据职责设计对象287c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现用例实现：是在设计模型中用协作的对象描述如何实现一
15、个特定用例RUP。一个用例实现就是一个特定场景的对象协作。回忆前面所学的内容回忆前面所学的内容：1.用例模型使用用例表达角色希望系统达到的目标，用SSD表达角色发送给系统的事件，并建议将用例还没有表达清楚的系统操作效果在系统契约中描述。2.系统事件是角色激活系统执行系统操作的消息，系统执行一个用例场景，这就是一个用例实现。3.交互图中的对象是由领域模型中的概念类启发命名的软件对象，也包括为了设计而引入的纯虚构对象，交互图描述这些对象协作完成任务的交互过程。297c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现项目相关人员眼中值得注意的领域概念对象开发者
16、可以从现实世界领域获得启发而创建软件类。所以，项目相关人员所想像的领域与软件实现的领域之间的表示差距就降低了。从领域模型中的概念类到设计模型中的软件类。307c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现对象设计：makeNewSale操作makeNewSale()交叉引用用例：Process Sale前置条件无后置条件1.创建一个Sale实例s（实例创建）2.s和Register建立关联（关联形成）3.初始化s的属性（属性修改）选择Register作为控制类317c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例
17、实现注意：这不是一个SalesLineItem实例，而是一个容纳SalesLineItem对象的集合对象。（如list）327c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现对象设计：enterItem操作enterItem(itemID:ItemID,quantity:integer)交叉引用用例：Process Sale前置条件有一个销售正在进行后置条件1.创建一个SalesLineItem实例sli（实例创建）2.sli和当前的Sale建立关联（关联形成）3.sli.quantity变成参数quantity（属性修改）4.实例sli在itemID
18、匹配的基础上与ProductSpecification建立关联（关联形成）思考：谁拥有ProductSpecification？Store？ProductCatalog？337c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现347c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现对象设计：endSale操作endSale()交叉引用用例：Process Sale前置条件有一个销售正在进行后置条件1.Sale.isComplete变为真（属性修改）357c2.3 7c2.3 设计模型：设计模型：GRASPGRASP
19、模式与用例实现模式与用例实现处理销售的成功场景：主要成功场景：1.顾客携带商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格、累加值。价格可以根据一套定价规则来计算。收银员重复34步，直到商品输入结束。5.系统显示总值并计算税金。endSale后，销售总额应该生成并显示给客户。（本次迭代不考虑显示）367c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现377c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现对象设计：makePayment操作mak
20、ePayment(amount:Money)交叉引用用例：Process Sale前置条件有一个销售正在进行后置条件1.创建一个Payment实例p（实例创建）2.p.amountTendered等于amount（属性修改）3.p和当前的Sale建立关联（关联形成）4.当前的Sale和Store建立关联（关联形成）：目的是向已完成销售的历史日志中添加。主要成功场景：6.收银员请顾客付款。7.顾客支付，系统处理支付。8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统和库存系统。9.系统打印收据余额要打印，怎么生成？387c2.3 7c2.3 设计模型：设计模型：GRASPGRAS
21、P模式与用例实现模式与用例实现计算余额处理支付397c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现对象设计：startUp大多数系统都有一个startUp用例，以及一些用于启动应用的初始化系统操作。虽然startUp是最早执行的系统操作，但直到所有其他系统操作都考虑完后再为它进行交互图设计，这能保证已经将初始化活动进行了充分地挖掘。应用如何启动？建立一个初始领域对象，由它负责后续直接领域对象的创建。应用发送create消息以创建初始领域对象如果初始领域对象控制进程，则应用继续发送run消息给初始领域对象，移交应用控制权。407c2.3 7c2.3 设
22、计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现如何选择初始领域类？原则：选择领域对象的容器，或者聚集层次结构的根或临近根的类作为初始化领域对象的类。可能是一个外观控制器（Register），也可能是包含所有或大多数其他对象的类（Store）。417c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现将UI层与领域层相连一种方法：初始化例程（如Java的main方法）创建一个UI和一个领域对象，并将领域对象传递给UI。另一种方法：一个UI对象从一个大家熟知的源（如工厂对象）抽取领域对象。public class Main public s
23、tatic void main( String args ) Store store = new Store(); Register register = store.getRegister(); ProcessSaleJFrame frame = new ProcessSaleJFrame( register ); . 427c2.3 7c2.3 设计模型：设计模型：GRASPGRASP模式与用例实现模式与用例实现界面和领域层的职责UI层应不拥有任何领域逻辑职责，它只负责用户界面的任务，如更新可视化部件；UI层应将所有面向领域的请求转发给领域层，由领域层负责处理这些请求。437c2.4 7c
24、2.4 设计模型：决定可见性设计模型：决定可见性可见性：是一个对象看见或拥有另一个对象引用的能力。一个对象只有拥有另外一个对象的可见性（visibility）才能发送消息给该对象。对象A发送消息给对象B，A必须可见B。常见的四种可见性：（对象A可见对象B）属性可见性：B是A的属性。参数可见性：B是A的一个方法的参数。本地可见性：B是A的一个方法内部的局部变量。全局可见性：B具有某种形式的全局可见性，如单态类。447c2.4 7c2.4 设计模型：决定可见性设计模型：决定可见性457c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图设计类图（Design Class Diagra
25、m,DCD）交互图（用例实现，UCR）将处理系统消息的职责分配给设计类，DCD则将处理消息的职责转化为对象的方法。交互图和DCD经常并行交叉进行：画一部分交互图，然后更新DCD，再进一步扩展交互图，依此类推。DCD主要定义类的接口，不定义算法。基本的属性和关联类的接口：方法属性类型、属性可见性、对象导航等。467c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图477c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP1：通过扫描所有的交互图以及领域模型中涉及的类，识别参与软件解决方案的类。Register,ProductCatalog,Store,Pay
26、mentSale,ProductSpecification,SalesLineItemSTEP2:根据在领域模型中已经识别出来的部分属性，绘制适当的类图。注意：角色类未被转换到设注意：角色类未被转换到设注意：角色类未被转换到设注意：角色类未被转换到设计模型中。如：计模型中。如：计模型中。如：计模型中。如：CashierCashier。487c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP3:添加方法通过交互图获得每一个类的方法：一般，发送给类X的所有消息的集合就是类X必须定义的大多数方法。497c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图添加方法
27、要注意的几个问题：创建create消息一般被忽略，因为在编程语言中，每个类都有相应的构造函数来实现对象的创建。(但要注意构造函数的参数）为了实现封装性，每个对象一般都有简单的存取私有成员的get和set方法，这些方法是显然的，为了不干扰类图的可读性，不列出存取方法。发送给多对象的消息，处理消息的操作不是多对象中的每一个对象的方法，而是容纳这些对象的容器对象。507c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP4:添加更多的类型信息属性类型方法参数类型以及返回类型517c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP5:添加关联和导航导航（n
28、avigability）：是关联角色的一个属性，表示从一个源对象沿着关联导航方向可以单向地到达一个目标类。导航意指可见性通常是属性可见性。在OOPL中，从A关联导航到B，转换为类A中有一个类B的实例属性。定义A到B带导航修饰关联的常见情况：A发送一个消息到BA创建一个B的实例A需要维护到B的一个连接往往：一个对象的创建者要求拥有一个与它所创建对象的不间断连接。527c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图537c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图547c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP6:添加依赖关
29、系依赖关系：表示一个元素（类、用例等）对另外一个元素有所了解（用带箭头的虚线表示）。在类图中常用依赖关系表示类之间的非属性可见性（参数可见性、本地可见性、全局可见性）。属性可见性用关联和导航表达。Sale557c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图STEP7:类成员的细节表示（可选）成员可见性：惯例：属性私有，方法公有。方法体描述：注释。567c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图 1 1 2 2 3 3 4 4 577c2.5 7c2.5 设计模型：创建设计类图设计模型：创建设计类图完成的工件流程工件初始I1细化E1.En构造C1.Cn
30、移交T1.Tn业务建模 领域模型S需求用例模型SR构想SR补充规范SR术语表SR设计设计模型SR软件架构文档S数据模型SR实现实现模型SRR项目管理 软件开发计划SRRR测试测试模型SR环境开发案例SRS表示开始（Start），R表示提炼（Refine）587c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码由于采用迭代增量式开发，后一次迭代都是在前一次迭代的基础上开展的，因此，每一次迭代之前需要将前一次迭代产生的代码逆工程到设计模型，特别是当代码和设计模型有轻微的不一致的时候更需要这种逆向工程技术的支持。597c2.6 7c2.6 实现模型：将设计映射成代码实现模型：
31、将设计映射成代码从DCD（设计类图）创建类的定义用方法和简单属性定义类607c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码添加引用（reference）属性对象的引用属性是指引用另外一个对象作为自己的属性，而不是指简单类型的属性。一个类的引用属性由类图中的关联和导航来建议一般来讲：这个引用属性的名称就是导航方向的角色名称productSpec617c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码从交互图创建方法交互图显示了响应方法调用而发送的消息，这些消息的顺序将转换为方法定义中的一系列语句。627c2.6 7c2.6 实现模型：将设计映射
32、成代码实现模型：将设计映射成代码637c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码多对象的容器类/集合类在代码中的体现一个对象维护一组对其他对象的可见性通常是必要的；在类图中体现在多重性大于1的一端。647c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码类的实现和测试XP（eXtremProgramming）（Beck提出）提倡测试为先的编程（Test First Programming）因为我们先知道程序的结果再去考虑用程序实现，所以先编写好测试用例再去编程是合理的；好处：实际编写了单元测试（因为这个工作经常被遗忘！）程序员编写了一个通过测试的程序，而且在程序编写结束就知道了，有一种成就感。为类编写单元测试，可以使类的接口和行为更加清晰，因为直到实现前类的接口和行为还可能不是很清晰。成千上万个单元测试类提供了一个有意义的正确性校验。657c2.6 7c2.6 实现模型：将设计映射成代码实现模型：将设计映射成代码66
