**5. Specification properties**

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

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

(which forms the considered interaction scenario) contains any matched message which

The message in the activation part of the combined fragment in Fig. 6 informing about a change of the temperature requested by the user (message Z), entails incompleteness of the specification. The message specifies system's reaction to the action from its environment and therefore links two different fragments of the same scenario. However, there is no another

The complete graph of all possible scenarios with the results of its analysis is given in Fig. 9.

value would be assigned to the considered variable.

diagram containing this message in its reaction part.

Fig. 9. Complete (interpreted) graph of possible scenarios

whereas it is not possible for completeness. Completeness refers to the domain of application and therefore it requires domain expertise; it can also be validated experimentally.

As our specifications are executable, the experiments are possible and the user observing system's behavior may decide on completeness of the specification. Nevertheless, some aspects of completeness may be checked automatically. For example, if a sequence diagram contains a message being the system response, a stimulating action is expected.

The notions of definiteness and consistency as defined below may be automatically checked. Consistency is essential and indispensable property of the specification. General definition of consistency is given in (Huzar & Walkowiak, 2010). Here, we concentrate on partial orders of exchanged messages defined by different sequence diagrams. Two orders are consistent, if the sequences determined by matching messages are the same. Consistency of specification means that partial message orders, determined by different sequence diagrams defining one scenario of interactions between the system and its environment, are consistent.

The specification is undefined if there is at least one undefined transition in a scenario derived from the set of sequence diagrams. A transition may be undefined due to an undefined value of exchanged messages.

The algorithm constructing the graph of possible scenarios is extended by the analysis of consistency, definiteness and completeness of the specification.

The analysis of the specification is carried out during the configuration transformations. Particular configurations are processed until the following appears:


Now we consider consistency, definiteness and completeness of the exemplary specification.

The sequence diagrams in Figs. 4c and 5b represent fragments of the same scenario of the interaction between the system and its environment. The scenario specifies the system response to the situation when the bakery temperature exceeds the desired temperature by 500 C by 10 seconds from the time of its detection.

Observe that there is a contradiction in ordering of the matching messages *setBackgound*(WHITE) and *setText*(-) on these diagrams. According to the diagram in Fig. 5b when the alarm is detected, the display's background is change to white and next its content is reset. According to the diagram in Fig. 4c, in this situation the controller changes its state to OFF, and the display's content is reset, and next its background is changed to white.

Using of the variable in the message C, Fig. 4b, changing display's background, results in specification indefiniteness – lack of an event, which allows defining the value of the considered variable during the execution. The variable is not symbolic (its value isn't assigned by the environment), and none of diagrams activated during the transformation 106 Real-Time Systems, Architecture, Scheduling, and Application

whereas it is not possible for completeness. Completeness refers to the domain of application and therefore it requires domain expertise; it can also be validated experimentally.

As our specifications are executable, the experiments are possible and the user observing system's behavior may decide on completeness of the specification. Nevertheless, some aspects of completeness may be checked automatically. For example, if a sequence diagram

The notions of definiteness and consistency as defined below may be automatically checked. Consistency is essential and indispensable property of the specification. General definition of consistency is given in (Huzar & Walkowiak, 2010). Here, we concentrate on partial orders of exchanged messages defined by different sequence diagrams. Two orders are consistent, if the sequences determined by matching messages are the same. Consistency of specification means that partial message orders, determined by different sequence diagrams defining one scenario

The specification is undefined if there is at least one undefined transition in a scenario derived from the set of sequence diagrams. A transition may be undefined due to an

The algorithm constructing the graph of possible scenarios is extended by the analysis of

The analysis of the specification is carried out during the configuration transformations.



Now we consider consistency, definiteness and completeness of the exemplary specification. The sequence diagrams in Figs. 4c and 5b represent fragments of the same scenario of the interaction between the system and its environment. The scenario specifies the system response to the situation when the bakery temperature exceeds the desired temperature by

Observe that there is a contradiction in ordering of the matching messages *setBackgound*(WHITE) and *setText*(-) on these diagrams. According to the diagram in Fig. 5b when the alarm is detected, the display's background is change to white and next its content is reset. According to the diagram in Fig. 4c, in this situation the controller changes its state to OFF, and the display's content is reset, and next its background is changed to white.

Using of the variable in the message C, Fig. 4b, changing display's background, results in specification indefiniteness – lack of an event, which allows defining the value of the considered variable during the execution. The variable is not symbolic (its value isn't assigned by the environment), and none of diagrams activated during the transformation

contains a message being the system response, a stimulating action is expected.

of interactions between the system and its environment, are consistent.

consistency, definiteness and completeness of the specification.

Particular configurations are processed until the following appears:

(the set of live copies of the reached configuration is empty),

undefined value of exchanged messages.


messages in reaction part (incompleteness).

500 C by 10 seconds from the time of its detection.

(which forms the considered interaction scenario) contains any matched message which value would be assigned to the considered variable.

The message in the activation part of the combined fragment in Fig. 6 informing about a change of the temperature requested by the user (message Z), entails incompleteness of the specification. The message specifies system's reaction to the action from its environment and therefore links two different fragments of the same scenario. However, there is no another diagram containing this message in its reaction part.

The complete graph of all possible scenarios with the results of its analysis is given in Fig. 9.

Fig. 9. Complete (interpreted) graph of possible scenarios



$$\mathbf{s}\_{sd} = \{ \langle l, t \rangle \, | \, l \in \text{sd}. L, t \in l. T \} \tag{6.1.1}$$


$$\forall\_{l \in \text{sd}.L} \colon \forall\_{l.t\_x \in T} \colon \chi \le \mathfrak{x} \iff l.t\_\chi \in T \tag{6.1.2}$$

$$\forall\_{\langle l,t\rangle \in \mathfrak{s}\_{\text{sd}}} ; \forall\_{t' \in l.T} ; t' \prec\_{\mathfrak{s}d} t \iff t' \in \mathfrak{l} \text{ s}\_{\text{sd}} \tag{6.1.3}$$

$$\mathbf{lc}\_{sd} = \langle \mathbf{s}d, \mathbf{s}\_{sd}, mode \rangle \tag{6.1.4}$$


$$\begin{array}{l}\text{conf} = \langle \text{e}, \text{Lc}\_{\text{spec}}, \text{Lc}\_{\text{forbliden}}, \text{Lc}\_{\text{expected}}, \text{context}, \text{time}\_{\text{context}},\\\text{guards}, \text{Forblidden}, \text{Expected}, \text{type} \rangle\end{array} \tag{6.1.5}$$


$$\text{Let } e \in \text{sd}. E\_{first} \iff \left\{ e \in \text{sd}. E\_{com} \land e.type = \text{send} \land \exists\_{e' \in \text{sd}. E\_{com}} \colon e' \prec\_{\text{sd}} e \right\} \tag{6.1.6}$$

$$\text{Let } e \in \text{sd}. E\_{\text{init}} \iff \left( e \in \text{sd}. E\_{\text{first}} \land \text{src} \left( e.msg \right) \in \text{Envíromment} \right) \tag{6.1.7}$$

$$e \in \text{lc.} E\_{enabled} \iff \tag{6.1.8}$$

$$\{e \in lc. sd. E\_{com} \cup lc. sd. E\_{sync} \land \nexists\_{e' \in lc. sd. E\_{com} \cup lc. sd. E\_{sync}} \colon \{e' \prec\_{sd} e \land e' \notin \emptyset \land lc. s\_{sd}\} \land \emptyset\}}$$
 
$$\{e. type = send \implies e.msg.recvEvent \in advance(lc. s\_{sd}, e).E\_{enabel})\}$$


$$e \in \operatorname{lc}.E\_{advanced} \iff\tag{6.1.9}$$

$$\{e \in \text{lc.sd.} E\_{com} \land \text{src(e.msg)} \notin \text{Env} \text{return} \land \text{s} \mid \text{reaction(lc.sd)} \in \text{allEnclosing(e)} \land \}$$

$$\{e.msg.arg \neq \bot \Rightarrow \text{val}(\text{lc.e.msg.arg.} \omega) \neq \bot\}$$

$$e \in lc. E\_{reached} \iff \tag{6.1.10}$$

$$\left( e \in lc. sd. E\_{com} \land \left( e \in lc. E\_{enabel} \lor \exists\_{e' \in lc. sd. E\_{sync}} \colon e \in advance(lc, e'). E\_{reached} \right) \right)$$

$$e \in lc.E\_{vlodating} \iff \tag{6.1.11}$$


$$\begin{aligned} \left( \texttt{match}\_{w-\mathit{unif}} \left( \texttt{var'}, \texttt{var} \right) \right) & \left( \texttt{var'}.\omega = \bot \vee\\ \left( \texttt{var'}.\omega = \texttt{var}.\omega \wedge \left( \texttt{var'}.\omega = \texttt{\&} \Rightarrow \texttt{are\\_Connect} \left( \texttt{var'}, \texttt{var} \right) \right) \right) \vee\\ \left( \texttt{var'}.\omega = \texttt{\&} \wedge \texttt{var}.\omega \notin \{\bot, \texttt{\&} \} \wedge \texttt{var}.\omega \notin \texttt{var'}.\Phi \right) \end{aligned} \tag{6.1.12}$$

 $\textit{s} \textit{match}\_{\textit{s}-\textit{unif}}(var', var) \triangleq \textit{s}$ 
$$\left(var'.\omega = var.\omega \wedge \left(var'.\omega = \mathbb{k} \Longrightarrow \textit{areConnect(var', var)}\right)\right) \tag{6.1.13}$$


$$\begin{aligned} \mathit{match}\_{q-\mathit{unif}}(\mathit{msg'}, \mathit{msg}) & \stackrel{\scriptstyle \omega}{=} \{ \mathit{src(msg')} = \mathit{src(msg)} \land \mathit{dst(msg')} = \mathit{dst(msg)} \land \\ \mathit{msg'}.o &= \mathit{msg}.o \land \mathit{match}\_{q-\mathit{unif}}(\mathit{msg'}.\mathit{arg,\mathit{msg}.\mathit{arg}}.\mathit{arg)} \end{aligned} \tag{6.1.14}$$

$$\text{match}\_{a-unif}(\mathbf{e}', \mathbf{e}) \triangleq \left\{ \mathbf{e}'.\text{type} = \mathbf{e}.\text{type} \land \text{match}\_{a-unif}(\mathbf{e}'.\text{msg}, \mathbf{e}.\text{msg}) \right\} \tag{6.1.15}$$

$$G\_{b\text{Spec}} = \langle V\_{b\text{Spec}}, A\_{b\text{Spec}}, guard \rangle \tag{6.1.16}$$






$$E\_{init} = \left\{ e \middle| e \in \cup\_{sd \in b \in p \gets s \not D\_{space}} \text{sd}. E\_{init} \right\}.$$

$$factor(c\_0, E\_{limit})\tag{\*} \text{ definition 6.2.1}$$

	-

$$V\_{b\small Spec} \gets V\_{b\small Spec} \cup \{\upsilon\}\_{\prime}$$

$$A\_{b\mathcal{S}pec} \leftarrow A\_{b\mathcal{S}pec} \cup \{a\}.$$


$$A\_{bSpec} \gets A\_{bSpec} \cup \{a\}\_{\prime}$$


$$E\_{advanced} = \left\{ e \middle| e \in \cup\_{lc \in c.Lc\_{spec}} lc. E\_{advanced} \right\}.$$

$$\{\exists\_{e \in E}\_{e \in E, a \text{v} \text{n} \text{c} \text{c} \text{s}} \colon e \in \mathsf{U}\_{s d \in b \text{S} \text{p} \text{c} \text{c}} \text{ s}d. E\_{\text{sym}}\};$$


$$A\_{b\underline{S}pec} \gets A\_{b\underline{S}pec} \cup \{a\}\_b$$

$$\{\exists\_{e \in E\_{advancat}} \colon e \in \cup\_{sd \in b\mathcal{Speed}} \text{sd}.E\_{com}\} \colon$$

$$factor \text{(c, E}\_{advanced)}. \tag{\*} \text{ definition 6.2.1}$$


$$\mathcal{V}\_{b\text{Spec}} \gets \mathcal{V}\_{b\text{Spec}} \cup \{\upsilon'\}\_{\prime}$$

$$A\_{b\mathcal{S}pec} \leftarrow A\_{b\mathcal{S}pec} \cup \{a\}.$$


$$\left(\exists\_{\mathbf{e}\in\bigcup\_{\mathbf{l}\text{e}\in cLc\_{\text{spec}}}}\mathbf{l}\mathbf{c}.E\_{\text{anabld}}\right)$$

$$\left(\exists\_{e \in \cup\_{lc \gets c \gets pac}} \operatorname{lc \to\_{enab \gets l}} \right)$$

$$c.type \leftarrow in complete,$$

$$\forall\_{e \in E} \colon E\_{out} \gets E\_{out} \cup \{ \operatorname{copy}(e) \}.$$

$$\forall\_{\mathbf{e},\mathbf{e'} \in \mathcal{E}\_{\text{out}}} \colon \mathbf{e} \neq \mathbf{e'} \land \text{conf.} \, \mathsf{match}\_{\mathsf{w} - \mathsf{unif}} \{\mathsf{e}, \mathsf{e'}\} \land \mathsf{var} \neq \bot \land \mathsf{var}. \, \mathsf{o} \in \{\bot, \mathsf{k}\} \land \mathsf{var'}. \, \mathsf{o} \notin \{\bot, \mathsf{k}\} \implies \mathsf{z} \mathsf{a} \mathsf{r}. \, \mathsf{A} \mathsf{q} \leftarrow \mathsf{v} \mathsf{a} \mathsf{r}. \, \mathsf{A} \mathsf{q} \to \{\mathsf{v} \mathsf{a} \mathsf{r}. \, \mathsf{a}\} \to \mathsf{a} \mathsf{q}$$

$$lc \leftarrow advance(lc, e).$$



$$lc.mode \gets \textit{reaction}\_{\prime\prime}$$

$$lcleftarrow \text{ } advance(lc, \langle cf, \text{exit} \rangle).$$


$$L\mathfrak{c}\_{\mathrm{spec}} \leftarrow L\mathfrak{c}\_{\mathrm{spec}} \backslash \{lc\}.$$

$$Lc\_{forbilden} \leftarrow Lc\_{forbilden} \text{ } \{lc\}\_{\prime}$$


$$\left(\exists\_{e' \in lc.E\_{\nu \wedge \iota \wedge \iota \wedge \iota \wedge \iota}} \colon c. \operatorname{match}\_{s-unif}(e', e)\right)$$

$$c.type \leftarrow võolating.$$

$$L\mathfrak{c}\_{smec} \leftarrow L\mathfrak{c}\_{smec} \cup \{lc = \langle \mathrm{sd}, initial(\mathrm{sd}), action \rangle\}\_{\ell}$$

$$\mathsf{Lc}\_{forbilden} \leftarrow \mathsf{Lc}\_{forbilden} \cup \{ \mathsf{lc} = \langle \mathsf{sd}, initial(\mathsf{sd}), check \rangle \}.$$

$$\mathsf{Lc}\_{\text{expected}} \leftarrow \mathsf{Lc}\_{\text{expected}} \cup \{ \mathsf{lc} = \langle \mathsf{sd}, initial(\mathsf{sd}), check \rangle \}$$


$$c \xrightarrow{\iota''}\_{sync} c' \iota$$

$$guard \gets guarantees \land cf. guard$$

$$lc \leftarrow advance(lc, e'),$$

$$c \xrightarrow{\mathfrak{c''}}\_{\text{symc}} c'.$$


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

In the chapter we present a way of effective application of UML sequence diagrams to realtime system specification. Assumption that specification of a system is represented by a set of sequence diagrams is close to the agile software development methodologies: each sequence diagram represents a single user story, and the set of sequence diagrams should

In general, the proposed approach to a construction of system specification may be considered as a bottom-up approach – on the base of a set of user stories a complete specification and its semantics is derived. A consequence of the approach is the need to check consistency of the set of user stories. Another bottom-up approach basing on Live Sequence Charts is presented in (Harel & Marelly, 2003). The approach was also inspiration for our works. It is worth to note that application of Live Sequence Charts is further developed in (Maoz &

Opposite approaches to system specification are classified as top-down ones. Within these approaches, specification is constructed as a set of hierarchically ordered sequence diagrams. The diagrams at higher level of the hierarchy are composed from diagrams at lower level of the hierarchy, by means of some composition operators. An example of such approach, adopting Message Sequence Charts, is presented in (Cleaveland & Sengupta,

Lack of precise, formal semantics for UML sequence diagrams brings many interpretation problems. An illustration of this statement is more than a dozen proposals for the semantics of sequence diagrams, which are surveyed in (Micskei & Waeselynck, 2011). However, in contrast to our approach, it should be emphasized that these proposals concern only

The proposed approach to semantic definition of a set of UML sequence diagrams is based on transformation of the set into a graph of all possible scenarios. The graph enables system analyst to give answer to practical questions about consistency and completeness of scenarios, and thus about consistency and completeness of specification. Additionally, both consistency and definiteness may be checked automatically on the-fly. The checking algorithm was implemented as a programming tool supporting edition and analysis of specifications (Walkowiak, 2011). This tool has a form of plug-in to Visual Paradigm modeling

Cleaveland, R. & Sengupta,B. (2006). Triggered Message Sequence Charts. *IEEE Transactions on Software Engineering ,* Vol. 32, No. 8, (Aug. 2006), pp. (587 - 607), ISSN 0098-5589 Harel, D. & Marelly, R. (2003). Come, Let's Play: A Scenario-Based Approach to

Harel, D. & Maoz, S. (2008). Assert and Negate Revisited: Modal Semantics for UML

Huzar, Z. & Walkowiak, A. (2010). Specification of real-time systems using UML sequence

Sequence Diagrams, *Software and Systems Modeling,* Vol. 7, No. 2, (May 2008), pp.

diagrams, Przegląd Elektrotechniczny (Electrical Review), R. 86 NR 9/2010, pp.

represent complete description of the designed system.

individual sequence diagrams, but not the set of diagrams.

Programming, ISBN 3-540-00787-3, *Springer* 

(237-252), ISSN 1619-1366

226-229, ISSN 0033-2097

Harel, 2011).

2006).

tool.

**8. References** 

Fig. 20. The activity diagram presenting the construction of the graph of possible scenarios

In the chapter we present a way of effective application of UML sequence diagrams to realtime system specification. Assumption that specification of a system is represented by a set of sequence diagrams is close to the agile software development methodologies: each sequence diagram represents a single user story, and the set of sequence diagrams should represent complete description of the designed system.

In general, the proposed approach to a construction of system specification may be considered as a bottom-up approach – on the base of a set of user stories a complete specification and its semantics is derived. A consequence of the approach is the need to check consistency of the set of user stories. Another bottom-up approach basing on Live Sequence Charts is presented in (Harel & Marelly, 2003). The approach was also inspiration for our works. It is worth to note that application of Live Sequence Charts is further developed in (Maoz & Harel, 2011).

Opposite approaches to system specification are classified as top-down ones. Within these approaches, specification is constructed as a set of hierarchically ordered sequence diagrams. The diagrams at higher level of the hierarchy are composed from diagrams at lower level of the hierarchy, by means of some composition operators. An example of such approach, adopting Message Sequence Charts, is presented in (Cleaveland & Sengupta, 2006).

Lack of precise, formal semantics for UML sequence diagrams brings many interpretation problems. An illustration of this statement is more than a dozen proposals for the semantics of sequence diagrams, which are surveyed in (Micskei & Waeselynck, 2011). However, in contrast to our approach, it should be emphasized that these proposals concern only individual sequence diagrams, but not the set of diagrams.

The proposed approach to semantic definition of a set of UML sequence diagrams is based on transformation of the set into a graph of all possible scenarios. The graph enables system analyst to give answer to practical questions about consistency and completeness of scenarios, and thus about consistency and completeness of specification. Additionally, both consistency and definiteness may be checked automatically on the-fly. The checking algorithm was implemented as a programming tool supporting edition and analysis of specifications (Walkowiak, 2011). This tool has a form of plug-in to Visual Paradigm modeling tool.
