1 Intro to Software design - Mississippi State...

Software Architecture – Intro to Software Design 1

Chapter 1 Programming Review and

Introduction to Software Design


Process Phase Introduced in This Chapter

Requirements Analysis

Design

Implementation

Architecture Framework Detailed Design

Key: = secondary emphasis = main emphasis x x

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, the course and the book begins by discussing programming, and ends by explaining architecture.


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 ) {…}



•  Preconditions: conditions on non-local variables that the method’s 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 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 variables

Programming Conventions: Method Documentation 1 of 2



Programming Conventions: Method Documentation 2 of 2

q Return: –  What the method returns

q Known issues: –  Honest statement of what has to be done, defects that have

not been repaired etc. –  (Obviously) limited to what’s known!



Key Concept: à Specifying Methods ß

We specify each method in its comment section with preconditions, postconditions, return, invariants and known issues.



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 path Set name to “defaultName"

Truncate name

Set name to parameter

Parameter & settings make sense else

Parameter name too long else Output notification to console



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

Pseuodocode Example For an X-ray Controller



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



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



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.



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)



Good Habits for Writing Functions 2 of 3

q  Don’t use parameters as method variables q  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 )

q  Limit number of parameters to 6 or 7 q  Introduce variables near their first usage



Good Habits for Writing Functions 3 of 3

q  Initialize all variables o  re-initialize where necessary to “reset”

q Check loop counters, especially for range correctness q Avoid nesting loops more than 3 levels

o  introduce auxiliary methods to avoid

q Ensure loop termination o  a proof is ideal – in any case, be convinced

q  Inspect before compiling o  be convinced of correctness first



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.



Typical I/O For C

omm

and Line Calculator


Problems With CommandLineCalculator Implementation*

q  How do we know that all required functionality has been handled? (correctness)

q  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”)

q  Not clear what some of the method are meant to do (documentation)

1 of 2

* See appendix to this chapter



Problems With CommandLineCalculator Implementation*

q Hard to modify, add or remove parts. (flexibility)

q Executes fast enough? (speed efficiency)

q Satisfies memory requirements? (space efficiency)

q Class usable for other applications? (reusability)

2 of 2

* See appendix to this chapter



Key Concept: à Ensure Correctness ß

We are primarily responsible for ensuring that our code does what it’s intended to.



I/O For R

obust Com

mand Line C

alculator


Better Design for interactWithUser()

Thick line is nominal path

else

accountNum within range else

Exception

Prompt for account number and get userRequest

userRequest != “Quit application”

Try to make integer accountNum from userRequest

Notify user of bad value

Handle integer

exception

return

do executeAdditions on accountNum

Prompt for account number and get userRequest


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.



Key Concept: à Write Robust Code ß

Good designs withstand anomalous treatment.



Aspects of Flexibility

•  Obtaining more or less of what’s 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



We can reuse …. q Object code (or equivalent)

–  Example: sharing dll’s between word processor and spreadsheet

–  To be covered in the Components chapters xx - xx q Classes – in source code form

–  Example: Customer class used by several applications –  Thus, we write generic code whenever possible

q Assemblies of Related Classes –  Example: the java.awt package

q Patterns of Class Assemblies –  To be covered in Design Pattern chapters xx - xx

Types of Reuse



Key Concept: à Design for Flexibility and Reuseß

Good designs are more easily modified and reused.



Lesson Summary: Design Questions

q  Insufficient flexibility o  To add subtraction, multiplication etc.

o  To change the nature of the project

q  Speed efficiency not explored

q  Space efficiency not explored o  Limit to number of accounts?

q  Reusability doubtful o  OO not leveraged

q  No visualization of design provided


Remaining Problems With CommandLineCalculator

1 Intro to Software design - Mississippi State...

Documents

Transcript of 1 Intro to Software design - Mississippi State...