Object-Oriented Design Method
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,
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.
1: Organization of the IDEF4 Model
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
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.
2: Inheritance Diagram
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.
3: Type Diagram
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.
4: Protocol Diagram
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
5: Method Taxonomy Diagram
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.
6: Client Diagram
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
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
to support the IDEF4 method.