1. EECE 309: Software Engineering
Final Exam Review

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

3. 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

4. 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

5. 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

6. 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

7. 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)

8. 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

9. Exception Abstraction - 2
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

10. Exception Abstraction - 3
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 }

11. 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)

12. 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

13. Data Abstraction - 1 Abstract Data Type (ADT)
Has an overview of what it is or does
Has one or more constructors
Provides operations for common tasks (both mutators and observers)
Has one or more producer methods
NOTE: Method Specifications should only describe the external view of the ADT

14. 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.

15. 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)

16. Data abstraction - 4 Never ever expose the rep Immutable abstractions
Watch out for inadvertent ways such as initializing from other objects or returning a reference to rep
Immutable abstractions
Do not modify the externally visible ADT state
Immutable abstraction possible with mutable rep
Immutable abstraction useful for concurrency

17. 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 should synchronize accesses to shared data – otherwise, race conditions

18. Concurrency - 2
Synchronized methods in Java  Only one thread can be inside a set of synchronized methods in an object instance 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

19. 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

20. Iteration abstraction - 1
Iteration abstraction: A general-purpose way to access the elements of a container ADT without coupling it with the action performed (e.g., print)
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 that implements the Java iterator interface and stores the current state of the iteration

21. 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

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

23. 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 the overriden 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)

24. 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

25. Some final thoughts ….
Prepare well for the exam – understand the concepts, solve in-class exercises, quizzes etc. Try the sample exam before looking at the solutions (and coming to the discussion)
Post questions to Piazza – I will answer questions during exam period until Dec 10th.

26. The Road Ahead Other S/W engg. courses Other Comp. Eng. 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

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