110 likes | 285 Views
Levels of Rigor. Level 0 : No Use of FSTs Level 1 : Use of concepts and notation from discrete math. Level 2 : Use of formalized specification languages with some supporting tools
E N D
Levels of Rigor • Level 0: No Use of FSTs • Level 1: Use of concepts and notation from discrete math. • Level 2: Use of formalized specification languages with some supporting tools • Level 3: Use of formal specification languages with supporting environments, including theorem proving and proof checking tools.
Example of Level 0 specification Calculate the mean average of a set of employee salaries • Read in the List, L, of employee salaries from the Employee file • Sum the values in L in Total • Divide Total by the number of elements in L and output the result
Example of a level 1 specification Calculate the mean average of a set of employee salaries inputempsals: list of N(N is the set of natural numbers) outputavg: R (R is the set of real numbers) Pre-condition empsals ≠ emptylist Post-condition avg = ( ∑ i=1 empsals(i))div #empsals #empsals
Example of a level 2 specification Calculate the mean average of a set of employee salaries Z specification (in this case avg is formed by carrying out an integer division) sum: seqN→ R sum (Ø) = 0 ∀l : seqΝ● sum (l) = head(l) + sum (tail (l) ) Average empsals?:seqΝ avg! : R avg! = sum (empsals?)div#empsals
Choosing appropriate levels of rigor • Justifying designs of critical systems – level 3 • Gain insight into a problem and/or solution – level 2 • Documentation - level 1 • Well-understood problem – level 0
Specification qualities • incompleteif it does not provide any information to determine behavior under particular circumstances • impreciseif it does not provide enough information to determine behavior under particular circumstances • ambiguousif behavior under particular circumstances is open to different interpretations • inconsistentif two statements in the specification contradict each other
Types of FSTs • Specification approach: model-oriented, property-oriented • Specification perspective: process-oriented, state-oriented, object-oriented, … • Semantic basis: operational semantics, denotational semantics, formal logic,… • Analysis approach: model checking, theorem proving, animation/simulation,... • Types of applicable systems: transformational, reactive,…
Formal Reasoning - Why and What? • Once some properties are specified, many others can be inferred • Reasoning enabled usage of formal models as non-executable prototypes • Provides a systematic way to check certain kinds of oversights • Can show that a detailed design is a correct refinement of a more abstract specification • Formal reasoning is sometimes called a proof.
Calculation A train moves at a constant velocity of 60 miles/hr. How far does the train travel in 4 hrs? Distance = velocity * time (definition) = 60 * time (velocity = 60) = 60 * 4 (time = 4) = 240 (Arithmetic) Applies a transitive rule: if a = b and b = c, we can conclude a = c
Calculation and Proof • Calculations need not be arithmetic
Proof and Laws • Proof is valid only if every step is justified • Laws: predicate describe operators, for simplifying expressions and computing values Example: • Predicate: 2 * n = 6 --- constraining values for variables Law: 0 * n = 0 • ( p q ) p q • ( p q ) (p r) p (q r)