Transcript Chapter 1 Programming Review and Introduction to Software Design

Chapter 1
Programming Review and Introduction to
Software Design
Requirements
Analysis
Process Phase Introduced in This Chapter
Design
Framework Architecture Detailed Design
Key: x = main emphasis x = secondary emphasis
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Implementation
Key Concept:  Where We’re 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.
Coding Practices Used in This Book

Instance variables may be referred to with “this.”
o Example:
class Car { int milesDriven; … }
May use this.milesDriven within methods of Car to clarify

Static variables may be referred to with class name.
o Example:
class Car { static int numCarsSold; … }
May use Car.numCarsSold within methods of Car to clarify

Parameters are given prefix “a” or “an”
o Example:
public … getVolume( int aLength ) {…}
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Preconditions: conditions on non-local variables that the
method’s code assumes
Programming Conventions:
o Includes parameters
Method Documentation 1 of 2
o Verification of these conditions not promised in method itself

Postconditions: value of non-local variables after execution
o Includes parameters
o Notation: x' denotes the value of variable x after execution

Invariants: relationships among non-local variables that the
function’s execution do not change
(The values of the individual variables may change, however.)
o Equivalent to inclusion in both pre- and post-conditions
o There may also be invariants among local variables
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Programming Conventions: Method Documentation 2 of 2
 Return:
o What the method returns
 Known issues:
o Honest statement of what has to be done, defects
that have not been repaired etc.
o (Obviously) limited to what’s known!
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
else
Parameter & settings make sense
Set name to
“defaultName"
Nominal path
Output notification to console
protected final void setName( String aName )
{
// Check legitimacy of parameter and settings
if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) ||
( maxNumCharsInName() > alltimeLimitOfNameLength() ) )
{ name = new String( "defaultName" );
System.out.println
( "defaultName selected by GameCharacter.setName()");
}
else
// Truncate if aName too long
if( aName.length() > maxNumCharsInName() )
name = new String
( aName.getBytes(), 0, maxNumCharsInName() );
else // assign the parameter name
name = new String( aName );
}
else
Set name
to parameter
Flowchart Example
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Parameter
name too long
Truncate
name
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
Pseuodocode Example For an X-ray
Controller
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.
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.
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.
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.
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
o … manipulate( float aFloat, int anInt )
 poor
o … getBaseRaisedToExponent( float aBase, int anExponent )

Avoid global variables: consider passing parameters instead
o … extract( int anEntry ) { …… table = …. }
 replace?
o … extract( int anEntry, EmployeeTable anEmployeeTable )
But not when the number of parameters exceeds  7

Defend against bad data
o Check parameter and other input values
o Use exceptions – or –
o Use defaults
-- or –
o Return special values (less desirable)
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Good Habits for Writing Functions 2 of 3
 Don’t use parameters as method variables
 Give names to numbers
for( i = 0; i < 8927; ++i )
 poor: why 8927?
o Instead:
int NUM_CELLS = 8927;
for( cellCounter = 0; cellCounter < 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.
Good Habits for Writing Functions 3 of 3

Initialize all variables
o re-initialize where necessary to “reset”

Check loop counters, especially for range correctness

Avoid nesting loops more than 3 levels
o introduce auxiliary methods to avoid

Ensure loop termination
o a proof is ideal – in any case, be convinced

Inspect before compiling
o be convinced of correctness first
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Typical I/O
For
Command
Line
Calculator
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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
o Invalid number of accounts
o Invalid account
o Invalid amount to add (not an integer)
o 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.
Problems With CommandLineCalculator Implementation*
2 of 2
 Hard
to modify, add or remove parts. (flexibility)
 Executes fast
enough? (speed efficiency)
 Satisfies memory
 Class
requirements?
(space efficiency)
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.
Key Concept:  Ensure Correctness 
We are primarily responsible for ensuring
that our code does what it’s intended to.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
I/O For Robust
Command Line
Calculator
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Prompt for account number and get userRequest
Better Design for
interactWithUser()
Thick line is nominal path
return
else
userRequest != “Quit application”
Exception
Try to make integer
accountNum from userRequest
Handle
integer
exception
else
Notify user
of bad value
accountNum within range
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.
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,
it’s 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.
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.
Aspects of Flexibility
 Obtaining more
or less of what’s already present
o Example: handle more kinds of accounts without
needing to change the existing design or code
 Adding new
kinds of functionality
o Example: add withdraw to existing deposit function
 Changing functionality
o Example: allow withdrawals to create an overdraft
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
We can reuse ….
 Object code (or equivalent)
Types of Reuse
o Example: sharing dll’s between word processor and
spreadsheet
o To be covered in the Components chapters xx - xx
 Classes
– in source code form
o Example: Customer class used by several applications
o Thus, we write generic code whenever possible
 Assemblies of
Related Classes
o Example: the java.awt package
 Patterns of
Class Assemblies
o 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.
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.
Remaining Problems With CommandLineCalculator
 Insufficient flexibility
o To add subtraction, multiplication etc.
o To change the nature of the project
 Speed efficiency not explored
 Space efficiency not explored
o Limit to number of accounts?
 Reusability doubtful
o OO not leveraged
 No visualization of design provided
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.