Einf ührung

Große Systeme, die über viele Jahre existieren und während dieser Zeit immer wieder erweitert und umstrukturiert werden, werfen große Wartungsprobleme auf. Gewartet werden müssen typischerweise nicht nur die aktuelle Version des Systems, sondern auch ältere Releases, die noch bei Kunden im Einsatz sind. Neben historisch entstandenen Varianten können auch aus produktbezogenen Gründen Varianten entstehen. Im Endeffekt müssen mehrere Systemvarianten, die zwar erhebliche Gemeinsamkeiten, aber auch signifikante Unterschiede aufweisen können, parallel weiterentwickelt werden.

Ein heute stark favorisierter Ansatz zur Reduktion der Entwicklungs-und Wartungsaufwände ist die modellbasierte Systementwicklung [10], also die Generierung von Teilen des Systems aus Modellen. In diesem Kontext werden auch domänenspezifische Sprachen diskutiert, die meist eine vorhandene Modellierungssprache erweitern 1 . Insb. die adaptive Wartung infolge von neuen Versionen unterliegender Systeme (DBMS, BS u.a.) kann so erleichtert werden. Die eingesetzten Modelltypen hängen natürlich von den Merkmalen der Anwendungsdomäne ab. Häufig eingesetzt werden Datenmodelle, meist eine Variante der UML-Klassendiagramme. Für eingebettete Systeme werden vor allem Zustandsmodelle und Funktions-bzw. Aktivitätsmodelle eingesetzt. Die Anwendungsdomänen unterscheiden sich auch darin, wie große Teile eines Systems aus den Modellen generiert werden können: im Idealfall alles, oft müssen jedoch umfangreiche Teile manuell entwickelt werden.

Die modellbasierte Systementwicklung hat die Konsequenz, daß die Modelle zum integralen Teil der Software werden. Die Modelle müssen immer völlig konsistent sein mit manuell entwickeltem Code, Konfigurationsdaten und sonstigen Ressourcen, die oft in XML-Dateien gespeichert werden. Alle zusammengehörigen Dokumente -hierzu gehören natürlich auch Testdaten, Dokumentationen und sonstige Begleitdokumente -müssen gemeinsam versioniert werden.

Die Versionierung von Software wird klassischerweise durch Repository-Systeme wie CVS oder SVN unterstützt. Diese sind allerdings für Texte ohne spezielle Struktur konzipiert worden und arbeiten mit strukturierten Dokumenten, namentlich Modellen, nicht zufriedenstellend. Im Kern sind die üblichen Repository-Dienste auch für Modelle erforderlich; Systeme, die dies leisten, bezeichnen wir i.f. als Modell-Repositories. Modell-Repositories müssen natürlich nicht nur Modelle, sondern auch beliebige andere Dokumente integriert mitverwalten können.

Wir konzentrieren uns i.f. auf solche Modell-Repositories, die Funktionen anbieten, die die Weiterentwicklung langlebiger Software mit langen Versionshistorien unterstützen.

Technologische Herausforderungen

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 verfügbar.

Differenzberechnung

Die Der in [6] publizierte Vergleich von Algorithmen zeigt die Spannbreite der aktuell bekannten Lösungen und die jeweiligen Kompromisse auf:

-Verbreitet sind Verfahren, die auf Basis persistenter Identifizierer von Modellelementen arbeiten. Sie sind sehr effizient und leicht implementierbar, basieren aber auf sehr einschränkenden Voraussetzungen und Annahmen, die bei langlebigen, großen Systemen praktisch nicht erfüllbar sind. Sie bieten wenig bzw. keine Unterstützung für die Konfliktbehandlung und ähnlichkeitsbasierte Suchverfahren, weil die Semantik der Dokumenttypen nicht bekannt ist.

-Auf der anderen Seite stehen dedizierte Algorithmen für einzelne Sprachen bzw. Dokumenttypen, die besonders hochwertige Vergleichs-bzw. Mischergebnisse liefern, dafür aber relativ ineffizient sind und einen sehr hohen (um nicht zu sagen prohibitiven) Implementierungsaufwand verursachen, weil sie für jeden Modelltyp weitgehend neu entwickelt werden müssen.

-Frameworks wie das System SiDiff [5] zielen mittels einer "Sprache" zur Spezifikation von Ähnlichkeiten auf einen tragfähigen Kompromiß zwischen Laufzeiteffizienz, Qualität der Ergebnisse und Implementierungsaufwand der Algorithmen.

Qualitativ gute Algorithmen sind aktuell nur verfügbar für Klassendiagramme (Datenmodelle) in diversen Varianten, insb. für reverse engineerte Java-Quellprogramme, ferner für einfachere Varianten von Aktivitätsdiagramme und Zustandsautomaten. Für andere Modelltypen und domänenspezifischen Sprachen ist wenig oder nichts verfügbar. Weiterer Forschungs-und Entwickungsbedarf besteht hinsichtlich der Gestaltung der Metamodelle, der Qualitätsbeurteilung bzw. Optimierung von Differenzen und der Evolution der Metamodelle.

Mischfunktionen

Beim

Suchfunktionen

Suchfunktionen verallgemeinern die paarweise Ähnlichkeit, die schon beim Vergleichen von zwei Modellen benötigt wurde, auf beliebige Revisions-und Varianten-Ketten oder allgemeine Sammlungen von Modellen. Die Existenz bzw. Qualität von Suchfunktionen hängt daher direkt von den Funktionen ab, die Ähnlichkeiten berechnen. Einzelne Lösungsansätze werden in [2,13,14] diskutiert, von einem flächendeckenden Angebot praxiserprobter Lösungen ist man aber noch weit entfernt.

Analysefunktionen

Hauptzweck [7], die auf polymetrischen Sichten [8] basiert, Evo Spaces [16], die sich optisch an Stadtbilder anlehnen, Gevol [3], das Evolution Radar [1] und weitere Systeme.

Ein genereller Nachteil der vorstehenden Ansä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 überhaupt für Historien einsetzen kann; sie stoßen bei großen Modellen ohnehin an ihre Grenzen und sind nicht für die Darstellung von Historien konzipiert worden. Veränderungen an den Strukturen eines Systems zählen indes zu den interessantesten Veränderungen.

Lösungsansätze zur Visualisierung von Modell-Historien

Dieser Abschnitt skizziert einige Lösungsansätze, die für die Visualisierung von Modell-Historien im Kontext des SiDiff-Projekts [11] entwickelt wurden.

Metriken von Differenzen statt Differenzen von MetrikenÜbliche

3D-Darstellungen und Animation

3-dimensionale Darstellungen von Versionshistorien können grob eingeteilt werden in solche, die Strukturen der Modelle direkt anzeigen, auf dieser Basis natürlich auch Veränderungen der Strukturen, und andere, die i.w. nur Metrikwerte anzeigen. Diese Darstellung ist gut geeignet, um bestimmte Typen von Änderungen zu erkennen, allerdings hat sie durchaus Limitationen:

Anzeige von

-Die Zahl der angezeigten Entitäten muß klein sein. Für eine erste Gesamtübersicht über ein unbekanntes System ist diese Darstellung daher wenig geeignet, sie ist eher nach einer Einschränkung der Menge der zu untersuchenden Entitäten sinnvoll. Gute Möglichkeiten zur Selektion der angezeigten Entitäten sind daher sehr wichtig.

-Es kann nur eine beschränkte Zahl von Versionen sinnvoll angezeigt werden, ca. Zusätzlich kann eine der Entitäten ausgewählt werden, deren Beziehungen zu anderen Entitäten dargestellt werden.

Res ümee

Die modellbasierte Systementwicklung erfordert für Modelle die gleichen Repository-Dienste, 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 drängendste Problem stellen Misch-und Vergleichswerkzeuge dar. Für viele Modelltypen sind keine brauchbaren Werkzeuge verfügbar, die verfügbaren Werkzeuge unterstützen nur das zeitaufwendige manuelle Mischen und bieten nur beschränkte Unterstützung bei der Konflikterkennung.

Analysefunktionen, die die Weiterentwicklung von Systemen mit vielen Revisionen bzw. Varianten unterstützen, existieren nur als Forschungsprototypen. Hier ist noch viel Raum für Verbesserungen vorhanden, sowohl bei der Entwicklung weiterer Darstellungsformen als auch bei der Integration verschiedener Darstellungsformen und Optimierung hinsichtlich der praktischen Nutzung.