An approach to architectural analysis of product lines.
This paper addresses the issue of how to perform architectural analysis on an existing product line architecture. The con tribution of the paper is to identify and demonstrate a repeatable product line architecture analysis process. The approach defines a good product line architecture in terms of those quality attributes required by the particular product line under development. It then analyzes the architecture against these criteria by both manual and tool-supported methods. The phased approach described in this paper provides a structured analysis of an existing product line architecture using (1) formal specification of the high-level architecture, (2) manual analysis of scenarios to exercise the architecture's support for required variabilities, and (3) model checking of critical behaviors at the architectural level that are required for all systems in the product line. Results of an application to a software product line of spaceborne telescopes are used to explain and evaluate the approach.
INTRODUCTION
A software product line is a collection of systems that
share a managed set of properties that are derived from
a common set of software assets [4]. A product line
approach to software development is attractive to most
organizations due to the focus on reuse of both intellec-
This research was performed while this author was a visiting
researcher at the Jet Propulsion Laboratory.
y This author supported in part by a NASA/ASEE Summer
Faculty Fellowship.
z Contact Author.
x Mailing address: Dept. of Computer Science, Iowa State Uni-
versity, 226 Atanaso Hall, Ames, IA 50011-1041.
tual eort and existing tangible artifacts. The systems
or \derivatives" in a software product line (e.g., software
based on the product line) usually share a common ar-
chitecture. For a new product line, many alternative
architectures are designed according to the requirement
specications and one is selected as the \baseline" or
\core" for future systems. For a product line that leverages
existing systems, an architecture may already be in
place with organizational commitment to its continued
use.
This paper addresses the issue of how to perform architectural
analysis on an existing product line archi-
tecture. The contribution of the paper is to identify
and demonstrate a repeatable product line architecture
analysis process. Throughout the paper, application to
a software product line of spaceborne telescopes is used
to explain and evaluate the approach. The approach
denes a \good" product line architecture in terms of
those quality attributes required by the particular product
line under development. It then analyzes the architecture
against these criteria by both manual and tool-supported
methods.
This paper demonstrates the analytical value of specifying
an existing architecture with an Architectural Description
Language (ADL), both in terms of identifying
architectural mismatches with the product line and in
terms of providing a baseline for subsequent automated
analyses. The ADL model is then used to manually exercise
the architecture in order to measure how each of
a set of selected scenarios that capture the required attributes
(e.g., modiability, fault tolerance) impacts the
architecture. We found that this technique was particularly
eective at verifying whether or not the architecture
supported planned variabilities within the product
line.
Further verication of the architecture involves automated
tool support to analyze key, common behaviors.
We were particularly interested in the adequacy of the
fault-tolerant behavior of a critical data interface common
to all systems. Model checking of the targeted
behaviors allows demonstration of the consequences of
some architectural decisions for the product line.
The phased approach described in this paper provides a
structured analysis of an existing product line architecture
using: (1) architectural recovery and specication,
(2) manual analysis of scenarios to exercise architectural
support for required variabilities, and (3) model checking
of critical behaviors at the architectural level that
are required for all systems in the product line.
The rest of the paper is organized as follows. Section 2
provides background relating to software architecture,
product lines, and the interferometer application. Section
3 describes the three-step approach outlined above
in greater detail. Section 4 presents and discusses the
results from the manual and tool-supported analyses.
Section 5 brie
y describes related work. Section 6 offers
concluding remarks and indicates some directions
for future research.
This section describes background material in the areas
of software architectures, software product lines, and
interferometry.
2.1 Software Architectures
A software architecture describes the overall organization
of a software system in terms of its constituent ele-
ments, including computational units and their interrelationships
[21]. In general, an architecture is dened
as a conguration of components and connectors. A
component is an encapsulation of a computational unit
and has an interface that species the capabilities that
the component can provide. Connectors, on the other
hand, encapsulate the ways that components interact.
A conguration of components interconnected with connectors
determines the topology of the architecture and
provides both a structural and semantic view of a sys-
tem, where the semantics are provided by the individual
specications of the components and connectors.
Another important concept in the area of software architectures
is the concept of an architectural style. An
architectural style denes patterns and semantic constraints
on a conguration of components and connec-
tors. As such, a style can dene a set or family of systems
that share common architectural semantics [18].
For instance, a pipe and lter style refers to a pipelined
set of components whereas a layered style refers to a
set of components that communicate via hierarchies of
interfaces. The distinction between architectural style
and architecture is an important concept throughout
the work described here. As one would expect, all the
systems in our example product line share a base architectural
style and a set of shared software components
that are organized and communicate in certain
prescribed manners. However, there are architectural
variations among the systems regarding the number of
components and connectors, with some systems replicating
portions of the baseline reference architecture in
their individual architectures.
2.2 Product Lines
Bass, Clements, and Kazman dene a software product
line as \a collection of systems sharing a managed set of
features constructed from a common set of core software
assets" [4]. These assets typically include a base architecture
and a set of shared software components. The
software architecture for the product line displays the
commonality that the systems share and provides the
mechanisms for variability among the products. The
systems in the product line are referred to as members
or derivatives of the baseline architecture or architectural
style.
2.3 Interferometers
The product line of interest in this work is a set of interferometer
projects under development by NASA's Jet
Propulsion Laboratory. An interferometer, in this con-
text, is a collection of telescopes that act together as a
single, very powerful instrument. Interferometers will
be used to explore the origins of stars and galaxies and
to search for Earth-like planets around distant stars.
An interferometer combines the starlight it collects from
telescopes in such a way that the light \interferes" or
interacts to increase the intensity and increase the precision
of the observation.
Three spaceborne interferometers are either under development
or planned for launch in the next eleven
years, with additional formation-
ying interferometers
envisioned for subsequent years [13, 19]. Two ground-based
interferometers in the product line are currently
operational, with at least two more planned.
Among the components shared by the interferometer
systems and discussed in this paper are the Delay Line,
the Fringe Tracker, and the Internal Metrology. The
Delay Line component compensates for the dierence
in time between the arrival of starlight at the separate
mirrors. The Fringe Tracker component provides constant
feedback to the Delay Line regarding needed adjustments
to maintain peak intensity of the fringe (pat-
terns of light and dark bands produced by interference
of the light). The Internal Metrology component provides
input to the Delay Line regarding small changes in
distances among parts of the interferometer that must
be included in its calculations.
In previous work, we analyzed commonalities and variabilities
of the JPL interferometry software project [17].
The software in these interferometers has a high degree
of commonality with a managed set of shared features
built from core software components [3]. A group of
developers at JPL with a strong background in interferometer
software provides reusable, generic software
components to the interferometer projects.
Extensive documentation of the requirements and design
for these software components, as well as C code
for the component prototypes, were available for our
analyses. In addition, we used whatever project-unique
documentation was available. Predictably, more documentation
exists for projects farther along in their de-
velopment. System descriptions are available for all the
missions; software requirements and design documents
are still high-level and informal for later missions; and
code is not yet available for any of the spaceborne interferometers

In this section we describe the approach that was used
to analyze the interferometer software product line. Section
3.1 summarizes the overall process used during the
project and introduces the architectural recovery, dis-
covery, and specication of the existing product line;
Section 3.2 describes the manual analysis process used
to measure quality attributes related to product lines;
and Section 3.3 describes the behavioral analysis performed
using automated tool support.
3.1 Process
A software architecture is one key required element that
should be present in order to analyze software for product
line \tness" since it is the architecture, above any
other artifact, that is being reused. One of the properties
of this particular product line is that although
an architecturally-based product line approach was not
used in the construction of the software, the artifacts
(both conceptual and physical) were being used in a
manner indicative of a product line approach. As such,
several software products had been developed or were
in the process of being developed based on the core architecture

For the interferometer software, we performed three
architecture-centered steps: 1) architecture recovery,
discovery, and specication, 2) manual architectural
analysis, and assisted architectural analysis.
The rst step, architecture recovery, discovery, and
specication, was used in order to facilitate two goals:
1) to familiarize the analysts with the problem domain
and implemented solution, and 2) to support construction
of a software architectural representation that was
consistent with current standards and vocabulary. For
this step, documentation, source code, and developer
communication was used to assist in the construction
of a reasonable specication of the software architec-
ture. The resulting architecture specication, shown
graphically in Figure 1, formed the basis for all subsequent
analyses, both manual and automated. In the
diagram, hardware components are shown as shaded
and round rectangles while the software components are
shown as sharp rectangles. The connectors, represented
by lines between components, depict the relationships
between components in the architecture. This particular
diagram represents the software that exists within
an \arm" of an interferometer, where a standard interferometer
has two arms.
The software architecture recovered in the rst step
formed the baseline or core architecture for the interferometer
product line. The assumption in this step
(later conrmed by the analysis described below) was
that, although changes in software code are frequent,
signicant modications to the software architecture are
infrequent. As such, a reasonable, initial view of the
software architecture can be derived from existing design
documents and later modied as new information
is recovered.
To aid in the validation of the models constructed in the
rst step, we consulted with the project engineers to determine
the accuracy of the architecture as documented
in comparison with how the project engineers viewed
the architecture. This information was instrumental in
constructing a more accurate view of the interferometer
architecture.
To further validate the accuracy of the core architecture
and its scalability to the existing and planned products
in the product line, we compared the core to the individual
product line derivatives. To facilitate the com-
parison, we developed a table (excerpted in Table 1) as
a medium for communication with several developers.
In the table, each row represents a dierent component
that could be potentially present in an interferometer
system. The columns represent the dierent derivatives
that are currently either being developed or are planned
for deployment over the next several years. This table
served as a simple way to represent features of the architecture
that are common in behavior to each potential
derivative, but can potentially vary in multiplicity
based on the number of potential starlight collectors or
\arms". For each derivative, we consulted with developers
to verify that the number of components listed in
the table was consistent with individual mission plans.
Components Core D1 D2 D3
Baselines
Arms
Delay Line 2 2 6-8 4
Fringe Tracker 2 1 3-4 2
Instrument
User Interface

Table

1: Comparison Matrix
The next phase of the approach was to perform a number
of analyses in order to help determine whether the
architecture was amenable to a product line development
approach. The primary goal was to determine

Figure

1: Interferometer Software Architecture
if certain, desirable quality attributes present in most
product line architectures were also present in the interferometer
architecture. In addition, we were interested
in performing behavioral analysis in order to study how
behavioral interactions in the core architecture might
potentially impact derivatives.
The remainder of this section is divided into Manual
Architectural Analysis and Analysis Using Automated
Support Tools. One of the interesting aspects of this
bifurcation of the analysis along manual and automated
analysis lines is that the quality attributes that fall into
the class of variabilities seem to be supported only by
manual analysis techniques whereas the commonalities
seem to be supported in some manner by automated
tools. As the work described here is only a single point
of data, we do not attempt to explain the observation,
although we do nd it interesting and recognize the need
for further investigation along these lines.
3.2 Manual Architectural Analysis
Bass, Clements, and Kazman divide quality attributes
into those that can be discerned by observing the system
at runtime and those that cannot [4]. Of the ones that
cannot be observed at runtime, modiability is the key
property required by the interferometer product line.
Modiability, according to Bass et al., \may be the quality
attribute most closely aligned to the architecture of
a system," and, as such, is a good way to evaluate the
architecture. Bass et al., identify four categories of mod-
iability: Extensibility or changing capabilities, Deleting
capabilities, Portability (adapting to new operating
environments), and Restructuring.
To evaluate the modiability of the interferometry product
line architecture, we extracted examples of each of
the four categories of modiability from the requirements
specications of four systems currently planned
or under development. As such, we are using a product-oriented
view of a product line, which is consistent with
other product line approaches such as the PuLSE technique
[6]. We then manually analyzed the eect of each
change on the specied architecture. This interferometer
system was chosen because its requirements were
well documented and individual product line derivatives
had requirements that facilitated the study of the mod-
iability of the baseline architecture.
The approach used is very similar to SAAM [14], a
scenario-based method for analyzing architectures. A
scenario is a description of an expected use of a spe-
cic product line. SAAM also tests modiability, e.g.,
by proposing specic changes to be made to the sys-
tem. The advantage of the scenario-based approach is
that it moves the discussion from a rather amorphous,
high-level of generality (\modiability") to a concrete,
context-based level of detail particular to the product
line (\adds pathlength feedforward capability").
The interferometer product line has signicant requirements
that fall under each of the four categories of mod-
iability as follows.
Extensibility. Potential extensibility variations include
new algorithms (e.g., a dierent fringe-search algo-
rithm) and added features (e.g., pathlength feedforward,
internal metrology).
Deletions. Deletions involve changes required to support
the incremental capabilities of the various testbeds
and prototypes. For example, testbeds use pseudostar
input rather than actual starlight, whereas
the science interferometers use direct starlight as input.
Attribute Scenario Type Example Scenario Eect on Architecture
Extensibility Change algorithm Algorithm for fringe search changed No change required
Extensibility Add feature Pathlength feedforward capability No style change; additional connectors
Extensibility Add feature Internal metrology added No style change; additional components
and connectors
Deletion Delete input Use pseudostar rather than actual No change required
Portability Change HCI device Shift handheld paddle to remote device Connector unchanged
Portability Change sensor Starlight detector hardware changed Interface intact; component
implementation changes
Portability Add input units More starlight collectors No style change; \duplicate"
existing pieces; see discussion
Portability Add processors Distribute targeting computation No style change;
change within components
Restructuring Optimize for reuse Proposed switch to CORBA Might change style and connectors

Table

2: Analyzing the Architecture's Modiability via Scenarios
Portability. Portability changes are widespread, since
dierent interferometers in the product line will have
dierent numbers of starlight collectors, mirrors, tele-
scopes, etc. In addition, dierent systems will use different
starlight detector hardware and dierent operator
interfaces (e.g., a handheld paddle for the testbeds,
remote commandability for the
ight units). The interferometer
software will run on multiple processors, with
the number of processors being a variability among the
systems.
Restructuring. Restructuring changes that are not included
in the other categories are limited. A proposed
change to optimize for reuse is the only scenario used in
the architectural evaluation.
As shown in Table 2, nine representative changes were
selected to evaluate the modiability of the architecture:
three extensibility changes, one deletion, four portability
changes, and one restructuring. All these changes
are variabilities in the product line specication, i.e.,
not common to all the interferometers. The approach
was to use these representative scenarios to exercise and
evaluate the baseline architecture. A discussion of the
results of the application to the baseline interferometer
architecture and, more generally, of the advantages
and disadvantages of this approach can be found in Section
4.
3.3 Analysis using Automated Support Tools
One of the goals of this project was to determine the
extent to which automated support tools could be used
to aid in the analysis of a product line software archi-
tecture. Specically, it was our intent to identify tools
that could be adopted with little overhead, while still
satisfying the objective of formally analyzing the architectural
behavior. This meant that the selected tools
should have a reasonable level of support and documentation

The following tasks were identied as the critical path
for achieving our automated analysis objectives: (1) Architecture
specication in an ADL, (2) Formal speci-
cation of behavior, and (3) Analysis of behavior. The
approach used in the selection of notations and tools is
described here. The results of the tool-supported analysis
are described and discussed in Section 4.
The ACME [9] ADL and ACMEStudio [1] support tool
were chosen for the specication of the architecture.
ACME is an architecture description language that has
been used for high-level architectural specication and
interchange [9]. ACME contains constructs for embedding
specications written in a wide variety of existing
ADLs, making it extensible to both existing and future
specication languages. ACME is supported by an architectural
specication tool, ACMEStudio, that supports
graphical construction and manipulation of software
architectures. Analysis of the design documents
yielded the software architecture depicted in Figure 1.
In addition to recovering and specifying the high-level
view of the interferometer architecture, behaviors of
component interactions were derived from existing design
documentation. Specically, we used information
found in design documents to help construct a formal
specication of component interactions in the interferometer
software. The Wright ADL was used for the
formal specication of behavior. Wright [2] is an ADL
based on the CSP specication language [11]. The primary
focus of the Wright ADL is to facilitate the spec-
ication of connector, role, and port semantics. In addition
to being based on the well-established CSP se-
mantics, existing Wright tools support the ACME ADL,
thus providing a clean interface with the existing ACME
specication.
The nal step involved using the formal specications
to analyze behavior of various aspects of certain interactions
between components in the architecture. To
increase condence in the validity of the formal anal-
ysis, source code from the interferometer components
planned for reuse was informally reverse engineered to
determine whether properties observed in the formal
specication were present in the implementation. The
Model Checker was used to further analyze behaviors
of interest. Spin [12] is a symbolic model checker
that has been used for verifying the behavior of a wide
variety of hardware and software applications. Promela,
the input specication language for Spin, is based on Di-
jkstra's guarded command language as well as CSP.
The primary reason for choosing each of the notations
and tools listed above was a pragmatic one. The notations
are related either via direct tool interchange
support (as is the case between ACME and Wright) or
by some semantic foundation (e.g., CSP foundation for
Wright and Promela). As such, the ACME framework
(including Wright specications) could be used for specifying
the interferometer architecture, and verication
using Spin could follow naturally with a small amount
of translation of the embedded Wright into Promela.
In this section we describe the results of applying the approach
described in Section 3. Specically, Section 4.1
discusses the issues that were encountered during the recovery
and specication of the interferometer architec-
ture. Sections 4.2 and 4.3 describe our eorts to manually
and semi-automatically analyze the architecture,
respectively.
4.1 Architecture Specication
As shown in Figure 2, the original documentation for
the interferometry software depicts the architecture using
a layered style. However, during the analysis and
subsequent specication of the architecture, it was discovered
that the architecture, as documented, exhibited
\layer bridging" properties whereby non-adjacent layers
in the architecture communicated, thus \bridging" or by
passing intermediate layers. In addition, sibling components
located in a layer were found to communicate,
contrary to the layered style. Consequently, the high-level
interferometer architecture was re-specied in a
style that was consistent with the services and behaviors
described in lower-level documentation. The resulting
architecture, shown in Figure 1, more accurately spec-
ied the architecture as a heterogeneous architecture
with a collection of communicating processes as well as
a constrained pipe and lter interaction between the
Instrument CDS and all of the other remaining components

4.2 Manual Analysis Results
The baseline architecture shows the commonality that
exists among the members of the product line. Each
member of the product line uses this architecture or an
adaptation of it. Thus, nothing in the architecture can
constrain the anticipated variabilities among the members

As mentioned earlier, one of the key quality attributes
for the interferometer product line is modiability. It
Gizmo Prototypes
Gizmo Design Pattern
Core Services
Configuration
Controller
Modulation
Framework
Command
Framework
Command &
Telemetry
Framework
Engine
Framework
Framework
Gizmo
Inter-processor
Communication
Periodic Task Scheduler Hardware Framework
Pointer
Angle
Instrument
CDS
Delay Line Fringe Tracker Star Tracker

Figure

2: Original Core Architecture
was with the goal of exercising the product line architecture
that we considered the eect on the architecture
of each of nine representative modiability scenarios, all
drawn from the documentation.
Eect on architecture of scenarios

Table

2 summarizes the results of our manual analysis
of the product line architecture for modiability via the
nine scenarios described in Section 3.2. Column 1 indicates
to which of the four categories of modiability each
scenario belongs (Extensibility, Deletion, Portability, or
Restructuring). Column 2 is a high-level description of
the scenario (e.g., \Change algorithm", \Add feature",
\Change sensor", etc. Column 3 brie
y describes the
particular scenario. Column 4 indicates the eect of
that modiability scenario on the baseline architecture.
Of the nine scenarios, four involved no change to the
baseline architecture. These scenarios were: change of
algorithm, deletion of input, change of human-computer
interface device, and change of sensor device. Two
other scenarios, related to extensibility, require additional
connectors and, in one case, an additional component
not in the original architecture. However, these extensions
are relatively straight-forward and their scope
is easy to anticipate.
The other three scenarios require signicant changes to
the product line architecture, but the changes are not
visible at the level of the specied architecture. In one
case (add input units), implementation of the scenario
can involve adding \arms" (i.e., additional axes) to the
interferometer. This has no eect on the more detailed
core architecture (which represents a single axis), but
requires duplication/replication of connectors and components
on the baseline architecture, a signicant architectural
consequence. The scenario that distributes
the targeting computation over more processors can be
accommodated without change to the baseline architec-
ture. At the level of the model, there was no commitment
to implementation details such as number of
processors. The sole restructuring scenario, a possible
switch to CORBA, might change both the style and the
implementation of the connectors, and would require
further investigation.
Discussion
Locality of change. Most modiability scenarios
demonstrated good locality of change for the specied
architecture (i.e., involved changes that could be readily
scoped). The existence of an architectural specication
assisted in this eort. Most scenarios do not aect the
services required of other components.
Units of reuse. The units of reuse in the architecture
tended to be small. For example, a Delay Line is a
unit, but a Delay Line-Fringe Tracker-Star Tracker is
not. All Delay Lines have a high degree of common-
ality, and the interfaces between a single Delay Line
and a single Fringe Tracker are similar for all members
(the \portability layer"), but the number of Delay
Line-Fringe Tracker interfaces varies greatly among the
product line members. The architectural style was not
changed by the scenarios, but the number of connections
and, to a lesser degree, components, was changed.
There are many dierent cross-strappings possible and
a large amount of reconguration involved in meeting
the real-time constraints on the various missions. Having
small units of reuse may complicate verication and
integration of individual members (e.g., with regard to
contention, race conditions, starvation, etc.
Role of redundancy. Several of the scenarios involved
adding multiple, identical components or connectors.
However, these copies are not redundant, in the sense of
adding robustness, since they are all needed to achieve
the required performance. For example, if starlight
collectors are added, it is to increase the amount of
starlight that the interferometer can process in order
to meet requirements for detecting dim targets. Like-
wise, if processors are added, it is to meet requirements
for increasing the resolution capability of an interfer-
ometer. In this architecture, redundancy does not add
robustness for the most part; there are not spare units
or alternate data paths.
Performance. One of the unusual aspects of this application
is that the range and scope of the variabilities
tend to be non-negotiable. This is due to the very
tight performance and accuracy requirements on the interferometry
missions. For example, an upcoming in-
terferometer, the Space Interferometry Mission (SIM),
requires precision at the level of picometer metrology
and microarcsecond astrometry. To achieve this level
of precision, signicant real-time constraints exist with
limited
exibility to accommodate reuse concerns. Performance
requirements on each mission also drive the
choice of hardware, algorithms, and added capabilities.
The consequence for reuse is that in trade-os of modi-
ability vs. performance, performance wins.
Architectural style. Despite the range of variations
that aect the architecture (e.g., varying the number of
ports on a component, varying the number of instances
of a component), the interferometry project is committed
to keeping the architectural style stable. Most im-
portantly, this demonstrates itself in their maintaining
the commonality of the interfaces. The number of interfaces
is not constant among product line members,
but the interfaces themselves are relatively stable. Recognizing
the long timeline over which the product line
will extend (proposed launches from to 2020) and
the primacy of performance (with continuous improvement
of hardware and algorithms), the project has done
a good job of designing for evolvability.
Repeatable process. The manual analysis of the architecture
is a repeatable process that can be applied to
product lines. The process is as follows:
1. anticipated changes from available documentation
and project information. These anticipated
changes form product line variabilities that
the baseline architecture must accommodate.
2. Categorize the anticipated changes into modia-
bility categories (extensibility, deletion, portability,
restructuring).
3. Select and develop scenarios for each category. The
choice of scenarios is made to broadly challenge the
goodness of the architecture with regard to the four
modiability categories.
4. Evaluate the eect of each modiability scenario on
the baseline architecture. This gives a measure of
the goodness of the architecture with respect to the
anticipated variabilities for this product line.
4.3 Analysis Using Automated Support Tools
While the manual analysis addressed issues related directly
to the use of the interferometer architecture as
a product line, the automated analysis was primarily
of use for analyzing behavior viewed as common across
product line members. As such, any behavioral properties
(both positive and negative) discovered at the architectural
level were likely to be common to all members
of the product line.
Verication
A key element of the interferometer architecture was
the use of the \Target Buer" connector. This connec-
tor, both in the design and in the implementation, is a
non-locking buer used to communicate star targets to
the Delay Line component by several other components.
The Target Buer connector was viewed as a possible
concern, especially in light of the non-locking feature. It
was determined that behavior involving this connector
should be formally specied in order to study its impact
on the system.
There are several components that are either directly
or indirectly impacted by the non-locking nature of the
Target Buer connector: Target Sources, a Command
Controller, and a Target Generator component. The
Target Generator uses the values written to the Target
Buer by various Target Sources to compute a target
position for the interferometer. The Command Controller
provides control for the computation by enabling
or disabling the Target Sources. Target Sources write a
timestamped value to the Target Buer, with the timestamp
determining a time that the target value becomes
valid.
The Target Generator uses the following four-step sequence
for calculating the target position:
1. Promote waiting targets to active status if the current
time is greater than or equal to the timestamp
2. Read new targets from enabled target sources
3. Pend (assign to wait status) or activate new targets
based on timestamps
4. Compute the total target
The Wright specication of the interaction between the
Target Generator and the potential sources of data that
are written to the Target Buer is shown in Figure 3.
The Source specication models the fact that a source
internally decides whether or not to write a new value to
the Target Buer. Finally, the Target Generator specication
models the target-position algorithm described
above.
From the Wright specication, we constructed a
Promela specication, portions of which are found in

Figures

4 and 5, with the intention of determining
whether or not the following situations could occur.
Data From Disabled Sources. Is there a potential
for calculating the target position by using data from
sources that are currently disabled?
Best Data from Enabled Sources. Is there a potential
to calculate a target position by using data that is less
current than data currently in the target buer?
In the rst case, we were interested in determining
whether or not it was possible to generate a target position
by using data from inactive sources. In essence, a
target position input can be read by the Target Gener-
ator, pended due to the timestamp (e.g., the timestamp
indicates that the target value is not to be used until
some time in the future), and subsequently promoted
into use when the timestamp matches (or precedes) the
current time. The potential inconsistency occurs during
the time that the target is pended and is caused by the
fact that a source can be disabled during this waiting
period.
Style TargetComputation
Connector TargetBuffer
Role
Role
Reader.readtarget!x -> Glue [] Tick
Component Source
disable -> CDSCommand |~| Tick
Computation (CDSCommand.enable -> Generate) []
(CDSCommand.disable -> Computation) [] Tick
where { Generate = DLTarget.write!y -> Generate []
Generate [] Tick }
Component TargetGenerator
Input.read_target?x ->
_pend_or_activate ->
_compute -> Computation [] Tick )
Style
Configuration TargetComputationInstance
Instances
Attachments
src1.DLTarget as tb1.Writer
dl.Input as tb1.Reader
End Configuration

Figure

3: Subset of the Wright Specication
proctype source_1 (chan cds){
chan cmd;
chan ts = [1] of { int };
chan { int };
int active_or_inactive;
cds?cmd;
do :: (msgs_generated < max_msgs) &&
(active_or_inactive == true) ->
if :: run message(msg);
run timestamp(ts);
od

Figure

4: Promela Specication of Target Source
The second case involves the following situation. As be-
fore, a target from a source is read, potentially pended,
and eventually promoted. Because of the sequencing of
events, a new target value from the source can over-write
the recently promoted target and, based on the
timestamp, be valid for immediate use.
Using the Spin model checker, it was veried that
these situations do in fact exist. In order to determine
whether these cases were also present in the code, we
examined source les and were able to verify that the
proctype target_generator (chan valid){
int sum;
int v;
do :: (msgs_generated < max_msgs) ->
/* "activation/promotion" of
pended targets achieved
by maintaining previous
value of s1 or s2 */
/* read new targets from active target sources */
if :: (v ==
(v ==
/* check if pended or not and compute target*/
if :: (v >
if :: ((s1_ap <= now) && (s2_ap <= now)) ->
reset sum */
(msgs_generated >= max_msgs) -> break;

Figure

5: Promela Specication of Target Generator
situations, as documented and as specied with Wright,
did in fact exist in an early, pre-
ight version of the
source code.
In each of these cases, the use of a non-locking buer
coupled with the target-generator algorithm provided
the potential for intermittent values that are inconsistent
with the desired and current target. The interferometry
project engineers conrmed that the Spin
model checker accurately modeled the software behavior
in both situations. In the rst case, a target from a
currently disabled target source may still be activated.
In the second case, a newly received target with a less-
current timestamp can overwrite an active target. How-
ever, in neither case is the software behavior contrary
to intent, given the underlying assumptions about the
operational use of the software.
Discussion
The automated analysis of the interferometer architecture
using the Spin model checker was greatly facilitated
by the availability and use of the Wright and ACME
ADLs. In eect, by using this combination of tools, we
were able to use model checking in a manner that was directed
by the structure and behavior of a software archi-
tecture. That is, the software architecture specication
was used to direct the model checking activity by facilitating
identication of potentially interesting points
of interaction in the interferometer architecture. Given
the fact that any behavior observed in the architecture is
potentially replicated among all product line members,
we found that the approach was a good complement to
the manual analysis activities.
There is an extensive body of related work on product
lines, described brie
y in Section 2.2 and in more detail
in [17]. Our work builds on product family techniques
such as Commonality Analysis [3] and the FAST process
[22], which systematically model the required similarities
and dierences among family members. The architectural
implications of product line models have been
analyzed by Perry [20], by Gomaa and Farrukh [10], and
by researchers at SEI, among others [5]. To date, the
emphasis has been on developing architectures for new
product lines rather than on evaluating the architecture
of an existing product line, as is done here.
As described in Section 3.2, the Software Architecture
Analysis Method (SAAM) is a scenario-based method
for architectural assessment. A related architectural
analysis method is the Architecture Tradeo Analysis
Method (ATAM) [15]. This iterative method is based
on identifying a set of quality attributes and associated
analysis techniques that measure an architecture along
the dimensions of the attributes. Sensitive points in
an architecture are determined by assessing the degree
to which an attribute analysis varies with variations in
the architecture. In our approach, we focus on quality
attributes that are specic to product line architec-
tures. As such, the approach can be applied in either
the SAAM or the ATAM context.
Rapide [16] is a suite of techniques and tools that
support the use of executable architectural design languages
(EADLs). The toolset supports analysis of time-sensitive
systems from the early construction phase
(e.g., architecture denition) to analysis of correctness
and performance. In our work, the motivation for choosing
a particular technique was based on a desire to eventually
transfer the technology to the project engineers.
In addition, we were interested in interoperability with
other tools. As such, we found that the ACME ADL
and associated ACMEStudio tool presented the least
amount of educational overhead. ACME also had the
advantage of being able to embed other ADLs in its
specication. However, we recognize that several alternatives
such as Rapide exist and are investigating
the possibility of performing similar analyses with those
tools.
6 CONCLUSION
The work described here identies and demonstrates a
process for analysis of an existing product line archi-
tecture. The results of the architectural recovery and
discovery are captured in an ADL model to support
subsequent inquiries. The architecture is manually analyzed
against a set of representative scenarios that have
the required quality attributes. Further analysis of critical
behaviors at the architectural level uses automated
tools and model checking to evaluate the consequences
of architectural decisions for the product line. The application
of this combined approach to the interferometer
product line architecture resulted in some measurements
of both the
exibility and limits of its architectural
style that could assist the project.
Further work is planned in several areas. In previous
work we have used formal techniques for the reverse engineering
of program code [7, 8]. We plan to investigate
how reverse engineering can also be used to assist in the
recovery of product line assets from existing repositories
or collections of programs. This may involve consideration
of dierent analysis frameworks (e.g., Rapide)
that oer fully integrated environments and investigation
of Wright/Spin translations. We also plan to pursue
the relationship between product line commonali-
ties/variabilities and analysis techniques. The observation
here that quality attributes relating to variabilities
(e.g., modiability) seem best supported by manual
analysis techniques whereas commonality attributes are
best analyzed with automated tool support (e.g., model
checking) merits further study. Finally, we would like
to make more precise the role of architectural issues in
product line decision models.

Acknowledgments

We thank Dr. John C. Kelly for his continued support of this
work. We thank Dr. Braden E. Hines, Dr. Charles E. Bell,
and Thomas G. Lockhart for helpful discussions and explanations
regarding the reuse of interferometry software. Part
of the work described in this paper was carried out at the Jet
Propulsion Laboratory, California Institute of Technology,
under a contract with the National Aeronautics and Space
Administration. Funding was provided under NASA's Code



--R

Acmestudio: A graphical design environment for acme.
A Formal Basis for Architectural Connection.

Software Architecture in Practice.
A framework for software product line practice.
A systematic approach to derive the scope of software product lines.
Strongest Post-condition as the Formal Basis for Reverse Engineer- ing
A Speci
ACME: An Architecture Description Interchange Language.
A reusable architecture for federated client/server systems.
Communicating Sequential Processes.
The Model Checker Spin.



An Event-Based Architecture De nition Language
Extending the product family approach to support safe reuse.
Exploiting architectural style to develop a family of applications.

Generic architecture descriptions for product lines.
Software Architectures: Perspectives on an Emerging Discipline.
Software Product-Line Engineering
--TR
Communicating sequential processes
Software architecture
Defining families
A formal basis for architectural connection
The Model Checker SPIN
Strongest postcondition semantics as the formal basis for reverse engineering
Software architecture in practice
A systematic approach to derive the scope of software product lines
A specification matching based approach to reverse engineering
A reusable architecture for federated client/server systems
Software product-line engineering
Extending the product family approach to support safe reuse
Scenario-Based Analysis of Software Architecture
An Event-Based Architecture Definition Language
Generic Architecture Descriptions for Product Lines
Acme

--CTR
Robyn R. Lutz , Gerald C. Gannod, Analysis of a software product line architecture: an experience report, Journal of Systems and Software, v.66 n.3, p.253-267, 15 June
H. Conrad Cunningham , Yi Liu , Cuihua Zhang, Using classic problems to teach Java framework design, Science of Computer Programming, v.59 n.1-2, p.147-169, January 2006
Femi G. Olumofin , Vojislav B. Mii, A holistic architecture assessment method for software product lines, Information and Software Technology, v.49 n.4, p.309-323, April, 2007
software architecture analysis;software archtecture;product lines;interferometry software