UML 2.0 Interactions with OCL/RT Constraints - Software and ...

Forum on Specification and Design Languages 2008

UML 2.0 Interactions with OCL/RT Constraints Daniel Calegari Garc´ıa

Mar´ıa Victoria Cengarle

Nora Szasz

Instituto de Computaci´on Universidad de la Rep´ublica Montevideo 11300, Uruguay Email: [email protected]

Institut f¨ur Informatik Technische Universit¨at M¨unchen Garching bei M¨unchen 85748, Germany Email: [email protected]

Facultad de Ingeniera Universidad ORT Montevideo 11100, Uruguay Email: [email protected]

Abstract—The Unified Modeling Language 2.0 Interactions language describes inter-component behavior. However, it cannot define meaningful time constraints. OCL for Real Time is a language for real-time constraints specification well-suited for describing constraints on interactions. This work defines a formal semantics for the merger of those languages. The semantics allows the recognition of valid and invalid behaviors of a system with time constraints. An analysis of the properties derived from the semantics is also done. In particular, the notions of refinement of interactions and refinement of constraints, intended for formal verification, are explored.

I. I NTRODUCTION Behavioral specifications describe how system elements interact over time. Inter-component behavior can partially be specified using the Unified Modeling Language 2.0 Interactions language [1]. This language is not expressive enough, it lacks constructs for the specification of constraints. The Object Constraint Language (OCL [2]) is part of the UML and it is a natural candidate to complement the language for interactions. The OCL, however, has some limitations: it offers neither time nor signal handling constructs, it is incapable of expressing general liveness properties or performance aspects of systems conveniently. OCL for Real Time (OCL/RT) is an extension of OCL which covers these aspects [3]. Our concern is to set the ground for lifting UML 2.0 interactions to a formal design technique. The UML 2.0 specification introduces some guidelines for the formal understanding of interactions. However, the specification is rather vague and obscure in some aspects since it is given in natural language. In [4] a denotational semantics is defined intended to verify traces (sequences of messages) against interactions specifications; this semantics allows to discern when a trace is positive (a valid execution), negative (an invalid execution), or inconclusive for a given interaction. We go a step beyond and relate the language of interactions with OCL/RT. We propose a formal semantics for the merger of UML 2.0 Interactions language and OCL/RT, based on the works mentioned above. The semantics recognizes valid and invalid behavior of a system execution considering both interaction structure and constraints satisfaction. We also study This work has been partially sponsored by the Uruguayan Technological Development Program PDT Project 54-106 ”Extensions of UML models for behavioral design of real-time systems and product lines”, and the DFG project rUML.

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

some properties defined in terms of the semantics, like refinement of interactions and constraints. These definitions are intended for formal verification of system properties. Some languages like UML/RT [5] and ROOM [6] extend UML for real-time specifications. These works do not present formal semantics and only take into account basic timing annotations. Some other works define the semantics of UML 2.0 Interaction as those in [4,7–11]. However, only a few of them consider interactions with basic time constraints. Finally, there are several approaches for coping with time and events in OCL and related specification languages for the UML. As far as we know, only in [12] there is an OCL extension to be used with interactions; this work focuses on liveness properties and does not consider any formal semantics. A detailed comparison between related works can be found in [13]. The remainder of this paper is structured as follows. Section II briefly introduces the UML 2.0 Interactions and OCL/RT languages. A formal semantics for an enhanced UML 2.0 Interactions language with OCL/RT constraints support is presented in Section III. The semantics is used in Section IV to review the notions of implementation and refinement of an interaction, and to present the notion of refinement of constraints. Section V presents a short summary of the practical application of the concepts developed in previous sections. Finally, Section VI presents a short summary with concluding remarks and an outline of future work. II. BACKGROUND We briefly review the background of our work. Although we assume the reader is familiar with UML interactions, we present UML 2.0 Interaction and OCL/RT languages. A. UML 2.0 Interactions UML 2.0 Interactions [1] describe possible message exchanges between system instances. A message is a communication between two instances and is defined by two events, representing the sending and the receiving of that message. Interactions are graphically represented by Sequence Diagrams. They focus on message interchange among lifelines. The instances involved in the diagram are on the horizontal axis, each one is represented by an object rectangle with the object or class name. Below the rectangle, a vertical dashed line called lifeline represents the instance execution over time. Communications between instances are represented

Page 167

Forum on Specification and Design Languages 2008

as horizontal message arrows between the instance lifelines. Sequence Diagrams are read from top to bottom to view the exchange of messages taking place as time passes. Each interaction may contain sub-interactions called interaction fragments, which can be structured and combined using interaction operators. The resulting combined fragments enclose messages or fragments within a rectangular frame with the name of the operator shown in a pentagram at the upper-left corner. These define special behavior like sequential, parallel, and iterative composition of interactions, alternative, optional and invalid interactions, and interactions considering and ignoring a set of messages, among others. The UML also introduces visual elements to express time and duration observations, and time and duration constraints. As an example, consider the interaction in Figure 1 where an instance a of A sends the message n to an instance b of B and b responds sending up to N times the message m. There is a visual constraint restricting the duration of message n between 0 and 3 time units.

Figure 1.

Interaction with a combined fragment

[4] defines the abstract syntax of the language by a context-free grammar which does not consider all the features introduced by the UML 2.0 specification. They also define the semantics of interactions, which decides when a trace (sequence of messages) is positive (a valid execution) or negative (an invalid execution) for some interaction. B. OCL/RT OCL/RT (OCL for Real Time) is defined in [3] as an extension of OCL 1.4 for real-time and reactive systems constraints specification. The language is based on the notion of traces of events with timestamps and allows the specification of the temporal behavior of a system. The constraints are evaluated over sequences of system states (system execution) instead of just on a given state as OCL does. For the definition of OCL/RT constraints, that are evaluated over a sequence of system states, a new clause is introduced context C constr: c

where C is a classifier and c an OCL/RT constraint. OCL is furthermore extended with particular OCL/RT features: the modality always c and the satisfaction operator @η. The modality always c satisfies the constraint c over a system run when the constraint evaluates to true in every system state. The satisfaction operator @η yields the value of a given expression at the system state where event η occurred.

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

System states are formalized by dynamic bases. A dynamic basis comprises an implementation of the predefined OCL types and their operations, as well as the set of current instances of classes together with their attribute valuations, connections to other instances, and implementations of operations. OCL/RT constraints restrict system runs. A system run ρ is a finite or infinite sequence of pairs of dynamic bases and finite sets of events. OCL/RT is equipped with an operational semantics that permits the derivation of judgments of the form (ρ, i); γ  c ↓ v where ρ is a system run, i an index of ρ, γ a variable environment, c an OCL/RT constraint, and v a value. Such a judgement conveys that c evaluates to v at the ith system state in the system run ρ using the variable environment γ. III. C ONSTRAINED I NTERACTIONS The abstract syntax of the fragment of the language of UML 2.0 defined in [4] is extended with OCL/RT time constraints as shown in Figure 2. The production rule constraint(Term, Interaction) considers an OCL/RT term and the interaction over which the term is evaluated; the Term must be of boolean type, expressions of other type are not permitted. Interaction ::= Basic | CombinedFragment CombinedFragment ::= strict (Interaction, Interaction) | seq (Interaction, Interaction) | par (Interaction, Interaction) | loop (Nat, (Nat|∞), Interaction) | ignore (Messages, Interaction) | alt (Interaction, Interaction) | neg (Interaction) | assert (Interaction) | constraint (Term, Interaction) Figure 2. Abstract syntax of interactions with OCL/RT constraints (fragment)

In order to consider timed events the meta-class Event (UML 1.5) was extended in [3]. Each event shows the time at which it occurred by a link to the primitive data type Time that represents the global system time, as in the original definition. It is assumed that Time comes with a total ordering relation ≤ for comparing time values, an associative and commutative binary operation + for adding time values, and a class attribute now that always yields the current system time. We extend the event meta-model as shown in Figure 3 in order to model a system based on message passing through instances. Every (partial) message is composed of at least one and at most two events representing the sending of that message by an instance (of a classifier) and the reception of it by another instance (possibly the same). Any classifier instance is linked to all its current events, message events among them. There is also a well-formedness rule on system runs: send and receive events of the same message must occur in this order.

Page 168

Forum on Specification and Design Languages 2008

«primitive» Time

event that is not of interest for some given interaction, e.g. an attribute value change, such that its occurrence is nevertheless events at considered for it may cause a state change. System runs +now() : Time receiver 1 1 sender contain every event occurred during the system execution, while interactions can specify partial behavior of the system. 1..2 1 MessageEvent Message We say that the instance s is active for snd(s, r, m) and, similarly, that the instance r is active for rcv(s, r, m). We define a binary, symmetric conflict relation < > ⊆ E × E on events: If an instance is active for both events η1 and η2 then SndMsgEvent RcvMsgEvent > η2 . Trivially, τ < > η for any η ∈ Eτ . η1 < Given an event η ∈ E, the occurrence time of the event Figure 3. Event model for messages can be retrieved by the map at : E → T. The domain T is equipped with a total ordering relation ≤ for comparing time values and a binary operation + for adding time values. As an example, consider the interaction in Figure 1. The We write lin at (E) for all possible linearizations of the set constraint on the first message can be expressed as follows: of events E given by the function at, i.e., l ∈ lin at (E) if, and only if l is the isomorphism class [(X, ≤X , λX )] of the totally context B def: sndN : Event = ordered, labeled sets (X, ≤X , λX ) with λX : X → E bijective events->select(e | e.oclIsTypeOf(SndMsgEvent) and such that ∀x , x ∈ X . at(λ (x )) < at(λ (x )) =⇒ 1 2 X 1 X 2 and e.message.name = "n")->any() ≤ x and ∀x , x ∈ X . x ≤ x ∨ x ≤ x . x 1 X 2 1 2 1 X 2 2 X 1 def: rcvN : Event = A basic interaction is given by an event-labeled pomset [14] events->select(e | e.oclIsTypeOf(RcvMsgEvent) [(X, ≤X , λX )] such that conflicting events do not occur conand e.message.name = "n")->any() constr: always((rcvN.at λX (x2 ), then currently, i.e., if x1 , x2 ∈ X with λX (x1 ) < ≤ x or x ≤ x . An event-labeled pomset is a pomset x 1 X 2 2 X 1 The abstract syntax term representing the diagram of Fig: X → E (or simply with an injective labeling function λ X ure 1 is thus λ). The order x1 ≤X x2 is interpreted as “the occurrence seq (constraint (ϕ1 , B1 ), loop (0, N, B2 )) of event λ(x1 ) precedes the occurrence of event λ(x2 )”. The where B1 is a basic interaction representing the dispatch and empty interaction [(∅, ∅, ∅)] is denoted by ε. We write lin(p) for all possible linearizations of a pomset p, arrival of message n, B2 is a basic interaction representing  the dispatch and arrival of message m, and ϕ1 is the above i.e., all traces that extend the ordering of p: [(X , ≤X  , λX  )] ∈  , λ )]) if, and only if, X = X, λ lin([(X, ≤ X X X  = λX , and constraint. Notice that there exists an implicit weak sequence    ⊆≤ where x ≤ x or x ≤ x for all x1 , x2 ∈ X  . ≤ X X 1 X 2 2 X 1 between B1 and the loop. System states are formalized by dynamic bases. A systemWe adapt the formal semantics in [4] to recognize valid and run ρ is a finite or infinite sequence of pairs of dynamic bases invalid behavior for some given interaction with constraints. and finite sets of events possibly containing the silent event τ We use a more expressive notion of trace: a system run. This ∗ , H ), (ω , H ), (ω , H ), . . . ∈ (Σ × ℘ E ) (ω 0 0 1 1 2 2 ≤ω τ notion allows the use of OCL/RT constraints in interactions ∪ (Σ×℘≤ω Eτ )∞ and the fusion of both semantics. As in [4] the semantics is divided into two fragments: one that does not contain occur- such that if η1 ∈ Hi \ {τ } and η2 ∈ Hj \ {τ } with i < j, rences of the neg nor assert operators (positive fragment), then at(η1 ) < at(η2 ). The dynamic basis ω0 defines the initial and the other that contains them (negative fragment). In what system state; ωn is transformed into ωn+1 by a single system follows we first introduce the unified semantic domains and step where the events in Hn occur. We denote by ω(ρ)n the nth dynamic basis in ρ, by H(ρ)n then present both fragments of the semantics. the nth set of events in ρ, and by ρ(n) the nth pair of dynamic A. Semantic Domains basis and set of events in the system run ρ. The empty system We assume four primitive domains for events E, messages run is denoted by ε. Given a system run ρ, we define: M, abstract time points T and natural numbers N. An event ∗ η ∈ E is either of the form snd(s, r, m) or of the form • the partition of a system run ρ as the set of pairs (ρ1 , ρ2 ) rcv(s, r, m), representing the dispatch and the arrival of with ρ1 and ρ2 system runs such that ∀j ∈ N . ω(ρi )j = message m from sender instance s to receiver instance r, ω(ρ)j (i = 1, 2) and ∀j ∈ N . {H(ρ1 )j , H(ρ2 )j } is a respectively. Events are univocally identified, i.e., two arbitrary partition of the set of events H(ρ)j .  • rem(ρ) as the system run ρ resulting from removing events, even if they are both a send (or receive) event of the every pair (ωi , ∅) from ρ. same message from the same sender to the same receiver, can • concurrence ρ as the set of pairs of system runs be distinguished. (rem(ρ1 ), rem(ρ2 )) such that (ρ1 , ρ2 ) ∈ ρ∗ . We let certain events be anonymous or unobservable by • strict sequencing ρ; as the set of pairs (ρ1 , ρ2 ) ∈ ρ such replacing them by a predefined silent event denoted by τ . We that ∃k ∈ N . ∀i ∈ N . 0 ≤ i ≤ k ⇒ H(ρ1 )i = H(ρ)i and define the domain Eτ as E ∪ {τ }. A silent event represents an Classifier

1

*

Event

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

1

Page 169

Forum on Specification and Design Languages 2008

•

•

k < i ⇒ H(ρ2 )i−k = H(ρ)i . weak sequencing ρ;< of pairs of system runs > as the set  , ρ ) ∈ ρ such that ∀η ∈ (ρ 1 2 1  n H(ρ1 )n \ {τ }, η2 ∈  H(ρ ) \ {τ } . η > < η ⇒ at(η 2 n 1 2 1 ) < at(η2 ). n filter (M )(ρ), with M ∈ M, as the set of system runs that result of the removal of some events from ρ whose messages are labelled by elements in M and subsequently eliminating pairs with empty set of events, i.e., rem(ρ ) ∈ filter (M )(ρ) if ∀i ∈ N . ω(ρ)i = ω(ρ )i ∧ H(ρ )i ⊆ H(ρ)i , and any η ∈ H(ρ)i \ H(ρ )i is of the form either snd(s, r, m) or rcv(s, r, m) with m ∈ M .

B. The Positive Fragment The semantics of the positive fragment of the language (with no occurrences of negation and assertion) is defined by an inductive positive satisfaction relation between system runs and interactions, denoted by ρ |=p S and read system run ρ positively satisfies interaction S, as shown in Figure 4. ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p ρ |=p

where both the constraint and the interaction must be satisfied in order to consider a system run positive. In this case, it is not possible to consider positive a system run where constraints are not valid, not even the empty system run. Consider the example in Figure 1 and the system runs ρ1 = (ω0 , {snd(a, b, n, at 1 ), rcv(a, b, n, at 2 )}) and ρ2 = (ω0 , {snd(a, b, n, at 1 ), rcv(a, b, n, at 2 )}) (ω1 , {snd(b, a, m, at 3 ), rcv(b, a, m, at 4 )}) Both system runs positively satisfy seq (B1 , loop (0, N, B2 )). In the case of ρ1 , it satisfies the interaction since the operator loop accepts the empty system run and (ρ1 , ε) ∈ ρ1;< >. However, the system runs are valid for the whole interaction depending on the assignments for at i . Table I T IME ASSIGNMENTS FOR THE EXAMPLE



B if lin at ( i H(ρ)i \ {τ }) ⊆ lin(B) strict(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ; . ρi |=p Si (i = 1, 2) seq(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ;< > . ρi |=p Si (i = 1, 2) par(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ . ρi |=p Si (i = 1, 2)  loop(0, 0, S) if i H(ρ)i \ {τ } = ∅  loop(0, n + 1, S) if i H(ρ)i \ {τ } = ∅ ∨ ρ |=p seq(S, loop(0, n, S)) loop(m + 1, n + 1, S) if ρ |=p seq(S, loop(m, n, S)) loop(m, ∞, S) if ∃n ≥ m . ρ |=p loop(m, n, S) ignore(M, S) if ∃ρ1 . ρ1 ∈ filter (M )(ρ) ∧ ρ1 |=p S alt(S1 , S2 ) if ρ |=p S1 ∨ ρ |=p S2

ρ |=p constraint(ϕ, S) if (ρ, 0); ∅ ϕ ↓ true ∧ ρ |=p S Figure 4.

Semantics of the positive fragment

The base case considers a system run possibly containing one or more occurrences of the silent event τ . Silent events are ignored in order to verify the satisfaction of a given system run. A system run satisfies a basic interaction if every possible linearization of all its events but τ (with respect to their occurrence time) is included in the linearization of the basic interaction (with respect to its partial ordering). In order to satisfy strict, seq and par operators, the system run is partitioned in two and the satisfaction is verified for each resulting system run. Performing a partition of a system run may produce empty set of events Hi in the resulting system runs. Those sets are removed, with their corresponding dynamic bases, since they represent transitions taken by some other parts of the interaction. The ignore operator is evaluated by filtering some events of the system run. The loop operator is equivalent to its unfolding as weak sequencing of its interaction arguments. The alt operator is evaluated as the disjunction of the satisfaction of the system run in both interaction fragments. Finally, there is a satisfaction rule to evaluate whether a system run positively satisfies an OCL/RT-constrained interaction. The constraint fragment is interpreted as a conjunction

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

at i

Assignment 1

Assignment 2

Assignment 3

at 1 at 2 at 3 at 4

0 2 3 4

0 4 5 6

0 3 7 9

With the first and third time assignments in Table I, the reception of n is done before 3 time units since the sending of n. In consequence, ϕ1 is satisfied and both system runs are valid. The proof of this is developed as follows: ρ2 (0) |=p B1 (ρ2 (0), 0); ∅ ϕ1 ↓ true ρ2 (0) |=p constraint(ϕ1 , B1 )

then,

ρ2 (0) |=p constraint(ϕ1 , B1 ) ρ2 (1) |=p loop(0, N, B2 ) (ρ2 (0), ρ2 (1)) ∈ ρ2;< >

ρ2 |=p seq(constraint(ϕ1 , B1 ),loop(0, N, B2 ))

If we consider the second assignment, the constraint is not satisfied and consequently the system run is not positive but negative as we show next. C. The Negative Fragment The semantics of the negative fragment of the language (with occurrences of negation and assertion) is defined by an inductive negative satisfaction relation between system runs and interactions, denoted by ρ |=n S and read system run ρ negatively satisfies interaction S, as shown in Figure 5. As in [4] we regard the empty system run and also those with events besides possibly τ as being positive for neg (S). We change the negative satisfaction rule following the same idea as sequential operators: after traversing a negative fragment a system run will always be negative no matter what happens afterwards. A system run positively satisfying S is positive for assert(S), otherwise the system run is negative. For the operators strict and seq we adopt the view that the only system runs that are negative are those that either run through the first operand negatively or fulfil the first operand positively and the second operand negatively.

Page 170

Forum on Specification and Design Languages 2008

 ρ |=p neg(S) if i H(ρ)i \ {τ } = ∅ ρ |=p assert(S) if ρ |=p S

a concrete specification refines an abstract specification if any model of the concrete specification is also a model of the abstract one. Below, we adapt the set of definitions ρ |=n strict(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ; . (ρ1 |=n S1 ∨ (ρ1 |=p S1 ∧ ρ2 |=n S2 )) originally given in [4] for implementation and refinement of an interaction to our semantic domains. ρ |=n seq(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ;< > . (ρ1 |=n S1 ∨ (ρ1 |=p S1 ∧ ρ2 |=n S2 )) Definition 1 (Implementation of Interactions). A process is an ρ |=n par(S1 , S2 ) if ∃(ρ1 , ρ2 ) ∈ ρ . ((ρ1 |=n S1 ∧ ρ2 |=n S2 ) ∨ arbitrary set of system runs. A process I is an implementation (ρ1 |=n S1 ∧ ρ2 |=p S2 ) ∨ of an interaction S, written I |= S, if (ρ1 |=p S1 ∧ ρ2 |=n S2 )) 1. ∃ρ ∈ I . ρ |=p S ρ |=n loop(0, n + 1, S) if ρ |=n seq(S, loop(0, n, S)) 2. ∀ρ ∈ I . ρ n S ρ |=n loop(m + 1, n + 1, S) if ρ |=n seq(S, loop(m, n, S)) An interaction S is implementable if there is a process I such ρ |=n loop(m, ∞, S) if ∃n ≥ m . ρ |=n loop(m, n, S) that I |= S. ρ |=n ρ |=n ρ |=n ρ |=n

ignore(M, S) if ∃ρ1 . ρ1 ∈ filter (M )(ρ) ∧ ρ1 |=n S alt(S1 , S2 ) if ρ |=n S1 ∧ ρ |=n S2 neg(S) if ∃(ρ1 , ρ2 ) ∈ ρ; . ρ1 |=p S assert(S) if ρ p S

ρ |=n constraint(ϕ, S) if (ρ, 0); ∅ ϕ ↓ false ∨ ρ |=n S Figure 5.

Semantics of the negative fragment

A similar instance is taken towards par where at least one operand has to be run through negatively in order to make a run negative. The loop and ignore operators follow the same idea as in the positive fragment, while for the alt operator both operands have to be run through negatively. Finally, there is a satisfaction rule to evaluate whether a system run negatively satisfies an OCL/RT constrained interaction. The negative rule is interpreted as the “negation” of the positive satisfaction rule: either the constraint evaluates to false or the system run negatively satisfies the interaction. We had that the system runs ρ1 and ρ2 of above satisfy the interaction of Figure 1 depending on the value of ati . For the second time assignment, ϕ1 is not satisfied and consequently the system run is negative for the interaction: ρ2 (0) |=n constraint(ϕ1 , B1 ) ρ2 (1) |=p loop(0, N, B2 ) (ρ2 (0), ρ2 (1)) ∈ ρ2;< >

ρ2 |=n seq(constraint(ϕ1 , B1 ),loop(0, N, B2 ))

D. Summary of Constraints Satisfaction The satisfaction rule for constraints, defined in the previous section, states that a system run ρ is positive for an interaction constraint(ϕ, S) if the system run positively satisfies the interaction S and also ϕ evaluates to true. If ρ negatively satisfies the interaction S or ϕ evaluates to false, the system run ρ negatively satisfies the interaction constraint(ϕ, S). In any other case, the system run ρ is considered inconclusive. Finally, a system run can be both positive and negative. In this case, we speak of an overspecified interaction. In the following, by ρ  ϕ ↓ v abbreviates (ρ, 0); ∅  ϕ ↓ v. IV. I MPLEMENTATION AND R EFINEMENT Refinement means adding information to a specification to make it closer to an implementation. This can be formally defined using the notion of refinement by model inclusion:

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

Definition 2 (Refinement). An interaction S  refines an interaction S, written S ; S  , if any implementation of S  is also an implementation of S, i.e., ∀I . I |= S  ⇒ I |= S. With these definitions we can increase the set of refinement rules given in [4]. We show one of them in the following lemma. It is straightforward to prove that S ; constraint(ϕ, S) for any constraint ϕ and interaction S. Lemma 1. Let S and S  be interactions with S  implementable and not overspecified, let ϕ be a constraint. If S ; S  , then constraint(ϕ, S) ; constraint(ϕ, S  ). Proof: Let I be a process with I |= constraint(ϕ, S  ). (a) ∃ρ ∈ I . ρ |=p constraint(ϕ, S  ). Thus (by the positive satisfaction relation) ρ  ϕ ↓ true ∧ ρ |=p S  , and thus ρ n S  as S  is not overspecified. Then ρ |=p S by definition of ;, and thus, ρ |=p constraint(ϕ, S). (b) ∀ρ ∈ I . ρ n constraint(ϕ, S  ). Thus (by the negative satisfaction relation) ρ  ϕ ↓ false ∧ ρ n S  . Now, let I’ be a process such that I’ |= S’. Then, I’ ∪ {ρ} |= S’, and thus I’ ∪ {ρ} |= S because S ; S’. Finally, ρ n S, and hence, ρ n constraint(ϕ, S). From (a) and (b) we conclude that I |= constraint(ϕ, S), thus constraint(ϕ, S) ; constraint(ϕ, S  ). In analogy to Definition 2, we define constraint refinement. Definition 3 (Constraint Refinement). A constraint ϕ refines a constraint ϕ, written ϕ ; ϕ if, for any system run ρ, 1. ρ  ϕ ↓ true ⇒ ρ  ϕ ↓ true 2. ρ  ϕ ↓ undef ⇒ ρ  ϕ ↓ false We can also define a further refinement rule. Lemma 2. Let ϕ and ϕ be constraints, let S be an interaction. If ϕ ; ϕ , then constraint(ϕ, S) ; constraint(ϕ , S). Proof: Let I be a process with I |= constraint(ϕ , S). (a) ∃ρ ∈ I . ρ |=p constraint(ϕ , S). Thus (by the positive satisfaction relation) ρ  ϕ ↓ true ∧ ρ |=p S. Then (by Definition 3) ρ  ϕ ↓ true, and finally, ρ |=p constraint(ϕ, S). (b) ∀ρ ∈ I . ρ n constraint(ϕ , S). Thus (by the negative satisfaction relation) one of the following cases occur: (1) ρ  ϕ ↓ true ∧ ρ n S. Then (by Definition 3) ρ  ϕ ↓ true, and finally ρ n constraint(ϕ, S);

Page 171

Forum on Specification and Design Languages 2008

(2) ρ  ϕ ↓ undef ∧ ρ n S. Then (by Definition 3) ρ  ϕ ↓ false and in consequence ρ n constraint(ϕ, S) From (a) and (b) we conclude that I |= constraint(ϕ, S), and thus the thesis holds. The interaction of the example in Figure 1 can be refined by adding a new constraint ϕ2 which states that every message m must be sent within 3 time units since the reception of n:

with an expressive support of complex constraints in interactions. We also reviewed the notions of implementation and refinement of interactions, we extended the set of refinement rules intended for formal verification, and we introduced the notion of constraint refinement. Since some kind of constraints are not relevant for the interactions, OCL/RT is not used in its full potential. Future work is needed in order to extend the language to specify context B state-based constraints suited for temporal logic reasoning. def: sndM : Set(Event) = events->select(e | e.oclIsTypeOf(SndMsgEvent) Moreover, system runs do not consider termination events for and e.message.name = "m") operations nor synchronization of messages. Both concepts are def: rcvN : Event = needed to develop a integrated behavioral specification model events->select(e | e.oclIsTypeOf(RcvMsgEvent) and e.message.name = "n")->any() connecting other development activities as intra-component specifications and design by contract. constr: always(sndM->forAll(e | Our approach tends to ensure software quality attributes e.at < rcvN.at + 3)) by verification of the generated models at early development The third assignment of Table I makes the system run invalid stages. A formal background helps to prevent from ambigufor constraint(ϕ2 , seq(constraint(ϕ1 , B1 ), loop(0, ous, imprecise, contradictive and error-prone specifications. N, B2 ))) while it is valid for seq(constraint(ϕ1 , B1 ), This approach allows a tighter control of the processes and loop(0, N, B2 )). The interactions can also be refined by a improves software reliability. Our intention is not capricious constraint refinement. If we restrict the duration of n to since software modeling and formal verification are strongly {0..2}, only the first assignment makes the system run valid. related in growing engineering approaches nowadays. V. I N P RACTICE ACKNOWLEDGMENT A practical analysis is mandatory for a fine-tuning and a careful utilization of the proposal. [13] presents some examples, taken from the literature, that apply our approach; these examples are not repeated here due to space reasons. UML 2.0 Interactions can graphically specify basic timing constraints, as defined in [1]. These kind of constraints are simple time and duration observations and/or constraints. They can be expressed with OCL/RT assigning to them a concrete meaning in the evaluation of a system-run. Besides, OCL/RT allows specifying more complex constraints involving also system instances, message events and global variables. Consequently our approach is one of the most powerful proposals in order to specify real-time constraints in UML 2.0 Interactions. As far as we know, only the work in [12] analyzes an OCL extension to be used with interactions. There, the problem of synchronization and the specification of liveness properties (normally expressed at the level of state diagrams) are addressed. Our work does not address the problem of synchronization but the use of OCL/RT allows specifying some liveness properties. We think that our work and that in [12] are complementary, and a fusion of both can be made in order to investigate the relation between constrained interactions and timed state machines. VI. C ONCLUSIONS AND O UTLOOK This work contributes to the clarification on the use of time constraints in inter-component behavioral specifications. Based on previous works, we developed a semantics for an enhanced UML 2.0 Interactions language with OCL/RT constraints support. The resulting denotational semantics evaluates the positivity/negativity of a system run within an interaction, considering both interaction structure and constraints satisfaction. To the best of our knowledge, our semantics is the only one

978-1-4244-2265-4/08/$25.00 © 2008 IEEE

The authors are indebted to Alexander Knapp for fruitful discussions on the subject. R EFERENCES [1] “UML 2.0 Superstructure,” Object Management Group, Formal Specification formal/05-07-04, 2005. [Online]. Available: http://www.omg.org/docs/formal/05-07-04 [2] “UML 2.0 Object Constraint Language,” Object Management Group, Formal Specification formal/06-05-01, 2006. [Online]. Available: http://www.omg.org/cgi-bin/doc?formal/06-05-01 [3] M. V. Cengarle and A. Knapp, “Towards OCL/RT,” Lecture Notes in Computer Science, vol. 2391, pp. 390–409, 2002. [4] M. V. Cengarle and A. Knapp, “UML 2.0 Interactions: Semantics and Refinement,” in Proc. 3rd Intl. Work. on Critical Systems Development with UML. Technische Universit¨at M¨unchen, 2004, pp. 85–99. [5] B. P. Douglass, Real-Time UML: Advances in the UML for Real-Time Systems, 3rd ed. Addison Wesley, 2004. [6] B. Selic, G. Gullekson, and P. T. Ward, Real-Time Object-Oriented Modeling. Wiley, 1994. [7] H. St¨orrle, “Semantics of Interactions in UML 2.0,” Proc. 2003 IEEE Symp. on Human Centric Computing Languages and Environments, pp. 129–136, 2003. [8] Ø. Haugen, R. Kobro, K. Husa, and K. Stølen, “Why Timed Sequence Diagrams Require Three-Event Semantics,” Lecture Notes in Computer Science, vol. 3466, pp. 1–25, 2005. [9] R. Grosu and S. Smolka, “Safety-Liveness Semantics for uml 2.0 sequence diagrams.” in Proc. 5th Intl. Conf. on Application of Concurrency to System Design. IEEE Computer Society, 2005, pp. 6–14. [10] Y. Hammal, “Branching Time Semantics for UML 2.0 Sequence Diagrams.” Lecture Notes in Computer Science, vol. 4229, pp. 259–274, 2006. [11] A. Cavarra and J. K¨uster-Filipe, “Formalizing Liveness-Enriched Sequence Diagrams Using ASMs,” Lecture Notes in Computer Science, vol. 3052, pp. 62–77, 2004. [12] A. Cavarra and J. K¨uster-Filipe, “Combining Sequence Diagrams and OCL for Liveness.” Electronic Notes in Theorical Computer Science, vol. 115, pp. 19–38, 2005. [13] D. Calegari, “UML 2.0 Interactions with OCL/RT Constraints,” InCoPEDECIBA, Master Thesis Report TR07-17, 2007. [Online]. Available: http://www.fing.edu.uy/inco/pedeciba/bibliote/tesis/tesis-calegari.pdf [14] V. Pratt, “Modelling Concurrency with Partial Orders,” International Journal of Parallel Programming, vol. 15, no. 1, pp. 33–71, 1986.

Page 172