**2. Sequence diagrams in UML**

Features of real-time systems define some requirements put on the system development process, and in consequence, on specification language used in this process. The language, in which the specification is expressed, should be characterized by the right power of expression (allowing a description of real-time systems, and development of system models for the assumed point of view), and should be abstract (allowing an appropriate level of detail description). Additionally, the language should be supported by programming tools enabling validation (confirmation that the informal user's needs are met) and verification (checking the specification against a set of properties: consistency, completeness, determinism) of specifications.

98 Real-Time Systems, Architecture, Scheduling, and Application

properties are expressed in modal logics. We propose to use sequence diagrams to express them, to obtain in this way uniformity of means for a system specification. For this purpose, the notion of monitoring scenarios is introduced. Monitoring scenarios are specified by sequence diagrams, and are used to define liveness and safety properties of the system's

In the chapter, the proposed semantics of extended sequence diagrams is explained, and an example of a simple system specification and its analysis are presented. The analysis is done by means of the prototype of a programming tool that enables analysis of system's behavior against consistency and completeness as well as checking its liveness and safety properties.

Section 2 presents how UML sequence diagrams are defined, and also introduces new kinds of combined fragments that are used to define extended sequence diagrams. A set of exten-

Section 3 outlines our approach to specification of the real-time systems. The approach uses class diagrams to represent the structural aspect, and a set of sequence diagrams to represent the behavioral aspect of the specified system. A specific feature of the approach is a possibility to extend the behavior specification with additional monitoring diagrams – sequence diagrams – representing forbidden and expected behaviors. In this way we introduce some redundancy to the behavior specification, which enables checking safety

In Section 4, an informal semantics of real-time system specification is explained; a notion of the graph of possible scenarios is defined. The graph is derived from the set of extended sequence diagrams, and defines a set of possible scenarios representing system's behavior. System's specification requires validation with respect to consistency, definiteness and com-

Section 6 is the main section of the chapter. It formalizes semantics of a set of extended sequence diagrams. First, it defines a set of basic notions, and next it formally presents construction of the graph of possible scenarios which are semantics of a set of sequence

Features of real-time systems define some requirements put on the system development process, and in consequence, on specification language used in this process. The language, in which the specification is expressed, should be characterized by the right power of expression (allowing a description of real-time systems, and development of system models for the assumed point of view), and should be abstract (allowing an appropriate level of detail description). Additionally, the language should be supported by programming tools enabling validation (confirmation that the informal user's needs are met) and verification (checking the specification against a set of properties: consistency, completeness, determi-

ded sequence diagrams is used to represent the behavior of a real-time system.

and liveness of system's behavior. The approach is illustrated by a simple example.

pleteness. These properties are defined and discussed in Section 5.

Section 7 ends the chapter with concluding remarks.

**2. Sequence diagrams in UML** 

nism) of specifications.

behavior.

diagrams.

The chapter is organized as follows.

There are several languages that enable real-time systems specification, but we focus on UML, especially on UML sequence diagrams that are drawn from Message Sequence Charts (ITU-T, 2004; Cleaveland & Sengupta, 2006). UML 2.4 sequence diagrams provide mechanisms for specification of time properties (OMG, 2011).

A sequence diagram represents an interaction – a set of communications among objects arranged visually in time order. The diagram shows the objects with their lifelines participating in an interaction, and the sequences of exchanged messages, but it does not show object relationships. So, the diagram forms an interaction that consists of objects' lifelines and messages exchanged between the lifelines. For each message there are two events: sending and receiving.

The newest version of UML 2.4.1 enables explicit handling of real-time events on sequence diagrams. The basic mechanisms are: observation of current time, especially observation of time of an event occurrence, and observation of duration of message transmission. As in the previous versions of UML, time constraints may be specified – see Fig.1. The constraints may take into account times of sending and receiving a message, duration of a message transmission, times of occurring of selected events etc.

Fig. 1. Sequence diagram with time constraints

Sequence diagrams can exist in a descriptor form (describing all possible scenarios) and in an instance form (describing one actual scenario). The descriptor form uses combined fragments that are shown as nested regions within a sequence diagram. A combined fragment defines an expression of interaction fragments. A combined fragment is defined by an interaction operator and corresponding interaction operands. There are a number of combined fragments for representing contingent behavior, such as conditionals, loops, and so on. A combined fragment has a keyword, e.g., *alt*, *break*, *par*, *loop*, *seq*, *strict*, that specifies its type. Depending on the keyword, there are one or more embedded operands, each of which is a structured subfragment of the overall interaction. A combined fragment may also have zero or more gates, which specify the interface between the combined fragment and other parts of the interaction.

Specification and Validation of Real-Time Systems Using UML Sequence Diagrams 101

reflects a family of user stories; each describing a scenario or scenarios represented by a

The peculiarity of the proposed approach lies in that the set of diagrams may contain also additional diagrams called monitoring diagrams. The idea to use the monitoring diagrams comes from the postulate, that we expect high level of credibility of specification of each system, and especially specification of the real-time system. The monitoring diagrams introduce some redundancy to the specification and, in this way, increase its credibility. So,

ܾܵ݁ܿ ൌ ܵ݀௦ ܵ݀௧ where the set ܵ݀௦ specifies the desired behavior of the system, and the set *Sdmonit* defines monitored behaviors. The monitored behaviors may in turn be split into forbidden and

ܵ݀௧ ൌ ܵ݀ௗௗ ܵ݀௫௧ௗ. The forbidden behaviors represent the safety property of the developed system, i.e., they express the fact that the undesirable situation will not appear during system execution (the

The expected behaviors represent the liveness property of the system, i.e., express the fact that if some situation is required it will happen eventually during the system execution (the

The liveness and safety properties (Nissanke, 1997) are usually expressed in a language of modal logics (Manna & Pnueli, 1992; Manna & Pnueli, 1995). Having a model or a system's prototype, one examines whether the model or prototype complies with specified properties (*model checking*). Peculiarity of the presented approach is to use sequence diagrams to express these both properties. In this way we obtain the possibility of specifying the system's

An example of a system specification is presented below. The example specifies a simple real-time system which controls and monitors a bakery. Fig. 3 presents a class diagram

The behavior of the system is described by three user stories represented in Figs. 4, 5 and 6. The first user story is presented on three sequence diagrams – Fig. 4. They describe reaction of the system when the main switch of the control panel is clicked to on or to off. When the main switch of the control panel is clicked to on, the main light should be turned on and the console background color should be changed to green. When the switch is clicked to off, the light should be turned off, and the console background color should be changed to white.

The second user story is presented on two sequence diagrams – Fig. 5. The story relates to an alarm situation when the current temperature of the bakery exceeds the permissible temperature for some period of time. In reaction to the situation the main light on the console is changed to red, and next, alternatively, the controller switches off the system, or

the user decides about switching off or setting a new permissible temperature.

behavior and its properties using a uniform mechanism of sequence diagrams.

the behavioral aspect *bSpec* consists of two sets of sequence diagrams:

sequence diagram.

expected behaviors, namely:

system reaches desirable states).

system does not reach unacceptable states).

representing components of the system.

Following specific features of real-time systems, a new combined fragment is introduced. It is a composition of two new stereotypes «action» and «reaction» applied to arguments of the combined fragment with operator *strict* (Fig. 2a). This combined fragment expresses a typical cooperation schema between a computer system and its environment: the system should respond to signals received from the environment. The argument with the stereotype «action» specifies a message or a sequence of messages that represent a stimulus from the environment, and the argument with the stereotype «reaction» specifies a message or a sequence of messages that represent the system response. Both arguments are linked via strict sequencing operator which means that if the scenario represented by the argument «action» is executed then the scenario represented by the argument «reaction» must occur.

The other two combined fragments presented in Fig. 2b and 2c are new stereotypes of *assert* and *neg* combined fragments. The fragments are used to define liveness and safety properties, respectively, of the specified system. The first one means that if the execution reaches the beginning of the construct, then the behavior of the fragment, as an expected behavior of the specified system, must occur. The second one defines the behavior of the fragment, as a forbidden behavior of the system, may not occur.

Fig. 2. Examples of sequence diagram with specific combined fragments
