The Journal of Systems and Software 61 (2002) 201212

3
www.elsevier.c
om/locate/jss ,

7
2

Cha 1

llen 2
3

ges V

of
a

com s
t
pon e
r
ent-
a
bas s
,
ed
dev
S
w

elop e
d

men e
n

t b

Ivica R
e
Crnkovic s
e
Magnus a

Larsson r
c
a
h

a
n
d

D
e
v
e
l
o
p
m
e
n
t
,

A
B
B

A
u
t
 System evolution,
maintenance, migration and
compatibilities are some of the
challenges met with when
developing a component-
based software system. Since
most systems evolve over
time, components must be
maintained or replaced. The
evolution of requirements
aects not only specific
system functions and
particular components but
also component-based
architecture on all levels.
Received
Increased 1 complexity is a
March 2001;
consequence
received in of dierent
revised form
components and systems
1 July 2001;
having
accepted 1 dierent life cycles. In
September
component-based systems it
2001
is easier to replace part of
system with a commercial

Abstract component. This process is

however not straightforward
It isand dierent factors such as
generally requirements management,
understood marketing issues, etc., must
that be taken into consideration. In
building this paper we discuss the
software issues and challenges
systems encountered when developing
with and using an evolving
component component-based software
s has many system. An industrial control
advantages system has been used as a
but thecase study. 2002 Elsevier
diculties Science Inc. All rights
of thisreserved.
approach
Keywords: Reuse; Component-based
should notdevelopment; Development
be ignored.environment; Architecture; Commercial
components
longer period ofsyste phas
time tend to bem e and
updated andthat the
changed manysupp time
1. times duringorts to
Introdu this period.this
Reuse and anappr
mark
et
ction open oach migh
component- requi t be
based res longe
Sys architecture aremore r, but
tems the key to theeort in the
that success ofin long
live systems with athe run,
over long life cycle.desig the
a Designing an reusa
ble the reusable cus-
ar- components, on tome
chitec the component r
ture man-agement and requi
will and on theas an reme
prove integration exam nts.
profit process. ple Durin
able. This paperuses
The issues related to the
describes important g
reuse development andthe evolu
conce maintenance ofABB tion
reusable components
pt can Adva of
be nt the
used indus syste
on trial m
dier proce new
ent *
Corresponding ss techn
levels author. Tel.: +46-21- contr ologi
: On a 103183; fax: +46-21- ol
low 342666. E-mail
es
level addresses:
syste were
it is a ivica.crnkovic@mdh. m. In devel
reuse se (I. Crnkovic), Secti oped
of mag- on 2 whic
sourc nus.larsson@mdh.se we h
e- (M. Larsson). give result
code, an ed in
and overv the
small- iew ap-
size of pear
comp the
onent ance
s. Adva on
More nt the
reuse syste mark
is m et of
obtai desig many
ned n and comp
with the onen
larger main ts
comp chara with
onent cteris
s the
encap -tics same
sulati of functi
ng Adva onalit
busin nt y as
ess reusa the
functi ble propr
ons. comp ietar
Finall onen y
y, the ts. ones.
integr Secti The
ation on 3
of fact
compl out- that
ete lines new
produ all comp
cts in the onen
compl devel ts
ex opme must
syste nt be
ms and incor
can main porat
be tena
seen ed
as the nce into
highe aspe the
st cts of existi
level a ng
of comp syste
reuse. onen ms
On t- intro
each base duce
level d s
of syste new
reuse m
there dema
are whic nds
speci h on
fic must the
dema comp syste
nds ly m
on with devel
- powe ABB
opme 2. Case study of rgene grou
p is
nt ratio divid
proce an industrial n, ed
ss. automation trans into
These system missi comp
on a-
new and nies,
issues 2.1. Overview distri one
butio of
are n, in whic
discus indus h,
sed in ABB trial ABB
is aauto Auto
Sec- global electricalmatio matio
tion engineering n n
4. and technol-ogyprod Produ
company, ucts, cts
serving etc. AB, is
customers inThe
1212/02/$ - see Inc. reser S0164 -
0164- front matter 2002 All ved. 1212(01)0
Elsevier Science rights PII: 0148 - 0
202 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
(API) for
proprietary and
responsible for the development third-party
of industrial automa-tion applications are
products. The automation examples of the
products encompass several functionality
families of industrial process- provided. Advant
com-ponents have
control systems including both access to process,
software and hardware. production and
quality data from
The main characteristics of any process control
these products are reli-ability, unit in a plant or in
an Intranet
high quality and compatibility. domain.
These features are the result of
responses to the main customers 2.2. Designing with
re-quirements: The customers
require stable products, running reuse
around the clock, year after year,Fig. 1. An overview of the
conceptual architecture of
which can be easily upgradedthe Advant open control Designing with
without impact on the existingsystem. reuse of existing
components has
pro-cess. To achieve this, ABB many advantages
uses a component-based system (Sommerville,
1996). The
approach to design extendable software
and flexible sys-tems. development time
can be reduced
The Advant open control and the reliability
of the products
system (OCS) (ABB, 2000) is increased. These
component-based to suit dierent were important
industrial applica-tions. The range prereq-uisites for
the Advant OCS
includes systems for Power development.
Utilities, Power Plants and Advant OCS
Infrastructure, Pulp and Paper, products can be
Met-als and Minerals, Petroleum, assembled in many
Chemical and Consumer dierent
Industries, Transportation configurations for
systems, etc. An overview of the use in various
Advant system is shown in Fig. 1. branches of
Advant OCS performs process industry. Specific
control and provides business systems are
information by assembling a designed with the
system of dier-ent families of reuse of Advant
Advant products. Process OCS products and
information is managed at the other external
level of process controllers. The products. This
process controllers are based on a means customers
real-time operating system and get a tailor-made
execute the control loops. The system that meets
operator station (OS) and their needs.
information management station External products
(IMS) gather and supervise and components
product information, while the can be used
business sys-tem provides
analysis information for together with the
optimization of the entire Advant OCS due to
processes. Advant products use the openness of
standard and proprietary the system. For
communication protocols to example, a
satisfy real-time requirements. satellite
communication
Advant OCS therefore includes component, which
information man-agement is used to transmit
functions with real-time insight data from the
into all aspects of the process oshore station to
controlled. Advant Information the supervision
Man-agement has an SQL-based system inland, can
relational database accessi-ble to be integrated with
resident software and all the Advant OCS.
connected computers. Historical
data acquisition reports, versatile The Advant
calculation packages and an system
architecture is
application programming designed for reuse.
interface Dierent products
such as Operator
and Information
Management
Stations are used
as system
components in
assembling
complete systems.
The two operator
station versions,
Master OS and MOD OS, are used control network. flexibility to add
in building dierent types ofSeveral control special hardware
operator applications. networks can be and software for
interconnected to specific applica-
2.3. Scalability give a complete tions such as
plant network weighing, fixed- and
which can share variable-speed
Advant OCS can be configuredcentrally
operator,
located
motor drives, safety
in a multitude of ways, dependinginformation and systems and
on the size and complexity of the engineering product quality
process. The initial investmentworkplaces. measurements and
can consist of stand-alone
process controllers and, control in, for
optionally, local operator stations example, the paper
for control and supervision of2.4. Openness industry. Second-
separate ma-chines and process and third-party
sections. Subsequently, several administrative,
pro-cess controllers can be The system is information, and
interconnected and together withfurther control can also be
central operator and informationstrengthened by the easily incorporated.
management stations build up a
I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212 203

The components
2.5. Cost-eectiveness are built upon
operating systems,
The step-by-step expansion one, a standard
capability of Advant OCS allows system (such as
users to add new functionality Unix or Windows),
without making existing and the other, a
equipment obsolete. The Fig. 2. The operator
station is assembled
proprietary real-
systems self-configuration time system.
capability eliminates the need for from components.
engi-neers to enter or edit To illustrate
topology descriptions when new dierent aspects of
stations are physically installed. component-based
New units can be added while the development and
system is in full operation. With maintenance, we
Advant OCS, system expansion is
therefore easy and cost-eective. shall further look at
two components:
2.6. Reusable components
1 OMF, a business type
of component with a
The Advant OCS products are high level of
component-based to minimize the functionality and a
complex internal
cost of maintenance and structure.
development. Fig. 2 shows the
component architecture of the 2 C++_complib is
operator station assembled from a basic and a
components.
The operator station consists of very general
a specific number of functional library
components and a set of standard component.
Advant components. These
components use the user
interface system (UIS) 2.7. OMF
component. Object management
facility (OMF) is a component
which handles the infrastructure OMF (Nubling et
and data management. OMF is al., 1999) is object-
similar to CORBA (OMG, 2000) in oriented mid-
that it provides a distributed dleware for
object model with data, operation industrial process
and event services. The UxBase automation. It
component provides drivers and encapsu-lates real-
other specific operating system time process
functions. Helper classes for control entities of
strings, lists, pointers, maps and almost every
other general-purpose classes are conceivable
available in the C++_complib description into
library component. objects that can be
accessed from
applications
running on
dierent platforms,
for example, Unix
and Windows NT.
Programming inter-
faces are available
for many
languages, such as
C, C++, Visual
Basic, Java,
Smalltalk and SQL
while interfaces to
the IEC 1131-3
(IEC, 1992) process
control languages
are under
development. OMF
is also adapted to
Mi-crosoft
component object
model (COM) via
adapters and
another
component called
OMF COM aware.
The adapters for
OPC (OLE for
process control)
(OPC, 1998) and OLE automation oers inter-faces to providing
are also implemented. Thanks to many important frameworks and
all these software interfaces, OMF communication tools for a wide
makes process and production protocols in the range of platforms
data available to the majority of field including
computer programmers and MasterNet, MOD and environments.
users, i.e., even to those not DCN, TCP/IP and These utilities are
necessarily involved in the Fieldbus well integrated into
industrial control field. For Foundation. These their respective
instance, it is easy to develop adapters make it surroundings, al-
applications in Microsoft Word, possible to build lowing developers
Excel and Access to access homogeneous
process informa-tion. OMF has control systems to retain the tools
been developed for demanding out of heteroge- and utilities they
real-time applications, and neous field prefer to work
incorporates features such as equipment and with.
real-time response, asynchronous disparate system
communications, standing nodes. 2.8. C++_complib
queries and priority scheduling of
data transfers. On one side OMF OMF reduces the
provides industry-standard time and cost of C++_complib is a
class library that contains
interfaces to software software devel- general-purpose classes
applications, and on the other, it opment such as containers, string
by management
204 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
components which veloping a
have been used to reusable
classes, file management classes,assemble process component
etc. The C++_complib library wasautomation requires three to
developed when no standardsystems. four times more
libraries, such as STL (Austern, resources than
1999), were available on the developing a
market. The main purpose of this3. Dierent reuse component, which
library was to improve thechallenges serves a particular
case (Szyperski,
eciency and quality, and 1998). The fact
promote the uniform usage of the3.1. Component that the
basic functions. generality and requirements of
C++_complib is not aeciency the components
component according to the are usually
definition in Szyperski (1998), Reuse principles incomplete and not
where a component is a unit ofplace high well understood
composition deployeddemands on (Sommerville,
reusable
independently of the product.components. The 1996) brings
However, in a developmentcomponents must additional level of
process C++_complib is treatedbe suciently gen- complexity. In the
in a very similar way as binary eral to cover the case of C+
dierent aspects of +_complib, the
components with sometheir use. At the
restrictions such as dynamicsame time they situation was
configuration. must be concrete simpler, because
and simple enough the functional
2.9. Experience to serve a requirements were
particular
requirement in an clear. It was
ecient way. De- relatively easy to
The Advant system is a define the
successful system and the main interface, which
reasons for its success are its was used by
component-based architecture dierent
giving flexibility, robustness, components in the
stability and compatibility, and
eective build and integration same way. The
pro-cedures. This type of situation was more
architecture is similar to product complicated with
line architectures (Bass et al., complex
1999). Some case studies (Bosch, components such
1999) have shown that product- as OMF. Although
line architec-tures are
successfully applied in small- and the basic concept
medium-sized enterprises of component
although there exist a number of functionality was
problems and challenging issues clear, the demands
(organization, training, on the component
information distribution, product interface and
variants, etc.). The Advant behavior were
experience shows that applying of
product-line architectures can be dierent in
successful for large organizations. dierent
However, the cost of achieving components and
products. Some
these features has been high. To components
suit the requirements of an open required a high
sys-tem, new ABB products have level of
always to be backward abstraction, while
compatible. It would have been others required the
easier to develop a new system interface to be on
a more detailed
that did not require being level. These
compatible with the previous dierent types of
systems. A guarantee that the require-ments
system is back-ward compatible is have led to the
a warranty that an existing creation of two
system will work with new levels of compo-
products and this makes the nents: OMF base,
including all low-
system trustworthy. level functions, and
Development with large OMF framework,
components which are easy to containing only a
reuse increases the eciency higher level of
significantly as com-pared with functions and with
reusing a smaller component that more pre-defined
could have been developed in- behavior and less
house at the same cost as its flexibility. In
purchase price. Advant OCS general,
products are examples of large requirements for
generality and eciency at the servicing software.
same time lead to the business,
implementation of several industrial, and 3 Evolution of
other pro-cesses technology used
variants of components which can in software
be used on a dierent abstraction should
permanently products.
level. In some specific cases, a increase the Evolution in
particular solution must be eciency of computer
provided. This type of so-lution is these processes, hardware and
usually beyond the object- improve the software tech-
oriented mecha-nisms, since such quality of the nology is so fast
components are on the higher products, that an
abstraction level. minimize the organization
production and manufacturing
3.2. System evolution maintenance long-life and
costs, etc. complex
products must
2 Evolution
Long-life products are most technology
of expect signifi-
cant technology
related
often aected by evolu-tion of dierent to changes during
domains. The the product life
dierent kinds: cycle. From the
advance of
technology in reliability and
the dierent risk point of
fields in which view, such orga-
1 Evolution of system software is used nizations prefer
requirements, functional and requires not to use the
non-functional. A consequence improved latest
of a continually com-petitive software. The
technology, but
market situation is a demand improvements
for continually improved may require a
completely new
because of the
demands of a
system performance. The ap-proach to or highly
systems control-ling and new functions in competitive mar-
I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212 205

The ucts or of a non-

development of reusable piece of
ket, are forced to adopt new reusable software. The
technology as it appears. The components would relation between
often unpredictable changes be easier
functional
if component
which must be made in requirements did requirements and
products cause delivery delays not evolve during the requirements
and increased pro-duction the time of from the products
costs. development. As a is expressed with
result of new the following
1 Evolution of technology used for the require-ments for equation:
product develop-ment. As in the the products, new X
case of products themselves, requirements for
new tech-nology and tools used the will be
com-ponents
defined. The RC RC0 aiRpi ;
in the development process more reusable a 0 6 ai 6 1;
appear frequently on the component is, the
market. Manufacturers are more demands are
faced with a dilemma to placed on it. A where RC0 denotes
adopt the new technology and number of direct requirements
possibly improve the requirements
coming from
of the compo-nent,
Rpi requirements of
development process at the dierent products the products Pi; ai
risk of short-term higher costs may be the same impact factors to
(for training and mi-gration) or or very similar, but the component and
to continue using the existing this is not RC is the total
technology and thereby miss necessarilycase for
the
all number of
an opportunity to lower component
develop-ment costs in the long requirements
passed to the requirements.
run. components. This To satisfy these
means that the requirements the
2 Evolution of society. Changes in number of
society (for example, requirements of components must be
reusable
environmental requirements or components grows updated more rapidly
changes in the rela-tions faster than that of and the new versions
between countries as in the EU) particular prod- must be released
can have a considerable impact more frequently than
on the demands on products (for the products using
example, new standards, new them.
currency, etc.) and on the
development process (relations The process of
between em-ployers and the change of
employees, working hours, etc.). components is
more dynamic in
3 Business changes. We face the early stage of
changes in government the component
policies, business integration lives. In that stage
processes, deregulation, etc.
These changes have an impact the components
on the nature of business, are less general
resulting, for example, in a and cannot
preference for short-term
planning rather than long-term respond to the new
planning and more stringent requirements of
time-to-market requirements. the products with-
4 Organizational changes. Changes out being changed.
in society and busi-ness have In later stages,
direct eect on business their generality
organizations. We can see a and adaptability
globalization process, more increase, and the
abrupt changes in business impact of the
operations and a demand for product
more flexi-ble structures and requirements
management procedures, just- become less
in-time deliveries of resources, significant. In this
services and skills. These period the
changes require another, fast products benefit
and flexible ap-proach to the from combinatorial
development process. and synergy
eects of
components reuse.
All these changes have a direct In the last stage of
or indirect impact on the product its life, the
life cycle. The ability to adapt to
these changes becomes the components are
crucial factor in achieving getting out-of-date,
business success (Brown, 2000). until they finally
In the following sections we become obsolete,
discuss some of these changes
and their consequences in the because of
development process and product dierent reasons:
life cycle. In-troduction of
new techniques,
3.3. Evolution of functional new development
requirements and run-time
platforms, new
development
paradigms, new
standards, etc. There is also acomponents, which required from C+
higher risk that the initial +_complib, and
component cohesion degeneratesare shown as steps new adapters and
when adding many changes, protocol support
which in turn requires more on the sec-ond were required from
eorts. OMF. The
graph. The development time
This process is illustrated in Fig. for these
component components was
3. The first graph shows the significantly
implements the shorter than for
growing number of requirements products: While
require-ments by new versions of a
for cer-tain products and for a product are typ-
its releases, which ically released
component being used by these every six months,
normally precede new versions of
products. The number of com-ponents are
the releases of the released as least
requirements of a common twice as often.
product if the After several years
component grows faster in the of intensive
requirements development and
beginning, saturates in the period improvement, the
originated from the components
t0 t1&, and grows again when became more
product stable and required
the compo-nent features become less eort for new
requirements. changes. In that
inadequate. Some of the product period the
Indeed this was frequency of the
requirements are satisfied withthe case with both releases has been
components we lowered, and
new releases of products andare analyzing here: especially the
New functions and eort has been
classes were significantly lower.
206 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
Unix HP-UX 8.x and dierent variants of the
continuing through products, and to maintain
new releases (HP- and improve them with
UX 9.x, 10.x), they the minimal eorts.
have been ported
to other Unix
platforms such as As an important
Digital Unix, and part of the reuse
also to completely concept was to
dierent platforms keep the high-level
such as Open VMS components
and Windows NT
family (NT 3.5, NT unchanged as far
4.0 and Windows as possible it was
2000). The decided to
products have encapsulate the
been developed
and main-tained in dierences
parallel. The between operating
challenge with this systems in low-
multi-platform level components.
development was This con-cept
to keep the
compatibility works, however,
between the only to some
extent. The
minimal activity
required for each
platform is to
rebuild the system
for that platform.
To make it possible
to rebuild the
software on every
platform, standard-
programming
languages C and
C++ have been
Fig. 3. To satisfy the requirements the reusable used.
component must be modified more often in the Unfortunately,
beginning of their life. dierent
implementations of
the C++ standard
in dif-ferent
compilers caused
New eorts for further problems in the
development of compo-nents code interpre-
tation and required
appeared with migration of the rewriting of
products on dierent platforms certain parts of the
and newer platform versions. code. To ensure
Although the functions of the that standard
products and components did not system services
change significantly a are available on all
considerable amount of work was platforms, the
done on the component level. POSIX standard
has been used.
3.4. Migration between dierent POSIX worked quite
platforms well on dierent
Unix plat-forms,
but much less so
During their several years of on Windows NT.
development, Advant products The second level of
have been ported to dierent
platforms. The reasons for this compatibility
were the customer requirement problem was
that the products should run on graphical user in-
specific platforms, and general terface (GUI). The
trends in the growing popularity
of certain operating systems. Of main dilemma was
course, at the same time, new whether to use
versions and variants of the exactly the same
platform already used appeared, GUI on every
sup-porting new, better and platform or to use
cheaper hardware. The Advant
products have migrated through the standard look
dierent platforms: Starting on and feel GUI for
each platform. This question
applied particularly on NT in
relation to Unix platforms.
Experience has shown that it is
not possi-ble to give a definitive
answer. In some cases it was
possible to use the same GUI and
the same graphical packages, but
in general, dierent GUIs were
imple-mented.
The main work regarding the
reuse of code on dif-ferent
platforms was performed on low-
level com-ponents such as
UxBase and OMF. While UxBase
provides dierent low-level
packages for every platform (for
example, dierent drivers), OMF
capsulated the dierences
directly in the code using
conditional com-pilation. OMF
itself is designed in such a way
that it was possible to divide the
code into two layers. One layer is
specific for each operating
system, and the other layer, with
the business logic, is
implemented for all of the
supported platforms. Reuse issues
on dierent platforms for C+
+_complib were easier, strictly
the package con-tains general
algorithms, which are not
depending on specific operating
system. Some problems
appeared, however, related to
dierent characteristics of
compilers on dierent platforms.
3.5. Compatibility

One of the most important

factors for successful re-usability
is the compatibility between
dierent versions of the
components. A component can be
replaced easily or added to new
parts of a system if it is
compatible with its previous
version. The compatibility
requirements are essential for
Advant products, since smooth
upgrading of systems, running for
many years, is required. Com-
patibility issues are relatively
simple when changes introduced
in the products are of
maintenance and
I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212 207

ASCII-support. 3.6. Development

These new environment
improvement nature only. Usingfunctions were
appropriate test plans, includingadded by new
regression tests, functional When
compatibility can be tested to a member-functions
reasonable extent. Morein the existing developing
complicated problems occur whenclasses and by reusable
new changes introduced in a re-adding new classes components
usable component eliminate theusing the several di-
compatibility. In such a case,inheritance mech- mensions of the
additional software, which cananism for reusing development
manage both ver-sions, must bethe already process must be
written. existing classes. consid-ered:
A typical example of such anThe in-troduction
incompatible change is a changeof the same
in the communication protocolfunctions in 1 Support for
between OMF clients and servers.dierent formats development of
All dierent versions of OMF musthave led to components on
be able to talk to each other to additional eorts in dierent
make the system flexible andreusing them. In
open. It is possible to havemost of the cases platforms.
dierent combinations ofthe old format has
operating systems and versions ofbeen replaced by 2 Support for
OMF and it still works. This hasthe new one, with development of
been solved with an algorithmthe help of simple dierent variants of
that ensures the transmission oftools built just for com-ponents for
correct data format. If two OMFthis purpose. In dierent products.
nodes have the same version,some other cases,
they talk in their native protocol. due to non-proper 3 Support for
planning and development
If an old OMF node talks with a
new, the new OMF is responsible prioritizing the and
for converting the data to the newtime-to-market maintenance of
format, this being designatedrequire-ments, dier-ent
RMIR (receiver makes it right).both old and new versions of
If a new OMF sends data to anformats have been components for
older, the older OMF cannotused in the same dierent product
convert the data since it issource modules ver-sions.
unaware of the new protocol. Inwhich have led to
this case the newer OMF mustlower main- 4 Independent
send in the old protocol format,tainability and to development of
SMIR (sender makes it right). some extent to
This algorithm builds on that factlower quality of the components and
all machines know about eachproducts. prod-ucts.
other and that they also know
what protocol they talk. However,
if an OMF-based node does not To cope with
know of the other node then it these types of
can always send in a pre-defined problems, it is not
protocol referred to as well su-cient to have
known format. All nodes do appropriate
recognize this protocol and can product
translate from it. This algorithm architecture and
minimizes the number of data component design.
con-versions between the nodes. Development
In the case of C++_complib the environment
support is also
problems with compatibility were essential. The
somewhat dierent. New development
demands on the same classes environment must
and functions appeared because permit an ecient
of new standards and technology. work in the project
One example is the use of C++ editing, com-
templates. When the template piling, building,
technology be-came suciently debugging and
testing. Parallel
mature, the new requirements and distributed
were placed for C++_complib: All development must
the classes were to be re- also be supported,
implemented as template classes. be-cause the same
The reason for this was the components are to
requirement for using basic be developed and
classes in a more general and maintained at the
ecient way. Another example is same time on
Unicode support in addition to dierent platforms.
This requires the
use of a powerful configuration C1-V2 uses the
manage-ment (CM) tool, and component version
definition of an advanced CM C2-V1, an older
process. version.
Integrating
The CM process support exists dierent
on two levels. First on the source-
code level, where source-code
files are under version
management and binary files are
built. The second level is the
product integration phase. The
prod-uct built must contain a
consistent set of component
versions. For example, Fig. 4
shows an inconsistent set of Fig. 4. An example of
components. The product version
P1-V2 uses the component inconsistent
versions C1-V2 and C2-V2. At the component
same time the component version integration.
208 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
independent of the When it is about
prod-ucts gives complex products, it
versions of the same component mayseveral
cause unpredict-able behavior of theadvantages. is impossible to
The
product. functions are manually track
broken down into dependencies
Another important aspect of CMsmaller entities between the
in developing re-usablethat are easier to
construct, develop
components, but a
components is changeand maintain. The tool support for
management. Changeindependent checking consistency
management keeps track ofcomponent de- must exist.
changes on the logical level, forvelopment
example, error reports, andfacilitates In the Advant
manages their relations withdistributed development the
implemented physical changesdevelopment, components were
treated as separate
(i.e., changes of documentation,which is common
products even if
source code, etc.). Becausein enterprises.
large
they were
change re-quests (for example,Development of developed within
functional requirements or errorcompo-nents the enterprise. To
reports) come from dierentindependently of have this approach
products, it is important toproduct or other helped when third-
party components
register information about thecomponent were used they
source of change re-quests. It isdevelopment also were all managed
also important to relate a changeintroduces a in a uniform way.
request from one product to othernumber
problems. The
of Every component
products. The following questionscomponent contained a file
and called import file
must be answered: What impactproduct test that included a
can the im-plemented changebecome more specification of all
have on other products? If andicult. On the component
error appears in one product,component level, a versions used to
does it appear in other prod-ucts?proper test build the
Possible implications must beenvironment must component. When
investigated, and if necessary,be built, which the final product
the users of the productsoften must include was assembled
a number of other from the
concerned must be informed. components or components, the
The development environmenteven maybe the import file has
designated Softwareentire product. been used for
Development Environment (SDE)integration Another problem is the integration and
(Crnkovic, 1997) is used inconfiguration problem.and A
check-ing if the
developing Advant products. It ismust be avoided.
situation shown in Fig. 4 consistent sets of
an internally built program the components
package which encapsulates have been
dierent tools, and provides selected. The
support for parallel development. development
The CM tool, based on RCS (Tichy, environment,
1985), provides support for all CM based on make,
disciplines such as change was set up to use
the import files and
manage-ment, works pace the common
management, build management, product structure.
etc. SDE runs on dierent All released
platforms with slightly modified components were
functions. For example, the build stored in the
process is based on Makefiles and product structure
autoconf on Unix platforms, while for availability to
Mi-crosoft Developer Studio with others. An-other
additional Project Set-tings is used structure was used
on Windows NT. The main during
objective of SDE is to keep the development of a
source-code in one place under com-ponent. The
version control. Dierent versions component was
of components are managed exported to the
using baselines, and change product structure
requests. Change requests are when the
also under version control, which development was
gives a possibility of acquiring finished. Using this
information useful for project approach it was
follow-up, for every change from shown that the
registration to imple-mentation architecture design
and release (Crnkovic and Willfor, plays a crucial role.
1998). A good
architecture with
clear and dis-
3.7. Independent component tinguished
development relations between
components
facilitates the
development
Component development process.
 The whole developmentnew ver-sions of installations
process is complex and re-quiresdierent products consistent.
organized and planned support,which already exist The relations
which is essen-tial for ecientin several versions. between
and successful development ofTo minimize this components,
reusable components and of products and
applications using these. cumbersome systems must be
process, ABB carefully registered
adopted a policy of to make possible
3.8. The maintenance process the tracing of
avoiding the errors on all levels.
generation of and A systematic use of
soft-ware
The maintenance process issupply of specific configuration
also complex, because it must bepatches to selected management has a
handled on dierent levels: Oncustomers. In- crucial role in the
maintenance
the system level, wherestead, revised process.
customers report their problems,products To support the
on the product level, where errorsincorporating sets maintenance
detected in a specific productof patches were process, Advant
prod-ucts and
version are reported, and finallygenerated and component
on the component level, where delivered to all specifications
the fault is located. Thecustomers with together with error
modification of the componentmaintenance reports are stored
in several classes
can have an impact on othercontracts, to keep of repositories (see
components and other products,customer Fig. 5).
which can lead to an explosion of
I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212 209

This procedure is the highest priority

not unique to is related to
component-based products and
development. It is customers. On the
a means of development level,
managing complex
prod-ucts and of all changes
maintaining many registered are re-
products. What is lated primarily to
spe-cific to the components.
component-based Information about
approach is the both products and
mapping between components is
products and stored on the
components and
the management development level.
of error reports on Error management
product and on this level is the
component level, most com-plex. An
the most dicult error may be
part of the detected in a
management. In specific product
this case the entire version, but may
procedure is
localized on the also be present in
PMR level, i.e., other products and
Fig. 5. Dierent levels of error product level. On other product
report management. the customer side, versions. The error
information with may be discovered
in one component,
but it can be
present in dierent
ver-sions of that
On the highest level, the component. The
repository managing cus-tomer problem can be
reports (CCRP) makes it possible solved in one
for service personnel to provide component
customers with prompt support. version, but it also
Information saved on this level is may be necessary
customer- and prod-uct-oriented. to solve it in
Reports indicating a product several. The
problem are registered in the revised component
product maintenance report versions are
repository (PMR) where all known eventually
problems related to products and subsequently
components are filed. Also, integrated into
product structure in-formation is new versions of
stored on this level. The product one or several
structure, showing dependencies products. This
between products and compo- multi-dimensional
nents, provides product and prob-lem (many
component developers with error reports,
assistance in relating error reports impact on dierent
to the source of the problem on versions of
both product and component components and
levels. A similar error products, the
management process is defined solution included in
for prod-ucts in the beta phase, dif-ferent
i.e., not yet released. All of the components and
problems identified in this phase product versions)
(typically by test groups) are is only par-tially
registered in the form of pre- managed
release problem reports (PPR). automatically, as
These problems are either solved many steps in the
before the product is released or process require
are reclassified as product error direct human
reports and saved in PMR. Any
change applied in code or decisions (for
documentation is under change example, a
control, and each change is decision if a
initiated by a change request. If a solution to a
change required comes from an problem will or will
error report, a change request will not be included in
be generated from a PMR. When a the next product
change made in a component is release). Although
tested and verified, the action the whole
descrip-tion is exported to the procedure is
correlating PMR, propagated to carefully designed
the products involved and finally and rigorously
returned to the cus-tomer via the followed, it has
CCRP repository. happened on
occasions that
unexpected changes have been4. Integrating severe problems,
included, and that changesstandard components especially in dis-
intended for inclusion were tributed real-time
absent from new product and safety-critical
releases. For more details of the In recent years systems, with long-
entire maintenance process seethe demands of period guarantees.
Kajko-Mattson (1999a) and Kajko-customers on In addition to these
Mattson (1999b). systems have new re-quirements,
Another important subject ischanged. time-to-market
the maintenance of ex-ternalCustomers require demands have
components. It has been shownintegration with become a very
that external components muststandard important factor.
be treated in the same way astechnologies and
internal components. All known These factors
errors and the complete errorthe use of standard and other changes
management process for internalapplica-tions in the in software and
and external compo-nents areproducts they buy. hardware
treated in a similar way. The list ofThis is a definite technology
known, and corrected errors intrend on the (Aoyama, 1998)
external components is important have introduced a
for developers, product managersmarket but there is new paradigm in
and service people. The cost of little awareness of the development
maintaining components, eventhe possible process. The devel-
those main-tained by others,problems involved. opment process is
must be taken into consideration. An improper use of now focused on the
standard com- use of standard
ponents can cause
210 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
more than once. At
and de facto standard In the middle of one point in time,
components, outsourcing, COTS 1980s, ABB Advant it was necessary to
and the production of
components. At the same time, products were abandon the
final products are no longer completely existing solutions
closed, monolith systems, but are proprietary in favor of new
instead component-based systems with
products that can be integrated internally devel- solutions based on
with other products available on oped hardware, existing
the market. basic and components and
This new paradigm in the application technologies. To il-
development process and software. In the
marketing strategy has beginning of lustrate the
introduced new problems and 1990s, hardware
standard migration process
raised new questions (McKinney, components we discuss the
and possibility of
1999): software platforms
were purchased replacing OMF and
while the real-time C++_complib with
1 The development process has additions and standard
been changed. Devel-opers are application
now not only designers and software were components.
programmers, they are also developed in-
integrators and marketing ternally. Experience from
investigators. Are the new The these examples
development methods system is now showed that it is
established? Are the developed further easier to replace a
developers properly educated? using components component if the
replacement
2 What are the criteria for the based on new, process is made in
selection of a compo-nent? standard
technologies.
small incremental
steps. Allowing the
How can we guarantee that a During this new component to
standard compo-nent fulfills development, further new coexist with the old
the product requirements? components become one makes it easier
available on the market.
ABB faced this issue to be backward
compatible and the
3 What are the maintenance change will be
aspects? Who is responsi-ble for smooth.
the maintenance? What can be
expected of the updating and
upgrading of components? How 4.2. Replacing OMF
can we satisfy the compatibility with DCOM
and reliability requirements?
4 What is the trend on the Moving from a
market? What can we expect to UNIX-based system
buy not only today but also on to a system based
the day we begin delivering our on Windows NT
product? had serious eect
on the system
5 When developing a component, architecture.
how can we guaran-tee that Microsoft
the proper standard is used? components using
Which stan-dard will be valid in a new object model
5, 10 years? were available,
namely COM/DCOM
(Box, 1998). DCOM
All these questions must be has functionality
considered before be-ginning a similar to that of
component-based development OMF and this
project. Jose-fsson (1999)
presents certain became a new
recommendations to the issue when DCOM
component integrator for use as was released.
guidelines: Test the imported Should ABB
component in the environment continue to
where it is to run and limit the develop its
practical number of component
sup-pliers to minimize the proprietary OMF or
compatibility problems. Make sure change to a new
that the supplier is evaluated standard
before a long-term agreement is component? The
signed. problem was that
The focus of development DCOM did not have
environment support should be all the functionality
transferred from the edit-build- of OMF and vice
test cycle to the component versa. The domains
integration-test cycle.
Configuration management must overlap only par-
give more consideration to run- tially.
time phase (Larsson and
Crnkovic, 1999). A subscription of
data with various
capabilities can be
4.1. Replacing internal components made in OMF, and
with standard compo-nents this subscription
functionality is not supported byadapted to COM proprietary ex-
DOCM. On the other hand, DCOMwith an adapter tensions adding
can create objects when they aredesignated OMF the functions
required and not like OMF whereCOM aware. This missing from COM.
objects are created before thefunction-ality All the
actual use of them. Bothhelped COM communication
technologies support objectdevelopers access
OMF objects and
with the current
system was to be
communication and in this area itvice versa. made through the
is easier to replace OMF withHowever, this OMF COM. This
DCOM. solution to the solution made it
If the decision was made toproblem using two easy to remove the
continue with OMF, all the new dierent
models was not
object old OMF and
replace it with COM
components that run on top ofoptimal since it in small steps over
COM could not be used, which added overhead in time. Adapters are
would drastically reduce thethe very useful when a
possibilities of integration withcommunication. new component is
other, third-party components. OnNor was it possible to used in parallel
the other hand, it would require to match the data with an existing
considerable work to make thetypes one to one, one (Rine et al.,
current system run on top ofwhich made the 1999). More
COM. This was the dilemma of solution limited. A
decision was taken
adapters to other
systems such as
COM versus OMF. to build the new Orbix(CORBA) and
To begin with, OMF wassystem on COM Fieldbus
technologies with Foundation were
I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212 211

approach pre-vents To manage

the system from dependencies, a
constructed. If the externalusing old graphic
systems have similar data types itcomponents, but it representation of
the configuration is
is fairly straightforward to build adoes not guarantee introduced. The
framework for adapters where theits functionality graphs are then
parts that take care of the pro- when components
new
are
placed
version
under
control.
prietary system can be reused.installed. Applying This information
New systems can be ac-cessed byideas from can be used to
adding a server and client stub to configuration man- predict which
components will be
the adapter framework. To beagement, such as aected by a
able to build functional adaptersversion and replacement or
between two middlewarechange installation of a
new component.
components it is important tomanagement,managing
in
have the capability to createcomponents is an It is generally
remote calls dynamically. Forapproach dicult to identify
which
instance the dynamic invocationcan be used to components during
interface (DII) in CORBA can besolve some of the run-time and to
used. If the middleware does notproblems. obtain their version
have this possibility it might be A certain level of information. When
possible to generate codeconfiguration the components
automatically that takes care ofcontrol will
achieved when it is
be
are identified it is
the dierent types of calls whichpossible to identify possible to build
are going to be placed through components
their versions and
with
graphs of
the adapter to the other system. dependencies on dependencies,
other components.
Information about which can be
4.3. Replacing C++_complib with STL a system can be
placed under represented in
version control for various ways and
later retrieval. This placed under
To switch from C++_complib tomakes to
it possible
compare
STL (Austern, 1999) was muchdierent baselines configuration
of
easier because STL covers almostconfiguration. a system control (Larsson,
all the C++_complib functions 2000).
and provides additional func- To improve the
tionality. Still, much work control of external
reminded to be done, since all the components, they
codes using C++_complib had to can be placed
under change
be changed to be able to use STL management to
instead. The decision was taken permit the
to continue using both monitoring of
components and to use STL changes and bugs.
whenever a new functionality was Instead of
added. After a time the use of old attaching source
code files to
components was reduced and the change requests,
inter-nal maintenance cost which is common
reduced. In some cases in the in change
same components both libraries management, the
were used, which gave some name and version
disadvantages, especially in the of the com-ponent
can be used to
maintenance pro-cess. track changes.
When a problem
4.4. Managing evolution of standard report is analyzed,
the outcome can
components be a change
request for each
component
Use of standard components involved. Each
implies less control on them such change
(Larsson and Crnkovic, 1999, request can
2000; Cook and Dage, 1999), contain a list of all
especially if the components are the changed
updated at run-time. A system of source files or a
components is usually configured description of the
once only during the build-time patches if the
when known and tested versions component is
of components are used. Later, external. Patches
when the sys-tem evolves with from the
new versions of components, the
sys-tem itself has no mechanism component vendor
to detect if new components have must be stored to
been installed. There might be a permit recreation
check that the version of of the same
replacement component is at configuration later.
least the same as or newer than In cases where the
the original version. This high quality of
products must be as-sured, theorientation reusable
enterprise developing productsprovides many components. The
must have special, well-definedadvantages, but it more a reusable
relations to the componentalso requires component is
vendors for the support andsystematic developed, the
maintenance. approach in design more complex is
planning, extensive the development
development, process, and more
support of a more support is required
5. Conclusion complex from the
maintenance organization.
process, and in Even when all
We have presented the ABBgeneral more these requirements
Advant control systems (OCS) asconsider-ation are satisfied, it can
a successful example of thebeing given to happen that there
development of a component-components. It is are unpredictable
based system. The success ofnot certain that an extra costs. One
example illustrate
these systems on the market has otherwise this: In the early
been primarily the result of appro-successful stage of the ABB
priate functionality and quality.development Advant OCS
development,
Success in development,organization can insucient
maintenance and continuedsucceed consideration was
in the given to Windows
improvement of the systems hasdevelopment of NT and ABB had to
been achieved by a carefulreusable pay the price for
architecture design, where thecomponents this oversight
or when it suddenly
main principle is the reuse ofproducts based on became clear
components. The reuse
212 I. Crnkovic, M. Larsson / The Journal of Systems and Software 61 (2002) 201212
Lecture Notes in of IEEE International
Computer Science. Conference on
that Windows NT would be the Springer, Berlin. Software
next operating plat-form. The new IEC, 1992.
Maintenance. ACM
Programmable
product versions on the new Press, New York.
platform have been developed by Controllers
Programming
Part 3,
Lan- Kajko-Mattson, M.,
porting the software from the old guages, IEC 1131.-3, 1999b. Maintenance
platform, but the costs were IEC, Geneva. at ABB (II): Change
execution processes
significantly greater than if the (the state of
design had been done moreJosefsson, Program
M., 1999. practice). In:
Proceedings of IEEE
independent of the first platform. varukomponenter i International
Conference on
Another problem we have praktiken -attkopa Software
addressed is the question of tid och prestera mer, Maintenance. ACM
Press, New York.
moving to new technologies Report V0400.78, Larsson, M., 2000. Applying
which require the re-creation of Sveriges configuration
the components or the inclusion Verkstadsindus-trier. management
of standard components availableKajko-Mattson, M., 1999a.
Maintenance at ABB (I): techniques to
on the market. In both cases it Software prob-lem component-based
can be dicult to keep or achieve administration processes (the
systems, Licentiate
the same functionality as the state of practice). In:
Proceedings Thesis Dissertation
original components had. 2000-007, Department
However, it seems that the of Information
process of replacing proprietary Technology, Uppsala
components by standard University.
components available from third Larsson, M., Crnkovic, I.,
parties is inevitable and then it is 1999. New
important to have a proper challenges for
configuration
strategy for migrating from old management. In:
components to the new ones. Proceedings of the
9th Symposium on
System
Configuration
Management.
Lecture Notes in
References Computer Science,
vol. 1675. Springer,
New York.
ABB, ABB Automation Products, Advant. Larsson, M., Crnkovic, I.,
Available from http:// 2000. Component
www.advantocs.com. configuration
manage-ment. In:
Aoyama, M., 1998. New age of software Proceedings of the
development: How compo-nent-based 5th Workshop on
software engineering changes the way Component Oriented
of software development. In: Programming.
Proceedings of the 1st workshop on
Component Based Software McKinney, D., 1999.
Engineering. Impact of
Austern, M., 1999. Generic Programming commercial o-the-
shelf (COTS)
and STL. Addison-Wesley, Reading, MA. software on the
interface between
Bass, L., Campbell, G., Clements, P., systems and
Northrop, L., Smith, D., 1999. Third software engineer-
product line practice report, Technical ing. In: Proceedings
of the 21st
Report, CMU/SEI-99-TR.003, Software International
Engineering Institute. Conference on
Bosch, J., 1999. Product-line architectures Software
Engineering. ACM
in industry: A case study. In: Press, New York.
Proceedings of 21st International Nubling, M., Popp, C.,
Conference on Software Engineering. Zeidler, C., 1999.
ACM Press, New York. OMF an object
Box, D., 1998. Essential COM. Addison-Wesley, Reading, MA. request broker for
Brown, A., 2000. Large-scale Component-based Development. the process control
Pren- application domain.
In: Proceedings of
tice-Hall, Englewood Clis, NJ. the 3rd International
Cook, J.E., Dage, J.A., 1999. Highly reliable Conference on
Enterprise
upgrading of com-ponents. In: Distributed Object
Proceedings of 21st International Computing EDOC.
Conference on Software Engineering. IEEE Computer
ACM Press, New York. Society, Silver
Spring.
Crnkovic, I., 1997. Experience with OMG, 2000. The common object
Change-oriented SCM Tools. In: request broker: Architecture
Proceedings of the 7th Symposium on and specification, Report v2.4,
Software Configuration Management. OMG Standards Collection,
Lecture Notes in Computer Science, vol. OMG.
1235. Springer, Berlin.
Crnkovic, I., Willfor, P., 1998. Change OPC, 1998. OLE for
measurements in an SCM Process. In:
Proceedings of the 8th Symposium on process control,
Software Configuration Management.
 Report v1.0, OPC Standards Collection,of Zagreb, Croatia. He Component-based
OPC Foundation. worked at ABB during Development and in
19851997, where he general Software
was responsible for Engineering.
Rine, D., Nada, N., Jaber, K., 1999. Usingsoftware development
adapters to reduce interactionenvironments. He was a
complexity in reusable component- project leader and Magnus Larsson is an
based software development. In:manager of a group industrial Ph.D. student
Proceedings of the 5th Symposium onwhich developed employed by ABB
Software Reusability. ACM Press, NewSoftware Development Automation Products at
York. Envi-ronment tools and the research and
development
Sommerville, I., 1996. Softwaremethods for distributed
development and mainte-
department since 1993.
He received a B.Sc. at
Engineering. Addison-Wesley, New York. nance of real-time Malardalen University
systems. He is the 1993 and an M.Sc. in
computer science at
Szyperski, C., 1998. Component SoftwareComputer Science Uppsala University
Beyond Object-Oriented Programming.Laboratory leader at the 1995. He is interested
Malardalen University in Component-based
Addison-Wesley, New York. and he leads the development, Software
Industrial IT research Configuration Manage-
ment and real-time
Tichy, W., 1985. RCS A system for group at Malardalen systems. He is a
version control. IEEE Software andUniversity. He is the co- member of the
organizer and a member Configuration
Practice Experiance 15 (7). of the program Management group at
committee of several the association of
Swedish Engineering
workshops related to Indus-tries. He
Software Engineering and presented the licentiate
Ivica Crnkovic is a professor of IndustrialConfiguration thesis Applying
Software Engineering at the MalardalenManagement. His main Configuration
University, Sweden. He received an M.Sc. in re-search interests are Management
Computer Science 1979, an M.Sc. in Software
Techniques to
Configuration Component-based
Theoretical Physics 1984, and a Ph.D. in Management, Systems in December
Computer Science 1991, all at the University 2000.