1. Software Engineering Modern Approaches
Eric Braude and Michael Bernstein

2. Chapter 22: Principles of Implementation

3. The Software Development Lifecycle
Planning
Learning Goals of This Chapter
How do teams choose the programming languages?
How does one define classes? methods?
What are standard implementation practices?
How do you handle variable naming? global variables? function parameters? initialization? comments?
What is “defensive programming?”
How do you handle errors?
What does it mean to “enforce intentions?”
What are good coding standards?
What implementation tools and environments are available for programming?
How do software engineers working on large projects go about programming?
How should student teams handle implementation?
Maintenance
Testing
The Software Development Lifecycle
Requirements analysis
Implementation
Design
Fig 22.1
Phase most relevant to this chapter is shown in bold
© 2010 John Wiley & Sons Ltd.

4. The Origins of a Class Domain class Design class Implementation class
Corresponds to a requirements paragraph
Example: DVD
Design class
Specified in SDD
Not a domain class
Example: RentalItem
Implementation class
Too minor to specify in design

5. Programming Conventions: Method Documentation 1 of 2
Intent: An informal statement of what the method is intended to do
Don’t specify the details here: The other categories provide them
Preconditions: Conditions on non-local variables that the method assumes
Includes parameters
Verification of these conditions not promised in method itself
Postconditions: Value of non-local variables after execution
Notation: x' denotes the value of variable x after execution

6. Programming Conventions: Method Documentation 2 of 2
Invariant: Relationship among non-local variables that the method’s execution leaves unchanged
(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
Return:
What the method returns
Known issues:
Honest statement of what has to be done, defects that have not been repaired etc.
Exceptions:
These are often thrown when the preconditions are not met because this indicates an abnormality in execution

7. Example of Method Documentation: Tic Tac Toe
/** Intent: Record anOorX at aRow/aCol if aRow/aCol blank; Return 'N' if
* not permitted; return anOorX if full row/column/diagonal *
* Preconditions: anOorX='O' OR anOorX='X‘; 1<=aRow0<=3; 1<=aCol<=3
* Postconditions (note use of x and x')
* Post0. All preconditions are met OR Exception thrown
* Post1. gameBoard' contains all non-blank elements of gameBoard
* Post2. gameBoard[aRow-1][aCol-1] = ' ' OR return = 'N'
* Post3. gameBoard[aRow-1][aCol-1] != ' ' OR
* gameBoard'[aRow-1][aCol-1] = anOorX
* Post4. There is no full line of anOorX in gameBoard' OR return = anOorX */
public static char makeMove( char anOorX, int aRow, int aCol ) throws Exception{

8. Good Implementation Practices 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 )  better
Avoid global variables: consider passing parameters instead
… extract( int anEntry ) { …… table = …. }  replace?
… extract( int anEntry, EmployeeTable anEmployeeTable )  better
But not when the number of parameters exceeds  7

9. Good Implementation Practices 2 of 3
Don’t use parameters as method variables
myMethod( int i ) { …… for( i=0; …  no!
Limit number of parameters to 6 or 7
Give names to numbers
for( i = 0; i < 8927; ++i )  poor: why 8927?
Instead:
int NUM_CELLS = 8927; //….
for( cellCounter = 0; cellCounter < NUM_CELLS; ++cellCounter )
Introduce variables near their first usage

10. Good Implementation Practices 3 of 3
Initialize all variables
re-initialize where necessary to “reset”
Check loop counters, especially for range correctness
Avoid nesting loops more than 3 levels
introduce auxiliary methods to avoid
Ensure loop termination
a proof is ideal – in any case, document reasoning

11. RPGMouseEventListener
Encounter Models
Design model
Implementation model
FrameworkRPG.
RolePlayingGame
RolePlayingGame
RPGame
«file»
RPGame.java
«file»
RPGame.class
RPGEvent
«file»
RPGEvent.java
«file»
RPGEvent.class
GameState
«file»
RPGame.java
«file»
RPGame.class
RPGMouseEventListener
«file»
RP…..java
«file»
RP…..class
© 2010 John Wiley & Sons Ltd.

12. Defect Recording Log (Humphrey)
Date
Number
Type
Phase Injected
Phase Removed
Repair Time (minutes)
6/14/99
142
Interface
Personal detailed design
Personal code review 10
Description: omitted checks on name length in EncounterCharacter.
6/16/99
143
Documen-tation
Code 4
Description: incorrect Javadoc description of EncounterCharacter.
This table concludes with defects found during unit test

13. Date Start Stop Interruptns. Time taken Phase Comments 6/99 10:04 am
Time_Recording_Log
Date
Start
Stop
Interruptns.
Time taken
Phase
Comments
6/99
10:04 am
10:25 am
4 + 6 11
Detailed Design
Consulted with V.N.
1:20 pm
4:34 pm
159
Personal Code review
Defect 14
7/99

14. OpenOffice Developer’s Guide
© 2010 John Wiley & Sons Ltd.

15. UML Excerpt from Developer’s Guide