Chapter 27 Formal Specification
|
|
- Jemima Glenn
- 6 years ago
- Views:
Transcription
1 Chapter 27 Formal Specification Chapter 27 Formal Specification Slide 1
2 Objectives To explain why formal specification helps discover problems in system requirements. To describe the use of: Algebraic specification techniques, and Model-based specification techniques (including simple pre- and post-conditions). And to introduce Function-based program specification. Chapter 27 Formal Specification Slide 2
3 Formal methods Formal specification is part of a more general collection of techniques known as formal methods. All are based on the mathematical representations and analysis of requirements and software. (cont d) Chapter 27 Formal Specification Slide 3
4 Formal methods (cont d) Formal methods include: Formal specification Specification analysis and property proofs Transformational development Program verification (program correctness proofs) (axiomatic, function theoretic) Specifications are expressed with precisely defined vocabulary, syntax, and semantics. (e.g., model checking ) Chapter 27 Formal Specification Slide 4
5 Acceptance and use Formal methods have not become mainstream as was once predicted, especially in the US. Some reasons: 1. Less costly techniques (e.g., inspections / reviews) have been very successful at increasing system quality. (Hence, the need for formal methods has been reduced.) (cont d) Chapter 27 Formal Specification Slide 5
6 Acceptance and use (cont d) 2. Market changes have made time-tomarket rather than quality the key issue for many systems. (Formal methods do not reduce time-to-market.) 3. Limited scope of formal methods. They re not well-suited to specifying the look and feel of user interfaces. (Many interactive applications are GUI-heavy today.) (cont d) Chapter 27 Formal Specification Slide 6
7 Acceptance and use (cont d) 4. Formal methods are hard to scale up for very large systems. (Although this is rarely necessary.) 5. Start-up costs can be high. 6. The risks of adopting formal methods on most projects are perceived to outweigh the benefits. Chapter 27 Formal Specification Slide 7
8 Acceptance and use (cont d) However, formal specification is an excellent way to find (some common types of) requirements errors and to express requirements unambiguously. Projects which use formal methods invariably report fewer errors in the delivered software. (cont d) Chapter 27 Formal Specification Slide 8
9 Acceptance and use (cont d) In systems where failure must be avoided, the use of formal methods is justified and likely to be cost-effective. In particular, the use of formal methods is increasing in critical system development where safety, reliability, and security are important. Chapter 27 Formal Specification Slide 9
10 Formal specification in the software process Requirements specification Formal specification Requirements elicitation definition High-le vel design System modelling Ar chitectural design a back-end element of requirements elicitation/analysis/specification/validation Chapter 27 Formal Specification Slide 10
11 Formal specification techniques Algebraic approach system is specified in terms of its operations and their relationships via axioms. Model-based approach (including simple pre- and post-conditions) system is specified in terms of a state model and operations are defined in terms of changes to system state. Function-based approach system is specified in terms of its functional behaviour via mathematical abstractions known as intended program functions. Chapter 27 Formal Specification Slide 11
12 Use of formal specification Formal specification is a rigorous process and requires more effort in the early phases of software development. This reduces requirements errors as ambiguities, incompleteness, and inconsistencies are discovered and resolved. Hence, rework due to requirements problems is greatly reduced. Chapter 27 Formal Specification Slide 12
13 Development costs with formal specification C o s t V&V D e s i g n a n d I m p l e m e n t a t i o n V&V D e s i g n a n d I m p l e m e n t a t i o n S p e c i f i c a t i o n S p e c i f i c a t i o n W i t h o u t f o r m a l s p e c i f i c a t i o n W i t h f o r m a l s p e c i f i c a t i o n Chapter 27 Formal Specification Slide 13
14 Algebraic Specification of subsystem interfaces Large systems are normally comprised of sub-systems with well-defined interfaces. Specification of these interfaces allows for their independent development. Interface objects Sub-system A Sub-system B (cont d) Chapter 27 Formal Specification Slide 14
15 Algebraic Specification of subsystem interfaces (cont d) Sub-system interfaces are often defined as abstract data types ( sorts ) or objects. The algebraic approach is particularly wellsuited to the specification of such interfaces. Chapter 27 Formal Specification Slide 15
16 Algebraic specification components Introduction defines the sort (type name) and declares other specifications that are used Description informally describes the operations on the type (the three other components are formal) Signature defines the syntax of the operations in the interface and their parameters Axioms defines the operation semantics by defining axioms which characterize behavior Chapter 27 Formal Specification Slide 16
17 The structure of an algebraic specification < SPECIFICA TION NAME > (Gener ic P ar ameter) sort < name > Introduction imports < LIST OF SPECIFICA TION NAMES > Inf or mal descr iption of the sor t and its oper ations Oper ation signatures setting out the names and the types of the parameters to the operations defined over the sort Axioms defining the oper ations o v er the sor t Chapter 27 Formal Specification Slide 17
18 Types of operations Constructor operations: operations which create or modify entities of the type Inspection operations: operations which evaluate (i.e., reveal) entities of the type being specified Rule of thumb for defining axioms: define an axiom which sets out what is always true for each inspection operation over (i.e., after applying) each (primitive) constructor operation. Chapter 27 Formal Specification Slide 18
19 Operations on a (FIFO linear) List abstract data type Constructor operations which create or modify sort List: Create, Cons and Tail Inspection operations which discover attributes of sort List: Head and Length (LISP fans: Tail = CDR, Head = CAR) Tail is not a primitive operation since it can be defined using Create and Cons. (Thus, axioms are not required for Head and Length over Tail.) Chapter 27 Formal Specification Slide 19
20 List specification LIST ( Elem ) sort List imports INTEGER a FIFO linear list Defines a list where elements are added at the end and removed from the front. The operations are Create, which brings an empty list into existence; Cons, which creates ( Constructs ) a new list with an added member; Length, which evaluates the list size; Head, which evaluates the front element of the list; and Tail, which creates a list by removing the head from its input list. Undefined represents an undefined value of type Elem. Create List Cons (List, Elem) List Head (List) Elem Length (List) Integer T ail (List) List operator names + type info for argument(s) & result Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L =Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 T ail (Create) = Create Create and Cons T ail (Cons (L, v)) = if L =Create then Create else Cons (T ail (L), v) defines Tail in terms of Chapter 27 Formal Specification Slide 20
21 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? Chapter 27 Formal Specification Slide 21
22 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? Chapter 27 Formal Specification Slide 22
23 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) Chapter 27 Formal Specification Slide 23
24 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) Chapter 27 Formal Specification Slide 24
25 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) Chapter 27 Formal Specification Slide 25
26 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) Chapter 27 Formal Specification Slide 26
27 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 27
28 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 28
29 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) Chapter 27 Formal Specification Slide 29
30 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) Chapter 27 Formal Specification Slide 30
31 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 31
32 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) Chapter 27 Formal Specification Slide 32
33 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) Chapter 27 Formal Specification Slide 33
34 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) Chapter 27 Formal Specification Slide 34
35 Recursion in specifications Tail (Cons (L, v)) = if L=Create then Create else Cons (Tail (L), v) Tail (Cons ( [5, 7], 9)) =? = Cons (Tail ( [5, 7] ), 9) (axiom 6) = Cons (Tail (Cons ([5], 7) ), 9) = Cons (Cons (Tail ([5]), 7), 9) (axiom 6) = Cons (Cons (Tail (Cons ([ ], 5) ), 7), 9) = Cons (Cons (Create, 7), 9) (axiom 6) = Cons ( [7], 9) = [7, 9] Chapter 27 Formal Specification Slide 35
36 Exercise What does Head (Tail (L)) do? L [ ] [a] [a, b] [a, b, c] Head (Tail (L)) undefined undefined b b Chapter 27 Formal Specification Slide 36
37 Exercise Are axioms 1-6 sufficient to prove ANY true assertion of the form Head (Tail (L)) = v? Consider ONE EXAMPLE: Head (Tail ([a, b]) = b Chapter 27 Formal Specification Slide 37
38 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Chapter 27 Formal Specification Slide 38
39 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Chapter 27 Formal Specification Slide 39
40 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) Chapter 27 Formal Specification Slide 40
41 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) Chapter 27 Formal Specification Slide 41
42 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) Chapter 27 Formal Specification Slide 42
43 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) Chapter 27 Formal Specification Slide 43
44 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) Chapter 27 Formal Specification Slide 44
45 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) Chapter 27 Formal Specification Slide 45
46 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) Chapter 27 Formal Specification Slide 46
47 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) Chapter 27 Formal Specification Slide 47
48 List specification LIST ( Elem ) sort List imports INTEGER a FIFO linear list Defines a list where elements are added at the end and removed from the front. The operations are Create, which brings an empty list into existence; Cons, which creates a new list with an added member; Length, which evaluates the list size; Head, which evaluates the front element of the list; and Tail, which creates a list by removing the head from its input list. Undefined represents an undefined value of type Elem. Create List Cons (List, Elem) List Head (List) Elem Length (List) Integer T ail (List) List operator names + type info for argument(s) & result Head (Create) = Undefined exception (empty list) Head (Cons (L, v)) = if L =Create then v else Head (L) Length (Create) = 0 Length (Cons (L, v)) = Length (L) + 1 T ail (Create) = Create Create and Cons T ail (Cons (L, v)) = if L =Create then Create else Cons (T ail (L), v) defines Tail in terms of Chapter 27 Formal Specification Slide 48
49 Proof that Head (Tail ([a, b])) = b Head (Tail ([a, b])) = Head (Tail (Cons ([a], b))) = Head (Cons (Tail ([a]), b)) (axiom 6) = Head (Cons (Tail (Cons ([ ], a)), b)) = Head (Cons ([ ], b)) (axiom 6) = b (axiom 2) Chapter 27 Formal Specification Slide 49
50 Question So, we can prove Head (Tail ([a, b])) = b using the given axioms, but how could one show that the axioms are sufficient to prove ANY true assertion of the form Head (Tail (L)) = v? (Hint: consider mathematical induction on the length of L.) Moral: Showing correctness and completeness of algebraic specifications can be tricky! Chapter 27 Formal Specification Slide 50
51 Model-based specification Algebraic specification can be cumbersome when object operations are not independent of object state (i.e., the result of previous operations). (System State) Model-based specification exposes the system state and defines operations in terms of changes to that state. (cont d) Chapter 27 Formal Specification Slide 51
52 Model-based specification (cont d) Z (pronounced zed and named after Zermelo-Fraenkel set theory) is a mature notation for model-based specification. Combines formal and informal descriptions and incorporates graphical highlighting. Based on notation used in axiomatic set theory, lambda calculus, and first-order predicate logic. (cont d) Chapter 27 Formal Specification Slide 52
53 Model-based specification (cont d) The basic building blocks of Z-based specifications are schemas. Schemas identify state variables and define constraints and operations in terms of those variables. Chapter 27 Formal Specification Slide 53
54 The structure of a Z schema NAME SIGNATURE Container contents: N capacity: N Natural numbers (0, 1, 2, ) (defines schema state) PREDICATE contents capacity (invariants, pre- & postconditions) Chapter 27 Formal Specification Slide 54
55 An insulin pump insulin Needle assembly delivery Sensor glucose level Insulin reservoir Pump Controller Clock Alarm Display1 Display2 text messages dose delivered Power supply Chapter 27 Formal Specification Slide 55
56 Modelling the insulin pump embedded control system The schema models the system as a number of state variables: reading? from glucose level sensor dose, cumulative_dose r0, r1, r2 last 3 glucose level readings capacity capacity of insulin reservoir insulin_available insulin reservoir level alarm! signals exceptional conditions pump! output for pump device display1!, display2! text messages & dose Names followed by a? are inputs, names followed by a! are outputs. Chapter 27 Formal Specification Slide 56
57 Insulin pump schema signature INSULIN_PUMP_STATE //Input device definition switch?: (off, manual, auto) ManualDeliveryButton?: Reading?: HardwareTest?: (OK, batterylow, pumpfail, sensorfail, deliveryfail) InsulinReservoir?: (present, notpresent) Needle?: (present, notpresent) clock?: TIME //Output device definition alarm! = (on, off) display1!, string display2!: string clock!: TIME dose!: (cont d) Chapter 27 Formal Specification Slide 57
58 Insulin pump schema signature (cont'd) // INSULIN_PUMP_STATE (Cont'd) // State variables used for dose computation status: (running, warning, error) r0, r1, r2: capacity, insulin_available : max_daily_dose, max_single_dose, minimum_dose: safemin, safemax: CompDose, cumulative_dose: Chapter 27 Formal Specification Slide 58
59 Schema predicates Each Z schema has a predicate part which defines conditions that are always true (schema invariants) For the insulin pump schema, for example, it is always true that: The dose must be less than or equal to the insulin available in the reservoir. No single dose may be more than 4 units of insulin, and the total dose delivered in a 24 hour time period must not exceed 25 units of insulin (safety constraints). display2! shows the amount of insulin to be delivered. Chapter 27 Formal Specification Slide 59
60 Insulin pump schema predicate // INSULIN_PUMP_STATE (Cont'd) r2 = Reading? dose! insulin_available insulin_available capacity // The cumulative dose of insulin delivered is set to zero once every 24 hours clock? = cumulative_dose = 0 // If the cumulative dose exceeds the limit then operation is suspended cumulative_dose max_daily_dose ( status = error display1! = Daily dose exceeded ) // Pump configuration parameters capacity = 100 safemin = 6 safemax = 14 max_daily_dose = 25 max_single_dose = 4 minimum_dose = 1 display2! = nat_to_string (dose!) clock! = clock? Chapter 27 Formal Specification Slide 60
61 The dosage computation The insulin pump computes the amount of insulin required by comparing the current reading with two previous readings. If these suggest that blood glucose is rising then insulin is delivered. Information about the total dose delivered is maintained to allow the safety check invariant to be applied. Note that this invariant always applies - there is no need to repeat it in the dosage computation. Chapter 27 Formal Specification Slide 61
62 RUN schema RUN INSULIN_PUMP_STATE operations change state Note [ switch? = auto status = running status = warning insulin_available max_single_dose cumulative_dose < max_daily_dose // The dose of insulin is computed depending on the blood sugar level (SUGAR_LOW SUGAR_OK SUGAR_HIGH) // 1. If the computed insulin dose is zero, don t deliver any insulin CompDose = 0 dose! = 0 Л // 2. The maximum daily dose would be exceeded if the computed dose was delivered so the insulin dose is set to the difference between the maximum allowed daily dose and the cumulative dose delivered so far Л CompDose + cumulative_dose > max_daily_dose alarm! = on status = warning dose! = max_daily_dose cumulative_dose imports state & predicates x - value of x after operation Chapter 27 Formal Specification Slide 62
63 RUN schema (cont'd) // RUN (cont'd) // 3. The normal situation. If maximum single dose is not exceeded then deliver the computed dose. If the single dose computed is too high, restrict the dose delivered to the maximum single dose. Л CompDose + cumulative_dose < max_daily_dose ( CompDose max_single_dose dose! = CompDose Л Л CompDose > max_single_dose dose! = max_single_dose ) insulin_available = insulin_available dose! cumulative_dose = cumulative_dose + dose! insulin_available max_single_dose * 4 ( status = warning display1! = Insulin low ) r1 = r2 r0 = r1 ] Chapter 27 Formal Specification Slide 63
64 Sugar OK schema predicate SUGAR_OK [ r2 safemin r2 safemax // sugar level stable or falling Л r2 r1 CompDose = 0 // sugar level increasing but rate of increase falling r2 > r1 (r2-r1) < (r1-r0) CompDose = 0 Л // sugar level increasing and rate of increase increasing compute dose // a minimum dose must be delivered if rounded to zero r2 > r1 (r2-r1) (r1-r0) (round ((r2-r1)/4) = 0) CompDose = minimum_dose Л Л r2 > r1 (r2-r1) (r1-r0) (round ((r2-r1)/4) > 0) CompDose = round ((r2-r1)/4)] Chapter 27 Formal Specification Slide 64
65 Specification via Pre- and Post- Conditions Predicates that (when considered together) reflect a program s intended functional behavior are defined over its state variables. Pre-condition: expresses constraints on program variables before program execution. An implementer may assume these will hold BEFORE program execution. Chapter 27 Formal Specification Slide 65
66 Specification via Pre- and Post- Conditions (cont d) Post-condition: expresses conditions / relationships among program variables after execution. These capture any obligatory conditions AFTER program execution. Language: predicate calculus Predicates (X>4) Connectives (Л, V,,, NOT) Universal and existential quantifiers ( for every, there exists ) Rules of inference (if A Л (A B) then B) Chapter 27 Formal Specification Slide 66
67 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: Post-cond: Chapter 27 Formal Specification Slide 67
68 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: Post-cond: Chapter 27 Formal Specification Slide 68
69 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: Chapter 27 Formal Specification Slide 69
70 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Chapter 27 Formal Specification Slide 70
71 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Suppose LIST is initially [18, -4, 6] and after sorting is [1, 2, 3] Chapter 27 Formal Specification Slide 71
72 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Л??? Suppose LIST is initially [18, -4, 6] and after sorting is [1, 2, 3] Chapter 27 Formal Specification Slide 72
73 Example 1 Sort a non-empty array LIST[1..N] into increasing order. Pre-cond: N 1 Post-cond: For_Every i, 1 i N-1, LIST[i] LIST[i+1] Л PERM(LIST,LIST ) where PERM(A,B) A is a permutation of B (and vice-versa) Chapter 27 Formal Specification Slide 73
74 Example 2 Search a non-empty, ordered array LIST[1..N] for the value stored in KEY. If present, set FOUND to true and J to an index of LIST which corresponds to KEY. Otherwise, set FOUND to false. Chapter 27 Formal Specification Slide 74
75 Example 2 Search a non-empty, ordered array LIST[1..N] for the value stored in KEY. If present, set FOUND to true and J to an index of LIST which corresponds to KEY. Otherwise, set FOUND to false. Chapter 27 Formal Specification Slide 75
76 Example 2 Pre-cond: N 1 Л LIST is ordered (?) Post-cond: Chapter 27 Formal Specification Slide 76
77 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: Chapter 27 Formal Specification Slide 77
78 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: Chapter 27 Formal Specification Slide 78
79 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Chapter 27 Formal Specification Slide 79
80 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Consider the search program: Begin End FOUND := False Chapter 27 Formal Specification Slide 80
81 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND)] Consider the search program: Begin End FOUND := False Chapter 27 Formal Specification Slide 81
82 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л ) V (NOT FOUND Л )] Chapter 27 Formal Specification Slide 82
83 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л )] Chapter 27 Formal Specification Slide 83
84 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Chapter 27 Formal Specification Slide 84
85 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Consider the search program: Begin LIST := [1, 2, 3] Key := 17 FOUND := False End Chapter 27 Formal Specification Slide 85
86 Example 2 Pre-cond: N 1 Л [( LIST is in increasing order ) V ( LIST is in decreasing order )] (Exercise: express the two ordered predicates above FORMALLY.) Post-cond: [(FOUND Л There_Exists i, 1 i N J=i Л LIST[J]=Key) V (NOT FOUND Л For_Every i, 1 i N, LIST[i] KEY)] Л UNCH(LIST,KEY) where UNCH(X 1, X 2, ) For_Every i, X i = X i Chapter 27 Formal Specification Slide 86
87 Exercise See PRE- AND POST-CONDITION SPECIFICATION EXERCISES on course website. Chapter 27 Formal Specification Slide 87
88 Function-based specification Defines required program behavior in terms of intended program functions. These define mappings from initial to final data states and can be (manually) expanded into program control structures. The correctness of an expansion (program) can be determined by considering correctness conditions associated with the control structures relative to the intended function. Chapter 27 Formal Specification Slide 88
89 Relations and functions A relation, r, is a set whose members (if any) are all ordered pairs. The set composed of the first member of each pair is called the domain of r and is denoted D(r). Members of D(r) are called arguments of r. A function, f, is a relation such that for each x D(f) there exists a unique element (x,y) f. (cont d) Chapter 27 Formal Specification Slide 89
90 Relations and functions (cont d) We often express this as y = f(x), where y is the unique value corresponding to x in the function f. It is the uniqueness of y that distinguishes a function from a relation. Chapter 27 Formal Specification Slide 90
91 Program specification Program data mappings may be specified via use of a concurrent assignment function. The domain of the function corresponds to the initial data states that would be transformed into final data states by a suitable program. Consider, for example, the conditional function: f = (y 0 x, y := x+y, 0) (cont d) Chapter 27 Formal Specification Slide 91
92 Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: Chapter 27 Formal Specification Slide 92
93 Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and Chapter 27 Formal Specification Slide 93
94 Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and the final value of y is 0... Chapter 27 Formal Specification Slide 94
95 Program specification (cont d) f = (y 0 x, y := x+y, 0) specifies a program for which: the final value of x is the sum of the initial values of x and y, and the final value of y is 0... if y is initially 0. Otherwise, the program would not terminate (since f is not defined in this case). Chapter 27 Formal Specification Slide 95
96 Example 3 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? If y 0 then x := x+y y := 0 end_if Chapter 27 Formal Specification Slide 96
97 Example 3 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? NO! If y 0 then x := x+y y := 0 end_if Chapter 27 Formal Specification Slide 97
98 Example 4 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? While y <> 0 do x := x+1 y := y-1 end_while Chapter 27 Formal Specification Slide 98
99 Example 4 f = (y 0 x, y := x+y, 0) Is f equivalent to the function computed by the following program? YES! While y <> 0 do x := x+1 y := y-1 end_while Chapter 27 Formal Specification Slide 99
100 Key points Formal system specification complements informal specification techniques. Formal specifications are precise and unambiguous. They remove areas of doubt in a specification. Formal specification forces an analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper than modifying a delivered system. (cont d) Chapter 27 Formal Specification Slide 100
101 Key points (cont d) Formal specification techniques are most applicable in the development of critical systems. Algebraic techniques are particularly well suited to specifying interfaces of objects and abstract data types. In model-based specification, operations are defined in terms of changes to system state. (cont d) Chapter 27 Formal Specification Slide 101
102 Key points (cont d) A program s required functional behaviour may also be specified via an intended function. The domain of the function corresponds to the initial data states that would be transformed into final data states by a suitable program. Chapter 27 Formal Specification Slide 102
103 Chapter 27 Formal Specification Chapter 27 Formal Specification Slide 103
Chapter 10 Formal Specification
Chapter 10 Formal Specification Ian Sommerville 2000 Software Engineering, Chapter 10 Slide 1 Objectives To explain why formal specification helps discover problems in system requirements. To describe
More informationFormal Specification. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 10 Slide 1
Formal Specification Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 10 Slide 1 Objectives To explain why formal specification techniques help discover problems in system requirements To
More informationΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΗ 11: Τυποποιημένες (Formal) Προδιαγραφές ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software Engineering,
More informationTechniques for the unambiguous specification of software
Formal Techniques for the unambiguous of software Objectives To explain why formal techniques help discover problems in system requirements To describe the use of algebraic techniques for interface To
More informationFormal Specification. Objectives
Formal Specification cmsc435-1 Objectives To explain why formal specification techniques help discover problems in system requirements To describe the use of algebraic techniques for interface specification
More informationYou have 45 minutes to work on this exam. It is a "closed-book/closed-notes" test.
NAME (as it appears on your UF ID): (Please PRINT) UF Student ID#: ----------------------------- CEN 5035 - Software Engineering --------------------------- Exam 3 Fall 2014 You have 45 minutes to work
More informationProgramming Languages Third Edition
Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand
More informationChapter 3 (part 3) Describing Syntax and Semantics
Chapter 3 (part 3) Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings
More informationShell CSCE 314 TAMU. Haskell Functions
1 CSCE 314: Programming Languages Dr. Dylan Shell Haskell Functions 2 Outline Defining Functions List Comprehensions Recursion 3 Conditional Expressions As in most programming languages, functions can
More informationContents. Chapter 1 SPECIFYING SYNTAX 1
Contents Chapter 1 SPECIFYING SYNTAX 1 1.1 GRAMMARS AND BNF 2 Context-Free Grammars 4 Context-Sensitive Grammars 8 Exercises 8 1.2 THE PROGRAMMING LANGUAGE WREN 10 Ambiguity 12 Context Constraints in Wren
More informationNAME (as it appears on your UF ID): (Please PRINT) CEN Software Engineering
NAME (as it appears on your UF ID): (Please PRINT) UF Student ID#: ------------------------------- CEN 5035 - Software Engineering ----------------------------- Exam 2 Fall 2010 You have 90 minutes to
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationScheme. Functional Programming. Lambda Calculus. CSC 4101: Programming Languages 1. Textbook, Sections , 13.7
Scheme Textbook, Sections 13.1 13.3, 13.7 1 Functional Programming Based on mathematical functions Take argument, return value Only function call, no assignment Functions are first-class values E.g., functions
More informationTopic Formal Methods. ICS 121 Lecture Notes. What are Formal Methods? What are Formal Methods? Formal Specification in Software Development
Lecture Notes What are? 1 Formal Method (FM) = specification language + formal reasoning Body of techniques supported by precise mathematics powerful analysis tools Rigorous effective mechanisms for system
More informationCSCE 314 TAMU Fall CSCE 314: Programming Languages Dr. Flemming Andersen. Haskell Functions
1 CSCE 314: Programming Languages Dr. Flemming Andersen Haskell Functions 2 Outline Defining Functions List Comprehensions Recursion 3 Conditional Expressions As in most programming languages, functions
More informationSemantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics
There is no single widely acceptable notation or formalism for describing semantics Operational Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The
More informationCMSC 330: Organization of Programming Languages. Operational Semantics
CMSC 330: Organization of Programming Languages Operational Semantics Notes about Project 4, Parts 1 & 2 Still due today (7/2) Will not be graded until 7/11 (along with Part 3) You are strongly encouraged
More informationCOSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor
COSC252: Programming Languages: Semantic Specification Jeremy Bolton, PhD Adjunct Professor Outline I. What happens after syntactic analysis (parsing)? II. Attribute Grammars: bridging the gap III. Semantic
More informationFormal Systems and their Applications
Formal Systems and their Applications Dave Clarke (Dave.Clarke@cs.kuleuven.be) Acknowledgment: these slides are based in part on slides from Benjamin Pierce and Frank Piessens 1 Course Overview Introduction
More information1.3. Conditional expressions To express case distinctions like
Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a
More information! Use of formal notations. ! in software system descriptions. ! for a broad range of effects. ! and varying levels of use. !
What Are Formal Methods? David S. Rosenblum ICS 221 Winter 2001! Use of formal notations! first-order logic, state machines, etc.! in software system descriptions! system models, constraints, specifications,
More informationLecture 5 - Axiomatic semantics
Program Verification March 2014 Lecture 5 - Axiomatic semantics Lecturer: Noam Rinetzky Scribes by: Nir Hemed 1.1 Axiomatic semantics The development of the theory is contributed to Robert Floyd, C.A.R
More information1. true / false By a compiler we mean a program that translates to code that will run natively on some machine.
1. true / false By a compiler we mean a program that translates to code that will run natively on some machine. 2. true / false ML can be compiled. 3. true / false FORTRAN can reasonably be considered
More informationZ Notation. June 21, 2018
Z Notation June 21, 2018 1 Definitions There are many different ways to introduce an object in a Z specification: declarations, abbreviations, axiomatic definitions, and free types. Keep in mind that the
More informationIntroduction to Scheme
How do you describe them Introduction to Scheme Gul Agha CS 421 Fall 2006 A language is described by specifying its syntax and semantics Syntax: The rules for writing programs. We will use Context Free
More informationChapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction
Topics Chapter 3 Semantics Introduction Static Semantics Attribute Grammars Dynamic Semantics Operational Semantics Axiomatic Semantics Denotational Semantics 2 Introduction Introduction Language implementors
More informationSOFTWARE ENGINEERING DESIGN I
2 SOFTWARE ENGINEERING DESIGN I 3. Schemas and Theories The aim of this course is to learn how to write formal specifications of computer systems, using classical logic. The key descriptional technique
More informationCMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics
Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End
More informationCOP4020 Programming Languages. Functional Programming Prof. Robert van Engelen
COP4020 Programming Languages Functional Programming Prof. Robert van Engelen Overview What is functional programming? Historical origins of functional programming Functional programming today Concepts
More informationFunctional Languages. Hwansoo Han
Functional Languages Hwansoo Han Historical Origins Imperative and functional models Alan Turing, Alonzo Church, Stephen Kleene, Emil Post, etc. ~1930s Different formalizations of the notion of an algorithm
More informationThis is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS
1 THE FORMALIZATION OF MATHEMATICS by Harvey M. Friedman Ohio State University Department of Mathematics friedman@math.ohio-state.edu www.math.ohio-state.edu/~friedman/ May 21, 1997 Can mathematics be
More informationLists. Michael P. Fourman. February 2, 2010
Lists Michael P. Fourman February 2, 2010 1 Introduction The list is a fundamental datatype in most functional languages. ML is no exception; list is a built-in ML type constructor. However, to introduce
More informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Describing the Meanings of Programs: Dynamic Semantics Copyright 2015 Pearson. All rights reserved. 2 Semantics There is no
More informationHandout 9: Imperative Programs and State
06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative
More informationAxiomatic Specification. Al-Said, Apcar, Jerejian
Axiomatic Specification Al-Said, Apcar, Jerejian 1 Axioms: Wffs that can be written down without any reference to any other Wffs. Wffs that are stipulated as unproved premises for the proof of other wffs
More informationGoals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1
Natural Semantics Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1 1 Natural deduction is an instance of first-order logic; that is, it is the formal
More informationFunctional programming with Common Lisp
Functional programming with Common Lisp Dr. C. Constantinides Department of Computer Science and Software Engineering Concordia University Montreal, Canada August 11, 2016 1 / 81 Expressions and functions
More informationQ Body of techniques supported by. R precise mathematics. R powerful analysis tools. Q Rigorous, effective mechanisms for system.
Introduction to Formal Methods 1 Introduction to Formal Methods 2 Formal Specification Requirements specification R notational statement of system services Software specification R formal abstract depiction
More informationAn Annotated Language
Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of
More informationTail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)
CMSC 330: Organization of Programming Languages Tail Calls A tail call is a function call that is the last thing a function does before it returns let add x y = x + y let f z = add z z (* tail call *)
More informationA Michael Jackson presentation. CSE503: Software Engineering. The following slides are from his keynote at ICSE 1995
A Michael Jackson presentation CSE503: Software Engineering The following slides are from his keynote at ICSE 1995 David Notkin University of Washington Computer Science & Engineering Spring 2006 1 2 3
More informationChapter 3. Describing Syntax and Semantics ISBN
Chapter 3 Describing Syntax and Semantics ISBN 0-321-49362-1 Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the
More informationChapter 3. Describing Syntax and Semantics
Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:
More informationFunctional Programming. Big Picture. Design of Programming Languages
Functional Programming Big Picture What we ve learned so far: Imperative Programming Languages Variables, binding, scoping, reference environment, etc What s next: Functional Programming Languages Semantics
More informationThe Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England
The Formal Semantics of Programming Languages An Introduction Glynn Winskel The MIT Press Cambridge, Massachusetts London, England Series foreword Preface xiii xv 1 Basic set theory 1 1.1 Logical notation
More informationA Short Introduction to Formal Specifications
A Short Introduction to Formal Specifications Prof. Dr. Hans J. Schneider Lehrstuhl für Programmiersprachen und Programmiermethodik Friedrich-Alexander-Universität Erlangen-Nürnberg 30.11.2000 Methods
More informationPolymorphic lambda calculus Princ. of Progr. Languages (and Extended ) The University of Birmingham. c Uday Reddy
06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 6: Polymorphic Type Systems 1. Polymorphic
More informationFunctional Programming. Pure Functional Languages
Functional Programming Pure functional PLs S-expressions cons, car, cdr Defining functions read-eval-print loop of Lisp interpreter Examples of recursive functions Shallow, deep Equality testing 1 Pure
More informationA Small Interpreted Language
A Small Interpreted Language What would you need to build a small computing language based on mathematical principles? The language should be simple, Turing equivalent (i.e.: it can compute anything that
More informationSimply-Typed Lambda Calculus
#1 Simply-Typed Lambda Calculus #2 Back to School What is operational semantics? When would you use contextual (small-step) semantics? What is denotational semantics? What is axiomatic semantics? What
More informationCS 242. Fundamentals. Reading: See last slide
CS 242 Fundamentals Reading: See last slide Syntax and Semantics of Programs Syntax The symbols used to write a program Semantics The actions that occur when a program is executed Programming language
More informationCSCC24 Functional Programming Scheme Part 2
CSCC24 Functional Programming Scheme Part 2 Carolyn MacLeod 1 winter 2012 1 Based on slides from Anya Tafliovich, and with many thanks to Gerald Penn and Prabhakar Ragde. 1 The Spirit of Lisp-like Languages
More informationMIDTERM EXAMINATION. CSE 130: Principles of Programming Languages. Professor Goguen. February 16, points total
CSE 130, Winter 2006 MIDTERM EXAMINATION CSE 130: Principles of Programming Languages Professor Goguen February 16, 2006 100 points total Don t start the exam until you are told to. Turn off any cell phone
More informationA CRASH COURSE IN SEMANTICS
LAST TIME Recdef More induction NICTA Advanced Course Well founded orders Slide 1 Theorem Proving Principles, Techniques, Applications Slide 3 Well founded recursion Calculations: also/finally {P}... {Q}
More informationLectures 20, 21: Axiomatic Semantics
Lectures 20, 21: Axiomatic Semantics Polyvios Pratikakis Computer Science Department, University of Crete Type Systems and Static Analysis Based on slides by George Necula Pratikakis (CSD) Axiomatic Semantics
More informationLOGIC AND DISCRETE MATHEMATICS
LOGIC AND DISCRETE MATHEMATICS A Computer Science Perspective WINFRIED KARL GRASSMANN Department of Computer Science University of Saskatchewan JEAN-PAUL TREMBLAY Department of Computer Science University
More informationFunctional Programming. Pure Functional Programming
Functional Programming Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends only on the values of its sub-expressions (if any).
More informationRecursion and Structural Induction
Recursion and Structural Induction Mukulika Ghosh Fall 2018 Based on slides by Dr. Hyunyoung Lee Recursively Defined Functions Recursively Defined Functions Suppose we have a function with the set of non-negative
More information11/6/17. Functional programming. FP Foundations, Scheme (2) LISP Data Types. LISP Data Types. LISP Data Types. Scheme. LISP: John McCarthy 1958 MIT
Functional programming FP Foundations, Scheme (2 In Text: Chapter 15 LISP: John McCarthy 1958 MIT List Processing => Symbolic Manipulation First functional programming language Every version after the
More informationFormal Methods. CITS5501 Software Testing and Quality Assurance
Formal Methods CITS5501 Software Testing and Quality Assurance Pressman, R. Software Engineering: A Practitioner s Approach. Chapter 28. McGraw-Hill, 2005 The Science of Programming, David Gries, 1981
More informationCS 61A Interpreters, Tail Calls, Macros, Streams, Iterators. Spring 2019 Guerrilla Section 5: April 20, Interpreters.
CS 61A Spring 2019 Guerrilla Section 5: April 20, 2019 1 Interpreters 1.1 Determine the number of calls to scheme eval and the number of calls to scheme apply for the following expressions. > (+ 1 2) 3
More informationLisp. Versions of LISP
Lisp Versions of LISP Lisp is an old language with many variants Lisp is alive and well today Most modern versions are based on Common Lisp LispWorks is based on Common Lisp Scheme is one of the major
More informationFormal Specification: Z Notation. CITS5501 Software Testing and Quality Assurance
Formal Specification: Z Notation CITS5501 Software Testing and Quality Assurance The Zed Notation, J.M.Spivey. Semester 1, 2017 A Formal Specification Notation A Syntax - often based on set theory and
More informationFunctional Programming
Functional Programming CS331 Chapter 14 Functional Programming Original functional language is LISP LISt Processing The list is the fundamental data structure Developed by John McCarthy in the 60 s Used
More informationPart II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?
Part II. Hoare Logic and Program Verification Part II. Hoare Logic and Program Verification Dilian Gurov Props: Models: Specs: Method: Tool: safety of data manipulation source code logic assertions Hoare
More informationFunctional Programming. Pure Functional Languages
Functional Programming Pure functional PLs S-expressions cons, car, cdr Defining functions read-eval-print loop of Lisp interpreter Examples of recursive functions Shallow, deep Equality testing 1 Pure
More informationNote that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.
CS 6110 S18 Lecture 8 Structural Operational Semantics and IMP Today we introduce a very simple imperative language, IMP, along with two systems of rules for evaluation called small-step and big-step semantics.
More informationCSC 501 Semantics of Programming Languages
CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this
More informationSoftware Engineering 2 A practical course in software engineering. Ekkart Kindler
Software Engineering 2 A practical course in software engineering Quality Management Main Message Planning phase Definition phase Design phase Implem. phase Acceptance phase Mainten. phase 3 1. Overview
More informationChapter 3. Syntax - the form or structure of the expressions, statements, and program units
Syntax - the form or structure of the expressions, statements, and program units Semantics - the meaning of the expressions, statements, and program units Who must use language definitions? 1. Other language
More informationIntroduction to Axiomatic Semantics
Introduction to Axiomatic Semantics Meeting 10, CSCI 5535, Spring 2009 Announcements Homework 3 due tonight Homework 2 is graded 13 (mean), 14 (median), out of 21 total, but Graduate class: final project
More informationProgramming Systems in Artificial Intelligence Functional Programming
Click to add Text Programming Systems in Artificial Intelligence Functional Programming Siegfried Nijssen 8/03/16 Discover thediscover world at the Leiden world University at Leiden University Overview
More informationMIDTERM EXAMINATION - CS130 - Spring 2005
MIDTERM EAMINATION - CS130 - Spring 2005 Your full name: Your UCSD ID number: This exam is closed book and closed notes Total number of points in this exam: 231 + 25 extra credit This exam counts for 25%
More informationMethods for requirements engineering
Methods for requirements engineering Objectives To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce
More informationAn introduction to Scheme
An introduction to Scheme Introduction A powerful programming language is more than just a means for instructing a computer to perform tasks. The language also serves as a framework within which we organize
More informationComputing Fundamentals 2 Introduction to CafeOBJ
Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal Faria, Prof. Heinrich Hußmann. See notes on slides
More informationReasoning About Programs Panagiotis Manolios
Reasoning About Programs Panagiotis Manolios Northeastern University March 22, 2012 Version: 58 Copyright c 2012 by Panagiotis Manolios All rights reserved. We hereby grant permission for this publication
More informationIntroductory logic and sets for Computer scientists
Introductory logic and sets for Computer scientists Nimal Nissanke University of Reading ADDISON WESLEY LONGMAN Harlow, England II Reading, Massachusetts Menlo Park, California New York Don Mills, Ontario
More informationOrganization of Programming Languages CS3200/5200N. Lecture 11
Organization of Programming Languages CS3200/5200N Razvan C. Bunescu School of Electrical Engineering and Computer Science bunescu@ohio.edu Functional vs. Imperative The design of the imperative languages
More informationFormal Specifications
Formal Specifications Course: Software Engineering - Design I Lecturer: email: Dr. Alessandra Russo ar3@doc.ic.ac.uk office hours: available in my office (Room 560) between 1:30-3:30pm on Wednesday. Duration:
More informationChapter 1. Introduction
1 Chapter 1 Introduction An exciting development of the 21st century is that the 20th-century vision of mechanized program verification is finally becoming practical, thanks to 30 years of advances in
More informationPrinciples of Programming Languages
Principles of Programming Languages Lesson 14 Type Checking Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172 1 Type Checking We return to the issue of type safety we discussed informally,
More informationSummer 2017 Discussion 10: July 25, Introduction. 2 Primitives and Define
CS 6A Scheme Summer 207 Discussion 0: July 25, 207 Introduction In the next part of the course, we will be working with the Scheme programming language. In addition to learning how to write Scheme programs,
More informationNotes on Higher Order Programming in Scheme. by Alexander Stepanov
by Alexander Stepanov August 1986 INTRODUCTION Why Scheme? Because it allows us to deal with: 1. Data Abstraction - it allows us to implement ADT (abstact data types) in a very special way. The issue of
More informationThe Prototype Verification System PVS
The Prototype Verification System PVS Wolfgang Schreiner Wolfgang.Schreiner@risc.uni-linz.ac.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.uni-linz.ac.at
More informationSEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION
CHAPTER 5 SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION Alessandro Artale UniBZ - http://www.inf.unibz.it/ artale/ SECTION 5.5 Application: Correctness of Algorithms Copyright Cengage Learning. All
More informationA Brief Introduction to Scheme (II)
A Brief Introduction to Scheme (II) Philip W. L. Fong pwlfong@cs.uregina.ca Department of Computer Science University of Regina Regina, Saskatchewan, Canada Lists Scheme II p.1/29 Lists Aggregate data
More informationAn Evolution of Mathematical Tools
An Evolution of Mathematical Tools From Conceptualization to Formalization Here's what we do when we build a formal model (or do a computation): 0. Identify a collection of objects/events in the real world.
More informationAbstract Specifications: A Review. Algebraic Specification
Abstract Specifications: A Review Computer Science 520/620 Prof. Leon J. Osterweil Spring 2012 Algebraic Specification Draws upon the semantics of modern algebra to form the basis of the semantics of data
More informationCSCE 314 Programming Languages. Type System
CSCE 314 Programming Languages Type System Dr. Hyunyoung Lee 1 Names Names refer to different kinds of entities in programs, such as variables, functions, classes, templates, modules,.... Names can be
More informationFunctional Programming. Overview. Topics. Definition n-th Fibonacci Number. Graph
Topics Functional Programming Christian Sternagel Harald Zankl Evgeny Zuenko Department of Computer Science University of Innsbruck WS 2017/2018 abstract data types, algebraic data types, binary search
More informationComputer Science 520/620 Spring 2014 Prof. L. Osterweil" Modeling Data and Types" Software Models and Representations" Part 5"
Computer Science 520/620 Spring 2014 Prof. L. Osterweil Modeling Data and Types Software Models and Representations Part 5 Modeling Data and Types Representation of Data/Objects Complement to emphasis
More information19 Machine Learning in Lisp
19 Machine Learning in Lisp Chapter Objectives Chapter Contents ID3 algorithm and inducing decision trees from lists of examples. A basic Lisp implementation of ID3 Demonstration on a simple credit assessment
More informationIntroduction to Functional Programming in Racket. CS 550 Programming Languages Jeremy Johnson
Introduction to Functional Programming in Racket CS 550 Programming Languages Jeremy Johnson 1 Objective To introduce functional programming in racket Programs are functions and their semantics involve
More informationChapter 3: Syntax and Semantics. Syntax and Semantics. Syntax Definitions. Matt Evett Dept. Computer Science Eastern Michigan University 1999
Chapter 3: Syntax and Semantics Matt Evett Dept. Computer Science Eastern Michigan University 1999 Syntax and Semantics Syntax - the form or structure of the expressions, statements, and program units
More informationCSE 307: Principles of Programming Languages
CSE 307: Principles of Programming Languages Advanced Topics R. Sekar Topics 1 / 14 1. 2 / 14 Section 1 3 / 14 Semantics of Programs Syntax defines what programs are valid. Semantics defines what the valid
More informationCom S 541. Programming Languages I
Programming Languages I Lecturer: TA: Markus Lumpe Department of Computer Science 113 Atanasoff Hall http://www.cs.iastate.edu/~lumpe/coms541.html TR 12:40-2, W 5 Pramod Bhanu Rama Rao Office hours: TR
More informationFall 2018 Discussion 8: October 24, 2018 Solutions. 1 Introduction. 2 Primitives
CS 6A Scheme Fall 208 Discussion 8: October 24, 208 Solutions Introduction In the next part of the course, we will be working with the Scheme programming language. In addition to learning how to write
More informationScheme: Data. CS F331 Programming Languages CSCE A331 Programming Language Concepts Lecture Slides Monday, April 3, Glenn G.
Scheme: Data CS F331 Programming Languages CSCE A331 Programming Language Concepts Lecture Slides Monday, April 3, 2017 Glenn G. Chappell Department of Computer Science University of Alaska Fairbanks ggchappell@alaska.edu
More informationDefining Languages GMU
Defining Languages CS463 @ GMU How do we discuss languages? We might focus on these qualities: readability: how well does a language explicitly and clearly describe its purpose? writability: how expressive
More information