University of Munich/ Department of CS(Informatik)

Evolution von Softwaresystemen durch Transformation
(Object-Oriented Software Refactoring via Design Pattern Transformation)

Inhalt:

Die Entwicklung der Informatik, neuer Hard- und Software- Technologien hat in den letzten Jahren zu einen gigantischen

Beitrag der Arbeitslosigkeit in den führenden Industrieländer geführt. Viele traditionelle Berufe sind entweder ganz

oder teilweise durch den Computer und Programme ersetzt worden. Nun ist die Zeit reif, dass die Softwareentwickler 

letztendlich auch für die Arbeitslosigkeit in den eigenen Reihen sorgen werden. Ein gutes Beispiel dafür liefert uns

hier die Design Pattern Transformation, die zusammen mit den OOSR  das Hauptthema meiner Arbeit ist.

Natürlich gibt es auch wichtigere Gründe für die Einführung der OOSR via Pattern Transformation,

als nur die Steigerung der Arbeitslosigkeit. Wir alle wollen unser Geld bestmöglich investieren,

die Firmen wollen, dass ihre Aktien möglichst hoch steigen, dies ist jedoch gewinnbedingt, 

was wiederum von den Kosten abhängig ist. Kurz gesagt, wir wollen bei der SW-Entwicklung und Wartung kosten einsparen.

Wenn früher (70er/80er) die Wartungskosten bei 30-50% lagen, so sind sie heutzutage bei 80/90% der

Gesamtkosten der Software. Design Pattern vergrößert zwar die Entwicklungskosten, verringert aber

erheblich die Wartungskosten, da z.B. Upgrade und Portierung mit weniger Aufwand verbunden sind. 

Die Stichworte Wiederverwendung und Erweiterbarkeit der Software bekommen ein weiteres Attribut - 

einfache (kostenminimale)  Wiederverwendung bzw. Erweiterbarkeit.

Das Beispiel des Problems der Umstellung auf das Jahr 2000 zeigt uns, das durchaus externe Ereignisse

für die Fehleranfälligkeit der SW sorgen können, die mit dem eigentlichen Programm vielleicht gar 

nichts zu tun haben, oder zum Zeitpunkt der Entwicklung nicht erkannt wurden. OOSR via Design Pattern

Transformation gibt uns auch hier Mechanismen, um die Fehleranfälligkeit der Programme mit  minimalen

Aufwand zu beheben (in diesem speziellen Beispiel wäre es ein Wrapper für den Datentyp). Außerdem ist

es sicherer bestehende (und "fehlerfreie") Module zu rekonstruieren und wiederzuverwenden, als neue 

Module mit ähnlicher Funktionalität zu entwickeln.  

Der dritte Grund für die Einführung von OOSR via Design Pattern wäre die Zeit. Es ist üblich in der 

SW- Branche, daß angesichts der harten Konkurrenz, jede Firma kürzere Entwurf- und Entwicklungszeiten 

verspricht, als es eigentlich notwendig wäre. Die Versuche der Firmen die versprochenen Termine einzuhalten,

sorgten für die Akzeptanz neuer Projekt Management und Entwicklungs- Technologien, die z.B. Entwicklung 

während des Entwurfes erlauben (Stichwort: Reverse Engineering). Gute Beispiele dafür sind "Rational Rose"

und "STP" OMT -Tools. Diese Tools in Verbindung mit den ClassViewer-Tools (etwa SNIFF+ / Visual Works / MSD)

verwenden unter anderem Design Pattern (z.B.Class-Wizard) und in der nächsten Zukunft auch Pattern Transformationen,

um eben die Entwicklung und Wartungszeiten zu reduzieren.



Jetzt haben wir aber schon viel gesagt, ohne zu wissen, was nun eigentlich die OOSR via Pattern Transformation

wirklich bedeutet! Nun Design Pattern (Muster) definieren uns einen Zielzustand

d.h. den Entwurf für eine Programmcode Implementierung. Ein brauchbares Transformationstool wäre

in der Lage den vorhandenen Code (oder UML-Diagramme) automatisch zu transformieren in ein

neues als Ziel definiertes Programm! Ein solches Tool, das die Modifikation vom Programmcode

automatisch ausführt, hätte nicht nur dem Programmierer die Codierung und damit verbundene 

Fehleranfälligkeit erspart, sondern hätte die Softwarekosten erheblich reduzieren können.

Damit hätten wir in unserem Beispiel kleinere Kosten, größere Gewinne, Aktien- Höhenflug und 

Viele Arbeitslose Programmierer!

Um das Thema Motivation abzuschließen, möchte ich noch zwei Gesetze der SW- Branche zitieren:

"Nicht große Firmen essen Kleine, sondern die Schnellen essen die Langsamen!" und " Zeit ist Geld!" 

Vor lauter Optimismus in der Einführung ist es manchen wohl so vorgekommen, das die OOSR via Patern Transformation

ein schneller und kostenminimaler Weg zum Erfolg sei, wir möchten aber, dass die

Rahmenbedingungen für den Einsatz der Pattern Transformation uns nicht entgangen bleiben. Denn der Einsatz neuer

Technologien ist mit Risiken verbunden, so daß man manchmal leicht auf die Schnauze fällt(wie es manche Projekte tun!).

Anstatt schnell und kostenminimal zum Erfolg zu kommen, wird man dann mit einem Klotz am Bein den Aufwand verdoppeln,

wenn man die Randbedingungen nicht beachtet. Deshalb möchte ich zunächst einmal auf die Voraussetzungen für die OOSR

via Pattern Transformation eingehen. Dabei muß man in erster Linie zwischen den "Specification to Source" und

"Source to Source "  -Transformationen unterscheiden. 

Nehmen wir nun den Fall "Source to Source ".  Dabei gelten folgende Faustregel:



1) Vorhandener Code soll keine komplizierten Pre-Compiler Makros erhalten (z.B.: #ifndef, #pragma, usw.)  

2) Compiler- Wechsel ist bei der Transformation nicht möglich. (wegen Make-File compatibility)

3) Vorhandener Code ist ein Einzelprogramm (keine Programmfamilie) z.B.: Falls DLL zu dem Programm   

    geändert wird, werden andere Programme, die dieselbe DLL benutzen, nicht mehr laufen!

4) Code Verfügbarkeit. z.B.: FrameWork oder System-API header-files sind nur "Read Only" und können   

    nicht für die Transformation verwendet werden. Deshalb grundsätzlich transformiere nur eigenen Code!

5) Gute Planung ist alles:

-  Plazierung des generierten Code(Code Placement),

-  Transformation Aktivierungs- Bedingungen(Enabling Conditions),

- Granularität der Transformation.



Da insbesondere alle Einzelheiten später näher erläutert werden, werden wir uns an der Stelle erstmal

  mit den Grundoperationen der Pattern Transformation beschäftigen.

Pattern Transformationen sind nun eine kleine Menge von primitiven Object-Orientierten Transformationen.

 Object-Orientierte Transformationen sind ihrerseits Programmcode Transformationen, und zwar Code, 

welcher Klassen, Methoden, Vererbung und weitere Konstrukte 

der Objekt- Orientierten Programmierung enthält (Also SmallTalk, C++, Java)



Transformation kann wie folgt beschrieben werden:

1) Beschreibung

2) Argumente

3) Anfangs- und End- Zustand 

4) Anwendung spezifischer Eigenschaften und Einschränkungen

5) Transformationsaufruf



Zur Demonstration der Grundtransformationen wird im folgenden die Sprache C++ verwendet, da

die Sprache am weitesten verbreitet ist und den meisten wohl bekannt sein wird.

1) Beschreibung: Macht es möglich eine Super-Subclass Beziehung zwischen zwei vorhandenen,

		aber unabhängigen Klassen herzustellen.

2) Argumente: 	c1(Superclass Name), c2 (Subclassname) 

	vm2* (Liste von c2 virtuellen Methoden, die in c1 vorhanden sein werden)

	m2* (Liste von c2  Methoden, die in c1 vorhanden sein werden)

	iv2* (Liste von c2 instanz-variablen, die in c1 verschoben  werden)

3) Start- und End-Zustände (siehe Abb.1.1)

4) Eigenschaften: 

	- andere Subclassen von c1 (falls vorhanden) müssen  vm2*() unterstützen

	- c2 muß alle virtuelle Methoden von c1 unterstützen

	- Methoden m2*() von c2 dürfen keine anderen Subklass-spezifische Variablen referenzieren

	(z.B. c2 wäre von c3 abgeleitet und hat c3 spezifische Instanz-Variablen)

5) Aufruf: Inherit(c1,c2,vm2*(),m2*(),iv2*);

1) Beschreibung: Macht es möglich bei Methodenaufruf der Klasse c1 ein neues Objekt der

   Klasse c2 zu erzeugen (z.B. C2* p_c2 = c1.CreateC2(); ) 

2) Argumente:  c1(Fabrik Name), c2 (Klassname), c3 (Klasse, die erzeugt wird) 

3) Start- und End-Zustände (siehe Abb.1.2)

4) Eigenschaften: 

   - Name der Fabrik-Methode (CreateC2()) darf nicht in c1 schon vorhanden sein!

   - C3 ist entweder C2 selbst, oder Superklasse von C2

   - V ist ein Ausdrück, welcher ein Objekt mit der Mehtode Create() liefert.

5) Aufruf: Factory (c1,c2,c3=c2,v);

1) Beschreibung: Sei Klasse C2 von C3 abgeleitet und in C1 referenziert. Folgende 

 Transformation macht die Verschiebung der Referenz einer Klasse

 auf die Basisklasse dieser referenzierter Klasse möglich.

2) Argumente: c1(Klasse, bei der Referenz vorliegt), c2 (Klasse, die referenziert ist),

          c3(die zu referenzierende Klasse) 

3) Start- und End-Zustände (siehe Abb.1.3)

4) Eigenschaften: 

	- C3 soll die Interface von C2 zu C1 anbieten (Test: Compiler-error: "undefined member")

	- Aufrufe der C1-Methoden, die einen Zeiger auf C2 liefern müssen auch C3 akzeptieren.

(Test: Compiler-error: "type mismatch")

	- Wenn C1 erzeugt C2, so muß C3 eine Basis der C2 sein und newC2() mit newC3() ersetzen

	- Falls C3 eine abstrakte Basisklasse ist, ersetze C2-Referenz mit C3, keine Transformation!

5) Aufruf: Substitute (c1,c2,c3);

Andere Transformationen sind entweder wohl bekannt oder treten sehr selten auf:

Erste zwei Transformationen sind aus diversen Class-Wizards bekannt:

-  CreateClass(Classname) oder CreateInstanceVariable(VarName, VarType):

   Beschreibung: Dienen zur Erzeugung der neuen Klasse und der Member der Klasse

- Singleton und InverseSingleton:

  Beschreibung: Macht es möglich, daß einer Klasse nur eine Instanz zur Laufzeit existiert

Oder auch umgekehrt (Inverse Singelton).

Problem: Prüfung, ob Singleton sicher und korrekt ist, ist sehr schwer

Nun wollen wir gemeinsam die Transformations-Theorie an einem praxisnahen Beispiel näher betrachten

und uns in die Tiefe(auf die Source-Ebene) begeben.     



Ausgangssituation: Ein Programm, das ein Honda Prelude erzeugt und 100000 Meilen fährt. Dabei werden

Reifen und Motor gewechselt. Das Programm arbeitet nur für Honda Prelude.

Aufgabe: Wir sollen ein Programm mit gleicher Funktionalität schreiben, das neue Modelle erzeugt und

fahren läßt.Insbesondere soll zunächst ein Honda Accord damit erzeugt werden.



Dabei dürfen wir das Programm für Honda Prelude verwenden.

1) Transformiere das vorhandene Programm zu einem neuen Programm mit gleicher Funktionalität. 

 Das neue Programm soll für Erweiterbarkeit und Wiederverwendbarkeit ausgelegt sein.

2) Transformation zu einem neuen  Programm mit gewünschter Funktionalität.

  SW- Wiederverwendung  mittels Transformationen (gleicher Funktionalität)



Step1.1: Inherit Transformation = Erzeuge (abstrakte) Basisklassen für (konkrete) Reifen und Motor. 

a) Ist Zustand (Tab.2.1)

b) Soll Zustand (Tab.2.1)

c) Transformationskontext und Code: (Abb.2.1)

d) Aufruf: Inherit[Engine,VTEC2_2,nil,(Drive),(miles, max_miles)]



Step1.2: Substitute Transformation = Wir wollen der Klasse "Auto" die Benutzung der neuen Klassen 

 "Reifen" und "Motor" beibringen.

a) Ist Zustand (Tab.2.2)

b) Soll Zustand (Tab.2.2)

c) Transformationskontext und Code: (Abb.2.2)

d) Aufruf: Substitute[Car,VTEC2_2,Engine] / Substitute[Car,GY184_HR14,Tire]



Step1.3: Factory Transformation = Nun wollen wir Autos mit verschiedenen Reifen und Motoren 

erzeugen können. Wir brauchen also eine Auto-Objekt Factory. 

a) Ist Zustand (Tab.2.3)

b) Soll Zustand (Tab.2.3)

c) Transformationskontext und Code: (Abb.2.3)

d) Aufruf: 	CreateClass[CarFactory]  

CreateInstanceVariable[App,PreludeFactory*,car_factory,new PreludeFactory]

FactoryMethod[PreludeFactory, GY184_HR14, MakeTire,Tire, app->car_factory]

		FactoryMethod[PreludeFactory, VTEC2_2, MakeMotor, Motor, app->car_factory]



Step1.4: Inherit Transformation = Erzeuge (abstrakte) Auto-Factory für (concrete) Auto-Factory . 

a)	Ist Zustand (Tab.2.4)

b)	Soll Zustand (Tab.2.4)

c)	Transformationskontext und Code: (Abb.2.4)

d)	Aufruf: Inherit[CarFactory,PreludeFactory,(MakeMotor,MakeReifen),nil,nil]



Step1.5: Substitute Transformation = Beibringen der Anwendung das Arbeiten mit der AutoFactory. 

a)	Ist Zustand (Tab.2.5)

b)	Soll Zustand (Tab.2.5)

c)	Transformationskontext und Code: (Abb.2.5)

d) Aufruf: Substitute[App, PreludeFactory, CarFactory]



Ergebnis:  Schritt 1 ist abgeschlossen! Anwendung kann immer noch einen Honda Prelude erzeugen und fahren.

 Das Programm ist nicht mehr an konkreten Prelude-Teilen abhängig (diese sind nicht mehr explizit  referenziert ),

 sondern es enthält eine AutoFactory, die  Objekte von Typ Motor und Reifen erzeugt, 

welche in einem Auto referenziert sind. Desweiteren wird diese abstrakte AutoFactory durch eine 

konkrete PreludeFactory implementiert, welche uns konkrete Prelude-Teile (VTEC2_2 Motor und GY184_HR14 Reifen)

 für das Auto-Objekt zur Verfügung stellt. 

Das neu entstandene Programm bietet uns nun eine ganze Reihe von Erweiterungsmöglichkeiten, 

Welche in ursprünglichem Programm mit einem riesigen Aufwand verbunden wären. Unter Anderem:

- wir können neue Typen von Reifen oder Motoren einfach erzeugen, indem wir weitere Subklassen von

  Reifen oder Motoren bilden (richtiges Verhalten wird vererbt!)

- wir können unseren Honda Prelude mit diesen neuen Teilen ausstatten, indem wir die Factory-Method

   in PreludeFactory modifizieren

- wir können andere Auto-Factorys hinzufügen, welche uns andere Autos erzeugen(z.B. Accord)

- wir können schließlich die gleiche Anwendung nutzen um andere Autos erzeugen und fahren zu lassen,

   soweit eine andere konkrete AutoFactory implementiert ist.



Step2.1: Creation Transformation = Addieren neuer Reifen und Motor- Klassen. 

a)	Ist Zustand (Tab.3.1)

b)	Soll Zustand (Tab.3.1)

c)	Transformationskontext und Code: (Abb.3.1)

d)	Aufruf:  CreateClass[AccordEngine] / CreateClass[AccordTire]  

Inherit[AccordEngine, Engine, nil, (max_miles,miles)]

Inherit [AccordTire, Tire, nil, (max_miles,miles)]



Step2.2: Factory Transformation = Prelude soll mit neuen Reifen und Motor erzeugt werden. 

a)	Ist Zustand (Tab.3.2)

b)	Soll Zustand (Tab.3.2)

c)	Transformationskontext und Code: (Abb.3.2)

d)	Aufruf: FactoryMethod[PreludeFactory,AccordTire,MakeTire,Tire,app->car_factory]

[PreludeFactory,AccordEngine,MakeEngine,Engine,app->car_factory]



Step2.3: Creation Transformation = Addieren neue AutoFactory. 

a)	Ist Zustand (Tab.3.3)

b)	Soll Zustand (Tab.3.3)

c)	Transformationskontext und Code: (Abb.3.3)

d)	Aufruf: CreateClass[AccordFactory]  

Inherit[AccordFactory, CarFactory, (MakeTire,MakeEngine),nil]



Step2.4: Reassociate Transformation = Reassitiation der Anwendung mit neuer AccordFactory. 

a)	Ist Zustand (Tab.3.4)

b)	Soll Zustand (Tab.3.4)

c)	Transformationskontext und Code: (Abb.3.4)

d)	Aufruf: Reassociate[App, PreludeFactory, AccordFactory], oder per Hand!



Ergebnis: Schritt2 ist abgeschlossen und wir haben unsere Aufgabe erfüllt! 

Insgesamt waren 9 Stufen notwendig um die gesamte Programmtransformation durchzuführen.

Nachdem wir nun die Pattern-Transformationstechnik an diesem umfangreichem Beispiel in einer

greifbaren Nähe kennengelernt haben, können wir auch einen kurzen Ausblick auf weitere Beispiele

aus der Industrie einwerfen.

CIM-Works ist ein Industrieweites Framework für Windows-Anwendungen, die für Simatech

Spezifiziert sind (wie etwa MFC für VisualC++). Große Architektur Veränderungen sind zwischen

Den Versionen 2 und 4 passiert und wurden mit Hilfe der Transformationen nachvollzogen.

Dieses Refactoring ist in 8 Stufen von einer Menge der primitiven Transformationen  (wie etwa:

-rename_class / - create_class / -create_factory/ - add_variable / move_variable / inherit) realisiert

 worden. Dabei sind 5K Byte Code entstanden.

Andrew User Interface System von CMU ist eine Sammlung von Tools, welche dem Benutzer das Erzeugen, 

Benutzen und Mailen von Dokumenten und Programmen mit eingebetteten Objekten

erlaubt. Upgrade von Version 6.3(C-API) zu Version 8.0(in C++) war ebenso mit Hilfe der Transformationen

 (wie z.B. structur_to_class / create_class / create_factory/ procedur_to_command) simuliert. 

Dieses 9-stufige Programm Refactoring wurde mit insgesamt 800 Transformationen durchgeführt. 

Dabei wurde 14K Byte Code generiert.

Zum Schluß wollen wir nun auf die Vor- und Nachteile der PatternsTransformations-Technologie

eingehen und über weitere Einsatzmöglichkeiten sowie Integration mit den anderen Tools diskutieren.

SW-Entwicklung muß schnell, sicher und  kostenminimal abgewickelt werden.Entstehende SW soll wiederverwendbar,

erweiterbar und möglichst platformunabhängig sein.Pattern Transformationen 

helfen uns dabei mit einer Reihe von Mechanismen, die Source-Code automatisch transformieren, 

ohne dabei die Funktionalität zu verändern (struct_to_class / Factory / Substitute - Transformationen) oder 

um die neue gewünschte Funktionalität herzustellen (create_class / Add_variable / Inherit / Singelton). 

Mit der Pattern Transformation Technologie haben wir erstmals eine Möglichkeit nicht nur für 

Generierung des Programmcodes des Entwurfes, sondern auch von einem existierendem Programm aus. 

Wir müssen nur lernen mit diesem mächtigen Werkzeug umzugehen!

 - Automatische Code Formatierung. Dies ist zwar bequem, macht aber Programmcode weniger lesbar

   (Man kann jedoch die Formatierung ausschalten)

 - Generierung der Kommentare. Einerseits brauchbar, so dass man weiss, was durch welche 

   Transformation entstanden ist, und andererseits kann sie unter Umständen völlig unbrauchbar sein.

    (Man kann diese Option ebenso ausschalten) 

 Wie in der Voraussetzung erwähnt worden war, ist Pattern Transformation nicht einsetzbar bei:

  - Komplizierten Makros (z.B.: #ifdef,  #define makro() F(),  #pragma(compiler-abhängig) #Flag )

  - Compilerwechsel. Denn das Tool hat Makefiles als Argument um Source-Code zu finden und

    Compiler-Flags zu berücksichtigen. Bei Compiler Wechsel sind Makefiles nicht kompatibel.

 - Programm Familie: Wenn die Library geändert wird, welche von den anderen Programmen benutzt wird.

 - File Access: Alle in die Transformation eingehenden Dateien müssen den Schreibzugriff gewährleisten.

   Dies ist in der Realität oft nicht der Fall (Frameworks, System-Hearder) 

- Programmierer sind Menschen: Alte handgemachte Kommentare werden teilweise unbrauchbar oder

werden gelöscht. Programmierer mögen keine generierten Codeformatierungen oder Kommentare! 

- Code Placement: Es muß entschieden werden wohin mit dem generiertem Programmcode.

-  Enabling Conditions: Wie sicher ist die Transformation.(Man muß eben genau wissen, was man tut!)

- Granularität der Transformation: Man muß ein gesundes Maß an Granularität finden! Denn

einerseits will man nicht vom Hundertsten ins Tausendste (z.B.  jede move_variable zu Basis-Klasse als

eigenständige Transformation) kommen und andererseits will man ja auch die komplizierten Transformationen,

 die nicht sicher sind und die keiner nachvollziehen kann, möglichst vermeiden.

Pattern Transformation Tools können und werden in die moderne OMT-Tools (wie etwa Rational Rose, STP) integriert,

 was nicht nur der Generierung von Source-Code aus UML- Diagrammen dient, sondern

auch der Abbildung der vorhandenen Programme in UML-Darstellung. Beispiele dafür sind:

- Smalltalk Refactoring Browser wurde von Meijers in OMT-Viewer integriert.

- Griswold Transformation Tool für eine Scheme-Umgebung

- CMU- und Demeter- Software für C++ Transformationen  

Man könnte sich einige Gebiete vorstellen, in denen Pattern und Pattern-Transformationen sehr

erfolgreich eingesetzt sein würden. Solche Software weisen bestimmte Eigenschaften auf: 

- Permanente Grundfunktionalität (BSP. Framework und Design.Tools), 

- Veränderung der Objekt-Attribute bei gleicher Funktionalität

   (BSP. Unterhaltung Software: Neue Version der Lora-Game mit neuen Labyrinthen!) 

- Automatisierung ( Programme für Fließbänder, neue Produktionshalle usw.) 

- Internet-Software und DBMS (Gleiche Grundalgorithmen, Schnittstellen)

Weniger ist diese Technik für die Anwendungen geeignet, die sehr komplizierte Vorgänge abbilden und

mit aufwendigen Benutzerschnittstellen ausgestattet sind, da man insbesondere nicht weis, was alles 

von einer Transformation betroffen sein wird und wie sicher die Transformation ist. Beispiele dafür sind

Bank- und Versicherungssoftware, die an eine Datenbank im Hintergrund gebunden sind und dessen

Objekt-Typen von den Datenbank-Objektrepräsentationen abhängig und daher weniger flexibel sind.  

Jedoch mit der Entwicklung der Objekt-orientierten Datenbanken ist auch hier der Einsatz der Pattern und

 Transformationen eine Frage der Zeit...

Automated Software Evolution via Design Pattern Transformation" von L. Tokuda, D. Batory

Design Patterns: Abstraction and Reuse of Object-Oriented Design" von Erich Gamma 

Refactoring Object-Oriented Frameworks" von W.F.Opdyke

Designing reusable Classes" von E. Johnson

Evolving Object-Oriented Software Architectures with Refactorings" von L. Tokuda, D. Batory