Chair of Software Engineering OOSC - Summer Semester 2005 1 Object-Oriented Software Construction Bertrand Meyer Lecture 10: Project Presentation Ilinca.

Slides:



Advertisements
Similar presentations
Building Bug-Free O-O Software: An Introduction to Design By Contract A presentation about Design By Contract and the Eiffel software development tool.
Advertisements

Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 1: Eiffel Introduction.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 3: Abstract Data Types.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic 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.
Design by Contract ™. 2 Design by Contract A discipline of analysis, design, implementation, management.
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Chair of Software Engineering ATOT - Lecture 10, 5 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 15: Exception handling.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 2 23 September 2008.
Software Testing and Quality Assurance
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 11: Design by Contract™
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 12, 12 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 12: Design by Contract™
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 6 7 October 2008.
Chair of Software Engineering OOSC - Lecture 4 1 Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 5: Project and EiffelStudio Presentation.
Chair of Software Engineering OOSC - Lecture 21 1 Object-Oriented Software Construction Bertrand Meyer.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 9: Contracts and Inheritance (based on work with.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 1: Modularity.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 14: Presentation of EiffelStudio.
Chair of Software Engineering ATOT - Lecture 11, 7 May Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering ATOT - Lecture 2, 2 April Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 6: Genericity.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chapter 1 Principles of Programming and Software Engineering.
Chair of Software Engineering Automatic Verification of Computer Programs.
Chair of Software Engineering Updated: 04 April 2006 Lecture 1: Course overview and introduction Concurrent Object-Oriented Programming Bertrand Meyer,
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
Chair of Software Engineering Object-Oriented Software Construction Bertrand Meyer Lecture 21: Agents and tuples.
Adding Contracts to Ada Ehud Lamm Adding Design By Contract to Ada.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
1 © Wolfgang Pelz Design by Contract Design by Contract™ Based on material drawn from: Bertrand.
Ranga Rodrigo. Class is central to object oriented programming.
Testing. Definition From the dictionary- the means by which the presence, quality, or genuineness of anything is determined; a means of trial. For software.
Selenium automated testing in Openbravo ERP Quality Assurance Webinar April 8th, 2010.
Program documentation Using the Doxygen tool Program documentation1.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
90-723: Data Structures and Algorithms for Information Processing Copyright © 1999, Carnegie Mellon. All Rights Reserved. 1 Lecture 1: Introduction Data.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
1 Assertions. 2 A boolean expression or predicate that evaluates to true or false in every state In a program they express constraints on the state that.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Principles of Programming & Software Engineering
Working in the Forms Developer Environment
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Principles of Programming and Software Engineering
Design by Contract in Python: Present and Future Aaron Bingham
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Design by contract Object-Oriented Software Construction by Bertrand Meyer, Prentice Hall The presence of a precondition or postcondition in a routine.
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Presentation transcript:

Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 10: Project Presentation Ilinca Ciupa

Chair of Software Engineering OOSC - Summer Semester Organizational matters  Project deadline: 30 June 2005 (last day of the semester)  You will work on the project in groups of 2  Project specification available at: t/Project_Specification.pdf

Chair of Software Engineering OOSC - Summer Semester Project development  Implementation language: Eiffel  Project should compile and run under Windows and Unix (at least)

Chair of Software Engineering OOSC - Summer Semester Overview  The project has 2 parts:  Object Spyglass  Testing framework  Testing framework is a client of the Spyglass  Spyglass must:  Expose its functionality through an interface  Remain independent of client implementation Object SpyglassTesting Framework

Chair of Software Engineering OOSC - Summer Semester Object Spyglass (1)  This snapshot will contain  The objects that its client (in this case the testing framework) passes to it  Any objects reachable from these  Main task: display a snapshot of the state of a running Eiffel system at a particular point of its execution

Chair of Software Engineering OOSC - Summer Semester  Additional functionality:  Allow the user to navigate the object structure by expanding and collapsing object fields  Desirable features:  The ability to store user preferences about the layout of objects  Heuristics to apply these preferences to subsequent runs of the system Object Spyglass (2)

Chair of Software Engineering OOSC - Summer Semester Contracts in Eiffel  In the Eiffel method, contracts are:  Routine preconditions – properties that must hold whenever the routine is called  Routine postconditions – properties that the routine guarantees when it returns  Class invariants – properties that the instances of a class satisfy at all “stable” times  Loop variants and invariants – loop correctness constructs  check instructions – express the software writer’s conviction that a certain property will be satisfied at certain stages of the computation  Contracts are expressed with assertions (boolean expressions + old notation)

Chair of Software Engineering OOSC - Summer Semester  Relies on contract violations to signal bugs  Works based on:  Test cases – contain:  Test inputs  Conditions for execution (preconditions of the tested routines)  Calls to the tested routines  Expected results (assertions)  Test driver – runs the test cases  When a contract violation occurs, the Spyglass helps the user understand the cause of the bug by providing a graphical display of the last saved system state. (It is the responsibility of the user to save state by inserting in his code calls to a state saving facility.) Testing framework

Chair of Software Engineering OOSC - Summer Semester Testing framework - Functionality  Lets users write test cases  Runs the test cases  Provides a state saving facility which allows users to record system state at particular points in the execution  If a contract is violated when running the test cases, the testing framework:  Displays information regarding the violated assertion (where it occurred, type and tag of contract)  Displays information regarding the location of the last performed state saving operation  Calls the Spyglass to display the last saved system state

Chair of Software Engineering OOSC - Summer Semester Example – System under test (1) (all code written by user) class EMPLOYEE … feature -- Basic operation receive_salary (sum: INTEGER) is -- Deposit `sum' in the employee's account after deducing -- taxes. require sum_positive: sum > 0 local a_list: LIST [ANY] do -- Save state. create {ARRAYED_LIST [ANY]} a_list.make (0) a_list.extend (Current) a_list.extend (sum) state_manager.save_state (generating_type, "receive_salary", a_list) salary_account.deposit (sum - tax (sum)) end State saving Routine body Functionality provided by the testing framework

Chair of Software Engineering OOSC - Summer Semester Example – System under test (2) (all code written by user) tax (sum: INTEGER): DOUBLE is -- Taxes that the employee pays for `sum'. require sum_positive: sum > 0 local pension, health_insurance: DOUBLE a_list: LIST [ANY] do -- Save state. create {ARRAYED_LIST [ANY]} a_list.make (0) a_list.extend (Current) a_list.extend (sum) state_manager.save_state (generating_type, "tax", a_list) pension := 0.1 * sum health_insurance := Health insurance premium is coded -- as a constant! Result := pension + health_insurance ensure tax_positive: Result >= 0 tax_less_than_sum: Result <= sum end State saving Routine body

Chair of Software Engineering OOSC - Summer Semester Example – Test case (also written by user) class RECEIVE_SALARY_TC_1 inherit TF_TEST_CASE feature -- Basic operations execute is -- Implementation of the deferred routine from -- class `TF_TEST_CASE'. local an_account: ACCOUNT an_employee: EMPLOYEE do create an_account.make (0) create an_employee.make (an_account, "John Doe", 30) an_employee.receive_salary (100) end Deferred class provided by the testing framework Postcondition of tax violated!

Chair of Software Engineering OOSC - Summer Semester Example – Root class (also written by user) class ROOT_CLASS create make feature -- Initialization make is -- Create and call the test driver. local test_driver: TF_TEST_DRIVER tc1: RECEIVE_SALARY_TC_1 do create test_driver.make create tc1 test_driver.add_test_case (tc1) test_driver.execute end Initiates testing Provided by the testing framework

Chair of Software Engineering OOSC - Summer Semester Example – what the system (testing framework + Spyglass) should do  When the postcondition of routine tax is violated, execution of tests stops and the testing framework:  Displays info regarding the contract violation:  Where it occurred: routine tax of class EMPLOYEE  Type of assertion: postcondition  Tag: tax_less_than_sum  Displays info about location of last performed state saving operation: routine tax of class EMPLOYEE  Calls the Spyglass passing it the last saved state  The Spyglass will display the objects that are passed to it (the object on which tax was called and argument sum ) and will allow navigation of the reference fields of these objects.

Chair of Software Engineering OOSC - Summer Semester Required tasks  Develop:  Object Spyglass  Testing framework  You decide on:  How you display objects in Spyglass  What user preferences regarding the display you store (if any)  How you use these preferences

Chair of Software Engineering OOSC - Summer Semester What you must deliver  Project source code:  ace file + Eiffel classes (.e files)  No compiled code!  No absolute paths in the ace file!  A test suite – a set of test cases that demonstrate the functionality of the system (also only as source code!)  Requirements document  Documentation:  User guide - how to use the tool  Developer guide - description of the architecture, main classes, limitations, how to extend the tool  All documents as pdf’s!

Chair of Software Engineering OOSC - Summer Semester Grading criteria 1.Correctness  Conformance to the specification provided by us  Conformance to the requirements document that you deliver 2.Design  Interfaces between modules  Extendibility  Use of design patterns (if applicable) 3.Quality of contracts 4.Quality of code  Easy to understand  Style guidelines 5.Testing (delivery of a test suite) 6.Documentation  Requirements document  User guide  Developer guide

Chair of Software Engineering OOSC - Summer Semester References  Eiffel  “Object-Oriented Software Construction, 2 nd edition”, Bertrand Meyer  “Eiffel: The Language”, Bertrand Meyer  Writing requirements specifications  IEEE standard: “IEEE Recommended Practice for Software Requirements Specifications” – available on the course web page  Style guidelines  “Object-Oriented Software Construction, 2 nd edition”, Bertrand Meyer (Chapter 26: “A Sense of Style”, pp )

Chair of Software Engineering OOSC - Summer Semester Tools  EiffelStudio 5.5  Free edition available from  Helpful material  Recommendations:  Use the Vision2 library for developing the Object Spyglass  Use class INTERNAL (part of the EiffelBase library) for runtime information about objects  Use class EXCEPTIONS (also part of EiffelBase) for information about assertion violations  An example for drawing in Vision2 provided on the web page (no obligation to use drawing though)  A guided tour of EiffelStudio available on the web page (also in EiffelStudio Help)

Chair of Software Engineering OOSC - Summer Semester End of lecture 10