Journal of Computing and Information Technology - CIT 13, 2005, 4, 321-327 321

Component-based Development
Process and Component Lifecycle

Ivica Crnkovic1, Stig Larsson2 and Michel Chaudron3

1 MälardalenUniversity, Västerås, Sweden
2 ABB Corporate Research, Västerås, Sweden
3 Technical University Eindhoven, Eindhoven, The Netherlands

In recent years component-based development has be- The rest of the paper is organized as follows.
come an established approach. Component-based Soft- Section 2 gives an overview of development
ware Engineering (CBSE) that deals with the entire
lifecycle of component-based products has been focused processes. Section 3 discusses some basic char-
on technologies related to design and implementation acteristics of component-based approach and il-
of software components and systems built from soft- lustrates component-based activities in the “V”
ware components. The experience has shown that pure development process model. We illustrate a
technologies alone are not enough. A CBSE approach
requires certain changes in development and life cycle component-based development approach in an
processes. However, very few CBSE works, either industrial case study in section 4. Finally, sec-
research or practical, have addressed these topics. This tion 5 concludes the paper.
paper describes principle differences of component-based
and non- component based processes. Also we give an
overview of a case study from a company that applies
component-based approach.
2. Basic Characteristic
Keywords: component-based software engineering, life-
cycle processes. of Lifecycle Process Models

1. Introduction Lifecycle processes include all activities of a

product or a system during its entire life, from
the business idea for its development, through
Component-based approach has in last years its usage and its completion of use. Differ-
shown considerable success in many application
ent models have been proposed and exploited
domains. Distributed and web-based systems,
desktop and graphical applications are typi- in software engineering, and different models
cal examples of domains in which component- have exhibited their (in)abilities to efficiently
based approach has been very successful. In govern all activities required for a successful
these domains the general-purpose component development and use of products. We can dis-
technologies, such as COM, .NET, EJB, J2EE tinguish two main groups of models: Sequential
are used. and evolutionary. The sequential models define
a sequence of activities in which one activity
There is, however, very little development pro- follows after a completion of the previous one.
cesses knowledge specific to component-based Evolutionary models allow performance of sev-
development. eral activities in parallel without requirements
This paper describes the characteristics of on a stringent completion of one activity to be
component-based processes, the reasons for this, able to start with another one. Well known ex-
and the differences from a non-component-based ample of sequential models is waterfall model,
development process. From a case study it or V model, and of evolutionary models, it-
shows that component-based approach provides erative and incremental development, or spiral
specific solutions in organization of a company. model.
322 Component-based Development Process and Component Lifecycle

Independently of the model type we can iden- Many of the methods, tools and principles of
tify the basic activities present in any lifecycle software engineering used in other types of sys-
process model. These activities are the follow- tem will be used in the same or similar way
ing: in CBSE. There is, however, one difference;
Requirements analysis and specification. The CBSE specifically focuses on questions related
system’s services, constraints and goals are es- to components and in that sense it distinguishes
tablished (i.e. a specification of what the system the process of “component development” from
is supposed to do). that of “system development with components”.
System and software design. An overall sys-
tem and software architecture is established. A
detailed design follows the overall design. Soft- 3.1. Building Systems from Components
ware design includes identifying and describing
the fundamental software systems abstractions
and their relationships. The main idea of the component-based approach
is building systems from pre-existing compo-
Implementation and unit testing. The for- nents. This assumption has several consequences
malization of the design in an executable way, for the system lifecycle. First, the develop-
which can be composed of smaller units. Test- ment processes of component-based systems
ing of the units follows their implementation. are separated from development processes of
System integration. The system units are inte- the components; the components should already
grated. have been developed and possibly used in other
System verification and validation. Correct- products when the system development process
ness of the complete system is verified and the starts. Second, a new separate process will ap-
system is validated with respect to the require- pear: Finding and evaluating the components.
ments. Third, the activities in the processes will be dif-
ferent from the activities in non- component-
Operation support and maintenance. A set based approach; for the system development the
of activates that are required for the expected emphasis will be on finding the proper compo-
performance of the system. nents and verifying them, and for the component
Disposal. A disposal activity, often forgotten development, design for reuse will be the main
in many lifecycle models, includes the phasing- concern.
out of the system, i.e. a possible replacement by
another system or a complete termination. There is a difference in requirements and busi-
ness ideas in these two cases and different ap-
Not all models are suitable for all types of sys- proaches are necessary. Components are built to
tem lifecycles. Usually large systems, which
be used and reused in many applications, some
include many stakeholders and whose develop-
possibly not yet existing, in some possibly un-
ment lasts a long period, prefer using sequential
models. The systems which use new technolo- foreseen way
gies are smaller and to which the time to market System development with components is fo-
is important, usually explore evolutionary mod- cused on the identification of reusable entities
els that are more flexible and can show some and relations between them, beginning from the
results much earlier than sequential models. system requirements and from the availability
These models can be applied in a component- of already existing components  1 ] 4 ]. Much
based development, but require adaptation to implementation effort in system development
the principles of component-based approach.
will no longer be necessary, but the effort re-
quired in dealing with components: locating
3. Component-Based Lifecycle them, selecting those most appropriate, testing
Process Models them, etc. will increase  6 ].
We do not only recognize different activities in
CBSE addresses challenges similar to those en- the two processes, but also find that many of
countered elsewhere in software engineering. these activities can be performed independently
Component-based Development Process and Component Lifecycle 323

of each other. In reality, the processes are al-

ready separate as many components are devel-
oped by third parties, independently of the sys-
tem development. Even components being de-
veloped internally in an organization which uses
these very same components, are often treated
as separate entities developed separately.

Let us discuss these differences in more detail.

Figure 1 shows a V development model adapted
to component-based approach.

We use V model as this model is widely used in

many organizations — typically large organiza-
Fig. 1. V development process for CBD.
tion building complex long-life products, such
as cars or robots. In this model the process starts
in a usual way by requirements engineering and the system requirements engineers and system
requirements specification, followed by system architects must be aware about the availability
specification. In a non-component-based ap- of already existing components.
proach the process would continue with the unit
design, implementation and test. Instead of per- A more realistic process is shown in Figure 2.
forming this activities that often are time and Let us look at the activities in different phases
efforts consuming, we simply select appropri- of the development process in more detail.
ate components and integrate them in the sys- Requirements analysis and specification. In
tem. However, two problems appear here which this phase one important activity is to analyze
break this simplicity: (i) It is not obvious that the possibility of realizing the solutions that will
there is any component to select, and (ii) the se- meet these requirements. In a component-based
lected component only partially fits our overall approach this implies that it is necessary to ana-
design. The first fact shows that we must have lyze whether these requirements can be fulfilled
a process for finding components. This process with available components. This means that the
includes activities for finding the components, requirements engineers must be aware of the
and then the component evaluation. The second components that can possibly be used. Since
fact indicates for a need of component adapta- it is not likely that appropriate components can
always be found, there is a risk that the new
tion and testing before it can be integrated into components have to be implemented. To keep
the system. And of course there must be a pro- with component-based approach (and utilize its
cess of component development, this being in- advantages) one possibility is to negotiate the
dependent of the system development process. requirements and modify them to be able to use
the existing components.
Figure 1 also shows a simplified and idealized
process. Its assumption is that the components
selected and used are sufficiently close to the
units identified in the design process, so that the
adaptation process requires (significantly) less
efforts than the units’ implementation. Further,
it does not consider what happens in the main-
tenance process; what happens if a system mal-
functions due to a problem that has occurred in
a component, or due to incompatibilities of the
components. This indicates that the component-
based approach is not only limited to the devel-
opment process, or part of the development pro-
cess, but to the entire lifecycle. At a very early
stage, in the Requirements and Design phases, Fig. 2. A detailed V development process for CBD.
324 Component-based Development Process and Component Lifecycle

System and software design. Similar to the re- components are of “black box” type and de-
quirements specification phase the system spec- livered from different vendors. Typically, a
ification and design are strongly related to the component can exhibit an error, but the cause
availability of the components. The potential of the malfunction lies in another component.
components are complying with a particular Contractual interfaces play an important role in
component model. One could assume that it checking the proper input and output from com-
would be possible to use components imple- ponents. These interfaces enable a specification
mented in different component technologies, of input and output and checking the correctness
but in practice it is very difficult to achieve inter- of data.
operability between different component mod- Operation support and maintenance. The
els. Particular component model requires a par- maintenance process includes some steps that
ticular architectural framework, and the appli- are similar to the integration process: A new or
cation is supposed to use this framework. This modified component is deployed into the sys-
has a direct impact on architectural decisions. tem. Also, it may be necessary to change the
For example, if the component model requires glue code. In most of the cases an existing
a client-server architecture style, it is obvious component will be modified or a new version of
that the application will use that style and not the same component will be integrated into the
another one (for example pipe-filter). This will system. Once again, new problems caused by
put limitations on the system design. Also, incompatibility between components, or by bro-
other properties of components can have a di- ken dependencies, may occur. This means that
rect influence on the design decisions. For this the system must be verified (either formally, or
reason the design process is tightly connected by simulation, or by testing).
to the availability of the components.
In comparison with a non-component-based ap-
Implementation and unit testing. When build- proach, in a component-based development pro-
ing component-based system, an ideal case is cess there are significantly less efforts in pro-
to build an application by direct integration gramming, but the verification and testing re-
of components, i.e. connecting components di- quire considerably more efforts. The verifica-
rectly. The “glue code” is a code that spec- tion activity is repeated in several phases, with
ifies this connection. In practice the role of slightly different goals:
the glue code will also include adaptation of
the components, and even implementation of Verifying component in isolation;
new functions. In an ideal case the compo- Verifying components in an assembly;
nents themselves are already built and tested.
However, the component tests in isolation are Verifying the system when a component has
not sufficient. Often, design units will be im- been deployed into the system.
plemented as assemblies of several components
and possibly a glue code. These assemblies
must be tested separately since an assembly of 3.2. Building Reusable Components
correct components may be incorrect, although
the components themselves are correct  3 ]. The process of building components can fol-
System Integration. The integration process low an arbitrary development process model.
includes integration of standard infrastructure However, any model will require certain mod-
components that build a component framework ification to achieve the goals; in addition to
and the application components. The integra- the demands on the component functionality,
tion of a particular component into a system a component is built to be reused. Reusabil-
is called a component deployment. Unlike the ity implies generality and flexibility, and these
entire system integration, a component deploy- requirements may significantly change the com-
ment is a mechanism for integration of partic- ponent characteristics. For example there might
ular components — it includes download and be a requirement for portability, and this re-
registering of the component. quirement could imply a specific imple- menta-
tion solution (like choice of programming lan-
System verification and validation. The stan- guage, implementation of an intermediate level
dard test and verification techniques are used of services, programming style, etc.). The gen-
here. A specific problem for component-based erality requirements imply often more function-
approach is location of error, especially when ality and require more design and development
Component-based Development Process and Component Lifecycle 325

efforts and more qualified developers. The com- another component. The components are also
ponent development will require more efforts developed internally, but their development is
in testing and specification of the components. separated from the development of the products.
The components should be tested in isolation,
but also in different configurations. Finally, the The product-line architecture identifies the ba-
documentation and delivery will require more sic architectural framework. The product archi-
efforts since the extended documentation is very tecture is shown in Figure 3.
important for increasing understanding of the The product architecture is a layered architec-
component. An example of extended compo- ture which includes (i) operating system, (ii)
nent specification can be found in ROBOCOP the component framework which is an inter-
component model  5 ]; a component is speci- mediate level between domain-specific services
fied by a row of modules: executable model, and operating, (iii) core components which are
functional model, simulation model, resource included in all product variants, and (iv) appli-
model, etc. Each model includes a correspond- cation components that are usually different for
ing documentation. different product variants.
Complementary to this horizontal layering there
is a vertical structuring in form of subsystems.
4. Industrial Case of Subsystems are also related to organizational
Component-Based Process Model structures; they are responsible for development
and maintenance of particular components. The
overall process is designed as shown in Figure 4.
We give here a short overview of a case study: a
process model used in a large international con-
sumer electronics company. The case study was
performed by four researchers in intensive inter-
views with different stakeholders of the devel-
opment projects: system architects, component
architects, developers, project leaders, the man-
agement, the quality assurance and test people,
and principal specialists.
The development divisions of the company are
placed in four different countries and they pro-
duce numerous products with different vari-
ants and models. The company has adopted Fig. 3. Product software architecture.
component-based development using product-
line architecture. The component model is in-
ternally developed and most of the tools are in-
ternally developed. The reason for that are spe-
cific requirements of the domain: low resource
usage, high availability, and soft real-time re-
quirements.
The component model follows the basic prin-
ciples of CBSE: The components are specified
by interfaces which distinguish “require” from
“provide” interfaces. In addition to functional
specification, the interface includes additional
information; interaction protocols, timeliness
properties, and the memory usage. The com-
ponent model enables a smooth evolution of the
components as it allows existence of multiple
interfaces. The model has a specific charac-
teristic; it allows hierarchical compositions: a
composite component is treated as a standard
component and it can be further integrated in Fig. 4. Overall development process.
326 Component-based Development Process and Component Lifecycle

In the overall process there are three sets of

independent parallel processes: (i) An overall
architecture and platform development process
are responsible for delivering new platforms and
basic components, (ii) subsystem development
processes which deliver a set of components that
provide different services, and (iii) the product
development process which is basically an in-
tegration process. This process arrangement
makes it possible to deliver new products ev-
ery six months, while the development of sub-
system components takes typically between 12 Fig. 5. Project organization structure.
and 18 months. The specific feature of these
projects is that all deliverables have the same
form. A deliverable is a software package de-
fined as a component. Two main documents (QA) managers have similar role in their do-
belong to every deliverable: component inter- mains: to ensure coordination and compatibil-
face specification and component sheet; the first ity of tests and quality processes. Subsystem
document describing the interconnection, the architects provide the designs of their subsys-
second describing the component internals. tems and coordinate the design decisions with
other subsystems. Each subsystem has a test
Although the overall development and produc- team and a QA manager whose responsibility
tion is successful, the process suffers from sev- is the quality of delivered subsystem compo-
eral drawbacks. The most serious is late dis- nents. The integration team which works in
covery of errors, due to interface or architec- delivery projects is represented by a product
tural mismatches, insufficient specifications of architect, QA and test managers who coordi-
semantics of the components, or due to inappro- nate the activities with other projects. We can
priate interfaces. Also, the problems related to observe that project teams have many “non-
encapsulation of a service in components often productive” stakeholders. This is in line with
occur; due to functional overlaps, or some re- the component-based approach — more efforts
quirements affecting the architecture, it is diffi- must be put on overall architecture and testing,
cult to decide in which components a particular and less on the implementation itself. Develop-
function will be implemented. All these prob- ment processes in our case are manly of an evo-
lems indicate that it is difficult to perform the lutionary model. The platform, the subsystems
processes independently; negotiation between and the products are developed in several itera-
different subsystems and agreement in many tions until the desired functionality and quality
technical details between different teams are are achieved. This requires synchronizations of
necessary. For this reason the processes are iterations.
not completely separated. They are distributed
among several projects and there is an overall
project that coordinates them all.
The processes have a strong support in the 5. Conclusion
project and organization structure (see Figure
5).
A component-based approach cannot be fully
The system architect and the management have utilized if development processes and even de-
overall responsibilities for requirements, poli- velopment organizations are not adopted ac-
cies, product line architecture, products visions cording to basic principles of CBSE. Since this
and long term goals. The project architect has approach aims for increased reusability of exist-
a responsibility for the overall project which re- ing components, the efforts for implementations
sults in a line of products. He/she coordinates decrease, and the efforts for system verification
the architectural design of the product family increase. This requires adjustments of the de-
and subsystems. The test and quality-assurance velopment processes.
Component-based Development Process and Component Lifecycle 327

By an industrial case study we have pointed out

the difficulties to achieve a complete separa-
Recived: June, 2005.
tion of the development processes of systems Accepted: October, 2005.
from the components, as well as the need for
a project organization which puts more empha- Contact address:
sis on architectural issues and on system and Ivica Crnkovic
Mälardalen University
components verification. Västerås
Sweden
[email protected]

Stig Larsson
6. Acknowledgments ABB Corporate Research
Västerås
Sweden
The authors would like to thank Chritiene Aarts [email protected]
for his enormous help in organizing the inter- Michel Chaudron
views and all the interviewees who took their Technical University Eindhoven
Eindhoven
valuable time for the interviews. The Netherlands

References
IVICA CRNKOVIC is a professor of industrial software engineering at
Mälardalen University where he is the administrative leader of the
software engineering laboratory and the scientific leader of the in-
 1] L. BASS, P. CLEMENTS AND R. KAZMAN, Software dustrial software engineering research. His research interests include
component-based software engineering, software configuration man-
Architecture in Practice, Addison Wesley, 1998. agement, software development environments and tools, as well as
 2] V. BORGHOFF, R. PARESI, (editors), Information software engineering in general. Professor Crnkovic received an M.Sc.
in electrical engineering in 1979, an M.Sc. in theoretical physics in
Technology for Knowledge Management, New York: 1984, and a Ph.D. in computer science in 1991, all from the University
Springer Verlag; 1998. of Zagreb, Croatia.
 3 ] IVICA CRNKOVIC AND MAGNUS LARSSON (editors),
Building Reliable Component-Based Software Sys-
tems, Artech House Publishers, ISBN 1-58053-327- MICHEL R. V. CHAUDRON is an assistant professor at the Eindhoven
University of Technology and a researcher in the System Architecture
2, 2003. and Networking group. His research interests include software archi-
tecture, empirical software engineering and component-based software
 4] D. GARLAN, R. ALLEN AND J. OCKERBLOOM, Ar- engineering. He received his MSc and his PhD from the Universiteit
chitectural Mismatch: Why Reuse is so Hard, IEEE Leiden and worked as a consultant in traffic and transport telematics.
Software, Vo. 12, issue 6, 1995.
 5] ITEA project, ROBOCOP-Robust Open Com-
ponent Based Software Architecture for Con- STIG LARSSON is responsible for the product development process im-
provement initiative at ABB. He has occupied different development and
figurable Devices Project http://www.hitech- management positions in ABB for the last 20 years. His professional
projects.com/euprojects/robocop. interest is in product development processes and software architecture.
He received his MSc in electrical engineering from the Royal Institute
 6] M. MORISIO, C. B. SEAMAN, A. T. PARRA, V. R. of Techonoloy in Stockholm.
BASIL, S. E. KRAFT AND S. E. CONDON, Investi-
gating and Improving a COTS-Based Software
Development Process, In Proceedings , 22nd ICSE,
ACM Press, 2000.