Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb

Jedes Softwaresystem durchläuft einen Software-

Lebenszyklus

. Dieser Lebenszyklus muss bei jeder Softwareentwicklung beachtet werden – insbesondere bei der Architektur des Softwaresystems. In der Regel leben Softwaresysteme nämlich wesentlich länger als ursprünglich gedacht. Die Abb. 1.0-1 zeigt die einzelnen Phasen des Software-Lebenszyklus. Den einzelnen Phasen lassen sich nichtfunktionale Anforderungen zuordnen (siehe »Nichtfunktionale Anforderungen «, S. 109).

Bei der objektorientierten Modellierung einer Anwendung denkt und arbeitet man vorwiegend mit Elementen wie Klassen, Objekten, Attributen, Assoziationen usw. Dabei handelt es sich um nicht materielle, d. h. rein logische Dinge. Ein Klassen-Diagramm sagt nichts darüber aus, in welcher Form eine Klasse später existieren wird. Durch die Wahl der Implementierungssprache wird dies zwar meist implizit vorgegeben, die Vorstellung bleibt jedoch vage.

Bei der Planung und Dokumentation der Verteilung einer Anwendung geht es darum, auf welchen Computersystemen die Anwendung laufen soll und welche Bestandteile der Anwendung auf welchen Systemen vorliegen müssen, damit ein reibungsloser Betrieb möglich ist.

Im Folgenden wird davon ausgegangen, dass für ein Softwaresystem bereits eine Spezifikation vorliegt. Es wird gezeigt, welche weiteren Entscheidungen notwendig sind, um von der Spezifikation zu einem Entwurf und zu einer Implementierung zu gelangen.

Das OOA-Modell der Fallstudie »Kundenverwaltung-Mini« zeigt die Abb. 5.0-1 (siehe »Fallstudie: KV – Überblick«, S. 15).

Beim Bau eines Hauses gibt es verschiedene Sichten. Der Elektriker hat eine andere Sicht als der Sanitär-Installateur.

In dem »Lehrbuch der Softwaretechnik – Basiskonzepte und Requirements Engineering« [Balz09a, S. 25 ff.] werden folgende allgemeinen Prinzipien vorgestellt, die für die Softwaretechnik relevant sind:

Prinzip der Abstraktion

Prinzip der Strukturierung

Prinzip der Bindung und Kopplung

Prinzip der Hierarchisierung

Prinzip der Modularisierung

Geheimnisprinzip

Prinzip der Lokalität

Prinzip der Verbalisierung

In klassischen Ingenieurdisziplinen werden große Teile früherer Lösungen wiederverwendet. Diese Entwurfsform wird in [ShGa96] als Entwurf-durch-Routine bezeichnet.

Ziel jeder Softwareentwicklung ist es, die Anforderungen des Auftraggebers bzw. des Marktes an das Softwareprodukt zu erfüllen. Es werden funktionale und nichtfunktionale Anforderungen unterschieden.

Eine Softwarearchitektur zu entwerfen ist schwierig, da verschiedene Einflussfaktoren zu berücksichtigen sind, die sich zudem auch noch gegenseitig beeinflussen können. Die meisten dieser Einflussfaktoren sollten bereits bei der Spezifikation festgelegt worden sein. Ist dies nicht der Fall, dann muss dies vor der Entwicklung der logischen Architektur nachgeholt werden.

Softwaresysteme werden heute in der Regel nicht nur in einem Land, sondern oft in mehreren Ländern oder sogar weltweit eingesetzt. Bereits bei der Architektur einer Software ist der mögliche Einsatz in verschiedenen Ländern zu berücksichtigen

In der Regel werden Anwendungen heute von mehreren Benutzern benutzt. Das kann bedeuten, dass bei einer Einzelplatz-Anwendung mehrere Benutzer nacheinander die Anwendung verwenden. Oder dass bei einer verteilten Anwendung mehrere Benutzer nebenläufig oder parallel auf die Anwendung, die auf einem Server installiert ist, zugreifen.

Wenn eine Bank eine Buchung vornimmt, so sind davon in der Regel zwei Konten betroffen. Dem einen Konto wird ein bestimmter Betrag belastet, dem anderen der exakt gleiche Betrag gutgeschrieben. Es wäre fatal, wenn eine Buchung, z. B. durch einen Hardware-Ausfall, zu einem Zeitpunkt abgebrochen würde, an dem zwar das eine Konto belastet, der Betrag dem anderen Konto aber noch nicht gutgeschrieben wurde.

Viele Softwaresysteme sind heute auf ein Netz miteinander verbundener Computersysteme verteilt. Um ein Softwaresystem verteilen zu können, muss es in Subsysteme strukturiert sein. Dabei sollten die Subsysteme in sich stark gebunden sein. Zwischen den Subsystemen sollte eine geringe Kopplung bestehen (siehe Prinzip der Bindung und Kopplung, »Architekturprinzipien«, S. 29).

Bei den meisten Softwaresystemen handelt es sich heute um verteilte Systeme, d. h. die einzelnen Subsysteme sind auf zwei oder mehrere Computersysteme verteilt. Die beteiligten Computersysteme sind miteinander vernetzt (leitungsgebunden, z. B. LAN, oder leitungsungebunden, z. B. WLAN, UTMS). Für die Softwareentwicklung stellt sich die Frage, wie die Kommunikation zwischen den einzelnen verteilten Subsystemen hergestellt werden kann.

Soll ein umfangreiches Anwendungssystem entwickelt werden, das viele nichtfunktionale Anforderungen und Randbedingungen erfüllen soll, dann ist zu prüfen, ob eine softwaretechnische Infrastruktur die Realisierung eines solchen Systems wesentlich erleichtern kann. Softwaretechnische Infrastrukturen werden oft auch als softwaretechnische Plattformen – kurz Plattformen – oder technische Referenzarchitekturen bezeichnet. Sie legen die Basistechniken – oft einschl. des Betriebssystems – und damit auch die Programmiersprachen fest. Man spricht auch von

Middleware

.

Immer dann, wenn Hardware- und Softwarekomponenten in ein umfassenderes Produkt integriert sind, um produktspezifische Funktionsmerkmale zu realisieren, spricht man von

Eingebetteten Systemen

(ES). Das Spektrum von Produkten, welche unter Verwendung von »Eingebetteten Systemen« realisiert werden, umfasst zahlreiche Branchen wie etwa Fahrzeugbau, Automatisierungs- und Produktionstechnik, Luft- und Raumfahrt, Medizintechnik, Umwelt- und Energietechnik,

Consumer Electronics

, Mobilkommunikation, Bahntechnik und Sicherheitstechnik [Nati09].

Bei einer systematischen objektorientierten Softwareentwicklung ist der Ausgangspunkt für die Architektur des Subsystems »Applikation « immer das objektorientierte Analysemodell, das die fachliche Lösung der Fachdomäne wiedergibt.

In fast allen Anwendungen müssen Daten langfristig gespeichert werden. Statt von langfristiger Speicherung spricht man häufig auch von (Daten-)

Persistenz

. Gemeint ist, dass die Daten das Beenden des dazu gehörenden Anwendungsprogramms »überleben« sollen, also unabhängig vom laufenden Programm weiter zur Verfügung stehen sollen.

Die »Binnen«-Architektur des Subsystems »Benutzungsoberfläche« wird in der Regel durch die verwendeten

Frameworks

implizit vorgegeben. Die Architekturen der

Frameworks

sind oft auf den Kontext zugeschnitten, z. B. ob es sich um eine Desktop- oder Web-Oberfläche handelt. Oft spielt auch die Art der Netzkommunikation eine Rolle, z. B. ob über HTTP oder RMI die Daten übertragen werden.

Wie die Abb. 21.0-1 zeigt, ist der Ausgangspunkt für den Entwurf die fachliche Lösung. Bei einer objektorientierten Softwareentwicklung ist dies in der Regel ein objektorientiertes Analysemodell (OOA) der Domäne. Das Ergebnis ist die technische Lösung.

Wie alle Artefakte, die im Laufe einer Softwareentwicklung entstehen, sollte bzw. muss auch die Softwarearchitektur einer Qualitätssicherung unterzogen werden. Wegen der überragenden Bedeutung der Architektur sollte eine Qualitätssicherung nicht erst am Ende, d. h. nach der kompletten Fertigsstellung der Architektur, erfolgen, sondern sie sollte die Architektur bei ihrer Entstehung begleiten.

Bei der Implementierung sollten folgende Prinzipien eingehalten werden:

Prinzip der Verbalisierung,

Prinzip der problemadäquaten Datentypen,

Prinzip der integrierten Dokumentation,

Prinzip des defensiven Programmierens.

Die nichtfunktionale Anforderung Weiterentwickelbarkeit mit seinen Merkmalen Änderbarkeit und Erweiterbarkeit (siehe »Weiterentwickelbarkeit «, S. 119) spielt bei vielen Softwaresystemen eine immer wichtigere Rolle. Diese Anforderung kann auf der Ebene des Entwurfs und der Implementierung durch die Reduzierung von Abhängigkeiten, durch die Vermeidung von Redundanz und durch die Trennung von Zuständigkeiten (siehe »Architekturprinzip: Trennung von Zuständigkeiten«, S. 31) unterstützt werden.

Die Umsetzung einer Softwarearchitektur in Programme erfolgt in der Regel inkrementell und iterativ. Insbesondere bei einer agilen Softwareentwicklung ist es das Ziel, auf der Basis von Testfällen (

test-first

) Programme zu erstellen und anschließend sofort mit bereits vorhandenen Programmen zu integrieren (

continuous integration

) (siehe z. B. [Reif11]). Dabei wird die Funktionalität des Programms dann schrittweise erweitert.

Nach der Fertigstellung eines Softwaresystems muss es verteilt und installiert werden.

Ein fertiggestellteses, verteiltes und installiertes Softwaresystem muss abgenommen werden.

Wartung

beschäftigt sich mit der Lokalisierung und Behebung von Fehlerursachen bei in Betrieb befindlichen Softwaresystemen, wenn die Fehlerwirkung bekannt ist.

Pflege

beschäftigt sich mit der Lokalisierung und Durchführung von Änderungen und Erweiterungen von in Betrieb befindlichen Softwaresystemen, wenn die Art der gewünschten Änderungen/Erweiterungen festliegt.

Um ein vorhandenes Softwaresystem mit unzureichender oder fehlender Dokumentation zu verstehen, ist ein

Reverse Engineering

erforderlich, das in mehreren Schritten durchgeführt werden kann [DDN09, S. 17 ff.]:

1

Festlegung der Marschrichtung

2

Einarbeitung in das System

3

Erstes Verstehen des Systems

4

Erstellen eines detaillierten Modells

Die Weiterentwicklung eines Alt-Systems kann nach [DDN09, S. 149 ff.] in fünf Schritten erfolgen:

1

Tests einsetzen

2

Das Alt-System migrieren

3

Duplizierten Code aufspüren

4

Neuverteilung von Zuständigkeiten

5

Bedingungen in Polymorphie transformieren

Die Weiterentwicklung eines Alt-Systems kann nach [DDN09, S. 149 ff.] in fünf Schritten erfolgen:

1

Tests einsetzen

2

Das Alt-System migrieren

3

Duplizierten Code aufspüren

4

Neuverteilung von Zuständigkeiten

5

Bedingungen in Polymorphie transformieren

Die Weiterentwicklung eines Alt-Systems kann nach [DDN09, S. 149 ff.] in fünf Schritten erfolgen:

1

Tests einsetzen

2

Das Alt-System migrieren

3

Duplizierten Code aufspüren

4

Neuverteilung von Zuständigkeiten

5

Bedingungen in Polymorphie transformieren