E-Book
7 Tage kostenlos im Abo
E-Book
34,90 €

Basiswissen für Softwarearchitekten E-Book

Mahbouba Gharbi

0,0

Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.

Herausgeber: dpunkt.verlag
Kategorie: Wissenschaft und neue Technologien
Serie: Basiswissen
Sprache: Deutsch
Veröffentlichungsjahr: 2023

Beschreibung

Grundlagenwissen nicht nur für Softwarearchitekt*innen ... - Techniken und Methoden für Entwurf, Dokumentation und Qualitätssicherung - Mit praxisnahen Beispielen, Prüfungsaufgaben und Glossar - Aktuell zum iSAQB-Lehrplan Version 2023.1Softwarearchitektur bildet einen wesentlichen Erfolgsfaktor für Softwareprojekte. 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. "Basiswissen für Softwarearchitekten" vermittelt das notwendige Wissen und Fähigkeiten, um eine dem Problem angemessene Softwarearchitektur für Systeme zu entwerfen. Es behandelt die wichtigen Begriffe und Konzepte der Softwarearchitektur sowie deren Bezug zu anderen Disziplinen. Darauf aufbauend werden die grundlegenden Techniken und Methoden für den Entwurf, die Dokumentation und die Qualitätssicherung von Softwarearchitekturen beschrieben. Ausführlich behandelt werden zudem die Rolle, die Aufgaben, das Umfeld und die Arbeitsumgebung des Softwarearchitekten, ebenso dessen Einbettung in die umfassende Organisations- und Projektstruktur. Das Buch orientiert sich am Lehrplan zum "Certified Professional for Software Architecture – Foundation Level" (CPSA-F) des International Software Architecture Qualification Board (iSAQB). Die 5. Auflage bietet eine Aktualisierung auf Basis des CPSA-F-Lehrplans in der Version 2023.1.

Details

Sie lesen das E-Book in den Legimi-Apps auf:

Android

iOS

von Legimi
zertifizierten E-Readern

Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 253

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android

iOS

Bewertungen

0,0

Rezensionen(0 Rezensionen)

Leseprobe

Mahbouba Gharbi ist Geschäftsführerin und Chef-Architektin bei ITech Progress GmbH und iSAQB-Vorstandsvorsitzende, ist bekennender Softwarearchitektur-Fan, Autorin zahlreicher Fachartikel und häufige Sprecherin auf internationalen Konferenzen.

Prof. Dr. Arne Koschel ist Dozent an der Hochschule Hannover mit dem Schwerpunkt verteilte (Informations-)Systeme. Er hat langjährige industrielle Praxis in Entwicklung und Architektur verteilter Informationssysteme. Nebenberuflich berät und referiert er zu Themen wie SOA, Integration, Middleware, EDA und Cloud Computing. Er ist Active Board Member im iSAQB.

Prof. Dr. Andreas Rausch leitet den Lehrstuhl für Software Systems Engineering an der Technischen Universität Clausthal. Er war und ist in der industriellen Praxis als Berater und leitender Softwarearchitekt bei einer Reihe von großen verteilten Softwaresystemen tätig.

Dr. Gernot Starke, innoQ Fellow, arbeitet als Berater für methodische Softwarearchitektur, Technologiemanagement und Projektorganisation. Seit mehr als 15 Jahren gestaltet er die Architektur von Softwaresystemen unterschiedlicher Größe.

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

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

5., überarbeitete und aktualisierte Auflage

Mahbouba Gharbi

Arne Koschel

Andreas Rausch

Gernot Starke

Lektorat: Christa Preisendanz

Lektoratsassistenz: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

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

ISBN:

Print 978-3-86490-984-9

PDF 978-3-98890-072-2

ePub 978-3-98890-073-9

mobi 978-3-98890-074-6

5., überarbeitete und aktualisierte Auflage 2023

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde mit mineralölfreien Farben auf FSC®-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie. Hergestellt in Deutschland.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor*innen noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 5. 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.

Softwarearchitektinnen und 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 Softwarearchitektinnen und Softwarearchitekten fest.

Die 5. Auflage unseres Buches bietet eine Aktualisierung auf Basis des neuen CPSA-F-Lehrplans in der Version 2023.1RC-2 vom April 2023. Mit dem neuen Lehrplan wird diese Auflage insbesondere im Bereich der Prinzipien und Heuristiken verstärkt und Themen wie Randbedingungen und Einflussfaktoren in der Softwarearchitektur werden vertieft. Auch die »Architecture Decision Records« erhalten als etablierter Standard einen eigenen Platz.

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« hervorgehoben. 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 aufzeigen. 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 Softwarearchitektinnen und 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 StarkeLudwigshafen, Hannover, Clausthal-Zellerfeld, Köln, im April 2023

Inhaltsübersicht

1Einleitung

1.1Softwarearchitektur als Disziplin im Software Engineering

1.2iSAQB – International Software Architecture Qualification Board

1.3Certified Professional for Software Architecture – Foundation und Advanced Level

1.4Zielsetzung des Buches

1.5Voraussetzungen

1.6Leitfaden für den Leser

1.7Zielpublikum

1.8Danksagungen

2Grundlagen von Softwarearchitekturen

2.1Einbettung in den iSAQB-Lehrplan

2.2Softwareintensive Systeme und Softwarearchitekturen

2.3Grundlegende Konzepte von Softwarearchitekturen

2.4Der Softwarearchitekturentwurf aus der Vogelperspektive

2.5Lernkontrolle

3Entwurf von Softwarearchitekturen

3.1Einbettung in den iSAQB-Lehrplan

3.2Überblick über das Vorgehen beim Architekturentwurf

3.3Arbeit mit Randbedingungen und äußeren Einflussfaktoren

3.4Entwurfsprinzipien und Heuristiken

3.5Architekturzentrierte Entwicklungsansätze

3.6Techniken für einen guten Entwurf

3.7Architekturmuster

3.8EXKURS: Entwurfsmuster

3.9Deployment und Betrieb

3.10Lernkontrolle

4Beschreibung und Kommunikation von Softwarearchitekturen

4.1Einbettung in den iSAQB-Lehrplan

4.2Das CoCoME-Beispiel

4.3Sichten und Schablonen

4.4Technische oder querschnittliche Konzepte in Softwarearchitekturen

4.5Architektur und Implementierung

4.6Übliche Dokumenttypen für Softwarearchitekturen

4.7Praxisregeln zur Dokumentation

4.8Beispiele weiterer Architektur-Frameworks

4.9Lernkontrolle

5Softwarearchitekturen und Qualität

5.1Einbettung in den iSAQB-Lehrplan

5.2Bewertung von Softwarearchitekturen

5.3EXKURS: Prototyp und technischer Durchstich

5.4Architekturanalyse

5.5Lernkontrolle

6EXKURS: Werkzeuge für Softwarearchitektinnen

6.1Allgemeine Hinweise zu Werkzeugen

6.2Werkzeuge zum Anforderungsmanagement

6.3Werkzeuge zur Modellierung

6.4Werkzeuge zur statischen Codeanalyse

6.5Werkzeuge zur dynamischen Analyse

6.6Werkzeuge zum Konfigurations- und Versionsmanagement

6.7Werkzeuge zum Codemanagement

6.8Werkzeuge zum Test

6.9Werkzeuge zur Dokumentation

Anhang

ABeispielfragen

A.1Auszüge aus der Prüfungsordnung

A.2Beispielfragen

BAbkürzungsverzeichnis

CGlossar

DLiteraturverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

1.1Softwarearchitektur als Disziplin im Software Engineering

1.2iSAQB – International Software Architecture Qualification Board

1.3Certified Professional for Software Architecture – Foundation und Advanced Level

1.4Zielsetzung des Buches

1.5Voraussetzungen

1.6Leitfaden für den Leser

1.7Zielpublikum

1.8Danksagungen

2Grundlagen von Softwarearchitekturen

2.1Einbettung in den iSAQB-Lehrplan

2.1.1Lernziele

2.2Softwareintensive Systeme und Softwarearchitekturen

2.2.1Was ist ein softwareintensives System?

2.2.2EXKURS: Ausprägungen von softwareintensiven Systemen

2.2.3Bedeutung der Softwarearchitektur für ein softwareintensives System

2.3Grundlegende Konzepte von Softwarearchitekturen

2.3.1Was ist eine Softwarearchitektur?

2.3.2Bausteine, Schnittstellen und Konfigurationen

2.3.3Konzepte der Beschreibung von Softwarearchitekturen

2.3.4Architekturbeschreibung und Architekturebenen

2.3.5Wechselwirkungen zwischen Softwarearchitektur und Umgebung

2.3.6Qualität und Nutzen der Softwarearchitektur

2.4Der Softwarearchitekturentwurf aus der Vogelperspektive

2.4.1Ziele und Aufgaben des Softwarearchitekturentwurfs

2.4.2Der Softwarearchitekturentwurf im Überblick

2.4.3Wechselspiel der Tätigkeiten und Abstraktionsstufen im Entwurf

2.4.4EXKURS: Aufgaben der Softwarearchitektin und Bezug zu anderen Rollen

2.5Lernkontrolle

3Entwurf von Softwarearchitekturen

3.1Einbettung in den iSAQB-Lehrplan

3.1.1Lernziele

3.2Überblick über das Vorgehen beim Architekturentwurf

3.3Arbeit mit Randbedingungen und äußeren Einflussfaktoren

3.3.1Arten von Einflussfaktoren

3.4Entwurfsprinzipien und Heuristiken

3.4.1Top-down und bottom-up

3.4.2Hierarchische (De-)Komposition

3.4.2.1Divide et impera

3.4.2.2Prinzipien bei der Zerlegung

3.4.2.3So-einfach-wie-möglich-Prinzip

3.4.2.4Trennung von Verantwortlichkeiten

3.4.3Konzeptionelle Integrität

3.4.4Erwarte Fehler

3.4.4.1Postels’ Law

3.4.5Schmale Schnittstellen und Information Hiding

3.4.5.1Information Hiding

3.4.5.2Verwendung von Schnittstellen

3.4.6Regelmäßiges Refactoring und Redesign

3.5Architekturzentrierte Entwicklungsansätze

3.5.1EXKURS: Domain-Driven Design

3.5.1.1Fachmodelle als Basis

3.5.1.2Systematische Verwaltung der Domänenobjekte

3.5.1.3Strukturierung der Fachdomäne

3.5.1.4Arten von Domänen

3.5.1.5Integration von Domänen

3.5.2EXKURS: Globale Analyse

3.5.3EXKURS: Evolutionäre Architektur

3.5.3.1Prinzipien

3.5.3.2Fitnessfunktionen

3.5.4EXKURS: Modellgetriebene Architektur

3.5.5Referenzarchitekturen

3.5.5.1Generative Erzeugung von Systembausteinen

3.5.5.2Aspektorientierung

3.5.5.3Objektorientierung

3.5.5.4Prozedurale Ansätze

3.6Techniken für einen guten Entwurf

3.6.1Ausgangssituation und Motivation: degeneriertes Design

3.6.2Lose Kopplung

3.6.3Hohe Kohäsion

3.6.4Single-Responsibility-Prinzip

3.6.5Offen-geschlossen-Prinzip

3.6.6Umkehr der Abhängigkeiten

3.6.7Abtrennung von Schnittstellen

3.6.8Zyklische Abhängigkeiten auflösen

3.6.9Liskov’sches Substitutionsprinzip

3.7Architekturmuster

3.7.1Adaptierbare Systeme

3.7.1.1Dependency Injection

3.7.2Interaktive Systeme

3.7.2.1Model View Controller

3.7.2.2Model View Presenter

3.7.2.3Presentation Abstraction Control

3.7.3Vom Chaos zur Struktur

3.7.3.1Schichtenarchitektur

3.7.3.2Pipes and Filters

3.7.3.3Blackboard

3.7.4Verteilte Systeme

3.7.4.1Herausforderungen verteilter Systeme

3.7.4.2Broker

3.7.4.3EXKURS: Serviceorientierung

3.7.4.4Modularisierung

3.7.4.5Microservices

3.8EXKURS: Entwurfsmuster

3.8.1Adapter

3.8.2Observer

3.8.3Decorator

3.8.4Proxy

3.8.5Fassade

3.8.6Brücke

3.8.7State

3.8.8Mediator

3.8.9Fabrik

3.8.10Interpreter

3.8.11Plug-in

3.8.12Kombinator

3.9Deployment und Betrieb

3.9.1Deployment

3.9.2Betrieb

3.9.3EXKURS: DevOps

3.10Lernkontrolle

4Beschreibung und Kommunikation von Softwarearchitekturen

4.1Einbettung in den iSAQB-Lehrplan

4.1.1Lernziele

4.2Das CoCoME-Beispiel

4.2.1Anwendungsfälle im CoCoME-System

4.2.2Übersicht über den strukturellen Aufbau des CoCoME-Systems

4.3Sichten und Schablonen

4.3.1Bewährte Sichten nach iSAQB

4.3.2UML-Diagramme als Notationsmittel in Sichtenbeschreibungen

4.3.3Sichtenbeschreibung – Grobaufbau und Einführungsbeispiel

4.3.3.1Grobaufbau – schablonenartige Sichtenbeschreibung

4.3.3.2Beispiel: Auszug aus einer Sichtenbeschreibung für eine Bausteinsicht

4.3.4Kontextsicht oder Kontextabgrenzung

4.3.5Bausteinsicht

4.3.6Laufzeitsicht

4.3.7Verteilungssicht bzw. Infrastruktursicht

4.3.8Wechselwirkungen zwischen Architektursichten

4.3.9Hierarchische Verfeinerung von Architektursichten

4.4Technische oder querschnittliche Konzepte in Softwarearchitekturen

4.4.1Technische bzw. querschnittliche Konzepte: Beispieldimensionen

4.4.2Beispiel: Fehlerbehandlung

4.4.3Beispiel: Sicherheit

4.5Architektur und Implementierung

4.5.1Beispiel: Implementierung

4.6Übliche Dokumenttypen für Softwarearchitekturen

4.6.1Zentrale Architekturbeschreibung

4.6.2Architekturüberblick

4.6.3Dokumentübersicht

4.6.4Übersichtspräsentation

4.6.5»Architekturtapete«

4.6.6Handbuch zur Dokumentation

4.6.7Architecture Decision Record

4.6.8Technische Informationen

4.6.9Dokumentation von externen Schnittstellen

4.6.10Template

4.7Praxisregeln zur Dokumentation

4.7.1Regel 1: »Schreiben aus der Sicht der Leserin«

4.7.2Regel 2: »Unnötige Wiederholung vermeiden«

4.7.3Regel 3: »Mehrdeutigkeit vermeiden«

4.7.4Regel 4: »Standardisierte Organisationsstruktur bzw. Schablonen«

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

4.7.6Regel 6: »Überprüfung auf Gebrauchstauglichkeit«

4.7.7Regel 7: »Übersichtliche Diagramme«

4.7.8Regel 8: »Regelmäßige Aktualisierungen«

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

4.8Beispiele weiterer Architektur-Frameworks

4.8.14+1-Framework

4.8.2SAGA

4.9Lernkontrolle

5Softwarearchitekturen und Qualität

5.1Einbettung in den iSAQB-Lehrplan

5.1.1Lernziele

5.2Bewertung von Softwarearchitekturen

5.2.1Qualitative Bewertung

5.2.1.1DIN ISO/IEC 25010

5.2.1.2Qualitätsmerkmale

5.2.1.3Weitere Qualitätsmerkmale

5.2.1.4Auswirkungen bestimmter Qualitätsmerkmale

5.2.1.5Taktiken und Praktiken

5.2.2Quantitative Bewertung

5.2.2.1Überprüfung von Architekturregeln

5.2.2.2Metriken

5.2.2.3Zyklomatische Komplexität

5.2.2.4Goodharts Gesetz

5.3EXKURS: Prototyp und technischer Durchstich

5.3.1Technischer Durchstich

5.3.2Prototyp

5.3.2.1Einsatz von Softwareprototypen

5.3.2.2Arten von Softwareprototypen

5.4Architekturanalyse

5.4.1EXKURS: ATAM-Methode

5.4.1.1Vorgehen bei der Bewertung

5.5Lernkontrolle

6EXKURS: Werkzeuge für Softwarearchitektinnen

6.1Allgemeine Hinweise zu Werkzeugen

6.1.1Kosten von Werkzeugen

6.1.2Lizenzen und Lizenzbedingungen

6.2Werkzeuge zum Anforderungsmanagement

6.2.1Anforderungen und Entscheidungskriterien

6.2.2Herausforderungen von Werkzeugen für das Anforderungsmanagement

6.2.3Beispielhafte Vertreter

6.3Werkzeuge zur Modellierung

6.3.1Anforderungen und Entscheidungskriterien

6.3.2Herausforderungen von Werkzeugen für die Modellierung

6.3.3Beispielhafte Vertreter

6.4Werkzeuge zur statischen Codeanalyse

6.4.1Anforderungen und Entscheidungskriterien

6.4.2Herausforderungen von Werkzeugen zur statischen Codeanalyse

6.4.3Beispielhafte Vertreter

6.5Werkzeuge zur dynamischen Analyse

6.5.1Anforderungen und Entscheidungskriterien

6.5.2Herausforderungen von Werkzeugen zur dynamischen Analyse

6.5.3Beispielhafte Vertreter

6.6Werkzeuge zum Konfigurations- und Versionsmanagement

6.6.1Anforderungen und Entscheidungskriterien

6.6.2Herausforderungen von Werkzeugen zum Konfigurations- und Versionsmanagement

6.6.3Beispielhafte Vertreter

6.7Werkzeuge zum Codemanagement

6.7.1Herausforderungen von Werkzeugen zum Codemanagement

6.7.2Beispielhafte Vertreter

6.8Werkzeuge zum Test

6.8.1Anforderungen und Entscheidungskriterien

6.8.2Herausforderungen von Testwerkzeugen

6.8.3Beispielhafte Vertreter

6.9Werkzeuge zur Dokumentation

6.9.1Anforderungen und Entscheidungskriterien

6.9.2Herausforderungen von Dokumentationswerkzeugen

6.9.3Beispielhafte Vertreter

Anhang

ABeispielfragen

A.1Auszüge aus der Prüfungsordnung

A.2Beispielfragen

BAbkürzungsverzeichnis

CGlossar

DLiteraturverzeichnis

Index

1Einleitung

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

Abb. 1–1Veröffentlichungen zu Softwarearchitektur seit 1973 [Reu12]

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

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–2Architektur 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 außen (gegenüber dem Nutzer) wohlstrukturiert, sodass sie intuitiv nutzbar ist, als auch innen (gegenüber demjenigen, der die Software pflegen und weiterentwickeln soll) wohlstrukturiert, sodass dieser die internen Strukturen der Software leicht verstehen und damit gut seinen Aufgaben nachkommen kann.

1.2iSAQB – 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, Requirements Engineering: www.ireb.de, Projektmanagement: www.pmi.org).

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 Abb. 1–3).

Abb. 1–3iSAQB-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 Besuches 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.3Certified 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 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 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–4Struktur 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.4Zielsetzung 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 jeweils Lehrenden 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.5Voraussetzungen

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.6Leitfaden 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. [isaqb-lehrplan]:

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.

Aspekte des praktischen Entwurfs von Softwarearchitekturen behandeln wir in

Kapitel 3

. Themen sind dort Varianten des Vorgehens bei der Architekturentwicklung, wichtige Architekturmuster wie Schichten, Pipes and Filters, Model View Controller, Entwurfsprinzipien wie Kopplung, Kohäsion, Trennung von Verantwortlichkeiten u.a.m.

Inhalt des

Kapitel 4

sind ausgewählte praxisnahe Beschreibungsmittel sowie in der Praxis bewährte Richtlinien, die es Ihnen erlauben, 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.

Kapitel 5

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

Abschließend zeigen wir in

Kapitel 6

(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 – 5 gründlich durcharbeiten und ergänzende Blicke in die anderen Abschnitte werfen. Ansonsten empfiehlt es sich, zumindest das Kapitel 2 komplett zu lesen und dann die Sie besonders interessierenden Themen zu vertiefen.

1.7Zielpublikum

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.8Danksagungen

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 5. Auflage wäre ohne die unermüdliche Unterstützung von Noah Neukam und Thorsten Mayer 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 Geduld aufgebracht haben, uns gemeinsam an diesem Buch arbeiten zu lassen.

2Grundlagen 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 Softwareingenieurinnen 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. Abb. 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–1Das 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. Abb. 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.