Towards a Conceptual Theory for

Object Oriented Systems Modeling

Theo Wiggerts

Towards a Conceptual Theory for

Object Oriented Systems Modeling

Theo Wiggerts

supervisor� Dr� ir� Th�P� van der Weide

Master�s Thesis No� ���� July �� �Department of InformaticsFaculty of Mathematics and InformaticsUniversity of Nijmegen� The Netherlands

Contents

� Introduction ���� A new paradigm � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���� Problems with object orientation � � � � � � � � � � � � � � � � � � � � � � � � � ���� Problem statement � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��� Thesis outline � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� Informal introduction to the theory ����� General systems theory � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Object universe � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Objects � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Types and behaviour � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���� Attributes� relationships and communication � � � � � � � � � � � � � � � � � � ���� Worldviews � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Decomposition � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Formal description of the theory ����� Universe components � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Auxiliary de nitions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���� Axioms � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Metamodel � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��� Derivable characteristics � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Evolution� the dynamics ����� Corpus evolutionis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Modeling evolution � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���� States � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ����� Universe history � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Object retrieval ���� Three layer strategy � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ���� Behaviour navigation � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� Conclusions and directions for further research ��

Bibliography ��

Index ��

Contents Contents

�

Chapter �

Introduction

��� A new paradigm

The software engineering community faces severe problems� Many projects don�t get readyin time� if they are brought to a succesful ending at all� After the delivery of a system a lot ofbugs are encountered� which have to be xed� And very probably� the delivered system is notdoing what it is supposed to do� This is partly caused by the lack of communication betweenthe builders and the users of the system which haven�t met very often since the speci cationswere frozen� Another reason lies in the fact that while the system was being developed� theworld didn�t stop turning� The environment in which the system should t has changed and itkeeps on changing while the system is operational� So the system has to be adapted over andover again in reaction to changing demands� But when we try to adapt the system �which isoften mildly called maintenance�� we nd out that the system is very hard� if not impossible�to adapt� This is caused both by the lack of good systems documentation and bad designand programming practice �modularization� data abstraction etc�� It will be clear that theseproblems bring about enormous costs and therefore it is not so strange that many authorssummarize them by the term software crisis� But �Boo�� rightly remarks that �a maladythat has carried on this long must be called normal��

But what is the deeper reason behind these problems � �Boo�� blames the inherentcomplexity of �software� systems and argues that object orientation provides the right meansto master this complexity� Although we do agree that this is a very important point in favorof object orientation� we don�t think that complexity is the sole reason for our problems�There is something wrong with the way systems are traditionally built as well� Practicallyevery system is built from scratch� �Tay�� compares the way software systems are built withthe way ri�es were made by craftsmen� Every ri�e was unique and a nice piece of work but ittook a long time to make it� A ri�e made in this way would nowadays cost a lot more than amodern ri�e does� This is because Eli Whitney thought of a new way to produce them� Hespeci ed standard ri�e components which could be used for several kinds of ri�es� Some ofthe standard components were put together and a new ri�e was born� This way of producinggave rise to mass �component� production which dramatically reduced the costs� On top ofthat� the ri�es were much easier to maintain as damaged ri�es could be repaired by usingspare standard components� As this new way of producing ri�es is essentially di�erent fromthe traditional method� we can speak of a new paradigm�

Object orientation translates this paradigm to software production� As we said� most

�

���� Problems with object orientation Ch� �� Introduction

software systems are built from scratch� A system is developed for a speci c purpose andenvironment and �parts of� it can�t be used elsewhere� If we could make software by puttingtogether some standard components� which were fully tested or proved to be correct and canbe bought from specialized vendors� we could dramatically reduce the time needed to builda system� This time reduction would yield lower development costs and the system wouldbetter t in its environment as this didn�t get much time to change� And when it does� thesystem can easily be adapted by changing� replacing or adding some components� And oncea component is made� �mass� production doesn�t cost anything as we can easily copy thecomponents for free �

This idea of object assembly doesn�t make the software engineer obsolete� On the contrary�the need for good designers will be greater than ever� This is because a system must bedesigned by putting together the right combination of components� while baring in mind thatthis combination will change over time� �JBJE� talks about plugable architectures in thisrespect� This is not only a technical issue� It also involves looking around on the marketto nd out what�s in store and deciding whether to buy a certain component or build oneyourself� And when a new component is built in house� the developers should design it insuch a way that it can be used for other �future� systems as well� This will reduce the overalldevelopment e�ort�

��� Problems with object orientation

So if we know the answer to our problems� why is the software crisis not solved yet � Themain reason seems to be that many projects are still developed in the traditional way� Thisis very understandable as object oriented methods and tools are still under development andcompanies won�t risk their critical projects on something relatively new� Besides that� thenumber of component vendors is still rather small� although it is growing� But when thenumber of available ready made components grows� it becomes harder to nd the particularcomponent you need� And a good component disclosure method has still to be thought of�There are a lot of languages and methods to choose from� but there is little consensus ontheir use� This makes it di�cult to compose systems from components supplied by di�erentvendors� Especially when the components are written in di�erent languages�

There is also no consensus on the concepts of object orientation� There are a lot ofdi�erent methods which all use about the same terminology� But the terms used� often havedi�erent meanings in di�erent methods� Fortunately some consensus seems to be growing asthe methods in�uence each other and object gurus adopt the good ideas of their colleagues�However these methods are still blurred with all kinds of implementation aspects of objectorientation like late binding� runtime type checking� inheritance issues and attributes� Somemethods �like OMT which is described in �RBP���� just simply combine some existingmethods from other elds� like data modeling and process modeling� and add some �avourby incorporating object oriented features�

A pure conceptual theory� which deals only with object oriented concepts and abstractsfrom implementation aspects� is hard to nd� Such a theory is needed because you must rsthave a clear view of what you are doing on a very abstract level before you get down and makeall kinds of design decisions� By making these decisions� possible solutions are excluded� asthey would be reached by making other choices� Besides object orientation is a new paradigm�So people who are new to it should not be diverted by implementation aspects but grasp the

�

Ch� �� Introduction ���� Problem statement

essentials� The paradigm shift is hard enough as it is�Another problem with existing methods is their lack of formality� Concepts are usually

introduced by means of examples and a lot of pictures� This may be good to get a feelingof what object orientation is about� but it also causes ambiguity� This ambiguity is re�ectedin the presence of numerous guidelines and rules of thumb advising the modeler when to usewhich concepts� When all concepts would be formally de ned� it could be checked whethera certain model correctly represents the universe of discourse �the subject of modeling�� Wemay not agree on the universe of discourse but at least we all assign the same meaning �orsemantics� to the model �

��� Problem statement

We have seen that there is a need for a formally de ned theory on a conceptual level� In thisthesis we want to partly ful ll this need�

The subject of this thesis is the presentation of a �rst attempt towards a theory for systemsmodeling� This theory is based on object oriented principles� on a conceptual level and for�mally de�ned� It can serve as a base for areas of research related to object oriented softwareengineering�

��� Thesis outline

The structure of this thesis is as follows�

Chapter � gives an informal introduction to the theory� The notion of an object universe isintroduced� In this universe� objects are frolicking around� interacting with each other andconstituting systems� We also introduce the notions of types and behaviour� The interrela�tionships between objects are captured by a concept which we call worldview� The fact thatsystems can be looked at at di�erent levels of abstraction is stressed and several comparisonswith concepts in other methods are made�

The structure of an object universe and its components are formally de ned in chapter �� Thisstructure should be instantiated by a concrete modeling technique� The axioms to which eachuniverse should conform� are presented and some theorems are derived from them�

In chapter � the theory is extended as an attempt to include dynamic aspects� Evolution in anobject universe is seen as continuous rearrangements of objects� The importance of identityin modeling evolution is stressed and some axioms restricting evolution are presented�

Building software from ready made components brings about a need for good object disclo�sure mechanisms� These should help us to nd the right combination of objects� In chapter we illustrate how the theory can be used to support object retrieval� To this purpose we alsoapply some ideas from the area of information retrieval� A three layer disclosure architectureis proposed and a navigation mechanism based on the de nition of behaviour is described�

The conclusions are presented in the nal chapter� In this chapter we also point at someinteresting topics for further research�

���� Thesis outline Ch� �� Introduction

��

Chapter �

Informal introduction to the theory

In this chapter we will informally describe object oriented systems on a conceptual level� Thismeans that we will not make any assumptions as to the hardware the system will be runningon or to the concrete techniques used to implement the objects� the thread of control and thecommunication between the objects� An object oriented system is seen as an �eco�system orpool wherein objects are crawling around� performing actions and having relationships� on aparticular level of abstraction that is� When we move to other levels of abstraction� we willenter entirely di�erent �worlds� being a part of our universe of discourse as well�

Object oriented systems are systems so the basic philosophy and terminology from generalsystem theory apply to object oriented system engineering as well� In the rst section we willgive a quick overview of the relevant concepts from systems theory� In the following sectionswe will introduce the terminology of our theory and the intuition behind it� building on theseconcepts�

��� General systems theory

In literature on systems �like �Vel�� and �Pat��� a system is usually de ned as something likea whole of elements and their �inter�relationships that achieves some purpose� This purposeis the reason why a system is worth studying in the rst place as it could not be achieved bythe individual parts� A system is more than the sum of its parts� it has some added value�This principle is called emergence as a system emerges from its elements�

We will call the elements objects� Some authors �like �Vel��� divide the elements in twogroups� passive ones� called objects� and active ones� called subjects� We will not make thisdistinction and use the term object for all elements� Each object has the potential to be active�So a subject from systems theory is just an object which uses this potential and an objectfrom systems theory is an object which doesn�t at this moment�

A system is a part of a universe which represents the total reality �the universe of discourseor application domain�� Objects in a system can have relations with objects within that system�which we will call internal objects� and with objects outside the system �which we will callexternal objects�� The external objects to which at least one internal object is related spanthe environment of the system� The term boundary is often used �in gures� to explicitlyseparate the system from its environment but it is no �physical� element of the universe onitself� Figure ��� summarizes the terms introduced so far�

��

���� Object universe Ch� �� Informal introduction to the theory

system

universe

environment

boundary

relations

external objects

internal objects

Figure ���� a basic system from general systems theory

��� Object universe

Just as systems in general systems theory reside in a universe� objects in our theory occurin a wider structure� which we call an object universe� In chapter � we will give a formalde nition of an object universe and its components and present the axioms it should conformto� It should be stressed that an object universe is not a concrete modeling technique� Itis a framework in which concrete modeling techniques can �be� t� Nonetheless it is veryinteresting to operate at such a general and conceptual level as it allows us to touch the veryphilosophy of what we think is object orientation� In the next sections the components of anobject universe are presented�

��� Objects

Now what exactly is an object � Each author provides his own de nition but the essence isthat an object is the smallest �thing� we want to look at on a certain level of abstraction� itis atomic� This �thing� can be any thing real or imaginable� �Boo�� de nes it as �anythingwith a crisply de ned boundary� which emphasizes that an object can be discerned anddistinguished from its environment� �Boo�� suggests the following de nition� �An object hasstate behaviour and identity�� The behaviour of an object is determined by its characterizingtype �see ����� The state of an object will be hidden on the current level of abstraction but itwill be of interest when we descent to a lower level of abstraction by opening the black boxthe object is at the current level �see ����� The next paragraph is devoted to the subject ofidentity�

��

Ch� �� Informal introduction to the theory ���� Types and behaviour

Identity

Objects have identity� Even if two objects �look� exactly the same� they are two di�erentobjects and thus not the same object� �Boo�� de nes identity as �that property of an objectwhich distinguishes it from all other objects�� But is identity really a property of objects �

Suppose we have cloned two identical rabbits� All of their properties are exactly the sameso there is no distinguishing property� Now suppose we decide to eat one of them� It doesn�tmatter to us which one we take �they taste the same�� but it matters to the rabbits � Soapparently there is such a thing as identity but it is no property of an object� It is re�ectedin the very existence of the object� When we study two objects� they are not the same object�they do not have the same identity� just because they both exist� But we want to be able totalk and reason about a particular object� now how do we denote objects uniquely when theydon�t necessarily have a distinguishing property � We will put labels on the objects for thispurpose� As long as we ensure that each object is labeled uniquely� these labels represent theimplicit identity of the objects�

One might say that this violates the conceptualization principle �see �Hof��� which statesthat conceptual models should deal only and exclusively with aspects of the universe ofdiscourse and that any aspects irrelevant to that meaning� like the arti cial introductionof identifying codes� should be avoided� We argue however that this does not violate theconceptualization principle as the labels are not treated as properties from the problem domainbut as implicit properties of objects which are elements of our modeling language� We don�tadd identity� it exists in the universe of discourse� Identity is just made explicit to allow usto talk about the individual objects�

In �Pro�� an object is identi ed by its unique history� We take a di�erent approach� Inchapter � we will describe evolution in an object universe� There� the identity of objects isessential to keep track of the objects in time as it links each object�s �appearances� at di�erentmoments in time� Demanding that objects �and other components of an object universe thatwill be introduced� like types e�g�� have identity allows us to de ne evolution in terms ofrearrangements of objects and types etc�

��� Types and behaviour

Objects are potentially active� they can do things� These things will be called actions� Wewill use the term behaviour to express� for a certain object� the actions it can perform andthe conditions under which these actions will actually be performed�Not all objects have the same behaviour� The behaviour of a certain object depends on its

type or characterization� The internal details of how a certain object realizes the speci cationsprescribed by its characterization will be hidden� This is called information hiding� In �Boo��Deutsch is quoted as follows� �a type is a precise characterization of structural or behavioralproperties which a collection of entities all share�� As we abstract from structural properties�a characterization of behaviour is indeed all that remains from this de nition�When an object is characterized by some type �when that type is the characterization of

that object�� the object should behave in the way that is speci ed for that type� So when you�buy� an object of a certain type� the �vendor� should convince you that the implemented codereally realizes the behaviour associated with that type� In this way a type can be seen as thefunctional speci�cation of the object� How the object implements the requested behaviour andwhat further demands it poses on its future environment will be determined by the vendor�

��

���� Types and behaviour Ch� �� Informal introduction to the theory

This means that di�erent vendors can come up with very di�erent implementations for objectscharacterized by the same type� In the following� when we say that an object is characterizedby some type� we will also say that that object is an instance of that type�

Subtypes

When the behaviour of a type comprises that of another type� the former type is called a spe�cialization or subtype of the latter �which in turn is called a supertype�� As a consequence aninstance of a �sub�type can be used whenever an instance of �one of� its supertype is required�see ����� The de nition of subtypes yields a type hierarchy� The inverse of specialization isusually called generalization��Hof�� states that in PSM �the conceptual data modeling technique de ned there� gener�

alization is not the inverse of specialization because in the case of specialization all propertiesand identity are inherited downward �a subtype inherits them from the supertype�� while inthe case of generalization they are inherited upward� In our theory the internal details ofobjects �properties� are hidden and identity is not seen as a property of an object but as animplicit characteristic of it� represented by a label �see ����� so none of these are inheritedat all� Types have associated behaviour and subtyping is de ned in terms of comprising be�haviour� so no inheriting takes place � And� in fact� the properties that would be inheritedupward serve to implement the same conceptual idea �behaviour�� otherwise the generaliza�tion would not make sense� So this kind of inheritance proves to be an implementation aspect�The behaviour associated with a type can comprise the behaviour of more than one other

type� So a type can have more than one supertype� This is usually called multiple inheri�tance� Although inheritance is really an implementation issue as we argued before� we willuse the terms inheritance and sub�super typing interchangeably here to adhere to widespreadterminology� Not all object oriented methods allow multiple inheritance because it can causesome problems which have to do with binding in object oriented programming languages �seee�g� �Boo���� But on a conceptual level we can�t live without it� its existence simply followsfrom the de nitions introduced�

Classes

The types introduced so far are di�erent from the types which are found in object orientedprogramming languages� The types in our theory represent abstract concepts with whichbehaviour is associated� The types from programming languages serve to implement theseconcepts� To avoid confusion� these latter types will be called classes �as is often done in objectoriented programming languages�� As we said before� di�erent objects can have di�erentimplementations and still be characterized by the same type� Classes serve as blueprintsfor the objects� they specify exactly how a type can be implemented� All objects beingimplemented by following the same blueprint can be said to be instances of the same class�Classes are not incorporated as a separate concept in our theory� The class of a particularobject is re�ected by the demands the object poses on its environment �see �����

In �BFP�� types and classes are also seen as di�erent concepts distinguishing betweenthe behavioural and the implementation aspects of types� However� they allow only one classto correspond to each type� So every instance of a type would be implemented the same way �We stressed before that in our theory� a type can be implemented di�erently �by di�erentclasses� for di�erent objects so we obviously don�t agree with this restriction�

��

Ch� �� Informal introduction to the theory ��� Attributes relationships and communication

In object oriented programming languages a hierarchy of classes can be built� Such a hi�erarchy can follow the type hierarchy but this is not necessary� The main reason for buildinga class hierarchy is reuse of code� subclasses inherit the data elds and methods� which areused to implement the functionality and may be overridden� of their superclass�es�� As aconsequence� subclassing is not restricted in the same rigid way as we restrict subtyping� In�Fir� thirty�nine ��� inheritance guidelines are presented� �Bud�� also gives some heuristicsfor when to subclass� Apart from specialization he mentions speci cation� construction� gen�eralization� extension� limitation� variance and combination as uses for inheritance� If appliedto types� some of these uses would �agrantly violate the axioms for subtyping which will bepresented in chapter �� �LP�� also address the di�erence between subtyping and subclassingand delve further into the ambiguity caused by inconsistent use of the term is�a�

��� Attributes� relationships and communication

Most object oriented methods �like e�g� �CY��� incorporate attributes of objects and rela�tionships between objects� Attributes are used to model the �properties� or the �state� of anobject� They are seen as data elds holding some value from a certain domain� Relationshipsare used to model all kinds of associations between objects�

Attributes or relationships �

The distinction between objects and values from domains brings about a choice in modelinga system� Should some property be an attribute or should we model it as an object whichis associated with the former � This question also plays a role in information modelingand causes one of the major di�erences between ER ��Che���� and PSM ��Hof���� whichformalizes and extends NIAM �introduced by �NH���� In ER attributes and relations aredi�erent concepts while in PSM the domains are modeled as label types which are treated asobject types �with some restrictions though�� Attributes are not seen as a separate concept�instead all facts about entities �objects� are modeled using fact types�

We will follow the same approach as in NIAM and PSM and we will go even further� Wewill not make any distinction between labels and �abstract� entities� we just de ne objects�This means that in our theory �forty�two� is an object �and not a value� and �natural number�is a type �and not a data type or a domain�� When we see ���� on a piece of paper� thiswill not be regarded as a conversion from a natural number to the domain �string� but as theability of a natural number to present itself on a piece of paper� We can drop the di�erencebetween labels and entities because we have de ned identity as an implicit characteristic ofan object �see ����� so the restrictions on label types� which are necessary in PSM to ensureidenti ability� no longer apply� Note that relationships and objects can �and in an objectoriented programming language will� be implemented as attributes �data elds� and datavalues but that is of no interest on a conceptual level�

Modeling relationships

�CY�� make a distinction between �instance connections�� which they use to model asso�ciations� and �message connections�� which they use to express that one object may sendmessages to �communicate with� another object� They fail to say how these two relationshiptypes relate to each other and what the di�erences are� They are drawn di�erently and an

�

���� Worldviews Ch� �� Informal introduction to the theory

instance connection is bidirectional while a message connection may be unidirectional� but itis not clear if e�g� it is necessary for one object to have an instance connection with anotherobject in order to be allowed to send messages to it�In PSM ��Hof��� some very strong concepts �like power types� sequence types� schema

types and �objecti ed� n�ary relationship types� are introduced to model a wide range ofstructures of types and relationships �in fact relationships are de ned as special kinds oftypes� called fact types�� In a number of object oriented models some of these constructs �ortheir equivalents� appear as well�But what is the essence of these relationships on a conceptual level � In our view the

only thing of interest is the knowledge of one object �about the existence� of another object�If it knows the other object� there is an unidirectional �knowledge relationship� �which willbecome bidirectional when the latter object knows the former as well� and the object is ableto communicate with the other object�

Modeling communication

This communication is usually modeled by objects passing messages to each other or� at amore concrete level� calling methods �procedures� of each other� in order to make the receiverperform a desired operation� We will abstract from the exact way the communication takesplace� In section ��� we have introduced behaviour as the actions an object can perform andthe conditions under which it actually will perform these actions� In our theory an objectcan be made to do something �perform a desired operation� by making sure the associatedcondition will hold �will be true�� In a concrete modeling technique this can e�g� be done bysending it a message�

��� Worldviews

On a purely conceptual level� we wish to abstract from internal details concerning the structureof relationships and objects� As we saw in ��� the only thing of interest is that one objectdepends on the presence of another object to perform its requested behaviour �note that thisis a �unidirectional relationship� ��� We will say that the latter object appears in the worldviewof the former�The term worldview allows us to really orientate ourselves to the individual objects in a

system� it models an object�s view of the world around it� We �creep into the skin� of anobject and describe what we see when we look outside� Impersonating objects and treatingthem as if they have human characteristics is called anthropomorphism� It is often claimedthat anthropomorphism is one of the great advantages of object orientation as it would standcloser to the way people think and agree with their experience in everyday life� But insoftware engineering practice� which has been directed by the way a machine �thinks�� it is tobe regarded as a new way of thinking�The worldview of a particular object contains all objects that are known to the object

and the knowledge the object has about the types of these objects� The knowledge of thepresence of each object is labeled with a predicator� These predicators allow us to formulateconstraints on the set of all objects and on the individual objects appearing in the worldview�We can state e�g� that the worldview of a particular computer �a concrete object whichcharacterization is the type �computer��� say �our computer�� should contain the knowledgelabeled with the predicator �screen� for at least one object� We can also state that if there is

��

Ch� �� Informal introduction to the theory ���� Worldviews

�screen�knowledge� about some object� its behaviour should comprise that of type �monitor��or� in other words� that the base of predicator �screen� is the type �monitor� �so the termspredicator and base have the same function here as they have in �Hof���� To make the lasttwo sentences a bit more readable� we will also talk about playing roles instead of havingknowledge labeled with predicators� We can now say that in the worldview of �our computer�at least one object should play the role �screen� and that any object which plays the role�screen� should behave like a �monitor�� The characterization of an object that actually playsthis role is not necessarily the type �monitor�� our computer just thinks its characterization is�monitor� and acts accordingly� The actual characterization of the monitor can be any typewhich associated behaviour comprises that of �monitor�� i�e� any subtype of �monitor� �see����� This is called polymorphism as the monitor can have �many shapes� �literal translation��Note that the screen knowledge is speci ed for a particular instance of type �computer�

and that other instances may have totally di�erent implementations and therefore totallydi�erent knowledge needs � Figure ��� illustrates the example� The arrow represents the�unidirectional� knowledge relation labeled by the predicator �screen� and the knowledge ourcomputer has about the vendor�s monitor is re�ected in its thinking balloon�

monitorvendor’s

monitorvendor’s

screen

type:computer

some

type:

some

type:monitor

computer our

monitorvery exotic

Figure ���� the worldview of �our computer�

Object oriented methods �like in �WBWW��� often incorporate a concept called contract�protocol or interface which serves to describe all services an object can perform� The objectis seen as a �server�� A client object can pick one or more desired operations from the list ofservices� Worldviews are not the same as contracts� In our theory the �client� knows what hewants and the �server� has to provide it� The server may be able to do a lot more but that�sof no interest to the client�

��

���� Decomposition Ch� �� Informal introduction to the theory

Multiple views

Other objects may have other knowledge of the monitor� in other words the monitor mayoccur in the worldview of other objects as well� For an electrical outlet e�g� it seems to be oftype �electricity consumer�� So multiple views of one object can �and practically always will�exist�In �Ber�b� multiple views are modeled as well� But there the object for which the multiple

views exist� determines how it is to be viewed depending on the type of the viewer� In ourtheory the viewed object doesn�t have to specify how it can be viewed� it doesn�t even have toknow if it is known by any object� We not only nd this more natural but think our approachis essential when you want to build �software� systems from �ready made� components� Wecan�t always predict the types of which instances will need to know a certain object� Wealso can�t extend the set of possible views of an object each time an instance of a previouslyunthought of type gets to know it� Furthermore� not every instance of a certain type needsto have the same view of a particular object �In section ��� we will demand that the worldviews of all objects are �valid�� This restricts

the set of possible views of an object to the supertypes of its characterizing type� �EE�� cometo a similar conclusion when they say that the concepts of view and superclass coincide�� Inthe example this means that the type �very exotic monitor� should be a �subtype of� type�monitor� and of type �electricity consumer�� in other words the vendor�s monitor should actlike a �monitor� and also like an �electricity consumer�� Figure ��� illustrates the idea ofmultiple views�

monitorvendor’s

monitorvendor’s

outlet

our

type:outlet

screen

type:computer

some

type:

computer our

very exotic

some

type:monitor

consumer

monitor

type:

somevendor’smonitor

consumerelectricity

Figure ���� multiple views of the monitor

��� Decomposition

Thus far we treated objects as atomic entities on the chosen level of abstraction� An objectwas considered a black box� When we descent to a lower level of abstraction we are openingthe box and we see that the higher level object is a system in itself � Analogously� when we

��

Ch� �� Informal introduction to the theory ���� Decomposition

ascent to a higher level of abstraction� the system we are studying will be regarded as anatomic object in a wider system� This is called �object oriented� �de�composition� When anobject occurs in the decomposition of a higher level object� which is a system� it is said tobe part of �play the part�of relation with� this object� We will also say that the object is asubsystem of the higher level object�Figure ��� illustrates the idea of decomposition� When an object is part of a system� it

is drawn inside it� The di�erence in the intensity of the colours highlights the di�erent levelsof abstraction� The arrows represent the knowledge that objects have of �the existence of�other objects� Predicators are not drawn in this gure� Note that no object has knowledgeof any object at a lower level of abstraction than its own and that for every arrow going froman object to an object in the environment of the system it is part of� there is a correspondingarrow from this system to that same external object� In the chapter � we will formulatesome axioms to be able to determine if certain knowledge is allowed �i�e� does not violate theprinciple of information hiding and illegally cross the borders of di�erent levels of abstraction��

Figure ���� objects � systems at several levels of abstraction

In �CY�� the part�of relation is called �whole�part structure�� The di�erence between whole�part structures and �instance connections� �their equivalent of relations� remains rather vaguethough� The authors don�t talk about whole�part structures modeling objects at di�erentlevels of abstraction but just say that �the di�erence between whole�part structure and in�stance connection is the underlying semantic strength� Whole�and�part is one of the basicmethods of organization that pervade all human thinking� This is much stronger in meaningthan a mere mapping between objects in a problem domain�� This does not con�ict withour view because chopping up problems in smaller proportions and doing so recursively atdi�erent levels of abstraction is indeed one of the basic methods of organization that humans

�

���� Decomposition Ch� �� Informal introduction to the theory

use� But because di�erent levels of abstraction are involved in part�of relations� they cannot be expressed in terms of �normal� relations involving only one level of abstraction �Onthe level of an object� the wider �higher level� system it is part�of� doesn�t even exist ��� Sowe do disagree with �CY�� when they say that using instance connections is an alternativemodeling choice for using whole�part structures as �it�s weaker in meaning �� � �� yet it stillcaptures the mapping��

Use cases

As far as the static aspects are concerned� our view of decomposition supports modeling withuse cases as described in e�g� �JC�� Use cases are� among other things� used for de ningfunctional requirements� They provide a black box view of a system� �Rum� de nes a usecase as a category of interactions between the system and an actor �an outside object in aparticular role� about a particular way or purpose of using the system from the user�s pointof view��

As �JC� say� use cases and objects provide complementary views of an application� Theuse cases model the end user�s view while objects form the structure of the system� this iscalled the developer�s view� In other words� use cases have to do with di�erent levels ofabstraction�

In our theory we also describe a system�s behaviour at a high level of abstraction anddecompose the system into a set of collaborating objects realizing this behaviour� �WB��suggests di�erent levels of describing use cases� Our theory supports this as well as we allowdecomposition at di�erent levels of abstraction� A system�s components can be decomposedthemselves and the resulting objects can be decomposed on their turn etc� this can go onrecursively as long as you want�This is a top down approach but we can also start at the lowest level and build systems

from objects and then build other systems from them etc� In this way we can make verycomplex systems with a relatively simple interface� without having to know how things workat lower levels� We can reach any required grade of complexity� In fact nature works thisway� Organs are build by composing cells and animals are composed from these organs� Andby putting some ants together� whole societies are made � This is what �Boo�� is pointing atwhen he says that �the object model scales up� as it follows the organization of complexity�In other words� object orientation gives you the power of abstracting out complexity�

Genericity

A binary search tree lled with numbers can be implemented the same way as a binary searchtree lled with names� In fact we can use the same implementation for storing and retrievinginstances of any type that can be compared with one another� This is called genericity�When we have a class �binary search tree� for any comparable type� we could declare

the class �binary search tree for numbers� as a subclass of it and reuse its methods� or in alanguage supporting genericity we could parameterize �binary search tree� with a class and ll in the class �number� when we need a �binary search tree for numbers�� On a conceptuallevel however� the type �binary search tree for numbers� is not a subtype of �binary searchtree� as its insert actions need instances of �number� rather then �comparable� as input� Somore information on the input parameters is needed and therefore it can not be a subtype�this is formalized by axiom T� which will be presented in section �����

We didn�t incorporate a separate concept for genericity in our theory so how do we model

��

Ch� �� Informal introduction to the theory ���� Decomposition

this situation � The answer lies in the fact that� as we saw� genericity has to do withimplementation� And that�s where it appears in our theory� A �binary search tree� is usedhere to implement a concrete instance of �binary search tree for numbers� �there might beother implementations for other binary search trees for numbers�� so it is part of the latter�

comparable

number

is-a

treebinary search

binary search treefor numbers

Figure ��� genericity on a conceptual level

Figure �� illustrates the example given here� Note that other objects might also occur in theimplementation of our binary search tree for numbers and that very probably �number� willbe a subtype of �comparable��

��

���� Decomposition Ch� �� Informal introduction to the theory

��

Chapter �

Formal description of the theory

In the previous chapter we saw that in a universe there are systems which consist of colla�borating objects� When we took a closer look� these objects proved to be systems on a lowerlevel of abstraction and systems proved to be objects in wider systems on a higher level ofabstraction� In other words� systems and objects are the same things� it only depends on thelevel of abstraction we are currently studying something� whether we call it a system or anobject� In this chapter we will formally describe our conceptual framework for object orientedsystems modeling� This framework poses demands on concrete techniques used to model theobject universe�

��� Universe components

An object universe U is a structure consisting of the following basic components�

� a set � of objects �or systems�� In practice� the set � is rather big� We won�t specifyhow large it is� We just say that it should not be possible to �run out of objects� duringuniverse life� That is while describing� designing or running the universe�

� a set T of types� For the size of T in concrete models� the same remark as we made for� applies�

� a function � � �� T yielding the characterizing type of each object�

� a relation part�of � ��� capturing decomposition� The expression x part�of y statesthat x occurs in the decomposition of y�

� a relation is�a � T � T expressing the subtype relationship� The expression � is�a �

states that � is a subtype of �� so an instance of � can be used whenever someoneexpects an instance of ��

� a set P of predicators� Predicators play an important role in modeling worldviewsand introducing polymorphism� They are also used to label the knowledge of objectsallowing them to restrict the domain of their knowledge�

� a function base � P � T yielding the type associated with a predicator� This type isused to restrict the set of objects allowed to occur in a knowledge element to instancesof this type or one of its subtypes�

��

���� Universe components Ch� �� Formal description of the theory

� a function knowledge � � � K where K is an abbreviation for ��K� and K � P � � isthe set of knowledge elements� So K acts as the domain for the knowledge objects haveabout other objects represented by sets of predicator�object tuples� knowledge�x� �f�p� y���q� z�g means that in the worldview of object x� y plays the role p and z playsthe role q�

� a set � of constraints that restricts the knowledge objects may have�

� a relation owns � �� � indicating which constraints should hold for each object�

� a relation models � K � � expressing how knowledge sets conform to constraints�kmodels � means that the constraint � holds for the knowledge set k�

� a set AD of action descriptions� Action descriptions should describe the semanticsof actions� A precise de nition is not needed here as action descriptions play onlya supporting role� We just demand that there should be consensus on their semanticsamong the people who are making a model� In a concrete modeling technique� an actiondescription can be anything from a simple name to a multi volume formal speci cationdocument describing the semantics of an action� Some methods �like �Mey���� specifythe semantics in terms of preconditions and postconditions�

� a set C of conditions� We won�t pose any demands on their structure� A concretetechnique should support conditions like �message X received�� More sophisticatedtechniques could also support conditions like �temperature too low� etc�

� a relation implies � C � C expressing the logical implication on conditions�

� a function behaviour � T � B associating a behaviour expression to each type� For thede nition of the set of behaviour expressionsB we introduce the following abbreviations�

T � is the set of sequences of types� de ned in the usual way�

A � AD� T � �T � is the set of actions� For an action �a�� o�� represents thetypes of the �input objects� while o represents the types of the �output objects�� Inliterature this tuple is usually called the signature of an action�

B � C � A is the set of behaviour elements� �c� a�� B is interpreted as �if cholds a will be performed�� So behaviour elements resemble the so called �guardedcommands� introduced by �Dij���

Now we can de ne the set of behaviour expressions as� B � ��B��

The set T was said to be �big enough� for our needs� But as behaviour is a functioneach type needs to have a behaviour expression associated with it� Most types won�t beused so we can simply associate the empty set with them� We will denote this �emptybehaviour expression� by �B�

� The same thing holds for objects� They all need to be characterized by a type� Tshould contain a special element� which we denote by �T � that will be assigned to allthe unused objects� �T can be seen as �the empty type�� By convention we will alwaysassign the empty behaviour to the empty type� so behaviour��T � � �B� This is formallyexpressed in axiom T� �page ����

��

Ch� �� Formal description of the theory ���� Auxiliary de�nitions

��� Auxiliary denitions

In section ��� we will formulate axioms a universe should conform to� To make those axiomsa bit more readable we now enhance our formalism by introducing some auxiliary de nitions�

� the relation acts�as � �� T is used to support polymorphism�

x acts�as � � ��x� is�a �

� we de ne part�of� � �� � as the single step variant of the part�of relation�

x part�of� y � x part�of y � z�x part�of z � z part�of y

�

� the predicate atomic � � tells if an object can�t be decomposed�

atomic�x� � y �y part�of x�

� we will overload the relation knows by providing two shorthands�knows � ��P � ��

x knowsp y � �p� y� � knowledge�x�

knows � �� ��x knows y � p�P �x knowsp y�

� the is�a relation is extended to sequences of types resulting in the relation are � T � �T ��

� are � � j� j � j�j � �i�����j�� j �i is�a �i

where j� j � j�j means that � and � have the same length and �i denotes the i�th item�type� from � �

� When you have two actions described by the same action description but the formerposes less demands on the types of the input objects or provides more information aboutthe types of the output objects� it is said to re�ne the latter� This is formalized by therelation re�nes � A�A�

�a���� o�� re�nes �a���� o�� � a� � a� �� are � � o� are o�

Other authors �like �LW��� take a similar approach� They talk about the contravarianceof arguments and the covariance of result� However� we don�t restrict the result of anaction to a single object�

� we also de ne a re nement relation for behaviour elements� re�nes � B � B�

�c�� a�� re�nes �c�� a�� � c� implies c� � a� re�nes a�

� we can now formally de ne what we mean when we say that some �type�s� behaviourcomprises some other �type�s� behaviour� For this purpose we introduce the relationcomprises � B�B�

b� comprises b� � �e��b�e��b� �e� re�nes e��

So a behaviour expression comprises another� when each behaviour element� occuringin the latter� is re ned in the former� On top of that� the comprising expression mayalso extend the behaviour by adding new behaviour elements�

�

���� Axioms Ch� �� Formal description of the theory

��� Axioms

The structure introduced so far can be populated in many ways� A lot of the possible pop�ulations don�t make sense as they do not conform to the way we think the elements of auniverse should behave� Therefore these populations have to be excluded� In this section wewill formulate the axioms an object oriented universe U should conform to�

Worldviews

As we saw in ���� worldviews allow us to describe an object�s knowledge of the world aroundit� Worldviews are formalized by the knowledge function and the derived knows relations�We demand that the knowledge� an object has about other objects� is correct�

W�� x knowsp y � y acts�as base�p�

To guarantee correct behaviour for the objects we demand that the constraints owned by theobjects are not violated�

W�� x owns � � knowledge�x� models �

Typing

The is�a relation� expressing subtyping� is re�exive and transitive�

T�� � is�a �

T�� � is�a � � � is�a � � � is�a �

This does not conform to the traditional ideas of subtyping but it does make sense when weconsider that our relation is called �is a�� It is of course possible to de ne a relation sub asthe one�step version of is�a�

The behaviour of a subtype should comprise its supertype�s behaviour� We will strengthenthis rule by demanding that when some type�s behaviour comprises that of another type� itshould �be� �play the is�a relationship with� that other type as well�

T�� � is�a � � behaviour��� comprises behaviour���

The behaviour of the special type �T should always be �B� This allows us to � ll� the totalfunction � for all unused objects�

T�� behaviour��T � � �B

In theorem ���� we will prove that �T is a �root type� by use of this axiom�

Decomposition

The part�of relation is irre�exive and transitive�

D�� x part�of x

D�� x part�of y � y part�of z � x part�of z

��

Ch� �� Formal description of the theory ���� Axioms

Some populations of the part�of relation have to be excluded� An object may e�g� not bepart of a system which is part of that object �or of another object which is part of the formerobject etc��� in other words� cycles are not allowed� This is indeed prohibited by the axiomsgiven above �proof� via transitivity we have that for each x in the cycle x part�of x whichcontradicts the irre�exivity��

These axioms are not enough� We also demand that if an object is part of any system � itoccurs directly in the decomposition of one and only one system�

D�� x part�of y � �z �x part�of� z�

Now each object which is part of a system has a direct �parent� but the �family line� can stillbe left� That is� we can still have x part�of y � x part�of z while y and z are two independentsystems� This situation is prohibited by the next axiom�

D�� x part�of y � x part�of z � y � z � y part�of z � z part�of y

Conditions

The implies relation on conditions �C� is re�exive and transitive�

C�� c implies c

C�� c� implies c� � c� implies c� � c� implies c�

Knowledge and levels of abstraction

Abstraction from details having to do with the inner structure of objects is one of the mostimportant things in object oriented systems engineering� There�s no harm done when an

Figure ���� illegal knowledge

object knows another object occuring in the decomposition of the same system on the samelevel of abstraction� but it should not be allowed to �look inside� �know any objects beingpart of� the other object or even itself� An object may look outside the system it is part of�

��

���� Axioms Ch� �� Formal description of the theory

It should do this because the knowledge of a system should be �implemented� by the objectsoccuring in its decomposition as we will see later on�

For an object to know another object� we will demand that it is �transitively� part of thesystem of which the other object is a direct part �but no part of the other object�� Thisimplies that for every object knowing another object there should be a system they both arepart of� At rst glance this seems a rather strong implication but it really ts our intuition�When we are describing or designing something� there will be one system at the top level ofabstraction having no knowledge of the rest of the universe� There always is such a system�take �the organization� or �the country� or� if all else fails� take �the universe known to man��Note that this is not equal to the object universe U we introduced� it�s a system� The objectuniverse is much bigger� it may contain other �universes� as well�� We see no reason to forbidan object to know itself� It actually comes handy not to as now an object can constrain itsown type� Formally we demand�

K�� x knows y ��x � y

��

�z �x part�of z � y part�of� z� � x part�of y

�

Figure ��� illustrates some examples of illegal knowledge� The drawing conventions used hereare the same as those used in gure ���� The reader is encouraged to convince himself�herselfthat each situation depicted there is indeed illegal� Some forms of legal knowledge are illus�trated in gure ����

Figure ���� legal knowledge

Knowledge should be consistent� When an object knows another object� this knowledgeshould be present in the decomposition �if any� of the former�

K�� x knowsp y � x �� y � atomic�x� � z �z part�of� x � z knowsp y�

Note that the same predicator is used in the two knows relations� This means that thedemands on the type of y should be re�ected in the decomposition as well� The other wayaround� when an object knows an external object� this knowledge should be re�ected on thesystem level�

K�� z knowsp y � z part�of� x � y part�of� x � x knowsp y

Note that the system depicted in gure ��� does not conform to these last two axioms� In gure ��� the necessary arrows are added�

��

Ch� �� Formal description of the theory ���� Metamodel

ppp

qq

r

s

Figure ���� consistent knowledge

Correct Implementations

Of course the objects must behave themselves according to their characterization� In otherwords� they should be implemented correctly� The provability of the correctness of implemen�tations is highly dependent on the concrete technique which is used� Therefore any concretetechnique should provide a predicate implements � � � T � x implements � should evaluateto true if and only if x provides a correct implementation of � � Now we can demand for allx � ��

I�� x implements ��x�

For a non atomic object� the implementation is provided by the objects directly occuring inits decomposition� We could argue that the behaviour elements associated with the object�stype should be partitioned over the constituting objects� This might be to strict for moresophisticated techniques with powerful action semantics however� Such techniques mightprovide rules that relate certain action descriptions like performing a� and a� in parallelfollowed by a� implies performing a��� Therefore we will demand that a concrete techniqueprovides a predicate realizes � ������� fx�� � � � � xng realizes y should evaluate to true if andonly if the combination of x�� � � � � xn is a correct realization for y� The possible decompositionsare restricted to correct realizations�

I�� fy j y part�of� xg realizes x

��� Metamodel

In the previous sections we introduced de nitions and axioms to formally describe a universeU � To gain insight in the structure of such a universe and to make the relations between itscomponents visible� gure ��� presents a metamodel of our framework� This metamodel isexpressed in the information modeling language PSM which is formally de ned in �Hof���In this technique� sets of entities of a certain type are represented graphically by circlessurrounding that type �which may be objecti ed relations� and sequences of entities of acertain type are represented by squares surrounding that type� The conventions for constraintsare the same as those in NIAM ��NH����

Label types are not drawn in the gure� We assume however that a concrete modelingtechnique provides the proper means of identi cation for instances of the entity types ��� T �

�

��� Derivable characteristics Ch� �� Formal description of the theory

P� C� AD and ��� The identi cation of instances of the other types can be found by applyingthe theory dealing with identi cation in PSM� which is presented in �Hof���

knowledge

implies

behaviour

T

�

C

AD

models

owns

�

B B A

K

K

Pbase

�

part�of is�a

T �

Figure ���� metamodel

��� Derivable characteristics

Up to now we have introduced the structure of an object oriented universe� We also speci edto which axioms populations of such a universe should conform� From these de nitions andaxioms we can derive theorems which hold in every concrete universe� In this section we willpresent some theorems which will be needed in the following chapters or will be useful togain a deeper insight in the framework� On top of that� the provability of these theorems willillustrate the power of the axioms introduced�

��

Ch� �� Formal description of the theory ��� Derivable characteristics

Lemma ����� are� re�nes � A�A� re�nes � B � B and comprises are re�exive

Proof�The re�exivity of are simply follows from the de nition of are and the re�exivity ofj�j � j�j and is�a �axiom T��From the re�exivity of are and � follows directly that re�nes � A�A is re�exiveTogether with the re�exivity of implies �assured by axiom C��� this yields the re�exivityof re�nes � B � BNow we have for b � B� �e�b e re�nes e and with the de nition of comprises we ndb comprises b� So comprises is re�exive� �

Now we can prove that two types with which the same behaviour is associated� can be usedinterchangeably� This is done by the following theorem�

Theorem ����� �type substitution�If �� � � T then�

behaviour��� � behaviour��� � � is�a � � � is�a �

Proof�Let �� � � T such that behaviour��� � behaviour���then behaviour��� comprises behaviour��� and behaviour��� comprises behaviour����follows from lemma ���� and the conjunctivity of ��Now applying axiom T� yields� � is�a � � � is�a � �

Note that not necessarily � is�a � � � is�a � � behaviour��� � behaviour��� �take e�g�behaviour��� � f�c��a� �� �� �� ���g and behaviour��� � f�c��a� ���� �����g� this doesn�tviolate axiom T� when � is�a � and � is�a ���

The is�a relation on types is visualized by a lattice like structure� One of the main questionsthat divide the object oriented community is whether this structure has a top �or root� orforms a �forest�� In our framework we can easily prove that there is a top� This is done in thefollowing theorem�

Theorem ����� �there is a root type�

��T ���T �� is�a � �

Proof�We will prove that �T is a root type�Let � � T �by de nition e�B �e � �B�so �e���Be��behaviour��� �e� re�nes e���from the de nition of comprises follows behaviour��� comprises �B�behaviour��T � � �B �axiom T�� so behaviour��� comprises behaviour��T �axiom T� now tells us that � is�a �T �

Note that �T is not necessarily the only root type� there may be more� However the behaviourassociated with any root type is always �B�

��

��� Derivable characteristics Ch� �� Formal description of the theory

Theorem ����� �behaviour of any root type is �B�If � � T then�

���T �� is�a � � � behaviour��� � �B

Proof�Let � � T such that ���T �� is�a � ��then �T is�a � so behaviour��T � comprises behaviour��� �axiom T��Axiom T� tells us that behaviour��T � � �B so with the de nition of comprises we have�e��behaviour���e���B �e� re�nes e��As �B is the empty set this evaluates to �e��behaviour��� �false�and thus behaviour��� � � �� �B� �

The following theorem states that when an object is part of another object� this is either theobject it is directly part of or its �parent� is part of that other object as well�

Theorem ����� �direct decomposition parent has same ancestors�If x� y� z � � then�

x part�of y � x part�of� z � y � z � z part�of y

Proof�Let x� y� z � � such that x part�of y � x part�of� z�when y � z then obviously y � z � z part�of yNow suppose y �� z�From axiom D� follows y part�of z � z part�of yThe de nition of part�of� tells us that there is no w such that x part�of w � w part�of zWe had x part�of y� so not y part�of z and thus z part�of y �

Finally� we present a lemma which we will need in chapter � It states that the supersetrelation on behaviour expressions �which are sets of behaviour elements� implies the comprises

relation�

Lemma ����� �superset implies comprises�If b�� b� � B then�

b� � b� � b� comprises b�

Proof�Let b�� b� � B such that b� � b� and let e � b�then e � b� �de nition of �� and e re�nes e �proven in lemma �����From the de nition of comprises we now have b� comprises b� �

��

Chapter �

Evolution� the dynamics

The framework introduced in the previous chapter is static� It allows a universe of objects tobe described at a certain moment in time� This object universe is a representation of somereal or imaginary universe of discourse or application domain we want to model� However� inpractically all cases the underlying universe of discourse won�t be static� All kinds of changesmay take place in the course of time� Children are born� people are registered in databases�cars break down and their parts are replaced� people have relationships� genes mutate� starsexplode and money �ows� We will also say that the universe of discourse evolves�As the universe of discourse changes� the universe of objects has to follow the changes

to maintain a correct representation of it� �Pro�� states that the main requirement of anevolving information system is that it�s able to evolve to the same extent and at the samepace as the underlying universe of discourse�� Of course this requirement is not limited toinformation systems� It is valid for all systems having an underlying universe of discourse�and this will be the case for all systems modeled in a technique tting the framework�These changes cause severe problems in �software� systems design� Usually at some point

in time the speci cations are frozen and a system is built� After several months �or evenyears� the system is ready and can be installed in the target environment� But during theimplementation of the system this environment has evolved so the system won�t t perfectlyanymore� And things get worse as most environments are evolving ever faster� Adapting thesystem to the new environment is usually called maintenance� but even during the mainte�nance of a system� the environment keeps changing�One of the answers of the software engineering community to this problem is to make more

�exible systems which are delivered fast and are designed to be easily adapted to changes�This is called the evolutionary approach� This approach is similar to �rapid� prototypingin that a �partially� working system is made fast� This rst prototype is not thrown awayhowever� it�s just the rst step in a life characterized by a lot of changes� The system evolvesin small steps and follows the changes in the universe of discourse more closely� This blurs thedistinction between the implementation and the maintenance phase� On a more conceptuallevel we say that an object universe is constantly being rearranged during its lifetime�

In this chapter we want to provide an initial base for modeling evolution in object orientedmodels� The introduced de nitions and axioms are by no means meant to be de nite� theyjust serve to support the general ideas� A rm formalization of evolution in an object universeremains an item for further research�

��

���� Corpus evolutionis Ch� �� Evolution� the dynamics

��� Corpus evolutionis

In information systems modeling� changes are usually divided in two groups� The rst groupconsists of changes in the population of a system� Entity types and relationship types arepopulated di�erently but the structure of the schema doesn�t change� This notion of changeis supported by all database systems� The other group consists of changes that do a�ectthe schema� Entity types and relations may be de ned or removed� Information systemssupporting both groups are coined evolving information systems� Technical support for suchsystems is not widespread� changes in the structure of a relational table may still cause a lotof problems� Population changes in information systems are comparable to changes in theknowledge of the objects in an object universe� But the possible changes in an object universeare not restricted to changes in knowledge�

Following �Pro�� we de ne the corpus evolutionis as the part of a system that is allowedto change with the course of time� This term is derived from �corpus delicti� meaning thesubstance of crime� the corpus evolutionis is the substance of evolution�

Identifying evolving components

Now which components of an object universe U as introduced in � are allowed to evolve � Theset � is not� An object can�t die or change� It can�t be born either� it is just there from thebeginning and it will stay forever� This is a rather extreme form of object persistence� but it isessential to our theory� As objects are always there and can�t change� we can identify them aswe did by adding labels� An Object can�t change but its expectations of its environment can�So changes in the universe of discourse are re�ected in an object universe by rearranging theobjects� just as changes in our real universe are rearrangements of atoms� When an object isthought to be �dead�� it is still an element of �� The behaviour of its characterizing type willjust be �B� This makes sense because this way a �dead� object can still be remembered� thatis� it can still occur in the worldview of an object� It can also �reincarnate� by characterizingit by a more lively type� its identity remains the same �We will treat the other basic components of U the same way as �� T � P� C� AD and �

are not allowed to change� However their interrelationships are rearrangeable� Note that thenon changeable types mentioned here are the types that should be identi able in a concretemodeling technique as we said in ���� This is no coincidence as an �meta� object type� ofwhich the identi cation is derivable from the identi cation of other object types� is indeed an�arrangement structure� of these object types�

So the elements of U which are allowed to evolve are�

� the function �� The characterization of an object may change� As an example considerthe birth of an instance x of type � � This is modeled by changing �� ��x� is changedfrom �T to � � The changeability of the type of an object is called metamorphism� A wellknown example of metamorphism in nature is the change of a caterpillar to a butter�y�The change of an object�s type can necessitate more changes to prevent the violation ofany axiom� In particular the worldviews of all objects should still be �valid��

� the relation part�of� When components are added to or extracted from a system �ob�ject�� this is re�ected in the part�of relation� Such a change can take place withouthaving to change the function � or another arrangement structure for the object� Inthis case the object is being re�composed without this being noticed by other objects�

��

Ch� �� Evolution� the dynamics ���� Modeling evolution

This possibility to change the implementation of an object without a�ecting any otherpart of a �software� system is often mentioned as an important advantage of objectoriented engineering� It is really an advantage of the modular way of building soft�ware� If well designed� objects just prove to be natural modules which are very cohesiveand loosely coupled� two important characteristics of good modular design �see e�g��Som����

� the relation is�a� A change of the relation is�a will usually be caused by a change ofthe function behaviour� Axiom T� �page ��� demands that the relation is�a is changedaccordingly� Note that such a change may have severe consequences for the correctnessof the objects� worldviews� Changing the type hierarchy is not allowed when this wouldcause axiom W� �page ��� to be violated� In this case the worldviews of the concernedobjects will have to be adapted as well�

� the function base� When for a certain kind of knowledge� represented by a predicator�another type is needed� the function base can be changed accordingly� Note that thismay have severe consequences for the correctness of the objects� worldviews as well�

� the function knowledge� When the worldview of an object changes� the function knowledgeshould be changed accordingly� These changes can e�g� be caused by a change in theimplementation of an object� causing it to pose di�erent demands to its environment�

� the relation owns� Changes in the worldview of an object can also a�ect the relationowns� When an employee retires� he no longer has to know his boss� So the constraintthat restricts the knowledge of the employee object to the knowledge including �bossknowledge� can be dropped�

� the function behaviour� Changing the behaviour associated with a type can be done bychanging the function behaviour� Such changes may become necessary when a relevantaspect of a concept is added� removed or changed� As an example consider a new lawwhich demands that each food product gives information about its ingredients� Now itbecomes clear why we allow two types to be associated with the same behaviour� Whena certain type had the same associated behaviour as the type �food product� but thenew law doesn�t apply to it� we just change the behaviour of �food product� withouthaving to change � for all instances of the other type� So the situation in which twotypes have the same behaviour associated with them will probably be a temporal one�Note that a change of the function behaviour will probably e�ect the relation is�a andtherefore might interfere with the worldviews of some objects� Care has to be taken asto prevent any axioms from being violated�

Note that models and implies are left out of the corpus evolutionis� This is done because theserelations are time independent truths in the concrete modeling technique used�

��� Modeling evolution

Now we have identi ed the �moving parts� of an object universe� the corpus evolutionis� thequestion remains how to model the movement� When looking at the bubbling universe� at anyone moment in time we see a static structure being an U as de ned in chapter �� The �static�

�

���� States Ch� �� Evolution� the dynamics

population of the corpus evolutionis at one moment in time is called a state of the universe�The evolution or history of an object universe can be seen as a sequence of consecutive states�

�Pro�� argues that simply modeling a sequence of states �or snapshots as he calls them�does not provide relations between successive versions of the application model elements�all instances of all evolvable object types in his theory�� In his model this is true becausethe elements occuring in the snapshots do not have an implicit identity� This is solvedby introducing functions over time linking the appearances in the several snapshots� Thefunctions over time are coined element evolutions� The snapshots can easily be derived fromthese element evolutions� Figure ��� illustrates this� The dots are application model elements�appearances�� The functions over time� linking them� are represented by dotted lines�

time

Figure ���� snapshots and element evolutions

So element evolutions are introduced to model identity over time� In our theory� identityis an implicit characteristic of objects� So the relation between successive versions of an object�the roles it plays in successive states of the corpus evolutionis� is clear� it�s the same object�Objects are kept out of the corpus evolutionis just like the underlying domain of values in�Pro��� We don�t need to introduce element evolutions when we want to keep track of theroles played by a certain object �or a type etc� in the course of time� We can derive this fromthe roles it plays in the consecutive states� Another advantage of our approach is that wedon�t need an axiom for evolution separation� In �Pro�� such an axiom is needed to preventan object from turning into a type or constraint etc� As the basic building blocks of ouruniverse ��� T � P� C� AD and �� are not part of the corpus evolutionis� such changes areimpossible�

��� States

We model evolution as a consecutive sequence of states� But what determines which statesoccur in such a sequence and the order in which they occur � One reason for changing thecurrent state� and thus adding a new state to the sequence following the former� is that theobject universe should follow the changes in the universe of discourse� Changes can also becaused by an object being re�implemented and yet another reason is that the state of theuniverse is changed because of actions performed by the objects in it� The rst two reasons

��

Ch� �� Evolution� the dynamics ���� Universe history

are very hard to formalize� to say the least� As a rst attempt to formalize the third reasonwe will extent the notion of states�

We will incorporate two new relations in a state�

� a relation holds�for � C � � expressing which conditions are true for each object�c holds�for x means that condition c is true for object x�

� a relation performs � � � A � ��� where �� stands for the set of sequences of ob�jects de ned in the usual way �like T ��� expressing which actions are performed byeach object� x performs a��y�� y�� � � � � yn�� means that object x performs action a withparameters y�� y�� � � � � yn�

We de ne S as the set of all possible states� The size of S is restricted by the followingaxiom which states that an object can only perform actions when this is speci ed in thebehaviour associated with its type� It also demands that the objects on which the action isperformed should be of the right types as de ned in the signature of the action� In otherwords the parameters should respect the action�s signature� This is another place where wesee polymorphism in action�

S�� x performs a�y� � ����o�T � ��a�� o�� behaviour���x�� � y matches �

where matches � �� � T � is de ned as follows�

x matches � � jxj � j� j � �i�����j�xj �xi acts�as �i �

��� Universe history

Evolution obviously has to do with time� We will abstract from all the complex issues involvedin modeling time and use a very simple time axis T � � � � � ti��� ti� ti��� � � � which is supposedto be discrete and totally ordered and can easily be de ned formally by use of a successor� apredecessor and a comparison operation� This means that we can speak of consecutive timepoints and of time points in a time segment� We won�t specify if T should be in nite or if itshould have an end point� this depends on the concrete situation we are modeling� A universehistory UH can now be de ned as a partial function mapping each time point to a state�

UH � T � S

Although we de ned a universe history as a partial function we do demand that it is de nedfor a full segment of time� This is done by the following axiom�

E�� UH�ti�� � UH�tj�� � �k�i�����j �UH�tk���

For a concrete universe history we will write �t when we mean the function � in the stateUH�t�� The abbreviations part�oft� is�at� baset� knowledget� ownst� behaviourt� holds�fort andperformst are de ned analogously�

Now we can formulate an axiom stating that� if in a state some condition holds for a certainobject and this condition makes sense to it �it knows how to react to it�� this condition stillholds in the following state or the object reacts to it by performing the appropriate action�

��

���� Universe history Ch� �� Evolution� the dynamics

E�� if UH�ti�� � UH�ti���� then�

c holds�forti x � c holds�forti�� x � a�A� �y�� ��c� a�� behaviourti����ti���x�� �

x performsti�� a�y��

We will now introduce the notion of substates� A state is a substate of another state ifthe facts� presented in it� hold in that other state as well� Formally� we de ne a relationsubstate � S � S as follows�

S� substate S� � �x� ��S��x� is�a �S��x�� �

�part�ofS� � part�ofS�� �

�p�P �baseS��p� is�a baseS��p�� �

�x� �knowledgeS��x� � knowledgeS��x�� �

�ownsS� � ownsS�� �

���T �behaviourS���� comprises behaviourS����� �

�holds�forS� � holds�forS�� �

�performsS� � performsS��

In this de nition �S� is used as an abbreviation for the function � in state S�� The otherabbreviations are de ned analogously� S� substate S� is used to express that S� is a substateof S�� We will also say that S� is a superstate of S��

The de nition of substates will be used to restrict the number of possible states to whicha particular state can evolve� For this purpose we also introduce a relation allows�evol �� � S � S� x allows�evol�S�� S� expresses that object x allows the universe to evolve fromstate S� to �a superstate of� S�� allows�evol is not a function so there might be another stateS� such that also x allows�evol�S�� S��Suppose we are now at time point ti� then the current state is UH�ti�� The universe

can not simply evolve to any state at time point ti��� The wishes of each individual object�expressed by allows�evol� have to be ful lled� Therefore we demand that the universe evolvesto a superstate of at least one of the states to which it is allowed to evolve by each object�This is formulated in the following axiom�

E�� if UH�ti�� � UH�ti���� then�

�x�S�S �x allows�evol�UH�ti��S � S substate UH�ti����

Objects which don�t pose any demands on the future state can simply restrict the set ofallowed states to the supertypes of the �empty state�� This �empty state� will be denotedby �S � By de nition we have� �x� ���S �x� � �T �� part�of�S � �� �p�P �base�S �p� � �T ���x� �knowledge�S �x� � ��� owns�S � �� ���T �behaviour�S ��� � �B�� holds�for�S � � andperforms�S � �� From this de nition the following corollary can easily be derived�

��

Ch� �� Evolution� the dynamics ���� Universe history

Corollary ����� �S is substate of every state

�S�S ��S substate S�

So for a particular object x� x allows�evol�UH�ti�� �S indeed doesn�t restrict UH�ti��� at all�

This is where our initial research in the evolution of an object universe ends� The frameworkprovides the means to model state changes and restrictions imposed to them by individualobjects� However� more research has to be done as to the reasons the objects have to steerevolution in a certain direction� Therefore special attention will have to be paid to the linkingof the framework with techniques which model the course of life of the objects�

�

���� Universe history Ch� �� Evolution� the dynamics

��

Chapter �

Object retrieval

Object oriented software engineering is often advocated as being the perfect way to buildand change systems fast� Systems can be composed from components �objects� which canbe trusted to behave themselves in a speci ed way and clearly de ne their expectations ofthe world around them �we formalized this by use of worldviews�� These components can beready made and stored somewhere� they can be bought from vendors or they can be producedin house�

One of the major problems we encounter when designing object oriented systems is to ndthe proper �speci cation of� objects to use� First we have to nd out which types the neededobjects should have� Then for each object we have to nd an implementation or specify one�This implementation poses demands on the environment of the object as we saw in chapter�� The objects have to t together� These demands re�ect the worldview of the object andconstrain the number and the types �depending on their associated behaviour� of the objects�needed to be� known by it� So now we have to nd types and behaviour again� It is clearthat this is not a sequential process but an iterative and creative one� Most methods provideguidelines and rules of thumb but designing systems remains an art� A developer can improvehis skills however by gaining experience�

Nowadays object orientation is becoming widely accepted and a growing number of classlibraries is being made available by an also growing number of vendors� At rst sight thisseems to be a positive development but it makes it even harder to nd the objects we need�in general it is more di�cult to nd a needle in a bigger haystack than in a smaller one��This development obviously stresses the need for good object retrieval methods�

The term object retrieval is derived from information retrieval which is concerned withdisclosing stored information in order to ful ll information needs� �Bru�� argues that theterm information disclosure should be prefered over information retrieval to stress that adisclosure system is involved� We will use the term object disclosure as the object equiva�lent of information disclosure and will use the terms object retrieval and object disclosureinterchangeably� Figure �� illustrates the information retrieval paradigm as presented by�Bru��� The cartoon character represents a person having an information need� This needis formulated in a request� The stored information is represented by the documents on theright hand side of the gure� For the �information objects� contained in these documents acharacterization is made� this is called indexing� Supply and demand are brought togetherby matching the request with the characterizations�

Object retrieval is a special form of information retrieval as we want to disclose objects

��

��� Three layer strategy Ch� �Object retrieval

formulation

matching

indexing

needinformation

request characterization

Figure ��� the information retrieval paradigm

�and types� instead of documents �It can be argued however� that the description of objectsand types can be seen as documents�� These objects are characterized by their types and theassociated behaviour� But that�s not all� they also pose demands on their environment� Sowhen we have found the right behaviour and type� the search continues� Now we focus onthe speci c details of the objects produced by the di�erent vendors�To support our search for concrete �speci cations of� objects we introduce a multi layer

strategy� We want to stress that the ideas presented here are not fully developed� Theyjust provide a starting point for further research in the area of object library managementtechniques�

��� Three layer strategy

In this section we will propose a disclosure mechanism for object retrieval using the theoryintroduced in this thesis� In this mechanism the retrieval process involves three layers�

� the behaviour layer

� the type layer

� the vendor layer �or class layer�

The behaviour layer allows us to browse through behaviour expressions� From a selectedbehaviour expression we can navigate to the types with which the speci ed behaviour isassociated �if any�� These types reside in the type layer� In this layer we can browse theis�a hierarchy� When we have selected a type we can navigate to the vendor layer wherewe nd possible implementations of objects characterized by that type� Here we can choose

��

Ch� �Object retrieval ��� Behaviour navigation

an implementation �class�� The information needed to make this choice is present at thevendor layer� Besides worldviews and decomposition information� additional information likeprice� implementation hierarchy in an object oriented programming language �class hierarchy��estimated production costs� implemented code� performance statistics etc� can be includedhere� Exploring the vendor layer will probably cause the other layers to be revisited�The navigation between layers is called inter layer navigation or beaming� While designing

systems� designers will not use the layers in a strictly sequential order� Heavy inter layer tra�cwill occur in practically all directions and many focuses will be explored at the same time�The division in layers presented here is purely conceptual� Figure �� illustrates the idea ofthe three layer architecture�

smalltalkvendor’s

needobjects

Figure ��� three layer disclosure strategy

It is very hard �or even impossible� to formalize disclosure at the vendor layer as choicesmade there involve human decisions� How do you formalize arguments like �I don�t trust thatvendor� or �We don�t produce that object�class� ourselves because our chief programmer ison vacation�� Disclosure at the type layer means browsing the lattice re�ecting the �one step�is�a hierarchy� This is pretty straightforward although some attention should be paid to thefact that nodes in this lattice can �and will� have multiple parent nodes� So a simple treebrowsing mechanism won�t do� Section �� is devoted to browsing at the behaviour layer�

��� Behaviour navigation

The hyperindex technique

For the disclosure at the behaviour layer we adopt and adapt the hyperindex technique aspresented in �Bru��� In this technique information objects are characterized by index ex�pressions� Power index expressions are introduced via the subexpression relation on indexexpressions� The power index expression of a certain index expression is de ned as the setof all subexpressions of that expression� For each index expression a power index expres�sion is made� From the union of all power index expressions a lattice�like structure� termed

��

��� Behaviour navigation Ch� �Object retrieval

lithoid� is rendered� Each vertex in the lattice is seen as a potential focus of the searcher�The surrounding vertices of a certain vertex are enlargements or re nements of the contextrepresented by the focus implied by that vertex�

Adapting the technique

In section ��� behaviour expressions were de ned as a set of behaviour elements� Theseexpressions will serve as our equivalent of index expressions� The power behaviour expressionof a behaviour expression b � B is de ned as follows�

Pb � ��b�

For such a power behaviour expression we can easily create a lattice where the underlyingordering relation is the subset relation� The behaviour expression itself is the top of thelattice and the empty set is the bottom� This empty set is the special behaviour expression�B introduced in ���� it stands for �no behaviour��We can now make a lithoid by forming the union of all power behaviour expressions for

all types�lithoid power behaviour expression�

�

��T

Pbehaviour���

Lemma ���� tells us that the superset relation on behaviour expressions implies the comprises

relation� This lemma ensures that taking subsets will yield a part of the lithoid we wouldget when we would de ne power behaviour expressions in terms of the relation comprises�Remember that we de ned B as a carthesian product� so incorporating all behaviour expres�sions would yield an enormous lithoid� By using subsets in the de nition we only incorporatethe behaviour expressions that will eventually lead us to an expression with which a typeis associated� So we won�t have to search trough behaviour expressions that will lead usnowhere� When� while navigating through the lithoid� we can�t get any closer to a requiredbehaviour description� a new association between a type and a behaviour expression has tobe added� By de nition this behaviour expression will now show up in the lithoid�The lithoid does not yet re�ect the comprises relation completely though� We have to

add some links to incorporate the re�nes relation on the behaviour elements constituting thebehaviour expressions� In the lattice only one step links will occur� So we have�

add link �b � fe�g� b � fe�g� � e� re�nes e�

Now the lattice re�ects the comprises relation on the lithoid power behaviour expression� In�Bru�� the edges were undirected� the direction in which the focus moved �enlargement orre nement� followed from the relative vertical positions of the index expressions� Going downyields a larger context while going up re nes the context� In our lithoid we will use directededges following the inverse comprises relation� This means that an arrow is drawn from b�to b� when b� comprises b�� So following the arrows� the context is re ned and more speci cbehaviour is found�

As an example consider a simple object universe where T � f�� �� �� �T g� b�� b�� b� � B�behaviour��� � fb�� b�g� behaviour��� � fb�� b�g and behaviour��� � �B while b� re�nes b�� Inthis example the lithoid power behaviour expression is f�B� fb�g� fb�g� fb�g� fb�� b�g� fb�� b�gg�In gure �� the resulting lithoid is drawn� Note that arrows are added from fb�g to fb�g andfrom fb�� b�g to fb�� b�g�

��

Ch� �Object retrieval ��� Behaviour navigation

fb�g

fb�� b�g

fb�g

fb�g

fb�� b�g

�B

Figure ��� example lithoid

At the behaviour layer we browse the lithoid by moving our focus along the edges in thedirection of the requested behaviour� This way of searching is called query by navigation in�Bru��� We just start in �B and follow the arrows� When the required behaviour expression isencountered� we look if there is any type with which this behaviour expression is associated�If not� we can look for a type which behaviour comprises the required behaviour� Or wecan �create� a type concept �and think of a useful name for it� by associating a previouslyunused element of T with the behaviour expression we found� In the example we couldchange behaviour��� to fb�g when fb�g would represent the requested behaviour and descentto the type layer while focusing on �� At the type layer we might decide to use another typeassociated with the same behaviour �if any�� before we descent to the class layer� And this isthe layer where we will do our shopping�

�

��� Behaviour navigation Ch� �Object retrieval

��

Chapter �

Conclusions and directions for

further research

In this thesis we presented a conceptual theory for modeling systems based on object orientedprinciples� The need for such a theory was stressed in the introduction� In this introductionwe also formulated the problem statement of this thesis� Our aim was to present a rst at�tempt towards a new theory for systems modeling� This theory should be based on objectoriented principles� on a conceptual level and formally de ned� Furthermore it should serveas a base for areas of research related to object oriented software engineering� The principleconcepts of object orientation were introduced on a conceptual level in chapter �� Theseconcepts were then formalized in chapter �� The theory was extended with dynamic aspectsin chapter � and in chapter we used the theory as a base to present some ideas for thedisclosure of objects�

We will now brie�y highlight the major conclusions per chapter� Some interesting elds forfurther research are pointed at as well�

In chapter � we informally presented the basic concepts of object orientation �in our view��The term object universe was introduced� In such an universe reside objects and systems� Wede ned an object as the smallest thing we want to look at at a certain level of abstraction�In other words� it is supposed to be atomic on that level of abstraction and we can�t see itsinner structure� We argued that objects can be distinguished from each other even if they�look� the same� So there is a notion of identity� This identity is not an arti cial introductionof identifying codes� It is an implicit characteristic of objects�

Besides objects� an object universe was also said to contain types� Each type has someassociated behaviour� When the behaviour associated with a certain type comprises thatof another type� it is a �subtype of� the latter by de nition� Each object is characterizedby a type� However� di�erent objects characterized by the same type can be implementeddi�erently and can be supplied by di�erent vendors� The implementation of an object isdetermined by its class� A class simply serves as a blueprint�Objects don�t live solitary� They have interrelationships and they communicate� Data

values and attributes were argued to be implementation aspects� Communication was con�ceptualized by making objects act on certain conditions� What an object will do and when itwill do it� depends on the behaviour associated with its type� Di�erent from entity relation�ship like modeling techniques� we didn�t introduce relationships as a separate concept� They

��

Ch� �� Conclusions and directions for further research

were modeled by letting objects have knowledge of other objects� The kind of knowledge wasspeci ed by predicators� Each predicator is connected to a type� called its base�This idea of �creeping in the skin� of object and looking outside to see what it sees around

itself was captured by the introduced concept of worldviews� The possible knowledge of anobject can be restricted by de ning constraints for that object� A nice aspect of worldviews isthat an object does not have to know everything about each object appearing in its worldview�Such an object may be able to do a lot more than our object knows� It is just guaranteedthat it will at least conform to the behaviour associated with the base of the predicator spec�ifying the knowledge� It�s characterization can be many types� So here we had polymorphismas a welcome by�product� Another nice by�product was the notion of multiple views of anobject which simply followed from the idea of worldviews rather than having to be de nedseparately�When leaving the current level of abstraction� we saw that a system constitutes other

systems on a higher level and that an object is composed of objects residing on a lowerlevel� So objects and systems proved to be the same concepts� It just depends on the levelof abstraction we are currently working whether we call something an object or a system�Understanding this is a very important as it enables one to model arbitrary complex systemson several levels of abstraction� To conclude this chapter� we addressed how use cases andgenericity relate to our theory�

The concepts introduced in chapter � were formalized in chapter �� In this chapter we de nedan object universe as a structure U � The components constituting a universe were de ned�We also presented the axioms to which each object universe should conform� A metamodeldescribing an object universe was shown and some characteristics were derived and provedto hold in each object universe� We proved e�g� that there is a root type� that is the typehierarchy has a top�

The dynamic aspects were dealt with in chapter �� Here evolution of an object universe wasseen as a sequence of rearrangements of its components� We identi ed the corpus evolutionis�which is that part of an object universe that�s allowed to change with the course of time�Components like objects and types were not allowed to change but the arrangement struc�tures connecting them were� We then argued that identity links the appearances of objects atseveral time points in a natural way� So we can keep track of a single object when we modelevolution as a sequence of states �snapshots��The de nition of states was extended with a relation describing which actions are per�

formed by each object and a relation allowing each object to steer the course of evolution�The notion of a universe history was de ned as a partial function mapping a segment of atime axis to states� This allowed us to formulate an axiom stating that objects should reacton conditions as speci ed by the behaviour associated with their type and that the argumentsof an action should respect the action�s signature� The de nition of substates helped to for�mulate an axiom which restricts the possible order of states occuring in a universe history�This chapter provided only a rst attempt at formalizing evolution in an object universe�

A rm formalization remains an item for further research� Another interesting subject for re�search is incorporating ideas from techniques describing the course of life of individual objectsor the interactions between objects in the course of time� These descriptions would re ne ourgeneral notion of the relation allows�evol�

In chapter we brie�y touched the area of managing object libraries� We argued that� when

��

Ch� �� Conclusions and directions for further research

we are building a system by putting together ready made components made by di�erent ven�dors� good methods are needed to nd the right combination of components �objects�� Weused the terms object retrieval and object disclosure in this respect� Based on our theory weproposed a three layer disclosure strategy� We then adapted the hyperindex technique� takenfrom the eld of information retrieval� and incorporated it in our theory for disclosure at thebehaviour layer� From this layer we can descent to the type layer where we can pick a typewhich behaviour comprises the speci ed behaviour� Then we visit the vendor layer where wedo some window shopping and negotiate with vendors�More research is needed in this eld as well� We easily stepped over the problem of nding

the appropriate actions� This will require good action speci cation techniques� Other aspectssuch as language di�erences should be looked at too� When we want to nd combinations ofobjects� they should be able to understand each other �

Other interesting elds emerge when we want to use the theory as a base for object orienteddatabases� It would be interesting to adapt the idea of a structural query language like LISA�D which is de ned in terms of path expressions in �Hof��� However� in our theory these pathswould not follow the structure of a model �the knowledge of the objects in our theory�� Itwould rather follow behaviour paths� For every argument of an action a path expression couldbe passed and� as we allow multiple result objects� there are several directions to continueour path�When we forget about behaviour� an object oriented data model remains which provides

the strong notion of identity� abstracts from structure and allows for unidirectional relation�ships through the notion of worldviews� It would be interesting to compare this model withsophisticated modeling techniques like PSM� which is presented in �Hof��� and look at theadvantages and disadvantages of the two approaches�

As our nal direction for further research we would welcome the implementation of asimple object universe shell� This could be used to study the suitability of our theory andthe idea of evolution as rearrangements of a constant amount of matter �objects� types etc��Special care will have to be taken to enforce all the axioms presented in this thesis�

We would like to conclude this thesis by saying that we hope that you found the ideas pre�sented in it to be interesting and fruitful and that they will inspire you and other researchersin future work�

�

Ch� �� Conclusions and directions for further research

�

Bibliography

�Ber�a� L�M�J� Bergmans� Composing concurrent objects� PhD thesis� University ofTwente� Enschede� The Nederlands� June ���

�Ber�b� L�M�J� Bergmans� The Composition�Filters Object Model� In Proceed�ings of the RICOT symposium �Enabling objects for Industry�� University ofTwente�RICOT �Research Initiative on Compositional Object Technology�� TheNetherlands� ��� derived from chapter � of �Ber�a��

�BFP�� M� L� Barja� A� A� A� Fernandes� N� W� Paton� M� H� Williams� A� Dinn� andA� I� Abdelmoty� Design and Implementation of Rock Roll� a DeductiveObject�Oriented Database System� Information Systems� ������ ��

�Boo�� G� Booch� Object�Oriented Design with Applications� Benjamin Cummings�Redwood City� California� ���

�Bru�� P�D� Bruza� Strati�ed Information Disclosure� A Synthesis between InformationRetrieval and Hypermedia� PhD thesis� University of Nijmegen� Nijmegen� TheNetherlands� ���

�Bud�� T� Budd� an introduction to object�oriented programming� Addison�Wesley Pub�lishing Company� April ��� Oregon State University�

�Che��� P�P� Chen� The Entity�Relationship Model� Toward a Uni ed View of Data�ACM Transactions on Database Systems� �����!��� March ����

�CY�� P� Coad and E� Yourdon� Object�Oriented Analysis� Yourdon Press� New York�New York� ���

�Dij�� E�W� Dijkstra� Guarded Commands� Nondeterminacy� and Formal Derivationof Programs� Communications of the ACM� ��������!��� August ���

�EE�� J� Ebert and G� Engels� Structural and Behavioural Views on OMT�Classes� InE� Bertino and Urban S�� editors� Object�Oriented Methodologies and Systems�International Symposium� ISOOMS � Palermo� Italy� Proceedings� SpringerVerlag� ���

�Fir� D� Firesmith� Inheritance guidelines� Journal of Object Oriented Programming������ May ��

�Hof�� A�H�M� ter Hofstede� Information modeling in data intensive domains� PhDthesis� University of Nijmegen� Nijmegen� The Netherlands� ���

�

Bibliography Bibliography

�JBJE� I� Jacobson� S� Bylund� P� Jonsson� and S� Ehneboom� Using contracts and usecases to build plugable architectures� Journal of Object Oriented Programming������ May ��

�JC� I� Jacobson and M� Christerson� A growing consensus on use cases� Journal ofObject Oriented Programming� ����� March�April ��

�JCJvO�� I� Jacobson� M� Christerson� M� Jonsson� and P� van Overgaard� OO SoftwareEngineering� A Use Case Driven Approach� Addison�Wesley� Reading� Mas�sachusets� ���

�KC��� S� N� Khosha an and G�P� Copeland� Object Identity� In Object�oriented pro�gramming systems� languages and applications� �OOPSLA� conference proceed�ings� Sigplan notices� New York� ���� Association for Computing Machinery�ACM��

�LP�� W� LaLonde and J� Pugh� Subclassing �� subtyping �� Is�a� Journal of ObjectOriented Programming� January ���

�LW�� B� H� Liskov and J� M� Wing� A Behavioural Notion of Subtyping� ACMTransactions on Programming Languages and Systems� ������ November ���

�Mey��� B� Meyer� Object�oriented software construction� Prentice�Hall internationalseries in computer science� Prentice�Hall� New York� ����

�NH�� G�M� Nijssen and T�A� Halpin� Conceptual Schema and Relational DatabaseDesign� a fact oriented approach� Prentice�Hall� Sydney� Australia� ���

�Pat�� D� Patching� Practical soft systems analysis� Pitman Publishing� London� ���

�Pro�� H�A� Proper� A Theory for Conceptual Modelling of Evolving Application Do�mains� PhD thesis� University of Nijmegen� Nijmegen� The Netherlands� ���

�RBP��� J� Rumbaugh� M� Blaha� W� Premerlani� F� Eddy� and W� Lorenson� Object�Oriented Modeling and Design� Prentice�Hall� Englewood Cli�s� New Jersey����

�Rum� J� Rumbaugh� OMT� The dynamic model� Journal of Object Oriented Program�ming� February ��

�Som�� I� Sommerville� Software Engineering� Addison�Wesley� Reading� Massachusetts����

�Tay�� D�A� Taylor� Object�oriented technology� a managers guide� Servio� Alameda����

�Vel�� J� in �t Veld� Analyse van organisatie problemen� een toepassing van denken insystemen en processen� Stenfert Kroese� Leiden�Antwerpen� � edition� ��� �indutch��

�WB�� R� Wirfs�Brock� Designing scenarios� Making the case for a use case framework�The Smalltalk Report� ����� ���

�

Bibliography Bibliography

�WBWW�� R� Wirfs�Brock� B� Wilkerson� and L� Wiener� designing object oriented software�Prentice�Hall� Englewood Cli�s� New Jersey� ���

�

Bibliography Bibliography

�

Index

abstracting out complexity� ��abstraction

from implementation� �levels of� ��� ��

action descriptions� ��actions� ��� ��

semantics� ��active objects� ��acts as� �adapting a system� �� �allows evol relation� ��ambiguity� anthropomorphism� ��application domain� ��� ��are relation� �associations� �atomic� ��� ��

predicate� �attributes� �� �axioms� ��

base� ��� ��beaming� ��behaviour� ��� ��� ��

comprising� ��behaviour elements� ��behaviour expression� ��behaviour expressions� ��behaviour function� ��black box� ��� ��black box view� ��blueprints� ��boundary� ��

changingenvironment� ��

characterization� ��� ��class� ��

hierarchy� �� ��

client object� ��code

reuse of� �combination

of components� �communication� ��complexity� ��

mastering� �of software� �

componentscombination of� �of an object universe� ��� ��production� �standard� �

comprises� �comprising behaviour� ��concepts� �conceptual theory� �

need for� �conceptualization principle� ��conditions� ��� ��consistent knowledge� ��constraints� ��� ��contract� ��contravariance of arguments� �corpus evolutionis� ��covariance of result� �

data elds� �decomposition� �� ��demands on environment� ��design decisions� �developer�s view� ��di�erent implementations� ��domain� �domain of values� ��

ecosystem� ��emergence� ��

Index Index

empty behaviour expression� ��empty type� ��environment� ��� �

changing� �� �� ��demands on� ��system tting in� �� �

evolution� ��� ��evolutionary approach� ��evolving information system� ��evolving information systems� ��external object� ��� �

forest� ��formality

lack of� framework� ��functional

requirements� ��speci cation� ��

functionality� �

generalization� ��genericity� ��guarded commands� ��guidelines� � ��

for inheritance� �

heuristics for subclassing� �hierarchy

of classes� �� ��of types� ��� �

history� ��� ��holds for relation� ��

identifying codes� ��identity� ��� ��implementation

of behaviour� ��implementation aspects� �implements predicate� �implies relation� ��information disclosure� ��information hiding� ��information retrieval� ��inheritance� �� ��

guidelines� �multiple� ��

instance

of a class� ��of a type� ��

instance connections� �� �inter layer navigation� ��interactions� ��interface� ��internal objects� ��is a� ��

knowledge� ��� ��knowledge elements� ��knows relation� �

label types� �labels� ��� �lattice� ��levels of abstraction� ��� ��library management� ��lithoid� ��

maintenance� �� ��management of object libraries� ��mass production� �

of components� �message connections� �messages� �metamodel� �metamorphism� ��methods� �� ��model

semantics� models relation� ��modularity� �multiple inheritance� ��multiple views� ��

object� ��� ��� ��behaviour� ��de nition� ��external� ��� �internal� ��state� ��

object assembly� �object disclosure� ��object orientation� �

concepts� �object retrieval� ��object universe� ��� ��

�

Index Index

components� ��� ��organization of complexity� ��overriding methods� �owns relation� ��

paradigma new� �

part of� �� ��� �performs relation� ��persistence� ��plugable architectures� �polymorphism� ��� �� ��pool� ��population� ��postconditions� ��power behaviour expression� ��preconditions� ��predicator� ��� ��procedures� ��production

a new way� �of components� �� �traditional� �

property� �distinguishing� ��

protocol� ��prototyping� ��

query by navigation� �

rapid prototyping� ��realize predicate� �rearrangements of objects� ��receiver� ��re nes relation� �relationships� �reuse of code� �root� ��rules of thumb� � ��

schema� ��semantics�

of actions� ��sequences of types� ��server� ��services� ��signature� ��� ��snapshots� ��

software crisis� �specialization� ��speci cation� ��standard components� �state� ��

of an object� ��� �subjects� ��substate� ��subsystem� �subtype� ��superstate� ��supertype� ��system� ��� ��

adapting� �de nition� ��

terminology� �theory

conceptual� �three layer architecture� ��time axis� ��top� ��traditional systems engineering� �type� ��� ��

hierarchy� ��� �

universe� ��� ��of objects� ��

universe history� ��universe of discourse� � ��� ��use cases� ��user�s point of view� ��

value� �vendors� �� ��views

multiple� ��

whole�part structure� �worldviews� ��� ��� ��

�