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 22nd.

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 10th

– 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