ABSTRACT Aspects and Transformations to Support Evolution in(5)

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

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).