A Formal Model for Component-Based System Assessment

A Formal Model for Component-Based System Assessment Camelia Serban and Andreea Vescan and Horia F. Pop Babes¸-Bolyai University, Department of Computer Science 1 Kogalniceanu St., 400084, Cluj-Napoca, Romania Email: {camelia, avescan, hfpop}@cs.ubbcluj.ro

Abstract—The selection of a component within a set of possible candidates which offer similar functionalities requires the evaluation of the candidate components using objective methods, the evaluation results helping developers in the selection task. In this article we propose a formal approach concerning component based systems (CBS) assessment. More precisely, we aim to define a quantitative evaluation model which provides a standard terminology and formalism in order to define metrics, to establish the assessment objectives and to interpret the measurement results obtained. Furthermore, the proposed model is general and scalable and allows other properties and interactions to be added. The article also presents the applicability of the model. Keywords-component; metrics; fuzzy analysis;

I. I NTRODUCTION Software systems become very large and complex applications. To reduce software development life cycles and costs, the software development community increasingly approaches the development of software systems by reusing components. In the selection of the component that best fulfill the system requirements, among components with similar functional properties, the knowledge on quality attributes could often represent the most significant information. Thus, there is a need for an objective evaluation methodology that may assist software developers to select appropriate components for projects. Objectivity can be achieved by performing a quantitative comparison among alternatives. Regarding component-based systems (CBS) assessment, various approaches have been found in literature [14], [11], [12], [13], [9], but most of them lack a standard terminology and formalism regarding the specification of the assessed domain, the definitions of metrics and the interpretation of the measurements results obtained. Consequently, the replication of experiments, the results comparison and generalization are hampered. In an attempt to address the above mentioned shortcomings, a formal model for the assessment of CBS is defined in Section III. The aplicability of the proposed approach, describing the steps needed to be performed, is presented in Section IV. This briefly presentation is due to the fact that the proposed model is a generalization and a

formalisation of our previous work [2], [3], [4], [5] where we presented several case-study and comparision with similar approaches were made. Section II discusses related work on CBS assessment. Finally, section V suggests directions for future work and concludes the paper. II. R ELATED W ORK ON CBS A SSESSMENT There are several approaches found in literature that address the problem of metrics-based assessment for both individual components and the system obtained by connecting components. Gill et al. in a suite of articles [14], [15], [16], [17] suggested useful guidelines for component-based measurement and several metrics applicable to componentbased development. Bertoa et al. [13] proposed usability metrics for software components. Washizaki et al. [12] proposed a quality model for measuring the reusabily of software components. Narasimhan [9] et al. and Hoek et al. [7] have proposed a set of metrics suite that can be used in software component integration to assess the fitness of components in a specific architecture and to measure the complexity of interaction. However, these approaches lack a standard terminology and formalism regarding the specification of the assessed domain, the definitions of metrics and the interpretation of the measurements results obtained. Goulao et al. [11] presented a formalization of metrics for CBD, using OCL language. We believe that this approach provides a useful mechanism for the precise definition, but the majority of software designers may not have the required background to understand the OCL formalism. Moreover, the proposed formalisation is not integrated within a corresponding assessment model. III. P ROPOSED A PPROACH D ESCRIPTION As we have stated before, our goal regarding CBS assessment is to obtain an quantitative evaluation methodology. Thus, the proposed model is composed of four layers of abstraction: • The assessment domain – the elements that are evaluated, their properties and the relationships between them are specified, defining a metamodel for CBS; • The assessment objectives – specified using a quantitative approach;

Formal definitions of metrics –metrics are defined using the proposed metamodel as contextual input; • A measurement results analysis method - fuzzy clustering is used for the interpretation of the results obtained by applying measurements. The detailed descriptions of these layers are presented in what follows. •

be noted that certain properties can only be observed, but not changed. Consider the following notations: ∪ RIc – the set of interfaces of component • Ic = P Ic c ∈ CR; ∪ • P I(CR) = P Ic – the set of provided interfaces c∈CR •

∪

RIc – the set of required interfaces

c∈CR

A. A meta-model for Component-Based System Any software measurement activity has to be preceded by the specification of the entities which will be evaluated, their properties and the relationship between them, defining in this way a meta-model for the analysed system. In what follows we will specify, in terms of algebraic sets and relations, the elements of the metamodel for compnent-based system. 1) System entities: Consider a repository of components CR, CR = {c1 , c2 , ..., cnoCR }. A subset of components Comp(S) = {c′1 , c′2 , ..., c′noComp }, Comp(S) ⊆ CR, is selected in order to construct a software system S that has to provide a set of services Serv(S) = {s1 , s2 , ..., snoServ }. Szyperski [8] defines a component as, “a unit of composition with a contractually specified interface and explicit context dependencies only.” Furthermore, it “can be deployed independently and is subject to composition by the third parties.” Therefore, components internal design and implementation are strongly encapsulated and the component exclusively communicates with other components through its interfaces, leading to inter-component dependencies. A dependency occurs when, in order to provide an interface, a component requires an interface which is provided by another component. Therefore, each component c ∈ CR is specified as a set of provided interfaces P Ic = {pic,1 , pic,2 , ..., pic,noP Ic }, a set of required interfaces RIc = {ric,1 , ric,2 , ..., ric,noP Ic } and the dependencies (context) between its provided and required interfaces. These dependencies are described in detail in Section III-A3. In this approach, a component interface is represented by an operation or by an event. The operations capture the dynamic behavioral capability of the component, and represent the service/functionality that the component provides. While certain aspects of a system are captured through proactive control via operations, other aspects are better captured in the form of reactive control via events. To facilitate reactive control, a component may generate events from time to time, and there may be none or many responses to an event from other components in the system. Interface operations and events provide inputs/outputs as parameters. These parameters define the signature of an operation/event. In addition to the operations and events, a software component may have a number of properties externally observable. A common use of component properties is for component customization and configuration at the time of use. It should

of set CR; RI(CR) =

•

of set CR; ∪ I(CR) = P I(CR) RI(CR) - the set of interfaces of CR set; ∪ P I(S) = P Ic – the set of provided inter-

•

faces from S, ∪ Serv(S) ⊆ P I(S); RI(S) = RIc – the set of required interfaces

•

c∈Comp(S)

c∈Comp(S)

•

from S; I(S) = P I(S) ∪ RI(S) – the set of interfaces from S; P aramc (i) = {pc,1 , pc,2 , ..., pc,N oP aramci } – the set of parameters that appear in the signature of interface i, i ∈ Ic ; Pc = {epc,1 , epc,2 , ..., epc,noEPc } – the set of properties of component c; ∪ ∪ P aramc (i) Pc – the set of parameP aramc =

•

ters of component ∪ c; P aram(S) =

• •

•

i∈Ic

P aramc – the set of parame-

c∈Comp(S) •

ters from the system S; ∪ P aram(CR) =

P aramc – the set of pa-

c∈Comp(S)

rameters from repository CR; Equation 1 defines the set of system entities. E = Comp(CR) ∪ I(CR) ∪ P aram(CR).

(1)

2) Properties of system entities: Because current approach refers to three types of system entities (component, interface, parameter), each type having its own set of properties, we define a model in order to specify the properties of entities of a generic type T . Properties of generic type entities. Formal specification. • Let us consider a set of entities A = {a1 , a2 , ..., ak } of a generic type T and a set of properties defined on this type, P ropT = {P1 , P2 , ...PnoPT }; • Each property Pi from P rop(T ), 1 ≤ i ≤ noPT , have a set of values Pi = {vi1 , vi2 , ...viN oVi }; • Each entity ai from A, 1 ≤ i ≤ k, is mapped to a value from the cartesian product, P1 ×P2 ×...×PnoPT , P ropV alT : A → P1 × P2 × ... × PnoPT . element vi of the vector Definition 1: An P ropV alT (aj ) = (v1 , v2 , ..., vnoPT ) is called the value of property Pi corresponding to entity aj , shortly denoted as vi = aj .Pi . Definition 2: P ropV alT (A) = {P ropV alT (aj )|i = 1, k} is called the set of properties values corresponding to entities set A of type T .

Definition 3: P ropT,A = [T, A, P ropT , P ropV alT (A)] is called properties specification corresponding to a set of entities A of type T . In what follows, we apply this model in order to specify the properties for each type of system entities from our metamodel: component (C), interface (I), parameter (P). Definition 4: The 4-tuple, P ropC,CR = [C, CR, P ropC , P ropV alC (CR)] is called specification of properties for entities of type“component”, where: • P ropC = {Granularity, Standard, CM M Level, Cost, V ersion}; • Granularity = {coarse − grained, medium − grained, f ine − grained}; • Standard = {Corba, COM, DCOM, .N et, EJB}; • CM M Level = {Initial, M anaged, Def ined, Quantitatively, Optimized}; • Cost = [a1 , b1 ], cost values range; • V ersion = {vi |i = 1, noV }. As we have mentioned before, interfaces are fundamental for a component because they characterize component functionality. In addition to the functional properties, there are other features of a software component, its non-functional properties like cost, CMM Level, quality attributes, such as reusability, functionality, security, performance and reliability. In general, quality attributes are not a constant property. The quality of a component depends on the specific usage context. Therefore, the quality attributes of a component are quantified by the component’s user, according to his system requirements and context. It is important to point out that the set of component properties, P ropC , is incomplete. Other data, such as those regarding the environment in which the component is used, can be added later on in the process. These statements argue that the proposed model has the scalability property. Definition 5: The 4-tuple, P ropI,I(CR) = [I, I(CR), P ropI , P ropV alI (I(CR))] is called specification of properties for entities of type “interface”, where: • P ropI = {Kind, F unctionality}, • Kind = {operation, event}, • F unctionality = {provided, required}. Definition 6: The 4-tuple, P ropP,P aram(CR) = [P, P aram(CR), P ropP , P ropV alP (P aram(CR))] is called specification of properties for entities of type“parameter”, where: • P ropP = {Kind, T ype, Aggregation, Access}, • Kind = {external, return − value, argument} • T ype = {predef ined, user − def ined, library}, • Aggregation = {simple, array, f ile}. • Access = {read − only, write − only, read − write}

3) Relations between system entities.: In this section we specify two types of relations that exist between the system entities defined in Section III-A1. Dependency relations. In order to specify component dependencies we introduce the following definitions. Definition 7: A dependency for a component c, c ∈ CR, is a pair (p, r), p ∈ P Ic and r ∈ RIc , with the meaning that in order to provide interface p, component c requires an interface r from other component, we shortly denote this relation as p DRc r. In Figure 1 we exemplify the dependency relations for a component c. DRc

ri

rj

rk

Pu Pv Pt

ri rj rk

Component c

pu pv pt

Figure 1. Specification Table of the Component Dependencies Requirements for component c with the DRc (pu ) = {(pu , ri ), (pu , rk )}, DRc (pv ) = {(pv , rj ), (pv , rk )} and DRc (pt ) = {(pt , rj )} and the graphical representation of the contexts.

Definition 8: The set of all dependencies of a component c, c ∈ CR, is a binary relation DRc ⊆ P Ic × RIc , defined as (p, r) ∈ DRc ⇐⇒ p DRc r. Remark: It is important to mention that there are interfaces without dependencies. The services of these interfaces are the services that handle input data. Additional notations are needed: • DRc (p) = {(p, r)|r ∈ RIc ∧ p DRc r} represents the dependencies set ∪ of the provided interface p, p ∈ P Ic ; DRc is the set of all dependencies • DR(CR) = c∈CR

from the repository CR. Connection relations. The connection occurs when a component provides an interface and other component uses it. We define two kinds of connection relations for a component c: in–connection relations, when component c uses an interface from other component, and out-connection relations, when component c provides an interface for other component. It is important to mentioned that the connection relations are identifiable as the Comp(S) set is constructed. Next, we formally define these connection relations. Definition 9: Consider c, d ∈ Comp(S). We say that c is in–connected with d within the system S, if (∃) r ∈ RIc such that r ∈ P Id and component c uses the required interface r from component d. We briefly denote this relation as c CRin,r d. Definition 10: Let CRin,c = {(r, d)|(r ∈ RIc , d ∈ Comp(S)) ∧ c CRin,r d} be the set of all in–connections of component c, c ∈ Comp(S). Definition 11: Let CRin,c (p) = {(r, d)|(r, d) ∈ CRin,c ∧ (p, r) ∈ DRc }, c ∈ Comp(S), p ∈ P Ic , be the set of all in–

connections of component c regarding the provided interface p. Definition 12: Consider c, d ∈ Comp(S). We say that c is out–connected with d within the system S, if (∃) p ∈ P Ic such that p ∈ RId and component d uses p from component c. We shortly denote this relation as c CROut,p d. Definition 13: Let CRout,c = {(p, d)|(p ∈ P Ic , d ∈ Comp(S)) ∧ c CRout,p d} be the set of all out–connections of component c, c ∈ Comp(S). ∪ Definition 14: Let CR(S) = CRin,c be the set c∈Comp(S)

of all connections of the software system S. Remark: There are four types of connections using provided and required interfaces. See Figure 2. Component c Component c

Component c

Figure 2.

Component d

Component d

Component d

Component d Component c

The four types of connections relations.

B. Assessment Objectives Any assessment activity must have clear objectives. There are two kinds of requirements that need to be fulfilled when constructing a CBS: the system has to provide a set of functionalities/services and secondly it has to meet certain non-functional properties(illities) or quality attributes, such as security, performance and reliability. These two kinds of system requirements represents the assessment objectives. Regarding system functionalities/services it’s easy to verify if they are attained by the final system. For the second kind of objectives, there are several questionable aspects and not much work has been done in this area. This is because the evaluation of the quality attributes is not integrated within a quantitative model that provides a more pragmatic way of dealing with the problems of results comparison and generalization. In order to mitigate the above mentioned problems, we specify the assessment objectives following the Factor Criteria Metric (FCM) approach. Thus, each quality attribute is refined into several criteria that suggest relevant metrics and consequently, it is linked to one or more metrics that best capture its meaning. Due to the fact that the properties of the system are influenced more by the interaction of its components than by the properties of a single component, the objectives of the proposed assessment are reported to target product: the component assembly. Another aspect concerning the quality attributes is that they influence each other in several ways; for example the increase of one attribute (e.g. performance) can diminish another attribute (e.g. maintainability). Because of this, we have to establish a weight factor (wf) for each selected metric, factor which defines a priority in component selection

process. Thus, between two components that offer similar services it is possible to select a component with a low reusability value instead of a component with a high value of this attribute, if other quality attribute is more important for the beneficiary of the system. Taking all these into account, we consider the following notations and definitions: • Serv(S) – the set of assessment functional objectives, which is the set of services that have to be provided by the final system; • QAttrib(S) = {qa1 , qa2 , ..., qan } – the set of assessment non-functional objectives or quality attributes; • Criteria(S) = {c1 , c2 , ..., cnoC } – the criteria in which the elements of QAttrib(S) set are refined; • M etrics(S) = {(m1 , w1 ), (m2 , w2 ), ..., (mnoM , wnoM )} – the set of metrics corresponding to selected criteria and their weight factors; ⊆ QAttrib(S) × • Assoc QAttrib − Criteria Criteria(S) – the associations relation between the quality attributes and criteria; • Assoc Criteria − M etrics ⊆ Criteria(S) × M etrics(S) – the associations relation between the assessment objectives and metrics; Definition 15: The associations Quality Attributes – Criteria form a bipartite graph, denoted as QACG = (QAttrib(S), Criteria(S), Assoc QAttrib − Criteria). Definition 16: The associations Criteria–Metrics form a bipartite graph, denoted as CM G = (Criteria(S), M etrics(S), Assoc Criteria − M etrics). Definition 17: (Assessment objectives specification) The 3-tuple, (Serv(S), QACG, CM G) represents the assessment objectives specification. To add more clarity for this approach, in Figure 3 we present an example of non-functional assessment objectives, example adapted from [12], [13]. Metrics implied in this example are cited as follows: RCC, SCCp, EMI, RCO [12], ICM [15], CHS, PSU [7]. Quality Attributes

Reusability

Usability

QACG

Criteria

Metric-wf

Adaptability

RCC-5

Functionality

PSU-5

Portability

SCCp-3

Customizability

EMI-2

Understandability

RCO-4

Interfaces Complexity

ICM-2

DocumentationQuality

CHS-5 CMG

Figure 3.

Non-functional assessment objectives. Example

C. Formal Definition of Metrics Although a large number of metrics have been proposed by researchers to assess software systems, they pose some

problems, the most important being that metrics definitions are imprecise, incomplete, lacking a formality degree used to define them. In order to overcome these problems, we strive to formally define metrics for CBS, using the context delineated for the meta-model presented in Section III-A and expressing them in terms of algebraic sets and relations. The definitions of the metrics are therefore unambiguous, straightforward and language independent. They rely on the accurate formalism of sets and relations, knowledge assumed as familiar since the first stages of our studies. As a proof of concept, in Table I we formally define some metrics using the proposed approach. These metrics are introduced by Hoek et al. [7] PSU, RSU and by Narasimhan and Hendradjaya [9] IDC, OIDC, IIDC. Consider the following notations: •

•

• •

OCRout,c = {e|e ∈ CRout,c ∧ e.Kind = operation} – the set of out – connection operation relations of component c; OCRin,c = {e|e ∈ CRin,c ∧ e.Kind = operation} – the set of in – connection operation relations of component c; OP Ic = {e|e ∈ P Ic ∧ e.Kind = operation – the set of provided operation of component c; ORIc = {e|e ∈ RIc ∧ e.Kind = operation – the set of required operation of component c.

Metric Informal definition

Provided Service Utilization (PSU) PSU metric represents the ratio of services provided by the component which are actually used.

Formal definition Metric Informal definition

P SU (c) =

Formal definition Metric Informal definition

RSU (c) =

Formal definition Metric Informal definition

IDC(c) =

Formal definition Metric

IIDC(c) =

Informal definition Formal definition

card(OCRout,c ) , card(OP Ic )

c ∈ Comp(S)

Required Service Utilization (RSU) RSU metric represents the ratio of services required by the component which are actually used. card(OCRin,c ) , card(ORIc )

c ∈ Comp(S)

Interaction Density of a Component (IDC) IDC metric is defined as a ratio of actual interactions over potential ones ∪ card(CRin,c

CRout,c )

card(Ic )

, c ∈ Comp(S)

Incoming Interaction Density of a Component (IIDC) IIDC metric is defined as a ratio of actual incoming interactions over potential ones card(CRin,c ) , card(RIc )

c ∈ Comp(S)

Outgoing Interaction Density of a Component (OIDC) OIDC metric is defined as a ratio of actual outgoing interactions over potential ones OIDC(c) =

card(CRout,c ) , card(P Ic )

c ∈ Comp(S)

Table I F ORMAL D EFINITIONS OF M ETRICS

D. Mesurement Results Analysis After computing the values of metrics which have been selected for the assessment, each component ci ∈ CR will be identified as a vector, ci = (ci1 , ci2 , ..., cinoM ) with the coresponding values of these metrics m1 , m2 , ..., mnoM , mj ∈ M etrics(S), 1 ≤ j ≤ noM . The matrix CR = (ci,j )i=1,k;j=1,noComp represents the assessment results. A relevant interpretation of these results is needed, in order to use them as input data in the component selection algorithm. Regarding this interpretation, a difficulty arises in setting the threshold values for metrics. To avoid the problem of setting threshold for metrics, we use fuzzy clustering analysis. This allows us to place an object in more than one group, with different membership degrees, giving us the posibility to take into account some specific elements of the analysed system by reducing the rigidity of the threshold values. The following definitions emphasize how we apply fuzzy analisys in the proposed assessment model. Definition 18: A matrix U = {U1 , U2 , ..., Uk } is called a fuzzy partiton of a set of components CR, components caracterized by the matrix of the assessment results, iff: • Ui = {ui1 , ui2 , ..., uinoComp }, uij ∈ [0..1], i = 1, k, j = 1, noComp; k ∑ • uij = 1, j = 1, noComp; i=1

where, uij represents the membership degree of the component cj to cluster i; Due to the fact that the number of clusters is an input data for a partitional clustering algorithm, we considered the Fuzzy Divisive Hierarchic Clustering (FDHC) algorithm [10]. This algorithm produces a binary tree fuzzy partition that provides an in-depth analysis of the data set, deciding the optimal subcluster cardinality and the optimal fuzzy partition of the data set. In the following we formally define these two partitions. Definition 19: A set BT F P = {N1 , N2 , ..., Nl } is called a binary tree fuzzy partition of a set of components CR, components caracterized by the matrix of the assessment results, iff: th • (∀)i ∈ {1, 2, ..., l}, Ni = (fi , Ui ), fi -the father of i cluster, fi ∈ {0...l}; Ui = (ui1 , ui2 , ...ui(noComp) ), uij ∈ [0..1], uij represents the membership degree of the component cj to cluster i; • (∃)i, i ∈ {1, 2, ..., l} such that fi = 0 ∧ uij=1 , (∀)j ∈ {1, 2, ..., noComp}, Ni - the root node (cluster); • ∀i ∈ {1...l}, fi ̸= 0, ∃j, k : fi = k ∧ fj = k ∧ Ui + Uj = Uk , where Ui + Uj = (ui1 + uj1 , ui2 + uj1 , ...ui(noComp) + uj(noComp) ). Definition 20: Consider the binary tree fuzzy partition BT F P reffered in Definition 19. A subset OF P = {G1 , G2 , ..., Gk } ⊂ BT F P is called an optimal fuzzy partition iff: Gj is a terminal(leaf) node from BT F P (fi ̸= j, ∀i, j ∈ {1..k} );

In [4] we have constructed an algorithm that describes how to select a component from a set of possible candidates, starting from the fuzzy partitions defined before. IV. A PLICABILITY The steps needed to be performed to apply the proposed evaluation model are mapped on the described model entities: 1) Step1 - Elements identification of the proposed CBS meta-model. At this step, the elements of the sets E, P rop(E), Rel(E)) are identified. 2) Step2 - Setting the Objectives. The elements Serv(S), QACG, CM G, reffered in Definition 17, are established and the selected metrics are formally defined as we have exemplified in Section III-C. 3) Step3 - Metrics computation, Partitions construction, Results analysis. This step encompasses the metrics values computation, the fuzzy partitions determination and the component selection for the system that we aim to build. The selection is made using the algorithm introduced in our previous work. [4]. In conclusion we can state that: the first two steps, mentioned above, define the problem of CBS assessment, what are the input data (first step) and what are the results (second step), while the last step establish the sequence of operations needed to be performed in order to obtain o solution.

[3] A. Vescan, A Metrics-based Evolutionary Approach for the Component Selection Problem. Proceedings of the 11th International Conference on Computer Modelling and Simulation, 25 - 27 March, Cambridge, England, pp. 83 – 88, 2009. [4] C. Serban, A. Vescan, H. F. Pop, A new Component Selection Algorithm Based on Metrics and Fuzzy Clustering Analysis. Proceedings of the 4th International Conference on Hybrid Artificial Intelligence Systems, Vol. 5572, pp. 621 – 628, 2009. [5] C. Serban, A. Vescan, H. F. Pop, A conceptual framework for component-based system metrics definition. 9th RoEduNet International Conference, (accepted). [6] A. Baroni, S. Braz and F. Brito e Abreu , Using OCL to formalize object-oriented design metrics definitions. Proceedings of ECOOP Workshop on Quantitative Approaches in ObjectOriented Software Engineering, 2003. [7] A. v.d. Hoek, E. Dincel, and N. Medvidovic, Using Service Utilization Metrics to Assess and Improve Product Line Architectures. The 9th IEEE International Software Metrics Symposium , 2003. [8] C. Szyperski, Component Software, Beyond Object-Oriented Programming. ACM Press, Addison-Wesley, 1998. [9] V. L., Narasimhan, and B. Hendradjaya, A New Suite of Metrics for the Integration of Software Components. First International Workshop on Object Systems and Software Architectures, 2004. [10] D. Dumitrescu, Hierarchical pattern classification, Fuzzy Sets and Systems 28, 1988, 145–162.

V. C ONCLUSIONS AND F UTURE W ORKS In order to mitigate the shortcomings presented in Section II, we proposed a formal model for CBS assessment. Our model is based on standard terminology and formalism, defining a CBS metamodel that is used as contextual input in order to formally define metrics, to specify the assessment objectives and also to define a robust method, based on fuzzy analysis, for the interpretation of the measurements results obtained. Furthermore, our model is general and scalable and allows other properties and interactions to be added. As one of our future work, we aim to extend the proposed CBS metamodel and to better emphasize its applicability through more case-studies. ACKNOWLEDGMENT This research has been supported by the Romanian CNCSIS through the PNII-IDEI research grant ID 550/2007. R EFERENCES [1] J. Warmer, A. Kleppe, and W. Bast,: MDA Explained: The Model Driven ArchitecturePractice and Promise. AddisonWesley, 2003. [2] C. Serban, A. Vescan, and H.F. Pop. Component selection based on fuzzy clustering analysis. Creative Mathematics and Informatics, 17 (3), pp. 505 – 510, 2008.

[11] M. Goulao, and F.B. Abreu, Composition Assessment Metrics for CBSE. In Proceedings of the 31st Euromicro Conference - Component-Based Software Engineering Track. IEEE Computer Society, 2005. [12] H. Washizaki, H. Yamamoto, and Y. Fukazawa, A metrics suite for measuring reusability of software components. Proceedings of the 9th International Symposium on Software Metrics, 211– 223, 2003. [13] M.F. Bertoa, J.M. Troya and A. Vallecillo, Measuring the Usability of Software Components. Journal of Systems and Software 79(3), 427–439, 2006. [14] N. S. Gill and P. S. Grover, Component-Based Measurement: Few Useful Guidelines. ACM SIGSOFT Software Engineering Notes, vol. 28, 1–4, 2003. [15] N. S. Gill, Few Important Considerations For Deriving Interface Complexity Metric For Component-Based Systems. Software Engineering Notes, 29(2), 2004. [16] N. S. Gill, Importance of Software Component Characterization for Better Software Reusability, ACM SIGSOFT Software Engineering Notes, Vol. 31(1), 1–3, 2006. [17] N. S. Gill, Dependency and Interaction Oriented Complexity Metrics of Component-Based Systems, ACM SIGSOFT Software Engineering Notes, Vol. 33(2), 1–5, 2008.