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.
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.
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.
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.
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.
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.
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.
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.
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.
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
