EECE 310: Software Engineering

1. EECE 310: Software Engineering Final Exam Review

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

22. 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 iteratorinterface and stores the state of the iteration in its rep, so it has its own RI and AF (distinct from ADT)

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

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

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

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

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

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

29. The Road Ahead • Other S/Wengg. 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

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