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

7/29/2019 A Survey of Synergistic Relationships for Designing Architecture: Scenarios, Quality Attributes, Patterns, Decisions,

1/15

Vol 01, Issue 02, December 2012 International Journal of Web Technologyhttp://iirpublications.com ISSN: 2278-2389

Integrated Intelligent Research (IIR) 74

A SURVEY OF SYNERGISTIC RELATIONSHIPS FOR DESIGNINGARCHITECTURE: SCENARIOS, QUALITY ATTRIBUTES,

PATTERNS, DECISIONS, REASONING FRAMEWORK

1K. K. Baseer, 2A. Rama Mohan Reddy, 3C. Shoba Bindu1JNTUA/JNIAS, Hyderabad, India. [email protected]

2SVU College of Engineering, Tirupati, India. [email protected], Anantapur, India. [email protected]

Abstract- Software Architectures are generally designed with particular functional and nonfunctionalrequirements. Organizations often need to choose Software Architecture for future development fromseveral 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 thesemethods encourage the use of architectural patterns to develop architectures with known characteristicsand 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 anumber of inter-dependent design choices that relate to a range of design concerns. Each decisionrequires selecting among a number of alternatives; each of which impacts differently on various qualityattributes (e.g., real-time, reliability, and performance). This paper discusses a selection frameworkbased on multiattribute decision making using Hypothetical Equivalents, Architectural Information in aformat that can support design decisions, ArchDesigner as a taxonomic approach along with GB casestudy and a Reasoning Framework which is encapsulation mechanism, can be used by nonexperts toexamine a specific quality (e.g., performance, modifiability, availability) of a system.

I. INTRODUCTION

Software architecture (SA) of a product familyconstrains the achievement of various qualityattributes (such as reusability, performance,security, maintainability and usability) [1]. Anumber of methods, such as Architecture

Tradeoff Analysis Method (ATAM) [2], QualityAttribute-oriented Software Architecture designmethod (QASAR) [3] and Quality-drivenArchitecture Design and Analysis (QADA) [4],have been developed to pay significant attentionto quality related issues at the SA level. Theseapproaches heavily depend on architecturalstyles and patterns to design candidatearchitectures and associated reasoningframeworks to evaluate SAs for desired qualityattributes. Patterns are a vital means ofdesigning SAs of large complex systems. One ofthe major objectives of using patterns is todevelop a software system with predictable non-functional properties [1]. Scenarios are used tocharacterize quality goals and patterns are usedto achieve those goals. Moreover, scenarios areused to reason about the design decisions during

SA design stage and to evaluate that SA withrespect to target quality requirements. Recently,there have been attempts to codify the links that

exist among scenarios, quality attributes, andpatterns.

Existing software architecture selectionmethods [5, 6, 7, and 8] have been analyzed toidentify their limitations. Architecture of asystem addresses both functional and nonfunctional requirements of a system. Functionalrequirements represent what the system does andnon functional requirements address the qualityaspects [9] of the system. Non functionalrequirements such as modifiability,

performance, reusability, comprehensibility andsecurity are crucial to a software system. Thesequality requirements should be addressed asearly as possible in the software lifecycle andproperly built into software architecture beforeone proceeds for a detailed design. Stakeholdersare the ones who are related to the proposedsystem in one way or the other viz., end users,


2/15



developers, maintenance engineers, architects,business people etc. Their expectations andrequirements are converted into functional andnon functional requirements of the proposedsystem.

A quality attribute is a non-functional

requirement of a system, e.g., reliability,modifiability and so forth. One of the majorobjectives of using patterns is to develop asoftware system with predictable non-functionalproperties [1]. Each pattern helps achieve one ormore quality attribute and may hinder others.Quality attributes are mostly improved, and havefewer changes in forms of new requirements. Itis complex because the architect must makecomplex design trade-offs to meet cotendingarchitectural requirements [10]. Softwarearchitecture has significant impact on satisfying

quality attribute requirements, but it is not easyto determine whether architecture will satisfy thequality requirements. Complex theories andtools are often required to arrive at reliableanswers.

However, the extracted information can onlybe useful if it is documented in a manner thatmakes it readily useable during the architecturedesign and assessment activities by making therelationships of scenarios, quality attributes, andpatterns explicit. The one of the goal of

Muhammad Ali Babar [32] research is toimprove the process of SA design and evaluationby providing architectural information in aformat that can support design decisions with aninformed knowledge of the consequences ofthose decisions.

This paper discusses a selection frameworkbased on multiattribute decision making usingHypothetical Equivalents [37]. The frameworkprovides the rationale for an architectureselection process by comparing the fitness ofcontending candidate architectures for the

envisioned system based on the qualityrequirements of different Stakeholders.

A quality driven design approach,ArchDesigner that promotes a disciplinedengineering and reasoning framework during SAdesign. The novelty of this approach lies in theuse of optimization techniques, particularlyInteger Programming [31], for optimizing the

SA design comprised of multiple inter-dependent design decisions.

A reasoning framework (RF) is a vehicle forencapsulating the quality attribute knowledgeand tools needed to analyze the behavior of asystem with respect to some quality attribute.

Using reasoning frameworks in two differenttechnologies. One is ArchE, an architecturaldesign assistant that adjusts designs usingarchitectural tactics to satisfy qualityrequirements [11]. The other is prediction-enabled component technology (PECT). In aPECT, RFs predict behaviors of component-based systems based on properties of thecomponents [12].

On the whole in this paper, discussion on aselection framework based on multiattribute

decision making using Hypothetical Equivalents,design stage of SAs with respect to designdecisions and quality goals based oncombinational of scenarios, patterns, reasoningframework, architecture styles, and evaluatingthe SAs with respect to targeted qualityrequirements to achieve those goalsirrespectively. Further paper is discussing aboutBearing Quality conditions on SA Design,Improve the Process of SA Design andEvaluation, A Quality Driven Design Approachalong with GB case study, Elements of a

Reasoning Framework and at last Conclusionwith Future work.

II . MULTI ATTRIBUTE DECISIONMAK ING PROCESS

ATAM [7], SAAM [6], CBAM [8] fail toquantitatively analyze software architecturestructures based on quality attributes. In theproposed method creates a support frameworkusing Analytical Hierarchy Process [13] forcomparison of different software architecturalstructures for a specific software quality

attribute. Moreover, given a prioritization ofquality attributes for the software system, or apart thereof, the most suitable softwarearchitecture structure can be indicated using thecreated framework. On analysis of the existingmethod the following disadvantages wereidentified:

1. If there are n architecture structures andm quality attributes then the number of


3/15



comparisons is m*n (n-l )/2 which isextensively high.

2. Different Stakeholders have differentpriority levels and are concerned with onlyparticular quality attributes.

3. Changes of smaller degree when made toany one of the structures underconsideration, forces the repetition ofdecision making procedure.

4. If two structure values are same then thereis no provision for making a choice.

5. The quality attributes are treatedindependently. But in reality, the qualityattributes are interdependent.

To overcome the above limitations, the weightedsum approach of multi attribute decision makingprocess [14] is proposed. The proposed

framework [38] uses a more rigorous method,called hypothetical equivalents, to find atheoretically correct set of weights (priorities)based on the decision maker's stated references.

This results in enhancing the accuracy andsimplicity of the proposed decision supportsystem.

The series of steps involved in the selectionprocess is as follows:

A. Stakeholders Preferences.B. Identification of the stake holder's quality

requirements.

C. Fixation of acceptable range for eachquality 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 candidatearchitectures.

H. Calculation of Cumulative scores.I. Selection of the Architecture.

A. Stakeholders PreferencesSoftware Development involves lot ofStakeholders. Stakeholders' preferences need tobe considered for selecting architecture.However, classical marketing research decisionmaking process follows a concept ofsegmentation to deal with individualStakeholders 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 QualityRequirement

Table 1: Quality Requirements of each groupGroup Quality requirement

Manager CostTeamsize

Developmnt time

Technical Person

Maintainability

Reliability

Responsetime

user Function usability Learnability

C. Fixation of acceptable range for each qualityattributes

After identifying the groups and their qualityrequirements, the acceptable satisfactory rangefor each quality requirement need to be fixed. As

an example, the user group's acceptablesatisfactory range for the quality attributeLearnability would be 2 8 hours.D. NormalizationNormalization is a common way to eliminatedimensions from the problem. Duringnormalization, the lowest range value is usuallytaken as 0 and the highest range value as 100. Asan example, we consider the range forlearnability (2 hours to 8 hours), where 2 hoursimplies 0 and 8 hours implies 100.E. Identification of the Strength of PreferenceUsing a linear preference scale may not trulyreflect a decision maker's preferences. Forexample, if 75% of user group prefers thedecrease in the learnability time from 80 to 50minutes and 25% of the group from 40 to 30minutes, the linear preference function cannotcapture this preference. Hence a non-linearstrength of preference representation reflectingtrue preferences is adopted and shown in Fig. 1.

To register this strength of preference, aquestionnaire is prepared which is given to allStakeholders and the results are obtained. Basedon the values in the questionnaire, strength ofpreference graph is drawn.


4/15



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

Similarly strength of preference graphs aregenerated for all the quality attributes of every

group as shown in Table 1.F. Determination of the Weight of PreferenceThe hypothetical equivalence approach [37]determines the attribute weights using a set ofpreferences rather than selecting weightsarbitrarily based on intuition or experience. Asan example: Consider the technical person groupand their three quality attributes of interest viz.,Response time, Reusability and Maintainability.However, the technical person group can alsoconsider other pertinent metrics for designquality viz., cohesion and coupling. Fourhypothetical architecture (A, B, C, D) values areprepared and presented to the group as in Table2.

Table 2: Hypothetical Architectures

Quality and WeightArchitcture

Responsetime(W1)

Reusability(W2)

Maintainability(W3)

TotalScore

A 10 0 100WB 0 0 4 40W3C 10 10 4 10W1+1

W2+50W3

D 0 0 5 50W3The group feels that A is equivalent to B and Cis equivalent to D. The indifference pointsresults in the following equations.

100 = 40 (1)10 +10 +50 = 50 (2)

The normalization equation is + + = 1 (3)

For solving the three equations, the weights arefixed as: = 0.2, = 0.3, = 0.5Hence the weight of preference for Responsetime is 0.2, the weight of preference forReusability is 0.3 and the weight of preference-

for Maintainability is 0.5. Similarly weight ofpreference for the quality attributes of the rolesviz., Manager and User are computed.

G. Conversion of the values of quality attributefor the given candidate architectures

For all candidate architectures, the qualityattribute values of each group are normalizedusing the corresponding strength of preferencegraphs. As an example, quality attributes of thegroup Technical Person are normalized andtabulated in Table 3. The total score of each of

the architectures is computed by aggregation ofthe row values. Before aggregation, the rowvalues have to be multiplied by theircorresponding weights. Similarly Value Tablesfor the other groups viz., User and Manager areconstructed.

Table 3: Value Table

Quality and WeightArchitecture

Responsetime(0.2)

Reusability (0.3)

Maintainability (0.5)

TotalScore

A 10 0 0 20B 75 3 0 55.C 1 10 0 50

H. Calculation of Cumulative scoresThe value table of each of the groups isexamined and the total score of each of thearchitectures is aggregated to obtain thecumulative score. Let there be m groups and narchitectures:

Total scores of architectures j = (

)

Where W=Weight of the particular attributeV =Value of the attributek =Number of attributes in the table

Cumulative score for an architecture j =

10

0

8 6 3


5/15



(,)

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

I. Selection of the ArchitectureThe architecture with the highest cumulativescore is selected. This architecture providesmaximum satisfaction to the Stakeholders andalso specifies to what extent the Stakeholders'requirements have been satisfied. The totalsatisfaction of the candidate architectures arecalculated based on the average of the totalscores of that particular architecture. Forexample if the cumulative scores of threeexample architectures A, B and C is 110.5,

248.5 and 234.5 respectively and the number ofgroups is 4 then the Total satisfaction of anarchitecture = cumulative score / number ofroles. The obtained result is tabulated in Table 4.

Table 4: Total Satisfaction Table

Architecture Total SatisfactionA 36.B 82.C 78.1

From the above Table, it is evident thatArchitecture B gives the maximum satisfactionto the Stakeholders.

I II . IMPROVE THE PROCESS OF SADESIGN AND EVAL UATION

To improve the process of SA design andevaluation by providing architecturalinformation in a format that can support designdecisions with an informed knowledge of theconsequences of those decisions. Morespecifically, Muhammad Ali Babar intend tominimize the time, resources and skill levelrequired to effectively and efficiently design andanalyze a SA for product family. Author believethat developing a systematic approach toidentify, efficiently extracting, and explicitlydocumenting the relationships of scenarios,quality attributes, and patterns is one of the mostimportant work to be done.

Scenarios have been found quite effectiveand useful for exactly specifying qualityattributes. Several approaches use scenarios toencourage disciplined thinking during SA designand evaluation activities [4, 30]. A pattern isknown solution to a recurring problem in a

particular circumstance. One of the main goalsof using patterns is to design a SA with knownquality attributes. Each pattern either supports orinhibits one or more quality attributes. Eachpatterns description has large amount ofarchitecturally significant information, e.g.scenarios, quality attributed supported orhindered, forces, tactics and so on.

Author [32] proposes a framework of twotemplates 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 asimple process of identifying and extracting thearchitectural information from patterns. Table 5presents the first template, which captures theinformation extracted from patterns.

Author [32] claims that these templatesmake the relationships among scenarios, qualityattributes, and patterns explicit. Moreover, theproposed templates also capture one of the mostimportant parts of a pattern description, forces.

The forces of a pattern describe the factorswhose clash causes the problem that the pattern

attempts to solve by resolving the clashes amongthose factors. Recently, software engineeringcommunity has started paying appropriateattention to the forces of a pattern in an attemptto fully understand the problem and solutiondescribed in a pattern.


6/15



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 Patter

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 Attribute Positively NegativelyAttribute Supported Attribute Hindered

SupportedGeneralScenarios

S1S2S..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 ProposedScenarios 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.

ConcreteScenario

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/Styl Name of the architectural pattern or style that can support this scenarios.

Design Tactic 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 desiredquality 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.

IV. A QUALITY DRIVEN DESIGN

APPROACH

The software engineering community hasdeveloped different methods to support systematicreasoning about various quality attributes (e.g.,

real-time [16], reliability [17], and performance[18]) during software architecture design.However, these methods study a specific qualityattribute in isolation. In reality, quality attributesinteract with each other. For example, there isgenerally a conflict between configurability andperformance [19]; performance also impactsmodifiability, and each quality attribute impactscost [20].


7/15



Some researchers have developed methods tomake quality attributes a central considerationduring application design. Bosch [21] proposes amethod that explicitly considers quality attributesduring the design process. Hofmeister et al.[22]describe a framework known as global analysis to

identify, accommodate, and describearchitecturally significant factors includingquality attributes early into the design phase.However, these methods do not sufficientlysupport the reasoning about the qualityconsequences of each design decision.

The work of Chung et al. [15] provides aframework that considers each design decisionbased on its effects on the quality attribute space.However, it does not provide support to explicitlyperform trade-off analysis between competing

design decisions. Bass et al. [20] have proposedthe Attribute Driven Design (ADD) method tohelp the architect base the design process on thedesired quality attributes. ADD is basically builtupon Attribute Based Architecture Styles (ABAS)[23], and architectural views [24, 25]. It providesa framework to make design decisions withknown affects on the desired quality attributes.However, the codified knowledge or experienceof an architect may present more than one designalternative for each design decision. In thissituation, a quantitative reasoning framework to

support the multi criteria decision analysis cancomplement methods like ADD.

Authors [33] goal is to reduce the complexityand increase the reliability of SA design. One wayof doing it is by systemizing the architecturaldesign process, as suggested earlier in [34]. Thedesign approach must also deal with inter-dependencies among different decisions. Initially,they identified two types of dependencies(Alternative-Based and Context-Baseddependencies). Based on these observations, they

argue that the SA design problem can beformulated as a global optimization problem,since design decisions are highly dependent oneach other, and the selection of any designalternative must not violate global constraints.

Therefore, they state the optimization problem asfollows:

"They seek to maximize the value of the SA for allstakeholders involved by selecting alternativesyielding highest value scores, during assuring thatdependencies are maintained and globalconstraints stated are not violated".

To the best of their knowledge, none of theexisting design approaches explore the potentialof applying optimization techniques for solvingcomplex software design problems, comprised ofmultiple inter-dependent architectural designdecisions.

In this paper a design approach isArchDesigner, which comprises three steps asshown in Figure 2. It starts with the first designdecision and computes value scores for itspotential alternatives solutions. This is repeated

for each design decision. The second steptransforms the computed value scores into anormalized form, in order to prepare them for thethird step. Finally, the third step formulates theoptimization equations so as to maximize thevalues associated with selected alternatives,subject to stated constraints and inter-dependencies.Step 1: Value score computation:

They define the value score of a design alternativeas the degree to which an alternative satisfies the

desired quality attributes. For a particular designdecision, potential design alternatives areevaluated across a set of quality attributesassociated with that design decision. Figure 3depicts the process of computing alternative valuescores pertaining to a particular design decision.

The input to this process is twofold:

Design alternatives and their relativesupport for associated quality attributes.

Preferences on associated qualityattributes provided by differentstakeholders


8/15



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

designd cision

Compute

alternative

value scores

Consider

next design

decision

Normalized

Computed

Value Scores

Formulate

the

O timization

Solve the

Optimization

roblem

Other

Design

Decision


9/15



Step 2: Normalization of value scores:Before moving on to the third step, they need tonormalize the alternatives value scores obtainedin the previous step. The reason for this is thatthe alternatives value scores from differentdecisions will be summed in the next step.

Hence, they have to scale them relatively. To dothis, they weight the different decisions Njrelatively in a manner that reflects their relativesignificance to the application. Naturally, somedesign decisions are more important than others,and thus should receive higher weights. Havingdone this, they then multiply the obtained valuescores by the weight of their correspondingdecision: = Step 3: Optimization formulation:In this step, they seek to maximize the

accumulative value score, which represents theobjective function. This can best be formulatedusing Integer Programming (IP):

:

Subject to:

[1,,]: = 1

,

,.,


10/15



Fig. 5 GB Design decisions and their Interdependencies

Directed arrows in Figure 5 depict inter-dependencies among the different decisions. Alist of the selected design decisions is shown in

Table 7, along with the corresponding

alternatives that were considered, relevantquality attributes, and the stakeholdersparticipating in the decision-making process.Highlighted alternatives represent the realselections made.After analyzing the selected design decisionsand their alternatives and inter-dependencies,171 potential combinations of alternativesexisted for the architect to consider. In addition,every design decision involved more than onegroup of stakeholders, each of which favoreddifferent solutions. Also, the project was

constrained by one-year duration. All theseissues made the design activity quite complex.

Table 7. List of selected decisions, along with theiralternatives, Quality attributes, and stakeholders

DesignDecision

Alternatives

QualityAttributes

Stakeholders

Architecture (ARCH)

3-tierusing

J2EE(THTJ)

3-tierusing.Net(THTD

) 2-tier

(TWOT)

COABS(COAB)

Modifiability

Scalability Performanc

e

Cost Developme

nt effort

Portability Ease of

installation

Development Team

Research Teams Funding Agency

EventNotification(EVNT)

Publish-Subscribe

Reliability Performan

ce Complexit

Development

Team Research

usingJMS(JMS)

Publish-Subscribeusing

MSMQ(MSMQ)

Databasetriggers(TRGR)

COABS(COAB)

y ofimplementation

Teams

Authentication (AUTH)

Database-basedSecurity (DB)

J2EE-basedSecurity(J2EE)

.NETbasedSecurity(.NET)

COABS(COAB)

Complexity ofImplementation

Ease ofDeployment andsetup

Development

Team Research

Teams

RemoteAccess(RMAC)

Browser-based(HTTP)

WebServices(WEBS)

SecureNetwork(VPN)

Performance

Security Modifiabi

lity Complexi

ty ofdeployment

Complexity ofimplementation

Development

Team Research

Teams Funding

agency

SupportingNon-

windowsplatformsfor API(HERT)

J avaLangu

age(J AVA)

Browser(BROW)

CLanguage (C)

Usability Modifiab

ility Cost Develop

mentEffort

Development

Team Research

Teams


11/15



Design decisions plays vital role in SAdesign. In this paper a design approach isArchDesigner, which comprises of three stepsfor solving optimization problem globally. As anexample GB case study was included, itprovides the way of handling design decisions

for complex systems. With these discussions therelationship between design decisions andquality attributes are clearly specified.

V. ELEMENTS OF A REASONINGFRAMEWORK

The architecture description provided as inputmust satisfy the RF analytic constraints. Thedesired quality attribute measures are restrictedto problems from the problem description.Interpretation translates the architecturedescription into a model representation. Then,

the evaluation procedure reads the modelrepresentation (and sometimes the desiredquality attribute measures) to predict the qualityattribute measures that are the output of the RF.

The evaluation procedure uses algorithms basedon theanalytic theory. The Figure 6 shows howa generic RF works.

Fig. 6 Elements of a reasoning framework

From the users perspective, the RF is a

black box that takes an architecture descriptionand desired quality attribute measures as inputand produces quality attribute measures asoutput. Users dont need to be experts in theanalytic theory or understand how the internalelements work. Sections 3.1 to 3.6 describe thesix elements of a RF, using as example a real-time performance RF.

A. Problem DescriptionThe problem description identifies the qualityattribute problems for which the RF is used,more specifically the quality measures that canbe calculated or the quality requirements thatcan be evaluated. For example, while

performance is a broad topic with many possiblemeasures, a specific performance RF might onlycalculate task latency or evaluate whether taskswill meet their deadlines.

B. Analytic TheoryEach RF is based on an analytic theorya bodyof knowledge used to reason about some qualityattribute. Analytic theories draw fromestablished disciplines, such as queuing theory,RMA, Markov analysis and automata theory. Ananalytic theory defines assumptions, elements

and their properties, rules governing therelations among elements, and logic for drawingconclusions from a model in the theory. Forexample, RMA theory is used to reason aboutworst-case latency. It assumes fixed priorityscheduling is used, and arrival rates andexecution times have little or no variability.RMA models are expressed in terms of sets oftasks, their topology and priorities, executiontimes, and the frequency with which externalmessages arrive. RMA theory includes formulaefor computing worst-case latency and ensuring

deadline satisfaction.

C. Analytic ConstraintsEach RF specifies analytic constraints that mustbe met by the input architecture description to beanalyzable. An example of an analytic constraintfor a performance RF is all event arrivals mustbe periodic. By restricting the design space towhich the RF is applied, assumptions can bemade in the analytic theory and evaluationprocedure. These assumptions are necessary toimprove confidence in the results, permit

analytic tractability, or even ensure solvability.The RF may also require specific properties ofthe elements to be known. For example, aperformance RF may require the execution timeof each component.


12/15



D. Model RepresentationA model is a simplified version of reality.Models are represented using some parseableencoding for elements, relations and theirproperties. For example, the modelrepresentation of a system in a performance RF

consists of tasks and subtasks that haveexecution time and priority as properties. A RFmay provide a visualization of the model, suchas that shown in the lower portion of Figure 7.

E. InterpretationInterpretation is the process that takes anarchitecture description as input and generates amodel representation that contains allinformation that the evaluation procedure needs

to calculate quality attribute measures. In theperformance RF example, the architecturaldescription must identify the schedulableentities, the execution times that contribute toeach of them, and the period of each. The upperportion of Figure 6 is an example of an

architecture description used as the input to aperformance RF called SS. The lower portionshows the performance model.

F. Evaluation ProcedureAn evaluation procedure is the computablealgorithm by which a RF calculates qualityattribute measures from a model representation.

The algorithm can be directly implemented, orsimulation tools and spreadsheets can be used.

Fig. 7 Interpretation for SS [35].

In the performance example, the evaluationprocedure to calculate worst-case latency for

process I is an algorithm for iteratively solvingthe following formula until it converges (valuesof independent variables come from the modelrepresentation).

= + +

With these discussions, encapsulating thequality attribute knowledge with the help of

reasoning framework, which comprises of sixstep process that produces quality attribute

measures as output by considering real-timeperformance RF as an example.

VI . CONCLUSIONSoftware Architectures are generally designedwith particular functional and nonfunctionalrequirements. Several methods have beenproposed to design of architectures with respect


13/15



to desired quality attributes. Existing softwarearchitecture selection methods [5, 6, 7, and 8]have been analyzed to identify their limitations.

The framework provides the rationale for anarchitecture selection process by comparing thefitness of contending candidate architectures for

the envisioned system based on the qualityrequirements of different Stakeholders. Insupporting to SA design and evaluation processby considering two templates, one is to capturethe extracted information from patterns andanother is to documenting the architecturalinformation along with forces. With thesetemplates the relationships among scenarios,quality attributes and patterns are explicitlyprovided. Design decisions plays vital role in SAdesign. In this paper a design approach isArchDesigner, which comprises of three steps

for solving optimization problem globally. As anexample GB case study was included, itprovides the way of handling design decisionsfor complex systems. With these discussions therelationship between design decisions andquality attributes are clearly specified. Usingoptimization techniques, it attempts to determinethe optimal combination of design alternativesthat best satisfy stakeholders quality goals andproject constraints. This paper discusses atechnique developed at the SoftwareEngineering Institute (SEI) for encapsulating

quality attribute knowledge for use in the designsoftware architectures. A reasoning framework,our encapsulation mechanism, can be used bynonexperts to analyze a specific quality (e.g.,performance, modifiability, availability) of asystem, which comprises of six step process thatproduces quality attribute measures as output byconsidering real-time performance RF as anexample.

In [32] plan to use experimentation to assessauthors claim of improving SA design and

evaluation process by distilling SA sensitiveinformation from patterns and usefulness of theproposed framework to document theinformation. In [33] also plan to build a toolbased on the ArchDesigner to support the SAdesign process. In [35] have defined and at leastpartially 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 andusability. These RFs are being implemented asplug-ins to the tool infrastructure developed forArchE and for PECTs.

REFERENCES

[1] Bass, L., et al., "Software Architecture inPractice", 2 ed.2003: Addison-Wesley.

[2] Clements, P., et al., "Evaluating SoftwareArchitectures: Methods and Case Studies".2002: Addison-Wesley.

[3] Bosch, J., "Design & Use of SoftwareArchitectures: Adopting and evolving aproduct-line approach". 2000: Addison-Wesley.

[4] Matinlassi, M., et al., "Quality-drivenarchitecture design and quality analysismethod: A revolutionary initiation approach

to a product line architecture," Tech. ReportVTT Technical Research Centre of Finland,Espoo, 2002.

[5] M. Svahnberg et al, "A Method forUnderstanding Quality Attributes inSoftware Architecture Structures", ACMtransactions (2002).

[6] Liliana Dobrica et al, "A Survey on SoftwareArchitecture Analysis Methods", IEEEtransaction on Software Engineering volume28 (July 2002).

[7] Kazman et al., "Architecture Trade-offAnalysis Method", Technical report,Carnegie Melon University, SoftwareEngineering Institute (1998).

[8] Kazman et al, "Quantifying the Costs andBenefits of Architectural Decisions", IEEE2001.

[9] Farcisca losavio et al, "QualityCharacteristics of Software Architecture",

Journal of object Technology Volume 2(2003).

[10] Chung, L., et al. Non-FunctionalRequirements in Software Engineering.

Kluwer Academic Publishers, Boston, Ma.1999.

[11] Bachmann, F., et al., Preliminary Design ofArchE: A Software Architecture DesignAssistant, SEI-2003-TR-021, SEI, 2003.

[12] Wallnau, K. Volume III: A Technology forPredictable Assembly from CertifiableComponents, SEI-2003-TR-009, SEI, 2003.


14/15



[13] Eelko K.R.E. Huizingh and. Hans C.J .Vrolijk, "Decision Support for InformationSystems Management: Applying AnalyticHierarchy Process", Research schoolsystems 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 conferencePittsburgh, Pennsylvania (2001).

[15] Chung, L., et al. Non-FunctionalRequirements in Software Engineering.Kluwer Academic Publishers, Boston, Ma.1999.

[16] Klein, M.H., et al. A Practitioner'sHandbook for Real-Time Analysis: Guide toRate Monotonic Analysis for Real-Time

Systems. Kluwer Academic, 1993.[17] Lyu, M.R. Handbook of Software Reliability

Engineering. McGraw-Hill and IEEEComputer Society, New York, 1996.

[18] Smith, C.U., and Williams, L.G. SoftwarePerformance Engineering: A Case StudyIncluding Performance Comparison withDesign Alternatives. IEEE Transactions onSoftware Engineering, 19(7), 1993.

[19] Lundberg, L. et al. Quality Attributes inSoftware Architecture Design. Proceedingsof the IASTED 3rd 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 SoftwareArchitectures: Adopting and evolving aproduct-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-BasedArchitectural Styles, Tech. Report,CMU/SEI-99-TR-022, Soft EngineeringInstitute, Carnegie Mellon University.

[24] Kruchten, P.B. The 4+1 View Model ofarchitecture. IEEE Software, 12(6), 1995, p.42-50.

[25] Soni, D., Nord, RL, and Hofmeister, C.Software Architecture in Industrial

Applications. Proc. ofthe 1 7th InternationalConference on Software Engineering,Washington, USA, 1995.

[26] Hissam, S., et al., Predictable Assembly ofSubstation Automation Systems: AnExperiment Report, Second Edition, SEI-

2002-TR-031, SEI, 2002.[27] Bachmann, F., et al., Experience in Using

an Expert System in Designing forModifiability, Proceedings of WICSA,2004.

[28] Bachmann, F., A Variability ReasoningFramework, SEI-2005-TR-009, SEI, 2005.

[29] Ivers, J . & Sharygina, N. Overview ofComFoRT: A Model Checking ReasoningFramework, SEI-2004- TN-018, SEI, 2004.

[30]Thiel, S., "On the Definition of aFramework for an Architecting Process

Supporting Product Familiy Development,"Proc. of the 4th Int'l Workshop on ProductFamily Engineering. 2001. Bilbao, Spain.

[31] Anderson, D., Sweeny, D., and T. Williamsan Introduction to Management Science:Quantitative Approaches to DecisionMaking. South-Western EducationalPublishing, 2002.

[32] Muhammad Ali Babar., " Scenarios, QualityAttributes, and Patterns: Capturing andUsing their Synergistic Relationships forProduct Line Architectures," Proc. of the

11th Asia-Pacific Software EngineeringConference (APSEC04).

[33]Tariq Al-Naeem, Ian Gorton, MuhammedAli Babar, Fethi Rabhi, and BoualemBenatallah., A Quality-Driven SystematicApproach for Architecting DistributedSoftware Applications.

[34] Al-Naeem, T., et al. Systematic Approachesfor Designing B2B Applications.International Journal ofElectronicCommerce (IJEC), Nov 2004.

[35] Len Bass, James Ivers, Mark Klein, PauloMerson, Kurt Wallnau., EncapsulatingQuality Attribute Knowledge. Proc. of the5th Working IEEE/IFIP Conference onSoftware Architecture (WICSA05).

[36] Gorton, L, and Haack, J. Architecting in theFace of Uncertainty: An Experience Report.Proc. OfInternational Conference onSoftware Engineering, Edinburgh, Scotland,2004.


15/15



[37]Tung-King See et al, "Multi attributeDecision Making Using HypotheticalEquivalents", Proceedings of DesignEngineering Technical Conferences andComputers and Information in EngineeringConference ASME (2002).

[38] Software Architecture Selection FrameworkBased on Quality Attributes-G. Zayaraz andP. Thambidurai-IEEE Indicon 2005Conference, Chennai, India, I I - 1 3 Dec.2005

AUTHORS BIOGRAPHY

K. K. Baseer obtained hisBachelor of Technologyand Master degrees in

Computer Science andEngineering from JNTUH,Hyderabad and currentlyhe is pursing Ph.D. degreein JNIAS/JNTUA

University, Hyderabad. At present working as anAssistant Professor in department of Information

Technology, SVEC, Tirupati, INDIA. His areasof interest include Software Engineering,Software Architecture, IRS, and other latesttrends in technology. He has more than 4 yearsof experience in teaching and in Industry in the

area of Computer Science and Engineering.

Dr. A. Rama Mohan Reddyreceived his M. Tech.(Computer Science) fromNIT, Warangal andcompleted his Ph.D. in thearea of software Architecturefrom Sri VenkateswaraUniversity, Tirupati. He has

more than 20 years of teaching experience. He

published many papers in the peer-refereedjournals and conferences. His interested areasare Software Engineering, SoftwareArchitecture, Data Mining and ComputerOrganization.

C. Shoba Bindu receivedher B.Tech Degree inElectronics & Comm.Engineering from

JawaharLal NehruTechnological University,

Anantapur, India, in 1997,M.Tech. in Computer

Science & Engineering from Jawaharlal NehruTechnological University, Anantapur, India, in2002. She received her Ph.D. in ComputerScience and Engineering at Jawaharlal Nehru

Technological University, Anantapur, A.P.,India. Her Research Interested includes NetworkSecurity and Wireless Communication Systemsand Software Engineering.

Documents

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