IDEF4, or Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language for the design of component-based client/server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation. It specifies design objects with sufficient detail to enable source code generation.^[1]

This method is part of the IDEF family of modeling languages in the field of systems and software engineering.

IDEF4 method is a graphically oriented methodology for the design of object-oriented software systems. The object-oriented programming paradigm provides the developer with an abstract view of their program as composed of a set of state maintaining objects which define the behavior of the program by the protocol of their interactions. An object consists of a set of local state defining attributes and a set of methods (procedures) that define the behavior of that particular object and its relationship to the other objects that make up the system.^[2]

The IDEF4 method multi-dimensional approach to object-oriented software system design consists of the following items:^[1]

• Design layers (system-level, application-level, and low-level design),
• Artifact design status (application domain, in transition, software domain),
• Design models (static, dynamic, and behavior) and the design rationale component, and
• Design features ranging from general to specific enabling deferred decision making.

The development of IDEF4 came from the recognition that the modularity, maintainability, and code reusability that results from the object-oriented programming paradigm can be realized in traditional data processing applications. The proven ability of the object-oriented programming paradigm to support data level integration in large complex distributed systems is also a major factor in the widespread interest in this technology from the traditional data processing community.^[2]

IDEF4 was developed as a design tool for software designers who use object-oriented languages such as the Common Lisp Object System, Flavors, Smalltalk, Objective-C, C++ and others. Since effective usage of the object-oriented paradigm requires a different thought process than used with conventional procedural or database languages, standard methodologies such as structure charts, data flow diagrams, and traditional data design models (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process.^[2]

IDEF4 uses an object-oriented design method or procedure that is very similar to Rumbaugh’s Object Method Technique^[3] and Schlaer/Mellor’s Object-Oriented Analysis and Design (OOA/OOD) technique.^[4] However, there are some crucial differences:

• IDEF4 is specifically designed to be compatible with other IDEF methods,
• IDEF4 allows one to track the status of design artifacts from domain object through transition to design specification, and
• IDEF4 includes a design rationale component.

These extra dimensions are shown in the figure. The edges of the box show the progression of the design from start to finish elaborating each of these dimensions.

In IDEF4, a design starts with the analysis of requirements and takes as input the domain objects. These domain objects are encoded in their equivalent IDEF4 form and marked as domain objects. As computational objects are developed for these objects, they are marked as “transitional” and finally as “completed.” The level of completion of an IDEF4 design is determined by setting measures based on the status, level, and model dimensions of individual artifacts in the design.^[1]

The system-level design starts once the “raw material” (domain) objects have been collected. This develops the design context, ensures connectivity to legacy systems, and identifies the applications that must be built to satisfy the requirements. Static, dynamic, behavioral, and rationale models are built for the objects at the system level. These specifications become the requirements on the application level – the next level of design. The application level design identifies and specifies all of the software components (partitions) needed in the design. Static models, dynamic models, behavioral models, and the rationale component are built for the objects at the application level. These specifications become the requirements on the next level of design – the low-level design. Static Models, Dynamic Models, Behavioral Models, and the design rationale component are built for the low-level design objects. Sub-layers may be built within each layer to reduce complexity.^[1]

IDEF4 is an iterative procedure involving partitioning, classification/specification, assembly, simulation, and rearranging activities (see figure). First, the design is partitioned into objects, each of which is either classified against existing objects or for which an external specification is developed. The external specification enables the internal specification of the object to be delegated and performed concurrently. After classification/specification, the interfaces between the objects are specified in the assembly activity (i.e., static, dynamic, and behavioral models detailing different aspects of the interaction between objects are developed). While the models are developed, it is important to simulate use scenarios or cases^[5] between objects to uncover design flaws. Based on these flaws, the designer can then rearrange the existing models and simulate them until the designer is satisfied.^[1]

IDEF4’s defines a set of object oriented concepts:^[1]

• Domains: IDEF4 projects are implemented in a domain. A domain can be seen as the scope of the system being developed. During system design, the software is transitioned between three domains: the application domain, the design domain, and the implementation domain.
• Features, Artifacts, and Objects
• Object Instance: Objects can be object instances, object classes, and object partitions. Object instances are the individual things encountered in the application domain.
• Classes: Classes are generalizations about objects and are used to manage complexity by taking advantage of similarities in object instances and grouping them under a class or category.
• Subclass/Superclass: The term subclass captures the concept of grouping particular instances of a class into an even more specialized class.
• Partitions: A partition object contains objects and relations.
• Attributes: Attributes are an implementation choice on how to represent an object’s state.
• Object States: Object states represent situations or conditions of an object instance that are meaningful in the design.
• Method: A method is an implementation of behavior (i.e., a set of instructions according to which the object performs some operation).
• Message and Polymorphism: Objects communicate by sending messages to each other.
• Event: An event is a signal generated by a method in an object indicating some condition in the object.
• Object Life cycles: In any system, objects exhibit patterns of behavior as they cycle through different states.
• Client/Server: An object plays the role of a client relative to a message if it is the sender of that message.
• Relationships and Roles: Objects are connected together with arcs. These arcs are called relationships and they show associations between objects.
• Inheritance: A specific type of relationship used in object-oriented technology is inheritance.
• Encapsulation and Information Hiding: Encapsulation and information hiding are two object-oriented concepts that are most easily understood when discussed in terms of interactions between objects.

The IDEF4 Method assumes that the domain objects have been identified through Object-Oriented Domain Analysis. Methods such as IDEF1, IDEF5, IDEF3, SA/SD can be used to perform domain analysis.^[6] However, IDEF4 practitioners should be aware of how objects are identified, as the design process may reveal deficiencies in the Object-Oriented Analysis. IDEF4 had defined five types of classes:^[1]

• Physical Objects: things found and observed in the natural world.
• Role Objects: The role may be related to other activities that the person engages in (e.g., a patient in a hospital, a stockholder, a client, a trustee, a suspect in a burglary, or a tax payer).
• Event Objects: Events or incidents may also be considered objects. The identification of events as objects is highly subjective, and will depend on the domain in which the software is to be used.
• Interaction Objects: Interaction objects are the result of interactions or transactions between two or more objects.
• Specification and Procedure Objects: Specification objects describe the acceptable characteristics of objects instances. Procedure objects refer to the way other object instances may interact.

IDEF4 users design in three distinct layers:^[1]

1. system design,
2. application design, and
3. low-level design.

This three layered organization reduces the complexity of the design. The system design layer ensures connectivity to other systems in the design context. The application layer depicts the interfaces between the components of the system being designed. These components include commercial applications, previously designed and implemented applications, and applications to be designed. The low-level design layer represents the foundation objects of the system.

IDEF4 distinguishes between IDEF4 artifacts newly created from the application domain, artifacts in transition to design specification, and artifacts that have been specified that can be applied to create the design specification. Any design artifact in IDEF4 can be marked as domain, transition, or complete. This allows practitioners and reviewers to track the progress of the design toward completion.^[1]

IDEF4 uses three design models and a design rationale component:^[1]

• The Static Model (SM) defines time-invariant relations between objects (for example, inheritance).
• The Dynamic Model (DM) specifies the communication between objects and the state transitions of objects.
• The Behavior Model (BM) defines the relations between the respective behaviors of objects.

The design rationale component provides a top-down representation of the system, giving a broad view that encompasses the three design models and documents the rationale for major design evolutions.

Each model represents a different cross section of the design. The three design models capture all the information represented in a design project, and the design rationale documents the reasoning behind the design. Each model is supported by a graphical syntax that highlights the design decisions that must be made and their impact on other perspectives of the design. To facilitate use, the graphical syntax is identical among the three models.^[1]

IDEF4 provides a broad range of design features – from generic to specific. This range enables deferred decision making by allowing the designer to first capture design features in general terms and later to refine them. This significantly reduces the burden on designers by allowing them to immediately capture new design concepts with IDEF4 design features, even if these design concepts have not yet been explored in detail.^[1]

• Thomas M. Blinn (1989). IDEF3 and IDEF4 Automation System Requirements Documents and System Environment Models: An Interim Technical Report. National Technical Information Service.
• Patricia Griffith Friel and Thomas M. Blinn (1989). "Automated IDEF3 and IDEF4 Systems Design Specification Document". Technical report. NASA Johnson Space Center.
• Richard J. Mayer, Douglas D Edwards (1990). IDEF4 Technical Report, Version 1.0. NASA* Richard J. Mayer, Douglas D. Edwards (1990). IDEF4 Formalization Report, Version 1.0. NASA
• Richard J. Mayer, et al. (1992). IDEF4 Method Report. Wright-Patterson Air Force Base, Ohio 45433-7604. May 2002.
• Richard J. Mayer et al. (1995). IDEF4 Object-Oriented Design Method Report Version 2.0. Jan 1995.

• IDEF4 Overview Archived 2016-02-27 at the Wayback Machine