图 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）。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
