20 Integration 20.1 Einbettung der Integration in die Software-Entwicklung 20.2 Integrationsstrategien 20.3 Probleme der Integration 20.4 Planung und Dokumentation der Integration 20.5 Grundsätze für die Integration

Einordnung Dieses Kapitel betrachtet die Montage des Systems, die Integration. Die Integration ist ein wichtiger und schwieriger Schritt der Software- Entwicklung Er wird oft unterschätzt! Es geht um den Zusammenhang, der zwischen Entwurf, Test und Integration besteht.

20.1 Einbettung der Integration in die Software-Entwicklung

Definition und Ziel integration — The process of combining software components, hardware components, or both into an overall system. IEEE Std 610.12-1990 Wenn (auf der Basis einer soliden Spezifikation) die Bestandteile des Systems realisiert, angepasst oder beschafft sind, können sie zusammengefügt werden. Im Zuge der Integration soll aus den Bestandteilen ein vollständiges und funktionsfähiges System entstehen. Die Software-Architektur liefert den Bau- und Montageplan. Das der Architektur zu Grunde gelegte Metamodell gibt die Ebenen der Integration vor, die oft hierarchisch angeordnet sind. Basiert z.B. eine Architektur auf Subsystemen aus Komponenten aus Modulen, dann sind dies auch die Ebenen der Integration.

Teilintegriertes System Solange das System noch nicht vollständig integriert ist, wird das Ergebnis jedes Integrationsschritts als teilintegriertes System bezeichnet. Typisches Problem der Integration: Inkompatible Schnittstellen (syntaktische und semantische Konflikte durch unterschiedliches Verständnis der Spezifikation und durch Schlamperei oder – weit schlimmer – durch das Fehlen einer Spezifikation) Darum wird das teilintegrierte System vor jeder Verwendung und weiteren Integrationen getestet und korrigiert (Integrationstest).

Integrationstest integration testing — Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. IEEE Std 610.12-1990 Hier geht es nicht um die Fehler der einzelnen Komponenten (Modultest), sondern um Konsistenzprobleme zwischen den Komponenten. Integration und Integrationstest dürfen nicht in der Entwicklungsumgebung stattfinden! Dazu sollte eine eigene Integrationsumgebung eingerichtet werden. Wenn alles integriert ist, folgt der Systemtest.

20.2 Integrationsstrategien

Testtreiber und Platzhalter Ein teilintegriertes System ist i.A. nicht ausführbar! Für den Integrationstest werden darum Testtreiber und Platzhalter (Stubs) benötigt. Ein Testtreiber versorgt das teilintegrierte System mit Eingaben. Ein Platzhalter vertritt eine benötigte, aber noch nicht verfügbare Komponente. Er liefert entweder konstante Werte oder simuliert das Verhalten der ersetzten Komponente mehr oder minder realistisch. Je nach Integrationsstrategie werden mehr oder weniger Testtreiber und Platzhalter benötigt. „intelligente“ Platzhalter sind aufwändiger als Testtreiber. Darum ist es vorteilhaft, so zu integrieren, dass nur wenige Platzhalter benötigt werden.

Beispiel In diesem Integrationsszenario werden sowohl ein Testtreiber als auch Platzhalter benötigt: Report-Generator wird mit dem teilintegrierten System 1 integriert. Das teilintegrierte System 2 wird vom Testreiber RG-Tester angesteuert und enthält die Stubs XML-Formatierer und Excel-Formatierer.

Integration in einem Schritt Big-Bang-Integration Im Prinzip sehr attraktiv, denn Testtreiber und Platzhalter sind nicht notwendig. Nach der Integration ist das System vollständig und kann ohne Hilfsmittel getestet werden. In der Praxis Kaum möglich, weil die Komponenten zu viele Fehler und Inkonsistenzen enthalten; das System ist kaum ausführbar, die Probleme lassen sich in einem großen, den Beteiligten kaum bekannten System nicht zuordnen. Nur möglich, wenn schon vor der Integration eine hohe Qualität der Komponenten und gute Konsistenz der Schnittstellen gewährleistet sind (z.B. Cleanroom-Entwicklung).

Inkrementelle Integration Die Komponenten einer Integrationsebene werden einzeln oder in kleinen Gruppen integriert. Wenn alle Komponenten rechtzeitig verfügbar sind, bestimmen die Benutzt-Beziehungen die Reihenfolge der Integration. Andernfalls versucht man, alle fertigen Komponenten so rasch wie möglich zu integrieren.

Top-down- und Botton-up-Integration Top-down-Integration Folgt der hierarchischen Struktur der Architektur von oben nach unten. Vorteil: Ein ausführbares System entsteht sehr früh. Nachteil: U.U. müssen viele Platzhalter (mit einer gewissen Funktionalität) erstellt werden. Bottom-up-Integration Eine Komponente wird integriert, wenn alle benötigten Komponenten bereits integriert sind. Nur bei zyklischen Abhängigkeiten braucht man Platzhalter (oder alle zyklisch abhängigen Komponenten werden auf einen Schlag integriert). Vorteil: Keine oder nur wenige Platzhalter werden benötigt. Nachteil: Die Prüfung des Gesamtsystems ist erst nach dem letzten Integrationsschritt möglich.

Kontinuierliche Integration Im Extreme Programming: laufende (typisch tägliche) Integration auf dem (von den Entwicklungsumgebungen getrennten) Integrationsrechner. Die Integration wird zu einem fortlaufenden Prozess. Sobald eine neue Komponente fertig oder eine bereits vorhandene modifiziert ist, wird sie integriert und getestet. Nur wenn der Test keine Fehler zeigt, bleibt der neue Code auf dem Integrationsrechner. Voraussetzungen enge Zusammenarbeit kleine Inkremente diszipliniertes Vorgehen

Beispiel zur Integration

Top-down-Integration keine Treiber, viele Platzhalter

Bottom-up-Integration Nur ein Platzhalter (wegen der zyklischen Abhängigkeit), aber viele Treiber.

20.3 Probleme der Integration

Ideale Wert versus Praxis In einer idealen Welt ist die Integration einfach, kein Problem: Die Entwickler realisieren strikt nach Spezifikation die Komponenten. Dank sauberer Spezifikation und strenger Typprüfung passen die Teile am Ende wie geplant zusammen. Der Integrationsaufwand ist gering und fällt nicht ins Gewicht. In der Praxis sieht das ganz anders aus. Vor allem zwei Gründe stehen der mühelosen Integration entgegen: Die Spezifikation ist schwammig und unvollständig. Folge: Komponenten, die nicht zusammenpassen. Im System sollen Fremdkomponenten verwendet werden. Meist ist die Information über die Fremdkomponenten völlig unzureichend und steht nicht rechtzeitig zur Verfügung.

20.4 Planung und Dokumentation der Integration

Informationsbedarf Die Integration eines großen, komplexen Systems ist aufwändig und mühsam und wird oft auch dadurch erschwert und verzögert, dass immer wieder Fragen aufkommen, die nur mit großer Mühe geklärt werden können. Was bedeutet diese Warnung, können wir weitermachen oder nicht? Ist es in Ordnung, dass im Test immer mehr Speicher belegt wird, oder handelt es sich um ein Speicherleck? Warum wird laut Architekturplan diese Komponente integriert, obwohl ihre Funktionalität nie in Anspruch genommen wird? Welche Komponente hätte die Datenstruktur initialisieren müssen? Oder ist das gar nicht erforderlich? Da es sich vor allem um Schnittstellenprobleme handelt, ist nicht a priori klar, welche Entwickler zuständig sind.

Integrationsplan Ein Integrationsplan ist wichtig! Er muss folgende Informationen enthalten: Identifikation der zu integrierenden Komponenten Technische Voraussetzungen der Integration, Ressourcen, Bedingungen und Einschränkungen Organisation und Reihenfolge der Integration Spezifische Angaben zu den einzelnen Integrationsschritten Da die Integration typisch auf unterschiedlichen Ebenen stattfindet (Subsystem-, Komponenten-, Modulebene), muss der Integrationsplan alle diese Ebenen behandeln.

20.5 Grundsätze für die Integration

Grundsätze Die Integration planen! Frühzeitig mit der Integration beginnen! Ein gutes Verfahren zur Integration besteht darin, damit zu beginnen, bevor codiert wird. Den Aufwand für die Integration und den Integrationstest nicht unterschätzen! Die Integrationsstrategie auf die Projektorganisation und auf den Entwicklungsprozess abstimmen! Den gesamten Aufwand für die Integration präzise erfassen! Integrationsrisiken erkennen und reduzieren! Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway (1968, S. 31)