Deriving test plans from architectural descriptions.
INTRODUCTION
In recent years the focus of software engineering is continuosly
moving towards systems of larger dimensions
and complexity. Software production is becoming more
and more involved with distributed applications running
on heterogeneous networks, while emerging technologies
such as commercial o-the-shelf (COTS) products are
becoming a market reality [22]. As a result, applications
are increasingly being designed as sets of autonomous,
decoupled components, promoting faster and cheaper
system development based on COTS integration, and
facilitating architectural changes required to cope with
the dynamics of the underlying environment.
The development of these systems poses new challenges
and exacerbates old ones. A critical problem is understanding
if system components integrate correctly. To
this respect the most relevant issue concerns dynamic
integration. Indeed, component integration can result in
architectural mismatches when trying to assemble components
with incompatible interaction behavior [12, 7],
leading to system deadlocks, livelocks or in general failure
to satisfy desired functional and non-funtional system
properties.
In this context Software Architecture (SA) can play a
signicant role. SAs have in the last years been con-
sidered, both by academia and software industries, as a
means to improve the dependability of large complex
software products, while reducing development times
and costs [21, 3]. SA represents the most promising approach
to tackle the problem of scaling up in software
engineering, because, through suitable abstractions, it
provides the way to make large applications manage-
able. The originality of the SA approach is to focus on
the overall organization of a large software system (the
using abstractions of individual components. This
approach makes it possible to design and apply tractable
methods for the development, analysis, validation, and
maintenance of large software systems.
A crucial part of the development process is testing.
While new models and methods have been proposed
with respect to requirements analysis and design, notably
UML [18], how to approach the testing of these
kinds of systems remains a neglected aspect. The paradox
is that these new approaches specically address the
design of large scale software systems. However, for such
systems, the testing problems not only do not diminish,
but are intensied. This is especially true for integration
testing. In fact, due to the new paradigms centered
on component-based assembly of systems, we can easily
suppose a software process in which unit testing plays
a minor role, and testers have to focus more and more
on how components work when plugged together.
Lot of work has been devoted to the analysis of formal
descriptions of SAs. Our concern is not in the analysis
of the consistency and correctness of the SA, but rather
on exploiting the information described at the SA level
to drive the testing of the implementation. In other
words we assume the SA description is correct and we
are investigating approaches to specication-based integration
testing, whereby the reference model used to
generate the test cases is the SA description.
In general, deriving a functional test plan means to identify
those classes of behavior that are relevant for
testing purposes. A functional equivalence class collects
all those system executions that, although dierent
in details, carry on the same informative contents for
functional verication. The tester's expectation/hope
is that any test execution among those belonging to a
class would be equally likely to expose possible non con-
formities to the specication.
We identify interesting test classes for SA-based testing
as sequences of interactions between SA components.
More precisely, starting from an architectural descrip-
tion, carrying on both static and dynamic information,
we rst derive a Labelled Transition System (LTS), that
graphically describes the SA dynamics. The problem is
that the LTS provides a global, monolithic description
of the set of all possible behaviors of the system. It
is a tremendous amount of information
attened into a
graph. It is quite hard for the software architect to single
out from this global model relevant observations of
system behavior that would be useful during validation.
We provide the software architect with a key to decipher
the LTS dynamic model: the key is to use abstract views
of the LTS, called ALTSs, on which he/she can easily
visualize relevant behavioral patterns and identify those
ones that are more meaningful for validation purposes.
Test classes in our approach correspond to ALTS paths.
However, once test class selection has been made, it is
necessary to return to the LTS and retrieve the information
that was hidden in the abstraction step, in order
to identify LTS paths that are appropriate renements
of the selected ALTS paths. This is also supported by
our approach.
In the following we describe in detail the various steps
of the proposed approach in the scope of a case study.
In Section 2 we provide the background information:
we recall the Cham formalism, that is used here for SA
specication, and outline the case study used as a working
example. In Section 3 we provide a general overview
of the approach. In Section 4, we give examples of using
the approach, and address more specic issues. In
Section 5, we clarify better the relation between ALTS
paths and test specications. Finally, in the Conclu-
sions, we summarize the paper contribution and address
related work.
ADL DYNAMICS
architectures represent the overall system
structure by modelling individual components and their
interactions. An SA description provides a complete
system model by focussing on architecturally relevant
abstractions. A key feature of SA descriptions is
their ability to specify the dynamics. Finite State Machines
Petri Nets or Labelled Transition Systems
(LTSs) can be used to model the set of all possible
SA behaviors as a whole.
In the following subsection we brie
y recall the Cham
description of SA. From this description we derive an
LTS which represents the (global) system behavior of a
concurrent, multi-user software system.
The Cham Model
The Cham formalism was developed by Berry and
Boudol in the eld of theoretical computer science for
the principal purpose of dening a generic computational
framework [4].
Molecules constitute the basic elements
of a Cham, while solutions S 0 are multisets
of molecules interpreted as dening the states of a
Cham. A Cham specication contains transformation
rules
dictating the way solutions can evolve (i.e., states
can change) in the Cham. Following the chemical
metaphor, the term reaction rule is used interchangeably
with the term transformation rule. In the follow-
ing, with abuse of notation, we will identify with R both
the set of rules and the set of corresponding labels.
The way Cham descriptions can model SAs has already
been introduced elsewhere [14]. Here we only summarize
the relevant notions. We structure Cham specications
of a system into four parts:
1. a description of the syntax by which components of
the system (i.e., the molecules) can be represented;
2. a solution representing the initial state of the system

3. a set of reaction rules describing how the components
interact to achieve the dynamic behavior of
the system.
4. a set of solutions representing the intended nal
states of the system.
The syntactic description of the components is given
by a syntax by which molecules can be built. Following
Perry and Wolf [17], we distinguish three classes of
components: data elements, processing elements, and
connecting elements. The data elements contain the information
that is used and transformed by the processing
elements. The connecting elements are the \glue"
that holds the dierent pieces of the architecture to-
gether. For example, the elements involved in eecting
communication among components are considered connecting
elements. This classication is re
ected in the
syntax, as appropriate.
The initial solution corresponds to the initial, static conguration
of the system. We require the initial solution
to contain molecules modeling the initial state of each
component. Transformation rules applied to the initial
solution dene how the system dynamically evolves
from its initial conguration. One can take advantage of
this operational
avor to derive an LTS out of a Cham
description. In this paper we will not describe how an
LTS can be derived (see [11]). We only recall the LTS
denition we will rely on.
Denition 2.1 A Labelled Transition System is a
quintuple (S; is the set of states,
L is the set of labels, S 0 2 S is the initial state, SF  S
is the set of nal states and
is the transition relation.
Each state in the LTS corresponds to a solution, therefore
it is made of a set of molecules describing the states
of components. Labels on LTS arcs denote the transformation
rule that lets the system move from the tail
node state to the head node state.
We also need the denition of a complete path:
Denition 2.2 Let
l 1
l 2
l 3
be a path in an LTS. p is complete if S 0
is the initial
solution and Sn is a nal one.
Although our approach builds on the Cham description
of a SA it is worthwhile stressing that it is not committed
to it. Our choice of the Cham formalism is dictated
by our background and by its use in previous case stud-
ies. We are perfectly aware that other choices could be
made and want to make clear that the use of a specic
formalism is not central to our approach.
In more general terms what we have done so far can
be summarized as follows: we have assumed the existence
of an SA description in some ADL and that from
such description an LTS can be derived, whose node and
arc labels represent respectively states and transitions
relevant in the context of the SA dynamics. We also
User1
Router Server
Timer
AlarmUR AlarmRS (c)
Check1
AckSR (c)
User2
AlarmUR1
Check2
Check

Figure

1: Processes and Channels
assume that states contain information about the single
state of components and that labels on arcs denote
relevant system state transitions.
The TRMCS Case-Study
The Teleservice and Remote Medical Care System
(TRMCS) [2] provides monitoring and assistance to
users with specic needs, like disabled or elderly people.
The TRMCS is being developed at Parco Scientico e
Tecnologico d'Abruzzo, and currently a Java prototype
is running and undergoes SA based integration testing.
A typical TRMCS service is to send relevant information
to a local phone-center so that the family and medical
or technical assistance can be timely notied of critical
circumstances. We dene four dierent processes (User,
Router, Server and Timer), where:
User: sends either an \alarm" or a \check" message
to the Router process. After sending an alarm, it
waits for an acknowledgement from the Router.
Router: waits signals (check or alarm) from User.
It forwards alarm messages to the Server and checks
the state of the User through the control messages.
Server: dispatches help requests.
Timer: sends a clock signal for each time unit.

Figure

1 shows the static TRMCS Software Architectural
description, in terms of Component and Connec-
tors. Boxes represent Components, i.e., processing el-
ements, arrows identify Connectors, i.e., connecting elements
(in this case channels) and arrows labels refer
to the data elements exchanged through the channels.

Figure

shows only the reaction rules of the TRMCS
Cham Specication.
A portion of the LTS of the TRMCS SA is given in Fig.
3. The whole LTS is around 500 states. Note that arc
labels 0, 1, ., 21 correspond, respectively, to T 0 , T 1 ,
., T 21 , i.e., the labels of the TRMCS reaction rules,\0"
denotes the initial state and box states denote pointers
to states elsewhere shown in the picture (to make the
Reaction Rules
T1: User1= User1.o(check1), User1.o(alarmUR1).i(ackRU1)
T2: User2= User2.o(check2), User2.o(alarmUR2).i(ackRU2)
T3: User1.o(check1)= o(check1).User1
T4: User2.o(check2)= o(check2).User2
T11: o(alarmUR1).i(ackRU1).User1, i(alarmUR).o(alarmRS).i(ackSR).o(ackRU).Router
T12: o(alarmUR2).i(ackRU2).User2, i(alarmUR).o(alarmRS).i(ackSR).o(ackRU).Router
T13: o(alarmRS1).i(ackSR1).o(ackRU1).Router , i(alarmRS).o(ackSR).Server
T14: o(alarmRS2).i(ackSR2).o(ackRU2).Router , i(alarmRS).o(ackSR).Server
T15: o(ackSR1).Server,
T17: o(ackRU1).Router ,
T18: o(ackRU2).Router ,
T19: m1.Router, Timer, Sent = o(nofunc).Router, m1.Router, NoSent

Figure

2: TRMCS Cham Reaction Rules
graph more readable). Double arrows denote the points
in which the gure cuts LTS paths.
In this section we introduce our approach to SA-based
testing. Our goal is to use the SA specication as a reference
model to test the implemented system. Needless
to say, there exists no such thing as an ideal test plan
to accomplish this goal. It is clear, on the contrary,
that from the high-level, architectural description of a
system, several dierent SA-based test plans could be
derived, each one addressing the validation of a specic
functional aspect of the system, and dierent interaction
schemes between components.
Therefore, what we assume as the starting point for our
approach is that the software architect, by looking at
the SA from dierent viewpoints, chooses a set of important
patterns of behavior to be submitted to testing.
This choice will be obviously driven by several factors,
including specicity of the application eld, criticality,
schedule constraints and cost, and is likely the most crucial
step to a good test plan (we give examples of some
possible choices in Section 4).
With some abuse of terminology, we will refer to each
of the selected patterns of behavior as to an SA testing
criterion. With this term we want to stress that our
approach will then derive a dierent, specic set of tests
so as to fulll the functional requirements that each
\criterion" (choice) implies. In general more SA testing
criteria can be adopted to test a SA.
Two remarks are worth noting here. One is that as
the derived tests are specically aimed at validating the
high-level interactions between SA components, the test
plans we develop apply to the integration test stage.
The second remark is that since we are concerned with
testing, i.e., with verifying the software in execution, we
will greatly base our approach on the SA dynamics. In
particular, starting from a selected SA testing criterion,
we will primarily work on the SA LTS and on other
graphs derived from the latter by means of abstraction
(as described in the following).
Introducing obs-functions over SA dynamics
An SA testing criterion is initially derived by the software
architect in informal terms. We want to translate
it in a form that is interpretable within the context of
the SA specication, in order to allow for automatic
processing.
Intuitively, an SA testing criterion abstracts away not
interesting interactions. Referring to the Cham formal-
ism, an SA testing criterion naturally partitions the
Cham reaction rules into two groups: relevant interactions
(i.e., those ones we want to observe by testing)
and not relevant ones (i.e., those we are not interested
in). This suggests to consider an interpretation domain
D, where to map the signicant transformation rules
(i.e., the arc labels of the LTS), and a distinct element
, where to map any other rule.
Figure

3: A portion of the TRMCS LTS
We therefore associate to an SA testing criterion an obs-
function. This is a function that maps the relevant reaction
rules of the Cham SA description to a particular
domain of interest D. More precisely, we have:
The idea underlying the set D is that it expresses a
semantic view of the eect of the transition rules on the
system global state.
From LTS to ALTSs
We use the obs-function just dened as a means to derive
from the LTS an automaton still expressing all high
level behaviors we want to test according to the selected
SA testing criterion, but hiding any other unrelevant be-
haviors. The automaton is called an ALTS (for Abstract
LTS).
This is the LTS that is obtained by relabelling, according
to the function obs, each transition in R(S 0
), and by
minimizing the resulting automaton with respect to a selected
equivalence (trace- or bisimulation-based equiv-
alence), preserving desired system properties (as discussed
in [5]).
If we derive a complete path over an ALTS (see De-
nition 2.2), this quite naturally corresponds to the high
level specication of a test class of the SA (we give examples
in the next section). Therefore, the task of deriving
an adequate set of tests according to a selected
SA testing criterion is converted to the task of deriving
a set of complete paths appropriately covering the
ALTS associated with the criterion via an obs-function.
In an attempt of depicting a general overview of the ap-
proach, we have so far deliberately left unresolved some
concrete issues. Most importantly, what does it mean
concretely to look at the SA from a selected observation
point, i.e., which are meaningful obs-functions? And,
also, once an ALTS has been derived, how are paths
on it selected? Which coverage criterion could be ap-
plied? We will devote the next section to answer these
questions, with the help of some examples regarding the
TRMCS case study.
Considering the informal description of the TRMCS in
Section 2, because of obvious safety-critical concerns,
we may want to test the way an Alarm message
ows
in the system, from the moment a User sends it
to the moment the User receives an acknowledgement.
Casting this in the terms used in the previous section,
issues an Alarm msg
receives an Ack
issues an Alarm msg
obs (T receives an Ack
For any other T i , obs (T i

Figure

4: Alarm
ow: Obs-function
ReceiveAck1
ReceiveAck2
ReceiveAck1
ReceiveAck2
ReceiveAck1
A
ReceiveAck2

Figure

5: Alarm
the software architect may decide that an important
SA testing criterion is \all those behaviors involving the
ow of an Alarm message through the system".
From this quite informal specication, a corresponding
obs-function could be formally dened as in Figure 4. As
shown, we have included in the interpretation domain D
all and only the Cham transition rules that specically
involve the sending of an Alarm message by a User, or
the User's reception of an acknowledgement of the Alarm
message from the Router. Note that this information
is encoded, at the LTS level, in the arcs labels.
With reference to this obs-function, and applying reduction
and minimization algorithms (in this case we
have minimized with respect to trace equivalence, since
it preserves paths), we have derived the ALTS depicted
in

Figure

5 (the shaded circle represents the initial
state, that in this example also coincides with the only
nal one). This ALTS represents in a concise, graphical
way how the Alarm
ow is handled: after an Alarm is
issued (e.g., SendAlarm1), the system can nondeterministically
react with one of two possible actions (elaborat-
ing this Alarm and sending back an Acknowledgement
(ReceiveAck1) or receiving another Alarm message from
another User (SendAlarm2)).
Note the rather intuitive appeal of such a small graph
with regard to the (much more complex) complete LTS
(for the TRMCS it is one hundred times bigger). One
could be tempted to consider some rather thorough coverage
criterion of the ALTS, such as taking all complete
paths derivable by xing a maximum number of cycles
iterations. However, as we will see better in the next
section, each ALTS path actually will correspond to
sends the first Check msg
sends a further Check msg
sends the first Check msg
sends a further Check msg
obs every User has sent a Check msg
obs (T 21 some User has not sent a Check msg
For any other T i , obs (T

Figure

Check
ow: Obs-function
many concret test cases. Therefore, less thorough coverage
criteria seem more practical. In particular, we found
that McCabe's technique of selecting all basic paths [16]
oers here a good compromise between arc and path
coverage. A list of ALTS test paths derived according
to McCabe's technique is the following:
Let us consider, for example, Paths No. 2, 3 and 4.
These three paths are all devoted to verify that the
system correctly handles the consecutive reception of
two Alarm messages issued by two distinct Users. By
putting these three ALTS paths in the list, we explicitly
want to distinguish in the test plan the cases that: i)
each Ack message is sent rightly after the reception of
the respective Alarm message (Path3); or, the acknowledgements
are sent after both Alarms are received and
ii) in the same order of Alarm receptions (Path4); or
nally iii) in the opposite order (Path2). So the three
test classes are aimed at validating that no Alarm message
in a series of two is lost, whichever is the order they
are processed in.
Still considering the TRMCS, the software architect
could decide that also the Check
ow is worth testing.
Thus, in analogous way to what we have done for the
Alarm
ow, the Check
ow obs-function is derived in

Figure

6 and the corresponding ALTS is depicted in

Figure

7. It represents a dierent \observation" of the
TRMCS behavior.
We have reasoned so far in the hyphotetical scenario of
the TRMCS system being developed and of a software
architect that is deriving interesting architectural behaviors
to be tested. An alternative scenario could be
that the TRMCS is already functioning, and that one
CheckERR
CheckERR
CheckERR
CheckERR
CheckERR
CheckOK
CheckERR
CheckOK
CheckERR
I
A
F
G
CheckOK
CheckERR

Figure

7: Check
of the components is being modied, but we don't want
that this change aects the SA specication. We want
then to test whether the modied component still interacts
with the rest of the system in conformance to the
SA original description. In this case, the observation
point of the software architect will be \all the interactions
that involve this component". If, specically, the
component being modied is the Server, then the corresponding
obs-function is given in Figure 8. McCabe's
coverage criterion yields the following set of test classes:
This example evidences that even in deriving the basic
ALTS paths we do not blindly apply a coverage cri-
terion, but somehow exploit the semantics behind the
elements in D. For instance, consider Path5 above. If
we interpret it in light of McCabe's coverage criterion,
it is aimed at covering transition FRa2 from State A to
State C. The shorter path A C A would be equally good
for this purpose. But for functional testing this shorter
path is useless, because it would be perfectly equivalent
to the already taken Path2 A B A: both paths in fact
test the forwarding of one Alarm message to the Server.
Therefore, to cover the transition from A to C we have
instead selected the longer path A B A C A that serves
the purpose to test the consecutive forwarding of two
Alarms.
From Router
obs From Router
To Router
To Router
obs (T 21 From Router
For any other T , obs (T

Figure

8: Component Based: Obs-function
FRno
FRno FRno
FRno
A

Figure

9: Component Based: ALTS
CATION
ALTS paths specify functional test classes at a high abstraction
level. One ALTS path will generally correspond
to many concrete test cases (i.e., test executions
at the level of the implemented system).
It is well-known that several problems make the testing
of concurrent systems much more di-cult and expensive
than that of sequential systems (for reasons of space we
do not discuss these problems in depth here; see, e.g.,
[9]). Said simply, a trade-o can be imagined in general
between how tightly is the test specication of an event
sequence given, and how much eort will be needed
by the tester to force the execution of that sequence.
The point is that the tester, on receiving the high level
test specications corresponding to ALTS paths, could
choose among many concrete test executions that conform
to them. For example, considering Path2 A B D
B A on Fig. 5, a possible test execution can include
the sending of an Alarm message from User1 immediately
followed by the sending of an Alarm message from
User2; another test execution could as well include, between
the two Alarm messages, the Router reception
of other messages, e.g., a Check or a Clock, and still
conform to the given high level test specication.
This
exibility in rening test specications descends
from the fact that to derive the ALTS from the complete
LTS we have deliberately abstracted away transitions
not involving the Alarm
ow from and to a User.
In other words, more concrete executions, however dif-
ferent, as long as they conform to Path2, all belong to a
same test class according to the selected SA-based test
criterion (obs-function).
But after an ALTS-based list of paths has been cho-
sen, we can go back to the complete LTS and observe
what the selected abstraction is hiding, i.e., we can precisely
see on the SA LTS which are the equivalence
assumptions 1 behind ALTS paths (test classes) selection

This is a quite attractive feature of our approach for SA-
based test class selection. When functional test classes
are derived ad-hoc (manually), as is often the case
for the high level test stages, equivalence assumptions
those test classes rely upon remain implicit, and are
hardly recoverable from the system specication. In our
approach, rst an explicit abstraction step is required
(ALTS derivation). Second, going back from the ALTS
to the complete LTS, we can easily identify which and
how many LTS paths fulll a given ALTS path.
We can better explain this by means of an example.
Considering the ALTS for the Alarm
ow (Fig. 5), State
B is equivalent (under the test assumptions made)
roughly to forty states in the complete LTS (of course,
we can automatically identify all of them). Not only,
but there are more valid LTS subpaths that we could
traverse to reach each of these forty states. The valid
subpaths for this example are all those going from the
initial state S 0 of the LTS to any of the forty states equivalent
to state B of the ALTS, without including any
of the transformation rules in the domain D dened for
the Alarm
ow obs-function, except for the last arc that
must correspond to the transformation rule T 11 . All of
these (many) subpaths would constitute a valid rene-
ment of the abstract SendAlarm1 transition in Path2.
As such a renement should be applied to each state and
each arc of the ALTS paths, it is evident then how the
number of potential LTS paths for one ALTS path soon
becomes huge. We cannot realistically plan test cases
for all of them; so the pragmatic question is: how do
we select meaningful LTS paths (among all those many
rening a same ALTS path)? We don't believe that a
completely automatic tool, i.e., a smart graph processing
algorithm, could make a good choice. There are not
only semantic aspects of the functional behavior that a
tool could not capture, but also several non-functional
1 The term \equivalence"
here refers to its usual meaning in the testing literature, i.e.,
it denotes test executions that are interchangeable with respect
to a given functional or structural test criterion, and not to the
more specic trace/bisimulation equivalence used so far for graph

Figure

10: An LTS test path
factors to take into account. What we prospect, there-
fore, is that the software architect, with the indispensable
support of appropriate graphical tools and processing
aids, can exploit on one side his/her semantic
knowledge of the SA dynamics to discern between LT-
S paths that are equivalent with respect to an ALTS
abstraction. On the other side, he/she will also take
into account other relevant factors, not captured in the
SA description, such as safety-critical requirements, or
time and cost constraints. Thus we nally expect that
the software architect produces from the list of ALTS
paths a rened list of LTS paths, and give this list to
the tester as a test specication for validating system
conformance to SA.
In Fig. 12, for instance, we show an LTS path that is
a valid renement of Path2 for the Alarm
ow ALT-
S. This example is the shortest path we could take to
instantiate the ALTS path, in that it only includes indispensable
TRMCS transformation rules to fulll the
path. We precise that S 15 (lled in light gray) in particular
is the state equivalent to State B of the Alarm
ow ALTS (note in fact that the entering arc is labelled
11). Another of the forty LTS states equivalent to B is
Fig. 3). There is a semantic dierence
between S 15 and S 159 that could be relevant for integration
testing purposes. Before reaching S 159 , i.e., before
User1 sends an Alarm, User2 can send a Check message,
while this is never possible for any of the LTS subpaths
reaching S 15 . We could see this from analyzing the state
information that is associated with LTS nodes. In the
renement of Path2, the software architect could then
decide to pick one LTS path that includes S 159 in order
to test that a Check from another user does not interfere
with an Alarm from a certain user.
6 CONCLUSIONS
The contribution of this paper consists of an approach
to the use of the architectural description of a system
to dene test plans for the integration testing phase of
the system implementation. The approach starts from a
correct architectural description and relies on a labelled
transition system representation of the architecture dynamics

By means of an observation notion the software architect
can get out of the dynamic model suitable abstractions
that re
ect his/her intuition of what is interesting
or relevant of the system architectural description with
respect to a validation step. To be eective this step
relies on the software architect judgement and semantic
knowledge of the SA functional and non-functional
characteristics.
In summary, the proposed approach consists of the following
steps:
1. the software architect selects some interesting SA
testing criteria;
2. each SA testing criterion is translated into an obs-
in some case, a criterion could also identify
several related obs-functions;
3. For each obs-function, an ALTS is (automatically)
derived from the global LTS corresponding to the
SA specication;
4. On each derived ALTS, a set of coverage paths is
generated according to a selected coverage criteri-
on. Each path over the ALTS corresponds to the
high-level specication of a test class;
5. For each ALTS path, the software architect, by tool
supported inspection of the LTS, derives one or
more appropriate LTS paths, that specify more rened
transition sequences at the architectural level.
Our approach allows the software architect to move
across abstractions in order to get condence in his/her
choices and to better select more and more rened test
plans. It is worth noticing that in our approach a test
plan is a path, that is not only a sequence of events (the
labels on a path) but also a set of states which describe
the state of the system in terms of the single state com-
ponents. This is a much more informative test plan with
respect to the one that could be derived from e.g., the
requirements specications. In fact, using the SA LTS,
we also provide the tester with information about state
components that can be used to constrain the system
to exercise that given path.
Related Work
Lot of work has been devoted to testing concurrent and
real-time systems, both specication driven and implementation
based [9, 15, 8, 1]. We do not have room
here to carry out a comprehensive survey; we will just
outline some main dierences with our approach. These
works addressed dierent aspects, from modelling time
to internal nondeterminism, but all focus on unit test-
ing, that is they either view the concurrent system as
a whole or specically look at the problem of testing a
single component when inserted in a given environmen-
t. Our aim is dierent, we want actually to be able to
derive test plans for integration testing. Thus although
the technical tools some of these approaches use are obviously
the same of ours (e.g., LTS, abstractions, event
sequences), their use in our context is dierent. This
goal dierence emerges from the very beginning of our
we work on an architectural description that
drives our selection of the abstraction, i.e., the testing
criterion, and of the paths, i.e., the actual test classes.
Our approach of dening ALTS paths for specifying high
level test classes has lot in common with Carver and
Tai's use of Sequencing Constraints for specication-
based testing of concurrent programs [9]. Indeed, sequencing
constraints specify restrictions to apply on the
possible event sequences of a concurrent program when
selecting tests, very similarly to what ALTS paths do for
a SA. In fact, we are currently working towards incorporating
within our framework Carver and Tai's technique
of deterministic testing for forcing the execution of the
event sequences (rened LTS paths) produced with our
approach.
As far as architectural testing is concerned, the topic
has raised interest and received a good deal of attention
in recent years [19, 6, 20]. Our approach indeed stems
from this ground. Though, up to our knowledge, besides
our project no other attempt at concretely attacking the
problem has been pursued so far.
The Future
Our aim is to achieve a usable set of tools that would
provide the necessary support to our approach. So far
we have experimented our approach on the described
case study of which a running Java prototype exists.
The way we did it was not completely automatically
supported with respect to the ALTS denitions, the
criterion identication and path selection. As tool support
we could rely on a LTS generator starting from the
Cham description, which also allows for keeping track
of the state and arc labels. Work is ongoing to generalize
it to ALTS generation and to implement a graphical
front-end for Cham descriptions. We denitely believe
that the success of such an approach heavily depends on
the availability of simple and appealing supporting tool-
s. Our eort goes in two directions, on one side we are
investing on automating our approach and we would also
like to take advantage of other existing environments
and possibly integrate with them, e.g. [13, 10], on the
other we are involved in more experimentation. The
latter is not an easy job. Experimenting our approach
requires the existence of a correct architectural description
and a running implementation. The case study presented
here could be carried out since the project was
entirely managed under our control, from the requirements
specication to the coding. This is obviously not
often the case. The results we got so far are quite satisfactory
and there are other real world case studies we
are working on at the moment. For them we have already
a running implementation and we have been asked
to give a model of their architectural structure. We are
condent these will provide other interesting insights to
validate our approach.



--R

Design of a Toolset for Dynamic Analysis of Concurrent Java Programs.

Software Architecture in Practice.
The Chemical Abstract Machine.

An Approach to Integration Testing Based on Architectural Descriptions.
Cots integration: Plug and pray?
A Practical and Complete Algorithm for Testing Real-Time Systems
Use of Sequencing Constraints for Speci

Uncovering Architectural Mismatch in Component Be- havior
Architectural Why reuse is so hard.
The Project.
Formal Speci
Generating Test Cases for Real-Time Systems from Logic Speci cations
A Complexity Measure.
Foundations for the Study of Software Architecture.
"http://www.rational.com/uml/index.jtmpl"
Software testing at the architectural level.

Software Architecture: Perspectives on an Emerging Discipline.
Component Software.
--TR
The chemical abstract machine
Foundations for the study of software architecture
The concurrency workbench
Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model
Generating test cases for real-time systems from logic specifications
Software architecture
Software testing at the architectural level
Component software
Software architecture in practice
Use of Sequencing Constraints for Specification-Based Testing of Concurrent Programs
Uncovering architectural mismatch in component behavior
COTS Integration
Architectural Mismatch
A Practical and Complete Algorithm for Testing Real-Time Systems
An approach to integration testing based on architectural descriptions

--CTR
Mauro Cioffi , Flavio Corradini, Specification and Analysis of Timed and Functional TRMCS Behaviours, Proceedings of the 10th International Workshop on Software Specification and Design, p.31, November 05-07, 2000
Myra B. Cohen , Matthew B. Dwyer , Jiangfan Shi, Coverage and adequacy in software product line testing, Proceedings of the 2006 workshop on Role of software architecture for testing and analysis, p.53-63, July 17-20, 2006, Portland, Maine
Holger Giese , Stefan Henkler, Architecture-driven platform independent deterministic replay for distributed hard real-time systems, Proceedings of the 2006 workshop on Role of software architecture for testing and analysis, p.28-38, July 17-20, 2006, Portland, Maine
Antonia Bertolino , Paola Inverardi , Henry Muccini, An explorative journey from architectural tests definition down to code tests execution, Proceedings of the 23rd International Conference on Software Engineering, p.211-220, May 12-19, 2001, Toronto, Ontario, Canada
Luciano Baresi , Reiko Heckel , Sebastian Thne , Dniel Varr, Modeling and validation of service-oriented architectures: application vs. style, ACM SIGSOFT Software Engineering Notes, v.28 n.5, September
Henry Muccini , Antonia Bertolino , Paola Inverardi, Using Software Architecture for Code Testing, IEEE Transactions on Software Engineering, v.30 n.3, p.160-171, March 2004
Hong Zhu , Lingzi Jin , Dan Diaper , Ganghong Bai, Software requirements validation via task analysis, Journal of Systems and Software, v.61 n.2, p.145-169, March 2002
Paola Inverardi, The SALADIN project: summary report, ACM SIGSOFT Software Engineering Notes, v.27 n.3, May 2002
labelled transition systems;functional test plans;software achitectures;integration testing