View
26
Download
0
Category
Tags:
Preview:
DESCRIPTION
Effective Abstractions for Defining 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”. - PowerPoint PPT Presentation
Citation preview
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
Recommended