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]
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:
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]
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]
IDEF4 users design in three distinct layers:[1]
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 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]
