A Diagram For Object-Oriented Programs

A Diagram for Object-Oriented ProgramsWard CunninghamKent BeckComputer Research LaboratoryTektronix, Inc.AbstractWe introduce a notation for diagramming themessage sending dialogue that lakes place betweenobjects participating in an object- orientedcomputation. Our representation takes a global pointof view which emphasizes the collaboration betweenobjects implementing the behavior of individuals.We illustrate the diagram's usage with examplesdrawn from the Smalltalk-80TM virtual image. Wealso describe a mechanism for automatic constructionof diagrams from Smalltalk code.1. IntroductionThe Smantalk-80 virtual image [Goldberg 83] hasmany examples of expertly organized programs,many of which play an important role in theSmalltalk-80 system. These are worthy objects ofstudy for at least two reasons. First, they oftenprovide exquisite examples of the style and idiomunique to object-oriented programming. As valuableas a concise definition of object-orientedprogramming might be, it could not replace thecorpus of code in the virtual image for illuminatingthe range of application of the object-oriented style.Students of object-oriented programming should begrateful that the implementors of SmaUtalk pushedthe object metaphor to the limit, building their systemout of nothing but objects. Their result offers a guideto the "objectification" of even the most elusivealgorithms. One learns by doing and one doesSmalltalk by browsing the work of otherprogrammers. Second, many Smalltalk objects aredirectly reusable--an even more compelling reasonto study their behavior. To the degree that one'sapplication mimics Smalltalk's own implementation,one will find useful objects in the image,preprogrammed, waiting to be used. Smalltalk'sreputation as a user-interface-prototypingenvironment stems from its wealth of reusableuser-interface components.We sought a way of presenting the computationsemployed in Smalltalk's modular user interface. Wedeveloped a representation, a diagram, thatemphasised the object nature of the interfacecomponents. The essence of an object-orientedcomputation is the dialog carried out by the objectsinvolved. With this in mind, we consciously omittedfrom the diagram indications of state or sequence. Soreduced, a single diagram shows the cascade ofmessages that result, for example, from a userinteraction. The diagrams are not unique touser-interface codes, though, they are unique toobject-oriented computations. We have since appliedthe diagramming technique to many of the moreesoteric examples from the Smalltalk-80 image. Theresult has solidified our own understanding ofobject-oriented programming, and enabled us toteach others more clearly about Smalltalk-80.the ACM copyright notice and the title of the publication and its date appear,and notice is given that copying is by permission of the Association forComputing Machinery. To copy otherwise, or to republish, requires a fee and/or specific ix.rmimion.In this paper we will introduce the notations of ourdiagramming technique and apply them to severalexamples from the Smalltalk-80 image. I aterexamples are drawn from behaviors in the image thatare often misunderstood. We hope in this way tomake a convincing demonstration of the diagrams'usefulness. Also, the reader can expect to seeglimpses of the unique suitability of objects inimplementing user-interfaces. We close with adiscussion of an automatic technique for theconstruction and formatting of publication qualitydiagrams. 1986 ACM 0-89791-204-7/86/0900-0361Smalltalk-80 is a n'ademark o f the Xerox Corp. PostScript isa trademark o f A d o b e S y s t e m s , Inc.Permission to copy without fee all or part of this material is granted providedthat the copies are not made or distributed for direct commercial advantage,S 198675 OOPSLA'86 Proceedings361

. :. .,. .i alp" hWe begin with objects. Objects accept responsibilityfor their own behavior. As a convenience, the codethat implements this behavior is collected into acommon place for all objects of the same class.Further, objects of one class might vary in behavioronly slightly from those of another class. A new classis said to refine another if it implements ouly thevariant behavior while relying on the other class forthe remainder.(lb)ii :i"Figure 1. a) An object receiving a message, b) Anobject sending a message to another object.An object will exhibit behavior appropriate for thespecific message it receives. The variouscomputations are implemented by distinct methods,each labeled with a method selector. We place theselector of methods invoked by messages at thereceiving end of a message arc (See figure 2a.) It isimportant to note that the method invoked by amessage will depend on the selector and the receivingobject. The same selector might select differentmethods when received by different objects. InFigure 2b, for example, we cannot tell whether thetwo methods labeled "gamma" are the same. We needto know more about the objects involved.362:'"betaWe represent an object as a box (See figure la.) Amessage sent to an object excites behavior specific tothat object. We draw a message-send as a directed arelanding within the receiving object. If more than oneobject participates in a computation then there will bemore than one box in the diagram (See figure lb.)When one object invokes a computation in anotherobject through a message send, we show that send asan arc originating in the sending object and landing inthe receiving object. With the message goes atransfer of control. That is, the computation of thesender is suspended until the computation of thereceiver is completed. Control returns backwardalong a message arc along with the answer to themessage, if any. So far this mimics the usualsemantics of procedure call. Note that we draw aparticular message are only once, even if the messageis sent repeatedly, in a loop or otherwise.(la)(2b)(2a)2. The Diagram!igain" m g ilnlll,'lFigure 2. a) One method for "alpha" invokes anotherfor "beta". b) One method for "gamma" invokesanother for "gamma".We identify an object in a diagram by its class. Recallthat all members of a class share the same methods.The methods of the objects in Figure 3 are all exactlydetermined because we know the selector and thereceiver's class for all of the messages. Recall alsothat objects of one class might inherit methods fromanother class. When methods are inherited fromother classes (when a class does not implement amethod, but one of its superclasses does) we dividethe receiver into layers representing the classesinvolved and locate the method selector in theappropriate layer. Figure 3b shows two objects oftwo different classes (Senator and Plebe) eachrefining a third class (Citizen). The method for"gamma" invoked by each is in fact the same method,the one both inherit from Citizen. Of course, thesame method won't necessarily execute in the sameway in both cases; it is being executed on behalf ofdistinctly different objects. Figure 3c shows arevised Plebe. This time Plebes provide their ownmethod for "gamma" which overrides the defaultimplementation inherited by all Citizens.We draw message arcs so that they always enter anobject from above. When an are travels across alayer of methods before finding its selector in adeeper layer, this suggests an opportunity to overridethat has not been exploited. The top layer will be thatof the object's own class. Deeper layers will besuperclasses. The bottom layer (if shown) will be theroot of the hierarchy- class Object.Note the contradictory use of the "elevation"methaphor by the terms "override" and "superclass".Which way is up? Some observers have complainedthat it is non-intuitive to place subclasses abovesuperclasses in our characterizations of objects. Wejudge overriding the more important concept and liketo think of method-lookup searching deeper for animplementation if none is provided by the surfaceclass. Besides, we tried drawing the diagramsupside-down. They looked lifeless with their arcslimply dangling between method selectors.OOPSLA '86 ProceedingsSeptember 1986

Oa)Senator(3b). iOc)Senator, . alpha,,.Ji!.7 f : --ICitizen t ISenator i .g ('J1g Citizen '. ." !: ":'{" ' ! . ,%.Plebe ' "" '" gamma.Figure 3. a) A Senator's method for "alpha" invokes a Plebe's method for "beta". b) ASenator's method for "gamma" invokes a Plebe's method for "gamma", in this case thesame method inherited by all Citizens. c) A variant of b) where a Plebe overrides theinherited implementation of "gamma".Consider an example drawn from the Smalltalk-80image. The class Collection includes refmements formany commonly used aggregate data structuresarrays, sets, linked lists and the like. AnOrderedCollection, for example, implements aflexibly sized array. An OrderedCollection respondsto the message "add: anElement" by addinganElement at the next available location within itself.A slightly simplified diagram of this operationappears in Figure 4a. We can see that the add methodmakes use of two more elementary methods, size andat:put:. The diagram doesn't exactly explain why, butone could guess that size is used to determine whereto put the new element and at:put: is used to put itthere. Contrast this to the implementation of add: forSets in figure 4b. This time the index is found byhashing the new element. Note that computing a hashfunction is the responsibility of the new element, notof the Set. All objects can hash themselves. Points,for example, compute their hash from their componentx and y coordinates as illustrated in figure 4c.We have now seen two examples of recursivebehavior. In figure 3b the "gamma" method for oneCitizen invoked itself for another. This style ofrecursion is common in Smalltalk especially when theobjects are organized into a tree or list. In figure 4awe see a distinctly different kind of self reference.One method (add:) invokes others (size and at:put:)on behalf of the same object. This is done byaddressing messages to "self'. This is an idiom inSmaUtalk since it is the mechanism by which complexmethods are decomposed into simpler ones. Figure 5illustrates some particularly interesting variations onthis theme. The method "addAll:" works by addingeach element of another Collection, one at a time.The algorithm works for all refinements thatimplement an appropriate method for "add:". Wedraw messages to self as arcs arching up and backdown through the refining layers of an object,emphasizing the ref'mement's opportunity tooverride.il.SeL a?d . . .,.,.i /Collectioni at:put: Collection1.;I:Put: [PointhashIhasInteger hash.3.:i.Figure 4. a) Adding to an OrderedCollection. b) Adding to a Set. c) Hashing a Point.Sep(ember 1986OOPSLA '86 Proceedin0s363