Chapter 1 Programming Review and Introduction to Software Design

1
Chapter 1Programming Review and Introduction to
Software Design
2
Process Phase Introduced in This Chapter
Requirements Analysis
Design
Architecture
Framework
Detailed Design
Implementation
Key
secondary emphasis
main emphasis
x
x
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
3
Key Concept ? Where Were Headed ?
In development, we start by thinking about
architecture, and end with programming. For
learning purposes, this book begins by discussing
programming, and ends by explaining architecture.
4
Coding Practices Used in This Book

• Instance variables may be referred to with
  this.
• Example class Car int milesDriven
• May use this.milesDriven within methods of Car to
  clarify
• Static variables may be referred to with class
  name.
• Example class Car static int numCarsSold
  
• May use Car.numCarsSold within methods of Car to
  clarify
• Parameters are given prefix a or an
• Example public getVolume( int aLength )

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
5
Programming Conventions Method Documentation 1
of 2

• Preconditions conditions on non-local variables
  that the methods code assumes
• Includes parameters
• Verification of these conditions not promised in
  method itself
• Postconditions value of non-local variables
  after execution
• Includes parameters
• Notation x' denotes the value of variable x
  after execution
• Invariants relationships among non-local
  variables that the functions execution do not
  change
• (The values of the individual variables may
  change, however.)
• Equivalent to inclusion in both pre- and
  post-conditions
• There may also be invariants among local variables

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
6
Programming Conventions Method Documentation 2
of 2

• Return
• What the method returns
• Known issues
• Honest statement of what has to be done, defects
  that have not been repaired etc.
• (Obviously) limited to whats known!

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
7
Key Concept ? Specifying Methods ?
We specify each method in its comment section
with preconditions, postconditions, return,
invariants and known issues.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
8
Flowchart Example
else
Parameter settings make sense
Nominal path
Set name to defaultName"
Output notification to console
Parameter name too long
else
protected final void setName( String aName )
// Check legitimacy of parameter and
settings if( ( aName null ) (
maxNumCharsInName() lt 0 ) (
maxNumCharsInName() gt alltimeLimitOfNameLength()
) ) name new String( "defaultName"
) System.out.println (
"defaultName selected by GameCharacter.setName()")
else // Truncate
if aName too long if( aName.length()
gt maxNumCharsInName() ) name
new String ( aName.getBytes(),
0, maxNumCharsInName() ) else //
assign the parameter name name
new String( aName )
Truncate name
Set name to parameter
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
9
Pseuodocode Example For an X-ray Controller
FOR number of microseconds supplied by
operator  IF number of microseconds exceeds
critical value Try to get supervisor's approval
IF no supervisor's approval abort with "no
supervisor approval for unusual duration"
message ENDIF ENDIF IF power level exceeds
critical value abort with "power level exceeded"
message ENDIF IF ( patient properly aligned
shield properly placed machine self-test
passed ) Apply X-ray at power level p
ENDIF ENDFOR
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
10
Advantages of Pseudocode Flowcharts

• Clarify algorithms in many cases
• Impose increased discipline on the process of
  documenting detailed design
• Provide additional level at which inspection can
  be performed
• Help to trap defects before they become code
• Increases product reliability
• May decreases overall costs

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
11
Disadvantages of Pseudocode Flowcharts

• Create an additional level of documentation to
  maintain
• Introduce error possibilities in translating to
  code
• May require tool to extract pseudocode and
  facilitate drawing flowcharts

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
12
Key Concept ? The What vs. the How of Methods ?
Preconditions etc. specify what a method
accomplishes. Activity charts etc. describe how
the method accomplishes these.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
13
Good Habits for Writing Functions 1 of 3

• Use expressive naming the names of the function,
  the parameters and the variables should indicate
  their purpose
• manipulate( float aFloat, int anInt ) ? poor
• getBaseRaisedToExponent( float aBase, int
  anExponent )
• Avoid global variables consider passing
  parameters instead
• extract( int anEntry ) table . ?
  replace?
• extract( int anEntry, EmployeeTable
  anEmployeeTable )
• But not when the number of parameters exceeds ? 7
• Defend against bad data
• Check parameter and other input values
• Use exceptions or
• Use defaults -- or
• Return special values (less desirable)

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
14
Good Habits for Writing Functions 2 of 3

• Dont use parameters as method variables
• Give names to numbers
• for( i 0 i lt 8927 i ) ? poor why 8927?
• Instead
• int NUM_CELLS 8927
• for( cellCounter 0 cellCounter lt NUM_CELLS
  cellCounter )
• Limit number of parameters to 6 or 7
• Introduce variables near their first usage

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
15
Good Habits for Writing Functions 3 of 3

• Initialize all variables
• re-initialize where necessary to reset
• Check loop counters, especially for range
  correctness
• Avoid nesting loops more than 3 levels
• introduce auxiliary methods to avoid
• Ensure loop termination
• a proof is ideal in any case, be convinced
• Inspect before compiling
• be convinced of correctness first

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
16
Requirements for Command Line Calculator Example

1. CommandLineCalculator begins by asking the user
   how many accounts he wants to open. It then
   establishes the desired number, each with zero
   balance.
2. CommandLineCalculator asks the user which of
   these accounts he wants to deal with.
3. When the user has selected an account,
   CommandLineCalculator allows the user to add
   whole numbers of dollars to, or subtract them
   from the account for as long as he requires.
4. When the user is done with an account, he is
   permitted to quit, or to pick another account to
   process.

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
17
Typical I/O For Command Line Calculator
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
18
Problems With CommandLineCalculator
Implementation
1 of 2

• How do we know that all required
  functionality has been handled? (correctness)
• If the user makes a mistake the system crashes
  or performs unpredictably (robustness)
• The following cause crashes
• Invalid number of accounts
• Invalid account
• Invalid amount to add (not an integer)
• Invalid string (not stop or Quit application)
• Not clear what some of the method are meant to
  do (documentation)

See appendix to this chapter
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
19
Problems With CommandLineCalculator
Implementation
2 of 2

• Hard to modify, add or remove parts.
  (flexibility)
• Executes fast enough? (speed efficiency)
• Satisfies memory requirements? (space
  efficiency)
• Class usable for other applications? (reusability)

See appendix to this chapter
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
20
Key Concept ? Ensure Correctness ?
We are primarily responsible for ensuring that
our code does what its intended to.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
21
I/O For Robust Command Line Calculator
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
22
Better Design forinteractWithUser()
Prompt for account number and get userRequest
Thick line is nominal path
else
userRequest ! Quit application
Exception
Try to make integer accountNum from userRequest
return
Handle integer exception
else
accountNum within range
Notify user of bad value
do executeAdditions on accountNum Prompt for
account number and get userRequest
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
23
Key Concept ? Good Code May Not Be Good Design
?
The code here is more robust, but it does not
exploit object-orientation or exhibit a clear
design. Consequently, its inflexible, not easy
to verify, and unlikely to be reused.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
24
Key Concept ? Write Robust Code ?
Good designs withstand anomalous treatment.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
25
Aspects of Flexibility

• Obtaining more or less of whats already present
• Example handle more kinds of accounts without
  needing to change the existing design or code
• Adding new kinds of functionality
• Example add withdraw to existing deposit
  function
• Changing functionality
• Example allow withdrawals to create an overdraft

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
26
Types of Reuse

• We can reuse .
• Object code (or equivalent)
• Example sharing dlls between word processor and
  spreadsheet
• To be covered in the Components chapters xx - xx
• Classes in source code form
• Example Customer class used by several
  applications
• Thus, we write generic code whenever possible
• Assemblies of Related Classes
• Example the java.awt package
• Patterns of Class Assemblies
• To be covered in Design Pattern chapters xx - xx

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
27
Key Concept ? Design for Flexibility and Reuse?
Good designs are more easily modified and reused.
Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.
28
Remaining Problems With CommandLineCalculator

• Insufficient flexibility
• To add subtraction, multiplication etc.
• To change the nature of the project
• Speed efficiency not explored
• Space efficiency not explored
• Limit to number of accounts?
• Reusability doubtful
• OO not leveraged
• No visualization of design provided

Adapted from Software Design From Programming to
Architecture by Eric J. Braude (Wiley 2003), with
permission.