使用模式集成UML视图

《使用模式集成UML视图》由会员分享，可在线阅读，更多相关《使用模式集成UML视图（6页珍藏版）》请在金锄头文库上搜索。

1、使用模式集成UML视图（1）摘要模式在系统组合（合成）期间对养成重用可重复设计和体系结构配置的习惯很重要。木 论文研究关于模式的知识，它也可用于系统分析检验系统模型的完整性。为了支持自动分析 过程，该工作引入一个视图集成框架。自从每个视图（例如，松图）增加一个额外针对模型 的软件系统观点，来自一个视图的信息可能用于验证其它视图的完整性。这种形式的集成要 求对视图表明什么以及它们可以共享（或约束）什么信息有更深的理解。因此关于模式在结 构和行为上的知识，也是一个用于视图集成自动化的冇价值的来源。介绍为支持软件产品开发，我们频繁使用通用软件开发模型（和工具），例如统一建模语言 （UML）o然而，通

2、常意义的软件开发和特定的软件设计（正是我们工作的主要焦点）要求不 仅仅是大多数通用模型所能提供的内容。体系构造是关于：1）对实际问题充分建模2）解决模型问题并3）在现实世界中解释模型方案这样做的主要重点被置于体系结构的视图（例如框图）内和Z间不匹配的鉴别与调和上。 我们经常发现这方而的情况，分析和（体系结构的）说明的解释在大多数通用语言中是次重 点的。我们构造体系不仅仅是因为我们想建立（创作），而因为我们要理解。这样，体系 构造有许多分析和校验产品模型的概念完整性、一致性和彻底性的工作要完成。已完全成为 事实上00软件开发标准的UML的出现，在这个问题上也没冇任何例夕卜。木工作阐述在UML 视

3、图中体系结构不匹配的原因，以及说明模式和集成技术怎么能够以更口动化的方式应用于 识别并解决他们。为了做到这一点，本工作讨论视图集成框架，它的主要活动一一映射 （Mapping）变换（Transformation）和分化（Differentiation）o木论文将研究模式的角色，而不是集中于大量的集成技术（它们支持上述活动）。这样，我们将研究模式的知识怎样冇 助于保证软件系统模型一致性。通过那样，我们按以往很少使用的方式利用模式：我们用模 式用作系统分析，而不是将模式用作构建材料作为系统成分。视图和模型在软件开发中，我们利用模型和视图处理软件系统的复杂性。在这里，模型是指视图的 集合或者视图可以

4、看作模型的一个方而（或视点）o IEEE标准（草案）1471AT&T1993将视 图归结于“提出一个或多个系统利益关联者（Stakeholder）的利害关系S对于利益关联者， 我们定义为分享系统注意或兴趣个体或组（例如，开发者，用八，消费者等等）。应用于我 们的语境，视图是模型的片段，它也要细小到我们能够理解，但是也包含关于特定关系的关 联倍息。在UML中，视图木质上是图形的，11往往通过框图来实现。视图（例如类或序列 图）服务于下列意图：抽象并简化模型使得不同的利益关联者协调工作为不同解释进行补充（不同观众/利益相关者）提取关于特定关联的相关信息因此，将会用到什么类型的视图以及什么时候用到它

5、们是强烈依赖于哪个人正在使用和 需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它 们内部及它们Z间表现出对等数量的建模元索冗余。要给出一个简单例了，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产站实现（例如，C+代码）。类图和代码表述不同的视图，川不同的方法表达相同或类似的信息。虽然，代码可以从设计中 口动产生，这种逼近是有限的，述必须多次加入一些信息。更糟糕的是，现在这些冗余的信 息片断必须保持一致一一后者大多是手工活动。这样，无论什么时候设计变更了，代码就会 变得不一致（反Z亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型 概

6、念的完整性。视图不匹配和冗余既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少兀余的事物来替代 它们。我们需耍视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这 不是带來复杂性的细节数量本身，而是我们不得不同时了解的细节的数量Siegfried 1996 然阳，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图Z间不匹配的口 动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图 不匹配问题可能的逼近方法是基于它特有的问题一一冗余性。我们利用一套视图Z间的冗余 性意味着一个视图包含关于其它视图并可川作约束该视图的信息。这样，我们使川兀余

7、信息 来检验视图Z间的一致性和完整性。例如，如果我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着如果体系 结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直 接对话是不允许的。如果后來系统使用UML设计（例如，使川类和序列图），那么设计元素 Z内的调用依赖要求与上述的体系结构约束一致。我们将在后而说明一个例子。UML视图描述vs集成启用视图集成来确定和调和视图耍求两个层次的集成一一符号集成和语义集成。对于符 号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎 样交换作更进一步精炼

8、。只有在什么和怎样在确立之后，不一致性才町以确定。统一建模语言（UML）,像具他通川软件系统开发模型一样，只是不能很满足上述语义集成。UML 提供一个模型用于表达不同框图的视图来处理类、对彖、活动、状态、包及其它（参看图1）。 然而，UML不擅长集成他们。在UML视图之间的关联和依赖关系很少被捕获。如果后者 没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上 定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一 些微弱形式的依赖关系，例如类和对彖）。图1也表明问题的另一个方面一一那就是凤格/模式分层的凤胳 代理舷分 仅 仅 表 述 模扩

9、展UML以表达新的和外部概念（例如，风格和模式）。例如，怎样才能在UML中使用更 高级的模式例如分层的体系结构模式【1】或代理设计模式？在UML中，我们需耍再次区 式 和 完 整 集 成 它 们 。血仗交生一堆枪散集成的图解也图ta成图1 UML中表示法vs.集成视图集成框架视图集成的主要的障碍是缺乏完好定义的（工程的）模型基础。视图经常使用迥然不同 的表示信息方法，而这使得确定它们在哪里和怎样出现重叠非常困难。这样，组合和比较视 图的任务经常是手工的而且潜伏着错课的。集成框架的口标是要补偿鉴别和解决体系结构不 匹配口动化辅助手段的不足。如前面简短的叙述，这样做的时候，我们的框架需要处理什么信

10、息和怎样进行交换。我们在那里写到什么信息可被交换以及它怎么能交换的判断需 求。在我们的视图集成框架中，我们提到映射和变换这两个活动。我们也说只有在这些活动 定义之后，才能够尝试鉴别不一致性。后者我们称之为分化（参看图2 ）0图2在高层次式样上描写我们的视图集成框架。在那电，系统模型用于表达软件系统 的知识基础。软件开发者使川视图增加新的数据到系统模型并且复审现有数据（视图综合）。 对于UML,系统模型可能被看作通过UML设计工具（例如Rational Rose）完成的UML模 型和视图综合。系统模型和视图综合两者交互影响就是视图分析。一旦加入新的信息，它就町以针对系 统模型进行验证以保证其概念

11、完整性。图2表示视图分析可以怎样进一步细分为具上述三图2视图集成活动映射：通过使川命名字典、跟踪和跟踪仿真（例如相同物理类和方法的使用）以及某种 关联/模式形式（例如公共接口）來确定相关的信息片。变换：在视图中操作模型元素以便它们（或它们的片段）可以在其他视图中共亨（或在系统模型白身中表述）。例如，我 们可以使川抽彖技术泛化一个详细的框图，我们町使川视图转化在不同类型的视图Z间交换 信息，或者我们町以按不同的风格重新排列模型元索（或片段）产牛新的视角（例如拼结和 分割）。分化：详细研究系统模型鉴别系统模型中（潜在的）不匹配。（潜在的）不匹配按规则 和约束的形式讨论。此外，不匹配解决规则町与将要

12、怎样解决它们可选方法的不匹配标识规 则相关联。分化是强依赖于变换和映射的。然而，必须注明的是，那些活动不是相互E交的。显然地，我们只冇在知道模型元素的止确映射时才能做出冇川的变换。这种依赖关 系反之也是成立的。通过视图变换导出的信息可以澄清许多映射中的二义性。这样，一个视 图可以用于澄清其它视图中的二义性。此外，如图2所示，视图集成不只局限于模式,然而，模式对视图集成构成了非常重要的基础。我们将在后续章节中讨论这种面向模式的视 图集成方向。其他非模式相关的视图集成方向在Egyed 1999a和Egyedl999b中论述。上述 框架通常在UML之外也适用。产品订货系统案例我们将使川一个简单的产品

13、订货系统贯穿全文进行指导，该系统被分成两个主要的子系 统一一订单获取子系统和订单处理子系统。第一个子系统通过销售代表从消费者获取订单和 付款信息。后i个子系统获取仓库管理员对产品订单队列的处理。产甜订货系统合成两个 COTS （Commercial off the Shelf,已下架的商品化）产品：存货系统处理产品存货，而订单 仓库作为数据库（后者既用于产品订货系统乂用于存货系统）。表格1表示我们的系统体系结构使用分层模式（或分层风格）进行设计。该体系结构模式将在后而由设计模式和 其他设计特征补足。表格1讨论产品订货系统的分层体系结构模式-用户界面订单获取界面，订单处理用户界面，存货用户界面）

14、-订单框架消费者，付款，订单，订单行，记录器）-存更爲统、-网络Clan）-订单仓库模式怎样有助于视图集成？在文章展开论述时，我们将揭示关于产品订货系统更多的细节。虽然，由于篇幅的限制, 我们既不能在此表述整个系统，也不能阐述所有的集成技术。相反，如前而提到的，我们将 集小于视图集成时模式承担的角色上。对应于图2小简述的三个集成活动，模式支持如下 活动（下节将说明例子）：映射模式支持不同抽象层次的视图之间的映射（交义引用）。例如，一个高层框图指岀使用 一个已知后來在低层次框图小实现的模式。这样，这类模式存在于低层次框图的知识以及该 模式粗略了解（如在Gamma ct al. 1994和Busc

15、hman ct al 1996中定义）的知识有助于在低 层框图中自动鉴别。模式也支持不同类型视图的映射。例如，模式描述经常指定其结构和它们的动态行为。 那么，可以在我们的模型小使用这些知识來交义引用结构化的和动态的信息。变换模式应用于变换的方法与它们在映射中的用途类似。对于变换，我们可以把它们用作抽 象和转化。对于抽象，我们意指简化视图的处理。例如，如果我们想知道高层视图和低层视 图是否一致，那么我们需要楮炼高层视图或者抽象低层视图以使直接比较成为可能。丽者不 能白动进行，而后者可以。为了抽象视图，需要确定相关的片段，然后，它们被更加简单的 事物替换。対此，模式是完美的原始资料，因为它们提供哪

16、些片段属于一起的知识。我们可 以使用模式知识抽象低层模式到高层模式（或者对等的单个部件）。模式也可以如我们在映射中讨论的那样用于静态与动态结构之间的转化。既然模式经常用两种式样描述，我们 可以通过结构推导行为（反Z亦然）。这样，利用模式我们也可以转化视图。分化如图2中简述，分化强依赖于映射和变换。这意味着要在视图中找出不一致性，我们 需要确定其建模元索的关系，并且需要找出从一个视图到另一个视图变换信息的方法。没有 前一个步骤我们不能知道要比较什么信息，没有后一步，我们不知道怎样比较。一旦上述步 骤完成，我们可以使用两个主要技术比较视图：（图形）比较：依靠变换的视图和原始视图的对比进行比较。该技术暗示：一个视图可以保留充分完整的风格变换为另一个视图。 约束和规则检查：我们