L193测试驱动开发和重构和其他内容简介研讨.pptVIP

4. 从迭代1到迭代2的转移过程中有许多事情 要做。为突出重点，不详细讨论。这些事情 包括： *迭代计划会议 *使用UML工具从第一次迭代的源码中导出 图形，并挂在墙上，作为沟通和新一轮迭代 的起点。 *对UI的分析和设计，以及对数据库的建模 和实现也在进行中。 *举行了新一轮需求讨论会。 5. 迭代2的需求和重点 在迭代2中我们将忽略需求分析和领域分析, 把重点放在对象设计和模式应用上。 在POS应用的第二次迭代中，关注处理销 售用例场景的如下需求： *支持第三方外部服务的变化，如处理支付 和计算税金等。 *支持复杂的定价规则。 *支持窗口刷新。 这些需求在初始阶段就已在用例和补充规格 说明中提出了。 第24章 快速地更新分析 目标 快速地突出显示一些分析制品的变更。 1. 用例需要更新吗？ 就POS应用的案例来说，第二次迭代仍然 是基于原有用例，因为在第一次迭代中我们 只处理了主成功场景，且只处理现金支付。 在第二次迭代中要处理税金计算和计价规则 问题。原有用例已反映这些需求，不必更新。 2. SSD需要更新吗? 本次迭代要处理对具有不同接口的第三方 外部系统（如税金计算器）的支持，POS应 用系统将与这些外部系统进行通信。 增加边界外的参与者，系统事件会发生变 化，一些系统操作的要求也会变化。所以， SSD必须更新。 下图示出了对原有SSD的更新： 1）参与者的更新 2）系统操作流的更新 图中包括在下一次迭代要处理的信用卡支付 需求。 描述信用卡支付的SSD场景 makeCreditPayment ( credNum , expiryDate ) reply = requestApproval ( request ) postReceivable ( receivable ) ?actor? : CreditAuthorization Service ?actor? : Accounts enterItem ( itemID , quantity ) : NextGenPOS System : Cashier endSale Process Sale Pay by Credit Scenario description , total total with taxes makeNewSale ?actor? : TaxCalculator taxLineItems = getTaxes ( sale ) postSale ( sale ) *[more items] 3. 领域模型需要更新吗? 检查是否存在一组新的需求将会对领域模 型在概念、属性、关联上产生影响。如果没 有什么变化或只有很少一点变化，不影响大 局，就跳过对领域模型的更新，直接进入设 计工作。在设计过程中还可能发现新的概念。 本例中，PriceRule是个新概念，但增加这 个新概念对原有领域模型不会构成变异，所 以不急更新它。 TaxLineItem也是个新概念,可将其增加到 领域模型中去，如下图： 4. 系统操作契约需要更新吗? 由于本次迭代不处理新的支付,只增加税金 计算、计价规则和刷新显示问题，因此没有 增加新的系统操作。不需要增加新的系统操 作契约。 但是某些系统操作契约可能需要精化，可 根据实际情况决定是否精化，因为契约本来 就只是一种选项。 我们决定立即进入设计。 本次课小结 测试驱动的开发是指在代码编写前先做好测试程序和测试用例的开发方式。特别便于代码反复修改、迭代开发的情况。 重构是通过对代码的优化进而改进设计的一种实践。重构和模式是殊途同归。 课后作业 阅读教材第21~24章,理解 预习第25章. 系统分析与设计 第21章 测试驱动开发和重构 目标 结合学习案例，介绍测试驱动开发和重构 这两种重要的开发实践 极限编程(XP)所提倡的重要测试实践是:首 先编写测试。它还提倡不断地重构代码以改 进质量，包括降低冗余、提高清晰度等。现 代工具也都支持这两种实践。 21.1 测试驱动开发(TDD) 1. 什么是测试驱动开发 测试驱动开发是迭代和敏捷XP方法提倡的优 秀实践，也适用于UP，该实践也称测试优先开 发。TDD涵盖单元测试即对构件个体进行测试， 这里着重介绍对单个类进行单元测试的应用。 在TDD的OO单元测试中，要在测试类之前编 写测试代码，并且开发者要为几乎所有的产品 代码编写单元测试代码。其基本方法是先编写 一小段测试代码，然后编写一小段产品代码保 证其通过测试，依此类