Vorgehensweise Schritt für Schritt durch die Komponentenbasierte Reorganisation Die Vorgehensweise der komponentenbasierten Reorganisation umfaßt methodische Schritte, Regeln und Beispiele, die in sogenannten Workflows zusammengefaßt sind, und beschreibt praxisnah die Umsetzung der Konzepte. Sie setzt auf den Elementen vorhandener, praktisch erprobter Vorgehensweisen des Reverse-, Re- und Forward-Engineering auf. Sie adaptiert und erweitert Elemente dieser Vorgehensweisen und fügt neue, für die komponentenbasierte Reorganisation spezifische Elemente hinzu. In insgesamt acht Workflows beschreibt die Vorgehensweise der komponentenbasierten Reorganisation das Zusammenspiel der einzelnen Aktivitäten und die Verwendung der dabei erstellten Artefakten. Abbildung 8 – Überblick über die Aktivitätenabfolge der Vorgehensweise zu komponentenbasierten Reorganisation In einem Inventur-Workflow (INV) steht die Untersuchung des Altsystems auf Benutzersicht im Vordergrund. Dabei wird der Anwendungsbereich des Altsystems erfaßt und die vom Altsystem erbrachte fachliche Funktionalität dokumentiert. Die Ergebnisse dieses Workflows fließen in eine Anforderungsanalyse (ANF-Workflow) ein. Während der Anforderungsanalyse werden die Anforderungen an das zu entwickelnde Sollsystem erfaßt. Darauf aufbauend wird eine objektorientierte Analyse (ANA-Workflow) durchgeführt. In der objektorientierten Analyse werden Klassen und Objekte, sowie deren Attribute, Methoden und Beziehungen identifiziert. Im Design werden die Analysemodelle komponentenbasiert weiterentwickelt (DES-Workflow). In den vorhandenen Modellen werden bestehende Klassen und Objekte verfeinert und neue Klassen und Objekte eingefügt. Die Modellelemente werden strukturiert und auf Teilkomponenten einer Business Object Component abgebildet. Bis zu diesem Punkt blieben die Details der technischen Realisierung des Altsystem weitgehend unbeachtet. Dadurch wurde sichergestellt, daß die Strukturen, die die Designmodelle zeigen, nicht durch die technische Realisierung des Altsystems bestimmt sind und so die weiter oben geforderten Eigenschaften aufweisen. Parallel zum, aber unabhängig vom DES-Workflow, werden die Zusammenhänge im Altsystem beleuchtet (REV-Workflow). Besonders wichtig ist die Dokumentation der Funktionen, der Relationen und ihrer Beziehungen untereinander. Nur wenn bekannt ist, welche Funktionen Tupel welcher Relationen lesen oder manipulieren kann sichergestellt werden, daß Softwarebausteine nur Daten ihrer Teildatenbanken benutzen. Die Ergebnisse des REV-Workflows fließen in den DES-Workflow ein und führen zu einem Abgleich. Als Ergebnis entsteht ein Modell, daß die Funktionalität und Teile der Datenbank berücksichtigt, die wiederverwendet werden können. Außerdem enthält es Vorgaben für die Gestaltung der neu zu entwickelnden Funktionalität. Die Vorgaben des DES-Workflows werden während der Implementierung (IMPL-, INT- und TEST-Workflow) umgesetzt. Dazu werden Funktionen des Altsystems isoliert und zu Softwarebausteinen zusammengefügt. Korrespondierend zu den Funktionen werden Teile der Datenbank des Altsystems isoliert und in Teildatenbanken angelegt. Für die neu zu entwickelnde Funktionalität werden Klassen und Objekte implementiert und in Komponenten zusammengefaßt. Die Komponenten, Softwarebausteine und Teildatenbank werden dann zu einem Sollsystem integriert und getestet. Bei der Einführung (EINF-Workflow) muß als zentrale Aktivität der Datenbestand des Altsystems in die Teildatenbanken des Sollsystems überführt werden.