enterprise modelling idef0chen33.free.fr/m2/courses/idef0-anglais.pdf · what is idef0? objective :...
TRANSCRIPT
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