A Quantitative Evaluation of the Impact of Architectural Patterns on Quality Requirements

Abstract

When designing software architectures, an architect relies on a set of pre-defined styles commonly named architectural patterns. While architectural patterns embody high level design decisions, an architectural tactic is a design strategy that addresses a particular quality attribute. Tactics; in fact, serve as the meeting point between the quality attributes and the software architecture. To guide the architect in selecting the most appropriate architectural patterns and tactics, the interactions between quality attributes, tactics and patterns should be analyzed and quantified and the results should be considered as decision criteria within a quality-driven architectural design process. In this paper, we propose an approach for a quantitative evaluation of the support provided by a pattern for a given targeted set of quality attributes.

Full text

1 École de Technologie Supérieure, Montreal, Canada
2 Université du Québec à Montréal, Montreal, Canada
A QUANTITATIVE EVALUATION OF THE
IMPACT OF ARCHITECTURAL PATTERNS
ON QUALITY REQUIREMENTS
Mohamad Kassab1, Ghizlane El-Boussaidi1 and Hafedh Mili2
Abstract When designing software architectures, an architect relies on a set of
pre-defined styles commonly named architectural patterns. While architectural
patterns embody high level design decisions, an architectural tactic is a design
strategy that addresses a particular quality attribute. Tactics; in fact, serve as the
meeting point between the quality attributes and the software architecture. To
guide the architect in selecting the most appropriate architectural patterns and tac-
tics, the interactions between quality attributes, tactics and patterns should be ana-
lyzed and quantified and the results should be considered as decision criteria with-
in a quality-driven architectural design process. In this paper, we propose an
approach for a quantitative evaluation of the support provided by a pattern for a
given targeted set of quality attributes.
Key words: architectural patterns; architectural tactics; quality requirements; arc-
hitectural design.
1 Introduction
In the process-oriented and goal-oriented software development approaches, user
requirements are established based on an analysis of business goals and of the ap-
plication domain. Subsequently, architectures of the desired systems are designed
and implemented. One of the primary goals of the architecture of a system is to
create a system design to meet the required functionality, while satisfying the de-
sired quality. In fact, if we consider a system’s architecture as a set of architectural
decisions, the most significant ones concern the satisfaction of quality attributes
[1].
When designing software architectures, an architect relies on a set of idiomatic
patterns commonly named architectural styles or patterns. A Software Architec-
tural Pattern defines a family of systems in terms of a pattern of structural organi-
zation and behavior [3]. More specifically, an architectural style determines the
vocabulary of components and connectors that can be used in instances of that
style, together with a set of constraints on how they can be combined [2]. Many
common architectural patterns are described in [3, 4, 7, 10, 19, 20]. Common ar-

chitecture patterns include Layers, Pipes and Filters, Model View Controller
(MVC), Broker, Client-Server and Shared Repository.
While architectural patterns embody high level design decisions, an architec-
tural tactic [13] is a design strategy that addresses a particular quality attribute. In-
deed tactics serve as the meeting point between the quality attributes and the soft-
ware architecture. In [8], the authors define an architectural tactic as an
architectural transformation that affects the parameters of an underlying quality
attribute model. “The structure and behavior of tactics is more local and low level
than the architectural pattern, and therefore must fit into the larger structure and
behavior of patterns applied to the same system” [9]. Implementing a tactic into a
pattern may affect the pattern by modifying some of its components, adding some
components and connectors, or replicating components and connectors [9].
Architectural patterns have been described using different frameworks (see e.g.
[10], [11], [20]). A common framework to describing patterns includes the name,
an example, the problem, the structure and the dynamics of the solution, and the
consequences of using a pattern expressed in terms of its benefits and its liabili-
ties. Hence the selection of an architectural pattern is qualitatively driven by the
properties it exhibits [17] and the architecture knowledge and experience with pat-
terns. To guide the architect in selecting the most appropriate architectural patterns
and tactics, the interactions between quality attributes, tactics and patterns should
be analyzed and quantified and the results should be considered as decision crite-
ria within a quality-driven architectural design process. In this paper, we propose
an approach for a quantitative evaluation of the support provided by a pattern for a
given targeted set of quality attributes.
The paper is organized as follows. We start by the quantitative mapping of
quality attributes into architectural tactics where we consider not only the positive
contribution of tactics to implement the qualities but also the potential conflict
among qualities due to the introduced tactics (Section 2), then we relate the archi-
tectural patterns to the tactics based on quantitative evaluations of the impact of
incorporating the latter within the former (Section 3). The quantitative impact of
incorporating the quality into architectural patterns is then calculated through a
matrix transformation method using the data from the quality-tactic and tactic-
pattern quantified relations (Section 4). Section 5 discusses related work, and Sec-
tion 6 provides conclusion and the future work discussion. The approach is dem-
onstrated throughout the paper through the analysis of the impact of incorporating
both “Performance” and “Security” qualities into Pipes-Filters, Layers, MVC and
Broker patterns.
2 Quality-tactics interaction
Quality is “the totality of characteristics of an entity that bear on its ability to satis-
fy stated and implied needs” [12]. Software Quality is an essential and distinguish-

ing attribute of the final product. Many approaches [12, 14, 22] classify software
quality in a structured set of characteristics which are further decomposed into
sub-characteristics. In [24], quality taxonomy was built out of many inputted ap-
proaches starting from the ISO 9126-1 [12] to define the root nodes for the quality
taxonomy (External Quality, Internal Quality and Quality in Use).
Tactics on the other hand are measures taken to improve the quality attributes
[13]. For example, introducing concurrency for a better resource management is a
tactic to improve system’s performance. Similarly, Authentication and Authoriza-
tion are popular tactics to resist unwanted attacks on the system and improve the
overall security. In [13], the authors list the common tactics for the qualities:
Availability, Modifiability, Performance, Security, Testability and Usability.
Typically, systems have multiple important quality attributes, and decisions
made to satisfy a particular quality may help or hinder the achievement of another
quality attribute. The best-known cases of conflicts occur when the choice of a
tactic to implement certain quality attribute contributes negatively towards the
achievement of another quality. For example, decisions to maximize the system
reusability and maintainability through the usage of “abstracting common servic-
es” tactic may come at the cost of the “response time”. “Authentication” is a clas-
sical tactic to achieve Security, but it may come on the cost of Performance and
Usability; as in the case of requiring additional ID. Therefore, architects must deal
with tradeoffs, priorities and interdependencies among qualities and tactics before
selecting some tactics that may achieve one quality and hinder another. In this pa-
per, we present these interdependencies empirically using three point scale
adopted from [14]; where +1 indicates that if the tactic is implemented then a posi-
tive contribution (support) is given to the quality; -1 indicates that if the tactic is
implemented then a negative contribution (hinder) is given to the quality; and 0
indicates that the tactic has no impact on the quality.
In Figure 1 we used the Softgoal Interdependency Graph notations [14] to illu-
strate the quality / tactics relationship on Security and Performance qualities. We
used the same set of tactics recommended in [13]. In addition, we incorporated our
observations towards the interdependencies between security / performance quali-
ties due to the derived tactics.
For example, the Security tactic “Implementing Identification for Attacker” re-
quires an audit trail, which is a space consuming; thus the value -1 was assigned
between this tactic and Performance quality. The Security tactics “Authorization”
and “Authentication” have negative effects on the response time of the system,
and thus the value of -1 was assigned between these tactics and the Performance
quality.
On the other hand, while “Maintaining Multiple Copies” tactic contributes po-
sitively to the achievement of performance, each copy increases the risk of reveal-
ing confidential data, and thus a value of -1 was assigned between this tactic and
Security quality.

Fig.1 Impact of Security and Performance Tactics
3 Tactics - Architectural patterns interaction
For a given quality attribute, the tactics are organized into sub-sets called catego-
ries in [13] and design concerns in [18]. Captured qualities can be realized through
satisfying these design concerns. For example, performance is divided into three
design concerns: resource demand, resource management and resource arbitration.
A design concern by itself is realized through the implementation of a set of prop-
er tactics. Each tactic is a design option for the architect [13] to satisfy a particular
concern. For example, some tactics that support the “Resource Management” de-
sign concern are: Introduce Concurrency, Maintain Multiple Copies of either data
or computations and Increase Available Resources.
Tactics are considered as the building blocks from which architectural patterns
are composed [13]. While an architectural pattern is commonly defined by its
components, their interactions and interrelationships and their semantic, its im-
plementation includes a combination of tactics depending on the pattern’s objec-
tives. For example, the Broker pattern implements the modifiability tactic “Use an
Intermediary” by introducing the Broker component which acts as an intermediary
between clients and servers to provide location-transparent service invocations [8].
Nevertheless patterns can impact individual tactics by making it easier or more
difficult to implement them [9]. Indeed the changes due to a tactic’s implementa-
tion within a pattern may-at worst-break the pattern’s structure and/or behavior.

To study the relationship between tactics and patterns, we analyze a pattern to
evaluate the support it provides to help implementing a tactic. In [15], the authors
identified six types of changes that a pattern’s structure or behavior might undergo
when a tactic is implemented:
 Implemented in: The tactic is implemented within a component of the pattern.
Actions are added within the sequence of the component.
 Replicates: A component is duplicated. The component’s sequence of actions is
copied intact, most likely to different hardware.
 Add, in the pattern: A new instance of a component is added to the architecture
while maintaining the integrity of the architecture pattern. The new component
comes with its own behavior while following the constraints of the pattern.
 Add, out of the pattern: A new component is added to the architecture which
does not follow the structure of the pattern. The added actions do not follow the
pattern.
 Modify: A component’s structure changes. This implies changes or additions
within the action sequence of the component that are more significant than
those found in “implemented in”.
 Delete: A component is removed.
In this paper, we adopt the five point scale from [15] to identify the impact magni-
tude of incorporating tactics within architectural patterns, where +2 presents
“Good Fit” category, +1 presents “Minor Changes” required for the incorporation,
-1 presents “Significant changes” required for the incorporation, -2 presents “Poor
Fit” category and 0 presents that the tactic and the pattern are basically orthogonal.
The impact is defined as a function of number of participants impacted as listed in
Table 1.
Table 1: Impact magnitude as a function of number of participants impacted [15].
Change Type
Number of Changes
Impact Range
Implemented in
1
+2 to +1
Replicates
3 or less
+2 to +1
More than 3
+1 to 0
Add, in the pattern
3 or less
+2 to +1
More than 3
+1 to 0
Add, out of the pattern
3 or less
0 to -1
More than 3
-1 to -2
Modify
3 or less
+2 to -1
More than 3
0 to -2
Tables 2 and 3 summarize our findings on the impact of implementing Security
and Performance tactics (using the scale described above) on pipes and filters,
Layered, MVC and Broker patterns.

Table 2: Impact of Incorporating Security Tactics into Pipes/Filters, Layered, MVC and Broker
patterns
Pipes / Filters
Layered Architecture
MVC
Broker
Security Tactics: Resisting Attacks
Authenticate Users
-2
+1
-2
+2
Authorize Users
-2
-2
-2
-2
Limit Access
+1
+1
+1
-2
Limit Exposure
+2
+2
-2
-1
Maintain Data Confidentiality
-1
-1
-1
0
Security Tactics: Detecting Attacks
intrusion detection
0
0
0
+1
Security Tactics: Recovering From
an Attack
Identification of Attacker
-2
-2
-2
-2
Restoration
-2
-1
0
+2
Average
-0.75
-0.25
-1
-0.25
Table 3: Impact of Incorporating Performance Tactics into Pipes/Filters, Layered, MVC and
Broker patterns
Pipes / Filters
Layered
MVC
Broker
Performance Tactics: Resource Demand
increase computation efficiency
-1
-1
+1
+1
reduce computational overhead
-1
-1
+1
-2
manage event rate
-1
-1
+1
-2
control frequency of sampling
+1
+1
+1
+1
Performance Tactics: Resource Manage-
ment
introduce concurrency
+2
+1
+1
0
maintain multiple copies
-2
-1
+1
0
increase available resources
0
0
0
0
Performance Tactics: Resource Arbitration
Scheduling Policy
-1
-1
+1
+1
Average
-0.375
-0.375
0.875
-0.125
For example, The Pipes and Filters architectural pattern provides a structure for
systems that compute a stream of data [10]. Each computation is encapsulated in a
component (filter). Data is passed between adjacent filters through connectors
(pipes). Computations transform one or more input streams into one or more out-
put streams, incrementally. There are no shared states between filters (stateless),
and there is no central control in this pattern. In order to implement authorization,
a new component must be introduced to manage role profiles along with new con-

nections to each filter component. In addition, changes are required within exist-
ing filters to enable them to communicate with the new introduced component.
These changes mean that significant work is required to implement authorization
in this pattern; thus authorization is considered as a poor fit for the Pipes and Fil-
ters pattern as it represents a major “Add, out of the pattern” scenario and modifi-
cations to the existing components and thus -2 value was assigned.
Because of the “stateless” nature for the filters, this poses as a challenge when
implementing the “restoration” tactic which aims at bringing the system to a latest
correct state. In that case, it usually makes most sense to restart processing of that
data from the beginning. If one must implement this tactic, then states must be de-
fined for each filter and a mechanism must be created to restore a filter to the
proper state when it comes back up. That may require a monitoring process. These
changes involve major changes to components, plus possible major “Add, out of
the pattern” and “Modify”. Hence a value of -2 was assigned. On other hand,
pipes-filters pattern naturally supports concurrent execution. Each filter can be
implemented as a separate task and potentially executed in parallel with other fil-
ters [3]. The performance may be improved with filters running on different pro-
cessors and processing data in an incremental and parallel way, i.e. a filter can
work on partial results of its predecessors [16]. A value of +2 was assigned.
Regarding the Layers pattern, this is a widely used pattern. The Layers pattern
structures an application by decomposing it into groups of subtasks where each
group of subtasks is at a particular level of abstraction [10]. In other words,
Layered Architecture is an organized hierarchy, each layer providing service to the
layer above it and serves as a client to the layer below [3]. Because of Layers ar-
chitecture organization, implementing the “Authenticate users” tactic is relatively
easier than in Pipes and Filters. Indeed this tactic can be added as an additional
layer on top of the existing ones; changes to the existing architecture are limited to
its top layer and the new layer is within the structure of the pattern [15]. This is an
example of (Add, in the pattern); and thus (+1) was assigned as a value. On other
hand, as Layered Pattern supports layers of access, this limits the exposure by not
placing all the logic and data into one layer. The spreading of layers among differ-
ent hosts is recommended though to minimize the probability of an attack. A value
of +2 was assigned for the difficulty of incorporating Limit Exposure in Layered
architecture.
The MVC pattern divides an interactive application into three components [10]:
1) The model which encapsulates the core functionality and data; 2) Views which
display the model information to the user; and 3) Controllers which handle user
input and which are associated to views. The consistency between the model and
its views is ensured using a change-propagation mechanism. Because the model
component encapsulates core data and functionality, in order to implement the
“Limit Exposure” tactic, this component needs to be broken into different compo-
nents each with limited services. The components which will assume the model
are preferably to be distributed among different hosts to limit the possibility of at-
tacks. Such an implementation changes the pattern structure and behavior (“Ma-

jor”, Add, out of the pattern) and thus a value of -2 is assigned. On other hand, de-
pending on the interface of the model, a view may need to make multiple calls to
obtain all its display data [10]. This negatively impacts the response time to user
requests and, hence to the Performance requirement. The response time may be
improved by caching data within views. This is a “Minor” modification to an ex-
isting component; thus a value of +1 was assigned to “Manage Event Rate” tactic.
4 Calculation of the Impact of Architectural Patterns on quality
attributes
We will now compute the quantitative impact of architectural patterns on quality
attributes combining the data from the quality-tactic and tactic-pattern quantified
relations. In the previous section, we discussed the latter impact considering each
quality in isolation from the rest of the set of qualities that are aimed for the sys-
tem. Averaging the values of impact of tactics against the patterns in the above
analysis yields a value ranging from -2 to 2 representing how much the pattern is
accommodating for the quality’s tactics in abstract; with the value of -2 represents
the least accommodating case, and the value of +2 represents the most accommo-
dating.
For example, averaging the values for impact of Security tactics against the
four patterns in Table 2 revealed that:
 Both Layered and Broker patterns are the most accommodating patterns for Se-
curity tactics.
 MVC is the least accommodating pattern for Security tactics.
Similarly for Performance, averaging the values for impact of Performance tac-
tics against the four patterns in Table 3 revealed that:
 MVC is the most accommodating pattern for Performance tactics.
 Both Pipes/Filters and Layered are the least accommodating patterns for Per-
formance tactics.
While this analysis is important for the architect as it provides quantitative evi-
dences that can be used to optimize his architectural choices, it is still ignorant to
the positive/negative interdependencies in the quality-tactics relationship as a ma-
jor dimension to be considered when it comes to the architect’s choices. We pr o-
pose to consider the quality-tactics relation in conjunction with tactics-patterns re-
lation through a matrix multiplication operation that yields the impact of
architectural patterns on quality attributes.
Let A be the matrix of the impact values of the tactics on architectural patterns;
A is composed of a set of atp values where atp is the impact value for the tactic t on
the pattern p. In addition, let B be the matrix representing the quality-tactics rela-
tionship; B is composed of a set of bqt values where bqt represents the impact value

of the tactic t on the quality q. Then the matrix representing the impact of incorpo-
rating quality attributes in architectural patterns is calculated as:
C = (AB) / ||Total number of Tactics||
An element in C (e.g. cij ) is the scalar product of the ith row of A with the kth
column of B; divided by the total number of tactics being considered for the sys-
tem.
The results from this calculation represent quantitatively the impact against
each pattern p for each quality q (defined in total set of qualities Q being consi-
dered for the system) in the presence and relativity to the rest of all other qualities
defined in set Q. It is important to note that the numbers in the result matrix
(quality vs. pattern) are relative to the rest of the set of qualities to be considered
for the system. That is, if we choose to consider adding more qualities to the sys-
tem, for example, then these numbers will change accordingly.
Table 4 shows the results of our calculation following the above method on the
impact of incorporating both Security and Performance Tactics into Pipes-Filters,
Layered, MVC and Broker patterns. The results reveal that when both Security
and Performance are to be considered as the key qualities of the system, then:
 MVC is the most accommodating pattern for the Performance quality while
implementing all tactics of both Security and Performance in this system (it
scored the highest among the four patterns against Performance).
 Broker is the least accommodating pattern for the Performance quality while
implementing all tactics of both Security and Performance in the system (it
scored the lowest among all patterns against Performance).
 Layered is the most accommodating pattern for the Security quality while im-
plementing all tactics of both Security and Performance in this system (it
scored the highest among the four patterns against Security).
 MVC is the least accommodating pattern for the Security quality while imple-
menting all tactics of both Security and Performance in the system (it scored
the lowest among all patterns against Security).
Table 4: Impact of Incorporating Security / Performance into selected architectural patterns.
Security
Performance
Pipes-Filters
-0.25
0.3125
Layered
-0.063
0.125
MVC
-0.562
0.875
Broker
-0.125
-0.125
These results are based on the assumption that all the tactics implementing each
quality are to be accommodated for the system. In practice; though, the architect
may choose to select only a subset of the tactics to satisfy the quality achievement.

The numbers derived from our approach can be useful for the architect to tune his
selection of tactics as will be discussed in the future work section.
5 RELATED WORK
Many patterns have been proposed and described in the literature (e.g. [3], [10],
[4], [11], [20]). However, patterns consequences descriptions are incomplete, not
searchable or cross-referenced and, mostly qualitative [9]. They are often classi-
fied according to the specific classes of systems they enable to construct (e.g. vir-
tual machines). Our work aims at providing a quantitative method for comparing
and evaluating architectural design choices and in particular by using information
drawn from tactics descriptions as given in [13] and the quantitative impact of
these tactics on quality attributes and architectural patterns. The SEI Attribute
Driven Design method [13] [18] describes an iterative process to designing soft-
ware architecture where at each iteration of the process, the architect chooses arc-
hitectural tactics and patterns that satisfy the most important quality attributes for
that iteration. However the architectural decisions such as the selection of a pat-
tern is mainly based on a qualitative evaluation and the architect expertise and
knowledge.
Our analysis is based on the scale introduced in [15]. Harrison and Avgeriou
propose a general model that relates patterns to tactics and quality attributes. In
particular the proposed framework concentrates on the interaction between tactics
and patterns and especially how tactic implementations affect patterns. Our ap-
proach may be seen as complementary to this framework as we consider both the
impact of a tactic on a pattern and the impact of the tactic on other quality
attributes.
Our work is closely related to Bode and Riebisch’s work [17]. They present a
quantitative evaluation of a set of selected architectural patterns regarding their
support for the evolvability quality attribute. They refine the evolvability attribute
into sub-characteristics and relate them to some properties that support good de-
sign. The selected patterns are used in a case study and the resulting design is as-
sessed to determine the impact of these patterns on these properties. A matrix of
impact values of patterns on evolvability sub-characteristics is inferred from the
matrix relating properties to sub-characteristics and the matrix relating properties
to patterns. For each pattern, the impact on evolvability is calculated from the re-
sulting matrix as an average of all impact values on evolvability sub-
characteristics. Our approach differs from Bode and Riebisch’s approach in the
way the analysis of the relationship between patterns and quality requirements was
carried out; they use a particular case study and an evaluation by experts while our
approach is based on the analysis of the generic structures and behavior of tactics
and patterns. Besides, we consider more than one quality attribute in our analysis.

6 Conclusion and Future Work
In this paper, we proposed a quantitative approach to selecting architectural pat-
terns starting from a subset of quality requirements. This approach relies on a
quantitative assessment of the impact of architectural tactics on quality require-
ments, in the one hand, and the impact of incorporating these tactics in architec-
tural patterns, in the other hand. We illustrate the approach using four common
architectural patterns and assessing their support for both Security and Perfor-
mance quality requirements. Though this is a preliminary quantitative investiga-
tion of the architectural patterns when considering more than one quality require-
ment, we believe that it’s a key step towards a quality-driven architectural design
process.
In the future, we plan to extend the ontology in [23] to integrate our quantita-
tive approach to support the selection process of a set of tactics and patterns that
satisfies a set of quality attributes while considering the trade-offs among quality
attributes, tactics and patterns. Furthermore we plan to refine the approach in two
ways. First we would like to refine our analysis and results by considering sub-
characteristics of quality attributes (e.g. analyzing availability and confidentiality
as sub-characteristics of security). Second, the numerical value that is assigned to
a pattern regarding its support for a quality attribute depends on the selected sub-
set of tactics to achieve the targeted attribute. In this paper we derived this value
by considering all the tactics related to an attribute. However, in the future we
would like to give the opportunity to an architect to tune these values by consider-
ing or discarding alternative tactics. This will help to alleviate impacts of the pat-
tern whose choice was driven by a core of quality attributes on the other attributes.
REFERENCES
[1] Jansen J., van der Ven J., Avgeriou P., Hammer D.K., “Tool Support for using Architectural
Decisions”, In proceedings of the 6th Working IEEE/IFIP Conference on Software Architec-
ture (WICSA'07), Mumbai, India, 2007.
[2] Microsoft Application Architecture Guide: Patterns & Practices, 2nd Edition,
http://msdn.microsoft.com/en-us/library/ff650706.aspx.
[3] Garlan, D., Shaw, M., “An Introduction to Software Architecture”, Technical Report,
CMU, Pittsburgh, PA, USA, 1994.
[4] Avgeriou, P. and Zdun, U., “Architectural Patterns Revisited– a Pattern Language”, In Pro-
ceedings of 10th European Conference on Pattern Languages of Programs (EuroPLoP 2005),
pp. 1- 39, 2005.
[5] Garcia, A. F., and Rubira, C. M., “An Archietctural-based Reflective Approach to Incorporat-
ing Exception Handling into Dependable Software”, Advances in exception handling tech-
niques, vol. 2022, Springer-Verlag, pp. 189-206, 2001.
[6] Garcia, A. F., Rubira, C. M. F., Romanovsky, A. B., and Xu, J. A., “A Comparative Study of
Exception Handling Mechanisms for Building Dependable Object-Oriented Software”, Jour-
nal of Systems and Software vol. 59, Issue 2, pp. 197-222, 2001.
[7] Issarny, V., Benatre, J.-P., “Architecture-based Exception Handling”, In Proceedings of the
34th Annual Hawaii international Conference on System Sciences (Hicss-34), 2001.

[8] Bachmann, F., Bass, L., Nord, R., “Modifiability Tactics”, Technical Report, SEI, CMU/SEI
2007-TR-002, September 2007.
[9] Harrison, N., Avgeriou, P., Zdun, Uwe, “On the Impact of Fault Toler-
ance Tactics on Architecture Patterns”, In proceedings of 2nd International Workshop on
Software Engineering for Resilient Systems (SERENE 2010), London, UK, 2010.
[10] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., “Pattern-Oriented Soft-
ware Architecture: A System of Patterns”, John Wiley & Sons, 1996.
[11] Gamma, E., Helm, R., Johnson, R., Vlissides, J.M., “Design Patterns: Elements of Reusable
Object-Oriented Software systems”, Addison-Wesley, 1994.
[12] International Standard ISO/IEC 9126-1. (2001). Software engineering – Product quality –
Part 1: Quality model. ISO/IEC 9126-1:2001, 200.
[13] Bass, L., Clements, P., Kazman, R., “Software architecture in practice”, Addison-Wesley,
2003.
[14] Chung, L., Nixon, B.A., Yu, E., and Mylopoulos, J., “Nonfunctional Requirements in Soft-
ware Engineering”, Kluwer Academic Publishing, 2000.
[15] Harrison, N. B., Avgeriou, P., “How do architecture patterns and tactics interact? A model
and annotation”, Journal of Systems and Software, vol. 83, Issue 10, pp. 1735-1758, 2010.
[16] Gröne, B., and Keller F., “Conceptual architecture patterns”, FMC-based representation,
Potsdam: Univ.-Verl., 2004.
[17] Bode, S., Riebisch, M., “Impact Evaluation for Quality-Oriented Architectural Decisions
Regarding Evolvability”, The 4th European conference on Software architecture, pp.182-197,
2010.
[18] Wood, W. G., “A Practical Example of Applying Attribute-Driven Design (ADD)”, Version
2.0. February 2007, Technical report CMU/SEI-2007-TR-005 ESC-TR-2007-005, 2007.
[19] Völter, M., Kircher M., Zdun U., “Remoting Patterns: Foundations of Enterprise, Internet
and Realtime Distributed Object Middleware”, Wiley, 2005.
[20] Shaw M., Garlan D., “Software Architecture: perspectives on an emerging discipline”, Pren-
tice Hall, 1996.
[21] Yoder J., Barcalow J., “Architectural Patterns for Enabling Application Security”, Proceed-
ings of Pattern Language of Programs conference, Allerton Park, Illinois, U.S.A, 1997.
[22] Boehm, B. W., Brown, J. R., & Lipow, M., Quantitative Evaluation of Software Quality,
The 2nd International Conference on Software Engineering, IEEE Computer Society, (pp.
592- 605), 1967.
[23] Kassab, M., “Non-Functional Requirements: Modeling and Assessment”, VDM Verlag Dr.
Mueller, ISBN 978-3-639-20617-3, 2009.