Software-Visualisierung und -Analytics: Stand der Technik und Perspektiven

Anbieter zum Thema

MicroConsult Academy GmbH

Eine allgemeinere Visualisierung von Metriken und Relationen zugleich sind polymetrische Sichten. Polymetrische Sichten stellen binäre Relationen in Form von Graphen dar. Graphen sind in der Mathematik lediglich Knoten und Kanten. Sobald sie aber gezeichnet werden (vgl. Abbildung 9), erhalten sie eine Darstellung, das heißt, ein Ausdehnung, Form und Farbe sowie einen Ort, an dem sie gezeichnet werden. Diese visuellen Eigenschaften können verwendet werden, um weitere Informationen abzubilden.

Knoten haben in der zweiten Dimension eine Höhe und Breite sowie eine X- und Y-Position. Sie haben darüber hinaus eine Farbe. Mit diesen Mitteln können bis zu fünf Metriken dargestellt werden. Darüber hinaus könnte man noch Form und Textur für nominale Information und Farbverlauf für ordinale Information ausnutzen.

Bildergalerie

Bildergalerie mit 14 Bildern

Ein Beispiel für eine polymetrische Sicht ist in Abbildung 10 zu sehen. Wir sehen hier Klassen als Knoten dargestellt. Die Vererbung ist durch Kanten von oben nach unten ausgedrückt. Die Breite der Knoten ist die Anzahl der Attribute einer Klasse und die Höhe die Anzahl der Methoden (jeweils exklusive der ererbten). Der Farbton bildet die Anzahl der Code-Zeilen der Klasse ab. Je dunkler die Klasse ist, desto mehr Code-Zeilen hat sie. Die schwarzen Pfeile markieren besonders interessante Klassen, die allein durch die Betrachtung als statistische Ausreißer herausstechen. Die mit 1 bezeichnete Klasse fällt durch ihre Höhe und dunkle Farbe sofort ins Auge. Offenbar handelt es sich um eine Klasse mit sehr vielen Methoden und einer Anzahl Code-Zeilen, wie sie sonst keine Klasse hat. Diese Klasse sollte untersucht werden, ob sie nicht verkleinert werden kann, indem sie in mehrere kleinere Klassen aufgeteilt wird.

Die zweite Klasse ist im Gegensatz dazu sehr klein in Bezug auf alle drei Größenmetriken. Von ihr leitet auch keine andere Klasse ab. Es wäre hier zu untersuchen, ob diese Klasse überhaupt benötigt wird. Die dritte Klasse ist hoch und breit und hat auch im Verhältnis viele Zeilen Code. Es leitet keine Klasse davon ab. Möglicherweise könnte sie in mehrere Klassen, die voneinander erben, zerlegt werden. Bei der Klassenhierarchie, auf die der Pfeil mit der Nummer vier verweist, fällt auf, dass von zwei Klassen der zweiten Ebene sehr viele weitere Klassen ableiten, während die anderen Klassen dieser Ebene nicht weiter spezialisiert werden. Die fünfte Klasse ist winzig, hat aber zwei recht große Geschwisterklassen und sehr viele Kinderklassen. Das könnte ein Hinweis darauf sein, dass es sich hier um eine abstrakte Klasse handelt.

Das Beispiel zeigt, dass man mit der polymetrischen Sicht sehr viele unterschiedliche Metriken gleichzeitig darstellen und visuell vergleichen kann. Hier wird die menschliche Fähigkeit der visuellen Mustererkennung im Sinne der Visual Analytics ausgenutzt. Durch beliebige Abbildung von Metriken auf die fünf visuellen Attribute Höhe, Breite, X- und Y-Koordinate sowie Farbe kann man sich seine eigene Sicht schaffen, die für den jeweiligen Zweck am besten geeignet ist.

Die Sicht ist jedoch auf fünf Metriken begrenzt und nicht in allen Fällen können die Koordinaten für Metrikwerte verwendet werden. Sobald Kanten gezeichnet werden, bevorzugt man eher ein Layout der Knoten, das den Graph lesbar macht. Dann können die Koordinaten keine andere Semantik haben.

Eine besondere Herausforderung bei Verwendung von Graphen ist die Visualisierung von Relationen. Will man zum Beispiel einen Aufrufgraphen visualisieren, dann liegt es nahe, dies als einen Graphen darzustellen, dessen Knoten die Funktionen und dessen Kanten die Aufrufe zwischen Funktionen repräsentieren. Wenn ein solcher Graph von einem Analysewerkzeug extrahiert wurde, dann haben die Knoten und Kanten jedoch zunächst keine natürlichen Positionen. Die Wissenschaft des Graphzeichnens (engl. Graph Drawing) beschäftigt sich mit Algorithmen, die Knoten und Kanten möglichst effizient so platzieren, dass daraus ein übersichtlicher Graph wird. Ein Beispiel für einen visualisierten Graphen sieht man in Abbildung 11. Der Algorithmus, der die Koordinaten der Knoten berechnet hat, betrachtet die Knoten als Körper und die Kanten als Anziehungskräfte, um dann iterativ eine Anordnung zu bestimmen, die ein Kräftegleichgewicht darstellt. Die Probleme hierbei sind, dass Hierarchien verloren gehen, die Anordnung nicht notwendigerweise die Semantik adäquat widerspiegelt und es zu Kreuzungen von Knoten und Kanten kommt. Es ist der Darstellung nicht ohne weiteres zu entnehmen, wer mit wem verbunden ist.

Eine neue, recht vielversprechende Idee, die Hierarchie der Software zu erhalten und für mehr Übersichtlichkeit bei der Darstellung der Kanten zu sorgen, sind gebündelte Kanten. Ein Beispiel hierfür zeigt Abbildung 12. Die Hierarchie ist als geschachtelte Kreissegmente in Form äußerer Ringe wiedergegeben. In der Mitte finden sich die am tiefsten geschachtelten Elemente, wie zum Beispiel Klassen oder Dateien. In der Mitte ist dann Raum für die Kanten. Diese Anordnung stellt somit sicher, dass Kanten keine Knoten kreuzen können. Darüber hinaus werden die Kanten, die von nah beieinander liegenden Knoten ausgehen und zu nah beieinander liegenden Knoten hinführen, gebündelt. Der Grad der Bündelung kann vom Nutzer eingestellt werden. Im linken Teil von Abbildung 12 findet keine Bündelung der Kanten statt. Im rechten Teil wird gebündelt, wodurch die Darstellung deutlich aufgeräumter wirkt und auch schneller zu erkennen ist, welche Teile mit welchen anderen Teilen verbunden sind. Auch hier kann man jedoch nicht immer ohne weiteres erkennen, welche Knoten mit den Kanten verbunden werden. Dies wird erst durch Selektion von Knoten oder Kanten und dem Ausblenden nicht selektierter Elemente ermöglicht.

Welche Rolle spielen Metaphern?

Metaphern nutzen das Prinzip der Analogie zweier Gegenstandsbereiche und erlauben es, bekannte Aspekte des einen Bereichs auf den anderen Bereich zu übertragen. In der Mensch-Maschine-Kommunikation sind sie allgegenwärtig. Man denke nur an den Papierkorb auf dem Desktop. Beides – Papierkorb und Desktop (Schreibtisch) – sind Alltagsgegenstände, die in graphischen Benutzungsoberflächen nachgebildet sind. Metaphern werden auch in der Software-Visualisierung gerne eingesetzt. Eine der populärsten Metaphern sind die Software-Städte.

Abbildung 13 zeigt ein Beispiel einer solchen Software-Stadt. Dabei werden Klassen eines objektorientierten Programms als Gebäude dargestellt. Wie bei den polymetrischen Sichten werden ausgewählte Metriken (z. B. Anzahl von Methoden, Attribut und Code-Zeilen) dargestellt, die auf die Breite, Länge und in diesem Fall durch die dritte Dimension hinzugekommene Höhe abgebildet werden. Letzten Endes sind Software-Städte nichts weiter als dreidimensionale Tree-Maps. Sie erwecken beim menschlichen Betrachter aber sofort den Eindruck einer Stadt amerikanischen Zuschnitts und wirken weit weniger abstrakt als zweidimensionale Tree-Maps.

Software-Cities eignen sich gut für die Darstellung von Aspekten einer bestimmten Version einer Software. Soll hingegen die Evolution einer Software über verschiedene Versionen hinweg dargestellt werden, sind sie weniger geeignet. Im Verlauf der Evolution können weitere Komponenten hinzukommen oder existierende Komponente wegfallen oder sich ihre Eigenschaften, die durch Höhe, Breite und Länge abgebildet sind, ändern. Tree-Maps sind für eine kompakte Repräsentation auf engem Raum ausgelegt. Das Layout sollte sich aber über verschiedene Visualisierungen von Versionen derselben Software möglichst nicht ändern, da sich ansonsten der menschliche Betrachter nicht mehr zurecht findet.

Eine bessere Darstellung für diesen Zweck sind die Evo-Streets, wie sie in Abbildung 14 abgebildet sind. Die Gebäude sind hier zum Beispiel auch wieder Klassen eines Programms. Die sie verbindenden Straßen bilden den Hierarchiebaum ab. Je schmaler eine Straße ist, desto tiefer ist die dadurch dargestellte Hierarchieebene. Hier wird die Einschränkung aufgegeben, mit einer vorgegebenen Fläche auszukommen. Stattdessen können am Rande Dinge hinzukommen. Die Evo-Streets können sich somit ausdehnen. Das Alter einer Klasse wird darüber hinaus noch durch einen Höhenzug dargestellt. Im Verlaufe der Evolution wächst die Stadt auf einem Gebirge.

Wie kann ich meine eigene Software-Visualisierung selbst implementieren?

Es gibt eine Reihe von kostenlosen und kostenpflichtigen Programme und Frameworks, mit denen man seine eigenen Visualisierungen gestalten kann. Eine einfache Suchanfrage im Internet mit den Schlüsselwörtern „visualization tools“ liefert gleich viele Treffer. Wenn es um Visualisierung in Kombination mit analytischen Methoden geht, dann ist eines der populärsten Frameworks R (https://www.r-project.org/). R ist ein open-source-basiertes Ökosystem von Programmen für statistische Verfahren und Visualisierung. Wer Visualisierungen gestalten möchte, die interaktiv im Browser laufen, wird in der Regel bei D3.js fündig werden (https://d3js.org/). Die genannten Frameworks helfen sehr bei der Visualisierung. Jedoch muss man darüber hinaus auch die Daten extrahieren, die visualisiert werden sollen. Zudem muss die Visualisierung auch zur Problemstellung passen. Das Design der Visualisierung selbst und die Extraktion der Daten nehmen einem die Visualisierungs-Tools nicht ab.

Zusammenfassung

Software-Visualisierung ist in der Wartung unabdingbar, wenn es um Probleme gibt, bei denen ein Mensch eine sehr große Menge von Daten interpretieren muss. Eine spezifische Software-Visualisierung ist immer nur gut für bestimmte Zwecke und schlecht für andere, weil jede Visualisierung bestimmte Information betont und andere Information vernachlässigt. Wann sich eine Visualisierung (oder auch Notation) eignet, besagt die Match-Mismatch-Hypothese von Gilmore und Green:

“Problem-solving performance depends on whether the structure of a problem is matched by the structure of a notation.”

Man sollte also viele mögliche Varianten von Visualisierungen kennen, so dass man die dem Problem angemessene ausfindig machen kann. So wenig wir erwarten würden, dass ein Laie in der Lage ist, Details in einem Ultraschallbild zu erkennen, so wenig sollten wir wohl auch vermuten, dass ein Wartungsprogrammierer beim ersten Blick auf einen speziellen Typ von Software-Visualisierung im Stande ist, etwas zu erkennen. Eine Visualisierung zu verstehen, ist Übungssache. Man spricht hier auch von einem Alphabetismus der Software-Visualisierung. Wir müssen lernen, eine graphische Sprache zu verstehen und uns darin auszudrücken. Und was auf den ersten Blick bunt und schön aussieht, kann sich umgekehrt bei der näheren Beschäftigung als unnütz herausstellen.

Schließlich sei noch angemerkt, dass wir Menschen noch mit vielen weiteren Sinnen ausgestattet sind, von denen wir bei der Darstellung von Software aber kaum Gebrauch machen. Möglicherweise werden wir in der Zukunft unsere Software sogar riechen, schmecken und fühlen können. Tatsächlich gibt es schon erste Ansätze, Software auch zu hören. Zudem ist zu erwarten, dass bald Visualisierungen in Virtual Reality aufkommen werden. Die notwendigen Geräte dafür sind bereits erschwinglich und einige Forschergruppen – unter anderem auch unsere – experimentieren bereits damit.

(Dieser Beitrag wurde mit freundlicher Genehmigung vom Autor dem Tagungsband Embedded Software Engineering Kongress 2017 entnommen.)

* Prof. Dr. Rainer Koschke ist Leiter der Arbeitsgruppe Softwaretechnik an der Universität Bremen. Sein Forschungsschwerpunkt ist die Wartung und Evolution existierender Software. Praktisch einsetzbare Methoden und Werkzeuge für die Weiterentwicklung existierender Software sind das Ziel seiner Forschung. Er ist Mitgründer der Axivion GmbH.

(ID:45490923)