July 92 - Object-Oriented Analysis and Design Methods
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
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.
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.
Examples
FigureTwo shows an example of the Coad/Yourdon OOA notation, describing the Coad/Yourdon methodology. There are 3 subjects on the diagram: Class-&-Objects, Structures, and Subjects, which are described as follows:
- Class-&-Objects have Attributes and Services, and are connected by Instance Connections and Message Connections. Services may be shown on child diagrams called Service Charts.
- Structures can be Gen-Spec Structures (is a), or Whole-Part Structures (part of).
- Subjects can contain multiple Class-&-Objects and Structures; there can be multiple subjects in an OOA Model.
Figures Three and Four on the next page show a partial class diagram for MacApp 2 and an object diagram of MacApp's menu command mechanism using the Booch OOD notation. The class diagram shows the portion of the class hierarchy which is important to the menu command mechanism.
gTarget, a global variable, is the start of the command chain. Its declared type is the class TEvtHandler, so during execution it can be an instance of TEvtHandler or one of its subclasses (from figure 3 we see that this is TApplication, TDocument, TView, TScroller or TWindow). The TEvtHandler class has a field (or attribute, if you prefer), fNextHandler, of type TEvtHandler. During execution this field is set so that every subview points to its superview (declared as type TView), every window points to its enclosing document, and every document points to its application object. When a user selects a menu item, the DoMenuCommand method is invoked for the object designated by gTarget. If that object is unable to respond to it, then the same command message is passed around the command chain until an object handles it or nil is returned in fEventHandler.
As you can see, none of this is evident by simply looking at the class diagram, and without the class diagram the object diagram is missing something. The diagrams complement each other, providing the reader a greater understanding of the whole.
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.
Parting Comments
Given limited time and deadlines, we couldn't put everything that we wanted to into this article. We hope to have a second part to this article in the next issue of FrameWorks that goes through, step by step, a complete example of OOA and OOD, starting with the Coad/Yourdon OOA method following through to the Booch OOD method.
If you have any comments or questions, please feel free to link us (see AppleLink addresses above), or call us at (310) 458-0092, or write to us at ICONIX Software Engineering, 2800 28th Street, Suite 320, Santa Monica, CA 90405. n
