1 / 108

Program understanding

Program understanding. Prof. Robertas Damaševičius robertas.damaseviciu s @ktu.lt Prof. Vytautas Štuikys Kaunas University of Technology. Content. Program comprehension / understanding Role of program understanding in maintenance Program comprehension: challenges, factors, techniques

van
Download Presentation

Program understanding

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. 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

More Related