Information Technology Reference
In-Depth Information
The rest of the paper is organized as follows. Section 2 formally introduces
the scenario language used and the notion of behavioral aspects. Section 3 intro-
duces various interpretations for join points and Sect. 4 describes three detection
algorithms for these join points. Section 5 presents our composition operator for
sequence diagrams (
amalgamated sum
). Section 6 presents its implementation on
the Kermeta platform [19]. Section 7 discusses future works whose aim at over-
coming a current limitation of our approach. Section 8 compares our approach
with related works, and Sect. 9 concludes this work.
2
Sequence Diagrams and Aspects
2.1
Scenarios: UML 2.0 Sequence Diagrams
Scenario languages are used to describe the behaviors of distributed systems at
an abstract level or to represent systems behavioral requirements. They are close
to users understanding and they are often used to refine use cases with a clear,
graphical and intuitive representation. Several notations have been proposed,
among which UML 2.0 SDs [21], Message Sequence Charts (MSCs) [13] or Live
Sequence Charts [8]. In this paper, the scenarios will be expressed by UML 2.0
SDs. To define formally SDs in an easier way, we call basic sequence diagrams
(bSD), a SD which corresponds to a finite sequence of interactions. We call
combined sequence diagrams (cSDs) a SD which composes bSDs (with sequence,
alternative and loop operators). In this way, a cSD can define more complex
behaviors (even infinite behaviors if the cSD contains loops).
More specifically, bSDs describe a finite number of interactions between a set
of objects. They are now considered as collections of events instead of ordered
collections of messages in UML 1.x, which introduce concurrency and asynchro-
nism increasing their power of expression. Figure 1 shows several bSDs which
describe some interactions between the two objects
.The
vertical lines represent lifelines for the given objects. Interactions between ob-
jects are shown as arrows called messages like
customer
and
server
.Eachmes-
sage is defined by two events: message emission and message reception which
induces an ordering between emission and reception. In this paper, we use ar-
rows represented with an open-head that corresponds to asynchronous messages
2
in the UML2.0 standard notation. Asynchronous means that the sending of a
message does not occur at the same time as the corresponding reception (but
the sending of a message does necessarily precede the corresponding reception).
Consequently, in Fig. 2, the event
log in
and
try again
e
3
corresponding to the reception of the first
message
a
and the event
e
2
corresponding to the sending of the second message
a
are not ordered. Events located on the same lifeline are totally ordered from
top to bottom (excepted in specific parts of the lifeline called coregions).
We recall that in the UML2.0 specification, the semantics of an Interaction
(a Sequence Diagram) is a set of traces, i.e., a set of sequences of events. Con-
sequently, all events are not totally ordered. For instance, in Fig. 2, the bSD
M
2
We use asynchronous messages to be more general.
Search WWH ::
Custom Search