Dieses Mapping von iSAQB Lernzielen zu Buchkapiteln bezieht sich auf die 10. Auflage des Buches.
- In früheren Auflagen fand sich dieses Mapping als Teil des Buches selbst (Kapitel 14).
- Es sind lediglich die R1 und R2 Lernziele enthalten, da R3 nicht prüfungsrelevant ist.
- Bei der eigenständigen Vorbereitung (ohne Besuch einer Schulung) lohnt es, das iSAQB Glossar zu berücksichtigen - das erklärt wesentliche Begriffe im iSAQB-Sinne.
iSAQB Curriculum 2023
Diese Version des iSAQB Foundation-Lehrplans finden Sie hier.
Lehrplan Kapitel 1: Grundbegriffe
LZ 1-1: Definitionen von Softwarearchitektur (R1)
Hier geht es wesentlich um die wesentlichen Gemeinsamkeiten der (vielen möglichen) Definitionen.
| Buchkapitel | Seite |
|---|---|
| 2.1 Was ist Softwarearchitektur? | 14-18 |
LZ 1-2: Nutzen und Ziele von Softwarearchitektur (R1)
| Buchkapitel | Seite |
|---|---|
| 2 Darum Softwarearchitektur | 13 ff. |
LZ 1-4: Aufgaben und Verantwortung von Softwarearchitekt:innen (R1)
Sicher eines der (praktisch und methodisch) wichtigsten Themen.
| Buchkapitel | Seite |
|---|---|
| 2.3 Die Aufgaben von Softwarearchitekt:innen | 22-25 |
LZ 1-5: Rolle von Softwarearchitekt:innen in Beziehung zu anderen Stakeholdern (R1)
Dieser Lernziel wird hauptsächlich in Abschnitt 2.4 behandelt, der verschiedene Modelle der Rolle von Softwarearchitekten im Verhältnis zu anderen Teammitgliedern und Stakeholdern diskutiert.
| Buchkapitel | Seite |
|---|---|
| 2.4 Rolle von Softwarearchitekt:innen: Wer macht’s? | 26-32 |
LZ 1-6: Zusammenhang zwischen Entwicklungsvorgehen und Softwarearchitektur (R2)
Dieser Abschnitt behandelt zwar nicht direkt den Zusammenhang zwischen Entwicklungsvorgehen und Softwarearchitektur, aber er spricht das iterative Vorgehen in der Architekturentwicklung an.
| Buchkapitel | Seite |
|---|---|
| 2.5 Architekturen entstehen (meist) iterativ | 32-33 |
LZ 1-7: Kurz- und langfristige Ziele (R2)
Die folgenden Abschnitte behandeln Aspekte, die sich auf kurz- und langfristige Ziele in der Softwarearchitektur beziehen. Insbesondere kommt die Balance zwischen kurzfristigen Anforderungen und langfristigen Qualitätszielen zur Sprache.
| Buchkapitel | Seite |
|---|---|
| 2.2 Architekturentscheidungen | 19-21 |
| 2.3 Die Aufgaben von Softwarearchitekt:innen | 22-25 |
| 3.5 Qualitätsanforderungen klären | 39-43 |
LZ 1-8: Explizite versus impliziten Aussagen (R1):
Die folgenden Abschnitte betonen die Bedeutung von expliziten Aussagen in der Softwarearchitektur. Sie erklären, wie man implizite Annahmen vermeidet. Besonders in der Dokumentation und Kommunikation von Architekturentscheidungen wird auf die Wichtigkeit expliziter Formulierungen eingegangen.
| Buchkapitel | Seite |
|---|---|
| 2.1 Was ist Softwarearchitektur? | 14-18 |
| 2.2 Architekturentscheidungen | 19-21 |
| 5.3 Effektiv dokumentieren | 129-137 |
| 5.4 Bestandteile von Architekturdokumentation | 138-149 |
Lehrplan Kapitel 2: Entwurf und Entwicklung von Softwarearchitekturen
LZ 2-1: Vorgehen und Heuristiken zur Architekturentwicklung (R1,R3)
Diese Abschnitte behandeln verschiedene Vorgehensweisen und Heuristiken zur Entwicklung von Softwarearchitekturen, einschließlich grundlegender Prinzipien, spezifischer Entwurfsmethoden und Architekturmuster.
| Buchkapitel | Seite |
|---|---|
| 4.1 Grundlagen, Prinzipien und Heuristiken | 48-65 |
| 4.2 Entwurfsmethoden | 66-84 |
| 4.2.1 Domain-Driven Design (Entwurf nach Fachlichkeit) | 67-71 |
| 4.2.2 Quality-Driven Software Architecture | 72-77 |
| 4.2.3 Top-down und Bottom-up | 79-80 |
| 4.2.4 Sichtenbasierter Entwurf | 80-84 |
LZ 2-2: Softwarearchitekturen entwerfen (R1)
Hier gibt es viel Überschneidung zu Lernziel 2-1 (s.o.).
| Buchkapitel | Seite |
|---|---|
| 4.2 Entwurfsmethoden | 66-84 |
| 4.2.1 Domain-Driven Design (Entwurf nach Fachlichkeit) | 67-71 |
| 4.2.2 Quality-Driven Software Architecture | 72-77 |
| 4.2.3 Top-down und Bottom-up | 79-80 |
| 4.2.4 Sichtenbasierter Entwurf | 80-84 |
LZ 2-3: Anforderungen klären (R1-R3)
Die folgenden Abschnitte behandeln verschiedene Aspekte der Anforderungsklärung, von der Identifikation der Kernaufgaben über die Ermittlung von Stakeholdern bis hin zur Klärung von Qualitätsanforderungen und Randbedingungen. Zusätzlich thematisieren die Abschnitte 2.3 und 4.2.1 die Rolle des Architekten bei der Anforderungsklärung und die Bedeutung der Fachdomäne für die Anforderungsanalyse, wobei Domain-Driven-Design keine Relevanz für die Prüfung besitzt.
| Buchkapitel | Seite |
|---|---|
| 2.3.1 Anforderungen klären (als Aufgabe) | 23 |
| 3. Anforderungen klären (mit Unterabschnitten 3.1 bis 3.7) | 35-46 |
| 3.1 Was ist Kernaufgabe oder Ziel des Systems? | 35-36 |
| 3.2 Relevante Stakeholder ermitteln | 36-37 |
| 3.3 Welche Kategorie von System? | 37-38 |
| 3.4 Fachdomäne klären | 38-39 |
| 3.5 Qualitätsanforderungen klären | 39-43 |
| 3.6 Externe Nachbarsysteme: Kontextabgrenzung | 44-45 |
| 3.7 Einflussfaktoren und Randbedingungen ermitteln | 45-46 |
LZ 2-4: Querschnittskonzepte entwerfen (R1)
Wichtig für die Prüfung ist die begriffliche Trennung von “Strukturen” und “Querschnittlichen Konzepten”.
Die vielen Konzepte aus Buchkapitel 7 besitzen KEINE Prüfungsrelevanz (wohl aber praktische!).
Die folgenden Abschnitte behandeln verschiedene Aspekte von Querschnittskonzepten, von der grundlegenden Definition bis hin zu detaillierten Beschreibungen spezifischer technischer Konzepte.
| Buchkapitel | Seite |
|---|---|
| 2.1.6 Prinzipien (synonym: Konzepte) | 17-18 |
| 4.1.2 Prinzipien | 49-62 |
| 5.4.6 Querschnittliche Konzepte | 146-148 |
LZ 2-5: Wichtige Lösungsmuster (R1, R3)
Von der Vielzahl möglicher Patterns (Architektur- und Designpatterns) gehören nur relativ wenige zu den prüfungsrelevanten Kandidaten.
| Buchkapitel | Seite |
|---|---|
| 4.4.1 Schichten (Layer) | 88-90 |
| 4.4.2 Ports-und-Adapter | 91-94 |
| 4.4.4 Microservices | 94-102 |
| 4.4.5 Pipes und Filter | 102-104 |
| 4.4.13 Model-View-Controller | 114-116 |
| 4.4.16 Adapter | 120 |
| 4.4.17 Stellvertreter (Proxy) | 120-121 |
| 4.4.18 Fassade | 121-122 |
| 4.4.10 Broker | 109-110 |
LZ 2-6: Entwurfsprinzipien (R1-R3)
Die folgenden Abschnitte behandeln umfassend verschiedene Entwurfsprinzipien, von grundlegenden Konzepten bis hin zu spezifischen Prinzipien wie SOLID. Viele dieser Prinzipien sind überdeckend und begrifflich oftmals unscharf oder in der Literatur sogar unterschiedlich beschrieben.
| Buchkapitel | Seite |
|---|---|
| 4.1 Grundlagen, Prinzipien und Heuristiken (und Unterabschnitte) | 48-65 |
| 4.1.2.1 Lose (geringe) Kopplung | 51-53 |
| 4.1.2.2 Hohe Kohäsion | 53-54 |
| 4.1.2.3 Trenne Verantwortlichkeiten/Belange | 54-55 |
| 4.1.2.4 Modularisierung | 55 |
| 4.1.2.5 Abstraktion, Kapselung und das Geheimnisprinzip | 55 |
| 4.1.2.6 Hohe Konsistenz | 55-56 |
| 4.1.2.7 Keine zyklischen Abhängigkeiten | 56-57 |
| 4.1.2.8 SOLID-Prinzipien des objektorientierten Entwurfs | 57-62 |
LZ 2-7: Abhängigkeiten von Bausteinen (R1)
Die folgenden Abschnitte behandeln verschiedene Aspekte von Abhängigkeiten zwischen Bausteinen, einschließlich verschiedener Arten von Kopplung, Beziehungen und Strategien zum Management von Abhängigkeiten. Sie bieten sowohl methodische Grundlagen als auch praktische Ansätze zur Handhabung von Abhängigkeiten in der Softwarearchitektur.
| Buchkapitel | Seite |
|---|---|
| 2.1.3 Beziehungen | 15 |
| 4.1.2.1 Lose (geringe) Kopplung | 51-53 |
| 4.1.2.7 Keine zyklischen Abhängigkeiten | 56-57 |
| 4.2.7 Abhängigkeiten von Bausteinen managen | 65 |
| 5.4.2 Bausteinsicht: Code-im-Großen | 140-142 |
LZ 2-8: Qualitätsanforderungen erreichen (R1)
Die folgenden Abschnitte behandeln verschiedene Aspekte des Erreichens von Qualitätsanforderungen in der Softwarearchitektur. Sie reichen von der Klärung der Anforderungen über spezifische Ansätze zur Erreichung von Qualitätszielen bis hin zu Methoden zur Bewertung und Messung der erreichten Qualität.
| Buchkapitel | Seite |
|---|---|
| 3.5 Qualitätsanforderungen klären | 39-43 |
| 4.2.2 Quality-Driven Software Architecture | 72-77 |
| 4.2.8 Qualitätsanforderungen mit passenden Ansätzen und Techniken erreichen | 65-66 |
| 6.1 Qualitative Architekturbewertung | 172-178 |
LZ 2-9: Schnittstellen entwerfen (R1-R3)
Diese Abschnitte behandeln verschiedene Aspekte des Schnittstellenentwurfs, von grundlegenden Konzepten über spezifische Entwurfstechniken bis hin zur Dokumentation und Modellierung von Schnittstellen. Sie bieten sowohl theoretische Grundlagen als auch praktische Tipps für den Entwurf effektiver und robuster Schnittstellen in der Softwarearchitektur.
| Buchkapitel | Seite |
|---|---|
| 2.1.3 Beziehungen | 15 |
| 4.3 Schnittstellen entwerfen | 84-88 |
| 4.3.1 Anforderungen an Schnittstellen | 86 |
| 4.3.3 Tipps zum Entwurf von Schnittstellen | 87-88 |
| 5.4.3 Schnittstellen: Die Brücken zwischen Welten | 143-144 |
| 5.6.1 UML Kurzeinführung (Abschnitt zu Schnittstellen) | 157 |
Lehrplan Kapitel 3: Beschreibung und Kommunikation
LZ 3-1: Anforderungen an technische Dokumentation (R1)
Die folgenden Abschnitte behandeln umfassend die Anforderungen an technische Dokumentation in der Softwarearchitektur. Sie decken sowohl allgemeine Prinzipien der effektiven Dokumentation als auch spezifische Techniken und Formate ab. Die detaillierte Struktur des arc42-Templates sowie des arc42 Canvas sind nicht prüfungsrelevant.
| Buchkapitel | Seite |
|---|---|
| 5.2 Anforderungen an Architekturdokumentation | 128-129 |
| 5.3.1 Tipps für bessere Architekturdiagramme | 131-137 |
LZ 3-2: Softwarearchitekturen beschreiben und kommunizieren (R1-R3)
Die folgenden Abschnitte decken umfassend die Beschreibung und Kommunikation von Softwarearchitekturen ab. Sie behandeln verschiedene Aspekte der Architekturdokumentation, von der Begründung für die Dokumentation über effektive Dokumentationstechniken bis hin zu spezifischen Sichten und Notationen zur Beschreibung von Architekturen.
| Buchkapitel | Seite |
|---|---|
| 5.1 Warum kommunizieren und dokumentieren | 126-127 |
| 5.3 Effektiv dokumentieren | 129-137 |
| 5.3.1 Tipps für bessere Architekturdiagramme | 131-137 |
| 5.4 Bestandteile von Architekturdokumentation (und Unterabschnitte) | 138-149 |
| 5.4.1 Kontextabgrenzung: Vogelperspektive | 138-140 |
| 5.4.2 Bausteinsicht: Code-im-Großen | 140-142 |
| 5.4.3 Schnittstellen: Die Brücken zwischen Welten | 143-144 |
| 5.4.4 Laufzeitsicht: Was geschieht wann? | 144-145 |
| 5.4.5 Verteilungssicht: Zusammenhang zur technischen Infrastruktur | 145-146 |
| 5.4.6 Querschnittliche Konzepte | 146-148 |
| 5.4.7 Entscheidungen | 148-150 |
| 5.6 Notationen zur Modellierung: UML, C4 und andere | 154-165 |
LZ 3-3: Notations-/Modellierungsmittel für Beschreibung von Softwarearchitektur (R2-R3)
Die folgenden Abschnitte behandeln verschiedene Notations- und Modellierungsmittel zur Beschreibung von Softwarearchitekturen. UML ist teilweise prüfungsrelevant, C4 allerdings nicht.
| Buchkapitel | Seite |
|---|---|
| 5.6 Notationen zur Modellierung: UML, C4 und andere | 154-165 |
| 5.6.1 UML Kurzeinführung | 155-159 |
LZ 3-4: Architektursichten (R1)
Dokumentation von Architektursichten, insbesondere Kontext-, Baustein-, Laufzeit- und Verteilungssicht.
| Buchkapitel | Seite |
|---|---|
| 5.4.1 Kontextabgrenzung: Vogelperspektive | 138-140 |
| 5.4.2 Bausteinsicht: Code-im-Großen | 140-142 |
| 5.4.4 Laufzeitsicht: Was geschieht wann? | 144-145 |
| 5.4.5 Verteilungssicht: Zusammenhang zur technischen Infrastruktur | 145-146 |
LZ 3-5: Kontextabgrenzung (R1)
| Buchkapitel | Seite |
|---|---|
| 5.4.1 Kontextabgrenzung: Vogelperspektive | 138-140 |
| 3.6 Externe Nachbarsysteme: Kontextabgrenzung | 44-45 |
LZ 3-6: Querschnittskonzepte (R2)
Hier geht es um die Dokumentation der Querschnittskonzepte. Nut eingeschränkt prüfungsrelevant.
| Buchkapitel | Seite |
|---|---|
| 5.4.6 Querschnittliche Konzepte | 146-148 |
LZ 3-7: Schnittstellen (R1)
Hier geht es um die Dokumentation von Schnittstellen (auch mit UML).
| Buchkapitel | Seite |
|---|---|
| 5.4.2 Bausteinsicht: Code-im-Großen | 140-142 |
| 5.4.3 Schnittstellen: Die Brücken zwischen Welten | 143-144 |
| 4.3 Schnittstellen entwerfen | 84-88 |
LZ 3-8: Architekturentscheidungen (R1-R2)
Diese Abschnitte behandeln Architekturentscheidungen und Architecture Decision Records (ADRs). Sie bieten Einblicke in die Bedeutung von Architekturentscheidungen, wie man diese dokumentiert und kommuniziert.
Aufbau und Verwendung von ADRs sind nicht prüfungsrelevant.
| Buchkapitel | Seite |
|---|---|
| 2.2 Architekturentscheidungen | 19-21 |
| 5.4.7 Entscheidungen | 148-150 |
Lehrplan Kapitel 4: Architektur und Qualität
LZ 4-1: Qualitätsmodelle und Qualitätsmerkmale (R1)
Diese Abschnitte behandeln umfassend Qualitätsmodelle und Qualitätsmerkmale. Sie bieten Einblicke in verschiedene Qualitätsmodelle, einschließlich des ISO/IEC 25010 Standards sowie Q42 (nicht prüfungsrelevant), und erklären, wie man Qualitätsanforderungen identifiziert, formuliert und in der Softwarearchitektur berücksichtigt.
| Buchkapitel | Seite |
|---|---|
| 3.5 Qualitätsanforderungen klären | 39-43 |
| 4.2.2 Quality-Driven Software Architecture | 72-77 |
LZ 4-2: Qualitätsanforderungen an Softwarearchitekturen (R1)
Hier geht es um Qualitätsanforderungen. Das hatten wir bei der Anforderungsklärung (siehe oben) auch schon - aber doppelt hält besser.
| Buchkapitel | Seite |
|---|---|
| 3.5 Qualitätsanforderungen klären | 39-43 |
LZ 4-3: Softwarearchitekturen qualitativ analysieren (R2-R3)
Die konkreten Details der Methode ATAM sind nicht prüfungsrelevant. In den Abschnitten über “Quality-Driven Software Architecture” haben Sie die meisten der für die Analyse wichtigen Begriffe bereits gelesen. In jedem Fall müssen Sie vor einer qualitativen Analyse die konkreten Qualitätsanforderungen (siehe LZ-4-2) geklärt haben.
| Buchkapitel | Seite |
|---|---|
| 3.5 Qualitätsanforderungen klären | 39-43 |
| 6.1 Qualitative Architekturbewertung | 172-178 |
LZ 4-4: Softwarearchitekturen quantitativ bewerten (R2)
Zum bewerten über Zahlen (“Metriken”) gibt es auch ein paar Infos:
| Buchkapitel | Seite |
|---|---|
| 6.2 Quantitative Bewertung durch Metriken | 179-181 ] |
Beispiele von Softwarearchitekturen
Keine prüfungsrelevanten Lernziele.
iSAQB Curriculum 2025 (to be released April 1st 2025)
t.b.d.