Lecture 5: Specifying Java Programs


 Sharon Powell
 1 years ago
 Views:
Transcription
1 Lecture 5: Specifying Java Programs This lecture aims to:! Introduce the basic ingredients of a program specification.! Show how to map ObjectZ specifications into program specifications! Define reasoning rules for» assignment» ifelse statements, Aims and Objectives! Illustrate the use of a defensive and a nondefensive approach in programming Lecture 5: Specifying Java programs Slide Number 1 What is a program specification? It is a form of contract between a software customer and a software producer: The customer provides» software requirements» acceptable conditions The software provides» a program which satisfies the requirements Preconditions Program Postconditions Requirements and acceptable conditions of a software can be derived from more abstract formal specifications (e.g. ObjectZ) Lecture 5: Specifying Java programs Slide Number 2 With the previous lecture notes, we have concluded the first topic of this part of the course, namely objectoriented specifications of system requirements and design. The remaining set of lecture notes will be focused on a lower level of specification, that of a program specification. and on reasoning techniques used to verify the correctness of small Java programs. The main aim of this last part of this course is to introduce basic constructs of an (objectoriented) program specification, and learn simple reasoning rules for checking the correctness of basic program statements such as assignment, ifthenelse, while loop statements, as well as reasoning about the correctness of method calls. We will also see how, and to which extend, an ObjectZ specification can be mapped directly into a program specification and program skeleton. We will conclude this lecture illustrating example programs developed using the defensive and the nondefensive approaches to program design. We will assume, throughout this last part of the course, that program specifications are written in classical logic. Note: My personal thanks to Krysia Broda (examples used in this part of the course are taken from her lecture notes.) A program specification can be seen as a contract between the software customer and the software producer. A software customer is the person who provides the conditions (if required by the software developer) under which the software is supposed to run correctly, as well as the requirements. Such conditions are expressed in a program specification as preconditions, and they are mainly constraints on the input parameters that (components of ) a software system is supposed to receive. The requirements are instead postcondition, constraints on the output of the software, i.e. on the results of (the components of ) the software. The software developer has the task of developing the software and guaranteeing that the requirements are met. A program specification can therefore be seen as an agreement between these two parties, more specifically between the customer and the program (developed). The agreement statement is of the form Provided that the program is used within the agreed conditions (e.g. on input variables), then the program performs the required task. Writing a specification of a program and reasoning with the specification and the program code, means guaranteeing that such agreement is satisfied. We have already seen how to write formal specifications and system requirements, using for instance ObjectZ language. These specifications can almost automatically be mapped into program specifications. We will see in the next few slides examples of such mapping. In doing so we will gradually introduce basic constructs of a program specification. 1 2
2 Formalising specifications: convention Specification expressions are written:» using basic logical notations;» within comments lines of the (Java) programming language» using the following prefixes:» modifies: for list» pre: for preconditions» post: for postconditions» loop invariant: for loop invariants» loop variant: for loop variants» invariant: for class invariants» using any parameter of the program Lecture 5: Specifying Java programs Slide Number 3 Specifying Java Methods (1) //pre: none // post: (result = x result = y) & (result<=x & result<=y) int IntMin(int x, int y) { int r; if(x<=y)r=x;elser=y; return r; Precondition Postcondition Preconditions are constraints only on the input variables of a method; Postconditions are constraints on the output of a method. They can also refer to the input variables, and to the class attributes. The variable result stands for the value returned by the method. Preconditions are checked on entry. Postconditions are checked on exit. Lecture 5: Specifying Java programs Slide Number 4 We will use the following convention to write our program specifications. The examples that we ll be using are simple enough to not require very elaborated logical notations. We might, sometime, complement the logical notation with some English, if necessary. The book Reasoned Programming gives examples of program specifications with respect to the functional programming language Miranda and the imperative programming language Modula2. In Miranda the comment line is defined by, whereas in Modula2 a comment line starts with a *. We will adopt instead the notation of Java: so our specifications, if limited to just one line will start with //, and if longer than a line will be delimited by the comment symbols /*..*/. The main constructs of program specifications that we are going to consider are precondition, postconditions, loop invariants, loop variants,andclass invariants. Each of these constructs are going to be identified in our annotated (i.e. specified) program with the key words pre:, post:, loop invariant:, loop variant:, and invariant, respectively. The key word modifies is instead used to define the attributes of an object that a given method is supposed to change. All but the loop invariant and loop variants are program specification s constructs that can be derived from a given ObjectZ specification. Parameters used in the program code can also be used in the program specifications Program specifications aim to check that a program fulfils its purposes. Using just testing, we can check that given specific values to the input variables of a method, the method behaves correctly. But we can never be sure that the method will work correctly on all possible input. Given a precondition and a postcondition to a method definition, we can instead check that for any possible value of the input variables that satisfies the precondition, the code of the method makes the postcondition true. This is what we mean by checking correctness of a (Java) method. Above is an example of pre and postconditions for a simple method, called IntMin, which returns the minimum of two integer numbers given as input variables. In general, preconditions are only conditions on the input variables of a method, which must be true before a method is executed. Postconditions are conditions on the output of the method and/or on the attributes values of the object, which must be true after the operation has been performed, and given that the preconditions are also true. Note that, postconditions can also refer to the input, but preconditions can refer to only the input. 3 4
3 Specifying Java Methods (2) public class TwoNumbers{ int u, v; // modifies u, v; //pre: none //post: u=v 0 v=u 0 ; void Swap( ) { int temp; temp=u;u=v;v=temp; Postconditions can also express constraints on the new values of the attributes of an object. The attribute_name (i.e. u) denotes the value of the attribute after the execution of the method, attribute_name 0 (i.e. u 0 ) denotes the value of the attribute at the start of the method execution. The modifies statement declares instead that the method is supposed to change the values of the attributes u and v. Lecture 5: Specifying Java programs Slide Number 5 Specifying Class Invariants public class TwoNumbers{ int u, v; //invariant: u 2 v 3; void incrementu(int incr) { u=u+incr; Class Invariant Invariants:» are declared immediately after the attributes declarations in a class;» express constraints on the values of the attributes of a class;» behave like postconditions of the constructor and of each methods in the class. e.g. public class TwoNumbers{ int u, v; What is wrong here? //post: u 2 v 3; void incrementu(int incr) { u=u+incr; Lecture 5: Specifying Java programs Slide Number 6 This is an example of postcondition of a method that expresses constraints on the values of the attributes of the class, after the method is executed. The notational convention that we adopt here is to use in the postcondition just the name of the attribute to refer to the new value of that attribute after the execution of the method, and the name of the attribute with the subscript 0 to refer to the value of the attribute at the start of the method execution. Whenever a method is supposed to change the value of a class attribute, we include before the preconditions the construct modifies and the list of the attributes that can be changed by the method. Program specifications aim to check that a program fulfils its purposes. Using just testing, we can check that given specific values to the input variables of a method, the method behaves correctly. But we can never be sure that the method will work correctly on all possible input. Given a precondition and a postcondition to a method definition, we can instead check that for any possible value of the input variables that satisfies the precondition, the code of the method makes the postcondition true. This is what we mean by checking correctness of a (Java) method. Above is an example of pre and postconditions for a simple method, called IntMin, which returns the minimum of two integer numbers given as input variables. In general, preconditions are only conditions on the input variables of a method. Postconditions are conditions on the output of the method, and/or on the attributes values of the object, after the operation has been performed. Note that, postconditions can also refer to the input, but preconditions can only refer to the input. 5 6
4 Mapping ObjectZ into Java Specifications General rules for the mapping: ObjectZ class schema ClassName Constants Attributes Axioms of the state schema Initial schema Operation schema» list;» preconditions;» axioms; Visibility List Java Specification public class ClassName final attributes of the class Attributes of the class Invariants Constructor of the class Method declaration with» modifies list;» preconditions;» postconditions; public / static prefixes. Lecture 5: Specifying Java programs Slide Number 7 Example: Mapping the CreditCard schema CreditCard " (Init, withdraw, deposit, withdrawavail) limit: N limit {1000, 2000, 5000 Init balance: Z balance = 0 balance + limit 0 withdraw (balance) amount?:n amount?<=balance + limit balance' = balance amount? withdrawavail (balance) amount!:n amount! = balance + limit balance = limit public class CreditCard{ private final init limit = 1000; private int balance; //invariant: limit 0; //invariant: balance + limit 0 public CreditCard( ) { balance = 0; //modifies: balance; //pre: amount balance 0 + limit; //post: balance = balance 0 amount; public void withdraw(int amount) { //modifies: balance; //pre: none; //post: balance = limit result = balance 0 + limit; public int withdrawavail( ) { Lecture 5: Specifying Java programs Slide Number 8 In this slide we give basic rules for mapping ObjectZ specifications into Java program and program specifications. Refinement of formal specifications into programs and program specifications can be done in various different ways, depending on the relation between the classes specified in ObjectZ and the Java classes declared in the program. The assumption that we are using here is that the ObjectZ specification provides already the architecture definition of our Java program. This means that each class schema defined in ObjectZ is expected to be implemented by a Java class in our Java program. This explain the first row of the mapping given in this table. Attributes defined in a class schema (constants and variables) are mapped into attributes of our Java class, preserving the same distinction of constants and variables. So all the constants of a class schema are Java class s attributes declared as final, and all the variables of a state schema are not final attributes of the Java class. Note that initialisation values given in the axiom part of a constant definition in ObjectZ can be used to initialise the final attributes. This explains the second and third rows of the mapping given in this table. The axioms of a state schema are mapped into invariants of our Java class. The Initial schema in ObjectZ corresponds to the Java constructor of the Java class. Operation schemas are mapped into Java method specifications, in the following way. The list declared in the operation schema is mapped into a modifies construct, the precondition axioms are mapped into preconditions, and the remaining axioms of an operation schema are mapped into postconditions of the method. For simplicity we assume that each operation schema in ObjectZ can have only one output variable. Finally, if the class schema includes a visibility list, then for each feature (attribute and operation) included in the visibility list, the corresponding Java feature will be declared to be public and the remaining features declared to be private. In this slide we give an example of how we could map part of the class schema CreditCard we saw in Lecture 3 into a Java program and its specification. Few things are interesting to notice. First of all, the constant limit is defined in ObjectZ to be a natural number. In Java we don t have natural numbers as basic types, so the declaration of the final attribute limit in Java is a refinement of that given in ObjectZ. It is defined as an integer with the addition of an extra invariant that has not been specified in the ObjectZ class schema. Second, the constant definition in ObjectZ declares limit to be of type enumeration by specifying the possible values that it could assume. In the actual implementation, the engineer will need to make a decision and define a value for the final attribute limit. Again, this is another example of simple refinement of the given formal specification. Third, the precondition of the method withdraw is necessary for the class invariant to be satisfied. In the ObjectZ class schema definition, such precondition would be redundant. In the actual implementation, if this method is not declared to throw exceptions, the precondition is essential. We ll see later how the choice of a defensive vs a nondefensive approach to the implementation leads to different codes and program specifications. NOTE: For simplicity we restrict ourselves to class schemas whose attributes are of basic types (natural; numbers, real numbers, seqchar). 7 8
5 Reasoning about Programs: notations Program code includes variable assignments, thus variables change in their values. When reasoning about correctness of method codes, we have to be able to refer to current, previous and intermediate values of variables. Convention:» At each point of a method code, variable_name denotes the value of the variable at that current point of execution of the code (i.e. now);» A variable_name 0 denotes the value of the variable at the start of a method to distinguish it from the current value;» A variable_name i ( i is a positive number) denotes an intermediate value of the variable assumed after the start of a method execution up to and excluded the current point. Example MethodA( ){ x=1; x=x+1; // x 0 = value of attribute x at the start // x = 1; x 0 = value of attribute x at the start // x 1 =1;x=x 1 +1=2;x 0 = value of x at the start Lecture 5: Specifying Java programs Slide Number 9 Midconditions Midconditions are specifications (or expressions) that can be included at any arbitrary point within a program code. They are supposed to hold whenever the program control passes throughout the point where they are stated. Example: // pre: none int z; // y=y 0 x=x 0 z=x; //y=y 0 z=x 0 x=y; //x=y 0 z=x 0 y=z; //y=x 0 x=y 0 // post: x = y 0 y=x 0 Preconditions = midconditions at the start Postconditions = midconditions just before exit Midconditions =usedtohelp justify code Lecture 5: Specifying Java programs Slide Number 10 An important feature of imperative or OO programming languages is the operation of assignment. Variables can change their values within the body of a method. To reason about the correctness of a method, namely to check whether a postcondition is satisfied at the end of a method, it s important to keep truck of the different values that a variable can assume during the execution of the method. To keep truck of these different values of each variable, we use the following conventions. Variables at the beginning of a method are denoted by their name with the subscript 0, variables at a currents point of execution of a method, are denoted with just their name. When we perform reasoning about a part of a code, each intermediate value assumed by the variable within this code is denoted with the variable name subscribed with an (incremental) indexing number. This convention relates to the convention for writing postconditions that we have defined in slide 5. If the current point of execution is at the end of the method code, the current value of a variable is the value at the exit of the method. Hence, the postcondition uses just the variable name to indicate the variable s value at the current point that is at the exit of the method. We have given here an example of the use of this notation, by commenting each line of the code of MethodA. These comments are called midcondition, and define the current value of variables at a certain point of execution, possibly referring to previous or initial values of the variables. We define in the next slide what a midcondition is and why it s useful. Midconditions can be used to reason about programs, for instance to show that the postconditions of a methods are met given the code and that the preconditions are true. We can reason with midconditions in two different ways: forward starting from the initial midcondition (i.e. the precondition) and following the statements to derive a new midcondition and so on, until we reach the end of the code. The last midcondition so generated is supposed to be equal to postcondition for the postcondition to be satisfied. Another way for generating midconditions is reasoning backwards from the lastmidcondition (i.e. postcondition). Starting from the end, we can look at the operation in the code and substitute in the last midcondition the variables accordingly to simulate backwards what the code is supposed to do. We discuss here how we can generate the midconditions given in the example here by reasoning forward and by reasoning backwards. Reasoning forward: At the start of this piece of code, the variables x and y are equal to some initial values x 0 and y 0 respectively. This is our first midcondition (or precondition of our piece of code). To second midcondition is generated looking at the code. At the point after the assignment z = x; the variable z includes the value of x just before the assignment. i.e. z = x 0. The variable y is instead left unchanged. This gives our second midcondition. We can used a similar reasoning to show how we get the third midcondition and then the four midcondition. Since there is no more code, we want this last midcondition to be equal to the postcondition. This is the case, so we can say that our piece of code satisfies the given postcondition. Backward reasoning: We start from the postcondition. This is also our last midcondition. We then look at the last operation and we generate the previous midcondition by substituting in the last midcondition the variable y with z. And so on, until we reach the first midcondition. This is what we initially had as precondition, so the piece of code satisfies the postcondition. The backward reasoning helps us identify those pieces of information about the initial conditions that are necessary for the code to establish the postcondition. Such (minimal) set of information about the initial conditions are called weakest preconditions. 9 10
6 Reasoning rules for assignments midcondbefore {x = expr midcondafter Meaning: If the midcondbefore holds and the assignment x=expr is executed then the midcondafter holds. program midcondition before // x > 10; x=x3; // x > 5; midcondition after Examples i. Substitute x3 for x in the midcondafter; ii. midcondbefore' = x3>5; or x > 8; so we have x>8{x=x3; x>5,whichistrue; iii.x > 10 implies x > 8? This is obviously true (The weakest precondition is x>8) To show it: i. Replace in midcondafter all occurrences of x with expr, ii. This gives a new midcondition, called midcondbefore', so that midcondbefore' {x = expr midcondafter is true. iii. Show that midcondbefore implies midcondbefore' program x=x1; midcondition before //0<x<N+1 // 0 x<n; midcondition after i. Substitute x1 for x in the midcondafter: ii. midcondbefore' = 0 x1 < N, which gives 1 x<n+1,whichistrue; iii.0 <x<n+1implies1 x<n+1. (The weakest precondition is 1 x<n+1) Lecture 5: Specifying Java programs Slide Number 11 Lecture 5: Specifying Java programs Slide Number 12 In this slide, we give the general rules for reasoning about assignments. The statement midcondbefore{x=exprmidcondafter is called a judgment. This reasoning can be used in two ways: if both midconditions are given, it just shows that assuming the midcondbefore to be correct, the assignment operation satisfies the midcondafter. If only the midcondafter is given together with the assignment, then it helps identify the minimal midcondbefore that is needed in order to verify the correctness of the operation. Note that it is easier in general to work from midcondafter to midcondbefore. Reasoning about sequences of statements is based on reasoning about the individual statements in the way illustrated above. For instance, suppose that we want to reason about the following judgement: midcondbefore{statement1; statement2midcondafter This can be split into the following two judgements: This slide shows two examples of reasoning with midcondition before and midcondition after in the case of just assignment operations. Both examples have the two midconditions specified. The reasoning on the righthandside show that given that the midcondition before is satisfied then the midcondition after is also satisfied after the operation of assignment is performed. In both cases, the backward reasoning generates a weakest precondition which may or may not be equal to the given first midcondition. To show that the code is correct, we need to show that the initial midcondition does entails the weakest precondition. midcondbefore{statement1midconbetween midcondbetween{statement2midcondafter Both the above judgements are satisfied if and only if the first judgement is satisfied. This is essentially the mechanism we are going to use to prove that the postcondition of a method is satisfied whenever the preconditions are satisfied. The body of the method is essentially a sequence of statements, the precondition is the first midcondition before and the postcondition is the last midcondition after with respect to the body of the method. The reasoning should then check the satisfiability of all the intermediate midconditions for all the statements included in the body of the method
7 Conditionals //pre: none; //post: (result = x 0 result = y 0 ) (result x 0 result y 0 ) int intmin(int x, int y) { // x = x 0 y=y 0 if (x <= y) // x 0 <= y 0 ; return x; // result = x 0 &result<=y 0 ; else // x 0 >y 0 ; return y; // result = y 0 &result<x 0 ; Reasoning rules for conditionals midcondbefore {IF test {s1else {s2 midcondafter Meaning: If the midcondbefore holds and the test is true and {s1 is executed then the midcondafter holds, and if midcondbefore holds and the test is false and {s2 is executed then the midcondafter also holds. There are two branches of execution, the THEN (when the condition is true) and the ELSE branch, when the condition is false. We need to show that the postcondition holds independently from the branch that is executed. To show it: i. Show midcondbefore & test {s1 midcondafter ii.and show midcondbefore & test {s2 midcondafter Lecture 5: Specifying Java programs Slide Number 13 Lecture 5: Specifying Java programs Slide Number 14 We want to show that after each return the postcondition is true. The ifelse statement always requires a case analysis. Take the first branch (or first case). To get on this branch the program must have passed the iftest. So assuming x 0 to be the initial value of x, and y 0 to be the initial value of y, we know that at this point of the execution, x 0 <= y 0. We can then annotate it as midcondition of the program at this particular point of the execution. The program then return x. Therefore result = x 0 is true and so it s the expression result = x 0 result = y 0.Sincex 0 <= y 0, we also know that result <= y 0 (this is the next midcondition). Moreover we also have result <= x 0, and thus the second part of the midcondition is true. So also the second part of the postcondition is true. The other branch (or second case) is similar. On entering it we know that x 0 >y 0. Since the method returns y, we have that result=y 0 is true and so it s the expression result = x 0 result = y 0. Moreover, we also have result < x 0 and thus the second part of the midcondition is true. This shows at each return point that the postcondition is true. A similar reasoning can be done backwards starting from the postcondition. We want to show (result=x 0 result=y 0 ) and (result <=x 0 result<=y 0 ). On the if branch, we have as last operation return x. So we can substitute result for x and get (x=x 0 x=y 0 )and(x x 0 x y 0 ). The first part (x=x 0 x=y 0 ) is true and the second part is true because the midcondition before the test would in this case be x=x 0 y=y 0,wehavethatx<=y 0 is true. Analogously for the other branch. NOTE: in the second type of reasoning the new midconditionsbefore' generated from the postcondition are equivalent to the midconditions given in the program. In the next slide we give the general rules for reasoning about ifelse statements. In this slide, we give the general rules for reasoning about ifelse statements, or conditionals. A conditional judgement is equivalent to two judgements of the form: midcondbefore & test {S1 midcondafter, midcondbefore & test {S2 midcondafter. Check that the conditional judgement is satisfied means therefore to check that both the above two judgements are satisfied. This means showing that whatever execution branch is taken by the program under the midcondbefore, it is always possible to establish the truth of the midcondafter. To verify each of the above two judgments independently, we make use of the same (backward) reasoning shown for the assignment statement. Starting from the midcondafter, making appropriate substitutions and getting a new midcondbefore', which should be implied by the given midcondbefore together with the truth or falsity of the ifcondition, according to which of the two judgments we are analysing
8 Example //pre: none; //post: (result = x 0 result = y 0 ) and (result x 0 result y 0 ) int intmin( ) { // x = x 0 y=y 0 ; IF (x y) // x 0 <= y 0 ; return x; // result = x 0 result y 0 ; ELSE // x 0 >y 0 ; return y; // result = y 0 result < x 0 ; Reasoning: i. Substituting result with x in the postcondition we get the midcondbefore': (x = x 0 x=y 0 ) (x x 0 x y 0 ), which is true, given the (test) and the initial midcondition x=x 0 and y = y 0. ii.substituting result with y in the postcondition we get the midcondbefore': (y = x 0 y=y 0 ) (y x 0 y y 0 ), whichisalsotrue,given( test) and the initial midcondition x=x 0 and y = y 0. Lecture 5: Specifying Java programs Slide Number 15 Nondefensive vs Defensive Approach to Programming Nondefensive approach: Preconditions are used to specify the good values for the input parameters of a method, for which the method should behave correctly. Defensive approach: The program does not have any precondition on the values of its input parameters, but its code has to define all the appropriate output for all possible input values. Lecture 5: Specifying Java programs Slide Number 16 The choice of a defensive or nondefensive approach to the design of a system affects its implementation. In the ObjectZ specifications we have introduced the concept of precondition, as an axiom to include in an operation schema in order to guarantee correct execution of the operation. This is what we call nondefensive approach. We haven t seen, on the other hand, the concept of defensive approach for the definition of operation schema in a given class schema. This is because in objectoriented specifications, when an error occurs, there is no sense to talk about the new state of a given object, since the error would make the operation inapplicable. From the point of view of the implementation, when we refine an ObjectZ operation schema included in a class schema into a method we could still take into consideration whether we are implementing that method using a defensive or a nondefensive approach. In the first case we would need to add to the method the necessary preconditions that make the operation work correctly. In the second case, we should declare that the method could throw some exceptions, and its code would have to check for these exceptions. This is another example of how the implementation of a given formal specification can be further refined at the implementation level. An example is given in the next slide
9 Nondefensive vs Defensive: example //pre: x 0; //post: result^2 = x; int sqrt(int x) { return sqroot(x); (suppose this is a mathematical function for calculating the square root of an integer). //pre: none //post: (x<0 throw exception) or (x 0 & result = sqrt(x)). int sqrt(int x) throw exception{ if (x<0) throw exception else return sqroot(x); (suppose this is a mathematical function for calculating the square root of an integer). Lecture 5: Specifying Java programs Slide Number 17 Summary ObjectZ specifications can be mapped (or refined) into Java programs and program specifications. In a postcondition, result means the value returned by the method. Variables change their values: so specification expressions carry always a notion of now. A undecorated variable always denotes its value now. For pre and postconditions, now is, respectively, entry to and return from a method; for a midcondition, now is just after the related statement has been executed. A subscript 0 on a variable denotes its value originally, i.e. on entry to the method it refers to. Other subscripts like 1 on variables indicate their values at some intermediate points. Variables not mentioned in the specifications are assumed not to change. In an IF statement, the test gives preconditions for the IF and the ELSE parts. Lecture 5: Specifying Java programs Slide Number
Lecture Notes on Linear Search
Lecture Notes on Linear Search 15122: Principles of Imperative Computation Frank Pfenning Lecture 5 January 29, 2013 1 Introduction One of the fundamental and recurring problems in computer science is
More informationFormal Languages and Automata Theory  Regular Expressions and Finite Automata 
Formal Languages and Automata Theory  Regular Expressions and Finite Automata  Samarjit Chakraborty Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zürich March
More informationRigorous Software Development CSCIGA 3033009
Rigorous Software Development CSCIGA 3033009 Instructor: Thomas Wies Spring 2013 Lecture 11 Semantics of Programming Languages Denotational Semantics Meaning of a program is defined as the mathematical
More informationMathematical Induction
Mathematical Induction In logic, we often want to prove that every member of an infinite set has some feature. E.g., we would like to show: N 1 : is a number 1 : has the feature Φ ( x)(n 1 x! 1 x) How
More informationDiscrete Mathematics and Probability Theory Fall 2009 Satish Rao, David Tse Note 2
CS 70 Discrete Mathematics and Probability Theory Fall 2009 Satish Rao, David Tse Note 2 Proofs Intuitively, the concept of proof should already be familiar We all like to assert things, and few of us
More informationSoftware Analysis (POPA Sec , )
Software Analysis (POPA Sec. 2.2.2, 2.52.5.2) Klaus Ostermann Based on slides by Jurriaan Hage Overview Correctness proof Live Variables Analysis The While language with procedures Live Variables Analysis
More informationCourse: Programming II  Abstract Data Types. The ADT Stack. A stack. The ADT Stack and Recursion Slide Number 1
Definition Course: Programming II  Abstract Data Types The ADT Stack The ADT Stack is a linear sequence of an arbitrary number of items, together with access procedures. The access procedures permit insertions
More informationTheory of Computation Prof. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras
Theory of Computation Prof. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras Lecture No. # 31 Recursive Sets, Recursively Innumerable Sets, Encoding
More informationLinear and quadratic Taylor polynomials for functions of several variables.
ams/econ 11b supplementary notes ucsc Linear quadratic Taylor polynomials for functions of several variables. c 010, Yonatan Katznelson Finding the extreme (minimum or maximum) values of a function, is
More information2. Methods of Proof Types of Proofs. Suppose we wish to prove an implication p q. Here are some strategies we have available to try.
2. METHODS OF PROOF 69 2. Methods of Proof 2.1. Types of Proofs. Suppose we wish to prove an implication p q. Here are some strategies we have available to try. Trivial Proof: If we know q is true then
More informationCase studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090  Object Oriented Software Design
I. Automated Banking System Case studies: Outline Requirements Engineering: OO and incremental software development 1. case study: withdraw money a. use cases b. identifying class/object (class diagram)
More information3. Mathematical Induction
3. MATHEMATICAL INDUCTION 83 3. Mathematical Induction 3.1. First Principle of Mathematical Induction. Let P (n) be a predicate with domain of discourse (over) the natural numbers N = {0, 1,,...}. If (1)
More informationProgramming by Contract. Programming by Contract: Motivation. Programming by Contract: Preconditions and Postconditions
COMP209 Object Oriented Programming Designing Classes 2 Mark Hall Programming by Contract (adapted from slides by Mark Utting) Preconditions Postconditions Class invariants Programming by Contract An agreement
More informationCHAPTER 3. Methods of Proofs. 1. Logical Arguments and Formal Proofs
CHAPTER 3 Methods of Proofs 1. Logical Arguments and Formal Proofs 1.1. Basic Terminology. An axiom is a statement that is given to be true. A rule of inference is a logical rule that is used to deduce
More informationdef: An axiom is a statement that is assumed to be true, or in the case of a mathematical system, is used to specify the system.
Section 1.5 Methods of Proof 1.5.1 1.5 METHODS OF PROOF Some forms of argument ( valid ) never lead from correct statements to an incorrect. Some other forms of argument ( fallacies ) can lead from true
More informationMoving from CS 61A Scheme to CS 61B Java
Moving from CS 61A Scheme to CS 61B Java Introduction Java is an objectoriented language. This document describes some of the differences between objectoriented programming in Scheme (which we hope you
More informationOutline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References
Outline Computer Science 331 Introduction to Testing of Programs Mike Jacobson Department of Computer Science University of Calgary Lecture #34 1 Denitions 2 3 4 Implementation and Evaluation 5 Debugging
More informationDebugging. Common Semantic Errors ESE112. Java Library. It is highly unlikely that you will write code that will work on the first go
Debugging ESE112 Java Programming: API, PsuedoCode, Scope It is highly unlikely that you will write code that will work on the first go Bugs or errors Syntax Fixable if you learn to read compiler error
More information[Refer Slide Time: 05:10]
Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture
More informationAn Interesting Way to Combine Numbers
An Interesting Way to Combine Numbers Joshua Zucker and Tom Davis November 28, 2007 Abstract This exercise can be used for middle school students and older. The original problem seems almost impossibly
More informationThe Foundations: Logic and Proofs. Chapter 1, Part III: Proofs
The Foundations: Logic and Proofs Chapter 1, Part III: Proofs Rules of Inference Section 1.6 Section Summary Valid Arguments Inference Rules for Propositional Logic Using Rules of Inference to Build Arguments
More informationSoftware Engineering Techniques
Software Engineering Techniques Low level design issues for programminginthelarge. Software Quality Design by contract Pre and post conditions Class invariants Ten do Ten do nots Another type of summary
More informationHandout #1: Mathematical Reasoning
Math 101 Rumbos Spring 2010 1 Handout #1: Mathematical Reasoning 1 Propositional Logic A proposition is a mathematical statement that it is either true or false; that is, a statement whose certainty or
More informationLikewise, we have contradictions: formulas that can only be false, e.g. (p p).
CHAPTER 4. STATEMENT LOGIC 59 The rightmost column of this truth table contains instances of T and instances of F. Notice that there are no degrees of contingency. If both values are possible, the formula
More information0.8 Rational Expressions and Equations
96 Prerequisites 0.8 Rational Expressions and Equations We now turn our attention to rational expressions  that is, algebraic fractions  and equations which contain them. The reader is encouraged to
More informationBoolean Algebra Part 1
Boolean Algebra Part 1 Page 1 Boolean Algebra Objectives Understand Basic Boolean Algebra Relate Boolean Algebra to Logic Networks Prove Laws using Truth Tables Understand and Use First Basic Theorems
More informationPart I. The Picture class
CS 161 LAB 5 This lab will have two parts. In the first part, we will create a class to automate the drawing of the robot from the second lab. For the second part, we will begin a ClunkyCalculator class
More information2. Compressing data to reduce the amount of transmitted data (e.g., to save money).
Presentation Layer The presentation layer is concerned with preserving the meaning of information sent across a network. The presentation layer may represent (encode) the data in various ways (e.g., data
More informationQuotes from ObjectOriented Software Construction
Quotes from ObjectOriented Software Construction Bertrand Meyer PrenticeHall, 1988 Preface, p. xiv We study the objectoriented approach as a set of principles, methods and tools which can be instrumental
More informationCHAPTER 2. Logic. 1. Logic Definitions. Notation: Variables are used to represent propositions. The most common variables used are p, q, and r.
CHAPTER 2 Logic 1. Logic Definitions 1.1. Propositions. Definition 1.1.1. A proposition is a declarative sentence that is either true (denoted either T or 1) or false (denoted either F or 0). Notation:
More information6.3 Conditional Probability and Independence
222 CHAPTER 6. PROBABILITY 6.3 Conditional Probability and Independence Conditional Probability Two cubical dice each have a triangle painted on one side, a circle painted on two sides and a square painted
More informationCHAPTER 7 GENERAL PROOF SYSTEMS
CHAPTER 7 GENERAL PROOF SYSTEMS 1 Introduction Proof systems are built to prove statements. They can be thought as an inference machine with special statements, called provable statements, or sometimes
More informationMAT71506 Program Verication: Exercises
MAT71506 Program Verication: Exercises Antero Kangas Tampere University of Technology Department of Mathematics September 11, 2014 Accomplishment Exercises are obligatory and probably the grades will
More informationChapter 3. Cartesian Products and Relations. 3.1 Cartesian Products
Chapter 3 Cartesian Products and Relations The material in this chapter is the first real encounter with abstraction. Relations are very general thing they are a special type of subset. After introducing
More informationAppendix... B. The Object Constraint
UML 2.0 in a Nutshell Appendix B. The Object Constraint Pub Date: June 2005 Language The Object Constraint Language 2.0 (OCL) is an addition to the UML 2.0 specification that provides you with a way to
More informationChapter II. Controlling Cars on a Bridge
Chapter II. Controlling Cars on a Bridge 1 Introduction The intent of this chapter is to introduce a complete example of a small system development. During this development, you will be made aware of the
More informationPROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE
International Journal of Computer ScienceandCommunication Vol. 2, No. 1, JanuaryJune2011, pp. 153157 PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE Neeraj Kumar Singhania University,
More informationApplications of Methods of Proof
CHAPTER 4 Applications of Methods of Proof 1. Set Operations 1.1. Set Operations. The settheoretic operations, intersection, union, and complementation, defined in Chapter 1.1 Introduction to Sets are
More informationYear 9 set 1 Mathematics notes, to accompany the 9H book.
Part 1: Year 9 set 1 Mathematics notes, to accompany the 9H book. equations 1. (p.1), 1.6 (p. 44), 4.6 (p.196) sequences 3. (p.115) Pupils use the Elmwood Press Essential Maths book by David Raymer (9H
More informationT79.232 Safety Critical Systems Case Study 2: B Method  Basic Concepts
T79.232 Safety Critical Systems Case Study 2: B Method  Basic Concepts February 21, 2008 T79.5303: Case Study 2: B Method  Basic Concepts 21 B method  what is it about? B method describes entities
More informationClasses and Objects in Java Constructors. In creating objects of the type Fraction, we have used statements similar to the following:
In creating objects of the type, we have used statements similar to the following: f = new (); The parentheses in the expression () makes it look like a method, yet we never created such a method in our
More informationInduction. Margaret M. Fleck. 10 October These notes cover mathematical induction and recursive definition
Induction Margaret M. Fleck 10 October 011 These notes cover mathematical induction and recursive definition 1 Introduction to induction At the start of the term, we saw the following formula for computing
More informationWhat's Wrong With Formal Programming Methods? Eric C.R. Hehner
What's Wrong With Formal Programming Methods? Eric C.R. Hehner Department of Computer Science, University of Toronto, Toronto M5S 1A4 Canada The January 1991 issue of Computing Research News includes the
More informationDesign by Contract beyond class modelling
Design by Contract beyond class modelling Introduction Design by Contract (DbC) or Programming by Contract is an approach to designing software. It says that designers should define precise and verifiable
More informationBinary Adders: Half Adders and Full Adders
Binary Adders: Half Adders and Full Adders In this set of slides, we present the two basic types of adders: 1. Half adders, and 2. Full adders. Each type of adder functions to add two binary bits. In order
More informationCalling the Function. Two Function Declarations Here is a function declared as pass by value. Why use Pass By Reference?
Functions in C++ Let s take a look at an example declaration: Lecture 2 long factorial(int n) Functions The declaration above has the following meaning: The return type is long That means the function
More informationSpecification and Analysis of Contracts Lecture 1 Introduction
Specification and Analysis of Contracts Lecture 1 Introduction Gerardo Schneider gerardo@ifi.uio.no http://folk.uio.no/gerardo/ Department of Informatics, University of Oslo SEFM School, Oct. 27  Nov.
More informationNIKLAUS WIRTH Algorithms + Data Structures = Programs
java04.frm Page 171 Saturday, August 26, 2000 6:03 PM 171 Linked Lists The simplest way to interrelate or link a set of elements is to line them up in a single list... For, in this case, only a single
More information2 SYSTEM DESCRIPTION TECHNIQUES
2 SYSTEM DESCRIPTION TECHNIQUES 2.1 INTRODUCTION Graphical representation of any process is always better and more meaningful than its representation in words. Moreover, it is very difficult to arrange
More informationChapter 1: Key Concepts of Programming and Software Engineering
Chapter 1: Key Concepts of Programming and Software Engineering Software Engineering Coding without a solution design increases debugging time  known fact! A team of programmers for a large software development
More informationPseudo code Tutorial and Exercises Teacher s Version
Pseudo code Tutorial and Exercises Teacher s Version Pseudocode is an informal way to express the design of a computer program or an algorithm in 1.45. The aim is to get the idea quickly and also easy
More informationPARTA Questions. 2. How does an enumerated statement differ from a typedef statement?
1. Distinguish & and && operators. PARTA Questions 2. How does an enumerated statement differ from a typedef statement? 3. What are the various members of a class? 4. Who can access the protected members
More information15150 Lecture 11: Tail Recursion; Continuations
15150 Lecture 11: Tail Recursion; Continuations Lecture by Dan Licata February 21, 2011 In this lecture we will discuss space usage: analyzing the memory it takes your program to run tail calls and tail
More informationRigorous Software Engineering Hoare Logic and Design by Contracts
Rigorous Software Engineering Hoare Logic and Design by Contracts Simão Melo de Sousa RELEASE (UBI), LIACC (Porto) Computer Science Department University of Beira Interior, Portugal 20102011 S. Melo de
More informationSolving Problems Recursively
Solving Problems Recursively Recursion is an indispensable tool in a programmer s toolkit Allows many complex problems to be solved simply Elegance and understanding in code often leads to better programs:
More informationConstructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers
Constructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers TIMOTHY S. GEGGHARRISON Winona State University Although computer scientists understand the importance of discrete
More informationAutomated Program Behavior Analysis
Automated Program Behavior Analysis Stacy Prowell sprowell@cs.utk.edu March 2005 SQRL / SEI Motivation: Semantics Development: Most engineering designs are subjected to extensive analysis; software is
More informationCOMP 250 Fall 2012 lecture 2 binary representations Sept. 11, 2012
Binary numbers The reason humans represent numbers using decimal (the ten digits from 0,1,... 9) is that we have ten fingers. There is no other reason than that. There is nothing special otherwise about
More informationLecture # 06 Introducing abstract Machines Saima Zareen
Lecture # 06 Introducing abstract Machines Saima Zareen Formal Specification of a System Formal Specification describes the System behavior Operations of system Problem with formal specification is large
More informationJava+ITP: A Verification Tool Based on Hoare Logic and Algebraic Semantics
: A Verification Tool Based on Hoare Logic and Algebraic Semantics Department of Computer Science University of Illinois at UrbanaChampaign 6th International Workshop on Rewriting Logic and its Applications,
More information(Refer Slide Time: 00:01:16 min)
Digital Computer Organization Prof. P. K. Biswas Department of Electronic & Electrical Communication Engineering Indian Institute of Technology, Kharagpur Lecture No. # 04 CPU Design: Tirning & Control
More information4. MATRICES Matrices
4. MATRICES 170 4. Matrices 4.1. Definitions. Definition 4.1.1. A matrix is a rectangular array of numbers. A matrix with m rows and n columns is said to have dimension m n and may be represented as follows:
More informationNotes on Complexity Theory Last updated: August, 2011. Lecture 1
Notes on Complexity Theory Last updated: August, 2011 Jonathan Katz Lecture 1 1 Turing Machines I assume that most students have encountered Turing machines before. (Students who have not may want to look
More information8 Divisibility and prime numbers
8 Divisibility and prime numbers 8.1 Divisibility In this short section we extend the concept of a multiple from the natural numbers to the integers. We also summarize several other terms that express
More informationC H A P T E R Regular Expressions regular expression
7 CHAPTER Regular Expressions Most programmers and other powerusers of computer systems have used tools that match text patterns. You may have used a Web search engine with a pattern like travel cancun
More informationLecture 3: Finding integer solutions to systems of linear equations
Lecture 3: Finding integer solutions to systems of linear equations Algorithmic Number Theory (Fall 2014) Rutgers University Swastik Kopparty Scribe: Abhishek Bhrushundi 1 Overview The goal of this lecture
More informationMath 4310 Handout  Quotient Vector Spaces
Math 4310 Handout  Quotient Vector Spaces Dan Collins The textbook defines a subspace of a vector space in Chapter 4, but it avoids ever discussing the notion of a quotient space. This is understandable
More information9.4. The Scalar Product. Introduction. Prerequisites. Learning Style. Learning Outcomes
The Scalar Product 9.4 Introduction There are two kinds of multiplication involving vectors. The first is known as the scalar product or dot product. This is socalled because when the scalar product of
More informationCONTENTS 1. Peter Kahn. Spring 2007
CONTENTS 1 MATH 304: CONSTRUCTING THE REAL NUMBERS Peter Kahn Spring 2007 Contents 2 The Integers 1 2.1 The basic construction.......................... 1 2.2 Adding integers..............................
More informationFactoring  Trinomials where a = 1
6.3 Factoring  Trinomials where a = 1 Objective: Factor trinomials where the coefficient of x 2 is one. Factoring with three terms, or trinomials, is the most important type of factoring to be able to
More informationUnified Static and Runtime Verification of ObjectOriented Software
Unified Static and Runtime Verification of ObjectOriented Software Wolfgang Ahrendt 1, Mauricio Chimento 1, Gerardo Schneider 2, Gordon J. Pace 3 1 Chalmers University of Technology, Gothenburg, Sweden
More informationVDM vs. Programming Language Extensions or their Integration
VDM vs. Programming Language Extensions or their Integration Alexander A. Koptelov and Alexander K. Petrenko Institute for System Programming of Russian Academy of Sciences (ISPRAS), B. Communisticheskaya,
More informationNotes on Determinant
ENGG2012B Advanced Engineering Mathematics Notes on Determinant Lecturer: Kenneth Shum Lecture 918/02/2013 The determinant of a system of linear equations determines whether the solution is unique, without
More informationOverview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification
Introduction Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Advanced Topics in Software Engineering 1 Concurrent Programs Characterized by
More information(Refer Slide Time: 01:52)
Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture  2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This
More informationRegular Expressions and Automata using Haskell
Regular Expressions and Automata using Haskell Simon Thompson Computing Laboratory University of Kent at Canterbury January 2000 Contents 1 Introduction 2 2 Regular Expressions 2 3 Matching regular expressions
More informationc 2008 Je rey A. Miron We have described the constraints that a consumer faces, i.e., discussed the budget constraint.
Lecture 2b: Utility c 2008 Je rey A. Miron Outline: 1. Introduction 2. Utility: A De nition 3. Monotonic Transformations 4. Cardinal Utility 5. Constructing a Utility Function 6. Examples of Utility Functions
More informationMATH 10034 Fundamental Mathematics IV
MATH 0034 Fundamental Mathematics IV http://www.math.kent.edu/ebooks/0034/funmath4.pdf Department of Mathematical Sciences Kent State University January 2, 2009 ii Contents To the Instructor v Polynomials.
More informationSoftware Engineering
Software Engineering Lecture 04: The B Specification Method Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 50 The B specification method
More informationLEARNING OBJECTIVES FOR THIS CHAPTER
CHAPTER 2 American mathematician Paul Halmos (1916 2006), who in 1942 published the first modern linear algebra book. The title of Halmos s book was the same as the title of this chapter. FiniteDimensional
More informationIntroduction to Computers and Programming. Testing
Introduction to Computers and Programming Prof. I. K. Lundqvist Lecture 13 April 16 2004 Testing Goals of Testing Classification Test Coverage Test Technique Blackbox vs Whitebox Real bugs and software
More informationLogic in Computer Science: Logic Gates
Logic in Computer Science: Logic Gates Lila Kari The University of Western Ontario Logic in Computer Science: Logic Gates CS2209, Applied Logic for Computer Science 1 / 49 Logic and bit operations Computers
More informationUses of Empirical Modelling in a frisbee simulation
Uses of Empirical Modelling in a frisbee simulation Abstract This paper shall describe how Empirical Modelling was used in constructing a small simulation of a frisbee game. The purpose of the paper is
More informationExtended Static Checking for Java
Lukas TU München  Seminar Verification 14. Juli 2011 Outline 1 Motivation 2 ESC/Java example 3 ESC/JAVA architecture VC generator Simplify 4 JML + ESC/Java annotation language JML What ESC/Java checks
More informationCOMP1008 Developing Classes
COMP1008 Developing Classes Agenda For the next block of lectures we will be looking at designing and writing an OO program requiring a small number of classes. Along the way we will: Get an overview of
More informationChapter 4 Software Lifecycle and Performance Analysis
Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and
More informationStyle Guide For Writing Mathematical Proofs
Style Guide For Writing Mathematical Proofs Adapted by Lindsey Shorser from materials by Adrian Butscher and Charles Shepherd A solution to a math problem is an argument. Therefore, it should be phrased
More information2) Write in detail the issues in the design of code generator.
COMPUTER SCIENCE AND ENGINEERING VI SEM CSE Principles of Compiler Design UnitIV Question and answers UNIT IV CODE GENERATION 9 Issues in the design of code generator The target machine Runtime Storage
More informationElementary Number Theory We begin with a bit of elementary number theory, which is concerned
CONSTRUCTION OF THE FINITE FIELDS Z p S. R. DOTY Elementary Number Theory We begin with a bit of elementary number theory, which is concerned solely with questions about the set of integers Z = {0, ±1,
More informationMath 55: Discrete Mathematics
Math 55: Discrete Mathematics UC Berkeley, Fall 2011 Homework # 5, due Wednesday, February 22 5.1.4 Let P (n) be the statement that 1 3 + 2 3 + + n 3 = (n(n + 1)/2) 2 for the positive integer n. a) What
More informationSo let us begin our quest to find the holy grail of real analysis.
1 Section 5.2 The Complete Ordered Field: Purpose of Section We present an axiomatic description of the real numbers as a complete ordered field. The axioms which describe the arithmetic of the real numbers
More informationModule 10. Coding and Testing. Version 2 CSE IIT, Kharagpur
Module 10 Coding and Testing Lesson 23 Code Review Specific Instructional Objectives At the end of this lesson the student would be able to: Identify the necessity of coding standards. Differentiate between
More informationMathematics for Computer Science/Software Engineering. Notes for the course MSM1F3 Dr. R. A. Wilson
Mathematics for Computer Science/Software Engineering Notes for the course MSM1F3 Dr. R. A. Wilson October 1996 Chapter 1 Logic Lecture no. 1. We introduce the concept of a proposition, which is a statement
More informationThe Little Man Computer
The Little Man Computer The Little Man Computer  an instructional model of von Neuman computer architecture John von Neuman (19031957) and Alan Turing (19121954) each independently laid foundation for
More informationRegression Verification: Status Report
Regression Verification: Status Report Presentation by Dennis Felsing within the Projektgruppe Formale Methoden der Softwareentwicklung 20131211 1/22 Introduction How to prevent regressions in software
More information1 Lecture 19: Implicit differentiation
Lecture 9: Implicit differentiation. Outline The technique of implicit differentiation Tangent lines to a circle Examples.2 Implicit differentiation Suppose we have two quantities or variables x and y
More informationPART I. THE REAL NUMBERS
PART I. THE REAL NUMBERS This material assumes that you are already familiar with the real number system and the representation of the real numbers as points on the real line. I.1. THE NATURAL NUMBERS
More informationSensitivity Analysis 3.1 AN EXAMPLE FOR ANALYSIS
Sensitivity Analysis 3 We have already been introduced to sensitivity analysis in Chapter via the geometry of a simple example. We saw that the values of the decision variables and those of the slack and
More informationChapter 5 Programming Statements. Chapter Table of Contents
Chapter 5 Programming Statements Chapter Table of Contents OVERVIEW... 57 IFTHEN/ELSE STATEMENTS... 57 DO GROUPS... 58 IterativeExecution... 59 JUMPING... 61 MODULES... 62 Defining and Executing a Module....
More informationLecture 2 Mathcad Basics
Operators Lecture 2 Mathcad Basics + Addition,  Subtraction, * Multiplication, / Division, ^ Power ( ) Specify evaluation order Order of Operations ( ) ^ highest level, first priority * / next priority
More information