Understanding Detailed Design in Software Engineering: Verification and Validation, Study notes of Software Development Methodologies

Download Understanding Detailed Design in Software Engineering: Verification and Validation and more Study notes Software Development Methodologies in PDF only on Docsity! How detailed should a "detailed design" be? ensure appropriate function resolve ambiguities enable independent development enable unit testing Enough detail to: Details Tuesday, October 13, 2009 12:16 PM Details Page 1 Overall design: how modules "fit together". Goal of overall design: maximize cohesion, minimize coupling Detailed design: what does each module do? Goal of detailed design: make implementation verifiable. Overall vs Detailed Overall vs Detailed Tuesday, October 13, 2009 12:23 PM Details Page 2 a module is correct if when used as it is intended, it works as expected. For a software developer, lots of bug reports start out, "I tried to do something the software says it won't do, and by George, it doesn't do it." This is not a verification problem! it does not matter what it does when misused! Software engineers wrestle a lot with "program correctness" Program verification Tuesday, October 13, 2009 12:18 PM Details Page 5 Preconditions: what must be true before a function is called. Postconditions: what will be true after a function is called, given that preconditions are met. Invariants: things that remain true before and after each function call. Program correctness for software engineers A set of preconditions, postconditions, and invariants for a function form a contract for a function. Basic program correctness Tuesday, October 13, 2009 12:26 PM Details Page 6 L is a list, E is a new element Preconditions: L is modified so that E is now its head, with all other members preserved. Postconditions: function link-at-head L is a list Preconditions: If L is non-empty, its head is removed and its other elements remain. If L is empty, nothing happens. Postconditions: function unlink-from-head Example: a linked list Example: a linked list Tuesday, October 13, 2009 12:27 PM Details Page 7 start with postconditions work backward one statement at a time. When you get back past the beginning, you have provable preconditions. If these are weaker than or equivalent with stated preconditions, your program is correct. Weakest precondition analysis in action Reference: http://www.cs.wm.edu/~coppit/other- papers/tucker_noonan_ch12.pdf Weakest precondition analysis in action Tuesday, October 13, 2009 1:30 PM Details Page 10 x = x + 1; return x; int inc(int x) { } Preconditions: x is any integer Postconditions: return that integer plus 1 Analysis int inc(int x) { // (2) { x = argument } x = x + 1; // (1) { x = argument + 1 } return x; } Given that result is argument + 1, derived preconditions are that input is argument, which is the same as stated preconditions. Thus A dumb example Tuesday, October 13, 2009 1:32 PM Details Page 11 Key to weakest precondition analysis: Hoare/Floyd Logic A Hoare triple: {before} statement {after} {P} nop {P}: if you do nothing, state doesn't change. e.g., {y=1} x=y {x=1} {P'} x=y {P}: where P' is the result of starting with P and replacing x with y where it occurs. {P} s1 {Q} and {Q} s2 {R} -------------------------------- {P} s1;s2 {R} {P ^ C} A {Q}, {P ^ ¬C} B {Q} -------------------------------------- {P} if (C) then A else B {Q} {C ^ I} while (C) body {¬C} -------------------------------------- {I} while (C) body; {¬C ^ I} {P} body {Q}, P' → P, Q → Q' --------------------------------------------------- {P'} body {Q'} Several axioms: Hoare Logic Monday, October 19, 2009 1:35 PM Details Page 12 There is no way to predict whether a particular Turing machine will halt, other than to run it and observe it. The halting problem: Is testing really the halting problem? The proof of undecidability requires infinite state- space. Any program running in a finite state-space can be analyzed; it is simply intractable to do so. No, for an extremely counter-intuitive reason: My favorite theory Ph.D. qualifying question: "Can a program running in a finite space be undecidable?" The halting problem Tuesday, October 13, 2009 2:55 PM Details Page 15 test cases: what should happen? formal modeling: what should code "do"? Approaches to verification in the design phase Approaches to verification Wednesday, October 14, 2009 1:42 PM Details Page 16 speed requirements make them complicated. if we "leave out" the speed component, we can succinctly describe what should happen. if we "specify" internals in a suitably high-level language, we can show "what to do" without the "how". Fact: most algorithms are fairly simple Formal modeling Wednesday, October 14, 2009 1:44 PM Details Page 17 Unlike normal programming languages, Zed "processes" are assertions of state. Every storage object is a function of its keys A function is a set of associations. salary = { amy -> 500, george -> 200, frank -> 100} salary.amy = 500 salary.george = 200 salary.frank = 100 sets salary to a function with elements salary' = salary { amy -> 600 } # give amy a raise can augment functions salary' = { amy } salary # omit amy from function salary. can remove elements of functions Zed functions Zed functions Wednesday, October 14, 2009 2:13 PM Details Page 20 Zed example Counter.x' = Counter.x + 1 Zed example Wednesday, October 14, 2009 2:04 PM Details Page 21 dom(F) is its domain rng(F) is its range if F is a function An array is a function from integers to its container type! A linked list is a function from its key type to its value type All implementation details are lost! In Z, functions are just sets Coping with functions Wednesday, October 14, 2009 2:37 PM Details Page 22 An advanced Z example: mapping Wednesday, October 14, 2009 2:24 PM Details Page 25 A map is a set of locations Wednesday, October 14, 2009 2:29 PM Details Page 26 Can control everything about this addition Can say whether to duplicate entries or not. Cannot say "how" to accomplish anything! Important: Adding to a map Wednesday, October 14, 2009 2:32 PM Details Page 27 Details Page 30 If one can express program steps as modifications to a state space, then ○ although the steps themselves may be complex as set operations, ○ the resulting program is just a sequence, and○ most loops are not represented in the sequence ○ (other than the trivial overall loop)○ Thus Z specifications are easier to verify than those of a regular programming language.... ○ ... because of the details that Z omits! ○ The big deal of Z The big deal of Z Monday, October 19, 2009 2:06 PM Details Page 31 preconditions are statements in the constraints about input data. postconditions are statements in the constraints about output data. The operation is the whole Z clause. Every Z specification corresponds to a Hoare/Floyd triple, where E.g. Z specifications and Hoare/Floyd logic Monday, October 19, 2009 2:16 PM Details Page 32 Recall the array schema: case 1: 0<=ind?<Array.SIZE case 2: ind?<0 case 3: ind?>=Array.SIZE So, how to test an array? This is a simple example of equivalence partitioning (that we will study later). Dumb example: testing an array Monday, October 19, 2009 2:27 PM Details Page 35 to limit communication between groups to circumscribe behavior so that there are no mistakes in implementation to suggest unit tests of individual modules to aid in verification of the final result detailed design has several roles Summary so far: Summary so far Monday, October 19, 2009 2:22 PM Details Page 36 the public interfaces required for modules. planned interactions between work of different teams The detailed design document should inform implementors of: software interactions within a team/module. private interfaces used only within the module. The detailed design document should not describe Caveats for design Tuesday, October 13, 2009 2:58 PM Details Page 37