Software Wartung und Evolution Modeling History with Metamodels. Harald Gall Institut für Informatik Universität Zürich

Transcription

1 Software Wartung und Evolution Modeling with Metamodels Harald Gall Institut für Informatik Universität Zürich

2 Modeling to Understand Software Evolution 2007, Tudor Gîrba

3 Context: Reverse engineering is creating high level views of the system Requirements Analysis Design Time Implementation Tudor Gîrba 3/47

4 Context: holds useful information for reverse engineering The doctor always looks at my health file Historical information is useful but, it is hidden among huge amounts of data n N versions means N times more data The more data the more techniques are needed to analyze it Tudor Gîrba 4/47

5 Context: Many techniques were developed Trend analysis [Lehman et al. 01] Evolution patterns [Lanza, Ducasse 02] Co-change analysis [Gall etal. 03] Authors analysis [Eick et al. 02] Tudor Gîrba 5/47

6 Problem: Current approaches rely on ad-hoc models or on too specific meta-models Trend analysis [Lehman etal. 01] Evolution patterns [Lanza, Ducasse 02] Research question: How can we build a generic meta-model? Co-change analysis [Gall etal. 03] Authors analysis [Eick etal. 02] Tudor Gîrba 6/47

7 Overview Hismo Hismo: Modeling Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 7/47

8 Example: Evolution Matrix reveals different evolution patterns [Lanza, Ducasse 02] Pulsar Class Idle Class Thesis: NOM Polymetric view White Dwarf Class Supernova Class Evolution needs to be modeled as a first class entity Class NOA versions Tudor Gîrba 8/47

9 Solution: encapsulates and characterizes the evolution Pulsar Class Idle Class Class White Dwarf Class ispulsar isidle Supernova Class versions Tudor Gîrba 9/47

10 Hismo: The history meta-model System System Class Class Tudor Gîrba 10/47

11 but, what about relationships? System System Inheritance Inheritance Class Class Tudor Gîrba 11/47

12 Hismo is obtained by transforming the structural meta-model Tudor Gîrba 12/47

13 Overview Application: measurements Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 13/47

14 Problem: holds useful information hidden among large amounts of data How much was a class changed? When was a class changed? Tudor Gîrba 14/47

15 can be measured: How much was a class changed? Evolution of Number of Methods n ENOM(C)= NOM i (C)-NOM i-1 (C) i=2 ENOM(C)= = Tudor Gîrba 15/47

16 can be measured: When was a class changed? Latest Evolution of Number of Methods Earliest Evolution of Number of Methods n LENOM(C)= NOM i (C)-NOM i-1 (C) 2 i - n i=2 n EENOM(C)= i=2 NOM i (C)-NOM i-1 (C) i LENOM(C)= = EENOM(C)= = Tudor Gîrba 16/47

17 measurements compress aspects of the evolution into numbers ENOM LENOM EENOM A B C D E Tudor Gîrba 17/47

18 measurements compress aspects of the evolution into numbers ENOM LENOM EENOM A Balanced changer B Late changer C D Dead stable E Early changer Tudor Gîrba 18/47

19 Many measurements can be defined at different levels of abstraction Evolution Latest/Earliest Evolution Stability Historical Max/Min Historical Average Growth Trend of Number of Methods Number of Statements Cyclomatic Complexity Lines of Code Number of Classes Number of modules But measurements are a means not a goal Tudor Gîrba 19/47

20 Overview Application: Yesterday s Weather Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 20/47

21 Common Wisdom: The recently changed parts are likely to change in the near future Is the common wisdom relevant? [Mens,Demeyer 01] Yesterday s Weather metaphor: It expresses the chances of having the same weather today as we had yesterday It is location specific Switzerland - 30% Sahara - 90% Tudor Gîrba 21/47

22 Yesterday s Weather: For each given version we check the common wisdom Past Late Changers Future Early Changers YesterdayWeatherHit(present): past:=histories.toplenom(start, present) future:=histories.topeenom(present, end) past.intersectwith(future).notempty() hit Past versions Present version Future versions Tudor Gîrba 22/47

23 Overall Yesterday s Weather shows the localization of changes in time hit hit hit hit hit hit hit hit hit hit YW = 3 hits 8 possible hits = 37% YW = 7 hits 8 possible hits = 87% Case studies: 40 versions of CodeCrawler (180 classes): 100% 40 versions of Jun (700 classes): 79% 40 versions of Jboss (4000 classes): 53% Tudor Gîrba 23/47

24 Overview Application: -based Detection Strategies Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 24/47

25 Context: Detection Strategies detect design flaws based on measurements [Marinescu 04] Example: God Class Maintainability problem because it encapsulates a lot of knowledge Class ATFD > 40 Class WMC > 75 Class TCC < 0.2 Class NOA > 20 AND AND OR God Class Tudor Gîrba 25/47

26 -based Detection Strategies take evolution into account Example: a Stable God Class is not necessarily a bad one Last God Class Stability > 95% AND Stable God Class Case study: 5 out of 24 God Classes in Jun were stable and harmless Tudor Gîrba 26/47

27 Overview Application: Characterizing the evolution of class hierarchies Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 27/47

28 Context: Given the evolution of a hierarchy A A A A A B C B C B C B B D D D E time A is persistent B is stable C was removed E is newborn D inherited from C and then from A Tudor Gîrba 28/47

29 but useful information is hidden among large amounts of data How were the hierarchies evolved? Tudor Gîrba 29/47

30 Hierarchy Evolution Complexity View characterizes class hierarchy histories ENOM C A B ENOS Age Removed Class D E Age Removed Inheritance A is persistent B is stable C was removed E is newborn D inherited from C and then from A Tudor Gîrba 30/47

31 Case study: Class hierarchies in Jun reveal evolution patterns Young Unstable root Reliable inheritance Persistent Unbalanced Stable Reliable inheritance Newborn Old Stable Balanced Reliable inheritance Old Unstable Unbalanced Unreliable inheritance Tudor Gîrba 31/47

32 Overview Application: Detecting co-change patterns Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 32/47

33 Context: Repeated co-changes reveal hidden dependencies [Gall etal. 98] A v1 v2 v3 v4 v5 v6 B C D Can we identify co-change patterns like: Parallel Inheritance Shotgun Surgery? E Tudor Gîrba 33/47

34 Formal Concept Analysis (FCA) finds elements that have properties in common [Ganter, Wille 99] A B P1 P2 P3 P4 P5 P6 (A,D,E) (P2) (A,B,C,D,E) () (A,B,C,D) (P6) C FCA (D,E) (P2,P4) (A,D) (P2,P6) (A,B,C) (P5,P6) D (D) (P2,P4,P6) (A) (P2,P5,P6) (C) (P3,P5,P6) E To use FCA, we need to map our interests on elements and properties () (P1,P2,P3,P4,P5,P6) Tudor Gîrba 34/47

35 Formal Concept Analysis (FCA) finds elements that have properties in common [Ganter, Wille 99] A B P1 P2 P3 P4 P5 P6 (A,D,E) (P2) (A,B,C,D,E) () (A,B,C,D) (P6) C FCA (D,E) (P2,P4) (A,D) (P2,P6) (A,B,C) (P5,P6) D (D) (P2,P4,P6) (A) (P2,P5,P6) (C) (P3,P5,P6) E To use FCA, we need to map our interests on elements and properties () (P1,P2,P3,P4,P5,P6) Tudor Gîrba 35/47

36 We use FCA to identify entities that co-changed repeatedly A B v1 v2 v3 v4 v5 v6 (A,D,E) (v2) (A,B,C,D,E) () (A,B,C,D) (v6) C FCA (D,E) (v2,v4) (A,D) (v2,v6) (A,B,C) (v5,v6) D (D) (v2,v4,v6) (A) (v2,v5,v6) (C) (v3,v5,v6) E Elements = Histories Properties = changed in version X () (v1,v2,v3,v4,v5,v6) Tudor Gîrba 36/47

37 Example: Parallel inheritance denotes children added in several hierarchies v1 v2 v3 v4 v5 v6 A Case study: JBoss A A A A A A ServiceMBeanSupport JBossTestCase 14 versions EJBLocalHome EJBLocalObject 9 versions Elements = ClassHistories Properties = changed number of children in version X Tudor Gîrba 37/47

38 Overview Application: Ownership map Hismo Applications Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 38/47

39 Context: The code history might tell you what happened, but not why it happened Case study: Outsight [Rysselberghe, Demeyer 04] files Who is responsible for this? time Tudor Gîrba 39/47

40 We color the lines to show which author owned which files in which period Green author large commit Green author ownership File A File B Blue author small commit Tudor Gîrba 40/47

41 The commit history shows what happened Tudor Gîrba 41/47

42 Ownership Map shows which author owned which files in which period Tudor Gîrba 42/47

43 We cluster the file histories to favor colored blocks inside each module We use the Hausdorf distance between the commit timestamps d(a, B) = min 2 { a - b b B } a A A B Tudor Gîrba 43/47

44 Ownership Map on alphabetically ordered files is not very useful, but Tudor Gîrba 44/47

45 The ordered Ownership Map reveals developer patterns Edit Takeover Monologue Familiarization Dialogue Tudor Gîrba 45/47

46 Overview Implementation: Hismo Applications Both Hismo and its applications are implemented in one single infrastructure Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 46/47

47 Implementation: All tools are integrated into Moose Van CodeCrawler ConAn Chronia Moose Model repository Extensible meta-model Integration mechanism Tudor Gîrba 47/47

48 Conclusion: Hismo offers a uniform way of expressing evolution analyses Hismo Applications Questions? Historical measurements Yesterday s Weather -based Detection Strategies Hierarchy evolution Co-change patterns Ownership Map Tudor Gîrba 48/47

49 Hismo: is a sequence of s, where a adds the notion of time to Snapshot 1 * * 1 Snapshot date: Date Class Class Class Method Method Method Tudor Gîrba 49/47

50 The techniques are orthogonal to the type of data Node = class Edge = inheritance Node = Class Edge = Inheritance Tudor Gîrba 50/47

51 Entity identity: Are two entities at different points in time the versions of the same history? The current versioning systems record snapshots What are the names? ver 1 ver 2 What are the properties? What we would like Preserve the identity in the environment Record changes as they happen Tudor Gîrba 51/47