eece 310 software engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
EECE 310: Software Engineering PowerPoint Presentation
Download Presentation
EECE 310: Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 30

EECE 310: Software Engineering - PowerPoint PPT Presentation


  • 76 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'EECE 310: Software Engineering' - pascha


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
about the final exam
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
final exam syllabus
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)
what will we cover this class
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
slide5
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
abstraction
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
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
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
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
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
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 }

exception abstraction 3
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
testing 1
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
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
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.
data abstraction 2
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
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
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
concurrency 1
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
concurrency 2
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
concurrency 3
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 - 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)
iteration abstraction 2
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
iteration abstraction 3
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
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)
sub typing 2
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
sub typing 3
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
some final thoughts
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.
the road ahead
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
requests and announcements
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