§8 1 OBJECTS 227 Such cycles in the dynamic structure can only exist if the client relation among the corresponding classes also has direct or indirect cycles.In the above example,the class declaration is of the form class PERSONI feature name:STRING loved one,landlord:PERSONI end showing a direct cycle (PERSON/is a client of PERSON/). The reverse property is not true:the presence ofa cycle in the client relation does not imply that the run-time structure will have cycles.For example you may declare a class class PERSON2 feature mother,father:PERSON2 end which is a client of itself,but if this models the relations between people suggested by the attributes'names,there can be no reference cycle in the run-time structure,as it would imply that a certain person is his own parent or indirect ancestor. A look at the run-time object structure From what we have seen so far emerges a first picture of the structure of an object-oriented system during its execution. A possible run- time object root structure 27 "Raphael" (TYPEI) 3.5 (TYPE4) "Sarah" True (TYPE3) 897 Z (TYPE5) -62 "Caroline" (TYPEI) (TYPE2)
§8.1 OBJECTS 227 Such cycles in the dynamic structure can only exist if the client relation among the corresponding classes also has direct or indirect cycles. In the above example, the class declaration is of the form class PERSON1 feature name: STRING loved_one, landlord: PERSON1 end showing a direct cycle (PERSON1 is a client of PERSON1). The reverse property is not true: the presence of a cycle in the client relation does not imply that the run-time structure will have cycles. For example you may declare a class class PERSON2 feature mother, father: PERSON2 end which is a client of itself; but if this models the relations between people suggested by the attributes’ names, there can be no reference cycle in the run-time structure, as it would imply that a certain person is his own parent or indirect ancestor. A look at the run-time object structure From what we have seen so far emerges a first picture of the structure of an object-oriented system during its execution. A possible runtime object structure "Raphaël" 27 "Sarah" 3.5 – 62 "Caroline" root True 'Z' (TYPE1) (TYPE4) (TYPE2) (TYPE1) (TYPE3) 897 (TYPE5)
228 THE RUN-TIME STRUCTURE:OBJECTS $8.2 The system is made of a certain number of objects,with various fields.Some of these fields are values of basic types(integer fields such as 27,character fields such as'Zand so on);others are references,some void,others attached to objects.Each object is an instance ofsome type,always based on a class and indicated below the object in the figure. Some types may be represented by just one instance,but more commonly there will be many instances of a given type;here TyPE/has two instances,the others only one.An object may have reference fields only;this is the case here with the TyPE4 instance,or basic fields only,as with the TYPE5 instance.There may be self-references:direct,as with the top field of the TyPE2 instance,or indirect,as with the clock-wise reference cycle starting from and coming back to the TyPE/instance at the top. This kind of structure may look unduly complicated at first-an impression reinforced by the last figure,which is meant to show many of the available facilities and does not purport to model any real system.The expression"spaghetti bowl"comes to mind. But this impression is not justified.The concern for simplicity applies to the software text and not necessarily to the run-time object structure.The text of a software system embodies certain relations(such as"is child of","loves","has as landlord");a particular run-time object structure embodies what we may call an instance of these relations-how the relations hold between members of a certain set of objects.The relations modeled by the software may be simple even if their instances for a particular set of objects are complex.Someone who considers the basic idea behind the relation"loves"fairly simple might find the instance of the relation for a particular group of people-the record of who loves whom-hopelessly entangled. So it is often impossible to prevent the run-time object structures of our O-O systems from becoming big (involving large numbers of objects)and complex (involving many references with a convoluted structure).A good software development environment will provide tools that help explore object structures for testing and debugging. Such run-time complexity does not have to affect the static picture.We should try to keep the software itself-the set of classes and their relations-as simple as possible. The observation that simple models can have complex instances is in part a reflection on the power of computers.A small software text can describe huge computations;a simple O-O system can at execution time yield millions of objects connected by many references.A cardinal goal of software engineering is to keep the software simple even when its instances are not. 8.2 OBJECTS AS A MODELING TOOL We can use the techniques introduced so far to improve our understanding of the method's modeling power.It is important in particular two clarify two aspects:the various worlds touched by software development;and the relationship ofour software to external reality
228 THE RUN-TIME STRUCTURE: OBJECTS §8.2 The system is made of a certain number of objects, with various fields. Some of these fields are values of basic types (integer fields such as 27, character fields such as 'Z' and so on); others are references, some void, others attached to objects. Each object is an instance of some type, always based on a class and indicated below the object in the figure. Some types may be represented by just one instance, but more commonly there will be many instances of a given type; here TYPE1 has two instances, the others only one. An object may have reference fields only; this is the case here with the TYPE4 instance, or basic fields only, as with the TYPE5 instance. There may be self-references: direct, as with the top field of the TYPE2 instance, or indirect, as with the clock-wise reference cycle starting from and coming back to the TYPE1 instance at the top. This kind of structure may look unduly complicated at first — an impression reinforced by the last figure, which is meant to show many of the available facilities and does not purport to model any real system. The expression “spaghetti bowl” comes to mind. But this impression is not justified. The concern for simplicity applies to the software text and not necessarily to the run-time object structure. The text of a software system embodies certain relations (such as “is child of ”, “loves”, “has as landlord”); a particular run-time object structure embodies what we may call an instance of these relations — how the relations hold between members of a certain set of objects. The relations modeled by the software may be simple even if their instances for a particular set of objects are complex. Someone who considers the basic idea behind the relation “loves” fairly simple might find the instance of the relation for a particular group of people — the record of who loves whom — hopelessly entangled. So it is often impossible to prevent the run-time object structures of our O-O systems from becoming big (involving large numbers of objects) and complex (involving many references with a convoluted structure). A good software development environment will provide tools that help explore object structures for testing and debugging. Such run-time complexity does not have to affect the static picture. We should try to keep the software itself — the set of classes and their relations — as simple as possible. The observation that simple models can have complex instances is in part a reflection on the power of computers. A small software text can describe huge computations; a simple O-O system can at execution time yield millions of objects connected by many references. A cardinal goal of software engineering is to keep the software simple even when its instances are not. 8.2 OBJECTS AS A MODELING TOOL We can use the techniques introduced so far to improve our understanding of the method’s modeling power. It is important in particular two clarify two aspects: the various worlds touched by software development; and the relationship of our software to external reality
$8.2 OBJECTS AS A MODELING TOOL 229 The four worlds of software development From the preceding discussions it appears that when talking about object-oriented software development we should distinguish between four separate worlds: The modeled system,also known as the external system (as opposed to the software system)and described through object types and their abstract relations A particular instantiation of the extemal system,made of objects between which relations may hold. The software system,made of classes connected by the relations of the object- oriented method (client and inheritance). An object structure,as may exist during the execution of the software system,made of software objects connected through references. The following picture suggests the mappings that exist between these worlds. Molds and MOLD INSTANCE their instances Abstract Model ABSTRACT Data Object Type CONCRETE Class (Software) Object Implements Is an instance of On both the software level (lower part of the picture)and the external level (higher part)it is important to distinguish between the general notions (classes and abstract relations,appearing on the left)and their specific instances(objects and relation instances, appearing on the right).This point has already been emphasized in the previous chapter's discussion of the comparative role of classes and objects.It also applies to relations:we must distinguish between the abstract relation loved one and the set of loved one links that exist between the elements of a certain set of objects. This distinction is emphasized neither by the standard mathematical definitions of relations nor,in the software field,by the theory of relational databases.Limiting ourselves to binary relations,a relation is defined in both mathematics and relational databases as a set of pairs,all of the form<x,y>where every x is a member a given set TX
§8.2 OBJECTS AS A MODELING TOOL 229 The four worlds of software development From the preceding discussions it appears that when talking about object-oriented software development we should distinguish between four separate worlds: • The modeled system, also known as the external system (as opposed to the software system) and described through object types and their abstract relations. • A particular instantiation of the external system, made of objects between which relations may hold. • The software system, made of classes connected by the relations of the objectoriented method (client and inheritance). • An object structure, as may exist during the execution of the software system, made of software objects connected through references. The following picture suggests the mappings that exist between these worlds. On both the software level (lower part of the picture) and the external level (higher part) it is important to distinguish between the general notions (classes and abstract relations, appearing on the left) and their specific instances (objects and relation instances, appearing on the right). This point has already been emphasized in the previous chapter’s discussion of the comparative role of classes and objects. It also applies to relations: we must distinguish between the abstract relation loved_one and the set of loved_one links that exist between the elements of a certain set of objects. This distinction is emphasized neither by the standard mathematical definitions of relations nor, in the software field, by the theory of relational databases. Limiting ourselves to binary relations, a relation is defined in both mathematics and relational databases as a set of pairs, all of the form <x, y> where every x is a member a given set TX Molds and their instances MOLD INSTANCE ABSTRACT CONCRETE Abstract Data Type Model Object Class (Software) Object Implements Is an instance of
230 THE RUN-TIME STRUCTURE:OBJECTS $8.2 and every y is a member of a given set TY.(In software terminology:all x are of type TY and ally are oftype Ty.)Appropriate as such definitions may be mathematically,they are not satisfactory for system modeling,as they fail to make the distinction between an abstract relation and one of its particular instances.For system modeling,if not for mathematics and relational databases,the loves relation has its own general and abstract properties,quite independent of the record of who loves whom in a particular group of people at a particular time. This discussion will be extended in a later chapter when we look at transformations on "The abstraction both abstract and concrete objects and give a name to the vertical arrows of the preceding function”,page376. figure:the abstraction function. Reality:a cousin twice removed You may have noted how the above discussion(and previous ones on neighboring topics) stayed clear of any reference to the "real world".Instead,the expression used above in reference to what the software represents is simply "the modeled system". This distinction is not commonly made.Many of the discussions in information modeling talk about"modeling the real world",and similar expressions abound in books about O-O analysis.So we should take a moment to reflect on this notion.Talking about the "reality"behind a software system is deceptive for at least four reasons. First,reality is in the eyes of the beholder.Without being accused of undue chauvinism for his profession,a software engineer may with some justification ask his customers why their systems are more real than his.Take a program that performs mathematical computations -proving the four-color conjecture in graph theory, integrating some differential equations,or solving geometrical problems in a four- dimensional Riemann surface.Are we,the software developers,to quarrel with our mathematician friends (and customers)as to whose artefacts are more real:a piece of software written in some programming language,or a complete subspace with negative curvature? Second,the notion of real world collapses in the not infrequent case of software that solves software problems-reflexive applications,as they are sometimes called.Take a C compiler written in Pascal.The "real"objects that it processes are C programs.Why should we consider these programs more real than the compiler itself?The same observation applies to other systems handling objects that only exist in a computer:an editor,a CASE tool,even a document processing system (since the documents it manipulates are computer objects,the printed version being only their final form) The third reason is a generalization of the second.In the early days of computers,it See also“DISCUS may have been legitimate to think of software systems as being superimposed on a pre- SMON”,20.6pge existing,independent reality.But today the computers and their software are more and 693 on the dangers of staying too close more a part of that reality.Like a quantum physicist finding himself unable to separate the to reality. measure from the measurement,we can seldom treat"the real world"and "the software" as independent entities.The MIS field(Management Information Systems,that is to say, business data processing)provides some of the most vivid evidence:although it may have
230 THE RUN-TIME STRUCTURE: OBJECTS §8.2 and every y is a member of a given set TY. (In software terminology: all x are of type TX and all y are of type TY.) Appropriate as such definitions may be mathematically, they are not satisfactory for system modeling, as they fail to make the distinction between an abstract relation and one of its particular instances. For system modeling, if not for mathematics and relational databases, the loves relation has its own general and abstract properties, quite independent of the record of who loves whom in a particular group of people at a particular time. This discussion will be extended in a later chapter when we look at transformations on both abstract and concrete objects and give a name to the vertical arrows of the preceding figure: the abstraction function. Reality: a cousin twice removed You may have noted how the above discussion (and previous ones on neighboring topics) stayed clear of any reference to the “real world”. Instead, the expression used above in reference to what the software represents is simply “the modeled system”. This distinction is not commonly made. Many of the discussions in information modeling talk about “modeling the real world”, and similar expressions abound in books about O-O analysis. So we should take a moment to reflect on this notion. Talking about the “reality” behind a software system is deceptive for at least four reasons. First, reality is in the eyes of the beholder. Without being accused of undue chauvinism for his profession, a software engineer may with some justification ask his customers why their systems are more real than his. Take a program that performs mathematical computations — proving the four-color conjecture in graph theory, integrating some differential equations, or solving geometrical problems in a fourdimensional Riemann surface. Are we, the software developers, to quarrel with our mathematician friends (and customers) as to whose artefacts are more real: a piece of software written in some programming language, or a complete subspace with negative curvature? Second, the notion of real world collapses in the not infrequent case of software that solves software problems — reflexive applications, as they are sometimes called. Take a C compiler written in Pascal. The “real” objects that it processes are C programs. Why should we consider these programs more real than the compiler itself? The same observation applies to other systems handling objects that only exist in a computer: an editor, a CASE tool, even a document processing system (since the documents it manipulates are computer objects, the printed version being only their final form). The third reason is a generalization of the second. In the early days of computers, it may have been legitimate to think of software systems as being superimposed on a preexisting, independent reality. But today the computers and their software are more and more a part of that reality. Like a quantum physicist finding himself unable to separate the measure from the measurement, we can seldom treat “the real world” and “the software” as independent entities. The MIS field (Management Information Systems, that is to say, business data processing) provides some of the most vivid evidence: although it may have “The abstraction function”, page 376. See also “DISCUSSION”, 20.6, page 693 on the dangers of staying too close to reality
$8.3 MANIPULATING OBJECTS AND REFERENCES 231 been the case with the first MIS applications,a few decades ago,that companies introduced computers and the associated software simply with the aim of automating existing procedures,the situation today is radically different,as many existing procedures already involve computers and their software.To describe the operations of a modern bank is to describe mechanisms of which software is a fundamental component.The same is true of most other application areas;many of the activities of physicists and other natural scientists,for example,rely on computers and software not as auxiliary tools but as a fundamental part of the operational process.One may reflect here about the expression"virtual reality",and its implication that what software produces is no less real than what comes from the outside world.In all such cases the software is not disjoint from the reality,as if we had a feedback loop in which operating the software injects some new and important inputs into the model. The last reason is even more fundamental.A software system is not a model of reality;it is at best a model of a model of some part of some reality.A hospital's patient monitoring system is not a model of the hospital,but the implementation of someone's view of how certain aspects of the hospital management should be handled-a model of a model of a subset of the hospital's reality.An astronomy program is not a model of the universe;it is a software model of someone's model of some properties of some part of the universe.A financial information system is not a model of the stock exchange;it is a software transposition of a model devised by a certain company to describe those aspects of the stock exchange which are relevant to the company's goals. See "BEYOND The general theme of the object-oriented method,abstract data types,helps SOFTWARE”,6.6. understand why we do not need to delude ourselves with the flattering but illusory notion page 147. that we deal with the real world.The first step to object orientation,as expressed by the ADT theory,is to toss out reality in favor of something less grandiose but more palatable: a set of abstractions characterized by the operations available to clients,and their formal properties.(This gave the ADT modeler's motto-tell me not what you are but what you have.)Never do we make any pretense that these are the only possible operations and properties:we choose the ones that serve our purposes of the moment,and reject the others.To model is to discard. To a software system,the reality that it addresses is,at best,a cousin twice removed. 8.3 MANIPULATING OBJECTS AND REFERENCES Let us come back to more mundane matters and see how our software systems are going to deal with objects so as to create and use flexible data structures. Dynamic creation and reattachment What the description of the run-time object structure has not yet shown is the highly dynamic nature of a true object-oriented model.As opposed to static and stack-oriented policies of object management,illustrated at the programming language level by Fortran and Pascal respectively,the policy in a proper O-O environment is to let systems create
§8.3 MANIPULATING OBJECTS AND REFERENCES 231 been the case with the first MIS applications, a few decades ago, that companies introduced computers and the associated software simply with the aim of automating existing procedures, the situation today is radically different, as many existing procedures already involve computers and their software. To describe the operations of a modern bank is to describe mechanisms of which software is a fundamental component. The same is true of most other application areas; many of the activities of physicists and other natural scientists, for example, rely on computers and software not as auxiliary tools but as a fundamental part of the operational process. One may reflect here about the expression “virtual reality”, and its implication that what software produces is no less real than what comes from the outside world. In all such cases the software is not disjoint from the reality, as if we had a feedback loop in which operating the software injects some new and important inputs into the model. The last reason is even more fundamental. A software system is not a model of reality; it is at best a model of a model of some part of some reality. A hospital’s patient monitoring system is not a model of the hospital, but the implementation of someone’s view of how certain aspects of the hospital management should be handled — a model of a model of a subset of the hospital’s reality. An astronomy program is not a model of the universe; it is a software model of someone’s model of some properties of some part of the universe. A financial information system is not a model of the stock exchange; it is a software transposition of a model devised by a certain company to describe those aspects of the stock exchange which are relevant to the company’s goals. The general theme of the object-oriented method, abstract data types, helps understand why we do not need to delude ourselves with the flattering but illusory notion that we deal with the real world. The first step to object orientation, as expressed by the ADT theory, is to toss out reality in favor of something less grandiose but more palatable: a set of abstractions characterized by the operations available to clients, and their formal properties. (This gave the ADT modeler’s motto — tell me not what you are but what you have.) Never do we make any pretense that these are the only possible operations and properties: we choose the ones that serve our purposes of the moment, and reject the others. To model is to discard. To a software system, the reality that it addresses is, at best, a cousin twice removed. 8.3 MANIPULATING OBJECTS AND REFERENCES Let us come back to more mundane matters and see how our software systems are going to deal with objects so as to create and use flexible data structures. Dynamic creation and reattachment What the description of the run-time object structure has not yet shown is the highly dynamic nature of a true object-oriented model. As opposed to static and stack-oriented policies of object management, illustrated at the programming language level by Fortran and Pascal respectively, the policy in a proper O-O environment is to let systems create See “BEYOND SOFTWARE”, 6.6, page 147