Automatisierte Entwurfsmustererkennung

Der einleitende Abschnitt betont die enormen Wartungskosten von Software, die etwa 50% der Gesamtkosten ausmachen. Ein besseres Systemverständnis ist daher unerlässlich für effiziente Softwarewartung. Die Identifizierung von Entwurfsmustern im Systementwurf trägt maßgeblich zu diesem Verständnis bei. Ein zentrales Problem ist die fehlende Kennzeichnung und Dokumentation dieser Muster, insbesondere wenn keine Entwickler mehr verfügbar sind, die Auskunft geben können. Hier bietet die automatisierte Entwurfsmustererkennung einen entscheidenden Vorteil, da sie das Systemverständnis vereinfacht und den Wartungsprozess optimiert. Die automatische Erkennung von Entwurfsmustern wird als Schlüssel zur Verbesserung der Softwarequalität und zur Reduzierung der hohen Wartungskosten dargestellt. Die Aussage, dass 50% der Gesamtkosten auf Softwarewartung entfallen, verdeutlicht den dringenden Bedarf an innovativen Lösungen wie der automatisierten Entwurfsmustererkennung. Ohne diese automatisierte Lösung bleiben viele Entwurfsmuster im System verborgen und erschweren die Wartungsarbeiten erheblich. Die effiziente und schnelle Identifizierung der Muster ist der Kern der vorgeschlagenen Lösung.

Eine Kurzfassung präsentiert erschreckende Statistiken zur Softwareentwicklung: Über 30% der Projekte scheitern oder werden vorzeitig abgebrochen, mehr als die Hälfte wird mit Mängeln ausgeliefert. Nur 16% der Projekte werden erfolgreich abgeschlossen. Umfragen zeigen, dass die größten Schwierigkeiten im Bereich Anforderungsspezifikation, Analyse und Entwurf liegen. Dies unterstreicht die Bedeutung von effizienten Entwicklungsmethoden und einer klaren Dokumentation. Entwurfsmuster (Design Patterns) werden als Lösungsansatz vorgestellt, da sie häufig auftretende Entwurfsprobleme mit generischen Schemata lösen und die Wiederverwendbarkeit von Code fördern. Die klare Benennung und Dokumentation der Muster sichert ihre Identifizierung und erleichtert das Verständnis des Systems, insbesondere für neue Entwickler. Die beschriebenen Probleme in der Softwareentwicklung, mit über 30% gescheiterten Projekten, unterstreichen die Notwendigkeit für Verbesserungen im Entwurf und der Dokumentation. Entwurfsmuster bieten eine Möglichkeit, die Softwarequalität zu erhöhen und die Wahrscheinlichkeit des Scheiterns von Projekten zu reduzieren. Die geringe Erfolgsquote von lediglich 16% verdeutlicht das Ausmaß des Problems und die Notwendigkeit für effektivere Methoden, wie die im Dokument beschriebene automatisierte Entwurfsmustererkennung.

Der Text referenziert verschiedene Ansätze zur automatisierten Entwurfsmustererkennung. Das von Kyle Brown entwickelte Werkzeug KT analysiert Smalltalk-Quellcode über Klassen- und Sequenzdiagramme. Die Herausforderung liegt in der Erkennung von Verhaltensmustern, die ohne dynamische Aspekte schwer zu identifizieren sind. Ein weiteres Beispiel ist DP++, welches die Korrektheit von Musterkandidaten mittels direkter Kontrolle überprüft – eine Methode, die bei großen Projekten zu aufwändig ist. Weitere Ansätze, wie der mehrstufige Suchprozess von Antoniol et al. ([Antoniol+98]) mit AOL und einem Pattern Recognizer, oder die flexible Musterdefinition von Niere et al. ([Niere+01]) mit Fuzzy Logik, werden erwähnt. Es wird jedoch deutlich, dass viele dieser Ansätze entweder unzureichend getestet wurden oder keine aussagekräftigen Metriken wie Präzision und Recall liefern. Der Mangel an umfassenden Tests und die fehlende Angabe von Präzisions- und Recall-Werten bei vielen existierenden Werkzeugen unterstreichen die Notwendigkeit für eine gründliche Evaluierung neuer Ansätze. Die beschriebenen Ansätze zeigen sowohl vielversprechende als auch limitierte Herangehensweisen zur Entwurfsmustererkennung. Die Evaluation dieser Methoden ist entscheidend für die Weiterentwicklung im Feld der automatisierten Entwurfsmustererkennung.

Die automatisierte Entwurfsmustererkennung wird als Lösung für das Problem der fehlenden Dokumentation von Entwurfsmustern in Softwareprojekten vorgestellt. Ein Hauptproblem ist, dass die verwendeten Muster oft nicht gekennzeichnet oder dokumentiert sind, was zu Schwierigkeiten bei der Wartung führt, insbesondere wenn die ursprünglichen Entwickler nicht mehr verfügbar sind. Die Arbeit von Sebastian Naumann ([Naumann01]) liefert die Grundlage für die Entwicklung automatisierter Algorithmen zur Erkennung der 23 Entwurfsmuster aus [Gamma+96]. Diese Algorithmen, ursprünglich in Pseudocode notiert, bilden den Ausgangspunkt der vorliegenden Arbeit. Die Herausforderungen liegen nicht nur in der Implementierung, sondern auch in der Genauigkeit der Erkennung. Die Metriken Präzision und Recall spielen eine entscheidende Rolle bei der Bewertung der Leistungsfähigkeit der Algorithmen. Die Genauigkeit der Erkennung ist entscheidend, um die Zuverlässigkeit der automatisierten Entwurfsmustererkennung zu gewährleisten. Die Arbeit identifiziert die Herausforderungen, die mit der Implementierung und dem Test der Algorithmen verbunden sind, sowie die Notwendigkeit, die Genauigkeit der Ergebnisse durch geeignete Metriken zu bewerten. Die mangelnde Dokumentation der Entwurfsmuster wird als Hauptproblem identifiziert, das durch den Einsatz automatisierter Erkennungsmethoden gelöst werden soll.

Der Text analysiert verschiedene bestehende Ansätze zur Entwurfsmustererkennung und deren Limitationen. Das Werkzeug KT von Kyle Brown ([Brown96]), entwickelt für Smalltalk, arbeitet mit Klassen- und Sequenzdiagrammen und zeigt die Schwierigkeiten bei der Erkennung von Verhaltensmustern auf, wenn dynamische Aspekte fehlen. Der Ansatz von Bansiya, der ein selbstentwickeltes Projekt testete, leidet an der nicht praktikablen manuellen Überprüfung der Ergebnisse bei großen Projekten. Antoniol et al. ([Antoniol+98]) verwenden einen mehrstufigen Suchprozess mit AOL (Abstract Object Language) und einem Pattern Recognizer. Niere et al. ([Niere+01]) entwickeln eine flexible Musterdefinition basierend auf Submustern und Vererbung, aber ihre Implementierung war zum Zeitpunkt der Veröffentlichung noch nicht abgeschlossen. Die Kritik an den bestehenden Werkzeugen konzentriert sich auf mangelnde Tests und die fehlende Angabe von Präzision und Recall. Diese Analyse identifiziert Lücken in bestehenden Ansätzen und begründet den Bedarf an einer verbesserten, umfassend getesteten Methode zur automatisierten Entwurfsmustererkennung.

Die vorliegende Arbeit konzentriert sich auf den Test und die Verbesserung der von Naumann entwickelten Algorithmen, die auf UML-Klassendiagrammen basieren. Die UML wird als allgemeine Beschreibungssprache erkannt, deren Abstraktionslevel zu Problemen bei der Umsetzung in konkrete Programmiersprachen führt. Die Implementierung erfolgt in Java, wobei die Objekterzeugung eine besondere Herausforderung darstellt. Java bietet verschiedene Möglichkeiten zur Objekterzeugung, die nicht alle durch das Schlüsselwort 'new' abgedeckt werden, was die Erkennung von Erzeugungsmustern erschwert. Die Verwendung des CASE-Tools Together ControlCenter mit seinen Schnittstellen (RWI, SCI) ermöglicht das Reverse Engineering von Java-Quellcode und die Verarbeitung der Informationen in Form von UML-Klassendiagrammen. Die Arbeit schlägt den Entwurf einer spezifischen API für die Mustersuche vor, um die Genauigkeit und Effizienz des Prozesses zu verbessern. Die Implementierung und das Testen der Algorithmen mit dem Fokus auf Java und UML-Klassendiagrammen bilden den Kern der Arbeit. Die beschriebenen Herausforderungen unterstreichen die Komplexität des Problems und die Notwendigkeit eines optimierten Ansatzes. Das CASE-Tool Together ControlCenter dient als Instrument zur Unterstützung des Reverse Engineering und der Datenverarbeitung.

Die Algorithmen von Naumann ([Naumann01]), ursprünglich nur als Pseudocode vorhanden, wurden im Rahmen dieser Arbeit in Java implementiert. Als Grundlage diente das UML-Klassendiagramm. Die UML wird als allgemeine Beschreibungssprache beschrieben, die nicht auf die Besonderheiten spezifischer Programmiersprachen eingeht, was zu Problemen bei der Implementierung führte. Für das Reverse Engineering des Quellcodes und die Verarbeitung der Informationen wurde das CASE-Tool Together ControlCenter von Togethersoft verwendet. Dabei kamen die internen Schnittstellen Read Write Interface (RWI) und Source Code Interface (SCI) der OpenAPI zum Einsatz. Die Arbeit beinhaltet auch den Entwurf einer neuen Application Programmers Interface (API), die speziell auf die Anforderungen der Mustersuche zugeschnitten ist. Die Wahl von Java als Implementierungssprache und die Nutzung von Together ControlCenter als CASE-Tool sind wichtige Aspekte der Methodik. Die Schwierigkeiten der Umsetzung des Pseudocodes in Java aufgrund der generischen Natur der UML werden hervorgehoben. Die Entwicklung einer neuen API zeigt den Fokus auf Verbesserung und Optimierung des gesamten Prozesses der Entwurfsmustererkennung.

Für den Test der implementierten Algorithmen wurden mehrere Referenzsysteme verwendet: ein selbstentwickeltes 'Pattern-Projekt', das alle 23 Entwurfsmuster aus [Gamma+96] enthält, der Applikationsserver Tomcat und das Abstract Windowing Toolkit (AWT). Die Daten zu AWT und Tomcat stammen von PatternStories ([Patterns]), die zu Drawlet von einer Präsentation ([Auer97]). Das selbstentwickelte Pattern-Projekt diente als umfassender Testfall, während AWT und Tomcat realistische Anwendungsszenarien repräsentierten. Die Kennzahlen Präzision und Recall spielen eine zentrale Rolle bei der Bewertung der Algorithmen. Die Auswahl der Referenzsysteme ist wichtig für die Aussagekraft der Testergebnisse und umfasst sowohl ein vollständig kontrolliertes System als auch real existierende Software-Systeme. Der Vergleich mit existierenden Systemen wie AWT und Tomcat erlaubt die Bewertung des entwickelten Ansatzes in einem realistischen Kontext. Die Verwendung eines selbstentwickelten Systems erlaubt eine vollständige Kontrolle über die enthaltenen Entwurfsmuster, was die Bewertung der Genauigkeit der Algorithmen vereinfacht.

Die Testergebnisse zeigen einen Recall von 100% für alle 23 Entwurfsmuster. Die Präzision variiert je nach Algorithmus und Muster. Für einige Algorithmen wurde eine Präzision von 100% erreicht, während andere deutlich niedrigere Werte aufwiesen (z.B. 33%, 4%, 1%). Die niedrige Präzision bei einigen Algorithmen resultiert aus der Beschränkung auf statische Aspekte oder zu restriktiven Definitionen der Muster. Verbesserungsvorschläge werden präsentiert, um die Präzision zu erhöhen. Die durchschnittliche Präzision aller Algorithmen liegt nach den Tests bei 68%. Die Laufzeiten der Algorithmen wurden gemessen und sind bei umfangreichen Projekten teilweise sehr hoch (über eine Stunde). Die Messung der Laufzeiten erfolgte auf einem AMD Athlon 1800XP Prozessor mit 384 MB RAM unter Windows XP. Die erzielten Resultate von 100% Recall bei allen Mustern stellen ein positives Ergebnis dar. Die unterschiedlichen Präzisionswerte zeigen jedoch den Bedarf an weiteren Optimierungen der Algorithmen und eine Weiterentwicklung der Definitionen der einzelnen Muster, um sowohl die Genauigkeit als auch die Effizienz der automatisierten Mustererkennung zu steigern.

Die Naumann-Algorithmen wurden auf Basis ihrer Pseudocode-Notation implementiert und in das CASE-Tool Together ControlCenter von Borland integriert. Da Together Reverse Engineering von Quelltext bietet, waren keine zusätzlichen Werkzeuge notwendig. Für jedes Entwurfsmuster wurde eine separate Klasse mit find()- und print()-Methoden erstellt, abgeleitet von einer Superklasse FindPattern. Fast jedes Muster erhielt eine eigene JavaBean-Klasse zur Speicherung seiner Instanz und Komponenten, Ausnahmen bilden Singleton, Fassade und Interpreter. Die Integration in Together ControlCenter ermöglicht die direkte Anwendung der Algorithmen auf vorhandenem Quellcode, wodurch ein nahtloser Workflow entsteht. Die modulare Struktur der Implementierung, mit separaten Klassen für jeden Algorithmus und der Verwendung von JavaBeans, fördert die Wartbarkeit und Erweiterbarkeit. Die Verwendung von Together ControlCenter als Entwicklungsumgebung vereinfacht den Prozess der Integration und ermöglicht die Nutzung der bereits vorhandenen Funktionen des Tools.

Um dem Benutzer lange Wartezeiten zu ersparen, wurde ein Nutzerinterface entwickelt, welches die individuelle Auswahl der auszuführenden Algorithmen erlaubt. Die langen Laufzeiten einzelner Algorithmen, besonders bei umfangreichen Projekten (manchmal über eine Stunde), werden als Problem angesprochen. Die Benutzerschnittstelle bietet die Möglichkeit, Algorithmen einzeln oder in Gruppen auszuwählen, um die Verarbeitung zu steuern und unnötige Wartezeiten zu vermeiden. Die Implementierung der Benutzerschnittstelle verbessert die Benutzerfreundlichkeit und ermöglicht es dem Nutzer, den Prozess der Entwurfsmustererkennung effizient zu steuern. Die langen Laufzeiten einzelner Algorithmen werden angesprochen und als ein Problemfeld definiert, das in zukünftigen Entwicklungsschritten angegangen werden sollte.

Die Ergebnisse der Algorithmen werden in einer XML-Datei dokumentiert, basierend auf einem eigens entwickelten XML-Schema. Diese Datei enthält die Strukturen der einzelnen Muster und weitere relevante Elemente, um eine effiziente Weiterverarbeitung zu ermöglichen. Als Ausblick wird eine Idee zur Visualisierung der Ergebnisse in Together ControlCenter präsentiert. Die Visualisierung soll die identifizierten Muster in einer Baumstruktur darstellen und eine Navigation sowie das Hervorheben der beteiligten Klassen im Klassendiagramm ermöglichen. Die XML-Dokumentation ermöglicht eine strukturierte und maschinenlesbare Speicherung der Ergebnisse, die für weitere Analysen und die Integration in andere Systeme genutzt werden können. Der Ausblick auf eine integrierte Visualisierung innerhalb von Together ControlCenter zeigt die Möglichkeit, die Ergebnisse der Analyse intuitiv zu präsentieren und zu navigieren. Das Referenzsystem, welches für die Tests entwickelt wurde, wird als rudimentär beschrieben. Für zukünftige Untersuchungen wird eine umfangreichere Sammlung von Implementierungsvarianten der Entwurfsmuster empfohlen.