This action might not be possible to undo. Are you sure you want to continue?
By DBMS, May 1996 Michael Gora
The good, the bad, and the ugly of OOAD methodologies, and various approaches to using them.
Most new client/server application development tools emphasize object-oriented (OO) features. This implies that an OO analysis and design (OOAD) methodology should be an effective guide to applying these tools to business problems. But with the numerous methodologies available for OOAD, how do you choose the correct one? How do you get started, and how do you ascertain whether your approach is as efficient as it should be? And how do you avoid the pitfalls? OOAD can provide wonderful benefits, but believing that a new methodology will solve all your problems is like believing in Utopia. It's time for a reality check. In this article, I review different OOAD methodologies and various approaches to using them. I explain why I disagree with a number of mainstream concepts, I discuss what has worked and not worked in a number of projects, and I discuss how client/server applications that are developed with 4GL Windows tools may require a nonstandard approach to OOAD. My most common approach to OO methodology involves fairly strict adherence to OO design and construction guidelines as appropriate to a particular language, but a very loose and flexible approach to OO analysis. For me, OO analysis has become just another screwdriver in my toolkit -- useful for some projects but not for others. I spent all of 1988 and some of 1989 working with Richard Brown, one of the top OO developers in the U.S., building an OO EIS/DSS system under OS/2, using C as the language. Brown is a former Mitre Corp. principal scientist who, in an earlier life, was best known as the architect of the Kurzweil reading machine, which reads books to the blind, is still found in some libraries, and is still considered a high-water mark in OCR technology. The architecture of the EIS/DSS system we designed was based on LISP-based OO and artificial intelligence (AI) systems that Brown created for NASA and the Department of Defense while he was at Mitre. The project gave me good early exposure to OO concepts that had been proven in the field. Since 1989, my focus has been on Windows client/server development, although for a while, objects played no significant role in my work. For the last three years, however, almost all my technical work (that is, some of the analysis and all of the design and development) has been object oriented. I wouldn't do it any other way, but I'm still not comfortable with OOAD in the analysis phase. Although I currently teach three different OOAD courses, and have led custom seminars on OOAD, and one on managing OO projects, I'm still not completely happy with what I'm teaching. Is my lack of OO analysis understanding the problem, or is something else wrong? Every developer I know who has worked with OOAD and OO construction for more than a few months is extremely reluctant to go back to any other way of developing systems. The development speed, degree of organization, robustness, and code reuse have all been enhanced so much that going back to any other way of doing things is completely unthinkable. So why do I continue to squirm? A survey of available literature shows that the applications competing for "object honors" are written mostly in C++ or Smalltalk, and have a heavy manufacturing, engineering, aerospace, or scientific focus. That the major OOAD methodologies are best for such problems, however, does not guarantee that they are also best for typical business client/server applications. You need to determine which methodology is best suited for your
The class definition defines the Customer class attributes and methods. model) of a set of logically related instances that share the same or similar characteristics. and state transition diagrams). Aggregation is identified by the phrase "is a part of. specification and evaluation of requirements." Firesmith also states that OO design is "the design of an application in terms of objects. and methods might be Add. and the term "object" is synonymous with instance. as well as contain any required new attributes and methods. that can have direct instances. classes." In comparing the definition of traditional analysis with that of OOAD. Inheritance (also referred to as generalization/specialization) is usually identified by the phrase "is a kind of. its limitations. According to Donald Firesmith in his book Dictionary of Object Technology (SIGS Books. but can override any of the ancestor attributes and methods. An object is any abstraction that models a single thing. such as residential customers and commercial customers. message passing. (Using OOAD often requires adaptations to methodologies. and what to do if no methodology matches your requirements precisely. classes. Update. classes. the types of problems to which it is best suited. an employee is associated with a company). When you're choosing a methodology. The drawing notation is slightly different in each. inheritance. Delete.) The Role of OOAD in the Software Life Cycle To understand what's right and wrong with OOAD. For an object class named Customer. 1995). aggregation. If you have different kinds of customers. modeling. These descendants use inheritance to gain access to all of the Customer class attributes and methods. and association. and a real customer such as "XYZ Corp. and relationships. as well as with an instance of a nonvisual class that can contain the business rules and data buffers that allow student data to be accessed in any window. Student and Faculty are both a kind of Person and are therefore inherited from the Person class.particular application. A class is any uniquely identified abstraction (that is. The student window class w_student in the lower left is the window designed in the application. If neither of the first two relationships applies. inheritance. Figure 2 illustrates the object relationships typically used in a single window. attributes might be Name and Address. they are important new additions to the toolkit. This window can have any number of instances at runtime." is an instance of the class. There are three types of relationships between classes: inheritance. Table 1 (page 64) summarizes the major OOAD methodologies. An abstract class is a class that has no instances." For example. Each instance of the window is associated with an instance of the sheet menu. Figure 1 shows some class relationships using Rumbaugh notation. polymorphism and dynamic binding. it is important to consider not only the methodology's features. but the objects are clearly related (for example. frameworks and their interactions. but also the cost of using it. the real differences in the methodologies are more subtle. process flow. and Validate. the only aspect that is really new is thinking of the world or the problem in terms of objects and object classes. When used in typical initial attempts to develop . that is. All of the major OOAD methodologies have a similar basic view of objects. you need to know where OO methodologies fit into the software life cycle." while OO analysis is "the discovery. and is used only for inheritance. then the relationship is association. analysis is "the development activity consisting of the discovery. you can create two new classes of customers that are descendants of the Customer class. These methodologies do not replace traditional approaches (such as data flow. clusters. analysis and specification of requirements in terms of objects with identity that encapsulate properties and operations. Classes have attributes and methods. and the training available." as with a product that contains parts. A concrete class is a class that can be instantiated.
your choice of development tool does affect the object architecture. and window control classes before they even start to experiment seriously with problem domain classes such as a Customer class.0. NewEra (Informix Software Inc. it is usually a requirement in complex systems that an object's attributes can map to one or more tables in one or more databases.). the problem domain is the least intuitive place to start. SQLWindows (Centura Software). even though another approach might be better for some parts of the problem * an overemphasis on the problem domain object model during the analysis phase * analysis diagrams and output formats that end users may find difficult to understand * difficulty in the methodology's ability to describe complex analysis problems * a lack of emphasis on the underlying system architecture * an inability to understand the limitations of either 4GL OO languages or of beginning OO developers Every object methodology tells you to start with the object model.). all of the methodologies suffer from the same basic flaws: * an overemphasis on the OO approach in general. Of course. Smalltalk. and so on. These types of problems are now on their way out. Each major 4GL supports a slightly different flavor of OO. controls. in object terms is much more difficult. and so on. menu classes. Learning to describe the problem domain.0 and new versions of other tools. * A good object model should be able to map to any data model.client/server applications using OOAD methodologies. the limitations on the problem domain object model have essentially disappeared. there are at least four problems with this approach: * The data model often exists before the object model. there are exceptions to . To build a client/server application. not the data model.0. In PowerBuilder 4. my company built a good three-tiered object architecture into one application to aid in managing complexity. In my experience. and other tools all have or had similar limitations. Despite this. For me. a good conceptual object model of an order-entry system simply could not be implemented easily. but neither the tools nor the methodologies are perfect. and the object model that you create during analysis may require significant adaptation going into the design phase. the accounting problem or order-entry problem. For example. menus. The last problem in this list is the only one that is disappearing rapidly. in SQLWindows 5. This should not continue to be the case. system error objects. Delphi. Another aspect of the problem is that for most developers learning about objects in typical development projects using OO client/server tools such as PowerBuilder. * The analyst may rightly be more comfortable building the data model before the object model. that is. SQLWindows. OO developers must first learn how to inherit windows. Delphi (Borland International Inc. With PowerBuilder 5. * A good abstract object model of the problem domain may not be easy to implement in the chosen language or development tool. and we had to strip it out for performance reasons. most developers using 4GL OO tools spend a year or more becoming comfortable with window classes. the overhead of the additional layers was unacceptable.
and now that Rational Rose is moving away from its previous tight link with C++ to a more open approach that supports 4GLs such as PowerBuilder. and process. 1990 and 1991. and traditionally uses techniques such as data flow diagrams. Coad and Yourdon. OOAD Methodologies OOAD methodologies fall into two basic types. Their methodology focuses on analysis of business problems. the (relative) weaknesses in analysis are disappearing rapidly. Booch Grady Booch's approach to OOAD (see his book Object-Oriented Design with Applications. which produces Rational Rose. its major strength has been in design. Prentice-Hall. but has the disadvantage of producing output from analysis that may be impossible to review with users. called SOSAS: . Coad and Yourdon Coad and Yourdon published the first practical and reasonably complete books on OOAD (Object-Oriented Analysis and Object-Oriented Design. There are several other methodologies that I don't discuss. In Coad and Yourdon. the methodology's popularity should increase rapidly. Process modeling or functional modeling is concerned with processes that transform data values. Rational Software is one of the major forces in the OOAD world. However. and generally uses state transition diagrams. Booch is the chief scientist at Rational Software. although Smalltalk developers typically begin to deal with abstract classes very quickly. The unary type asserts that because objects combine processes (methods) and data. Shlaer and Mellor. as shown schematically in Table 2. Object-Oriented Methods (Addison-Wesley. 1994) is one of the most popular. 1994). or the others that focus more on design. Dynamic modeling is concerned with events and states. respectively). I believe that Booch represents one of the better developed OOAD methodologies. Jacobson. only one notation is needed. Rumbaugh. which does an excellent job of both describing and comparing available methodologies. and if you are interested in learning more about them. LBMS. and uses a friendlier notation than that of Booch. For more than 20 states. I don't expect Smalltalk to become a major force in the client/server world.) Booch's design method and notation consist of four major activities and six notations. and is supported by a variety of reasonably priced tools ranging from Visio to Rational Rose. Benjamin/Cummings. dynamics. it becomes difficult to manage. (Now that James Rumbaugh and Ivar Jacobson have joined the company. I describe the methodologies of Booch. analysis proceeds in five stages. While the Booch methodology covers requirements analysis and domain analysis.this. but are not usable for systems with a large number of states. The ternary (or three-pronged) type is the natural evolution of existing structured methods and has three separate notations for data. Fusion. For systems with complex rules. state diagrams are fine for those with a small number of states. I strongly recommend Ian Graham's book. The unary type is considered to be more object-like and easier to learn from scratch. And. state transition diagrams become excessively unwieldy. and Shlaer and Mellor. with Rumbaugh and Jacobson entering the fold. In the following sections. Once a single-state transition diagram has more than eight to 10 states.
to develop a set of requirements for OOAD. Coad and Yourdon's methodology is not as limiting as its critics claim.K. Coleman did not use some of the major components of Rumbaugh and Shlaer and Mellor in Fusion. Coad and Yourdon do not deal as well as Rumbaugh. and several other methodologies do with these structures. The chief requirement was a simple methodology with an effective notation. because the components were not found to be useful in practice. and others. Fusion's pragmatic approach seems to hold considerable potential for client/server applications. . which Coleman and others developed by borrowing and adapting ideas from other methodologies. but this methodology is not being marketed as aggressively as most of the other methodologies. * Services: The identification of what other methodologies call methods or operations. Classification structures correspond to the inheritance relationship between classes. * Structures: There are two types: classification structures and composition structures. if you adhere to a premise that you should use those pieces of a methodology that work. Jacobson. Rumbaugh. but Coad and Yourdon provide few guidelines for how to do this. Derek Coleman of Hewlett-Packard led a team in the U. Customer classes and Order classes * human interaction component: user-interface classes such as window classes * task management component: system-management classes such as error classes and security classes * data management component: database access method classes and the like Although Coad and Yourdon's methodology is perhaps one of the easiest OO methodologies to learn and get started with. Jacobson. but. The result was Fusion. these five activities are supplanted by and refined into four components: * problem domain component: classes that deal with the problem domain. the most common complaint is that it is too simple and not suitable for large projects. However. but everything I read and hear about it places it at or near the head of the pack. * Objects: Object classes must be specified in this stage. and add other parts from other methodologies as required. Fusion I have never used Fusion. They incorporated some major ideas from Booch. Some writers have called this encouraging and remarkable. Articles that Fusion practitioners have written have been some of the most pragmatic and useful that I have seen about OOAD. * Attributes: These are handled in a fashion very similar to that in relational analysis. In 1990. for example.* Subjects: These are similar to the levels or layers in data-flow diagrams and should contain five to nine objects. unless you conduct a significant research effort. Composition structures define the other types of relationships between classes. and conducted a major survey of methods in use at HP and elsewhere. and explicitly rejected many other ideas from these methodologies. and consider it indirect proof that excessive emphasis on state models comes from Rumbaugh and Shlaer and Mellor's telecommunications and realtime system backgrounds. In design. you generally hear much more about other methodologies than about Fusion.
rules. and dynamics (state transitions and so on). together with attributes and methods. This makes the methodology well-suited for client/server database applications. Of the major methodologies. and contains a much richer object modeling notation than . I have used it not only for OO analysis. Rumbaugh OMT It offers one of the most complete descriptions yet written of an OO analysis methodology. and regards the shared objects as important interfaces between subsystems. Although it is somewhat lacking in OO design and construction. between customer behavior shared by all applications and customer object behavior unique to a single application. only SEOO gives the feeling of having started with non-OO approaches and then adapting to OO. SEOO draws a clear line between shared objects and other objects. SEOO is intended to be object oriented while retaining the advantages of traditional data modeling. It is a technique with which a purist would quibble. triggers. included hardware. it contains a large number of ideas and approaches that are of significant use to analysts and designers. for example.Because SEOO is proprietary. the notation is similar to that of ER modeling with methods (operations) added * the Dynamic Model (DM): state transition diagrams (STDs) for each class. It treats a data model as a view of the shared objects. software. but for a number of diagrams in recent proposals. A very positive aspect of this is the heavy focus on data management and data modeling. as well as global event-flow diagrams * the Functional Model (FM): diagrams very similar to data flow diagrams Because Rumbaugh's notation (as well as that of Booch and Shlaer and Mellor) is supported by low-end drawing tools such as Visio. and referential-integrity rules as a set of shared objects in a database. at the first level of inheritance. This technique allows a distinction. there is not as much detailed information available about it as there is about other methodologies. Rumbaugh's is one of those with which I feel most comfortable. For example. Rumbaugh starts by assuming that a requirements specification exists. The four major components of the SEOO methodology are: * work-breakdown structures and techniques * an object modeling methodology * GUI design techniques * relational database linkages to provide ER modeling and 4GL-specific features Of all the major OOAD approaches. and printed deliverables. but which is eminently practical. SEOO is unique in treating data. which also include constraints. I recently drew a diagram of project deliverables (in a proposal for a large OO development project) using Visio and Rumbaugh notation to show the object hierarchy of deliverables which. Analysis consists of building three separate models: * the Object Model (OM): definition of classes. It supports many traditional diagrams from structured methodologies. and it is somewhere between difficult and impossible to try it out just to compare it with the others.
and you must find another approach that does work. considered a guru by many.0 suggests yet another new class library architecture. Shlaer and Mellor OO Analysis When Shlaer and Mellor OO analysis first came out in 1988. Of these. believing each feature to be the solution to all their problems. 1988 and 1992. Objects Upon reflection. the fact that using objects requires more attention to systems architecture than in the past? The answers lie in training. Its weakness at this time is that is it less useful for client/server application design and construction. and PowerBuilder 5. to me. attributes. assure that we are working on the right objectives every hour. a data-flow diagram shows the process model. but the applications occasionally cited as examples of its use seem to be in the areas of real-time or process control. It seems that there are too many object bigots who build excessively complex object architectures and don't realize that objects can be overused just as easily as the go to statement in Cobol can be abused. was formerly an object bigot. (Note that this is more like a data model than an object model. That changed when he spent several months trying to force a complex set of business rules into an OO methodology that didn't support them (at least not without significant adaptation). Prentice-Hall. No one feature will make all software trivial to write. it represented one of the earliest examples of OO methodology and it has evolved very positively since then. Using. This does not mean that it is not usable for such work. Pragmatism in the OO world. You must be able to recognize quickly if the object methodology isn't working for your particular project. One of my object experts.) Originally an object-based extension of data modeling. Object-Oriented Systems Analysis -.Coad and Yourdon's.0. The object architectures that I used in PowerBuilder 3. but I have not seen it used for client/server development. and pragmatism. means being certain that my object guru is not an object bigot. Finally. This may have to do with the fact that an earlier version. if they have successfully completed other OO projects. is widely used in the realtime world. the experience was very expensive. (See Shlaer and Mellor's books. my discomfort with OOAD may be merely a side effect of the enormous rate of change in our industry.Modeling the World in Data and Object Lifecycles: Modeling the World in States. How do we deal with methodologies and development tools that continue to evolve rapidly? How do we train analysts that may be less versed in the new approaches than the developers are? And how do we assure that the analysts can deal with what I call the object problem. Not Abusing. discipline. While he was smart enough to learn from his mistake. that is. The same is true of all other OO languages. experience. respectively. commitment. but experienced analysts can overcome this with enough experience with class libraries for their development tool.0 were no longer optimum for PowerBuilder 4. Creating good software will continue to be hard work. But it never is. a state model documents the states of objects and the transitions between them. and relationships. the Shlaer and Mellor methodology starts with an information model describing objects. .) Next. whether it is object oriented or not. I am astounded at the number of gurus who "ooh" and "aah" (or should I say "om") at every new feature in every new OO development tool. the latter two may require the most attention. and assure that we are doing this efficiently. This methodology seems to be influenced strongly by relational design. and no one architecture will be ideal for all problems. Discipline requires us to question what we are doing every day. the Ward/Mellor approach.
and experience. Rich. Pragmatic Complex. but heavily Embedded. Rich. skill. Rich Middle of the Road. better code that is more reliable and reusable than ever before. Real-Time Shlaer and Mellor OOA No Ternary Design Table 2. I have recently come to believe that the same is probably true of objects. The Steps in Booch's Methodology Steps Logical structure Physical structure Dynamics of Classes Dynamics of Instances Notations Class Diagrams Object Diagrams Module Diagrams Process Diagrams State Transition Diagrams Timing Diagrams . Rich Design Coad and Yourdon Fusion No Unary Analysis Client/Server No Ternary Full Life Cycle Full Life Cycle Full Life Cycle Analysis & Design All Jacobson Objectory LBMS SEOO Yes Yes Ternary Ternary All Client/Server Rumbaugh OMT No Ternary All. Rich. but just as many ways to do things wrong. but the combination of turmoil and immaturity in the object world requires a great deal of caution and pragmatism. the object world will not be a better world. that is. a GUI world without objects. After my first two years of working in Windows. Pragmatic Complex. Pragmatic Simple. Major OOAD Methodologies Analysis Methodology Proprietary Type Scope Strengths Primary Cited Applications / Markets All Booch No Ternary Complex.I have no doubt that OOAD methodologies can deliver faster. Table 1. Limited. If you do not have staff with the right combination of training. I saw that there were more ways to do things right than ever before. Real-Time Embedded. Somewhat Pragmatic Complex. Pragmatic Complex.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.