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

第七章面向对象软件开发过程（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 本次迭代需求 回顾： 初始和前期细化迭代阶段考察需求分析和OOA/OOD的一系列基本问题。 本次迭代: 以更广的视角考察分析和设计的多个方面 建立用例之间的关系 泛化和特化 状态建模 分层架构 包的设计 架构分析 对象持久化设计。 §7c3.2 建立用例关系 用例之间的关系 初始阶段：目标是用用例发现功能需求，忽略了用例之间的关系。 用例之间存在包含（include，过去称use）和扩展（extend）关联关系。 包含关系 用例的一部分行为经常在其他多个用例中出现。如：信用卡支付流程经常出现在Process Sale、Process Rental等用例中，与其重复书写，不如分离到单独具有信用卡支付的子功能用例上，并说明它被包含在其他用例中。 §7c3.2 建立用例关系 应用包含关系的目的： 将多个用例中的重复功能独立形成子功能用例，避免用例功能的重复。（重用原则） 将一个过长的用例分解成若干单元，以便更好理解此用例。（模块化原则） 也可以描述异步事件的处理。 如：顾客可以在任何时候取消购物。 §7c3.2 建立用例关系 扩展关系 当一个用例的文本由于某种原因不允许被大量修改，但又存在一些新的扩展场景和条件步骤出现需要修改原始的用例文本，如何在不修改原始用例文本的基础上扩展这些场景呢？应用扩展关系。 扩展关系的思路：创建一个扩展用例，在该用例中描述从什么地方、在什么情况下扩展某个基用例的行为。 其实，当原始用例文本允许修改的情况下，通常只需更新“扩展”部分，无需创建复杂的用例关系。 §7c3.2 建立用例关系 §7c3.3 泛化建模 本次迭代要处理信用卡和支票支付的场景 用例1:Process Sale …… 扩展： 7b.用信用卡支付： 1.顾客输入信用卡账号信息 2.系统向外部的支付授权服务系统发出授权支付请求和批准支付的请求 2a.系统侦测到与外部系统交互失败： 1.系统通知收银员有错误发生 2.收银员要求顾客改变支付方式 3.系统收到支付批准并通知收银员 3a.系统收到支付拒绝的通知 1.系统通知收银员系统拒绝支付 2.收银员要求顾客改变支付方式 4.系统记录信用卡的支付情况，包括支付授权 5.系统初始信用卡签名的输入方式 6.收银员要求顾客为信用卡支付签名。顾客签名。 §7c3.3 泛化建模 出现了一些新的领域概念： CreditPaymentRequest CreditApprovalReply §7c3.3 泛化建模 §7c3.3 泛化建模 §7c3.3 泛化建模 §7c3.4 精化领域模型 将过去学习的OO概念应用到POS领域模型： 关联类、限定关联 聚集与组合 派生 应用包组织模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 包的划分原则： 同一个主题域－由概念或目的紧密相关 在同一个类层次中 参与同一个用例 紧密相关 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.4 精化领域模型 §7c3.5 增加新的SSD和契约 本次迭代处理顾客支付问题 信用卡支付 支票支付 有一个共同的SSD开始 §7c3.5 增加新的SSD和契约 §7c3.5 增加新的SSD和契约 接下来的工作： 描述系统操作makeCreditPayment的操作契约 描述系统操作makeCheckPayment的操作契约 发现一些可能的新的领域概念类 利用GRASP模式将操作契约中完成状态的职责分配给不同的概念类（用交互图表示） 从领域类转换到设计类（DCD表达） 从交互图中寻找设计类的方法 测试用例、代码实现 §7c3.5 增加新的SSD和契约 §7c3.6 在状态图中为行为建模 状态图可以用来描述： 一个类（概念类或者软件类） 用例（描述外部系统事件的合法顺序） 系统（因为一个系统也可以看成一个类） 用例状态图：表达系统事件顺序 在设计模型中，用例的状态是由谁维持的？ §7c3.6 在状态图中为行为建模 如果一个对象对于接收到的所有相同事件的处理方式是一样的，则该对象是状态无关的；如果采取不同的方式处理该事件，则该对象是状