关键字：UML视图
摘要 模式在系统组合（合成）期间对养成重用可重复设计和体系结构配置的习惯很重要。本论文研究关于模式的知识，它也可用于系统分析检验系统模型的完整性。为了支持自动分析过程，该工作引入一个视图集成框架。自从每个视图（例如，框图）增加一个额外针对模型的软件系统观点，来自一个视图的信息可能用于验证其它视图的完整性。这种形式的集成要求对视图表明什么以及它们可以共享（或约束）什么信息有更深的理解。因此关于模式在结构和行为上的知识，也是一个用于视图集成自动化的有价值的来源。
介绍
为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：
1) 对实际问题充分建模
2) 解决模型问题并
3) 在现实世界中解释模型方案
这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。
已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。
本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。
视图和模型
在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注意或兴趣个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：
介绍
为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：
1) 对实际问题充分建模
2) 解决模型问题并
3) 在现实世界中解释模型方案
这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。
已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。
本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。
视图和模型
在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注意或兴趣个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
