Fakult¨at fur¨ Informatik

CSR-10-03

Transformation monolithischer Business-Softwaresysteme in verteilte, workflowbasierte Client-Server-Architekturen

Bj¨orn Krellner · Thomas Reichel · Gudula Runger¨ · Marvin Ferber Sascha Hunold · Thomas Rauber · Jurgen¨ Berndt · Ingo Nobbers

Juli 2010

Chemnitzer Informatik-Berichte Schlussbericht BMBF-Verbundprojekt TransBS

Transformation monolithischer Business-Softwaresysteme in verteilte, workflowbasierte Client-Server-Architekturen

Gefördert durch das BMBF Fördernummern 01 ISF 10 A/B/C

erstellt von: Björn Krellner1, Thomas Reichel1, Gudula Rünger1 Marvin Ferber2, Sascha Hunold2, Thomas Rauber2 Jürgen Berndt3, Ingo Nobbers3

1TU Chemnitz, Professur Praktische Informatik, 09107 Chemnitz 2Universität Bayreuth, Lehrstuhl für Angewandte Informatik II, 95440 Bayreuth 3Berndt & Brungs Software GmbH, Mottmannstr. 1–3, 53842 Troisdorf

Chemnitz, im Juli 2010

Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter den Förderkennzeichen 01 ISF 10 A – C gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

Inhaltsverzeichnis

1 Kurzdarstellung 11 1.1 Aufgabenstellung ...... 11 1.2 Voraussetzung für die Durchführung des Vorhabens ...... 12 1.3 Planung und Ablauf des Vorhabens ...... 13 1.4 Anknüpfung an den wissenschaftlich-technischen Stand ...... 16 1.5 Zusammenarbeit mit anderen Stellen ...... 17

2 Eingehende Darstellung 19 2.1 Erzielte Ergebnisse und Aufbau des Berichts ...... 19 2.2 Wichtige Positionen des zahlenmäßigen Nachweises ...... 19 2.3 Notwendigkeit und Angemessenheit der geleisteten Arbeit ...... 20 2.4 Voraussichtlicher Nutzen, insbesondere Verwertbarkeit des Ergebnisses 20 2.5 Während der Durchführung des Projekts bekannt gewordener Fortschritt auf dem Gebiet des Vorhabens ...... 21 2.6 Erfolgte und geplante Veröffentlichungen des Ergebnisses ...... 22

3 GBware und GBwareD 25 3.1 Analyse von GBware ...... 25 3.1.1 Kurzbeschreibung GBware ...... 25 3.1.2 Systemarchitektur ...... 25 3.1.3 Abarbeitung der Geschäftsprozesse ...... 27 3.1.4 Ablaufumgebungen ...... 28 3.2 Erstellung eines Anforderungskatalogs an GBwareD ...... 29 3.2.1 Kundenspezifische Anforderungen ...... 29 3.2.2 Anforderungen an GBwareD ...... 30 3.2.3 Hard- und Softwarekonfiguration von GBwareD ...... 33 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware ...... 34 3.3.1 Modularisierung von GBware ...... 34 3.3.2 Entwurf der Schnittstellen zwischen Modulen ...... 37 3.3.3 Extraktion der Workflow-Komponenten in GBware ...... 37 3.3.4 Testszenarien ...... 39 3.3.5 Kundenspezifische Konfigurationsmöglichkeiten ...... 40

4 Entwurf des Transformationssystems 43 4.1 Anforderungen an Transformationen und Transformationssystem . . . . 43 4.2 Basistechnologien und verwandte Ansätze ...... 45 4.2.1 Verteilungsplattformen ...... 45 4.2.2 Transformationsframeworks und -ansätze ...... 46 4.2.3 Workflowbeschreibungen ...... 47

3 Inhaltsverzeichnis

4.3 Konzeption des Transformationsprozesses ...... 47 4.3.1 Softwaresichten ...... 48 4.3.2 Grobstruktur des Transformationsprozesses ...... 50 4.4 Entwurf einer Software-Architektur des Transformationssystems . . . . 51

5 Auswahl einer Infrastruktur zur Realisierung des Transformations- systems 55 5.1 Model Driven Architecture (MDA) ...... 55 5.1.1 MDA Entwicklungsprozess ...... 56 5.1.2 MDA Werkzeuge ...... 57 5.2 Modellspezifikationen für Software und Transformationen ...... 58 5.3 Toolunterstützung der Verarbeitung der Transformation ...... 62 5.3.1 Compilerwerkzeuge ...... 62 5.3.2 Visualisierungswerkzeuge ...... 66

6 Entwicklung und Realisierung des Transformationssystems 69 6.1 Realisierung des Transformationssystems TRANSFORMR ...... 70 6.1.1 Inkrementeller Transformationsprozess ...... 70 6.1.2 Flexible Software Representation (FSR) ...... 72 6.1.3 Nutzerschnittstelle des Transformationssystems ...... 74 6.2 Metakomponenten des Transformationssystems ...... 76 6.3 Realisierung prototypischer Komponentenbildungstransformationen . . 78 6.3.1 MemberGroups ...... 80 6.3.2 Verschiebetransformationen ...... 82 6.3.3 Evaluierung der Verschiebetransformationen ...... 86 6.4 Realisierung prototypischer Filtertransformationen ...... 87 6.5 Skalierbarkeit des Transformationssystems ...... 90

7 Entwurf eines Client-Server-Frameworks CBFRAME 93 7.1 Zielsetzung ...... 93 7.2 Anforderungen ...... 93 7.3 Evaluation von Open Source Business-Software-Systemen ...... 94 7.4 Middleware-Plattform ...... 96 7.4.1 Anforderungen ...... 96 7.4.2 Java Enterprise Edition ...... 96 7.4.3 CORBA Component Model ...... 98 7.4.4 .NET Framework ...... 100 7.4.5 Zusammenfassung ...... 100 7.5 Transformation der grafischen Benutzeroberfläche ...... 101 7.5.1 Zielsetzung ...... 101 7.5.2 Konzepte zur UI-Transformation von GBware ...... 102 7.5.3 Zusammenfassung ...... 105 7.6 Rahmenarchitektur von CBFRAME ...... 105 7.7 Zusammenfassung ...... 106

4 Inhaltsverzeichnis

8 Auswahl einer Infrastruktur zur Realisierung des Client-Server- Frameworks 109 8.1 Zielsetzung ...... 109 8.2 Workflow-Beschreibungssprachen ...... 109 8.2.1 EPK ...... 109 8.2.2 BPMN ...... 110 8.2.3 Bewertung grafischer Modellierungswerkzeuge ...... 110 8.2.4 JPDL ...... 111 8.2.5 XPDL ...... 111 8.2.6 BPEL ...... 112 8.2.7 Fazit ...... 112 8.3 Vergleich verschiedener BPEL-Implementierungen ...... 113 8.4 Untersuchung der Kommunikationseigenschaften von JEE ...... 115 8.4.1 Anbindung von Legacy-Software über JMS ...... 115 8.4.2 Anbinden von Delphi-Clients an JEE-Applikationsserver . . . . 116 8.4.3 Kommunikation mit Enterprise JavaBeans über CORBA . . . . 118 8.5 Zusammenfassung ...... 119

9 Das Client-Server-Framework 121 9.1 Zielsetzung ...... 121 9.2 Das CBFRAME-Remote-Adapter-Pattern ...... 121 9.2.1 Musterbasierte Quellcodetransformation ...... 122 9.2.2 Verteilte Ausführung von Geschäftslogik ...... 123 9.2.3 Definition des CBFRAME-Remote-Adapter-Pattern ...... 124 9.2.4 Anwendung des CBFRAME-Remote-Adapter-Pattern ...... 125 9.2.5 Integration in TRANSFORMR ...... 127 9.2.6 CBFRAME-Remote-Adapter-Pattern für Webservices ...... 129 9.3 Effiziente verteilte Workflow-Abarbeitung ...... 131 9.3.1 Problemstellung und Ziele ...... 131 9.3.2 Automatische Transformation von BPEL-Prozessen ...... 133 9.3.3 Lastverteilungsverfahren für BPEL-Prozesse ...... 134 9.4 Zusammenfassung ...... 136

10 Prototypische Transformation der Referenzsoftware GBware 137 10.1 Prototypische Analyse und Transformation mit TRANSFORMR ..... 137 10.1.1 Anwendung von TRANSFORMR auf GBware ...... 137 10.1.2 Anwendung von TRANSFORMR auf TurboCASH ...... 141 10.2 Prototypische UI-Transformation von GBware ...... 144 10.2.1 Abstrakte UI-Zwischendarstellung ...... 144 10.2.2 GUI-Transformation von Delphi nach Java ...... 146 10.2.3 Anpassung der generierten GUI ...... 147 10.2.4 Diskussion über die Grenzen des Verfahrens ...... 148 10.3 Evaluierung von Kunden-Workflows ...... 149 10.3.1 Auswahl und Evaluierung der Workflow-Komponenten . . . . . 150 10.3.2 Anpassung der Kunden-Workflows ...... 152 10.4 Zusammenfassung ...... 152

5 Inhaltsverzeichnis

11 Zusammenfassung 155

12 Literaturverzeichnis 157

6 Abbildungsverzeichnis

3.1 3-Schicht Systemarchitektur der Business-Software GBware...... 26 3.2 Schematische Darstellung der Abarbeitung eines Workflows in GBware. 27 3.3 Konzept der Systemarchitektur der verteilten Business-Software GBwa- reD...... 33 3.4 Beispiel einer TTable mit generierten Adressdaten in einer Nutzer- schnittstelle...... 36 3.5 Schematische Darstellung der Modellierung von Geschäftsprozessen in GBware als zustandsbasierte Workflows mit assoziierten Aktionen. . . . 38 3.6 Nutzerschnittstelle des exemplarischen GBware mit reduzierter Funk- tionalität...... 39 3.7 ER-Modell der Abbildung von Geschäftsprozessen in einer relationalen Datenbank...... 40

4.1 Übergangsdiagramm der Flexible Software Representation (FSR) in verschiedene Softwaresichten...... 48 4.2 Transformationsentscheidungen und Transformationsprozess...... 50 4.3 Schematische Darstellung der Architektur des Transformationssystems. 51

5.1 Transformationsansatz nach der Model Driven Architecture (MDA). . . 56 5.2 Softwaremodelle Program Representation Graph und Dagstuhl Middle Model...... 59 5.3 Entwurf der Flexible Software Representation...... 61 5.4 Allgemeine Funktionsweise von TXL nach [15]...... 63

6.1 Transformationsprozess des Toolsets TRANSFORMR...... 71 6.2 Abstraktionsebenen des Transformationsprozesses...... 72 6.3 Softwaremodell (FSR) des Toolsets TRANSFORMR...... 73 6.4 Nutzerschnittstelle des Werkzeugs TRANSFORMR...... 74 6.5 Graph Dependency View des Toolsets TRANSFORMR...... 75 6.6 Beispiel einer Source-to-Model Transformation...... 77 6.7 TXL-Grammatik zum Hinzufügen von Annotationen...... 78 6.8 Membergroup Browser zur Analyse der FSR...... 82 6.9 Aufrufdiagramme zur Verschiebung einer common Membergroup. . . . 83 6.10 Aufrufdiagramme zur Verschiebung einer strong Membergroup. . . . . 85 6.11 UML-Diagramme der Extraktion eines Interfaces aus Basismodulen. . . 88 6.12 Beispiel einer TXL-Transformationsregel zur Extraktion eines Interfaces. 89 6.13 Laufzeitverhalten der Extraktionsphase...... 91 6.14 Speicherbedarf von Zwischendarstellung und Softwaremodell (FSR). . . 92 6.15 Beziehung von Laufzeit und Programmgröße in der Extraktionsphase. . 92

7 Abbildungsverzeichnis

7.1 Frontend-Transformation, Konzept 1...... 103 7.2 Frontend-Transformation, Konzept 2...... 104 7.3 Architektur von CBFRAME für Web-Clients...... 105

8.1 Beispiel grafisch modellierter Business Prozesses. (Links: BPMN, Rechts: EPK) ...... 110 8.2 Vergleich des erzielten Durchsatzes von JMS und MPI...... 116 8.3 Mögliche Anbindung des GBware-Clients an Java Enterprise Server . . 117 8.4 CORBA-JEE-Bridge...... 118 8.5 Zugriff auf Java-Routinen von Delphi...... 119

9.1 Schematische Darstellung der schrittweisen Anwendung einer muster- basierten Transformation...... 123 9.2 UML-Darstellung des CBFRAME-Remote-Adapter-Pattern...... 125 9.3 Anwendung des CBFRAME-Remote-Adapter-Pattern zur automati- schen Auslagerung von Methoden auf entfernte Server...... 126 9.4 Beispiel eines Templates zur automatischen Erzeugung eines Servicean- bieters auf Serverseite (RMI)...... 127 9.5 Screenshot des erzeugten Client/Server-Programms zur Berechnung ei- nes Mandelbrot-Bildes...... 128 9.6 Velocity-Template zur Generierung eines Remote-Interface...... 129 9.7 Implementierung des CBFRAME-Remote-Adapter-Pattern für Java und RMI in TRANSFORMR...... 129 9.8 Exemplarische Bereitstellung einer Funktion als Webservice...... 130 9.9 Als Webservice ausgelagerte Funktion...... 131 9.10 Workflowabarbeitung mit räumlich verteilten, redundanten Dienstanbie- tern (Providern)...... 132 9.11 Der Ausgangs-Workflow (oben) und der transformierte Workflow (un- ten) mit Scheduler zur Lastbalancierung der Webservice-Aufrufe. . . . 133 9.12 Durchschnittliche Ausführungszeit eines BPEL-Prozesses mit 10 Web- service-Aufrufen...... 135

10.1 Aufbau von Delphi Programmcode...... 138 10.2 UML-Klassendiagramm eines Ausschnitts des betrachteten Programm- codes...... 140 10.3 Screenshot der Nutzerschnittstelle von TurboCASH...... 142 10.4 Screenshots der Analyse von TurboCASH mit TRANSFORMR...... 144 10.5 Transformation und Konvertierung der Oberfläche einer Legacy- Anwendung...... 144 10.6 Mögliche Transformation einer Delphi-Oberfläche...... 146 10.7 Beispiel einer abstrakten Darstellung der GUI...... 147 10.8 Beispiel einer Delphi-Java-Transformation...... 149 10.9 Abbildung des Kunden-Workflows „Rechnung“ aus GBware als Zu- standsautomat...... 150 10.10 Abbildung des Kunden-Workflows „Rechnung“ und modifizierter Kunden-Workflow mit Integration einer Liquiditätsprüfung ...... 151

8 Tabellenverzeichnis

1.1 Zusammenfassender Überblick über die Arbeitspakete...... 13

3.1 Konfiguration von Betriebssystem und Datenbankserver für GBware. . . 28

4.1 Abstraktionsschichten der Softwaresichten der FSR...... 49

5.1 Auswahl frei verfügbarer und proprietärer MDA Werkzeuge (Stand: September 2006)...... 58

6.1 Unterstützte Betriebssysteme des Laufzeitsystems und der genutzten Werkzeuge des Transformationssystems...... 69 6.2 Knotenmengen und Kanten des Softwaremodells zur Ermittlung von MemberGroups...... 81 6.3 Verbesserungen der Anzahl abhängiger Klassenpaare...... 87

7.1 Vergleich von Open Source-ERP-Systemen...... 95 7.2 Implementierungen der Java-Enterprise-Edition ...... 97 7.3 Programmiersprachen mit CORBA-Anbindung...... 99 7.4 Vergleich von CORBA-Implementierungen...... 100 7.5 Gegenüberstellung von Enterprise-Frameworks...... 101

8.1 Vergleich verschiedener BPEL-Ablaufumgebungen...... 114

9.1 Vergleich der Antwortzeiten einer Funktion für unterschiedliche Kontexte.131

10.1 Zuordnung von Elementen einer Delphi Unit zu Modellelementen der FSR...... 139 10.2 Verwendete Dateitypen in Konfiguration und Programmcode von Tur- boCASH...... 143 10.3 Freie Projekte zur Generierung der grafischen Benutzeroberfläche für Java.145

9 Tabellenverzeichnis

10 1 Kurzdarstellung

1.1 Aufgabenstellung

Das Ziel des Projekts TransBS bestand in der Entwicklung einer Methodik zur Überfüh- rung existierender, monolithischer Business-Softwaresysteme in eine moderne, kompo- nentenbasierte, verteilte, skalierbare und auf Open Source Produkten basierende Client- Server-Architektur mit konfigurierbaren Workflows für heterogene Plattformen. Dabei sollte die interne modulare und logische Struktur der gegebenen Software berücksichtigt werden, die die Grundlage der Komponentenbildung und der Auswahl der Verteiltheit bildet.

Die wesentlichen Arbeitspunkte des Projekts beinhalteten:

• Die Entwicklung und prototypische Umsetzung eines funktionalitäts- und kor- rektheitserhaltenden Transformationswerkzeugs zur Überführung der Module von Business-Softwaresystemen in Komponenten, die in einem Client-Server-System ausgeführt werden können. Zur Überführung der Softwaresysteme wurde ein in- krementeller Transformationsansatz vorgeschlagen, durch den schrittweise aus der gegebenen Grobstruktur eine den speziellen Anforderungen entsprechende, verteilte Software entsteht. Das Transformationswerkzeug sollte über geeigne- te Beschreibungs- und Spezifikationssprachen für die Modulinteraktion verfügen und mit Hilfe von compilerbasierten Methoden realisiert werden. Dabei spielte die Separation von Aspekten der Geschäftslogik, Verteiltheit, Sicherheit und He- terogenität eine wesentliche Rolle. • Die Entwicklung eines offenen, erweiterbaren und modularen Client-Server-Fra- meworks für Business-Software mit Kommunikationsinterface, in das Teile der existierenden Business-Softwaresystemen integriert werden können. Wesentlicher Bestandteil dieses Arbeitspunkts war die Auswahl einer geeigneten Zielplattform für die zu transformierende Software sowie die Festlegung geeigneter Protokolle, um sowohl die Sicherheit der Datenübertragung als auch die Ausfallsicherheit des Gesamtsystems zu gewährleisten. • Die exemplarische Transformation des sich im Einsatz befindenden Business- Softwaresystems GBware (General Businessware) in ein verteiltes Softwaresys- tem GBwareD. GBwareD sollte über spezielle Workflows gemäß kundenspezifi- scher Gegebenheiten konfiguriert bzw. parametrisiert und für neue Aufgabenbe- reiche erweitert werden können.

Die Transformation existierender, über viele Jahre gewachsener Softwaresysteme in mo- dulare und skalierbare Systeme, die auf unterschiedlichen Plattformen ausführbar sind,

11 1 Kurzdarstellung ist eine der großen Herausforderungen im Softwarebereich. Die im Projekt TransBS ent- wickelte Methodik sollte eine einfache Adaption, Erweiterbarkeit und Wartbarkeit der existierenden Softwaresysteme sichern und damit die Marktchancen der Systeme erhö- hen.

1.2 Voraussetzung für die Durchführung des Vorhabens

Das Verbundprojekt war so zusammengesetzt, dass die erforderlichen wesentlichen Ar- beitspunkte in der Kernkompetenz des jeweiligen Projektpartners lagen. Dazu konnte das Know-how über kaufmännische Prozesse und kundenspezifische Anforderungen, über den Entwurf und die Realisierung von parallelen und verteilten Systemen und über die Analyse und Transformation von Software gezielt in den Arbeitspunkten angewen- det werden.

Professur Praktische Informatik, TU Chemnitz

Die Professur Praktische Informatik an der TU Chemnitz beschäftigt sich seit vielen Jahren mit der Realisierung großer modularer Anwendungen für verteilte Systeme in in- terdisziplinärer Zusammenarbeit mit Partnern aus Industrie und Wissenschaft. Darüber hinaus spielt die Realisierung von Übersetzerwerkzeugen zur schrittweisen Transforma- tion von Spezifikationen und Programmcode eine wichtige Rolle. Die TU Chemnitz bearbeitete vor allem die Entwicklung des Transformationsprozesses und die prototypische Entwicklung eines Transformationswerkzeugs. Darüber hinaus war die Konsortialführung bei der TU Chemnitz angesiedelt, was auch die Vermittlerrol- le des Transformationswerkzeugs zwischen Business-Software und verteilten Systemen deutlich macht (Kapitel 4 bis 6 und 10).

Lehrstuhl Angewandte Informatik II, Universität Bayreuth

Die Kernkompetenz des Lehrstuhls für Angewandte Informatik II der Universität Bay- reuth umfasst die Realisierung spezialisierter, anwendungsorientierter Hard- und Soft- warelösungen für verteilte Systeme, die Entwicklung von Kommunikationsbibliotheken für taskbasierte Komponentensysteme und Verteilungsstrategien für Anwendungen in parallelen und verteilten Systemen. Zwischen der TU Chemnitz und der Universität Bayreuth gibt es eine langjährige Zusammenarbeit im Bereich der effizienten Umset- zung komponentenbasierter Anwendungen auf verschiedenen Plattformen. Die Universität Bayreuth war schwerpunktmäßig mit dem Entwurf und der Realisie- rung des Client-Server-Frameworks sowie der Entwicklung geeigneter Protokolle und Schnittstellen zwischen Client und Server befasst (Kapitel 7 bis 9 und 10).

12 1.3 Planung und Ablauf des Vorhabens

Berndt & Brungs Software GmbH, Troisdorf

Die Berndt & Brungs Software GmbH gegründet 1987, verfügt über umfangreiche Er- fahrungen im Bereich der kaufmännischen Prozesse und deren Konzeption und Umset- zung in Softwareprodukte. Diese Kompetenzen werden seit 1995 in Zusammenarbeit mit KMUs im eigenen Produkt GBware (jetzt aimap) implementiert und eingesetzt. Die Leistungserbringung von Berndt & Brungs Software GmbH erfolgt durch den Verkauf von Nutzungslizenzen, die Realisierung von kundenspezifischen Anforderungen sowie durch begleitende Consulting-Leistungen (Schulung, Customizing, u. a.).

Im beantragten Projekt übernahm die Berndt & Brungs Software GmbH schwerpunkt- mäßig die Analyse von GBware, die Erstellung eines Anforderungskatalogs an ein verteiltes System GBwareD unter Einbringung der Kundenwünsche und verschiedene Vorbereitungs- und Anpassungsarbeiten von GBware zur Transformation in GBwareD (Kapitel 3 und 10).

Zusammenarbeit

Insbesondere in Arbeitspaketen, die sich Planungs- und Vorbereitungsarbeiten widmen, in Analyse- und Entwurfsphasen sowie in der abschließenden Phase war eine starke Interaktion der Verbundpartner notwendig. Der Austausch der Projektbeteiligten wurde besonders in diesen Phasen durch Kontaktbesuche unterstützt.

1.3 Planung und Ablauf des Vorhabens

Der Arbeitsplan des Projekts TransBS war in elf Arbeitspunkte aufgeteilt, wobei die Ar- beitspunkte 1–3 vorrangig von der Berndt & Brungs Software GmbH, die Arbeitspunkte 4–6 von der TU Chemnitz und die Arbeitspunkte 7–9 von der Universität Bayreuth be- arbeitet wurden. Der abschließende Arbeitspunkt 10 (Evaluation und Dokumentation der bisherigen Arbeiten) wurde in Interaktion durch alle Projektbeteiligte durchgeführt. Tabelle 1.1 fasst die Arbeitspunkte und deren Inhalte zusammen.

Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete.

Arbeits- Bezeichnung Inhaltsbeschreibung Betei- pakete ligte AP 1 Analyse von GBware Analyse des Ist-Zustandes von GBware und BBS Erfassung von kundenspezifischen Gegeben- heiten, die für eine Transformation und ver- teilte Ausführung berücksichtigt werden sol- len. AP 1.1 Analyse der Systemarchitektur AP 1.2 Erfassung der Workfloweigenschaften

13 1 Kurzdarstellung

Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete.

Arbeits- Bezeichnung Inhaltsbeschreibung Betei- pakete ligte AP 1.3 Erfassung der Voraussetzungen von Kundenseite AP 1.4 Erfassung der Anforderungen an die Ausführungsplattform

AP 2 Erstellung eines Anforde- Konkretisierung der Anforderungen an das BBS rungskataloges an GBwa- resultierende Softwaresystem GBwareD und reD Prüfung auf Konsistenz und Machbarkeit. AP 2.1 Konkretisierung der Anforderungen an eine verteilte Realisierung AP 2.2 Untersuchung der Anforderungen an die verteilten Workflows AP 2.3 Erfassung der Ziel-Hardwarekonfiguration AP 2.4 Bestimmung der zu integrierenden Teile von GBware

AP 3 Vorbereitungs- und An- Vorbereitung von GBware auf den Transfor- BBS passungsarbeiten für GB- mationsprozess, vor allen eine Modularisie- ware rung, Untersuchung von Abhängigkeiten und Definition von Schnittstellen. AP 3.1 Modularisierung von GBware AP 3.2 Entwurf von Schnittstellen zwischen den Modulen AP 3.3 Extraktion der Workflowkomponenten von GBware AP 3.4 Definition eines Testszenarios AP 3.5 Spezifikation kundenspezifischer Konfigurationsmöglichkeiten

AP 4 Entwurf des Transforma- Entwurf der Mechanismen des Transforma- TUC tionssystems TransBS tionsprozesses, Spezifikation der Zwischen- formate, Automatisierungs- und Interaktions- möglichkeiten der Transformation. AP 4.1 Erstellung einer Anforderungsspezifikation an die Transformationssoftware AP 4.2 Planung und Entwurf des inkrementellen Transformationsvorgangs AP 4.3 Anforderungskatalog und Planung von Korrektheits- und Bewer- tungsmechanismen AP 4.4 Entwurf der Softwarearchitektur des Transformationssystems

AP 5 Auswahl einer Infrastruk- Evaluation existierender Sprach- und Trans- TUC tur zur Realisierung des formationsansätze und Festlegung von Transformationssystems Sprachkonzepten und -Mechanismen. AP 5.1 Erfassung und Auswahl von Transformationsmechanismen AP 5.2 Erfassung, Auswahl und Definition von Spezifikationssprachen AP 5.3 Planung von Metakomponenten des Transformationswerkzeuges

AP 6 Entwicklung und Rea- Inkrementelle Realisierung eines prototypi- TUC lisierung des prototypi- schen Transformationssystems basierend auf schen Transformations- AP 4 und AP 5 und Evaluation der Werkzeug- systems komponenten. AP 6.1 Planung und Festlegung der Hard- und Softwareplattformen AP 6.2 Entwicklung und Realisierung des Transformationsfrontends

14 1.3 Planung und Ablauf des Vorhabens

Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete.

Arbeits- Bezeichnung Inhaltsbeschreibung Betei- pakete ligte AP 6.3 Entwicklung und Realisierung der Komponentenbildungs-Transformation AP 6.4 Entwicklung und Realisierung der Filter-Transformation AP 6.5 Entwicklung und Realisierung der Metakomponenten AP 6.6 Evaluation der Werkzeugkomponenten

AP 7 Entwurf eines Client- Analyse der Anforderungen an eine verteilte UBT Server-Frameworks Software und Festlegung von Funktionalität CBFrame und Komponenten des Frameworks. AP 7.1 Entwurf der Architektur des Frameworks AP 7.2 Entwurf der statischen Komponenten des Frameworks AP 7.3 Festlegung des verwendeten Kommunikationsprotokolls AP 7.4 Definition eines Sicherheitskonzepts AP 7.5 Mechanismen zur Ausfallsicherheit durch Datenredundanz AP 7.6 Definition der verwendeten Workflows

AP 8 Auswahl einer Infra- Auswahl einer Infrastruktur durch Analyse UBT struktur zur Realisierung von Laufzeitsystemen zur Verarbeitung von des Client-Server- Workflows und Untersuchung von Middlewa- Frameworks relösungen (z. B. JRE, CORBA). AP 8.1 Definition einer Spezifikationssprache für Workflows AP 8.2 Auswahl einer Implementierungsplattform AP 8.3 Entwicklung einer Kommunikationsplattform

AP 9 Entwicklung und Rea- Implementierung eines prototypischen Fra- UBT lisierung des prototy- meworks aufbauend auf AP 7 und AP 8 zur pischen Client-Server- Integration von erzeugten Komponenten von Frameworks GBware. AP 9.1 Entwicklung und Realisierung des Kommunikationsprotokolls AP 9.2 Entwicklung und Realisierung des Kommunikationsmoduls AP 9.3 Entwicklung und Realisierung der Datenhaltungskomponente mit Datenkonsistenz AP 9.4 Entwicklung und Realisierung der Marshalling-Komponente zur Konvertierung von Datenformaten AP 9.5 Entwicklung und Realisierung einer Flattening-Komponente zur Workflow-Verarbeitung AP 9.6 Evaluation der Framework-Komponenten

AP 10 Prototypische Transfor- Abschließende Evaluation und Dokumenta- BBS, mation der Referenzsoft- tion verschiedener Teile des Prototyps aus UBT, ware GBware Transformationswerkzeug und Client-Server- TUC Framework. AP 10.1 Anwendung von TransBS auf GBware AP 10.2 Ausführliche Tests anhand verschiedener Kunden-Workflows AP 10.3 Parametrisierung der Workflows anhand von Kundenszenarien

15 1 Kurzdarstellung

Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete.

Arbeits- Bezeichnung Inhaltsbeschreibung Betei- pakete ligte AP 11 Projektmanagement, Regelmäßige Projekttreffen zur Koordination BBS, Publikationstätigkeit der Arbeiten und Veröffentlichung erreichter UBT, Resultate in internationalen Publikationsorga- TUC nen.

1.4 Anknüpfung an den wissenschaftlich-technischen Stand

Softwaresysteme zur Realisierung von Geschäftsprozessen erfordern eine weitgehen- de Konfigurierbarkeit, Adaptionsmöglichkeit und Erweiterbarkeit gemäß kundenspezifi- scher Anforderungen, sollen aber möglichst kostengünstig realisiert werden. Ausgangs- punkt ist dabei oft ein existierendes Softwaresystem, welches durch langjährige Arbeit und Expertenwissen über die jeweilige Unternehmensstruktur an die Erfordernisse des jeweiligen Kunden angepasst wurde, so dass nicht nur eine funktionierende, sondern auch für ein Unternehmen essentiell notwendige Softwareinfrastruktur im Laufe der Jahre gewachsen ist. Dem steht ein ständiger Wandel der Hard- und Softwarestruktu- ren und Technologien gegenüber, dem sich Unternehmen aus Gründen der Sicherheit, Leistungsfähigkeit, Kosten oder auch Verfügbarkeit von Plattformen anpassen müssen [16]. Zusätzlich müssen Design und Architektur bei langjähriger Weiterentwicklung und Wartung angepasst werden, was auf Grund bestehender Strukturen zur Erosion der ur- sprünglichen Architektur führen kann (Code Decay [18]) und eine Restrukturierung des Gesamtsystems notwendig macht. Bisherigen Softwaresystemen fehlen häufig entschei- dende Aspekte wie Verteiltheit, Anpassbarkeit an heterogene Plattformen oder Skalier- barkeit, die zu Beginn der Entwicklung nicht abzusehen waren, aber zunehmend an Wichtigkeit gewinnen und nachträglich nur schwierig oder mit erheblichem Aufwand zu integrieren sind, da sie eine vollständige Reorganisation der Systemarchitektur erfor- dern können und alle Bereiche eines Unternehmens betreffen können.

Der Problemkreis der Realisierung moderner, verteilter, effektiver Unternehmenssoft- ware wird in jüngster Zeit aus verschiedenen Gesichtspunkten und Wissenschaftsdis- ziplinen in praktischer und theoretischer Hinsicht aufgegriffen, darunter Management- Entscheidungsstrategien zur Softwareerneuerung, Aspekte der Geschäftsmodellierung, softwaretechnische Aspekte der Reengineering- und Legacy-Problematik auf der Basis von Softwarearchitekturen oder ganz konkreter Fallstudien sowie Softwaredesignprin- zipien für verteilte Systeme.

Eine häufige Fragestellung im Management- oder Software-Engineeringbereich ist die kostengünstige und effektive Überführung erprobter monolithischer Unternehmenssoft- ware in moderne, verteilte Systeme, wobei gerade Softwareprodukte beachtet werden, die Ende der 80er oder Anfang der 90er Jahre im Hinblick auf den damaligen aktuellen

16 1.5 Zusammenarbeit mit anderen Stellen

Standard der Modularität und Flexibilität entworfen wurden, aber den technologischen Anforderungen der jüngsten Entwicklungen nicht mehr genügen. Darüber hinaus bedin- gen weitreichende Änderungen der Anforderungen eine wesentliche Überarbeitung der Architektur der bestehenden Softwaresysteme, was ebenfalls die Fragestellung nach ei- ner kostengünstigen und effektiven Überführung aufwirft. Die zahlreichen Ansätze zur Entwicklung komponentenbasierter und verteilter Systeme berücksichtigen dieses Pro- blem kaum in detaillierter Form, sondern beschäftigen sich entweder mit dem Design neuer Software oder mit der ganzheitlichen Ankopplung bestehender Softwarekompo- nenten über Wrapper- und Middleware-Lösungen. Beides wird bestehender leistungsfä- higer, modularer Unternehmenssoftware nicht gerecht.

Zur Transformation von Business-Software wurden neue Methoden und Verfahren ent- wickelt, die im Transformationswerkzeug TRANSFORMR prototypisch realisiert sind. Ein Hauptbeitrag des Projekts lag in der Entwicklung der inkrementellen Transforma- tionsmethodik, in der schrittweise aus einer gegebenen monolithischen Software inter- aktiv eine auf einer Client-Server-Architektur basierende Software erzeugt wird. Die umfassende Analyse der bestehenden Software stellt dabei eine maßgebliche Voraus- setzung für die vielfältigen Transformationsmöglichkeiten dar. Da die Modularität der gegebenen Software wesentliche Voraussetzung für eine Transformation in ein verteiltes System darstellt, die jedoch nicht vorausgesetzt werden kann, war auch die Entwicklung von Methoden zur Erzeugung und Bewertung von Modularität ein wesentlicher Bestand- teil des Projekts.

1.5 Zusammenarbeit mit anderen Stellen

Innerhalb des TransBS-Konsortiums waren alle für das Projekt wesentlichen Kompe- tenzen durch die Projektbeteiligten vertreten: Praktiker im Umfeld von kaufmännischen Prozessen und Entwicklung von Business-Software anhand kundenspezifischer Anfor- derungen und wissenschaftliche Forschung im Bereich der Software- und Systement- wicklung verteilter und heterogener Systeme sowie die Entwicklung und Realisierung von Transformationswerkzeugen im Bereich Compilerbau.

17 1 Kurzdarstellung

18 2 Eingehende Darstellung

2.1 Erzielte Ergebnisse und Aufbau des Berichts

Die erzielten Ergebnisse des Projekts sind im Detail in den Abschnitten 3 bis 10 dar- gestellt. Kapitel 3 beschreibt die Analyse der Business-Software GBware, stellt einen Anforderungskatalog an ein verteiltes System GBwareD vor und beschreibt die durchge- führten Vorbereitungs- und Anpassungsarbeiten zur Realisierung der gestellten Anfor- derungen. Die Kapitel 4 bis 6 beschreiben die Konzepte und die Realisierung des Trans- formationssystems. Aufbauend auf einem allgemeinen inkrementellen Transformations- ansatz werden mögliche existierende Softwaresysteme zur Umsetzung des Transforma- tionsansatzes evaluiert. Abschließend wird in Kapitel 6 die Implementierung des Trans- formationswerkzeugs TRANSFORMR dargelegt. Der Entwurf des Client-Server-Frame- works und der darin enthaltenen Komponenten wird in Kapitel 7 erörtert. Auf dieser Grundlage werden in Kapitel 8 Infrastrukturen zur Umsetzung des Frameworks eva- luiert, die in Kapitel 9 in der prototypische Realisierung des Frameworks CBFRAME münden. Im Kapitel 10 werden die prototypisch realisierten Werkzeuge des Transfor- mationssystems und des Client-Server-Frameworks auf die Business-Software GBware prototypisch angewendet.

Dem Projektpartner Berndt & Brungs Software GmbH sind dabei die Kapitel 3 und 10, der TU Chemnitz die Kapitel 4 bis 6 und 10 und der Universität Bayreuth die Kapitel 7 bis 10 gemäß des Arbeitsplans vorrangig zuzuordnen.

2.2 Wichtige Positionen des zahlenmäßigen Nachweises

Die Zuwendung des BMBF für das Projekt TransBS wurde im Wesentlichen für Perso- nalmittel der insgesamt sechs geförderten Mitarbeiterstellen der Projektpartner (jeweils zwei Stellen TU Chemnitz, Universität Bayreuth und Berndt & Brungs Software GmbH) verwendet.

Die Einzelheiten der Verwendung sind in den Erfolgskontrollberichten und in den rech- nerischen Nachweisen enthalten.

19 2 Eingehende Darstellung

2.3 Notwendigkeit und Angemessenheit der geleisteten Arbeit

Bei den angestrebten Projektzielen (Abschnitt 1.1) handelte es sich um zusätzliche Ak- tivitäten aller Projektbeteiligter, die durch die Wahrnehmung ihrer sonstigen Pflichten voll ausgelastet sind. Für die Berndt & Brungs Software GmbH ist die Überführung des monolithischen Systems GBware in eine modulare, verteilte Client-Server-Architektur eine Aufgabe, die ohne die zur Verfügung gestellten Mittel nicht ganzheitlich durchge- führt werden konnte.

Durch die Förderung wurden Konzepte zur schrittweisen Überführung der bestehenden Software GBware identifiziert und in einem generischen Werkzeug prototypisch rea- lisiert, die auch in anderen Business-Software-Systemen Anwendung finden können. Dabei stellten sich vor allem die Analyse und Transformation von Programmcode (Ka- pitel 4 – 6) und die Konfiguration der Verteiltheit und die Extraktion von Workflow- Komponenten (Kapitel 7 – 9) sowie die Anbindung des Legacy-Delphi Programmcodes (Abschnitt 8.4) als fordernd und vielschichtig heraus.

Das realisierte Transformationswerkzeug sowie die zugehörigen Konzepte zur Erzeu- gung von Verteiltheit und Modularität konnten erfolgreich für GBware und weitere un- tersuchte Systeme eingesetzt werden (Abschnitte 6.3 und 6.5 und Kapitel 10).

2.4 Voraussichtlicher Nutzen, insbesondere Verwertbarkeit des Ergebnisses

Die Forschungsarbeiten an der TU Chemnitz und der Universität Bayreuth, insbeson- dere die Betrachtungen zu Modularität, Verteiltheit und Parallelität, werden an den je- weiligen Professuren weiter verfolgt. Dabei bildet der entwickelte Prototyp eines Trans- formationswerkzeugs (TRANSFORMR) eine wichtige Grundlage für weitere Forschung und Evaluation. Durch den modularen Aufbau des Werkzeugs und die inkrementelle Methodik können neue Funktionalitäten einfach in das System integriert werden. Das bestehende Wissen über Workflows konnte bereits in einem weiteren Projekt, das sich vor allem der energetischen Betrachtung von Entwicklungs- und Herstellungsprozessen widmet, erfolgreich eingebracht werden.

Das Unternehmen Berndt & Brungs Software GmbH konnte die entwickelten Methoden und Konzepte erfolgreich in die Weiterentwicklung ihrer Software GBware (jetzt aimap) einbinden. Dabei führte die neu eingebrachte Modularität zu mehr Flexibilität und zu einer einfacheren Durchführung der Anpassungen der Software an die spezifischen Be- dürfnisse der Kunden. Vor allem im Bereich der Webzugriffs von aimap konnten dabei große Fortschritte gemacht werden. Mit diesen Voraussetzungen konnte die Software aimap ihr Marktpotential sichern und in einigen Bereichen (z. B. dem Fuhrparkmanage- ment) ausbauen.

20 2.5 Während der Durchführung des Projekts bekannt gewordener Fortschritt auf dem Gebiet des Vorhabens 2.5 Während der Durchführung des Projekts bekannt gewordener Fortschritt auf dem Gebiet des Vorhabens

Während der Durchführung des Projekts wurden von verschiedenen Forschergruppen neue Aspekte, die auch das Projekt TransBS betreffen, publiziert. So zeigen neuere Ar- beiten im Bereich der Transformation von Programmcode wie die Kategorisierung von Programmcode zur Remodularisierung [16], Ansätze zur automatischen Transformation auf Basis von Metriken [51] oder evolutionären Strategien [26] die Bedeutsamkeit au- tomatischer Code-Transformationen. Ein wesentlicher Aspekt ist die Zusammenarbeit der Transformationswerkzeuge (bspw. über ein gemeinsames Austauschformat), um je nach vorliegender Problemstellung geeignete Transformationsmechanismen zu verwen- den [33]. Die Analyse des gegebenen Programmcodes stellt dabei einen essentiellen Aspekt für aufbauende Transformationen dar [9].

Verschiedene Verfahren zur modellgetriebenen Softwareentwicklung (MDA) kommen in unterschiedlichen Domänen zum Einsatz, um für verschiedene Zielplattformen (bspw. verschiedene Betriebssysteme für Mobilgeräte [37]) ausführbaren Programmcode zu ge- nerieren. Die Erzeugung eines vollständigen plattformunabhängigen Modells für beste- henden Programmcode steht jedoch wie zum Zeitpunkt der Antragstellung weiterhin aus (siehe auch Kapitel 5.1).

Die Entwicklung WFMC-konformer1 Open Source Workflow-Engines und die Evalua- tion der Integration der Engines in Business-Software schritt im Projektzeitraum weiter voran [35]. Eine allgemein geeignete Strategie zur Extraktion von Business-Workflows konnte auf Grund der Vielzahl von Individuallösungen zur Realisierung von Workflows noch nicht formuliert werden [54].

Auch die Entwicklung von Business-Plattformen, die Basisfunktionalitäten zur Einbet- tung individueller Geschäftsprozesse bieten, hat sich weiter fortgesetzt. Die für das Pro- jekt TransBS relevante Plattform JavaEE (Java Platform Enterprise Edition) wurde durch eine Vielzahl proprietärer und frei zugänglicher Komponenten erweitert. Beispiele dafür sind standardisierte Schnittstellen zur Datenbankabstraktion (JPA) und zur Realisierung einer Abbildung zwischen Geschäftsobjekten und relationaler Datenbank (Hibernate), Frameworks zur Integration von Rich Internet Applications (Web-2.0-Anwendungen, AJAX) in Java (z. B. Richfaces) und die Einbindung von Workflow-Engines durch die Modellierung von Geschäftsprozessen beispielsweise mit jBPM (Java Business Process Modelling) [29]. Dabei bewegte sich der Trend weg von der Spezifikation der Kompo- nenten in XML, hin zur Festlegung von Eigenschaften durch Annotationen. Durch die Kombination einer großen Zahl unterschiedlicher Komponenten zur effektiven Realisie- rung einer Business-Plattform ist eine Einbindung bestehender Software in die Frame- works nur durch komplexe Transformationen möglich [28].

1Workflow Management Coalition: Verbund von über 300 Herstellern, Beratern und Wissenschaftlern zur Standardisierung und Etablierung eines Workflow-Referenzmodells.

21 2.6 Veröffentlichungen

Gegenüber den im Antrag dargestellten Aktivitäten haben sich keine Änderungen erge- ben.

2.6 Erfolgte und geplante Veröffentlichungen des Ergebnisses

Erfolgte Veröffentlichungen

[FHK+09a]F ERBER,M.,S.HUNOLD,B.KRELLNER, T. RAUBER, T. REICHEL und G.RÜNGER: Reducing the Class Coupling of Legacy Code by a Metrics- Based Relocation of Class Members. Erscheint in: Proc. of the 4th IFIP TC2 Central and East European Conf. on Software Engineering Techni- ques (CEE-SET), 2009. [FHK+09b]F ERBER,M.,S.HUNOLD,B.KRELLNER, T. RAUBER, T. REICHEL und G.RÜNGER: Softwaremodernisierung durch werkzeugunterstütztes Ver- schieben von Codeblöcken. In: Software Engineering 2009 - Workshop- band, Band P-150 der Reihe Lecture Notes in Informatics, Seiten 393–401, Bonn, 2009. Köllen Druck+Verlag GmbH. [FHR09]F ERBER,M.,S.HUNOLD und T. RAUBER: Load Balancing Concurrent BPEL Processes by Dynamic Selection of Web Service Endpoints. In: ICPPW ’09: Proceedings of the 2009 International Conference on Paral- lel Processing Workshops, Seiten 290–297, Washington, DC, USA, 2009. IEEE Computer Society. [HKK+08a]H UNOLD,S.,M.KORCH,B.KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Inkrementelle Transformation einer monolithischen Ge- schäftssoftware. In: Software Engineering 2008 - Workshopband, Band P- 122 der Reihe Lecture Notes in Informatics, Seiten 226–231, Bonn, 2008. Köllen Druck+Verlag GmbH. [HKK+08b]H UNOLD,S.,M.KORCH,B.KRELLNER, T. RAUBER, T. REICHEL und G.RÜNGER: Transformation of Legacy Software into Client/Server App- lications through Pattern-based Rearchitecturing. In: Proc. of the 32nd Annual IEEE Int. Computer Software and Applications Conf., COMPSAC ’08, Seiten 303–310. IEEE Computer Society, 2008. [HKR+09]H UNOLD,S.,B.KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Pattern-based Refactoring of Legacy Software Systems. In: Proc. of the 11th Int. Conf. on Enterprise Information Systems (ICEIS), Seiten 78–89. Springer, 2009. [KR06]K ÜHNEMANN, M. und G. RÜNGER: Modellgetriebene Transformation von Legacy Business-Software. In: KAISER, U., P. KROHA und A. WIN- TER (Herausgeber): 3. Workshop Reengineering Prozesse (RePro 2006), Software Migration, Band Mainzer Informatik-Bericht Nr. 2/2006, 2006.

22 2.6 Geplante Veröffentlichungen

[RR06]R AUBER, T und G. RÜNGER: Transformation von Business-Software für Client-Server Architekturen. BMBF-Statuskonferenz, Leipzig, 2006. [RR07]R AUBER, T. und G. RÜNGER: Transformation of Legacy Business Soft- ware into Client-Server Architectures. In: Proc. of the 9th Int. Conf. on Enterprise Information Systems, Seiten 36–43. INSTICC, 2007. [RR08]R AUBER, T. und G. RÜNGER: Incremental Transformation of Business Software. In: Lecture Notes in Business Information Processing, Band 12 der Reihe LNBIP, Seiten 81–94. Springer, 2008. [RR10]R AUBER, T. und G. RÜNGER: Adaptive Execution of Software Systems on Parallel Multicore Architectures. Erscheint in: Proc. of the 12th Int. Conf. on Enterprise Information Systems (ICEIS), 2010.

Geplante Veröffentlichungen

[BFH+]B ERNDT,J.,M.FERBER,S.HUNOLD,B.KRELLNER,I.NOBBERS, T. RAU- BER, T. REICHEL und G. RÜNGER: Transformation monolithischer Business- Softwaresysteme in verteilte, workflowbasierte Client-Server-Architekturen. Technischer Bericht, Erscheint in: Chemnitzer Informatik-Berichte. [FHRa]F ERBER,M.,S.HUNOLD und T. RAUBER: BPEL Remote Objects: Integra- ting BPEL Processes into Object-Oriented Applications. Konferenzbeitrag. [FHRb]F ERBER,M.,S.HUNOLD und T. RAUBER: Executing Software Modules in a Compute Cloud Using Web Service Technology. Konferenzbeitrag. [KRR]K RELLNER, B., T. REICHEL und G. RÜNGER: TransFormr - Incremental Transformation of Legacy Business Software Systems. Zeitschriftenartikel. [RR]R EICHEL, T. und G. RÜNGER: Incremental Software Restructuring by Succes- sive Dependency Analysis and Transformation. Konferenzbeitrag.

23 2.6 Geplante Veröffentlichungen

24 3 GBware und GBwareD

3.1 Analyse von GBware

3.1.1 Kurzbeschreibung GBware

GBware (jetzt aimap) ist eine voll integrierte kaufmännische Anwendung, die als Pro- zesssteuerungswerkzeug und als Kommunikationsplattform zum Einsatz im Groß- und Einzelhandel, sowie im Internetverkauf eingesetzt wird. Mit der Business-Software kann eine vollständige Prozesskette vom Lieferanten bis zum Kunden mit einer Vielzahl von unterschiedlichen klassischen Modulen wie z. B. Einkauf, Verkauf, Kasse, Zahlungs- und Mahnwesen, Marketing oder Lagerverwaltung sowie einigen individuellen Modu- len wie z. B. die Projektakte zur Projekt- und Dokumentenverwaltung im Internet abge- bildet werden.

Die spezifischen Geschäftsprozesse der einzelnen Kunden werden durch eine Parame- trisierung von GBware und die Integration individueller Prozesse im System abgelegt. Dabei liegt ein Schwerpunkt auf der schnellen Ausführung der Prozesse bei gleichzeiti- ger Sicherstellung der Datenkonsistenz durch eine transaktionsbasierte Steuerung.

3.1.2 Systemarchitektur

Die Architektur der Business-Software GBware kann in drei Schichten eingeteilt wer- den. Abbildung 3.1 veranschaulicht die drei Schichten und ihre Abhängigkeiten.

• In der zentralen Datenbank werden sowohl die Geschäftsdaten als auch die Dar- stellung der Geschäftsprozesse als Workflows abgelegt. Für den jeweiligen Kun- den werden darüber hinaus über Administrationsmodule die Rechte und Rollen der Nutzer von GBware und ihre Sichten auf die Geschäftsdaten gespeichert. Zu- dem wird die Konfiguration der vom Kunden genutzten Module ebenfalls in der Datenbank hinterlegt. Durch die Nutzung einer Oracle Datenbank konnten spezifische, leistungskri- tische Funktionalitäten der Business-Logik als Datenbank-Funktionen realisiert werden. Dies bietet den Vorteil, dass individuelle Prozeduren genau wie normale Datenbankabfragen an die Datenbank gesendet werden können und so direkt in der Datenbank effizient abgearbeitet werden. Die Verlagerung der Funktionalität vom Client in die Datenbank bietet somit eine besonders leistungsfähige Möglich- keit Business-Logik vom Client zu extrahieren.

25 3 GBware und GBwareD

Abbildung 3.1: 3-Schicht Systemarchitektur der Business-Software GBware.

In einem geschützten Bereich der Datenbank wird die Konfiguration von GB- ware für den jeweiligen Kunden abgelegt. Mit Hilfe dieser Konfiguration wird festgelegt, welche Module für den Kunden aktiviert/deaktiviert werden sollen und welche Optionen der jeweiligen Module verfügbar sein sollen. • Der Application-Server enthält einen Teil der Business-Logik der Software GB- ware. Er ist vor allem für den Aufbau der Verbindung zur Datenbank sowie für das Übermitteln von Datenbankabfragen für lesende und schreibende Zugriffe zu- ständig. In der Realisierung in Delphi wird ein Connection-Objekt mit Benutzername und Passwort für die Datenbank generiert und bei erfolgreichem Zugang ein Data- Set-Provider (DCOM-Objekt, siehe auch Abschnitt 4.2.1) an den Client weiterge- reicht, über dessen Methoden Datenbankabfragen auch entfernt aufgerufen wer- den können. • Die Schnittstelle zum Nutzer von GBware bildet der in Delphi realisierte Client. Er enthält die Formulare der Interaktion mit dem System, die durch erweiterte Delphi-Klassen repräsentiert werden. Diese beinhalten zusätzlich Verarbeitungs- regeln für die Behandlung von Ein- und Ausgaben (z.B. maximale Wertebereiche) und Vorschriften zur Korrektheitsprüfung. Zusätzlich ist ein Teil der Business-Logik auf dem Client umgesetzt, da in der Realisierung in Delphi eine enge Kopplung zwischen Nutzerschnittstelle und Da- ten eine Auswirkung des von Delphi unterstützten Entwicklungsprozesses (Rapid- Application-Development, siehe auch Abschnitt 4.1) ist. An dieser Stelle wird vom Projekt TransBS sowohl der größte Handlungsbedarf als auch der größte Nutzen einer Verlagerung der Funktionalität und damit einer Verschlankung des Clients erwartet. Typisch für die Arbeitsweise mit dem Client ist die Anmeldung am Application- Server, die Anforderung eines Objekts zur Verbindung mit der Datenbank, die Bearbeitung einzelner Datensätze (wobei diese in der Datenbank für weitere Zu- griffe zur Vermeidung von Konflikten und Inkonsistenzen gesperrt werden) und das Aktualisieren (und Freigeben) der bearbeiteten Daten. Dabei wird die Art und Abfolge von genutzten Formularfeldern von den in der Datenbank abgelegten zu- standsbasierten Geschäftsprozessen gesteuert.

26 3.1 Analyse von GBware

Abbildung 3.2: Schematische Darstellung der Abarbeitung eines Workflows in GBware.

Ein wichtiges Transformationsziel ist der Zugriff auf das System GBware über das In- ternet, wobei Aspekte der Datensicherheit, Vertraulichkeit und Leistung berücksichtigt werden müssen. Dabei soll die (Web-)Nutzerschnittstelle in möglichst gleicher Weise wie im bisherigen Client verfügbar sein, um einen Wechsel vom bisherigen Delphi- Client möglichst einfach zu gestalten. Dies macht eine angepasste Verarbeitung der Ein- und Ausgaben notwendig (Fehlerkorrektur auf Server, bzw. auf Client über dynamische Web-Inhalte). Gleichzeitig soll eine Duplizierung der Funktionalität und damit eine dop- pelte Wartung der eigentlichen Business-Logik möglichst vermieden werden, um die Fehleranfälligkeit des Systems zu minimieren und damit sein bisheriges Marktpotential zu erhalten.

3.1.3 Abarbeitung der Geschäftsprozesse

In das System GBware ist eine Eigenimplementierung einer Workflow-Engine integriert, die zur Abarbeitung der spezifischen Geschäftsprozesse der jeweiligen Kunden verwen- det wird. Die Prozesse werden fest in der Datenbank konfiguriert und abgelegt und durch Nutzer-, Zeit- oder Datenbankereignisse ausgelöst und gesteuert. Durch die Konfigurati- on der Geschäftsprozesse in der Datenbank des Kunden können Feinabstimmungen oder

27 3 GBware und GBwareD

Tabelle 3.1: Konfiguration von Betriebssystem und Datenbankserver für GBware.

Betriebssystem Datenbankversion Windows NT4 SP6 Oracle 8i Windows 2000, XP, 2003 (Server) Oracle 8i, Oracle 10g Windows Vista, Windows 7 Oracle 10g SuSe Linux Enterprise Server Oracle 10g auch umfangreichere Änderungen der Geschäftsprozesse direkt beim Kunden realisiert werden, ohne dass der Programmcode von GBware für den Kunden angepasst werden muss.

Durch die Workflows werden Geschäftsobjekte verarbeitet, an die ihr jeweiliger Zustand oder Status im Prozess gekoppelt ist. Durch eine Bearbeitung eines Prozessschritts kann der Zustand entsprechend der Spezifikation des Workflows geändert werden. In Abbil- dung 3.2 ist eine schematische Darstellung der Abarbeitung eines Workflows in GBware als Flussdiagramm abgebildet. Der Workflow wird durch ein Ereignis aus der Nutzer- schnittstelle ausgelöst (z. B.„neues Angebot erstellen“). Im ersten Schritt (Prüfroutinen eines Statusübergangs) wird überprüft, ob der Übergang (kein Zustand → Aufruf des Workflows) für den Nutzer in der jeweiligen Domäne erlaubt ist. Wird die Prüfung er- folgreich abgeschlossen, kann der erste hinterlegte Prozessschritt (E-Mails erzeugen) ausgeführt werden. In jedem Schritt kann der Statusübergang an weitere Aktionen des Nutzers gekoppelt sein. In der Abbildung wird die E-Mailerzeugung durch Schablonen nur im dem Fall ausgeführt, wenn der Nutzer dies wünscht. Je nach ausgewählter Akti- on werden nun die jeweiligen Anweisungen (Statements) des Prozessschritts ausgeführt, die in Abhängigkeit von der Eingabe zu einem neuen Status der Geschäftsobjekte füh- ren (z. B. Wechsel in den Status E-Mails gesendet oder E-Mails senden verschoben). An jeden Prozessschritt können weitere Schritte angefügt werden (Rekursionen vorhan- den). Diese weiteren Schritte können ihrerseits weitere Anweisungen ausführen oder auch neue Aktionen auslösen, die die Geschäftsobjekte auch anderen Nutzern zur Abar- beitung vorlegen.

Alle Statusübergänge im Geschäftsprozess können mit Prüfroutinen versehen werden, die Vorbedingungen für den Übergang in einen nächsten Zustand definieren. Diese wer- den zum Teil vom Nutzer selbst spezifiziert, können aber auch durch den Gesetzgeber vorgegeben sein.

3.1.4 Ablaufumgebungen

Das System GBware ist eine reine Windows-Anwendung und wird für den Einsatz in den Betriebssystemen Windows NT/2000/XP/Vista und Windows 7 entwickelt. Es wird hauptsächlich in der Programmiersprache Delphi und mit der zugehörigen Borland Del- phi 7 Entwicklungsumgebung implementiert. Als Datenbank nutzt GBware Oracle ab Version 8i.

28 3.2 Erstellung eines Anforderungskatalogs an GBwareD

Die Installation von GBware ist in drei verschiedenen Installationsvarianten möglich.

1. Stand-Alone: In dieser einfachsten Variante werden Datenbank, Application-Ser- ver und Client auf einem einzigen Rechner installiert. 2. Klassisch: Bei der klassischen Variante werden Datenbank und Application-Ser- ver auf einem zentralen Rechner installiert und bilden ein sogenanntes Backend. Der Client befindet sich auf mehreren im Netz verfügbaren Rechnern, die mit dem Backend kommunizieren. Zusätzlich kann ein Client auch auf dem Backend- Rechner selbst installiert sein. 3. Professionell: Zusätzlich zur klassischen Variante sind hier Client, Application- Server und Datenbankserver physikalisch voneinander getrennt. In dieser Variante kann die beste Skalierbarkeit von GBware erreicht werden.

Tabelle 3.1 zeigt die möglichen Kombinationen aus Betriebssystem und Datenbank- versionen für den Rechner auf die die Datenbank installiert wird. Die Möglichkeit der Installation auf einem Linux-Server ist nur in der professionellen Installationsvariante möglich, da sowohl der Application-Server als auch der Client ein Windows-Betriebs- system benötigen.

3.2 Erstellung eines Anforderungskatalogs an GBwareD

3.2.1 Kundenspezifische Anforderungen

Von Seiten der Nutzer von GBware werden verschiedene Anforderungen bzgl. einer verteilten Ausführung und einer modularen Struktur gestellt. Dabei spielt bei klein- und mittelständischen Kunden nicht nur der zu erwartende Nutzen einer Reorganisation von GBware, sondern auch die zu erwartenden finanziellen Auswirkungen auf bestehen- de Lizenzverträge eine große Rolle, was schon bei der Planung berücksichtigt werden muss.

Im Einzelnen werden von Kundenseite folgende Anforderungen an GBwareD gestellt:

• Zugriff auf das System über eine Webschnittstelle. Vielen Kunden ist eine ört- lich nicht begrenzte Nutzung von GBware wichtig. Die Bereitstellung eines inter- netfähigen Client-Rechners kann meist ohne große Probleme gewährleistet wer- den. Auch wenn die Installation des GBware-Delphi-Clients sehr einfach gehal- ten ist, kann vor allem für Neukunden der Zugang über einen Browser intuitiver erscheinen. Verbunden mit der örtlich unabhängigen Nutzung ist häufig auch die zentrale Verwaltung von Dokumenten. Dabei sind Aspekte einer sicheren Übertra- gung, möglichst geringe Antwortzeiten und eine gleichartige Nutzerschnittstelle zu berücksichtigen. Zusätzlich bestehen Überlegungen der Anbindung von Thin- Clients.

29 3 GBware und GBwareD

• Partizipation der Kunden der GBware-Nutzer am System. Im Zusammenhang mit dem Zugriff auf das System über das Internet wird von den Nutzern auch eine Partizipation ihrer Kunden ins System gewünscht, um den Aufwand von manu- ellen Eingaben von Daten ins System und eventuelle Fehler zu minimieren. Für die Kunden der Nutzer ist jedoch eine Installation eines GBware-Clients keine sinnvolle Alternative, so dass für diesen Zweck nur die Bereitstellung einer Web- schnittstelle sinnvoll ist. • Lastverteilung auf mehrere Application-Server. Zur effizienteren Abarbeitung von Anfragen und zur Erhöhung der Ausfallsicherheit des Systems ist eine Last- verteilung auf mehrere Application-Server erwünscht. Wie auch bei den Anforde- rungen des Webzugriffs sollen sich dabei die Response-Zeiten nicht verschlech- tern (diese ist im Moment vor allem durch die Datenbankzugriffe bedingt). • Erweiterte Parametrisierung der Geschäftsprozesse. Da jedes Kundenunter- nehmen über eigene individuelle Geschäftsprozesse verfügt, die die eigentliche Stärke des Unternehmens ausmachen, ist eine abgestimmte Parametrisierung der Workflows eine Hauptforderung aus der Praxis. Neben der Flexibilität für den Kunden ergeben sich dadurch erhebliche Einsparpotentiale für Consulting und Anforderungsentwicklung. Dazu gehört auch eine Integration verschiedener Kom- munikationsmedien in den Workflow, wie z. B. E-Mail, Fax oder SMS, sowohl für die Erstellung von Berichten als auch für das Auslösen von Ereignissen im Ge- schäftsprozess. Die vorrangige Anforderung der Kunden an das bisherige GBware ist die Anbindung an das Internet in Form einer Webschnittstelle. Die Schnittstelle sollte generisch gehalten sein, so dass unterschiedliche Anforderungen verschiedener Kunden einfach integriert werden können. Auch für die Sicherung des Marktpotentials von GBware in naher Zu- kunft wird diese Anforderung entscheidend sein.

3.2.2 Anforderungen an GBwareD

Auf Grundlage der Anforderungen der GBware Kunden können die Anforderungen für ein modulares (und damit wartbares), verteiltes GBwareD abgeleitet werden.

• Trennung von Nutzerschnittstelle und Business-Logik, Verschlankung des Clients. Eine wesentliche Grundlage für die Integration einer Webschnittstelle in GBware ist die Trennung von Nutzerschnittstelle und Business-Logik. Die Kapse- lung ist notwendig, um Programmlogik, die sich bisher im Delphi-Client befand, auch für das Web-Backend bereitzustellen und dabei eine Duplizierung, und da- mit eine doppelte Pflege des Codes, zu vermeiden. Da in Web-Clients kaum Logik integriert werden kann oder soll (bestimmte Kunden verzichten aus Sicherheits- gründen auf Client-Seite auf dynamische Webinhalte), muss die Business-Logik aus dem bisherigen Delphi-Client in den Application-Server oder als Datenbank- funktionalität in die Datenbank verschoben werden. Dabei bleibt abzuwägen, in wie weit auch Präsentationslogik (bspw. die Über- prüfung einer Eingabe eines Formularfelds) verschoben werden sollte, da jede

30 3.2 Erstellung eines Anforderungskatalogs an GBwareD

Kommunikation mit Application-Server oder Datenbank wesentlich längere Ant- wortzeiten als die bisherige Client-seitige Auswertung mit sich bringt. Zusätzlich verfügen Webschnittstellen (v. a. wenn auf Client-Seite auf dynamische Webin- halte verzichtet werden soll) über einen geringeren Funktionsumfang als übliche Nutzerschnittstellen von lokalen Programmen. Beispielsweise können im Web nur schwer modale Dialoge (ein modaler Dialog im Vordergrund lässt keinen Zugriff auf die Hauptfenster der Anwendung zu, so lange er angezeigt wird) nachgebil- det werden. Das kann bedeuten, dass im Delphi- und im Web-Client bestimmte Interaktionen mit dem System unterschiedlich gestaltet werden müssen, um die Korrektheit der Abläufe sicher zu stellen. • Modularisierung von GBware, Bildung von Einzelkomponenten. Das System GBware wird als monolithische Anwendung ausgeliefert. Dies bedeutet, dass an jeden Kunden alle aktuell verfügbaren Module ausgeliefert werden, jedoch nur die Module, die der Kunde nutzen möchte, in einem geschützten Bereich der Da- tenbank frei geschaltet werden. Besonders durch die Vielzahl unterschiedlicher Formularmasken der Module steigt die Größe der ausgelieferten Software stetig an. Es wird daher die Realisierung von Modulen als dynamische Bibliotheken ver- folgt. Dies hat einerseits den Vorteil, dass nur die Module zum Kunden geliefert werden müssen, die er tatsächlich geordert hat. Andererseits wird dadurch auch die Kapselung der Module durch einen standardisierten und schnittstellenkonfor- men Zugriff verstärkt, was im Moment nur durch Programmierrichtlinien gewähr- leistet werden kann. Von der Verwendung dynamischer Bibliotheken wird daher auch eine Steigerung der Wartbarkeit und der Erweiterbarkeit erwartet. • Modularisierung von GBware, Wiederverwendung bestehenden Programm- codes. Für die Verlagerung von Business-Logik für einen gemeinsamen Zugriff der Delphi- und Web-Clients und die Bildung dynamischer Bibliotheken muss nicht nur der Programmcode der betroffenen Schnittstellen, sondern auch der Co- de der verschobenen Business-Logik angepasst werden. Soll bspw. ASP.NET als Lösung für den Application-Server eingesetzt werden, so müssen bisher verwen- dete Delphi Bibliotheken durch .NET-Bibliotheken ersetzt werden, da verschie- dene bisher verwendeten Bibliotheken nicht im ASP Umfeld unterstützt werden. Die Funktionalität ist dabei zwar im Allgemeinen vorhanden, jedoch können sich einzelne Aufrufe auch bei gleicher Benennung im Detail unterscheiden, so dass spezifische Anpassungen im Programmcode vorgenommen werden müssen. • Erweiterte Rechteverwaltung. Die Integration eines Web-Clients und die Par- tizipation von Kunden der GBware-Nutzer erfordern Änderungen der bisherigen Rechteverwaltung. Aktuell werden bei der Nutzung eines Geschäftsobjekts (z. B. Adresse, Rechnung) die betreffenden Datensätze oder auch ganze Tabellen für weitere Zugriffe gesperrt, um Inkonsistenzen der Daten zu vermeiden (andern- falls könnte bspw. durch konkurrierenden Zugriff auf einen Datensatz eine falsche Rechnung o.ä. entstehen). Eine Spezialisierung der Nutzung auf Lese- und Schreibrechte der jeweiligen Nut- zer ist daher zweckmäßig, da bspw. für Nutzer, welche nur lesenden Zugriff (Re-

31 3 GBware und GBwareD

porting) besitzen, keine Blockierung der Datensätze bis zur einer Empfangsbestä- tigung notwendig ist, sondern nur ein aktueller Stand konsistenter Daten ausgege- ben werden muss. Bisher existiert noch keine Möglichkeit, ausgewählten Nutzern nur einen Teil der Daten eines Datensatzes zu präsentieren. Dieses Problem soll durch individuelle Datenbanksichten für Nutzergruppen gelöst werden. Da die Rechteverwaltung in jedes Modul integriert werden muss, stellt sie ein Bei- spiel eines querschnittlichen Belangs (Cross-Cutting Concern) dar, das nicht mit herkömmlichen Ansätzen modularisiert werden kann. Daher soll zunächst eine prototypische Einführung in ausgewählten Modulen erfolgen. • Anbindung weiterer Medien an das System. Die von Kunden gewünschten Kommunikationsmedien (Fax, SMS, E-Mail, Office-Anbindung, andere Informa- tionssysteme z. B. ITIL Ticket Service, etc.) sollen in bestehende Workflows inte- griert werden können, um neue Möglichkeiten des Reporting bzw. des Auslösens von Workflow-Ereignissen zu eröffnen. • Erweiterung der Workflow-Engine. Die beschriebenen Reorganisationen haben direkte Auswirkungen auf die verwendete Workflow-Engine. Zum Einen müs- sen dabei die Aufrufe der bisher verwendeten Routinen angepasst werden, um die Routinen in den neu erzeugten Einzelkomponenten zu erreichen. Zum Ande- ren setzt auch die Anbindung weiterer Medien in das System neue Parameter der Abarbeitung der Prozesse voraus, die in die Workflow-Engine integriert werden müssen. • Hardware- und Betriebssystemunabhängigkeit. Für den flexiblen Einsatz von GBware in die gewohnte Hard- und Softwareumgebung des Kunden, sollte GB- ware möglichst unabhängig von spezifischer Hard- oder Software sein. Durch die bisherige Nutzung von Borland-Delphi als Umgebung für den Client und den Ap- plication-Server ist jedoch eine Bindung an Windows-Betriebssysteme vorgege- ben. Da ein Wechsel der Umgebung (z. B. auf JavaEE) umfangreiche Änderungen und Tests der jeweiligen Module mit sich bringt, wird ein schrittweises Verfahren zur Integration und Migration der Module verfolgt. Zur Anbindung bzw. Integration von vorhandener Software beim Nutzer (bspw. SAP, Navision, KHK-Fibu, Exact) sind eine Vielzahl von Schnittstellen vorgese- hen. Da diese Schnittstellen häufig spezifisch für die jeweilige Software beschrie- ben sind, soll die Pflege der bisher realisierten Schnittstellen fortgesetzt werden und Schnittstellen zu neuen Softwareprodukten entsprechend der Kundenanforde- rungen hinzugefügt werden. • Unabhängigkeit vom Datenbankanbieter. Eine weitere denkbare Anforderung an GBwareD ist die Unabhängigkeit vom Datenbankanbieter. Mit der Unterstüt- zung verschiedener möglicher Datenbanken könnte eine für den Kunden sowohl leistungsgerechte als auch dem jeweiligen Kostenrahmen entsprechende Bereit- stellung von GBware erreicht werden. Dieser Anforderung entgegen steht die Forderung aller Kunden nach möglichst maximaler Leistung bei der Abarbeitung der Geschäftsprozesse auch für viele Nutzer, die z. B. durch die Verlagerung von Funktionalität in die Datenbank erreicht wird und damit datenbankspezifische Op- timierungen möglich macht.

32 3.2 Erstellung eines Anforderungskatalogs an GBwareD

Abbildung 3.3: Konzept der Systemarchitektur der verteilten Business-Software GBwa- reD.

Ein erster Schritt in Richtung der Unabhängigkeit vom Datenbankanbieter ist die Unterstützung von Java als Skriptsprache für verschiedene Datenbanken. Die Überführung der bisherigen proprietären Sprache PL/SQL (von Oracle) in Java- Skripte zum Einsatz in verschiedenen Datenbanksystemen soll daher vor allem im Hinblick auf ihre mögliche Leistungsfähigkeit evaluiert werden.

Durch die Bestandsanalyse von GBware stellten sich vor allem die Aspekte Modularität und Verteiltheit als wichtigste Anforderungen an GBwareD heraus. Dabei hat zunächst eine möglichst optimale Trennung zwischen Business-Logik und Nutzerschnittstelle für einen webbasierten Zugriff auf GBware Priorität. Darüber hinaus ist die Bildung von Einzelkomponenten aus bestehenden Modulen eine zentrale Anforderung, um in einem weiteren Schritt explizite Verteiltheit (z. B. mehrere Application-Server) zu erreichen.

3.2.3 Hard- und Softwarekonfiguration von GBwareD

Durch die Anforderungen der Nutzer von GBware und den daraus resultierenden tech- nischen Anforderungen leitet sich eine mögliche Systemarchitektur eines verteilten GB- ware ab. Abbildung 3.3 zeigt eine Variante der 3-Schicht-Architektur von GBwareD. Die wesentliche Veränderung gegenüber der Architektur von GBware (Abbildung 3.1) ist die Verlagerung der Business-Logik, angedeutet durch die Quadrate (Module) im Ap- plication-Server und in der Datenbank. Dies beschreibt die Trennung von Nutzerschnitt- stelle und Logik und somit die Verschlankung des bisherigen Delphi-Clients. Besonders leistungskritische Module können dabei als Datenbankfunktionen (Java-Skripte, die in der Datenbank ausgeführt werden) realisiert werden. Beide Clients enthalten somit nur noch einfache Präsentationslogik (z. B. die Überprüfung von Eingabeformaten). Zusätz- lich zum Delphi-Client soll ein neuer Web-Client zur Verfügung stehen, der über einen identischen Funktionalitätsumfang verfügen soll. Der Web-Client soll darüber hinaus bestimmte Funktionalitäten auch über einen Mobile-Client für Smartphones anbieten. Falls Kunden aus Sicherheitsgründen keine dynamischen Web-Inhalte (z. B. eine Deak- tivierung von Java-Skript im Browser) wünschen, muss auch die Präsentationslogik auf den Application-Server verlagert werden.

33 3 GBware und GBwareD

Die Kommunikation zwischen Clients und Application-Server soll über DCOM (Del- phi-Client) bzw. HTTP(S) (Web-Client) erfolgen. Im Application-Server müssen dafür Schnittstellen realisiert werden, die die bisherige Business-Logik kapseln. In einer wei- terentwickelten Architektur soll die Möglichkeit der ausschließlichen Kommunikation über HTTP(S) auf XML-Basis evaluiert werden, um verschiedene Schnittstellen mit gleicher Funktionalität im Application-Server zu vermeiden.

Der Application-Server selbst bleibt zunächst als Delphi-Server bestehen, um die vor- handene Business-Logik weiter verwenden zu können und eine schrittweise Trennung von Nutzerschnittstelle und Business-Logik zu erlauben. Perspektivisch soll jedoch die Nutzung eines JavaEE-Servers Grundlage für die Business-Logik bilden, um die ge- wünschte Unabhängigkeit vom Betriebssystem zu erreichen. In diesem Rahmen sollen auch die Möglichkeiten für mehrere Application-Server evaluiert werden.

3.3 Vorbereitungs- und Anpassungsarbeiten für GBware

3.3.1 Modularisierung von GBware

Möglichkeiten der Modularisierung in Delphi

Zur Bildung von Modulen stellt die Delphi Sprachspezifikation Packages und Libraries zur Verfügung (siehe auch Abbildung 10.1 zum Aufbau einer Applikation in Delphi, S. 138). Ähnlich dem Package-Konzept in Java wird über das Schlüsselwort package ein neuer Namensraum definiert, in dem Programmteile (Units) abgelegt werden. Die in Packages enthaltenen Programmteile können über die Deklaration verschiedener Sicht- barkeiten im Modul gekapselt oder explizit für die Verwendung als Schnittstelle des Moduls gekennzeichnet werden. Packages stellen Modularität nur in Hinblick auf den Programmcode her, da sie durch den Compiler statisch in die ausführbare Datei einge- fügt werden.

Durch die Deklaration von Libraries über das Schlüsselwort library können jedoch auch Module erzeugt werden, die erst zur Laufzeit vom Hauptprogramm genutzt wer- den. Dies ermöglicht zum Einen den Austausch von Libraries, ohne dass die Software komplett neu kompiliert werden muss. Zum Anderen können Libraries als Dynamic Link Libraries (DLL) erst zur Laufzeit der Software in den Speicher geladen bzw. dar- aus entfernt werden, je nachdem ob das Modul verwendet wird. Mit dem Einsatz von Dynamic Link Libraries kann somit sowohl die Kapselung des Programmcodes der Mo- dule als auch die Bereitstellung eines skalierbaren Softwareprodukts durch spezifische Aktivierung und Deaktivierung verwendeter Module erreicht werden.

34 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware

Darüber hinaus stehen für Delphi auch verschiedene Plugin-Frameworks (z. B. TMS1, DPF2) zur Verfügung, die DLLs über eine fest definierte Schnittstelle auch zur Laufzeit zur Software hinzufügen bzw. entfernen. Sie bieten zum Teil auch Möglichkeiten der Verifizierung der Plugins, damit kein „fremder“ Programmcode durch einfaches Umset- zen der spezifizierten Schnittstelle zum System hinzugefügt werden kann. Im Rahmen der Modularisierung von GBware wurde als Machbarkeitsstudie das Mo- dul „Projektverwaltung“ manuell umgestellt, um wesentliche Schritte einer Modulari- sierung zu ermitteln und Möglichkeiten der Unterstützung durch das Transformations- system zu evaluieren. Dabei wurde deutlich, dass ein endgültiger Abschluss der Modu- larisierung oft nicht möglich ist, da neue Anforderungen an Module neue Umstrukturie- rungen erfordern können.

Trennung von Nutzerschnittstelle und Business-Logik

Die Trennung von Nutzerschnittstelle und Business-Logik ist für die Restrukturierung von GBware ein vordringliches Ziel, um Business-Logik aus dem Client zu extrahieren. Bei einer Studie im Modul „Projektverwaltung“ zeigte sich, dass eine manuelle Tren- nung des Programmcodes häufig die Frage aufwirft, welcher Programmcode Business- Logik entspricht, bzw. welcher Programmcode verlagert werden soll oder kann. Da der Begriff Business-Logik nur unscharf definiert ist, kann eine Antwort auf diese Frage nur im Kontext der Zielarchitektur von GBwareD beantwortet werden. Da ei- ne Web-Schnittstelle wesentlicher Bestandteil der Architektur ist, sind eher strikte De- finitionen, die einen möglichst großen Teil der Logik als Business-Logik klassifizie- ren, sinnvoll. Chad Z. Hower3 definiert Business-Logik bspw. als die Funktionalität, die über die SQL-Operationen Create, Retrieve, Update oder Delete hinausgeht oder diese Operationen auf mehrere Tabellen anwendet (als Ausnahme lässt er joins auf Tabel- len zu). Zusätzlich postuliert er, dass Business-Logik in einer 3-Schicht-Architektur zu 100 % in der Applikationsschicht angelegt werden sollte und dass Präsentationslogik (z. B. Überprüfung von Eingabeformaten), wenn notwendig, sowohl im Client als auch in der Applikationsschicht enthalten sein sollte, sodass beim Hinzufügen neuer Clients alle Mechanismen zur Sicherstellung korrekter Eingabedaten schon vorhanden sind und nicht notwendigerweise per Definition auf allen Clients realisiert werden müssen. Durch die Verlagerung aller rechenintensiven Operationen in die Applikationsschicht wird die größtmögliche Skalierbarkeit eines Systems erreicht, da das Ergänzen neuer Applikati- onsserver wesentlich kostengünstiger realisiert werden kann als der Zukauf von Daten- bank-Servern. Für GBware stellte sich auf Basis bisheriger Erfahrungen und nach der Evaluation des Moduls Projektverwaltung die Verschiebung leistungskritischer Funktionalitäten in die Datenbank als sinnvoll heraus, da hinreichend Leistung mit den verwendeten Daten- bank-Servern bereitsteht. 1TMS Plugin Framework, http://www.tmssoftware.com/site/tpf.asp 2Delphi Plugin Framework, Open Source, http://sourceforge.net/projects/rd-dpf/ 3http://www.codeproject.com/KB/architecture/DudeWheresMyBusinessLogic. aspx

35 3 GBware und GBwareD

Abbildung 3.4: Beispiel einer TTable mit generierten Adressdaten in einer Nutzer- schnittstelle.

Als weiteres Problem der Trennung stellte sich die z. T. enge Verknüpfung von Frame- work-Komponenten der Nutzerschnittstelle mit der Business-Logik dar. Dieses Problem soll anhand einer Tabellenkomponente der Borland Database Engine (BDE) beschrie- ben werden. TTable (Abbildung 3.4) bietet einen direkten Zugriff auf eine Tabelle einer Datenbank, die über die BDE angebunden werden kann (z. B. Oracle, MS SQL Server, etc.). Der Zugriff auf die Tabelle wird durch die Übergabe einer sog. DataSour- ce ermöglicht. Die Komponente stellt bei entsprechender Konfiguration die Möglichkeit zur Verfügung, Datensätze zu verändern, hinzuzufügen oder zu löschen. Darüber hin- aus aktualisiert TTable die angezeigten Datensätze automatisch, wenn sich die Tabelle oder auch einzelne Einträge von Datensätzen in der Datenbank ändert. Mit der Kom- ponente TTable kann innerhalb kurzer Zeit eine komplexe Nutzerschnittstelle erzeugt werden, die dem Nutzer ein breites Spektrum der Bearbeitung von Daten gestattet. Al- lerdings enthält die Komponente selbst die Funktionalitäten zum Ändern, Hinzufügen und Löschen, so dass die zugehörige Business-Logik nicht unmittelbar von ihrer Dar- stellung in der Nutzerschnittstelle gelöst werden kann. Soll bspw. eine Tabelle mit ent- sprechender Funktionalität im Web-Client angeboten werden, so müssen die Aktionen Ändern, Hinzufügen und Löschen manuell für den Client implementiert werden, da sie fest im Delphi-Client integriert sind. Werden nun durch neue Anforderungen Änderun- gen an den Aktionen notwendig (z. B. bei Anlegen eines neuen Datensatzes wird eine bestimmte Person informiert), so müssen diese Änderungen sowohl im Web-Client als auch im Delphi-Client separat realisiert und getestet werden. Ist diese Duplizierung von Funktionalität in erheblichem Maße notwendig, so steigt die Wahrscheinlichkeit, dass Inkonsistenzen zwischen den Clients auftreten oder dass entdeckte Fehler nur an einer Stelle korrigiert werden. Andererseits kann eine Ablösung von TTable nur manuell durch Nutzung einer Tabellenkomponente erfolgen, die nur für die Nutzerschnittstelle geeignet ist, da TTable durch individuellen Programmcode in die jeweiligen Formulare eingebettet ist. Wird diese Komponente sehr häufig verwendet, stellt dies einen großen Zeit- und Kostenfaktor dar, insbesondere da TTable nur ein Beispiel aus eine Reihe von Framework-Komponenten ist, die implizit Business-Logik enthalten.

Weitere Konzepte, Lösungsansätze und Problemstellungen der Trennung von Nutzer- schnittstelle und Business-Logik, sowie der Transformation der Nutzerschnittstelle wer- den in den Abschnitten 7.5 und 10.2 vorgestellt.

36 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware

3.3.2 Entwurf der Schnittstellen zwischen Modulen

GBware stellt auf Basis von Kernmodulen unterschiedliche Komponenten zur Verfü- gung, die individuelle Anforderungen des Kunden lösen. Geschäftsprozesse enthalten in der Regel abstrakt betrachtet analoge Prozessschritte (z. B. Angebot → Auftrag → ... → Lieferung/Rechnung → Buchung), jedoch unterscheiden sich die Geschäftspro- zesse im Detail häufig sehr stark und es werden z. T. andere Abläufe verwendet, die nicht dem abstrakten Schema entsprechen. Die individuellen Anpassungen erfordern flexible Lösungen bei der Realisierung der Schnittstellen zwischen den Modulen, über die die Module auf vielfältige Weise mit individuellen Vor- und Nachbedingungen zusammen arbeiten können.

Ein Beispiel für die Notwendigkeit flexibler Schnittstellen ist die Zusammenarbeit der Module „Projekt“ und „Auftrag“ im Rahmen der Immobilienverwaltung von GBware. Das Modul „Projekt“ dient hier zur Verwaltung von Aktivitäten, die sich auf bestimmte Immobilien beziehen, wie bspw. Mieternachrichten, Sanierungen oder Schadensmel- dungen. Im Modul „Auftrag“ werden Angebote, Aufträge und Rechnungen kaufmän- nisch bearbeitet. In einem praktischen Anwendungsfall kann das Modul „Projekt“ das Modul „Auftrag“ steuern, wenn z. B. aufgrund einer Schadensmeldung (Modul „Pro- jekt“) ein Auftrag für die Reparatur (Modul „Auftrag“) erstellt und abgearbeitet wird. In einem weiteren Anwendungsfall steuert das Modul „Auftrag“ das Modul „Projekt“, wenn z. B. auf Basis verschiedener Angebote (Modul „Auftrag“) ein neues Sanierungs- projekt (Modul „Projekt“) erstellt wird.

Eine zentrale Fragestellung bei der Gestaltung von Schnittstellen ist daher, wie die Ser- vices eines Moduls entworfen werden können, so dass sie in möglichst vielen (auch zukünftig möglichen) Anwendungsfällen verwendet werden können, ohne ihre Funktio- nalität anpassen zu müssen. Ist die Flexibilität der Schnittstellen gegeben, kann über die Abbildung der Geschäftsprozesse in Workflows die Abstimmung der Konfigurationen der Module erfolgen.

3.3.3 Extraktion der Workflow-Komponenten in GBware

Workflows zur Steuerung und Überwachung der Geschäftsprozesse werden in GBware in der Datenbank mit folgenden Bestandteilen abgelegt.

• Im Zentrum des Workflows stehen die Geschäftsobjekte (z. B. Adresse, Doku- ment, Projekt, Lager), die die Datenbasis des Systems bilden. • Jedes Geschäftsobjekt wird im Workflow mit einem Status/Zustand (z. B. ange- legt, gebucht, weitergeleitet, gelöscht) versehen, der den aktuellen Zustand des Geschäftsobjekts im Workflow abbildet. • Die möglichen Statusübergänge werden im Workflow als Transitionen bezeich- net. Fasst man den Workflow formal als endlichen Automaten auf, so entsprechen die Transitionen den vorhandenen Kanten des Zustandsgraphen.

37 3 GBware und GBwareD

Abbildung 3.5: Schematische Darstellung der Modellierung von Geschäftsprozessen in GBware als zustandsbasierte Workflows mit assoziierten Aktionen.

• Jede Transition wird mit verschiedenen Aktionen versehen, die den Statuswechsel des Geschäftsobjekts in der Datenbank anstoßen. Es können Vor- und Nachbedin- gungen des Zustandswechsels geprüft werden, die im Fehlerfall eine Rücksetzung bereits abgearbeiteter Aktionen auslösen. Darüber hinaus können Nachrichten (in- tern oder extern) versendet und Folgeprozesse sowie neue Workflows angestoßen werden.

Abbildung 3.5 zeigt eine schematische Darstellung eines Workflows, wie er in GBwa- re modelliert wird. Die Geschäftsobjekte werden dabei mit den Zuständen (Status) des Workflows assoziiert. Die Übergänge zwischen den Zuständen sind mit Aktionen ver- knüpft, die bspw. Funktionalitäten in der Datenbank auslösen können (Aktion 1, Akti- on 2) oder als Auslöser für die Aktivierung eines neuen Workflows verwendet werden können. Auslöser eines Workflows können darüber hinaus auch externe Ereignisse (Ein- gang einer speziellen E-Mail im System) oder der Nutzer sein. Des Weiteren können Workflows auch zeitgesteuert ausgelöst werden, bzw. auch zeitgesteuert Zustandsüber- gänge auslösen (Eskalation).

Die Abarbeitung der in dieser Weise modellierten Workflows erfolgt über eine in der Berndt & Brungs Software GmbH realisierte Workflow-Engine. Die Engine nutzt ver- schiedene Datenbanktabellen, die Status, Transitionen und Aktionen enthält, und führt diese entsprechend der Konfiguration aus.

Betrachtet man die ausgeführten Aktionen näher, so sind diese in GBware häufig als Stored Procedures als Funktionalität in der Datenbank in der Sprache PL/SQL, die nur von Oracle Datenbanken unterstützt wird, realisiert. Die Verschiebung von Funktiona- lität zur Datenbank wurde vor allem aufgrund der hervorragenden Leistungsfähigkeit und der damit geringen Antwortzeiten für den Nutzer auch für große Datenmengen um- gesetzt. Um erste Schritte der Extraktion des Workflows zu gehen und damit dessen Unabhängigkeit vom jeweiligen Datenbankanbieter zu erreichen, wurde mit der Trans- formation von PL/SQL nach Java begonnen. Oracle unterstützt in den neueren Versionen

38 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware

Abbildung 3.6: Nutzerschnittstelle des exemplarischen GBware mit reduzierter Funk- tionalität. auch Java als Datenbankskriptsprache, womit die Leistungsanforderungen der Nutzer aufrecht erhalten werden können. Gleichzeitig bieten auch andere Datenbankanbieter (z. B. IBM/DB2) die Möglichkeit, Stored Procedures als Java-Skripte in der Datenbank auszuführen.

Die Überführung von PL/SQL nach Java dauert noch an, da eine automatische und kor- rektheitserhaltende Transformation, auch wegen der unterschiedlich mächtigen Schitt- stellen zum jeweiligen Framework, für die einmalige Nutzung nicht realisierbar ist. Es zeigt sich, dass der Einsatz von Java auch dem Produktiveinsatz gewachsen ist und die Flexibilität und Modularität der Funktionalitäten in der Datenbank erhält und teilweise ausbaut.

3.3.4 Testszenarien

Von der Berndt & Brungs Software GmbH wurde allen Projektbeteiligten ein exem- plarisches z. T. schon modularisiertes und in seiner Funktionalität auf das Wesentliche beschränktes Testprojekt zur Verfügung gestellt, um Analysen und realisierte Transfor- mationen beispielhaft durchzuführen und ein gemeinsames Verständnis von Modularität und Verteiltheit für GBwareD zu erlangen.

In Abbildung 3.6 ist die Nutzerschnittstelle des Testprojekts dargestellt. Im (Delphi- )Client sind die Module Adresse (Address), Artikel (Product) und Verkauf (Process) enthalten. Die Architektur von GBwareD ist dabei über die Server-Module (rechts un- ten) abgebildet. Für jedes Modul, das im Client verfügbar ist, steht ein prototypischer Server zur Verfügung, die über den zentralen Server Main erreicht werden können. Die Verbindung der Server zur Datenbank ist über eine XML-Schnittstelle modelliert, um keinen zusätzlichen Datenbankserver einrichten zu müssen.

Auf Grundlage des Testprojekts konnten erste Ansätze zur Bildung von Modularität und Verteiltheit manuell durchgeführt werden und auch deren mögliche Automatisierbar-

39 3 GBware und GBwareD

Abbildung 3.7: ER-Modell der Abbildung von Geschäftsprozessen in einer relationalen Datenbank. keit evaluiert werden. Beispielsweise konnten so erste Analysen von Delphi-Programm- code mit dem Werkzeug TRANSFORMR (Abschnitt 10.1) durchgeführt und Möglich- keiten der schrittweisen Umstellung einer Legacy-Delphi-Server Anwendung auf einen JavaEE-Server über eine CORBA-Schnittstelle evaluiert werden (Abschnitt 8.4).

Als weiteres Szenario zum Test und zur Evaluierung der Extraktion und Überführung der Workflow-Komponenten von GBware wurde ein klassischer Geschäftsprozess definiert, der auch Randbedingungen (z. B. Verhalten im Fehlerfall) abdeckt. Der Vorgang enthält folgende Schritte:

1. Anforderungsdefinition (z. B. Meilensteinplanung) im Modul Projekt; 2. Übernahme externer Dokumente (Modul Projekt) und Zuordnung beteiligter Adressen mit Rollen (Lieferant, Kunde) im Modul Adresse; 3. Parallel dazu Angebotsverfolgung und Angebotsphase (Modul Vorgang) und Be- stellphase (Modul Einkauf); 4. Auftragsbearbeitung (Modul Vorgang); 5. Auftragsabwicklung (Module Projekt, Zeiterfassung, Personal-Disposition); 6. Fakturierung und Kontrolle des Zahlwesens (Module Zahlung, Offene-Posten- Buchhaltung, Mahnungen).

Während der Durchführung kann der Geschäftsprozess mit dem Modul Auswertungen überwacht und es können verschiedenste Daten über das Laufzeitverhalten des Prozesses gesammelt werden.

3.3.5 Kundenspezifische Konfigurationsmöglichkeiten

Basierend auf den Ergebnissen der Extraktion der Workflow-Komponenten (Ab- schnitt 3.3.3) wurden verschiedene Varianten der Modellierung von zustandsbasierten Prozessen untersucht. Dabei stand die Abbildung des Prozesses in ein relationales Da- tenbankmodell im Vordergrund, um Anwendungslogik zu realisieren, die in beliebigen Geschäftsprozessen verwendet werden kann.

40 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware

Zur Modellierung von Workflows als zustandsbasierte Geschäftsprozesse kann ein ER- Diagramm verwendet werden, aus dem direkt die zu erzeugenden Tabellen in der Da- tenbank abgeleitet werden können. Dazu werden alle Entitäten (dargestellt als Recht- ecke) und alle Relationen zwischen den Entitäten (dargestellt durch Rhomben) in Ta- bellen umgewandelt. Tabellen, die aus Relationen erzeugt wurden, verfügen dabei über einen Primärschlüssel, der sich aus den Primärschlüsseln der jeweiligen Entitäten (meist eindeutige Nummern) ergibt. Zwischen den Entitäten können Relationen verschiedener Kardinalität auftreten, die durch 1-1- (1 zu 1), 1-n- oder n-m-Beziehungen abgebildet werden. Betrachtet man beispielsweise die 1-n-Beziehung zwischen Status und Transi- tion, so kann ein Status beliebig viele (auch keine) Übergänge zu Folgezuständen besit- zen. Jeder Transition ist jedoch genau ein Ausgangszustand zugeordnet.

In Abbildung 3.7 ist die gewählte Modellierung dargestellt. Ein Geschäftsprozess wird somit als eine beliebige Menge von Status aufgefasst, die mit beliebig vielen Geschäfts- objekten verknüpft sind. Jeder Status verfügt über beliebig viele Transitionen zu einem Folgestatus. Jeder Transition können beliebig viele Aktionen zugeordnet werden, die während des Zustandswechsels abgearbeitet werden. Zusätzlich können Nachrichten bei Zustandsübergängen oder ausgeführten Aktivitäten an Nutzer innerhalb oder außerhalb des Systems versendet werden.

Die Abarbeitung eines Geschäftsprozesses erfolgt in einer von Berndt & Brungs Softwa- re GmbH realisierten Workflow-Engine. Bei der Durchführung eines Prozesses wird zu- nächst der jeweils aktuelle Zustand des Prozesses mit seinen verbundenen Geschäftsob- jekten eingelesen. Wird eine Transition angestoßen (über Nutzerinteraktion, zeitbasiert oder auch automatisch), so werden die für die Aktion notwendigen Eingabeparameter über Objekt-IDs in der Datenbank identifiziert und an die Aktion, die häufig als Daten- bankfunktion vorliegt, übergeben. Bei Durchführung der Aktion werden die assoziierten Geschäftsobjekte angepasst und die Ergebnisse in die Datenbank zurückgeschrieben.

Bei der Abarbeitung der Workflows muss die Sicherung der Datenkonsistenz und die Si- cherung des Prozessablaufs wesentlicher Bestandteil sein. Datenkonsistenz geht einher mit einer zeitweisen Sperre von Datensätzen, um bei sequentiellen Änderungen Inkon- sistenzen an Datenobjekten zu vermeiden. Eine solche „ununterbrechbare“ Folge von Änderungen wird häufig als Transaktion modelliert und durch unterschiedliche Soft- ware (Transaktionsmonitor) unterstützt. Zur Sicherung des Prozessablaufs kommen vor allem die Funktionalitäten des Datenbanksystems Oracle zum Einsatz. Mit ihrer Hilfe kann ein Transaktionsmanagement gestaltet werden, welches es möglich macht, Daten, die während eines Prozesse geändert werden, aufzuzeichnen und darüber eine Rücksetz- barkeit des Prozesses zu gewährleisten.

41 3 GBware und GBwareD

42 4 Entwurf des Transformationssystems

Business-Software setzt Geschäftsprozesse um, die oft über Jahre gesammeltes Exper- tenwissen enthalten. Durch neue Anforderungen an Hard- und Softwareumgebungen, an interne Abläufe oder externe Vorgaben, müssen realisierte Geschäftsprozesse konti- nuierlich angepasst und erweitert werden. Die Änderungen der Geschäftsprozesse be- treffen sowohl Aspekte der Software wie Sicherheit, Leistungsfähigkeit, Usability und Wartbarkeit als auch die Interaktion mit anderen Systemen. Unternehmen müssen folg- lich die Risiken einer Restrukturierung bzw. Modernisierung sowie den möglichst feh- lerfreien Betrieb der beteiligten Systeme in den Restrukturierungsprozess einbeziehen. Vielen Business-Softwaresystemen mangelt es häufig an Anpassbarkeit an heterogene Plattformen (z. B. unterschiedliche Betriebssysteme, Multicore-Systeme) oder Skalier- barkeit hinsichtlich der zu verarbeitenden Datenmenge, da die ursprünglich entworfene Software verteilte Aspekte nicht berücksichtigte. Die Anpassung der Software zur ver- teilten Ausführung kann Restrukturierungen großer Teile des Business-Softwaresystems mit sich bringen und viele Teile des Unternehmens und seiner Geschäftsprozesse betref- fen. Die Planung und Entwicklung eines Transformationssystems, das die Entwickler bei der Reorganisation und Anpassung von Business-Softwaresystemen bei den genannten Problemstellungen unterstützt, war Inhalt der Arbeitspakete 4 bis 6, die vorrangig vom Projektpartner TU Chemnitz bearbeitet wurden.

4.1 Anforderungen an Transformationen und Transformationssystem

Ein Ziel des Projekts TransBS war es, erprobte monolithische Business-Software zu modularisieren und die entstandenen Module in einen verteilten Programmkontext ein- zubetten. Im Rahmen des Projekts wurde Business-Software betrachtet, die in den Pro- grammiersprachen Delphi oder Java implementiert ist. Der Aufbau dieser Art von Soft- ware orientiert sich häufig am Rapid-Application-Development-Ansatz (RAD). Mit dem RAD-Ansatz können dem Kunden durch die grafische Unterstützung der Entwicklungs- umgebung in kurzer Zeit Prototypen seiner Software vorgestellt werden, die dann in mehreren Iterationsschritten weiter verfeinert und ausgebaut werden. Dieses Vorgehen hat den Nachteil, dass Anforderungen des Kunden (z. B. Skalierbarkeit), die zu einer grundsätzlichen Designentscheidung führen müssten, möglicherweise erst zu spät be- trachtet werden und nur schwer in den Prototypen integriert werden können. Weiterhin sind Nutzerschnittstelle und Business-Logik oft stark verwoben (GUI-Primitive kön- nen direkt Änderungen der Datenbank vornehmen), so dass eine Modularisierung, und

43 4 Entwurf des Transformationssystems damit die Trennung des Programmcodes für Nutzerschnittstelle und Business-Logik, erschwert wird.

Ausgehend von dieser exemplarischen Beschreibung der Probleme einer Reorganisa- tion bzw. Restrukturierung ergeben sich für die Transformation einer monolithischen Business-Software in eine modulare, komponentenbasierte Client-Server-Architektur folgende Anforderungen:

• Erhalt der Funktionalität des bestehenden Systems; • Sicherstellung der Korrektheit der Transformation; • Möglichkeit zur Bildung von Teilsystemen, die als Varianten des Systems mit eingeschränkter Funktionalität angeboten werden können; • Erhalt bzw. Ausbau der für weitere Änderungen wichtigen Softwareeigenschaften wie Erweiterbarkeit, Wartbarkeit und Flexibilität; • Explizite Integration von Verteiltheit (Zugriffsstrukturen, Synchronisation, Koor- dination) mit der Möglichkeit einer effizienten Realisierung; • Skalierbarkeit mit dynamischer Erweiterung und Anpassung an kundenspezifi- sche Anforderungen; • Flexible verteilte Abarbeitungsmöglichkeit auf modernen, heterogenen Plattfor- men.

Das entwickelte Transformationssystem unterstützt einen mehrstufigen Transforma- tionsprozess, der die genannten Eigenschaften integriert. Dies erlaubt eine Separati- on der verschiedenen zu transformierenden Eigenschaften, was zu einer Reduktion der Komplexität des Transformationsprozesses führt. Für das Transformationssystem erge- ben sich basierend auf den Anforderungen an die Transformationen folgende Grund- prinzipien:

• Sprachorientierte Spezifikation der Interaktion von Modulen bzw. Komponenten bestehender und neu zu erzeugender Softwaresysteme; • Abbildung des Transformationsprozesses als mehrstufigen Prozess bestehend aus Grob- und Feinstrukturabbildung der Softwarearchitektur; • Nutzung eines inkrementellen Transformationsprozesses, der das monolithische System über Zwischenstufen in das Zielsystem überführt; • Anwendung von Methoden der modellgetriebenen Softwareentwicklung; • Verwendung eines flexiblen Filtermechanismus zur Konkretisierung der Kompo- nentenverteilung; • Spezifikationskonzept zur Beschreibung von konkreten Transformationsszenari- en; • Nutzung von Methoden des Compilerbaus zur Durchführung der spezifizierten Transformationsanforderungen.

44 4.2 Basistechnologien und verwandte Ansätze

Die Anforderungen an zu transformierende Legacy-Software setzen eine andere Vor- gehensweise voraus als sie zur Erzeugung neuer Software notwendig ist. Aspekte der Analyse der Software und die Extraktion der bestehenden Struktur aus Programmcode, Dokumentation und weiteren Ressourcen sowie die Transformation und Generierung der Zielsoftware stellen eine große Herausforderung dar. Die Verschiedenartigkeit und Komplexität der Transformationsmöglichkeiten bedingt ein Zusammenspiel verschiede- ner Technologien aus den Gebieten Software-Engineering, verteilte Systeme, Compiler- bau und Softwareentwicklung moderner Business-Systeme.

4.2 Basistechnologien und verwandte Ansätze

Planung und Entwurf des Transformationsprozesses und der zugehörigen Werkzeuge, zur Erzeugung eines modularen und verteilten Softwaresystems, basieren auf vorhan- denen Methoden modularer, verteilter Programmgestaltung und bestehenden Konzepten zur Transformation von Software. Im Bereich von Business-Softwaresystemen ist dar- über hinaus die explizite Beschreibung von Geschäftsprozessen in Form von Workflows relevant.

4.2.1 Verteilungsplattformen

Die Entwicklung komponentenbasierter und verteilter Softwaresysteme wird als Com- ponent-based Software Engineering (CBSE) [17] bezeichnet. Ansätze des CBSE basie- ren auf unterschiedlichen Basistechnologien. Ein Beispiel ist die Common Object Re- quest Broker Architecture (CORBA) beschrieben durch die Object Management Group (OMG1). Der Ansatz stellt für die verteilte und unabhängige Entwicklung von Kompo- nenten die Interface Definition Language (IDL) bereit, die die programmiersprachenun- abhängige Spezifikation von Schnittstellen und austauschbaren Datenstrukturen ermög- licht. Basierend auf CORBA und remote procedure call-Mechanismen (RPC) wurde die remote method invocation (RMI) für Java entwickelt. RPC bietet eine Basis für die Kom- munikation von Enterprise Java Beans (EJB), eine Komponentenspezifikation von Sun, die eine verteilte Ausführung von Komponenten in Java ermöglicht. Das CORBA Com- ponent Model (CCM) erweitert diesen Ansatz auch auf andere Programmiersprachen.

Microsoft bietet mit dem distributed component object model (DCOM) eine weitere Möglichkeit zur verteilten Ausführung von Prozessen auf Basis der Plattform-Techno- logie COM, die unter dem Betriebssystem Windows eine Interprozesskommunikation und eine dynamische Objekterzeugung unabhängig von der verwendeten Programmier- sprache ermöglicht. Die genannten Middleware-Plattformen werden in Abschnitt 7.4 detailliert beschrieben.

1http://www.omg.org/ – Konsortium unterschiedlicher Unternehmen der Computerbranche mit dem Ziel Standards zu etablieren

45 4 Entwurf des Transformationssystems

Die beschriebenen Basistechnologien stellen zwar ein allgemeines Framework für ver- teilte Komponenten bereit, bieten jedoch keine Unterstützung für spezifische Anwen- dungsgebiete. CBSE greift dieses Problem auf und spezifiziert Ansätze zur inkremen- tellen Entwicklung von Softwaresystemen [41] oder das Zusammenstellen existierender Komponenten entsprechend gegebener Anforderungen und Spezifikationen [13, 53]. Die Wiederverwendbarkeit von Softwarekomponenten, welche besonders in Projekten mit langer Wartungszeit, wie beispielsweise Business-Software, häufig auftritt, wird ebenso in die Ansätze einbezogen wie Techniken der generativen oder aspektorientierten Pro- grammierung (AOP).

4.2.2 Transformationsframeworks und -ansätze

Die Transformation von Legacy-Software wurde durch verschiedene Forschergruppen betrachtet. Viele Ansätze konzentrieren sich auf die Transformation von Legacy-Soft- ware in modulare objektorientierte Systeme [7] oder auf die Extraktion von Business- Logik [16]. Neuere Ansätze berücksichtigen Aspekte der Verteiltheit, indem sie bei- spielsweise eine Middleware für die Datenintegration bieten [42]. Für verteilte Systeme spielt die Leistungsfähigkeit eine wesentliche Rolle, da zusätzliche Latenz- und Über- tragungszeiten entstehen, wenn beispielsweise lokale Aufrufe in einer Legacy-Software durch Webservices (z. B. SOAP) ersetzt werden [39]. Zur Transformation von großen Softwaresystemen wurde das System DMS entwickelt, welches beispielsweise das Fin- den von Code Clones, die Transformation von C/C++ Präprozessordirektiven oder die Transformation der Programmiersprache JOVIAL (Jules Own Version of the Internatio- nal Algorithmic Language; eine Variante von Algol 58) nach C ermöglicht [7]. Für die- se Transformationen können graphbasierte Visualisierungs-Tools oftmals hilfreich sein [5]. Auch Clustering-Methoden werden angewendet, um Module oder Komponenten in Legacy-Software zu identifizieren [40, 4]. Dieser Ansatz bietet auch für das Projekt TransBS Möglichkeiten zur Analyse von Software.

Obwohl verschiedene Ansätze zur Transformation von Business-Software formuliert wurden, existieren keine allgemein akzeptierten Methoden zur inkrementellen Trans- formation von Software. Ein wichtiger Grund ist das Vorhandensein verschiedener ver- teilter Softwareplattformen wie CORBA oder EJB, die nicht in beliebiger Weise mitein- ander verknüpft werden können. Ein weiterer Grund ist die Vielschichtigkeit der Pro- bleme der Transformation von Business-Software, die eine allgemeine Formulierung erschwert. Viele modulare und verteilte Lösungen bedingen deshalb häufig eine Neu- entwicklung der Business-Logik.

Der Model Driven Architecture (MDA2) Ansatz geht auf das Problem der Heterogenität der Plattformen ein und nutzt ein modellgetriebenes Konzept zur schrittweisen Erzeu- gung komponentenbasierter und verteilter Software aus einer gegebenen Anforderungs- beschreibung [49]. Die schrittweise Generierung beginnt mit einer UML-Spezifikation der statischen Schnittstellen und des dynamischen Verhaltens der Komponenten in ei- nem plattformunabhängigen Modell (Platform Independent Model, PIM). Eine Reihe 2http://www.omg.org/mda/

46 4.3 Konzeption des Transformationsprozesses von Modelltransformationen wie CORBA profiles oder Enterprise Application Integra- tion (EAI), die als UML-Erweiterungen zur Verfügung stehen, führen zur Erzeugung eines plattformspezifischen Modells (Platform Specific Model, PSM). Dieses Modell dient wiederum zur Generierung von Programmcode oder Programmgerüsten für ei- ne gewählte Plattform. Wesentlich für eine Anwendung der MDA-Ansätze auf Lega- cy-Software ist die zu einem großen Teil automatische Erzeugung des PSM bzw. des PIM aus bestehendem Programmcode, Dokumentation und weiteren verfügbaren Da- ten. Besonders die Menge und Heterogenität vorhandener Daten erschweren dabei die Erzeugung des Softwaremodells.

4.2.3 Workflowbeschreibungen

Ein wichtiger Bestandteil verteilter Business-Software ist die Transparenz der verteil- ten Ausführung und die Integration expliziter Workflow-Definitionen. Wenn das Wissen über die Verteilung für die Schnittstellen explizit definiert wird und somit vor dem Ent- wickler nicht verborgen ist, führt die Transparenz vor allem zur Vermeidung kostenin- tensiver entfernter Aufrufe in verteilter Business-Software.

Workflow-Technologien für die formale Beschreibung der Ausführung von Business- Prozessen sind ein wichtiger Bestandteil für die Entwicklung flexibler Business-Softwa- re. Die Workflow Management Coalition (WFMC3) beschreibt Standards für Workflow- Architekturen, die auch Aspekte verteilter Ausführung umfassen. Eine direkte Integra- tion von Workflows in verteilte Technologien wurde bisher kaum von anderen Autoren betrachtet [20]. Detaillierte Beschreibungen von Workflow-Beschreibungssprachen und Ausführungsumgebungen sind in den Abschnitten 8.2 und 8.3 zu finden.

4.3 Konzeption des Transformationsprozesses

Der wesentliche Bestandteil des Transformationsprozesses ist eine Zwischendarstel- lung, die den gesamten Transformationsprozess unterstützt und unabhängig von einer konkreten Programmiersprache die Legacy-Software mit ihren Abhängigkeiten und lo- gischen Strukturen abbildet. Diese Hilfsstruktur setzt sich aus mehreren Ebenen zusam- men und beinhaltet sowohl den statischen Aufbau der Software als auch Metainforma- tionen über Transformation, Modularität, Verteilung, usw. Die oberste Ebene bildet eine Koordinationsstruktur, die die Komponenten der Software enthält, die die tatsächliche Funktionalität kapseln und eine weitergehende Analyse der enthaltenen hierarchischen Struktur ermöglicht. Die hierarchische Struktur wird in einzelne Module gegliedert, die den Programmcode der Legacy-Software enthalten.

Die Zwischendarstellung des Transformationsprozesses zur Erzeugung einer modula- ren, flexiblen verteilten Software aus einer gegebenen monolithischen Software wird im Folgenden als Flexible Software Representation (FSR) bezeichnet. Durch sukzessive 3http://www.wfmc.org/

47 4 Entwurf des Transformationssystems

Flexible Software Representation

FSR

Software Explicit Distributed Subsystem Workflow Software

Software Distributed Software Subsystem Software Subsystem als gesteuert durch mit adaptivem Distributed expliziten Workflow System Workflow

FSP

Flexible Software Package

Abbildung 4.1: Übergangsdiagramm der Flexible Software Representation (FSR) in ver- schiedene Softwaresichten.

Transformationen wird die Legacy-Software zunächst in ein modulares Softwaresys- tem umgewandelt, das durch die FSR beschrieben wird. Das modulare System bildet die Grundlage für eine verteilte Ausführung der Module, entsprechend einer gegebenen Spezifikation der Verteilung. Zur Unterstützung des Transformationsprozesses wird ein Toolset bereitgestellt, das die Schritte automatisiert und eine adäquate Interaktion mit dem Nutzer bietet. Die Zwischendarstellung ist der Ausgangspunkt zur schrittweisen Transformation in eine Software mit gleichem Ausführungsverhalten aber unterschied- lichen Sichten auf die Software.

4.3.1 Softwaresichten

Abbildung 4.1 zeigt die Zwischendarstellung und die unterschiedlichen Sichten auf die Software. Es werden folgende Sichten unterschieden:

• Software Subsystem mode (SSu) stellt die explizite modulare Struktur der Softwa- re dar. Die SSu erlaubt die Auswahl von Modulen, die separierbare Funktionali- täten abbilden. Intention dieser Sicht ist die Extraktion einzelner Funktionalitäten aus der Gesamtsoftware. • Explicit Workflow mode (ExW) beschreibt die Geschäftsprozesse (Business-Lo- gik) der Software durch explizite Workflows in einer XML-basierten Beschrei- bungssprache. Diese Sicht ist die Basis für Änderungen des Workflows zur An- passung an die gewählte Zielplattform. • Distributed Software mode (DS) spezifiziert eine explizite Struktur kooperieren- der Komponenten, die auf ein frei wählbares verteiltes System abgebildet werden können. Die DS basiert auf der modularen Struktur, die durch die SSu beschrieben

48 4.3 Konzeption des Transformationsprozesses

Tabelle 4.1: Abstraktionsschichten der Softwaresichten der FSR.

Flexible Software Representation – FSR Software Subsystem Explicit Workflow Distributed – SSu – – ExW – Software – DS – Modellebene Koordinations- Workflow- Komponenten- program beschreibung interaktion Tiefere Ebene Module/Funktionen Module Komponenten statische Programmier- Workflow-Engine verteiltes Komponenten umgebung Laufzeitsystem

wird. Das Ausführungsverhalten der DS kann implizit durch die Komponenten selbst oder durch einen expliziten Workflow festgelegt werden.

Alle drei beschriebenen Sichten werden aus der ursprünglichen FSR erzeugt. Durch Kombination der verschiedenen Sichten können Softwarebeschreibungen mit erweiter- ten Eigenschaften abgeleitet werden. Beispielsweise bietet die Kombination aus SSu und ExW die Möglichkeit der Definition eines Softwarepakets, das konfigurierbare Work- flows enthält. Eine Kombination aus SSu und DS beschreibt dagegen, wie einzelne Mo- dule einer Software in einer verteilten Umgebung angeordnet werden und interagieren können. Werden alle Sichten zusammengefasst, entsteht das Flexible Software Package (FSP), ein adaptives, verteiltes, modulares System, das durch konfigurierbare Workflows gesteuert wird.

Der Vorteil der inkrementellen Transformation in die verschiedenen Softwaresichten und ihrer Kombination liegt darin, dass nicht jedes Softwareprodukt alle Eigenschaften der verschiedenen Sichten aufweisen muss. Zur Effizienzsteigerung werden nur dieje- nigen Eigenschaften zum Endprodukt hinzugefügt, die tatsächlich benötigt werden, da aus zusätzlichen Eigenschaften häufig auch ein höherer Bedarf an Ressourcen folgt.

Die Transformation der FSR in die verschiedenen Softwaresichten und ihre Kombina- tion erfolgt auf abstrakter Ebene. Die Zwischendarstellung selbst besteht aus einer (ab- strakten) Modellebene und einer oder mehreren darunter liegenden Ebenen. Die Model- lebene beschreibt die Interaktion der Komponenten und bietet eine abstrakte Sicht auf das Softwaresystem. In niedrigeren Ebenen befinden sich die Teile der Software, die ei- ne spezielle Funktionalität der Business-Software implementieren. Eine Transformation arbeitet auf allen Ebenen, wandelt die Darstellungen der jeweiligen Ebene entsprechend der Transformation um und stellt die Konsistenz der Ebenen sicher. Alle Ebenen zusam- men bilden die endgültige Software, die zusätzliche statische Komponenten benötigt, um ausführbar zu sein. Modellebene und eine darunter liegende Ebene sind in Tabel- le 4.1 zusammen mit benötigten statischen Komponenten für die jeweiligen Sichten der FSR dargestellt.

49 4 Entwurf des Transformationssystems

Specification Intermediate Execution Executable Executable Executable Level Representation Mode Software Software Software

Coordination SSu Program

Logical Modular Workflow

Structure Structure Description filter create

transform Coordination Structure

Business Software FSR ExW System Set of Modules

Code Components/ Modules DS

Fragments Services select create transform Components include include inc. Programming Workflow Distributed Environment Engine Runtime System

Abbildung 4.2: Transformationsentscheidungen und Transformationsprozess.

4.3.2 Grobstruktur des Transformationsprozesses

Der gesamte Transformationsprozess besteht aus einer Menge einzelner interaktiver Transformationsentscheidungen. Abbildung 4.2 zeigt die Grobstruktur des Transforma- tionsprozesses und beschreibt Pfade von der Legacy-Software zu möglichen Zielstruk- turen in Abhängigkeit von den Entscheidungen in den verschiedenen Transformations- stufen. Jeder Pfad in Transformationsrichtung, vom Business Software System zu einer Executable Software, entspricht einem Transformationsprozess durch den ein Software- system einer bestimmten Softwaresicht entsteht. Die Softwaresysteme können mit Hilfe verschiedener Techniken wie CORBA oder EJB umgesetzt werden. Der Transforma- tionsprozess orientiert sich an verschiedenen Ausprägungen des MDA-Ansatzes. Der Transformationsprozess beginnt mit der Spezifikationsstufe (specification level), die die logische Struktur der Legacy-Software extrahiert und vorhandene Code-Fragmente zusammenfasst, die später als Module verwendet werden können. Für diesen Schritt werden Compilertools eingesetzt, die eine Analyse der Elemente und Abhängigkeiten der vorhandenen Software durchführen und in die gewünschte Zwischendarstellung (In- termediate Representation, FSR) überführen. Die Herstellung einer geeigneten Modul- struktur wird durch Komponentenbildungstransformationen realisiert. Aus der FSR, die die Modulstruktur und Module der Legacy-Software enthält, können nun die verschie- denen Sichten (Execution Mode) erzeugt werden, beispielsweise ein Koordinationspro- gramm (Coordination Program) für die Sicht SSu oder eine Workflow-Beschreibung (Workflow Description) für ExW. Die Sichten bilden die Basis für die verschiedenen Zu- sammenstellungen, die durch zusätzliche statische Komponenten als ausführbare Soft- ware (Executable Software) realisiert werden können. Die Auswahl benötigter Module und ihrer Kooperations- und Koordinationsstrukturen werden durch Filtertransformatio- nen realisiert.

50 4.4 Entwurf einer Software-Architektur des Transformationssystems

Transformation System User Interface

FSR Views Transformation UI

Transformation System

Application/View Logic External Plugins

Transformation Modules

FSR FSR Creation Programmcode Delphi FSR Transformation Access Java FSR Generation Flexible Software Representation

Abbildung 4.3: Schematische Darstellung der Architektur des Transformationssystems.

4.4 Entwurf einer Software-Architektur des Transformationssystems

Die Anforderungen an den Transformationsprozess und die Transformationen wurden in der Architektur des Transformationssystems aufgenommen. Abbildung 4.3 zeigt die Module des Transformationssystems und ihre vereinfachte Interaktion. Die modula- re komponentenorientierte Architektur besitzt eine Nutzerschnittstelle zur interaktiven Transformation und Analyse der Zwischendarstellung, die den Zugriff auf das Transfor- mationssystem mit unterschiedlichen Sichten auf die FSR und deren Transformations- prozess unterstützt und Ergebnisse für den Nutzer grafisch abbildet und aufbereitet. Die Nutzerschnittstelle wird durch Model-View-Controller (MVC) [24] oder Model-View- Presenter (MVP) [23] Prinzipien von der Logik des Transformationssystems separiert, um Flexibilität und Erweiterbarkeit der Nutzerschnittstelle und der Logik zu erreichen. Die Komponenten der Architektur des Transformationssystems sind:

• Das Modul Flexible Software Representation (FSR) beinhaltet die Modelldaten und Zugriffsmechanismen auf die Zwischendarstellungen der Legacy-Software. Es bietet eine zentrale Schnittstelle zum Aufbau und zu Metainformationen der bearbeiteten Software und bisher ausgeführten Transformationen. Über eine Mo- dellschicht werden in darunter liegenden Ebenen Module und deren Codestruktu- ren referenziert. Durch Transformation der FSR werden die Metadaten (Koordi- nationsprogramm, Workflow-Beschreibung, etc.) über die enthaltenen Software- elemente z. B. zur Visualisierung für eine ausgewählte Sicht (FSR Views) hinzu- gefügt.

51 4 Entwurf des Transformationssystems

• Das Modul Application/View Logic stellt Algorithmen zur Aufbereitung der FSR-Daten in der Nutzerschnittstelle und zur Abhängigkeitsanalyse innerhalb der FSR zur Verfügung. Das Modul referenziert ausschließlich die Modellebene der FSR, um Abhängigkeiten zu programmiersprachenspezifischen Eigenschaften zu vermeiden und allgemeine Funktionalitäten zur Erzeugung der Sichten SSu, ExW und DS zu liefern. Zur Bereitstellung der Funktionalität für die Sichten können auch externe Werkzeuge über das Modul External Plugins eingebunden werden. • Die Komponente Transformation Modules beinhaltet Module zur Erzeugung der FSR aus der Legacy-Software (FSR Creation), der Transformation der FSR (FSR Transformation) und der Generierung von Programmcode für die Zielplattform (Code Generation). Über die Transformation UI (Transformation System User Interface) können Nutzer mit den enthalten Modulen interagieren.

– Im Modul FSR Creation wird die Extraktion der FSR aus der bestehenden Legacy-Software vorgenommen. Dabei wird aus dem Programmcode der Software eine abstrakte und von Programmiersprachen unabhängige Dar- stellung durch eine Sprachtransformation mit Hilfe von Compilerwerkzeu- gen gewonnen. Der Zugriff auf den konkreten Code wird über das Modul Programcode Access gekapselt, um die Erweiterung auf neue Programmier- sprachen möglichst einfach zu gestalten. – Transformationen der FSR werden im Modul FSR Transformation durch- geführt. Die Grobtransformationsschritte Komponentenerzeugungs- und Fil- ter-Transformation werden in Einzeltransformationen umgesetzt, die je nach Transformationsziel in unterschiedlicher Reihenfolge inkrementell auf die FSR angewendet werden können. – Das Modul Code Generation erzeugt aus der FSR Programmcode für die gewählte Zielplattform und generiert notwendige Schnittstellen zu den benö- tigten statischen Komponenten. So können beispielsweise erzeugte Module als Enterprise Beans in einem Java Enterprise Server (JavaEE4) eingebettet werden oder erzeugte explizite Workflow-Beschreibungen in eine Workflow- Beschreibungssprache (z. B. XPDL5) übersetzt werden.

• Programcode Access bietet für alle Transformation Modules die Möglichkeit des Zugriffs und der Verarbeitung von Programmcode der Legacy-Software. Zusätz- lich können über dieses Modul externe Werkzeuge wie beispielsweise Parserge- neratoren oder Sprachtransformationstools angebunden werden. Im Modul wird versucht, den Zugriff auf den Programmcode zu abstrahieren, so dass die Trans- formation Modules möglichst unabhängig von der verwendeten Sprache agieren können. Durch die Beschränkungen der jeweiligen Zielplattform kann es jedoch auch zu Einschränkungen der Transformationen kommen, so dass eine völlige Ab- straktion von der Programmiersprache nicht in jedem Fall erreicht werden kann. Als Beispiele für unterstützte Programmiersprachen werden in der schematischen Darstellung der Architektur Delphi und Java genannt.

4http://java.sun.com/javaee/ 5Standardisierte Sprache für Workflows der Workflow Management Coalition (WfMC)

52 4.4 Entwurf einer Software-Architektur des Transformationssystems

• External Plugins bietet Schnittstellen zu externen Werkzeugen deren Funktio- nalität im Transformationssystem verwendet wird (z. B. Compilerwerkzeuge oder Visualisierungssoftware). Das Modul steuert den Ablauf der Verwendung und bie- tet eine zentrale Fehlerbehandlung für die verwendeten externen Tools, um deren Verwendung im Transformationssystem unabhängig von tatsächlichen Implemen- tierungen zu gestalten. Beispielsweise können durch diese Herangehensweise Ver- änderungen der Schnittstelle zum externen Tool zentral im Modul External Plug- ins behandelt werden.

Die Kapselung der einzelnen Module der Architektur spielt für die Weiterentwick- lung des Transformationssystems auch in Hinblick auf eine Erweiterbarkeit in eine Komponenten- oder Plugin-Architektur eine wichtige Rolle. Vorteil des modularen Auf- baus des Transformationssystems ist die Einsetzbarkeit einer Auswahl der Module, um spezifische Problemstellungen zu lösen. Beispielsweise kann aus den Modulen FSR, FSR Creation und User Interface ein Subsystem zur Analyse von Software erzeugt wer- den, das Entwickler bei der Implementierung von Software unterstützt und eine abstrakte Sicht auf die bestehende Gesamtarchitektur bietet.

53 4 Entwurf des Transformationssystems

54 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Gegenstand der Auswahl einer Infrastruktur zur Realisierung des Transformationssys- tems war die Erfassung existierender Sprach- und Transformationsansätze und eine Bewertung hinsichtlich einer Eignung für das Projekt. Dazu wurden zunächst Ansät- ze und Tools der modellgetriebenen Softwareentwicklung untersucht und Konzepte für den Transformationsprozess adaptiert. Zur geeigneten Modellierung der Zwischendar- stellung für eine abstrakte Sicht auf Legacy-Software wurden verschiedene abstrakte Softwaremodelle evaluiert und wichtige Bausteine in die Realisierung der FSR über- nommen. Darüber hinaus wurden unterschiedliche Werkzeuge untersucht, die als Meta- komponenten für verschiedene Teilaufgaben des Transformationsprozesses herangezo- gen werden.

5.1 Model Driven Architecture (MDA)

Die Object Management Group (OMG) spezifiziert mit der Model Driven Architecture (MDA) einen herstellerneutralen Entwicklungsprozess, der als Standard der modellge- triebenen Softwareentwicklung etabliert werden soll. Die Grundlage von MDA ist die plattformunabhängige modellbasierte Beschreibung von Softwaresystemen und deren Überführung mit Hilfe weiterer plattformspezifischer Modelle in kompilierbaren Pro- grammcode. Bei jedem Übergang fügt der Entwickler neue Informationen zum aktuellen Modell hinzu und wird bei der Transformation in ein spezifischeres Modell (bis hin zum Programmcode) durch automatische Modelltransformationen unterstützt. Die Intention des Entwicklungsprozesses ist es, Änderungen an der Software durch Änderungen des Modells zu verwirklichen und diese mit den vorhandenen Modelltransformationen in ausführbaren Programmcode zu überführen.

Das Konzept des Transformationsprozesses verfolgt eine gleichartige inkrementelle Vor- gehensweise, bei der das Ausgangsmodell nicht aus Anforderungen an eine Neuentwick- lung, sondern aus bestehenden Programmstrukturen und Anforderungen an eine Anpas- sung der Business-Software erzeugt wird. Aus diesem Grund wurden die Konzepte und bestehende Werkzeuge der MDA bezüglich ihrer Eignung für das Transformationssys- tem evaluiert.

55 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Abbildung 5.1: Beispiel einer Modelltransformation nach dem MDA-Ansatz vom platt- formunabhängigen Modell (PIM) über das plattformabhängige Modell (PSM) zum Programmcode (Code).

5.1.1 MDA Entwicklungsprozess

Der inkrementelle Prozess der modellgetriebenen Entwicklung besteht aus drei Teil- schritten. Abbildung 5.1 zeigt ein Beispiel für modellgetriebene Transformationen nach dem MDA-Ansatz. Ausgangspunkt stellt das Platform Independent Model (PIM) dar. Es beschreibt Software und insbesondere Geschäftsprozesse auf einer Metaebene, oh- ne Details einer speziellen Plattform wie CORBA oder EJB zu berücksichtigen. Durch eine Model-to-Model-Transformation wird das PIM in das Platform Specific Model transformiert. Hier werden Details der Plattform hinzugefügt. Im Beispiel der Abbil- dung 5.1 wird eine BusinessEntity als EJBEntityBean realisiert oder eine UniqueID als Primärschlüssel einer Datenbank umgesetzt. Aus dem plattformspezifischen Modell kann durch eine weitere Transformation Programmcode bzw. ein Programmgerüst ge- neriert werden. Die Transformationsregeln zwischen den Abstraktionsebenen werden durch MDA-Tools unterstützt, müssen aber für die jeweilige Domäne angepasst bzw. ergänzt werden. Als übergeordnete Ebene der Modelle wird das Computational Inde- pendent Model (CIM) verwendet, das eine umgangssprachliche Beschreibung der Soft- ware (bzw. der zu Grunde liegenden Geschäftsprozesse) darstellt. Da eine automatische Transformation aus dem CIM in ein PIM nur schwer möglich ist, kommt das CIM im Rahmen der modellgetriebenen Entwicklung von Software nur gelegentlich zum Ein- satz. Für alle Modelle des MDA-Ansatzes wird eine Modellierung durch UML mit do-

56 5.1 Model Driven Architecture (MDA) mänenspezifischen Erweiterungen (Domain Specific Language, DSL), Stereotypen oder der Object Constraint Language (OCL) zur Präzision der Modelle favorisiert [45].

Die modellgetriebene Vorgehensweise führt häufig zu einem sehr komplexen Entwick- lungsprozess, wenn im Laufe der Entwicklung Modelländerungen einer Stufe Änderun- gen des übergeordneten Modells nach sich ziehen. Diese Änderungen werden zur Zeit häufig per Hand in das bestehende Modell eingebracht, was dem Ansatz der automati- schen Modelltransformation widerspricht. Werden beispielsweise Änderungen des ge- nerierten Programmcodes von Hand vorgenommen, stimmt die Struktur des Codes nicht mehr mit dem Modell überein und eine Anpassung des Modells muss erfolgen. Dieser Vorgang kann sich anschließend auch auf höhere Abstraktionsebenen propagieren.

5.1.2 MDA Werkzeuge

Im Rahmen des Arbeitspakets wurden fünf verschiedene MDA Werkzeuge auf ihre Eig- nung als Infrastruktur für das Transformationssystem untersucht. Tabelle 5.1 zeigt die Auswahl proprietärer und frei verfügbarer MDA Werkzeuge mit ihren Eigenschaften. Proprietäre Tools verfügen dabei über den größten Funktionsumfang und enthalten zum Teil auch Unterstützung für Code-to-Model Transformationen zur Generierung eines Modells aus bestehendem Code, die eine essentielle Funktionalität zur Analyse von Legacy-Software darstellen. Allerdings wird oftmals nur eine Analyse des vom Tool selbst erzeugten Programmcodes unterstützt (er enthält beispielsweise geschützte Be- reiche, die nicht verändert werden dürfen), was eine Anwendung auf Legacy-Software erschwert. Die untersuchten freien MDA-Tools OpenArchitectureWare1 und AndroM- DA2 unterstützen nur das Erzeugen neuer Software (Forward Engineering) und sind nicht mit vertretbarem Aufwand auf Reverse- bzw. Roundtrip Engineering erweiterbar. Für die Anwendbarkeit des Transformationswerkzeugs auf Legacy-Software ist diese Erweiterung jedoch essentiell. Zusätzlich ergeben sich durch die Beschränkungen der (plattformabhängigen bzw. -unabhängigen) Modellspezifikationen Schwierigkeiten bei der Beschreibung von feingranularem Programmcode, was eine automatische Transfor- mation der Modelle und eine anschließende Propagierung auf den Programmcode ver- hindert.

Nach eingehender Untersuchung ist die Anwendbarkeit existierender MDA Werkzeu- ge nur mit außerordentlichem Aufwand, der einer Neuentwicklung gleich kommt, zu ermöglichen. Demgegenüber sind jedoch die MDA Konzepte der Abstraktion von Soft- ware auf verschiedene Modellebenen und die zugehörigen Modelltransformationen sehr gut auf die Analyse und Transformation von Legacy-Software anwendbar. Die Model- lebenen bieten die Möglichkeit zur Realisierung der Transformation in verschiedenen Schichten, die eine Reduzierung der Komplexität und eine Differenzierung der Zustän- digkeiten in einzelne Module des Transformationssystems ermöglicht. Basierend auf diesen Rahmenbedingungen wurde eine Eigenimplementierung mit Einbeziehung exter- ner Werkzeuge zur Realisierung des Transformationssystems favorisiert. Dazu wurden

1http://www.openarchitectureware.org/ 2http://www.andromda.org/

57 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Tabelle 5.1: Auswahl frei verfügbarer und proprietärer MDA Werkzeuge (Stand: Sep- tember 2006).

IBM Compuware Interactive Open AndroMDA Rational OptimalJ Objects Architecture Software ArcStyler Ware Architect

Typ Suite Suite Suite Framework Framework

IDE Eclipse Eclipse, keine Eclipse Eclipse JBuilder, VisualStudio

UML- 2.0 1.3, 1.4 2.0 je nach 2.0 je nach Support 2.0 teilweise UML Tool UML Tool

PIM/PSM Verknüpfung Mittels Mittels Ja, Nein Transfor- von PSM Modulen Marksets ab Version 4 mationen mit PIM

Methoden Forward, Forward, Forward, Forward Forward Reverse, Reverse, Reverse Roundtrip Roundtrip

Ziel- C++, Java Java, XML, Java, .NET, Beliebig Java, SQL, sprachen SQL C++, Cobol, durch anpassbar CORBA Anpassung

Zielarchi- J2EE J2EE, .NET, J2EE, .NET, Beliebig J2EE (Spring, tekturen CORBA CORBA durch Hibernate, Anpassung Struts), anpassbar Testen Component Unit Tests Unit Tests Nein Nein Tests (JUnit) (JUnit) verschiedene existierende Modelle zur detaillierten Beschreibung von Software unter- sucht, die im Folgenden vorgestellt werden.

5.2 Modellspezifikationen für Software und Transformationen

Basisbaustein des Transformationssystems ist das Modul Flexible Software Representa- tion zur Abbildung der Legacy-Software in einer mehrschichtigen Zwischendarstellung. Für die Repräsentation der Modellebene wurden verschiedene vorhandene Softwaremo- delle und vorhandene Tools der Modelle evaluiert.

58 5.2 Modellspezifikationen für Software und Transformationen

0..1 defines ModelObject {abstract} SourceObject {abstract} name 0..1 declares *

ModelElement {abstract} ModelRelationship {abstract} visibility

isSubpackageOf invokes * ** * accesses * Package StructuralElement {abstract} BehaviouralElement {abstract} 0..1 * imports

* isOfType 0..1 Type Value hasValue ExecutableValue Method 0..1 * isDefinedInTermsOf 0..1 isConstructor 0..1 isDestructor isAbstract Variable isParameterOf EnumeratedType isDynamicallyBound isOverideable 1..* * * CollectionType isEnumerationLiteralOf Routine FormalParameter size EnumerationLiteral position * StructuredType isFieldOf Field

0..1 isMethodOf * Class isSubclassable * * inheritsFrom

Figure 9: Program Representation Graph (type graph) for the OO paradigm (simplified). Note that, in order to be more clear visually, the abstract elements have extra ’ ’ in their name as prefix and postfix in additionAbbildung to the usual italic 5.2: Links: Program Representation Graph (PRG) [16]. Rechts: Strukturmo- Tools (JDT) [8]. As for the metamodel, an Eclipse Modeling Framework (EMF [7]) based meta- model for Java called Java EMF Modeldell (JEM) des is part Dagstuhlof the Eclipse’s Visual Middle Editor project, Model but is (DMM) [38]. still in its early development stages [9]. A different issue is the type of relation between the PRG and the model used to reference the source code. We are considering the following alternatives: 1. An extension to the type graph (PRG) by adding an attribute to the abstract class CodeFrag- Derment thatProgram uniquely identifies Representation the equivalent element in the source Graph code reference (PRG) model [16] (Abbildung 5.2, links) stellt ein all- 2. The use of an association model that defines the mapping between elements of the PRG and gemeinescorresponding elements Modell of the source für codeobjektorientierte reference model Sprachen zur Verfügung. Im Modell werden die The first alternative is a straight-forward solution that has a tight relation between both models. ThisUML-typischen is a drawback because with this option Elemente the PRG will depend wie on theKlassen, chosen source code Methoden, ref- Variablen und ihre Beziehungen, erenceaber model. auch Its main advantage feingranulare is the simplicity ofElemente implementation where wie no extra Sequenzen models are von Programmcode (CodeFragment) oder abstrakte Statements (StructuralElement) abgebildet. Das Basiselement des Gra- phen stellt eine Klasse (Class) dar. Der PRG enthält Referenzen zum AssociationModel, über das ein Zugriff auf den Programmcode der Modellelemente möglich ist. In einer Implementierung für Java wurde der Zugriff auf den Programmcode mit dem Eclipse Framework Java Development Tools (JDT) realisiert, das auch Transformationen des Programmcodes (Refactorings) mit Hilfe der Entwicklungsumgebung Eclipse zulässt.

Lethbridge et al. beschreiben das Dagstuhl Middle Model (DMM) in [38], das ein umfangreiches Modell zur Abbildung objektorientierter und prozeduraler Programmier- sprachen darstellt. Es separiert die Darstellung statischer Strukturen (Klassen, Metho- den; siehe Abbildung 5.2 rechts) (StructuralElements) von der Beschreibung der Bezie- hungen zwischen den statischen Elementen (BehaviouralElements) und bietet darüber hinaus ein Teilmodell zur Abbildung von Programmcode (SourceObjects). Das Basisele- ment des Graphen bildet ein package, das wiederum packages oder Klassen/Module ent- halten kann. Das Modell wurde vorrangig als Zwischendarstellung des Programmcodes für Tools zur Visualisierung verwendet.

Sowohl für die genannten Modelle als auch für weitere Modelle wie dem Columbus Schema [22] oder dem Abstract Syntax Graph [44] steht häufig nur die Modellspezifika- tion zur Verfügung. Tools zur Transformation von Programmcode in die entsprechenden Modelle sind kaum öffentlich verfügbar bzw. in proprietären Werkzeugen integriert, so dass eine Anpassung und Wiederverwendung nicht möglich ist.

59 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Für die Spezifikation der Flexible Software Representation werden daher die Konzep- te der evaluierten Modelle adaptiert und in ein eigenes Modell integriert. Wesentlich hierbei sind:

• Ein hierarchischer Aufbau der statischen Elemente der Programmiersprache; • Die Integration eines Beziehungsmodells für objektorientierte Programmierspra- chen; • Referenzierung des Programmcodes in den Modellelementen zur Propagierung der Modelltransformationen zum Programmcode; • Einfache Erweiterbarkeit des Modells zur Adaption für neue Programmierspra- chen; • Mechanismen zur Konsistenzsicherung zwischen referenziertem Programmcode und Modell.

Zusätzlich zur Modellierung der Legacy Software muss in der FSR eine Komponen- te zur Verwaltung der Transformationen realisiert werden. Die Komponente ist für die Anwendung der Transformationsoperationen auf die FSR und die Möglichkeit zur Wie- derherstellung des ursprünglichen Zustands zuständig. Die Realisierung der Transfor- mationsoperationen selbst ist nicht Bestandteil der Komponente.

Die untersuchten Softwaremodelle enthalten keine zusätzlichen Konzepte zur Spezifi- kationen von Transformationen der Modelle. Auch im Bereich der MDA-Werkzeuge existiert kein allgemein gültiger Ansatz zur Beschreibung von Transformationen. Häufig wird dort eine werkzeugspezifische Beschreibung auf Basis von XML gewählt, die die Eigenschaften der jeweiligen Modelländerung enthält. Für die Entwicklung des Trans- formationsprototypen wird daher ebenfalls eine selbst definierte Spezifikation der Trans- formationen auf XML-Basis gewählt.

Abbildung 5.3 veranschaulicht den schematischen Aufbau der Flexible Software Repre- sentation. Folgende Elemente sind in der FSR integriert:

• Das Software Model beschreibt den statischen Aufbau des Programmcodes der Legacy-Software und enthält Elemente zur Modellierung der unterschiedlichen Arten der Beziehungen in objektorientierten Sprachen (Beziehungen aus Verer- bung, Aufrufbeziehungen, etc.). Das Modell verfügt über einen ausgezeichneten Basisknoten (Program), Elemente für Teilsysteme (Subsystem), eine Komponente Module zur Modellierung von Klassen und Interfaces und feingranulare Elemente innerhalb von Klassen wie Attribute (Variable), Methoden (Procedure), Codeblö- cke (CodeBlock) und Statements (Statement). Das Softwaremodell referenziert ein Modell des Programmcodes (Code Model), über das der Zugriff und die Trans- formation des Legacy-Programmcodes möglich ist. • Das Transformation Module stellt eine Schnittstelle zur Transformation der FSR bereit und verwaltet durchgeführte Transformationsoperationen.

– Im Transformation Model werden durchgeführte Transformationsoperatio- nen in einer Baumstruktur modelliert. Über den Wurzelknoten (Root) werden

60 5.2 Modellspezifikationen für Software und Transformationen

Flexible Software Representation

Code Model

Software Model Transformation Module

1 * Transformation SubSystem * 1 Program Manager 1 1 * * * 1 1 Module LocalModule

1 Consistence * Block Procedure 1 * Statement * Manager Statement

1 1 * Simple * Variable * 1 LocalVariable Statement Transformation Model

* 1 * Root 1 * 1 CodeBlock Dependency 1 * Operation1 ... Operationn Module Procedure Variable Dependency Dependency Dependency Operationn,1 ... Operationn,m

Abbildung 5.3: Entwurf der Flexible Software Representation (FSR) bestehend aus sta- tischem Softwaremodell mit Beziehungsmodell und Transformations- komponente.

die vom Nutzer initiierten Transformationen in ihrer Reihenfolge als Kind- knoten angeordnet (Operation1 bis Operationn). Eine Transformation selbst kann weitere Transformationen bedingen, die als Kindknoten der Transfor- mation dargestellt werden (Bedingte Transformationen von Operationn sind die Transformationen Operationn,1 bis Operationn,m). – Die Ausführung aller Transformationen im Transformation Model wird vom Transformation Manager gesteuert und entspricht einer Postorder-Traver- sierung des Baums des Transformation Models, wobei die Wurzel (Root) eine Referenz zur Liste der Transformationen (Operation1 bis Operationn) darstellt. Der Manager stellt zusätzlich Methoden zum Rücksetzen durchge- führter Transformationen bereit. Die Realisierung der Transformationsope- rationen selbst ist nicht Bestandteil des Transformation Managers, sondern ist Teil der Transformation Modules (siehe Abbildung 4.3). – Treten während der Durchführung einer Transformation Fehler auf, so ist der Consistence Manager für die Wiederherstellung des letzten konsistenten Zustands des Softwaremodells und die Weiterleitung der Fehlerausgabe an das User Interface zuständig. Die Korrektheit der Transformationsoperatio- nen kann nur über spezifizierte Vor- und Nachbedingungen in den Operatio- nen selbst sicher überprüft werden. Allgemeine Korrektheitsprüfungen des Modells bzw. des Programmcodes können nur auf syntaktischer Basis (z. B. Grammatik des Codes, spezifizierte Einschränkungen des Modells) getrof- fen werden, was jedoch die detaillierten (semantischen) Eigenschaften nach einer Transformation des Modells oder des Codes nicht berücksichtigt.

61 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Zur Sicherung der Persistenz kann die Flexible Software Representation als XML-Do- kument dargestellt und gesichert werden. Die Erzeugung und Transformation der FSR aus Legacy-Software sowie die Visualisierung der FSR können durch existierende Tech- niken und Werkzeuge unterstützt werden, die im nächsten Abschnitt beschrieben wer- den.

5.3 Toolunterstützung der Verarbeitung der Transformation

Die Analyse von Legacy-Software setzt ein detailliertes Verständnis des vorhandenen Programmcodes voraus. Zu diesem Zweck werden verschiedene Compilerwerkzeuge eingesetzt, die aus dem Programmcode einen Syntaxbaum extrahieren und den Code in die gewünschte abstrakte Darstellung transformieren. Um verschiedene Eingabespra- chen zu unterstützen, muss das Werkzeug zudem eine separate Spezifikation der Gram- matik der Eingabe ermöglichen. Für die genannten Anforderungen existiert eine große Bandbreite verschiedener Systeme3.

5.3.1 Compilerwerkzeuge

Zur Realisierung der notwendigen Transformationen des inkrementellen Transformati- onsprozesses wurden verschiedene Compilerwerkzeuge im Hinblick auf ihre Eignung zur Transformation von Programmcode evaluiert. Dabei stellte sich TXL4 als am besten geeignetes Tool heraus, da der Einarbeitungsaufwand in die Sprache gegenüber um- fangreichen und komplexen Werkzeugen, wie ANTLR5, wesentlich geringer ist und die Eignung zur Transformation von Programmcode verschiedener Programmiersprachen in einer Vielzahl von Projekten bestätigt wurde [7].

TXL ist eine funktionale Texttransformationssprache. Abbildung 5.4 zeigt die allgemei- ne Funktionsweise von TXL. Ein TXL-Programm besteht aus einer Grammatik (Gram- matical Structure Specification) und Transformationsregeln (Structural Transformation Rules). Die Transformation einer Eingabe geschieht in drei Phasen: Im ersten Schritt, der Parse-Phase, wird die Eingabe (Original Source Artifact) in einen Syntaxbaum umge- wandelt. Anschließend wird der Baum in der Transform-Phase entsprechend der Trans- formationsregeln verändert. Im dritten Schritt, der Unparse-Phase, wird aus dem er- zeugten und modifizierten Syntaxbaum der Ausgabetext (Transformed Source Artifact) generiert. Zur Transformation können bestehende Grammatiken für verschiedene Pro- grammiersprachen wie C#, ANSI C++ 3.0, Java, PHP und Delphi genutzt werden, was die Entwicklung eigener Transformationsregeln für den Programmcode dieser Sprachen wesentlich erleichtert. 3http://catalog.compilertools.net/ 4http://www.txl.ca/ 5http://www.antlr.org/

62 rule vectorizeScalarAssignments 5.3 Toolunterstützung der Verarbeitung der Transformation replace [repeat statement] V1 [variable] := E1 [expression]; V2 [variable] := E2 [expression]; RestOfScope [repeat statement] TXL Program

where not Grammatical Structure Structural E2 [references V1] Specification Transformation Rules where not E1 [references V2]

by < V1,V2 > := < E1,E2 > ; Original TXL Transformed RestOfScope Source Source end rule Artifact Processor Artifact Figure 1. Simple Example TXL Transformation Rule. The replace clause gives the pattern for which the rule AbbildungFigure 5.4: 2. AllgemeineThe TXL Processor. Funktionsweise von TXL nach [15]. searches by example in actual source text, binding names to parts (such as the [expression]s) which may vary in each The TXL Processor automatically implements source instance. The by clause gives the transformed result in similar transformations written in the TXL language. style, using the bound names to transfer parts Seitfrom the 2002 matc isthed TXL als FreeTXL frei verfügbar und wird sowohl an Universitäten als auch pattern. The where clauses specify additional semantic constraints on when the rule can be applied. in Softwareunternehmen eingesetzt. Die Sprache ist sehr gut dokumentiert u. a. in der Programmreferenz [14] (aktuell für die Version 10.5). Ein kurzer Überblick soll auch hier angegeben werden: 2.1. The TXL Processor 2.2. Grammatical Notation - Specifying Source Structure The TXL processor is a compiler and run time system for the TXL programming language that directlyTXL-Grammatikdefinition interprets TXL TXL uses a BEineNF-like Grammatikdefinition grammatical notation to speci istfy für sourc dene Eingabetext (bzw. programs consisting of a grammatical specification of the structure (Figure 3). In order to keep the notation lightweight structure of the input text and a rooted denset of Eingabeprogrammcode) structural and in a by-e notwendigxample style, undterminal wird symbo in einemls of the EBNF-ähnlichen input, for (erweiter- transformation rules to implement a souterce Backus-Naur-Form) to source example Stil opera notiert.tors, sem Einzelneicolons, ke Definitionenywords and the l werdenike, appea mitr einer define- transformation. The result is a rapid prototyAnweisungpe of the sourc vorgenommen.e simply as th Alternativeemselves. Quo Möglichkeitenting of terminal symb werdenols is allo durchwed „|“ getrennt und transformer described by the rules that can be used immediately but not required except in cases where terminal symbols of the on real input (Figure 2). können Terminal- undtarget (zu langu spezifizierende)age are keywords orNichtterminalsymbole special symbols of TXL itsenthalten.elf. Nichttermi- nalsymbole werdenRefe dabeirences in to eckigen nonterm Klammerninal types de verwendet.fined elsewher Dase in ausgezeichnetethe Nicht- terminal [program]grammarwird app alsear Startsymbol in square bracket verwendet.s [ ]. The u Nebensual set diesemof BNF sind noch weitere Nichtterminalsymbole vordefiniert: define program % goal symbol comments [expression] % of the grammar• [id] für Bezeichner /* (Folge*/ von Buchstaben, Ziffern oder _, beginnend mit Buch- end define // stabe oder _);end comments define expression % general [term] % recursion• [number] fürcompounds Ganz- oder Fließkommazahlen; | [expression] + [term] % & ambiguity[stringlit] := <= >= -> <-> | [expression] – [term] % supported• end compoundsfür Zeichenketten, die zwischen doppelten Anführungsstrichen end define " stehen; tokens define term • [charlit] für hexnumber Zeichenketten, "0[Xx][\dABCDEFabcdef]+" die zwischen einfachen Anführungsstrichen ’ [primary] end tokens | [term] * [primary] stehen; | [term] / [primary] keys end define • [comment] für program Kommentare. procedure function repeat until for while do begin 'end define primary [number] end keys opt repeat | ( [expression] ) Häufigkeiten und Aufzählungen werden u. a. mit den Modifikatoren , end define und list (durch KommaFigure 4. getrennt)Specifying Lexical angegeben. Forms in EineTXL. Unterscheidung, ob z. B. bei der repeat-Anweisung mindestens ein Vorkommen notwendig ist oder nicht, ist durch ein Figure 3. Simple Example of a TXL Grammar. Lexical forms specify how the input text is to be partitioned into angehängtes „+“ möglich:the termi[repeatnal symbols (toke nonterminal+]ns) of the source langudefiniertage. The z. B. eine nicht-leere Terminal symbols such as +, -, *, / and the paFolgerentheses von in nonterminalthe comments -Ausdrücken.section specifies Dacommenting die Modifikatoren conventions of auch the in eckigen Klam- definitions above represent themselves. References to input language, the compounds and tokens sections how nonterminal types are denoted by square mernbracke genutztts, as in werden,sequence ist dorts of diecharacte Angabers are vonto be Terminalsymbolen grouped into terminal durch ein führendes [expression] above. TXL comments begin withApostroph % and contin möglich.ue symbols, and the keys section specifies which symbols are to be to the end of the line. considered keywords rather than identifiers. Die Angabe von Schlüsselwörtern der zu definierenden Sprache geschieht in einem keys-Block. Äquivalent geschieht die Definition von Kommentarblöcken in einem comments-Block. Pro Zeile ist eine Angabe möglich, die Angabe einer Zeichenket- te wird als Trennzeichen eines bis zum Zeilenende gehenden Kommentars verstanden.

63 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

Die Angabe von zwei Zeichenketten wird als Anfangs- und Enddefinition eines (mehr- zeiligen) Kommentars gelesen. Mittels redefine kann die Definition einer importieren Grammatik verfeinert oder komplett verändert werden, ohne die Grammatik selbst verändern zu müssen. Der fol- gende Ausschnitt aus einer vereinfachten TXL-Grammatikdefinition der Programmier- sprache Java veranschaulicht die Prinzipien: comments % Kommentare werden beim Einlesen ignoriert // % Einzeilige Kommentare bis zum Zeilenende /∗∗ / % Mehrzeilige Kommentare end comments keys % Schlüsselworte der Eingabesprache (’ leitet Literale ein) ’class ’private ’public % Auswahl von Schlüsselworten in Java ’interface ’if ’else ’for end keys define program %reserviertes Startsymbol der Grammatik; Aufbau einer Java-Datei [opt package_decl] % 1. Deklaration des Namensraums (optional) [repeat import_decl] % 2. Import Deklarationen (beliebig viele, auch keine) [repeat type_decl] % 3. Deklaration von einer beliebigen Anzahl von Klassen, end define % Interfaces, etc. define package_decl % Definition eines Namensraums; beginnt in Java mit dem ’package [qualified_name] ’; % Schlüsselwort package, gefolgt von einem qualifizierten Namen end define % z. B. package org.transbs.transformr; define import_decl % Definition einer Import Deklaration; Java Schlüsselwort import ’import [opt ’static] % Importiert alle statischen Variablen und Methoden [qualified_name] ’; % einer bestimmten Klasse | ’import [qualified_name] ’.∗ ’; % Import aller Klassen eines Packages ohne qualifizierten Namen end define define type_decl % Definition eines Nichtterminals für Typ-Deklarationen [class_decl] | [interface_decl] | [enum_decl] end define define class_decl % Definition eines Nichtterminals zur Deklaration einer Klasse [repeat modifier] % Modifier: z. B. public, abstract ’class [class_name] % Schlüsselwort class und Name der Klasse [opt extends_clause] % optionale Superklasse [opt implements_clause] % optionale Interfaces, die durch die Klasse implementiert werden [class_body] % Körper der Klasse (z. B. Methoden, Membervariablen, etc.) end define

TXL-Transformationsdefinitionen Transformationen werden durch Funktionen und Regeln definiert. Eine Funktion ersetzt ein Nichtterminalsymbol durch eine andere mögliche Ableitung. Eine Ableitung beschreibt eine Folge von Terminal- und Nichtter- minalsymbolen, die aus dem Nichtterminalsymbol mittels der Grammatik erzeugt wer- den kann. function name replace [type] pattern by replacement [nextfunction] end function

Die Funktion name wird auf das erste Vorkommen des Nichtterminals type angewen- det, das der Ableitung pattern entspricht. Bei der Anwendung wird die Ableitung

64 5.3 Toolunterstützung der Verarbeitung der Transformation

pattern durch replacement ersetzt. In replacement können weitere TXL- Funktionen aufgerufen werden (nextfunction), die auch Übergabeparameter be- sitzen können. Wird statt des Schlüsselworts function das Schlüsselwort rule ver- wendet, wird die Ersetzung auf alle Nichtterminale des Typs type angewendet, die die Ableitung pattern besitzen. Die Transformationsregeln werden ausgehend von einer Funktion main angewendet, die beginnend mit dem Startsymbol [program] weitere Regeln aufruft.

Das folgende Beispiel zeigt die Spezifikation von Transformationsregeln. Dabei wird der Namensraum einer Import-Deklaration, die nicht static deklariert ist, von transformation in transformr umbenannt. rule resolveImports replace [import_decl] % Ersetzung aller Import Deklarationen beginnend mit ’import % Schlüsselwort import ohne folgendes static Name [qualified_name] ’; % gefolgt von einem beliebigen qualifiziertem Namen by ’import % Ersetzung durch Anwendung der Funktion Name [replaceImportName] ’; % replaceImportName auf den qualifizierten Import-Namen end rule function replaceImportName replace [qualified_name] % Anwendung der Funktion auf einen qualifizierten Namen ’org.transbs.transformation % beginnend mit org.transbs.transformr Comps [repeat component] % und mit beliebigen Namen folgend (z. B. .gui.View) by ’org.transbs.transformr Comps % Ersetzung durch eine Umbenennung des Namensraums end function % transformation durch transformr

Mit Hilfe der Transformationsregeln wurden im Transformationswerkzeug TRANS- FORMR verschiedene Programmcodetransformationen realisiert. Beispiele sind die Ex- traktion der FSR aus Programmcode (Abschnitt 6.2) und die Auslagerung von Funktio- nalität (Abschnitt 9.2).

Vorgehen beim Transformieren zwischen verschiedenen Sprachen Um Programmcode in eine andere Sprache zu transformieren, muss die Grammatik beide Programmiersprachen als Eingabe akzeptieren, da während der Transformation Kon- strukte aus Quell- und Zielsprache nebeneinander existieren. Dabei wird folgendes Vor- gehen empfohlen:

1. Erstellen der Grammatiken für die Quell- und die Zielsprache, so dass kein Nicht- terminal mehrfach existiert; 2. Festlegen einer Menge von Nichtterminalen, die als Transformationssymbole ge- nutzt werden sollen, und Erzeugen einer gemeinsamen Transformationsgramma- tik mit eben diesen gemischten Nichtterminalen; 3. Definition der Transformationsregeln, die die definierten Nichtterminale nutzen.

Für die Quellsprache C++ und die Zielsprache Java könnte man den Nichtterminalen der beiden Grammatiken den Prefix C_ bzw. J_ voranstellen. Da beide Sprachen in vielen Syntaxdetails Gemeinsamkeiten haben, ist es möglich, eine relativ kleine Menge

65 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems an Nichtterminalen zu identifizieren, mit der alle notwendigen Transformationen vor- genommen werden können. Die gemeinsame Transformationsgrammatik wird erzeugt, indem sie für die ausgewählten Nichtterminale wie folgt definiert wird:

% Übergeordnetes Nichtterminal beider Programmiersprachen, das in den Transformationsregeln verwendet wird define expression [C_expression] % besteht aus Ausdrücken in C++ | [J_expression] % und Ausdrücken in Java end define redefine C_expression % Erweiterung der Ausdrücke von C++ ... % Übernahme der bestehenden C++ Ausdrücke | [expression] % Hinzunahme der allgemeinen Regeln end redefine redefine J_expression % Analoge Vorgehensweise für Ausdrücke in Java ... | [expression] end redefine define program % Deklaration eines neuen Startsymbols für [C_program] % die Transformationsgrammatik | [J_program] end define

Für das Transformationswerkzeug TRANSFORMR bietet TXL eine hervorragende Grundlage zur Realisierung der notwendigen Transformationen zur Erzeugung des Soft- waremodells (Model-to-Code), zur Veränderung des Modells (Model-to-Model) mit zu- gehörigem Programmcode und zur Generierung des Programmcodes für das Zielsystem (Model-to-Code). Die konkrete Anwendung von TXL wird in Kapitel 6 beschrieben.

5.3.2 Visualisierungswerkzeuge

Die grafische Darstellung der Struktur der zu verarbeitenden Software, von Bestand- teilen der Software oder auch von Metrikauswertungen hat eine große Bedeutung für die Akzeptanz und Nutzbarkeit der Transformationssoftware. Daher bestand vorab die Aufgabe, eine geeignete Bibliothek oder extern aufrufbare Software zu finden, die die- se Visualisierungsentwicklung unterstützt. Hauptaspekt ist die Darstellung von Graphen bspw. zur UML-Darstellung der Klassenstruktur, die sehr groß werden kann. Eine Dar- stellung, die es vermeidet, dass sich Kanten gehäuft kreuzen, ist hier sehr wünschens- wert.

Es wurden folgende freie Werkzeuge zur Visualisierung beliebiger Graph-Strukturen evaluiert:

• JGraph6 [3] ist eine umfangreiche, interaktive, quelloffene Java-Swing-Kompo- nente. Die Software ist gut dokumentiert und einfach an eigene Anforderungen anzupassen. Allerdings sind keine Algorithmen zur Positionierung der Knoten von Graphen frei verfügbar.

6http://www.jgraph.com/

66 5.3 Toolunterstützung der Verarbeitung der Transformation

• GraphViz7 [19] ist ein ebenfalls quelloffenes Paket, das von AT&T und den Bell- Labs entwickelt wird. Diese Software ist in C geschrieben und enthält mehrere Render-Engines zur Knotenpositionierung sowie vielfältige Konfigurationsmög- lichkeiten der Darstellung von Kanten und Knoten. Eine interaktive Java-Imple- mentierung namens Grappa wird seit 2004 nicht mehr weiterentwickelt, so dass die Software auf der entsprechenden Plattform jeweils nativ gerufen werden muss oder von Java aus mittels des Java Native Interface8 (JNI) genutzt werden kann. • Mit dem Graphical Editing Framework9 (GEF) und dessen Plugin Draw2D [36] existiert eine weitere Java-basierte Lösung zur grafischen Visualisierung diver- ser Graphstrukturen, die zusätzlich Schnittstellen für eine interaktive Anpassung bietet. GEF ist jedoch in die Eclipse-Umgebung integriert und hat u. a. Abhän- gigkeiten zum EMF-Datenmodell. Eine Nutzung bietet sich vor allem dann an, wenn das zu entwickelnde Transformationswerkzeug als Eclipse-Plugin realisiert werden soll.

Für die Realisierung verschiedener Visualisierungen im Transformationswerkzeug wur- de das GraphViz-Paket gewählt, da die Darstellungsmöglichkeiten für einen Prototyp ausreichend sind und die einfache Schnittstelle und die freie Verfügbarkeit eine einfa- che Integration ermöglichen.

7http://www.graphviz.org/ 8http://java.sun.com/javase/6/docs/technotes/guides/jni/index.html 9http://www.eclipse.org/gef/

67 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

68 6 Entwicklung und Realisierung des Transformationssystems

Die Planung der Softwareentwicklung des Transformationssystems erfolgte vor allem in Hinblick auf Weiterentwicklung und breiten Einsatz des Werkzeugs. Die Unterstützung einer Vielzahl von Plattformen war somit wesentliches Entscheidungskriterium sowohl bei der Auswahl von Entwicklungsumgebung und Programmiersprache als auch bei der Evaluierung von existierenden Werkzeugen zur Unterstützung der Analyse und Trans- formation von Legacy-Software.

Die Standardisierung und Verbreitung der Java Virtual Maschine (JVM) und der Java Programming Language (Java) führten zur Wahl der Java Plattform zur Realisierung des Transformationssystems. Die Loslösung der Programmiersprache von der jeweili- gen Architekturplattform und die damit verbundene Portabilität ist ein Alleinstellungs- merkmal von Java und damit zur Entwicklung eines Transformationswerkzeugs für den breiten Einsatz sehr gut geeignet. Darüber hinaus existieren für Java eine Vielzahl von Bibliotheken, die für einzelne Lösungen herangezogen werden können.

Tabelle 6.1: Unterstützte Betriebssysteme des Laufzeitsystems und der genutzten Werk- zeuge des Transformationssystems.

Java, JVM TXL GraphViz Linux x86/x86_64 x/x x/x x/x Windows XP/Vista/2008 x/x/x x/x/x x/x/x Mac OS (10.5) x x x Solaris 32/64 x/x x/- x Linux PPC x x x

Tabelle 6.1 zeigt, dass eine Unterstützung der Laufzeitumgebung und der genutzten Werkzeuge für alle gängigen Betriebssysteme gegeben ist. Allein das Transformations- werkzeug TXL ist für 64-Bit-Betriebssysteme noch nicht verfügbar. Dieses Manko kann jedoch durch vorhandene 32-Bit-Emulationen ausgeglichen werden. Durch die Wahl dieser Werkzeuge kann das Transformationssystem somit für alle weit verbreiteten Be- triebssysteme unabhängig realisiert werden.

Ein weiteres wesentliches Merkmal des realisierten Transformationssystems stellt Er- weiterbarkeit dar, um neue Funktionalitäten basierend auf schon implementierten Analyse- und Transformationsbausteinen einfach zu ermöglichen. Erweiterbarkeit kann durch eine komponentenbasierte oder Plugin-Architektur realisiert werden. Dafür stehen

69 6 Entwicklung und Realisierung des Transformationssystems für Java verschiedene Spezifikationen und Frameworks zur Verfügung. Die OSGi Al- liance1, ein weltweites Konsortium unterschiedlicher IKT-Unternehmen (Informations- und Kommunikationstechnologie), spezifiziert eine umfangreiche hardwareunabhängi- ge dynamische Softwareplattform, die es erleichtert einzelne Module über ein Kom- ponentenmodell zur Laufzeit zu verwalten. Die OSGi stellt dabei jedoch nur eine Re- ferenzimplementierung zur Verfügung, die je nach Anwendungsfall angepasst werden muss. Die Entwicklungsumgebung Eclipse2 basiert beispielsweise auf einem OSGi-Fra- mework namens Equinox. In der Spezifikation sind neben der Komponentenverwaltung auch Versions- und Sicherheitsaspekte integriert. Eine Basis für die Verwaltung von Komponenten bietet auch das Java Plug-in Framework3 (JPF). Dieses beinhaltet ver- schiedene Dienste zur Verwaltung von Plugins und ihrer Abhängigkeiten und ermöglicht damit die Bildung modularer Anwendungen.

Da die Realisierung einer Architektur auf Basis von Komponenten oder Plugins zwar das Hinzufügen neuer Funktionalitäten erleichtert, aber das Verändern bzw. Verschieben von Funktionalität immer mit einer Änderung der äußeren Schnittstellen einhergeht, wurde zur Implementierung des Prototypen auf eine explizite Plugin- oder Komponentenar- chitektur verzichtet. Die Bestandteile des Transformationssystems wurden zu Modulen (siehe Abbildung 4.3) zusammengefasst, deren Schnittstellen eine einfache Anpassung ermöglichen und eine spätere Umwandlung in eine Komponenten- oder Plugin-Archi- tektur erlauben.

6.1 Realisierung des Transformationssystems TRANSFORMR

6.1.1 Inkrementeller Transformationsprozess

Die Realisierung eines Systems zur Transformation monolithischer Business-Soft- ware in eine modulare, skalierbare Client-Server-Architektur setzt individuelle Transformations- und Migrationsstrategien voraus. Ziel war aus diesem Grund die Um- setzung eines einfach erweiterbaren Transformationssystems zur Unterstützung ver- schiedener Ausgangs- und Zielplattformen. Das entwickelte Toolset TRANSFORMR ba- siert auf einem dreistufigen Prozess, der die Anforderungen an das Transformations- system umsetzt. Zur Realisierung der unterschiedlichen Transformationstypen (Code- to-Code, Code-to-Model, Model-to-Code) wird ein Language Transformation Proces- sor (LTP) eingesetzt, der die Transformationen mit Hilfe einer Grammatik der Einga- be und Transformationsregeln umsetzt. Als LTP wurde für das TRANSFORMR-Toolset TXL (vgl. Einführung in Abschnitt 5.3) gewählt. Abbildung 6.1 zeigt den Transforma- tionsprozess, wie er im Toolset TRANSFORMR mit folgenden Transformationsphasen implementiert ist:

1http://www.osgi.org/ 2http://www.eclipse.org/ 3http://jpf.sourceforge.net/

70 6.1 Realisierung des Transformationssystems TRANSFORMR

Target Model

Logical Logical Structure Structure

Target Legacy Flexible Software Target consists Flexible Software consists Software Representation Software of Representation of System (FSR) System (TFSR)

Source Source Code Code

Extraction Transformation Code Generation

Abbildung 6.1: Realisierung des Transformationsprozesses im Toolset TRANSFORMR.

• Im ersten Schritt (Extraction) wird der Legacy-Programmcode und seine Struktur analysiert und in die Flexible Software Representation (FSR) umgewandelt. Der Legacy-Programmcode besteht aus einer großen Anzahl Dateien, die in verschie- denen Verzeichnissen abgelegt sind. Mit Hilfe des LTP TXL wird aus jeder Einga- bedatei ein abstrakter Syntaxbaum des Programmcodes generiert und eine XML- basierte Zwischendarstellung extrahiert. Durch Zusammenfügen der extrahierten Zwischendarstellungen der Eingabedateien wird die vollständige FSR erzeugt.

• In der Phase Transformation können durch Interaktion mit dem Nutzer verschie- dene Transformationen auf die erzeugte FSR angewendet werden. Die Transfor- mationen teilen sich in Basistransformationen, wie Umbenennen, Erzeugen oder Verschieben einzelner Softwareelemente, und zusammengesetzte Transformatio- nen, die aufbauend auf den Basistransformationen mehrstufige umfassende Trans- formationen darstellen. Beispiele zusammengesetzter Transformationen sind die Verschiebung zusammengehöriger Gruppen von Eigenschaften und Methoden (Member) einer Klasse (Abschnitt 6.3) und die Auslagerung von Funktionalität auf entfernte Rechner (Abschnitt 6.4). In diesem Schritt sind verschiedene Sich- ten mit verschiedenen Metriken der aktuellen Softwarerepräsentation möglich, um den Einfluss unterschiedlicher Transformationen zu bestimmen. Zur Auswahl ge- eigneter Transformationen ist ein Konzept des Zielmodells bzw. der Zielarchi- tektur notwendig, das in Abbildung 6.1 als Target Model dargestellt ist. Nach inkrementeller Anwendung der verfügbaren Transformationsoperationen auf die FSR entsteht die Target Flexible Software Representation (TFSR), die das Ziel- system auf Modellebene beschreibt.

• Der letzte Schritt Code Generation erzeugt ausgehend von der TFSR (mit den verwendeten Transformationen) und dem bestehenden Legacy-Code den Pro- grammcode für das Zielsystem. Auch in diesem Schritt wird wiederum der LTP TXL verwendet, um aus der Zwischendarstellung Programmcode zu generieren bzw. den bestehenden Programmcode mit den gewählten Transformationen anzu- passen.

71 6 Entwicklung und Realisierung des Transformationssystems

Architectural Model Transformation Representation FSR TFSR Layer

language language language language Transformation AST Transformation dependent dependent dependent dependent Layer AST AST AST AST

annotated annotated Annotated Code Transformation annotated annotated Code Layer source code file target code file source code file target code file

Code source code file target code file Layer source code file target code file

Legacy System Target System

Abbildung 6.2: Abstraktionsebenen die im Transformationsprozess des Toolsets TRANSFORMR durchlaufen werden.

Der Transformationsprozess arbeitet auf verschiedenen Abstraktionsebenen, die in Ab- bildung 6.2 dargestellt sind. Der Code Layer beinhaltet den ausführbaren Programm- code der Legacy-Software und der Zielsoftware und bildet die Basisebene des Trans- formationsprozesses. Im Annotated Code Layer werden den Softwareelementen des Programmcodes Annotationen hinzugefügt, um Modellelemente und Codeelemente ein- deutig referenzieren zu können (beispielsweise lokale Variablen oder einzelne Anwei- sungen). Der Transformation Layer enthält abstrakte Syntaxbäume des annotierten Codes, die mit geeigneten Regeln sowohl horizontal (Code-to-Code) als auch verti- kal (Code-to-Model, Model-to-Code) transformiert werden können. Die oberste Ebene (Architectural Representation Layer) enthält die Modellbeschreibung des Programm- codes (FSR und TFSR). Diese Beschreibung ist unabhängig von der im Code Layer verwendeten Programmiersprache und bildet die Basis für verschiedene Sichten auf das Legacy-Softwaresystem. Die Realisierung der Abstraktionsebenen basiert auf dem Horseshoe Model von Kaz- man et al. [31]. In diesem Modell werden die Schichten Source Text (Programmcode), Code-Structure (ASTs), Function-Level (Module) und Architectural Concepts (Design Patterns) unterschieden und analog der oben beschriebenen Abstraktionsebenen zur Ver- einfachung der Transformationen für den Nutzer genutzt. Die Ebenen Function-Level und Architectural Concepts sind im Transformationsprozess in der Schicht Architec- tural Representation Layer zusammengefasst. Die Transformation Layer entspricht im Horseshoe Model der Ebene Code-Structure und die zwei Ebenen Code Layer und An- notated Code Layer werden durch die Ebene Source Text repräsentiert.

6.1.2 Flexible Software Representation (FSR)

Die Flexible Software Representation stellt die zentrale Schnittstelle zu Aufbau und Metainformationen der Legacy-Software dar. Abbildung 6.3 zeigt den strukturellen Auf- bau des Modells zur Repräsentation von Software in einer objektorientierten Program-

72 6.1 Realisierung des Transformationssystems TRANSFORMR

Node Abstrakte Basisklasse Annotation Program aller FSR-Elemente 1 1 Referenzierung der FSR- + subsystems: SubSystem* + name: String Elemente im Programmcodes + annotation: Annotation 1 + semantics: Semantic 1 * 1 Semantic * SubSystem Semantische Beschreibung 1 + subsystems: SubSystem* des FSR-Elements + modules: Module* + classification: NODE_CF + description: String 1 * Module LocalModule 1 + modifiers: Modifier* * 1 Statement in dem eine 1 + procedures: Procedure* lokale Klasse definiert wird + variables: Variable* + module: Module 1 * * Modifier Procedure BlockStatement Statement + PUBLIC * 1 + modifiers: Modifier* 1 * Komplexes Statement: Abstrakte Basisklasse + PRIVATE + variables: Variable* if, for, while, etc. für beliebige Statements * ... + codeblock: BlockStatement + codeblocks: CodeBlock* * 1 1 * SimpleStatement * Variable LocalVariable Zuweisung oder + modifiers: Modifier* Statement in dem eine lokale 1 * 1 Methodenaufruf + type: Module Variable definiert wird + dependencies: Dependency* + dependencies: Dependency* + variable: Variable + modules: Module* * 1 1 1 1 * CodeBlock * + type: CODEBLOCK_TYPE Dependency * + dependencies: Dependency* * Abstrakte Basisklasse + variables: Variable* 1 * für Abhängigkeiten + statements: Statement* 1 + calleeNode: Node + codeblocks: CodeBlock* + calledNode: Node + anonymousMods: Module*

ModuleDependency ProcedureDependency VariableDependency + writeAccess: boolean

Abbildung 6.3: Softwaremodell (Vereinfachung) der Flexible Software Representation (FSR) des Toolsets TRANSFORMR als UML-Klassendiagramm. miersprache. Die Legacy-Software wird darin in einer Graphstruktur dargestellt, deren Basiselement ein Program-Knoten ist. Ein Program-Knoten besitzt beliebig viele Sub- System-Kindknoten, die wiederum Module als Platzhalter für Klassen und Interfaces beinhalten. Die weiteren Knoten repräsentieren die Modellelemente für Methoden (Pro- cedure) und Membervariablen (Variable) von Klassen, sowie Elemente zur Repräsen- tation von Codeblöcken (CodeBlock) und einzelner Statements (Statement). Abhängig- keiten werden einerseits durch die abstrakte Basisklasse Dependency mit ihren Realisie- rungen ProcedureDependency (Aufruf einer Methode), VariableDependency (Nutzung einer Membervariable) und ModuleDependency (Abhängigkeit zu einer Klasse, bspw. Cast) als auch durch Referenzen von Modulen zu Modulen (Generalisierung, Realisie- rung) abgebildet.

Jeder Knoten des Softwaregraphen stellt eine Realisierung der abstrakten Basisklasse Node dar und besitzt Referenzen zu Annotationsinformationen (Annotation) und se-

73 6 Entwicklung und Realisierung des Transformationssystems

Abbildung 6.4: Links: Nutzerschnittstelle des TRANSFORMR Toolsets (FSR der Software jEdit). Rechts: Metrik-Dialog für eine ausgewähltes SubSystem im FSR Baum (MOOD-Metriken für das Package org.git.sp.jedit.browser). mantischen Informationen über den Knoten (Semantic) wie beispielsweise Kommentare. Innerhalb der Module verfügen die Modellelemente über eindeutige Bezeichner (Anno- tation), die auch im annotierten Programmcode (Annotated Code Layer, Abbildung 6.2) enthalten sind. Über die Annotation kann der Programmcode für jedes Modellelement referenziert werden (z. B. der Programmcode eines Statements).

6.1.3 Nutzerschnittstelle des Transformationssystems

Die grafische Nutzerschnittstelle des Toolsets TRANSFORMR zeigt Abbildung 6.4. Im Hauptfenster wird der Aufbau der Legacy-Software hierarchisch in einem Baum darge- stellt (links). Jeder Knoten bietet kontextsensitiv verschiedene mögliche Transformatio- nen (Refactor) und Sichten (View) an. Über die Menüleiste kann aus bestehendem Pro- grammcode eine neue FSR erzeugt werden bzw. eine bestehende (transformierte) FSR gespeichert werden (File). Darüber hinaus besteht die Möglichkeit zur Anzeige allge- meiner Sichten (View) und die Verwaltung durchgeführter Transformationen (Transfor- mation). Für jedes Element sind im Toolset verschiedene Metriken realisiert, die bspw. den Bindungsgrad von Modulen eines SubSystems (Coupling Factor, Abbildung 6.4, rechts), die Kapselung einer Klasse oder die Komplexität von Mehoden bestimmen.

Ein Beispiel für eine Sicht auf die Legacy-Software ist die Module Structure View (Ab- bildung 6.5). Für diese Ansicht werden Subsysteme oder Module einzelner Subsysteme zu Metakomponenten, sogenannten Module Structures, zusammengefasst. Die Meta- komponenten stellen eine mögliche Komponentenbildung der Legacy-Software dar, die unabhängig von bestehenden Komponenten gebildet werden kann. Die Module Struc- ture View stellt die Anzahl der Abhängigkeiten zwischen den Metakomponenten als Graphstruktur dar. Die Ansicht ist vom Nutzer interaktiv steuerbar und bietet verschie- dene Möglichkeiten der detaillierten Untersuchung der Abhängigkeiten über einen Pro- perties-Dialog (Mitte rechts). Zunächst können im Hauptfenster des Views Zyklen im

74 6.1 Realisierung des Transformationssystems TRANSFORMR

Abbildung 6.5: Graph Dependency View des TRANSFORMR Toolsets zur Identifikation von Abhängigkeiten zwischen Komponenten.

Graphen farblich hervorgehoben werden. Hierbei können auch einzelne Kanten von der Ermittlung der Kreise ausgeschlossen werden, um die Ansicht durch Verringerung der Anzahl dargestellter Kanten zu vereinfachen. Die Analyse und Beseitigung dieser zir- kulären Abhängigkeiten zwischen Komponenten stellt für die Bildung eines modularen Designs einen wichtigen Zwischenschritt dar, da diese Abhängigkeiten häufig Ursache für Probleme bei der Änderung beteiligter Komponenten sind. Eine Untersuchung der Abhängigkeiten zwischen zwei Metakomponenten bietet die Package Dependency Pair View (links unten). Nach Modulen geordnet werden hier die Abhängigkeiten zu einer Zielkomponente (Target package) textuell beschrieben dargestellt. Zusätzlich können verschiedene Filter auf den Graphen angewendet werden, so dass bestimmte Typen von Abhängigkeiten nicht dargestellt werden. Beispielsweise können so Abhängigkeiten zu Konstanten bzw. Klassen, die nur Konstanten enthalten, oder auch Abhängigkeiten zu Interfaces, die an unterschiedlicher Stelle in der Legacy-Software auftreten können, aus- geblendet werden. Durch die schrittweise Reduzierung der Abhängigkeiten kann der Module Structure View vereinfacht werden, was einen einfacheren Überblick über die Abhängigkeiten von Komponenten der Legacy-Software erlaubt. Eine genauere Analy- se der ausgeblendeten Abhängigkeiten kann im Removed Dependencies-Dialog vorge- nommen werden (rechts unten).

Aus der Analyse der Abhängigkeiten können sich notwendige Transformationen (bei- spielsweise Verschiebungen) ergeben, die bestehende Strukturen der Legacy-Software

75 6 Entwicklung und Realisierung des Transformationssystems verbessern. Mögliche Transformationen können mit dem Toolset auf Modellebene vor- genommen werden, so dass vom Zugriff auf den tatsächlichen Programmcode abstra- hiert werden kann.

Im TRANSFORMR Toolset sind weitere Sichten auf die FSR, wie Aufrufdiagramme (z. B. Abbildung 6.9) oder UML-Klassendiagramme (z. B. Abbildung 6.11) auch von Teilen des Softwaremodells, realisiert. Zur Ermittlung verschiedener Kennzahlen, wur- den Metriken aus den Sammlungen Metrics for Object-Oriented Design (MOOD), Me- trics for Object-Oriented Software Engineering (MOOSE) und Quality Metrics for Ob- ject-Oriented Design (QMOOD) für eine Anwendung auf die FSR angepasst (Überblick über Metriken in [6]). Ausgewählte Metriken kommen beispielsweise in den Kompo- nentenbildungstransformationen (Abschnitt 6.3) zur Anwendung.

6.2 Metakomponenten des Transformationssystems

Wie in Abschnitt 5.3 beschrieben, existieren verschiedene Applikationen, die zur Rea- lisierung von Teilaufgaben des Transformationssystems verwendet werden können. Ge- genstand dieses Abschnitts ist eine Erläuterung, wie die Applikationen den Transforma- tionsprozesses unterstützen und welche Schnittstellen dabei genutzt werden können.

Der Aufruf externer Werkzeuge von einer Java-Anwendung kann über implementierte Schnittstellen in Java oder über Betriebssystemfunktionen erfolgen. Zum Aufruf nativer Bibliotheksfunktionen stehen Java Native Interface (JNI) und Java Native Access (JNA) zur Verfügung. JNI spezifiziert eine standardisierte Schnittstelle, für die ein plattformab- hängiges Interface generiert werden muss, und realisiert den Zugriff auf Funktionen über den Systemzugriff System.loadLibrary(..). Die Bibliothek muss dabei mit ei- ner aus der Schnittstelle generierten Headerdatei kompiliert werden. JNA dagegen ist eine zusätzliche Java-Bibliothek, die den Zugriff und auch die Konvertierung von Daten- typen ohne zusätzlichen (generierten) Programmcode ermöglicht. Darüber hinaus bietet Java die Möglichkeit Anweisungen über einen Systemruf auszuführen. Dieser Zugriff ist zwar einerseits langsamer als Aufrufe über JNI bzw. JNA, allerdings kann der Aufruf der externen Werkzeuge unabhängig vom verwendeten Betriebssysteme erfolgen, wenn die Schnittstellen der Tools für die unterschiedlichen Betriebssysteme einander entspre- chen.

Da die verwendeten Werkzeuge TXL und GraphViz als eigenständige Programme ver- fügbar sind, wurde für die prototypische Realisierung der Zugriff über Systemrufe be- vorzugt, der für die getesteten Betriebssysteme Linux und Windows keine Unterschiede in den Befehlszeilen aufwies und somit nach Installation ohne Anpassungen verwendet werden konnte. Sowohl TXL als auch GraphViz unterstützen als Ein- und Ausgabe Da- tenströme, was die Erzeugung zusätzlicher temporärer Dateien unnötig macht und eine direkte Serialisierung der Ein- und Ausgaben ermöglicht. Beispielhaft soll im Folgenden die Verwendung von TXL im Extraktionsprozess beschrieben werden.

76 6.2 Metakomponenten des Transformationssystems

package mypackage ; public class MyClass { p r i v a t e Work v a r ; < v a r i a b l e i d="var" type="mypackage.Work" a n n o t a t i o n − i d="0" /> p u b l i c void doSomething () { var.doWork (); } package mypackage ; /@stmt_id="0"@/ v a r/@dep_id="1"@/ . doWork/@dep_id="2"@/(); } }

Abbildung 6.6: Links: Originaler und annotierter (qualifizierter) Java Programmcode. Rechts: Extrahierte FSR-XML-Beschreibung des Programmcodes.

Bei der Extraktion der FSR aus dem bestehenden Programmcode treten Aufrufe von TXL in mehreren Phasen auf. Zunächst bei der Annotation des Programmcodes, um zwischen den zu erzeugenden Modellelementen und den Programmelementen eindeuti- ge Referenzen herzustellen. Des Weiteren bei der Ersetzung der lokalen Datentypen mit ihren global qualifizierten Bezeichnern und schließlich bei der eigentlichen Extraktion der XML-FSR-Struktur aus dem annotierten und qualifizierten Programmcode.

Abbildung 6.6 zeigt die schrittweise Bildung der FSR aus einem Programmcode in Ja- va. Zunächst werden im Programmcode lokale Typbezeichner durch qualifizierte globale Bezeichner ersetzt (der Typ der Membervariable var wird durch mypackage.Work ersetzt). Anschließend werden zu den Programmelementen Annotationen hinzuge- fügt. In Abbildung 6.7 werden links Ausschnitte aus den Erweiterungen der Gram- matik und notwendige Transformationsregeln für eine Abhängigkeitsannotation am Anfang eines Statements (z. B. /@dep_id="1"@/ in Abbildung 6.6) dargestellt. Notwendig für die Transformation ist die Erweiterung der Grammatik für Annota- tionen (redefine reference) und das anschließende Hinzufügen der Annota- tionen an allen definierten Positionen im abstrakten Syntaxbaum durch TXL (rule replaceReferenceStart).

Nach der Aufbereitung des Programmcodes erfolgt die eigentliche Extraktion der spra- chunabhängigen Zwischendarstellung. Abbildung 6.6 zeigt rechts die aus dem Pro- grammcode erzeugte FSR, die auch die hinzugefügten Annotationen enthält. Einen Aus- schnitt der Grammatikerweiterungen und Transformationsregeln für diese Transforma- tion zeigt Abbildung 6.7 rechts. Analog zum Hinzufügen von Annotationen muss die bestehende Grammatik für (annotiertes) Java um die XML-Strukturen der FSR für alle zu extrahierenden Elemente erweitert werden (redefine class_declaration). Darauf aufbauend werden die Transformationsregeln definiert, die den annotierten Pro-

77 6 Entwicklung und Realisierung des Transformationssystems

% Erweiterung der Grammatik um dep-Annotation % Erweiterung des Nichtterminals class_declaration redefine reference redefine class_declaration [id][dep_annotation] .. [repeat dimension][repeat component] |’ .. % Definition einer Referenz-Annotation ’ define dep_annotation end redefine ’/@ ’dep_id= [stringlit] ’@/ end define % Transformation einer java class_declaration in XML rule rp_class_declaration replace $ [class_declaration] % Hinzufügen der dep-Annotation für alle Referenzen M [repeat modifier] % qualifizierte Typbezeichner werden nicht annotiert ’classN [class_name] rule replaceReferenceStart E [opt extends_clause] skipping [type_specifier] I [opt implements_clause] B [class_body] replace $ [reference] construct Name [stringlit] ID [id] Dim [repeat dimension] _[quoteN ] RC [repeat component] construct Modifier [stringlit] construct Annotation [stringlit] _[quoteM ] _[getNextAnnotationDependency] import PACKAGE_NAME [stringlit] construct Marker [dep_annotation] construct Inherits [repeat inherits] ’/@ ’dep_id= Annotation ’@/ _[getInheritsEI ] by by ID Marker Dim ’<’module ’id=Name ’package=PACKAGE_NAME RC [markComponent] ’type="class" ’modifier= Modifier’ > [markClassCreation] InheritsB’ end rule end rule

Abbildung 6.7: Ausschnitt der Erweiterungen der Grammatik und Transformationsre- geln zum Hinzufügen von Annotationen zu Statements (links) und zur Extraktion eines Modules aus einer Klassendeklaration (rechts). grammcode in die XML-Struktur überführen (rule rp_class_declaration). Dabei wird von der Regel nur der XML Knoten module erzeugt. Alle Kindknoten die sich innerhalb der Klassendeklaration befinden (z. B. Variablen- oder Methodende- klarationen) werden mit weiteren Regeln transformiert.

Die erzeugte FSR stellt ein sprachunabhängiges Modell dar, das projektspezifisch je- doch eher auf objektorientierte Eingabesprachen zugeschnitten ist. Auf diesem Modell als Zwischendarstellung können verschiedene Restrukturierungen und andere Transfor- mationen durchgeführt werden, die im Folgenden detaillierter vorgestellt werden.

6.3 Realisierung prototypischer Komponentenbildungstransformationen

Ein wichtiger Teilbereich der Restrukturierung von Legacy-Business-Software ist die (Re-)Modularisierung von Software als Basis einer Migration von Legacy-Software für eine Ausführung in verteilten Umgebungen [48] oder zur Reduzierung ihrer Komplexi- tät [43]. Ziel der Modularisierung ist eine hohe Kohäsion (cohesion, starker Zusammen- halt von Elementen einer Einheit, z.B. von Klassen) und niedrige Kopplung (coupling,

78 6.3 Realisierung prototypischer Komponentenbildungstransformationen schwacher Zusammenhalt von Elementen unterschiedlicher Einheiten) [25]. Eine Spezi- fikation der Modularität eines Systems besteht aus der Beschreibung der Funktionalität der Komponenten und der Eingrenzung der Abhängigkeitsbeziehungen zwischen den Komponenten. Auf diese Weise können beispielsweise zirkuläre Abhängigkeiten von Komponenten vermieden werden, die eine Weiterentwicklung der beteiligten Kompo- nenten oftmals erschweren und ein Hinweis für ein falsches Architekturdesign sind.

Eine bestehende Spezifikation der Modularität einer Software kann durch Erweiterun- gen verletzt werden, die Änderungen an der bisherigen Architektur erfordern. Da die Spezifikation oft nur als zusätzliche Dokumentation zur Verfügung steht, eine zügige Anpassung der Software gewünscht ist oder ein Einblick in die gesamte Software auf Grund ihrer Größe nicht möglich ist, kann es zu falschen Designentscheidungen und da- mit zur Verletzung der ursprünglichen Modularität kommen. Eine ökonomisch tragbare Weiterentwicklung einer über Jahre gewachsenen Software ist nur durch eine Restruktu- rierung bzw. (Re-)Modularisierung möglich. Die kontinuierliche „Erosion“ des Designs wird auch als code decay [18] bezeichnet.

Der notwendige Prozess der (Re-)Modularisierung bringt das Risiko neuer Fehler durch manuelle Veränderung eines möglicherweise nicht vollständig überschaubaren Softwa- resystems mit sich. Für Entwickler ist daher eine Unterstützung durch Werkzeuge für wiederkehrende Transformationen vorteilhaft. Für die Modularisierung eines Software- systems sind vor allem Transformationen wichtig, die das Verschieben unterschiedlicher Elemente der Softwarearchitektur erlauben.

Im Bereich objektorientierter Sprachen können Verschiebungen auf verschiedenen Ebe- nen stattfinden. Die Verschiebung von Klassen zwischen Komponenten (z.B. packa- ges) bildet dabei die allgemeinste Transformation. Diese Verschiebetransformation wird von den meisten aktuellen Entwicklungsumgebungen (z.B. Eclipse, Delphi Professio- nal) funktionalitäts- und korrektheitserhaltend unterstützt. Durch eine Vermischung von Funktionalität verschiedener Komponenten ist es häufig notwendig auch Elemente in- nerhalb von Klassen wie Methoden oder Membervariablen in andere Klassen zu ver- schieben, um die gewünschte Modularität herzustellen. Durch die Bindung einer Me- thode an den jeweiligen Zustand der Klasse müssen bei einer Verschiebung in eine Zielklasse die Membervariablen, die das Ergebnis der Methode beeinflussen, ebenfalls in die Zielklasse verschoben oder von der Zielklasse aus zugänglich gemacht werden. Die Verschiebung der Membervariablen (oder weiterer genutzter Methoden der gleichen Klasse) ist nicht in jedem Fall möglich, da sie auch von anderen Methoden genutzt wer- den können. Diese Schwierigkeiten führen zu der Vorbedingung, dass eine Instanz der Zielklasse (mit dem entsprechenden Zustand) an jeder Stelle verfügbar sein muss, in der die zu verschiebende Methode der Ausgangsklasse aufgerufen wird. Da die Herstellung dieser Vorbedingung für jede Klasse, die die zu verschiebende Methode nutzt, indivi- duelle Transformationen benötigt, kann eine funktionalitäts- und korrektheitserhaltende Verschiebung nur in ausgewählten Fällen automatisch durchgeführt werden. Die Ver- schiebung wird daher meist nur für einfache Fälle (z.B. wenn die Methode keinerlei Ab- hängigkeiten zu anderen Methoden oder Membervariablen der Klasse besitzt) von den o.g. Entwicklungsumgebungen unterstützt. Der Versuch einer Verschiebung bei wenigen zusätzlichen Abhängigkeiten schlägt häufig fehl oder verändert die bisherige Kapselung

79 6 Entwicklung und Realisierung des Transformationssystems der Klasse, um beispielsweise den Zugriff auf Membervariablen oder -methoden aus der Zielklasse zu ermöglichen.

Die Verschiebung von Methoden zur Modularisierung wird auch von anderen Autoren betrachtet. Correia et al. [16] beschreiben ein Transformationssystem zur Trennung der Funktionalitäten von Nutzerschnittstelle, Business-Logik und Datenschnittstellen. Da- bei wird der Legacy-Programmcode durch verschiedene (semi-)automatische Regeln in vorhandene Kategorien eingeordnet und anschließend eine Trennung der Code-Katego- rien vorgenommen, die auch eine Verschiebung von Methoden beinhaltet. Die Autoren beschreiben die Verschiebung jedoch nur auf Modellebene (im Program Representati- on Graph, siehe Abbildung 5.2) und vernachlässigen die Betrachtung der tatsächlichen Abhängigkeiten der Methode und die über die Verschiebung hinaus gehenden Verände- rungen des Programmcodes. Tsantalis und Chatzigeorgiou [51] beschreiben eine Me- trik zur Berechnung der Distanz zwischen Methoden und Klassen. Das dort vorgestellte Transformationssystem schlägt dabei für jede Methode die Klasse als Zielklasse vor, zu welcher die ausgewählte Methode den geringsten Abstand hat. Das System ist als Eclip- se-Plugin realisiert und vermittelt die auszuführenden Verschiebetransformationen an die Refactoring-Engine von Eclipse weiter. Damit ist eine automatische Verschiebung, wie oben beschrieben, nur in wenigen einfachen Fällen möglich.

6.3.1 MemberGroups

Methoden besitzen zur Ermittlung ihres Rückgabewerts häufig Abhängigkeiten zu an- deren Membern (Membervariablen und -methoden) der Klasse. Aus diesem Grund be- trachten wir zusammengehörige Gruppen von Membern einer Klasse (MemberGroups [27]), die eine von den restlichen Membern der Klasse separierte Funktionalität darstel- len. Das Ziel der Verschiebung einer MemberGroup ist die Verbesserung der Modulari- tät, bei der sowohl die Funktionalität als auch die Integrität (Kapselung) der Klasse der MemberGroup erhalten bleibt.

Zur Definition einer MemberGroup werden die Elemente (Knoten) des Softwaremodells der FSR und besondere Abhängigkeitsbeziehungen (Kanten) zwischen den Elementen betrachtet (siehe Tabelle 6.2). Dazu wird aus der FSR ein Abhängigkeitsgraph aufge- baut, der sowohl die Abhängigkeiten zwischen Membern des Softwaresystems als auch die Zugehörigkeit eines Members zu einer Klasse abbildet (Beispiele siehe Abbildun- gen 6.9 und 6.10). Für die Spezifikation einer MemberGroup werden folgende Relatio- nen zwischen den Membern u und v definiert:

• dep(u, v): Abhängigkeit zwischen u und v, unabhängig von der Richtung der Ab- hängigkeit;

∗ • depU (u, v): Transitive Abhängigkeit zwischen u und v. Zwischen u und v existiert ein Abhängigkeitspfad (dep-Relationen) über Member aus der Menge U ⊆ M.

80 6.3 Realisierung prototypischer Komponentenbildungstransformationen

Tabelle 6.2: Knotenmengen und Kanten des Softwaremodells zur Ermittlung von Mem- berGroups. Beschreibung Definition

Menge aller Klassen ∆ = {C0,...,Cn} Menge aller Konstruktoren einer Klasse C Con(C) Menge aller Methoden einer Klasse C Meth(C) Menge aller Member-Variablen der Klasse C Var(C) Menge aller Member der Klasse CM(C) = Meth(C) ∪ Var(C) ∪ Con(C) S Menge aller Member des Projekts M = C∈∆ M(C)

Lese-, Schreib- oder Aufrufabhängigkeit u → v zwischen Member u und v (u 6= v) Ungerichtete Kante zwischen Member u und v dep(u, v) = (u → v) ∨ (v → u) u v Ungerichteter Pfad zwischen und innerhalb einer dep∗ (u, v) Untermenge aller Member U ⊆ M U

Ausgehend von diesen Definitionen wird eine MemberGroup MG(m) beginnend mit Member m ∈ Var(C) ∪ Meth(C) in Klasse C wie folgt definiert:

MG(m) = {m} ∪ {v ∈ (C) ∪ (C) | ∗ (m, v)} Meth Var depMeth(C)∪Var(C) (6.1) ∪ {u ∈ Con(C) | ∃t ∈ MG(m) mit dep(u, t)}.

Primärer Bestandteil einer MemberGroup MG(m) ist zunächst der Member m ∈ Meth(C)∪Var(C) selbst. Dazu werden alle Methoden und Membervariablen der Klasse C hinzugefügt, zu denen von m aus eine dep∗-Relation über alle Methoden und Mem- bervariablen der Klasse besteht. Abschließend werden alle Konstruktoren der Klasse C hinzugefügt, die eine dep-Relation zu MG(m) besitzen. Mit dieser Vorschrift werden schnittmengenfreie MemberGroups in einer Klasse C bzgl. ihrer Membervariablen und -methoden erzeugt, da nach Gleichung 6.1 jeder Member nur Teil einer MemberGroup sein kann. Konstruktoren von C können jedoch in mehreren MemberGroups auftreten.

Zur Untersuchung bestehender MemberGroups in Legacy-Softwaresystemen wurde der MemberGroup Browser aufbauend auf der FSR des Toolsets TRANSFORMR implemen- tiert. Er ermittelt die MemberGroups aus der Modellbeschreibung der Software und bie- tet verschiedene Möglichkeiten, die gefundenen MemberGroups zu filtern und darzu- stellen. Abbildung 6.8 zeigt links die Nutzerschnittstelle des Browsers, mit der über den FSR-Baum (links) MemberGroups aus bestimmten Bereichen der Legacy-Softwa- re angezeigt werden. Die angezeigten MemberGroups können danach mit verschiede- nen Filtern, wie beispielsweise der Größe der MemberGroups, eingeschränkt werden. Die dadurch entstandene Menge der MemberGroups (Resulting Membergroups) kann mit verschiedenen Diagrammen ausgewertet werden. Als Beispiel ist in Abbildung 6.8 rechts die Häufigkeit des Auftretens von MemberGroups verschiedener Größen darge- stellt, wobei die Größen 4–9, 10–19, etc. zur besseren Übersicht automatisch zusam- mengefasst werden.

81 6 Entwicklung und Realisierung des Transformationssystems

Abbildung 6.8: Links: TRANSFORMR MemberGroup Browser zur Analyse der Mem- berGroups eines Legacy-Softwaresystems. Rechts: Statistik der ausge- wählten MemberGroups (Häufigkeit der Größe von MemberGroups).

6.3.2 Verschiebetransformationen

Auf Basis des Analysewerkzeugs wurden zwei MemberGroup Patterns untersucht, durch deren Verschiebung die Modularität des Programmcodes verbessert werden kann. Da eine Verschiebung allgemeiner MemberGroups nicht automatisch möglich ist, wer- den für jedes Pattern Vorbedingungen definiert, die erfüllt sein müssen, damit die not- wendigen Transformationen zur Verschiebung korrektheits- und funktionalitätserhaltend durchgeführt werden können. Das common Pattern beschreibt eine MemberGroup, die eine beliebige Struktur besitzt, aber in ihrer Verwendung im Softwaresystem (Aufrufe von Methoden oder Nutzung von Membervariablen der MemberGroup) eingeschränkt ist. Im Gegensatz dazu beschreibt das strong Pattern MemberGroups, die in ihrer Struk- tur beschränkt sind, aber im Softwaresystem beliebig verwendet werden können.

Zusätzlich zu den Vorbedingungen, die im Folgenden für beide Patterns betrachtet wer- den sollen, können Einschränkungen einer Verschiebung auch durch Generalisierung und Realisierung der Klasse der MemberGroup entstehen. Eine Verschiebung ist bei- spielsweise nicht möglich, wenn eine Methode einer MemberGroup die Realisierung eines Interfaces darstellt oder Member von Kindklassen der MemberGroup-Klasse Ab- hängigkeiten zu Membern der MemberGroup besitzen. Strategien zur Verschiebung in diesen Fällen existieren ebenfalls, werden aber in den folgenden Patterns nicht betrachtet und können Teil weiterer Untersuchungen sein. Die Abwesenheit von Einschränkungen aus Generalisierung und Realisierung wird als Vorbedingung der folgenden Pattern be- trachtet.

Verschiebung von common MemberGroups Ziel der Verschiebung von Mem- berGroups nach dem common Pattern (vgl. Gleichung 6.1), ist die Verlagerung von ungünstig positionierten Teilfunktionalitäten in Klassen mit höherer semantischer Zu- gehörigkeit unter Beibehaltung oder Reduktion der Abhängigkeiten zwischen den be- treffenden Klassen. Die Zugehörigkeit einer MemberGroup zu einer Klasse kann über die Anzahl der Abhängigkeiten zur Klasse bestimmt werden. Ein Maß für die Anzahl

82 6.3 Realisierung prototypischer Komponentenbildungstransformationen

Abbildung 6.9:T RANSFORMR Aufrufdiagramm mit Klassen (Rechtecke), Metho- den (Ellipsen) und Membervariablen (Rhomben). Links: Verschiebba- re common MemberGroup {m(), b(), var} in Klasse Source. Rechts: Nach Target verschobene MemberGroup. der Abhängigkeiten zwischen einer MemberGroup MG(m) und einer Klasse C wird auf Basis der CINT -Metrik von Lanza et al. [34] wie folgt definiert:

CINT (MG(m),C) = {u → v | u ∈ MG(m) und v ∈ M(C)} . (6.2)

Die Metrik summiert alle ausgehenden Kanten (Aufruf einer Methode oder Nutzung ei- ner Membervariablen) der Member der MemberGroup zur Klasse C. Eine Verschiebung der MemberGroup in eine Klasse C wäre dann sinnvoll, wenn die MemberGroup eine größere Zahl von Abhängigkeiten zur Klasse C als zur Ausgangsklasse besitzt und C eine mögliche Zielklasse für das common Pattern ist.

Die Verschiebung einer common MemberGroup in eine gewählte Zielklasse ist möglich, wenn die folgenden Vorbedingungen erfüllt sind:

• Ausgangs- und Zielklasse der Verschiebung werden nur als Membervariablen in allen Klassen, die Member der MemberGroup aufrufen oder nutzen, verwendet; • Ausgangs- und Zielklasse werden in allen nutzenden Klassen nur ein Mal instan- tiiert; • Alle Anweisungen im Konstruktor der Ausgangsklasse, die Member der Mem- berGroup referenzieren, müssen unabhängig von Variablen sein, die nur lokal im Konstruktor verfügbar sind, da sonst die Verschiebung der Statements in den Kon- struktor der Zielklasse nicht möglich ist.

Abbildung 6.9 zeigt ein Beispiel einer Verschiebung einer common MemberGroup von einer Klasse Source in eine Klasse Target unter Beibehaltung der An- zahl der Abhängigkeitsbeziehungen. Neben der Verschiebung der Member m(), b() und var, müssen die Aufrufe der Methode caller() zu den Methoden m()

83 6 Entwicklung und Realisierung des Transformationssystems und b() der MemberGroup angepasst werden, wobei eine zusätzliche Kante von caller() zur Membervariable t hinzugefügt werden muss, um die Methoden in Target aufzurufen. Das Statement zur Initialisierung der Variable var (Abhängigkeit Source() → var, links) wird in den Konstruktor der Zielklasse verschoben (Abhän- gigkeit Target() → var, rechts).

Bei einer allgemeinen Verschiebung einer common MemberGroup müssen zunächst po- tentielle Zielklassen bestimmt werden. Dazu werden alle Klassen ermittelt, die Abhän- gigkeiten zur MemberGroup besitzen. Diese Menge, die als Mhas bezeichnet wird, ent- hält die ursprüngliche Klasse der MemberGroup selbst und alle Klassen, die Member- variablen oder Methoden der MemberGroup nutzen. Mögliche Zielklassen für die Mem- berGroup sind alle Klassen, die als Typen von Membervariablen in allen Klassen von Mhas auftreten, aber nicht der Ausgangsklasse entsprechen. Im Beispiel in Abbildung 6.9 besteht die Menge Mhas nur aus der Klasse Another. Die Menge möglicher Zielklas- sen enthält im Beispiel somit nur den Typ der Membervariable t (Klasse Target), da keine weiteren Typen in allen Klassen Mhas als Membervariablen verwendet werden (ohne Ausgangsklasse Source). Aus der Menge aller möglichen Zielklassen kann als konkrete Zielklasse diejenige Klasse ausgewählt werden, deren CINT -Metrik maximal ist.

Sind alle Vorbedingungen für eine Verschiebung erfüllt, so kann eine MemberGroup MG von einer Ausgangsklasse S in die Zielklasse T mit folgendem Algorithmus verschoben werden. 1 t_common ( source S , membergroup MG , target T , project P ) begin 2 resolveNameClashes ( MG , T ); 3 for each member M in MG : 4 if M in constructors ( S ): 5 moveConstructorStatements ( S , M , T ) 6 else : 7 moveMember ( S , M , T ) 8 replaceMemberGroupReferences ( P , MG , S , T ); 9 end

Der Transformationsalgorithmus besteht aus den folgenden Schritten: Zunächst müssen mögliche Namenskollisionen zwischen Member der Zielklasse T und der MemberGroup durch Umbenennen der Member der MemberGroup aufgelöst werden (Zeile 3). Danach werden abhängige Anweisungen des Konstruktors der Ausgangsklasse in den Konstruk- tor der Zielklasse (Zeile 6) und alle Member der MemberGroup in die Zielklasse ver- schoben (Zeile 8). Abschließend werden alle Referenzen auf die MemberGroup in der Ausgangsklasse mit Referenzen auf die MemberGroup in der Zielklasse ersetzt (Zeile 9).

Verschiebung von strong MemberGroups Die Verschiebung einer Member- Group nach dem strong Pattern zielt auf die Entkopplung der Ausgangs- und Zielklasse und damit auf die Reduzierung der Abhängigkeiten (coupling) und die Verbesserung der Modularität der Legacy-Software. Im Gegensatz zur common MemberGroup wer- den durch das strong Pattern nur MemberGroups betrachtet, die genau eine öffentlich genutzte Methode (die von anderen Klassen aufgerufen wird) besitzen. Mögliche Ziel- klassen der strong MemberGroups sind die Klassen, die der öffentlichen Methode als

84 6.3 Realisierung prototypischer Komponentenbildungstransformationen

Abbildung 6.10:T RANSFORMR Aufrufdiagramm. Links: Verschiebbare strong Mem- berGroup {m(Target), b(), var} mit einem Parameter mit Typ der Zielklasse. Rechts: Verschobene MemberGroup und entkoppelte Klassen Source und Target.

Parameter übergeben werden. Sind mehrere Parameter als Zielklassen geeignet, so kann mit der CINT -Metrik (Gleichung 6.2), die Klasse ausgewählt werden, zu der die meis- ten Abhängigkeiten bestehen.

Die Verschiebung einer strong MemberGroup ist möglich, wenn die folgenden Vorbe- dingungen erfüllt sind:

• Die CINT -Metrik von MemberGroup und Zielklasse hat einen Wert von mindes- tens 1; • Ausgangs- und Zielklasse werden in allen nutzenden Klassen nur ein Mal instan- tiiert; • Analog zum common Pattern müssen die Anweisungen des Konstruktors der Aus- gangsklasse, die Abhängigkeiten zur MemberGroup besitzen, unabhängig von nur lokal verfügbaren Variablen sein.

Abbildung 6.10 zeigt ein Beispiel einer Verschiebung einer strong MemberGroup beste- hend aus den Membern m(), b() und var der Klasse Source. Analog zum Beispiel der common MemberGroup entfällt die Initialisierung des Members var in der Klasse Source (Abhängigkeit Source() → var) durch die Verschiebung in die Zielklas- se (Abhängigkeit Target() → var). Durch die Verschiebung wird die Abhängigkeit zwischen der Ausgangs- (Source) und Zielklasse (Target) entfernt. Damit kann die Zahl gekoppelter Klassen (coupling) von drei auf zwei reduziert und somit die Modu- larität des Systems verbessert werden. Zusätzlich zur Verschiebung der Member kann der Parameter der Methode m(), der als Zielklasse verwendet wurde, entfernt werden, da in die Zielklasse selbst verschoben wurde und der Parameter somit über den this- Operator verfügbar ist.

85 6 Entwicklung und Realisierung des Transformationssystems

Sind die Vorbedingungen der Verschiebung für eine strong MemberGroup gegeben, so kann sie mit dem folgenden Algorithmus verschoben werden: 1 function t_strong ( source S , membergroup MG , target T , project P ) 2 begin 3 resolveNameClashes ( MG , T ); 4 for each member M in MG : 5 if M in constructors ( S ): 6 moveConstructorStatements ( S , M , T ); 7 else : 8 moveMember ( S , M , T ); 9 replacePublicMethodParameterByTarget ( MG , T ) 10 removePublicMethodParameter ( P , MG , T ); 11 replaceMemberGroupReferences ( P , MG , S , T ); 12 end

Analog zum Verschiebealgorithmus des common Patterns wird auch in diesem Algorith- mus mit der Auflösung von Namenskonflikten zwischen Membern der MemberGroup und Membern der Zielklasse begonnen (Zeile 3) und anschließend abhängige Anwei- sungen im Konstruktor der Ausgangsklasse und die Member der MemberGroup in die Zielklasse verschoben (Zeilen 4–8). Im Folgenden werden innerhalb der öffentlichen Methode alle Referenzen zum Parameter der Methode durch Referenzen auf die Ziel- klasse selbst (this) ersetzt (Zeile 9). Der nun nicht mehr benötigte Parameter wird in der öffentlichen Methode entfernt (Zeile 10). Abschließend werden alle Referenzen zur Ausgangsklasse (d. h. zur öffentlich genutzten Methode der MemberGroup) durch Re- ferenzen zur Zielklasse (Parameter des Methodenaufrufs) ersetzt und der Parameter aus der Liste der Parameter der Methode entfernt (Zeile 11).

6.3.3 Evaluierung der Verschiebetransformationen

Zur Evaluierung der Auswirkungen der dargestellten Verschiebungen auf die Modu- larität von Softwaresystemen wurden die Patterns auf zwei Open Source Projekte an- gewendet. Ausgewählt wurden JMeter4 (Version 2.3.2, 80 KLOC (kilo lines of code), 794 Klassen), ein Desktop Test- und Analysetool für verschiedene Netzwerkapplikatio- nen und -protokolle, und jEdit5 (Version 3.4, 95 KLOC, 940 Klassen) ein Cross-Platt- form Texteditor. Zur Messung der Änderung der Modularität wurde das Softwaremodell (FSR) beider Projekte erzeugt und die Anzahl voneinander abhängiger Klassenpaare (siehe Class Coupling, [11]) berechnet. Nach Anwendung der Patterns wurde die An- zahl erneut berechnet und mit dem ursprünglichen Wert verglichen. Für die Patterns wurden nur wenige MemberGroups gefunden, die den beiden Patterns mit ihren jeweiligen Vorbedingungen genügten. Bei der Suche nach dem strong Pattern wurden zwar sehr viele MemberGroups mit nur einer öffentlich genutzten Methode ge- funden, allerdings war bei 90 % der MemberGroups kein geeigneter Parameter vorhan- den, dessen Typ als Zielklasse der MemberGroup geeignet war (z.B. primitive Datenty- pen, Interfaces, Klassen von Bibliotheken). Im Falle der common MemberGroups war 4http://jakarta.apache.org/jmeter/ 5http://www.jedit.org/

86 6.4 Realisierung prototypischer Filtertransformationen

Tabelle 6.3: Verbesserungen der Anzahl abhängiger Klassenpaare. Eine Verringerung entspricht einer Verbesserung der Modularität des Softwaresystems.

————— abhängige Klassenpaare ————— Projekt Ausgangswert strong common P jEdit 4453 4455 (+0.04 %) 4449 (−0.08 %) 4451 (−0.04 %) JMeter 3698 3694 (−0.1 %) 3697 (−0.03 %) 3693 (−0.14 %) der häufigste Hinderungsgrund einer Verschiebung Abhängigkeiten aus Generalisierung bzw. Realisierung (49 %) neben der Voraussetzung, dass Ausgangs- und Zielklasse der Verschiebung nur als Membervariable genutzt werden (22 %).

Tabelle 6.3 zeigt die Änderungen der Anzahl abhängiger Klassen vor und nach An- wendung beider Patterns auf den Programmcode der ausgewählten Projekte. Bei An- wendung des strong Patterns auf das Projekt jEdit wurden durch die Verschiebung der MemberGroup Abhängigkeiten ausgehend von der MemberGroup zu weiteren Klassen in der Zielklasse hinzugefügt. In der Ausgangsklasse konnten diese jedoch nicht entfernt werden, da Member, die nicht Teil der MemberGroup waren, weiterhin Abhängigkeiten zu den Klassen besaßen. Somit erhöhte sich die Summe der abhängigen Klassenpaa- re, auch wenn die Abhängigkeit zwischen Ausgangs- und Zielklasse entfernt wurde. Trotz der beschriebenen Probleme wurde durch die Verschiebung der MemberGroups eine Entkopplung von Klassen in beiden Projekten erreicht. Die notwendigen Prüfun- gen der Vorbedingungen und zugehörige Transformationen können automatisiert mit dem TRANSFORMR durchgeführt werden und sind für beliebige weitere Projekte an- wendbar.

6.4 Realisierung prototypischer Filtertransformationen

Ziel der Filtertransformationen war die Erzeugung expliziter Verteiltheit basierend auf einem modularisierten Softwaresystem. Stellvertretend dafür wurde die Transformation einer monolithischen Anwendung in eine Client-Server-Applikation betrachtet. Mono- lithische Anwendungen weisen oftmals Defizite auf, die durch die Integration externer Services bzw. die Auslagerung interner Services gelöst werden können. Beispielswei- se bieten existierende Applikationen Services wie eine zentrale Datenhaltung oder eine konfigurierbare Web-Schnittstelle an, die von der monolithischen Software als Nutze- roberfläche genutzt werden kann. Andere Beweggründe für eine Auslagerung können Aspekte der Datensicherheit und -integrität, Korrektheitsprüfungen, sowie die Nutzung von Compute-Servern für rechenintensive Prozesse sein.

Als ein Beispiel wurde die Transformation zur Auslagerung einer zeit- und speicher- intensiven Berechnung auf einen Server betrachtet, der durch remote method invoca- tion (RMI) mit der Client-Anwendung kommuniziert. Abbildung 9.5 (Seite 128) zeigt

87 6 Entwicklung und Realisierung des Transformationssystems

(a)

(b) (c)

Abbildung 6.11: Extraktion eines Interfaces aus gemeinsamen Methoden zweier Klas- sen im TRANSFORMR (a). (b) und (c) zeigen die TRANSFORMR UML- Klassendiagramme des Subsystems mandelbrot.calculator vor und nach der Extraktion. die Muster-Applikation der Berechnung eines Fraktals der Mandelbrot-Menge. Die Be- rechnung der Menge besitzt zwei Implementierungen, von denen eine auf einen Server ausgelagert werden soll.

Die Transformation der Auslagerung basiert auf der Herstellung und Ersetzung einer be- stimmten Abhängigkeitsbeziehung von Klassen und zusätzlicher Codegenerierung zur Kapselung und Realisierung der entfernten Aufrufe. Die Umsetzung der Transforma- tion wurde in enger Zusammenarbeit mit der Realisierung des Client-Server-Frame- works durchgeführt und wird daher im Detail in Abschnitt 9.2 (Seite 121 ff.) dargestellt. Zur Vorbereitung der Auslagerung können jedoch weitere Transformationen notwendig sein, die die notwendigen Abhängigkeitsbeziehungen herstellen (siehe Abbildung 9.2). Beispielhaft sollen im Folgenden die Transformationen zur Extraktion eines Interfaces aus einer oder mehrerer Klassen vorgestellt werden. Abbildung 6.11 zeigt die UML- Klassendiagramme vor und nach der Extraktion und den Aufruf der Extraktion in der TRANSFORMR Nutzerschnittstelle.

Die Extraktions-Transformation setzt sich aus einer Modelltransformation und ei- ner Codetransformation zusammen. In der Modelltransformation wird ein neues Mo- dule (IMandelbrotCalculator) erzeugt, das die aus den Basismodulen extra-

88 6.4 Realisierung prototypischer Filtertransformationen

package mandelbrot. calculator ; include "Java.Grm" public class Mandelbrot1 { function main replace [program] p u b l i c MandelbrotImage P[program] c a l c u l a t e ( by P [addImport][addImplementsWith] FractalProperties fp) [addImplementsWithout] { end function ... } } function addImport replace ∗ [repeat import_declaration] ImpDec[repeat import_declaration] construct AddImp [import_declaration] ’import ’mandelbrot ’. ’IMandelbrotCalculator package mandelbrot. calculator ; ’; by ImpDec [. AddImp] import mandelbrot . end function IMandelbrotCalculator; function addImplementsWithout public class Mandelbrot1 replace ∗ [class_header] implements M[repeat modifier] ’class ’Fractal IMandelbrotCalculator { E[opt extends_clause] construct AddImpl [implements_clause] p u b l i c MandelbrotImage ’implements ’IMandelbrotCalculator c a l c u l a t e ( by M ’class ’Mandelbrot1E AddImpl FractalProperties fp) end function { ... function addImplementsWith } .. } end function

Abbildung 6.12: Links: Ursprünglicher (oben) und transformierter (unten) Pro- grammcode des Basismodules Mandelbrot1. Rechts: Ausschnitt der TXL Transformationsregeln zum Hinzufügen des Interfaces IMandelbrotCalculator zum Basismodule Mandelbrot1. hierten Methodensignaturen (calculate(FractalProperties)) besitzt. Zu- sätzlich wird das erzeugte Module als implementierendes Interface zu den Basis- modulen (Mandelbrot1, Mandelbrot2) hinzugefügt. Bei den Transformatio- nen müssen verschiedene Vorbedingungen beachtet werden. So können beispiels- weise nur Methoden in das Interface extrahiert werden, die in allen Basismodulen die gleiche Signatur aufweisen. Ein Ausschnitt der Codetransformation zeigt Ab- bildung 6.12. Durch die Anwendung der TXL-Regel (rechts), wird zu einer Basis- klasse (hier Mandelbrot1) ein weiteres Interface (IMandelbrotCalculator) hinzugefügt. Die Funktion addImplementsWithout fügt das Interface für den Fall hinzu, dass noch keine anderen Interfaces implementiert werden (die implements_clause existiert noch nicht). Eine weitere TXL Funktion für das Hinzufügen des Interfaces für den Fall, dass schon andere Interfaces implemen- tiert waren, ist ebenfalls in der vollständigen Transformationsspezifikation enthalten (addImplementsWith). Zusätzlich wird in der Zielklasse eine Import-Deklaration (import mandelbrot.IMandelbrotCalculator) hinzugefügt, falls sich das neu erzeugte Interface nicht im gleichen Package wie die Basisklasse befindet.

Die TXL-Regeln zur Transformation von Programmcode können häufig mit geringfü- gigen Änderungen für andere Module wiederverwendet werden. Im oben beschriebe-

89 6 Entwicklung und Realisierung des Transformationssystems nen Beispiel (Abbildung 6.12 rechts) können beliebige Basismodule durch weitere In- terface-Deklarationen erweitert werden. Dafür muss in den TXL-Regeln nur der Na- men der Basismodule und des Interfaces entsprechend angepasst werden. Alle anderen Teile der Regeln bleiben unverändert. Zur Ausnutzung der Wiederverwendbarkeit der TXL-Regeln wurde eine Template-Engine in das Werkzeug TRANSFORMR integriert, die auf Basis einer Menge von TXL-Regel-Templates Transformationsregeln für spe- zifische Programmtransformationen generiert. Ein Template besteht aus den TXL-Re- geln für eine Transformation und enthält Platzhalter für konkrete Werte der Regeln. Im Beispiel Abbildung 6.12 ist beispielsweise der Name des hinzuzufügenden Interfaces als ein Platzhalter realisiert, der durch die Template-Engine mit dem konkreten Namen IMandelbrotCalculator ersetzt wird.

Die Template-Engine ermöglicht sowohl eine leichte Wiederverwendbarkeit von TXL- Regeln als auch das Bilden von komplexen Transformationen durch das Zusammen- setzen mehrerer Einzeltransformationsregeln und bildet die Grundlage zur Generierung einer Vielzahl von TXL-Regeln zur Transformation von Programmcode.

6.5 Skalierbarkeit des Transformationssystems

Zur Bewertung der Anwendbarkeit des Transformationssystems auf beliebige Softwa- reprojekte ist eine Auswertung des Verhaltens für verschiedene Eingabekonfigurationen notwendig. Von besonderem Interesse ist dabei die dynamische Entwicklung des Res- sourcenbedarfs (Zeit und Speicher) für unterschiedliche Größen des zu untersuchenden Programmcodes. Da die Extraktion der FSR aus Programmcode eine mehrstufige Trans- formation darstellt und beispielhaft für die Entwicklung verwendeter Ressourcen des Transformationssystems steht, wurde der Extraktionsprozess zur detaillierten Untersu- chung ausgewählt.

Als Versuchsprojekt wurde der Programmcode des Java SE Development Kits 6 (JDK 1.6.0_03) verwendet, der eine geeignet hohe Komplexität und Größe besitzt. Aus allen Klassen innerhalb der packages java.** und javax.** (417 KLOC, 4434 Klassen, 35,4 MB) wurden zufällig Klassen ausgewählt, um jeweils 100 Testprojekte zwischen 8 kB (ca. 0,2 KLOC) und 2 MB (ca. 45 KLOC) Programmcode (mit möglicher Ab- weichung von 5 %) zu bilden. Quelldateien, die öffentliche Enumerations oder Dekla- ration von Annotationen enthielten, wurden dabei nicht ausgewählt, da diese speziellen Typen von Quelldateien vom Prototyp des Transformationssystems noch nicht verarbei- tet werden. Zusätzlich wurden Kommentare aus dem Programmcode entfernt, um nur die tatsächliche Verarbeitung von Programmcode zu berücksichtigen und einen direkten Zusammenhang zwischen Größe des ausführbaren Quellcodes und dem Aufwand der Extraktion herzustellen. Die Extraktion eines Projekts der insgesamt 900 Testprojekte wurde jeweils dreimal durchgeführt, um mögliche statistische Ausreißer zu identifizie- ren und zu entfernen. Als Testsystem wurde ein Arbeitsplatzrechner mit Intel Pentium 4 CPU (3.20 GHz), 1 GB Arbeitsspeicher und Ubuntu 8.04 (Kernel-Version 2.6.24-16) verwendet.

90 6.5 Skalierbarkeit des Transformationssystems

60 Total Time for a new TransFormr project Globalizing 300 Annotation FSRCreation 50 LoadFiles 250 AddConstructors ResolveDependencies AddGlobalizedFiles 40 200

30 150 time in seconds time in seconds 100 20

50 10

0 0 8 16 32 64 128 256 512 1024 2048 8 16 32 64 128 256 512 1024 2048 size of legacy source code in kB size of legacy source code in kB

Abbildung 6.13: Links: Durchschnittliche Gesamtlaufzeit der Extraktion der FSR aus Projekten unterschiedlicher Größe. Rechts: Durchschnittliche Laufzei- ten der einzelnen Stufen des Extraktionsprozesses.

Abbildung 6.13 zeigt die durchschnittlichen Laufzeiten zur Erzeugung einer FSR aus Projekten unterschiedlicher Größe. Insgesamt (linke Abbildung) steigt der Zeitbedarf li- near mit der Größe des zu extrahierenden Programmcodes an, wobei zu beachten ist, dass die x-Achse logarithmisch skaliert ist. Aus dem rechten Diagramm von Abbil- dung 6.13 wird deutlich, dass vor allem die Schritte Globalizing (Ersetzung der lokalen Typbezeichner mit qualifizierten Typbezeichnern) und die FSRCreation (Erzeugung der XML-FSR-Strukturen aus annotiertem Programmcode) einen Großteil der Gesamtlauf- zeit in Anspruch nehmen, wohingegen die Identifikation der Abhängigkeiten im Pro- jekt (ResolveDependencies) nur einen sehr kleinen Teil der Gesamtlaufzeit in Anspruch nimmt. Für eine optimale Anpassung an die Anzahl verfügbarer Prozessorkerne werden die Schritte Globalizing und FSRCreation für einzelne Programmcodedateien auf die verfügbaren Prozessoren verteilt, da in diesen Phasen die Bearbeitung jeder Datei un- abhängig von anderen Dateien ist. Die Maximalzahl gleichzeitig parallel abgearbeiteter Threads ist dabei frei konfigurierbar.

Die Entwicklung des Speicherbedarfs des annotierten Codes und der XML-Struktur der FSR ist in Abbildung 6.14 dargestellt. Es zeigt sich, dass der annotierte Code etwa um den Faktor 2,3 größer ist als der originale Programmcode und dass die XML-Struktur der FSR etwa die 7 bis 8-fache Größe des originalen Programmcodes erreicht. Da sich beide Größen aber um ein Vielfaches der Größe des originalen Programmcodes bewegen (siehe Abbildung 6.14 rechts) kann auch für den benötigten Speicherbedarf eine lineare Skalierung festgestellt werden.

Abbildung 6.15 zeigt die Entwicklung der Laufzeit der Extraktionsphase pro bearbei- tetes kB originalem Programmcode bzw. XML-FSR-Struktur. Es zeigt sich erneut eine gute Skalierbarkeit für die Projekte, da die benötigte Zeit zur Verarbeitung eines kB an originalen Programmcodes (bzw. resultierender XML-FSR-Struktur) mit steigender Projektgröße abnimmt.

91 6 Entwicklung und Realisierung des Transformationssystems

16 9 FSR FSR / source code rate AnnotatedCode Annotated code / source code rate 14 8

12 7

10 6 8 5 6 total file size in MB 4 4 generated code / project-size rates 2 3

0 2 8 16 32 64 128 256 512 1024 2048 8 16 32 64 128 256 512 1024 2048 size of source code in kB size of source code in kB

Abbildung 6.14: Links: Speicherbedarf des erzeugten annotierten Codes und der XML- Strukturen der FSR in Abhängigkeit der Projektgrößen. Rechts: Ent- wicklung des Verhältnisses zwischen dem Speicherbedarf des anno- tierten Codes bzw. der XML-Struktur der FSR und dem originalen Pro- grammcodes.

0.35 Time / FSR Size Time / Legacy Project Size 0.3

0.25

0.2

0.15

0.1 time / size (FSR, legacy code) rate 0.05

0 8 16 32 64 128 256 512 1024 2048 size of legacy source code in kB

Abbildung 6.15: Verhältnisse aus durchschnittlicher Laufzeit zur Extraktion einer FSR und Speicherbedarf der FSR bzw. des originalen Programmcodes. Die Laufzeit pro kB extrahierter FSR sinkt mit steigender Projektgröße.

92 7 Entwurf eines Client-Server-Frameworks CBFRAME

7.1 Zielsetzung

Die zentrale Aufgabe dieses Arbeitspaketes ist es, die Zielplattform CBFRAME und deren Architektur für die zu transformierende Software zu entwerfen. Das Hauptaugen- merk liegt dabei auf der Erstellung einer erweiterbaren Softwarearchitektur. Beim Ent- wurf der Zielplattform CBFRAME ist zu unterscheiden, welche Komponenten statisch integriert werden müssen und für welche eine dynamische Adaptierbarkeit gegeben sein sollte. Eine verteilte Ausführung der Business-Software innerhalb von CBFRAME erfor- dert die Festlegung von Protokollen, damit die einzelnen Komponenten des Frameworks sowie die Client-Software mit den Framework-Komponenten kommunizieren können. Dabei spielen die zu verwendenden Sicherheitskonzepte eine tragende Rolle, um eine si- chere Datenübertragung im Framework zu gewährleisten. Ein weiteres Kriterium beim Entwurf ist die Betrachtung der Ausfallsicherheit des Gesamtsystems. Deshalb sollen Methoden zur Datenredundanz verglichen und ggf. in CBFRAME integriert werden. Des Weiteren sind in diesem Arbeitspaket die zu verarbeitenden Workflows zu analysieren, um diese Erkenntnisse in die Architektur des Frameworks einfließen zu lassen. In einem weiteren Kapitel werden Möglichkeiten der Modernisierung der grafischen Oberfläche (GUI) untersucht. Dabei werden manuelle und automatische Transformationsmöglich- keiten, sowie die Möglichkeiten zur Einbettung in den Gesamt-Transformationsprozess betrachtet.

7.2 Anforderungen

Für die Überführung einer Software in eine neue Architektur, sind die Anforderungen an die neue Architektur zusammenzutragen. Ein zentrale Anforderung an die in die- sem Projekt betrachtete Zielsoftware ist die Lauffähigkeit auf einem heterogenen Sys- tem. Als heterogen bezeichnen wir in diesem Fall Software, die auf unterschiedlichen Hardwarearchitekturen ausgeführt werden kann und auch nicht auf ein Betriebssystem beschränkt ist. Da die einzelnen Komponenten der Zielsoftware klar definierte Schnitt- stellen haben sollen, ist es möglich, einzelne Komponenten mit unterschiedlichen Pro- grammiersprachen oder Frameworks umzusetzen. Eine komponentenbasierte Architek- tur ermöglicht eine bessere Adaptierbarkeit an die Anforderungen des heterogenen Sys- tems, da einzelne Bausteine speziell an Hardware- oder Betriebssystemeigenschaften

93 7 Entwurf eines Client-Server-Frameworks CBFRAME angepasst werden können. Die Zielarchitektur soll einem Client-Server-Modell entspre- chen, in dem die Komponenten mittels Anfragenachrichten Dienste anderer Komponen- ten nutzen sollen. Damit ist der Grundstein gelegt, um eine verteilte Architektur der Gesamtsoftware zu ermöglichen, bei der Teilprozesse der Business-Software auf unter- schiedlichen Recheneinheiten ausgeführt werden können. Die Analyse der in der Aus- gangssoftware enthaltenen Workflows ergab, dass in der Beispielapplikation GBware vorwiegend betriebswirtschaftliche Geschäftsprozesse verarbeitet werden. Diese sollten demnach in CBFRAME besonders unterstützt werden, was die Auswahl einer geeigneten Workflow-Verarbeitungstechnologie erfordert. Um eine Software in eine neue Architek- tur zu überführen, sind die damit verbundenen Kosten von zentraler Bedeutung. Ein wichtiger Kostenfaktor für die Entwickler sowie für die späteren Kunden sind die Li- zenzgebühren einzelner Bibliotheken oder Laufzeitsysteme. Aus diesem Grund werden beim Entwurf der Architektur bevorzugt Open Source-Produkte für den späteren Einsatz analysiert und evaluiert.

7.3 Evaluation von Open Source Business-Software-Systemen

Da es sich bei der im Projekt zu transformierenden Software um Business-Software handelt, wurden die Architekturen verschiedener Open Source-Business-Systeme un- tersucht. Es sollte eine aktuelle Übersicht über die verwendeten Technologien erstellt werden, die Anhaltspunkte gibt, woran sich die neue Architektur der zu transformieren- den Software anlehnen sollte. Die Ausgangssoftware unseres Projekts dient vorwiegend der Ressourcenplanung in Unternehmen und lässt sich demnach den ERP-Systemen (Enterprise Resource Planning) zuordnen. Aus diesem Grund wurden verschieden Open Source-ERP-Systeme auf ihre Eigenschaften analysiert und verglichen. Schwerpunkte dieser Untersuchung lagen dabei auf: • der Software- und Entwicklungsplattform, • der Kommunikationsschicht, • und der Workflow-Engine.

Folgende ERP-Systeme wurden analysiert: • Compiere1, • erpOS2, • JFire3, • und Openbravo4.

Die Ergebnisse des Vergleichs bezüglich Aufbau und Eigenschaften verschiedener Open Source-ERP-Systeme sind in Tabelle 7.1 zusammengefasst. Alle betrachteten ERP- Systeme haben eine dreischichtige Softwarearchitektur, bestehend aus Datenbank, Ap-

1http://www.compiere.de 2http://www.erpos.com 3http://www.jfire.org 4http://www.openbravo.com

94 7.3 Evaluation von Open Source Business-Software-Systemen

Tabelle 7.1: Vergleich von Open Source-ERP-Systemen.

Compiere erpOS JFire Openbravo Lizenz GPL EPL LGPL Openbravo Public License Datenbank Oracle MaxDB / IBM DB2 MySQL PostgreSQL und Oracle Architektur 3-Tier / MVC 3-Tier / MVC 3-Tier / MVC 3-Tier / MVC Client Rich-Client (Java, Web (JSF, Axis) Eclipse RCP Web (AJAX) JDBC, RMI) Web (JSP, Tomcat) Rich-Client (Eclipse RCP) Mobile Clients (J2ME 2.0) Application JBoss JBoss + Tomcat JBoss Tomcat Server Workflow-Engine Compiere (WfMC- jBPM/jBoss jBPM keine konform) Persistenzschicht Compiere Hibernate JDO 2.0 Hibernate Framework Spring Spring Weitere Enterprise Service Bus (ESB) Technologien plikationsserver und Clients. Die Systeme basieren auf der Java-Plattform, um Unab- hängigkeit von der Zielhardware zu gewährleisten. Als grundlegender Java Enterpri- se Softwarestack wird bei den genannten ERP-Systemen entweder der Java-Enterprise- Application-Server [12] oder das Spring-Framework5 verwendet.

Bei der Erstellung von Applikationen die auf ERP-Systemen aufsetzen werden Codetei- le oftmals mittels modellgetriebener Softwareentwicklung automatisiert erzeugt. Zum Einsatz kommen dabei Werkzeuge wie openArchitectureWare6, welche gängige Techni- ken der modellgetriebenen Softwareentwicklung unterstützen, z.B. Metamodellierung, Modelltransformationen und Codegenerierung [50] (vgl. Kap. 5.1).

Im Bereich der GUI-Programmierung wurde deutlich, dass alle Projekte eine strikte Trennung der Logik nach dem MVC-Prinzip (Model-View-Controller) einhalten. MVC ist ein Muster bei der Softwareentwicklung, das dafür sorgt, dass Logik zur Steuerung der Benutzeroberfläche und die Logik zur Erzeugung einer Oberfläche getrennt sind. Damit ist es möglich, mit der selben Steuerlogik Rich-Client Oberflächen (Windows) oder Web-Oberflächen im Browser anzusteuern, was den Programmieraufwand deutlich reduziert.

Die Festlegung auf ein ERP-System determiniert auch die entsprechende Workflow- Engine, die vom Anwendungsentwickler bei Verwendung eines bestimmten ERP- Systems benutzt werden muss. Die verglichenen ERP-Systeme verwenden größtenteils jBPM7 von JBoss. jBPM bietet die Möglichkeit, Geschäftsprozesse mittels jPDL (Be- schreibungssprache) zu definieren und auszuführen. Darüber hinaus bietet jBPM auch eine Laufzeitumgebung für Geschäftsprozesse, die zuvor mit BPEL (Business Process Execution Language [2]) modelliert wurden. Jedoch ist jPDL keine standardisierte Spra- che der WfMC8, wie bspw. XPDL9.

5http://www.springframework.org 6http://www.openarchitectureware.org 7http://www.jboss.com/products/jbpm 8http://www.wfmc.org 9http://www.wfmc.org/standards/xpdl.htm

95 7 Entwurf eines Client-Server-Frameworks CBFRAME

7.4 Middleware-Plattform

Die Evaluation der ERP-Systeme macht deutlich, dass eine moderne Softwarearchitek- tur, die aus mehreren logischen Schichten aufgebaut ist, um Zuständigkeiten besser zu trennen (N-Tier-Architektur), auf einer geeigneten Middleware-Plattform aufgebaut sein muss. Als Basis verwenden alle betrachteten ERP-Systeme einen Java-Enterprise-App- lication-Server. Da es aber neben der Java Enterprise Edition (JEE) auch andere Midd- leware-Ansätze gibt, soll ein weiterer Vergleich Aufschluss geben, welche Middleware für den Einsatz in TransBS geeignet ist.

7.4.1 Anforderungen

Die Middleware, auf der CBFRAME aufbauen soll, muss einige Voraussetzungen er- füllen, die im Weiteren genauer charakterisiert werden. Ein wesentliches Kriterium ist, dass sich die Middleware möglichst aus Open Source-Komponenten zusammensetzt. Dadurch lassen sich zum einen Kosten sparen, zum anderen können einzelne Kompo- nenten bei Bedarf modifiziert werden. Die meisten Applikationsserver, wie z. B. JBoss, bieten einen sehr großen Softwarestack, der häufig verwendete Bestandteile einer Busi- ness-Applikation als generische Komponente bereitstellt. Als Beispiel sei die Persis- tenzschicht erwähnt, mit der es möglich ist, einzelne Geschäftsobjekte direkt auf rela- tionale Datenbanken abzubilden ohne eigenen Code schreiben zu müssen. Ein weiteres wichtiges Kriterium neben dem Funktionsumfang ist die Unterstützung durch Entwick- lungswerkzeuge, wie IDEs (Integrated Development Environment). Diese Werkzeuge sollen einen möglichst großen Funktionsumfang der Applikationsserver abdecken und nach Möglichkeit keine Lizenzgebühren erfordern.

Drei verschiedene Middleware-Softwarestacks wurden auf Ihre mögliche Verwendung innerhalb von CBFRAME untersucht. Dazu gehören: • die Java Enterprise Edition, • das CORBA Component Model, • und .NET.

7.4.2 Java Enterprise Edition

Die Java Enterprise Edition ist eine Spezifikation einer Softwarearchitektur, auf der An- wendungen aufgebaut werden können. Die Spezifikation umfasst Softwarekomponen- ten und Dienste, die ein JEE-Applikationsserver bereitstellen muss. Damit lassen sich Anwendungen leichter portieren und sind von der Ausführungsumgebung weitgehend unabhängig. Außerdem erleichtert das Vorhandensein von Softwarekomponenten die Entwicklung der Anwendungen, da oft benötigte Module bereits mitgeliefert werden. Die Spezifikation lehnt sich stark an Java als Programmiersprache an, wobei es auch möglich ist, andere Java-VM-basierte Sprachen zur Entwicklung zu benutzen.

Wichtige Eckpfeiler der Spezifikation sind u.a.

96 7.4 Middleware-Plattform

Tabelle 7.2: Implementierungen der Java-Enterprise-Edition

Open Source proprietär JBoss IBM WebSphere JOnAS BEA WebLogic Sun Java System Application Server, GlassFish SAP Web Application Server Apache Geronimo Oracle Application Server

• die Gewährleistung der Sicherheit, • die Bereitstellung von Transaktionsmechanismen, • umfangreiche Namensdienste, • eine Persistenzschicht, • einfache Installation der Komponenten (Deployment).

Diese Eckpfeiler bilden eine Rahmenarchitektur, um verteilte und mehrschichtige An- wendungen effizient und schnell entwickeln zu können. Die klar definierten Schnittstel- len der einzelnen Softwarekomponenten sorgen für Interoperabilität der Spezifikations- implementierungen verschiedener Hersteller. Durch den Einsatz eines JEE-Applikati- onsservers reduziert sich die Komplexität der Entwicklung, da sich die Programmierer auf die Kernfunktionalitäten ihrer Anwendung konzentrieren können. Im Kern der JEE- Spezifikation stehen die Enterprise JavaBeans (EJB), die die Geschäftslogik der Anwen- dungen enthalten. Alle EJBs können in EJB-Containern ausgeführt werden, die spezielle Systemfunktionen, wie Transaktionen oder Rechtemanagement, implementieren. Da die EJBs auf der Serverseite implementiert sind, enthalten die Clients keine (oder kaum) Ge- schäftslogik und sind damit weniger aufwändig zu programmieren. Zudem gibt es eine große Auswahl an JEE-kompatiblen Applikationsservern. Die am meisten verbreiteten Applikationsserver sind in Tabelle 7.2 aufgeführt.

Verschiedene JEE-Standards werden von den Entwicklungswerkzeugen Eclipse10 und NetBeans11 sehr gut unterstützt. Mit diesen IDEs lassen sich durch viele verschiedene Assistenzprogramme (Wizards) sehr schnell neue EJBs erzeugen und debuggen. Außer- dem vereinfacht sich der Deployment-Prozess der Softwarekomponenten mit Hilfe der IDEs deutlich.

Als Fazit lässt sich feststellen, dass die Java-Enterprise-Plattform sehr gut als Middle- ware für CBFRAME dienen kann. Die Spezifikation bietet eine große Menge an standar- disierten APIs (Application Programming Interface) für Business-Anwendungen. Die APIs sind sehr gut dokumentiert und deren Benutzung wird in einer Vielzahl von Bü- chern näher erläutert. Die Unabhängigkeit vom Betriebssystem und damit von der Hard- ware stellt einen weiteren Pluspunkt dar. Darüber hinaus existieren freie Umsetzungen des Standards, wodurch sich Lizenzgebühren einsparen lassen. Für JEE stehen leistungs- fähige Werkzeuge zur freien Verfügung. Die Nachteile der JEE liegen vor allem in der Komplexität des Softwarestacks begründet. Da viele Komponenten und Services mitge- liefert werden, ist die Einarbeitung sehr zeitintensiv. Als weiteren Nachteil kann man die 10http://www.eclipse.org 11http://www.netbeans.org

97 7 Entwurf eines Client-Server-Frameworks CBFRAME

Fixierung auf Java als Programmiersprache sehen. Da man aber mittlerweile auch an- dere Sprachen auf der Java-Virtual-Machine benutzen kann, wie Groovy12 oder Scala13, sollte dies kein schwerwiegender Nachteil sein.

7.4.3 CORBA Component Model

Der CORBA-Standard wird von der Object Management Group (OMG) herausgegeben, welche 1989 gegründet wurde und mittlerweile eines der größten Softwarekonsortien der Welt ist. Das ursprüngliche Ziel der OMG war es, einen Standard zu definieren, der den Rahmen für eine verteilte und zugleich portable Ausführung von Anwendun- gen in heterogenen Systemen festlegt. Wichtige Ziele des CORBA-Standards waren die Verwendung objektorientierter Schnittstellen und die Unabhängigkeit von der verwen- deten Programmiersprache. Im Jahr 1991 wurde die Common Object Request Broker Architecture14 (CORBA) als Standard verabschiedet. Im Laufe der Jahre wurden immer neue Spezifikationen in den Standard aufgenommen, so dass der Standard mehr als 700 Seiten umfasst. CORBA beinhaltet die Definition eines Objekt- und eines Referenzmo- dells. Das Objektmodell definiert Schnittstellen zwischen auf verteilten Rechnern aus- geführten Objekten. Nur über diese Schnittstellen kann ein Objekt durch Anfragen von Clientprozessen verwendet werden. Die Details der jeweiligen Implementierung bleiben für die Clients unsichtbar. Das Referenzmodell stellt Schnittstellenkategorien zur Verfü- gung, die über einen Object Request Broker (ORB) miteinander verbunden sind. Durch einen ORB können die Clientprozesse mit den verteilten Objekten kommunizieren. Die Objektschnittstellen werden in CORBA über die Interface Definition Language (IDL) spezifiziert. Die IDL bietet eine von der Programmiersprache unabhängige Beschrei- bung der Objektschnittstellen. Dadurch können Anwendungsteile in unterschiedlichen Programmiersprachen realisiert werden. Die folgenden Arbeitsschritte sind notwendig, um mittels CORBA und IDL auf ein entferntes Objekt zuzugreifen:

1. Beschreibung der Schnittstelle mit der IDL. 2. IDL-Compiler generiert Server-Skeleton und Client-Stub. 3. Implementierung des Server-Skeletons. Der Server erzeugt eine Instanz und akti- viert diese. 4. Client erzeugt Instanz des Stubs und ruft Methoden des Stubs auf. 5. ORB überträgt bei Methodenaufruf Eingabeargumente (in) zum Server, ruft ent- sprechende Methode des Server-Objekts auf und überträgt Ausgabeargumente (out) und Rückgabewert zurück zum Client.

Nicht für jede Programmiersprache existiert ein CORBA-Standard, der angibt, wie Me- thoden und Datentypen abzubilden sind. Eine Übersicht über die CORBA-Standardisie- rung unterschiedlicher Programmiersprachen ist in Tabelle 7.3 aufgeführt.

12http://groovy.codehaus.org/ 13http://www.scala-lang.org/ 14http://corba.org

98 7.4 Middleware-Plattform

Tabelle 7.3: Programmiersprachen mit CORBA-Anbindung.

standardisiert nicht standardisiert Ada Delphi C Eiffel C++ Perl COBOL Tcl CORBA Scripting Language Java Lisp, PL/1, Python, Smalltalk

Da Delphi keine standardisierte Programmiersprache ist, muss innerhalb des TransBS- Projektes der benötigte Funktionsumfang von CORBA im konkreten Fall geprüft wer- den.

Wie bereits beschrieben, wurde der CORBA-Standard über die Jahre aktualisiert und an neue Gegebenheiten angepasst. Als wichtigste Neuerung wurde mit der Version 3.0 das CORBA Component Model (CCM) eingeführt. Dabei bildet die Softwarekomponente den Kern der CCM. Das CCM lehnt sich an die EJB-Definition an, regelt z. B. den Typ von Komponenten (Session, Entity) und den Aufruf von Komponenten über Container. Das CCM standardisiert serverseitige Werkzeuge, wie Component Server, Component Implementation Framework, Packaging Tools, Deployment Tools. Die Komponenten sind serverseitige Objekte, die in Containern installiert werden. Die Container besitzen einen ORB und einen Portable Object Adapter (POA).

Es existieren verschiedene CORBA-Implementierungen diverser Hersteller, die vor al- lem unterschiedliche Standards implementieren. Die Eigenschaften einiger ausgewähl- ter CORBA-Implementierungen sind in Tabelle 7.4 vergleichend aufgeführt.

Der Vergleich zeigt, dass es sehr große Unterschiede zwischen den einzelnen Implemen- tierungen gibt. Wie schon erwähnt, implementieren sie nicht alle den aktuellen Standard. Zum Zeitpunkt der Studie wurde keine freie CORBA-Implementierung gefunden, die den oben erwähnten Standard 3.0 umsetzt. Wie außerdem zu erkennen ist, beschränken sich viele Implementierungen auf wenige Programmiersprachen. Eine Ausnahme bildet ORBit2. Da ORBit2 im Gnome-Projekt15 zum Einsatz kommt, bietet es eine Vielzahl von Programmiersprachen-Bindings.

Dedizierte Entwicklungsumgebungen gibt es bei CORBA nicht. Allerdings existieren für Eclipse verschiedene Plugins, um CORBA zu verwenden, z. B. das Eclipse COR- BA Plugin, ORB Studio und JNIUS. Auch andere IDEs bieten für die entsprechende Programmiersprache CORBA-Funktionen an, wie z. B. der JBuilder oder C++-Builder.

15http://www.gnome.org/

99 7 Entwurf eines Client-Server-Frameworks CBFRAME

Tabelle 7.4: Vergleich von CORBA-Implementierungen.

Implementierung Typ CORBA-Standard Sprachen ILU (PARC Xerox) frei 2.0 C/C++, Python, Java, Lisp JacORB frei 2.3 Java MICO frei 2.3 C++ omniORB frei 2.6 C++, Python OpenORB frei 2.4.2 Java ORBit2 frei 2.4 C, C++, Python, Perl, Ruby,... TAO frei 2.4 (+3.0 Features) C++ Java IDL (Sun) frei 2.3.1 Java Orbix (IONA) kommerziell 2.6 (+3.0 Features) C++, COBOL, PL/1 Orbacus (IONA) kommerziell 2.6 C++, Java Visibroker (Borland) kommerziell 2.6 Java, C++, .NET-Sprachen Tuxedo (BEA) kommerziell OpenFusion (PrismTech) kommerziell

7.4.4 .NET Framework

Eine weitere Middleware-Plattform ist das .NET-Framework, das von Microsoft ange- boten und entwickelt wird. Es ist aktuell in der Version 3.5 verfügbar und vereint eine Reihe verschiedener Technologien unter einer gemeinsamen Schnittstelle. Es umfasst wie JEE eine Laufzeitumgebung, eine Klassenbibliothek und Services und soll somit die Interoperabilität von Windows-Programmen verbessern. Es werden unter anderem Schnittstellen zur Verarbeitung von Workflows, zur grafischen Darstellung (GUI) und Netzwerkkommunikation (bspw. Webservices) angeboten. Das .NET-Framework wird von Microsoft nur für Windows angeboten, obwohl auch freie Implementierungen exis- tieren, z. B. Mono16. Diese implementieren jedoch nicht nicht den aktuellen Standard und bieten zudem nicht den vollen Umfang der .NET-Klassenbibliothek von Microsoft. Da im .NET-Framework größtenteils proprietäre Technologien verwendet werden, die von Microsoft eigens für das .NET-Framework entwickelt wurden (bspw. Workflow- Verarbeitung), und offiziell nur Windows als Zielplattform unterstützt wird, ist die Ein- setzbarkeit im heterogenen Umfeld eingeschränkt (bspw. gegenüber JavaEE).

7.4.5 Zusammenfassung

Die Aufgabe dieses Arbeitspunktes war es, eine Middleware als Implementierungsbasis sowohl für CBFRAME als auch für die zu transformierende Software zu ermitteln. Da- bei wurden folgende drei verschiedene Middleware-Ansätze untersucht: Java Enterprise Edition, CORBA Component Model und .NET. Ein zusammenfassender Überblick über die Funktionen dieser Softwareplattformen wird in Tabelle 7.5 gegeben. Die Tabelle enthält eine Bewertung von Funktionen, die für die Realisierung der CB- FRAME-Plattform notwendig sind. Für JavaEE sind die meisten freien Referenzimple- 16http://www.mono-project.com

100 7.5 Transformation der grafischen Benutzeroberfläche

Tabelle 7.5: Gegenüberstellung von Enterprise-Frameworks.

JavaEE CORBA .NET Freie Implementierungen + + - Verschiedene Programmiersprachen - + + Verschiedene Betriebssysteme + + - Security Services + + + IDE-Unterstützung + - + Freie IDEs + - - Data Marshalling + + + mentierungen, wie z. B. Glassfish, vorhanden. Dagegen existieren für CORBA zwar freie Implementierungen, die meist aber nicht den kompletten Standard umsetzen. COR- BA bietet die Möglichkeit, sehr viele unterschiedliche Programmiersprachen zu verwen- den, wohingegen JavaEE stark an die Programmiersprache Java gebunden ist. Das .NET- Framework bietet neben C# und Visual Basic auch C/C++-Unterstützung. Das .NET- Framework zielt auf Windows als Betriebssystem ab. Im Gegensatz dazu sind JEE und CORBA nicht an ein spezielles Betriebssystem gebunden. Die IDE-Unterstützung von JEE und .NET ist sehr gut. Mit NetBeans, Eclipse und Visual Studio existieren sehr gute Werkzeuge für JEE und .NET, wobei NetBeans und Eclipse frei erhältlich sind. Außerdem unterstützen alle drei untersuchten Plattformen das Data-Marshalling, was den Programmierer von der komplexen Aufgabe der Datenkonvertierung befreit.

7.5 Transformation der grafischen Benutzeroberfläche

7.5.1 Zielsetzung

Die Transformation der GUI ist ein Teilschritt in der gesamten Transformationsket- te, welche in [46] vorgestellt wird. Dieser Transformationsschritt hängt besonders von der Zielarchitektur ab, in die transformiert werden soll. Legacy-Software ist oft durch die Verwendung von veralteten Benutzeroberflächen gekennzeichnet [52] und meist an Hardware (z.B. Macintosh) oder Software (z.B. Windows) gebunden (AP 2.3). Ein wei- teres Merkmal von Legacy-Software ist, dass Logik, die die Oberfläche steuert, mit der Geschäftslogik stark verwoben ist. Das führt dazu, dass die Transformation der Ober- fläche eine Überführung der betroffenen Geschäftslogik nach sich zieht. Ziel der Mo- dernisierung der grafischen Benutzeroberfläche ist die Extraktion von Programmcode, der die grafische Oberfläche beschreibt, aus der monolithischen Software und die Be- reitstellung der grafischen Oberfläche für heterogene Systeme. Die Trennung von GUI- und Geschäftslogik ist erforderlich, um eine Modularisierung der Geschäftssoftware zu erreichen.

101 7 Entwurf eines Client-Server-Frameworks CBFRAME

Aktuelle Technologien zur Generierung und Darstellung von grafischen Oberflächen verwenden oftmals Plattform übergreifend einheitliche Bibliotheken (z. B. Java Swing) und dynamische Beschreibungen der Anordnung der einzelnen GUI-Elemente (Wid- gets), z. B. durch Layout-Manager in Java. Außerdem gewinnen Web-Applikationen zunehmend an Bedeutung. Die Modellierung von Web-Oberflächen ist sehr vielfältig realisierbar durch einfaches HTML, aber auch Skriptsprachen wie Javascript oder Ad- obe Flash werden oftmals zusätzlich eingesetzt. Bei Web-Applikationen wird die grafi- sche Oberfläche naturgemäß erst zur Laufzeit, üblicherweise vom Webbrowser, ausge- wertet und dargestellt (rendern). Auch klassische lokale Applikationen verwenden diese Technologie zunehmend. So wird die GUI der Browser-Applikation Mozilla Firefox aus der XML-basierten Beschreibungssprache XUL zur Laufzeit erzeugt. Deshalb wurde in CBFRAME die Abbildung der grafischen Oberfläche in einer XML-basierten Beschrei- bungssprache favorisiert.

Bei der Bereitstellung einer grafischen Oberfläche als Webseite (auch via Javascript), wie auch bei der Anbindung von entfernten Diensten (via RPC oder Webservice), müssen Zugangsberechtigungen implementiert und die Integrität der übertragenen Daten sichergestellt werden. Die verwendeten Technologien müssen auf geeignete Verschlüsselungs- und Authentifizierungsmechanismen hin überprüft werden. Dabei kann im Web-Umfeld das sowohl Verschlüsselung als auch Authentifizierung unterstüt- zende SSL/TLS-Protokoll zur Anwendung kommen, welches mit Zertifikaten arbeitet. Das Transport Layer Security(TLS)-Protokoll arbeitet dabei transparent für die eigentli- che Applikation auf der Transport-Schicht im TCP/IP-Protokollstack und ist somit viel- seitig einsetzbar.

Legacy-Software wurde im Allgemeinen nicht für mehrere Threads konzipiert. Dadurch ist es nicht möglich, dass ein Benutzer in einem Fenster arbeiten kann, während eine rechenintensive Aufgabe im Hintergrund ausgeführt wird. Zur Erhöhung der Benutzer- freundlichkeit ist eine Auslagerung der Aufgabe in einen weiteren Thread sinnvoll. Da- bei ist zu beachten, dass nach der Auslagerung grafische Ein- und Ausgaben des ausge- lagerten Threads nebenläufig zu weiteren nutzergesteuerten Ein- und Ausgaben auftre- ten können. Eine threadsichere Gestaltung der grafischen Oberfläche ist daher sinnvoll und wird durch die Verwendung eines dedizierten UI-Threads realisiert, der die grafi- schen Ein- und Ausgabeereignisse über eine Queue steuert. Damit können auch aktuelle Widget-Bibliotheken (Swing, GTK, QT), die nicht threadsicher sind, für die Darstellung der Benutzeroberfläche verwendet werden.

7.5.2 Konzepte zur UI-Transformation von GBware

Um ein Werkzeug in TRANSFORMR zu realisieren, das den Entwickler bei der Transfor- mation der grafischen Oberfläche unterstützt, wurden Konzepte zur UI-Transformation untersucht. Um die geforderte Modularisierung und Lauffähigkeit unter heterogenen Plattformen zu erreichen, ist es günstig, die monolithische Software (GBware) in eine Model-View-Controller-Architektur (MVC) [24] zu überführen. In dieser Architektur werden das Modell (Model), also das Dokument oder die Daten, von der Präsentation

102 7.5 Transformation der grafischen Benutzeroberfläche

Abbildung 7.1: Frontend-Transformation, Konzept 1.

(View) und der Steuerungskomponente (Controller) getrennt. Vorteil dieser Architektur ist die leichte Austauschbarkeit der 3 Komponenten. Es können beispielsweise verschie- dene Darstellungsformen der grafischen Oberfläche gewählt werden. Außerdem werden Änderungen am Dokument sofort in der Präsentationsschicht sichtbar. Die Steuerungs- komponente gewährleistet auch den threadsicheren Zugriff auf das Modell und die Prä- sentation.

Es wurden zwei Konzepte der Transformation von Benutzeroberflächen erarbeitet, wel- che nachfolgend vorgestellt werden. Um die Probleme bei der Transformation in eine MVC-Architektur zu begrenzen, werden entsprechende Arbeitsschritte definiert, die ei- ne werkzeuggestützte Transformation der GUI ermöglichen.

Manuelle Vortransformation in ein MVC-Framework

Das hier vorgestellte Konzept setzt eine manuelle Vortransformation von der zu trans- formierenden monolithischen Software (GBware) nach MVC voraus. Die schematische Darstellung in Abbildung 7.1 veranschaulicht dieses Konzept. Dabei wird der ursprüng- liche Quellcode manuell in ein vorher definiertes MVC-Framework übertragen. Die Funktionalität bleibt dabei komplett erhalten. Bei dieser manuellen Transformation wer- den Geschäftslogik und grafische Oberfläche voneinander getrennt. Die manuelle Vor- transformation nach MVC hat den Vorteil, dass man die einzelnen Teilkomponenten (Model, View, Controller) separat transformieren kann. Außerdem ist es so möglich, spezielle Transformationsschritte für die einzelnen Teilkomponenten anzuwenden. Wei- terhin ist das MVC-Modell direkt für den Einsatz im Web nutzbar. UI-Code, welcher für Rich-Clients geschrieben wurde, ist hingegen nicht direkt in ein Request-Response- Modell für die Darstellung im Browser übertragbar. Ist die Software in das MVC-Modell transformiert, müssen die spezifischen Widgets aus der UI-Bibliothek der Quellsprache

103 7 Entwurf eines Client-Server-Frameworks CBFRAME

Abbildung 7.2: Frontend-Transformation, Konzept 2.

(z. B. die Visual Component Library (VCL) für Delphi) durch eine plattformunabhän- gige UI-Beschreibungssprache spezifiziert werden (TransBS View Transformation). Die Beschreibungssprache muss zur Laufzeit/Compilezeit auf die Zielplattform übersetzt werden. Spezielle Renderer (z. B. HTML/Swing Renderer) sind erforderlich, die die ab- strakten UI-Elemente auf die Zielplattform abbilden.

Automatische GUI-Extraktion

Ein weiteres entwickeltes Konzept zur Transformation der Benutzeroberfläche sieht vor, die Software am Anfang nicht manuell zu zerlegen, sondern zunächst die Elemente der GUI aus dem Programmcode zu extrahieren, um damit die Darstellung vom Programm- code mit Werkzeugunterstützung abzuspalten. Das Ergebnis dieses Transformations- schritts ist eine Beschreibung der Benutzeroberfläche in einer UI-Beschreibungssprache. Anhand des Syntaxbaums des Programmcodes werden die Quellcodeteile identifiziert, welche am Aufbau der GUI beteiligt sind. Da die GUI aus den Elementen einer Stan- dardbibliothek aufgebaut ist, kann der größte Teil der Elemente (statische Elemente) au- tomatisch erkannt werden. Im nächsten Schritt werden die extrahierte UI-Beschreibung und die verbliebene Geschäftslogik zu einer MVC-Architektur zusammengefügt. Dieser Schritt erfolgt manuell, wird jedoch durch ein Werkzeug unterstützt. Die daraus gewon- nene MVC-Beschreibung der GUI kann im Nachgang wie im ersten Konzept weiter transformiert werden. Abbildung 7.2 skizziert die Funktionsweise dieses Konzepts.

104 7.6 Rahmenarchitektur von CBFRAME

Rich Client Web Browser

View (Windows Forms) Client

IIOP/ Web Services HTTP

GUI Elements Presentation

GUI Logic

Controller Business Objects Application Server

Persistence Layer Model Database Database

Abbildung 7.3: Architektur von CBFRAME für Web-Clients.

7.5.3 Zusammenfassung

Um die grafische Oberfläche einer monolithische Software in eine moderne, plattform- unabhängige Darstellung zu transformieren, wurden zwei Konzepte vorgestellt. Ziel ist die Transformation einer monolithischen Anwendung in eine Movel-View-Controller- Architektur. Prototypisch wurde ein Werkzeug entwickelt, das eine statisch definierte GUI aus einem Delphi-Programm extrahiert und in eine Java Swing GUI transformiert (siehe Abschnitt 10.2, Seite 144). Dabei wird die Geschäftslogik manuell mit Werk- zeugunterstützung übertragen. Die wenigen sprachspezifischen Details, die nicht auto- matisch transformiert werden konnten, beispielsweise Grafiken auf Buttons, können im Nachgang mit einem grafischen Editor komfortabel übertragen werden.

7.6 Rahmenarchitektur von CBFRAME

Aus den Betrachtungen der Architektur in 7.3 genannter ERP-Systeme und den Unter- suchungen der Middleware-Plattformen lässt sich eine Architektur für die Zielsoftware abgrenzen. Die hier gezeigte Architektur ist ein Vorschlag für eine Zielkonfiguration, die zu Beginn der Softwaretransformation vom Entwickler festgelegt werden muss. Zu- grunde liegt hier eine Transformation von Delphi nach JavaEE unter Verwendung einer verteilten Architektur.

105 7 Entwurf eines Client-Server-Frameworks CBFRAME

Abbildung 7.3 zeigt die Softwarearchitektur der Zielsoftware, wenn die Ausgangssoft- ware in eine Web-basierte Anwendung überführt werden soll. Wichtig in dieser Archi- tektur ist die strikte Trennung der einzelnen Softwareteile in die verschiedenen Schich- ten. Auf der Serverseite wird ein JEE-Application-Server eingesetzt, der die Business- Logik kapselt und die Kundendaten in der Datenbank bereitstellt. Der Controller auf Serverseite enthält die Logik zur Erzeugung der entsprechenden grafischen Benutzero- berfläche, die eng an die Business-Logik gekoppelt ist. Eine weitere Schicht, die Prä- sentationsschicht, dient zur Generierung der Ausgabe an die Clients. Da verschiedene Clients, z. B. Browser oder Rich-Clients, angebunden werden sollen, kann in der Präsen- tationsschicht schon auf die entsprechende Ausgabestufe Einfluss genommen werden. Die Web-Clients sind über HTTP (oder HTTPS) an den Server angebunden. Die Web- Tier kann z. B. mit Glassfish oder Tomcat realisiert werden. Soll ein Rich-Client ange- bunden werden, z. B. Delphi-Clients, ist es möglich, die Verbindung zum Server ent- weder über Webservices zu realisieren oder das IIOP-Protokoll17 einzusetzen. Um IIOP verwenden zu können, muss eine CORBA-Implementierung, die Delphi unterstützt, mit dem CORBA-Broker der JEE-Implementierung kommunizieren. Die Gesamtarchitektur ist in verschiedene Schichten untergliedert. Die einzelnen Schichten bilden die statischen Komponenten des Frameworks. Diese sind z. B. die Per- sistenzschicht oder die Präsentationsschicht. Die Implementierung wird bei der Fest- legung der Transformationsparameter vom Benutzer festgelegt. Beispielsweise könnte eine dynamische Instanziierung für die Gesamtarchitektur wie folgt aussehen: • Präsentationsschicht → Apache Tomcat mit JSF (Java Server Faces) oder JSP (Java Server Pages), • Applikationsserver → Sun Glassfish, • Workflow-Engine → activeBPEL18, • Persistenzschicht → Hibernate19, • Datenbank → MySQL20. Die gewählten Instanziierungen bezüglich der Architektur für die Zielsoftware defi- nieren damit auch die möglichen Sicherheitskonzepte und Kommunikationsprotokol- le. Wird z. B. eine BPEL-Engine verwendet, muss diese im Kern der Business-Logik- Schicht verankert sein. Das bedeutet aber auch, dass auf die BPEL-Prozesse, die als Webservices angeboten werden, mit HTTP oder HTTPS zugegriffen werden kann.

7.7 Zusammenfassung

Dieses Arbeitspaket beschäftigte sich mit dem Entwurf eines Client-Server-Frame- works, in welches die Ausgangssoftware transformiert werden soll. Dabei wurden be- sonders freie Softwareprodukte und Open Source-Technologien untersucht. Die Ana- lyse verschiedener ERP-Systeme ergab, dass das Framework mehrschichtig ausgelegt

17Internet Inter-ORB Protocol 18http://www.activevos.com/community-open-source.php 19https://www.hibernate.org/ 20http://www.mysql.com

106 7.7 Zusammenfassung sein sollte, um die flexible Anbindung verschiedenster Technologien zu ermöglichen. Eine sogenannte Middleware wie CORBA oder JEE dient dabei als Zwischenschicht. Die Anbindung der grafischen Oberfläche wurde untersucht und die Transformation der GUI in eine Model-View-Controller-Architektur vorgeschlagen, damit die GUI mit einer modernen Widget-Bibliothek wie Swing realisiert werden kann. Die vorgestellte Rah- menarchitektur von CBFRAME trägt all diesen Anforderungen Rechnung indem sie auf aktuelle Technologien aus dem Java-Umfeld aufbaut, um auch zukünftige Erweiterun- gen zu ermöglichen. Die konkrete Auswahl einzelner Technologien, die die vorgestellten Konzepte umsetzen, wird im folgenden Kapitel vorgestellt.

107 7 Entwurf eines Client-Server-Frameworks CBFRAME

108 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

8.1 Zielsetzung

Nachdem im vorherigen Arbeitspunkt die Architektur des Frameworks CBFRAME um- rissen wurde, ist die Realisierung der Infrastruktur des Frameworks Inhalt dieses Ar- beitspunktes. Hierzu soll untersucht werden, welche Workflow-Sprache sich für die Umsetzung der im Projekt betrachteten Geschäftslogik eignet. Nach Festlegung einer Workflow-Beschreibungssprache, ist eine Kommunikationsplattform zu entwerfen, über die die Workflow-Prozesse Daten untereinander austauschen können. Um die genann- ten Ziele umzusetzen, werden zuerst verschiedene Beschreibungssprachen für Business- Workflows auf ihre Eignung hinsichtlich der Integration in CBFRAME untersucht. In ei- ner Fallstudie wird danach aufgezeigt, wie sich die Kommunikation zwischen Legacy- und erneuertem Softwaresystem realisieren lässt. Dazu wird eine Leistungsdiagnostik einzelner Kommunikationslösungen durchgeführt.

8.2 Workflow-Beschreibungssprachen

8.2.1 EPK

Die Ereignisgesteuerte Prozesskette (EPK) wurde an der Universität des Saarlandes ent- wickelt [32] und ist nunmehr integrativer Bestandteil des ARIS-Konzepts (Architektur Integrierter Informationssysteme) der IDS Scheer. Die EPK ist eine grafische Model- lierungssprache, mit der sich Geschäftsprozesse einer Organisation beschreiben lassen. Geschäftsprozessbeschreibungen in EPK sind nicht ausführbar, können aber von ver- schiedenen Übersetzungswerkzeugen in ausführbaren Code zur Einbettung in eine Busi- ness-Applikation transformiert werden. Eine EPK wird durch einen gerichteten Graph repräsentiert, dessen Knoten Ereignisse oder Funktionen darstellen können, wie in Ab- bildung 8.1 rechts dargestellt ist. Die Kanten und Konnektoren geben die Richtung des Kontrollflusses an. Ein Ereignis stellt den Zustand des Prozesses dar, der vor oder nach dem Ausführen einer Funktion vorliegt. Die Funktionsknoten bezeichnen eine Aufgabe, wobei sich diese auch aus Teilgeschäftsvorgängen zusammensetzen kann.

109 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

Abbildung 8.1: Beispiel grafisch modellierter Business Prozesses. (Links: BPMN, Rechts: EPK)

8.2.2 BPMN

Eine weitere grafische Spezifikationssprache für den Ablauf von Geschäftsprozessen ist die Business Process Modeling Notation (BPMN)[1]. Diese Sprache wird von der Ob- ject Management Group (OMG) gepflegt und ist seit 2006 offiziell ein OMG-Standard. Geschäftsprozessbeschreibungen in BPMN sind ebenfalls nicht direkt ausführbar und dienen vornehmlich der Visualisierung. Wie die EPKs definiert auch die BPMN eine Reihe von grafischen Elementen, mit denen die Workflows modelliert werden können. Diese grafischen Elemente unterteilen sich in die folgenden vier Kategorien: Flow Ob- jects, Connecting Objects, Swimlanes und Artifacts. Abbildung 8.1 links zeigt einen mit BPMN modellierten Geschäftsprozess. Die Flow Objects definieren die Knoten des Prozessgraphen, d. h. sie bezeichnen z. B. Aktivitäten, Tasks oder einen Entscheidungs- punkt. Die Connecting Objects sind die Kanten im Graph und definieren sowohl die Reihenfolge der Aktivitäten als auch die zu übertragenden Nachrichten. Mit Hilfe der Swimlanes kann eine Aktion oder ein Ereignis an bestimmte Benutzer geknüpft wer- den. Damit lassen sich Benutzerrollen definieren. Artifacts sind weitere Elemente wie Annotationen oder Datenobjekte.

8.2.3 Bewertung grafischer Modellierungswerkzeuge

Die Beschreibungssprachen EPK und die BPMN dienen hauptsächlich der grafischen Modellierung der Geschäftsprozesse und sind nicht direkt ausführbar. Die Beschrei- bungssprachen sind so definiert, dass sie von den technischen Details der Ausführung abstrahieren, um die Modellierung aus betriebswirtschaftlicher Sicht zu unterstützen. Geschäftsprozesse können somit von wirtschaftswissenschaftlichen Fachkräften ohne technisches Personal modelliert werden. Für eine Umsetzung in ein Software-Produkt ist aber eine Transformation in eine ausführbare Workflow-Beschreibungssprache not- wendig. Zu diesen ausführbaren Prozessbeschreibungen zählen z. B. die jBPM Process Definition Language (JPDL), die XML Process Definition Language (XPDL) und die

110 8.2 Workflow-Beschreibungssprachen

Business Process Execution Language (BPEL). Diese ausführbaren Workflow-Beschrei- bungssprachen werden im Folgenden näher untersucht.

Der Einsatz von EPK oder der BPMN innerhalb der transformierten Software ist von den Kundenwünschen abhängig. Ein Software-Framework wie CBFRAME wird nur die Möglichkeit der Ausführung eines Workflows bereitstellen können. Die grafische Mo- dellierung liegt dann in der Hand des Kunden. Allerdings kann bei der Übertragung von EPKs nach XPDL oder von BPMN nach BPEL schon auf bestehende Werkzeuge zurückgegriffen werden [8].

8.2.4 JPDL

Die jBPM Process Definition Language (JPDL1) lehnt sich stark an die Java-Techno- logie an. JPDL ist Teil des jBPM, das ein von JBoss entwickeltes Software-Framework zur Modellierung von Geschäftsprozessen darstellt. JPDL nutzt ähnliche Notationen wie BPMN, z. B. Tasks, Actions oder Swimlanes. Eine Stärke von JPDL ist die Unterstüt- zung von Langzeitprozessen (long running processes), die oft mit Human-Tasks ver- knüpft sind. Die Definition des Workflows erfolgt in einem XML-Format, wobei der Workflow als gerichteter Graph mit Knoten und Kanten abgelegt ist. Die Bereitstellung der Beschreibungssprache im JEE-Stack von JBoss bietet den Vorteil, dass die Inte- gration in Java-Enterprise-Applikationen weniger Zwischenschichten erfordert. Auszu- führende Anweisungen und Tasks können direkt als Java-Code mit der entsprechen- den Aktion verknüpft werden. Die Ausführungsumgebung jBPM übernimmt somit für eine komplexe Geschäftssoftware das gesamte Zustandsmanagement. Die Verbindung mit Java macht es einfach, JPDL um eigene Konstrukte zu erweitern. Im Kontext von TransBS hat diese Nähe zu Java den Nachteil der Sprachabhängigkeit. Da eine schritt- weise Transformation der Legacy-Software stattfinden muss, ist es notwendig, möglichst unabhängig von der Programmiersprache zu sein. Andererseits ist die Sprache nicht of- fiziell standardisiert und beschränkt sich auf den Applikationsserver von JBoss. Ist je- doch die betrachtete Ausgangssoftware eine Java-Applikation und die Verwendung von JBoss ist erwünscht, so ist JPDL ein guter Kandidat für eine Beschreibungssprache von Arbeitsabläufen.

8.2.5 XPDL

Die XML Process Definition Language (XPDL2) ist eine XML-basierte Sprache zur Modellierung von Geschäftsprozessen als Workflows. Die Entwicklung und Standar- disierung von XPDL wird von der Workflow Management Coalition (WfMC3) voran- getrieben. Die Version 2.0 der XPDL, die 2005 veröffentlicht wurde, unterstützt den

1http://www.jboss.com/products/jbpm 2http://www.wfmc.org/standards/xpdl.htm 3http://www.wfmc.org

111 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

BPMN-Standard zur grafischen Repräsentation eines Workflows. Durch die Standardi- sierung der Sprache eignet sich XPDL als Austauschformat zwischen Workflow-Mo- dellierungswerkzeugen. Außerdem existieren mehrere XPDL-kompatible Ausführungs- umgebungen (Engines), mit denen XPDL-basierte Prozessabläufe ausgeführt werden können. Eine solche Engine ist z. B. Enhydra Shark4, die als Open Source-Version zur Verfügung steht.

8.2.6 BPEL

Eine weitere XML-basierte Beschreibungssprache von Workflows ist die Business Pro- cess Execution Language (BPEL [2]). Sie liegt seit April 2007 als WS-BPEL in der Ver- sion 2.0 vor. BPEL dient primär der Orchestrierung von Webservices, weshalb Nutzerin- teraktionen nicht Teil des Standards sind. Für die Integration von Human Tasks wurde eine Erweiterung mit dem Namen BPEL4People veröffentlicht, welche einige Herstel- ler von BPEL-Ausführungsumgebungen implementieren. Im Gegensatz zu XPDL bietet BPEL keine standardisierte grafische Repräsentation eines Workflows. BPEL hat sich in den letzten Jahren als eine Art Industriestandard zur Ausführung von Geschäftsprozes- sen etabliert. Dazu beigetragen haben eine Reihe von verfügbaren Ausführungsumge- bungen und zahlreiche freie sowie kommerzielle Entwicklungswerkzeuge.

8.2.7 Fazit

Die Integration einer Verarbeitungsmöglichkeit von Workflows in Business-Software- Produkte ist eine komplexe Aufgabe. Für die jeweilige Ausgangssoftware muss ge- prüft werden, welche Faktoren die Wahl der Beschreibungssprache und der Ausfüh- rungsumgebung beeinflussen [35]. Die Evaluation verschiedener freier ERP-Systeme in Abschnitt 7.3 zeigte, dass JPDL im Java-Umfeld häufig genutzt wird. Speziell beim Ein- satz von JBoss bietet sich JPDL als Workflow-Beschreibungssprache an, da die Ausfüh- rungsumgebung mitgeliefert wird. Für große Java-basierte Projekte ist JPDL ein guter Kandidat, da sich die Workflow-Beschreibungssprache recht zügig in den Java-Entwick- lungsprozess integrieren lässt. Bei BPEL muss man z. B. vorher genau festlegen, welche Funktionen als Webservices bereitzustellen sind, um darauf einen BPEL-Workflow auf- setzen zu können. Trotzdem ist die Workflow-Beschreibungssprache JPDL durch die Bindung an Java und JBoss sowie durch ihre Nichtstandardisierung kein Kandidat für die weiteren Betrachtungen in TransBS. Ein direkter Vergleich von XPDL und BPEL ist schwierig, da auch hier die Ausgangsfaktoren die Entscheidung bestimmen. Im Ge- gensatz zu BPEL bietet XPDL eine grafische Darstellung der Geschäftsprozesse. Der Nachteil von XPDL ist, dass es im Vergleich zu BPEL nur eine kleine Zahl an Engines und Editoren gibt. Das Fehlen einer grafischen Darstellung fällt bei BPEL nicht ins Ge- wicht, wenn das Entwicklungswerkzeug eine Übersetzung von BPMN-Modellen nach

4http://www.enhydra.org/workflow/shark

112 8.3 Vergleich verschiedener BPEL-Implementierungen

BPEL unterstützt. Die häufige Verwendung in Industrieprojekten sowie die größere An- zahl freier Entwicklungsumgebungen hat den Ausschlag gegeben, dass wir BPEL als Beschreibungssprache von Workflows genauer untersuchen.

8.3 Vergleich verschiedener BPEL-Implementierungen

BPEL stellt nur einen Sprachstandard dar, für den verschiedene Implementierungen von unterschiedlichen Herstellern existieren. Im Folgenden wird eine aktuelle Bestandsauf- nahme der verschiedenen BPEL-Implementierungen (genannt BPEL-Engines) und de- ren Funktionsumfang durchgeführt. Verglichen werden folgende BPEL-Engines:

• Sun BPEL Engine (Sun Microsystems), • activeBPEL (Active Endpoints), • intalio Server (Intalio).

Die Tabelle 8.1 enthält einen detaillierten Vergleich der Eigenschaften der verschiedenen BPEL-Engines. Alle drei BPEL-Engines bedienen sich der Java-Plattform, um Plattfor- munabhängigkeit zu gewährleisten. Eine Integration in eine Geschäftssoftware bedarf einer genauen Analyse der Lizenzierungsproblematik. Alle drei Engines werden als freie Open Source-Produkte angeboten, es muss jedoch trotzdem die Kompatibilität der Open Source-Lizenz mit dem Geschäftsmodell geprüft werden. Sollten die Open Source-Li- zenzen nicht genügen, muss eine kommerzielle Version gekauft werden, was einen nicht unerheblichen Kostenfaktor darstellt. Darüber hinaus wird oft die kommerzielle Versi- on benötigt, um den gesamten Funktionsumfang, speziell den des grafischen Designers, nutzen zu können. Alle untersuchten Produkte unterstützen die Standards WS-BPEL und BPEL4WS, der Sun BPEL Engine fehlt jedoch im Gegensatz zu den Konkurrenten die Erweiterung BPEL4People. Andererseits ist die Sun BPEL Engine in die Sun-eigene Entwicklungsumgebung NetBeans integriert. Eine solche Entwicklungsumgebung gibt es für die activeBPEL-Engine nur in der kommerziellen Variante. Wichtig ist ebenfalls der Funktionsumfang, der von den Engines umgesetzt wird. Die Sun BPEL Engine setzt nur Grundfunktionen der Standards um, wohingegen ihn die anderen Implementierun- gen nahezu vollständig abdecken.

Als Fazit dieses Vergleichs lässt sich angeben, dass zwar alle Firmen ihre Produk- te (Engines) auch als freie Varianten anbieten, deren Funktionsumfang gegenüber der kommerziellen Variante jedoch stark eingeschränkt ist. Die Erstellung von ausführbaren Workflows mit BPEL kann nur durch grafische Modellierungswerkzeuge effizient und produktiv realisiert werden. Diese Designer sind meist nur in der kommerziellen Version enthalten oder im Leistungsumfang wie bei NetBeans noch relativ begrenzt.

Trotzdem bietet die activeBPEL-Engine das beste Gesamtpaket für eine weiterführen- de Untersuchung der Integration in eine Legacy-Software. Aus diesem Grund wird die activeBPEL-Engine von Active Endpoints verwendet, da sie als Open Source-Produkt

113 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks ukinufn u rnfntoe ermctgsh mächtig sehr Tasks mächtig Human sehr & BPEL4People u.a. (Java) (MPL) alle License intuitiv Public sehr Mozilla Tasks Human & BPEL4People Grundfunktionen nur (community) Geronimo Apache Bedienung Unterstützung keine (Java) alle Funktionsumfang (welche) umgebung Entwicklungs- in Integration GPL User-Interaction Tomcat engine Apache (BPEL BPEL-Standard v2 Glassfish Unterstützter (Jan09) (Java) Version GPLv2 alle aktuelle und CDDL Server Application System Java Sun (Preis) Version kommerzielle Betriebssystem Glassfish Lizenz server Application u PLEgn ciePLitloServer intalio terprise activeBPEL Engine BPEL Sun a(eBas a(ciePLDsge,ae kom- aber Designer, (activeBPEL ja Einarbeitungszeit) (mittlere BPEL4WS & 2.0 WS-BPEL BPEL4WS & (NetBeans) 2.0 ja WS-BPEL BPEL4WS & 2.0 WS-BPEL 080408_1 Standard Socket (pro VrlihvrcidnrBPEL-Ablaufumgebungen. verschiedener Vergleich 8.1: Tabelle 10 . 000 ) US$) 2 . 000 S,En- US$, build Nachfolgejahren) e Jahr ers- ten im CPU-Sockel (pro activeVOS hh Einarbeitungszeit) (hohe mittelmäßig merziell) .. 5.2.1 5.0.2 17 . 000 US$, 25 . 000 S in US$ nai nepieEdition Enterprise ( intalio 8%Oe Source) Open (80% sh oeEinarbeitungszeit) hohe (sehr überfrachtet Designer) (Intalio ja > 10 . 000 S Jahr) / US$

114 8.4 Untersuchung der Kommunikationseigenschaften von JEE zur Verfügung steht und einen Großteil des BPEL-Standards abdeckt. Außerdem imple- mentiert die Engine die Standards BPEL4People und Human Tasks, welche speziell für Geschäftsprozesse mit Nutzerinteraktionen gebraucht werden.

8.4 Untersuchung der Kommunikationseigenschaften von JEE

Ein weiterer wichtiger Punkt in diesem Arbeitspaket ist die Entwicklung einer Kommu- nikationsplattform für die transformierte Geschäftssoftware. Da im vorangegangenen Arbeitspunkt die Java-Enterprise-Edition als Grundlage der Basisarchitektur der Ziel- software ausgewählt wurde, konzentrieren sich die Betrachtungen in diesem Abschnitt auf Kommunikationslösungen zwischen Legacy-Software und JEE-Applikationsserver.

8.4.1 Anbindung von Legacy-Software über JMS

Bei der Umstellung oder schrittweisen Erneuerung einer Legacy-Anwendung müssen oft verschiedene Kommunikationspfade aufrecht erhalten werden. Es können bspw. Tei- le einer Legacy-Software über veraltete Protokolle angebunden sein, oder der Nachrich- tenaustausch zwischen Softwareteilen wurde speziell für diesen Einsatz entwickelt. Ver- wendet man nun einen JEE-Applikationsserver als Basisbaustein, müssen ältere Dienste transparent angebunden werden. Aus diesem Grund stellt der JEE-Stack auch den Java Message Service (JMS5) bereit. JMS bildet eine einheitliche, standardisierte Schnittstel- le zur Benutzung einer Message Oriented Middleware (MOM). Damit können Nach- richten asynchron und transparent zwischen verschiedenen Softwareteilen ausgetauscht werden. JMS bietet zwei Kommunikationsmuster. Bei der Point-to-Point-Kommunika- tion erstellt ein Producer eine Nachricht, die dann von einem Consumer aus der ent- sprechenden Schlange entnommen wird. Das andere Muster ist Publish-and-Subscribe, wobei die Nachrichten nach Themen getrennt werden. Ein Consumer kann sich für ein Thema (topic) anmelden und erhält alle Nachrichten, die an die entsprechende The- menschlange gesendet werden. Durch die asynchrone und zeitlich entkoppelte Verar- beitung von Nachrichten lassen sich Legacy-Anwendungen integrieren.

In diesem Kontext wurde untersucht, wie schnell eine Datenkommunikation über JMS durchgeführt werden kann. Die Tests sollten zum einen die Performance von JMS un- tersuchen, zum anderen aber auch die Verwendung von JavaBeans innerhalb des Pro- jekts verdeutlichen. Es wurde ein Ping-Pong-Test durchgeführt, der oft für Latenz- und Brandbreitenmessungen verwendet wird. Der Versuchsaufbau ist auf der linken Seite von Abbildung 8.2 veranschaulicht. Dabei verbindet sich der Java-Client mit dem Server und legt eine Nachricht in der Nachrichtenschlange des Servers ab. Der Server startet das zugehörige Bean, welches die Nachricht annimmt, eine neue Antwortnachricht erzeugt

5http://java.sun.com/products/jms

115 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

Ping pong, 2 Hosts, 100 MBit Ethernet

10 jms mpi 9

8

7

6

5

4 Durchsatz [MB/s] 3

2

1

0 1 2 4 8 16 32 64 128 256 512 Nachrichtengröße [kB]

Abbildung 8.2: Vergleich des erzielten Durchsatzes von JMS und MPI. und diese dem Client zurückschickt. Im Fall von JMS wird jeweils eine Nachrichten- schlange für ein Empfangsthema (receive topic) und ein Antwortthema (reply topic) auf dem Applikationsserver erstellt. Ein JavaBean überwacht die beiden Schlangen auf dem Server. Der Client schickt eine Nachricht an das Empfangsthema des Servers. Damit wird das JavaBean aufgerufen, welches als Empfänger dient. Das JavaBean kopiert die Nachricht in das Antwortthema, bei dem sich der Client angemeldet hat. Somit wird die Nachricht zurück zum Client übertragen.

Als JEE-Server-Implementierung wurde Glassfish6 gewählt, da es sich dabei um eine freie Implementierung des aktuellen JEE5-Standards handelt. Die Abbildung 8.2 zeigt den erzielten Durchsatz von JMS im Vergleich zu MPI7 (Message Passing Interface) bei Verwendung eines 100-Mbit Ethernet-Netzwerks. Wie zu erwarten war, kommt JMS nicht an die Durchsatzraten von MPI heran. Speziell bei kleinen Nachrichten ist der zeit- liche Overhead durch den größeren Softwarestack deutlich höher. Da der Overhead im JEE-Softwarestack bei steigender Nachrichtengröße annähernd konstant bleibt, spielt er jedoch bei genügend großen Nachrichten keine entscheidende Rolle mehr. Müssen Nachrichten zwischen Legacy-Applikationen verschickt werden, kann JMS eingesetzt werden. Es ist zu bedenken, dass diese transparente Schnittstelle auch einen gewissen Overhead nach sich zieht, gerade wenn viele kleine Nachrichten verschickt werden müs- sen.

8.4.2 Anbinden von Delphi-Clients an JEE-Applikationsserver

Um eine Kommunikationsplattform für eine verteilte Zielarchitektur festzulegen, ist zu untersuchen, wie die Clients mit dem Server Daten austauschen. Die eingesetzten Kom- munikationsprotokolle sind von der Ausgangssoftware abhängig. Im Fall von TransBS 6https://glassfish.dev.java.net/ 7http://www.mcs.anl.gov/mpi

116 8.4 Untersuchung der Kommunikationseigenschaften von JEE

Abbildung 8.3: Mögliche Anbindung des GBware-Clients an Java Enterprise Server soll die Software GBware prototypisch transformiert werden. Da diese Software eine in Delphi geschriebene, grafische Benutzeroberfläche (GUI) besitzt, stellt sich die Frage, ob und wie diese Oberfläche weiterverwendet werden kann. Ein wichtiges Argument für die Weiterverwendung von grafischen Benutzerschnittstellen ist die Kundenzufrie- denheit. Oft besteht der Wunsch, vertraute Oberflächen weiter zu verwenden.

Das Hauptproblem dabei liegt in der Verbindung von neuen (Web-Interface) und al- ten Bestandteilen (GUI-Logik-Code, GUI-Bibliothek) des Programms. Hierzu können Techniken der EAI (Enterprise Application Integration) zum Einsatz kommen, die ver- schiedene Wege bietet (Bridging, Wrapping, Adapter), um ehemals autonome Program- me miteinander zu verbinden [30]. Das ermöglicht den Datenaustausch der verschiede- nen Systeme und erhöht damit die Effizienz des Gesamtsystems.

Eine mögliche Konfiguration von GBware vor und nach der Transformation ist in Abbil- dung 8.3 dargestellt. Die ursprüngliche Variante verwendet das proprietäre DCOM zur Kommunikation zwischen Client und Applikationsserver. Für die Zielsoftware ist dann eine geeignete Anbindung des DCOM-Clients zu finden. Es wäre möglich,

a) eine DCOM-CORBA-Bridge zu realisieren, die etwa DCOM-spezifische Klassen, wie das TDataSet, durch ein CORBA-Äquivalent ersetzt, b) eine DCOM-RMI-Bridge analog zu gestalten, oder c) die Delphi-Clients mittels HTTP (SOAP) mit Webservices kommunizieren zu las- sen.

Mit der CORBA-RMI-Bridge wäre man sehr nah an der Sprache Java, die auch vom Ap- plikationsserver verwendet wird, da RMI Bestandteil des Java-Basisframeworks ist. Da- durch muss weniger Wrapper- und Adaptercode geschrieben werden, um diese Anbin- dung zu realisieren. Folglich lässt sich diese Bridge nur für Java einsetzen. Die DCOM- CORBA-Bridge würde die Beschränkung auf Delphi und Java lockern. Es werden aber zusätzliche Softwareschichten benötigt, die diese Abstraktion realisieren. Die Bridging- Varianten sind zwar relativ schnell im Vergleich zu SOAP, können aber durch die Ver- wendung von unterschiedlichen Bibliotheken verschiedener Hersteller (CORBA-Imple- mentierungen, keine CORBA-Standards für Delphi) schneller zu Fehlern im System führen. Eine Kommunikation mit SOAP scheint auf den ersten Blick, speziell für einfa- che GUI-Aktionen, mit viel Overhead verbunden.

117 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

Abbildung 8.4: CORBA-JEE-Bridge.

8.4.3 Kommunikation mit Enterprise JavaBeans über CORBA

Ein grafischer Delphi-Client, der wiederverwendet werden soll, muss neben der internen Realisierung der UI-Elemente auch Serverfunktionen nutzen, die zuvor über DCOM an- gebunden waren. Um eine erfolgreiche Transformation einzelner Softwarekomponenten zu ermöglichen, ist es nötig, sich von DCOM zu lösen und andere Mechanismen für den Datenaustausch innerhalb von GBware einzusetzen. Dazu wurde eine Testapplikation betrachtet, die die grundlegende Funktionalität des GBware-Clients implementiert. Ziel war es, eine schrittweise Transformation dieser Testapplikation zu entwickeln, um sich von den DCOM-Serverobjekten lösen zu kön- nen. Nach genauerer Analyse der verschiedenen Kommunikationsmöglichkeiten bietet die Verwendung von CORBA die nötige Flexibilität und Robustheit, um einzelne Tei- le der Altsoftware auszulagern und sicher wiederzuverwenden. Dazu wurde eine Bei- spielapplikation erstellt, welche den Kommunikationspfad zwischen Delphi und Java exemplarisch implementiert. Eine mögliche Realisierung einer Delphi-JEE-Schnittstelle ist in Abbildung 8.4 darge- stellt. In dieser Variante greift der Delphi-Client mittels CORBA auf Java-Objekte des Servers zu. Da das Anbinden von JavaBeans innerhalb eines Java-Clients leichter ist als die Anbindung von CORBA-Code direkt am JEE-Server, verwendet das Beispiel einen JavaBeans-Proxy. Der Proxy kommuniziert via CORBA mit dem Delphi-Client und setzt die Aufrufe entsprechend auf JEE-Funktionen um. Diese Lösungsmöglichkeit wurde im Folgenden anhand einer Testapplikation evaluiert. In dieser Applikation lokalisiert ein Delphi-Client ein verteiltes Objekt, das in Java im-

118 8.5 Zusammenfassung

Abbildung 8.5: Zugriff auf Java-Routinen von Delphi. plementiert ist, via CORBA. Dieses Objekt stellt den Java-Proxy dar und muss bei einem CORBA-Namensserver registriert werden. Der Delphi-Client hat dann die Möglichkeit, freigegebene Schnittstellen des Java-Objekts zu benutzen. In unserem Fall wird eine Fließkommazahl vom Java-Server an den Delphi-Client übermittelt. Für den Fall, dass man einen JEE-Server anbinden möchte, muss das Java-Proxy-Objekt die Aufrufe an den JEE-Server weiterleiten. Die Abbildung 8.5 zeigt exemplarisch die Funktionsweise des Testprogramms. In der linken Konsole wird das Delphi-Client-Programm gestartet, dass die GUI enthält. In der oberen Konsole wird der Namensserver gestartet, in diesem Fall der SunORB aus dem Java Development Kit. Als CORBA-Implementierungen für Delphi und Java kamen Visibroker und JacORB8 zum Einsatz. Der Delphi-Client holt sich auf Anfrage beim CORBA-Namensserver eine Referenz auf ein verteiltes Java- Objekt beim Java-Server und kann dann dessen Methoden aufrufen.

8.5 Zusammenfassung

Die Ziele des Arbeitspunktes waren die Wahl einer Beschreibungssprache für Workflows und die Auswahl einer Kommunikationsplattform für die transformierte Software.

Dazu wurden verschiedene Workflow-Beschreibungssprachen auf ihre Eigenschaften hin und auf ihre mögliche Verwendung innerhalb einer Geschäftssoftware untersucht.

8http://www.jacorb.org

119 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks

Es hat sich dabei gezeigt, dass der BPEL-Standard sehr weit verbreitet ist und von vie- len Unternehmen unterstützt und eingesetzt wird. BPEL bietet eine gute Grundlage, um Geschäftsprozesse zu automatisieren oder externe Services von Drittanbietern zu inte- grieren. Infolgedessen wurden verschiedene BPEL-Ausführungsumgebungen (Engines) miteinander verglichen, um weitere Tests für die prototypische Implementierung reali- sieren zu können. Die konkrete Wahl einer BPEL-Engine ist aber von den Vorausset- zungen der Ausgangssoftware, den Kundenwünschen und eventueller Lizenzbeschrän- kungen (bspw. GPL9) abhängig. Da sich der Funktionsumfang der betrachteten freien BPEL-Engines unterscheidet, muss für den gegeben Fall geprüft werden, ob alle benö- tigten Funktionen zur Verfügung stehen.

Nach Wahl einer Workflow-Sprache und einer Ausführungsumgebung können einzelne Geschäftsprozesse im neuen System modelliert und umgesetzt werden. Die BPEL-Engi- nes arbeiten dazu mit den JavaEE-Servern zusammen, welche die einzelnen Teilprozesse implementieren und als Webservices bereitstellen. Es wurden verschiedene Kommuni- kationsplattformen untersucht, die es ermöglichen Daten zwischen Teilen der Legacy- Software und der erneuerten Software auszutauschen, um bspw. die Einarbeitung in die erneuerte Software zu erleichtern indem die ursprüngliche grafische Oberfläche in der modernisierten Software wiederverwendet wird. Eine mögliche Variante ist die Integra- tion der alten oder neuen Softwarebestandteile über den JMS (Java Message Service), welche genauer untersucht wurde. Speziell für die im Projekt betrachtete Delphi-Softwa- re wurde des Weiteren analysiert, wie die grafische Oberfläche der Client-Anwendung weiterverwendet werden kann. Dazu wurde ein Kommunikationsmodell entwickelt und prototypisch umgesetzt, in dem der Delphi-Client über CORBA mit einem Java-Objekt kommuniziert. Zur Anbindung eines JavaEE-Servers leitet dann das über CORBA er- reichbare Java-Objekt Funktionsaufrufe und Daten an den JavaEE-Server weiter.

9GNU General Public License, http://www.gnu.org/copyleft/gpl.html

120 9 Entwicklung und Realisierung des prototypischen Client-Server-Frameworks

9.1 Zielsetzung

Nachdem die grundlegende Softwarearchitektur und die Kommunikationsplattform fest- gelegt wurden (siehe Kapitel 7 und 8), werden diese nun prototypisch anhand von Test- szenarien umgesetzt. Dazu ist ein Client-Server-Framework zu entwickeln, welches die verteilte Ausführung von Geschäftsprozessen ermöglicht. Für das gewählte Testszenario ist deshalb ein Kommunikationsprotokoll zu wählen, über welches die verteilten Prozes- se Daten austauschen können. Wichtig ist hierbei die Frage nach der Datenkonsistenz und der Datenkonvertierung in dem verteilten System. Die Ergebnisse der Arbeiten zu diesen Fragestellungen werden in diesem Kapitel darge- stellt. Zuerst wird gezeigt, wie sich Geschäftslogik aus Legacy-Code herauslösen lässt, um diesen auf einem entfernten Rechner auszuführen. Die Extraktion von Code basiert auf der Analyse von Mustern in der abstrakten Softwarebeschreibung (FSR vgl. Ab- schnitt 6.1.2). Das Werkzeug zur Erzeugung und Verarbeitung der abstrakten Software- beschreibung, TRANSFORMR, wurde in Kapitel 6 vorgestellt. Um die extrahierten Co- deteile wieder in der Ausgangssoftware zu verwenden, wird das CBFRAME-Framework entwickelt, das die entfernten Funktionen transparent mit dem JavaEE-Server verbindet. Nachdem die gewünschten Funktionen ausgelagert sind, können sie auch als Services (bspw. Webservice) angebunden werden. Um einen hohen Durchsatz zu erzielen und um die Ausfallsicherheit des Systems zu erhöhen, können diese Services redundant von verschiedenen Servern angebunden werden. Die Service-Redundanz wirft jedoch auch die Frage auf, welcher Server eine Anfrage bearbeiten soll. Aus diesem Grund wird auch diese Fragestellung innerhalb dieses Arbeitspunktes betrachtet.

9.2 Das CBFRAME-Remote-Adapter-Pattern

Das neu entwickelte CBFRAME-Remote-Adapter-Pattern bezeichnet eine Transforma- tion, die aus mehreren Teilschritten zusammengesetzt ist. Das primäre Ziel des CBFRA- ME-Remote-Adapter-Pattern ist es, die Software so umzuformen, dass einzelne Teile von dedizierten entfernten Servern bereitgestellt werden. Im ersten Schritt muss die Software mit ihren Abhängigkeiten analysiert werden. Dazu wird nach einem zuvor fest definier- ten Muster gesucht, welches eine verteilte Ausführung des Codes ermöglicht. Hat man

121 9 Das Client-Server-Framework dieses Muster gefunden, kann es im nächsten Schritt durch ein Zielmuster ersetzt wer- den. Da u. U. nicht alle notwendigen Informationen für eine Auslagerung des Codes vorhanden sind, muss an dieser Stelle der Entwickler eingreifen und die entsprechen- den Details bereitstellen. Diese Informationen sind abhängig vom betrachteten Muster und von der Zielplattform, z. B. dem Namen des Zielservers oder des zu verwendenden Ports.

Es wird an einem Beispiel gezeigt, wie das CBFRAME-Remote-Adapter-Pattern in der Praxis benutzt werden kann. Dazu wird ein nicht-paralleles Java-Programm so trans- formiert, dass einzelne Berechnungsfunktionen von einem Server via RMI automatisch angebunden werden. Des Weiteren zeigen wir die Integration dieser Mustertransforma- tion in das Werkzeug TRANSFORMR.

9.2.1 Musterbasierte Quellcodetransformation

Das Aufspalten von Software zur späteren parallelen Ausführung kann mit unterschied- lichen Verfahren realisiert werden. Die weitgehend automatische Transformation des Legacy-Codes stand jedoch in unserem Projekt im Mittelpunkt. Um die Quellcodeteile zu finden, die eine abgeschlossene Funktionalität enthalten und automatisch transfor- miert werden können, wird eine umfassende Analyse der Ausgangssoftware benötigt. Wie in Kapitel 6 beschrieben, bietet das Transformationswerkzeug TRANSFORMR eine Analyse des Quellcodes bezüglich der Abhängigkeiten zwischen den Klassen der Soft- ware an, wodurch sich UML-Klassendiagramme der Software generieren lassen.

Die UML-Klassendiagramme dienen der Visualisierung der Softwarestruktur und der betrachteten Muster in der abstrakten Softwarebeschreibung (FSR). Ein Muster ist ein Teilbaum der FSR. Die FSR kann benutzt werden um eine Mustertransformation an- zuwenden. Da die Schnittstellen zwischen den Klassen klar definiert sind, lassen sich einzelne Klassen oder ganze Gruppen von Klassen durch andere Muster (Teilbäume) ersetzen, sofern sie die definierten Schnittstellen zu den unberührten Codeteilen imple- mentieren. Der Vorteil einer solchen FSR-basierten Transformation liegt in der automa- tischen Anwendbarkeit. Außerdem lassen sich bei Bedarf auch Transformationsschritte rückgängig machen. Ein weiterer Vorteil besteht in der Unterstützung des Entwicklers bei der Codetransformation. Ist ein Ausgangsmuster definiert, kann ein Werkzeug wie TRANSFORMR automatisch nach diesem Muster innerhalb der FSR suchen und Trans- formationsmöglichkeiten aufzeigen. Dies ist besonders hilfreich, wenn das Projekt Hun- derte Klassen umfasst und die Abhängigkeiten vom Entwickler kaum überblickt werden können.

Die Abbildung 9.1 verdeutlicht die Schritte der musterbasierten Transformation.

1. Zuerst wird mit Hilfe des Analysewerkzeugs die Struktur der Software ermittelt. Dabei wird die Baumstruktur der abstrakten Softwarebeschreibung aufgebaut. Es wird angenommen, dass die verfügbaren Transformationsmuster über eine Daten- bank verfügbar seien.

122 9.2 Das CBFRAME-Remote-Adapter-Pattern

Abbildung 9.1: Schematische Darstellung der schrittweisen Anwendung einer muster- basierten Transformation.

2. Das Transformationswerkzeug versucht dann, anhand der bekannten Muster mög- liche Transformationen zur Anwendung anzubieten, von denen der Entwickler ei- ne auswählt. 3. Das vom Entwickler gewählte Ausgangsmuster wird in diesem Schritt durch ein Zielmuster ersetzt. 4. Je nach Zielmuster muss bei der Transformation neuer Code generiert werden. Typischerweise ist Adaptercode notwendig, um das Zielmuster an die bestehende Altsoftware und die neue Zielplattform anzupassen.

Im betrachteten Beispiel (Abbildung 9.1) wird ein bestimmtes Ausgangsmuster (P, dar- gestellt im UML-Klassendiagramm) mit Hilfe eines Zielmusters in eine neue Plattform eingebettet. Der ursprüngliche Code bleibt erhalten, muss aber mit Adaptercode, dem speziellen CBFRAME-Pattern, an die Ursprungssoftware angebunden werden. In un- serem Beispiel sind zwei Adapter zu erzeugen. Der Erste verbindet den alten Teil der Software mit dem herausgelösten Ausgangsmuster, wohingegen der zweite Adapter für die Einbettung in die neue Plattform sorgt.

9.2.2 Verteilte Ausführung von Geschäftslogik

Ein wichtiges Kriterium für die Modernisierung von GBware ist die Verwendung einer verteilten Ausführungsumgebung und die Bereitstellung und Nutzung externer Services. Hinsichtlich dieser Voraussetzungen wurden bereits verschiedene Software-Plattformen in Abschnitt 7 auf ihre Verwendungsmöglichkeit untersucht. In dieser Analyse hat sich

123 9 Das Client-Server-Framework die JavaEE-Plattform als Kandidat für die Nutzung als CBFRAME-Basis herauskris- tallisiert. Ein Hauptaugenmerk des Transformationsvorhabens liegt auf der Erzeugung einer Client-Server-Anwendung aus einer ursprünglich nicht verteilt laufenden Appli- kation. Um dieses Ziel zu erreichen, wurde die automatische Einbettung von Klassen der Legacy-Software in die JavaEE-Plattform untersucht, wobei musterbasierte Trans- formationen eine tragende Rolle spielen.

Eine Möglichkeit Software in eine Client-Server-Anwendung zu überführen, ist die Ver- wendung entfernter Funktionsaufrufe (RPC, remote procedure calls). Durch RPC lassen sich Methoden oder Funktionen transparent auf einen Server auslagern, ohne explizite Kommunikations- oder Synchronisationsaufrufe im Code verwenden zu müssen. Da- mit bleibt der aufrufende Code weitestgehend unverändert. Die Java-Plattform bietet die Remote Method Invocation (RMI)1 an, um einen entfernten Methodenaufruf zu imple- mentieren.

Im folgenden Abschnitt wird gezeigt, wie Funktionen aus einer Legacy-Software her- ausgelöst werden können und wie diese mittels RMI auf einem entfernten Server zur Verfügung gestellt werden. Verwendet wird dazu der musterbasierte Transformationsan- satz mit dem speziellen Transformationsmuster “CBFRAME-Remote-Adapter-Pattern”.

9.2.3 Definition des CBFRAME-Remote-Adapter-Pattern

Das Ziel beim Entwurf des CBFRAME-Remote-Adapter-Pattern lag darin, Funktionen auf entfernte Server auszulagern, ohne (größere) Modifikationen am Ursprungscode vor- nehmen zu müssen. Der Großteil des benötigten Adaptercodes sollte sich automatisch generieren lassen. Das Auslagern von Funktionen bietet unterschiedliche Vorteile für ei- ne gegebene Geschäftssoftware. Rechenintensive Funktionen können auf schnelleren Serverrechnern angeboten werden, was die Arbeitsgeschwindigkeit verbessern kann. Durch die transparente Auslagerung lassen sich auch sicherheitskritische Berechnun- gen integrieren. Anstatt alle unternehmenskritischen Daten, die für eine Berechnung notwendig sind, auf dem Client vorzuhalten, genügt es, dass Ergebnis zum Client zu übertragen.

Unter Beachtung dieser Anforderungen entstand das Transformationsmuster CB- FRAME-Remote-Adapter-Pattern. Die UML-Repräsentation des Musters ist in Abbil- dung 9.2 dargestellt. Grafik 9.2(a) zeigt das notwendige Ausgangsmuster in der zu trans- formierenden Software und Grafik 9.2(b) stellt das zugehörige Zielmuster dar. Das In- terface LegacyFeature enthält die Funktionen, die ausgelagert werden sollen, z. B. die Methode doWork(). Diese Funktionen werden von mindestens einer Klassen reali- siert oder implementiert, hier angegeben als LegacyImplementation. Um die Im- plementierung der Klasse LegacyImplementation möglichst transparent für den Rest der Software auszutauschen, muss eine neue Klasse erstellt werden, die dieselben Methoden aus LegacyFeature erbt. Dies ist die Klasse LegacyRemoteAdapter, die dafür sorgt, dass der Aufruf von doWork() transparent umgeleitet werden kann.

1http://java.sun.com/javase/technologies/core/basic/rmi/

124 9.2 Das CBFRAME-Remote-Adapter-Pattern

(a) Ausgangsmuster (b) Zielmuster

Abbildung 9.2: UML-Darstellung des CBFRAME-Remote-Adapter-Pattern.

Das Ziel dieser Umleitung ist die Klasse LegacyRemoteFeatureProvider, die wiederum die Methoden des Interfaces LegacyRemoteFeature implementiert. Die Klasse LegacyRemoteFeatureProvider besitzt eine Referenz auf die ursprüng- liche Klasse LegacyImplementation und ruft intern diese Methoden auf.

Der Vorteil der Verwendung eines Interfaces auf Serverseite ist, dass man später auch andere Implementierungen hinzufügen kann, ohne an der Client-Software Änderungen vornehmen zu müssen. Das vorgestellte Transformationsmuster “CBFRAME-Remote- Adapter-Pattern” basiert auf dem Entwurfsmuster “Proxy”. Dabei ist der Zugriff auf ein Objekt nur noch über das vorgelagerte Proxy-Objekt möglich. Ein Proxy-Objekt dient dazu, die eigentliche Implementierung des Ursprungsobjekts vor dem restlichen Softwaresystem zu verstecken. In diesem Fall fungiert LegacyRemoteAdapter als Proxy-Objekt.

Um die Veränderung im Code zu veranschaulichen, werden die ursprüngliche Aufruf- kette und die nach der Transformation entstandene Aufrufkette miteinander verglichen. Angenommen, eine Klasse X in der Ursprungssoftware besitzt eine Variable obj vom Typ LegacyImplementation. Um das Ergebnis der Funktion doWork() zu erhalten, ruft diese Klasse X obj.doWork(param) auf. Nachdem die Transfor- mation durchgeführt wurde, besitzt die Klasse X nun eine Variable obj2 vom Typ LegacyRemoteAdapater. Über die Variable obj2 wird nun wiederum doWork() aufgerufen, jedoch mit folgender veränderter Aufrufkette: obj2.doWork(param) → legacyRemoteProvider.doRemoteWork(param) → obj.doWork(param).

9.2.4 Anwendung des CBFRAME-Remote-Adapter-Pattern

Nach Erarbeitung des Transformationsmusters wurde ein Prototyp eines Transformati- onswerkzeugs implementiert. Die Arbeitsweise des Transformationswerkzeugs ist sche- matisch in Abbildung 9.3 dargestellt. Das Werkzeug arbeitet auf dem Quellcode der Ausgangssoftware (Legacy-Quellcode). Des Weiteren benötigt jedes Transformations- muster zur Umsetzung eine gewisse Zahl an Code-Templates, um die Ausgangsklas-

125 9 Das Client-Server-Framework

Abbildung 9.3: Anwendung des CBFRAME-Remote-Adapter-Pattern zur automati- schen Auslagerung von Methoden auf entfernte Server. sen anzupassen. Außerdem sind Konfigurationsdateien notwendig, die musterspezifi- sche Definitionen enthalten. Zur Anwendung von CBFRAME-Remote-Adapter-Pattern gehören die folgenden Angaben:

• Name der Legacy-Klasse, • Informationen über auszulagernde Methoden (Namen, Rückgabewerte, Parame- terliste), • Name der zu generierenden Server-Klassen (Vermeiden von Namenskonflikten), • Art der Transformation (z. B. Erzeugung von RMI-Code mit eindeutiger Objekt- Nummer).

Mit diesen Informationen kann das Transformationswerkzeug den Quellcode des Ur- sprungsprogramms bearbeiten.

Abbildung 9.4 zeigt ein Beispiel-Template eines Serverprogramms, das Funktionen via RMI bereitstellt. Die Variablen, die mit “«..»” gekennzeichnet sind, dienen als Platz- halter und werden vom Transformationswerkzeug mit konkreten Werten ersetzt. Ne- ben der einfachen Variablenersetzung werden auch komplette Methoden, wie z. B. bei “«RemoteInterfaceImplementation»”, automatisch generiert.

Um CBFRAME-Remote-Adapter-Pattern zu testen, wurde eine typische Legacy- Anwendung in Java implementiert. Diese Anwendung besteht aus einer grafischen Be- nutzeroberfläche, welche verschiedene Fraktal-Implementierungen, wie z. B. eine Man- delbrot-Menge, berechnet und anzeigt. Es wurde untersucht, wie diese Applikation um- zugestalten ist, damit eine Auslagerung von Funktionalität auf den Server realisiert wer- den kann. Das Ziel bestand darin, dass eine vom Entwickler gewählte Implementierung einer Fraktalberechnung auf einen entfernten Server ausgelagert wird. Dieses Ziel steht stellvertretend für andere zeitaufwendige Berechnungen in Business-Anwendungen, wie z. B. rechenintensive Berichte oder Optimierungs- und Planungsaufgaben, welche nach Möglichkeit von einem schnellen Rechner ausgeführt werden sollten.

Die Anwendung wurde daraufhin so verändert, dass eine der Fraktal-Implementierun- gen von einem anderen Serverrechner durchgeführt wird. Wichtig dabei ist, dass der Ur-

126 9.2 Das CBFRAME-Remote-Adapter-Pattern

package <>; import java.io.IOException; import java .rmi.AlreadyBoundException; import java .rmi.RemoteException; import java.rmi. registry .LocateRegistry; import java.rmi. registry .Registry; import java.rmi. server .UnicastRemoteObject;

<> p u b l i c class <> implements IMandelbrotRemoteCalculator {

p r i v a t e <> <>= new <>();

p u b l i c <>(){}

<>

p u b l i c s t a t i c void main(String[] args) {

t r y { <> server = new <>(); RemoteProperties props = new RemoteProperties ();

<> stub = (<>) UnicastRemoteObject .exportObject(server , props.getInPort ());

Registry registry = LocateRegistry.getRegistry(props.getServerName()); registry .bind("<>", stub);

} catch (Exception e) { System. err . println(e.getMessage()); } } }

Abbildung 9.4: Beispiel eines Templates zur automatischen Erzeugung eines Servicean- bieters auf Serverseite (RMI). sprungscode möglichst wenig Änderungen erfährt. Im besten Fall sollte nur die Instan- tiierung der Legacy-Klasse ausgetauscht werden müssen. Das Ergebnis einer solchen Transformation ist in Abbildung 9.5 zu sehen. Der Screenshot zeigt das bereits transfor- mierte Legacy-Programm. Das Fraktal-Bild wird vom Server (Terminals auf der rechten Seite) generiert, vom Client empfangen und dort angezeigt. In unserer prototypischen Implementierung wird RMI als Protokoll eingesetzt. Die Java Runtime bietet für RMI eine Serialisierung der Daten mittels IDL an und kann so als Marshalling-Komponente dienen.

9.2.5 Integration in TRANSFORMR

Dieser Abschnitt beschreibt, wie die musterbasierte Transformation des “CBFRAME- Remote-Adapter-Pattern” in das Werkzeug TRANSFORMR integriert werden kann. Um die automatische Erzeugung von Adaptercode zu unterstützen ist es sinnvoll Code- Templates zu verwenden. Dazu wurden verschiedene Template-Sprachen auf ihre An- wendbarkeit überprüft und getestet. Sogenannte Template Engines ermöglichen die Er-

127 9 Das Client-Server-Framework

Abbildung 9.5: Screenshot des erzeugten Client/Server-Programms zur Berechnung ei- nes Mandelbrot-Bildes. Die Berechnung des Bildes wird vom Server btn2xp durchgeführt und beim lokalen Client angezeigt.

setzung von Platzhaltern in allgemeinen Templates (Textdokumente, Quellcode, etc.) zur Anpassung an konkrete Anforderungen. Das können beispielsweise Namen oder Adres- sen in Seriendokumenten sein. Die Velocity-Engine der Apache Foundation war dabei am leichtesten und flexibelsten zu verwenden. Apache Velocity ermöglicht darüber hin- aus mehr Funktionen als das in Abschnitt 6.4 beschriebene Ersetzungwerkzeug zur Co- de-Erzeugung. Über Hashmaps und Listen können komplexe Java-Objekte von einem aufrufenden Java-Programm (TRANSFORMR) an Velocity übergeben werden. Auf diese Objekte kann mittels Referenz zugegriffen und deren definierte Methoden aufgerufen werden. Außerdem besteht die Möglichkeit, die Reflection-Funktionalität von Java zu nutzen, was speziell bei der Generierung der Adapter-Klassen vorteilhaft ist, da über eine Instanz des Objekts alle Funktionen sowie deren Parameter und Rückgabewerte zu- gegriffen werden können. Darüber hinaus bietet Velocity Sprachmittel wie Conditionals und Schleifen, womit die Code-Generierung besser strukturiert werden kann. Die Ab- bildung 9.6 zeigt exemplarisch ein Velocity-Template zur Generierung eines Remote- Interface für eine spezifische Zielklasse.

Die Funktion zum Auslagern von Klassen steht nach der Integration in TRANSFORMR als Transformationsmittel zur Verfügung, siehe Abbildung 9.7.

128 9.2 Das CBFRAME-Remote-Adapter-Pattern

package $remote.get( ’TargetPackage’); import java .rmi.Remote; import java .rmi.RemoteException; p u b l i c interface $remote.get( ’LegacyRemoteInterface’) extends Remote {

# f o r e a c h ($interface in $interfaces) #methodAutomaticallyGenerated () #makeRemoteMethodSignatur($interface "$interface.getName()Remote")

# end }

Abbildung 9.6: Velocity-Template zur Generierung eines Remote-Interface.

Abbildung 9.7: Implementierung des CBFRAME-Remote-Adapter-Pattern für Java und RMI in TRANSFORMR.

9.2.6 CBFRAME-Remote-Adapter-Pattern für Webservices

Um eine Legacy-Anwendung in ein Webservice-orientiertes System zu überführen, müssen ausgewählte Funktionen als Service extrahiert, modelliert und ausgelagert wer- den. Mit dem beschriebenen CBFRAME-Remote-Adapter-Pattern können ausgewähl- te Funktionen des Legacy-Programms auf einen externen Server ausgelagert werden. In dem zuvor betrachteten Fall wurde das Client-Programm über Java und RMI an die Serverfunktionen angebunden. Nun sollte diese Funktionalität auf Webservices er- weitert werden. Webservices werden über eine standardisierte Schnittstellenbeschrei- bung (Web Service Description Language, WSDL2) verfügbar gemacht. Diese XML- Beschreibungssprache deklariert Schnittstelle und Übergabeparameter, sowie die mög- lichen Übertragungsprotokolle, um auf den Webservice zuzugreifen. Dadurch sind Webservices flexibler einsetzbar als RMI-Aufrufe, welche eine Java-Umgebung voraus- setzen. Wenn die benötigten Funktionen als Webservice vorliegen, ist es sinnvoll, diese als Business-Workflow mit BPEL zu modellieren. Die Abbildung 9.8 zeigt die ange- wendete Transformationsmethode. Zuerst muss, z. B. mit TRANSFORMR, die Legacy- Anwendung analysiert werden. Entscheidet sich der Entwickler dafür, eine gewählte Funktion als Webservice anzubieten, wird diese mit Hilfe des TRANSFORMRs extra- 2http://www.w3.org/TR/wsdl

129 9 Das Client-Server-Framework

Abbildung 9.8: Exemplarische Bereitstellung einer Funktion als Webservice. hiert. Da diese Funktion in Delphi geschrieben ist und möglicherweise komplexe Rou- tinen ausführt, wäre eine Neuimplementierung zwar möglich, aber wirtschaftlich nicht rentabel. Aus diesem Grund wird die auszulagernde Funktion via Wrapper-Funktion im Java-Server integriert. Die Wrapper-Funktion bietet nach außen eine Java-Schnittstelle an und sorgt für die Konvertierung und die Übergabe der Parameter an die ursprüngli- che Delphi-Funktion. Der Java-Server kann diese Funktion als Webservice nach außen zur Verfügung stellen. Außerdem lässt sich die Funktion, nachdem sie als Webservice zur Verfügung gestellt wurde, sowohl von anderen Webservices als auch als Teil eines BPEL-Workflows benutzen.

Die beschriebene Vorgehensweise der Auslagerung einer Legacy-Funktion auf einen Webserver wurde prototypisch implementiert. In einer Evaluation des Prototyps wurden folgende Fragestellungen ausgewertet:

1. Ist eine automatische Transformation einer Funktion in einen Webservice möglich und wie viel Zusatzinformation benötigt das Transformationswerkzeug? 2. Wie viel Overhead (bzgl. der Zeit) ist mit der Auslagerung einer einfachen Funk- tion auf einen Webserver verbunden?

Im Experiment wurde die Funktion aus Abbildung 9.9 als Webservice angeboten. Als Webservice-Provider wurden hierzu Tomcat 5.53 als Application-Server und Axis24 als Webservice-Engine verwendet. Außerdem wurde diese Funktionalität nativ (in C) reali- siert und via Java-Wrapper-Funktion als Webservice angeboten. In dieser Variante wird aus der Java-Funktion mittels Java-Native-Interface (JNI) eine C-Funktion aufgerufen, die eine Legacy-Funktion charakterisieren soll. Bei der Implementierung des Webser- vice zeigte sich, dass zum Auslagern der Funktion als Webservice im Vergleich zu RMI

3http://tomcat.apache.org/ 4http://ws.apache.org/axis2/

130 9.3 Effiziente verteilte Workflow-Abarbeitung

f l o a t celsiusToFarenheit ( f l o a t c e l s i u s ) { return ( c e l s i u s * 9 / 5 ) + 32; }

Abbildung 9.9: Als Webservice ausgelagerte Funktion. zusätzlich nur Informationen über den Webserver (Port) notwendig sind. Die generel- len Transformationsschritte sind analog zur Implementierung des CBFRAME-Remote- Adapter-Pattern mit RMI. Tabelle 9.1 stellt die Antwortzeiten der verschiedenen Funktionsrealisierungen gegen- über. Wie zu erwarten war, ist der lokale Aufruf einer Java-Funktion schneller als die Benutzung eines Wrappers, der eine native C-Funktion aufruft. Im Gegensatz zum lo- kalen Aufruf einer Funktion muss bei einem Webservice mit einem gewissen Overhead gerechnet werden. Die durchschnittliche Antwortzeit der Webservice-Funktion lag in diesem Test bei 3.8 ms. Das ist zwar im Verhältnis zu lokalen Aufrufen recht viel, aber für eine Integration von externen Services, deren Rechenzeit lokal ein Vielfaches der Webservice-Antwortzeit betragen kann, akzeptabel. Es wird ebenso deutlich, dass das Wrapping einer nativen Funktion für die Antwortzeit eines Webservices keine entschei- dende Rolle spielt.

Tabelle 9.1: Vergleich der Antwortzeiten einer Funktion für unterschiedliche Kontexte.

Art der Messung mittlere Antwortzeit [ms] Aufruf als einfache Java-Funktion 17 · 10−6 Aufruf als native C-Funktion aus Java via 33 · 10−6 JNI Aufruf des Webservices aus Java 3.8 (1 GBit Ethernet, 2 Hops)

Die Tests der Java- und der C-Funktion sowie der Webserver wurden auf einem Intel Core2 Duo (3 GHz, 4 GB, Linux x86_64, Java 1.5) ausgeführt. Der Webservice-Client, der den Webservice aufruft, wurde auf einem QuadCore Xeon (2.5 GHz 32 GB, Linux x86_64, Java 1.6) ausgeführt.

9.3 Effiziente verteilte Workflow-Abarbeitung

9.3.1 Problemstellung und Ziele

Für die betrachteten Workflows wurde in Abschnitt 8.2 BPEL als Modellierungsspra- che ausgewählt. BPEL Workflows orchestrieren üblicherweise eine Reihe von exter- nen Diensten (z. B. Webservice). Ein externer Dienst kann von verschiedenen Anbietern

131 9 Das Client-Server-Framework

Abbildung 9.10: Workflowabarbeitung mit räumlich verteilten, redundanten Dienstan- bietern (Providern). bereitgestellt werden. Die Dienstanbieter (Provider) sind durch Nutzung des Internets oftmals räumlich verteilt. Darüber hinaus können externe Dienste durch mehrere red- undante Anbieter bereitgestellt werden, um beispielsweise eine gestiegene Anzahl von Anfragen bearbeiten zu können oder eine hohe Verfügbarkeit zu sichern. Im vorange- gangenen Abschnitt wurde beschrieben, wie verschiedene Komponenten einer Legacy- Software als externe Dienste ausgelagert werden können. Dabei wurde die Auslagerung als Webservice favorisiert, um die externen Dienste in einem BPEL-Workflow-Prozess einbinden zu können. Zusätzlich können in BPEL auch Dienste anderer externer Anbie- ter eingebunden werden. Die beispielhafte Verwendung räumlich verteilter, redundanter Dienstanbieter ist in Abbildung 9.10 dargestellt. Redundant ausgelegte Dienste führen nur zu einer Verbesserung der Verfügbarkeit und der Performance, wenn die Dienst-Anfragen gleichmäßig über die verfügbaren Dienst- Anbieter verteilt werden. Um die redundanten Dienste jedoch effizient nutzen zu kön- nen, bedarf es einer Lastbalancierungsstrategie. Hierbei ist zu beachten, dass verschie- dene Dienst-Anbieter unterschiedlich lang für die Beantwortung einer Anfrage benö- tigen können. Dies ist in der unterschiedlichen Ausstattung der Server und auch in deren momentaner Auslastung begründet. Ein effizientes Verfahren zur Lastverteilung sollte demnach unterschiedliche Anfrage-Geschwindigkeiten unterstützen und auch die Veränderung der Anfrage-Geschwindigkeit eines Dienstes unter Last berücksichtigen. Üblicherweise werden kommerziell angebotene Dienste im Web durch ihre Dienstgüte charakterisiert (Quality of Service). Die Dienstgüte ist jedoch oftmals nur als Mindest- dienstgüte beschrieben und sagt nichts über die momentane Güte aus. Demnach können Quality of Service Eigenschaften nur als „worst-case“ Abschätzung dienen und wurden deshalb nicht weiter betrachtet. Weiterhin stellen externe Dienste eine Abfrage der Aus- lastung zur Laufzeit eventuell nicht zur Verfügung. Deshalb beschränkt sich das nachfol- gend vorgestellte Verfahren auf die Auswertung von Informationen, die die Workflow-

132 9.3 Effiziente verteilte Workflow-Abarbeitung

Abbildung 9.11: Der Ausgangs-Workflow (oben) und der transformierte Workflow (un- ten) mit Scheduler zur Lastbalancierung der Webservice-Aufrufe.

Ausführungsumgebung (in diesem Fall die BPEL-Engine) im laufenden Betrieb selbst sammeln kann.

Ein weiteres Problem ist die Modellierung der Lastverteilung in einem bereits vorhan- den BPEL-Prozess. In BPEL-Prozessen finden sich üblicherweise statisch formulierte Webservice-Aufrufe, die auf einen bestimmten Anbieter festgelegt sind. Um jedoch eine gute Lastbalancierung zu erreichen, müssen die Aufrufe zu Webservice-Anbietern dy- namisch anpassbar sein. Zielsetzung ist es, die vorhandenen BPEL-Workflows nicht neu schreiben zu müssen, sondern eine automatische Transformation des BPEL-Prozesses zu realisieren.

9.3.2 Automatische Transformation von BPEL-Prozessen

In [21] wurde im Rahmen von TransBS ein Verfahren entwickelt, welches es ermög- licht, einen günstigen Webservice-Anbieter zur Laufzeit dynamisch auszuwählen. Dazu wurde in die favorisierte BPEL-Engine activeBPEL eine Scheduler-Funktion integriert, die Informationen über die zur Verfügung stehenden Anbieter sammelt und aufgrund der vorangegangenen Webservice-Aufrufe entscheidet, welcher Anbieter sich gut für

133 9 Das Client-Server-Framework die Ausführung des nächsten Webservice-Aufrufs eignet. Dem Scheduler werden die verfügbaren Anbieter zu jeder Dienstart bekannt gemacht. Die Scheduler-Funktion wur- de als Java-Klasse implementiert und ist über activeBPEL-Erweiterungen als Dienst innerhalb der activeBPEL-Engine für alle BPEL-Prozesse verfügbar. Aus Sicht eines BPEL-Prozesses wird der Scheduler wie ein Webservice aufgerufen. Im Deployment- Descriptor des BPEL-Prozesses, der Informationen über die Kommunikation des BPEL- Prozesses nach außen enthält, wird der Webservice-Aufruf auf den internen Scheduler abgebildet. Die Integration des Scheduling-Mechanismus ist zwar für die activeBPEL- Engine proprietär, jedoch lassen sich auch in andere BPEL-Engines individuelle Erwei- terungen integrieren.

Der gegebene BPEL-Prozess wird automatisch transformiert, indem vorhandene Web- service-Aufrufe von Aufrufen zur Scheduling-Funktion der Workflow-Engine einge- schlossen werden. Dies ist in Abbildung 9.11 für einen BPEL-Prozess mit zwei Web- service-Aufrufen dargestellt. Der vorherige Scheduler-Aufruf liefert den zur Ausfüh- rung des eigentlichen Dienst-Aufrufs günstigsten Anbieter zurück und der nachfolgende Scheduler-Aufruf zeigt den Abschluss des Dienst-Aufrufs an. Ein üblicherweise statisch definierter Webservice-Aufruf lässt sich zur Laufzeit anpassen. Dazu wird die Webser- vice-Addressing-Spezifikation (namespace wsa5) verwendet. Weitere Informationen sind unter dem Kapitel „Making BPEL Processes Dynamic“ in [10] zu finden. Im trans- formierten BPEL-Prozess (Abbildung 9.11 unten) werden verschiedene Webservice- Anbieter für die beiden Aufrufe genutzt.

9.3.3 Lastverteilungsverfahren für BPEL-Prozesse

Die modifizierten BPEL-Prozesse wurden auf einer activeBPEL-Engine in verschiede- nen Testszenarien untersucht. Dazu zählte nicht nur eine homogene Umgebung (alle Anbieter antworten gleich schnell), sondern auch eine heterogene Umgebung, in der die Anbieter aufgrund verschiedener Rechenleistungen unterschiedliche Antwortzei- ten für gleichartige Webservice-Aufrufe zeigen. Es wurden die folgenden Scheduling- Strategien miteinander verglichen:

• Round Robin (RR) Die Webservice-Aufrufe werden der Reihe nach über die vorhandenen Anbieter verteilt. • Lowest Counter First (LCF) Jeder Anbieter hat zu einem bestimmten Zeitpunkt etwa die gleiche Anzahl von Anfragen zu verarbeiten. Hierbei wird die momentane Auslastung berücksichtigt und stets der Anbieter mit der momentan geringsten Auslastung als nächster aus- gewählt. • Weighted Random (WR) Die Webservice-Aufrufe werden zufällig verteilt. Dabei sind die Auswahlwahr- scheinlichkeiten der einzelnen Anbieter nach der Dauer des letzten Aufrufs ge-

5http://www.w3.org/TR/ws-addr-core/

134 9.3 Effiziente verteilte Workflow-Abarbeitung

(200 ms web service call duration) (200 ms web service call duration) 40 120 2−LCF 2−LCF 2−RR 2−RR 35 2−WR 2−WR 4−LCF 100 4−LCF 4−RR 4−RR 30 4−WR 4−WR static static 80 25

20 60

15 40

Average execution time [s] 10 Average execution time [s] 20 5

0 0 2 4 6 8 10 12 14 16 18 20 2 4 6 8 10 12 14 16 18 20 # BPEL processes # BPEL processes

Abbildung 9.12: Durchschnittliche Ausführungszeit eines BPEL-Prozesses mit 10 Web- service-Aufrufen. Links: gleich schnelle Anbieter (homogen), Rechts: unterschiedlich schnelle Anbieter (heterogen).

wichtet. Schneller antwortende Anbieter werden mit höherer Wahrscheinlichkeit ausgewählt.

Es wurden Messungen mit 2 und 4 Anbietern durchgeführt. Dabei ruft der untersuchte BPEL-Prozess einen Webservice 10 mal nacheinander auf. Der Webservice führt einen Primzahltest durch und benötigt für größere Zahlen mehr Zeit zur Entscheidung als für kleinere. Die Antwortzeit des Webservices wurde durch entsprechende Wahl der Zahl im unbelasteten Zustand auf 200 ms kalibriert. Sie verlängert sich mit steigender An- zahl gleichzeitiger Aufrufe. In Abbildung 9.12 sind die gemessenen Ausführungszei- ten für den untersuchten BPEL-Prozess dargestellt. Alle Messungen wurden für gleich schnell und für unterschiedlich schnell antwortende Webservice-Anbieter durchgeführt. Die Kurven zeigen die drei Scheduling-Strategien (RR,LCF,WR) für 2 und 4 Anbieter. Zum Vergleich ist auch die Kurve des statischen BPEL-Prozesses abgebildet.

Die Ergebnisse unterscheiden sich stark zwischen der heterogenen und der homogenen Umgebung. Im homogenen Fall liegen alle drei Strategien nahezu gleich auf, wobei die durchschnittliche Ausführungszeit von WR leicht größer als die der anderen Stategien ist. Im heterogenen Fall ist dies jedoch nicht so, die RR-Strategie schneidet hier erwar- tungsgemäß schlecht ab, da sie die verschiedenen Antwortzeiten und die momentane Auslastung der Dienstanbieter nicht berücksichtigt. Die LCF-Strategie erzielt die besten Ergebnisse für eine große Anzahl von BPEL-Prozessen, ist aber für eine geringe Anzahl ungeeignet. Hier macht sich der ungünstige Fall bemerkbar, bei dem für wenige gleich- zeitige Aufrufe stets der langsamste Anbieter ausgewählt wird, da hier zwar die mo- mentane Last berücksichtigt wird, nicht aber die absolute Antwortzeit. Die WR-Strategie berücksichtigt die absolute Antwortzeit und ist somit für eine geringe Anzahl gleich- zeitig ausgeführter BPEL-Prozesse gut geeignet, jedoch bleibt sie oft etwas hinter der

135 9 Das Client-Server-Framework schnellsten Strategie zurück, da die Auswahl des nächsten günstigen Dienst-Anbieters hier zufällig erfolgt und somit keine Optimalität garantiert werden kann.

Die hier kalibrierte Antwortzeit des Webservice-Aufrufs von 200 ms stellt nur einen Ausschnitt der Messungen dar. Weitere Messungen haben gezeigt, dass für steigende Antwortzeiten die adaptiven Verfahren LCF und WR effizienter werden und die erfor- derliche zusätzliche Zeit (Overhead) für die Scheduling-Funktionalität prozentual sinkt. Für den Fall 200 ms konnte ein zusätzlicher Zeitaufwand von durchschnittlich 4-5 % festgestellt werden.

Wir konnten zeigen, dass unter Einbeziehung der Informationen über die vorangegan- genen Webservice-Aufrufe eine Verteilung über die verfügbaren Webservice-Anbieter erreicht werden konnte. Die durchschnittliche Ausführungszeit gegenüber der statisch implementierten Variante eines BPEL-Prozesses konnte signifikant verringert werden. Vor allem die zufällige Strategie WR hat sich als ausgewogen und praktikabel herausge- stellt.

9.4 Zusammenfassung

Ziel war es ein Framework zu entwickeln, welches die verteilte Ausführung von Ge- schäftsprozessen ermöglicht. Um eine Verteilung zu erreichen, wurde eine musterba- sierte Transformation des Legacy-Quellcodes vorgeschlagen. Es wurde gezeigt, wie das CBFRAME-Remote-Adapter-Pattern angewendet werden kann, um Teile der Legacy- Software auszulagern. Das Werkzeug TRANSFORMR konnte genutzt werden, um Mus- ter im Quellcode zu finden. Die Fähigkeit zur automatischen Auslagerung von Funktio- nalität wurde in TRANSFORMR integriert. Dabei wird der auszulagernde Quellcode über Adapter angebunden. Anhand einer Fallstudie wurde die Leistungsfähigkeit des Ver- fahrens überprüft. Die Anbindung des ausgelagerten Programmcodes kann über einen entfernten Funktionsaufruf oder über Webservices erfolgen.

Für die Abarbeitung der Geschäfts-Workflows wurde BPEL als Zielsprache zur Model- lierung ausgewählt. Dabei spielte auch die leichte Anbindung externer Dienste (Webser- vices) an BPEL Prozesse eine Rolle. Um die Performance und Ausfallsicherheit eines Softwaresystems zu erhöhen, wurde die Nutzung redundant ausgeführter Dienste vorge- schlagen. Um dies zu unterstützen, wurde eine Transformation für BPEL-Prozesse ent- wickelt, die es ermöglicht, den Dienstanbieter für einen Aufruf zur Laufzeit dynamisch auszuwählen. Dazu wurden auch Möglichkeiten der Lastbalancierung untersucht und verschiedene Möglichkeiten in heterogenen Umgebungen erprobt. Wir konnten zeigen, dass sich mit einer Verteilung der Dienstaufrufe eine Verbesserung der Gesamtperfor- mance des Softwaresystems erreichen lässt.

136 10 Prototypische Transformation der Referenzsoftware GBware

10.1 Prototypische Analyse und Transformation mit TRANSFORMR

Im Gegensatz zur weit verbreiteten Programmiersprache Java wird Delphi von einer kleineren Nutzergruppe eingesetzt. Dies wird in der Literatur oft mit der Plattformun- abhängigkeit und der Vielzahl auch frei verfügbarer Bibliotheken und Frameworks für Java begründet [47]. Delphi wird vor allem zur Entwicklung von Business-Software für die Windows-Plattform verwendet, in der eine Vielzahl von Nutzerschnittstellen und die grafische Darstellung von Daten im Vordergrund stehen. Hier bietet die enge und ausge- reifte Kopplung von Sprache und IDE (Delphi Professional) im Gegensatz zu Java eine standardisierte Möglichkeit (Rapid Application Development) in kurzer Zeit anspruchs- volle Anwendungen und ihre Anbindung an Datenbanken zu realisieren.

10.1.1 Anwendung von TRANSFORMR auf GBware

Für die Analyse und die Transformation von Programmiersprachen sind vor allem die Unterschiede der Grammatiken und der Sprachkonzepte bedeutend. Dabei können in- besondere in der Ausgangssprache verwendete Sprachkonzepte, die in der Zielsprache nicht vorhanden sind, zu Problemen führen. Im gemeinsamen abstrakten Softwaremo- dell müssen daher alle Sprachkonzepte angemessen repräsentiert werden.

Das Sprachkonzept von Delphi bietet, anders als Java, auf Grund der Abwärtskompati- bilität zu Borland Pascal die Möglichkeit zur Mischung von objektorientierter und pro- zeduraler Programmierung. In Java müssen dagegen alle Methoden und Variablen einer Klasse zugeordnet werden. Delphi unterscheidet in der Grammatik der Sprache zwi- schen einem Deklarationsteil (interface), in welchem öffentlich verfügbare Klassen und Attribute definiert werden, und einem Realisationsteil (implementation), der die ent- sprechenden Methodenrümpfe und weitere nicht öffentlich genutzte Klassen, Methoden und Variablen enthält. Die unterschiedlichen Varianten der Spezifikation von Klassen, Methoden und Variablen haben Auswirkungen auf ihre Sichtbarkeit und müssen ent- sprechend im erzeugten Modell behandelt werden. Der Delphi-Sprachstandard bietet Namespaces zur logischen Aufteilung des Programmcodes in einzelne Komponenten. Eine automatische Freispeicherverwaltung (Garbage Collection), wie sie in Java inte- griert ist, kann dabei nur über Frameworks (z. B. .NET-Framework) realisiert werden.

137 10 Prototypische Transformation der Referenzsoftware GBware

Abbildung 10.1: Aufbau von Delphi Programmcode. Das Delphi-Hauptprogramm nutzt Units direkt oder über Packages (statisch) bzw. Libraries (dynamisch zur Laufzeit möglich), die Units in einem separaten Modul enthalten.

Programmgerüst einer Delphi-Anwendung

Abbildung 10.1 zeigt den schematischen Aufbau einer Delphi-Anwendung bestehend aus Hauptprogramm (Delphi Program Main File), verschiedenen Units (evtl. in unter- schiedlichen Namespaces) und genutzten Bibliotheken, die als Package (Komposition von Units mit verfügbarem Programmcode oder als Dynamic Link Library (DLL) kom- piliert) oder Library (nur als DLL kompiliert) verfügbar sein können. Der Programmm- code einer Delphi Unit wird dabei in einer separaten Datei gespeichert. Das Hauptpro- gramm initialisiert die Anwendung und ruft die zum Start notwendigen Module aus den jeweiligen Units auf. Eine Unit bildet eine Einheit, die im Teil interface für andere Units sichtbare Klassen, statische Methoden oder statische Variablen deklariert. Im Abschnitt implementation wird die Realisierung der vorher deklarierten Methoden und Klassen angegeben. Zusätzlich können hier Methoden und Variablen deklariert und realisiert werden, die nur innerhalb der Unit verwendet werden können. Units können anders als in Java in beliebigen Unterverzeichnissen gruppiert werden. Eine Paketstruktur, die sich direkt auf die zu verwendende Verzeichnisstruktur auswirkt, wird in Delphi nicht ver- wendet.

Entwicklung einer Zuordnung zwischen Delphi-Sprachkonzepten und der FSR

Zur Extraktion der FSR aus einer Delphi-Anwendung wurden im TransBS-Projekt die Zuordnungen aus Tabelle 10.1 vorgeschlagen. Eine Delphi Unit wird in ein Module transformiert, das sowohl für andere Units sichtbare, als auch nicht sichtbare statische Submodule (Klassen) oder statische Methoden und Variablen enthält. Die Bezeichnung „statisch“ wird verwendet um deutlich zu machen, dass diese Elemente nicht an eine

138 10.1 Prototypische Analyse und Transformation mit TRANSFORMR

Tabelle 10.1: Zuordnung von Elementen einer Delphi Unit zu Modellelementen der FSR.

Delphi Programm Element FSR Element namespaces SubSystem structure unit (static) Module interface class (static) Submodule interface class method Submodule method interface class variable Submodule member variable interface method (static) Procedure interface variable (static) Variable implementation class (inner) Module implementation method (private static) Procedure implementation variable (private static) Variable

Instanz des übergeordneten Moduls gebunden sind, sondern unabhängig davon aufgeru- fen bzw. benutzt werden können. Somit bildet die Unit und ihr zugeordnetes Module nur einen Container für Klassen, statische Methoden und statische Variablen. Da für Delphi keine feste Verzeichnisstruktur vorgegeben ist, werden Namespaces zur Einordnung ei- nes Moduls in eine SubSystem-Struktur verwendet. Alle Modellelemente innerhalb von Methoden (Statements, Dependencies) werden analog zur Sprache Java abgebildet.

Die Erweiterung des Werkzeugs TRANSFORMR zur Unterstützung von Delphi als Eingabesprache, erfordert die Realisierung aller sprachabhängigen Komponenten von TRANSFORMR. Dies betrifft die Komponente Programm Code Access und Teile der Transformation Modules (siehe Abbildung 4.3, Seite 51) zur Analyse und Transforma- tion von Delphi-Programmcode sowie ein Code Model (siehe Abbildung 5.3, Seite 61) zur Referenzierung des Programmcodes aus dem Softwaremodell. Dabei können beste- hende Teile der Erzeugung von Modell bzw. Programmcode und Transformation wie beispielsweise die Verarbeitung von Kommentaren für Java wiederverwendet werden. Ein Hauptaugenmerk wurde in der prototypischen Realisierung auf die Vollständig- keit der verwendeten Grammatik für Delphi zur Analyse und Transformation von Pro- grammcode mit TXL und auf die Entwicklung von TXL-Transformationsregeln zur Ex- traktion der FSR gelegt. Die verwendete Grammatik wurde auf Basis einer für TXL verfügbaren Grammatik für Borland Delphi 2006 entwickelt. Durch die Weiterentwick- lung konnten auch Abweichungen zwischen dem Delphi-Compiler und der Sprachspe- zifikation in die Grammatik eingebracht werden, da einige der verwendeten Eingabe- daten Konstrukte verwendeten, die nicht in der Spezifikation beschrieben wurden, aber trotzdem vom Delphi-Compiler akzeptiert wurden. Somit kann ein breites Spektrum verschiedener Programmcodes mit TXL verarbeitet werden. Die entworfene Zuordnung der Elemente (Tabelle 10.1) wurde in einer Vielzahl von TXL-Transformationsregeln umgesetzt, die die XML-Strukturen der FSR aus dem Pro- grammcode aufbauen. Besonders aufwändig stellte sich die Zuordnung der Methoden- deklarationen im interface-Abschnitt zu den von Methodenrümpfen im implementati-

139 10 Prototypische Transformation der Referenzsoftware GBware

Abbildung 10.2: UML-Klassendiagramm eines Ausschnitts des betrachteten Pro- grammcodes. on-Abschnitt der Unit dar, da in TXL eine eindeutige Identifikation von Methoden an- hand von Methodensignatur und Elternknoten (Klassen, Units) im abstrakten Syntax- baum nur umständlich realisiert werden kann.

Prototypische Anwendung auf GBware

Für eine detaillierte Untersuchung wurde der Programmcode einer GBware Nutzer- schnittstelle (Abbildung 10.8) ausgewählt, die zur Erstellung oder zur Änderung eines Auftrags verwendet wird. Sowohl der Programmcode zum Aufbau der Nutzerschnitt- stelle als auch zur Behandlung der unterschiedlichen Ereignisse (z. B. Klicken auf einen Button) wurde prototypisch mit TRANSFORMR untersucht. Dabei war von besonderem Interesse in wie weit eine vollständige Analyse des Programmcodes (auch in Hinblick auf die verschiedenen Dialekte der Programmiersprache Delphi) möglich ist.

Es zeigte sich, dass die Analyse ohne weitere Anpassungen von Grammatik und Trans- formationsregeln durchgeführt werden konnte. Abbildung 10.2 zeigt den Ausschnitt ei- nes UML-Klassendiagramms als eine beispielhafte Visualisierung des betrachteten Pro- grammcodes. Da in Delphi Groß- und Kleinschreibung nicht unterschieden wird, wur- den alle Bezeichner während der Transformation in die FSR normalisiert (Anfangsbuch- stabe groß, weitere Zeichen klein), da innerhalb der FSR zur Abdeckung verschiedener Eingabesprachen Groß- und Kleinschreibung unterschieden wird.

Typisch für Software, die mit Delphi-Werkzeugen entwickelt wurde (inklusive Erstel- lung aller grafischen Ansichten), ist die Nutzung vieler Hilfsmodule, die nur sporadisch verwendet werden (nur wenige Zugriffe auf ihre Membervariablen oder -Funktionen)

140 10.1 Prototypische Analyse und Transformation mit TRANSFORMR und das Vorhandensein vieler Funktionen mit geringem Funktionalitätsumfang (bspw. im zentralen Modul Formprocorder in der Mitte von Abbildung 10.2).

Beim Verarbeiten des Programmcodes konnten Besonderheiten des Programmierstils bei der Firma BBS festgestellt werden. Beispielsweise erschwert die Erweiterung vie- ler GUI-Primitive um neue Eigenschaften deren Erkennen und Mappen auf bekannte Zielelemente einer anderen GUI-Bibliothek. Der Vorteil, dass Delphi einen bekannten (komplexen) GUI-Elementumfang hat, konnte also nicht umfänglich genutzt werden.

10.1.2 Anwendung von TRANSFORMR auf TurboCASH

TurboCASH ist ein Open Source Buchhaltungssystem für kleine Unternehmen bzw. Einzelunternehmen unter der GPL1. Es wurde seit 1985 zunächst als kommerzielle Soft- ware entwickelt und ist seit Juli 2003 frei verfügbar. Es besitzt eine Vielzahl von Kom- ponenten wie Einkauf, Verkauf, Kontoführung, Lagerhaltung, Steuerverwaltung, Rech- nungsmanagement, Kontensynchronisation, Module für Reporting und Analyse von Da- ten, sowie die Einbindung anderer Unternehmenssoftware.

Im Gegensatz zu GBware basiert TurboCASH auf einer 2-Schicht-Architektur bei der Business-Logik und Nutzerschnittstelle zu einer Schicht verschmelzen. Davon losgelöst existiert eine Datenbankschicht. Bis zur Version 3 wurde die Borland Database Engi- ne (BDE), eine Paradox Datenbank, verwendet. Ab Version 4 wird die freie Datenbank Firebird2 genutzt, die überwiegend konform zum SQL-2003 Standard ist. Durch die Verwendung der Datenbank Firebird kann TurboCASH auch als Multi-User-System be- trieben werden, indem verschiedene TurboCASH Installationen auf unterschiedlichen Clients auf eine gemeinsame Datenbank zugreifen.

Zur vollständigen Übersetzung des Programmcodes von TurboCASH in eine ausführ- bare Software, werden einige proprietäre Bibliotheken (z. B. Delphi 7 Professional oder Quick Reports), bedingt durch die langjährige kommerzielle Entwicklung, benötigt. Ei- ne Loslösung von proprietären Werkzeugen und Bibliotheken wird angestrebt, ist aber mit erheblichen Änderungen an der Software verbunden — insbesondere die Trennung von Delphi 7 und der Wechsel auf die Entwicklungsumgebung Lazarus3.

Abbildung 10.3 zeigt eine Bildschirmmaske von TurboCASH. Über die Toolbar und die Menuleiste sind im hinteren Fenster die verfügbaren Module abrufbar. Über die- se Einträge können auch konfigurierte Abläufe im System angestoßen oder rückgesetzt werden. Im Fenster im Vordergrund der Abbildung sind die Konfigurationsmöglichkei- ten einer Aktie dargestellt. Dabei können sowohl Grenzwerte zum Kauf und Verkauf der Aktie als auch Konfigurationen zur Buchung der Aktie im System und ihrer Präsentation in Berichten (Reports) definiert werden.

1General Public Licence, http://www.gnu.org 2http://www.firebirdsql.org 3http://www.lazarus.freepascal.org - Open Source Entwicklungsumgebung für Delphi mit freien Bibliotheken

141 10 Prototypische Transformation der Referenzsoftware GBware

Abbildung 10.3: Screenshot der Nutzerschnittstelle von TurboCASH.

Zu Beginn der Analyse von TurboCASH wurde eine detaillierte Untersuchung der vor- handenen Daten durchgeführt. Dabei konnten eine Vielzahl verschiedener Dateien mit unterschiedlicher Funktion identifiziert werden. In Tabelle 10.2 sind die Dateitypen mit ihrer Endung einschließlich einer kurzen Beschreibung ihrer Funktion dargestellt. Für eine automatische Analyse mit dem entwickelten Werkzeug TRANSFORMR eig- neten sich nur die Dateien mit den Endungen dfm (zur UI-Transformation, siehe Ab- schnitt 10.2), dpk, dpr, pas und inc. Bei der eingehenden Analyse stellten die Ab- hängigkeiten zu proprietären Komponenten eine Schwierigkeit dar, da eine Übersetzung des Gesamtsystems ohne diese Komponenten nicht möglich war. Trotz der Schwierig- keiten konnte der Programmcode in den oben genannten Dateien einer Analyse mit TRANSFORMR unterzogen werden.

Zunächst wurden mit Hilfe der für GBware erzeugten Grammatik und der Transforma- tionsregeln die Flexible Software Representation durch Extraktion des Softwaremodells aus den Programmcodedateien erzeugt (Abbildung 10.4). Es zeigte sich, dass die für GBware entwickelte Grammatik und die Transformationsregeln ohne Änderungen auch auf TurboCASH angewendet werden konnten. Dabei wurden insgesamt 24 Packages, 378 Module, 1126 Methoden und 1773 Membervariablen im Programmcode identifi- ziert.

Nach eingehender Analyse des Programmcodes zeigte sich, dass in der Hauptdatei Tcash3.dpr fast alle weiteren Units und Packages statisch eingebunden werden, was zu einer sehr flachen Hierarchie des Systems führt. Die von Delphi bereitgestellten Me- thoden zur Bildung von Modulen und expliziten Schnittstellen (siehe Abbildung 10.1) wurden kaum verwendet, was zu einer starken Kopplung aller in der Dokumentation ge- nannten Komponenten von TurboCASH führt. Eine Extraktion oder auch der Austausch

142 10.1 Prototypische Analyse und Transformation mit TRANSFORMR

Tabelle 10.2: Verwendete Dateitypen in Konfiguration und Programmcode von Turbo- CASH. Dateien mit kursiver Dateiendung können von TRANSFORMR ver- arbeitet werden.

Mit TRANSFORMR auswertbarer Programmcode / Dokumentation .dfm text Delphi Win32 form file: Ablage aller Objekte der Nutzerschnittstelle mit ihren jeweiligen Eigenschaften (z. B. absolute Position). Für jede Schnittstelle existiert genau eine dfm- und eine pas-Datei mit der zu- gehörigen Programmlogik. .dpk text Delphi package source file: Programmcode eines Delphi Packages. .dpr text Delphi project file: Zentrale Projektdatei für ein Delphi-Professional- Projekt, in der alle weiteren Dateien des Projekts referenziert sind. .pas text Delphi unit source file: Programmcode einer Delphi Unit. .inc text Delphi project include file: Programmcode, der beim Übersetzen in eine Delphi Unit eingefügt wird. .txt text Diverse Dokumentationen, auch in Lotus 1-2-3 oder RTF-Format (ma- nuelle Auswertung notwendig). Konfigurationen der Entwicklungsumgebung und des integrierten Compilers .bpg text Borland Delphi project group file: Steuerung des Übersetzens auch mehrerer zusammenhängender Projekte. .cfg text Delphi project configuration file. .ddp binär Delphi diagram portfolio file: Konfigurationen des Diagramm Editors. .dof text Delphi options file: Konfigurationen des Linkers und Compilers (z. B. Zielverzeichnisse, Suchpfade, etc.). .dsk text Delphi Desktop File: Konfiguration des Desktops. Entwicklungsum- gebung (Offene Dateien, Position der Fenster, etc.). .dsm binär Delphi Symbol Module: Informationen über die letzte erfolgreiche Übersetzung. .dti text Delphi 5 diagram portfolio file. .res binär Resource File: Ressourcen die bei der Übersetzung verwendet werden (z. B. String-Konstanten, Bilder, etc.). .rsm binär Remote debugging symbols file. .tlb binär OLE (Object Linking and Embedding) type library file: Informationen über Typen und Interfaces die über einen ActiveX Server erreichbar sind. Konfiguration und Daten der verwendeten Datenbank und Schnittstelle .db binär Standard paradox file: Daten einer Paradox Datenbank. .lck binär Paradox lock file: Zugriffskontrolle einer Paradox Datenbank. .net binär Borland Database Engine (BDE) paradox data file: Konfiguration des Zugriffs auf eine Paradox Datenbank über BDE. .xml text Daten der Datenbank im XML-Format. ausgewählter Komponenten ist durch die Vielzahl der bestehenden Abhängigkeiten so- mit voraussichtlich nur mit großem manuellen Aufwand möglich.

143 10 Prototypische Transformation der Referenzsoftware GBware

Abbildung 10.4: Screenshots der Analyse von TurboCASH mit TRANSFORMR. Links: Hauptfenster von TRANSFORMR mit Package- und Modulstruk- tur. Rechts: UML Diagramm des Moduls Database im Namespace aTCASH3.Unit.

Abbildung 10.5: Transformation und Konvertierung der Oberfläche einer Legacy- Anwendung.

Neben der Analyse des Programmcodes können die vorhandenen Bildschirmmasken (v. a. in dfm-Dateien) mit dem Werkzeug zur Transformation von Delphi-Nutzerschnitt- stellen ausgewertet werden.

10.2 Prototypische UI-Transformation von GBware

10.2.1 Abstrakte UI-Zwischendarstellung

Wesentlicher Aspekt der Anwendung des Transformationssystems auf GBware lag auf der prototypischen Realisierung der Transformation der grafischen Benutzeroberfläche. Hierbei wurde, wie auch in den übrigen Arbeitspunkten, der Schwerpunkt auf die Trans- formation von Delphi nach Java gelegt. Aus diesem Grund konzentrierten sich die Ar- beiten auf die automatische Extraktion der GUI, wobei Delphi als Quellsprache und

144 10.2 Prototypische UI-Transformation von GBware

Tabelle 10.3: Freie Projekte zur Generierung der grafischen Benutzeroberfläche für Ja- va. Java GUI Designer Java GUI Builder SWIXML Beschreibung Editor mit Codege- Laufzeitbibliothek Laufzeitbibliothek nerator und Codegenerator Aktualität eingestellt eingestellt aktuell Beschreibungs- ini xml xml format Codegenerierung/ ja/nein ja/ja nein/ja Laufzeitgenerie- rung Dokumentation schlecht gut gut Flexibilität wenige Swing Wid- beliebige Klassen Swing gets möglich

Java als Zielsprache vorausgesetzt wurden. Da der Quellcode von GBware sehr stark mit der Geschäftslogik verwoben war, wurde die manuelle Vortransformation in eine Model-View-Controller-Architektur (MVC) nicht realisiert und stattdessen das Konzept der automatischen GUI-Extraktion wieder aufgegriffen.

Die Arbeitsweise der Transformation einer GUI mit automatischer GUI-Extraktion ist in Abbildung 10.5 illustriert. Bei der Transformation der grafischen Benutzeroberflä- che wurde ein Ansatz favorisiert, der die ursprüngliche GUI (Delphi) zunächst in eine universelle Zwischendarstellung überführt. Diese Zwischendarstellung bietet die Mög- lichkeit, die grafische Oberfläche (beispielsweise durch Layoutanpassungen) zu verän- dern, und bildet die Ausgangsbasis zur Codegenerierung. Einige Entwicklungsumge- bungen zur Generierung von grafischen Benutzeroberflächen (beispielsweise NetBeans oder JFormDesigner) verwenden ebenfalls eine Zwischendarstellung der Benutzerober- fläche zur Codegenerierung. Ein weiterer Aspekt dieser universellen Darstellung ist die damit verbundene Möglichkeit eine Ansicht der Benutzeroberfläche direkt aus der uni- versellen Zwischendarstellung zu generieren, ohne Programmcode erzeugen zu müssen. Dieser Vorteil wurde im TransBS-Projekt genutzt, um das Ergebnis der Transformation frühzeitig sichtbar zu machen. Da die genannten Entwicklungsumgebungen die Spezi- fikation der abstrakten Darstellung der GUI im XML-Format nicht offenlegen, wurden freie Werkzeuge und Bibliotheken untersucht, um eine passende Plattform für die Trans- formation von Delphi nach Java zu finden. Tabelle 10.3 zeigt die Eigenschaften der nä- her betrachteten Projekte Java GUI Designer4 (JGUID), Java GUI Builder5 (JGB) und SWIXML6. Bei der Auswahl wurde vor allem auf gute Erweiterbarkeit und Dokumen-

4http://jguid.sourceforge.net/ 5http://jgb.sourceforge.net/ 6http://www.swixml.org/

145 10 Prototypische Transformation der Referenzsoftware GBware

Abbildung 10.6: Mögliche Transformation einer Delphi-Oberfläche. tation Wert gelegt, da keine Technologie alle notwendigen Anforderungen erfüllt und somit Änderungen erforderlich waren.

Für die prototypische Implementierung wurde Java GUI Builder ausgewählt, weil damit nicht nur GUI-Widgets der Java-Standardbibliothek unterstützt werden sondern auch individuell angepasste GUI-Klassen. Dies ist vorteilhaft, wenn GUI-Widgets verwendet werden, die nicht zur Standardbibliothek gehören. Weiterhin ist sowohl die Erzeugung der GUI zur Laufzeit durch die Java GUI Builder Laufzeitbibliothek möglich als auch die vollständige Quellcodegenerierung. Die Möglichkeit vollständigen Quellcode zu ge- nerieren ist zur Nach- und Weiterbearbeitung der grafischen Oberfläche nützlich.

10.2.2 GUI-Transformation von Delphi nach Java

Die Transformation der grafischen Benutzeroberfläche von Delphi nach Java wird in drei Schritten vollzogen. Abbildung 10.6 zeigt die dabei angewendete Methode für die Transformation. Delphi-Anwendungen bestehen typischerweise aus den Quellcode-Da- teien (*.pas) und zugehörigen GUI-Beschreibungsdateien (*.dfm). Die dfm-Dateien enthalten die hierarchische Anordnung der grafischen Elemente, z. B. enthält ein Fenster mehrere Panels und ein Panel kann mehrere Buttons besitzen. Die Transformation glie- .pas dert sich in die Transformation der Logik (−−→) und der grafischen Benutzeroberfläche .dfm (−−→). Bei der Transformation aus der Zwischendarstellung (universelles XML) in die Zielsprache ist die Logik wieder mit den GUI-Elementen zu verknüpfen. Diese Aufgabe muss mit Werkzeugunterstützung geschehen. Dabei muss der entsprechende Teil der Logik wieder mit den Ereignisroutinen der GUI-Elemente verknüpft werden, damit z. B. auf das Klicken eines Buttons auch das zugehörige Ereignis ausgelöst wird. Die Logik wird dabei durch den Aufbau des Syntaxbaums in die Zielsprache überführt.

146 10.2 Prototypische UI-Transformation von GBware

Abbildung 10.7: Beispiel einer abstrakten Darstellung der GUI.

Dazu kann die FSR (Flexible Software Representation) des Werkzeugs TRANSFORMR genutzt werden. Für die grafische Umwandlung werden die dfm-Dateien in eine allge- meine Beschreibung konvertiert, welche in der Abbildung als Intermediate XML bezeichnet ist. Ein Beispiel der Zwischendarstellung der grafischen Oberfläche des ur- sprünglichen Delphi-Programms ist in Abbildung 10.7 dargestellt. Die darin verwendete XML-Beschreibung ist eine Eigenentwicklung und bildet die hierarchisch aufgebauten dfm-Dateien in XML ab.

Die universelle XML Zwischendarstellung wird durch eine XML-zu-XML Trans- formation generiert. Dabei werden die GUI-Widgets der Ausgangssprache in GUI- Widgets der Zielsprache abgebildet, Anpassungen durchgeführt und eine neue Struktur der GUI erzeugt. Dieser Vorgang kann durch eine XSL-Transformation realisiert werden und mehrere Stufen umfassen. Falls in der Ausgangsbeschreibung (Delphi) oder in der Zielbeschreibung (Java) GUI-Widgets verwendet werden, die nicht aus der Standardbi- bliothek stammen (beispielsweise abgeleitete Widgets mit zusätzlichen Eigenschaften), so ist die Transformation ebenso problemlos möglich. Die Java GUI Builder-Bibliothek ermöglicht die Instantiierung beliebiger Java Klassen. Somit muss die Abbildung von Quell- in Ziel-Widget angepasst werden und die individuellen Klassen müssen zur Lauf- zeit auffindbar sein.

Die universelle XML Zwischendarstellung kann wahlweise zur Erzeugung von Programmcode benutzt werden oder zur Generierung der grafischen Oberfläche zur Laufzeit durch die Java GUI Builder-Bibliothek. Je nachdem werden verschiedene Java Sourcecode Dateien generiert, die eine vollständige GUI enthalten oder nur den Code zur Erzeugung der GUI aus der XML-Datei und die verwendeten Ereignisroutinen.

10.2.3 Anpassung der generierten GUI

In Delphi werden die GUI-Widgets durch die Angabe von absoluten Koordinaten im Anzeigefenster platziert. Weiterhin ist die Größe eines Widgets fest in der .dfm-Datei kodiert. Um die Anordnung und Größe der Widgets nach Java zu übertragen, reicht

147 10 Prototypische Transformation der Referenzsoftware GBware es nicht aus, diese absoluten Koordinaten einfach zu übernehmen, da in Java Widget- Schriftarten, Umrandungen und Farben standardmäßig anders gesetzt sind als in Delphi. Somit sind die GUI-Widgets im resultierenden Anzeigefenster oft nicht wohlgeformt. Einige dieser Seiteneffekte lassen sich jedoch automatisch beheben, so beispielsweise die geeignete Anordnung und Skalierung der GUI-Widgets.

Um die Möglichkeiten der aktuellen GUI-Bibliotheken von Java zu nutzen, bietet es sich an, das Layout der GUI-Widgets durch einen Layoutmanager verwalten zu lassen. Dieser sorgt dafür, dass alle Widgets eine geeignete Größe haben und passt das Layout beim Vergrößern/Verkleinern des Fensters an. Es gibt verschiedene Layoutmanager, die unterschiedliche Algorithmen zur Anordnung der GUI-Widgets verwenden. Als Ziellay- out der absolut positionierten Widgets wurde das GridbagLayout gewählt. Bei diesem Layout werden die Komponenten in einem Raster aus Zeilen und Spalten positioniert. Diese Darstellung ist aus dem absoluten Layout gut generierbar. Weitere Versuche mit BorderLayout, GridLayout und FlowLayout stellten sich als zu unflexibel heraus. Falls eine Layouttransformation ins GridBagLayout gewünscht wird, kommt aufgrund von Restriktionen der Java GUI Builder-Bibliothek nur die Generierung von Java Programm- code in Frage. Eine Erzeugung zur Laufzeit wird derzeit nicht unterstützt. Um dies zu ermöglichen müsste die Bibliothek von Java GUI Builder angepasst werden. Das Ergeb- nis der Transformation eines Delphi-Dialogs ist in Abbildung 10.8 dargestellt. Es zeigt auf der linken Seite den Dialog zur Erstellung einer Rechnung in GBware und rechts den transformierten Dialog unter Verwendung des GridBagLayouts in Java.

Nicht alle Details der ursprünglichen GUI konnten im Projekt erfasst werden (beispiels- weise Grafiken auf Buttons). Für die Nachbearbeitung der generierten grafischen Ober- fläche (beziehungsweise des Quellcodes) ist eine Werkzeugunterstützung wünschens- wert. Dies wurde erreicht, indem der generierte Quellcode nach den Richtlinien des Visual Editor des Java-Entwicklungswerkzeugs Eclipse erzeugt wurde. Somit kann der Quellcode im Visual Editor eingelesen werden und dort grafisch nachbearbeitet werden.

10.2.4 Diskussion über die Grenzen des Verfahrens

Das größte Problem besteht in der Extraktion der GUI aus dem Legacy-Programm und der damit verbundenen Erstellung der Zwischendarstellung. Die automatische Analyse ist dann erfolgreich, wenn viele Elemente statisch im Programm definiert sind. Wer- den die Elemente zur Laufzeit dynamisch erzeugt oder ist der Aufbau der grafischen Oberfläche vom Eintreten einiger Bedingungen abhängig, ist eine statische Extraktion nicht möglich. Um dieses Problem zu lösen, könnten Laufzeit-Analysen der Legacy- Software durchgeführt und die erreichten Zustände protokolliert werden. Die Laufzeit- Analyse von Legacy-Software ist Gegenstand aktueller Forschung, so dass noch keine einsetzbaren Lösungen existieren.

Ein weiteres Problem ist die Abbildung der Elemente aus dem Quell- in das Zielsystem. Für einfache Grafik-Widgets, z. B. Menüs und Buttons, gibt es für fast alle Zielplattfor- men entsprechende Gegenstücke. Schwieriger ist es, komplexe Elemente wie Tabellen

148 10.3 Evaluierung von Kunden-Workflows

Abbildung 10.8: Beispiel einer Delphi-Java-Transformation. Oben: Ausgangsprogramm (Delphi); Unten: Zielprogramm (Java). abzubilden. Hierzu müssen für die gegebene Legacy-Software spezielle Transformati- onsroutinen bereitgestellt werden, die die Aufgabe im konkreten Fall lösen. Für indivi- duelle GUI-Widgets in der Quellsprache muss ebenfalls eine Entsprechung in der Ziel- sprache gefunden werden und die zugehörigen Transformationsroutinen müssen erstellt werden.

10.3 Evaluierung von Kunden-Workflows

Am Beispiel des Workflows zur Erstellung einer Rechnung wurde die Extraktion ei- nes Kunden-Workflows durchgeführt. Das Ziel der Extraktion ist die Überführung des Kunden-Workflows aus der bisherigen Darstellung in Datenbanktabellen in eine BPEL-

149 10 Prototypische Transformation der Referenzsoftware GBware

löschen drucken

drucken / gedruckt drucken bearbeiten löschen gelöscht drucken stornieren neu/erstellen bearbeiten buchen undefiniert angelegt geändert stornieren gebucht storniert buchen

Abbildung 10.9: Abbildung des Kunden-Workflows „Rechnung“ aus GBware als Zu- standsautomat.

Beschreibung. Der Workflow „Rechnung“ ist in der Datenbank als Automat modelliert und besteht aus einer Reihe von Zuständen. Es gibt einen Initialzustand und mehrere Endzustände. Außerdem sind die Aktionen modelliert, die den Übergang von einem Zu- stand in einen Folgezustand auslösen. Weiterhin finden sich in der Datenbank auch die Aktionen, die bei einem Zustandsübergang ausgeführt werden. Der komplette Zustands- automat ist in Abbildung 10.9 dargestellt.

10.3.1 Auswahl und Evaluierung der Workflow-Komponenten

Der ursprüngliche Workflow „Rechnung“ in GBware ist zustandsbasiert. BPEL legt je- doch einen aktionsbasierten Ablauf des Geschäftsprozesses zugrunde. Dies bedeutet, dass diejenigen Aktionen modelliert werden, die zu einer Zustandsänderung führen. Die Zustände selbst sind anschließend implizit im Prozess enthalten. Der BPEL-Prozess re- präsentiert die Aktionen, die auf einem Dokument oder einer Datenmenge ausgeführt werden können sowie die Abfolge dieser Aktionen. Der Zustand des Dokuments ist so- mit entkoppelt vom darüber liegenden Prozess. Weiterhin hat diese aktionsbasierte Mo- dellierung Auswirkungen auf die Anbindung der User Clients (grafische Oberfläche). Da die User Clients via HTTP mit der Workflow-Engine kommunizieren, kann keine bi- direktionale eventbasierte Anbindung der grafischen Oberfläche gewährleistet werden, wie es in MVC-Architekturen üblich ist. HTTP ist ein verbindungsloses Protokoll und arbeitet nach dem Request-Response-Verfahren. Diese Einschränkung ist jedoch für die hier betrachteten Prozesse nicht problematisch, da sich deren Zustand üblicherweise nicht in kurzen Abständen verändert (im Gegensatz beispielsweise zu Videobildern). Außerdem erfolgt die Zustandsänderung direkt nach dem Auslösen einer Aktion. Somit ist die Anbindung von User Clients nach dem Request-Response-Verfahren hier pro- blemlos möglich. Die BPM-Notation des Prozesses „Rechnung“ ist in Abbildung 10.10 veranschaulicht.

Nicht alle BPEL-Engines und Modellierungswerkzeuge unterstützen Rückwärtskan- ten im Prozess. Damit ist die Modellierung von Schleifen nicht möglich. Im Bei- spiel-Prozess in Abbildung 10.10 existiert eine Schleife, die die Knoten „bearbeiten“ und „drucken“ umfasst. Von den vorgestellten BPEL-Engines „Sun BPEL Engine“, „activeBPEL“ und „Intalio Server“ unterstützt nur activeBPEL Rückwärtskanten im Prozess. Weiterhin sieht BPEL nur die einmalige Ausführung einer Aktivität vor. Akti- vitäten, die mehrfach ausgeführt werden können („bearbeiten“ oder „drucken“ im Bei-

150 10.3 Evaluierung von Kunden-Workflows

Abbildung 10.10: Links: Abbildung des Kunden-Workflows „Rechnung“ in aktionsba- sierter BPM-Notation. Rechts: Abbildung des modifizierten Kunden- Workflows „Rechnung“ nach Integration einer Liquiditätsprüfung. Aufrufe von Datenbankfunktionen sind in beiden Abbildungen nur für die Aktionen „stornieren“ bzw. „prüfen“ dargestellt. spiel), müssen über eine While- oder For-Schleife modelliert werden, in die eine virtuel- le Abbruchbedingung integriert wird. activeBPEL bietet für diesen Fall die Möglichkeit sogenannte „transition conditions“ (Übergangsbedingungen) zu definieren, die erfüllt sein müssen, um von einer Aktivität zur Folgeaktivität zu gelangen.

Der extrahierte Kunden-Workflow „Rechnung“ wurde für die Ausführung auf der activeBPEL-Engine angepasst. Der Funktionsumfang der einzelnen BPEL-Engines un- terscheidet sich anders als erwartet erheblich (beispielsweise unterstützt die SunBPEL- Engine keine „transition conditions“). Deshalb ist die oftmals beworbene Portabili- tät von BPEL-Prozessen nur unter bestimmten Voraussetzungen gewährleistet. Da die activeBPEL-Engine alle benötigten Funktionen unterstützt, wurde sie als Zielplattform für die Ausführung der BPEL-Prozesse ausgewählt. Die activeBPEL-Engine setzt auf dem Apache Tomcat Application Server auf. Eine sichere Anbindung von User Cli- ents (grafische Oberfläche) ist demnach via HTTPS gewährleistet. Eine erhöhte Aus- fallsicherheit konnte durch das Verfahren der verteilten Prozessabarbeitung (vgl. 9.3) erreicht werden. Dabei wird durch die effiziente Verteilung von Webservice-Aufrufen auf Webservice-Anbieter nicht nur eine Steigerung des Durchsatzes erreicht, sondern durch die vorhandene Redundanz von Diensten auch eine alternative Möglichkeit der Ausführung bei Ausfall eines Webservice-Anbieters gewährleistet.

Da Rechnungen häufig erstellt werden, muss es möglich sein mehrere Prozesse der glei- chen Art gleichzeitig instantiieren und verwalten zu können. Bei der Anbindung der grafischen Nutzerschnittstelle ist es beispielsweise notwendig einen Prozess eindeutig zu identifizieren, um Benutzereingaben zuordnen zu können. Die BPEL-Engine bietet jedoch nur jeweils eine Schnittstelle für alle gleichartigen Prozesse. Um Prozesse den- noch zuverlässig unterscheiden zu können, existieren in BPEL sogenannte „correlation sets“ (Korrelationsmengen). Dabei werden ein oder mehrere Kommunikationsparame- ter markiert, welche eindeutig einem Prozess zugeordnet sind. Die BPEL-Engine leitet einen Aufruf an den Prozess weiter, dessen korrelierende Parameter zu den Werten der Kommunikationsparameter passen. Ein neuer Prozess wird entweder über die Angabe

151 10 Prototypische Transformation der Referenzsoftware GBware einer noch nicht vorhandenen Korrelationsmenge erzeugt oder explizit durch den Aufruf einer speziellen Instantiierungsaktivität („neu/erstellen“ in Abbildung 10.10).

10.3.2 Anpassung der Kunden-Workflows

Auch bei der Anpassung der Kunden-Workflows wurde schnell deutlich, dass nicht jede Entwicklungsumgebung zur Erstellung eines BPEL-Prozesses mit jeder BPEL-Engine kompatibel war. Somit ist es empfehlenswert die jeweilige zur BPEL-Engine gehörende Entwicklungsumgebung zu benutzen. Mit Hilfe solcher Entwicklungsumgebungen ist die Modifikation der komplexen BPEL-Dokumente leicht möglich. Außerdem bieten sie oftmals die Möglichkeit, die erstellten BPEL-Prozesse auf eine BPEL-Engine zu übertragen (Deployment-Prozess) und zu debuggen. Die im Projekt erstellten Prozesse bestehen maßgeblich aus Webservice-Aufrufen und Variablenzuweisungen. Die Anpassung an veränderte Anforderungen kann somit leicht vorgenommen werden. Weiterhin ist die Integration neuer Funktionalität möglich, da die auf Standards basierenden Webservices über ein WSDL-Dokument (Web Services Des- cription Language) einfach in den BPEL-Prozess integriert werden können. Beispielhaft sind im Folgenden die nötigen Schritte angeführt, die für das Hinzufügen neuer Funk- tionalität zu einem Workflow notwendig sind: • Bereitstellung der neuen Funktionalität als Webservice und Veröffentlichung der Schnittstelle. • Integration des Webservice in den BPEL-Prozess und eventuell Anpassung der Schnittstellen des Prozesses. • Falls Änderungen an den Schnittstellen zum BPEL-Prozess vorgenommen wur- den, müssen diese auch zu den Kommunikationspartnern (andere BPEL-Prozesse, User Clients) propagiert werden. Im dargestellten Kunden-Workflow (Abbildung 10.10, rechts) wurde eine Liquidi- tätsprüfung eingefügt (rot markierte Elemente). Diese ist der Aktion „buchen“ im Workflow-Prozess vorangestellt und prüft vor einer Buchung das entsprechende Kun- denkonto. Um diese Prüfung durchführen zu können wurde ein weiterer Dienst in die Datenbank integriert, welcher die tatsächliche Prüfung anhand der Geschäftsdaten vor- nimmt. Sollte das Kundenkonto beispielsweise auf Grund einer Reihe von noch ausste- henden Zahlungen als nicht ausreichend vertrauenswürdig eingestuft werden, so wird diese Information an den Prozess zurückgemeldet. Daraufhin wird die Buchung abge- brochen und die „Rechnung“ muss erneut bearbeitet werden.

10.4 Zusammenfassung

In diesem Kapitel wurden verschiedene Szenarien zur Anwendung des Transforma- tionswerkzeugs auf die Referenzsoftware GBware und die Business-Software Turbo- CASH vorgestellt. Die für die Programmiersprache Delphi entwickelte Grammatik und

152 10.4 Zusammenfassung die Transformationsregeln konnten erfolgreich auf die zwei Softwaresysteme GBware und TurboCASH angewendet werden. Es zeigte sich, dass die Flexible Software Repre- sentation (FSR) neben der Abbildung von Software in Java auch für Systeme in Delphi geeignet ist. Die extrahierten Modelle ließen auch Rückschlüsse auf das zu Grunde lie- gende Design (Module und ihre Abhängigkeiten) und mögliche Schwachstellen (bspw. starke Kopplung einzelner Module) zu.

Für eine Überführung der grafischen Nutzerschnittstelle aus der Programmiersprache Delphi nach Java wurde ein Ansatz vorgestellt, der ausgehend von der statischen Be- schreibung der GUI in Delphi eine sprachunabhängige Zwischendarstellung erzeugt, aus der in einem weiteren Transformationsschritt die Java Nutzerschnittstelle erzeugt wer- den kann. Anhand einer komplexen Nutzerschnittstelle von GBware wird die Eignung der Realisierung gezeigt.

Abschließend wurde ein in GBware realisierter Kunden-Workflow extrahiert und in eine standardisierte Beschreibungssprache für Geschäftsprozesse überführt. Workflows wer- den in GBware als Zustandsautomaten modelliert, die nicht auf standardisierten Work- flow-Engines ausgeführt werden können. Es wurde eine Transformation der Zustands- automaten anhand des Workflows „Rechnung“ in BPEL vorgestellt, der auch die Ver- knüpfung zur bestehenden Geschäftslogik (Datenbankfunktionen) erlaubt. Anhand einer neuen Aktion „prüfen“ wurde die einfache Erweiterbarkeit von BPEL-Prozessen aufge- zeigt.

153 10 Prototypische Transformation der Referenzsoftware GBware

154 11 Zusammenfassung

Zielstellung des Projekts TransBS war die Entwicklung einer Methodik zur Überführung existierender monolithischer Legacy-Business-Softwaresysteme in eine komponenten- basierte, verteilte Client-Server-Architektur mit konfigurierbaren Workflows für hete- rogene Plattformen. Das Hauptaugenmerk des Projekts lag auf der Entwicklung eines inkrementellen Transformationssystems (TRANSFORMR) zur Bildung von Komponen- ten innerhalb des Legacy-Systems sowie dem Entwurf und der Realisierung eines Client- Server-Frameworks (CBFRAME) zur konfigurierbaren, Workflow-basierten Ausführung der Komponenten. Anschließend sollte der erstellte Prototyp in verschiedenen Anwen- dungsszenarien evaluiert und getestet werden. Die wesentliche Basis moderner Business-Softwaresysteme ist ein Ausführungsframe- work, das die Unabhängigkeit von der jeweils verwendeten Plattform sicherstellt, einen möglichst standardisierten Zugriff auf Workflows und die Workflow-Abarbeitung bie- tet, eine modulare Entwicklung ermöglicht und die Trennung von Nutzerschnittstelle und Business-Logik zulässt. Als Referenzsystem wurde das Enterprise Resource Plan- ning System GBware der Firma Berndt & Brungs Software GmbH analysiert, um An- forderungen an modulare und verteilte Business-Software zu formulieren. Durch den exemplarischen Entwurf von Schnittstellen zwischen Modulen und die Extraktion der Workflow-Komponente in GBware konnten wichtige Voraussetzungen für die prakti- sche Anwendbarkeit des Transformationssystems erarbeitet werden.

Grundlage des entwickelten Transformationssystems TRANSFORMR ist ein inkremen- teller Transformationsprozess, der ausgehend vom vorhandenen Programmcode des Le- gacy-Systems ein sprachunabhängiges Softwaremodell (Flexible Software Representa- tion, FSR) erzeugt, das die statische Struktur des Systems wiederspiegelt und verschie- dene Visualisierungen von Abhängigkeiten und Metriken zur Extraktion von Software- eigenschaften ermöglicht. Mit der Nutzung des Compilerwerkzeugs TXL, das für eine Vielzahl von Programmiersprachen Unterstützung bietet, wurden für die Sprachen Java und Delphi Grammatiken und Regeln zur Extraktion des Softwaremodells bereitgestellt. Mit Hilfe der FSR können schrittweise Abhängigkeiten des Systems aufgedeckt und Transformationen zur Erzeugung von Modulen ausgeführt werden. Prototypisch wur- den Transformationen zur automatischen Erzeugung von Komponenten, basierend auf der Verschiebung von Methoden, umgesetzt, was zu einer Erhöhung der Modularität in den evaluierten Systemen führte. Das Werkzeug TRANSFORMR bietet im Rahmen eines Restrukturierungsprozesses flexible Hilfestellung bei der Analyse und Transformation von Programmcode von Business-Systemen. Für den Entwurf und die Realisierung eines konfigurierbaren, verteilten Ausführungs- frameworks auf heterogenen Plattformen für Komponenten von Business-Softwaresys- temen wurde eine eingehende Evaluierung bestehender Open Source Frameworks auf

155 11 Zusammenfassung

Basis von Java, CORBA und .NET durchgeführt und es wurden geeignete Workflow- Beschreibungssprachen und -Engines ausgewertet. Dabei stellten sich vor allem Frame- works auf Basis von JavaEE und Java-basierte Workflow-Beschreibungen und -Engines (z. B. BPEL) als geeignet heraus. Um eine verteilte Ausführung mit geeigneter Ska- lierbarkeit zu erreichen, wurden verschiedene Technologien zur verteilten Ausführung und zur Anbindung von Legacy-Systemen untersucht (Kommunikation mit Java Mes- sage Service (JMS), CORBA). Speziell für die Anbindung von Delphi-Clients an das Ausführungsframework wurden die Möglichkeiten der Anbindung über eine DCOM- CORBA-Bridge, eine DCOM-RMI-Bridge und das HTTP-basierte Protokoll SOAP un- tersucht. Zur verteilten Ausführung von Business-Logik wurde das Remote-Adapter- Pattern entworfen und in das Werkzeug TRANSFORMR integriert. Das Pattern ermög- licht eine automatische Transformation zur Auslagerung von Funktionalität auf entfernte Server, um bspw. ressourcenintensive Aufgaben verlagern zu können.

Der realisierte Prototyp wurde in verschiedenen Szenarien auf die Referenzsoftware GBware angewendet. Dabei gaben die Analyse und Transformation des Delphi Pro- grammcodes Aufschluss über das Design von Teilen des Systems und ihrer Eigen- schaften. Die Transformation einer komplexen graphischen Nutzerschnittstelle nach Ja- va wurde durchgeführt und zeigte die Anwendbarkeit der Transformationen auch für allgemeine Schnittstellen. Zur Evaluation der gewählten Workflow-Beschreibung und -Engine wurde der Kunden-Workflow „Rechnung“ extrahiert und in der Beschreibungs- spache BPEL modelliert. Dabei konnte die bestehende Business-Logik (meist Daten- bankfunktionen) in den Prozess integriert werden.

Das im Rahmen des Projekts TransBS entwickelte Transformationswerkzeug TRANS- FORMR und das Ausführungsframework CBFRAME profitierte vor allem von der Kom- bination von Methoden und Wissen unterschiedlicher Gebiete der Softwareentwicklung wie Compilerbau, modellgetriebene Softwareentwicklung und Business-Process-Mana- gement sowie der Integration standardisierter Business-Plattformen. Der inkrementel- le Transformationsprozess ermöglicht dabei die unabhängige Entwicklung von Einzel- komponenten zur Betrachtung von Teilproblemen und sichert damit die Anpassbarkeit und Erweiterbarkeit des Systems auf andere Problemstellungen der Analyse und Trans- formation von Business-Software.

156 12 Literaturverzeichnis

[1] Business Process Modeling Notation (BPMN) Specification, Final Adopted Speci- fication, 2006. [2] Web Services Business Process Execution Language Version 2.0, April 2007.

[3]A LDER,G.: Design and Implementation of the JGraph Swing Component. Tech- nischer Bericht, JGraph Ltd, 2001.

[4]A NDRITSOS, P. und V. TZERPOS: Software Clustering based on Information Loss Minimization. In: WCRE ’03: Proc. of the 10th Working Conf. on Reverse Engi- neering, Seiten 334–344, Washington, DC, USA, 2003. IEEE Computer Society.

[5]B ALMAS, F.: Displaying dependence graphs: a hierarchical approach. J. Softw. Maint. Evol., 16(3):151–185, 2004.

[6]B ARONI,A.L.: Formal Definition of Object-Oriented Design Metrics. Diplomar- beit, Ecole des Mines de Nantes, France; Universidade Nova de Lisboa, Portugal, 2002.

[7]B AXTER,I.D.,C.PIDGEON und M. MEHLICH: DMS®: Program Transforma- tions for Practical Scalable Software Evolution. In: ICSE ’04: Proc. of the 26th Int. Conf. on Software Engineering, Seiten 625–634, Washington, DC, USA, 2004. IEEE Computer Society.

[8]B EER,D.,J.DÜMMLER und G. RÜNGER: Transformation von Prozessmodellen in Workflowbeschreibungen. In: GEIST,A.,G.HEINDL und E. SCHWEIGHOFER (Herausgeber): Tagungsband des 10. Internationalen Rechtsinformatik Symposi- ons IRIS 2007, Seiten 180–188. BOORBERG, 2007.

[9]B INKLEY,D.: Source Code Analysis: A Road Map. In: FOSE ’07: 2007 Future of Software Engineering, Seiten 104–119, Washington, DC, USA, 2007. IEEE Com- puter Society.

[10]B OLIE,J.,M.CARDELLA,S.BLANVALET,M.JURIC,S.CAREY, P. CHANDRAN, Y. COENE,K.GEMINIUC,M.ZIRN und H. GAUR: BPEL Cook- book: Best Practices for SOA-based integration and composite applications deve- lopment. Packt Publishing, 2006.

[11]B RITOE ABREU, F. und R. CARAPUÇA: Object-Oriented Software Engineering: Measuring and Controlling the Development Process. In: Proc. 4th Int. Conf. on Software Quality (ASQC), McLean, VA, USA, Oct. 1994.

[12]B URKE, B. und R. MONSON-HAEFEL: Enterprise JavaBeans 3.0 (5th Edition). O’Reilly Media, Inc., May 2006.

157 12 Literaturverzeichnis

[13]C AO, F., B. R. BRYANT,C.C.BURT,R.R.RAJE,A.M.OLSON und M. AU- GUSTON: A Component Assembly Approach Based On Aspect-Oriented Gene- rative Domain Modeling. Electronic Notes in Theoretical Computer Science, 114:119–136, 2005. Proc. of the Software Composition Workshop (SC 2004).

[14]C ORDY,J.R.,I.H.CARMICHAEL und R. HALLIDAY: The TXL Programming Language, Version 10.5. Reference Manual, School of Computing, Queen’s Uni- versity, Kingston, Canada, Nov. 2007.

[15]C ORDY,J.R.,T.R.DEAN,A.J.MALTON und K. A. SCHNEIDER: Software En- gineering by Source Transformation-Experience with TXL. Source Code Analysis and Manipulation, IEEE International Workshop on, Seiten 168–178, 2001.

[16]C ORREIA,R.,C.MATOS,M.EL-RAMLY,R.HECKEL,G.KOUTSOUKOS und L.ANDRADE: Software Reengineering at the Architectural Level: Transformation of Legacy Systems. Technischer Bericht, University of Leicester, 2006.

[17]C RNKOVIC, I. und M. LARSSOM: Challenges of component-based development. J. Syst. Softw., 61(3):201–212, 2002.

[18]E ICK, S. G., T. L. GRAVES, A. F. KARR,J.S.MARRON und A. MOCKUS: Does Code Decay? Assessing the Evidence from Change Management Data. IEEE Trans. Softw. Eng., 27(1):1–12, 2001.

[19]E LLSON,J.,E.R.GANSNER,E.KOUTSOFIOS,S.C.NORTH und G. WOOD- HULL: Graphviz and Dynagraph – Static and Dynamic Graph Drawing Tools. Technischer Bericht, AT&T Labs - Research, 2003.

[20]E MMERICH, W.: Distributed component technologies and their software enginee- ring implications. In: ICSE ’02: Proc. of the 24th Int. Conf. on Software Enginee- ring, Seiten 537–546, New York, NY, USA, 2002. ACM.

[21]F ERBER,M.,S.HUNOLD und T. RAUBER: Load Balancing Concurrent BPEL Processes by Dynamic Selection of Web Service Endpoints. In: ICPPW ’09: Pro- ceedings of the 2009 International Conference on Parallel Processing Workshops, Seiten 290–297, Washington, DC, USA, 2009. IEEE Computer Society.

[22]F ERENC, R. und Á. BESZÉDES: Data Exchange with the Columbus Schema for C++. In: CSMR ’02: Proc. of the 6th European Conf. on Software Maintenance and Reengineering, Seiten 59–66, Washington, DC, USA, 2002. IEEE Computer Society.

[23]F OWLER,M.: GUI Architectures. In: Development of Further Patterns of Enterprise Application Architecture. http://www.martinfowler.com/ eaaDev/.

[24]F OWLER,M.,D.RICE,M.FOEMMEL,E.HIEATT,R.MEE und R. STAFFORD: Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002.

[25]G AMMA,E.,J.VLISSIDES,R.JOHNSON und R. HELM: Design Patterns CD: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Pu- blishing Co., Inc., Boston, MA, USA, 1998.

158 12 Literaturverzeichnis

[26]H ARMAN,M.: The Current State and Future of Search Based Software Enginee- ring. In: FOSE ’07: 2007 Future of Software Engineering, Seiten 342–357, Wa- shington, DC, USA, 2007. IEEE Computer Society. [27]H UNOLD,S.,B.KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Pattern- based Refactoring of Legacy Software Systems. In: Proc. of the 11th Int. Conf. on Enterprise Information Systems (ICEIS), Seiten 78–89. Springer, 2009. [28]I HNS,O.,D.HARBECK,S.M.HELDT und H. KOSCHEK: EJB 3 professionell: Grundlagen- und Expertenwissen zu Enterprise JavaBeans 3 für Einsteiger, Um- steiger und Fortgeschrittene. dpunkt.verlag, 2009. [29]J AMAE, J. und P. JOHNSON: JBoss in Action. Configuring the JBoss Application Server. Manning Publications Co., 2009. [30]J URIC,M.,R.NAGAPPAN,R.LEANDER und S. J. BASHA: Professional J2EE EAI. Wrox Press Ltd., Birmingham, UK, UK, 2001. [31]K AZMAN,R.,S.G.WOODS und S. J. CARRIÈRE: Requirements for Integrating Software Architecture and Reengineering Models: CORUM II. In: Proc. of WCRE 98, (Honolulu, HI), October 1998. [32]K ELLER,G.,M.NÜTTGENS und A.-W. SCHEER: Semantische Prozeßmodellie- rung auf der Grundlage “Ereignisgesteuerter Prozeßketten (EPK)“. Arbeitsbe- richt Heft 89, Institut für Wirtschaftsinformatik Universität Saarbrücken, 1992. [33]K RAFT,N.A.,B.A.MALLOY und J. F. POWER: An infrastructure to support interoperability in reverse engineering. Inf. Softw. Technol., 49(3):292–307, 2007. [34]L ANZA,M.,R.MARINESCU und S. DUCASSE: Object-Oriented Metrics in Prac- tice. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2006. [35]L AURES,G.,H.MEYER, T. HAHMANN,J.MÖLLER und P. SOMMER: Eva- luation von Open Source Produkten zur Ausführung Web Service-basierter Ge- schäftsprozesse. In: 1. GI-Workshop OpenBPM: 2006: Geschäftsprozessmanage- ment mit Open Source-Technologien?, 0 2006. [36]L EE,D.: Display a UML Diagram using Draw2D. Technischer Bericht, IBM, 2003. [37]L ENGYEL, L., T. LEVENDOVSZKY und H. CHARAF: Validated model transformation-driven software development. Int. J. Comput. Appl. Technol., 31(1/2):106–119, 2008. [38]L ETHBRIDGE, T. C., S. TICHELAAR und E. PLOEDEREDER: The Dagstuhl Midd- le Metamodel: A Schema For Reverse Engineering. Electronic Notes in Theoretical Computer Science, 94:7–18, 2004. Proc. of the Int. Workshop on Meta-Models and Schemas for Reverse Engineering (ateM 2003). [39]L ITOIU,M.: Migrating to web services: a performance engineering approach. J. Softw. Maint. Evol., 16(1-2):51–70, 2004. [40]L UNG,C.-H.,M.ZAMAN und A. NANDI: Applications of clustering techniques to software partitioning, recovery and restructuring. J. Syst. Softw., 73(2):227– 244, 2004.

159 12 Literaturverzeichnis

[41]M EHTA, A. und G. T. HEINEMAN: Evolving legacy system features into fine- grained components. In: ICSE ’02: Proc. of the 24th Int. Conf. on Software Engi- neering, Seiten 417–427, New York, NY, USA, 2002. ACM. [42]M ENKHAUS, G. und U. FREI: Legacy System Integration using a Grammar-based Transformation System. CIT - Journal of Computing and Information Technology, 12(2):95–102, 2004. [43]M ENS, T. und T. TOURWÉ: A Survey of Software Refactoring. IEEE Trans. Softw. Eng., 30(2):126–139, 2004. [44]N IERE, J., W. SCHÄFER, J. P. WADSACK,L.WENDEHALS und J. WELSH: To- wards Pattern-Based Design Recovery. In: Proc. of the 24th Int. Conf. on Software Engineering (ICSE), Seiten 338–348. IEEE Computer Society Press, May 2002. [45]P ETRASCH, R. und O. MEIMBERG: Model Driven Architecture. Eine praxisori- entierte Einführung in die MDA. dpunkt.verlag, 2006. [46]R AUBER, T. und G. RÜNGER: Transformation of Legacy Business Software into Client-Server Architectures. In: Proc. of the 9th Int. Conf. on Enterprise Informa- tion Systems, Seiten 36–43. INSTICC, 2007. [47]S EACORD,R.C.,D.PLAKOSH und G. A. LEWIS: Modernizing Legacy Systems: Software Technologies, Engineering Process and Business Practices. Addison- Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [48]S ERRANO,M.A.,D.L.CARVER und C. M. DE OCA: Reengineering legacy systems for distributed environments. J. Syst. Softw., 64(1):37–55, 2002. [49]S IEGEL,J.: Why use the model driven architecture to design and build distributed applications? In: ICSE ’05: Proc. of the 27th international conference on Software engineering, Seiten 37–37, New York, NY, USA, 2005. ACM. [50]S TAHL, T., M. VÖLTER,S.EFFTINGE und A. HAASE: Modellgetriebene Softwa- reentwicklung - Techniken, Engineering, Management. dpunkt.verlag, 2. Auflage Auflage, 2007. [51]T SANTALIS, N. und A. CHATZIGEORGIOU: Identification of Move Method Refac- toring Opportunities. IEEE Transactions on Software Engineering, 99(2):347–367, 2009. [52]U LRICH, W. M.: Legacy Systems: Transformation Strategies. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. [53]Z HAO, W., B. R. BRYANT,J.GRAY und C. C. BURT: A Generative and Model Driven Framework for Automated Software Product Generation. In: Proc. of the 6th ICSE Workshop of Component Based Software Engineering, Seiten 103–108, 2003. [54]Z OU, Y. und M. HUNG: An Approach for Extracting Workflows from E-Commerce Applications. In: ICPC ’06: Proc. of the 14th IEEE Int. Conf. on Program Compre- hension, Seiten 127–136, Washington, DC, USA, 2006. IEEE Computer Society.

160 Chemnitzer Informatik-Berichte

In der Reihe der Chemnitzer Informatik-Berichte sind folgende Berichte erschienen: CSR-06-01 Wassil Dimitrow, Mathias Sporer, Wolfram Hardt, UML basierte Zeitmo- dellierung fur¨ eingebettete Echtzeitsysteme, Februar 2006, Chemnitz CSR-06-02 Mario Lorenz, Guido Brunnett, Optimized Visualization for Tiled Displays, M¨arz 2006, Chemnitz CSR-06-03 D. Beer, S. H¨ohne, R. Kunis, G. Runger,¨ M. Voigt, RAfEG - Eine Open Source basierte Architektur fur¨ die Abarbeitung von Verwaltungsprozessen im E-Government, April 2006, Chemnitz CSR-06-04 Michael K¨ampf, Probleme der Tourenbildung, Mai 2006, Chemnitz CSR-06-06 Torsten Hoefler, Mirko Reinhardt, Torsten Mehlan, Frank Mietke, Wolfgang Rehm, Low Overhead Ethernet Communication for Open MPI on Linux Clusters, Juli 2006, Chemnitz CSR-06-07 Karsten Hilbert, Guido Brunnett, A Texture-Based Appearance Preserving Level of Detail Algorithm for Real-time Rendering of High Quality Images, August 2006, Chemnitz CSR-06-08 David Brunner, Guido Brunnett, Robin Strand, A High-Perpormance Paral- lel Thinning Approach Using a Non-Cubic Grid Structure, September 2006, Chemnitz CSR-06-09 El-Ashry, Peter K¨ochel, Sebastian Schuler,¨ On Models and Solutions for the Allocation of Transportation Resources in Hub-and-Spoke Systems, Septem- ber 2006, Chemnitz CSR-06-10 Raphael Kunis, Gudula Runger,¨ Michael Schwind, Dokumentenmanagement fur¨ Verwaltungsvorg¨ange im E-Government, Oktober 2006, Chemnitz CSR-06-11 Daniel Beer, J¨org Dummler,¨ Gudula Runger,¨ Transformation ereignisgesteu- erter Prozeßketten in Workflowbeschreibungen im XPDL-Format, Oktober 2006, Chemnitz CSR-07-01 David Brunner, Guido Brunnett, High Quality Force Field Approximation in Linear Time and its Application to Skeletonization, April 2007, Chemnitz CSR-07-02 Torsten Hoefler, Torsten Mehlan, Wolfgang Rehm (Eds.), Kommunikati- on in Clusterrechnern und Clusterverbundsystemen, Tagungsband zum 2. Workshop, Februar 2007, Chemnitz CSR-07-03 Matthias Vodel, Mirko Caspar, Wolfram Hardt, Energy-Balanced Coopera- tive Routing Approach for Radio Standard Spanning Mobile Ad Hoc Net- works, Oktober 2007, Chemnitz CSR-07-04 Matthias Vodel, Mirko Caspar, Wolfram Hardt, A Concept for Radio Stan- dard Spanning Communication in Mobile Ad Hoc Networks, Oktober 2007, Chemnitz Chemnitzer Informatik-Berichte CSR-07-05 Raphael Kunis, Gudula Runger,¨ RAfEG: Referenz-Systemarchitektur und prototypische Umsetzung - Ausschnitt aus dem Abschlussbericht zum Pro- jekt ”Referenzarchitektur fur¨ E-Government” (RAfEG) -, Dezember 2007, Chemnitz

CSR-08-01 Johannes Steinmuller,¨ Holger Langner, Marc Ritter, Jens Zeidler (Hrsg.), 15 Jahre Kunstliche¨ Intelligenz an der TU Chemnitz, April 2008, Chemnitz CSR-08-02 Petr Kroha, Jos´eEmilio Labra Gayo, Using Semantic Web Technology in Requirements Specifications, November 2008, Chemnitz CSR-09-01 Amin Coja-Oghlan, Andreas Goerdt, Andr´eLanka, Spectral Partitioning of Random Graphs with Given Expected Degrees - Detailed Version, Januar 2009, Chemnitz CSR-09-02 Enrico Kienel, Guido Brunnett, GPU-Accelerated Contour Extraction on Large Images Using Snakes, Februar 2009, Chemnitz

CSR-09-03 Peter K¨ochel, Simulation Optimisation: Approaches, Examples, and Expe- riences, M¨arz 2009, Chemnitz CSR-09-04 Maximilian Eibl, Jens Kursten,¨ Marc Ritter (Hrsg.), Workshop Audiovisu- elle Medien: WAM 2009, Juni 2009, Chemnitz

CSR-09-05 Christian H¨orr, Elisabeth Lindinger, Guido Brunnett, Considerations on Technical Sketch Generation from 3D Scanned Cultural Heritage, September 2009, Chemnitz

CSR-09-06 Christian H¨orr, Elisabeth Lindinger, Guido Brunnett, New Paradigms for Automated Classification of Pottery, September 2009, Chemnitz

CSR-10-01 Maximilian Eibl, Jens Kursten,¨ Robert Knauf, Marc Ritter , Workshop Au- diovisuelle Medien, Mai 2010, Chemnitz

CSR-10-02 Thomas Reichel, Gudula Runger,¨ Daniel Steger, Haibin Xu, IT- Unterstutzung¨ zur energiesensitiven Produktentwicklung, Juli 2010, Chemnitz

CSR-10-03 Bj¨orn Krellner, Thomas Reichel, Gudula Runger,¨ Marvin Ferber, Sascha Hu- nold, Thomas Rauber, Jurgen¨ Berndt, Ingo Nobbers, Transformation mo- nolithischer Business-Softwaresysteme in verteilte, workflowbasierte Client- Server-Architekturen, Juli 2010, Chemnitz Chemnitzer Informatik-Berichte ISSN 0947-5125

Herausgeber: Fakult¨at fur¨ Informatik, TU Chemnitz Straße der Nationen 62, D-09111 Chemnitz