2.细化阶段

细化阶段包括

1.对核心，有风险的软件架构进行编程和测试。

2.发现并稳定需求的主体部分。

3.规避主要风险。（这里的风险包含业务价值，所以是实现那些重要的场景，而不是技术风险）

   

构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。

   

最佳实践

1.实行短时间定量，风险驱动的迭代。

2.及早开始编程。

3.对架构的核心和风险部分，进行适应性的设计，实现和测试。

4.尽早，频繁，实际的测试。

5.基于反馈进行调整。

6.迭代式的编写大部分用例，需求。

   

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

   

领域模型

2008年12月2日

15:44

   

领域模型

这一精髓的ooa步骤是从领域到重要概念或对象的分解。

领域模型是对领域内的概念类或现实世界中对象的可视化表示。

   

对领域模型应用uml类图表示法，会产生概念透视图 模型。

它可以展示：

1.领域对象或概念类。

2.概念类之间的关联。

3.概念类的属性。

   

领域模型不包括如下内容

1.软件制品。

2.职责和方法。职责是用来驱动软件对象的，领域对象是真实世界针对特定领域可视化。

   

概念类

   

oo关键思想：领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。

   

如何创建领域模型

1.界限：以当前迭代要设计的需求为界。

2.概念类：分类列表，确定名词短语，现有模型。

3.属性与类的常见错误。如果某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。

属性是对象的逻辑数据值。

当需求建议或暗示需要记住信息时，引入属性。

属性的类型应该是简单数据类型。

4.使用描述类，记录重复，描述的信息。

   

关联 是类之间的关系，表示有意义和值得关注的连接。

在领域模型中表示关联，

要基于现实世界的需要。

需要记住的关联。

   

   

   

   

系统顺序图

2008年12月3日

11:36

   

表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。？？

1.系统被视为黑盒。系统行为分析。

2.应为每个用例的主成功场景，和频繁发生的扩展绘制。

   

   

操作契约

2008年12月3日

14:37

   

组成部分：

1.操作：操作的名称和参数。

2.交叉引用：会发生此操作的用例。

3.前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。这些假设比较重要，应该告诉读者。

4.后置条件：最重要的部分，完成操作后，领域模型对象的状态。

4.1创建或删除实例。

4.2属性值的变化。

4.3形成或消除关联。

   

契约是优秀的需求分析工具，能够详细描述系统操作必须的变化，而不需描述这些操作是如何完成的。

   

后置条件，主要的作用就是，用于分析复杂的操作后，领域模型对象的变化，防止用例变得过于复杂。提倡使用十分准确的分析性语言。

   

相应的可以把契约应用于c# or java ，以断言的形式，如果配合测试驱动开发，就可以确保，操作做了正确的事情。

不过这个还是需求阶段的产物，处理的对象也是领域模型，和实际的软件模型有区别，所以上面这句话未必适用。