《面向对象软件开发过程细化阶段深入课件》由会员分享，可在线阅读，更多相关《面向对象软件开发过程细化阶段深入课件（53页珍藏版）》请在金锄头文库上搜索。
1、第七章面向对象软件开发过程（3) 细化迭代深入1提纲提纲7c3.1 本次迭代需求7c3.2 建立用例关系7c3.3 泛化建模7c3.4 精化领域模型7c3.5 增加新的SSD和契约7c3.6 在状态图中为行为建模7c3.7 应用模式设计逻辑架构7c3.8 组织模型包的设计和实现7c3.9 架构分析和SAD的介绍7c3.10 对象持久化设计27c3.1 7c3.1 本次迭代需求本次迭代需求回顾：初始和前期细化迭代阶段考察需求分析和OOA/OOD的一系列基本问题。本次迭代:以更广的视角考察分析和设计的多个方面建立用例之间的关系泛化和特化状态建模分层架构包的设计架构分析对象持久化设计。37c3.2
2、7c3.2 建立用例关系建立用例关系用例之间的关系初始阶段：目标是用用例发现功能需求，忽略了用例之间的关系。用例之间存在包含（include，过去称use）和扩展（extend）关联关系。包含关系用例的一部分行为经常在其他多个用例中出现。如：信用卡支付流程经常出现在Process Sale、Process Rental等用例中，与其重复书写，不如分离到单独具有信用卡支付的子功能用例上，并说明它被包含在其他用例中。用例1:Process Sale主要成功场景：1.顾客携带购买的商品或服务到POS机结账7.顾客付款，系统处理支付。扩展：7b.用信用卡支付：包含Handle Credit Payme
3、nt用例。7c.用支票支付：包含Handle Check Payment用例。47c3.2 7c3.2 建立用例关系建立用例关系应用包含关系的目的：将多个用例中的重复功能独立形成子功能用例，避免用例功能的重复。（重用原则）将一个过长的用例分解成若干单元，以便更好理解此用例。（模块化原则）也可以描述异步事件的处理。如：顾客可以在任何时候取消购物。用例1:Process Sale主要成功场景：扩展：a*：在任何时间，顾客可以选择取消购物：包含Cancel Sale用例建模专家用例建模专家用例建模专家用例建模专家CockburnCockburn建议：尽量使用包含关系而非扩展和泛化。建议：尽量使用包含
4、关系而非扩展和泛化。建议：尽量使用包含关系而非扩展和泛化。建议：尽量使用包含关系而非扩展和泛化。57c3.2 7c3.2 建立用例关系建立用例关系扩展关系当一个用例的文本由于某种原因不允许被大量修改，但又存在一些新的扩展场景和条件步骤出现需要修改原始的用例文本，如何在不修改原始用例文本的基础上扩展这些场景呢？应用扩展关系应用扩展关系应用扩展关系应用扩展关系。扩展关系的思路：创建一个扩展用例，在该用例中描述从什么地方、在什么情况下扩展某个基用例的行为。其实，当原始用例文本允许修改的情况下，通常只需更新“扩展”部分，无需创建复杂的用例关系。注意：注意：注意：注意：1.1.不要花太多的时间研究用例之
5、间的关系，因为编写用例的重要工作不要花太多的时间研究用例之间的关系，因为编写用例的重要工作不要花太多的时间研究用例之间的关系，因为编写用例的重要工作不要花太多的时间研究用例之间的关系，因为编写用例的重要工作是编写用例文本。是编写用例文本。是编写用例文本。是编写用例文本。2.2.尽量使用包含关系，而不要使用扩展关系。尽量使用包含关系，而不要使用扩展关系。尽量使用包含关系，而不要使用扩展关系。尽量使用包含关系，而不要使用扩展关系。3.3.使用扩展关系的一个合适的动机是：不允许修改基用例文本。使用扩展关系的一个合适的动机是：不允许修改基用例文本。使用扩展关系的一个合适的动机是：不允许修改基用例文本。
6、使用扩展关系的一个合适的动机是：不允许修改基用例文本。67c3.2 7c3.2 建立用例关系建立用例关系77c3.3 7c3.3 泛化建模泛化建模本次迭代要处理信用卡和支票支付的场景用例1:Process Sale扩展：7b.用信用卡支付： 1.顾客输入信用卡账号信用卡账号信息 2.系统向外部的支付授权服务系统支付授权服务系统发出授权支付请求授权支付请求和批准支付的批准支付的请求请求 2a.系统侦测到与外部系统交互失败： 1.系统通知收银员有错误发生 2.收银员要求顾客改变支付方式 3.系统收到支付批准支付批准并通知收银员 3a.系统收到支付拒绝支付拒绝的通知 1.系统通知收银员系统拒绝支付
7、2.收银员要求顾客改变支付方式 4.系统记录信用卡的支付情况信用卡的支付情况，包括支付授权 5.系统初始信用卡签名的输入方式 6.收银员要求顾客为信用卡支付签名。顾客签名。87c3.3 7c3.3 泛化建模泛化建模出现了一些新的领域概念：CreditPaymentRequestCreditApprovalReply将一个类划分为子类的动机：1.子类具有额外的相关属性；（扩充属性）2.子类具有额外的相关关联；（子类继承父类的属性和关联）3.子类在运行、处理、反应或操作等相关方式上与超类或其他子类不同。（扩充操作）4.子类代表一个活动的事物，他们与超类的其他子类在相关的行为方式上相似但不同。（扩展
8、操作：多态）将多个子类概括为概念超类的动机：这多个子类代表一个相似概念的变体所有子类具有的相同属性可以提取并在超类中表示所有子类具有的相同关联都可以被提取并与超类相关。97c3.3 7c3.3 泛化建模泛化建模Payment类层次107c3.3 7c3.3 泛化建模泛化建模AuthorizationService层次117c3.3 7c3.3 泛化建模泛化建模PaymentAuthorizationTransaction层次一般地，与外部服务有关的交易在领域模型中表示出来是有价值的，因为可以解决与服务有关的活动和流程问题。127c3.4 7c3.4 精化领域模型精化领域模型将过去学习的OO概念
9、应用到POS领域模型：关联类、限定关联聚集与组合派生应用包组织模型137c3.4 7c3.4 精化领域模型精化领域模型应用关联类(ServiceContract)解决一个商店和多家授权服务机构之间的合约关系147c3.4 7c3.4 精化领域模型精化领域模型受限关联有序元素157c3.4 7c3.4 精化领域模型精化领域模型聚集和组合167c3.4 7c3.4 精化领域模型精化领域模型派生177c3.4 7c3.4 精化领域模型精化领域模型包的划分原则：同一个主题域由概念或目的紧密相关在同一个类层次中参与同一个用例紧密相关POS领域模型包187c3.4 7c3.4 精化领域模型精化领域模型广泛
10、共享、或者没有一个明显归属的概念可以置入Core/Misc包中。197c3.4 7c3.4 精化领域模型精化领域模型207c3.4 7c3.4 精化领域模型精化领域模型217c3.4 7c3.4 精化领域模型精化领域模型227c3.4 7c3.4 精化领域模型精化领域模型237c3.5 7c3.5 增加新的增加新的SSDSSD和契约和契约本次迭代处理顾客支付问题信用卡支付支票支付有一个共同的SSD开始247c3.5 7c3.5 增加新的增加新的SSDSSD和契约和契约信用卡支付SSDmakeCreditPayment支票支付SSDmakeCheckPayment257c3.5 7c3.5 增加
11、新的增加新的SSDSSD和契约和契约接下来的工作：描述系统操作makeCreditPayment的操作契约描述系统操作makeCheckPayment的操作契约发现一些可能的新的领域概念类利用GRASP模式将操作契约中完成状态的职责分配给不同的概念类（用交互图表示）从领域类转换到设计类（DCD表达）从交互图中寻找设计类的方法测试用例、代码实现267c3.5 7c3.5 增加新的增加新的SSDSSD和契约和契约系统操作契约277c3.6 7c3.6 在状态图中为行为建模在状态图中为行为建模状态图可以用来描述：一个类（概念类或者软件类）用例（描述外部系统事件的合法顺序）系统（因为一个系统也可以看成
12、一个类）用例状态图：表达系统事件顺序在设计模型中，用例的状态是由谁维持的？287c3.6 7c3.6 在状态图中为行为建模在状态图中为行为建模如果一个对象对于接收到的所有相同事件的处理方式是一样的，则该对象是状态无关的；如果采取不同的方式处理该事件，则该对象是状态相关的。为具有复杂行为的、与状态相关的对象创建状态图。用例（将其看作一个类）有状态的会话（session）它们是服务器端的软件对象，代表正在进行的会话或与客户端的交互。系统（可以看作一个特殊的用例）窗口控制器交易（销售、订单、支付）对事件的反应通常依赖于其状态。设备改变角色的类297c3.6 7c3.6 在状态图中为行为建模在状态图中
13、为行为建模事件的类型：外部事件：通常也称为系统事件，由系统外的事物引发。用SSD说明外部事件。内部事件：由系统内部事物导致的。一个对象发出的消息或者信号触发另一个对象的方法时意味着产生了一个内部事件。用交互图表达内部事件。时间事件：由一个指定日期和时间或者一段时间引发的事件。软件中，一个时间事件由一个实时或模拟的时钟驱动。优先使用状态图来说明外部和时间事件以及对事件的反应，而不是使用它来描述基于内部事件的对象行为。307c3.7 7c3.7 应用模式设计逻辑架构应用模式设计逻辑架构架构：是一组有关如下要素的重要决策：软件系统的组织、构成系统的结构化元素、接口、它们相互协作的行为的抉择；结构化元
14、素和行为元素逐步组合成粒度更大的子系统的方式的抉择；指导元素及其接口、协作和组合方式的架构风格的抉择。架构：不仅包括结构化元素，也包括行为元素，特别是系统和子系统的大尺度的职责及其协作。作为系统的一种描述，架构还要解释系统为什么以某种方式进行设计的动机或理由。UP中的架构分析架构调研：识别对系统存在或可能存在重大影响的功能性和非功能性需求（特别是非功能性需求）。广义上讲，这是对系统的重大设计决策有特别影响的需求进行分析。架构设计：对软件、硬件和网络、运营、政策等软件设计中的需求和要素进行决策。317c3.7 7c3.7 应用模式设计逻辑架构应用模式设计逻辑架构327c3.7 7c3.7 应用模
15、式设计逻辑架构应用模式设计逻辑架构layerlayerpartitionpartition一层就是一个包。337c3.7 7c3.7 应用模式设计逻辑架构应用模式设计逻辑架构一般层间耦合观点：1.所有较高层可依赖于技术服务层和基础层；2.依赖于业务基础设施层的领域层是要首先考虑的；3.表示层发出对应用层的调用，应用层再对领域层进行服务调用。表示层不直接对领域层进行调用，除非不存在应用层。4.如果应用是一个单进程的“桌面”程序，为了保证效率，领域层对其他层可见。5.如果是分布式系统，那么领域对象的的序列化复制对象（值对象或者数据容器对象）通常可以被传递到表示层。347c3.7 7c3.7 应用模
16、式设计逻辑架构应用模式设计逻辑架构应用层是可选的吗？如果存在应用层，那么它所包含的对象要负责：了解客户端的会话状态；协调表示层和领域层；控制工作流。GRASP控制器模式对象属于应用层EJB中会话Bean也属于应用层一些应用中可能不需要应用层，下述场合设置应用层是有价值的：系统使用多种用户界面。应用层对象作为适配器收集和合并不同UI需要的数据，同时作为外观封装和隐藏对领域层的访问。在分布式系统中，领域层和表示层在不同的节点上，并为多个客户端所共享时，通常需要跟踪会话状态，这种职责由应用层完成。领域层不能或不应维护会话状态有一个已定义的工作流，受其控制的实体必须按照顺序出现，应用层来完成这种职责。
17、357c3.7 7c3.7 应用模式设计逻辑架构应用模式设计逻辑架构早期的信息系统三层架构367c3.7 7c3.7 应用模式设计逻辑架构应用模式设计逻辑架构377c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现模型包组织原则：1.按照功能内聚垂直和水平划分成包基于功能内聚进行模块化：组合在一起的元素具有紧密的相关性，它们参与或实现共同的目的、服务、协作、策略和功能。2.将一族接口打包将一族功能相关的接口置于一个单独的包中，与这些接口的实现类分离。3.基于开发工作和不稳定的类簇打包包通常是开发工作和版本发布的基本单元在一个大型包中，针对开发工作的可以单独隔离成一个小包；在一个
18、大型包中，将不稳定的类簇和稳定的类簇隔离开来，分别形成子包，减少对不稳定包的过多依赖。387c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现4.职责最大的包应该最稳定如何提高包的稳定性：仅包含或主要包含接口和抽象类不依赖于其他包（独立的），或者只依赖于那些十分稳定的包，或者封装了依赖关系，使得依赖元素没有影响。如：利用外观对象封装了规则引擎子系统，规则引擎的实现发生变化，也不会影响依赖于它的包，因为依赖关系（表现在外观对象对规则引擎子系统）被封装。包含相对稳定的代码，如：java.util强制定义一个缓慢变更的时间表5.提取出独立的元素将可以被独立使用的或可在不同环境下使用的
19、元素组织成单独的包。397c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现6.使用工厂方法减少对具体化包的依赖尽量减少和含有具体类的包依赖工厂方法1.尽量依赖于接口或者抽象类，而不要直接依赖于具体类。2.使用领域对象工厂及接口来创建所有的领域对象是常用的设计思想。407c3.8 7c3.8 组织模型包的设计和实现组织模型包的设计和实现7.避免包之间的循环依赖如果一组包具有循环依赖关系，那么这些包应该作为同一个发布单元；但是，如果这个包较大的话，也会增加其他影响的可能性。所以，应该破除循环依赖关系。方法1.把参与循环依赖的元素提取出来形成一个新的小包；方法2.使用接口来破除循环
20、依赖417c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍架构分析的本质：识别可能影响架构的因素，了解其易变性和优先级，并解决这些问题。难点：有什么问题？如何权衡这些问题？解决这些问题有哪些方法？UP中，架构因素记录在补充规范中，架构决策记录在软件架构文档（SAD）中。架构分析在初始阶段就已经开始了（架构因素的描述），是细化阶段的重点。软件开发中，架构分析是具有高优先级和影响力的活动。架构分析定义：在功能性需求的语境中，有关识别和实现系统非功能性需求的活动。427c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍架构级别上需要定义和解决的一些问题：可靠性和容错
21、性是如何影响设计的？如：POS中远程服务中断，处理销售还要能进行。购买的子组件的许可成本将如何影响收益？分布式远程服务如何影响有关软件质量的需求和功能性需求？远程服务减少了许可成本（只需购买一份）为了减少交互的次数，要集中和远程服务交换数据。（无法实时响应）容易出现单点故障（远程服务不服务怎么办）适应性和可配置性将如何影响设计？对变化的适应性对客户需求的可配置性437c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍架构分析的一般步骤：1.识别和分析影响架构的非功能性需求功能性需求同样和架构有关，体现在功能的易变性上，非功能性要求要给予更充分的考虑，统称为架构因素。对架构最具影
22、响的因素包含在高层的FURPS+范畴之内。架构因素同样在需求分析中产生，只不过初始阶段以用例描述功能需求为主，将架构因素置于补充规范中。当细化阶段早期开始进行架构分析的时候，开发组要更细致地调查这些需求。2.对于那些对架构具有重要影响的需求而言，分析可选方案并做出处理这些影响的决定，这就是架构决策。447c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍简单因素表（记录架构因素）因素测量和质量场景可变性（当前灵活性和未来演化）因素对项目的影响获取成功的优先级困难或风险可靠性-可恢复性从远程服务失败中恢复当远程服务失败时，当侦听到服务重新在线的一分钟内重新与其建立连接，在产品环境
23、下实现正常的存储装载当前灵活性专家认为直到重新建立连接前，本地客户端简化的服务是可以接受的（也是可取的）演化在2年内，一些零售店可能选择支付本地完全复制远程服务的功能（如税金计算机器）。可能性？高对大规模设计影响大零售商确实不希望远程服务失败，因为这将限制或阻止他们使用POS进行销售高中457c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍架构设计：需要权衡架构因素相互依赖关系的优先级，并寻求解决方案。这些解决方案记录在：技术备忘录中（见下页）。架构设计的基本原则：低耦合高内聚受保护变化系统不同方面的分离和影响的局部化如：将持久化服务和安全服务分离到单独的包中，然后采用装饰模
24、式将其装饰到具体对象上。467c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍技术备忘录问题可靠性从远程服务故障中恢复解决方案概要：通过使用查询服务实现位置透明，实现从远程到本地的故障恢复和本地服务的部分复制。架构因素：1.从远程服务的故障中可靠恢复（如税金计算器、库存）2.从远程产品（描述和价格）数据库的故障中可靠恢复解决方案： 在服务工厂中创建一个适配器的实现获得服务位置的受保护变化。在所有可能的地方，通常简化或约束服务实现提供远程服务的本地实现。如：使用固定税率来实现本地税金的计算；本地产品信息数据对最常用产品进行缓存；库存更新在重新连接时存储和传递。 为了尽可能满足重
25、新连接远程服务ASAP的质量场景，对这些服务可采用代理对象，每一次服务调用时它测试远程服务是否需要重新激活，并且可以重新定位服务。动机： 零售商不想停止销售。遗留问题： 无考虑过的备选方案： 与提供远程信用授权服务的厂商签订“黄金级”服务协议以提高服务质量。该方案可行，但过于昂贵。477c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍UP中的架构视图1.逻辑视图用包描述系统的层、子系统、类和接口的软件的概念性组织，也概括了主要软件元素的功能；用类图描述类及类之间的关系；使用交互图描述重要的用例场景。2.进程视图进程和线程，用交互图和类图描述3.部署视图进程和组件到处理节点的物
26、理部署和节点之间的物理网络配置。4.数据视图给出从对象到持久化数据的映射规格。5.用例视图概括了架构上最重要的用例及其非功能性需求。6.实现视图实际可执行的源码，源码之间的关系（组件图）487c3.9 7c3.9 架构分析和架构分析和SADSAD的介绍的介绍软件架构文档（SAD）架构描述 （在本文档中将说明如何描述架构的概要，如使用技术备忘录和架构视图。这部分对不熟悉技术备忘录或视图的人有所帮助。注意并不需要所有的视图）架构因素和决定 （参考补充规范查阅因素表。同时，技术备忘录概要说明了架构决策。）逻辑视图 （UML包图和主要元素的类图）进程视图 （UML类图和交互图，描述系统的进程和线程。）
27、用例视图 （对最具有架构意义的用例的简明概括。）部署视图 （UML部署图展示了节点和所分配的进程与组件以及对系统网络结构的注释。）497c3.10 7c3.10 对象持久化设计对象持久化设计持久化：持久化对象：需要持久化存储的对象，如：ProductSpecification。物化（materialization）：从持久化存储中的非对象表示的数据（如记录）转换为对象的活动。延迟物化(Lazy Materialization)：并不是所有数据都立即物化成对象，按需物化。反物化（dematerialization）：将对象转换为持久化存储中的非对象表示数据的活动。O-R（对象关系）映射507c3.10 7c3.10 对象持久化设计对象持久化设计O-R映射：将对象表示为表（关系数据库）为每一个对象（或者对象的代理）和记录分配对象标识（object identifier）517c3.10 7c3.10 对象持久化设计对象持久化设计使用外观模式访问持久化服务持久化服务是O-R映射服务，由专业的持久化框架提供。框架实现了核心和稳定的功能，并包含了允许开发者嵌入可变的功能或扩展功能的机制。框架是内聚的类和接口的集合，它们的协作提供了一个逻辑子系统的核心和不变部分的服务。527c3.10 7c3.10 对象持久化设计对象持久化设计如何物化和反物化？53
