<< zurück

MBSE Home

weiter >>

10.3 Zusammenfassung der Refactoring-Techniken

In Kapitel 9 und diesem Kapitel wurden die theoretischen Grundlagen für transformationelle Softwareentwicklung auf Basis der UML/P untersucht und mit der Methodik zur Durchführung von Refactoring-Schritten kombiniert. Statt einer Auflistung einzelner Regeln wurde diskutiert, wie aus vorhandenen Regelsätzen, zum Beispiel für Java, Refactoring-Regeln für UML/P übertragen werden können. Eine pragmatische, im Wesentlichen auf Invarianten basierende Erweiterung wurde durch die Beschreibung einer additiven Vorgehensweise für den Wechsel von Datenstrukturen angegeben. Anhand von Beispielen wurde die praktische Einsetzbarkeit dieser Vorgehensweise demonstriert. Es zeigt sich, dass die UML/P gemeinsam mit den in den Kapiteln 6, 7 und 8 diskutierten Vorgehensweisen zur Testdefinition eine hervorragende Sprache zur evolutionären Entwicklung des Produktionssystems und der Testfälle darstellt.

Refactoring ist eine seit [Fow99] immer populärer werdende Technik, deren Wurzeln in der evolutionären Weiterentwicklung bereits in [Opd92] dokumentiert wurden. Tatsächlich reicht der Gedanke einer transformationellen Softwareentwicklung, die ähnlich zur mathematischen Herleitung von Aussagen durchgeführt wird, noch sehr viel weiter zurück [BBB⁺85, Dij76, PR03]. Erst durch [Fow99] wurde die zunächst sehr formal präsentierte Vorgehensweise zur Transformation existenter Systeme durch praktische Beschreibungen, die an die Entwurfsmuster aus [GHJV94] angelehnt sind, einer breiteren Verwendung zugänglich gemacht. Als wesentlicher Erfolgsfaktor dafür lässt sich die Ersetzung der verifizierenden Ansätze zur Sicherstellung der Korrektheit einer Transformation durch automatisierte Tests identifizieren. Diese stellen zwar die Korrektheit nicht sicher, bieten aber, wie praktische Erfahrungen zeigen, einen guten Schutz vor Fehlern bei der Transformation. Die Verwendung von automatisierten Tests zur Festlegung des im Refactoring notwendigen Beobachtungsbegriffs ist eine daraus resultierende, wesentliche Errungenschaft.

Zur Zeit findet eine intensive Entwicklung von Refactoring-Regeln statt und es ist unklar wieviele Regeln ein für praktische Belange ausreichendes Portfolio zur Verfügung stellen muss. So gibt es allgemeine Prinzipien, wie „Divide-Et-Impera“ oder die „Einbettung“ von Methoden in allgemeinere Problemstellungen, die meist mit einer Erweiterung der Parameter vorgenommen wird, aus denen sich Regeln ableiten lassen. In [TDDN00] wird beispielsweise die Sprachunabhängigkeit von Refactoring-Regeln untersucht, indem Gemeinsamkeiten zwischen Java- und Smalltalk-Regeln extrahiert werden. Daneben gibt es auch sprachspezifische Refactoring-Regeln, wie zum Beispiel der Umgang mit Exceptions in Java oder mit den Statecharts in UML/P. Eine dritte Klasse von Refactoring-Techniken ergibt sich aus der Behandlung von Framework- oder Komponenten-spezifischen Situationen. So kann in Java zum Beispiel ein Vektor durch eine Set-Struktur ersetzt werden, wenn die Reihenfolge und die Anzahl der darin enthaltenen Elemente keine Rolle spielen.

Dauerhaft erfolgreich werden Refactoring-Techniken vor allem dann, wenn die Werkzeugunterstützung weiter ausreift. Entwicklungsumgebungen erlauben bereits eine effiziente Identifikation und Bearbeitung aller auftretenden Stellen einer Methode oder eines Attributs. Die konkrete Unterstützung der Durchführung von Refactoring-Schritten bis hin zum Vorschlag wenigstens einfacher algebraischer Vereinfachungen wird allerdings in der nächsten Zukunft noch einigen Aufwand für Werkzeughersteller erfordern.

Neben der derzeit stattfindenden stetigen Erweiterung des Regelsatzes speziell für Java, eröffnen sich vor allem Fragestellungen für die Übertragung von Regeln zwischen Sprachen und zur besseren Fundierung der Korrektheit von Refactoring-Regeln. Dazu ist eine Präzisierung der Regeln notwendig, um sie zum Beispiel in Form von Taktiken maschinell umsetzbar und in allen Implikationen (Kontextbedingungen) verständlich zu machen. Während die Refactoring-Regeln in [Fow99] für die manuelle Anwendung sehr hilfreich sind, sind sie doch in ihren Kontextbedingungen, Sonderfällen, etc. zu informell, um einer formalen Untersuchung der Korrektheit zugänglich zu sein.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>