# Specification and Analysis of Contracts Lecture 1 Introduction

Save this PDF as:

Size: px
Start display at page:

## Transcription

1 Specification and Analysis of Contracts Lecture 1 Introduction Gerardo Schneider Department of Informatics, University of Oslo SEFM School, Oct Nov. 7, 2008 Cape Town, South Africa Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

2 Plan 1 Formal Methods 2 Contracts and Informatics Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

3 Plan 1 Formal Methods 2 Contracts and Informatics Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

4 How to Guarantee Correctness? Is it possible at all? How to show a system is correct? It is not enough to show that it can meet its requirement We should show that a system cannot fail to meet its requirement By testing? Dijkstra wrote (1972): Program testing can be used to show the presence of bugs, but never to show their absence By other kind of proof? Dijkstra again (1965): One can never guarantee that a proof is correct, the best one can say is: I have not discovered any mistakes What about automatic proof? It is impossible to construct a general proof procedure for arbitrary programs 1 Any hope? 1 Undecidability of the halting problem, by Turing. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

5 How to Guarantee Correctness? Is it possible at all? How to show a system is correct? It is not enough to show that it can meet its requirement We should show that a system cannot fail to meet its requirement By testing? Dijkstra wrote (1972): Program testing can be used to show the presence of bugs, but never to show their absence By other kind of proof? Dijkstra again (1965): One can never guarantee that a proof is correct, the best one can say is: I have not discovered any mistakes What about automatic proof? It is impossible to construct a general proof procedure for arbitrary programs 1 Any hope? 1 Undecidability of the halting problem, by Turing. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

6 How to Guarantee Correctness? Is it possible at all? How to show a system is correct? It is not enough to show that it can meet its requirement We should show that a system cannot fail to meet its requirement By testing? Dijkstra wrote (1972): Program testing can be used to show the presence of bugs, but never to show their absence By other kind of proof? Dijkstra again (1965): One can never guarantee that a proof is correct, the best one can say is: I have not discovered any mistakes What about automatic proof? It is impossible to construct a general proof procedure for arbitrary programs 1 Any hope? In some cases it is possible to mechanically verify correctness; 1 Undecidability of the halting problem, by Turing. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

7 How to Guarantee Correctness? Is it possible at all? How to show a system is correct? It is not enough to show that it can meet its requirement We should show that a system cannot fail to meet its requirement By testing? Dijkstra wrote (1972): Program testing can be used to show the presence of bugs, but never to show their absence By other kind of proof? Dijkstra again (1965): One can never guarantee that a proof is correct, the best one can say is: I have not discovered any mistakes What about automatic proof? It is impossible to construct a general proof procedure for arbitrary programs 1 Any hope? In some cases it is possible to mechanically verify correctness; in other cases... we try to do our best 1 Undecidability of the halting problem, by Turing. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

8 System Correctness A system is correct if it meets its design requirements Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

9 System Correctness Example A system is correct if it meets its design requirements System: A telephone system Requirement: If user A want to call user B, then eventually (s)he will manage to establish a connection a Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

10 System Correctness Example A system is correct if it meets its design requirements System: A telephone system Requirement: If user A want to call user B, then eventually (s)he will manage to establish a connection System: An operating system Requirement: A deadly embrace a will never happen a A deadly embrace is entered when two processes obtain access to two mutually dependent shared resources and each decide to wait indefinitely for the other Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

11 System Correctness Example A system is correct if it meets its design requirements System: A telephone system Requirement: If user A want to call user B, then eventually (s)he will manage to establish a connection System: An operating system Requirement: A deadly embrace a will never happen System: A contract for Internet services Requirement: Signatory A will never be obliged to pay more than a certain amount of money a A deadly embrace is entered when two processes obtain access to two mutually dependent shared resources and each decide to wait indefinitely for the other Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

12 System Correctness Example A system is correct if it meets its design requirements System: A telephone system Requirement: If user A want to call user B, then eventually (s)he will manage to establish a connection System: An operating system Requirement: A deadly embrace a will never happen System: A contract for Internet services Requirement: Signatory A will never be obliged to pay more than a certain amount of money a A deadly embrace is entered when two processes obtain access to two mutually dependent shared resources and each decide to wait indefinitely for the other Saying a program is correct is only meaningful w.r.t. a given specification! university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

13 What is Validation? In general, validation is the process of checking if something satisfies a certain criterion Some authors differentiate validation and verification: Validation: "Are we building the right product?", i.e., does the product do what the user really requires Verification: "Are we building the product right?", i.e., does the product conform to the specifications Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

14 What is Validation? In general, validation is the process of checking if something satisfies a certain criterion Some authors differentiate validation and verification: Validation: "Are we building the right product?", i.e., does the product do what the user really requires Verification: "Are we building the product right?", i.e., does the product conform to the specifications Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

15 What is Validation? In general, validation is the process of checking if something satisfies a certain criterion Some authors differentiate validation and verification: Validation: "Are we building the right product?", i.e., does the product do what the user really requires Verification: "Are we building the product right?", i.e., does the product conform to the specifications Remark Some authors define verification as a validation technique, others talk about V & V Validation & Verification as being complementary techniques. In this tutorial I consider verification as a validation technique university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

16 Usual Approaches for Validation The following techniques are used in industry for validation: Testing Check the actual system rather than a model Focused on sampling executions according to some coverage criteria Not exhaustive It is usually informal, though there are some formal approaches Simulation A model of the system is written in a PL, which is run with different inputs Not exhaustive Verification Is the process of applying a manual or automatic technique for establishing whether a given system satisfies a given property or behaves in accordance to some abstract description (specification) of the system 2 2 From Peled s book Software reliability methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

17 Usual Approaches for Validation The following techniques are used in industry for validation: Testing Check the actual system rather than a model Focused on sampling executions according to some coverage criteria Not exhaustive It is usually informal, though there are some formal approaches Simulation A model of the system is written in a PL, which is run with different inputs Not exhaustive Verification Is the process of applying a manual or automatic technique for establishing whether a given system satisfies a given property or behaves in accordance to some abstract description (specification) of the system 2 2 From Peled s book Software reliability methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

18 Usual Approaches for Validation The following techniques are used in industry for validation: Testing Check the actual system rather than a model Focused on sampling executions according to some coverage criteria Not exhaustive It is usually informal, though there are some formal approaches Simulation A model of the system is written in a PL, which is run with different inputs Not exhaustive Verification Is the process of applying a manual or automatic technique for establishing whether a given system satisfies a given property or behaves in accordance to some abstract description (specification) of the system 2 2 From Peled s book Software reliability methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

19 Usual Approaches for Validation The following techniques are used in industry for validation: Testing Check the actual system rather than a model Focused on sampling executions according to some coverage criteria Not exhaustive It is usually informal, though there are some formal approaches Simulation A model of the system is written in a PL, which is run with different inputs Not exhaustive Verification Is the process of applying a manual or automatic technique for establishing whether a given system satisfies a given property or behaves in accordance to some abstract description (specification) of the system 2 2 From Peled s book Software reliability methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

20 What are Formal Methods? Formal methods are a collection of notations and techniques for describing and analyzing systems 3 Formal means the methods used are based on mathematical theories, such as logic, automata, graph or set theory Formal specification techniques are used to unambiguously describe the system itself or its properties Formal analysis/verification techniques serve to verify that a system satisfies its specification (or to help finding out why it is not the case) 3 From D.Peled s book Software Reliability Methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

21 What are Formal Methods? Formal methods are a collection of notations and techniques for describing and analyzing systems 3 Formal means the methods used are based on mathematical theories, such as logic, automata, graph or set theory Formal specification techniques are used to unambiguously describe the system itself or its properties Formal analysis/verification techniques serve to verify that a system satisfies its specification (or to help finding out why it is not the case) 3 From D.Peled s book Software Reliability Methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

22 What are Formal Methods? Formal methods are a collection of notations and techniques for describing and analyzing systems 3 Formal means the methods used are based on mathematical theories, such as logic, automata, graph or set theory Formal specification techniques are used to unambiguously describe the system itself or its properties Formal analysis/verification techniques serve to verify that a system satisfies its specification (or to help finding out why it is not the case) 3 From D.Peled s book Software Reliability Methods. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

23 Limitations Software verification methods do not guarantee, in general, the correctness of the code itself but rather of an abstract model of it It cannot identify fabrication faults (e.g. in digital circuits) If the specification is incomplete or wrong, the verification result will also be wrong The implementation of verification tools may be faulty The bigger the system (number of possible states) more difficult is to analyze it (state explosion problem) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

24 Any advantage? Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

25 Any advantage? OF COURSE!! Formal methods are not intended to guarantee absolute reliability but to increase the confidence on system reliability. They help minimizing the number of errors and in many cases allow to find errors impossible to find manually Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

26 Using Formal Methods Formal methods are used in different stages of the development process, giving a classification of formal methods 1 We describe the system giving a formal specification 2 We can then prove some properties about the specification (formal verification) 3 We can proceed by: Deriving a program from its specification (formal synthesis) Verifying the specification w.r.t. implementation (formal verification) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

27 Formal Specification A specification formalism must be unambiguous: it should have a precise syntax and semantics (e.g., natural languages are not suitable) A trade-off must be found between expressiveness and analysis feasibility More expressive the specification formalism more difficult its analysis (if possible at all) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

28 Proving Properties about the Specification To gain confidence about the correctness of a specification it is useful to: Prove some properties of the specification to check that it really means what it is supposed to Prove the equivalence of different specifications Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

29 Proving Properties about the Specification To gain confidence about the correctness of a specification it is useful to: Prove some properties of the specification to check that it really means what it is supposed to Example Prove the equivalence of different specifications a should be true for the first two points of time, and then oscillates First attempt: a(0) a(1) t a(t + 1) = a(t) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

30 Proving Properties about the Specification To gain confidence about the correctness of a specification it is useful to: Prove some properties of the specification to check that it really means what it is supposed to Example Prove the equivalence of different specifications a should be true for the first two points of time, and then oscillates First attempt: a(0) a(1) t a(t + 1) = a(t) INCORRECT! - The error may be found when trying to prove some properties Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

31 Proving Properties about the Specification To gain confidence about the correctness of a specification it is useful to: Prove some properties of the specification to check that it really means what it is supposed to Example Prove the equivalence of different specifications a should be true for the first two points of time, and then oscillates First attempt: a(0) a(1) t a(t + 1) = a(t) INCORRECT! - The error may be found when trying to prove some properties Correct specification: a(0) a(1) t 0 a(t + 2) = a(t + 1) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

32 Formal synthesis It would be helpful to automatically obtain an implementation from the specification of a system Difficult since most specifications are declarative and not constructive They usually describe what the system should do; not how it can be achieved Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

33 Formal synthesis It would be helpful to automatically obtain an implementation from the specification of a system Difficult since most specifications are declarative and not constructive They usually describe what the system should do; not how it can be achieved Example 1 Specify the operational semantics of a programming language in a constructive logic (Calculus of Constructions) 2 Prove the correctness of a given property w.r.t. the operational semantics in Coq 3 Extract an OCAML code from the correctness proof (using Coq s extraction mechanism) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

34 Verifying Specifications w.r.t. Implementations There are mainly two approaches: Deductive approach (automated theorem proving) Describe the specification Φ spec in a formal model (logic) Describe the system s model Φ imp in the same formal model Prove that Φ imp = Φ spec Algorithmic approach Describe the specification Φ spec as a formula of a logic Describe the system as an interpretation M imp of the given logic (e.g. as a finite automaton) Prove that M imp is a model (in the logical sense) of Φ spec Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

35 Verifying Specifications w.r.t. Implementations There are mainly two approaches: Deductive approach (automated theorem proving) Describe the specification Φ spec in a formal model (logic) Describe the system s model Φ imp in the same formal model Prove that Φ imp = Φ spec Algorithmic approach Describe the specification Φ spec as a formula of a logic Describe the system as an interpretation M imp of the given logic (e.g. as a finite automaton) Prove that M imp is a model (in the logical sense) of Φ spec Remark The same technique may be used to prove properties about the specification university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

36 When and Which Formal Method to Use? It depends on the problem, the underlying system and the property we want to prove Examples: Digital circuits... (BDDs, model checking) Communication protocol with unbounded number of processes... (verification of infinite-state systems) Overflow in programs (static analysis and abstract interpretation)... Open distributed concurrent systems with unbounded number of processes interacting through shared variables and with real-time constraints => VERY DIFFICULT!! Need the combination of different techniques Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

37 When and Which Formal Method to Use? It depends on the problem, the underlying system and the property we want to prove Examples: Digital circuits... (BDDs, model checking) Communication protocol with unbounded number of processes... (verification of infinite-state systems) Overflow in programs (static analysis and abstract interpretation)... Open distributed concurrent systems with unbounded number of processes interacting through shared variables and with real-time constraints => VERY DIFFICULT!! Need the combination of different techniques Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

38 When and Which Formal Method to Use? It depends on the problem, the underlying system and the property we want to prove Examples: Digital circuits... (BDDs, model checking) Communication protocol with unbounded number of processes... (verification of infinite-state systems) Overflow in programs (static analysis and abstract interpretation)... Open distributed concurrent systems with unbounded number of processes interacting through shared variables and with real-time constraints => VERY DIFFICULT!! Need the combination of different techniques Remark In this tutorial: Specification and verification of contracts using logics and model checking techniques university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

39 Plan 1 Formal Methods 2 Contracts and Informatics Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

40 Contracts A contract is a binding agreement between two or more persons that is enforceable by law. [Webster on-line] Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

41 Contracts A contract is a binding agreement between two or more persons that is enforceable by law. [Webster on-line] This deed of Agreement is made between: 1. [name], from now on referred to as Provider and 2. the Client. INTRODUCTION 3. The Provider is obliged to provide the Internet Services as stipulated in this Agreement. 4. DEFINITIONS a) Internet traffic may be measured by both Client and Provider by means of Equipment and may take the two values high and normal. OPERATIVE PART 1. The Client shall not supply false information to the Client Relations Department of the Provider. 2. Whenever the Internet Traffic is high then the Client must pay [price] immediately, or the Client must notify the Provider by sending an specifying that he will pay later. 3. If the Client delays the payment as stipulated in 2, after notification he must immediately lower the Internet traffic to the normal level, and pay later twice (2 [price]). 4. If the Client does not lower the Internet traffic immediately, then the Client will have to pay 3 [price]. 5. The Client shall, as soon as the Internet Service becomes operative, submit within seven (7) university-log days the Personal Data Form from his account on the Provider s web page to the Client Relations Department of the Provider. Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

42 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

43 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

44 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc 3 In the context of web services (SOA) Service-Level Agreement, usually written in an XML-like language (e.g. WSLA) Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

45 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc 3 In the context of web services (SOA) Service-Level Agreement, usually written in an XML-like language (e.g. WSLA) 4 Behavioral interfaces Specify the sequence of interactions between different participants. The allowed interactions are captured by legal (sets of) traces Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

46 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc 3 In the context of web services (SOA) Service-Level Agreement, usually written in an XML-like language (e.g. WSLA) 4 Behavioral interfaces Specify the sequence of interactions between different participants. The allowed interactions are captured by legal (sets of) traces 5 Contractual protocols To specify the interaction between communicating entities Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

47 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc 3 In the context of web services (SOA) Service-Level Agreement, usually written in an XML-like language (e.g. WSLA) 4 Behavioral interfaces Specify the sequence of interactions between different participants. The allowed interactions are captured by legal (sets of) traces 5 Contractual protocols To specify the interaction between communicating entities 6 Social contracts : Multi-agent systems Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

48 Contracts and Informatics 1 Conventional contracts Traditional commercial and judicial domain 2 Programming by contract or Design by contract (e.g., Eiffel) Relation between pre- and post-conditions of routines, method calls, invariants, temporal dependencies, etc 3 In the context of web services (SOA) Service-Level Agreement, usually written in an XML-like language (e.g. WSLA) 4 Behavioral interfaces Specify the sequence of interactions between different participants. The allowed interactions are captured by legal (sets of) traces 5 Contractual protocols To specify the interaction between communicating entities 6 Social contracts : Multi-agent systems 7 Deontic e-contracts : representing Obligations, Permissions, Prohibitions, Power, etc university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

49 Conventional contracts Traditional commercial and judicial domain Research on Law and Informatics Interesting questions: Is it possible translate conventional contracts into formal languages/logics? Which properties are preserved? How to analyze traditional contracts? Detect superfluous clauses, cross references, inconsistencies, etc? Tools A nice successful story Jean-Marc Eber and Simon Peyton-Jones paper How to write a financial contract Eber s startup: Lexifi Technologies Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

50 Conventional contracts Traditional commercial and judicial domain Research on Law and Informatics Interesting questions: Is it possible translate conventional contracts into formal languages/logics? Which properties are preserved? How to analyze traditional contracts? Detect superfluous clauses, cross references, inconsistencies, etc? Tools A nice successful story Jean-Marc Eber and Simon Peyton-Jones paper How to write a financial contract Eber s startup: Lexifi Technologies Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

51 Conventional contracts Traditional commercial and judicial domain Research on Law and Informatics Interesting questions: Is it possible translate conventional contracts into formal languages/logics? Which properties are preserved? How to analyze traditional contracts? Detect superfluous clauses, cross references, inconsistencies, etc? Tools A nice successful story Jean-Marc Eber and Simon Peyton-Jones paper How to write a financial contract Eber s startup: Lexifi Technologies Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

52 Programming by contract The term originated with the language Eiffel ( Programming by contract or Design by contract ) Used in the context of Object-Oriented Programming Software designers should define precise verifiable interface specifications for software components Based on the theory of abstract data types Inspired by business contracts Impose an obligation to be guaranteed when calling a module: the routine s precondition An obligation for the client, and a benefit for the supplier (of the routine) Guarantee a property on exit: the routine s postcondition An obligation for the supplier, and a benefit for the client Maintain a property, assumed on entry and guaranteed on exit: the class invariant university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

53 Programming by contract The term originated with the language Eiffel ( Programming by contract or Design by contract ) Used in the context of Object-Oriented Programming Software designers should define precise verifiable interface specifications for software components Based on the theory of abstract data types Inspired by business contracts Impose an obligation to be guaranteed when calling a module: the routine s precondition An obligation for the client, and a benefit for the supplier (of the routine) Guarantee a property on exit: the routine s postcondition An obligation for the supplier, and a benefit for the client Maintain a property, assumed on entry and guaranteed on exit: the class invariant university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

54 Programming by contract The term originated with the language Eiffel ( Programming by contract or Design by contract ) Used in the context of Object-Oriented Programming Software designers should define precise verifiable interface specifications for software components Based on the theory of abstract data types Inspired by business contracts Impose an obligation to be guaranteed when calling a module: the routine s precondition An obligation for the client, and a benefit for the supplier (of the routine) Guarantee a property on exit: the routine s postcondition An obligation for the supplier, and a benefit for the client Maintain a property, assumed on entry and guaranteed on exit: the class invariant university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

55 Contracts in the Context of SOA Several SOA standards provide a way to describe contractual aspects Usually written in an XML-like language (e.g. WSLA) These service contracts act at different levels, specific to different aspects Between service provider and consumer Orchestration of services Functional aspects Describe collaboration between business partners Service-Level Agreement It describes different levels of service Availability, serviceability, performance, operation, other attributes like billing and even penalties in the case of violation Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

56 Contracts in the Context of SOA Several SOA standards provide a way to describe contractual aspects Usually written in an XML-like language (e.g. WSLA) These service contracts act at different levels, specific to different aspects Between service provider and consumer Orchestration of services Functional aspects Describe collaboration between business partners Service-Level Agreement It describes different levels of service Availability, serviceability, performance, operation, other attributes like billing and even penalties in the case of violation Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

57 Contracts in the Context of SOA Several SOA standards provide a way to describe contractual aspects Usually written in an XML-like language (e.g. WSLA) These service contracts act at different levels, specific to different aspects Between service provider and consumer Orchestration of services Functional aspects Describe collaboration between business partners Service-Level Agreement It describes different levels of service Availability, serviceability, performance, operation, other attributes like billing and even penalties in the case of violation Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

58 Contracts in the Context of SOA Several SOA standards provide a way to describe contractual aspects Usually written in an XML-like language (e.g. WSLA) These service contracts act at different levels, specific to different aspects Between service provider and consumer Orchestration of services Functional aspects Describe collaboration between business partners Service-Level Agreement It describes different levels of service Availability, serviceability, performance, operation, other attributes like billing and even penalties in the case of violation Note We will expand on a taxonomy of SOA contract specification languages in next lecture university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

59 Behavioral interfaces Specify the sequence of interactions between different participants Such interface represents a contract between the participants The allowed interactions are captured by legal (sets of) traces The behavior of objects and components can be completely defined in terms of their reaction to incoming message sequences Advantages: Different objects and component implementations can be compared based on their behavior It helps analyzing compositionality of components It is possible to analyze component implementations without knowing the context Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

60 Behavioral interfaces Specify the sequence of interactions between different participants Such interface represents a contract between the participants The allowed interactions are captured by legal (sets of) traces The behavior of objects and components can be completely defined in terms of their reaction to incoming message sequences Advantages: Different objects and component implementations can be compared based on their behavior It helps analyzing compositionality of components It is possible to analyze component implementations without knowing the context Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

61 Contractual protocols Protocols may be seen as contracts regulating the parties ideal mode of interaction Other names for the same kind of contracts Trade procedures Business protocols Specifications This definition of a contract could be mostly seen as a specification Usually one specify the point of view of each party as a Finite State Machine or Petri net Sometimes the contract is not explicit, but implicit in the interaction of the parties Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

62 Contractual protocols Protocols may be seen as contracts regulating the parties ideal mode of interaction Other names for the same kind of contracts Trade procedures Business protocols Specifications This definition of a contract could be mostly seen as a specification Usually one specify the point of view of each party as a Finite State Machine or Petri net Sometimes the contract is not explicit, but implicit in the interaction of the parties Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

63 Social contracts Based on different modal logics In the context of multi-agent systems Aim at simulate/specify social behavior Interaction between agents who can decide based on knowledge and trust on other agents Agents act according to certain normative rules prescribing: Proper and acceptable behavior (moral) Acceptable behavior (legal) Very expressive: It considers various types of norms What ought to be Expectation on what will be Particular reactions to behavior Sanctions to be applied, or how to induce a particular kind of conduct Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

64 Social contracts Based on different modal logics In the context of multi-agent systems Aim at simulate/specify social behavior Interaction between agents who can decide based on knowledge and trust on other agents Agents act according to certain normative rules prescribing: Proper and acceptable behavior (moral) Acceptable behavior (legal) Very expressive: It considers various types of norms What ought to be Expectation on what will be Particular reactions to behavior Sanctions to be applied, or how to induce a particular kind of conduct Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

65 Social contracts Based on different modal logics In the context of multi-agent systems Aim at simulate/specify social behavior Interaction between agents who can decide based on knowledge and trust on other agents Agents act according to certain normative rules prescribing: Proper and acceptable behavior (moral) Acceptable behavior (legal) Very expressive: It considers various types of norms What ought to be Expectation on what will be Particular reactions to behavior Sanctions to be applied, or how to induce a particular kind of conduct Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

66 Electronic deontic contracts Based on deontic logic and combined with other modal logics It contains constructs to specify at least Obligations, Permissions, and Prohibitions A contract can be obtained From a conventional contract Written directly in a formal specification language It allows formal reasoning Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

67 Contracts In this tutorial We will see deontic e-contracts Two scenarios: 1 Obtain an e-contract from a conventional contract Context: legal (e.g. financial) contracts 2 Write the e-contract directly in a formal language Context: web services, components, OO, etc Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

68 Contracts In this tutorial We will see deontic e-contracts Two scenarios: 1 Obtain an e-contract from a conventional contract Context: legal (e.g. financial) contracts 2 Write the e-contract directly in a formal language Context: web services, components, OO, etc Definition A contract is a document which engages several parties in a transaction and stipulates their (conditional) obligations, rights, and prohibitions, as well as penalties in case of contract violations. university-log Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

69 Links and Papers Introduction to Formal Methods: See first lecture of the course Specification and verification of parallel systems (INF5140) and references therein: INF5140/v07/undervisningsmateriale/1-formal-methods.pdf Gerardo Schneider (UiO) Specification and Analysis of e-contracts SEFM, 3-7 Nov / 28

### INF5140: Specification and Verification of Parallel Systems

Motivation INF5140: Specification and Verification of Parallel Systems Lecture 1 Introduction: Formal Methods Gerardo Schneider Department of Informatics University of Oslo INF5140, Spring 2009 Outline

### Software testing. Objectives

Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating

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

### Introducing Formal Methods. Software Engineering and Formal Methods

Introducing Formal Methods Formal Methods for Software Specification and Analysis: An Overview 1 Software Engineering and Formal Methods Every Software engineering methodology is based on a recommended

### Introduction to Formal Methods. Các Phương Pháp Hình Thức Cho Phát Triển Phần Mềm

Introduction to Formal Methods Các Phương Pháp Hình Thức Cho Phát Triển Phần Mềm Outline Introduction Formal Specification Formal Verification Model Checking Theorem Proving Introduction Good papers to

### TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.

CH04 Capturing the Requirements Understanding what the customers and users expect the system to do * The Requirements Process * Types of Requirements * Characteristics of Requirements * How to Express

### Kirsten Sinclair SyntheSys Systems Engineers

Kirsten Sinclair SyntheSys Systems Engineers Kirsten Sinclair SyntheSys Systems Engineers Spicing-up IBM s Enterprise Architecture tools with Petri Nets On Today s Menu Appetiser: Background Starter: Use

### 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,

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

### A Framework for the Semantics of Behavioral Contracts

A Framework for the Semantics of Behavioral Contracts Ashley McNeile Metamaxim Ltd, 48 Brunswick Gardens, London W8 4AN, UK ashley.mcneile@metamaxim.com Abstract. Contracts have proved a powerful concept

### A Classification of Model Checking-based Verification Approaches for Software Models

A Classification of Model Checking-based Verification Approaches for Software Models Petra Brosch, Sebastian Gabmeyer, Martina Seidl Sebastian Gabmeyer Business Informatics Group Institute of Software

### Rigorous Software Development CSCI-GA 3033-009

Rigorous Software Development CSCI-GA 3033-009 Instructor: Thomas Wies Spring 2013 Lecture 5 Disclaimer. These notes are derived from notes originally developed by Joseph Kiniry, Gary Leavens, Erik Poll,

### Model Checking: An Introduction

Announcements Model Checking: An Introduction Meeting 2 Office hours M 1:30pm-2:30pm W 5:30pm-6:30pm (after class) and by appointment ECOT 621 Moodle problems? Fundamentals of Programming Languages CSCI

### Coverability for Parallel Programs

2015 http://excel.fit.vutbr.cz Coverability for Parallel Programs Lenka Turoňová* Abstract We improve existing method for the automatic verification of systems with parallel running processes. The technique

### Model Checking based Software Verification

Model Checking based Software Verification 18.5-2006 Keijo Heljanko Keijo.Heljanko@tkk.fi Department of Computer Science and Engineering Helsinki University of Technology http://www.tcs.tkk.fi/~kepa/ 1/24

### School of Computer Science

School of Computer Science Computer Science - Honours Level - 2014/15 October 2014 General degree students wishing to enter 3000- level modules and non- graduating students wishing to enter 3000- level

### ONLINE EXERCISE SYSTEM A Web-Based Tool for Administration and Automatic Correction of Exercises

ONLINE EXERCISE SYSTEM A Web-Based Tool for Administration and Automatic Correction of Exercises Daniel Baudisch, Manuel Gesell and Klaus Schneider Embedded Systems Group, University of Kaiserslautern,

### Verifying Semantic of System Composition for an Aspect-Oriented Approach

2012 International Conference on System Engineering and Modeling (ICSEM 2012) IPCSIT vol. 34 (2012) (2012) IACSIT Press, Singapore Verifying Semantic of System Composition for an Aspect-Oriented Approach

### Software Engineering. How does software fail? Terminology CS / COE 1530

Software Engineering CS / COE 1530 Testing How does software fail? Wrong requirement: not what the customer wants Missing requirement Requirement impossible to implement Faulty design Faulty code Improperly

### Challenges and Opportunities for formal specifications in Service Oriented Architectures

ACSD ATPN Xi an China June 2008 Challenges and Opportunities for formal specifications in Service Oriented Architectures Gustavo Alonso Systems Group Department of Computer Science Swiss Federal Institute

### Model Checking of Software

Model Checking of Software Patrice Godefroid Bell Laboratories, Lucent Technologies SpecNCheck Page 1 August 2001 A Brief History of Model Checking Prehistory: transformational programs and theorem proving

### The Model Checker SPIN

The Model Checker SPIN Author: Gerard J. Holzmann Presented By: Maulik Patel Outline Introduction Structure Foundation Algorithms Memory management Example/Demo SPIN-Introduction Introduction SPIN (Simple(

### Formal Verification of Software

Formal Verification of Software Sabine Broda Department of Computer Science/FCUP 12 de Novembro de 2014 Sabine Broda (DCC-FCUP) Formal Verification of Software 12 de Novembro de 2014 1 / 26 Formal Verification

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

### Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or

### Simulation-Based Security with Inexhaustible Interactive Turing Machines

Simulation-Based Security with Inexhaustible Interactive Turing Machines Ralf Küsters Institut für Informatik Christian-Albrechts-Universität zu Kiel 24098 Kiel, Germany kuesters@ti.informatik.uni-kiel.de

### CSE4213 Lecture Notes

CSE4213 Lecture Notes Introduction to B Tools Computer Science and Software Engineering Monash University 20070226 / Lecture 1 ajh 1/15 1 Outline 2 3 4 5 ajh 2/15 In this course we will be introducing

### Mathematical Reasoning in Software Engineering Education. Peter B. Henderson Butler University

Mathematical Reasoning in Software Engineering Education Peter B. Henderson Butler University Introduction Engineering is a bridge between science and mathematics, and the technological needs of mankind.

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

### Software Engineering using Formal Methods

Software Engineering using Formal Methods Model Checking with Temporal Logic Wolfgang Ahrendt 24th September 2013 SEFM: Model Checking with Temporal Logic /GU 130924 1 / 33 Model Checking with Spin model

### Software Active Online Monitoring Under. Anticipatory Semantics

Software Active Online Monitoring Under Anticipatory Semantics Changzhi Zhao, Wei Dong, Ji Wang, Zhichang Qi National Laboratory for Parallel and Distributed Processing P.R.China 7/21/2009 Overview Software

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

### Software Testing. Quality & Testing. Software Testing

Software Testing Software Testing Error: mistake made by the programmer/developer Fault: a incorrect piece of code/document (i.e., bug) Failure: result of a fault Goal of software testing: Cause failures

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

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

### T-79.186 Reactive Systems: Introduction and Finite State Automata

T-79.186 Reactive Systems: Introduction and Finite State Automata Timo Latvala 14.1.2004 Reactive Systems: Introduction and Finite State Automata 1-1 Reactive Systems Reactive systems are a class of software

### Tilburg University. Publication date: 2010. Link to publication

Tilburg University On the formal specification of business contracts and regulatory compliance Elgammal, Onbekend; Türetken, O.; van den Heuvel, Willem-Jan; Papazoglou, Mike Published in: Proceedings of

### Software Engineering. Software Testing. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering Software Testing Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To discuss the distinctions between validation testing and defect t testing To describe the

### 8.6 WORKING OUT CONTRACTING CONDITIONS

SELECTING AND DESCRIBING OBJECT SCENARIOS 205 and the text For more information, select destination. He presses Mallorca and picks the first alternative from the resulting menu Major sights, Hotels, Recreations.

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

### Lecture 17: Requirements Specifications

Lecture 17: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications

### StaRVOOrS: A Tool for Combined Static and Runtime Verification of Java

StaRVOOrS: A Tool for Combined Static and Runtime Verification of Java Jesús Mauricio Chimento 1, Wolfgang Ahrendt 1, Gordon J. Pace 2, and Gerardo Schneider 3 1 Chalmers University of Technology, Sweden.

### Chapter 8 Software Testing

Chapter 8 Software Testing Summary 1 Topics covered Development testing Test-driven development Release testing User testing 2 Program testing Testing is intended to show that a program does what it is

### Contracts between Software Agents

Contracts between Software Agents Agents and Intelligent Systems Group King s College London Simon Miles Nir Oren Michael Luck (and including work with Sanjay Modgil, Nora Faci, Martin Kollingbaum) Automation

### Algorithmic Software Verification

Algorithmic Software Verification (LTL Model Checking) Azadeh Farzan What is Verification Anyway? Proving (in a formal way) that program satisfies a specification written in a logical language. Formal

### Software Engineering Reference Framework

Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

### Development of global specification for dynamically adaptive software

Development of global specification for dynamically adaptive software Yongwang Zhao School of Computer Science & Engineering Beihang University zhaoyw@act.buaa.edu.cn 22/02/2013 1 2 About me Assistant

### The Course. http://www.cse.unsw.edu.au/~cs3153/

The Course http://www.cse.unsw.edu.au/~cs3153/ Lecturers Dr Peter Höfner NICTA L5 building Prof Rob van Glabbeek NICTA L5 building Dr Ralf Huuck NICTA ATP building 2 Plan/Schedule (1) Where and When Tuesday,

### Creating semantically valid topic maps

Creating semantically valid topic maps Geir Ove Gr nmo STEP Infotek A.S., Oslo, Norway grove@infotek.no http://www.infotek.no Abstract: A topic map, like a database or XML document, provides a way of structuring

### Model-Checking Verification for Reliable Web Service

Model-Checking Verification for Reliable Web Service Shin NAKAJIMA Hosei University and PRESTO, JST nkjm@i.hosei.ac.jp Abstract Model-checking is a promising technique for the verification and validation

### Basic Testing Concepts and Terminology

T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts

### CS52600: Information Security

CS18000: Programming I CS52600: Information Security Vulnerability Analysis 15 November 2010 Prof. Chris Clifton Vulnerability Analysis Vulnerability: Lapse in enforcement enabling violation of security

### Chair of Software Engineering. Software Verification. Assertion Inference. Carlo A. Furia

Chair of Software Engineering Software Verification Assertion Inference Carlo A. Furia Proving Programs Automatically The Program Verification problem: Given: a program P and a specification S = [Pre,

### Lecture 9 verifying temporal logic

Basics of advanced software systems Lecture 9 verifying temporal logic formulae with SPIN 21/01/2013 1 Outline for today 1. Introduction: motivations for formal methods, use in industry 2. Developing models

### Software Verification: Infinite-State Model Checking and Static Program

Software Verification: Infinite-State Model Checking and Static Program Analysis Dagstuhl Seminar 06081 February 19 24, 2006 Parosh Abdulla 1, Ahmed Bouajjani 2, and Markus Müller-Olm 3 1 Uppsala Universitet,

### Sofware Requirements Engineeing

Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (). Understandable

### UML TUTORIALS THE USE CASE MODEL

UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between

### Today s Agenda. Automata and Logic. Quiz 4 Temporal Logic. Introduction Buchi Automata Linear Time Logic Summary

Today s Agenda Quiz 4 Temporal Logic Formal Methods in Software Engineering 1 Automata and Logic Introduction Buchi Automata Linear Time Logic Summary Formal Methods in Software Engineering 2 1 Buchi Automata

### Runtime Verification - Monitor-oriented Programming - Monitor-based Runtime Reflection

Runtime Verification - Monitor-oriented Programming - Monitor-based Runtime Reflection Martin Leucker Technische Universität München (joint work with Andreas Bauer, Christian Schallhart et. al) FLACOS

### Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors

Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors Klaus Wissing PolySpace Technologies GmbH Argelsrieder Feld 22 82234 Wessling-Oberpfaffenhofen

### Policy Modeling and Compliance Verification in Enterprise Software Systems: a Survey

Policy Modeling and Compliance Verification in Enterprise Software Systems: a Survey George Chatzikonstantinou, Kostas Kontogiannis National Technical University of Athens September 24, 2012 MESOCA 12,

### ADAPTIVE SOA INFRASTRUCTURE BASED ON VARIABILITY MANAGEMENT. Peter Graubmann, Mikhail Roshchin

70 ADAPTIVE SOA INFRASTRUCTURE BASED ON VARIABILITY MANAGEMENT Peter Graubmann, Mikhail Roshchin Abstract: In order to exploit the adaptability of a SOA infrastructure, it becomes necessary to provide

### Quality Management. Lecture 12 Software quality management

Quality Management Lecture 12 Software quality management doc.dr.sc. Marko Jurčević prof.dr.sc. Roman Malarić University of Zagreb Faculty of Electrical Engineering and Computing Department of Fundamentals

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

### Lecture 03 (04.11.2013) Quality of the Software Development Process

Systeme hoher Qualität und Sicherheit Universität Bremen, WS 2013/14 Lecture 03 (04.11.2013) Quality of the Software Development Process Christoph Lüth Christian Liguda Your Daily Menu Models of Software

### CS Master Level Courses and Areas COURSE DESCRIPTIONS. CSCI 521 Real-Time Systems. CSCI 522 High Performance Computing

CS Master Level Courses and Areas The graduate courses offered may change over time, in response to new developments in computer science and the interests of faculty and students; the list of graduate

### Doctor of Philosophy in Computer Science

Doctor of Philosophy in Computer Science Background/Rationale The program aims to develop computer scientists who are armed with methods, tools and techniques from both theoretical and systems aspects

Business Rules and Decision Processes in Mediated Business Coordination Zheng Zhao and Virginia Dignum and Frank Dignum Department of Information and Computing Sciences Utrecht University The Netherlands

### Testing LTL Formula Translation into Büchi Automata

Testing LTL Formula Translation into Büchi Automata Heikki Tauriainen and Keijo Heljanko Helsinki University of Technology, Laboratory for Theoretical Computer Science, P. O. Box 5400, FIN-02015 HUT, Finland

### Structure of Presentation. Stages in Teaching Formal Methods. Motivation (1) Motivation (2) The Scope of Formal Methods (1)

Stages in Teaching Formal Methods A. J. Cowling Structure of Presentation Introduction to Issues Motivation for this work. Analysis of the Role of Formal Methods Define their scope; Review their treatment

### Rigorous. Development. Software. Program Verification. & Springer. An Introduction to. Jorge Sousa Pinto. Jose Bacelar Almeida Maria Joao Frade

Jose Bacelar Almeida Maria Joao Frade Jorge Sousa Pinto Simao Melo de Sousa Rigorous Software Development An Introduction to Program Verification & Springer Contents 1 Introduction 1 1.1 A Formal Approach

### Formal Verification by Model Checking

Formal Verification by Model Checking Natasha Sharygina Carnegie Mellon University Guest Lectures at the Analysis of Software Artifacts Class, Spring 2005 1 Outline Lecture 1: Overview of Model Checking

### Master of Science in Computer Science

Master of Science in Computer Science Background/Rationale The MSCS program aims to provide both breadth and depth of knowledge in the concepts and techniques related to the theory, design, implementation,

### Personal data and cloud computing, the cloud now has a standard. by Luca Bolognini

Personal data and cloud computing, the cloud now has a standard by Luca Bolognini Lawyer, President of the Italian Institute for Privacy and Data Valorization, founding partner ICT Legal Consulting Last

### The Service Revolution software engineering without programming languages

The Service Revolution software engineering without programming languages Gustavo Alonso Institute for Pervasive Computing Department of Computer Science Swiss Federal Institute of Technology (ETH Zurich)

### The CompCert verified C compiler

The CompCert verified C compiler Compiler built and proved by Xavier Leroy et al. Talk given by David Pichardie - Harvard University / INRIA Rennes Slides largely inspired by Xavier Leroy own material

### 11-QA 1 11-QA. Increased cost to distribute modifications Technical reviews. Increased customer support Document reviews

Software Qualities Quality Assurance Maintainer Go Documentation Readable Ce Go Design Functionality Ease of use Ease of learning User Reliability Correctness Efficiency Low Cost Portability Increased

### Analyzing Service Contract with Model Checking

Analyzing Service Contract with Model Checking Contract-Oriented Software Development for Internet Services Joseph C. Okika, Anders P. Ravn Department of Computer Science Aalborg University, Denmark FLACOS

### Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program.

Software Testing Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program. Testing can only reveal the presence of errors and not the

### Process Modelling from Insurance Event Log

Process Modelling from Insurance Event Log P.V. Kumaraguru Research scholar, Dr.M.G.R Educational and Research Institute University Chennai- 600 095 India Dr. S.P. Rajagopalan Professor Emeritus, Dr. M.G.R

### On the Relation between Design Contracts and Errors: A Software Development Strategy

On the Relation between Design Contracts and Errors: A Software Development Strategy Eivind J. Nordby, Martin Blom, Anna Brunstrom Computer Science, Karlstad University SE-651 88 Karlstad, Sweden {Eivind.Nordby,

### Datavetenskapligt Program (kandidat) Computer Science Programme (master)

Datavetenskapligt Program (kandidat) Computer Science Programme (master) Wolfgang Ahrendt Director Datavetenskap (BSc), Computer Science (MSc) D&IT Göteborg University, 30/01/2009 Part I D&IT: Computer

### Execution of A Requirement Model in Software Development

Execution of A Requirement Model in Software Development Wuwei Shen, Mohsen Guizani and Zijiang Yang Dept of Computer Science, Western Michigan University {wwshen,mguizani,zijiang}@cs.wmich.edu Kevin Compton

### IV. Software Lifecycles

IV. Software Lifecycles Software processes and lifecycles Relative costs of lifecycle phases Examples of lifecycles and processes Process maturity scale Information system development lifecycle Lifecycle

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

### Model Based Testing for Security Checking. Wissam Mallouli and Prof. Ana Cavalli National Institute of Telecommunications, France November 21, 2007

Model Based Testing for Security Checking Wissam Mallouli and Prof. Ana Cavalli National Institute of Telecommunications, France November 21, 2007 Outline Introduction Active/Passive Testing Active Testing

### Virtual Time and Timeout in Client-Server Networks

Virtual Time and Timeout in Client-Server Networks Jayadev Misra July 13, 2011 Contents 1 Introduction 2 1.1 Background.............................. 2 1.1.1 Causal Model of Virtual Time...............

### Software Engineering in a Nutshell

Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of

### BIS 3106: Business Process Management. Lecture Two: Modelling the Control-flow Perspective

BIS 3106: Business Process Management Lecture Two: Modelling the Control-flow Perspective Makerere University School of Computing and Informatics Technology Department of Computer Science SEM I 2015/2016

### Properties of Stabilizing Computations

Theory and Applications of Mathematics & Computer Science 5 (1) (2015) 71 93 Properties of Stabilizing Computations Mark Burgin a a University of California, Los Angeles 405 Hilgard Ave. Los Angeles, CA

### A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation

PLDI 03 A Static Analyzer for Large Safety-Critical Software B. Blanchet, P. Cousot, R. Cousot, J. Feret L. Mauborgne, A. Miné, D. Monniaux,. Rival CNRS École normale supérieure École polytechnique Paris

### Principles of Software Engineering: Course Outline. Ethan Jackson And Wolfram Schulte, Research in Software Engineering (RiSE) Microsoft Research

Principles of Software Engineering: Course Outline Ethan Jackson And Wolfram Schulte, Research in Software Engineering (RiSE) Microsoft Research Overview Motivation and Focus Syllabus Projects i. Motivation

### Testing & Verification of Digital Circuits ECE/CS 5745/6745. Hardware Verification using Symbolic Computation

Testing & Verification of Digital Circuits ECE/CS 5745/6745 Hardware Verification using Symbolic Computation Instructor: Priyank Kalla (kalla@ece.utah.edu) 3 Credits Mon, Wed, 1:25-2:45pm, WEB L105 Office

### The ConTract Model. Helmut Wächter, Andreas Reuter. November 9, 1999

The ConTract Model Helmut Wächter, Andreas Reuter November 9, 1999 Overview In Ahmed K. Elmagarmid: Database Transaction Models for Advanced Applications First in Andreas Reuter: ConTracts: A Means for

### Annex 1. Contract Checklist for Cloud-Based Genomic Research Version 1.0, 21 July 2015

Annex 1. Contract Checklist for Cloud-Based Genomic Research Version 1.0, 21 July 2015 The following comprises a checklist of areas that genomic research organizations or consortia (collectively referred

### introduction to program monitoring

introduction to program monitoring CS 119 part II beyond assert and print course website http://www.runtime-verification.org/course09 action standing order: sell when price drops more than 2% within 1

### Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development

Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development The FDA requires medical software development teams to comply with its standards for software

### Data Model Bugs. Ivan Bocić and Tevfik Bultan

Data Model Bugs Ivan Bocić and Tevfik Bultan Department of Computer Science University of California, Santa Barbara, USA bo@cs.ucsb.edu bultan@cs.ucsb.edu Abstract. In today s internet-centric world, web