EECE 310: Software Engineering - PowerPoint Presentation

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