Chapters 4

1
Chapters 45 Design PrinciplesCorrectness,
Robustness, Flexibility, Reusability, and
Efficiency
2
Correctness and Sufficiency

• Goal
• That each artifact satisfies designated
  requirements, and that together they satisfy all
  of the applications requirements.
• Approaches to correctness
• Informal approaches
• Formal approaches

3
Sufficient Designs
A design sufficient to implement the requirements.
Also called
a correct design
It follows that
the design must be entirely understandable
A common way to achieve this is to make
the design very modular
4
Formal approaches to correctness

• Invariants
• Unchanging relationships among variables
• Class invariants
• Keep objects in correct states
• Make attributes private so no one can change the
  state of an object directly.
• Encapsulate private attributes with operations
• Operations act as guards keep the object in a
  correct state
• Operations throw exceptions when a request may
  put the object into a wrong state

5
Invariants for Class Automobile

• mileage gt 0
• mileage lt 1000000
• vehicleID has at least 8 characters
• value gt -300 (300 is the disposal cost of a
  worthless automobile)
• originalPrice gt 0
• ( type REGULAR value lt originalPrice )
• ( type VINTAGE value gt originalPrice
  )

6
Introducing Interfaces

• The interface of a module defines the uses of the
  module.
• Interface to classes
• It is often beneficial to group them into several
  interfaces when a class supports many methods
• The interface segregation principle
• Interface to packages
• Group the functions of the package into
  interfaces
• Use a designated object to provide the interfaces

7
Interface to classes
Dimensions getWidth() getLength() getWeight()
TranspMeans getDuration() setVehicle() printRoute(
)
GoodsType getType() setType() perishable()
Original form
Shipment setVehicle() perishable() getWidth() prin
tRoute() getType() getLength() getDuration() setTy
pe()
Shipment
Dimensions
Shipment
TranspMeans
GoodsType
8
Package interfaces
purchases
Pricing
Furniture
singleton PurchasesIF
Clothing
Selection
Appliance
ClothingTryout
9
Example of package interfaces
billing
Financial
chatServer
Accounting
Bill
Conversation
Conversation- services
chatClient
ConversationManager
Participant- services
Display
ServerComm
ClientComm
Message- reception
10
Modularization choosing classes

• Domain classes
• Particular to the application
• Examples BankCustomer, BankTransaction, Teller
• Typically not GUI classes
• Sufficient to classify all requirements
• Non-Domain classes
• Generic to all software systems
• Examples abstract classes, utility classes
• Arise from design and implementation
  considerations
• Select domain classes first and then add
  non-domain classes

11
Modularization choosing packages

• An essential part of choosing an applications
  architecture
• Decompose the system into a set of three to ten
  packages

12
Modularization choosing packages
Application tracking trajectory of rocket
carrying orbit-bound satellite into position
Alternative 1
Alternative 2
Mechanics
Control
Position
Trajectory
Ground control
Weather
On board navig.
13
Refactoring

• Refactoring Change the design and implementation
  with changing the behavior
• Philosophy of Extreme programming
• Design only for the requirements given
• Revise the design and implementation when more
  requirements are added
• Refactoring examples
• Promote a primitive attributes to class
• Introducing abstract base classes or interface

14
Refactoring promote attribute

• class Automobile
• int mileage // Promote it to a class

class Mileage int nominalMileage 0 int
chassisMileage 0 int engineMileage
0 public int computerEffectiveMileage()
class Automobile Mileage mileage //
Promoted to a class
15
Refactoring introducing abstracts
Person SSN Name getSSN() getName()
Student SSN Name getSSN() getName() major getMajor
()
Faculty SSN Name getSSN() getName() office getOffi
ce()
Staff SSN Name getSSN() getName() dept getDept()
16
Improving Robustness

• Protection from faulty Input
• User input
• Input, not from user
• Data communication
• Function calls made by other applications
• Protection from developer error
• Faulty design
• Faulty implementation

17
Initializing variables objects

• Desirable practice
• Initialize all variables before using them
• Initialized variables may offer more valuable
  info on debugging
• Initialize objects
• class Client
• MyClass c new MyClass(1, a) // take class
  default
• Better
• class MyClass
• static MyClass getInstance()
• return new MyClass(1, a)
• Class Client
• MyClass c MyClass.getInstance()

18
Constraints on Parameters 1

• Example
• int computeArea(int aLength, int aBreadth)
• Capture parameter constraints in classes if
  feasible
• int computeArea( RectangleDimension aRDimension )
• Specify all parameter constraints in method
  comments
• aLength gt 0 and
• aBreadth gt 0 and
• aLength gt aBreadth

19
Constraints on Parameters 2

• Callers obey explicit requirements on parameters
  
• Problem is method programmers have no control
  over callers
• Check constraints first within the method code
• if( aLength lt 0 )
• Throw exception if this is a predictable
  occurrence
• Otherwise abort if possible
• Otherwise return default if it makes sense in
  context
• And generate warning or log to a file

20
Wrapping Parameters in a class
Replace int computeArea( int aLength, int
aBreadth) .. With int computeArea(Rectangle
aRectangle) .. where class Rectangle
Rectangle( int aLength, int aBreadth )
if( aLength gt 0 ) this.length aLength
else .. Rectangle class
checks the parameters.
21
Flexibility

• Aspects of flexibility
• adding more of the same kind of functionality
• Example (banking application) handle more kinds
  of accounts without having to change the existing
  design or code
• adding different functionality
• Example add withdraw function to existing
  deposit functionality
• changing functionality
• Example allow overdrafts

22
Flexibility more of the same kind
class Website Member members void
register(Member aMember) .
0..n
members
WebSite register()
Member
Make the design flexible enough to accept new
kinds of members! ? Next page
23
Flexibility more of the same kind
0..n
members
WebSite
Member
StandardMember
XMember
YMember
The open-close principle!
24
Flexibility more of different func.

• A list of related functions
• Example add print to an air travel itinerary
  functions
• Solution add the new function to the existing
  set
• An existing base class
• Example add print road- and ship- to air
  itinerary ? next page
• Neither
• Example add print itineraries for combinations
  of air, road and ship transportation
• Solution design patterns

25
Flexibility more of different func.
Trip printItinerary()
SomeApplicationClass
StandardTrip printItinerary()
Method(s) call printItinerary()
Trip printItinerary()
SomeApplicationClass
Print out the part common to all subclasses
SeaTrip printItinerary()
LandTrip printItinerary()
StandardTrip printItinerary()
26
Reusability

• Design reuse
• Design patterns
• Frameworks
• Implementation reuse
• Foundation classes (e.g., Java API)
• Library functions

27
Reusability function reuse

• Specify completed or well document
• Pre- and post-conditions, assumptions, etc
• Avoid unnecessary coupling with the enclosing
  class
• Make static if feasible
• Include parameterization
• Use meaningful names
• Understandability promotes reusability
• Explain the algorithm
• Reusers need to know how the algorithm works.
• If the algorithm comply with the government or
  companys regulation.

28
Reusability class reuse

• Describe the class completely.
• Make the class name and functionality match a
  real world concept
• Define a useful abstraction
• Reduce dependencies on other classes
• When class A depends on B, no use of A can be
  made without B. Thus it limits reuse of A.
• Sometimes, certain dependencies may be acceptable
  in some applications
• A House may depend on an EntryDoor since every
  house has an entry door
• A Piano may depend on PianoManufacture

29
Reusability class dependencies
Piano
Customer
Class Piano is dependent on class Customer. This
limits the reusability of Piano. Why a piano
warehouse application needs to know Customer?
Customer
Piano
PianoOrder
A possible solution is to separate the
relationship between Customer and piano into a
new class, PianoOrder. Now Customer and Piano
Are independent of each other both can be
easily reused.
The mediator design pattern!
30
Reusability class combinations
Customer computeBill()
Customer computeBill()
RegularCustomer computeBill()
Leveraging inheritance The base class
Customer provides computeBill() for all
subclasses. Subclass RegularCustomer may use
super.computeBill().
class RegularCustomer extends Customer
public int computeBill() int baseAmnt
super.computerBill() // add specials to
baseAmnt return value
abstract class Customer public int
computerBill() // do required computation
for // customers of all types return
value
31
Reusability class combinations
Customer computeBill()
Customer computeBill()
Bill compute()
Leveraging aggregation Computation for bills
is delegated to an aggregate class Bill
class Customer private Bill bill public
int computerBill() int value
this.bill.compute() return value
class Bill public int compute()
// do computation return value
32
Reusability class combinations
Customer computeBill( Orders )
Orders value()
Customer computeBill()
Leveraging dependency Customer has a
method computerBills() which takes a parameter of
Orders.
class Orders public int computeValue()
// do computation return value
class Customer public int computerBills(Order
s someOrders) int value
someOrders.computeValue() return total

33
Efficiency - time

• Design for Other Criteria, Then Consider
  Efficiency
• Design for flexibility, reusability ,
• At some point, identify inefficient places
• Make targeted changes to improve efficiency
• Design for Efficiency From the Start
• Identify key efficiency requirements up front
• Design for these requirements during all phases
• Combine These Two Approaches
• Make trade-offs for efficiency requirements
  during design
• Address remaining efficiency issues after initial
  design

34
Efficiency - Space-Time Trade-offs
Space
35
Summary of Chapter 4

• Correctness of a Design or Code
• Supports the requirements
• In general, many correct designs exist
• Robustness of a Design or Code
• Absorbs errors
• -- of the user
• -- of developers

36
Summary of Chapter 5

• Flexibility
• readily changeable
• Reusability
• in other applications
• Efficiency
• in time
• in space