建立了这个框架后，架构师通过几次迭代对解决方案加以发展。每次迭代都合并额外的功能 — 发票、待交定单、亲自订购、电话订购等等。在每种情况下，架构师都更新适当的抽象层次，然后将这些更新改进到物理实现层。
重访抽象层次核心原则
让我们对照核心抽象层次原则来测试我们的示例。
| • |
这些层次的数量和范围是定义完善的：我们有四个不同的层次：公司黑盒子、系统黑盒子、系统内的逻辑设计以及物理实现。 |
| • |
每个层次内的多个视图：在这个简单示例中，我们在每个层次上展示了一个动态视图和静态视图。 |
| • |
必须保持层次间的一致性：如果对域模型作出了更改，则更改也一定会影响到较低层次。举例来说，如果零售商决定为其产品提供维护合同，分析师就会将MaintenanceContract 添加到域模型，并将其改进为其物理表现形式。对于维护大型系统来说，同步所有层次是很重要的。因为提交了增强请求，所以分析师执行对相应细节层次的影响评估。一些增强请求影响域层次（并且因此影响所有后续层次）。其他请求只影响物理层次。 |
扩展层次以支持企业解决方案
既然我们已经展示了带有四个抽象层次的简单示例，现在就让我们扩展这个方法来支持 IT 企业的解决方案。图 9 展示了一个 Rational 统一过程 (Rational Unified Process，RUP) 配置，它将项目产品组织到定义完善的抽象层次中。
表中的层次描述如下。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
