ABSTRACT Aspects and Transformations to Support Evolution in Model-Driven Engineering

更新时间：2023-06-02 01:58:01 阅读量：实用文档文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

abstract推荐度：
相关推荐

A key benefit of system and software modeling is the ability to explore various design alternatives to reach a fixedpoint representation of a concrete system design. Among a diverse set of configuration possibilities, a model engineer must be able to explo

Aspects and Transformations to

Support Evolution in Model-Driven Engineering

Jeff Gray, Yuehua Lin, Jing Zhang

University of Alabama at Birmingham

ABSTRACT

A key benefit of system and software modeling is the ability to explore various design alternatives to reach a fixed-point representation of a concrete system design. Among a diverse set of configuration possibilities, a model engineer must be able to explore the effects of a design decision (e.g., the effect of a specific communication protocol on systemic properties such as throughput) in a rapid manner and be able to revert back to a previous configuration. Each new design configuration can be simulated or analyzed to determine the effect on a set of observed properties. There are two key challenges in supporting evolution in model-driven engineering: 1) the emergence of crosscutting properties that are projected across a model hierarchy, and 2) scalability issues that concern the expansion of a base model. We have applied model transformation to provide an automated solution that addresses these two modeling challenges.

KEYWORDS/TAXONOMY

D.2.2 [Software Engineering]: Design Tools and Techniques – Object-oriented design methods.

D.2.5 [Software Engineering]: Programming Environments – graphical environments.

As the size of system models grow, the limits of model-driven engineering practice are being pressed to address increasingly complex management issues that pertain to change evolution within the model representation [1]. Consequently, modeling tools are being challenged to provide new capabilities to assist in model evolution. A general metric for determining the effectiveness of a modeling toolsuite comprises the degree of effort required to make a correct change to a set of models. A goal of model evolution is to improve productivity while reducing the potential for error that is typically associated with a manual process. To reduce the complexity of the modeling activity, an approach to model evolution should limit the amount of mouse clicking and typing required to realize a change.

There are two categories of change evolution that present specific problems for the modeling process. The first category pertains to concerns that crosscut the hierarchy of the model representation. Such changes require the model engineer to visit multiple locations in the model in order to address a specific concern. For example, the effect of fluctuating bandwidth on the quality of service in a video stream may crosscut multiple components that are defined in a model. The application of aspect-oriented techniques [2] at the modeling level can provide a solution to this type of evolution by modularizing the crosscutting property. A second category of change evolution concerns the issue of scalability, where a base model is replicated to expand the size of a model. For example, a core model may capture the essential connections and properties of a sensor network that can then be scaled to an arbitrary number of sensors. This type of change requires the creation of multiple modeling elements and the appropriate connections between them.

A manual approach to address these two categories of change is typically inadequate. As an alternative to manual model evolution, we have applied a model transformation approach to assist in the automation of evolving modeling concerns. In this article we motivate the need for change evolution among these two categories through specific examples from models in the mission-computing avionics domain. The practical benefits of applying aspects and transformations at the modeling level are emphasized by the significant reduction of manual effort.

AUTOMATED MODEL TRANSFORMATION

Model transformation provides an opportunity to automate several of the tasks that are typically performed manually in model-driven engineering. Such automation is a key to the concepts associated with a software factory [3], which aims to remove several remaining accidental complexities associated with software development. Numerous techniques and tools have been developed to support model transformation (please see accompanying sidebar for an overview). To perform model transformations in an automated manner, modeling tools need to offer a specific language for model developers to define their own transformations and execute these transformations on demand

[4]. Our investigation into the development of a model transformation engine suggests that such a language needs to possess the following two characteristics:

The language should be domain- and user-centered. The primary goal for the design of a transformation specification language should allow users to describe a transformation using concepts from their own domain. Among the language considerations of conciseness and comprehension, the key to the design of a transformation language is a set of core abstractions that are intuitive and cover the largest possible range of situations implied by current modeling practice. To achieve this goal, a user-centered transformation language should consist of a small set (ideally a minimized set) of concepts and constructs, but be powerful enough to express a complete set of desired transformation activities.

The language should be specific to model transformation. A model transformation language needs to have full power to specify all types of modeling objects and transformation behaviors, including model navigation, model querying and model modification. This requires both a robust type system and a set of functionally rich operators. In addition to full expressiveness, such a language should provide specific constructs and mechanisms for users to describe model transformations in an efficient way. In other words, a transformation language is also a domain-specific language that captures all the features of the model transformation domain.

The Constraint-Specification Aspect Weaver (C-SAW) was designed with these two characteristics in mind. Figure 1 presents the model transformation process from the perspective of C-SAW. A set of input models, as defined by a specific domain represented by a metamodel, serve as input to C-SAW. A transformation specification is also required to define the specific changes to be made to the source models. The language that is used by C-SAW to describe a transformation specification is the Embedded Constraint Language (ECL), which was created as an extension to the Object Constraint Language (OCL). The output of C-SAW is a set of transformed target models. C-SAW is implemented as a plugin for the Generic Modeling Environment (GME), which provides an environment for defining new modeling environments [5]. The implementation issues associated with C-SAW are presented in the middle of Figure 1, which illustrate the connection between the GME modeling API with the ECL parser and interpreter. Additional information about C-SAW (including papers, software, and videos) can be found at http://www.cis.uab.edu/gray/Research/C-SAW/

Key Constructs of a Model Transformation Language

ECL provides many capabilities to assist a model engineer in writing transformation specifications that reflectively refer to concepts from the user’s modeling domain in order to refine a model in a stepwise manner [6]. This allows transformations to be written concisely and intuitively because the transformations refer to domain elements recognized by the model engineer. The ECL constructs that support such transformation include a type system, a mechanism for selecting modeling elements, and a set of operators to manipulate the source models.

Figure 1. The model transformation process with the Constraint-Specification Aspect Weaver (C-SAW). Source models and a transformation specification serve as input to a transformation engine that derives new target models.

Type System. In GME terminology, a model is structurally a graph where its elements are the nodes of the graph and the relationships between elements are the edges of the graph. An atom is a model element that can not contain any other model elements. A model may be a container in which there may be a combination of submodels and atoms. Both models and atoms have a set of properties. ECL provides a basic type system to describe values and model objects in a transformation. The data types in ECL include standard primitive data types (e.g., boolean, integer, real and string) and model object types (e.g., atom, model, object and connection) that can reflectively refer to domain concepts specified in the metamodel.

Model selection and aggregation. A common activity during model transformation is to find the elements in a model that may need to be modified. There are two different approaches to locating model elements. The first approach - querying - evaluates a predicate expression over a model, returning those elements of the model for which the expression holds. The other common approach uses pattern matching where a term or a graph pattern containing free variables is matched against the model. ECL supports model queries by providing the select operator and a set of special operators on model aggregations to select a collection of model objects. There are also a set of operators to find a single model object.

The select operator is frequently used in ECL to specify a selection from an existing collection, which can be the result of previous operations and navigations. The result of the select operation is always a subset of the original collection. There are also numerous operators to support model aggregation. For example, models(<expression>) is used to select all the submodels that satisfy the constraint specified by the expression. Other query operators include atoms(<expression>), connections(<expression>) and

attributes(<expression>). Operators like findAtom and findModel are used to find a single atom or model; source and destination are used to return the source object and the destination object in a connection.

Transformation operations. The primary model transformation operations include adding model objects, removing model objects and changing model object properties. Standard OCL does not provide such capabilities because it does not allow side effects to a model. However, a transformation language should be able to alter the state of a model. ECL extends the standard OCL by providing a series of operators for changing the structure of a model. To add new elements (e.g., a model, atom or connection) to a model, ECL provides such operators as addModel, addAtom and addConnection. Similarly, to remove a model, atom or connection, there are operators like removeModel, removeAtom and removeConnection. To change the value of any attribute of a model element, setAttribute can be used.

Sidebar: Model Transformation

As a core component of Model-Driven Engineering, model transformation represents the process of applying a set of transformation rules that take one or more source models as input to produce one or more target models as output [1]. There are two major categories of model transformation: model-to-code transformation and model-to-model transformation [2]. Model-to-code transformation generates source code (e.g., Java or C++) from models. The focus of such transformation is to generate artifacts at a lower level of abstraction that can be executed. Model-to-model transformation occurs at the same level of abstraction by translating between source and target models. Many modeling activities can be automated by model transformation to improve the productivity of model engineers and ensure the quality of models. Typical model transformation activities include model refactoring, model optimization, model refinement and model scalability.

To support the automation of model transformation, development tools need to offer a language for model engineers and developers to specify and execute the desired transformations. In general, there are three different approaches for defining transformations, as summarized from [1]:

Direct Model Manipulation – developers access an internal model representation and use a general purpose programming language

(GPL), such as Java or C++, to manipulate the representation from a set of procedural APIs provided by the host modeling tool.

Intermediate Representation – a modeling tool can export the model into an intermediate representation format (e.g., XML). Transformations can then be performed on the exported model by an external transformation tool (e.g., XSLT), and the output models can be imported back into the host modeling tool.

Specialized Transformation Language – a specialized transformation language provides a set of constructs for explicitly specifying the behavior of the transformation. A transformation specification can typically be written more concisely than direct manipulation with a GPL.

Currently, numerous specialized model transformation languages have been proposed by both academic and industrial researchers. These languages are used to define transformation rules and rule application strategies that can be either graphical or textual. Additionally, model transformation languages may be either imperative or declarative [2]. In addition to our C-SAW, some representative examples of other transformation systems follow:

Graph Rewriting and Transformation Language (GReAT) [3] is a graphical transformation language based on graph grammars and graph transformations. In this approach, models are treated as graphs and model transformations are specified as graph transformations. Graph transformations are realized by the application of transformation rules, which are rewriting rules for graphs. A transformation rule consists of two parts: the Left Hand Side (LHS) is a graph to match, and the Right Hand Side (RHS) is a replacement graph. If a match is found for the LHS graph, then the rule is fired, which results in the matched sub-graph of the graph under transformation being replaced by the RHS graph. GReAT provides graphical notations to specify graph patterns, model transformation rules and control flow of transformation execution.

ATLAS Transformation Language (ATL) [4] is a hybrid transformation language, which combines declarative and imperative constructs. Declarative constructs are used to specify source and target patterns as transformation rules (e.g., filtering model elements), and imperative constructs are used to implement sequences of instructions (e.g., assignment, looping and conditional constructs).

Although there exist different approaches to model transformation, the Object Management Group (OMG) initiated a standardization process by issuing a request for proposals on Query/Views/Transformations (QVT), which is near finalization [5].

References

5. S. Sendall and W. Kozaczynski, “Model Transformation - the Heart and Soul of Model-Driven Software Development,” IEEE Software, September/October 2003, pp. 42-45. K. Czarnecki and S. Helsen, “Classification of Model Transformation Approaches,” OOPSLA Workshop on Generative Techniques in the Context of Model-Driven Architecture, Anaheim, California, October 2003. A. Agrawal, G. Karsai, and A. Lédeczi, “An End-to-End Domain-Driven Software Development Framework,” 18th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Anaheim, California, October 2003, pp. 8-15. I. Kurtev, K. van den Berg, and F. Jouault, “Rule-based Modularization in Model Transformation Languages Illustrated with ATL,” ACM Symposium on Applied Computing (SAC) - Model Transformation Track, Dijon, Bourgogne, France, March 2006. MOF 2.0 Query/Views/Transformations RFP, Object Management Group, 2002. /docs/ad/05-07-01.pdf.

CROSSCUTTING DESIGN PROPERTIES

When a concern is spread across an artifact it can be difficult to comprehend and change. Aspect-oriented software development (AOSD) [2] is focused on techniques to modularize concerns that crosscut the decomposition of a system. Although the original application of aspects was focused at the programming language level, there is a growing community investigating aspect-oriented modeling (e.g., the Aspect-Oriented Modeling workshop has met eight times - rmatik.uni-essen.de/events/AOM_AOSD2006/). The most prominent work in aspect modeling is concentrated on notational aspects for the UML [7], but there are also opportunities to provide automation within modeling tools using AOSD principles. In fact, our original development of C-SAW five years ago was motivated by the need to specify constraints that were found to be crosscutting within the model of a distributed real-time embedded system (DRE) [8]. C-SAW has evolved into a general model transformation tool that is capable of addressing a wide range of transformations.

Aspects of Embedded Systems Models

The top of Figure 2 shows the interaction among components in a mission computing avionics application that is modeled in the Embedded Systems Modeling Language (available from http://escher.isis.vanderbilt.edu/tools/). The internal representation of two components are shown in the middle of the figure, which reveals the data elements and other constituents that are specifically intended to describe the infrastructure of component deployment and distribution middleware. The infrastructure implements an event-driven model of computation where components update and transfer data to each other through event notification and call-back methods.

A concurrency atom and two data atoms are circled within the selected components in Figure 2. Each of these atoms represents a concern of the system that is spread among the components across the modeling hierarchy. The concurrency atom (highlighted by a red circle) identifies a property of the system that corresponds to the synchronization strategy that is distributed across the components. The collection of atoms circled in blue defines the recording policy of a black box flight data recorder. A precondition is attached to some of the data elements (indicated by the green circle) to assert a set of valid values upon component invocation.

The challenge of model evolution with respect to crosscutting properties can be understood by considering the effort that is needed to change the synchronization or black box data recorder policies. To make a change to an existing policy in order to analyze the affect of an alternative design decision requires that the model engineer visit every component to make the change manually. This results in much mouse clicking and typing in the modeling tool in order to navigate across the model hierarchy, especially when the size of the models are large (e.g., the specific system modeled in Figure 2 represents a subset of an application that has over 6,000 components).

Figure 2. A subset of a model hierarchy with crosscutting model properties. Concerns related to synchronization (red circle), black-box data recording (blue circle), and preconditions (green circle) are scattered across many submodels.

As an alternative to manual evolution, ECL can be used to define an aspect that assists in the automated evolution of the model. For example, to specify that all data2_ atoms must have a precondition defining the valid range of values, the following modeling aspect can be defined:

aspect PreData2()

{

rootFolder().findFolder("ComponentTypes").models()->

select(m|().endWith("Impl"))->AddPre(“data2_”, “Data2Cond”, “value<200”); }

This modeling aspect can be interpreted as, “From the root folder, collect all of the models that are of type ComponentTypes. From this collection, select all of the components whose name ends with ‘Impl’ and apply the AddPre strategy.” In C-SAW, an aspect is applied by traversing a model and matching elements of the model that satisfy a predicate (e.g., the selection predicate in the PreData2 aspect). Those elements that satisfy a given predicate are then transformed according to the rules in the associated strategy. A strategy is a modular construct provided by ECL to define the transformation within a model. Each strategy should be performed in a specific modeling context, which is provided by the aspect. The context of a strategy call can be an entire project; a specific model, atom, or connection; or a collection of assembled modeling elements. Using the ECL, aspects are defined to

quantify those modeling elements that are to be changed, and a strategy is applied to perform the required transformation.

The AddPre strategy shown in Listing 1 is applied to each component selected from the PreData2 aspect. This strategy finds all of the atoms in the component that are of type Data which match the name passed in as an argument from the aspect. All of the Data atoms that match this predicate will have a new precondition attached by the AddCond strategy. Line 12 of AddCond retrieves a placeholder for the actual Data that will be transformed. The parent component that contains the Data atom is reflectively obtained in line 13. The transformation sequence defined in lines 15 through 17 creates a new Condition atom (line 15) and sets those attributes defining a precondition with an associated expression (lines 16 and 17). The final task of the AddCond strategy adds a connection to the parent component that links the Data atom to the new Condition.

19 strategy AddPre(atomName, condName, condExpr : string) { atoms()->select(a | a.kind() == "Data" and () == atomName)-> AddCond(condName, condExpr); } strategy AddCond(condName, condExpr : string) { declare p : model; declare data, pre : atom; data := self; p := parent(); pre:=p.addAtom("Condition", condName); pre.setAttribute("Kind", "PreCondition"); pre.setAttribute("Expression", condExpr); p.addConnection("AddCondition", pre, data); }

Listing 1. ECL transformation to add a precondition expression to a Data atom.

AUTOMATED MODEL SCALABILITY

A second form of design exploration involves scaling up different parts of a model. Scalability of modeling tools is of utmost concern to designers of large-scale DRE systems. From our personal observation, models can have multiple thousands of coarse grained components (others have reported similar experience, please see [1]). System modeling using traditional manual techniques and tools can approach the limits of the effective capability of humans. The issue of scalability affects the performance of the modeling activity, as well as the correctness of the model representation. Consider a base model consisting of a few modeling elements and their corresponding connections. To scale a base model to hundreds, or even thousands, of duplicated elements would also require a lot of clicking and typing within the associated modeling tool. Furthermore, the tedious nature of manually replicating a base model may also be the source of many errors (e.g., forgetting to make a connection between two replicated modeling elements). A comparison of approaches to support automated model scalability can be found in [9].

Replicating a CORBA Event Channel Model

Figure 3 provides an illustration of scalability applied to the Event QoS Aspect Language (EQAL), which has been used to configure a large collection of federated event channels for mission computing avionics applications (EQAL

is available for download at http://www.dre.vanderbilt.edu/cosmic). The scalability issues in EQAL arise when a small federation of CORBA event services must be scaled from a base model to accommodate a larger number of publishers and subscribers. As can be seen in Figure 3, scaling an EQAL model from three sites (with two gateways per site) to a larger model containing 8 sites (with 7 gateways per site) requires the addition of many new modeling elements. Our experience has shown that model transformations serving as replicators can significantly automate this manual task.

Figure 3. Replication among a federation of CORBA gateways. At the outermost level, three federation sites are replicated to eight sites, with each internal site replicated from two to seven gateways.

The expandSite strategy in Listing 2 illustrates a transformation that replicates the internal CORBA gateways for a specific site. The site and number of desired gateways are passed as parameters in line 1 of the strategy, which then finds the specific site in line 3 and calls a recursive strategy. The addGateWay_r strategy ensures that the proper number of gateways is added. The addGateWay strategy performs the actual transformation on the model by creating a new gateway (line 19), locating the site’s core event channel (line 20) and connecting the new gateway to the existing channel (line 21).

The collection of interacting strategies in Listing 2 accomplishes the transformation that is shown in the upper-right of Figure 3 (i.e., the internal expansion of Site 2). These strategies are also reusable and can be utilized by a model engineer to flexibly explore a design by applying the transformation to several different sites. Although not shown here, a different set of transformations have been specified to scale the outermost number of sites (i.e., moving from three sites to eight sites, as shown in the bottom-right of Figure 3). The parameterization of expandSite is a key to defining the alternative designs. These strategies are not an “aspect” in the sense of Listing 1, but represent a different type of model evolution that can also be specified in a transformation language like ECL.

Considering Figure 3, to perform the equivalent transformation manually would require the insertion of over 120 new modeling elements and almost 150 connections between all of the new elements. Such a manual task is time consuming and prone to error. Furthermore, the real disadvantage of a manual process to replication can be seen when the next design alternative needs to be considered (e.g., scaling to 20 sites with 12 gateways per site), which requires a whole new set of manual modifications. The model transformation of Listing 2 can flexibly handle such replication through parameterization of the specific strategies.

22 { findModel("Site " + intToString(site)).addGateWay_r(1, numGW); } strategy addGateWay_r(curr, numGW : integer) { if (curr <= numGW) then addGateWay(curr); addGateWay_r(curr+1, numGW); endif; } strategy addGateWay(num : integer) { declare site_gw : atom; declare ec : model; site_gw := addAtom("CORBA_Gateway", "CORBA_Gateway" + intToString(num)); ec := findModel("Event_Channel"); addConnection("LocalGateway_EC", site_gw, ec); }

Listing 2. Model transformation to expand the number of CORBA gateways at a specific site.

Tool support for programming language environments is much more advanced than the current capabilities offered in modeling tools. Integrated Development Environments (IDEs) for programming languages provide numerous features for comprehending and evolving large code bases (e.g., automated refactoring, code navigation and visualization). Despite recent advances in modeling tools, there are still many tasks that can benefit from increased automation. Our experience has led us to believe that model transformation can provide a common technology for implementing various kinds of model evolution. In particular, our C-SAW transformation engine has been applied to several modeling languages in the domain of distributed real-time and embedded system in order to modularize crosscutting properties and replicate elements of a core model. We are exploring several additions that will provide extra value to the transformation process, such as testing and debugging support for the ECL to detect and find errors that may exist in a transformation specification.

Acknowledgements

The initial investigation of this research was made possible by previous support from the DARPA PCES program. Current support from the NSF CSR-SMA program is enabling the application of these ideas toward evolution of performance modeling for distributed design patterns.

References

1. S. Johann and A. Egyed, “Instant and Incremental Transformation of Models,” Proceedings of the Conference

on Automated Software Engineering, Linz, Austria, September 2004, pp. 362-365.

2. R.E. Filman, T. Elrad, S. Clarke, and M. Aksit, Aspect-Oriented Software Development, Boston: Addison-

Wesley, 2004.

3. J. Greenfield, K. Short, S. Cook, and S. Kent, Software Factories: Assembling Applications with Patterns,

Models, Frameworks, and Tools, New York: John Wiley and Sons, 2004.

4. Jean Bézivin, “On the Unification Power of Models,” Journal of Software and System Modeling, vol. 4, no. 2,

May 2005, pp. 171-188.

5. K. Balasubramanian, A. Gokhale, G. Karsai, J. Sztipanovits, and S. Neema, “Developing Applications Using

Model-driven Design Environments,” this issue.

6. D. Batory, J.N. Sarvela, and A. Rauschmeyer, “Scaling Step-Wise Refinement,” IEEE Transactions on

Software Engineering, June 2004, pp. 355-371.

7. R. France, I. Ray, G. Georg, and S. Ghosh, “An Aspect-Oriented Approach to Design Modeling,” IEE

Proceedings – Software (Special Issue on Early Aspects), vol. 151, no. 4, August 2004, pp. 173-186.

8. J. Gray, T. Bapty, S. Neema, and J. Tuck, “Handling Crosscutting Constraints in Domain-Specific Modeling,”

Communications of the ACM, October 2001, pp. 87-93.

9. J. Gray, Y. Lin, J. Zhang, S. Nordstrom, A. Gokhale, S. Neema, and S. Gokhale, “Replicators: Transformations

to Address Model Scalability,” Model Driven Engineering Languages and Systems (MoDELS) (formerly the UML series of conferences), Springer-Verlag LNCS 3713, Montego Bay, Jamaica, October 2005, pp. 295-308.

Jeff Gray is an Assistant Professor in the Department of Computer and Information Sciences at the University of Alabama at Birmingham (UAB), where he co-directs the research in the Software Composition and Modeling (SoftCom) laboratory. His primary research interests include model-driven engineering, aspect-orientation, and generative programming. He obtained the PhD in Computer Science from Vanderbilt University and BS/MS in Computer Science from West Virginia University. Jeff is a member of the ACM and has been a member of IEEE for over 18 years (consistently since a freshman undergraduate). Contact him at gray@cis.uab.edu.

Yuehua (“Jane”) Lin is a PhD candidate in the Department of Computer and Information Sciences at the University of Alabama at Birmingham (UAB) and member of the SoftCom lab. Jane’s technical interests are focused on model transformation and supporting tools. She has an MS in Computer Science from Auburn University. Jane is a student member of the IEEE and ACM. Contact her at liny@cis.uab.edu.

Jing Zhang is a PhD candidate in the Department of Computer and Information Sciences at the University of Alabama at Birmingham (UAB) and member of the SoftCom lab. Her research is focused on techniques that combine model transformation and program transformation in order to assist in evolving large software systems. Jing obtained an MS in Computer Science from UAB. She is a student member of the ACM. Jing can be contacted at zhangj@cis.uab.edu.

本文来源：https://www.bwwdw.com/article/y391.html

相关文章：

账户管理试题10-21

大学生预备党员思想汇报03-31

公司年度培训工作总结03-20

雨伞购销合同09-10

电子助理工程师自我评价02-24

模块四后测 2014教育技术中级培训100分答案08-26

苏教版二年级语文第三单元复习空白卷05-17

钢铁冶金用鼓风机项目可行性研究报告备案用(专业版)08-11

全球化背景下的企业文化与核心竞争优势07-25

上一篇：java学生信息管理系统下一篇：工程经济与管理复习题及参考答案