Final Exam Review About the final exam Comprehensive includes all material Roughly equal weightage to all topics Will be based on material covered in class and textbook especially those in lecture notes ID: 637604
Download Presentation The PPT/PDF document "EECE 310: Software Engineering" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
EECE 310: Software Engineering
Final Exam ReviewSlide2
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 questionsSlide3
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 (
c
hapter 5)
Concurrency
Iteration abstractions (chapter 6)
Types and LSP (chapter 7)
Testing (chapter 10)Slide4
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 reviewSlide5
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 Slide6
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 isolationSlide7
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 Slide8
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 anythingSlide9
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)Slide10
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 proceduresSlide11
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 }Slide12
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 circumstanceSlide13
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)Slide14
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 exercisedSlide15
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.Slide16
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.Slide17
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)Slide18
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 typesSlide19
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 deadlocksSlide20
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 synchronizedSlide21
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 stateSlide22
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)Slide23
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 generatorSlide24
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)Slide25
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)Slide26
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 classSlide27
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 interfaceSlide28
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 22
nd
.Slide29
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 2011Slide30
Requests and Announcements
Teaching evaluations are online
Please take the time to fill them by
Apr
10
th
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