图 2 视图集成活动
映射：通过使用命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种关联/模式形式（例如公共接口）来确定相关的信息片。
变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共享（或在系统模型自身中表述）。例如，我们可以使用抽象技术泛化一个详细的框图，我们可使用视图转化在不同类型的视图之间交换信息，或者我们可以按不同的风格重新排列模型元素（或片段）产生新的视角（例如拼结和分割）。
分化：详细研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则和约束的形式讨论。此外，不匹配解决规则可与将要怎样解决它们可选方法的不匹配标识规则相关联。分化是强依赖于变换和映射的。
然而，必须注明的是，那些活动不是相互正交的。显然地，我们只有在知道模型元素的正确映射时才能做出有用的变换。这种依赖关系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视图可以用于澄清其它视图中的二义性。
此外，如图 2 所示，视图集成不只局限于模式，然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视图集成方向。其他非模式相关的视图集成方向在[Egyed1999a]和[Egyed1999b]中论述。上述框架通常在UML之外也适用。
产品订货系统案例
我们将使用一个简单的产品订货系统贯穿全文进行指导，该系统被分成两个主要的子系统――订单获取子系统和订单处理子系统。第一个子系统通过销售代表从消费者获取订单和付款信息。后一个子系统获取仓库管理员对产品订单队列的处理。产品订货系统合成两个COTS（Commercial off the Shelf，已下架的商品化）产品：存货系统处理产品存货，而订单仓库作为数据库（后者既用于产品订货系统又用于存货系统）。
表格 1 表示我们的系统体系结构使用分层模式（或分层风格）进行设计。该体系结构模式将在后面由设计模式和其他设计特征补足。
表格 1 讨论产品订货系统的分层体系结构模式
产品订货系统
- 用户界面（订单获取界面，订单处理用户界面，存货用户界面）
- 订单框架（消费者，付款，订单，订单行，记录器）
- 存货系统
- 网络（LAN）
- 订单仓库
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
