Effective abstractions for defining and verifying processes
This presentation is the property of its rightful owner.
Sponsored Links
1 / 80

Effective Abstractions for Defining and Verifying Processes PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

Effective Abstractions for Defining and Verifying Processes. Leon J. Osterweil ([email protected]) Univ. of Massachusetts Amherst, MA 01003 USA URL: laser.cs.umass.edu UC Irvine 9 November 2001. What do we mean by “process”.

Download Presentation

Effective Abstractions for Defining and Verifying Processes

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Effective abstractions for defining and verifying processes

Effective Abstractions forDefining and Verifying Processes

Leon J. Osterweil ([email protected])

Univ. of Massachusetts

Amherst, MA 01003 USA

URL: laser.cs.umass.edu

UC Irvine

9 November 2001


What do we mean by process

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

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

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


Effective abstractions for defining and verifying processes

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 process

Process 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 as Software

Software processes should be developed using a

(Software development process) development process


Process representation approaches

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

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

Petri Net Requirements specification process

Developers

Users

Real World

JSD

Interview

RW_Desc

Develop Spec

Sys_Spec_Diag

Develop Implementation

Sys_Impl_Diag +

Sys_Spec_Diag

Design_Spec


Decomposition of a part of the rqts process

Decomposition of a part of the Rqts. process

RW_Model

Model_System

RW_Model

Identify_Model_Process

Model_Process_

Name_List

Connect

Connection_List

+

Model_Process_Name_List

Specify_Model_Process

Model_Process_List

RW_Model

Init_Sys_Spec_Diagram


Design process petri net

Req_Spec

Design Process Petri net

BOOD

Req_Spec

Identify_Object

Objects

States

Identify_Operations

Objects

Operations

States

Establish_Visibility

Objects

States

Operations

Visibility

Establish_Interface

Interface

Create_Implementation

Implementation

Interface

Create_Design_Spec

Design_Spec

Design_Spec


Effective abstractions for defining and verifying processes

Req_Spec

More

Identify_Object

Req_Spec

Identify_Nouns

Nouns +

Req_Spec

Identify

Actor

Identify

Concrete

Object

Identify

Abstract

Object

Identify

Agent

Identify

Server

concrete

object

Agent

Actor

server

Abstract

Object

Identify_Class

Objects

Classes

Identify_Attributes

Objects

States

Objects

States


Problems with petri nets

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 of traditional waterfall model

Data Flow Diagram ofTraditional Waterfall Model

Requirements

High-LevelDesign

Low-LevelDesign

Code

Test


With rework

With Rework

Requirements

High-LevelDesign

Low-LevelDesign

Code

Test


With more rework

With More Rework

Requirements

High-LevelDesign

Low-LevelDesign

Code

Test


The trouble with dataflow diagrams

The Trouble with Dataflow Diagrams

Where does output go?

Requirements

What to do when reviews fail?

What causes this rework?

High-LevelDesign

What portion of

activity should bedone?

Low-LevelDesign

Code

Test

How do we break this cycle?


Representing processes with code

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 code formalisms

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)WhereReal_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


Hfsp design model1

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)WhereReal_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

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)


Effective abstractions for defining and verifying processes

(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);

HFSP OO Design Model


Process definition strains programming languages severely

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

Questions

Where does output go?

Requirements

What to do when reviews fail?

What causes this rework?

High-LevelDesign

What portion of

activity should bedone?

Low-LevelDesign

Code

Test

How do we break this cycle?


Little jil

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

Little-JIL Step Notation

Interface Badge

Prerequisite Badge

Postrequisite Badge

TheStepName

Z

X

Sequencing

Handlers

Reactions


Little jil example smart regression test process

Little-JIL Example:“Smart” Regression Test Process

RegressionTest

GetArtifacts

ReportResults

Stop

PerformTest

SelectTests

Stop

PerformTest

Report Failure

ExecuteTest

GetExecutable

GetTest Cases

NoteFailure

Compare Results

Get Input

Data

Run Test

Get Expected

Output Data


The bood booch oo design process as an example

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

What BOOD is:

  • 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 doesn t address

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

Proactive Flow Sequencing Kinds


The nominal process

The Nominal Process

  • Using parallel and sequential step kinds

Booch

Booch

Identify_Classes_and_Objects

Implement

Identify_Relationships

Classical

Use Case

Behavioral

Identify_Semantics


More control constructs

More Control Constructs

Implement

Reuse_Implementation

Custom_Implementation

Look_for_Inheritance

Look_for_Parameterized_Class

Look_for_Objects_to_Delegate_to


Scoped exception handing

Scoped Exception Handing

  • All steps may contain one or more exception handlers

  • React to exceptions thrown in descendent steps

  • Handlers are steps themselves

InterfaceFilesDontCompile

DevelopInterfaceFiles

InterfaceFilesCompile


Four different continuations on exception handlers

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

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

Assessing Milestones Using Postrequisites

  • In BOOD, defined as conditions on the product

  • In Little-JIL, represented with postrequisites on steps

InterfaceFilesDontCompile

DevelopInterfaceFiles

InterfaceFilesCompile


Real time specification

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

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

Bob

Resource

Human

Design Team

Carol

Hardware

Ted

Software

Alice

Data

Manager

PC

Class

Sparc

Designer

Schedulable Class

Instance

Resource Model:Is-A Relationships


Resource model requires relationships

Bob

Resource

Human

Design Team

Carol

Hardware

Ted

Software

Alice

Data

Manager

PC

Sparc

Designer

Resource Model:Requires Relationships


Resource model whole part relationships

Bob

Resource

Human

Design Team

Carol

Hardware

Ted

Software

Alice

Data

Manager

PC

Sparc

Designer

Resource Model:Whole-Part Relationships


An example resource model

An Example Resource Model


Resource request example

Resource Request Example

Agent: BOODDesigner;expert

tool: ClassDiagramEditor

artifact: DiagramReposLock

IdentifyRelationships

SpecifyRelationships

RefineRelationships

Resource request is a query on the

Resource specification repository


Artifact flow

Artifact Flow

Booch

new_ident

new_concept

Identify_Classes_and_Objects

Implement

new_ident

new_concept

new_concept

Identify_Relationships

Identify_Semantics


Remember these questions

Remember These Questions

Where does output go?

Requirements

What to do when reviews fail?

What causes this rework?

High-LevelDesign

What portion of

activity should bedone?

Low-LevelDesign

Code

Test

How do we break this cycle?


High level process

High-Level Process


Requirements details

Requirements Details


Design details

Design Details


Requirements rework

Requirements Rework


Current evaluation projects

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

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

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

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 (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

Capability Maturity Model (CMM)

Level 1: Initial

Level 2: Repeatable

Level 3: Defined

Level 4: Managed

Level 5: Optimizing


The capability maturity model cmm is a specific approach to software process improvement

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


Software process measurement and evaluation

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

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

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

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

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

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

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 step decomposition

Open Cry Auction Step Decomposition

Auction

Open-Cry

Accept Bids From Bidder

Close Auction

Accept Bids From Bidder

Accept One Bid

Submit Bid

Update Best Bid

Accept One Bid


With exceptions

With Exceptions

Auction

Open-Cry

NoMoreBidders

Accept Bids From Bidder

Close Auction

NoMoreBidders

AuctionClosed

AuctionNotClosed

Accept Bids From Bidder

Accept One Bid

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

Submit Bid

AuctionNotClosed

Update Best Bid

Accept One Bid

BidIsHigher

BidIsBetter


With resources

With Resources

agent:Auctioneer

Auction

Open-Cry

bidder:Bidder

NoMoreBidders

Auctioneer

Auctioneer

agent

Accept Bids From Bidder

Close Auction

NoMoreBidders

AuctionClosed

Auctioneer

agent

bidder

AuctionNotClosed

Accept Bids From Bidder

Accept One Bid

AuctionClosed

BidNotHigher

BidNotBetter

DeadlineExpired

agent

auctioneer

Submit Bid

AuctionNotClosed

Update Best Bid

Accept One Bid

BidIsHigher

BidIsBetter


With artifact flow

With Artifact Flow

best: BidReference

Auction

Open-Cry

best: BidReference

NoMoreBidders

Accept Bids From Bidder

Close Auction

NoMoreBidders

AuctionClosed

best: BidReference

bid:Bid

AuctionNotClosed

Accept Bids From Bidder

Accept One Bid

AuctionClosed

BidNotHigher

bid:Bid

BidNotBetter

deadline: Duration 1m

DeadlineExpired

best: BidReference

bid:Bid

Submit Bid

AuctionNotClosed

Update Best Bid

Accept One Bid

BidIsHigher

BidIsBetter


Entire auction

agent:Auctioneer

Entire Auction

best: BidReference

bidder:Bidder

Auction

Open-Cry

Auctioneer

best: BidReference

NoMoreBidders

Auctioneer

agent

Accept Bids From Bidder

Close Auction

NoMoreBidders

Auctioneer

AuctionClosed

best: BidReference

agent

bidder

bid:Bid

AuctionNotClosed

Accept Bids From Bidder

Accept One Bid

AuctionClosed

BidNotHigher

bid:Bid

BidNotBetter

deadline: Duration 1m

DeadlineExpired

best: BidReference

agent

auctioneer

bid:Bid

Submit Bid

AuctionNotClosed

Update Best Bid

Accept One Bid

BidIsHigher

BidIsBetter


Entire auction1

agent:Auctioneer

Entire Auction

best: BidReference

bidder:Bidder

Auction

Open-Cry

Auctioneer

best: BidReference

NoMoreBidders

Auctioneer

agent

Accept Bids From Bidder

Close Auction

NoMoreBidders

Auctioneer

AuctionClosed

best: BidReference

agent

bidder

bid:Bid

AuctionNotClosed

Accept Bids From Bidder

Accept One Bid

AuctionClosed

BidNotHigher

bid:Bid

BidNotBetter

deadline: Duration 1m

DeadlineExpired

best: BidReference

agent

auctioneer

bid:Bid

Submit Bid

AuctionNotClosed

Update Best Bid

Accept One Bid

BidIsHigher

BidIsBetter


Properties checked

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

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

Flowgraph Model of a Leaf Step

LeafPosted

LeafStarted

LeafCompleted

LeafTerminated


Flowgraph model of a sequential step

Substep1

Substepn

Flowgraph Model of a Sequential Step

SeqPosted

SeqStarted

Terminated

Completed

.

Terminated

.

.

Completed

Terminated

Completed

SeqCompleted

SeqTerminated


Flowgraph model of a parallel step

Substep1

Substep2

Flowgraph Model of a Parallel Step

ParPosted

ParStarted

Completed

Completed

Terminated

Terminated

ParCompleted

ParTerminated


Flowgraph model of a try step

Substep1

Substepn

Flowgraph Model of a Try Step

TryPosted

TryStarted

Completed

Terminated

Completed

.

.

.

Terminated

Completed

Terminated

TryTerminated

TryCompleted


Flowgraph model of a choice step

.

Substep1

.

.

Substepn

Flowgraph Model of a Choice Step

ChoicePosted

ChoiceStarted

Substep1HasStarted

Substep1HasNotStarted

SubstepnHasNotStarted

SubstepnHasStarted

. . . . . . . .

ChoiceTerminated

Completed

Terminated

ChoiceCompleted


Analysis results

Analysis Results


Current evaluation projects1

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

Key Challenges

  • Lateral data flow

  • Visualization

  • Efficient execution

  • Clean definitions of abstractions


  • Login