Journal of Software Engineering and Applications, 2011, 4, 283-292
doi:10.4236/jsea.2011.45031 Published Online May 2011 (http://www.SciRP.org/journal/jsea)
283
Moving from Traditional Software Engineering to
Componentware
Faisal Nabi1, Roisin Mullins2
1E-commerce Security Re search Group, Hazraat Baba Bullah Shah Research Center, Qasoor, Pakistan; 2IT Research Group, School
of Business, University of Wale s Trinity Saint David, Wales, UK.
Received March 10th, 2011; revised April 13th, 2011; accepted April 21st, 2011.
ABSTRACT
The field of software engineering and software technology is developing very fast. Perhaps as a consequence, there is
seldom enough interest or opportunity for systematic investigation of how the underlying technology will actually per-
form. That is, we introduce new concepts, methods, techniques and tools—or change existing ones and emphasize their
value. A major turn in software engineering leading to Componentware has dramatically changed the shape of software
development and introduced interesting methods for the design and rapid development of systems which may provide
cost-effective benefits. In this paper we will discuss Componentware, process model, architecture, principles and the
drivers, advantages, disadvantage and reveal profound changes from the traditional software engineering approaches.
Keywords: Software, Component, Componentware, Component Infrastructure, Software Pattern, Software Architecture,
Component-Based-Development
1. Introduction
The past 20 years has been a time of change in the field
of IT as we see a succession of new technological inven-
tions. The software engineering field has gone through
several generations of introductions of methods and
techniques for developing large, complex systems. The
1970s was the decade of structured programming and
structured methods. The 1980s, was the decade of data
modelling and techniques. And the 1990s have focused
on methods and techniques to support prototyping, itera-
tive development, and a variety of rapid application de-
velopment (RAD) techniques based upon the object ori-
ented (OO) paradigm. The past practices associated with
programming using machine code, assembly languages,
high level languages, fourth generation languages, and
further on to CASE tools, appear to act to solve some
technological problems and help us meet requirements
and develop better systems. However, those in the pro-
fession recognize that previous approaches have not
managed to minimize project failures and project short-
falls [1,2]. One of the key drivers for changes to the
software engineering approaches is the pace of change
that has swept through businesses across the world. This
has accelerated a need for software engineers to respond
to the need for better and improved systems that meet the
changing requirements, more flexible design and allow
for easier reconfiguration. Businesses have become reli-
ant on using and integrating IT and view these tools as
being core to their strategies, competitiveness and the
value they create for customers and supplier. The busi-
ness place high value on their IT and continue to invest
in new systems but in return they expect results. The
overall system requirements from businesses have in-
creased considerably. Having this in mind the search for
new engineering techniques, in order to meet new busi-
ness needs, to some extent is anticipated but requires a
discerning rethink about the stages of change.
There is a concern that much of traditional software
approaches are misunderstood and many software de-
signers fail to appreciate the capabilities of software ap-
proaches. Therefore, there is a need to move to a stage
where the importance of software approaches are highly
valued and better understood.
The signal of a software crisis on the increase in busi-
nesses became apparent decades ago, then with the move
to object-oriented approaches (such as the Object Model-
ling Technique) which became standard they were
deemed equally unsuccessful for corporate developers.
These outcomes have been repeatedly confirmed by re-
search. Three key factors that exacerbate the software

Moving from Traditional Software Engineering to Componentware
284
crisis are:
• Requirem e nt s chan ge
• Commercial innovation
• Distributed computing
A significant part of the problem is the belief that all
user expectations are achievable. While it seems apparent
that user requirements for systems have increased much
faster than corporate developers’ capability to deliver.
The problem is also not helped by the fact that require-
ments changes are more frequent as businesses jostle for
position in the market and try to find ways to increase
their competitive advantage by means of strategic co rpo-
rate software.
Another confounding factor is the destabilizing force
of accelerating technology innovation, both in commer-
cial software and hardware platforms. Corporate devel-
opers have difficulty finding compatible configurations
of software products, and are forced to upgrade configu-
rations frequently as new products are released. Further,
software maintenance due to technology upgrades is a
significant corporate cost driver.
Due to dominance of the Internet for business and
geographically diverse enterprises, distributed computing
is an essential feature of many new applications. Today’s
highly distributed enterprises require heterogeneous
hardware/software, decentralized legacy configurations,
and complex communicatio n s infrastru ctur e. Th e result is
an environment with frequent partial system failures.
Distributed computing reverses many key assumptions
that are the basis for procedural and object-oriented
software development.
The recognized technology for the software industry
has been object-oriented programming (OO) and has
been widely adopted by new corporate development pro-
jects mainly because OO is universally supported by
software tool vendors. There are many programmers re-
ceiving training for object-oriented development (e.g.
C++ and Java) as corporations create new strategic sys-
tems. This acclaimed approach will not satisfy all the
engineering requirements and it is likely that these de-
velopers and corporations are likely to become the next
generation of disillusioned participants in the software
crisis. However, the organizations that endure and thrive
with this technology must use it in sophisticated new
ways, represented by componentware.
Therefore, it can be argued that Componentware ele-
ments could present a fundamental rethink and provide a
focus for changes in systems thinking, software proc-
esses, and technology utilization.
The componentware approach could address the fail-
ure of the majority of projects to meet their deadlines,
budget constraints, quality requirements and should per-
form well against the ever increasing costs associated
with software maintenance. Software developers as re-
ported in the literature [2] who have built software sys-
tems for business by assembling components already
developed and prepared for integration suggest that there
are four elements of Componentware:
• Component Infrastructures
• Software Patterns
• Software Architecture
• Component-Base d Development
Mowbray and Malveau (2004) suggest that “Compo-
nentware technologies provide sophisticated approaches
to software development that challenges outdated as-
sumptions. Together these elements create a major new
technology trend. Componentware represents as funda-
mental a change in technology as object-orientation and
previous generations” and this new age of software de-
velopment is illustrated in Figure 1 [2].
In this paper we address the background leading to the
need for a Componentware approach. The move from
traditional approaches to the Componentware era, com-
ponent technology, the drivers and factors of Compo-
nentware, advantages, disadvantage and conclusion.
2. The Move from Traditional Software
Engineering to Componentware
The ubiquitous nature and widespread use of the personal
computers and the Internet has created new markets, en-
couraged new users and developers and importantly
makes computers a core part of education, business and
society.
The acceptance that technology is a part of everyday
life has placed an additional emphasis for change in the
software industry. For example, new users as consumers
expect the cost of software to reduce in order to match
the ever-decreasing hardware price. Further, demand for
new applications such as electronic commerce and
groupware are high. However, conventional methodolo-
gies have not witnessed huge gains in productivity and
quality. This is a further realization of the need to
re-think the way softw are develo pment should pro ceed in
the future.
Figure 1. Change of environment and software.

Moving from Traditional Software Engineering to Componentware285
Componentware has advantages in that they use com-
ponents as the primary source and this would lead to a
gain in productivity and qu ality. This is a view expressed
by those from a matured engineering discipline [3]. As
suggested by McIlroy, (1976) “making applications from
software components has been a dream in software engi-
neering community. My thesis is th at the software indus-
try is weakly founded, in part because of the absence of a
software components sub industry. … A components
industry could be immensely successful” [4]. However, it
is clear that widespread reuse of software components in
the software industry has not come about and a number
of obstacles have been identified. However, it seems
clear that the most fundamental problems are a lack of
mechanisms to make components interoperable and there
appears to be a lack of “reusable” components.
Since the early 1990’s, approaches namely Compo-
nentware (CW) [5] or Component-Based Software Engi-
neering (CBSE) has emerged [3,6-9]. The CBSE ap-
proach emphasized End-User Computing such as making
possible to develop applications on the PCs. Further, the
use of COTS (Commercial Off-The-Shelf) and Internet
technology such as Web and Java-based technologies
software promoted the CBSE approach for development
business appl i cat ions [10].
It is likely that if CBSE had been more widely ac-
cepted it could have opened up new possibilities for
CBSE such as network distribution of components, and
the reuse and interoperation of components over the
Internet. In recent times, a few types of technologies
have been widely deployed and are still evolving. They
include ActiveX/DCOM from Microsoft [11], CORBA
from OMG [12] and JavaBeans from SUN Microsystems
[13].
2.1. What Differentiates CW/CBSE from the
Conventional Software Reuse?
1) Conventional Software Reuse and CW/CBSE:
Although object-oriented technologies have promoted
software reuse, there is a big gap between the whole sys-
tems and classes. To fill the gap, many interesting ideas
have emerged in object-oriented software reuse in recent
years. They include software architecture [14], design
patterns [15], and frameworks [16].
2) CW/CBSE Approach: Componentware Engineering
(CW)/Component-Based-Software Engineering (CBSE)
as reported in the literature take different approaches,
from conventional software reuse in the following ways.
a) Plug & Play: Component should be able to plug and
play with other components or frameworks so that com-
ponents can be composed at run-time without compila-
tion.
b) Interface-centric: Components should separate the
interface from the implementation and hide the imple-
mentation details so that they can be composed without
knowing their implementation.
c) Architecture-centric: Components are designed on a
pre-defined architecture so that they can interoperate
with other components and/or frameworks.
d) Standardization: A component interface should be
standardized so that they can be manufactured by multi-
ple vendors and widely reused across the corporations.
e) Distribution through Market: Components can be
acquired and improved though competition, being avail-
able on the market, and provide incentives to the ven-
dors.
2.2. Process Model of CW and CBSE
CW/CBSE component-based software engineering al-
lows the software development and delivery stages to
evolve rather than follow a conventional approach and in
doing so some parts of a system can be acquired from the
component vendors and/or be outsourced to other or-
ganizations, some parts of software process can be done
concurrently.
1) The architecture and the software process can be
designed to allow software reuse, the software process
should be reuse-oriented so that designers can reuse arti-
facts at different levels of abstraction along with software
process.
2) Figure 2 illustrates the conv entional waterfall proc-
ess and an example of CBSE process. As indicated in the
figure the Componentware (CW)/CBSE process consists
of two processes; component development and compo-
nent integration. Since these two processes can be done
by different organizations, these two processes can be
concurrent. Unlike the conventional process, the CBSE
process needs an additional process for component ac-
quisition.
Figure 2. Conventional software process compared to com-
ponent-based process model.
JSEA

Moving from Traditional Software Engineering to Componentware
286
3. Component Technology
We will discuss these componentware technologies after
a brief introduction to componentware’s unique princi-
ples.
What is a Software Component?
A software component can be regarded as “a software
element that conforms to a component model and can be
independently deployed and composed without modifi-
cation according to a composition standard” [17].
A further example of a software component “is a unit
of composition with contractually specified interfaces
and context dependencies only. A software component
can be deployed independently and is subject to compo-
sition by the thi rd part y ” [3] .
To simplify the concept of software components, we
classify the notion of software components into three
types:
1) Reusable Module/Unit is an independent and deliv-
erable software part that encapsulates a functional speci-
fication and implementation for reuse by a third party.
2) A reusable component is an independent, deploy-
able, and replaceable software unit that is reusable by a
third party based on the unit’s specification, implementa-
tion, and well-defined contracted interfaces.
3) A composite building block is a reusable compo-
nent that is developed as a building part to conform a
well-defined component model and the accompanying
composition standards.
3.1. Component Architecture and Principles
When Component-based dev elopment is put into practice,
it is necessary to divide the development into two parts
that of supplier on one side and customer on the other
side. In the organization the component developers are
involved in the role of component supplier on one side
and the developers of the software systems who are in-
volved in assembly of these components have the role of
component consumer on the other side.
This division can only be effective when a common
basis is provided for suppliers and consumers of compo-
nents. A component execution environment like COM or
CORBA provide a partial solution. The main focus has
been on technical issues concerning the communication
between running software components. Therefore to aid
the smooth process a component architecture is required
to provide suppliers and customers with a set of rules,
standards and guidelines that prescribe what components
are and how they are assembled into software systems.
Component architecture therefore in our view is a set
of principles and rules according to which a software
system is designed and built with the use of componen ts.
The component architecture covers three aspects of a
software system. These are:
1) Building blocks: The architecture specifies the type
of building blocks systems are composed of.
2) Construction of the software system: The architec-
ture specifies how the building blocks are joined together
when developing an application. The architecture de-
scribes the role that building block s play in the system.
3) Organization: Components are divided in categories
based upon their functionality and these categories are
placed in two dimensional layering.
3.2. Component vs Objects
As described by Szyperski C. (1998) a component’s
characteristic properties are “that it is a unit of inde-
pendent deployment; it is a unit of third-party composi-
tion; and it has no observable state” [3]. This means that
the component is independently deployable and it needs
to be separated from the other components and the envi-
ronment and it contains all its features.
In contrast to the properties characterizing components,
an object’s characteristic properties are that it is a unit of
instantiation (it has a unique identity); it has state that
can be persistent; and it encapsulates its state and behav-
ior [3]. Again, several object properties follow directly.
Since an object is a unit of instan tiation, it cannot be par-
tially instantiated. Further, since an object has an indi-
vidual state, it also needs a unique identity so you can
identify it, despite state chang es, for the object’s lifetime
as shown in Figure 3.
Table 1 describes that although most components are
composed of objects, there are fundamental differences
between two structures. A Component can be differenti-
ated from an object in that its “encapsulation” is guaran-
teed, that is there are no exposed implementation de-
pendencies. An object might only be used within a single
application, but a component has been designed with
reuse in mind and can not assume much about the envi-
Figure 3. Components when activated create interacting
objects.

Moving from Traditional Software Engineering to Componentware287
Table 1. Summary of objects compared to components.
Objects Components
Many Interdependencies Few Interdependencies
Composed into Components Composed into Services
Interface and Implementation
Together Separate Interface and Implementation
ronment in which it will be used. An object typically
defines a much smaller portion of a problem space: an
e-mail message, for example.
A component operates at a higher level, for example,
for sending and receiving e-mail. A component typically
contains a mechanism for configuring its operation in
addition to its basic methods for performing its functions.
This provides a means for a component to be adjusted to
a range of different preferences, whereas an individual
object dose not usually provides this range of configura-
bility.
A component is often composed of a number of ob-
jects, which are designed to work together to provide
specific functionality. Some component standards (such
as EJB) also provide a recommended means to package
their components for deployment (e.g, EJB’s in jar file,
containing objects themselves and a deployment descrip-
tion file).
Traditional Notions of Modules with Components:
Module concepts do not normally support one aspect of
Full-fledged components. For one, there are no persistent
immutable resources that come with a Module, beyond
that which has been hardwired as constant in the code.
Resources parameterize a component and replacing these
resources lets you version a component without needing
to recompile; for example localization. Further, modifi-
cation of resources may look like a form of a mutable
component state. Since components are not supposed to
modify their own resources (or their code), this distinc-
tion remains useful; resources fall into the same category
as the complied code that forms part of a component. An
additional aspect of the components that is not usually
associated with modules is the configurability of de-
pendencies.
3.3. Componentware
The term “Componentware” has been argued in the sci-
entific community, and it is best considered as a reincar-
nation of object-orientated programming and other soft-
ware technologies. There are four basic principles: en-
capsulation, polymorphism, late binding, and safety that
distinguish componentware from previous technology
generations.
Except for inheritance, the list overlaps with ob-
ject-orientated approaches. The concept of a component
means that inheritance does not have a fit/support, be-
cause it is loosely coupled and often distributed. Figure
3, clearly explains component’s functionality by invok-
ing other objects, and this is called delegations.
All components specification correspondence to its
implementations. The specification states, its public in-
terfaces with other components that define a component
encapsulating a functional specification and implementa-
tion for reuse. Whereas, polymorphism supports reuse of
component specifications that can be local or global
standards for reuse throughout a system.
Componentware supports composition allowing inte-
gration and specifications from constituent components
for buildi ng systems.
3.4. Component Infrastructures
It has been reported [18] that many global businesses
including Microsoft, Sun Microsytems, IBM and the
CORBA consortia have established significant compo-
nentware infrastructures through massive technology and
marketing investments.
These component infrastructures are described as
dominant infrastructures extending beyond industry
segments and of course they share similarities. A key
feature is their ability to be mutually interoperable and
they are becoming mainstream development platforms.
For example [18] “Microsoft has been promoting the
Component Object Model (COM) and follow-on prod-
ucts for several years. COM is a single-computer com-
ponent infrastructure. OLE and ActiveX define compo-
nentware interfaces based upon COM. In theory, the Dis-
tributed Component Object Model (DCOM) extends the
capabilities of COM over networks and the Internet”. It
has been reported that there has been a remarkable shift
in businesses such as Microsoft to migrate to compo-
nentware and to continue to promote componentware in
the future.
3.4.1. Software Patter ns
Software patterns are often simply described as the de-
sign tools, knowledge reuse and describe the manner of
modelling business systems. These are described by
Mowbray, T. J. and R. C. Malveau, (1997) [19,20] as
“comprising a common body of software knowledge
which can be applied across all component infrastruc-
tures. The most famous category of software patterns,
called design patterns, comprises proven software design
ideas which are reused by developers”. Other important
categories of patterns include analysis patterns and
anti-patterns [20]. The software patterns are important in
understanding design concepts of componentware and
are important for specifications and implementation. It is
expected that software patterns will ameliorate many of
the common problems reported when developing ob-
JSEA

Moving from Traditional Software Engineering to Componentware
288
ject-oriented systems.
3.4.2. Software Archi tecture
Software architectures are concerned with design context,
including planning, maintenance, operations, stable in-
terface specifications, and the design and reuse of com-
ponents. These stable architecture designs present inter-
esting opportunities for distributed projects teams.
3.5. Component-Based Development
There are a number of advantages and factors that stimu-
late interest in component-based development. Accord-
ing to Brown, (1996) the following factors have contrib-
uted to make the component-based development ap-
proach become so popular [7].
 The need to automate the software development proc-
ess.
 The economic push moving many organizations to-
wards greater use of available commercial solutions.
 The style and architecture of the applications being
developed has significantly changed. There has been a
major change from centralized mainframe-based applica-
tions towards multi-tiered applications.
 A set of infrastructure standards and supporting tech-
nologies has emerged during the last few years.
 Domain-specific libraries and frameworks are starting
to appear.
 Leading companies within the software industry have
announced component-based development strategies.
 The web infrastructure is maturing. While there is a
great deal of chaos and competing technology, there is
also a basic shape to the infrastructure that allows collec-
tions of independent developed software applications to
be searched, remotely invoked, communicated, and share
data.
Component-Based Development Roles: Component-
Based-Development is a term that describes the process
of creating applications from existing components and it
involves more than just deployment and creates the units
of functionality, which are later assembled into an appli-
cation [21]. The component-based development process
includes reuse and is an iterative, incremental develop-
ment process and requires specialist technical roles.
These componentware roles are described as “compo-
nent system architect, component framework architect,
component programmer and component assembler/app-
lication developer and these roles are different from ob-
ject-oriented approaches which are more reliant on man-
agement decision making.
3.6. The Component-Based Development Process
Component-based development process appears as two
different activities.
1) The component-based application development
process.
2) The component development process respectively.
The component-based application development proc-
ess focuses on assembly software components that sup-
ply user services driven by specific business require-
ments. Whereas the component development process
focuses on acquiring, wrapping and building the actual
components.
Component Application Development
Many authors are in agreement that the component ap-
plication development process considers the design phase
as a major aspect as it captures specification, assembly
selection of components and integration. According to
Brown (1996) “the development of component-based
systems introduces fundamental changes in the way sys-
tems are acquired, integrated, deployed and evolved.
Rather than the classic waterfall approach to system de-
velopment, systems are designed by examining existing
components to see how they meet the system require-
ments. This is followed by an iterative process of refin-
ing the requirements to match the existing components,
and deciding which of those components that can best be
integrated to provide th e necessary functionality. Finally,
the system is engineered by assembling the selected
components using locally developed code”. It is further
suggested that [7] “the real difference between tradition al
application development and component based applica-
tion development takes place within the design phase,
and it is in the design that you begin paying attention to
how the objects you have identified, during the analysis
phase, can be grouped into components”.
These component states are best described by Brown
(1996) as [7] (Figure 4):
● “Gathered or off-the-shelf components (COTS)
Consists of those identified as being of poten tial inter-
est, and requires a process of investigating those compo-
nents which may come from a variety of local and re-
mote sources. At this stage little may be known about a
component’s characteristics. The information available
may simply be its name, its parameters, and some idea of
its required operating environment.
● Qualified components
Have discovered interfaces so that possible source of
conflict and overlap among components has been identi-
fied. Discovery can take many forms, but usually in-
volves detailed analysis of any available component
documentation or specifications, discussions with com-
ponent developers and users, and trial execution of the
component in different settings.
● Adap ted components
Have been amended to address potential sources of

Moving from Traditional Software Engineering to Componentware
JSEA
289
and data representation” [22]. Architecture is, increas-
ingly, becoming a crucial part of a software organiza-
tion’s business strategy because it is a reusable asset in
itself that can be reapplied to subsequent systems.
conflict. Typically, simple scripts are written as a buffer
between user request and component actions. The buffer
can be used to provide default information to the com-
ponents, eliminate access to unwanted component be-
havior, and act as an insulation layer for the replacement
of components. The figure implies a kind of component
wrapping.
Therefore, it has increased value for the business and
presents opportunities for new bu siness strategies.
A common view is that component-based development
requires a planned and disciplined approach to the archi-
tecture of the system being built. According to Clements
(1995) “purchasing components at random will result in
a collection of mismatched parts that will have no hope
of working in unison” [23]. This has been further advo-
cated by Garlan (1995), as outlined in [24] who points
out that “the reason why even carefully considered sets
of components may be unlikely to successfully operate
with each other is that designers of software components
make assumptions that are often subtle and undocu-
mented about the ways in which the components will
interact with other co mponents, or th e expectations abou t
services or behaviours of those other components”. It has
been suggested that component models do not solve all
architectural mismatch problems.
● Assembled components
Have been integrated via some form of common infra-
structure. For consistent component assembly the infra-
structure must consist of both a physical communication
infrastructure such as messaging infrastructure and a set
of conceptual agreements such as naming convention that
embody the shared semantics among the components.
This infrastructure will support component assembly and
coordination, and differentiates architectural assembly
from ad hoc glue.
● Updated components
Have been replaced by newer versions, or by different
components with similar behavior and interfaces. This
aspect of component assembly must be expected and
well supported as an essential activity through appropri-
ate definition of component interfaces and controlled
interaction among components”.
Further, a key aspect of component development is to
design for component reuse.
However, there is a component-based development
approach known as layered systems and this approach “is
based on dividing into different groups (layers) based on
what kind of services the components are offering, that is
the characteristics of the components”. This approach
suggests greater efficiency for development and mainte-
nance projects.
3.7. Architectural Design of a Component-Based
System The unified principle of the layered system architec-
ture approach is that a component at a particular layer is
allowed to make use only of components at the same or
next lower layer.
The importance of a stable, solid and dynamic system
architecture is critical to large-scale systems and is of
utmost importance for component-based systems. Ac-
cording to Bass (1998) architecture is, “an abstract view
distinct from the details of implementation, algorithm, Thus, components at each layer are insulated from
change when components at distant layers are replaced or
Figure 4. Reference model for compone n t assembly [7].

Moving From Traditional Software Engineering to Componentware 290
Table 2. Difference between component-based software and
traditional software model for component assembly [26].
Perspective Component-Based
Software Traditional Software
Objective To efficiently develop reliable, maintainable,
reusable software systems
To develop
efficient, reliable
software systems
Infrastructure
Beside operating systems
and programming
languages, certain
component models are
needed. For
instance NET/COM +,
EJB, or CORBA
Only need the
support of
operating systems
and programming
languages
Process
Component-based
software engineering
process – includes many
unique activities such as
component selection,
customization,
composition
Traditional
software
engineering
process – includes
requirements
analysis, design,
coding and testing
Roles Component providers
Component users
Usually, only one
development team
participates in the
entire process.
Portability
Relatively easy to
achieve, because the
adopted component
model and component
architectures will
reconcile many
incompatibility and
interoperability issues.
Difficult to
achieve as the
entire engineering
process is often
for one specific
environment
Interoperability
1. Communications
among components will
go through interfaces
and are managed by
component model.
Component model can
manage some of the
interoperability issues
for you.
2. When combining
varied components,
interoperability issue is
more serious
Very often,
traditional
software systems
are developed in a
restricted context,
and there are less
interoperability
issues. Once there
are, it is hard to
achieve as
modules and
subsystems are
context dependent
Maintainability
1. When producer
provides newer version,
system can be easily
upgraded
2. Less control over how
and when components
are maintained
3. May introduce more
overhead when source
code is not available
4. Versioning is handled
by component providers
independently, so
potential conflicts
may exist
1. When
maintaining the
software, any
modification
may require
reconstruction
of the entire
system
2. Have full
controll of any
maintenance
activity
Reusability
Reusability can occur at
any different level:
component, component
architecture
Difficult to reuse;
for some OO
systems, the reuse
is limited to
individual classes
Scalability
Easy to scale: the
scalability can be
automatically managed
by component model
Hard to scale as
any change in the
code may require
changes to all
relevant modules
or subsystems
Structure Loosely coupled
Often distributed
Usually
tightly coupled
and centralized
system
Code
availability Some component source code may not be available Source code is usually available
Customization
1. Many components are
general purpose
components and need
customization before
composition
2. Introspection
mechanism provided by
the component systems
to explore available
systems
When integrating
modules into the
final product, no
customization is
needed
modified” [24]. Additionally, according to Clements
(1996) the study and practice of software architecture is
still immature. Rigorous techniqu es need to be deve loped
to describe software architecture so that they can be ana-
lyzed to predict and assume non-functional system prop-
erties [25] and because a solid and dynamic architecture
is so critical to component-based systems, the architec-
ture-based activities need to be more precisely defined
and supported with processes and tools, and need to be
smoothly incorporated into existing development proc-
esses.
4. The Drivers of Componentware
There are many deficiencies in the traditional software
engineering approaches that have led to an acceptance to
move to componentware which allows rapid “Assembly”
of parts (Components), the development of parts as “re-
usable entities”, maintenance and upgrading of systems
by customizing and replacing such parts. A comparison
of component-based software and traditional software is
presented in Table 2.
The move to Componentware also reveals that busi-
nesses are forced to find ways to address the problems
with traditional approach es. The common failure such as,
the majority of projects unable to meet their deadline,
budget, quality requirement and the continued in crease in
the costs associated with software maintenances can not
continue and needs to be addressed by adopting a new

Moving from Traditional Software Engineering to Componentware291
approach.
The traditional systems objective is “to deliver an effi-
cient and reliable software system. Reusability, main-
tainability and ability to evolve are characteristics that
are not among the top priorities. Nevertheless, as soft-
ware systems get larger and larger, and more and more
complex, these characteristics become more critical [26].
Finally Componentware needs to address the follow-
ing objectives: shorter time to market, lower cost, better
reusability, higher reliability, and maintainability if it is
to be accepted by the software industry and software de-
velopers.
5. Disadvantage of Componentware
It has been suggested that “the component users do not
have full control of the entire engineering process, which
can introduce difficulties in component composition,
selection, testing, and maintenance, as well as many
other activities” [26]. Therefore more thought needs to be
given to understand how the separate roles and distinct
working patterns of designers and users can adjust to
utilizing the innovative capability offered by the Com-
ponentware approach.
6. Conclusions
The move to greater use of Componentware is the next
major software technology trend. At the present time the
uptake has not been widespread as developers prepare for
the transition.
It is readily available for commercial explo itation. The
move to Componentware has been widely accepted and
actively supported by major vendors, including Microsoft,
Sun, IBM, and t he CORBA vendo r c ons o rt i a .
The most important aspects of componentware are not
the choice of technologies, but how these are applied.
Successful adoption of componentware must include the
reuse of software patterns, the planning of software ar-
chitecture, and the establishment of component-based
development teams and recognition of specific roles.
The move to Componentware is an exciting opportu-
nity to advance software development and address the
shortcomi ngs o f outdated softw are approaches.
This paper seeks to clarify that if Componentware is
adopted it should enables modern business practices and
expectations in ways that could not be achieved with
previous approaches especially when business have to
face the challenges of requirements change and rapid
commercial innovation. There is good evidence to sup-
port that Componentware delivers the benefits of soft-
ware reuse and en ables outsourcing to distribu ted project
teams which is of high importance and in addition it cre-
ates new value fo r bu sinesses.
REFERENCES
[1] B. Dahlbom and L. Mathiassen, “The Future of Our Pro-
fession,” Communications of the ACM, Vol. 40, No. 6,
1997, pp. 499-519. doi:10.1145/255656.255706
[2] T. J. Mowbray and R. C. Malveau, “Software Architect
Bootcamp,” Prentice Hall PTR, London, 2004.
[3] C. Szyperski, “Component Software: Beyond Object-
Oriented Programming,” ACM Press, Addison-Wesley,
New York, 1998.
[4] M. D. McIlroy, “Mass-Produced Software Components,
Software Engineering Concepts and Techniques (1968
NATO Conference on Software Engineering),” Van
Nostrand Reinhold, New York, 1976.
[5] J. Udell, “Componentware,” Byte, Vol. 19, No. 5, 1994,
pp. 46-56.
[6] M. Aoyama, “Componentware: Building Applications
with Software Components,” Information Processing So-
ciety of Japan, in Japanese, Vol. 37, No. 1, 1996, pp.
71-79.
[7] A. Brown, “Component-Based Software Engineering,”
IEEE CS Press, Washington DC, 1996.
[8] D. Kiely, “Are Components the Future of Software?”
IEEE Computer, Vol. 31, No. 2, 1998, pp. 10-11.
[9] J. Sametinger, “Software Engineering with Reusable
Components,” Springer-Verlag, Berlin, 1997.
[10] K. Wallnau and D. Carney, “COTS Products and Tech-
nology Evaluation: Concepts and Pragmatics,” 20th Inter-
national Conference on Software Engineering Tutorial,
Kyoto, 19-25 September 1998.
[11] “Microsoft,” 1998. http://www.microsoft.com/activex/
[12] ”OMG,” 1998. http://www.omg.org
[13] A. Thomas, “Enterprise JavaBeans: Server Component
Model for Java,” White Paper, 1997.
http://www.javasoft.com/products/ejb/.
[14] M. Shaw and D. Garlan, “Software Architecture, Perspec-
tives on an Emerging Discipline,” Prentice Hall, London,
1996.
[15] E. Gamma and R. Helm, “Design Patterns: Elements of
Reusable Object-Oriented Software,” Addison-Wesley,
New York, 1995.
[16] M. E. Fayad and D. C. Schmidt,“Object-Oriented Appli-
cation Frameworks,” Communications of the ACM, Vol.
40, No. 10, 1997, pp. 32-38.
doi:10.1145/262793.262798
[17] B. Councill and G. T. Helneman, “Component-Based
Software Engineering: Putting the Pieces Together,” Ad-
dison-Wesley, New York, 2001.
[18] “Componentware,” 2010. http://www.phptr.com
[19] T. J. Mowbray and R. C. Malveau, “Corba Design Pat-
terns,” John Wiley & Sons, New York, 1997.
[20] W. J. Brown, R. C. Malveau, H. W. McCormick and T. J.
Mowbray, “Antipatterns: Refactoring Software, Archi-
tectures, and Projects in Crisis,” John Wiley & Sons, New
York, (1998).
JSEA

Moving from Traditional Software Engineering to Componentware
292
[21] N. Michael, “Java Frameworks & Components: Acceler-
ate Your Web Application Development,” Cambridge
University Press, Cambridge, 2003.
[22] L. Bass, P. Clements and R. Kazman, “Software Archi-
tecture in Practice,” Addison-Wesley, New York, 1998.
[23] P. E. Clements, “From Subroutines to Subsystems: Com-
ponent-Based Software Development,” American Pro-
grammer, Cutter Information Corporation, 1995.
[24] D. Garlan, R. Allen and J. Ockerbloom, “Architectural Mis-
match,” Proceedings of the 17th International Conference on
Software Engineering, Washington, 24-28 April, 1995.
[25] P. E. Clements, “Software Architecture: An Executive
Overview,” Software Engineering Institute, 1996.
[26] J. Z. Gao, H. S. J. Tsao and Y. Wu, “Testing and Quality
Assurance for Component-Based Software,” Artech
House Computer Library, Boston-London, 2005.