IDEF4

Dimensions of IDEF4 Design Objects.

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]

IDEF4 Design Activities.

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 five types of Object classes in IDEF4.

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]

Organization of the IDEF4 model.

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]