Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)

Slides:



Advertisements
Similar presentations
Formal Specifications
Advertisements

1 Note content copyright © 2004 Ian Sommerville. NU-specific content © 2004 M. E. Kabay. All rights reserved. Formal Specification IS301 – Software Engineering.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Lilian Blot Announcements Teaching Evaluation Form week 9 practical session Formative Assessment week 10 during usual practical sessions group 1 Friday.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
CS 355 – Programming Languages
Software Engineering and Design Principles Chapter 1.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Katz Formal Specifications Larch 1 Algebraic Specification and Larch Formal Specifications of Complex Systems Shmuel Katz The Technion.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 91 Formal Specification l Techniques for the unambiguous specification of software.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
Describing Syntax and Semantics
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 10 Slide 1 Formal Specification.
MCA –Software Engineering Kantipur City College. Topics include  Formal Methods Concept  Formal Specification Language Test plan creation Test-case.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Abstract data types What does ‘ abstract ’ mean? From Latin: to ‘ pull out ’— the essentials –To defer or hide the details –Abstraction emphasizes essentials.
Ranga Rodrigo. Class is central to object oriented programming.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Formal Specification l Techniques for the unambiguous specification of software.
©Ian Sommerville 2000Software Engineering, Chapter 10 Slide 1 Chapter 10 Formal Specification.
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 9 Slide 1 Chapter 9 Formal Specifications.
TECH Computer Science Data Abstraction and Basic Data Structures Improving efficiency by building better  Data Structure Object IN  Abstract Data Type.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
WXGE6103 Software Engineering Process and Practice Formal Specification.
111 Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract,
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
CS 363 Comparative Programming Languages Semantics.
ISBN Chapter 3 Describing Semantics.
Chapter 3 Part II Describing Syntax and Semantics.
Programming Languages and Design Lecture 3 Semantic Specifications of Programming Languages Instructor: Li Ma Department of Computer Science Texas Southern.
SWEN 5130Requirements Engineering Algebraic Specification Slide 1 Algebraic Specification u Specifying abstract types in terms of relationships between.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
1 / 48 Formal a Language Theory and Describing Semantics Principles of Programming Languages 4.
90-723: Data Structures and Algorithms for Information Processing Copyright © 1999, Carnegie Mellon. All Rights Reserved. 1 Lecture 1: Introduction Data.
Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, Mitchell, R., and McKim, Design by Contract,
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
Requirements Engineering Methods for Requirements Engineering Lecture-31.
©Ian Sommerville 2000Software Engineering, Chapter 10 Slide 1 Chapter 10 Formal Specification.
Defining Classes I Part B. Information hiding & encapsulation separate how to use the class from the implementation details separate how to use the class.
Faithful mapping of model classes to mathematical structures Ádám Darvas ETH Zürich Switzerland Peter Müller Microsoft Research Redmond, WA, USA SAVCBS.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VII. System Specification (I)
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVIII. Software Testing.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini VIII. Specifications (II)
IS301 – Software Engineering V:
Formal Specification.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Algebraic Specifications
Chapter 27 Formal Specification.
Logical architecture refinement
Semantics In Text: Chapter 3.
Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract, Computer,
Algebraic Specification Software Specification Lecture 34
Program correctness Axiomatic semantics
Presentation transcript:

Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini IX. System Models (III)

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 2 Objective Introduce formal descriptive notation Logic Algebraic Z

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 3 Logic Specifications Use of First Order Logic formula to describe program properties Expressions involve variables, numeric constants, functions, predicates. Logical connectives and, or, not, implies, for all, exists Examples x > y and y > z implies x>z for all i in N x[i] > x[i+1] for all M in N (exist n in N(n>M)) Free variables and bound variables

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 4 Logic Specifications – input/output assertions A property for a program or a subprogram P is specified as a formula of type {Pre(i 1,i 2,...,i n )} P {Post(O 1,O 2,...,O m,i 1,i 2,...,i n )}

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 5 input/output assertions - example {true} P {(o=i 1 or o=i 2 ) and o  i 1 and o  i 2 } {n>0} P {o=  k=1...n  i k } {(i 1 >0 and i 2 >0)} P {(exists z 1,z 2 (i 1 =o x z 1 and i 2 =o x z 2 ) and not (exists h(i 1 =h x z 1 and i 2 =h x z 2 ) and h>o))}

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 6 Generalising input/output assertions We would like to talk of programs fragments! The language should be able to refer variables defined within the program {n > 0} – n is a constant value procedure search(table: in integer_array; n: in integer; element: in integer; found: out Boolean); {found=(exist i(1<=i<=n and table(i)=element))}

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 7 input/output assertions and classes The language “predicates” over object variables and data structures defining: Invariants Object states Methods execution must preserve invariants Examples: set abstraction or ordered set abstraction Pre- and Post-conditions on each methods {INV and precondition} program fragment for m {INV and post-condition} Logical statements defined by the developer to increase verification power

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 8 Example public class Queue { Object[] queue; int length,head,tail,elementInQueue; public Queue(int length) { queue = new Object[length]; this.length=length;this.head=0;this.tail=0;this.elementInQueue=0; } public void insert(Object o) { queue[head]=o;head++;elementInQueue++; if (head==length) head=0; } public Object remove() { Object o = queue[tail];tail++;elementInQueue--; if (tail==length) tail=0; return o; } public boolean isEmpty() { return (head==tail); }

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 9 Design by Contract Engineering principle known as Design by Contract (DbC) Logical statements defined at the interface level Constitute the agreement among the contractor and the client Support in programming languages: Eiffel, JContractor... Design vs. Requirements using logic specifications Which is the universe of discourse?

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 10 Verification of Specifications Using FOT you specify that any implementation must guarantee that all of the given rules are true Logical expressions can be used to analyze system properties applying logical deduction Derive the formula from the specification of the system Operational formalisms do not allow to prove properties You can discover behaviour but you cannot provide a proof! Proving theorems is not a decidable problem within FOT

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 11 Algebraic Specification Large systems are decomposed into subsystems with well-defined interfaces between these subsystems. Specification of subsystem interfaces allows independent development of the different subsystems. Interfaces may be defined as abstract data types or object classes. The algebraic approach to formal specification is particularly well-suited to interface specification as it is focused on the defined operations in an object.

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 12 Specification elements Introduction Defines the sort (the type name) and declares other specifications that are used. Description Informally describes the operations on the type. Signature Defines the syntax of the operations in the interface and their parameters. Axioms Defines the operation semantics by defining axioms which characterise behaviour.

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 13 Systematic Algebraic Specification Algebraic specifications of a system may be developed in a systematic way Specification structuring; Specification naming; Operation selection; Informal operation specification; Syntax definition; Axiom definition.

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 14 Specification Operations Constructor operations. Operations which create entities of the type being specified. Inspection operations. Operations which evaluate entities of the type being specified. Rule of thumb: identify constructor operations and define inspector operations for each primitive constructor operation.

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 15 Operations on a List ADT Constructor operations which evaluate to sort List Create, Cons and Tail. Inspection operations which take sort list as a parameter and return some other sort Head and Length. Tail can be defined using the simpler constructors Create and Cons. No need to define Head and Length with Tail.

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 16 Operations on a List ADT LIST(ELEM) sort List imports INTEGER Defines a list where elements are added at the end and removed from the front. The operations are Create, which brings an empty list into existence, Cons, which creates a new list with an added member, Length, which evaluates the list size, Head, which evaluates the front element of the list, and Tail, which creates a list by removing the head from its input list. Undefined represents an undefined value of type Elem. Create --> List Cons(List, Elem) --> List Head(List) --> Elem Length(List) --> Integer Tail(List) --> List Head(Create) = Undefined exception (empty list) Head(Cons(L,v)) = if L = Create then v else Head(L) Length(Create)=0 Length(Cons(L,v)) = Length(L) + 1 Tail(Create) = Create Tail(Cons(L,v)) = if L = Create then Create else Cons(Tail(L),v)

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 17 Operations on a List ADT Operations are often specified recursively. Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v). Cons ([5, 7], 9) = [5, 7, 9] Tail ([5, 7, 9]) = Tail (Cons ( [5, 7], 9)) = Cons (Tail ([5, 7]), 9) = Cons (Tail (Cons ([5], 7)), 9) = Cons (Cons (Tail ([5]), 7), 9) = Cons (Cons (Tail (Cons ([], 5)), 7), 9) = Cons (Cons ([Create], 7), 9) = Cons ([7], 9) = [7, 9]

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 18 Algebraic specifications Algebraic Specifications can be easily combined Reuse of algebras Import allow to reuse Assume allows to rewrite definition

Ingegneria del Software I – A.A. 2006/2007 Andrea Polini 19 Keynote Discussed two formalism for defining a software specification with a descriptive flavour Use of FOT Algebraic specification Operational spec better for simulation descriptive for analysis Limitations of analysis have been highlighted