Section 30.1. MODEL-INTEGRATED COMPUTING AND AOSD

30.1. MODEL-INTEGRATED COMPUTING AND AOSD

To support this focus on the development of interacting subsystems with multiply redundant design requires the development of languages that allow description of the function and relationships between different parts of the overall system. These descriptions "let go" of the specific logic of individual processes to capture the interactions that are necessary for the redundancy and robustness of multiple processes. When stated in this way we see that it is the description of constraints between functional units of the system that are the essential parts of the collective description of the system

Gerald Sussman [ 42].

The aim of domain-specific modeling (DSM) is similar to the objective of textual domain-specific languages (DSL) [45] in that expressive power is gained from notations and abstractions aligned to a specific problem domain. A DSM approach typically employs graphical representations of the domain abstractions rather than the textual form of a traditional DSL. A program in a DSL is also usually given a fixed interpretation, but a model created from DSM may have multiple interpretations. For example, one interpretation may synthesize to C++, whereas a different interpretation may synthesize to a simulation engine or analysis tool.

Like DSLs, domain-specific modeling raises the level of abstraction to highlight the key concerns of the domain in a manner that is intuitive to a subject matter expert or systems engineer. A domain-specific visual language (DSVL) [18] can decouple designers from specific notations, such as UML [5]. In domain-specific modeling using a DSVL, a design engineer describes a system by constructing a visual model using the terminology and concepts from a specific domain.

30.1.1. Model-Integrated Computing

An approach called model-integrated computing (MIC) [25] has been refined at Vanderbilt University over the past decade to assist the creation and synthesis of computer-based systems. A key application area for MIC is those domains (such as embedded systems areas typified by automotive and avionics systems) that tightly integrate the computation structure of a system and its physical configuration. In such systems, MIC has been shown to be a powerful tool for providing adaptability in frequently changing environments. An example of the flexibility provided by MIC is documented by Long et al. [31], where an installed system at the Saturn automobile factory was shown to offer significant improvements in throughput by being able to adapt to changes in business needs and the physical environment. Other example domains where MIC has been successfully applied are the DuPont chemical factory [14], numerous government projects supported by DARPA and NSF, electrical utilities [33], and even courseware authoring support for educators [22].

An instance of the type of domain-specific modeling supported by MIC is implemented using the Generic Modeling Environment (GME) [30]. The GME is a modeling environment that can be configured and adapted from meta-level specifications (called the modeling paradigm) that describe the domain [35]. When using the GME, a modeler loads a modeling paradigm into the tool to define an environment containing all the modeling elements and valid relationships that can be constructed in a specific domain [26].

The process for applying MIC is shown in Figure 30-1. The left-hand side of this figure describes the task of creating new modeling environments. From meta-level specifications, new modeling environments are generated using meta-level translators. (Note that this process is self-descriptivethe meta-level specifications are also created with the GME.) These meta-level specifications define the domain ontology, the specifications that identify the pertinent entities of the domain, and their related associations.

Figure 30-1. Process for applying model-integrated computing.

After a modeling environment has been generated, a domain expert can create models for the particular domain associated with the environment (see the middle of Figure 30-1). Once a model has been created, it can be processed by domain interpreters, which traverse the internal data structures that represent the model and generate new artifacts. These interpreters can synthesize an application that is customized for a specific execution platform and can generate input to analysis tools. The synthesis/interpretation task is represented by the right-hand side of Figure 30-1.

An example of a meta-model is shown in Figure 30-2. In the GME, a meta-model is described with UML class diagrams and constraints that are specified in the object constraint language (OCL) [48]. At the meta-modeling level, OCL constraints are used to specify the semantics of the domain that cannot be captured with the static relationships defined by a class diagram. The meta-model of Figure 30-2 specifies the entities and relationships among collaborators in a middleware publisher/subscriber service, such as a CORBA event channel [24]. For instance, the meta-model contains the representation of several types of connecting ports, as well as various methods (e.g., call-back or notify) that are needed to realize the event channel. Constraints are not explicitly shown in this screenshot, but an informal example of a constraint for Figure 30-2 would state, "Every data object that is attached to a call-back and compute method must also be associated with a corresponding notify method." The meta-model can itself be interpreted to produce a new modeling environment. In fact, this particular meta-model defines the ontology for the subset of the Bold Stroke [39] avionics models that we present in Section 30.2; that is, Figure 30-6 is an instance of the meta-model of Figure 30-2. The environment generated from this meta-model provides semantic checks to ensure that the constructed models conform to the semantics of the meta-model [43]. Other mature meta-modeling environments include MetaEdit+ [36] and DOME [23]. A similar approach that also uses OCL has been adopted recently in the Kent Modeling Framework (KMF) [6].

Figure 30-2. A GME meta-model for Bold Stroke Avionics Mission Computing.

Figure 30-6. A GME model of the Bold Stroke component interactions.

30.1.2. Crosscutting Concerns in Domain Modeling

A distinguishing feature of AOSD is the notion of crosscutting, which characterizes the phenomenon whereby some representation of a concern is scattered among multiple boundaries of modularity and tangled among many other concerns. Aspect-oriented programming (AOP) languages, such as AspectJ [28], permit the separation of crosscutting concerns into aspects. We have found that the same crosscutting problems that arise in code also exist in domain-specific models [16]. For example, it is often the case that the meta-model forces a specific type of decomposition, such that the same concern is repeatedly applied in many places, usually with slight variations at different nodes in the model (this is a consequence of the "dominant decomposition" [44], which occurs when a primary modularization strategy is selected that subjects other concerns to be described in a non-localized manner).

A concrete example of crosscutting in models is shown in Section 30.2 based on the meta-model in Figure 30-2. An abstract illustration of the effect of crosscutting constraints is presented in Figure 30-3. In this figure, a hierarchical decomposition is evident. This decomposition has forced another concern (represented by the checkered boxes, all pointing toward the existence of a global crosscutting constraint) to be distributed across the hierarchy of the model. This results in much redundancy and replicated structure because the concern is tailored to the context of numerous nodes in the model.

Figure 30-3. Crosscutting constraints in domain-specific modeling.

There are several different types of constraints that may be applied throughout a model. Figure 30-4 shows a set of resource constraints that indicate specific hardware resources needed by software. Several of the models created using the GME tool contain thousands of components, with several layers of hierarchy. In the presence of a dominant decomposition, the constraints of a complex model become tangled throughout the model, which makes them hard to understand. The AODM approach can isolate the crosscutting constraints to modularize these global system properties more effectively.

Figure 30-4. Crosscutting resource constraints.

30.1.3. Model Weavers

Our approach to AODM requires a different type of weaver from those that others have constructed in the past, such as the AspectJ weaver [28], because the type of software artifact processed by our model weaver differs from traditional (programming language) weavers. Programming language weavers support better modularization at a lower level of abstraction by processing source code, but a domain-specific modeling weaver processes the structured description of a visual model. In particular, this new weaver requires the capability of reading a model that has been stored in the Extensible Markup Language (XML). This weaver also requires the features of an enhanced constraint language. The standard OCL is strictly a declarative language for specifying assertions and properties on UML models. Our need to extend the OCL is motivated by the fact that we require an imperative language for describing the actual model transformations. We have created the Constraint Specification Aspect Weaver (C-SAW) to provide support for modularizing crosscutting modeling concerns in the GME (please see the C-SAW web page at http://www.gray-area.org/Research/C-SAW).

Our approach to model weaving involves the following concepts:

Model constraints. This type of constraint appears as attributes of modeling elements. It is these constraints that are traditionally scattered across the model. These constraints are typically represented by a specialized entity in the meta-model, such as the OCLConstraint meta-type in Figure 30-2.

Modeling pointcuts. A modeling pointcut is a new modular construct that specifies crosscutting concerns across a model hierarchy. Each modeling pointcut describes the binding and parameterization of strategies to specific nodes in a model. A modeling pointcut is conceptually similar to a pointcut in AspectJ [28]. Like an AspectJ pointcut designator, a modeling pointcut is responsible for identifying the specific locations of a crosscutting concern and offers the capability to make quantifiable statements across the boundaries of a model [11]. Quantification permits statements such as, "For all the places where properties X, Y, and Z hold, then also make sure that property A and B are also true, but not property C." In the context of modeling pointcuts, the general notion of quantification refers to the ability to make projected assertions and transformations across a space of conceptual representation, such as models or even source code.

Strategies. A strategy is used to specify elements of computation, constraint propagation, and the application of specific properties to the model nodes. (Note: We refer to "model nodes" as being those modeling elements that have a definition in the meta-model and serve as visualization elements in the domain model.) The name "strategy" is inspired by the Strategy design pattern [13]. We use this term to define a collection of interchangeable heuristics. Strategies are generic in the sense that their descriptions are not bound to particular model nodes. Each weaver that supports a specific meta-level GME paradigm has disparate strategies. A strategy provides a hook that the weaver can call to process node-specific constraint application and propagation. Strategies therefore offer numerous ways for instrumenting nodes in the model with crosscutting concerns. Section 30.2.2 provides an example strategy for assigning eager/lazy evaluation within a CORBA event channel.

These three items differ in purpose and in application, yet each is based on the same underlying language. We call this language the embedded constraint language (ECL). The ECL is an extension of the OCL and provides many of the common features of OCL, such as arithmetic operators, logical operators, and operators on collections (e.g., size, forAll, exists, select). However, a unique feature of ECL that is not in OCL is a set of reflective operators for navigating the hierarchical structure of a model. These operators can be applied to first class model objects (e.g., a container model or primitive model element) to obtain information needed in either a strategy or pointcut.

Figure 30-5 shows the use of model weaving with C-SAW. In this figure, the solid arrows represent the output from tools that generate, or transform, a model. The GME can export the contents of a model in the form of an XML document (see step 1 in Figure 30-5; in this case, the exported XML is related to the meta-level paradigm from which the model was constructed, such as the one in Figure 30-2). In our approach, the exported XML representing a model is often devoid of any constraints. The constraints are not present in such cases because they are modularized by the pointcuts and strategies.

Figure 30-5. Process of using a C-SAW model weaver with the GME.

The input to the domain-specific weaver consists of the XML representation of the model, as well as a set of modeling pointcuts provided by the modeler (step 2). In Figure 30-5, these entities are positioned to the left of the domain-specific weaver. The output of the weaving process is a new XML description of the model (step 3). This enhanced model, though, contains new concerns that have been integrated throughout the model by the weaver and that can be reloaded into the GME (step 4).

There are several key benefits of the Aspect-Oriented (AO) approach described previously. For example, consider the case of modeling an embedded system where constraints often have conflicting goals (e.g., latency and resource usage). In a non-AO approach, latency and resource requirements would be scattered and tangled throughout the model. As a result, it would be hard to isolate the effects of latency or resource constraints on the design. However, by using aspects to represent these concerns, designers can apply modeling pointcuts separately to see how the system is affected in each case. In this way, areas of the system that have more difficulty meeting a requirement may be given more relaxed constraints, while the constraints on other parts of the system may be tightened.

In general, AODM enables designers to isolate and study the effects of concerns (such as constraints) across an entire model. This approach is desirable with respect to application-constraint tuning because the separation of concerns provided by the modeling pointcuts improves the modular understanding of the effect of each constraint. The plugging/unplugging of various sets of modeling pointcuts into the model can be described as creating "what if" scenarios. These scenarios help explore constraints that may have conflicting goals. The insertion and removal of design alternatives is analogous to AspectJ's ability to plug/unplug certain aspects into a core piece of Java code [28].

Our previous work [16] investigated the idea of a meta-weaver framework that used generative programming techniques [9] to produce new model weavers based upon the strategies specified for a specific domain. The framework could therefore be instantiated to produce a specific weaver for a particular domain (e.g., avionics) and could also be instantiated with different strategies to generate another weaver for an additional domain (e.g., automotive electronics). The details of the meta-weaver framework are described in Gray et al. [16].