Evolution statt Revolution im Software-Engineering (Teil 1)

Es muß nicht immer gleich eine komplette Umgebung sein

19.04.1991

Fast jeder Hersteller versucht mittlerweile, seine Kompetenz im Software-Engineering dadurch zu unterstreichen, daß er komplette Softwareproduktions-Umgebungen (SPU) anbietet. Die Anwender stehen diesem Geschehen meist ziemlich hilflos gegenüber. Oft retten nur die begrenzten Budgets die Unternehmen davor, riesige Fehlinvestitionen zu tätigen.

Ob es sich nun um IBMs AD/Cycle, DECs Cohesion, Softlabs Maestro II oder Predict Case von der Software AG handelt - jeder Hersteller versucht, das Thema Software-Engineering aufzugreifen. Zwar haben die Produkte häufig noch nicht den Reifegrad erreicht, der einen problemlosen Einsatz erlaubt; doch die Themen ICASE (Integrated Computer Aided Software Engineering) und Repository dominieren bereits die Diskussion im Bereich Software-Engineering.

In diesem Beitrag sollen Wege aufgezeigt werden, wie die Anwender heute schon Qualitäts- und Produktivitätsfortschritte in der Anwendungsentwicklung erzielen können, ohne eine komplette SPU zu installieren, und wie sie sich gleichzeitig die Option offenhalten, zu einem späteren Zeitpunkt vielleicht doch eine komplette SPU zu implementieren.

Um einschätzen zu können, inwieweit eine konkrete SPU evolutionär implementiert werden kann, muß zunächst bekannt sein, welche Bestandteile eine solche Umgebung hat und welche Möglichkeiten es gibt, diese Bestandteile schrittweise einzusetzen. Im Grunde verfügen alle Softwareproduktions-Umgebungen über sieben zentrale Bausteine, die in der Abbildung dargestellt sind:

1.grafische Benutzeroberfläche,

2. Monitor,

3.Vorgehensmodell / Methoden,

4.phasenorientierte und

5.phasenübergreifende Werkzeuge,

6.Infrastrukturkonzept sowie

7.Repository.

Der Einstieg in alle zeitgemäßen SPUs geschieht über eine grafische Benutzeroberfläche. Diese Oberflächen sind ein essentieller Teil einer SPU, da viele Methoden des Software-Engineerings grafisch orientiert sind. Weil aber die herkömmlichen Zentralrechner nicht über solche grafischen Möglichkeiten verfügen, gehört zu einer SPU neben der Back-end-Maschine (in der Regel der klassische Host) ein Front-end-Rechner, also ein DOS-, OS / 2- oder Unixbasiertes System. Entscheidet man sich für eine konkrete SPU, so kauft man gleichzeitig auch deren Infrastrukturkonzept.

Kommunikation mit dem Anwender

Die Aufgabe des Monitors ist, die Kommunikation zwischen Anwender, Vorgehensmodell, Werkzeugen und Repository zu steuern. Möchte der Anwendungsentwickler zum Beispiel in der Phase Realisierung ein Programm compilieren, so stellt der Monitor ihm zum einen das Vorgehensmodell für die entsprechende Aktivität der Phase zur Verfügung, um dort vielleicht unternehmensspezifische Standards nachlesen zu können; zum anderen wird dem Entwickler der richtige Compiler mit der korrekten Parametrisierung angeboten. Schließlich sorgt der Monitor dafür, daß die Ergebnisse (Source- und Objectcode) im Repository abgelegt werden.

Einen weiteren wesentlichen Baustein bildet das Vorgehensmodell mit den zugehörigen Methoden. Gerade deutsche Hersteller legen großen Wert auf die Integration eines Vorgehensmodells in ihre Softwareproduktions-Umgebung. Im Gegensatz zu Vorgehensmodellen älteren Datums versuchen zeitgemäße Ansätze des Software-Engineering, Methoden zu integrieren.

Dem kommt entscheidende Bedeutung zu, denn in einer SPU definiert das Vorgehensmodell die im Softwareherstellungs-Prozeß zu erzeugenden Ergebnisse und deren Beziehung untereinander. Dies wiederum ist notwendig, weil bei der Nutzung eines Repositories die Ergebnisse und ihre Struktur durch das Informationsmodell des Repositories genau definiert sein müssen. Das setzt jedoch voraus, daß Vorgehensmodell (Methoden), Werkzeuge und Repository vollkommen konsistent zueinander sind.

Bei den Werkzeugen muß zwischen den phasenorientierten (zum Beispiel ein Compiler) und den phasenübergreifenden Werkzeugen (zum Beispiel ein Projekt-Management-Tool) unterschieden werden. Im Gegensatz zu den phasenorientierten Tools benötigen die phasenübergreifenden Werkzeuge Informationen, die an verschiedenen Stellen im Software-Entwicklungsprozeß erzeugt werden. So muß zum Beispiel ein Projekt-Management-Tool auf den Status aller Ergebnisse der Anwendungsentwickler zugreifen können. Phasenübergreifende Werkzeuge benötigen also eine intensive Kommunikation mit allen Projektbeteiligten.

Upper- und Lower-CASE-Tools

Die phasenorientierten Werkzeuge werden klassisch in die Upper-CASE- und die Lower-CASE-Werkzeuge unterteilt. Upper-CASE-Werkzeuge sind zum Beispiel Werkzeuge wie die IEW (Information Engineering Workbench) von Knowledgeware, also Werkzeuge, die die frühen Phasen der Software-Entwicklung abdecken. Lower-CASE-Werkzeuge sind Sprachen, Generatoren, Interpreter etc.

Wie schon im Zusammenhang mit der Benutzeroberfläche erwähnt, sind alle Komponenten einer SPU in ein Infrastrukturkonzept eingebettet. Auch wenn Hersteller nicht explizit auf diese Tatsache hinweisen, so verlangt doch jede SPU ein bestimmtes Infrastrukturkonzept.

Insbesondere werden damit die Arbeitsplätze der Anwendungsentwickler definiert. Dies determiniert in der Regel auch die Netzarchitektur und die Rolle des Zentralrechners in der Anwendungsentwicklung.

Das Kernstück einer Softwareproduktions-Umgebung ist das Repository. Ihm müssen alle Ergebnisarten, die im Rahmen der Softwareherstellung anfallen, bekannt sein. Aber das Repository kennt nicht nur die Ergebnisarten, es weiß ebenfalls, wie diese Ergebnisarten zusammenhängen.

Konsistenzkontrolle wird teilweise automatisiert

So hat dem Repository zum Beispiel bekannt zu sein, daß ein Programm eine fachliche Spezifikation haben muß. Diese Informationen sind wichtig, weil so zumindest eine teilautomatisierte Konsistenzkontrolle möglich ist.

Diese Informationen werden in einem Metamodell beschrieben. Dieses Metamodell ist sehr komplex; es hat meist über hundert Objekte und noch einmal genauso viele Beziehungen. Diese Komplexität ist es, die Firmen wie der IBM mit ihrem Repository Manager / MVS Schwierigkeiten bereitet. Noch komplexer wird die Sache, wenn man bedenkt, daß in dem AD / Cycle-Konzept der IBM unterschiedliche Werkzeuge für die gleichen Phasen der Software-Entwicklung integriert werden müssen.

Zwar gibt es einige Standardisierungsbestrebungen wie die ANSI-Norm "lnformations Resource Dictionary System" (IRDS). Doch ist weder klar, welcher Standard sich etablieren wird, noch, wie dieser einmal aussehen soll.

Im Repository werden allerdings nicht immer die Daten selbst gespeichert. Teilweise stehen dort nur Verweise auf die eigentliche Datenhaltung. Insofern, als das Repository das Herzstück einer Softwareproduktions-Umgebung ist, müssen natürlich alle Bestandteile der SPU mit ihm kommunizieren können.

Wie die Abbildung zeigt, kann das Repository entweder zentral oder verteilt konzipiert sein. Bei einem zentralen Repository ist es die Aufgabe des Front-end-Monitors, den Zugriff auf das Repository zu steuern.

Bei einem verteilten Repository ist die Sache etwas komplizierter: Dort lassen sich zwei Kommunikationsarten unterscheiden; die eleganteste, aber auch aufwendigste Lösung ist, die Verteilung der Ergebnisse dem Repository selbst - im Sinne einer verteilten Datenbank - zu überlassen.

In der Regel werden allerdings einfachere Mechanismen eingesetzt. Mit einem Check-Out / Update-Verfahren lassen sich Ergebnismengen (Teilmodelle) aus einem zentralen Repository in ein lokales auf dem Front-end auslagen.

Die entsprechenden Ergebnisse erhalten dann das Merkmal "ausgelagert" und stehen nur noch für einen Lesezugriff zu Verfügung. Zu gewissen Zeitpunkten muß der Entwickler selbst die auf seinem lokalen Repository residierenden Ergebnisse in das zentrale Repository überführen.

(wird fortgesetzt)