Jan Bosch 3
Departmentof Computer Science andBusiness Administration
Universityof Karlskrona/Ronneby
S-372 25, Ronneby,Sweden
Tel: +46-457 -78 7 26
Fax: +46-457- 271 25
E-mail: Jan.Bosch@ide.hk-r.se
URL: http://www.pt.hk-r.se/~b osch
Abstract
Although object-oriented metho ds make extensive use of relations b etween objects, these re-
lations, other than inheritance and part-of, can not directly b e represen ted by the conventional
object-orientedmo del. Thismeans that relationswhichare identi ed during analysis anddesign
have tob eimplementedontop oftheobject mo del,i.e. byusingmetho dco de andmessagepass-
ing, rather than by expressing relations directly within in the mo del. It would b e b ene cial if
theobject-orientedmo delwouldsupp ort thesp eci cation ofallrelevanttyp esofrelationswithin
the mo del,including application-domainsp eci c relation typ es. Therefore, weprop ose a mecha-
nism,implementedinL ay
OM{anextended objectmo del, that supp ortssp eci cation ofalltyp es
ofrelationsb etweenobjects withinthemo delascomp onentsof theobject mo del. Inaddition,an
approachforidentifyingandsp ecifying application-domainrelationtyp esispresented.
Research Pap er: languagedesign, reuse,architecture
1 Introduction
The concept of relation plays an imp ortant role in mo delling applications. Most object-oriented
developmentmetho ds,e.g.[8,10,16,17],makeextensiveuseofrelationsb etweenanalysisanddesign
entities. However, the object-oriented mo del in which the analysis and design mo del generally is
implementeddo esnotprovidesupp ortforexpressingrelationsotherthaninheritanceandaggregation.
Weconsiderthis a problemb ecause arelation,b eing a conceptualentity,can notb eexpressedin the
object mo del as an entity, but needs to b e implemented as distributed pieces of metho d co de and
messages. Thesoftwareengineershould b eabletoexpress alltyp esofrelations,oratleastthelarger
part,asentities in theobject-orientedmo del.
Others[16]alsoidenti edthisasaproblemandprop osetomo delrelationsasindep e ndentobjects.
This,web elieve,isunsatisfactoryfortworeasons. First,arelationshouldb epartoftheobjectwhose
b ehaviouris in uenced bytherelation. A relation is notan object,but it should b emo delled as an
identi able unit. Second, for the objects involved in the relation the designer still needs to de ne
metho ds and messageexchanges.
Weprop osetomo deltherelationsanobjecthaswithotherobjectsasapartoftheobjectde nition.
Thedesigner cande ne relationsofaclasswithother classes forthree purp oses. First,a relationcan
3
Thisworkhasb eensupp ortedbytheBlekingeForskningsstiftel se.
Structural relations de ne the structure of a class and provide reuse. The second typ e of relation,
i.e. a behavioural relation, is de ned for clients of the class. The functionality of the class is used
byclient objects and the class can de ne a behaviouralrelationwith eachclient(or clientcategory).
ehavioural relations restrictthe b ehaviour of the class. For instance, access to the class might b e
restrictedfortheclientincertainobjectstates. Thethirdtyp eofrelationsthatcan b eapplied bythe
designer are application domain relations. Manydomains have,next to reusable application domain
classes, also application domain relation typ es that can b e reused. In practice, we have exp erience d
this categorisation asb eing verynatural. Therefore, wecategorise relationsin structural, behavioural
and application-domain speci crelation typ es.
The contribution of this pap er, we b elieve, is that it presents a novel approach to representing
relations b etween objects that is 1) more uniform than the conventional approaches, 2) provides
reuse of relation typ es and 3) increases the traceability of relations in the implementation mo del.
We explici tly do not aim at mo delling relations as in relational databases. Our goal is to extend
the relation typ es that can directly b e represented within the object mo del (currently inheritance
andaggregation)withadditional relationtyp esthatincrease theexpressivenessoftheobject-oriented
mo del.
This pap er is organised as follows. First, we analyse the problems of the conventional object
mo del 1
with resp ect to relations in the next section. Then, in section 3, we intro duce the pro cess
controldomainwhichwillserveasanexamplethroughoutthepap er. Insection ,theaforementioned
categories ofrelations arede ned and describ ed. Asasolution tothe discussedproblems weprop ose
thela ered obectmodelin section . Section 6 discusses the relation toother workand we conclude
in thelastsection withan evaluationand a description offuture work.
tion l
Inthissectionwedescrib etherationalefortheresearchresultinginthispap er. First,ashortoverview
ofobject-orientedanalysisanddesign isgiven. Inthesubse uentsection,an analysisoftheproblems
of theconventionalobject-orientedmo del withresp ect tothemetho dologyare describ ed.
. er ie o nal sis an esi n e s
A conventional object-oriented metho d consists of many steps and pro cesses, but it can generally
b e decomp osedin vehigh-level steps. elow,we give abrief description of thesteps. However,the
intentionofthisdescriptionistoillustratehowasoftwareengineerdealswithrelationsduringanalysis
anddesign. Itexplici tlydo esnotintendtogiveaprecisedescriptionofananalysisanddesignmetho d.
Thedescription is a generalisationof themorep opular object-orientedmetho ds, e.g.[ ,8, 10,16].
1. e uirement and domain anal sis: uring re uirementsanalysis the software engineer tries to
identify andde ne all re uirements in a consistent,coherentand complete re uirement sp eci -
cation. omainanalysisisconcernedwithidentifying theoreticaland engineering domains that
arerelevantfortheapplication underdevelopment.
2. bectandsubs stemidenti cation: Thesoftwareengineerstructuresthesystemintoahierarchy
ofsubsystems and identi es relevantobjectsin the application domain.
3. elation identi cation: After the system has b een structuredand candidate objects have b een
de ned,thesoftwareengineersearchesforrelationsb etweentheidenti edobjects. Atthis stage
1
ith`conventionalob ect o del',werefertothetraditionalob ect o delassupp ortedby alltal k and .
thecharacteristicsof eachrelation asprecisely asp ossible.
. tructure speci cation: As the structure of the system is the fo cal p oint here, the relations
identi edduringtheprevious phaseare`mapp ed'tooneofthreerelation typ es,i.e. inheritance,
aggregation or uses. The latter relation basically captures all relation typ es that cannot b e
expresseddirectly withintheobjectmo del. The structureofthesystemisde ned based onthe
inheritance andaggregaterelations.
. ehaviour speci cation: The uses relations,i.e. therelation typ esthat cannot b eimplemented
within theobject mo del,aretranslated intometho dco de and messagesends b etween objects.
From the ab ove description one can conclude that, although many di erent typ es of relations
can b e identi ed during the relation identi cation phase, only inheritance and aggregation relations
are represented within the mo del. Other relation typ es have to b e expressed on top o the object
mo del. In addition, despite the fact that application domain entities are mo delled by classes, the
application domain relations b etween the classes are not mo delled as rst-class entities, but need
to b e translated into metho d co de and message sends. Our exp erience has shown that, next to
application-domain sp eci cclasses,oftenapplication-domainsp eci crelationtyp esalsoprovideuseful
and reusable abstractions.
. ro le s
The problems related tothe use of relations in the conventionalobject mo del can b e categorised as
follows.
ac r : uring analysis and design, the application is mo delled in terms of
objects and relations b etweenobjects. uring theimplementation phase, themo del hastob e
expressedinanobject-orientedlanguagethatonlysupp ortstherepresentationoftheinheritance
and part-o relation. Other typ es of relations haveto b e implemented on top of the language
mo del. Obviously, this is nota uniform approachto expressing relations b etween objects: de-
p ending on therelationtyp e, thesoftwareengineerhas toexpress therelation in di erent ways
in theobjectmo del.
e ec e rce Re se: From ourexp erience, wehavelearned that applicationdomains
notonlyhavedomainsp eci c classes,butoftenalsodomainsp eci crelations. However,b ecause
theconventionalobjectmo deldo es notsupp ort explici t representationofrelations,thedomain
sp eci crelation typ esaregenerallyneglected. Aproblemisthatonelo osesan imp ortantsource
of reuse when relations are implemented as metho d co de within one (or b oth) of the related
objects. The rst-class representation of the application domain relation typ e is lost and it
cannot b ereused.
e she racea : Ifrelationscan notb eexpressedexplici tlyin theobjectmo delbut
havetob eimplementedaspieces ofmetho dco deandmessagesb etweenobjects,thetraceabilit
ofthe implementationmo del withresp ect tothe design mo delismoredi cult. Thisb ecause a
unitin thedesign mo deldo es nothaveacorresp onding unitin theimplementation mo del. The
implementation mo dels thereal worldproblem less exactthanp ossible.
hen weuse theter `obect'werefer, unlesse plici tl y stated, toanalysi s and design entities, e.g. subsyste s,
classesandinstances.
ε
Figure1: efault pro cess - controllercon guration
Figure 2: Analysis anddesign mo del
l roc ontrol lic tion
In this pap er wewill usea part of a pro cess control application as therunning example. In gure 1
thedefault con gurationfora pro cess and an asso ciatedcontroller isshown.
In pro cess control, the system,i.e. the controlled and the controlling part, is build by using two
typ esof comp onents: processand controller. Thepro cess has oneinput, thedesiredvalue ,and one
output,theactual value . Thecontrollerhas twoinputs,thedesired value and themeasured value
and one output,thesetvalue . The setvalueof thecontrolleris connectedtothedesiredvalue of
thepro cess.
In gure 2, an analysis and design mo del of a part of a pro cess control application is shown.
The most imp ortantclasses in this application arethe controllerand theprocess. othinherit from
class trans ormer. etween the pro cess and the controller, a relation of typ econtrols exists. lass
transormerwhichcontainsfunctionalityfortransforminganinputtoanoutput. Thepro cesscontains
a sensor to interact with the real-world pro cess it represents, whereas the controller contains an
actuator tocontrolthis pro cess.
Thepro cess isanabstractionof areal-worldpro cess. In pro cesscontroltheory,anumb erofuseful
pro cess abstractions have b een de ned. xamples are the ero-order pro cess, e.g. an (ideal) servo
system, the rst-order pro cess, e.g. the heating of a water mass,and the second-order pro cess, e.g.
twoheatingtanks in se uence. Orthogonal tothe order ofthepro cess, a pro cess can havea reaction
delay,i.e. atimeintervalb etweentheactuationand theresp onse ofthepro cess. Thesepro cess typ es
arearchetyp esand a real-worldpro cess ismo delled using comp ositionsof these pro cess typ es.
ro cess controltheory also de nesthree basic typ es ofcontrol:
The rstisproportional( )control,wherethedi erence b etweentheactualvalueofthepro cess
and thedesired valueofthe controllerarelinearly translatedinto aset valueforthecontroller.
The second typ e of control is integrating (I) control, where the controller not only uses the
currentactual value, but also thehistory of the pro cess. An integratorcan, forinstance, level
outthee ects ofa static disturbance in thepro cess, whereasa controller cannot.
The third typ e is the di erentiating ( ) controller which is used to obtain a fast resp onse to
These three basic typ es of controllers can b e comp osed to form more accurate (and realistic)
controllers. The controller typ es that are used in practice are , I, and I .In this notation,
I, forexample, referstoa controllerthatcombines prop ortionaland integratingcontrol.
The combination of a pro cess and an asso ciated controller can b e used asa higher level pro cess,
which in turncan b econtrolled byahigher levelcontroller. Also, pro cesses can b e combined, either
parallel orse uential andthe resultis generallya higher order pro cess.
l tion
Astheterm`relation'is usedin manydi erentcontextsand anysoftwareengineer hassomeasso cia-
tionsconnectedwiththeterm,wehavetob eexplicit ab outouruseofrelations. Forthispurp ose, we
de ne arelation asan connection romone obect or class to another obect or class that
in uencesthebehaviour o insome a . onotethatin thisde nitionweexplicitl ydemand that
theb ehaviourof theobjectisin uence d bytherelation. Wearenotconcernedwithrelationsthat do
notin uencetheb ehaviouroftheobject. Asecondasp ect ofthisde nition istheunidirec tionali ty of
a relation. The rationalefor de ninga relation asunidirectional isthat we asso ciate a relation with
theobjectwhose b ehaviouris in uenced bythe relation. Our exp erience is that only a small subset
of the relation typ es is bidirecti onal in terms of our de nition. These relations are mo delled as two
unidirecti onal relations.
It is our aim to present the concept of relation in a veryuniform manner and to deal with each
relation typ e in exactly thesame manner. We b elieve that the conversionof an analysis and design
mo del intoa set of classde nitions ismorenatural if relations can directly b eexpressed in theclass
de nition.
uringanalysis and design,thedesigner can de ne relationsof aclass withotherclasses for three
purp oses. First,arelation can b eusedtoextendthefunctionality ofaclass. Thistyp eofrelation,we
refer to asstructuralrelations. Structural relations de ne the structureof a class and provide reuse.
The second typ e of relation is de ned for clients of the class. The functionality of the class is used
byclient objects and the class can de ne a behaviouralrelationwith eachclient(or clientcategory).
ehavioural relations restrictthe b ehaviour of the class. For instance, some functionality might b e
restricted to certain clients or in sp eci c situations. The third typ e of relations that the designer
can applyareapplicationdomainrelations. Manydomainshave,nexttoreusableapplication domain
classes, also application domain relation typ esthat can b ereused. Forinstance, thecontrolsrelation
typ eisaveryimp ortantrelationinthedomainofpro cesscontrol. Thede nedrelationtyp ecategories
aredescrib ed in thefollowingsubsections
. r c ral ela ions
Structuralrelation typ es,asdescrib ed ab ove,de ne the structureofan application. A classuses the
structural relations toextendits b ehaviourand theclasscan b eseen astheclient,i.e. theclass that
obtainsfunctionality providedbyotherclasses. enerally,threetyp esofstructural relationsareused
in object-oriented systems development:
nheritance: This relation typ e is often seen as the central concept of the object-oriented
paradigm. Inheritance allows a class to reuse the interface elements and the internal state
de ned in the inherited class. The direction of the relation is from the inheriting class to the
inherited class, astheb ehaviourof theinheriting classischanged.
Theter `interfaceele ent'willb ediscussedin oredetailinsection .
e a
Inherit elegate artOf
c a
onditionalInherit onditional elegate onditional artOf
par a artialInherit artial elegate artial artOf
c a ond artialInherit ond artial elegate ond artial artOf
a par a
Table 1: Structural relation typ eidenti ers
elegation: A second typ e of structural relation is delegation, i.e. the object can delegate a
message to another object while encapsulating this from the sender of the delegated message.
espite the discussion within the object-oriented research community, a numb erof years ago,
concerning the advantagesand disadvantagesof inheritance and delegation, web elie ve that an
object-oriented mo del should supp ort b oth typ es of relations. The direction of the delegation
relationisfromthedelegating objecttothedelegatedobject,astheb ehaviourofthedelegating
objectis extended.
art-o: erhapsthemostfundamentalrelationin mo delli ngapplicationsisthepart-o relation.
The approach of problem decomp osition and solution comp osition, one of the basic problem
solving characteristicsof humans, re uires the concept of parts. This relation typ eis directed
fromthewholetothepart,i.e. froman object toanobject . The rationaleforthis
isthat theb ehaviourof isextended byits partsandnotvisa versa.
Theab ovedescrib edrelationtyp esallprovidesomeformofreuse. Theinherited,delegatedorpart
object provides b ehaviour that is reused bythe inheriting, delegating or whole object, resp ectively.
Therefore, b esides referring to these relation typ es as structural, we can also de ne them as reuse
relations.
Orthogonaltothediscussed relationtyp es,which arethefundamentaltyp esofreuse relations,one
can recognisetwoadditional dimensions tostructural relationtyp es,i.e. partialit and conditionalit .
artialit : Thereusing objectdo es notnecessarily re uire thereuse ofall interface elementsof
the reused object. Actually, it mighteven explici tly constraincertain interface elementsto b e
reused. Therefore, indep end ent of the object state or the client typ e, the reusing object may
only wanttousea partorsubsetof theinterface ofthe reusedobject.
onditionalit : Whenreusinganobjectorclass,thereusingobjectmightre uire thatthereuse
only o ccursin certainstates. Therefore, theobectstate isafactorin deciding whethertoreuse
a particular interface element. When sp ecifying a reuse relation, the software engineer has to
determine whether all interface elementsof the reused object should b e accessible in all object
states.
We b elieve that a relation b etween two classes orobjects, regardless of its complexity,should b e
mo delled asa singleentitywithin themo del. Analternativeapproachwouldb e tode ne a collection
oforthogonalconstructsandtodecomp osearelationb etweenobjectsintoinstancesofeachorthogonal
construct as is done in, e.g. [3]. This approach, however, do es not represent a conceptual entity in
analysis anddesign asan entityin thelanguagemo del.
The di erent asp ects of a structural relation, i.e. its typ e, partiality and conditionality, form a
three-dimensional space which containsall p ossible combinations. In compliance with ourmo delling
principl e, we de ne a relation typ e for each combination. This results in twelve structural relation
typ es. Thesestructural relation typ esareshownin table 1.
