Coupled Software Transformations — Extended
Coupled Software Transformations — Extended
复制标题
耦合软件转换——扩展
DOI：
10.1007/978-3-540-72524-4_74
复制
发表时间：
2007
期刊：
影响因子：
56.9
通讯作者：
R. Lämmel
中科院分区：
文献类型：
--
作者：
R. Lämmel
我们确定了耦合软件转换的类别，它包括涉及两个或更多工件的转换场景，这些工件在以下意义上是耦合的：一端的转换需要协调另一端的转换，以便重新建立全局一致性。我们描述了耦合转换的本质。我们证实了耦合变换问题是广泛和多样的。1. 每个人都习惯于两种常见的软件转换类别：类型保留转换（在b[15]中也称为rephrasing，但也有其他术语）与类型更改转换（在文献中主要称为翻译）。我们使用术语类型作为格式、语法、模式、语言、元模型等的占位符。（在这里，我们不必限制自己使用与上下文无关的结构。）保持类型的转换为输入和输出断言相同的类型。例如，程序优化器和程序规范化器就是这种类型。类型更改转换将根据一种类型的数据映射到根据另一种类型的数据。例如，MDA中的语言编译器、应用程序生成器和pimto - psm转换都属于这种类型。许多转换场景具有更复杂的形状。最值得注意的是，人们往往最终想要耦合转换——这是本文的主题。我们的意思是... ...可能涉及到两个或更多不同类型的工件，而一端的转换需要协调另一端的转换，以便重新建立全局一致性。我们注意到，任何类型的耦合转换问题都必须实例化所涉及的工件类型的一致性概念。耦合转换从工件的一致聚集开始并结束。任何类型的耦合转换问题也必须实例化协调的概念，它定义了一个工件的转换如何影响所有其他工件。我们强调我们使用术语软件转换，而不是更严格的术语程序转换。也就是说，我们并不局限于源代码的转换。因此，数据、不可执行规范、语法、元模型、文档和其他工件的转换都包括在内。我们还强调，我们不局限于信息保存（或语义保存）转换，因为增强或减少也应该包括在内。例如，进化转化需要这样的普遍性；请参阅[19]中（基于规则的）程序的各种转换属性。2. 考虑一个使用关系数据库进行数据管理的信息系统，所有功能都是用第二代-第四代语言（“2 - 4gl”）实现的。我们面临着如下的工件：关系模型，它作为数据库中的数据库模式实现；用户界面组件的4GL表单；4 gl报告;对4GL源有贡献的SQL或PL/SQL片段；在2-3GL代码中嵌入SQL代码；2 - 3GL程序的数据结构，重新哈希一些关系模型。需要耦合转换的演进场景多种多样。例如，我们可能面临一个更改请求，它被表述为数据库模式级别的修改。此主要修改必须通过数据库实例映射完成。此外，所有的2-4GL代码也可能需要修改。所以我们必须适应SQL和PL/SQL片段，我们必须适应嵌入式SQL代码，甚至是原生的2-4GL代码，因为它提交到数据库模式的方式。所有这些适应都是相互关联的。一致性指的是在不同的代码构件中使用相同的关系模型。这显然是一个耦合变换问题。能否成功地提供该场景的有效实现是另一个问题，它需要包括与不断发展的数据库模式相关的所有代码工件的操作协调。3. 耦合软件转换的一般类别以前并没有被确定——尽管特定的转换技术确实存在，而且相当多的相关研究正在进行；参见[5,11,26,29,22,17,10]。因此，最终给这一类别起个名字也许是有用的。我们将更进一步：在第4节中，我们将描述耦合转换的本质。耦合变换问题是普遍存在的；它们在计算机科学的各个学科中都有遇到，例如，语言处理、生成式编程、自动化软件工程、软件再工程、模型驱动的体系结构和数据库再工程。在第5节中，我们将列举与耦合转换相关的一些问题域。这些领域对耦合的理解截然不同。4. 耦合转换的本质在不失去一般性的情况下，我们将考虑两个工件的协调。设和为工件的类型。我们假设在和上存在一致性关系。我们得到了两个具体的工件。我们考虑上的一个保类型变换，记为，我们将这个变换应用到这样的变换上，得到。然后，调和问题是关于确定一个合适的这样的持有。我们在图1中总结了选择的调节选项；连续箭头显示转换；虚线箭头表示一致性声明。图中的第一个选项，不调和，仅仅是为讨论提供一个良好的起点。如果已知是受限制的，在不挑战一致性的情况下改变，那么我们就可以保持原样。例如，在数据库实例上使用SQL的数据操作语言不会影响底层数据库模式。因此，这种受限制的实例转换不会触发模式转换。显然，这个简单的选项不包括转换数据库模式的反向情况。图中的第二个选项，即退化的和解，仍然微不足道。我们假设类型的具体工件可以从类型的具体工件派生
We identify the category of coupled software transformations, which comprises transformation scenarios involving two or more artifacts that are coupled in the following sense: transformation at one end necessitates reconciling transformations at other ends such that global consistency is reestablished. We describe the essence of coupled transformations. We substantiate that coupled transformation problems are widespread and diverse. 1. Definition of the subject matter Everyone is used to two common categories of software transformations: type-preserving transformations (also called rephrasing in [15], but other terms are around as well) vs. type-changing transformations (mostly called translations in the literature). We use the term type as a placeholder for format, grammar, schema, language, meta-model, and others. (Here, we do not necessarily restrict ourselves to context-free structure.) A type-preserving transformation asserts the same type for input and output. For instance, program optimisers and program normalisers are of that kind. A type-changing transformation maps data according to one type to data according to another type. For instance, language compilers, application generators, and PIM-to-PSM transformations in MDA are of that kind. Many transformation scenarios are of a more complex shape. Most notably, one often ends up wanting coupled transformations — the subject of this paper. By this, we mean that ... ... two or more artifacts of potentially different types are involved, while transformation at one end necessitates reconciling transformations at other ends such that global consistency is reestablished. We note that any kind of coupled transformation problem must instantiate the notion of consistency for the involved kinds of artifacts. A coupled transformation starts from and finishes with a consistent conglomeration of artifacts. Any kind of coupled transformation problem must also instantiate the notion of reconciliation, which defines how transformations of one artifact affect all the other artifacts. We emphasise that we use the term software transformation rather than the more restrictive term program transformation. That is, we do not restrict ourselves to the transformation of source code. Hence, transformations of data, nonexecutable specifications, grammars, meta-models, documentation, and other artifacts are included. We also emphasise that we do not restrict ourselves to information-preserving (or semantics-preserving) transformations because enhancements or reductions should be included as well. For instance, evolutionary transformations require such generality; see the various transformation properties for (rule-based) programs in [19]. 2. An example related to software evolution Consider an information system that uses a relational database for data management, and all functionality is implemented in 2nd – 4th generation languages (“2–4GLs”). We are faced with artifacts such as the following: the relational model, which is implemented as the database schema in the database; 4GL forms for user-interface components; 4GL reports; SQL or PL/SQL fragments that contribute to 4GL sources; embedded SQL code in the 2–3GL code; 2– 3GL programs with data structures that rehash some of the relational model. There are various evolution scenarios that call for coupled transformations. For instance, we might face a change request that is phrased as a modification at the level of the database schema. This primary modification must be completed by a database instance mapping. Furthermore, all the 2–4GL code is likely to require modification as well. So we have to adapt SQL and PL/SQL snippets, we have to adapt embedded SQL code, and even native 2–4GL code because of the way it commits to the database schema. All these adaptations are coupled. Consistency is here about the use of the same relational model in the different code artifacts. So this is definitely a coupled transformation problem. It is a different question whether or not one succeeds to provide an effective implementation of the scenario, which would need to include an operational reconciliation for all the code artifacts relative to an evolving database schema. 3. The purpose of this text The general category of coupled software transformations has not been identified previously — even though specific transformation techniques do exist, and quite some amount of related research is being pursued; see, e.g., [5, 11, 26, 29, 22, 17, 10]. So giving finally a name to this category is perhaps useful as such. We go further than that: in Sec. 4, we will describe the essence of coupled transformations. Coupled transformation problems are ubiquitous; they are encountered in various disciplines of computer science, e.g., in language processing, generative programming, automated software engineering, software re-engineering, model-driven architecture, and database re-engineering. In Sec. 5, we will enumerate some problem domains in which coupled transformations are relevant. The understanding of coupling differs radically for these domains. 4. The essence of coupled transformations Without loss of generality, we will consider reconciliation for two artifacts. Let and be the types of the artifacts. We assume a consistency relation on and . We are given two concrete artifacts and such that holds. We consider a type-preserving transformation on , denoted by , and we apply this transformation to such that we obtain . Then, the reconciliation issue is about determining a suitable such that holds. We summarise selected reconciliation options in Fig. 1; continuous arrows visualise transformations; dashed arrows visualise consistency claims. The first option in the figure, no reconciliation, is merely there to provide a good starting point for the discussion. If is known to be restricted such that is changed without challenging consistency, then we can just keep — as is. For instance, using SQL’s data manipulation language on a database instance does not affect the underlying database schema. So this sort of restricted instance transformation does not trigger a schema transformation. Clearly, the inverted situation, where the database schema is transformed, is not covered by this trivial option. The second option in the figure, degenerated reconciliation, is still trivial. We assume that the concrete artifacts of type are derivable from the concrete artifacts of type Trivial option: no reconciliation