Program understanding

1. Program understanding Prof. Robertas Damaševičiusrobertas.damasevicius@ktu.lt Prof. Vytautas Štuikys Kaunas University of Technology Program understanding

2. Content • Program comprehension / understanding • Role of program understanding in maintenance • Program comprehension: challenges, factors, techniques • Program comprehension (cognitive) models • Software inspection Program understanding

3. Content • Program comprehension / understanding • Role of program understanding in maintenance • Program comprehension: challenges, factors, techniques • Program comprehension (cognitive) models • Software inspection Program understanding

4. Program comprehension • Program comprehension is the study of how software engineers understand programs. • Program comprehension is needed for: • Debugging • Code inspection • Test case design • Re-documentation • Design recovery • Code revisions Program Comprehension

5. Program comprehension process • Use of existing knowledge to acquire new knowledge about a program • Existing knowledge: • Programming languages • Computing environment • Programming principles • Architectural models • Possible algorithms and solution approaches • Domain-specific information • Any previous knowledge about the code • New knowledge: • Code functionality • Architecture • Algorithm implementation details • Control flow • Data flow Program Comprehension

6. Aims of program understanding • Ultimate purpose of comprehending programs is to be able successfully to implement requested changes. • This entails acquiring information about certain aspects of the software system such as • problem domain, • execution effect, • cause-effect relation, • product environment, • relation and decision-support features of the software Program understanding

7. Program understanding (1) • Prior to implementing change, it is essential to understand SW as a whole and the programs affected by the change in particular • During maintenance, this involves: • having a general knowledge of what the software system does andhow it relates to its environment; • identifying where in the system changes are to be effected; and • having an in-depth knowledge of how the parts to be corrected or modified work Program understanding

8. Program understanding (2) • Program understanding consumes a significant proportion of maintenance effort and resources • Hewlett Packard estimates reading code costs $200 million a year • Half of the total effort on change is used up in understanding • Cost increases in the event of • a programmer maintaining programs written by someone else • inaccurate, out-of-date or even non-existent documentation • deterioration in program structure due to quick fixes Program understanding

9. Program comprehension model Program understanding

10. Comprehension process • Comprehension is a transformation from the programming domain to the problem domain involving the reconstruction of • knowledge about these domains (including any intermediate domains) and • the relationship between them. Program understanding

11. Information required for program comprehension (1) • Knowledge of Problem domain • Helps the management team in selecting appropriate resources i.e. expertise skills, algorithms, tools, techniques • Execution effect • Abstract level representation of the system’s behavior for a specific set of inputs. • Purpose is to verify whether or not the requested change is implemented and expected outcomes are achieved. Program understanding

12. Information required for program comprehension (2) • Cause-effect relationship • Purpose is to find out the effects of intended change on other parts of system, it also helps in predicting potential ripple effects. • To find out the nature of dependencies in a system, because whether the change is small or large the dependencies always produce many difficulties and errors • Product-environment relationship • Purpose is to find out all the external factors (business rules, government regulations, operating platform) that could have affect on a system • Decision support features • Features (complexity, maintainability) that help to make decisions about alternative analysis, budgeting and resource allocations Program understanding

13. Program comprehension strategies • Top-down • Mapping from programming domain to problem domain • Bottom-up • Recognition of recurring patterns in code to produce high-level semantic structures • Opportunistic • Top-down and bottom-down methods are used as necessary • information is assimilated Program understanding

14. Top-down comprehension Program understanding

15. Bottom-up comprehension process Program understanding

16. Bottom-up comprehension • Programmer successively recognises patterns in the program • These are iteratively grouped into high-level, semantically more meaningful structures • High-level structures are chunked together into even bigger structures in a repetitive bottom-up fashion until the program is understood Program understanding

17. Evaluation • The main weaknesses of both the top-down and bottom-up comprehension strategies are: • failure to take into consideration the contribution that other factors such as the available support tools make to understanding; and • the fact that the process of understanding a program rarely takes place in such a well-defined fashion as these models portray. • Programmers tend to take advantage of any clues they come across in an opportunistic way Program understanding

18. Opportunistic model • Comprehension depends on three key and complementary features: • Knowledge base: the expertise and background knowledge that the maintainer brings to the understanding task. • Mental model: the programmer's current understanding of the target program • Assimilation process: procedure used to obtain information from various sources such as source code and system documentation Program understanding

19. Taxonomy of program comprehension factors Program understanding

20. Content • Program comprehension / understanding • Role of program understanding in maintenance • Program comprehension: challenges, factors, techniques • Program comprehension (cognitive) models • Software inspection Program understanding

21. Maintenance & Understanding • Program and system comprehension are vital and expensive parts of software maintenance process • “Thereisnohigh-qualitysubstitute for experience when it comes to understanding and maintaining a system, as existing methods and tools are not effective enough and documentation tends to be unreliable”* * Survey: C. Tjortjis and P.J. Layzell, "Expert Maintainers’ Strategies and Needs when Understanding Software: A Qualitative Empirical Study", Proc. IEEE 8th Asia-Pacific Software Engineering Conf. (APSEC 2001), IEEE Comp. Soc. Press, 2001, pp. 281-287. Program understanding

22. Maintenance practices and requirements related to understanding • To facilitate program comprehension system representations (overviews, abstractions, diagrams, module interrelationships) must be to be derived (semi-)automatically • High level abstractions of subsystems with related functionality and interrelationships, must be visualised, recorded and referenced for future use • Standardised information of team member communications regarding a software system must be captured and stored • Capturing knowledge regarding past modifications by extracting information from comments and relating this to known functionality of code emerges to be of great importance • Partial program comprehension has to be balanced against the risk of failure in completing a maintenance task Program understanding

23. Maintenance tasks & activities requiring understanding Source: Program Understanding: A Survey, A. von Mayrhauser and A. M. Vans Technical Report CS-94-120, 1994. Program understanding

24. Taxonomy of components for program comprehension Source: Software Comprehension – Integrating Program Analysis and Software Visualization, Welf L¨owe Morgan Ericsson Jonas Lundberg Thomas Panas Program understanding

25. Content • Program comprehension / understanding • Role of program understanding in maintenance • Program comprehension: challenges, factors, techniques • Program comprehension (cognitive) models • Software inspection Program understanding

26. Comprehension challenges (1) • Stupid use of high intelligence (Tricky Code) • very hard to understand by other person, which later on causes problems in comprehension • Different programming Styles • large software program is co-written by a group of programmers having different programming skill and experience. • In result the developed product have a combination of programming styles followed. • These sorts of programs are very difficult to understand Program understanding

27. Comprehension challenges (3) • Poor Naming convention • use of meaningless, inconsistent and poor naming conventions may be a heavy burden or source of lack of comprehension • name should also have the ability to define the concept clearly. • Lack of Domain words in Software Vocabulary • Use of domain words in source code, documentation and user manuals is considered a good practice • good developer usually try to embed this domain information in identifiers and comments because in case of unavailability of sufficient documentation it is very helpful in improving the code understandability. • Conflict on Software Vocabulary • comprehension of program identifier depends upon their ability to describe the domain concept • wrong selection of descriptive terms corresponding to domain concept (misconception) is hurdle in comprehension Program understanding

28. Comprehension challenges (3) • Program representation • Grouping related statements and modules might smoother the comprehension. • Good visual layout makes the code more understandable and modifiable in the absence of author. • Insufficient comments • lack of comments are the major causes to increase maintenance cost and reduce the comprehension. • Deep-nesting / Deep-Inheritance tree • Undue usage of deep-nesting is one of the major causes in making code comprehension unmanageable • Few people can understand deep-nesting which goes more than 3 levels Program understanding

29. Comprehension challenges (4) • Concept location • in case of a large complex program it is neither possible nor cost effective way to read all the code from the scratch. • maintainer mostly use the related queries to find the desired part of the code • Difference between natural language description of change request and program vocabulary for its implementation is hindrance • Code duplication (“bad smells in code”) • writing the code from the beginning is very hard as compared to code duplication but software having that problem is often considered bad • programmers feel it easier and more reliable to use pretested code • makes maintenance and evolution more difficult and expensive. • Identification of dead code • one of the major problems in understanding code. Program understanding

30. Comprehension techniques • Reading by step-wise abstraction • Determine the function of critical subroutines, work through the program hierarchy until the function of the program is determined. • Checklist-based reading • Readers are given a checklist to focus their attention on particular issues within the document. • Different readers were given different checklists, therefore each reader would concentrate on different aspects of the document. • Defect-based reading • Defects are categorized and characterized (e.g., data type inconsistency, incorrect functionality, missing functionality, etc.) • A set of steps (a scenario) is then developed for each defect class to guide the reader to find those defects. • Perspective-based reading • Similar to defect-based reading, but instead of different defect classes, readers have different roles (tester, designer and user) to guide them in reading. Program Comprehension

31. Factors improving understandability (1) • Expertise • Well grounded knowledge of problem domain, problem solving and programming languages make the program comprehension easier • Syntax highlighting • commonly used to highlight different code constructs by using different colors and fonts for different identifiers • may be used with combination of other strategies to improve the concept/concern location techniques. • Cross referencing • provide the linkage between identifier’s definition and its use at different places in the source code • cross referencing support between code segments written in different languages can make the understandability of code easier Program understanding

32. Factors improving understandability (2) • Call graphs • represent inter procedural communication in a source code. • Static call graphs show the potential calls • dynamic call graphs show the calls that can occur on a particular execution of a program • Comments and Annotations • virtually added comments that originally don’t exist in the code • don’t require write access to add them in source code. • Annotation helps the maintainer to comprehend the code easily. • programmers can add as many comments as they want without flooding the code Program understanding

33. Factors improving understandability (3) • Program Slicing • effective technique for narrowing down the concentration on the responsible part of the program • used in finding the cause-effect relationship. • makes it easier in finding the cause of the error by slicing down the program in small related pieces. • Ripple Analysis • to locate that part of code that might be affected by implementing a certain change. • = forward program slicing • helpful in finding the extent and nature of dependencies among different code segments • Program Decomposition • break down large program into significant small modules easier to comprehend Program understanding

34. Comprehension efectiveness • Aside from the issue of how comprehension occurs, comprehension performance and effectiveness are affected by many factors: • Maintainer characteristics • Program characteristics • Task characteristics Program Comprehension

35. Maintainer characteristics • Familiarity with code base • Application domain knowledge • Programming language knowledge • Programming expertise • Tool expertise • Individual differences Program Comprehension

36. Program characteristics • Application domain • Programming domain • Quality of problem to be understood • Program size and complexity • Availability and accuracy of documentation Program Comprehension

37. Task characteristics • Task type • Experimental: recall, modification • Perfective, corrective, adaptive, reuse, extension. • Task size and complexity • Time constraints • Environmental factors Program Comprehension

38. Content • Program comprehension / understanding • Role of program understanding in maintenance • Program comprehension: challenges, factors, techniques • Program comprehension (cognitive) models • Software inspection Program understanding

39. Models • Mental models • Internal working representation of the software under consideration. • Cognitive models • Theories of the processes by which software engineers arrive at a mental model. CognitiveModel Mental Model Program Program Comprehension

40. Mental models • Program comprehension is a process that uses existing knowledge to acquire new knowledge that ultimately meets the goals of a code cognition task. • In the process we reference both existing and newly acquired knowledge to build a mental model of how the software works Program understanding

41. Mental models • Static elements • Text structure knowledge • Microstructure • Chunks (macrostructure) • Plans (objects) • Hypotheses • Dynamic elements • Strategies (chunking and cross-referencing) • Supporting elements • Beacons • Rules of discourse Program Comprehension

42. Elements of mental models: static • Structure knowledge includes the program text and its structure. • Is built through experience and is stored in long-term memory. • Chunks are knowledge structures consisting of various levels of abstractions of text structures. • correspond to control-flow organization of the program text. • Plans are elements of knowledge that support the development and validation of expectations, interpretations, inferencing, and keep the attention of the comprehender • include causal knowledge about the information flow and relationships between parts of programs. • Programming plans can be high-level, low level, or intermediate level programming concepts. • Includes roles for data objects, operations, tests, other plans, and constraints • Domain plans incorporate all knowledge about the problem area except for code and low-level algorithms. Program understanding

43. Text structure • The program text and its structure • Control structure: iterations, sequences, conditional constructs • Variable definitions • Calling hierarchies • Parameter definitions • Microstructure – actual program statements and their relationships. Program Comprehension

44. Chunks • Macrostructure • Contain various levels of text structure abstractions • Identified by a descriptive label. • Can be composed into higher level chunks. Program Comprehension

45. Plans (objects) • Knowledge elements for developing and validating expectations, interpretations, and inferences. • Include causal knowledge about information flow and relationships between parts of a program. • Programming plans • Based on programming concepts. • Low level: iteration and conditional code segments. • Intermediate level: searching, sorting, summing algorithms; linked lists and trees. • High level • Domain plans • All knowledge about the problem area. • Examples: problem domain objects, system environment, domain-specific solutions and architectures. Program Comprehension

46. Elements of mental models: dynamic • Strategy guides the sequence of actions while following a plan to reach a particular goal • reading and understanding every single line of code while building a mental representation at higher levels of abstraction. • Understanding mechanisms that produce information • Chunking creates new higher-level-abstraction structures from chunks of lower-level structures. • Cross-referencing relates different levels of abstraction, by mapping program parts to functional descriptions. • Actions classify programmer activities, both implicit and explicit during maintenance task • Episodes are composed of sequences of actions and aggregate to form higher-level processes • Processes, episodes, actions, and strategies are the dynamic components of mental model construction Program understanding

47. Strategies • Guide the sequence of actions while following a plan to reach a goal. • Match programming plans to code. • Shallow reasoning – do not perform in-depth analysis; stop upon recognition of familiar idioms and programming plans. • Deep reasoning – perform detailed analysis. • Mechanisms for understanding • Chunking • Cross-referencing Program Comprehension

48. Cross-referencing • Map program parts to functional descriptions temp = a; a = b; b = temp; swap for (i=0; i<size; i++) if (array[i]==target) return true; sequential search Program Comprehension

49. Supporting elements • Beacons • Cues that index into existing knowledge. • A swap routine can be a beacon for a sorting function. • Experienced programmers recognize beacons much faster than novice programmers. • Used commonly in top-down comprehension. • Rules of discourse • Rules that specify programming conventions. • Examples: coding standards, algorithm implementations, expected use of data structures. Program Comprehension

50. Cognitive models • Letovsky • Shneiderman and Mayer • Brooks • Soloway, Adelson and Ehrlich • Pennington • Mayrhauser and Vans (Integrated meta-model) Program Comprehension