Aspect-Oriented Modeling of Adaptive Web Applications
with HiLA
∗
Gefei Zhang
Ludwig-Maximilians-Universität München
gefei.zhang@pst.ifi.lmu.de
ABSTRACT
Modeling adaptivity is a challenging task for two reasons: 1) adaptation is usually strongly interwoven with the general functionality
of the web application, separation of concerns is hard to achieve,
and 2) adaptation rules may be conflicting, i.e., changing and revoking the effect of each other. We propose to use our aspect-oriented
extension of UML state machines, High-level Aspects (HiLA), to
model adaptation rules of web applications. With HiLA, adaptation
rules can be modeled separately from the general functionalities.
We also provide an automatic technique for checking the consistency of the aspects (i.e., the adaptation rules). Therefore, HiLA
provides valuable help for modularly modeling adaptive web applications and keeping the adaptation rules consistent.
1.
INTRODUCTION
Being one of the key instruments to tie the generally a priori unknown users in a highly competitive market, adaptivity is a very
important feature of modern web applications. Modeling adaptation rules elegantly is a highly desirable goal of Web Engineering.
Since adaptation is usually interwoven with general functionalities of the web application, “elegance” is hard to achieve. Instead, model elements concerning adaptation are often entangled
with those concerning general functionalities such as navigation
and presentation, while single model elements are involved in both
general functionalities and adaptation rules. The result are complex
models which are hard to maintain, and prone to errors.
Moreover, complex web applications may be subject to a large
number of adaptation rules, which may be conflicting, i.e., they
may change or even revoke the results of each other. Keeping an
overview over all adaptation rules and determining if any of those
conflicts with another is often a hard job. Automatic detection of
conflicts between adaptation rules would clearly be very desirable.
We propose the use of High-Level Aspects (HiLA, [18, 19]) to
model adaptation rules of web applications. HiLA is an aspectoriented extension of UML state machines, a popular language for
modeling behaviors of software systems. Since state machine are
∗Partially supported by the DFG project M AEWA (WI 841/7–2).
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MoMM2009 December 14–16, Kuala Lumpur, Malaysia.
Copyright 2009 ACM 978–1–60558–659–5/0012 ...$10.00.
deemed to be simple, they are widely used, in particular, to model
web applications. Adaptation rules, however, can be hardly separated from basis functionalities. The complexity of state machines
may increase rapidly when modeling adaptive web applications.
We apply HiLA to a UML state machine (the base machine)
which models the general functionalities of a web application. The
base machine can be constructed by any state machine based web
modeling approaches, such as [5, 9, 11]. Aspects are used to model
adaptation rules, separately from the base machine and separately
from each other. Aspects are then weaved to the base machine,
yielding the complete behavior of the system in the form of another UML state machine. Conflict detection between the rules
then amounts to consistency checking between the aspects, which
(at least partially) can be done automatically in HiLA. This way,
HiLA helps solve both of the two aforementioned difficulties of
modeling adaptive web applications. The wide acceptance of UML
state machines in Web Engineering improves the chance of HiLA
being helpful for a broad community.
The remainder of this paper is organized as follows: the following Sect. 2 shows by means of an example how cumbersome
adaptation modeling can get even for simple systems. After a brief
overview of HiLA given in Sect. 3, Sect. 4 presents how to model
adaptivity rules using HiLA. In Sect. 5 we discuss how to detect
potential conflicts between adaptation rules. Related work is discussed in Sect. 6 before concluding remarks are given in Sect. 7.
2.
EXAMPLE
We use an e-learning system as our running example. The state
machine in Fig. 1, adopted from [19] and slightly modified, models an e-learning system (which is not adaptive). The user can
first select a level (state SelectLevel), and then answer questions
(ShowQuestion) of this level. If an answer is right (Right), he can
proceed to the next question, otherwise he may choose to try again
(event again) or to see the key of the question (key). Instead of answering the question, the user may also choose another level (transition from ShowQuestion to SelectLevel).
The state machine is very simple because the e-learning system
is very simple. As soon as its requirements get complex, the complexity of the state machine increases rapidly.
For example, consider an adaptation rule stating that selection of
a level l > 0 is only allowed when the user has answered minRight
questions on level l − 1 correctly in a row. Note such a feature does
not necessarily require the user to login, www.amazon.com, e.g.,
stores the browsing history of unregistered users, too. Figure 2,
also taken from [19], shows how this restriction might be modeled
in a standard UML state machine: a new attribute variable crir is
introduced for counting the length of the current stroke of correct
answers, it is incremented in state Right and reset to 0 once Wrong
setLevel
SelectLevel
newLevel
exit / l = inputLevel()
ShowQuestion
inputAnswer
[right]
Right
[else]
end
again
Wrong
key
next
ShowKey
next
Figure 1: E-learning system
setLevel [r[l] >= minRight] / if (cl != l) crir = 0
SelectLevel
entry / cl = l
exit / l = inputLevel()
end
newLevel
ShowQuestion
setLevel [else]
inputAnswer
[right]
Right
do / crir ++
[else]
again
ShowError
Wrong
do / r[l] == max(r[l], crir);
crir = 0
key
next
ShowKey
next
Figure 2: E-learning system: level selection restricted (erroneously)
is active. Array r is introduced to store the maximal length of crir at
each level. Once the user gives a wrong answer, the system updates
this record if necessary. In order to know whether the user has
selected in SelectLevel a different level than the current one or just
continues with the same level, another new variable cl stores the
current level each time SelectLevel is entered. The transition from
SelectLevel to ShowQuestion is split into two to handle the cases
whether the level inputted by the user is selectable or not. Finally,
the variable crir has to be reset to 0 when the user has successfully
changed to another level. Obviously, it is unsatisfactory that the
model elements involved in this one, rather simple adaptation rule
are scattered all over the state machine, switching the feature on and
off is difficult and requires modifications all over the state machine.
Not bad enough? Well, this solution is wrong! Suppose the user
selects a new level l, r[l] still has the default value 0. Then the user
answers minRight times correctly, and proceeds to choosing level
l + 1 without answering a question wrong. Since Wrong has not
been active, array r is not updated. Consequently, upon setLevel, the
value of r[l] ≥ minRight is false, the transition therefore disabled.
The mistake is that r[l] must be updated both in state Wrong and
on the transition from ShowQuestion to SelectLevel. This mistake
was not discovered until we model checked Fig. 2 using the tool
Hugo/RT [8], six months after the publication of [19].
3.
HILA IN A NUTSHELL
Insufficient separation of concerns as exhibited by the above example is an inherent weakness of UML state machines. The language High-Level Aspects (HiLA), an aspect-oriented extension of
UML state machines, was defined in [19] to address this problem.
In HiLA, an aspect is a graphical specification of an additional or
alternative behavior of a UML state machine (base machine), to be
executed at certain points of time in the base machine’s execution.
These points of time are when a transition is being fired while certain states are active, or if firing the transition would make certain
«history»
hs1 = # Pattern1
hs2 = # Pattern2
«aspect»
Name
«pointcut»
selector
State*
{xor}
ST*
{Constraint}
«advice»
AdvBody
Label 1
Label 2
Label 3
Figure 3: Concrete syntax of aspects
states active. The transitions are specified by the pointcut of the
aspect, the behavior to execute by its advice. We say the aspect
advises the transitions selected by the pointcut. The advice of an
aspect is also a state machine, except that its final states may be
labeled. When a transition which is advised by an aspect is taken,
the advice of that aspect is executed; when the advice state machine
finishes, execution of the base machine is resumed with a transition
from the advice to the target state of the advised transition.
The concrete syntax of HiLA aspects is shown in Fig. 3, the
oblique identifiers being place holders. With State* a set of states is
specified. The selector may be either «before» or «after». A pointcut labeled «after» selects all transitions leaving any state in State*
while the base machine is in an active state configuration1 containing all states in State*. A pointcut labeled «before» selects each
transition T in such active state configurations that after taking T
all states in State* will become active. Alternatively, the selector
1
In general, UML state machines contain several concurrent regions. At a given point of time in the execution, there is always one
state active in each region. The set of the active states is called the
active state configuration. The execution of a UML state machine
can be viewed as its active state configuration changing over time.
«aspect»
RightInARow
«pointcut»
«history»
a(l) = #
Right
Wrong
«aspect»
TooManyRights
[minRight..*]
[0]
«advice»
«pointcut»
«history»
SelectLevel
{l > 0}
ShowQuestion
[(a(l−1)) > 0]
r(l) = #
1
[else]
ShowError
goto
SelectLevel
«before»
Right
qs(l) = # ShowQuestion
ShowQuestion
«advice»
[qs(l) >= minQuestion
&& r >= qs(l)*quota]
[else]
1
Figure 4: Aspect for level restriction
ShowError
goto SelectLevel
may be empty and a set of states and transitions ST* may be specified. In this case the pointcut matches all transitions in ST* into
active state configurations in which all states in ST* are active. The
pointcut may also contain a constraint. In this case, the advice is
only executed when the constraint is satisfied.
The labels of the final states in an advice are used to specify the
state configuration to activate when the advice’s execution is finished. In particular, label 1 means the base machine should resume
at the target of the advised transition. A label of the form goto X
indicates the base machine to go to an arbitrary state X. For other
labels, see [17]. In Fig. 3 three resumption strategies are defined.
Depending on the execution of AdvBody, one of them will be used.
Moreover, an aspect may contain optional history properties in
its «history» compartment, see Fig. 3. A history property contains
a pattern consisting of active state configurations and constraints,
and its value is the number of matches of this pattern by the base
machine’s execution history where the constraints evaluate to true.
Fig. 3 shows two history properties, hs1 and hs2. Property can be
used in pointcuts and advices to define history-sensitive behavior.
4.
MODELING ADAPTIVE WEB APPLICATIONS WITH HILA
HiLA helps separate cross-cutting concerns of UML state machines. Since adaptivity is in general such a concern, HiLA helps
modeling adaptivity separately from the main functionality model
(the base model). We assume a state machine as our base model,
and call it also base machine. This machine can be obtained using common engineering methods, which model web applications
with state machines, including [5, 9, 11]. In the following, we use
Fig. 1 as our base machine, and enrich this application by adaptation rules. The aspects we are going to define will show how
HiLA keeps adaptation modeling separate from the base machine,
and thus reduces the complexity of the overall design.
1. Selection of a level l > 1 is only allowed when the user has
answered minRight questions on level l−1 correctly in a row.
While being hard to model in UML, this rule can be easily modeled in HiLA, see Fig. 4: the history property a counts for each
value of parameter l how often (operator #) the pattern on the right
hand side is matched by the execution history. The pattern contains
two states, each associated with a multiplicity. It is matched by
any subsequence of the execution history in which state Right has
been active at least minRight times (multiplicity [minRight..*]) and
in which state Wrong has not been active ([0]).
The pointcut contains two states and a transition. It selects therefore the points of time just before the transition is fired, provided
that the constraint l > 0 is true. In such moments, the execution of the transition is interrupted, and the advice executed. If
the value of a(l-1) is greater than 0, then such a sequence could be
Figure 5: Aspect to avoid too many Rights
found on the level l − 1, i.e. the user did answer minRight questions correctly without being interrupted by answering any question wrong. In this case, the advised transition is resumed (final
state labeled 1), otherwise an error message is shown, and the state
machine resumes by activating the state SelectLevel (final state labeled goto SelectLevel). This way, the level restriction rule is modeled separately from the base machine, without invasive and pervasive modification of the latter. More importantly, “monitoring” the
Right sequences is now modeled declaratively. It is only necessary
to define what to do, i.e., the system should count the number of
right answers in a row. How this should be done, on the contrary,
no longer needs to be specified. Compared with the UML solution,
the HiLA solution is thus much less likely to be erroneous.
2. When the user has mastered a level, i.e., when he has answered at least minQuestion questions and achieved a Right
rate of quota, then no other question on this level is allowed.
This adaptation rule is intended to increase the challenge factor
of the system. Figure 5 shows how it is modeled in HiLA: two
history properties qs and r are defined, which count for each level
l how often states ShowQuestion and Right have been active in the
execution history, respectively. The pointcut specifies the points
of time just before (stereotype «before») state ShowQuestion gets
active, i.e., just before a new question is to be displayed.
The advice then checks if the user has answered enough questions on this level (qs(l) >= minQuestion) with “too many” right
answers (r >= qs(l)*quota). If this is not the case, the interrupted
transition is continued (1), otherwise an error message is shown,
and the base machine resumes at SelectLevel, the state indicated by
the label of the final state, to ask the user to select another level.
Again, HiLA allows the adaptation rule to be modeled separately
and declaratively.
3. When the user is beginning a “winning series” of at least 5
questions, a congratulation message should be shown.
We model this feature with an after aspect, as shown in Fig. 6.
The symbol ⊥ in the pattern of the history property s is matched
by the end of the execution history. The arrow → means “directly
followed by”. The whole pattern is therefore matched by the most
recent state configurations of the history if they start with a Wrong,
followed by five consecutive Rights. Every time after («after»)
state Right has been active, the advice is executed: if there is one
match of the pattern, then the congratulation message is shown,
and the base machine is instructed to proceed to the next question
(goto ShowQuestion). Otherwise the advise does not do anything
but simply terminates.
«aspect»
Congratulation
«pointcut»
«history»
s(l) = #
Transition
SelectLevel → ShowQuestion
«after»
Fig. 5
Right
Right
[5]
⊥
Wrong
Wrong
«advice»
[(s(l)) == 0]
[0]
Fig. 5
Wrong → ShowQuestion
ShowKey → ShowQuestion
Fig. 6
Fig. 5
Fig. 5
1
Aspect
Advising
RightInARow (Fig. 4)
TooManyRights (Fig. 5)
SelectLevel → ShowQuestion
SelectLevel → ShowQuestion
Right → ShowQuestion
Wrong → ShowQuestion
ShowKey → ShowQuestion
Right → ShowQuestion
Figure 7: Aspects and advised transitions
CONFLICT HANDLING
Modern web applications are often subject to a multitude of adaptation rules. The rules may be conflicting, i.e., they may change or
revoke the effect of each other. Automated consistency checking of
the rules would be therefore very desirable. Since in HiLA adaptation rules are modeled in separate aspects, consistency checking
of rules amounts to consistency checking of aspects. While this
problem is generally undecidable, HiLA provides a methodology
to detect potential conflicts caused by different resumption strategies of aspects.
If a transition is advised by two or more aspects, it is possible
that different goto targets are set by different aspects. In the realm
of web applications this means that different results of navigation
adaptation are imposed by different rules. This kind of conflicts of
HiLA aspects can be detected automatically in three steps.
1. List all aspects and the transitions advised by the aspects.
The purpose of this step is to determine all transitions that are
subject to some aspect. Obviously, a «before» aspect advises all
transitions leading to each state contained in the pointcut; an «after»
aspect advises all transitions leaving the states contained in the
pointcut; a transition aspect (like Fig. 4) advises the transition specified in the pointcut. For our e-learning example, we obtain the
table in Fig. 7.
2. Determine for each advised transition the advising aspects.
If a transition is advised by multiple advises, list all labels of
the final states in the advice.
The purpose of this step is to create a table where transitions, that
are advised by multiple aspects, can be easily determined. We omit
the non-advised transitions, and build a “reverse” table of the last
step. The result in the e-learning example is given in Fig. 8. Note
it is not necessary to include the labels of an aspect if it is the only
aspect advising a transition, for conflicts of resumption strategies
are not possible when a transition is advised by only one aspect.
Note also that we resolve keyword 1, and replace it by the target of
the transition.
Label
SelectLevel
ShowQuestion
SelectLevel
ShowQuestion
ShowQuestion
SelectLevel
ShowQuestion
—
—
Figure 8: Transitions and advising aspects
Figure 6: Aspect for showing congratulation message
Congratulation (Fig. 6)
Right → ShowQuestion
[else]
Congratulation
5.
Advised by
Fig. 4
3. If a transition is advised by multiple aspects, and the different aspects can use different resumption strategies, then
there is a possible conflict, and the modeler should examine
the corresponding adaptation rules to resolve the conflict if
necessary. Otherwise we can be sure that our model is free
of resumption strategy conflicts.
According to Fig. 8, the transitions from Wrong and ShowKey to
ShowQuestion are advised by only one aspect. They are therefore
clearly free of resumption conflict. On the contrary, the transition
from Right to ShowQuestion is advised by two aspects. It is possible that the execution of one of the aspects finishes at a final state
labeled SelectLevel, and the other finishes at a final state labeled
ShowQuestion.
This is where the modeler should examine the rules modeled
by these two aspects. The aspect Congratulation in Fig. 6 defines
only an additional behavior. It is only important that this behavior gets executed, rather than a special resumption strategy being
followed. Therefore we decide to assign its “concurrent aspect”
TooManyRights (Fig. 5) a higher priority, i.e., in case of conflict, the
resumption label taken by TooManyRights is used, independently of
the label taken by Congratulation.
The most complex case in this example is the transition from
SelectLevel to ShowQuestion. This transition is advised by two aspects, both of which can take two different labels. Clearly, this is
also a potential conflict, since one aspect may require the base machine to resume at SelectLevel while the other says ShowQuestion.
This potential conflict is caused by unter-specification of the requirements: while two rules are defined for restriction of level selection, their relation to each other is not specified. That is, it is not
specified what to do if, given a certain execution history, one of the
two rules allows selecting a certain level but the other forbids it. We
suppose that the two rules are both “important”, i.e., selection of a
level l is only allowed when the user has performed well enough on
level l − 1 and not “too well” on level l. This can be easily modeled
by modifying the advice in Fig. 4 to take into account r and qs in
Fig. 5 as well.
6.
RELATED WORK
Adaptivity has been recognized as a key instrument of custom
tieing of web applications and has been an important part of Web
Engineering research. Consequently, engineering methods for adaptive web applications are provided by a large number of web engineering approaches, such as OO-H [6], WSDM [1], UWE [10],
OOHDM/SHDM [12], Hera [2], and WebML [3]. More details
are given in [14]. We point out that UML state machines are also
used by Dolog [5], and Aspect-Oriented Modeling by UWE [10],
Hera [2] and Schauerhuber [13]. Moreover, our aspects using history properties are reminiscent of the Event-Condition-Action rules
used in WebML, WSDM, and OO-H, see also [14].
As opposed to the above approaches, HiLA is the only approach
which supports consistency checking of the adaptation rules. In
fact, this topic seems to be surprisingly little investigated, the only
publication to our knowledge being [16], where conservative conditions of potential conflicts are also given. In comparison to HiLA,
this approach defines “only” a reference model rather than a graphical modeling language. Moreover, the result of weaving HiLA
aspects to the base machine is also a UML state machine (due to
space limitation not shown in this paper), which can be verified using formal analysis, such as theorem proving or model checking.
An example of model checking the weaving result of HiLA aspects
is given in [7]. This provides valuable support to find modeling
mistakes in an early step of the software development process.
Compared with other Aspect-Oriented Modeling approach, such
as [4, 15, 20], HiLA is a high-level approach: it is only necessary
to specify what to do if what happens (see our history properties)
rather than how to achieve it.
7.
CONCLUSIONS AND FUTURE WORK
We presented how the language HiLA can be used to model
adaptation rules in web applications. HiLA enables separating adaptation rules from the base model, and increases the modularity and
maintainability of the models, and reduces their error-proness. We
also provided an automatic method for checking potential conflicts
between the rules as well as guidelines for conflict handling.
HiLA was defined as a general extension of UML state machines. It increases generally the modularity of UML state machines. Its applicability is not limited to Web Engineering only.
Examples of applying HiLA to the development of crisis management systems and computer games are given in [7, 18]. The usefulness of HiLA in Web Engineering is given by that of UML state
machines: wherever these are applied in this area (and they are indeed widely applied), chances are that HiLA can help improve the
modularity of the models. While the examples in this paper concern navigation adaptation only, HiLA is expected to be also useful
for the modeling of content and presentation adaptation, provided
these are modeled in the base machine.
Future work includes the investigation of less conservative consistency checking and a graphical modeling tool for HiLA.
8.
REFERENCES
[1] S. Casteleyn. Designer Specified Self Re-organizing
Websites. PhD thesis, Vrije Universiteit Brussel, 2005.
[2] S. Casteleyn, Z. Fiala, G.-J. Houben, and K. van der Sluijs.
Considering Additional Adaptation Concerns in the Design
of Web Applications. In V. P. Wade, H. Ashman, and
B. Smyth, editors, Proc. 4th Int. Conf. Adaptive Hypermedia
and Adaptive Web-Based Systems (AH’06), volume 4018 of
Lect. Notes Comp. Sci., pages 254–258. Springer, 2006.
[3] S. Ceri, F. Daniel, F. M. Facca, and M. Matera. Model-driven
Development of Context-Aware Web Applications. ACM
Trans. Internet Technology, 7(2):1–32, 2007.
[4] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and
Design. Addison-Wesley, 2005.
[5] P. Dolog. Engineering Adaptive Web Applications. PhD
thesis, Universität Hannover, 2006.
[6] I. Garrigós, S. Meliá, and S. Casteleyn. Adapting the
Presentation Layer in Rich Internet Applications. In
M. Gaedke, M. Grossniklaus, and O. Díaz, editors, Proc. 9th
Int. Conf. Web Engineering (ICWE’09), volume 5648 of
Lect. Notes Comp. Sci., pages 292–299. Springer, 2009.
[7] M. Hölzl, A. Knapp, and G. Zhang. Modeling the Crisis
Management System Using HiLA. 2009. Submitted.
[8] A. Knapp, S. Merz, and C. Rauh. Model Checking Timed
UML State Machines and Collaborations. In W. Damm and
E. R. Olderog, editors, Proc. 7th Int. Symp. Formal
Techniques in Real-Time and Fault Tolerant Systems, volume
2469 of Lect. Notes Comp. Sci., pages 395–416. Springer,
2002.
[9] A. Knapp and G. Zhang. Model Transformations for
Integrating and Validating Web Application Models. In H. C.
Mayr and R. Breu, editors, Proc. Modellierung 2006
(MOD’06), volume P-82 of Lect. Notes Informatics, pages
115–128. Gesellschaft für Informatik, 2006.
[10] N. Koch, A. Knapp, G. Zhang, and H. Baumeister.
UML-Based Web Engineering: An Approach Based on
Standards. In L. Olsina, O. Pastor, G. Rossi, and D. Schwabe,
editors, Web Engineering: Modelling and Implementing Web
Applications, volume 12 of Human-Computer Interaction
Series, chapter 7, pages 157–191. Springer-Verlag, 2007.
[11] S. Meliá, J. Gómez, S. Pérez, and O. Díaz. A Model-Driven
Development for GWT-Based Rich Internet Applications
with OOH4RIA. In Proc. 8th Int. Conf. Web Engineering
(ICWE’08), pages 13–23. IEEE, 2008.
[12] G. Rossi, D. Schwabe, and R. Guimarães. Designing
Personalized Web Applications. In Proc. 10th Int. Conf.
World Wide Web (WWW’01), pages 275–284. ACM, 2001.
[13] A. Schauerhuber. aspectUWA: Applying Aspect-Orientation
to the Model-Driven Development of Ubiquitous Web
Applications. PhD thesis, Technische Universität Wien,
2007.
[14] W. Schwinger, W. Retschitzegger, A. Schauerhuber,
G. Kappel, M. Wimmer, B. Pröll, C. C. Castro, S. Casteleyn,
O. De Troyer, P. Fraternali, I. Garrigos, F. Garzotto,
A. Ginige, G.-J. Houben, N. Koch, N. Moreno, O. Pastor,
P. Paolini, V. P. Ferragud, G. Rossi, D. Schwabe, M. Tisi,
A. Vallecillo, K. van der Sluijs, and G. Zhang. A Survey on
Web Modeling Approaches for Ubiquitous Web
Applications. Int. J. Web Information Systems (IJWIS),
4(3):234–305, 2008.
[15] J. Whittle and P. K. Jayaraman. MATA: A Tool for
Aspect-Oriented Modeling based on Graph Transformation.
In Proc. 11th Int. Wsh. Aspect-Oriented Modeling
(AOM@MoDELS’07), 2007.
[16] H. Wu. A Reference Architecture for Adaptive Hypermedia
Applications. PhD thesis, Technische Universiteit
Eindhoven, 2002.
[17] G. Zhang. Aspect-Orientd State Machines. PhD thesis,
Ludwig-Maximilians-Universität München, 2010. In
preparation.
[18] G. Zhang and M. Hölzl. HiLA: High-Level Aspects for UML
State Machines. In Proc. 14th Int. Wsh. Aspect-Oriented
Modeling (AOM@MoDELS’09), 2009.
[19] G. Zhang, M. Hölzl, and A. Knapp. Enhancing UML State
Machines with Aspects. In G. Engels, B. Opdyke, D. C.
Schmidt, and F. Weil, editors, Proc. 10th Int. Conf. Model
Driven Engineering Languages and Systems (MoDELS’07),
volume 4735 of Lect. Notes Comp. Sci., pages 529–543.
Springer, 2007.
[20] J. Zhang, T. Cottenier, A. van den Berg, and J. Gray. Aspect
Composition in the Motorola Aspect-Oriented Modeling
Weaver. J. Object Technology, 6(7):89–108, 2007.