IDEF3

Last updated January 15, 2023

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

Overview

One of the primary mechanisms used for descriptions of the world is relating a story in terms of an ordered sequence of events or activities. The IDEF3 Process Description Capture Method was created to capture descriptions of sequences of activities, which is considered the common mechanisms to describe a situation or process. The primary goal of IDEF3 is to provide a structured method by which a domain expert can express knowledge about the operation of a particular system or organization. Knowledge acquisition is enabled by direct capture of assertions about real-world processes and events in a form that is most natural for capture. IDEF3 supports this kind of knowledge acquisition by providing a reliable and wellstructured approach for process knowledge acquisition, and an expressively, yet easy-to-use, language for information capture and expression.^[1]

Motives for the development of IDEF3 were the need:^[1]

to speed up the process of business systems modeling,
to provides mechanisms to describe this data life cycle information,
to supported project management techniques by an automated tool,
to provide the concepts, syntax, and procedures for building system requirements descriptions, and
to work well both independently and jointly with other methods which address different areas of concentration (e.g., the IDEF0 Function Modeling method) as a complementary addition to the IDEF method family.

History

The original IDEFs were developed since the mid-1970s for the purpose of enhancing communication among people who needed to decide how their existing systems were to be integrated. IDEF0 was designed to allow a graceful expansion of the description of a systems' functions through the process of function decomposition and categorization of the relations between functions (i.e., in terms of the Input, Output, Control, and Mechanism classification). IDEF1 was designed to allow the description of the information that an organization deems important to manage in order to accomplish its objectives.^[2]

The third IDEF (IDEF2) was originally intended as a user interface modeling method. However, since the Integrated Computer-Aided Manufacturing (ICAM) Program needed a simulation modeling tool, the resulting IDEF2 was a method for representing the time varying behavior of resources in a manufacturing system, providing a framework for specification of math model based simulations. It was the intent of the methodology program within ICAM to rectify this situation but limitation of funding did not allow this to happen. As a result, the lack of a method which would support the structuring of descriptions of the user view of a system has been a major shortcoming of the IDEF system. The basic problem from a methodology point of view is the need to distinguish between a description of what a system (existing or proposed) is supposed to do and a representative simulation model that will predict what a system will do. The latter was the focus of IDEF2, the former is the focus of IDEF3.^[2]

IDEF3 basic concepts

Descriptions and models

The distinction between descriptions and models, though subtle, is an important one in IDEF3, and both have a precise technical meaning.^[1]

The term description is used as a reserved technical term to mean records of empirical observations; that is, descriptions record knowledge that originates in or is based on observations or experience.
The term model is used to mean an idealization of an entity or state of affairs. That is, a model constitutes an idealized system of objects, properties, and relations that is designed to imitate, in certain relevant respects, the character of a given real-world system. Frictionless planes, perfectly rigid bodies, the assumption of point mass, and so forth are representative examples of models.

The power of a model comes from its ability to simplify the real-world system it represents and to predict certain facts about that system by virtue of corresponding facts within the model. Thus, a model is a designed system in its own right. Models are idealized systems known to be incorrect but assumed to be close enough to provide reliable predictors for the predefined areas of interest within a domain. A description, on the other hand, is a recording of facts or beliefs about something within the realm of an individual’s knowledge or experience. Such descriptions are generally incomplete; that is, the person giving a description may omit facts that he or she believes are irrelevant, or which were forgotten in the course of describing the system. Descriptions may also be inconsistent with respect to how others have observed situations within the domain. IDEF3 accommodates these possibilities by providing specific features enabling the capture and organization of alternative descriptions of the same scenario or process, see figure.^[1]

Description capture

Modeling necessitates taking additional steps beyond description capture to resolve conflicting or inconsistent views. This, in turn, generally requires modelers to select or create a single viewpoint and introduce artificial modeling approximations to fill in gaps where no direct knowledge or experience is available. Unlike models, descriptions are not constrained by idealized, testable conditions that must be satisfied, short of simple accuracy.^[1]

The purpose of description capture may be simply to record and communicate process knowledge or to identify inconsistencies in the way people understand how key processes actually operate. By using a description capture method users need not learn and apply conventions forcing them to produce executable models (e.g., conventions ensuring accuracy, internal consistency, logical coherence, non-redundancy, completeness). Forcing users to model requires them to adopt a model design perspective and risk producing models that do not accurately capture their empirical knowledge of the domain.^[1]

Scenarios

The notion of a scenario or story is used as the basic organizing structure for IDEF3 Process Descriptions. A scenario can be thought of as a recurring situation, a set of situations that describe a typical class of problems addressed by an organization or system, or the setting within which a process occurs. Scenarios establish the focus and boundary conditions of a description. Using scenarios in this way exploits the tendency of humans to describe what they know in terms of an ordered sequence of activities within the context of a given scenario or situation. Scenarios also provide a convenient vehicle to organize collections of process-centered knowledge.^[1]

Process-Centered Views

IDEF3 Process Schematics are the primary means for capturing, managing, and displaying process-centered knowledge. These schematics provide a graphical medium that helps domain experts and analysts from different application areas communicate knowledge about processes. This includes knowledge about events and activities, the objects that participate in those occurrences, and the constraining relations that govern the behavior of an occurrence.^[1]

Object-Centered Views

IDEF3 Object Schematics capture, manage, and display object-centered descriptions of a process—that is, information about how objects of various kinds are transformed into other kinds of things through a process, how objects of a given kind change states through a process, or context-setting information about important relations among objects in a process.^[1]

IDEF3 process description language

IDEF3 descriptions are developed from two different perspectives: process-centered and object-centered. Because these approaches are not mutually exclusive, IDEF3 allows cross-referencing between them to represent complex process descriptions.^[1]

Process Schematics

Process schematics tend to be the most familiar and broadly used component of the IDEF3 method. These schematics provide a visualization mechanism for process-centered descriptions of a scenario. The graphical elements that comprise process schematics include Unit of Behavior (UOB) boxes, precedence links, junctions, referents, and notes. The building blocks here are:^[1]

Unit of Behavior (UOB) boxes
Links : Links are the glue that connect UOB boxes to form representations of dynamic processes.
Simple Precedence Links : Precedence links express temporal precedence relations between instances of one UOB and those of another.
Activation Plots : Activation plots are used to represent activations.
Dashed Links : Dashed links carry no predefined semantics.
Link Numbers : All links have an elaboration and unique link numbers.
Activation Semantics for Nonbranching Process Schematics.
Junctions : Junctions in IDEF3 provide a mechanism to specify the logic of process branching.
UOB Decompositions : Elaborations capture and structure detailed knowledge about processes.
UOB Reference Numbering Scheme : A UOB box number is assigned to each UOB box in an IDEF3 Process Description.
Partial Descriptions : UOB boxes are joined together by links. Since the description capture is the focus of IDEF3, it is possible to conceive of UOBs without links to other parts of an IDEF3 schematic.
Referents : Referents enhance understanding, provide additional meaning, and simplify the construction (i.e., minimize clutter) of both process schematics and object schematics.

Object Schematics

IDEF offers a series of building blocks to express detailed object-centered process information; that is, information about how objects of various kinds are transformed into other kinds of things through a process, or how objects of a given kind change states through a process.^[1]

Objects : An object of a certain kind, like a chassis, will be represented simply by a circle containing an appropriate label.
Object States : A certain kind of object being in a certain state will be represented by a circle with a label that captures the kind itself and a corresponding state, representing thereby the type, or class, of objects that are in that state.
Object schematics : The construction of complex representations built from kind symbols and object state symbols.
Transition Schematics : The first and most basic construct is the basic state transition schematic or simply, transition schematic.

Related Research Articles

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.

<span class="mw-page-title-main">Business process modeling</span> Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

ISO 10303 is an ISO standard for the computer-interpretable representation and exchange of product manufacturing information. It is an ASCII-based format. Its official title is: Automation systems and integration — Product data representation and exchange. It is known informally as "STEP", which stands for "Standard for the Exchange of Product model data". ISO 10303 can represent 3D objects in Computer-aided design (CAD) and related information.

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.

IDEF0, a compound acronym, is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, reengineering and integration of information systems, business processes or software engineering analysis.

A conceptual model is a representation of a system. It consists of concepts used to help people know, understand, or simulate a subject the model represents. In contrast, physical models are physical object such as a toy model that may be assembled and made to work like the object it represents.

Integration DEFinition for information modeling (IDEF1X) is a data modeling language for the development of semantic data models. IDEF1X is used to produce a graphical information model which represents the structure and semantics of information within an environment or system.

Scientific modelling is a scientific activity, the aim of which is to make a particular part or feature of the world easier to understand, define, quantify, visualize, or simulate by referencing it to existing and usually commonly accepted knowledge. It requires selecting and identifying relevant aspects of a situation in the real world and then developing a model to replicate a system with those features. Different types of models may be used for different purposes, such as conceptual models to better understand, operational models to operationalize, mathematical models to quantify, computational models to simulate, and graphical models to visualize the subject.

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.

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.

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.

IDEF5 is a software engineering method to develop and maintain usable, accurate domain ontologies. This standard is part of the IDEF family of modeling languages in the field of software engineering.

Enterprise engineering is the body of knowledge, principles, and practices used to design all or part of an enterprise. An enterprise is a complex socio-technical system that comprises people, information, and technology that interact with each other and their environment in support of a common mission. One definition is: "an enterprise life-cycle oriented discipline for the identification, design, and implementation of enterprises and their continuous evolution", supported by enterprise modelling. The discipline examines each aspect of the enterprise, including business processes, information flows, material flows, and organizational structure. Enterprise engineering may focus on the design of the enterprise as a whole, or on the design and integration of certain business components.

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.

Method engineering in the "field of information systems is the discipline to construct new methods from existing methods". It focuses on "the design, construction and evaluation of methods, techniques and support tools for information systems development".

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.

References

1 2 3 4 5 6 7 8 9 10 11 12 13 Richard J. Mayer et al. (1993) Information Integration for Concurrent Engineering (IICE): IDEF3 Process Description Capture Method Report. Logistics Research Division, Wright-Patterson AFB, OH 45433
1 2 3 4 Patricia Griffith Friel and Thomas M. Blinn (1989). "Automated IDEF3 and IDEF4 Systems Design Specification Document". Technical report. NASA Johnson Space Center.

External links

Overview of IDEF3 Archived 2010-04-25 at the Wayback Machine at www.idef.com

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.

[May03-1] 1 2 3 4 5 6 7 8 9 10 11 12 13 Richard J. Mayer et al. (1993) Information Integration for Concurrent Engineering (IICE): IDEF3 Process Description Capture Method Report. Logistics Research Division, Wright-Patterson AFB, OH 45433

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

[1]

[2]