Skip to main content
main-content

Über dieses Buch

Im Mittelpunkt dieses Buches steht der Entwurf von Softwarearchitekturen, die Königsdisziplin der Softwaretechnik. Die Kunst besteht darin, eine Architektur zu entwerfen, die die funktionalen und nichtfunktionalen Anforderungen unter Berücksichtigung von Architekturprinzipien, Architektur -und Entwurfsmustern sowie weiteren Einflussfaktoren erfüllt. Dabei sind vielfältige Abhängigkeiten zu berücksichtigen. Ausgehend von globalen Architekturmustern werden zunächst Einzelaspekte mit ihren Alternativen behandelt. Damit immer der Bezug zur Realität vorhanden ist, wird eine durchgängige Fallstudie in verschiedenen Varianten zunächst für Einzelaspekte entworfen und implementiert. Dadurch wird es auch möglich, gute Softwarearchitekturen zu entwerfen, auch wenn keine Standardplattform, wie z.B. Java EE, zur Verfügung steht, nicht geeignet ist oder nicht benötigt wird. Neben der Java EE-Plattform wird auch die .NET-Plattform behandelt. Zusätzlich werden die Besonderheiten bei softwareintensiven Systemen dargestellt.

Das Buch kann zur Vorlesungsbegleitung, zum Selbststudium und zum Nachschlagen verwendet werden. Die behandelten Themen:

Der Entwurf

ArchitekturprinzipienArchitektur- & EntwurfsmusterNichtfunktionale AnforderungenEinflussfaktoren auf die ArchitekturGlobalisierung von SoftwareAuthentifizierung & AutorisierungTransaktionenVerteilte ArchitekturenArten der NetzkommunikationSoftwaretechnische InfrastrukturenSubsystem ApplikationSubsystem PersistenzSubsystem BenutzungsoberflächeEntwurfsprozessQS der Architektur

Die Implementierung

ImplementierungsprinzipienSchnittstellen, Fabriken & KompositionRestrukturieren (refactoring)

Verteilung, Installation, Abnahme & Einführung

Verteilung & InstallationAbnahme & Einführung

Der Betrieb

WartungPflegeReverse EngineeringReengineering

Inhaltsverzeichnis

Frontmatter

Der Software-Lebenszyklus

1. Der Software-Lebenszyklus

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).

Helmut Balzert

Der Entwurf

Frontmatter

2. Artefakte

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.

Helmut Balzert

3. Verteilungsdiagramme

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.

Helmut Balzert

4. Fallstudie: KV – Überblick

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.

Helmut Balzert

5. Fallstudie: KV – Einzelplatz

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

Helmut Balzert

6. Was ist eine Softwarearchitektur?

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

Helmut Balzert

7. Architekturprinzipien

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

Helmut Balzert

8. Architektur- und Entwurfsmuster

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

Helmut Balzert

9. Nichtfunktionale Anforderungen

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.

Helmut Balzert

10. Einflussfaktoren auf die Architektur

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.

Helmut Balzert

11. Globalisierung von Software

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

Helmut Balzert

12. Authentifizierung und Autorisierung

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.

Helmut Balzert

13. Transaktionen

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.

Helmut Balzert

14. Verteilte Architekturen

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).

Helmut Balzert

15. Arten der Netzkommunikation

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.

Helmut Balzert

16. Softwaretechnische Infrastrukturen

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

.

Helmut Balzert

17. Architekturen »Eingebetteter Systeme«

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].

Helmut Balzert

18. Das Subsystem Applikation

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.

Helmut Balzert

19. Das Subsystem Persistenz

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.

Helmut Balzert

20. Das Subsystem Benutzungsoberfläche

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.

Helmut Balzert

21. Der Entwurfsprozess

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.

Helmut Balzert

22. Qualitätssicherung der Architektur

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.

Helmut Balzert

Die Implementierung

Frontmatter

23. Implementierungsprinzipien

Bei der Implementierung sollten folgende Prinzipien eingehalten werden:

Prinzip der Verbalisierung,

Prinzip der problemadäquaten Datentypen,

Prinzip der integrierten Dokumentation,

Prinzip des defensiven Programmierens.

Helmut Balzert

24. Schnittstellen, Fabriken und Komposition

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.

Helmut Balzert

25. Restrukturieren (refactoring)

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.

Helmut Balzert

Verteilung, Installation, Abnahme und Einführung

Frontmatter

26. Verteilung und Installation

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

Helmut Balzert

27. Abnahme und Einführung

Ein fertiggestellteses, verteiltes und installiertes Softwaresystem muss abgenommen werden.

Helmut Balzert

Der Betrieb

Frontmatter

28. Wartung

Wartung

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

Helmut Balzert

29. Pflege

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.

Helmut Balzert

30. Reverse Engineering

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

Helmut Balzert

31. Reengineering (Teil 1)

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

Helmut Balzert

32. Reengineering (Teil 2)

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

Helmut Balzert

33. Reengineering (Teil 3)

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

Helmut Balzert

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise