使用模式集成UML视图

2019-11-17 04:43:46

字体：大中小

来源：转载

供稿：网友

介绍为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：

1) 对实际问题充分建模

2) 解决模型问题并

3) 在现实世界中解释模型方案

这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。

已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。

本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。

视图和模型在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注重或爱好个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：

抽象并简化模型

使得不同的利益关联者协调工作

为不同解释进行补充（不同观众/利益相关者）

提取关于特定关联的相关信息

因此，将会用到什么类型的视图以及什么时候用到它们是强烈依靠于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。

要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致――后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。

视图不匹配和冗余既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]

然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题――冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。

例如，假如我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着假如体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不答应的。假如后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依靠要求与上述的体系结构约束一致。我们将在后面说明一个例子。

UML视图描述 vs 集成启用视图集成来确定和调和视图要求两个层次的集成――符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。

统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依靠关系很少被捕捉。假如后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依靠关系，例如类和对象）。

图 1 也表明问题的另一个方面――那就是扩展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更高级的模式例如分层的体系结构模式【[1]】或代理设计模式？在UML中，我们需要再次区分仅仅表述模式和完整集成它们。使用模式集成UML视图（图一）

图 1 UML中表示法 vs. 集成视图集成框架视图集成的主要的障碍是缺乏完好定义的（工程的）模型基础。视图经常使用迥然不同的表示信息方法，而这使得确定它们在哪里和怎样出现重叠非常困难。这样，组合和比较视图的任务经常是手工的而且潜伏着错误的。集成框架的目标是要补偿鉴别和解决体系结构不匹配自动化辅助手段的不足。

如前面简短的叙述，这样做的时候，我们的框架需要处理什么信息和怎样进行交换。我们在那里写到什么信息可被交换以及它怎么能交换的判定需求。在我们的视图集成框架中，我们提到映射和变换这两个活动。我们也说只有在这些活动定义之后，才能够尝试鉴别不一致性。后者我们称之为分化（参看图 2 ）。

图 2 在高层次式样上描写我们的视图集成框架。在那里，系统模型用于表达软件系统的知识基础。软件开发者使用视图增加新的数据到系统模型并且复审现有数据（视图综合）。对于UML，系统模型可能被看作通过UML设计工具（例如Rational Rose）完成的UML模型和视图综合。

系统模型和视图综合两者交互影响就是视图分析。一旦加入新的信息，它就可以针对系统模型进行验证以保证其概念完整性。图 2 表示视图分析可以怎样进一步细分为其上述三个主要活动：使用模式集成UML视图（图二）

图 2 视图集成活动
映射：通过使用命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种关联/模式形式（例如公共接口）来确定相关的信息片。

变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共享（或在系统模型自身中表述）。例如，我们可以使用抽象技术泛化一个具体的框图，我们可使用视图转化在不同类型的视图之间交换信息，或者我们可以按不同的风格重新排列模型元素（或片段）产生新的视角（例如拼结和分割）。

分化：具体研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则和约束的形式讨论。此外，不匹配解决规则可与将要怎样解决它们可选方法的不匹配标识规则相关联。分化是强依靠于变换和映射的。

然而，必须注明的是，那些活动不是相互正交的。显然地，我们只有在知道模型元素的正确映射时才能做出有用的变换。这种依靠关系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视图可以用于澄清其它视图中的二义性。

此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。介绍为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：

1) 对实际问题充分建模

2) 解决模型问题并

3) 在现实世界中解释模型方案

这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。

已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。

本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。

视图和模型在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注重或爱好个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：

抽象并简化模型

使得不同的利益关联者协调工作

为不同解释进行补充（不同观众/利益相关者）

提取关于特定关联的相关信息

因此，将会用到什么类型的视图以及什么时候用到它们是强烈依靠于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。

要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致――后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。

视图不匹配和冗余既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]

然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题――冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。

例如，假如我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着假如体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不答应的。假如后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依靠要求与上述的体系结构约束一致。我们将在后面说明一个例子。

UML视图描述 vs 集成启用视图集成来确定和调和视图要求两个层次的集成――符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。

统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依靠关系很少被捕捉。假如后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依靠关系，例如类和对象）。

图 1 也表明问题的另一个方面――那就是扩展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更高级的模式例如分层的体系结构模式【[1]】或代理设计模式？在UML中，我们需要再次区分仅仅表述模式和完整集成它们。使用模式集成UML视图（图一）

图 1 UML中表示法 vs. 集成
视图集成框架视图集成的主要的障碍是缺乏完好定义的（工程的）模型基础。视图经常使用迥然不同的表示信息方法，而这使得确定它们在哪里和怎样出现重叠非常困难。这样，组合和比较视图的任务经常是手工的而且潜伏着错误的。集成框架的目标是要补偿鉴别和解决体系结构不匹配自动化辅助手段的不足。

如前面简短的叙述，这样做的时候，我们的框架需要处理什么信息和怎样进行交换。我们在那里写到什么信息可被交换以及它怎么能交换的判定需求。在我们的视图集成框架中，我们提到映射和变换这两个活动。我们也说只有在这些活动定义之后，才能够尝试鉴别不一致性。后者我们称之为分化（参看图 2 ）。

图 2 在高层次式样上描写我们的视图集成框架。在那里，系统模型用于表达软件系统的知识基础。软件开发者使用视图增加新的数据到系统模型并且复审现有数据（视图综合）。对于UML，系统模型可能被看作通过UML设计工具（例如Rational Rose）完成的UML模型和视图综合。

系统模型和视图综合两者交互影响就是视图分析。一旦加入新的信息，它就可以针对系统模型进行验证以保证其概念完整性。图 2 表示视图分析可以怎样进一步细分为其上述三个主要活动：使用模式集成UML视图（图二）

图 2 视图集成活动映射：通过使用命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种关联/模式形式（例如公共接口）来确定相关的信息片。

变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共享（或在系统模型自身中表述）。例如，我们可以使用抽象技术泛化一个具体的框图，我们可使用视图转化在不同类型的视图之间交换信息，或者我们可以按不同的风格重新排列模型元素（或片段）产生新的视角（例如拼结和分割）。

分化：具体研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则和约束的形式讨论。此外，不匹配解决规则可与将要怎样解决它们可选方法的不匹配标识规则相关联。分化是强依靠于变换和映射的。

然而，必须注明的是，那些活动不是相互正交的。显然地，我们只有在知道模型元素的正确映射时才能做出有用的变换。这种依靠关系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视图可以用于澄清其它视图中的二义性。

此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。 QQRead.com 推出数据恢复指南教程数据恢复指南教程数据恢复故障解析常用数据恢复方案硬盘数据恢复教程数据保护方法数据恢复软件专业数据恢复服务指南介绍为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：

1) 对实际问题充分建模

2) 解决模型问题并

3) 在现实世界中解释模型方案

这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。

已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。

本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。

视图和模型在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注重或爱好个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：

抽象并简化模型

使得不同的利益关联者协调工作

为不同解释进行补充（不同观众/利益相关者）

提取关于特定关联的相关信息

因此，将会用到什么类型的视图以及什么时候用到它们是强烈依靠于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。

要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致――后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。

视图不匹配和冗余
既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]

然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题――冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。

例如，假如我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着假如体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不答应的。假如后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依靠要求与上述的体系结构约束一致。我们将在后面说明一个例子。

UML视图描述 vs 集成启用视图集成来确定和调和视图要求两个层次的集成――符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。

统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依靠关系很少被捕捉。假如后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依靠关系，例如类和对象）。

图 1 也表明问题的另一个方面――那就是扩展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更高级的模式例如分层的体系结构模式【[1]】或代理设计模式？在UML中，我们需要再次区分仅仅表述模式和完整集成它们。使用模式集成UML视图（图一）

图 2 视图集成活动映射：通过使用命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种关联/模式形式（例如公共接口）来确定相关的信息片。

变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共享（或在系统模型自身中表述）。例如，我们可以使用抽象技术泛化一个具体的框图，我们可使用视图转化在不同类型的视图之间交换信息，或者我们可以按不同的风格重新排列模型元素（或片段）产生新的视角（例如拼结和分割）。

分化：具体研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则和约束的形式讨论。此外，不匹配解决规则可与将要怎样解决它们可选方法的不匹配标识规则相关联。分化是强依靠于变换和映射的。

然而，必须注明的是，那些活动不是相互正交的。显然地，我们只有在知道模型元素的正确映射时才能做出有用的变换。这种依靠关系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视图可以用于澄清其它视图中的二义性。

此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。 QQRead.com 推出数据恢复指南教程数据恢复指南教程数据恢复故障解析常用数据恢复方案硬盘数据恢复教程数据保护方法数据恢复软件专业数据恢复服务指南介绍为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(UML)。然而，通常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不仅仅是大多数通用模型所能提供的内容。体系构造是关于：

1) 对实际问题充分建模

2) 解决模型问题并

3) 在现实世界中解释模型方案

这样做的主要重点被置于体系结构的视图（例如框图）内和之间不匹配的鉴别与调和上。我们经常发现这方面的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重点的。我们构造体系不仅仅是因为我们想建立（创作），而且因为我们要理解。这样，体系构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。

已完全成为事实上OO软件开发标准的UML的出现，在这个问题上也没有任何例外。本工作阐述在UML视图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更自动化的方式应用于识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动――映射（Mapping）、变换(Transformation)和分化(Differentiation)。

本论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样有助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模式用作系统分析，而不是将模式用作构建材料作为系统成分。

视图和模型
在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的集合或者视图可以看作模型的一个方面（或视点）。IEEE标准（草案）1471[AT&T1993]将视图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系”。对于利益关联者，我们定义为分享系统注重或爱好个体或组（例如，开发者，用户，消费者等等）。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关联信息。在UML中，视图本质上是图形的，且往往通过框图来实现。视图（例如类或序列图）服务于下列意图：

抽象并简化模型

使得不同的利益关联者协调工作

为不同解释进行补充（不同观众/利益相关者）

提取关于特定关联的相关信息

因此，将会用到什么类型的视图以及什么时候用到它们是强烈依靠于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。

要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致――后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。

视图不匹配和冗余既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]

然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题――冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。

例如，假如我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着假如体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不答应的。假如后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依靠要求与上述的体系结构约束一致。我们将在后面说明一个例子。

UML视图描述 vs 集成启用视图集成来确定和调和视图要求两个层次的集成――符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。

统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依靠关系很少被捕捉。假如后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依靠关系，例如类和对象）。

图 1 也表明问题的另一个方面――那就是扩展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更高级的模式例如分层的体系结构模式【[1]】或代理设计模式？在UML中，我们需要再次区分仅仅表述模式和完整集成它们。使用模式集成UML视图（图一）