Relating source-model data with version and change data

Abstract

Extensive software system are generally very expensive. Due to monetary reasons, the lifetime of such systems have to be especially long. As time passes by, software systems undergo a lot of changes. Each workover costs money, and if architectural changes are necessary, the amount spent might even raise significantly. Changes and adaptions often result in the majority of funds being invested into these makeovers.<br />Hence keeping the costs for changes as low as possible should be a priority of all companies.<br />To perform this task the structure of software systems has to be analysed. Not only the current state of the source code and design, but also the evolution of it should be investigated. By checking the changes that are made to files, classes or methods in the different releases much more hints can be found than by just taking a look at the current state. The data stored in the version control system is enough to do some analysis about the evolution.<br />Based on the source model data of one release of a software project, the new addresses of the entities in another release should be calculated.<br />Both versions have to be retrieved from the version control system and stored in the local file system. Each of the pairs of equivalent source code files is compared with the diff-command. To analyse the differences made to the compared release, six cases of the relative positioning of the source code changes to the entities are defined. Test cases for all six cases are provided. Some of them are pretty synthetic which is obvious because of the odd things that have been done to the source code to produce the test cases.<br />The analysis is also done with a real software project. The large Open Source project Mozilla is used, where releases 1.3a and 1.4, are compared wheras the pathological of the six defined cases don't occur.<br />Therefore the new source model data can be computed corretly.<br />The computation process itself is CPU intensive but no problem for state of the art computers. But what takes up to 50% of the computation time are the file operations for the comparison.<br />Three essential files are also compared from release 0.9.2 to 1.6. Here all six cases occur and therefore the new addresses cannot be calculated completely correct. But if a length can be calculated it is almost always correct.<br />During the computation process statistical values for each entity are logged. This allows us to get evolution data on the method level which can be used for deeper analysis of the software project.<br />

Umfangreiche Software-Systeme sind im Allgemeinen sehr teuer. Um diese hohen Kosten zu rechtfertigen, ist die Lebensdauer solcher Systeme oft sehr hoch. Im Laufe der Zeit müssen diese Systeme aber immer wieder geändert werden, und wenn die Architektur des Systems erneuert werden muss, können die Änderungskosten den Großteil des finanziellen Gesamtaufwandes ausmachen. Aus diesem Grund gilt es die Änderungskosten so gering wie möglich zu halten.<br />Um dieses Ziel zu erreichen muss die Struktur der Software-Systeme analysiert werden. Hier gilt der Augenmerk aber nicht nur dem momentanen Status von Source Code und Design, sondern vor allem auch der Evolution des Systems. Die Analyse der Änderungen an Dateien, Klassen und Methoden liefert weitere signifikante Hinweise. Die Daten die in der Versionsverwaltung gespeichert sind, reichen aus um eine Analyse der Evolution vorzunehmen.<br />Basierend auf den Source Model Daten einer Releases, sollen die Adressen der Entitäten in einer anderen Release berechnet werden. Dazu müssen beide Releases komplett aus der Versionsverwaltung geholt werden. Jedes Paar von Source-Code Dateien wird mit dem diff-Befehl verglichen und um die Differenzen zu analysieren wurden sechs verschiedene Fälle der relativen Position der Änderung zu vorhandenen Entitäten festgelegt.<br />Einige davon sind eher künstlich, was man vor allem an den dafür generierten Testfällen merkt.<br />Um das Programm an einem realen Software-System zu testen, wird das Open-Source Projekt Mozilla benutzt. Die Releases 1.3a und 1.4 des Projektes werden verglichen, wobei die künstlich konstruierten Fälle hier gar nicht auftreten, wodurch die neuen Source-Model Daten korrekt berechnet werden können.<br />Der Berechnungsprozess selbst ist CPU intensiv, stellt aber kein Problem für moderne Computer dar. Aber ca. 50% der Gesamtzeit brauchen die Dateizugriffe für die Vergleiche der Source-Code Dateien.<br />Drei essenzielle Dateien des Projektes werden von Release 0.9.2 bis 1.6 verglichen. Aufgrund der größeren Differenzen treten hier alle sechs konstruierten Fälle auf und demnach können nicht alle Adresse korrekt berechnet werden. Falls die neue Länge einer Methode aber ausgegeben wird, stimmt sie fast immer.<br />Während der Berechnung der neuen Source-Model Daten werden statistische Werte über die Änderungen mitgespeichert. Dadurch ist es möglich Evolutionsdaten bis auf Methodenebene herunter zu brechen, wodurch tiefere Einblicke in die Evolution des Software-Systems gewonnen werden können.