Tools and Techniques for

Process Modeling
 Tools and Techniques for Process Modeling

• Notation depends on what we want to

capture in the model
• The two major notation categories
– Static model: depicts the process, showing that
the inputs are transformed to outputs.
– Dynamic model: enacts the process, so the user
can see how intermediate and final products are
transformed over time.

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.2
 Tools and Techniques for Process Modeling
Static Modeling: Lai Notation

• Element of a process are viewed in terms of seven

types
– Activity: Something that will happen in a process
– Sequence: The order of activities
– Process model: A view of interest about the system
– Resource: A necessary item, tool, or person.
– Control: An external influence over process enactment
– Policy: A guiding principle
– Organization: The hierarchical structure of process agents
• Several templates, such as an Artifact Definition
Template

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.3
 2.3 Tools and Techniques for Process Modeling
Static Modeling: Lai Notation
Name Car
Synopsis This is the artifact that represents a class of cars.
Complexity type Composite
Data type (car_c, user-defined)
Artifact-state list
parked ((state_of(car.engine) = off) Car is not moving, and
(state_of(car.gear) = park) engine is not running.
(state_of(car.speed) =
stand))
initiated ((state_of(car.engine) = on) Car is not moving, but the
(state_of(car.key_hole) = engine is running
has-key)
(state_of(car-driver(car.))
= in-car)
(state_of(car.gear) = drive)
(state_of(car.speed) =
stand))
moving ((state_of(car.engine) = on) Car is moving forward or
(state_of(car.keyhole) = backward.
has-key)
(state_of(car-driver(car.))
= driving)
((state_of(car.gear) =
drive) or (state_of(car.gear)
= reverse))
((state_of(car.speed) =
stand) or
(state_of(car.speed) = slow)
or (state_of(car.speed) =
medium) or
(state_of(car.speed) =
high))
Sub-artifact list
doors The four doors of a car.
engine The engine of a car.
keyhole The ignition keyhole of a
car.
gear The gear of a car.
speed The speed of a car.
Relations list
car-key This is the relation between a car and a key.
car-driver This is the relation between a car and a driver.

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.4
 2.3 Tools and Techniques for Process Modeling
Static Modeling: Lai Notation (continued)

• The process of starting a car

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.5
 2.3 Tools and Techniques for Process Modeling
Static Modeling: Lai Notation (continued)

• Transition diagram illustrates the transition

for a car

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.6
 2.3 Tools and Techniques for Process Modeling
Dynamic Modeling

• Enables enaction of process to see what

happens to resources and artifacts as
activities occur
• Simulate alternatives and make changes to
improve the process
• Example: We can use systems dynamics
model to help us decide how many testers
we need or when we must initiate testing in
order to finish on schedule.

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.7
 2.3 Tools and Techniques for Process Modeling
Dynamic Modeling: System Dynamics

• Introduced by Forrester in the 1950's

• Abdel-Hamid and Madnick applied it to
software development
• One way to understand system dynamics is
by exploring how software development
process affects productivity

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.8
 2.3 Tools and Techniques for Process Modeling
Dynamic Modeling: System Dynamics (continued)

• Pictorial presentation of factors affecting productivity

• Arrows indicate how changes in one factor change
another

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.9
 2.3 Tools and Techniques for Process Modeling
Dynamic Modeling: System Dynamics (continued)

• A system
dynamic
model
containing
four major
areas
affecting
productivity

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.10
 2.4 Practical Process Modeling
Marvel Case Studies

• Uses Marvel process language (MPL)

• MPL uses three constructs: classes, rules,
tool envelopes to produce three-part process
description:
– rule-based specification of process behaviour
– object-oriented definition of model’s information
process
– set of envelopes to interface between Marvel and
external software tools

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.11
 2.4 Practical Process Modeling
Marvel Case Study - 1 (continued)

• Involved two AT&T networks that carried

– phone calls
– signalling network responsible for routing calls
and balancing the network load
• Marvel was used to describe the signalling
fault resolution

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.12
 2.4 Practical Process Modeling
Marvel Case Studies (continued)

• Signaling Fault Resolution Process

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.13
 2.4 Practical Process Modeling
Example of Marvel Commands

TICKET:: superclass ENTITY

status : (initial, open, referred_out, referral_done,
closed, fixed) = initial; Class
diagnostics : (terminal, non_terminal, none) = none; definition
level : integer; for trouble
description : text; tickets
referred_to : link WORKCENTER;
referrals : set_of link TICKET;
process : link PROC_INST;
end

diagnose [?t: TICKET]:

(exists PROC_INST ?p suchthat (linkto [?t.process ?p]))
:
(and (?t.status = open}(?t.diagnostics = none)) Rule for
{TICKET_UTIL diagnose ?t.Name} diagnosing
(and (?t.diagnostics = terminal) ticket
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC3));
(and (?t.diagnostics = non_terminal)
(?p.last_task = diagnose)
(?p.next_task = refer_to_WC2));

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.14
 2.4 Practical Process Modelling
Desirable Properties of Process Modelling Tools and
Techniques

• Facilitates human understanding and

communication
• Supports process improvement
• Supports process management
• Provides automated guidance in performing
the process
• Supports automated process execution

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.15
 2.5. Information System Example
Piccadilly Television Advertising System

• Needs a system that is easily maintained and

changed
• Requirements may change
– Waterfall model is not applicable
• User interface prototyping is an advantage
• There is uncertainty in regulation and
business constraints
– Need to manage risks
• Spiral model is the most appropriate

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.16
 2.5. Information System Example
Piccadilly System (continued)

• Risk can be viewed in terms of two facets

– Probability: the likelihood a particular problem
may occur
– Severity: the impact it will have on the system
• To manage risk, the model needs to include
characterization of risks in the process
model

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.17
 2.5. Information System Example
Lai Artifact Table for Piccadilly System

Name Risk (problemX)

Synopsis This is the artifact that represents the risk that problem X
will occur and have a negative affect on some aspect of the
development process.
Complexity type Composite
Data type (risk_s, user_defined)
Artifact-state list
low ((state_of(probability.x) = low) Probability of problem is
(state_of(severity.x) = small)) low, severity problem
impact is small.
high-medium ((state_of(probability.x) = low) Probability of problem is
(state_of(severity.x) = large)) low, severity problem
impact is large.
low-medium ((state_of(probability.x) = high) Probability of problem is
(state_of(severity.x) = small)) high, severity problem
impact is small.
high ((state_of(probability.x) = high) Probability of problem is
(state_of(severity.x) = large)) high, severity problem
impact is large.
Sub-artifact list
probability.x The probability that
problem X will occur.
severity.x The severity of the
impact should problem
X occur on the project.

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.18
 2.6 Real Time Example
Ariane-5 Software
• Involved reuse of software from Ariane-4
• The reuse process model
– Identify reusable subprocesses, describe them
and place them in a library
– Examine the requirements for the new software
and the reusable components from library and
produce revised set of requirements
– Use the revised requirements to design the
software
– Evaluate all reused design components to certify
the correctness and consistency
– Build or change the software
Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.19
 2.6 Real Time Example
Ariane-5 Software (continued)

• Reuse process model presentation

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 2.20