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

Implementation

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

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.

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 methods 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 functions 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 whats 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 Set name to defaultName" Output notification to console

Parameter & settings make sense

Nominal path
Parameter name too long

else

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 ); }

Set name to parameter

Truncate name

Flowchart Example

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

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

y y

Clarify algorithms in many cases Impose increased discipline on the process of documenting detailed design Provide additional level at which inspection can be performed
y Help to trap defects before they become code y 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

y

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 = . }
But not when the number of parameters exceeds s 7

replace?

o extract( int anEntry, EmployeeTable anEmployeeTable )

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

Dont use parameters as method variables Give names to numbers

for( i = 0; i < 8927; ++i ) o Instead: int NUM_CELLS = 8927; for( cellCounter = 0; cellCounter < NUM_CELLS; ++cellCounter ) poor: why 8927?

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 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.

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.

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

else

userRequest != Quit application

return

Exception

Try to make integer accountNum from userRequest

Handle integer exception Notify user of bad value

else

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, 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.

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 whats 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 dlls 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.