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