EECE 309 Software Engineering Final Exam Review Final

EECE 309: Software Engineering Final Exam Review

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)

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

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 • 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. , Null. Pointer. Exception • Always make your exception checked unless it is truly a rare or unexpected circumstance

Exception Abstraction - 3 • Exception is thrown where error happens throw new Some. Exception(“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(Exception. Name e) { // take some action with e }

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

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 expose the rep – 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

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

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

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

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 – has. Next: 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 the overriden method may throw FEWER exceptions. This is statically checked by compiler. – Methods rule: The over-ridden methods of the subclass 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 baseclass’s specifications or by introducing an abstract class or interface as the base class

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

The Road Ahead • Other S/W engg. courses – – – EECE 415: Requirements Engg. EECE 443: Project Mgt. EECE 416: Testing EECE 417: Architecture EECE 419: 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 before Dec 2 nd – 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