Basiswissen für Softwarearchitekten E-Book

Mahbouba Gharbi

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch

Seitenzahl: 296

Veröffentlichungsjahr: 2025

Beschreibung

Grundlagenwissen nicht nur für Softwarearchitekt*innen - Das bewährte Standardwerk in 6. Auflage: verständlich und klar strukturiert aufbereitet - Mit vielen praxisnahen Beispielen, Tipps und Exkursen - Eine reichhaltige Fundgrube für Lehre und Selbststudium   Die Softwarearchitektur bildet – neben motivierten Teams und gutem Management – einen wichtigen Erfolgsfaktor von Softwareprojekten. Sie stellt im Sinne einer systematischen Konstruktion sicher, dass Qualitätsanforderungen wie Erweiterbarkeit, Flexibilität, Performance und Time-to-Market erfüllt werden können.  Dieses Buch vermittelt das notwendige Wissen und die Fähigkeiten, um eine problemadäquate Softwarearchitektur für Systeme zu entwerfen. Es behandelt - wichtige Begriffe und Konzepte der Softwarearchitektur, - grundlegende Techniken und Methoden für den Entwurf und die Entwicklung, - die Beschreibung und Kommunikation sowie Qualitätssicherung von Softwarearchitekturen, - die Rolle, die Aufgaben und die Arbeitsumgebung von Softwarearchitekten sowie - Kategorien und Entscheidungskriterien für die Auswahl konkreter Werkzeuge.   Die 6., überarbeitete und aktualisierte Auflage wurde um ein eigenes Kapitel zu Anforderungen und Rahmenbedingungen erweitert und behandelt nun auch das Thema Daten und Datenmodelle.  Das Buch orientiert sich am Lehrplan zum »Certified Professional for Software Architecture – Foundation Level« (CPSA-F), Version 2025.1RC-6, des International Software Architecture Qualification Board (iSAQB®) und eignet sich als kompaktes Grundlagenwerk bestens zur Prüfungsvorbereitung, für die Anwendung in der Praxis und als Lehrbuch an Hochschulen.  

Leseprobe

Hinweise zur Benutzung

Dieses E-Book ist urheberrechtlich geschützt. Mit dem Erwerb des E-Books haben Sie sich verpflichtet, die Urheberrechte anzuerkennen und einzuhalten. Sie sind berechtigt, dieses E-Book für persönliche Zwecke zu nutzen. Sie dürfen es auch ausdrucken und kopieren, aber auch dies nur für den persönlichen Gebrauch. Die Weitergabe einer elektronischen oder gedruckten Kopie an Dritte ist dagegen nicht erlaubt, weder ganz noch in Teilen. Und auch nicht eine Veröffentlichung im Internet oder in einem Firmennetzwerk.

Copyright-Vermerk

Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen bei den Autor*innen und beim Rheinwerk Verlag, insbesondere das Recht der Vervielfältigung und Verbreitung, sei es in gedruckter oder in elektronischer Form.

© Rheinwerk Verlag GmbH, Bonn 2025

Nutzungs- und Verwertungsrechte

Sie sind berechtigt, dieses E-Book ausschließlich für persönliche Zwecke zu nutzen. Insbesondere sind Sie berechtigt, das E-Book für Ihren eigenen Gebrauch auszudrucken oder eine Kopie herzustellen, sofern Sie diese Kopie auf einem von Ihnen alleine und persönlich genutzten Endgerät speichern. Zu anderen oder weitergehenden Nutzungen und Verwertungen sind Sie nicht berechtigt.

So ist es insbesondere unzulässig, eine elektronische oder gedruckte Kopie an Dritte weiterzugeben. Unzulässig und nicht erlaubt ist des Weiteren, das E-Book im Internet, in Intranets oder auf andere Weise zu verbreiten oder Dritten zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und jegliche den persönlichen Gebrauch übersteigende Vervielfältigung des E-Books ist ausdrücklich untersagt. Das vorstehend Gesagte gilt nicht nur für das E-Book insgesamt, sondern auch für seine Teile (z. B. Grafiken, Fotos, Tabellen, Textabschnitte).

Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte dürfen aus dem E-Book nicht entfernt werden.

Die automatisierte Analyse des Werkes, um daraus Informationen insbesondere über Muster, Trends und Korrelationen gemäß § 44b UrhG (»Text und Data Mining«) zu gewinnen, ist untersagt.

Markenschutz

Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.

Haftungsausschluss

Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor*innen, Herausgeber*innen oder Übersetzer*innen für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen.

Mahbouba Gharbi · Arne Koschel · Andreas Rausch · Gernot Starke

Basiswissen für Softwarearchitekten

Aus- und Weiterbildung nach iSAQB®-Standard zum Certified Professional for Software Architecture – Foundation Level

6., überarbeitete und aktualisierte Auflage

Wir hoffen, dass Sie Freude an diesem Buch haben und sich Ihre Erwartungen erfüllen. Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Informationen zu unserem Verlag und Kontaktmöglichkeiten finden Sie auf unserer Verlagswebsite www.dpunkt.de. Dort können Sie sich auch umfassend über unser aktuelles Programm informieren und unsere Bücher und E-Books bestellen.

Autoren: Mahbouba Gharbi, Arne Koschel, Andreas Rausch, Gernot Starke

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner

Covergestaltung: Eva Hepper, Silke Braun

Das vorliegende Werk ist in all seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion, der Vervielfältigung auf fotomechanischen oder anderen Wegen und der Speicherung in elektronischen Medien.

Ungeachtet der Sorgfalt, die auf die Erstellung von Text, Abbildungen und Programmen verwendet wurde, können weder Verlag noch Autor*innen, Herausgeber*innen oder Übersetzer*innen für mögliche Fehler und deren Folgen eine juristische Verantwortung oder irgendeine Haftung übernehmen.

Die in diesem Werk wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. können auch ohne besondere Kennzeichnung Marken sein und als solche den gesetzlichen Bestimmungen unterliegen.

Die automatisierte Analyse des Werkes, um daraus Informationen insbesondere über Muster, Trends und Korrelationen gemäß § 44b UrhG (»Text und Data Mining«) zu gewinnen, ist untersagt.

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar.

ISBN Print: 978-3-98889-048-1

ISBN PDF: 978-3-98890-271-9

ISBN ePub: 978-3-98890-272-6

6., überarbeitete und aktualisierte Auflage 2025

dpunkt.verlag ist eine Marke des Rheinwerk Verlags.

Translation Copyright für die deutschsprachige Ausgabe © Rheinwerk Verlag, Bonn 2025

Rheinwerk Verlag GmbH • Rheinwerkallee 4 • 53227 Bonn

[email protected]

Vorwort zur 6. Auflage

Softwarearchitektur bildet – neben motivierten Teams und gutem Management – einen wichtigen Erfolgsfaktor von Softwareprojekten. Sie stellt im Sinne einer systematischen Konstruktion sicher, dass Qualitätsanforderungen wie beispielsweise Erweiterbarkeit, Flexibilität, Performance oder Time-to-Market erfüllt werden können.

Softwarearchitekten bringen die Kundenwünsche in Einklang mit den technischen Möglichkeiten und Randbedingungen. Sie sorgen für eine passende Struktur und das Zusammenspiel aller Systemkomponenten. Als Teamplayer arbeiten sie eng mit der Entwicklung sowie anderen Projektbeteiligten zusammen.

Unser Buch »Basiswissen für Softwarearchitekten« orientiert sich am Lehrplan zum »Certified Professional for Software Architecture – Foundation Level« (CPSA-F) des International Software Architecture Qualification Board (iSAQB®). Der iSAQB e.V. legt als internationales und offenes Gremium Standards für die Ausbildung, Prüfung und Zertifizierung von Softwarearchitekten fest.

Die 6. Auflage unseres Buches bietet eine Aktualisierung auf Basis des neuen CPSA-F-Lehrplans in der Version 2025.1RC-6 vom Januar 2025. Mit dem neuen Lehrplan wird diese Auflage um ein eigenes Kapitel zu Anforderungen und Randbedingungen erweitert. Außerdem wurde in das Kapitel über den Entwurf von Softwarearchitekturen das Thema Daten und Datenmodelle mit aufgenommen.

Bei der Überarbeitung des iSAQB®-Lehrplans wurden einige Themen auf weitere Ausbildungsstufen verschoben und sind somit nicht mehr Bestandteil des »Foundation Level«-Lehrplans. Diese Inhalte sind zwar weiterhin in unserem Buch zu finden, sie sind jedoch als »Exkurs« gekennzeichnet. Interessierte Leserinnen und Leser1 können sich also abseits vom Lehrplan über eine Erweiterung in Form von Exkursen freuen, die parallel zum Lehrplan praxisrelevante und verwandte Themen aufzeigen, Inhalte vertiefen oder moderne Ansätze vorstellen. Wer das Buch nur zur Prüfungsvorbereitung nutzt, der kann diese Exkurse ignorieren. Des Weiteren wurde das Glossar aktualisiert.

Mit der Zertifizierung zum CPSA-F weisen Softwarearchitekten einen fundierten Wissens- und Kenntnisstand für die Konstruktion kleiner und mittlerer Systeme nach. Ausgehend von einer hinreichend detailliert beschriebenen Anforderungsspezifikation können sie eine angemessene Softwarearchitektur entwerfen und dokumentieren. CPSA-F-Absolventinnen und -Absolventen besitzen damit das Rüstzeug, um problembezogene Entwurfsentscheidungen auf der Basis ihrer vorab erworbenen Praxiserfahrung zu treffen.

Das Selbststudium des vorliegenden Buches ermöglicht die Vorbereitung auf diese Zertifizierungsprüfung – praktische Erfahrung in Entwurf und Entwicklung von Softwaresystemen, das Beherrschen einer höheren Programmiersprache sowie der Grundlagen von UML vorausgesetzt. Darüber hinaus ist grundsätzlich der Besuch entsprechender Präsenzveranstaltungen zu empfehlen, weil der Erfahrungsaustausch mit anderen Fachleuten nicht durch Lektüre zu ersetzen ist.

Wir im Autorenteam arbeiten, lehren und forschen seit vielen Jahren im Bereich des Software & Systems Engineering sowie zur Konstruktion mittlerer und großer IT-Systeme. Wir hoffen, einen Teil unserer Erfahrungen in diesem Buch für Sie als Leserin oder Leser angemessen aufbereitet zu haben.

Wir wünschen Ihnen viel Spaß beim Lesen sowie viel Erfolg bei Ihrer Schulungsmaßnahme und Prüfung zum CPSA-F.

Mahbouba Gharbi, Arne Koschel, Andreas Rausch, Gernot Starke

Ludwigshafen, Hannover, Clausthal-Zellerfeld, Köln, im April 2025

Inhaltsübersicht

1

Einleitung

1.1

Softwarearchitektur als Disziplin im Software Engineering

1.2

iSAQB

®

– International Software Architecture Qualification Board

1.3

Certified Professional for Software Architecture – Foundation und Advanced Level

1.4

Zielsetzung des Buches

1.5

Voraussetzungen

1.6

Leitfaden für den Leser

1.7

Zielpublikum

1.8

Danksagungen

2

Grundlagen von Softwarearchitekturen

2.1

Einbettung in den iSAQB

®

-Lehrplan

2.2

Softwareintensive Systeme und Softwarearchitekturen

2.3

Grundlegende Konzepte von Softwarearchitekturen

2.4

Der Softwarearchitekturentwurf aus der Vogelperspektive

2.5

Lernkontrolle

3

Anforderungen und Randbedingungen

3.1

Einbettung in den iSAQB

®

-Lehrplan

3.2

Arbeit mit Randbedingungen und äußeren Einflussfaktoren

3.3

Anforderungen an Qualitäten formulieren

3.4

Szenarien

3.5

Lernkontrolle

4

Entwurf von Softwarearchitekturen

4.1

Einbettung in den iSAQB

®

-Lehrplan

4.2

Überblick über das Vorgehen beim Architekturentwurf

4.3

Entwurfsprinzipien und Heuristiken

4.4

Architekturzentrierte Entwicklungsansätze

4.5

Techniken für einen guten Entwurf

4.6

Architekturmuster

4.7

EXKURS:

Entwurfsmuster

4.8

Daten und Datenmodelle

4.9

Deployment und Betrieb

4.10

Lernkontrolle

5

Beschreibung und Kommunikation von Softwarearchitekturen

5.1

Einbettung in den iSAQB

®

-Lehrplan

5.2

Das CoCoME-Beispiel

5.3

Sichten und Schablonen

5.4

Technische oder querschnittliche Konzepte in Softwarearchitekturen

5.5

Architektur und Implementierung

5.6

Übliche Dokumenttypen für Softwarearchitekturen

5.7

Praxisregeln zur Dokumentation

5.8

Beispiele weiterer Architektur-Frameworks

5.9

Lernkontrolle

6

Analyse und Bewertung von Softwarearchitekturen

6.1

Einbettung in den iSAQB

®

-Lehrplan

6.2

Bewertung von Softwarearchitekturen

6.3

EXKURS:

Technischer Durchstich und Prototyp

6.4

Architekturanalyse

6.5

Lernkontrolle

7

EXKURS:

Werkzeuge für Softwarearchitekten

7.1

Allgemeine Hinweise zu Werkzeugen

7.2

Werkzeuge zum Anforderungsmanagement

7.3

Werkzeuge zur Modellierung

7.4

Werkzeuge zur statischen Codeanalyse

7.5

Werkzeuge zur dynamischen Analyse

7.6

Werkzeuge zum Konfigurations- und Versionsmanagement

7.7

Werkzeuge zum Codemanagement

7.8

Werkzeuge zum Testen

7.9

Werkzeuge zur Dokumentation

Anhang

A

Beispielfragen

A.1

Auszüge aus der Prüfungsordnung

A.2

Beispielfragen

B

Abkürzungsverzeichnis

C

Glossar

D

Literaturverzeichnis

Index

Inhaltsverzeichnis

1

Einleitung

1.1

Softwarearchitektur als Disziplin im Software Engineering

1.2

iSAQB

®

– International Software Architecture Qualification Board

1.3

Certified Professional for Software Architecture – Foundation und Advanced Level

1.4

Zielsetzung des Buches

1.5

Voraussetzungen

1.6

Leitfaden für den Leser

1.7

Zielpublikum

1.8

Danksagungen

2

Grundlagen von Softwarearchitekturen

2.1

Einbettung in den iSAQB

®

-Lehrplan

2.1.1

Lernziele

2.2

Softwareintensive Systeme und Softwarearchitekturen

2.2.1

Was ist ein softwareintensives System?

2.2.2

EXKURS:

Ausprägungen von softwareintensiven Systemen

2.2.3

Bedeutung der Softwarearchitektur für ein softwareintensives System

2.3

Grundlegende Konzepte von Softwarearchitekturen

2.3.1

Was ist eine Softwarearchitektur?

2.3.2

Bausteine, Schnittstellen und Konfigurationen

2.3.3

Konzepte der Beschreibung von Softwarearchitekturen

2.3.4

Architekturbeschreibung und Architekturebenen

2.3.5

Wechselwirkungen zwischen Softwarearchitektur und Umgebung

2.3.6

Qualität und Nutzen der Softwarearchitektur

2.4

Der Softwarearchitekturentwurf aus der Vogelperspektive

2.4.1

Ziele und Aufgaben des Softwarearchitekturentwurfs

2.4.2

Der Softwarearchitekturentwurf im Überblick

2.4.3

Wechselspiel der Tätigkeiten und Abstraktionsstufen im Entwurf

2.4.4

Aufgaben des Softwarearchitekten und Bezug zu anderen Rollen

2.5

Lernkontrolle

3

Anforderungen und Randbedingungen

3.1

Einbettung in den iSAQB

®

-Lehrplan

3.1.1

Lernziele

3.2

Arbeit mit Randbedingungen und äußeren Einflussfaktoren

3.2.1

Anliegen der Stakeholder

3.2.2

Arten von Einflussfaktoren

3.3

Anforderungen an Qualitäten formulieren

3.3.1

Qualitätsmodelle und Qualitätsmerkmale

3.3.1.1

Qualitätsmodell DIN ISO/IEC 25010:2023

3.3.1.2

Qualitätsmerkmale

3.3.1.3

Auswirkungen bestimmter Qualitätsmerkmale

3.3.1.4

Taktiken und Praktiken

3.3.2

Messbarkeit von Qualitäten

3.4

Szenarien

3.4.1

Arten von Szenarien

3.4.2

Bestandteile von Szenarien

3.4.3

Beispiele für Szenarien

3.5

Lernkontrolle

4

Entwurf von Softwarearchitekturen

4.1

Einbettung in den iSAQB

®

-Lehrplan

4.1.1

Lernziele

4.2

Überblick über das Vorgehen beim Architekturentwurf

4.3

Entwurfsprinzipien und Heuristiken

4.3.1

Top-down und bottom-up

4.3.2

Hierarchische (De-)Komposition

4.3.2.1

Divide et impera

4.3.2.2

Prinzipien bei der Zerlegung

4.3.2.3

So-einfach-wie-möglich-Prinzip

4.3.2.4

Trennung von Verantwortlichkeiten

4.3.3

Konzeptionelle Integrität

4.3.4

Erwarte Fehler

4.3.4.1

Postel’s Law

4.3.5

Schmale Schnittstellen und Information Hiding

4.3.5.1

Information Hiding

4.3.5.2

Verwendung von Schnittstellen

4.3.6

Regelmäßiges Refactoring und Redesign

4.4

Architekturzentrierte Entwicklungsansätze

4.4.1

EXKURS:

Domain-Driven Design

4.4.1.1

Fachmodelle als Basis

4.4.1.2

Systematische Verwaltung der Domänenobjekte

4.4.1.3

Strukturierung der Fachdomäne

4.4.1.4

Arten von Domänen

4.4.1.5

Integration von Domänen

4.4.2

EXKURS:

Globale Analyse

4.4.3

EXKURS:

Evolutionäre Architektur

4.4.3.1

Prinzipien

4.4.3.2

Fitnessfunktionen

4.4.4

EXKURS:

Modellgetriebene Architektur

4.4.5

Referenzarchitekturen

4.4.5.1

Generative Erzeugung von Systembausteinen

4.4.5.2

Aspektorientierung

4.4.5.3

Objektorientierung

4.4.5.4

Prozedurale Ansätze

4.5

Techniken für einen guten Entwurf

4.5.1

Ausgangssituation und Motivation: degeneriertes Design

4.5.2

Lose Kopplung

4.5.3

Hohe Kohäsion

4.5.4

Single-Responsibility-Prinzip

4.5.5

Offen-geschlossen-Prinzip

4.5.6

Umkehr der Abhängigkeiten

4.5.7

Abtrennung von Schnittstellen

4.5.8

Zyklische Abhängigkeiten auflösen

4.5.9

Liskov’sches Substitutionsprinzip

4.6

Architekturmuster

4.6.1

Adaptierbare Systeme

4.6.1.1

Dependency Injection

4.6.2

Interaktive Systeme

4.6.2.1

Model View Controller

4.6.2.2

Model View Presenter

4.6.2.3

Presentation Abstraction Control

4.6.3

Vom Chaos zur Struktur

4.6.3.1

Schichtenarchitektur

4.6.3.2

Pipes and Filters

4.6.3.3

Blackboard

4.6.4

Verteilte Systeme

4.6.4.1

Herausforderungen verteilter Systeme

4.6.4.2

Broker

4.6.4.3

EXKURS:

Serviceorientierung

4.6.4.4

Modularisierung

4.6.4.5

Microservices

4.7

EXKURS:

Entwurfsmuster

4.7.1

Adapter

4.7.2

Observer

4.7.3

Decorator

4.7.4

Proxy

4.7.5

Fassade

4.7.6

Brücke

4.7.7

State

4.7.8

Mediator

4.7.9

Fabrik

4.7.10

Interpreter

4.7.11

Plug-in

4.7.12

Kombinator

4.8

Daten und Datenmodelle

4.8.1

Datenmodelle

4.8.2

Arten von Daten

4.8.3

Auswirkungen von Daten auf Architekturentscheidungen

4.9

Deployment und Betrieb

4.9.1

Deployment

4.9.2

Betrieb

4.9.3

EXKURS:

DevOps

4.10

Lernkontrolle

5

Beschreibung und Kommunikation von Softwarearchitekturen

5.1

Einbettung in den iSAQB

®

-Lehrplan

5.1.1

Lernziele

5.2

Das CoCoME-Beispiel

5.2.1

Anwendungsfälle im CoCoME-System

5.2.2

Übersicht über den strukturellen Aufbau des CoCoME-Systems

5.3

Sichten und Schablonen

5.3.1

Bewährte Sichten nach iSAQB

®

5.3.2

UML-Diagramme als Notationsmittel in Sichtenbeschreibungen

5.3.3

Sichtenbeschreibung – Grobaufbau und Einführungsbeispiel

5.3.3.1

Grobaufbau – schablonenartige Sichtenbeschreibung

5.3.3.2

Beispiel: Auszug aus einer Sichtenbeschreibung für eine Bausteinsicht

5.3.4

Kontextsicht oder Kontextabgrenzung

5.3.5

Bausteinsicht

5.3.6

Laufzeitsicht

5.3.7

Verteilungssicht bzw. Infrastruktursicht

5.3.8

Wechselwirkungen zwischen Architektursichten

5.3.9

Hierarchische Verfeinerung von Architektursichten

5.4

Technische oder querschnittliche Konzepte in Softwarearchitekturen

5.4.1

Technische bzw. querschnittliche Konzepte: Beispieldimensionen

5.4.2

Beispiel: Fehlerbehandlung

5.4.3

Beispiel: Sicherheit

5.5

Architektur und Implementierung

5.5.1

Beispiel: Implementierung

5.6

Übliche Dokumenttypen für Softwarearchitekturen

5.6.1

Zentrale Architekturbeschreibung

5.6.2

Architekturüberblick

5.6.3

Dokumentübersicht

5.6.4

Übersichtspräsentation

5.6.5

»Architekturtapete«

5.6.6

Handbuch zur Dokumentation

5.6.7

Architecture Decision Record

5.6.8

Technische Informationen

5.6.9

Dokumentation von externen Schnittstellen

5.6.10

Template

5.7

Praxisregeln zur Dokumentation

5.7.1

Regel 1: »Schreiben aus der Sicht der Leser«

5.7.2

Regel 2: »Unnötige Wiederholung vermeiden«

5.7.3

Regel 3: »Mehrdeutigkeit vermeiden«

5.7.4

Regel 4: »Standardisierte Organisationsstruktur bzw. Schablonen«

5.7.5

Regel 5: »Begründen Sie wesentliche Entscheidungen schriftlich«

5.7.6

Regel 6: »Überprüfung auf Gebrauchstauglichkeit«

5.7.7

Regel 7: »Übersichtliche Diagramme«

5.7.8

Regel 8: »Regelmäßige Aktualisierungen«

5.7.9

EXKURS:

Regel 9: »Passen Sie die Änderbarkeit der Dokumentation an die Architektur an«

5.8

Beispiele weiterer Architektur-Frameworks

5.8.1

4+1-Framework

5.8.2

SAGA

5.9

Lernkontrolle

6

Analyse und Bewertung von Softwarearchitekturen

6.1

Einbettung in den iSAQB

®

-Lehrplan

6.1.1

Lernziele

6.2

Bewertung von Softwarearchitekturen

6.2.1

Qualitative Bewertung

6.2.2

Quantitative Bewertung

6.2.2.1

Überprüfung von Architekturregeln

6.2.2.2

Metriken

6.2.2.3

Zyklomatische Komplexität

6.2.2.4

Goodharts Gesetz

6.3

EXKURS:

Technischer Durchstich und Prototyp

6.3.1

Technischer Durchstich

6.3.2

Prototyp

6.3.2.1

Einsatz von Softwareprototypen

6.3.2.2

Arten von Softwareprototypen

6.4

Architekturanalyse

6.4.1

EXKURS:

ATAM-Methode

6.4.1.1

Vorgehen bei der Bewertung

6.5

Lernkontrolle

7

EXKURS

: Werkzeuge für Softwarearchitekten

7.1

Allgemeine Hinweise zu Werkzeugen

7.1.1

Kosten von Werkzeugen

7.1.2

Lizenzen und Lizenzbedingungen

7.2

Werkzeuge zum Anforderungsmanagement

7.2.1

Anforderungen und Entscheidungskriterien

7.2.2

Herausforderungen von Werkzeugen für das Anforderungsmanagement

7.2.3

Beispielhafte Vertreter

7.3

Werkzeuge zur Modellierung

7.3.1

Anforderungen und Entscheidungskriterien

7.3.2

Herausforderungen von Werkzeugen für die Modellierung

7.3.3

Beispielhafte Vertreter

7.4

Werkzeuge zur statischen Codeanalyse

7.4.1

Anforderungen und Entscheidungskriterien

7.4.2

Herausforderungen von Werkzeugen zur statischen Codeanalyse

7.4.3

Beispielhafte Vertreter

7.5

Werkzeuge zur dynamischen Analyse

7.5.1

Anforderungen und Entscheidungskriterien

7.5.2

Herausforderungen von Werkzeugen zur dynamischen Analyse

7.5.3

Beispielhafte Vertreter

7.6

Werkzeuge zum Konfigurations- und Versionsmanagement

7.6.1

Anforderungen und Entscheidungskriterien

7.6.2

Herausforderungen von Werkzeugen zum Konfigurations- und Versionsmanagement

7.6.3

Beispielhafte Vertreter

7.7

Werkzeuge zum Codemanagement

7.7.1

Herausforderungen von Werkzeugen zum Codemanagement

7.7.2

Beispielhafte Vertreter

7.8

Werkzeuge zum Testen

7.8.1

Anforderungen und Entscheidungskriterien

7.8.2

Herausforderungen von Testwerkzeugen

7.8.3

Beispielhafte Vertreter

7.9

Werkzeuge zur Dokumentation

7.9.1

Anforderungen und Entscheidungskriterien

7.9.2

Herausforderungen von Dokumentationswerkzeugen

7.9.3

Beispielhafte Vertreter

Anhang

A

Beispielfragen

A.1

Auszüge aus der Prüfungsordnung

A.2

Beispielfragen

B

Abkürzungsverzeichnis

C

Glossar

D

Literaturverzeichnis

Index

1 Einleitung

Software ist allgegenwärtig. Dies gilt sowohl für kommerzielle Unternehmenssoftware als auch für nahezu alle anderen Bereiche des beruflichen, öffentlichen und privaten Alltags: Fliegen, Telefonieren, Überweisen, Autofahren – all das wäre ohne Software kaum noch möglich. In jedem Haushalt und in vielen Alltagsgegenständen, von der Waschmaschine bis zum Auto, werden softwaregesteuerte Bestandteile verwendet [BJ++06]. Software steht in der Regel nicht autark für sich, sondern ist in Geräte mit Hardware und Elektronik oder in Geschäftsprozesse, mit denen Unternehmen ihre Wertschöpfung erzielen, eingebettet [TTL00].

Der Nutzen und wirtschaftliche Erfolg von Unternehmen und Produkten wird zunehmend von Software und deren Qualität bestimmt (siehe [BM++96], [SV99], [TTL00]). Als Folge stehen Softwareingenieure und damit die Disziplin Software Engineering vor der Herausforderung, immer komplexere Anforderungen immer schneller und kostengünstiger bei gleichzeitig hoher Softwarequalität umzusetzen.

Die kontinuierliche Steigerung der Größe und Komplexität von softwareintensiven Systemen hat inzwischen dazu geführt, dass sie zu den komplexesten von Menschen geschaffenen künstlichen Systemen überhaupt zählen. Bestes Beispiel ist das Internet: ein auf Software basierendes weltumspannendes System. Inzwischen ist das Internet sogar auf der internationalen Raumstation ISS verfügbar und hat damit die Grenzen der Erde überschritten.

Nur ein strukturiertes und systematisches Herangehen kann dabei gesichert zum Erfolg führen. Trotz Anwendung etablierter Softwareentwicklungsmethoden bleibt die Anzahl der fehlgeschlagenen Softwareprojekte seit Jahren erschreckend hoch. Um dem entgegenzuwirken, versucht man in den frühen Phasen des Software Engineering bereits möglichst viele Fehler zu vermeiden bzw. dort zu identifizieren und auszumerzen. Zu diesen Phasen zählen insbesondere das Requirements Engineering sowie die Softwarearchitektur. Getreu den Worten von Ernst Denert, einem der Väter der methodischen Softwareentwicklung, wollen wir uns hier mit Softwarearchitektur beschäftigen, der »Königsdisziplin des Software Engineering« (zitiert aus dem Geleitwort von Ernst Denert in [Sie04]).

1.1 Softwarearchitektur als Disziplin im Software Engineering

Bereits in den 60er-Jahren wurden die Probleme mit Softwareprojekten unter dem Stichwort Softwarekrise bekannt. 1968 fand in Garmisch eine NATO-Konferenz hochrangiger Forscher und Praktiker statt, um unter dem Titel »Software Engineering« über die Zukunft der Softwareentwicklung nachzudenken. Heute gilt diese Konferenz als Geburtsstunde des Software Engineering [Dij72].

Im Vergleich zu traditionellen Ingenieurdisziplinen wie beispielsweise dem Bauwesen, das auf mehrere Tausend Jahre Erfahrung zurückblicken kann, ist Software Engineering mit dem Geburtsjahr 1968 noch sehr jung. So erscheint es auch nicht verwunderlich, dass dessen Teildisziplin Softwarearchitektur noch deutlich jünger ist. Abbildung 1.1 demonstriert dies deutlich: Das Web of Knowledge, eine der großen und renommierten Publikationsdatenbanken, verzeichnet erst ab den 90er-Jahren eine wachsende Anzahl von Publikationen zum Thema Softwarearchitektur [Reu12].

Abb.

1.1

Veröffentlichungen zu Softwarearchitektur seit 1973 [Reu12]

Betrachten wir hingegen die klassische Architektur im Bauwesen, so können wir auf eine bereits Jahrtausende währende Tradition zurückblicken. Ein wichtiger Vordenker war hier Marcus Vitruvius Pollio, ein römischer Architekt aus dem ersten Jahrhundert vor Christus. Er ist Autor des Werkes »De architectura«, das heute unter dem Titel »Ten Books on Architecture« bekannt ist [Vit60]. Vitruvius vertrat die These, dass gute Architektur durch eine kunstvolle Kombination der folgenden Elemente zu erreichen sei:

■

utilitas (Nützlichkeit):

Das Gebäude erfüllt seine Funktion.

■

firmitas (Festigkeit):

Das Gebäude ist stabil und langlebig.

■

venustas (Schönheit):

Das Gebäude ist ästhetisch gestaltet.

Abb.

1.2

Architektur im alten Rom

Diese These lässt sich direkt auf die Disziplin Softwarearchitektur übertragen. Ziel der Softwarearchitektur und damit Aufgabe eines Softwarearchitekten ist es, ein System zu konstruieren, das in einem kunstvoll ausgewogenen Dreiklang die drei folgenden Eigenschaften vereint:

■

utilitas (Nützlichkeit):

Die Software erfüllt die funktionalen und nicht funktionalen Anforderungen der Nutzer und Kunden.

■

firmitas (Festigkeit):

Die Software ist stabil im Hinblick auf die geforderten Qualitätseigenschaften, z. B. die Anzahl der gleichzeitig zu bedienenden Nutzer, und langlebig, da zukünftige Weiterentwicklungen möglich sind, ohne das System komplett neu bauen zu müssen.

■

venustas (Schönheit):

Die Software ist sowohl nach außen gegenüber dem Nutzer als auch nach innen gegenüber demjenigen, der die Software pflegen und weiterentwickeln soll, gut strukturiert. Dadurch ist sie intuitiv nutzbar und die internen Strukturen sind leicht verständlich, sodass die Aufgaben gut erledigt werden können.

1.2 iSAQB® – International Software Architecture Qualification Board

Softwarearchitektur ist eine junge Disziplin, über deren Umfang und Ausgestaltung in der Informatik trotz vieler Publikationen immer noch unterschiedliche Meinungen kursieren. Aufgaben und Verantwortungsbereiche von Softwarearchitekten werden unterschiedlich definiert und in Softwareprojekten ständig neu verhandelt.

Für andere Disziplinen im Software Engineering hingegen, wie z.B. beim Projektmanagement, Requirements Engineering oder Testen, gibt es inzwischen einen deutlich ausgereifteren Wissenskanon. Dafür bieten unabhängige Organisationen Lehrpläne an, die klar beschreiben, welche Kenntnisse und Fähigkeiten eine entsprechende Ausbildung vermitteln soll (Testen: www.istqb.org_[ISTQB], Requirements Engineering: www.ireb.de [IREB], Projektmanagement: www.pmi.org [PMI]).

Vor diesem Hintergrund haben Anfang 2008 verschiedene Softwarearchitekturexperten aus Wirtschaft und Wissenschaft das »International Software Architecture Qualification Board« als eingetragenen Verein (iSAQB e.V., www.isaqb.org) gegründet. Dessen Ziel ist es, Standards für die Ausbildung und Zertifizierung von Softwarearchitekten zu definieren. Bewusst wird im iSAQB® jegliche Hersteller- oder Produktorientierung vermieden. Zertifizierungen auf den unterschiedlichen Stufen Foundation Level, Advanced Level und Expert Level ermöglichen es Softwarearchitekten, sich den Stand ihrer Kenntnisse und Fähigkeiten durch ein anerkanntes Verfahren bescheinigen zu lassen (siehe Abbildung 1.3).

Abb.

1.3

iSAQB

®

-Zertifizierungsstufen (

www.isaqb.org

)

Von diesem standardisierten Lehr- und Ausbildungsplan profitieren sowohl etablierte als auch angehende Softwarearchitekten und ebenso Unternehmen oder auch entsprechende Aus- und Weiterbildungseinrichtungen, da er die eingangs geschilderte begriffliche Unsicherheit beseitigt. Nur auf Basis von präzisen Lehr- und Ausbildungsplänen kann eine Prüfung und Zertifizierung angehender Softwarearchitekten stattfinden und so letztlich ein qualitätsgesicherter Ausbildungsstand von Softwarearchitekten mit einem entsprechend akzeptierten Wissenskanon etabliert werden.

Die Zertifizierung zum Certified Professional for Software Architecture (CPSA) wird von unabhängigen Zertifizierungsstellen durchgeführt. Basis für die Zertifizierung zum CPSA (Foundation Level) ist ein anspruchsvoller, vom iSAQB® in Einklang mit dem Lehrplan entwickelter, nicht öffentlicher Fragenkatalog, aus dem eine Teilmenge als Prüfungsfragen ausgewählt wird. Für die Zertifizierung zum Advanced Level werden neben der Erfordernis des Besuchs von lizenzierten Schulungen bzw. der Anerkennung eines anderen, nicht durch den iSAQB® definierten Zertifikats praktische Aufgaben gestellt. Der Expert Level befindet sich derzeit noch in Entwicklung.

Auf Basis dieses Lehrplans bieten verschiedene lizenzierte Schulungsveranstalter mehrtägige Kurse an, die Wissen in diesen Themengebieten auffrischen und vielfach deutlich vertiefen. Die Teilnahme an einem Kurs wird zwar nachdrücklich empfohlen, ist jedoch nicht Bedingung für die Prüfungsanmeldung zur Zertifizierung.

1.3 Certified Professional for Software Architecture – Foundation und Advanced Level

Der iSAQB® hat inzwischen nicht nur die Zertifizierungsrichtlinien für den CPSA Foundation Level, sondern auch für den Advanced Level definiert.

Der Advanced Level ist modular aufgebaut und besteht aus einzelnen Schulungen, die sich jeweils einem bestimmten Schwerpunkt der Kompetenz eines IT-Professionals widmen:

■

Methodische Kompetenz:

Wissen und Fähigkeiten im Bereich des systematischen Vorgehens bei IT-Projekten, unabhängig von Technologien

■

Technische Kompetenz:

Wissen und Fähigkeiten im Bereich des Einsatzes von Technologien zur Lösung von Entwurfsaufgaben

■

Kommunikative Kompetenz:

Wissen und Fähigkeiten im Bereich der Kommunikation, Präsentation, Rhetorik und Moderation zur effektiven Wahrnehmung der Rolle im Softwareentwicklungsprozess

Voraussetzungen für den Advanced Level sind:

■

Ausbildung und Zertifizierung zum CPSA-F (Foundation Level)

■

Mindestens 3 Jahre Berufserfahrung in der IT-Branche

■

Mitarbeit an Entwurf und Entwicklung von mindestens zwei verschiedenen IT-Systemen

■

Für die Prüfung: mindestens 70 Credit Points aus allen drei Kompetenzbereichen (jeweils mindestens 10 Credit Points)

Die Prüfung besteht aus der Bearbeitung einer Prüfungsaufgabe in Eigenregie und der anschließenden Besprechung der Lösung mit zwei unabhängigen Prüfern in einem Interview.

Für den Foundation Level wurden die Bereiche, in denen ein Softwarearchitekt über fundiertes Wissen und geeignete Fähigkeiten verfügen sollte, im Rahmen eines öffentlich zugänglichen Lehrplans beschrieben [isaqb-lehrplan]. Danach soll angehenden Softwarearchitekten folgendes Spektrum an Inhalten vermittelt werden:

■

der Begriff und die Bedeutung von Softwarearchitektur,

■

die Aufgaben und Verantwortungsbereiche von Softwarearchitekten,

■

die Rolle des Softwarearchitekten in Projekten,

■

State-of-the-Art-Methoden und -Techniken zur Entwicklung von Softwarearchitekturen.

Im Mittelpunkt steht der Erwerb folgender Fähigkeiten:

■

mit anderen Projektbeteiligten aus den Bereichen Anforderungsmanagement, Projektmanagement, Test und Entwicklung wesentliche Softwarearchitekturentscheidungen abzustimmen,

■

Softwarearchitekturen auf Basis von Sichten, Architekturmustern und technischen Konzepten zu dokumentieren und zu kommunizieren,

■

die wesentlichen Schritte beim Entwurf von Softwarearchitekturen zu verstehen und für kleine und mittlere Systeme selbstständig durchzuführen.

Die Schulung zum Foundation Level vermittelt das notwendige Wissen, um für kleine und mittlere Systeme ausgehend von einer hinreichend detailliert beschriebenen Anforderungsspezifikation eine dem Problem angemessene Softwarearchitektur zu entwerfen und zu dokumentieren. Diese kann dann als Implementierungsgrundlage bzw. -vorlage genutzt werden. Teilnehmer erhalten das Rüstzeug, um problembezogene Entwurfsentscheidungen auf der Basis ihrer vorab erworbenen Praxiserfahrung zu treffen.

Abbildung 1.4 zeigt die inhaltliche Struktur und die Gewichtung der einzelnen Bereiche des Lehrplans für den iSAQB® Certified Professional for Software Architecture (CPSA), Foundation Level.

Abb.

1.4

Struktur des iSAQB

®

-Lehrplans für CPSA, Foundation Level

Sie haben die Möglichkeit, sich bei verschiedenen unabhängigen Anbietern durch eine Prüfung gemäß dem iSAQB®-Lehrplan zertifizieren zu lassen. Für die Zertifizierung setzen die Prüfungsanbieter standardisierte Prüfungsfragen ein, die der iSAQB® erarbeitet hat.

Für die Prüfungen wird ein Multiple-Choice-Verfahren verwendet. Entsprechend objektiv ist das Prüfungsergebnis messbar.

Mit der Prüfung können Sie somit Ihr notwendiges Grundlagenwissen als Softwarearchitekt nachweisen. Natürlich müssen Sie dann später in der Anwendung zeigen, dass Sie Ihr Wissen auch praktisch und erfolgreich in konkreten Architekturen einzusetzen wissen.

1.4 Zielsetzung des Buches

Wir, das Autorenteam des Buches, haben gemeinsam mit anderen iSAQB®-Mitgliedern am iSAQB®-Lehrplan für den Certified Professional for Software Architecture, Foundation Level, gearbeitet. Im Rahmen dieser Zusammenarbeit ist auch die Idee zu diesem Buch entstanden. Dementsprechend verfolgen wir darin die zentrale Zielsetzung, kompakt und prägnant das notwendige Wissen für die CPSA-Prüfung, Foundation Level, und somit das Fundament für den Wissenskanon in der Disziplin Softwarearchitektur bereitzustellen. Das Buch ist demzufolge die ideale Referenz für eine entsprechende Prüfungsvorbereitung. Wir empfehlen Ihnen ergänzend den Besuch entsprechender Schulungen, da dort das Lehrmaterial durch über dieses Buch hinausgehende praktische Beispiele von Softwarearchitekturen und persönliche Erfahrungen der Dozenten oder Trainer abgerundet wird.

Da der iSAQB® und somit auch das Buch primär auf methodische Fähigkeiten und Wissen fokussiert, gehören konkrete Implementierungstechnologien oder spezielle Werkzeuge explizit nicht zum standardisierten Lehrinhalt. Deshalb haben wir dieses Buch bewusst technologieneutral verfasst. Auch die von uns verwendeten Notationen, wie z. B. die UML, sind nur exemplarisch zu verstehen. Ebenso ist es nicht Ziel des Buches, ein einzelnes konkretes Vorgehensmodell oder einen spezifischen Entwicklungsprozess darzustellen. Vielmehr werden von uns an vielen Stellen mehrere Beispiele etwa für Notationen oder Vorgehensmodelle kurz vorgestellt.

In diesem Buch erklären wir vor allem wichtige Begriffe und Konzepte der Softwarearchitektur und stellen deren Bezug zu anderen Disziplinen dar. Darauf aufbauend führen wir die grundlegenden Techniken und Methoden für den Entwurf und die Entwicklung, die Beschreibung und Kommunikation sowie die Qualitätssicherung von Softwarearchitekturen ein. Schließlich betrachten wir die Rolle, die Aufgaben, das Umfeld und die Arbeitsumgebung von Softwarearchitekten und deren Einbettung in die umfassende Organisations- und Projektstruktur.

1.5 Voraussetzungen

Entsprechend der oben genannten Zielsetzung setzt das vorliegende Buch – wie auch der iSAQB®-Lehrplan – Erfahrung in der Softwareentwicklung voraus. Insbesondere gehören folgende Inhalte nicht zum Lehrplan und sind damit auch nicht Thema des Buches, obgleich sie zu den notwendigen Kompetenzen von Softwarearchitekten zählen:

■

typischerweise mehrjährige praktische Erfahrung in der Softwareentwicklung, erworben durch Programmierung unterschiedlicher Systeme,

■

vertiefte Kenntnisse und praktische Erfahrung mit mindestens einer höheren Programmiersprache,

■

Grundlagen der Modellierung und Abstraktion sowie der Modellierungssprache UML, insbesondere der Klassen-, Paket-, Komponenten- und Sequenzdiagramme sowie deren Bezug zum Quellcode,

■

praktische Erfahrung in technischer Dokumentation, insbesondere in der Dokumentation von Quellcode, Systementwürfen oder technischen Konzepten,

■

Kenntnisse über die Methodik beim Testen von Software in den verschiedenen Teststufen.

Darüber hinaus sind Kenntnisse und Erfahrung mit der Objektorientierung für das Verständnis einiger Konzepte hilfreich. Ebenfalls wünschenswert ist Erfahrung in der Konzeption und Implementierung verteilt ablaufender Anwendungen wie etwa Client-Server-Systeme oder Webanwendungen.

1.6 Leitfaden für den Leser

Der Aufbau dieses Buches orientiert sich vor allem an der Struktur und den Inhalten des iSAQB®-Lehrplans Foundation Level nach Abbildung 1.4 bzw. [isaqblehrplan]:

■

In

Kapitel 2

beschreiben wir grundlegende Begriffe und Inhalte des Themenbereichs Softwarearchitektur, die in den folgenden Kapiteln aufgegriffen und vertieft werden. Beispielsweise wird dort der Begriff der »Sicht« auf ein Softwaresystem im Rahmen einer Softwarearchitektur eingeführt.

■

In

Kapitel 3

diskutieren wir den Umgang mit Anforderungen und Randbedingungen. Dabei wird auf die Arbeit mit Randbedingungen und Einflussfaktoren, das Formulieren von Qualitätsanforderungen und den Einsatz von Szenarien eingegangen. Wichtige Begriffe: Softwarequalität, Qualitätsmodelle und Qualitätsmerkmale, Kompromisse zwischen Qualitätsmerkmalen, Taktiken und Praktiken zur Erreichung von Qualitätsmerkmalen, Szenarien.

■

Aspekte des praktischen Entwurfs von Softwarearchitekturen erörtern wir in

Kapitel 4

. Themen sind dort unter anderem Varianten des Vorgehens bei der Architekturentwicklung, wichtige Architekturmuster wie Schichten, Pipes and Filters, Model View Controller sowie Entwurfsprinzipien wie Kopplung, Kohäsion und Trennung von Verantwortlichkeiten. Darüber hinaus werden Daten, Datenmodelle, Deployment und Betrieb behandelt.

■

In

Kapitel 5

werden ausgewählte praxisnahe Beschreibungsmittel sowie in der Praxis bewährte Richtlinien vorgestellt. Diese ermöglichen es Ihnen, Ihre Softwarearchitektur zu dokumentieren und zielgruppenorientiert anderen zu vermitteln. Das iSAQB

®

-Sichtenmodell, Querschnittsaspekte in Softwarearchitekturen sowie praktisch bewährte Richtlinien für die Dokumentation von Softwarearchitekturen sind Beispiele für den Inhalt des Kapitels.

■

In

Kapitel 6

werfen wir einen ersten Blick auf den Zusammenhang von Softwarearchitektur und Qualitätsfragestellungen. Wichtige Begriffe dieses Abschnitts sind u.a. bezogen auf Software: Architekturbewertung (qualitativ und quantitativ), ATAM (Architecture Tradeoff Analysis Method) und Risiken bezüglich der Erreichung von Qualitätsmerkmalen.

■

Abschließend zeigen wir in

Kapitel 7

(Exkurs) eine Reihe von Beispielen für Unterstützungswerkzeuge des Softwarearchitekten, wie z. B. solche zur Modellierung, Generierung oder Dokumentation.

■

Einige beispielhafte Übungsfragen, ein Glossar sowie ein Quellenverzeichnis runden das Buch ab.

Speziell zur iSAQB®-Prüfungsvorbereitung sollten Sie vor allem die Kapitel 2 – Kapitel 6 gründlich durcharbeiten und ergänzend einen Blick in Kapitel 7 und weitere Exkurse werfen. Ansonsten empfiehlt es sich, zumindest das Kapitel 2komplett zu lesen und anschließend die Themen zu vertiefen, die Sie besonders interessieren.

1.7 Zielpublikum

Als Zielpublikum dieses Buches sehen wir in erster Linie Zertifizierungsinteressierte, die es – ggf. neben Schulungen – als Vorbereitung zur Prüfung einsetzen wollen. Hinzu kommen Praktiker und Studierende, die die praktischen Grundbegriffe von Softwarearchitekturen kennenlernen wollen.

Interessant ist dieses Buch auch für Softwareprojektmanager, Softwareproduktmanager sowie Entscheider auf der mittleren Softwareentwicklungsebene als Einstiegsüberblick zum Thema Softwarearchitektur.

1.8 Danksagungen

Wir möchten uns an dieser Stelle beim iSAQB-Verein für seine unterstützende Mitwirkung bedanken. Frau Ingrid Schindler vom Lehrstuhl für Software Systems Engineering der Technischen Universität Clausthal und Mitarbeiter der ITech Progress haben uns beim Anfertigen der Abbildungen sehr unterstützt. Die Erstellung der 6. Auflage wäre ohne die unermüdliche Unterstützung von Dimitri Blatner und Thomas Garratt von ITech Progress nicht möglich gewesen.

Unserer Betreuerin seitens des dpunkt.verlags, Frau Christa Preisendanz, danken wir für ihre Geduld.

Zu guter Letzt möchten wir ganz besonders unseren Familien und Partnern danken, die an zahllosen Tagen die Zeit und die Geduld aufgebracht haben, uns gemeinsam an diesem Buch arbeiten zu lassen.

2 Grundlagen von Softwarearchitekturen

Wie bereits eingangs beschrieben, ist Software heute fast allgegenwärtig. Nahezu rund um die Uhr verlassen wir uns auf das korrekte Funktionieren von Software, angefangen vom Klingeln des Weckers am Morgen über funktionierende Bremsen in Autos und bei der Bahn bis zur Verwaltung unseres Geldes auf Bankkonten.

Trotz dieser Allgegenwärtigkeit und unserer Abhängigkeit von Software haben wir Softwareingenieure es immer noch nicht in der notwendigen Tiefe verstanden, wie man Software wiederholbar erfolgreich baut: Softwareprojekte dauern zu lange, kosten zu viel, scheitern zu oft. Und selbst wenn ein Softwareprojekt erfolgreich in den Betrieb geht, ist das Ergebnis für die Beteiligten oft mangelhaft. Dies attestiert uns der CHAOS-Report der Standish Group in jährlichen Abständen immer wieder [Sta99]. Auch alle Kritik am CHAOS-Report im Speziellen kann nicht darüber hinwegtäuschen, dass andere Erfolgserhebungsmethoden ganz ähnliche, nicht schmeichelhafte Ergebnisse liefern (siehe [EK08], [EV10]): Unterm Strich ist unsere Fähigkeit, Softwareprojekte innerhalb des magischen Vierecks (siehe [Bal00], [Die00], [Dum01], [Lit05], [May05]) erfolgreich abzuwickeln, sehr begrenzt (vgl. Abbildung 2.1). Wir schaffen es immer noch nicht, wiederholbar qualitativ hochwertige Software zu erschwinglichen Kosten und im vorgegebenen Zeitfenster mit der notwendigen Funktionalität zu erstellen.

Abb.

2.1

Das magische Viereck erfolgreicher Softwareprojekte

Will man erfolgreich Software entwickeln, dann sind Requirements Engineering und Architekturentwurf nachweislich zwei zentrale Schlüsselfaktoren. Bei beiden ist das Risiko von gravierenden Fehlentwicklungen hoch, da früh – insbesondere bei noch eingeschränktem Wissensstand – Entscheidungen zu treffen sind, deren Auswirkungen weit reichen und teilweise erst deutlich später im Projektverlauf erkennbar werden (siehe [Nus01], [GEM04]).

Deshalb ist Softwarearchitektur einer der entscheidenden Erfolgsfaktoren in der Softwareentwicklung. Denn der Architekturentwurf entscheidet mit darüber, wie man Millionen von Programmzeilen großer softwareintensiver Systeme so strukturiert, dass im Ergebnis die geforderte Funktionalität mit der gewünschten Qualität bei Erfüllung der finanziellen Vorgaben im vereinbarten Zeitrahmen zur Verfügung steht (vgl. Abbildung 2.1).

Aber was ist Softwarearchitektur eigentlich? Was sind die Kernkonzepte in diesem so entscheidenden Teilgebiet des Software Engineering? Welche Vorgehensweisen und Ansätze gibt es für einen erfolgreichen Architekturentwurf?

Wie Software Engineering ist auch Softwarearchitektur ein junges Gebiet. Deshalb finden sich viele unterschiedliche Auffassungen zu den genannten Fragestellungen – und diese möchten wir hier nicht etwa abwerten oder schlicht als falsch disqualifizieren. Vielmehr möchten wir in diesem Kapitel unser grundlegendes Verständnis von Softwarearchitektur darlegen und so die Basis für die nachfolgenden Kapitel liefern.

Zunächst werden wir den Begriff des softwareintensiven Systems und den damit einhergehenden Zusammenhang mit der Softwarearchitektur vorstellen. Darauf aufbauend können wir dann die zentralen Grundbegriffe von Softwarearchitekturen vorstellen und definieren. Schließlich führen wir das grundlegende Vorgehen beim Architekturentwurf ein und stellen das Wechselspiel mit den anderen Disziplinen und Rollen vor.

2.1 Einbettung in den iSAQB®-Lehrplan

Nachfolgend finden Sie die Lernziele des Kapitels »Grundlagen von Softwarearchitekturen« aus dem iSAQB®-Lehrplan [isaqb-lehrplan].

2.1.1 Lernziele

■

LZ 1–1:

Definitionen von Softwarearchitektur verstehen

■

LZ 1–2:

Ziele und Nutzen von Softwarearchitektur verstehen und erläutern

■

LZ 1–3:

Langfristige Auswirkungen von Softwarearchitektur kennen

■

LZ 1–4:

Aufgaben und Verantwortung von Softwarearchitekt:innen verstehen

■

LZ 1–5:

Abgrenzung zu anderen Architekturdomänen

■

LZ 1–6:

Rolle von Softwarearchitekt:innen mit anderen Stakeholdern in Beziehung setzen

1

2.2 Softwareintensive Systeme und Softwarearchitekturen

Eine Softwarearchitektur manifestiert sich stets in dem zugehörigen System unabhängig davon, ob sie explizit entworfen wurde oder irgendwie gewachsen ist. Deshalb müssen wir zuerst ein klares Verständnis dafür entwickeln, was denn ein softwareintensives System überhaupt ist, bevor wir uns einer tiefer gehenden Betrachtung der Softwarearchitektur derartiger Systeme zuwenden können. Dazu werden wir in den folgenden Abschnitten zuerst den Begriff des softwareintensiven Systems präzisieren und dabei auch die unterschiedlichen Arten von softwareintensiven Systemen diskutieren. Auf dieser Basis können wir letztlich den Bezug zur Softwarearchitektur der betrachteten Systeme herstellen.

2.2.1 Was ist ein softwareintensives System?

Hier stellt sich zuerst die grundlegende Frage: Was ist überhaupt ein System? Eine Antwort auf diese Frage finden wir im IEEE-Standard 610.12-1990, dem »IEEE Standard Glossary of Software Engineering Terminology«. Dort ist ein System wie folgt definiert:

»system. A collection of components organized to accomplish a specific function or set of functions.«

([IEEE 610.12-1990], Seite 73)

Das charakterisiert recht treffend die wesentlichen Eigenschaften eines Systems, die auch intuitiv so zu erwarten sind. Ein System besteht aus Bausteinen bzw. Komponenten, wie z. B. Hardware-, Software- oder mechanischen Bausteinen. Bereits in diesem Systembegriff findet sich die Vorstellung wieder, dass Systeme in Bausteine zerlegt werden können. Darüber hinaus soll entsprechend der Definition ein System einem bestimmten Zweck dienen. Dies spiegelt das Grundverständnis des Ingenieurwesens wider, für den Menschen nutzbringende Dinge zu erschaffen (siehe NSPE Code of Ethics for Engineers [NSPE]).