**3. Real-time system specification**

In the presented approach to system specification we define the system as a pair of two elements: the system structure that expresses the static aspect, and its behavior that presents the dynamic aspect of the system. Specification of the static aspect *sSpec* is expressed by UML class and obje**c**ts diagrams while specification of the behavioral aspect *bSpec* – by a set of extended UML sequence diagrams. So, the system specification is defined as:

$$Spec\_{UIM} = \text{} \text{ 1$$

In a typical approach, one would expect that the set of sequence diagrams *bSpec* will specify only the desired behavior of the developed system. Usually, such a set of sequence diagrams 100 Real-Time Systems, Architecture, Scheduling, and Application

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

of extended UML sequence diagrams. So, the system specification is defined as:

In the presented approach to system specification we define the system as a pair of two elements: the system structure that expresses the static aspect, and its behavior that presents the dynamic aspect of the system. Specification of the static aspect *sSpec* is expressed by UML class and obje**c**ts diagrams while specification of the behavioral aspect *bSpec* – by a set

*SpecUML= <sSpec, bSpec >*  In a typical approach, one would expect that the set of sequence diagrams *bSpec* will specify only the desired behavior of the developed system. Usually, such a set of sequence diagrams

**3. Real-time system specification** 

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

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, the behavioral aspect *bSpec* consists of two sets of sequence diagrams:

$$b \\$pec = \\$d\_{spec} \cup \\$d\_{monit}$$

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 expected behaviors, namely:

$$\mathcal{S}d\_{monit} = \mathcal{S}d\_{forblidden} \cup \mathcal{S}d\_{expected} \cdot$$

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 system does not reach unacceptable states).

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 system reaches desirable states).

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 behavior and its properties using a uniform mechanism of sequence diagrams.

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 representing components of the system.

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.

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

Fig. 5. Sequence diagrams – representation of the second user story

Fig. 6. Sequence diagrams – representation of the third user story

permissible temperature by the user.

The last, a very simple user story – Fig. 6 – describes reaction of the system on setting a new

Two sequence diagrams in Fig. 7 represent the expected and forbidden behaviors of the specified system. The scenario from Fig. 7b should belong to the set of expected scenarios of

the system, while the scenario from Fig. 7a should not belong to this set of scenarios.

Fig. 3. Class diagram for the example

Fig. 4. Sequence diagrams – representation of the first user story

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

Fig. 3. Class diagram for the example

Fig. 4. Sequence diagrams – representation of the first user story

Fig. 5. Sequence diagrams – representation of the second user story

The last, a very simple user story – Fig. 6 – describes reaction of the system on setting a new permissible temperature by the user.

Fig. 6. Sequence diagrams – representation of the third user story

Two sequence diagrams in Fig. 7 represent the expected and forbidden behaviors of the specified system. The scenario from Fig. 7b should belong to the set of expected scenarios of the system, while the scenario from Fig. 7a should not belong to this set of scenarios.

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

The algorithm constructs the graph while walking from one location to another location along the lifelines on the sequence diagrams. A location is a time point on an object's lifeline with attached event, e.g. sending or receiving message. A set which for each lifeline of a

The snapshot represents current progress of the behavior modeled by the sequence diagram. The diagram together with its snapshot and the values of currently exchanged messages constitute a live copy of the diagram. The set of live copies of all diagrams which are involved into common scenario, i.e. operate on the same messages, determines a configu-

Of course, construction of the graph has to take into account all possible relationships between scenarios presented by individual sequence diagrams. In particular, in the first place, a consistency between scenarios has to be checked. The algorithm of the graph

Each specification should be unambiguous and a complete formulation of the user's requirements. We check the specification against the following three properties: definiteness, consistency and completeness. Definiteness and consistency may be checked automatically

given single diagram contains its location constitutes a snapshot of the diagram.

Fig. 8. Fragments of the graph of possible scenarios

ration. A configuration is changing when an event appears.

construction is presented in details in Section 6.

**5. Specification properties** 

Fig. 7. Sequence diagrams – representation of expected and forbidden behaviors
