第7章面向对象软件开发过程细化阶段深入

1第七章面向对象软件开发过程（3)细化迭代深入2提纲§7c3.1本次迭代需求§7c3.2建立用例关系§7c3.3泛化建模§7c3.4精化领域模型§7c3.5增加新的SSD和契约§7c3.6在状态图中为行为建模§7c3.7应用模式设计逻辑架构§7c3.8组织模型包的设计和实现§7c3.9架构分析和SAD的介绍§7c3.10对象持久化设计3§7c3.1本次迭代需求回顾：–初始和前期细化迭代阶段考察需求分析和OOA/OOD的一系列基本问题。本次迭代:–以更广的视角考察分析和设计的多个方面建立用例之间的关系泛化和特化状态建模分层架构包的设计架构分析对象持久化设计。4§7c3.2建立用例关系用例之间的关系–初始阶段：目标是用用例发现功能需求，忽略了用例之间的关系。–用例之间存在包含（include，过去称use）和扩展（extend）关联关系。包含关系–用例的一部分行为经常在其他多个用例中出现。如：信用卡支付流程经常出现在ProcessSale、ProcessRental等用例中，与其重复书写，不如分离到单独具有信用卡支付的子功能用例上，并说明它被包含在其他用例中。用例1:ProcessSale主要成功场景：1.顾客携带购买的商品或服务到POS机结账……7.顾客付款，系统处理支付。……扩展：7b.用信用卡支付：包含HandleCreditPayment用例。7c.用支票支付：包含HandleCheckPayment用例。5§7c3.2建立用例关系–应用包含关系的目的：将多个用例中的重复功能独立形成子功能用例，避免用例功能的重复。（重用原则）将一个过长的用例分解成若干单元，以便更好理解此用例。（模块化原则）也可以描述异步事件的处理。–如：顾客可以在任何时候取消购物。用例1:ProcessSale主要成功场景：……扩展：a*：在任何时间，顾客可以选择取消购物：包含CancelSale用例建模专家Cockburn建议：尽量使用包含关系而非扩展和泛化。6§7c3.2建立用例关系扩展关系–当一个用例的文本由于某种原因不允许被大量修改，但又存在一些新的扩展场景和条件步骤出现需要修改原始的用例文本，如何在不修改原始用例文本的基础上扩展这些场景呢？应用扩展关系。–扩展关系的思路：创建一个扩展用例，在该用例中描述从什么地方、在什么情况下扩展某个基用例的行为。–其实，当原始用例文本允许修改的情况下，通常只需更新“扩展”部分，无需创建复杂的用例关系。注意：1.不要花太多的时间研究用例之间的关系，因为编写用例的重要工作是编写用例文本。2.尽量使用包含关系，而不要使用扩展关系。3.使用扩展关系的一个合适的动机是：不允许修改基用例文本。7§7c3.2建立用例关系8§7c3.3泛化建模本次迭代要处理信用卡和支票支付的场景用例1:ProcessSale……扩展：7b.用信用卡支付：1.顾客输入信用卡账号信息2.系统向外部的支付授权服务系统发出授权支付请求和批准支付的请求2a.系统侦测到与外部系统交互失败：1.系统通知收银员有错误发生2.收银员要求顾客改变支付方式3.系统收到支付批准并通知收银员3a.系统收到支付拒绝的通知1.系统通知收银员系统拒绝支付2.收银员要求顾客改变支付方式4.系统记录信用卡的支付情况，包括支付授权5.系统初始信用卡签名的输入方式6.收银员要求顾客为信用卡支付签名。顾客签名。9§7c3.3泛化建模出现了一些新的领域概念：–CreditPaymentRequest–CreditApprovalReply将一个类划分为子类的动机：–1.子类具有额外的相关属性；（扩充属性）–2.子类具有额外的相关关联；（子类继承父类的属性和关联）–3.子类在运行、处理、反应或操作等相关方式上与超类或其他子类不同。（扩充操作）–4.子类代表一个活动的事物，他们与超类的其他子类在相关的行为方式上相似但不同。（扩展操作：多态）将多个子类概括为概念超类的动机：–这多个子类代表一个相似概念的变体–所有子类具有的相同属性可以提取并在超类中表示–所有子类具有的相同关联都可以被提取并与超类相关。10§7c3.3泛化建模Payment类层次11§7c3.3泛化建模AuthorizationService层次12§7c3.3泛化建模PaymentAuthorizationTransaction层次一般地，与外部服务有关的交易在领域模型中表示出来是有价值的，因为可以解决与服务有关的活动和流程问题。13§7c3.4精化领域模型将过去学习的OO概念应用到POS领域模型：–关联类、限定关联–聚集与组合–派生–应用包组织模型14§7c3.4精化领域模型应用关联类(ServiceContract)解决一个商店和多家授权服务机构之间的合约关系15§7c3.4精化领域模型受限关联有序元素16§7c3.4精化领域模型聚集和组合17§7c3.4精化领域模型派生18§7c3.4精化领域模型包的划分原则：–同一个主题域－由概念或目的紧密相关–在同一个类层次中–参与同一个用例–紧密相关POS领域模型包19§7c3.4精化领域模型广泛共享、或者没有一个明显归属的概念可以置入Core/Misc包中。20§7c3.4精化领域模型21§7c3.4精化领域模型22§7c3.4精化领域模型23§7c3.4精化领域模型24§7c3.5增加新的SSD和契约本次迭代处理顾客支付问题–信用卡支付–支票支付–有一个共同的SSD开始25§7c3.5增加新的SSD和契约信用卡支付SSDmakeCreditPayment支票支付SSDmakeCheckPayment26§7c3.5增加新的SSD和契约接下来的工作：–描述系统操作makeCreditPayment的操作契约–描述系统操作makeCheckPayment的操作契约–发现一些可能的新的领域概念类–利用GRASP模式将操作契约中完成状态的职责分配给不同的概念类（用交互图表示）–从领域类转换到设计类（DCD表达）–从交互图中寻找设计类的方法–测试用例、代码实现27§7c3.5增加新的SSD和契约系统操作契约28§7c3.6在状态图中为行为建模状态图可以用来描述：–一个类（概念类或者软件类）–用例（描述外部系统事件的合法顺序）–系统（因为一个系统也可以看成一个类）用例状态图：表达系统事件顺序–在设计模型中，用例的状态是由谁维持的？29§7c3.6在状态图中为行为建模如果一个对象对于接收到的所有相同事件的处理方式是一样的，则该对象是状态无关的；如果采取不同的方式处理该事件，则该对象是状态相关的。为具有复杂行为的、与状态相关的对象创建状态图。–用例（将其看作一个类）–有状态的会话（session）－它们是服务器端的软件对象，代表正在进行的会话或与客户端的交互。–系统（可以看作一个特殊的用例）–窗口–控制器–交易（销售、订单、支付）－对事件的反应通常依赖于其状态。–设备–改变角色的类30§7c3.6在状态图中为行为建模事件的类型：–外部事件：通常也称为系统事件，由系统外的事物引发。用SSD说明外部事件。–内部事件：由系统内部事物导致的。一个对象发出的消息或者信号触发另一个对象的方法时意味着产生了一个内部事件。用交互图表达内部事件。–时间事件：由一个指定日期和时间或者一段时间引发的事件。软件中，一个时间事件由一个实时或模拟的时钟驱动。优先使用状态图来说明外部和时间事件以及对事件的反应，而不是使用它来描述基于内部事件的对象行为。31§7c3.7应用模式设计逻辑架构架构：是一组有关如下要素的重要决策：–软件系统的组织、构成系统的结构化元素、接口、它们相互协作的行为的抉择；–结构化元素和行为元素逐步组合成粒度更大的子系统的方式的抉择；–指导元素及其接口、协作和组合方式的架构风格的抉择。架构：–不仅包括结构化元素，也包括行为元素，特别是系统和子系统的大尺度的职责及其协作。–作为系统的一种描述，架构还要解释系统为什么以某种方式进行设计的动机或理由。UP中的架构分析–架构调研：识别对系统存在或可能存在重大影响的功能性和非功能性需求（特别是非功能性需求）。广义上讲，这是对系统的重大设计决策有特别影响的需求进行分析。–架构设计：对软件、硬件和网络、运营、政策等软件设计中的需求和要素进行决策。32§7c3.7应用模式设计逻辑架构33§7c3.7应用模式设计逻辑架构layerpartition一层就是一个包。34§7c3.7应用模式设计逻辑架构一般层间耦合观点：1.所有较高层可依赖于技术服务层和基础层；2.依赖于业务基础设施层的领域层是要首先考虑的；3.表示层发出对应用层的调用，应用层再对领域层进行服务调用。表示层不直接对领域层进行调用，除非不存在应用层。4.如果应用是一个单进程的“桌面”程序，为了保证效率，领域层对其他层可见。5.如果是分布式系统，那么领域对象的的序列化复制对象（值对象或者数据容器对象）通常可以被传递到表示层。35§7c3.7应用模式设计逻辑架构应用层是可选的吗？–如果存在应用层，那么它所包含的对象要负责：了解客户端的会话状态；协调表示层和领域层；控制工作流。GRASP控制器模式对象属于应用层EJB中会话Bean也属于应用层–一些应用中可能不需要应用层，下述场合设置应用层是有价值的：系统使用多种用户界面。应用层对象作为适配器收集和合并不同UI需要的数据，同时作为外观封装和隐藏对领域层的访问。在分布式系统中，领域层和表示层在不同的节点上，并为多个客户端所共享时，通常需要跟踪会话状态，这种职责由应用层完成。领域层不能或不应维护会话状态有一个已定义的工作流，受其控制的实体必须按照顺序出现，应用层来完成这种职责。36§7c3.7应用模式设计逻辑架构早期的信息系统三层架构37§7c3.7应用模式设计逻辑架构38§7c3.8组织模型包的设计和实现模型包组织原则：–1.按照功能内聚垂直和水平划分成包基于功能内聚进行模块化：组合在一起的元素具有紧密的相关性，它们参与或实现共同的目的、服务、协作、策略和功能。–2.将一族接口打包将一族功能相关的接口置于一个单独的包中，与这些接口的实现类分离。–3.基于开发工作和不稳定的类簇打包包通常是开发工作和版本发布的基本单元在一个大型包中，针对开发工作的可以单独隔离成一个小包；在一个大型包中，将不稳定的类簇和稳定的类簇隔离开来，分别形成子包，减少对不稳定包的过多依赖。39§7c3.8组织模型包的设计和实现–4.职责最大的包应该最稳定如何提高包的稳定性：–仅包含或主要包含接口和抽象类–不依赖于其他包（独立的），或者只依赖于那些十分稳定的包，或者封装了依赖关系，使得依赖元素没有影响。如：利用外观对象封装了规则引擎子系统，规则引擎的实现发生变化，也不会影响依赖于它的包，因为依赖关系（表现在外观对象对规则引擎子系统）被封装。–包含相对稳定的代码，如：java.util–强制定义一个缓慢变更的时间表–5.提取出独立的元素将可以被独立使用的或可在不同环境下使用的元素组织成单独的包。40§7c3.8组织模型包的设计和实现–6.使用工厂方法减少对具体化包的依赖尽量减少和含有具体类的包依赖工厂方法1.尽量依赖于接口或者抽象类，而不要直接依赖于具体类。2.使用领域对象工厂及接口来创建所有的领域对象是常用的设计思想。41§7c3.8组织模型包的设计和实现–7.避免包之间的循环依赖如果一组包具有循环依赖关系，那么这些包应该作为同一个发布单元；但是，如果这个包较大的话，也会增加其他影响的可能性。所以，应该破除循环依赖关系。–方法1.把参与循环依赖的元素提取出来形成一个新的小包；–方法2.使用接口来破除循环依赖42§7c3.9架构分析和SAD的介绍架构分析的本质：识别可能影响架构的因素，了解其易变性和优先级，并解决这些问题。–难点：有什么问题？如何权衡这些问题？解决这些问题有哪些方法？UP中，架构因素记录在补充规范中，架构决策记录在软件架构文档（SAD）中。