Understanding Tradeoffs among Different
Architectural Modeling Approaches
Roshanak Roshandel
*
, Bradley Schmerl
†
, Nenad Medvidovic
*
, David Garlan
†
, Dehua Zhang
†
*
Computer Science Department
University of Southern California
Los Angeles, CA 90089, USA
†
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15213, USA
{roshande,neno}@usc.edu {schmerl,garlan,zhangd}@cs.cmu.edu
Abstract
Over the past decade a number of architecture descrip-
tion languages (ADLs) have been proposed to facilitate
modeling and analysis of software architecture. While
each claims to have various benefits, to date there have
been few studies to assess the relative merits of these ap-
proaches. In this paper we describe our experience using
two ADLs to model a system initially described in UML,
and compare their effectiveness in identifying system de-
sign flaws. We also describe the techniques we used for
extracting architectural models from a UML system de-
scription.
1. Introduction
A critical component of an engineering basis for soft-
ware architecture is the availability of notations for formal
architectural representation and analysis. Indeed, over the
past decade there has been considerable research into this
issue, leading to a large number of proposals for architec-
tural description languages (ADLs). Each ADL typically
provides some unique capabilities for modeling, together
with tools to carry out analyses of properties. For exam-
ple, one ADL may be suitable for code generation, while
another may be better suited for formal analysis with re-
spect to topology, interfaces, or interaction protocols.
Unfortunately, in the pantheon of architectural model-
ing approaches, it is often unclear what aspects of archi-
tectural design the different approaches focus on, how
they relate, and what benefits they can provide in increas-
ing the quality of a software system. Thus, when making
decisions about how to model a system, it is often hard to
determine the best approach to take, and whether the ef-
fort required in producing multiple models would provide
significant benefits.
A case in point is the role of modeling in the design of
SCRover, a mobile robot based on the Mission Data Sys-
tem (MDS) architectural style [6][7] from NASA’s Jet
Propulsion Laboratory (JPL), and built using the MDS
implementation framework. MDS is an architectural ap-
proach created by JPL to streamline the development of
software for space missions. SCRover was designed and
developed in collaboration with the MDS team and is suf-
ficiently complex to be indicative of typical autonomous
robot software used in NASA’s space missions. Addition-
ally, it is being used as a testbed for research by various
institutions into increasing the dependability of NASA’s
space software, through NASA’s High Dependability
Computing Project [16].
The SCRover project represents a typical approach to
developing MDS-based systems. The modeling lessons
learned can thus be applied to other MDS systems. Fur-
thermore, errors detected in the design of SCRover may
be indicative of the types of errors encountered in other
MDS-based systems.
The broad applicability of SCRover means that it is
also an attractive testbed for applying modeling technolo-
gies. SCRover was designed in the context of the MBASE
software process [21], which extensively employs UML.
The architectural nature of MDS makes SCRover an ideal
candidate for architectural modeling. Architectural as-
pects of SCRover are difficult to extract from the UML
documentation, and automated analysis of the documenta-
tion is not practical. Instead, peer-reviews are used to ana-
lyze SCRover’s design documentation.
In this paper we document our experience in using two
representative ADLs, Acme [9] and Mae [18], to model
SCRover. Both models were derived from the initial
MBASE UML design, but were developed independently
of each other, and focus on different aspects of the archi-
tecture. We describe how each approach used the
SCRover documentation to develop the respective archi-
tectural models and discuss the differences that resulted
from focusing on different aspects of the original docu-
mentation. We show how these differences led to the
automatic detection of distinct, but complementary,
classes of errors, and how automatic analysis afforded by
either ADL yields better results than peer-review of the
SCRover documentation for architectural defects.
The rest of this paper is organized as follows: Section 2
provides some background to software architectures and
Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04)
0-7695-2172-X/04 $ 20.00 © 2004 IEEE
architectural modeling, and introduces MDS and
SCRover. Section 3 describes the two approaches that we
used to model SCRover, discusses details of each ap-
proach, and the process of developing each model. In Sec-
tion 4, we evaluate the results of each approach using a
detailed classification of architectural defects. Sections 5
and 6 discuss lessons learned and future work.
2. Background
2.1. Software Architecture
While there are numerous definitions of software archi-
tecture [1][17][19], the basis of all of them is the notion
that an architecture describes a system’s gross structure
using one or more views. These views shed light on con-
cerns such as the system’s composition, its main pathways
of interaction, and the key properties of its parts. Further-
more, an architectural description ideally includes suffi-
cient information to allow analysis and critical appraisal.
At its core an ADL[14] typically represents an archi-
tectural model as a graph of interacting components (e.g.,
[5][9][15]). Nodes in the graph (the components) repre-
sent the principal computational elements and data stores
of the system: clients, servers, databases, etc. Arcs are
termed connectors, and represent the pathways of interac-
tion between the components, which can be realized in a
system by a complex base of middleware and distributed
systems support. To account for various behavioral prop-
erties of a system, elements in the graph can typically be
annotated with property lists, although the mechanisms for
this differ across ADLs. For example, properties associ-
ated with a connector might define its protocol of interac-
tion, or performance attributes (e.g., delay, bandwidth).
There are a number of benefits to constraining the de-
sign space for architectures by associating a style with the
architecture. An architectural style typically defines a set
of types for components, connectors, interfaces, and prop-
erties, and may include rules that govern how instances of
those types are composed. Requiring a system to conform
to a style has many benefits, including support for analy-
sis, reuse, code generation, and system evolution
[5][15][17][22]. Typically, analysis of an architectural
model cannot be defined rigorously without appeal to a
particular style, even if that style merely states that every
component must have certain properties.
2.2. Mission Data System (MDS)
The Mission Data System (MDS) [6][7] is a methodol-
ogy, an architectural style, and an implementation frame-
work designed and built by NASA’s JPL. It attempts to
capture decades of experience in developing space soft-
ware, and represents a product family approach to space
mission software. The goal of MDS is to bridge the con-
ceptual gap between scientists, system engineers, and
software developers. It also strives to provide a set of
tools and methodologies that enable development of reli-
able systems and that reduce development costs by pro-
moting reuse and preventing erroneous behaviors early in
the development life cycle.
The MDS design methodology offers a technique for
capturing data in terms of States, Commands, and Meas-
urements. Moreover, MDS component types include Con-
trollers, Estimators, Sensors, State-Variables, and Actua-
tors. Instances of these interact by manipulating or com-
municating data. A set of constraints that govern manipu-
lation and communication of the data among architectural
elements forms the MDS architectural style. The MDS
implementation framework offers implementation-level
abstractions that adhere to the MDS style. The framework
is a C++ library of approximately 250,000 lines of code
that provides over 35 reusable packages for common func-
tionality such as state-oriented control, event logging, time
services, data management, visualization, and units of
measurement.
2.3. SCRover
The SCRover project [2] is a collaborative effort by the
University of Southern California (USC) and JPL to de-
velop a campus public safety robot performing mission
scenarios representative of JPL’s planetary rover mis-
sions. It was designed and built using the MDS methodol-
ogy and implementation framework. In the version of
SCRover used in this report, its functionality includes
basic robot navigation and control capabilities such as
moving along a wall, turning as needed, and avoiding ob-
stacles. In addition, the robot reports images obtained by
its camera, range information, and sensor and battery
health data. The implementation includes over 3000 lines
of application-specific code in addition to the MDS
framework code.
The SCRover project is intended to serve as a testbed
for research and academic organizations to accelerate
software engineering technology maturity and transition in
the context of NASA’s High Dependability Computing
Project [16]. With this potential scrutiny in mind,
SCRover was designed carefully using the MBASE proc-
ess [3][21], with extensive documentation for require-
ments and design, and extensive use of design reviews.
3. Architectural Modeling for SCRover
The high-level architecture of SCRover is shown in
Figure 1. In accordance with the MDS architectural style,
each high level component shown in the figure will be
further refined into corresponding Controller, Estimator,
Adaptor, and State variable components, with connections
between them. These components and connectors interact
according to the stylistic constraints of MDS. The rest of
Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04)
0-7695-2172-X/04 $ 20.00 © 2004 IEEE
this section describes each of the three models of
SCRover and how the two architectural models were de-
rived from the UML models.
3.1. The MBASE-UML Modeling Approach
Initially, the architecture of the SCRover system was
designed by a research group at USC using a subset of
UML in the context of USC’s MBASE process [21].
MBASE offers a set of integrated models that capture
product, success, process, and property models of the
system under development. The MBASE process defines
an approach for negotiating requirements, capturing op-
erational concepts, building initial design models, assess-
ing project risks, and planning the life cycle. These as-
pects are captured in separate documents that are regularly
maintained to ensure their consistency.
MBASE’s Software and System Architecture Descrip-
tion (SSAD) is a 140-page document that uses a subset of
UML diagrams (use-case, class, and sequence diagrams)
to model the topology and interactions among different
SCRover‘s subsystems. The SSAD also models the proc-
ess for achieving the specified system goals. English
prose, tables, and other conventions are used to further
elaborate the functionality of the system. Specifically, the
SSAD focuses on the following aspects of system design:
• System Analysis elaborates the goals of the system, the
processes by which the goals may be achieved, and the
scenarios that describe these processes.
• Architectural Design describes the topology of the sys-
tem in terms of components and their interfaces (i.e.,
method signatures). It describes the components’ be-
haviors in English, and the system’s overall behaviors
using sequence diagrams. Use-cases model the manner
in which components are used in the system.
• Implementation Design further refines the components
in terms of class diagrams that specify the compo-
nents’ attributes and their provided interfaces. Opera-
tions are associated with interfaces, and are modeled in
terms of pre- and post-conditions captured in English.
The SSAD provides a starting point for understanding
a system’s structure and functionality. However, the lack
of formal semantics associated with UML manifests itself
in this process. Moreover, the use of English prose, al-
though descriptive, hampers effective modeling of the
system since automated support cannot be provided to
ensure the consistency and correctness of the specifica-
tion. Instead, peer-reviews of the documentation are per-
formed to ensure both its internal consistency, and its
compliance with the MDS architectural conventions.
In the context of our experience, the complexity of
SCRover and the underlying MDS architectural style, to-
gether with the informality of the SSAD, motivated us to
consider other modeling approaches that would enable
automatic analysis and help to reveal a broader class of
errors early in the development process.
3.2. The Acme Modeling Approach
To model systems written using the MDS framework,
the Acme team first encoded the MDS architectural con-
ventions as an Acme style. We based the style definition
on a set of documents from JPL that prescribed in English
prose the types of elements in an MDS design and the
constraints on how instances of those types could be com-
bined. The resulting style formally captures the high-level
vocabulary and rules governing the architectures of all
MDS systems.
The architectural style consists of six component types
(e.g., Sensor, Actuator, Controller), eight connector types
(e.g., Command Submit, Measurement Request, State Up-
date), seventeen port types and eighteen role types, in
addition to 39 formal rules that specify what it means to
have a correct MDS system topology. Figure 2 illustrates
a small segment of an architecture written in this style.
This segment depicts interaction between a Controller, an
Actuator, and an Estimator. In this interaction, the Con-
troller submits a command to an Actuator via its Com-
mand Submit connector. The Actuator then notifies the
Estimator that it received a command. Subsequently, the
Estimator queries the Actuator to find out what the com-
mand was. Examples of the MDS rules:
1. If an Estimator can be notified of a command by an
Actuator, then that Estimator must be able to query
the Actuator for the command.
2. An Actuator must have exactly one Controller con-
nected to it.
3. An Actuator must have the same number of Com-
mand Submit, Command Notification, and Command
Query ports (one for each type of command that it re-
ceives).
Figure 1. SCRover high-level architecture
Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04)
0-7695-2172-X/04 $ 20.00 © 2004 IEEE
The first MDS rule above can be captured in Acme
with the following predicate:
1
invariant (forall e :! EstimatorT in self.
components
|
(forall cnp :! CmdNotProvT in e.
ports
|
(forall a :! ActuatorT in self.
components
|
(forall cnr :! CmdNotReqrT in a.
ports
|
(
connected
(cnp, cnr) ->
(exists cqr :! CmdQryReqrT in e.
ports
|
exists cqp :! CmdQryProvT in a.
ports|
connected
(cqr, cqp)))))));
These rules are automatically checked by Acme tools.
3.2.1 The Acme Process
The Acme team primarily used the SSAD to develop
an architectural model of SCRover. The process consisted
of three phases that built up evidence for the types of
components and connectors in the architecture.
Phase 1: Identify components and possible connec-
tions. Primarily using the class diagrams, the components
are identified, and then the connectors are recorded based
on the associations between classes in the diagrams. Be-
cause a given UML association between components may
be one of several possible architectural connectors, some
of these are marked as possible connectors, pending fur-
ther evidence from the other phases.
Figure 3 gives an example of a diagram from the
SSAD, showing an interaction between a Position &
Heading Estimator and a Hardware Adaptor.
2
From this
diagram, it is straightforward to derive the existence of an
Estimator component. However, there are several choices
for what the association in the diagram could mean:
1
In this rule, self refers to the system, italicized words refer to prede-
fined Acme functions, and the clause <name> :! <type> means that
<name> declares the type <type>.
2
In the Acme MDS architectural style, Actuators and Sensors are
distinguished as separate entities whereas in the SSAD they are bundled
together in Hardware Adaptors. The “mode of use” attribute of an
Adaptor dictated whether it was a Sensor or an Actuator in this process.
• The Hardware Adaptor is being used as a Sensor, and
either the Estimator is periodically requesting meas-
urements, or it is notified of measurements from the
Sensor. The direction of the arrow argues against the
former; if it is the latter, however, there is no corre-
sponding measurement requested by the Estimator, as
required by MDS rules.
• The Hardware Adaptor is being used as an Actuator,
and the Estimator is either notified of a command, or
is querying a command. For reasons similar to the
above, we cannot tell which connector it actually is.
To resolve the above ambiguity, we need the informa-
tion from Phase 2.
Phase 2: Refine connections based on sequence dia-
grams. Evidence from messages in sequence diagrams is
used to substantiate and disambiguate possible connectors
obtained from Phase 1. If a message cannot be mapped to
any possible connectors from Phase 1, a connector is
added to the architecture based on knowledge of the MDS
style. The lack of a connector is then noted as an omission
from the SSAD class and interaction diagrams.
Figure 4 shows the portion of a sequence diagram from
the SSAD that we used to disambiguate whether the
Hardware Adaptor is being used as a Sensor or Actuator
by the Position & Heading Estimator, and to determine
the type of connection between the two components. The
method call and parameter name suggest that the Estima-
tor polls the Adaptor for a measurement, leading to the
conclusion that the hardware adaptor is being used as a
sensor in this case, and that the connection is a measure-
ment request.
3
Phase 3: Review and resolve inconsistencies. To com-
plete the MDS architecture, the final phase reviews the
results of the previous phases against all other available
documentation. Any inconsistencies that arise from deci-
sions made in Phase 1 or 2 are also reviewed. If an incon-
sistency is found, “reasonable” decisions based on knowl-
edge of the MDS architectural style are made. If neces-
sary, Phase 1 and/or 2 processes are repeated.
3
The actual direction of the interaction results in an error when the
model is later checked by the tools.
Figure 3. Portion of SSAD’s component classifier diagram
Figure 2. A
Controller/Actuator/Estimator
pattern in MDS
Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04)
0-7695-2172-X/04 $ 20.00 © 2004 IEEE
After the model has been developed, Acme tools check
the model according to the constraints specified in the
style and any problems are reported.
3.2.2 Acme View of SCRover
At the end of this process we had an architectural view
of SCRover that shows the components involved in each
control loop, their connections, and the relationship be-
tween control loops. For example, from the model it is
evident that the Position and Heading Controller uses
information from both SCRover’s Position and Heading,
as well as the nature of known Obstacles. It is also imme-
diately apparent from the model that components query
Sensors and State Variables directly, and are not notified
of changes (which the MDS style allows).
3.3. The Mae Modeling Approach
Acme models were primarily used to check topological
constraints. In contrast, Mae [18][22] was used to model
the refinement of the SCRover components’ functionality
and enable analysis of architectural mismatch. Mae is an
extensible architectural evolution environment. It enables
modeling, analysis, and management of different versions
of architectural artifacts, and supports domain-specific
extensions to capture additional system properties.
At its core Mae leverages xADL 2.0 [5], an XML-
based ADL. xADL 2.0 is a collection of modularly organ-
ized XML schemas that represent components, connec-
tors, and interfaces. Extensions to xADL may be built to
represent additional architectural properties via new XML
schemas. The extensions used for modeling SCRover are
depicted in Figure 5(b).
Mae employs the Static Behavior extension to xADL’s
core to capture static behavioral properties of the system.
Figure 5(a) depicts how a component type is specified in
the context of this schema: pre- and post-conditions and
invariants are used to statically describe the state of the
component using a set of variables (StateDecl); invariants
may constrain the values for these variables; signatures
are instances of an interface type (not shown in the fig-
ure), and in addition to a pointer to their parent type, have
a name, a direction (provided or required) and a set of
interface elements; an interface element in turn is speci-
fied in terms of a method signature, and is mapped to one
or more operations where associated pre- and post-
conditions are captured; finally, the subtype field is used
to capture relationships among components.
The MDS Types extension shown in Figure 5(b) was
built by extending the static behavioral model to capture
namespaces and complex inheritance information for
components. Finally, the MDS Implementation schema
links architectural artifacts to their implementation-level
counterparts. This extension is primarily used for code
generation from the architectural model.
4
3.3.1 The Mae Process
These extensions in concert define a specific ADL that
can capture all the functional requirements of architectural
elements in the context of MDS. To build a Mae architec-
tural model of SCRover, we needed to refine the models
in the MBASE-SSAD document. This process was cen-
tered on the following two activities:
Phase 1: Identify Components and Connectors. Simi-
larly to the experience of the Acme team, the Mae team
extensively used the existing class diagrams to identify
components and connectors in the system. Sometimes
components were formed by merging two or more classes
that together would correspond to an MDS component
type (Controller, Estimator, etc.). Once the components
were identified, their interconnections were established by
leveraging associations in the diagrams. Additional con-
nectors were also identified in the next phase, when the
components’ interfaces were modeled.
Phase 2: Refine component services in terms of inter-
faces and their associated operations. Once the compo-
nents were identified, we needed to specify the services
they provide to the system, as well as those they require
from the system. The former were directly obtained from
the UML class diagrams, while the latter were derived
using a combination of class diagrams and the detailed
information provided in the Implementation Design sec-
tion of the SSAD, along with extensive help from a
SCRover system architect.
Using this information, we were able to partially model
the system in Mae. Additional work was required in con-
verting the pre- and post-conditions (as specified in the
Implementation Design section of the SSAD) into first-
order logic expressions required by Mae. The extra effort
was due to two obstacles: (1) These conditions were
specified in English prose and often lacked proper con-
nection to a component’s state. Consequently a great por-
4
The details of MDS Types and MDS Implementation schemas may
not be described in this paper as they may be subject to the U.S. Interna-
tional Traffic in Arms Regulation (ITAR).
Figure 4. Portion of SSAD’s sequence diagram
showing interaction between
Adaptor
and
Estimator
Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA’04)
0-7695-2172-X/04 $ 20.00 © 2004 IEEE
