Fig.3.2band then Fig.3.2a, on the contrary, would yield a model in which class
Ais contained in isolation, i.e. not connected to other classes. The reason is that when weaving Fig. 3.2bfirst, there is still no class Ain the base model, which means the pointcut does not match any part of the model, hence there is nothing to weave. Then, in the next step, weaving of Fig.3.2a, classAis woven into the model, without associations.
In graph grammar systems, consistency checking is also an important topic. Given a graphG, two or more grammar rules are conflicting if applying them toG
in different orders leads to different result graphs. If in a graph grammar system the rules are not conflicting, the system is called confluent.
Since we implement our static aspects by graph grammars, the question of consistency between aspects amounts to the confluence of the graph grammar , which can be checked automatically by the tool of AGG. This technique is widely used by static aspect approaches, see [38].
3.5. Discussion
Static aspects are a rather popular way for separation of concerns on the level of software design, proposals presented so far include [2,66,75]. Compared with these approaches, the pointcut language of our approach does not allow quantifi- cation by pattern matching. Instead, we use UML templates to define aspect tem- plates and source out quantification to the binding of the formal parameters. The outsourcing makes the semantics of our static aspects easier to understand, without reducing the expressive power of the language. Selection languages like JPDD [31] can be easily used to select the model elements a formal parameter should be in- stantiated with.
Static aspects are actually model transformations. Consistency checking via automatic confluence checking of the underlying graph grammar system helps the modeler design conflict free aspects [33,74].
On the other hand, static aspects are low level constructs: they define only syn- tactic modifications. The understanding of the weaving result’s semantics requires carefully studying the result model; modeling using static aspects is as error-prone as directly modifying the base model. This can be seen in the following example.
EXAMPLE 3.3 (Modeling the minRt feature of the e-learning example with static aspects). Figure3.5shows a static aspect based implementation of the level selection restrictionminRtof our e-learning system, using Fig.2.3a(p.16) as the base model. For separation of concerns, the required modifications of the base model are defined in two aspects: MinRightGuardmodels mainly how to split the transition fromSelectLeveltoShowQuestioninto two to handle the cases whether the user may or may not change level. In particular, the guard of the transition in the base model is stored in?Gin the pointcut and reused in the advice. An additional stateShowErroris introduced to give an error message. More complex is the aspect
Array, modeling how to introduce an arrayrand a variablecrirto do the counting.
The value ofcriris increased in Right, set to zero in Wrong, where the arrayr is also updated to store the current maximal length of sequential right answers. Note that the transition from SelectLevel to ShowQuestion, already modified once in aspect MinRightGuard, needs modification again, i.e. its effect must be extended by an action to set crirto zero if the user has chosen a new level (cl != l,clis set by an extension of the entry action of SelectLevel). Finally, the transition from
ShowQuestion ShowQuestion ShowError SelectLevel setLevel[?G] SelectLevel setLevel [else] «aspect» MinRightGuard «transformation pointcut» «transformation advice»
setLevel [?G && l == 0 || r[l−1] >= minRight]
(a) Splitting the transition fromSelectLevelto ShowQuestioninto two
do / r[l] == max(r[l], crir); Wrong crir = 0 ShowQuestion ShowQuestion Wrong Right entry / cl = l; ?Z SelectLevel newLevel / r[l] = max(r[l], crir) setLevel[?G] / ?A; if (cl != l) crir = 0
newLevel setLevel[?G] / ?A «aspect» Array «transformation pointcut» «transformation advice» SelectLevel do / crir ++ Right entry / ?Z
(b) Implementing the array to count the current num- ber of right answers in a row
Figure 3.5: Example: static aspects modeling the minRtfeature of the e-learning system
ShowQuestionmust also extend its action to setr[l], otherwise this modeling would
exhibit the same mistake as the one in Fig.2.3b.
This example reveals some of the reasons why static aspects are sometimes suboptimal
• Static aspects are less declarative than imperative. It is seldom possible for the modeler to define what the desired semantics of the system is. He often has to define in every little detail how to do it. In the above example, instead of just saying “allow change to levell+ 1 only when
minRightright answers in a row on levell”, we have to define in Fig.3.5
how the elements of the base model should be modified.
• In the first place, it is the syntax that is modified by static aspects. The modification of the semantics is not directly defined. For example, the behavior of the result model of weaving Fig.3.5to Fig.2.3ais everything but intuitive.
• Since the modeler has to implement everything imperatively, modeling with static aspects is also error-prone. In Fig.3.5, it is the modeler who has to pay attention not to forget to extend the effects of the transition
fromShowQuestiontoSelectLevel. Otherwise this aspect would be just
as erroneous as Fig.2.3b.
Therefore, static aspects do not provide a totally satisfactory answer to the problems of the UML state machines discussed in Sect. 2.2. What we need is an approach of high level, i.e. declarative, behavioral aspects. HILA is such an approach, as will be shown in the following chapters.