Formal Modelling of Java GUI Event Handling

Jessica Chen

School of Computer Science, University of Windsor,

Windsor, Ont. Canada N9B 3P4
[email protected]

Abstract. Programming in Java Swing and AWT can be quite error-

prone due to the implicit nondeterminism caused by the complex event
handling realized via multithreading. In this work, we provide a frame-
work on formal modelling of Java GUI event handling in terms of labelled
transition systems. The significance of the work is twofold: on one hand,
it provides a formal basis for a better understanding and correct use
of Java GUI event handling mechanism; on the other hand, it lays the
ground work for formally reasoning about the correctness of a GUI-based
Java application against certain properties that, due to the nondetermin-
ism involved, may be hard to detect.

Keywords: Java Swing and AWT, Concurrency, Nondeterminism,

Model Checking, Labelled Transition Systems.

1 Motivation

With the advances of software development and the increasing use of web pro-
gramming technologies, more and more applications now make use of Graphical
User Interface (GUI) to enhance user friendliness. In particular, as Java is gain-
ing its increasing popularity, many web applications now involve graphical user
interface developed with Java Swing and AWT.
However, programming in Java Swing and AWT can be quite error-prone due
to the implicit nondeterminism caused by the complex event handling realized
through the use of multiple threads. To write correct programs thus requires a
good understanding of Java multithreading and the GUI event control. Such a
good understanding is hard to achieve without a precise definition of the working
context. In this paper, we define the operational semantics in terms of labelled
transition systems for the behavior of a GUI-based Java application/applet at
a lower level where event handling mechanism is explicitly specified. This is
essential for the software programmers to get a better understanding of the
internal event control and thus avoid potential errors in their coding.
No programmer can be perfect: both faults and errors are quite common
in software industry practice. In order to detect system faults and errors, vari-
ous static analysis techniques, formal verification techniques, and dynamic test-
ing/debugging techniques have been explored. Although testing has always been
our primary device to guarantee the quality of the systems, some concurrency

C. George and H. Miao (Eds.): ICFEM 2002, LNCS 2495, pp. 359–370, 2002.
c Springer-Verlag Berlin Heidelberg 2002


360 Jessica Chen

control related errors are hard to find because the tests are not repeatable due
to the nondeterminism involved. The Java GUI event systems are typically of
this kind because of the implicitly employed multithreading in the GUI event
handling. For these systems, software verification under certain formalisms and
methodologies usually gives us higher confidence about the system. The formal
model we defined for the Java event handling is the basis for formally reasoning
about the correctness of the a GUI-based Java application/applet against certain
properties that, due to the nondeterminism involved, may be hard to detect by
ordinary testing techniques.
In the following, we first give in Section 2 a brief review of Java GUI event
handling mechanism. Then we present our operational semantics followed by an
example in Section 3 and 4. In Section 5 we discuss how to detect errors via
labelled transition system. The related work is provided in Section 6 and we
have Section 7 for conclusion and final remarks.

2 Java GUI Event Handling Mechanism

Common graphical user interactions include moving the mouse, clicking a but-
ton, typing in a text field, selecting an item from a menu, closing a window, etc.
Java GUIs are event driven: when the user interacts with the GUI, some events
are automatically generated and a proper piece of code may be executed as to
handle each event.
A triggered event contains information about the event type and the event
context.
– GUI events are classified into different types. For instance, single click on a
button can trigger an action event, while moving the mouse around triggers
lots of mouse events.
– The same user interaction on different GUI components may cause totally
different reactions. The event context is the GUI component object on which
the event is triggered.

An event listener is an object who listens for specific types of events generated
on specific GUI objects. Each event listener has pre-defined methods (called event
handlers) to be executed for the events that it listens to.
In order to have the Java run-time system process GUI events, the program-
mer needs to perform two tasks:
– register an event listener for each specific type of event on each specific GUI
object;
– provide implementation of the event handlers to handle such events for each
event listener.
Figure 1 shows a very simple Java application with Swing. It constructs a
JFrame p which contains a JTextField t. l is an event listener object that is
registered to listen to the action events on t. l handles such events by calling its
method actionPerformed which sets t to be non-editable.
 Formal Modelling of Java GUI Event Handling 361

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class NotSafeProg extends JFrame {

private JTextField t;
public NotSafeProg() /* constructor */
{
/* call constructor of superclass JFrame with title “A Wrong Program” */
super(”A Wrong Program”);
t = new JTextField(); /* create a JTextField object t */
/* add t to current JFrame object */
getContentPane().add(t, BorderLayout.NORTH);
TextFieldListener l = new TextFieldListener(); /* create a listener object */
t.addActionListener(l); /* register listener l for action events in t */
setSize(200,100);
setVisible(true);
/* ......do something here...... */
t.setEnabled(true);
}
private class TextFieldListener implements ActionListener {
/* this method is automatically called when action events on t triggered */
public void actionPerformed(ActionEvent e)
{
t.setEnabled(false);
}
}
public static void main(String args[])
{
NotSafeProg p = new NotSafeProg();
p.setDefaultCloseOperation(JFrame.EXIT ON CLOSE);
}
}

Fig. 1. A Swing application with potential error

362 Jessica Chen

When the user interacts with the GUI, all triggered events are put into an
event queue. An internal dispatching thread is dedicated to dispatch the events
from the event queue: it keeps picking the events from the head of the event
queue and dispatching it to the proper event listeners according to the event
type and the associated event context. If there is no listener registered for this
event type and context, the event will be simply ignored. If there are some
listeners registered, then their corresponding predefined event handlers will be
executed.
There is a special kind of events that requires the dispatching thread to
perform by itself the run() method defined on the event context. We use runnable
to denote this type.
The event context is not guaranteed to be thread-safe in general: When an
event is dispatched to a listener, the event handler may be executed in a thread
other than the one that performed the listener registration. The choice of which
thread to use is made by the service provider. Furthermore, when an event is
dispatched to multiple listeners, the service provider will normally choose to
execute the event handlers concurrently in separate threads.
In the above example, the JFrame constructor is called by an implicitly cre-
ated thread (we call it main below) to execute the main() method. Within this
constructor, we have registered l for action events on t. However, the dispatching
thread may assign a thread other than main to execute the event handler of l.
This makes the concurrent executions of event handler and of the JFrame con-
struction possible. As a consequence, while a separate thread is setting t to be
non-editable according to the event handler, it is possible that the main thread
will be trying to set t to be editable. This causes the simultaneous access to the
same GUI object via different threads and hence implies potential errors.
Although here we have only shown a very simple example, the real applica-
tions may take quite complicated forms and thus make the potential errors hard
to see by code walk through. Like in many concurrent systems, to detect such
concurrency-related errors via ordinary testing techniques is also hard mainly
because the tests are not repeatable.

3 Operational Semantics for the Event Handling

We define the operational semantics of the behavior of the Java GUI event
handling mechanism in terms of labelled transition systems. Basically, a labelled
transition system is a triple (States,Labels,→) where
– States is the set of possible states of the program computation;
– Labels is a set of labels showing the information about the state changes;
– →⊆ State × Labels × State is a transition relation that describes the system
l
evolution. (s, l, s ) ∈→ (also written as s −→ s ) expresses that the system

may evolve from state s to state s with the information of the state change
described in l.
A state in our setting consists of the state of objects, the state of event queue,
the state of the registration, and the state of the execution state of the threads.
 Formal Modelling of Java GUI Event Handling 363

An object is represented by a couple (od, st) where od is an object identifier

and st is an object state. An object state consists of a set of field name and field
value pairs. Let P be a given GUI-based Java program under consideration.

– We use Fd to denote the set of field names used in P .

– We use V to denote the set of field values in P . For simplicity, we only
consider integer and boolean values.
– We use Od to denote the set of object identifiers in P . Note that it includes
the identifiers of all thread objects created in the program.
– O ∈ Od → (F d → V ) is a state of objects in P .

An event is represented by a couple (gd, tp) where gd is a GUI object identifier

to denote the event context, and tp is an event type name. An event queue is
represented by a sequence of events.

– We use Gd to denote the set of GUI object identifiers in P . Gd ⊆ Od.

– We use T P to denote the set of type names of GUI events in P . This set
includes the special name runnable for those events that request the dis-
patching thread to execute the run() method of the given runnable objects.
– E ⊆ Gd × T P is a set of events.
– Q ∈ E ∗ is a sequence of events. Let e ∈ E be an event. We use head(Q) to
denote the first event of Q; enqueue(Q,e) to denote the event queue obtained
from Q by adding e to the tail of the queue; dequeue(Q) to denote the event
queue obtained from Q by removing the head event.

An event listener registration is a triple (gd, tp, ld) where gd is the identifier of
the GUI object, i.e. the context of the event; tp is the name of the event type;
and ld is the identifier of the listener object. Such an event listener registration
expresses that the object with identifier ld is registered to listen to the events of
type tp on GUI object with identifier gd.

– We use Ld to denote the set of listener object identifiers. Ld ⊆ Od.

– R ⊆ Gd × T P × Ld is a set of event listener registrations. Let gd ∈ Gd,
ty ∈ T P . We use reg(R,gd,tp) to denote the set of listener objects registered
with gd and tp in R.

In this work, we consider only the following restricted set of atomic actions:
A = {read(od, f d), write(od, f d, v), reg(gd, tp, ld), dereg(gd, tp, ld)
| od ∈ Od, f d ∈ F d, v ∈ V, gd ∈ Gd, tp ∈ T P, ld ∈ Ld}
A sequential program execution can be constructed as a process term [19] based
on a set of atomic actions and a set of operators. For simplicity, we only con-
sider the sequential execution operator denoted by a semicolon. Extension of this
framework to include other operators such as choice, recursion, etc. is straightfor-
ward. For convenience, we assume that such a sequence is a sequence of actions
ended by a special symbol stop.
364 Jessica Chen

– SE ⊆ A∗ ×{stop} is a set of sequential executions. Let smi ∈ A for 1 ≤ i ≤ n

and n ≥ 1. We use sm1 ; . . . ; smn ; stop to denote the program execution of a
sequence sm1 , . . ., smn of actions.
A thread state records the current status of the execution of a thread. It is a
pair (td,se) where td is the thread identifier and se is the program that td needs
to execute.
– We use T d to denote the set of thread identifiers. It includes the special
identifier dt for the dispatching thread. T d ⊆ Od.
– T ∈ T d → SE is a set of thread states.
A method registration is a triple (ld,tp,se) where ld is the identifier of the listener
object, tp is an event type name, and se is the piece of program to be executed
when listener ld handles an event of type tp.
– M ∈ (Ld×T P ) → SE is a set of method registrations. Let ld ∈ Ld, tp ∈ T P .
We use met(M,ld,tp) to denote the piece of program for listener ld to handle
events of type tp.
Given a program, the labelled transition system is a quadraple S, L, →, s0 .
where
S ⊆ O × Q × R × T,
s0 ∈ S is the initial state,
L ⊆ T d × (A ∪ {dispatch, runnable}) ∪ {trigger(e) | e ∈ E},
and O, Q, R, T , E, M , T d, A are as defined above.
The transition relation −→ is defined as the least relation satisfying the
following eight structural rules. All the structural rules have schema:

antecedent
consequent

which is interpreted logically as: ∀(antecedent −→ consequent), where ∀(. . .)

stands for the universal closure of all free variables occurring in (. . .). Observe
that, typically, antecedent, consequent share free variables. In case the an-
tecedent is missing, it is interpreted as true.
In the following, od ∈ Od, f d ∈ F d, v ∈ V, gd ∈ Gd, tp ∈ T P , k ≥ 1, ld, l1 ,
. . ., lk ∈ Ld, sm, sm1 , . . ., smk ∈ SE.

Rule A1 (Dispatch with Listeners)

head(Q) = (od, tp) ∧ tp = runnable∧

reg(R, od, tp) = {l1 , . . . , lk } ∧ 1≤i≤k met(M, li , tp) = smi
(dt,dispatch)
O, Q, R, T ∪ {(dt, stop)} −−−−−−−−−→
O, dequeue(Q), R, T ∪ {(dt, stop), (t1 , sm1 ), . . . , (tk , smk )}
 Formal Modelling of Java GUI Event Handling 365

where ti are new threads (1 ≤ i ≤ k), and T does not include the behavior of
the dispatching thread.
The first rule is used to define the possible evolution of the system caused by
the event dispatching of the dispatching thread when the first event of the event
queue is a GUI event and there are listeners registered in the current R to handle
it. In this case, the whole system makes the related transition corresponding to
the one by the dispatching thread while all other threads remain in the same
state. In the ending state of the system, the GUI event is removed from the event
queue Q, and there are new threads generated to perform each of the handling
tasks of the listeners registered for this event. Note that the dispatching thread
should have no code to execute (i.e. in state stop) in order to dispatch events
from the event queue, otherwise it has to execute its own code first.

Rule A2 (No Listener Dispatch)

head(Q) = (od, tp) ∧ tp = runnable ∧ reg(R, od, tp) = ∅

(dt,dispatch)
O, Q, R, T ∪ {(dt, stop)} −−−−−−−−−→O, dequeue(Q), R, T ∪ {(dt, stop)}

where T does not include the behavior of the dispatching thread.

Rule (A2) is used to define the possible evolution of the system caused by
the event dispatching of the dispatching thread when the first event of the event
queue is a GUI event and there is no listener registered in the current R to
handle it. In this case, the GUI event is simply removed from the event queue
Q and ignored.

Rule A3 (Runnable)

head(Q) = (od, tp) ∧ tp = runnable ∧ met(M, od, runnable) = sm

(dt,runnable)
O, Q, R, T ∪ {(dt, stop)} −−−−−−−−−→O, dequeue(Q), R, T ∪ {(dt, sm)}

where T does not include the behavior of the dispatching thread.

When the first element in the event queue is of type runnable, the dispatching
thread will execute the related code, that is, the run() method of the context
object of the event. This is expressed by Rule (A3). Note that at the ending
state, the dispatching thread is assigned the related code to perform, and thus
no more available to dispatch events until the assigned code is completed.

Rule A4 (Trigger)

O(gd, visible) = true

trigger(gd,tp)
O, Q, R, T  −−−−−−−−−−→O, enqueue(Q, (gd, tp)), R, T 

Rule (A4) expresses our simulation of the GUI input from the end users. An
end user can trigger GUI events at any time as long as the context GUI object
366 Jessica Chen

is currently visible by the end user. Here we use O(od,f ) to denote the value of
field f of object od in the current state.
Rules (A5) and (A6) define the possible evolution of the system caused by
an action to read from the main memory or write into the main memory. The
thread that executes such an action can be either of a program thread or the
dispatching thread that is executing a run() method. Rules (A7) and (A8) show
the possible system moves caused by the registration and deregistration of the
event listeners to the specified event types on the specified GUI objects. For the
lack of space, we do not present these structural rules formally.
Given an initial state, the above eight structural rules allow us to associate
to it a labelled transition system whose states are those reachable from the ini-
tial state, via the transitions inferred by using the structural rules. The labelled
transition system generated from the initial state describes all the possible evo-
lutions, and hence constitutes our model of the system.

4 An Example

In the above given program, there are four objects that we are interested in
(without confusion, we use the object reference names as their identifiers):

– the listener object l.

we are interested only in the object identifier.
– the JFrame object p.
we are interested only in its field visible, which is initially false.
– the JTextField object t.
we are interested only in its field visible which is initially false and its field
enabled which is initially true.
– the implicit thread main which is used to call the main method.
we are interested only in its object identifier.

Thus, we have

– Ld = {l};
– Gd = {p, t};
– T d = {main, dt};
– TP contains all the names of the event types that can be triggered on GUI
object p and t, such as action event (denoted by ae below), focus event, text
event.
– M = {(l, ae, write(t, enabled, f alse); stop)}

At the beginning, s0 = O0 , [ ], ∅, {T0 } where

– O0 ={(l,∅),(p,{(visible,f alse)}),(t,{(visible,f alse),(enabled,true)}),(main,∅)};

– T0 =(main, reg(t, ae, l);write(p,visible,true);write(t,visible,true),
write(t,enabled,true);stop)
 Formal Modelling of Java GUI Event Handling 367

From state s0 , we can apply Rule (A7) to obtain

(main,reg(t,ae,l))
s0 −−−−−−−−−−−−→ s1
where
s1 =O0 , [ ], {(t, ae, l)}, {T1 },
T1 =(main,write(p,visible,true);write(t,visible,true);write(t,enabled,true);stop).
This corresponds to the action performed by thread main to register l as the
listener of the action event on t.
From state s1 , we can apply Rule (A6) twice to obtain
(main,write(p,visible,true)) (main,write(t,visible,true))
s1 −−−−−−−−−−−−−−−−−−−→ s2 −−−−−−−−−−−−−−−−−−−→ s3
where
s3 =O1 , [ ], {(t, ae, l)}, {T2 }
T2 =(main, write(t, enabled, true); stop)
O1 ={(l,∅),(p,{(visible,true)}),(t,{(visible,true),(enabled,true)}),(main,∅)};
This corresponds to the setVisible(true) action performed by thread main.
Once GUI object t is set visible, user interactions may occur at any time. So,
for example, from s3 we can apply Rule (A4) to obtain
trigger(t,ae)
s3 −−−−−−−−−→ s4
where
s4 = O1 , [(t, ae)], {(t, ae, l)}, {T2 }

5 Detecting Errors
The most prominent significance in defining operational semantics on the GUI
event handling mechanism lies in formally reasoning about the correctness of the
GUI-based programs.
As we know, process algebras e.g. CCS [19], CSP [13], ACP [1], have been
well studied for describing concurrent and multi-process systems. For finite state
processes (processes that can be interpreted on finite transition systems), various
practical model checking tools have been developed to verify whether a process
satisfies certain properties (see e.g. [3,7,10,15,18,26]), where the properties ac-
tually characterize the requirements of the system and can be described in a
formula of a modal/temporal logic such as CTL [9], µ-calculus [16,25]. Since
most of these tools are based on transition systems, we can make use of their
techniques, or even reuse existing tools to verify certain properties over the tran-
sition systems we obtained for the GUI event handling.
For example, we know that GUI update is not thread-safe. We need to guaran-
tee that at each moment, there is at most one thread accessing the GUI objects.
This can be expressed as an invariance that in the given transition system, there
is no two consecutive actions (labels in our setting) (t1 , op1 ) and (t2 , op2 ) such
that op1 and op2 both access some GUI objects, i.e. for some t1 , t2 ∈ T d, od1 ,
od2 ∈ Gd, f1 , f2 ∈ F d, v1 , v2 ∈ V ,
368 Jessica Chen

t1 = t2 ,
op1 = write(od1 , f1 , v1 ) or op1 = read(od1 , f1 ),
op2 = write(od2 , f2 , v2 ) or op2 = read(od2 , f2 ).
This statement can be easily formulated in, for example, modal µ-calculus or
action-based CTL [20]. Similarly, we can formulate an invariance to express that
at each moment, there is at most one thread accessing an (not necessarily GUI)
object field.
The violation of these invariance are mainly due to the nondeterministic as-
signment of the threads to execute the event handlers, and the possibility of
hitting the related errors is relatively low. As a consequence, it becomes very
hard, if not impossible, to detect them using ordinary testing techniques. With-
out the help of verification tools, such errors would easily slip into product in
customers hands.

6 Related Work

Formal verification strongly relies on the formal specifications or formal models

of the target systems. Such a formal specification or formal model can be derived
either from the design documents or from the final code.
Formalism of design documents has been an important and active research
direction [11,17,22]. Typically, since Unified Modeling Language (UML) [2] is well
accepted by the software industries as graphical design notations, people have
been studying the translations of UML descriptions into various formalisms. For
example, in [11] it has been discussed the formalism of class diagrams in UML
using Z [24]. In [17], operational semantics is provided to UML State Machine
so that formal verification techniques can further apply.
Considering final code or programming languages, we have mainly two ap-
proaches.

– One is to provide automated translation of a program into a certain formal

specification language so that the related verification technique can apply.
For example, in [23], Shatz et al. described a tool to verify the correctness
of Ada tasking programs using Petri Net. A translator from a concurrent
extension of C++ into Promela [14] is presented in [4], and a translator
from a subset of Java into Promela can be found in [12]. In both of these two
works, the translated programs are then given to SPIN model checker (see
e.g. [15]) as input to verify systems properties given in LTL [21]. In [6], we
discussed a translation of a concurrency-sensitive subset of Java into CCS
in order to verify systems properties given in model µ-calculus.
– Another approach is to provide formal semantics to some popular program-
ming languages. For example, in [5,8], the semantics of subsets of Java are
defined directly with a set of structural rules. Our work actually followed
this line of research. We have discussed the operational semantics of Java
event handling mechanism which has not been addressed in the literature.
 Formal Modelling of Java GUI Event Handling 369

7 Conclusion and Final Remarks

Based on the Java language specification, we proposed a framework on the mod-

eling of Java GUI event handling mechanism in labelled transition systems. The
proposed operational semantics gives a precise definition of the behavior of the
system with respect to the GUI events, and thus helps us to gain a better under-
standing of the system behavior and avoid incorrect programming. It can also
be further developed for formal verification against certain required properties,
such as deadlock/livelock freeness, fairness, eventualities, etc. Usually these kind
of properties are very hard to test with general testing techniques.
As we mentioned, we have considered only the part of the graphical user
interface of Java. To further combine this part of semantics on GUI with other
parts on multithreading, stream socket etc. is possible as long as they all define
the system models in labelled transition systems through structural rules.
We have adopted interleaving semantics in our interpretation. Of course, a
truly concurrent semantics may also be considered. This can be accomplished by
providing some additional structural rules. Our choice on interleaving semantics
is based on the following three observations: (i) it is simple and the generated
model is relatively small; (ii) we can easily check the satisfiability of some system
properties that we are interested in against the given model; (iii) most of the
existing formal verification tools are based on interleaving models.

Acknowledgements

This work is supported in part by the Natural Sciences and Engineering Research
Council of Canada under grant number RGPIN 209774.

References

1. J. Bergstra and J. Klop. Process algebra for synchronous communication. Infor-

mation and Control, 60:109–137, 1984.
2. G. Booch, I. Jacobson, and J. Rumbaugh. The Unified Modeling Language User
Guide. Addison-Wesley, 1998.
3. G. Boudol, R. de Simone, V. Roy, and D. Vergamini. Process calculi, from theory
to practice: Verification tools. In Proc. of Workshop on Automatic Verification
Methods for Finite State Systems, LNCS 407. Springer-Verlag, 1990.
4. T. Cattel. Modeling and verification of sC++ applications. In Proc. of the Tools
and Algorithms for the Construction and Analysis of Systems, LNCS 1384, pages
232–248. Springer-Verlag, 1998.
5. P. Cenciarelli, A. Knapp, B. Reus, and M. Wirsing. An event-based structural
operational semantics of multi-threaded java. In Formal Syntax and Semantics of
Java, LNCS 1523, pages 157–200. Springer-Verlag, 1999.
6. J. Chen. On verifying distributed multithreaded Java programs. Software Quality
Journal, 8:321–341, 1999.
7. R. Cleaveland and S. Sims. The NCSU concurrency workbench. In Computer-Aided
Verification (CAV’96), LNCS 1102, pages 394–397. Springer-Verlag, 1996.
370 Jessica Chen

8. E. Coscia and G. Reggio. A proposal for a semantics of a subset of multi-threaded

“good” Java programs. In Proc. of the OOPSLA’98 Workshop on Formal Under-
pinnings of the Java Paradigm. Vancouver, Canada, October 1998.
9. E. A. Emerson. Temporal and modal logic. In Handbook of Theoretical Computer
Science, volume B, chapter 16. Elsevier Science Publishers B.V., 1990.
10. E. A. Emerson. Automated temporal reasoning about reactive systems. In Logics
for Concurrency: Structure versus Automata, LNCS 1043, pages 41–101. Springer-
Verlag, 1996.
11. R. B. France, J. M. Bruel, M. M. Larrondo-Petrie, and M. Shroff. Exploring the
semantics of UML type structures with Z. In IFIP Proc. of Formal Methods in
Open Object-based Distributed Systems, pages 247–257. Chapman & Hall, 1997.
12. K. Havelund. Java PathFinder. In The 6th International SPIN Workshop, LNCS
1680. Springer-Verlag, 1999.
13. C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall Int., London,
1985.
14. G. Holzmann. The Design and Validation of Computer Protocols. Prentice Hall,
1991.
15. G. Holzmann. The model checker SPIN. IEEE Transactions on Software Engi-
neering, 23(5), May 1997.
16. D. Kozen. Results on the propositional µ-calculus. Theoretical Computer Science,
27(2):333–354, 1983.
17. J. Lilius and I. Paltor. Formalizing UML state machines for model checking. In
UML’99: Lecture Notes in Computer Science 1723. Springer-Verlag, 1999.
18. K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993.
19. R. Milner. Communication and Concurrency. Prentice Hall, London, 1989.
20. R. D. Nicola, A. Fantechi, S. Gnesi, and G. Ristori. An action based framework
for verifying logical and behavioural properties of concurrent systems. Computer
Networks and ISDN Systems, 25(7):761–778, Feb. 1993.
21. A. Pnueli. The temporal logic of programs. In Proc. of 18th IEEE Symp. on
Foundations of Computer Science, pages 46–57. 1977.
22. G. Reggio, M. Cerioli, and E. Astesiano. Towards a rigorous semantics of UML
supporting its multiview approach. In Proceedings of FASE 2001, LNCS 2029.
Springer-Verlag, 2001.
23. S. Shatz, K. Mai, C. Black, and S. Tu. Design and implementation of a Petri
Net based toolkit for Ada tasking analysis. IEEE Transactions on Parallel and
Distributed Systems, 1(4), October 1990.
24. J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall, 1992.
25. C. Stirling. Modal and temporal logics. In Handbook of Logic in Computer Science,
Volume 2, pages 477–563. Oxford University Press, 1992.
26. C. Stirling. Modal and temporal logics for processes. In Logics for Concurrency:
Structure versus Automata, LNCS, 1043, pages 149–237. Springer-Verlag, 1996.