Teaching Software Maintenance using .NET and Rotor

1. Teaching Software Maintenance using .NET and Rotor Leonardo Bottaci University of Hull, Hull, UK

2. .NET MSc in Distributed Systems Development • Aims • Teach the knowledge and skills to develop and maintain large scale systems software. • Modules • C# • .NET Framework • Software maintenance • Distributed systems programming • Virtual machine architectures • Trustworthy computing

3. Software Maintenance Module • Aims • The management and practice of software systems maintenance • Difficulties • No general systematic organised body of knowledge, there is no theory. • Little enthusiasm or glamour, programmers feel constrained by legacy and commercial constraints.

4. Student background • Degree in computer science or equivalent experience. • No student very experienced in • object oriented languages • language implementation • runtime systems Relevant for the practical work

5. Software Maintenance Module • Teaching strategy • Student centred learning through practical experience. • Laboratory practical work 2 supervised hours per week, 1 lecture per week. • Students may also ask me questions outside those times.

6. Software maintenance management: 1 • Why manage • Commercial constraints • Process models • IEEE standard • Matching process models to different types of organisation and situations • Legacy systems • Safety critical • Rapid applications development

7. Software maintenance management: 2 • Configuration management • Requirements driven • Tools • Code modified in practical work managed using VSS • Cost estimation • Formal, organisational level • Metrics, statistical regression • Less formal, individual level

8. Software maintenance management: 3 • Maintenance through reuse • All levels, from ideas to code • Program design • Program objects should model stable application objects • Functionality is usually not stable • Seminar discussion of examples from JSD .NET contribution to reuse covered in another module

9. Maintenance practice • Course practical work, 100% of credit • Objective: Learn how to maintain software • Context: Modification of the jscript compiler in Rotor to produce a program dependency graph • Emphasis on the learning objective • Student background varies.

10. Acquire experience Learn from experience Learning Strategy • Student centred learning through practical experience. • Practice alone reinforces current behaviour.

11. Assessing learning In order of importance: • Evidence of learning in the logbook • Student contribution to seminars and lab discussions • Assessment of modified software Safe environment for sensible risk taking

12. Why use Rotor? • Code contains very few comments • Code sufficiently readable for students to make progress in the relatively short time allocated for a module • Students motivated by “real” code

13. Initial lab exercises • Read the Rotor documentation and build the system • Try the jscript compiler. • Find, compile and execute a sample jscript program • Modify the jscript compiler by adding a print message, rebuild and recompile jscript sample.

14. Maintenance task stage 1 • Modify the jscript compiler to output the abstract syntax tree (useful in stage 2 of the practical work.) • Students given a short review of compiler operation, scanner, parser, code generator • No other information

15. Student reaction to task • Many questions, I answer very few • The learning more important than the task • Mantra, logbook • Some students frustrated, fear of losing marks, try to renegotiate task • Leads to discussion on the role of risk • need to manage it • university environment relatively safe.

16. Progress on stage 1 • A few students modify scanner to print characters and tokens, boosts confidence • Students working individually but ideas spread fast in the lab • Students still cannot find the point at which the parser returns an abstract syntax tree • Do not know C# • Insufficient analysis of code, tools • cordbg used but not effectively

17. Code reading skills • Code reading should be goal-directed • Reading to see what is there • Trying to understand each line • What are you expecting to find? • Formulate an hypothesis • Read the code to confirm or disprove it.

18. Code reading illustration: 1 What is the following code doing? while (...) { ... } Hypothesise the most popular uses of a loop in general and look at code for evidence.

19. Code reading illustration: 2 while (...) { sum := sum + a[i]; ... } Array accumulation a likely hypothesis

20. Code reading illustration: 3 while (...) { sum := sum + a[i]; if (...) ... else ... ... } Hypotheses to explain the conditional inside a loop

21. Code reading illustration: 4 while (...) { sum := sum + a[i]; if (...) done := 1; else ... ... } Flag, is it for early termination?

22. Code reading illustration: 5 while (i < 9 and done = 0) { sum := sum + a[i]; if (...) done := 1; else ... ... }

23. Maintenance as goal-directed activity • Debugging should be goal-directed • Ineffective experience with cordbg • Students claim they lack knowledge to formulate goals • Then acquisition of knowledge is goal • Muted student response • Implications too disturbing

24. AST located, how to print? • Lack of experience in object-oriented programming • Mention ToString() after students admit they have found no elegant solution • Still reluctant • Too ad hoc • Too many classes to modify • Place students into teams, do not mix ability.

25. Students recognise lack of knowledge in object orientation • Students uncomfortable with lack of design knowledge • Students now told to find out about object oriented compilers and object oriented design in general • Use literature, user groups, individuals, code itself • Some students want to learn too much, others too little.

26. Design patterns • Students prompted to research design patterns • Have just met these in the C# module • Quickly find relevant material on the template pattern and visitor pattern

27. Maintenance task stage 2 • Identify through a systematic enumeration the occurrences of arithmetic and logical operators in a jscript program if (i + j > 0) j = j + 1; else i = i - 1; print(“i = “ + i + “, j = “ + j);

28. Maintenance task stage 2 • Given a program and an operator occurrence id, generate a mutant program that differs from the given program only at the occurrence of the operator if (i - j > 0) //ORIGINALLY i + j j = j + 1; else i = i - 1; print(“i = “ + i + “, j = “ + j);

29. Maintenance planning • Some students suggest modifying the IL • Seen as a quick fix • Two implementation plans • Modify ast • Modify IL • How to evaluate?

30. Detailed plan • For each proposal • Plan the implementation steps • Assumptions that need to be tested • Decision tree discussion • Cost estimates in hours

31. Cost estimation: individual • Necessary and frequent activity, usually implicit • In practical work, students encouraged to make cost estimation explicit so that it can be scrutinised and improved. • Calculate estimate, record in logbook • When task complete, review estimate • Note how it can be improved

32. Misguided judgement • Enthusiasm for the IL modification option based on difficulty with ast. • Understanding of requirements conveniently vague. • Drip feed reminders about the requirements to the extent that both options remain in contention.

33. Implementation options evaluated • IL modification is seen correctly as an easy way to solve 95% of the problem • Remaining 5% hard • Discussion about the language independent generation of mutant programs • Students return to modification of the ast

34. Acquire experience Learn from experience Practical exercise: outcomes • Learn what is required to maintain software. • Learn how to improve one’s knowledge and skill. • Lazy practice makes permanent • Goal directed practice makes better • Motivation and self confidence. • Requires a rational assessment of one’s abilities

35. Teaching method • Opportunistic and improvisational • Respond to issues raised by students • Easier with small group of students • Course notes are structured • Use white board, few slides • Interact with students to provoke a response

36. Course materials • Lecture notes • Practical exercise • Tutor’s notes • Hints, Modifications to jscript compiler • Debugging tutorial • C# compiler, MSIL, fjit Contact email L.Bottaci at hull.ac.uk