Object-Oriented Analysis and Design Methods

Doug Rosenberg and Patti Jennett

As software development has progressed, the systems developed by software engineers have increased in complexity. Until recently, structured programming techniques were the most widely used for all phases of development, from analysis and design to implementation. As the systems we model in software have become more complex, many have found structured programming techniques lacking. Object-oriented programming (OOP) has been touted as solving many of the problems of programming complex systems, such as software manageability, code reuse, and continual change. Yet choosing an OOP implementation doesn't mean that you can forget about analysis and design.

Good software doesn't just write itself, even if you choose the "best" implementation technique (like object-oriented programming), or the "best" environment, or the "best" language. Good software must begin with a good design. A good design needs a good analysis of the problem domain so that those implementing the system are in tune with those who are commissioning the system. OOP needs both an analysis and design technique suited to the methodology. Figure 1 gives some examples of available analysis and design techniques.

Why Coad/Yourdon and Booch?

So which technique do you choose? Most of us are familiar with structured analysis and data flow diagrams, but those are ill suited for OOP. Object-oriented analysis and design techniques are relatively new and are proliferating rapidly as OOP matures. Several object-oriented analysis (OOA) methods (e.g., Shlaer/Mellor) have their roots in Information Modeling techniques, while other object-oriented design (OOD) methods (such as Booch) evolved from object-oriented programming methodologies. The one you choose may depend on whether you are coming from a structured analysis environment to an object-oriented one and want something familiar or you prefer to immerse yourself in pure object-oriented techniques from the beginning.

Today's popular OO modeling methods can be divided into two groups: those which have evolved down from Data Modeling and those which have evolved up from OOP practices. Examples of methods evolved from Data Modeling include Shlaer/Mellor, Rumbaugh, and Coad/Yourdon; examples of those evolved from OOP practice include Booch and Wirfs-Brock. In general, methods evolved from Data Modeling seem better suited to analysis, while methods evolved from OOP practice seem better suited to design. ICONIX chose the Coad/Yourdon and Booch methods for the initial version of ObjectModelerª based on market feedback as to which OOA and OOD methods seemed to be gaining the greatest acceptance in the field.

Using structured analysis or analyzing data flow diagrams can be used as a front end to OOA or OOD. Thinking in those terms may help those new to OOP initially understand the problem better, but it is not optimal over the long term life of a program. Once analysts, designers, and programmers are trained in object-oriented techniques, continually going back to structured techniques when making changes to the system adds an unnecessary step to the life-cycle.

Coad/Yourdon and Booch provide more "pure" methods of analysis and design. They start with viewing the problem domain from an object-oriented vocabulary. A "pure" object-oriented method allows for easier refinement of the problem over the life-cycle of the application.

What is OBJECT-ORIENTED Analysis?

Grady Booch, in his book Object-Oriented Design with Applications, states: "Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain." This definition brings up three key elements: classes, objects and problem domain.

Coad and Yourdon, in their book Object-Oriented Analysis, define problem domain as "A field of endeavor under consideration." They give examples of problem domains as air space management, avionics, finance, and law. These example problem domains are rather broad, so we are not finished here. Coad and Yourdon also state that "OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light."

Coad/Yourdon describe an object as "An abstraction of something in a problem domain, reflecting the capabilities of a system to keep information about it, interact with it, or both; an encapsulation of Attribute values and their exclusive Services. (synonym: an Instance)." They describe a class as "A description of one or more Objects with a uniform set of Attributes and Services, including a description of how to create new Objects in the Class."

With these definitions in mind, let's examine the Coad/Yourdon OOA methodology.

Coad/Yourdon - The Method

Coad and Yourdon base their approach to OOA on 8 principles for managing complexity. Those principles are Abstraction (both Data and Procedural), Encapsulation, Inheritance, Association, Communication with messages, Pervading methods of organization (subdivided into Objects and attributes, Whole and parts, Classes and members, and distinguishing between them), Scale, and Categories of behavior (Immediate causation, Change over time, Similarity of functions). These principles are very similar to the Object Model used by Booch, described below.

The overall approach consists of five major activities. They are Finding Class-&-Objects, Identifying Structures, Identifying Subjects, Defining Attributes, and Defining Services. From these five activities, they arrive at a five layer model of OOA. The five layers are the Subject Layer, Class-&-Object Layer, Structure Layer, Attribute Layer, and Service Layer.

Subjects are used to give a higher level overview of the problem domain than the class and object level. They are used as a guide through a large model.

Class-&-Object is a term meaning "a Class and the Objects in that Class." In general, over time, Class-&-Objects remain stable. They provide the basis for moving towards reusable analysis. Attributes and Services describe the Class-&-Object in more detail. They represent the Object's state (or data) and its behavior (processes). While the Class-&-Objects are not likely to change over time, the Attributes and Services may change radically.

Structures are divided into two types, the "is a" or "is a kind of" structure and the "has a"Êstructure. Coad/Yourdon call these the Generalization-Specialization (Gen-Spec) and Whole-Part structures.

What is OBJECT-ORIENTED Design?

Booch defines OOD as follows: "Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design." In other words, OOD uses classes and objects to structure systems, as opposed to algorithmic abstractions used by structured design. It also uses a notation that expresses classes and objects (the logical decomposition) as well as modules and process (the physical decomposition).

Booch - The Method

The Object Model

1. Elements of Object Model

According to Booch, there are four major elements of the Object Model:

Abstraction, Encapsulation, Modularity, and Hierarchy. A model must have all four of these elements to be object-oriented.

In addition, there are three minor elements of the Object Model:

Typing, Concurrency, and Persistence. Each of these elements is useful to the model, but not essential. The elements of the Object Model help you make use of the full power of the object-oriented language used for implementation. Without them, for example, an Object Pascal implementation will look like Pascal, a C++ implementation will look like C, etc. (and we all know that good FORTRAN programmers can write FORTRAN in any language).

So what are Abstraction, Encapsulation, Modularity, and Hierarchy?

In brief, Abstraction is the process of identifying the essential characteristics of an object that distinguish it from all other kinds of objects. Basically it is identifying your classes and objects. Booch provides a wonderful chapter on how to identify your classes and objects, which we highly recommend.

Encapsulation is another term for information hiding. While Abstraction focuses on how the object is viewed from the outside, Encapsulation focuses on what can only be seen from inside the object perspective.

Modularity is how one partitions a program. It creates well-defined, documented boundaries within a program. These boundaries can provide logical separation between the objects of an application, to separate out reusable parts. Sometimes they are used to partition out the work to individual programmers (hopefully in a logical manner).

Hierarchy is defined by Booch as the "ranking or ordering of abstractions." Hierarchy defines the structure of your complex system, the "kind of" class structure and the "part of" object structure. Inheritance is classified as a "kind of" hierarchy, and is sometimes called the "is a" hierarchy.

What are Typing, Concurrency and Persistence?

Typing:

Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. type is a precise characterization of structural or behavioral properties which a collection of entities all share.

Type is "A name assigned to an interface. In typed languages, declaring a class creates a new type, and an object may be of one or more type through interface inheritance".

Strong/Weak typing refers to type consistency, a given programming language may be:

Strongly typed : Java, Eiffel
Untyped: Smalltalk
Bybrid: C++

Static/dynamic binding refers to the time when names are bound to types. Static binding means that the types of all varaibles and expressions are fixed at the time of compilation; Dynamic binding means that the types of all variables and expressions are not known until runtime. Dynamic binding lets substitute objects that have identical interfaces for each at runtime. This substitutability is known as Polymorphism.

Concurrency:

Heavyweight Process is one that is typically independently managed by the target opertaing system, and so encompasses its own address space. Lightweight process usually lives within a single operating system process along with other lightweight processes, which share the same address space. Communication among heavyweight processes is generally expensive, involving some form of interprocess communications; communication among lighweight processes is less expensive, and often involves shared data.

A fundamental concept in computer programming is the idea of handling more than one task at a time. Many programming problems require that the program be able to stop what it’s doing, deal with some other problem, and then return to the main process. The solution has been approached in many ways. Initially, programmers with low-level knowledge of the machine wrote interrupt service routines, and the suspension of the main process was initiated through a hardware interrupt. Although this worked well, it was difficult and nonportable, so it made moving a program to a new type of machine slow and expensive.

Sometimes, interrupts are necessary for handling time-critical tasks, but there’s a large class of problems in which you’re simply trying to partition the problem into separately running pieces so that the whole program can be more responsive. Within a program, these separately running pieces are called threads, and the general concept is called concurrency or multithreading. A common example of multithreading is the user interface. By using threads, a user can press a button and get a quick response rather than being forced to wait until the program finishes its current task.

Ordinarily, threads are just a way to allocate the time of a single processor. But if the operating system supports multiple processors, each thread can be assigned to a different processor, and they can truly run in parallel. One of the convenient features of multithreading at the language level is that the programmer doesn’t need to worry about whether there are many processors or just one. The program is logically divided into threads and if the machine has more than one processor, then the program runs faster, without any special adjustments.

All this makes threading sound pretty simple. There is a catch: shared resources. If you have more than one thread running that’s expecting to access the same resource, you have a problem. For example, two processes can’t simultaneously send information to a printer. To solve the problem, resources that can be shared, such as the printer, must be locked while they are being used. So a thread locks a resource, completes its task, and then releases the lock so that someone else can use the resource.

Java’s threading is built into the language, which makes a complicated subject much simpler. The threading is supported on an object level, so one thread of execution is represented by one object. Java also provides limited resource locking. It can lock the memory of any object (which is, after all, one kind of shared resource) so that only one thread can use it at a time. This is accomplished with the synchronized keyword. Other types of resources must be locked explicitly by the programmer, typically by creating an object to represent the lock that all threads must check before accessing that resource.

Persistence:

When you create an object, it exists for as long as you need it, but under no circumstances does it exist when the program terminates. While this makes sense at first, there are situations in which it would be incredibly useful if an object could exist and hold its information even while the program wasn’t running. Then the next time you started the program, the object would be there and it would have the same information it had the previous time the program was running. Of course, you can get a similar effect by writing the information to a file or to a database, but in the spirit of making everything an object, it would be quite convenient to be able to declare an object persistent and have all the details taken care of for you.

Java provides support for “lightweight persistence,” which means that you can easily store objects on disk and later retrieve them. The reason it’s “lightweight” is that you’re still forced to make explicit calls to do the storage and retrieval. Lightweight persistence can be implemented both through object serialization

2. Relationships Among Classes

Association
Association are often implemented in programming language as pointer from one object to another (buried pointer).
Cardinality is a kind of association which has three basic forms: a) one-to-one; b) one-to-many; c) many-many
Inheritance
Aggregation - is a whole/part relationship. Containment by value is a type of physical containment. The contained part does not exist independently of the enclosing object. When the whole object is destroyed, its parts are also destroyed. A less direct kind of aggregation is containment by reference. The contained part is not physically in the whole, it must be accessed by reference. The objects are not so tightly coupled (one may be destroyed without the other being affected). Only containment by reference may be cyclic (eg. A shareholder owns stocks, but does not physically contain the stocks. The lifetime of the objects is independent although they are conceptually a whole/part relationship.
Using - relationships imply a client and supplier for certain services. This differs from association which can be bidirectional. The supplier may appear as an argument in the interface of the client. This highlights that the supplier is not part of the client, but is used by it.
Instantiation - Ways to build classes with Genericity
Parameterized Types - also be called generics (Ada, Eiffel), or templete (C++). C++ provides templates to allow definition of parameterized types. Templates provide a way of specifying how a family of related classes can be made. Templates are most useful in creating type-safe collection classes. A class template for a family of collection classes specifies how a collection class can be made for a particular element type. A template is written in terms of one or more type parameters. For example, for collection classes, a type parameter may refer to the type of elements. A specific collection class is created from the template when the element type is specified at the time of use. For different element types, different collection classes belonging to the same family are generated at the time of use. This can result in bloated compiled code. This problem can be eliminated by designing intrusive template collection classes, so-called because the classes of elements in the collection must inherit from a common superclass. This restriction makes it difficult to use a collection class to store instances of a preexisting class.
Inheritance and Late Binding - Although Java does not support parameterized types, it is possible to implement type-safe collection classes. For example, the constructor of a type-safe collection class can take a prototype element, an object of the same type as elements that will be inserted. Now, before allowing insertion, the collection can check if the element to be inserted and the prototype are of the same type, thus enabling it to enforce type safety. If the element is not of the desired type, it can reject the element by throwing an exception. This approach is nonintrusive, and this collection class can be used to store objects of any specified type by providing an appropriate prototype at the time of instantiation. The class can be implemented so that it does not do type checking if no prototype is provided when the constructor is invoked, thus allowing the use of the collection class for implementing heterogeneous as well as homogeneous collections. It is possible to accomplish the same in C++ using typeid.
The approach for a type-safe Java collection described here provides significant run-time flexibility as compared to most C++ template classes. However, C++ template collection classes enable more compile-time checking. Additionally, C++ template classes can be parameterized by primitive types as well as classes, while only objects may be stored in a collection class using the approach described for Java.

Metaclass - Every object is an instance of some class. Most often we deal with the objects which are built from classes. But sometime, we may want to manipulate the class itself just as if it is a common object. In that case, we need metaclass. A metaclass is a class whose instances are themselves classes, it is the class of a class.

Not every programming directly support metaclass:

Supported: Java, Smalltalk
Not Supported: C++

In java, the class Class is a metaclass, it provides services to application programs, such as returning a set of all methods, instances or parents for review (or even modification). The metaclass Class provides some degree of reflection, including retrieving methods, fields, nested classes, loader, and also the ability to generically create new instances of a class and generically invoke methods on an object. See the following example:

import java.lang.reflect.*;

public class MyClass{
    String attribute;
	
    public MyClass(){
        this("Default Attribute");
    }

    public MyClass(String attr){
        this.attribute=attr;
    }

    public String getAttribute(){
        System.out.println("method getAttribute get called");
        return attribute;	
    }

    public void setAttribute(String attr){
        System.out.println("method setAttribute get called");
        this.attribute=attr;		
    }

    public static  void main(String[] arg){
        //Get the Class object of MyClass 
        Class aClass = MyClass.class;                    

        //Get the Class object of a class named "MyClass".
        try{
            Class aClass2 = Class.forName("MyClass");
        }
        catch(ClassNotFoundException e){
        }
		
        // Get MyClass's public methods
        Method methods[] = aClass.getMethods();     		

        // Get MyClass's declared public methods
        Method  declaredMethods[]  = aClass.getDeclaredMethods();     		
		
        // Get class MyClass through one of its methods.
        Class  getClassBack = methods[0].getDeclaringClass();  

        MyClass instance1 = null;

        // Create a new object with  MyClass()
        try{
            // Create a new object with class MyClass
            instance1 = (MyClass)aClass.newInstance();    
        }
        catch(InstantiationException e){}
        catch(Exception e){}

        //call the getAttribute() method through reflection
        Method method = null;
        try{
            method = aClass.getDeclaredMethod("getAttribute", null); 
            method.invoke(instance1, null);
        }
        catch(Exception e){
            System.out.println(e);
        }

        MyClass instance2 = null;

        // Create a new object with  MyClass(String)
        try{
            Class[] paramTypes ={ Class.forName("java.lang.String") };			
            Constructor constructor = aClass.getConstructor(paramTypes);
            Object[] params  = { "My Attribute"};
            instance2  = (MyClass) constructor.newInstance(params);
        }
        catch(InstantiationException e){}
        catch(Exception e){}

        //call the setAttribute(String) method through reflection
        try{						
            Class[] paramTypes ={ Class.forName("java.lang.String") };			
            Method myMethod = aClass.getMethod("setAttribute", paramTypes);
            Object[] params  = { "My Attribute"};
            myMethod.invoke(instance2, params);
        }
        catch(IllegalAccessException e){}
        catch(InvocationTargetException e){}
        catch(ClassNotFoundException e){}
        catch(NoSuchMethodException e){}
    }

 }

3. Classfication

Classification is the means whereby we order knowledge. In object-oriented design it allows us to expose the commonality within key abstractions and mechanism, eventually leads us to smaller and simpler architectures.

Identifying Classes and Objects

Classical Approaches for classification are derived primarily from the principles of classical categorization. All the entities that have a given property or collection of properties in a common form a category. Such properties are necessary and sufficient to define a category. For example, married people form a category, but tall people do not unless we define an absolute criteria for tall.

Shlaer and Mellor (1988) suggest classes and objects usually come from one of the following sources:

Tangible things - cars, telemetry data, sensors
Roles - teacher, politician, clerk
Events - landing, interrupt, request
Interactions - loan, meeting

From a database modeling perspective, Ross (1987) offers a similar list:

People - Humans who carry out some function.
Places - Areas set aside for people or things.
Things - Physical objects or groups of objects.
Organizations - Formally organized collections of people, resources, facilities, and capabilities having a defined mission, whose existence is largely independent of the individuals.
Concepts - Principles or ideas not tangible per se; used to organize or keep track of business activities.
Events - Things that happen, usually to something else at a given date and time, or a step in an ordered sequence.

Coad and Yourdon (1990) suggest another set of objects:

Structure - "is a" and "part of" relationships.
Other Systems - external systems with which the applications interacts.
Devices - devices with which the application interacts.
Events Remembered - historical events that must be recorded.
Roles Played - different roles which users play while interacting with the application.
Locations - Physical locations, offices, sites important to the application.
Organizational Units - Groups to which the user belongs.

A different approach to classification comes from behavior analysis. Whereas classical approach focuses on tangible things, behavior analysis focuses on dynamic behavior as the primary source of classes and objects. Classes are formed based upon groups of objects that exhibit similar behavior. Wirfs-Brock (1990) emphasize responsibilities for identifying objects. Rubin and Goldberg (1992) suggest an approach of using system functions to identify classes and objects. They emphasize first understanding what takes place in the system then assigning these behaviors to parts of the system. They also try to identify who initiates and participates in these behaviors.

Identifying Key Abstractions

A key abstraction is a class or object that forms part of the vocabulary of the problem domain. They give boundaries to problems, highlight things that are relevant to the design, suppress things that are superfluous. They should lead to an appropriate choice of objects.

Identification of key abstractions involves:

Discovery - recognition of abstractions used by domain experts.
Invention - creation of classes/objects that may not be part of the problem domain, but are useful in the design or implementation.

If domain experts talk about an abstraction, it is probably important. Customers using a bank machine talk of accounts, deposits, and withdrawals. A developer would use these and introduce new abstractions such as database, screen manager, lists, queues.

The key abstractions are artifacts of the particular design, not of the problem domain.

Once a key abstraction has been identified as a candidate it must be evaluated in terms of:

Coupling - the strength of association between two modules. Strong coupling complicates a system because it is harder to change and understand one module if it is highly interrelated with other modules. (Are objects independent of each other?)
Cohesion - the degree of connectivity among the elements of a single modules (class or object). Elements of a module should work together to provide a desired behavior. (Are the things in the object describing one abstraction?)
Sufficiency - the module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. If this is missing the class will appear incomplete when it is used. (Is there enough functionality to use the object?)
Completeness - the module captures all meaningful characteristics of the abstraction. A complete class is one whose interface is general enough to be commonly usable by any client. (Is there enough required functionality in the module to make it generally useful?)
Primitiveness - operations which can be efficiently implemented with only the underlying abstraction. Providing all meaningful operations in an object can overwhelm the user and is generally unnecessary since many high-level operations can be composed of lower level methods. (Modules should not be combinations of existing operations without good reason)

Sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction. Stroustrup has the following to say about selecting an abstraction:

"the programmer must focus on the questions: how are objects of this class created? can objects of this class be created and/or destroyed? what operations can be done on such objects? If there are no good answers to these questions, the concept probably wasn't 'clean' in the first place, and it might be a good idea to think a bit more about the problem and the proposed solution instead of immediately starting to 'code around' the problems."

New abstractions must be placed within the context of the existing class/object hierarchies. This is neither bottom-up or top-down. Halbert and O'Brien observe:

"You do not always design types in a type hierarchy by starting with a supertype and then creating the subtypes. Frequently, you create several seemingly disparate types, realize they are related, and then factor out their common characteristic into one or more supertypes ... several passes up and down are usually required to produce a complete and correct program design."

Creating classes which are too general creates a grainsize conflict which makes inheritance by a subclass difficult because of the large semantic gap. Moving a general subclass up in the class structure, thus increasing the degree of sharing, is known as class promotion.

Naming classes should be done consistently for easier recognition.

Objects - proper nouns (eg. theSensor, shape)
Classes - noun phrases (eg. Sensors, Shapes)
Modifier operations - verb phrase (eg. draw, moveLeft)
Selector operations - should imply a query or be named with verbs of the form "to be" (eg. extentOf, isOpen)

Identifying Mechanisms and Patterns

The term mechanism is used to describe any structure whereby objects collaborate to provide some behaviour that satisfies a requirement of the problem. Whereas the design of a class embodies the knowledge of how individual objects behave, a mechanism is a design decision about how collections of objects cooperate. Mechanism thus represent patterns of behavious.

All well-structured object-oriented architectures are full of design patterns. The detail discussion of design patterns can be found "Design Patterns -Elements of Reusable Object-oriented software" by Erich Gamma,.etc.

Example of the Mechanisms

M-V-C (Model-View-Controller)
Blackboard - no central control, individual knowledge source independently update a blackboard,any change to the blackboard may trigger an agent to explore some new problem-solving path.

The Method

Booch addresses both a Logical and a Physical view of design, with both Static and Dynamic aspects of each. He segments Logical Design into Class Structure and Object Structure, and Physical Design into Module Architecture and Process Architecture. From this view of design, he comes up with a notation that includes four basic diagrams: class diagrams, object diagrams, module diagrams, and process diagrams. These are mainly static representations. To represent the dynamic aspects he also uses two supplementary diagrams in his notation: state transition diagrams and timing diagrams.

A class diagram shows the class structure using classes, the relationship between classes (such as class A uses class B or class C instantiates class D for example), and class utilities (a free subprogram or group of them). Class diagrams are largely static. For large systems, the class structure may be too large to represent in one diagram so class category diagrams are used to organize the classes. The use of class categories is analogous to the use of subjects in the Coad/Yourdon methodology.

Object diagrams show the existence of objects and their relationships to each other. Objects tend to be transitory during the execution of a program, so object diagrams show only a snapshot of the object at a given period of time. Each object on an object diagram shows some specific instance of a class.

Module diagrams show the allocation of classes, class utilities, objects, and other declarations of the physical module. This diagram is only used when the implementation language supports it.

Process diagrams are used for multi-process systems. They are used to visualize the allocation of processes to processors.

State transition diagrams (STDs) show the state space of a class, the events that cause a transition from one state to the other, and the actions that result from the change of state. Coad and Yourdon use STDs as well.

Timing diagrams show the dynamic interactions of various objects on the object diagram. For example, they can show over time, how operation 1, associated with object A, can invoke operation 2, associated with object B.

How can CASE Tools Help?

CASE tools help in many ways. They provide a common communication medium for a team of developers and help a team of analysts and designers to stay in synch. They provide a standard graphics vocabulary, which lends itself to conformity among diagrams. They also make the whole problem of documentation much easier, taking the grunt work out of documentation.

ICONIX has implemented ObjectModelerª to support both the Coad/Yourdon OOA and Booch OOD methods; specifically, Coad/Yourdon Class-&-Object and Service diagrams, and Booch Class, Class Category, and Object diagrams. ObjectModelerª allows, via a diagram editor, the end user to draw and manipulate instances of these diagram types.

Both the Booch and Coad/Yourdon methods also make use of State Transition Diagrams; ICONIX supports STDs in the FastTaskª module. Booch also makes use of Module and Process Architecture diagrams; the ICONIX AdaFlowª module may be used to create these (since Booch's Module diagram is very similar to his Ada diagramming notation). Finally, Booch proposes the use of Timing diagrams but states that these may be replaced by PDL. ObjectModeler's Language Sensitive Editor supports PDL in addition to C++. Those developers who do choose to work in PDL will probably find the ICONIX PowerPDL module useful, as well.

Conclusion

One of the hardest parts of object-oriented programming is coming up with the best set of objects to describe the problem domain, especially one that is complex and ever changing (the marketing guys want what? by tomorrow?!). There are often deadlines to meet, and we tend to want to jump in and start programming right away. Don't do it! First we need to analyze the problem domain and design a system that meets the requirements, before we implement it, otherwise we can end up with code that is not reusable, or continually needs to be "patched" or rewritten (from the ground up).

The combination of Coad/Yourdon OOA and Booch OOD provide a synergistic method for analysis and design. The principles laid out by Coad and Yourdon are very similar to the Object Model used by Booch's notation. Their notations use an object-oriented visualization to describe the problem domain, not structured analysis. This lends itself well to an object-oriented implementation and in the end leads to more manageable code. It also has one final bonus-not only do you have reusable code, you have reusable analysis and design as well.