IDEF4

Last updated January 15, 2023

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]

Overview

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 his 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.

History

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 concepts

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.

IDEF4 Design Activities

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 re-partitioning 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 Object-oriented Concepts

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 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.

Object Class Identification

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
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 Building blocks

IDEF4 Layers

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

system design,
application design, and
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 Artifact Status

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 Design Models

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]

Design Features

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]

Related Research Articles

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state and implementations of behavior. In many languages, the class name is used as the name for the class, the name for the default constructor of the class, and as the type of objects generated by instantiating the class; these distinct concepts are easily conflated. Although, to the point of conflation, one could argue that is a feature inherent in a language because of its polymorphic nature and why these languages are so powerful, dynamic and adaptable for use compared to languages without polymorphism present. Thus they can model dynamic systems more easily.

The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.

In software engineering and computer science, abstraction is:

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses from functional modeling to data, simulation, object-oriented analysis and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

A functional software architecture (FSA) is an architectural model that identifies enterprise functions, interactions and corresponding IT needs. These functions can be used as a reference by different domain experts to develop IT-systems as part of a co-operative information-driven enterprise. In this way, both software engineers and enterprise architects can create an information-driven, integrated organizational environment.

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

In object-oriented design, the dependency inversion principle is a specific methodology for loosely coupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

Glossary of Unified Modeling Language (UML) terms provides a compilation of terminology used in all versions of UML, along with their definitions. Any notable distinctions that may exist between versions are noted with the individual entry it applies to.

Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

Knowledge Discovery Metamodel (KDM) is a publicly available specification from the Object Management Group (OMG). KDM is a common intermediate representation for existing software systems and their operating environments, that defines common metadata required for deep semantic integration of Application Lifecycle Management tools. KDM was designed as the OMG's foundation for software modernization, IT portfolio management and software assurance. KDM uses OMG's Meta-Object Facility to define an XMI interchange format between tools that work with existing software as well as an abstract interface (API) for the next-generation assurance and modernization tools. KDM standardizes existing approaches to knowledge discovery in software engineering artifacts, also known as software mining.

ArchiMate is an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

Semantic data model (SDM) is a high-level semantics-based database description and structuring formalism for databases. This database model is designed to capture more of the meaning of an application environment than is possible with contemporary database models. An SDM specification describes a database in terms of the kinds of entities that exist in the application environment, the classifications and groupings of those entities, and the structural interconnections among them. SDM provides a collection of high-level modeling primitives to capture the semantics of an application environment. By accommodating derived information in a database structural specification, SDM allows the same information to be viewed in several ways; this makes it possible to directly accommodate the variety of needs and processing requirements typically present in database applications. The design of the present SDM is based on our experience in using a preliminary version of it. SDM is designed to enhance the effectiveness and usability of database systems. An SDM database description can serve as a formal specification and documentation tool for a database; it can provide a basis for supporting a variety of powerful user interface facilities, it can serve as a conceptual database model in the database design process; and, it can be used as the database model for a new kind of database management system.

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

IDEF3 or Integrated DEFinition for Process Description Capture Method is a business process modelling method complementary to IDEF0. The IDEF3 method is a scenario-driven process flow description capture method intended to capture the knowledge about how a particular system works.

IDEF6 or Integrated Definition for Design Rationale Capture is a method to facilitate the acquisition, representation, and manipulation of the design rationale used in the development of enterprise systems. This method, that wants to define the motives that drive the decision-making process, is still in development. Rationale is the reason, justification, underlying motivation, or excuse that moved the designer to select a particular strategy or design feature. More simply, rationale is interpreted as the answer to the question, “Why is this design being done in this manner?” Most design methods focus on what the design is.

Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are:

<span class="mw-page-title-main">Interaction Flow Modeling Language</span>

The Interaction Flow Modeling Language (IFML) is a standardized modeling language in the field of software engineering. IFML includes a set of graphic notations to create visual models of user interactions and front-end behavior in software systems.

The composition filters model denotes a modular extension to the conventional object model. It provides a solution for a wide range of problems in the construction of large and complex applications. Most notably, one implementation of composition filters provides an abstraction layer for message-passing systems.

References

1 2 3 4 5 6 7 8 9 10 11 12 Richard J. Mayer et al. (1995). IDEF4 Object-Oriented Design Method Report Version 2.0. Jan 1995.
1 2 3 Patricia Griffith Friel and Thomas M. Blinn (1989). "Automated IDEF3 and IDEF4 Systems Design Specification Document". Technical report. NASA Johnson Space Center.
↑ James Rumbaugh (1991). Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall.
↑ Sally Shlaer and Stephen J. Mellor (1988) Object-Oriented Systems Analysis: Modeling The Real World in Data. Englewood Cliffs, NJ: Prentice Hall.
↑ Ivar Jacobson (1994). Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison-Wesley.
↑ Edward Yourdon, and Larry Constantine (1979). Structured design: Fundamentals of a discipline of computer program and systems design. Englewood Cliffs, NJ: Prentice-Hall.

External links

IDEF4 Overview Archived 2016-02-27 at the Wayback Machine at idef.com333

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[May95-1] 1 2 3 4 5 6 7 8 9 10 11 12 Richard J. Mayer et al. (1995). IDEF4 Object-Oriented Design Method Report Version 2.0. Jan 1995.

[FB89-2] 1 2 3 Patricia Griffith Friel and Thomas M. Blinn (1989). "Automated IDEF3 and IDEF4 Systems Design Specification Document". Technical report. NASA Johnson Space Center.

[3] James Rumbaugh (1991). Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall.

[4] Sally Shlaer and Stephen J. Mellor (1988) Object-Oriented Systems Analysis: Modeling The Real World in Data. Englewood Cliffs, NJ: Prentice Hall.

[5] Ivar Jacobson (1994). Object-Oriented Software Engineering: A Use Case Driven Approach. Reading, MA: Addison-Wesley.

[6] Edward Yourdon, and Larry Constantine (1979). Structured design: Fundamentals of a discipline of computer program and systems design. Englewood Cliffs, NJ: Prentice-Hall.

[1]

[2]

[3]

[4]

[5]

[6]