4 + 1架构视图模型与UML之间的映射

我对4 + 1架构视图模型如何映射到UML感到有些困惑。

维基百科提供了以下映射：

• 逻辑视图：类图，通讯图，顺序图。
• 开发视图：组件图，包装图
• 流程视图：活动图
• 物理视图：部署图
• 方案：用例图

纸张UML时序图的构建在对象生命周期概念作用提供了以下映射：

• 逻辑视图（类图（CD），对象图（OD），序列图（SD），协作图（COD），状态图图（SCD），活动图（AD））
• 开发视图（包装图，组件图），
• 流程视图（用例图，CD，OD，SD，COD，SCD，AD），
• 物理视图（部署图），以及
• 结合了上述四个方面的用例视图（用例图，OD，SD，COD，SCD，AD）。

网页UML 4 + 1 View Materials提供了以下映射：

最后，白皮书《将4 + 1视图架构与UML 2结合使用》给出了另一个映射：

• 逻辑视图类图，对象图，状态图和组合结构
• 过程视图顺序图，通讯图，活动图，时序图，交互概述图
• 开发视图组件图
• 物理视图部署图
• 用例视图用例图，活动图

我相信进一步的搜索也会揭示其他映射。

尽管各种人通常有不同的看法，但我不明白为什么会出现这种情况。特别地，每个UML图都从特定方面描述系统。那么，例如，为什么一位作者认为“顺序图”描述了系统的“逻辑视图”，而另一位作者却认为它描述了“过程视图”呢？

您能帮我澄清一下混乱吗？

尽管我总体上同意Bart van Ingen Schenau的回答，但我认为有几点需要进一步阐述。

4 + 1视图模型的优势在于，它可以将涉众映射到他们所需的信息类型，而无需使用特定的建模符号。重点是确保所有小组都有信息以了解系统并继续工作。

4 + 1视图软件体系结构模型中描述了这篇Philippe Kruchten的纸建筑蓝图- “4 + 1”软件Architeture的视图模型最初发表在IEEE软件（1995年11月）。该出版物没有特别提及UML。实际上，本文将Booch表示法用于逻辑视图，将Booch表示法扩展用于过程视图和开发视图，并呼吁使用开发物理视图的“几种形式”，并为场景提供新的表示法。

不要尝试将每个视图映射到特定类型的图，而要考虑每个视图的目标受众是谁以及他们需要什么信息。知道这一点后，请查看各种类型的模型以及哪些模型可以提供所需的信息。

逻辑视图旨在解决最终用户对确保系统捕获其所有所需功能的担忧。在面向对象的系统中，这通常是在类级别上。在复杂的系统中，您可能需要一个包视图并将这些包分解为多个类图。在其他范例中，您可能对表示模块及其提供的功能感兴趣。最终结果应该是所需功能到提供该功能的组件的映射。

流程视图旨在供人们设计整个系统，然后将子系统或系统集成到系统的系统中。该视图显示了系统具有的任务和过程，与外界和/或系统内组件之间的接口，已发送和已接收的消息以及如何解决性能，可用性，容错和完整性。

开发视图主要适用于将要构建模块和子系统的开发人员。它应该显示模块之间的依赖关系和关系，模块的组织方式，重用性和可移植性。

物理视图主要供需要了解软件的物理位置，节点之间的物理连接，部署和安装以及可伸缩性的系统设计人员和管理员使用。

最后，这些方案有助于捕获需求，以便所有利益相关者都了解如何使用该系统。

一旦了解了每个视图应提供的内容，就可以选择要使用的建模符号以及所需的详细程度。Bart的最后一段特别正确-您可以通过关注特定的设计元素或将各种类型的图组合成一组来在UML模型中显示各种级别的细节。另外，您可能要考虑超越UML到其他建模符号，以更好地描述您的系统体系结构-SysML，实体关系建模或IDEF。

您无法在4 + 1体系结构模型的视图与各种UML图之间找到一对一的映射，这是因为这种映射不存在。

所有这些作者试图通过其“映射”来说明的是，对于每个视图，都有一组不同的UML图，这些图对于传达您想要在该视图中告诉的信息很有用。

此外，通过强调图中的不同元素，可以以不同的方式使用某些UML图，这对于多个视图很有用。但是，即使可以在多个视图中使用一种UML图类型，您也将为每个视图绘制一个不同的图（或一组图）。

尽管我同意托马斯·欧文斯（Thomas Owens）的回答方法来满足最终用户的需求，但未能提及的一件事是，克鲁克滕（Kruchten）对“ 4 + 1视图模型体系结构”的原始定义没有做出任何解释的原因对UML的特定引用是因为该文章是在1995年编写的（正如回答所言），但是直到1997年才真正采用UML作为标准。

文章中Booch表示法的不断使用表明将每个模型视图与特定的UML图相关联是适当的，因为Grady Booch是参与UML开发的人之一。

因此，许多不同的作者认为不同的UML图适用于每个视图，因为可以将多个UML图视为Booch表示法的某种“抽象”，因为4 + 1模型的原始定义依赖于Booch表示法。代表每个视图。

希望这可以为其他研究者带来更多帮助。

您是否仍使用1995年购回的VCR？当软件还处于初期阶段时，适用4 + 1。但是即使那样，也没有人使用超过2或3个“视图”。在过去的20年中，软件工程发生了变化。如今，范围/上下文，概念，逻辑和物理以及...都是不同的。必须集成许多COTS解决方案，依此类推。今天，我们正在讨论景观图，服务实现以及许多其他视图和观点。最好的查看方法是通过一个简单的分类法框架，如Zachman：6个视图和6个观点。让那作为您的起点。6个视图是：上下文概念或业务逻辑或系统物理或技术交付或使企业正常运转的工件

6个观点是：数据，什么功能，如何建立网络，人们在哪里，谁在何时，何时成为动机或为什么

让我们来看一个例子。如果我们仅对数据感兴趣，那么我们将从合并范围视图开始，然后说“我们的合并范围是CRM”。在数据观点的概念视图中，我们将提出一些CRM语义模型。该模型将是概念性的业务信息概念，而不是数据对象。接下来，在逻辑视图中，我们将从CRM的概念模型中生成逻辑数据模型。我们可能会使用ER方法来生成逻辑数据模型。然后，在物理视图中，我们将生成物理数据模型。在这里，我们将为我们选择的数据库平台，索引等定义具体的数据类型。最后，在交付视图中，我们将使用DDL脚本，而在正常运行的企业视图中，我们将在某个数据库服务器上部署一个二进制文件。并映射到DBM供应商的内部数据结构中。我们针对每个观点或专栏重复此操作。另外，如果有多个利益相关者，我们将为每个视点/视图组合创建多个模型。现在已经有了该分类法，您可以定义自己的观点和观点，并将其与该分类法保持一致。例如，对于企业级计划，以下观点都很重要：参与者合作应用程序行为应用程序合作应用程序结构应用程序使用业务功能业务流程业务流程合作实施和部署信息结构基础结构基础设施使用情况景观概述组织服务实现的分层等 现在已经有了该分类法，您可以定义自己的观点和观点，并将其与该分类法保持一致。例如，对于企业级计划，以下观点都是非常重要的：参与者合作应用程序行为应用程序合作应用程序结构应用程序使用业务功能业务流程业务流程合作实施和部署信息结构基础结构基础设施使用情况景观概述组织服务实现的分层等 现在已经有了该分类法，您可以定义自己的观点和观点，并将其与该分类法保持一致。例如，对于企业级计划，以下观点都是非常重要的：参与者合作应用程序行为应用程序合作应用程序结构应用程序使用业务功能业务流程业务流程合作实施和部署信息结构基础结构基础设施使用情况景观概述组织服务实现的分层等

克鲁琴的4 + 1可能无法满足所有这些需求