Chapter30.Two-Level Aspect Weaving to Support Evolution in Model-Driven Synthesis


Chapter 30. Two-Level Aspect Weaving to Support Evolution in Model-Driven Synthesis

JEFF GRAY, JANOS SZTIPANOVITS, DOUGLAS C. SCHMIDT, TED BAPTY, SANDEEP NEEMA, AND ANIRUDDHA GOKHALE

An important step in solving a problem is to choose the notation. It should be done carefully. The time we spend now on choosing the notation may be well repaid by the time we save later avoiding hesitation and confusion. Moreover, choosing the notation carefully, we have to think sharply of the elements of the problem which must be denoted. Thus, choosing a suitable notation may contribute essentially to understanding the problem

George Pólya [ 37].

Since the inception of the software industry, models have been a beneficial tool for managing complexity. In fact, the first commercial software package that was sold independently of a hardware manufacturer was an application for constructing flow chart models, i.e., ADR's AUTOFLOW [1]. In numerous disciplines, models are constructed to assist in the understanding of the essential characteristics of some instance from a particular domain. Mechanical engineers, architects, computer scientists, and many other professionals create models to provide projected views over an entity that has been abstracted from the real world. As tools for creative exploration, even children erect models of real-world structures using Legos, Tinker Toys, and other similar materials.

As Polya points out in the opening quote of this chapter, the notation chosen to represent our abstractions contributes to the ease (or difficulty) with which we understand the essence of a problem. Selecting the correct modeling abstractions can make the difference between a helpful aid and an irritating hindrance to comprehension. In models for computer-based systems, tool support can also offer assistance in comprehending complex systems.

In addition to improving comprehension, models are also built to explore various design alternatives. In many domains, it is often too costly (in both time and money) to build variations of the real product in order to explore the consequences and properties of numerous configuration scenarios. For example, a model of the Joint Strike Fighter aircraft, along with configurations of various hostile scenarios, permits the simulation of an aircraft before it has even left the production line [46]. Models can be the source for simulations or analyses that provide a more economical means for observing the outcome of modified system configurations. The level of maturity of a chosen modeling tool can greatly influence the benefits of the modeling process, which is especially true when a modeling tool can make changes throughout a model's lifecycle.

As Gerald Sussman observes [42], in traditional system development, "Small changes in requirements entail large changes in the structure and configuration." It is desirable to have changes in the requirements be proportional to the changes needed in the corresponding implementation. Unfortunately, crosscutting requirements (such as high availability, security, and scalability in distributed systems) tend to have a hard-to-manage, global impact on system structure.

Our work involves the construction of models that represent a system in a particular domain. From these domain-specific models of systems and software, various artifacts are generated, such as source code and simulation scripts. We have found that model-based approaches can help to solve problems that often accompany changes to system requirements. For example, Neema et al. offer an approach for synthesizing models represented as finite state machines into a contract description language, which is then translated to C++ [34]. The benefit of this technique is that very small changes to the state machine models often result in large transformations of the corresponding source code. Thus, a single manipulation of a higher-level abstraction may produce multiple transformations at the concrete level, resulting in a conservation of effort when compared to the equivalent effort needed to make the same modification at the implementation level.

Aspect-oriented software development (AOSD) is growing in depth and breadth. The techniques espoused by AOSD researchers generally provide new capabilities for modularizing crosscutting concerns that are hard to separate using traditional mechanisms. This chapter summarizes our work in applying AOSD techniques to domain-specific modeling and program synthesis. The use of weavers, which are translators that perform the integration of separated crosscutting concerns, is described at multiple levels of abstraction. Our research on aspect-oriented domain modeling (AODM) employs the following two-level approach to weaving:

  • At the top level, weavers are built for domain-specific modeling environments. The concept of applying AOSD techniques to higher levels of abstraction is covered in Section 30.1, where we describe our Constraint-Specification Aspect Weaver (C-SAW).[1] This section also provides an overview of Model-Integrated Computing (MIC). An example of AODM is described in Section 30.2.

    [1] According to Webster's Revised Unabridged Dictionary, a crosscut saw (or c-saw) is "a saw, the teeth of which are so set as to adapt it for sawing wood crosswise of the grain rather than lengthwise."

  • The second level of weaving occurs during model interpretation. Synthesis of source code from models typically proceeds as a mapping from each modeling element to the generation of a set of semantically equivalent source code statements. When a library of components is available, the model interpreter can leverage a larger granularity of reuse by generating configurations of the available components. It is hard, however, to synthesize certain properties described in a model (e.g., those related to Quality of Service (QoS)) due to the closed nature of the components. An aspect-oriented solution can instrument components with features that are specified in the model. Section 30.3 presents an approach and an example for generating AspectJ [28] source code from domain-specific models.

The chapter concludes with summary remarks and a description of current and future work in this area.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net