1COMP 7700 – Intro to Software Design1Chapter 1Programming Review andIntroduction to Software DesignCOMP 7700 – Intro to Software Design2Process Phase Introduced in This ChapterRequirementsAnalysisDesignImplementationArchitectureFramework Detailed DesignKey: = secondary emphasis= main emphasisxxAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design3Key Concept:  Where We’re Headed In development, we start by thinkingabout architecture, and end withprogramming.For learning purposes, the course and thebook begins by discussing programming,and ends by explaining architecture.COMP 7700 – Intro to Software Design4Coding 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.COMP 7700 – Intro to Software Design5• Preconditions: conditions on non-local variables that themethod’s code assumes– Includes parameters– Verification of these conditions not promised in method itself• Postconditions: value of non-local variables afterexecution– Includes parameters– Notation: x' denotes the value of variable x after execution• Invariants: relationships among non-local variables thatthe function’s 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 variablesProgramming Conventions:Method Documentation 1 of 2Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design6Programming Conventions: MethodDocumentation 2 of 2 Return:– What the method returns Known issues:– Honest statement of what has to be done, defects that havenot been repaired etc.– (Obviously) limited to what’s known!Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.2COMP 7700 – Intro to Software Design7Key Concept:  Specifying Methods We specify each method in its commentsection with preconditions,postconditions, return, invariants andknown issues.Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design8Flowchart 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 nameSet name to parameterParameter & settings make senseelseParametername too longelseOutput notification to consoleAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design9FOR number of microseconds supplied by operatorIF number of microseconds exceeds critical valueTry to get supervisor's approvalIF no supervisor's approvalabort with "no supervisor approval for unusual duration" messageENDIFENDIFIF power level exceeds critical valueabort with "power level exceeded" messageENDIFIF ( patient properly aligned & shield properly placed & machine self-test passed )Apply X-ray at power level pENDIFENDFORPseuodocode Example For an X-ray ControllerAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design10Advantages of Pseudocode & Flowcharts• Clarify algorithms in many cases• Impose increased discipline on the process ofdocumenting detailed design• Provide additional level at which inspection can beperformed• Help to trap defects before they become code• Increases product reliability• May decreases overall costsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design11Disadvantages of Pseudocode & Flowcharts• Create an additional level of documentation tomaintain• Introduce error possibilities in translating to code• May require tool to extract pseudocode and facilitatedrawing flowchartsAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.COMP 7700 – Intro to Software Design12Key Concept:  The What vs. the How of Methods Preconditions etc. specify what a methodaccomplishes.Activity charts etc. describe how themethod accomplishes these.Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.3COMP 7700 – Intro to Software Design13Good Habits for Writing Functions 1 of 3• Use expressive naming: the names of the function, theparameters 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.COMP 7700 – Intro to Software Design14Good Habits for Writing Functions