不幸的是，通过模式的映射仍然比上述例子可说明的要更困难一些。我们作了简化的假定，就是模式的结构和行为是静态的。虽然，通常模式不是那些精确定义的，并且我们需要它们更一般的描述。图 5 表明这样一个例子，仓库代理模式看上去不象定义的那样。然而，既然网络是部分代理类，它就可以合并到代理类中，并且代理类继承它所有的依赖关系（下一节的Rose/Architect将表达一个模型来这样做）。
　
　　该映射技术的另一个问题是模式，在识别的时候，有时可能只是粗糙地指出它们的位置。例如，对应于队列，产品，和产品队列，订单行队列（OrderLine Queue）可以在低层框图中找到。虽然这也是正确的，但是它丢失了同时在低层框图中表示的组成订单行（OrderLine）。
　
　　变换模式和抽象单独的介于图 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]得到更多信息。
　
　　相关的工作视图集成的缺乏并不是新发现。相反，很多模型描述都谈论到保持视图一致的需求。有时，处理模型提供有关什么任务可以提升体系结构概念完整性的附加方针。例如，一个关于使用WinWin Spiral Model（螺旋模型）[Boehm et al 1998]的案例研究建议在LCO（life-cycle objectives， 生命周期目标）和LCA（life-cycle architecture，生命周期体系结构）阶段之后使用体系结构复审板（Architecture Review Boards）[AT&T 1993]来检验和证实分析和设计的完整性。类似的观点可以在其他多不胜数的研究工作中看到：[Sage-Lynch 1998]讨论集成（企业范围）的不同方面。他们一再地强调“体系结构在系统集成中承担重要的角色。”他们针对三个主要的视图表达需求：企业视图，系统过程和管理视图以及技术实现视图――并且他们强调在这些视图之间保证一致性。
　

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

【责编:Lili】