1 / 36

Teaching Software Maintenance using .NET and Rotor

Teaching Software Maintenance using .NET and Rotor. Leonardo Bottaci University of Hull, Hull, UK. .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

harris
Download Presentation

Teaching Software Maintenance using .NET and Rotor

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 www2.dcs.hull.ac.uk/people/cssdjg/MSRAD • Lecture notes • Practical exercise • Tutor’s notes • Hints, Modifications to jscript compiler • Debugging tutorial • C# compiler, MSIL, fjit Contact email L.Bottaci at dcs.hull.ac.uk

More Related