Describing interactions between MSC components: the MSC connectors

Computer Networks 42 (2003) 323–342 www.elsevier.com/locate/comnet

Describing interactions between MSC components: the MSC connectors Peter Graubmann Corporate Department Technology, Siemens AG, Otto-Hahn-Ring 6, M€unchen D-31739, Germany

Abstract The description of the interactions between components play a prominent role in todayÕs compositional system development strategies. In particular, system family engineering focuses on the description and evolution of interfaces. The communication between the parts of a system, (that is, its components) follows interaction patterns that are expressed in the component-oriented world as software connectors. Message sequence charts (MSCs) are well suited to provide the adequate descriptions for both components and connectors. However, a few new language constructs are required to achieve an adequate description of the component communication. The syntax of these constructs is presented here, together with a brief discussion of their semantics. The interaction of MSC components via an MSC connector is defined by matching the component and connector interface descriptions, based upon a partitioning of the component environment. MSC connectors may be considered as a high-level message construct for the refinement of the communication behaviour, a construct which is still missing in the MSC language. The concepts, originally derived from system family and component oriented software engineering, turn out to be useful as well for interaction abstractions between the smaller MSC language constructs such as operator expressions or plain instances, thus providing a uniform approach to the abstraction of communication features in the MSC language.
2003 Elsevier Science B.V. All rights reserved. Keywords: Component; Interface; Interface protocol; Compositionality; Message sequence chart; High level message sequence chart; MSC connector; Component oriented software development; System family engineering; Product line

1. Introduction Essentially, the message sequence charts (MSC) language is an elegant, intuitive trace language that provides an easy way to describe the behaviour of systems or their parts.

E-mail address: [email protected] (P. Graubmann).

During the history of MSC, different styles of use have developed. In the beginning, MSCs were mainly used as a means to express sample or paradigmatic behaviour: single MSCs were specified to exemplify and discuss specific sequences of events. Later, when more elaborated structuring means and the HMSC (High-level MSC) concepts were available, it became reasonable to describe, on the chosen abstraction level, a more complete system (or subsystem) behaviour: related MSCs were specified and put together in a structured way. Obviously, to keep specifications readable, it

1389-1286/03/$ - see front matter
2003 Elsevier Science B.V. All rights reserved. doi:10.1016/S1389-1286(03)00246-9

324

P. Graubmann / Computer Networks 42 (2003) 323–342

is still necessary to find the appropriate level of abstraction. Today, system development is more and more based on the use and re-use of components. This is particularly true for system families, where a group of related products (products with the same main characteristics but differing features, such as mobile phones) are derived from a common collection of components. In this case, since interfaces are the ‘‘glue’’ that ties the components together [1,2], interface description techniques that are capable of expressing the semantics of interfaces, in particular their behaviour, become of eminent importance. As long as just a ‘‘single’’ MSC is considered (that is, if only a certain behaviour trace has to be analysed on its own), one has only to deal with instances and messages between them, and with the messages from and to the ‘‘rest of the world’’–– in MSC terms, the environment. In such a case, a monolithic environment may be sufficient. However, as soon as systems are understood as a composition of components, the need of structuring the environment arises. Then it becomes necessary to express a little bit more precisely––from a logical point of view––which part of the ‘‘outside world’’ is involved in a particular interaction. Actually, grouping messages from and to the environment allows the logical identification of component roles, which is a prerequisite for defining component interfaces (see for example the unified modelling language (UML) approach to system design [3,4]). Combining components means to determine the appropriate interaction between the respective components in their particular roles. Thus, combining components results in defining the necessary communication protocols for their interaction. Within System Family Engineering (SFE), communication patterns providing for the interaction between various component variants have to be developed that can be re-used when new products of the system family are to be configured. The MSC connectors presented in the following sections are intended to provide a description means for these interaction protocols. They are the appropriate abstraction for the information interchange that is complementary to the MSC references and the operator expressions, which already

serve as behaviour abstractions in MSC-2000. MSC connectors also allow reasoning about the communication protocols in isolation and derivation of recurring interaction patterns, which can be used for the component composition. In addition, if the essential behaviour structures of the composed components are modelled as MSCs (preferably as High Level MSCs, MSC references or decomposed instances), the composition results can be analysed by investigating the application of the MSC connectors to the MSC component models. A first attempt towards a component-oriented view for MSC has been provided in [5] based on [6] by providing a generalisation of the parallel merge operation, which in MSC-2000 is defined as free interleaving. In [5], it has been argued that free interleaving is in general too weak and has to be enhanced by the inclusion of additional communication behaviour introducing further interrelations between the parallel components. However, the introduction of ‘‘gates’’ in HMSCs for that purpose can be seen only as a first step. The generalisation of the parallel merge operation proposed here is based on the usage of MSC connectors and an identification of events in the MSC connector and the MSC components that have to be connected. This generalised parallel merge operation for MSC obviously corresponds to the general parallel composition with synchronisation in process algebra languages [7]. The interface description and the structuring and partitioning of the environment, associated with the connector concept, may be viewed as a new and improved approach to the well known gate problem in MSC. This is particularly important since the gate concept contained in the MSC standard [8–10] appears to be quite intricate. Since in addition it leads to several consistency problems [11], it has never found broad acceptance. Thus, besides its support for an MSC based approach to component oriented design and ‘‘interface engineering’’, the MSC connector concept is proposed as an evolution of the MSC language and its completeness with respect to the interaction abstraction [12]. Without doubt, the MSC connector concept is principally compatible with the definitions of the

P. Graubmann / Computer Networks 42 (2003) 323–342

UML Sequence Diagrams. However, modifications and adaptations necessary to introduce the connector concept into the UML are not discussed in this paper and elaboration of the details of embedding connectors into UML 2.0 will be part of further work. The next section will present the syntactic characteristics of MSC components and MSC connectors as well as the connector application to components. The third section describes the merging process of MSC connectors and components: the behaviour resulting from a connector application. The fourth section presents an outline of the formal connector semantics based on sets of labelled partial orders (LPO sets) and the appropriate merge functions. The fifth section illustrates the usage of the MSC connectors by the means of a small example (various cash registers interacting with an administration and book keeping unit). Finally, a brief conclusion and outlook will be provided.

2. MSC connectors and MSC components: syntactic characteristics Describing the behaviour of a system using MSC connectors requires two distinct steps: • Defining the necessary connectors and components. • Applying the connectors to components or similar constructs. Applying a connector to components establishes the fact that these components communicate. Defining the connector defines how the communication takes place. In the following, we describe the syntax for both MSC connector definition and MSC connector application. 2.1. Definition of MSC components and connectors It is expected MSC components will mainly be MSC references or decomposed instances. However, plain instance axes or operator expressions may also be components and connected by MSC

325

connectors. 1 The MSC components are described with all the usual MSC constructs. Only the environment receives a special treatment, which has to be considered as an extension of MSC-2000, because the environment is structured into several, logically distinct environments, each described by its own environmental instance. Environmental instances in an MSC component are discriminated from the normal, so-called internal instances of a component by the keyword env in the instance header (see Fig. 1). They differ from the standard MSC environment by the property that they carry a name identifier. There is no event structure (no event ordering) defined for them. Environmental instances can simply be viewed as a special partitioning of the environment. Besides the environmental instances, there is still the standard environment, represented by the MSC frame. Environmental instances can be used to structure the environment in an arbitrary way, however, with respect to the connector concept and the related aspect of compositional design, environmental instances are interpreted to represent the component roles exposed by the component to the external world. Within this interpretation, messages to and from a particular environmental instance may be seen as mirroring the event structure posed by the so-called ‘‘connected instances’’ of the component: those component instances included in the message exchange with the environmental instance. Thus, the message exchange between connected instances and an environmental instance determines the communication protocol of the component with respect to the role that is identified by this environmental instance. For the merging procedure of MSC components and connectors, the names of the component roles (expressed by the identifiers of the environmental instances) are crucial, because this merging is

1

If they are not ‘‘components’’ from a system architecture point of view, they may be considered components from a MSC language point of view. MSC connectors have a system engineering facet, but are as well a contribution to the MSC language evolution with respect to the ‘‘gate problem’’. This paper is slightly more focussed on the system engineering side; but what is said applies as well for the smaller MSC constructs.

326

P. Graubmann / Computer Networks 42 (2003) 323–342

msc A I0

I1

I2

X env

environmental instance

a u

standard MSC environment

b

v

c

connected instances (instances connected to role X) Fig. 1. The environmental instance X and the standard MSC environment, together with the instances I1 and I2 , which are connected with respect to the environmental instance X .

based upon an identification of the roles that are defined for the MSC components and the MSC connectors. For more details see Sections 3 and 4. Because in some cases (in particular within nested operator expressions) the introduction of an additional environmental instance may rather blur the clarity of the MSC diagrams, two additional alternatives for the representation of environmental instances are proposed: the so-called arrow mechanism and the so-called attached environment identifier. Using the arrow mechanism means to draw the message arrow between the (internal) instance and environment frame (as done in the standard MSC) and to attach to the message name and the optional parameter list a small arrow and the environment identifier. The direction of the small arrow corresponds to the direction of the message arrow and the environment identifier is placed close to the environment frame. This provides a

(a) msc A

quite intuitive description, as the example in Fig. 2a shows. Using the attached environment identifier rather resembles the way gates are described in the current MSC standard: there is the message arrow between instance and environment frame as usual and the environment identifier is attached to the arrow endpoint at the environment frame (see Fig. 2b). It is proposed not to mix the variants of the environmental instance representation. Thus, in the presence of an environmental instance axis, the arrow mechanism or attached environment identifier may not be used. In general, the environmental instance axis should be preferred to express the role-specific environment of an MSC component whereas arrow mechanism and attached environment identifier are better suited to denote environments used for the connection of small MSC constructs.

(b) msc A

I0

I1

I2

I0

a

I2

a u

v

I1

u

b X c X

v

b

X c

X

environment identifier Fig. 2. Alternative notations for environmental instances: (a) arrow mechanism; (b) attached environment identifier.

P. Graubmann / Computer Networks 42 (2003) 323–342

Because MSC connectors are intended as a flexible and easily applicable means to describe communication patterns between components, they are not only to describe a plain communication induced by components, but also have to be capable to express a possibly complex behaviour. Furthermore, in order to function as a communication pattern, an MSC connector has to be able to abstract from concrete component roles and possibly even message names. A connector used by two different components has to be ‘‘flexibly’’ adapted to role and message names, because it cannot be expected that the names are the same and nevertheless meaningful in both components. Moreover, role and message names may be modified during a more elaborate development process. Actually, the abstraction is simply necessary to decouple the development of the components, the connectors and the composition procedure. MSC connectors describe the interaction protocol between components. Thus, they are best described in the MSC language itself. However, since they have a (slightly) different interpretation and some additional language constructs, they are distinguished from MSCs by the keyword con (an abbreviation of ‘‘connector’’) as in Fig. 3. Syntactically, the description of MSC connectors somehow can be seen as a variant of the MSC reference definition [13]. The same constructs that constitute the MSC references are also available for MSC connectors. There is, however, the additional need, to identify the ‘‘proxies’’ for the communicating components and respectively the roles in which they participate in the interaction.

These are indicated by the so-called external instances. The external instances are distinguished by the keyword ext in the instance header (see Fig. 3). Their names identify the communicating roles that are connected by the MSC connector, however, they resemble the standard instances in all other respects and show, in particular, the usual event ordering. MSC connectors contain not only the external instances as references to the interacting component roles, but also internal instances. The internal instances in the connector definition enable a connector to provide some ‘‘implicit’’ behaviour which cannot or should not be assigned to the components themselves. Examples for such activities may be the adaptation of message parameters (wrapping) or the integration of interaction/communication services, etc. Furthermore, during the composition of connectors (which will, however, not be discussed in detail in this paper), internal instances appear quite naturally. Probably, it should also be mentioned explicitly that the standard MSC environment and the environmental instances are available for the MSC connector definition, too. Environmental instances, which are without event structure, should not be confused with the external instances which actually bear the behaviour information with respect to the connected component roles. From a system modelling point of view, a connector environment may serve as abstraction of a connection management interface. Summarising the MSC connector and component definition: besides the notion of an MSC

con C X

P

Y

ext

327

ext

b y z

external instances (representing connected component roles) Fig. 3. An MSC connector definition with its external instances.

328

P. Graubmann / Computer Networks 42 (2003) 323–342

msc D msc B I3

Y A

C X [c

z; d

y] Y

env

B

d c

Fig. 4. MSC connector C connecting the MSC references A and B. The definition of connector C is to be found in Fig. 3. The definition of component A is given in Fig. 1.

A1

(a)

A2

A3

connector branching point

A1

A2

(b)

A3

A1

(c)

A2

A1

(d)

Fig. 5. Variants of the connector application symbol: (a, b) branching connectors; (c) unidirectional connector; (d) self-connector. The instances Ai are decomposed instances; the double line as instance axis symbol is a proposal to draw decomposed instances in analogy to the double lined connector symbol.

connector as such, the only new concept applying here is the additional classification of instance axes as (a) environmental, (b) external, (c) internal, and, among the internal instances, as (d) connected. Thereby, external instances are restricted to MSC connectors and connected instances can only occur in MSC components (they are implicitly defined by the environmental instances in the MSC component). 2.2. Application of MSC connectors to MSC constructs MSC connectors can be applied to plain instance axes, to decomposed instances, to MSC reference symbols, or to operator expressions. In order to express the connector application, a specific graphical symbol is to be used. Because connectors can be understood as a kind of high-level

message, a double line arrow seems to be appropriate (see Fig. 4). The obligatory connector name is attached to the arrow symbol. However, MSC connectors are not restricted to connecting only two components. Fig. 5a and b show branching connectors which define the interaction protocol for the decomposed instances A1 , A2 , and A3 . 2 A branching connector is denoted as a connector arrow with branching points (see Fig. 5b) where other double lined connector arrows originate, leading to further MSC components. A special case is depicted in Fig. 5a, where the instance axis crosses the connector symbol

2 Please note the proposal for the representation of decomposed instances by a double line instance axis; this symbol elegantly corresponds to the double lined arrow of the connector application symbol.

P. Graubmann / Computer Networks 42 (2003) 323–342

exactly at a branching point: this includes the component represented by this instance into the connector application. Instances whose axes cross a connector symbol at any places other than branching points are considered to be not touched by the connector. There are two special cases for the connector symbol: the unidirectional connector and the ‘‘selfconnector’’. A unidirectional connector symbol (Fig. 5c) between two components indicates through the missing of an arrowhead at one of the connector endpoints that the component at this side of the connection only sends messages into the connector but does not receive any messages out of the connector. Self-connectors (Fig. 5d) seem to be slightly contradictory: they are applied to one component only, and thus, at first glance, could only describe that the component is accessing a certain service which is not explicitly represented in the described system. However, if one, considers evolving systems, a self-connector may serve as the starting point for a connector composition. Because connector composition is not discussed explicitly in this paper, self-connectors are mentioned merely to give a complete list of the syntactic constructs. MSC connectors are intended to serve as communication patterns, usable in various contexts and more than one connector application. Hence, their definition has to be independent from the actual component definition. Consequently, the necessary adaptation to the concrete situation has to be established during the connector application. To achieve this, the MSC connector application provides two mechanisms: the external instance mapping and the message mapping. Both mappings can be seen in Fig. 4 where (a) the external instance mapping is expressed by the ‘‘X ’’ and ‘‘Y ’’, associated with the respective connector endpoints, and (b) the message mapping is given by the expression ‘‘[c z; d y]’’ which identifies the messages ‘‘z’’ and ‘‘y’’ in the definition of the MSC connector C with the respective messages ‘‘c’’ and ‘‘d’’ in the MSC component definitions. The external instance mapping identifies for each endpoint of the connector symbol how the component roles are to be identified with the roles defined within the connector, that is how the en-

329

vironmental instances of the MSC component are to be associated with the external instances in the MSC connector. This association can be chosen quite deliberately, in order to assign the communication pattern represented by the connector to the components in an adequate way. In the most simple case, of course, component roles and connector roles are the same. This happens in the above mentioned Fig. 4, where the external instance X in C is associated with the environmental instance X in MSC A. Equally simple is the case, where component and connector roles are considered the same albeit they are differently named. This can be seen in Fig. 6, where the association between the environmental instance E in MSC B with the external instance X4 in connector C is expressed by the plain mapping ‘‘E X4 ’’. However, the situation may be somewhat more complicated, in particular, if the applied connector was originally designed in a different context. Then, several external instances in the connector may be mapped onto one environmental instance: the component interface then plays several ‘‘roles’’ jointly which were distinguished when the connector was defined. Or otherwise, one external connector instance may be mapped onto several or even all environmental instances in the component: here, the component distinguishes more sharply between different interfaces and their roles, which are not explicitly separated in the communication pattern presented by the connector. To formulate the most general case: a partition 3 of the external instances of the connector has to be mapped injectively 4 onto partitions of the environmental instances of the connected MSC components. It should be mentioned explicitly, that each external instance is (due to the partition

3

A partition of a set is a collection of mutually disjoint subsets of this set where the union of these subsets is again equal to the set. This (set-theoretical) definition of a partition ensures the soundness of the given definition of the external instance mapping. 4 Only an injective mapping (instead of a bijection) is required, since there may be environmental instances in the MSC components which are not involved in the connector application at all.

330

P. Graubmann / Computer Networks 42 (2003) 323–342

C

A

B E

E1 X1, X2; E2, E3 X3

X4

msc A

con C

IA

E1 env

E2 env

E3 env

a

msc B

X1

X2

X3

X4

E

ext

ext

ext

ext

env

a

b

a b

b

c

c d

c d

E1

X1, X2;

IB

E2, E3

d

E

X3

X4

Fig. 6. Example for a general external instance mapping: the roles of the MSC connector and roles of the MSC components are explicitly identified.

property) associated with exactly one connector endpoint. The external instance mapping has to be defined for each connector endpoint. If an endpoint of the MSC connector C is to be associated with the MSC component A, and if the collection of sets of its environmental instances fE1 ; . . . ; Ei g, fEiþ1 ; . . . ; Ej g; . . . forms a partition of the environmental instances of A that are involved in the connection, if further fX1 ; . . . ; Xr g, fXrþ1 ; . . . ; Xs g; . . . is a partition of the external instances of the MSC connector C, then the most general form of the external instance mapping is given by a list of individual mappings of the above mentioned partitions:

roles is necessary, the external instance mapping becomes quite simple: since in these cases the role identifiers for connectors and components are intentionally identical, it turns out that the names of the environmental instances in the component often coincide with the names of the external instances occurring in the connector. 5 Hence, with R1 ; . . . ; Rn the role names involved in the connector application at a specific connector endpoint, the general form of the respective external instance mapping boils down to

E1 ; . . . ; Ei

In cases, where the MSC component contains only one environmental instance E, a connector application clearly has to refer to the thereby determined component role. The external instance mapping ‘‘E X1 ; . . . ; Xm ’’ can thus be abbreviated to ‘‘X1 ; . . . ; Xm ’’ as the list of external in-

Eiþ1 ; . . . ; Ej ...

X1 ; . . . ; Xr ; Xrþ1 ; . . . ; Xs ;

See Fig. 6 for an example: The behaviour of the two roles X1 and X2 , specified for the MSC connector C, is subsumed by the one role E1 in MSC component A. The converse happens with the role X3 in C which is split into the two roles E2 and E3 in A. In the majority of cases, where no splitting or combining of component respective connector

R1

R1 ; . . . ; Rn

Rn

and this expression is reasonably abbreviated as R1 ; . . . ; R n :

5 In developments, where connectors are used as communication patterns in different application contexts, this is obviously not always true, in which case the more elaborate form of the external instance mapping has to be employed.

P. Graubmann / Computer Networks 42 (2003) 323–342

stances mapped onto the component role is sufficient. This is also the form, the external instance mapping has to take, if the connector is applied to a plain instance axis (see Fig. 14). There is another special case for which the external instance mapping can be simplified: all environmental instances in the connected MSC component and thus all its roles should jointly be associated with one partition of the connector roles. For this case, a special character is introduced, the universal instance identifier # for environmental component instances. With X1 ; . . . ; Xm the names of the external instances in the connector that are associated with the component, the external instance mapping takes the form ‘‘# X1 ; . . . ; Xm ’’ (see Fig. 7).

If the only exposed role name of the component (the name of the only environmental instance) is the same as the associated connector role name (its external instance) and all conflicts are resolved (where there is another MSC component exposing the same role name, an explicit external instance mapping assigns to it another connector role), an explicit external instance mapping may be dropped (see Fig. 8). The variety of default rules proposed for the external instance mapping facilitates the connector application with respect to the context in which the MSC connectors are used without jeopardising the flexibility that is needed to utilise the connectors as communication patterns in evolving systems or system families.

msc A C

A # X1,X2

con C

IA

B E X3

331

E1 env

E2 env

E3 env

msc B

X1

X2

X3

E

ext

ext

ext

env

a c

a

a c

c d

d

Fig. 7. Usage of the universal instance identifier # within the external instance mapping.

A

C

B

R

identical names

msc A

S

resolved conflict

con C

IA a

msc B

R

R

S

R

env

ext

ext

env

a

IB a

Fig. 8. Example of a dropped external instance mapping.

IB

d

332

P. Graubmann / Computer Networks 42 (2003) 323–342 external message names

A

C [ a,b

x;c

y,z | a

B x; b

y; *

universal message identifier

z] substitutes for the external message names message substitution message substitution group message mapping

Fig. 9. The message mapping and its syntactic structure.

The second mechanism to ensure the flexibility of the connector application is the message mapping already mentioned above. The message mapping provides a simple procedure to rename so-called external messages specified in the MSC connector. 6 External messages are those messages in an MSC connector which come from or go to an external instance. The message mapping is enclosed in square brackets and attached to the connector symbol (see Fig. 4). There can be several message substitution groups within a message mapping, each of them separated from the others by a ‘‘j’’. This symbol was chosen to reminds one of the BNF alternative operator, because the message substitution groups describe alternatives of message name substitutions (see Fig. 9). A message substitution group is a collection of message substitutions, separated by a semicolon. Each message substitution has the form ‘‘m1 ; . . . ; mn x1 ; . . . ; xr ’’ with xi , i 2 f1; . . . ; rg, the names of external messages occurring in the connector 7 and mj , j 2 f1; . . . ; ng the replacement message

6

Besides the message mapping, the general substitution of internal message and instance names in a connector can facilitate its usage as a flexible communication pattern (internal messages are all those messages which are not in touch with an external connector instance). The syntax for this kind of substitution would be aligned with the substitution mechanism defined in the standard for MSC references. We do not discuss it here in more detail since only the external messages mapping is directly relevant for the connector application. 7 The set of names of external messages occurring in the different message substitutions of a message substitution group are necessarily mutually disjoint, in order to avoid an inconsistent substitution.

names, which naturally are expected to be message names occurring in the MSC components to which the connector is applied. 8 Each xi may be substituted by any mj . External messages whose names do not appear in any message substitution are treated as ‘‘message constants’’ in the respective connector application: their names have to match without change when the merging procedure (see Section 3) is performed to determine the behaviour of the connector application. There is also a short-hand notation for all messages occurring in the MSC components involved in the connector application: the universal message identifier . The message substitution ‘‘ z’’ in Fig. 9, thus, corresponds to the message substitution ‘‘mA1 ; . . . ; mAp mB1 ; . . . ; mBq z’’ where mAi , i 2 f1; . . . ; pg are the names of all the messages sent to and received from the environmental instances of the MSC component A, that are involved in the connector application, and mBj , j 2 f1; . . . ; qg are the respective message names from MSC component B. The result of the message substitution of the connector application in Fig. 10 is depicted in Fig. 11. MSC A and MSC B both describe two alternatives each: in MSC A, sending message a or sending message b is established, and in MSC B,

8

This would be desirable in order to facilitate the understanding of the connector application, but it is no strict requirement. The message mapping mechanism can deal with message names which do not appear in the MSC components (the respective merge functions become void––see the Sections 3 and 4––and the substitution does not contribute to the resulting behaviour of the connector application).

P. Graubmann / Computer Networks 42 (2003) 323–342

msc A

msc A

con C

IA C

A

B

[a,b

msc B

X1

X2

ext

ext

IB1

X2 env

x

alt

x]

X1 env

333

alt

a b

IB2

a b

Fig. 10. Small example for a message substitution.

con Ca

msc D*

a

C A

b

B

C A

B

con Cb

X1

X2

X1

X2

ext

ext

ext

ext

a

b

Fig. 11. MSC D shows that the behaviour of MSC D in Fig. 10 after the substitution of the external message x in the connector C by either a or b results in an alternative.

receiving of either message a or b is specified. The substitution of message a for the external message x yields the MSC connector C a (see Fig. 11) which, applied to A and B results in the sending of the message a from instance IA in MSC A to the instance IB1 in MSC B. All three other possibilities (sending b in A and receiving b in B, sending a in A and receiving b in B, sending b in A and receiving a in B) are excluded by the merging mechanism (see Section 3 below for the details). The analogous arguments apply to the MSC connector C b , which results from the substitution of b for x in C. The only resulting behaviour is the sending of message b from IA in A to IB2 in B. Thus, we get the expected result.

3. Merging the behaviours The behaviour defined by a connector application is the result of a merging of the behaviours specified by the MSC connector and the MSC components. The basic merging procedure can be defined in the following manner:

Each connector in/out message event on an external connector instance has to be identified with a corresponding equally named in/out message event that is received from, respectively sent to one of the environmental instances in the connected MSC that are associated to the external connector instance through the external instance mapping. The message mapping has to be performed prior to the merging. For this merging procedure, it is assumed that messages with identical names also correspond with respect to their parameters. The explicit definition of this correspondence is part of ongoing work and will be detailed in a later publication. Fig. 12 gives a simple example of the merging process, based upon the connector application of Fig. 4. The external instance names in the connector C and the respective environmental instance names in the components A and B coincide. We have a trivial external instance mapping, identifying (a) the external instance X in the MSC connector C with the only environmental instance X in A, and (b) the external connector instance Y with

334

P. Graubmann / Computer Networks 42 (2003) 323–342

corresponding external and environmental instances: con C

msc A I0

I1

I2

msc B

X

X

env

ext

a

P

Y

Y

ext

env

I3

b d

u

b

y

v

c

z

c

corresponding message events: Fig. 12. The merging of message events according to the connector application defined in Fig. 4. Cf. the component definition MSC A in Fig. 1 and the connector definition for MSC C in Fig. 2.

the environmental instance Y in B. As a next step, we have to identify the message events occurring on the connected instances I1 and I2 in A with the message events on the external instance X of the connector C. This is straight forward for the message b which appears to be a ‘‘message constant’’ in component A and connector C. Identifying the component message c with the connector message z, however, is only possible after applying the message mapping ‘‘c z’’. For the other connector endpoint, we have I3 as the connected instance and after the due message mapping, we

can identify the message events on this instance with the message events on the external instance Y in the connector C. Fig. 13 shows the behaviour resulting from the merging described in Fig. 12. It presents the MSC Dexp as behavioural equivalent to MSC D as defined in Fig. 4. The external message events of the MSC connector C are matched with the assigned environmental message events of the MSC components A and B, and thus, the external connector instances get merged with the appropriate connected component instances. In Figs. 12 and 13,

msc Dexp I0

I1

I2

P

I3

a b

u

d

v c

internal instance of A

connected instances of A merged with X of C

internal instance of C

connected instance of B merged with Y of C

the environmental instances X in A and Y in B disappeared, since they only represented the interfaces of A and B, respectively

Fig. 13. MSC Dexp is the result of the merging procedure, exemplified in Fig. 12. MSC Dexp is the appropriate expansion of MSC D, the connector application in Fig. 4.

P. Graubmann / Computer Networks 42 (2003) 323–342

the external instance X is blended into the connected instances I1 and I2 , and the external instance Y is identified with I3 . The environmental instances describing the MSC component interfaces vanish during the merging procedure. In Figs. 12 and 13, the environmental instances X in MSC A and Y in MSC B disappear. Consequently, the set of instances of the resulting connected MSC Dexp is a union of the set of internal component instances, the set of connected component instances and the set of internal connector instances. Because both MSC connectors and MSC components may contain structural concepts like inline expressions, co-regions and High Level MSCs (HMSCs), the merging procedure may become quite sophisticated. In particular, in case of alternatives, only some branches of the connector behaviour description will match with given branches of the MSC component behaviour description (see Fig. 10 and the resulting behaviour in Fig. 11, where only two of four possible behaviour combinations are ‘‘accepted’’ by the connector). In general, only part of the complete MSC component behaviour description will match with the connector behaviour description. In this way the connector may impose role specific constraints on the component interfaces and thus prove the eminent importance of the proper ‘‘interface engineering’’, in particular in the area of system families (see also the example in Section 5). A formalisation of the merging procedure between MSC connectors and MSC components based on partial order sets is briefly outlined in Section 4. MSC connectors and MSC components containing compositional constructs are expanded in

335

form of alternatives of basic MSC connectors and of basic MSC components, possibly enhanced by co-regions and generalised ordering constructs, the peculiarities of are not discussed in detail in this paper. There is still a simple but special case which should be explicitly mentioned. In the case where a connector is applied to a plain instance, environmental instances are definitely missing on such a ‘‘component’’ side. Consequently, the merging mechanism as described above cannot work properly. However, it is quite obvious, that only the external instance of the MSC connector has to be projected onto the plain ‘‘component’’ instance axis in order to establish the interaction defined by the connector. Hence, in this case, the connector application turns out to play the same role as the insertion of an MSC reference. Fig. 14 shows a simple example: the application of MSC connector C of Fig. 3 to plain instances A and B.

4. Brief resume of the formal MSC connector semantics Because this presentation of the MSC connectors focusses mainly on the connector syntax and the embedding of the connector concepts in a software and system family engineering process, it is not the place to elaborate on the MSC connector semantics (for a more detailed description see [12]). However, a brief sketch of the basic ideas should be given nevertheless, since it may facilitate the understanding of the concept. The explanation of the merging mechanism for the connector application in Section 3 employed msc D1exp

msc D1 A

B expands to

C X [c

z; d

A

y] Y

P

B

b d c

Fig. 14. MSC connector C (find the connector definition in Fig. 3) connecting the plain instances A and B. The result of the connector application is given as MSC Dexp (which is the appropriate expansion of MSC D1 ). 1

336

P. Graubmann / Computer Networks 42 (2003) 323–342

basic MSCs (BMSCs), and thus, as result again a basic MSC was obtained. According to the MSC2000 standard Z.120 [9], a basic MSC describes the causal ordering of the contained communication events. Consequently, also the meaning of MSC components and MSC connectors may be provided suitably by a partial order semantics. Because only basic MSCs (BMSCs) can be interpreted in a straightforward manner by a partial order, a main task in developing a partial order connector semantics is to put the involved MSCs and connectors into an appropriate form. Therefore, a partial order semantics has to be extended to MSCs containing composition mechanisms in form of decomposed instances, MSC references, MSC reference operator expressions, inline expressions and HMSCs. A compositional denotational semantics may be provided interpreting MSC operators as operations on partial orders [14]. The main idea is to describe MSCs containing high level constructs by means of sets of partial orders which are interpreted as alternatives using the delayed choice operator. Other structural concepts like co-regions and generalised ordering can be integrated without problems into partial ordering. For the definition of the connect operation, the notion of events and actions play a crucial role. Message events and actions (identified as message types, mainly given by the message name) have to be strictly distinguished since in general, several messages with the same name (action) may occur within one MSC. Therefore, as the underlying structure the formal MSC connector semantics make use of labelled partial orders with the following definition from [8]: A labelled partial order (LPO) is a structure, consisting of a set of events, a reflexive, antisymmetric and transitive ordering relation on this set of events, and a labelling function that provides the mapping of the event set onto the corresponding set of action types, which are essentially the message names. Since also output (sending) events have to be distinguished from input (consumption) events the output/input type shall be included in the action type definition.

According to this approach, it is assumed that the MSC connector and each of the MSC components that shall be merged are represented in form of a set of LPOs. These LPOs of connector and components have to be mutually merged whereby in general only a few combinations fit together which then are called consistent. The merging result for non-consistent combinations is denoted as empty LPO. The main step in defining the connector semantics is therefore to define the merge functions. Because the merging procedure identifies message events on the external instances of the connector with connected message events on the corresponding connected instances, merge functions are bijective mappings between these two sets of events. However, any arbitrary bijection would not yield a correct merging. Thus, a merge functions has to be consistent. It has to be all of the following: (a) compliant with the external instance mapping; (b) type consistent; (c) ordering consistent. The external instance mapping (a) can be formulated as mapping between partitions of the set of external connector instances and environmental component instances. The type consistency (b) requires that the type of the identified messages, i.e., the name of the message together with input/ output type is preserved and can be formulated by means of the LPO labelling functions and the message mapping (after the message substitution, the labelling of identified events has to be identical). Ordering consistency (c) means that the union of the ordering relations of the connector and components, after being mapped by the merge function, 9 together with the transitive closure again yields an ordering relation. Each consistent merge function defines an LPO. The behaviour of a connector application is thus given as the set of LPOs which are derived from

9

A merge function, defined between events, can be easily extended to a component-wise mapping of the ordering relation.

P. Graubmann / Computer Networks 42 (2003) 323–342

the consistent merge functions. If there are no consistent merge functions, the connection application is a failure. The work on the connector semantics is still ongoing. It has to be extended to multiple connector applications, which can be quite straightforward. It will also include the definition of static rules to ensure specific properties for the connector application.

5. Example In this section, a small example of MSC components connected by an MSC connector is presented. In its basic form, the example models a supermarket cash register system and describes how a cash register device interacts with a central administration component that is responsible for some book keeping, the authorisation of shop cards 10 and credit cards, and possibly other functions. The example given here is a revised version of the example in [12]. The intention of the example is to show that different cash register devices (defined as different MSC components) can be connected to the central administration unit (defined as another MSC component) by application of the same MSC connector. It will turn out that even the necessary external instance mapping and the message mapping are the same for all the connector applications. There are three variants of cash register devices: the ‘‘all-round cash register’’ which is capable of coping with all kind of payments foreseen in this small example (Fig. 15: the MSC allround_register), the ‘‘shop card register’’ where only a shop card is accepted (Fig. 22: the MSC shop_card_ register), and the ‘‘cash only register’’ where customers may only pay cash and where no cards are accepted (Fig. 23: the MSC cash_only_register). Fig. 15 presents the HMSC model of the ‘‘allround cash register’’. This cash register device al-

10 A shop card is issued by a supermarket and allows payment up to a certain credit limit. Shop card holders have to provide a pin in order to perform a transaction, whereas it is assumed for credit cards that no pin is required.

337

lows for several forms of payment: it accepts shop cards, credit cards and cash payment. After the bought items having been entered into the cash register (which is not detailed here), the customer has to pay. If he or she decides to pay cash, the cash is simply entered into the register and the amount is submitted to the environmental instance admin (MSC cash_payment, Fig. 16). In case of a shop card payment, the card is read and the pin has to be provided (MSC shop_ card_payment in Fig. 17). Subsequently, both, card number and pin data together with the due amount of the purchase are sent for a card check to the environmental instance admin (MSC check_shop_card, Fig. 18). For a credit card payment, only the credit card is read (MSC credit_card_payment, Fig. 17), and the card data together with the due amount again are transferred to the environmental instance admin (MSC check_credit_card, Fig. 18). Within the MSCs card_failed and card_ok (both Fig. 18) the check_result is obtained from the environmental instance response and subsequently displayed (Fig. 19). The MSC cancel_operation (Fig. 16) provides the possibility of cancelling the transaction. Some of the various MSCs determining this first component contain the environmental instance customer, which is devoted to the interaction with the customer. Others contain the already mentioned environmental instances admin or response. Only the instances admin and response constitute the interface of the HMSC allround_register which will be connected by the MSC connector CP to the other MSC component shop_admin. The second MSC component shop_admin (Fig. 19) deals with shop and credit card authorisation and, if necessary, with the pin check for the customer. It returns either the result ok or failed. This MSC component is modelled by means of inline expressions. It contains the environmental instances register and credit_card_centre whereby only the instance register represents the interface to the MSC connector CP. The MSC connector CP manages the communication between both MSC components concerning the transmission of either data for amount of purchase and the card check operations and the

338

P. Graubmann / Computer Networks 42 (2003) 323–342

msc allround_register

enter_ item_list

shop_card_ payment

*

credit_card_ payment

check_ shop_card

check_ credit_card

card_failed

card_ok

cash_ payment

cancel_ operation

Fig. 15. MSC component allround_register. The definitions of the MSC references in this HMSC are to be found in Figs. 16–18. MSC reference enter_item_list is not further detailed in this paper.

msc cash_payment customer

msc cancel_operation

controller

register

env

admin

controller

register

env

enter cash

admin env

cancel cash ack

cancel info

amount

Fig. 16. MSCs cash_payment and cancel_operation. That are referenced from allround_register (Fig. 15).

result messages. When applying the connector between the two components (for example constructing the MSC super_market_1, see Fig. 20), the substitution rule (message mapping) is employed for the connector message result: it may be substituted by the messages ok and failed in the component allround_register. The external connector instance R is mapped onto the environmental instances admin and response whereas the external connector instance A is mapped onto the environmental instance register in the respective components. The second part of the example intends to demonstrate the multi-usability of the connector.

In particular, in the domain of system family engineering, systems are usually composed of various components. The family approach consists of deriving system variants by substituting components by new components with slightly different (either reduced or extended) functionality without modifying the components that are not exchanged. Because such a property has to be designed into the system family, interfaces become an even more important class of objects. Our example shows that the connector CP (Fig. 21) is capable to serve also for the slightly modified register components shop_card_register (Fig. 22) and cash_only_register (Fig. 23) which are restric-

P. Graubmann / Computer Networks 42 (2003) 323–342

msc credit_card_payment customer

card reader

339

msc shop_card_payment controller

register

card reader

customer

env

controller

register

env

activate_card_reader

activate_card_reader

*

insert card read_card

*

insert card read_card

* card data

* card data

provide pin get_pin

* pin data

Fig. 17. MSCs credit_card_payment and shop_card_payment that are referenced from allround_register (Fig. 15). MSC references with an asterisk are not further detailed in this paper.

msc check_shop_card controller

msc check_credit_card

admin

controller

admin

env

env

card check card check

pin check

amount

amount

msc card_ok controller

msc card_failed register

response

controller

env

response env

ok display

register

failed display

Fig. 18. MSCs check_shop_card, check_credit_card, card_failed and card_ok referenced from allround_register (Fig. 15).

tions of the general allround_register. The shop_card_register only accepts the shop card–– neither cash nor credit card. The cash_only_register allows the customer cash payment only. The resulting substitution of the MSC allround_register in the system MSC syper_market_1 by the MSC

shop_card_register leads to the system syper_ market_2 (Fig. 24), replacing it by the MSC cash_only_register produces the system syper_ market_3 (also Fig. 24). In both cases, there is no change necessary in either the administration component shop_admin nor in the connector CP.

340

P. Graubmann / Computer Networks 42 (2003) 323–342

msc shop_admin book keeping

register

credit card centre

env

alt

env

amount card check

alt

pin check amount shop_card_check

*

amount credit_card_check

alt

*

ok failed

cancel info

Fig. 19. MSC shop_admin. MSC references with an asterisk are not further detailed in this paper.

6. Conclusion This paper discussed syntax and semantics of the MSC connector concept as an communication abstraction between MSC components, thus making a component oriented system modelling by means of the MSC language possible. The proposed concepts, originally based upon consider-

ation within system family engineering, prove to be also applicable for the interaction description of the ‘‘smaller’’ MSC constructs like operator expressions, plain instances, etc. In comparison with earlier approaches towards a modularisation using the rather obscuring MSC gate construct [11], the employment of MSC connectors seems to be a well understood and sound concept. The semantics, based upon labelled sets of partial orders (LPO sets), which is discussed in depth in [12], has been presented here in a brief overview, showing that a clear and easy to understand semantics for MSC components and connectors is available. The possibility to switch between a variety of different views within the same language depending on the partitioning together with an appropriate tool support where this transition can be performed in a selective manner making use of the HyperMSC concept [15] will greatly enhance the applicability of MSC within the software development process. In particular, comprehensive MSC behaviour descriptions become possible. Successful practical experience in componentoriented system modelling along these lines based on a corresponding tool support has been gained already some years ago, however, on a rather informal level for ISDN systems at the public switching systems division of Siemens AG. The formalisation provided in [6] can be seen as a predecessor of the approach presented within this paper. By means of this general modularisation concept for the MSC language, the transition to state oriented languages like SDL may be facilitated [5]. Thereby, in the future MSC connectors may also be fruitfully employed for the composi-

msc super_market_1

allround_ register

CP admin, response R

[ok, failed

result]

register A

shop_ admin

Fig. 20. MSC system super_market_1––application of MSC connector CP to MSC components allround_register and shop_admin.

P. Graubmann / Computer Networks 42 (2003) 323–342

msc cash_only_register

con CP

loop

341

R

A

customer

ext

ext

env

controller

register

env

enter item list

alt opt

card check

*

alt cash_payment

opt

admin

*

pin check cancel_operation

amount opt

result Fig. 23. MSC cash_only_register. This component is a variant of the allround_register, accepting only cash payments. MSC references with an asterisk are not further detailed in this paper. Cancel_operation is in Fig. 16.

cancel info

Fig. 21. MSC connector CP.

msc super_market_2

shop_card_ register admin, response R

msc shop_card_register customer

card reader

controller

register

env

enter item list activate card reader

admin

response

env

env

result]

register A

shop_ admin

result]

register A

shop_ admin

msc super_market_3

* *

cash_only_ register admin, response R

insert card read card

CP [ok, failed

CP [ok, failed

* card data

provide pin get pin

card_check

Fig. 24. Application variants: In MSC system super_market_2 component allround_register is substituted by the shop_ card_register; In MSC system super_market_3 component allround_register is substituted by cash_only_register.

* pin data pin_check amount alt

ok failed cancel_operation display

Fig. 22. MSC shop_card_register. This component is a variant of the allround_register, accepting only shop card payments. MSC references with an asterisk are not further detailed in this paper. Cancel_operation is in Fig. 16.

tion of system components that are modelled in SDL or other state-oriented languages.

Acknowledgements I would like to thank Ekkart Rudolph with whom I have worked together very closeon the subject of this paper and whose untimely death in 2002 has interrupted a personal friendship and a very fruitful co-operation. I would like to take the opportunity to thank the reviewers for their valuable comments. The work presented here was performed within the Eureka Programme, ITEA Project ip00004  and funded by the German BMBF. CAFE

342

P. Graubmann / Computer Networks 42 (2003) 323–342

References [1] M. Broy, I. Kr€ uger, Interfaces––towards a scientific foundation of a methodological usage of message sequence charts, in: J. Staples, M.G. Hinchey, S. Liu (Eds.), Formal Engineering Methods ICFEMÕ98, IEEE Computer Society, 1998. [2] A. Egyed, N. Metha, N. Medvidovic, Software connectors and refinement in family architectures, in: Proceedings of the 3rd International Workshop on Software Architectures for Product Families, Las Palmas de Gran Canaria, Spain, 15–17 March 2000. [3] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modelling Language User Guide, third ed., Addison-Wesley, Reading, MA, 1999. [4] D.F. DÕSouza, A.C. Wills, Objects, Components and Frameworks with UML. The Catalysis Approach, Addison-Wesley, Reading, MA, 1999. [5] S. Mauw, M.A. Reniers, High level message sequence charts, in: A. Cavalli, A. Sarma (Eds.), SDLÕ97: Time for Testing – SDL, MSC and Trends, Proceedings of the 8th SDL Forum, Evry, France, North-Holland, Amsterdam, 1997. [6] E. Rudolph, P. Graubmann, J. Grabowski, Message sequence chart: composition techniques versus oo-techniques Õtema con variazioniÕ, in: R. Break, A. Sarma (Eds.), SDLÕ95: With MSC in Case, Proceedings of the 7th International SDL Forum, Oslo, Norway, North-Holland, Amsterdam, 1995. [7] R. Milner, Communication and Concurrency, International Series in Computer Science, Prentice-Hall International, Englewood Cliffs, NJ, 1989. [8] ITU-T Recommendation Z.120 (10/96): Message Sequence Chart (MSC), Geneva, 1997. Known as ‘‘MSC-96’’. Superseded (see [9,10]). [9] ITU-T Recommendation Z.120 (11/99): Message Sequence Chart (MSC), Geneva, August 2001. Known as ‘‘MSC2000’’. See also [10].

[10] ITU-T Recommendation Z.120 Corrigendum 1 (12/01): Message Sequence Chart (MSC), Geneva, October 2002. Corrections and modifications to ‘‘MSC-2000’’. [11] S. Loidl, E. Rudolph, U. Hinkel, MSCÕ96 and beyond – a critical look, in: A. Cavalli, A. Sarma (Eds.), SDLÕ97: Time for Testing – SDL, MSC and Trends, Proceedings of the 8th SDL Forum, Evry, France, North-Holland, Amsterdam, 1997. [12] P. Graubmann, E. Rudolph, MSC Connectors––The PhilosopherÕs Stone, in: E. Sherratt (Ed.), SAM2002, Aberystwyth, Lecture Notes in Computer Science, vol. 2599, Springer, Berlin, March 2003. [13] P. Graubmann, E. Rudolph, J. Grabowski, Component interface descriptions using HyperMSCs and MSC connectors, IEEE Visual Languages and Formal Methods, Stresa, Italy, 5–7 September, 2001. [14] J.P. Katoen, L. Lambert, Pomsets for message sequence charts, in: Proceedings of the 1st Workshop of the SDL Forum Society on SDL and MSC (SAMÕ1998), Berlin, Germany, June 1998. [15] J. Grabowski, P. Graubmann, E. Rudolph, HyperMSCs with connectors for advanced visual system modelling and testing, in: R. Reed, J. Reed (Eds.), SDL 2001: Meeting UML, Proceedings of the 10th International SDL Forum, Copenhagen, Denmark, June 2001, Lecture Notes in Computer Science, vol. 2078, Springer, Berlin, 2001.

Peter Graubmann is with the corporate technology division of Siemens AG in Munich. He has been involved in many research projects covering software engineering methods, formal description techniques, component-oriented development and platform technologies, including a longstanding involvement in the development of Message Sequence Charts. He currently focuses on System Family Engineering and, in particular, on Interface Engineering.