The Journal of Systems and Software 71 (2004) 11–29
www.elsevier.com/locate/jss
Formally analyzing software architectural specifications using SAM
Xudong He *, Huiqun Yu, Tianjun Shi, Junhua Ding, Yi Deng
School of Computer Science, Florida International University, Miami, FL 33199, USA
Received 6 May 2002; received in revised form 11 August 2002; accepted 16 August 2002
Abstract
In the past decade, software architecture has emerged as a major research area in software engineering. Many architecture
description languages have been proposed and some analysis techniques have also been explored. In this paper, we present a
graphical formal software architecture description model called software architecture model (SAM). SAM is a general software
architecture development framework based on two complementary formalisms––Petri nets and temporal logic. Petri nets are used to
visualize the structure and model the behavior of software architectures while temporal logic is used to specify the required
properties of software architectures. These two formal methods are nicely integrated through the SAM software architecture
framework. Furthermore, SAM provides the flexibility to choose different compatible Petri net and temporal logic models according
to the nature of system under study. Most importantly, SAM supports formal analysis of software architecture properties in a
variety of well-established techniques––simulation, reachability analysis, model checking, and interactive proving. In this paper, we
show how to formally analyze SAM software architecture specifications using two well-known techniques––symbolic model
checking with tool Symbolic Model Verifier, and theorem proving with tool STeP.
2002 Elsevier Inc. All rights reserved.
Keywords: Software architecture; Formal specification and verification; Petri nets; Temporal logic; Model checking; Theorem proving
1. Introduction
Software architecture has become one of the most
active research areas in software engineering in recent
years due to the following potential benefits. A well
designed software architecture may provide: better system structure understanding, multiple levels of reuse,
clear dimensions for system evolution, and ease for
system management (Shaw, 2001). On one hand, having
a sound architecture has profound impact on the
maintainability, scalability and extensibility of software’s lifecycle. On the other hand, a rigorous approach
toward architecture level system design can help to detect and eliminate design errors early in the development
cycle, to avoid costly fixes at the implementation stage,
and thus to reduce overall development cost and to increase the quality of the systems. To achieve the above
advantages, a more formal and rigorous way to software
architectural specification, design and analysis is needed.
*
Corresponding author. Tel.: +1-305-348-6036; fax: +1-305-3483549.
E-mail address: hex@cs.fiu.edu (X. He).
0164-1212/$ - see front matter 2002 Elsevier Inc. All rights reserved.
doi:10.1016/S0164-1212(02)00087-0
In the past several years, many formal architectural
description languages (ADLs) and models have been
proposed, including the Chemical Abstract Machine
(Inverardi and Wolf, 1995), Rapide (Luckham et al.,
1995), Unicon (Shaw et al., 1995), MetaH (Binns et al.,
1996), Wright (Allen and Garlan, 1997), and SAM
(Wang et al., 1999).
Despite the flourishing research results on new ADLs,
research on software architecture development and
analysis techniques was sparse and lagging (Shaw,
2001). Among the ten ADLs reviewed in (Medvidovic
and Taylor, 2000), several provided an executable semantics of an architecture description and supported
some analysis capabilities through simulation and/or
formal verification. For example, Rapide (Luckham
et al., 1995) supports simulation, the Chemical Abstract
Machine (Inverardi and Wolf, 1995) and Wright (Allen
and Garlan, 1997) support limited formal verification.
Several researchers also explored software architecturebased testing techniques (Richardson and Wolf, 1996).
A recent workshop (Inverardi and Richardson, 1999)
contained the results on the dynamic analysis techniques
of software architectures. To the best of our knowledge,
12
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
software architecture model (SAM) is only one that
supports both model checking and theorem proving in
addition to simulation. The analysis capabilities offered by SAM are a direct result of SAM’s dual formal methods approach combining a model-oriented
method––Petri nets, and a property-oriented method––
temporal logic.
Furthermore, SAM supports the formal representation and analysis of non-functional properties such as
real-time schedulability and security at the software architecture level. Among the ten popular ADLs surveyed
in (Medvidovic and Taylor, 2000), (1) MetaH (Binns
et al., 1996) supported the description of non-functional
properties such as real-time schedulability, reliability
and security in components but not in connectors; (2)
Unicon (Shaw et al., 1995) supported the definition of
real-time schedulability in both components and connectors; and (3) Rapide (Luckham et al., 1995) supported the modeling of time constraints in architectural
configurations. The analysis of non-functional properties in the above ADLs was not performed at the
architecture specification level instead of during the
simulation and implementation.
In addition to its modeling and analysis capabilities,
SAM also provides a visual representation of software
architectures. Among the ADLs reviewed in (Medvidovic and Taylor, 2000), only Unicon (Shaw et al., 1995)
provided graphical icons for software architecture entities, but without defining their formal semantics.
In this paper, we show how to use SAM to visualize,
model, and analyze software architectures through two
examples. The formal analyses are done using two different techniques and tools–the symbolic model checker
Symbolic Model Verifier (SMV), and the theorem prover STeP. The focus of this paper is on how to formally
analyze SAM architecture specifications. Interested
readers can find how to develop SAM architecture
specifications in (He and Deng, 2002).
2. The software architecture model
SAM is a general formal framework for visualizing,
specifying, and analyzing software architectures (He and
Deng, 2002; Wang et al., 1999), and has been developed
in the past four years at the Florida International
University. The development philosophy of SAM is to
introduce a simple, flexible, and formal software architecture specification and analysis model without the
need to invent another ADL. During the development
of SAM, we have aimed to achieve the following desirable features.
First, SAM must support precise specification and
formal analysis. Thus SAM needs to use some formal
method as its underlying foundation. The foundation of
the most existing software ADLs and/or models rests on
a single formal method. For example, Z (Spivey, 1992)
was used to specify software architecture (Abowd et al.,
1995), CSP (Hoare, 1985) was used as the foundation of
Wright (Allen and Garlan, 1997), and CHAM, an operational formalism, was proposed in (Inverardi and
Wolf, 1995) to specify software architectures. We have
decided in establishing SAM’s foundation using a dual
formalism combining a Petri net model and a temporal
logic. Petri nets are used to define the behavior models of
components and connectors while temporal logic is used
to specify properties of components and connectors. The
correctness of a software architecture specification is
assured when all the system properties hold in the behavior models. We believe that the use of dual complimentary formal methods has many advantages over a
single formalism, including defining and analyzing different system aspects using different formalism to improve understandability and reduce complexity through
divide-and-conquer strategy. Our belief is supported by
the active research on integrating formal methods in recent years (Clarke and Wing, 1996). The main problems
of formal method integration are a suitable integration
style and a uniform theoretical foundation (Clarke and
Wing, 1996). Based on our earlier results in integrating
Petri nets and temporal logic (He and Lee, 1990), we
have solved the above problems satisfactorily in SAM.
Second, SAM specifications must be scalable. To
achieve this feature, we resort to the abstraction and
divide-and-conquer principles. SAM supports hierarchical and horizontal decompositions. An SAM specification consists of multiple layers (called compositions),
and each layer contains multiple components and connectors. Components and connectors communicate with
their external environments only through ports. This
hierarchical decomposition structure is nicely supported
by the underlying formal methods as well. The structure
and the behavioral model of a composition can be derived by combining the behavior models of its constituent components and the connectors through their
common ports. The composition-wide properties can be
specified in temporal logic just as those component and
connector properties.
Third, SAM must be expressive and flexible. To
achieve this feature, we do not fix a particular Petri net
model and a temporal logic as SAM’s underlying formal
foundation. We leave this choice open as long as the
chosen pair of Petri net model and temporal logic is
compatible within our integration. For example, realtime Petri net and real-time computational tree logic
were used to study software architectures of real-time
systems (Wang et al., 1999), predicate transition nets
and first order linear-time temporal logic were used to
specify and verify software architectures explicitly
dealing with data abstraction (He and Deng, 2000,
2002). This flexibility allows us to find the best match
between a particular application and a dual formalism.
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
Fourth, SAM needs to be understandable and usable.
To realize these features, we introduced hierarchical
decomposition. The visual structure and the simple
control flow mechanism of Petri nets are certainly very
helpful. Furthermore, we restrict that the propositional/
predicate symbols used in temporal logic specifications
be only the ports defined in Petri net models. This restriction significantly simplifies the resulting temporal
logic specifications such that they are easy to write and
understand. Furthermore, we use as much software tool
support as possible in both developing and analyzing
SAM specifications.
2.1. Visualizing the structures of software architectures
In SAM, a software architecture is visualized by a
hierarchical set of boxes with ports connected by directed arcs. These boxes are called compositions. Each
composition may contain other compositions. The bottom-level compositions are either components or connectors. Various constraints can be specified. This
hierarchical model supports compositionality in both
software architecture design and analysis, and thus facilitate scalability. Fig. 1 shows a graphical view of an
SAM software architecture, in which connectors are not
emphasized and are only represented by thick arrows.
Each component or connector is defined using a Petri
net. Thus the internal logical structure of a component
or connector is also visualized through the Petri net
structure.
Textually, an SAM software architecture is defined
by a set of compositions C ¼ fC1 ; C2 ; . . . ; Ck g (each
composition corresponds to a design level or the concept
of sub-architecture) and a hierarchical mapping h re-
13
lating compositions. Each composition Ci ¼ fCmi ;
Cni ; Csi g consists of a set Cmi of components, a set Cni
of connectors, and a set Csi of composition constraints.
An element Cij ¼ ðSij ; Bij Þ, (either a component or a
connector) in a composition Ci has a property specification Sij (a temporal logic formula) and a behavior
model Bij (a Petri net). Each composition constraint in
Csi is also defined by a temporal logic formula. The
interface of a behavior model Bij consists of a set of
places (called ports) that is the intersection among relevant components and connectors. Each property
specification Sij only uses the ports as its atomic propositions/predicates that are true in a given marking if
they contain appropriate tokens. A composition constraint is defined as a property specification, however it
often contains ports belonging to multiple components
and/or connectors. A component Cij can be refined into
a lower-level composition Cl , which is defined by
hðCij Þ ¼ Cl .
2.2. Modeling the behaviors of software architectures
In SAM, the behavior of a component or a connector
is explicitly defined using a Petri net. The behavior of an
overall software architecture is implicitly derived by
composing all the bottom-level behavior models of
components and connectors. SAM provides both the
modeling power and flexibility through the choice of
different Petri net models. We have used several Petri net
models including time Petri nets (Wang et al., 1999),
condition event nets, and predicate transition nets (He
and Deng, 2000, 2002) in our previous work. The selection of a particular Petri net model is based on the
application under consideration. A simple Petri net
Fig. 1. An SAM software architecture.
14
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
model such as condition event nets is adequate when we
only need to deal with simple control flows and dataindependent constraints; while a more powerful Petri net
model such as predicate transition nets is needed to
handle both control and data. To study performance
related constraints, a more specialized Petri net model
such as stochastic Petri nets is more appropriate and
convenient. In this paper, we use predicate transition
nets (PrT nets), by Genrich and Lautenbach (1981) to
model behaviors.
In the following sections, we give a brief definition of
PrT nets using the conventions in (He, 1996).
2.2.1. The syntax and static semantics of PrT nets
A PrT net is a tuple (N, Spec, ins) where
(1) N ¼ ðP ; T ; F Þ is the net structure, in which
(i) P and T are non-empty finite sets satisfying
P \ T ¼ £ (P and T are the sets of places and transitions of N, respectively),
(ii) F ðP T Þ [ ðT P Þ is a flow relation (the arcs
of N);
(2) Spec ¼ ðS; OP ; EqÞ is the underlying specification,
and consists of a signature S ¼ ðS; OP Þ and a set
Eq of S-equations. Signature S ¼ ðS; OP Þ includes
a set of sorts S and a family OP ¼ ðOPs1 ;...;sn ;s Þ of
sorted operations for s1 ; . . . ; sn , s 2 S. For each
s 2 S, we use CONs to denote OP;s (the 0-ary operation of sort s), i.e. the set of constant symbols of sort
s. The S-equations in Eq define the meanings and
properties of operations in OP. We often simply
use familiar operations and their properties without
explicitly listing the relevant equations. Spec is a
meta-language to define the tokens, labels, and constraints of a PrT net. Tokens of a PrT net are ground
terms of the signature S, written MCONS . The set of
labels is denoted using LabelS ðX Þ (X is the set of
sorted variables disjoint with OP). Each label can
be a multiple set expression of the form fk1 x1 ; . . . ;
kn xn g. Constraints of a PrT net are a subset of first
order logic formulas (where the domains of quantifiers are finite and any free variable in a constraint
appears in the label of some connecting arc of the
transition), and thus are essentially propositional
logic formulas. The subset of first order logical formulas contains the S-terms of sort bool over X, denoted as TermOP ;bool ðX Þ.
(3) ins ¼ ðu; L; R; M0 Þ is a net inscription that associates a net element in N with its denotation in
Spec:
(i) u : P ! }ðSÞ is the data definition of N and
associates each place p in P with a subset of sorts
in S.
(ii) L : F ! LabelS ðX Þ is a sort-respecting labeling of
PrT net. We use the following abbreviation in the
following definitions:
Lðx; yÞ ¼
Lðx; yÞ
£
iff ðx; yÞ 2 F
otherwise
(iii) R : T ! TermOP ;bool ðX Þ is a well-defined constraining mapping, which associates each transition t in T with a first order logic formula
defined in the underlying algebraic specification.
Furthermore, the constraint of a transition defines
the meaning of the transition.
(iv) M0 : P ! MCONS is a sort-respecting initial
marking. The initial marking assigns a multi-set
of tokens to each place p in P.
2.2.2. Dynamic semantics of PrT nets
(1) Markings of a PrT net N are mappings M : P !
MCONS ;
(2) An occurrence mode of N is a substitution
a ¼ fx1
c1 ; . . . ; xn
cn g,
which
instantiates
typed label variables. We use e: a to denote the result
of instantiating an expression e with a, in which e
can be either a label expression or a constraint;
(3) Given a marking M, a transition t 2 T , and an occurrence mode a, t is a_enabled at M iff the follow tÞ : aÞ ing predicate is true: 8p : p 2 P . (Lðp;
MðpÞÞ ^ RðtÞ : a;
(4) If tis a_enabled at M, t may fire in occurrence mode
a. The firing of t with a returns the marking M 0 de tÞ : a [ Lðt;
pÞ : a for
fined by M 0 ðpÞ ¼ MðpÞ Lðp;
p 2 P . We use M½t=aiM 0 to denote the firing of t with
occurrence a under marking M. As in traditional Petri nets, two enabled transitions may fire at the same
time as long as they are not in conflict;
(5) For a marking M, the set ½Mi of markings reachable
from M is the smallest set of markings such that
M 2 ½Mi and if M 0 2 ½Mi and M 0 ½t=aiM 00 then
M 00 2 ½Mi, for some t 2 T and occurrence mode a
(note: concurrent transition firings do not produce
additional new reachable markings);
(6) An execution sequence (or a run) M0 T0 M1 T1 . . . of N
is either finite when the last marking is terminal (no
more enabled transition in the last marking) or infinite, in which each Ti is an execution step consisting
of a set of non-conflict firing transitions;
(7) The behavior of N (denoted by compðN Þ) is the set of
all execution sequences starting from the initial
marking.
The dining philosophers problem is a classic multiprocess synchronization problem introduced by Dijkstra. The problem consists of k philosophers sitting at a
round table who do nothing but think and eat. Between
each philosopher, there is a single chopstick. In order to
eat, a philosopher must have both chopsticks. A problem can arise if each philosopher grabs the chopstick on
the right, then waits for the chopstick on the left. In this
case a deadlock has occurred. The challenge in the
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
15
dining philosophers problem is to design a protocol so
that the philosophers do not deadlock (i.e. the entire set
of philosophers does not stop and wait indefinitely), and
so that no philosopher starves (i.e. every philosopher
eventually gets his/her hands on a pair of chopsticks).
The following is an example of the PrT net model of the
dining philosophers problem.
There are three places (Thinking, Chopstick and
Eating) and two transitions (Pickup and Putdown) in the
PrT net. In the underlying specification Spec ¼ ðS;
OP ; EqÞ, S includes elementary sorts such as Integer and
Boolean, and also sorts PHIL and CHOP derived from
Integer. S also includes structured sorts such as set and
tuple obtained from the Cartesian product of the elementary sorts; OP includes standard arithmetic and relational operations on Integer, logical connectives on
Boolean, set operations, and selection operation on tuples; and Eq includes known properties of the above
operators.
The net inscription (u, L, R, M0 ) is as follows:
losophers picking up chopsticks simultaneously, and
some philosophers picking up chopsticks while others
putting down chopsticks. The constraints associated
with transitions Pickup and Putdown also ensure that a
philosopher can only use two designated chopsticks
defined by the implicit adjacent relationships. Table 1
gives the details of a possible run of five dining philosophers PrT net.
• Sorts of predicates:
uðThinkingÞ ¼ }ðPHILÞ;
uðEatingÞ ¼ }ðPHIL CHOP CHOPÞ,
uðChopstickÞ ¼ }ðCHOPÞ,
where } denotes power set.
• Arc definitions:
Lðf 1Þ ¼ fphg; Lðf 2Þ ¼ fch1; ch2g;
Lðf 3Þ ¼ fhph; ch1; ch2ig,
Lðf 4Þ ¼ fhph; ch1; ch2ig;
Lðf 5Þ ¼ fphg; Lðf 6Þ ¼ fch1; ch2g.
• Constraints of transitions:
RðPickupÞ ¼ ðph ¼ ch1Þ ^ ðch2 ¼ ph 1Þ;
RðPutdownÞ ¼ true.
• The initial marking m0 is defined as follows:
M0 ðThinkingÞ ¼ f1; 2; . . . ; kg; M0 ðEatingÞ ¼ f g;
M0 ðChopstickÞ ¼ f1; 2; . . . ; kg.
2.3.1. Values, state variables, and states
The set of values is the multi-set of tokens MCONS
defined by the Spec of a given PrT net N. Multi-sets can
be viewed as partial functions. For example, multi-set
f3a; 2bg can be represented as fa7!3; b7!2g.
The set of state variables is the set Pof places of N,
which change their meanings during the executions of N.
The arity of a place p is determined by its sort uðpÞ in
the net inscription.
The set of states St is the set of all reachable markings
½M0 i of N. A marking is a mapping from the set of state
variables into the set of values. We use M½jxj to denote
the value of x under state (marking) M.
Since state variables take partial functions as values,
they are flexible function symbols. We can access a
particular component value of a state variable. However
there is a problem associated with partial functions, i.e.
many values are undefined. The above problem can
easily be solved by extending state variables into total
The above specification allows concurrent executions
such as multiple non-conflicting (non-neighboring) phi-
2.3. Specifying SAM architecture properties
In SAM, software architecture properties are specified using a temporal logic. Depending on the given Petri
net models, different temporal logics are used. In this
section, we provide the essential concepts of a generic
first order linear-time temporal logic to specify the
properties of components and connectors. We follow the
approach in (Lamport, 1994) to define vocabulary and
models of our temporal logic in terms of PrT nets
without giving a specific temporal logic.
Table 1
A possible run of five dining philosophers problem
Markings mi
Transitions ni
Thinking
Eating
Chopstick
Fired Transition
Token(s) consumed
{1,2,3,4,5}
{2,3,4,5}
{1,2,3,4,5}
{1,3,4,5}
{1, 3, 5}
{1, 2, 3, 5}
{1,2,3,4,5}
{1,2,3,4}
{1,2,4}
{1,2,3,4}
{1,2,3,4,5}
{}
fh1; 1; 2ig
{}
fh2; 2; 3ig
fh2; 2; 3i; h4; 4; 5ig
fh4; 4; 5ig
{}
fh5; 5; 1ig
fh5; 5; 1i; h3; 3; 4ig
fh5; 5; 1ig
{}
{1,2,3,4,5}
{3,4,5}
{1,2,3,4,5}
{1,4,5}
{1}
{1,2,3}
{1,2,3,4,5}
{2,3,4}
{2}
{2,3,4}
{1,2,3,4,5}
Pickup
Putdown
Pickup
Pickup
Putdown
Putdown
Pickup
Pickup
Putdown
Putdown
–
ph ¼ 1, ch1 ¼ 1, ch2 ¼ 2
hph; ch1; ch2i ¼ h1; 1; 2i
ph ¼ 2, ch1 ¼ 2, ch2 ¼ 3
ph ¼ 4, ch1 ¼ 4, ch2 ¼ 5
hph; ch1; ch2i ¼ h2; 2; 3i
hph; ch1; ch2i ¼ h4; 4; 5i
ph ¼ 5, ch1 ¼ 5, ch2 ¼ 1
ph ¼ 3, ch1 ¼ 3, ch2 ¼ 4
hph; ch1; ch2i ¼ h3; 3; 4i
hph; ch1; ch2i ¼ h5; 5; 1i
–
16
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
functions in the following way: for any n-ary state
variable p , any tuple c 2 MCONSn and any state M, if
pðcÞ is undefined under M, then let M½jpðcÞj ¼ 0. The
above extension is consistent with the semantics of PrT
nets. Furthermore we can consider the meaning ½jpðcÞj
of the function application pðcÞ as a mapping from
states to Nat using a postfix notation for function application M½jpðcÞj.
2.3.2. Rigid variables, rigid function and predicate symbols
Rigid variables are individual variables that do not
change their meanings during the executions of N. All
rigid variables occurring in our temporal logic formulas
are bound (quantified), and they are the only variables
that can be quantified. Rigid variables are variables
appearing in the label expressions and constraints of N.
Rigid function and predicate symbols do not change
their meanings during the executions of N. The set of
rigid function and predicate symbols is defined in the
Spec of N.
2.3.3. State functions, predicates, and transitions
A state function is an expression built from values,
state variables, rigid function and predicate symbols.
For example ½jpðcÞ þ 1j is a state function where c and 1
are values, p is a state variable, + is a rigid function
symbol. Since the meanings of rigid symbols are not
affected by any state, thus for any given state M,
M½jpðcÞ þ 1j ¼ M½jpðcÞj þ 1.
A predicate is a boolean-valued state function. A
predicate p is said to be satisfied by a state M iff M½jpj is
true.
A transition is a particular kind of predicates that
contain primed state variables, e.g. ½jp0 ðcÞ ¼ pðcÞ þ 1j.
A transition relates two states (an old state and a new
state), where the unprimed state variables refer to the
old state and the primed state variables refer to the new
state. Therefore the meaning of a transition is a relation
between states. The term transition used here is a temporal logic entity. Although it reflects the nature of a
transition in a PrT net N, it is not a transition in N. For
example, given a pair of states M and M 0 : M½jp0 ðcÞ ¼
pðcÞ þ 1jM 0 is defined by M 0 ½jp0 ðcÞj ¼ M½jpðcÞj þ 1.
Given a transition t, a pair of states M and M 0 is called
a ‘‘transition step’’ iff M½jtjM 0 equals true. We can
easily generalize any predicate p without primed state
variables into a relation between states by replacing all
unprimed state variables with their primed versions
such that M½jp0 jM 0 equals M 0 ½jpj for any states M and
M 0.
and () ), universal quantifier 8 and derived existential
quantifier 9, and temporal operators always , sometimes , and until U.
The semantics of temporal logic is defined on behaviors (infinite sequences of states). The behaviors are
obtained from the execution sequences of PrT nets
where the last marking of a finite execution sequence is
repeated infinitely many times at the end of the execution sequence. For example, for an execution sequence
M0 ; . . . ; Mn , the following behavior r ¼ hhM0 ; . . . ;
Mn ; Mn ; . . .ii is obtained. We denote the set of all possible behaviors obtained from a given PrT net as St1 .
Let u and v be two arbitrary temporal formulas, p be
an n-ary predicate, t be a transition, x; x1 ; . . . ; xn be rigid
variables, r ¼ hhM0 ; M1 ; . . .ii be a behavior, and
rk ¼ hhMk ; Mkþ1 ; . . .ii be a k step shifted behavior sequence; we define the semantics of temporal formulas
recursively as follows:
(1)
(2)
(3)
(4)
(5)
(6)
(7)
r½jpðx1 ; . . . ; xn Þj M0 ½jpðx1 ; . . . ; xn Þj
r½jtj M0 ½jtjM1
r½j:uj :r½juj
r½ju ^ vj r½juj ^ r½jvj
r½j8xuj 8xr½juj
r½juj 8n 2 Natrn ½juj
r½juUvj 9krk ½jvj ^ 80 6 n < krn ½juj
A temporal formula u is said to be satisfiable, denoted
as rj ¼ u, iff there is an execution r such that r½juj is
true, i.e. rj ¼ u () 9r 2 St1 . r½juj. u is validwith regard to N, denoted as N j ¼ u, iff it is satisfied by all
possible behaviors St1 from N : N j ¼ u () 8r 2
St1 r½juj.
2.3.5. Defining system properties in temporal logic
Specifying architecture properties in SAM becomes
defining PrT net properties using temporal logic. Canonical forms for a variety of system properties such as
safety, guarantee, obligation, response, persistence, and
reactivity are given in (Manna and Pnueli, 1992). For
example, the following temporal logic formulas specify a
safety property and a liveness property of the PrT net in
Fig. 2, respectively:
• Mutual exclusion: 8ph 2 f1; . . . ; kg: ðhph; ; i 2
Eating ^ hph 1; ; i 2 EatingÞ which defines that no
adjacent philosophers can eat at the same time.
• Starvation freedom: 8ph 2 f1;...;kg}ðhph; ; i 2 EatingÞ
which states that every philosopher will eventually get
a chance to eat.
2.4. Analyzing SAM architecture specifications
2.3.4. Temporal formulas
Temporal formulas are built from elementary formulas (predicates and transitions) using logical connectives : and ^ (and derived logical connectives _, ),
An SAM architectural specification is well-defined if
the ports of a component are preserved (contained) in
the set of exterior ports of its refinement and the prop-
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
17
3.1. Modeling the alternating bit protocol
Fig. 2. A PrT net model of the dining philosophers problem.
osition symbols used in a property specification are
ports of the relevant behavior model(s).
The correctness of an SAM architectural specification
is defined by the following criteria:
(1) Element (Component/Connector) Correctness––the
property specification Sij holds in the corresponding
behavior model Bij , i.e. Bij j ¼ Sij . Note we use Bij
here to denote the set of behaviors or execution sequences defined by Bij ;
(2) Composition Correctness––the conjunction of all
constraints in Csi of Ci is implied by the conjunction
of all the property specifications Sij of Cij , i.e.
^Sij j ^Csi . An alternative weaker but acceptable
criterion is that the conjunction of all constraints
in Csi holds in the integrated behavior model Bi of
composition Ci ; i.e. Bi j ¼ ^Csi ;
(3) Refinement Correctness––the property specification
Sij of a component Cij must be implied by the composition constraints Csl of its refinement Cl with
Cl ¼ hðCij Þ, i.e. ^Csl j Sij . An alternative weaker
but acceptable criterion is that Sij holds in the integrated lower-level behavior model Bl of Cl , i.e.
Bl j ¼ Sij .
The refinement correctness is equivalent to the composition correctness when the property specification Sij
is inherited without change as the composition constraint Csl of its refinement Cl ¼ hðCij Þ. The above
correctness criteria are the verification requirements of
an SAM architectural specification.
3.1.1. The alternating bit protocol
The ABP is a simple yet effective protocol for reliable
transmission over lossy channels that may lose or corrupt, but not duplicate, messages. The protocol consists
of a sender, a receiver, and two channels, and the main
goal of ABP is to ensure that the receiver will eventually
deliver an accepted message from the sender. There are
several variant ABPs, among which the main differences
focus on whether the channel can detect the lost or
corrupted messages or not. If yes, a message (ACK) is
resent when a lost or corrupted ACK (message) is detected. Otherwise, a timeout mechanism is introduced to
send message (ACK) periodically when no desired ACK
(message) is received during a certain time.
The protocol guarantees that (1) an accepted message
will eventually be delivered, (2) an accepted message is
delivered only once, and (3) the accepted messages are
delivered in order.
We provide a specification of ABP without a timeout
mechanism, which assumes that the channels may lose
or corrupt, but not duplicate messages, and the lost or
corrupted messages are detectable.
3.1.2. Specifying ABP
It is straightforward to construct the architecture of
this ABP from its requirements. As shown in Fig. 3,
there are two components, Sender and Receiver, and two
connectors, DataChannel and AckChannel. ABP has two
interface ports. One is the Accept port, which is the interface accepting messages from the environment; the
other is the Deliver port, which is the interface delivering
the accepted messages out to the environment. All other
ports are internal to the ABP system.
The architecture property specifications are derived
directly from the requirements of the protocol. In fact,
they are formal expressions of the protocol requirements
in temporal logic. The property specifications include:
(P1) Liveness property: Accepted message will be eventually delivered
ðAcceptðxÞ ! }DeliverðxÞÞ
(P2) Safety property: Messages will be delivered in
order, e.g. if message x1 is sent by the sender before message x2, x1 will be delivered by the receiver
before x2.
3. Analyzing SAM specifications using symbolic model
checking
In this section, we show how to analyze SAM architecture specifications using symbolic model checker
SMV (McMillan, 1993) through the well-known alternating bit protocol (ABP).
Fig. 3. Software architecture of the ABP.
18
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
ððAcceptðx1ÞU ðAcceptðx2Þ ^ :Acceptðx1ÞÞ !
ð:Deliverðx2ÞUDeliverðx1ÞÞÞ
(P3) Safety property: Each messages is delivered only
once with the assumption that all accepted messages are distinct.
ðDeliverðxÞ ^ DeliverðyÞ ! x ¼ yÞ
Following the process of ABP and its requirements,
we can develop the property specification and corresponding behavior model of each element in the architecture, as shown in Figs. 4–6, respectively.
The net inscription of Sender model is as follows:
uðAcceptÞ ¼ } (MESSAGE), where MESSAGE is
the type of string.
uðAckInÞ ¼ BIT [ flost; corruptedg,
where BIT ¼ f0; 1g.
uðDataOutÞ ¼ uðDataBuf Þ ¼ BIT MESSAGE
Fig. 4. Behavior model of the sender.
RðsendDataÞ ¼ ðack 2 BIT ^ ack ¼
d½1 ^ d 0 ½1 ¼ 1 ack ^ d0 ½2 ¼ mÞ
RðresendDataÞ ¼ ðack ¼ lost ^ ack ¼ corruptedÞ
The initial marking of Accept is dependent on the
environment, and the other initial markings of the other
three predicates are as follows:
M0 ðAckInÞ ¼ f1g;
M0 ðDataBuf Þ ¼ fh1; \ "ig; M0 ðDataOutÞ ¼ f g
And the corresponding property specification is:
ðAckInðxÞ ^ ðx ¼ lost _ x ¼ corruptedÞ^
DataBuf ðyÞ ! }DataOutðyÞÞ
ðAckInðxÞ ^ AcceptðmÞ^
DataBuf ðyÞ ^ x ¼ y½1 ! }DataOutðh1 x; miÞÞ
The net inscription of Receiver model is as follows:
uðDeliverÞ ¼ }ðMESSAGEÞ
uðAckOutÞ ¼ uðAckBuf Þ ¼ BIT
uðDataInÞ ¼ ðBIT MESSAGEÞ [ flost; corruptedg
RðdeliverDataÞ ¼ ðd 2 BIT MESSAGE ^ d½1 ¼
1 b ^ b0 ¼ d½1 ^ m ¼ d½2Þ
RðresendAckÞ ¼ ðd ¼ lost _ d ¼ corruptedÞ
M0 ðAckBuf Þ ¼ f1g; M0 ðDataInÞ ¼ M0 ðAckOutÞ ¼
M0 ðDeliverÞ ¼ f g
The corresponding property specification is:
ðDataInðxÞ ^ ðx ¼ lost _ x ¼ corruptedÞ^
AckBuf ðyÞ ! }AckOutðyÞÞ
ðDataInðxÞ ^ AckBuf ðyÞ ^ x½1 ¼
1 y ! }AckOutðx½1ÞÞ
The behavior models for DataChannel and AckChannel have the same net structure, and can be deemed
as two instances of the same net structure. For simplicity, we only describe the model for the DataChannel
connector.
The net inscription of the DataChannel model is as
follows:
RðlostÞ ¼ ðm0 ¼ lostÞ
RðcorruptÞ ¼ ðm0 ¼ corruptedÞ
RðtransmittedÞ ¼ true
Fig. 5. Behavior model of the receiver.
The corresponding property specification is:
ðSenderDataOutðxÞ ! }SenderAckOutðyÞ^
ðy ¼ x _ y ¼ lost _ y ¼ corruptedÞ
3.2. Analyzing SAM specification of the ABP using
symbolic model checking
Fig. 6. Behavior model of the channel.
Symbolic model checking is an effective automatic
technique for analyzing temporal properties of finite
state systems and has been widely accepted in the past
decade (Clarke et al., 1999). We have applied model
checking technique to analyze the SAM architecture
specifications of several systems. In this section, we show
how to apply the model checking technique to analyze
the ABP specification.
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
3.2.1. The SMV system
SMV is a software tool for symbolically checking finite state systems against specifications in temporal logic
Computation Tree Logic (CTL) by Clarke et al. (1986).
It uses the Ordered Binary Decision Diagram (OBDD),
an efficient canonical form for representing Boolean
formulas by Bryant (1986)) based symbolic model
checking algorithm (McMillan, 1993). The system
structure of SMV is illustrated in Fig. 7.
To verify a finite state system in SMV, it has to be
described in SMV input language. SMV then translates
this description into a system (also called Kripke
structure) model and uses the OBDD-based symbolic
model checking algorithm to check if a given specification in CTL is true or false. In the latter case, a counterexample is given when possible.
3.2.2. Translating an SAM specification into an SMV
program
An SMV program consists of a definition of a finite
state transition system and a list of properties written in
CTL formulas. A transition system is defined in terms of
a state space, a transition relation, and a set of initial
states. Since it is intended to describe finite state systems,
the only data types in the language are finite ones––
Booleans, scalars and fixed arrays. The complete syntax
of the SMV language is described in the SMV documentation (McMillan, 1993).
The above SAM architecture specification of ABP
consists of behavioral models defined by PrT nets, and
properties specified in first order linear-time temporal
formulas. Therefore, to translate a SAM specification
into an SMV program, we need to translate behavior
models in PrT nets into the finite transition systems in
SMV, and properties in first order linear-time temporal
logic to CTL.
We provide the following general procedure and rules
for translating an architecture specification in SAM into
the SMV language:
19
Step 1: Connecting the behavior models of individual
components and connectors into a single composition
level behavior model.
It is straightforward to get the composition level behavior model from the individual behavior models and
the architecture by merging common ports.
Step 2: Defining state variables
Declare a state SMV variable for each place in the
composition behavior model. The values of the state
variable represent the possible markings of the place.
Therefore, the number of possible values of a state
variable should be the number of possible markings of
the corresponding place. If a place p is k-bounded and
juðpÞj is the number of all possible values of a token in p,
then
number of possible markings of place p is
PjuðpÞthe
j i
k
.
Therefore, the declare statement for place
i¼0
phas the form:
p : 0::
jX
uðpÞj
ki 1
i¼0
Thus we treat a predicate symbol as a set of propositional symbols. This can be done when each p is bounded and juðpÞj is finite. However, in many cases, some
specific properties still hold after reducing a behavior
model with infinite states to one with finite states.
Therefore, to verify a specific property, we can reduce
some infinite places to finite places as long as the reduction does not affect the verification of this property.
For example, the type of place Accept in Fig. 4 is infinite, and the message can be any string. When we want
to verify that an accepted message will be eventually
delivered, we do not care about the content of a message. In this case, we can reduce the type of Accept to a
finite type, even a type containing only one value.
Step 3: Defining initial state
Initialize each SMV state variable to the value, which
is corresponding to the initial marking of the place in the
behavior model, using the INIT statement:
INIT ¼ ^ ðp ¼ f ðM0 ðpÞÞÞ
p2P
where f is the mapping from the initial marking of place
p to the value of state variable p.
Step 4: Defining transition relations
First, for each transition in the behavior model, define the transition name as its enabling conditions in
DEFINE statement. For a transition t, its corresponding define statement is t :¼ ^ ðpi > 0Þ ^ RðtÞ.
pi 2t
Second, define transition relations using TRANS
statement. Similar to the method proposed by Wimmel
(1997), the TRANS statement consists of one sub-formula TRANSt for each transition t:
TRANSt ¼ t ^ ð
Fig. 7. The SMV system structure.
^
nextðpÞ
p2ðt[tÞ
¼ f ðMðpÞÞÞ ^ ð
^
nextðpÞ ¼ pÞ
p2P ðt[tÞ
20
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
where f is the mapping from the marking of predicate p
to the value of state variable p, after t fires; and next is
an operator of SMV to denote the value of a state
variable in the next state. Sub-formula TRANSt reflects
the firing of transition t, and guarantees that the transition relations in the finite system are equivalent to the
transitions in PrT net.
In addition, to make it possible to verify a behavior
model containing deadlocks, which means there is no
enabled transition, a sub-formula has to be added to the
transition relation that allows the system to stay in its
current state if there is a deadlock (Wimmel, 1997). The
symbol deadlock is defined as:
deadlock :¼ : _ t
t2T
Thus, the TRANS statement is finally defined as follows:
TRANS ¼ _ TRANSt _ ðdeadlock ^ ^ nextðpÞ ¼ pÞ
t2T
p2P
Step 5: Defining the specifications to be verified
What we need to do here is to translate the properties
to be verified in SAM to the SPEC part in SMV. The
former is a first order linear-time temporal logic formula
and the latter is a CTL formula. CTL is a propositional
branching-time temporal logic. There are two main
problems in translating a first order linear-time temporal
logic formula into one in CTL. The first problem is how
to translate predicates. In general, it is not possible to
translate predicates into a set of propositions, since the
domain of a quantifier might be infinite. As we discussed
in Step 2, however, we can replace a predicate with a set
of propositions when we are dealing with finite state
systems or when we do not need to use data content to
verify a property. In this case, a first order linear-time
temporal logic formula is essentially a propositional
linear temporal logic (known as LTL) formula. Now,
the second problem is how to map linear-time computation models to branching-time computation models.
The different time perspectives of LTL and CTL result
in the incomparable expressive power. Some LTL formulas (e.g. }p) are not expressible in CTL, and some
CTL formulas (e.g. AFAGp) are not expressible in LTL.
An LTL formula can be expressed by a CTL formula if
and only if the LTL formula lies in the common fragment of LTL and CTL. The work of Maidl (2000)
showed that an LTL formula is expressible in CTL if the
negation of the LTL formula can be represented using a
1-weak Buchi automaton. Fortunately, it is well-known
that the majority of system properties such as safety and
liveness properties can be verified in either computation
model, i.e. choosing any one of them does not affect the
satisfiability or validity of a property. Thus we only need
to add a universal path quantifier in front of an LTL
formula to make it a CTL formula.
Step 6: Defining fairness constraints
It is not possible to explicitly define fairness constraints in PrT nets, however it is often implicitly assumed that the firings of transitions are fair. Thus we
need to add fairness constraints using the FAIRNESS
statement in SMV.
Step 7: Dealing with timing constraint when necessary
When timing constraint is defined in the behavior
model in SAM, additional code should be added to the
SMV program. Generally, time grows without bound in
behavior model, so the underlying state transition system has infinite states and SMV becomes inapplicable.
In most cases, however, we do not care about absolute
time but relative time. What we need to do is to keep
track of time lapses with a state variable whose range is
bounded.
The validity of the above translation rests on steps 2–
4 while other steps are quite easy to understand. It is
well-known that a finite state transition system is a
special case of a Petri net, in which no concurrency is
allowed (Murata, 1989). It is also well-known that a
state-based verification approach is adequate to ensure
general safety and liveness properties (Lamport, 1994).
Therefore, restricting a Petri net’s behavior into interleaved executions (i.e. firing one transition at each step)
by translating a Petri net into a state transition system
does not affect the satisfiability/validity of a property
specification. Now the question is how to translate a
Petri net into a finite state transition system written in
SMV. A finite state transition system consists of (1) a
finite set of state variables, (2) an initial state, and (3) a
finite set of state transitions. Let us examine how the
above three elements are correctly obtained from the
translation. In Section 4, a more formal treatment is
presented where the target language (fair transition
systems) is more appropriate. A finite state transition
system in SMV consists of a finite set of variables defining the state space. In a PrT net, a marking (state) is
collectively defined by the current contents in all the
places. Thus each place corresponds to a state variable.
This treatment of places in PrT nets ensures that no
instantiation is needed during the rest of the translation.
To ensure the system containing only finite many states,
we require the boundedness of all places. It is straightforward to obtain the initial state of an SMV program
from the initial marking of a PrT net. Each state transition in SMV is obtained from a transition occurrence
in a PrT net. A transition occurrence t in a PrT net
consists of an enabling condition (pre-condition) and
firing result (post-condition), which are correctly defined
by sub-formulas t and TRANSt .
3.2.3. Analyzing the SAM specification of ABP using
SMV
Following the general steps and rules described in the
previous section, it is quite easy to translate the archi-
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
tecture specification to SMV program. The complete
SMV program for ABP without timer is shown in Appendix A.
Our goal is to verify that the compositional architecture specification satisfies the three properties, (P1),
(P2) and (P3) described in Section 3.1.2. To make the
underlying transition system finite and to simplify the
analysis, we assume that there are eight distinct messages accepted initially. Namely, there are eight distinct
tokens in place Accept. The ids for the messages range
from 1 to 8. The messages sent by the Sender are in the
order from 8 to 1. No any other message is accepted. We
verify that all eight messages and only eight messages
are delivered, and eight messages are delivered in the
order they are sent by the Sender.
With the above assumption, we translate the architecture specification to the SMV program as follows.
Since juðAckBuf Þj ¼ 2 and it is 1-bounded, we can
define the state variable AckBuf as: AckBuf: 0 . . . 2;
However, to make it more meaningful, we define it as
follows instead: AckBuf {0, bit0, bit1}; where state 0
means there is no token in Place AckBuf. Similarly, we
can define AckOut and AckIn. AckOut: {0, bit0, bit1}
and AckIn: {0, bit0, bit1, lost, corrupted}, respectively.
We have noted from the assumption that
juðAcceptÞj ¼ 8 and it is eight-bounded, so it seems that
we
define Accept to range between 0 and
P8 should
i
i¼0 8 1. In fact, Accept can be represented by eight
values (in addition to 0) since messages are sent in order.
So we define Accept as: Accept: 0 . . . 8; where state 0
means there is no token in Place Accept, i (i > 0) means
that there are i tokens in Accept and the id for each
message is 1 to i, respectively. Similarly, Deliver is defined as: Deliver: 0 . . . 8.
To make it more convenient to extract message id and
associated bit tag, we define the remaining two variables
as follows:
DataBuf : 0 . . . 17; ==0 : empty; 1 :
==undefined; 2–17 : message id 2 þ bit
DataOut : 0 . . . 17;
DataIn : 0 . . . 19; ==18-lost; 19-corrupted
After the state variables are defined, the initial state
and transition relations are defined straightforwardly.
See Appendix A for the complete SMV program for this
model.
The SPEC part is defined as follows according to the
properties we intend to verify.
(1) All messages are eventually delivered. This formula
ensures property (P1).
AF Deliver ¼ 8
where A is the universal path quantifier and F is the
temporal operator } in CTL.
21
(2) Messages are delivered in order and all delivered
message are distinct. This formula ensures properties (P2) and (P3).
AGðdeliverData & !next ðdeliverDataÞ ! DataIn=2
¼ Deliver þ 1Þ;
where G is the temporal operator in CTL.
If we run the SMV program now, the first formula is
false. This is because we have not considered the fairness
constraints. ABP works successfully only when the
channels do not always lose or corrupt messages.
Therefore we need to add fairness constraints in the
SMV program to make sure that a message will get
through the channel when it is sent infinitely often. The
necessary fairness constraints are as follows:
FAIRNESS
DataOut > 0 ! AFðDataIn > 0 & DataIn < 18Þ
AckOut > 0 ! AFðAckIn ¼ bit0 j AckIn ¼ bit1Þ
After the fairness constraints are added, the specification is evaluated to be true.
4. Analyzing SAM specifications using theorem proving
Although model checking is very effective for finite
state systems, it is in general not applicable to systems
with infinite states. Depending on the underlying Petri
net and temporal logic models used in SAM, model
checking may or may not be applicable. In the previous
Section, we showed how to apply model checking to
SAM specifications. In this section, we show how to use
the more general theorem proving approach to verify
SAM specifications. We have successfully applied the
theorem proving approach in analyzing an SAM specification of an electronic commerce system.
4.1. The stanford temporal prover
STeP, the Stanford Temporal Prover, is a tool for
formal verification of temporal properties of reactive
systems (Manna et al., 1994). Fig. 8 presents an overview
of the STeP system. The main inputs are a reactive system in the form of a fair transition system (FTS) and a
property in first order linear-time temporal logic to be
proven. Verification can be performed by the model
checker or by deductive means. Model checking is automatic; deductive verification is to a large extend automatic for simple safety properties, while progress
properties require more user guidance, usually in the
form of a verification diagram. In all cases, the automatic
prover is responsible for generating and proving the required verification conditions. An interactive Gentzenstyle theorem prover is used to establish those verification conditions that cannot be proved automatically.
22
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
Fig. 8. An overview of the STeP system.
4.2. Translating PrT nets to FTS models
In order to use STeP to analyze SAM architecture
specifications, we first need to translate a PrT net into an
FTS model.
A fair transition system hV ; H; T ; J ; Ci is defined by
the following components (Manna and Pnueli, 1992):
• V ¼ fu1 ; . . . ; un g V : A finite set of system variables.
• H: The initial condition.
• T: A finite set of transitions. Each transition s 2 T is
a function s. R ! 2R (R denotes the set of all states),
mapping each state s 2 R into a (possibly empty) set
of states s R. Each state in s(s) is called a
s-successor of s.
We say that the transition s is enabled on the state s if
sðsÞ 6¼ £. Otherwise, we say that s is disabled on s.
• J T : A set of just transitions.
• C T : A set of compassionate transitions.
Each transition s 2 T is represented by a first order
formula qs ðV ; V 0 Þ, called the transition relation. Thus,
the state s0 is a s-successor of the states if the formula
qs ðV ; V 0 Þ evaluates to true. The enabledness of the
transition s can be expressed by the formula EnðsÞ:9V 0 :
qs ðV ; V 0 Þ.
Let S be a FTS for which the above components have
been identified. We define a computation of S to be an
infinite sequence of V-states r: s0 ; s1 ; s2 ; . . ., satisfying
the following requirements:
• Initiation: s0 is initial, i.e. s0 j ¼ H.
• Consecution: For each j ¼ 0; 1; . . ., the state sjþ1 is a
s-successor of the state sj i.e. sjþ1 2 s (sj ), for some
s 2 T.
• Justice: For each s 2 J it is not the case that s is continually enabled beyond some point in r but taken at
only finitely many positions in r.
• Compassion: For each s 2 C it is not the case that s is
enabled on infinitely many states in r but taken at
only finitely many positions in r.
For a system S, we denote by Comp( S) the set of all
computation of S.
Given a PrT net p ¼ ðN ; Spec; InsÞ as defined in Section 2.2.1, we define a corresponding FTS by Sp ¼ hV ;
H; T ; J ; Ci, where
• The set of local variables: V ¼ fvp jp 2 P g.
• Initial conditions: H ¼ ^p2V (v ¼ M0 ðpÞ).
• For every transition t in p and every a in the set of
occurrence modes aS, there is a corresponding transition t with the transition relation defined as qt : a ¼
ðenðtÞ ! f ðtÞÞ:a,
V
where enðtÞ ¼ RðtÞ ^ p2P (vp Lðp; tÞ) and f ðtÞ ¼
V
0
p2P (vp ¼ vp Lðp; tÞ [ Lðt; pÞ).
The set of all possible transitions is T ¼ fqt :
ajt 2 T ^ a 2 aSg.
• Weak fairness: J ¼ T .
• Strong fairness: C ¼ £.
The translation is quite straightforward and can be
automated to a large extent. The soundness of the
above transformation is explained as the following
theorem.
Theorem (Soundness of the transformation). Given a
PrT net p, suppose Sp ¼ hV ; H; T ; J ; Ci be the FTS obtained from p using the above transformation rules.
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
• For any run r ¼ m0 ; m1 ; m2 ; . . . 2 CompðpÞ, 8vp 2 V ,
i 2 Nat, let si ðvp Þ ¼ mi ðpÞ, then r0 ¼ s0 ; s1 ; s2 ; . . . 2
CompðSp Þ.
• For any state sequence r ¼ s0 ; s1 ; s2 ; . . . 2 CompðSp Þ,
8p 2 P , i 2 Nat, let mi ðpÞ ¼ si ðvp Þ, then r0 ¼ m0 ;
m1 ; m2 ; . . . 2 CompðpÞ.
Proof
(1) Suppose run r ¼ m0 ; m1 ; m2 ; . . . 2 CompðpÞ, Let the
corresponding transition sequence be t0 ; t1 ; t2 ; . . . ;
and occurrence models be a0 ; a1 ; a2 ; . . . By definition, the following predicate holds:
8i 2 Nat; 8p 2 P ððmi ðpÞ Lðp; tÞ : ai Þ ^ ðRðti Þ : ai Þ
^ ðmiþ1 ¼ mi ðpÞ Lðp; tÞ : ai [ Lðt; pÞ : ai ÞÞ
Because 8vp 2 V , s0 ðvp Þ ¼ m0 ðpÞ, we get s0 j ¼ H. For
each i 2 Nat, (si ; siþ1 Þj ¼ st i;a i holds. Consequently,
s0 ; s1 ; s2 . . . is a run of Sp and the corresponding
transition sequence is st0;a0 ; st1;a1 ; st2;a2 ; . . . Therefore
r0 ¼ s0 ; s1 ; s2 ; . . . 2 CompðSp Þ.
(2) Suppose r ¼ s0 ; s1 ; s2 ; . . . 2 CompðSp Þ. Let the corresponding transition sequence be st0;a0 ; st1;a1 ; st2;a2 ; . . .
Thus mi 2 ½m0 i follows from the definition of
mi and sti;ai . Consequently, r0 ¼ m0 ; m1 ; m2 ; . . .
2 CompðpÞ. Reducing label substitutions: There may be many redundant transitions in the resulting FTS, i.e. these
transitions never occur due to the label constrains of PrT
nets. Consequently, the label constraints can sometimes
be used to significantly reduce the number of transitions.
We usually apply the label constraints to reduce transitions before formal verification of the models.
To demonstrate the translation, we apply the above
rules to the dining philosophers system and obtain the
following FTS S ¼ hV ; H; T ; J ; Ci, where
V ¼ fthinking; chopstick; eatingg
H ¼ ðthinking ¼ f1; 2; 3; 4; 5gÞ ^ ðeating ¼ f gÞ
^ðchopstick ¼ f1; 2; 3; 4; 5gÞ
Using the label reduction strategy for occurrence
mode, we get
a S ¼ fhph; ch1; ch2i7!h1; 1; 2i,
hph; ch1; ch2i7!h2; 2; 3i,
htph; ch1; ch2i7!h3; 3; 4i,
hph; ch1; ch2i7!h4; 4; 5i,
hph; ch1; ch2i7!h5; 5; 1ig
T ¼ fqpickup : a; qputdown : aja 2 aSg,
where: qpickup ¼ enðpickupÞ ! f ðpickupÞ
enðpickupÞ ¼ ðfphg thinkingÞ^
ðfch1; ch2g chopstickÞ
f ðpickupÞ ¼ ðthinking0 ¼ thinking fphgÞ
^ðchopstick 0 ¼ chopstick fch1; ch2gÞ
^ðeating0 ¼ eating [ fhph; ch1; ch2igÞ; and
qputdown ¼ enðputdownÞ ! f ðputdownÞ
23
enðputdownÞ ¼ ðfhph; ch1; ch2ig eatingÞ
f ðputdownÞ ¼ ðeating0 ¼ eating fhph; ch1; ch2igÞ
^ðthinking0 ¼ thinking [ fphgÞ
^ðchopstick 0 ¼ chopstick [ fch1; ch2gÞ
4.3. Verifying SAM specifications using STeP
After translating a PrT net into an FTS, we can use
STeP to verify SAM architecture properties. A verification session begins by loading a program or transition
system that describes the system of interest and entering
a temporal logic formula that expresses one or more
properties to be proved. The formula becomes the root
goal of a proof tree. There are now several ways to
proceed. The most common route is to apply a verification rule. The basic verification rule for safety properties is B-INV:
H ! p;
fpgT fpg
p
which states that if a property p is satisfied by the initial
condition H, and is maintained by every transition in the
transition set T, then p holds in every state.
By applying a suitable rule, a proof goal is reduced to
a few first order verification conditions or simpler temporal formulas, which are usually easier to verify. The
proof is finished if all sub-goals are established. In order
to use the prover, knowledge about inference rules is
required. Furthermore, general knowledge and experience of theorem proving are essential in guiding and
obtaining successful results. STeP supports the proving
of safety properties nicely; however it is in general difficult to prove liveness properties.
The FTS of the five dining philosophers problem is
described in STeP as follows:
Transition System % 5-dining philosophers
out thinking:array[1 . . . 5] of bool
where Forall i:[1 . . . 5].(thinking[i] ¼
true)
out chopstick:array[1 . . . 5] of bool
where Forall i:[1 . . . 5].(chopstick[i] ¼
true)
out eating:array[1 . . . 5] of bool
where Forall i:[1. . . 5].(eating[i] ¼
false)
location pickup:[1 . . . 5] ! bool
location putdown:[1 . . . 5]! bool
Transition pickup[i:[1 . . . 5]] Just:
enable (thinking[i] ¼ true)
/n chopstick[i] ¼ true)
/n chopstick[(i mod 5)+1] ¼ true)
assign thinking[i] ¼ false,
chopstick[i] ¼ false,
chopstick[(i mod 5)+1] ¼ false,
24
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
eating[i] ¼ true
Transition putdown[i:[1 . . . 5]] Just:
enable eating[i] ¼ true
assign thinking[i] ¼ true,
chopstick[i] ¼ true,
chopstick[(i mod 5)+1] ¼ true,
eating[i] ¼ false
The property of mutual exclusion is specified as follows.
SPEC
variable i:[1 . . . 5]
Forall i:[1 . . . 5].[](!(eating[i] ¼ true /n
eating[(i mod 5)+1] ¼ true))
This is a typical invariance property. After loading
the FTS and the property specification, we can apply
rule B-INV. The result is shown in Fig. 9, which shows
the graphical user interface and the available functionality of STeP.
The result tells us that the property is not inductive,
that is, it is not preserved by all transitions. In particular, the verification conditions for transitions pickup[i]
are not generally valid although they are valid for this
program, and indeed when we apply rule B-INV the
Simplifier does not reduce them to true. We now have
several options. Since this is a finite state system with
small number of states, model checking has a good
chance of succeeding. STeP has a model checking
component. Using the model checker, we are able to
instantly verify the remaining sub-goal.
5. Related work
Our work is related to research in several areas. First,
the dual formalism foundation of SAM is related to
work in integrating formal methods, especially integrating Petri nets and temporal logic (He and Lee, 1990;
Mandrioli et al., 1996). However, SAM provides a unique hierarchical framework to tailor the dual formalism
for software architecture specification while other works
aimed to provide a general specification methodology.
As far as we know, SAM is the only software architecture description method that uses the dual formalism
Petri nets and temporal logic.
Second, our work is related to symbolic model
checking software specifications in general, and model
checking software architecture specification in specific.
Several researchers applied SMV to analyze properties
of requirements specifications of real systems (Chan
et al., 1998; Sreemani and Atlee, 1996). There are several
differences between our work and their works: (1) the
underlying specification methods are different––a statemachine language based on statecharts was used in
(Chan et al., 1998) and the Software Cost Reduction
notation was used in (Sreemani and Atlee, 1996), while
ours is PrT nets; (2) the main concerns are slightly different––software architecture specification is in general
much simpler than a general software specification due
to the high-level abstraction of a software architecture
specification. Although we may refine an architecture
specification into a more detailed specification, we can
always focus on analyzing individual components and
Fig. 9. The result of applying Rule B-INV to the dining philosophers problem.
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
connectors to tackle the complexity problem. Therefore
we are less concerned with the state explosion problem.
Furthermore, SAM provides a hierarchical architecture
specification model, which enables iterative model
checking in a bottom-up fashion. With regard to model
checking software architecture specifications, we only
found one publication (Ciancarini and Mascolo, 1999).
In (Ciancarini and Mascolo, 1999), model checking an
architecture specification written in an architecture
language PoliS was mentioned; however, no results were
given. PoliS is a coordination language based on nested
tuple spaces. It is conceivable that the rewrite rules can
be used to derive transitions. It is not straightforward to
define the state space. Furthermore, the property to be
checked cannot be written directly using PoliS itself.
Perhaps, the research most closely related to our
work is model checking Petri nets. However most researchers aimed to develop new or more effective model
checking techniques for specific Petri net models (Juan
et al., 1998; Valmari, 1996). Our goal is to apply the
existing symbol model checking technique to software
architecture specifications written in SAM. The work on
codifying Petri nets in SMV (Wimmel, 1997) has influenced our translation approach in Section 3.
Finally, our work is related to proving Petri net
properties using temporal logic (Bradfield, 1991; He and
Ding, 1992; He and Lee, 1990). Instead of trying to
develop new temporal logic techniques to analyze Petri
nets, we have explored how to use mature existing
temporal logic techniques and tools to analyze the
properties of Petri nets modeling SAM software architecture behaviors. Both the net structures and properties
of these Petri nets are more restrictive and simpler than
Petri nets describing general systems.
6. Concluding remarks
In this paper, we presented the SAM framework and
its foundation for software architecture specification,
and defined the correctness criteria of SAM specifications. We presented two analysis techniques for SAM
specifications by providing translation approaches from
PrT nets to state transition systems in SMV and STeP.
We demonstrated our translation approaches through
two examples.
Model checking is very effective and the verification is
completely automatic. We have used SMV in two applications––a flexible manufacturing system and the alternating bit communication protocol. In the first
application, we used place transition nets (a class of low
level Petri nets) and CTL as the foundation of SAM.
The translation was straightforward. SMV allocated
10046 BDD nodes and only took 0.19 s user time and
0.02 s system time. We successfully detected a deadlock
in the behavior model represented using a place transi-
25
tion net. The deadlock was caused by the wrong direction of an arc. In the second application, we explored
how to apply model checking to PrT nets by transforming predicate symbols to a set of propositional
symbols or by suppressing data items if a property to be
verified is data independent. We also explored how to
deal with time constraints. We developed two PrT behavior models for the ABP––one without timer and one
with timer. SMV allocated 10412 BBD nodes and took
0.06 s user time to a liveness property for the ABP model
without timer; however SMV allocated 1804888 BBD
and took 314.79 s to prove the same liveness property.
The limitation of model checking is its applicability,
for it is in general not applicable to infinite state systems.
To analyze SAM architecture specifications for infinite
state systems, we have tried temporal theorem prover
STeP and have applied it to an electronic commerce
system. STeP is being developed to support formal
verification of reactive systems. Unlike most systems for
temporal verification, STeP is not restricted to finite
state systems, but combines modeling checking with
deductive methods to allow the verification of a broad
class of systems. Techniques such as verification rules,
verification diagrams, decision procedures and invariant
generation in STeP make it a powerful tool for verification of parameterized (N-component) circuit designs,
parameterized (N-process) programs, and programs
with infinite data domains. However, STeP has its limitation also. Although a wide range of systems can in
principle be modeled as FTSs, it is often difficult to
conveniently represent large synchronous systems by
FTSs. In addition, the assertion language of STeP is
based on first order logic, and does not offer the same
expressiveness and flexibility of higher order logic theorem provers; these, on the other hand, require more
complex deductive support. Proofs in STeP can be saved
and re-run as tactics, but the proof management is not
as flexible or robust as that of PVS, a general-purpose
theorem proving environment (Owre et al., 1992). We
can say that relatively small but intricate concurrent
systems appear to be the most amenable to analysis with
STeP.
We have developed an environment for creating,
maintaining, simulating SAM specifications. We are
developing tools to translate behavior models in Petri
nets into state transition systems in SMV and in STeP so
that the whole process of developing and analyzing
SAM architecture specifications can be supported using
automated tools.
In this paper, we only focused on the complete model
checking, i.e. we first verify the correctness of individual
components and connectors and then verify the correctness of a composition by connecting the behavior
models of individual components and connectors into a
single composition level behavior model in PrT net. This
approach works in most situations due to the high-level
26
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
abstraction of a software architecture specification.
However the connected composition level behavior
model can be quite large in some situations to prevent
the effective use of symbolic model checking technique
or theorem proving. To solve this problem, we are
investigating several compositional model checking
techniques. Among the various proposed automated
compositional verification techniques in temporal logic
(Berezin et al., 1998; Clarke et al., 1994; Grumberg and
Long, 1994) and in Petri nets (Juan et al., 1998; Valmari,
1996), we found that the interface module technique
(Berezin et al., 1998) and the IO graph technique (Juan
et al., 1998) are most relevant to our research. We are
currently focusing on how to adapt these compositional
verification techniques to analyze SAM software architectural specifications. We are also studying compositional temporal logic proving techniques developed in
(Abadi and Lamport, 1991, 1993).
Acknowledgements
We thank two anonymous reviewers for their helpful
comments, which help improve the presentation of this
paper. This work is supported in part by NSF under
grant HDR-9707076 and CCR-0098120, and by NASA
under grant NAG 2-1440.
Appendix A. SMV program for ABP model
MODULE main
VAR
Accept:0 . . . 8;
Deliver:0 . . . 8;
DataBuf:0 . . . 17;
DataOut:0 . . . 17;
DataIn:0 . . . 19;
AckOut:{0, bit0, bit1};
AckIn:{0, bit0, bit1, lost, corrupt};
AckBuf:{0, bit0, bit1};
INIT
Accept ¼ 8 & Deliver ¼ 0 & DataBuf ¼ 1 &
DataOut ¼ 0 & DataIn ¼ 0 & AckOut ¼ 0 &
AckIn ¼ bit1 & AckBuf ¼ bit1
TRANS
(
–sendData
sendData & next(Accept) ¼ (Accept 1)
& next(AckIn) ¼ 0
&
(next(DataBuf) ¼ case
AckIn ¼
bit0:(9 AcceptÞ 2 þ 1; 1:(9 AcceptÞ 2;esac)
&
(next(DataOut) ¼ case
AckIn ¼
bit0:(9 AcceptÞ 2 þ 1; 1:(9 AcceptÞ 2;esac)
& next(DataIn) ¼ DataIn & next(AckOut) ¼ AckOut & next(AckBuf) ¼ AckBuf
& next(Deliver) ¼ Deliver
j
–resendData
resendData
&
next(AckIn) ¼ 0
&
next(DataBuf) ¼ DataBuf & next(DataOut) ¼ DataBuf
& next(Accept) ¼ Accept & next(DataIn) ¼ DataIn & next(AckOut) ¼ AckOut
& next(AckBuf) ¼ AckBuf
& next(Deliver) ¼ Deliver
j
–deliverData
deliverData & next(Deliver) ¼ Deliver
+ 1 & next(DataIn) ¼ 0
& (next(AckBuf) ¼ case AckBuf ¼ bit0:
bit1;1:bit0;esac)
& (next(AckOut) ¼ case AckBuf ¼ bit0:
bit1;1:bit0;esac)
& next(Accept) ¼ Accept & next(AckIn) ¼ AckIn & next(DataOut) ¼ DataOut
& next(DataBuf) ¼ DataBuf
j
–resendAck
resendAck & next(AckBuf) ¼ AckBuf &
next(DataIn) ¼ 0
& next(AckOut) ¼ AckBuf & next(Accept) ¼ Accept & next(AckIn) ¼ AckIn
& next(DataOut) ¼ DataOut & next(DataBuf) ¼ DataBuf & next(Deliver) ¼ Deliver
j
–DataChannel
–Data transmitted successfully
DataTransmitted & next(DataOut) ¼ 0 &
next(DataIn) ¼ DataOut
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(AckIn) ¼ AckIn
& next(AckOut) ¼ AckOut & next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf
j
–Data lost in transit
DataLost
&
next(DataOut) ¼ 0
&
next(DataIn) ¼ 18
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(AckIn) ¼ AckIn
& next(AckOut) ¼ AckOut & next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf
j
–Data corrupted in transit
DataCorrupted & next(DataOut) ¼ 0 &
next(DataIn) ¼ 19
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(AckIn) ¼ AckIn
& next(AckOut) ¼ AckOut & next(Data-
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
Buf) ¼ DataBuf & next(AckBuf) ¼ AckBuf
j
–Ack Channel
–Ack transmitted successfully
AckTransmitted & next(AckOut) ¼ 0 &
next(AckIn) ¼ AckOut
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(DataOut) ¼
DataOut
& next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf & next(DataIn) ¼ DataIn
j
–Ack lost in transit
AckLost & next(AckOut) ¼ 0 & next(AckIn) ¼ lost
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(DataOut) ¼
DataOut
& next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf & next(DataIn) ¼ DataIn
j
–Ack corrupted in transit
AckCorrupted & next(AckOut) ¼ 0 &
next(AckIn) ¼ corrupt
& next(Accept) ¼ Accept & next(Deliver) ¼ Deliver & next(DataOut) ¼
DataOut
& next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf & next(DataIn) ¼ DataIn
j
–selfloop for deadlock
deadlock & next(Accept) ¼ Accept &
next(Deliver) ¼ Deliver
& next(DataOut) ¼ DataOut & next(AckIn) ¼ AckIn & next(AckOut) ¼ AckOut
& next(DataBuf) ¼ DataBuf & next(AckBuf) ¼ AckBuf & next(DataIn) ¼ DataIn
)
DEFINE
sendData: ¼ Accept>0 & ((DataBuf mod
2) ¼ 0 & AckIn ¼ bit0 | (DataBuf mod
2) ¼ 1 & AckIn ¼ bit1);
resendData: ¼ DataBuf>0
&
(AckIn ¼ lost | AckIn ¼ corrupt |
(DataBuf mod 2) ¼ 1 & AckIn ¼ bit0 |
(DataBuf mod 2) ¼ 0 & AckIn ¼ bit1);
deliverData: ¼ DataIn>0 & DataIn< ¼ 17
& ((DataIn mod 2) ¼ 0 & AckBuf ¼ bit1 |
(DataIn mod 2) ¼ 1 & AckBuf ¼ bit0);
resendAck: ¼ AckBuf! ¼ 0 & DataIn>0 &
(DataIn ¼ 18|DataIn ¼ 19 |
(DataIn mod 2) ¼ 1 & AckBuf ¼ bit1 |
(DataIn mod 2) ¼ 0 & AckBuf ¼ bit0);
DataTransmitted: ¼ DataOut>0;
DataLost: ¼ DataOut>0;
DataCorrupted: ¼ DataOut>0;
27
AckTransmitted: ¼ AckOut! ¼ 0;
AckLost: ¼ AckOut! ¼ 0;
AckCorrupted: ¼ AckOut! ¼ 0;
deadlock: ¼ !(sendData|resendData|deliverData|resendAck|DataTransmitted|AckTransmitted);
FAIRNESS
(DataIn>0 & DataIn<18) & (AckIn ¼ bit0
| AckIn ¼ bit1)
SPEC
(AF Deliver ¼ 8)
SPEC
(AG((deliverData & !next(deliverData))->(DataIn/2 ¼ Deliver+1)))
Appendix B. Running results with fairness constraints
–specification AF Deliver ¼ 8 is true
–specification
AG
(deliverData
&
!next(deliverData) -> . . . is true
resources used:
user time:0.09 s, system time:0.02 s
BDD nodes allocated:10412
Bytes allocated:1376256
BDD nodes representing transition relation:1597 þ 28
reachable states:129 (2^7.01123) out of
2.36196eþ07 (2^24.4935)
References
Abadi, M., Lamport, L., 1991. The Existence of Refinement Mappings. Theoretical Computer Science 82 (2), 253–284.
Abadi, M., Lamport, L., 1993. Composing specifications. ACM
Transactions on Programming Languages and Systems 15 (1),
73–130.
Abowd, G., Allen, R., Garlan, D., 1995. Formalizing style to
understand descriptions of software architecture. ACM Transaction on Software Engineering and Methodology 4 (4), 319–364.
Allen, R., Garlan, D., 1997. A formal basis for architectural
connection. ACM Transactions on Software Engineering and
Methodology 6 (3), 213–249.
Berezin, S., Campos, S., Clarke, E.M., 1998. Compositional Reasoning
in Model Checking. Technical Report, CMU-CS-98-106, Carnegie
Mellon University.
Binns, P., Engelhart, M., Jackson, M., Vestal, S., 1996. Domainspecific software architectures for guidance, navigation, and
control. International Journal of Software Engineering and
Knowledge Engineering 6 (2).
Bradfield, J., 1991. Proving temporal properties of Petri nets. In:
Lecture Notes in Computer Science, vol. 524. Springer-Verlag. pp.
29–47.
Bryant, R.E., 1986. Graph-based algorithms for Boolean function
manipulation. IEEE Transactions on Computers C-35 (8), 667–
691.
Chan, W., Anderson, R., Beame, P., Burns, S., Modugno, F., Notkin,
D., Reese, J., 1998. Model checking large software specifications.
IEEE Transaction on Software Engineering 24 (7), 498–520.
28
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
Ciancarini, P., Mascolo, C., 1999. Model checking a software
architecture. In: Proceedings of ROSATEA: International Workshop on the Role of Software Architecture in Analysis and Testing,
Software Engineering Notes. vol. 24, p. 4.
Clarke, E., Wing, J., 1996. Formal methods: state of the art and future.
ACM Computing Surveys 28 (4), 626–643.
Clarke, E.M., Emerson, E.A., Sistla, A.P., 1986. Automatic verification of finite-state concurrent systems using temporal logic specifications. ACM Transaction on Programming Languages and
Systems 8 (2), 244–263.
Clarke, E.M., Grumberg, O., Long, D.E., 1994. Model Checking and
Abstraction. ACM Transaction on Programming Language and
Systems 16 (5), 1512–1542.
Clarke, E.M., Grumberg, O., Peleg, D., 1999. Model Checking. The
MIT Press.
Genrich, H., Lautenbach, K., 1981. System modeling with high-level
Petri nets. Theoretical Computer Science 13, 109–136.
Grumberg, O., Long, D., 1994. Model checking and modular
verification. ACM Transaction on Programming Language and
Systems 16 (3), 843–871.
He, X., 1996. A formal definition of hierarchical predicate transition
nets. In: Proceedings of the 17th International Conference on
Application and Theory of Petri Nets (ICATPN’96). Lecture Notes
in Computer Science, 1091, Osaka, Japan, pp. 212–229.
He, X., Deng, Y., 2000. Specifying software architectural connectors in
SAM. International Journal of Software Engineering and Knowledge Engineering 10 (4), 411–432.
He, X., Deng, Y., 2002. A framework for developing and analyzing
software architecture specifications in SAM. The Computer Journal 45 (1), 111–128.
He, X., Ding, Y., 1992. A temporal logic approach for analyzing safety
properties of predicate transition nets. In: Proceedings of the 12th
IFIP World Computer Congress (Information Processing’92).
Madrid, Spain, pp. 127–133.
He, X., Lee, J.A.N., 1990. Integrating predicate transition nets and
first order temporal logic in the specification of concurrent systems.
Formal Aspects of Computing 2 (3), 226–246.
Hoare, C.A.R., 1985. Communicating Sequential Processes. PrenticeHall International.
Inverardi, P., Richardson, D., 1999. ROSATEA: International Workshop on the Role of Software Architecture in Analysis and Testing.
In: Software Engineering Notes, vol. 24. p. 4.
Inverardi, P., Wolf, A., 1995. Formal specification and analysis of
software architectures using the chemical abstract machine model.
IEEE Transactions on Software Engineering 21 (4), 373–386.
Juan, E., Tsai, J.P., Murata, T., 1998. Compositional verification of
concurrent systems using Petri-net-based condensation rules. ACM
Transactions on Programming Languages and Systems 20 (5), 917–
979.
Lamport, L., 1994. The temporal logic of actions. ACM Transactions
on Programming Languages and Systems 16 (3), 872–923.
Luckham, D.C., Kenney, J., Augustin, L., et al., 1995. Specification
and analysis of system architecture using rapide. IEEE Transactions on Software Engineering 21 (4), 336–355.
Maidl, M., 2000. The Common Fragment of CTL and LTL. In:
Proceeding of 41st Symposium on Foundations of Computer
Science. pp. 643–652.
Mandrioli, D., Morzenti, A., Pezze, M., Pietro, P., Silva, S., 1996. A
Petri net and logic approach to the specification and verification of
real time systems. In: Heitmeyer, C., Mandrioli, D. (Eds.), Formal
Methods for Real time Computing. John Wiley & Sons Ltd.
Manna, Z., Anuchitanukul, A., Bjorner, N., Browne, A., Chang, E.,
Colon, M., de Alfaro, L., Devarajan, H., Sipma, H., Uribe, T.,
1994. STeP: The Stanford Temporal Prover, Technical Report
STAN-CS-TR-94-1518, Computer Science Department, Stanford
University.
Manna, Z., Pnueli, A., 1992. The Temporal Logic of Reactive and
Concurrent Systems. Springer-Verlag.
McMillan, K.L., 1993. Symbolic Model Checking. Kluwer Academic
Publishers, Boston.
Medvidovic, N., Taylor, R., 2000. A classification and comparison
framework for software architecture description languages. IEEE
TSE 26 (1), 70–93.
Murata, T., 1989. Petri nets: properties, analysis and applications.
Proceedings of the IEEE 77 (4), 541–580.
Owre, S., Rushby, J.M., Shankar, N., 1992. PVS: a prototype
verification system. In: Kapur, D. (Ed.), 11th International
Conference on Automated Deduction (CADE). In: Lecture
Note in Artificial Intelligence, vol. 607. Springer-Verlag, pp. 748–
752.
Richardson, D., Wolf, A., 1996. Software testing at the architectural
level. In: Proceedings of the 2nd International Software Architecture Workshop. pp. 68–71.
Shaw, M., 2001. The coming-of-age of software architecture research.
In: Proceedings of International Conference on Software Engineering. Toronto, pp. 656–664.
Shaw, M., Deline, R., Klein, D., et al., 1995. Abstractions for software
architecture and tools to support them. IEEE Transactions on
Software Engineering 21 (4), 314–335.
Spivey, J., 1992. Z Reference Manual, second ed. Cambridge University Press.
Sreemani, T., Atlee, J., 1996. Feasibility of model checking software
requirements: a case study. In: Proceedings of the 11th Annual
Conference On Computer Assurance. Gaithersburg, MD, pp. 77–
88.
Valmari, A., 1996. Compositionality in state space verification
methods. Lecture Notes in Computer Science 1091, 29–56.
Wang, J., He, X., Deng, Y., 1999. Introducing software architecture
specification and analysis in SAM through an example. Information and Software Technology 41 (7), 451–467.
Wimmel, G., 1997. A BDD-based Model Checker for the PEP Tool.
Technical Report, Department of Computer Science, University of
Newcastle.
Xudong He received the BS and MS degrees in computer science from
Nanjing University, China, in 1982 and 1984, respectively. He received
the Ph.D. degree in computer science from Virginia Polytechnic Institute & State University (Virginia Tech) in 1989.
He joined the faculty in the School of Computer Science at Florida
International University (FIU) in 2000, and is an associate professor of
the School of Computer Science and the Director of the Center for
Advanced Distributed System Engineering. Prior to joining FIU, he
was an associate professor in the Department of Computer Science at
North Dakota State University since 1989. His research interests include formal methods, especially Petri nets, and software testing
techniques. He has published over 50 papers in the above areas.
Dr. He is a member of the Association for Computing Machinery,
and the IEEE Computer Society.
Huiqun Yu received his B.S. degree from Nanjing University in 1989,
M.S. degree from East China University of Science and Technology
(ECUST) in 1992, and Ph.D. degree from Shanghai Jiaotong University in 1995, all in computer science. Currently, he is a visiting
scholar in the School of Computer Science at Florida International
University. He holds a Professor position in the Department of
Computer Science and Engineering at ECUST. His research interests
include formal methods for complex software systems, hardware/
software co-design of embedded systems, and techniques for analysis
of software architecture.
Tianjun Shi received his B.S. in Manufacturing Engineering from
Beijing University of Aeronautics and Astronautics in 1995 and M.S.
in Computer Science from Beijing Institute of Information and Control in 1998. He is currently a Ph.D. candidate in Computer Science at
Florida International University. His research interests include software architecture, formal methods, distributed computing and networking.
X. He et al. / The Journal of Systems and Software 71 (2004) 11–29
Junhua Ding received a B.S. degree in Computer Engineering from
China University of Geosciences in 1994, and an M.S degree in
Computer Science from Nanjing University in 1997. He is presently a
Ph.D. candidate in the School of Computer Science at Florida International University. He is also a software engineer in the Cytomics
Development Center of Beckman Coulter Inc. His research interests
include modeling and analysis of distributed systems, Cytomics system
development.
Yi Deng is the Director of the School of Computer Science at the
Florida International University (FIU) – The State University of
Florida at Miami. From August 2000 to May 2002, he was with the
University of Texas at Dallas (UT-Dallas) as the Managing Director
of the Embedded Software Center and Associate Professor of Computer Science in the School of Engineering and Computer Science.
Prior to joining UT-Dallas, he had been an Associate Professor of
29
Computer Science at FIU and the founding Director of Center for
Advanced Distributed Systems Engineering (CADSE) – a university
research center designated by the Florida Board of Regents. His research interests include component-based software engineering, software architecture, formal methods for complex systems, modeling and
analysis of software security systems and middleware. He has published over 60 papers in various journals and conferences. He has
been the Principal Investigator (PI) or Co-PI of fourteen (14) research
awards of over $7 million from the National Science Foundation
(NSF), US Air Force Office of Scientific Research (AFOSR), US
Army Research Office (ARO), US Air Force Rome Laboratory and
the National Aeronautics and Space Administration (NASA), as well
as from industry. Dr. Deng is an editor for the International Journal
of Software Engineering and Knowledge Engineering and has been
program committee chair or member for several conferences. He received his Ph.D. in Computer Science from University of Pittsburgh
in 1992 and is a member of ACM, EEE and IEEE Computer Society.