A New Suite of Metrics for the Integration of Software ... - CiteSeerX

A New Suite of Metrics for the Integration of Software Components

V. L. Narasimhan and B. Hendradjaya

Faculty of Electrical Engineering and Computer Science University of Newcastle NSW 2308, Australia Tel.: +61 2 4921 6953 Email: {narasimhan, bayu}@cs.newcastle.edu.au

Abstract In this paper we propose two sets of metrics to measure complexity and criticality of large software systems designed and integrated using the principles of Component Based Software Engineering (CBSE). From the Component Interface Definition Language (CIDL) specification [32], we derive two suites of complexity metrics, namely, Component Packing Density (CPD) metrics and Component Interaction Density (CID). The CPD metric relates component co nstituents to the number of integrated components. The CID metric suite relates interactions between components to the number of available interactions in the entire system. We also define a set of criticality criteria for component integration. Our proposed experimental design and the expected results are also outlined in this paper. 1

Introduction

Building large software and/or information systems is a complex and arduous task, as “best practices” have to be applied correctly in many activities during each stages of development [12]. Of the many best practices, a smart way to go about is to re-use codes and follow the adopted development methodology as closely as possible so that the development cost, time and effort are minimised. While the development methodology is usually tied to the particular one adopted within a large software house and/or project, the aim in reusing software has been to improve quality, productivity and maintainability of software [24]. While both issues have been fraught with several problems, the latter issue is the primary concern of this proposal. Thus for example as has been quoted by [5], Gartner Group predicted that by the year 2003, up to 70% of software development will reuse existing software code, but this has not happened. Modern approach to software re-use has been through Component Based Software Engineering (CBSE). Even though there is no IEEE/ISO standard definition for a component that we know of, one of the leading exponents in this area, Syzperski [26] defines software component as follows: “Software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third party”. Syzperski indirectly states that components have to be composed to work together in order to build a system. As many systems are assembled from independent components, more components will be developed by various developers. This situation will lead to the need for metrics to measure the efficiency and effectiveness of such software. The metrics helps project manager, developer, tester and anyone involved in the development of software. A set of metrics can be used to predict the cost, effort, and time to develop and testing. Metrics for software has been researched to assess quality of software development [11]. And it has been done from using the information from lines of code to the characteristic of object-oriented software. The very nature of the definition permits assembling of several hundred components to make a system without much trouble – at least in theory !. Crnkovic et al. [7] provide a good description of the relationships among components, their properties and frameworks. Furthermore, major software houses, have put in considerable effort to make a standard for software component architectures. The well-known standards include, JavaBeans [10] from Sun Microsystems, COM+/DCOM [14] from Microsoft Corporation and CCM (CORBA Component Model) [18,26,33] from the Object Management Group (OMG). CCM uses the syntax of Corba’s Component Interface Definition Language (CIDL) extensively to express the process of assembling components. As with many standards in practice, the systems designed using even the known standards still do not integrate well, primarily because of 1) the need to strictly conform to the given standard (which often may not be comprehensive) [1,2,4,5] and 2) due to the differing behavioural characteristics of components themselves [25]. The newly developed Vienna Component Framework [16] enables composition across different component standards and hence it is hoped that it will solve some of the integration problems.

The process of assembling, adapting and wiring each software component into a complete application requires comprehensive analysis, design, testing and maintenance later on. Unfortunately, one of the key limitations of the CBSE approach is the lack of suitable metrics to estimate the success or otherwise of the approach. Indeed, Lorenz and Vlissides [15] identify that the CBSE development model is different to designing with object oriented design. Sparling [25] describes how software component development lifecycle has different activities compared to just a traditional life-cycle. Arsanjani stresses the issues in development and integration of Enterprise Components [1]. Their strong conclusions are that a series of new software metrics is required for component-based development in order to facilitate predicting the effort required for each activity. This research is an attempt to build a suite of software metrics for CBSE, with particular emphasis on software component integration. Why we need the metrics and some related works for CBSE is described in section 2. Section 3 discusses the proposed metrics, which are complexity metrics, criticality metrics, our preliminary work on triangular metrics and an example of using the metrics. Section 4 contains the strategy to implement the proposed metrics including the proposed experimental design and the expected outcomes. The discussion and conclusions of the research are stated in section 5 and 6 respectively. 2

The need of metrics and related works

Reliable prediction of various aspects of the software development cycle is still a major problem in software engineering [15]. In addition, system building using software components, poses additional challenges [21], mainly because software re-use during major projects calls for special development process. For example, Ravichandran et al [19] conclude that while white box re-use is easier, black-box reuse is the best solution to systems integration. During this process, metrics are used for a variety of purposes including schedule design, complexity management, time-to-release estimation and the like in order to understand the underlying integration process. Unfortunately sometimes, the metrics to be measured are undefined and/or unclear and this is due to: 1) the rapid growth of the field to where it is right now and 2) the introduction of new technologies at a rapid pace. In CBSE, in particular, issues related to component integration plays a more pivotal role than others, as CBSE is tailored towards “integrating components towards building an actual system”. Consequently, this research will propose a suite of metrics for measuring component integration. Recent research in component metrics includes the work by Dolado [8], who validates the use of lines of code in counting the size of software for a component-based method. A component-based method is described by Verner and Tate [27] for estimating early in the software life-cycle, the number of lines of code (LOC) of a system. But the use of LOC actually depends on the language of implementation, and it is hard to predict the size of the software before the implementation. Most metrics for component-based has been developed to count the reusability of software component [11,20,28,29,30]. A larger scale of measuring the software component is discussed in [21,22,29], where they focus on the process and measurement framework in developing software components. The issue of integration problem is discussed by Sedigh-Ali et al. [22], where the complexity of interfaces and their integration is interpreted as quality metrics. Cho et al. [23] define a metrics for complexity, customisability and reusability. They count the complexity of metrics by using the combination of the number of classes, interfaces, and relationship among classes. They also combine the calculation of cyclometric complexity with the sum of classes and interfaces. Our work in this area indicates that the suite of metrics that we have defined could be of substantial use in estimating the effectiveness of the overall integration process, during the specification and design stages. As a consequence, a software developer does not have to wait until the programming stage to get any estimation. We intend to consolidate our work and validate the metrics suite through actual experimentation and analysis of the results. The suite will also integrate existing metrics available in the literature.

3

Proposed Metrics

Some disadvantages of component integration are technical difficulties during integration, performance constraint and incompatibility between different developers [21]. These problems get exasperated, when a large number of components are present in a system. The identification of complex components would make the job of component integration and testing easier. In addition, identifying critical components leads to risk reduction during the development process. Further the task of system maintenance would also get benefit from knowledge on the nature of components. Figure 1 shows a linkage between two components of system P and systems Q, where a node and an edge represent a component and link between components respectively. In this example, one could consider component B to be more complex than components A, D or X, because it has more links than the others. Therefore in one sense, B could be a critical component. On the other hand, component X may not be complex, but it is critical for the correct operation of the integrated system. Here, component X functions as a bridge between two complex components B and E. The definition for criticality does not stop here and it has other dimensions (see later). Similarly the complexity of a system depends on packaging density of components. For example, vertically connected components can be easily integrated as compared to multiply connected components. In addition, facets of components also have roles in connectivity and quality metrics. Further, dynamic characteristics of components along with their constraints can aid the design of new type of metrics for quality, management and reliability measures.

D

A

F B

D

X

E

G C

H System P

System Q

Fig. 1: Interacting Systems and Components

In order to compute the value for criticality and complexity, we have identified several conceptual views of the components and systems, based on the analysis of the static and dynamic characteristics of components. We will explore their variants on existing component-based platforms such as COM, JavaBeans or CORBA.

3.1

Components Integration Descriptions

Our definition of a software component is based on the composition of the software component itself and its relation with a software system. We define a software system as a complete application having one or more of objects, classes, modules, traditional procedural codes or operations, variables and also other components contained within it, as defined below: ::= | | || ::= | | | |

We now define several types of components as noted below: • A operation-component consists only of traditional procedures or operations; • A class-component is a component consisting only of classes; • A module-component is a component consisting only of modules*; • A super-component is a combination of components, procedure/operations, variables, and classes. *

The concept of modules is adopted from modular languages such as Modula or Ada. An Ada’s package or module, for example, can contain several classes. A detailed description of this concept can be found in [26].

Some papers [16,26] have stated a framework as part of component description. But for our purposes, a framework is just a combination of components.

3.2

Complexity Metrics for Components

From a CIDL specification, we derive Component Packing Density (CPD) metrics and Component Interaction Density (CID) metrics. The CPD metric relates component constituents to the number of integrated components. A component packing density metrics is used to identify the density of integrated components. Thus, a higher density represents a higher complexity. The CID metric relates interactions between components to the number of available interactions in the entire system. The higher number of interaction density the higher will be the interaction complexity. They are further described below. 3.2.1

Component Packing Density

The CPD metrics is in the form of a ratio of constituent to the number of components. Briefly, the relationships are identified along the lines of equation (1), where the constituents can be one or more of number of Lines Of Code (LOC), number of objects/classes, number of modules, or number of operations.

CPDconstituent _ type =

# < constituent > # components

(1)

where # is the number of lines of code, operations, classes, and/or modules in the related components. The number of constituent depends on the information that might come from the definition of component. Component developers should be asked to include such values for their component. If there is information on the number of classes for each component, we just sum up all the classes and divide it by the number of components. This equation can be applied to all component types. From the CPD metric, the following useful observations can be made: • The number shows the density of components interacting to each other. • Higher density means higher complexity, as that will make software developer to do more on impact analysis and risk assessment • The CPD value of the system could be use to predict the type of software application. For example the CPD value of business application software with a real-time system should shows different value. Business applications tend to have more components to access data, than a real time application. A list of type of applications can be found in [17] and Boehm et. al [3] have a good example between business application and real time system. For software project people, this number can be used to predict the amount of resources that further needs to be assigned in order to complete the project. 3.2.2

Interaction Density Metrics for Component Integration

Interaction among components can be characterized by the use of a component’s interface or through consuming other component’s events. In other words, interaction happens when a component provides an interface and other components use it, and also when a component submits an event and other components receive it. Under OMG’s terminology [32,33], an interface that is provided by a component is called a facet, while an interface required for a component is called a receptacle. A component that provides an interface will introduce a risk on the reliability of the interface. In addition, there is also a risk in submitting and receiving an event, as events have to be handled with care for the correct processing. This issue raises the problem of measuring the density of interaction in components. We believe that a higher density of interaction causes a higher complexity level.

We propose the metric Average Interaction Density (AID) to measure the interaction density among components in a software system. To measure AID, we define Interaction Density of a Component (IDC), which is the ratio between the actual number of interactions to the available interactions in a component. For instance, a component may provide 10 interfaces, but there could be only 5 of the interfaces used in a particular software system, in such case the value of IDC will be 0.5. The maximum value of IDC is one, which means that all the available interfaces are used. The equation is given by (2)

#I IDC =

(2)

# Imax

where I is Actual Interactions, and Imax is Maximum Available Interactions. The same idea can be used to define metrics for incoming and outgoing interaction densities in a component. Incoming-interactions are any received interface that is required in a component, and also any received event that comes to a component. Outgoing-interactions are any provided interface used and any possible source of events consumed. We propose an Incoming Interaction Density of a Component (IIDC) and Outgoing Interaction Density of a Component (OIDC). IIDC is defined as a ratio of the number of incoming interaction used to the number of incoming interaction available.

# IIN IIDC =

# ImaxIN

(3)

where, #IIN is the number of incoming interaction used, and #ImaxIN is the number of incoming interaction available. OIDC is defined as a ratio of the number of outgoing interaction used to the number of incoming interaction available.

# IOUT OIDC =

# ImaxOUT

(4)

where, #IOUT is the number of outgoing interaction used, and #ImaxOUT is the number of outgoing interaction available. Average Interaction Density of Software Components (AIDC) is a sum of Interaction Density for each component divided by the number of components, as given by (5).

AID =

IDC1 + IDC 2 + ... + IDC n # components

(5)

where, IDC1 to IDCn is interactions density for component 1 to n. #components is the number of the existing component in actual system. The value of IDC, IIDC, and OIDC are used to count the complexity of interactions within an individual component. These values yield the complexity level for a component in complete software system. For complexity level of the whole software system, we use the value of Average Interaction Density (AID). For software developers, the value of IDC, IIDC and OIDC will be useful to examine the density of interactions within the component. A component with high value of density indicates the need to employ high quality professionals to do the design. The value of AID will be valuable to assess the whole system interaction. The low value of AID indicates a simple system, which also means lower effort to do the software risk analysis.

3.3

Criticality Metrics for Component

Critical component sometimes exists in software. For example in figure one, a bridge is a critical component. Critical component is to be identified as early as possible by software developer. For a software tester this component requires substantial testing effort. Every possible scenarios for this critical component has to be tested, particularly if it is a base component, in which wrong operations can be inherited by the subcomponents. In this research, we propose a metric to identify the critical components. We characterize some circumstances that make a component to be called critical. They are: • Link Criticality: Link Criticality is defined as a condition in which a component has many links to other components. The use of facet interface by other component creates a link to that other component. The more facet used, the more critical the component will be. • Bridge Criticality: Bridge Criticality is defined as a state in which a component acts as a bridge between two components or applications. It could be a potential problem, if this component is malfunction. • Inheritance Criticality: Inheritance Criticality is defined as a condition in which a component becomes a base for other inherited component. • Size Criticality: Size Criticality is defined as a condition in which the size of component might induce a problem. The bigger software volume, the more error will be found during the development stage. Based on those conditions, we propose a set of metrics to identify the criticality of components. • For Links Criticality, we sum the number of links connected to a component. A component will be called critical if the number of links has reached a certain threshold value. CRITLINK =# links (6) • For Bridge Criticality, we have to identify a component that functions as bridge. We can set up an incidence matrix, which contains components and their links information. An importance weight value should be put for each links. A software developer will responsible for giving this number for each links. A likely become bridge component will be marked higher than others. • For inheritance criticality, the relevant information can be obtained from the inheritance tree. • For size criticality, we count the number of lines of code, modules, operations or classes, and check if the value has exceeded a certain threshold value. (7) CRITSIZE =# constituent where #constituent can be LOC, the number of operations, the number of classes, or components (for super-component). By knowing this critical number, a software developer will get a better understanding of which component face higher risk than other components, and then an optimized resource allocation can be deployed for that critical component. This critical number is an indication of the risk associated with the component. For a software tester, critical component needs to be exhaustively tested. 3.4

Triangular Metrics (Preliminary work)

Based on CPD, AID and Critical metrics, we proposed another new metrics, which is the combination of them. The three metrics actually have different point of view. Component Packing Density is calculated from the density in the integrated components. Average Interaction Density comes from density of interaction within an integrated component. Both are representing the complexity of the system. The last metrics is based on the criticality of the component. For complexity metrics, we can combine them into two-axis diagram of density as drawn in figure 2.

Component Interaction Density

Component Packing Density

Fig. 2: Two axis of component complexity By examining their value, we deduct some possibilities to state the characteristic of the software, as the following: 1. A low value of CPD and a low value of CID: This might represent just a simple software application, which does not have many components in it and has low interaction, which might describe a low transaction processing. 2. A low value of CPD and a high value of CID This condition might happen within the system, which has low data processing, and high computation, such as a real time system. 3. A high value of CPD and a low value of CID This condition might suggest a transaction processing system, which usually has high volume of data processing, which should need many components and this kind of system usually has low interaction among components. 4. A high value of CPD and a high value of CID This condition represents a very complex system, which might has many classes or constituent within components, and high interactions among components. Diagrams in figure 3 illustrate these characteristics.

Fig. 3: Four possible values of CPD and CID

We can actually combine the packing and interaction density with our proposed critical metrics. The critical metrics is actually more component specific. Link Criticality, Size Criticality, Bridge Criticality and Inheritance Criticality are used to locate which component has higher critical value than others. For the whole system point of view, intuitively we can just sum up all the value, to obtain the critical numbers of the system. And finally we combine them into the three-axis diagram, as shown in figure 4.

Component Interaction Density

Component criticality

Component Packing Density

Fig. 4: Three axis of component complexity and criticality

By using the characteristic of the software that comes from the complexity condition as described above, we can further describe how critical a software is. A real-time system usually has higher criticality compared to just a transaction-based system. Our work in this triangular metric is still in early stage of work. There are no defined low and high values of densities and criticality. Most of the characteristics that are described above are still in our hypotheses, which should be tested by further investigation.

3.5

An example: PDA (Personal Digital Assistant)

We illustrate the importance of the proposed metrics through the evaluation of PDA (Personal Digital Assistant) software. A Personal Digital Assistance (PDA) has three main components. The first component is called DateBook which is used to record activities by their time and date. An activity can be a plan to meet with someone, a thing that should be done, or just a journal of a day. The second component is an AddressBook, which records the name, address, phone number, and other personal or company’s information. The third component is a TodoBook, which records activities and its deadline in the future. Each component is linked to the other by a usage linkage. Arranging a time and date of a meeting with somebody requires link to AddressBook. We can use this link if we plan to have a meeting with somebody that is recorded in AddressBook. TodoBook provides a deadline for DateBook. This code below is written in CIDL pseudo code. Module PDA { Interface Daily{ void viewDayList(); } Interface Weekly { void viewWeeklyList(); } Interface Monthly { void viewmonthlyList(); } Interface Note { void viewNote(); } Interface Address { void ListAddress(); void SearchAddress(); } Interface DateOfBirth { void ListDoB(); } Interface TodoList { void ListTodo(); }

component DateBook { provides Dayly dayly; provides Weekly weekly; provides Monthly monthly; provides Note listnote; uses Address address; uses TodoList todolist; } component AddressBook { provides Address address; provides DateOfBirth dateofbirth; } component TodoBook { provides TodoList todolist; } }

We can see the linkage between components clearly in figure two.

Address

DateOfBirth Daily

AddressBook

Address

Weekly

Monthly

TodoList DateBook

Note

TodoList

: Facet

TodoBook

: Receptacle

Fig. 5: Diagram view of linkage between components in PDA

From the linkage we can derive the metrics value as the followings: •

DateBook has 4 operations (procedures), AddressBook has 3 operations, and TodoBook has 1 operations, so the Component Packing Density 1 is calculated using operations constituent. CPDOPERATION = 8/3 = 2.33

DateBook has 6 available interactions (4 facets and 2 receptacles), they are Daily, Weekly, Monthly, Note, Address and TodoList interface. And there are only Address and TodoList interface, which are interact with other components. AddressBook has 2 available interfaces, and only one is used, where TodoBook has 1 used interface out of 1 available interface. IDCDATEBOOK = 2/6= 1/3 = 0.33 IDCADDRESSBOOK = 1/2 = 0.5 IDCTODOBOOK = 1/1=1.0 DateBook has 2 receptacles available for incoming operation from interface, in which both are used. Addressbook has no receptacles, and also TodoBook. IIDCDATEBOOK = 2/2=1.0 IIDCADDRESSBOOK = 0.0 IIDCTODOBOOK = 0.0 DateBook has 4 facets, and none is used, AddressBook has 2 facets, which one is used, and TodoBook has 2 facet which both are used.

OIDCDATEBOOK = 0/4=0.0 OIDCADDRESSBOOK = 1/2 = 0.5 OIDCTODOBOOK = 2/2=1.0 By using equation 7, the Average Interaction Density is AID=(1/3+1/2+1)/3=11/18 = 0.61 For criticality of the PDA, we say that: 1. 2. 3.

For component DateBook, AddressBook, TodoBook, we have CRITLINK= 2, CRITLINK= 1, and CRITLINK= 1 respectively. We must have a certain threshold number to say if a component is critical. In this research, we have not had the number yet. With the example given, it is not applicable to examine the inheritance and bridge criticality, but size criticality can be counted by examining the number of operations. For DateBook, AddressBook, and TodoBook, we count CRITSIZE=4, CRITSIZE=3 and CRITSIZE=1 respectively. We can say that DateBook is more critical than AddressBook and TodoBook. To say if it is critical component, we need a threshold value, which we don’t have it at this stage.

Our work on triangular metrics is still in early stage. We do not provide an example for it at this paper. 4

Implementation Strategy

The metric suite can also be applied at the stage of specification and design. In CBSE, one is expected to plug the component onto the system, but before plugging, a component integrator needs to obtain the name of components and their interfaces. After all the components have been gathered, the next step is to connect the components to each other. The organisation of the components can be designed using a special language like CIDL (Component Interface Definition Language). A special program, called the Metrics Extractor Engine (MEE), extracts the metrics from a CIDL source code. Specifically MEE performs the following activities: • Parse the CIDL source code and get the components definitions (namely components name, usable interface ports, required interface ports, event produced ports, and event sink ports. Place them on a list of components. Get information if the ports are used or unused from CIDL source code. The parsing process will also record the base components from the source code. • Set up an incidence matrix, which contains components and their links information. Input an importance weight value for each links. This value will be important to find whether integrated components have bridge criticality. A critical link should have high importance value. With our current research, we have to give this value intuitively. • Input the type of the component, which can be done by finding the information from component description. As an example for operation-component, we should have the number of procedures or operations inside a component. This information will be used to calculate a packing density metrics. • For each links, give descriptions on facet that is used by a component. This description will be use to count interaction density metrics. The metrics values will be stored in a Metrics database, using XML format. Figure 3 shows the global process of extracting the metrics. The stored metrics can be utilised by other program such as an effort and time prediction program. These programs are essential for project management software, which take into account the complexity and criticality of integrated component.

Code in CIDL Format

Metrics Extractor Engine

Metrics Database

Effort Prediction

Time Prediction

Fig. 6: Metrics Extractor Engine

4.1

Proposed Experimental Design

We will validate the metrics using the properties mentioned by Weyuker [29], so that the proposed metrics do not violate properties of measurement theory. There will be nine properties that should be tested, which have been used to validate the OO metrics done by Chidamber and Kemerer [5]. We propose a design scenario to empirically validate the metrics, which will be used to verify if the metrics value is consistent with some predicted values. For complexity metrics and criticality metrics, we proposed to set up a CIDL file with n components and m links, where n will be greater than 10 and m will be greater than 20. This value is defined intuitively, as we thought such number is enough for this design. A tool to automatically measure the values of the metrics will be developed. The tool calculates the number of complexity and criticality in the design of integrated components. A metrics’ value without limitation or specified interval is not usable. We should define an interval number or a threshold value for the specific item of the metrics. To have the interval number or the threshold value, we proposed to do activities below: • Define an environment for testing the metrics. Currently CIDL is the option of component-based integration scheme. So we propose a CORBA environment to be set up, but an MS-DCOM would also possible. • Data collection: Data is gathered from an academic project and industry if possible. The project should have enough documentation on specification and have CIDL in the design. We will run the Metrics Extractor Engine against their CIDL design. • Analyse the result using method as follows 1) define a model from collected of data, and eliminate the extreme cases 2) validate the model in new other subset (for tuning the model), if the number of data is large enough. Finally, there could be three subsets of data, the first is for building the model, the second is for tuning the model and the third is for evaluation of the equations. This method of analysis has been done by [6]. The data relationship will be put on linear regression model using a classical statistical analysis.

4.2

Expected Outcome

The metrics measure the complexity and criticality of the integration of components. It is intended to aid CBSE developers. By recognizing the complexity and criticality of the design, it would be a good information for developers to predict the effort to finish an integrated component. Software tester can have detail information about which components should be stressed tested based on its complexity and criticality. Empirical evaluation of the metrics suite should be done so that the user confidence of the metric suite can be established. The use of software prototype of the metrics generator based on CIDL should help measuring of the integration. It is expected that the metrics can be used to: • Find the critical and complex part of the component. The measurement result will indicate which component is critical than others, and which is more complex than others. Some threshold values could be used to indicate if a component need more considerations than others;

• • • 5

Measure the degree of the complexity and criticality of a system, and later on can be used to classify the software system; Derive a mechanism/formula to predict time and effort required to develop a system using integrated components from industry data. We also hope to gather some feedback on the metrics from software designers and testers in less than 6 months after they use the metrics.

Discussion

The metrics proposed in this paper can be used to identify the complexity and criticality of the metrics. By recognizing a complex and/or critical component, it should give a contribution on the effort and cost estimation. This information should help a software project leader to estimate better. The parsing of metrics from the description of CIDL makes possible to visualize the component in a special visualization system. A special program will identify the components and their links. Each component can be transformed to a node, and the interface used is displayed as a link between nodes. A project manager can view the components relationship by examining the component graph. The system should give a good pictures’ description and show the user the complexity and criticality number for each components. The metrics suite can also be incorporated in a CASE (Computer Aided Software Engineering) tool. CASE tool helps designer to built the software. A component-based CASE tool can include the metrics suite for helping the developer in designing the software. The developer can get an insight of which component has high complexity or risking the criticality. Object Constraint Language (OCL) is another related standard, which describes constraints in analysis and design by using Unified Modelling Language (UML). OCL can be embedded on the component model as an added constraint to system building. Adding the constraint in the proposed metrics could yield another method of measuring CBSE software development. Our triangular metrics is still in our early research. Much work on data collection has to be done to test our hypotheses. 6

Conclusion

This research has proposed a set of metrics suite to be used in software component integration. We believe these metrics is based on a measurement theory, but it has to be validated first with some properties of software metrics. We hope that these metrics would help component-based developer (and integrator) to identify the level of complexity and criticality of a component in integrated software system. By understanding this level it can be used to predict time and effort. We have also proposed an experimental design to validate the metrics theoretically and empirically. We expect by gathering real data and analysing it, some useful results can be produced by using this metrics. A further study of complexity and criticality on software component metric should help provide a basis for significant future progress.

7. References 1. Ali Arsanjani, "Developing and Integrating Enterprise Components and Service", Communication of the ACM, Vol. 45, No. 10, October 2002. 2. Fernando Berzal, Ignacio Blanco, Juan-Carlos Cubero, Nicolas Marin, "Component-based Data Mining Frameworks", Communications of the ACM, Vol. 45, No. 12, December 2002. 3. B. Boehm, C. Abts, A. W. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B.Steece, Software Cost Estimation with COCOMO II, Prentice Hall, 2000. 4. Lisa Brownsword, Tricia Obendorf, Carol A. Sledge, "Developing New Processes for COTS-Based Systems", IEEE Software, July/August 2000. 5. A.W. Brown, "Large-Scale, Component-Based Development", Prentice Hall, 2000. 6. S.R. Chidamber and C.F. Kemerer. "A Metrics Suite for Object-oriented Design", IEEE Transaction on Software Engineering, Vol. 20 No. 6, June 1994. 7. Ivica Crnkovic, Brahim Hnich, Torsten Jonsson and Zeynep Kiziltan, "Specification, Implementation, and Deployment of Components", Communications of the ACM, Vol.45, No. 1 8. Jose Javier Dolado, "A Validation of the Component-Based Method for Software Size Estimation", IEEE Transactions on Software Engineering, Vol. 26, No. 10, October 2000. 9. R. Dumke, A. Winkler, "Managing the Component-Based Software Engineering with Metrics.", Proc. of the 5th International Symposium on Assessment of Software Tools (SAST ), 1997. 10. R.Englander, "Developing Java Beans", O'Reilly Publ., 1997. 11. Norman E. Fenton and Shari Lawrence Pfleeger, "Software Metrics: A Rigorous & Practical Approach 2nd edition", PWS Publishing Company, 1997. 12. W. Frakes and C. Terry, "Software Reuse: Metrics and Models", ACM Computing surveys, Vol. 28, No. 2, June 1996 13. Katsuro Inoue et. al, "Component Rank: Relative Significance Rank for Software Component Search", Proceedings of the 25th International Conference on Software Engineering, 2003. 14. B. Kitchenham, S.L. Pfleeger and N.Fenton, "Towards a Framework for software Measurement Validation", IEEE Transaction on Software Engineering., vol.21, no.12, pp.929-944, 1995. 15. David H. Lorenz and John Vlissides, "Designing Components versus Objects: A Transformational Approach", Proceedings of the 23rd international conference on Software engineering, pp. 253-262, 2001. 16. Oberleitner, Gschwind, Jazayer, "The Vienna Component Framework Enabling Composition Across Component Modles", Proceedings of the 25th International Conference on Software Engineering (ICSE’03), 2003. 17. Putnam, L. and Myers, W. Industrial Strength Software. Effective Management Using Measurement, IEEE Computer Society Press, 1997. 18. Rastofer, and F. Bellosa, "Component-Based Software Engineering for Distributed Embedded RealTime System", IEE Proceeding Software, Vol 148, No. 3, June 2001. 19. T. Ravichandran and Marcus A. Rothenberger, "Software Reuse Strategies and Component Markets", Communications of the ACM, Vol. 46, No. 8, August 2003. 20. Schmietendorf, R. Dumke, E. Foltin, "Metrics Based Asset Assessment", ACM Sigsoft Software Engineering Notes, Vol 25, No 4, July 2000, pp 51 21. Sahra Sedigh-Ali, Arif Ghafoor, Raymond A. Paul, "Software Engineering Metrics for COTS-Based System", IEEE Computer, 2001, pp 44-50. 22. Sahra Sedigh-Ali, Arif Ghafoor, Raymond A. Paul, "Metrics Guided Quality Management for Component-Based Software System",25th Annual International Computer Software and A 23. Eun Sook Cho, Min Sun Kim, Soo Dong Kim, "Component Metrics to Measure Component Quality", The 8th Asia-Pacific Software Engineering Conference (APSEC), 2001. 24. J. Sodhi and P. Sodhi, "Software Reuse, Domain Analysis and Design Process", McGraw-Hill, 1999. 25. Michael Sparling, "Lesson Learned: Through Six Years of Component-Based Development", Communications of the ACM, Vol. 43, No. 10, October 2000. 26. Clemens Syzperski, "Component Software: Beyond Object-Oriented Programming", Addison Wesley, 1998. 27. J. Verner and G. Tate, "A Software Size Model", IEEE Transaction on Software Engineering, Vol. 18, No. 4, April 1992.

28. P. Virtanen, P, "Empirical Study Evaluating Component Reuse Metrics", Proc. of the ESCOM 2001, April 2001, London, pp. 125-136. 29. H. Washizaki, H. Yamamoto, Y. Fukazawa, "Software Component Metrics and It's Experimental Evaluation", Proceeding of International Symposium on Empirical Software System, 30. H. Washizaki, H. Yamamoto, Y. Fukazawa, "Metrics Suite for Measuring Reusability of Software Components", 9th International Software Metrics Symposium, 2003. 31. E.J. Weyuker. "Evaluating Software Complexity", IEEE Transaction on Software Engineering, Vol 14, No. 9, pp. , Sept. 1988. 32. -."Corba Components", OMG formal document 02-06-05, Version 3.0, June 2002. 33. OMG CCM Implementers Group, "CORBA Component Model Tutorial", MARS PTC & Telecom DTC OMG Meeting, Yokohama, Japan, April 24th, 2002.