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

Transkript

1 Fakultät für Informatik CSR Transformation monolithischer Business-Softwaresysteme in verteilte, workflowbasierte Client-Server-Architekturen Björn Krellner Thomas Reichel Gudula Rünger Marvin Ferber Sascha Hunold Thomas Rauber Jürgen Berndt Ingo Nobbers Juli 2010 Chemnitzer Informatik-Berichte

2 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 Krellner 1, Thomas Reichel 1, Gudula Rünger 1 Marvin Ferber 2, Sascha Hunold 2, Thomas Rauber 2 Jürgen Berndt 3, Ingo Nobbers 3 1 TU Chemnitz, Professur Praktische Informatik, Chemnitz 2 Universität Bayreuth, Lehrstuhl für Angewandte Informatik II, Bayreuth 3 Berndt & Brungs Software GmbH, Mottmannstr. 1 3, 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.

3

4 Inhaltsverzeichnis 1 Kurzdarstellung Aufgabenstellung Voraussetzung für die Durchführung des Vorhabens Planung und Ablauf des Vorhabens Anknüpfung an den wissenschaftlich-technischen Stand Zusammenarbeit mit anderen Stellen Eingehende Darstellung Erzielte Ergebnisse und Aufbau des Berichts Wichtige Positionen des zahlenmäßigen Nachweises Notwendigkeit und Angemessenheit der geleisteten Arbeit Voraussichtlicher Nutzen, insbesondere Verwertbarkeit des Ergebnisses Während der Durchführung des Projekts bekannt gewordener Fortschritt auf dem Gebiet des Vorhabens Erfolgte und geplante Veröffentlichungen des Ergebnisses GBware und GBwareD Analyse von GBware Kurzbeschreibung GBware Systemarchitektur Abarbeitung der Geschäftsprozesse Ablaufumgebungen Erstellung eines Anforderungskatalogs an GBwareD Kundenspezifische Anforderungen Anforderungen an GBwareD Hard- und Softwarekonfiguration von GBwareD Vorbereitungs- und Anpassungsarbeiten für GBware Modularisierung von GBware Entwurf der Schnittstellen zwischen Modulen Extraktion der Workflow-Komponenten in GBware Testszenarien Kundenspezifische Konfigurationsmöglichkeiten Entwurf des Transformationssystems Anforderungen an Transformationen und Transformationssystem Basistechnologien und verwandte Ansätze Verteilungsplattformen Transformationsframeworks und -ansätze Workflowbeschreibungen

5 Inhaltsverzeichnis 4.3 Konzeption des Transformationsprozesses Softwaresichten Grobstruktur des Transformationsprozesses Entwurf einer Software-Architektur des Transformationssystems Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Model Driven Architecture (MDA) MDA Entwicklungsprozess MDA Werkzeuge Modellspezifikationen für Software und Transformationen Toolunterstützung der Verarbeitung der Transformation Compilerwerkzeuge Visualisierungswerkzeuge Entwicklung und Realisierung des Transformationssystems Realisierung des Transformationssystems TRANSFORMR Inkrementeller Transformationsprozess Flexible Software Representation (FSR) Nutzerschnittstelle des Transformationssystems Metakomponenten des Transformationssystems Realisierung prototypischer Komponentenbildungstransformationen MemberGroups Verschiebetransformationen Evaluierung der Verschiebetransformationen Realisierung prototypischer Filtertransformationen Skalierbarkeit des Transformationssystems Entwurf eines Client-Server-Frameworks CBFRAME Zielsetzung Anforderungen Evaluation von Open Source Business-Software-Systemen Middleware-Plattform Anforderungen Java Enterprise Edition CORBA Component Model NET Framework Zusammenfassung Transformation der grafischen Benutzeroberfläche Zielsetzung Konzepte zur UI-Transformation von GBware Zusammenfassung Rahmenarchitektur von CBFRAME Zusammenfassung

6 Inhaltsverzeichnis 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server- Frameworks Zielsetzung Workflow-Beschreibungssprachen EPK BPMN Bewertung grafischer Modellierungswerkzeuge JPDL XPDL BPEL Fazit Vergleich verschiedener BPEL-Implementierungen Untersuchung der Kommunikationseigenschaften von JEE Anbindung von Legacy-Software über JMS Anbinden von Delphi-Clients an JEE-Applikationsserver Kommunikation mit Enterprise JavaBeans über CORBA Zusammenfassung Das Client-Server-Framework Zielsetzung Das CBFRAME-Remote-Adapter-Pattern Musterbasierte Quellcodetransformation Verteilte Ausführung von Geschäftslogik Definition des CBFRAME-Remote-Adapter-Pattern Anwendung des CBFRAME-Remote-Adapter-Pattern Integration in TRANSFORMR CBFRAME-Remote-Adapter-Pattern für Webservices Effiziente verteilte Workflow-Abarbeitung Problemstellung und Ziele Automatische Transformation von BPEL-Prozessen Lastverteilungsverfahren für BPEL-Prozesse Zusammenfassung Prototypische Transformation der Referenzsoftware GBware Prototypische Analyse und Transformation mit TRANSFORMR Anwendung von TRANSFORMR auf GBware Anwendung von TRANSFORMR auf TurboCASH Prototypische UI-Transformation von GBware Abstrakte UI-Zwischendarstellung GUI-Transformation von Delphi nach Java Anpassung der generierten GUI Diskussion über die Grenzen des Verfahrens Evaluierung von Kunden-Workflows Auswahl und Evaluierung der Workflow-Komponenten Anpassung der Kunden-Workflows Zusammenfassung

7 Inhaltsverzeichnis 11 Zusammenfassung Literaturverzeichnis 157 6

8 Abbildungsverzeichnis Schicht Systemarchitektur der Business-Software GBware Schematische Darstellung der Abarbeitung eines Workflows in GBware Konzept der Systemarchitektur der verteilten Business-Software GBwareD Beispiel einer TTable mit generierten Adressdaten in einer Nutzerschnittstelle Schematische Darstellung der Modellierung von Geschäftsprozessen in GBware als zustandsbasierte Workflows mit assoziierten Aktionen Nutzerschnittstelle des exemplarischen GBware mit reduzierter Funktionalität ER-Modell der Abbildung von Geschäftsprozessen in einer relationalen Datenbank Übergangsdiagramm der Flexible Software Representation (FSR) in verschiedene Softwaresichten Transformationsentscheidungen und Transformationsprozess Schematische Darstellung der Architektur des Transformationssystems Transformationsansatz nach der Model Driven Architecture (MDA) Softwaremodelle Program Representation Graph und Dagstuhl Middle Model Entwurf der Flexible Software Representation Allgemeine Funktionsweise von TXL nach [15] Transformationsprozess des Toolsets TRANSFORMR Abstraktionsebenen des Transformationsprozesses Softwaremodell (FSR) des Toolsets TRANSFORMR Nutzerschnittstelle des Werkzeugs TRANSFORMR Graph Dependency View des Toolsets TRANSFORMR Beispiel einer Source-to-Model Transformation TXL-Grammatik zum Hinzufügen von Annotationen Membergroup Browser zur Analyse der FSR Aufrufdiagramme zur Verschiebung einer common Membergroup Aufrufdiagramme zur Verschiebung einer strong Membergroup UML-Diagramme der Extraktion eines Interfaces aus Basismodulen Beispiel einer TXL-Transformationsregel zur Extraktion eines Interfaces Laufzeitverhalten der Extraktionsphase Speicherbedarf von Zwischendarstellung und Softwaremodell (FSR) Beziehung von Laufzeit und Programmgröße in der Extraktionsphase

9 Abbildungsverzeichnis 7.1 Frontend-Transformation, Konzept Frontend-Transformation, Konzept Architektur von CBFRAME für Web-Clients Beispiel grafisch modellierter Business Prozesses. (Links: BPMN, Rechts: EPK) Vergleich des erzielten Durchsatzes von JMS und MPI Mögliche Anbindung des GBware-Clients an Java Enterprise Server CORBA-JEE-Bridge Zugriff auf Java-Routinen von Delphi Schematische Darstellung der schrittweisen Anwendung einer musterbasierten Transformation UML-Darstellung des CBFRAME-Remote-Adapter-Pattern Anwendung des CBFRAME-Remote-Adapter-Pattern zur automatischen Auslagerung von Methoden auf entfernte Server Beispiel eines Templates zur automatischen Erzeugung eines Serviceanbieters auf Serverseite (RMI) Screenshot des erzeugten Client/Server-Programms zur Berechnung eines Mandelbrot-Bildes Velocity-Template zur Generierung eines Remote-Interface Implementierung des CBFRAME-Remote-Adapter-Pattern für Java und RMI in TRANSFORMR Exemplarische Bereitstellung einer Funktion als Webservice Als Webservice ausgelagerte Funktion Workflowabarbeitung mit räumlich verteilten, redundanten Dienstanbietern (Providern) Der Ausgangs-Workflow (oben) und der transformierte Workflow (unten) mit Scheduler zur Lastbalancierung der Webservice-Aufrufe Durchschnittliche Ausführungszeit eines BPEL-Prozesses mit 10 Webservice-Aufrufen Aufbau von Delphi Programmcode UML-Klassendiagramm eines Ausschnitts des betrachteten Programmcodes Screenshot der Nutzerschnittstelle von TurboCASH Screenshots der Analyse von TurboCASH mit TRANSFORMR Transformation und Konvertierung der Oberfläche einer Legacy- Anwendung Mögliche Transformation einer Delphi-Oberfläche Beispiel einer abstrakten Darstellung der GUI Beispiel einer Delphi-Java-Transformation Abbildung des Kunden-Workflows Rechnung aus GBware als Zustandsautomat Abbildung des Kunden-Workflows Rechnung und modifizierter Kunden-Workflow mit Integration einer Liquiditätsprüfung

10 Tabellenverzeichnis 1.1 Zusammenfassender Überblick über die Arbeitspakete Konfiguration von Betriebssystem und Datenbankserver für GBware Abstraktionsschichten der Softwaresichten der FSR Auswahl frei verfügbarer und proprietärer MDA Werkzeuge (Stand: September 2006) Unterstützte Betriebssysteme des Laufzeitsystems und der genutzten Werkzeuge des Transformationssystems Knotenmengen und Kanten des Softwaremodells zur Ermittlung von MemberGroups Verbesserungen der Anzahl abhängiger Klassenpaare Vergleich von Open Source-ERP-Systemen Implementierungen der Java-Enterprise-Edition Programmiersprachen mit CORBA-Anbindung Vergleich von CORBA-Implementierungen Gegenüberstellung von Enterprise-Frameworks Vergleich verschiedener BPEL-Ablaufumgebungen Vergleich der Antwortzeiten einer Funktion für unterschiedliche Kontexte Zuordnung von Elementen einer Delphi Unit zu Modellelementen der FSR Verwendete Dateitypen in Konfiguration und Programmcode von TurboCASH Freie Projekte zur Generierung der grafischen Benutzeroberfläche für Java.145 9

11 10 Tabellenverzeichnis

12 1 Kurzdarstellung 1.1 Aufgabenstellung Das Ziel des Projekts TransBS bestand in der Entwicklung einer Methodik zur Überführung existierender, monolithischer Business-Softwaresysteme in eine moderne, komponentenbasierte, 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 korrektheitserhaltenden 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 inkrementeller Transformationsansatz vorgeschlagen, durch den schrittweise aus der gegebenen Grobstruktur eine den speziellen Anforderungen entsprechende, verteilte Software entsteht. Das Transformationswerkzeug sollte über geeignete 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 Heterogenität eine wesentliche Rolle. Die Entwicklung eines offenen, erweiterbaren und modularen Client-Server-Frameworks 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 Softwaresystem GBwareD. GBwareD sollte über spezielle Workflows gemäß kundenspezifischer Gegebenheiten konfiguriert bzw. parametrisiert und für neue Aufgabenbereiche erweitert werden können. Die Transformation existierender, über viele Jahre gewachsener Softwaresysteme in modulare und skalierbare Systeme, die auf unterschiedlichen Plattformen ausführbar sind, 11

13 1 Kurzdarstellung ist eine der großen Herausforderungen im Softwarebereich. Die im Projekt TransBS entwickelte 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 Arbeitspunkte 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 angewendet 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 interdisziplinärer Zusammenarbeit mit Partnern aus Industrie und Wissenschaft. Darüber hinaus spielt die Realisierung von Übersetzerwerkzeugen zur schrittweisen Transformation 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 Vermittlerrolle 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 Bayreuth umfasst die Realisierung spezialisierter, anwendungsorientierter Hard- und Softwarelö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 Umsetzung komponentenbasierter Anwendungen auf verschiedenen Plattformen. Die Universität Bayreuth war schwerpunktmäßig mit dem Entwurf und der Realisierung des Client-Server-Frameworks sowie der Entwicklung geeigneter Protokolle und Schnittstellen zwischen Client und Server befasst (Kapitel 7 bis 9 und 10). 12

14 1.3 Planung und Ablauf des Vorhabens Berndt & Brungs Software GmbH, Troisdorf Die Berndt & Brungs Software GmbH gegründet 1987, verfügt über umfangreiche Erfahrungen im Bereich der kaufmännischen Prozesse und deren Konzeption und Umsetzung 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 schwerpunktmäß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 Arbeitspunkte 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 bearbeitet 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. Arbeitspakete Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete. Bezeichnung Inhaltsbeschreibung Beteiligte AP 1 Analyse von GBware Analyse des Ist-Zustandes von GBware und Erfassung von kundenspezifischen Gegebenheiten, die für eine Transformation und verteilte Ausführung berücksichtigt werden sollen. AP 1.1 AP 1.2 Analyse der Systemarchitektur Erfassung der Workfloweigenschaften BBS 13

15 1 Kurzdarstellung Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete. Arbeitspakete AP 1.3 AP 1.4 Bezeichnung Inhaltsbeschreibung Beteiligte Erfassung der Voraussetzungen von Kundenseite Erfassung der Anforderungen an die Ausführungsplattform AP 2 AP 2.1 AP 2.2 AP 2.3 AP 2.4 AP 3 AP 3.1 AP 3.2 AP 3.3 AP 3.4 AP 3.5 AP 4 AP 4.1 AP 4.2 AP 4.3 AP 4.4 AP 5 AP 5.1 AP 5.2 AP 5.3 Erstellung eines Anforderungskataloges an GBwareD Konkretisierung der Anforderungen an das resultierende Softwaresystem GBwareD und Prüfung auf Konsistenz und Machbarkeit. Konkretisierung der Anforderungen an eine verteilte Realisierung Untersuchung der Anforderungen an die verteilten Workflows Erfassung der Ziel-Hardwarekonfiguration Bestimmung der zu integrierenden Teile von GBware Vorbereitungs- und Anpassungsarbeiten für GBware Vorbereitung von GBware auf den Transformationsprozess, vor allen eine Modularisierung, Untersuchung von Abhängigkeiten und Definition von Schnittstellen. Modularisierung von GBware Entwurf von Schnittstellen zwischen den Modulen Extraktion der Workflowkomponenten von GBware Definition eines Testszenarios Spezifikation kundenspezifischer Konfigurationsmöglichkeiten Entwurf des Transformationssystems TransBS Entwurf der Mechanismen des Transformationsprozesses, Spezifikation der Zwischenformate, Automatisierungs- und Interaktionsmöglichkeiten der Transformation. Erstellung einer Anforderungsspezifikation an die Transformationssoftware Planung und Entwurf des inkrementellen Transformationsvorgangs Anforderungskatalog und Planung von Korrektheits- und Bewertungsmechanismen Entwurf der Softwarearchitektur des Transformationssystems Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Evaluation existierender Sprach- und Transformationsansätze und Festlegung von Sprachkonzepten und -Mechanismen. Erfassung und Auswahl von Transformationsmechanismen Erfassung, Auswahl und Definition von Spezifikationssprachen Planung von Metakomponenten des Transformationswerkzeuges BBS BBS TUC TUC AP 6 Entwicklung und Realisierung des prototypischen Transformationssystems AP 6.1 AP 6.2 Inkrementelle Realisierung eines prototypischen Transformationssystems basierend auf AP 4 und AP 5 und Evaluation der Werkzeugkomponenten. Planung und Festlegung der Hard- und Softwareplattformen Entwicklung und Realisierung des Transformationsfrontends TUC 14

16 1.3 Planung und Ablauf des Vorhabens Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete. Arbeitspakete AP 6.3 AP 6.4 AP 6.5 AP 6.6 Bezeichnung Inhaltsbeschreibung Beteiligte Entwicklung und Realisierung der Komponentenbildungs-Transformation Entwicklung und Realisierung der Filter-Transformation Entwicklung und Realisierung der Metakomponenten Evaluation der Werkzeugkomponenten AP 7 Entwurf eines Client- Server-Frameworks CBFrame AP 7.1 AP 7.2 AP 7.3 AP 7.4 AP 7.5 AP 7.6 Analyse der Anforderungen an eine verteilte Software und Festlegung von Funktionalität und Komponenten des Frameworks. Entwurf der Architektur des Frameworks Entwurf der statischen Komponenten des Frameworks Festlegung des verwendeten Kommunikationsprotokolls Definition eines Sicherheitskonzepts Mechanismen zur Ausfallsicherheit durch Datenredundanz Definition der verwendeten Workflows AP 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server- Frameworks AP 8.1 AP 8.2 AP 8.3 Auswahl einer Infrastruktur durch Analyse von Laufzeitsystemen zur Verarbeitung von Workflows und Untersuchung von Middlewarelösungen (z. B. JRE, CORBA). Definition einer Spezifikationssprache für Workflows Auswahl einer Implementierungsplattform Entwicklung einer Kommunikationsplattform AP 9 Entwicklung und Realisierung des prototypischen Client-Server- Frameworks AP 9.1 AP 9.2 AP 9.3 AP 9.4 AP 9.5 AP 9.6 Implementierung eines prototypischen Frameworks aufbauend auf AP 7 und AP 8 zur Integration von erzeugten Komponenten von GBware. Entwicklung und Realisierung des Kommunikationsprotokolls Entwicklung und Realisierung des Kommunikationsmoduls Entwicklung und Realisierung der Datenhaltungskomponente mit Datenkonsistenz Entwicklung und Realisierung der Marshalling-Komponente zur Konvertierung von Datenformaten Entwicklung und Realisierung einer Flattening-Komponente zur Workflow-Verarbeitung Evaluation der Framework-Komponenten AP 10 Prototypische Transformation der Referenzsoftware GBware Abschließende Evaluation und Dokumentation verschiedener Teile des Prototyps aus Transformationswerkzeug und Client-Server- 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 UBT UBT UBT BBS, UBT, TUC 15

17 1 Kurzdarstellung Tabelle 1.1: Zusammenfassender Überblick über die Arbeitspakete. Arbeitspakete Bezeichnung Inhaltsbeschreibung Beteiligte AP 11 Projektmanagement, Publikationstätigkeit Regelmäßige Projekttreffen zur Koordination der Arbeiten und Veröffentlichung erreichter Resultate in internationalen Publikationsorganen. BBS, UBT, TUC 1.4 Anknüpfung an den wissenschaftlich-technischen Stand Softwaresysteme zur Realisierung von Geschäftsprozessen erfordern eine weitgehende Konfigurierbarkeit, Adaptionsmöglichkeit und Erweiterbarkeit gemäß kundenspezifischer Anforderungen, sollen aber möglichst kostengünstig realisiert werden. Ausgangspunkt 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 Softwarestrukturen 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 ursprünglichen Architektur führen kann (Code Decay [18]) und eine Restrukturierung des Gesamtsystems notwendig macht. Bisherigen Softwaresystemen fehlen häufig entscheidende Aspekte wie Verteiltheit, Anpassbarkeit an heterogene Plattformen oder Skalierbarkeit, 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 erfordern können und alle Bereiche eines Unternehmens betreffen können. Der Problemkreis der Realisierung moderner, verteilter, effektiver Unternehmenssoftware wird in jüngster Zeit aus verschiedenen Gesichtspunkten und Wissenschaftsdisziplinen 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 Softwaredesignprinzipien für verteilte Systeme. Eine häufige Fragestellung im Management- oder Software-Engineeringbereich ist die kostengünstige und effektive Überführung erprobter monolithischer Unternehmenssoftware 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

18 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 bedingen weitreichende Änderungen der Anforderungen eine wesentliche Überarbeitung der Architektur der bestehenden Softwaresysteme, was ebenfalls die Fragestellung nach einer kostengünstigen und effektiven Überführung aufwirft. Die zahlreichen Ansätze zur Entwicklung komponentenbasierter und verteilter Systeme berücksichtigen dieses Problem kaum in detaillierter Form, sondern beschäftigen sich entweder mit dem Design neuer Software oder mit der ganzheitlichen Ankopplung bestehender Softwarekomponenten ü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 entwickelt, die im Transformationswerkzeug TRANSFORMR prototypisch realisiert sind. Ein Hauptbeitrag des Projekts lag in der Entwicklung der inkrementellen Transformationsmethodik, in der schrittweise aus einer gegebenen monolithischen Software interaktiv eine auf einer Client-Server-Architektur basierende Software erzeugt wird. Die umfassende Analyse der bestehenden Software stellt dabei eine maßgebliche Voraussetzung 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 Bestandteil des Projekts. 1.5 Zusammenarbeit mit anderen Stellen Innerhalb des TransBS-Konsortiums waren alle für das Projekt wesentlichen Kompetenzen durch die Projektbeteiligten vertreten: Praktiker im Umfeld von kaufmännischen Prozessen und Entwicklung von Business-Software anhand kundenspezifischer Anforderungen und wissenschaftliche Forschung im Bereich der Software- und Systementwicklung verteilter und heterogener Systeme sowie die Entwicklung und Realisierung von Transformationswerkzeugen im Bereich Compilerbau. 17

19 18 1 Kurzdarstellung

20 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 dargestellt. Kapitel 3 beschreibt die Analyse der Business-Software GBware, stellt einen Anforderungskatalog an ein verteiltes System GBwareD vor und beschreibt die durchgeführten Vorbereitungs- und Anpassungsarbeiten zur Realisierung der gestellten Anforderungen. Die Kapitel 4 bis 6 beschreiben die Konzepte und die Realisierung des Transformationssystems. Aufbauend auf einem allgemeinen inkrementellen Transformationsansatz werden mögliche existierende Softwaresysteme zur Umsetzung des Transformationsansatzes evaluiert. Abschließend wird in Kapitel 6 die Implementierung des Transformationswerkzeugs TRANSFORMR dargelegt. Der Entwurf des Client-Server-Frameworks und der darin enthaltenen Komponenten wird in Kapitel 7 erörtert. Auf dieser Grundlage werden in Kapitel 8 Infrastrukturen zur Umsetzung des Frameworks evaluiert, die in Kapitel 9 in der prototypische Realisierung des Frameworks CBFRAME münden. Im Kapitel 10 werden die prototypisch realisierten Werkzeuge des Transformationssystems 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 Personalmittel 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 rechnerischen Nachweisen enthalten. 19

21 2 Eingehende Darstellung 2.3 Notwendigkeit und Angemessenheit der geleisteten Arbeit Bei den angestrebten Projektzielen (Abschnitt 1.1) handelte es sich um zusätzliche Aktivitä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 durchgeführt werden konnte. Durch die Förderung wurden Konzepte zur schrittweisen Überführung der bestehenden Software GBware identifiziert und in einem generischen Werkzeug prototypisch realisiert, die auch in anderen Business-Software-Systemen Anwendung finden können. Dabei stellten sich vor allem die Analyse und Transformation von Programmcode (Kapitel 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 Erzeugung von Verteiltheit und Modularität konnten erfolgreich für GBware und weitere untersuchte 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, insbesondere die Betrachtungen zu Modularität, Verteiltheit und Parallelität, werden an den jeweiligen Professuren weiter verfolgt. Dabei bildet der entwickelte Prototyp eines Transformationswerkzeugs (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 Bedü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 Fuhrparkmanagement) ausbauen. 20

22 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 Arbeiten 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 automatischer Code-Transformationen. Ein wesentlicher Aspekt ist die Zusammenarbeit der Transformationswerkzeuge (bspw. über ein gemeinsames Austauschformat), um je nach vorliegender Problemstellung geeignete Transformationsmechanismen zu verwenden [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 generieren. Die Erzeugung eines vollständigen plattformunabhängigen Modells für bestehenden Programmcode steht jedoch wie zum Zeitpunkt der Antragstellung weiterhin aus (siehe auch Kapitel 5.1). Die Entwicklung WFMC-konformer 1 Open Source Workflow-Engines und die Evaluation 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 Einbettung individueller Geschäftsprozesse bieten, hat sich weiter fortgesetzt. Die für das Projekt 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 Komponenten in XML, hin zur Festlegung von Eigenschaften durch Annotationen. Durch die Kombination einer großen Zahl unterschiedlicher Komponenten zur effektiven Realisierung einer Business-Plattform ist eine Einbindung bestehender Software in die Frameworks nur durch komplexe Transformationen möglich [28]. 1 Workflow Management Coalition: Verbund von über 300 Herstellern, Beratern und Wissenschaftlern zur Standardisierung und Etablierung eines Workflow-Referenzmodells. 21

23 2.6 Veröffentlichungen Gegenüber den im Antrag dargestellten Aktivitäten haben sich keine Änderungen ergeben. 2.6 Erfolgte und geplante Veröffentlichungen des Ergebnisses Erfolgte Veröffentlichungen [FHK + 09a] FERBER, 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 Techniques (CEE-SET), [FHK + 09b] FERBER, M., S. HUNOLD, B. KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Softwaremodernisierung durch werkzeugunterstütztes Verschieben von Codeblöcken. In: Software Engineering Workshopband, Band P-150 der Reihe Lecture Notes in Informatics, Seiten , Bonn, Köllen Druck+Verlag GmbH. [FHR09] FERBER, 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 Parallel Processing Workshops, Seiten , Washington, DC, USA, IEEE Computer Society. [HKK + 08a] HUNOLD, S., M. KORCH, B. KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Inkrementelle Transformation einer monolithischen Geschäftssoftware. In: Software Engineering Workshopband, Band P- 122 der Reihe Lecture Notes in Informatics, Seiten , Bonn, Köllen Druck+Verlag GmbH. [HKK + 08b] HUNOLD, S., M. KORCH, B. KRELLNER, T. RAUBER, T. REICHEL und G. RÜNGER: Transformation of Legacy Software into Client/Server Applications through Pattern-based Rearchitecturing. In: Proc. of the 32nd Annual IEEE Int. Computer Software and Applications Conf., COMPSAC 08, Seiten IEEE Computer Society, [HKR + 09] [KR06] HUNOLD, 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 Springer, 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,

24 2.6 Geplante Veröffentlichungen [RR06] [RR07] [RR08] [RR10] RAUBER, T und G. RÜNGER: Transformation von Business-Software für Client-Server Architekturen. BMBF-Statuskonferenz, Leipzig, RAUBER, T. und G. RÜNGER: Transformation of Legacy Business Software into Client-Server Architectures. In: Proc. of the 9th Int. Conf. on Enterprise Information Systems, Seiten INSTICC, RAUBER, T. und G. RÜNGER: Incremental Transformation of Business Software. In: Lecture Notes in Business Information Processing, Band 12 der Reihe LNBIP, Seiten Springer, RAUBER, 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), Geplante Veröffentlichungen [BFH + ] BERNDT, 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] FERBER, M., S. HUNOLD und T. RAUBER: BPEL Remote Objects: Integrating BPEL Processes into Object-Oriented Applications. Konferenzbeitrag. [FHRb] FERBER, M., S. HUNOLD und T. RAUBER: Executing Software Modules in a Compute Cloud Using Web Service Technology. Konferenzbeitrag. [KRR] [RR] KRELLNER, B., T. REICHEL und G. RÜNGER: TransFormr - Incremental Transformation of Legacy Business Software Systems. Zeitschriftenartikel. REICHEL, T. und G. RÜNGER: Incremental Software Restructuring by Successive Dependency Analysis and Transformation. Konferenzbeitrag. 23

25 Geplante Veröffentlichungen

26 3 GBware und GBwareD 3.1 Analyse von GBware Kurzbeschreibung GBware GBware (jetzt aimap) ist eine voll integrierte kaufmännische Anwendung, die als Prozesssteuerungswerkzeug 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, Zahlungsund Mahnwesen, Marketing oder Lagerverwaltung sowie einigen individuellen Modulen wie z. B. die Projektakte zur Projekt- und Dokumentenverwaltung im Internet abgebildet werden. Die spezifischen Geschäftsprozesse der einzelnen Kunden werden durch eine Parametrisierung von GBware und die Integration individueller Prozesse im System abgelegt. Dabei liegt ein Schwerpunkt auf der schnellen Ausführung der Prozesse bei gleichzeitiger Sicherstellung der Datenkonsistenz durch eine transaktionsbasierte Steuerung Systemarchitektur Die Architektur der Business-Software GBware kann in drei Schichten eingeteilt werden. Abbildung 3.1 veranschaulicht die drei Schichten und ihre Abhängigkeiten. In der zentralen Datenbank werden sowohl die Geschäftsdaten als auch die Darstellung der Geschäftsprozesse als Workflows abgelegt. Für den jeweiligen Kunden werden darüber hinaus über Administrationsmodule die Rechte und Rollen der Nutzer von GBware und ihre Sichten auf die Geschäftsdaten gespeichert. Zudem wird die Konfiguration der vom Kunden genutzten Module ebenfalls in der Datenbank hinterlegt. Durch die Nutzung einer Oracle Datenbank konnten spezifische, leistungskritische 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öglichkeit Business-Logik vom Client zu extrahieren. 25

27 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 GBware 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 GBware. 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 zustä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 weitergereicht, über dessen Methoden Datenbankabfragen auch entfernt aufgerufen werden 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 Verarbeitungsregeln 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 Daten 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 Zugriffe 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 zustandsbasierten Geschäftsprozessen gesteuert. 26

28 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 Internet, 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 Einund Ausgaben notwendig (Fehlerkorrektur auf Server, bzw. auf Client über dynamische Web-Inhalte). Gleichzeitig soll eine Duplizierung der Funktionalität und damit eine doppelte Wartung der eigentlichen Business-Logik möglichst vermieden werden, um die Fehleranfälligkeit des Systems zu minimieren und damit sein bisheriges Marktpotential zu erhalten 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 verwendet wird. Die Prozesse werden fest in der Datenbank konfiguriert und abgelegt und durch Nutzer-, Zeit- oder Datenbankereignisse ausgelöst und gesteuert. Durch die Konfiguration der Geschäftsprozesse in der Datenbank des Kunden können Feinabstimmungen oder 27

29 3 GBware und GBwareD Tabelle 3.1: Konfiguration von Betriebssystem und Datenbankserver für GBware. Betriebssystem Windows NT4 SP6 Windows 2000, XP, 2003 (Server) Windows Vista, Windows 7 SuSe Linux Enterprise Server Datenbankversion Oracle 8i Oracle 8i, Oracle 10g Oracle 10g 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 Abbildung 3.2 ist eine schematische Darstellung der Abarbeitung eines Workflows in GBware als Flussdiagramm abgebildet. Der Workflow wird durch ein Ereignis aus der Nutzerschnittstelle 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 erfolgreich abgeschlossen, kann der erste hinterlegte Prozessschritt ( s erzeugen) ausgeführt werden. In jedem Schritt kann der Statusübergang an weitere Aktionen des Nutzers gekoppelt sein. In der Abbildung wird die erzeugung durch Schablonen nur im dem Fall ausgeführt, wenn der Nutzer dies wünscht. Je nach ausgewählter Aktion 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ühren (z. B. Wechsel in den Status s gesendet oder s senden verschoben). An jeden Prozessschritt können weitere Schritte angefügt werden (Rekursionen vorhanden). Diese weiteren Schritte können ihrerseits weitere Anweisungen ausführen oder auch neue Aktionen auslösen, die die Geschäftsobjekte auch anderen Nutzern zur Abarbeitung 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 werden zum Teil vom Nutzer selbst spezifiziert, können aber auch durch den Gesetzgeber vorgegeben sein 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 Delphi 7 Entwicklungsumgebung implementiert. Als Datenbank nutzt GBware Oracle ab Version 8i. 28

30 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-Server und Client auf einem einzigen Rechner installiert. 2. Klassisch: Bei der klassischen Variante werden Datenbank und Application-Server 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 Datenbankversionen 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-Betriebssystem benötigen. 3.2 Erstellung eines Anforderungskatalogs an GBwareD 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 bestehende 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 örtlich nicht begrenzte Nutzung von GBware wichtig. Die Bereitstellung eines internetfähigen Client-Rechners kann meist ohne große Probleme gewährleistet werden. Auch wenn die Installation des GBware-Delphi-Clients sehr einfach gehalten 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 Übertragung, möglichst geringe Antwortzeiten und eine gleichartige Nutzerschnittstelle zu berücksichtigen. Zusätzlich bestehen Überlegungen der Anbindung von Thin- Clients. 29

31 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 manuellen 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 Webschnittstelle sinnvoll ist. Lastverteilung auf mehrere Application-Server. Zur effizienteren Abarbeitung von Anfragen und zur Erhöhung der Ausfallsicherheit des Systems ist eine Lastverteilung auf mehrere Application-Server erwünscht. Wie auch bei den Anforderungen des Webzugriffs sollen sich dabei die Response-Zeiten nicht verschlechtern (diese ist im Moment vor allem durch die Datenbankzugriffe bedingt). Erweiterte Parametrisierung der Geschäftsprozesse. Da jedes Kundenunternehmen ü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 Kommunikationsmedien in den Workflow, wie z. B. , Fax oder SMS, sowohl für die Erstellung von Berichten als auch für das Auslösen von Ereignissen im Geschä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 Zukunft wird diese Anforderung entscheidend sein 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 Kapselung ist notwendig, um Programmlogik, die sich bisher im Delphi-Client befand, auch für das Web-Backend bereitzustellen und dabei eine Duplizierung, und damit eine doppelte Pflege des Codes, zu vermeiden. Da in Web-Clients kaum Logik integriert werden kann oder soll (bestimmte Kunden verzichten aus Sicherheitsgründen auf Client-Seite auf dynamische Webinhalte), muss die Business-Logik aus dem bisherigen Delphi-Client in den Application-Server oder als Datenbankfunktionalität in die Datenbank verschoben werden. Dabei bleibt abzuwägen, in wie weit auch Präsentationslogik (bspw. die Überprüfung einer Eingabe eines Formularfelds) verschoben werden sollte, da jede 30

32 3.2 Erstellung eines Anforderungskatalogs an GBwareD Kommunikation mit Application-Server oder Datenbank wesentlich längere Antwortzeiten als die bisherige Client-seitige Auswertung mit sich bringt. Zusätzlich verfügen Webschnittstellen (v. a. wenn auf Client-Seite auf dynamische Webinhalte 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) nachgebildet 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 Datenbank 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 verfolgt. 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 schnittstellenkonformen Zugriff verstärkt, was im Moment nur durch Programmierrichtlinien gewährleistet werden kann. Von der Verwendung dynamischer Bibliotheken wird daher auch eine Steigerung der Wartbarkeit und der Erweiterbarkeit erwartet. Modularisierung von GBware, Wiederverwendung bestehenden Programmcodes. 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 Code der verschobenen Business-Logik angepasst werden. Soll bspw. ASP.NET als Lösung für den Application-Server eingesetzt werden, so müssen bisher verwendete Delphi Bibliotheken durch.net-bibliotheken ersetzt werden, da verschiedene 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 Partizipation 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 (andernfalls könnte bspw. durch konkurrierenden Zugriff auf einen Datensatz eine falsche Rechnung o.ä. entstehen). Eine Spezialisierung der Nutzung auf Lese- und Schreibrechte der jeweiligen Nutzer ist daher zweckmäßig, da bspw. für Nutzer, welche nur lesenden Zugriff (Re- 31

33 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 ausgegeben 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 Beispiel 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, , Office-Anbindung, andere Informationssysteme z. B. ITIL Ticket Service, etc.) sollen in bestehende Workflows integriert 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üssen dabei die Aufrufe der bisher verwendeten Routinen angepasst werden, um die Routinen in den neu erzeugten Einzelkomponenten zu erreichen. Zum Anderen 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 GBware 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 Application-Server ist jedoch eine Bindung an Windows-Betriebssysteme vorgegeben. 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 vorgesehen. Da diese Schnittstellen häufig spezifisch für die jeweilige Software beschrieben sind, soll die Pflege der bisher realisierten Schnittstellen fortgesetzt werden und Schnittstellen zu neuen Softwareprodukten entsprechend der Kundenanforderungen hinzugefügt werden. Unabhängigkeit vom Datenbankanbieter. Eine weitere denkbare Anforderung an GBwareD ist die Unabhängigkeit vom Datenbankanbieter. Mit der Unterstützung verschiedener möglicher Datenbanken könnte eine für den Kunden sowohl leistungsgerechte als auch dem jeweiligen Kostenrahmen entsprechende Bereitstellung 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 Optimierungen möglich macht. 32

34 3.2 Erstellung eines Anforderungskatalogs an GBwareD Abbildung 3.3: Konzept der Systemarchitektur der verteilten Business-Software GBwareD. 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 Hard- und Softwarekonfiguration von GBwareD Durch die Anforderungen der Nutzer von GBware und den daraus resultierenden technischen Anforderungen leitet sich eine mögliche Systemarchitektur eines verteilten GBware 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 Application-Server und in der Datenbank. Dies beschreibt die Trennung von Nutzerschnittstelle 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ätzlich 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 Deaktivierung von Java-Skript im Browser) wünschen, muss auch die Präsentationslogik auf den Application-Server verlagert werden. 33

35 3 GBware und GBwareD Die Kommunikation zwischen Clients und Application-Server soll über DCOM (Delphi-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 weiterentwickelten 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 vorhandene 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 gewü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 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 Sichtbarkeiten 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 eingefü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 werden. 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. daraus entfernt werden, je nachdem ob das Modul verwendet wird. Mit dem Einsatz von Dynamic Link Libraries kann somit sowohl die Kapselung des Programmcodes der Module als auch die Bereitstellung eines skalierbaren Softwareprodukts durch spezifische Aktivierung und Deaktivierung verwendeter Module erreicht werden. 34

36 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware Darüber hinaus stehen für Delphi auch verschiedene Plugin-Frameworks (z. B. TMS 1, DPF 2 ) 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 Umsetzen der spezifizierten Schnittstelle zum System hinzugefügt werden kann. Im Rahmen der Modularisierung von GBware wurde als Machbarkeitsstudie das Modul Projektverwaltung manuell umgestellt, um wesentliche Schritte einer Modularisierung zu ermitteln und Möglichkeiten der Unterstützung durch das Transformationssystem zu evaluieren. Dabei wurde deutlich, dass ein endgültiger Abschluss der Modularisierung oft nicht möglich ist, da neue Anforderungen an Module neue Umstrukturierungen 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 Trennung 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 eine Web-Schnittstelle wesentlicher Bestandteil der Architektur ist, sind eher strikte Definitionen, die einen möglichst großen Teil der Logik als Business-Logik klassifizieren, sinnvoll. Chad Z. Hower 3 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 Tabellen 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 Applikationsserver wesentlich kostengünstiger realisiert werden kann als der Zukauf von Datenbank-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 Datenbank-Servern bereitsteht. 1 TMS Plugin Framework, 2 Delphi Plugin Framework, Open Source, aspx 35

37 3 GBware und GBwareD Abbildung 3.4: Beispiel einer TTable mit generierten Adressdaten in einer Nutzerschnittstelle. Als weiteres Problem der Trennung stellte sich die z. T. enge Verknüpfung von Framework-Komponenten der Nutzerschnittstelle mit der Business-Logik dar. Dieses Problem soll anhand einer Tabellenkomponente der Borland Database Engine (BDE) beschrieben 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. DataSource 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 hinaus 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 Komponente TTable kann innerhalb kurzer Zeit eine komplexe Nutzerschnittstelle erzeugt werden, die dem Nutzer ein breites Spektrum der Bearbeitung von Daten gestattet. Allerdings 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 Darstellung in der Nutzerschnittstelle gelöst werden kann. Soll bspw. eine Tabelle mit entsprechender 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 Änderungen 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 Nutzerschnittstelle und Business-Logik, sowie der Transformation der Nutzerschnittstelle werden in den Abschnitten 7.5 und 10.2 vorgestellt. 36

38 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware 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äftsprozesse 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 Schadensmeldungen. Im Modul Auftrag werden Angebote, Aufträge und Rechnungen kaufmännisch bearbeitet. In einem praktischen Anwendungsfall kann das Modul Projekt das Modul Auftrag steuern, wenn z. B. aufgrund einer Schadensmeldung (Modul Projekt ) 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 Sanierungsprojekt (Modul Projekt ) erstellt wird. Eine zentrale Fragestellung bei der Gestaltung von Schnittstellen ist daher, wie die Services 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 Funktionalitä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 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, Dokument, Projekt, Lager), die die Datenbasis des Systems bilden. Jedes Geschäftsobjekt wird im Workflow mit einem Status/Zustand (z. B. angelegt, 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 bezeichnet. Fasst man den Workflow formal als endlichen Automaten auf, so entsprechen die Transitionen den vorhandenen Kanten des Zustandsgraphen. 37

39 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 Nachbedingungen des Zustandswechsels geprüft werden, die im Fehlerfall eine Rücksetzung bereits abgearbeiteter Aktionen auslösen. Darüber hinaus können Nachrichten (intern oder extern) versendet und Folgeprozesse sowie neue Workflows angestoßen werden. Abbildung 3.5 zeigt eine schematische Darstellung eines Workflows, wie er in GBware 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 verknüpft, die bspw. Funktionalitäten in der Datenbank auslösen können (Aktion 1, Aktion 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 (Eingang einer speziellen im System) oder der Nutzer sein. Des Weiteren können Workflows auch zeitgesteuert ausgelöst werden, bzw. auch zeitgesteuert Zustandsübergä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 verschiedene 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 Funktionalitä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 umgesetzt. Um erste Schritte der Extraktion des Workflows zu gehen und damit dessen Unabhängigkeit vom jeweiligen Datenbankanbieter zu erreichen, wurde mit der Transformation von PL/SQL nach Java begonnen. Oracle unterstützt in den neueren Versionen 38

40 3.3 Vorbereitungs- und Anpassungsarbeiten für GBware Abbildung 3.6: Nutzerschnittstelle des exemplarischen GBware mit reduzierter Funktionalitä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 korrektheitserhaltende Transformation, auch wegen der unterschiedlich mächtigen Schittstellen 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 Testszenarien Von der Berndt & Brungs Software GmbH wurde allen Projektbeteiligten ein exemplarisches z. T. schon modularisiertes und in seiner Funktionalität auf das Wesentliche beschränktes Testprojekt zur Verfügung gestellt, um Analysen und realisierte Transformationen 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 unten) 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

41 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-Programmcode mit dem Werkzeug TRANSFORMR (Abschnitt 10.1) durchgeführt und Möglichkeiten 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 Bestellphase (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 Kundenspezifische Konfigurationsmöglichkeiten Basierend auf den Ergebnissen der Extraktion der Workflow-Komponenten (Abschnitt 3.3.3) wurden verschiedene Varianten der Modellierung von zustandsbasierten Prozessen untersucht. Dabei stand die Abbildung des Prozesses in ein relationales Datenbankmodell im Vordergrund, um Anwendungslogik zu realisieren, die in beliebigen Geschäftsprozessen verwendet werden kann. 40

42 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 Datenbank abgeleitet werden können. Dazu werden alle Entitäten (dargestellt als Rechtecke) und alle Relationen zwischen den Entitäten (dargestellt durch Rhomben) in Tabellen 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 Transition, so kann ein Status beliebig viele (auch keine) Übergänge zu Folgezuständen besitzen. 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äftsobjekten 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 Software GmbH realisierten Workflow-Engine. Bei der Durchführung eines Prozesses wird zunächst der jeweils aktuelle Zustand des Prozesses mit seinen verbundenen Geschäftsobjekten 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 Datenbankfunktion 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 Sicherung des Prozessablaufs wesentlicher Bestandteil sein. Datenkonsistenz geht einher mit einer zeitweisen Sperre von Datensätzen, um bei sequentiellen Änderungen Inkonsistenzen an Datenobjekten zu vermeiden. Eine solche ununterbrechbare Folge von Änderungen wird häufig als Transaktion modelliert und durch unterschiedliche Software (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ücksetzbarkeit des Prozesses zu gewährleisten. 41

43 42 3 GBware und GBwareD

44 4 Entwurf des Transformationssystems Business-Software setzt Geschäftsprozesse um, die oft über Jahre gesammeltes Expertenwissen enthalten. Durch neue Anforderungen an Hard- und Softwareumgebungen, an interne Abläufe oder externe Vorgaben, müssen realisierte Geschäftsprozesse kontinuierlich angepasst und erweitert werden. Die Änderungen der Geschäftsprozesse betreffen sowohl Aspekte der Software wie Sicherheit, Leistungsfähigkeit, Usability und Wartbarkeit als auch die Interaktion mit anderen Systemen. Unternehmen müssen folglich die Risiken einer Restrukturierung bzw. Modernisierung sowie den möglichst fehlerfreien 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 Skalierbarkeit hinsichtlich der zu verarbeitenden Datenmenge, da die ursprünglich entworfene Software verteilte Aspekte nicht berücksichtigte. Die Anpassung der Software zur verteilten Ausführung kann Restrukturierungen großer Teile des Business-Softwaresystems mit sich bringen und viele Teile des Unternehmens und seiner Geschäftsprozesse betreffen. 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 einzubetten. Im Rahmen des Projekts wurde Business-Software betrachtet, die in den Programmiersprachen Delphi oder Java implementiert ist. Der Aufbau dieser Art von Software orientiert sich häufig am Rapid-Application-Development-Ansatz (RAD). Mit dem RAD-Ansatz können dem Kunden durch die grafische Unterstützung der Entwicklungsumgebung 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 betrachtet werden und nur schwer in den Prototypen integriert werden können. Weiterhin sind Nutzerschnittstelle und Business-Logik oft stark verwoben (GUI-Primitive können direkt Änderungen der Datenbank vornehmen), so dass eine Modularisierung, und 43

45 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 Reorganisation 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, Koordination) mit der Möglichkeit einer effizienten Realisierung; Skalierbarkeit mit dynamischer Erweiterung und Anpassung an kundenspezifische Anforderungen; Flexible verteilte Abarbeitungsmöglichkeit auf modernen, heterogenen Plattformen. Das entwickelte Transformationssystem unterstützt einen mehrstufigen Transformationsprozess, der die genannten Eigenschaften integriert. Dies erlaubt eine Separation der verschiedenen zu transformierenden Eigenschaften, was zu einer Reduktion der Komplexität des Transformationsprozesses führt. Für das Transformationssystem ergeben sich basierend auf den Anforderungen an die Transformationen folgende Grundprinzipien: 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 Komponentenverteilung; Spezifikationskonzept zur Beschreibung von konkreten Transformationsszenarien; Nutzung von Methoden des Compilerbaus zur Durchführung der spezifizierten Transformationsanforderungen. 44

46 4.2 Basistechnologien und verwandte Ansätze Die Anforderungen an zu transformierende Legacy-Software setzen eine andere Vorgehensweise 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 verschiedener Technologien aus den Gebieten Software-Engineering, verteilte Systeme, Compilerbau 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 vorhandenen 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 Verteilungsplattformen Die Entwicklung komponentenbasierter und verteilter Softwaresysteme wird als Component-based Software Engineering (CBSE) [17] bezeichnet. Ansätze des CBSE basieren auf unterschiedlichen Basistechnologien. Ein Beispiel ist die Common Object Request Broker Architecture (CORBA) beschrieben durch die Object Management Group (OMG 1 ). Der Ansatz stellt für die verteilte und unabhängige Entwicklung von Komponenten die Interface Definition Language (IDL) bereit, die die programmiersprachenunabhängige Spezifikation von Schnittstellen und austauschbaren Datenstrukturen ermöglicht. 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 Kommunikation von Enterprise Java Beans (EJB), eine Komponentenspezifikation von Sun, die eine verteilte Ausführung von Komponenten in Java ermöglicht. Das CORBA Component 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-Technologie COM, die unter dem Betriebssystem Windows eine Interprozesskommunikation und eine dynamische Objekterzeugung unabhängig von der verwendeten Programmiersprache ermöglicht. Die genannten Middleware-Plattformen werden in Abschnitt 7.4 detailliert beschrieben. 1 Konsortium unterschiedlicher Unternehmen der Computerbranche mit dem Ziel Standards zu etablieren 45

47 4 Entwurf des Transformationssystems Die beschriebenen Basistechnologien stellen zwar ein allgemeines Framework für verteilte Komponenten bereit, bieten jedoch keine Unterstützung für spezifische Anwendungsgebiete. CBSE greift dieses Problem auf und spezifiziert Ansätze zur inkrementellen 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 Programmierung (AOP) Transformationsframeworks und -ansätze Die Transformation von Legacy-Software wurde durch verschiedene Forschergruppen betrachtet. Viele Ansätze konzentrieren sich auf die Transformation von Legacy-Software in modulare objektorientierte Systeme [7] oder auf die Extraktion von Business- Logik [16]. Neuere Ansätze berücksichtigen Aspekte der Verteiltheit, indem sie beispielsweise eine Middleware für die Datenintegration bieten [42]. Für verteilte Systeme spielt die Leistungsfähigkeit eine wesentliche Rolle, da zusätzliche Latenz- und Übertragungszeiten 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 Finden von Code Clones, die Transformation von C/C++ Präprozessordirektiven oder die Transformation der Programmiersprache JOVIAL (Jules Own Version of the International Algorithmic Language; eine Variante von Algol 58) nach C ermöglicht [7]. Für diese 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 Transformation von Software. Ein wichtiger Grund ist das Vorhandensein verschiedener verteilter Softwareplattformen wie CORBA oder EJB, die nicht in beliebiger Weise miteinander verknüpft werden können. Ein weiterer Grund ist die Vielschichtigkeit der Probleme der Transformation von Business-Software, die eine allgemeine Formulierung erschwert. Viele modulare und verteilte Lösungen bedingen deshalb häufig eine Neuentwicklung der Business-Logik. Der Model Driven Architecture (MDA 2 ) Ansatz geht auf das Problem der Heterogenität der Plattformen ein und nutzt ein modellgetriebenes Konzept zur schrittweisen Erzeugung komponentenbasierter und verteilter Software aus einer gegebenen Anforderungsbeschreibung [49]. Die schrittweise Generierung beginnt mit einer UML-Spezifikation der statischen Schnittstellen und des dynamischen Verhaltens der Komponenten in einem plattformunabhängigen Modell (Platform Independent Model, PIM). Eine Reihe

48 4.3 Konzeption des Transformationsprozesses von Modelltransformationen wie CORBA profiles oder Enterprise Application Integration (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 eine gewählte Plattform. Wesentlich für eine Anwendung der MDA-Ansätze auf Legacy-Software ist die zu einem großen Teil automatische Erzeugung des PSM bzw. des PIM aus bestehendem Programmcode, Dokumentation und weiteren verfügbaren Daten. Besonders die Menge und Heterogenität vorhandener Daten erschweren dabei die Erzeugung des Softwaremodells Workflowbeschreibungen Ein wichtiger Bestandteil verteilter Business-Software ist die Transparenz der verteilten 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 Entwickler nicht verborgen ist, führt die Transparenz vor allem zur Vermeidung kostenintensiver 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-Software. Die Workflow Management Coalition (WFMC 3 ) beschreibt Standards für Workflow- Architekturen, die auch Aspekte verteilter Ausführung umfassen. Eine direkte Integration 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 Zwischendarstellung, die den gesamten Transformationsprozess unterstützt und unabhängig von einer konkreten Programmiersprache die Legacy-Software mit ihren Abhängigkeiten und logischen Strukturen abbildet. Diese Hilfsstruktur setzt sich aus mehreren Ebenen zusammen und beinhaltet sowohl den statischen Aufbau der Software als auch Metainformationen ü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 modularen, flexiblen verteilten Software aus einer gegebenen monolithischen Software wird im Folgenden als Flexible Software Representation (FSR) bezeichnet. Durch sukzessive

49 4 Entwurf des Transformationssystems Flexible Software Representation FSR Software Subsystem Explicit Workflow Distributed Software Software Subsystem mit adaptivem Workflow Software Subsystem als Distributed System Distributed Software gesteuert durch expliziten Workflow FSP Flexible Software Package Abbildung 4.1: Übergangsdiagramm der Flexible Software Representation (FSR) in verschiedene Softwaresichten. Transformationen wird die Legacy-Software zunächst in ein modulares Softwaresystem 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 unterschiedlichen Sichten auf die Software 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 Software dar. Die SSu erlaubt die Auswahl von Modulen, die separierbare Funktionalitäten abbilden. Intention dieser Sicht ist die Extraktion einzelner Funktionalitäten aus der Gesamtsoftware. Explicit Workflow mode (ExW) beschreibt die Geschäftsprozesse (Business-Logik) der Software durch explizite Workflows in einer XML-basierten Beschreibungssprache. Diese Sicht ist die Basis für Änderungen des Workflows zur Anpassung an die gewählte Zielplattform. Distributed Software mode (DS) spezifiziert eine explizite Struktur kooperierender 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

50 4.3 Konzeption des Transformationsprozesses Modellebene Tabelle 4.1: Abstraktionsschichten der Softwaresichten der FSR. Software Subsystem SSu Flexible Software Representation FSR Explicit Workflow ExW Distributed Software DS Koordinationsprogram Workflowbeschreibung Komponenteninteraktion Tiefere Ebene Module/Funktionen Module Komponenten statische Komponenten Programmierumgebung Workflow-Engine verteiltes 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 erweiterten Eigenschaften abgeleitet werden. Beispielsweise bietet die Kombination aus SSu und ExW die Möglichkeit der Definition eines Softwarepakets, das konfigurierbare Workflows enthält. Eine Kombination aus SSu und DS beschreibt dagegen, wie einzelne Module 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 diejenigen 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 Kombination erfolgt auf abstrakter Ebene. Die Zwischendarstellung selbst besteht aus einer (abstrakten) Modellebene und einer oder mehreren darunter liegenden Ebenen. Die Modellebene beschreibt die Interaktion der Komponenten und bietet eine abstrakte Sicht auf das Softwaresystem. In niedrigeren Ebenen befinden sich die Teile der Software, die eine 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 zusammen 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 Tabelle 4.1 zusammen mit benötigten statischen Komponenten für die jeweiligen Sichten der FSR dargestellt. 49

51 4 Entwurf des Transformationssystems Specification Level Intermediate Representation Execution Mode Executable Software Executable Software Executable Software Coordination Program SSu Logical Structure transform Modular Structure create Workflow Description Coordination Structure filter Business Software System FSR ExW Set of Modules Code Fragments transform Modules create Components/ Services Components select include include inc. DS Programming Environment Workflow Engine Distributed Runtime System Abbildung 4.2: Transformationsentscheidungen und Transformationsprozess Grobstruktur des Transformationsprozesses Der gesamte Transformationsprozess besteht aus einer Menge einzelner interaktiver Transformationsentscheidungen. Abbildung 4.2 zeigt die Grobstruktur des Transformationsprozesses und beschreibt Pfade von der Legacy-Software zu möglichen Zielstrukturen in Abhängigkeit von den Entscheidungen in den verschiedenen Transformationsstufen. Jeder Pfad in Transformationsrichtung, vom Business Software System zu einer Executable Software, entspricht einem Transformationsprozess durch den ein Softwaresystem einer bestimmten Softwaresicht entsteht. Die Softwaresysteme können mit Hilfe verschiedener Techniken wie CORBA oder EJB umgesetzt werden. Der Transformationsprozess 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 (Intermediate Representation, FSR) überführen. Die Herstellung einer geeigneten Modulstruktur wird durch Komponentenbildungstransformationen realisiert. Aus der FSR, die die Modulstruktur und Module der Legacy-Software enthält, können nun die verschiedenen Sichten (Execution Mode) erzeugt werden, beispielsweise ein Koordinationsprogramm (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 Zusammenstellungen, die durch zusätzliche statische Komponenten als ausführbare Software (Executable Software) realisiert werden können. Die Auswahl benötigter Module und ihrer Kooperations- und Koordinationsstrukturen werden durch Filtertransformationen realisiert. 50

52 4.4 Entwurf einer Software-Architektur des Transformationssystems Transformation System User Interface FSR Views Transformation UI Flexible Software Representation FSR Transformation System Application/View Logic Transformation Modules FSR Creation FSR Transformation FSR Generation Programmcode Access External Plugins Delphi Java 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 modulare komponentenorientierte Architektur besitzt eine Nutzerschnittstelle zur interaktiven Transformation und Analyse der Zwischendarstellung, die den Zugriff auf das Transformationssystem mit unterschiedlichen Sichten auf die FSR und deren Transformationsprozess 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 Modellschicht werden in darunter liegenden Ebenen Module und deren Codestrukturen referenziert. Durch Transformation der FSR werden die Metadaten (Koordinationsprogramm, Workflow-Beschreibung, etc.) über die enthaltenen Softwareelemente z. B. zur Visualisierung für eine ausgewählte Sicht (FSR Views) hinzugefügt. 51

53 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 Darstellung durch eine Sprachtransformation mit Hilfe von Compilerwerkzeugen gewonnen. Der Zugriff auf den konkreten Code wird über das Modul Programcode Access gekapselt, um die Erweiterung auf neue Programmiersprachen möglichst einfach zu gestalten. Transformationen der FSR werden im Modul FSR Transformation durchgeführt. Die Grobtransformationsschritte Komponentenerzeugungs- und Filter-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 (JavaEE 4 ) eingebettet werden oder erzeugte explizite Workflow-Beschreibungen in eine Workflow- Beschreibungssprache (z. B. XPDL 5 ) übersetzt werden. Programcode Access bietet für alle Transformation Modules die Möglichkeit des Zugriffs und der Verarbeitung von Programmcode der Legacy-Software. Zusätzlich können über dieses Modul externe Werkzeuge wie beispielsweise Parsergeneratoren oder Sprachtransformationstools angebunden werden. Im Modul wird versucht, den Zugriff auf den Programmcode zu abstrahieren, so dass die Transformation 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 Abstraktion 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 Standardisierte Sprache für Workflows der Workflow Management Coalition (WfMC) 52

54 4.4 Entwurf einer Software-Architektur des Transformationssystems External Plugins bietet Schnittstellen zu externen Werkzeugen deren Funktionalität im Transformationssystem verwendet wird (z. B. Compilerwerkzeuge oder Visualisierungssoftware). Das Modul steuert den Ablauf der Verwendung und bietet eine zentrale Fehlerbehandlung für die verwendeten externen Tools, um deren Verwendung im Transformationssystem unabhängig von tatsächlichen Implementierungen zu gestalten. Beispielsweise können durch diese Herangehensweise Veränderungen der Schnittstelle zum externen Tool zentral im Modul External Plugins behandelt werden. Die Kapselung der einzelnen Module der Architektur spielt für die Weiterentwicklung des Transformationssystems auch in Hinblick auf eine Erweiterbarkeit in eine Komponenten- oder Plugin-Architektur eine wichtige Rolle. Vorteil des modularen Aufbaus 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 werden, das Entwickler bei der Implementierung von Software unterstützt und eine abstrakte Sicht auf die bestehende Gesamtarchitektur bietet. 53

55 54 4 Entwurf des Transformationssystems

56 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Gegenstand der Auswahl einer Infrastruktur zur Realisierung des Transformationssystems war die Erfassung existierender Sprach- und Transformationsansätze und eine Bewertung hinsichtlich einer Eignung für das Projekt. Dazu wurden zunächst Ansätze und Tools der modellgetriebenen Softwareentwicklung untersucht und Konzepte für den Transformationsprozess adaptiert. Zur geeigneten Modellierung der Zwischendarstellung für eine abstrakte Sicht auf Legacy-Software wurden verschiedene abstrakte Softwaremodelle evaluiert und wichtige Bausteine in die Realisierung der FSR übernommen. Darüber hinaus wurden unterschiedliche Werkzeuge untersucht, die als Metakomponenten für verschiedene Teilaufgaben des Transformationsprozesses herangezogen 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 modellgetriebenen 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 Programmcode. 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 Vorgehensweise, bei der das Ausgangsmodell nicht aus Anforderungen an eine Neuentwicklung, sondern aus bestehenden Programmstrukturen und Anforderungen an eine Anpassung der Business-Software erzeugt wird. Aus diesem Grund wurden die Konzepte und bestehende Werkzeuge der MDA bezüglich ihrer Eignung für das Transformationssystem evaluiert. 55

57 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Abbildung 5.1: Beispiel einer Modelltransformation nach dem MDA-Ansatz vom plattformunabhängigen Modell (PIM) über das plattformabhängige Modell (PSM) zum Programmcode (Code) MDA Entwicklungsprozess Der inkrementelle Prozess der modellgetriebenen Entwicklung besteht aus drei Teilschritten. 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, ohne 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 Abbildung 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 generiert 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 Independent Model (CIM) verwendet, das eine umgangssprachliche Beschreibung der Software (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 Einsatz. Für alle Modelle des MDA-Ansatzes wird eine Modellierung durch UML mit do- 56

58 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 Entwicklungsprozess, wenn im Laufe der Entwicklung Modelländerungen einer Stufe Änderungen des übergeordneten Modells nach sich ziehen. Diese Änderungen werden zur Zeit häufig per Hand in das bestehende Modell eingebracht, was dem Ansatz der automatischen Modelltransformation widerspricht. Werden beispielsweise Änderungen des generierten 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 MDA Werkzeuge Im Rahmen des Arbeitspakets wurden fünf verschiedene MDA Werkzeuge auf ihre Eignung 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 Bereiche, die nicht verändert werden dürfen), was eine Anwendung auf Legacy-Software erschwert. Die untersuchten freien MDA-Tools OpenArchitectureWare 1 und AndroM- DA 2 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 Transformation der Modelle und eine anschließende Propagierung auf den Programmcode verhindert. Nach eingehender Untersuchung ist die Anwendbarkeit existierender MDA Werkzeuge nur mit außerordentlichem Aufwand, der einer Neuentwicklung gleich kommt, zu ermöglichen. Demgegenüber sind jedoch die MDA Konzepte der Abstraktion von Software auf verschiedene Modellebenen und die zugehörigen Modelltransformationen sehr gut auf die Analyse und Transformation von Legacy-Software anwendbar. Die Modellebenen bieten die Möglichkeit zur Realisierung der Transformation in verschiedenen Schichten, die eine Reduzierung der Komplexität und eine Differenzierung der Zuständigkeiten in einzelne Module des Transformationssystems ermöglicht. Basierend auf diesen Rahmenbedingungen wurde eine Eigenimplementierung mit Einbeziehung externer Werkzeuge zur Realisierung des Transformationssystems favorisiert. Dazu wurden

59 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Tabelle 5.1: Auswahl frei verfügbarer und proprietärer MDA Werkzeuge (Stand: September 2006). IBM Rational Software Architect Compuware OptimalJ Interactive Objects ArcStyler Open Architecture Ware AndroMDA Typ Suite Suite Suite Framework Framework IDE Eclipse Eclipse, JBuilder, VisualStudio keine Eclipse Eclipse UML- Support , 2.0 teilweise je nach UML Tool 2.0 je nach UML Tool PIM/PSM Transformationen Verknüpfung von PSM mit PIM Mittels Modulen Mittels Marksets Ja, ab Version 4 Nein Methoden Forward, Reverse, Roundtrip Forward, Reverse, Roundtrip Forward, Reverse Forward Forward Zielsprachen C++, Java Java, XML, SQL Java,.NET, C++, Cobol, CORBA Beliebig durch Anpassung Java, SQL, anpassbar Zielarchitekturen J2EE J2EE,.NET, CORBA J2EE,.NET, CORBA Beliebig durch Anpassung J2EE (Spring, Hibernate, Struts), anpassbar Testen Component Tests Unit Tests (JUnit) Unit Tests (JUnit) Nein Nein verschiedene existierende Modelle zur detaillierten Beschreibung von Software untersucht, die im Folgenden vorgestellt werden. 5.2 Modellspezifikationen für Software und Transformationen Basisbaustein des Transformationssystems ist das Modul Flexible Software Representation zur Abbildung der Legacy-Software in einer mehrschichtigen Zwischendarstellung. Für die Repräsentation der Modellebene wurden verschiedene vorhandene Softwaremodelle und vorhandene Tools der Modelle evaluiert. 58

60 5.2 Modellspezifikationen für Software und Transformationen 0..1 defines ModelObject {abstract} name 0..1 declares * SourceObject {abstract} ModelElement {abstract} visibility ModelRelationship {abstract} issubpackageof invokes * accesses * * * * Package StructuralElement {abstract} BehaviouralElement {abstract} 0..1 * imports * isoftype 0..1 Type 0..1 Value hasvalue ExecutableValue Method * isdefinedintermsof 0..1 isconstructor 0..1 isdestructor Variable isabstract isparameterof EnumeratedType isdynamicallybound isoverideable 1..* * * CollectionType isenumerationliteralof Routine EnumerationLiteral FormalParameter size position * StructuredType isfieldof Field 0..1 * Class issubclassable * * inheritsfrom ismethodof 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 addition to the usual italic Abbildung 5.2: Links: Program Representation Graph (PRG) [16]. Rechts: Strukturmodell des Dagstuhl Middle Model (DMM) [38]. Tools (JDT) [8]. As for the metamodel, an Eclipse Modeling Framework (EMF [7]) based metamodel for Java called Java EMF Model (JEM) is part of the Eclipse s Visual Editor project, but is 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: Der Program Representation Graph (PRG) [16] (Abbildung 5.2, links) stellt ein allgemeines Modell für objektorientierte Sprachen zur Verfügung. Im Modell werden die UML-typischen Elemente wie Klassen, Methoden, Variablen und ihre Beziehungen, aber auch feingranulare Elemente wie Sequenzen von Programmcode (CodeFragment) oder abstrakte Statements (StructuralElement) abgebildet. Das Basiselement des Graphen 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. 1. An extension to the type graph (PRG) by adding an attribute to the abstract class CodeFragment that uniquely identifies the equivalent element in the source code reference model 2. The use of an association model that defines the mapping between elements of the PRG and corresponding elements of the source code reference model The first alternative is a straight-forward solution that has a tight relation between both models. This is a drawback because with this option the PRG will depend on the chosen source code reference model. Its main advantage is the simplicity of implementation where no extra models are Lethbridge et al. beschreiben das Dagstuhl Middle Model (DMM) in [38], das ein umfangreiches Modell zur Abbildung objektorientierter und prozeduraler Programmiersprachen darstellt. Es separiert die Darstellung statischer Strukturen (Klassen, Methoden; siehe Abbildung 5.2 rechts) (StructuralElements) von der Beschreibung der Beziehungen zwischen den statischen Elementen (BehaviouralElements) und bietet darüber hinaus ein Teilmodell zur Abbildung von Programmcode (SourceObjects). Das Basiselement des Graphen bildet ein package, das wiederum packages oder Klassen/Module enthalten 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 Modellspezifikation 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

61 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Für die Spezifikation der Flexible Software Representation werden daher die Konzepte 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 Programmiersprachen; Referenzierung des Programmcodes in den Modellelementen zur Propagierung der Modelltransformationen zum Programmcode; Einfache Erweiterbarkeit des Modells zur Adaption für neue Programmiersprachen; Mechanismen zur Konsistenzsicherung zwischen referenziertem Programmcode und Modell. Zusätzlich zur Modellierung der Legacy Software muss in der FSR eine Komponente zur Verwaltung der Transformationen realisiert werden. Die Komponente ist für die Anwendung der Transformationsoperationen auf die FSR und die Möglichkeit zur Wiederherstellung des ursprünglichen Zustands zuständig. Die Realisierung der Transformationsoperationen selbst ist nicht Bestandteil der Komponente. Die untersuchten Softwaremodelle enthalten keine zusätzlichen Konzepte zur Spezifikationen 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 Transformationsprototypen wird daher ebenfalls eine selbst definierte Spezifikation der Transformationen auf XML-Basis gewählt. Abbildung 5.3 veranschaulicht den schematischen Aufbau der Flexible Software Representation. 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 Vererbung, 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 Transformation 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 Transformationsoperationen in einer Baumstruktur modelliert. Über den Wurzelknoten (Root) werden 60

62 5.2 Modellspezifikationen für Software und Transformationen Code Model Flexible Software Representation Software Model Transformation Module 1 * SubSystem * 1 * 1 1 * Module 1 1 * Variable Module Dependency * 1 * Procedure 1 * Program * 1 LocalModule Block Statement * 1 LocalVariable * 1 1 * * 1 CodeBlock Dependency 1 * 1 Procedure Dependency Statement Simple Statement Variable Dependency * Transformation Manager Consistence Manager Transformation Model Operation 1 Root... Operation n,1 Operation n... Operation n,m Abbildung 5.3: Entwurf der Flexible Software Representation (FSR) bestehend aus statischem Softwaremodell mit Beziehungsmodell und Transformationskomponente. die vom Nutzer initiierten Transformationen in ihrer Reihenfolge als Kindknoten angeordnet (Operation 1 bis Operation n ). Eine Transformation selbst kann weitere Transformationen bedingen, die als Kindknoten der Transformation dargestellt werden (Bedingte Transformationen von Operation n sind die Transformationen Operation n,1 bis Operation n,m ). Die Ausführung aller Transformationen im Transformation Model wird vom Transformation Manager gesteuert und entspricht einer Postorder-Traversierung des Baums des Transformation Models, wobei die Wurzel (Root) eine Referenz zur Liste der Transformationen (Operation 1 bis Operation n ) darstellt. Der Manager stellt zusätzlich Methoden zum Rücksetzen durchgeführter Transformationen bereit. Die Realisierung der Transformationsoperationen 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 Transformationsoperationen kann nur über spezifizierte Vor- und Nachbedingungen in den Operationen 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) getroffen werden, was jedoch die detaillierten (semantischen) Eigenschaften nach einer Transformation des Modells oder des Codes nicht berücksichtigt. 61

63 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Zur Sicherung der Persistenz kann die Flexible Software Representation als XML-Dokument dargestellt und gesichert werden. Die Erzeugung und Transformation der FSR aus Legacy-Software sowie die Visualisierung der FSR können durch existierende Techniken und Werkzeuge unterstützt werden, die im nächsten Abschnitt beschrieben werden. 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 Eingabesprachen zu unterstützen, muss das Werkzeug zudem eine separate Spezifikation der Grammatik der Eingabe ermöglichen. Für die genannten Anforderungen existiert eine große Bandbreite verschiedener Systeme Compilerwerkzeuge Zur Realisierung der notwendigen Transformationen des inkrementellen Transformationsprozesses wurden verschiedene Compilerwerkzeuge im Hinblick auf ihre Eignung zur Transformation von Programmcode evaluiert. Dabei stellte sich TXL 4 als am besten geeignetes Tool heraus, da der Einarbeitungsaufwand in die Sprache gegenüber umfangreichen und komplexen Werkzeugen, wie ANTLR 5, 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 allgemeine Funktionsweise von TXL. Ein TXL-Programm besteht aus einer Grammatik (Grammatical 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 umgewandelt. Anschließend wird der Baum in der Transform-Phase entsprechend der Transformationsregeln verändert. Im dritten Schritt, der Unparse-Phase, wird aus dem erzeugten und modifizierten Syntaxbaum der Ausgabetext (Transformed Source Artifact) generiert. Zur Transformation können bestehende Grammatiken für verschiedene Programmiersprachen 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

64 zescalarassignments repeat statement] ariable] := E1 [expression]; ariable] := E2 [expression]; fscope [repeat statement] eferences V1] eferences V2] 5.3 Toolunterstützung der Verarbeitung der Transformation Grammatical Structure Specification TXL Program Structural Transformation Rules V2 > := < E1,E2 > ; fscope Original Source Artifact TXL Processor Transformed Source Artifact xample TXL Transformation Rule. se gives the pattern for which the rule ple in actual source text, binding names to e [expression]s) which may vary in each lause gives the transformed result in similar nd names to transfer parts from the matched here clauses specify additional semantic n the rule can be applied. ocessor essor is a compiler and run time system for ming language that directly interprets TXL g of a grammatical specification of the input text and a rooted set of structural les to implement a source to source he result is a rapid prototype of the source ed by the rules that can be used immediately e 2). % goal symbol n] % of the grammar ion % general % recursion n] + [term] % & ambiguity n] [term] % supported primary] primary] ion] ) Example of a TXL Grammar. such as +, -, *, / and the parentheses in the represent themselves. References to are denoted by square brackets, as in. TXL comments begin with % and continue e. Abbildung 5.4: Allgemeine Funktionsweise von TXL nach [15]. Figure 2. The TXL Processor. The TXL Processor automatically implements source transformations written in the TXL language. Seit 2002 ist TXL als FreeTXL frei verfügbar und wird sowohl an Universitäten als auch 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.2. Grammatical Notation - Specifying Source Structure TXL uses a BNF-like grammatical notation to specify source structure (Figure 3). In order to keep the notation lightweight and in a by-example style, terminal symbols of the input, for example operators, semicolons, keywords and the like, appear simply as themselves. Quoting of terminal symbols is allowed but not required except in cases where terminal symbols of the target language are keywords or special symbols of TXL itself. References to nonterminal types defined elsewhere in the grammar appear in square brackets [ ]. The usual set of BNF TXL-Grammatikdefinition Eine Grammatikdefinition ist für den Eingabetext (bzw. den Eingabeprogrammcode) notwendig und wird in einem EBNF-ähnlichen (erweiterte Backus-Naur-Form) Stil notiert. Einzelne Definitionen werden mit einer define- Anweisung vorgenommen. Alternative Möglichkeiten werden durch getrennt und können Terminal- und (zu spezifizierende) Nichtterminalsymbole enthalten. Nichtterminalsymbole werden dabei in eckigen Klammern verwendet. Das ausgezeichnete Nichtterminal [program] wird als Startsymbol verwendet. Neben diesem sind noch weitere Nichtterminalsymbole vordefiniert: comments /* */ // end comments [id] für Bezeichner (Folge von Buchstaben, Ziffern oder _, beginnend mit Buchstabe oder _); [number] für compounds Ganz- oder Fließkommazahlen; [stringlit] := für Zeichenketten, <= >= -> <-> die zwischen doppelten Anführungsstrichen end compounds " stehen; tokens [charlit] fürhexnumber Zeichenketten, "0[Xx][\dABCDEFabcdef]+" die zwischen einfachen Anführungsstrichen end tokens stehen; [comment] für Kommentare. keys program procedure function repeat until for while do begin 'end end keys Häufigkeiten und Aufzählungen werden u. a. mit den Modifikatoren opt, repeat und list (durch Komma Figure 4. getrennt) Specifying Lexical angegeben. Forms in Eine TXL. Unterscheidung, ob z. B. bei der repeat-anweisung mindestens ein Vorkommen notwendig ist oder nicht, ist durch ein angehängtes + möglich: [repeat nonterminal+] definiert z. B. eine nicht-leere Folge von nonterminal-ausdrücken. Da die Modifikatoren auch in eckigen Klammern genutzt werden, ist dort die Angabe von Terminalsymbolen durch ein führendes Apostroph möglich. Lexical forms specify how the input text is to be partitioned into the terminal symbols (tokens) of the source language. The comments section specifies commenting conventions of the input language, the compounds and tokens sections how sequences of characters are to be grouped into terminal symbols, and the keys section specifies which symbols are to be 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 Zeichenkette wird als Trennzeichen eines bis zum Zeilenende gehenden Kommentars verstanden. 63

65 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems Die Angabe von zwei Zeichenketten wird als Anfangs- und Enddefinition eines (mehrzeiligen) 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 folgende Ausschnitt aus einer vereinfachten TXL-Grammatikdefinition der Programmiersprache 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 package [qualified_name] ; end define % Definition eines Namensraums; beginnt in Java mit dem % Schlüsselwort package, gefolgt von einem qualifizierten Namen % 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 [class_decl] [interface_decl] [enum_decl] end define define class_decl [repeat modifier] class [class_name] [opt extends_clause] [opt implements_clause] [class_body] end define % Definition eines Nichtterminals für Typ-Deklarationen % Definition eines Nichtterminals zur Deklaration einer Klasse % Modifier: z. B. public, abstract % Schlüsselwort class und Name der Klasse % optionale Superklasse % optionale Interfaces, die durch die Klasse implementiert werden % Körper der Klasse (z. B. Methoden, Membervariablen, etc.) 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 Nichtterminalsymbolen, die aus dem Nichtterminalsymbol mittels der Grammatik erzeugt werden kann. function name replace [type] pattern by replacement [nextfunction] end function Die Funktion name wird auf das erste Vorkommen des Nichtterminals type angewendet, das der Ableitung pattern entspricht. Bei der Anwendung wird die Ableitung 64

66 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 besitzen können. Wird statt des Schlüsselworts function das Schlüsselwort rule verwendet, 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] import Name [qualified_name] ; by import Name [replaceimportname] ; end rule % Ersetzung aller Import Deklarationen beginnend mit % Schlüsselwort import ohne folgendes static % gefolgt von einem beliebigen qualifiziertem Namen % Ersetzung durch Anwendung der Funktion % replaceimportname auf den qualifizierten Import-Namen 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 Extraktion der FSR aus Programmcode (Abschnitt 6.2) und die Auslagerung von Funktionalitä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 Konstrukte aus Quell- und Zielsprache nebeneinander existieren. Dabei wird folgendes Vorgehen empfohlen: 1. Erstellen der Grammatiken für die Quell- und die Zielsprache, so dass kein Nichtterminal mehrfach existiert; 2. Festlegen einer Menge von Nichtterminalen, die als Transformationssymbole genutzt werden sollen, und Erzeugen einer gemeinsamen Transformationsgrammatik 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

67 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems an Nichtterminalen zu identifizieren, mit der alle notwendigen Transformationen vorgenommen 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... [expression] end redefine define program [C_program] [J_program] end define % Analoge Vorgehensweise für Ausdrücke in Java % Deklaration eines neuen Startsymbols für % die Transformationsgrammatik Für das Transformationswerkzeug TRANSFORMR bietet TXL eine hervorragende Grundlage zur Realisierung der notwendigen Transformationen zur Erzeugung des Softwaremodells (Model-to-Code), zur Veränderung des Modells (Model-to-Model) mit zugehörigem Programmcode und zur Generierung des Programmcodes für das Zielsystem (Model-to-Code). Die konkrete Anwendung von TXL wird in Kapitel 6 beschrieben Visualisierungswerkzeuge Die grafische Darstellung der Struktur der zu verarbeitenden Software, von Bestandteilen 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 diese Visualisierungsentwicklung unterstützt. Hauptaspekt ist die Darstellung von Graphen bspw. zur UML-Darstellung der Klassenstruktur, die sehr groß werden kann. Eine Darstellung, die es vermeidet, dass sich Kanten gehäuft kreuzen, ist hier sehr wünschenswert. Es wurden folgende freie Werkzeuge zur Visualisierung beliebiger Graph-Strukturen evaluiert: JGraph 6 [3] ist eine umfangreiche, interaktive, quelloffene Java-Swing-Komponente. Die Software ist gut dokumentiert und einfach an eigene Anforderungen anzupassen. Allerdings sind keine Algorithmen zur Positionierung der Knoten von Graphen frei verfügbar

68 5.3 Toolunterstützung der Verarbeitung der Transformation GraphViz 7 [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öglichkeiten der Darstellung von Kanten und Knoten. Eine interaktive Java-Implementierung 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 Interface 8 (JNI) genutzt werden kann. Mit dem Graphical Editing Framework 9 (GEF) und dessen Plugin Draw2D [36] existiert eine weitere Java-basierte Lösung zur grafischen Visualisierung diverser Graphstrukturen, die zusätzlich Schnittstellen für eine interaktive Anpassung bietet. GEF ist jedoch in die Eclipse-Umgebung integriert und hat u. a. Abhängigkeiten 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 wurde 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 einfache Integration ermöglichen

69 68 5 Auswahl einer Infrastruktur zur Realisierung des Transformationssystems

70 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 Transformation 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 jeweiligen Architekturplattform und die damit verbundene Portabilität ist ein Alleinstellungsmerkmal 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 Werkzeuge 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 Transformationswerkzeug 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 Betriebssysteme unabhängig realisiert werden. Ein weiteres wesentliches Merkmal des realisierten Transformationssystems stellt Erweiterbarkeit 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

71 6 Entwicklung und Realisierung des Transformationssystems für Java verschiedene Spezifikationen und Frameworks zur Verfügung. Die OSGi Alliance 1, ein weltweites Konsortium unterschiedlicher IKT-Unternehmen (Informationsund Kommunikationstechnologie), spezifiziert eine umfangreiche hardwareunabhängige dynamische Softwareplattform, die es erleichtert einzelne Module über ein Komponentenmodell zur Laufzeit zu verwalten. Die OSGi stellt dabei jedoch nur eine Referenzimplementierung zur Verfügung, die je nach Anwendungsfall angepasst werden muss. Die Entwicklungsumgebung Eclipse 2 basiert beispielsweise auf einem OSGi-Framework 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 Framework 3 (JPF). Dieses beinhaltet verschiedene 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 Komponentenarchitektur 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-Architektur erlauben. 6.1 Realisierung des Transformationssystems TRANSFORMR Inkrementeller Transformationsprozess Die Realisierung eines Systems zur Transformation monolithischer Business-Software in eine modulare, skalierbare Client-Server-Architektur setzt individuelle Transformations- und Migrationsstrategien voraus. Ziel war aus diesem Grund die Umsetzung eines einfach erweiterbaren Transformationssystems zur Unterstützung verschiedener Ausgangs- und Zielplattformen. Das entwickelte Toolset TRANSFORMR basiert auf einem dreistufigen Prozess, der die Anforderungen an das Transformationssystem umsetzt. Zur Realisierung der unterschiedlichen Transformationstypen (Codeto-Code, Code-to-Model, Model-to-Code) wird ein Language Transformation Processor (LTP) eingesetzt, der die Transformationen mit Hilfe einer Grammatik der Eingabe 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 Transformationsprozess, wie er im Toolset TRANSFORMR mit folgenden Transformationsphasen implementiert ist:

72 6.1 Realisierung des Transformationssystems TRANSFORMR Target Model Logical Structure Logical Structure Legacy Software System consists of Flexible Software Representation (FSR) Target Flexible Software Representation (TFSR) consists of Target Software System Source Code Source 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 verschiedenen Verzeichnissen abgelegt sind. Mit Hilfe des LTP TXL wird aus jeder Eingabedatei ein abstrakter Syntaxbaum des Programmcodes generiert und eine XMLbasierte 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 verschiedene Transformationen auf die erzeugte FSR angewendet werden. Die Transformationen teilen sich in Basistransformationen, wie Umbenennen, Erzeugen oder Verschieben einzelner Softwareelemente, und zusammengesetzte Transformationen, die aufbauend auf den Basistransformationen mehrstufige umfassende Transformationen 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 Sichten mit verschiedenen Metriken der aktuellen Softwarerepräsentation möglich, um den Einfluss unterschiedlicher Transformationen zu bestimmen. Zur Auswahl geeigneter Transformationen ist ein Konzept des Zielmodells bzw. der Zielarchitektur 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 Zielsystem auf Modellebene beschreibt. Der letzte Schritt Code Generation erzeugt ausgehend von der TFSR (mit den verwendeten Transformationen) und dem bestehenden Legacy-Code den Programmcode 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 anzupassen. 71

73 6 Entwicklung und Realisierung des Transformationssystems Architectural Representation Layer FSR Model Transformation TFSR Transformation Layer language dependent AST language dependent AST AST Transformation language dependent AST language dependent AST Annotated Code Layer annotated annotated source code file source code file Code Transformation annotated annotated target code file target code file Code Layer source code file source code file target 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 Abbildung 6.2 dargestellt sind. Der Code Layer beinhaltet den ausführbaren Programmcode der Legacy-Software und der Zielsoftware und bildet die Basisebene des Transformationsprozesses. Im Annotated Code Layer werden den Softwareelementen des Programmcodes Annotationen hinzugefügt, um Modellelemente und Codeelemente eindeutig referenzieren zu können (beispielsweise lokale Variablen oder einzelne Anweisungen). Der Transformation Layer enthält abstrakte Syntaxbäume des annotierten Codes, die mit geeigneten Regeln sowohl horizontal (Code-to-Code) als auch vertikal (Code-to-Model, Model-to-Code) transformiert werden können. Die oberste Ebene (Architectural Representation Layer) enthält die Modellbeschreibung des Programmcodes (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 Kazman 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 Vereinfachung der Transformationen für den Nutzer genutzt. Die Ebenen Function-Level und Architectural Concepts sind im Transformationsprozess in der Schicht Architectural Representation Layer zusammengefasst. Die Transformation Layer entspricht im Horseshoe Model der Ebene Code-Structure und die zwei Ebenen Code Layer und Annotated Code Layer werden durch die Ebene Source Text repräsentiert 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 Aufbau des Modells zur Repräsentation von Software in einer objektorientierten Program- 72

74 6.1 Realisierung des Transformationssystems TRANSFORMR * Modifier + PUBLIC + PRIVATE... * 1 1 Program + subsystems: SubSystem* 1 1 * SubSystem + subsystems: SubSystem* + modules: Module* 1 * Module + modifiers: Modifier* + procedures: Procedure* + variables: Variable* Node Abstrakte Basisklasse aller FSR-Elemente + name: String + annotation: Annotation + semantics: Semantic LocalModule Statement in dem eine lokale Klasse definiert wird + module: Module 1 * * 1 Procedure + modifiers: Modifier* + variables: Variable* + codeblock: BlockStatement 1 * BlockStatement Komplexes Statement: if, for, while, etc. + codeblocks: CodeBlock* * Annotation Referenzierung der FSR- Elemente im Programmcodes Semantic Semantische Beschreibung des FSR-Elements + classification: NODE_CF + description: String Statement Abstrakte Basisklasse für beliebige Statements * * * 1 * 1 * Variable + modifiers: Modifier* + type: Module + dependencies: Dependency* * CodeBlock + type: CODEBLOCK_TYPE + dependencies: Dependency* + variables: Variable* + statements: Statement* + codeblocks: CodeBlock* + anonymousmods: Module* 1 * * 1 1 * LocalVariable Statement in dem eine lokale Variable definiert wird 1 + variable: Variable Dependency Abstrakte Basisklasse für Abhängigkeiten + calleenode: Node + callednode: Node * * SimpleStatement Zuweisung oder Methodenaufruf + dependencies: Dependency* + modules: Module* 1 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 (Procedure) und Membervariablen (Variable) von Klassen, sowie Elemente zur Repräsentation von Codeblöcken (CodeBlock) und einzelner Statements (Statement). Abhängigkeiten werden einerseits durch die abstrakte Basisklasse Dependency mit ihren Realisierungen 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, Realisierung) abgebildet. Jeder Knoten des Softwaregraphen stellt eine Realisierung der abstrakten Basisklasse Node dar und besitzt Referenzen zu Annotationsinformationen (Annotation) und se- 73

75 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 (Annotation), 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) 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 dargestellt (links). Jeder Knoten bietet kontextsensitiv verschiedene mögliche Transformationen (Refactor) und Sichten (View) an. Über die Menüleiste kann aus bestehendem Programmcode eine neue FSR erzeugt werden bzw. eine bestehende (transformierte) FSR gespeichert werden (File). Darüber hinaus besteht die Möglichkeit zur Anzeige allgemeiner Sichten (View) und die Verwaltung durchgeführter Transformationen (Transformation). 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 (Abbildung 6.5). Für diese Ansicht werden Subsysteme oder Module einzelner Subsysteme zu Metakomponenten, sogenannten Module Structures, zusammengefasst. Die Metakomponenten stellen eine mögliche Komponentenbildung der Legacy-Software dar, die unabhängig von bestehenden Komponenten gebildet werden kann. Die Module Structure View stellt die Anzahl der Abhängigkeiten zwischen den Metakomponenten als Graphstruktur dar. Die Ansicht ist vom Nutzer interaktiv steuerbar und bietet verschiedene Möglichkeiten der detaillierten Untersuchung der Abhängigkeiten über einen Properties-Dialog (Mitte rechts). Zunächst können im Hauptfenster des Views Zyklen im 74

76 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 zirkulä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, ausgeblendet 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 Analyse der ausgeblendeten Abhängigkeiten kann im Removed Dependencies-Dialog vorgenommen werden (rechts unten). Aus der Analyse der Abhängigkeiten können sich notwendige Transformationen (beispielsweise Verschiebungen) ergeben, die bestehende Strukturen der Legacy-Software 75

77 6 Entwicklung und Realisierung des Transformationssystems verbessern. Mögliche Transformationen können mit dem Toolset auf Modellebene vorgenommen werden, so dass vom Zugriff auf den tatsächlichen Programmcode abstrahiert 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, wurden Metriken aus den Sammlungen Metrics for Object-Oriented Design (MOOD), Metrics for Object-Oriented Software Engineering (MOOSE) und Quality Metrics for Object-Oriented Design (QMOOD) für eine Anwendung auf die FSR angepasst (Überblick über Metriken in [6]). Ausgewählte Metriken kommen beispielsweise in den Komponentenbildungstransformationen (Abschnitt 6.3) zur Anwendung. 6.2 Metakomponenten des Transformationssystems Wie in Abschnitt 5.3 beschrieben, existieren verschiedene Applikationen, die zur Realisierung von Teilaufgaben des Transformationssystems verwendet werden können. Gegenstand dieses Abschnitts ist eine Erläuterung, wie die Applikationen den Transformationsprozesses 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 plattformabhängiges Interface generiert werden muss, und realisiert den Zugriff auf Funktionen über den Systemzugriff System.loadLibrary(..). Die Bibliothek muss dabei mit einer aus der Schnittstelle generierten Headerdatei kompiliert werden. JNA dagegen ist eine zusätzliche Java-Bibliothek, die den Zugriff und auch die Konvertierung von Datentypen 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 entsprechen. Da die verwendeten Werkzeuge TXL und GraphViz als eigenständige Programme verfügbar sind, wurde für die prototypische Realisierung der Zugriff über Systemrufe bevorzugt, 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 Datenströ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

78 6.2 Metakomponenten des Transformationssystems package mypackage ; p u b l i c c l a s s MyClass { p r i v a t e Work v a r ; p u b l i c void dosomething ( ) { v a r. dowork ( ) ; } } package mypackage ; p u b l i c c l a s s MyClass { p r i v a t e mypackage. Work v a r /@v a r _ i d ="0"@/ ; } } p u b l i c void dosomething /@p r o c _ i d ="1"@/ ( ) /@s t m t _ i d ="1"@/ { /@b l o c k _ i d ="0"@/ /@s t m t _ i d ="0"@/ v a r /@d e p _ i d ="1"@/. dowork /@d e p _ i d ="2"@/ ( ) ; <module i d =" MyClass " package =" mypackage " kind =" c l a s s "> < v a r i a b l e i d =" v a r " t y p e =" mypackage. Work" a n n o t a t i o n i d =" 0 " /> <procedure i d =" dosomething " t y p e =" void " a n n o t a t i o n i d =" 1 "> <statement block a n n o t a t i o n i d =" 1 "> <codeblock a n n o t a t i o n i d =" 0 "> <statement simple a n n o t a t i o n i d =" 0 "> <procedure dependency a n n o t a t i o n i d =" 2 " t a r g e t p r o c e d u r e = " mypackage. Work#doWork ( ) " /> <variable dependency a n n o t a t i o n i d =" 1 " a c c e s s =" r e a d " t a r g e t v a r i a b l e = " mypackage. MyClass # v a r " /> </ statement simple> </ codeblock> </ statement block> </ procedure> </module> 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 eindeutige 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 Java. 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 hinzugefügt. In Abbildung 6.7 werden links Ausschnitte aus den Erweiterungen der Grammatik 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 Annotationen (redefine reference) und das anschließende Hinzufügen der Annotationen an allen definierten Positionen im abstrakten Syntaxbaum durch TXL (rule replacereferencestart). Nach der Aufbereitung des Programmcodes erfolgt die eigentliche Extraktion der sprachunabhängigen Zwischendarstellung. Abbildung 6.6 zeigt rechts die aus dem Programmcode erzeugte FSR, die auch die hinzugefügten Annotationen enthält. Einen Ausschnitt der Grammatikerweiterungen und Transformationsregeln für diese Transformation 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

79 6 Entwicklung und Realisierung des Transformationssystems % Erweiterung der Grammatik um dep-annotation redefine reference [id] [dep_annotation] [repeat dimension] [repeat component]... end redefine % Definition einer Referenz-Annotation define dep_annotation /@ dep_id= end define % Hinzufügen der dep-annotation für alle Referenzen % qualifizierte Typbezeichner werden nicht annotiert rule replacereferencestart skipping [type_specifier] replace $ [reference] ID [id] Dim [repeat dimension] RC [repeat component] construct Annotation [stringlit] _[getnextannotationdependency] construct Marker [dep_annotation] /@ dep_id= by ID Marker Dim RC [markcomponent] [markclasscreation] end rule % Erweiterung des Nichtterminals class_declaration redefine class_declaration.. <module id=[stringlit] [SP] package= [stringlit] [SP] kind=[stringlit] [SP] modifier=[stringlit] >.. </module> end redefine % Transformation einer java class_declaration in XML rule rp_class_declaration replace $ [class_declaration] M [repeat modifier] class N [class_name] E [opt extends_clause] I [opt implements_clause] B [class_body] construct Name [stringlit] _[quote N] construct Modifier [stringlit] _[quote M] import PACKAGE_NAME [stringlit] construct Inherits [repeat inherits] _[getinherits E I] by < module id=name package=package_name type="class" modifier= Modifier > Inherits B </ module> end rule Abbildung 6.7: Ausschnitt der Erweiterungen der Grammatik und Transformationsregeln 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 Methodendeklarationen) werden mit weiteren Regeln transformiert. Die erzeugte FSR stellt ein sprachunabhängiges Modell dar, das projektspezifisch jedoch eher auf objektorientierte Eingabesprachen zugeschnitten ist. Auf diesem Modell als Zwischendarstellung können verschiedene Restrukturierungen und andere Transformationen 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 Komplexität [43]. Ziel der Modularisierung ist eine hohe Kohäsion (cohesion, starker Zusammenhalt von Elementen einer Einheit, z.b. von Klassen) und niedrige Kopplung (coupling, 78

80 6.3 Realisierung prototypischer Komponentenbildungstransformationen schwacher Zusammenhalt von Elementen unterschiedlicher Einheiten) [25]. Eine Spezifikation 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 Komponenten oftmals erschweren und ein Hinweis für ein falsches Architekturdesign sind. Eine bestehende Spezifikation der Modularität einer Software kann durch Erweiterungen 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 damit zur Verletzung der ursprünglichen Modularität kommen. Eine ökonomisch tragbare Weiterentwicklung einer über Jahre gewachsenen Software ist nur durch eine Restrukturierung 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 Softwaresystems mit sich. Für Entwickler ist daher eine Unterstützung durch Werkzeuge für wiederkehrende Transformationen vorteilhaft. Für die Modularisierung eines Softwaresystems sind vor allem Transformationen wichtig, die das Verschieben unterschiedlicher Elemente der Softwarearchitektur erlauben. Im Bereich objektorientierter Sprachen können Verschiebungen auf verschiedenen Ebenen stattfinden. Die Verschiebung von Klassen zwischen Komponenten (z.b. packages) bildet dabei die allgemeinste Transformation. Diese Verschiebetransformation wird von den meisten aktuellen Entwicklungsumgebungen (z.b. Eclipse, Delphi Professional) funktionalitäts- und korrektheitserhaltend unterstützt. Durch eine Vermischung von Funktionalität verschiedener Komponenten ist es häufig notwendig auch Elemente innerhalb von Klassen wie Methoden oder Membervariablen in andere Klassen zu verschieben, um die gewünschte Modularität herzustellen. Durch die Bindung einer Methode 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 werden 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, individuelle Transformationen benötigt, kann eine funktionalitäts- und korrektheitserhaltende Verschiebung nur in ausgewählten Fällen automatisch durchgeführt werden. Die Verschiebung wird daher meist nur für einfache Fälle (z.b. wenn die Methode keinerlei Abhä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

81 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. Dabei wird der Legacy-Programmcode durch verschiedene (semi-)automatische Regeln in vorhandene Kategorien eingeordnet und anschließend eine Trennung der Code-Kategorien vorgenommen, die auch eine Verschiebung von Methoden beinhaltet. Die Autoren beschreiben die Verschiebung jedoch nur auf Modellebene (im Program Representation 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änderungen des Programmcodes. Tsantalis und Chatzigeorgiou [51] beschreiben eine Metrik 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 Eclipse-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 MemberGroups Methoden besitzen zur Ermittlung ihres Rückgabewerts häufig Abhängigkeiten zu anderen Membern (Membervariablen und -methoden) der Klasse. Aus diesem Grund betrachten wir zusammengehörige Gruppen von Membern einer Klasse (MemberGroups [27]), die eine von den restlichen Membern der Klasse separierte Funktionalität darstellen. Das Ziel der Verschiebung einer MemberGroup ist die Verbesserung der Modularitä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 aufgebaut, der sowohl die Abhängigkeiten zwischen Membern des Softwaresystems als auch die Zugehörigkeit eines Members zu einer Klasse abbildet (Beispiele siehe Abbildungen 6.9 und 6.10). Für die Spezifikation einer MemberGroup werden folgende Relationen zwischen den Membern u und v definiert: dep(u, v): Abhängigkeit zwischen u und v, unabhängig von der Richtung der Abhängigkeit; dep U(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

82 6.3 Realisierung prototypischer Komponentenbildungstransformationen Tabelle 6.2: Knotenmengen und Kanten des Softwaremodells zur Ermittlung von MemberGroups. Beschreibung Definition Menge aller Klassen = {C 0,..., C n } 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 C M(C) = Meth(C) Var(C) Con(C) Menge aller Member des Projekts M = C M(C) Lese-, Schreib- oder Aufrufabhängigkeit zwischen Member u und v (u v) u v Ungerichtete Kante zwischen Member u und v dep(u, v) = (u v) (v u) Ungerichteter Pfad zwischen u und v innerhalb einer Untermenge aller Member U M dep U (u, v) 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 Meth(C) Var(C) dep (m, v)} Meth(C) Var(C) {u Con(C) t MG(m) mit dep(u, t)}. (6.1) 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 Membervariablen 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 implementiert. Er ermittelt die MemberGroups aus der Modellbeschreibung der Software und bietet verschiedene Möglichkeiten, die gefundenen MemberGroups zu filtern und darzustellen. Abbildung 6.8 zeigt links die Nutzerschnittstelle des Browsers, mit der über den FSR-Baum (links) MemberGroups aus bestimmten Bereichen der Legacy-Software angezeigt werden. Die angezeigten MemberGroups können danach mit verschiedenen 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 dargestellt, wobei die Größen 4 9, 10 19, etc. zur besseren Übersicht automatisch zusammengefasst werden. 81

83 6 Entwicklung und Realisierung des Transformationssystems Abbildung 6.8: Links: TRANSFORMR MemberGroup Browser zur Analyse der MemberGroups eines Legacy-Softwaresystems. Rechts: Statistik der ausgewählten MemberGroups (Häufigkeit der Größe von MemberGroups) 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, werden für jedes Pattern Vorbedingungen definiert, die erfüllt sein müssen, damit die notwendigen 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 Struktur beschränkt sind, aber im Softwaresystem beliebig verwendet werden können. Zusätzlich zu den Vorbedingungen, die im Folgenden für beide Patterns betrachtet werden sollen, können Einschränkungen einer Verschiebung auch durch Generalisierung und Realisierung der Klasse der MemberGroup entstehen. Eine Verschiebung ist beispielsweise nicht möglich, wenn eine Methode einer MemberGroup die Realisierung eines Interfaces darstellt oder Member von Kindklassen der MemberGroup-Klasse Abhä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 betrachtet. Verschiebung von common MemberGroups Ziel der Verschiebung von MemberGroups nach dem common Pattern (vgl. Gleichung 6.1), ist die Verlagerung von ungünstig positionierten Teilfunktionalitäten in Klassen mit höherer semantischer Zugehörigkeit unter Beibehaltung oder Reduktion der Abhängigkeiten zwischen den betreffenden 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

84 6.3 Realisierung prototypischer Komponentenbildungstransformationen Abbildung 6.9: TRANSFORMR Aufrufdiagramm mit Klassen (Rechtecke), Methoden (Ellipsen) und Membervariablen (Rhomben). Links: Verschiebbare 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 einer 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 instantiiert; Alle Anweisungen im Konstruktor der Ausgangsklasse, die Member der MemberGroup referenzieren, müssen unabhängig von Variablen sein, die nur lokal im Konstruktor verfügbar sind, da sonst die Verschiebung der Statements in den Konstruktor 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 Anzahl der Abhängigkeitsbeziehungen. Neben der Verschiebung der Member m(), b() und var, müssen die Aufrufe der Methode caller() zu den Methoden m() 83

85 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ängigkeit Target() var, rechts). Bei einer allgemeinen Verschiebung einer common MemberGroup müssen zunächst potentielle Zielklassen bestimmt werden. Dazu werden alle Klassen ermittelt, die Abhängigkeiten zur MemberGroup besitzen. Diese Menge, die als M has bezeichnet wird, enthält die ursprüngliche Klasse der MemberGroup selbst und alle Klassen, die Membervariablen oder Methoden der MemberGroup nutzen. Mögliche Zielklassen für die MemberGroup sind alle Klassen, die als Typen von Membervariablen in allen Klassen von M has auftreten, aber nicht der Ausgangsklasse entsprechen. Im Beispiel in Abbildung 6.9 besteht die Menge M has nur aus der Klasse Another. Die Menge möglicher Zielklassen enthält im Beispiel somit nur den Typ der Membervariable t (Klasse Target), da keine weiteren Typen in allen Klassen M has als Membervariablen verwendet werden (ohne Ausgangsklasse Source). Aus der Menge aller möglichen Zielklassen kann als konkrete Zielklasse diejenige Klasse ausgewählt werden, deren CIN T -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 Konstruktor der Zielklasse (Zeile 6) und alle Member der MemberGroup in die Zielklasse verschoben (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 werden durch das strong Pattern nur MemberGroups betrachtet, die genau eine öffentlich genutzte Methode (die von anderen Klassen aufgerufen wird) besitzen. Mögliche Zielklassen der strong MemberGroups sind die Klassen, die der öffentlichen Methode als 84

86 6.3 Realisierung prototypischer Komponentenbildungstransformationen Abbildung 6.10: TRANSFORMR Aufrufdiagramm. Links: Verschiebbare strong MemberGroup {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 meisten Abhängigkeiten bestehen. Die Verschiebung einer strong MemberGroup ist möglich, wenn die folgenden Vorbedingungen erfüllt sind: Die CINT -Metrik von MemberGroup und Zielklasse hat einen Wert von mindestens 1; Ausgangs- und Zielklasse werden in allen nutzenden Klassen nur ein Mal instantiiert; Analog zum common Pattern müssen die Anweisungen des Konstruktors der Ausgangsklasse, 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 bestehend 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 Zielklasse (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 Modularitä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

87 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 Algorithmus mit der Auflösung von Namenskonflikten zwischen Membern der MemberGroup und Membern der Zielklasse begonnen (Zeile 3) und anschließend abhängige Anweisungen 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 Zielklasse 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 Referenzen zur Zielklasse (Parameter des Methodenaufrufs) ersetzt und der Parameter aus der Liste der Parameter der Methode entfernt (Zeile 11) Evaluierung der Verschiebetransformationen Zur Evaluierung der Auswirkungen der dargestellten Verschiebungen auf die Modularität von Softwaresystemen wurden die Patterns auf zwei Open Source Projekte angewendet. Ausgewählt wurden JMeter 4 (Version 2.3.2, 80 KLOC (kilo lines of code), 794 Klassen), ein Desktop Test- und Analysetool für verschiedene Netzwerkapplikationen und -protokolle, und jedit 5 (Version 3.4, 95 KLOC, 940 Klassen) ein Cross-Plattform 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 Anzahl 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 gefunden, allerdings war bei 90 % der MemberGroups kein geeigneter Parameter vorhanden, dessen Typ als Zielklasse der MemberGroup geeignet war (z.b. primitive Datentypen, Interfaces, Klassen von Bibliotheken). Im Falle der common MemberGroups war

88 6.4 Realisierung prototypischer Filtertransformationen Tabelle 6.3: Verbesserungen der Anzahl abhängiger Klassenpaare. Eine Verringerung entspricht einer Verbesserung der Modularität des Softwaresystems. Projekt abhängige Klassenpaare Ausgangswert strong common jedit (+0.04 %) 4449 ( 0.08 %) 4451 ( 0.04 %) JMeter ( 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 Anwendung beider Patterns auf den Programmcode der ausgewählten Projekte. Bei Anwendung 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 Klassenpaare, 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üfungen der Vorbedingungen und zugehörige Transformationen können automatisiert mit dem TRANSFORMR durchgeführt werden und sind für beliebige weitere Projekte anwendbar. 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. Monolithische Anwendungen weisen oftmals Defizite auf, die durch die Integration externer Services bzw. die Auslagerung interner Services gelöst werden können. Beispielsweise bieten existierende Applikationen Services wie eine zentrale Datenhaltung oder eine konfigurierbare Web-Schnittstelle an, die von der monolithischen Software als Nutzeroberflä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 speicherintensiven Berechnung auf einen Server betrachtet, der durch remote method invocation (RMI) mit der Client-Anwendung kommuniziert. Abbildung 9.5 (Seite 128) zeigt 87

89 6 Entwicklung und Realisierung des Transformationssystems (a) (b) (c) Abbildung 6.11: Extraktion eines Interfaces aus gemeinsamen Methoden zweier Klassen 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 Berechnung 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 bestimmten Abhängigkeitsbeziehung von Klassen und zusätzlicher Codegenerierung zur Kapselung und Realisierung der entfernten Aufrufe. Die Umsetzung der Transformation wurde in enger Zusammenarbeit mit der Realisierung des Client-Server-Frameworks 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 einer Codetransformation zusammen. In der Modelltransformation wird ein neues Module (IMandelbrotCalculator) erzeugt, das die aus den Basismodulen extra- 88

90 6.4 Realisierung prototypischer Filtertransformationen package m a n d e l b r o t. c a l c u l a t o r ; p u b l i c c l a s s Mandelbrot1 { p u b l i c MandelbrotImage c a l c u l a t e ( F r a c t a l P r o p e r t i e s fp ) {... } } package m a n d e l b r o t. c a l c u l a t o r ; import m a n d e l b r o t. I M a n d e l b r o t C a l c u l a t o r ; p u b l i c c l a s s Mandelbrot1 implements I M a n d e l b r o t C a l c u l a t o r { p u b l i c MandelbrotImage c a l c u l a t e ( F r a c t a l P r o p e r t i e s fp ) {... } } include "Java.Grm" function main replace [program] P[program] by P [addimport][addimplementswith] [addimplementswithout] end function function addimport replace [repeat import_declaration] ImpDec[repeat import_declaration] construct AddImp [import_declaration] import mandelbrot. IMandelbrotCalculator ; by ImpDec [. AddImp] end function function addimplementswithout replace [class_header] M[repeat modifier] class Fractal E[opt extends_clause] construct AddImpl [implements_clause] implements IMandelbrotCalculator by M class Mandelbrot1 E AddImpl end function function addimplementswith.. end function Abbildung 6.12: Links: Ursprünglicher (oben) und transformierter (unten) Programmcode des Basismodules Mandelbrot1. Rechts: Ausschnitt der TXL Transformationsregeln zum Hinzufügen des Interfaces IMandelbrotCalculator zum Basismodule Mandelbrot1. hierten Methodensignaturen (calculate(fractalproperties)) besitzt. Zusätzlich wird das erzeugte Module als implementierendes Interface zu den Basismodulen (Mandelbrot1, Mandelbrot2) hinzugefügt. Bei den Transformationen müssen verschiedene Vorbedingungen beachtet werden. So können beispielsweise nur Methoden in das Interface extrahiert werden, die in allen Basismodulen die gleiche Signatur aufweisen. Ein Ausschnitt der Codetransformation zeigt Abbildung Durch die Anwendung der TXL-Regel (rechts), wird zu einer Basisklasse (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 implementiert 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

91 6 Entwicklung und Realisierung des Transformationssystems nen Beispiel (Abbildung 6.12 rechts) können beliebige Basismodule durch weitere Interface-Deklarationen erweitert werden. Dafür muss in den TXL-Regeln nur der Namen 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 spezifische Programmtransformationen generiert. Ein Template besteht aus den TXL-Regeln 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 Zusammensetzen 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 Softwareprojekte ist eine Auswertung des Verhaltens für verschiedene Eingabekonfigurationen notwendig. Von besonderem Interesse ist dabei die dynamische Entwicklung des Ressourcenbedarfs (Zeit und Speicher) für unterschiedliche Größen des zu untersuchenden Programmcodes. Da die Extraktion der FSR aus Programmcode eine mehrstufige Transformation darstellt und beispielhaft für die Entwicklung verwendeter Ressourcen des Transformationssystems steht, wurde der Extraktionsprozess zur detaillierten Untersuchung 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 Abweichung von 5 %) zu bilden. Quelldateien, die öffentliche Enumerations oder Deklaration von Annotationen enthielten, wurden dabei nicht ausgewählt, da diese speziellen Typen von Quelldateien vom Prototyp des Transformationssystems noch nicht verarbeitet 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 identifizieren 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 ) verwendet. 90

92 6.5 Skalierbarkeit des Transformationssystems time in seconds Total Time for a new TransFormr project time in seconds Globalizing Annotation FSRCreation LoadFiles AddConstructors ResolveDependencies AddGlobalizedFiles 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 Laufzeiten 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 linear 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 Abbildung 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 Gesamtlaufzeit in Anspruch nehmen, wohingegen die Identifikation der Abhängigkeiten im Projekt (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 unabhä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 bearbeitetes 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

93 6 Entwicklung und Realisierung des Transformationssystems FSR AnnotatedCode 9 8 FSR / source code rate Annotated code / source code rate total file size in MB generated code / project-size rates 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: Entwicklung des Verhältnisses zwischen dem Speicherbedarf des annotierten Codes bzw. der XML-Struktur der FSR und dem originalen Programmcodes Time / FSR Size Time / Legacy Project Size time / size (FSR, legacy code) rate 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

94 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 Hauptaugenmerk liegt dabei auf der Erstellung einer erweiterbaren Softwarearchitektur. Beim Entwurf 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 erfordert 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 sichere 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öglichkeiten, 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 diesem Projekt betrachtete Zielsoftware ist die Lauffähigkeit auf einem heterogenen System. 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 Schnittstellen haben sollen, ist es möglich, einzelne Komponenten mit unterschiedlichen Programmiersprachen oder Frameworks umzusetzen. Eine komponentenbasierte Architektur ermöglicht eine bessere Adaptierbarkeit an die Anforderungen des heterogenen Systems, da einzelne Bausteine speziell an Hardware- oder Betriebssystemeigenschaften 93

95 7 Entwurf eines Client-Server-Frameworks CBFRAME angepasst werden können. Die Zielarchitektur soll einem Client-Server-Modell entsprechen, in dem die Komponenten mittels Anfragenachrichten Dienste anderer Komponenten nutzen sollen. Damit ist der Grundstein gelegt, um eine verteilte Architektur der Gesamtsoftware zu ermöglichen, bei der Teilprozesse der Business-Software auf unterschiedlichen Recheneinheiten ausgeführt werden können. Die Analyse der in der Ausgangssoftware 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 Architektur 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 Lizenzgebü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 untersucht. Es sollte eine aktuelle Übersicht über die verwendeten Technologien erstellt werden, die Anhaltspunkte gibt, woran sich die neue Architektur der zu transformierenden 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: Compiere 1, erpos 2, JFire 3, und Openbravo 4. 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

96 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 (WfMCkonform) jbpm/jboss jbpm keine Persistenzschicht Compiere Hibernate JDO 2.0 Hibernate Framework Spring Spring Weitere Technologien Enterprise Service Bus (ESB) plikationsserver und Clients. Die Systeme basieren auf der Java-Plattform, um Unabhängigkeit von der Zielhardware zu gewährleisten. Als grundlegender Java Enterprise Softwarestack wird bei den genannten ERP-Systemen entweder der Java-Enterprise- Application-Server [12] oder das Spring-Framework 5 verwendet. Bei der Erstellung von Applikationen die auf ERP-Systemen aufsetzen werden Codeteile oftmals mittels modellgetriebener Softwareentwicklung automatisiert erzeugt. Zum Einsatz kommen dabei Werkzeuge wie openarchitectureware 6, welche gängige Techniken 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 jbpm 7 von JBoss. jbpm bietet die Möglichkeit, Geschäftsprozesse mittels jpdl (Beschreibungssprache) 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 Sprache der WfMC 8, wie bspw. XPDL

97 7.4 Middleware-Plattform 7 Entwurf eines Client-Server-Frameworks CBFRAME Die Evaluation der ERP-Systeme macht deutlich, dass eine moderne Softwarearchitektur, 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-Application-Server. Da es aber neben der Java Enterprise Edition (JEE) auch andere Middleware-Ansätze gibt, soll ein weiterer Vergleich Aufschluss geben, welche Middleware für den Einsatz in TransBS geeignet ist Anforderungen Die Middleware, auf der CBFRAME aufbauen soll, muss einige Voraussetzungen erfü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 Komponenten bei Bedarf modifiziert werden. Die meisten Applikationsserver, wie z. B. JBoss, bieten einen sehr großen Softwarestack, der häufig verwendete Bestandteile einer Business-Applikation als generische Komponente bereitstellt. Als Beispiel sei die Persistenzschicht erwähnt, mit der es möglich ist, einzelne Geschäftsobjekte direkt auf relationale Datenbanken abzubilden ohne eigenen Code schreiben zu müssen. Ein weiteres wichtiges Kriterium neben dem Funktionsumfang ist die Unterstützung durch Entwicklungswerkzeuge, 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 Java Enterprise Edition Die Java Enterprise Edition ist eine Spezifikation einer Softwarearchitektur, auf der Anwendungen aufgebaut werden können. Die Spezifikation umfasst Softwarekomponenten 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

98 7.4 Middleware-Plattform Tabelle 7.2: Implementierungen der Java-Enterprise-Edition Open Source JBoss JOnAS Sun Java System Application Server, GlassFish Apache Geronimo proprietär IBM WebSphere BEA WebLogic SAP Web Application Server 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 Anwendungen effizient und schnell entwickeln zu können. Die klar definierten Schnittstellen der einzelnen Softwarekomponenten sorgen für Interoperabilität der Spezifikationsimplementierungen verschiedener Hersteller. Durch den Einsatz eines JEE-Applikationsservers 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 Anwendungen 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) Geschä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 Eclipse 10 und NetBeans 11 sehr gut unterstützt. Mit diesen IDEs lassen sich durch viele verschiedene Assistenzprogramme (Wizards) sehr schnell neue EJBs erzeugen und debuggen. Außerdem 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 Middleware für CBFRAME dienen kann. Die Spezifikation bietet eine große Menge an standardisierten 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 Hardware stellt einen weiteren Pluspunkt dar. Darüber hinaus existieren freie Umsetzungen des Standards, wodurch sich Lizenzgebühren einsparen lassen. Für JEE stehen leistungsfä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 mitgeliefert werden, ist die Einarbeitung sehr zeitintensiv. Als weiteren Nachteil kann man die

99 7 Entwurf eines Client-Server-Frameworks CBFRAME Fixierung auf Java als Programmiersprache sehen. Da man aber mittlerweile auch andere Sprachen auf der Java-Virtual-Machine benutzen kann, wie Groovy 12 oder Scala 13, sollte dies kein schwerwiegender Nachteil sein 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 Anwendungen in heterogenen Systemen festlegt. Wichtige Ziele des CORBA-Standards waren die Verwendung objektorientierter Schnittstellen und die Unabhängigkeit von der verwendeten Programmiersprache. Im Jahr 1991 wurde die Common Object Request Broker Architecture 14 (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 Referenzmodells. Das Objektmodell definiert Schnittstellen zwischen auf verteilten Rechnern ausgefü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 Beschreibung 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 aktiviert diese. 4. Client erzeugt Instanz des Stubs und ruft Methoden des Stubs auf. 5. ORB überträgt bei Methodenaufruf Eingabeargumente (in) zum Server, ruft entsprechende 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 Methoden und Datentypen abzubilden sind. Eine Übersicht über die CORBA-Standardisierung unterschiedlicher Programmiersprachen ist in Tabelle 7.3 aufgeführt

100 7.4 Middleware-Plattform Tabelle 7.3: Programmiersprachen mit CORBA-Anbindung. standardisiert Ada C C++ COBOL CORBA Scripting Language Java Lisp, PL/1, Python, Smalltalk nicht standardisiert Delphi Eiffel Perl Tcl Da Delphi keine standardisierte Programmiersprache ist, muss innerhalb des TransBS- Projektes der benötigte Funktionsumfang von CORBA im konkreten Fall geprüft werden. 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 allem unterschiedliche Standards implementieren. Die Eigenschaften einiger ausgewählter CORBA-Implementierungen sind in Tabelle 7.4 vergleichend aufgeführt. Der Vergleich zeigt, dass es sehr große Unterschiede zwischen den einzelnen Implementierungen 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-Projekt 15 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

101 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 Java ORBit2 frei 2.4 C, C++, Python, Perl, Ruby,... TAO frei 2.4 (+3.0 Features) C++ Java IDL (Sun) frei 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 NET Framework Eine weitere Middleware-Plattform ist das.net-framework, das von Microsoft angeboten 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 existieren, z. B. Mono 16. 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 Einsetzbarkeit im heterogenen Umfeld eingeschränkt (bspw. gegenüber JavaEE) 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. Dabei 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

102 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 verwenden, 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 Zielsetzung Die Transformation der GUI ist ein Teilschritt in der gesamten Transformationskette, 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 weiteres 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 Oberfläche eine Überführung der betroffenen Geschäftslogik nach sich zieht. Ziel der Modernisierung der grafischen Benutzeroberfläche ist die Extraktion von Programmcode, der die grafische Oberfläche beschreibt, aus der monolithischen Software und die Bereitstellung der grafischen Oberfläche für heterogene Systeme. Die Trennung von GUIund Geschäftslogik ist erforderlich, um eine Modularisierung der Geschäftssoftware zu erreichen. 101

103 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 (Widgets), 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 Adobe Flash werden oftmals zusätzlich eingesetzt. Bei Web-Applikationen wird die grafische Oberfläche naturgemäß erst zur Laufzeit, üblicherweise vom Webbrowser, ausgewertet 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 Beschreibungssprache 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ützende SSL/TLS-Protokoll zur Anwendung kommen, welches mit Zertifikaten arbeitet. Das Transport Layer Security(TLS)-Protokoll arbeitet dabei transparent für die eigentliche Applikation auf der Transport-Schicht im TCP/IP-Protokollstack und ist somit vielseitig 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 Benutzerfreundlichkeit ist eine Auslagerung der Aufgabe in einen weiteren Thread sinnvoll. Dabei ist zu beachten, dass nach der Auslagerung grafische Ein- und Ausgaben des ausgelagerten Threads nebenläufig zu weiteren nutzergesteuerten Ein- und Ausgaben auftreten können. Eine threadsichere Gestaltung der grafischen Oberfläche ist daher sinnvoll und wird durch die Verwendung eines dedizierten UI-Threads realisiert, der die grafischen 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 Konzepte zur UI-Transformation von GBware Um ein Werkzeug in TRANSFORMR zu realisieren, das den Entwickler bei der Transformation 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

104 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 verschiedene Darstellungsformen der grafischen Oberfläche gewählt werden. Außerdem werden Änderungen am Dokument sofort in der Präsentationsschicht sichtbar. Die Steuerungskomponente gewährleistet auch den threadsicheren Zugriff auf das Modell und die Präsentation. Es wurden zwei Konzepte der Transformation von Benutzeroberflächen erarbeitet, welche nachfolgend vorgestellt werden. Um die Probleme bei der Transformation in eine MVC-Architektur zu begrenzen, werden entsprechende Arbeitsschritte definiert, die eine werkzeuggestützte Transformation der GUI ermöglichen. Manuelle Vortransformation in ein MVC-Framework Das hier vorgestellte Konzept setzt eine manuelle Vortransformation von der zu transformierenden monolithischen Software (GBware) nach MVC voraus. Die schematische Darstellung in Abbildung 7.1 veranschaulicht dieses Konzept. Dabei wird der ursprüngliche Quellcode manuell in ein vorher definiertes MVC-Framework übertragen. Die Funktionalität bleibt dabei komplett erhalten. Bei dieser manuellen Transformation werden Geschäftslogik und grafische Oberfläche voneinander getrennt. Die manuelle Vortransformation 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. Weiterhin 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

105 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ängige 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 abstrakten 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 Programmcode mit Werkzeugunterstützung abzuspalten. Das Ergebnis dieses Transformationsschritts 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 Standardbibliothek aufgebaut ist, kann der größte Teil der Elemente (statische Elemente) automatisch 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 gewonnene MVC-Beschreibung der GUI kann im Nachgang wie im ersten Konzept weiter transformiert werden. Abbildung 7.2 skizziert die Funktionsweise dieses Konzepts. 104

106 7.6 Rahmenarchitektur von CBFRAME View Rich Client (Windows Forms) Web Browser Client IIOP/ Web Services HTTP Presentation GUI Elements Controller GUI Logic Business Objects Application Server Persistence Layer Model Database Database Abbildung 7.3: Architektur von CBFRAME für Web-Clients Zusammenfassung Um die grafische Oberfläche einer monolithische Software in eine moderne, plattformunabhä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 Werkzeugunterstützung übertragen. Die wenigen sprachspezifischen Details, die nicht automatisch 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 Untersuchungen 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. Zugrunde liegt hier eine Transformation von Delphi nach JavaEE unter Verwendung einer verteilten Architektur. 105

107 7 Entwurf eines Client-Server-Frameworks CBFRAME Abbildung 7.3 zeigt die Softwarearchitektur der Zielsoftware, wenn die Ausgangssoftware in eine Web-basierte Anwendung überführt werden soll. Wichtig in dieser Architektur ist die strikte Trennung der einzelnen Softwareteile in die verschiedenen Schichten. 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 Benutzeroberflä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äsentationsschicht 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 angebunden werden, z. B. Delphi-Clients, ist es möglich, die Verbindung zum Server entweder über Webservices zu realisieren oder das IIOP-Protokoll 17 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 Persistenzschicht oder die Präsentationsschicht. Die Implementierung wird bei der Festlegung 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 activebpel 18, Persistenzschicht Hibernate 19, Datenbank MySQL 20. Die gewählten Instanziierungen bezüglich der Architektur für die Zielsoftware definieren damit auch die möglichen Sicherheitskonzepte und Kommunikationsprotokolle. 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-Frameworks, in welches die Ausgangssoftware transformiert werden soll. Dabei wurden besonders freie Softwareprodukte und Open Source-Technologien untersucht. Die Analyse verschiedener ERP-Systeme ergab, dass das Framework mehrschichtig ausgelegt 17 Internet Inter-ORB Protocol

108 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 Rahmenarchitektur von CBFRAME trägt all diesen Anforderungen Rechnung indem sie auf aktuelle Technologien aus dem Java-Umfeld aufbaut, um auch zukünftige Erweiterungen zu ermöglichen. Die konkrete Auswahl einzelner Technologien, die die vorgestellten Konzepte umsetzen, wird im folgenden Kapitel vorgestellt. 107

109 108 7 Entwurf eines Client-Server-Frameworks CBFRAME

110 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks 8.1 Zielsetzung Nachdem im vorherigen Arbeitspunkt die Architektur des Frameworks CBFRAME umrissen wurde, ist die Realisierung der Infrastruktur des Frameworks Inhalt dieses Arbeitspunktes. 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 genannten Ziele umzusetzen, werden zuerst verschiedene Beschreibungssprachen für Business- Workflows auf ihre Eignung hinsichtlich der Integration in CBFRAME untersucht. In einer Fallstudie wird danach aufgezeigt, wie sich die Kommunikation zwischen Legacyund erneuertem Softwaresystem realisieren lässt. Dazu wird eine Leistungsdiagnostik einzelner Kommunikationslösungen durchgeführt. 8.2 Workflow-Beschreibungssprachen EPK Die Ereignisgesteuerte Prozesskette (EPK) wurde an der Universität des Saarlandes entwickelt [32] und ist nunmehr integrativer Bestandteil des ARIS-Konzepts (Architektur Integrierter Informationssysteme) der IDS Scheer. Die EPK ist eine grafische Modellierungssprache, mit der sich Geschäftsprozesse einer Organisation beschreiben lassen. Geschäftsprozessbeschreibungen in EPK sind nicht ausführbar, können aber von verschiedenen Übersetzungswerkzeugen in ausführbaren Code zur Einbettung in eine Business-Applikation transformiert werden. Eine EPK wird durch einen gerichteten Graph repräsentiert, dessen Knoten Ereignisse oder Funktionen darstellen können, wie in Abbildung 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

111 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks Abbildung 8.1: Beispiel grafisch modellierter Business Prozesses. (Links: BPMN, Rechts: EPK) 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 Object 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 Objects, 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 Entscheidungspunkt. 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 werden. Damit lassen sich Benutzerrollen definieren. Artifacts sind weitere Elemente wie Annotationen oder Datenobjekte 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 Beschreibungssprachen 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 notwendig. Zu diesen ausführbaren Prozessbeschreibungen zählen z. B. die jbpm Process Definition Language (JPDL), die XML Process Definition Language (XPDL) und die 110

112 8.2 Workflow-Beschreibungssprachen Business Process Execution Language (BPEL). Diese ausführbaren Workflow-Beschreibungssprachen 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 Modellierung 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] JPDL Die jbpm Process Definition Language (JPDL 1 ) lehnt sich stark an die Java-Technologie 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ützung von Langzeitprozessen (long running processes), die oft mit Human-Tasks verknü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 Integration in Java-Enterprise-Applikationen weniger Zwischenschichten erfordert. Auszuführende Anweisungen und Tasks können direkt als Java-Code mit der entsprechenden 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 schrittweise Transformation der Legacy-Software stattfinden muss, ist es notwendig, möglichst unabhängig von der Programmiersprache zu sein. Andererseits ist die Sprache nicht offiziell standardisiert und beschränkt sich auf den Applikationsserver von JBoss. Ist jedoch 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 XPDL Die XML Process Definition Language (XPDL 2 ) ist eine XML-basierte Sprache zur Modellierung von Geschäftsprozessen als Workflows. Die Entwicklung und Standardisierung von XPDL wird von der Workflow Management Coalition (WfMC 3 ) vorangetrieben. Die Version 2.0 der XPDL, die 2005 veröffentlicht wurde, unterstützt den

113 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks BPMN-Standard zur grafischen Repräsentation eines Workflows. Durch die Standardisierung der Sprache eignet sich XPDL als Austauschformat zwischen Workflow-Modellierungswerkzeugen. Außerdem existieren mehrere XPDL-kompatible Ausführungsumgebungen (Engines), mit denen XPDL-basierte Prozessabläufe ausgeführt werden können. Eine solche Engine ist z. B. Enhydra Shark 4, die als Open Source-Version zur Verfügung steht BPEL Eine weitere XML-basierte Beschreibungssprache von Workflows ist die Business Process Execution Language (BPEL [2]). Sie liegt seit April 2007 als WS-BPEL in der Version 2.0 vor. BPEL dient primär der Orchestrierung von Webservices, weshalb Nutzerinteraktionen nicht Teil des Standards sind. Für die Integration von Human Tasks wurde eine Erweiterung mit dem Namen BPEL4People veröffentlicht, welche einige Hersteller 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äftsprozessen etabliert. Dazu beigetragen haben eine Reihe von verfügbaren Ausführungsumgebungen und zahlreiche freie sowie kommerzielle Entwicklungswerkzeuge Fazit Die Integration einer Verarbeitungsmöglichkeit von Workflows in Business-Software- Produkte ist eine komplexe Aufgabe. Für die jeweilige Ausgangssoftware muss geprüft werden, welche Faktoren die Wahl der Beschreibungssprache und der Ausführungsumgebung beeinflussen [35]. Die Evaluation verschiedener freier ERP-Systeme in Abschnitt 7.3 zeigte, dass JPDL im Java-Umfeld häufig genutzt wird. Speziell beim Einsatz von JBoss bietet sich JPDL als Workflow-Beschreibungssprache an, da die Ausführungsumgebung 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-Entwicklungsprozess integrieren lässt. Bei BPEL muss man z. B. vorher genau festlegen, welche Funktionen als Webservices bereitzustellen sind, um darauf einen BPEL-Workflow aufsetzen 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 Gegensatz 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 Gewicht, wenn das Entwicklungswerkzeug eine Übersetzung von BPMN-Modellen nach

114 8.3 Vergleich verschiedener BPEL-Implementierungen BPEL unterstützt. Die häufige Verwendung in Industrieprojekten sowie die größere Anzahl 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 Bestandsaufnahme der verschiedenen BPEL-Implementierungen (genannt BPEL-Engines) und deren 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 Plattformunabhä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-Lizenzen nicht genügen, muss eine kommerzielle Version gekauft werden, was einen nicht unerheblichen Kostenfaktor darstellt. Darüber hinaus wird oft die kommerzielle Version 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 Implementierungen nahezu vollständig abdecken. Als Fazit dieses Vergleichs lässt sich angeben, dass zwar alle Firmen ihre Produkte (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ührende 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

115 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks Tabelle 8.1: Vergleich verschiedener BPEL-Ablaufumgebungen. Sun BPEL Engine activebpel intalio Server Application server Glassfish Apache Tomcat Apache Geronimo (community) Lizenz CDDL und GPLv2 GPL Mozilla Public License (MPL) u.a. (80% Open Source) Betriebssystem alle (Java) alle (Java) alle (Java) kommerzielle Version (Preis) Sun Java System Application Server (pro Socket Standard US$, Enterprise US$) activevos (pro CPU-Sockel im ersten Jahr US$, US$ in Nachfolgejahren) intalio Enterprise Edition (> US$ / Jahr) aktuelle Version (Jan09) Glassfish v2 (BPEL engine build _1) Unterstützter BPEL-Standard WS-BPEL 2.0 & BPEL4WS WS-BPEL 2.0 & BPEL4WS WS-BPEL 2.0 & BPEL4WS User-Interaction keine Unterstützung BPEL4People & Human Tasks BPEL4People & Human Tasks Integration in Entwicklungsumgebung (welche) ja (NetBeans) ja (activebpel Designer, aber kommerziell) ja (Intalio Designer) Funktionsumfang nur Grundfunktionen sehr mächtig sehr mächtig Bedienung sehr intuitiv (mittlere Einarbeitungszeit) mittelmäßig (hohe Einarbeitungszeit) überfrachtet (sehr hohe Einarbeitungszeit) 114

116 8.4 Untersuchung der Kommunikationseigenschaften von JEE zur Verfügung steht und einen Großteil des BPEL-Standards abdeckt. Außerdem implementiert 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 Kommunikationsplattform für die transformierte Geschäftssoftware. Da im vorangegangenen Arbeitspunkt die Java-Enterprise-Edition als Grundlage der Basisarchitektur der Zielsoftware ausgewählt wurde, konzentrieren sich die Betrachtungen in diesem Abschnitt auf Kommunikationslösungen zwischen Legacy-Software und JEE-Applikationsserver 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. Teile einer Legacy-Software über veraltete Protokolle angebunden sein, oder der Nachrichtenaustausch zwischen Softwareteilen wurde speziell für diesen Einsatz entwickelt. Verwendet 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 (JMS 5 ) bereit. JMS bildet eine einheitliche, standardisierte Schnittstelle zur Benutzung einer Message Oriented Middleware (MOM). Damit können Nachrichten asynchron und transparent zwischen verschiedenen Softwareteilen ausgetauscht werden. JMS bietet zwei Kommunikationsmuster. Bei der Point-to-Point-Kommunikation erstellt ein Producer eine Nachricht, die dann von einem Consumer aus der entsprechenden 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 Themenschlange gesendet werden. Durch die asynchrone und zeitlich entkoppelte Verarbeitung 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 untersuchen, zum anderen aber auch die Verwendung von JavaBeans innerhalb des Projekts 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

117 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks Ping pong, 2 Hosts, 100 MBit Ethernet 10 9 jms mpi 8 Durchsatz [MB/s] 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 Nachrichtenschlange 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 Glassfish 6 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 MPI 7 (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 zeitliche 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üssen 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 Kommunikationsprotokolle sind von der Ausgangssoftware abhängig. Im Fall von TransBS

118 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 Kundenzufriedenheit. Oft besteht der Wunsch, vertraute Oberflächen weiter zu verwenden. Das Hauptproblem dabei liegt in der Verbindung von neuen (Web-Interface) und alten Bestandteilen (GUI-Logik-Code, GUI-Bibliothek) des Programms. Hierzu können Techniken der EAI (Enterprise Application Integration) zum Einsatz kommen, die verschiedene Wege bietet (Bridging, Wrapping, Adapter), um ehemals autonome Programme miteinander zu verbinden [30]. Das ermöglicht den Datenaustausch der verschiedenen Systeme und erhöht damit die Effizienz des Gesamtsystems. Eine mögliche Konfiguration von GBware vor und nach der Transformation ist in Abbildung 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 lassen. Mit der CORBA-RMI-Bridge wäre man sehr nah an der Sprache Java, die auch vom Applikationsserver verwendet wird, da RMI Bestandteil des Java-Basisframeworks ist. Dadurch muss weniger Wrapper- und Adaptercode geschrieben werden, um diese Anbindung 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 Verwendung von unterschiedlichen Bibliotheken verschiedener Hersteller (CORBA-Implementierungen, 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 einfache GUI-Aktionen, mit viel Overhead verbunden. 117

119 8 Auswahl einer Infrastruktur zur Realisierung des Client-Server-Frameworks Abbildung 8.4: CORBA-JEE-Bridge 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 angebunden 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önnen. Nach genauerer Analyse der verschiedenen Kommunikationsmöglichkeiten bietet die Verwendung von CORBA die nötige Flexibilität und Robustheit, um einzelne Teile der Altsoftware auszulagern und sicher wiederzuverwenden. Dazu wurde eine Beispielapplikation erstellt, welche den Kommunikationspfad zwischen Delphi und Java exemplarisch implementiert. Eine mögliche Realisierung einer Delphi-JEE-Schnittstelle ist in Abbildung 8.4 dargestellt. 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

120 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 JacORB 8 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

121 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 vielen Unternehmen unterstützt und eingesetzt wird. BPEL bietet eine gute Grundlage, um Geschäftsprozesse zu automatisieren oder externe Services von Drittanbietern zu integrieren. Infolgedessen wurden verschiedene BPEL-Ausführungsumgebungen (Engines) miteinander verglichen, um weitere Tests für die prototypische Implementierung realisieren zu können. Die konkrete Wahl einer BPEL-Engine ist aber von den Voraussetzungen der Ausgangssoftware, den Kundenwünschen und eventueller Lizenzbeschränkungen (bspw. GPL 9 ) 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-Engines arbeiten dazu mit den JavaEE-Servern zusammen, welche die einzelnen Teilprozesse implementieren und als Webservices bereitstellen. Es wurden verschiedene Kommunikationsplattformen 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 Integration der alten oder neuen Softwarebestandteile über den JMS (Java Message Service), welche genauer untersucht wurde. Speziell für die im Projekt betrachtete Delphi-Software 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 erreichbare Java-Objekt Funktionsaufrufe und Daten an den JavaEE-Server weiter. 9 GNU General Public License, 120

122 9 Entwicklung und Realisierung des prototypischen Client-Server-Frameworks 9.1 Zielsetzung Nachdem die grundlegende Softwarearchitektur und die Kommunikationsplattform festgelegt wurden (siehe Kapitel 7 und 8), werden diese nun prototypisch anhand von Testszenarien 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 Prozesse 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 dargestellt. 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. Abschnitt 6.1.2). Das Werkzeug zur Erzeugung und Verarbeitung der abstrakten Softwarebeschreibung, TRANSFORMR, wurde in Kapitel 6 vorgestellt. Um die extrahierten Codeteile 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 Transformation, 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 definierten Muster gesucht, welches eine verteilte Ausführung des Codes ermöglicht. Hat man 121

123 9 Das Client-Server-Framework dieses Muster gefunden, kann es im nächsten Schritt durch ein Zielmuster ersetzt werden. Da u. U. nicht alle notwendigen Informationen für eine Auslagerung des Codes vorhanden sind, muss an dieser Stelle der Entwickler eingreifen und die entsprechenden 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 transformiert, dass einzelne Berechnungsfunktionen von einem Server via RMI automatisch angebunden werden. Des Weiteren zeigen wir die Integration dieser Mustertransformation in das Werkzeug TRANSFORMR Musterbasierte Quellcodetransformation Das Aufspalten von Software zur späteren parallelen Ausführung kann mit unterschiedlichen 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 transformiert 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 Software 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 anzuwenden. 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 implementieren. Der Vorteil einer solchen FSR-basierten Transformation liegt in der automatischen 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 Transformationsmöglichkeiten aufzeigen. Dies ist besonders hilfreich, wenn das Projekt Hunderte 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 Datenbank verfügbar seien. 122

124 9.2 Das CBFRAME-Remote-Adapter-Pattern Abbildung 9.1: Schematische Darstellung der schrittweisen Anwendung einer musterbasierten Transformation. 2. Das Transformationswerkzeug versucht dann, anhand der bekannten Muster mögliche Transformationen zur Anwendung anzubieten, von denen der Entwickler eine 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, dargestellt 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 unserem 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 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

125 9 Das Client-Server-Framework die JavaEE-Plattform als Kandidat für die Nutzung als CBFRAME-Basis herauskristallisiert. Ein Hauptaugenmerk des Transformationsvorhabens liegt auf der Erzeugung einer Client-Server-Anwendung aus einer ursprünglich nicht verteilt laufenden Applikation. Um dieses Ziel zu erreichen, wurde die automatische Einbettung von Klassen der Legacy-Software in die JavaEE-Plattform untersucht, wobei musterbasierte Transformationen eine tragende Rolle spielen. Eine Möglichkeit Software in eine Client-Server-Anwendung zu überführen, ist die Verwendung 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. Damit bleibt der aufrufende Code weitestgehend unverändert. Die Java-Plattform bietet die Remote Method Invocation (RMI) 1 an, um einen entfernten Methodenaufruf zu implementieren. Im folgenden Abschnitt wird gezeigt, wie Funktionen aus einer Legacy-Software herausgelöst werden können und wie diese mittels RMI auf einem entfernten Server zur Verfügung gestellt werden. Verwendet wird dazu der musterbasierte Transformationsansatz mit dem speziellen Transformationsmuster CBFRAME-Remote-Adapter-Pattern 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 vornehmen zu müssen. Der Großteil des benötigten Adaptercodes sollte sich automatisch generieren lassen. Das Auslagern von Funktionen bietet unterschiedliche Vorteile für eine 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 Berechnungen 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 Abbildung 9.2 dargestellt. Grafik 9.2(a) zeigt das notwendige Ausgangsmuster in der zu transformierenden Software und Grafik 9.2(b) stellt das zugehörige Zielmuster dar. Das Interface LegacyFeature enthält die Funktionen, die ausgelagert werden sollen, z. B. die Methode dowork(). Diese Funktionen werden von mindestens einer Klassen realisiert oder implementiert, hier angegeben als LegacyImplementation. Um die Implementierung 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

126 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üngliche 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 Aufrufkette 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 Transformation 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) Anwendung des CBFRAME-Remote-Adapter-Pattern Nach Erarbeitung des Transformationsmusters wurde ein Prototyp eines Transformationswerkzeugs implementiert. Die Arbeitsweise des Transformationswerkzeugs ist schematisch in Abbildung 9.3 dargestellt. Das Werkzeug arbeitet auf dem Quellcode der Ausgangssoftware (Legacy-Quellcode). Des Weiteren benötigt jedes Transformationsmuster zur Umsetzung eine gewisse Zahl an Code-Templates, um die Ausgangsklas- 125

127 9 Das Client-Server-Framework Abbildung 9.3: Anwendung des CBFRAME-Remote-Adapter-Pattern zur automatischen Auslagerung von Methoden auf entfernte Server. sen anzupassen. Außerdem sind Konfigurationsdateien notwendig, die musterspezifische 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, Parameterliste), 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 Ursprungsprogramms bearbeiten. Abbildung 9.4 zeigt ein Beispiel-Template eines Serverprogramms, das Funktionen via RMI bereitstellt. Die Variablen, die mit «..» gekennzeichnet sind, dienen als Platzhalter und werden vom Transformationswerkzeug mit konkreten Werten ersetzt. Neben 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 Benutzeroberfläche, welche verschiedene Fraktal-Implementierungen, wie z. B. eine Mandelbrot-Menge, berechnet und anzeigt. Es wurde untersucht, wie diese Applikation umzugestalten ist, damit eine Auslagerung von Funktionalität auf den Server realisiert werden 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-Implementierungen von einem anderen Serverrechner durchgeführt wird. Wichtig dabei ist, dass der Ur- 126

128 9.2 Das CBFRAME-Remote-Adapter-Pattern package <<TargetPackage>> ; import j a v a. i o. I OException ; import j a v a. rmi. AlreadyBoundException ; import j a v a. rmi. RemoteException ; import j a v a. rmi. r e g i s t r y. L o c a t e R e g i s t r y ; import j a v a. rmi. r e g i s t r y. R e g i s t r y ; import j a v a. rmi. s e r v e r. U n i c a s t R e m o t e O b j e c t ; <<Imports>> p u b l i c c l a s s <<RemoteLegacyFeatureProvider>> implements I M a n d e l b r o t R e m o t e C a l c u l a t o r { p r i v a t e < < L e g a c y F e a t u r e P r o v i d e r > > <<LegacyFeatureImplVar>> = new < < L e g a c y F e a t u r e P r o v i d e r > > ( ) ; p u b l i c <<RemoteLegacyFeatureProvider>> ( ) { } < < R e m o t e I n t e r f a c e I m p l e m e n t a t i o n > > p u b l i c s t a t i c void main ( S t r i n g [ ] a r g s ) { t r y { <<RemoteLegacyFeatureProvider>> s e r v e r = new <<RemoteLegacyFeatureProvider>> ( ) ; R e m o t e P r o p e r t i e s p r o p s = new R e m o t e P r o p e r t i e s ( ) ; <<LegacyRemoteInterface>> s t u b = ( <<LegacyRemoteInterface>> ) U n i c a s t R e m o t e O b j e c t. e x p o r t O b j e c t ( s e r v e r, p r o p s. g e t I n P o r t ( ) ) ; R e g i s t r y r e g i s t r y = L o c a t e R e g i s t r y. g e t R e g i s t r y ( p r o p s. getservername ( ) ) ; r e g i s t r y. bind ( " <<RmiObjectId>> ", s t u b ) ; } } } catch ( E x c e p t i o n e ) { System. e r r. p r i n t l n ( e. getmessage ( ) ) ; } Abbildung 9.4: Beispiel eines Templates zur automatischen Erzeugung eines Serviceanbieters auf Serverseite (RMI). sprungscode möglichst wenig Änderungen erfährt. Im besten Fall sollte nur die Instantiierung der Legacy-Klasse ausgetauscht werden müssen. Das Ergebnis einer solchen Transformation ist in Abbildung 9.5 zu sehen. Der Screenshot zeigt das bereits transformierte 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 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 Anwendbarkeit überprüft und getestet. Sogenannte Template Engines ermöglichen die Er- 127

129 9 Das Client-Server-Framework Abbildung 9.5: Screenshot des erzeugten Client/Server-Programms zur Berechnung eines 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 Adressen in Seriendokumenten sein. Die Velocity-Engine der Apache Foundation war dabei am leichtesten und flexibelsten zu verwenden. Apache Velocity ermöglicht darüber hinaus mehr Funktionen als das in Abschnitt 6.4 beschriebene Ersetzungwerkzeug zur Code-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 zugegriffen werden können. Darüber hinaus bietet Velocity Sprachmittel wie Conditionals und Schleifen, womit die Code-Generierung besser strukturiert werden kann. Die Abbildung 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

130 9.2 Das CBFRAME-Remote-Adapter-Pattern package $remote. g e t ( TargetPackage ) ; import j a v a. rmi. Remote ; import j a v a. rmi. RemoteException ; p u b l i c i n t e r f a c e $remote. g e t ( LegacyRemoteInterface ) extends Remote { # f o r e a c h ( $ i n t e r f a c e i n $ i n t e r f a c e s ) # m e t h o d A u t o m a t i c a l l y G e n e r a t e d ( ) # makeremotemethodsignatur ( $ i n t e r f a c e "$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 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 werden. Mit dem beschriebenen CBFRAME-Remote-Adapter-Pattern können ausgewählte 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 erweitert werden. Webservices werden über eine standardisierte Schnittstellenbeschreibung (Web Service Description Language, WSDL 2 ) verfügbar gemacht. Diese XML- Beschreibungssprache deklariert Schnittstelle und Übergabeparameter, sowie die möglichen Übertragungsprotokolle, um auf den Webservice zuzugreifen. Dadurch sind Webservices flexibler einsetzbar als RMI-Aufrufe, welche eine Java-Umgebung voraussetzen. 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 angewendete 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

131 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 Routinen 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üngliche 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 Funktion auf einen Webserver verbunden? Im Experiment wurde die Funktion aus Abbildung 9.9 als Webservice angeboten. Als Webservice-Provider wurden hierzu Tomcat als Application-Server und Axis2 4 als Webservice-Engine verwendet. Außerdem wurde diese Funktionalität nativ (in C) realisiert 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 Webservice zeigte sich, dass zum Auslagern der Funktion als Webservice im Vergleich zu RMI

132 9.3 Effiziente verteilte Workflow-Abarbeitung f l o a t c e l s i u s T o F a r e n h e i t ( 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 generellen 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 lokalen 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 entscheidende Rolle spielt. Tabelle 9.1: Vergleich der Antwortzeiten einer Funktion für unterschiedliche Kontexte. Art der Messung Aufruf als einfache Java-Funktion Aufruf als native C-Funktion aus Java via JNI Aufruf des Webservices aus Java (1 GBit Ethernet, 2 Hops) mittlere Antwortzeit [ms] 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 Problemstellung und Ziele Für die betrachteten Workflows wurde in Abschnitt 8.2 BPEL als Modellierungssprache ausgewählt. BPEL Workflows orchestrieren üblicherweise eine Reihe von externen Diensten (z. B. Webservice). Ein externer Dienst kann von verschiedenen Anbietern 131

133 9 Das Client-Server-Framework Abbildung 9.10: Workflowabarbeitung mit räumlich verteilten, redundanten Dienstanbietern (Providern). bereitgestellt werden. Die Dienstanbieter (Provider) sind durch Nutzung des Internets oftmals räumlich verteilt. Darüber hinaus können externe Dienste durch mehrere redundante Anbieter bereitgestellt werden, um beispielsweise eine gestiegene Anzahl von Anfragen bearbeiten zu können oder eine hohe Verfügbarkeit zu sichern. Im vorangegangenen 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 Anbieter 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önnen, bedarf es einer Lastbalancierungsstrategie. Hierbei ist zu beachten, dass verschiedene 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 Mindestdienstgü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 Auslastung zur Laufzeit eventuell nicht zur Verfügung. Deshalb beschränkt sich das nachfolgend vorgestellte Verfahren auf die Auswertung von Informationen, die die Workflow- 132

134 9.3 Effiziente verteilte Workflow-Abarbeitung Abbildung 9.11: Der Ausgangs-Workflow (oben) und der transformierte Workflow (unten) 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 vorhanden 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 dynamisch anpassbar sein. Zielsetzung ist es, die vorhandenen BPEL-Workflows nicht neu schreiben zu müssen, sondern eine automatische Transformation des BPEL-Prozesses zu realisieren Automatische Transformation von BPEL-Prozessen In [21] wurde im Rahmen von TransBS ein Verfahren entwickelt, welches es ermöglicht, 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

135 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 wurde 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 Erweiterungen integrieren. Der gegebene BPEL-Prozess wird automatisch transformiert, indem vorhandene Webservice-Aufrufe von Aufrufen zur Scheduling-Funktion der Workflow-Engine eingeschlossen werden. Dies ist in Abbildung 9.11 für einen BPEL-Prozess mit zwei Webservice-Aufrufen dargestellt. Der vorherige Scheduler-Aufruf liefert den zur Ausführung 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 Webservice-Addressing-Spezifikation (namespace wsa 5 ) verwendet. Weitere Informationen sind unter dem Kapitel Making BPEL Processes Dynamic in [10] zu finden. Im transformierten BPEL-Prozess (Abbildung 9.11 unten) werden verschiedene Webservice- Anbieter für die beiden Aufrufe genutzt Lastverteilungsverfahren für BPEL-Prozesse Die modifizierten BPEL-Prozesse wurden auf einer activebpel-engine in verschiedenen 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 Antwortzeiten 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 ausgewählt. Weighted Random (WR) Die Webservice-Aufrufe werden zufällig verteilt. Dabei sind die Auswahlwahrscheinlichkeiten der einzelnen Anbieter nach der Dauer des letzten Aufrufs ge

136 9.3 Effiziente verteilte Workflow-Abarbeitung Average execution time [s] (200 ms web service call duration) 2 LCF 2 RR 2 WR 4 LCF 4 RR 4 WR static Average execution time [s] (200 ms web service call duration) 2 LCF 2 RR 2 WR 4 LCF 4 RR 4 WR static # BPEL processes # BPEL processes Abbildung 9.12: Durchschnittliche Ausführungszeit eines BPEL-Prozesses mit 10 Webservice-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 Anzahl gleichzeitiger Aufrufe. In Abbildung 9.12 sind die gemessenen Ausführungszeiten 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 erwartungsgemäß 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 gleichzeitige Aufrufe stets der langsamste Anbieter ausgewählt wird, da hier zwar die momentane 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 gleichzeitig ausgeführter BPEL-Prozesse gut geeignet, jedoch bleibt sie oft etwas hinter der 135

137 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 erforderliche 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 vorangegangenen 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 herausgestellt. 9.4 Zusammenfassung Ziel war es ein Framework zu entwickeln, welches die verteilte Ausführung von Geschäftsprozessen ermöglicht. Um eine Verteilung zu erreichen, wurde eine musterbasierte 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 Muster im Quellcode zu finden. Die Fähigkeit zur automatischen Auslagerung von Funktionalität wurde in TRANSFORMR integriert. Dabei wird der auszulagernde Quellcode über Adapter angebunden. Anhand einer Fallstudie wurde die Leistungsfähigkeit des Verfahrens ü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 Modellierung ausgewählt. Dabei spielte auch die leichte Anbindung externer Dienste (Webservices) an BPEL Prozesse eine Rolle. Um die Performance und Ausfallsicherheit eines Softwaresystems zu erhöhen, wurde die Nutzung redundant ausgeführter Dienste vorgeschlagen. Um dies zu unterstützen, wurde eine Transformation für BPEL-Prozesse entwickelt, 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 Gesamtperformance des Softwaresystems erreichen lässt. 136

138 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 Plattformunabhä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 ausgereifte Kopplung von Sprache und IDE (Delphi Professional) im Gegensatz zu Java eine standardisierte Möglichkeit (Rapid Application Development) in kurzer Zeit anspruchsvolle Anwendungen und ihre Anbindung an Datenbanken zu realisieren 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 inbesondere in der Ausgangssprache verwendete Sprachkonzepte, die in der Zielsprache nicht vorhanden sind, zu Problemen führen. Im gemeinsamen abstrakten Softwaremodell müssen daher alle Sprachkonzepte angemessen repräsentiert werden. Das Sprachkonzept von Delphi bietet, anders als Java, auf Grund der Abwärtskompatibilität zu Borland Pascal die Möglichkeit zur Mischung von objektorientierter und prozeduraler Programmierung. In Java müssen dagegen alle Methoden und Variablen einer Klasse zugeordnet werden. Delphi unterscheidet in der Grammatik der Sprache zwischen einem Deklarationsteil (interface), in welchem öffentlich verfügbare Klassen und Attribute definiert werden, und einem Realisationsteil (implementation), der die entsprechenden 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 entsprechend 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 integriert ist, kann dabei nur über Frameworks (z. B..NET-Framework) realisiert werden. 137

139 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 unterschiedlichen Namespaces) und genutzten Bibliotheken, die als Package (Komposition von Units mit verfügbarem Programmcode oder als Dynamic Link Library (DLL) kompiliert) oder Library (nur als DLL kompiliert) verfügbar sein können. Der Programmmcode einer Delphi Unit wird dabei in einer separaten Datei gespeichert. Das Hauptprogramm 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 verwendet. 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

140 10.1 Prototypische Analyse und Transformation mit TRANSFORMR Tabelle 10.1: Zuordnung von Elementen einer Delphi Unit zu Modellelementen der FSR. Delphi Programm Element namespaces unit interface class interface class method interface class variable interface method interface variable implementation class implementation method implementation variable FSR Element SubSystem structure (static) Module (static) Submodule Submodule method Submodule member variable (static) Procedure (static) Variable (inner) Module (private static) Procedure (private static) Variable Instanz des übergeordneten Moduls gebunden sind, sondern unabhängig davon aufgerufen 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 eines 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 Transformation von Delphi-Programmcode sowie ein Code Model (siehe Abbildung 5.3, Seite 61) zur Referenzierung des Programmcodes aus dem Softwaremodell. Dabei können bestehende 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ändigkeit der verwendeten Grammatik für Delphi zur Analyse und Transformation von Programmcode mit TXL und auf die Entwicklung von TXL-Transformationsregeln zur Extraktion der FSR gelegt. Die verwendete Grammatik wurde auf Basis einer für TXL verfügbaren Grammatik für Borland Delphi 2006 entwickelt. Durch die Weiterentwicklung konnten auch Abweichungen zwischen dem Delphi-Compiler und der Sprachspezifikation in die Grammatik eingebracht werden, da einige der verwendeten Eingabedaten 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 Programmcode aufbauen. Besonders aufwändig stellte sich die Zuordnung der Methodendeklarationen im interface-abschnitt zu den von Methodenrümpfen im implementati- 139

141 10 Prototypische Transformation der Referenzsoftware GBware Abbildung 10.2: UML-Klassendiagramm eines Ausschnitts des betrachteten Programmcodes. on-abschnitt der Unit dar, da in TXL eine eindeutige Identifikation von Methoden anhand von Methodensignatur und Elternknoten (Klassen, Units) im abstrakten Syntaxbaum nur umständlich realisiert werden kann. Prototypische Anwendung auf GBware Für eine detaillierte Untersuchung wurde der Programmcode einer GBware Nutzerschnittstelle (Abbildung 10.8) ausgewählt, die zur Erstellung oder zur Änderung eines Auftrags verwendet wird. Sowohl der Programmcode zum Aufbau der Nutzerschnittstelle 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 Transformationsregeln durchgeführt werden konnte. Abbildung 10.2 zeigt den Ausschnitt eines UML-Klassendiagramms als eine beispielhafte Visualisierung des betrachteten Programmcodes. Da in Delphi Groß- und Kleinschreibung nicht unterschieden wird, wurden alle Bezeichner während der Transformation in die FSR normalisiert (Anfangsbuchstabe 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 Erstellung aller grafischen Ansichten), ist die Nutzung vieler Hilfsmodule, die nur sporadisch verwendet werden (nur wenige Zugriffe auf ihre Membervariablen oder -Funktionen) 140

142 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 vieler 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 Anwendung von TRANSFORMR auf TurboCASH TurboCASH ist ein Open Source Buchhaltungssystem für kleine Unternehmen bzw. Einzelunternehmen unter der GPL 1. Es wurde seit 1985 zunächst als kommerzielle Software entwickelt und ist seit Juli 2003 frei verfügbar. Es besitzt eine Vielzahl von Komponenten wie Einkauf, Verkauf, Kontoführung, Lagerhaltung, Steuerverwaltung, Rechnungsmanagement, Kontensynchronisation, Module für Reporting und Analyse von Daten, 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 Engine (BDE), eine Paradox Datenbank, verwendet. Ab Version 4 wird die freie Datenbank Firebird 2 genutzt, die überwiegend konform zum SQL-2003 Standard ist. Durch die Verwendung der Datenbank Firebird kann TurboCASH auch als Multi-User-System betrieben werden, indem verschiedene TurboCASH Installationen auf unterschiedlichen Clients auf eine gemeinsame Datenbank zugreifen. Zur vollständigen Übersetzung des Programmcodes von TurboCASH in eine ausführbare Software, werden einige proprietäre Bibliotheken (z. B. Delphi 7 Professional oder Quick Reports), bedingt durch die langjährige kommerzielle Entwicklung, benötigt. Eine 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 Lazarus 3. Abbildung 10.3 zeigt eine Bildschirmmaske von TurboCASH. Über die Toolbar und die Menuleiste sind im hinteren Fenster die verfügbaren Module abrufbar. Über diese 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öglichkeiten 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. 1 General Public Licence, Open Source Entwicklungsumgebung für Delphi mit freien Bibliotheken 141

143 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 vorhandenen 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 eigneten sich nur die Dateien mit den Endungen dfm (zur UI-Transformation, siehe Abschnitt 10.2), dpk, dpr, pas und inc. Bei der eingehenden Analyse stellten die Abhängigkeiten zu proprietären Komponenten eine Schwierigkeit dar, da eine Übersetzung des Gesamtsystems ohne diese Komponenten nicht möglich war. Trotz der Schwierigkeiten 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 Transformationsregeln 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 identifiziert. 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 Methoden zur Bildung von Modulen und expliziten Schnittstellen (siehe Abbildung 10.1) wurden kaum verwendet, was zu einer starken Kopplung aller in der Dokumentation genannten Komponenten von TurboCASH führt. Eine Extraktion oder auch der Austausch 142

144 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 verarbeitet 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 zugehö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 oder RTF-Format (manuelle 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. Entwicklungsumgebung (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 somit voraussichtlich nur mit großem manuellen Aufwand möglich. 143

145 10 Prototypische Transformation der Referenzsoftware GBware Abbildung 10.4: Screenshots der Analyse von TurboCASH mit TRANSFORMR. Links: Hauptfenster von TRANSFORMR mit Package- und Modulstruktur. 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-Nutzerschnittstellen ausgewertet werden Prototypische UI-Transformation von GBware 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 Transformation von Delphi nach Java gelegt. Aus diesem Grund konzentrierten sich die Arbeiten auf die automatische Extraktion der GUI, wobei Delphi als Quellsprache und 144

146 10.2 Prototypische UI-Transformation von GBware Tabelle 10.3: Freie Projekte zur Generierung der grafischen Benutzeroberfläche für Java. Beschreibung Java GUI Designer Java GUI Builder SWIXML Laufzeitbibliothek und Codegenerator Aktualität eingestellt eingestellt aktuell Editor mit Codegenerator Beschreibungsformat Codegenerierung/ Laufzeitgenerierung ini xml xml ja/nein ja/ja nein/ja Dokumentation schlecht gut gut Flexibilität wenige Swing Widgets beliebige möglich Klassen Laufzeitbibliothek Swing 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öglichkeit, die grafische Oberfläche (beispielsweise durch Layoutanpassungen) zu verändern, und bildet die Ausgangsbasis zur Codegenerierung. Einige Entwicklungsumgebungen zur Generierung von grafischen Benutzeroberflächen (beispielsweise NetBeans oder JFormDesigner) verwenden ebenfalls eine Zwischendarstellung der Benutzeroberfläche zur Codegenerierung. Ein weiterer Aspekt dieser universellen Darstellung ist die damit verbundene Möglichkeit eine Ansicht der Benutzeroberfläche direkt aus der universellen 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 Spezifikation der abstrakten Darstellung der GUI im XML-Format nicht offenlegen, wurden freie Werkzeuge und Bibliotheken untersucht, um eine passende Plattform für die Transformation von Delphi nach Java zu finden. Tabelle 10.3 zeigt die Eigenschaften der näher betrachteten Projekte Java GUI Designer 4 (JGUID), Java GUI Builder 5 (JGB) und SWIXML 6. Bei der Auswahl wurde vor allem auf gute Erweiterbarkeit und Dokumen

147 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 generieren ist zur Nach- und Weiterbearbeitung der grafischen Oberfläche nützlich 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-Dateien (*.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 gliedert sich in die Transformation der Logik (.pas ) 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

148 10.2 Prototypische UI-Transformation von GBware <GUIRoot> <Form1 C a p t i o n =" Form1 " Color =" c l B t n F a c e " Font. C h a r s e t ="DEFAULT_CHARSET" Font. Color =" clwindowtext " Font. H e i g h t =" 13" Font. Name=" Tahoma " Font. S t y l e =" [ ] " H e i g h t =" 328 " L e f t =" 0 " O l d C r e a t e O r d e r =" F a l s e " P i x e l s P e r I n c h =" 120 " T e x t H e i g h t =" 16 " Top=" 0 " Type=" TForm1 " Width=" 475 "> <Label1 C a p t i o n =" Label1 " H e i g h t =" 49 " L e f t =" 296 " Top=" 64 " Type=" TLabel " Width=" 113 " /> <Edit1 H e i g h t =" 24 " L e f t =" 96 " TabOrder=" 0 " Text =" E d i t 1 " Top=" 64 " Type=" TEdit " Width=" 153 " /> <Button1 C a p t i o n =" Button1 " H e i g h t =" 33 " L e f t =" 200 " OnClick=" B u t t o n 1 C l i c k " TabOrder=" 1 " Top=" 200 " Type=" TButton " Width=" 81 " /> </Form1> </GUIRoot> 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 allgemeine Beschreibung konvertiert, welche in der Abbildung als Intermediate XML bezeichnet ist. Ein Beispiel der Zwischendarstellung der grafischen Oberfläche des ursprü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 Transformation 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 Standardbibliothek 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 Laufzeit 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 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

149 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 Ziellayout 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 Programmcode 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 Ergebnis 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 (beispielsweise Grafiken auf Buttons). Für die Nachbearbeitung der generierten grafischen Oberfläche (beziehungsweise des Quellcodes) ist eine Werkzeugunterstützung wünschenswert. 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 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. Werden 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 Zielplattformen entsprechende Gegenstücke. Schwieriger ist es, komplexe Elemente wie Tabellen 148

150 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 Transformationsroutinen bereitgestellt werden, die die Aufgabe im konkreten Fall lösen. Für individuelle GUI-Widgets in der Quellsprache muss ebenfalls eine Entsprechung in der Zielsprache gefunden werden und die zugehörigen Transformationsroutinen müssen erstellt werden Evaluierung von Kunden-Workflows Am Beispiel des Workflows zur Erstellung einer Rechnung wurde die Extraktion eines 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