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

UML (OMG, 2011) is considered as a contemporary standard in information systems development. Being a graphical modeling language it offers a family of diagrams that may be used for specification and designing of information systems. Sequence diagrams, being a part of the family, are very often used to specify functional requirements of the developed systems and are typically associated with the use case realizations in the logical view of the system under development. They show how actors involved in the scenario representing a use case realization cooperate with system’s objects. Therefore, the meaning of a sequence diagram is a set of scenarios, each describing interaction between objects of the designed system and its environment. Semantics of sequence diagrams is defined informally in plain language, and, additionally, the definition is limited to the interpretation of single diagrams. But in nontrivial cases a set of sequence diagrams is necessary to give a complete specification of the system’s behavior, and therefore the interpretation of the set of such diagrams is needed. Since UML has informal semantics, a set of sequence diagrams brings some interpretation problems. The problem becomes even more difficult when the real-time systems are designed when numerous time constraints are associated with the diagrams.

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 behavior.
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.
The chapter is organized as follows.
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 extended sequence diagrams is used to represent the behavior of a real-time system. 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 diagramssequence diagrams -representing forbidden and expected behaviors. In this way we introduce some redundancy to the behavior specification, which enables checking safety and liveness of system's behavior. The approach is illustrated by a simple example.
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 completeness. These properties are defined and discussed in Section 5.
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 diagrams.
Section 7 ends the chapter with concluding remarks.

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.

www.intechopen.com
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. 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.
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.

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 objects diagrams while specification of the behavioral aspect bSpec -by a set of extended UML sequence diagrams. So, the system specification is defined as:

Spec UML = <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 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:

= ∪
where the set specifies the desired behavior of the system, and the set Sd monit defines monitored behaviors. The monitored behaviors may in turn be split into forbidden and expected behaviors, namely: 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.

Informal semantics of a set of sequence diagrams
The definition of UML presented in the standard (OMG, 2011) is informal. Lack of formal semantics brings ambiguity problems (Harel & Maoz, 2008;Störrle, 2004), especially in the case of automation of system development process and design of tools supporting the process. Furthermore, the possibility of UML model-checking is limited to syntax verification. To allow analysis of the properties of the spetcification formulated in UML, we propose a transformation of the specification -a set of sequence diagrams -to the abstract model which describes the behavior of the modeled system as a graph of possible scenarios (Fig. 8).
The graph of possible scenarios consists of nodes and arcs. Nodes represent system's configurations, meaning its states. Arcs represent events that cause transitions between configurations. Events may represent message sending or message receiving, time events and synchronization events. The latter are related to entering into or exiting from the combined fragments or their arguments.
The structure of the graph is similar to a tree. The root of the tree represents an initial configuration, in general, while leafs represent final configurations. It is possible however for some leafs to return to the initial configuration what is formally represented by an arc labeled with an artificial event δ. It is also possible to have loops for some configurations. The loops are labeled by synchronization events that do not change system configurations. A sequence of transitions starting from the initial configuration (a scenario) may be finite or infinite. The set of all sequences of transitions defines the set of possible scenarios of interactions between the system and its environment.  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 given single diagram contains its location constitutes a snapshot of the diagram.
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 configuration. A configuration is changing when an event appears.
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 construction is presented in details in Section 6.

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 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: the end of interaction being a reaction to a stimulus from the environment is reached (the set of live copies of the reached configuration is empty), -inconsistency in the message orders, -identification of the events, which refer to indefinite values of messages (indefiniteness), -identification of the messages exchanged between the system elements or the messages sent from the system to its environment such that they appear in activation part of a sequence diagram and there is not another sequence diagram which contains the same messages in reaction part (incompleteness). 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 50 0 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 (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.

Graph of possible scenarios
The Section gives formal definitions (subsection 6.1) that are necessary to present formally construction of the graph of possible scenarios (subsection 6.2). In this way formal semantics of a set of extended sequence diagram is defined.

Basic definitions
In the definitions given below we introduce basic meta-classes from the meta-model of the extended sequence diagram. For the sake of simplicity we will treat the meta-classes as sets of specific elements. Therefore the notation e : M, where e is a name of an element, and M is a name of a meta-class, will be read: e is an instance of the meta-class M, or e is an element of the set M.
We will use dotted notation: if e is some element and p is its property then the expression e.p means the value of the property p of the element e.
Notation and meta-elements of the system specification

The function
: yields the instance which sends a message: ) = . .

The function
: yields the instance which receives a message: ) = . .

The function
: for a given sequence diagram, yields the argument of a combined fragment stereotyped by « » The function : for a given sequence diagram, yields the argument of a combined fragment stereotyped by « » The function : ∪ ∪ ∪ ⊥ for a given specification element, yields an argument of the combined fragment in which the element is nested directly; if there is no such an argument the function returns ⊥ The function : ∪ ∪ for a given specification element, yields a list of arguments of all combined fragment in which the element is nested: ≼ ⊆ A partial ordering relations defined on the set of time points at lifelines of a given extended sequence diagram ≼ ⊆ A partial ordering relations defined on the set of events of a given extended sequence diagram The series of the following definitions refines some notions, e.g. snapshot, configuration, which were informally introduced in Section 4. where: --is a lifeline of an object from the diagram sd, and --is a time instance at the lifeline representing time of a communication event or a synchronization event on entry to or exit from a combined fragment.

The function
: ℎ yields an initial snapshot of a sequence diagram.
An example of a snapshot of a sequence diagram is presented in Fig. 10.  where: --is a copy of the sequence diagram with the valuation of its variables, --a snapshot of the sequence diagram showing the progress of the behavior described by the diagram, and -, , ℎ -a state of the active copy. The active copy is in the a state if realizes behavior specified in the activation part of the diagram, in the state if realizes behavior specified in the reactive part of the sequence diagram, and in the ℎ state if realizes behavior specified by the monitoring diagram.
Let an active copy and a variable with the valuation established for the active copy be given (see example in Fig. 11) indicates by or false whether valuation of the variable is undefined. Fig. 11. An example of an active copy If an active copy is known and a given event happens then by applying the function : × a new active copy is defined.
Definition 6.1.5 A configuration of a set of sequence diagrams, noted : Configuration, is defined as the tuple: where: --is a communication event which causes a transition to a new state represented by the configuration, = ⊥ for the initial configuration, --a subset of active copies of the sequence diagrams specifying required behavior, --a subset of active copies of the sequence diagrams specifying forbidden behavior, --a subset of active copies of the sequence diagrams specifying expected behavior, --a set of bound variables, which values are agreed during a transition to the configuration, -_ -a set of time instants of the event e and other events associated with e, --a condition for realization of the communication event e, --a set of sequence diagrams specifying forbidden behavior, --a set of sequence diagrams specifying expected behavior, -, , , , ⊥ -type of the final configuration; -indicates that the configuration is the result of a completely executed reaction to the event incoming from system's environment; -indicates whether the configuration leads to the violation of event order; -indicates whether the configuration represents an undefined state of a system; indicates whether the configuration represents an incomplete state of system; ⊥ indicates the leaf-configuration.
An example of a configuration of a set of sequence diagrams is presented in Fig. 12. An event e is a first event in the diagram sd if it belongs to the set of communication events of the diagram, and it is a message sending event, and there are no other events that precede e in the sense of the relation ≼ : : ≼ (6.1.6) Examples of first events for sequence diagrams are presented in Fig. 13. An event e is an initial event of the sequence diagram sd if it belongs to the set of first events of the diagram and it is message event which is sent by the environment of the system: An example of an initial event for a sequence diagram is presented in Fig. 14. An event e is enabled in the active copy if it belongs to the set of events of the diagram . , and the time points of the snapshot for all lifelines representing instances participating in realization of the event e directly precede e, and there is no a such event e' that proceeds e (does not belong to the lower closure of the snapshot ⇃ . ).
If e is a communication event sending a message and e'' is a communication event receiving the message then e'' is enabled in the snapshot representing realization of the event e: . (6.1.8) . . , ). ) An example of time point associated with an enabled event for an active copy of a sequence diagram is presented in Fig. 15. An event e causes a transition of the active copy if: • it belongs to the set of enabled events for the active copy, and • if it is associated with the message sending by the system then it also belongs to the scenario representing system's reaction (part « ») and the variable to which it refers has defined value: .
. ≠⊥ , . . . ) ≠⊥) ) www.intechopen.com An example of time point associated with an event causing transition for an active copy of a sequence diagram is presented in Fig. 16. An event e is reachable for the active copy if it is the enabled communication event for the copy or if there exists a synchronization event e' such that e is reachable for the active copy representing realization of the event e': . (6.1.10) . .  .

: , ).
An example of a time point associated with the reachable event for an active copy is presented in Fig. 17. An event e violates events' ordering of the active copy if it belongs to the set of obligatory communication events of the diagram . , but it is not reachable for the copy: . (6.1.11) . . . . . .

: )
An example of time points associated with violating events for an exemplary active copy is presented in Fig. 18.   Table 1. Definition of the strict-unifiable and weak-unifiable variables, where is a concrete value.
Definition 6.1.14 A message is weak-unifiable ( strict-unifiable) with a message when both messages are sent between the same objects, and relate to a call of the same operation and have weak-unifiable (strict-unifiable) arguments: , . ) (6.1.14) where q means 'weak' or 'strict'.

Definition 6.1.15
A communication event is weak-unifiable (strict-unifiable) with a communication event when both events are of the same type (sending or receiving), and relate to a weak-unifiable (strict-unifiable) message: where q means 'weak' or 'strict'.

Let
: ℎ means the specification of the system behavior expressed by a set of extended UML sequence diagrams. where: www.intechopen.com --a set of graph vertices; each vertex is labeled by a configuration which is reachable from the initial configuration, --a set of graph arcs; each arc is labeled by an event; each arc has the form , , , where , are vertices labeled by , : , and : is the event which causes a transition from to c 2 , noted by → , -: ∪ ⊥ -a partial function that assigns a Boolean expression to an arc.
Further, we will use the function, : , which for a given vertex of the graph of possible scenarios returns a configuration labeling the vertex.

Construction of the graph of possible scenarios
The algorithm of construction of the graph of possible scenarios is presented below. To facilitate presentation of the algorithm a state machine diagram presenting an active copya component of a transformed configuration -is shown in Fig. 19. A detailed description of the algorithm is summarized in the form of an activity diagram in Fig. 20, after its textual description. CREATE -One of the first events of the diagram occurs -e1 -The SyncEvent -exit from the argument with the stereotype «action» of the diagram occurs -e2 -The SyncEvent -exit from a combined fragment with the stereotype «action»/«reaction» of the diagram occurs -e3 -The SyncEvent -exit from a combined fragment with the stereotype «forbidden» or «expected» of the diagram occurs -e4 -One of the violates events' ordering events of the diagram occurs -e5 -when(condition), where the condition is defined as: 'The set of events causing transitions for active copies within the configuration is empty'. GUARDS: -Q1 -The specification diagram -Q2 -The monitoring diagram -Q3 -Active Copy is the last element of the set of active copies of the configuration -Q4 -The set of events that are accessible at the given configuration contains the event which refers to a variable whose value is not specified -Q5 -The set of events that are accessible at the given configuration contains the system event which belongs to the scenario representing system activation a. If the set of active copies of the configuration is empty . = return to the initial configuration in which the system awaits for events from its environment: i. the configuration is considered as complete final configuration: .
← , ii. let be an arc of the form , , : iii. go to step 4.
b. The set of events which enable transitions for active copies within the configuration c is defined: iii. go to step 4.
www.intechopen.com e. If the set is empty = ) then: i. If the set of events that are accessible at the given configuration contains the event which refers to a variable whose value is not specified, i.e. ⋃ .
the configuration is considered as unspecified final configuration which represents system's deadlock: . ← , ii. If the set of events that are accessible at the given configuration contains the system event which belongs to the scenario representing system activation, i.e. ⋃ .
the configuration is considered as incomplete final configuration which represents system's deadlock: . ← , iii. go to step 4.

Definition 6.2.1
Factorization of the set of the activating events which cause transitions (elimination of copies, marking the symbolic variables, determining forbidden values of the symbolic variables) -: , : [ ]) is defined as follows: Let the set of events with a fixed valuation of variables is empty, i.e. = : 1. Create a copy of the events: 2. Remove repetition of the strict-unifiable events: 3. For each event  , which has a statically undefined variable, extend the set of forbidden values about the statically defined values of variables of the events ′ , which are weak-unifiable with e: where: www.intechopen.com = .
. , 4. Each event sending by system's environment, which refers to a variable with statically undefined value, declare/label its variable as symbolic: The transition relations → ′ is defined by the following rules: For each active copy of the configuration c . ∪ . ∪ . for which the event e is reachable . ): 1. modify the snapshot of the active copy: , ).
2. if the event e represents an entry to a combined fragment = , ): a. which is a strict sequence, negation or assertion combined fragment .  , , ) then: b. which is a parallel or alternative combined fragment .  , ) then: 3. if the event e represents an exit from an argument of a combined fragment = .
, ): a. which is a strict sequence . = ): i. if there exists a subsequent argument of the combined fragment then entry to the argument: ii. if the event e is an exit from the argument with the stereotype «action» . = . ) then: . , The procedure of event unification is defined as follows: ′, ) /* definition 6.2.5 Definition 6.2.5 The binding variables procedure is defined as follows: , ) 1. , , 2. If the variable x or were bounded already then merge the sets:

Conclusions
UML sequence diagrams allow capturing requirements in a convenient way. Due to their simple, intuitive syntax and semantics, they are a suitable communication medium between analysts, developers, customers and end-users. Due to their focus on inter-object communication they are useful for specification of reactive systems, in particular real-time systems.
Of course, they are not the only UML diagrams that may be used for real-time systems specification. For example, in (Roubtsova et al., 2000), system's specification consists of a class and object diagrams representing static, and state diagrams representing behavior aspect of the specification.
www.intechopen.com 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.