CASE-Systeme arbeiten heute häufig noch so wie Anwendungssysteme vor 20 Jahren: Sie sind nicht integriert in andere Anwendungen und konzentrieren sich auf Benutzeroberflächen und auf Funktionalität. Werner Dreesbach* beschreibt, warum die Datenintegration in einer gemeinsamen Entwicklungsdatenbank - einem Repository - notwendig ist und welche Produkte und Funktionen in einem Repository-Umfeld von Bedeutung sind.

Flexibilität, Offenheit, Erweiterbarkeit oder Portabilität lassen sich erleben, sie sind für Anwender gemacht. Starrheit, Geschlossenheit, Enge oder Betriebssystem-Fixierung akzeptieren Anwender nicht lange. Voraussetzung für gute Architekturen ist auch bei Software-Architekturen das professionelle Engagement der Architekten.

Die Architektur repositorybasierter Software-Entwicklungsumgebungen unterscheidet sich von vielen anderen Konzepten alleine schon durch die einheitliche Führung aller Informationen in einer gemeinsamen Datenbank Informationen sind nicht nur Entwicklungsdaten, sondern auch die Methoden und Vorgehensweisen, die beschreiben, wie in Projekten diese Entwicklungsdaten erarbeitet werden.

Bosis des Repositories: die Informationsmodelle

Simulieren wir einfach eine derartige Umgebung in unseren Gedanken, ziehen wir uns einen Datenhandschuh an und tasten uns durch die Produkte und Funktionen in einem in der Praxis wirklich existierenden Repository-Umfeld - und nicht in einem Umfeld, auf das wir noch mehrere Jahre warten müssen!

Die Basis jedes Repositories sind Informationsmodelle. In einem Informationsmodell wird beschrieben, welche Objekttypen mit welchen Attributen verwaltet werden und welche Relationen zwischen den einzelnen Objekttypen aufgebaut werden können. Erst durch die Festlegung der Informationsmodelle wird die Aufgabe des Repositories festgelegt. Informationsmodelle können Standards darstellen - wie IBMs Information Model - oder unternehmensspezifisch aufgebaut werden. Die freie Definierbarkeit der Informationsmodelle erlaubt Einsatz auch außerhalb der klassischen Anwendungsgebiete.

In einem Repository kann - technisch gesehen - jedes Objekt mit jedem anderen und mit sich selbst verknüpft werden. Erst durch die Definition des Informationsmodells wird diese Flexibilität eingeschränkt auf das fachlich Sinnvolle. Zum Aufbau der Relationen genügt bei einigen Systemen die textliche Erwähnung eines anderen Objekts in einem Objekt. Das Repository wird somit wie in PC-gestützten Hypertext-Systemen aufgebaut. Bei anderen Systemen sind syntaktische Regeln einzuhalten, um die gleiche Funktionalität zu erreichen.

Alle Relationen können mit beliebigen Zusatzinformationen belegt werden, die wiederum ausgewertet werden können. Zusatzinformationen sollten nicht auf festgelegte Werte beschränkt, sondern frei definierbar sein, um die reale Umwelt wirklich abbilden zu können und nicht immer wieder auf Kunstgriffe angewiesen zu sein.

Objekte können Zustände hinsichtlich ihrer strukturellen Einbettung und hinsichtlich ihres Bearbeitungsstands haben. Zwischen produktiven und in Entwicklung befindlichen Objekten wird im Rahmen einer Versionsverwaltung unterschieden. Die Bearbeitung von Objekten erfolgt über frei wählbare Editoren. Auswertungen können in verschiedenen Darstellungen erfolgen. Die Darstellung aller hinterlegten Relationen in grafischen Netzen, Strukturdiagrammen für Übersichten und Verwendungsnachweise. Matriken, E/A-Matriken, N2-Matriken und Präzedenz-Matriken sind Kontrollinstrumente für Hierarchie-, Netz- und Schleifenkonstrukte.

Auswertungen müssen nicht bei der Definition der Repository-Struktur festgelegt werden, sondern können dynamisch aufgebaut werden. Ad-hoc-Auswertungen erlauben ein Navigieren in unbekannten Strukturen: Ausgehend von jedem beliebigen Objekt kann über Abfragen zu jedem anderen Objekt was gefunden werden.

Das Ansteuern der Objektbearbeitung ist Aufgabe der Benutzeroberflächen, die mit Hilfe einer Repository Sprache erweiterbar ist. Die Sprache hat verschiedene Anwendungsschwerpunkte: das Einbringen funktionaler Erweiterungen, die Definition von Benutzeroberflächen und die Kopplung zu anderen Werkzeugen. Die hohe Integrationsfähigkeit mit anderen Tools über Schnittstellen macht ein Repository zur Basis eines Trägersystems für Software-Entwicklungsumgebungen .

Die Repository-Anwendungen sollten kompatibel zwischen den unterstützten Betriebssystemen sein. Die Kompatibilität bezieht sich auf die Funktionalität, die verwalteten Informationen und die Benutzeroberflächen. Alle Daten und Meta-Daten - Objekte, Benutzeroberflächen und Repository-Prozeduren - müssen über Import- und Export-Mechanismen zwischen den verschiedenen Betriebssystemen im Großrechner-, Midrange- und PC-Bereich austauschbar sein.

Viele heute verfügbare Software-Entwicklungsumgebungen sind "Dictionary"-gesteuert. Diese integrierten Dictionaries - oder besser Directories - haben meist nur eine einzige Aufgabe: Sie verwalten die in ihrer jeweiligen Umgebung anfallenden Informationen und verknüpfen einen Subset dieser Informationen untereinander.

Dictionaries haben keinen Selbstzweck. Vielmehr sind die hinterlegten Informationen Grundlage für die Generierung von Zielsystemen: Cobol und PL/1 oder IMS- und DL/l-Datenbanken. Das Single-Sourse-Prinzip - jede Information wird nur ein einziges Mal zentral geführt - wird durch die Generierungen und der damit verbundenen Vervielfältigung der Informationen zu einem qualitäts- und produktivitätssteigernden Faktor. Über Bridge-Funktionen müssen Schnittstellen zu anderen Systemen zur Verfügung stehen Generierung für das Directory "Prediet" in Adabas-Umgebungen, Anbindungen des IMS-DD, des DB2-Katalogs oder der Enzyklopädien von IEW/ ADW, IEF oder den Bachman-Tools sind einige Beispiele.

CUA-Konformität ist ein berechtigtes Anliegen

Die Führung der Benutzer übernehmen Produkte, die für das Prozeß- und das Projektmanagement verantwortlich sind Die Schnittstellen zum Benutzer müssen sich an den Möglichkeiten des Betriebssystems orientieren. Eine einheitliche Benutzerführung mit CUA-Konformität ist dabei eine Forderung die heute zu recht gestellt wird Das Prozeßmanagement steuert die objektorientierten und Vorgehensmodell-orientierten Zugriffe auf Informationen des Repositories. Das Projektmanagement führt bei der Planung Kontrolle, Kontierung und Überwachung von Projekten die Regie und ist in die Funktionalität des Prozeßmanagements integriert.

Die Implementierung und die Einführung Repository-gesteuerter Vorgehensmodelle ist in der Vergangenheit häufig an einer zu starren Modelldefinition gescheitert. Es ist naiv zu glauben, daß Projekte gleich welcher Art über ein einheitliches Vorgehensmodell bearbeitet werden können: Umfangreiche Dialog-Vorhaben sind mit Wartungsarbeiten an Batch-Anwendungen nicht zu vergleichen. Und auch Dialog-Vorhaben können sich je nach Aufgabenstellung und Aufwand stark voneinander unterscheiden.

Ein unternehmensspezifisches Phasenmodell ist heute in fast jedem Org./DV-Bereich vorzufinden Das Problem, mit dem Unternehmen konfrontiert wurden, war nicht die Festlegung der Vorgehensweisen für Projekte, sondern die Hinterlegung dieser Vorgehensweisen in einem Trägersystem und die Verwaltung seiner projektspezifischen Ausprägungen.

In jedem Work-Management ist eine Komponente zur Definition und Nutzung unternehmenspezifischer Informations- und Vorgehensmodelle ein Muß. Informationsmodelle beschreiben die Struktur der Informationsablage im Repository und sind somit unabhängig von Vorgehensmodellen, die die Nutzung dieser Informationsstrukturen in Projekten beschreiben .

Auf der Vorgehensmodell-Ebene werden die Phasen, Ergebnisse und Aktivitäten beschrieben. Auf der Basis der Ergebnisse haben die Vorgehensmodelle und Informationsmodelle ihre Nahtstelle: Für jedes Ergebnis wird definiert, in welchen Objekttypen und Attributen es abgelegt werden soll. Für

jede Phase kann zusätzlich bis auf Attributebene hinunter beschrieben werden, ob die entsprechenden Inhalte Muß-, Kann- oder reinen Informations-Charakter haben.

Es müssen beliebig viele Vorgehens- und Informationsmodelle verwaltbar sein. In der Regel wird man für die Aufgaben der Software-Entwicklung nur ein Informationsmodell, aber mehrere Vorgehensmodelle beschreiben. Die Modelle haben unternehmensweite Bedeutung. Projektleiter haben jedoch die Möglichkeit, das für ihr Projekt relevante Modell zu einem Projektmodell maßzuschneidern. Bei dieser Taylorisierung können Phasen, Ergebnisse und Aktivitäten in ihrer Struktur, Anzahl oder Bedeutung für das aktuelle Projekt verändert werden.

Optimierung durch CASE beginnt beim Mitarbeiter

Über einen Driver als Führungsinstrument sieht der Entwickler seine Projektumgebung mit seinem Vorgehens- und Informationsmodell. Phasen können vom Projektleiter geöffnet und geschlossen werden, Projektsichten und unternehmensweite Sichten auf die Informationen werden unterstützt, Mitarbeiter können dem Projekt zugeordnet werden. Mitarbeiterspezifische Berechtigungen und Zugriffsarten lassen sich bis auf Objektebene vergeben, Auswertungen als Standard oder im Ad-hoc-Modus durchlaufen. Aus anderen Projekten können Informationen entliehen, Status-Folgen definiert und gesteuert werden.

Für die Aufbereitung der in der Projektbearbeitung beschriebenen und verknüpften Objekte muß ein integrierter Berichtsgenerator zur Verfügung stehen. Beliebige Handbücher, Glossare oder Managementberichte werden über Formatierer zusammengestellt. Auch die Informations- und Vorgehensmodelle des Meta-Repositories können in Handbuchform ausgedruckt werden.

Die Ansteuerung grafisch orientierter CASE-Tools für Methoden und freie Netzstrukturen, die ein Visualisieren und Bearbeiten aller Informationen eines zentralen oder dezentralen Repositories erlauben, ist ebenfalls Aufgabe des Work-Managements.

CASE hat den Anspruch, die Produktivität in der Anwendungsentwicklung durch qualitative Verbesserungen im Herstellungsprozeß wesentlich zu erhöhen. Wichtige Faktoren für Produktivitätssteigerungen sind zweifelsfrei die erhöhte Effektivität und Effizienz jedes einzelnen Mitarbeiters, die Automatisierung von Abläufen und die Mehrfachnutzung von Bausteinen.

Produktivität entsteht jedoch zuallererst durch gezielte Zusammenarbeit der Mitarbeiter, durch eindeutiges Verstehen und durch den unmittelbaren und direkten Austausch von Informationen. Sie entsteht ferner aus der gezielten Zusammenarbeit von Projektteams untereinander und miteinander. Anwendungssysteme erreichen eine immer stärkere Integration. Diese Integration aber muß auch bei der Software vorhanden sein, mit der diese Systeme gebaut werden - bei den CASE-Produkten.

Vernetzte Arbeitsplätze, gemeinsames Repository

Damit ergibt sich eine zentrale Anforderung an ein CASE-Tool, die allzu oft übersehen wird. Nicht einzelne, voneinander isolierte Arbeitsplätze, sondern vernetzte Arbeitsplätze mit Informationen in einem gemeinsam genutzten Repository sind die Basis für den CASE-Erfolg.

Das Repository muß das gesamte Wissen aller Aufgaben der Software-Entwicklung abbilden können - und nicht nur das Wissen, um in frühen Projektphasen Methoden unterstützen zu können. Noch bevor man an Methoden denkt, ist oft eine grafische Aufbereitung und Analyse von vorhandenen Informationen notwendig. Somit werden Produkte benötigt, die jegliche Informationen - auch solche, die mit Texteditoren, Panels, Re-Engineering-Werkzeugen oder Generatoren erstellt und im Repository abgelegt worden sind, -grafisch aufbereiten und weiterverarbeiten können.

Vier Faktoren bedingen den Methodeneinsatz

Freie Auswahl der Diagramme, der Methoden, der Symbole und der Informationsausschnitte aus einem Repository sind Kennzeichen eines CASE-Tools, die es zu einem universell einsetzbaren grafischen Werkzeug machen .

Will man sofort oder später Methoden einsetzen, so sind vier Faktoren ausschlaggebend:

- die Informationen (Datenflüsse, Funktionsstrukturen, Entities, Relationen, Datengruppen, Module, Programme, Bausteine, Listen, Masken etc. ), die die Voraussetzung oder das Ergebnis beschreiben und einen Ausschnitt aus einem übergelagerten Informationsmodell bilden;

- die grafischen Symbole und deren Abhängigkeiten in Diagrammen;

- die Vorgehensweise sowie die Einzelschritte bei der Anwendung der Methoden;

- die notwendigen Integritäts- und Plausibilitätsprüfungen.

Die Informationen werden unmittelbar als Ausschnitt des Repositories ausgewählt, so daß nicht nur projektinterne Referenzen, sondern auch die Bezüge zu anderen Projekten, zu produktiven Anwendungen und letztlich zu allen anderen im Repository abgelegten Informationen bestehen. Die grafische Aufbereitung und Bearbeitung von Diagrammen erfolgt mit dem entsprechend konfigurierten CASE-Werkzeug.

Die Einzelschritte für die Durchführung der Methoden werden im Work-Management hinterlegt, der die textuelle, formatierte oder grafische Bearbeitung der einzelnen Schritte steuert. Die Integritäts- und Plausibilitätsprüfungen der Methoden sind als Regeln beschrieben und werden mit einem Regelanalysator geprüft.

Verschiedene Methoden wie beispielsweise Entity-Relationship-Modellierung und strukturierte Analyse müssen als fertige Pakete heute vorliegen. Weitere objektorientierte und Geschäftsvorfall-orientierte Ansätze müssen aber vom Anwender selbst erstellt werden können.

Die Methoden lassen sich durch das flexible Konzept der erweiterbaren Informationsmodelle und der formulierbaren Vorgehenssystematik an neue Anforderungen anpassen. Diese Flexibilität ist Voraussetzung für den Übergang von datenfluß- beziehungsweise funktionsorientierten Ansätzen zur Objektorientierung.

"Altlasten" hängen wie ein Damokles-Schwert über vielen Produkten, die die Qualitäts- und Produktivitätssteigerung in der Software-Entwicklung auf ihre Fahnen geschrieben haben. Die vergangenen Jahre haben gezeigt, daß die meisten CASE-Produkte keine Vergangenheit akzeptieren: Sie sind für Neuentwicklungen konzipiert.

Aber auch die Altlasten lassen sich mit einem Repository in den Griff bekommen. Die wichtigste Information für einen Software-Entwickler ist bei Wartungsaufgaben das Wissen über das Sourcen, Copy Elemente, Dateien und Datenbanken. Die typischen, immer wiederkehrenden Fragen stellen sich fast täglich:

- Wo wird das Copy Element verwendet?

- Wer verändert die Datei?

- Was für Auswirkungen hat die Änderung einer Unterprogrammschnittstelle?

- Wird das Programm in der Produktion angesprochen?

Auf diese Fragen geben Re-Engineering-Produkte Antworten - ohne manuelles Zutun.

Scanner - also maschinelle Analysemechanismen - sind heute in Repository-Umgebungen für Cobol, PL/1, Assembler, CSP, RPG, C, MVS- oder BS2000-Job-Control sowie ganze SAP-Anwendungssysteme verfügbar Akribisch holen sie Information für Information aus den Altbeständen heraus. Jede Information ist für sich schon nützlich, aber in ihrer Gesamtheit noch um ein Vielfaches mehr wert.

Diese Gesamtheit wird im Repository verwaltet. Alle gewonnenen Informationen fließen hier ein, werden geordnet, abgelegt und untereinander verknüpft.

Die Programme, die als unwartbar galten, werden transparent, der Respekt geht verloren. Aussagen zu Abhängigkeiten zwischen den einzelnen Produktionsteilen sind nicht mehr nur vage Hoffnungen, sondern zuverlässige - maschinell ermittelte - Realität. Der Wartungsaufwand in der Software-Entwicklung nimmt ab, die Qualität der Wartungsaufgaben nimmt zu.

Nicht alle interessanten Informationen können durch einen bloßen Scanner ermittelt werden. Datenbankzugriffs-Module werden gefunden, nicht aber die parametergesteuerten unternehmensspezifischen Übergabemechanismen. Für derartige Aufgabenstellungen bieten einige Scanner User-Exits an. Mit deren Hilfe kann über den normalen Leistungsumfang der Scanner hinaus jede zusätzliche individuelle Forderung realisiert werden.

Dateninhalte mit dem Scanner überführen

Bei Mengengerüsten von fast 100 000 Verknüpfungen für nur drei SAP-Komponenten (RF, RM, RA) ist es nicht verwunderlich, daß bei Wartungsarbeiten nicht immer alle Abhängigkeiten berücksichtigt und erst in der Produktion Fehler erkannt werden. Bei derartigen Mengengerüsten muß aber nicht nur die "Intelligenz" der Scanner vorhanden sein, sondern auch eine Repository-gesteuerte Datenhaltung zur Verwaltung der analysierten Informationen.

Wertvolle Informationen sind nicht nur in Programmen, sondern auch in Directories oder Sourcen von Datenbanksystemen verzeichnet. Scanner bieten die Möglichkeit, den gesamten DB2-Katalog, IMS-Strukturen oder Predist-Inhalte maschinell in ein Repository zu überführen und zu analysieren. Andere Informationen finden sich in den CASE-Tools. Schnittstellen zu IEW/ADW, IEF oder den Bachman-Tools erlauben auch hier eine maschinelle Integration .

Neben der Altlasten-Bewältigung werden Scanner bei der Entwicklung von laufenden Projekten eingesetzt. Scanner liefern hierzu unter Cobol und PL/1 eine maschinelle Qualitätsprüfung Qualitätsanforderungen können über Parameter unternehmensspezifisch definiert werden Programmgrößen, maximal erlaubte Schachtelungstiefen von bedingten Anweisungen und Datenstrukturen Richtlinien für die Namensvergabe von Datenfeldern, nicht gewünschte Befehle oder der prozentual geforderte Anteil an Kommentaren sind Beispiele.

Der Aufwand für alle Arbeiten des Re-Engineerings ist gegenüber dem hohen Nutzen verschwindend gering. Und durch die einheitliche Führung aller Informationen in einem unter nehmensweiten Repository ist die Grundlage für ein kontrolliertes Forward-Engineering geschaffen.

Das Work-Management und die Tools müssen mit dem Repository über eine Client-Server-Architektur zusammenarbeiten können. Über eindeutig definierte - und verfügbare - CPI- und API-Schnittstellen werden dann die Datenzugriffe gesteuert.

Ein unternehmensweites Repository entfaltet erst dann seinen ganzen Nutzen, wenn Clients und Server auf verschiedene Betriebssysteme verteilt werden können. Über eine APPC-Kopplung - basierend auf LU6.2 - lassen sich dann beispielsweise Clients auf MVS-, OS/2- und MS-DOS-Umgebungen verteilen, während der Server zentral unter MVS oder auch dezentral unter OS/2 gefahren wird Eine redundante Datenhaltung - Charakteristik fast aller Entwicklungsumgebungen - muß durch die Client-Server-Architektur von Repository-basierten Entwicklungsumgebungen der Vergangenheit angehören.

Ein Repository-Server sollte sich gegenüber technischen Ziel-Datenbanksystemen transparent verhalten. Repository-basierte Entwicklungsumgebungen haben den Anspruch einer hohen Integrationsfähigkeit. Die ausschließliche Konzentration auf nur eine Betriebssystemwelt, in der das Repository lauffähig ist, vermindert - oder verhindert - diesen Anspruch. Der Repository-Server muß bei gleicher Funktionalität somit die Aufgabe haben, nicht nur den Repository Manager/MVS der IBM anschließen zu können, sonderen auch das Siemens-Repository ERMS, andere im Markt etablierte Produkte wie "Rochade" oder auch SQL fähige Datenbanksysteme wie "Ingres" oder "Oracle" - insbesondere im Unix- und VMS-Bereich .

Erst dann stehen das Work-Management, die Funktionsschichten, die CASE-Tools und die Re-Engineering-Konzepte unverändert in verschiedenen Entwicklungsumgebungen zur Verfügung. Denn die Intelligenz und die Mächtigkeit von Entwicklungsumgebungen steckt in den Tools und nicht in der Datenbank, also dem Repository, in dem die Tools ihre Daten ablegen.