Effective Abstractions forDefining and Verifying Processes

Leon J. Osterweil (ljo@cs.umass.edu)

Univ. of Massachusetts

Amherst, MA 01003 USA

URL: laser.cs.umass.edu

UC Irvine

9 November 2001

What do we mean by “process”

• Activities related to the development, verification, evolution, evaluation, management, etc. of software products

• Examples of high level processes:– Develop requirements– Do Object Oriented Design– Formally verify

• Examples of low level processes– Archive result of running a test case– Verify a lemma

• Tend to be concurrent (coordination of people, systems)• Usually (regrettably) informal or undefined

Why the interest in process?

• Superior quality from superior processes– Build quality in, don’t “test in” quality (manufacturing)– Many observed “process errors”

• Real processes are intricate, have intricate interconnections

• Machines can help people with process complexities– Process effectiveness from human/machine synergy

Approaches to Process Definition• Process Definition may have different goals

– Communication

– Coordination

– Intuitive understanding

– Verification

– Training

– Automation

– Deep understanding

– Etc.

• Different definition formalisms support different of these goals to different degrees

• Formalisms vary in rigor, precision (semantic detail), semantic scope, clarity

Our Premise: Processes are software

Software Processes as Software

Consist of Requirements, Specification, Design, Code, etc. Process Requirements --Key to designing suitable process --Basis for evaluation and improvement of processProcess Specification/Modeling/Design --Helps conceptualization, communication, visualization --Can be management aid Process Code --Provides rigor and complete details --Basis for execution/tool support and integration Process Measurements and Evaluation --Results of Static Analysis and Dynamic Measurement --Basis for....Process Maintenace (aka Process Improvement)

Software processes should be developed using a (Software development process) development process(Software development process) development processSoftware processes should be developed using a (Software development process) development process(Software development process) development process

Process Representation Approaches

• Natural and Structured Natural Language

• Pictorial representations often used --DFD’s, FSA’s, etc.

• Programming language approaches can be used too

• Process aspects often modelled --Behavior modelling --Procedure modelling --Dataflow modelling --Product modelling --Role/actor/agent modelling ----some integrate, interrelate several

Directly analogous to product definition formalism approaches

Pictorial Approaches

• Support intuition about processes• Tend to have weak semantics

– Weak support for reasoning• Examples

– Data flow diagrams– Petri Nets– Finite state machines– Control flow diagrams– Combinations of the above

Petri Net Requirements specification process

Interview

Develop Spec

Develop Implementation

DevelopersReal World

Users

RW_Desc

Sys_Spec_Diag

Sys_Impl_Diag +Sys_Spec_Diag

Design_Spec

JSD

Decomposition of a part of the Rqts. process

Init_Sys_Spec_Diagram

Model_System

RW_Model

RW_Model

Identify_Model_Process

Model_Process_ Name_List

Connect

Connection_List +Model_Process_Name_List

Specify_Model_Process

Model_Process_List

RW_Model

Design Process Petri net

Req_Spec

Req_Spec

Identify_Object

Objects States

Identify_Operations

Operations Objects States

Establish_Visibility

Operations

Objects States

VisibilityEstablish_Interface

Interface

Create_Implementation

Implementation InterfaceCreate_Design_Spec

Design_Spec

Design_Spec

BOOD

More

Identify_Object

Req_Spec

Req_Spec

Identify_Nouns

IdentifyConcreteObject

IdentifyServer

IdentifyAbstractObject Identify

Agent

Identify Actor

Nouns + Req_Spec

concreteobject

server AbstractObject

AgentActor

Identify_Class

ObjectsClasses

Identify_AttributesObjects

Objects

States

States

Problems with Petri Nets

• Hard to define artifact flow• Hard to specify complex exception management• Petri Nets are not inherently hierarchical• Hard to specify agents, resources

Data Flow Diagram ofTraditional Waterfall Model

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

With Rework

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

With More Rework

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

The Trouble with Dataflow Diagrams

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

Where does output go?

What causes this rework?

What portion ofactivity should bedone?

How do we break this cycle?

What to do when reviews fail?

Representing Processes with Code

• Uses languages with execution semantics

• Provides details and elaborations upon process design

• Forces grappling with details omitted from model/design

• Vehicle for meshing process control with product data at arbitrarily low levels of detail

• Provides superior visibility enabling better control

• Basis for better predictability

• Basis for process execution

• Blueprint for tool integration

Variety of Approaches to CodeFormalisms

• More traditional coding languages:

--Procedural (Sutton's Appl/A)

--Rule-based (Kaiser's Marvel)

--Functional Hierarchy (Katayama’s HFSP)

--Law based (Minsky)

--Object Oriented (schema definition languages)

• Key issue: developing abstractions to facilitate process definition

HFSP design model

(a) JSD(Real_World | Design_Spec) =>(1)Develop_Spec(Real_World_Desc |System_Spec_Diagram)(2)Develop_Impl(System_Spec_Diagram |System_Impl_Diagram)(3)Where Real_World_Desc = Interview(Users, Developers,Real_World)(4) Design_Spec = union(System_Spec_Diagram, System_Impl_Diagram)

Second_level(b) Develop_Spec(Real_World_Desc |System_Spec_Diagram) =>(1)Develop_System_Model(Real_World_Desc |Real_World_Model, Init_System_Spec_Diagram)(2)Develop_System_Func(Real_World_Model, Init_System_Spec_Diagram |System_Spec_Diagram)

Third_level(c) Develop_System_Model(Real_World_Desc|Real_World_Model, Init_System_Spec_Diagram) =>(1)Model_Reality(Real_World_Desc |Real_World_Model)(2)Model_System(Real_World_Model |Init_System_Spec_Diagram)

(d) Develop_System_Func(Real_World_Model,Init_System_Spec_Diagram |System_Spec_Diagram)(1)Define_Func(Real_World_Model, Init_System_Spec_Diagram |System_Function, Function_Process)(2)Define_Timing(Init_System_Spec_Diagram, System_Function |Timing)(3)Where System_Spec_Diagram =is_composed_of(Init_System_Spec_Diagram, System_Function, Function_Process, Timing)

Fourth_level(e)Model_Reality(Real_World_Desc | Real_World_Model) =>(1)Identify_Entity_Action(Real_World_Desc | Entity_Action_List)(2)Draw_Entity_Structure(Entity_Action_List | Entity_Structure_List)Where Real_World_Model = is(Entity_Structure_List) Real_World_Process = is(Entity_Structure)(f) Model_System(Real_World_Model | Init_System_Spec_Diagram) =>(1)Identify_Model_Process(Real_World_Model | M_Proc_Name_List)(2)Connect(Real_World_Model, M_Proc_Name_List | Connection_List)(3)Specify_Model_Process(Connection_List, Real_World_Model, M_Proc_Name_List |Model_Process_List)(4)Where Init_System_Spec_Diagram = is(Model_Process_List)(5)Connection = is(State_Vector) or is(Data_Stream)

HFSP design model(a) JSD(Real_World | Design_Spec) =>

(1)Develop_Spec(Real_World_Desc |System_Spec_Diagram)(2)Develop_Impl(System_Spec_Diagram |System_Impl_Diagram)(3)Where Real_World_Desc = Interview(Users, Developers,

Real_World)(4) Design_Spec = union(System_Spec_Diagram, Syst

em_Impl_Diagram)

(b) Develop_Spec(Real_World_Desc |System_Spec_Diagram) =>

(1)Develop_System_Model(Real_World_Desc |Real_World_Model, Init_System_Spec_Diagram)

(2)Develop_System_Func(Real_World_Model, Init_System_Spec_Diagram |System_Spec_Diagram)

More Elaboration

(b) Develop_Spec(Real_World_Desc |System_Spec_Diagram) =>(1)Develop_System_Model(Real_World_Desc |

Real_World_Model, Init_System_Spec_Diagram)(2)Develop_System_Func(Real_World_Model,

Init_System_Spec_Diagram |System_Spec_Diagram)

(d) Develop_System_Func(Real_World_Model,Init_System_Spec_Diagram |System_Spec_Diagram)(1)Define_Func(Real_World_Model, Init_System_Spec_Diagram

|System_Function, Function_Process)(2)Define_Timing(Init_System_Spec_Diagram, System_Function |

Timing)(3)Where System_Spec_Diagram =is_composed_of(Init_System_Spec_Diagram, System_Function,

Function_Process, Timing)

HFSP OO Design Model(a) BOOD(Req_Spec | Design_Spec) =>(1) Identify_Object(Req_Spec | Objects, States)(2) Identify_Operations(Req_Spec, Objects, States | Operation)(3) Establish_Visibility(Req_Spec, Objects, States, Operation | Visibilty)(4) Establish_Interface(Visibility, Objects, States, Operation | Interface)(5) Establish_Implementation(Interface | Implementation)(6) Where Design_Spec = is_composed_of(Interface, Implementation);

Second Level(b) Identify_Object(Req_Spec | Objects, States) =>(1) Identify_Nouns(Req_Spec | Nouns)(2) Identify_Concrete_Object(Req_Spec, Nouns | Concrete_Object)(3) Identify_Abstract_Object(Req_Spec, Nouns | Abstract_Object)(4) Identify_Server(Req_Spec, Nouns | Server)(5) Identify_Agent(Req_Spec, Nouns | Agent)(6) Identify_Actor(Req_Spec, Nouns | Actor)(7) Identify_Class(Req_Spec, Agent, Server, Actor, Concrete_Object, Abstract_Object | Class)(8) Identify_Attributes(Objects | States)(9) Where Objects = union(Concrete_Object, Abstract_Object, Class, Agent, Actor, Server)

(c) Identify_Operation(Req_Spec, Object, States | Operation) =>(1) Identify_Suffered(Req_Spec, Object, States | Operation_Suffered)(2) Identify_Required(Req_Spec, Object, States | Operation_Required)(3) Defining_Time_Order(Req_Spec, Operation | Time_Order)(4) Defining_Space(Req_Spec, Operations | Space)(5) Where Operation = union(Operation_Suffered, Operation_Required)

(d) Establish_Visibility(Req_Spec, States, Operation | Visibility) =>(1) Specify_Object_See(Objects | Objects_See)(2) Specify_Object_Seen(Objects | Object_Seen)(3) Where Visibility = union(Objects_See, Object_Seen)

(e) Establish_Interface(Visibility, Object, States, Operations | Interface) =>(1) Derive_Module(Object | Module)(2) Specify_Attr(States, Module | Attributes)(3) Specify_Proc(Operations, Module | Procedures)(4) Specify_Visibility(Visibility, Module | Visibility_Spec)(5) Where Subsystem = is_in_terms_of(Module),(6) Interface = is_composed_of(Attributes, Procedure, Visibility_Spec);

Process definition strains programming languages severely

• Some issues– More pervasive dynamism– Complex reactive control– State reification– Novel transaction notions– Need for new abstractions– Specification of resources– Real time specification– More central role for humans– Need to mix paradigms

• Language design grows from new challenges– better languages, and not only for processes

Questions

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

Where does output go?

What causes this rework?

What portion ofactivity should bedone?

How do we break this cycle?

What to do when reviews fail?

Little JIL

• Exploring effective process abstractions– Clear, precise definition of realistic processes

• Graphical language with execution semantics– Expresses process coordination– Designed to be used interchangeably with

other product, resource, scheduling factors• Visual JIL is the graphical interface to Little JIL

Little-JIL Step Notation

TheStepName

Interface Badge

Prerequisite Badge Postrequisite Badge

SequencingReactions

Handlers

Z X

Little-JIL Example:“Smart” Regression Test Process

RegressionTest

GetArtifacts

GetExecutable GetTest Cases

PerformTest

PerformTestExecuteTest Report Failure

SelectTests

Stop

StopReportResults

Get Input Data

Get Expected Output Data

Run Test

Compare Results

NoteFailure

The BOOD (Booch OO-Design) Process as an example

• Notation– Class diagrams, state transition diagrams, interaction

diagrams, ...• Method:

– Identify classes and objects– Identify semantics of classes and objects– Identify relationships between classes and objects– Specify the interface and implementation of the classes

and objects

What BOOD is:

What BOOD Doesn’t Address

• Only describes the “nominal” process– Doesn’t address how to handle non-nominal

conditions (exceptions)• Only describes “design-in-the-small”

– Design “in the large” is not addressed• General lack of precision• Does not address collaboration

– Much design is done by teams• Does not address configuration management

– How to handle design evolution

Proactive Flow Sequencing Kinds

• Sequential– In order, left to right

• Parallel

• Choice– Choose from Agenda

• Try

The Nominal Process

• Using parallel and sequential step kinds

Booch

Identify_Classes_and_Objects

Identify_Semantics

Identify_Relationships

Implement

Booch

ClassicalBehavioral

Use Case

More Control Constructs

Implement

Look_for_Inheritance

Look_for_Objects_to_Delegate_to

Look_for_Parameterized_Class

Custom_ImplementationReuse_Implementation

Scoped Exception Handing

• All steps may contain one or more exception handlers• React to exceptions thrown in descendent steps• Handlers are steps themselves

DevelopInterfaceFiles

InterfaceFilesCompile

InterfaceFilesDontCompile

Four different continuations on exception handlers

• Complete– Handler was a “fixup” and now it is OK to go back

• Continue– Handler brought step to an acceptable postcondition

state and it is OK to go on• Restart

– SNAFU. Handler cleaned up mess, now OK to redo• Rethrow

– Go up to parent and hope the parent knows what to do

Prerequisites and Postrequisites

• Test before/after execution of a step• Requisites are themselves entire steps• Program what to look for, in what order, and

distinguish among responses for various contingencies

• Uses exception handling to respond to failures

Assessing Milestones Using Postrequisites

• In BOOD, defined as conditions on the product• In Little-JIL, represented with postrequisites on steps

DevelopInterfaceFiles

InterfaceFilesCompile

InterfaceFilesDontCompile

Real Time Specification

• Each step may have a deadline specification• Exception thrown when step execution exceeds

deadline• Scheduling algorithms can detect when a step’s

substep structure is unschedulable– Exception is thrown

Examples of Resources

• Input artifacts: requirements document, locks on key artifacts

• People: designers with varying skills• Tools: ROSE• Agents: Each step has a distinctly identified unique

resource responsible for execution of the step (and all of its substeps)

Resource Model:Is-A Relationships

Resource

Human HardwareSoftwareData

Manager Designer

PC Sparc

Design Team

Bob Carol Ted Alice

Class

Schedulable Class

Instance

Resource Model:Requires Relationships

Resource

Human HardwareSoftwareData

Manager Designer

PC Sparc

Design Team

Bob Carol Ted Alice

Resource Model:Whole-Part Relationships

Resource

Human HardwareSoftwareData

Manager Designer

PC Sparc

Design Team

Bob Carol Ted Alice

An Example Resource Model

Resource Request Example

IdentifyRelationships

SpecifyRelationships RefineRelationships

Agent: BOODDesigner;experttool: ClassDiagramEditorartifact: DiagramReposLock

Resource request is a query on theResource specification repository

Artifact Flow

Booch

Identify_Classes_and_Objects

Identify_Semantics Identify_Relationships

Implement

new_ident

new_ident

new_conceptnew_concept

new_concept

Requirements

Low-LevelDesign

Code

Test

High-LevelDesign

Where does output go?

What causes this rework?

What portion ofactivity should bedone?

How do we break this cycle?

What to do when reviews fail?

Remember These Questions

High-Level Process

Requirements Details

Design Details

Requirements Rework

Current Evaluation Projects• Perpetual testing: Programming flexibly evolvable

integrated testing and analysis• KDD/Data Mining• Programming the process of collaborative Object

Oriented Design• Programming the process of doing data flow analysis• Programming robot coordination• Programming and analyzing ecommerce processes such

as auctions

• Applicability seems very broad• Current emphases: ecommerce, robotics

Process Execution• Often (unfortunately) referred to as process enactment

• One clear goal of process implementation (coding) --although not the only goal

• Execution is on a "virtual machine" consisting of --process program code --software tools --humans

• Process execution tends to run for a very long time --Months or years

• Process code changes itself as it executes

• Process execution is different from product execution in interesting ways (eg. assumptions about the underlying machines have to be different)

Process Execution Support With Process Centered Environments

• Code processes in executable languages– Code in flexibility, freedom for humans as desired

• Compile and execute them• Support from a (distributed, concurrent) environment

infrastructure and toolset– The process as an integration rationale

• Can the process really help humans by– taking onerous work off our backs?– leaving us more free to do what we do best?– providing support and direction as desired?

Juliette: The Little-JIL Interpreter

• Powerful substrate required to interpret Little-JIL• Architecture of Julia is distributed• Every step has its own interpreter• Step and interpreter are executed on agent’s platform• Interpretation uses Juliette services• Communication is via Agendas--one for each agent and service• Services include:

– Object Management– Resource Management– Step sequence Management– Agenda Management– Scheduler

Process Maintenance (Process Improvement)

• Process maintenance takes place over an extended period of time--can be expected to be more costly and important than process development

• Improvement efforts should always be relative to stated goals

• Process Improvement aimed at progress towards process requirements and improvement goals

• Improvement progress must be measured to assure progress is made and improvement is underway • These argue for the importance of process requirements specification and precise process measurement

• Greater rigor can lead to more effective improvement

Capability Maturity Model (CMM)• Structure for modelling the effectiveness of organizations in improving their software processes

• Developed and promulgated by Watts Humphrey at the Software Engineering Institute

• Based on work on industrial statistical process control by Deming and Juran (decades ago)

• Hypothesizes a "normative model" of how software should be developed, based upon a comprehensive profile of activity areas

• Hypothesizes five levels of process maturity

Level 1: InitialLevel 1: InitialLevel 2: RepeatableLevel 2: RepeatableLevel 3: DefinedLevel 3: DefinedLevel 4: ManagedLevel 4: ManagedLevel 5: OptimizingLevel 5: Optimizing

Level 1: InitialLevel 1: InitialLevel 2: RepeatableLevel 2: RepeatableLevel 3: DefinedLevel 3: DefinedLevel 4: ManagedLevel 4: ManagedLevel 5: OptimizingLevel 5: Optimizing

The Capability Maturity Model (CMM)is a Specific Approach to

Software Process Improvement

Software Process Measurement and Evaluation

• Analogy to application software measurement and evaluation seems very useful here

• Dynamic monitoring of process execution is analogous to interactive debugging of application software

• Need to support analysis of processes too

Focus on Process Quality

• Is the process correct?– Errors will happen very fast– When will humans notice/correct them?

• Is the implementation in code correct?• How fast will the process run?• How to be sure that humans perform their jobs?

– Train them, monitor their participation• Are resources adequate, efficiently used?• How to improve the process

– And be sure that changes are improvements?

Process Analysis and Testing

• Visual scans of process programs can identify gross errors and major risks

• Dynamic analysis of instrumented process programs– Timing– Event analysis

• Use software graph analysis to demonstrate absence of some risks– Deadlocks– Race conditions

• Dataflow analysis of process programs– Application specific errors can be defined and automatically

scanned for

Approaches to Quality Determination

• Dynamic approaches– Testing (run process and observe/measure)– Simulation (model some or all of the functionality)– Sampling approaches: detect errors, statistical

summaries• Static approaches

– Infer theorems/prove properties from models– Prove absence of errors– Prove worst/best cases

Process Precision is Key to Determining /Assuring Quality

• Precise process definitions can be:– Analyzed

• To prove desired properties ( they are correct)• To find flaws (or prove there are none)• To compare them to competing processes

– Repeated• Aid in training

– Improved• Not just changed

– Used to integrate new agents and subprocesses– Automated as desired

Programming Auction Processes

• Why:– Identify differences/similarities– Create a taxonomy of auctions– Basis for proving properties, showing absence of

errors– Basis for automation; then measurement, evaluation

• How:– Use Little-JIL– Program a range of auctions– Analyze for a range of properties/errors

Example

• Open Cry (English) Auction

– Ascending bids

– Unlimited number of bidders

– Not Vickery

– Auctioneer discretion in closing auction

• Properties of interest

– No late bids accepted

– All bids considered

– No deadlocks, no race conditions

– Highest bid always wins

– ….

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

Open Cry Auction Step Decomposition

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

With Exceptions

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

With Resources

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

bidder:Bidder

Auctioneer

Auctioneer

agent:Auctioneer

Auctioneer agent

agent bidder

agentauctioneer

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

With Artifact Flow

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

best: BidReference

best: BidReference

best: BidReference

bid:Bid

deadline: Duration 1m

best: BidReference

bid:Bid

bid:Bid

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

Entire Auction

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

best: BidReference

best: BidReference

best: BidReference

bid:Bid

deadline: Duration 1m

best: BidReference

bid:Bid

bid:Bid

agent:Auctioneer

bidder:Bidder

Auctioneer

Auctioneer agent

agent bidder

Auctioneer

agentauctioneer

Open-Cry Auction

Close Auction Accept Bids From Bidder

Accept Bids From BidderAccept One Bid

Submit BidUpdate Best Bid Accept One Bid

Entire Auction

NoMoreBidders

NoMoreBidders

AuctionClosed

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

AuctionNotClosed

BidIsHigher

AuctionNotClosed

BidIsBetter

best: BidReference

best: BidReference

best: BidReference

bid:Bid

deadline: Duration 1m

best: BidReference

bid:Bid

bid:Bid

agent:Auctioneer

bidder:Bidder

Auctioneer

Auctioneer agent

agent bidder

Auctioneer

agentauctioneer

Properties Checked

• No Late Bids Accepted– Checked on initial version– Inconclusive Results– Need to add an “AuctionNotClosed” prerequisite to

“Update Best Bid”• Highest Bid Always Wins

– Checked on initial version– Inconclusive results– Assumed locking discipline on bid handling– Checked on the revised auction– Conclusive Results

Results

• Modeling Little-JIL step semantics was complex in some cases (eg. the choice step kind)

• Modeling dataflow and resource specification was subtle at times

• Process flowgraphs were large and complex• FLAVERS was quite capable of performing analyses

Flowgraph Model of a Leaf Step

LeafPosted

LeafStarted

LeafTerminatedLeafCompleted

Flowgraph Model of a Sequential Step

SeqPosted

SeqStarted

SeqTerminatedSeqCompleted

Substep1

Substepn

Terminated

Terminated

Terminated

...

Completed

Completed

Completed

Flowgraph Model of a Parallel Step

ParPosted

ParStarted

ParTerminatedParCompleted

Substep1 Substep2

Terminated

TerminatedCompleted

Completed

Flowgraph Model of a Try Step

TryPosted

TryStarted

TryCompletedTryTerminated

Substep1

Substepn

Completed

...

Terminated

Terminated

Terminated

Completed

Completed

Flowgraph Model of a Choice Step

ChoicePosted

ChoiceStarted

ChoiceCompleted

ChoiceTerminatedSubstep1 Substepn

Substep1HasNotStarted SubstepnHasNotStarted

Substep1HasStarted

SubstepnHasStarted

...

TerminatedCompleted

…

. . . . . . . .

Analysis Results

Property TFG Nodes TFG Edges Result Time (s)No Late Bids Accepted 1 216 11,837 Inconclusive - fault 6.56No Late Bids Accepted 2 316 30,881 Conclusive 41.10Possible Race Condition 327 35,788 Inconclusive - fault 143.25No Race Condition (no lock) 189 7,710 Inconclusive - fault 15.07No Race Condition (with lock) 269 20,910 Conclusive 17.52

Current Evaluation Projects• Perpetual testing: Programming flexibly evolvable

integrated testing and analysis• KDD/Data Mining• Programming the process of collaborative Object

Oriented Design• Programming the process of doing data flow analysis• Programming robot coordination• Programming and analyzing ecommerce processes such

as auctions

• Applicability seems very broad• Current emphases: ecommerce, digital

government, robotics

Key Challenges

• Lateral data flow• Visualization• Efficient execution• Clean definitions of abstractions