集成 Rational Software Architect 和 Rational Data Architect

核心提示： 图 4. 自下而上集成场景：数据建模到应用程序建模查看原图（大图）当同时满足以下条件时，建议考虑使用自下而上场景：域内的 LDM 可用，集成 Rational Software Architect 和 Rational Data Architect(7)， 具有一些现有数据源（关系数据库或其他数

图 4. 自下而上集成场景：数据建模到应用程序建模

查看原图（大图）

当同时满足以下条件时，建议考虑使用自下而上场景：

域内的 LDM 可用。

具有一些现有数据源（关系数据库或其他数据源）。

企业希望从应用程序中解耦数据并实现企业级数据管理。

企业希望创建可跨整个企业重用的信息。

涉及多个计划。例如，业务应用程序重写并需要绑定到数据仓库。

应用程序过于复杂，并经常变化。

应用程序以数据为中心。

项目需要考虑已有的数据模型（至少需要考虑一部分）。如果有遗留的应用程序、第三方应用程序或需要实现基于标准的界面，就需要考虑这一点。

最后，实现自下而上方法也需付出一定代价：

在从 LDM 转换到类模型时，有些语义可能会丢失，因为 LDM 的数据语义比类模型更加丰富（例如主键）。

由于 LDM 往往比类模型更完整，如果未经恰当交流就将 LDM 推入类模型，那么应用程序建模师就会面对大量的信息。如果应用程序建模师不理解 LDM，那么他们最后可能不得不从头开始重新定义 LDM 中已有的实体或属性。因此，因此，数据建模师和应用程序建模师之间需要进行恰当的培训和交流。理想情况下，应用程序建模师经过培训后应该能理解和利用逻辑数据模型。

中间会合

前面的小节描述了自上而下和自下而上场景，它们主要侧重于全新的开发。然而，软件开发的永恒主题就是变化。应用程序建模和数据建模并不是件一劳永逸的事。为了避免过时，应用程序建模和数据建模需要反复进行，并迅速转化为业务价值。因此，应用程序建模和数据建模工具应该支持模型更新功能。例如，可以对类模型中的修改进行更新，并自动（适用于简单修改）或手动（涉及复杂过程）反映到 LDM 中，反之，从 LDM 到类模型这个过程也一样。