1. Looking ahead Your final-year project

2. In final year you do a project...  For these courses, it ’ s assumed you will build an “ artefact ”, and report on the building of it.  It ’ s marked on the cleverness, innovation, problem-solving ability, insight etc. shown in the report.

3. Project topic  Ideally clever & small - you then have the time to deal with it properly.  You choose the topic, in consultation with possible supervisors.  ( “ Your ” topic => motivation => better projects.)  Staff may suggest project topics, or topic areas though.

4. Clearly, my suggestions are …  … mainly Software Engineering topics …  SE projects tend to need advance preparation …  … which is why I ’ m raising the issue now, so we can talk through possible projects over the rest of this year.

5. My special SE interests  Program tools to help design & code: –graphic editors for design; –prototypers; –programming-language oriented text editors; –program provers; –configuration management tools; –…–…  Programming languages

6. Other S.E. staff  No other SE specialists at the moment, but various staff I ’ d point you at for particular aspects – e-mail me for suggestions!

7. INSE - Lecture 12 Debugging; Maintenance

8. Debugging

9. A thought Glendower: I can call up spirits from the vasty deep Hotspur: Why, so can I, or so can any man, but will they come when you do call for them? Henry IV, part 1, Act 3 scene 1 u So when you know there ’ s a bug - finding it takes some mix of persistence, luck, skill and thought. u Skill and thought don ’ t “ just happen ”.

10. Debugging is... u time-consuming u reveals one ’ s own errors, so is … –often inefficiently done, so … »AVOID IT as much as possible u “ Short cuts ” in design & coding are false economy: –take extreme care in design –struggle for highest legibility of code u In maintenance: –if something works, don ’ t tamper.

11. Effective debugging (1) u Simplify it! –unit test any fragment that you feel might have a bug, no matter how small, & debug; –size modules so they probably have tiny numbers of bugs, and debug; –system test for small new combinations, and debug. u So then you only need to deal with a tiny number of bugs at a time.

12. Effective debugging (2) u Design every verification test to trap as many classes of bug as possible –avoids messy test-then-debug-then-test- then-debug … cycles

13. When there is a bug... u...you often need to improvise a “ pursuit test ” targeted on chasing the bug - –obvious, but often overlooked, especially by beginners. u … follow the logic of the bug back towards it ’ s origin ( “ back-deduction ” ) - –also obvious but often overlooked, especially by beginners.

14. Where is the bug? u Locate the region of the program that the bug is in - –e.g. in response to a mysteriously corrupted variable - what/where is corrupting it? –“ wolf fence ” tactic »(Also called “ divide and conquer ” ).

15. Having put in debugging code u It was expensive! keep it! u Comment it out: //... some debug code... u Eliminate it by conditional compilation: final boolean DEBUGGING = False; … if (DEBUGGING) { … some debug code … }

16. Dynamic debuggers... u … are now common extras for compilers and IDEs: –you can set “ break-points ”, then execute to the first break-point reached; –you can restart from a break-point till the next is reached; –you can “ single-step ” ; –you can monitor the values of variables; –you can change the values of variables; –...

17. Aptitudes for debugging u Ability to spot obscure patterns; u Ability to separate interleaved patterns; u Meticulousness; u Tenacity; u Judgement; u Intuition; u LUCK!!!

18. Maintenance  expense & risk  corrective, innovative & perfective maintenance  rate of discovery of bugs  aptitudes for maintenance

19. Maintenance is expensive  Most Industry reports say between 60% and 90% of total programming effort is maintenance;  quite where in that range seems to correlate to various sections of the industry;  high end => long life with regular need for functional change;  also varies with the effort that went into making the software maintainable and keeping it so!

20. Maintenance is risky  You are changing something beyond it ’ s original design …  … will the design stand up to the changes?  MORAL: designs should have flexibility build in.

21. Kinds of maintenance  Corrective - is really debugging, done late (the user reported the bug)  Innovative - adding new capabilities, perhaps updating old ones  Perfective - internal improvement to correct software not needing any innovation or update.

22. Corrective maintenance  Fixing errors (or other severe deficiencies) in a version of the software being used by customers;  therefore much more fraught than “ normal ” debugging.  Often –either not obvious where (in spec/design/ code) it originates; –or blatantly a result of wrong requirements or mis-specification!

23. Innovative maintenance  The requirements have changed...  … maybe new facilities are needed/ desired;  … maybe the real-world situation has changed;  … maybe there ’ s a perception that the real-world situation could be modelled better.

24. Perfective maintenance  Improving perceived quality, or...  Improving actual (internal) quality, or …  Increasing capacity, or …  Increasing speed, or...

25. Rate of discovery of bugs

31. Staffing of maintenance  … perhaps because their managers told them to repair the old one …  MORALS: –keep the team stable; –manage it thoughtfully.

32. After this lecture (1) u STRATEGIES FOR DEBUGGING: –avoid; –simplify. u TACTICS: –back-deduce (location by history); –wolf-fence (location by geography). u TOOLS: –dynamic debuggers. –(read the manual for others in the compiler or IDE).

33. After this lecture (2)  Build for maintainability;  Maintain thoughtfully;  Staff issues for maintainability – choose well!  This is another issue for long-term thought about your experience, and what you observe of other people ’ s experience.

34. u © C Lester 1997-2014

35. Revisiting “ risks of maintenance ”