=Paper=
{{Paper
|id=None
|storemode=property
|title=Statically Defined Dynamic Architecture Evolution
|pdfUrl=https://ceur-ws.org/Vol-688/acota2010_paper4_watson.pdf
|volume=Vol-688
|dblpUrl=https://dblp.org/rec/conf/acota/WatsonBP10
}}
==Statically Defined Dynamic Architecture Evolution==
https://ceur-ws.org/Vol-688/acota2010_paper4_watson.pdf
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
Statically Defined Dynamic Architecture Evolution
Robert Watson, Sutirtha Bhattacharya, Dewayne E. Perry
Empirical Software Engineering Lab (ESEL)
ECE, The University of Texas at Austin
Austin, TX 78712
rwatson@nextstatecorp.com
sutirtha.bhattacharya@intel.com
perry@mail.utexas.edu
Abstract-There are a variety of contexts where dynamic as determined by it's functionality, at some moment of the
architecture evolution is needed. The context we have been systems' operation.
working in is that of providing architecture models of NASA This view of architecture can be obtained by constructing a
training simulations for manned space exploration. In this complete architecture for each exhibited architecture. In our
context, as in many others, we do not need unrestricted dynamic
evolution, but only a limited form of dynamic evolution where
work this approach has lead to a proliferation of architecture
the transitions and boundaries of that evolution are well specifications having a great deal in common. An undesirable
understood. We present our approach to this restricted form of consequence is that the architecture as a whole contains
dynamic evolutions in the context of an abstract architecture considerable redundant specification.
model and use an architecture of architectures with transition In this paper we propose a simplifying construct, the arch-
connectors as the means of prescribing our statically defined transition, that permits the architecture to be specified as a set
dynamic architecture evolution. Further, we present an of apparent architectures and avoids much of the redundancy
incremental mechanism for generating the needed architectures encountered when the apparent architectures must be
and validate our approach with an implemented prototype. individually specified in full.
In section 2 we review related work on dynamic architecture.
I. INTRODUCTION In section 3 we discuss the need for separation of concerns.
The approach used for the modeling is described in section 4.
Some system designs benefit from architectures that allow Section 5 discusses the proposed model while section 6
some flexibility at run time. For example, systems with provides an example software architecture that illustrates the
clearly defined “modes” may exhibit different architectures in abstract model.
each operational mode. When these systems are modeled by a The contributions of this paper are an abstract architectural
single architecture, that architecture can accurately reflect the model and a statically defined mechanism for limited dynamic
implementation concerns of the end product, but not the evolution of the architecture. These contributions are
individual behavioral aspects. summarized in section 7.
We have been working on architectures for software
simulators applied to the simulation of manned exploration II. RELATED WORK
missions. This application domain exhibits architectural
changes as elements of the physical system are assembled,
disassembled, reassembled, and even destroyed as in the case Existing work with dynamic architecture tends toward
of a discarded component that burns up on reentry into earth's concrete architectures and runtime reconfiguration of the
atmosphere. This is more than rearranging components to software implementation. Often architectural change means a
obtain equivalent functionality. Instead, these changes result change in configuration that provides the same or similar
in new and often unique architectures. functionality, such as in the case of a fault-tolerant system.
The architecture of simulators in this application domain are An elegant example of this type of dynamic architecture is
strongly influenced by the architecture of the systems being described by Grondin, Bouraqadi, and Vercouter [7] who
simulated. Consequently the architecture of the simulator define a single model of the software system. A runtime
tends to be very dynamic. Traditionally architectures for engine uses the model as a goal that it attempts to satisfy in
these systems have been composite, with all elements that response to changes in the execution context.
may appear in the simulation present in a single architecture. Hirsch, Kramer, Magee, and Uchitel [8] apply modes as a
Such a view is concrete, representing the simulator as it would form dynamic configuration. A mode is a sub-architectural
be constructed. region of the architecture that can be replaced with another
Our intent is to construct abstract architectures that allow region in a process called a transition. Mode transitions differ
designers to work with high level views of the system. We from the arch-transitions we present in that mode transitions
want to consider the individual architectures as they are provide reconfiguration for the purpose of maintaining
exhibited by the system. In this view of architecture, a system existing functionality. That is, given a mode that provides a
has a single composite architecture that is the conjunction of a service, a transition on that mode will continue to provide the
set of exhibited architectures. An exhibited (or apparent) same service while utilizing different resources.
architecture being the architecture the system appears to have,
20
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
Wermelinger [9] describes a method of using chemical when a solution is actually deployed, the “world” or the
abstract machines to define dynamic architectures. Like many deployment environment may give the implementation
other dynamic ADLs, his method employs a central different functions, which are often beyond the control of
configurator that controls the dynamic aspect of the even the creators of the solution.
architecture. Wermelinger's configurator adjusts the We base our abstract architectural model on a not-so-novel
architecture in response to changes in available components, idea of separation of concerns. Our architectural model is
equivalent to our effector functions. Not addressed in this supported by the three key constructs of: architectural
paper is a method to select or restrict specific architectural elements, architectural composition, and architectural regions.
changes and it appears that all permissible architectural The architectural elements serve to capture the elements of the
changes will be reversible. architecture i.e., the components and the connectors that
In [10] Wermelinger, Lopes, and Fiadeiro describe a language define the component interactions. For each architectural
for architectural reconfiguration. Changes in configuration are element we capture the service specifications, dependency
implemented by scripts. Scripts are invoked at runtime by a specifications and the general constraints. The general
user or some automatic trigger mechanism. Consequently constraints are categorized into functional and non-functional
their language is not intended to provide a static description of constraints. Together with the service and dependency
the dynamic architecture. Interestingly, the language only specifications, the functional constraints captured as part of
provides a facility add or remove elements but not to move an general constraints identify the requirements of the “world”
element within the architecture. This appears to lose that the architectural element solves i.e., the “What”, while the
continuity of element instances during reconfiguration, non-functional constraints capture the system requirements
comparable to a loss of state in the implementation. that need to be satisfied for delivering the “machine” – i.e.,
Magee and Kramer [11] describe an approach to dynamic the “How”. The architecture composition and architectural
architecture using the Darwin ADL. Their approach embeds region constructs are intended to capture the form of the
constraints on dynamic configuration within the component architecture. These two constructs focus on capturing
specifications. Any assembly of components that is consistent information that is relevant for performing compositional
with these constraints is valid. This approaches constrains the analysis – their purpose being quite distinct from capturing
ability of the system to reconfigure to a lesser degree than what individual components do or need.
ours, and does not contemplate enumeration of the set of
possible configurations. IV. APPROACH FOR SPECIFICATIONS
Le Metayer [12] describes a graph based approach to
describing architectures. A collection of graph rewriting rules Our primary goal is to create an abstract model of software
(called the coordinator) define allowable changes that the architecture (i) to provide reasoning about component
architecture may undergo. These changes can be applied composition and (ii) to provide a basis for constraint based
iteratively to define any number of architectures. They apply architecture evaluation. An important secondary goal is to
graphs to individual architectures but not the architecture-of- support the reasoning about component substitution (i.e.,
architectures as we describe in this paper. component reuse and component evolution).
Software architectures are generally thought of in one of two
III. SEPARATION OF CONCERNS ways: as prescriptions or as descriptions. There are good
reasons for both approaches and the need for each is largely
Divide and Conquer has been widely acknowledged as a dependent on the use. The differences are as follows: an
fundamental strategy in software engineering and computer architectural prescription defines the important constraints on
science. We see it in sorting algorithms; it appears in the architecture – i.e., it defines important, but not necessarily
multiplication of polynomials. In fact it is the seed idea that all components and connectors, their critical properties
has spearheaded progress in operating systems and (though again, not necessarily all of them), and the critical
programming languages. However, the applicability of this relationships and interactions among the components of that
strategy to architectural design is unclear. architecture. What is prescribed is necessary; what is not
In this context it is important to discuss the Shanley principle mentioned is allowed as needed in completing the remaining
that was highlighted as a rule for efficient design by Arnoul de design at both the architectural and the lower levels of design.
Marneffe [3]. The idea behind the Shanley Principle is that An architectural description on the other hand defines the
one part can perform multiple functions. It has been complete architecture; what is not described is not allowed.
wonderfully explained by Jackson [1] as “the architecture of The former is usually under-constrained, while the latter is
the world has been designed with the fullest possible precisely constrained (though it may often be over-
application of the Shanley Principle”. While efficient design is constrained). The former is usually described with constraints
definitely our motivation, separation of concerns is not in while the latter requires a more descriptive (and often simpler)
contradiction of the Shanley Principle and that it effortlessly architectural language.
steps from Jackson’s, World (i.e., problem space from which We use a prescriptive approach for this research as the
we derive our requirements) to his Machine (i.e., the solution constraints provide an extremely useful tie between the system
space from which we create our system that satisfies these drivers and the architectural design, and provide a form of
requirements). Separation of concerns is important when we self-documenting rationale. Besides, given that an iterative
build the “machine” for managing complexity of the development model is fast becoming the norm rather than the
interrelationships in an “intransigently informal world”, but exception in industry, it seems that building a descriptive
21
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
architectural model would not be possible until the very last functional partitioning and also introduce the notion of object
iteration, and by then most of the key architectural and design orientation that helps identify the implementation classes later
decisions would already have been made. during development. The elements of an architecture are the
data, processing and connecting elements that have a physical
V. MODEL FOR SOFTWARE ARCHITECTURE existence and deliver some services that are either functional
or non functional in nature. In this model we have not
Our proposal for an architectural model is consistent with the differentiated data, processing and connecting elements but
initial Perry and Wolf definition of software architecture. We conflated them all into arch-elements.
propose three abstract constructs as the basis for our analysis: There is one issue however that may require structural
o Arch-element: Can be either a component or a connector differences: multiple connecting connectors. Connectors
(while their structure for purposes of modeling and have been usually thought of as point to point mechanisms
analysis is identical, they have distinct logical purposes, that provide the abstractions for communication interactions.
i.e., connectors represent interactions among However, that is not their only use. They may be used as
components). This construct represents basic elements in coordinators and mediators as well. For example, one could
the architecture. imagine a very complex connector that serves as a coordinator
o Arch-composition: An arch-composition represents a sub- of fault handling mechanism and instead of just one to one
connectors, there are obvious uses for many to one (multiple
architectural structure. As such it represents the
clients, one server), one to many (broadcast), and many to
substructure of an arch-element and must satisfy the
many (cooperating components negotiating or reaching
interface constraints of the elements involved. The rules
consensus) connectors, either with a fixed set of connections
of compositional completeness govern not only the
or an open-ended set of them. This is an important research
support of the arch-element interface, but the internal
issue that will need to be solved to complete our architecture
interdependencies as well.
model. And of course, connectors can be the subjects of
o Arch-region: An arch-region is an arbitrary set of arch- architectural composition just as processing and data elements
elements or arch-compositions and can overlap, contain are.
or be contained in other arch-regions. An arch-region The abstract model captures architectural elements as
provides a constraint scoping mechanism. As such, it arch-element =
represents a collection of arch-elements to which a set of (name, {service specifications },{dependency
constraints apply. specifications}, {general constraints })
It is obvious that system integration is an inherently complex As mentioned previously, an arch-element is qualified by the
process and there are no silver bullets for the problem. service specifications, the dependency specifications and the
However there is a lot that can be done to facilitate this general constraints. The service specifications essentially
difficult process. We propose to use the rationale in our capture the interface information so that other arch-elements
architectural model to document the assumptions about the can integrate and leverage the capabilities provided by the
components, the connectors and the global architecture arch-element being specified. The dependency specifications
structure so that the information is available to the system help capture the ‘needs’ of an arch-element i.e. services that a
integrator for making optimal decisions. Besides, the form in given arch-element depends on. The general constraints
our model will provide insight into the global architecture capture all the functional and non-functional constraint that
structure that could potentially provide guidelines to the arch-element needs to satisfy.
component developers. The non-functional aspects specified A service specification has a name, a set of input, output and
in our model would also capture information that would be general constraints associated with that service. Input and
useful during system composition. output constraints may define the information itself or
For the overall organization of the architecture, we introduce constraints on that information that is needed or provided by
the notion of an architectural region. Essentially it represents the specified service. Example I/O constraints might include
a collection of architectural elements and/or compositions to things like sorted lists of faculty descriptions, etc (of course in
which a set of constraints apply. The concept of regions a semi-formal notation). The service specification construct is
facilitates the specification of targeted rules for a sub- shown below.
architecture. These rules could be compositional rules such as service specification =
architectural styles or design patterns, as well as domain ( name,{input constraints },{output constraints },
specific constraints. They help localize constraints and make {general service constraints } )
system instantiation easier, as they can potentially help We separate out the dependency specifications from service
promote a loose form of packaging of a set of components. specifications even though dependencies are basically the
Regions influence the form of an architecture and will be same except they are usually not named. These dependency
elaborated further in section 5.2. specifications must be satisfied by the service specifications of
In the next two sub-sections we discuss the models for the the supporting architectural elements. This separates the
different aspects of our architecture prescriptions. formal service interface constraints from an arch-element’s
dependency interface constraints. The representation of the
A. The Elements: Components and Connectors dependency-specification is shown below.
A software architecture specification is partitioned into several
arch-elements. These arch-elements are driven initially by
22
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
dependency specification = The Attribute Constraints capture the data supported by the
({input constraints}, {output constraints}, {general arch-element. An individual attribute constraint is qualified by
dependency constraints } ) its name, the data elements associated with it and any
The Input Constraints for the Service and Dependency additional constraints that may be applicable. Information
specifications include the Input Data, Input Event and the Pre- about the data elements are captured in the data element
Condition constraints, while the Output constraints include the specification while general attribute constraints capture
Output Data, Output Events and the Post-Condition additional constraints on the data element or the attribute. As
constraints. The Pre-Condition Constraints capture the set of an example, the data entity ‘Address’ which is captured as an
conditions (as captured by the arch-element state) that need to attribute may be further qualified by the associated data
be satisfied for the service to begin execution while the Post- elements such as street name, city, zip code and country.
Condition Constraints capture the arch-element’s state that attribute constraints =
should be satisfied upon execution of the service. ( name, { data element specifications }, { general
General constraints can be functional constraints or non- attribute constraints } )
functional constraints, such as performance, fault tolerance, The Behavioral Constraints capture the behavioral aspects of
etc. They may also be topological constraints indicating an architectural element and is modeled using a state chart
placement in a distributed system. Obligations entailed by representation. The dynamic behavior of a component is
using a particular arch-element may also be represented. The modeled by the following quintuple and is termed as a
general constraints are shown below: behavioral unit which essentially represents a “unit of
general constraints = behavior”.
({functional constraints}, {non-functional constraints}) Behavioral unit =
As part of general constraints, the functional constraints are ( state, trigger, guard, effects, target )
intended to lump together different kinds of constraints that The Quality Attribute Constraints specifies the constraints on
are associated with the delivery of end user functional the quality attributes for the arch-element. These constraints
requirements. As the data managed by an arch-element is on the quality attributes are over and above the system’s
fundamental to the kinds of services that it supports, we capabilities, services and behavior captured in the model. It is
capture the data associated with an arch-element using the important to capture these constraints as a part of the
attribute constraints. Behavioral constraints ensure that the specifications because it has often been seen that systems need
arch-element specifications comprehend the various states to be re-designed because it fails to satisfy certain quality
associated with the arch-element. It is common experience attributes. Hence explicit knowledge of a component’s
that architectural mismatches often happen when integration is constraints would help in avoiding unacceptable system
done just by considering the API and not the implementation configurations.
logic of the associated methods. The functional constraints The Quality Attribute Constraints are composed of the
construct is shown below. Runtime Constraints and the Static Constraints. The Runtime
functional-constraints = Constraints captures the constraints of the arch-element that
({attribute constraints }, {behavioral constraints } are relevant/observable during the execution of the element.
The non-functional constraints are captured in terms of the On the contrary, the Static Constraints captures the constraints
Quality Attribute Constraints and the Deployment on the quality attributes of the arch-element that are not
Constraints. The Quality Attribute Constraints specifies affected by the runtime characteristics. Obviously these
the constraints on the quality attributes for the architectural constraints are optional for an arch-element as all of these
element. These constraints on the quality attributes are together may not make sense in different contexts.
over and above the arch-element’s services, dependencies The Runtime Constraints captures the Performance, Security,
and the functional constraints. It is important to capture Availability, Usability and Reliability related constraints. The
these constraints as part of the architectural specification Performance Constraints are responsible for capturing the
because it has often been seen that systems need to be re- responsiveness of the system related to transactions per unit
designed not because of any deficiency in supported time, arrival rates and distribution of service request,
functionality, but because they fail to satisfy requirements processing times, queue sizes and latency. The Security
associated with certain quality attributes such as reliability, Constraints captures the element’s ability to resist
availability and performance. Thus explicit knowledge of unauthorized usage while continuing to provide its services to
these constraints would help in avoiding unacceptable authorized users. The Availability Constraints captures the
system configurations. The Deployment Constraints on the constraints on the availability of the architectural element. The
other hand capture an architectural element’s deployment usability related constraints are captured in the Usability
related constraints such as installation requirements, Constraints. The Usability constraints are related to
platform dependencies etc. The non-functional constraints Learnability, Efficiency, Memorability, Error Avoidance and
construct is shown below. Error Handling. The Reliability Constraints captures the
non-functional constraints = constraints of the component related to its consistent
( {quality attribute constraints }, {deployment performance as per specifications.
constraints } ) The Static Constraints captures Modifiability, Portability,
In the rest of this section we elaborate the details associated Reusability, Integrability and Testability constraints of the
with some of the additional constructs mentioned previously. architectural element. The Modifiability Constraints captures
issues related to the ease of changing or extending
23
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
capabilities, ease of deleting capabilities, adapting to new as Windows XP. The Runtime Environment Constraint details
operating environments, and restructuring the internals of the the runtime environment information of the arch-elements
component. The support for the system’s ability to run under while the Runtime Libraries Constraint captures information
different computing environment is captured in the Portability about the runtime libraries required for correct operation. The
Constraints. The Reusability Constraints help specify the User Interface Constraint specifies the UI features that should
ability of the component to be used in different contexts. The be supported by the arch-element. The Installation Constraint
requirements related to the integration of components is captures the information of the installation requirements. It
captured in the Integrability Constraints while the Testability specifies information about the directory where the arch-
Constraints captures the testability related constraints. The element is to be installed, the system files that are modified,
testability related constraints are typically tied to the arch- the files that are placed in the system directory, the registry
element’s observability and controllability. changes (in the case of Windows applications) made, etc. The
The Deployment Constraints captures an arch-element’s Performance Monitor Constraint helps specify the details
deployment related constraints. The Deployment Constraints about performance monitors for the arch-element.
are partitioned into the Core Infrastructure Constraints and The Interaction Constraints are an aggregate of the Peripheral
Interaction Constraints. Constraints, the Network Support Constraints, the Database
The Core Infrastructure Constraints for an arch-element Constraints, the COTS Package Constraints, the Architectural
captures the requirements for installation of the element on its Element Constraints and the Data Transport Constraints. The
base platform. It specifies the basic installation requirements Peripheral Constraints details the peripheral dependencies of
for the component without consideration for its interaction the arch-element. For example, if an arch-element transmits
with other system components. Hence, satisfaction of the Core real-time data from a wireless computing platform, it would
Infrastructure Constraints specification does not imply proper require a wireless modem. The Network Support Constraints
functional operation of an arch-element. The Interaction captures information about bandwidth, throughput and other
Constraints on the other hand, captures the information about network related requirements for proper operation while the
how an arch-element interacts with other elements in the Database Constraints specifies the database(s) that the arch-
architecture. Satisfaction of all the Deployment Constraint element needs to interact with. The Middleware Constraints
specifications, which includes both the Core Infrastructure specifies the middleware requirements for the arch element
Constraint and the Interaction Constraint specification, implies and the COTS Package Constraints captures the dependencies
proper deployment of the component in the context of the on COTS packages. The Architecture Elements Constraints
overall architecture. The division of the Deployment identifies the other arch-elements that the arch-element being
Constraint into Core Infrastructure Constraints and Interaction specified interacts with. Finally, the Data Transport
Constraints was motivated by the goal of separately Constraints captures information about the way data is
addressing the issues of an arch-element’s own installation transported from the arch-element being specified to other
requirements versus its requirements for interaction with other arch-elements.
arch-elements. The information captured in these two sets of
constraints would help in reasoning over the deployment B. Form
requirements of the arch-element from these two distinct By the Perry Wolf definition, the form is a set of weighted
perspectives. These constraints are optional and should be properties and relationships among components and
used as needed for capturing the non-functional specifications. connectors. A form defines constraints on the components and
The Core Infrastructure Constraint is composed of the connectors and how they are placed relative to each other and
Computing Platform Constraint, the Dynamic Display how they interact.
Constraint, Operating System Constraint, Runtime Research and experience with building software over the years
Environment Constraint, Runtime Libraries Constraint, User has resulted in the codification of collective experience of
Interface Constraint, Installation Constraint and the skilled designers, architects and software engineers. These
Performance Monitor Constraint. The Computing Platform proven solutions to recurring design problems are popularly
Constraint captures information about the base platform on known as patterns. Different kinds of patterns have been
which the arch-element needs to be installed. For example, proposed – Architectural Patterns [5], Design Patterns [4] and
these constraints would specify that an arch-element should be Idioms. These help define the relationship between different
deployed on an Intel Core 2 Duo series machine at a certain components under given constraints and is relevant to the
clock frequency with 1GB of memory and 80 GB of hard disk form of a software architecture. They generally impose a rule
space. The Dynamic Display Constraint captures information on the architecture that specifies how the system will handle a
about the display requirement of the arch-element. It captures given aspect of functionality [2]. Architectural Style is another
information like the screen size, the vertical and horizontal concept that is relevant to the form of an architecture. Styles
scan frequency and viewing angle of the display for optimal essentially abstract archelement and the formal aspects from
viewing of the arch-element. These constraints are particularly various architectures. They are often less constrained than
important for graphics based arch-elements where display specific architectures. Different architectural styles such as the
with a high resolution is required for proper viewing. The pipe and filter, layered or blackboard promotes different
Operating Systems Constraint captures the possible operating quality attributes for a software system when they are defined
systems in which the arch-element can be installed and at a global level. Several architectural styles can also be
executed. For example, this constraint specifies whether a merged in a software architecture as long as the constraints of
particular software should execute on Windows 2000 as well the two styles do not conflict. Examples of styles in an
24
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
architecture are provided in Perry and Wolf [2] and by Perry new (derived) arch-configurations and existing (source) arch-
in [6]. Application of architectural styles helps define the form configurations. Of course the derivation of arch-
of an architecture. configurations can be carried out to any number of levels.
The key constructs of our model that are relevant to the form Moreover, derivation need not be idempotent, so performing a
of an architecture are architectural composition and single derivation repeatedly could yield many new
architectural region. As explained previously, architecture configurations.
composition represents the subarchitectural structure of an We represent the derivation of one arch-configuration from
archelement while architectural region provides a construct another by introducing connectors among arch-configurations.
scoping mechanism and represents a collection of arch Connectors in this role consist of two constraints, a predicate
element to which a set of constraints apply. These two and an effector function. The predicate restricts the source
constructs are demonstrated below arch-configuration and the effector defines how the derived
arch-composition = arch-configuration will differ from the source.
( name, { arch-elements }, { mappings }) Using connectors among arch-configurations in this way, an
arch-region = ( Descriptor, { arch-elements | arch- architecture consists of one or more explicit arch-
compositions }, { general constraints } ) configurations plus some number of derived arch-
While archcomposition and archregion are the two configurations obtained by applying connectors to explicit and
fundamental scooping concepts of our model, we also provide derived arch-configurations. A directed graph can be formed
a construct for capturing the generic form of an architecture. from the resulting architecture-of-architectures, where the
The purpose of this construct is to capture in a granular vertices of the graph are arch-configurations and the edges are
fashion the elements that make up form. connectors. Provided that the description of the differences
The form of an architecture can be influenced by both between pairs of arch-configurations is simpler than the arch-
functional as well as nonfunctional requirements. For a configurations themselves, the architecture as a whole is
given software architecture model, the form needs to be simplified.
specified at a global level and/or at a local level i.e. for an We use arch-configurations to capture various apparent
architectural region or subarchitecture , as for complex architectures exhibited by a highly dynamic system. A single
systems it may be impossible to specify the form at a global arch-configuration captures the apparent architecture of the
level. system over one or more intervals of time. At points where
A given style or a pattern is represented as a Form Unit in our two such intervals are adjacent there exists a transition from
model. Thus a subject observer pattern is a form unit with one apparent architecture to another. Since the architecture of
multiple Form Unit Mappings, where each form unit is each interval is captured by an arch-configuration, the
represented by an Architectural Element Pair, the Rule for the transition is naturally represented by a connector, and in the
relationship between the pair and the Cardinality between the context of dynamic architectures we refer to these connectors
pair. One arch-element is common across all the Form Unit as arch-transitions. Arch-transitions then, capture changes in
Mappings for the subject observer pattern and serves as the the apparent architecture of the system, and in our work with
Subject. The second component in the Arch Element Pair for simulators, a change in the physical architecture of the
the form unit mappings represents the Observers. simulated system. Thus many arch-transitions are ultimately
determined by the physics and design of the system being
C. Architecture-of-architectures simulated.
When many architectures are developed having a large Our approach to an architecture-of-architectures
number of elements in common, it is convenient to merge accommodates dynamic properties by introducing new
them into a single architecture-of-architectures. An individual architectures where implied by explicitly defined arch-
architecture within the composite is an arch-configuration and configurations and arch-transitions. To add a bit of formality
is represented by an arch-region. Utilizing arch- to this statement, assume an architecture a which has an arch-
configurations reduces redundancy by allowing a single arch- configuration c and arch-transition connector t. Let p and e be
element definition to appear in multiple architectures (arch- the predicate and effector of t. c' is an arch-configuration of
configurations). Additionally, corrections or improvements to architecture a if p(c) holds and c' is the configuration obtained
an arch-element immediately benefit all dependent by applying e to c.
architectures. This extension to architecture allows for many (possibly
In some architectures, specifically the NASA simulator infinitely many) architectures to be specified in a very
architectures we have been developing, significant compact form. The intuitive justification for this extension is
redundancy remains among the arch-configurations. The that the arch-transitions are capturing those changes that the
redundancy is a consequence of having distinct arch- physical system is capable of performing, thus limiting the
configurations that are closely related. These arch- possible arch-configurations to precisely those mandated by
configurations have a large portion of their substructure in the physics and design of the physical system. This is
common with differences limited to a few areas. We address precisely the behavior desired from a simulator. Although we
this redundancy by describing differences among arch- have introduced the possibility of an infinitely varying
configurations rather than providing complete descriptions of architecture, the limitations of the physical system has
each arch-configuration. We assume that at least one arch- constrained this set to be finite.
configuration exists and is fully described. Additional arch-
configurations can be described by the differences between
25
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
D. Rationale
The rationale in our architecture model is the set of
justifications for the choice of elements and formal aspects of
the architecture. A rationale ties architectural design decisions
to various system drivers – for example decisions may be tied
to functionality requirements from the user, non functional
system constraints, market requirements and business
strategies. In fact the constraints mentioned earlier in this
paper provide an extremely useful tie between system drivers
and the architectural design; they provide a form of self-
documenting rationale.
In our model we treat rationale as atomic units that may be
associated with any aspect of our specification. They are
sprinkled over every facet of our architecture. Off course
these can be later categorized into convenient groups but we
do not model rationale using either a hierarchy or
decomposition to reinforce the fact that justifications for an
architectural decision is often independent of the level of
abstraction for which a design decision is needed.
VI. APPLICATION OF ABSTRACT MODEL
We have constructed a prototype application to read and
analyze architectures. This prototype can evaluate the Fig. 1. Example Arch-Configuration Graph
derivation of selected arch-configurations and show the
architecture that is produced. B. Explicit Arch-configurations
In the examples that follow it will be apparent that the Fig. 2 is an excerpt from the architectural specification that
language accepted by the prototype adds some flexibility to produces the graph in Fig. 1. Configuration onpad is an
the description of arch-transitions, beyond what was described explicit arch-configuration for the pre-launch configuration of
in section 5. Specifically, arch-transitions are not limited to a the system. We can derive most other arch-configurations that
single predicate and effector function. Instead, both tasks are are needed from this initial arch-configuration. All of the
carried out incrementally by a sequence of statements in components needed to perform pre-launch simulation are
procedural fashion. The examples that follow illustrate how referenced here, the most important of which is fullstack, the
these statements are used. component that represents the complete vehicle assembly at
Our prototype has been applied to the specification of the time of launch. Additional simulation components and
architectures for simulators used in NASA's manned space their functions are: ISS (International Space Station);
exploration. Much of these simulator architectures reflect the environment, the physical properties of space, planets,
architecture of the physical systems being simulated. These moon(s), stars, etc.; simulator, those aspects of the system
physical systems undergo architectural changes as the vehicles which are not being simulated, including the simulation
reassemble into new configurations during operation. system itself. A trivial constraint onpad uniquely identifies
Additionally, some elements cease to exist as missions this configuration to be situated on the launch pad (i.e. it is a
progress, either because the element has been destroyed (such pre-launch configuration).
as during reentry), because a reconfiguration causes a physical
element to no longer have a physical embodiment (such as
fullstack discussed below), or because an element can no C. Arch-transitions
longer contribute usefully to the simulation and is removed for It can be seen from Fig. 1 that transition launch can be applied
simplicity (such as a discarded booster engine). Our example to configuration onpad to obtain the post-launch architecture
has been simplified for space and to focus on our use of arch- stage1. The difference between architectures onpad and
transitions. stage1 is subtle and mostly consists of the fact that fullstack is
not rigidly attached to the earth in configuration stage1. The
specification for arch-transition launch is shown in Fig. 2.
A. Architecture-of-architectures Graph Most arch-transitions will declare a global variable conf.
Fig. 1 shows a graph of arch-configurations within an When the evaluation of an arch-transition begins, the value of
architecture. This architecture describes a simulator for an conf is an arch-configuration identical to the source
Apollo-like vehicle from launch through docking with the ISS configuration. The work of the effector function is
(International Space Station) and return to earth. Nodes in accomplished by assigning new values to conf. Multiple
this graph are arch-configurations and edges are arch- assignments may be made, with each assignment prior to the
transitions. Configuration onpad is an explicitly specified final one providing an unfinished intermediate configuration.
arch-configuration. All other configurations are derived from The derived configuration produced by the transition is the
onpad by the application of arch-transitions. value of conf when evaluation of the transition is complete.
26
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
configuration onpad { the combined CM/LAS assembly a separate vehicle. The
component fullstack; rename function specifies a new name for a configuration in
component ISS; the architecture-of-architectures graph.
component environment; Validity checks are performed to ensure that the transition is
component simulator; appropriate, given the source configuration. These checks
constraint onpad; include: the CM/LAS assembly must not be an element of the
} configuration, that would indicate that an LAS abort transition
has already occurred; the LAS must exist somewhere in the
composition fullstack { configuration, otherwise it has been jettisoned and dropped
component cm; from the simulation; the LAS must not be an independent
component sm; element in the configuration, that would indicate that the LAS
component stage1; has been jettisoned.
component stage2; The effector function is accomplished in four steps. First, the
component las; CM and LAS are moved to become children of the
} configuration (as if they were no longer part of any larger
assembly). This is a convenience that avoids the need to
transition launch { specify exactly where in the source architecture these
global var conf; elements appear. A subsequent step combines the CM and
conf = rename(conf, stage1); LAS (from their now known locations) into a new composite
if (!has_constraint(conf, onpad)) return(false); element cm_las. Lastly a trivial constraint is added indicating
conf = remove_constraint(conf, onpad); that the derived configuration will represent an aborting
return(true); configuration.
} Transition LAS_abort is interesting because, generally, the
LAS can be used to effect an abort procedure anytime prior to
transition stage1_separation { being jettisoned. This includes the pre-launch configuration
global var conf; and extends usually sometime into the second stage burn.
conf = rename(conf, stage2); This period spans several arch-configurations. Activating the
if (!has_component(conf, fullstack)) return(false); LAS from each of these source configurations produces a
if (has_constraint(conf, onpad)) return(false); unique new architecture. Without arch-transitions, several
conf = replace(fullstack, {..stack_stage_two, ..stage1}); explicit arch-configurations are needed to capture each
return (true); possible resulting architecture. Here we use just one arch-
} transition that captures only the changes that need to be
applied to each source configuration. By applying this
transition LAS_abort { transition to each applicable source configuration (a process
global var conf; automated by our prototype), all consequent arch-
conf = rename(conf, launch_abort); configurations are included in the architecture.
if (exists(conf, cm_las)) return(false); Note that the graph in Fig. 1 shows launch_abort to be the
if (!exists(conf, las)) return(false); only arch-configuration resulting from the application of
if (find_parent(conf, las) != conf) LAS_abort. This is a simplification in the graph
return (false); representation indicating that the architecture that results from
conf = move(las, conf); each application of LAS_abort is logically the same even
conf = move(cm, conf); though details may differ depending on the source
conf = add_element(conf.cm_las, conf.cm, conf.las); configuration. Thus, launch_abort is actually a composite of
conf = add_constraint(conf, aborting); three arch-configurations.
return(true); Our prototype analysis tool can evaluate an architecture and
} produce an architecture-of-architectures graph. These graphs
can be useful to check for errors in the architecture. Problems
Fig. 2. Example Architectural Specification in the specification of transitions may introduce erroneous
configurations, transitions in unexpected locations, or missing
In the case of transition launch, there is one significant step in configurations and transitions. In our work with simulators,
the derivation, removing the onpad constraint. the nature of the system being simulated makes this kind of
Statement return(false) indicates a condition where the arch- validation easy to perform. The expected form of the graph is
transition predicate does not hold and therefore the arch- easily compared to expected system behavior.
transition is not valid for the source configuration. Statement The prototype can also synthesize an explicit arch-
return(true) indicates the predicate holds and the production configuration from any derived configuration. This allows
of a new derived arch-configuration is complete. designers to obtain a full view of any arch-configuration even
Transition LAS_abort captures the change that occurs when though the information is not directly available from the
the LAS (Launch Abort System) is activated. This transition specification. This is a useful feature that allows designers to
applies to several configurations and has the effect of making easily explore and validate the ramifications of their design
decisions.
27
ACoTA First International Workshop on Automated Tailoring and Configuration of Applications
VII. SUMMARY NSF CISE grants SRS Grant CCF-0820251 and SOD IIS-
0438967.
In this paper we propose an architectural model for
documenting the specifications of architectural elements, the REFERENCES
form of the architecture as well as the justifications for the
different design decisions. Our intent is to provide an abstract [1] Jackson, M, “The World and the Machine”, Proceedings of the
model sufficiently rich to support the compositional 17th International Conference of Software Engineering, Seattle,
requirements of architectures and to be able to reason about, WA, 1995
analyze, and evaluate architectures described in our abstract [2] Perry, D. E., Wolf, A. L., “Foundations for the Study of Software
model. To better realize this intent we have utilized an Architectures”, ACM Software Engineering Notes, 17, 4,
architecture-of-architectures so that we can construct separate October 1992, 40-52
[3] de Marneffe, P. A., “Holon programming: A Survey”, Universite
architectures to independently specify the transient behaviors de Liege, Service Informatique, 1973
of the system. We introduce connectors among these several [4] Gamma E., Helm R., Johnson R., Vlissides J., “Design Patterns
architectural configurations so that we can specify one Elements of Reusable Object-Oriented Software”, Addison-
architecture as a variation, evolution, or modification of Wesley, 2002
another. In our work with simulators we find it is natural to [5] Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M.,
think of the system architectures in this way, by what changes “Pattern Oriented Software Architecture”, Wiley Series in
from one architecture to the next. We have validated our Software Design patterns, 2001
approach using existing simulators and have constructed a [6] Perry, D. E., “A Product Line Architecture for a Network
prototype architecture analysis tool to support them. Product”, ARES III: Software Architectures for Product
Families 2000, Los Palmos, Gran Canaria, Spain, March 2000,
Springer-Verlag, LNCS 1951, p39-52
VIII. FUTURE WORK [7] G. Grondin, N. Bouraqadi, and L. Vercouter, “Madcar: an
abstract model for dynamic and automatic (re-)assembling of
We are currently expanding the scope of our example component-based applications,” in 9th Int. SIGSOFT
architecture in space exploration to model a larger portion of Symposium on Component-Based Software Engineering
the system. From this detailed model we are exploring the (CBSE2006), No 4063, LNCS. Springer, 2006, pp. 360–367.
possibility of generating executable simulators. In addition, [8] D. Hirsch, J. Kramer, J. Magee, and S. Uchitel, “Modes for
our current work indicates that the composite configurations software architectures,” in of Lecture Notes in Computer
displayed in Fig. 1 are a useful feature that benefits Science. Springer, 2006, pp. 113–126.
[9] M. Wermelinger, “A simple description language for dynamic
understandability. That introduces a need to consider the architectures,” in ISAW ’98: Proceedings of the third
analytical implications of arch-configuration that represent international workshop on Software architecture. New York,
sets of unique configurations united by arbitrary semantic NY, USA: ACM, 1998, pp. 159–162.
(user) considerations. We are also evaluating the need for [10] M. Wermelinger, A. Lopes, and J. L. Fiadeiro, “A graph based
additional architectural constructs. In particular, a construct to architectural (re)configuration language,” SIGSOFT Softw.
act as a modifier of architectural transitions much like Eng. Notes, vol. 26, no. 5, pp. 21–32, 2001.
transitions are modifiers of arch-configurations. [11] J. Magee and J. Kramer, “Dynamic structure in software
architectures,” SIGSOFT Softw. Eng. Notes, vol. 21, no. 6, pp.
ACKNOWLEDGEMENT 3–14, 1996.
[12] D. Le Metayer, “Software architecture styles as graph
grammars,” SIGSOFT Softw. Eng. Notes, vol. 21, no. 6, pp.
The research described here was funded in part by NASA 15–23, 1996.
grant NNX08AC48G under the direction of Toby Martin, and
28