Viele langlebige Systeme existieren in mehreren Varianten, die parallel weiterentwickelt werden mu¨ssen. Hierzu werden unterstu¨tzende Repository-Dienste beno¨tigt, neben dem klassischen Mischen von Dokumenten auch Historienanalysen. Bei Systemen, die mit modellbasierten Methoden (weiter-) entwickelt werden, ergeben sich besondere Probleme, weil auch die Modelle mitversioniert und in die Analysen einbezogen werden mu¨ssen. Dieser Workshopbeitrag beschreibt dieses Problemfeld genauer und skizziert Lo¨sungsansa¨tze, die im Rahmen des SiDiff-Projekts entwickelt wurden.
Die modellbasierte Systementwicklung hat die Konsequenz, daß die Modelle zum integralen Teil der Software werden. Die Modelle mu¨ ssen immer vo¨ llig konsistent sein mit manuell entwickeltem Code, Konfigurationsdaten und sonstigen Ressourcen, die oft in XML-Dateien gespeichert werden. Alle zusammengeh o¨rigen Dokumente – hierzu geho¨ ren natu¨ rlich auch Testdaten, Dokumentationen und sonstige Begleitdokumente – mu¨ ssen gemeinsam versioniert werden.
Die Versionierung von Software wird klassischerweise durch Repository-Systeme wie CVS oder SVN unterst u¨tzt. Diese sind allerdings fu¨ r Texte ohne spezielle Struktur konzipiert worden und arbeiten mit strukturierten Dokumenten, namentlich Modellen, nicht zufriedenstellend. Im Kern sind die u¨ blichen Repository-Dienste auch fu¨ r Modelle erforderlich; Systeme, die dies leisten, bezeichnen wir i.f. als Modell-Repositories. ModellRepositories mu¨ ssen natu¨ rlich nicht nur Modelle, sondern auch beliebige andere Dokumente integriert mitverwalten ko¨ nnen.
Wir konzentrieren uns i.f. auf solche Modell-Repositories, die Funktionen anbieten, die die Weiterentwicklung langlebiger Software mit langen Versionshistorien unterst u¨tzen. 2
Hauptfunktionen von Modell-Repositories. Zur Unterstu¨ tzung von Entwicklungsprozessen werden mit hoher Priorita¨t folgende Dienste bzw. Funktionen von Repositories beno¨ tigt. Diese bauen auf Basisfunktionen zur Verwaltung von Versionsgraphen und anderer administrativer Daten auf. Man kann alle Funktionen in einem einzigen System realisieren oder einige in Form autarker Analysewerkzeuge, solche Implementierungsentscheidungen interessieren uns an dieser Stelle nicht. 1. das Vergleichen und Mischen von Modellen: In großen Projekten ist arbeitsteilige Entwicklung und das gemeinsame Bearbeiten von Dokumenten unvermeidlich. Das exklusive Sperren von Dokumenten fu¨ hrt zu praktischen Problemen, daher hat sich in der Praxis weitgehend die Strategie durchgesetzt, nicht zu sperren, sondern automatisch zu mischen (3-Wege-Mischen). 2. Suchfunktionen, die “gleiche” Modellelemente oder -Fragmente in unterschiedlichen Varianten finden: Wir unterstellen hier, daß bei langlebigen Systemen mehrere Releases bei Anwendern installiert sind. Wenn in irgendeinem der Releases ein kritischer Fehler gefunden wird, muß f u¨r alle anderen Releases gepru¨ ft werden, ob der Fehler dort auch auftritt. In einen Fehler sind in der Regel mehrere Modellelemente involviert. Dieses Modellfragment kann in anderen Releases identisch oder in modifizierter Form auftreten. In diesem Zusammenhang ist es auch wichtig zu wissen, in welcher Version – die nicht notwendig ein Release ist – der Fehler entstanden ist und in welchem Kontext die damaligen A¨nderungen standen. Generell ist es fu¨ r das Versta¨ndnis des Systems oft hilfreich zu wissen, welche Teile warum und zusammen mit welchen anderen Teilen eingefu¨ hrt wurden und wie diese Systemteile weiterentwickelt wurden. 3. historienbasierte Modellanalysen: Ein System, das oft gea¨ndert wird, degeneriert insofern, als die Qualita¨t der Entwurfsentscheidungen immer suboptimaler wird. Im Endeffekt sinkt die Verstehbarkeit des Systems und damit auch die Wartbarkeit, ferner wird die Einscha¨tzung, wie aufwendig bzw. risikoreich weitere A¨ nderungen sind, immer schwieriger. Der Qualita¨tsverlust muß durch Maßnahmen zur Strukturverbesserung kompensiert werden. Fu¨r die Planung solcher Reengineering-Maßnahmen beno¨tigt man Analysefunktionen, die kritischsten Defizite des Systems zu finden helfen. Derartige Analysefunktionen werden auch im Rahmen des Softwarequalita¨tsmanagements fu¨r die Bewertung von Entwicklungsprozessen, zur Vorbereitung von Audits etc. beno¨tigt.
Prinzip direkt von Entwicklern genutzt. Intern weisen sie begriffliche U¨ berschneidungen und Abha¨ngigkeiten auf. Es liegt nahe, ein Repository-System in dementsprechende Subsysteme zu zerlegen. Im folgenden Referenzmodell werden die konzeptuellen Abha¨ngigkeiten und mit den Konzepten direkt korrespondierende Dienste in Form von Schichten dargestellt:
Diese Schicht beinhaltet Dienste zur Speicherung von Dokumenten beliebigen Typs. Eingeschlossen ist die Verwaltung von Nachfolger-Beziehungen zwischen Revisionen, Benutzern und sonstigen administrativen Daten. Diese Schicht wird man in der Regel durch ein etabliertes Repository-Produkt realisieren.
Dieser Schicht liegen Begriffsdefinitionen fu¨r die A¨ hnlichkeit von einzelnen Modellelementen bzw. Modellfragmenten zugrunde. Diese Definitionen gehen direkt in die Berechnung von Modelldifferenzen ein. Allerdings gilt bei manchen A¨ hnlichkeitsbegriffen auch die Umkehrung. Daher kann man die Berechnung von A¨ hnlichkeiten und Differenzen nicht trennen. Aus Dokumentdifferenzen kann man direkt Differenzmetriken ableiten, die typischerweise in der Differenz angegebene Korrespondenzen zwischen Modellelementen oder A¨nderungsoperationen za¨hlen, ggf. gewichtet und/oder selektiert.
Im Gegensatz zu Schicht 0 ist diese Schicht abha¨ngig vom Modelltyp, d.h. pro Modelltyp sind eigene Implementierungen oder zumindest Anpassungen erforderlich.
Dies gilt auch fu¨r die aufbauenden Schichten.
Eine Mischung basiert in der Regel auf einer vorher bestimmten Differenz, da die gemeinsamen Teile nur einmal in das Ergebnis u¨bernommen werden. Die speziellen Teile der zu mischenden Dokumente ko¨nnen unvertra¨glich sein. Zentrale Begriffe dieser Ebene sind daher Konflikte und Strategien zur Konfliktbehandlung.
Diese Schicht realisiert die oben erwa¨hnten Suchfunktionen und historienbasierte Modellanalysen. Sie baut direkt auf Schicht 1 auf und liegt daher parallel zu den Mischfunktionen. Neben der Definition von Suchfunktionen sind hier Verfahren zur Vorverarbeitung und Indexierung von Versionshistorien angeordnet.
Dieser Abschnitt diskutiert den Stand der Technik in den vorstehende benannten Schichten des Referenzmodells. Auf Schicht 0 gehen wir nicht ein, denn hier ist etablierte Technologie verfu¨gbar. 3.1
Die entscheidende interne Funktion ist hier Bestimmung korrespondierender Dokumentteile. Fu¨r textuelle Dokumente sind hinreichend gute und effiziente Algorithmen bekannt, fu¨r graphstrukturierte Modelle ist das Problem deutlich komplizierter. Persistente Darstellungen sind keine geeignete Basis, sondern nur abstrakte Syntaxba¨ume. Besonders schwierig ist die Bestimmung von Korrespondenzen bei Modelltypen, in denen wichtige Modellelemente keine markanten lokalen Eigenschaften haben, sondern deren Nachbarschaft entscheidend ist. Ein zusa¨tzliches Problem bei langlebigen Systemen sind neue Sprachversionen, die zu vera¨nderten Metamodellen fu¨hren.
Der in [
Beim Mischen von Dokumenten ko¨nnen Fehler entstehen, und zwar hinsichtlich kontextfreier bzw. kontextsensitiver Syntax, Programmierstil und Semantik. Paare von Modellteilen (bzw. die sie erzeugenden A¨ nderungen), die solche Fehler erzeugen, stehen in Konflikt zueinander. Mischfunktionen haben daher zwei wesentliche Teilfunktionen, na¨mlich Konflikterkennung und Konfliktbehandlung, also Mischentscheidungen. Beide Teilfunktionen ha¨ngen von der Semantik des Modelltyps ab und sind schwieriger zu realisieren, wenn –
Modelle dieses Typs komplexe Konsistenzkriterien aufweisen und Modelleditoren nur Modelle verarbeiten ko¨nnen, die einen hohen Korrektheitsgrad einhalten; – eventuelle falsch positive Mischentscheidungen von nachfolgenden Entwicklungsschritte nicht oder nur mit hohem Aufwand erkannt werden.
Der Stand der Technik kann hier als rudimenta¨r bezeichnet werden. Fu¨r viele Modelltypen gibt es keine Mischwerkzeuge, viele vorhandene Mischwerkzeuge unterstu¨tzen nur das 2Wege-Mischen auf Syntaxbaumsdarstellungen und bieten nur sehr wenig Unterstu¨tzung. 3.3
Suchfunktionen verallgemeinern die paarweise A¨ hnlichkeit, die schon beim Vergleichen
von zwei Modellen beno¨tigt wurde, auf beliebige Revisions- und Varianten-Ketten oder
allgemeine Sammlungen von Modellen. Die Existenz bzw. Qualita¨t von Suchfunktionen
ha¨ngt daher direkt von den Funktionen ab, die A¨ hnlichkeiten berechnen. Einzelne
Lo¨sungsansa¨tze werden in [
Hauptzweck dieser Funktionen ist, die Qualita¨t eines Systems zu beurteilen und insb. Systemteile (also u.a. Modellfragmente) zu finden, an denen Strukturverbesserungen notwendig sind. Systemteile mit einer geringen Gro¨ße sind in diesem Sinne leichter handhabbar, weil man in vielen Fa¨llen die Defekte formal beschreiben kann (z.B. zu große Klassen oder Zyklen in benutzt-Beziehungen); auf dieser Basis kann man Suchverfahren implementieren, die die entsprechenden Stellen finden. Ferner ist aufgrund der geringen Gro¨ße der Aufwand fu¨r die Reparatur gering, namentlich wenn sie durch Refactorings, ggf. in Verbindung mit Design-Patterns, z.T. automatisierbar ist bzw. durch Werkzeuge unterstu¨tzt wird.
Strukturverbesserungen in gro¨ßeren Systemteilen werfen deutlich mehr Probleme auf: die Definition, wann ein Defekt vorliegt, ist nicht formalisierbar, und vielfach wird nicht alleine der Zustand einer Version zur Beurteilung herangezogen, sondern Merkmale der A¨ nderungshistorie, d.h. es wird vom Entwicklungsprozeß auf die Qualita¨t des Produkts geschlossen. Beispielsweise sind Defizite in Systemteilen, in denen wiederholt gro¨ßere A¨nderungen stattfanden, wahrscheinlicher. Das Auffinden von suspekten Systemteilen ist eher als ein Information-Retrieval-Problem anzusehen, bei dem es darum geht, unter den vielen mo¨glichen Verbesserungsmaßnahmen diejenigen mit dem gro¨ßten Nutzen und den geringsten Kosten herauszufinden. Wegen der ho¨heren Umbaukosten ko¨nnen na¨mlich i.d.R. nur wenige derartige Maßnahmen durchgefu¨hrt werden.
Visualisierung von Historien. Die geforderten Analysen ganzer Versionshistorien stehen vor dem Problem der Informationsu¨berflutung: einzelne Versionen sind i.d.R. schon sehr umfangreich, das Datenvolumen steigt infolge der Versionen um 1 - 2 Gro¨ßenordnungen.
Viele Analyseverfahren nutzen daher Metriken, einzelne Versionen werden also nicht mehr in allen Details dargestellt, sondern auf ihre Metrikwerte reduziert. “Auffa¨llige” Versionen bzw. Vorkommnisse in der Versionshistorie ko¨nnen nur noch anhand der Metrikwerte bzw. der numerischen Differenzen der Metrikwerte erkannt werden.
Auf Metriken basieren auch fast alle Methoden zur Visualisierung von Historien. Die
bekannten Methoden zur Visualisierung von großen naturwissenschaftlichen Datenmengen
versagen aber bei Modellen weitgehend, weil hier die Grundstruktur des Datenraums nicht
ein homogenes 3D-Gitter ist, sondern durch die wesentlich komplizierteren Strukturen in
Modellen gepra¨gt ist. Es sind diverse Vorschla¨ge fu¨r 2- oder 3-dimensionale
Visualisierungen von Versionshistorien gemacht worden, die teilweise auf einer 2-dimensionalen
Darstellung einzelner Versionen basieren, u.a. die Evolution Matrix [
Ein genereller Nachteil der vorstehenden Ansa¨tze ist, daß die gewohnte graphische Darstellung der Modelle, in der die Systemstrukturen gut dargestellt werden, nicht mehr eingesetzt wird. Wegen der geometrischen Eigenschaften ist es sogar prinzipiell fraglich, ob man die gewohnten Darstellungsformen u¨berhaupt fu¨r Historien einsetzen kann; sie stoßen bei großen Modellen ohnehin an ihre Grenzen und sind nicht fu¨r die Darstellung von Historien konzipiert worden. Vera¨nderungen an den Strukturen eines Systems za¨hlen indes zu den interessantesten Vera¨nderungen. 4
Dieser Abschnitt skizziert einige Lo¨sungsansa¨tze, die fu¨r die Visualisierung von
ModellHistorien im Kontext des SiDiff-Projekts [
U¨ bliche Metriken fu¨r Modelle sind Za¨hlungen von Strukturelementen, z.B. die Zahl der Attribute einer Klasse in einem Klassendiagramm oder die Zahl der ausgehenden Transitionen eines Zustands in einem Zustandsmodell. Wenn nun die ein Attribut durch ein anderes ersetzt wird oder eine Transition durch eine andere, a¨ndern sich die Metrikwerte nicht, obwohl signifikante A¨ nderungen stattgefunden haben. Anders gesagt sind die numerischen Differenzen der Metrikwerte nur ein unzuverla¨ssiger Indikator fu¨r den Umfang der A¨ nderungen.
Die naheliegende Lo¨sung besteht darin, zuna¨chst eine vollsta¨ndige (korrekte) Differenz
[
Differenzmetriken und Werkzeuge, die diese unterstu¨tzen, mu¨ssen spezifisch fu¨r
einzelne Modelltypen entwickelt werden, da jeder Modelltyp eigene Editieroperationen und
Konsistenzkriterien hat. Das reine Graphiksystem eines Werkzeugs kann weitgehend
unabha¨ngig von den Modelltypen entwickelt werden (s. z.B. [
3-dimensionale Darstellungen von Versionshistorien ko¨nnen grob eingeteilt werden in solche, die Strukturen der Modelle direkt anzeigen, auf dieser Basis natu¨rlich auch Vera¨nderungen der Strukturen, und andere, die i.w. nur Metrikwerte anzeigen.
Anzeige von Modellstrukturen. Ein Beispiel fu¨r die erste Kategorie ist der
StructureChangesView im Werkzeug Evolver [
Abbildung 1: StructureChangesView im Werkzeug Evolver Die Kameraposition kann beliebig zwar in Realzeit vera¨ndert werden (“Ego-Shooter”), normalerweise ist sie vor der vordersten Scheibe, so auch in Bild 1. Nur diese vorderste Version kann man also unbehindert erkennen, die dahinterliegenden Versionen werden von den davorliegenden teilweise verdeckt. Die vorneliegende Version ist die am meisten interessierende; um diese von den anderen optisch abzuheben, werden die hinteren Versionen immer transparenter gezeichnet. Die Knoten der Graphen werden vereinfacht dargestellt; wu¨ rde man alle Details einer Klasse oder eines Zustands darstellen, wa¨ren diese nicht mehr lesbar.
Diese Darstellung ist gut geeignet, um bestimmte Typen von A¨ nderungen zu erkennen, allerdings hat sie durchaus Limitationen: – –
Die Zahl der angezeigten Entita¨ten muß klein sein. Fu¨ r eine erste Gesamtu¨ bersicht u¨ ber ein unbekanntes System ist diese Darstellung daher wenig geeignet, sie ist eher nach einer Einschra¨nkung der Menge der zu untersuchenden Entita¨ten sinnvoll. Gute Mo¨ glichkeiten zur Selektion der angezeigten Entita¨ten sind daher sehr wichtig. Es kann nur eine beschra¨nkte Zahl von Versionen sinnvoll angezeigt werden, ca. 5 Versionen sind noch gut erkennbar, ab ca. 10 Versionen wird die Darstellung trotz transparenter Darstellung unbrauchbar. Die Zahl der anzeigten Versionen sollte in Realzeit vera¨nderbar sein, ebenso die vorne angezeigte Version. Wu¨ nschenswert ist ferner eine Funktion, die aus der gesamten Revisionskette besonders interessante Versionen anhand bestimmter Kriterien selektiert.
Metrikbasierte Darstellungen. Ein Beispiel fu¨ r die zweite o.g. Kategorie ist der EvolutionView im Werkzeug Evolver, s. Bild 2. Diese zeigt fu¨ r jede Version und jede Entita¨t eine Sa¨ule. Die Ho¨ he einer Sa¨ule ergibt sich anhand einer Metrik, angewandt auf diese Entita¨t in dieser Version. Bei der Kameraposition, die in Bild 2 gewa¨hlt ist, verla¨uft die “Zeit” von hinten nach vorne. Von links nach rechts sind die angezeigten Entita¨ten angeordnet. In Bild 2 ist eine der Entita¨ten selektiert und alle zugeordneten Sa¨ulen u¨ ber alle Versionen hinweg sind dunkler gezeichnet.
Abbildung 2: EvolutionView An den Seiten befinden sind zusa¨tzlich noch zwei Spektrographen: diese zeigen die Ha¨ufigkeitsverteilungen der Metrikwerte an. Hierzu wird der Wertebereich der Metrik in ca. 10 Intervalle eingeteilt, entsprechend viele kleine u¨bereinanderliegende Rechtecke stehen auf einer Spektrographen-Wand zur Verfu¨gung. Mit einer Farbcodierung wird die Zahl der Sa¨ulen, deren Gro¨ße im jeweiligen Intervall liegt, angezeigt. Die in Bild 2 vorne sichtbare Spektrographen-Wand zeigt die Ha¨ufigkeitsverteilungen der Metrikwerte pro Entita¨t u¨ber die Systemversionen hinweg an, die seitlich sichtbare Wand die Ha¨ufigkeitsverteilungen pro Systemversion.
Animationen. Die beiden vorigen Darstellungsformen haben die zeitliche Reihenfolge, die durch eine Folge von Revisionen eines Systems entsteht, auf eine Dimension eines 3-dimensionalen graphischen Objekts abgebildet. Ein vo¨llig anderer Ansatz besteht darin, die zeitliche Reihenfolge durch eine Animation darzustellen. Basis kann eine geeignete 2oder 3-dimensionale Darstellung einzelner Versionen sein. Dies muß allerdings so gewa¨hlt sein, daß die Bewegungen gut erkennbar sind, also nicht zu geringfu¨gig und nicht zu heftig sind.
Ein Beispiel findet sich im EvolutionView des Werkzeugs Evolver, s. Bild 3, das nur ein
Bild einer Animation zeigt. Komplette Animationen ko¨nnen auf der WWW-Seite des
Projekts [
Abbildung 3: AnimationView
formen haben jeweils eigene Sta¨rken und Schwa¨chen und mu¨ssen in einer integrierten Form verfu¨gbar sein, in der man nahtlos zwischen diesen und weiteren Darstellungen, auch von Einzelversionen, wechseln kann.
Erste kontrollierte Evaluationen der oben vorgestellten Darstellungsformen zeigten, daß die EvolutionView aus Anwendersicht den gro¨ßten Nutzen brachte, gefolgt von der AnimationView. Am schlechtesten schnitt die StructureChangesView ab. 5
Die modellbasierte Systementwicklung erfordert fu¨r Modelle die gleichen RepositoryDienste, die man bei textuellen Dokumenten gewohnt ist. In der Praxis und hinsichtlich der technologischen Grundlagen ist man hiervon noch weit entfernt.
Das aus Sicht der Praxis dra¨ngendste Problem stellen Misch- und Vergleichswerkzeuge dar. Fu¨r viele Modelltypen sind keine brauchbaren Werkzeuge verfu¨gbar, die verfu¨gbaren Werkzeuge unterstu¨tzen nur das zeitaufwendige manuelle Mischen und bieten nur beschra¨nkte Unterstu¨tzung bei der Konflikterkennung.
Analysefunktionen, die die Weiterentwicklung von Systemen mit vielen Revisionen bzw. Varianten unterstu¨tzen, existieren nur als Forschungsprototypen. Hier ist noch viel Raum fu¨r Verbesserungen vorhanden, sowohl bei der Entwicklung weiterer Darstellungsformen als auch bei der Integration verschiedener Darstellungsformen und Optimierung hinsichtlich der praktischen Nutzung.