TU Kaiserslautern
Process Modeling
5.7 IDEF0
Integration Definition for Function Modeling (IDEF0)
Federal Information Processing Standards Publication 183
Initial document:
Air Force Wright Aeronautical Laboratories Integrated Computer
Manufacturing (ICAM) Architecture, Part II; Volume IV - Function
Modeling Manual (IDEF0), June 1981
Function modeling
Systems
Company (Process modeling)
Based on SADT (Structured Analysis and Design Technique)
Slide 65
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Background of IDEF0
Project
USAF ICAM (Integrated Computer Aided Manufacturing)
1975 - 1980
IDEF = ICAM DEFinition Language
Three languages
IDEF0 (What do I do?)
function model
IDEF 1-1x (What do I need to know to do what I do?)
information model
IDEF2 (When do I need to know what I need to know to do what I do?)
dynamics model
Slide 66
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Characteristics of IDEF0
Simplicity of process documentation
Advantages
Comprehensive graphical representation
Simple notation
Supports human communication
Widely applied in practice
Prescriptive models (especially organization-specific reference models)
Tool support
Slide 67
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Syntactical Elements of IDEF0
Boxes - Function
Develop Model
Function name (Verb)
Number
1
Arrows - Data / Objects
Straight-line arrow segment
Curved-arrow segment (corners
are rounded with 90 degree arcs)
Forking arrows
Rejoining arrows
Slide 68
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Syntax Rules of IDEF0
Boxes
Boxes shall be sufficient in size to insert box name
Boxes shall be rectangular in shape, with square corners
Boxes shall be drawn with solid lines
Arrows
Arrows that bend shall be curved using only 90 degree arcs
Arrows shall be drawn in solid-line segments
Arrows shall be drawn vertically or horizontally, not diagonally
Arrow ends shall touch the outer perimeter of the function box and shall
not cross over into the box
Arrows shall attach at box sides, not at corners
Ref: Draft Federal
Information Processing
Standards Publication 183
Slide 69
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Connecting Arrows, Boxes and Names
Design
Requirements
Recommended
Detailed Design
Preliminary
Design Data
Perform Detailed Design 2
Design
Engineer
MFG/A632
Each side of a box has a specific meaning
a) Input: left side
b) Control: upper side
c) Output: right side
d) Mechanisms: upwards, lower side
e) Usage of a mechanism: downwards, lower side
Slide 70
Dr. Jrgen Mnch 2002-2007
A squiggle (
)is used for
connection of names to arrows
when clear positioning is not possible
TU Kaiserslautern
Process Modeling
Diagram
Design
Requirements
Recommended
Detailed Design
Preliminary
Design Data
Perform Detailed Design
2
Design
Engineer
MFG/A632
PURPOSE: Designing the software system
VIEWPOINT: Design Team
QA/A-0
TOP LEVEL
Diagrams create a
decomposition hierarchy!
Slide 71
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Evaluation of IDEF0
Criterion
Natural representation
Support of quality management
Adaptability of model
Formality
Understandability
Interpretability (execution & enactment)
Flexibility
Traceability
Slide 72
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
5.8 ETVX
Development by IBM [Radice] beginning of 1980s
Notation for description of activities
Entry Task Verification eXit
Entry criteria must be satisfied before a set of tasks can be performed
Tasks set of tasks to be performed
Verification & validation - The means to determine that the tasks are
completed properly
eXit criteria - criteria for task completion
Slide 73
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Basic Schema in ETVX
Tasks
Entry
Criteria
Verification &
Validation
Slide 74
Dr. Jrgen Mnch 2002-2007
Exit
Criteria
TU Kaiserslautern
Process Modeling
Example ETVX: Size Estimation
Top-level description
Entry
P ro d u c t s tru c tu re is a s d e ta ile d a s t e c h n ic a lly
p o s s ib le .
Task
P re c is e ly d e fin e s ta n d a rd o f m e a s u re m e n t.
E s tim a te s iz e o f e a c h e le m e n t.
S u m s iz e o f e a c h e le m e n t.
A p p l y c o n tin g e n c y fa c to rs .
C o m p a r e t o h i s t o r i c a l d a t a o f s i m i la r t y p e /
c o m p le x it y.
C h e c k fo r c a lc u la tio n e rr o rs .
E s tim a te h a s b e e n v e rifie d a g a in s t h is to ric a l
d a ta .
C a lc u la tio n s h a v e b e e n c h e c k e d .
E s tim a te h a s b e e n a d d e d to h is to ric a l d a ta .
D e t a i l e d s i z e e s t im a t e p r o d u c e d .
Validation /
Verification
eXit
Slide 75
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Estimation ETVX
Advantages
Intuitive understanding of tasks
Detailed enough for the implementation of processes for many purposes
Can be used for delegation of tasks (prescriptive models)
Disadvantages
Becomes complex very fast
General flow difficult to understand
Slide 76
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Evaluation of ETVX
Criterion
Natural representation
Support of quality management
Adaptability of model
Formality
Understandability
Interpretability (execution & enactment)
Flexibility
Traceability
Slide 77
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
5.9 SPEM
Software Process Engineering Model
Released 2005 by the Object Management Group (OMG)
Based on UML notation (UML 1.4)
Uses parts of UML metamodel
Defined as a subset of UML
Metamodel for description of software development processes
(or a family of processes) and their components
Intended for development and adoption of processes
Planning and execution of processes (in a project) is not part of
metamodel
Slide 78
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Roles, Activities, Work Products
Activities are performed by roles on work products
Different roles work together by exchanging work products and
initiating activities
Slide 79
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Basic Types of SPEM
Work products
Can be consumed, produced, modified
Can have different states
Can be composed of other work products (aggregation)
Can formally be defined as deliverables
Work product state machine:
created
drafted
reviewed
approved
Guidance
Special type of products (are not work products)
Cannot be produced or modified (e.g., technique, template, checklist,)
Process roles
Define responsibilities for work products
Perform activities
Slide 80
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Basic Types of SPEM
Activities
Done by a single process role
The process role executing the activity is its owner, others can be
assistants
Can be refined into activity steps
Entry and exit criteria by preconditions and goals
Work breakdown structure
Process can be described on different levels of detail:
Activity
Work definition: composite set of activities
Iteration: composite work definition with a minor milestone
Phase: time span between two milestones (entry, exit criteria)
Lifecycle: complete process
Slide 81
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Example SPEM: Activity
<<Activity>>
Find Actors and Use Cases
/performer: System Analyst
/assistant: Customer
/assistant: Architect
Slide 82
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
SPEM Diagrams
Process models can be visualized using standard UML
diagrams
Class diagram
Package diagram
Activity diagram
Use case diagram
Sequence diagram
State chart diagram
As in UML, process models can be structured using packages
Discipline: specialization of package used to categorize activities
according to a common theme
Process component: self-contained, internally consistent piece of
process description
Slide 83
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Slide 84
Example SPEM: Activity Diagram
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Evaluation of SPEM
Criterion
Natural representation
Support of quality management
Adaptability of model
Formality
Understandability
Interpretability (execution & enactment)
Flexibility
Traceability
Slide 85
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
5.10 Little-JIL
Little-JIL
Agent coordination language
Process divided into small units of work: steps
Steps can be assigned to agents
JIL vs. Little-JIL
JIL: complex process language
Text-based
Based on ADA
Many complex functions
Little-JIL: coordination language
Subset of JIL
Only essential functions
Graphical representation for every function
Slide 86
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Agents and Steps
Agent
Autonomous entity
Can be human or automated
Each agent has one or more agendas
with work (i.e., steps) assigned to it
When work is done, the agent has to report success or failure
Step
Basic building block
Represents a unit of work
Can be decomposed into sub-steps
Every Little-JIL program is represented by its root step, which is
decomposed to describe the process
Slide 87
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
States of a Step
Completed
Started
Terminated
Posted
Retracted
Opted-Out
Posted
Started
Step is removed from agenda without being started (can be reposted to another agent)
Opted-Out
Slide 88
Step failed to complete (e.g., after an exception was thrown)
Retracted
Completion is indicated by the agent
Terminated
Start is indicated by the agent
Completed
Step is posted to the agenda of the agent
Step is an optional step and agent decides not to start it
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Graphical Representation of a Step
Step is annotated with badges
Every badge provides additional information or specifies the control
flow
Sub-steps are drawn below parent step
Connected with arcs to sequencing badge of parent step
Slide 89
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Step Badges
Sequencing badge
None:
Step is not decomposed
Sequential:
Sub-steps are executed from
left to right, each one starting
after previous sub-step is
completed
Parallel:
Sub-steps are executed
concurrently
Choice:
Only one of the sub-steps is
executed
Try:
Try sub-steps from left to right
until one sub-step succeeds
Slide 90
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Step Badges
Interface badge
Resource declaration
Defines resources used by the step
Products produced by other steps and agents can also be needed resources
Parameter declaration
Defines parameters used by the step
Types: In, Out, In/Out, Locals
For object exchange between parent step and sub-steps
Channel declaration
Specifies all channels the step can write into or read from
Communication between two arbitrary steps
Exception declaration
Specifies all exceptions that can be thrown by the step
Exceptions can be thrown to show that a process did not complete correctly
Message declaration
Defines all messages that can be sent by the step
Messages can be sent during execution of the step (automatically or by the
agent)
Slide 91
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Step Badges
Pre- /Post-requisite badge
Define pre- and post-conditions for the execution of the step
If the step is started / terminated and the condition fails, an exception is
thrown
Reactions badge
Every reaction defines a step for a certain message
If the step is in state started and the message is sent by some other
step, the reaction step is executed immediately (parallel to other active
steps)
Handler badge
Every exception handler defines the types of exception he handles and
the steps executed when the exception occurs
If an exception occurs and no handler is defined for this exception, the
step is terminated and the exception is thrown to the parent step
Slide 92
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Slide 93
Example Little-JIL: Simple Process
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Slide 94
Example Little-JIL: Process with Exceptions and Messages
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Evaluation of Little-JIL
Criterion
Natural representation
Support of quality management
Adaptability of model
Formality
Understandability
Interpretability (execution & enactment)
Flexibility
Traceability
Slide 95
Dr. Jrgen Mnch 2002-2007
MVP-L
IDEF0
ETVX
SPEM
Little-JIL
Naturalness
Support of quality management
Adaptability of model
Formality
Understandability
Feasibility (execution &
Interpretability
enactment)
Flexibility
Traceability
Slide 96
Dr. Jrgen Mnch 2002-2007
Funsoft
Nets
MSL
Statemate
Overview of Process Modeling Languages
Appl/A
TU Kaiserslautern
Process Modeling
TU Kaiserslautern
Process Modeling
5.11 Further Notations
Software Process Modeling Notations
UML (e.g., Activity Charts)
Tool-specific notations
Business Process Modeling Languages
ARIS: Notation for Business Processes, uses Event-driven Process
Chains
BPML (Business Process Modeling Language)
Slide 97
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Future Research Tasks
Slide 98
Definition of a comprehensive and consistent terminology
Relationships to languages in workflow management systems
Concepts for process and product variability
Concepts for process instantiation for project planning
Concepts for re-planning for process enactment
Dr. Jrgen Mnch 2002-2007
TU Kaiserslautern
Process Modeling
Summary
Several process modeling languages exist for prescriptive and
descriptive modeling
Different criteria have been introduced to assess process
notations
There is no universal process modeling language
The suitability of a language essentially depends on the
application purpose
Concepts of abstraction must be available for descriptive
modeling
Slide 99
Dr. Jrgen Mnch 2002-2007
