DoSAM Domain-Specific Software Architecture Comparison Model *

Transcription

1 DoSAM Domain-Specific Software Architecture Comparion Moel * Klau Bergner 1, Anrea Rauch 2, Marc Sihling 1, Thoma Ternité 2 1 4Soft GmbH Mitterertraße 3 D Munich, Germany {bergner ihling}@4oft.e 2 Techniche Univerität Kaierlautern Fachbereich Informatik Arbeitgruppe Softwarearchitektur Gottlieb-Daimler-Straße D Kaierlautern, Germany {rauch ternite}@informatik.uni-kl.e Abtract. The architecture of an IT ytem i of crucial importance for it ucce. In orer to ae architecture fitne, a number of tanarize architecture evaluation metho have been propoe. Mot of them are intene for the evaluation of a ingle architecture at a certain point in time. Furthermore, the reult are often highly epenent on the peron performing the evaluation. Thu, uch metho cannot be ue to compare an rate ifferent architecture. The DoSAM metho intea provie an evaluation framework for comparing ifferent oftware architecture in a certain omain. After aapting thi framework to the application omain at han once, it can then be ue repeately for all future evaluation in a methoical an reproucible way. 1 Introuction The architecture of an IT ytem i a key ucce factor throughout it whole life cycle. During evelopment, the architecture erve a a blueprint for all further eign an implementation activitie. Deciion met by the oftware architect etermine quality attribute of the final ytem like performance, calability an availability [6]. If thee eciion mut be revie later on, ubtantial cot an elay may arie. Even more eriou are the conequence for the operation an maintenance phae, uring which the majority of cot accumulate [2, 3]. Only future-proof ytem bae on a clear, extenible tructure can be aapte to new requirement with reaonable effort [5]. A metho for aeing the trength an hortcoming of ytem architecture i, therefore, very valuable in a multitue of ituation. Firt of all, it allow the oftware architect to evaluate hi eciion early in the oftware life cycle in orer to avoi cotly wrong eciion. Another application i the aement of an exiting legacy ytem in orer to guie it reeign. Finally, potential cutomer may ue uch a metho to rate the architecture of alternative ytem uring the tener proce. * Thi work originate from a framework of reearch tuie relate to Moularity of Naval Ship an fune by the German Procurement Agency Buneamt für Wehrtechnik un Bechaffung in Koblenz.

2 Toay, a number of architecture evaluation metho exit, like SAAM an ATAM (both ecribe in [1]). Mot of them concentrate on the aement of a ingle ytem architecture at a certain point of time, yieling a lit of trength an weaknee (like SAAM) or of critical eign traeoff (like ATAM). Thi i helpful for performing an architecture review for a ingle ytem or for electing a certain eign variant for a pecial apect of a ytem architecture. However, the majority of current architecture evaluation metho o not upport the comparion an rating of ifferent architecture againt each other. Note that the quetion here i not whether a certain etail of architecture A olution i better compare to architecture B olution often, quetion like that have an immeiate, obviou anwer. However, acrificing an optimal etail olution in one area may pay off well in other area, an may inee be a eliberate an wie eciion. To take apect like thi into conieration, an to hift the view from etail problem to the big picture, aement metho nee to take a more general an more pecific approach at the ame time: More general, a they have to provie an aement framework that i applicable for ifferent oftware architecture, taking into account their trength an weaknee in orer to ultimately get a ingle number on a cale. More pecific, thi weighting proce mut be bae on clearly tate, tranparent criteria erive from the given context an goal of the application omain. The DoSAM metho preente in thi paper can bring together thee contrat. It central iea i to provie a omain-pecific oftware architecture comparion framework, which erve a a reference for ifferent architecture in a certain omain. The comparion framework i erive from omain-pecific cenario, an comprehen a it two imenion the neceary architecture ervice an the quality attribute for the omain uner conieration. The comparion framework i evelope once an can then be ue repeately to ae ifferent architecture. Thi make it valuable epecially for application in the tener proceure, but alo for comparing an electing ifferent overall approache uring ytem architecture eign. In principal, the DoSAM metho may alo be ue for a ingle architecture review. Compare to other metho, the aitional invetment in the reference framework lea to aitional cot, however. Thi weakne turn into trength when the architecture i evaluate more than once, e.g. to upport an iterative eign proce. Furthermore, the creation of the reference comparion framework uually bring aitional clarity, a it force the aeor to think about the ervice an quality attribute neceary for the application omain. The ret of the paper i tructure a follow: Firt, in Section 2 we hortly outline the tate of the art with repect to oftware architecture evaluation metho. Then, in Section 3 we give an overview over the propoe approach for a omain-pecific oftware architecture comparion moel. In Section 4 we preent a ample application of DoSAM. Section 5 how a part of the comparion framework for a pecific quality attribute. A concluion i given at the en of the paper in Section 6.

3 2 Relate Work Although commonly accepte in it importance for cot an quality of oftware ytem, the methoic aement of oftware architecture i a rather young icipline. Mot approache rely on acaemic work preente in [1]: SAAM - Software Architecture Analyi Metho - Aement of oftware architecture i one via cenario, quality attribute an quality objective. Scenario provie an unertaning of typical ituation the architecture mut cope with. Quality attribute an quality objective efine the apect of interet. During the proce of aement, the architectural approache at han are ientifie an evaluate with repect to the ientifie objective. A a reult, each architectural eciion i aociate with one or more rik to inicate problem area. ATAM Architecture Traeoff Analyi Metho - In comparion to SAAM, thi approach concentrate on fining crucial traeoff-eciion an trie to etect the rik involve. Therefore, ATAM reult in a goo unertaning of the pro an con of each traeoff an the implication of alternative olution in the context of a given overall architecture. CBAM Cot-Benefit Analyi Metho - The CBAM metho [10] enhance ATAM by quantification of the economic benefit an cot of architectural eciion. ALMA Architecture-Level Moifiability Analyi - Compare to the other approache, the ALMA metho [11] ha it focu on aaptation an moification cenario for a given architecture an hence take a pecial interet in the correponing ubet of quality attribute. ARID Active Review for Intermeiate Deign - With a focu on the architecture of ubytem, thi lightweight evaluation approach provie a proceure for the early phae of architectural eign. The propoe technique i that of eign review a imple an effective, but rather ubjective metho. SACAM Software Architecture Comparion Analyi Metho - Thi recently propoe metho allow for comparion of a et of oftware architecture poibly of quite ifferent application omain (cf. [8]). From a company buine goal, the relevant quality criteria are erive an ecribe by mean of cenario (imilar to ATAM). Bae on preefine metric an architecture view, the evaluator look for inicator to core each architecture with repect to the criteria. The DoSAM metho preente in thi paper i bae on imilar bae concept, like cenario an quality attribute. However, in aition, it bring in ome new apect: Apart from SACAM, none of the preente approache allow for the comparion of everal architecture of the ame application omain. The evaluation proceure i highly tailore to the pecific of the architecture uner conieration an epen on the peron performing the evaluation. DoSAM trive for a more objective evaluation which can be repeate a requirement change over time. Like SACAM, the preparation of the comparion framework only nee to be one once for a certain application omain. Once the comparion framework ha been aapte, it can be eaily reue for aitional architecture or for re-evaluation after moification of exiting one.

4 In the proce of a SACAM evaluation, the evaluator trie to fin a common level of abtraction for comparion by ientifying a number of common view. Thi may be quite ifficult, epecially when comparing completely ifferent architecture. DoSAM intea retrict itelf to the comparion of architecture in the ame application omain bae on a common architecture blueprint. Thi blueprint erve a a conceptual framework, proviing guiance for the aeor an implifying the comparion proce. Furthermore, DoSAM introuce architectural ervice a a mean of ecribing the baic functionality an purpoe of the application omain in an abtract way. Compare to application cenario, which are often very pecific an may change over the lifetime of the architecture, architectural ervice provie a more high-level an table view. Conceptually, ervice are roughly imilar to SACAM view type, a they etermine which architectural apect are aee. However, in contrat to SACAM view type, ervice are motivate by the application omain an not by technical iue foun in the architectural ocumentation (e.g. component epenency an complexity metric, a mentione a example by SACAM). To um up, nowaay mot architecture evaluation focu on the evaluation of a ingle architecture, not on the repeatable an tanarize comparion of ifferent architectural olution. The only exception known to u i the SACAM metho. Compare to it, DoSAM provie aitional guiance, tructure an tability ue to the explicit conieration of a given application omain. 3 Domain-Specific Software Architecture Comparion Moel The DoSAM approach upport the evaluation an comparion of ifferent architectural olution within a given omain. Once a omain architecture comparion framework (DACF) ha been create by an expert for a certain application omain, the concrete architecture evaluation (CAE) of the architecture in thi omain can be performe following a tanarize an repeatable proce. The tructure of the DACF i hown in Fig. 1. Each of the inner boxe repreent an intermeiate reult to be elaborate uring the elaboration of the DACF.

5 Fig. 1. Domain Architecture Comparion Framework (DACF) A can be een, the framework conit of three main part: 1. What i evaluate? - The omain architecture blueprint an the architectural ervice together form an abtract ecription chema for all architecture in the application omain. The intention here i to fin contituent of the architecture that are inherent to the application omain at han, an therefore inevitably repreente in all imaginable olution. Thereby, it i crucial to fin the right level of abtraction: it mut not be too etaile to be able to form a repreentative blueprint for the omain but it mut not be to abtract to be able to reaon about the relevant architectural propertie. Hence a omain pecialit i neee to etermine the proper architecture blueprint. Thereby, prevalent architectural tyle an pattern in a given omain have to be taken into account (cf. [12]). An example for an abtract architecture ervice woul be the ata tranfer ervice of a network-centric ytem, mae up by a certain number of harware an oftware component in a pecific architecture. 2. How i it evaluate? The relevant quality attribute an the correponing quality attribute metric (one for each quality attribute) tate in which repect the architecture are aee an how the aement of thee criteria i performe. An example for a quality attribute woul be the availability, which coul be meaure by quality attribute metric like the mean time to failure (MTTF) in a certain cenario. 3. What i important? Finally, the quality computation weight in the mile of the figure mut be provie to tate the relative importance of each application of a quality attribute metric on an architectural ervice. For example, the aeor might ecie that the availability of the ata tranfer ervice i very important in a certain application omain, at leat in relation to the availability of other architecture ervice. The poibility of ajuting the architectural ervice an the quality attribute, a well a the metric an weight, make the creation an fine-tuning of a DACF a challenging tak. However, when thi tak ha been performe well, the reulting DACF can be intuitive an unertanable even for peron with no eeper architectural

6 knowlege. At a high level, the DACF might capture tatement like that military ytem rely heavily on the availability, afety an ecurity of communication ervice, wherea buine ytem might emphaize the performance of their tranaction an torage ervice, for example. A alreay tate, the creation of the DACF ha to be performe only once for each application omain. Note that the moular tructure of the DACF make it poible to a new quality attribute an/or architecture ervice to the framework without breaking the exiting framework. Fig. 2. DoSAM Application: DACF Creation an Concrete Architecture Evaluation (CAE) After the creation of the DACF (hown in the upper part of Fig. 2) it can be applie to evaluate an compare the concrete architecture. Thi i a three-tep proce, which cloely correpon to the three main part of the DACF hown in Fig. 1. It conit of the three following activitie, which are performe for each concrete architecture to be evaluate: 1. Relate to Blueprint & Ientify Service: The concrete architecture i relate to the architectural blueprint of the application omain, yieling the et of all harware an oftware component an their connection that are relevant for the ubequent tep. Thi may reult in one or more highlevel architecture overview iagram of the whole ytem. Bae on that, the component involve in the realization of the ientifie architectural ervice are ientifie. For the ata tranfer ervice of a buine tranac-

7 tion ytem, thi may, for example, reult in harware an oftware component like router, firewall, protocol tack an caching oftware. 2. Apply Quality Attribute Metric: The concrete ervice implementation of the evaluate architecture i examine an aee with repect to the ientifie quality attribute of the application omain. Thi i one by employing the quality attribute metric. Each of thee metric yiel a ingle evaluation reult on a normalize cale from 0 to 100. The ata tranfer ervice coul, for example, be evaluate with repect to performance by aeing the combination of average throughput an average repone time. A etaile example for the moifiability quality attribute metric i given in Section Apply Quality Computation Technique: When all architecture ervice have been aee with repect to all quality attribute, the evaluation reult may be entere into the weighte quality computation matrix. Again, thi lea to a ingle, normalize evaluation reult, characterizing the fitne of the architecture compare to other architecture an proviing a hint for it abolute value with repect to the criteria capture within the DACF. Provie that a well-eigne DACF ha been elaborate, the egree of freeom in performing the concrete architecture evaluation (CAE) will be rather low, enuring a fair, repeatable evaluation of all architecture. Thi alo mean that a CAE can alo be performe by people who are not highly-kille application omain or architecture expert. Furthermore, if the application of the quality attribute metric i upporte by tool, the effort an time neee to perform a CAE can be kept very low. 4 Sample Application Domain The following ection will briefly emontrate the preente aement proce for the omain of IT architecture for moern naval craft. We have choen thi application omain becaue DoSAM ha been eigne for a navy relate tuy in the firt place [9], but alo becaue of the intereting architectural challenge involve: Compare to the clear, hitoric eparation of utie for the ifferent kin of military hip, moern time eman highly flexible craft that can eaily be moifie to fit requirement of variou miion cenario (e.g. clearance of mine, evacuation, etc.) Cooperation with unit of ifferent, international armie teaily grow in importance an o oe the ability of interaction an communication. Conequently, quality attribute like moularity, flexibility, an extenibility are of growing importance for the ytem architecture of moern military craft. The choen ample application omain i that of moular hip with the following unertaning of moularity:

8 All hip ue a common, baic architecture which can be enhance an pecialize for all ifferent kin of craft. Thi iea of a hare infratructure platform reult in a rather high egree of reue an hence reuce the cot for evelopment, prouction, maintenance an eucation. A ingle hip can be equippe for a couple of ifferent eployment cenario, which i one either in the hipyar or in the fiel. That i, eparate moule may be intalle, each aing new feature an ervice. Single moule can be tanarize an tanar COTS (commercial offthe-helf) component can be ue within the hip to further reuce evelopment an maintenance cot. To cope with the complexity of thi moular approach, the eman on the quality of the unerlying oftware an harware infratructure platform are very high. It architecture i ubject to aement in the following chapter. 5 DoSAM Applie Thi ection offer a concrete example of the application of DoSAM a ecribe in Section 3 in the ample application omain preente in Section 4. The preentation follow the three main area of the DACF a hown in Fig. 1 a well a their application uring the CAE a hown in Fig. 2. Firt, in Section 5.1 an 5.2 the omain architecture blueprint an the correponing architecture ervice are ecribe, repectively. In the following, the relevant quality attribute are ecribe in Section 5.2, an an example for a etaile quality attribute metric i given in Section 5.3. Finally, the quality computation technique an it application are hown in Section Domain Architecture Blueprint In orer to evaluate architecture uing the DACF evaluation moel, it i neceary to create an architecture blueprint that how a high level of univerality. A alreay mentione in Section 3, uch a blueprint mut not be too etaile to repreent all concrete omain architecture implementation an to upport the mapping to real ytem architecture without contraining them. But the blueprint mut not be to abtract, otherwie it will not be powerful enough to reaon about the relevant architectural propertie. It i not an eay tak to fin uch a blueprint, but extenive uage of the knowlege of omain pecialit will lea to goo reult. During evelopment, univerality of the blueprint mut be kept in min. In our ample application omain ecribe in the previou ection, a component bae tyle eem to be a reaonable choice. Obviouly, in other omain, other tyle may be more appropriate. For example, one woul expect pipe an filter in a ignal proceing application or, if applicable, the architecture might be oriente on event trigger [12].

9 Fig. 3 how a omain architecture blueprint for the ample application omain ecribe in the previou ection. A tate above, thi blueprint follow an architectural tyle bae on component. Obviouly, thi central platform conit of both harware an oftware. Software can be plit up into application oftware an bae oftware. Since we want to ae only the fitne of the bae platform, the application-pecific oftware i not evaluate, viualize by the grey an white boxe in Fig. 3. Here, grey boxe repreent component of the central platform, wherea white boxe how application-pecific oftware an harware that relie on it. Bae oftware an harware are each ubivie into four categorie: Aapter erve a interface for enor an effector an their oftware. Example in the harware omain are network aapter an harware interface for enor an effector. In the oftware omain, generic evice river fall into thi category. Worktation harware (coniting of CPU, main memory, ata torage ubytem etc.) an oftware (e.g. operating ytem, communication oftware, mail client etc.) Server harware an oftware, imilar to their worktation counterpart. Network infratructure coniting of witche, router, firewall (both harware an oftware) an the network cable. Fig. 3. Domain Architecture Blueprint for the Bae Platform a part of the DACF The categorie epicte by grey boxe efine the cope of the ubequent evaluation: During the aement of the architectural ervice within the CAE, only component falling into one of thee categorie may be coniere.

10 Fig. 4. Sample Part of an Architecture Overview Diagram create uring CAE To relate the concrete architecture to the blueprint architecture, one or more architecture overview iagram may be create. A imple repreentation coul look a hown in Fig. 4, with oftware component hown a boxe with a ahe borer an harware component a boxe with a oli borer. Alternatively, UML ecription technique like eployment or component iagram coul alo be ue, a far a they can viualize the component categorie of the blueprint architecture. 5.2 Architectural Service The central platform i proviing variou ervice for the application running on the hip. The following architecture ervice have been ientifie a crucial for the evaluation of ifferent architectural olution: Data tranfer ervice: Achieve the tranfer of heterogeneou ata between ifferent application an harware moule with naval, military an civil application. The ata tranfer ervice mut provie an infratructure for multimeia meage like vieo/peech, real-time ata rea in by enor, an application meage between ifferent application ervice. Data torage ervice: Achieve the peritent torage for real-time, multimeia, an application ata a well a for arbitrary ocument. Proceing ervice: CPU power mut be upplie for computationally expenive tak. Thi applie to both interactive an batch program. Sytem management ervice: Monitoring, aminitration an maintenance of the platform an it component mut be achieve. Authentication/authorization ervice: Carrie out the ientification, authentication an authorization of uer, application an component.

11 Preentation ervice: Achieve the preentation of GUI an output on en evice like creen, printer etc. Thee application-pecific architecture ervice ecompoe the functionality of the unerlying ytem into eparate area that can be evaluate inepenently. Note that in orer to ae each ervice for a given architecture uring the CAE, it mut be poible to ientify the component that contitute it implementation. Thi may be one by marking the component on the architecture overview iagram, thu builing a erie of cut-out view from the overall architecture. Compare to the full architecture, the complexity of uch an architecture ervice view will uually be greatly reuce, thu implifying the evaluation of the ervice. Very imple example for architectural ervice cut-out view taken from Fig. 4 coul range from all component (for the remote ata torage ervice, in which all component might participate) to jut the ellpc worktation harware an oftware (for the preentation ervice, which coul employ thee worktation a terminal for other computer without creen). 5.3 Relevant Quality Attribute Quality attribute like thoe foun in the IEEE tanar for quality attribute [7] efine criteria for a certain capability area of the architecture. In a military environment, epecially on a hip, the following quality attribute play an important role in the fulfillment of it purpoe. Availability evaluate the capability of the architecture to provie continuou functionality. It i efine a the relative amount of time the ytem functionality i acceible. Sytem break own an malfunction have a negative effect on availability. Performance i influence by parameter like throughput an repone time. It meaure how fat the architecture i an how many uer can ue it imultaneouly. Uability characterize the operability of the ytem. The uer interface mut provie fat upport of routine procee on the hip. The architecture efine the framework to be ue by application in orer to provie a uer-frienly interface. Safety an Security a quality attribute evaluate the poibility of input error an unwante effect (afety) an the egree of protection againt intene an unintene attack (ecurity). Moifiability efine the egree to which the architecture i configurable an extenible. Thi quality attribute inclue apect like eveloper frienline, unertanability an moularity. It ha a crucial influence on the effort an cot for neceary change. Functionality valuate the completene of the functionality an feature provie for application epening on the platform. The ecription above tay at a very abtract level, of coure. In orer to be ueful for a concrete evaluation, there mut be unambiguou operational proceure that can

12 be applie in a repeatable way. During the creation of the DACF, we have evie a number of uch proceure. A all of them yiel a reult a ingle number normalize by a cale from 0 to 100, we have calle them quality attribute metric. The following ection give an example. 5.4 Sample Quality Attribute Metric Moifiability A an example for the evaluation proceure of a particular quality attribute, our quality attribute metric for the moifiability quality attribute i ecribe in the following. In the cenario ecribe in Section 4, moifiability i a central apect of the intene moularity of the hip. The following requirement have to be regare in the evaluation of the architecture: The quality of the moular hip mut not be egrae ue to the change. Preparation an realization of the moification mut be one in a little time a poible. The cot for preparation an realization of a change mut be a low a poible. In ummary, the apect quality, time, an cot enable an evaluation of moifiability of a moular hip. Time an cot can be etermine an compare for ifferent cenario, but the reulting quality i not quantifiable a eaily. In the following context, we aume that metho guaranteeing quality aurance like regreion tet are ue. Thi inuce the aumption that the quality i not worene by potential change in the following context. Concerning moifiability, the following type of change can be ientifie: CS: Change of olution: A change reulting from an alteration of the technical etup without any change in functionality that coul be perceive by the uer. The technical olution only efine how the ytem work. CF: Change of functionality: A change of functionality implie a change of any abilitie of the ytem etermining what the ytem oe. Thi can inclue a change of olution, too. The ifferent change type (CS, CF) can be realize by the following change realization type: CC: Change by configuration: The configuration parameter are the only part of a component that unerlie a change. Thi uually nee the leat realization time. CI: Change by intallation an eintallation: New component are integrate into the moular hip or remove, repectively. In orer to be ubject to a CI, the particular component an it moule mut alreay be known an well pecifie. Otherwie, thi coul lea to a ecreae quality. CD: Change by evelopment: The implementation of a component i change or totally renewe. A mentione before, quality aurance metho have to be applie in orer to prevent a ecreaing quality ue to newly implemente component.

13 Uually, a change by evelopment irectly implie a change by intallation an eintallation, wherea a CI uually contain a change by configuration. Total cot Aitional cot Peron affecte Total change effort in MD Average integration an tet effort in MD Depenent architecture component Average changing effort in MD Amount of architecture component to be change Change realization type Service involve Frequency of change Changing cenario CS: Change of olution: Scenario 1 0,25 / Data torage CD ,000 Change of DBMS Year Reaon/etail: A change i retricte to the ata torage ervice. It can only be achieve by programming. For a change of the DBMS, e.g. from Oracle to MySQL, the component Miion- App ha to be reviite. CF: Change of functionality: Scenario 2 1 / Year Data torage CD ,000 Integration of a Proceing ifferent Miion Sytem Mgmt. Databae Preentation Authorization Reaon/etail: A change involve all ervice except the ata tranfer ervice. It can only be achieve by programming. The integration of alreay exiting Oracle atabae originating from other application nee an enhancement of the atabae chema an the original atabae ha to be aapte. The component Oracle 10i i irectly involve. Table 1: Exemplary Evaluation Table for Moifiability In orer to enable an evaluation of moifiability, ifferent changing cenario have to be ientifie firt. Thee cenario are written own in an evaluation table (ee Table 1). Ientifying thee cenario i part of ajuting the DACF an mut therefore only be one once. During architecture evaluation an comparion, for each architecture the change realization type of all cenario ha to be etermine. Aitionally, the following apect are written own: the amount of architecture component that are touche by the change, the amount of epenent architecture component, the average effort for integration an teting, an for the change itelf. Furthermore, the number of affecte peron i note an the aitional are etermine. When evaluating a concrete architecture, thee value are ue to calculate the architecture pecific cot to realize cenario. The calculation rule i explaine below. Every architecture i evaluate uing the ame cenario. For each cenario, the total change effort TChEff in man ay (MD) i etermine uing the following equation: TChEff ( ACCh + ACDep ) AITEff = ACCh ChEff +, where ACCh are the average component to be change, ChEff i the average change effort for a component change, ACDep are the epenent architecture component, an AITEff i the average integration an teting effort. All thee value are taken from the evaluation table exemplarily hown in Table 1. (1)

14 The total cot TC are etermine uing the following equation, where a MD i exemplarily et to a tanar value like 1200 Euro. Being note in the lat column of Table 1, TC repreent the architecture pecific cot to realize cenario : ( CRT TChEff ( PA + ) C ) TC = Frq , (2) where Frq i the aume frequency of a change, CRT i the change realization type, PA are the peron affecte, an C are the aitional cot in thi cenario. The ifferent change realization type each inuce ifferent factor value: Change realization type CC: CRT = 1 Change realization type CI: CRT = 2 Change realization type CD: CRT = 3 During architecture evaluation, not only potential change an their cot are of interet. Unertanability an applicability of the architecture itelf have an influence on the quality of it moifiability, too. Thi hol true epecially in a omain like a moular hip, where it i an important requirement that application component are exchangeable with low effort. In orer to repect thi, the architecture ha to be evaluate regaring thi apect, too. Thi happen by etermination of an architecture unertanability an applicability factor AUAF for each architecture ervice : AUAF where IQF i the interface quality factor an efine by the following table. = IQF UF, (3) IQF UF i the unertanability factor UF Stanar interface 1 1 Fully pecifie interface 2 UFF Informally pecifie interface 4 UFF Table 2: Definition of interface quality factor an unertanability factor Table 2 how the factor value for the three poible interface type of an architecture ervice: tanar interface, fully pecifie interface, an informally pecifie interface. It i aume that there exit no unpecifie interface. The unertanability factor formula UFF i efine by: UFF PAF M PTF m m m M =, where M i the et of parameter involve an M i it carinality. The parameter amount factor PAF ha the value 1, if the amount of parameter in the metho m m (4)

15 ha le than 10 parameter, otherwie it ha the value 2. factor being etermine by the following rule: Parameter type i a primitive ata type: PTF = 1 Parameter type i a complex ata type: PTF = 2 m m PTF i the parameter type m Parameter type i a complex ata type with pointer: PTF = 4 Parameter type i not efine: PTF = 16 An AUAF value of 1 inicate the bet value that can be achieve. After having etermine the cot for each change cenario an the AUAF for all architecture ervice, the intene metric value of the moifiability ervice can be etermine by: Mo TC + TC S =101 AUAF, TC m m Mo of an architecture where TC are the total project cot. The moifiability of a particular architecture ervice therefore i etermine by the application unertanability an applicability factor an the cot reulting from all changing cenario that have been thought of uring the evelopment of the omain architecture comparion framework. Thi value i et in relation to the total project cot an then normalize to a maximum value of 100. A negative value i interprete a 0. (5) 5.5 Quality Computation Weight an Quality Computation Technique The quality computation technique i bae on a two-imenional matrix with the architecture ervice in it row an the quality attribute in it column. For every combination of quality attribute an architecture ervice, the DACF provie a quality attribute metric yieling a metric percentage value normalize to the range from 0 to 100 (uually, the ame quality attribute metric will be ue for all architecture ervice alike, although thi i not trictly neceary). In Table 3, thee value can be foun in the Value column. A can be een in the example, the availability of the ata tranfer ervice ha reache a high evaluation reult of 97%, inicating the high fitne of the architecture with repect to thi apect. In orer to aapt the evaluation proce to the requirement of the application omain, the DACF creator ha to weight the relative importance of the quality attribute a well a the contribution of each architecture ervice to each quality attribute (QA). Thee weight are part of the DACF an mut therefore be ue for all CAE alike without change. In Table 3, the quality attribute weight can be foun in the white cell in the Total QA row, an the architecture ervice weight can be foun in the Weight column. A an example, the availability ha been rate a more important compare to the moifiability (at a rate of 60 to 40). Furthermore, all ervice have been eeme equally important for the evaluation of the availability with the ingle

16 exception of the ytem management ervice, which in the example ha no relevance for the availability altogether. Note that only the cell with a white backgroun can be et by the uer all other content are provie automatically by the DoSAM quality computation technique. Thi pertain to the weighte point in the Point column a well a to all Sum an Total. The um characterize the relative fitne of the QA an ervice. In the example, the architecture reache a core of 68% with repect to the availability QA, an of 71,30% with repect to the moifiability QA, while it total weighte core i 69,32%. Thi en reult number can now be compare with the repective en reult for other architecture, allowing to rate the architecture againt each other. Table 3: Exemplary Evaluation Matrix for Two Quality Attribute Another benefit of the two-imenional evaluation matrix i that an architecture may not only be aee with repect to it QA, but alo with repect to it architecture ervice. To allow for thi, the matrix firt compute architecture ervice weight (column Weight Service) an weighte ervice um inicating the total fitne of the architecture ervice (column Sum Service). In the example, the relative importance of the ata tranfer ervice evaluation i 24%, wherea the ytem management ervice reache only 2%, ue to the low weight of 0% an 5% in the correponing Weight column. Furthermore, the core of the ytem management of 19% i coincientally alo much lower than the core of the ata tranfer ervice of 81%. The Sum QA row an the Sum Service column together form a powerful analyi tool for the architect. Not only oe he ee how goo the architecture come out with repect to the quality attribute, but he can alo trace thi back to hi eign eciion for ingle architecture ervice. In the example, it coul have been a wie eciion to put no emphai on the ytem management ervice, a it oen t contribute much to the overall fitne of the ytem. 6 Concluion In the paper, we have preente the DoSAM metho for evaluating an comparing ifferent architecture in a certain application omain. We have motivate the neceity for a new approach by comparing it to other architecture evaluation metho. Our overview of DoSAM coul of coure not capture all etail of the metho. Therefore, we have retricte ourelve to a urvey of the metho bae principle an a hort preentation of ome key reult from an example application, namely, the

17 evaluation of IT application platform for moular naval craft. The actual, complete application example i much bigger among other, it contain elaborate quality attribute metric for all ientifie QA, not only for the moifiability QA. Our preent experience with DoSAM up to now i encouraging: It eem to be a generally applicable an very flexible metho uitable for all kin of architecture. For the future, we plan to further elaborate an refine the DoSAM metho bae on aitional evaluation experience. To o thi, we will evie new or refine quality attribute metric for the exiting an for new QA. In the following, better tool upport for thee QA metric may then be evelope in orer to lower the time an effort neceary for concrete architecture evaluation. A long-term objective woul be the eign an implementation of a toolkit for rapily builing omain-pecific architecture comparion framework bae on exiting quality attribute metric. Reference 1. P. Clement, R. Kazman, M. Klein: Evaluating Software Architecture, Metho an Cae Stuie, SEI Serie in Software Engineering, R. Harrion, Maintenance Giant Sleep Uniturbe in Feeral Data Center, Computerworl, March 9, B.P. Lientz an E.B. Swanon. Software Maintenance Management, Reaing, MA: Aion- Weley N. Laing, P. Bengton, H. van Vliet an J. Boch. Experience with SAA of Moifiability, May P. Bengton, J. Boch, Architecture Level Preiction of Software Maintenance, The 3r European Conference on Software Maintenance an Reengineering (CSMR'99), pp , L. Ba, P. Clement, R. Kazman, K. Ba. Software Architecture in Practice (Sei Serie in Software Engineering). Aion-Weley Publihing IEEE St , IEEE Stanar for a Software Quality Metric Methoology C. Stoermer, F. Bachmann, C. Verhoef, SACAM: The Software Architecture Comparion Analyi Metho, Technical Report, CMU/SEI-2003-TR-006, K. Bergner, A. Rauch, M. Sihling, Verfahren zur Bewertung von DV-Architekturen für a moulare Schiff, 4Soft Cutomer Stuy, J. Auni, R. Kazman, M. Klein, Uing Economic Conieration to Chooe Among Architecture Deign Alternative, Technical Report, CMU/SEI-2001-TR-035, P. Bengton, N. Laing, J. Boch, H. van Vliet, Architecture-Level Moifiability Analyi (ALMA), Journal of Sytem an Software, Volume 69, Iue 1-2, F. Buchmann, R. Meunier, H. Rohnert, P. Sommerla, M. Stal, A Sytem of Pattern, John Wiley&Son, 1996.