See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/4068924

Moving Towards Quality Attribute Driven Software Architecture Reconstruction

Conference Paper · December 2003

DOI: 10.1109/WCRE.2003.1287236 · Source: IEEE Xplore

CITATIONS READS
34 251

3 authors, including:

Liam M O'Brien
Geoscience Australia
91 PUBLICATIONS 1,468 CITATIONS

SEE PROFILE

All content following this page was uploaded by Liam M O'Brien on 25 February 2015.

The user has requested enhancement of the downloaded file.

 Moving Towards Quality Attribute Driven
Software Architecture Reconstruction
Christoph Stoermer Liam O’Brien Chris Verhoef
Robert Bosch Corporation Software Engineering Institute Free University of Amsterdam
4500 Fifth Avenue Carnegie Mellon University De Boelelaan 1081a
Pittsburgh, PA 15213 USA 4500 Fifth Avenue 1081 HV Amsterdam
+1 412 268 3949 Pittsburgh, PA 15213 USA The Netherlands
cstoerme@sei.cmu.edu +1 412 268 7727 +31 20 4447760
lob@sei.cmu.edu x@cs.vu.nl

ABSTRACT • Checking the conformance of an as-designed

There are many good reasons why organizations should architecture with an as-built architecture, for instance
perform software architecture reconstructions. However, in outsourcing situations as part of a product
few organizations are willing to pay for the effort. Software acceptance procedure
architecture reconstruction must be viewed not as an effort • Tracing of architecture elements to the source code, for
on its own but as a contribution in a broader technical instance to measure the impact of architectural changes
context, such as the streamlining of products into a product However, only few organizations invest in SAR efforts. In
line or the modernization of systems that hit their the cases we are aware of, SAR is a facet in a much broader
architectural borders. In these contexts software architects organizational context where software architectures play an
frequently need to reason about existing systems, for important role in achieving particular business goals.
example to lower adoption and technical barriers for new Therefore it is worth understanding the organizational
technology approaches. We propose a Quality Attribute context and the role of software architecture to define an
Driven Software Architecture Reconstruction (QADSAR) effective SAR concept.
approach where this kind of reasoning is driven by the
analysis of quality attribute scenarios. From our extensive experience we have identified several
contexts where SAR can be applied. Our experience
This paper introduces a quality attribute driven perspective includes: improving the understanding of the software
on software architecture reconstruction. It presents a architecture of existing systems, improving the architecture
technical reasoning framework and illuminates the itself, assessing quality attribute characteristics of these
information that is required from the reconstruction process systems, improving the documentation of the architecture
to link the knowledge gained back to the business goals of of these systems, and more.
an organization. The paper illustrates the techniques by
presenting a real-world case study. We experienced that the QADSAR approach is the right
mechanism for driving reverse engineering of existing
Keywords systems. Indeed, Tahvildari, et al., outline an approach that
Architecture, Architecture Reconstruction, Architecture uses non-functional requirements or quality attributes, such
Views, Product Lines, Quality Attributes, Quality Attribute as performance and modifiability to guide the
Driven Analysis. reengineering process [37]. Bengtsson and Bosch outline a
similar approach for reengineering based upon quality
1 INTRODUCTION attribute scenarios that drive architecture transformation
Much research has been done in software architecture [4].
reconstruction (SAR) in the past several years In our case we are applying a quality attribute driven
[5,11,16,17,18,21,23,25,27,31,32] and many techniques approach to architecture reconstruction and goal-based
and methods have been developed along with tools to system understanding. The goal of the reconstruction is to
support them [10,15,22,29]. But why are only few provide information that will assist in the analysis of the
organizations carrying out architecture reconstructions? quality attributes.
There should be many reasons for organizations to perform In the past, several SAR efforts have related their work
software architecture reconstructions. For example: with more common/standard notations such as UML [31].
• Re-documenting the architecture of existing systems The goal of QADSAR is not to align architecture
visualizations with mainstream notations, such as UML.
The key to our approach is to enable architecture analysis
of existing systems via a quality driven approach. The approach is the analysis of quality attributes on a
analysis is motivated by the knowledge that software software architecture level [9]. It further allows the
architectures are driven by business goals that are participation of various architecture stakeholders with
incorporating quality attribute scenarios. specific roles, such as developers, project managers,
The remainder of the paper is organized as follows. Section and marketing experts. However, the architectures of
2 outlines representative application contexts for SAR. existing systems may not be documented very well or
Section 3 outlines the quality attribute driven (QAD) may be inaccurate due to the erosion of design and
analysis framework that guides the SAR. Section 4 implementation.
combines the QAD analysis with SAR and provides the Again, SAR is not the primary concern that caused the
fundamental QADSAR steps. In Section 5 we apply initial effort at an organization. But SAR contributes to
QADSAR in a real-world case study. Section 6 outlines our the overall goal by providing architecture
current research and future work. Section 7 concludes the documentation that is appropriate for the analysis of
paper. business goals.
2 APPLICATION CONTEXTS • Exclusive decision among competing existing
From areas, such as migration to product lines, IT systems. A typical situation that is occurring quite
assessments, competing systems and system modernization, frequently today is the merger of organizations with
we have collected four representative contexts for similar product portfolios. A decision for a favorable
applications of SAR: product is done depending on a set of criteria. Besides
quantitative approaches, for example based on cost of
• Streamlining existing products into product lines. producing or maintaining a product, there are
Product lines embody a strategic reuse model of qualitative approaches based on the software
products sharing a market segment. One key practice architecture comparison of the existing products [35].
in product lines is the definition of software product The criteria for qualitative approaches are mainly
line architecture. Software architectures for product quality attribute driven, for example the exchange of
lines reflect common and variable parts of systems and communication protocols (modifiability), or the
offer appropriate design constructs. Product lines processing of a particular number of transactions per
typically evolve out of the commonalities among day (performance). One of the difficulties in
existing products in a specific market segment. Several comparing existing software architectures is the
products may be delivered by an organization before a heterogeneity of architecture descriptions in terms of
systematic migration to a product line takes place. In terminology, concepts, architecture notations, and level
order to evaluate the potential for creating a product of detail.
line from existing products it is necessary to analyze To compare software architectures SAR provides a set
their architectures and compare the commonalities and of comparable architecture views in heterogeneous
differences across the product line candidates. environments. These views are used for the quality-
Although SAR is not the primary intention of the driven criteria analysis.
organization, in this situation it offers a vehicle for
architects to reconstruct the architecture in • System Modernization. Studies show that between
environments where it is poorly documented. This is 50% and 90% of software maintenance involves the
done so as to be able to reason about software understanding of the software being maintained [38].
architecture commonalities and differences of existing One major reason for these high costs is due to
products. Software architecture aspects of the current architecture erosion which results in the
system are used as an input in the definition of the new maintainability of the software system being
software product line architecture. For elaborate deteriorated. Software architects have to understand,
treatments on product line migration refer to [12, 36]. analyze, and reason about the as-built software
architecture of a system to modernize it [34].
• IT assessments of existing systems. Organizations SAR can support the understanding of existing
evaluate the alignment of existing systems with systems. It allows software architects to form
business goals. Business goals have a strong influence increasingly abstract models of a system and the
on quality attributes, such as modifiability, resulting artifacts from SAR can be used to analyze
performance, and availability. Often quality attributes quality-driven requirements that are caused by the
are competing and result in tradeoffs. Changing demands of system modernization.
business goals require a reassessment of tradeoffs,
sensitivity points, and risks that are inherent in each
system. Experiences show that an efficient assessment These application contexts don’t represent a complete list.
Our purpose is to illustrate the common characteristics of between reasoning and reconstruction:
application contexts in which SAR contributes to the
The goal is to assist software architects in the analysis of
overall goal. The characteristics are:
quality attribute driven goals in poorly documented
• Software architectures play a significant role within an architecture settings.
organization. Software architectures are abstractions of The goal has implications on criteria for completeness, the
implementations in the solution (design) space and at types of elements to be reconstructed, and criteria for poor
the same time the first implementations in the problem documentation that result in a SAR effort:
(requirements) space. At the transition of requirements
and design they are recognized by various stakeholders • Completeness. Reconstructing software architectures
of an organization as a major communication arena. require criteria for completeness: How many
• The analysis of software architectures is quality architecture views have to be reconstructed to
attribute driven. Business goals are primarily sufficiently describe the architecture? The yardstick for
incorporated as quality goals that shape the software completeness is the analysis framework. The goal is
architecture of a product. Evaluating quality attributes not to reconstruct every architecture aspect of a
software system but to provide the necessary
reveals the tradeoffs and risks that are involved in
information required by targeted quality attribute
architecture design decisions.
models of the analysis framework.
• Software architecture documentation, if it exists at all,
often describes the as-built architectures insufficiently • Types of elements. A question arising in many SAR
and in many cases inaccurately. A precondition for efforts relates to the type of elements, relations, and
reasoning about software architectures and quality notations that should be reconstructed: Is it sufficient
attributes is the existence of good architecture to describe the architecture in layers represented as
descriptions that provide accurate information about box-and-arrow drawings? Again, the approach answers
the as-built systems. this question from the perspective of the analysis
framework. For example, performance formulas
require specific performance data and may not take
All three characteristics have to be considered upfront to an into account layers and graph aspects at all. The
application of SAR. Figure 1 illustrates the informal element types, relations and particular properties, such
connection between SAR and the application contexts, as throughput, are given by the quality attribute models
assuming that a SAR is adding value. The effort is divided of the analysis framework.
into two parts: reasoning and reconstruction. The reasoning
part consists of the application context and the QAD • Re-documentation. The criteria for poor
Analysis Framework. The analysis framework is a means to documentation are given by the ability of the
evaluate systems in the achievement of particular quality documentation to provide sufficient information to the
attribute goals, for example security and scalability goals. analysis framework: Are required element types
The analysis framework steers the architecture sufficiently described to feed a particular quality
reconstruction to make particular aspects of existing attribute model? Software architecture documentation
software visible. For example, a performance model might might sufficiently describe element types of a set of
require threads, queues, waiting points, and performance quality attribute models (for example, analyzed in the
properties such as throughput and deadlines. SAR has to design process) but may lack element types of a model
provide the information inquired by the QAD Analysis that is currently under investigation.
Framework. 3 QAD ANALYSIS FRAMEWORK
The application contexts introduced above require the
inquiries analysis of existing systems. The analysis is driven by
business goals, articulated in quality attributes that should
Application Context be evaluated on existing systems. Evaluations require a
Existing Recon- systematic way to reason about the achievement of quality
Reasoning QAD Analysis goals. We denote the “systematic way” as a framework that
System struction
Framework
guides software architects to evaluate or design
architectures. The analysis framework that we refer to in
our approach adopts the architecture analysis concepts as
provides information proposed in [2].
Figure 1: Reasoning and Reconstruction Quality attributes are refined into quality attribute
scenarios.
Figure 1 also illustrates the goal of an analysis driven
approach that is founded in the informal connection “A quality attribute scenario is a quality attribute
requirement of a system. It consists primarily of a stimulus represent specific information regarding an element,
and a response. The stimulus is a condition that needs to be such as throughput, thresholds, deadlines, and race
considered when it arrives at a system and the response is conditions. Again, elements and properties in the
the (measurable) activity undertaken after the arrival of the analysis process are obtained from the existing system.
stimulus. In addition to the stimulus and response, a quality Note, that the terminology of elements and properties
attribute scenario includes the source of the stimulus, the of Quality Attribute Models might differ from the
context under which the stimulus occurs, the artifact that is terminology already used in the existing system.
stimulated, and how the response is to be measured” [3].
• The responses of the Quality Attribute Models for
An example scenario is: The system has to be able to elements and properties of an existing architecture are
accept and execute user commands 250 ms after used to determine if the existing system or part-system
power-on. The source of the stimulus is the power-on satisfies the requirements as provided by the quality
switch, the stimulus is power-on, the context is startup, the scenarios.
response is normal mode of operation, and the measure is Figure 2 illustrates this connection. The QAD Analysis
250ms until user input can be accepted. Framework steers the inquiries from the existing system to
Quality attribute scenarios are input to a corresponding feed the Quality Attribute Model with the required
Quality Attribute Model, such as a performance model. To architecture elements.
achieve particular qualities that are addressed with inquiries
scenarios, developers decide to structure the software in a
particular way. For example, to meet the 250ms deadline in
QAD Analysis Framework Existing
the above scenario, a designer might decide to use an System
architecture tactic such as reduce computational overhead quality
values Quality Attribute control
attribute tactics
by avoiding in-depth memory checks during start-up. scenarios
Models

The authors of [2] introduce the notion of tactics as a response provides

means to control a quality attribute response by feedback to tactic
manipulating some aspect of a quality attribute model
through architecture design decisions. A tactic is an elements, properties
responses
architecture strategy that “is concerned with the
relationship between design decisions and a quality
attribute response”. There are collections of tactics Figure 2: Analysis Framework
available to achieve particular quality attribute goals (for At this point we would like to subsume architecture
further details refer to [3]). Different quality attributes have elements, relations, properties, and tactics under the
quality attribute models with different precision. For concept of architecture views. An architecture view is a
example performance models can be fairly formal (queuing representation of a set of system elements and relations
models) while usability models try to model user among them [8]. An architecture view has a defined
satisfaction, which can be very informal. notation that specifies element types (such as component,
Quality Attribute Models can be used in the design as well task, or pattern), relation types (such as ‘consist of’, or ‘is-
as in the analysis of software systems. The context in case a’), and property items (such as throughput values).
of an existing system is distinguished from a design process 4 COMBINING QAD WITH SAR
in the following ways: So far we considered SAR as a black-box that has to
• The architecture tactics are not free to select. In the provide information about existing systems to support the
design process the software architect has to select the QAD Analysis Framework. The application contexts of
appropriate tactic to satisfy the required responses. In Section 2 presented some stumbling blocks:
the case of an existing system the tactics are already • Architects of existing systems may no longer be
realized and have to be extracted from existing available,
sources. The extraction is guided by proposed lists of
tactics for each quality attribute model. These lists can • the system is eroded from the as-designed architecture,
be obtained from [3]. and

• Each Quality Attribute Model requires particular • the documentation contains poor information related to
architecture elements and their properties. For a quality attribute model under investigation.
instance, architecture elements for a performance To tackle the architecture view extraction the following
model are units of concurrency which can be four strategies (ST) might apply depending on the
implemented as processes and threads. Properties application context:
• ST1 - Extract the required information from available QAD Analysis Framework SAR
architecture documentation. The success of this
1) Scope
activity depends on the documentation quality and the Identification
relevance of the contained information in regards to Source 2) Source Model
the as-built system. Model Extraction

Required By
• ST2 - Interview the expert. This is probably the easiest QUAD Analysis Abstraction 3) Source Model
Model
way to obtain answers if the expert is still available. Framework Abstraction

• ST3 - Conduct a reconstruction workshop. Architecture

Views
4) Element and
Property Instantiation
Architectures have several stakeholders with expertise
in particular areas. The workshop typically sets at the 5) Quality Attribute
Evaluation
beginning a common understanding of software
architectures and the purpose of reconstruction before
Legend
the information is extracted in a group effort.
method step method flow

• ST4 - Undertake an architecture reconstruction from remark connects remark

available sources, such as source code. This strategy is step product produces
the most labor-intensive strategy. It requires a mixture
of all strategies above in addition to the source Figure 3: The QADSAR Steps
elicitation. However, the results are more accurate,
The approach continues with step 2 (Source Model
reflect the as-built architecture, and offer traceability
Extraction) to extract source elements from available
from the code back to the design.
sources. Source elements are typically the constructs of the
Our approach follows the last strategy on the basis of an as- implementation language like functions, classes, files, and
built system. However, it is a guided extraction process in directories. Relations describe how the source elements
the way that not all information is elicited but only the relate to each other, such as call relations between functions
elements and properties relevant for the analysis or read accesses by methods on attributes. Besides static
framework. aspects there are also dynamic aspects like function
execution time, or process relations. The static relations are
Applications of SARs are performed in various ways typically generated by existing tools like source code
because SAR is embedded in a broader organizational parsers or lexical analyzers. Dynamic information is
context. For example, SAR in a product line migration generated by profiling or code instrumentation techniques.
context might be performed over promising assets of The extracted elements and relations constitute the Source
existing systems [12]. SAR in an architecture conformance Model.
setting [35] reconstructs the views that are specified in an
as-designed architecture document [24]. In any case, there Elements of the source model are in most cases too fine-
is a set of core steps that is used in most SAR applications. grained for architecture reasoning. Therefore, step 3
The steps comprise: (Source Model Abstraction) has to identify and apply
aggregation strategies to abstract from detailed source
• Step 1: Scope Identification. views. There exist several aggregation strategies [Harris 95
WCRE], which highly depend on the existing system and
• Step 2: Source Model Extraction. the architecture views that should be extracted. Various
techniques exist such as Relation Partition Algebra and
• Step 3: Source Model Abstraction.
Tarski Algebra for manipulation of relational information
• Step 4: Element and Property Instantiation. [13,14,19]. A common abstraction technique is aggregation
of coherent functionality. Other techniques capture
• Step 5: Quality Attribute Evaluation. independent branches in the calling graph or aggregate
functions attached to an execution process. There could be
Figure 3 provides an overview of the steps. The trigger for low-level aggregation techniques like collection of all files
the method is the QAD Analysis Framework that requires in a directory or extracting files and functions following
architecture information to perform the quality attribute certain naming conventions. The aggregated elements
analysis. Step 1 (Scope Identification) sets the scope for constitute the Aggregation Model.
SAR. The scope identifies the architecture viewtypes [8] The aggregation model consists of entities and relations
and the part (or parts) of the system (or systems) that that are collapsed. They might be associated with
should be reconstructed. The identification depends on the architecture elements but they are not explicitly denoted as
quality attribute scenarios, the related quality attribute architecture elements with particular properties. To obtain
models, and the type of system. the required architecture views we have to assign in step 4
(Element and Property Instantiation) the element types application software adaptable to the communication
specified by the view-type of the analysis framework. software predetermined by the OEM. Therefore, one task of
Elements are now layers, tasks, ‘consist of’ relations, etc. this project is to investigate the modifiability of the
We have to assign required properties, such as throughput, application software with regards to other communication
deadlines for tasks, etc. Further on we would like to software packages.
associate tactics that are achieved with a particular set of
The concrete quality attribute scenario for the analysis is:
architecture elements.
The organization has to replace the communication
The results of step 4 feed the QAD Analysis Framework for package from vendor V1 by a package from vendor V2 in
step 5 (Quality Attribute Evaluation) that is performed one day. The source of the stimulus is the organization, the
with the particular quality attribute scenarios, quality stimulus is organization requires to exchange
attribute models, and the corresponding architecture tactics. communication package, the context is during deployment
The tactics are used to detect mechanisms in the time, the response is modification without affecting other
reconstructed views that support the quality attribute functionality, and the response measure is number of
scenarios. modules affected and effort. To determine the viewtypes
that we require for the analysis we still need to construct
5 CASE STUDY
the quality attribute model for modifiability.
To illustrate the usage of QADSAR we present a case study
that we performed in the domain of automotive body Modifiability is strongly influenced by the different types
components, such as window lifters, climate controls, of dependencies between modules of a system. To analyze
sunroofs, and door locks. The broader context of the case the impact of a change the knowledge of these
study is embedded in a multi-year effort to streamline dependencies is of importance. A dependency among
automotive body products into product lines. Product lines modules exists, if a modification to some aspects of module
require from organizations strategic usage of practice areas A requires a modification in module B to accommodate the
in software engineering, technical management, and modification to module A. We then say that module A
organizational management [7]. A key practice area is depends in some way on module B. Here is a list of possible
‘software architecture definition’ which produces the first dependency types that we summarize from [3]:
design artifacts that begin to place requirements into a
solution space. Besides a top-down approach to design • Syntax dependencies
software architectures based on domain analysis efforts and Syntax dependencies between modules A and B can be
sets of specific product requirements and business goals the either data (type/format of data is consistent) or service
architects wanted to explore and analyze the software (signature of services are consistent) related.
architecture of a representative set of existing products.
• Semantics dependencies
The analysis was done on an automotive body door unit
that was at the beginning of the case study project already Semantic dependencies between module A and B can
at a testing stage. A Door Control Unit (DCU) is the be either data or service related.
hardware/software unit that is physically located in both the • Sequence-of-use dependencies
front and rear driver- and passenger-side automobile doors.
The DCU provides a rich set of features, such as the control Sequence-of-use dependencies can be either data or
of window positions, exterior mirror position, interior control related.
lighting, seat-belt indication, door-open indication, exterior • Interface identity dependencies.
door lamps, low-battery indication, seat positions and seat
temperature control. The units for each door are networked Interfaces between module A and B must be consistent
and arbitration is performed between (possibly conflicting) (same name or handle).
requests from different units.
• Runtime location dependencies.
We apply in the following the reconstruction steps as
Runtime location dependencies (on same or different
proposed in Section 4.
processor or located within different processes)
Step 1 - Scope Identification between module A and B must be consistent.
The DCU consists of three packages from different
• Quality-of-service or quality of data dependencies.
vendors: Boot Loader, Communication, and Application.
The communication package is typically predetermined by Quality-of-service or quality of data dependencies
the OEM (Original Equipment Manufacturer) and has to be involve the service or data provided by the modules.
deployed by all suppliers that provide networked devices
for a specific model platform. Suppliers, following a • Existence-of-module dependencies.
product line approach, are interested in keeping their Existence-of-module dependencies involve module A
 or B being present for the other to function properly. communication paths, or abstract common services.
Common to the tactics are strategies to reduce and manage
• Resource behavior dependencies. the dependencies (as previously enlisted) between modules.
Resource behavior dependencies relate to resource The tactics help us in the following reconstruction process
behavior (such as memory usage, resource ownership) to identify what to look for in the existing system and to
between module A and module B. create particular views. Applied to this context:
A quality attribute model for modifiability is more informal
• Maintain semantic coherence – this tactic has not to be
than a model for performance that could rely, for example,
evaluated because the communication package is
on rate monotonic scheduling or queuing models [1].
already determined to be separated by the OEM.
From the quality scenario, the dependency types, and the
• Isolate expected changes – that is: is something
type of system under investigation we are able to determine
actively done in the application package to mitigate
the viewtypes. We select from the more general
changes.
dependency list above the dependency types that are useful
for the DCU software and the particular quality attribute • Hide information – for example, is there an explicit
scenario. model to separate interfaces from their realizations.
• Syntax dependencies - both, data and functions with Step 2 - Source Model Extraction
parameters can be elicited from a module view. Source model extraction is a well-known step in
architecture reconstruction ([10,31]). There are many
• Semantic dependencies – Contracts about content (data
program tools available to extract the information needed
and service) are difficult to extract. However, a good
for a source model ([20,33,42]). The tools used depend on
point to start is the analysis of denoted interfaces with
the language in which the system is implemented, which in
semantic descriptions.
this case is C. From the type of the language in which the
• Sequence-of-use-dependencies – for data: dataflow system is implemented, and the required viewtypes, we can
views; for service: interaction diagrams or state identify a set of elements (such as files, variables, functions
machine views. etc.) and relations (such as calls, contains, includes, etc.) to
extract.
• Interface identity dependencies – not of relevance in
this context. Most of the extraction tools provide the ability to output
their analysis results in a text file, which can be
• Runtime location dependencies – typically presented in manipulated using a scripting language, such as perl
a deployment view. Location dependencies exist in [40,41], into the format required by a reconstruction tool.
terms of different configurations for driver and One format frequently used is the Rigi Standard format
passenger side. However, for the particular (RSF) [28] (a tuple-based data format in the form of
communication package it is of no further interest. “relation <entity1> <entity2>”).
• Quality-of-service –or quality of data dependencies, The extracted information was loaded into our
Existence of module dependencies, and resource experimental reconstruction tool ARMIN (Architecture
behavior dependencies, that require concurrency Reconstruction and MINing), that we are currently
views, are not further considered in this paper. building for QADSAR. The Figures (5, 6, 7, and 8) are
However, it is obvious, that a modifiability analysis is screenshots presented by ARMIN. The figure notation,
frequently not independent from a performance such as relation conventions, is analogous to Rigi [30].
analysis. For example, resource behavior might require
scheduling assumptions. An exchange of a Step 3 - Source Model Abstraction
communication package following a rate monotonic The reconstruction of any system involves several activities
scheduling might require different execution time for abstracting from the source level information, which
budgets. consists of the set of elements and relations, to higher-level
views of that information. These activities include, for
Due to space and illustration purposes we concentrate on example, aggregation, pattern matching, analyzing
the analysis by using several module views. documents to assist in identifying abstractions, and
Modifiability might be achieved in a software system by interviewing developers and maintainers to assist in
different architecture tactics. Examples to achieve identifying abstractions. Figure 4 illustrates the different
modifiability for the quality attribute scenario of this case abstraction levels. The “File+” aggregation subsumes local
study are: maintain semantic coherence, isolate expected information inside files (such as static functions and local
changes, and hide information. Examples for other variables) to hide details that are not architecturally
modifiability tactics are: use a virtual machine, limit relevant. Files are composed to sub-layers (L-1), layers (L-
0), and finally the DCU system (System) according to the
as-designed software specification.

System

L-0
Decomposition

Abstraction
L-1

File+

Source Model

Figure 4: Abstraction Model

The resulting aggregation is illustrated in Figure 4. The
content of the collapsed relations between the application
Figure 6: Module View - Syntax Dependencies
and the communication package are illustrated in Figure 5.
To detect the ‘hide information’ tactic we try to isolate
from the application specific interface files that manage the
access to and from the communication package. The result
is illustrated in Figure 7.

Figure 5: Software Packages

Parts of the content of the collapsed edge between the
Application and the Communication package are illustrated
in Figure 6. The top directory (Application -> Figure 7: Module View - Interface Identification
Communication) is part of the system abstraction level of Finally, the quality attribute scenario identified in step 1
Figure 4. Below that is the L-0 level (for example Data- expects a response measure in terms of ‘number of modules
>LAN) followed by the L-1 and File+ levels. At the lowest affected’. For this we extract a dependency layout for the
level are, for example, calls relations (FrontDoorReq -> LAN part of the communication package, as illustrated in
WindowMoveReq). Figure 6 allows a detailed syntax Figure 8 and analyze the application modules that access
dependency analysis. the ‘LAN’ module. All modules above ‘LAN’ are
accessing the ‘LAN’ component unidirectional. The
‘Diagnosis’ and ‘uC_Config’ modules have bidirectional
relations whereas the LAN Common part accesses ‘LAN
Common’. Note, that Figure 8 doesn’t show relations
among modules other than ‘LAN’.
 scenario that captured one of the business goals of the
organization. Based on the scenario and type of system we
developed a quality attribute model and defined the
required architecture viewtypes and elements. The specific
tactics for modifiability where used to detect mechanisms
in the existing system that support the business goal. The
final evaluation resulted in an improvement effort of the
existing system to support the quality attribute scenario
sufficiently.
6 CURRENT AND FUTURE WORK
Based on our work in architecture reconstruction, software
product lines and software architecture analysis, we are
currently undertaking research to address the demands of
formal and informal quality attribute analysis of existing
systems by incorporating software architecture
reconstruction techniques. We are currently doing and plan
to continue work on:
ƒ Investigating the relationships between the quality
attribute analysis and the architecture views that would
need to be reconstructed to support the analysis.
ƒ Developing a support tool (ARMIN) for QADSAR
Figure 8: Module View - Affected Modules with export mechanisms to use specialized analysis
Step 4 – Element and Property Instantiation tools for particular quality attributes, such as
The generated entities and relations of step 3 might be performance tools [39]. ARMIN is a successor for the
associated with architecture elements, such as layers, Dali Architecture Reconstruction Workbench [10].
subsystems, design patterns, etc., but they are not explicitly 7 CONCLUSIONS
denoted as architecture elements with particular properties. The QADSAR approach establishes the link between
This capability is important, for example, to export models Quality Attribute Driven Analysis and architecture
to formal performance analysis tools, such as TimeWiz reconstruction. The business goal driven approach of
[39]. For the modifiability part of this case study it is system understanding provides an efficient way to steer the
sufficient to use the generated entities and relations from reconstruction process by providing the required viewtypes
step 3. for a particular system. The quality attribute related
Step 5 – Quality Attribute Evaluation architecture tactics are an efficient way to infuse the
Using the module views from step 4, the quality attribute reconstruction and analysis process to measure the response
model for modifiability and the quality attribute scenario for particular quality attribute scenarios. The response
from step 1 with the set of modifiability tactics, we are now measure is linked back to the business goals of an
able to perform the evaluation. Strictly speaking, the organization.
evaluation already started in step 4 with the generation of The case study has shown the application of QADSAR for
the module views. a modifiability scenario in an embedded system.
The two tactics that could support the communication Applications for further quality attribute scenarios are
package exchange are: isolate expected changes and hide derivable with the techniques of Quality Attribute Models
information. Both tactics reduce the dependencies and the and their related architecture tactics.
number of modules affected by changes. However, both We believe that from a detailed investigation of a particular
tactics are not identifiable in the analysis of Figures 7 and quality attribute and from the type of system involved
8. QADSAR provides a substantial contribution to leverage
Figure 7 shows that there is no explicit notion of interface SAR in a concrete organizational context.
identifiable, e.g. no separation of interface and REFERENCES
implementation. Several attempts to capture an interface by 1. Bachmann, F.; Bass, L. and Klein, M. Illuminating the
different aggregations failed. An analysis of Figure 8 with Fundamental Contributors to Software Architecture
the developers illuminated that changes are likely to be Quality, CMU/SEI-2002-TR-025, Software
expected in more than a dozen modules. Engineering Institute, Carnegie Mellon University,
The case study started with the analysis of quality attribute 2002
2. Bachmann, F.; Bass, L. and Klein, M. Deriving Bookshelf, IBM Systems Journal, Vol. 36, No. 4, pp.
Architectural Tactics – A Step toward Methodical 564-593, November 1997.
Architectural Design, CMU/SEI-2003-TR-004,
16. Guo, G.; Atlee, J. and Kazman, R., A Software
Software Engineering Institute, Carnegie Mellon
Architecture Reconstruction Method, Proceedings of
University, 2003
the First Working IFIP Conference on Software
3. Bass, L.; Clements, P. and Kazman, R. Software Architecture (WICSA1), San Antonio, Texas, February
Architecture in Practice, 2nd Edition. Reading MA: 22-24, 1999 pp 225-243.
Addison Wesley, 2003.
17. Harris, D.R.; Reubenstein, H. B. and Yeh, A. S.,
4. Bengtsson, P. and Bosch, J., Scenario-based Software Recognizers for Extracting Architectural Features from
Architecture Reengineering, Proceedings of the 5th Source Code, Proceedings of the 2nd Working
International Conference on Software Reuse (ICSR5), Conference on Reverse Engineering, 1995.
IEEE, pp. 308-317, 2-5 june, 1998.
18. Harris, R.; Reubenstein, H. B. and Yeh, A. S., Reverse
5. Bowman, T.; Holt, R. C. and N. V. Brewster, Linux as Engineering to the Architectural Level, Proceedings of
a Case Study: Its Extracted Software Architecture. the International Conference on Software Engineering
Proceedings of the International Conference on (ICSE), pp 186-195, April 1995.
Software Engineering, Los Angeles, May 1999.
19. Holt, R., Structural Manipulations of Software
6. Buschmann, F.; Meunier, R.; Rohmert, H.; Architecture using Tarski Relational Algebra,
Sommerlad, P. and Stal, M., Pattern-Oriented Software Proceedings of the Working Conference on Reverse
Architecture, New York, NY: John Wiley & Sons, Engineering, Honolulu, Hawaii, pp 210-219, October
1996. 12-14 1998.
7. Clements, P. and Northrop, L., Software Product 20. Imagix Corporation’s Imagix 4D:
Lines, Addison Wesley, 2002 http://www.imagix.com/
8. Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; 21. Kazman, R. and Carrière, S. J., Playing Detective:
Ivers, J.; Little, R.; Nord, R. and Stafford, J., Reconstructing Software Architecture from Available
Documenting Software Architectures: Views and Evidence, Journal of Automated Software Engineering,
Beyond, Addison Wesley, 2002. pp 107-138, April 1999.
9. Clements, P.; Kazman, R. and Klein, M., Evaluating 22. KLOCwork inSight:
Software Architectures, Addison Wesley, 2002. http://www.klocwork.com/Accelerator.htm
10. The Dali Architecture Reconstruction Workbench: 23. Krikhaar, R. L., Software Architecture Reconstruction,
http://www.sei.cmu.edu/ata/products_services/dali.htm Ph.D. Thesis, University of Amsterdam, 1999.
l
24. Kruchten, P. The ‘4+1’ View Model of Software
11. Eixelsberger, W.; Ogris, M.; Gall, H. and Bellay, B., Architecture, IEEE Software 12, 6, November 1995.
Software architecture recovery of a program family,
25. Laine, P. K., The Role of Software Architecture in
Proceedings of the International Conference on
Solving Fundamental Problems in Object-Oriented
Software Engineering, pp 508 –511, Kyoto Japan,
Development of Large Embedded Systems,
April 1998.
Proceedings of the Working IEEE/IFIP Conference on
12. Faust, D. and Verhoef, C. Software Product Line Software Architecture. Amsterdam, The Netherlands,
Migration and Deployment, Software – Practice & pp 14-23, August 28-31, 2001.
Experience, Published by John Wiley & Sons, Ltd,
26. Lassing, N., Architecture-Level Modifiability
2003.
Analysis, PhD Thesis, Vrije Universiteit Amsterdam,
13. Feijs, L. M. G. and Krikhaar, R. L., Relation Algebra 2002,
with Multi-Relations, International Journal of http://www.cs.vu.nl/~nlassing/research/thesis.pdf
Computer Mathematics, 70, pp 57-74, 1999.
27. Mendonça, N. C. and Kramer, J., Architecture
14. Feijs, L. M.. G. and van Ommering, R. C., Theory of Recovery for Distributed Systems, SWARM Forum at
Relations and its Applications to Software Structuring, the Eight Working Conference on Reverse
Phillips Research Internal Report, 1994. Engineering, Stuttgart, Germany, October 2001.
15. Finnigan, P. J.; Holt, R.; Kalas, I.; Kerr, S.; 28. Müller, H. A.; Mehmet, O. A.; Tilley, S. R.; and Uhl,
Kontogiannis, K.; Mueller, H.; Mylopoulos, J.; J. S. A Reverse Engineering Approach to System
Perelgut, S.; Stanley, M. and Wong, K., The Portable Identification. Journal of Software Maintenance:
 Research and Practice 5, 4, December 1993.
29. The Portable Bookshelf: http://swag.uwaterloo.ca/pbs/
30. The Rigi Tool: http://www.rigi.csc.uvic.ca/
31. Riva, C., Reverse Architecting: An Industrial
Experience Report, Proceedings of the Seventh
Working Conference on Reverse Engineering,
Brisbane, Australia, pp 42-50, November 23-25, 2000.
32. Sartipi, K. and Kontogiannis, K., A Graph Pattern
Matching Approach to Software Architecture
Recovery, Proceedings of the IEEE International
Conference on Software Maintenance (ICSM 2001),
Florence, Italy, pp 408-419, November 7-9, 2001.
33. Scientific Toolworks Inc’s Understand for C/C++/
Java /Fortran/Ada: http://www.scitools.com/
34. Seacord, R. C.; Plakosh, D.; and Lewis G. A.,
Modernizing Legacy Systems, SEI Series in Software
Engineering, Addison Wesley, 2003.
35. Stoermer, C.; Bachmann, F. and Verhoef, C, SACAM
– The Software Architecture Comparison Analysis
Method, CMU/SEI-2003-TR006, (to be published).
36. Stoermer, C. and O’Brien, L., MAP- Mining Assets for
Product Line Evaluations, Proceedings of the Third
Working IFIP Conference on Software Architecture
(WICSA 01). Amsterdam, Netherlands, 2001.
37. Tahvildari, L.; Kontogiannis, K. and Mylopoulos, J.,
Quality-driven software re-engineering, Journal of
Systems and Software, vol. 6. Issue 3, June 2003.
38. Tilley, S. and Smith, D. B. Perspectives on Legacy
System Reengineering, Software Engineering Institute,
Carnegie Mellon University, 1995, available at:
http://www.sei.cmu.edu/reengineering/lsysree.pdf
39. TimeWiz: http://www.timesys.com.
40. Wall, L. and Schwartz, R. L., Programming Perl,
O’Reilly & Associates, Inc., 1991.
41. Wall, L.; Christiansen, T. and Schwartz, R. L.,
Programming Perl, 2nd Edition, O’Reilly & Associates,
Inc., 1996.
42. Windriver’s SNiFF+: http://www.windriver.com/

View publication stats