Descriptive Specifications in Foundations of Software Engineering - Prof. Kenneth M. Ander, Study notes of Software Engineering

Download Descriptive Specifications in Foundations of Software Engineering - Prof. Kenneth M. Ander and more Study notes Software Engineering in PDF only on Docsity! Lecture 11: Descriptive Specifications (Continued) Kenneth M. Anderson Foundations of Software Engineering CSCI 5828 - Spring Semester, 2000 February 22, 2000 © Kenneth M. Anderson, 2000 2 Today’s Lecture • Finish RAISE example • Examine APP Language • Examine Inscape Interface Language February 22, 2000 © Kenneth M. Anderson, 2000 3 RAISE • A Method and a Language • Specification Language: RSL • Specifications Refined in Levels – Associated consistency proof obligations • Proofs of Properties Aided by Tools Rigorous Approach to Industrial Software Engineering February 22, 2000 © Kenneth M. Anderson, 2000 4 Are These Theorems of POTS? ❶¬ ∃ L1, L2, L3 : Line • active_calls(L1) = L3 ∧ active_calls(L2) = L3 ∧ L1 ≠ L2 ❷∀ L1, L2 : Line • place_call(L1, L2) post line_status(L2) = Off_Hook February 22, 2000 © Kenneth M. Anderson, 2000 5 Practical Logic Specifications • Most Software Faults Occur at Interfaces – Typically, function boundaries • Assertions Can Specify Interface Properties – Preconditions to calling a function – Postconditions of returning from a function • Guaranteeing Logical Properties – Dynamic (run-time) assertion checking – Static (compile-time) theorem proving February 22, 2000 © Kenneth M. Anderson, 2000 6 Self-Checking Programs • Dynamic Analysis of Logic-Based Specifications • Examples – Anna (ANNotated Ada) – APP (Annotation PreProcessor for C) • Requires Sample Inputs for Analysis An alternative to program proving February 22, 2000 © Kenneth M. Anderson, 2000 7 APP Assertion Language • Annotations as Structured Comments /*@ … @*/ • Basic Constructs assume (precondition) promise (postcondition) February 22, 2000 © Kenneth M. Anderson, 2000 8 APP Specification void print_warning(code, line, file) int code; int line; char* file; /*@ assume warnings_on; promise warnings_on; @*/ { … } February 22, 2000 © Kenneth M. Anderson, 2000 17 APP Specification of place_call() /*@ 2: assume line_status(L1) == off_hook && active_calls[L1] == 0 && !some(line L3 = 1; L3 < LINE_MAX; L3++) active_calls[L3] == L1; 1: return S where !S || (L1 != L2 && active_calls[L1] == L2 && !in some(line L3 = 1; L3 < LINE_MAX; L3++) active_calls[L3] == L2); @*/ February 22, 2000 © Kenneth M. Anderson, 2000 18 Running with Self-Checking • Sample Diagnostic Output promise violated: file pc.c, line 11, function place_call • Checking-level Is Set at Runtime – No need for recompilation #Run at level 1 $If violations, re-run at level 2 for more info • Violation Actions Can Be Used to Customize and Enhance Diagnostics February 22, 2000 © Kenneth M. Anderson, 2000 19 Logic-based Construction • Logic Used to “Build” Rather Than “Prove” • Functions Specified Independently • Condition Satisfaction Connects Functions – Preconditions and postconditions treated like hardware input and output pins – Postconditions satisfy some preconditions – Preconditions depend on some postconditions February 22, 2000 © Kenneth M. Anderson, 2000 20 Inscape Interface Language • Base Terms – Function and parameter names – Predicates • Preconditions and Postconditions • Special Postcondition: Obligation – Postcondition that must eventually be satisfied February 22, 2000 © Kenneth M. Anderson, 2000 21 Graphical Notation • Routines are presented as rectangles – each condition is numbered • preconditions are placed at the top • postconditions are placed at the bottom • obligations are placed on the right – conditions which “match” are connected • unmatched conditions are propagated to higher level entities February 22, 2000 © Kenneth M. Anderson, 2000 22 Inscape Specification OpenFile (F, &FP) preconditions: LegalFileName(F) O1 FileExists(F) O2 postconditions: LegalFileName(F) O3 FileExists(F) O4 ValidFilePointer(FP) O5 FileOpen(FP) O6 obligations: FileClosed(FP) O7 February 22, 2000 © Kenneth M. Anderson, 2000 23 Example of Graphical Notation OPENFILE O2O1 O6O5O4O3 O7 February 22, 2000 © Kenneth M. Anderson, 2000 24 Inscape Specification CloseFile (&FP) preconditions: ValidFilePointer(FP) C1 FileOpen(FP) C2 postconditions: not(ValidFilePointer(out(FP))) C3 FileClosed(in(FP)) C4 obligations: February 22, 2000 © Kenneth M. Anderson, 2000 25 Example of Graphical Notation OPENFILE O2O1 O6O5O4O3 O7 CLOSEFILE C2C1 C3 C4 February 22, 2000 © Kenneth M. Anderson, 2000 26 Inscape Specification ReadRecord (FP, R, &L,&Buffer) preconditions: ValidFilePointer(FP) R1 FileOpen(FP) R2 LegalRecordNumber(R) R3 RecordExists(R) R4 RecordReadable(R) R5 RecordConsistent(R) R6 February 22, 2000 © Kenneth M. Anderson, 2000 27 Inscape Specification ReadRecord (FP, R, &L,&Buffer) postconditions: ValidFilePointer(FP) R7 FileOpen(FP) R8 LegalRecordNumber(R) R9 RecordExists(R) R10 RecordReadable(R) R11 RecordConsistent(R) R12 Allocated(*Buffer) R13 0 <= L <= Allocated(*Buffer) R14 RecordIn(*Buffer) R15 February 22, 2000 © Kenneth M. Anderson, 2000 28 Inscape Specification ReadRecord (FP, R, &L,&Buffer) obligations: Deallocated(*Buffer) R16