Quiz2 Review

1
Quiz2 Review

• Brandy Leung
• Roshan Gupta
• Godfrey Tan

2
Outline

• Problem Object Models
• Subtyping and Subclassing
• Inheritance and Composition
• Project Management
• Equality
• Dynamic Reasoning
• Design Patterns

3
Problem Object Models
4
Why?

• To model and identify the problems clearly and
  succinctly
  
• One of the most important steps in developing
  software
  

5
POM vs COM

• Problem OM
• NO implementation details indicate WHAT abstract
  data are maintained
  
• Sets reflect the abstract data (say Nodes and
  Edges)
  
• Draw by examining specifications
• Code OM
• Refinement of POM
• Indicate important implementation details about
  HOW you maintain data (like Hashtable, ArrayList,
  )
  
• Draw by examining source code

6
Problem Object Models

• Classify domains
• Boxes to represent sets of items
• Identify relationships
• Field arrows between boxes
• Include multiplicity and modifiability
• Markings on field arrows

7
Problem Object Models
Project
!


Name
!
!
Goals
Members

!
Salary
Short-term
Long-term
Leader
!
8
Subtyping and Subclassing
9
Why?

• Provide an abstraction for a type hierarchy
• Code reuse on both clients and vendors

10
True Subtyping

• Subtypes may have more methods and properties so
  long as they abide by the substitution principle
  
• Substitution principle must hold between two
  types to have a subtype relationship
  
• Hard to enforce behavioral constraints (by
  compilers)
  

11
Substitution priniciple

• Subtype must be substitutable for supertype
• The rep invariants and specification constraints
  of supertype must not be violated by subtype
  
• All the methods and properties of the supertype
  must be present in subtype
  
• Each of those methods in subtype must requires no
  stronger precondition and no weaker postcondition

12
Subclassing in Java

• Pure implementation inheritance
• Code reuse and possible specification reuse
• Clients may not need to change code when new
  subtypes are introduced
  
• Does not worry about the behavioral constraints

13
Potential Problems with Subclassing

• Break encapsulation
• Subtype and supertype may depend on each other
• May lead to abuse sub-classing things that are
  not subtypes
  
• e.g. Stack extends Vector
• Should only be used when a true sub-type
  relationship exists (even so)

14
Inheritance v.s. Composition and Forwarding
15
Why?

• Code reuse
• Modularity

16
Inheritance

• Subclassing using extends
• Powerful way to achieve code reuse
• Java allows one class to inherit another without
  a true subtype relationship between them
  
• Introduces implementation dependencies between
  superclass and subclass and thus, breaks
  encapsulation
  

17
Composition and Forwarding

• Composition and Forwarding
• A class (a wrapper) contains another class
• A class calls methods of the contained class
• No implementation dependencies between the
  container and the contained
  
• Gives programmer more control with method
  dispatching (vs Javas default)
  
• More code, less efficient (added level of
  indirection)
  

18
Example

• class IHashSet extends HashSet
• private int addCount
• public void add(Object o)
• addCount
• super.add(o)
• public void addAll(Collection c)
• addCount c.size()
• super.addAll(c)

19
Example

• class IHashSet extends HashSet
• private int addCount
• // _at_modifies addCount
• public void add(Object o)
• addCount
• super.add(o)

20
Example

• class IHashSet implements Set
• private HashSet s
• private int addCount
• public void add(Object o)
• addCount
• s.add(o)
• public void addAll(Collection c)
• addCount c.size()
• s.addAll(c)

21
When not to use inheritance

• If the subclass is not a true subtype of the
  superclass
  
• If there are implementation dependencies between
  the two classes
  
• Requires code examination (not just specs)

22
Project Management
23
Why?

• To complete projects within two budgets
• Time
• Cost

24
Static components

• Organization
• Centralized (large projects) or decentralized
• Goals
• Prioritized goals for a particular project

25
Decentralized Organization

• Jointly make key decisions
• e.g. spec and Java interfaces
• Checkpoint meetings with a leader and an agenda
• e.g. resolve problems, track progress, code review

26
Models of the process

• Waterfall
• Analyze design implement test produce
• Hacking
• Build modify until satisfied operate
• Prototyping/Incremental
• Iterative process of analyze, design, prototype
  and incremental build

27
Complex projects

• Understand requirements/design thoroughly
• Hard to know them initially
• Catch mistakes early on
• Costly to discover later
• Need a model to reduce risk

28
Prototype

• To answer questions
• Requirements, design, implementation, testing
• To get feedback
• Find gotchas
• To throw away
• Pitfalls wasted work failure to discard second
  system effect

29
Incremental Model

• Design
• Implement
• Validate (Unit Test and Integration)
• Assess risk (schedule)
• Go back to 1
• Start with depth-first implementation of basic
  functionalities, then add more complex ones
  incrementally

30
Pluses and Minuses

• Feedback
• Easier to measure progress reality check
• Modular design changes and validation easier
• Better customer-vendor relationship
• Shared problem solving and less adversarial
• Pitfalls executives and customers must pay
  attention throughout the project lifetime

31
(No Transcript)
32
Why scheduling is hard?

• Estimates
• Too optimistic
• Progress
• Poorly monitored
• Slippage
• Not aggressively treated

33
Controlling Schedule

• Need verifiable milestones
• To monitor progress
• e.g. modules finished not 90 done
• Need critical path chart
• To know the effects of slippage
• Hold people accountable

34
When schedule slips

• Add people (hardly works)
• Buy components (not always possible)
• Change deliverables
• Cut features
• Change schedule
• Sorry, it will be released next quarter

35
Implementation/Testing

• Bottom-up
• Implement the bottom-most modules of the MDD
  first
  
• Test stand-alone and integrate bottom-up
• Top-down
• Implement the top-most modules first
• Build stubs to simulate the depending ones

36
Equality
37
Notions of Equivalence

• Behaviorally Equivalent
• If there is no sequence of (mutative) operations
  that can distinguish them
  
• Observationally Equivalent (similar)
• If no difference can be observed through observer
  operations
  

38
Equivalence Can Be Subtle

• List table1 new Vector()
• List table2 new Vector()
• // Key list of people in table, Value true if
  table is full
  
• Hashtable seatingChart new Hashtable()
• seatingChart.put(table1, new Boolean(false))
• seatingChart.put(table2, new Boolean(false))
• table1.add(Curly)
• table2.add(Shemp)
• System.out.println(seatingChart.size()) //
  Prints 1!

39
Behaviorally Equivalent equals

• Mutable types
• Can only be equals to itself
• StringBuffer s new StringBuffer(thing)
• StringBuffer t new StringBuffer(thing)
• s.equals(t) ?
• Immutable types
• If all the fields in both objects are equals
• String a thing String b thing
• a.equals(b) ?

40
Observationally Equivalent similar

• Mutable types
• If all the fields in both objects are similar
• StringBuffer s new StringBuffer(thing)
• StringBuffer t new StringBuffer(thing)
• s.similar(t) ?
• Immutable types
• If all the fields in both objects are similar
• String a thing String b thing
• a.similar(b) ?

41
Remember!

• a.equals(b) ?
• a.hashCode() b.hashCode()
• This must be satisfied even when all the fields
  are primitive types

42
Dynamic Reasoning
43
Weakest Precondition

• For each statement S with pre-assertion P
• Assume post-assertion Q is true
• (Substitute S in Q) wp(S,Q)
• Check P ? wp(S,Q)
• If false, we have trouble!
• Example
• Pre-assertion P y 0
• Code S x y 1
• Post-assertion Q x 1

44
Weakest Precondition cases

• wp(S, Q) S Q
• Assignment wp(x e, Q) Q with all (free)
  occurrences of x replaced by e
  
• Composition wp(S1 S2, Q) wp(S1, wp(S2, Q))
• If wp(if b S1 else S2, Q) b ? wp(S1, Q) b ?
  wp(S2, Q)

45
Example

• wp(z y4 x y, x 0)
• By composition
• wp(z y4, wp(x y1, x 0))
• By assignment
• wp(z y4, y 0)
• z 4

46
Loops P while b S Q

• Unrolled-loop analysis hard
• Solution find a loop invariant I s.t.
• Base Case P ? I
• For each iteration where b is true
• after b and S executed, I still holds
• When b is false, loop terminates
• I still true and Q is true
• Total correctness decrementing function to prove
  loop termination
  

47
Loops

• Find invariant, I
• P ? I
• I b S I
• (I b) ? Q
• Decrementing function, D(X), where X is some
  subset of state, such that
  
• I b S D(X)
• (I D(X) minVal) ? b

48
Example

• // remove all elements in the list equal
• // to the first element
• int i 1
• while(i
• if( list.get(i).equals(list.get(0)) )
• list.remove(i)
• else
• i
• What is the loop invariant?
• What is the deprecating function?

49
Example

• // remove all elements in the list equal
• // to the first element
• int i 1
• while(i
• if( list.get(i).equals(list.get(0)) )
• list.remove(i)
• else
• i
• What is the loop invariant?
• for all 0 list 0
  
• What is the deprecating function?
• list.size() - i

50
Design Patterns
51
Design Patterns

• So far
• Encapsulation (data hiding)
• Subclassing (inheritance)
• Iteration
• Exceptions
• Dont use design patterns prematurely
• Complex, decrease understandability

52
Design PatternsCreational Patterns

• Factories
• Factory method method that manufactures an
  object of a particular type
  
• Factory object object that encapsulates factory
  methods
  
• Prototype object can clone() itself, object is
  passed in to a method (instead of a factory
  object)

53
Design PatternsCreational Patterns

• class Race
• BicycleFactory bfactory
• // constructor
• Race()
• bfactory new BicycleFactory()
• Race createRace()
• Bicycle bike1 bfactory.completeBicycle()
• Bicycle bike2 bfactory.completeBicycle()
• ...

54
Design PatternsCreational Patterns

• class TourDeFrance extends Race
• // constructor
• TourDeFrance()
• bfactory new RacingBicycleFactory()
• class Cyclocross extends Race
• // constructor
• Cyclocross()
• bfactory new MountainBicycleFactory()

55
Design PatternsCreational Patterns

• Sharing
• Singleton only one object of a class exists
• Interning reuses object instead of creating new
  ones correct for immutable objects only
  
• Flyweight (generalization of interning), can be
  used if most of the object is immutable

56
Design PatternsBehavioral Patterns

• Procedures as objects
• Strategy pattern context has expectation of what
  the procedure will do (Comparator)
  
• Command pattern no expectation about the
  behavior of a procedure (Runnable)

57
Design PatternsBehavioral Patterns

• Multi-way Communication
• Observer maintain a list of observers (that
  follow a particular interface) to be notified
  when state changes needs add and remove observer
  methods
• Blackboard (generalizes Observer pattern)
  multiple data sources and multiple viewers
  asynchronous
  
• Mediator (intermediate between Observer and
  Blackboard) decouples information, but not
  control, synchronous

58
Design PatternsTraversing Composites

• Support many different operations
• Perform operations on subparts of a composite
• Interpreter groups together operations for a
  particular type of object
  
• Procedural groups together all code that
  implements a particular operation
  
• Visitor depth-first traversal over a
  hierarchical structure Nodes accept Visitors
  Visitors visit Nodes

59
Design PatternsVisitor

• public class Visitor
• void visit(Node n) //do work on n
• public class Node
• public void accept (Visitor v)
• //for any children or members of this
• child.accept(v)
• v.visit(this)

60
Design PatternsStructural Patterns

• Wrappers
• Pattern Functionality Interface
• Adaptor Same Different
• (incompatibility)
• Decorator Different Same
• (extends)
• Proxy Same Same
• (controls or limits)

61
Design PatternsStructural Patterns

• Implementation of Wrappers
• Subclassing
• Delegation stores an object in a field
  preferred implementation for wrappers
  
• Composite
• Allows client to manipulate a unit or collection
  of units in the same way