chapter 1 programming review and introduction to software design
TRANSCRIPT
Process Phase Introduced in This ChapterRequirementsAnalysis
Design
Implementation
ArchitectureFramework Detailed Design
Key: = secondary emphasis= main emphasis xx
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
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.
Programming Conventions: Method Documentation 1 of 2
Preconditions: conditions on non-local variables that the method’s code assumeso Includes parameters
o Verification of these conditions not promised in method itself
Postconditions: value of non-local variables after executiono 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 variablesAdapted 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.
Flowchart Example
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 ); }
Nominal pathSet name to “defaultName"
Truncate name
Set name to parameter
Parameter & settings make sense else
Parametername too long elseOutput notification to console
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 ENDIFIF power level exceeds critical value
abort with "power level exceeded" message ENDIFIF ( patient properly aligned & shield properly placed & machine self-test passed )
Apply X-ray at power level p ENDIF
ENDFOR
Pseuodocode Example For an X-ray Controller
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 purposeo … manipulate( float aFloat, int anInt ) poor
o … getBaseRaisedToExponent( float aBase, int anExponent )
Avoid global variables: consider passing parameters insteado … extract( int anEntry ) { …… table = …. } replace?
o … extract( int anEntry, EmployeeTable anEmployeeTable )
But not when the number of parameters exceeds 7
Defend against bad datao 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 variableso re-initialize where necessary to “reset”
Check loop counters, especially for range correctness
Avoid nesting loops more than 3 levelso introduce auxiliary methods to avoid
Ensure loop terminationo a proof is ideal – in any case, be convinced
Inspect before compilingo 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*
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 crasheso Invalid number of accountso Invalid accounto 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)
1 of 2
* See appendix to this chapterAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.
Problems With CommandLineCalculator Implementation*
Hard to modify, add or remove parts. (flexibility)
Executes fast enough? (speed efficiency)
Satisfies memory requirements? (space efficiency)
Class usable for other applications? (reusability)
2 of 2
* 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.
Better Design forinteractWithUser()
Thick line is nominal path
else
accountNum within rangeelse
Exception
Prompt for account number and get userRequest
userRequest != “Quit application”
Try to make integeraccountNum from userRequest
Notify userof bad value
Handle integer
exception
return
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)
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 applicationso 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
Types of Reuse
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 providedAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.