UML视图2.docVIP

使用模式集成UML视图（2） 分化 　　图 3 使用UML包说明我们系统的高层设计视图。该图显示主要订单系统部件（或子系统）的交互。关于分层体系结构的知识现在可以帮助我们在表格 1 中的体系结构和图 3 的设计之间自动确定不匹配。表格 2 总结两个视图对立的约束。 　　体系结构视图约束从表格 1 导出。它们定义我们系统层次之间的调用依赖关系（例如，用户界面依赖于订单框架）。图 3 是设计视图约束的基础。该图说明一个含有一套包以及它们之间调用依赖的UML包图（包和依赖的语义在[Booch-Jacobson-Rambaugh 1997]中定义）。 表格 2 体系结构上和设计视图对立的约束 　　建立这些约束是变换的责任，并且在这种情形下能够自动完成。例如，利用我们在表格 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