Principles of object oriented modeling

\oopindex{modeling} The philosophy of design underlying object oriented software development centers around abstraction and information hiding. Objects, encapsulating state and behavior, support these notions. Moreover, objects provide a natural means to model a problem since the objects in a system may bear a close correspondence to the entities encountered in reality. As phrased in  [Booch86], each module in the system denotes an object or a class of objects from the problem space. As a design method, the approaches treated in  [Booch91] and  [WWW90] have in common an emphasis on the identification of the objects that play a role in the system and on delineating the functionality of these objects, that is to assess what services are provided and how the objects interact in order to provide these services. A very succinct formulation of such a basic design method is given in  [BC89], where the notion of CRC-cards is introduced. CRC stands for Class, Responsibility and Collaborators. The authors argue that design is greatly facilitated by using these cards that contain for each object (class) its name, its responsibilities, which are the operations it supports, and its collaborators, the objects/classes it has to interact with to fulfill its responsibilities. Clearly, of a design method, as opposed to a programming language, we require to be able to characterize objects and their possible interactions with other objects in an abstract way, ignoring implementation dependent details. However, since objects are the major organizing principle both in object oriented programming and design, the distinction between design and implementation lies in the degree that abstraction and conceptual clarity is supported. For developing a design method, the central question is what we consider to be objects and what means must (minimally) be provided to characterize the functionality of objects and their interactions with other objects.

Objects

 [Booch86] characterizes objects as (clearly identifiable) entities that suffer and require actions. Operationally, an object may be defined as to comprise a state and behavior. The actions an object suffers may be requests to give information on its state or may demand to change the state of the object. To provide a service an object may need to issue such requests to other objects. In an object oriented system, computation amounts to sending messages among objects.  [Booch86] identifies the roles that objects may play in such a system. An object may be an actor that operates by sending requests to other objects but provides no services. An object may be a server that may be requested to perform some task. The most usual case, however, is that an object both suffers and requires actions. These objects, called agents in  [Booch86], need as well as provide services.\ftn{ With regard to the distinctions made, we may want to rephrase the design guideline {\it "minimize and localize dependencies among objects"} as a recommendation to maximize the number of actors and servers in a system, under the proviso that no more objects are introduced than necessary. } As concerns the operations of an object or methods as they are commonly called, a distinction can be made between methods to create and initialize an object (constructors), methods to dispose of an object (destructors), methods to change the state of an object (modifiers), methods to evaluate the current state (selectors) and methods to visit parts of the object (iterators). In a design document, the description of an object will usually not contain a precise characterization of its constructor and destructor methods. However, when objects have own activity the constructor characterize this activity or may lay down the protocol for interaction with other objects. In these cases, I think, the description of the constructor enhances a conceptual understanding of the functionality of the object.

Inheritance

There is some debate whether inheritance is to be considered an integral part of an object oriented development method. C.f.  [Booch86]. I share the view expressed in e.g.  [HOB87] that inheritance is of major importance in the design and implementation of object oriented systems as a means to suppress the complexity of a large collection of object descriptions by means of a hierarchical organization of the objects according to their functionality. Moreover, inheritance is of essential importance for the effective reuse of software. C.f.  [Meyer88] and  [WWW90]. In object oriented design, inheritance comes down to sharing specifications of behavioral properties of objects.\ftn{ In object oriented programming languages inheritance by code sharing has proven to be a very powerful mechanism. As a design guideline, it may be advised to use inheritance strictly for the specification of conceptual hierarchies. In a typed setting, such an advice could be enforced by allowing the use of inheritance to create subtypes only, although in practice this would be very restrictive. In an untyped setting such restrictions cannot be enforced. C.f.  [WZ88]. } Describing objects and characterizing their structural relations by means of inheritance are the two major components of an object oriented design methodology. Objects provide a mechanism to abstract from the details of how a service is provided. To make use of a service, it suffices to know what services an object offers and what messages must be sent to request for that service. Inheritance provides a means to to create a hierarchy of objects and to separate the stable conceptual issues from more specific volatile details.