1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.

Slides:



Advertisements
Similar presentations
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Design By Contract Using JMSAssert.
Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy Eivind J. Nordby.
Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
Reasoning About Code; Hoare Logic, continued
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.
CS 355 – Programming Languages
Feb 2003 R McFadyen1 Contracts (Ch 13) Used to help understand requirements more completely based on assertions; assertions are applicable to any.
Object Design: Specifying Interfaces Chapter 9. 2 Object Design  Object design is the process of adding details to the requirements analysis and making.
Formal Methods of Systems Specification Logical Specification of Hard- and Software Prof. Dr. Holger Schlingloff Institut für Informatik der.
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Copyright W. Howden1 Lecture 13: Programming by Contract.
Static and Dynamic Contract Verifiers For Java Hongming Liu.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Describing Syntax and Semantics
Object Specification Moving towards a more precise specification of software.
Component-Based Software Engineering Components and Interfaces Paul Krause.
Ranga Rodrigo. Class is central to object oriented programming.
Computer Science School of Computing Clemson University Discrete Math and Reasoning about Software Correctness Murali Sitaraman
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
Abstract Data Types (ADTs) and data structures: terminology and definitions A type is a collection of values. For example, the boolean type consists of.
More with Methods (parameters, reference vs. value, array processing) Corresponds with Chapters 5 and 6.
Lecture 17 March 24, 2011 Formal Methods 2 CS 315 Spring Adapted from slides provided by Jason Hallstrom and Murali Sitaraman (Clemson)
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
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.
OOSC - JMSAssert. Design By Contract A powerful technique for writing reliable software. Specifying the software purpose with the implementation. Key.
Chapter 5: Sequences, Mathematical Induction, and Recursion 5.5 Application: Correctness of Algorithms 1 [P]rogramming reliability – must be an activity.
Reasoning about programs March CSE 403, Winter 2011, Brun.
© 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.
Protocols Software Engineering II Wirfs Brock et al, Designing Object-Oriented Software, Prentice Hall, Mitchell, R., and McKim, Design by Contract,
Computer Science 209 Software Development Handing Errors and Creating Documentation.
Class Design I Class Contracts Readings: 2 nd Ed: Section 9.5, Advanced Topic nd Ed: Section 8.5, Advanced Topic 8.2 Some ideas come from: “Practical.
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.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Loop Invariants and Binary Search Chapter 4.4, 5.1.
CEN th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi Object Design: Specifying.
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
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.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Winter 2006CISC121 - Prof. McLeod1 Stuff Midterm exam in JEF234 on March 9th from 7- 9pm.
Sections 3.4 Formal Specification
Class Invariants Class invariants are logical conditions to ensure the correct working of a class. Class invariants must hold true when an object is created,
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Used to help understand requirements more completely
GC211Data Structure Lecture2 Sara Alhajjam.
Software Development Handing Errors and Creating Documentation
Formal Specification of Java Interfaces
Reasoning about code CSE 331 University of Washington.
The Object Constraint Language
Structural testing, Path Testing
Specifying Object Interfaces
Introduction to Data Structures
Programming Languages 2nd edition Tucker and Noonan
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,
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
CSE 1020:Software Development
Object Constraint Language (OCL)
Programming Languages 2nd edition Tucker and Noonan
A type is a collection of values
Presentation transcript:

1 Specifying Object Interfaces

2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface simple? * what operations are public/private/protected? * what are input parameters of each operation? * what is the return type of each operation? --what “contracts” are there? (pre and post conditions, e.g.)

3 Developers participating in class specification: * implementer—designs internal data structures and code for the class * user—will use the class as an application—must know boundary (interface specification) for the client class they are developing * extender—develops specialized version of the class— interface specifications provide constraints to this developer

4 Preconditions, postconditions, invariants “contracts”: useful in white box and black box testing, include preconditions, postconditions, and invariants (loop or class, e.g.). Example: how do you ensure --there is no division by zero? --array bounds are not exceeded? --I/O error does not cause system crash? --faulty / missing component does not cause system crash? Also important in formal methods specifications

5 Preconditions, postconditions, invariants--definitions precondition: logical condition that a caller of an operation guarantees before making the call postcondition: logical condition that an operation guarantees upon completion invariant: logical condition that is preserved by transformations example: loop invariant is preserved by the transformations effected by the loop instructions

6 Example--stacks, queues, division example: what would be preconditions for common stack operations? What would be postconditions? Push: Pop: Isempty?: Top: what about a queue? What about division? (precondition; postcondition—e.g., type)

7 Loop invariant example: does this program compute a n for n > 0? Algorithm strategy? float pow(float a, int n) { float r = 1; while (n > 0) {{if (n%2 == 0) {a = a*a;n=n/2;} else {r=r*a; n=n-1;} } return r; } "proof" using an invariant that this program is correct: let a in, n in be inputs; invariant: r x a n = a in ** n in proof:1. Invariant holds before entering loop first time 2. Invariant holds after iteration i if it held at iteration i-1 3. So, by induction, invariant is true for n > 0 3. Now, if loop terminates, n = 0, so we program does compute a n

8 Other invariants example: class invariant is preserved by all class operations e.g., the size of an array is always >= 0 interface invariants: for public sections (users) implementation invariants: for class implementations (designers, coders)

9 Invariants--examples example: suppose we have a bounded stack of floating point numbers interface invariant: after a push, the stack is no longer empty s.push(x) => not (s.empty) if the stack is not full and we push an element on the stack, then calling pop returns that element: not(s.full) and s.push(x); y=s.pop => x = y these make no reference to the particular implementation

10 Invariants--examples (cont.) Implementation invariant: example: if we implement the stack as a bounded array then an invariant is that the stack pointer is within the array bounds using invariants in program: c++: assert c++, java: error checking--(e.g., try, catch) note: including checking increases program length, decreases efficiency

11 Expressing constraints: Can use natural language or a special language such as OCL (Object Constraint Language) Constraint is a boolean expression, returns value true or false Constraint can be: --attached to an entry in the CRC card if desired (example: figure 9.4)—leads to cluttered documents --specified by keyword context

12 Examples from text (this form or syntax in figure 9-5, page 360 should be used in object comments in project): context Tournament inv: self.getMaxNumPlayers( ) > 0 context Tournament::acceptPlayer(p:Player) pre: !is PlayerAccepted(p) context Tournament::acceptPlayer(p:Player) pre: getNumPlayers( ) < getmaxNumPlayers( ) context Tournament::acceptPlayer(p:Player) post: isPlayerAccepted(p)

13 Useful OCL syntax: Collections of objects: distinguishes among sets, sequences, bags --set: for a single association --sequence: used for navigating a single ordered association --bag: may contain the same object multiple times (differs from set) Useful operations on collections: Size includes(object)—member select(expression)—members which satisfy given condition union(collection) interstction(collection) asSet(collection)—returns the set of members of the collection Quantifiers: forAll; exists We will revisit these concepts when we discuss formal methods

14 Object design—steps: ---Identify missing attributes and operations ---specify types, signatures (e.g. is a collection ordered or not?), and visibility of each attribute and operation --specify pre and post conditions --specify invariants --note any inherited contracts --document the process in the Object Design Document --assign development responsibilities to developer team