Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Pragmatic Design Quality Assessment - (Tutorial at ICSE 2008)

5,920 views

Published on

This set of slides was used for the tutorial given by Tudor Girba, Michele Lanza and Radu Marinescu at International Conference on Software Engineering (ICSE) 2008.

Published in: Technology

Pragmatic Design Quality Assessment - (Tutorial at ICSE 2008)

  1. 1. Pragmatic Design Quality Assessment Tudor Gîrba University of Bern, Switzerland Michele Lanza University of Lugano, Switzerland Radu Marinescu Politehnica University of Timisoara, Romania
  2. 2. 1946
  3. 3. 1951
  4. 4. 1951
  5. 5. 1951
  6. 6. 1951
  7. 7. 1951 2008
  8. 8. 1951 2008
  9. 9. 1951 2008
  10. 10. ? 1951 2008
  11. 11. Software is complex. 29% Succeeded 18% Failed 53% Challenged The Standish Group, 2004
  12. 12. How large is your project?
  13. 13. How large is your project? 1’000’000 lines of code
  14. 14. How large is your project? 1’000’000 lines of code * 2 = 2’000’000 seconds
  15. 15. How large is your project? 1’000’000 lines of code * 2 = 2’000’000 seconds / 3600 = 560 hours
  16. 16. How large is your project? 1’000’000 lines of code * 2 = 2’000’000 seconds / 3600 = 560 hours / 8 = 70 days
  17. 17. How large is your project? 1’000’000 lines of code * 2 = 2’000’000 seconds / 3600 = 560 hours / 8 = 70 days / 20 = 3 months
  18. 18. But, code is for the computer. Why would we ever read it?
  19. 19. } } { { } } { { g rin ee gin en d ar rw fo
  20. 20. fo rw ar d en gin ee rin g { { { { { { } { { } } actual development } } } { } } }
  21. 21. What is the current state? fo rw ar What should we do? d en Where to start? gin ee How to proceed? rin g { { { { { { } { { } } actual development } } } { } } }
  22. 22. fo rw g rin ar ee d gin en gin en ee se rin erv g re { { { { { { } { { } } actual development } } } { } } }
  23. 23. Reverse engineering is analyzing a subject system to: identify components and their relationships, and create more abstract representations. Chikofky & Cross, 90
  24. 24. { { { { } } } } { } A large system contains lots of details.
  25. 25. ity? its qual ju dge How to { { { { } } } } { } A large system contains lots of details.
  26. 26. http://moose.unibe.ch http://loose.upt.ro/incode
  27. 27. 1 Software in 2 Software in numbers pictures 3 Software in 4 Software in time tools
  28. 28. Software in numbers 1
  29. 29. Youcannot control what you cannot measure. Tom de Marco
  30. 30. Metrics are functions that assign numbers to products, processes and resources.
  31. 31. Software metrics are measurements which relate to software systems, processes or related documents.
  32. 32. Metrics compress system traits into numbers.
  33. 33. Let’s see some examples...
  34. 34. Examples of size metrics NOM - number of methods NOA - number of attributes LOC - number of lines of code NOS - number of statements NOC - number of children Lorenz, Kidd, 1994 Chidamber, Kemerer, 1994
  35. 35. McCabe cyclomatic complexity (CYCLO) counts the number of independent paths through the code of a function. McCabe, 1977  it reveals the minimum number of tests to write  interpretation can’t directly lead to improvement action
  36. 36. Weighted Method Count (WMC) sums up the complexity of class’ methods (measured by the metric of your choice; usually CYCLO). Chidamber, Kemerer, 1994  it is configurable, thus adaptable to our precise needs  interpretation can’t directly lead to improvement action
  37. 37. Depth of Inheritance Tree (DIT) is the (maximum) depth level of a class in a class hierarchy. Chidamber, Kemerer, 1994  inheritance is measured  only the potential and not the real impact is quantified
  38. 38. Coupling between objects (CBO) shows the number of classes from which methods or attributes are used. Chidamber, Kemerer, 1994  it takes into account real dependencies not just declared ones  no differentiation of types and/or intensity of coupling
  39. 39. Tight Class Cohesion (TCC) counts the relative number of method-pairs that access attributes of the class in common. Bieman, Kang, 1995 TCC = 2 / 10 = 0.2  interpretation can lead to improvement action  ratio values allow comparison between systems
  40. 40. ...
  41. 41. McCall, 1977
  42. 42. Metrics Assess and Improve Quality!
  43. 43. Metrics Assess and Improve Quality! a lly ? Re
  44. 44. McCall, 1977
  45. 45. Problem 1: metrics granularity ? capture symptoms, not causes of problems in isolation, they don’t lead to improvement solutions
  46. 46. Problem 1: metrics granularity ? capture symptoms, not causes of problems in isolation, they don’t lead to improvement solutions Problem 2: implicit mapping we don’t reason in terms of metrics, but in terms of design principles
  47. 47. 2 big obstacles in using metrics: Thresholds make metrics hard to interpret Granularity make metrics hard to use in isolation
  48. 48. Can metrics help me in what I really care for? :)
  49. 49. fo rw ar d en gin ee rin g { { { { { { } { { } } actual development } } } { } } }
  50. 50. fo rw How do I understand code? ar d en gin ee rin g { { { { { { } { { } } actual development } } } { } } }
  51. 51. fo rw How do I understand code? ar d How do I improve code? en gin ee rin g { { { { { { } { { } } actual development } } } { } } }
  52. 52. fo rw How do I understand code? ar d How do I improve code? en gin How do I improve myself? ee rin g { { { { { { } { { } } actual development } } } { } } }
  53. 53. etr ics! w ith m o do i ng t tn oth I wan fo rw How do I understand code? ar d How do I improve code? en gin How do I improve myself? ee rin g { { { { { { } { { } } actual development } } } { } } }
  54. 54. How to get an initial understanding of a system?
  55. 55. Metric Value LOC 35175 NOM 3618 NOC 384 CYCLO 5579 NOP 19 CALLS 15128 FANOUT 8590 AHH 0.12 ANDC 0.31
  56. 56. Metric Value LOC 35175 NOM 3618 NOC 384 CYCLO 5579 NOP 19 CALLS 15128 FANOUT 8590 AHH 0.12 ANDC 0.31
  57. 57. Metric Value LOC 35175 NOM 3618 NOC 384 CYCLO 5579 NOP 19 CALLS 15128 FANOUT 8590 ha t? ww AHH An d no 0.12 ANDC 0.31
  58. 58. We need means to compare.
  59. 59. hierarchies? coupling?
  60. 60. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 Inheritance ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT Size Communication
  61. 61. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT Size
  62. 62. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT Communication
  63. 63. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 Inheritance ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT
  64. 64. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT
  65. 65. Java C++ LOW AVG HIGH LOW AVG HIGH CYCLO/LOC 0.16 0.20 0.24 0.20 0.25 0.30 LOC/NOM 7 10 13 5 10 16 NOM/NOC 4 7 10 4 9 15 ...
  66. 66. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT close to high close to average close to low
  67. 67. The Overview Pyramid provides a metrics overview. Lanza, Marinescu 2006 close to high close to average close to low
  68. 68. fo rw How do I understand code? ar d How do I improve code? en gin How do I improve myself? ee rin g { { { { { { } { { } } actual development } } } { } } }
  69. 69. etr ics! w ith m o do i ng t oth nt n I wa fo rw How do I understand code? ar d How do I improve code? en gin How do I improve myself? ee rin g { { { { { { } { { } } actual development } } } { } } }
  70. 70. How do I improve code?
  71. 71. Quality is more than 0 bugs. Breaking design principles, rules and best practices deteriorates the code; it leads to design problems.
  72. 72. Imagine changing just a small design fragment
  73. 73. Imagine changing just a small design fragment
  74. 74. Imagine changing just a small design fragment and33% of all classes would require changes
  75. 75. expensive Design problems are frequent unavoidable
  76. 76. expensive Design problems are frequent unavoidable th em? ate limin nd e ete ct a to d How
  77. 77. God Classes tend to centralize the intelligence of the system, to do everything and to use data from small data-classes. Riel, 1996
  78. 78. God Classes tend to centralize the intelligence of the system, to do everything and to use data from small data-classes.
  79. 79. God Classes centralize the intelligence of the system, do everything and use data from small data-classes.
  80. 80. God Classes are complex, are not cohesive, access external data.
  81. 81. God Classes are complex, are not cohesive, access external data. sing uer ies u to q s s in ator etric per se m ical o Co mpo log
  82. 82. Detection Strategies are metric-based queries to detect design flaws. Lanza, Marinescu 2006 Rule 1 METRIC 1 > Threshold 1 AND Quality problem Rule 2 METRIC 2 < Threshold 2
  83. 83. Shotgun Surgery has uses is has (partial) Feature Data Envy uses Class is partially God has Intensive Class Coupling Brain has has Method Extensive Brain has Significant Coupling Class Duplication has is is has Refused is Tradition Parent Breaker Bequest has (subclass) Futile Hierarchy Lanza, Marinescu 2006 Identity Collaboration Classification Disharmonies Disharmonies Disharmonies
  84. 84. A God Class centralizes too much intelligence in the system. Lanza, Marinescu 2006 Class uses directly more than a few attributes of other classes ATFD > FEW Functional complexity of the class is very high AND GodClass WMC ! VERY HIGH Class cohesion is low TCC < ONE THIRD
  85. 85. An Envious Method is more interested in data from a handful of classes. Lanza, Marinescu 2006 Method uses directly more than a few attributes of other classes ATFD > FEW Method uses far more attributes of other classes than its own AND Feature Envy LAA < ONE THIRD The used quot;foreignquot; attributes belong to very few other classes FDP ! FEW
  86. 86. Data Classes are dumb data holders. Lanza, Marinescu 2006 Interface of class reveals data rather than offering services WOC < ONE THIRD AND Data Class Class reveals many attributes and is not complex
  87. 87. Data Classes are dumb data holders. Lanza, Marinescu 2006 More than a few public data NOAP + NOAM > FEW AND Complexity of class is not high WMC < HIGH Class reveals many OR attributes and is not Class has many public complex data NOAP + NOAM > MANY AND Complexity of class is not very high WMC < VERY HIGH
  88. 88. fo rw ar d en gin ee rin g { { { { { { } { { } } actual development } } } { } } }
  89. 89. fo rw How do I understand code? ar d How do I improve code? en gin How do I improve myself? ee rin g { { { { { { } { { } } actual development } } } { } } }
  90. 90. How do I improve myself?
  91. 91. Follow a clear and repeatable process
  92. 92. Follow a clear and repeatable process
  93. 93. Follow a clear and repeatable process
  94. 94. Follow a clear and repeatable process mb ers! so f nu in term qu ality ab out re ason D on’t
  95. 95. QA is part of the the Development Process http://loose.upt.ro/incode
  96. 96. Can we understand the beauty of a painting by measuring its frame or counting its colors?
  97. 97. 1 Software in 2 Software in numbers pictures 3 Software in 4 Software in time tools
  98. 98. Software in pictures 2
  99. 99. Software is beautiful
  100. 100. 1854, London, cholera epidemic
  101. 101. 1812, Napoleon’s Campaign in Russia
  102. 102. Numbers..
  103. 103. Numbers..
  104. 104. Numbers.. ANDC 0.31 AHH 0.12 20.21 NOP 19 9.42 NOC 384 9.72 NOM 3618 NOM 418 0.15 LOC 35175 15128 CALLS 0.56 CYCLO 5579 8590 FANOUT
  105. 105. Visualization compresses the system into pictures.
  106. 106. A picture is worth a thousand words... anonymous ...depends on the picture Lanza
  107. 107. U ML han mo re t tio n is liza isua wa re v Soft
  108. 108. We are visual beings ... ... and we’re good at spotting patterns
  109. 109. How many groups do you see?
  110. 110. How many groups do you see?
  111. 111. How many groups do you see?
  112. 112. How many groups do you see?
  113. 113. Gestalt principles proximity similarity enclosure connectivity
  114. 114. More Gestalt principles closure continuity
  115. 115. We do not see with our eyes, but with our brain. Our brain works like a computer, with 3 types of memory Iconic memory, the visual sensory register Short-term memory, the working memory Long-term memory Sensation Perception (Physical Process) (Cognitive Process) Stimulus Sensory Organ Perceptual Organ Brain Iconic Memory - Short-term Memory - Long-term Memory
  116. 116. Iconic Short-term memory memory
  117. 117. Iconic Short-term memory memory < 1 second very fast automatic subconscious preattentive
  118. 118. Iconic Short-term memory memory < 1 second couple of seconds very fast 3-9 chunks automatic subconscious preattentive
  119. 119. Categorizing Preattentive Attributes Category Form Color Spatial Motion Motion Orientation Hue 2D position Flicker Line length Intensity Direction Line width Size Attribute Shape Curvature Added marks Enclosure
  120. 120. Attributes of Form Orientation Line Length Line Width Size Shape Curvature Added Marks Enclosure
  121. 121. Attributes of Form Line Length Line Width Size Shape Curvature Added Marks Enclosure
  122. 122. Attributes of Form Line Width Size Shape Curvature Added Marks Enclosure
  123. 123. Attributes of Form Size Shape Curvature Added Marks Enclosure
  124. 124. Attributes of Form Shape Curvature Added Marks Enclosure
  125. 125. Attributes of Form Curvature Added Marks Enclosure
  126. 126. Attributes of Form Added Marks Enclosure
  127. 127. Attributes of Form Enclosure
  128. 128. Attributes of Form
  129. 129. Exemplifying Preattentive Processing
  130. 130. Exemplifying Preattentive Processing 8789364082376403128764532984732984732094873290845 389274-0329874-32874-23198475098340983409832409832 049823-0984903281453209481-0839393947896587436598
  131. 131. Exemplifying Preattentive Processing 8789364082376403128764532984732984732094873290845 389274-0329874-32874-23198475098340983409832409832 049823-0984903281453209481-0839393947896587436598 8789364082376403128764532984732984732094873290845 389274-0329874-32874-23198475098340983409832409832 049823-0984903281453209481-0839393947896587436598
  132. 132. 70% of all external inputs come through the eyes
  133. 133. Software visualization is the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both the human understanding and effective use of computer software. Price, Becker, Small
  134. 134. Static Visualization
  135. 135. Dynamic Visualization
  136. 136. llet r bu no silve
  137. 137. Software is complex
  138. 138. Software is complex
  139. 139. A picture is worth a thousand words.
  140. 140. era lly :) ok it lit L to UM
  141. 141. Example: what is ?
  142. 142. Polymetric Views show up to 5 metrics. Lanza, 2003 Width metric Height metric Position metrics Color metric
  143. 143. A simple & powerful concept LOC NOS parameters parameters lines
  144. 144. System Complexity shows class hierarchies. Lanza, Ducasse, 2003 attributes methods lines
  145. 145. Class Blueprint shows class internals. Lanza, Ducasse, 2005 Initialize Interface Internal Accessor Attribute invocation and access direction
  146. 146. Class Blueprint has a rich vocabulary. internal access Access external Attribute access Invocation Regular Constant invocations Overriding Delegating lines Method Extending Setter Abstract Getter
  147. 147. Class Blueprint reveals patterns. twin classes schizophrenic class
  148. 148. Distribution Map shows properties over structure. Ducasse etal, 2006 31 parts, 394 elements and 9 properties
  149. 149. Softwarenaut explores the package structure. Lungu etal, 2006
  150. 150. Code City shows where your code lives. Wettel, Lanza, 2007 classes are buildings grouped in quarters of packages
  151. 151. Jmol - The Time Machine
  152. 152. Jmol - The Time Machine
  153. 153. Jmol - The Time Machine
  154. 154. Jmol - The Time Machine
  155. 155. Jmol - The Time Machine
  156. 156. Jmol - The Time Machine
  157. 157. Jmol - The Time Machine
  158. 158. Jmol - The Time Machine
  159. 159. Software is beautiful
  160. 160. 1 Software in 2 Software in numbers pictures 3 Software in 4 Software in time tools
  161. 161. Software in time 3
  162. 162. fo rw g rin ar ee d gin en gin en ee se rin erv g re { { { { { { } { { } } actual development } } } { } } }
  163. 163. { { } } } { { { } } re v er se en gin ee rin g reverse engineering fo actual development rw ar d en gin ee rin g { { } } { { } }
  164. 164. { { { { } } } } { } A large system contains lots of details.
  165. 165. { { { { { { { { { { { { { { { { { { { { } } } } } } } } } } } } } } } } { } } { } } { } } { } } { } The history of a large system contains even more details.
  166. 166. Most often time is put on the horizontal and a property on the vertical axis. Lehman etal, 2001
  167. 167. Spectographs show change activity. Wu etal, 2004 commit time
  168. 168. Evolution Matrix shows changes in classes. Lanza, Ducasse, 2002 Idle class Pulsar class Supernova class White dwarf class
  169. 169. Evolution Matrix shows changes in classes. Lanza, Ducasse, 2002
  170. 170. History can be measured.
  171. 171. What changed? When did it change? ... 2 4 3 5 7 2 2 3 4 9 2 2 1 2 3 2 2 2 2 2 1 5 3 4 4
  172. 172. Evolution of Number of Methods LENOM(C) = ∑ |NOMi(C)-NOMi-1(C)| 2i-n LENOM(C) = 4 + 2 + 1 + 0 = 7 1 5 3 4 4
  173. 173. Latest Evolution of Number of Methods LENOM(C) = ∑ |NOMi(C)-NOMi-1(C)| 2i-n Earliest Evolution of Number of Methods EENOM(C) = ∑ |NOMi(C)-NOMi-1(C)| 22-i -3 -2 -1 0 LENOM(C) = 42 + 22 + 12 + 02 = 1.5 1 5 3 4 4 EENOM(C) = 4 20 + 2 2-1 + 1 2-2 + 0 2-3 = 5.25
  174. 174. ENOM LENOM EENOM 2 4 3 5 7 7 3.5 3.25 2 2 3 4 9 7 5.75 1.37 2 2 1 2 3 3 1 2 2 2 2 2 2 0 0 0 1 5 3 4 4 7 1.25 5.25
  175. 175. ENOM LENOM EENOM balanced changer 7 3.5 3.25 late changer 7 5.75 1.37 3 1 2 dead stable 0 0 0 early changer 7 1.25 5.25
  176. 176. ENOM LENOM EENOM balanced changer 7 3.5 3.25 late changer 7 5.75 1.37 ed. measur3 1 2 be ry can H isto dead stable 0 0 0 early changer 7 1.25 5.25
  177. 177. History can be measured in many ways. Evolution Number of Methods Stability Number of Lines of Code Historical Max of Cyclomatic Complexity Growth Trend Number of Modules ... ...
  178. 178. The recently changed parts are likely to change in the near future. Common wisdom
  179. 179. The recently changed parts are likely to change in the near future. ally? Common wisdom re re they A
  180. 180. 30% 90%
  181. 181. present
  182. 182. past present
  183. 183. past future present
  184. 184. past future present
  185. 185. past future present
  186. 186. past future YesterdayWeatherHit(present): past:=histories.topLENOM(start, present) future:=histories.topEENOM(present, end) past.intersectWith(future).notEmpty() present
  187. 187. past future YesterdayWeatherHit(present): past:=histories.topLENOM(start, present) future:=histories.topEENOM(present, end) past.intersectWith(future).notEmpty() present prediction hit
  188. 188. Yesterday’s Weather shows the localization of changed in time. Girba etal, 2004 hit hit hit YW = 3 / 8 = 37% hit hit hit hit hit hit hit YW = 7 / 8 = 87%
  189. 189. A God Class centralizes too much intelligence in the system. Class uses directly more than a few attributes of other classes ATFD > FEW Functional complexity of the class is very high AND GodClass WMC ! VERY HIGH Class cohesion is low TCC < ONE THIRD
  190. 190. A God Class centralizes too much intelligence in the system. Class uses directly more than a few attributes of other classes ATFD > FEW tab le? f it is s wh Functional complexity of the at i ut, class is very high B AND GodClass WMC ! VERY HIGH Class cohesion is low TCC < ONE THIRD
  191. 191. History-based Detection Strategies take evolution into account. Ratiu etal, 2004 God Class in the last version isGodClass(last) AND Harmless God Class Stable throughout the history Stability > 90%
  192. 192. What happens with inheritance? A A A A A B C B C B C B B D D D E ver .1 ver. 2 ver. 3 ver. 4 ver. 5 A is persistent, B is stable, C was removed, E is newborn ...
  193. 193. Hierarchy Evolution encapsulates time. Girba etal, 2005 A changed methods changed age lines C B Removed Removed D E A is persistent, B is stable, C was removed, E is newborn ...
  194. 194. Hierarchy Evolution reveals patterns. Girba etal, 2005
  195. 195. Co-change analysis recovers hidden dependencies. Time is the lines. Gall etal, 2003
  196. 196. Evolution Radar shows co-change relationships. D’Ambros, Lanza 2006 one package and its co-change relationships
  197. 197. Software is developed by people.
  198. 198. CVS shows activity.
  199. 199. Who is responsible for this?
  200. 200. Who is responsible for this?
  201. 201. Alphabetical order is no order.
  202. 202. Ownership Map reveals development patterns. Girba etal, 2006
  203. 203. JEdit
  204. 204. Ant
  205. 205. Who copied from whom? (john 23.06.03) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill 09.01.05) if (!isActive()) { (bill 09.01.05) return false (bill 09.01.05) } (steve 16.02.05) List offs = i.getOffenders(); (john 23.06.03) Object dm = offs.firstElement(); (steve 16.02.05) ListSet newOffs = computeOffenders(dm); (john 23.06.03) boolean res = offs.equals(newOffs); (john 23.06.03) return res; (george 13.02.05) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill 11.13.05) if (!isActive()) { (bill 11.13.05) return false (bill 11.13.05) } (steve 16.02.05) List offs = i.getOffenders(); (george 13.02.05) Object dm = offs.firstElement(); (steve 16.02.05) ListSet newOffs = computeOffenders(dm); (george 13.02.05) boolean res = offs.equals(newOffs); (george 13.02.05) return res;
  206. 206. What is useless? (john 23.06.03) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill 09.01.05) if (!isActive()) { (bill 09.01.05) return false (bill 09.01.05) } (steve 16.02.05) List offs = i.getOffenders(); (john 23.06.03) Object dm = offs.firstElement(); (steve 16.02.05) ListSet newOffs = computeOffenders(dm); (john 23.06.03) boolean res = offs.equals(newOffs); (john 23.06.03) return res; (george 13.02.05) public boolean stillValid (ToDoItem I, Designer dsgr) { (bill 11.13.05) if (!isActive()) { (bill 11.13.05) return false (bill 11.13.05) } (steve 16.02.05) List offs = i.getOffenders(); (george 13.02.05) Object dm = offs.firstElement(); (steve 16.02.05) ListSet newOffs = computeOffenders(dm); (george 13.02.05) boolean res = offs.equals(newOffs); (george 13.02.05) return res;
  207. 207. When did changes happen? 23.06.03 public boolean stillValid (ToDoItem I, Designer dsgr) { 09.01.05 if (!isActive()) { 09.01.05 return false 09.01.05 } 16.02.05 List offs = i.getOffenders(); 23.06.03 Object dm = offs.firstElement(); 16.02.05 ListSet newOffs = computeOffenders(dm); 23.06.03 boolean res = offs.equals(newOffs); 23.06.03 return res; 13.02.05 public boolean stillValid (ToDoItem I, Designer dsgr) { 11.13.05 if (!isActive()) { 11.13.05 return false 11.13.05 } 16.02.05 List offs = i.getOffenders(); 13.02.05 Object dm = offs.firstElement(); 16.02.05 ListSet newOffs = computeOffenders(dm); 13.02.05 boolean res = offs.equals(newOffs); 13.02.05 return res;
  208. 208. Clone Evolution shows how developers copy. Balint etal, 2006
  209. 209. { { } } } { { { } } re v er se en gin ee rin g reverse engineering fo actual development rw ar d en gin ee rin g { { } } { { } }
  210. 210. 1 Software in 2 Software in numbers pictures 3 Software in 4 Software in time tools
  211. 211. Software in tools 4
  212. 212. http://moose.unibe.ch http://loose.upt.ro/incode http://www.inf.unisi.ch/phd/wettel/codecity.html
  213. 213. Pragmatic Design Quality Assessment Tudor Gîrba University of Bern, Switzerland Michele Lanza University of Lugano, Switzerland Radu Marinescu Politehnica University of Timisoara, Romania
  214. 214. Tudor Gîrba, Michele Lanza, Radu Marinescu http://creativecommons.org/licenses/by/3.0/

×