List of Figures

Chapter 1: Object Thinking

Figure 1-1: A graphical object model using UML graphical syntax.

Figure 1-2: A person as visual metaphor of an object.

Figure 1-3: Customer depictions.

Figure 1-4: Difference continuum.

Figure 1-5: A partial completed CRC card for an airplane.

Chapter 2: Philosophical Context

Figure 2-1: Domain-reflective customer model (partial).

Figure 2-2: Relational customer model (partial).

Figure 2-3: A graphical representation of one aspect of an object: its behaviors or responsibilities.

Figure 2-4: A graphical model of objects communicating (interacting) with one another.

Chapter 3: From Philosophy to Culture

Figure 3-1: Program structure chart.

Figure 3-2: Applicability graph.

Chapter 5: Vocabulary: Words to Think With

Figure 5-1: Three popular graphical object models: soccer ball, animated data entity, and CRC card (left to right).

Figure 5-2: A value holder, a simple two-dimensional array with the contents of the first column restricted to labels and the contents of the second restricted to data objects such as strings, numbers , dates, and characters .

Figure 5-3: A Dispatcher object. Events to be dispatched are located in the first column, whereas the second column is a queue of event registration requests .

Figure 5-4: A registration request consists of a simple dyadwho is to be notified (an object) and the means of notification (a message).

Figure 5-5: Inheritance tree fragment, showing both single and multiple inheritance.

Figure 5-6: Hectors rough sketch of the objects the group is talking about, which he has made so that he has something to point to while telling the stories.

Chapter 6: Method, Process, and Models

Figure 6-1: In this Department of Motor Vehicles example ( patterned after Coad and Yourdon, 1991), data modeling rules lead the designer to place the fee attribute and therefore the calculate fee method in the LegalDocument class. This mandates the need for a case statement to handle fee calculations and couples LegalDocument to the entire Vehicle class hierarchy.

Figure 6-2: In this example, the addition of a single new attribute requires the creation of a new class, allowing some customers to buy on credit and therefore have a creditLimit attribute, for example.

Figure 6-3: A semantic net, a brainstorming tool for discovery of potential objects in a domain.

Figure 6-4: Semantic net for the LIMT example.

Figure 6-5: The classic CRC card view of an object (LIMT example).

Figure 6-6: Object description and stereotype (LIMT example).

Figure 6-7: Contracts: categories of methods or responsibilities (LIMT example).

Figure 6-8: Knowledge required by an object (LIMT example).

Figure 6-9: Message protocol.

Figure 6-10: Events generated by an object.

Figure 6-11: In this set of symbols from an interaction diagram, symbols whose labels appear in italics are additions to standard UML.

Figure 6-12: This interaction diagram illustrates the conversation required to fill in and validate a mortgage application.

Figure 6-13: Text-only equivalent of the previously modeled interaction diagram.

Figure 6-14: This text-only binary use case model captures the same information as a top-level use case diagram.

Figure 6-15: A class hierarchy diagram showing single inheritance only.

Figure 6-16: A gestalt map provides an overview of the objects and their static relationships.

Figure 6-17: A collective memory map, a static view of the data in a system.

Figure 6-18: The most commonly used symbols borrowed from Harel.

Chapter 7: Discovery

Figure 7-1: A partial semantic net for a subsidized mortgage company.

Figure 7-2: A UML-style, top-level (analogous to a context diagram) partial use case.

Figure 7-3: In this system request table, the service requester is identified at the top. ( NewSystem is assumed to be the service provider.) Each line identifies the service requested : the message sent to NewSystem , the object returned as a result of that request, and notes for explanations if needed. Each line of the table constitutes a precondition/postcondition for a conversation.

Figure 7-4: In this conversation table, preconditions and postconditions are noted at the top of table. Each line of the table shows who is making a request, the nature of the request (message), the service provider, the object returned, and a comment if necessary. The conversational order is assumed to be top down.

Figure 7-5: This interaction diagram depicts the user -driven conversation required to fill in a form.

Figure 7-6: This interaction diagram depicts the alternative scenario for filling in an application.

Figure 7-7: Side 2 of the object cube for the Application and entryField objects contains a simple record of the description and stereotype obtained from the domain expert (user).

Figure 7-8: Sides 1 and 2 of the Application and entryField object cubes. "(Indented lines on side 1 of Class: Application are collaborators for the immediately preceeding responsibility.)"

Figure 7-9: Objects identified in the subsidized mortgage example (side 1 of the object cubes).

Figure 7-10: Objects identified in the subsidized mortgage example (side 2 of the object cubes).

Figure 7-11: Side 1 for airplane, location, instrumentCluster , and instrument objects.

Figure 7-12: Object communications required for an airplane to tell the control tower where it is currently located.

Chapter 8: Thinking Toward Design

Figure 8-1: Sides 1 and 4 of the Airplane object cube, showing the relationship between responsibilities and knowledge required.

Figure 8-2: Sides 1 and 4 of the objects (classes) introduced in the ATC example from the preceding chapter.

Figure 8-3: Object classes from the mortgage trust application introduced in the preceding chapter.

Figure 8-4: Knowledge required for objects and responsibilities identified for the mortgage trust application introduced in the preceding chapter.

Figure 8-5: Sides 1 and 5 of the objects in the ATC example introduced in the preceding chapter.

Figure 8-6: Responsibilities for the objects in the mortgage trust application (object cube side 1).

Figure 8-7: Message protocol for the objects in the mortgage trust application (object cube side 5).

Figure 8-8: Contracts for all classes in both the ATC and mortgage trust application examples (object cube side 3).

Figure 8-9: Events for objects in the ATC and mortgage trust examples (object cube side 6). Note that most objects have no events. In some cases this is because they are inherited (MortgageApplication from Form), but usually it just reflects that most objects are not willing to share much state information, except for the almost universal "changed" state inherited from class Object).

Figure 8-10: An event dispatcher table and an event registration tuple.

Chapter 9: All the Worlds a Stage

Figure 9-1: The is-a- kind-of relationships among the objects (via their classes) in the mortgage trust example.

Figure 9-2: A visual model of collaborations, based on a graph in Designing Object Oriented Software, by Wirfs-Brock et al., 1991.

Figure 9-3: A semantic net fragment, showing a constraining relationship among objects in a domain.

Figure 9-4: SRM depiction of the classes and relationship in the mortgage trust example.

Figure 9-5: Relationships among airplane, blip, and airspace.

Figure 9-6: Relationships among objects occupying instance variables of other objects in the airplane, blip, and airspace example.

Figure 9-7: A collective memory map for the mortgage trust example.

Figure 9-8: The proper organization (architecture) of a program consistent with structured development ideas.

Figure 9-9: A structure depicting how actual source code might reflect the hierarchical control architecture.

Figure 9-10: Objects move along the route provided by the pipes and obtain services from the objects embodying the filters.

Figure 9-11: Elements common to all blackboard systems.

Figure 9-12: Generalized model of the MVC concepts.

Figure 9-13a: Hierarchical composition of a complex view.

Figure 9-13b: The application completion screen in the mortgage trust example is a hierarchically organized collection of object views.

Figure 9-14: The composite object, Customer , might use a composite dispatcher instead of each object using its own dispatcher.

Figure 9-15: The diagram on the left has labels reflecting domain vocabulary. The one on the right is the identical conversation with labels reflecting implementation vocabulary.

Figure 9-16a: The original story that, whenever it looks as though a lot is going to happen, is factored with a placeholder for a substory inserted.

Figure 9-16b: Substory: Entry field obtains and validates contents.

Figure 9-16c: Substory: Application form validates self.

Figure 9-17: State change notification is always a message to oneself, never to other objects. A state change can trigger multiple messages to other objects, reflecting the contents of the event dispatcher, as shown in the diagram on the left.

Figure 9-18: This Harel state chart depicts a mouse and its composite parts plus a fragment of a mouse manager.

Figure 9-19: Partial charts for application and entry field, from the mortgage trust example.

Figure 9-20: Sample rules with identification of element types.

Figure 9-21: Object cube representation of the DataItem class.

Chapter 10: Wrapping Up

Figure 10-1: Composable document framework.

Figure 10-2: Object routing and tracking framework.

Figure 10-3: Resource allocation and scheduling framework.

Figure 10-4: Thangka painting.