迭代2：更多模式

目标：

为了更广泛地分享建立对象系统的常见步骤，讲述初始阶段的几章和讲述细化阶段中迭代1的几章中强调了广泛使用的基本分析和对象设计技术。

在本次迭代中，案例研究只强调：

因为（在迭代1中）已经就第项的基本思想进行了详细解释，所以这里对需求分析或领域建模只进行最小限度的讨论，同时对设计的解释也更为简洁。在本次迭代中当然会由其他大量的分析、设计和实现u哦东，大师为了与读者发你想如何惊醒对象设计的信息，在此对这些活动都不进行重点介绍。

从迭代1到迭代2

在迭代1结束的时候，应该已经完成下列任务：

所有软件都已经被充分地测试：单元、验收、负载、可用性等。UP中的思想使今早、实际并连续不断地验证质量和正确性，使得早期反馈能够指导开发人员对系统进行调整和改建，已发现其中的“正确道路”。
客户定期地参与对已完成部分的评估，从而使开发任意获得对调整和澄清需求的反馈。而且，客户可以今早地看见系统的进展。
已经对系统进行了完成的集成和固化，使其称为基线化的内部版本。

由于本届强调的使对OOA/D的介绍，因此为简洁期间，胜利了结束迭代1和启动迭代2的大量你活动。以下内容使被省略的大量活动中的一小部分：

迭代计划会议，用以决定下一迭代的工作内容，解决存在的问题，闭关定义主要任务。
在新迭代开始的时候，使用UML工具通过逆向工程从上次迭代的源代码中导出图形。
对UI的可用性分析和工程也正在进行中。对于许多系统的成哥容颜，这是个极为重要的技巧和活动。
数据库建模和实现也在进行中。
举行了另一个为期两天的需求讨论会，其中以详述形式编写了更多用例。在细化过程中，大越对10%的最具有风险性的需求进行了设计和实现，同时并行地深入探讨和定义了大越80%的用例，丹斯这些需求中的大部分都要到后续迭代中财会实现。

迭代2着重于使用职责和GRASP进行对象设计，并且应用了一些GoF设计模式。

NextGen POS应用中的迭代2要处理以下几个我们关注的需求：

只在处理销售用例的场景语境中，才考虑这些需求。

请注意这些滚不是新发现的需求，二十在初始阶段就识别了的需求。

由于这些需求，我们要在迭代2中对处理销售用例进行修订，但是因为实现了更多场景，所以该系统使增量式发展的。场景的方式使，在多次迭代中对统一用例的不同场景或特性进行工作，并且逐渐地扩展系统以最终实现对所有功能需求的处理。另一方面，在一次迭代内也可以完全实现一些简短的用例。

但是，不应该把一个场景分开在多次迭代中处理，一次迭代应该完成一个或多个端到端的场景。

Monopoly应用在第二次迭代中增加的福建按需求包括：

实现玩Monopoly游戏用例的基本、关键场景：游戏者在棋盘四周的方格中移动。向以前一样，游戏以模拟方式运行，除了游戏者熟练外，不需要任何用户输入。但是，在迭代2中要应用一些特殊方格规则。
在游戏的开始，每个游戏者都会收到1500美元。游戏不限hi钱的总额。
当游戏者落到Go方格时，这个游戏者将收到200美元。
当游戏者楼道Go-To-Jail方格时，这个游戏者要被移动到Jail方格上。
当游戏者落到Income-Tax方格时，这个游戏者要支付最少200美元或价值其资产10%的税金。