Trace Semantics of Interactions in UML 2.0 - Semantic Scholar

Trace Semantics of Interactions in UML 2.0 Harald St¨orrle IFI-PST, LMU M¨ unchen, Oettingenstr. 67, 80538 M¨ unchen, Germany

Abstract The Unified Modeling Language (UML, see [27]) is the industry standard for modeling software intensive systems. Recently, the standard has been upgraded from version 1.5 to 2.0, introducing significant changes and additions. In particular, Message Sequence Charts (MSC) according to the ISO standard (see [13, 12]) have been integrated. In UML, the concept underlying these notations is called interaction. This article examines UML interactions by defining a formal, yet straightforward trace semantics, including time, with a view to refinement. Key words: UML 2.0 interaction diagram, Message Sequence Chart (MSC), Life Sequence Chart (LSC), denotational trace semantics, orthogonal UML extensions

1

1.1

Introduction

Role of the UML

The Unified Modeling Language (UML) is the industry standard for modeling, it has even been dubbed “the lingua franca of software engineering” (cf. [31, p. v]). However, over the past few years, a number of rather serious shortcomings have been identified, concerning for instance the formal semantics of UML models, most notably that of dynamic views. Still, the UML is the visual notation in software engineering today, in terms of practical importance. Currently, the UML is undergoing a major revision, advancing from version 1.5 to version 2.0. In doing so, a number of the mentioned shortcomings are being addressed. In particular, Message Sequence Charts (MSC) as described in the ISO standard (see [13, 12]) have been integrated.In UML, the concept underlying these notations is called Interaction. 1 1

Throughout this paper, UML metaclasses will be printed capitalised “CamelCaps”, as they are used in the UML standard) in order to distinguish them from

Preprint submitted to Elsevier Science

13 February 2004

1.2

Interactions in UML

There are many variants of Message Sequence Charts (see section 8.3 for a discussion). The UML variant differs from others in many ways. While some are very obvious, many of these differences are difficult to spot yet still rather consequential. It is therefore necessary to disseminate the standard quite painstakingly. Given the importance of the UML, however, it is well worth looking into these details. It turns out that while UML 2.0 improves upon the previous versions of the UML in many ways, there are still flaws and inconsistencies. In particular, the OMG proposal has yet again failed to define a formal semantics, as would be necessary to take full advantage of the UML, e.g., in automated tools. Since tool support is one of the main justifications for using UML in the first place, this is not just a an academic desideratum, but a very down-to-earth practical problem.

1.3

Purpose and approach of article

Building on previous work published as [35, 34, 36], this article aims at summarising the state of the art concerning syntax and semantics of UML interactions. Since the UML is a moving target, there are still some open questions and issues, which need further consideration. Some of the more speculative issues as to how the standard might be evolved in the future are also discussed here. This article first explains the new definition of interactions and the differences to the corresponding definitions in the current UML version. Then it defines a straightforward semantics of Interactions including time. The approach presented in this article is very close to the classic approach in programming language semantics, that is, starting from concrete syntax, the abstract syntax is explained. The semantics is defined for plain Interactions, so called Combined Fragments, the more advanced features, and finally for assertion, negation, refinement and time.

ordinary vocabulary and to avoid awkward and tedious expressions like “interactions in the sense of UML” or similar.

2

1.4

State of the standard

First of all, the state of the standard as it is examined in this article needs clarification. Currently, the officially adopted version of the UML is 1.5 of March, 2003. The UML 2.0 standard comes in two main parts: the infrastructure which “explains the language architecture structure and the formal approach used for its specification” (cf. [27, p. xiv]) and the superstructure which “defines the user level constructs [. . .].” (cf. [27, p. v]) 2 This article deals with the superstructure. In the remainder, “UML 2.0 superstructure” is used synonymously to “UML 2.0 ”, as no confusion is to be expected. The process of advancing to UML 2.0 (as far as the superstructure part is concerned) has proceeded to the stage where, as has generally been expected, the proposal of the “U2-Partners”-group has been chosen from among the contending initial proposals as the basis for the standard. This proposal has been advanced to the status of “final adopted spec, version 2.0 ” by the OMG in mid 2003, with the provision of integrating contributions of the other proposals. On August, 2nd 2003, the OMG has published the latest version of the superstructure (cf. [27]), which is the basis of this article.

2

Syntax and intuition

To level the ground, we start with a brief discussion of the concrete and abstract syntax of interactions in UML 2.0. This explanation frequently uses the corresponding notions of UML 1.x as a contrast to make reference easier for those familiar with UML. In the remainder, UML 2.0 will be called the “new standard ” or simply “the standard ” while the older versions (in particular 1.4 and 1.5) will be collectively referred to as the “old standard ”.

2.1

Concrete syntax

In UML 2.0, all diagrams have a frame around them and a compartment displaying its type and name (see sketch) which makes it easier to refer to it, e.g. as a subdiagram or companion diagram. 2

These two, together with the Object Constraint Language (OCL) and for UML Diagram Interchange are the four central Requests For Proposals (RFPs) of the UML 2.0. Additionally, there are some more like specific profiles or the HumanUsable Textual Notation (HUTN) and the XML Metadata Interchange (XMI) Specification. These are irrelevant for the semantics of Interactions, however.

3



In the old standard, there were two types of interaction diagrams, namely sequence and collaboration diagrams. In the new standard, collaboration diagrams have been renamed to communication diagrams. On the same level, timing diagrams, have been introduced (see Figure 1). As far as simple Interactions are concerned, these three diagram types are semantically equivalent and very similar, but not identical in expressive power. sd P

sd P

Lifeline 1

sd P

Lifeline 2

Lifeline 2 Lifeline 2

Lifeline 1

Lifeline 1

Fig. 1. Three alternative syntactical forms for the same semantic contents: a sequence diagram (left), a communication diagram (middle), and a timing diagram (right).

Additionally, sequence diagrams have been extended considerably, and now have approximately the same expressive power as High Level MSCs: they may be structured using InteractionOperators (see Figure 2). The operators include different kinds of sequential and parallel composition, exception handling, case distinction, macro-expansion and selective hiding of message types. If there are two arguments to an InteractionOperator, they are divided by a dashed line. While almost identical visually, there are some important differences semantically between ITU-T High Level MSCs and UML sequence diagrams. sd P

Lifeline 1

Lifeline 2

a alt opt

b c d e

Fig. 2. Sequence diagrams may be structured using InteractionOperators.

4

UML timing diagrams resemble the traditional timing diagrams known in the engineering disciplines. Timing diagrams may be considered as an elaboration of metric sequence diagrams. 3 While communication diagrams and sequence diagrams focus on structure and message exchange, respectively, timing diagrams focus on state and state change across time. Time annotations may be provided either as a metric time scale (only in timing diagrams), or as constraints on the duration of states or message transmissions (all kinds of interaction diagrams), see Figure 3. sd P {0...3s}

sd P

B

A msg() {0..1ms}

x

A

t=now

y z

msg()