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
Figure 2. A subset of a model hierarchy with crosscutting model properties. Concerns related to synchronization (red circle), black-box data recording (blue circle), and preconditions (green circle) are scattered across many submodels.
As an alternative to manual evolution, ECL can be used to define an aspect that assists in the automated evolution of the model. For example, to specify that all data2_ atoms must have a precondition defining the valid range of values, the following modeling aspect can be defined:
aspect PreData2()
{
rootFolder().findFolder("ComponentTypes").models()->
select(m|().endWith("Impl"))->AddPre(“data2_”, “Data2Cond”, “value<200”); }
This modeling aspect can be interpreted as, “From the root folder, collect all of the models that are of type ComponentTypes. From this collection, select all of the components whose name ends with ‘Impl’ and apply the AddPre strategy.” In C-SAW, an aspect is applied by traversing a model and matching elements of the model that satisfy a predicate (e.g., the selection predicate in the PreData2 aspect). Those elements that satisfy a given predicate are then transformed according to the rules in the associated strategy. A strategy is a modular construct provided by ECL to define the transformation within a model. Each strategy should be performed in a specific modeling context, which is provided by the aspect. The context of a strategy call can be an entire project; a specific model, atom, or connection; or a collection of assembled modeling elements. Using the ECL, aspects are defined to
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
quantify those modeling elements that are to be changed, and a strategy is applied to perform the required transformation.
The AddPre strategy shown in Listing 1 is applied to each component selected from the PreData2 aspect. This strategy finds all of the atoms in the component that are of type Data which match the name passed in as an argument from the aspect. All of the Data atoms that match this predicate will have a new precondition attached by the AddCond strategy. Line 12 of AddCond retrieves a placeholder for the actual Data that will be transformed. The parent component that contains the Data atom is reflectively obtained in line 13. The transformation sequence defined in lines 15 through 17 creates a new Condition atom (line 15) and sets those attributes defining a precondition with an associated expression (lines 16 and 17). The final task of the AddCond strategy adds a connection to the parent component that links the Data atom to the new Condition.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 strategy AddPre(atomName, condName, condExpr : string) { atoms()->select(a | a.kind() == "Data" and () == atomName)-> AddCond(condName, condExpr); } strategy AddCond(condName, condExpr : string) { declare p : model; declare data, pre : atom; data := self; p := parent(); pre:=p.addAtom("Condition", condName); pre.setAttribute("Kind", "PreCondition"); pre.setAttribute("Expression", condExpr); p.addConnection("AddCondition", pre, data); }
Listing 1. ECL transformation to add a precondition expression to a Data atom.
AUTOMATED MODEL SCALABILITY
A second form of design exploration involves scaling up different parts of a model. Scalability of modeling tools is of utmost concern to designers of large-scale DRE systems. From our personal observation, models can have multiple thousands of coarse grained components (others have reported similar experience, please see [1]). System modeling using traditional manual techniques and tools can approach the limits of the effective capability of humans. The issue of scalability affects the performance of the modeling activity, as well as the correctness of the model representation. Consider a base model consisting of a few modeling elements and their corresponding connections. To scale a base model to hundreds, or even thousands, of duplicated elements would also require a lot of clicking and typing within the associated modeling tool. Furthermore, the tedious nature of manually replicating a base model may also be the source of many errors (e.g., forgetting to make a connection between two replicated modeling elements). A comparison of approaches to support automated model scalability can be found in [9].
Replicating a CORBA Event Channel Model
Figure 3 provides an illustration of scalability applied to the Event QoS Aspect Language (EQAL), which has been used to configure a large collection of federated event channels for mission computing avionics applications (EQAL