Enterprise Modelling IDEF0

David Chen IMS, University Bordeaux 1

What is IDEF0?
Developed since 1970s USAF (US Air Force) Project ICAM (Integrated Computer Aided Manufacturing) ICAM DEFinition (IDEF): Structured modelling languages Objective: Description of functions of the enterprise with the help of graphical notations. At the origin, IDEF0 was developed to improve the communication between actors trying to understand the system. Today, IDEF0 is used for documentation, understanding, design, analysis, planning, and integration

IDEF
IDEF0 - Functions (WHAT) Question: What I do? IDEF1 - Information (With WHAT) Question: What I need for doing? IDEF3 Process (SEQUENCE) Question: In what order I do?

IDEF0 - Purpose
Answer to three questions : What functions are implemented in the system? What objects are processed by the functions?
=> Object flow between functions

What resources are used by functions ?

IDEF0 characteristics
To provide a modelling language that has the following characteristics: a) Generic (for analysis of systems and subject areas of varying purpose, scope and complexity); b) Rigorous and precise (for production of correct, usable models); c) Concise (to facilitate understanding, communication, consensus and validation); d) Conceptual (for representation of functional requirements independent of physical or organizational implementations); e) Flexible (to support several phases of the life cycle of a project).

BASIC NOTATIONS

Box syntax
Each box corresponds to a function (or activity)

Develop product 1

name of the function: a verb, or a verbal expression, as specific as possible Number of order: chronological number (C-number (1 ... 6), which identifies the box in the diagram

Boxes 1. Boxes shall be sufficient in size to insert box name. 2. Boxes shall be rectangular in shape, with square corners. 3. Boxes shall be drawn with solid lines.

Arrow syntax
Each arrow corresponds to a flow: a physical object, a data (immaterial, independent of its support) a signal (control, trigger) For which the name is indicated in label

or

Arrow positions and roles

-Events triggering function, -Indications on method of execution,

Control(s) (Factors which constraints the function)

Input(s) (object (s) transformed) by the function)

(FUNCTION)

Output(s) (Result(s) provided by the function)

Mechanism (means used by the function)

Call (sub-system used in a non exclusive way, Can not be detailed as a sub-function)

Example

Exercise HAM PIZZA

???

??? ??? ??? ???

Node: A-0 Title: ??? PAGE : 1/1

Exercise HAM PIZZA

Recipe

Make Pizza Ham Pizza Flour Water Ham

Node: A-0 Title:

Oven
Make pizza PAGE : 1/1

IDEF0 Model
An IDEF0 Model is composed of three types of information: Diagrams Text Glossary - Diagrams are cross referenced to each other - Diagrams are main elements of a model

Types of diagrams
Top-level context diagram (A-0) each model shall have a top-level context diagram present the subject of the model by a single box with its bounding arrows Child diagram decompose higher level context diagram into its major sub-functions Parent diagram contains one or more parent boxes Remark: a diagram may be both a parent diagram and a child diagram

IDEF0 Diagram
Example

Optional node tree diagram

Illustration

Optional diagrams of context

High levels of Diagram of context Optional Diagram of context Optional, describe the environment of A-0 Diagram of context Top-model Node A-0 (Mandatory)

IDEF0 Model of a study

Principle Construction Rules

The principles of construction of diagrams :
Each arrow going in or out of its parent box must be found in the child diagram. The arrows have a label indicating their nature. The label can be replaced by a code for which the meaning is given in the text or glossary. The mechanisms can sometime be not mentioned if they are not useful for the understanding of the diagram. In general we only represent the elements that we want to show in the model.

Detail Reference Expression (DRE)

Code written below the lower right corner of a box that points to its child diagram

Diagram Features (1)

Arrows as Constraints
Arrows on an IDEF0 diagram represent data or objects as constraints. Only at low levels of detail can arrows represent flow or sequence,

Diagram Features (2)

Arrows as activations of a Box
an output of one box may provide some or all of the data and objects needed for activations of one or more other boxes.

Remark: Here, we do not precise if the function 2 must be done before the function 3 or inversely

Diagram Features (3)

Arrows as Pipelines
It is useful to think of high-level arrows as pipelines or conduits. Highlevel arrows have general labels, while arrows on lower-level diagrams have more specific labels. If an arrow splits, forming two or more new arrow segments, each arrow segment may have a more specific label

More examples
Graphic Interpretation
Arrow Fork and Join structures

A& B

Diagram Features (4)

Inter-Box Connections

Correspondence of boundary arrows

Node parent > node child each child details one of the components of the parent Node child > node parent the interface of a box of the parent (= the connected arrows) defines the context of child

ICOM Coding of Boundary Arrows

ICOM (Input, Control, Output Mechanism) Coding the boundary arrows in the child diagram

NOTE: The dashed lines show how the ICOMs on the child diagram relate boundary arrows on the child to the arrows of its parent box.

Tunnelled arrows
Parentheses arrows
Child -> Parent (not shown)

Parent -> Child (not shown)

Tunnelled arrows - example

Summary of syntax rules

1. The diagrams of context are numbered A-n (n0): optional for n>0 2. The model must have at least one diagram of context A-0, which have only one box with the number 0 3. The diagrams (not context) must contain at least 3 boxes and maximum 6. 4. Each box in a diagram (not context) must be numbered in the order (from 1 to 6), within the box (bottom at right corner) 5. Each box which is detailed must give a reference (number of node, or number of page) of the child diagram, noted outside the box (bottom at right) 6. Each box must have at least a Control and an Output 7. A box can have zero or several Inputs 8. A box can have zero or several Mechanisms 9. A box can have 0 or 1 call 10. The names of the boxes and arrows must not contain the following terms: function, activity, process, input, output, control and mechanism

OTHER CONSTRAINTS ON THE DIAGRAMS

Input / Control
One of the two representations

- activity a2 is dependent of d which is created or modified by activity a1 - a function must have at least one Control. The input is not mandatory

Input / Control
- When an Input is also a control, we can indicate only the control - The detail can be represented in the child diagram - The two followings schemas are therefore equivalents

Note: An arrow (control) in a parent diagram can be used as an input in a child diagram

The good practices

- If an arrow is too long, repeat the label :

- Avoid too many output arrows:

- Avoid the redundancies : x

Wrap the arrows

Wrap the arrows (same source or destination)

Iteration and feedback

- A iterative activity (memorisation or feedback) can be represented in the following ways: Memory
or

- Feedback Input must be presented down and under.

- Feedback Control must be presented up and over.

Crossing of the arrows

- Avoid crossing

AUTHOR READER CYCLE

The participants
Authors (Analysts) People who prepare any IDEF model. Commenters (Experts or other Authors) People knowledgeable of the subject being modelled from whom authors may have obtained information by means of interviews, and have enough training in an IDEF technique to offer structured comments in writing. People assigned to make a written critique of a kit. Readers (Experts or anyone who wishes to be on the reader list) People knowledgeable of the subject being modelled from whom authors may have obtained information by means of interviews, and review documents for information but are not expected to make written comments. Librarian A person assigned the responsibility of maintaining a file of documents, making copies, distributing kits and keeping records.

The cycle author - reader

- The authors of the diagrams propose to commenter/readers : the diagrams the texts of explication annexes a glossary of terms used (data dictionary) - The readers/commenters : verify the syntax verify the hierarchy analyze the proposed modelling generate criticisms on the modelling (written comments) - The author in turn reacts in written to the remarks and suggestions made by the reader: if disagreement the author and reader must discuss (results of discussion written form) - Such a author-reader cycle will be carried out in two axes: the hierarchy of the diagrams, and the set of involved persons and till the final agreement on the model - This documented procedure allows knowing why specific decisions taken and who influenced these decisions - IDEF0 leads to the creation and permanent update of a model, avoid to have in the end of project a too heavy documentation phase

The Author Reader cycle

The Author Reader cycle

Objectives - ensure the quality of the diagrams - ensure the homogenous of the model components - favour team spirit, the emergence of a consensus

Status of a diagram Determine its degree of approval working (in elaboration by the author) draft (engaged in the author-reader cycle) recommended (waiting for approval by the authority) publication

Read a IDEF0 diagram

How to approach a diagram to understand quickly its content? 1. Read the function of boxes, in diagonal 2. Exam the parent box, and identify the most important arrows 3. Look for principle path, which relates the most important input to principle output 4. Exam each box in the order to verify that each input is justified 5. Exam the other arrows and look for other paths, the feedbacks and, the errors 6. Read the texts

Commenter a diagram
Is the diagram - syntactically correct? - comprehensible for the reader ? - conform to his (her) comprehension of things? Control the diagram Characteristics of a note : - an idea > a note - concise - clear, precise on the nature of disagreement - suggest a solution Make the notes of synthesis on the whole diagrams or of the kit to identify the cause of disagreement

Improve a diagram
1. Decompose a box in several ones 2. Regroup several boxes in one box 3. Add, delete, group of interfaces of a box => add, ramify, join a arrow. When we modify the interface of a diagram, the consequences on the parent box and the diagrams which detail their children can be very heavy. Avoid: - instability - small modification which alter the consistency of the model

IDEF Kit Diagram form

IDEF Couver sheet form

The format of an IDEF0 document

Conclusion
Rigorous approach Does not take into account the enterprise function or organisational borders Only syntax, no semantics Enterprise modelling
Understand the functions of the enterprise Information flow between the functions Preliminary design: architecture

Development of software
Function specification method

REFERENCES
INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEF0) Federal Information Processing Standards Publications (FIPS PUBS), National Institute of Standards and Technology (NIST), 1993 December 21 ICAM Architecture Part II-Volume IV - Function Modeling Manual (IDEF0) AFWALTR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, WrightPatterson Air Force Base, Ohio 45433, June 1981. IDEF0 IEEE 1320.1-1998, Standard for Functional Modeling Language-Syntax and Semantics for IDEF0