eece 310: software engineering

Download EECE 310: Software Engineering

Post on 24-Feb-2016




0 download

Embed Size (px)


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 - PowerPoint PPT Presentation


EECE 310: Software Engineering

EECE 310: Software EngineeringFinal Exam ReviewAbout the final examComprehensive includes all materialRoughly equal weight-age to all topics

Will be based on material covered in class and textbook (especially those in lecture notes)

Closed book, closed notesApproximately 2.5 hours long 6-7 questionsFinal Exam SyllabusAll lectures in class except the one on JML

All topics covered in class & the textbookObjects in Java (chapter 2)Procedural abstractions (chapter 3)Exceptions (chapter 4)Data abstractions (chapter 5)ConcurrencyIteration abstractions (chapter 6)Types and LSP (chapter 7)Testing (chapter 10)What will we cover this class ?Quick overview of each topic2-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

NoteI 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 AbstractionAbstraction: Hiding of irrelevant details

Two kinds of abstractionBy parameterizationBy specification

Two benefits of abstractionLocality: Understand code in isolationModifiability: Modify code in isolationObjects in JavaUnderstand what passing by reference Vs. passing by value means

Mutable and Immutable objects in Java

Type CheckingApparent and actual typesImplicit type conversions

Procedural Abstraction - 1REQUIRES clause: Pre-conditionOnly what is absolutely needed for correctnessNOT 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 doesCan be omitted if the proc. doesnt modify anythingProcedural Abstraction - 2EFFECTS clause: Post-conditionAbsolutely required for every procedureDocument all the behaviors, including exceptionsHigh-level specification of behaviors, not detailsOnly need to handle cases NOT in pre-condition

Specs must be clear, full, and minimally constraining (as far as possible)Exception Abstractions - 1Exceptions must be specified in the procedures 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 proceduresException Abstraction - 2Exception 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 - 3Two kinds of exceptionsChecked: Must be handled by calling procedure (or propagated) e.g., IOExceptionUnchecked: Need not always be handled especially if calling code is confident that the exceptional situation never arises e.g., NullPointerExceptionAlways make your exception checked unless it is truly a rare or unexpected circumstanceTesting 1Black-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 - 2Glass Box Tests: Use knowledge of code to come up with test-casesFor 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 itFor non-loop statements, every path in the procedure must be exercisedData Abstraction - 1Abstract Data Type (ADT)Has an overview of what it is or does at the topHas one or more constructorsProvides 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 - 2Rep Invariant: All the constraints that must be preserved by the representation, no matter how trivial, and are not obvious in declarationMust 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 ADTMany to one mapping defined for legal representationsWrite it as a function AF(c) = for every in the rep.

Data abstraction - 3Writing proofs for RI satisfactionNumber each clause in RI if conjunction of clausesShow that constructor establishes each clauseShow that if the clause is satisfied prior to methods execution, then it must be satisfied after its execution

Writing proofs for AF correctnessAssume RI holds (if you havent 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 - 4Never ever expose the repWatch 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 representationImmutable abstraction possible with mutable rep

Equality only needs to be for immutable types

Concurrency - 1Threads in JavaEach run with an independent stack and PCCommunicate through a shared heapFiles, I/O etc. are shared

Threads need to synchronize access to shared data otherwise, can have race conditions. Too much synchronization leads to deadlocksConcurrency - 2Synchronized 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 synchronizedModifies a shared field of the objectReads shared fields multiple times and uses themBreaks the rep invariant if not synchronizedConcurrency - 3Fine grained synchronization can avoid performance problems of coarse-grainedSynchronize on smaller blocks of code Synchronize on custom objectsRemember mapping from locks to objects

Better to avoid synchronization if possibleUse immutable objects and copy mutable stateIteration abstraction - 1Iteration 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 iterationA 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 - 2Nest 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 ADTs iterator method)

ADT passes itself to the generator object at the time of generators creation (for initialization in constructor)

Generator must at least implement the followingnext: returns the current object and advances the state of the iteration to the next objecthasNext: returns true if next object present, false o/wise. Does not change externally visible state of the generatorIteration abstraction - 3Iterator 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 iterationPost-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 -1LSP must be followed by any valid sub-type -> can substitute sub-type in place of the parent typeSignature 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 types properties (evolution and invariant)Sub-typing - 2To 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 ADTs specifications only

Can be fixed by changing either the base-classs specifications or by introducing an abstract class or interface as the base class

Sub-typing - 3Sub-types can be tricky to get correctNot easy to define sub-types without violating LSPEven if LSP is not violated, they can lead to subtle problems (E.g., InstrumentedIntSet)

Moral: Favor composition over inheritanceCreate a wrapper around the class and add new functionality to the methodsMake them implement a common interfaceSome 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