Refining UML interactions with underspecification and nondeterminism. Ragnhild Kobro Runde, Øystein Haugen, Ketil Stølen

Transcription

1 University of Oslo Departent of Inforatics Refining UML interactions with underspecification and nondeterinis Ragnhild Kobro Runde, Øystein Haugen, Ketil Stølen Research Report 325 ISBN ISSN Revised January 2007

2

3 REFINING UML INTERACTIONS WITH UNDERSPECIFICATION AND NONDETERMINISM RAGNHILD KOBRO RUNDE 1 ØYSTEIN HAUGEN 1 KETIL STØLEN 1,2 1 Departent of Inforatics, University of Oslo PO Box 1080, Blindern, NO-0316 Oslo, Norway {ragnhilk oysteinh}@ifi.uio.no 2 SINTEF ICT, NO-0373 Oslo, Norway ketil.stolen@sintef.no Abstract. STAIRS is an approach to the copositional developent of UML interactions, such as sequence diagras and interaction overview diagras. An iportant aspect of STAIRS is the ability to distinguish between underspecification and inherent nondeterinis through the use of potential and andatory alternatives. This paper investigates this distinction in ore detail. Refineent notions explain when (and how) both kinds of nondeterinis ay be reduced during the developent process. In particular, in this paper we extend STAIRS with guards, which ay be used to specify the choice between alternatives. Finally, we introduce the notion of an ipleentation and define what it eans for an ipleentation to be correct with respect to a specification. ACM CCS Categories and Subject Descriptors: D.2.1 [Software Engineering]: Requireents/Specifications; D.3.1 [Prograing Languages]: Foral Definitions and Theory; F.3.1 [Logics and Meanings of Progras]: Specifying and Verifying and Reasoning about Progras Key words: UML interactions, foral seantics, nondeterinis, underspecification, refineent 1. Introduction STAIRS [9, 8] is an approach to the copositional developent of UML interactions, such as sequence diagras and interaction overview diagras. Interactions in UML 2.0 [13] are behavioural definitions that describe soe, but not necessarily all, of the behaviour that a given syste perfors. Most often the interactions will describe positive behaviours, i.e. behaviours that the syste is allowed to perfor. There ay also be behaviours that the interactions define as negative, eaning that they are unacceptable, and there ay even be behaviours of the syste that are not at all covered by any of the interactions defined.

4 2 R. K. RUNDE, Ø. HAUGEN, K. STØLEN This partiality of interactions is otivated by several factors. First of all, the description of a real syste requires far too any interaction diagras to define all the behaviours. To anage such a volue of diagras would be ipractical. Also, the goal of interactions is to visualize iportant interaction patterns. Thus the ephasis is on iportance, rather than copleteness. This is in contrast to ost other kinds of behavioural specifications, including UML state achines. The definition of a state achine is coplete in the sense that it ay be seen to define all the possible behaviours of that entity. A ethodology ay initially use interactions to capture user requireents, and use these as stepping stones for the next developent stages where ephasis is placed ore on copleteness and realizability. STAIRS supports this through the notion of refineent. In particular, the refineent definitions take into account that initial specifications in the for of interactions typically describe only a few exaple scenarios. A scenario not described by an initial specification is not necessarily unwanted, but it has not been thought of yet. Thus, a refineent step ay be to include new scenarios in the specification, as well as to reduce the aount of underspecification and nondeterinis in the specification. Refineent ay also be to describe soe of the aspects of a scenario in ore detail. In this paper we focus on defining and refining specifications with nondeterinis. In the introductory chapter of the UNITY-book [3] Chandy and Misra observe: Nondeterinis is useful in two ways. First, it is eployed to derive siple progras, where siplicity is achieved by avoiding unnecessary deterinis; such progras can be optiized by liiting the nondeterinis, i.e., by disallowing executions unsuitable for a given architecture. Second, soe systes (e.g., operating systes and delay-insensitive circuits) are inherently nondeterinistic; progras that represent such systes have to eploy soe nondeterinistic constructs. STAIRS is based on this overall observation. However, contrary to Chandy and Misra we take the position that the two useful ways of using nondeterinis should be described differently. Avoiding unnecessary deterinis ay for instance be achieved through underspecification. By underspecification we ean that the specification gives several alternative behaviours that are equivalent in the sense that they all serve the sae purpose. For an ipleentation to be correct, it is sufficient to fulfil only one of the alternative behaviours. Underspecification ay also be used as an abstraction echanis, for instance by giving several alternative behaviours but not stating how to select between the. This will typically later be refined into an if-then-else construct in the ipleentation. On the other hand, inherent nondeterinis is used to capture alternative behaviours that ust all be possible for the ipleentation. A typical exaple is the tossing of a coin, where both heads and tails should be

5 REFINING UML INTERACTIONS 3 possible outcoes, and no legal refineent should reove one of these two alternatives. A syste ay also need to exhibit nondeterinistic behaviour due to differences in its environent. Inherent nondeterinis is very different fro underspecification, and should be described differently. One iportant reason for this is that unless we do not distinguish these two, there will be no way to ensure that inherently nondeterinistic behaviour is ipleented as such. This ay not see like a ajor proble at first. If the developent tea knows that a given specification should be ipleented as delay-insensitive circuits you will probably get the inherently nondeterinistic ipleentation that you expect. However, in the doain of inforation security, the inherently nondeterinistic behaviour is fundaental for the validity of the specification. As pointed out in e.g. [10] and [12], security properties are in general not preserved by standard refineent. If nondeterinis is used as a eans to hide the internal workings of a syste, it is essential that it is not treated as underspecification, which allows eliination of all uncertainty (nondeterinis) in a refineent. In [14] Roscoe points out that using inherent nondeterinis ensures security as it prevents the aking of any inference about the possible outcoes, while for nondeterinis based on underspecification there are three possible conclusions about the security of a syste: secure, insecure, or don t know. Hence, it akes things a lot easier if the specification language provides a way to distinguish between these two ways of using nondeterinis. In the setting of UML interactions, the operator alt is used to specify alternative behaviours. As the UML standard [13] is rather vague on whether these alternatives represent underspecification or inherent nondeterinis, people interpret the sae interaction differently, leading to confusion. This could be avoided by having two different operators for specifying alternative behaviours, as we have in STAIRS. This is particularly iportant as the partiality of interactions akes it iportant to know which of the described scenarios represent significantly different behaviours and which scenarios only serve as exaples of how to achieve the sae purpose. The reainder of this paper is structured into six sections. Section 2 introduces the basic STAIRS foralis, while Section 3 uses this in an exaple specification illustrating nondeterinis. In Section 4 we extend the foralis with guards, and in Section 5 we discuss refineent in STAIRS with ephasis on nondeterinis. Section 6 defines what it eans for a syste to be a correct ipleentation of a STAIRS specification. Section 7 provides a brief suary and relates STAIRS to approaches known fro the literature.

6 4 R. K. RUNDE, Ø. HAUGEN, K. STØLEN 2. Background: UML interactions with denotational trace seantics In this section, we present the basic STAIRS foralis. Section 2.1 gives the fundaental trace echaniss. In Section 2.2 we present our textual syntax for interactions, while Section 2.3 forally defines denotational trace seantics for UML interactions. 2.1 Representing executions by traces In STAIRS, we define the seantics of interactions by using sequences of events. By A ω we denote the set of all finite and infinite sequences over the set A. We use to the denote the epty sequence. Moreover, by e 1,e 2,...,e we denote the sequence of eleents, whose first eleent is e 1, whose second eleent is e 2, and so on. We define the functions # A ω N 0 { }, [ ] A ω N A to yield the length and the nth eleent of a sequence. Hence, #a yields the nuber of eleents in a and a[n] yields a s nth eleent if n #a. We also need functions for concatenation, truncation and filtering: A ω A ω A ω, A ω N 0 A ω, S P(A) A ω A ω Concatenating two sequences iplies gluing the together. Hence, a 1 a 2 denotes a sequence of length #a 1 + #a 2 that equals a 1 if a 1 is infinite, and is prefixed by a 1 and suffixed by a 2, otherwise. For any 0 i #a, we define a i to denote the prefix of a of length i. The filtering function S is used to filter away eleents. By B S a we denote the sequence obtained fro the sequence a by reoving all eleents in a that are not in the set of eleents B. For exaple, we have that {1,3} S 1,1,2,1,3,2 = 1,1,1,3 A trace h is a sequence of events, used to represent a syste run. For any single essage, transission ust happen before reception if both events are present. Thus we get the following well-foredness requireent on traces, stating that if at any point in the trace we have a transission event, up to that point we ust have had at least as any transissions as receptions of that particular essage: i [1,#h] : k.h[i] =! #(({!} {.h[i]}) S h i ) > #(({?} {.h[i]}) S h i ) H denotes the set of all well-fored traces.

7 REFINING UML INTERACTIONS 5 Interaction Epty Event Weak sequencing Refuse Assert Potential alternatives Mandatory alternatives Loop Epty skip Event Kind Message Kind Transission Reception Transission! Reception? Message ( Signal, Transitter, Receiver ) Transitter Lifeline Receiver Lifeline Refuse refuse [ Interaction ] Assert assert [ Interaction ] Potential alternatives alt [ Interaction list ] Mandatory alternatives xalt [ Interaction list ] Loop loop Set [ Interaction ] Weak sequencing seq [ Interaction list ] Interaction list Interaction Interaction list, Interaction Figure 1: Syntax of interactions 2.2 Syntax of interactions The set of syntactically correct interactions, denoted by D, is defined by the BNF-graar in Fig. 1. Signal represents the actual content of a essage, Lifeline is the nae of a lifeline (representing a coponent) in the diagra and Set should be an expression that evaluates to a subset of N 0 (the natural nubers including 0). As can be seen fro the definition, a essage is a triple (s,tr,re) of a signal s, a transitter tr, and a receiver re. As a shorthand, we will often use the nae of the signal to stand for the whole essage in cases where the transitter and receiver are clear fro the context. We let L denote the set of all lifelines, and M denote the set of all essages. We distinguish between two kinds of events; a transission event tagged by an exclaation ark! represents the transission of a essage, while a reception event tagged by a question ark? represents the reception of a essage. E denotes the set of all events, while K denotes {!,?}. We define the functions k. E K,. E M, tr.,re. E L to yield the kind, essage, transitter and receiver of an event, respectively.

8 6 R. K. RUNDE, Ø. HAUGEN, K. STØLEN We also define the functions ll. D P(L), ev. D P(E), sg. D P(M) to yield the set of lifelines, events and essages of an interaction, respectively. Interactions are built fro events through the application of various operators as defined by the graar in Fig. 1. We do not cover the coplete set of operators in UML 2.0 [13], but rather focus on a few essential operators. These fundaental operators ay be used to define other useful, high-level operators as deonstrated in Section 5.2. See [7] for STAIRS definitions of additional operators like parallel execution and gates. The operators assert, alt, seq and loop are UML 2.0 operators. The operator xalt is new, proposed in [9] to odel andatory alternatives, i.e. alternatives that ust all be present in the final ipleentation. For negation, UML 2.0 uses the operator neg. However, this operator is used in several contexts, with slightly different eanings as we explain in [15]. Therefore, we have in this paper chosen to introduce a new operator refuse that covers one of these traditional uses of neg. We only consider interactions that are well-fored in the sense that if both the transitter and the receiver lifelines of a essage are present in the diagra, then both the transission and the reception event of that essage ust be present as well. Forally: sg.d : (#ev.d > 1 tr. ll.d re. ll.d) # { e ev.d k.e =!.e = } = # { e ev.d k.e =?.e = } where { } denotes a ulti-set and # is overloaded to yield the nuber of eleents in such a set. A ulti-set is needed here as the sae essage (consisting of a signal, a transitter and a receiver) ay occur ore than once in the sae diagra. Also, we assue that for all operators except fro seq, the operand(s) consist only of coplete essages, i.e. essages with both the transission and the reception event within the operand. 2.3 Seantics of interactions The seantics of interactions is defined by a function [ ] that for any interaction d yields a set [ d ] of interaction obligations. The ter obligation is used to explicitly convey that any ipleentation of a specification is obliged to fulfil each specified alternative. (What it forally eans to fulfil an obligation is discussed in Section 6.) An interaction obligation is a pair (p,n) of sets of traces. The first set p represents positive traces that ay be the result of running the final syste, while the second set n represents negative traces that ust not appear in the ipleentation of the obligation. Traces not defined as positive or negative are called inconclusive. As will be forally defined in Section 5, a refineent ay later redefine (soe of)

9 REFINING UML INTERACTIONS 7 Sybol Stands for d interaction D list of interactions, separated by coa h trace s, p, n trace set o interaction obligation O set of interaction obligations Table I: Notational conventions these inconclusive traces as positive or negative. An obligation pair (p, n) is contradictory if p n. The epty diagra, denoted by skip, is a specification without any events that corresponds to a progra doing nothing. The epty diagra defines the epty trace as positive: [ skip ] def = {({ }, )} (1) For an interaction consisting of a single event e, its seantics is given by: [ e ] def = {({ e }, )} (2) The actual content of the essages is not significant for the purpose of this paper. Hence, we do not give any seantic interpretation of essages as such. The rest of this section will define the seantics of the different coposition operators described briefly in Section 2.2. Table I lists the notational conventions that will be used in the following definitions Weak sequencing Weak sequencing is the iplicit coposition echanis cobining constructs of an interaction. The operator seq is defined by the following invariants: The ordering of events within each of the operands is aintained in the result. Events on different lifelines fro different operands ay coe in any order. Events on the sae lifeline fro different operands are ordered such that an event of the first operand coes before that of the second operand, and so on. First, we define weak sequencing of trace sets: s 1 s 2 def = {h H h 1 s 1,h 2 s 2 : l L : (3) e.l S h = e.l S h 1 e.l S h 2 }

10 8 R. K. RUNDE, Ø. HAUGEN, K. STØLEN sd W L1 L2 x y Figure 2: Weak sequencing where e.l denotes the set of events that ay take place on the lifeline l. Forally: e.l def = {e E (k.e =! tr.e = l) (k.e =? re.e = l} (4) Weak sequencing of interaction obligations is defined as: (p 1,n 1 ) (p 2,n 2 ) def = (p 1 p 2,(n 1 p 2 ) (n 1 n 2 ) (p 1 n 2 )) (5) Notice that all traces obtained by cobining a negative and a positive traceset, will also be negative. Weak sequencing of sets of interaction obligations is defined as: O 1 O 2 def = {o 1 o 2 o 1 O 1 o 2 O 2 } (6) Finally, the seq construct is defined by: [ seq [d] ] [ seq [D,d] ] def = [ d ] def = [ seq [D] ] [ d ] (7) As an exaple, the interaction in Fig. 2 shows two essages both originating fro L1 and targeting L2. Its seantics is calculated as: [ W ] = [ seq [!x,?x,!y,?y] ] = (([!x ] [?x ]) [!y ]) [?y ] (Def. (7)) = (({({!x }, )} {({?x }, )}) {({!y }, )}) {({?y }, )} (Def. (2)) = ({({!x,?x }, )} {({!y }, )}) {({?y }, )} (Defs. (3) (6)) = {({!x,?x,!y,!x,!y,?x }, )} {({?y }, )} (Defs. (3) (6)) = {({!x,?x,!y,?y,!x,!y,?x,?y }, )} (Defs. (3) (6)) Hence, this interaction specifies one interaction obligation with two positive traces and no negative ones. The positive traces state that the transission of x ust be the first event to happen, but after that either y ay be transitted (by L1) or x ay be received (by L2).

11 REFINING UML INTERACTIONS 9 sd A L1 L2 sd A L1 L2 alt x xalt x y y (a) Potential alternatives (b) Mandatory alternatives Figure 3: Specifying alternatives Negative behaviour The refuse construct defines negative traces: [ refuse [d] ] def = {(,p n) (p,n) [ d ]} (8) Notice that a negative trace cannot be ade positive by reapplying refuse. Negative traces reain negative, since negation should be seen as an operation that characterizes traces absolutely and not relatively Assertion The assert construct akes all inconclusive traces negative. Except for that the sets of positive and negative traces are left unchanged: [ assert [d] ] def = {(p,n (H \ p)) (p,n) [ d ]} (9) Notice that contradictory obligation pairs reain contradictory Potential alternatives The alt construct is used when specifying underspecification, i.e. to define potential traces that are equivalent in the sense that it is sufficient for an ipleentation to include only one of the. The seantics of alt is the inner union of each point-wise selection of interaction obligations fro its operands: [ alt [d 1,...,d ] ] def = { {o 1,...,o } i [1,] : o i [ d i ] } (10) The inner union of interaction obligations is defined as: i [1,] (p i,n i ) def = ( i [1,] p i, i [1,] n i ) (11)

12 10 R. K. RUNDE, Ø. HAUGEN, K. STØLEN Fig. 3(a) gives a siple exaple using the alt construct. The dashed horizontal line separates the operands. We get: [ A ] = [ alt [seq [!x,?x],seq [!y,?y]] ] = { { ({!x,?x }, ),({!y,?y }, ) } } (Defs. (3) (7),(10)) = { ({!x,?x,!y,?y }, ) } (Def. (11)) Mandatory alternatives The xalt construct is used to specify inherent nondeterinis, i.e. andatory alternatives that ust all be present in an ipleentation: [ xalt [d 1,... d ] ] def = i [1,] [ d i ] (12) Fig. 3(b) has the sae essages as Fig. 3(a), but separated by xalt instead of alt. In this case, we get two interaction obligations: Loop [ A ] = [ xalt [seq [!x,?x],seq [!y,?y]] ] = { [ seq [!x,?x] ], [ seq [!y,?y] ] } (Def. (12)) = { {({!x,?x }, )}, {({!y,?y }, )} } (Defs. (3) (7)) = { ({!x,?x }, ), ({!y,?y }, ) } (Def. of ) For a set of interaction obligations we define a finite loop construct µ n, where n N 0 denotes the nuber of ties the body of the loop is iterated. µ n O is defined inductively as follows: µ n O def = {({ }, )} if n = 0 O if n = 1 µ n 1 O O otherwise (13) For a definition of infinite loop, see [7]. In the UML 2.0 standard [13], loop is used together with liits stating the iniu and axiu nuber of ties the content of the loop should be executed. In our definition, the set I is a generalization of this, such that the nubers in I specify the possible alternatives for how any ties the loop content should be executed. Not all of these need to be actual alternatives in an ipleentation, eaning that the definition of loop uses the point-wise inner union between these alternatives, siilar to the definition of alt: [ loop I [d] ] def = { i I o i i I : o i µ i [ d ] } (14)

13 REFINING UML INTERACTIONS 11 sd L L1 L2 loop {0,1,2} x Figure 4: Looping As an exaple, the interaction in Fig. 4 has the following seantics: [ L ] = [ loop {0,1,2} [seq [!x,?x]] ] = { i {0,1,2} o i i {0,1,2} : o i µ i [ seq [!x,?x] ] } (Def. (14)) = { i {0,1,2} o i i {0,1,2} : o i µ i {({!x,?x }, )} } (Defs. (3) (7)) = { i {0,1,2} o i o 0 µ 0 {({!x,?x }, )} o 1 µ 1 {({!x,?x }, )} o 2 µ 2 {({!x,?x }, )} } = { i {0,1,2} o i o 0 {({ }, )} o 1 {({!x,?x }, )} o 2 {({!x,?x }, )} {({!x,?x }, )} } (Def. (13)) = { i {0,1,2} o i o 0 {({ }, )} o 1 {({!x,?x }, )} o 2 {({!x,?x,!x,?x,!x,!x,?x,?x }, )} } (Defs. (3) (6)) = { { ({ }, ), ({!x,?x }, ), ({!x,?x,!x,?x,!x,!x,?x,?x }, ) } } = { ({,!x,?x,!x,?x,!x,?x,!x,!x,?x,?x }, ) } (Def. (11)) 3. STAIRS and nondeterinis As seen in the previous section, weak sequencing ay result in several different traces with the sae events in a soewhat different order. These traces are alternative eans to achieve the sae goal, and they are therefore grouped into the sae interaction obligation as it is sufficient to keep only one of the in an ipleentation. In UML 2.0, the other eans to specify alternative behaviours is by using the operator alt. This is used both for specifying potential alternatives where keeping only one is sufficient, and for andatory alternatives that ust all be present in a correct ipleentation. In STAIRS, we have distinguished

14 12 R. K. RUNDE, Ø. HAUGEN, K. STØLEN cs C A:sender S:network B:receiver Figure 5: Coposite structure of context C sd Co A:sender S:network B:receiver Figure 6: Very siple counication these two uses by separating between our two operators alt and xalt. Each use of UML 2.0 alt corresponds in STAIRS to either alt or xalt. In this section we present an exaple illustrating the use of these two operators. Consider a situation where a sender counicates with a receiver through a network of type S as shown in the UML coposite structure diagra in Fig. 5 (notice that this is not an interaction). A very siple counication is shown by the interaction in Fig. 6, its seantics being: { ({!(,A,S),?(,A,S),!(,S,B),?(,S,B) }, ) } Next, we would like to specify that there is a need for redundant counication through the network S. That is, the network S needs to support ore than one way of bringing the essage fro one end of the network to the other. There ay be several reasons for requiring this redundancy: Several paths through the network will ake it easier to exploit the full capacity of the network. Multiple paths will ensure increased internal robustness of the network and as such iprove the availability of the full counication. Multiple paths will ake it ore difficult to attack the network to jeopardize the counication, and as such the counication security is iproved. We indicate in Fig. 7 a siple network architecture for S where there are alternative branches. A real counication network ay of course have far ore paths, but giving a few is sufficient for the purpose of this paper. We want to ake an interaction where we require two (different) counication

15 REFINING UML INTERACTIONS 13 cs S N1:N G:N N3:N N2:N N4:N Figure 7: Internal structure of the network S showing three counication paths possibilities, and we ay do this by introducing an xalt construct as shown in Fig. 8, where S is expanded according to the structure in Fig. 7. We have used xalt here in order to express that the network ust support at least two counication paths. Of course, for each concrete counication only one of the will be applied. After node N2, the network S has yet another branch giving two alternative paths. For the sake of the discussion we assue that it is not iportant to have both of these available, and so we specify the alternatives using alt and not xalt in Fig. 8. sd S_Co A:sender G:N N1:N N2:N N3:N N4:N B:receiver xalt alt Figure 8: Counication behaviour requiring two counication paths

16 14 R. K. RUNDE, Ø. HAUGEN, K. STØLEN Positive A->G->N1->B A->G->N2->N3->B A->G->N2->N4->B Negative Figure 9: Venn-diagra of the specification in Fig. 8 The seantics of S Co is: { ({!(,A,G),?(,A,G),!(, G, N1),?(,G,N1),!(,N1,B),?(,N1,B) }, ), ({!(,A,G),?(,A,G),!(,G, N2),?(,G,N2),!(,N2,N3),?(,N2,N3),!(,N3,B),?(,N3, B),!(,A,G),?(,A,G),!(,G, N2),?(, G,N2),!(,N2,N4),?(,N2,N4),!(,N4,B),?(,N4, B) }, ) } Fig. 9 illustrates this seantics using a specialized Venn-diagra with one ellipse for each interaction obligation. Traces not shown as positive or negative in an obligation are inconclusive for this obligation. Forally, S Co is a refineent of Co. Refineent will be forally defined in Section 5. In Section 5 we will also develop this exaple further, by giving soe possible refineents to illustrate the siilarities and differences between the two operators alt and xalt. But first, in the next section, we forally extend STAIRS with guards, which ay be used to specify the choice between alternatives. 4. Extending STAIRS with data and guards Although the focus of interactions is on the essages, the diagras ay also be decorated with data. The ost coon use of data in interactions is in guards, which is a echanis for choosing between alternatives. Data is also used in assignents and general constraints. In this section we extend our basic foralis with definitions of these concepts. The extension ensures that (sub-)interactions not including data have the sae seantics as before. 4.1 Data Since interactions ainly specify events and not data, the exact data values will ost of the tie be underspecified (or unspecified). Changes in the data ay in general happen at any tie, also when there is nothing in the diagra indicating such a change. As a consequence, in the seantic odel we do not include data as such. Instead, data is represented indirectly through events representing its use in assignents, constraints, and guards.

17 REFINING UML INTERACTIONS 15 Interaction Epty Event Weak sequencing Refuse Assert Guarded alt Guarded xalt Loop Assignent Constraint Assignent assign ( Variable, Expression ) Constraint constr ( Constraint ) Guarded alt alt [ Guarded list ] Guarded xalt xalt [ Guarded list ] Guarded list Guarded interaction Guarded list, Guarded interaction Guarded interaction Guard Interaction Guard Constraint Figure 10: Syntax of interactions with data Forally, we extend the syntax of interactions as defined by the BNFgraar in Fig. 10. Nonterinals that are unchanged fro the original syntax in Fig. 1 are not repeated. Variable should be either a global variable or a variable local to the lifeline on which the assignent is placed (not shown in our textual syntax), while Expression is a atheatical expression and Constraint an expression that evaluates to true or false. If an operand of guarded alt or guarded xalt does not contain an explicit guard, we interpret this as being the guard true. In the seantics, we extend the set of trace events with the two special events write (for assignents) and check (for constraints). We also need the notion of a state. Let Var be the set of all variables and Val be the set of all variable values. A state σ is then a total function assigning a value to each variable. Forally: σ Var Val For any expression expr, we use expr(σ) to denote its value in σ. 4.2 Assignent Explicit specification of variable values ay be done by using assignents. In UML 2.0, assignents are written inside a rounded box on the appropriate lifeline, as illustrated in Fig. 11. Seantically, we represent an assignent var = expr by the special event write(σ,σ ) where σ is the state iediately before the assignent and σ the state iediately after: [ assign(var,expr) ] { ({ write(σ,σ ) σ (var) = expr(σ) def = (15) v Var : (v = var σ (v) = σ(v))}, ) }

18 16 R. K. RUNDE, Ø. HAUGEN, K. STØLEN sd assign A avar = avar + 1 Figure 11: Assignent sd constraint A B { avar = 0 } { avar > 0 } Figure 12: Constraint 4.3 Constraints (state invariants) In UML 2.0, constraints are written within curly brackets, as illustrated in Fig. 12. A constraint is a restriction that ust be fulfilled by the syste, eaning that we have a negative trace if the constraint is broken. Seantically, a constraint is represented by the special event check(σ), where σ is the state in which the constraint is evaluated: [ constr(c) ] def = (16) { ({ check(σ) c(σ)}, { check(σ) c(σ)}) } This definition ensures that if the constraint is a tautology, then the seantics of constr(c) has no negative traces, and that a contradiction gives no positive traces: [ constr(true) ] = {({ check(σ) true(σ)}, { check(σ) false(σ)})} = {({ check(σ) σ Var Val}, )} [ constr(false) ] = {({ check(σ) false(σ)}, { check(σ) true(σ)})} = {(, { check(σ) σ Var Val})} Notice that one constraint in itself gives potentially an infinite nuber of syste traces, varying with respect to the state coponent only.

19 REFINING UML INTERACTIONS 17 As an exaple of the use of constraints in an interaction, the coplete seantics of the interaction in Fig. 12 ay be calculated as: [ constraint ] = [ seq [constr(avar = 0),!,?,constr(avar > 0)] ] = ( ( [ constr(avar = 0) ] [! ] ) [? ] ) [ constr(avar > 0) ] (Def. (7)) = ( ( [ constr(avar = 0) ] {({! }, )} ) {({? }, )} ) [ constr(avar > 0) ] (Def. (2)) = ( ( {({ check(σ) σ(avar) = 0}, { check(σ) σ(avar) 0})} {({! }, )} ) {({? }, )} ) {({ check(σ ) σ (avar) > 0}, { check(σ ) σ (avar) 0})} (Def. (16)) = ( { ({ check(σ) σ(avar) = 0} {! }, { check(σ) σ(avar) 0} {! } { check(σ) σ(avar) 0} { check(σ) σ(avar) = 0} ) } {({? }, )} ) {({ check(σ ) σ (avar) > 0}, { check(σ ) σ (avar) 0})} (Defs. (5) (6)) = ( { ({ check(σ),! σ(avar) = 0} {!,check(σ) σ(avar) = 0}, { check(σ),! σ(avar) 0} {!,check(σ) σ(avar) 0}) } {({? }, )} ) {({ check(σ ) σ (avar) > 0}, { check(σ ) σ (avar) 0})} (Def. (3)) = { ({ check(σ),!,? σ(avar) = 0} {!,check(σ),? σ(avar) = 0}, { check(σ),!,? σ(avar) 0} {!,check(σ),? σ(avar) 0}) } {({ check(σ ) σ (avar) > 0}, { check(σ ) σ (avar) 0})} (Defs. (3) (6)) = { ({ check(σ),!,?,check(σ ) σ(avar) = 0 σ (avar) > 0)} {!,check(σ),?,check(σ ) σ(avar) = 0 σ (avar) > 0}, { check(σ),!,?,check(σ ) σ(avar) 0 σ (avar) 0} {!,check(σ),?,check(σ ) σ(avar) 0 σ (avar) 0}) } (Defs. (3) (6), and forula anipulation) 4.4 Guards (interaction constraints) According to UML 2.0, alternatives (and other cobined fragents) in an interaction ay be guarded by an interaction constraint (also called a guard). A guard is a special kind of constraint that ay only occur at the beginning of the interaction operand in question. As opposed to general constraints,

20 18 R. K. RUNDE, Ø. HAUGEN, K. STØLEN sd guards A B alt [ avar = 0 ] x [ avar >= 0 ] y Figure 13: Guards guards are written inside square brackets, as illustrated in Fig. 13. As the exaple illustrates, the guards used in an alt (or xalt) ay be overlapping and need not be exhaustive. If the guard is true, the interaction operand describes positive traces of the syste. The seantics in the case of a false guard is not stated explicitly in the UML 2.0 standard [13]. However, with guards being a specialization of general constraints, it is natural to interpret traces with a false guard as negative. As will be deonstrated in Section 5, this is advantageous as it eans that adding guards to an alt/xalt-construct constitutes a valid refineent step. A side effect of this is that we will be able to odel guards by using the ore general notion of constraints as defined in the previous section Guarded alt UML 2.0 [13] states that if none of the operands of an alt construct has a guard that evaluates to true, none of the operands are executed and the reainder of the enclosing interaction is executed. This gives the following seantics for guarded alt: [ alt [c 1 d 1,...,c d ] ] { {o 1,...,o,({ check(σ) ( j [1,] c j)(σ)}, )} def = (17) i [1,] : o i [ seq [constr(c i ),d i ] ] } The seantics of Fig. 13 is inforally illustrated in Fig. 14. Forally, its

21 REFINING UML INTERACTIONS 19 Positive Negative [avar < 0] <> [avar = 0] <!x,?x> [avar >= 0] <!y,?y> [avar 0] <!x,?x> [avar < 0] <!y,?y> Figure 14: Seantics of guarded alt in Fig. 13 coplete seantics ay be calculated as: [ guards ] = [ alt [avar = 0 seq [!x,?x], avar 0 seq [!y,?y] ] ] = { { ({ check(σ),!x,?x σ(avar) = 0}, { check(σ),!x,?x σ(avar) 0}), ({ check(σ),!y,?y σ(avar) 0}, { check(σ),!y,?y σ(avar) < 0}), (Defs. (3) (7), ({ check(σ) σ(avar) < 0}, )} } (16),(17)) = { ({ check(σ),!x,?x σ(avar) = 0} { check(σ),!y,?y σ(avar) 0} { check(σ) σ(avar) < 0}, { check(σ),!x,?x σ(avar) 0} { check(σ),!y,?y σ(avar) < 0} } (Def. (11)) Definition (17) giving the seantics of guarded alt is consistent with definition (10) of unguarded alt in Section 2.3. In our new setting, a specification alt [D] without guards is interpreted as the specification alt [D ] where D is the sae list of interactions as D, each one guarded by true. Calculating this seantics using definition (17), gives us the sae seantics as definition (10) when abstracting away all check-events. This is proved in Appendix C Guarded xalt We define the seantics of guarded xalt as: [ xalt [c 1 d 1,...,c d ] ] def = i [1,] [ seq [constr(c i ),d i ] ] (18) Unlike guarded alt, the seantics of guarded xalt does not iplicitly include the case where all guards are false, since xalt is used to specify explicit choices that ust be present in the ipleentation. As an exaple, the seantics of Fig. 13 with alt replaced by xalt, is inforally illustrated in Fig. 15. Forally, its coplete seantics ay be

22 20 R. K. RUNDE, Ø. HAUGEN, K. STØLEN Positive Negative [avar = 0] <!x,?x> [avar 0] <!x,?x> [avar >= 0] <!y,?y> [avar < 0] <!y,?y> Figure 15: Seantics of guarded xalt in Fig. 13 calculated as: [ guards ] = [ xalt [avar = 0 seq [!x,?x], avar 0 seq [!y,?y] ] ] = { {({ check(σ),!x,?x σ(avar) = 0}, { check(σ),!x,?x σ(avar) 0})}, {({ check(σ),!y,?y σ(avar) 0}, (Defs. (3) (7), { check(σ),!y,?y σ(avar) < 0})} } (16),(18)) = { ({ check(σ),!x,?x σ(avar) = 0}, { check(σ),!x,?x σ(avar) 0}), ({ check(σ),!y,?y σ(avar) 0}, { check(σ),!y,?y σ(avar) < 0}) } (Def. ) As for alt, reoving the guards in definition (18) gives the original xaltseantics in definition (12) as proved in Appendix C. 5. Refineent In this section we discuss soe iportant aspects of refineent in the setting of STAIRS. Section 5.1 gives the necessary background for this discussion, presenting the ain refineent definitions. In the rest of Section 5 we focus on underspecification and inherent nondeterinis, and how guards ay be introduced as a refineent step in both cases. 5.1 Background: Foral definitions Refineent eans to add inforation to a specification such that the specification becoes ore coplete. This ay be achieved by categorizing inconclusive traces as either positive or negative, or by reducing the set of positive traces. Negative traces always reain negative. A specification ay also becoe ore coplete by introducing ore details.

23 REFINING UML INTERACTIONS Glass-box refineent Forally, an interaction obligation (p,n ) is a refineent of an interaction obligation (p,n), written (p,n) r (p,n ), iff n n p p n (19) An interaction d is a glass-box refineent of an interaction d, written d g d, iff o [ d ] : o [ d ] : o r o (20) Theore. The refineent operator g is reflexive: d g d transitive: d g d d g d d g d onotonic with respect to refuse, loop, seq, (guarded) alt and (guarded) xalt: d g d refuse [d] g refuse [d ] d g d loop I [d] g loop I [d ] d 1 g d 1,...,d g d seq [d 1,...,d ] g seq [d 1,...,d ] d 1 g d 1,...,d g d alt [d 1,...,d ] g alt [d 1,...,d ] d 1 g d 1,...,d g d xalt [d 1,...,d ] g xalt [d 1,...,d ] Proof. Reflexivity, transitivity and onotonicity with respect to seq, loop and unguarded alt and xalt is proved in [7]. Monotonicity with respect to refuse and guarded alt and xalt is proved in Appendix E. By definition (20), new interaction obligations ay be freely added to the specification, thus increasing the andatory nondeterinis required of an ipleentation. Adding new obligations is an iportant aspect of the STAIRS ethodology. Soeties, however, it is desirable to restrict this possibility. A ore restrictive notion of refineent is liited glass-box refineent, where each obligation in the new refined interaction ust correspond to an obligation in the original interaction. Forally, an interaction d is a liited glass-box refineent of an interaction d, written d l d, iff d g d o [ d ] : o [ d ] : o r o (21) The refineent theore above is valid also when replacing g with l, as proved in Appendix D (reflexivity and transitivity) and Appendix E (onotonicity). Notice that a step of refineent ay still increase the total nuber of obligations, but only if two different obligations in [ d ] refine the sae obligation in [ d ]. Methodologically, a STAIRS specification would typically be developed by using g initially and switching to the ore restrictive l after the desired level of nondeterinis in the specification has been reached.

24 22 R. K. RUNDE, Ø. HAUGEN, K. STØLEN Black-box refineent Black-box refineent ay be understood as refineent restricted to the externally visible behaviour. We define the function ext H P(L) H to yield the trace obtained fro the trace given as first arguent by filtering away those events that are internal with respect to the set of lifelines given as second arguent: ext(h,l) def = {e E tr.e l re.e l} S h (22) The ext operator is overloaded to sets of traces, to pairs of sets of traces, and sets of pairs of sets of traces in the standard pointwise anner: ext(s, l) ext((p,n),l) ext(o, l) def = {ext(h,l) h s} (23) def = (ext(p, l), ext(n, l)) (24) def = {ext((p,n),l) (p,n) O} (25) An interaction d is a black-box refineent of an interaction d, written d b d, iff o ext([ d ],ll.d) : o ext([ d ],ll.d ) : o r o (26) The refineent theore above is valid also when replacing g with b, as the properties are independent of the content of the actual traces. Black-box refineents will often include lifeline decopositions that are not externally visible. Soe lifeline decopositions ay also be externally visible due to a change in the sender or receiver of a essage. We have already used this in Fig. 8, where the network S was decoposed into several nodes. Forally, an interaction d is a lifeline decoposition of an interaction d with respect to a lifeline substitution ls, written d ls l d, iff d b subst(d,ls) (27) where ls L L is a function defining the lifeline substitution and the function subst(d, ls) yields the interaction d with every lifeline l in d substituted with the lifeline ls(l). 5.2 Adding positive behaviour We now return to our running exaple fro Section 3. Even with two different counication paths, we have no guarantee that any of the will be available at a certain tie. This is ade explicit in Fig. 16, where the epty diagra (i.e. skip) is added as a third operand to the xalt-construct. When this operand is selected, we get a positive trace consisting of only

25 REFINING UML INTERACTIONS 23 sd N_Co A:sender G:N N1:N N2:N N3:N N4:N B:receiver xalt alt Figure 16: Refineent by adding behaviour Positive A->G->N1->B A->G->N2->N3->B A->G->N2->N4->B A->G Negative Figure 17: Seantics of N Co (Fig. 16) two events, the transission of fro A to G, and the reception at G. No further counication will take place, and B will never receive the essage. The seantics of N Co is illustrated in Fig. 17. Coparing this with Fig. 9, which illustrates the seantics of S Co (Fig. 8), we see that every interaction obligation given by S Co is also an interaction obligation by N Co. By definitions (19) (20), this eans that the odified specification is a valid refineent of the original one, S Co g N Co. The last obligation in Fig. 17 illustrates that new obligations ay be added freely when using standard glass-box refineent, g. Assue now that our counication network describes the eergency network used by the police, that a police officer needs to counicate, but that the counication for soe reason fails. In practice, a police officer ay grab his personal obile phone and call his colleague. This is not a andatory choice (the police are not set up with personal obile phones),

26 24 R. K. RUNDE, Ø. HAUGEN, K. STØLEN sd M_Co A:sender G:N N1:N N2:N N3:N N4:N Mobile:N B:receiver xalt alt opt Figure 18: Refineent by adding behaviour Positive A->G->N1->B A->G->N2->N3->B A->G->N2->N4->B A->G A->G->Mobile->B Negative Figure 19: Seantics of M Co (Fig. 18) but ay be used as an alternative. The resulting specification is shown in Fig. 18. The opt-construct is a high-level operator, which ay be defined as opt d def = dalt skip (28) The odified specification affects only the last of the interaction obligations in Fig. 17, where a positive behaviour is added as illustrated in Fig. 19. By definition (19), this is a valid refineent as the negative trace-sets in both interaction obligations are epty and the positive trace-set in the N Co one is a subset of the new positive trace set in the M Co one: {!(,A,G),?(,A,G) } {!(,A,G),?(,A,G),!(,A,G),?(,A,G),!(,G,Mobile),?(,G,Mobile),!(,Mobile,B),?(,Mobile,B) } Notice that adding an extra lifeline (the obile phone) to the interaction

27 REFINING UML INTERACTIONS 25 sd A_Co A:sender G:N N1:N N2:N N3:N N4:N Mobile:N B:receiver assert xalt alt opt Figure 20: Adding negative behaviour Positive A->G->N1->B A->G->N2->N3->B A->G->N2->N4->B A->G A->G->Mobile->B Negative everything else everything else everything else Figure 21: Seantics of A Co (Fig. 20) is unprobleatic, as all traces involving this new lifeline were considered inconclusive in the original interaction. 5.3 Adding negative behaviour The refineent exaples in the previous section categorized earlier inconclusive traces as positive. Siilarly, earlier inconclusive traces ay be categorized as negative, either by specifying the negative traces explicitly through the use of refuse, or by using assert. In our network exaple, we decide that M Co is a coplete description of the possible behaviours, and that everything not in the interaction should be considered negative. This gives us the interaction in Fig. 20. The seantics of A Co is illustrated in Fig. 21. Coparing this with Fig. 19, which illustrates the seantics of M Co, we see that A Co is obviously a refineent of M Co, as we have the sae positive trace-sets for both specifications and the original epty negative trace-sets are subsets

28 26 R. K. RUNDE, Ø. HAUGEN, K. STØLEN N2:N N3:N N4:N B:receiver alt refuse Figure 22: Redefining positive behaviour as negative Positive A->G->N1->B A->G->N2->N3->B A->G A->G->Mobile->B Negative everything else A->G->N2->N4->B everything else everything else Figure 23: Seantics of A Co with the refineent in Fig. 22 of any set. 5.4 Redefining positive behaviour as negative Refineent ay also be used to reduce the set of positive traces by redefining the as negative. Looking at the specification in Fig. 20, we ay decide that there really is no need to have both counication choices specified by the alt-construct. A refineent of this sub-specification could then be as given by Fig. 22. The coplete seantics for this refineent is illustrated in Fig. 23. We see that the refined specification only affects the obligation in the iddle. By definition (19), this is a valid refineent step as the negative trace-set is extended and the traces that were previously positive are now either positive or negative. Another possible refineent of A Co could be to specify how the choice between the different counication paths should be ade. In the case of our eergency network, using a obile phone should only be an option if the ain network fails. In the interaction in Fig. 24, the node G akes the choice between the different alternatives specified by the xalt-construct. Siilarly, N2 akes the choice between the alt-operands. We have assued that G and N2 have inforation about the capacity of

29 REFINING UML INTERACTIONS 27 sd G_Co A:sender G:N N1:N N2:N N3:N N4:N Mobile:N B:receiver assert xalt [N1 capacity ok] [N2 capacity ok] alt [N3 capacity ok] [N4 capacity ok] opt [else] Figure 24: Introducing guards the different nodes. This ay in practice be achieved either by continuous inforation back fro the nodes (not shown in the described behaviour) or through evaluating the counication historically relative to known paraeters of the nodes. For our purpose, it is not significant how G and N2 get their data. It is interesting, however, that for xalt the two first guards ay both be true, both false, or one true and one false. All of these situations represent cases in real life. If both guards are true, the choice between the two paths ay be done arbitrarily. If both guards are false, the else operand coes into effect. We have not specified what should happen if both guards are false in the alt-fragent. However, according to definition (17) giving the seantics of guarded alt, this is equal to the epty trace, i.e. no further counication takes place. Fig. 25 illustrates the seantics of G Co. All traces with a false guard are negative as specified by definitions (16) (18). This akes G Co a valid refineent of A Co. In general, introducing guards in an alt- or xalt-construct will always be a legal refineent step as proved in Appendix E. 5.5 Adding ore details As another exaple, assue that our sender and receiver suspect that soewhere inside the network there is soeone listening to and possibly anipulating their essages. They would like to encrypt their essages and agree (openly) to exchange inforation to set up a secret key that they shall use

30 28 R. K. RUNDE, Ø. HAUGEN, K. STØLEN Positive Negative A->G->[N1 ok]->n1->b A->G->[N1 not ok]->n1->b everything else Positive Negative A->G->[N2 ok]->n2->[n3 ok]->n3->b A->G->[N2 ok]->n2->[n4 ok]->n4->b A->G->[N2 ok]->n2->[n3 not ok and N4 not ok] A->G->[N2 not ok]->n2->[n3 ok or not ok]->n3->b A->G->[N2 not ok]->n2->[n4 ok or not ok]->n4->b A->G->[N2 ok]->n2->[n3 not ok]->n3->b A->G->[N2 ok]->n2->[n4 not ok]->n4->b everything else Positive Negative A->G->[N1 not ok and N2 not ok] A->G->[N1 not ok and N2 not ok]->mobile->b A->G->[N1 ok or N2 ok] A->G->[N1 ok or N2 ok]->mobile->b everything else Figure 25: Seantics of Fig. 24 for subsequent encryption. Following the procedure outlined by Sion Singh in [16] on how to achieve exchanging of secret keys through insecure counication, we need to be able to describe a nuber of siilar sequences differing basically in the value of soe critical nubers. In Fig. 26 we have shown the protocol with a generalized notation for xalt. We have supplied the xalt with an extra clause which gives one or ore paraeters with finite doains associated. This generalized notation is identical to replicating the operand for all values of the variable inside the doain. The behaviour of Fig. 26 eans that the sender chooses a natural nuber (between 0 and 255 in this exaple) and fro that calculates another natural (here in the range ), and this calculated nuber is transitted over the insecure network to the receiver. The receiver does exactly the sae the other way with a nuber that he/she chooses. Fro the nubers that they initially chose and the nubers that they received fro each other, they are able to calculate a coon key, p. This key is secret since the network does not have sufficient inforation to calculate it directly. (Of course, in a real situation the one-way function will be ore coplicated and the nubers far larger.)

31 REFINING UML INTERACTIONS 29 sd Secure A:sender S:network B:receiver xalt {na: } [ a = (7**na) od 11 ] garbled(a) garbled(a) xalt {nb: } [ b = (7**nb) od 11 ] garbled(b) garbled(b) p = (b**na) od 11 p = (a**nb) od 11 Figure 26: Generalized xalt for the description of establishing a coon secret key To give a couple of concrete exaples, we assue in Fig. 27 that the sender has only the naturals 2 and 3 to choose fro, while the receiver chooses only fro 4 and 5. The specification in Fig. 27 gives rise to four interaction obligations (with p = 1,5,9 or 10), one for each possible cobination of values for the two lifelines. The choice between these should be nondeterinistic, giving the intruder four possible values for the key. With ore alternatives for na and nb, as in the original specification, we get a lot of obligations and potential keys aking it difficult for the intruder to find the correct key by plain guessing or by trial-and-error. In Fig. 28 we indicate a possible decoposition of the sender A in the first xalt-construct in Fig. 26. A is decoposed into a rando generator and a sender lifeline C. The generator loops a sufficient nuber of ties, each tie sending either 0 or 1 to the sender. Taken together, these essages will constitute the binary representation of the nuber na in Fig. 26. Using xalt here, eans that both 0 and 1 ust be possible in each round in the loop, giving a totally nondeterinistic choice for na. Siple calculations show that we will get the sae possible values for na in both diagras, leading to the sae obligations and the sae values of the paraeter a in both cases, eaning that the decoposition is indeed a valid refineent.

32 30 R. K. RUNDE, Ø. HAUGEN, K. STØLEN sd Secure A:sender S:network B:receiver xalt [a = (7**2) od 11 == 5] garbled(5) garbled(5) [a = (7**3) od 11 == 2] garbled(2) garbled(2) xalt garbled(3) b = (7**4) od 11 == 3] garbled(3) garbled(10) b = (7**5) od 11 == 10] garbled(10) p = (b**na) od 11 p = (a**nb) od 11 Figure 27: A few exaple-values for the generalized xalt 6. Ipleentation In this section we explain what we ean by an ipleentation and what it eans for an ipleentation to be correct with respect to a STAIRS specification. Intuitively, if the specification has only one interaction obligation, a correct ipleentation ay only produce traces belonging to the positive and inconclusive trace sets of the obligation, i.e. no negative trace ust be produced by the ipleentation. With ore than one interaction obligation, we ay in general find the sae trace being positive in one obligation while negative in another. Seantically, we represent ipleentations in the sae way as we represent interactions, naely by sets of interaction obligations. Fro a seantic point of view, an ipleentation is a special kind of specification characterized by the following three criteria: