Component Based Architecture -New Paradigm for Software Development

Thayalan Guhathashan and Rajan Raghuraman

{tg1e08, rr12g08}@ecs.soton.ac.uk

MSc in Software Engineering

School of Electronics and Computer Science
University of Southampton

Abstract This short review paper presents
Component based Architectures (CBA), which is
a new approach for software engineering tasks,
which can be adopted in many areas.
Component-based software development is
associated with a shift from traditional system
building using set of coding to system building
by plugging together components.
1. Introduction
In the changing world, component-based
software technology is becoming an
increasingly popular approach to facilitate
the development of evolving systems. The
objective of this technology was to take
elements from a collection of reusable
software components (i.e. components-off-
the shelf-COTS packages) and build
applications by simply plugging them
together. Hence, it aimed at the production
of high-quality software systems with
shorter and more cost-effective development
cycles. By reconfiguring components,
adapting existing components, or
introducing new components it was hoped
that applications could be adapted to
changing requirements of real-world
software systems more easily and address
the problems of object-oriented development
approaches [5, 7].
2. Overview
The core of the CBA is the components and
their interaction. Industry’s shift to CBA is a
new enterprise architecture model for
delivering applications. CBA has made a
tremendous amount of interest in the IT
world because of the continuing integration
problems of the Enterprise applications. IT
organizations everywhere have jumped on
the CBA in hopes that it might finally ease
the IT planning burden. But it is not that
easy [5].
The main drive behind component
technology was reusability. Applications
can be built simply by simply plugging
existing reusable software components
together
However, reusability was not the only drive
behind component technology: independent
evolution of application parts, enhanced
flexibility, adaptability, and maintainability
of software systems, higher-level of
application development than “classical”
programming paradigms can be achieved
through the CBA.
3. OOP & Component based Technology
Theoretically object-oriented programming
(OOP) languages, analysis and design
methods would provide a well-suited tool-
box for component-based application
development, but practice showed that the
technology was often applied in a way that
contradicted the goals behind component
technology.
Object-oriented analysis and design methods
are domain-driven, which usually leads to
designs based on domain objects. Most of
these methods make the assumption that an
application is being built from scratch, and
they incorporate reuse of existing

-1-
architectures and components too late in the being violated. In addition, changing
development process [4]. framework classes often implies extensive
modifications of application-specific code
In order to successfully plug components [4].
together, it is necessary that the interface of
each component matches the expectations of
the other components and the “contracts”
between the components are well-defined.
Therefore, component-based application
development depends on adherence to
restricted, plug-compatible interfaces and
standard interaction protocols. However, the Figure 1Object-orientation versus component
result of an object-oriented analysis and ware [7]
design method generally is a design with Figure 1 illustrates the problems associated
rich object interfaces and non-standard with the object-oriented paradigm.
interaction protocols [4]. Classes/objects implemented in one
programming language cannot interoperate
Object-oriented programming languages with those implemented in other languages.
have been very successful for implementing Some object-oriented languages even
and packaging components, but they only require the same compiler version.
offer limited support for flexibly of Furthermore, composition of objects is
connecting components and explicitly typically done on the language level.
representing architectures in applications. Composition support is missing, that is,
visual/ interactive tools that allow the
Given the source code of an object-oriented plugging together of objects [7].
application, one can more easily identify the
components, but it can be extremely difficult
Objects Components
to tell how the system is composed. The
reason is that object-oriented source code Bound to OO language Can be written in any
exposes class hierarchies, not object (C++, Smalltalk) language
interactions. In addition, the way objects are Tight couplings More loosely coupled
interconnected is typically distributed (implementation than objects (Interface
amongst the objects themselves, which inheritance) inheritance)
hinders a clean separation between Functional
computational and compositional aspects Aggregation
needed for component-based development Fine granularity in Larger granularity
[4].Although object-oriented applications object decomposition
can often be adapted to additional
requirements with a minimal amount of new Limited forms for Interface oriented
accessing (methods)
code, it can require a great deal of detailed
study in order to find out where exactly the No Mechanism for Mechanism for
extension is needed. Unfortunately, object- runtime discovery runtime discovery
oriented frameworks do not make their No common Designed to obey
generic architecture explicit, which results in framework rules of a common
a steep learning curve before a framework framework (.NET,
can be successfully used. Since object- CORBA, COM)
oriented frameworks focus on sub classing No binary specification Has a binary
of framework classes (also known as white- specification allowing
box reuse), a detailed understanding of the run-time discovery
generic architecture is needed in order to and reuse
prevent contracts between two classes from Table 1- Difference between Objects and
Components.

-2-
The above mentioned table 01 lists the
major differences between components and As a consequence, standards for describing
objects. We can decide whether they are components have been established. The
revolutionary or evolutionary component (module) interface is described
either
Briefly we can say OOP concept is having
• Textually by means of an interface
lack in functionality, interaction, quality,
description language (IDL), or
management, evaluation tools and
• Visually/interactively by means of
methodologies.
appropriate tools.
The significant factors of CBA are
In OO languages, several classes (fine-
independent extensions, component markets,
grained components) typically form one
reduced time to market and improved
coarse-grained component (see Figure 2).
predictability [10].

4. Component Based Software

Development

4.1 Components in module-oriented

languages

Components expressed in module-oriented

languages can only be reused in another
project exactly in the same way as the
module was originally designed. Otherwise
the source code or even its interface has to
be changed. This leads to the creation of
multiple versions. Component testing must
be repeated.
4.2 Components in object-oriented
languages
In order to overcome some reuse problems
of module-oriented languages, object
oriented languages introduce language
constructs to achieve delta changes
(programming by difference) without having
to touch the source code of original
modules/classes. Inheritance is central to
this solution [7].
Figure 2 Granularity of components [7]
5. Component Models
From an industrial view of point , various
component models were defined and the
corresponding infrastructure implemented,
the most important ones being CORBA,
COM, JavaBeans, and Enterprise
JavaBeans, the CORBA Component Model,
and .NET. Whereas these technologies are
still playing major role in IT industry,
other technologies that were defined did not
survive for long time and are now
considered being out of date (e.g., OpenDoc
)[4].
6. CBA implementation challenges

4.3 Language-independent component There are many challenges in implementing

specification CBA. Cultural and bureaucratic
impediments, EA and asset management
The goal of component-based software process challenges, Legacy technologies and
development is the possibility to implement architecture and skill mix [5].
a component in (almost) any language, not
only in any module-oriented and object-
oriented languages but even in conventional
languages.

-3-
7. Conclusion
The key concept of Component based
development is reusability. It has benefits as
well as some implementation challenges. It
has some significant differences from the
traditional object oriented approach. It has
also been used in several application
domains, such as e-governance structure, e-
business, ERP design environment, Software
engineering approaches etc. Most of the IT
companies are shifting to component based
development approach in order to increase
their productivity.
[7] Wolfgang P. (1997) Component-Based
Software Development—A New
Paradigm in Software Engineering:
Proceedings of Software Engineering
Group, University of Constance,
Software Concepts and Tool Conference
(1997).
[8] David G and Bradley S. Component-
Based Software Engineering in
Pervasive Computing Environments
Published by School of Computer
Science, Carnegie Mellon University.

References [9] Adiajagan M, and Vijayakumar B

(2006) Interoperability in Component
[1] Bertrand,M.(2003). The Grand Based Software Development:
Challenge of Trusted Components: Proceedings of world academy of
IEEE Computer Society Press in Science, Engineering and Technology
Proceedings ICSE 2003, Portland, VOLUME 16 NOVEMBER 2006 ISSN
Oregon. 1307-6884.

[2] Bonn-Oh,K.(2000).Component-based [10] Felix B,Len B,Charles B, Santiago

ERP design in a distributed object
environment :Proceedings of the 2000
information resources management
association international conference on
Challenges of information technology
management in the 21st century, Alaska,
United States.
Comella-D, Fred L, John R and Robert
(2000)S. Technical Concepts of
Component-Based Software
Engineering, Report was prepared for
the SEI Joint Program Office HQ
ESC/DIB 5 Eglin Street Hanscom.

[3] Doron,B.A, Moshe,C. and John Low,

Component Based Development and
Use:Managing the Component Life
Cycle : Logix Conference.

[4] Jean-Guy,S. and Jun,H. Components –

the Past, the Present, and the Future

[5] John, C. B, David, R. M, and John,

W.N. (2003), Succeeding with
Component Based Architecture in e-
government: Industry Advisory Council
(IAC) Concept Paper, Australia.

[6] Pearl, E.E. and Daniela Mehandjiska,S.

(2003). Why a Component-based
Architecture for E-business :Computer
Science and Technology conference,
Cancun, Mexico.

-4-