Werkzeuge des Continuous Engineering

Transkript

1 Michael Löwe Fachhochschule für die Wirtschaft, Hannover Zusammenfassung Dieses Skript versucht nicht, einen enzyklopädischen Überblick über die derzeit verfügbaren Werkzeuge zum Forward-, Reverse- und Reengineering zu geben. Die Vielfalt ist zu groß. Zudem sind viele Werkzeuge an bestimmte Technologien (z. B. Fortran oder Cobol) gebunden und dadurch ohne spezielle Vorkenntnisse nur schwer zu verstehen und zu beurteilen. Wir wollen uns dem Thema vielmehr aus Sicht des Software-Entwicklers nähern, der heutzutage damit konfrontiert ist, seine Projekte über sehr lange Zeiträume an sich schnell ändernde technische und fachliche Anforderungen anpassen zu müssen. Für dieses Szenario sollte eine Arbeitsumgebung eine Vielzahl von unterstützenden Werkzeugen bereithalten, die zum großen Teil noch nicht verfügbar sind. Dieses Skript soll deutlich machen, wie diese Werkzeuge beschaffen sein müssen und wie man sie herstellen kann, wenn am Markt ein entsprechendes Angebot nicht zu finden ist. Als Seiteneffekt führt das Skript in eine Vorgehensweise zur Software Entwicklung - dem Continuous Engineering - ein, die die Schlagworte Modell-getriebene Software-Entwicklung, Meta-Modellierung und Programm- und Systemgenerierung verbindet. Wir setzen dabei voraus, dass Software-Entwicklung heutzutage gleichbedeutend ist mit Objektorientierter Analyse, Objektorientiertem Entwurf und Objektorientierter Programmierung. Als Modellierungssprache benutzen wir UML2. Alle Programmtransformationen werden mit Hilfe einer programmiersprachlichen Notation, die sich weitgehend an der Syntax und Semantik von Java orientiert, illustriert. Eine Übertragung in ähnliche objektorientierte Sprachen wie C# oder C++ ist einfach möglich.

2 - 2 - Inhalt Software Engineering...3 Forward Engineering...4 Beispiel: Beseitigung von Mehrfachvererbung...5 Beispiel: Beseitigung zyklischer Benutzungen...6 Beispiel: Einführung von Rollen...7 Reverse Engineering...9 Continuous Engineering...10 Das ideale Vorgehensmodell...12 Round-Trip Entwicklung...12 Die Renaissance des Wasserfalls...13 Beispiel: Optimierung einer Stückliste...14 Entwicklungsspuren...17 Automatisierung...19 Systemgenerierung...21 Benutzeroberflächen...22 Anzeige von Modellobjekten...22 Controller-Fassaden...24 Allgemeines Ereigniskonzept...26 Generierte Oberflächen...28 Mehrbenutzerfähigkeit...30 Pessimismus...30 Noch mehr Pessimismus...32 Strenge Serialisierung...33 Optimismus...35 Persistenz...40 Relationale Schemata für Objektmodelle...41 Typen, Objekte, Assoziationen und Links...41 Spezialisierung...43 Meta-Modell...46 Anbindung einer Relationalen Datenbank an das Fachsystem...48 Transaktionssicherheit...52 Verteilung...54 Metamodellierung...54 Daten und Werte...54 Operationen und Methoden...54 Der Werkzeugkasten...54

3 - 3 - Software Engineering Die derzeitige Software-Entwicklung unterscheidet sich sehr stark von den Herangehensweisen am Ende des letzten Jahrhunderts. Sind früher die Systeme auf der grünen Wiese entwickelt worden, gibt es heute kaum noch ein neues System, das kein bereits vorhandenes Altsystem (Legacy System) ersetzen soll. Das bedeutet unter anderem, dass große Datenbestände übernommen werden müssen, dass alle Schnittstellen in umliegende Systeme (z. B. Statistiken, Datenkaufhaus, Elektronischer Datenaustausch) weiter versorgt werden müssen und dass die Benutzer bereits Arbeitstechniken mit dem alten System herausgebildet haben, die ggf. umgestellt werden müssen. Erfahrungen aus der Praxis zeigen 1, dass der Kostenaufwand für den Ersatz eines 10 bis 20 Jahre alten Systems sich zu gleichen Teilen (1) auf die eigentliche Entwicklung, (2) auf die Integration mit den Randsystemen, (3) die Migration der Daten und (4) die Einführung und Schulung verteilt. Das bedeutet, dass lediglich 25% der Kosten in der Entwicklung des Neusystems verbraucht werden. Hingegen werden 75% aufgewendet, um das Gesamtsystem (technisches und soziales Umfeld) auf den neuen Stand zu bringen. Diese Kostenverteilung zeigt, dass die technischen und fachlichen Unterschiede zu groß sind, wenn Systeme komplett alle 10 bis 20 Jahre ersetzt werden. Warum müssen Systeme überhaupt ersetzt werden? Warum kann ein System nicht kontinuierlich so weiter entwickelt werden, dass es stets in jeder Hinsicht auf dem Stand-der-Kunst ist. Die wichtigsten Gründe sind hier bei den Entwicklern selbst zu suchen und zu finden. Sie entwickeln in dem Bewusstsein, dass ihre Systeme nicht für die Ewigkeit sein werden. Das beste Beispiel dafür war das große Problem mit der Datumsdarstellung am Ende des letzten Jahrtausends. Obwohl in modernen Betriebs- und Datenbanksystemen bereits korrekte Abbildungen der Zeit und des Datums seit den achtziger Jahren zu finden waren, sind die eigenen Datumsformate nicht umgestellt worden. Denn das System funktionierte ja und ein Auftrag zur Änderung existierte nicht. Andere Aufträge zur Änderung und Anpassung waren vorhanden und dringender. Deswegen wurde das Problem solange ausgeblendet, bis es schließlich mit Nachdruck und unter hohem Kostenaufwand viel zu spät vom Management erkannt und angegangen wurde. Dieses Bewusstsein der Entwickler und auch der verantwortlichen Leiter führt dazu, dass viele Änderungen und Anpassungen mit minimalem Aufwand umgesetzt werden, wenn das System erst einmal im Einsatz ist. Werden alte Entwurfsentscheidungen durch neue notwendige fachliche oder technische Anpassungen konterkariert, wird in aller Regel nicht zunächst ein komplettes Redesign durchgeführt und danach die eigentliche Änderung eingepasst. Die Kosten scheinen zu hoch. Stattdessen wird mit einigen Tricks der gewünschte Effekt im alten Entwurf herbeigeführt. Auf die nötige Dokumentation solcher schmutzigen Tricks wird weitgehend verzichtet, da man sich damit nicht mit Ruhm bekleckern kann. Alle weiteren Anpassungen werden dadurch doppelt schwer. Auf diese Weise verkommt das System, Änderungen werden immer schwieriger und Fehlfunktionen nehmen zu. Aus diesem Grund muss nach einigen Jahren über den kompletten Ersatz nachgedacht werden. Ist der Entwickler an allem schuld? So, wie es oben dargestellt wurde, schon! Aber hat er überhaupt eine Chance? Wie wird er motiviert, komplizierte Redesigns vorzunehmen, wenn es nötig wird? In den meisten Fällen gar nicht. Indizien dafür sind: 1. Fehlende Schulungen in neuen Technologien, die z. B. für einen Plattformwechsel nötig sind. Die Entwickler, die sich um ein System im Betrieb kümmern, sind in der Betriebsund Entwicklungstechnik dieses Systems meist sehr versiert und schnell. In anderen Technologien haben sie meist Defizite. Deswegen scheuen sie einen Wechsel. 1 Erfahrungen des Autors aus einer Vielzahl von Neuentwicklungsprojekten bei einem der größten Deutschen Versicherungsunternehmen.

4 Fehlende Budgets. Der Erfolg eines Systems bemisst sich meist nach der Anzahl der Änderungen pro Jahr, die es verkraftet. Zeit für notwendige Entwurfsverbesserungen zählt hier nicht sofort. Und die errungenen Möglichkeiten für die Zukunft werden heute nicht gemessen. 3. Fehlende Perspektive. Häufig ist klar, dass es ein Folgesystem geben wird. Und es ist auch klar, dass dieses System mit Hilfe von neuen jungen Leuten - meist Beratern - entwickelt wird. Die Wartungsknechte am Altsystem werden dadurch nicht motiviert. Obwohl also klar ist, dass der Markt sowohl für eine kontinuierliche Veränderung der fachlichen Anforderungen als auch der technischen Grundlagen sorgen wird, sind die Entwicklungsmannschaften (Management und Entwickler) für Software-Systeme noch nicht auf die ständige Bereitschaft zur Veränderung eingestellt. Veränderung wird häufig als lästig empfunden und nicht als Chance begriffen. Continuous Engineering hingegen begrüßt Veränderung als Impuls für Verbesserung. Der erste Grundsatz des Continuous Engineering ist daher: CE1: Jede Veränderung ist die Chance für Verbesserung! Ein wesentlicher Grund, warum diese häufig auftretenden Chancen nur allzu selten genutzt werden, ist das Fehlen adäquater Werkzeuge. Zwar hat sich gerade im Bereich der Refaktorisierungen in der letzten Zeit eine Menge getan. So verfügen heute viele Integrierte Software-Entwicklungsumgebungen auch über komplexe Möglichkeiten der Semantik-erhaltenden Umstrukturierung (vgl. zum Beispiel Eclipse). Wir werden aber unten sehen, dass dieses Angebot bei weitem nicht ausreicht für die komplizierten Aufgabenstellungen, die im Continuous Engineering auftreten. Als Grundlage für diese Erkenntnis müssen wir zunächst die Begriffe Forward Engineering, Reverse Engineering und Continuous Engineering genauer fassen und von einander abgrenzen. Forward Engineering Mit dem Begriff Forward Engineering bezeichnen wir alle Aktivitäten, die ein erstes abstraktes Modell eines Anwendungssystems schrittweise in ein lauffähiges System überführen. Viele Schritte des Forward Engineering sind bereits vollständig automatisiert. Das beste Beispiel ist der Java-Compiler von Sun, der syntaktisch und semantisch korrekte Quellprogramme in Java ohne manuelles Dazutun in äquivalenten Java Virtual Machine Code übersetzt, der auf den meisten Plattformen unmittelbar ablauffähig ist. Niemand kommt heute noch auf die Idee, in dem erzeugten Code Veränderungen vorzunehmen, zum Beispiel zur Steigerung der Performanz. Das überlässt man dann doch lieber dem Just-in-Time-Compiler 2, ein weiteres vollautomatisches Werkzeug des Forward Engineering. Aber natürlich geht nicht alles automatisch. Das Hinzufügen einer Persistenzschicht in einer relationalen Datenbank, einer Transaktionsicherung für bestimmte Funktionen oder einer Ver- System 1 System 2 System 3 System 4 System 5 System 6 System 7 System 8 System 9 Abbildung 1: Forward Engineering 2 Dieser Compiler übersetzt zur Laufzeit häufig benutzte Passagen des Java Virtual Maschine Codes in nativen Assembler Code der Zielmaschine. A n a l y s e E n t w u r f R e a l i s i e r u g

5 - 5 - teilungsstruktur ist so komplex, dass derzeit keine vollautomatischen Werkzeuge auf dem Markt sind. 3 Aber egal ob automatisch oder manuell, Forward Engineering umfasst stets die Aktivitäten, die ein System von einer abstrakteren Ebene in eine konkretere, System-nähere Ebene überführen, vgl. Abbildung 1 4. Die Automatik nimmt zu, je näher man der Systemebene kommt. Aber auch beim Übergang vom Entwurf in die Realisierung gibt es Entwicklungsschritte, die (noch) nicht automatisch erledigt werden. Beispiel: Beseitigung von Mehrfachvererbung Ein gutes Beispiel für eine solche Situation ist die Beseitigung von Mehr- A IA this fachvererbung, wenn als Zielsprache Java zum Einsatz kommen soll. Java <<extends>> <<implements>> ist nicht in der Lage direkt mit Mehrfachvererbung umzugehen. Der beste B B A Weg, mit dieser Situation umzugehen mya ist, eine Vererbung durch Delegation zu simulieren. Das entsprechende Abbildung 2: Vererbung durch Delegation Muster ist in Abbildung 2 dargestellt. Die Vererbung wird durch eine Schnittstellenimplementierung und eine Assoziation simuliert. Dazu wird aus der Oberklasse A die Schnittstelle IA herausgezogen. 5 Zu der Schnittstelle von A gehören alle öffentlichen Operationen und alle protected Operationen, die von B gerufen werden. Die Klasse A implementiert natürlich alle Operationen von IA durch die vorhandenen Methoden. Die Klasse B implementiert die Operationen aus der Schnittstelle IA, für die es keine eignen Methoden (Überschreibung) besitzt 6, durch Delegation an sein A-Object mya. Dieses Objekt muss im Konstruktor von B erzeugt werden und steht dann zur Nutzung durch genau ein B-Objekt zur Verfügung (Komposition) 7. Der Delegationscode für eine Operation T op(t1 x1,...,tn xn) aus der Schnittstelle IA ist gegeben durch den Ausdruck return this.mya.op(x1,...,xn). Das Muster wirft zwei Probleme auf: 1. Durch die Verteilung der Methoden auf zwei Objekte ist die Identität gespalten. Jedes B-Objekt hat nicht nur seine B-Identität sondern auch die Identität seines A-Objekts. Das heißt this bedeutet je nach Kontext mal ein Objekt vom Typ B und mal ein Objekt vom Typ A. 2. Die Klasse A muss konkret sein, weil nach der Transformation Objekte dieser Klasse erzeugt werden. Zur Lösung des zweiten Problems bei einer abstrakten Klasse A muss A zunächst weiter zerlegt werden. Wir benötigen nicht nur die gesamte Schnittstelle IA sondern auch den Teil IAM dieser Schnittstelle, für die A Methoden besitzt. 8 Die ursprüngliche abstrakte Klasse A wird dann zu einer konkreten Klasse A', wenn wir sie nur noch die Schnittstelle IAM implementieren lassen. Diese Transformation ist in Abbildung 3 dargestellt. Das Attribute mya der transformierten Klasse B er- 3 Wir werden weiter unten diskutieren, wie solche Werkzeuge beschaffen sein müssen. 4 Das System auf der Ebene der Analyse ist eine Lösung des gestellten Problems unter Annahme idealer Technik. Auf der Ebene des Entwurfs handelt es sich um die Lösung in der gegebenen Betriebstechnik (Oberflächen, Datenbanken, Middleware etc.). In der Realisierung ist das System in der gegebenen Realisierungstechnik (Programmiersprache, Datenbankabfragesprache, Frameworks etc.) ausformuliert. 5 Alle Assoziationen auf A werden auf IA umgelenkt. 6 Besitzt B eigene Methoden für Operationen aus A, haben wir an dieser Stelle keine Vererbung sondern Überschreibung. 7 Dieses Attribut ist final, kann also nach der Konstruktion nicht mehr einen anderen Wert erhalten. 8 IA ist eine Erweiterung von IAM.

6 - 6 - hält dann den Typ A', und B kann nur noch die Operationen aus IAM durch Delegation implementieren. Das reicht aber auch, da B für alle anderen Operationen (IA IAM) sowieso eigene Implementierungen besitzen muss. Zur Lösung des ersten Problems ist ein weiteres Attribut this nötig. Denn bestimmte A-Objekte haben keine eigene <<extends>> IAM Identität, nämlich die, die Dienstleister A {a} für ein B-Objekt sind. Wann immer in IA A den Methoden der Klasse A also über Abbildung 3: Elimination abstrakter Klassen this geredet wird, muss damit unter Umständen ein B-Objekt gemeint sein. Deswegen werden alle Vorkommen von this in A ersetzt durch this.getthis(). Dieses neue Attribut wird unmittelbar nach der Konstruktion eines A-Objekts a gesetzt und zwar (1) auf das B-Objekt, für das a tätig ist oder auf this, falls a als selbständiges Objekt erzeugt wurde. ********* Ein gutes Beispiel für einen Entwicklungsschritt des Forward Engineering an der Grenze zwischen Analyse und Entwurf ist die Beseitigung gegenseitiger Benutzung von Teilsystemen, die durch symmetrische Relationen entsteht, mit Hilfe des Observer-Musters. Beispiel: Beseitigung zyklischer Benutzungen <<implements>> Die Ergebnisse der Analyse enthalten meist eine Reihe symmetrischer Assoziationen im Fachklassenmodell, die rein fachlich wohl begründet sind. Aus der Sicht des Entwurfs stören solche Beziehungen aber ganz erheblich, wenn das Gesamtsystem in ein hierarchisch gegliedertes System unabhängiger Komponenten und Subsysteme zerlegt werden soll. Denn zwei Klassen A und B, die durch eine symmetrische Assoziation verbunden sind, müssen zwangsläufig in derselben Komponente landen, denn A ist nicht ohne B kompilierbar und umgekehrt. Enthält das Fachklassendiagramm der Analyse viele symmetrische Assoziationen ist eine Subsystemzerlegung fast unmöglich. Also müssen in der Regel einige der symmetrischen Assoziationen aufgelöst werden. Dabei kann die folgende Transformation helfen, die ein Observer-Muster einführt, vgl. Abbildung 4. MyA mya SB A mya a myb B <<implements>> <<extends>> A a myb B Systemgrenze Abbildung 4: Elimination zyklischer Benutzung Beide beteiligte Klassen werden in zwei Typen zerlegt. Und zwar A in eine Schnittstelle MyA und A selbst. Die Schnittstelle enthält dabei alle Operationen, die von B aus gerufen werden. 9 Die Klasse B erhält eine Abstraktion SB, die nur die Aufgabe hat, das Attribut mya zu verwalten. 10 In dieser 9 Wir setzen dabei bereits voraus, dass direkte Zugriffe auf Attribute durch getter und setter gekapselt sind. 10 Observer für Arme.

7 - 7 - Situation kann jedes A-Objekt a sein B-Objekt direkt verwalten. Wird myb in a auf b gesetzt, muss gleichzeitig mya in b auf a gesetzt werden. Der entsprechende setter in A muss entsprechend erweitert werden. Danach werden, wie gewünscht, alle Rückrufe von b dem richtigen A-Objekt, nämlich a, zugestellt. Es kann jetzt eine Systemgrenze zwischen A und B eingezogen. Denn nur noch das System, in dem A landet benutzt das andere System, das B (und SB sowie MyA) enthält, und zwar über zwei Wege: (1) Implementierung von MyA und Benutzung von B. Natürlich ist nach der Umformung klar, dass die Initiative zum Setzen der Assoziation nur noch von der A-Seite aus ergriffen werden kann. Das ist aber in vielen Fällen adäquat. ********* Auch innerhalb der Analyse ist Forward Engineering wichtig. Denn nur selten gelingt es, in einem großen Wurf ein komplettes System zu modellieren. Häufig erkennt man, erst nachdem schon ein Modell vorhanden ist, die Notwendigkeit zur Einführung gewisser Analysemuster, wie etwa dem Rollenmuster für Beziehungen zwischen Personen und/oder Objekten. Beispiel: Einführung von Rollen In Abbildung 5 ist im oberen Teil eine typische Situation dargestellt, die im Laufe der Analyse für ein Versicherungsunternehmen entstehen kann: Personen haben Bankverbindungen (konten) und darunter ein ausgezeichnetes Konto für Abbuchungen (eingangskonto) und eines für Gutschriften (ausgangskonto) 11. Die Personen sind wichtig für die Vertragsverwaltung und die Schadenabwicklung der Versicherung. Zu jedem Vertrag muss es einen Vertragspartner geben. Zu jedem Schaden gibt es einen Anspruchsteller. In diesem ersten Modell wird implizit angenommen, dass die Prämien für einen Vertrag von dem Eingangskonto des Partners abgebucht werden. Auf der anderen Seite wird unausgesprochen angenommen, dass etwaige Zahlungen aus einem Schaden an den Anspruchsteller auf dessen Ausgangskonto gebucht werden. Diese im Modell implizit mit gedachten Informationen kann man durch die Einführung eines Rollenmusters explizit machen. Dasselbe Modell mit diesem Konto Konto eingangskonto konten ausgangskonto Muster ist im unteren Teil der Abbildung 5Abbildung 5 wiedergegeben. Hier zeigen Vertrag und Schaden nicht direkt auf Personen sondern auf Rollenobjekte (PersonRolle), die für Personen in bestimmten Rollen stehen (prs). Eine Spezialisierung der Klasse PersonRolle ist PersonRolleMit- Konto (PRolle m. Kto). Von dieser Rolle sind alle Rollen abgleitet, die Rollen für eine Person sind 11 Bezeichnung jeweils aus Sicht des Versicherungsunternehmens. * Person partner anspruchsteller Person Person prs Rolle * Vertrag konten konto PRolle m. Kto Anpruch Steller Partner Abbildung 5: Einführung des Rollenmusters Vertrag Schaden Schaden

8 und in denen eine Bankverbindung benötigt wird. In diesem Modell sind das zunächst zwei, nämlich Partner und AnspruchSteller Das Modell mit dem Rollenmuster offeriert einige Verbesserungsmöglichkeiten für die weitere Entwicklung des Modells. So ist es nun zum Beispiel möglich, dass verschiedene Schaden-Objekte unterschiedliche Bankverbindungen nutzen, indem für eine Person mehrere AnspruchSteller-Rollen angelegt werden. ********* Wenn wir die charakterisierenden Eigenschaften des Forward Engineering herausarbeiten wollen, können wir von den Gemeinsamkeiten der Beispiele oben ausgehen. Allen Beispielen ist gemeinsam, dass Struktur hinzugefügt wird. So wird zum Beispiel beim Zerlegen einer abstrakten Klasse in Abbildung 3 ein Modellelement (abstrakte Klasse) in fünf Elemente zerlegt, nämlich in eine Klasse, zwei Schnittstellen und zwei Implementierungsbeziehungen. Dasselbe Phänomen tritt auch beim Einführen des Rollenmusters (Abbildung 5) auf. Aus einem Element, nämlich der Klasse Person, werden 5 Klassen, eine Assoziation (prs) und drei Spezialisierungen; aus einem Element werden 9. Scheinbar ist hier aber auch etwas zusammengefasst worden, nämlich die beiden Assoziation eingangskonto und ausgangskonto zu konto. Das ist aber semantisch nicht der Fall. Die syntaktische Zusammenfassung an der abstrakten Klasse PersonRolleMitKonto führt semantisch dazu, dass sowohl alle Objekte der konkreten Klasse Partner als auch alle Objekte der konkreten Klasse AnspruchSteller einen Link zu einem Konto aufbauen können. Die beiden Assoziationen sind also noch da, heißen nur gleich. In allen anderen Beispielen finden wir ebensolche Zerlegungen, nur dass manchmal mehrere Modellelemente zerlegt worden sind. Das ist zum Beispiel bei der Einführung des Observer-Musters in Abbildung 4 der Fall. Hier sind sowohl A als auch B in drei Elemente zerlegt und die symmetrische Assoziation in zwei gerichtete. Wir halten also fest: beim Forward Engineering wird nicht beliebig Struktur hinzugefügt, sondern es werden Elemente auf der jeweiligen Systemebene in mehrere Modellelemente der nächst niedrigeren Systemebene zerlegt. Entsprechend gibt es in der umgekehrten Richtung eine Abbildung f, die jedem Modellelement c einer Modellebene ein Element f(c) der nächst höheren zuordnet. Dieses Element f(c) ist die Abstraktion von c. Dabei können mehrere Elemente dieselbe Abstraktion besitzen. Der Kern der Abbildung f bildet die entsprechenden Äquivalenzklassen auf der konkreten Ebene. Das bedeutet in dem Beispiel in Abbildung 1: Ist ein abstraktes Ausgangssystem (System1) in acht Schritten zu einem konkreten Zielsystem (System9) entwickelt worden, gibt es für jedes Element im Zielsystem einen Rückbezug auf jede Abstraktionsebene und zwar vermittelt durch eine entsprechende Komposition der Abbildungen f8: System9 System8 bis f1: System2 System1. Ein Schritt des Forward Engineering von System1 nach System2 liegt also immer dann vor, wenn es eine Abstraktionsabbildung f: System2 System1 gibt. Typischer Weise folgt man beim Forward Engineering vorgefertigten Mustern, vergleiche alle Beispiele oben. Solche Muster können in der Regel automatisiert werden und errichten für das Muster typische Abstraktionsabbildungen. Das führt uns zu folgendem Grundsatz: CE2: Forward Engineering soll ausschließlich Muster verwenden und diese wenn nötig durch Programmtransformation weitgehend automatisieren! Dieser Begriff von Forward Engineering betont den Übergang vom Abstrakten zum Konkreten und liefert mit Hilfe der Rückabbildung auch gleich die Abstraktion mit, wie man wieder vom Konkreten zur nächst abstrakteren Ebene gelangt. Damit kann das Forward Engineering gut gegen den Begriff der Weiterentwicklung abgegrenzt werden. Weiterentwicklung bedeutet, dass auf dem höchsten Abstraktionsniveau (System1 im Beispiel in Abbildung 1) Elemente ergänzt werden. Das heißt bei der Weiterentwicklung werden keine vorhandenen Elemente konkretisiert, sondern es werden ganz neue Elemente hinzugefügt, die zwar mit den vorhandenen Beziehungen haben kön-

9 - 9 - nen, aber nicht aus ihnen hervorgehen. Mit den Methoden des Forward Engineering müssen diese Elemente zusammen mit den bereits vorhandenen dann wieder auf die Zielebene des Systems (inklusive technischer und entwicklungstechnischer Rahmenbedingungen) gebracht werden. Compiler gehen dabei zum Beispiel so vor, dass das alte Kompilat weggeworfen wird und der ergänzte Quellcode wieder vollständig in den neuen Zielcode transformiert wird. Dieses Vorgehen ist ideal, da sich der Entwickler sowohl mit etwaigen Zwischenebenen als auch mit dem Endergebnis nicht auseinander setzen muss und der gesamte Prozess vollautomatisch ist. Wenn sich dieses Vorgehen auf den gesamten Prozess des Forward Engineering ausdehnen lässt, erhalten wir eine ideale Situation. Weiterentwicklung findet auf der Ebene der abstrakten Modelle statt und die gesamte Konkretisierung in Richtung Betriebs- und Entwicklungstechnik wird automatisch erstellt. Von diesem Ideal sind wir immer noch sehr weit entfernt. Dafür gibt es viele Gründe, die im Folgenden noch ausführlich angesprochen werden. Ein wesentlicher Handicap der aktuellen Systeme ist, dass neben dem lauffähigen System auf der konkreten Ebene der Programmier- und Konfigurationssprachen keine Abstraktionen in Form von Modellen vorliegen. Deswegen gibt es derzeit einen hohen Bedarf nach Reverse Engineering. Reverse Engineering Reverse Engineering bezeichnet alle Aktivitäten der Rückgewinnung eines Systems auf abstrakten Niveaus aus konkreten Systemebenen, meist aus dem lauffähigen Zielsystem. Damit bezeichnet Reverse Engineering genau den Umkehrprozess zum Forward Engineering. Schon diese kurze Charakterisierung macht deutlich, dass wir uns mit diesem Gebiet nicht lange auseinander setzen müssen. Denn Abstraktionsprozesse sind nicht konstruktiv wie die oben vorgestellten Muster-getriebenen Schritte vom Abstrakten zum Konkreten. Abstraktion ist kreativ. Wenn hier Werkzeuge helfen sollen, müssen sie 1. Methoden der künstlichen Intelligenz anwenden oder 2. lediglich den menschlichen Anwender bei seinen Abstraktionsprozessen unterstützen. Die erste Gruppe von Werkzeugen ist meist für sehr große industrielle Projekte nicht geeignet, das Finden von Abstraktionen scheitert meist an der großen Quantität und der Komplexität der Aufgabe. In der zweiten Gruppe gibt es eine Vielzahl von Werkzeugen, die Programm- und Systemstrukturen (Klassen, Vererbungsstruktur und Assoziationen, Kontrollfluss zwischen Programm-Statements, Datenfluss zwischen Variablen, Funktionsaufrufe, Import-Strukturen, Interaktion über Nachrichten etc.) analysieren und visualisieren. Durch die graphische Darstellung allein ist wie gesagt noch keine Abstraktion gegeben, aber die graphische Darstellung kann dem Anwender dabei helfen, die richtigen Abstraktionen zu erkennen. Ein Problem ist hier wiederum die Größe industrieller Systeme. Die Graphiken werden dadurch unübersichtlich. So ist zum Beispiel in einem Aufrufgraphen von 1000 oder mehr Funktionen so gut wie nichts mehr zu erkennen. Auch Kontrollflussgraphen neigen zur Unübersichtlichkeit, wenn es um Methoden mit mehr als 500 Zeilen geht. In einem Benutzungsgraphen zwischen 1000 Klassen (Import-Struktur) lassen sich Zyklen mit dem bloßen Auge nicht mehr erkennen. Die Strukturen von Systemen auf der konkreten ausführbaren Ebene sind nicht zu Letzt deswegen so komplex und unübersichtlich, weil sie alle Aspekte des Systems zugleich repräsentieren. Die reine Fachlichkeit (fachliche Funktion) ist umstellt mit einer Vielzahl nicht-fachlicher, eher technischer Details, die zum Beispiel nötig sind, um die verwendeten Frameworks zu befriedigen, die notwendige Performanz des Endsystems bereitzustellen, Mehrbenutzer-Koordination zu bieten oder die Oberflächen und Schnittstellen zu versorgen. Der Einstieg in das Reverse Engineering ist

10 schon deswegen schwierig, da sich diese Aspekte im Nachhinein nicht leicht von einander separieren lassen, insbesondere dann, wenn eben nicht ingenieurmäßig nach Mustern in der Entwicklung vorgegangen wurde, die ihre typischen Abstraktionen hinterlassen. Häufig ist bei der Visualisierung von Programmstrukturen das zentrale Problem, das richtige Layout für die Graphik zu finden. Denn das Layout muss so gewählt sein, dass der menschliche Benutzer in der Lage ist, die wesentlichen Strukturen zu identifizieren. Dabei spielen die typischen Schönheitsideale für Graphen, wie zum Beispiel Kreuzungsfreiheit von Kanten, eher eine untergeordnete Rolle. Eine schöne, kreuzungsfreie Darstellung zeigt meist gar nichts an interessanter Struktur, da dabei semantisch zusammengehörige Elemente sehr weit verstreut werden können. Ein statisches Layout scheint also weniger hilfreich, wenn es um 100 oder mehr Elemente und/oder Beziehungen geht. Die Darstellung muss vielmehr dynamisch sein: Wählt der Benutzer ein Element e aus, müssen die zu diesem Element unmittelbar in Beziehungen stehenden Elemente in der Nähe von e dargestellt werden. Wechselt er dann zu einem dieser Elemente muss sich die Anzeige dynamisch anpassen und dann diesen Kontext komplett und kompakt anzeigen. Bisher sind wenige solcher graphischer Editoren auf dem Markt. Das Wiederentdecken abstrakter Ebenen in der Systementwicklung ist also ein kreativer Prozess, der allenfalls durch Werkzeuge unterstützt aber nicht automatisiert werden kann. Umso wichtiger ist es, während der Entwicklung eines Systems die richtige Menge an Abstraktionsniveaus einzuziehen und die gesamte Entwicklung über alle diese Ebenen zu dokumentieren. In diesem Fall können die zu Grunde liegenden Abstraktionen nicht verloren gehen. Sie müssen dann auch nicht mühevoll wieder beschafft werden, wenn das System fachlich weiterentwickelt oder technisch angepasst werden soll. Dieser Gedanke leitet direkt über zum nächsten Thema über: Continuous Engineering. Continuous Engineering Heutzutage werden kaum noch neue Systeme in dem Sinne entwickelt, dass bisher komplett manuelle Prozesse durch ein DV-System unterstützt werden sollen. Die normale Ausgangssituation ist derzeit, dass ein vorhandenes System weiterentwickelt oder abgelöst werden soll. Im Fall der Ablösung spricht man zwar auch von Neuentwicklung. Der Begriff ist hier aber nicht adäquat. Denn die sogenannte Neuentwicklung würde nicht stattfinden, wenn sich das alte System kostengünstig an neue oder veränderte fachliche oder technische Gegebenheiten anpassen ließe. Diese Art der Neuentwicklung ist also eher eine Variante der Weiterentwicklung: Es sollen die Funktionen des alten Systems im Prinzip wieder zur Verfügung gestellt werden und zudem sollen (1) einige der alten Funktionen verändert, (2) ein Satz neuer Funktion hinzugefügt und (3) die technischen Rahmenbedingungen angepasst werden. Warum entscheidet man sich dann derzeit in vielen Unternehmen für eine komplette Neuentwicklung der vorhandenen Systeme und attestiert den alten Systemen, nicht mehr genügend anpassbar zu sein? Die zentrale Ursache liegt im Entwicklungsprozess: die ursprünglichen Abstraktionen der alten Systeme sind über die Jahre 12 verloren gegangen. Das einzige Material, das für eine Weiterentwicklung zur Verfügung steht, ist das (dokumentierte) lauffähige System in einer (oder mehreren) Programmiersprache(n) (häufig Cobol, PL1 etc.). Die Entwurfsentscheidungen, die zu diesem System geführt haben, sind nicht mehr vorhanden und die Effekte und Phänomene, die diese Entscheidungen im System selbst hervorgerufen haben, nicht mehr zu erkennen (durch zum Beispiel Reverse Engineering). Trotz dieses Defizits sind die Systeme mehrfach an geänderte Umstände angepasst worden; in wie weit aber diese Anpassungen vollständig erfolgt sind und dem ursprünglichen Entwurf genügten, ist stets unklar geblieben. Hin und wieder ist sogar klar, dass einige Erweiterungen zu der ursprünglichen Entwurfsidee im Widerspruch stehen. Dennoch trickst man 12 Wir reden hier über Systeme, die in der Regel 20 Jahre oder mehr in Betrieb waren.

11 sie in das System, da der Aufwand für ein komplettes Redesign als zu hoch eingeschätzt wird 13. Dadurch wird der Entwurf des Systems immer mehr verschleiert, es treten vermehrt Fehler auf und die Anpassungsprozesse werden immer langsamer. Zum Schluss entscheidet das Management, dass es billiger ist, das System zu ersetzen als weitere Anstrengungen für Anpassungen zu unternehmen. Solche Projekte, die ein vorhandenes, nicht mehr anpassbares System durch ein Neusystem ersetzen sollen, stehen aber auch unter keinem guten Stern. Von ihnen wird erwartet, dass sie (1) die guten Funktionen des Alt-Systems wieder zur Verfügung stellen, (2) die notwendigen Anpassungen und Erweiterungen (, die das Altsystem nicht mehr schaffte) beinhalten und (3) langfristig an fachliche und technische Kontextänderungen anpassbar sind. Insofern ist das neue System aus Sicht der Auftraggeber eine kontinuierliche Weiterentwicklung des Altsystems. Das Problem ist hier auch dasselbe, wie bei der Erweiterung von Alt-Systemen: Die abstrakten Analysen und Entwürfe des Altsystems egal ob sie sich als richtig oder (mit der Zeit) als falsch erwiesen haben stehen nicht mehr zur Verfügung und lassen sich nicht mehr wieder gewinnen. Das bedeutet, die Neuentwicklung muss die gesamte Entwicklung von vorne beginnen. Die Analyse muss komplett wiederholt werden. Die Entwürfe müssen komplett neu entwickelt werden, wobei nicht aus den Fehlern der Vergangenheit gelernt werden kann. Das Performanz-Tuning der Realisierung muss dafür sorgen, dass die Geschwindigkeit des Altsystems erreicht wird, ohne dass man auf die während der Entwicklung des alten Systems gemachten Erfahrungen zurückgreifen kann. Der Aufwand dafür wird aus Sicht des Managements häufig drastisch unterschätzt. Hier ist man der Meinung, dass es sich lediglich um eine Weiterentwicklung handelt, denn das Altsystem konnte ja auch schon fast alles. Wo ist also das Problem? Wieso ist die Neuentwicklung so teuer? Die einfache Antwort: Weil niemand mehr weiß, was und warum man es konnte. Die Darstellung oben macht deutlich, dass wir es heute mit einem kontinuierlichen Erweiterungsund Anpassungsprozess in der Software-Entwicklung zu tun haben. Auch vermeintliche Neuentwicklungen zur Ablösung eines Altsystems passen in dieses Schema. Das Continuous Engineering (CE) befasst sich folgerichtig mit allen Aktivitäten, die zur Umgestaltung eines DV-Systems nötig sind. Ziel des CE ist es, die Methoden des Forward Engineering so zu ergänzen 14, dass alle Ab- 13 Hier ein gutes Beispiel für einen solchen Trick: Ein Versicherungsunternehmen hat eine Vertragsanwendung für die Auto-Versicherung in Betrieb, die den Beitrag dadurch bestimmt, indem in einer großen zweidimensionalen Tabelle aus Typ- und Regionalklasse nachgeschlagen wird. Solange keine weichen Tarifmerkmale im Spiel sind, ist diese Vorgehensweise durchaus gerechtfertigt, denn die notwendigen Tabellen werden Jahr für Jahr von zentraler Stelle (Gesamtverband der Deutschen Versicherungswirtschaft GDV) geliefert. Aber nun bringen einige Versicherungsunternehmen prozentuale Rabatte und Zuschläge für Kilometerleistung, Berufsstand des Halters, Alter des Halters etc. auf den Markt (sogenannte weiche Tarifmerkmale). Unser Unternehmen muss reagieren und will auch solche Zu- und Abschläge erheben bzw. gewähren. Wie ist das in die Vertragsanwendung einzubauen? Der richtige Weg ist natürlich die Erweiterung der Tarifberechnung um ein flexibles Zu- und Abschlagssystem (inklusive Analyse, Entwurf, Implementierung und Test). Dazu fehlt die Zeit! Deswegen erweitert man die vorhandene Methode des Nachschlagens in einer Tabelle. Die weichen Tarifmerkmale werden zu weiteren Dimensionen; die Tabelle hat so mit der Zeit 5, 6,..., 10 Dimensionen. Die Erstellung der (sehr goßen) Tabelle geschieht dann in der Fachabteilung mit Hilfe von Tabellenkakulationsprogrammen. Hier rechnet man natürlich ganze Dimensionen durch prozentuale Zu- und Abschläge auf andere Dimensionen aus. Doch leider macht man den Fehler, Prozentpunkte zu addieren statt Prozente zu multiplizieren. So wird aus zwei Rabatten von 10% für Merkmal A und 15% für Merkmal B ein Rabatt von 25% für Merkmal A und B. Diese Tabellen gehen in Produktion. Solange nur wenige weiche Merkmale existieren kann man mit dem Fehler leben. Mit der Zeit nehmen aber die Anzahl der Merkmale zu, so dass es mit der Additionsmethode im schlimmsten Fall schon zu einem Rabatt von 75% kommen kann. Weitere Merkmale lassen sich nun nicht mehr einführen, da sonst einige Versicherungsnehmer keine Prämie mehr zahlen sondern Geld ausbezahlt bekommen würden. 14 Der Begriff Continuous Engineering umfasst also das Forward Engineering. So grenzt sich dieser eher

12 straktionsniveaus eines Systems, die in der Erstentwicklung eingezogen wurden, auch nach der Veränderung erhalten bleiben und entsprechend angepasst werden. Wenn nötig, soll es auch möglich sein, neue Zwischenebenen einzuführen oder alte Ebenen zusammenzulegen. So soll die Erweiterbarkeit des Systems nachhaltig gesichert werden. Insbesondere soll so die Wiederverwendung von Analyse- und Entwurfsergebnissen in zwei Richtungen forciert werden. Ist lediglich eine technische Anpassung nötig, werden die Ebenen der Analyse unverändert gelassen. Nur die Transformationen in den Entwurf und die Realisierung sind zu adaptieren. Wird das System fachlich erweitert, so sind die Analysemodelle zu erweitern. Große Teile sollten dabei unangetastet bleiben, so dass die Transformation dieser Teile in das lauffähige System übernommen werden können. Diese Überlegungen führen zu einem idealen Vorgehensmodell in der Software-Entwicklung. Das ist Thema des nächsten Kapitels. Das ideale Vorgehensmodell Die Analyse im vorangegangenen Abschnitt hat gezeigt, dass die derzeitigen Probleme bei der Weiterentwicklung in die Jahre gekommener Systeme im Wesentlichen dadurch verursacht werden, dass die ursprünglichen Analyse- und Entwurfsdokumente für diese Systeme nicht mehr vorhanden oder nicht mehr auf dem aktuellen Stand sind. Was heißt hier nicht mehr auf dem aktuellen Stand? Das bedeutet, dass im ablauffähigen System Änderungen vorgenommen worden sind, die mit den Analyse- und Entwurfsdokumenten nicht vereinbar sind, ohne dass diese Dokumente entsprechend angepasst worden. Werden viele solcher Änderungen gemacht, haben die Analysen und Entwürfe schnell gar nichts mehr mit dem System zu tun. Diese Entwicklung wird durch ein Vorgehen, das sich Round-Trip Entwicklung nennt, begünstigt. Round-Trip Entwicklung Natürlich hat sich in der Software-Entwicklung die Einsicht durchgesetzt, dass die Entwicklung eines Systems zumindest die Phasen Analyse, Entwurf, Realisierung und Qualitätsmanagement (Test) durchlaufen soll. Das gilt für alle Vorgehensmodelle, sowohl für das klassische Wasserfallmodell, als auch für das V-Modell und alle iterativen inkrementellen Ansätze, ja sogar für das Extreme Programming. Die Unterschiede liegen nur darin, wie oft und in welcher zeitlichen Reihenfolge die Phasen zu durchlaufen sind. Man ist sich auch einig, dass die Ergebnisse jeder Phase zu dokumentieren sind, so dass während der Entwicklung auch die abstrakteren Ebenen eines Systems beschrieben und aktualisiert werden. Damit dieser Ansatz praktikabel ist, wird von den meisten Entwicklern ein so genanntes Round- Trip Engineering (RTE) gefordert. Und viele Anbieter von Entwicklungswerkzeugen unterstützen es. Beim RTE wird der Entwickler nicht gezwungen, Änderungen, die die Analyse betreffen, ausschließlich in den Analysedokumenten, wie etwa Klassenmodellen oder Aktivitätsdiagrammen, vorzunehmen und von da aus mit den Methoden des Forward Engineering das gesamte System zu verändern. Er kann Veränderungen jederzeit in jedem Dokument auf jedem Abstraktionsniveau vornehmen; die angebotenen Werkzeuge des RTE sorgen dann dafür, dass diese Änderungen auch in die Dokumente der anderen Abstraktionsebenen eingepflegt werden. Typische Beispiele für solche Werkzeuge sind die automatische Extraktion von UML2-Klassenmodellen aus objektorientiertem Programmcode oder relationalen Datenbanktabellen oder von Programmablaufplänen (UML2- Aktivitätsdiagrammen) aus programmiersprachlichen Statements. unübliche Begriff vom Reengineering ab, dass nur die Umgestaltung adressiert. Reengineering in der Literatur meint auch häufig die nochmalige Komplettentwicklung eines Systems oder Prozesses in dem Fall, dass das Vorhandene sich als vollständig untauglich herausgestellt hat. Das ist gerade nicht der Fokus des CE. Wir wollen wiederverwenden und Wiederverwendbares herstellen.

13 Wird dieses Verfahren extensiv angewendet, ist die Entwicklung massiv mit Reverse Engineering Schritten durchsetzt. Problematisch ist hier, dass wie wir oben festgestellt haben Reverse Engineering nicht ohne Dazutun des Entwicklers zu gescheiten Abstraktionen führt. Klassen, die zum Beispiel im Java-Code entstehen, können keine Mehrfachvererbung nutzen. Entsprechend wird es auch in der Analyse keine Mehrfachvererbung geben, selbst wenn sie sinnvoll ist. Assoziationen, die in der Programmiersprache entstehen, sind immer gerichtet. Klassenmodelle aus relationalen Strukturen enthalten zwangsläufig keine Generalisierung und damit keine Abstraktionen. Generierte Programmablaufpläne spiegeln alle Programmverzweigungen wieder, technische wie fachliche. Werden die erzeugten Dokumente nicht nachgearbeitet, sind sie über kurz oder lang nichts anderes als der Programmcode nur anders notiert. Auch so gehen gute erste Abstraktionen mit der Zeit verloren. Die Gefahr, die mit dem RTE einhergeht, ist, dass die Entwickler den formalen Anforderungen des Vorgehensmodells genüge tun. Sie erzeugen ja die geforderten Dokumente in UML2 oder anderen Analyse- und Entwurfssprachen. Aber sie genügen dem Vorgehensmodell nur formal und nicht inhaltlich. Im Endeffekt wird nicht mehr auf den abstrakten Ebenen gearbeitet, die Weiterentwicklung des Programmcodes steht im Vordergrund, die Abstraktionen werden zu Abfallprodukten. Zum Schluss erhalten wir wieder die alte Situation, in der neben dem lauffähigen System keine weiteren brauchbaren Dokumente für die Weiterentwicklung existieren. 15 Resümee: Die Werkzeuge des Round-Trip Engineering helfen nicht wirklich bei der methodischen Software-Entwicklung, sie verleiten vielmehr dazu, die Methode zu unterlaufen. Die Renaissance des Wasserfalls Sollen die oben beschriebenen Effekte vermieden werden, benötigen wir eine klare Sortierung sämtlicher Dokumente, die während der Entwicklung entstehen, nach Abstraktionsniveaus. Und wir müssen dafür sorgen, dass Änderungen und Erweiterungen des Systems immer zuerst auf dem höchsten Abstraktionsniveau vorgenommen werden, das von den Änderungen bzw. Erweiterungen betroffen ist. Von da aus ist dann die Änderung bzw. Ergänzung mit den Methoden des Forward Engineering auf alle konkreteren Ebenen ingenieurmäßig zu übertragen. Dieses Vorgehen stellt sicher, dass der Ausgangspunkt für jede Änderung auf dem richtigen Abstraktionsniveau gefunden wird. Insofern wird die abstrakteste betroffene Ebene als erste angepasst und nicht als letzte. Das führt konsequent dazu, dass vom Abstrakten zum Konkreten gedacht und entwickelt wird. Nur so besteht die Chance, dass die ursprünglichen Abstraktionen ordentlich gepflegt und nachhaltig weiterentwickelt werden. Diese Idee führt in gewissem Sinne zurück zum Entwicklungsmodell des Wasserfalls. Erst wenn die Analysedokumente vollständig aktualisiert sind, wird mit den Änderungen in den Entwurfsdokumenten begonnen und erst, wenn dies abgeschlossen ist, erfolgt die Anpassung des Coding auf der Realisierungsebene. Entwickelt wird immer vorwärts nie rückwärts. Sicher, das entspricht in groben Zügen dem Wasserfallmodell nur mit dem Unterschied, dass inkrementell vorgegangen wird. Nicht die komplette Analyse muss abgeschlossen sein, um auf konkreteren Ebenen aktiv zu werden. Es muss nur immer der Teil oder die Ausbaustufe, der oder die gerade entwickelt wird, zunächst auf der Ebene der Analyse abgeschlossen sein, bevor mit dem weiteren Forward Engineering begonnen wird. Auch Rückkopplung von der konkreten zur Abstrakten Ebene ist nicht ausgeschlossen. Werden Probleme in der Implementierung, zum Beispiel im Bereich der Performanz, entdeckt, muss ggf. zurückgekehrt werden in den Entwurf und die nötigen Veränderungen (zum Beispiel Denormalisierung der relationalen Datenbank) müssen dort vorgenommen werden. 15 Natürlich immer unter der Prämisse, dass die generierten Dokumente nicht gründlich nachgearbeitet werden.

14 In dem oben dargestellten Szenario wird implizit angenommen, dass es stets möglich ist, genau das Abstraktionsniveau zu bestimmen, auf dem eine Änderung oder Erweiterung eingepflegt werden muss. Das ist aber nicht so einfach, wenn die einzelnen Dokumente auf den verschiedenen Abstraktionsniveaus nebeneinander stehen und keine gemeinsame Struktur aufweisen. Es stellt sich zum Beispiel beim Hinzufügen einer Klasse die Frage, ob sie das Analysemodell erweitert (dann muss sie hier angelegt werden) oder lediglich in dem gewählten Entwurf eine Rolle spielt (dann kann sie problemlos in den Entwurf eingepflegt werden). Solche Fragestellungen können einfach entschieden werden, wenn jedes Objekt (Klasse, Operation, Methode, Statement, Ausdruck etc.) auf einer konkreten Ebene 16 auf seine Abstraktion, i. e. auf ein Objekt der nächst höheren (abstrakten) Ebene, abgebildet wird. 17 Jedes Objekt, das kein neues Analyse-Objekt ist, muss dann abgebildet werden. Gelingt das, ist die Anlage auf der konkreten Ebene o.k., gelingt es nicht, gehört das Objekt auf eine abstraktere Ebene. Diese Idee der Abbildung von der konkreten auf die abstrakte Ebene ist schon im Rahmen des Forward Engineering oben diskutiert worden. Durch ein Werkzeug verwaltet, liefert sie die Leitplanken für den gesamten Entwicklungsprozess. Das Einfügen von Objekten auf einer konkreten Ebene ist immer ein Einfügen in eine Äquivalenzklasse (alle Objekte, die dieselbe Abstraktion haben). Der Zwang dazu, für jedes neue Objekt eine Abstraktion angeben zu müssen, führt dazu, dass gründlich über die richtige Ebene für das Einfügen nachgedacht wird. Gleichzeit wird die Aufgabe zur Konkretisierung auf allen konkreteren Ebenen klar formuliert und ebenfalls durch ein Werkzeug verwaltbar. Das Löschen eines Objekts verkleinert die Konkretisierung der Abstraktion und macht alle seine eigenen Konkretisierungen obsolet. Das Aufspalten eines Objekts führt zu neuen Objekten, die die Abstraktion des ursprünglichen Objekts übernehmen. Das Zusammenfassen von Objekten ist nur möglich, wenn sie dieselbe Abstraktion haben. Ansonsten muss zunächst eine Zusammenfassung in der Abstraktion erfolgen. Soll eine Äquivalenzklasse geteilt werden, muss zunächst die Abstraktion verfeinert werden. Ein Werkzeug zur Verwaltung einer solchen Abstraktionsabbildung ist nicht kompliziert, es führt nur gründlich Buch. Dennoch ist es sehr wertvoll. Mit Hilfe seiner Informationen ist es möglich die Auswirkungen jeder Änderung oder Ergänzung nach oben (zu den abstrakteren Ebenen) zu ermitteln. Es führt den Entwickler zum richtigen Abstraktionsniveau für seine Änderungen und unterstützt damit die nachhaltige Pflege aller Dokumente im Projekt. Der Zwang zur Angabe einer Abstraktion verhindert wildes Round-Trip Engineering, keine Änderung muss den Wasserfall hinauf schwimmen. Als Fazit dieses Abschnitts halten wir fest: CE3: Software Entwicklung im Rahmen des Continuous Engineering ist stets Forward Engineering nie Reverse Engineering. Diesen Slogan wollen wir einem etwas größeren Beispiel verdeutlichen. Beispiel: Optimierung einer Stückliste Beispiele für das Forward Engineering hatten wir bereits mit den Abbildung 2, Abbildung 3, Abbildung 4 und Abbildung 5 dargestellt. Hier wollen wir ein etwas größeres Beispiel einer Stückliste diskutieren, dass zeigt, wie Änderungen und Ergänzungen richtig einzupassen sind. Stücklisten (vergleiche Abbildung 6) geben für Produkte (Product) an, aus welchen Teilen (parts) sie hergestellt werden. Dazu hat jedes Produkt eine Liste (QPartList) der direkt benötigten Unterteile. Diese Liste besteht aus Einträgen (QuantifiedPart), die nicht nur das Unterteil selbst (part) spezifizieren, sondern auch die Anzahl (quantity) angeben, wie oft dieses Unterteil beim Zusam- 16 Alle Ebenen außer der obersten abstraktesten sind konkret. 17 Diese Abbildung sollte durch ein Werkzeug des CE verwaltet werden.

15 menbau des Produkts benötigt wird. Unterteile können andere Produkte oder Materialien (Material) sein. Deswegen gibt es die Abstraktion des Teils (Part), die das eingesetzte Composite Pattern vervollständigt. Materialien haben einen Preis pro Stück (price). Alle Assoziationen sind Aggregationen, was zum Ausdruck bringt, dass die gesamte Struktur auf den Teilen frei von Zyklen ist. Letztlich bestehen alle Produkte aus Materialien (Material). Deswegen gibt es für alle Teile die Operation getparts(q:integer):qpartlist, die ermittelt, welche Materialien wie oft für die Produktion von q Stück des Empfängers nötig sind. 18 Materialien implementieren diese Operation ganz einfach, indem eine Liste mit einem Eintrag geliefert wird. Dieser Eintrag spezifiziert das Material selbst und als Quantität wird der Parameter q eingetragen. Die Implementierung für Produkte nutzt die Operation getparts():qpartlist in der Klasse QPartList, die die Materialliste für ein Exemplar rekursiv berechnet. Diese Ergebnisliste wird dann nur noch mit q multipliziert. Material price:amount Ebenso wichtig wie die Materialliste getparts():qpartlist ist der Herstellungspreis für eine Anzahl q von Teilen. Um diesen zu ermitteln, gibt es die Operation Abbildung 6: Modell einer Stückliste getprice(q:integer):amount. Diese Operation ist ein einfacher getter für Materialien. Für Produkte muss die Materialliste für die angegebene Stückzahl berechnet und anschließend aufaddiert werden. Part getparts(q:integer):qpartlist getprice(q:integer):amount Product parts part QuantifiedPart quantity:integer * QPartList Material price:amount Part getparts(q:integer):qpartlist getprice(q:integer):amount Subject part ProductState getparts():qpartlist QuantifiedPart quantity:integer * * Observer Product parts Uncached Cached materials QPartList getparts():qpartlist Abbildung 7: Effiziente Stückliste Die Berechnung der Materialliste ist aufwändig, denn eine kommerzielle Stückliste kann leicht einige tausend Teile beinhalten. Deswegen ist es eine gute Idee, eine einmal berechnete Stückliste 18 Diese Mengen sind für den Einkauf wichtig, wenn ein entsprechender Fertigungsauftrag eingeht.

16 aufzuheben und nicht immer wieder neu zu berechnen. Solange sich an der Struktur der Produkte nichts ändert, kann man auf diese Art und Weise viele Berechnungen sparen. Diese Idee kann mit Hilfe eines State Patterns umgesetzt werden (vergleiche Abbildung 7). Produkte erhalten einen Zustand (ProductState), für den es zwei Ausprägungen gibt, nämlich einen Zustand (Uncached), in dem noch keine Materialliste berechnet wurde, und einen (Cached), der eine bereits berechnete Materialliste (materials) zwischenspeichert. Ein Produkt kann jetzt zur Bestimmung seiner Materialliste an den Zustand delegieren. Der Zustand ohne Zwischenspeicher (Uncached) delegiert an das Produkt und dessen Teileliste (parts) zurück, merkt sich aber das Ergebnis, indem der Zustand des Produkts gewechselt wird. Der Zustand mit Zwischenspeicher (Cached) liefert seine gespeicherte Liste (materials) und ändert den Zustand des Produkts nicht. Produkte müssen jetzt in ein Observer Pattern eingebunden werden (Implementierung der abstrakten Klasse Subject und der Schnittstelle Observer). Denn ändert sich die Unterstruktur eines Produkts, so müssen dieses Produkt und alle Produkte, die es direkt oder indirekt nutzen, ggf. ihren Zustand von Cached zu Uncached ändern. Dazu muss sich jedes Produkt bei allen seinen direkten Unterprodukten als Beobachter registrieren. Alle seine Änderungen müssen dann an alle seine Beobachter (und transitiv wiederum an alle Beobachter von diesen) weitergegeben werden. Dieses neue Modell (Abbildung 7) ist eine Konkretisierung des Modells aus Abbildung 6. Die Abbildung von der konkreten zur abstrakten Ebene ordnet alle in Abbildung 7 grau hinterlegten Klassen und alle Beziehungen dazwischen der Klasse Product im Modell in Abbildung 6 zu. Die beiden Assoziationen parts und materials im Modell in Abbildung 7 werden zu der Assoziation parts abstrahiert. Alle anderen Abstraktionen sind eins zu eins (Korrespondenz über Namensgleichheit). Die beiden vorgestellten Modelle stellen also dasselbe System auf zwei Abstraktionsniveaus dar. Soll dieses System weiterentwickelt werden, muss entschieden werden, auf welchem Abstraktionsniveau der Ausgangspunkt für die jeweilige Weiterentwicklung gesetzt wird. Hier zwei Beispiele: 1. Produkte benötigen zu ihrer Herstellung nicht nur die richtig Menge an Materialien. Sie verbrauchen auch Arbeitskraft, nämlich die Arbeitskraft, die zum Zusammenbau der Materialien nötig ist. Das Modell soll so weiterentwickelt werden, dass dieser Zusammenhang abgebildet werden kann. 2. Auch die Berechnung des Einkaufspreises ist aufwändig und es lohnt darüber nachzudenken, nach einer ersten Berechnung des Preises diesen auch zu speichern. Die erste Erweiterung (vergleiche Abbildung 8) kann als Erweiterung auf der abstrakten Ebene in das vorhandene System eingebaut Material Part Element price:amount <<singleton>> Workload Abbildung 8: Erweiterung um Arbeit werden. Zunächst wird die vorhanden Klasse Material in zwei Klassen, nämlich die abstrakte Klasse Element und die konkrete Klasse Material, und eine Spezialisierungsbeziehung zerlegt. Danach wird das Modell um die Klasse Workload und eine zusätzliche Spezialisierungsbeziehung erweitert. Danach kann die Erweiterung eins zu eins auf die konkrete Ebene weitergegeben werden, da die vorliegende Konkretisierung (Abbildung 7) nur Produkte betrifft. Die Erweiterung muss auf der abstrakten Ebene erfolgen, da der Klasse Workload keine Abstraktion zugeordnet werden kann. Sie ist wirklich neu! Mit der zweiten Weiterentwicklung verhält es sich anders. Hier wird lediglich ein neuer Zustand für Produkte eingeführt. Alle neuen Klassen und Beziehungen lassen sich auf Objekte auf der abstrakten Ebene beziehen. Das heißt, diese Entwicklung wird auf der konkreten Ebene durchgeführt. Inhaltlich ähnelt sie der ersten Entwicklung (vergleiche Abbildung 9): Der Produktzustand

17 Cached wird zunächst zerlegt in drei Objekte, i. e. die abstrakte Klasse Cached, die konkrete Klasse CMaterials und eine Spezialisierung. Alle diese Objekte müssen abstrahiert werden zu Product, da zuvor die Klasse Cached diese Abstraktion besaß. Dann wird ein neuer konkreter Zustand CM&Price (samt Spezialisierung) hinzugefügt, der in der Lage ist, neben der Materialliste auch ihren Preis zu speichern. Er erhält ebenfalls die Abstraktion Product. Die Zustandsübergänge werden nun angepasst und die Klasse ProductState erhält eine Operation getprice():amount, an die ein Produkt eine Preisanfrage delegieren kann und deren Abstraktion die Methode getprice(q:integer):amount ist. Jetzt ist die Klasse Material dahingehend zu verfeinern, dass sie Subject spezialisiert. Denn nun müssen auch Zustandswechsel bei Produkten erfolgen, wenn sich Materialien, genauer gesagt ihre Preise, ändern. Die Logik dabei ist, dass sich ein Produkt genau dann bei allen seinen Materialien in der Materialliste registriert, wenn der Wechsel in den Zustand CM&Price erfolgt. Wird der Zustand verlassen, muss die Deregistrierung erfolgen. Product Uncached ProductState getparts():qpartlist getprice():amount CMaterials Die skizzierte Entwicklung sollte mit folgenden Ergänzungen verbessert werden: (1) Da jetzt sowohl Produkte als auch Materialien von Subject abgeleitet sind, kann man natürlich gleich Part von Subject ableiten und das Modell wird deutlich übersichtlicher. (2) Die Produkte benötigen jetzt mehr Informationen von ihren beobachteten Objekten, insbesondere darüber, ob sich ein Unterprodukt strukturell geändert hat oder ein Bestandteil (Material oder Workload) im Preis. (2a) Die Operation in Observer muss von update():void zu update(event event):void verfeinert werden. (2b) Dazu wird der leere Parameter 19 () von update verfeinert zu einer Spezialisierungshierarchie aus Abstraktion Event und Konkretisierungen PriceChangedEvent und StructureChangedEvent. (3) Um elegant entscheiden zu können, auf welches Ereignis reagiert werden muss, kann zum Beispiel ein EventVisitor programmiert werden, der ebenfalls zum leeren Parameter () abstrahiert wird. Entwicklungsspuren Die systematische Entwicklung, wie sie oben im Beispiel skizziert wurde, benötigt als Grundlage nicht nur die Modelle auf den verschiedenen Abstraktionsniveaus. Ebenso wichtig sind die Beziehungen zwischen den Modellen. Dabei haben wir bereits herausgearbeitet, dass jedes Objekt in einem Modell, das nicht auf dem höchsten Abstraktionsniveau angesiedelt ist, auf eine Abstraktion abzubilden ist. parts CE4: Ein (vertikaler) Entwicklungsschritt s: A K des Forward Engineering von einer abstrakteren Ebene A zur einer konkreten Ebene K wird repräsentiert durch eine surjektive Abbildung sr: K A. 19 Beachte, dass das leere Produkt aus genau einem Element besteht. Cached CM&Price price:amount materials Abbildung 9: Speicherung des Gesamtmaterialpreises QPartList getparts():qpartlist

18 Das bedeutet, dass jeder Verfeinerungsschritt eine Spur in der umgekehrten Richtung hinterlässt. Diese Spur zeigt auf, wie jedes abstrakte Objekte durch eine Menge von konkreteren Objekten realisiert ist. Diese Mengen sind die Äquivalenzklassen, die durch die repräsentierende Abbildung erzeugt werden (Kern der Repräsentation). Diese Spur zeigt zugleich auf, welche Auswirkungen Veränderungen auf der konkreten Ebene auf die Abstraktion haben: 1. Veränderungen innerhalb der einzelnen Äquivalenzklassen, zum Beispiel das Zusammenfassen von Objekten in derselben Klasse oder das Aufsplitten von Objekten, haben keine Wirkungen. 2. Das Zusammenfassen von Objekten aus unterschiedlichen Klassen pflanzt sich auf die Abstraktion fort. 3. Das Löschen der letzten Repräsentation eines abstrakten Objekts ist nicht möglich, ohne die gesamte Konkretisierungsebene zu löschen. Neben den vertikalen Entwicklungsschritten (Forward Engineering) haben wir im Continuous Engineering auch die horizontalen Schritte der Weiterentwicklung. Hier können Objekte (1) ergänzt, (2) gelöscht, (3) aufgespalten und (4) zusammengelegt werden. Beispiele für das Ergänzen und Aufspalten haben wir bereits oben im Beispiel der Stückliste gesehen. Zusammenlegen und Löschen sind genau die Umkehrfunktionen. Im Beispiel benötigen wir sie, wenn wir die Optimierung zum Zwischenspeichern des Gesamtmaterialpreises wieder entfernen wollen. Diese horizontalen Schritte lassen sich nicht durch eine einfache Abbildung repräsentieren. Zum Beispiel benötigt das Zusammenlegen eine Abbildung in Richtung der Entwicklung, das Aufspalten aber eine Abbildung gegen die Richtung der Entwicklung. Das Ergänzen kann durch eine nicht surjektive Abbildung in Richtung der Entwicklung repräsentiert werden. 20 Das Löschen erfordert eine nicht surjektive Abbildung gegen die Entwicklungsrichtung. 21 Zur Darstellung der Weiterentwicklung benötigen wird also allgemeine Relationen: CE5: Ein (horizontaler) Entwicklungsschritt w: M M' des Continuous Engineering von einem Modell M zu einem Modell M' auf demselben Abstraktionsniveau wird repräsentiert durch ein Paar von Abbildung (l: D M, r: D M'). Dabei repräsentiert die linke Seite l das Löschen und Aufspalten und die rechte Seite r das Hinzufügen und Zusammenfassen. Die horizontalen und vertikalen Entwicklungsschritte besitzen komplexe Konsistenzbedingungen. Denn jeder horizontale Schritt hat Auswirkungen auf (1) die ggf. vorhandenen Abstraktionen sowie auf (2) die ggf. vorhandenen Konkretisierungen. Betrachten wir zunächst einen horizontalen Schritt w = (l: D M, r: D M') im Zusammenspiel mit einer Abstraktion s: M N. Zunächst ist folgende Frage zu beantworten: Wann ist w mit s kompatibel? (a) Da Abstraktionen surjektiv sind, muss die linke Seite l muss dafür sorgen, dass jede Abstraktion repräsentiert bleibt. Das bedeutet, dass l nicht komplette Äquivalenzklassen bzgl. s löscht. (b) Die rechte Seite r darf nur Objekte zusammenfassen, die dieselbe Abstraktion haben. Außerdem ist für jedes neue Objekt in M' eine Abstraktion anzugeben. Sind diese Anforderungen erfüllt, kann man die neue Abstraktion s' berechnen. Die Abstraktion für D ergibt sich durch s l: D N. Die Abstraktion für M' ist für alle neuen Objekte entweder di- 20 Genau die Objekte ohne Urbild sind neu. 21 Gelöscht werden genau die Objekte, die kein Urbild haben.

19 rekt durch den horizontalen Schritt definiert oder ergibt sich für alle anderen Objekte x durch s l (y) für r(y) = x. 22 Nun zu den Auswirkungen auf die konkreteren Ebenen. Hier gibt es keine Vorbedingungen. Das Löschen von Objekten führt zum Löschen aller Konkretisierungen. Neue Objekte werden identisch auf der konkreten Ebene repräsentiert. Das heißt für jedes neue Objekte wird dasselbe Objekt auch auf allen konkreteren Ebenen erzeugt und auf das auf der nächst höheren Ebene abgebildet. Solange diese Form der identischen Repräsentation vorliegt, kann auch das Aufspalten und Zusammenfassen von Objekten (identisch) auf die konkreteren Ebenen fortgesetzt werden. Sind aber tatsächliche vertikale Entwicklungsschritte ausgeführt worden, muss die gesamte (vertikale) Entwicklung für zusammengefasste bzw. aufgespaltene Objekte erneut durchgeführt werden (Forward Engineering für den betroffenen Teil). Dieses System der vertikalen und horizontalen Entwicklungsspuren strukturiert das jeweilige Ergebnis des Entwicklungsprozesse so, dass alle Auswirkungen jeder weiteren Änderung sofort bestimmt werden kann. So erhält der Entwickler unmittelbare Information darüber (1) ob seine Veränderung auf dem richtigen Abstraktionsniveau angesiedelt ist und (2) welche Konkretisierungen erneut zu entwickeln sind. Ein (Buchhaltungs-)Werkzeug, das in der Lage ist, solche Spuren zu verwalten, geht damit deutlich über eine simple Versionsverwaltung hinaus. Es sollte der zentrale Bestandteil einer Continuous Engineering Workbench (CEW) sein. Mehr Komfort (über die reine Verwaltung hinaus) kann dann erzielt werden, wenn typische Muster sowohl für die vertikale als auch die horizontale Entwicklung im Werkzeug prototypisch so hinterlegt werden, dass sie als atomare Schritte (Refaktorisierungen) abgerufen und automatisch eingebaut werden können. Mehr dazu im nächsten Abschnitt. ClassA (a) ClassA' ClassA ClassA (b) ClassA ClassA' Abbildung 10: Einführung von Indirektion Automatisierung Viele Entwicklungsschritte folgen vorgefertigten Mustern. Die Umsetzung von Modellen mit Mehrfachvererbung in solche ohne Mehrfachvererbung haben wir beispielsweise schon oben besprochen, vergleiche Abbildung 2. Dabei muss ggf. das Muster angewendet werden, das aus einer abstrakten Klasse den konkreten Anteil heraus schält, vergleiche Abbildung 3. Die Einführung von Rollen (Abbildung 5) ist ein weiteres Beispiel. Dieses Muster kann sowohl vertikal wie horizontal eingesetzt werden. Grundlage vieler Muster auch des Rollenmusters ist die Einführung von Indirektionen über (a) Vererbungsbeziehungen oder (b) Assoziationen, vergleiche Abbildung 10. Indirektionen sind auch die Grundlage der Veränderungen im Beispiel: Optimierung einer Stückliste auf Seite 14, vergleiche Abbildung 7 und Abbildung 8. Die Einführung eines Observers 22 Die Eindeutigkeit dieser Definition folgt daraus, dass nur innerhalb von Äquivalenzklassen zusammengelegt wird.

20 (Abbildung 4) zur Realisierung einer symmetrischen Beziehung ist ein weiteres Beispiel für einen vertikalen Entwicklungsschritt, der einem standardisierten Muster folgt. Das gesamte Entwicklungsszenario wird wesentlich vereinfacht, wenn alle vertikalen Entwicklungsschritte aus der Anwendung vorgefertigter automatisierter Muster bestehen. Automatisiert heißt hier, dass die Angabe des verwendeten Musters und der Stelle im abstrakten Modell reicht, um den Entwicklungsschritt vollständig (inklusive Rückabbildung der erzeugten konkreten Objekte) maschinell zu ergänzen. Dann reduziert sich das Continuous Engineering ausschließlich auf die horizontalen Schritte. Die vertikalen Schritte müssen nicht mehr repräsentiert werden. Sie werden nur im abstrakten Modell spezifiziert (Angabe von Muster/Stelle-Paaren) und ihre Ausführung wird einem Transformationswerkzeug überlassen. Ein solches Transformationswerkzeug ist eine Art Compiler: Aus einer auf hohem Abstraktionsniveau geschriebenen Quelle (bei einem Compiler in einer Programmiersprache) wird vollautomatisch das ausführbare Zielsystem mit derselben Semantik erstellt (bei einem Compiler nativer Zielcode des Hardwaresystems oder Code für eine virtuelle Maschine). Der entscheidende Vorteil eines Szenarios mit einem solchen Transformationswerkzeug ist, dass ausschließlich auf der höchsten Abstraktionsstufe entwickelt wird. Alles Vertikale ist weg-rationalisiert. Dann ist es eigentlich auch nicht mehr nötig, die horizontalen Schritte so aufwändig, wie oben dargestellt, als Relation zu repräsentieren. Bei jeder Veränderung des Modells von M nach M' kann die automatisch erzeugte vertikale Entwicklung für M vollständig gelöscht werden. Denn die neue vertikale Entwicklung für M' kann ausschließlich aus den in M' enthaltenen Informationen erzeugt werden. 23 Wir werden allerdings weiter unten sehen, dass es nicht möglich ist, auf die Repräsentation der horizontalen Ebene vollständig zu verzichten. Sie ist nötig, wenn wir eine automatische Migration vorhandener Datenbestände aus dem alten in das neue Modell benötigen. Wir werden im weiteren Skript untersuchen, in wie weit ein solches verlockendes Entwicklungsmodell realistisch ist. Es ist deswegen verlockend, weil es uns erlaubt, ein Anwendungssystem gleichzeitig (i) auf dem höchst möglichen Abstraktionsniveau zu beschreiben und (ii) an beinahe jede vorhandene Betriebs- und Entwicklungstechnik anzupassen. Die Eigenschaft (i) führt dazu, dass wir ein rein fachliches System 24 zum Ausgangspunkt jeder Entwicklung machen können. Ändert sich die Betriebs- oder Entwicklungstechnik, ist nur der vertikale Transformationsprozess (ii) anzupassen, die fachlichen Funktionen können unverändert übernommen werden. Ändert sich die Fachlichkeit, ist nur das abstrakte Modell (i) anzupassen, die Mechanismen der vertikalen Transformation (ii) bleiben gleich und können wieder verwendet werden. Auf diese Art und Weise wird ein Maximum an Entkopplung von fachlicher Funktion und technischer Umsetzung erreicht. Dabei ist zu beachten, dass Fachliche Beschreibung auf dem höchst möglichen Abstraktionsniveau nicht heißt, dass die Beschreibung in irgendeiner Weise unvollständig ist. Das gesamte System ist beschrieben und nach automatischer vertikaler Transformation auch ablauffähig. 25 Abstrahiert ist von den Details der Betriebstechnik (zum Beispiel Benutzeroberflächen, Mehrbenutzerkoordination oder Persistenz) und der Entwicklungstechnik (zum Beispiel Einschränkung auf einfache Vererbung, Abwesenheit symmetrischer Assoziationen oder Einschränkung der Polymorphie ausschließlich auf den Empfänger 26 ). Natürlich sind auch ausreichend Testfälle auf dem ab- 23 Auch die alte vertikale Entwicklung für M lässt sich jederzeit wieder aus den in M enthaltenen Informationen gewinnen. 24 Eine solche Beschreibung fehlt derzeit in den meisten Projekten (siehe oben). Meist liegen nur Beschreibungen vor, die fachliche und technische Aspekte mischen. Dabei verstellt die Technik den klaren Blick auf das fachliche Modell und umgekehrt. 25 Das Wort Abstraktion kommt aus dem Lateinischen abstrahere, das wegziehen oder abziehen bedeutet und nicht weglassen. 26 Allgemeine Polymorphie ermöglicht die Spezialisierung von 2 oder mehr Parametern (Empfänger und ein oder mehr Parameter) einer Operation, wie etwa in LOMF.