面向对象软件开发过程-细化阶段深入ppt课件

1、第七章面向对象软件开发过程3) 细化迭代深化提纲提纲7c3.1 本次迭代需求7c3.2 建立用例关系7c3.3 泛化建模7c3.4 精化领域模型7c3.5 添加新的SSD和契约7c3.6 在形状图中为行为建模7c3.7 运用方式设计逻辑架构7c3.8 组织模型包的设计和实现7c3.9 架构分析和SAD的引见7c3.10 对象耐久化设计7c3.1 7c3.1 本次迭代需求本次迭代需求回想：初始和前期细化迭代阶段调查需求分析和OOA/OOD的一系列根本问题。本次迭代:以更广的视角调查分析和设计的多个方面建立用例之间的关系泛化和特化形状建模分层架构包的设计架构分析对象耐久化设计。7c3.2 7c3.

2、2 建立用例关系建立用例关系 用例之间的关系 初始阶段：目的是用用例发现功能需求，忽略了用例之间的关系。 用例之间存在包含include，过去称use和扩展extend关联关系。 包含关系 用例的一部分行为经常在其他多个用例中出现。如：信誉卡支付流程经常出如今Process Sale、Process Rental等用例中，与其反复书写，不如分别到单独具有信誉卡支付的子功能用例上，并阐明它被包含在其他用例中。用例1:Process Sale主要胜利场景：1.顾客携带购买的商品或效力到POS机结账7.顾客付款，系统处置支付。扩展：7b.用信誉卡支付：包含Handle Credit Payment用

3、例。7c.用支票支付：包含Handle Check Payment用例。7c3.2 7c3.2 建立用例关系建立用例关系运用包含关系的目的：将多个用例中的反复功能独立构成子功能用例，防止用例功能的反复。重用原那么将一个过长的用例分解成假设干单元，以便更好了解此用例。模块化原那么也可以描画异步事件的处置。如：顾客可以在任何时候取消购物。用例1:Process Sale主要胜利场景：扩展：a*：在任何时间，顾客可以选择取消购物：包含Cancel Sale7c3.2 7c3.2 建立用例关系建立用例关系扩展关系当一个用例的文本由于某种缘由不允许被大量修正，但又存在一些新的扩展场景和条件步骤出现需求修

4、正原始的用例文本，如何在不修正原始用例文本的根底上扩展这些场景呢？运用扩展关系。扩展关系的思绪：创建一个扩展用例，在该用例中描画从什么地方、在什么情况下扩展某个基用例的行为。其实，当原始用例文本允许修正的情况下，通常只需更新“扩展部分，无需创建复杂的用例关系。7c3.2 7c3.2 建立用例关系建立用例关系7c3.3 7c3.3 泛化建模泛化建模 本次迭代要处置信誉卡和支票支付的场景 用例1:Process Sale 扩展： 7b.用信誉卡支付： 1.顾客输入信誉卡账号信息 2.系统向外部的支付授权效力系统发出授权支付恳求和同意支付的恳求 2a.系统侦测到与外部系统交互失败： 1.系统通知收银

5、员有错误发生 2.收银员要求顾客改动支付方式 3.系统收到支付同意并通知收银员 3a.系统收到支付回绝的通知 1.系统通知收银员系统回绝支付 2.收银员要求顾客改动支付方式 4.系统记录信誉卡的支付情况，包括支付授权 5.系统初始信誉卡签名的输入方式 6.收银员要求顾客为信誉卡支付签名。顾客签名。7c3.3 7c3.3 泛化建模泛化建模出现了一些新的领域概念：CreditPaymentRequestCreditApprovalReply将一个类划分为子类的动机：1.子类具有额外的相关属性；扩展属性2.子类具有额外的相关关联；子类承继父类的属性和关联3.子类在运转、处置、反响或操作等相关方式上与

6、超类或其他子类不同。扩展操作4.子类代表一个活动的事物，他们与超类的其他子类在相关的行为方式上类似但不同。扩展操作：多态将多个子类概括为概念超类的动机：这多个子类代表一个类似概念的变体一切子类具有的一样属性可以提取并在超类中表示一切子类具有的一样关联都可以被提取并与超类相关。7c3.3 7c3.3 泛化建模泛化建模Payment类层次7c3.3 7c3.3 泛化建模泛化建模AuthorizationService层次7c3.3 7c3.3 泛化建模泛化建模PaymentAuthorizationTransaction层次普通地，与外部效力有关的买卖在领域模型中表示出来是有价值的，由于可以处理与

7、效力有关的活动和流程问题。7c3.4 7c3.4 精化领域模型精化领域模型将过去学习的OO概念运用到POS领域模型：关联类、限定关联聚集与组合派生运用包组织模型7c3.4 7c3.4 精化领域模型精化领域模型运用关联类(ServiceContract)处理一个商店和多家授权效力机构之间的合约关系7c3.4 7c3.4 精化领域模型精化领域模型受限关联有序元素7c3.4 7c3.4 精化领域模型精化领域模型聚集和组合7c3.4 7c3.4 精化领域模型精化领域模型派生7c3.4 7c3.4 精化领域模型精化领域模型包的划分原那么：同一个主题域由概念或目的严密相关在同一个类层次中参与同一个用例严密

8、相关POS领域模型包7c3.4 7c3.4 精化领域模型精化领域模型广泛共享、或者没有一个明显归属的概念可以置入Core/Misc包中。7c3.4 7c3.4 精化领域模型精化领域模型7c3.4 7c3.4 精化领域模型精化领域模型7c3.4 7c3.4 精化领域模型精化领域模型7c3.4 7c3.4 精化领域模型精化领域模型7c3.5 7c3.5 添加新的添加新的SSDSSD和契约和契约本次迭代处置顾客支付问题信誉卡支付支票支付有一个共同的SSD开场7c3.5 7c3.5 添加新的添加新的SSDSSD和契约和契约信誉卡支付SSDmakeCreditPayment支票支付SSDmakeChec

9、kPayment7c3.5 7c3.5 添加新的添加新的SSDSSD和契约和契约接下来的任务：描画系统操作makeCreditPayment的操作契约描画系统操作makeCheckPayment的操作契约发现一些能够的新的领域概念类利用GRASP方式将操作契约中完成形状的职责分配给不同的概念类用交互图表示从领域类转换到设计类DCD表达从交互图中寻觅设计类的方法测试用例、代码实现7c3.5 7c3.5 添加新的添加新的SSDSSD和契约和契约系统操作契约7c3.6 7c3.6 在形状图中为行为建模在形状图中为行为建模 形状图可以用来描画： 一个类概念类或者软件类 用例描画外部系统事件的合法顺序

10、系统由于一个系统也可以看成一个类 用例形状图：表达系统事件顺序 在设计模型中，用例的形状是由谁维持的？7c3.6 7c3.6 在形状图中为行为建模在形状图中为行为建模假设一个对象对于接纳到的一切一样事件的处置方式是一样的，那么该对象是形状无关的；假设采取不同的方式处置该事件，那么该对象是形状相关的。为具有复杂行为的、与形状相关的对象创建形状图。用例将其看作一个类有形状的会话session它们是效力器端的软件对象，代表正在进展的会话或与客户端的交互。系统可以看作一个特殊的用例窗口控制器买卖销售、订单、支付对事件的反响通常依赖于其形状。设备改动角色的类7c3.6 7c3.6 在形状图中为行为建模在

11、形状图中为行为建模事件的类型：外部事件：通常也称为系统事件，由系统外的事物引发。用SSD阐明外部事件。内部事件：由系统内部事物导致的。一个对象发出的音讯或者信号触发另一个对象的方法时意味着产生了一个内部事件。用交互图表达内部事件。时间事件：由一个指定日期和时间或者一段时间引发的事件。软件中，一个时间事件由一个实时或模拟的时钟驱动。优先运用形状图来阐明外部和时间事件以及对事件的反响，而不是运用它来描画基于内部事件的对象行为。7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构架构：是一组有关如下要素的重要决策：软件系统的组织、构成系统的构造化元素、接口、它们相互协作的行为的抉择；构造

12、化元素和行为元素逐渐组合成粒度更大的子系统的方式的抉择；指点元素及其接口、协作和组合方式的架构风格的抉择。架构：不仅包括构造化元素，也包括行为元素，特别是系统和子系统的大尺度的职责及其协作。作为系统的一种描画，架构还要解释系统为什么以某种方式进展设计的动机或理由。UP中的架构分析架构调研：识别对系统存在或能够存在艰苦影响的功能性和非功能性需求特别是非功能性需求。广义上讲，这是对系统的艰苦设计决策有特别影响的需求进展分析。架构设计：对软件、硬件和网络、运营、政策等软件设计中的需求和要素进展决策。7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构7c3.7 7c3.7 运用方式设计逻

13、辑架构运用方式设计逻辑架构一层就是一个包。7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构普通层间耦合观念：1.一切较高层可依赖于技术效力层和根底层；2.依赖于业务根底设备层的领域层是要首先思索的；3.表示层发出对运用层的调用，运用层再对领域层进展效力调用。表示层不直接对领域层进展调用，除非不存在运用层。4.假设运用是一个单进程的“桌面程序，为了保证效率，领域层对其他层可见。5.假设是分布式系统，那么领域对象的的序列化复制对象值对象或者数据容器对象通常可以被传送到表示层。7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构运用层是可选的吗？假设存在运用层，那么它所包

14、含的对象要担任：了解客户端的会话形状；协调表示层和领域层；控制任务流。GRASP控制器方式对象属于运用层EJB中会话Bean也属于运用层一些运用中能够不需求运用层，下述场所设置运用层是有价值的：系统运用多种用户界面。运用层对象作为适配器搜集和合并不同UI需求的数据，同时作为外观封装和隐藏对领域层的访问。在分布式系统中，领域层和表示层在不同的节点上，并为多个客户端所共享时，通常需求跟踪会话形状，这种职责由运用层完成。领域层不能或不应维护会话形状有一个已定义的任务流，受其控制的实体必需按照顺序出现，运用层来完成这种职责。7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构早期的信息系统

15、三层架构7c3.7 7c3.7 运用方式设计逻辑架构运用方式设计逻辑架构7c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现模型包组织原那么：1.按照功能内聚垂直和程度划分成包基于功能内聚进展模块化：组合在一同的元素具有严密的相关性，它们参与或实现共同的目的、效力、协作、战略和功能。2.将一族接口打包将一族功能相关的接口置于一个单独的包中，与这些接口的实现类分别。3.基于开发任务和不稳定的类簇打包包通常是开发任务和版本发布的根本单元在一个大型包中，针对开发任务的可以单独隔离成一个小包；在一个大型包中，将不稳定的类簇和稳定的类簇隔分开来，分别构成子包，减少对不稳定包的过多依赖。7

16、c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现4.职责最大的包应该最稳定如何提高包的稳定性：仅包含或主要包含接口和笼统类不依赖于其他包独立的，或者只依赖于那些非常稳定的包，或者封装了依赖关系，使得依赖元素没有影响。如：利用外观对象封装了规那么引擎子系统，规那么引擎的实现发生变化，也不会影响依赖于它的包，由于依赖关系表如今外观对象对规那么引擎子系统被封装。包含相对稳定的代码，如：java.util强迫定义一个缓慢变卦的时间表5.提取出独立的元素将可以被独立运用的或可在不同环境下运用的元素组织成单独的包。7c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现6.运

17、用工厂方法减少对详细化包的依赖尽量减少和含有详细类的包依赖工厂方法1.尽量依赖于接口或者笼统类，而不要直接依赖于详细类。2.运用领域对象工厂及接口来创建一切的领域对象是常用的设计思想。7c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现7.防止包之间的循环依赖假设一组包具有循环依赖关系，那么这些包应该作为同一个发布单元；但是，假设这个包较大的话，也会添加其他影响的能够性。所以，应该废除循环依赖关系。方法1.把参与循环依赖的元素提取出来构成一个新的小包；方法2.运用接口来废除循环依赖7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见架构分析的本质：识别能够影响架

18、构的要素，了解其易变性和优先级，并处理这些问题。难点：有什么问题？如何权衡这些问题？处理这些问题有哪些方法？UP中，架构要素记录在补充规范中，架构决策记录在软件架构文档SAD中。架构分析在初始阶段就曾经开场了架构要素的描画，是细化阶段的重点。软件开发中，架构分析是具有高优先级和影响力的活动。架构分析定义：在功能性需求的语境中，有关识别和实现系统非功能性需求的活动。7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见架构级别上需求定义和处理的一些问题：可靠性和容错性是如何影响设计的？如：POS中远程效力中断，处置销售还要能进展。购买的子组件的答应本钱将如何影响收益？分布式远程效力

19、如何影响有关软件质量的需求和功能性需求？远程效力减少了答应本钱只需购买一份为了减少交互的次数，要集中和远程效力交换数据。无法实时呼应容易出现单点缺点远程效力不效力怎样办顺应性和可配置性将如何影响设计？对变化的顺应性对客户需求的可配置性7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见架构分析的普通步骤：1.识别和分析影响架构的非功能性需求功能性需求同样和架构有关，表达在功能的易变性上，非功能性要求要给予更充分的思索，统称为架构要素。对架构最具影响的要素包含在高层的FURPS+范畴之内。架构要素同样在需求分析中产生，只不过初始阶段以用例描画功能需求为主，将架构要素置于补充规范中

20、。当细化阶段早期开场进展架构分析的时候，开发组要更细致地调查这些需求。2.对于那些对架构具有重要影响的需求而言，分析可选方案并做出处置这些影响的决议，这就是架构决策。7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见简单要素表记录架构要素要素丈量和质量场景可变性当前灵敏性和未来演化要素对工程的影响获取胜利的优先级困难或风险可靠性-可恢复性从远程效力失败中恢复当远程效力失败时，当侦听到效力重新在线的一分钟内重新与其建立衔接，在产品环境下实现正常的存储装载当前灵敏性专家以为直到重新建立衔接前，本地客户端简化的效力是可以接受的也是可取的演化在2年内，一些零售店能够选择支付本地完全复

21、制远程效力的功能如税金计算机器。能够性？高对大规模设计影响大零售商确实不希望远程效力失败，由于这将限制或阻止他们运用POS进展销售高中7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见架构设计：需求权衡架构要素相互依赖关系的优先级，并寻求处理方案。这些处理方案记录在：技术备忘录中见下页。架构设计的根本原那么：低耦合高内聚受维护变化系统不同方面的分别和影响的部分化如：将耐久化效力和平安效力分别到单独的包中，然后采用装饰方式将其装饰到详细对象上。7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见技术备忘录问题可靠性从远程效力缺点中恢复处理方案概要：经过运用查询效

22、力实现位置透明，实现从远程到本地的缺点恢复和本地效力的部分复制。架构要素：1.从远程效力的缺点中可靠恢复如税金计算器、库存2.从远程产品描画和价钱数据库的缺点中可靠恢复处理方案： 在效力工厂中创建一个适配器的实现获得效力位置的受维护变化。在一切能够的地方，通常简化或约束效力实现提供远程效力的本地实现。如：运用固定税率来实现本地税金的计算；本地产品信息数据对最常用产品进展缓存；库存更新在重新衔接时存储和传送。 为了尽能够满足重新衔接远程效力ASAP的质量场景，对这些效力可采用代理对象，每一次效力调用时它测试远程效力能否需求重新激活，并且可以重新定位效力。动机： 零售商不想停顿销售。遗留问题： 无思索过的备选方案： 与提供远程信誉授权效力的厂商签署“黄金级效力协议以提高效力质量。该方案可行，但过于昂贵。7c3.9 7c3.9 架构分析和架构分析和SADSAD的引见的引见UP中的架构视图1.逻辑视图用包描画系统的层、子系统、类和接口的软件的概念性组织，也概括了主要软件元素的功能；用类图描画类及类之间的关系；运用交互图描画重要的用例场景。2.进程视图进程和线程，用交互图和类图描画3.部署视图进程和组件四处置节点的物理部署和节点之间的物理网络配置。4.数据视图给出从对象到耐久化数据的映射规格。5.用例视图概括了架构上最重要的用例及其非功能性需求。6.实现视图