Presentation is loading. Please wait.

Presentation is loading. Please wait.

Effective Abstractions for Defining and Verifying Processes Leon J. Osterweil Univ. of Massachusetts Amherst, MA 01003 USA URL: laser.cs.umass.edu.

Similar presentations


Presentation on theme: "Effective Abstractions for Defining and Verifying Processes Leon J. Osterweil Univ. of Massachusetts Amherst, MA 01003 USA URL: laser.cs.umass.edu."— Presentation transcript:

1 Effective Abstractions for Defining and Verifying Processes Leon J. Osterweil Univ. of Massachusetts Amherst, MA USA URL: laser.cs.umass.edu UC Irvine 9 November 2001

2 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

3 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

4 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

5 Our Premise: Processes are software

6 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 should be developed using a (Software development process) development process Software processes should be developed using a (Software development process) development process

7 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

8 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

9 Petri Net Requirements specification process Interview Develop Spec Develop Implementation Developers Real World Users RW_Desc Sys_Spec_Diag Sys_Impl_Diag + Sys_Spec_Diag Design_Spec JSD

10 Decomposition of a part of the Rqts. process Init_Sys_Spec_Diagram 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

11 Design Process Petri net Req_Spec Identify_Object Objects States Identify_Operations Operations Objects States Establish_Visibility Operations ObjectsStates Visibility Establish_Interface Interface Create_Implementation ImplementationInterface Create_Design_Spec Design_Spec BOOD

12 More Identify_Object Req_Spec Identify_Nouns Identify Concrete Object Identify Server Identify Abstract Object Identify Agent Identify Actor Nouns + Req_Spec concrete object server Abstract Object Agent Actor Identify_Class Objects Classes Identify_Attributes Objects States

13 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

14 Data Flow Diagram of Traditional Waterfall Model Requirements Low-Level Design Code Test High-Level Design

15 With Rework Requirements Low-Level Design Code Test High-Level Design

16 With More Rework Requirements Low-Level Design Code Test High-Level Design

17 The Trouble with Dataflow Diagrams Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail?

18 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

19 Variety of Approaches to Code Formalisms 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

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

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

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

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

24 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

25 Questions Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail?

26 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

27 Little-JIL Step Notation TheStepName Interface Badge Prerequisite Badge Postrequisite Badge Sequencing Reactions Handlers ZX

28 Little-JIL Example: “Smart” Regression Test Process RegressionTest GetArtifacts GetExecutable GetTest Cases PerformTest ExecuteTest Report Failure SelectTests Stop ReportResults Get Input Data Get Expected Output Data Run Test Compare Results NoteFailure

29 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:

30 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

31 Proactive Flow Sequencing Kinds Sequential –In order, left to right Parallel Choice –Choose from Agenda Try

32 The Nominal Process Using parallel and sequential step kinds Booch Identify_Classes_and_Objects Identify_Semantics Identify_Relationships Implement Booch Classical Behavioral Use Case

33 More Control Constructs Implement Look_for_Inheritance Look_for_Objects_to_Delegate_to Look_for_Parameterized_Class Custom_Implementation Reuse_Implementation

34 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 InterfaceFilesDo ntCompile

35 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

36 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

37 Assessing Milestones Using Postrequisites In BOOD, defined as conditions on the product In Little-JIL, represented with postrequisites on steps DevelopInterfaceFiles InterfaceFilesCompile InterfaceFilesDo ntCompile

38 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

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

40 Resource Model: Is-A Relationships Resource HumanHardwareSoftwareData Manager Designer PCSparc Design Team BobCarolTedAlice Class Schedulable Class Instance

41 Resource Model: Requires Relationships Resource HumanHardwareSoftwareData Manager Designer PC Sparc Design Team BobCarolTedAlice

42 Resource Model: Whole-Part Relationships Resource HumanHardwareSoftwareData Manager Designer PC Sparc Design Team BobCarolTedAlice

43 An Example Resource Model

44 Resource Request Example IdentifyRelationships SpecifyRelationshipsRefineRelationships Agent: BOODDesigner;expert tool: ClassDiagramEditor artifact: DiagramReposLock Resource request is a query on the Resource specification repository

45 Artifact Flow Booch Identify_Classes_and_Objects Identify_Semantics Identify_Relationships Implement new_ident new_concept

46 Requirements Low-Level Design Code Test High-Level Design Where does output go? What causes this rework? What portion of activity should be done? How do we break this cycle? What to do when reviews fail? Remember These Questions

47 High-Level Process

48 Requirements Details

49 Design Details

50 Requirements Rework

51 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

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

53 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?

54 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

55 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

56 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: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimizing Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: Managed Level 5: Optimizing

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

58 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

59 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?

60 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

61 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

62 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

63 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

64 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 – ….

65 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid Open Cry Auction Step Decomposition

66 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Exceptions NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter

67 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Resources NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter bidder:Bidder Auctioneer agent:Auctioneer Auctioneer agent bidder agent auctioneer

68 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid With Artifact Flow NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter best: BidReference bid:Bid deadline: Duration 1m best: BidReference bid:Bid

69 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid Entire Auction NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter best: BidReference bid:Bid deadline: Duration 1m best: BidReference bid:Bid agent:Auctioneer bidder:Bidder Auctioneer agent bidder Auctioneer agent auctioneer

70 Open-Cry Auction Close Auction Accept Bids From Bidder Accept One Bid Submit Bid Update Best Bid Accept One Bid Entire Auction NoMoreBidders AuctionClosed BidNotHigher BidNotBetter DeadlineExpired AuctionNotClosed BidIsHigher AuctionNotClosed BidIsBetter best: BidReference bid:Bid deadline: Duration 1m best: BidReference bid:Bid agent:Auctioneer bidder:Bidder Auctioneer agent bidder Auctioneer agent auctioneer

71 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

72 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

73 Flowgraph Model of a Leaf Step LeafPosted LeafStarted LeafTerminatedLeafCompleted

74 Flowgraph Model of a Sequential Step SeqPosted SeqStarted SeqTerminatedSeqCompleted Substep 1 Substep n Terminated... Completed

75 Flowgraph Model of a Parallel Step ParPosted ParStarted ParTerminatedParCompleted Substep 1 Substep 2 Terminated Completed

76 Flowgraph Model of a Try Step TryPosted TryStarted TryCompletedTryTerminated Substep 1 Substep n Completed... Terminated Completed

77 Flowgraph Model of a Choice Step ChoicePosted ChoiceStarted ChoiceCompleted ChoiceTerminated Substep 1 Substep n Substep 1 HasNotStartedSubstep n HasNotStarted Substep 1 HasStarted Substep n HasStarted... Terminated Completed …....

78 Analysis Results

79 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

80 Key Challenges Lateral data flow Visualization Efficient execution Clean definitions of abstractions


Download ppt "Effective Abstractions for Defining and Verifying Processes Leon J. Osterweil Univ. of Massachusetts Amherst, MA 01003 USA URL: laser.cs.umass.edu."

Similar presentations


Ads by Google