Constraint-Based Embedded Program Composition

This project is a DARPA/IXO-funded research effort


Project Description | Downloads | PCES Presentations | Publications | People | Links


Project Synopsis

This representation and analysis project is investigating the combination of model-integrated computing and aspect-oriented programming composition technologies to develop 1) a domain-specific, graphical language that captures the functional design of real-time embedded systems, 2) a weaving process that maps high-level invariant properties and system requirements to design constraints affecting specific program regions, and 3) a generation process that customizes components and composes real-time embedded systems. These technologies and tools are being demonstrated in the Boeing Bold Stroke OEP, where they are used to automatically initialize and configure avionics mission computing components that are customized for particular mission needs, and in the BBN UAV OEP, where the tools are used to synthesize CDL/QDL specifications, customizing the quality adaptive behavior of multi-media streaming applications. If successful, this project will help produce domain-specific and even application-specific modeling tools that will enable DoD systems engineers to configure, analyze, and validate complex real-time embedded systems in a more intuitive manner.

Project Description


The main goal of this project is to demonstrate the synergy of model-integrated computing (MIC) with the ideas from Aspect-Oriented Programming (AOP). In particular, the concepts of aspect-orientation will be applied at a higher level of abstraction - at the modeling level. An additional goal is to develop a framework for building weavers.

The motivation for the project stems from difficulties encountered when trying to specify the constraints for a model-based system. It became apparent that constraints cross-cut the model. A solution that isolates the constraints as a separate area of concern will improve the manageability of such models.


Under a prior project, we created a development environment for specification, simulation, and synthesis of dynamic, real-time embedded systems. A system's requirements, algorithms, resources, and behavior is captured as a 'design-space,' representing a multitude of alternative system implementations.  An integrated  language allows specification of design constraints as components within a set of hierarchical, multiple aspect models.


Figure 1

A drawback of our current approach can be seen in the sprinkling of many constraints throughout various levels of our model. It is difficult to maintain and reason about the effect and purpose of constraints when they are scattered about. Managing these distributed constraints becomes extremely difficult as system sizes increase (see Figure 1, where models are represented by the black circles and the replicated constraints are red blocks). Also, experimenting with different architectures, synchronization methods, network protocols, etc., becomes error-prone and labor intensive. We need a mechanism to separate out this concern. Our goal is to be able to specify global constraints at a particular level in the model and have that constraint automatically propagated down to the sub-objects (in this case a sub-object represents aggregation, not inheritance).


Handling Crosscutting Constraints

To solve these problems, we require a consistent, powerful way of specifying constraints and automatically weaving these into the target system designs. Aspect-oriented approaches can be applied to create system-wide constraint languages and methods for distributing and applying user-defined, embedded system, real-time constraints.

The manner in which our weaver is used is illustrated in Figure 2. The GME can export the contents of a model in the form of an XML document. In our former approach, the generated XML would be tangled with constraints throughout the document. Under our new approach, however, it may be quite possible that the exported XML is void of any constraint. The weaver is assigned the job os spreading the constraints throughout the model.

In the figure below, the input to the domain specific weaver consists of the XML representation of the model, as well as a set of specification aspects provided by the modeler. Specification aspects are similar to pointcuts in AspectJ in the sense that the define specific locations in the model where a particular constraint is to be applied. The output of the weaving process is a new description of the model in XML. This enhanced model, though, contains new constraints that have been integrated throughout the model by the weaver.

Figure 2

The requirements for our new approach necessitate a different type of weaver from those that others have constructed in the past. A new weaver is desired that will allow propagation of constraints to sub-objects. As the weaver visits a particular node in the object graph, it must know how to diffuse that constraint to its underlings. Depending on the type of node, the diffusion process may be performed in different ways. To provide the weaver with the needed information to perform the propagation, a new type of aspect is needed. We call this a “strategy aspect.”  Strategy aspects are specified independently of any particular model and are joined to the object graph by the weaver.

The intent of a strategy aspect is to provide a hook that the weaver may call in order to process the node-specific constraint propagations. Strategy aspects must be weaved prior to the weaving of constraint aspects. As the weaver visits each object node during constraint weaving, it may call upon the strategy aspect to aid in applying the constraint to that object. Thus, strategy aspects provide numerous ways for instrumenting object nodes in the object graph with constraints. An important design goal of this aspect language will be to decouple the strategy aspects from the constraint aspects. For more information on the specifics of this approach, please see our Communications of the ACM paper below.

Synthesizing Customized Components

We are also working on techniques to generate customized CORBA Component Model (CCM) components and containers. This generation will be driven by specific QoS properties that are provided from the higher-level specifications.

This work will provide a way to represent component functionality, along with system requirements, in a behavior/runtime-neutral way. The functional components will then be composed by generating the component wrappers with the behavior required to meet the QoS specifications.



    Click here to download the most recent AQME paradigm, sample models, and documentation...

    The GME can be obtained by clicking here.


PCES Presentations







Last update: 06/12/02