HOME

TheInfoList



OR:

IDEF4, or ''Integrated DEFinition for Object-Oriented Design'', is an
object-oriented design 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. Overview An object contains encapsulated data and procedures grouped t ...
modeling language 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 st ...
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. Richard J. Mayer et al. (1995)
'' IDEF4 Object-Oriented Design Method Report ''
Version 2.0. Jan 1995.
This method is part of the
IDEF IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition,IEEE Standard for Functional Modeling Language—Syntax and Semantics for IDEF0, Software Engineering Standards Committee of the IEEE Computer Soci ...
family of
modeling language 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 st ...
s in the field of
systems A system is a group of interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure and purpose and express ...
and
software engineering Software engineering is a systematic engineering approach to software development. A software engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term '' ...
.


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.Patricia Griffith Friel and Thomas M. Blinn (1989)
"Automated IDEF3 and IDEF4 Systems Design Specification Document"
Technical report. NASA Johnson Space Center.
The IDEF4 method multi-dimensional approach to object-oriented software system design consists of the following items: * 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 A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to th ...
component, and * Design features ranging from general to specific enabling deferred
decision making In psychology, decision-making (also spelled decision making and decisionmaking) is regarded as the cognitive process resulting in the selection of a belief or a course of action among several possible alternative options. It could be either rati ...
.


History

The development of IDEF4 came from the recognition that the modularity, maintainability and code reusability that results from the
object-oriented programming Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or ''properties''), and the code is in the form of pr ...
paradigm can be realized in traditional
data processing Data processing is the collection and manipulation of digital data to produce meaningful information. Data processing is a form of ''information processing'', which is the modification (processing) of information in any manner detectable by an ...
applications. The proven ability of the object-oriented programming paradigm to support data level integration in large complex
distributed system A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system. Distributed computing is a field of computer sci ...
s is also a major factor in the widespread interest in this technology from the traditional data processing community. IDEF4 was developed as a design tool for software designers who use object-oriented languages such as the
Common Lisp Object System The Common Lisp Object System (CLOS) is the facility for object-oriented programming which is part of ANSI Common Lisp. CLOS is a powerful dynamic object system which differs radically from the OOP facilities found in more static languages such as ...
,
Flavors Flavor or flavour is either the sensory perception of taste or smell, or a flavoring in food that produces such perception. Flavor or flavour may also refer to: Science *Flavors (programming language), an early object-oriented extension to Lis ...
,
Smalltalk Smalltalk is an object-oriented, dynamically typed reflective programming language. It was designed and created in part for educational use, specifically for constructionist learning, at the Learning Research Group (LRG) of Xerox PARC by Alan Ka ...
,
Objective-C Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. Originally developed by Brad Cox and Tom Love in the early 1980s, it was selected by NeXT for its NeXTS ...
,
C++ C++ (pronounced "C plus plus") is a high-level general-purpose programming language created by Danish computer scientist Bjarne Stroustrup as an extension of the C programming language, or "C with Classes". The language has expanded significan ...
and others. Since effective usage of the object-oriented paradigm requires a different thought process than used with conventional procedural or
database language In computing, a database is an organized collection of data stored and accessed electronically. Small databases can be stored on a file system, while large databases are hosted on computer clusters or cloud storage. The design of databases span ...
s, standard methodologies such as
structure chart A structure chart (SC) in software engineering and organizational theory is a chart which shows the breakdown of a system to its lowest manageable levels.IRS (2008) "Configuration Management" In: ''IRS Resources Part 2. Information Technology Chap ...
s,
data flow diagram A data-flow diagram is a way of representing a flow of data through a process or a system (usually an information system). The DFD also provides information about the outputs and inputs of each entity and the process itself. A data-flow diagram ha ...
s, 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.


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 and Schlaer/ Mellor’s Object-Oriented Analysis and Design (OOA/OOD) technique. 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 A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to th ...
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. 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 A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to th ...
component are built for the low-level design objects. Sub-layers may be built within each layer to reduce complexity. 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 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.


IDEF4 Object-oriented Concepts

IDEF4’s defines a set of object oriented concepts: * ''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 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 ...
,
IDEF5 IDEF5 (''Integrated Definition for Ontology Description Capture Method'') is a software engineering method to develop and maintain usable, accurate domain ontologies.Perakath C. Benjamin et al. (1994)''IDEF5 Method Report''. Knowledge Based System ...
,
IDEF3 IDEF3 or Integrated DEFinition for Process Description Capture Method is a business process modelling method complementary to IDEF0.Richard J. Mayer et al. (1993Information Integration for Concurrent Engineering (IICE): IDEF3 Process Description C ...
, SA/SD can be used to perform domain analysis.
Edward Yourdon Edward Nash Yourdon (April 30, 1944 – January 20, 2016) was an American software engineer, computer consultant, author and lecturer, and software engineering methodology pioneer. He was one of the lead developers of the structured analysis tec ...
, and
Larry Constantine Larry LeRoy Constantine (born 1943) is an American software engineer, professor in the Center for Exact Sciences and Engineering at the University of Madeira Portugal, and considered one of the pioneers of computing. He has contributed numerous c ...
(1979). ''Structured design: Fundamentals of a discipline of computer program and systems design''. Englewood Cliffs, NJ: Prentice-Hall.
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: * ''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: # 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.


IDEF4 Design Models

IDEF4 uses three design models and a design rationale component: * 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.


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.


References


Further reading

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


External links



{{Webarchive, url=https://web.archive.org/web/20160227141819/http://www.idef.com/IDEF4.htm , date=2016-02-27 at idef.com333 Object-oriented programming Systems engineering