Content uploaded by Jakob E. Bardram
Author content
All content in this area was uploaded by Jakob E. Bardram on Jan 03, 2015
Content may be subject to copyright.
Architectural Prototyping: An Approach for Grounding Architectural Design
and Learning
Jakob Eyvind Bardram, Henrik Bærbak Christensen and Klaus Marius Hansen
University of Aarhus
Computer Science Department
Aabogade 34, 8200 Aarhus N, Denmark
{bardram,hbc,klaus.m.hansen}@daimi.au.dk
Abstract
A major part of software architecture design is learning
how specific architectural designs balance the concerns of
stakeholders. We explore the notion of “architectural pro-
totypes”, correspondingly architectural prototyping, as a
means of using executable prototypes to investigate stake-
holders’ concerns with respect to a system under develop-
ment. An architectural prototype is primarily a learning
and communication vehicle used to explore and experiment
with alternative architectural styles, features, and patterns
in order to balance different architectural qualities. The
use of architectural prototypes in the development process
is discussed, and we argue that such prototypes can play a
role throughout the entire process. The use of architectural
prototypes are illustrated by three distinct cases of creating
software systems. We argue that architectural prototyping
can provide key insights that may otherwise be difficult to
obtain before a system is built. Furthermore, they define
skeleton systems that serve as communication means and
knowledge transfer among stakeholders.
1 Introduction
Exploring unknown territory may serve as metaphor for
building new software architectures. The planet Mars is a
fine example of unknown territory that is presently drawing
a lot of attention. Manytechniqueshelpus in suchan explo-
ration. Satellites like Mars Global Surveyor, Mars Odyssey,
and Mars Express orbit the planet and chart the territory us-
ing a wide range of different techniques. However, even
with the most advanced techniques there is no substitute for
“being there”, which is the reason why rovers like Mars
Spirit and Opportunity are now scouting the surface pro-
viding data that would otherwise be impossible to acquire.
In a similar vein, methods, techniques, and catalogues have
been designed forhelping architects in contemplating, eval-
uating, and constructing architectures. However, abstract
as they are, they provide the orbital view; and more often
than not, architects need to “be there” to explore issues in
sufficient detail to make qualified decisions.
In this paper, we explore architectural prototypes as the
metaphorical equivalent of “being there”, i.e., scouting the
architecture-to-be-implemented by actually building low-
cost executable systems that reflect essential architectural
qualities of a potential target system’s architecture.
Our main contribution is to explore the notion of archi-
tectural prototype in detail, to discuss its characteristics and
to describe how it differs from traditional software proto-
types. We hope thereby to initiate a classification and in-
vestigationof the concept in orderto introduce well-defined
terminology and techniques into the vocabulary of every
software architect.
Our paper is organized as follows. We present a def-
inition of what makes architectural prototype a particular
class of prototypes and outline characteristic properties in
Section 2. We then present three cases of defining, con-
structing, and evaluating architectural prototypes, emerging
from three radically different projects in Section 3. Next,
in Section 4 and 5, we present an initial attempt at classi-
fying types of architectural prototypes and relate these to
the overall process of architecture and system development.
Finally, we conclude in Section 6.
2 Architectural Prototyping
The seminal paper by Floyd [14] acknowledges the diffi-
culty in accurately defining “prototyping” in connection to
software development. She takes her starting point in a def-
inition of engineering/manufacturing prototypes and then
discusses the properties that are different or characteristic
for software prototypes.
Architectural
Prototype
Executable
Architectural
Quality
Stakeholder
Concern
Architecture
investigates
motivated by
System
has an
has
1..*
1..*
has
is important to
1..*
includes1..*
1..*
1..*
*
1..*
Figure 1. Ontology of Architectural Proto-
types
In a similar vein, we may characterize architectural pro-
totyping as a special class of softwareengineeringprototyp-
ing with a number of distinct properties. Floyd defines pro-
totypes as executable systems that “involve an early practi-
cal demonstration of relevant parts of the desired software”.
Prototypes are primarily interesting as a process rather than
the prototype itself as a product—it is used as “a learning
vehicle providing more precise ideas about what the target
system should be like.”
2.1 Definition
We define the concept of architectural prototype as fol-
lows:
An architectural prototype consists of a set of ex-
ecutablescreated to investigatearchitecturalqual-
ities related to concerns raised by stakeholders of
a system under development. Architectural pro-
totyping is the process of designing, building, and
evaluating architectural prototypes.
Figure 1 relates this definition to the software architec-
tureontologydefinedbyIEEE[23]. The System is the entity
beingbuilt, which may encompass, e.g., singleapplications,
frameworks, and product lines. Stakeholders have interests
in the System expressed through a number of Concerns re-
gardingthe developmentof the system. Architectural Qual-
ities are specific Concerns of interest in architectural proto-
types and includes qualities such as performance, reliabil-
ity, or modifiability [2]. The Concerns and their included
Architectural Qualities define the reasons for building Ar-
chitectural Prototypes through a set of Executables.
Architectural prototypes may investigate Architectural
Qualities in a number of ways. We elaborate this below
through a focus on defining characteristics of architectural
prototypes.
2.2 Characteristics
A number of properties characterize architectural proto-
types and set them apart from traditionalsoftware engineer-
ing prototypes.
First, architectural prototypes are constructed for explo-
rationand learning of the architectural design space. Floyd
characterized prototypes as “learning vehicles”, but though
this was a general statement, the focus was (and has tra-
ditionally been) on “software intended as a direct support
for human work.” In contrast, architectural prototypes have
the architecture itself as focus, largely ignoring the intent
of the system under study. This has interesting relations to
what Bass et al. describe as the architecture business cy-
cle [2, § 1]. One important influence on architecture, me-
diated through the architect, is the architect’s own experi-
ence. Success with a certainarchitecturalstyle, for instance,
inclines the architect to use it again even if inappropriate.
Architectural prototyping is a way to break this circle as it
allows the architect to learn and experiment at a low cost.
That is, the architect’s “design vocabulary” is expanded.
Second, architectural prototyping addresses issues re-
garding architectural quality attributes in the target system.
It is the primary challenge for the architect to define an ar-
chitecture that balances conflicting qualities in an appropri-
ate way. Typical issues the architecture must address are:
“will it perform adequately?”, “is it cost-efficient to main-
tain?”, “can we guaranty high availability?” Architectural
prototypes are important vehicles for striking this balance
as qualities can be observed and measured directly: per-
formance measurements can be made, experience is gained
whether the programming interface is understandable, etc.
In our example section, we outline architectural proto-
types developedfor the purposeof analyzing the qualities of
performance versus maintainability (Section 3.1), modifia-
bility and buildability (Section 3.2), and performance (Sec-
tion 3.3) respectively.
Third, architectural prototypes do not provide function-
ality per se. As noted by Bass et al. “functionality”(defined
as the ability of the system to do the work for which it was
intended [2, § 4.1]) is largely non-architectural in nature.
Architectural prototypes are skeleton systems that facilitate
functionality; they do (usually) not deal with the function-
ality itself. This is an important property because it is what
makes architectural prototyping cost-efficient.
Fourth, architectural prototypes typically address archi-
tectural risks. Architectural risks may be to find the proper
balance among opposing qualities like performance and
modifiability but it may also be related to, e.g., buildabil-
ity concerns. A typical example of the latter is prototyp-
ing to acquire knowledge about technologic platforms (e.g.,
J2EE), programming models (e.g., knowledge-based sys-
tem), and other aspects that may be new to the organization
or to the architects.
And fifth, architectural prototypes address the problem
of knowledge transfer and architectural conformance.A
major challenge in architecture centric development is en-
suring that the architecture “as-built” is identical to the ar-
chitecture “as-designed”. Here the architecture prototype
serves as a reference system that demonstrates keyarchitec-
tural decisions, patterns and styles to the development team
as concrete source code, and may serve as the backbone
system for “growing” the required functionality on top of.
Thus architectural prototypes that demonstrate the desired
balance of qualities are most likely not thrown away but
used as skeleton systems.
Architectural prototypes are executable systems but our
definition does not dictate how these are produced. In the
case studies described below, the architectural prototypes
were build by hand using traditional integrated program-
ming environments. However, stronger tool support, e.g.,
to produce executables from Unified Modeling Language
(UML; [20]) or Architecture Description Language (ADL)
specifications, may be available for specific problem do-
mains.
3 Case Studies
The following sections present architectural prototypes
in action through three cases of architectural prototyping.
The examples have been chosen as to represent a broad
spectrumof types of architecturalprototypes(see Section 4)
and problem domains – viz., real-time embedded software,
information systems, and (research in) pervasive comput-
ing.
3.1 Closed-loop Process Control
This project dealt with a major revision of a Danish ven-
dor’s closed-loop process control system for engine con-
trol [7, 9]. The existing system was based on software run-
ning on a single, embedded CPU system with fixed connec-
tions to sensors (sensing the controlled process) and actu-
ators (controlling the process). As example, the system is
used to control elevators, cooling by fans, conveyor belts,
etc.
The challenge was to design an extensible, distributed,
system that allowed for a flexible, expandable, system by
adding “option-cards” having their own processing power
and memory. For instance, one may extend the system to
handle more sensors simply by adding more A/D converter
cards. Thus the software had to be redesigned to handle A)
distribution, as data comes from separate embedded cards
and B) dynamic reconfigurations. Our focus was primarily
on issue A.
The main quality of the new architecture was hard real
time performance. All measurements of the process (feed-
backvalues)haveto be sampled, processed(like averaging),
communicated to the control algorithm, and feed to the en-
gine control hardware within a timeframe of about a few
milliseconds. The second driving quality was maintainabil-
ity in order to ease maintenanceand lowerthe software error
rate. The existing system hadhad high performancebut had
turned out to be difficult to maintain.
Thus the challenge was to find a suitable architecturethat
could provide “as much maintainability as possible” and
still perform.
We responded to this challenge by designing four archi-
tecture prototypes for further analysis. Three of these were
variants of the pipe-line architectural style while the last
was based on a repository style.
The three pipe-line architecture prototypes differed on
the dataflow protocols. In the pull variant the control algo-
rithm (data sink) requests data from components in a chain
all the way to the components responsible for sampling
feed-back value input (data sources). In the push variant
it is instead the input components that publish data to sub-
scribers, and data flows using an Observer pattern protocol
[15] through the chain of components to the control algo-
rithm. Finally, a mixed push/pull variant was defined where
input components publish data to an intermediate cache
component(push),whilethe control algorithmrequests data
from the cache (pull). Common to all three variants was
that data flows through (sometimes remote) methods calls
between components.
The repository prototype instead defines a distributed
database component. Logically, there is one central
database storing feed-back values. At the deployment level,
each CPU card has a local database component that use the
network to guaranty that the database contents is consistent
across all nodes; a task that the underlying CAN bus is di-
rectly designed for [6]. In this scenario, input components
simply write feed-back values to the distributed database,
and the control algorithm component reads them. Thus data
is communicated essentially through variable reading and
writing.
The architecture evaluation phase contained two, inter-
woven, activities. In the analysis activity, consequences for
performance and maintainability were discussed and ana-
lyzed in meetings between stakeholders; in the construction
activity actual prototypes were constructed, both on hard-
waresimilar to the target platform[13] as well as onthe Java
platform. The stakeholders included lead designers from
the company and a university research group, both with ar-
chitectural and software design insight.
Prototypes were built for the pushed variant pipe-line
and for the repository-based architecture. The pulled vari-
antpipe-line was used in the present productionsystem soft-
wareand its characteristicsthereforewell known; the mixed
variant pipe-line was not constructed as sufficient knowl-
edge was acquired during the construction of the other pro-
totypes to deem it less interesting.
The conclusion of the evaluation phase was that both
the process as well as the prototypes built were essential
in finding a high performance architecture with good main-
tainability characteristics. The process of building the pro-
totypes and later reviews of the “lessons learned” during
meetings spurred a lot of discussion and pin-pointedtrouble
spots that had not been identified during earlier more ab-
stract discussions. As an example, the pushed variant pipe-
line seemed promising, due to its low coupling property,
but the experimentsshowed a major drawback about timing
issues: each new feed-backvalue sampled in the input com-
ponent essentially triggers a new update sequence through
to the control algorithm that is thus run several times within
each control interval—which clearly exceeded the time slot
allotted. One may argue that we should have identified
this (in hindsight, obvious) problem without building pro-
totypes. However, it shows the value of prototypes as even
seasoned architects may oversee the obvious whereas exe-
cuting software does not; also there was great value in actu-
ally demonstrating the problem to stakeholders.
The outcome was that the repositoryvariant had superior
properties: Performance was adequate while the variable
access paradigm for data communication provided strong
decouplingbetween componentswhile beingeasy to under-
stand and maintain. Furthermore, time expenditure calcula-
tions for each component were greatly simplified as data
read/write is constant time while method call estimates de-
pends on a complete flow analysis. Thus the repository ar-
chitecture prototype was chosen as skeleton system for the
final product.
3.2 The Dragon Architectural Prototypes
The Dragon project developed a series of evolutionary
prototypes of a customer service system for a globally dis-
tributed container shipping company [10]. The project pro-
gressed through two major phases in which an iterative and
incremental development strategy was used (see Figure 2):
• Exploring major functional concerns through horizon-
tal prototyping. This phase explored uncovered func-
tional requirementsthrough among others prototyping,
ethnography[19], and participatory design [16] since a
major risk of the project was uncertaintyand complex-
ity with regards to functionality and scope. The phase
resulted in a series of prototypes which were reviewed
and approved by the shipping company.
• Exploring software architecture through vertical pro-
totyping. Building on the horizontal prototypes devel-
Customers
Booking
Products
Schedules
Documentation
Inbound
Rerouting
Stuffing
Route Map
Quote
RDB integration
Multi-user
Allocation
Customization
4
th
+ prototype
1
st
prototype
user interface
3
rd
prototype
2
nd
prototype
functionality
Paper sketch
Time
Concerns
Review
Review
Review
Review
Review
Review
Review
Runtime
Figure 2. Activities in the Dragon Project
oped in the first phase, the Dragon project explored
technical concerns such as integrationwith legacy sys-
tems, creating Computer-SupportedCooperative Work
(CSCW) support, and experimentingwith binary com-
ponent technology [11].
The second phase of the Dragon project created evolu-
tionary architectural prototypes based on horizontal proto-
types. The decision to build architectural prototypes on
top of a functional prototype was, among others, based
on that the realizability of the system needed to be inves-
tigated with respect to unknown and conflicting require-
ments. The first phase, which included numerous presen-
tations to staff, workshops, and reviews, meant that require-
ments were reasonably complete in terms of use cases as
well as user interaction. Achieving such a level of com-
pleteness of functional requirements may indeed often be
necessary to ground architectural design of interactive sys-
tem in the advent of high uncertainty of requirements [3].
An example of a user interface design which had architec-
tural implications and was crucial for usability was the pos-
sibility for customer service agents to partially specify, e.g.,
values to a search in a legacy system for products related to
a quote, let the search work in the background, and at the
same time let the customer service agent continue to work
on other parts of the quote.
In the context of this, the architectural prototypes of the
Dragon project explored, first, a horizontal, suitable divi-
sion of responsibilities among components and associated
connectors and, secondly, the implications of adding ver-
tical support for, e.g., integration with legacy systems and
support for collaborative work.
The main architectural quality that was investigated in
the second phase of the Dragon project was buildability.
The earlier exploratory activities had shown that the ini-
tial architecture was problematic with respect to develop-
ment time, deploymentetc. It was thus investigatedthrough
prototypes whether and how these problems could be alle-
viated. Other architectural qualities explored encompassed
modifiability, usability, and integrability. Modifiability and
usability were explored through the creation of architectural
prototypes on top of functional prototypes, showing that a
system containing components pertaining to major domain
abstractions and with the required usability characteristics
couldindeed be built in a way in which new domain compo-
nents could be addedto the system with littleeffort [11]. In-
tegrabilitywasinvestigatedthroughproof-of-conceptproto-
types simulating integration with legacy systems based on
data from the functional prototypes.
The stakeholders of the architecturalprototypes were the
development team (which included a university research
group, external consultants, and company representatives)
and decision makers in the company. The development
team was concerned with whether and to which degree a
software architecture supporting the functional prototypes
couldbe designed in the contextof the quality requirements.
From the perspective of the decision makers from the com-
pany, the purpose was to remove as many risks as possible
in a situation characterized by high uncertainty and com-
plexitywith respect to functional requirementsbeforea full-
scale development of the production system was launched;
a development for which the prototypes were to be used as
a main requirements specification. The architectural proto-
types were instrumental in reachingthe goals of these stake-
holders.
3.3 Activity-Based Computing Framework
The Activity-BasedComputing (ABC) Framework[8, 1]
is a research system for pervasive computing. The ba-
sic idea in activity-based computing is to help users focus
on their work activities (or tasks) rather than low-level is-
sues in contemporary computer systems, like files, applica-
tions, network connectivity,or deviceinteroperability. Such
higher-level support is essential in a pervasive computing
paradigm, because users cannot cope with the details of
handling many different devices.
A core part of the ABC framework is an infrastructure
(or middleware layer), which stores, manages, and dis-
tributes activities on behalf of the users. To explore how
to design the architecture for this middleware layer, a cou-
ple of architectural styles were explored using architectural
prototypes; a call-based client-server style, an event-based
system consisting of several independentcomponents,and a
peer-to-peer architecture. The purpose of these prototypes
was to explore different approaches to an architecture for
activity-based computing and to experiment with the feasi-
bility and efficiency of different styles, features, and archi-
tecture patterns.
First, the well-known call-based client-server architec-
tural style was applied. The prototype explored how activ-
ities could be stored, managed, and distributed to clients
using a central ’Activity Server’. Clients would call the
server and get a copy of an activity. The server would also
handle parallel updates and inconsistencies. This architec-
ture was, however, put to a test when real-time collabora-
tion was introduced to the ABC framework. Two or more
users could simultaneously collaborate on an activity, and
the ABC framework would then enable them to see what
each other was doing and hear each other. This is in the
CSCW research tradition often referred to as desktop con-
ferencing or real-time application sharing. The call-based
client server architecture turned out not to be well-suited
for this kind of real-time updates of e.g. moving scrollbars
and other user-interface changes.
Hence, a prototype was built based on an event-based
publish/subscribe architecture instead. Each of the clients
participating in a real-time activity sharing session would
both publish and subscribe to changes in the state of the
client applications. This architecture proved to handle the
real-time collaborative features of the ABC framework in a
much more elegant way.
Further exploration has been done lately, building a pro-
totype that use a peer-to-peer type of architecture where
changes to the state of clients in a session is distributed di-
rectly between the clients, and is not handled by a central
publish/subscribe broker.
Performance in real-time activity sharing is crucial and
further examination of how to make the most efficient im-
plementation of this event-based architecture were carried
out. In particular an experiment was set up to measure
which architecture pattern was the most efficient in terms
of response time and CPU and network load; the ‘Reactor’
architectural pattern or the ‘Leader/Follower’ architectural
pattern [22].
A final example of architectural prototyping done dur-
ing the development of the ABC framework was to explore
the issue of portability, and more precisely the feature of
binding time in the control of the system. Portability is a
key concern in pervasive computing and also a difficult ar-
chitecture quality to meet, because there is (or will be) a
wide range of heterogeneous devices in a pervasive com-
puting world. In the first architecturalprototype of the ABC
framework, applications used in the framework were added
at compile time. Hence, portability was supported at com-
pile time, by compiling and linking to the applications, that
the ABC framework would support on its clients. The pro-
totype was built in Java and could hence be ported across
devicesthat had a Java virtualmachine, which could run the
J2SE version of Java. This is a traditional way of handling
portability, i.e. to link and compile applications at compile
time and then have a hardware abstraction in terms of a vir-
tual machine. However, the aim of the ABC framework is
to look up applications on run-time and the next version
of the prototype was hence built to explore this issue of the
framework. To achievethis thereis a registryon each device
that can participate in the ABC infrastructure. This registry
is used by the framework to look up applications that can
implement certain services. For example, an activity deal-
ing with word processing would require a text editor and a
spell checker. When activated, this activity would look up a
‘text editor’ and a ‘spell check’ service on various devices.
Hence, on a Windows PC the text editor might be ‘Write’
and the spell checker taken from MS Word. On a PDA the
text editor might be the default one and the ‘spell check’
service might not be implemented.
4 Classification of Architectural Prototypes
An architectural prototype can serve several purposes at
various stages in the development process. We can distin-
guish between two basic types of architectural prototypes:
• Exploratory prototypes used to clarify requirements
to the architecturetogether with its stakeholders, to ex-
plore aspects of the target system, and used to discuss
alternative architectural solutions.
• Experimental prototypes used to gauge the adequacy
of a proposed architecture, or details hereof, before in-
vesting in a large-scale implementation of it. Experi-
mental prototypes are typically used to measure soft-
ware architecture qualities; e.g., to make quantitative
measurement of performance or portability.
Exploratory and experimental prototypes can be used to
clarify and learn about architectural questions and issues in
a broad sense, ranging from questions of the overall archi-
tectural style to more detailed questions about a specific ar-
chitectural pattern. This is illustrated in Table 1. Let us con-
sider these approachesto architecturalprototyping in detail.
4.1 Exploratory Architectural Prototypes
Exploratory prototypes are used to focus on basic issues,
questions or critical problems of the architecture. Their
main purpose is to facilitate communication and learning
among stakeholders of an architecture, like the architect(s),
the customers, the users, and the developers. Exploratory
prototypes are used when there is a high degree of uncer-
tainty about how to build the target system, andis thus often
used in the early stages of software development. In such
situations, a practical demonstration of an executable ar-
chitectural prototype can facilitate a discussion of pros and
cons, which is grounded in ‘real code’ and not merely spec-
ulations of what can be achieved and what not. Typically,
a number of alternative prototypes are built and compared
againstone anotherand theyare typically thrown awayafter
use.
When planning a new system, a new module, or changes
to an existing one, the architect might consider using differ-
ent architectural styles. In this case a number of architec-
tural prototypes can be build to explorepros and cons of dif-
ferent styles. Such exploration can also be used to help the
architect to think beyond the styles/patterns that s/he is usu-
ally applying (cf. [2, 5]). For example, in the ‘Closed-Loop
Process Control’ case (Section 3.1) the architect explored
two types of architectural styles, each with a different ap-
proach to meet the requirementof the system. Architectural
qualities like buildability and conceptual integrity are also
investigated in such early, overall architectural prototypes.
Alternative exploratoryprototypes can be judged according
to howthey meet core quality requirements to the target sys-
tem. This judgment is typically done by the system’s differ-
ent stakeholders in common and the exploratory prototypes
are used to ground the discussions in “real code”. For ex-
ample, in the Dragon case, a proof-of-concept of how to
integrate with legacy data was used among the stakeholders
of the target system to learn and to reduce risk.
Once an architectural style has been decided upon it can
be refined by exploring different features of the architec-
ture like exploring types of components, connectors, or the
topology of the architecture. Prototypes can be built to ex-
plore how the choice of certain features of the architecture
influences the overall target system. For example, in the
ABC framework presented in Section 3.3, the feature of
synchronicity in the control structure was explored. The
motive was to investigate how an asynchronous event sys-
tem handled real-time collaboration compared to the more
traditional call-and-return client-server architecture.
On a more detailed level, exploratory prototypes can be
used to survey different strategies in implementation. In
this case minor prototypes can be built to investigate how
various architecture or design patterns can help meet the
required qualities for an architecture. For example, once
the asynchronous event system style of architecture was de-
cided upon in the ABC framework, prototypes were devel-
oped in order to decide how the event notification scheme
should be implemented in the architecture.
4.2 Experimental Architectural Prototypes
Experimental prototypes are used to measurespecific as-
pects of a proposed architecture, or details hereof. This is
done before engaging in the development of the target sys-
tem based on this architecture. Their main purpose is to
establish experimentally if the proposed architecture meets
the qualitative requirement. For example, measure if the ar-
chitecture supports the qualities of performance, availabil-
ity, or portability. The main users of an experimental proto-
type are the architects themselves in order to prove that the
system, when built according to a certain architecture, can
Table 1. Classification of Architectural Prototypes.
Architectural Style Architectural Feature Architectural Pattern
Exploration Exploring alternative architectural Refining the style by Exploring different
styles of a system exploring alternative features implementation strategies
Experimental Assessing how to meet Quantitative measurement of Tuning implementation
core qualities specific qualities details to improve on qualities
meet e.g. the performance requirements. Other stakehold-
ers, like the customers, might, however, also be interested
in an early proof of conformance to quality requirements.
One might argue to what degree it is possible to obtain valid
measurements for architectural qualities before the system
is built. It might, e.g., be difficult to measure performance
and response time in a highly distributed system handling
terra-bytes of data, before this system is built and deployed
on thousands of hosts. However, we would argue that if a
certain architecture quality, like in this case performance,is
important,then it isimperativeto start buildingfor and eval-
uating performance at an early phase in the development.
For this purpose, an architectural prototype can be built of
the intended architecture for experimentation under execu-
tion conditions simulating the intended deployment envi-
ronment.
On the most overall level, an experimental prototype can
bebuildto assess how to meetcore requirements tosoftware
qualities. For example, in the ‘Closed-Loop Process Con-
trol’ case, the qualities of performance and modifiability
were key to the system and hence experimental prototyping
were applied to judge how these two qualities would play
out against each other. Not surprisingly, there is a trade-
off between various architecture qualities and experimental
prototypingcan be used as method to judgeexactly howthis
trade-offis manifested through real code, and help discover
solution of how to balance such trade-offs.
On an intermediate level, an experimental prototype can
be used to quantitatively measure how well an architecture
fulfils requirements to software qualities. This is typically
done by experimentingwith features of the chosen architec-
ture. For example, the modifiability and reusabilityof a sys-
tem and its components are often correlated to its constitut-
ing parts, i.e. components and connectors. Thus, an experi-
mental architectural prototype can be constructed to evalu-
ate how a certain blue-print of components and connectors
can meet the requirement for modifiability and reusability.
Runtime qualities, like performanceand availability, can be
gauged by experimentingwith control and data issues, such
as synchronicity, binding time, and continuity. Such qual-
ities can be subject to quantitative requirements, e.g. time
measurement of response time in information systems and
processing availability in embedded systems. Experimen-
tal prototype can help to continously establish if and how
the underlying architecture meets such requirements. For
example, a simple experiment in the ‘Closed-Loop Process
Control’ case revealed that the pushed pipe-line architec-
ture could not meet the hard real-time performancerequire-
ments to the architecture. Other experimental prototypes
focusing on architecture feature might work more like a
‘proof-of-concept’ in the sense that the prototype demon-
strated (proves) that certain software qualities are reached.
For example, in the ABC Framework binding time for ap-
plications were moved from compiletime to runtime and an
experiment was conducted to establish how portability and
reusability played out under these new conditions.
On a detailed level, an experimental prototype can be
built to test how the use of architectural and/or design pat-
terns can helpaccomplish the overall architecturalqualities.
Such experimentationoftenrevealssome of the internal ten-
sions embedded in an architecture. On the one hand, the use
of architectural and design patterns help meet non-runtime
qualities. Patterns help to make code modularized, to cre-
ate loose couplings, to abstract, etc., that all help accom-
plish qualities like modifiability, reusability, and integrabil-
ity. On the other hand, there is a tendencythat patterns make
it harder to meet runtime qualities, like performance, secu-
rity, and availability. Levelsof indirectionssimply take time
and are, if distributed over network layers, vulnerable to se-
curity attacks. Experimental architectural prototypes can
help understand and settle this basic tension in the use of
patterns. For example, in the ‘Close-Loop Process Control’
case, the use of the Observer pattern was simply abandoned
for performance reasons, and replaced with constant time
access of data in shared variables.
5 Architectural Prototypes and the Develop-
ment Process
As the examples in Section 3 and 4 point out, architec-
tural prototypes may play different roles at different stages
of a development process. More generally, we may look at
a process frameworksuch as the Unified Process [17] which
encompasses a number of concrete development processes
and relate architectural prototypes and architectural proto-
typing to this
1
. The Unified Process is a process framework
which may be tailored to specific development processes
through,among others, modellingthe developmentprocess.
As an extreme, consider the “dX” process created based on
(R)UP
2
which is actually an instantiation of eXtreme Pro-
gramming (XP; [4]) on top of UP.
In the context of the Unified Process, a process defines
an assignment of tasks and responsibilities within develop-
ment.
Figure 3. Rational Unified Process (from [21])
Figure 3 shows an overview of an instantiation of UP for
a developmentproject in which the dynamic organizationof
the process (in terms of time) is shown horizontally and the
static organization of the process (in terms of workflows) is
shown vertically. In general, the UP process operates with
four phases in which iterative development is performed:
• Inception is concerned with understanding what to
build by amongothers establishing a business caseand
finding and describing major use cases. The Closed-
loop Process Control case and the Dragon case were
very much concerned with development in this phase.
Architectural prototypes built in this phase would fo-
cus on major risks and qualities that are essential to
whether the system should be built.
• Elaboration is concerned with understanding how to
build what has been identified in the inception phase.
This typically includes defining an “executable archi-
tectural prototype” [21], “80% complete” use cases,
and development plans. These are developed in or-
der to eliminate major risks and uncertainties and on
1
Here we will refer to the Rational Unified Process (RUP; http:
//www.ibm.com/software/awdtools/rup/), which is a widely
used variant of the Unified Process, and UP interchangeably
2
http://www.objectmentor.com/publications/
RUPvsXP.pdf
an architectural level, in particular experimental archi-
tectural prototypes may play a role. The “architectural
prototypes” of RUP are a special kind of architectural
prototypes which are built as a skeletal system sup-
porting incremental construction of a system. In con-
trast, our main emphasis is on learning through archi-
tectural prototyping, i.e., much of architectural proto-
typing would come before the architectural prototypes
of RUP could be defined.
• Construction is concernedwith incrementallybuilding
a functionally complete version of the system (typi-
cally a “beta version”of the system). Remainingappli-
cationfeatures and componentsare built and integrated
into the system. Here, architectural prototypes may be
particularly useful for investigating detailed architec-
tural concerns orexperimentingwith new architectural
requirements.
• Transition is concerned with building the final version
of the product which may be finally shipped to cus-
tomers. A mature system is installed in the production
environment and thefinal product is created. Although
architectural prototypes may not be very useful per se
in this phase, most systems go through additional (re-
duced) phases of inception, elaboration, and construc-
tion in which architectural prototyping may be appro-
priate. The versions of the ABC framework, e.g., has
evolved through a number of transition phases and the
deployment (albeit in limited form) of the system has
beena majordriver for the need for architectural proto-
typing. Moreover, experiments with needed architec-
tural evolution of a deployed system may be necessary,
although these may be very high-cost experiments.
Considering the core process and supporting workflows of
Figure 3, architectural prototypes may play a role if deci-
sions of architectural significance are to be made in either
workflow.
Consider as an example the “requirements” workflow in
which actors and use cases are used to elicit, organize, and
documentrequired functionality. Here exploratoryarchitec-
tural prototypes may be used to uncover requirements to the
architecture (as in the Dragon case in Section 3.2). In par-
ticular, this may be useful in extending the vocabulary of
the architect and avoiding tunnel vision, e.g., with respect
to favoured architectural styles.
During “analysis and design” — in which it is uncov-
ered how the requirements should be realized through im-
plementation — exploratory and experimental prototypes
may complement models of architectural designs by pro-
viding a grounding of architectural choices. Also, archi-
tectural scenarios as created through, e.g., SAAM [18] or
ATAM [12], may be used to guide and verify the created
architectural prototypes. In particular, specific critical ar-
chitectural qualities could be investigated as a result of this
workflow.
An “architecturalprototype”in thesense ofRUPis apre-
requisite for “Implementation”. A sound basis for the RUP
architecturalprototype may have been provided through ex-
ploratory and experimentalprototypes. Even though imple-
mentation is mainly about realizing functionality, the im-
plementation may provide further validation of experimen-
tal architectural prototypes through their realization as full
(sub) systems.
The core supporting workflows (test, deployment, con-
figuration and change management, project management,
and environment) are workflows in which architectural pro-
totypes may be used to eliminate major concerns with spe-
cific architectural quality attribute related to these. Archi-
tectural prototypes, may, e.g., be used to explore architec-
tures realizing a desired level of testability such as the abil-
ity to verify reliability, functionality, and performance au-
tomatically. Another example would be to experiment with
buildability through architectural prototypes supporting the
environment workflow.
In summary, architectural prototypes may play a role in
most phases ofdevelopmentas well in supporting the work-
flows of the process, although the use of and need for ex-
ploratory and experimental prototypes has a different bal-
ance throughout development.
6 Conclusion
In this paper we have discussed the concept of archi-
tectural prototypes and defined it as a set of executables
created to investigate architectural qualities related to con-
cerns raised by a system’s stakeholders. An architectural
prototype is primarily a learning vehicle to explore and ex-
periment with alternative architectural styles, features, and
patterns. As opposed to traditional software prototypes, an
architectural prototype typically does not provide function-
ality per se, but addresses non-functional architectural qual-
ities of the target system.
We have proposed a classification of architectural pro-
totypes as explorative or experimental. Exploratory proto-
types help in settling the intrinsic trade-offs between archi-
tectural qualities. Experimental prototypes measure certain
software qualities at an early stage of development. We
have related architectural prototypes to an iterative devel-
opment process, exemplified by RUP.
We have explored the concept of architectural prototype
by discussing how they were used in three distinct cases:
(i) investigating how to build a high performance, em-
bedded, distributed control system; (ii) developing proto-
types of a globally distributed customer service system sup-
porting containerized shipping; and (iii) a research frame-
work for pervasive computing. In all three cases, we have
found architectural prototypes beneficial and cost-effective
in demonstrating intrinsic properties of the potential archi-
tectures at an early stage of architectural analysis and de-
sign, and thereby been essential to reduce risk and demon-
strate critical concerns to stakeholders. In one case, the ar-
chitecturalprototypewasused as the skeletonsystem for the
final product, and thus servedas principalmeans to commu-
nicate architectural design to the development team.
The term ‘architectural prototype’ has been used before,
primarily meaning a ‘skeleton system’ that is the first ver-
sion of the target system upon which developers can build
the system. We have found this use of the term too re-
strictive as prototype buildingserveswell in the architecture
analysis phase and should not be restricted to the construc-
tive phases.
Our main mission and contribution is to show that the
construction of architectural prototypes is a viable and
strong technique for architecture analysis and design. Ar-
chitectural prototypes have characteristics allowing them to
identify and analyse architectural concerns and trade-offs
that are otherwise difficult to obtain. We thus find the con-
cept important and hope to see more research in the nature
of architectural prototypes in order to make it a first-class
citizen of any software architects’ vocabulary and toolbox.
Acknowledgements
The research presented in this paper has been funded
by ISIS Katrinebjerg competence centre, Aarhus, Denmark
(http://www.isis.alexandra.dk).
References
[1] J. E. Bardram. Activity-Based Support for Mobility and
Collaboration in Ubiquitous Computing. In L. Baresi, ed-
itor, Proceedings of the Second International Conference on
Ubiquitous Mobile Information and Collaboration Systems,
Lecture Notes in Computer Science, pages 101–115, Riga,
Latvia, Sept. 2004. Springer Verlag.
[2] L. Bass, P. Clements, and R. Kazman. Software Architecture
in Practice 2nd Edition. Addison-Wesley, 2003.
[3] L. Bass and B. John. Supporting usability through software
architecture. IEEE Computer, 34(10):113–115, 2001.
[4] K. Beck. Extreme Programming Explained: Embrace
Change. Addison-Wesley, 1999.
[5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and
M. Stal. Pattern-oriented Software Architecture. John Wiley
and Sons, 1996.
[6] CAN. Controller Area Network CAN, an In-Vehicle Se-
rial Communication Protocol. In SAE Handbook 1992. SAE
Press, 1992.
[7] H. B. Christensen. Using Software Architectures for De-
signing Distributed Embedded Systems. Technical Report
CfPC-2003-PB-55, Center for Pervasive Computing, 2003.
[8] H. B. Christensen and J. E. Bardram. Supporting Hu-
man Activities – Exploring Activity-Centered Computing.
In G. Borriello and L. E. Holmquist, editors, Proceedings
of Ubicomp 2002: Ubiquitous Computing, volume 2498
of Lecture Notes in Computer Science, pages 107–116,
G¨oteborg, Sweden, Sept. 2002. Springer Verlag.
[9] H. B. Christensen and O. Eriksen. An Architectural Style
for Closed-loop Process-Control. Technical Report CfPC-
2003-PB-54, Center for Pervasive Computing, 2003.
[10] M. Christensen, A. Crabtree, C. Damm, K.Hansen, O. Mad-
sen, P. Marqvardsen, P. Mogensen, E. Sandvad, L. Sloth,
and M. Thomsen. The M.A.D. experience: Multiperspec-
tive Application Development in evolutionary prototyping.
In E. Jul, editor, ECOOP’98 – Object-Oriented Program-
ming. Proceedings of the 12th European Conference, pages
13–40. Springer Verlag, 1998.
[11] M. Christensen, C. Damm, K. Hansen, E. Sandvad, and
M. Thomsen. Creation and evolution of software architec-
ture in practice. In Proceedings of TOOLS Pacific’99, pages
2–15, 1999.
[12] P. Clements, R. Kazman, and M. Klein. Evaluating Software
Architectures: Methods and Case Studies. Addison-Wesley,
2002.
[13] Europe Technologies: EVM-CAN Evaluation Board.
http://www.europe-technologies.com/.
[14] C. Floyd. A systematic look at prototyping. In R. Budde,
K. Kuhlenkamp, L. Mathiassen, and H. Z¨ullighoven, edi-
tors, Approaches to Prototyping, pages 1–18. Springer Ver-
lag, 1984.
[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design
Patterns: Elements of Reuseable Object-Oriented Software.
Addison-Wesley, 1994.
[16] J. Greenbaum and M. Kyng. Design at Work: Coopera-
tive Design of Computer Systems. Lawrence Erlbaum Asso-
ciates, 1991.
[17] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Soft-
ware Development Process. Addison-Wesley, 1999.
[18] R. Kazman, L. Bass, and G. Abowd. SAAM: A Method for
Analyzing the Properties of Software Architectures. In Pro-
ceedings of the Sixteenth International Conference on Soft-
ware Engineering. ACM Press, 1994.
[19] F. Kensing and J. Simonsen. Using ethnography in con-
textual design. Communications of the ACM, 40(7):82–88,
1997.
[20] OMG. Unified Modeling Language specification 1.5.
Technical Report formal/2003-03-01, Object Management
Group, 2003.
[21] Rational Software. Rational Unified Process: Best
Practices for Software Development Teams. http:
//www.rational.com/media/whitepapers/
rup_bestpractices.pdf, 1998.
[22] D. Schmidt, M. Stal, H. Rohnert, and F. Buschmann.
Pattern-oriented Software Architecture – Patterns for Con-
current and Networked Objects, volume 2. John Wiley and
Sons, 2000.
[23] Software Engineering Standards Committee. IEEE recom-
mended practice for architectural description of software-
intensive systems. Technical Report IEEE Std 1471-2000,
IEEE Computer Society, 2000.
