模式和抽象
单独的介于图 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中，这种抽象可以是自动的。对此，设计模式需要按照它们的输入（源）和目的以及它们的访问点进行讨论。
文章来源于领测软件测试网 https://www.ltesting.net/
