Presentation is loading. Please wait.

Presentation is loading. Please wait.

Reasoning About Precisely Defined Processes Leon J. Osterweil Lab. For Advanced SE Research (LASER) University.

Similar presentations


Presentation on theme: "Reasoning About Precisely Defined Processes Leon J. Osterweil Lab. For Advanced SE Research (LASER) University."— Presentation transcript:

1 Reasoning About Precisely Defined Processes Leon J. Osterweil Lab. For Advanced SE Research (LASER) University of Massachusetts Amherst, MA Institute for Software Research University of California Irvine 25 April 2014

2 Thanks to Collaborators Faculty and Staff Lori A. Clarke George Avrunin Barbara Lerner Sandy Wise Students Bobby Simidchieva M.S. Raunak Stefan Christov Huong Phan Heather Conboy Xiang Zhou Seung Yeob Shin Huong Phan – And others….

3 A Focus on Human-Intensive Systems Integrate contributions of – Software systems – Hardware devices – Human participants They control much of the world’s work – So it is important that they be defect-free, secure They are increasingly complex – Concurrent, distributed, complex, exception rich – Making it hard to be sure of them

4 Some Examples Elections Medical Procedures – Blood transfusion – Chemotherapy administration Software Development Management processes Manufacturing Processes Emergency planning and support

5 Some Examples Elections Medical Procedures – Blood transfusion – Chemotherapy administration Software Development Management processes Manufacturing Processes Emergency planning and support

6 Our Approach Human-intensive systems are collections of processes Model them Analyze them Continuously improve them

7 Copyright L.J.Osterweil All Rights reserved An Example: Health Care Process Engineering ~100,000 people die in US hospitals each year due to preventable medical errors –1999 IOM report estimate –Doesn’t count serious injury, pain-and-suffering, needless cost Errors like: –Transfusing the wrong type of blood –Delivering incorrect medication –Amputating the wrong leg –Removing the healthy lung (leaving the cancerous one in) Recent NY Times article estimates it is probably more like 440,000 deaths per year –Third leading cause of death in the US

8 ~100,000 people each year in US hospitals due to preventable errors One fully loaded 747 per day

9 Another Example: Elections in the U.S. Elections entail far more than casting and tabulating votes Need to consider the entire process – Voting machines play a part – Humans are also key participants – Databases too The election process is large and complex and, in the U.S., varies from jurisdiction to another Election processes vary over time as well Goal To identify potential defects, threats to security, in election processes and evaluate approaches to correcting them

10 Our Approach: Continuous Process Improvement Create a precise, accurate model of a real-world process Use formal analysis methods to automatically identify potential problems in the model – E.g. single points of failure (SPFs) Modify process model to address the problems – Verify that the modification makes things better Deploy improvements in real-world process Approach: Consider a process to be a kind of software: Apply software engineering technologies

11 Programming Human-Intensive Processes Process programming language requirements: –Capture complexity of systems clearly, cleanly, in detail –Rich semantics (e.g. functionality, concurrency, resource utilization, exceptions, human participation) –Precisely defined semantics to support static analysis, simulations, and executions –Understandable to the domain experts (facilitate validation that the definition models actual process)

12 Process definition Properties Model Checker (FLAVERS) Discrete event simulator Failure mode and effects analyzer Fault tree generator Hazards Failure modes Scenario specifications Satisfied properties, violated properties + counterexamples Fault trees, minimal cut sets Effects of failure modes Discrete event simulation runs Little-JIL narrator Property elicitor (PROPEL) Process editor (Little-JIL editor) Textual representation of process definition Process Improvement Environment Architecture Requirements Derivation Derived Requirements Device model Process definition + requirements Analysis Analysis Feedback Improvements, new family members

13 The Little-JIL Process Definition Language Blends proactive and reactive control Coordinates human and automated agents Emphasizes exception specification, management Facilities for abstraction, scoping, hierarchy Supports artifact flow Concurrency, synchronization with message-passing Articulate specification of resources Steps have agents that can be humans, software, hardware Semantics for aborting steps Pre/post condition constructs Facilities for human choice Rigorously defined using finite state machine semantics Visual language

14 “Step” is the central Little-JIL abstraction TheStepName Interface Badge (parameters, resources, agent) Prerequisite Badge Postrequisite Badge Substep sequencing Handlers X Artifact flows Exception type continuation

15 Define an election process Use the Little-JIL process definition language – Consists of coordination diagram, and other specifications (e.g. agents, artifacts, resources) – Especially appropriate for modeling concurrency and complex exception handling that arise in elections – Visual representation facilitates communication and validation

16 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Top-Level, simplified election process

17 Hierarchy, Scoping, and Abstraction in Little-JIL Definition is a hierarchical decomposition Think of steps as procedure invocations –They define scopes –Copy and restore argument semantics Encourages use of abstraction –Eg. system fragment reuse

18 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference = Adding some elaborations Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted

19 Exception Handling: A Special Focus of Little-JIL Steps may have one or more exception handlers Handlers are steps themselves – With parameter flow React to exceptions thrown in descendent steps – By Pre- or Post-requisites – Or by Agents Four different continuations

20 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Fill out provisional ballot Submit provisional ballot And some exception management Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception   Voter Already Checked Off Exception Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted exceptions: ID Mismatch exceptions: ID Mismatch Exceptions: Missing ID Inadmissable ID exceptions: Voter Already Checked Off

21 Properties needed to support Finite-State Verification (Model-Checking) Refine the requirements for an election process – High-level requirements – Low-level requirements – Precise properties, or event sequences Identify event alphabet Annotate graph with events used to define properties Verify the process adheres to the properties – Run formal analysis using finite-state verification

22 Decompose high-level requirements Example refinement of high-level requirement into a collection of low-level requirements each unique voter is allowed at most one vote  voter must receive ballot before choosing to vote  voter must leave voting booth after choosing to vote  voter must be authenticated before entering voting booth  voter must be checked off before entering voting booth  voter must enter voting booth before choosing to vote

23 Formally define the properties Use the PROPEL property elicitation tool to formally define a property corresponding to the low-level requirement “ voter must be authenticated before entering voting booth ”

24 Example property Voter must be authenticated before entering voting booth: Disciplined English view: – VoterEntersVotingBooth cannot occur until after VoterIsAuthenticated has occurred. VoterIsAuthenticated is not required to occur, however. – VoterIsAuthenticated can occur multiple times before the first subsequent VoterEntersVotingBooth occurs. – After VoterIsAuthenticated occurs other events can occur before the first subsequent VoterEntersVotingBooth occurs – After VoterEntersVotingBooth occurs neither VoterIsAuthenticated nor VoterEntersVotingBooth can occur again. FSA view:

25 FLAVERS finite-state verifier Binding property events to process steps Property FSA specified in PROPEL Little-JIL process definition Bindings between property events and process steps Yes, the process satisfies the property No, the property could be violated Here is a counter-example OR

26 Finite-state verification with FLAVERS The FLAVERS FSV verifier has been extended to automatically construct finite models of the Little-JIL process definitions Finite model represents all possible event sequences, for the events in a property, that could occur for all the possible traces through the process definition Apply dataflow analysis algorithm to determine if the model is consistent with the property If the process is inconsistent with the property, a counter-example trace is produced FLAVERS determines whether the election process, as defined in Little-JIL, adheres to the property “voter must be authenticated before entering voting booth”

27 (Voter Already Checked Off Exception) (Voter Enters Voting Booth Event) (Voter Votes Or Does Not Vote Event) (Voter Leaves Voting Booth Event) [pass authentication and vote] [present ID] [perform pre-vote authentication] [let voter vote with provisional ballot] [fill out provisional ballot] [submit provisional ballot] Violation detected An unauthenticated voter can vote with provisional ballot – Counter-example produced by FLAVERS to demonstrate how the property “ voter must be authenticated before entering voting booth ” could be violated

28 Violation detected An unauthenticated voter can vote with provisional ballot – Counter-example produced by FLAVERS to demonstrate how the property “ voter must be authenticated before entering voting booth ” could be violated

29 Violation explanation The parallel step creates a race condition – The pre-vote authentication step is executed in parallel with two others – Exceptions can occur in any order – Exceptions may appear to be independent, but they are not – If confirm voter has not voted wins, that creates problems Forcing sequential execution can correct this situation After correcting the process definition, the FLAVERS verifier can verify that the new process definition satisfies the “ voter must be authenticated before entering voting booth ” property, as well as the other properties

30 Is this a “real” problem? Humans would probably never let this happen – They will be watching and using their judgment But suppose this process were automated? – Steps executed by hardware/software wherever possible – This scenario could actually happen – Would manifest itself as a “bug” Prior diagnostic analysis prevents this

31 In Medical Domain Have found race conditions, deadlocks Unsafe sequences – Administering medication with checking, dosage, permission, etc. – Not being sure to weight patients upon arrival – Letting patients into emergency department without wristbands

32 Other kinds of problems Finite state verification/model checking looks for event sequence defects But assumes that all steps are performed correctly Humans may make errors – Software too Looking for consequences of incorrect performance done using Fault Tree Analysis

33 Fault Tree Analysis (FTA) A well accepted and widely practiced safety analysis technique that identifies all possible combinations of events that could lead to a given hazard –Hazard: A condition in which loss of life or serious loss of property becomes possible Approach –Specify a hazard that is of concern –Create a fault tree for that hazard –Derive Minimal Cut Sets (MCSs)--minimal event combinations that can cause the hazard

34 Process definition Properties Model Checker (FLAVERS) Discrete event simulator Failure mode and effects analyzer Fault tree generator Hazards Failure modes Scenario specifications Satisfied properties, violated properties + counterexamples Fault trees, minimal cut sets Effects of failure modes Discrete event simulation runs Little-JIL narrator Property elicitor (PROPEL) Process editor (Little-JIL editor) Textual representation of process definition Process Improvement Environment Requirements Derivation Derived Requirements Device model Process definition + requirements Analysis Analysis Feedback Improvements, new family members

35 Fault Tree Analysis (FTA) FTA is a deductive, top-down analysis to find out which events in a system could lead to a given hazard A fault tree is a graphical model of various combinations of events that could produce the hazard 35 B ACKGROUND hazard gate primary event

36 Minimal Cut Set (MCS) A minimal cut set (MCS) is a minimal set of primary events all of whose occurrence ensures that the hazard event occurs MCS can be computed automatically from a Fault Tree using Boolean Algebra A MCS indicates a system vulnerability that an adversary may be able to exploit to create the hazard – E.g. A singleton MCS, called a single point of failure (SPF) is a particularly worrisome vulnerability 36 B ACKGROUND

37 Our Approach: Generate the Fault Tree from the Process Definition Specify a hazard –Consider hazards created by the delivery of an incorrect artifact to a process step –Generation based on templates for the semantics of the language Use Fault Tree Analysis to develop all Minimal Cut Sets –Automatically calculated from the fault tree using Boolean algebra

38 Small example part of a real generated fault tree

39 Details of our Approach Use our rigorously defined model of the process – Derived from and validated by domain experts Obtain election hazards from domain experts Apply fault tree analysis – To detect vulnerabilities Using hazard analysis – To define attacks that can exploit the vulnerabilities In ongoing work we are also – Composing attacking and defending processes – Evaluating the defender’s resistance to such attacks Using model checking 39

40 FTA for Medical Processes Use to identify critical steps that should be double-checked

41 Finding Vulnerabilities in The Simple Blood Transfusion Process

42 A Derived Fault Tree

43 Calculating Minimal Cut Sets Each gate corresponds to an equation 1: E1 = E2 2: E2 = E3 + E4 3: E3 = E5 + E6 4: E5 = E7  E8 5: E6 = E9  E13 6: E7 = E11 + E12 7: E9 = E11 + E10 => E1 = ( E4 ) + ( E11 ) + ( E12  E8 ) + ( E10  E13 )

44 Calculating Minimal Cut Sets Each gate corresponds to an equation 1: E1 = E2 2: E2 = E3 + E4 3: E3 = E5 + E6 4: E5 = E7  E8 5: E6 = E9  E13 6: E7 = E11 + E12 7: E9 = E11 + E10 => E1 = ( E4 ) + ( E11 ) + ( E12  E8 ) + ( E10  E13 ) Single points of failure

45 An Actual Generated Fault Tree

46 Process definition Properties Model Checker (FLAVERS) Discrete event simulator Failure mode and effects analyzer Fault tree generator Hazards Failure modes Scenario specifications Satisfied properties, violated properties + counterexamples Fault trees, minimal cut sets Effects of failure modes Discrete event simulation runs Little-JIL narrator Property elicitor (PROPEL) Process editor (Little-JIL editor) Textual representation of process definition Dynamic Analysis too by generating discrete event simulations Requirements Derivation Derived Requirements Device model Process definition + requirements Analysis Feedback Improvements, new family members Process definition + requirements Analysis

47 Driving Simulations to Optimize Resource Allocations Define processes in Little-JIL Hypothesize resource behaviors Define resource allocation strategies Run simulations Tabulate

48 An Example part of an ED process

49 An Example Resource Type specification

50 Some Resource Instance Specifications

51 Priority-based scheduling policy greatly reduces Length of Stay for patients across all acuity levels. Waiting times by acuity level using: Sickest-first scheduling policy

52 Priority-based scheduling policy greatly reduces Length of Stay for patients across all acuity levels. Waiting times by acuity level using: Priority-Based scheduling policy

53 The number of handoffs decreases when doctors and nurses stop accepting new patients 1 hour before their shifts end.

54 Triage Nurse can/cannot place patient in bed Elapsed time (in simulation time units)

55 Summary of Results Found some defects in some healthcare processes Effected a 70% reduction in the number of “errors reaching the patient” at Baystate Oncology Division Identified defects and vulnerabilities in election processes Automating some code refactoring processes While also— – Improving our process language – Creating automated Fault Tree generation/analysis toolset

56 Another Example Domain Elections Medical Procedures – Blood transfusion – Chemotherapy administration Software Development Management processes Manufacturing Processes Emergency planning and support

57 Software Engineering Analysis of Scrum processes – Precise definition(s) – Simulations of task assignment strategies Understanding Rework in software development – What is rework? – Application to refactoring

58 Scrum: Activity Skeleton Development Iteration Sprint Planning MeetingSprintSprint ReviewSprint Retrospective X

59 Scrum Development Iteration Sprint Planning MeetingSprintSprint ReviewSprint Retrospective X product: Product sprint backlog channel: Backlog Channel sprint backlog sprint backlog channel product agent: ScrumMaster owner: ProductOwner deadline: Hours = 4 product: Product product agent: team

60 Now Elaborate on the Sprint Step Development Iteration Sprint Planning MeetingSprintSprint ReviewSprint Retrospective X product: Product sprint backlog channel: Backlog Channel sprint backlog sprint backlog channel product agent: ScrumMaster owner: ProductOwner deadline: Hours = 4 product: Product product agent: team

61 Sprint: Activity Skeleton Sprint Daily Sprint Daily Scrum Checked Work Revise Sprint Backlog = X X 30 + *

62 Sprint Step Details Sprint Daily Sprint Daily Scrum Revise Sprint Backlog = X X sprint backlog sprint backlog channel agent: ScrumMaster team: Team sprint burndown: BurndownTool editor: BacklogTool deadline: Minutes = 15 sprint backlog: Backlog 30 + * product product: Product deadline: Days = 1 agent: Team product: Product agent: Team editor: BacklogTool sprint backlog: Backlog Now elaborate on “Checked Work” Checked Work

63 Checked Work Elaboration Sprint Daily Sprint Daily Scrum Revise Sprint Backlog = X X sprint backlog sprint backlog channel agent: ScrumMaster team: Team sprint burndown: BurndownTool editor: BacklogTool deadline: Minutes = 15 sprint backlog: Backlog 30 + * product product: Product deadline: Days = 1 agent: Team product: Product agent: Team editor: BacklogTool sprint backlog: Backlog Now elaborate on “Checked Work” Checked Work

64 Checked Work Subprocess Work Checked Work Rework Integrate X

65 Checked Work Subprocess Work Checked Work Integrate X Report: Build Failed product: Product Build Failed report Build Fail Report product  X product: Product report: Build Failed := report U Build Fail Report Check Build Report: Build Failed product: Product product agent: Team agent: Builder agent: Team

66 Development Iteration Sprint Planning MeetingSprintSprint ReviewSprint Retrospective X product: Product sprint backlog channel: Backlog Channel sprint backlog sprint backlog channel product agent: ScrumMaster owner: ProductOwner deadline: Hours = 4 Product: Product product agent: team 1 2 “Begin Sprint” event“End Sprint” event

67 Sprint Daily Sprint Daily Scrum Work Revise Sprint Backlog = X X sprint backlog sprint backlog channel agent: ScrumMaster team: Team sprint burndown: BurndownTool editor: BacklogTool deadline: Minutes = 15 sprint backlog: Backlog 30 + * product product: Product deadline: Days = 1 agent: Team product: Product agent: Team editor: BacklogTool sprint backlog: Backlog 3 4

68 Sprint Daily Sprint Daily Scrum Work Revise Sprint Backlog = X X sprint backlog sprint backlog channel agent: ScrumMaster team: Team sprint burndown: BurndownTool editor: BacklogTool deadline: Minutes = 15 sprint backlog: Backlog 30 + * product product: Product deadline: Days = 1 agent: Team product: Product agent: Team editor: BacklogTool sprint backlog: Backlog 3 4 sprint backlog change

69 Sprint Daily Sprint Daily Scrum Work Revise Sprint Backlog = X X sprint backlog sprint backlog channel agent: ScrumMaster team: Team sprint burndown: BurndownTool editor: BacklogTool deadline: Minutes = 15 sprint backlog: Backlog 30 + * product product: Product deadline: Days = 1 agent: Team product: Product agent: Team editor: BacklogTool sprint backlog: Backlog 3 4 sprint backlog change This is benign because the step is performed by Team

70 Simulation of Different Task Assignment Strategies Hypothesized – Distribution of task sizes and difficulties – Distribution of worker coding and testing skill levels – Different team makeups – Different strategies for task assignment Fault injection to simulate coding bugs and inadequate testing Iterate until no more bugs found

71 Different strategies for task assignment Strategies – Random assignment of tasks to workers – Greedy: Hardest tasks to strongest workers – Prev: Tasks not completed reassigned to previously assigned workers – Greedy Prev: Combination of Greedy and Prev Different task assignment strategies produced sharp differences in – Lines of code produced – Number of residual bugs

72

73 What is “rework”? in software development? In other intellectual work?

74 Traditional Software Development Process

75

76 Requirements Develop Rqmt Element Declare and Define Rqmt Define Rqmt ElementDeclare Rqmt Element Develop Rqmt Element ~ Rqmt OK X Inter-requirement Consistency Check + Rqmt OK Rework in a Requirements Specification Sub-Process =

77 Copyright L.J.Osterweil All Rights reserved Rework in a Design Sub-Process

78 Copyright L.J.Osterweil All Rights reserved Requirements Rework May Be Triggered During Design

79 Copyright L.J.Osterweil All Rights reserved Requirements Rework Process

80 Copyright L.J.Osterweil All Rights reserved Contains a Previously Executed Step

81 Copyright L.J.Osterweil All Rights reserved That We Saw Previously Here

82 Copyright L.J.Osterweil All Rights reserved Requirements Rework Invocation of step originally defined as substep of Requirements

83 Copyright L.J.Osterweil All Rights reserved Requirements Rework Invocation of step originally defined as substep of Requirements Same exception thrown

84 Copyright L.J.Osterweil All Rights reserved Requirements Rework Invocation of step originally defined as substep of Requirements Same exception thrown Different invocation context -> different response

85 Copyright L.J.Osterweil All Rights reserved High-Level Design Declare and Define HLDesign Elements Declare HLDesign Element Requirements ~ A Rqmt OK X HLDesign OK Define HLDesign Elements High-Level Design ~ HLD OK Declare HLDesign Elements Develop Rqmt Element ~ Rqmts OK 9 Another Rework-centered Design Process

86 Copyright L.J.Osterweil All Rights reserved Coding Develop Code Modules Define Module Interfaces Code All Modules Define A Module Interface = + X ~Rqmts OK ~HLD OK Low-Level Design Requirements High-Level Design Coding Develop Rqmt Element … … Interface OK Code OK ~LLD OK ~Code OK ~ A Rqmt OK Coding

87 Final Observations Many kinds of analysis applicable to processes – FSV/Model Checking – Fault Tree Analysis – Reachability Analysis – Discrete Event Simulation Requires rigorous definitions of processes and properties/hazards Broadly applicable to many diverse domains

88 What we have learned about system and process software could show us how to do better application software Resource management – Which supports integration of humans “inside the box” Rework – Which entails effective use of retrospection, inspection

89 Resource Management A resource is an entity that is characterized by –Ability to provide one or more “capabilities” Capability: The ability to support doing some task/activity/work –A set of descriptive attributes Attribute: a (name, value) pair Capability set changes with context, circumstances –Attribute values do too A resource is a set of –Guarded capabilities –Guarded attributes

90 Resource Management Seems overlooked in application software – Old view: Software = algorithms + data ??? – New view ?: Software = activities +artifacts+resources Resources rediscovered in Service-orientated software development? A big issue, with lots of hard questions

91 Rework Pervasive in virtually all creative activities The essence is in the data (and resources), rather than the activities Rework is a kind of recursion State reification and inspection helps So does historical retrospection

92 We should focus more on similarities than differences Strong Temptations to do the opposite – And good rewards too Everything is different from everything else But there are often important similarities too – And we should try to learn from similarities – And we should find strong rewards in doing so

93 What we do is more fundamental than we may think Can we carry to other domains our clear insights into: – Abstraction – Concurrency – Analysis/Reasoning – Phased development and evolution And learn from related disciplines about – Rework – “humans in the box” – Agents/resources And fashion an understanding of something still far deeper and more fundamental

94 Thank you and Questions?

95 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Fill out provisional ballot Submit provisional ballot Recall the previous process Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception   Voter Already Checked Off Exception Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted exceptions: ID Mismatch exceptions: ID Mismatch exceptions: Voter Already Checked Off

96 Issue regular ballot Issue provisional ballot Now elaborate the issue ballot step

97 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Fill out provisional ballot Submit provisional ballot Now elaborate the issue ballot step Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception   Voter Already Checked Off Exception Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted exceptions: ID Mismatch exceptions: ID Mismatch exceptions: Voter Already Checked Off Issue regular ballot Issue provisional ballot X

98 Detecting Vulnerabilities in This Process Process has numerous checks and double- checks, but are they enough? What combinations of incorrect performances could cause a hazard? Can the wrong artifact reach – The wrong step – The wrong agent How to find these situations? 98

99 99 An Example Election Process Hazard: An unqualified voter gets to vote with a regular ballot Is modeled, based upon our Little-JIL process definition, as : The “record voter preference” step receives an incorrect “ballot” artifact.

100 Artifact flow Primarily along parent-child edges – As procedure invocation parameters – Passed to exception handlers too – Often omitted from coordination diagrams to reduce visual clutter Parent-child data flow is inadequate – Artifacts also need to flow laterally – And subtasks need to communicate with each other Little-JIL also incorporates channels – For concurrency synchronization, preemption – And for passing data laterally

101 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted Fill out provisional ballot Submit provisional ballot Issue regular ballot Issue provisional ballot X voterName >> >> voterName voterRegistered >> voterQualified >> >> voterQualified voterQualified==true voterRegistered==true voterQualified==false voterQualified==true >> voterQualified ballot >> >> voterQualified >> ballot Add artifact flow (and adjust exception management)  Voter Already Checked Off Exception Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception 

102 The Fault Tree automatically derived from the Little-JIL this process definition 102 P RELIMINEARY R ESULTS Hazard: an unqualified voter gets to vote with a regular ballot Hazard specification using the FTA tool artifact “ballot” input into the step “record voter preference” is wrong

103 The Resulting MCSs There are 11 MCSs in the fault tree Example: 103 P RELIMINEARY R ESULTS 1.Step get voter name produces wrong voterName 2.Step verify voter has not voted does not throw VoterUnregistered exception (while checking prerequisite) 3.Step check off voter as voted does not throw VoterUnqualified exception (while checking prerequisite) 4.Step issue regular ballot does not throw VoterUnqualified exception (while checking prerequisite) One informal interpretation: An imposter provides an incorrect name, but three different checks fail to pick this up. There are other interpretations, too.

104 1.Step get voter name produces wrong voterName 2.Step verify voter has not voted does not throw VoterUnregistered exception (while checking prerequisite) 3.Step check off voter as voted does not throw VoterUnqualified exception (while checking prerequisite) 4.Step issue regular ballot does not throw VoterUnqualified exception (while checking prerequisite) One Interpretation: Imposter provides name of qualified voter who has not yet voted 104 There is really only one incorrectly performed step, namely the first one. The others are “incorrect”, only because they get incorrect input—but they are correct given their inputs

105 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted Fill out provisional ballot Submit provisional ballot Issue regular ballot Issue provisional ballot X voterName >> >> voterName voterRegistered >> voterQualified >> >> voterQualified voterQualified==true voterRegistered==true voterQualified==false voterQualified==true >> voterQualified ballot >> >> voterQualified >> ballot An impostor has the name of a registered voter who has not voted  Voter Already Checked Off Exception Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception 

106 1.Step get voter name produces wrong voterName 2.Step verify voter has not voted does not throw VoterUnregistered exception (while checking prerequisite) 3.Step check off voter as voted does not throw VoterUnqualified exception (while checking prerequisite) 4.Step issue regular ballot does not throw VoterUnqualified exception (while checking prerequisite) Alternative Interpretation: Imposter provides name of qualified voter who has voted, but official does not notice 106

107 pass authentication and vote present ID Perform pre-vote authentication Check off voter as voted Issue ballot Record voter preference Let voter voter with provisional ballot = Confirm voter ID matches voter Confirm voter ID matches voting roll Confirm voter has not voted Fill out provisional ballot Submit provisional ballot Issue regular ballot Issue provisional ballot X voterName >> >> voterName voterRegistered >> voterQualified >> >> voterQualified voterQualified==true voterRegistered==true voterQualified==false voterQualified==true >> voterQualified ballot >> >> voterQualified >> ballot Alternative interpretation: An impostor has the name of a registered voter who has voted, but the election official does not notice  Voter Already Checked Off Exception Missing ID Exception  Inadmissible ID Exception  ID Mismatch Exception 


Download ppt "Reasoning About Precisely Defined Processes Leon J. Osterweil Lab. For Advanced SE Research (LASER) University."

Similar presentations


Ads by Google