Lecture 5: Specifying Java Programs

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Lecture 5: Specifying Java Programs"

Transcription

1 Lecture 5: Specifying Java Programs This lecture aims to:! Introduce the basic ingredients of a program specification.! Show how to map Object-Z specifications into program specifications! Define reasoning rules for» assignment» if-else statements, Aims and Objectives! Illustrate the use of a defensive and a non-defensive 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 Pre-conditions Program Post-conditions 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 object-oriented 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 (object-oriented) program specification, and learn simple reasoning rules for checking the correctness of basic program statements such as assignment, if-then-else, while loop statements, as well as reasoning about the correctness of method calls. We will also see how, and to which extend, an Object-Z 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 non-defensive 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 pre-conditions, and they are mainly constraints on the input parameters that (components of ) a software system is supposed to receive. The requirements are instead post-condition, 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 Object-Z 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 pre-conditions» post: for post-conditions» 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; Pre-condition Post-condition Pre-conditions are constraints only on the input variables of a method; Post-conditions 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. Pre-conditions are checked on entry. Post-conditions 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 Modula-2. In Miranda the comment line is defined by, whereas in Modula-2 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 pre-condition, 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 Object-Z 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 pre-condition and a post-condition to a method definition, we can instead check that for any possible value of the input variables that satisfies the pre-condition, the code of the method makes the post-condition true. This is what we mean by checking correctness of a (Java) method. Above is an example of pre- and post-conditions for a simple method, called IntMin, which returns the minimum of two integer numbers given as input variables. In general, pre-conditions are only conditions on the input variables of a method, which must be true before a method is executed. Post-conditions 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 pre-conditions are also true. Note that, post-conditions can also refer to the input, but pre-conditions 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; Post-conditions 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 post-conditions 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 post-condition 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 post-condition 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 pre-condition and a post-condition to a method definition, we can instead check that for any possible value of the input variables that satisfies the pre-condition, the code of the method makes the post-condition true. This is what we mean by checking correctness of a (Java) method. Above is an example of pre- and post-conditions for a simple method, called IntMin, which returns the minimum of two integer numbers given as input variables. In general, pre-conditions are only conditions on the input variables of a method. Post-conditions 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, post-conditions can also refer to the input, but preconditions can only refer to the input. 5 6

4 Mapping Object-Z into Java Specifications General rules for the mapping: Object-Z class schema ClassName Constants Attributes Axioms of the state schema Initial schema Operation schema» -list;» pre-conditions;» 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;» pre-conditions;» post-conditions; 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 Object-Z 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 Object-Z and the Java classes declared in the program. The assumption that we are using here is that the Object-Z specification provides already the architecture definition of our Java program. This means that each class schema defined in Object-Z 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 Object-Z 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 Object-Z 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 pre-condition axioms are mapped into pre-conditions, and the remaining axioms of an operation schema are mapped into postconditions of the method. For simplicity we assume that each operation schema in Object-Z 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 Object-Z 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 Object-Z. It is defined as an integer with the addition of an extra invariant that has not been specified in the Object-Z class schema. Second, the constant definition in Object-Z 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 pre-condition of the method withdraw is necessary for the class invariant to be satisfied. In the Object-Z class schema definition, such pre-condition would be redundant. In the actual implementation, if this method is not declared to throw exceptions, the pre-condition is essential. We ll see later how the choice of a defensive vs a non-defensive 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 Mid-conditions Mid-conditions 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 Pre-conditions = mid-conditions at the start Post-conditions = mid-conditions just before exit Mid-conditions =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 post-condition 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 post-conditions 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 post-condition 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 mid-condition, 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 mid-condition is and why it s useful. Mid-conditions can be used to reason about programs, for instance to show that the post-conditions of a methods are met given the code and that the pre-conditions are true. We can reason with mid-conditions in two different ways: forward starting from the initial mid-condition (i.e. the pre-condition) and following the statements to derive a new mid-condition and so on, until we reach the end of the code. The last mid-condition so generated is supposed to be equal to post-condition for the post-condition to be satisfied. Another way for generating mid-conditions is reasoning backwards from the last-midcondition (i.e. post-condition). Starting from the end, we can look at the operation in the code and substitute in the last mid-condition the variables accordingly to simulate backwards what the code is supposed to do. We discuss here how we can generate the mid-conditions 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 mid-condition (or pre-condition of our piece of code). To second mid-condition 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 mid-condition. We can used a similar reasoning to show how we get the third mid-condition and then the four mid-condition. Since there is no more code, we want this last mid-condition to be equal to the post-condition. This is the case, so we can say that our piece of code satisfies the given post-condition. Backward reasoning: We start from the post-condition. This is also our last mid-condition. We then look at the last operation and we generate the previous mid-condition by substituting in the last midcondition the variable y with z. And so on, until we reach the first mid-condition. This is what we initially had as pre-condition, so the piece of code satisfies the post-condition. The backward reasoning helps us identify those pieces of information about the initial conditions that are necessary for the code to establish the post-condition. Such (minimal) set of information about the initial conditions are called weakest pre-conditions. 9 10

6 Reasoning rules for assignments mid-cond-before {x = expr mid-cond-after Meaning: If the mid-cond-before holds and the assignment x=expr is executed then the mid-cond-after holds. program mid-condition before // x > 10; x=x-3; // x > 5; mid-condition after Examples i. Substitute x-3 for x in the mid-cond-after; ii. mid-cond-before' = x-3>5; or x > 8; so we have x>8{x=x-3; x>5,whichistrue; iii.x > 10 implies x > 8? This is obviously true (The weakest pre-condition is x>8) To show it: i. Replace in mid-cond-after all occurrences of x with expr, ii. This gives a new mid-condition, called mid-cond-before', so that mid-cond-before' {x = expr mid-cond-after is true. iii. Show that mid-cond-before implies mid-cond-before' program x=x-1; mid-condition before //0<x<N+1 // 0 x<n; mid-condition after i. Substitute x-1 for x in the mid-cond-after: ii. mid-cond-before' = 0 x-1 < N, which gives 1 x<n+1,whichistrue; iii.0 <x<n+1implies1 x<n+1. (The weakest pre-condition 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 mid-condbefore{x=exprmid-cond-after is called a judgment. This reasoning can be used in two ways: if both mid-conditions are given, it just shows that assuming the mid-cond-before to be correct, the assignment operation satisfies the mid-cond-after. If only the mid-cond-after is given together with the assignment, then it helps identify the minimal mid-cond-before that is needed in order to verify the correctness of the operation. Note that it is easier in general to work from mid-cond-after to mid-condbefore. 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: mid-cond-before{statement1; statement2mid-cond-after This can be split into the following two judgements: This slide shows two examples of reasoning with mid-condition before and mid-condition after in the case of just assignment operations. Both examples have the two mid-conditions specified. The reasoning on the right-hand-side show that given that the mid-condition before is satisfied then the mid-condition after is also satisfied after the operation of assignment is performed. In both cases, the backward reasoning generates a weakest pre-condition which may or may not be equal to the given first mid-condition. To show that the code is correct, we need to show that the initial mid-condition does entails the weakest pre-condition. mid-cond-before{statement1mid-con-between mid-cond-between{statement2mid-cond-after 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 post-condition of a method is satisfied whenever the pre-conditions are satisfied. The body of the method is essentially a sequence of statements, the pre-condition is the first mid-condition before and the post-condition is the last midcondition after with respect to the body of the method. The reasoning should then check the satisfiability of all the intermediate mid-conditions 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 mid-cond-before {IF test {s1else {s2 mid-cond-after Meaning: If the mid-cond-before holds and the test is true and {s1 is executed then the mid-cond-after holds, and if mid-cond-before holds and the test is false and {s2 is executed then the mid-cond-after 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 post-condition holds independently from the branch that is executed. To show it: i. Show mid-cond-before & test {s1 mid-cond-after ii.and show mid-cond-before & test {s2 mid-cond-after 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 post-condition is true. The if-else statement always requires a case analysis. Take the first branch (or first case). To get on this branch the program must have passed the if-test. 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 mid-condition 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 mid-condition). Moreover we also have result <= x 0, and thus the second part of the mid-condition is true. So also the second part of the post-condition 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 mid-condition is true. This shows at each return point that the postcondition is true. A similar reasoning can be done backwards starting from the post-condition. 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 mid-condition 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 mid-conditions-before' generated from the postcondition are equivalent to the mid-conditions given in the program. In the next slide we give the general rules for reasoning about if-else statements. In this slide, we give the general rules for reasoning about if-else statements, or conditionals. A conditional judgement is equivalent to two judgements of the form: mid-cond-before & test {S1 mid-cond-after, mid-cond-before & test {S2 mid-cond-after. 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 mid-cond-before, it is always possible to establish the truth of the mid-condafter. 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 mid-cond-after, making appropriate substitutions and getting a new mid-cond-before', which should be implied by the given mid-cond-before together with the truth or falsity of the if-condition, 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 post-condition we get the mid-cond-before': (x = x 0 x=y 0 ) (x x 0 x y 0 ), which is true, given the (test) and the initial mid-condition x=x 0 and y = y 0. ii.substituting result with y in the post-condition we get the mid-condbefore': (y = x 0 y=y 0 ) (y x 0 y y 0 ), whichisalsotrue,given( test) and the initial mid-condition x=x 0 and y = y 0. Lecture 5: Specifying Java programs Slide Number 15 Non-defensive vs Defensive Approach to Programming Non-defensive approach: Pre-conditions 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 pre-condition 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 non-defensive approach to the design of a system affects its implementation. In the Object-Z specifications we have introduced the concept of pre-condition, as an axiom to include in an operation schema in order to guarantee correct execution of the operation. This is what we call non-defensive 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 Object-Z 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 non-defensive approach. In the first case we would need to add to the method the necessary pre-conditions 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 Non-defensive 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 Object-Z specifications can be mapped (or refined) into Java programs and program specifications. In a post-condition, 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 post-conditions, now is, respectively, entry to and return from a method; for a mid-condition, 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 pre-conditions for the IF and the ELSE parts. Lecture 5: Specifying Java programs Slide Number

Lecture Notes on Linear Search

Lecture Notes on Linear Search Lecture Notes on Linear Search 15-122: 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 information

Formal Languages and Automata Theory - Regular Expressions and Finite Automata -

Formal 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 information

Rigorous Software Development CSCI-GA 3033-009

Rigorous Software Development CSCI-GA 3033-009 Rigorous Software Development CSCI-GA 3033-009 Instructor: Thomas Wies Spring 2013 Lecture 11 Semantics of Programming Languages Denotational Semantics Meaning of a program is defined as the mathematical

More information

Mathematical Induction

Mathematical 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 information

Discrete Mathematics and Probability Theory Fall 2009 Satish Rao, David Tse Note 2

Discrete 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 information

Software Analysis (POPA Sec , )

Software Analysis (POPA Sec , ) Software Analysis (POPA Sec. 2.2.2, 2.5-2.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 information

Course: Programming II - Abstract Data Types. The ADT Stack. A stack. The ADT Stack and Recursion Slide Number 1

Course: 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 information

Theory 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 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 information

Linear and quadratic Taylor polynomials for functions of several variables.

Linear 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 information

2. 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 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 information

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design

Case 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 information

3. Mathematical Induction

3. 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 information

Programming by Contract. Programming by Contract: Motivation. Programming by Contract: Preconditions and Postconditions

Programming 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 information

CHAPTER 3. Methods of Proofs. 1. Logical Arguments and Formal Proofs

CHAPTER 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 information

def: 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.

def: 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 information

Moving from CS 61A Scheme to CS 61B Java

Moving from CS 61A Scheme to CS 61B Java Moving from CS 61A Scheme to CS 61B Java Introduction Java is an object-oriented language. This document describes some of the differences between object-oriented programming in Scheme (which we hope you

More information

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References

Outline. 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 #3-4 1 Denitions 2 3 4 Implementation and Evaluation 5 Debugging

More information

Debugging. Common Semantic Errors ESE112. Java Library. It is highly unlikely that you will write code that will work on the first go

Debugging. 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, Psuedo-Code, 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]

[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 information

An Interesting Way to Combine Numbers

An 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 information

The Foundations: Logic and Proofs. Chapter 1, Part III: Proofs

The 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 information

Software Engineering Techniques

Software Engineering Techniques Software Engineering Techniques Low level design issues for programming-in-the-large. Software Quality Design by contract Pre- and post conditions Class invariants Ten do Ten do nots Another type of summary

More information

Handout #1: Mathematical Reasoning

Handout #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 information

Likewise, we have contradictions: formulas that can only be false, e.g. (p p).

Likewise, 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 information

0.8 Rational Expressions and Equations

0.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 information

Boolean Algebra Part 1

Boolean 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 information

Part I. The Picture class

Part 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 information

2. Compressing data to reduce the amount of transmitted data (e.g., to save money).

2. 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 information

Quotes from Object-Oriented Software Construction

Quotes from Object-Oriented Software Construction Quotes from Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental

More information

CHAPTER 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. 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 information

6.3 Conditional Probability and Independence

6.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 information

CHAPTER 7 GENERAL PROOF SYSTEMS

CHAPTER 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 information

MAT-71506 Program Verication: Exercises

MAT-71506 Program Verication: Exercises MAT-71506 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 information

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products

Chapter 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 information

Appendix... B. The Object Constraint

Appendix... 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 information

Chapter II. Controlling Cars on a Bridge

Chapter 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 information

PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE

PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE International Journal of Computer ScienceandCommunication Vol. 2, No. 1, January-June2011, pp. 153-157 PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE Neeraj Kumar Singhania University,

More information

Applications of Methods of Proof

Applications of Methods of Proof CHAPTER 4 Applications of Methods of Proof 1. Set Operations 1.1. Set Operations. The set-theoretic operations, intersection, union, and complementation, defined in Chapter 1.1 Introduction to Sets are

More information

Year 9 set 1 Mathematics notes, to accompany the 9H book.

Year 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 information

T-79.232 Safety Critical Systems Case Study 2: B Method - Basic Concepts

T-79.232 Safety Critical Systems Case Study 2: B Method - Basic Concepts T-79.232 Safety Critical Systems Case Study 2: B Method - Basic Concepts February 21, 2008 T-79.5303: Case Study 2: B Method - Basic Concepts 2-1 B method - what is it about? B method describes entities

More information

Classes and Objects in Java Constructors. In creating objects of the type Fraction, we have used statements similar to the following:

Classes 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 information

Induction. Margaret M. Fleck. 10 October These notes cover mathematical induction and recursive definition

Induction. 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 information

What's Wrong With Formal Programming Methods? Eric C.R. Hehner

What'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 information

Design by Contract beyond class modelling

Design 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 information

Binary Adders: Half Adders and Full Adders

Binary 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 information

Calling the Function. Two Function Declarations Here is a function declared as pass by value. Why use Pass By Reference?

Calling 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 information

Specification and Analysis of Contracts Lecture 1 Introduction

Specification 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 information

NIKLAUS WIRTH Algorithms + Data Structures = Programs

NIKLAUS 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 information

2 SYSTEM DESCRIPTION TECHNIQUES

2 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 information

Chapter 1: Key Concepts of Programming and Software Engineering

Chapter 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 information

Pseudo code Tutorial and Exercises Teacher s Version

Pseudo code Tutorial and Exercises Teacher s Version Pseudo code Tutorial and Exercises Teacher s Version Pseudo-code 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 information

PART-A Questions. 2. How does an enumerated statement differ from a typedef statement?

PART-A Questions. 2. How does an enumerated statement differ from a typedef statement? 1. Distinguish & and && operators. PART-A 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 information

15-150 Lecture 11: Tail Recursion; Continuations

15-150 Lecture 11: Tail Recursion; Continuations 15-150 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 information

Rigorous Software Engineering Hoare Logic and Design by Contracts

Rigorous 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 2010-2011 S. Melo de

More information

Solving Problems Recursively

Solving 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 information

Constructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers

Constructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers Constructing Contracts: Making Discrete Mathematics Relevant to Beginning Programmers TIMOTHY S. GEGG-HARRISON Winona State University Although computer scientists understand the importance of discrete

More information

Automated Program Behavior Analysis

Automated 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 information

COMP 250 Fall 2012 lecture 2 binary representations Sept. 11, 2012

COMP 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 information

Lecture # 06 Introducing abstract Machines Saima Zareen

Lecture # 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 information

Java+ITP: A Verification Tool Based on Hoare Logic and Algebraic Semantics

Java+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 Urbana-Champaign 6th International Workshop on Rewriting Logic and its Applications,

More information

(Refer Slide Time: 00:01:16 min)

(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 information

4. MATRICES Matrices

4. 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 information

Notes on Complexity Theory Last updated: August, 2011. Lecture 1

Notes 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 information

8 Divisibility and prime numbers

8 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 information

C H A P T E R Regular Expressions regular expression

C H A P T E R Regular Expressions regular expression 7 CHAPTER Regular Expressions Most programmers and other power-users 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 information

Lecture 3: Finding integer solutions to systems of linear equations

Lecture 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 information

Math 4310 Handout - Quotient Vector Spaces

Math 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 information

9.4. The Scalar Product. Introduction. Prerequisites. Learning Style. Learning Outcomes

9.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 so-called because when the scalar product of

More information

CONTENTS 1. Peter Kahn. Spring 2007

CONTENTS 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 information

Factoring - Trinomials where a = 1

Factoring - 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 information

Unified Static and Runtime Verification of Object-Oriented Software

Unified Static and Runtime Verification of Object-Oriented Software Unified Static and Runtime Verification of Object-Oriented Software Wolfgang Ahrendt 1, Mauricio Chimento 1, Gerardo Schneider 2, Gordon J. Pace 3 1 Chalmers University of Technology, Gothenburg, Sweden

More information

VDM vs. Programming Language Extensions or their Integration

VDM 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 information

Notes on Determinant

Notes on Determinant ENGG2012B Advanced Engineering Mathematics Notes on Determinant Lecturer: Kenneth Shum Lecture 9-18/02/2013 The determinant of a system of linear equations determines whether the solution is unique, without

More information

Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification

Overview 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)

(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 information

Regular Expressions and Automata using Haskell

Regular 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 information

c 2008 Je rey A. Miron We have described the constraints that a consumer faces, i.e., discussed the budget constraint.

c 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 information

MATH 10034 Fundamental Mathematics IV

MATH 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 information

Software Engineering

Software 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 information

LEARNING OBJECTIVES FOR THIS CHAPTER

LEARNING 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. Finite-Dimensional

More information

Introduction to Computers and Programming. Testing

Introduction 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 information

Logic in Computer Science: Logic Gates

Logic 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 information

Uses of Empirical Modelling in a frisbee simulation

Uses 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 information

Extended Static Checking for Java

Extended 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 information

COMP1008 Developing Classes

COMP1008 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 information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 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 information

Style Guide For Writing Mathematical Proofs

Style 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 information

2) Write in detail the issues in the design of code generator.

2) Write in detail the issues in the design of code generator. COMPUTER SCIENCE AND ENGINEERING VI SEM CSE Principles of Compiler Design Unit-IV Question and answers UNIT IV CODE GENERATION 9 Issues in the design of code generator The target machine Runtime Storage

More information

Elementary Number Theory We begin with a bit of elementary number theory, which is concerned

Elementary 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 information

Math 55: Discrete Mathematics

Math 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 information

So let us begin our quest to find the holy grail of real analysis.

So 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 information

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur

Module 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 information

Mathematics 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 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 information

The Little Man Computer

The Little Man Computer The Little Man Computer The Little Man Computer - an instructional model of von Neuman computer architecture John von Neuman (1903-1957) and Alan Turing (1912-1954) each independently laid foundation for

More information

Regression Verification: Status Report

Regression Verification: Status Report Regression Verification: Status Report Presentation by Dennis Felsing within the Projektgruppe Formale Methoden der Softwareentwicklung 2013-12-11 1/22 Introduction How to prevent regressions in software

More information

1 Lecture 19: Implicit differentiation

1 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 information

PART I. THE REAL NUMBERS

PART 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 information

Sensitivity Analysis 3.1 AN EXAMPLE FOR ANALYSIS

Sensitivity 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 information

Chapter 5 Programming Statements. Chapter Table of Contents

Chapter 5 Programming Statements. Chapter Table of Contents Chapter 5 Programming Statements Chapter Table of Contents OVERVIEW... 57 IF-THEN/ELSE STATEMENTS... 57 DO GROUPS... 58 IterativeExecution... 59 JUMPING... 61 MODULES... 62 Defining and Executing a Module....

More information

Lecture 2 Mathcad Basics

Lecture 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