In den 80er Jahren wurde der CASE-Eineatz durch hohe Startinvestitionen und Verunsicherung der Anwender erschwert. Diese Hemmnisse waren, so Jürgen Schmitz*, darauf zurückzuführen, daß es sich bei den verfügbaren Werkzeugen durchweg um Insellösungen handelte. Der Ansatz für die 90er Jahre sei hingegen die integrierte Umgebung.

Insellösungen waren die CASE-Tools des vergangenen Jahrzehnts in vielerlei Hinsicht: Sie unterstützten einzelne, zum Teil nicht normierte Methoden, bedienten sich "selbstgestrickter" Benutzeroberflächen, arbeiteten mit einfacher Datenhaltung ohne Datenbanken und waren nicht auf Standardhardware verfügbar.

Daraus resultierten eine Reihe von Hemmnissen für eine breitere Durchdringung des Marktes mit CASE: Die Technologie erforderte hohe Startinvestitionen in Hardware und Ausbildung; sie führte zudem - durch fehlende Standards und Glaubenskriege - zu einer Verunsicherung potentieller Anwender, und sie litt unter mangelnder Offenheit, wenn es um die Einbettung angebotener Werkzeuge in bestehende Entwicklungswelten ging.

Nicht mehr bloß ein Schlagwort

Als wichtigstes Erfolgskriterium bei den CASE-Tools der 90er Jahre gilt hingegen die Integrationsfähigkeit. Inzwischen ist der Begriff der Integration seiner Funktion als bloßes Schlagwort entwachsen und mit konkretem Inhalt gefüllt. Integration drückt sich in vielen verschiedenen Formen aus, die in einigen Grundformen zusammengefaßt werden können: Integration der Methoden und der Datenhaltung sowie Zusammenführung an der Benutzeroberfläche und über unterschiedliche Lifecycle-Phasen sind hier zu nennen.

Zum Schlüsselfaktor wird dieses Charakteristikum, weil es die Möglichkeit bietet, Fehler zu vermeiden, indem durch Datenintegration Ergebnisse einer Entwicklung einfacher miteinander verknüpft und auf Konsistenz beziehungsweise Redundanz geprüft werden können. Ein Beispiel: Während ein normales CASE-Tool Daten und Funktionen modellieren kann, prüft ein hochintegriertes Werkzeug auch, ob die Funktionen die Daten korrekt benutzen.

Integration beschleunigt zudem den Entwicklungsprozeß, da ähnliche oder verwandte Informationen nur einmal eingegeben werden müssen. Als Beispiel seien hier Codegeneratoren und Dokumentationswerkzeuge angeführt.

Mit dem Charakteristikum der Integration ist das computergestützte Software-Engineering auch leichter erlernbar - aufgrund der gleichen Benutzerschnittstelle beziehungsweise einer höheren Verarbeitungskomplexität. Sichtbarer technischer Beleg für die Bedeutung der Integration in der Industrie sind das Engagement der Hardwarehersteller, die Repositories als strategisches Werkzeug für die CASE-Integration anbieten, sowie die Forschungsvorhaben (Esprit, European Software Factory), die sich das Thema Integration zum Ziel gesetzt haben.

Funktionen worden leichter austauschbar

Mit den Repositories bieten die Hardwarehersteller Werkzeuge zur Datenintegration; außerdem stellen sie den Rahmen für eine Integration an der Benutzeroberfläche zur Verfügung. Doch sollte dieses Angebot lediglich als ein Rahmen betrachtet werden, da es darüber hinaus sehr viel größere Integrationsmöglichkeiten gibt - beispielsweise über die Modellierung von Daten und deren logische Beziehungen.

Ein Datenmodell ist eine Navigationshilfe zur Sicherung beziehungsweise Steigerung des Wertes von Informationen. Diese Informationen aus Daten über Kunden oder Produkte in Vertriebsorganisationen sowie aus Produktivitäts- oder Qualitätsdaten in der Fertigungsindustrie bestehen.

Außerdem ist das Datenmodell eine Art Straßenkarte, die zeigt, über welche Zugriffspfade man Informationen erreichen kann und wie Informationen sinnvoll zu verknüpfen sind, um neue Aussagen zu erhalten. Daraus kann eine höhere Wiederverwendbarkeit bei der Software-Entwicklung resultieren, weil Verarbeitungsfunktionen, die auf dem gleichen Datenmodell basieren, leicht ausgetauscht werden können.

Für die Datenmodellierung hat Peter Chen das Entity-Relationship-Diagramm entwickelt (siehe Kasten). Diese Methode entspricht dem Standard für Datenmodellierung in der Requirement-Phase. Darüber hinaus existieren Regeln für die Kooperation mit anderen Requirement-Methoden. Die Standardisierung bedingt in diesem Fall eine Herstellerunabhängigkeit und verschafft Vorteile in der Ausbildung.

Die Frage der Integration von Methoden über Phasengrenzen hinweg ist durchaus nicht trivial. Ziel ist es, Inhalte zwischen Phasen automatisch umzusetzen (zum Beispiel das Design aus dem Pflichtenheft) sowie Rückwirkungen zwischen einzelnen Abschnitten der Entwicklung zu erkennen und zu kontrollieren. Innerhalb einer Phase ist die Methodenintegration eine bekannte Technologie, in der Anforderungsphase gehört sie sogar zum Stand der Technik. Erinnern wir uns an den Beginn der 80er Jahre: Damals entbrannte ein Glaubensstreit um die "richtige" Methode, auch bezüglich der Frage der Datenoder Funktionsorientierung.

Inzwischen sind die Anwendungen inhaltlich zusammengewachsen; so wurde in Automatisierungsprojekten Datenbanken unverzichtbar. Die Methodenexperten sind sich deshalb heute einig: Man braucht die Daten-Funktions- und Zustandsmodellierung zur Erarbeitung von Anwendungen.

Die Unterschiede liegen in der Gewichtung der Modelle. Während bei der Automatisierung eines Flugzeug-Cockpits vielleicht 80 Prozent Zustandsmodellierung, 18 Prozent Funktionsmodellierung und zwei Prozent Datenmodellierung anfallen, ist das Verhältnis bei einer Prozeßautomatisierung eher ausgewogen, bei Datenbank-Anwendungen hingegen sehr umgekehrt.

Außerdem sind die Basismethoden de facto mit der Structured Analysis nach Yourdon (für die Funktionsmodellierung), der Realtime-Methode nach Ward/Mellor oder Pirbhai/Hatley (für Echtzeit-Modellierung) und der Entity-Relationship-Methode nach Chen (für die Datenmodellierung) standardisiert. Integrationsregeln zwischen den Methoden sind bekannt und werden von den Tools auch unterstützt.

Der Vorteil der Methodenintegration liegt für den Anwender in einer größeren Anwendungsbreite: Durch die Zusammenführung von Methoden läßt sich ein höherer Standardisierungsgrad innerhalb von Unternehmen erzielen, die CASE für verschiedene Anwendungen einsetzen wollen.

Mehr und frühere Fehlererkennung ist ein weiteres Plus. So lassen die 18 Prozent Funktionsmodellierung aus dem oben genannten Beispiel zusätzliche Konsistenzprüfungen auf die 80 Prozent Zustandsmodellierung zu.

Die Verknüpfung der Methoden kann beispielsweise über das Data-Dictionary erfolgen, das alle Datenstrukturen dokumentiert.

Die Idee dahinter ist, daß alle Datenbeschreibungen, sei es im Funktions-, Zustands- oder Datenmodell, derselben Syntax und Semantik folgen. Jede Informationseinheit des Datenmodells (Entity oder Relationship) muß im Funktionsmodell mindestens einmal repräsentiert sein und umgekehrt.

Wenn Informationen zwischen Methoden überschneidend auftreten, werden sie nur einmal beschrieben, und die Überschneidung wird zu Plausibilitätsprüfungen benutzt.

Je besser die Methodenintegration gelöst ist, desto mehr profitieren die Tools davon - in Form höherer Funktionalität. Beispiele für Zusatzfunktionalität sind Prüfungen zwischen dem Auftreten von Entities/Relationships in Datenmodellen sowie ihrem korrespondierenden Auftreten als Stores im Datenfluß-Diagramm.

Ein äußeres Zeichen der Datenintegration und ein guter Testfall für den Grad der Integration ist das Umbenennen von Entwicklungsobjekten. Entschließt man sich beispielsweise, den Begriff "Datum" in Rechnungsdatum umzubenennen, so muß die Umbenennung nicht nur im Data-Dictionary, sondern auch in der Beschreibung der Rechnungserstellung, im Datenmodell, kurz: bei allen Verwendungsstellen, konsistent durchgeführt werden.

Zwei Sichten stehen für die Betrachtung eines Datenmodelles zur Verfügung. Aus "logischer Sicht" wird betont, ob und in welchem Zusammenhang die Daten stehen, aber nicht, wie diese Zusammenhänge implementiert werden. Dem gegenüber steht die physikalische Sicht, die zeigt, wie Daten auf ein Datenbanksystem verteilt werden, um die Vorgaben mit adäquater Performance bearbeiten zu können.

Wegen dieser unterschiedlichen Sichtweise reicht es nicht, ein Datenmodell im Verhältnis 1:1 aus der logischen in die physikalische Sicht zu transformieren. Davon abgesehen lassen sich einige Elemente eines Datenmodells in herkömmlichen Datenbanken gar nicht direkt implementieren (n-zu-m-Beziehungen). Auf dem Markt existieren allerdings Module, die eine solche Transformation für relationale Datenmodelle von Anwendungsentwicklungs-Systemen durchfuhren.

Probleme bei der Teamarbeit

Die Zusammenfassung aller Daten-Informationen in nur einem Datenmodell ist nicht praktikabel; ab einer bestimmten Größe ist dies unübersichtlich, schwer zu entwickeln und schafft Konflikte, wenn mehrere Mitglieder am Datenmodell arbeiten wollen.

CASE-Tools neuerer Technologie bieten eine Möglichkeit, solche Konflikte durch Integration von Teamarbeit zu lösen. Die verschiedenen Mitglieder des Teams pflegen dort jeweils separate Teile eines Datenmodells, zum Beispiel die Parts, die von verschiedenen Anwendungen benötigt werden. Dadurch werden Zugriffskonflikte vermieden.

Weil bei dieser Art der Arbeitsteilung Inkonsistenzen auftreten können (widersprüchliche Benutzung von Entities, die in mehreren Teilmodellen vorkommen), sind Konsistenzprüfungen erforderlich. Diese werden von modernen Tools mitgeliefert - und mehr noch: Die Integration verschiedener Datenmodelle auf grafischem Weg zu einem großen, geschlossenen Datenmodell gehört ebenfalls dazu.

Die Pflege dieses globalen Datenmodells erfolgt zweckmäßigerweise weiterhin auf der Ebene der Teilmodelle, denn Änderungen in einem Teilmodell können für das globale Modell nachvollzogen werden. Diese Technik wird auch angeboten, um bottom-up aus bestehenden Anwendungen unternehmensweite Datenmodelle ableiten und pflegen zu können. Der Vorteil ist der, daß Tool-gestütztes Arbeiten auch in komplexen Systemen praktikabel ist.

Die Integration des CASE-Prozesses ist und bleibt, die wichtigste Aufgabe für die Software-Anbieter. Diese Aufgabe kann von den Repository-Anbietern allein nicht wahrgenommen werden; denn Integration hat mehr Ausprägungen als lediglich die Datenintegration durch Repositories.