Enterprise Modelling

IDEF0

David Chen

IMS, University Bordeaux 1

� Developed since 1970s

� USAF (US Air Force) Project ICAM (Integrated Computer Aided Manufacturing)

� ICAM DEFinition (IDEF): Structured modelling languages

What is IDEF0?

� 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

� IDEF0 - Functions (WHAT)

Question: What I do?

� IDEF1 - Information (With WHAT)

IDEF

� 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? 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 NOTATIONSBASIC NOTATIONS

Box syntax

Develop

product

name of the function: a verb, or a verbal expression,

as specific as possible

Number of order: chronological number (C-number (1

Each box corresponds to a function (or activity)

product1

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)

-Events triggering function,

-Indications on method of

execution,…

(FUNCTION)Input(s) Output(s)

(object (s) transformed)

by the function)

(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

Make Pizza

Recipe

Node: A-0 Title: Make pizza PAGE : 1/1

Make Pizza

Flour

Water

Ham

Ham Pizza

Oven

IDEF0 Model

An IDEF0 Model is composed of three types of information:

� Diagrams

Text� 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 diagramChild 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

Diagram of context

Top-model

Node A-0

High levels of Diagram of context

Optional

Diagram of context

Optional, describe the

environment of A-0

Node A-0

(Mandatory)

IDEF0 Model of a study

Principle Construction Rules

� 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

The principles of construction of diagrams :

� 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 on an IDEF0 diagram represent

data or objects as constraints. Only at

low levels of detail can arrows

represent flow or sequence,

Arrows as Constraints

Diagram Features (2)

an output of one box may provide some or

all of the data and objects needed for

activations of one or more other boxes.

Arrows as activations of a Box

Remark: Here, we do not precise if

the function 2 must be done before

the function 3 or inversely

Arrows as Pipelines

Diagram Features (3)

It is useful to think of high-level arrows as pipelines or conduits. High-

level 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 labelspecific 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 childeach child details one of the

components of the parent

Node child –> node parentthe 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.

Parent -> Child

Child -> Parent

(not shown)

Tunnelled arrows

Parentheses arrows

Parent -> Child

(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)

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

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

OTHER CONSTRAINTS ON THE 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

- Avoid too many output arrows:

Wrap the arrows

Wrap the arrows (same source or destination)

Iteration and feedback

Memory

- A iterative activity (memorisation or feedback) can be represented in the

following ways:

or

- Feedback ‘Control’ must be

presented “up and over.”

- Feedback ‘Input’ must be

presented “down and under.”

Crossing of the arrows

- Avoid crossing

AUTHOR – READER CYCLEAUTHOR – 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 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.• LibrarianA 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• 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 diagramDetermine 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• Control the diagramCharacteristics 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� 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)(IDEF0)AFWALTR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, June 1981.

� IDEF0IEEE 1320.1-1998, Standard for Functional Modeling Language-Syntax and Semantics for IDEF0