第四部分 细化迭代2—更多模式(23-26章).ppt

PRJ270: Essentials of Rational Unified Process Module 1 Best Practices of Software Engineering 第四部分 细化迭代2 —— 更多模式 主要内容 第 23 章 迭代2：更多模式 第 24 章 快速地更新分析 第 25 章 GRASP 更多具有职责的对象 第 26 章 应用GoF设计模式 第 23 章 迭代2—更多模式 简介 基本对象设计 使用模式来创建稳固的设计 应用UML使模型可视化 23.1 从迭代1到迭代2 在迭代1 所有软件都已经被充分地测试 客户定期地参与对已完成部分的评估 已经对系统（这里的系统也包括所有子系统）进行了完整的集成和固化，使其成为基线化的内部版本 23.3 迭代2 需求和重点： 对象设计和模式 迭代2着重于使用职责和GRASP进行对象设 计，并且应用一些GoF设计模式。 NextGen POS 支持第三方外部服务的变化，例如，能够与不同的税金计算器相连接 复杂的定价规则，可更换的业务规则 需要进行设计，使得在销售总额变化时刷新GUI窗口 定价问题： 根据一系列定价规则计算价格 Monopoly Monopoly应用在第二次迭代中所增加的附加需求包括： 实现玩Monopoly游戏用例的基本、关键场景：游戏者在棋盘四周的方格中移动。像以前一样，游戏以模拟方式运行，除了游戏者数量外，不需要任何用户输入。但是，在迭代2中要应用一些特殊方格规则。下列各点对其进行了描述…… 迭代2 需求 在游戏的开始，每个游戏者都会收到1500美元。游戏不限制钱的总额。 当游戏者落在Go方格时，这个游戏者将收到200美元。 当游戏者落到Go-To-Jail方格时，这个游戏者要被移到Jail方格上。 但是与完整规则不同，对释放的处理很简单。在下一个回合时，游戏者就可以出来滚动骰子，根据总点数移动。 当游戏者落到Income-Tax方格时，这个游戏者要支付至少200美元或价值其资产10％的税金。 迭代2 需求 由于这些需求，我们要在迭代2中对迭代1中的用例进行修订，但是实现了更多场景 对面向分析的对象的修改在此轮迭代中也是需要的 Use-Cases SSDs Domain Model 第 24 章 快速地更新分析 24.1 案例研究：NextGen POS 用例： 本次迭代中不需要精化该用例 建议本次迭代中举行为期一到两日的简短的需求讨论会。 注意：需求分析将基于对早期开发的反馈进行改进。 案例研究：NextGen POS 应该更新SSD，使其至少能够反应一些系统间的协作 案例研究：NextGen POS 领域模型 新的需求对领域模型新概念、关联和属性方面产生影响？ 如果没有涉及新的领域概念，可以跳过对领域模型的精化，快速投入到设计工作中。 使用UP的过程成熟标志是： 知道何时创建制品能够带来显著价值，或者是当遇到呆板的“完成作业”式的步骤时能够较好地略过。 另一方面，一般开发人员建模不是太多，而是太少。 案例研究：NextGen POS 系统操作契约 没有考虑新的系统操作，因此也不用考虑新的操作契约。 24.2 案例研究：Monopoly 用例，等等 假设大家都知道游戏规则，用例被省略了。 不需要更新SSD 没有书面的操作契约 案例研究：Monopoly 领域模型 Square、GoSquare、IncomeTaxSquare和GoToJailSquare等概念是类似的，类似问题可以考虑组织为泛化－特化类层次结构 泛化（generalization） 准则： 当有下列情况时，创建超类的概念子类： 子类具有我们感兴趣的额外属性。 子类具有我们感兴趣的额外关联。 对子类概念的影响、处理、反应和操作与超类或其他子类有显著的差异。 将超类声明为抽象类 在子类上附以超类名称 准则：将超类声明为抽象类 准则：在子类上附以超类名称 没有任何特殊之处的RegularSquare也是一个独特的概念。 现在涉及到了金钱，Player具有cash属性 第 25 章 GRASP：更多具有职责的对象 目标 我们学习了什么? 信息专家 创建者 高内聚 低耦合 控制器 我们还需要学习? 多态（Polymorphism） 间接性（Indirection） 纯虚构（Pure Fabrication） 防止变异（Protected Variation） 25.1 多态（Polymorphism） 问题： 如何处理基于类型的选择? “If-then-else”; “select-case”？ 很难方便地扩展有新变化的程序 如何创建可插拔的软件构件? 客户－服务器关系中的可视化构件，如何才能够替换服务器构件，而不对客户端产生影响呢？ 解决方案 当相关选择