Eine umfassende Integration aller Entwicklungsprozesse schließt neben Hardware- und Software-Engineering auch die Projektorganisation und die Qualitätssicherung ein. Das entsprechende Schlagwort lautet Interprozeß-Integration. Matthias Hallmann und Claus Horbach* erläutern, was darunter im einzelnen zu verstehen ist.

In den vergangenen Jahren stellten viele Veröffentlichungen, Projekte und Produkte Teillösungen für verschiedene Problembereiche des System-Engineering vor. Diese monolithischen Lösungen führten vom Eigentlichen Ziel weg, nämlich von einer durchgängigen, soweit wie möglich automatisierten und rechnergestützten Produktion und Pflege von qualitativ hochwertigen Systemen.

Softwaresysteme werden künftig nicht als alleinstehende Lösungen entwickelt, sondern als komplexe, eingebettete Systeme, die sich aus Spezialhardware und Software zusammensetzen. Dieser Trend führt zu hochkomplexen, schwer zu entwickelnden und noch schwerer zu wartenden Systemen, deren Entwicklungs- und Pflegekosten den üblichen Rahmen bei weitem überschreiten.

Keine standardisierten Software-Schnittstellen

Für die Entwicklung solcher Systeme mit tiefgreifenden Randbedingungen durch die Hardware sind unterschiedliche Entwicklungsprozesse aus unterschiedlichen Disziplinen miteinander zu verzahnen. Die dazu nötigen Techniken befinden sich in verschiedenen Entwicklungsstadien: Während im Bereich des Hardware-Engineering bereits standardisierte und akzeptierte Schnittstellen für den Entwicklungsprozeß existieren, ist dies im Software-Engineering keineswegs der Fall.

In beiden Bereichen gibt es eine Vielzahl von Methoden, Werkzeugen, Sprachen, Modellen, Qualitätssicherungstechniken etc. Das Fernziel für das Jahr 2000 ist die Interprozeß-Integration, das heißt die umfassende Integration der Entwicklungsprozesse in allen Disziplinen zu einem globalen Entwicklungsprozeß. Dazu zählen neben den Mitteln des Software-Engineerings, und Hardware auch die Techniken aus der Projektorganisation und der Qualitätssicherung. In letzter Zeit wurde mit einigen Forschungsarbeiten begonnen, die genau dieses Ziel, nämlich die Interprozeß-Integration, erreichen wollen, zum Beispiel das Esprit-Projekt "Atmosphere".

Ein Weg, der zur umfassenden Interprozeß-Integration führt, besteht darin, zunächst

Integrationslösungen auf einer niedrigeren Ebene innerhalb der aufgeführten Entwicklungsprozesse zu suchen. Das Software-Engineering beispielsweise verwendet eine Vielzahl von unterschiedlichen, nicht aufeinander abgestimmten Methoden, Sprachen und Werkzeuge innerhalb eines Prozesses zu integrieren, heißt Intraprozeß-Integration.

Verschiedene Lebenszyklusmodelle, die den Entwicklungsprozeß in zeitlich aufeinanderfolgende Phasen strukturieren, beschreiben die Erstellung von Softwaresystemen. Für die einzelnen Phasen (zum Beispiel Requirements-Engineering, Entwurf, Implementierung und Abnahme) stehen viele Methoden und Techniken zur Verfügung. Zur Zeit existiert jedoch keine durchgehende Methode für alle Phasen des Software-Lebenszyklus.

Methodenintegration bedeutet das Verkleben der Methoden für die einzelnen Phasen zu einer durchgehenden Methode (horizontal), aber auch die Integration von Methoden innerhalb einer Phase (vertikal). Für das Requirements-Engineering gibt es verschiedene Methoden zur Modellierung unterschiedlicher Sichten auf das zu beschreibende System. Die horizontale Methodenintegration - wie etwa bei der Erzeugung von Modulrahmen aus einem Entwurf eingesetzt - verwendet vornehmlich Transformationen als Techniken. Im Software-Engineering setzt der Entwickler eine Vielzahl von verschiedenartigen Sprachen zur formalen oder halbformalen Beschreibung eines Problems auf unterschiedlichen Abstraktionsniveaus ein. Beispielsweise kommen im Requirements-Engineering meist grafische Sprachen (Structured-Analysis-Diagramme) und in der Codierungsphase Programmiersprachen zum Einsatz. Im Gegensatz zu Programmiersprachen sind die Syntax, Semantik und Pragmatik der halbformalen, grafischen Sprachen für Requirements-Engineering und Entwurfsphase nicht exakt definiert.

Die Sprachintegration versucht eine einheitliche Notation zu finden, die Beschreibungen unterschiedlicher Sichten auf ein Problem ermöglichen. Hierfür gibt es zur Zeit jedoch noch keine Lösungsansätze. Zusätzlich erschweren die vielen unterschiedliche Sprachkonstrukte für verschiedene Anwendungsgebiete, zum Beispiel parallele Programmierung oder Nicht-Determinismen, die Integrationsaufgabe.

Vertikale und horizontale Tools

Ein Werkzeug dient der automatischen Unterstützung von Aktivitäten im Software-Entwicklungsprozeß. Häufig unterstützt ein Werkzeug eine Methode. Analog zu der Vielzahl von Methoden für die unterschiedlichen Phasen gibt es ebenso viele Werkzeuge für die verschiedenen Aktivitäten im Software-Entwicklungsprozeß. Beispielsweise existieren für die Implementierungsphase Editoren, Präprozessoren, Compiler, Linker und Debugger. Allein für die im Requirements-Engineering eingesetzte Methode SA gibt es verschiedene grafische Editoren, Analysatoren, Reportgeneratoren, Transformatoren zur Entwurfsphase etc.

Neben diesen horizontalen Werkzeugen kommen auch vertikale Werkzeuge für Konfigurations- und Versions- und Projekt-Management sowie in der Qualitätssicherung zum Einsatz. Durch die Integration von Werkzeugen für alle Bereiche des Software-Lebenszyklus und alle projektbegleitenden Phasen könnte eine vollständige anvendungsabhängige Software-Produktionsumgebung zusammengesetzt werden.

Doch der größte Teil der heute verfügbaren Werkzeuge bietet Einzellösungen für eine definierte Aktivität. Für das Zusammenspiel und den Informationsaustausch zwischen den Tools, deren Uniformität und Konsistenz nach außen sowie lokale Architektur für die Werkzeuge und die Software-Produktionsumgebungen werden zur Zeit Lösungen weiterentwickelt.

In diesem Bereich der Intraprozeß-Integration zeichnen sich erste Lösungen in Form von Rahmensystemen ("Frameworks") ab, die den Werkzeugen eine Reihe von Integrationsmechanismen anbieten. Ein Rahmensystem baut auf einer Plattform, bestehend aus Hardware und Betriebssystem, auf und bietet den Werkzeugen seine Dienste über eine Schnittstelle an. Die Zwischenschicht des Rahmensystems vereinfacht Portierungen auf unterschiedliche Plattformen. Ausgestattet mit einer Menge geeigneter Werkzeuge, läßt sich ein Rahmensystem zu einer vollständigen Software-Produktionsumgebung ausbauen.

Drei verschiedene Integationsdimensionen

Die Integration der Werkzeuge zu einer Software-Produktionsumgebung wird in die drei voneinander unabhängigen Bereiche aufgeteilt: Datenintegration, Kontrollintegration und Darstellungsintegration. Diese Bereiche heißen Integrationsdimensionen.

Die Datenintegration umfaßt Dienste für die einheitliche Ablage aller Informationen, die im Software-Entwicklungsprozeß anfallen. Ein einfacher Mechanismus zur Datenintegration ist der Datenaustausch über eine Datei, wie er etwa zwischen Editor und Compiler sowie zwischen Compiler und Linker praktiziert wird. Kompliziertere Mechanismen sind Datenbanksysteme und Repositories.

Die Kontroll- und Kommunikationsintegration hingegen offeriert Dienste, die eine Steuerung des Software-Entwicklungs durch kontrolliertes Aufrufen der Werkzeugfunktionalitäten erlauben und die gegenseitige Kontrolle der Werkzeuge ermöglichen. In einem einfachen Fall unterstützt hierbei eine Kommandoprozedur die Steuerung; künftig soll diese Aufgabe von einem ausführbaren Prozeßmodell übernommen werden. Zur Kontrollintegration ist ein Kommunikationsmechanismus notwendig, über den sich die Werkzeuge Botschaften zusenden können.

Die unter der Dimension Darstellungsintegration subsummierten Dienste dienen der umformen und konsistenten Definition von grafischen User-Interfaces. Durch die Benutzung durchgängiger grafischer Funktionen kann ein einheitliches Aussehen unterschiedlicher Werkzeuge erlangt werden. Daraus resultiert dann eine bessere Erlernbarkeit. Häufig ist die Rede vom gleichen "Look and Feel". In dieser Integrationsdimension stehen mit dem X-Window-System, den OSF/Motif-Objektbibliotheken und dem OSF/Motif-Style-Guide bereits De-facto-Standards zur Verfügung.

Ein Rahmensystem stellt Dienste für alle obengenannten Integrationsdimensionen bereit. Die Benutzung dieser Schnittstellen durch die Werkzeuge hat Auswirkungen auf die

Architektur dieser Werkzeuge. Deren Funktionalität wird von der Datenhaltung, der grafischen Darstellung und den allgemeinen Diensten getrennt. Das macht die Werkzeuge nicht nur uniformer, sondern auch einfacher. Die Auslagerung des Benutzerschnittstellen-Code beispielsweise reduziert häufig den Werkzeugcode um die Hälfte.

Die Hardwarehersteller haben bereits reagiert

Zu einem solchen Rahmensystem gehören zunächst ein Objektspeicher (OMS) sowie Benutzerschnittstellen- und Kommunikationsdienste. Weitere Dienste, beispielsweise zur Konfigurations- und Versionsverwaltung, werden vielfach als sogenannte Shared-Services angeboten.

Die Dienste des Rahmensystems beschränken sich nicht speziell auf den CASE-Sektor. Sie können auch in anderen CAx-Bereichen zum Einsatz kommen.

Auch die Hersteller proprietärer Hardwaresysteme haben die Bedeutung des Rahmensystems für die Integration und die Erstellung einer Software-Produktionsumgebung erkannt. So bietet die IBM beispielsweise ebenfalls in ihrem AD/Cycle-Konzept ein solches System an - unter der Bezeichnung AD/Plattform.

Teil dieser Plattform ist Repository Manager mit seinem vordefinierten Informationsmodell, das die Aufgabe des Objektspeichers übernimmt. Zur Darstellungsintegration dient der Presentation Manager mit den Richtlinien des Common User Access (CUA).

Das Rahmensystem Cohesion von Digital Equipment enthält als Datenablage das CDD/Repository mit der objektorientierten Atis-Schnittstelle. Zur Darstellungsintegration dient das X-Window-System mit den OSF/Motif Style-Guide.

Während AD/Cycle und Cohesion zu einer datenorientierten Software-Produktionsumgebung führen, setzt HP mit der Softbench auf eine kommunikationsorientierte Architektur. Die Werkzeuge kommunizieren hier über einen Broadcast Message Server. Die Datenintegration erfolgt über das Unix-Dateisystem; die Darstellungsintegration basiert - wie bei Cohesion - auf dem X-Windows-System mit den OSF/Motif-Objekten und dem OSF/Motif-Style-Guide.

Einen interessanten Ansatz zur Integration bietet derzeit das europäische Eureka-Projekt Eureka Software Factory (ESF). Ziel dieses Projekts ist die Erstellung einer sogenannten Softwarefabrik. Mit diesem Begriff ist eine anwendungsunabhängige Software-Produktionsumgebung gemeint, die sich jeweils auf den Einzelfall eines bestimmten Anwendungsgebiets ausrichten läßt.

Kooperation im europäischen Rahmen

Die Schwerpunkte der "Softwarefabrik" liegen in einem hohen Grad auf der Automation sowie der industriellen und standardisierten Softwareproduktion. Im ESF-Projekt werden Werkzeuge in Komponenten aufgespaltet: Dienstkomponenten stellen die Werkzeugfunktionen zur Verfügung, während die Benutzerinteraktions-Komponenten den Dialog zwischen Anwender und Werkzeug verwalten.

Die einzelnen Komponenten können über einen Kommunikationskanal, den Software-Bus, integriert werden. Damit sich eine Komponente in den Software-Bus einsteckten läßt, muß sie allerdings durch eine abstrakte Komponentenbeschreibungs-Sprache definiert werden.

Im Gegensatz zu den proprietären Lösungen bietet die Softwarefabrik die Möglichkeit, ein Prozeßmodell zu definieren sog wie auszufahren und dadurch den Software-Entwicklungsprozeß stärker zu automatisieren.