Description. The class versions are represented as platforms next to each other along a time- line, from left (first version) to right (last version) and the methods are represented as “bricks”. We combine this with the age map technique to enable a clearer visual distinction between the different “generations” (i.e., groups of methods created in the same version) of methods.
time version 1 version 2 version 3 m1 m2 m3 m5 m6 m7 m12 m17 m9 m10 m11 m13 m14 m15 m18 m1 m9 m1 m2
Figure 4.7. Example illustrating the principles of the timeline technique
Figure 4.7 illustrates these principles applied to the three-versions history of classC. In the first version, classChas seven methods (m1tom7). In the second version, methodm7is removed and five other methods (m8tom12) are added to the class. The new bricks appear at the top of the building in a lighter color than the rest of the bricks. The place formerly occupied bym7will remain empty from here on. In the third version, the older methodm2is removed and six new methods (m13tom18) are added. The benefit of this visualization is that it provides a complete representation of an artifact’s evolution, thus allowing for the detection of evolutionary patterns.
We use this technique mostly at the class level, by visualizing the evolution of a class in terms of its methods. The importance of choosing the right granularity is shown in Figure 4.8 by means of a comparison: The fine-grained timeline of classstandard.StandardDrawingView from JHotDraw, depicts interesting events, such as the creation or removal of methods (See Figure 4.8(a)). In contrast, the coarse-grained timeline of the same class is only able to show details at the class level, such as the modification of the NOA or NOM metric values (See Fig- ure 4.8(b)). We consider the coarse-grained timeline a poor combination for evolution analysis and, therefore, exclude it from the discussion.
(a) Fine-grained (b) Coarse-grained
Figure 4.8. The timeline of classstandard.StandardDrawingViewat different granularities This technique can also be applied at package level, to depict the evolution of a package in terms of its sub-packages and classes. Figure 4.9 shows a fine-grained timeline of a district, whose tallest building represents precisely the class whose timeline was shown in Figure 4.8(a).
Goals. Isolate a reduced set of artifacts to create a view of their entire history including all the inner components. Observe evolution patterns, such as incrementally grown classes, recurring methods, etc.
Application. We analyzed a number of Jmol’s classes using the timeline technique. Figure 4.10 shows the timeline of the org.jmol8.g3d.Graphics3D class, which spreads over the last 22 versions of Jmol’s history made of 51 versions. This class is likely to be an important one, given the structure of its timeline. Already in its first version, it contained 103 methods and it has been subject to massive changes. With each new version, new functionality (i.e., methods) was added to this class and at the same time old functionality was removed. Gradually, the initial structure of the class got lost in time and the final column of the timeline accurately reflects its continuous adaptation: Out of the 311 methods that existed throughout its history, only 158 have made it to the current version.
fillQuadrilateral
fillTriangle
applyBlueAnaglyph
Figure 4.10. Timeline of classGraphics3D
The timeline of Graphics3D illustrates an interesting pattern, manifested through bricks exhibiting color anomalies. After looking into this pattern, we learned that this pattern indicates a restoration of groups of methods after a period of time from their removal.
Through the combined effect of the age map technique and the chronological order imposed on the layout, the color of the brick representing a restored method stands out as an anomaly in every subsequent version of the class, i.e., it breaks the color pattern of its surrounding bricks. Although its position denotes the fact that it has been created at roughly the same time as its neighbor bricks, the color reflects a shorter life (i.e., fewer versions) than the one of its neighbors. Figure 4.10 shows three examples of such methods. The first one isfillQuadrilateral, which disappeared after the first version of the class, reappeared in the ninth version and after six more versions was removed again. The second method isfillTrianglewhich was created in the first version of the class, survived for five versions, and then disappeared for fifteen more versions. As this case illustrates, the more versions pass between removal and restoration, the more striking the color anomaly is. The third method isapplyBlueAnaglyph, which was created later (i.e., in the tenth version), removed right after that, and restored in version 17.
We looked at the timelines of several long-lived classes in Jmol, four of which are illustrated in Figure 4.11 along with a description of their evolution in numbers (See Table 4.5). At a first glance, we see how each timeline reflects the evolutionary characteristics of the underlying class history. For instance, the peak of each timeline (the height of the last version of the building) de- picts the number of method histories:Evalis twice as tall asJmolViewerorTransformManager, but half the height ofViewer, which encapsulates 1,029 method histories in its evolution.Eval lost many of its initial methods during its evolution (166 out of 432) and this is well reflected in its timeline: the most recent version (i.e., the last column) looks unstable, with many missing bricks in its structure.
Class History Total Current Removed
api.JmolViewer 177 150 27
viewer.Viewer 1,029 750 279
viewer.TransformerManager 220 161 59
viewer.Eval 432 266 166
Table 4.5. The number of methods for the class histories in Figure 4.11
Table 4.5 presents the timelines of the classesViewer,JmolViewer (i.e., the superclass of Viewer),Eval, andTransformManager. An intriguing observation we made was that each of these timelines shows a group of bricks, which disappears in revision 5,154 from 22/05/2006 and reappears after exactly three sampled versions, in revision 6,098 from 6/11/2006, as illus- trated by the common time coordinates in the top left part of Figure 4.5.
The hypothesis that first came to our mind was that the developers massively removed meth- ods from these logically coupled classes, thus generating bugs which were not detected right away and which could only be fixed later by reviving the removed methods.
Reality Check. Our hypothesis was confirmed both indirectly and directly. We first looked at the logs of the Jmol versioning repository. The version in which the methods were removed had to be in the range between revisions 4,709 and 5,154. The log of revision 5,091 from 10/05/2006 reads: “No morejavax.vecmath.Point3fin g3d shape drawing routines. There were some cases where screen coordinates were being passed in as Point3f objects [. . .] ”. Similarly, we searched for a revision which would give away the recovery of the previously
Viewer org.jmol.viewer NOMH: 1'029 18 versions Eval org.jmol.viewer NOMH: 432 18 versions TransformerManager org.jmol.viewer NOMH: 220 18 versions JmolViewer org.jmol.api NOMH: 177 18 versions 4'709 5'154 5'319 5'480 6'098 time
Figure 4.11. Learning from the past by correlating several class timelines of Jmol
removed methods, in the range between revisions 5,480 and 6,098. We found revision 5,579 from 17/09/2006 whose log acknowledges the restoration: “Revert ofvecmathlib change”.
This was a fortunate case, because oftentimes the developers do not document their modi- fications in the logs of the versioning system. However, since we wanted to learn more about this system, we contacted the developers who committed in the repository during that period. Three of the developers shared with us interesting insights on this period in the system’s evolu- tion. Developer1 agreed with us: “Your hypothesis is probably correct” and recalled: “We found some major problems, and diagnostic was too difficult, so we reverted to a stable version and tried to apply patches in small batch.” Developer2 remembered that “It was quite a nightmare for everyone involved. The issue was that I was new to the project and had committed quite a few additions to Jmol thinking that Developer3 was monitoring; as it turned out he found my additions too much too fast, and because there was a problem with the graphics display module g3d that resulted in some slow performance, he opted to revert to an earlier state. In the end it turned out to be a recent addition to transparency in the graphics, not anything I had done, that caused the problem. In any case, we did sort of start over – or at least I did. I think I have that right. So I think your hypothesis is correct[. . .] ”.
Drawbacks. Given the real estate of the screen, there are scalability issues in the case of arti- facts with hundreds or more revisions.