Editing IDEF

{{Short description|Family of modeling languages}}
{{For|the defense fair|International Defence Industry Fair}}

[[Image:IDEF Methods.svg|thumb|320px|IDEF methods: part of the systems engineer's toolbox]]

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

The most-widely recognized and used components of the IDEF family are IDEF0, a functional modeling language building on SADT, and IDEF1X, which addresses information models and database design issues.

== Overview of IDEF methods ==
IDEF refers to a family of [[modeling language]], which cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. Eventually the IDEF methods have been defined up to IDEF14:  
* [[IDEF0]]: Function modeling<ref>[http://www.idef.com/IDEF0.htm IDEFØ Overview] {{Webarchive|url=https://web.archive.org/web/20160305001934/http://www.idef.com/IDEF0.htm |date=2016-03-05 }} at idef.com</ref>
* [[IDEF1X#History|IDEF1]]: Information modeling<ref>[http://www.idef.com/IDEF1.htm IDEF1 Overview] {{Webarchive|url=https://web.archive.org/web/20160303225827/http://www.idef.com/IDEF1.htm |date=2016-03-03 }} at idef.com</ref>
* [[IDEF1X]]: Data modeling<ref>[http://www.idef.com/IDEF1x.htm IDEF1x Overview] {{Webarchive|url=https://web.archive.org/web/20160308075846/http://www.idef.com/idef1X.htm |date=2016-03-08 }} at idef.com</ref>
* [[IDEF2]]: Simulation model design
* [[IDEF3]]: Process description capture<ref>[http://www.idef.com/IDEF3.htm IDEF3 Overview] {{Webarchive|url=https://web.archive.org/web/20100425012200/http://www.idef.com/IDEF3.htm |date=2010-04-25 }} at idef.com</ref>
* [[IDEF4]]: Object-oriented design<ref>[http://www.idef.com/IDEF4.htm IDEF4 Overview] {{Webarchive|url=https://web.archive.org/web/20160227141819/http://www.idef.com/IDEF4.htm |date=2016-02-27 }} at idef.com</ref>
* [[IDEF5]]: Ontology description capture<ref>[http://www.idef.com/IDEF5.htm IDEF5 Overview] {{Webarchive|url=https://web.archive.org/web/20160303225811/http://www.idef.com/IDEF5.htm |date=2016-03-03 }} at idef.com</ref>
* [[IDEF6]]: Design rationale capture<ref name= "MGM90"/>
* IDEF7: Information system auditing
* [[IDEF8]]: User interface modeling
* [[IDEF9]]: Business constraint discovery
* IDEF10: Implementation architecture modeling
* IDEF11: Information artifact modeling
* IDEF12: Organization modeling
* IDEF13: Three-schema mapping design
* [[IDEF14]]: Network design

In 1995 only the [[IDEF0]], [[IDEF1X]], [[IDEF2]], [[IDEF3]] and [[IDEF4]] had been developed in full.<ref>Robert P. Hanrahan [http://www.stsc.hill.af.mil/crosstalk/1995/06/IDEF.asp The IDEF Process Modeling Methodology] {{webarchive|url=https://web.archive.org/web/20070126094915/http://www.stsc.hill.af.mil/crosstalk/1995/06/IDEF.asp |date=2007-01-26 }}. Software Technology Support Center. 1995</ref> Some of the other IDEF concepts had some preliminary design. Some of the last efforts were new IDEF developments in 1995 toward establishing reliable methods for business constraint discovery [[IDEF9]], design rationale capture [[IDEF6]], human system, interaction design [[IDEF8]], and network design [[IDEF14]].<ref name="May05">[[Richard J. Mayer]] (1995) et al. [http://www.idef.com/pdf/compendium.pdf Information Integration for Concurrent Engineering (IICE) Compendium of methods report] {{Webarchive|url=https://web.archive.org/web/20070711223834/http://www.idef.com/pdf/compendium.pdf |date=2007-07-11 }}. Wright-Patterson Air Force Base, Ohio 45433-7604.</ref>

The methods IDEF7, IDEF10, IDEF11, IDEF 12 and IDEF13 haven't been developed any further than their initial definition.<ref>[http://it.toolbox.com/blogs/enterprise-solutions/idef-standards-overview-18730 Observations from a Tech Architect: Enterprise Implementation Issues & Solutions] Craig Borysowich. Accessed 20 Jan 2009.</ref>

== History ==
IDEF originally stood for [[Integrated Computer-Aided Manufacturing|ICAM]] Definition, initiated in the 1970s at the US Air Force Materials Laboratory, [[Wright-Patterson Air Force Base]] in Ohio by [[Dennis E. Wisnosky]], Dan L. Shunk, and others.<ref name="Sav96">Charles M. Savage (1996). ''Fifth Generation Management: Co-creating Through Virtual Enterprising, Dynamic Teaming, and Knowledge Networking'' Butterworth-Heinemann, 1996. {{ISBN|0-7506-9701-6}}. p. 184.</ref> and completed in the 1980s. IDEF was a product of the ICAM initiative of the [[United States Air Force]]. The [[Institute of Electrical and Electronics Engineers|IEEE]] recast the IDEF abbreviation as Integration Definition."<ref name="IEEE IDEF Ref">IEEE Standard for Functional Modeling Language—Syntax and Semantics for IDEF0, Software Engineering Standards Committee of the IEEE Computer Society, IEEE-SA Standards Board, The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA, [https://web.archive.org/web/20130509181157/http://standards.ieee.org/findstds/standard/1320.1-1998.html IEEE Std 1320.1-1998], 25 June 1998</ref>

The specific projects that produced IDEF were ICAM project priorities 111 and 112 (later renumbered 1102). The subsequent Integrated Information Support System (IISS) project priorities 6201, 6202, and 6203 attempted to create an [[Data processing|information processing]] environment that could be run in [[heterogeneous]] physical computing environments. Further development of IDEF occurred under those projects as a result of the experience gained from applications of the new modeling techniques. The intent of the IISS efforts was to create 'generic subsystems' that could be used by a large number of collaborating enterprises, such as U.S. [[defense contractor]]s and the armed forces of friendly nations.

At the time of the ICAM 1102 effort there were numerous, mostly incompatible, [[data model]] methods for storing computer data &mdash; [[Sequential access|sequential]] ([[VSAM]]), [[Hierarchical model|hierarchical]] ([[Information Management System|IMS]]), [[Network model|network]] ([[Cincom]]'s TOTAL and [[CODASYL]], and [[Cullinet]]'s [[IDMS]]). The [[relational data model]] was just emerging as a promising way of thinking about structuring data for easy, efficient, and accurate access. [[Relational database management system]]s had not yet emerged as a general standard for data management.

The ICAM program office deemed it valuable to create a "neutral" way of describing the data content of large-scale systems. The emerging academic literature suggested that methods were needed to process [[Data independence|data independently]] of the way it was [[data structure|physically stored]]. Thus the IDEF1 language was created to allow a neutral description of data structures that could be applied regardless of the storage method or file access method.

IDEF1 was developed under ICAM program priority 1102 by Robert R. Brown of the [[Hughes Aircraft Company]], under contract to [[SofTech, Inc.]] Brown had previously been responsible for the development of [[Information Management System|IMS]] while working at [[Rockwell International]]. Rockwell chose not to pursue IMS as a marketable product but [[International Business Machines|IBM]], which had served as a support contractor during development, subsequently took over the product and was successful in further developing it for market. Brown credits his Hughes colleague Timothy Ramey as the inventor of IDEF1 as a viable formalism for modeling information structures. The two Hughes researchers built on ideas from and interactions with many luminaries in the field at the time. In particular, IDEF1 draws on the following techniques:
* the evolving natural language information model ([[NIAM|ENALIM]]) technique of [[G. M. Nijssen]] ([[Control Data Corporation]]) — this technique is now more widely known as [[NIAM]] or the object–role model [[object–role modeling|ORM]];
* the network data structures technique, popularly called the [[CODASYL]] approach, of [[Charles Bachman]] ([[Honeywell Information Systems]]);
* the hierarchical data management technique, implemented in IBM's IMS data management system, developed by [[R. R. Brown]] ([[Rockwell International]]);
* the relational approach to data of [[E. F. Codd]] ([[IBM]]);
* The [[entity–relationship model|entity–relationship approach]] (E–R) of [[Peter Chen]] ([[UCLA]]).
The effort to develop IDEF1 resulted in both a new method for information modeling and an example of its use in the form of a "reference information model of manufacturing." This latter artifact was developed by D. S. Coleman of the D. Appleton Company (DACOM) acting as a sub-contractor to Hughes and under the direction of Ramey. Personnel at DACOM became expert at IDEF1 modeling and subsequently produced a training course and accompanying materials for the IDEF1 modeling technique.

Experience with IDEF1 revealed that the translation of information requirements into database designs was more difficult than had originally been anticipated. The most beneficial value of the IDEF1 information modeling technique was its ability to represent data independent of how those data were to be stored and used. It provided data modelers and data analysts with a way to represent data requirements during the requirements-gathering process. This allowed designers to decide which DBMS to use after the nature of the data requirements was understood and thus reduced the "misfit" between data requirements and the capabilities and limitations of the DBMS. The translation of IDEF1 models to database designs, however, proved to be difficult.

== The IDEF modeling languages ==

=== IDEF0 ===
{{main|IDEF0}}
[[Image:IDEF Diagram Example.jpg|280px|thumb|Example of an [[IDEF0]] diagram: a [[function model]] of the process of maintaining reparable spares]]

The IDEF0 functional modeling method is designed to model the decisions, actions, and activities of an organization or system.<ref name = "VG00">Varun Grover, William J. Kettinger (2000). ''Process Think: Winning Perspectives for Business Change in the Information Age''. p. 168.</ref> It was derived from the established graphic modeling language [[Structured Analysis and Design Technique|structured analysis and design technique]] (SADT) developed by [[Douglas T. Ross]] and [[SofTech, Inc.]] In its original form, IDEF0 includes both a definition of a graphical modeling language ([[syntax]] and [[semantics]]) and a description of a comprehensive methodology for developing models.<ref name= "ITL93">[http://www.itl.nist.gov/fipspubs/idef02.doc FIPS Publication 183] {{Webarchive|url=https://web.archive.org/web/20090227122140/http://www.itl.nist.gov/fipspubs/idef02.doc |date=2009-02-27 }} released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).</ref> The US Air Force commissioned the SADT developers to develop a [[function model]] method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.<ref name = "VG00"/>

=== IDEF1X ===
{{main|IDEF1X}}
[[Image:B 5 1 IDEF1X Diagram.jpg|thumb|left|210px|Example of an [[IDEF1X]] diagram]]

To satisfy the [[data modeling]] enhancement requirements that were identified in the IISS-6202 project, a sub-contractor, [[DACOM]], obtained a license to the [[logical database design technique]] (LDDT) and its supporting software (ADAM). LDDT had been developed in 1982 by Robert G. Brown of The Database Design Group entirely outside the IDEF program and with no knowledge of IDEF1. LDDT combined elements of the relational data model, the E–R model, and generalization in a way specifically intended to support data modeling and the transformation of the data models into database designs. The graphic syntax of LDDT differed from that of IDEF1 and, more importantly, LDDT contained interrelated modeling concepts not present in IDEF1. Mary E. Loomis wrote a concise summary of the syntax and semantics of a substantial subset of LDDT, using terminology compatible with IDEF1 wherever possible. DACOM labeled the result [[IDEF1X]] and supplied it to the ICAM program.<ref>IEEE (1998). ''IEEE Std 1320.2-1998. IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X''. New York. p. iii.</ref><ref>Bruce, Thomas A. (1992), Designing Quality Databases with IDEF1X Information Models, {{ISBN|0-932633-18-8}} p=xii</ref>

Because the IDEF program was funded by the government, the techniques are in the [[public domain]]. In addition to the ADAM software, sold by DACOM under the name Leverage, a number of [[Computer-aided software engineering|CASE]] tools use [[IDEF1X]] as their representation technique for data modeling.

The IISS projects actually produced working prototypes of an information processing environment that would run in heterogeneous computing environments. Current advancements in such techniques as [[Java (programming language)|Java]] and [[JDBC]] are now achieving the goals of ubiquity and versatility across computing environments which was first demonstrated by IISS.

=== IDEF2 and IDEF3 ===
{{main|IDEF3}}
[[File:2-03 Example of an Enhanced Transition Schematic.jpg|thumb|240px|Example of an enhanced transition schematic, modelled with [[IDEF3]]]]

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 [[Integrated Computer-Aided Manufacturing|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 predicts what a system will do. The latter was the focus of [[IDEF2]], the former is the focus of [[IDEF3]].<ref name="FB89">Patricia Griffith Friel and Thomas M. Blinn (1989). [https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19910023489_1991023489.pdf "Automated IDEF3 and IDEF4 Systems Design Specification Document"]. Technical report. NASA Johnson Space Center.</ref>

=== IDEF4 ===
{{main|IDEF4}}
[[File:118 The Behavior Diagram for methods Implementing Louder.jpg|thumb|left|210px|[[IDEF4]] behavior diagram]]

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 system]]s is also a major factor in the widespread interest in this technology from the traditional data processing community.<ref name="FB89"/>

[[IDEF4]] was developed as a design tool for software designers who use object-oriented languages such as the [[Common Lisp Object System]], [[Flavors (programming language)|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 language]]s, standard methodologies such as [[structure chart]]s, [[data flow diagram]]s, and traditional [[database model|data design model]]s (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process.<ref name="FB89"/>

=== IDEF5 ===
{{main|IDEF5}}
[[Image:4-54 Composition Schematic for Ballpoint.jpg|thumb|240px|Example of an [[IDEF5]] composition schematic for a ballpoint pen]]

[[IDEF5]], or integrated definition for ontology description capture method, is a software engineering method to develop and maintain usable, accurate, domain [[ontology (computer science)|ontologies]].<ref name="PCB94">Perakath C. Benjamin et al. (1994). [http://www.idef.com/pdf/Idef5.pdf ''IDEF5 Method Report''] {{Webarchive|url=https://web.archive.org/web/20081221091108/http://www.idef.com/pdf/Idef5.pdf |date=2008-12-21 }}. Knowledge Based Systems, Inc.</ref> In the field of computer science ontologies are used to capture the [[concept and object]]s in a specific [[Domain analysis|domain]], along with associated relationships and meanings. In addition, ontology capture helps coordinate projects by standardizing [[terminology]] and creates opportunities for [[information]] reuse. The IDEF5 Ontology Capture Method has been developed to reliably construct ontologies in a way that closely reflects human [[understanding]] of the specific domain.<ref name="PCB94"/>

In the IDEF5 method, an ontology is constructed by capturing the content of certain assertions about real-world objects, their properties and their interrelationships, and representing that content in an intuitive and natural form. The IDEF5 method has three main components: A graphical language to support conceptual ontology analysis, a structured text language for detailed ontology characterization, and a systematic procedure that provides guidelines for effective ontology capture.<ref name=autogenerated1>Varun Grover, William J. Kettinger (2000). ''Process Think: Winning Perspectives for Business Change in the Information Age''. p.176-178</ref>

=== IDEF6 ===
{{main|IDEF6}}
[[File:IIDEF4 Design Activities.jpg|thumb|210px|left|IDEF6 model of IDEF4 design activities]]

[[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]]. 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 (i.e. on the final product, rather than why the design is the way it is).<ref name="May05"/>

IDEF6 is a method that possesses the conceptual resources and linguistic capabilities needed
# to represent the nature and structure of the information that constitutes design rationale within a given system, and
# to associate that rationale with design specifications, models, and documentation for the system.
IDEF6 is applicable to all phases of the information system development process, from initial conceptualization through both preliminary and detailed design activities. To the extent that detailed design decisions for software systems are relegated to the coding phase, the IDEF6 technique should be usable during the software construction process as well.<ref name= "MGM90">[[Richard J. Mayer|Mayer, Richard J.]]; Griffith, Patricia A.; Menzel, Christopher P. (1990-91) [http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA261594 "IDEF6: A Design Rationale Capture Method Concept Paper"] {{Webarchive|url=https://web.archive.org/web/20070402035120/http://stinet.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=ADA261594 |date=2007-04-02 }} Defense Technical Information Center</ref>

=== IDEF8 ===
IDEF8, or integrated definition for human-system interaction design, is a method for producing high-quality designs of interactions between users and the systems they operate. Systems are characterized as a collection of objects that perform functions to accomplish a particular goal. The system with which the user interacts can be any system, not necessarily a computer program. Human-system interactions are designed at three levels of specification within the IDEF8 method. The first level defines the philosophy of system operation and produces a set of models and textual descriptions of overall system processes. The second level of design specifies role-centered scenarios of system use. The third level of IDEF8 design is for human-system design detailing. At this level of design, IDEF8 provides a library of metaphors to help users and designers specify the desired behavior in terms of other objects whose behavior is more familiar. Metaphors provide a model of abstract concepts in terms of familiar, concrete objects and experiences.<ref name="May05"/>

=== IDEF9 ===
[[File:Typical business systems.jpg|thumb|320px|Typical business systems]]

IDEF9, or integrated definition for business constraint discovery, is designed to assist in the discovery and analysis of constraints in a [[business system]]. A primary motivation driving the development of IDEF9 was an acknowledgment that the collection of constraints that forge an enterprise system is generally poorly defined. The knowledge of what constraints exist and how those constraints interact is incomplete, disjoint, distributed, and often completely unknown. Just as living organisms do not need to be aware of the genetic or autonomous constraints that govern certain behaviors, organizations can (and most do) perform well without explicit knowledge of the glue that structures the system. In order to modify business in a predictable manner, however, the knowledge of these constraints is as critical as knowledge of genetics is to the genetic engineer.<ref name="May05"/>

=== IDEF14 ===
IDEF14, or integrated definition for network design method, is a method that targets the modeling and design of [[computer network|computer]] and [[communication network]]s. It can be used to model existing ("as is") or envisioned ("to be") networks. It helps the network designer to investigate potential network designs and to document design rationale. The fundamental goals of the IDEF14 research project developed from a perceived need for good network designs that can be implemented quickly and accurately.<ref name="May05"/>

== References ==
{{NIST-PD}}
{{reflist}}

== Further reading ==
* Ovidiu S. Noran (2000). [http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf Business Modelling: UML vs. IDEF] {{Webarchive|url=https://web.archive.org/web/20060113085843/http://www.cit.gu.edu.au/~noran/Docs/UMLvsIDEF.pdf |date=2006-01-13 }} Paper Griffith University

==External links==
{{Commons category|IDEF}}
* [http://www.idef.com Integrated DEFinition Methods]
* [https://web.archive.org/web/20070622145629/https://idbms.navo.navy.mil/DataModel/IDEF1X.html Data Modeling]
* [https://web.archive.org/web/20070126094915/http://www.stsc.hill.af.mil/crosstalk/1995/06/IDEF.asp The IDEF Process Modeling Methodology] by Robert P. Hanrahan 1995

{{Software engineering}}

[[Category:Data modeling]]
[[Category:Standards]]
[[Category:Systems engineering]]
[[Category:Modeling languages]]