Konzepte der komponentenbasierten Reorganisation Wie funktioniert KoReo? Für die Zerlegung der Anwendung und der Datenbank in einzelne Teile wurde das Konzept der Bausteine eingeführt. Ein Baustein umfaßt einen Teil der Anwendungslogik, den sogenannten Softwarebaustein, und einen Teil der Datenbank, die sogenannte Teildatenbank, (und eine vollständige Instanz des DBMS). Die Softwarebausteine sind so gestaltet, daß sie nur solche Funktionen und Prozeduren (Routinen) des Altsystems enthalten, die auf Daten zugreifen, die in der dem Softwarebaustein zugeordneten Teildatenbank gespeichert sind. Die Untersuchung von Möglichkeiten zur Datenbankaufteilung hat gezeigt, daß die Fragmentierung von Relationen und die Zuweisung einzelner Fragmente an Teildatenbanken eine geeignete Möglichkeit bietet, den Datenbestand aufzuteilen. Die Zuweisung vollständiger Relationen an Teildatenbanken ist auch möglich. Für die Möglichkeiten zur Strukturierung der Anwendungslogik wurden objektorientierte und komponentenbasierte Konzepte betrachtet. Das zentrale objektorientierte Konzept ist das Objekt. Die Identifikation von Objekten orientiert sich während der Anwendungsentwicklung (speziell der Anforderungsanalyse und Analyse) an Dingen der realen Welt oder der Vorstellungswelt. Allerdings sind Objekte nur im Zusammenspiel mit anderen Objekten in der Lage eine bestimmte fachliche Funktionalität zu erbringen. Objekte sind aufgrund ihrer geringen Granularität nicht als Strukturen geeignet, die Anforderungen an Softwaresysteme, wie sich aus dem Business Reengineering ableiten lassen. Objekte können zu Komponenten zusammengefaßt werden. Diese Komponenten erbringen eine bestimmte fachliche Funktionalität selbst, sind jedoch keine vollständigen Anwendungen. Das Konzept der Business Objects erweitert das Konzept der Komponenten um verschiedene Aspekte. Zentral für die komponentenbasierte Reorganisation war die Tatsache, daß Business Objects realen oder mentalen Dingen des Anwendungsbereichs entsprechen. Damit ist eine Aussage zur fachlichen Funktionalität und zum Umfang der benötigten Daten getroffen, die für ein Business Object benötigt werden. Mit dem Konzept der Business Object Component werden darüber hinaus die logischen Ebenen beschrieben. Um Softwarebausteine und Teildatenbanken im Altsystem identifizieren zu können, muß bekannt sein, welche fachliche Funktionalität Softwarebausteine realisieren, welche logischen Schichten Softwarebausteine umfassen und welche Daten in der Teildatenbank enthalten sein sollten. Die Orientierung an dem Konzept der Business Object Component, während der Zerlegung des Altsystems in Softwarebausteine und Teildatenbanken, führt zu Strukturen, die zwei wichtige Eigenschaften miteinander verbinden. Die Strukturen sind deutlich kleiner als vollständige Anwendungen, realisieren aber eine fachliche Aufgabe vollständig allein. Auf die Datenbank bezogen bedeutet dies, daß Strukturen entstehen, die nicht mit dem vollständigen Datenbestand arbeiten, der für die gesamte Anwendung notwendig wäre. Hier zeigt sich eine Lösungsmöglichkeit für die Very Large Database-Problematik. Gleichzeitig sind die entstehenden Strukturen so flexibel einsetzbar, daß sie den Anforderungen genügen, die der kontinuierliche Wandel im Unternehmensumfeld an die Softwareentwicklung stellt. Dadurch können die Problemstellungen betriebswirtschaftlicher Anwendungsfelder gelöst werden. Auf die Anwendung bezogen sind diese Strukturen geeignet, um die Anforderungen zu erfüllen, die sich aus dem Business Reengineering ableiten lassen. Durch die Orientierung am Konzept der Business Object Component können während der Zerlegung der Datenbank des Altsystem kohärente Teile im Schema der Datenbank identifiziert und von anderen Teilen abgegrenzt werden. Aus diesen Teilen wird die Teildatenbank erstellt. Durch die Orientierung am Konzept der Business Object Component kann die Granularität von Softwarebausteinen bestimmt und die Zerlegung des Altsystems gesteuert werden. Außerdem wird so sichergestellt, daß die Granularität eines Softwarebausteins mit der Teildatenbank korrespondiert. Es ist allerdings nicht möglich, die gesamte Funktionalität des Altsystems wiederzuverwenden. In der Literatur gibt es unterschiedliche Angaben aus vergleichbaren Projekten. Obwohl die konkreten Angaben sehr unterschiedlich sind, liegt die Wiederverwendungsquote immer in einem Bereich von 50 bis maximal 90 Prozent. In den Softwarebausteinen kann die Funktionalität des Altsystems zur Darstellung der Benutzeroberfläche nicht wiederverwendet werden. Andernfalls würde es dazu führen, daß die Softwarebausteine nicht auf verschiedene Rechner verteilt werden könnten. Es gibt weitere Funktionalität, die aufgrund der Aufteilung der Anwendungslogik nicht wiederverwendet werden kann oder soll. Wenn die nicht-wiederverwendete Funktionalität für die Zusammenarbeit innerhalb eines globalen Sollsystems notwendig ist, muß sie neu entwickelt werden. Auch aufgrund der Datenbankaufteilung in mehrere Teildatenbanken, muß zusätzliche Funktionalität neu entwickelt werden. Sie realisiert Funktionen, die Eindeutigkeit des Primärschlüssels einer fragmentierten Relation garantieren, die referentielle Integrität sichern oder alternative Formen zur Sicherung der Modellintegrität zur Verfügung stellen. Zu dieser Funktionalität gibt es keine direkte Entsprechung im Altsystem, da die beschriebenen Aufgaben dort vom Datenbankmanagementsystem übernommen wurden. Eine Neuentwicklung ist dieser Funktionalität ist daher unumgänglich. Die nicht-wiederverwendete und zusätzliche entwickelte Funktionalität kann in neuen Komponenten realisiert werden. Um die Zusammenarbeit der Komponenten mit den Softwarebausteinen zu ermöglichen, können Softwarebausteine „verpackt“, d.h. mit einer Kapselung, der sogenannten Wrapper-Schale, umgeben werden. Die Softwarebausteine verbleiben in ihrer Ursprünglichen Umgebung (Hardware, Betriebssystem, Laufzeitumgebung), erscheinen dann aber als Komponenten. Die Details ihrer Realisierung bleiben durch die Wrapper-Schale verborgen. Softwarebausteine können genau wie neu entwickelte Komponenten im Sollsystem verwendet werden. Für die Zusammenarbeit von Komponenten, (verpackten) Softwarebausteinen und ihren Teildatenbanken sind verschiedene Dienste notwendig. Beispielsweise werden Dienste zur Sicherstellung von globalen Transaktionen, zum Ausschluß eines gleichzeitigen Zugriffs, für Sicherheit und Schutz der Zusammenarbeit und zur Darstellung der Benutzeroberfläche benötigt. [1] Es ist nicht zwingend notwendig, daß eine Datenbankanwendung den Ausgangspunkt bildet. Ebensogut könnte eine Anwendung ohne Datenbanksystem den Ausgangspunkt bilden. Das Beispiel einer Datenbankanwendung bietet jedoch erst die Möglichkeit, die Konzepte, Vorgehensweisen und Werkzeuge der komponentenbasierte Reorganisation in ihrem vollen Umfang zu erläutern. [2] Der Begriff der Teildatenbank wird als Oberbegriff für einen Teil der Ausgangsdatenbank und eine vollständige Instanz des Datenbankmanagementsystems benutzt. Er soll betonen, daß die Datenbank des Ausgangssystem in kleinere Teile zerlegt worden ist, das Datenbankmanagementsystem aber weiterhin vollständig ist. Daher wird der Begriff Teildatenbank (und nicht z.B. Teildatenbanksystem) benutzt. [3] [Hammer&Champy, 1994] [4] vgl. [Noak, 1998], S. 1602 [5] vgl. [Griffel, 1998], S. 23 [6] vgl. [Hammer&Champy, 1994] [7] vgl. [Gerth, 1998] [8] vgl. [Link, 1998] [9] [Gernot&Dern, 1998], S. 77 [10] Da die Softwarebausteine durch die Wrapper-Laufzeitumgebung bei Bedarf in den Speicher geladen werden, gibt es im Task-Manager noch keinen K_KPA-Softwarebaustein, der zur Datenbank KKPADB korrespondiert. [11] Da die Black-Box eingeführt wurde, wird im folgenden auch weiterhin von Black-Box gesprochen, obwohl diese Bezeichnung während der Untersuchung ihrer Inhalte streng genommen nun keine Berechtigung mehr hat.