Program understanding: What programmers really want

671 views
610 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
671
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Program understanding: What programmers really want

  1. 1. Program Understanding:<br />What Programmers Really Want<br />Einar W. Høst<br />May 5th 2011<br />
  2. 2. Description<br />Introduction<br />How Analysis <br />can help<br />Understanding<br />Understanding Program Understanding<br />Agenda<br />Agenda<br />Evaluation<br />Examples<br />ConsiderLimitationsofCurrentTools<br />Look at some<br />well-known Analyses<br />
  3. 3. Program <br />Analysis<br />Program <br />Understanding<br />Program <br />Analysis<br />
  4. 4. Why is program understanding important?<br />
  5. 5. It’s what programmers do!<br />
  6. 6. “To program is to understand”<br /> - Kristen Nygaard<br />
  7. 7. Why is program understanding <br />hard?<br />
  8. 8. Size.<br />
  9. 9. Complexity.<br />
  10. 10. Heterogenity.<br />
  11. 11. Side-effects.<br />
  12. 12. The concept assignment problem.<br />
  13. 13. Intangibility.<br />
  14. 14. =><br />
  15. 15. Disorientation.<br />
  16. 16. “Few are the programmers who can explain their code well enough so that reading it is not incredibly frustrating.”<br /> - JefRaskin<br />
  17. 17. How can program analysis help?<br />
  18. 18. Program Understanding<br />?<br />$s.=($f=$A<br />RGV[$_%2]<br />)x(substr$s<br />,$_,1or$f)<br />for0..500;<br />
  19. 19. Program Understanding<br />!<br />$s.=($f=$A<br />RGV[$_%2]<br />)x(substr$s<br />,$_,1or$f)<br />for0..500;<br />Through themagic lens of a Tool<br />
  20. 20. What do programmers want?<br />
  21. 21. ”Helpme in finding<br />whatneeds to be changed...<br />
  22. 22. ...make thechange...<br />
  23. 23. ...and getthe !$&?/% out!”<br />
  24. 24. Just-in-time program understanding.<br />
  25. 25. Complete understanding is<br /><ul><li>Not realistic
  26. 26. Not cost-effective
  27. 27. Not necessary</li></li></ul><li>Understand the program <br />well enough to<br />implement a new feature <br />
  28. 28. Understand the program <br />well enough to<br />fix a bug<br />
  29. 29. Understand the program <br />well enough to<br />improveperformance<br />
  30. 30. Without change, <br />there is no need for understanding!<br />
  31. 31. Program understanding<br /><ul><li> Understanding execution behavior
  32. 32. Understanding control flow
  33. 33. Understanding data flow
  34. 34. Understanding dependencies
  35. 35. Understanding side-effects
  36. 36. Understanding change impact
  37. 37. Reasoning about design</li></ul>at the code level<br />
  38. 38. Program understanding<br /><ul><li> Understanding what is relevant</li></ul>at the task level<br />
  39. 39. Comprehension strategies<br />
  40. 40. Comprehension strategies<br />Reconstructknowledgeaboutthe program domain and mapping it to thesourcecode.<br />Top-down<br />
  41. 41. Comprehension strategies<br />Readcodestatements and mentallygroupthesestatementsintohigherlevelabstractions.<br />Bottom-up<br />
  42. 42. Comprehension strategies<br />Readcode in detail,<br />followcontrolflow,<br />gain global understanding.<br />Systematic<br />
  43. 43. Comprehension strategies<br />Scancode, looking for cluesindicatingrelevance to thetask at hand.<br />Opportunistic<br />
  44. 44. Comprehension strategies<br />conjecture<br />question<br />search<br />read<br />Inquiries<br />
  45. 45. Comprehension strategies<br />Understanding is formed by switchingbetweendifferentstrategies as needed.<br />Integrated<br />
  46. 46. Tools for <br />program understanding<br />
  47. 47. Analysis<br />Presentation<br />
  48. 48. Analysis tools<br /><ul><li>Callgraphs
  49. 49. Program slicing
  50. 50. Feature location
  51. 51. Effectsofchange
  52. 52. Software metrics</li></li></ul><li>Presentation tools<br /><ul><li>Visualisations
  53. 53. Context-awareness</li></li></ul><li>What is a program?<br />
  54. 54. print”This is not a program.”<br />
  55. 55. print(”This is not a program.”)<br />
  56. 56. The program as<br />text<br />
  57. 57. The program as<br />binary<br />
  58. 58. The program as<br />versioned<br />
  59. 59. The program as<br />process<br />
  60. 60. The program ecosystem<br /><ul><li> Source code / Compiled binary
  61. 61. Execution environment (runtime)
  62. 62. Test suite
  63. 63. Version control system
  64. 64. Issue tracking system
  65. 65. Integrated development environment
  66. 66. The programmer
  67. 67. External sources</li></li></ul><li>What questions can we ask <br />about a program?<br />
  68. 68. Behavior-centric<br /><ul><li> What does this piece of code do?
  69. 69. What happens if I change this?
  70. 70. Where is this code used?
  71. 71. Which parts of the program are affected by change?</li></ul>Requires program code<br />
  72. 72. Evolution-centric<br /><ul><li> Who wrote this piece of code?
  73. 73. Who can help me understand this?
  74. 74. Why was this feature implemented this way?
  75. 75. What are the most bug-prone parts of the program?
  76. 76. Where do changes happen most often?</li></ul>Requires program history<br />
  77. 77. Interaction-centric<br /><ul><li> How was this piece of code written?
  78. 78. Whichtasksare hard to accomplish?
  79. 79. Which parts of the program are hard to change? </li></ul>Requires coding-session history<br />
  80. 80. What is program analysis?<br />
  81. 81. Traditional program analysis<br />All you need is code<br />All you need is code<br />All you need is code, code<br />Code is all you need<br />
  82. 82. Static<br />Dynamic<br />
  83. 83. Static<br />All possible executions<br />
  84. 84. Static<br />Sound<br />+<br />Conservative<br />
  85. 85. Static<br />Trades <br />precision <br />for <br />soundness<br />
  86. 86. Sample executions<br />Dynamic<br />
  87. 87. Efficient<br />+<br />Precise<br />Dynamic<br />
  88. 88. Trades completeness<br />for<br />efficiency<br />Dynamic<br />
  89. 89. Static<br />Synergy<br />Dynamic<br />
  90. 90. Program analysis for <br />program understanding<br />
  91. 91. Call graph construction<br />
  92. 92. Call graph construction<br />Show calling relationshipsbetween parts of a program.<br />Essential idea<br />
  93. 93. Call graph construction<br />f<br />h<br />main<br />g<br />Sample graph<br />
  94. 94. Call graph construction<br />The relationdescribingexactlythosecallsmade from oneentity to another in anypossibleexecutionofthe program.<br />The ideal call graph<br />
  95. 95. Call graph construction<br />Make the program seem less fragmented by showingthecontrolflow links between program parts.<br />Benefit<br />
  96. 96. Call graph construction<br />The graphbecomes<br />too large and complex<br />to be comprehensible.<br />Limitation<br />
  97. 97. Call graph construction<br />”The sightofgcc'scallgraph<br />frightened my students <br />so muchthattheyrequested<br />a differentproject”<br /> - ArunLakhotia<br />Limitation<br />
  98. 98.
  99. 99. Program slicing<br />
  100. 100. Program slicing<br />Find a reduced program exhibitingthe same behaviorofinterest as the full program.<br />Essential idea<br />
  101. 101. Program slicing<br />The reduced program is called a program slice.<br />
  102. 102. Program slicing<br />C = < x, V ><br />x : a statement in program P<br />V : a subsetof variables in P<br />Slicing criterion<br />
  103. 103. Criterion: <12, z><br />1begin<br />2read(x,y)<br />3total := 0.0<br />4sum := 0.0<br />5if x <= 1<br />6 then sum := y<br />7 else begin<br />8read(z)<br />9 total := x*y<br />10 end<br />11write(total, sum)<br />12 end.<br />1 begin<br />2read(x,y)<br />5 if x <= 1<br />6 then<br />7 else<br />8read(z)<br />12 end.<br />
  104. 104. Criterion: <12, x><br />1begin<br />2read(x,y)<br />3total := 0.0<br />4sum := 0.0<br />5if x <= 1<br />6 then sum := y<br />7 else begin<br />8read(z)<br />9 total := x*y<br />10 end<br />11write(total, sum)<br />12 end.<br />1 begin<br />2read(x,y)<br />12 end.<br />
  105. 105. Program slicing<br />Whatwouldthe program look like ifweassume an initial statesatisfyingC ?<br />Forward conditioning<br />
  106. 106. Program slicing<br />Deletesstatementsthatwill not be executed given the initial state.<br />Forward conditioning<br />
  107. 107. Program slicing<br />Whatwouldthe program look like ifweassume an eventual statesatisfyingC ?<br />Backward conditioning<br />
  108. 108. Program slicing<br />Deletesstatementswhichcannot lead to the eventual state.<br />Backward conditioning<br />
  109. 109. Program slicing<br />The reduced program<br />is smaller.<br />Benefit<br />
  110. 110. Program slicing<br />The reduced program<br />looks foreign.<br />Limitation<br />
  111. 111. Program slicing<br />Hard to integrateintotheprogrammer’sworkflow.<br />Limitation<br />
  112. 112. Concept analysis<br />
  113. 113. Concept analysis<br />Identifygroupingsofobjectsthat have commonattributes.<br />Essential idea<br />
  114. 114. Concept analysis<br />C = (O, A, R)<br />O Set of objects<br />A Set of attributes<br />R Relation R⊆O ×A<br />Formal context<br />
  115. 115. Concept analysis<br />σ(O) = {a∈A⎮∀o∈O : (o, a)∈R}<br />O Set of objects<br />A Set of attributes<br />R Relation R⊆O ×A<br />Common attributes<br />
  116. 116. Concept analysis<br />τ(A) = {o∈O⎮∀a∈A : (o, a)∈R}<br />O Set of objects<br />A Set of attributes<br />R Relation R⊆O ×A<br />Common objects<br />
  117. 117. Concept analysis<br />A pair (O, A) is a concept<br />if A = σ(O) and O = τ(A)<br />Definition of concept<br />
  118. 118. Concept analysis<br />O=> Subprograms<br />A=> Features<br />Feature location<br />
  119. 119. Concept analysis<br />(s, f) ⊆ R<br />if subprogram s is invoked <br />when feature f is invoked<br />Feature location<br />
  120. 120. Concept analysis<br />Identify parts ofthe program relevant for a feature.<br />Benefit<br />
  121. 121. Concept analysis<br />Recoveryofcomponents and generationofhigh-levelarchitectureviews.<br />Benefit<br />
  122. 122. Concept analysis<br />Imperfecthigh-leveldescriptions have limited application for concretetasks.<br />Limitation<br />
  123. 123. Concept analysis<br />Requireseffort from <br />the programmer, <br />withunclearbenefits.<br />Limitation<br />
  124. 124. Concept analysis<br />Hard to integrateintotheprogrammer’sworkflow.<br />Limitation<br />
  125. 125. Change impact analysis<br />
  126. 126. Change impact analysis<br />Identifythepotentialconsequencesof a program change.<br />Essential idea<br />
  127. 127. Change impact analysis<br />Estimatewhat must be modified to accomplish a changeofbehavior.<br />Essential idea<br />
  128. 128. Change impact analysis<br />Subtyping and dynamicdispatchmeansthatchangeimpactcan be <br />non-local and unexpected.<br />Challenges in OO languages<br />
  129. 129. Change impact analysis<br />Atomic changes<br />
  130. 130. Change impact analysis<br />Provide a boundaryaroundtheeffectsof a program edit.<br />Benefit<br />
  131. 131. Change impact analysis<br />Provideconfidencethat an editdoes not have unexpectedeffectsoutsidetheboundary.<br />Benefit<br />
  132. 132. Change impact analysis<br />Limited by theprecisionofthechangeimpactanalysis.<br />Limitation<br />
  133. 133. Change impact analysis<br />Still needassurancethatnounexpectedeffectsoccur in theimpacted part ofthe program.<br />Limitation<br />
  134. 134. Change impact analysis<br />Hard to integrateintotheprogrammer’sworkflow.<br />Limitation<br />
  135. 135. Program metrics<br />
  136. 136. Program metrics<br />Quantifyaspectsofthe program presumed to be relevant.<br />Essential idea<br />
  137. 137. Program metrics<br /><ul><li> Lines of code
  138. 138. Depth of inheritance tree
  139. 139. Internal cohesion
  140. 140. Coupling to other elements
  141. 141. Cyclomatic complexity
  142. 142. Halstead complexity
  143. 143. ...</li></ul>Code-centric metrics<br />
  144. 144. Program metrics<br /><ul><li> Test coverage
  145. 145. Bug density
  146. 146. Change rate
  147. 147. ...</li></ul>Other metrics<br />
  148. 148. Program metrics<br />Answer questions regarding<br />program quality.<br />Benefit<br />
  149. 149. Program metrics<br />Identify potential problem<br />areas in the program.<br />Benefit<br />
  150. 150. Program metrics<br />Metrics are indirect<br />indicators of quality.<br />Limitation<br />
  151. 151. Program metrics<br />Task-generating, <br />not task-solving.<br />Limitation<br />
  152. 152. Software visualisation<br />
  153. 153. Software visualisation<br />Avoidoverwhelmingthe programmer by compressinginformation and usinggraphics.<br />Goal<br />
  154. 154. Table lens<br />
  155. 155. Table lens<br />Zoom outthetable layout and display cells as pixel bars scaled and colored by data values<br />Idea<br />
  156. 156. Table lens<br />Example<br />
  157. 157. Table lens<br />Present a compactviewof software metrics for program elements.<br />Application<br />
  158. 158. Treemap<br />
  159. 159. Treemap<br />Display hierarchical data as nestedrectangles.<br />Idea<br />
  160. 160. Treemap<br />Example<br />
  161. 161. Treemap<br />Comparemetricvalues for various program elements.<br />Application<br />
  162. 162. Polymetric view<br />
  163. 163. Polymetric view<br />Combineseveralmetrics for an entityinto a single view, by relating a visualaspect to eachmetric.<br />Idea<br />
  164. 164. Polymetric view<br />Example<br />
  165. 165. Polymetric view<br />Present a compactviewof software metrics for program elements.<br />Application<br />
  166. 166. Hierarchical edge bundles<br />
  167. 167. Hierarchical edge bundles<br />Bundle association data withstructure data in a radial view.<br />Idea<br />
  168. 168. Hierarchical edge bundles<br />Example<br />
  169. 169. Hierarchical edge bundles<br />Compactviewofassociationsbetween program elements.<br />Application<br />
  170. 170. What about task-oriented<br />program understanding?<br />
  171. 171. The paradox of software visualisation<br />
  172. 172. Programmers usevisualisation all the time whendiscussing programs informally.<br />
  173. 173. Computers aregood at presenting informationgraphically.<br />
  174. 174. ...and yet...<br />
  175. 175. Software visualisation tools are rarely used for everyday software development and understanding.<br />
  176. 176. Why?<br />
  177. 177. Hypothesis<br />Research is outof<br />touch withreality!<br />
  178. 178. Claim<br />Software visualisation<br />is a genericsolutionlooking for problems.<br />
  179. 179. Claim<br />Programmers needspecificsolutions to specific problems.<br />
  180. 180. Remedy<br />An easy-to-usetoolthat lets the programmer definethe problem thatneedsvisualisation.<br />
  181. 181. Task-aware environments<br />
  182. 182. Task-aware environments<br />Adaptinterface to reflectthetaskthe programmer is currentlyworking on.<br />Idea<br />
  183. 183. Task-aware environments<br />Introducesthenotionofdevelopmentsessions.<br />Details<br />
  184. 184. Task-aware environments<br />Links developmentsessions to tasks.<br />Details<br />
  185. 185. Task-aware environments<br />Sessionscan be thrownaway or saved for later.<br />Details<br />
  186. 186. Code bubbles<br />
  187. 187. Description<br />Introduction<br />How Analysis <br />can help<br />Understanding<br />Understanding Program Understanding<br />Agenda<br />Summary<br />Evaluation<br />Examples<br />ConsiderLimitationsofCurrentTools<br />Look at some<br />well-known Analyses<br />

×