使用模式集成UML视图(1)

介绍

为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言(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中，我们需要再次区分仅仅表述模式和完整集成它们。

图 1 UML中表示法 vs. 集成

视图集成框架

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

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

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

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

图 2 视图集成活动

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

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

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

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

此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。产品订货系统案例

我们将使用一个简单的产品订货系统贯穿全文进行指导，该系统被分成两个主要的子系统――订单获取子系统和订单处理子系统。第一个子系统通过销售代表从消费者获取订单和付款信息。后一个子系统获取仓库治理员对产品订单队列的处理。产品订货系统合成两个COTS（Commercial off the Shelf，已下架的商品化）产品：存货系统处理产品存货，而订单仓库作为数据库（后者既用于产品订货系统又用于存货系统）。

表格 1 表示我们的系统体系结构使用分层模式（或分层风格）进行设计。该体系结构模式将在后面由设计模式和其他设计特征补足。

表格 1 讨论产品订货系统的分层体系结构模式

产品订货系统

- 用户界面（订单获取界面，订单处理用户界面，存货用户界面）

- 订单框架（消费者，付款，订单，订单行，记录器）

- 存货系统

- 网络（LAN）

- 订单仓库

模式怎样有助于视图集成？

在文章展开论述时，我们将揭示关于产品订货系统更多的细节。虽然，由于篇幅的限制，我们既不能在此表述整个系统，也不能阐述所有的集成技术。相反，如前面提到的，我们将集中于视图集成时模式承担的角色上。对应于图 2 中简述的三个集成活动，模式支持如下活动（下节将说明例子）：

映射

模式支持不同抽象层次的视图之间的映射（交叉引用）。例如，一个高层框图指出使用一个已知后来在低层次框图中实现的模式。这样，这类模式存在于低层次框图的知识以及该模式粗略了解（如在[Gamma et al. 1994]和[Buschman et al 1996]中定义）的知识有助于在低层框图中自动鉴别。

模式也支持不同类型视图的映射。例如，模式描述经常指定其结构和它们的动态行为。那么，可以在我们的模型中使用这些知识来交叉引用结构化的和动态的信息。

变换

模式应用于变换的方法与它们在映射中的用途类似。对于变换，我们可以把它们用作抽象和转化。对于抽象，我们意指简化视图的处理。例如，假如我们想知道高层视图和低层视图是否一致，那么我们需要精炼高层视图或者抽象低层视图以使直接比较成为可能。前者不能自动进行，而后者可以。为了抽象视图，需要确定相关的片段，然后，它们被更加简单的事物替换。对此，模式是完美的原始资料，因为它们提供哪些片段属于一起的知识。我们可以使用模式知识抽象低层模式到高层模式（或者对等的单个部件）。

模式也可以如我们在映射中讨论的那样用于静态与动态结构之间的转化。既然模式经常用两种式样描述，我们可以通过结构推导行为（反之亦然）。这样，利用模式我们也可以转化视图。

分化

如图 2 中简述，分化强依靠于映射和变换。这意味着要在视图中找出不一致性，我们需要确定其建模元素的关系，并且需要找出从一个视图到另一个视图变换信息的方法。没有前一个步骤我们不能知道要比较什么信息，没有后一步，我们不知道怎样比较。一旦上述步骤完成，我们可以使用两个主要技术比较视图：

（图形）比较：依靠变换的视图和原始视图的对比进行比较。该技术暗示：一个视图可以保留充分完整的风格变换为另一个视图。

约束和规则检查：我们频繁地发现视图不能广泛的变换为另一个视图，但它的少部分和片段可以。在这种情况下，我们可以使用规则和约束来论述和分析这些片段。

对于分化，设计模式并非直接有用，然而，我们通过映射和变换收集到的有关视图的信息却可以。我们已经简短地讨论模式怎样有助于映射和变换视图。在这些例子中，比较视图是直接的，因为映射和变换启用直接（图形）比较。无论如何，模式在约束和规则检查中也非常有用。例如，我们在表格 1 中介绍的分层模式定义了自然的约束：用户界面只答应与订单框架对话，订单框架依次只能与存货系统对话等等。该体系结构的模式影响了设计的结构和它的行为。

在产品订货系统中使用模式

本节通过说明模式可以怎样在我们的产品订货系统语境中应用于集成活动的例子补充上述论述。

分化

图 3 使用UML包说明我们系统的高层设计视图。该图显示主要订单系统部件（或子系统）的交互。关于分层体系结构的知识现在可以帮助我们在表格 1 中的体系结构和图 3 的设计之间自动确定不匹配。表格 2 总结两个视图对立的约束。

体系结构视图约束从表格 1 导出。它们定义我们系统层次之间的调用依靠关系（例如，用户界面依靠于订单框架）。图 3 是设计视图约束的基础。该图说明一个含有一套包以及它们之间调用依靠的UML包图（包和依靠的语义在[Booch-Jacobson-Rambaugh 1997]中定义）。

表格 2 体系结构上和设计视图对立的约束

体系结构的视图约束

体系结构[用户界面取决于订单框架]；

体系结构[订单框架取决于存货系统]；

体系结构[存货系统取决于网络]；

体系结构[网络取决于订单仓库]；

设计视图约束

设计[订单获取UI取决于订单框架]；

设计[订单处理UI取决于订单框架]；

设计[存货UI取决于存货系统]；

设计[订单框架取决于存货系统]；

设计[订单框架取决于网络]；

设计[存货系统取决于网络]；

设计[网络取决于订单仓库]；

映射

设计[订单获取UI] 映射到体系结构[用户界面]

设计[订单处理UI] 映射到体系结构[用户界面]

设计[存货UI] 映射到体系结构[用户界面]

设计[订单框架] 映射到体系结构[订单框架]

设计[存货系统] 映射到体系结构[存货系统]

设计[网络] 映射到体系结构[网络]

设计[订单仓库] 映射到体系结构[订单仓库]

完整性规则

对于所有体系结构的视图约束存在设计视图约束；

例如：

体系结构[用户界面取决于订单框架] =>

存在：设计[订单获取UI取决于订单框架] 或者

设计[订单处理UI取决于订单框架] 或者

设计[存货UI取决于订单框架]

一致性规则

对于所以设计视图约束存在体系结构约束；

例子：

设计[订单处理UI取决于订单框架] =>

存在：体系结构[用户界面取决于订单框架]；

表格 3 描述产品订货系统的分层体系结构模式

产品订货系统

用户界面（订单获取UI,订单处理UI,存货UI）

订单框架

存货系统

网络（LAN）

订单仓库

建立这些约束是变换的责任，并且在这种情形下能够自动完成。例如，利用我们在表格 1 中的分层模式的知识我们可以自动导出层间的调用依靠关系。优点是模式的语义只需要定义一次并且可以在以后重用。视图的语义和符号也可以看作模式。这样，图 3 的包图带有一套预定义的相关约束。一旦定义，就可以对包图的不同实例导出设计约束。

表格 2 的映射部分定义了体系结构视图（表格 1 ）和设计视图（图 3 ）部件之间的关系。在这个例子中，用于映射的模式使用不是那么明显。我们将在后面讨论它们对于映射的使用。

表格 2 中最后两个部分是部分的分化活动。在那里，定义了两类规则，一个用于一致性，另一个用于完整性。假如体系结构定义的一些部件或连接器没有反映在设计中，就可能显示潜在的不完整。在另一方面，假如设计与体系结构抵触，那么这可能指出潜在的不一致性。另外，对于每套我们比较的视图，规则只需要定义一次；那些规则然后可以重用。在体系结构和设计实现之间确定不匹配现在是评估规则和约束的事情。这样揭示了没有完整性方面的不匹配情况，然而，有些不一致性方面的不匹配：

1) 存货UI部件对于存货系统的依靠与分层体系冲突，用户界面不答应不经过订单框架直接与存货系统进行交流。

2) 类似地，订单系统要求使用存货系统访问网络。

图 3 UML中的高层设计（包图和依靠）

确定这些不匹配并没有对他们的起因给出任何反馈。例如，是体系结构还是设计错误？表格 3 说明通过提升存货系统到订单框架同一个级别来解决上述所有不匹配而不会引入新的不匹配的可能方法。我们不相信实际的不匹配解决方法将彻底地自动完成。这种方法与先前的自我纠错源代码编译器的尝试相同，这种努力最后因为所包含的社会和技术的复杂性而失败了。可是，我们相信提供给设计者不仅仅使用（潜在的）不匹配，而且用关于怎样在处理不匹配以及理解它们这两者高度有利的情况下解决它们。此外，它可能对发现处理具有更好选择情形的技术非常有好处。我们将在[Egyed 1996]中更具体地讨论这种情形。

映射

图 4 表明我们系统的另一个视图，图 3 的一个精炼。另外，该视图可以对修订的体系结构和高层设计都能进行校验，然而，并没有发现不匹配。该视图用另外的设计模式例如模板【[2]】（Template）模式（通过<>构造型指定）和代理【[3]】（PRoxy）模式（通过《Proxy》构造型指定）。我们将使用它们进一步探究模式在视图集成中的价值。

图 4 高层设计视图使用UML类和包的精炼

图 5 低层设计视图使用UML类图

图 5 描写了对应的低层实现，它不只是解决用于图 4 中的模式，而且也精炼其它的一些建模元素。顶部三个类对应用户界面层，存货系统可以通过存货代理来访问，仓库可以类似地通过仓库代理来访问。要找出该视图是否和先前的视图一致，我们可以运用几个集成技术。

首先，我们需要找出哪些模型元素互相对应（映射）。这有几种技术可以应用，例如名字的相似性等等。可是，在该例子中模式的广泛使用使我们能够开发关于它们用于映射的知识。通过图4中的高层设计我们明白几个事实：

模板模式用于订单行（OrderLine）

代理模式用于桥接订单行（OrderLine）（产品）与存货系统

代理模式用于使用Oracle 数据库桥接订单框架子系统

接口特征（例如，消费者类与订单、付款、和消费者UI接口）

图 6 结构化模式知识（改编自[Buschman et al. 1996]）

虽然从技术上讲，最后一项并不是一个清楚定义的模式，然而它构成类配置的知识――这样，接口特征可以看作模式，即使它们大部分只是领域模式。关于领域的模式知识如同预定义的模式（参看图 6 ）一样使我们现在可以推论建模信息的关系。映射图 4 和图 5 的任务被精简为使用如图 6 所论述的预定义结构化模式知识来确定上述模式和（接口）特征的位置。

用图 6 作为指导，我们可以轻易地确定模板模式（产品，队列，以及产品队列对应于订单行（OrderLine））的对应。虽然，它也可以轻易找到代理模式，怎样能够区分它们却不够清楚。注重到目标是使得计算机自动鉴别它们。要在后来做到这一点，我们可以使用上面讨论的接口特征（模式）。想法是，至少存在一些映射或者能够通过名称相似性来建立。使用该额外信息它可能自动从Oracle模式区分存货（Inventory）模式。

不幸的是，通过模式的映射仍然比上述例子可说明的要更困难一些。我们作了简化的假定，就是模式的结构和行为是静态的。虽然，通常模式不是那些精确定义的，并且我们需要它们更一般的描述。图 5 表明这样一个例子，仓库代理模式看上去不象定义的那样。然而，既然网络是部分代理类，它就可以合并到代理类中，并且代理类继续它所有的依靠关系（下一节的Rose/Architect将表达一个模型来这样做）。

该映射技术的另一个问题是模式，在识别的时候，有时可能只是粗糙地指出它们的位置。例如，对应于队列，产品，和产品队列，订单行队列（OrderLine Queue）可以在低层框图中找到。虽然这也是正确的，但是它丢失了同时在低层框图中表示的组成订单行（OrderLine）。

QQread.com

推出各大专业服务器评测 linux服务器的安全性能

SUN服务器

HP服务器

DELL服务器

IBM服务器

联想服务器

浪潮服务器

曙光服务器

同方服务器

华硕服务器

宝德服务器

变换

模式和抽象

单独的介于图 4 中的高层视图以及图 5 的低层视图之间的映射不足以确定不匹配。例如，在图 4 可以看到付款是消费者的一部分，然而在图 5 中这种关系更加复杂。为校验两个图是按相同的方法讨论关系，我们可以使用Rose/Architect概念。

Rose/Architect [Egyed-KrUChten 1999]认为模式分组为三类，并且使用及物关系替换为更简单的模式。在类图中，及物关系论述那些不直接连结的类之间的关系。然而一个关系可以通过其他类（例如helper类）存在，它在它们之间形成了一个桥（例如，假设上述例子中付款和消费者并不直接相连，但是它仍然通过helper（帮助者）类事务（transaction）和账目（account）类给出关系）。这样，假如发现某些公式，它们可以按有效精度导出及物关系，那么，可以按工具形式提供简化和抽象类图方面的自动支持。这将答应设计者通过删除“帮助者类”从现有的、更细节化的模型中抽象出重要的类，这样将使得它们更进一步描写和分析类之间中间关系，即使这些类分散在整个模型的不同位置（例如，不同的框图，或者在不同的包和名字空间中）。

RA提供这种机制而[Egyed-Kruchten 1999]具体地讨论了这种技术。当前，RA模型由大概80条抽象规则组成。例如规则4，论述了一个类被第二个类泛化（继续的反义词）并且父类是第三个类的聚集（部分）（参看图 7 ）的情形。这种三类模式现在可以删除中间类来简化并创建一个从第一个类到第三个类的及物关系（在该例子中的一个聚集）。下面的RA模型讨论这些规则以及必须怎样应用它们来产出有效的结果。

图 7 表明我们的低层设计视图（图 5 ）中的付款给消费者关系案例的RA精炼步骤。在应用两个规则（分别是规则4和规则17）之后我们得到一个具有两个类以及它们之间依靠关系的简化模式。假如这也可以对其他类以及在映射小节中讨论的模式【[4]】进行处理，我们就可以自动产生更高层次的类图（图 8 ）。产生的这个抽象视图现在就可以与我们在图 4 中描写的原始的更高层次类图直接进行比较了。这样，通过模式的使用我们可以转换视图以便它以非常类似其它视图的方式表达信息。比较视图现在可以简单地使用一些图形比较算法（也可参看上面所说的分化）的形式来完成。图 8 也显示了可能的不一致性。例如，从付款到订单的聚集丢失了，存货系统对Oracle数据库的调用没有使用网络部件，以及一些链接是不同的（例如，使用关联链接而不是依靠链接）。在变换（抽象）之后，这些不匹配可以轻易地识别。

必须注重的是抽象没有彻底地自动完成。虽然，模式有助于在某些建模信息之间确定映射和变换，它们不能完全自动化该过程。因此，需要一些手工辅助来导出图 8 。而且，RA工具当前只能对付如图 7 讨论的简单的三类模式而不能处理图 6 中讨论的更加高级的设计模式。这样，由于该作业的缘故，抽象设计模式（例如代理）由手工完成。然而，一旦更加复杂的设计模式概念体现到RA中，这种抽象可以是自动的。对此，设计模式需要按照它们的输入（源）和目的以及它们的访问点进行讨论。

图 7 通过Rose/Architect的模式抽象

当前，另外一个RA缺点是它只能用于抽象类图信息。虽然该技术也可以扩展到抽象其它类型的视图，但是当我们想要比较不同类型视图的建模元素时它仍然对我们没有帮助。下一小节将论述这种情况。

模式和转化

鉴于抽象处理简化视图的情形，转化处理在不同类型视图之间共享建模信息的情况。例如，上述讨论中，我们广泛使用类和类图，它们按结构化形式表达信息。既然结构视图在表示系统行为通常是不足的，那么行为视图例如序列图就要用来填补这个缺口。

例如，再考虑表格 1 中体系结构分层模式的约束（与高层设计视图的约束一起）。在那里体系结构的约束决没有覆盖全部分层体系结构的行为。一个分层的体系结构不只是限制哪些层答应互相对话，它也限制交互的方向。虽然结构框图比如类图可以描写某些方向性的依靠，但是它可能忽略其它的方面。

图 8 使用Rose/Architect和设计模式抽象的类图

图 9 关于新订单创建的序列图（对应于低层次框图）

图 9 显示了一个更加复杂的行为案例。一个UML序列图在这里用于描述创建一个新的消费者订单的可能场景。在某些用户输入被校验之后，它检验消费者是否存在。假如不存在，新的消费者被创建，在此之后，建立新的订单。该场景描写低层次设计视图（图 5 ）某些行为方面。照此我们可以使用图 5 自动检验类（或对象）之间的调用依靠，在这种情况下没有揭示不匹配情况。该序列图也符合我们的体系结构，因为所有的层次约束都观察到了（两者都可以自动检验）。既然按照组件的行为结构视图具有高度二义性，我们可以再次利用我们的模式知识精炼行为的信息。

图 9 利用订单仓库代理，网络，和Oracle数据库以及在映射中我们发现的那些对应代理设计模式的类。如在[Buschman et al 1996]中所发现的那样，图 10 显示代理模式结构的和行为的定义。效应上，行为定义是结构的一个转化。这样，我们可以使用该知识来检验图 9 的正确性。

因为在图 10 中的代理定义和图 9 中代理实例化之间的抽象级别并不相同，我们需要先抽象图 9 。基本上，我们可以使用Rose/Architect概念通过合并网络到订单仓库代理中来抽象网络（这是有效的，因为网络是代理的一部分）。此后，定义和实例化之间的直接比较是可能的。在该案例中没有发现不匹配。

图 10 代理模式的结构和行为

由于篇幅的限制，我们不可能进一步讨论这个过程更多的细节。请参考[Egyed 1999a]和[Egyed 1999b]得到更多信息。