4+1体系结构视图模型与UML之间的映射

Question

我对4+1体系结构视图模型如何映射到UML感到有点困惑。

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

• 逻辑视图:类图、通信图、序列图。
• 开发视图:组件图、包图
• 过程视图:活动图
• 物理视图:部署关系图
• 场景:用例图

论文UML序列图构造在对象生命周期概念中的作用给出了以下映射：

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

网页UML 4+1视图材料显示了以下映射：

最后，白皮书UML2应用4+1视图体系结构给出了另一个映射：

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

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

虽然不同的人通常有不同的观点，但我不明白为什么这里是这样的。特别是，每个UML图都从特定的方面描述了系统。例如，为什么“序列图”被一个作者认为是描述系统的“逻辑视图”，而另一个作者则认为它描述了“过程视图”？

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

Answer 1

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

4+1视图模型的优点是它将涉众映射到他们需要的信息类型，而不需要使用特定的建模符号。重点是确保所有群体都有了解该系统并继续开展工作的信息。

软件体系结构的4+1视图模型是在软件架构的"4+1“视图模型--菲利普·克鲁赫顿的论文体系结构蓝图中描述的，最初发表在IEEE (1995年11月)上。此出版物没有对UML进行特定引用。实际上，本文使用Booch符号作为逻辑视图，对过程视图和开发视图的Booch表示法进行扩展，要求使用“几种形式”来开发物理视图，并为场景使用新的表示法。

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

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

过程视图是为设计整个系统，然后将子系统或系统集成到一个系统中而设计的。此视图显示系统所具有的任务和流程、与外部世界的接口和/或系统中组件之间的接口、发送和接收的消息以及如何处理性能、可用性、容错性和完整性。

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

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

最后，这些场景有助于捕获需求，以便所有涉众都了解系统的使用方式。

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

Answer 2

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

所有这些作者试图用他们的“映射”来判断的是，对于每个视图，都有一组不同的UML图，它们可以用来传递您想要在视图中显示的信息。

此外，通过在图中强调不同的元素，可以以不同的方式使用一些UML图，这使得它们对于多个视图非常有用。但是，即使可以在多个视图中使用一种UML图类型，您也会为每个视图绘制不同的图(或一组图)。

Answer 3

你还在使用1995年买的录像机吗?4+1当时软件还处于起步阶段。但即便如此，从来没有人使用过超过2或3种“观点”。在过去的20年里，软件工程发生了变化。现在，范围/背景、概念和逻辑、物理和.都是不同的。许多COTS解决方案必须集成，等等。今天，我们讨论的是风景图、服务实现以及其他几十种观点和观点。查看它的最好方法是通过一个简单的分类法框架，比如Zachman: 6个视图和6个观点。让这成为你的出发点。6个视图是:上下文、概念或业务、逻辑或系统、物理或技术交付或工件正常工作的企业。

6个观点是:数据或什么功能、网络如何、人在哪里、时间、时间、动机和原因。

让我们来看看一个例子。如果我们只对数据感兴趣，我们将从范围视图开始，并说“我们的范围是CRM”。在数据视点的概念视图中，我们将给出CRM的语义模型。模型将是概念性的、业务信息的概念，而不是数据对象。接下来，在逻辑视图中，我们将根据CRM的概念模型生成逻辑数据模型。我们可以使用ER方法来生成逻辑数据模型。然后，在物理视图中，我们将生成物理数据模型。这里，我们将为我们选择的db平台、索引等定义具体的数据类型。最后，在交付视图中，我们将有我们的DDL脚本，而在运行中的企业视图中，我们将在一些数据库服务器上部署一个二进制文件，并映射到DBMs供应商的内部数据结构中。我们对每一个观点或列都重复这一点。此外，如果有多个涉众，我们将为每个视点/视图组合创建多个模型。现在，您已经具备了此分类法，您可以定义自己的观点和视图，并将其与此分类相关联。例如，对于企业级活动，以下观点都很重要:参与者合作应用程序行为应用程序结构应用程序使用业务流程业务流程合作实现和部署信息结构基础设施基础设施使用概述、分层组织服务实现等等。

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