eberard@ajpo.sei.cmu.edu (Edward Berard) (11/21/89)
PROLOGUE Before I begin a discussion of object-oriented design (OOD), I must provide you with some "truth in advertising." For most of the article, I will refer to OOD as if it were a separate, _contiguous_ life-cycle phase. In reality, it is more appropriately handled in a recursive/parallel life-cycle approach, i.e., "analyze a little, design a little, implement a little, and test a little." In short, one may accomplish OOD at many different points in the development part of the life-cycle. I must also point out where OOD might fit in a more conventional (e.g., waterfall) life-cycle. Analysis (or requirements analysis) defines both the client's needs and a proposed solution to the client's problem. Object-oriented requirements analysis (OORA) accomplishes this in an object-oriented manner. Design, traditionally, is the phase of the life-cycle in which the internal architecture of the system (e.g., the module definitions and their interconnections) is accomplished. Design usually occurs before coding takes place. We will adopt this viewpoint. In essence we will assume that an OORA effort has occurred before we begin our OOD, and we will also assume that some form of coding (i.e., object-oriented programming (OOP)) will follow the OOD process. In the recursive/parallel life-cycle these distinctions become somewhat blurred, but the general flavor is preserved. The "good news" is that OOD and OORA are consistent in their thinking than are, say, structured analysis and structured design. The "bad news" is that this higher level of consistency makes it harder to differentiate between the two. If you were to study the state of the art in both OORA and OOD, however, you would notice several things, including: - Although there is a good deal of overlap, there are differences between the graphics for OOD and OORA. For example, OOD includes graphics for program units, whereas OORA does not. - Programming language issues can generally be avoided in OORA, whereas they must be specifically addressed in OOD. - There is high client visibility during OORA, and low client visibility during OOD. - Not all objects identified during analysis would become code software. Those objects which were used only to describe the context duing analysis, but do not become code software are often referred to as "analysis objects." - New objects (i.e., objects which were never mentioned previously) may be introduced in the OOD process. We call such objects "design objects." - The larger the overall project, the higher the ratio of design objects to analysis objects. (OORA does _not_ uncover all system objects, except for extremely simple (small) examples.) HISTORY While the significant history of object-oriented technology in general dates from at least 1966, the history of object-oriented design is much more recent. The object-oriented programming (OOP) crowd did not pay much attention to design issues until very recently. (See, for example, [Beck and Cunningham, 1989], [Rosson and Gold, 1989], and [Wirfs-Brock and Wilkerson, 1989].) As it turns out, most of the significant work, to date, in OOD has occurred in the Ada community. In the summer of 1979, the first preliminary Ada language reference manual became available. The U.S. Department of Defense (DoD) began to seek people who could provide Ada training. One of the places they went to was the U.S. Air Force Academy (USAFA) in Colorado Springs, Colorado. Major Dick Bolz, USAF and (then) Lt. Grady Booch, USAF were given the task of developing a DoD-wide Ada training course. In January of 1980, Booch attended an Association for Computing Machinery (ACM) symposium in Boston, Massachusetts on Ada. There was a very clear message delivered at the conference: "the main thrust of any Ada training must be software engineering, i.e., language syntax and semantics are there to support specific, and important, software engineering concepts." Booch then set out to find some mechanism for introducing software engineering into the Ada training efforts. He identified the work of Russell J. Abbott at California State University as being relevant (e.g., [Abbott, 1983]). Abbott had described a simple approach to design using nouns and verbs. Booch slightly formalized Abbotts approach, and referred to it as "object-oriented design" (see, e.g., [Booch, 1981] and [Booch, 1982]). By the time his first book ([Booch, 1983]) was released Booch had a number of working examples. [Note: Many people did not understand Booch's intentions. They thought, for example, that OOD _always_ required that one write a paragraph, and then underline nouns and verbs. Booch viewed the paragraph as a "crutch," i.e., one technique out of many which could help identify and define objects.] By 1982, I had begun to develop some Ada training courses. These courses included simple object-oriented design exercises. Later, in 1984, I wrote a 300-page "Handbook for Object-Oriented Design for Ada Software." By late 1985, both Booch and myself had begun to actively incorporate more classic object-oriented thinking (e.g., Smalltalk concepts) into our courses, consulting, and articles. In February of 1986, Booch wrote an article ([Booch, 1986]) describing his revised (more correctly: evolving) thinking on object-oriented approaches. Realizing that object-oriented thinking is not limited to design and coding, Booch began to refer to his approach as "object-oriented _development_." By 1986, other ideas of how to approach object-oriented design began to emerge. Ed Seidewitz and Mike Stark at NASA Goddard introduced what they referred to as "general object-oriented development" (GOOD). (See, e.g., [Seidewitz and Stark, 1986] and [Stark and Seidewitz, 1987].) CiSi (in France) began talking about their "hierarchical object-oriented design" (HOOD) method ([Heitz, 1988], [Heitz and Labreuille, 1988], and [Vielcanet, 1989]). Some folks at the Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania (phone: (412) 268-7700) presented their views ([Lee et al, 1987]). Ken Shumate, then at Hughes, introduced what he called "layered virtual machine/object-oriented design" (LVM/OOD) -- see, e.g., [Nielsen and Shumate, 1987] and [Shumate, 1988]. [Note: There are many schools of thought on how OOD can be accomplished. Someone believing that there was only one accepted way to accomplish OOD would be as confused as someone who originally thought that there is only one "accepted" way to accomplish OOP, and is visiting their first OOPSLA or ECOOP.] There have also been many attempts to somehow reconcile object-oriented approaches with the more traditional approaches, e.g., [Bulman, 1989], [Colbert, 1989], [Gray, 1987], [Gray, 1988], [Khalsa, 1989], [Masiero and Germano, 1988], [Ward, 1989], and [Wasserman et al, 1989]. [Experience has shown that simply attempting to integrate object-oriented thinking into the more traditional methodologies (e.g., structured) is a mistake. The major problem is that of localization, i.e., the placing of related items in close physical proximity to each other. Functional approaches, for example, tend to localize information around functions, whereas object-oriented approaches tend to localize information around objects. A functional decomposition "front end" to an object-oriented process, in effect, breaks up objects and scatters their parts. Later, these parts must be retrieved and relocalzed around objects.] Today, most of the attempts at creating an OOD methodology are still to be found in the Ada community. Unfortunately, many of these attempts are only slightly object-oriented, or reflect very old thinking (e.g., [Colbert, 1989]) There are however pleasant (and interesting) exceptions (e.g., [McQuown, 1989]). TRANSITIONING FROM OORA Assuming that one has a large enough project, OORA immediately precedes OOD. OORA will have identified some objects which are necessary for setting the context, but will not become code software. We generally refer to these objects as "analysis objects." There are two other types of objects which will be identified in OORA: - Objects which are part of the "user" interface, where a "user" can be a human, another piece of software, or a piece of hardware. (Remember, that most traditional analysis methodologies stop at the "user interface.") Examples of these objects include windows and read-only ports. - Objects which exist inside the proposed system, but become visible to the outside through the user interface. Examples of these objects include such things as messages in an electronic messaging system, and purchase orders (in a more traditional business application). (OORA may also have identified larger object-oriented entities such as subsystems and systems of objects, but these are the topic of another message.) In OOD, software engineers find themselves just inside of the "black box" for which the OORA analysts have specified the external interface. The job of OOD is to specify the internal architecture of this "black box." This means the OOD process will involve identifying internal (i.e., inside the black box) objects, and specifying their interactions. A MECHANISM FOR ACCOMPLISHING OOD ["Truth in advertising": The method I am about to describe here is a method I currently advocate. It is the result of almost 8 years of continual evolution, and has actually been used to develop large, object-oriented applications. However, not everyone agrees that it is the best approach. C'est la vie. ;-) More "Truth in advertising": Although, I will present the following steps as if they were sequential, some of them may be re-ordered, and some may even be accomplished in parallel.] The first part of the OOD process requires that the software engineer accomplish two different goals: identify the objects of interest, and specify how these objects will effect a solution to the problem. One might say that the software engineer must construct an object-oriented model (strategy) of the proposed solution. The object-oriented model can be accomplished using any one of a number of strategies, e.g.: - writing a paragraph (i.e., the approach originally advocated by Abbott) and identifying the objects from the nouns, pronouns, noun phrases, adjectives, adjectival phrases, adverbs, and adverbial phrases contained therein. - constructing a graphical model using such things as semantic networks, state transition diagrams, Petri net graphs, or any one of the variety of "object-message" diagraming techniques. This approach may be more appealing than "writing a paragraph," but it does require that the designer have some idea of what the objects are before creating the graphic model. - using an automated tool to sketch a solution, e.g., Smalltalk, Trellis, and Prograph. Once the strategy is agreed upon, the objects of interest can be identified. (Here, we extend the concept of object to include large object-oriented entities as well.) The designer should also gather information about each object and localize it with the appropriate object. The next major step requires the designer to identify suffered and required operations for each object. A "suffered" operation is something which happens to a given object, e.g., adding an element to a list, directing an elevator to go up, and querying a temperature sensor as to its current value. A "required" operation is an operation for an object other than the encapsulating object, and is necessary to ensure the correct and desired behavior of the object. For example, if we wish a list object to be ordered, it will require that the items contained in the list furnish a "<" (less than) operation. [Note: It is primarily (but not exclusively) through operations that objects are coupled. Unnecessary object coupling reduces both the reusability and reliability of our objects. The identification and separation of required operations is a means of reducing object coupling.] Operations can be identified directly from the object-oriented model we constructed in the first step (e.g., the verbs and verb phrases in the paragraph), or they may come indirectly from the suggested interactions in the model. In either case, the designer should associate attributes with each operation (suffered and required). During OOD, as during OORA, the software engineer will very likely encounter composite operations. A composite operation is an operation composed of two or more primitive operations. A primitive operation is an operation which cannot be accomplished simply, reliably, and efficiently without knowledge of the underlying implementation of the object. The designer must take care to decompose each composite operation. In the process of decomposing each composite operation, additional primitive operations, or object coupling, may be uncovered. At this point in the OOD process, the designer can begin identifying complete objects. By combining objects and their respective suffered operations, a more complete picture of each object begins to emerge. Several things may happen, i.e.: - The software engineer may recognize an object which is already available in the object library maintained by his or her organization. If this is the case, the library object will be extracted. - The software engineer may recognize that the desired object is a variation on an object currently in the object library. The currently existing object will then be used as the basis for the creation of a new object. - The software engineer may not find any existing object in the object library which closely (or exactly) meets the criteria for the needed object. In this case, a new object specification will be created. In any of the above cases, we must validate that we have chosen, or created, a correct and appropriate object. If we create a new object, or modify an existing object, these objects will have to be tested and quality assured, and then placed in the library (as well as being used for this specific project). [Note: If you are creating specifications for your objects, e.g., Object and Class Specifications (OCSs), these should also be added to the library.] Before any object can be considered usable, it must be examined for completeness. We do not want to have to modify any object (other than supplying parameters) when we reuse it. For example, our immediate application may only require that we add items to a list, but never delete them. If we place an add operation in the interface to the list, but no delete operation, the object is incomplete. It is very important that every object we create (either entirely new, or as a variation on an existing object) be examined for completeness. Completeness entails more than just operations. For example, we may wish to add exportable constants and exceptions to our object definition. The next major step in object the OOD process is deciding on programming language implementations for our objects. This step involves both the objects identified during design, and those identified during analysis. Some programming languages, e.g., Smalltalk, C++, and Trellis, are rather limiting in the way one can implement objects. Other languages, e.g., Ada, provide a variety of options. (Please note: I am _not_ saying "Ada is better than ...") The designer may wish to implement classes, instances, metaclasses, unencapsulated non-primitive operations, metaoperations, and parallel program units, depending on the capabilities furnished by the implementation language of choice. The designer may then wish to show programming language relationships among the objects of interest. By "programming language relationships" I mean, for example, access to capabilities (dependencies), nesting, message sending, and aggregation. These relationships may also be shown graphically, e.g., using the graphics suggested by Booch in his soon-to-be-released book on OOD. The designer may then choose to use the implementation language to precisely define the interfaces among the objects in the system. At this point, we have two main choices available to us: - switch to OOP and implement the internal structures of our objects - If the system is large enough, we may wish to re-apply the object-oriented development process (i.e., "analyze a little, design a little, ...") to the products of our design effort. Of course, there is much more to say. But, hey, this is only a net message.(8-)) Once again, thank you for listening. -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652 FAX: (301) 353-9272 BIBLIOGRAPHY [Abbott, 1983]. R.J. Abbott, "Program Design by Informal English Descriptions," Communications of the ACM, Vol. 26, No. 11, November 1983, pp. 882 - 894. [Beck and Cunningham, 1989]. K. Beck and W. Cunningham, "A Laboratory for Teaching Object Oriented Thinking," OOPSLA '89 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 1 - 6. [Booch, 1981]. G. Booch, "Describing Software Design in Ada," SIGPLAN Notices, Vol. 16, No. 9, September 1981, pp. 42 - 47. [Booch, 1982]. G. Booch, "Object Oriented Design," Ada Letters, Vol. I, No. 3, March- April 1982, pp. 64 - 76. [Booch, 1983]. G. Booch, "Object Oriented Design," IEEE Tutorial on Software Design Techniques, Fourth Edition, P. Freeman and A.I. Wasserman, Editors, IEEE Computer Society Press, IEEE Catalog No. EHO205-5, IEEE-CS Order No. 514, pp. 420 - 436. [Booch, 1986]. G. Booch, "Object Oriented Development," IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 211 - 221. [Boyd, 1987]. S. Boyd, "Object-Oriented Design and PAMELA: A Comparison of Two Design Methods for Ada," Ada Letters, Vol. 7, No. 4, July-August 1987, pp. 68 - 78. [Bulman, 1989]. D.M. Bulman, "An Object-Based Development Model," Computer Language, Vol. 6, No.8, August 1989, pp. 49 - 59. [Byrne and Wiatrowski, 1986]. W.E. Byrne and E. Wiatrowski, "Object-Oriented Design With Graphical Abstraction," Proceedings of the Third National Conference on Methodologies and Tools for Real-Time Systems, National Institute for Software Quality and Productivity, Washington, D.C., September 1986, pp. C-1 to C-19. [Clark, 1987]. R.G. Clark, "Designing Concurrent Objects," Ada Letters, Volume VII, No. 6, Fall 1987, pp. 107 - 109. [Colbert, 1989]. E. Colbert, "The Object-Oriented Software Development Method: A Practical Approach to Object-Oriented Development," Proceedings of TRI-Ada '89 -- Ada Technology In Context: Application, Development, and Deployment, October 23-26, 1989, Association for Computing Machinery, New York, New York, pp. 400 - 415. [Davis and Irving, 1989]. N.W. Davis and M. Irving, "Practical Experiences of Ada and Object-Oriented Design In Real-Time Distributed Systems," Ada: the Design Choice -- Proceedings of the Ada-Europe Conference, Madrid 13-15 June 1989, Cambridge University Press, Cambridge, United Kingdom, 1989, pp. 59 - 79. [Gray, 1987]. L. Gray, "Procedures for Transitioning from Structured Methods to Object-Oriented Design," Proceedings of the Conference on Methodologies and Tools for Real-Time Systems IV, National Institute for Software Quality and Productivity, Washington, D.C., September 14-15 1987, pp. R-1 to R-21. [Gray, 1988]. L. Gray, "Transitioning from Structured Analysis to Object-Oriented Design," Proceedings of the Fifth Washington Ada Symposium, June 27 - 30, 1988, Association for Computing Machinery, New York, New York, 1988, pp. 151 - 162. [Heitz, 1988]. M. Heitz, "HOOD: A Hierarchical Object-Oriented Design Method," Proceedings of the Third German Ada Users Congress, January 1988, Gesellschaft fur Software Engineering, Munich, West Germany, pp. 12-1 - 12-9. [Heitz and Labreuille, 1988]. M. Heitz and B. Labreuille, "Design and Development of Distributed Software Using Hierarchical Object Oriented Design and Ada," in Ada In Industry: Proceedings of the Ada-Europe International Conference Munich 7-9 June, 1988, Cambridge University Press, Cambridge, United Kingdom, 1988, pp. 143 - 156. [Jamsa, 1984]. K.A. Jamsa, "Object Oriented Design vs. Structured Design -- A Student's Perspective," Software Engineering Notes, Vol. 9. No. 1, January 1984, pp. 43 - 49. [Khalsa, 1989]. G.K. Khalsa, "Using Object Modeling to Transform Structured Analysis Into Object-Oriented Design," Proceedings of the Sixth Washington Ada Symposium, June 26-29, 1989, pp. 201 - 212. [Ladden, 1988]. R.M. Ladden, "A Survey of Issues To Be Considered In the Development of an Object-Oriented Development Methodology for Ada," Software Engineering Notes, Vol. 13, No. 3, July 1988, pp. 24 - 31. [Lee et al, 1987]. K.J. Lee, M.S. Rissman, R.D. D'Ippolito, C. Plinta, and R. Van Scoy, An OOD Paradigm for Flight Simulators, Technical Report CMU/SEI-87-TR-43 (ESD-TR-87-206), Software Engineering Institute, Pittsburgh, Pennsylvania, 1987. [Masiero and Germano, 1988]. P. Masiero and F.S.R. Germano, "JSD As An Object-Oriented Design Method," Software Engineering Notes, Vol. 13, No. 3, July 1988, pp. 22 - 23. [McQuown, 1989]. K. McQuown, "Object-Oriented Design in a Real-Time Multiprocessor Environment," Proceedings of TRI-Ada '89 -- Ada Technology In Context: Application, Development, and Deployment, October 23-26, 1989, Association for Computing Machinery, New York, New York, pp. 570 - 588. [Nielsen and Shumate, 1987]. K.W. Nielsen and K. Shumate, "Designing Large Real-Time Systems With Ada," Communications of the ACM, Vol. 30, No. 8, August 1987, pp. 695 - 715. [Rajlich and Silva, 1988]. V. Rajlich and J. Silva, "Two Object-Oriented Decomposition Techniques," Proceedings of the Fifth Washington Ada Symposium, June 27 - 30, 1988, Association for Computing Machinery, New York, New York, 1988, pp. 171 - 176. [Rosson and Gold, 1989]. M.B. Rosson and E. Gold, "Problem-Solution Mapping In Object-Oriented Design," OOPSLA '89 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 7 - 10. [Safford, 1987]. H.D. Safford, "Ada Object-Oriented Design Saves Costs," Government Computer News, Vol. 6, No. 19, September 25, 1987. page 108. [Seidewitz and Stark, 1986]. E. Seidewitz and M. Stark, General Object-Oriented Software Development, Document No. SEL-86-002, NASA Goddard Space Flight Center, Greenbelt, Maryland, 1986. [Shumate, 1988]. K. Shumate, "Layered Virtual Machine/Object-Oriented Design," Proceedings of the Fifth Washington Ada Symposium, June 27 - 30, 1988, Association for Computing Machinery, New York, New York, 1988, pp. 177 - 190. [Stark and Seidewitz, 1987]. M. Stark and E.V. Seidewitz, "Towards a General Object-Oriented Ada Life-Cycle," Proceedings of the Joint Ada Conference, Fifth National Conference on Ada Technology and Washington Ada Symposium, U.S. Army Communications-Electronics Command, Fort Monmouth, New Jersey, pp. 213 - 222. [Vidale and Hayden, 1987]. R.F. Hayden and C.R. Hayden, "A Student Project to Extend Object-Oriented Design," Proceedings of the Ada Software Engineering Education and Training Symposium, June 9-11, 1987, pp. 89 - 98. [Vielcanet, 1989]. P. Vielcanet, "HOOD Design Method and Control/Command Techniques fo the Development of Realtime Software," Proceedings of the Sixth Washington Ada Symposium, June 26-29, 1989, pp. 213 - 219. [Ward, 1989]. P.T. Ward, "How to Integrate Object Orientation with Structured Analysis and Design," IEEE Software, Vol. 6, No. 2, March 1989, pp. 74 - 82. [Wasserman et al, 1989]. A.I. Wasserman, P. Pircher, and R.J. Muller, "An Object-Oriented Design Method for Code Generation," Software Engineering Notes, Vol. 14, No. 1, January 1989, pp. 32 - 55. [Wirfs-Brock and Wilkerson, 1989]. R. Wirfs-Brock and B. Wilkerson, "Object-Oriented Design: A Responsibility-Driven Approach," OOPSLA '89 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 71 - 76.