Die gängigen CASE-Methoden lassen gerade in den frühen Entwicklungsphasen der Analyse, der Spezifikation und des Systementwurfs noch viele Wünsche offen. Christoph Crasemann, Kay-Ulrich Felgentreu und Hartmut Krasemann sprechen von einer "Methodenlücke". Sie erwarten" daß der Einsatz von objektorientierten Sprachen und Werkzeugen hier Abhilfe schaffen wird.

Immer größer werdende Softwaresysteme machen die Komplexität von Daten und Funktionalität zunehmend systembestimmend. Dies gilt insbesondere für große Informationssysteme mit hohen Strukturdatenanteilen und Anwendungsprogramm-Abhängigkeiten, für technische Konstruktionen im Anlagenbau (CAD) und für Prozeßsteuerungen großer vernetzter Systeme mit zeitkritischem Anteil.

Für das Systems Engineering entstehen daraus Probleme unter anderem in den Bereichen Systemwartung, Erweiterbarkeitsanforderungen, konstruktive Qualitätssicherung und Kostenexplosion. Computer Aided Software/Systems Engineering (CASE) soll hier bekanntlich Abhilfe schaffen. Doch zwischen Wunsch und Wirklichkeit liegen noch Welten.

Gute Unterstützung bietet CASE bei der Systemdokumentation und beim Projekt-Management - in geringerem Maße auch bei Test und Integration sowie beim Konfigurations-Management. Insbesondere die Realisierungsphase im Systems Engineering hat in den letzten Jahren zunehmend von den Programmiersprachen der 4. Generation, den rapide ansteigenden Hardwareleistungen und den Vernetzungen profitiert.

Unbefriedigend ist jedoch der Zustand des Systems Engineering und damit des CASE im Hinblick auf die Komplexitätsbewältigung innerhalb der Phasen Systemanforderungsanalyse, -spezifikation und -entwurf.

In diesen frühen Entwicklungsphasen steht das Problem einer geeigneten Grobstrukturierung des Systems (Design in the Large) im Vordergrund. Standardmethoden stellen dabei Funktionsspezifikationen nach Structured-Analysis-Ansätzen (SA) und Datenstrukturanalyse auf der Grundlage von Entity Relationship (ER) dar.

Die gewünschte Durchgängigkeit der Unterstützung von den Anforderungen bis zur Systemintegration bleibt jedoch wegen unzureichender Methodik bisher ein unerfüllter Wunsch. Vor den hochliegenden Spezifikationen sowie zwischen ihnen und dem Systementwurf klafft die CASE-Methodenlücke (siehe Abbildung 1). Außerdem werden beim Software-Anteil eines Systementwurfs häufig Anwendungslösungen mit Implementierungsdetails vermischt. Dadurch wird eine Iteration von den Anforderungen zur Systemlösung (als Validierungsschritt) weiter erschwert, wenn nicht sogar unmöglich gemacht.

Nur mit geeigneten Vorgehensweisen, die diese Methodenlücken ausfallen können heutige CASE-Werkzeug-Bausteine für die 90er Jahre passend ergänzt werden, Der Begriff CASE 90 soll hier eine methodische, werkzeugunterstützte und durchgängige Systems-Engineering-Technologie für die 90er Jahre bezeichnen, die im folgenden näher beschrieben wird. Dabei spielt der Ansatz, Systeme objektorientiert zu betrachten, eine wichtige Rolle.

Objektorientiert, aber wie? Im Bereich technischer Software werden objektorientierte Ansätze die größten Veränderungen für Programmiersprachen und Software-Entwicklungsmethoden herbeiführen. Das kennzeichnende Schlagwort hierfür ist der Übergang von der 3. oder 4. Programmiersprachen-Generation zur 5. Generation.

Nur ein Beispiel dafür ist C++, eine objektorientierte Erweiterung von C, die von wichtigen Herstellern bereits heute als künftige Softwareplattform ausgewählt wurde. Die treibende Kraft hinter dieser Entwicklung ist natürlich die Ökonomie: Bereits heute kann man zeigen, daß die Produktivität in der Software-Entwicklung mit objektorientierten Sprachen (5- Generation) bis zu zehnmal höher ist als mit prozeduralen Sprachen (3. Generation).

Diese Entwicklung hin zu objektorientierten Ansätzen und Programmiersprachen macht allerdings Anwender und Softwareproduzenten unsicher hinsichtlich der angemessenen Analyse- und Designmethoden. Einige Autoren geben hierauf eine simple Antwort: "Die reale Welt sieht und beschreibt gewöhnlich in Form von Objekten, und dies muß nun einfach auf die Abbildung eben dieser Welt in Programme übertragen werden."

Die Antwort kann aber nicht befriedigen, weil man mit Software neue, künstliche Teilsysteme (Teilwelten) schafft, über deren Struktur neu nachgedacht werden muß. Außerdem wird ein Weltausschnitt durch ein System nicht exakt nachgebildet, sondern hinreichend und angemessen approximiert (meist tut man dies, indem man durch das Weglassen von Details, die für die Anwendung irrelevant sind, stark vergröbert).

Die objektorientierte Betrachtungsweise ist also noch nicht alles: Es stellt sich die Frage, wie man die Objekte des zukünftigen Softwaresystems effektiv bestimmt. Weder Structured Analysis noch Entity Relationship können diese Frage ausreichend beantworten. Erforderlich ist eine erweiterte Methodologie der Analyse und Synthese für die komplexen Systeme der 90er Jahre. Wir nennen das Verfahren "Conceptual Design" für CASE 90.

Methoden wachsen an konkreten Problemen

Conceptual Design ist die konsequente Umsetzung einer Reihe wichtiger Erkenntnisse über die Entwicklung komplexer Systeme, insbesondere verteilter Realzeitsysteme. Es entstand an konkreten Projekten, wie Methoden Oberhaupt nur an konkreten Problemen wachsen können. Deshalb wird auch das Conceptual Design noch weiter wachsen, und zwar gleichzeitig mit dem weiteren Wachsen von Werkzeugen.

Die Erkenntnisse, die dem Conceptual Design zugrunde liegen, lassen sich folgendermaßen formulieren:

These 1: Die Systemspezifikation ist ein unerläßlicher Zwischenschritt bei der Entwicklung von der Anforderungsdefinition zum Systementwurf. Die heutzutage gängigen Spezifikationstechniken Structured Analysis und Entity Relationship sind für komplexe Systeme unzureichend. Das SA-ER-Modell muß daher erweitert werden zu dem strukturell reichhaltigeren Informationsmodell, indem das Problem in stärkerem Maße formal berücksichtigt wird.

Außerdem müssen Daten und Funktionalität miteinander gekoppelt werden (objektorientierte Denkweise). Dadurch kann auch das Lastenheft vom Auftraggeber und dem Auftragnehmer besser diskutiert werden, denn eine solche Information ist konkreter als abstrakte Funktionalität.

These 2: Aus der informationsorientierten Spezifikation kann und durch Verfeinerung ein objectorientiertes vollständiges anvendungsorientiertes Systemmodell (der Systemgrobentwurf) abgeleitet werden. Dabei ist das Informationsmodell der konkrete Kern des objektorientierten Systemmodells. (Das gilt selbst dann, wenn das System seinem Wesen nach sehr, funktional" ist.)

Dadurch wird der Übergang von der Systemspezifikation zu einem immer noch sehr anwendungsorientierten Systemgrobentwurf durchgängig. Auch dynamisches Systemverhalten und Benutzerschnittstellen können auf dieser Ebene dargestellt werden. Notwendige Entscheidungen über Hardware- und Softwarearchitektur sollten dabei konzeptuell sehr sauber gefaßt sein und auf ein Minimum beschränkt werden.

These 3: Aus dem objektorientierten Systemmodell müssen die grundlegenden Hardware- und vor allem Softwarespezifikationen automatisch erzeugt werden. Dabei entsteht eine Modularisierung des Systems, die das applikationsnahe objektorientierte Systemmodell noch widerspiegeln muß.

Insbesondere muß die Struktur dieses Modells erhalten bleiben; der Systemgrobentwurf darf nicht unter Verlust seiner Struktur auf einen völlig anderen implementierungsnahen Entwurf abgebildet werden. Die Implementierung muß sich der Anwendung nähern.

Ohne diesen Grundsatz wird später bei der Systemwartung in Implementierungsstrukturen gedacht: In diesen Strukturen - und nicht im Systemmodell - werden dann die Änderungen und Erweiterungen durchgeführt. Dadurch wird eine Überprüfung der Systemeigenschaften auf höherer Ebene erschwert, wenn nicht sogar unmöglich gemacht.

These 4: Unter Umständen muß ein abstraktes Architekturmodell des Zielsystems geschaffen werden, mit dem die Leistung des zu implementierenden Systems schon auf der Ebene des objektorientierten Modells wird.

These 5: Funktionale Leistung sowie Durchsatz des Systems müssen spätestens anhand der Strukturen des objektorientierten Modells validiert werden gegebenenfalls auch schon früher.

These 6: Die Entwicklung der Test- und Integrationspezifikationen ist keine isolierte Aktivität. Während des Conceptual Design wächst das Verständnis der Anforderungen. Daraus ergeben sich Test- und Integrationsanforderungen, die Hand in Hand mit dem wachsenden Anforderungsverständnis spezifiziert werden müssen.

Nicht auf dem Papier, sondern mit Tools

Dabei entstehen die genannten Modelle nicht mehr nur auf dem Papier, sondern werden mit den entsprechenden Werkzeugen entwickelt.

Nach dem Conceptual Design kann der Systemgrobentwurf (Design in the Large) dann gemäß den etablierten Standards verfeinert und auscodiert werden. Dazu dient die jeweils gewählte Implementierungssprache, eventuell zusammen mit Kommunikations- oder Datenbankschnittstellen.

Diese Sprachen sind -für die Implementierung gut geeignet; eine Systemstrukturierung, die in den frühen Systems-Engineering-Phasen nach den oben beschriebenen Prinzipien erfolgen muß, können sie jedoch nicht leisten.

CASE 90 befindet sich erst im Entstehungsprozeß. Umfassende Toolboxen lassen noch auf sich warten. Zur Zeit liegt ein Schwerpunkt darauf, die Methodologie von Conceptual Design zu unterstützen, um so zu einer CASE-90-Grundlage zu kommen.

Offene Werkzeuge erst in Anfängen vorhanden

Vorhandene CASE-Werkzeuge können in eingeschränktem Umfang an die oben aufgestellten Grundsätze angepaßt werden. Ein Hemmschuh ist dabei die fehlende Offenheit fast aller heutigen CASE-Werkzeuge: Offenheit bedeutet hier die Existenz einer Entwicklungsdatenbank, möglichst objektorientiert, zusammen mit einer geeigneten Sprache der 5. Generation als Werkzeugerstellungssprache. Diese Art von Werkzeugarchitekturen befindet sich jedoch erst in den Anfängen.

Dipl.-Inform. Christoph Crasemann, Dr. Kay-Ulrich Felgentreu und Dr. Hartmut Krasemann sind Mitarbeiter im Fachbereich Wissensbasierte Systeme der SCS Inforinationstechnik GmbH, Hamburg.