ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

Ella Roubtsova

Open University of the Netherlands, the Netherlands

Munich University of Applied Science, Germany

ella.roubtsova@ou.nl

ella.roubtsova@hm.edu

Keywords:

Separation of concerns, Behaviour models, Semantics, Composition techniques.

Abstract:

Model-driven software engineering community faces the problems related to the growing complexity of system

models and their rapid evolution. These problems are similar to the problems of programming. Driven by the

ideas of Aspect-Oriented Programming many modelling techniques were revised in attempts to ﬁnd their ways

to deal with model complexity and evolution. This paper presents an analysis of existing semantic groups of

modelling approaches, their goals, pros and cons, advantages and restrictions. It is aimed to show the deep

reason of the fact that particular composition semantics combined with the elegant idea of aspect weaving

leads to heavy veriﬁcation procedures after any change in the AOM model. This analysis reveals the elements

of modelling semantics that simplify the veriﬁcation procedures in AOM.

1 INTRODUCTION

Model-driven software engineering community faces

the problems related to the growing complexity of

system models and their rapid evolution. The an-

alysts (Chwif et al., 2000) name many reasons for

model complexity starting from the “show off” fac-

tor, the “possibility” to execute complex model on

powerful computers and ending with the “lack of un-

derstanding of the real system” and “unclear mod-

elling objectives”. Although it is universally acknowl-

edged that the simplest model is the most beautiful

one (Robinson, 1994), there are inescapable reasons

for model complexity. The modelled system cov-

ers several interfering and non-localizable problem

frames (Jackson, 2005) and the validity and complete-

ness of the model may depend on the coverage of rel-

evant problem frames.

The non-localizable problem frames in models

are often called aspects following the terminology

of Aspect-Oriented Programming (AOP). The mod-

elling approaches that have the goal to separate as-

pects in models and then compose them into the com-

plete model or produce the behaviour of the complete

model, form the research area called Aspect-Oriented

Modelling (AOM).

This paper presents a survey of existing semantic

groups of aspect-oriented approaches to identify and

explain their goals, abilities and restrictions. There

are many AOM surveys, for example (Reina et al.,

2004), (Chitchyan et al., 2005), (Op de beeck et al.,

2006), (Reddy et al., 2006) and (Schauerhuber et al.,

2007). These surveys mostly analyze the UML-based

approaches. The deviations of semantics is not the

point of attention. The criteria of comparison are of-

ten of practical nature such as the position of the ap-

proach within the full life cycle, evaluation of gran-

ularity and scalability. The aim of this paper is dif-

ferent. It is aimed to show the deep reason of the

fact that particular composition semantics combined

with the elegant idea of aspect weaving leads to heavy

veriﬁcation procedures after any change in the AOM

model. This analysis reveals the elements of mod-

elling semantics that simplify the veriﬁcation proce-

dures in AOM.

The reminder of the paper is the following. Sec-

tion 2 brieﬂy presents the achievements of AOP.

Section 3 observes the semantic groups of Aspect-

Oriented Modelling approaches on the basis of the

used composition techniques and explains the appli-

cability and restrictions, PROS and CONS of those

groups of AOM approaches. Section 4 draws conclu-

sions and identiﬁes the semantic elements that pro-

vide the necessary ﬂexibility and may result in a

breakthrough in the line of heavy design approaches.

Roubtsova E.

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED.

DOI: 10.5220/0004458100130024

In Proceedings of the First International Symposium on Business Modeling and Software Design (BMSD 2011) , pages 13-24

ISBN: 978-989-8425-68-3

2 ACHIEVEMENTS OF AOP

It was recognized by (Cardone and Lin, 2004) that

the difﬁculties with separation of concerns in AOP

were caused by the composition support of the main-

stream object-oriented programming languages that

“restricted to single inheritance and subtype polymor-

phism”. For example, there are three possible ways

to organize two features A and B. into classes: (1)

put them in the same class, (2) make A a subclass of

B, (3) make B a subclass of A. The ﬁrst two choices

force B to be included whenever A is included. By

forcing to choose a single ﬁxed hierarchy orthogonal

composition of features is restricted. “As the number

of features grows, this problem becomes more severe,

because the number of possible feature combinations

grows rapidly, but the number of feature combinations

that can be practically supported does not”.

In order to solve this problem, Aspect-Oriented

Programming (AOP) invented a modular unit called

aspect to implement a crosscutting concern. This unit

contains an advice in form of a code presenting a

concern and pointcut designators being the instruc-

tions on where, when and how to invoke the advice.

The well deﬁned places in the structure of a program

where an advice should be attached were named join

points. The join point model, using method calls as

join points, were generally accepted (Filman et al.,

2004) and implemented as extensions of program-

ming languages. Such extensions gave a new task for

compilers to produce the code with hard woven as-

pects. Another branch of AOP developed middleware

able to fulﬁl run-time aspect composition without pro-

ducing the code of the complete program.

The base programs used for weaving aspects

are designed to be oblivious (Filman and Friedman,

2004) to aspects. The advantage of this feature is

that ”Concerns are separated not only in the struc-

ture of the program but also in heads of their cre-

ators”. The disadvantage is that the systems ”melded

from separate minds” can only function if the proper-

ties of aspects are preserved in the composed system.

This preservation has not been achieved in AOP, al-

though this is an active research area (Kiczales and

Mezini, 2005). Current AOP techniques allow pro-

ducing spectative, regulative and invasive categories

of aspect (Katz, 2006). Spectative aspect can change

the values of variables local to the aspect, but can’t

change the value of any variable of other aspects and

the ﬂow of method calls. Regulative aspects affect

the ﬂow of control by restricting operations, delay-

ing, or preventing the continuation of a computation.

Invasive aspects change the values of variables in the

underlying program. In case of invasive aspects no

guaranty can be given about preserving of dynamic

properties of the underlying program.

3 AOM AND MODELLING

SEMANTICS

The complexity problems caused by the non-

localizable overlapping concerns was identiﬁed in

AOP and AOM was trying to map the ﬁndings of AOP

on models and understand the borders of application

of the AOP solutions. The AOM started with mod-

elling and analysis of AOP programs. The next step

was to evaluate the ability of existing modelling tech-

niques to capture aspects and compose them. This re-

search activity resulted in two streams of approaches.

The dominant stream localizes concerns at the mod-

elling level but do not simplify model analysis. There

are approaches that also localize reasoning on concern

models about the behaviour of the whole model.

3.1 Revision of Sequence Diagrams

The sequence diagrams were the ﬁrst group of mod-

elling notations revised for the AOM purposes.

A set of sequence diagrams with conventional se-

mantics is aimed to present only a part of possible se-

quences of system behaviour. Sequence diagrams are

mostly used to illustrate behaviour of programs and

therefore use operation calls and returns as elements

of behaviour. The composition techniques used in se-

quence diagrams are restricted to sequential composi-

tion, alternatives, cycles and insertion of sequences.

For the AOM needs the conventional sequence

diagrams were extended with Join Point Designa-

tion Diagrams (JPDD) (Stein et al., 2005). An

advice behaviour and the join points of this ad-

vice are speciﬁed with different sequence diagrams.

JPDDs are modelling means to graphically repre-

sent join point queries on sequence diagrams. Fig-

ure 1 borrowed from (Stein and Hanenberg, 2006)

shows the sequence diagrams presenting a join point

and an advice-sequence of an aspect “Access con-

trol policy” that prescribes that the owner manage-

ment data are used to ensure that particular units

(i.e. tasks, contacts, or appointments) are modi-

ﬁed or viewed by their proper owner. The advice

presented with the diagram a f terAdvice DenyAccess

is executed when one of the join points speci-

ﬁed with wildcards move|setProgress|setPriority is

called. The information about the current user is ob-

tained getCurrentUser() and compared with the in-

formation about the owner of the item. If the current

BMSD 2011 - First International Symposium on Business Modeling and Software Design

aspect Authorization(){

pointcut restrictAccess(PIMUnit pimUnit):

(call(* Appointment.move(..)) ||

call(* Task.setProgress(..)) ||

call(* Task.setPriority(..))) && target(pimUnit) &&

if(!pimUnit.getOwner().equals(PIMSystem.getCurrentUser())

|| (PIMSystem.getCurrentUser()== null));

void around(PIMUnit pimUnit) : restrictAccess(pimUnit) {

System.out.println("Access Denied!") ;

}

Figure 1: JPDD model.

user is not the owner currentUser!− <?owner > then

the access is denied.

The sequence diagrams with JPDDs imitate

aspect-oriented programs. The composition of

sequences presenting the base behaviour, advice

and join points is implemented as a compiler task.

As the sequence diagrams are close to the notation

of aspect-oriented languages, the code is generated

from them. As sequence diagrams present partial

behaviour of the system, then result of their composi-

tion is a partial code.

- PROS: The AOM version of sequence diagrams with

JPDDs supports more compact presentation of as-

pects than the conventional sequence diagrams. Mod-

els of join points become reusable artefacts. Ability

to present aspects with sequence diagrams eases evo-

lution of sequence diagrams.

- CONS: Understanding of models and reasoning on

models presented with AOM sequence diagrams with

JPDDs become more difﬁcult than understanding and

reasoning with plain sequences diagrams. It is mostly

because the weaving of aspects should be done in hu-

man heads. However, with tool support, the aspects

are woven into base sequences and presented to the

designers for understanding and linear reasoning.

Although sequence diagrams are found to be very

intuitive means for behaviour modelling, their main

issues still remain. Namely, even in combination

with class diagrams sequence diagrams are not able to

present complete behaviour of complex business sys-

tems having inﬁnite set of traces. Moreover, sequence

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

diagrams with JPDDs use the same composition tech-

niques as the AOP programs and cannot prevent spec-

iﬁcation of invasive aspects, i.e. they cannot prevent

changes of attribute values of one object or aspect by

another aspect.

3.2 Reuse and Revision of Workﬂows

Activity and workﬂow based approaches are aimed to

specify complete system behaviour that can be ana-

lyzed and veriﬁed against required properties. The

workﬂows are often used in AOM approaches as inte-

gration means to combine speciﬁed aspects. There are

also AOM approaches that deﬁne fragments of work-

ﬂows and compose workﬂow fragments into the com-

plete workﬂow.

Workﬂows for Integration. The Theme (Clarke

and Baniassad, 2005) approach is a good example of

the ﬁrst type of workﬂow use. At the level of require-

ments a designer identiﬁes actions as verbs in tex-

tual requirements. Each action potentially becomes

a theme depicted as a rhomb (Figure 2). The ac-

tions have relations via concepts depicted as paral-

lelograms with rounded corners. Actions found in

different themes become potential aspects. An ac-

tion view of each theme is a graph that contains ac-

tions and entities. The size of this view grows with

the number of entities and actions in the model. The

scalability is achieved by the separation of major and

minor actions. “Major actions become themes, while

minor actions are slotted to become methods within

a theme” (Baniassad and Clarke, 2004). This means

that the major actions in the Theme approach are not

elementary, they are activities. The elements of be-

haviour are method calls and returns.

The action view is analyzed to produce the

Theme/UML speciﬁcation of actions-aspects as com-

bination of class and sequence diagrams. The De-

sign level Theme/UML supports modelling of as-

pects in UML. Theme/Doc views are mapped onto

the Theme/UML model allowing traceability of re-

quirements. If a Theme/action is reused in the model,

the join points are speciﬁed in the Theme/UML view.

Figure 2 shows that Themes register and logged iden-

tiﬁed in the workﬂow are speciﬁed as combinations of

class and sequence diagrams called <theme>Register

and <theme>Logger. In this case the methods of

themes register, unregister and give should be spec-

iﬁed as join points of the <theme>Logger.

The action view “drives composition semantics

for design in Theme/UML”. The composition tech-

niques are concatenation and hierarchy of Major

and Minor actions. From the Theme/UML and

Theme/Doc speciﬁcations the corresponding compu-

tation tree can be generated and may be compared

with the workﬂow built at the level of requirements.

For example, such approach as GrACE (Graph-based

Adaptation, Conﬁguration and Evolution) (Ciraci

et al., 2009) uses different graph transformation

techniques in order to compose behaviours presented

by class, sequence diagrams and the action view in

the corresponding computation tree of the designed

system and apply model checking and veriﬁcation

algorithms to analyse the properties of the system.

- PROS: In addition to conventional activity diagrams

Workﬂow diagrams in Theme/UML separate aspects

and minor actions to increase the abstraction level and

decrease the size of workﬂows.

- CONS: The used composition techniques, namely

concatenation and hierarchy of activities, make it im-

possible to add new aspect models at the requirements

level without veriﬁcation of the complete model. The

evolution of the model is handled by re-generating the

views for any new set of requirements. Reasoning on

models does not become easier as the minor actions

are speciﬁed by sequence diagrams, but the composi-

tion of them as a workﬂow. Reasoning demands rel-

atively heavy procedures of building the computation

tree, reachability analysis and veriﬁcation of dynamic

properties.

Composed workﬂows. Another direction in the use

of workﬂow semantics for aspect-oriented modelling

is specifying fragments of a workﬂow and then com-

posing them into the complete workﬂow. The com-

position techniques used in workﬂows are restricted

to concatenation and hierarchical inclusion of frag-

ments.

The ADORE approach (Mosser et al., 2010) (Ac-

tivity moDel supOrting oRchestration Evolution) re-

examines the Business Process Execution Language

(BPEL) to enable separation of concerns.

An orchestration of services is deﬁned in ADORE

as a partially ordered set of activities. The types of

activities that can be deﬁned in ADORE include ser-

vice invocation (denoted by invoke-inv), variable as-

signment (assign-a), fault reporting (throw-t), mes-

sage receiving (receive- rcv), response sending (reply-

rp), and the null activity(nop), which is used for syn-

chronization purpose (Figure 3).

Each process (fragment) corresponds to a speciﬁc

concern and uses a partial point of view on its target.

A fragment contains special activities, called prede-

cessors P, successors S and a hook (assimilated as a

proceed in AspectJ) that represents a part of a trace

where the fragment is connected into an existing or-

BMSD 2011 - First International Symposium on Business Modeling and Software Design

Theme/Doc

Theme/ UML

Figure 2: Theme model.

t ( c ) := survSys:canCover(infor.loc)

a12 (feedID := survSys:activatevidea(infor, loc)

Sh hook(info)

a3 ui ::= displayVideoFeed(user, feedId)

Figure 3: ADORE model. Fragment requestVideo<user>.

chestration. The hook predecessors (P) are the im-

mediate predecessors of the ﬁrst activity in the target

block, and the hook successors (S) are the immediate

successors of the last activity in the block.

Fig. 3 describes the following behaviour. After

the execution of the hook predecessors (P), perform

the activity block referred to by (h) and then continue

with the hook successors (S). The vertical branch of

the fragment represents the additional behaviour. In

parallel to the behaviour described by the hook (h) the

system ﬁrst determines if the surveillance system can

cover the crisis area (t). If this functionality is avail-

able for this location, the process requests a video

feed (single ADORE activity a12) and then broadcasts

it to the Coordinator interface (a3).

The binding instructions are speciﬁed in a separate

ﬁle. For example, the fragment from Fig. 3 can be

bound on the block of activities

a3 : cms : buildchecklist(i)

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

Whilst

GoTo

<<aspect>>

WhilstOnDoTo

<<Whilst>>

[trigger=On]

Whilst

<<pointcut>>

<<advice>>

goto GoTo

Whilst

GoTo

<<aspect>>

WhilstOnDoTo

<<Whilst>>

[trigger=On]

Whilst

<<pointcut>>

<<advice>>

goto GoTo

/Do

Before

GoTo

<<aspect>>

WhilstOnDoTo

<<Before>>

Before

<<pointcut>>

<<advice>>

goto GoTo

[If]

/Do

When state Whilst is active,

if On is the current event,

go to state GoTo

Before activating state Before,

if condition If is true,

Execute action Do and go to state GoTo

When state Whilst is active,

if On is the current event,

execute action Do and go to state GoTo

Figure 4: HiLA patterns.

and

a4 : (ci)ui := promptchecklist(coord, id, cc1)

of the base orchestration. The predecessor of a3 is

assigned to P, the successor of a4 is assigned to S

and the hook is assigned to {a3, a4}. The complete

orchestration is generated from fragments according

to the binding instructions.

As with such an approach there is no guarantee

that any particular local properties of aspects are

propagated to the complete orchestration, the side

effects of separating of concerns and composition

in ADORE are formulated as rules. The violating

of rules not always signals about a mistake, this

may indicate a ”bad-smell”, like, for example, the

non-determinism caused by two conditions evaluated

to false at the same time. The ”bad-smells” are

analyzed by the designer of the orchestration.

- PROS: ADORE extends BPEL with means for mod-

elling of aspects. Models become closer to require-

ments.

- CONS: The composition techniques in workﬂows

cause the need of re-generating and ”bad-smells”

re-analyzing of the complete orchestration after any

change or adding any new fragment. Reasoning on

models is not localized and demands reachability

analysis and theorem proving.

3.3 Revision of State Machines

A UML Behaviour State Machine (BSM) (OMG,

2003) usually presents behaviour of one classiﬁer.

Before

GoTo

<<aspect>>

CoordinatorLogin

<<Before>>

Idle

<<pointcut>>

<<advice>>

[coordinator==null ]

Op ->validateCoordinator()

Figure 5: HiLA model of the Login Concern.

The execution semantics of BSM (McNeile and

Roubtsova, 2009) is complex, involves a queue or a

stack of active events and rules of their handling or

keeping in the queue until the state is appropriate for

their handling.

There are several approaches revising Behaviour

State Machines (BSM) trying to extend behaviour

speciﬁed by BSM for one classiﬁer. The approach by

(Mahoney et al., 2004) exploits the AND-composition

of several independent (orthogonal) statecharts de-

ﬁned by D.Harel (Harel and Gery, 1997). ”The key

feature of orthogonal statecharts is that events from

every composed statechart are broadcast to all oth-

ers. Therefore an event can cause transitions in two

or more orthogonal statecharts simultaneously” (Ma-

honey et al., 2004).

BMSD 2011 - First International Symposium on Business Modeling and Software Design

The ideas proposed by Mahoney et al. were fur-

ther developed in the approach called High-Level As-

pects (HiLA) (H

olzl et al., 2010). HiLA modiﬁes the

semantics of BSM allowing classiﬁers to apply ad-

ditional or alternative behaviour. Aspects extend the

behaviour speciﬁed for classiﬁers.

The basic static structure usually contains one or

more classes. Each base state machine is attached to

one of these classes and speciﬁes its behaviour. HiLA

offers two kinds of aspects to modify such a model.

Static aspects directly specify a model transformation

of the basic static structure of the model. Dynamic

(high-level) aspects only apply to state machines and

specify additional or alternative behaviour to be ex-

ecuted at certain ”appropriate” points in time in the

base machines execution.

HiLA introduces patterns for speciﬁcation of dy-

namic aspects (Figure 4). A pattern Whilst always

has an annotation Trigger = e. ”Conceptually it se-

lects the compound transition from State

∗

to State

∗∗

with trigger e, but if this transition does not exist, it is

created.” This means that an aspect is added while an

action is in the stack of active actions.

A pattern labelled with Before selects each tran-

sition T entering any state contained in State

∗

, but

only in active state conﬁgurations where after tak-

ing T all states in State

∗∗

, will become active”(H

olzl

et al., 2010). An aspect may extend the behaviour of

a class or introduce a new class to the speciﬁcation.

Figure 5 shows the aspect validating if the

Coordinator is logged in. The aspect is taken from

the model of a crisis management system (Holzl1

et al., 2010). Before the Idle state of system becomes

active, the system checks whether the coordinator is

not logged in (coordinator == null). If this is the

case, the Login sub-state machine is triggered and

operation validateCoordinator() becomes possible.

The aspect is regulative, it changes the ﬂow of control

in the base state machine.

- PROS: HiLA patterns support speciﬁcation of as-

pects in BSM.

- CONS: Evolution of models and reasoning on them

do not become easier. Active objects represented with

classiﬁes with aspects and new aspect classes execute

asynchronously resulting in non-deterministic system

behaviour. HiLA uses formal methods of model val-

idation. The application of aspects to BSM results

in another UML state machine which is analyzed us-

ing the model checking component of Hugo/RTmodel

checking tools. Hugo/RT translates the state machine

and the assertions into the input language of a back-

end model checker SPIN. SPIN then veriﬁes the given

properties presented in Linear Temporal Logic.

3.4 Revision of Design by Contract

The search of composition techniques suitable for

AOM led to the new look at the set-theory composi-

tion. Such approaches as Package Merge (Ammour

and Desfray, 2006) and Visual Contract Language

(VCL) (Am

alio and Kelsen, 2010) explore the declar-

ative way of aspect speciﬁcation based on composi-

tion of sets.

VCL revises the Design By Contract (DbC) prin-

ciple. An element of behaviour is an operation. Ac-

cording to the DbC (Meyer, 1991) the pre-conditions

and post-conditions have to be deﬁned for any speci-

ﬁed behaviour.

- If the precondition is satisﬁed then the result of the

corresponding behaviour is deﬁned. It satisﬁes the

post-condition.

- If a precondition is violated, the effect of the corre-

sponding behaviour becomes undeﬁned.

This means that only the non-interactive part of be-

haviour that takes place, when the preconditions are

not violated, can be composed and analyzed. VCL

inherits this property of DbC.

A VCL model is organized around packages,

which are reusable units encapsulating structure and

behaviour. Packages represent either a traditional

module or an aspect. VCL’s package composition

mechanisms allow larger package to be built from

smaller ones. A package is denoted by a cloud. In

Figure 6 package Authentication Ops extends pack-

age Authentication. A package encapsulates state and

behaviour in form of attributes and operations. Pack-

age Authentication Ops contains operations Login and

Logout.

Ordinary packages deﬁne global state. Abstract

packages do not deﬁne global state, they act as con-

tainers for state structures and their local behaviour to

be used in other packages.

VCL behavioural diagrams (BDs) identify the op-

erations of a package. There are two types of oper-

ations: update and observe (or query). Update oper-

ations perform changes of state in the system; they

involve a pair of states: before-state (described by

pre-condition) and an after-state (described by post-

condition). They are deﬁned in VCL contract dia-

grams. Figure 6 shows examples of VCL contract di-

agrams for LogIn and LogOut operations that belong

to the package Authentication Ops.

Aspects are composed using join extensions,

which is illustrated in Figure 7. In a join extension,

there is a contract that describes the joining behaviour

of an aspect (a join contract) that is composed with

a group of operations placed in a join-box. All op-

erations of package CrisisWithJI are conjoined with

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

AuthenticationOps

Authentication

loggedOut

status

pw?

pwMisses

loginOk

u? : User

pw? : Password

r!: LoginResult

LogInOk

Logout

u? : User

status

loggedIn

status

loggedOut

loggedIn

status

Figure 6: Packages in VCL.

join contracts LoggingOp, SessionMgmtOp and Au-

thorisationOp. Join contract AuthorisationOp speci-

ﬁes the extra behaviour of the Authorisation concern

by adding an extra pre-condition to all operations of

package CrisisWithJI; this speciﬁes that the users ex-

ecuting operations of package CrisisWithJI must be

logged-in and have the required permissions to exe-

cute that task.

VCL is designed with a formal Z semantics and

so it has the potential for veriﬁcation and global

reasoning using theorem proving.

- PROS: The VCL extends the DbC approach by

visual means to capture aspects. Modelling of pack-

ages is simple. It demands only knowledge of the set

theory and predicate logic.

- CONS: The use of the DbC does not allow lo-

calizing of reasoning on aspects about behaviour of

the whole model. Veriﬁcation of the complete model

is needed after every modiﬁcation in the number and

the content of aspects.

3.5 Revision of Mixins

Mixins are applied in the Protocol Modelling ap-

proach deﬁned by McNeile and Simons (McNeile and

Simons, 2003). A protocol model of a system is

a composition of protocol machines. Protocol ma-

chines are partial descriptions of class behaviours.

The composition operator for protocol machines is a

variant of the parallel composition operator deﬁned

by Hoare (Hoare, 1985) in his process algebra Com-

munication of Sequential Processes (CSP). This oper-

ator was extended by McNeile and Simons (McNeile

and Simons, 2003) for machines and events with data.

A protocol machine has its own alphabet of recog-

nized events and a local state. An event type is spec-

iﬁed as a data structure (Figure 8). An event instance

contains values of the attributes.

The local state of a machine is presented as a set

of own attributes and attributes derived from the state

of other machines. A machine can read the state of

other machines but cannot alter it. The derived states

should not be topologically connected. They are al-

ready spectative aspects inside of protocol machines.

Moreover, a machine has a set of transitions being

triples (state, event, state). Events are presented to the

model by the environment. Being in a suitable state,

a protocol machine accepts the presented event, oth-

erwise it refuses the event. A protocol model handles

one event at a time and reaches a well deﬁned qui-

escent state between each event. An element of be-

haviour is an accepted event. The behaviour of a pro-

tocol model is a set of sequences of accepted events.

Protocol machines use the CSP parallel compo-

sition algorithm to form more complex protocol ma-

chines. This is the description of the CSP parallel

composition algorithm:

- If all machines of the protocol model having an event

in their alphabet accept the event, the protocol model

accepts it.

- If at least one of protocol machines having this event

in its alphabet refuses the event, the composition of

machines refuses it.

So, the semantics of refusal which is absent in other

modelling semantics (BSM, workﬂows, sequence di-

agrams and contracts) is the key to synchronization

and CSP parallel composition.

BMSD 2011 - First International Symposium on Business Modeling and Software Design

CrisisWithAspects

AuthorisationCCCMSCrisisWithJI

LoggingCCCMS SessionMgmtCCCMS

↑CrisisOp

UserLoggedInAndHasPerm [t?/t!]

AuthorisationCCCMS

AuthorisationOp

cu? : User

AuthorisationOp

CrisisOp

LoggingOp

CrisisOp

All

CrisisWithJI

SessionMgmtOp

Join

Figure 7: Aspect Composition in VCL.

It is recognized in (McNeile and Roubtsova, 2008)

that protocol machines are natural abstractions to

specify aspects. For example, a protocol model of a

bank Account and a Customer is shown in Figure 8.

Behaviours of both objects include and equally com-

pose behaviours of aspects Freezing and Freeze Con-

trol. These aspects model the possibility to freeze

the behaviour of an account or a customer. The

INCLUDE-relation shown as a half-dashed triangle

gives to Protocol Models the expressiveness of multi-

ple inheritance. Behaviours of aspects are instantiated

with instantiation of objects, each of which has its ob-

ject identiﬁer.

All behaviours are equally composed on the ba-

sis of the CSP parallel composition as shown in Fig-

ure 9. A new registered Customer and a new open

Account are not-frozen. A bank security service may

freeze both an Account and(or) a Customer submit-

ting events Freeze.Customer and(or) Freeze.Account.

Then such an Account or Customer transits to state

Frozen. A Frozen behaviour cannot accept any event.

Its state is derived from the instances of the behaviour

Freezing included into the objects Account and Cus-

tomer correspondingly.

A join point in protocol model is a set of events or

states that can be seen identical in the context a par-

ticular protocol machine.

For example, the join point Generic Operate matches

events Deposit, Withdraw, Transfer, Leave, and Close

and any of these events can be accepted only in state

Freeze Not Active which is derived from state not

Frozen.

The proof presented in (McNeile and Roubtsova,

2008) shows that the CSP parallel composition

of Protocol Machines guarantees preservation of

ordering of traces of aspects in the whole speciﬁ-

cation. This property is called local reasoning or

observational consistency (Ebert and Engels., 1994).

It simpliﬁes reasoning on models as the traces can

become longer or shorter but the order of events

will be never changed. For example, trace Open,

Withdraw, Freeze Account is a trace of the compo-

sition of Freezing and Account, but the sub-trace

Open, Withdraw is a valid trace of Account. Small

and deterministic protocol machines are veriﬁed

or tested by direct execution. Then the syntactic

checks of speciﬁcations of join point are sufﬁcient

for veriﬁcation of the whole model.

- PROS: Protocol machines with generic events and

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

Customer

Date,

Customer OId,

Full Name,

Address

Leave

left

registered

Open, Deposit, Withdraw,

Transfer [Source, Target]

Account

Open

Store:

Balance=0,

Customer OID

closed

active

Deposit,

Withdraw,

Freezing Freeze Control

Operate

Freeze

Not

active

Open,

Freeze Account,

Freeze Customer

Frozen

not

Frozen

Withdraw, Transfer [Source, Target]

Events:

Date:Date

Customer OID: Customer

Full Name: String

Address: String

Leave

Date:Date

Customer OID: Customer

Reason: String

Open

Date:Date

Owner OID: Customer

Account: String

State Function:

If state=“not-frozen”

return “Freeze

not active”;

else return “Frozen”;

Join Point

Specification:

Generic Operate

matches Deposit,

Withdraw, Transfer,

Leave, Close

Freezing

INCLUDE

Events:

Close:

Date o: Date

Account: OID :Account

Freeze:

Date of Freeze: Date

Account: OID :Account

Reason: String

Release:

Date of Release: Date

Account: OID :Account

Events:

Deposit:

Date of Deposit: Date

TargetOID :Account

Amount: Currency

Withdraw:

Date of Withdraw: Date

SourceOID :Account

Amount: Currency

Transfer:

Date of Transfer: Date

Source: OID :Account

Target: OID :Account

Amount: Currency

Figure 8: Protocol Model.

states and the synchronous composition are natural

means for modelling of aspects. The CSP parallel

composition provides ﬂexible support for model evo-

lution. Protocol machines are not hierarchical, they

are equally composed. The composition operator

guarantees preservation of behaviour and properties

of aspects in the behaviour of the whole system.

- CONS: The understanding of a protocol model is not

very intuitive. It takes some time to begin freely ap-

ply the CSP parallel composition. However, the tool

Modelscope

supports execution and understanding

of protocol models.

http://www.metamaxim.com/pages/download.htm

Bank Account with Customer and Freezing Aspects

<<Object>>

Account

<<Object>>

Customer

<<Aspect>>

Freezing

<<CSP parallel composition>>

<<Aspect>>

Freeze Control

Figure 9: CSP composition of Protocol Machines.

4 CONCLUSIONS

Models should have higher abstraction level than pro-

grams and may more freely experiment with compo-

BMSD 2011 - First International Symposium on Business Modeling and Software Design

sition techniques unavailable in the main stream mod-

elling languages. However, the composition tech-

niques of many modelling techniques nowadays does

not deviate from composition forms available in dom-

inant programming languages. These languages are

designed to cover asynchronous communication and

have restricted means to deal with shared data. That

is why it is not a surprise that the extension of

models with the aspect building constructions causes

the same problems as in aspect-oriented programs.

Namely, such AOM models do not prevent speciﬁca-

tion of invasive aspects, do not guarantee local reason-

ing and have to be globally veriﬁed after every modi-

ﬁcation. Using AOM approaches with the same com-

position techniques as in programs we just move the

complexity from models to analysis techniques and

tools and rely heavily on results of this analysis. As

the models are subject of frequent changes, after any

new change the analysis should be repeated. This de-

pendence on analysis and veriﬁcation after any step

of modelling slows down the modelling process, re-

stricts the number of demonstrations of the model to

the client and makes the modelling process inﬂexible.

However, the understanding of the nature of as-

pects can simplify the analysis. Aspect-abstractions

exist at the same level as objects and they are not dis-

tributed from object. Therefore they need synchro-

nization with objects and access to shared data. The

lessons learned from the analysis of aspect-oriented

modelling approaches trying to use asynchronous

composition for aspects shows that approaches con-

fuse aspects and other abstraction sorts. Each type of

abstraction should be used on its own place. Aspects

and objects present problem frames, share data and

communicate synchronously. The distributed compo-

nents or services built from aspects and objects com-

municate asynchronously (Roubtsova and McNeile.,

2009). Such separation will simplify the AOM analy-

sis.

The mixin-based group of AOM approaches offers

to AOM a synchronous and agile way of modelling.

• The semantic restriction when one machine can-

not alter the state of other machines makes it im-

possible to specify invasive aspects.

• Using sets of events and states as join points is

more abstract and technology independent than

using operation calls and returns.

• Derived states provide unlimited weaving abstrac-

tions.

• Determinism of machines is assured by the con-

cept of quiescent states.

• The CSP parallel composition technique guaran-

tees the property of local reasoning on aspects

about the behaviour of the whole system. The lo-

cal properties of mixins survive their composition

and are preserved in the whole behaviour of the

system.

As a consequence of local reasoning, analysis and

execution of mixin-based models does not require

generation of the complete model or a computa-

tion tree after adding/removing/changing of as-

pects.

The semantics of event refusal splits the global

computation tree into sets of traces of woven pro-

tocol machines. The traces of the whole model are

generated on the ﬂy by a tool or a middleware im-

plementing CSP parallel composition algorithm.

• All these features reduce the analysis of mixin-

based models to veriﬁcation or testing of separate

machines and syntactic checks of speciﬁcation of

join points.

As the proposed semantics is notation indepen-

dent and it can be applied in many approaches, the

next step is to apply it and investigate the implemen-

tation of systems in mixin-based and object-oriented

languages. Most probably that offering of a CSP par-

allel composition middleware service will result in a

new group of aspect-oriented languages.

ACKNOWLEDGEMENTS

The author thanks all participants of the workshops

ABMB’05, ABMB’06, AOM’08, BM-MDA’09,

AOM’10 in Bellairs, and BM-FA’10 for fruitful dis-

cussions of different modelling approaches.

REFERENCES

alio, N. and Kelsen, P. (2010). VCL, a Visual Language

for Modelling Software Systems Formally. In Dia-

grams, pages 282–284.

Ammour, S. and Desfray, P. (2006). A Concern-based

Technique for Architecture Modelling Using the UML

Package Merge. M.Aksit and E.Roubtsova eds. Pro-

ceedings of ABMB2005, ENTCS, 163(1):7–18.

Baniassad, E. and Clarke, S. (2004). Theme: An Approach

for Aspect-Oriented Analysis and Design. ICSE 2004.

Proceedings. 26th International Conference on Soft-

ware Engineering. IEEE, pages 158–167.

Cardone, R. and Lin, C. (2004). Using Mixin Technol-

ogy to Improve Modularity. Aspect-Oriented Software

Development. R.Filman, T.Elrad, S.Clarke, M.Aks¸it

eds.Addison-Wesley, pages 219–241.

Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Alar-

con, M., Bakker, J., Tekinerdogan, B., Clarke, S., and

ASPECT-ORIENTATION IN MODELLING: LESSONS LEARNED

Jackson, A. (2005). Survey of Aspect-Oriented Anal-

ysis and Design Approaches. Technical Report D11

AOSD-Europe-ULANC-9, AOSD-Europe.

Chwif, L., Barretto, M. R. P., and Paul, R. (2000). On sim-

ulation model complexity. In WSC ’00: Proceedings

of the 32nd conference on Winter simulation. Society

for Computer Simulation International.

Ciraci, S., Havinga, W. K., Aksit, M., Bockisch, C. M., and

van den Broek, P. M. (2009). A Graph-Based As-

pect Interference Detection Approach for UML-Based

Aspect-Oriented Models. Technical Report TR-CTIT-

09-39, Enschede.

Clarke, S. and Baniassad, E. (2005). Aspect-Oriented Anal-

ysis and Design: The Theme Approach. Addison Wes-

ley.

Ebert, J. and Engels., G. (1994). Observable or invocable

behaviour-you have to choose. Technical report. Uni-

versitt Koblenz, Koblenz, Germany.

Filman, R., Elrad, T., Clarke, S., and Aks¸it, M. (2004).

Aspect-Oriented Software Development. Addison-

Wesley.

Filman, R. and Friedman, D. (2004). Aspect-Orineted Pro-

gramming is Quantiﬁcation and Obliviosness. Aspect-

Oriented Software Development. Addison-Wesley,

pages 21–35.

Harel, D. and Gery, E. (1997). Executable Object Modelling

with Statecharts. IEEE Computer, 30(7), pages 31–42.

Hoare, C. (1985). Communicating Sequential Processes.

Prentice-Hall International.

olzl, M. M., Knapp, A., and Zhang, G. (2010). Mod-

eling the Car Crash Crisis Management System Us-

ing HiLA. T. Aspect-Oriented Software Development,

7:234–271.

Holzl1, M., Knapp, A., and Zhang, G. (2010). Modeling

the car crash crisis management system using HiLA.

S. Katz et al. (Eds.): Transactions on AOSD VII, LNCS

6210, pages 234–271.

Jackson, M. (2005). Problem frames and software engineer-

ing, volume 47. Butterworth-Heinemann.

Katz, S. (2006). Aspect Categories and Classes of Temporal

Properties. Transactions on Aspect-Oriented Software

Development, LNCS 3880, pages 106–134.

Kiczales, G. and Mezini, M. (2005). Aspect-Oriented Pro-

gramming and Modular Reasoning. Proc. of the Inter-

national Conference on Software Engineering, pages

49–58.

Mahoney, M., Bader, A., Elrad, T., and Aldawud, O.

(2004). Using Aspects to Abstract and Modularize

Statecharts. In the 5th Aspect-Oriented Modeling

Workshop In Conjunction with UML 2004.

McNeile, A. and Roubtsova, E. (2008). CSP parallel com-

position of aspect models. AOM’08: Proceedings of

the 2008 AOSD Workshop on Aspect-Oriented Model-

ing, pages 13–18.

McNeile, A. and Roubtsova, E. (2009). Composition se-

mantics for executable and evolvable behavioral mod-

eling in MDA. In BM-MDA ’09: Proceedings of

the 1st Workshop on Behaviour Modelling in Model-

Driven Architecture, pages 1–8, New York, NY, USA.

ACM.

McNeile, A. and Simons, N. (2003). State Machines as

Mixins. Journal of Object Technology, 2(6):85–101.

Meyer, B. (1991). Design by contract. Advances in Object-

Oriented Software Engineering, eds. D. Mandrioli

and B. Meyer, pages 1–50.

Mosser, S., Blay-Fornarino, M., and France, R. (2010).

Workﬂow Design Using Fragment Composition - Cri-

sis Management System Design through ADORE. T.

Aspect-Oriented Software Development, 7:200–233.

OMG (2003). Uniﬁed Modeling Language: Superstructure

version 2.1.1 formal/2007-02-03.

Op de Beeck, S., Truyen, E., Boucke, N., Sanen, F., By-

nens, M., and Joosen, W. (2006). A study of aspect-

oriented design approaches. Technical Report CW435,

Department of Computer Science, Katholieke Univer-

siteit Leuven.

Reddy, R., Ghosh, S., France, R., and Straw, B. (2006).

Directives for composing aspect-oriented design class

models. Transactions on AOSD, LNCS 3880 , pages

75–105.

Reina, A. M., Torres, J., and Toro, M. (2004). Separating

Concerns by Means of UML-proﬁles and Metamodels

in PIMs. In Proc. of the 5th Aspect-Oriented Modeling

Workshop (UML04), Lisbon, Portugal.

Robinson, S. (1994). Successful simulation: A practical ap-

proach to simulation projects. McGraw-Hill, Maiden-

head,UK.

Roubtsova, E. and McNeile., A. (2009). Abstractions,

composition and reasoning. Proceedings of the 13th

Intl Workshop on Aspect-Oriented Modeling, Char-

lottesville. Virginia, USA, ACM DL, pages 19–24.

Schauerhuber, A., Schwinger, W., Kapsammer, E., Rets-

chitzegger, W., and Wimmer, M. (2007). A survey

on aspect-oriented modeling approaches. Technical

report, E188 - Institut f

ur Softwaretechnik und Inter-

aktive Systeme; Technische Universit

at Wien.

Stein, D. and Hanenberg, S. (2006). Why Aspect-Oriented

Software Development And Model-Driven Develop-

ment Are Not The Same - A Position Paper. M.Aksit

and E.Roubtsova eds. Proceedings of ABMB2005,

ENTCS, 163(1):71–82.

Stein, D., Hanenberg, S., and Unland, R. (2005). Visual-

izing Join Point Selections Using Interaction-Based

vs. State-Based Notations Exempliﬁed With Help of

Business Rules. EMISA-2005, pages 94–107.

BMSD 2011 - First International Symposium on Business Modeling and Software Design