图 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）模式。
　

上一页  [1] [2] [3] [4] [5] 下一页  

【责编:Lili】