Overview

The intuitive nature of object-oriented programming makes it easier to produce code. Unfortunately, the ease with which software is produced also makes it easier to create software of poor design, resulting in systems lacking re-usability, modularity, and maintainability. The IDEF4 method is designed to assist in the correct application of this technology.

With over thirty object-oriented design methods in existence today, why should we chose IDEF4? Most importantly, IDEF4 views object-oriented design as part of a larger system development framework, rather than an object-oriented analysis and design method that is ambiguous. IDEF4 stresses the object-oriented design process over the graphical syntax, using the graphical syntax and diagrams as aids to focus and communicate important design issues. IDEF4 is significantly different from other object design methods, primarily in its support of "least commitment" strategies and its support for assessing the design impact of the interaction between class inheritance, object composition, functional decomposition, and polymorphism.

IDEF4 Concepts

IDEF4 divides the object-oriented design activity into discrete, manageable chunks. Each subactivity is supported by a graphical syntax that highlights the design decisions that must be made and their impact on other perspectives of the design. No single diagram shows all the information contained in the IDEF4 design model, thus limiting confusion and allowing rapid inspection of the desired information. Carefully designed overlap among diagram types serves to ensure compatibility between the different submodels. The IDEF4 method allows the designer to easily make trade-offs between class composition, class inheritance, functional decomposition, and polymorphism in a design. IDEF4 is more than a graphical syntax--the graphical syntax provides a convenient framework for navigating an evolving object-oriented design that is ultimately specified on class invariant data sheets and method set contracts.

Figure 1 shows the basic organization of an IDEF4 model. Conceptually, an IDEF4 model consists of two submodels, the class submodel and the method submodel. The two submodels are linked through a dispatch mapping. These two structures capture all the information represented in a design model. Due to the size of the class and method submodels, the IDEF4 object designer never sees these structures in their entirety. Instead, the designer makes use of the collection of smaller diagrams and data sheets that effectively capture the information represented in the class and method submodels.

The class submodel is composed of the following diagram types: 1) Inheritance diagrams that specify class inheritance relations; 2) Type diagrams that specify class composition; 3) Protocol diagrams that specify method invocation protocols; and 4) Instantiation diagrams that describe object instantiation scenarios that assist the designer in validating the design.

The method submodel is composed of the following two diagram types: 1) Method taxonomy diagrams which classify method types by behavior similarity and 2) Client diagrams which illustrate clients and suppliers of methods, to specify functional decomposition.

IDEF4 Class Submodel

The class submodel consists of inheritance diagrams, type diagrams, instantiation diagrams, protocol diagrams, and class-invariant data sheets. The class submodel shows class inheritance and class composition structure.

IDEF4 Inheritance Diagrams

Inheritance diagrams specify the inheritance relations among classes. For example, Figure 2 shows the class Filled-rectangle inheriting structure and behavior directly from the classes Rectangle and Filled-object and indirectly from the class Object.

IDEF4 Instantiation Diagrams

Instantiation diagrams are associated with type diagrams in the class submodel. The instantiation diagrams describe the anticipated situations of composite links between instantiated objects that are used for validating the design.

IDEF4 Protocol Diagrams

Protocol diagrams specify the class argument types for method invocation. Figure 4 illustrates a protocol diagram for the Fill-closed-object: Polygon routine-class pair. From the diagram, the reader can to tell that Fill-closed-object will accept an instance of the class Polygon as its primary (self) argument and an instance of the class Color as a secondary argument, and will return an instance of a Polygon.

The IDEF4 Method Submodel

The method submodel consists of method taxonomy diagrams, client diagrams, and data sheets.

Method Taxonomy Diagrams

Method taxonomy diagrams classify method types by behavioral similarity. A method taxonomy diagram classifies a specific system behavior type according to the constraints placed on the method sets represented in the taxonomy. The arrows indicate additional constraints placed on the method sets. Figure 5 shows a Print method taxonomy diagram. The method sets in the taxonomy are grouped according to the additional contracts placed on the methods in each set. In the example, the first method set, Print, has a contract that states that the object must be printable. The Print-text method set contract would have constraints such as "the object to be printed must be text."

Client Diagrams

Client diagrams illustrate clients and suppliers of routine-class pairs. Double-headed arrows point from the routine that is called to the calling routine. Figure 6 shows a client diagram where the Redisplay routine attached to the class Redisplayable-object calls the Erase routine of the Erasable-object class and the Draw routine on the Drawable-object class.

Data Sheets

Because IDEF4 is not just a graphical language, additional information about the inheritance diagrams, method taxonomy diagrams and type diagrams is maintained in detailed data sheets.

Class Invariant Data Sheets

Class-invariant data sheets are associated with inheritance diagrams and specify constraints that apply to every instance of a particular class of objects. There is one class-invariant data sheet for each class. The constraint, "Every triangle has three sides," is a class-invariant constraint on the class Triangle.

Contract Data Sheets

Contract data sheets are associated with the method sets in method taxonomy diagrams and specify contracts that the implemented methods in a method set must satisfy. There is one contract data sheet for each method set. A method set called Pop, for popping values off a stack, would have a contract that specified that it would not attempt to "pop" a the stack if the stack was empty.

Summary

The IDEF4 method, developed under sponsorship of the U.S. Air Force Armstrong Laboratory, is designed to assist in the correct application of object-oriented technology. IDEF4 was developed by professional object-oriented designers and programmers. The most important reason for choosing the IDEF4 method is that it views object-oriented design as part of a larger system development framework, rather than an object-oriented analysis and design method that is everything to everyone. It stresses the object-oriented design procedure over the graphical syntax, using the graphical syntax and diagrams as aids to focus on and communicate important design issues.

KBSI has developed an automated Object-Oriented Design tool, SMARTCLASS®, to support the IDEF4 method.