Maintaining large software systems

Maintaining large software systems Dr L Bottaci Department of Computer Science University of Hull, Hull, UK

Preface: Module • 20 Credits • Syllabus topics • Software maintenance practice • Debugging • Software maintenance management

Preface: Resources • Course Materials • Check undergraduate web site for this module. • Lecture slides • Make your own notes • Course notes • ACW description • Read notice board and email

Preface: ACW • Assessed course work • Worth 100% of module assessment • Software maintenance task • Work individually • Assessed on what you learn, as well as product • ACW specification, on web page, will have details

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

Preface: Reading • Books • Few books specifically on Maintenance • See references in course notes • Consult any good software engineering book, e.g. • Pressman, Software Engineering, McGraw Hill, 2000

What is Software Maintenance? • Software does not change • But the operating environment and the world does. • Fix bugs • Adapt to new operating environment • Adapt to new requirements

Maintenance as software engineering • 50% (by cost) of maintenance is done to adapt to changed requirements • 80% (by cost) of software engineering is software maintenance

Maintenance costs • Cost of change increases with time after design • Reduce cost by planning for long term maintenance • Planning and designing for maintenance increases development cost • Commercial requirements important, balance with engineering requirements

Syllabus topic 1: Software maintenance practice • Software maintenance is not a theoretical subject • Learning is change • Learn by doing • Learn by thinking

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

Maintenance task: Brief intro • Modify the jscript compiler (part of the .NET sscli) to implement new requirements.

Maintenance task overview • Students given a short review of compiler operation, scanner, parser, code generator • Role of abstract syntax tree • No other information – it is important that you learn

Why use Rotor? • Code large enough that it cannot be understood in its entirety • Code contains very few comments • Sufficiently readable for students to make progress in the relatively short time allocated for a module • It is “real” code

Finding out about the system • Look for information about systems of the type you are examining • If it is an object-oriented compiler, look for information about object-oriented compilers. • Do not overlook journal articles and books. There is a lag between ideas appearing in the literature and their take up in commercial products so it may be necessary to search the literature that was published several years before the system was built.

Finding out about the system • Look for documentation, in the source code files themselves or in associated documentation files. • Check if the producer of the code has documentation in addition to whatever is in the distribution you are examining. • Has anyone else worked or looked at the code, do they have documentation or information? Can they be contacted?

Finding out about the system • Can static analysis tools be useful? • Very simple and useful facility is the ability to search a set of files for a given string e.g. the grep tool in UNIX, find, findstr in Windows. Similar tool in VS Ctrl-Shft-F • More sophisticated tools later

Finding out about the system • Can automatic documentation tools be useful? • E.g. it is often useful to know which functions call a given function. A complete description is known as the call graph. • Other kinds of graph - class hierarchies. • In general, automatic documentation tools produce cross referenced lists • Example documentation tool is doxygen, available on the web.

Finding out about the system • Ultimately, read the code.

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.

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.

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

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

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

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

Initial lab exercises: 1 • Read the Rotor (sscli) documentation • Download and build the system • Try the jscript compiler. • Find, compile and execute a sample jscript program • Test the system, save the log file to compare with future tests.

Initial lab exercises: 2 • Modify the jscript compiler to print a message before it compiles a file • Rebuild compiler and recompile jscript sample. • Rerun tests and check output with previous run of tests.

Further lab exercises • Print each character in the file compiled by the jscript compiler. • Print each token recognised by the jscript compiler.

Practical Exercise • Control moves to next statement in program unless there is a conditional statement or transfer of control statement. • Conditional statement is if-statement, switch-statement, while-statement and for-statement. • Transfer of control statement is return, break, continue. • Task is to modify the compiler so that it produces a warning when it detects that a statement is unreachable, i.e. cannot be executed.

Practical Exercise: E.g. for (i = 0; i < n; i++) { x = y; break; y = 0; }

Practical Exercise: E.g. switch (e) { case 1: x = 0; break; x = 1; case 2; x = 1; break; default: x = 2; }

Practical Exercise: E.g. if (true) { x = 0; } else { x = 1; }

Practical Exercise: stages • Continue and extend the examples given to produce a list of test cases. • Implementation plan with algorithm • When above two checked, proceed with implementation

Example implementation plan:textual substitution • Read jscript program source code, as a file of text, looking for keywords such as ‘return’, ‘break’, etc. • Identify statements in jscript program source code by looking for substrings terminating in a semicolon,

Example implementation plan:textual substitution, evaluation • Read jscript program source code, as a file of text, looking for keywords such as ‘return’, ‘break’, etc. • jsscanner does this, plus point for plan • Identify statements in jscript program source code by looking for substrings terminating in a semicolon, • jsparser does this, plus point for plan

Example implementation plan:examine the MSIL • Examine the MSIL produced by the jscript compiler to identify unreachable code. • Could start by examining MISL for simple source code examples given above.

Example implementation plan:transform the AST • Examine the AST produced by the jscript compiler to identify transfer of control statements, etc.

Example implementation plan:transform the AST, evaluation • Examine the AST produced by the jscript compiler to identify control transfer statements. • Traverse AST looking for a type of AST node • Need a ‘foreach-stmt’ to iterate over AST

Cost estimation: individual • Necessary and frequent activity, usually implicit • In practical work, cost estimation should be explicit so that it can be scrutinised and improved. • Calculate estimate, record in logbook • When estimate expires, review estimate • Note how it can be improved

Tools for navigating code • Tools are available for extracting information from code. • Most simple tools search files for strings, e.g. in VS Ctrl-Shft-F • Most sophisticated tools called reverse engineering

Tools for navigating code • Method call relationships for all methods is known as the call graph • Can be constructed by a tool. • Other graphs includes class hierarchies. • The sort of documentation produced by automatic documentation tools consists largely of cross referenced lists. • An example of such a documentation tool is doxygen, available on the web

Tools for navigating code • To answer more sophisticated queries, analysis of the program dependency graph is required. • To use these tools it is necessary to understand the program dependency graph. • The program dependency graph is actually a collection of graphs dealing with control and data dependency

Example program • 1. i := 0; • 2. sum := 0; • 3. done := 0; • 4. while (i < 9 and done = 0) • 5. sum := sum + a[i]; • 6. if (sum >= 8) • 7. done := 1; • else • 8. i := i + 1; • 9. print(sum);

Control Flow • The nodes of the graphs are the statements in a program or collections of statements known as regions. • A region may correspond to a basic block. • The conditional nodes of a control flow graph are distinguished (typically shown as squares) from the statement nodes (typically shown as ellipses) • Directed edges are the possible transitions between statements or basic blocks during program execution. • The conditional transitions are associated with a branch predicate (labelled T or F). • There is a distinguished start node and a distinguished exit node.

Control Dependency • The control dependency graph is derived from the control flow graph. • When node Y is control dependent on node X, taking one branch at X will ensure that Y is reached, Y may or may not be reached if the other branch is taken. • As an example, consider nodes 4 and 5 in the control flow graph of previous program.

Control Dependency: example • There is a path from node 4 to node 5. • Taking the true branch at 4 ensures that 5 is reached. This is not true if the other branch it taken. • Node 5 is said to be control dependent of node 4. • In contrast, node 9 is not control dependent on node 4 since either branch at node 4 will always lead to node 9.

Data Dependency • Data dependency exists between two nodes if the meaning of the program may change when the order of the two nodes is reversed. • Different kinds of data dependency. • Flow dependency • Def-order dependency

Flow Dependency • Flow dependency exists from X to Y if a variable v is defined (the value of v is set) at X and used at Y, and there is a path in the control flow graph from X to Y without an intervening definition of v. • In other words, the definition at X may directly determine the value of v at Y.

Def-order Dependency • Def-order dependency exists from X to Y if • both nodes define the same variable v, • X and Y are in the same branch of any conditional that contains both X and Y, • there is a node Z that is flow dependent on X and Y, and • X is to the left of Y in the abstract syntax tree.

Def-order Dependency: example • An example of def-order dependency is present between node 3 and node 7 in the previous example program

Maintaining large software systems