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 2023Permalink
Diese Version des iSAQB Foundation-Lehrplans finden Sie hier.
Lehrplan Kapitel 1: GrundbegriffePermalink
LZ 1-1: Definitionen von Softwarearchitektur (R1)Permalink
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)Permalink
| Buchkapitel | Seite |
|---|---|
| 2 Darum Softwarearchitektur | 13 ff. |
LZ 1-4: Aufgaben und Verantwortung von Softwarearchitekt:innen (R1)Permalink
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)Permalink
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)Permalink
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)Permalink
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):Permalink
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 SoftwarearchitekturenPermalink
LZ 2-1: Vorgehen und Heuristiken zur Architekturentwicklung (R1,R3)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
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 KommunikationPermalink
LZ 3-1: Anforderungen an technische Dokumentation (R1)Permalink
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)Permalink
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)Permalink
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)Permalink
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)Permalink
| Buchkapitel | Seite |
|---|---|
| 5.4.1 Kontextabgrenzung: Vogelperspektive | 138-140 |
| 3.6 Externe Nachbarsysteme: Kontextabgrenzung | 44-45 |
LZ 3-6: Querschnittskonzepte (R2)Permalink
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)Permalink
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)Permalink
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ätPermalink
LZ 4-1: Qualitätsmodelle und Qualitätsmerkmale (R1)Permalink
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)Permalink
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)Permalink
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)Permalink
Zum bewerten über Zahlen (“Metriken”) gibt es auch ein paar Infos:
| Buchkapitel | Seite |
|---|---|
| 6.2 Quantitative Bewertung durch Metriken | 179-181 ] |
Beispiele von SoftwarearchitekturenPermalink
Keine prüfungsrelevanten Lernziele.
iSAQB Curriculum 2025 (to be released April 1st 2025)Permalink
t.b.d.