Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC IEEE 31320 — Modeling Languages Standard Series (IDEF0 and IDEF1X97)
Information Technology — Modeling Languages — Part 1: Syntax and Semantics for IDEF0 / Part 2: IDEF1X97 (IDEFobject) (2012 Edition)
🗂️ BS ISO/IEC/IEEE 31320 is a joint ISO, IEC, and IEEE international standard on modeling languages, adopted in the UK by BSI with participation entrusted to Technical Committee IST/15 (Software and systems engineering). The series formally internationalizes the widely used IDEF method family from the U.S. Federal Information Processing Standards (FIPS): Part 1 specifies the syntax and semantics of the IDEF0 function modeling language, and Part 2 specifies the IDEF1X97 (IDEFobject) information modeling language. Both documents were first published in September 2012, with the UK editions issued in 2013 (Part 2 in July, Part 1 in August), classified under ICS 35.080 (Software).
💡 IDEF0 and IDEF1X97 are complementary: IDEF0 answers “what does the system do”, while IDEF1X97 answers “what information must the system store and relate”. They are frequently used together in the same systems-engineering and business-process re-engineering projects.
1. Series Overview and Position 📌
The IDEF (Integration DEFinition) method family originated in the 1970s–1980s under the U.S. Air Force ICAM (Integrated Computer Aided Manufacturing) program and was later published in the FIPS series. With growing demand for international standardization, ISO/IEC JTC 1 collaborated with IEEE to elevate IDEF0 and IDEF1X97 into the tripartite international standard ISO/IEC/IEEE 31320. The series provides a formal, interoperable language specification for function decomposition, business-process modeling, and data modeling in software and systems engineering. The forewords note that the standards were developed through IEEE’s consensus process and approved by the American National Standards Institute (ANSI).
2. Series Structure and Document List 📋
| Standard | Edition | Subject | Model Type |
|---|---|---|---|
| BS ISO/IEC/IEEE 31320-1 | 2012 | Syntax and semantics for IDEF0 | Function modeling |
| BS ISO/IEC/IEEE 31320-2 | 2012 | Syntax and semantics for IDEF1X97 (IDEFobject) | Information / data modeling |
3. Part 1: IDEF0 Function Modeling 🔧
IDEF0 uses the “boxes and arrows” graphic language to describe Activities with their Inputs, Controls, Outputs, and Mechanisms (ICOM). The standard systematically specifies:
- Activity Box: named with a verb phrase, representing the modeled function.
- Input, Control, Output, Mechanism: entering or leaving the box via the left, top, right, and bottom sides respectively.
- Decomposition: a parent activity may be decomposed into child diagrams, forming multi-level A-0 through A-n structures.
- Semantic rules: including boundary arrows, tunnel arrows, ICOM numbering, and diagram numbering conventions.
⚠️ IDEF0 emphasizes that “control differs from input”: controls are conditions constraining how an activity runs (rules, policies, standards), while inputs are objects transformed or consumed. Mixing the two is the most common beginner modeling error.
The standard also specifies presentation details such as box layout, arrow labelling, and page numbering, so models drawn by different people are stylistically consistent and exchangeable.
4. Part 2: IDEF1X97 (IDEFobject) Information Modeling 🔍
IDEF1X (Information Modeling) represents entity–relationship information models; the IDEF1X97 extended version is also called IDEFobject. The standard specifies entities, attributes, primary/foreign keys, relationships, and generalization–specialization concepts together with their graphic notation. It bridges relational database design and object-oriented domain modeling: the notation can be used for logical relational database design and can also guide object-model development.
💡 IDEF1X97’s normalization constraints (such as 1:N and N:M relationships, and classification relationship trees) map directly to SQL DDL statements, and it is the semantic prototype underlying many enterprise data-modeling tools (e.g., ERWin).
5. Engineering Practice 🛠️
- 🔍 Process review and re-engineering: build as-is and to-be function models with IDEF0 to identify redundant activities and bottlenecks.
- 🔧 Requirements analysis: the function model serves as a layered skeleton of the requirements specification, while the information model supports data-requirements definition.
- 📊 Database design: derive a logical data model from IDEF1X97 and map it to implementation-level table structures.
- 📋 Documentation and handover: standardized drawing conventions lower communication costs and facilitate cross-team collaboration and tool exchange.
6. Frequently Asked Questions ❓
❓ Q: What is the difference between IDEF0 and a flowchart?
A: IDEF0 emphasizes system-level function decomposition and ICOM semantics and does not represent chronological order; flowcharts emphasize control flow/sequencing. They address different dimensions and can be chosen or combined as needed.
A: IDEF0 emphasizes system-level function decomposition and ICOM semantics and does not represent chronological order; flowcharts emphasize control flow/sequencing. They address different dimensions and can be chosen or combined as needed.
❓ Q: When should IDEF1X97 be chosen over UML class diagrams?
A: IDEF1X97 is closer to relational data modeling (keys, normalized entity relationships), while UML targets object-oriented implementation. IDEF1X97 suits database-first scenarios.
A: IDEF1X97 is closer to relational data modeling (keys, normalized entity relationships), while UML targets object-oriented implementation. IDEF1X97 suits database-first scenarios.
❓ Q: Is use of the 31320 series affected by patents?
A: The standards are published as open international standards and their notation is freely usable in engineering practice; commercial tool implementations are governed by the vendors’ licenses.
A: The standards are published as open international standards and their notation is freely usable in engineering practice; commercial tool implementations are governed by the vendors’ licenses.
🔍 Q: How deep can an IDEF0 child diagram be decomposed?
A: The standard imposes no hard limit, but recommends 3–6 activities per diagram for readability; deep decomposition should use the numbering scheme (A0, A1, A11, …) to remain traceable.
A: The standard imposes no hard limit, but recommends 3–6 activities per diagram for readability; deep decomposition should use the numbering scheme (A0, A1, A11, …) to remain traceable.