在迭代开发中，我们并非一次就实现所有需求。

在多个迭代里对同一用例进行增量式开发。

细化阶段：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。（包括了三到四次的细化迭代）
关键思想和最佳实践：
 实行短时间定量、风险驱动的迭代
 及早开始编程
 对架构的核心和风险部分进行适应性设计、实现和测试
 尽早、频繁、实际的测试
 基于来自测试、用户、开发者的反馈进行调整
 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代进行一次
制品：领域模型、设计模型、软件架构文档、数据模型、用例、用户界面原型。

领域模型
领域模型是对领域内的概念类或现实世界中对象的可视化表示。
应用UML表示法，领域模型被描述为一组没有定义操作的类图，反映属性和关联。（一定注意，它不是软件对象！是概念对象！）
准则：
  使用领域术语
  认真汲取领域专家所使用的核心词汇和概念
  如果某概念类不是现实世界中的数字或文本，那么她可能是概念类而不是属性
  需要描述类：1、需要有关商品或服务的描述，独立于任何商品或服务的现有实例；2、减少冗余或重复信                 息
  避免加入大量关联，添加关联是为了突出对重要关系的大致理解，而非记录对象或数据的结构
  通过关联而不是属性来表示概念类之间的关系，领域模型中属性的类型应该是数据类型（基本类型）
  对数量和单位建模
每次迭代的领域建模不超过几个小时。

系统顺序图
系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。是操作契约和对象设计的输入。
SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件。这些事件是通过用例文本总结出来的。
应为每一个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。
基本上软件系统要对三种事件进行响应：来自于参与者的外部事件，时间事件，错误和异常（通常源于外部）。
系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。

操作契约
操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化。其中的关键元素是后置条件。
为系统操作定义操作契约。系统操作在绘制SSD草图时确定。
后置条件描述了领域模型内对象状态的变化。可分为三种类型：创建或删除实例，属性值的变化，形成和消除关联。注意，它描述的是所需的变化，而不是这些变化是如何完成的。以说明性的、被动式的过去时态编写后置条件。（例如，创建了xx，而不是创建xx）

逻辑架构和UML包图
逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。
UML包图常用于描述系统的逻辑架构--层、子系统、包等。
将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。
协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。较低层包含可复用功能。
可以将应用逻辑层更准确地称为架构的领域层，即包含领域对象（注意领域模型与领域对象是不同的两个概念），处理应用逻辑的层。
领域层是软件的一部分，领域模型是概念角度分析的一部分。
从UI层发送到领域层的消息将是SSD中所描述的消息。

轻量级绘图然后编码。


http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）