JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.

ORG

93

A Survey on Decision based Software Architecture Design approaches

Dr. G. Zayaraz, C. Dhaya, and Dr. V. Vijayalakshmi
Abstract Research on software architecture suggests that it is no longer perceived as interaction among components and connectors only, but rather as a set of architectural decisions. Architectural Knowledge is defined as the representation of the software architecture along with architectural decisions and their rationale, external influence and the development environment. Although the importance of architectural knowledge has been recognized for a considerable period of time, there is still no systematic process emphasizing the design decisions in the software architecture. Several decision-based architectural design techniques have been suggested, to provide real-world support to design reasoning and justification. This paper is a survey about the well-known existing architectural decision-based approaches for different architecture knowledge management strategies. The comparison framework is used to evaluate the level of support provided by the various approaches. Further the major differences and missing desired features in these methods are highlighted. Index Terms Software architecture, Architectural Knowledge (AK), Design decision, Design rationale, Decision Constraint Graph, Bayesian Belief Network.

1 INTRODUCTION
OFTWARE Architecture is a recognized discipline in software engineering, though it is still emerging [1]. Current methods for the documentation of software architecture concentrate on components and connectors [2],butfailtodocumentdesigndecisionsandtheirratio nale.Thismayleadto(i)costlysupportforsystemdevel opment(ii)poorcommunicationamongstakeholdersand (iii)reducedreusabilityofsoftware[3,4].Thearchitecting process can be considered as a decision making process throughwhichtheappropriatedecisionsmustbemadeat the right time [5]. Architectural design decisions play a vital role in the software architecting process e.g. during design, development, evolution, reuse and integration of architectures. In design, the main task is to make design decisions.Indevelopment,itisimportanttoknowwhich andwhycertaindesigndecisionshavebeentaken.Archi tecture evolution is about making new design decisions or removing obsolete ones to satisfy changing require ments.Reuseofsoftwarearchitectureistheuseofearlier tried and tested combinations of design decisions (e.g. design patterns or styles). In the integration of systems, themainconcernistheunificationofthedesigndecisions and their assumptions. These decisionbased approaches ofdevelopingsoftwarearchitecturemanagearchitectural knowledge emphasizing the explicit organization and documentationofdesigndecisionsanddocumentdesign rationale.

Thispapercomparesninedifferentdecisionbasedap proachesviz.,(i)Archium[6,7];(ii)AkermanandTyrees Ontology(ATO)[8];(iii)AREL[9];(iv)ArchDesigner[10]; (v) Bayesian Belief Network based Alternatives Selection Method (BBNbASM) [11]; (vi) AQUA [12]; (vii) Auto mated Solution Synthesis Method (ASSM) [13]; (viii) PAKME [14]; (ix) ADDSS [15]. The decision based com parison framework aims to (i) Recognize the differences and the similarities of these approaches (ii) Find the strengthsandweaknessesoftheseapproachesandthere byexplorenewpossibledirectionsforresearch. Therestofthispaperisorganizedasfollows:Section2 reviewsthedifferentdecisionbasedapproachesinbrief. Section3specifiestheanalysiselementsbasedontheap proaches on software architecture knowledge manage ment, decision making, design rationale and the quality. The outline of the comparison framework is tabulated. Section4concludesthesurveywork.

2 OVERVIEW OF DECISION BASED APPROACHES

2.1 Archium
Archium defines software architecture as a set of design decisions.
Architecturalmodel Definessoftwarearchitecture concepts,whicharesimilarto theconceptsusedinexisting architecturalmodels

DesignDecisionModel

Designdecisionsaretreatedasfirst classconcept
Motivation Causes Cause Motivates Problem Solve Solution Selects Choice

Dr. G. Zayaraz is with the Computer Science Department, Pondicherry Engineering College, Puducherry 605014. Ms. C. Dhaya is with the Computer Science Department, Pondicherry Engineering College, Puducherry 605014. Dr. V. Vijayalakshmi is with the Electronics and Commuication Department, Pondicherry Engineering College, Puducherry605014.

Compositionmodel Specifyhowdifferentmod elsarecomposedtogether

Figure 1: Archium meta-model

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

94

As shown in Figure 1 Archium consists of three submodels. The Archium aims at providing traceability among a wide range of AK concepts such as requirements, decisions, architecture descriptions and implementation. All of these AK concepts are expressed in Archium language, an extension of Java. Visualization and traceability of architectural decisions are the core features of Archium [16]. Both these features are essential for better understanding of the architectural design.

2.2 ATO
Akermann and Tyree Ontology (ATO) focus on architecture decisions which involve the use of ontology [8]. As mentioned in Figure 2, ATO is built on ontology that connects stakeholder concerns, architecture decisions, architecture assets, and an implementation roadmap. The Stakeholders Concern drives architecture entities and is captured as a set of key decisions. This concern includes business need (business goals, objectives, or issues), risk, change case (future requirements), quality (nonfunctional requirements such as performance, reliability, etc.), and capability (functional features of the system). The Architecture Decision is the key concept in this approach and it connects other three segments viz., Stakeholders concern, Implementation roadmap, and Architectural asset. It can be viewed as making changes to the various Architectural Assets such as the systems, interfaces, nodes, and components.
Stakeholders Concern addressedby Architecture Decision transforms ArchitectureAsset Implementation Roadmap implementedby

is a rationale-based architecture approach used for exploring architectural design reasoning (part of architectural knowledge) [9]. Further it specifies how architectural elements are related to requirements and design models. This UML based approach is aligned with the industry architecture design practice to support its application. AREL has three objectives: (i) Effectively capture design rationale (ii) Must not interfere with the natural process of architecture design during design rationale capture (iii) Retrieval of design rationale is easy to achieve. AREL is an acyclic graph which relates architecture elements (AE) to architecture rationale (AR) as illustrated in Figure 3.
DesignConcern <<AE>> Inputsthatcauseor motivateadesign decisionaredesign concerns. DesignDecision Capturesdesign issuesanddesign rationale DesignOutcome <<AE>> Resultsofadesign decision

Figure 3: AREL model

In AREL, architecture rationale (AR) comprises three types of justifications: qualitative rationale, quantitative rationale and alternative architecture rationale as described in Figure 4.
ArchitectureRationale(AR)

Qualitative designrationale (QLR)

Quantitative designrationale (QNR)

AlternativeArchi tectureRationale (AAR)

Representsthe reasoningand thearguments,in textualformat

Indicatetherelative costs,benefitsand risksofthedesign options

Documentthe discardeddesign options.

Figure 4: Architecture Rationale (AR) Figure 2: High level view of Ontology

The Implementation Roadmap aims at implementing the software architecture design; it provides direction on migrating to the target system. To build the instance of this ontology for a particular system, this approach suggest a five-steps methodology including (i) Capturing stakeholder concerns (ii) Analyzing the current architecture (iii) Defining the target architecture (iv) Conducting a gap analysis and producing the roadmap (v) Validating the architecture. This approach is based on Protg, an open source ontology tool which provides repository support. Following benefits have been examined in ATO (i) Improved focus on what is important (ii) Improved precision and clarity (iii) Creating a repository of architecture definitions with Repository support (iv) Support for impact analysis (v) On demand view creation.

To support architectural understanding and maintenance, traceability and probabilistic techniques have been proposed in this approach [17]. These probabilistic techniques can help to carry out change impact analysis and root cause analysis which is based on Bayesian Belief Networks (BBN). The traceability techniques comprise of forward, backward and evolution tracings.

2.4 ArchDesigner
ArchDesigner is a quantitative quality-driven architecture design approach [10] that tries to find the best architecture which satisfies conflicting stakeholders quality goals, competing architectural concerns, and project constraints such as time and cost limitations. This approach uses optimization techniques particularly Integer Programming [18], for optimizing the SA design comprised of multiple inter-dependent design decisions. ArchDesigner comprises three steps as shown in Figure 5. This approach evaluates and selects among candidate

2.3 AREL
AREL (Architecture Rationale and Elements Linkage)

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

95

software architectures in a fine-grained fashion, thereby helping stakeholders arriving at a suitable architecture solution. It helps architects in (i) Making informed architectural decisions (ii) Engineering distributed SA systematically (iii) Alleviating design complexity (iv) Handling the concerns of different stakeholders.
Step1:ValuescoreComputation
Takedecision1 Next decision

probability, the more possible this quality attribute may be achieved.

2.6 AQUA
AQUA is an integrated design-decision based architecture design approach for acquiring good software architecture with respect to its requirements [12]. AQUA supports finding, analyzing, and changing decisions based on the model of architectural design decisions. During the process, the AQUA easily supports the integration of architectural evaluation with architectural transformation. Architectural evaluation plays a significant role in revealing any potential defects or assessing the fulfillment of required quality requirements during finding and evaluating decisions. Architectural transformation plays a significant role in reducing defects in the architecture or making changes to the architecture during changing decisions. This change will be subject to change impact analysis using a Decision Constraint Graph. Therefore, the AQUA provides software architects with a means for achieving quality attributes through acquiring good software at the architectural level. However, these steps are not supported by any tools.

ComputeValuescoresforits potentialalternativessolutions

Foreachdecisiontopic,eachqualityattributesare quantified using MADM (Multiple Attribute DecisionMethod)

Step2:ValuescoreNormalization
Transforms the computed value scores into a norma lizedform

2.7 ASSM
Step3:OptimizationFormulation
Formulates the optimization equations to maximize thevaluesassociatedwithselectedalternatives,subject tostatedconstraintsandinterdependencies.

Step1:Issueelicitingactivity
Original architecture Project Constraints Requirements determines Architecturallysignificantissues(ASRs)

Figure 5: Steps in ArchDesigner

2.5 BBNbASM
Bayesian Belief Network based Alternatives Selection Method (BBNbASM) [11] uses BBN (Bayesian Belief Network) to support design decision-making. Bayesian Belief Network is a powerful technique for reasoning under uncertainty. It is based on the assumption that the impact of design decisions on quality attributes is undeterministic. The proper way to describe undeterministic is to assign a probability value between 0 and 1, rather than a deterministic value which is 0 or 1. Qualitative and quantitative analysis is performed over the BBN to understand how the design decisions influence system quality attributes to reach optimized software architecture. Bayesian Network consists of a set of nodes and a set of directed edges representing casual/influential relationship among these nodes. In Directed Acyclic Graph (DAG), nodes represent design decisions and quality attributes and a directed edge represents influential relationship between two nodes (meaning that one has influence on another). Each node is associated with a Conditional Probability Table (CPT) to store the conditional probability and the influence is measured by a probability. Once the Bayesian network is built up, a Bayesian network toolkit can be used to calculate the posterior probability value of each quality attributes. The different designs (decisions have different values) can be compared with the probability of quality values. The higher the

nextissue

Step2:Solutionexploitingactivity Issue1
Selectcandidatesolutions withpros&cons

Reusabledesign knowledgeor newtechnologies

basedon

Step3:Solutionsynthesizingactivity
This activity automatically synthesizes the candidate architec turesolutionsfromvariousissuesolutions. (i) The relations between issue solutions are identified to indicatewhethertheycanbecombinedtogether. (ii) Allfeasiblecombinationsofissuesolutionsareexplored. (iii) The issue solutions within each feasible combination are mergedtogeneratethearchitecturesolutions.

Step4:Architecturedecidingactivity
Thestakeholdersselectthetargetarchitecturesolutionfromthe synthesizedcandidatearchitecturesandvalidatethem.Tomake theselection,theyneedtoevaluatethecandidatearchitectures.

Figure 6: Steps in ASSM

Automated architecture solution synthesis method (ASSM) provides pragmatic help to architects, in the

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG
KnowledgeRepositoryofPAKME

96

process from architecturally significant issues to candidate architecture solutions [13]. The steps involved in ASSM are described above in Figure 6. ASSM integrates the notions of decisions and rationale in the architecture design process itself. This reduces the overhead of rationale capturing and recording, so that the process can be more efficient and productive.

GenericKnowledge Includesgeneralscena rios,patterns,quality attributes,designoptions

Projectbasedartifacts Includesconcretescenarios, contextualizedpatterns,quality factors,architecturedecisions

Webbaseduserinterface component (KnowledgeAcquisition) Providevariousformsand editingtoolstoenterproject specificornewgenericknow ledgeintheknowledgereposi tory

KnowledgeManagement Component (KnowledgeMaintenance) Provide various features to modify, delete and instantiate differentarchitecturalartifacts

2.8 ADDSS
ADDSS (Architecture Design Decision Support System) a web-based tool for storing, managing and documenting architectural design decisions taken during the architecting process. Further it provides traceability between requirements and architectures. To implement decision view [19] in ADDSS, a meta-model of architecture design decisions is used. This meta-model represents the relations between the decisions, the architecture, stakeholders involved in different views and the iterations performed in the design process. ADDSS includes the following features: (i) Flexible approach based on a set of mandatory and optional attributes for characterizing architectural design decisions (ii) Design decisions captured in ADDSS is reusable (iii) Provides a repository of patterns as proven design solutions (iv) Explicit relationships to other products of the software lifecycle and between decisions. These links are used to estimate the impact of adding, modifying, or removing a decision (v) Iterative construction process to show the evolution of architectural knowledge (vi) Dependencies between decisions form a traceable link (vii) Documents the decisions and architectures as PDF reports that are generated automatically (viii) Architecture visualization facility (ix) Allows the storage of different projects and architectures with each project having one or several architectures.

PAKME SERVICES
Searchcomponent (KnowledgeRetrieval) Helptheuserstofindrelevant informationbyKeyword search,advancedstringsearch andnavigationalsearch Reportingcomponent (KnowledgePresentation) Presentarchitectureknowledge inastructuredmannerbyusing representationmechanismslike utilityandresultstrees

Figure 7: PAKME model

3 ANALYSIS FRAMEWORK
In order to carry out the comparison in a uniform way, a comparison framework has been defined based on the activities that take place during the software architecture life-cycle. The outline for the comparison is described by the main concepts stated below and methodologies' characterizations as tabulated in Table 1. This comparison attempts to provide a broader perspective and understanding of how each decision based method works. The Table 2 specifies the key benefits and liabilities of the different decision methods in order to determine the suitable context of using each of them.

2.9 PAKME
PAKME (Process based Architecture Knowledge Management Environment) is a web-based architecture knowledge management approach. It aims in providing knowledge management support for the software architecture process. It is built on top of Hipergate (an open source groupware). PAKME supports both codification and personalization as it not only provides access to AK but also identifies the knowledge source. PAKME provides knowledge repository, templates and various functions to capture, manage, and present architectural knowledge. PAKME provides four main services: knowledge acquisition, knowledge maintenance, knowledge retrieval and knowledge presentation. The outline of the PAKME model is described in Figure 7. Moreover it supports multi-user and multi-project collaboration which helps geographically distributed stakeholders to share architecture knowledge.

Table 1: Framework Elements for Comparison

Elements
Representationof architectureknow ledge ImpactofQualityon thesoftwarearchitec ture

Description
TheDivisionAstatesthegeneraldescriptionof thearchitectureandtheinvolvementofthestake holderswithdifferentviews. TheDivisionBspecifiestheQualityissuestobe consideredinthesoftwarearchitectureprocess.It isusedtoselectthebestdecisionbasedsoftware architecturedesignonwhichthewholesystemis articulated. TheDivisionCrevealsthevariousprocesses involvedintheDecisionmakingdetailsand specifytherelationshipsbetweenthedecisions. TheDivisionDdetailshowtherationalehas beencapturedandretrieved.

Decisionmakingin softwarearchitecture Characterizationof rationaleinchoosing thedesigndecision

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

97

Table 2: Comparison of Decision based Methods

Features

ARCHIUM

ATO

AREL

ArchDesigner

BBNbASM

AQUA

ASSM

PAKME

ADDSS

REPRESENTATIONOFARCHITECTUREKNOWLEDGE(DivisionA) Architecture description (Describedin IEEE) Requirements drivenVsGoal driven Adoptedby Architecturalasset segment

Architectural designmodel

Architecturaldesign model

Architecturaldesign decisionmodel

Decisioncentric metamodel

Goaldriven (Requirementsandscenariosaretransformedtogoal)

Requirementsdriven (Relatedecisionswithscenariosandrequirements) (AQUA,ASSMandADDSSdonotdifferentiatefunctional&nonfunctionalrequirements) (Visualize differentarchi tectureviews accordingto stakeholders interest)

Supportfor viewpointsand views

(Similartoarchitec turalframeworks)

Modelling Stakeholders

Inrequirements modelwhere requirementsare preferredby stakeholder

Notincludedindesign process

Stakeholderisasso ciatedwitheach requirement

Differentrequire mentsfromdiffer entstakeholders basedonQuality attributes

Notincludedin designprocess

Notincludedin designprocess

Notincludedin designprocess

Usergroup/user (useridentifies ASRandscena rios)

Involvedin participation

Architectural solutiondescrip tion

Describearchitecturalsolutionsasaresultofdesigndecisions (Bothreasonsandsolutions)

Recordonlydesigndecisionswithoutreferencingsolutions

Bothreasonsand solutions

Onlydecisions

Bothreasons andsolutions

IMPACTOFQUALITYONTHESOFTWAREARCHITECTURE(DivisionB) *ModelQuality attributesandrelate themtodecision makingprocess *Qualityattribute isseenasspecia lizeddesigncon cern

Qualitymodel

Qualityattributesare involvedinthere quirement

*Qualityattributes areassociatedwith thedesigndeci sions

*Multiplequality attributesarein volved

Qualityattributes areinvolvedinthe requirement

Quality attributehas explicitrela tionshipwith nonfunctional requirements

Riskidentifica tionsupport

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

98

Features
Adaptableto requirement changes

ARCHIUM

ATO

AREL

ArchDesigner
Predefineallre quirementsbefore applyingreasoning processelsearchi tecturereanalysis

BBNbASM
Predefineallre quirementsbefore applyingreasoning processelsearchi tecturereanalysis

AQUA
Add/delete/modify nodesindecision constraintgraphbut manually

ASSM
Predefineallre quirementsbefore applyingreasoning processelsearchi tecturereanalysis

PAKME

ADDSS

Supportrequire mentimpact analysis

UseChangecaseto predictfuturechange

Supportforward traceabilityfor problemanalysis

Notadaptable

Notadaptable

DECISIONMAKINGINSOFTWAREARCHITECTURE(DivisionC) Decisionprocess tracking Documenting designdecisions inthearchitectur aldesign Explicit (usingmetamod el) Explicit (usingmeta model) Explicit (usingmeta model)

Explicit (usingmetamodel)

Explicit (usingmetamodel)

Explicit (lnformallydefinearchitecturaldecision asselectingadesignalternative) Quantifiedgraphi calmodel *Recordtheimpact ofdesignalterna tivesonquality attributesbutomits otherrelationships

Explicit (usingmetamodel) Qualifiedgraphical model Usedecisioncon straintgraphto recordtherelation shipbetweendeci sionvariables

Explicit (usingmetamodel)

Coverdifferenttypesofrelationshipsbetweenarchitecturalele ments Relationships betweendesign decisions (Traceabilityand dependency analysis)

Dependency relationshipby Visualizedgraph

Use(Decisiondecision relationship)torecord variousrelationship

Linkedbyarchitec tureelements

Documentdepen dencyrelationship

Recordrelation between solutionsusing inclusive, generalized, conflictiveand independent

Coverdifferenttypesofrelation shipsbetweenarchitecturalele ments *Classifyandrecordtheattributes ofeachdecision *Providessupportforreusing architecturalknowledge Donotprescribeawaydocument ingarchitecturaldesignotherthan designdecisions

Capturingdesign decisionsand designoutcomes Decisionmaking method

Componentand Connectorview

IBMarchitecturede scriptionstandard

Architectureratio naleconceptual modelandUML notation

Donotprescribeawaydocumentingarchitecturaldesignother thandesigndecisions

Componentand Connectorview

Qualitative

Quantitative Rankingdesign alternatives *Projectcostand timeconstraintsare takenintoaccount intheoptimization formulation. Advantage: *Usageofweighted qualityattributes andnormalization tomeasurethese twopriorities. Rankingdesign alternatives *Quantifyoverall architecturevalue bymeasuringalter nativesimpacton qualityattributes. *Interdependency relationshipbe tweendecisions *Bayesiannetworks tomodeldesign decisions,andis Decisionconstraint graphtosupportthe decisionevaluation anddecisionchang ingprocess. Advantage: *Generatevalidated architecturedesign decisionmodel. Disadvantage: *Notsupportedby anycomputerized tool. *Maintaining thedecisioncon

Qualitative

Decisionmaking process

Iterativedecisionprocess (SimilartodecisionloopofCOREmodel)

RecursiveAlgorithm toautomatically generatearchitec turecandidates Disadvantage: *Forlarge systemswherehuge numberofcandi datesis generated,ASSM, reducesitseffec tiveness

Iterativedecisionprocess (SimilartodecisionloopofCORE model) *Documentdesigndecisions withthehelpofarchitecturalstyles anddesignpatterns Advantage: *Reusing

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

99

Features

ARCHIUM

ATO

AREL

ArchDesigner

BBNbASM
intuitiveandeasy forreusing. *Evaluatesonlythe predetermined qualityattributes Disadvantage: *Prioritizingon qualityattributes anddesigndeci sionsismissing

AQUA
straintsgraphfor largesoftwaresys temisnotpossible

ASSM

PAKME

ADDSS

Decisionmaking level

Localizedlevel

Crosscuttingdesignlevel ASSMHolistic(butmanually)

Localizedlevel

CHARACTERIZATIONOFRATIONALEINCHOOSINGTHEDESIGNDECISION(DivisionD) Designreasoning Designdecision model Models(or)templates Architectureratio nalization UsingAHP Donotexplicitlycapturerationale (Reasoningprocess,algorithmandQuan titativeevaluationaretheclues) *InArchDesigner,Comparisonofalterna tivesandweighingofQualityattributes Designdecision model Models(or)tem plates Artifactsdata model Models(or) templates

Capturingratio nale

Retrievingratio nale

Standardtem plates(Design Architecturedesign Doesntmodelrationale rules,design rationale(AR) constraints,pros& butspecifytherelation duringdesign consarerecorded shipbetweenelements process indicatingwhythe solutionischosen) *AKisstoredinthe repositoryofontology ARtrace(QAR, Visualizationof tools QNR,AAR)& architectural *StandardQuerylan ARELtoolsupport decisionbya fortraceability dependencygraph guagetoretrievein formation

Evaluatingthedeci sionsinDecision constraint graph

Solutionsynthesis algorithm

Manually

Hyperlink providedin deci sion/solution template

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

100

CONCLUSION

[9]

An analysis framework to facilitate the comparison of the most popular nine decision based approaches [20] has been devised. The following observations were made during the comparative study: Lackofpropertoolsupport: Not all the methods have got the tools. Out of the nine decisions based approaches six methods have got the tools and three methods lack the tool support. Even though some methods have their tools they have not been completely developed and tested. Their usage in the industry is also limited. The reasons precluding the usage of these tools are yet to be explored. Supporting software life cycle with architectural knowledge: AK models encompass the fundamental conceptsofarchitecturalknowledge.Currentlyarchi tectural knowledge is mainly used in the design phase of the SDLC. Other software life cycle activi ties, like requirements engineering, detailed design, testing, implementation, deployment and mainten ance can also benefit from architectural knowledge. SinceAKhasnotbeeneffectivelyusedintheremain ing phases of the SDLC future research needs to ad dressthisissue.

[10]

[11]

[12]

[13]

[14]

[15]

REFERENCES
[1] Eeles, P.: The Process of Software Architecting, Technical Report (2006), available online: http://www.128.ibm.com/ developerworks/rational/library/apr06/eeles/index.html Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice, 2nd edition, Addison-Wesley Pearson Education, 2003. S. van der Ven, A. Jansen, J. Nijhuis, and J. Bosch, Design decisions: The Bridge between Rationale and Architecture, Rationale Management in Software Engineering, Springer, pp. 329-346, 2006. A. Jansen, J. S. van der Ven, P. Avgeriou, and D.K. Hammer, Tool Support for Architectural Decisions, Proceedings of the 6th IEEE/IFIP Working Conference on Software Architecture (WICSA),pp.4453,2007. R. Farenhorst, P. Lago, and H. van Vliet, Effective Tool Support for Architectural Knowledge Sharing, Proceedings of 5th European Conference on Software Architecture (ECSA), pp. 123-138, 2007. A. Jansen and J. Bosch, Software Architecture as a Set of Architectural Design Decisions, in Software Architecture, WICSA 05. 5th Working IEEE/IFIP Conference, pp. 109-120, 2005. A. Jansen, J. van der Ven, P. Avgeriou, and D. K. Hammer, "Tool Support for Architectural Decisions," in Software Architecture, WICSA '07. The Working IEEE/IFIP Conference, pp. 4-14, 2007. A. Akerman and J. Tyree, "Using ontology to support development of software architectures," IBM Systems Journal, vol.

[16]

[17]

[2]

[18]

[3]

[19]

[20]

[4]

45, pp. 813-825, 2006. Y A. Tang, Y. Jin, and J. Han, "A rationale-based architecture model for design traceability and reasoning," Journal of Systems and Software, vol. 80, pp. 918-934, 2007. T. Al-Naeem, I. Gorton, M. A. Babar, F. Rabhi, and B. Benatallah, "A quality-driven systematic approach for architecting distributed software applications," in Software Engineering. ICSE 2005. Proceedings. 27th International Conference, pp. 244-253, 2005. H. Zhang and S. Jarzabek, "A Bayesian Network approach to rational architectural design," International Journal of Software Engineering and Knowledge Engineering, vol. 15, pp. 695-717, 2005. H. Choi, Y. Choi, and K. Yeom, "An Integrated Approach to Quality Achievement with Architectural Design Decisions," Journal of Software, vol 1, pp. 40-49, 2006. X. Cui, Y. Sun, and H. Mei, "Towards Automated Solution Synthesis and Rationale Capture in Decision-Centric Architecture Design," Seventh Working IEEE/IFIP Conference on Software Architecture, pp. 221-230, 2008. M. A. Babar and I. Gorton, "A tool for managing software architecture knowledge," Proceedings - ICSE2007 Workshops: Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent, SHARK-ADI'07, Minneapolis, MN, 2007. R. Capilla, F. Nava, S. Prez, and J. C. Dueas, "A web based tool for managing architectural design decisions," 1st ACM Workshop on SHaring ARchitectural Knowledge (SHARK), 2006. Liang, P., Avgeriou, P., 2009. Tools and technologies for architectural knowledge management, Software Architecture Knowledge Management: Theory and Practice. Springer, pp. 91111. Antony Tang, A rationale-based model for architecture design reasoning. Ph.D. Thesis, Faculty of ICT, Swinburne University of technology, February 2007. D. Anderson, D. Sweeny, and T. Williams, An Introduction to Management Science: Quantitative Approaches to Decision Making, South-Western Eductional Publishing, 2002. Juan C. Dueas and Rafael Capilla. The Decision View of Software Architecture, Second European workshop on software architecture, EWSA 05, pp 222-230, 2005. W. Bu, A. Tang, and J. Han, "An Analysis of Decision centric architectural design approaches," Swinburne University of Technology http://www.swinburne.edu.au/ict/research/ documents/ SUTICT_TR2009_01.pdf, 2009.

[5]

[6]

[7]

[8]

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 12, DECEMBER 2011, ISSN 2151-9617 https://sites.google.com/site/journalofcomputing WWW.JOURNALOFCOMPUTING.ORG

101

Dr. G. Zayaraz is currently working as Associate Professor in Computer Science & Engineering at Pondicherry Engineering College, Puducherry, India. He received his Bachelors, Masters and Doctorate degree in Computer Science & Engineering from Pondicherry University. He has published more than twenty five research papers in reputed International Journals and Conferences. His areas of specialization include Software Architecture and Information Security. He is a reviewer/Editorial member for several reputed International Journals and Conferences. C. Dhaya is currently a research scholar pursuing her PhD in Computer Science and Engineering in Pondicherry Engineering College, Puducherry, India under the guidance of Dr. G. Zayaraz. She completed her B.E in Computer Science and Engineering in Adhiparasakthi Engineering College, Melmaruvathur, Madras University, and her M.E in Computer Science and Engineering in Jerusalem college of Engineering, Chennai, Anna University. She is working as an Assistant Professor in Adhiparasakthi Engineering College. Dr. V. Vijayalakshmi is currently working as Assistant Professor in Electronics & Communication Engineering at Pondicherry Engineering College, Puducherry, India. She completed her B.Tech, M.Tech and PhD in Pondicherry Engineering College which is affiliated to Pondicherry University. She has 19 years of teaching experience. To her credit, she has published 25 research papers relating to Network Security and software Engineering in several National / International Journals and Conferences.