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 world because of the continuing integration
Component based Architectures (CBA), which is problems of the Enterprise applications. IT
a new approach for software engineering tasks, organizations everywhere have jumped on
which can be adopted in many areas. the CBA in hopes that it might finally ease
Component-based software development is
the IT planning burden. But it is not that
associated with a shift from traditional system
building using set of coding to system building easy [5].
by plugging together components. The main drive behind component
technology was reusability. Applications
can be built simply by simply plugging
1. Introduction existing reusable software components
together
In the changing world, component-based
software technology is becoming an However, reusability was not the only drive
increasingly popular approach to facilitate behind component technology: independent
the development of evolving systems. The evolution of application parts, enhanced
objective of this technology was to take flexibility, adaptability, and maintainability
elements from a collection of reusable of software systems, higher-level of
software components (i.e. components-off- application development than “classical”
the shelf-COTS packages) and build programming paradigms can be achieved
applications by simply plugging them through the CBA.
together. Hence, it aimed at the production
of high-quality software systems with 3. OOP & Component based Technology
shorter and more cost-effective development
cycles. By reconfiguring components, Theoretically object-oriented programming
adapting existing components, or (OOP) languages, analysis and design
introducing new components it was hoped methods would provide a well-suited tool-
that applications could be adapted to box for component-based application
changing requirements of real-world development, but practice showed that the
software systems more easily and address technology was often applied in a way that
the problems of object-oriented development contradicted the goals behind component
approaches [5, 7]. technology.
2. Overview Object-oriented analysis and design methods
The core of the CBA is the components and are domain-driven, which usually leads to
their interaction. Industry’s shift to CBA is a designs based on domain objects. Most of
new enterprise architecture model for these methods make the assumption that an
delivering applications. CBA has made a application is being built from scratch, and
tremendous amount of interest in the IT 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 Figure 2 Granularity of components [7]
module was originally designed. Otherwise
the source code or even its interface has to 5. Component Models
be changed. This leads to the creation of
multiple versions. Component testing must From an industrial view of point , various
be repeated. component models were defined and the
corresponding infrastructure implemented,
4.2 Components in object-oriented the most important ones being CORBA,
languages COM, JavaBeans, and Enterprise
JavaBeans, the CORBA Component Model,
In order to overcome some reuse problems and .NET. Whereas these technologies are
of module-oriented languages, object still playing major role in IT industry,
oriented languages introduce language other technologies that were defined did not
constructs to achieve delta changes survive for long time and are now
(programming by difference) without having considered being out of date (e.g., OpenDoc
to touch the source code of original )[4].
modules/classes. Inheritance is central to
this solution [7].
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
[7] Wolfgang P. (1997) Component-Based
The key concept of Component based Software Development—A New
development is reusability. It has benefits as Paradigm in Software Engineering:
well as some implementation challenges. It Proceedings of Software Engineering
has some significant differences from the Group, University of Constance,
traditional object oriented approach. It has Software Concepts and Tool Conference
also been used in several application (1997).
domains, such as e-governance structure, e-
business, ERP design environment, Software [8] David G and Bradley S. Component-
engineering approaches etc. Most of the IT Based Software Engineering in
companies are shifting to component based Pervasive Computing Environments
development approach in order to increase Published by School of Computer
their productivity. 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 Comella-D, Fred L, John R and Robert
environment :Proceedings of the 2000 (2000)S. Technical Concepts of
information resources management Component-Based Software
association international conference on Engineering, Report was prepared for
Challenges of information technology the SEI Joint Program Office HQ
management in the 21st century, Alaska, ESC/DIB 5 Eglin Street Hanscom.
United States.

[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-