1. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
TECHNOLOGY (IJCET)
ISSN 0976 – 6367(Print)
ISSN 0976 – 6375(Online)
Volume 5, Issue 2, February (2014), pp. 40-45
© IAEME: www.iaeme.com/ijcet.asp
Journal Impact Factor (2014): 4.4012 (Calculated by GISI)
www.jifactor.com
IJCET
©IAEME
MEASURING COMPLEXITY THROUGH DEPENDENCY ANALYSIS FOR
COMPONENT-BASED SOFTWARE SYSTEMS – A UML APPROACH
Priyanka Bansod,
Jawwad Wasat Shareef, Jitendra Kumar Maitra
(Department of Mathematics & Computer Science, Rani Durgavati University, Jabalpur, India)
ABSTRACT
The software engineering community has put considerable efforts into the design and
development of component based software system (CBSS) in order to manage the software
increasing complexity and to maximize the reuse of code. The Component based systems (CBS) are
built up by integrating a number of these components in the system thus known as component
assembly. This paper presents modeling of component-based systems using open source software
UML tool like ArgoUML, for measuring the complexity and detecting dependencies among
components. The interaction densities and dependency level of an individual component and for the
system are analyzed. The detection of dependency among components and their complexity
measures helps the system analyst and designers to identify fault-prone components and associated
interactions; so that faults that are to occur at later stage can be detected at early stage, saving time
and financial loss. The complexity measures guides them as to where they should concentrate their
testing efforts, resulting in a reliable Component-based system.
Keywords: Component, Component Based System (CBS), Dependency, Interaction, Supplier,
Unified Modeling Language (UML).
1.
INTRODUCTION
The core of component based software system (CBSS), is known as component based
software engineering (CBSE). The term CBSD is an appropriate and methodical approach, which
involves the construction of an application by using prebuilt chunks, which were developed at
different times, by different humans, and possibly with different concepts and uses in mind [1]. As the
components are integrated in a system, more and more interaction between these components exists in
the system. These interactions among the components happen through their interfaces known as
provided or required interface. In other words, interaction happens when a component provides an
40

2. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
interface and other component uses it, interaction may take place in the form of event also, when a
component submits an event and other components receive it [2]. Often building and installing a new
software package requires updates to a series of other components as well [3]. Understanding and
tracking dependence relationships among components is increasingly difficult in large and complex
systems. The problem is intensified since CBS encompasses both components developed in-house and
components made available by a third party (e.g. COTS), often deployed with insufficient
documentation [4]. These metrics enable a system analyst to better understand the factors affecting
complexity of a CBSS and provide a mechanism for identifying complex components. This is
important as towards the latter stages of a CBS life cycle, complexity numbers can guide an analyst in
the allocation of resources to the testing and maintenance phases. In CBS, complexity not only
depends on the individual components but also on the underlying architecture and the integration
process. To measure the complexity of a UML CBSS, it is not practical to only consider one of the
attribute of a CBS affecting its complexity. Therefore, to have a reliable CBSS complexity measure, it
is necessary to identify and appropriately measure in detail each factor affecting its complexity.
CBSD approach in the present scenario is the most reliable and successful one. This approach is
different from the traditional approach. These commercial off the shelf (COTS) components can be
developed by different developers using different languages and different platforms, where COTS
components can be checked out from a component repository, and assembled into a target software
system. Component based software development (CBSD) can significantly reduce development cost
and time to market, and improve maintainability, reliability and overall quality of software systems.
The pressure for reducing software development life cycles and costs has lead to an increasing interest
in CBSS that not only facilitates the process of software development but also changes the ways to
develop software applications. With time CBSS is getting accepted in the industry as a new effective
software development paradigm [5]. Most of the CBSS research has been inclined towards methods
and approaches in the development and in comparison of software systems [6].
2.
DEPENDENCY ANALYSIS FOR COMPONENT BASED SYSTEMS
Dependency analysis involves the task of identifying the interdependent components of a
system. In component based systems, components communicate and share information in order to
provide system functionalities. Components are regularly composed for the purpose of offering more
abstract services in a system. This composition creates interaction that promotes dependencies among
components. Replacing a new version of a specific component or updating might involve replacing
the component(s) on which it depends, in order to preserve a specific system’s functionality. The key
point to analyze those aspects is the knowledge about possible component relations and dependencies
among them [7].
Dependency analysis provides benefits to the developers, administrators and maintainers in
providing useful information related to system and its maintenance. For a CBS it is essential to
identify dependencies among components, which not only helps in distinguishing causes of potential
problems, but also helps to understand which parts can be affected by the development, where more
attention and testing of components is required. There have been number of cases in CBS where
dependence relationships among components have been neglected during the system’s evolution [4].
3.
INTERACTION METRICS FOR COMPONENT BASED SYSTEMS
Various interaction complexity measures for the component based systems in the form of
metrics have been proposed, these are as follows
41

3. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
3.1
For Individual component
Incoming and outgoing interaction density can be measured for a component. The dependent
components on a parent component can also be identified. Interaction densities may be used to
measure the integration efforts for the system. These interaction of components in UML are coded
(UML:Dependency.client) and (UML:Dependency.supplier).
3.1.1 Interaction Density
Interaction Density (ID) for a component can be measured as the sum of incoming interactions
(required interface) and the outgoing interactions (provided interface).
3.1.2 Incoming Interaction Density
Incoming Interaction Density (required interface) (IID) for a component C can be measured as
the ratio of Used Incoming Interactions (UML: Dependency.client) UII (C) to the Available Incoming
Interactions (sum of UML: Dependency.client for component C) AII (C).
AII (C) and UII (C) can be measured as:
AII (C) = Sum of all provided services of Parent Components of C
(sum of UML: Dependency.client for Component C)
UII (C) = Sum of all required services for Component C
(number of UML: Dependency.client for component C)
Therefore:
௎ூூሺ஼ሻ
‫ ܦܫܫ‬ሺ‫ ܥ‬ሻ ൌ ஺ூூሺ஼ሻ
(1)
Equation (1) may be used to measure the integration efforts for that individual component.
Higher value of IID results in complex integration efforts, which will increase the maintenance
efforts.
3.1.3 Outgoing Interaction Density
Outgoing Interaction Density (provided interface) (OID) for a component C can be measured
as the ratio of Used Outgoing Interactions (UML: Dependency.supplier) UOI (C) to the Available
Outgoing Interactions (sum of UML: Dependency.supplier for component C) AOI (C).
AOI (C) and UOI (C) can be measured as:
AOI (C) = Sum of all provided services of Component C
(sum of UML: Dependency.supplier for component C)
UOI (C) = Sum of all required services of child Components of C
(number of UML: Dependency.supplier for component C)
Therefore:
௎ைூሺ஼ሻ
ܱ‫ܦܫ‬ሺ‫ ܥ‬ሻ ൌ ஺ைூሺ஼ሻ
(2)
Equation (2) may be used as a measure of usability of components in the system. Higher value
of this metric, result in higher possibility of using this component by other child components, which is
an indication of high dependability of this component within the system. Also, it may be used for
42

4. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
0976
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
Feb
measuring the service utilization. If all the provided interfaces of a component are utilized by other
dependent components then it may be termed as efficient component in terms of service utilization.
terms
On the other hand, if some of the provided interfaces are not used by any of the dependent
components, it means that the functionality provided by the component is not fully utilized by other
components [8].
3.1.4 Dependency Level
Dependency Level (DL) of a component is the sum of all the child components of C.
endency
DL (C) = Sum of child components of C
(3)
Equation (3) can be used to identify the critical components and isolated components in the
system. Highest value of DL will be referred as the most critical component of the system. Any
referred
change in this component may require several possible changes in other dependent components also.
On the other hand, 0 dependency level for a component means an isolated or independent component.
It can accommodate any change without affecting other components of the system.
syst
4.
ArgoUML: A TOOL FOR COMPONENT MODELING
A UML Model of simple component based system is shown in Figure 1.
base
The components are drawn in ArgoUML modeling tool created through Deployment diagram
option. There are total four components named C1, C2, C3 and C4 in the system, these components
are dependent on the other components and are denoted by dependencies D1, D2, D3, D4, D5, D6 and
D7. Some components are having incoming interactions, referred as (UML: Dependency.client) and
interactions,
some are having outgoing interactions, referred as (UML: Dependency.supplier). Some of the
components exhibit both incoming and outgoing interactions.
In Figure 1 component C1 is dependent on three components C2, C3 and C4 which is shown
components
by D2, D1 and D3 as dependency. Component C2 is dependent on two components C1 and C4 which
is shown by D4 and D5 as dependency. Similarly component C4 is dependent on two components C2
and C3 which is shown by D6 and D7 as dependency.
Figure 1. CBS Modeled In ArgoUML Having Four Components C1, C2, C3, C4 and Seven
Components
Dependencies D1, D2, D3, D4, D5, D6, D7.
ependencies
43

5. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
The dependency of Component based system for individual components are calculated from
Figure 1 through Interaction Metrics which is shown in TABLE I are as follows:
TABLE-I: Dependency Metrics Values Calculated From Figure-1 for Individual Component
Component
Interaction
Density (ID)
Incoming
Interaction
Density (IID)
Outgoing
Interaction
Density (OID)
Dependency
Level (DL)
C1
4
1
3
3
C2
4
2
2
2
C3
2
2
0
0
C4
4
2
2
2
Here based on the measurements given in TABLE I following predictions can be made:
•
•
•
•
•
•
5.
The Interaction Density (ID) of component in a component assembly as in TABLE I shows
both incoming interactions and outgoing interactions of components, as in TABLE I, C1, C2
and C4 are having maximum interactions and C3 is having only two incoming interactions.
The Incoming Interaction Density (IID) for component C2, C3 and C4 are equal as in
TABLE I which means these three components are performing equally important part in
component assembly, whereas component C1 has only one incoming interaction.
The Outgoing Interaction (OID) for Component C1 is high, which indicates the higher
possibility of using the component C1 by other components C2, C3 and C4, which is an
indication of high dependability of the component C1 within the system.
The Components C1, C2 and C4 are fully utilized by their respective child components.
The Dependency level (DL) of component C3 is minimum i.e., 0, thus if any changes are
done in component C3, it will not affect other components.
The Dependency level of component C1 is maximum i.e., 3, which means this component is
more critical, any changes made to this component will affect other components also.
CONCLUSION
The present work consists of a UML based approach in which components can be modeled to
design component based systems using ArgoUML to represent dependency among components. In
this paper we measure the interaction complexity of components and of the system. Different metrics
related with interactions among components are discussed to trace the incoming and outgoing
interactions. By this approach the minimum dependency level does not affect other components, thus
other components will remain unchanged. The information may be used to analyze several
interactions and dependency related issues.
44

6. International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 2, February (2014), pp. 40-45 © IAEME
6.
REFERENCES
[1]
J.W. Shareef, Component-Based Software Development: An Appropriate and Methodical
Approach. International Journal for Electro Computational World Knowledge Interface, Vol.
1, Isssue 5, ISSN No. 2249-541X, 2012.
[2] V.L. Narasimha and B. Hendradjaya, A New Suite of Metrics for the Integration of software
Components, 1st International Workshop on Object Systems and Software Architectures
(WOSSA’2004), S. Australia, 34-39.
[3] F. Kon and R.H. Campbell, Dependence Management in Component-based Distributed
Systems, IEEE Concurrency, Vol. 8, Issue 1, 2000, 26-36.
[4] M. Vieira and D.J. Richardson, Analyzing Dependencies in Large Component-Based
Systems, Proceedings of the 17th IEEE International Conference on Automated Software
Engineering, Edinburgh, UK, 2002, 241-246.
[5] V.P. Venkatesan and M. Krishnamoorthy, “A Metrics Suite for Measuring Software
Components”, JCIT, Voi. 4, No. 2, 2009, 138-153.
[6] S. Jing and C. Jiang, “An Approach to Predict Performance of Component-based Software
with the Palladio Component Model and Stochastic Well-formed Nets”, AISS, Vol. 2, No. 1,
2010, 31- 42.
[7] N.S. Gill and Balkishan, Dependency and Interaction Oriented Comp-lexity Metrics of
Component-Based Systems, ACM SIGSOFT Software Engineering Notes Vol.33 Issue 2,
2008, 1-5.
[8] Arun Sharma, Rajesh Kumar and P.S. Grover, Dependency Analysis for Component-Based
Software Systems, accepted for publication in ACM SIGSOFT Software Engineering Notes,
Vol. 34, Issue 4, July 2009, 1- 8.
[9] Sonar Sanjay Bhagwan and Dr. Samrat O. Khanna, “A UML Model for Automation of
Counseling System using Pure Object Oriented Approch”, International Journal of Computer
Engineering & Technology (IJCET), Volume 4, Issue 5, 2013, pp. 15 - 22, ISSN Print:
0976 – 6367, ISSN Online: 0976 – 6375.
[10] Dr. Harsh Dev, Rajeev Kumar, Gaurav Kumar and Suman Kr. Misra, “Location Based
UML Development- A Uml Based Modeling for Usage of Location Based Services”,
International Journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 5,
2013, pp. 194 - 203, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.
45