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 life-
cycle 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 X E
D
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:
<Software System> ::= <modules> | <classes> | <operations>|<variables>| <component>
<component> ::= <component> | <modules>| <classes> | <operations>|<variables>

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.
# < constituent >
CPDconstituent _ type =
# components (1)
where #<constituent> 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 = (3)
# ImaxIN

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 = (4)
# ImaxOUT

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).
IDC1 + IDC 2 + ... + IDC n (5)
AID =
# components
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.
CRITSIZE =# constituent (7)
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 Packing Density

Component
criticality

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 AddressBook

Daily
Address
Weekly
TodoList
Monthly DateBook

Note

TodoList
TodoBook
: Facet

: 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. 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.
2. 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.
3. 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 Metrics
Format Extractor
Metrics
Engine Database

Effort Time
Prediction 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;
 • 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.

5 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 Real-
Time 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.