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
Control(s) (Factors which constraints the function)
(FUNCTION)
Input(s)
-Events triggering function, -Indications on method of execution,…
Output(s) (Result(s) provided by the function)
(object (s) transformed) 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
Parent -> Child (not shown)
Child -> Parent (not shown)
Tunnelled arrows - example
Summary of syntax rules 1. The diagrams of context are numbered A-n (n≥0): 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
