See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/2435298 Components vs. Objects
Article · November 2000 Source: CiteSeer
CITATIONS READS
0 46
2 authors, including:
Luigia Petre
Åbo Akademi University
79 PUBLICATIONS 298 CITATIONS SEE PROFILE
All content following this page was uploaded by Luigia Petre on 03 July 2014. The user has requested enhancement of the downloaded file.
Components vs Ob jects Luigia Petre
Turku Centre for Computer Science TUCS Technical Rep orts
No Octob er
Components vs Ob jects Luigia Petre
Turku Centre for Computer Science TUCS Technical Rep ort No Octob er
ISBN X ISSN
faces Both comp
Abstract
Comp onentbased software engineering means constructing new systems from already existing serviceproviding components Ob jectbased software engi
similar app earance in
shing b etween these two notions In dierence b etween comp onents and
on this we also prop ose a guideline
incorp orates b oth notions and exploits comp p otential
new system in terms of interacting distinct
neering means constructing a
units of information and services called objects Both comp onents and jects have encapsulation prop erties and are accessed via welldened inter
onents and ob
to alleviate its evolution phase Finally b oth notions are
jects are considered to improve the reuse thought of b eing natural abstractions of realworld entities Moreover a
of software and
realworld entity can b e mo delled or implemented using either notion
Keywords Software Engineering Comp onents Ob
ob jects at their real jects
Their distingui this pap er we examine the conceptual ob jects and aim at clarifying it Based for a software engineering pro cess that
abstract mo delling gives rise onents and
TUCS Research Group Programming Metho dology Group
to confusion in
ob
Intro duction
concepts very often encountered in current sof
Comp onents and ob jects are
tware engineering terminology By
abstraction reuse easier evolution
p onents and ob jects can b e seen at
providing some services via welldened interfaces Both
used in mo delling the same system Their common goals similar structure
and likely b enets main questions are
of them rise the question of their dierences More
What is
Why do In trying to
etween comp
answer to these questions we examine the conceptual die
academics seem not we dierentiate the
to b e answered
the essential dierence b
onents and ob
aim to clarify it Based on
we need them b oth
jects
using them
b enets like natural software
or encapsulation are aimed at Both
com
certain granularity levels as
black b
can b e even
this software a prop er man ner An example emphasising the dierence as well as the guideline is also
rence b etween comp
we prop ose a guideline of how to make use of b oth notions during a
onents and ob jects and
engineering pro cess in order to exploit their advantages in
provided
The question of comparing comp
onents and ob jects has
efo to p erceive clearly and arguably to what degree can
app eared b such a discussion left students and programmers alike with controversities Moreover even
re most notably in
However the result of
two notions The
ob jects work in a certain application area with particular stra
p eople who can dierentiate comp o software construction or analysis These strategies emb ed certain
nents and
tegies for
interpretations of comp
academics that are so involved with unnecessary Either category we
onents and ob jects
a con sider some classical description of these notions and based on it we analyse
more systematic analysis of
comp onents and
ob jects In
this pap
er we
ob jects following the criteria of usage
reference and natu
comp onents and
re The result of the analysis can b e summarized as follows Comp onents
and ob jects are essentially dierent and
her in constructing large software pro ducts when following certain patterns
Consequently the contribution of the pap er consists in separating these software engineering concepts towards the b enet of b etter using them
two in a
software construction pro cess
Overview In and the comp
sections onentbased software
and we
Or they
the matter that consider this debate
consider it generally useful to take
shortly describ e the comp onent concept engineering as well as the ob jects and
quite advantageous to be used toget
oxes precisely two
are highly trained
the ob jectbased software construction resp ectively In section comp o nents and ob jects are analysed in parallel pointing out their key dierences
Section prop oses a software engineering pro cess that makes use concepts Finally the conclusions are presented in section
of b oth
Comp onents
The comp onentoriented style of programming consists in developing software comp onents as well as in assembling new software systems from them The software comp onent term has b een coined ab out three decades ago as a logical solution to the software engineering crisis This notion was
based on
and consumers in other engineering elds The foremost b enet of having a comp onentbased software industry consists in the reuse of software that it
an analogy to
plugandplay interop erability available to pro ducers
provides for Moreover comp onentbased software pro ducts are
have an increased exibility and robustness as well as a shortened time to market The comp onentbased development is not widespread yet but the
exp erience of thirty years is now used to ground it as
claimed to
construction metho d
Software comp onents were dened by Szyp erski in as units of com
p osition with contractually sp ecied interfaces and explicit context dep en dencies only In addition he states that a software comp onent can b e
deployed indep endently and is sub
From this denition we can resume comp onents as sp ecied by
ject to
comp osition by third parties
one party and nally used by a p ossible third party The third party uses the comp onent b eing based on the sp ecication of its
implemented by another party
has no information ab out the
comp onent may
comp onents All
manner as context dep endencies Comp onents using interfaces from
interfaces and
comp onent Comp onents are binary units providing the implementation of
the services sp ecied in their interfaces The
contractual ie it binds together a user of the interface and a provider of an implementation of the interface in a balanced manner The contract of the interface should b e precise enough to sp ecify the functionality of the latter
but also nondeterministic in order to allow the provider of
tion to cho ose its
the implementa own solution For providing the required functionality a
other are
software system that in
need additional system supp ort or other services from
other a contractual each a comp onentbased its turn provides some functionality using the col lab oration of the participating comp onents A system built this way is more
these requirements are clearly sp ecied in
said to b e comp osed together The result is
a fundamental software
actual implementation of the
sp ecication of
an interface is
Figure Mail Delivery System Comp onent View
robust as it is formed of smaller comp onents already tested by the market
Driver
Drive Load Transport
reused and thus themselves robust
red services of the participating comp onents the exibility of
MDS
replacing old and less ecient
the programming task coop eratively Each
the system is implementations
increased by the p ossibility of
provides for
to market is shortened
with new and
more p erformant ones
of the software pro duct Finally the time
evolution
since only
the comp onents implementing them has to b e p erformed
As the system sp ecies only the requi
This issue also
a smo other
the sp ecication of the required services and the assemblation of
As an example of a comp onentbased system
consider a
mail delivery
simulation Of
livery System MDS
of the latter two The system is required to send parcels to their destina
the three comp onents participating
in the system
well as to conrm
former uses
their delivery The comp onent MDS implements
tions as
two services SendParcel and
ve and Load parcels implemented here as the service Transport implemented here
Driver and Post Vehicle the
Mail De the services
Send Parcel Confirm Delivery
ConrmDelivery and requires the
Ob jects
The ob jectoriented style of programming consists in developing appli
cations built of ob jects that communicate with each other in order to
solve
ecic ob jectoriented OO approach consists in its mo dularity The OOapproach originated in OO programming and gained its rst big success with the programming of graphical interfaces Later it was generalized to many areas such as dis tributed systems and databases software engineering articial
and narrow resp
onsibilities and thus one advantage of the
Post Vehicle
services Dri by the Driver comp onent as well
by the Post Vehicle comp onent the interacting comp onents and their interfaces are represented
In Figure
using a UML comp onent diagram
ob ject is delegated with sp
Driver
Figure Mail Delivery System Ob ject View
Outage
0..1
On leave drives
class to
value The class denes the behaviour of
data typ e characterised by a set of prop erties attributes and op erations
which it b elongs and a state
complex abstract
created by a inherits from
a subset of the sup
*
Task Door Bus Car
intelligence
OOapproach to
lying the problem domain are rather stable elements Hence
solutions that
Conceptually an ob ject is
and information systems The
a software product consist in the fact that the ob jects under
ease this evolution encouraging the reuse of software
can have asso ciated items of information and can
b e manipulated by a set
an abstraction from a realworld entity that
of op erations sp
abstraction of a data item characterised by a unique and invariant identier a
ecically applicable to
it More represented by
the ob ject A
its ob jects together with the means for creating ob jects with
The implementation of ob ject op erations
common to
these prop erties The state only as a consequence of op
class is an
of an ob erations p
ontaneously but
ject cannot change sp
ob jects erclass extent The ob jects in the sub class extent must
is constrained by the prop erties of
suitable class decomp osition was found for the system under development
Post vehicle
erformed on it The
set of all
A class sub classderived class another class sup erclassbase class if the sub class extent is
class form the class extent
is also hidden from other ob
An OOsoftware system is modular due to
supp ort all the op
extent However the ob jects in the subclass extent may
op erations in
directly access other ob ject states
erations that are supp orted by the ob jects
in the sup erclass carry out these a sp ecic way and they may also have additional op erations Ob jects can interact by using each others operations They are not allowed to
jects
participate to it Each ob ject is concerned with
its corresp onding class
Provided that
a
main b enets of an
to a software pro duct anticipates the
an OOapproach need of the latter to evolve and favours
Truck
precisely an
a simple or more
the collection of ob jects that its own responsibilities and
Engine
Wheel
ob ject is an
0..1 On duty
fo cusing on classes construction rather than on the system as a whole eases the software engineering pro cess Moreover as classes are abstract data typ es generalization relationships b etween them inheritance improve the
and Door It can
Bus Truck and Car A Driver class has an asso ciation relationship with the
reuse of design and implementation Also
realworld entities are quite fundamental
with the hiding of the implementation from other ob jects contribute to an
easier evolution phase As an example of
and stable
delling
Figure that underlies the example also used in the previous section The
Post Vehicle class
is comp osed of three other classes ie Engine Wheel
diagram
Given the traditional description of previous sections we can notice some
it seems that
for the considered pro duct
an ob jectbased system consider the class diagram in
also b e sp ecialised to dierent classes of vehicles such
as
Post Vehicle class denoting that
several Post Vehicle instances Two other asso ciation relationships of the
the Driver instances are
allowed to drive
class Driver denote that
for instance on holiday or on a sickness leave and have at most one task to
its instances can b e on
at most one leave at a time
for instance of
The Conceptual Dierence
on the size
for software architecture and comp onents for implementation Moreover as
p erform at
In Figure these classes and their relationships are shown using a UML class
a time
transp orting the
mail to given destinations
components and ob jects as shown in common features these notions supp ort
Thus b oth of
dened interfaces Both comp onents and
the reuse of software and to alleviate its evolution phase They are thought of b eing natural abstractions of realworld entities Moreover a realworld
them have encapsulation prop erties and are accessed via
ob jects are considered to improve
entity can b e mo delled or implemented using either notion
well see Figures
and
In trying to dierentiate b etween these notions some intuitive grip
provide further insight We might say that
than ob jects We might also argue for comp
tities for software architecture an early software engineering phase
while software engine ering However none of these arguments are appropriate since they dep end
ob jects are more suitable in the implementation phase late
of the pro ject At dierent granularity levels
ob jects can b e used
we admitted that
notion it is dicult to say what do es it mean that comp onents are
the same realworld entity can b e mo delled with
either bigger
ob jects mo
This fact together
can comp onents are bigger entities
onents b
eing more suitable en
the
than ob jects
What we b elieve to
b e the signicant dierence b etween comp onents and roles While ob jects are suitable for describing real world entities comp onents are suitable for describing the services of real
ob jects relies in their
world entities That
of a system while comp onents are suitable for describing its functionality
p erform for the
can e considered as a more mathematical appro
rules ob
a dedicated theory of ob jects
is ob jects are
suitable for
describing the problem domain
From this p ersp ective the
while the comp onents partition its service space Expressed dierently the
ob jects of a system partition the state space
syntagm comp
Service vs identity refers in fact to the manner of using services from
onents vs ob
jects can b
e understo o
d as service vs identity
comp onents and ob
the required service and to use any comp onent providing an implementation
jects Using a service from
a comp
onent means to
sp ecify
ject means to
As an example consider a software pro ject that uses
of that service Using a service from an ob
is to be used and to use the service that particular ob ject with its particular
state can provide
sp ecify which ob
ject
the services of a comp onent that is able to a sp ecied amount of time and requires a salary of no more than x The identity of this component is of no interest
Driver comp
drive dierent typ es of
has been recently fo cuses on the self dynamic dispat ch classes inheritance prototyping subtyping covariance contravariance and metho d sp ecialization are captured by this theory On the other hand
onent In fact
this pro cars for
ject requires a
ject as a whole In an ob
jectoriented concepts like
for the pro
hierarchy of classes sp ecifying drivers some of them
In this case it is the identity of the ob ject or the class to
ob ject b elongs to that determines what services a particular driver d
pro ject jectorientation can b
The ob
ach to software In fact
develop ed that takes the concept of ob ject as primitive and
jects should ob ey Ob
the comp onentorientation can b e seen
tware In fact software comp onents have
mathematical engineering and market asp ects Their engineering dimen
sion comes from
out of already built parts or comp onents The
jects seen as engineering vs mathematics should hence b e understo o d in a broad sense That is ob jects can model the problem domain of a system in a
the basic concept b ehind them
similar manner to mathematics oering abstract mo dels of
the same p ersp ective comp onents can mo del the functionality of a system
in a similar manner to engineering disciplines oering problems or realizing the functions some systems have
the world From
practical solutions to to p erform
jectbased pro
more skilled than others
ject we might have a
as a more engineering approach to
a particular nature that
sof combines
which extent the
that of building systems syntagm comp onents vs ob
Summarizing apart from the ab ove more intuitional syntagm engineer
ing vs mathematics the initial syntagm comp
b e regarded as service vs identity or p erhaps service vs state For dis
tinguishing b etween these notions we
onents vs ob jects should can asso ciate a comp onent with the
set of services it implements and
set of prop erties attributes and op erations it
in the following section how to use b oth concepts in a software construction pro cess
Using Comp onents and Ob jects
an ob ject with an identity together with
We have argued b efore for comp onents to
This view implies that comp onents can describ e b est the functions a
has to p erform that
a system On
system We are interested in using these
to b e constructed simply reused Excluding the already existing
ob jects can b
b est the problem domain of a
prop erties of software pro ducts
is the functionality of
comp onents and
ob jects in
a pattern for developing large
In the analysis phase the
its required functionality Therefore it is not easy nor natural to depict a
has Based on this
a we show
b e considered as serviceoriented
system the other hand e considered as identityoriented and hence they can describ e
sp ecication of
a software system comprises only
the problem domain implementing a group of services These comp onents have
suitable class decomp osition of
see the system as a collection of services it should provide Consequently as many of these services are usually related to each other we can group them conveniently In this way we determine a set of comp onents each comp onent
or if they already exist
comp onents we end up with
the services are welldo cumented The design of each comp onent basically consists in determining the services to b e used from other comp onents and
the services to
the services a
implementation has
mandatory but the
and stable withstanding the evolution of
Moreover nding a suitable class decomp osition for initial system ie one comp onent is considerably easier
a set
of comp onents to construct for which
b e implemented by
suitable ob jectoriented decomp osition providing the required
Instead it
is natural to
that comp onent In order to implement
to be found At this stage the ob jectorientation is
exp erience shows that such an approach is
We note that this approach agrees with the intuition had so far More
precisely comp onents are
to b e used
used at the implementation level Nevertheless for
while a softwa re pro ject requiring only one comp onent its asso ciated class decomp osition
ob jects are
to be
not more intuitive the software system b etter a fo cused part of the
as software architecture means
Input Mail
Confirm Delivery
Drive
Load
Figure Mail Delivery System Use Case Diagram can b e seen as its architectural skeleton
Unload
Dispatch
Transport
<
Send Mail
example used
mail delivery system should provide the following services
in the previous sections let us assume it should enable the customer to input mail into the system and also
Example Given the
that the nal
to receive a conrmation of the
mail delivery if this is required
it should send
using other services like dispatching the mail loading and unloading it into a transp ortation means transp orting it as well as driving this transp ortation means
can now b e represented with
the use
the mail
to its desired destination this can b e p erformed
These services can b e represented for instance with a UML use case dia gram as in Figure Having the services depicted we can group together the logically related ones as in Figure At this level we have formed a set of three comp onents that should provide the resp ective services Moreover they
each other in the
a more complete form
line for constructing software As comp onents and ob jects have
should also communicate with
case diagram In fact based on the diagram shown in Figure the system
Figure
Each comp onent can b e further sp ecied and implemented using an in
ternal class decomp osition For instance the Post Vehicle comp onent can
have the structure as depicted in Figure The service Move will b e used
the Driver comp onent while the service Capacity by
by the MDS comp onent
for distributing the
The software engineering pro cess we have describ ed gives a
mail correctly in the transp ortation means
way prescrib ed by
of the diagram given in
general guide dierent roles
<
<
<
<
Input Mail
Confirm Delivery
Post Vehicle
Drive
Load
Figure Mail Delivery System Depicting Comp onent Services
Move
the correct transformation
comp onent using the renement
Unload
Dispatch
Transport
Send Mail
Figure Post Vehicle Comp onent
Capacity
that preserves the b ehaviour of A
Engine
Post vehicle
Wheel
Door
they are most useful in certain asp ects of this
re deterministic system A
p ermits to develop the internal structure of
cication until its implementation However in order to apply it
Bus Car
b oth concepts during the pro cess as
pro cess However by using a whole we exploit their characteristic
Truck
this guideline were exp erienced in for the develop
services to b e implemented in
deline describ ed in
ob jectorientation was determined for each
features b etter
The principles of
the comp onents were determined rst and the formal software construction technique
ment of control systems Here
then internally develop ed using
of renement The renement concept refers to
of an abstract and nondeterministic system A into a more concrete and mo
This metho d its initial sp e an initial each comp onent The determined using the gui this section Then an implementable solution based on
a comp onent from fo cused and precise sp ecication has to b e given for
the comp onents were
techniques
Conclusions
Summarizing comp onents are imp ortant as software construction concepts
based on
construction solution to
b est in underlying a problem domain describing a system functionality By
the notion of
service Ob jects are also important but
in providing a
we employ these notions at
The app earance and development
while comp onents are using comp onents and
jects are most suitable in ob jects together
each comp onent and
comp onent service Ob
their real
is often motivated by the great increase in software size by the shifting in
the software applications as well as by
her evolution In this programming and also orientation should replace ob
The software systems will continue to grow
p otential
of new concepts in software engineering
the need
way ob jectorientation seemed to replace structured
of software reuse or smo ot in this way it might b e considered that comp onent
jectorientation In
structured programming and lifts them to a new
fact ob
dimension Comp onentorientation should b e understo o d in the same
b eds the
advantages of
jectorientation em
ner Software systems grow continuously and need comp onent as a selfcontained software system that
man The notion of can b e reused or easily
replaced meets these requirements The
to evolve
however best realized when systems these concepts were
a comp onent is
of Web applications It
for software construction similar to engineering
the context
ral guideline for
conceptual dierence b etween comp onents and ob
jects
the software
References
ob jects are
is therefore imp ortant to
metho ds for for making
constructing
pro ducts of all typ es This
construction more natural deterministic and reliable by prop osing a gene
M Abadi and L Cardelli A Theory of Objects SpringerVerlag
G Bo o ch J Rumbaugh and I Jacobson The Unied Modeling Langu age User Guide AddisonWesley
M Bouzeghoub G Gardarin and P Valduriez Object Technology Con cepts and Methods International Thomson Computer Press
implementation of
used since for medium sized software
proven fundamental and stable
pap er is an attempt
the development of large software systems based on the
esp ecially in
have systematic metho ds
R Cattell Object Data Management Version AddisonWesley O J Dahl and K Nygaard Simula an Algolbased Simulation Langu
age In Communications of
the ACM
D Robson
C Horstmann Practical ObjectOriented Development in C and Ja
A Goldb erg and
mentation AddisonWesley
its Imple
va John Wiley Sons
B HendersonSellers C Szyp erski A Taivalsaari A
Wills Are Com
p onents Ob
jects In
Smal ltalk the Language and
OOPSLA Companion Panel Discussion
Pro duced Software Comp onents In
M Minsky A Framework for Representing Knowledge In Psychology of
M C McIlroy Mass
Conference on Software Engineering Garmisch Germany
Methods LNCS
SpringerVerlag to app ear Novemb er
K Sere
P H Winston McGraw Hill
Proc of NATO
Computer Vision ed
R Orfali D Harkey and J Edwards The Essential Distributed Objects
Survival Guide John
Wiley Sons
Developing Control Systems Comp onents In Proc
L Petre and
of IFM Second International Conference on Integrated Formal
D F DSouza and A C Wills Objects Components and Frameworks with UML The Catalysis Approach AddisonWesley
C Szyp erski Component SoftwareBeyond OO Wesley
Programming Addison
D Taylor ObjectOriented Information Systems John Wiley Sons
P H Winston Articial Intel ligence AddisonWesley
Turku Centre for Computer Science
Lemminkaisenkatu
FIN Turku
Finland httpwwwtucsab o
University of
Department of
Turku
Ab o Akademi University
Mathematical Sciences
Department of
Institute for Advanced Management Systems Research
Computer Science
Turku Scho ol of Economics and
Institute of Information Systems Science
Business Administration
View publication stats