如何在TOGAF全元模型中表示、应用和数据库？

Question

我希望以一种与内容元模型中定义的实体之间的关系一致的方式捕获应用程序和数据库之间的连接。

• 我们正在使用完整的元模型参34-8，我的问题涉及到数据扩展和基础设施整合扩展。
• 这在建模工具中得到(对以后的影响分析有用)
• 这个观点是为需要了解哪些应用程序和将要更新的数据库的技术受众而设计的。在这种环境中，在大多数情况下，数据库应用程序是一对一的。

下面描述了我想显示的关系

有什么好的方法来描述这种与元模型相一致的关系，并帮助观众理解他们需要改变的东西？哪些因素会改变描述它的最佳方式。

Answer 1

尽管上面的答案是深思熟虑的，但它们没有回答一个非常简单的问题，这就是TOGAF元模型中用来表示数据库的实体是什么。

答案非常简单，如果它是一个物理数据库(即您正在创建一个物理体系结构模型)，那么您将使用物理数据组件；如果它是一个逻辑数据库(即您正在创建一个逻辑体系结构模型)，那么您将使用一个逻辑数据组件。

Answer 2

TOGAF没有神奇的模板- TOGAF是一种描述现有体系结构、未来体系结构状态和从一个到另一个的路线图的方法。这个问题对于TOGAF认证的个人来说是非常有意义的，就像“如何在PRINCE2中表示应用和数据库”一样，对于一个PRINCE2合格的个人来说也是如此。

使用最适合听众的表示形式。TOGAF主张对体系结构有许多“观点”，针对不同的涉众群体、关注事项和不同的细节级别。决定您需要创建哪些观点，并确保每个视点都有一个明确的有针对性的图表，告诉您的涉众他们需要知道什么。

在上面的示例中，您可能希望包含或隐藏特定受众的技术细节，但这两个图表都适合于一个级别的细节，因此只要信息是可访问的和可理解的，就不要强调框的颜色或形状。

在问题更改后进行编辑

当我在认证考试前参加TOGAF课程时，培训师解释说，TOGAF材料提供的模型是所有参与者之间的妥协(看看这本书9.1版xxv - xxx页中的成员列表，想象一下让他们都同意任何事情- CA、CSC、HP、IBM.)因此，这些都是无用的。

他提供了他的公司生产的担保品的真实例子(名字经过修改，但以其他方式完整)，但有一项理解，即作为学生，我们不能复印，而是可以查看。这是一种解放的体验，因为它使我们摆脱了TOGAF本身提供的极其有限的“模型”，并向我们展示了如何使用比Visio更复杂的方法来创建高质量的材料。

所以，我要说的是--看看所给出的例子，但不要虔诚地使用它们，因为它们太妥协了，不可能成为更多的指南。我第一次看到TRM (第43章)，因为我通过了考试(这应该是一条线索)，它甚至比我记忆中的更无用。“企业体系结构日刊”(提供给成员)的后面一期通常包含示例，这些示例通常比Open正式提供的任何内容都要好。

根据需要对涉众进行文档和解释的内容，构建自己的体系结构。一个技术用户会期望一个完整的数据模型，一个技术业务用户可能想要一个概念性的数据模型，C级的管理人员会对一个表示数据库的框感到满意。用颜色表示需要注意的区域。

Answer 3

基于您希望捕获应用程序和数据库之间的连接的描述，我同意数据扩展(在第34.4.4章中定义)和基础设施合并扩展(在第34.4.5章中定义)都是合适的。具体来说，数据扩展的两个目的是捕获“创建实现逻辑数据组件并类似于数据库、注册中心、存储库、架构和其他分割数据技术的物理数据组件”和“创建体系结构的数据生命周期、数据安全性和数据迁移图，以更详细地显示数据关注点”。基础设施整合扩展的一些目的是捕捉“创建逻辑和物理应用程序组件，将应用程序的能力抽象出现有的实际应用程序”，以及“从现有的实际技术产品中创建逻辑和物理应用程序组件以抽象产品类型”。

如果要完全创建这两个扩展，则需要创建以下关系图：

• 数据安全图
• 数据迁移图
• 数据生命周期图
• 过程/应用实现图
• 软件工程图
• 应用迁移图
• 软件分布图
• 处理图
• 网络计算/硬件图
• 通信工程图

所有这些图表都是在建筑文物(第35章)中定义的。

根据您问题中的绘图，“软件通讯图”和“网络计算/硬件图”最接近于此。软件分布图显示了跨技术和地理位置的应用程序结构和物理分布。网络计算/硬件图显示应用程序组件之间的逻辑连接。由于您还提到了对应用程序和数据库的更新(我将其解释为对新版本的部署或对新供应商的技术刷新)，“应用程序迁移图”似乎是合适的，它还展示了您打算如何在所有环境中从组件的基线版本转移到目标版本。应当指出，所有这些都属于基础设施合并延期。

查看这些图的完整定义(并浏览其他图的定义)，TOGAF从不指定特定的建模符号或技术。每个TOGAF扩展都描述了体系结构的一个特定方面，这是一组模型，帮助您捕获与体系结构的那个方面相关的信息，并为满足特定目的的图表提供特定的名称。

如果您必须遵守TOGAF标准，最好的做法是选择您的扩展(看起来您有)，确保其目的与您想要交流的内容保持一致，查看支持该扩展的列表图，然后查看这些图的意图和用途。然后，与将使用文档的涉众(不仅仅是图表--可能有文本、表和其他信息)一起工作。

我的另一个建议来自信息技术IEEE标准.系统设计。软件设计说明(1016)：与其他设计语言相比，使用标准化的设计语言更可取。如果您正在使用一种标准化的设计语言(并正确地使用它)，那么您就不需要向读者解释您的符号意味着什么。如果您没有以非标准的方式使用标准化设计语言或使用标准化设计语言中的符号，您需要额外的内容向读者解释如何解释您的图表和设计符号，这将导致更详细的架构或设计描述。

简而言之:首先，咨询你的利益相关者。找出他们最容易理解和使用的图表和模型。可能已经制定了组织标准或惯例。如果没有标准、约定、偏好或共识，请寻找一个标准化的表示法，该符号可用于传递图所要传达的信息。如果没有标准化的符号，那么您可以选择使用您自己设计的符号，只要您也向读者说明如何理解该表示法。