1. Preamble Formation of teams: No midterm: First deliverable:
swag.uwaterloo.ca/~ijdavis/cgi-bin/teams1.cgi
No midterm:
swag.uwaterloo.ca/~ijdavis/cgi-bin/midterm.cgi
First deliverable:
Sam Nabi – guest lecture for 15th January 2016
Finalize team names by 15th January 2016
Winter 2016
(c) Ian Davis

2. Winter 2016
(c) Ian Davis

3. Winter 2016
(c) Ian Davis

4. Winter 2016
(c) Ian Davis

5. Winter 2016
(c) Ian Davis

6. Winter 2016
(c) Ian Davis

7. Winter 2016
(c) Ian Davis

8. Winter 2016
(c) Ian Davis

9. Winter 2016
(c) Ian Davis

10. Winter 2016
(c) Ian Davis

11. Winter 2016
(c) Ian Davis

12. Winter 2016
(c) Ian Davis

13. Winter 2016
(c) Ian Davis

14. Recommended strategies
Keep getting it wrong till you get it right
Plan to throw one away, you will anyway
If you plan to throw one away, you will throw two away
Throw bad ideas away early
Keep it simple stupid (KISS principle)
Enforce an architecture on everything
Plan for the long term
Generalize / encapsulate
Winter 2016
(c) Ian Davis

15. More recommendations Do things in the logical order
1. Registration / people profiles / login
2. Capture data / view data
3. Extend functionality
4. Permissions
Use a collaborative wiki for documenting:
Code / Design / Architecture
Meetings / Decisions etc.
Winter 2016
(c) Ian Davis

16. Winter 2016
(c) Ian Davis

17. Winter 2016
(c) Ian Davis

18. Winter 2016
(c) Ian Davis

19. Winter 2016
(c) Ian Davis

20. Low level utilities Wrap malloc/realloc/free Have single exit routine
Catch memory leaks
Have single exit routine
So can break point on exit
Have single abort routine
Permits final cleanup and trapping
Use a trap routine() for debugging
Make the code work for you
Write a log routine
Winter 2016
(c) Ian Davis

21. void log(const char. fmtP,
void log(const char *fmtP, ...) { va_listarg; va_start(arg, fmtP); vfprintf(stderr, fmtP, arg); va_end(arg); fflush(stderr); if (g_logF) { vfprintf(g_logF, fmtP, arg); fflush(g_logF); } }
Winter 2016
(c) Ian Davis

22. Winter 2016
(c) Ian Davis

23. Winter 2016
(c) Ian Davis

24. Winter 2016
(c) Ian Davis

25. Winter 2016
(c) Ian Davis

26. Winter 2016
(c) Ian Davis

27. Winter 2016
(c) Ian Davis

28. Winter 2016
(c) Ian Davis

29. Winter 2016
(c) Ian Davis

30. Winter 2016
(c) Ian Davis

31. Winter 2016
(c) Ian Davis

32. Winter 2016
(c) Ian Davis

33. Winter 2016
(c) Ian Davis

34. Winter 2016
(c) Ian Davis

35. Winter 2016
(c) Ian Davis

36. Programming Issues Code Complete (Roger S. Pressman)
Winter 2016
(c) Ian Davis

37. Comparison to assembler
Assembler to 1
Ada 1 to 4.5
Quick/Turbo Basic 1 to 5
C 1 to 2.5
Fortran 1 to 3
Pascal 1 to 3.5
C to ??
Winter 2016
(c) Ian Davis

38. Type of program Structured data Quick and dirty project Fast execution
(Good) Ada, C/C++, Pascal (Bad) Assembler, Basic
Quick and dirty project
(Good) Basic (Bad) Pascal, Ada, Assembler
Fast execution
(Good) Assembler, C, C++ (Bad) Interpreted Languages
Mathematical calculation
(Good) Fortran (Bad) Pascal
Easy to maintain
(Good) Pascal, Ada (Bad) C, Fortran
Winter 2016
(c) Ian Davis

39. Types of program Dynamic memory use Limited available memory
(Good) Pascal, C, C++ (Bad) Basic
Limited available memory
(Good) Basic, Assembler C (Bad) Fortran
Real-time requirements
(Good) Ada, Assembler, C (Bad) Fortran, Basic
String manipulation
(Good) Basic, Pascal (Bad) C
Winter 2016
(c) Ian Davis

40. Reasons to create routines
Reduce complexity
Avoid duplication
Anticipate change
Hide sequences
Hide data structures
Improve performance
Promote reuse
Improve readability
Improve portability
Isolate complexity
Multiple languages
Simplify boolean tests
Winter 2016
(c) Ian Davis

41. Cohesion Relationship of code within a routine.
How “strong” are the relationships.
Routines should do a single thing and do it well.
Goal: Create routines with internal integrity
50% of highly cohesive routines fault free.
18% of low cohesion routines fault free.
Winter 2016
(c) Ian Davis

42. Types of cohesion Functional cohesion (BEST)
Routine performs a single function
Verb + object { eg. GetFileData() }
Sequential cohesion (WEAK)
Routine performs set of steps in right order.
Share data from step to step
Wishy washy { eg. DoStep1(), DoStep2() }
Winter 2016
(c) Ian Davis

43. Types of cohesion Communicational cohesion (WEAK)
Does lots of things with the same data
Complex {eg. GetNameUpdatePhoneNo() }
Temporal cohesion (REASONABLE)
Lots of things done at the same time
Employ with functional cohesion
Focus on time {eg. Startup(), Shutdown() }
Winter 2016
(c) Ian Davis

44. Unacceptable cohesion
Procedural cohesion
Like sequential cohesion
BUT sequential parts are unrelated
(Ill)Logical cohesion
Separate logic conditioned by control flag
Flow of logic only thing which units code
Coincidental cohesion
Logic in same place coincidentally
Winter 2016
(c) Ian Davis

45. Coupling
The “usefulness” and “effectiveness” of the connection between routines.
Compliment of cohesion.
Want small, direct, meaningful, visible, flexible relations.
Want “loose” coupling.
Winter 2016
(c) Ian Davis

46. Coupling Routines should not depend on their caller.
They should be detached and self contained.
They should be sufficiently general.
Routines should not share global data.
Routines should fulfill a purpose rather than be viewed as performing specific actions.
Winter 2016
(c) Ian Davis

47. Coupling criteria Size of interface Intimacy
Lots of complex parameters are bad
Lots of reference to global data bad
Intimacy
Immediacy of method of communication
Parameter and return result (GOOD)
Via messages (WEAKER)
Global data (DUBIOUS)
Via mediator/database etc (WEAK)
e.g. Dummy records written to tape
Winter 2016
(c) Ian Davis

48. Coupling criteria Visibility Flexibility Clarity
How are results manifest
By parameter (GOOD)
By side effect (BAD)
Flexibility
How easy is it to pass the right parameters
Is routine plug and play or overly specific
Clarity
Routines should have sensible names
Winter 2016
(c) Ian Davis

49. Coupling criteria
Routines should be able to call other routines easily.
The consequences of such calls should be both clear and straightforward.
Break up a program along lines of minimal interconnectedness.
Split with the grain; not against the grain.
Winter 2016
(c) Ian Davis

50. Levels of coupling Simple-data coupling (SIMPLEST/BEST)
Only non-structured data shared
All data passed as parameters/return result
Strong data-structure coupling (OK)
Structured data passed between routines
Most/all of structures passed relevant
Weak data-structure coupling (WEAK)
Little information in structures passed relevant
Winter 2016
(c) Ian Davis

51. Levels of coupling Control coupling (POOR)
Parameters tell called routine how to behave
Caller understands internal workings of callee
Global data coupled (HORRIBLE)
Two routines operate on same global data
Connection neither intimate nor visible
Pathologically coupled (DISASTER)
One routine directly uses another routines code
One routine directly alters another routines data
Winter 2016
(c) Ian Davis

52. Additional coupling consideration
Identify all constant parameters.
Use constant pointers whenever the structure pointed at will not be changed.
Consider in-lining very short routines.
Use generic names rather than return codes.
Use objects to encapsulate functionality.
Access objects via complete interfaces.
Use compilers which do full type checking.
Winter 2016
(c) Ian Davis

53. Size of a routine Routine size inversely correlated with error
As size  to 200 lines errors per line  (Basili)
Routine size not correlated with errors
Structural complexity and amount of data far more significant than routine size (Shen)
Larger routines (65+ lines) cheaper and no less reliable (Card)
Small routines (<143lines) has 23% more errors than larger routines.
Winter 2016
(c) Ian Davis

54. Size of a routine
Code in which all routines about 10 lines long, as incomprehensible as code without routines at all (Conte).
Code required less change when routines averaged 100 to 150 lines of code. (Lind).
Practical upper limit on routine size about 200 lines of hard code (without comments).
Most buggy routines had > 500 lines code.
Winter 2016
(c) Ian Davis

55. Defensive programming tips
Use lots of assertions.
Avoid creating assertions with side-effects.
Check correctness of inputs.
Anticipate unexpected types in case statements, etc.
Document changes and use version control
Monitor memory leakage
Implement interfaces as interfaces
Check for error returns
Winter 2016
(c) Ian Davis

56. Defensive programming tips
Use macros to support / facilitate change.
Nest macros using brackets.
Order parameters as input, update, output.
Use same parameter order for similar tasks.
Compare with fprintf() and fputs()
Use all parameters; optionally default some.
Don’t use parameters as working variables.
Hard to debug when viewing stack.
Winter 2016
(c) Ian Davis

57. Defensive programming tips
Prefix global and object state variables
eg. m_pointer, g_counter
Designate data private when appropriate.
Distinguish pointers from non-pointers.
Identify levels of indirection to arrive at an element using a pointer.
Use comments to explain what is clear as well as what is unclear.
Winter 2016
(c) Ian Davis

58. Orthogonal issues Detect and eliminate memory leakage's
Code should be re-entrant
Don’t condition logic based on static data
Code should be thread safe
Avoid global state
Protect object state against concurrent update
Code interrupt safe
Anticipate unexpected throws, interrupts etc.
Eg. out of memory or Cntl-C
Winter 2016
(c) Ian Davis