Metamodellbasierte Generierung von kundenspezifischen Software-Leitst¨anden
Tobias R¨otschke
tobias.roetschke@es.tu-darmstadt.de
Abstract:Dieses Papier beschreibt einen Ansatz, bei dem architektur- und quelltext- bezogene Strukturierungskonzepte, Metriken und Konsistenzregeln entsprechend der jeweiligen Terminologie des Kunden in einem Metamodell mit dazugeh¨origen visuel- len Anfrageregeln spezifiziert werden. Mit Hilfe des Metamodellierungsrahmenwer- kes MOFLON k¨onnen aus dieser Spezifikation Analysewerkzeuge erstellt werden, die den zeitlichen Verlauf der benutzerdefinierten Metriken und Regelverst¨oße darstel- len und dabei eine Navigation ¨uber benutzerdefinierte Strukturkonzepte erlauben. Auf diese Weise sollt die Arbeit einen Beitrag zur effizienten Erstellung von maßgeschnei- derten Software-Leitst¨anden liefern.
1 Einleitung
Ziel von Software-Leitst¨anden ist es, allen Beteiligten zur Optimierung des Entwicklungs- prozesses kontinuierlich mit den f¨ur sie wesentlichen Informationen ¨uber den Qualit¨ats- zustand des gerade entwickelten Produktes zu versorgen. Ein wichtiger Aspekt ist es da- bei, Fehlentwicklungen fr¨uhzeitig zu erkennen und deren Ursache schnell zu lokalisieren, damit zeitnah Gegenmaßnahmen eingeleitet werden k¨onnen.
Im Bereich der statischen Software-Analyse bieten existierende L¨osungen eine Vielzahl von vordefinierten Metriken und Visualisierungsformen an, um die Struktur einer Soft- ware-Architektur verstehen und bewerten zu k¨onnen. Allerdings ist zur optimalen Nutzung eines m¨achtigen Werkzeugs ein erheblicher Einarbeitungsaufwand n¨otig, zumal viele Ent- wicklergruppen eine individuelle Terminologie entwickeln, die sich zuweilen nicht unmit- telbar auf die Terminologie des jeweiligen Werkzeuges abbilden l¨asst (vgl. z. B. [GE05, KB05]). Dar¨uber hinaus besteht die Gefahr, das zum einen ein Großteil der verf¨ugbaren Daten nicht ben¨otigt wird, w¨ahrend andererseits sehr spezifische Fragestellungen nicht be- antwortet werden k¨onnen. Der hier vorgestellte Beitrag bietet einen metamodellbasierten Ansatz zur Erstellung von kundenspezifischen Software-Leitst¨anden. Dieser setzt existie- rende Analysewerkzeuge zur Berechnung elementarer Quelltextmetriken etc. voraus und erlaubt, darauf aufbauend abgeleitete Metriken auf kundenspezifischen Architekturkon- zepten zu definieren und zu berechnen.
Der Rest dieses Artikels ist wie folgt gegliedert: In Abschnitt 2 wird das grunds¨atzliche Prinzip von Software-Leitst¨anden erl¨autert. Anschließend werden in Abschnitt 3 die M¨og- lichkeiten zur dom¨anenspezifischen Modellierung von Software-Leitst¨anden diskutiert. In
Abschnitt 4 wird erl¨autert, wie die Generierung von dazugeh¨origen Visualisierungswerk- zeugen m¨oglich wird. Die Ergebnisse dieser Arbeit werden in Abschnitt 5 zusammenge- fasst und m¨ogliche Fortsetzungen diskutiert.
2 Grundlagen
Software-Leitst¨ande sind komplexe Werkzeuge zur Qualit¨atssicherung, die es erlauben, Daten ¨uber Software-Systeme zu sammeln und diese in geeigneter Form f¨ur verschiedene Anwender darzustellen. Das in Abb. 1 dargestellte Grundprinzip trifft auch auf klassische Reverse-Engineering-Werkzeuge zu (vgl. z. B. [Kri99]).
Das Fundament jedes Software-Leitstandes ist eine Datenbank, in der Informationen ¨uber das Software-System zentral abgelegt werden k¨onnen. Aufgrund der h¨aufig großen Daten- mengen erfolgt das F¨ullen und Auslesen der Datenbank ¨ublicherweise asynchron. Dazu werden in einem automatisierten Prozess die vorhandenen Quelltexte, Modelle, und ande- re Dokumente regelm¨aßig eingelesen und in der Datenbank abgelegt. Anschließend wer- den diese Daten aufbereitet, indem unwichtige Daten heraus gefiltert, Detailinformatio- nen zusammengefasst und die Ergebnisse anhand von vorher definierten Regeln bewertet werden. Diese Daten k¨onnen anschließend in einer der Rolle des jeweiligen Betrachters angemessenen Form dargestellt werden [Adv05, LD03, LS02].
G¨angige Reverse-Engineering-Werkzeuge erlauben nur die Betrachtung eines Software- Systems zu einem bestimmten Zeitpunkt, prim¨ar mit dem Ziel, das Verst¨andnis der Soft- ware zu erm¨oglichen bzw. einmalige Verbesserungsmaßnahmen zu planen. Dagegen steht bei Software-Leitst¨anden der zeitliche Verlauf der Messgr¨oßen im Vordergrund, um auf diese Weise problematische Trends zeitnah identifizieren und aufhalten zu k¨onnen.
Im Vergleich zur dieser Arbeit ist besonders das Werkzeug Sotograph [BKL04] hervorzu- heben, welches ¨uber viele Eigenschaften eines Software-Leitstandes verf¨ugt. Dieses kom- merzielle Werkzeug erm¨oglicht die architekturzentrierte Trendanalyse von vordefinierten
Daten
Definition Daten Modellieren
Bewerten, Filtern, Zusammenfassen Erfassen,
Messen Darstellen
Abbildung 1: Allgemeines Prinzip von Software-Leitst¨anden
Software-Metriken. Zur Abstraktion der Ergebnisse auf Architektur-Niveau k¨onnen Quell- textverzeichnisse mit Hilfe einer Skript-Sprache auf vordefinierte Architekturkonzepte ab- gebildet werden. Im Gegensatz dazu besch¨aftigt sich der Autor mit der Generierung von Analysewerkzeuge f¨urfrei definierbare Metriken und Architekturkonzepte, ohne dabei Aspekte wie Parsen und Datenbankoptimierung vertiefen zu k¨onnen.
Wie sich im Folgenden herausstellen wird, erfordert der Einsatz von MOFLON Kennt- nisse, der Erlangung man nicht jedem einzelnen Entwickler zumuten kann. Die Spezifi- kation dieser Werkzeuge mit MOFLON muss also von geschulten Softwarearchitekten, Qualit¨atssicherungs-Spezialisten oder externen Beratern erstellt werden. Dagegen sollen die von MOFLON generierten Analysewerkzeuge m¨oglichst einfach zu verwenden und die Darstellung der Ergebnisse auf die Rolle des jeweiligen Benutzers zugeschnitten sein, um einen m¨oglichst großen Nutzen bei geringem Einarbeitungsaufwand zu erzielen.
3 Modellierung von Software-Leitst¨anden
Als Beispiel nehmen wir ein Software-System namens ”Fujaba Toolsuite“[Z¨un01], in wel- chem zuk¨unftig alle Methoden entfernt werden sollen, die als ”deprecated“markiert sind.
Dazu m¨ussen alle Aufrufstellen durch Alternativen ersetzt werden. Zur Unterst¨utzung der Aktion soll ein Werkzeug eingesetzt werden, dass die Anzahl dieser Aufrufstellen f¨ur jedes Zwischen-Release misst und in einem Balkendiagramm darstellen kann. Erl¨auternd muss hierzu erw¨ahnt werden, dass Fujaba aus eigenem Interesse untersucht wurde, da MOFLON als Erweiterung von Fujaba realisiert wurde. Um Verwirrung zu vermeiden, sprechen wir im Folgenden von ”Fujaba“ als Untersuchungsgegenstand und ”MOFLON“ als Generator f¨ur Analysewerkzeuge.
3.1 Erstellen eines Informationsmodells
Abb. 2 beschreibt das dazugeh¨orige Informationsmodell, wie es z. B. der Software-Architekt erstellen w¨urde. Es wurde von Hand als MOF 2.0-Diagramm in unserem Metamodellie- rungswerkzeug MOFLON [AKRS06] eingegeben. Die Spezifikation wurde zur sauberen Trennung von projektspezifischen Architekturkonzepten und Metriken auf zwei Pakete,
”Fujaba“ und ”FujabaMetrics“ aufgeteilt.
Die Toolsuite besteht aus mehreren Teilsystemen (”Subsystem“). Die meisten Teilsyste- me sind Plugins, die zur Laufzeit in die Toolsuite integriert werden. Plugins k¨onnen von einander abh¨angen (”depends-on“).
Genau eines der Teilsysteme ist der so genannte Kern (”Core“). Dies wird durch eine entsprechende Redefinition des Assoziationsendes ”subsystem“ ausgedr¨uckt. Jedes Teil- system besteht aus einer Menge von Klassen (”Class“). In einem Attribut ”deprecatedMe- thods“ wird die Anzahl der Aufrufe von als ”deprecated“ markierten Methoden abgelegt.
Im Folgenden gehen wir davon aus, dass ein Skript vorliegt, welches zu jedem Zwischen-
Abbildung 2: Projektspezifisches Informationsmodell
Release eine Instanz dieses Informationsmodells erzeugt. Dieses liegt als Hauptspeicher- Repository vor, auf welches ¨uber JMI-Schnittstellen (Java Metadata Interface, [Mos02]) zugegriffen werden kann.
3.2 Erg¨anzung des Informationsmodells um Metriken
Abb. 3 zeigt die Spezifikation f¨ur die Aggregation der Metrik ”deprecatedMethods“ von Klassen- auf Plugin-Niveau (so genanntesLifting, vgl. [Kri99]). Die Metrik wird als ab- geleitetes Attribut der erweiterten Klasse ”Plugin“ betrachtet und durch eine visuell spe- zifizierte Ableitungsregel definiert. F¨ur den Kern sei eine eigene, Abb. 3 entsprechende Ableitungsregel vorhanden.
Zur Definition der Ableitungsregel verwendet MOFLON einStory-Diagramm [Z¨un01].
Diese Notation lehnt sich an UML-Aktivit¨atsdiagramme zur Definition des Kontrollflusses an. Das Story-Diagramm in Abb. 3 enth¨alt f¨unf derartige Aktivit¨aten, die durch Rechtecke mit abgerundeten Ecken dargestellt werden. Im Gegensatz zu normalen UML-Aktivit¨ats- diagrammen sind Aktivit¨aten mit Inhalt versehen. Vorzugsweise handelt es sich dabei um modifizierte Objektdiagramme, die Muster auf einem Instanzgraphen beschreiben sowie
¨Anderungen, die bei erfolgreichem Erkennen des Musters am Instanzgraphen vorgenom- men werden. Alternativ k¨onnen Aktivit¨aten in Story-Diagrammen auch normalen Java- Code enthalten. Im Folgenden wird das Story-Diagramm aus Abb. 3 schrittweise erl¨autert.
Abbildung 3: Projektspezifische Metrik
Ausgehend vom Startknoten wird zun¨achst ein tempor¨ares Objekt namens ”result“ erzeugt und mit dem Wert ”0“ initialisiert. Anschließend wird die folgende, mit einem doppelten Rahmen gekennzeichnete Aktivit¨at ausgef¨uhrt (eine sogenannte ”foreach-Activity“). Die- se Aktivit¨at enth¨alt ein einfaches Objektdiagramm mit zwei Objekten. Das mit ”this“ ge- kennzeichnete Objekt repr¨asentiert die Instanz des aktuell betrachteten Plugins, auf dem die Methode ”getDeprecatedMethods() aufgerufen wird. Dieses Objekt ist ¨uber einen Link mit dem zweiten Objekt verbunden, welches ein Plugin repr¨asentiert, von welchem das ak- tuelle Plugin abh¨angt, und zur weiteren Berechnung einer lokalen Variablen ”p“ zuweist.
Auf Grund des doppelten Rahmens wird nicht nur ein beliebiges Plugin ausgew¨ahlt, son- dern es werden viel mehr alle passenden Plugins der Reihe nach besucht. Auf diese wird dann jeweils die ¨uber eine mit ”each time“ markierte Transition erreichbare Aktivit¨at an- gewendet. Diese beinhaltet einen in Java geschriebenen, rekursiven Methodenaufruf zur Methode ”getDeprecatedMethods()“ und addiert das erhaltene Ergebnis zum bisherigen Ergebnis ”result“.
Anschließend werden auf dieselbe Weise alle Ergebnisse der im aktuellen Plugin enthalte- nen Klassen aufgesammelt und zum Ergebnis addiert. Letztlich wird das Gesamtergebnis als Resultat des aktuellen Methodenaufrufs zur¨uckgegeben. Vielleicht mag dem dem Le- ser die hier verwendete visuelle Notation bei einem wie hier verwendeten kleinen Beispiel als zu aufw¨andig im Vergleich zu einer gewohnten textuellen Notation erscheinen; jedoch entfaltet sie ihre ganze St¨arke bei realistischen und somit komplexeren Spezifikationen, bei denen Navigationen ¨uber mehrere Objekte erforderlich werden.
Abbildung 4: Generiertes Balkendiagramm in Eclipse
4 Generierung der Visualisierung
Die Generierung der gew¨unschten Visualisierungswerkzeuge erfolgt unter der Annahme, dass Metriken als ein- oder zweistellige Funktionen vorliegen, die einen numerischen Wert zur¨uck liefern, wobei der erste Parameter immer implizit das Objekt ist, auf der die Ab- leitungsregel aufgerufen wird, und der zweite Parameter ein anderes Objekt. Betrachtet man zus¨atzlich noch den zeitlichen Verlauf von Metriken, kommt ein Zeitpunkt als zus¨atz- licher Parameter hinzu. Verschiedene Darstellungsformen eignen sich zur Visualisierung der Funktionen, unabh¨angig von der konkreten Art der Metrik.
Da die Metrik ”deprecatedMethods“ eine einstellige Funktion ist, eignet sich eine Dar- stellung als Balkendiagramm wie in Abb. 4, welche von unserem Rahmenwerk generiert werden kann. Jeder Balken zeigt den Wert der Metrik f¨ur ein Teilsystem der Toolsuite an.
Ebenso kann der zeitliche Verlauf der Metrik f¨ur ein bestimmtes Teilsystem dargestellt werden, wobei man gegebenenfalls den unteren Teil der Balken abschneiden w¨urde, um die ¨Anderungen im betrachteten Zeitrahmen hervorzuheben. M¨ochte man die Metrikwerte aller Teilsysteme zu verschiedenen Zeitpunkten gleichzeitig betrachten, ist eine Linien- schar bestehend aus Linien unterschiedlicher Farben eine geeignetere Darstellungsform.
Um die Generierung zu erm¨oglichen, wird ein Konfigurationsmechanismus verwendet, der hier aus Platzgr¨unden nicht im Detail erl¨autert werden kann. Dieser sorgt f¨ur die Ab- bildung der Elemente des Informationsmodells auf die Hierarchie des Visualisierungs- werkzeuges, die Auswahl der Darstellungsform, und die Zuordnung von Elementen des Informationsmodells zu den Freiheitsgraden der Darstellung. Exemplarisch sei hier noch die erstgenannte Problematik kurz erl¨autert:
Im Allgemeinen sollen generierte Analysewerkzeuge nur bestimmte Elemente visualisie-
ren, um die zur Verf¨ugung gestellten Information auf eine sinnvolles Maß zu beschr¨anken.
Zur Navigation wird davon ausgegangen, dass ein definierter Teil der durch Kompositions- beziehungen im Metamodell aufgespannten Hierarchie mit der Hierarchie des Visualisie- rungswerkzeuges korrespondiert. Bestimmte Methoden oder Attribute sollen als Metrik in- terpretiert werden, aber offensichtlich ist nicht jede Methode im Metamodell automatisch eine Metrik. Wie in Abb. 2 angedeutet, wird das eigentliche Metamodell (Paket ”Fujaba“) von der Metrikspezifikation unterschieden (Paket ”FujabaMetrics“). Zwischen diesen Pa- keten besteht eine in UML 2.0 bzw. MOF 2.0 neu eingef¨uhrte ”Merge“-Beziehung, welche
”FujabaMetrics“ als Redefinition des Pakets ”Fujaba“ charakterisiert. Nur Elemente, die in dem redefinierenden Paket ”FujabaMetrics“ enthalten sind, werden zur Generierung des Visualisierungswerkzeuges herangezogen.
5 Zusammenfassung und Ausblick
In diesem Beitrag wird dargelegt, wie Visualisierungskomponenten von Software-Leit- st¨anden aus kundenspezifischen Informationsmodellen und Metrikdefinitionen generiert werden k¨onnen. Die vorliegende Implementierung wurde im Rahmen einer Diplomarbeit [Sch06] erstellt und unterst¨utzt bislang die drei Visualisierungsformen Balkendiagramm, Liniendiagramm und Tabelle. F¨ur die Zukunft ist sind weitere Darstellungsformen geplant.
Neben der Berechnung von Metriken wird die ¨Uberpr¨ufung von Konsistenzregeln un- terst¨utzt, die ¨ahnlich wie Metriken definiert werden k¨onnen. Die Zahl der Verst¨oße kann als Metrik wie in diesem Papier beschrieben visualisiert werden. In [RS06] beschreiben wir dar¨uber hinaus eine Erweiterung der in diesem Papier verwendeten Story-Diagramme, mit der Anfragen ¨uber zeitlich verschiedene Instanzgraphen des Informationsmodells definiert werden k¨onnen. Dadurch wird eine bessere Unterst¨utzung von Trendanalysen erm¨oglicht.
Zur Definition von benutzerdefinierten Metriken w¨urde sich auch OCL [Obj05] als textu- elle Alternative zur hier dargestellten visuellen Spezifikationssprache anbieten. Diese ist im UML 2.0- bzw. MOF 2.0-Standard [Obj04] zur Definition von abgeleiteten Attribu- ten vorgesehen. Aus diesem Grund wir zur Zeit an unserem Fachgebiet an der Integration des Dresden OCL-Compilers [LO04] in das MOFLON-Rahmenwerk gearbeitet. Unter- scheidend ist anzumerken, dass die hier vorgestellten Story-Diagramme Vorteile besitzen, wenn umfangreiche Navigation ¨uber komplexe Strukturen zur Definition von Metriken angewendete werden m¨ussen. OCL dagegen eignet sich dagegen besser, wenn gr¨oßere Berechnungen durchzuf¨uhren sind.
Im Rahmen eines Projektes bei Philips Medical Systems wurde bereits ein kundenspezifi- scher Software-Leitstand von Hand realisiert [R¨ot03]. Die vorliegende Arbeit besch¨aftigt sich mit der Verallgemeinerung dieses Ansatzes, um schnell an andere Anwendungsgebie- te angepasst werden zu k¨onnen. Derzeit arbeiten wir an einer industriellen Fallstudie bei der Firma IBM, bei der zum einen die praktische Einsatzf¨ahigkeit des hier vorgestellten Ansatzes erprobt wird, zum anderen ein gr¨oßeres Augenmerk auf die Probleme bei der Akquisition der ben¨otigten Daten gelegt wird.
Literatur
[Adv05] Advizor. ADVIZORR: A Technical Overview. Bericht, Advizor Solutions, 2005.
http://www.advizorsolutions.com.
[AKRS06] Carsten Amelunxen, Alexander K¨onigs, Tobias R¨otschke und Andy Sch¨urr. MOF- LON: A Standard-Compliant Metamodeling Framework with Graph Transformations.
InECMDA-FA, Band 4066 vonLNCS, Seiten 361–375. Springer, 2006.
[BKL04] Walter R. Bischofberger, Jan K¨uhl und Silvio L¨offler. Sotograph - A Pragmatic Ap- proach to Source Code Architecture Conformance Checking. In Fl´avio Oquendo, Brian Warboys und Ronald Morrison, Hrsg.,European Workshop on Software Architecture, Band 3047 vonLNCS, Seiten 1–9. Springer, 2004.
[GE05] Thomas Genßler und J¨orn Eisenbiegler. Einf¨uhrung und Einsatz au- tomatisierter Softwarequalit¨atskontrollen - ein Erfahrungsbericht. In ObjektForum Entwicklertag IT-Innovationen, 2005. Pr¨asentation, http://www.andrena.de/Entwicklertag/2005/Downloads/
automatisierteQualitaetskontrolle.pdf.
[KB05] Martin Kern und Joachim Baumann. Sotograph - Erfahrungen in der Verwen- dung eines Architektur-Werkzeugs. InObjektForum Entwicklertag IT-Innovationen, 2005. Pr¨asentation, http://www.andrena.de/Entwicklertag/2005/
Downloads/Sotograph.pdf.
[Kri99] Ren´e Krikhaar. Software Architekture Reconstruction. Dissertation, Universiteit van Amsterdam, 1999.
[LD03] Michele Lanza und St´ephane Ducasse. Polymetric Views - a Lightweight Visu- al Approach to Reverse Engineering. IEEE Transactions on Software Engineering, 29(9):782–795, 2003.
[LO04] Sten L¨ocher und Stefan Ocke. A Metamodel-Based OCL-Compiler for UML and MOF.
In P. Schmitt, Hrsg.,Proc. OCL 2.0 - Industry Standard or Scientific Playground?, Band 102 vonENTCS, Seiten 43–61. Elsevier, 2004.
[LS02] Claus Lewerentz und Frank Simon. Metrics-Based 3D Visualization of Large Object- Oriented Programs. InVISSOFT, Seiten 70–77, 2002.
[Mos02] Mosher.A New Specification for Managing Metadata. Sun Microsystems, 2002.http:
//java.sun.com/developer/technicalArticles/J2EE/JMI/.
[Obj04] Object Management Group. Unified Modeling Language: Infrastructure, Version 2.0, 2004. ptc/04-10-14.
[Obj05] Object Management Group.OCL 2.0 Specification, 2005. ptc/05-06-06.
[R¨ot03] Tobias R¨otschke. Re-engineering a Medical Imaging System Using Graph Transforma- tions. InApplications of Graph Transformations with Industrial Relevance, Band 3062 vonLNCS, Seiten 185–201. Springer, 2003.
[RS06] Tobias R¨otschke und Andy Sch¨urr. Temporal Graph Queries to Support Software Evo- lution. InInternational Conference on Graph Transformation, 2006. Akzeptiert.
[Sch06] Daniel Sch¨osser. Generierung von Trendanalyse-Werkzeugen aus dom¨anenspezifischen Metamodellen. Diplomarbeit, TU Darmstadt, Mai 2006.
[Z¨un01] Albert Z¨undorf.Rigorous Object Oriented Software Development. University of Pader- born, 2001. Habilitation.
