A Survey of Synergistic Relationships For Designing Architecture: Scenarios, Quality Attributes, Patterns, Decisions, Reasoning Framework

Vol 01, Issue 02, December 2012 International J ournal of Web Technology
http://iirpublications.com ISSN: 2278-2389

Integrated Intelligent Research (IIR) 74

A SURVEY OF SYNERGI STI C RELATI ONSHI PS FOR DESI GNI NG
ARCHI TECTURE: SCENARI OS, QUALI TY ATTRI BUTES,
PATTERNS, DECI SI ONS, REASONI NG FRAMEWORK
1
K. K. Baseer,
2
A. Rama Mohan Reddy,
3
C. Shoba Bindu
1
J NTUA/J NIAS, Hyderabad, India. Kkbhaseer.ap@gmail.com
2
SVU College of Engineering, Tirupati, India. rammohansvu@gmail.com
3
J NTUCEA, Anantapur, India. shobabindu@gmail.com

Abstract- Software Architectures are generally designed with particular functional and nonfunctional
requirements. Organizations often need to choose Software Architecture for future development from
several contending candidate architectures. Several methods have been proposed to design, analyze,
selecting architectures with respect to hoped quality attributes to identify their restrictions. Most of these
methods encourage the use of architectural patterns to develop architectures with known characteristics
and apply scenarios to evaluate those architectures for desired quality attributes (e.g., reliability,
modifiability). In case of Architecting a complex design activity, it involves making decisions about a
number of inter-dependent design choices that relate to a range of design concerns. Each decision
requires selecting among a number of alternatives; each of which impacts differently on various quality
attributes (e.g., real-time, reliability, and performance). This paper discusses a selection framework
based on multiattribute decision making using Hypothetical Equivalents, Architectural Information in a
format that can support design decisions, ArchDesigner as a taxonomic approach along with GB case
study and a Reasoning Framework which is encapsulation mechanism, can be used by nonexperts to
examine a specific quality (e.g., performance, modifiability, availability) of a system.

I . I NTRODUCTION
Software architecture (SA) of a product family
constrains the achievement of various quality
attributes (such as reusability, performance,
security, maintainability and usability) [1]. A
number of methods, such as Architecture
Tradeoff Analysis Method (ATAM) [2], Quality
Attribute-oriented Software Architecture design
method (QASAR) [3] and Quality-driven
Architecture Design and Analysis (QADA) [4],
have been developed to pay significant attention
to quality related issues at the SA level. These
approaches heavily depend on architectural
styles and patterns to design candidate
architectures and associated reasoning
frameworks to evaluate SAs for desired quality
attributes. Patterns are a vital means of
designing SAs of large complex systems. One of
the major objectives of using patterns is to
develop a software system with predictable non-
functional properties [1]. Scenarios are used to
characterize quality goals and patterns are used
to achieve those goals. Moreover, scenarios are
used to reason about the design decisions during

SA design stage and to evaluate that SA with
respect to target quality requirements. Recently,
there have been attempts to codify the links that
exist among scenarios, quality attributes, and
patterns.

Existing software architecture selection
methods [5, 6, 7, and 8] have been analyzed to
identify their limitations. Architecture of a
system addresses both functional and non
functional requirements of a system. Functional
requirements represent what the systemdoes and
non functional requirements address the quality
aspects [9] of the system. Non functional
requirements such as modifiability,
performance, reusability, comprehensibility and
security are crucial to a software system. These
quality requirements should be addressed as
early as possible in the software lifecycle and
properly built into software architecture before
one proceeds for a detailed design. Stakeholders
are the ones who are related to the proposed
system in one way or the other viz., end users,

developers, maintenance engineers, architects,
business people etc. Their expectations and
requirements are converted into functional and
non functional requirements of the proposed
system.
A quality attribute is a non-functional
requirement of a system, e.g., reliability,
modifiability and so forth. One of the major
objectives of using patterns is to develop a
software system with predictable non-functional
properties [1]. Each pattern helps achieve one or
more quality attribute and may hinder others.
Quality attributes are mostly improved, and have
fewer changes in forms of new requirements. It
is complex because the architect must make
complex design trade-offs to meet cotending
architectural requirements [10]. Software
architecture has significant impact on satisfying
quality attribute requirements, but it is not easy
to determine whether architecture will satisfy the
quality requirements. Complex theories and
tools are often required to arrive at reliable
answers.

However, the extracted information can only
be useful if it is documented in a manner that
makes it readily useable during the architecture
design and assessment activities by making the
relationships of scenarios, quality attributes, and
patterns explicit. The one of the goal of
Muhammad Ali Babar [32] research is to
improve the process of SA design and evaluation
by providing architectural information in a
format that can support design decisions with an
informed knowledge of the consequences of
those decisions.
This paper discusses a selection framework
based on multiattribute decision making using
Hypothetical Equivalents [37]. The framework
provides the rationale for an architecture
selection process by comparing the fitness of
contending candidate architectures for the
envisioned system based on the quality
requirements of different Stakeholders.
A quality driven design approach,
ArchDesigner that promotes a disciplined
engineering and reasoning framework during SA
design. The novelty of this approach lies in the
use of optimization techniques, particularly
Integer Programming [31], for optimizing the
SA design comprised of multiple inter-
dependent design decisions.
A reasoning framework (RF) is a vehicle for
encapsulating the quality attribute knowledge
and tools needed to analyze the behavior of a
systemwith respect to some quality attribute.
Using reasoning frameworks in two different
technologies. One is ArchE, an architectural
design assistant that adjusts designs using
architectural tactics to satisfy quality
requirements [11]. The other is prediction-
enabled component technology (PECT). In a
PECT, RFs predict behaviors of component-
based systems based on properties of the
components [12].

On the whole in this paper, discussion on a
selection framework based on multiattribute
decision making using Hypothetical Equivalents,
design stage of SAs with respect to design
decisions and quality goals based on
combinational of scenarios, patterns, reasoning
framework, architecture styles, and evaluating
the SAs with respect to targeted quality
requirements to achieve those goals
irrespectively. Further paper is discussing about
Bearing Quality conditions on SA Design,
Improve the Process of SA Design and
Evaluation, A Quality Driven Design Approach
along with GB case study, Elements of a
Reasoning Framework and at last Conclusion
with Future work.

I I . MULTI ATTRIBUTE DECI SION
MAKI NG PROCESS
ATAM [7], SAAM [6], CBAM [8] fail to
quantitatively analyze software architecture
structures based on quality attributes. In the
proposed method creates a support framework
using Analytical Hierarchy Process [13] for
comparison of different software architectural
structures for a specific software quality
attribute. Moreover, given a prioritization of
quality attributes for the software system, or a
part thereof, the most suitable software
architecture structure can be indicated using the
created framework. On analysis of the existing
method the following disadvantages were
identified:
1. If there are n architecture structures and
m quality attributes then the number of

comparisons is m*n (n-l )/2 which is
extensively high.
2. Different Stakeholders have different
priority levels and are concerned with only
particular quality attributes.
3. Changes of smaller degree when made to
any one of the structures under
consideration, forces the repetition of
decision making procedure.
4. If two structure values are same then there
is no provision for making a choice.
5. The quality attributes are treated
independently. But in reality, the quality
attributes are interdependent.

To overcome the above limitations, the weighted
sumapproach of multi attribute decision making
process [14] is proposed. The proposed
framework [38] uses a more rigorous method,
called hypothetical equivalents, to find a
theoretically correct set of weights (priorities)
based on the decision maker's stated references.
This results in enhancing the accuracy and
simplicity of the proposed decision support
system.
The series of steps involved in the selection
process is as follows:
A. Stakeholders Preferences.
B. Identification of the stake holder's quality
requirements.
C. Fixation of acceptable range for each
quality attribute.
D. Normalization.
E. Identification of the Strength of
Preference.
F. Determination of the Weight of
Preference.
G. Conversion of the values of quality
attribute for the given candidate
architectures.
H. Calculation of Cumulative scores.
I. Selection of the Architecture.

A. Stakeholders Preferences
Software Development involves lot of
Stakeholders. Stakeholders' preferences need to
be considered for selecting architecture.
However, classical marketing research decision
making process follows a concept of
segmentation to deal with individual
Stakeholders preferences. Segmentation refers to
grouping people based on similar characteristics.
As an example, three groups viz., Manager,
Technical Person and User are considered.

B. Identification ofthe Stakeholder's Quality
Requirement
Table 1: Quality Requirements of each group
Group Quality requirements
Manager Cost
Team
size
Developme
nt time
Technica
l Person
Maintainabilit
y
Reliabilit
y
Response
time
user Function usability Learnability
C. Fixation of acceptable range for each quality
attributes
After identifying the groups and their quality
requirements, the acceptable satisfactory range
for each quality requirement need to be fixed. As
an example, the user group's acceptable
satisfactory range for the quality attribute
Learnability would be 2 8 hours.
D. Normalization
Normalization is a common way to eliminate
dimensions from the problem. During
normalization, the lowest range value is usually
taken as 0 and the highest range value as 100. As
an example, we consider the range for
learnability (2 hours to 8 hours), where 2 hours
implies 0 and 8 hours implies 100.
E. Identification of the Strength of Preference
Using a linear preference scale may not truly
reflect a decision maker's preferences. For
example, if 75% of user group prefers the
decrease in the learnability time from 80 to 50
minutes and 25% of the group from40 to 30
minutes, the linear preference function cannot
capture this preference. Hence a non-linear
strength of preference representation reflecting
true preferences is adopted and shown in Fig. 1.
To register this strength of preference, a
questionnaire is prepared which is given to all
Stakeholders and the results are obtained. Based
on the values in the questionnaire, strength of
preference graph is drawn.


X axis: Minutes, Y axis: Numerical units (0-100)
Fig. 1 Strength of Preference Graph

Similarly strength of preference graphs are
generated for all the quality attributes of every
group as shown in Table 1.
F. Determination of the Weight of Preference
The hypothetical equivalence approach [37]
determines the attribute weights using a set of
preferences rather than selecting weights
arbitrarily based on intuition or experience. As
an example: Consider the technical person group
and their three quality attributes of interest viz.,
Response time, Reusability and Maintainability.
However, the technical person group can also
consider other pertinent metrics for design
quality viz., cohesion and coupling. Four
hypothetical architecture (A, B, C, D) values are
prepared and presented to the group as in Table
2.
Table 2: Hypothetical Architectures
Quality and Weights
Archite
cture
Resp
onse
time
(W
1
)
Reusa
bility
(W
2
)
Maintain
ability
(W
3
)
Total
Score
A 100 0 0 100W
1

B 0 0 40 40W
3

C 10 10 40 10W
1
+10
W
2
+50W
3

D 0 0 50 50W
3

The group feels that A is equivalent to B and C
is equivalent to D. The indifference points
results in the following equations.

100w
1
=40w
3
(1)
10w
1
+10w
2
+50w
3
=50w
3
(2)
The normalization equation is
w
1
+w
2
+w
3
=1 (3)
For solving the three equations, the weights are
fixed as:
w
1
=0.2,w
2
=0.3,w
3
=0.5
Hence the weight of preference for Response
time is 0.2, the weight of preference for
Reusability is 0.3 and the weight of preference-
for Maintainability is 0.5. Similarly weight of
preference for the quality attributes of the roles
viz., Manager and User are computed.

G. Conversion of the values of quality attribute
for the given candidate architectures
For all candidate architectures, the quality
attribute values of each group are normalized
using the corresponding strength of preference
graphs. As an example, quality attributes of the
group Technical Person are normalized and
tabulated in Table 3. The total score of each of
the architectures is computed by aggregation of
the row values. Before aggregation, the row
values have to be multiplied by their
corresponding weights. Similarly Value Tables
for the other groups viz., User and Manager are
constructed.
Table 3: Value Table
Quality and Weights
Architect
ure
Respo
nse
time
(0.2)
Reusabi
lity (0.3)
Maintaina
bility (0.5)
Tot
al
Sco
re
A 100 0 0 20
B 75 35 60 55.5
C 100 100 0 50

H. Calculation of Cumulative scores
The value table of each of the groups is
examined and the total score of each of the
architectures is aggregated to obtain the
cumulative score. Let there be mgroups and n
architectures:

Total scores of architectures j = (w

k
=1
I
)

Where W=Weight of the particular attribute i
V =Value of the attribute
k =Number of attributes in the table

Cumulative score for an architecture j =
100
0
8 6 3

(IS
],x
)
m
x=1

Where, TS is the Total Score and m is the
number of roles.

I. Selection of the Architecture
The architecture with the highest cumulative
score is selected. This architecture provides
maximum satisfaction to the Stakeholders and
also specifies to what extent the Stakeholders'
requirements have been satisfied. The total
satisfaction of the candidate architectures are
calculated based on the average of the total
scores of that particular architecture. For
example if the cumulative scores of three
example architectures A, B and C is 110.5,
248.5 and 234.5 respectively and the number of
groups is 4 then the Total satisfaction of an
architecture = cumulative score / number of
roles. The obtained result is tabulated in Table 4.
Table 4: Total Satisfaction Table
Architecture Total Satisfaction
A 36.8
B 82.8
C 78.1

From the above Table, it is evident that
Architecture B gives the maximumsatisfaction
to the Stakeholders.

I I I . I MPROVE THE PROCESS OF SA
DESI GN AND EVALUATION
To improve the process of SA design and
evaluation by providing architectural
information in a format that can support design
decisions with an informed knowledge of the
consequences of those decisions. More
specifically, Muhammad Ali Babar intend to
minimize the time, resources and skill level
required to effectively and efficiently design and
analyze a SA for product family. Author believe
that developing a systematic approach to
identify, efficiently extracting, and explicitly
documenting the relationships of scenarios,
quality attributes, and patterns is one of the most
important work to be done.

Scenarios have been found quite effective
and useful for exactly specifying quality
attributes. Several approaches use scenarios to
encourage disciplined thinking during SA design
and evaluation activities [4, 30]. A pattern is
known solution to a recurring problem in a
particular circumstance. One of the main goals
of using patterns is to design a SA with known
quality attributes. Each pattern either supports or
inhibits one or more quality attributes. Each
patterns description has large amount of
architecturally significant information, e.g.
scenarios, quality attributed supported or
hindered, forces, tactics and so on.
Author [32] proposes a framework of two
templates to document architectural information
(i.e. general scenarios, quality attributes, tactics,
usage examples and so on) to support SA design
and evaluation processes and also provides a
simple process of identifying and extracting the
architectural information from patterns. Table 5
presents the first template, which captures the
information extracted frompatterns.
Author [32] claims that these templates
make the relationships among scenarios, quality
attributes, and patterns explicit. Moreover, the
proposed templates also capture one of the most
important parts of a pattern description, forces.
The forces of a pattern describe the factors
whose clash causes the problem that the pattern
attempts to solve by resolving the clashes among
those factors. Recently, software engineering
community has started paying appropriate
attention to the forces of a pattern in an attempt
to fully understand the problem and solution
described in a pattern.


Table 5: A table to document architecturally significant information found in a pattern
Pattern Name: Name of the software pattern Pattern Type: Architecture, Design or Style
Brief Description A brief description of the Pattern
Context The situation for which the pattern id recommended
Problem Description What types of problems the pattern is supposed to address?
Suggested Solution What is the solution suggested by the pattern to address the problem?
Forces Factors affecting the problem& solution. J ustification for using pattern
Available Tactics What tactics are used by the pattern to implement the solution?
Affected Attributes Positively Negatively
Attribute Supported Attribute Hindered
Supported
General
Scenarios
S1
S2
S..n
Usage Examples Some known examples of the usage of the pattern to solve the problems

The below Table 6 presents the second template, which is aimed at documenting the architectural
information found in patterns for SA evaluation, which needs concrete scenarios.

Table 6: A table to document architectural information for SA evaluation process
Project Name: Which Projects needs this Scenario?
Project Domain: Domain of the Project
Date: When was Proposed
Scenarios No: Serial number assigned to the Scenario
Business Goal Which Business Goals does the scenario achieve?
Stakeholder Which class of the stakeholder did suggest the scenario?
Attribute Which quality attribute are required by this scenario?
Description A brief description of the scenario.

Concrete
Scenario
Stimulus A Condition that needs to be Considered when it arrives at a system.
Context A Systems condition when a stimulus occur, eg.overloaded, etc.,
Response A measurable action that neds to be undertaken after the arrival of the stimulus.
Complexity How complexity is this scenario to realize?
Priority How much important is this scenario?
Pattern/Style Name of the architectural pattern or style that can support this scenarios.
Design Tactics What are the design tactics used by the pattern/style to supported the scenarios
Design Rational What are the reasons to use the pattern/tactics? How does the pattern provide the desired
quality attribute?

In supporting to SA design and evaluation process
by considering two templates, one is to capture
the extracted information from patterns and
another is to documenting the architectural
information along with forces. With these
templates the relationships among scenarios,
quality attributes and patterns are explicitly
provided.

I V. A QUALITY DRI VEN DESI GN
APPROACH
The software engineering community has
developed different methods to support systematic
reasoning about various quality attributes (e.g.,
real-time [16], reliability [17], and performance
[18]) during software architecture design.
However, these methods study a specific quality
attribute in isolation. In reality, quality attributes
interact with each other. For example, there is
generally a conflict between configurability and
performance [19]; performance also impacts
modifiability, and each quality attribute impacts
cost [20].

Some researchers have developed methods to
make quality attributes a central consideration
during application design. Bosch [21] proposes a
method that explicitly considers quality attributes
during the design process. Hofmeister et al.[22]
describe a framework known as global analysis to
identify, accommodate, and describe
architecturally significant factors including
quality attributes early into the design phase.
However, these methods do not sufficiently
support the reasoning about the quality
consequences of each design decision.

The work of Chung et al. [15] provides a
framework that considers each design decision
based on its effects on the quality attribute space.
However, it does not provide support to explicitly
perform trade-off analysis between competing
design decisions. Bass et al. [20] have proposed
the Attribute Driven Design (ADD) method to
help the architect base the design process on the
desired quality attributes. ADD is basically built
upon Attribute Based Architecture Styles (ABAS)
[23], and architectural views [24, 25]. It provides
a framework to make design decisions with
known affects on the desired quality attributes.
However, the codified knowledge or experience
of an architect may present more than one design
alternative for each design decision. In this
situation, a quantitative reasoning framework to
support the multi criteria decision analysis can
complement methods like ADD.

Authors [33] goal is to reduce the complexity
and increase the reliability of SA design. One way
of doing it is by systemizing the architectural
design process, as suggested earlier in [34]. The
design approach must also deal with inter-
dependencies among different decisions. Initially,
they identified two types of dependencies
(Alternative-Based and Context-Based
dependencies). Based on these observations, they
argue that the SA design problem can be
formulated as a global optimization problem,
since design decisions are highly dependent on
each other, and the selection of any design
alternative must not violate global constraints.
Therefore, they state the optimization problem as
follows:

"They seek to maximize the value of the SA for all
stakeholders involved by selecting alternatives
yielding highest value scores, during assuring that
dependencies are maintained and global
constraints stated are not violated".

To the best of their knowledge, none of the
existing design approaches explore the potential
of applying optimization techniques for solving
complex software design problems, comprised of
multiple inter-dependent architectural design
decisions.

In this paper a design approach is
ArchDesigner, which comprises three steps as
shown in Figure 2. It starts with the first design
decision and computes value scores for its
potential alternatives solutions. This is repeated
for each design decision. The second step
transforms the computed value scores into a
normalized form, in order to prepare them for the
third step. Finally, the third step formulates the
optimization equations so as to maximize the
values associated with selected alternatives,
subject to stated constraints and inter-
dependencies.
Step 1: Value score computation:

They define the value score of a design alternative
as the degree to which an alternative satisfies the
desired quality attributes. For a particular design
decision, potential design alternatives are
evaluated across a set of quality attributes
associated with that design decision. Figure 3
depicts the process of computing alternative value
scores pertaining to a particular design decision.
The input to this process is twofold:

Design alternatives and their relative
support for associated quality attributes.
Preferences on associated quality
attributes provided by different
stakeholders


Fig. 1 ArchDesigner Process [34].

Fig.2 ArchDesigner Process

Fig. 3 Computation of Value Scores [34].
Value Score Computation
Value Score Normalization
Optimization Formulation
Consider first
design
decision
Compute
alternative
value scores
usingMADM
Consider
next design
decision
Normalized
Computed
Value Scores
Formulate
the
Optimization
Solve the
Optimization
problem
Other
Design
Decision

Step 2: Normalization of value scores:
Before moving on to the third step, they need to
normalize the alternatives value scores obtained
in the previous step. The reason for this is that
the alternatives value scores from different
decisions will be summed in the next step.
Hence, they have to scale them relatively. To do
this, they weight the different decisions N
j

relatively in a manner that reflects their relative
significance to the application. Naturally, some
design decisions are more important than others,
and thus should receive higher weights. Having
done this, they then multiply the obtained value
scores by the weight of their corresponding
decision:
I
]
= N
]
I
]

Step 3: Optimization formulation:
In this step, they seek to maximize the
accumulative value score, which represents the
objective function. This can best be formulated
using Integer Programming (IP):
Hoximizc: X
]
I
]
n
]
=1
m
]=1

Subject to:
]
[1,,m]:X
]
=1
n
]
=1

Cost(X
1
1
,X
2
2
,.,X
m
m
) <=Constroint
Cost

Iimc(X
1
1
,X
2
2
,.,X
m
m
) Constroint
1mc

X
]
+X
ub
<=1,] b

A. GB CASE STUDY
The Glass Box (GB) project [36] is a part of
a multi-year, research program' to generate new
tools and technologies for information analysts.
The GB itself is a production software system,
which is deployed in the analyst's working
environment. Its basic role is to capture detailed
information on a user's workstation activities
during information gathering and analysis tasks.
This information is recorded over long time
periods, and made available to a range of
research projects based at research labs across
North America. There are approximately 15
separate research projects funded by the overall
program.
The relationship between the GB application
and the various stakeholders involved as shown
in Figure 4. Information Analysts are the
primary users of the GB. It is integrated with
their work environment, and provides both
transparent and explicit tools to record actions.
The Research Teams see the GB as a software
tool and data repository. They need to access the
data in the repository, and programmatically
integrate their tools with the GB environment.
The Funding Agency is responsible for
approving development plans and allocating
associated budgets, and for the overall success
of the program.

The initial GB version was a 2-tier client-
server system, utilizing a database, file store,
and a set of tools to capture user activities when
they accessed Web sites, documents, and
commenced and completed assignments. It ran
as a standalone system on each user
workstations.

Fig. 4 Glass Box Stakeholders

They applied ArchDesigner as a post-
mortem analysis of the major architectural
design decisions that were made during the GB
design. They then compared the results obtained
by ArchDesigner with the design decisions that
were actually made. For this purpose, they held
several interviews with the Lead Architect (LA)
of the project. Initially, there were at least 9
architectural design decisions that had
undergone extensive discussions and evaluation
during the design stage. These decisions are
shown in Figure 4. They have selected 5
decisions out of 9 to include in our study. These
are represented with yellow boxes in Figure 4.


Fig. 5 GB Design decisions and their Interdependencies

Directed arrows in Figure 5 depict inter-
dependencies among the different decisions. A
list of the selected design decisions is shown in
Table 7, along with the corresponding
alternatives that were considered, relevant
quality attributes, and the stakeholders
participating in the decision-making process.
Highlighted alternatives represent the real
selections made.
After analyzing the selected design decisions
and their alternatives and inter-dependencies,
171 potential combinations of alternatives
existed for the architect to consider. In addition,
every design decision involved more than one
group of stakeholders, each of which favored
different solutions. Also, the project was
constrained by one-year duration. All these
issues made the design activity quite complex.

Table 7. List of selected decisions, along with their
alternatives, Quality attributes, and stakeholders
Design
Decision
Alternative
s
Quality
Attributes
Stakeholders
Architectur
e (ARCH)
3-tier
using
J 2EE
(THTJ )
3-tier
using
.Net
(THTD
)
2-tier
(TWOT
)
COAB
S
(COAB
)
Modifiabili
ty
Scalability
Performanc
e
Cost
Developme
nt effort
Portability
Ease of
installation
Developmen
t Team
Research
Teams
Funding
Agency
Event
Notification
(EVNT)
Publis
h-
Subsc
ribe
Reliability
Performan
ce
Complexit
Develop
ment
Team
Research
using
J MS
(J MS)
Publis
h-
Subsc
ribe
using
MSM
Q
(MSM
Q)
Datab
ase
trigger
s
(TRG
R)
COA
BS
(COA
B)
y of
implement
ation
Teams

Authenticat
ion (AUTH)
Databa
se-
based
Securit
y (DB)
J 2EE-
based
Securit
y
(J 2EE)
.NET
based
Securit
y
(.NET)
COAB
S
(COAB
)
Complexit
y of
Implement
ation
Ease of
Deployme
nt and
setup
Develop
ment
Team
Research
Teams
Remote
Access
(RMAC)
Browse
r-based
(HTTP)
Web
Service
s
(WEBS
)
Secure
Networ
k
(VPN)
Performa
nce
Security
Modifiabi
lity
Complexi
ty of
deployme
nt
Complexi
ty of
implemen
tation

Develop
ment
Team
Research
Teams
Funding
agency
Supporting
Non-
windows
platforms
for API
(HERT)
J ava
Langu
age
(J AVA
)
Browse
r
(BRO
W)
C
Langua
ge (C)
Usability
Modifiab
ility
Cost
Develop
ment
Effort
Develop
ment
Team
Research
Teams


Design decisions plays vital role in SA
design. In this paper a design approach is
ArchDesigner, which comprises of three steps
for solving optimization problem globally. As an
example GB case study was included, it
provides the way of handling design decisions
for complex systems. With these discussions the
relationship between design decisions and
quality attributes are clearly specified.

V. ELEMENTS OF A REASONI NG
FRAMEWORK
The architecture description provided as input
must satisfy the RF analytic constraints. The
desired quality attribute measures are restricted
to problems from the problem description.
Interpretation translates the architecture
description into a model representation. Then,
the evaluation procedure reads the model
representation (and sometimes the desired
quality attribute measures) to predict the quality
attribute measures that are the output of the RF.
The evaluation procedure uses algorithms based
on the analytic theory. The Figure 6 shows how
a generic RF works.

Fig. 6 Elements of a reasoning framework

From the users perspective, the RF is a
black box that takes an architecture description
and desired quality attribute measures as input
and produces quality attribute measures as
output. Users dont need to be experts in the
analytic theory or understand how the internal
elements work. Sections 3.1 to 3.6 describe the
six elements of a RF, using as example a real-
time performance RF.

A. ProblemDescription
The problem description identifies the quality
attribute problems for which the RF is used,
more specifically the quality measures that can
be calculated or the quality requirements that
can be evaluated. For example, while
performance is a broad topic with many possible
measures, a specific performance RF might only
calculate task latency or evaluate whether tasks
will meet their deadlines.

B. Analytic Theory
Each RF is based on an analytic theorya body
of knowledge used to reason about some quality
attribute. Analytic theories draw from
established disciplines, such as queuing theory,
RMA, Markov analysis and automata theory. An
analytic theory defines assumptions, elements
and their properties, rules governing the
relations among elements, and logic for drawing
conclusions from a model in the theory. For
example, RMA theory is used to reason about
worst-case latency. It assumes fixed priority
scheduling is used, and arrival rates and
execution times have little or no variability.
RMA models are expressed in terms of sets of
tasks, their topology and priorities, execution
times, and the frequency with which external
messages arrive. RMA theory includes formulae
for computing worst-case latency and ensuring
deadline satisfaction.

C. Analytic Constraints
Each RF specifies analytic constraints that must
be met by the input architecture description to be
analyzable. An example of an analytic constraint
for a performance RF is all event arrivals must
be periodic. By restricting the design space to
which the RF is applied, assumptions can be
made in the analytic theory and evaluation
procedure. These assumptions are necessary to
improve confidence in the results, permit
analytic tractability, or even ensure solvability.
The RF may also require specific properties of
the elements to be known. For example, a
performance RF may require the execution time
of each component.


D. Model Representation
A model is a simplified version of reality.
Models are represented using some parseable
encoding for elements, relations and their
properties. For example, the model
representation of a system in a performance RF
consists of tasks and subtasks that have
execution time and priority as properties. A RF
may provide a visualization of the model, such
as that shown in the lower portion of Figure 7.

E. Interpretation
Interpretation is the process that takes an
architecture description as input and generates a
model representation that contains all
information that the evaluation procedure needs
to calculate quality attribute measures. In the
performance RF example, the architectural
description must identify the schedulable
entities, the execution times that contribute to
each of them, and the period of each. The upper
portion of Figure 6 is an example of an
architecture description used as the input to a
performance RF called
SS
. The lower portion
shows the performance model.

F. Evaluation Procedure
An evaluation procedure is the computable
algorithm by which a RF calculates quality
attribute measures from a model representation.
The algorithm can be directly implemented, or
simulation tools and spreadsheets can be used.

Fig. 7 Interpretation for
SS
[35].

In the performance example, the evaluation
procedure to calculate worst-case latency for
process I is an algorithm for iteratively solving
the following formula until it converges (values
of independent variables come fromthe model
representation).
I
n+1
=_
I
n
I
]
_ C
]
+C
+B
-1
=1

With these discussions, encapsulating the
quality attribute knowledge with the help of
reasoning framework, which comprises of six
step process that produces quality attribute
measures as output by considering real-time
performance RF as an example.

VI . CONCLUSION
Software Architectures are generally designed
with particular functional and nonfunctional
requirements. Several methods have been
proposed to design of architectures with respect

to desired quality attributes. Existing software
architecture selection methods [5, 6, 7, and 8]
have been analyzed to identify their limitations.
The framework provides the rationale for an
architecture selection process by comparing the
fitness of contending candidate architectures for
the envisioned system based on the quality
requirements of different Stakeholders. In
supporting to SA design and evaluation process
by considering two templates, one is to capture
the extracted information from patterns and
another is to documenting the architectural
information along with forces. With these
templates the relationships among scenarios,
quality attributes and patterns are explicitly
provided. Design decisions plays vital role in SA
design. In this paper a design approach is
ArchDesigner, which comprises of three steps
for solving optimization problem globally. As an
example GB case study was included, it
provides the way of handling design decisions
for complex systems. With these discussions the
relationship between design decisions and
quality attributes are clearly specified. Using
optimization techniques, it attempts to determine
the optimal combination of design alternatives
that best satisfy stakeholders quality goals and
project constraints. This paper discusses a
technique developed at the Software
Engineering Institute (SEI) for encapsulating
quality attribute knowledge for use in the design
software architectures. A reasoning framework,
our encapsulation mechanism, can be used by
nonexperts to analyze a specific quality (e.g.,
performance, modifiability, availability) of a
system, which comprises of six step process that
produces quality attribute measures as output by
considering real-time performance RF as an
example.

In [32] plan to use experimentation to assess
authors claim of improving SA design and
evaluation process by distilling SA sensitive
information from patterns and usefulness of the
proposed framework to document the
information. In [33] also plan to build a tool
based on the ArchDesigner to support the SA
design process. In [35] have defined and at least
partially implemented RFs for RMA [26],
impact analysis [27], variability analysis [28]
and model checking [29] and also they are
working in RFs for queuing theory, security and
usability. These RFs are being implemented as
plug-ins to the tool infrastructure developed for
ArchE and for PECTs.

REFERENCES
[1] Bass, L., et al., "Software Architecture in
Practice", 2 ed.2003: Addison-Wesley.
[2] Clements, P., et al., "Evaluating Software
Architectures: Methods and Case Studies".
2002: Addison-Wesley.
[3] Bosch, J ., "Design & Use of Software
Architectures: Adopting and evolving a
product-line approach". 2000: Addison-
Wesley.
[4] Matinlassi, M., et al., "Quality-driven
architecture design and quality analysis
method: A revolutionary initiation approach
to a product line architecture," Tech. Report
VTT Technical Research Centre of Finland,
Espoo, 2002.
[5] M. Svahnberg et al, "A Method for
Understanding Quality Attributes in
Software Architecture Structures", ACM
transactions (2002).
[6] Liliana Dobrica et al, "A Survey on Software
Architecture Analysis Methods", IEEE
transaction on Software Engineering volume
28 (J uly 2002).
[7] Kazman et al., "Architecture Trade-off
Analysis Method", Technical report,
Carnegie Melon University, Software
Engineering Institute (1998).
[8] Kazman et al, "Quantifying the Costs and
Benefits of Architectural Decisions", IEEE
2001.
[9] Farcisca losavio et al, "Quality
Characteristics of Software Architecture",
J ournal of object Technology Volume 2
(2003).
[10] Chung, L., et al. Non-Functional
Requirements in Software Engineering.
Kluwer Academic Publishers, Boston, Ma.
1999.
[11] Bachmann, F., et al., Preliminary Design of
ArchE: A Software Architecture Design
Assistant, SEI-2003-TR-021, SEI, 2003.
[12] Wallnau, K. Volume III: A Technology for
Predictable Assembly from Certifiable
Components, SEI-2003-TR-009, SEI, 2003.

[13] Eelko K.R.E. Huizingh and. Hans C.J .
Vrolijk, "Decision Support for Information
Systems Management: Applying Analytic
Hierarchy Process", Research school
systems Organization and management
(SOM) research report number 95B26,
University of Groningen (1995).
[14] Chen,Wand Wassenaar H.J., "An approach
to decision-Based design",
ASME design Technical conference
Pittsburgh, Pennsylvania (2001).
[15] Chung, L., et al. Non-Functional
Requirements in Software Engineering.
Kluwer Academic Publishers, Boston, Ma.
1999.
[16] Klein, M.H., et al. A Practitioner's
Handbook for Real-Time Analysis: Guide to
Rate Monotonic Analysis for Real-Time
Systems. Kluwer Academic, 1993.
[17] Lyu, M.R. Handbook of Software Reliability
Engineering. McGraw-Hill and IEEE
Computer Society, New York, 1996.
[18] Smith, C.U., and Williams, L.G. Software
Performance Engineering: A Case Study
Including Performance Comparison with
Design Alternatives. IEEE Transactions on
Software Engineering, 19(7), 1993.
[19] Lundberg, L. et al. Quality Attributes in
Software Architecture Design. Proceedings
of the IASTED 3
rd
International Conference
on Software Engineering and Applications,
Oct 1999.
[20] Bass, L., Clements, P., and Kazman, R.
Software Architecture in Practice. 2ed:
Addison-Wesley, 2003.
[21] Bosch, J . Design & Use of Software
Architectures: Adopting and evolving a
product-line approach. Addison-Wesley,
2000.
[22] Hofmeister, C., Nord, R.L., and Soni, D.
Applied Software Architecture. Reading,
MA, Addison-Wesley Longman, 2000.
[23] Klein, M., and Kazman, R. Attribute-Based
Architectural Styles, Tech. Report,
CMU/SEI-99-TR-022, Soft Engineering
Institute, Carnegie Mellon University.
[24] Kruchten, P.B. The 4+1 View Model of
architecture. IEEE Software, 12(6), 1995, p.
42-50.
[25] Soni, D., Nord, RL, and Hofmeister, C.
Software Architecture in Industrial
Applications. Proc. ofthe 1 7
th
International
Conference on Software Engineering,
Washington, USA, 1995.
[26] Hissam, S., et al., Predictable Assembly of
Substation Automation Systems: An
Experiment Report, Second Edition, SEI-
2002-TR-031, SEI, 2002.
[27] Bachmann, F., et al., Experience in Using
an Expert System in Designing for
Modifiability, Proceedings of WICSA,
2004.
[28] Bachmann, F., A Variability Reasoning
Framework, SEI-2005-TR-009, SEI, 2005.
[29] Ivers, J . & Sharygina, N. Overview of
ComFoRT: A Model Checking Reasoning
Framework, SEI-2004- TN-018, SEI, 2004.
[30] Thiel, S., "On the Definition of a
Framework for an Architecting Process
Supporting Product Familiy Development,"
Proc. of the 4th Int'l Workshop on Product
Family Engineering. 2001. Bilbao, Spain.
[31] Anderson, D., Sweeny, D., and T. Williams
an Introduction to Management Science:
Quantitative Approaches to Decision
Making. South-Western Educational
Publishing, 2002.
[32] Muhammad Ali Babar., " Scenarios, Quality
Attributes, and Patterns: Capturing and
Using their Synergistic Relationships for
Product Line Architectures," Proc. of the
11th Asia-Pacific Software Engineering
Conference (APSEC04).
[33] Tariq Al-Naeem, Ian Gorton, Muhammed
Ali Babar, Fethi Rabhi, and Boualem
Benatallah., A Quality-Driven Systematic
Approach for Architecting Distributed
Software Applications.
[34] Al-Naeem, T., et al. Systematic Approaches
for Designing B2B Applications.
International J ournal ofElectronic
Commerce (IJ EC), Nov 2004.
[35] Len Bass, J ames Ivers, Mark Klein, Paulo
Merson, Kurt Wallnau., Encapsulating
Quality Attribute Knowledge. Proc. of the
5th Working IEEE/IFIP Conference on
Software Architecture (WICSA05).
[36] Gorton, L, and Haack, J . Architecting in the
Face of Uncertainty: An Experience Report.
Proc. OfInternational Conference on
Software Engineering, Edinburgh, Scotland,
2004.

[37] Tung-King See et al, "Multi attribute
Decision Making Using Hypothetical
Equivalents", Proceedings of Design
Engineering Technical Conferences and
Computers and Information in Engineering
Conference ASME (2002).
[38] Software Architecture Selection Framework
Based on Quality Attributes-G. Zayaraz and
P. Thambidurai-IEEE Indicon 2005
Conference, Chennai, India, I I - 1 3 Dec.
2005

AUTHORS BIOGRAPHY

K. K. Baseer obtained his
Bachelor of Technology
and Master degrees in
Computer Science and
Engineering fromJ NTUH,
Hyderabad and currently
he is pursing Ph.D. degree
in J NIAS/J NTUA
University, Hyderabad. At present working as an
Assistant Professor in department of Information
Technology, SVEC, Tirupati, INDIA. His areas
of interest include Software Engineering,
Software Architecture, IRS, and other latest
trends in technology. He has more than 4 years
of experience in teaching and in Industry in the
area of Computer Science and Engineering.

Dr. A. Rama Mohan Reddy
received his M. Tech.
(Computer Science) from
NIT, Warangal and
completed his Ph.D. in the
area of software Architecture
from Sri Venkateswara
University, Tirupati. He has
more than 20 years of teaching experience. He
published many papers in the peer-refereed
journals and conferences. His interested areas
are Software Engineering, Software
Architecture, Data Mining and Computer
Organization.

C. Shoba Bindu received
her B.Tech Degree in
Electronics & Comm.
Engineering from
J awaharLal Nehru
Technological University,
Anantapur, India, in 1997,
M.Tech. in Computer
Science & Engineering from J awaharlal Nehru
Technological University, Anantapur, India, in
2002. She received her Ph.D. in Computer
Science and Engineering at J awaharlal Nehru
Technological University, Anantapur, A.P.,
India. Her Research Interested includes Network
Security and Wireless Communication Systems
and Software Engineering.

A Survey of Synergistic Relationships For Designing Architecture: Scenarios, Quality Attributes, Patterns, Decisions, Reasoning Framework

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

A Survey of Synergistic Relationships For Designing Architecture: Scenarios, Quality Attributes, Patterns, Decisions, Reasoning Framework

Загружено:

Авторское право:

Доступные форматы

Vol 01, Issue 02, December 2012 International J ournal of Web Technology

http://iirpublications.com ISSN: 2278-2389

Вам также может понравиться