EECE 310: Software Engineering Final Exam Review.

Slides:



Advertisements
Similar presentations
Exceptions CSE301 University of Sunderland Harry Erwin, PhD.
Advertisements

Identity and Equality Based on material by Michael Ernst, University of Washington.
CS0007: Introduction to Computer Programming Introduction to Classes and Objects.
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 6: Reasoning about Data Abstractions.
Written by: Dr. JJ Shepherd
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Exception Handling Chapter 15 2 What You Will Learn Use try, throw, catch to watch for indicate exceptions handle How to process exceptions and failures.
Exceptions and Exception Handling Carl Alphonce CSE116 March 9, 2007.
Chapter 8Java: an Introduction to Computer Science & Programming - Walter Savitch 1 Chapter 8 l Basic Exception Handling »the mechanics of exceptions l.
1 Software Engineering Lecture 11 Software Testing.
Defining classes and methods Recitation – 09/(25,26)/2008 CS 180 Department of Computer Science, Purdue University.
Chapter 8 Exceptions. Topics Errors and Exceptions try-catch throwing Exceptions Exception propagation Assertions.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Chapter 10 Classes Continued
COMP 321: Introduction to Computer Systems Scott Rixner Alan L. Cox
Exception Handling 1. Introduction Users may use our programs in an unexpected ways. Due to design errors or coding errors, our programs may fail in unexpected.
COSC 1P03 Data Structures and Abstraction 4.1 Abstract Data Types The advantage of a bad memory is that one enjoys several times the same good things for.
EECE 310: Software Engineering Exception handling and Testing.
CSCA48 Course Summary.
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION MIDTERM REVIEW Autumn 2011.
EECE 310: Software Engineering Iteration Abstraction.
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
Java Software Solutions Lewis and Loftus Chapter 14 1 Copyright 1997 by John Lewis and William Loftus. All rights reserved. Advanced Flow of Control --
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Software Testing Reference: Software Engineering, Ian Sommerville, 6 th edition, Chapter 20.
Exception Handling Unit-6. Introduction An exception is a problem that arises during the execution of a program. An exception can occur for many different.
Exceptions in Java. Exceptions An exception is an object describing an unusual or erroneous situation Exceptions are thrown by a program, and may be caught.
(1) Unit Testing and Test Planning CS2110: SW Development Methods These slides design for use in lab. They supplement more complete slides used in lecture.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Computer Programming with JAVA Chapter 8. Exception Handling Basic Exception Handling the mechanics of exceptions Defining and Using Exceptions some "simple"
Data Abstractions EECE 310: Software Engineering.
Comp 249 Programming Methodology Chapter 15 Linked Data Structure – Part A Dr. Aiman Hanna Department of Computer Science & Software Engineering Concordia.
90-723: Data Structures and Algorithms for Information Processing Copyright © 1999, Carnegie Mellon. All Rights Reserved. 1 Lecture 1: Introduction Data.
Concurrency Properties. Correctness In sequential programs, rerunning a program with the same input will always give the same result, so it makes sense.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Exception Handling in Java Topics: Introduction Errors and Error handling Exceptions Types of Exceptions Coding Exceptions Summary.
Chapter 1 Data Abstraction: The Walls CS Data Structures Mehmet H Gunes Modified from authors’ slides.
CSE 143 Lecture 4 More ArrayIntList : Pre/postconditions; exceptions; testing reading: slides created by Marty Stepp and Hélène Martin
PROGRAMMING TESTING B MODULE 2: SOFTWARE SYSTEMS 22 NOVEMBER 2013.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Programming & Debugging. Key Programming Issues Modularity Modifiability Ease of Use Fail-safe programming Style Debugging.
Written by: Dr. JJ Shepherd
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
1 C# - Inheritance and Polymorphism. 2 1.Inheritance 2.Implementing Inheritance in C# 3.Constructor calls in Inheritance 4.Protected Access Modifier 5.The.
Exceptions Lecture 11 COMP 401, Fall /25/2014.
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.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 10: Programming Exceptionally.
Effective Java, Chapter 9: Exceptions Items Last modified Fall 2012 Paul Ammann.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
CPSC 252 ADTs and C++ Classes Page 1 Abstract data types (ADTs) An abstract data type is a user-defined data type that has: private data hidden inside.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Modular Decomposition, Abstraction and Specifications
Eighth Lecture Exception Handling in Java
EECE 310: Software Engineering
EECE 309: Software Engineering
Tirgul 13 Exceptions 1.
Exception Handling Chapter 9.
Introduction to Data Structures
Effective Java, 3rd Edition Chapter 10: Exceptions
619 Final Review Last updated Spring 2010 © : Paul Ammann.
Data Structures and Algorithms for Information Processing
IMPORTANT NOTE Some parts of these section slides deal with null ints. This was a mistake, as primitives cannot be null. These issues have been corrected.
Effective Java, Chapter 9: Exceptions
Computer Science 340 Software Design & Testing
Software Specifications
Presentation transcript:

EECE 310: Software Engineering Final Exam Review

About the final exam Comprehensive – includes all material – Roughly equal weight-age to all topics Will be based on material covered in class and textbook (especially those in lecture notes) Closed book, closed notes – Approximately 2.5 hours long 6-7 questions

Final Exam Syllabus All lectures in class except the one on JML All topics covered in class & the textbook – Objects in Java (chapter 2) – Procedural abstractions (chapter 3) – Exceptions (chapter 4) – Data abstractions (chapter 5) – Concurrency – Iteration abstractions (chapter 6) – Types and LSP (chapter 7) – Testing (chapter 10)

What will we cover this class ? Quick overview of each topic – 2-3 slides per topic + common mistakes/gotchas I will answer questions on each topic during the session. Do not wait to ask questions at the end. The exam may test you on material that is not covered in this class (so read the whole notes) – However, we will touch upon all topics in the review

Note I will not answer questions of the form “Will this be on the final ?” or “how much weight age will be given to this particular topic ?” I will answer questions of the form “How do you do X ? “, “What does Y mean ?”, or “How do I use Z in this context ?” etc. You are expected to participate and ask questions

Abstraction Abstraction: Hiding of irrelevant details Two kinds of abstraction – By parameterization – By specification Two benefits of abstraction – Locality: Understand code in isolation – Modifiability: Modify code in isolation

Objects in Java Understand what passing by reference Vs. passing by value means Mutable and Immutable objects in Java Type Checking – Apparent and actual types – Implicit type conversions

Procedural Abstraction - 1 REQUIRES clause: Pre-condition – Only what is absolutely needed for correctness – NOT to be specified if you check for the condition or throw an exception (move to EFFECTS clause) MODIFIES clause: – Specifies anything the procedure can possibly modify, not only the ones it absolutely does – Can be omitted if the proc. doesn’t modify anything

Procedural Abstraction - 2 EFFECTS clause: Post-condition – Absolutely required for every procedure – Document all the behaviors, including exceptions – High-level specification of behaviors, not details – Only need to handle cases NOT in pre-condition Specs must be clear, full, and minimally constraining (as far as possible)

Exception Abstractions - 1 Exceptions must be specified in the procedure’s header (even if unchecked) Exceptions must also be specified in the EFFECTS clause even if they are unchecked Do NOT include exception conditions in the REQUIRES clauses of procedures

Exception Abstraction - 2 Exception is thrown where error happens throw new SomeException(“error message”); Exception may be propagated by the method if it has declared it in its header and it is a checked exception or if it is an unchecked exception and it is not caught Exception may be handled in some other method up the call-stack using catch catch(ExceptionName e) { // take some action with e }

Exception Abstraction - 3 Two kinds of exceptions – Checked: Must be handled by calling procedure (or propagated) e.g., IOException – Unchecked: Need not always be handled especially if calling code is confident that the exceptional situation never arises e.g., NullPointerException Always make your exception checked unless it is truly a rare or unexpected circumstance

Testing 1 Black-box tests: Written without knowledge of source code (based on spec alone) – Paths through the spec (all cases in the spec are covered for EFFECTS clause) – Boundary conditions, aliasing errors – Test for invalid inputs (i.e., violate REQUIRES clause – the program should degrade gracefully)

Testing - 2 Glass Box Tests: Use knowledge of code to come up with test-cases – For each loop in the program, make sure you traverse the loop 0, 1 and 2 times. For each such traversal, you need to ensure that every path in the loop body is covered (at least once) – For every statement where an exception may be raised, create a test case to raise it – For non-loop statements, every path in the procedure must be exercised

Data Abstraction - 1 Abstract Data Type (ADT) – Has an overview of what it is or does at the top – Has one or more constructors – Provides operations for common tasks (both mutators and observers) – Has one or more producer methods Rep refers to the implementation. Abstraction refers to the data type.

Data abstraction - 2 Rep Invariant: All the constraints that must be preserved by the representation, no matter how trivial, and are not obvious in declaration – Must be satisfied by every method both before and after its execution (but not necessarily during its execution) – Need to specify it in a semi-formal manner using & or | Abstraction function: Maps the representation to the abstraction exposed by the ADT – Many to one mapping defined for legal representations – Write it as a function AF(c) = … for every … in the rep.

Data abstraction - 3 Writing proofs for RI satisfaction – Number each clause in RI if conjunction of clauses – Show that constructor establishes each clause – Show that if the clause is satisfied prior to method’s execution, then it must be satisfied after its execution Writing proofs for AF correctness – Assume RI holds (if you haven’t proved it yet) – For each method, show that if the rep satisfies the pre-abstraction prior to its execution, then it satisfies the post-abstraction after its execution (using the AF)

Data abstraction - 4 Never ever expose the rep – Watch out for inadverent ways such as initializing from other objects or returning a reference to rep Immutability of abstraction need not imply immutability of the representation – Immutable abstraction possible with mutable rep Equality only needs to be for immutable types

Concurrency - 1 Threads in Java – Each run with an independent stack and PC – Communicate through a shared heap – Files, I/O etc. are shared Threads need to synchronize access to shared data – otherwise, can have race conditions. Too much synchronization leads to deadlocks

Concurrency - 2 Synchronized methods in Java  Only one thread can be inside a set of synchronized methods in an object at any time When should you make method synchronized – Modifies a shared field of the object – Reads shared fields multiple times and uses them – Breaks the rep invariant if not synchronized

Concurrency - 3 Fine grained synchronization can avoid performance problems of coarse-grained – Synchronize on smaller blocks of code – Synchronize on custom objects – Remember mapping from locks to objects Better to avoid synchronization if possible – Use immutable objects and copy mutable state

Iteration abstraction - 1 Iteration abstraction: A general-purpose way to access the elements of a container ADT without coupling it with the action performed To implement iterators, you need two things: – An iterator method that initializes the iteration and returns a generator object for performing iteration – A generator object implements the Java iterator interface and stores the state of the iteration in its rep, so it has its own RI and AF (distinct from ADT)

Iteration abstraction - 2 Nest the generator class within the ADT but make it private or protected to the ADT (so that the only way to create it is from the ADT’s iterator method) ADT passes itself to the generator object at the time of generator’s creation (for initialization in constructor) Generator must at least implement the following – next: returns the current object and advances the state of the iteration to the next object – hasNext: returns true if next object present, false o/wise. Does not change externally visible state of the generator

Iteration abstraction - 3 Iterator method specifications (part of ADT) – Pre-REQUIRES: Written before EFFECTS and reflects constraints on its arguments (just as before) – EFFECTS clause: What the iterator does. Typically returns a generator object that performs iteration – Post-REQUIRES: Written after the EFFECTS and reflects constraints on use of the generator object (typically that the ADT is not modified during iteration) – May optionally take in additional arguments to initialize generator (E.g., criteria for choosing objects)

Sub-typing -1 LSP must be followed by any valid sub-type -> can substitute sub-type in place of the parent type – Signature rule: Method signatures match exactly, except that over-riden method may throw FEWER exceptions. This is statically checked by compiler. – Methods rule: The over-ridden methods of the sub- class must do MORE (stronger post-condition) AND require LESS (weaker pre-condition) – Properties rule: All methods of the sub-type (not just the overriden ones) must ensure preservation of the parent type’s properties (evolution and invariant)

Sub-typing - 2 To check if LSP is satisfied, need to show that each of the rules is satisfied by all methods OR point out all violations of the LSP by methods LSP is based on the ADT’s specifications only Can be fixed by changing either the base- class’s specifications or by introducing an abstract class or interface as the base class

Sub-typing - 3 Sub-types can be tricky to get correct – Not easy to define sub-types without violating LSP – Even if LSP is not violated, they can lead to subtle problems (E.g., InstrumentedIntSet) Moral: Favor composition over inheritance – Create a wrapper around the class and add new functionality to the methods – Make them implement a common interface

Some final thoughts …. Prepare well for the exam – understand the concepts, solve in-class exercises, quizzes etc. Come to office hours if necessary. – Will post sample exam to the website next week as a guideline (but do not rely exclusively on this) Post questions to Piazza – I will answer questions during exam period until Apr 22 nd.

The Road Ahead Other S/W engg. courses – EECE415: Requirements Engg. – EECE443: Project Mgt. – EECE416: Testing – EECE417: Architecture – EECE419: Project Other Comp. Eng. courses – EECE 411: Distributed Systems – EECE 494: Real-time Systems – EECE 412: Computer security Rated No. 1 career by Wall Street Journal in 2011

Requests and Announcements Teaching evaluations are online – Please take the time to fill them by Apr 10 th – Tell me what you liked or didn’t like – can benefit future generations of students who take EECE 310. I’m looking for 496 project participants – Look at my webpage and send me your resume and transcripts if you are interested and eligible