Section 30.2. EXAMPLE: MODEL WEAVING OF EAGER-LAZY EVALUATION CONSTRAINTS

30.2. EXAMPLE: MODEL WEAVING OF EAGER-LAZY EVALUATION CONSTRAINTS

The point of time at which the resources are acquired can be configured using different strategies. The strategies should take into account different factors, such as when the resources will be actually used, the number of resources, their dependencies, and how long it takes to acquire the resources. Regardless of what strategy is used, the goal is to ensure that the resources are acquired and available before they are actually used

Michael Kircher [ 29].

This section introduces a modeling domain and an example to explain the process of model weaving with C-SAW. Section 30.3 expands on this example by presenting an approach for generating AspectJ code from models.

30.2.1. Modeling Bold Stroke Components in GME

Boeing's Bold Stroke project [39] uses COTS hardware and middleware to produce non-proprietary, standards-based component architecture for avionics mission computing capabilities, such as heads-up display, navigation, data link management, and weapons control. A driving objective of Bold Stroke is to support reusable product-line applications [8], leading to a highly configurable application component model and supporting middleware services. There have been efforts within the DARPA MoBIES and PCES programs to model the structure, behavior, and interactions of subsets of applications built from Bold Stroke components. A modeling effort for a subset of Bold Stroke components has been conducted using the GME.

Figure 30-6 represents a simple model that contains five components. All of these components have specified parameters (e.g., frequency, latency, Worst-Case Execution Time (WCET)) that affect end-to-end QoS requirements. The first component is an inertial sensor. This sensor outputs the position and velocity deltas of an aircraft. A second component is a position integrator. It computes the absolute position of the aircraft given the deltas received from the sensor. It must at least match the sensor rate such that there is no data loss. The weapon release component uses the absolute position to determine when to deploy a weapon. A mapping component is responsible for obtaining visual location information based on the absolute position. A map must be constructed such that the current absolute position is at the center of the map. A fifth component is responsible for displaying the map on an output device. The specific values of component properties are likely to differ depending on the type of aircraft represented by the model; for example, the latencies and WCETs for an F-18 are often lower than those of a helicopter. The core modeling components describe a product family with the values for each property indicating the specific characteristics of a member of the family. Gu and Shin provide a more detailed description of WCET within the context of Bold Stroke [20].

The internals of the components in Figure 30-6 permit their realization using the CORBA Component Model (CCM) [40]. The CCM provides capabilities that offer a greater level of reuse and flexibility for developers to deploy standardized components [47]. Each of the components in Figure 30-6 has internal details in support of the CCM that also are modeled. For instance, the contents of the Compute Position component are rendered in Figure 30-7. This figure specifies the interactions of entities within a middleware event channel, such as a call-back function, notification procedure, and local data store (Position). The ports and Receptacle/Facet entities provide the connection points to other components and events.

Figure 30-7. The internals of the Compute Position component.

30.2.1.1 Eager/Lazy Evaluation

In the interactions among the various components in the weapons deployment example, there is a protocol for computing a value and notifying other components of a completed computation. These interactions are the result of a publish/subscribe model that uses the CORBA Event Service, which consists of suppliers who publish events to an event channel that then delivers the events to the appropriate consumers in a timely and reliable manner [21]. The typical scenario for these interactions is:

1. One component (C) receives an event from another component (S), indicating that a new value is available from S.

2. C invokes the get_data() function of S to retrieve the most recent data value from S. C performs a computation based upon the newly retrieved value.

3. C notifies all other components that subscribed to the event published by C.

Because there are situations where early acquisition and computation of data can waste resources, the determination concerning how often a computation should be made is an optimization decision.

• In an eager evaluation, all the steps to perform the computation for a component are done at once. An eager evaluation would follow the three steps listed previously in a strict sequential order (see the top part of Figure 30-8 for a depiction of the eager evaluation protocol) each time an event is received from a supplier component.

  Figure 30-8. Description of eager/lazy strategy.

  
  
  

• A lazy evaluation is less aggressive in computing the most recent value. The second step from the previous list is performed late; that is, the value from the supplier and the actual computation are performed after a client component requests a data value. The computation is therefore performed only when needed, not during each reception of an event from a supplier. The concept of a lazy evaluation is shown in the bottom part of Figure 30-8.

30.2.2. Strategies for Eager/Lazy Evaluation

The manner by which a determination of eager/lazy evaluation is made can be modeled as an aspect. The determination is typically made according to some optimization protocol, which is spread across each component of the model. If it were essential to change properties of the model, it would be necessary to revisit each modeling element and modify the eager/lazy assignment of each node. The dependent nature of the eager/lazy evaluation on properties in the model makes change maintenance a daunting task for non-trivial models.

It would be useful to be able to separate the criteria used to assign an evaluation. Such separation would support changeability and exploration of different protocols. A specific strategy for determining eager/lazy evaluation is given in Listing 30-1. This listing shows how the EagerLazy strategy simply determines the location of the start and end nodes of a range of elements within the model to which the strategy is applied. It also finds the context of folders and models that will be needed during the distribution of the concern. The parameterization of the start and end nodesand also the latency thresholdenables this strategy to be called by a modeling pointcut in numerous ways. This AO design permits the weaving of different constraints into the model in a more efficacious manner by quantifying over the model space and parameterizing the heuristic that is applied. Without such capabilities, a modeler would have to visit every node of the model that is affected by the concern and manually apply the modification.

Listing 30-1. Eager/lazy strategy specified in the ECL

 defines EagerLazy, DetermineLaziness; strategy EagerLazy(EndName          : string;                    latencyThreshold : integer) {   declare components, interactions, startNode,           endNode : node;   components   := findFolder("Components");   interactions := findModel("Interaction");   startNode    := self;   endNode      := components.findModel(EndName);   startNode.DetermineLaziness(components, interactions,                               endNode, latencyThreshold); } strategy DetermineLaziness(components, interactions,                              endNode : node;                            latencyThreshold : integer) {   declare static accumulateLatency : integer;   declare        latency           : integer;   declare        currentID, endID  : string;   if (accumulateLatency < latencyThreshold) then     AddConstraint("EagerLazy", "assignment = lazy");   else     AddConstraint("EagerLazy", "assignment = eager");   endif;   latency           := self.compute.latency;   accumulateLatency := accumulateLatency + latency;   getID(currentID);   endNode.getID(endID);   if(currentID <> endID) then      self.BackFlow(components, interactions, endNode,                    latencyThreshold);   endif; } 

The DetermineLaziness strategy is invoked on the start node (because the strategy works backwards, the start node is actually the node that is nearest to the end of the interaction). This strategy performs a simple computation to determine the evaluation assignment for the current node. The intent of the strategy is to assign a component to an eager evaluation until the latency threshold is exceeded. After the threshold is exceeded, all subsequent components are assigned as lazy. If the current node is not the end node of the interaction, then the strategy named BackFlow is fired (this strategy is not shown in order to conserve space). The BackFlow strategy collects all of the suppliers of the current node (this is done by finding the components that are on the current component's data flow and serve as suppliers) and invokes a continuation on the collection.

A simple modeling pointcut is shown in Listing 30-2. This specification binds the EagerLazy strategy to the data flow path starting with the "InertialSensor" component (the "start" node) and ending with the "LocDisplay" component (the "end" node). The specific parameter for the latency threshold could be changed, which would weave in different constraints into the base model. Of course, the start and end nodes of the data flow can be changed, too. A more complex declaration of the starting and ending node could also be denoted, such as a declaration on properties of the nodes like whether or not a node has a publisher or consumer port.

Listing 30-2. Modeling pointcut for eager/lazy evaluation

 aspect EagerLazyWeaponsComponents {   models("")->select(m | m.name() = "InertialSensor")->                      EagerLazy("LocDisplay", 20); } 

The effect of applying the EagerLazy strategy across the set of modeled components can be seen in Figure 30-9. This figure displays the modifications made to the internals of the Update Map component. The internals of Update Map are similar to those of Compute Position, as shown in Figure 30-7. In this case, a new constraint has been added (called EagerLazy), and the specific value of this constraint is "assignment = Lazy" (this can be seen in the "Constraint Equation" box in the bottom-right of Figure 30-9).

Figure 30-9. Effects of eager/lazy strategy within Update Map component.

For application developers who are creating new instantiations of Bold Stroke, a model-based approach provides a facility for describing component configuration, assembly, and deployment information at higher-levels of abstraction with visual models as an alternative to hand-coded XML representations. Additionally, the availability of model weavers like C-SAW permits the rapid exploration of design alternatives, which are captured in constraints that specify crosscutting global properties of the modeled system.