Concerning Predictability in Dependable Componentbased Systems: Classification of Quality Attributes

Transcription

1 Concernng Predctablty n Dependable Componentbased Systems: Classfcaton of Qualty Attrbutes Ivca Crnovc 1, Magnus Larsson 2 1 Mälardalen Unversty, Department of Computer Scence and Engneerng Box 883, Västerås, Sweden vca.crnovc@mdh.se 2 ABB Corporate Research, Västerås, Sweden magnus.larsson@mdh.se Abstract. One of the man objectves of developng component-based software systems s to enable buldng systems by ntegraton of components whch are perceved as blac boxes. Whle the constructon part of the ntegraton usng component nterfaces s a standard part of all component models, the predcton of the qualty attrbutes of the component compostons s not fully developed. Ths decreases sgnfcantly the value of the component-based approach to buldng dependable systems. When t s not possble to predct the value of a partcular attrbute of a system on the bass of the specfcatons of the system components, the system must be subjected to other procedures, often costly, to determne ths value emprcally. However, all qualty attrbutes do not have the same characterstcs; nor s t possble to predct the behavor of all the propertes of a composton from the propertes of the components. Ths paper classfes dfferent types of relatons between the qualty attrbutes of components and those of ther compostons. The types of relatons are classfed accordng to the possblty of predctng the propertes of compostons from the propertes of the components and accordng to the mpacts of other factors such as system envronment or software archtecture. Such a classfcaton can ndcate the efforts whch would be requred to predct the system attrbutes that are essental for system dependablty and n ths way, the feasblty of the component-based approach n developng dependable systems. 1 Introducton Component-based development (CBD) s of great nterest to the software engneerng communty and has acheved consderable success n many engneerng domans. CBD, has been extensvely used for several years n destop envronments, offce applcatons, e-busness and n general n Internet- and web-based dstrbuted applcatons. The component technologes (for example COM/DCOM, CORBA, EJB and.net) used n these domans orgnate from object-orented (OO) technques. The basc prncples of the OO approach, such as encapsulaton and class specfcaton

2 have been further extended; the mportance of component nterfaces has ncreased; a component nterface s treated as a component specfcaton and the component mplementaton s treated as a blac box. A component nterface s also the means of ntegratng the component n an assembly. Component technologes nclude the support of component deployment nto a system through the component nterface. On the other hand, the management of components qualty attrbutes has not been supported by these technologes. In the domans n whch these technologes are wdely used, the qualty attrbutes have not been of prmary nterest and have not been explctly addressed n the component technologes, they have nstead been treated separately from the appled component-based technologes. Component-based approach s a large extend related to software archtecture. A use of a component-based technology helps n avodng of an archtectural msmatch by standardzng certan archtectural decsons. A software component model specfes rules for component composton and nteroperaton and n ths way smplfes the development process and smlar to software archtecture maes t possble to reason about qualty propertes to large extent ndependently of a partcular applcaton. The man dfference between a component-based approach and software archtectureorented approach s the focus on reusablty of already exstng components vs. topdown approach for dentfyng the components. In many other domans, for example dependable systems, CBD s utlzed to a lesser degree for a number of dfferent reasons. One s the dffculty of mplementng the same component technologes n dfferent domans because of dfferent system constrants. Another reason s the unclear dstncton between system components whch nclude both hardware and software parts and software components whch may be encapsulated n system components or dstrbuted through several system components (n ths artcle when we refer to components we assume software components ). Fnally an mportant reason s the nablty of component-based technologes to deal wth qualty attrbutes as requred n these domans. For dependable systems, a number of qualty attrbutes are at least as mportant as the functons they provde, and the development efforts related to them are most often greater than the efforts related to the mplementaton of partcular functons. If the advantages of componentbased technologes are lmted to the functonal doman only and cannot be utlzed n the doman of qualty attrbutes, or, even worse, ntroduce dffcultes n the management of qualty attrbutes, these technologes cannot be successfully utlzed n the development of dependable systems. Some of the man advantages of CBD are reusablty, hgher abstracton level and separaton of the system development process from the component development process. These advantages have however mplcatons related to other aspects of software and system development. The fnal success of the utlzaton of CBD depends not only on ts advantages but also on these mplcatons the degree to whch they are postve and negatve. Snce for dependable systems, partcular qualty attrbutes are of the greatest mportance, a queston whch arses s to what extent does CBD nfluence the achevement of these propertes: CBD can ntroduce new dffcultes, t can be rrelevant for those propertes, or can have a postve effect. For ths reason t s of nterest to analyze the ablty of CBD to cope wth requrements related to qualty attrbutes.

3 Component-based software engneerng (CBSE) faces two types of problems n dealng wth qualty attrbutes. The frst, common to all software development, s the fact that the qualty attrbutes are often mprecsely defned or very dffcult to measure. The second, specfc to component-based systems, s the dffculty of relatng system propertes to component propertes. In CBD one requrement s that components should be selected and ntegrated n an automatc and effcent way. Ths goal s acheved for the functonal part; components are selected and ntegrated through ther nterfaces. The queston s f a smlar approach can be appled to qualty attrbutes. For component-based systems crucal questons n relaton to qualty attrbutes are the followng: Gven the system qualty attrbutes requred, whch propertes are requred of the components concerned? Gven a set of component propertes, whch system propertes are predctable? How can the qualty attrbutes of a system be accurately predcted, from the qualty attrbutes of components whch are determned wth a certan accuracy. To whch extent, and under whch constrants are the emergng system propertes (.e. the system propertes non-exstent on the component level) determned by the component propertes? These and smlar questons have been addressed at a seres of CBSE worshops [1], and partcular models of certan propertes have been analyzed [2,3], but so far very lttle wor has been done n the systematzaton and classfcaton of qualty attrbutes n accordance wth the questons above. Although there are other classfcatons of qualty attrbutes such as [4-7], these have not consdered the predctablty aspect of the qualty attrbutes. Some system propertes can be derved drectly from the component propertes; others mght requre a complex model, related to the component model and the system archtecture. Some system propertes, such as safety, do not exst on the component level and mght be the result of a complex combnaton of the system nteracton wth ts envronment, system archtecture and component model. In ths paper, our ntenton s to demonstrate the dversty of qualty attrbutes and the dfferent methodologes whch can be used for predctng system behavor from the propertes of the components nvolved. These propertes can be classfed accordng to the ablty of component-based technologes to specfy them and provde methods for expressng ther compostons,.e. the ablty to predct the propertes of component assembles. Such a classfcaton ndcates the feasblty of the componentbased approach for buldng dependable systems. The paper s organzed as follows: Secton 2 dentfes the types of propertes accordng to the prncples for predctng the propertes of component assembles. Secton 3 dscusses the possblty of defnng component composton n a recursve way. Secton 4 provdes a lst of many qualty attrbutes and classfes them accordng to the compostonal prncples dscussed n the prevous sectons. Fnally, secton 5 exemplfes the reasonng by showng qualty attrbutes for safety-crtcal systems.

4 2 Classfcaton of Propertes A great number of qualty attrbutes are encountered n Software engneerng. They are classfed n many dfferent ways, frequently n a non-orthogonal manner. One example of classfcaton s related to the system lfe cycle: Run-tme propertes (vsble and measurable durng the program executon) and lfe-cycle propertes (those that characterze dfferent phases n a development and mantenance process). The classfcaton we consder here s related to composablty. We classfy propertes accordng to the prncples appled n dervng the system propertes from the propertes of the components nvolved. Instead of the term system, we shall use a generc term Assembly (A) whch smply denotes a set of nteractng components. Such an assembly can be a part of a software system (for example a functonal unt, or a subsystem), or the entre system. The only characterstc we want to relate to an assembly s a set of ntegrated components. Some propertes, however, cannot be related only to an assembly, but are explctly related to the entre system and ts nteracton wth the envronment. In such cases we refer to a System (S). Accordng to composton prncples we can dstngush the followng types of propertes: a. Drectly composable propertes. A property of an assembly whch s a functon of, and only of the same property of the components nvolved. b. Archtecture-related propertes. A property of an assembly whch s a functon of the same property of the components and of the software archtecture. c. Derved propertes. A property of an assembly whch depends on several dfferent propertes of the components. d. Usage-depended propertes. A property of an assembly whch s determned by ts usage profle. e. System envronment context propertes. A property whch s determned by other propertes and by the state of the system envronment. Let us dscuss these cases and gve examples n the followng subsectons. a. Drectly composable propertes Defnton: A drectly composable property of an assembly s a functon of, and only of the same property of the components. P = property, A = assembly, c = component A = { c } P( A) = f ( P( c )); N Note that the property of the assembly s the same as the component property. Further, the component technology s not explctly specfed n the relaton (1). However (1)

5 t s obvous that the functon f tself s dependent on the technology snce the mechansms to assemble components s provded by the component technology. An example of a property of ths type s the statc memory sze of a component or an assembly, ths s also nown as the memory footprnt. The smplest composton model s the calculaton of the statc memory of an assembly as the sum of the memores used by each component: n M ( A) = M ( c ) = 1 M = memory sze, A = assembly, c = components The functon M(c ) s dfferent for dfferent technologes. For example n the case of the separaton of composton tme from run-tme whch s usually used n embedded systems, M(c ) wll be a constant, possbly parameterzed by confguraton factors. In such cases the statc memory sze of an assembly wll be a constant. A more complcated model can be found n the Koala component model [8], n whch addtonal parameters, such as sze of glue code, nterface parameterzaton and dversty are taen nto account (.e. the parameters determned by the component technology used). The equaton (2) s also vald for a dynamc memory, wth the dfference that M(c ) s not a constant, but a functon whch may depend on the usage profle. When usng a partcular technology, ths functon may be lmted or budgeted. In such a case the total amount of memory can be calculated. n = 1 (2) M ( A) M max ( ) (3) The propertes of ths type can be calculated drectly from the component propertes and the partcular technology. There are no other assumptons and therefore these propertes are the easest to specfy and calculate. Ths does not mean that the composton functons are easy or even possble to express formally. However the fact that the property s vsble on component and assembly level, and that the assembly property s dependent only on the component propertes smplfes the predcton procedure. Ths s vald ether for measurements or for dentfyng restrctons whch wll mae t possble to reason about the composton. c b. Archtecture-related Propertes Defnton: An archtecture-related property of an assembly s a functon of the same property of the components and of the software archtecture. SA = software archtectureture, x = connectons P( A) = f ( P( c ), SA( c, x ));, N (4)

6 In ths case the assembly propertes depend not only on the component propertes but on the archtectural structure. The software archtecture s often used as a means for mprovng partcular propertes wthout changng the component propertes. These types of propertes can be tuned by dfferent archtectural solutons or varatons. An example of such a property s a performance predctablty model for J2EE (Java 2 Platform, Enterprse Edton) applcaton. A typcal applcaton mplemented n ths technology would be a dstrbuted web-based applcaton n whch the varablty n scalablty s acheved by t beng possble to add new clents and new computatonal (busness) components to the server as llustrated n Fgure 1. To acheve concurrency the components are executed n dfferent threads. A possble extenson varaton of ths archtecture s the possblty to nclude several nodes wth web servers and busness applcatons. The performance of the system shown n the Fgure 1 s related to the number of clents and the number of server components. A typcal requrement for such applcatons s the performance and scalablty,.e. the dependences between the performance and number of clents and actve busness components. Clent ter Web server ter Busness logc ter Data ter Web server Data access components Data Busness components Varablty ponts Fg. 1. A typcal mult-ter archtecture wth clent and servers varablty ponts affectng the performance qualty attrbute Accordng to [9,10] the tme per transacton T/N expressed n (5) depends on several factors related to the system archtecture: The frst factor comes from the concurrent requests that compete for servce from the server component. Ths ncludes the networ bandwdth and underlyng transport mechansms. The second factor descrbes a case n whch accepted requests compete for a thread to execute the busness components. The thrd factor results from concurrent access to the database by the concurrent server threads. The frst factor s proportonal to the number of clents, the second to the number of clents and nversely proportonal to the number of threads (.e. number of components on the server) and the thrd factor s proportonal to the number of the threads.

7 T / N = ax + b x y + cy T / N = executon tme per transacton x = number of clents; y = number of components a, b, c = proportonal factors for a partcular mplementaton The form of the equaton shows that t s possble to calculate the optmal number of threads n relaton to the number of clents to acheve a mnmum respond tme per transacton. (5) c. Derved Propertes Defnton: A derved property of an assembly s a property that depends on several dfferent propertes of the components. P( A) = f ( P ( c ), P ( c ), L, P ( c ));, N P = assembly property P... P = component propertes (6) In the same way that a functon of an assembly s more than the sum of the component functons, there are propertes that are the result of the composton of dfferent component propertes. An example of such a property n a real-tme system s the end-to-end deadlne (a maxmal response tme) that s a functon of dfferent component propertes, such as worst case executon tme (WCET) and executon perod as shown n the followng example. Let us consder real-tme port-based component models wth provded and requred nterfaces and nterfaces to an underlyng operatng system or I/O devces, as dscussed n [11-13]. In these models, components are mplemented as tass, parts of a tas or a set of tass. An assembly consstng of two components, where every component s realzed as a tas s shown on fgure 2. Each basc component ncludes propertes such as WCET and executon perod. A composton of ths smple model s acheved by connectng ports and dentfyng provded and requred nterfaces. The queston s whether we can calculate WCET for an assembly of components executng wth dfferent perods. In a case n whch the executon perods are the same, ths would be possble. In a case n whch these perods are dfferent, we cannot specfy WCET of the assembly, but we can specfy end-to-end deadlne and a perod. An end-to end deadlne s the maxmum tme nterval between the start of the frst component n an assembly and the fnsh of the last component n the assembly. The assembly perod wll be a number to whch the components perods are dvsors.

8 Input ports A C1 wcet1 f1 C2 wcet2 f2 Output ports Fg. 2. Composton of port-based components Emergng propertes,.e. propertes that are pertnent on a system (or an assembly) level but are not vsble on the component level are of specal nterest n ths category. For such propertes the major challenge s to dentfy the propertes of the components that have mpact on them. d. Usage-dependent Propertes Defnton: A Usage-dependent property of an assembly s a property whch s determned by ts usage profle. P ( A, U P U U = =, = ) = f ( P( c, U, property for a partcular usage profle assembly usageprofle ));, N component usageprofle The behavor of an assembly and consequently of a system depends not only on the nternal propertes of the components and ther composton but also on the partcular use of the system. A usage profle U whch determnes a partcular property P must be transformed to the usage profle U, to determne the propertes of the components. Propertes of ths type ntroduce partcular problems as they depend on the use of the system. Ths means that the component developers must predct as far as possble the use of the component n dfferent systems whch may not yet exst. A second problem s the transfer of the usage profle from the assembly (or from the system) to the component. Even f the usage profle on the assembly level (U ) s specfed, the usage profle for the components (U, ) s not easly determned especally when the assembly (and the system) confguraton s not nown. A partcular problem wth ths type of property s the lmted possblty of reusng measured and derved propertes. If the usage profle s changed, the propertes must be re-calculated or re-measured. An example of such a property s relablty whch s based on a usage profle. The queston arsng here s the possblty of reusng prevous specfcatons of the property [11]. The frst thought would be that ths s possble (7)

9 f the doman of the new usage profle s a sub-doman of an old usage profle. In ths case the value of a property wll be wthn the range of possble values of the property for the old usage profle, the local maxmum and mnmum value beng n the range of values for the old usage profle (see Fg. 3). P(U) P P l U l-mn U l U l-max U -mn U U -max Fg. 3. Property for dfferent usage profles If the new requrements are equal of or less strngent than the old requrements, we can use the property value from the old usage profle. Ths means, for example, that we do not need to measure the component propertes. U l U P mn ( A, U ) Pl ( A, U l ) P max ( A, U ) (8) In a case n whch a property s expressed as a statstcal value (such as a mean value), the property value n a partcular nterval can be changed n an unwanted drecton; Fg 3 llustrates an example n whch the mean value of the property P(U) n the nterval [U l-mn, U l-max ] s lower than n the entre nterval [U -mn, U -max ], although the mnmum value s hgher. For certan propertes (such as avalablty) n certan domans (for example multmeda) the average plays a more mportant role than mn or max values. e. System Envronment Context Propertes Defnton: A System Envronment Context property s a property whch s determned by other propertes and by the state of the system envronment.

10 P ( S, U U l S = System U,, E ) = f ( P ( c, U l, = System usage profle; E = Envronment context ), E ); = Component usage profle l,, l N (9) The property depends not only on the system property determned by the usage profle, but also the envronment n whch the system s used. An example of such a property s safety. As the safety property s related to the potental catastrophe, t s obvous that n dfferent crcumstances, the same property may have dfferent degrees of safety even for the same usage profle. We can argue that these propertes are out of the scope of the predctable assembly, but as such propertes are also dependent on component propertes, ths relaton s mportant. The analyss approach for such propertes s opposte to the composton; the system envronment and the system propertes defne the requrements for component propertes. A system can exhbt numerous propertes and certanly not all of them have the same characterstcs; some are easy to perceve and measure whle others are very dffcult to analyze, or measure (for nstance admnstrablty). Analyzable propertes, whch can be measured, are potental canddates for automatc reasonng about the behavor of a system. Propertes that depend on the envronment n whch a system s deployed are generally hard to derve from the component propertes. 3 Assembles and Systems We have used the generc term assembly for a set of ntegrated components. In the prevous secton t s shown that specfcaton of some propertes should dstngush between an assembly and a system. A system s n general much more than a set of components; a system s a set of software programs and ther nter-dependences deployed on computer hardware. A system s usually seen as a complete program or many programs and computers worng together to provde a functon and nteractng wth ts envronment. In several models the assembly s nterpreted by a runtme framewor that nstantates and executes the applcaton or system. Very seldom s an assembly of components an applcaton or a system of ts own, somethng that understands and can run ths assembly must be provded. Nevertheless, a software system may consst of a set of assembles, whch turns out to be a set of components. Several questons arse when composng assembles: Can the assembles composed be treated as components n the new assembly, or are they treated n the new assembly as a set of the orgnal components loosng the assembly dentty. An deal stuaton would be to have a means of usng a herarchcal and recursve model whch permts the same reasonng on all levels of the herarchy. In most of the exstng component-based technologes ths s not possble to acheve.

11 There are two nds of assembles supported by exstng component technologes. The frst s the 1st order assembly whch s not treated as a component n the component model. Ths type of assembly s merely a set of components ntegrated together, creatng an applcaton or a part of an applcaton. In ths case an assembly s seen as a vrtual boundary of the component set and not as a separate entty. The second type of assembly s herarchcal whch means that the assembly, created from components, s treated as a new component nsde the component model. There are dfferent crtera whch must be satsfed f an assembly s to be treated as a component. The basc crtera are the followng: Operatonal (constructon) nterface; Component deployment; Component qualty attrbutes. Operatonal Interface The operatonal nterface s the smplest part of the herarchcal composton. A component model should provde a means of constructng an nterface for the assembly from the ntegrated components. Several component technologes provde support for managng assembles. One example s port-based archtectures for components [11]. In such models components have specfed source and sn ports whch are attached to the ports of other components. It s easy to magne that the result of the composton of these components can be treated as a new component. Although t s mportant that the new nterface of the assembly must be specfed and mplemented n the same manner as those of the components themselves, the assembly s not otherwse defned n the same component model. Some component models provde support n creatng assembles on the archtecture defnton language (ADL) level. Other component models use composton languages that have composton and component notatons. The Koala component model [8], s one example that ncludes an ADL and programmng language whch descrbes the components and connectons between them. Koala however never creates the real assembles, source code components are used nstead and an applcaton/assembly s generated by the descrpton n ADL,.e. there are no bnary components as n, for nstance,.net technology. Another example s COM whch, by means of ts aggregate faclty, provdes support by bundlng several components nto a new one. Ths new component does not have a bnary representaton but from the users pont of vew t behaves as any other COM component. Component deployment To obtan ndependent deployment of components, the components must be pacaged ndependently and n a unform manner conformng to the component model. In the case of an assembly of ndependent components, t s not easy to pacage the complete assembly and to treat t as a component because there s no component type whch matches the assembly. Every component has a component type or unque dentfer specfed n a type repostory. For nstance, COM uses the wndows regstry to store the component dentfers and the defned nterface dentfers.

12 The component deployment and the component nstantaton are two separate actvtes; the component type s deployed and a component s subsequently nstantated from the type. Ths approach dffers from hardware components for whch the actual component s wred together wth other hardware components onto the board. The hardware components are deployed and nstantated at the same tme. Once nstalled, the software component can be nstantated many tmes. To nstantate an assembly means to nstantate components whch mght be already deployed. Ths fact maes t mpossble to treat assembles as ndependent unts of deployment. In the Koala component model, a new component, whch may nclude other components, can be specfed, so n that respect there are herarchcal assembles of components. When a complete system of components s desgned, Koala uses a compler whch, gven the descrpton of the assembly, produces the actual bnary output. Ths output s however not treated as a component n the model, as t s the fnal product. The model was desgned to produce applcatons, not to produce new bnary components. New components are added to the system n the form of source code, and component specfcatons. Component qualty attrbutes Wth respect to qualty attrbutes and herarchcal composton, t may be ased f t s possble to treat qualty attrbutes of assembles n the same way as qualty attrbutes of components. The queston s partally answered n the frst secton t depends on the type of the property. In many cases the property and the way to use t n composton reasonng wll be the same. The way to obtan the property value mght be dfferent. Theoretcally the property value of an assembly can be derved from the component propertes. In ths way a property of an assembly of assembles wll be a composton of assembly and component property functons. For example, the propertes of type (a) from the secton 2 wll be derved n the followng way: P( A ) = f ( P( A ) = f ( f ( P( c )));, N A P = property, A A a a = { A }; A = assembes, = { c } a = assembly of assembles c = components For the memory consumpton case n equaton (2), we have: (10) = 1 n M ( A ) = M ( A ) = M ( c ) (11) a = 1 j= 1 For emergng propertes, t s n general not possble to acheve recurson. The same s vald for component propertes whch are not relevant on the assembly level. We can conclude that the recursve compostons of components are very restrcted, whch s understandable from the defnton of a component. A component s defned as a unt of composton and treated as a blac box. Internal structure or nternal composton can completely dffer from the assembly or system structure and composton of components. j

13 4 Composablty of Qualty Attrbutes The lterature contans dfferent names for system (and component) propertes: nonfunctonal propertes, extra-functonal propertes, or qualty attrbutes. When dentfyng a partcular property of a system or of a component we use the term property, and when referrng to these propertes n general, we use the term qualty attrbute. Ths secton outlnes several dfferent qualty attrbutes and explans how they are classfed accordng to the fve types outlned n the frst secton. Qualty attrbutes can be complex and at a hgher level or they can be more tangble and concrete. Complex attrbutes are, for example, dependablty or performance whle tangble attrbutes could be, for example, memory footprnt, scalablty or avalablty. The complex attrbutes consst of several more tangble attrbutes, and as a consequence the complex attrbutes are harder to classfy n one category only. Apart from the fve categores presented n ths paper there are other means of classfcaton. For nstance, attrbutes can be placed n two classes, namely, whether they can be observed at run tme or not. Press et al show such a mappng of qualty attrbutes from the runtme observable perspectve [6]. To demonstrate that there are dfferent qualty attrbutes n the varous categores we have assembled a table (Table 1) showng the classfcaton of the attrbutes. The qualty attrbutes are manly taen from [4,6,14-16]. Accordng to [7] certan attrbutes grouped together consttute complex attrbutes. As these attrbutes are vaguely defned, and we have n some cases slghtly modfed them to acheve better consstency, n the table they are desgnated as concerns. Stll some nconsstences remaned: for example mantanablty s defned as a concern and as an attrbute. Such nconsstences are the result of havng dfferent requrements, prortes, development processes and focus when performng the categorzaton. The table shows the domnant type of composton and possbly another related composton type.. For each attrbute there s one domnant type of composton, mared wth an xx that has the greatest mpact on the partcular attrbute. Other related composton types, not as domnant, are mared n the table wth a sngle x. When dentfyng the most mportant types of compostons for each qualty attrbute we have ased the followng questons: 1. Is ths attrbute a property of a component or only of an assembly/system? A negatve answer ndcates that the property s derved from many dfferent component propertes or has system characterstcs. On the other hand, an affrmatve answer ndcates that the property mght be drectly composable. 2. If the attrbute s a property of a component, wll the same attrbute be present at the assembly of such components? If ths s true, are there some other propertes or factors that have (vsble) mpact on the attrbute of an assembly. If there are no such attrbutes then the property s drectly composable. 3. What s the most mportant mpact on ths attrbute on the assembly level? Ths clearly ndcates the type of composton.

14 Ths mples that a deployment of a component-based approach n a development process may mpact on many qualty attrbutes. 5 Composablty of dependablty attrbutes To llustrate the attrbute classfcaton, we tae dependablty as an example. Dependablty s defned as the ablty of a system to delver servce that can be trusted and the ablty of a system to avod falures that are more severe and frequent than are acceptable to the users. Dependablty s the man qualty attrbute when buldng safety-crtcal systems. (.e. those systems n whch falure can cause human casualtes). In most cases, safety-crtcal systems are hard real-tme systems (.e. systems n whch the tmng requrements must be met), and embedded systems (.e. a combnaton of software and hardware), whch mples a number of tmng and resource constrants. Such systems requre rgorous development procedures and software archtecture whch can mae them as predctable as possble. Dependablty s a complex attrbute consstng of sx man qualty attrbutes, namely, avalablty, relablty, safety, confdentalty, ntegrty and mantanablty. The questons of nterest to component-based software engneerng or development are: Whch of the dependablty propertes are emergng or derved system propertes, whch are both system and component propertes? How are these propertes n a component-based system related to component propertes? To whch extent (and how) can these propertes can be determned from component propertes? To whch extent can the uncertanty of the predctablty of these propertes be mnmzed and how much s t related to the uncertanty of the component propertes? The followng s a short analyss and classfcaton of the dependablty propertes. 5.1 Relablty The defnton of Relablty orgnates from the probablty that a system wll fal wthn a gven perod of tme. Relablty s nversely proportonal to ths probablty as mean tme to falure (MTTF) and t s defned for a specfed perod of tme under stated condtons. The probablty of falure s drectly dependent on the usage profle and context of the module under consderaton.

15 MTTF( A) = 1 ( ) A = module (component,assembly,module) P f P f A = probablty that module A fals per tme unt (12) The module can be a system, or an assembly or a component, so the relaton between the relablty of an assembly and a component can be expressed by (4) and, because of the fact that the relablty s measured under stated condtons, a usage profle must be specfed, whch s expressed by (6). The domnant type of mpact on relablty s the usage profle but relablty s also dependent on the software archtecture and how components are assembled; a fault-tolerant redundant archtecture mproves the relablty of the assembly of components. One possble approach to the calculaton of the relablty of an assembly s to use the followng elements [17,18]: Relablty of the components Informaton that has been obtaned by testng and analyss of the component gven a context and usage profle Path nformaton (usage paths) Informaton that ncludes usage profle and the assembly structure. Combned, t can gve a probablty of executon of each component, for example by usng Marov chans. It s noteworthy that even f the relablty of the components are nown t s very hard to now f sde effects tae place that wll affect an assembly of the components, e.g. f the components wrte n a memory space used by another component that causes a falure. A model based on these assumptons needs the means for calculatng or measurng component relablty and an archtecture whch permts analyss of the executon path. Component models that specfy provded and requred nterface, or mplement a port-based nterface mae t possble to develop a model for specfyng the usage paths. Ths s an example n whch the defnton of the component model facltates the procedure of dealng wth the qualty attrbute. One nown problem n the use of Marov chans n modelng usage s the rapd growth of the chan and complexty [17]. The problem can be solved because the relablty permts a herarchcal approach. The system relablty can be analyzed by (re)usng the relablty nformaton of the assembles and components (whch can be derved or measured) Avalablty Avalablty s defned as the probablty of a module beng avalable when needed. Formally, t s defned as the mean tme to falure dvded by the mean tme between falures (MTBF), whch n turn s the sum of the MTTF and the mean tme to repar (MTTR): Avalablty( A) = MTTF ( A) MTTF ( A) + MTTR( A) A = module (component, assembly,module) (13) From (13) we can see that avalablty s related to relablty. In the same way as relablty, avalablty can be obtaned by measurements through the usage profles. It

16 s however not the same property; For example a module can be consdered to have good avalablty f t has relatvely poor relablty but requres lttle tme to repar. Also, an assembly, or a component can be relable but not avalable, for example due to lac of resources (the component may need to wat for the resource to start). MTTR s related to a means to attan the dependablty,.e., t s related to fault tolerance, fault forecastng and fault removal. All these terms are not formally specfed and cannot be drectly measured. The dfference between relablty and avalablty s that avalablty s dependent on the dynamc state of the system the avalablty of an assembly cannot be derved from the avalablty of the components n the way that ts relablty can be derved from the relablty of ts components. Further, f avalablty s treated n a larger context, non run-tme propertes or qualty attrbutes must be taen nto a consderaton. Avalablty s related to the mantenance and support of the components consttutng the assembly. Factors such as these are very mportant n determnng f or not a component s to be selected for ncluson n a system. It s mportant to reduce the mean tme to repar by all means. 5.3 Safety Safety s a property nvolvng the nteracton of a system wth the envronment and the possble consequences of the system falure. It s a system property, nether a component nor an assembly property. Its safety depends on where and how the system s deployed. For example, a system controllng a robot could cause harm to a human beng f a fault leads to uncontrolled robot movement. Safety s ncreased by nstallng the robot n a cell whch cannot be entered durng operatons. Snce safety s a system property that s dependent on the system s envronment, a means for analyzng safety s a top-down approach, a decomposton rather than composton. In the analyss process, the components attrbutes are used as selecton crtera or are dentfed as demands that should be met. For ths reason a componentbased approach mght not have the apparent advantage on the contrary, f the startng dea s a reuse of exstng components, the components attrbutes cause new constrants and n ths way mght decrease the system safety. However, when the constrants are dentfed and unambguously related to the constrants on the system level, the system safety can ncrease. Also, some propertes, such as relablty, mght mprove the accuracy of the system safety predcton, especally f nown or measured when used n other applcatons. 5.4 Confdentalty and Integrty A system would not be dependable f unauthorzed access or, even worse, unauthorzed alteratons of the system data, was easy or even permtted. Hence securty aspects, confdentalty and ntegrty, defned as follows [15] apply to dependable systems. Confdentalty s defned as a measure of the absence of unauthorzed dsclosure of nformaton;

17 Integrty s defned as the absence of mproper system state alteratons. From the defntons t s apparent that these propertes are not drectly measurable, and ths s the man obstacle to the development of a theory for ther predcton. Integrty s a prerequste for avalablty, relablty and safety, but need not be so for confdentalty or mantanablty. Confdentalty and ntegrty are emergng system propertes that can be tested and analyzed on the system and archtectural level but not on the component level. Usage profles can be used for testng and analyss, but t s mpossble to automatcally derve these propertes from the component propertes. 5.5 Mantanablty Mantanablty s defned as the capacty to undergo repars and modfcatons. Mantenance s of three dfferent types, correctve, adaptve and perfectve mantenance [15]. Correctve mantenance s the removal of faults, thereby mprovng the relablty of components under the condton that no new faults are ntroduced. Adaptve mantenance s performed when a component s modfed to meet modfcatons n the target envronment. Perfectve or preventve mantenance addresses mprovements of the components n response to users or desgners nput. Mantanablty s related to the actvtes of people and not of the system tself. Component technologes mght provde support for dynamc upgradng/deployment of components whch can mprove the mantanablty of a system. In ths case the mantanablty s much a matter of component technology, and not of the component tself. The system archtecture thus has an mpact on mantenance. Component technologes certanly affect correctve and adaptve mantenance but not perfectve mantenance to the same degree. A component-based archtecture mght be easer to adapt to envronmental changes because of ts natural modularty. A more modular archtecture mght facltate, dependng on the relatonshps between the components, the removal of faults n correctve mantenance but for efforts to perfect the mplementaton, a component model s of lesser mportance. For nstance, a need to replace all macros n the code wth templates does not depend on the component model. As the classfcaton n table 1 ndcates, most mantanablty attrbutes are probably drectly composable or archtecture-related. There are many parameters that can be measured and then used to estmate the mantanablty of a code (for example McCabe Metrcs for complexty [19]). These parameters can be dentfed for each component. It s however not clear how these parameters can be defned on the assembly level. One possblty s to defne a mean value of all components normalzed per lnes of code. 6. Concluson A full advantage of component-based approach wll be acheved when not only the functonal parts are reused, but also when ths approach leads to easer and more

18 accurate predctablty of the system behavor. When systems are desgned and buld from components, many system attrbutes can be derved from the component propertes, ths beng more accurate f a support for defnng and measurements of the attrbutes are bult n the component technologes. However, a predctablty of attrbutes does not depend only of component models but also on the attrbutes themselves. For each property, a theory of the property, ts relaton to component model, composton rules and an overall context related to the requrements must be nown. The qualty attrbutes can be classfed wth respect to types of composton, n whch each type s characterzed by the requred nput for obtanng predctablty on the system level. Some types show clear composable characterstcs, whle others are not drectly related to compostons. The exstng component models dffer consderably and how the assembles and components attrbutes are treated wll be hghly dependent on these models, especally for those propertes that are drectly composable or are related to the archtecture. For example, f the component model has ndependently deployable components wth a 1st order assembly model, t s lely that the propertes of the components cannot be propagated further than the assembly level wthout consderng the envronment. In spte of dversty of propertes, technologes, and theores, t should be possble to create reference framewors that by dentfyng type of composablty of attrbutes can help n estmaton of accuracy and efforts requred for buldng component-based systems n a predctable way. References [1] Crnovc I., Schmdt H., Stafford J., and Wallnau K. C., "5th Worshop on Component-Based Software Engneerng: Benchmars for Predctable Assembly", In Software Engneerng Notes, volume 27, ssue 5, [2] Moreno G. A., Hssam S. A., and Wallnau K. C., "Statstcal Models for Emprcal Component Propertes and Assembly-Level Property Predctons: Toward Standard Labelng", In Proceedngs of 5th Worshop on component based software engneerng, [3] Stafford J. and mcgregor J., "Issues n Predctng the Relablty of Composed Components", In Proceedngs of 5th worshop on component based software engneerng, [4] Svahnberg M., Supportng Software Archtecture Evoluton, Ph.D. Thess, Blenge Insttute of Technology, Sweden, [5] Dromey G.R., "A Model for Software Product Qualty", In IEEE Transacton on Software Engneerng, volume 21, ssue 2, 1995.

19 [6] Press O., Wegmann A., and Wong J., "On Qualty Attrbute Based Software Engneerng", In Proceedngs of EUROMICRO 2001 CBSE worshop, [7] ISO/IEC, Informaton technology - Software product qualty - Part 1: Qualty model, report ISO/IEC FDIS :2000 (E), ISO, [8] van Ommerng R., "The Koala Component Model", n Crnovc I. and Larsson M. (edtors): Buldng Relable Component-Based Software Systems, ISBN , Artech House, [9] Yan L., Gorton I., Lu A., and Chen S., "Evaluatng the scalablty of enterprse javabeans technology", In Proceedngs of 9th Asa-Pacfc Software Engneerng Conference, IEEE, [10] Jogalear P. and Woodsde M., "Evaluatng the Scalablty of Dstrbuted Systems", In IEEE Transactons on Parallel & Dstrbuted Systems, volume 11, ssue 6, [11] Crnovc I. and Larsson M., Buldng Relable Component-Based Software Systems, ISBN , Artech House, [12] Hssam S. A., Huda J., Ivers J., Klen M., Larsson M., Moreno G. A., Northrop L., Plaosh D., Stafford J., Wallnau K. C., and Wood W., Predctable Assembly of Substaton Automaton Systems: An Experence Report, report CMU/SEI-2002-TR-031, Software Engneerng Insttute, Carnege Mellon Unversty, [13] Wall A., Larsson M., and Norström C., "Towards an Impact Analyss for Component Based Real-Tme Product Lne Archtectures", In Proceedngs of Euromcro Conference on Component Based Software Engneerng, [14] Bass L., Clements P., and Kazman R., Software Archtecture n Practce (2nd edton), ISBN , Addson-Wesley, [15] Avžens A., Lapre J.-C., and Randell B., "Fundamental Concepts of Computer System Dependablty", In Proceedngs of IARP/IEEE-RAS Worshop on Robot Dependablty: Technologcal Challenge of Dependable, Robots n Human Envronments, [16] Kazman R., Bass L., Abowd G., and Webb M., "SAAM: A Method for Analyzng the Propertes of Software Archtectures", In Proceedngs of The 16th Internatonal Conference on Software Engneerng, [17] Schmdt H. and Reussner R. H., " Parametrzed Comtracts and Adapter Synthess", In Proceedngs of 5th ICSE worshop on CBSE, 2001.

20 [18] Schmdt H., "Trustworthy components: compostonalty and predcton", In Journal of Systems & Software, volume 65, ssue 3, [19] McCabe T.J., A Complexty Measure, IEEE Transacton on Software Engneerng, volume 2, 1976.