Certified Professional for Software Architecture (CPSA ...isaqb.org/wp-content/uploads/2013/05/isaqb-Lehrplan-foundation.pdf · iSAQB Curriculum für Foundation Level Seite 6 von

Curr iculum für

Certified Professional for

Software Architecture (CPSA)

– Foundation Level –

V e r s i o n 2 . 0 ( 1 . J u l i 2 0 0 9 )

iSAQB Curriculum für Foundation Level

Seite 2 von 23 Stand 1. Juli 2009

Inhaltsverzeichnis

M bfkibfqrkd= Q

MKN t^p=sbRjfqqbiq=bfkb=clrka^qflk=ibsbi=pèrirkd\=Q MKO difbabRrkd=abp=ibeRmi^kp=rka=bjmcleibkb=wbfqifèb=^rcqbfirkd= Q MKP a^rbRI=afa^hqfh=rka=tbfqbRb=abq^fip=^hhRbafqfbRqbR=pèrirkdbk=Q MKQ slR^rppbqwrkdbk= R MKR difbabRrkd=abR=fp^n_=ibeRmi^kjlarib= R MKS ^_dRbkwrkd= R MKT bRdûkwbkab=fkclRj^qflkbkI=_bdRfccbI=§_bRpbqwrkdbk= S MKU bfkc§eRrkd=fk=a^p=fp^n_=wbRqcfwfbRrkdpmRldR^jj= S MKV _bdRfccb=rka=hlkwbmqb= S MKNM ibRkwfbib= S

N dRrka_bdRfccb=slk=plcqt^RbJ^RèfqbhqrRbk= T

NKN _bdRfccb=rka=hlkwbmqb= T NKO ibRkwfbib= T NKP RbcbRbkwbk= V

O _bpèRbf_rkd=rka=hljjrkfh^qflk=slk=plcqt^RbJ^RèfqbhqrRbk= NM

OKN _bdRfccb=rka=hlkwbmqb= NM OKO ibRkwfbib= NM OKP RbcbRbkwbk= NN

P bkqtf`hirkd=slk=plcqt^RbJ^RèfqbhqrRbk= NO

PKN _bdRfccb=rka=hlkwbmqb= NO PKO ibRkwfbib= NO PKP RbcbRbkwbk= NQ

Q plcqt^RbJ^RèfqbhqrRbk=rka=nrîfqûq= NR

QKN _bdRfccb=rka=hlkwbmqb= NR QKO ibRkwfbib= NR QKP RbcbRbkwbk= NS

R tbRhwbrdb=c§R=plcqt^RbJ^Rèfqbhqbk= NT

RKN _bdRfccb=rka=hlkwbmqb= NT RKO ibRkwfbib= NV RKP RbcbRbkwbk= NV



S _bfpmfbib=c§R=plcqt^RbJ^RèfqbhqrRbk= OM

SKN _bdRfccb=rka=hlkwbmqb= OM SKO ibRkwfbib= OM SKP RbcbRbkwbk= OM

T nrbiibk=rka=RbcbRbkwbk=wr=plcqt^RbJ^RèfqbhqrR= ON



0 Einleitung

0.1 Was vermittelt eine Foundation Level Schulung?

Eine akkreditierte Schulung Certif ied Professional for Software Architecture – Foundation Level vermittelt den Teilnehmern: • den Begriff und die Bedeutung von Software-Architektur, • die Aufgaben und Verantwortung von Software-Architekten, • die Rolle von Software-Architekten in Projekten, • State-of-the-Art Methoden und Techniken zur Entwicklung von Software-Architekturen, sowie

folgende Fähigkeiten: • mit anderen Projektbeteiligten aus den Bereichen Anforderungsmanagement, Projektmanage-

ment, Test und Entwicklung wesentliche Software-Architekturentscheidungen abzustimmen, • Software-Architekturen auf Basis von Sichten, Architekturmustern und technischen Konzepten

zu dokumentieren und kommunizieren, • die wesentlichen Schritte beim Entwurf von Software-Architekturen zu verstehen und für kleine

und mittlere Systeme selbständig durchzuführen Die Schulung für den Foundation Level vermittelt das notwendige Wissen und die notwendigen Fä-higkeiten, um für kleine und mittlere Systeme ausgehend von einer hinreichend detailliert beschrie-bene Anforderungsspezifikation eine dem Problem angemessene Software-Architektur zu entwerfen und zu dokumentieren, die dann als Implementierungsgrundlage bzw. -vorlage genutzt werden kann. Teilnehmer erhalten das Rüstzeug, um problembezogene Entwurfsentscheidungen auf der Basis ihrer vorab erworbenen Praxiserfahrung zu treffen.

0.2 Gliederung des Lehrplans und empfohlene zeitliche Aufteilung

0.3 Dauer, Didaktik und weitere Details akkreditierter Schulungen

Die genannten Zeiten sind Empfehlungen. Die Dauer einer Schulung sollte mindestens 3 Tage betra-gen, kann aber durchaus länger sein. Anbieter können sich durch Dauer, Didaktik, Art- und Aufbau der Übungen sowie der detaillierten Kursgliederung voneinander unterscheiden. Insbesondere die Art (fachliche und technische Domänen) der Beispiele und Übungen lässt der Lehrplan komplett offen.



0.4 Voraussetzungen

Teilnehmer sollten folgende Kenntnisse und/oder Erfahrung mitbringen: • Ausreichende praktische Erfahrung in Softwareentwicklung, erworben anhand unterschiedlicher

Projekte oder Systeme außerhalb der Ausbildung • Kenntnisse und praktische Erfahrung in mindestens einer höheren Programmiersprache • Grundlagen der Modellierung • Grundlagen von UML (Klassen-, Paket-, Komponenten- und Sequenzdiagramme) und deren

Abbildung auf Quellcode • Praktische Erfahrung mit verteilten Systemen (Entwicklung irgend eines Systems das nicht nur

auf einem Rechner ausgeführt wird) Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus: • Kenntnisse der Objektorientierung • Praktische Erfahrung in mindestens einer objektorientierten Programmiersprache • Praktische Erfahrung in der Konzeption und Implementierung verteilt ablaufender Anwendun-

gen, wie etwa Client/Server-Systeme oder Web-Anwendungen. • Erfahrung in CORBA, RMI, Web-Services • Praktische Erfahrung in technischer Dokumentation, insbesondere in der Dokumentation von

Quellcode, Systementwürfen oder technischen Konzepten.

0.5 Gliederung der iSAQB Lehrplanmodule

Die einzelnen Module des Lehrplans sind gemäß folgender Gliederung beschrieben: • Begriffe/Konzepte: Wesentliche Kernbegriffe dieses Lehrplanmoduls. • Unterrichts-/Übungszeit: Legt die Unterrichts- und Übungszeit fest, die für dieses Thema bzw.

dessen Übung in einer akkreditierten Schulung mindestens aufgewendet werden muss. • Lernziele: Beschreibt die zu vermittelnden Inhalte inklusive ihrer Kernbegriffe und -konzepte. Dieser Abschnitt skizziert damit auch die zu erwerbenden Kenntnisse in entsprechenden Schulungen. Die Lernziele werden differenziert in folgende Kategorien bzw. Unterkapitel: • Was sollen die Teilnehmer können? Diese Inhalte sollen die Teilnehmer nach der Schulung selb-

ständig anwenden können. Innerhalb der Schulung werden diese Inhalte durch Übungen abge-deckt und sind Bestandteil der Prüfung zum "Foundation Level".

• Was sollen die Teilnehmer verstehen? Diese Inhalte können in der Prüfung zum Foundation Level geprüft werden.

• Was sollen die Teilnehmer kennen? Diese Inhalte (Begriffe, Konzepte, Methoden, Praktiken oder Ähnliches) können das Verständnis unterstützen oder das Thema motivieren. Diese Inhalte sind nicht Bestandteil der Prüfung, werden in Schulungen thematisiert, aber nicht notwendiger-weise ausführlich unterrichtet.

• Referenzen: Verweise auf weiterführende Literatur, Standards oder andere Quellen. Eine aus-führliche Liste von Büchern und weiteren Quellen findet sich auf iSAQB-FachlicheQuellen.

0.6 Abgrenzung

Dieser Lehrplan stellt keine vollständige Beschreibung des Wissensgebiets „Software-Architektur“ dar. Er reflektiert lediglich den aus heutiger Sicht der iSAQB-Mitglieder notwendigen und sinnvollen Inhalt zur Erreichung der Lernziele des Foundation Level Folgende Themen oder Konzepte sind nicht Bestandteil des Foundation Level: • Konkrete Implementierungstechnologien, -frameworks oder –bibliotheken • Programmierung oder Programmiersprachen • Grundlagen der Modellierung • Umfassende Darstellung von UML • Systemanalyse, Requirements Engineering • Projektmanagement



0.7 Ergänzende Informationen, Begriffe, Übersetzungen

Soweit für das Verständnis des Lehrplan erforderlich, haben wir Fachbegriffe ins iSAQB Glossar auf-genommen, definiert und bei Bedarf durch die Übersetzungen der Originalliteratur ergänzt.

0.8 Einführung in das iSAQB Zertfizierungsprogramm

Dauer: 15 Min Übungszeit: keine

Dieser Abschnitt ist nicht prüfungsrelevant.

0.9 Begriffe und Konzepte

iSAQB, Zertifizierung, Foundation- und Advanced Level, Prüfung

0.10 Lernziele

Die Teilnehmer lernen den Kontext des iSAQB Zertifizierungsprogrammes und der zugehörigen Prü-fungen beziehungsweise Prüfungsmodalitäten kennen.

0.10.1 Was sollen die Teilnehmer kennen?

• iSAQB als Verein • Foundation Level in Abgrenzung zu weiteren Level

• Randbedingungen und Vorgehen beim iSAQB Zertifizierungsprogramm

• Andere Zertifizierungsprogramme (zum Beispiel TOGAF)



1 Grundbegriffe von Software-Architekturen

Dauer: 135 Min Übungszeit: 45 Min


Software-Architektur, Struktur, Bausteine/Komponenten, Schnittstellen, Beziehungen, übergreifende Konzepte/Aspekte, Architekturziele Software-Architekten und deren Verantwortlichkeit, Aufgaben und benötigte Fähigkeiten, nichtfunktionale und funktionale Anforderungen an Systeme, Randbe-dingungen, Einflussfaktoren, Typen von IT-Systemen (eingebettete Systeme, Echtzeitsysteme, Infor-mationssysteme etc.)

1.2 Lernziele

1.2.1 Was sollen die Teilnehmer können?

1.2.1.1 Definition von Software-Architektur

• Vergleich mehrerer De�nitionen von Software-Architektur (u.a. SEI, Booch etc.) und deren Ge-meinsamkeiten benennen: • Komponenten und Bausteine mit Schnittstellen und Beziehungen • Strukturen und übergreifende Konzepte • übergreifende Entwurfsentscheidungen mit systemweiten Konsequenzen • Design als Architektur-im-Kleinen

• Unsere Definition von Software-Architektur und Komponenten und der Bezug zum Code • Was ist eine Software-Architektur in diesem Kurs? • Was ist eine Komponenten, eine Schnittstelle, Beziehungen zw. Komponenten in diesem

Kurs?

• Wie kann man sich die Abbildung dieser Definitionen (SW-Architekturen/Komponenten /Schnittstellen/Beziehungen) auf den Code vorstellen?

• Analogie von Software-Architektur mit Konstruktionszeichnungen, Bauplänen erklären können • Software-Architektur als Beschreibung der Lösung • Software-Architektur als Unterstützung des Erstellungsprozesses, insbesondere der Imple-

mentierung

1.2.1.2 Nutzen und Ziele von Software-Architektur

Ziele von Software-Architekten und Software-Architekturen benennen und erklären • Fokus von Software-Architektur liegt auf Qualitätsmerkmalen wie Langlebigkeit, Wartbarkeit,

Änderbarkeit als Differenzierung gegenüber reiner Funktionalität. • Architekturziele sind in der Regel langfristig, Projektziele oftmals kurzfristig

1.2.1.3 Einordnung von Software-Architektur in die gesamte Entwicklung von IT-Systemen erklären

Rolle von Software-Architekt im Zusammenhang zu anderen Stakeholdern, kennen und erkären, insbesondere den Zusammenhang zu:

• Anforderungsanalyse (Systemanalyse, Requirements Management, Fachbereich) • Implementierung • Projektleitung und -management • Qualitätssicherung • IT-Betrieb (Produktion, Rechenzentren) [zutreffend primär für Informationssysteme] • Hardware-Entwicklung



1.2.1.4 Aufgaben von Software-Architekten

Software-Architekten tragen die Verantwortung für die Erreichung der geforderten oder notwendi-gen Qualität der Lösung. Sie müssen diese Verantwortung mit der Gesamtverantwortung der Pro-jektleitung koordinieren. • Aufgaben von Software-Architekten benennen und beschreiben können

• Anforderungen und Randbedingungen klären und hinterfragen, bei Bedarf verfeinern. Hierzu zählen neben den funktionalen Anforderungen (required features) insbesondere die gefor-derten Qualitätsmerkmale (required constraints). Konsequenzen dieser Randbedingungen auf die Architektur aufzeigen, siehe [Hofmeister+2000 Global Analysis], [Hofmeister+2005]

• Strukturentscheidungen hinsichtlich Systemzerlegung und Bausteinstruktur treffen, dabei Abhängigkeiten und Schnittstellen zwischen den Bausteinen festlegen

• Übergreifende technische Konzepte entscheiden (beispielsweise Persistenz, Kommunikation, GUI) und bei Bedarf umsetzen

• Software-Architektur kommunizieren und dokumentieren • Umsetzung und Implementierung der Architektur überwachen, Rückmeldungen der beteilig-

ten Stakeholder bei Bedarf in die Architektur einarbeiten, Konsistenz von Quellcode und Software-Architektur prüfen und sicherstellen

• Software-Architektur bewerten, insbesondere hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale

• Ergebniszusammenhänge zwischen den Aufgaben benennen und beschreiben: Welche Aufgabe liefert oder beeinflusst welches Arbeitsergebnis?

• Zusammenhang zwischen Anforderungen und Lösungen erläutern

• Randbedingungen und Einflussfaktoren für die Architekturgestaltung finden und gewichten

• Auf Basis bestehender Anforderungen Architekturziele identifizieren und präzisieren • Konsequenzen von Architekturentscheidungen erkennen, aufzeigen und gegenüber anderen

Stakeholdern argumentieren. • Selbständig die Notwendigkeit von Iterationen bei allen Aufgaben erkennen und Möglichkeiten

für entsprechende Rückmeldung aufzeigen

1.2.1.5 Architektur- und Entwurfsentscheidungen

• Bedeutung von Architekturzielen, Randbedingungen und Einflussfaktoren für die Gestaltung von Software-Architekturen aufzeigen können. • Erklärung von Anforderungen, sowohl required features als auch required constraints

• Erklärung von Randbedingungen / Einflussfaktoren • Erklärung von (langfristigen) Architekturzielen sowie deren Abgrenzung gegen (kurzfristige)

Projektziele • Entscheidungen über Strukturen und technische Konzepte, insbesondere die möglichen gegen-

seitigen Abhängigkeiten dieser Entscheidungen • Notwendigkeit expliziter und operationalisierter Architekturziele erläutern können. Nur anhand

solcher Ziele kann der Erfolg von Architekturen oder Architekturentwürfen bewertet werden

• Einfluss iterativen Vorgehens auf Architekturentscheidungen erläutern (hinsichtlich Risiken und Prognostizierbarkeit)

1.2.2 Was sollen die Teilnehmer verstehen?

• Software-Architekturen sind eine Beschreibung einer Lösung, nicht die Lösung selbst • Software-Architekturen unterstützen die Erreichung nichtfunktionaler Qualitätsmerkmale • Software-Architekten tragen die Verantwortung für die Erreichung der geforderten oder not-

wendigen Qualität der Lösung • Software-Architekten müssen ihre Aufgaben aktiv angehen • Software-Architekten sollten Annahmen oder Voraussetzungen explizit darstellen und implizite

Annahmen vermeiden



• Software-Architekten müssen aufgrund inhärenter Unsicherheit oftmals iterativ arbeiten und entscheiden. Dabei müssen sie bei anderen Stakeholdern systematisch Rückmeldung einholen.

• Qualitätsanforderungen (Required constraints) wie Änderbarkeit, Effizienz, Sicherheit etc. be-einflussen Software-Architekturen erheblich mehr als funktionale Anforderungen

• Differenzierung von Software-Architektur für unterschiedliche Typen von IT-Systemen verstehen: • Zusammenhang mit der System- oder Gesamtarchitektur für eingebettete oder hardwarena-

he Systeme. • Besonderheiten des Hardware-/Software-Codesigns verstehen (zeitliche und inhaltliche Ab-

hängigkeiten von Hard- und Softwareentwurf) • Zusammenhang mit Geschäfts- und Betriebsprozessen für Informationssysteme • Zusammenhang mit Geschäfts- und Betriebsprozessen für Entscheidungsunterstützungssy-

steme (Data Warehouse, Management InformationSystems)


• Weitere Ebenen von Architektur, z.B. Enterprise-IT-Architektur, Geschäftsarchitektur, Infrastruk-turarchitektur (etwa nach [Dern 2006]): Es gibt innerhalb der IT von Informationssystemen meh-rere Ebenen von Architekturen: • Infrastruktur-Architektur: Struktur der technischen Infrastruktur, Hardware, Netze etc. • Hardware-Architektur (für hardwarenahe Systeme) • Software-Architektur: Struktur einzelner Software-Systeme. Dies ist der Fokus von Software-

Architekten im Sinne des iSAQB. • Unternehmens-IT-Architektur, Enterprise-IT-Architektur: Struktur von Anwendungslandschaf-

ten. Nicht inhaltlicher Fokus von iSAQB. • Geschäftsprozess-Architektur, Business-Architektur: Struktur von Geschäftsprozessen (nicht

inhaltlicher Fokus von iSAQB).

• Taxonomie Qualitätsmerkmale nach ISO 9126 (ohne deren exakte Definition)

1.3 Referenzen

[Bass+2003] [Hofmeister+2000] [Posch 2004] [Reussner+2006] [Siedersleben 2004] [Starke 2008] [Vogel+2005]



2 Beschreibung und Kommunikation von Software-Architekturen



Sichten, Strukturen, (technische) Konzepte, Dokumentation, Kommunikation, Beschreibung Meta-Strukturen zur Beschreibung und Kommunikation, Bausteine, Bausteinsicht, Laufzeitbaustein, Lauf-zeitsicht, Verteilungssicht, Knoten, Kanal, Verteilungsartefakte, Mapping von Bausteinen auf Vertei-lungsartefakte, Beschreibung von Schnittstellen Dieser Teil des Lehrplans hängt eng mit dem Folgekapitel zusammen.

2.2 Lernziele


• Software-Architekturen stakeholdergerecht beschreiben und kommunizieren.

• Definition wesentlicher Architektursichten und deren Bedeutung erläutern • Dokumentieren verschiedener Architektursichten

• Baustein- oder Komponentensicht (Aufbau des Systems aus Softwarebausteinen) • Laufzeitsicht (dynamische Sicht, Zusammenwirken der Softwarebausteine zur Laufzeit, Zu-

standsmodelle) • Verteilungs-/Deploymentsicht (Abbildung von Softwarebausteinen auf Hardware oder Aus-

führungsumgebungen) • Bedeutung übergreifender technischer Konzepte beziehungsweise Architekturaspekte erklären

• Einige typische Konzepte benennen (z.B. Persistenz, Ablaufsteuerung, GUI, Vertei-lung/Integration)

• Beschreibung und Kommunikation von Schnittstellen

• Definition von Schnittstellen, insbesondere externer Schnittstellen • resourcenorientierter Ansatz • serviceorientierter Ansatz

• Wesentliche Grundlagen und Qualitätsmerkmale technischer Dokumentation erläutern:

• Qualitätsmerkmale technischer Dokumentation: Verständlichkeit, Korrektheit, Effizienz


• Beschreibung (a.k.a. Dokumentation) ist schriftliche Kommunikation • Die Beschreibungsmittel für Software-Architekturen unterstützen auch bei deren Entwurf und

Erstellung • UML Diagramme, die zur Notation von Architektursichten nützlich sind

• Klassen-, Paket- und Komponentendiagramme • Verteilungsdiagramme • Sequenzdiagramme

• Nutzen von template-/schablonenbasierter Dokumentation • Blackbox- und Whitebox Templates • Templates für Entwurf/Dokumentation von Knoten oder Kanälen • Templates zur Dokumentation von Schnittstellen

• Grundsätze guter technischer Dokumentation



• Sprache und Ausdrucksmittel technischer Dokumentation sollte an den Fähigkeiten und Zie-len der Leser ausgerichtet werden

• Verständlichkeit technischer Dokumentation kann nur von Lesern beurteilt werden • Wesentliche Qualitätsmerkmale technischer Dokumentation sind: • Korrektheit • Verständlichkeit

• Effizienz, sowohl beim Lesen als auch beim Schreiben • Dokumentieren Sie wichtige Architekturentscheidungen • Erklären Sie Architekturentscheidungen durch Begründungen und Herleitungen • Beschreibung von Software-Architekturen stellt besondere Anforderungen aufgrund der vielsei-

tigen Stakeholder • Unterschiedliche Leserkreise: Management, Entwickler, QS sowie andere Software- Architek-

ten • Unterschiedliche Autoren: Software-Architekten, Entwickler und ggfs. weitere.


• Grundlagen mindestens zweier, am besten mehrerer der publizierten Frameworks zur Beschrei-bung von Software-Architekturen: • TOGAF • FMC • RM/ODP • IEEE-1471 • arc42

• Ideen und Beispiele von Checklisten für die Erstellung, Dokumentation und Prüfung von Soft-ware-Architekturen

• Mögliche Werkzeuge zur Erstellung und Pflege von Architekturdokumentation

2.3 Referenzen

[Clements+2003] [Hargis+2004] [Starke 2008] [Starke+2009]



3 Entwicklung von Software-Architekturen



Entwurf, Vorgehen beim Entwurf, Entwurfsentscheidung, Sichten, technischer Konzepte Architek-turmuster, Entwurfsprinzipien, fachliche und technische Architekturen, modellbasierter Entwurf, iterativ/inkrementeller Entwurf, domain driven design, Top-Down und Bottom-Up Vorgehen

3.2 Lernziele

Dieser Teil führt Vorgehensweisen und Hilfsmittel für Entwurf und Entwicklung von Software-Architekturen ein. Die Teilnehmer erarbeiten in Übungen eine oder mehrere Architekturentwürfe und nutzen dabei die Ergebnisse des Kapitels 3.


• Vorgehen und Heuristiken zur Architekturentwicklung benennen, beschreiben und erklären: • Modell- und sichtenbasierte Architekturentwicklung • Modellbasierter Entwurf und Domain Driven Design • Iterativer und inkrementeller Entwurf

• Notwendigkeit von Iterationen, insbesondere bei unter Unsicherheit getroffenen Ent-scheidungen

• Rückmeldungen zu Entwurfsentscheidungen auf Basis von Quellcode sowie qualitativer Betrachtung

• Top-Down und Bottom-Up Vorgehen beim Entwurf • Einflussfaktoren und Randbedingungen als Beschränkungen beim Architekturentwurf

(Global Analysis) • Entwurf von Architekturen auf Basis bekannter funktionaler und nichtfunktionaler Anforderun-

gen für nicht sicherheits- oder unternehmenskritische Software-Systeme durchführen und an-gemessen dokumentieren

• Blackbox- und Whitebox-Begriff erklären und zielgerichtet anwenden • Schrittweise Verfeinerung und Präzisierung von Bausteinen (Hierarchisierung) anwenden • Entwurf einzelner Architektursichten, insbesondere Verteilungs-, Baustein- und Laufzeitsicht und

deren Konsequenzen auf den zugehörigen Quellcode beschreiben • Abbildung der Architektur auf den Code festlegen, entwerfen, sich überlegen und die damit

verbundenen Konsequenzen • Trennung fachlicher und technischer Bestandteile in Architekturen begründen und anwenden • Fachliche Strukturen entwerfen und begründen

• Fachliche Bausteine (Entitäten, Services) identifizieren, begründen und dokumentieren • Abstraktionen zum Übergang fachliche Bestandteile zu technischen Bestandteilen erklären

und anwenden

• Einfluß von Qualitätsanforderungen auf Architekturen

• Einfluß technischer Entscheidungen und Konzepte auf Architekturen, insbesondere Baustein-strukturen

• Grundlegende Konzepte der Architekturentwicklung benennen, erklären und anwenden • Bausteine von Software-Architekturen und deren Eigenschaften benennen und erklären:



• wünschenswerte Eigenschaften (Kapselung, Information Hiding, Geheimnisprinzip) von Bau-steinen

• Blackbox und Whitebox Bausteine • Arten der Zusammensetzung von Bausteinen (Schachtelung, Benutzung/Delegation, Vererbung) • UML-Notation für verschiedene Bausteine und deren Zusammensetzung

• Pakete als semantisch schwache Form der Aggregation von Bausteinen

• Komponenten mit fest definierten Schnittstellen als semantisch präzisere Form der Aggrega-tion

• Wichtige Architekturmuster beschreiben, erklären und angemessen anwenden können • Schichten • Pipes und Filter • Model-View-Controller

• Entwurfsprinzipien erläutern anwenden können • Geheimnisprinzip • Kopplung und Kohäsion • Trennung von Verantwortlichkeiten (Separation of Concern) • Offen-Geschlossen-Prinzip (Open-/Closed-Principle) • Umkehrung von Abhängigkeiten durch Schnittstellen • Dependency Injection zur Externalisierung von Abhängigkeiten • Zusammenhang zwischen Abhängigkeiten im Modell und im Quellcode von Programmier-

sprachen • Abhängigkeiten und Kopplung von Bausteinen verstehen und gezielt einsetzen

• Konsequenzen von Kopplung erkennen • Arten der Kopplung (strukturell, zeitlich, über Datentypen, über Hardware etc.) aufzeigen

können

• Möglichkeiten zur Auflösung bzw. Reduktion von Kopplung kennen • Schnittstellen / Interfaces entwerfen und beschreiben können


• Details zu Kopplung und deren Konsequenz in Programmiersprachen • Umsetzung von Beziehungen in (objektorientierten) Programmiersprachen

• Konstruktoren • Factory-Muster • Dependency-Injection

• Architekturmuster bedarfsgerecht einsetzen • nach POSA (Schichten, Pipes und Filter, Blackboard, Microkernel) • nach Fowler/PoEAA • nach Hohpe (Messaging, async-Muster) • sonstige Muster

• Sprachunabhängige Entwurfsmuster einsetzen • Adapter, Wrapper, Gateway • Facade • Registry • Broker


• Weitere Entwurfsmuster (Design Patterns), die nicht unbedingt Bestandteil einer akkreditierten Schulung sein müssen • Factory



• Wesentliche Quellen für Architekturmuster • POSA-Serie • Pattern-Konferenzen

• Beispiele weiterer Pattern-Languages • Organizational Patterns • Reengineering Patterns • Security Patterns • Client/Server Patterns • Patterns für Distributed Systems • Weitere je nach Schwerpunkt der jeweiligen Schulung

3.3 Referenzen

[Martin+2003] [Fowler 2003] POSA-Serie, insbesondere [POSA-1] und [POSA-4] [Demeyer+2002]



4 Software-Architekturen und Qualität



Qualität, Qualitätsmerkmale, DIN/ISO 9126, ATAM, Szenarien, Qualitätsbaum, Kompromisse (bei der Umsetzung von Qualitätsmerkmalen), qualitative Architekturbewertung

4.2 Lernziele

In diesem Teil lernen die Teilnehmer sowohl Maßnahmen zur Erreichung bestimmter Qualitätsmerk-male in Software-Systemen kennen, als auch methodisches Vorgehen zur qualitativen Bewertung von Software-Architekturen.


• Begriff der Qualität (angelehnt an DIN/ISO 9126) und Qualitätsmerkmalen erklären • Qualitätsmodelle (wie etwa DIN/ISO 9126) erklären • Zusammenhang und Wechselwirkungen von Qualitätsmerkmalen erläutern • Taktiken, Praktiken sowie technische Möglichkeiten zur Erreichung wichtiger Qualitätsziele von

Software-Systemen (unterschiedlich für eingebettete Systeme bzw. Informationssysteme) erklä-ren und anwenden, beispielsweise:

• Effizienz/Performance • Wartbarkeit, Änderbarkeit, Erweiterbarkeit, Flexibilität

• Qualitative Bewertung von Software-Architekturen nach ATAM durchführen • Vorgehen bei qualitativer Bewertung erklären und durchführen • Erstellung von Szenarien und Qualitätsbäumen erklären und durchführen

• Analyse von Software-Architekturen hinsichtlich Szenarien und Identifikation entsprechender Risiken selbständig durchführen

• Bewertung von Software-Architekturen im Hinblick auf ihre Umsetzung durchführen, d.h. die Frage beantworten, in wie weit eine Architektur auch im Code umgesetzt wurde. • Wie kann man Architekturen im Code überprüfen (und dies operationalisieren und im Pro-

zess integrieren, beispielsweise als Teil des Check-In-Vorgangs, im Build etc.) • Metriken und andere Messinstrumente, um Architektur beurteilen zu können


• Taktiken, Praktiken sowie technische Möglichkeiten zur Erreichung weiterer Qualitätsziele von Software-Systemen erklären und anwenden: • Sicherheit • Verständlichkeit, Nachvollziehbarkeit • Robustheit, Fehlertoleranz • Skalierbarkeit

• Prototypen oder technische Durchstiche zur Überprüfung von Architekturqualität einsetzen • Metriken zur Bewertung von Artefakten erklären • Zur Einschätzung und Bewertung von Architekturen können weitere Medien und Informationen

zu Rate gezogen werden, etwa: • Quellcode • bekannte Fehler in Quellcode, insbesondere Fehlercluster




Weitere Metriken, insbesondere Lines-of-Code, zyklomatische Komplexität, ein- und ausgehende Abhängigkeiten, Instabilität, Abstraktheit, Distanz

4.3 Referenzen

[Bass+2003] [Clements+2002] [Martin 2003] [Starke 2008]



5 Werkzeuge für Software-Architekten



Folgende Kategorien von Werkzeugen sind wichtige Arbeitsmittel für Architekten:

5.1.1 Modellierungswerkzeuge

Unterstützung bei diesen Aufgaben des Architekten: • Entwurf und Kommunikation von Software-Architekturen • Vorgabe für detailliertes Design und Implementierung, gegebenenfalls auch Codegenerierung Kriterien: • Unterstützung mehrerer Benutzer • Validierung / formale Überprüfung von Modellen • Unterstützung für Codegenerierung (siehe auch: Generierungswerkzeuge) • Unterstützung für Reverse Engineering • Unterstützung bei der Erzeugung von Dokumentation

• Unterstützung des Konfigurationsmanagements (Versionierung, Vergleich, Merge von Modellen)

5.1.2 Werkzeuge zur statischen Analyse

Unterstützung bei diesen Aufgaben des Architekten: • Bewertung bestehender Software-Systeme bzgl. Qualitätseigenschaften, z.B. Komplexität - kann

Grundlage für Refactoring sein • Analysieren, ob die Umsetzung den Vorgaben in der Architektur entspricht (z.B. werden Regeln

bezüglich zulässiger Abhängigkeiten befolgt) Kriterien: • Automatisierbarkeit • Aufbereitung und Visualisierung der Ergebnisse • Unterstützte Analysekriterien und Metriken

5.1.3 Werkzeuge zur dynamischen Analyse

Unterstützung bei diesen Aufgaben des Architekten: • Gezielte Untersuchung bestehender Software-Systeme bzgl. Performance- und Lasteigenschaf-

ten

5.1.4 Generierungswerkzeuge

Unterstützung bei diesen Aufgaben des Architekten: • Vorgabe eines Rahmens für die Implementierung • Übereinstimmung von Architekturmodell und Implementierung gewährleisten Kriterien:

• Konfigurierbarkeit der Code Generierung • Lesbarkeit des generierten Codes



• Ggf. Zertifizierung für sicherheitskritische Anwendungen • Wiederholbarkeit des Generierungsschritts • Schnittstelle zwischen generiertem und manuell implementiertem Code

5.1.5 Anforderungsmangementwerkzeuge

Unterstützung bei diesen Aufgaben des Architekten: • Analyse der Anforderungen für das zu entwerfende Software-System Kriterien: • Unterstützung der Traceability zwischen Anforderungen und Architektur

5.1.6 Dokumentationswerkzeuge

Unterstützung bei diesen Aufgaben des Architekten: • Kommunikation der Architektur Kriterien: • Automatisierte Generierung aktueller Dokumentation aus Architekturmodellen - hierbei ist auch

wichtig, Detaillierungsgrad und Umfang zielgruppengerecht wählen zu können • Unterstützung mehrerer Benutzer

• Unterstützung des Konfigurationsmanagement der Dokumentation (Versionierung, Nachvoll-ziehbarkeit von Änderungen)

5.1.7 Build-Systeme/-Werkzeuge

Unterstützung bei diesen Aufgaben des Architekten • Automatisierung des Kompilier-, Paketier- und Test-Vorgangs • Überprüfung auf Einhaltung struktureller Vorgaben • Ansteuerung eines kontinuierlichen Standbaus inkl. QS Kriterien: • Performance • Anpassbarkeit • Homogenität • Unterstützung proprietärer Werkzeugen

5.1.8 Konfigurationsmanagement

Unterstützung bei diesen Aufgaben des Architekten

• Zuordnung und Selektion von Konfigurationselementen zu einer Konfiguration • Inventarisierung

• Rekonstruktion einer Konfiguration Kriterien: • Performance

• Skalierbarkeit (Konfigurationen sowohl aufgrund der enormen Größe als auch aufgrund der Varianten)

• Methodische Integration mit anderen Werkzeugen (Versionsverwaltung, Issue-Tracker, Require-ments-Management-Werkzeuge ...)



5.2 Lernziele


Teilnehmer sollen die wichtigsten Kategorien von Werkzeugen sowie deren Stärken und Schwächen für die Arbeit von Software-Architekten benennen und erläutern können.


Die Arbeitsumgebung und die Arbeitsmittel von Software-Architekten hängen von den jeweiligen Randbedingungen und Einflussfaktoren ab.


Einige Vertreter typischer Werkzeuge aus eigener praktischer Erfahrung. Hierzu zählen: • Modellierungswerkzeuge (UML-Werkzeuge) • Generierungswerkzeuge (MDA- oder MDSD-Werkzeuge) • Dokumentationswerkzeuge (Wikis, Repository-basierte sowie Datei-basierte Dokumentenverwal-

tung)

• Werkzeuge zum Build- und Konfigurationsmanagement

5.3 Referenzen

Keine.



6 Beispiele für Software-Architekturen


Dieser Abschnitt ist nicht prüfungsrelevant.


Innerhalb jeder akkreditierten Schulung müssen mindestens ein, besser zwei Beispiele von Software-Architekturen vorgestellt und besprochen werden. Art und Ausprägung der vorgestellten Beispiele können von der Schulung bzw. den Interessen der Teilnehmer abhängen und werden seitens iSAQB nicht vorgegeben.

6.2 Lernziele

Vorstellung und Besprechung mindestens einer, besser zwei Beispielarchitekturen.


n.z.


n.z.


Einige Beispiele (möglichst) realitätsnaher Architekturen.

6.3 Referenzen

Keine. Schulungsanbieter sind für die Auswahl und Beschreibung von Beispielen verantwortlich.



7 Quellen und Referenzen zu Software-Architektur

Dieser Abschnitt enthält Quellenangaben, die ganz oder teilweise im Curriculum referenziert wer-den.

_=

[Bachmann 2000] Bachmann, F., L. Bass, et al.: Software Architecture Documentation in Practice. Software Engineering Institute, CMU/SEI-2000-SR-004. [Bass+2003] Bass, L., Clements, P. und Kazman, R. (2003): Software Architecture in Practice. Addison-Wesley, Reading, Mass [Bosch 2000] Bosch, J.: Design & Use of Software Architectures. Addison-Wesley, 2000 [Buschmann+96] Buschmann, F., R. Meunier, H. Rohnert,, P. Sommerlad,, M. Stal: A System of Patterns. Pattern – Oriented Software. Architecture. Wiley 1996. [Buschmann+2007] Frank Buschmann, Kevlin Henney, Doug Schmidt: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing (v. 4). Wiley, 2007.

`=

[Clements+2002] Clements, P., R. Kazman, M. Klein: Evaluating Software Architectures – Methods and Case Studies. Addison Wesley, 2002. [Clements+2003] Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Ivers et al: Documenting Software Architectures – Views and Beyond. Addison Wesley, 2003.

a=

[Demeyer+2002] Serge Demeyer, Stephane Ducasse, Oscar Nierstrasz. Object Oriented Reengineering Patterns. Mor-gan Kaufman, 2002. [Dern 2006] Dern, Gernot: Management von IT-Architekturen. Informationssysteme im Fokus von Architekturpla-nung und -entwicklung. Vieweg, Edition CIO, 2. Auflage, 2006.

b=

[Evans 2004] Evans, E.: Domain Driven Design. Addison-Wesley, 2004. Zugehöri-ge Website: www.domaindrivendesign.org.



c=

[Fowler 2003] Fowler, M. (2003): Patterns of enterprise application architecture. Addison-Wesley.

d=

[Gamma 1995] Gamma, E., R. Helm, R. Johnson, J. Vlissides: Design Patterns. Addison-Wesley, 1995. [Gordon 2006] Gordon, I.: Essential Software Architecture. Springer 2006.

e=

[Hargis+2004] Hargis, Gretchen et. al Developing Quality Technical Information. A Handbook for Writers and Edi-tors. Prentice Hall, 2004. [Hatley2000] Hatley, D., P. Hruschka, I. Phirbai: Process for System Architecture and Requirements Engineering. Dorset House, 2000. [Hofmeister+2000] Hofmeister, C., Nord, R. und Soni, D. (2000): Applied Software Architecture. Addison-Wesley. [Hofmeister+2005] Hofmeister, Christine, R. Nord, D. Soni. “Global Analysis: Moving from Software equirements Spe-cification to Structural Views of the Software Architecture,” IEE Proceedings Software, Vol. 152, Issue 4, pp. 187-197, August 2005. [Hohpe+2003] Hohpe, G., B. Woolf: Enterprise Integration Patterns: Design¬ing, Build-ing, and Deploying Messa-ging Solutions. Addison Wesley, 2003.

h=

[Keller 2006] Keller, Wolfgang: IT-Unternehmensarchitektur: Von der Geschäftsstrategie zur optimalen IT-Unterstützung. dpunkt, 2006. [Kruchten 1995] Kruchten, P.: Architectural Blueprints – The 4-1 View Model of Architecture. IEEE Software Novem-ber 1995; 12(6), p. 42-50.

j=

[Martin 2003] Martin, R. C. (2003): Agile Software Development, Principles, Patterns, and Practices. Pearson Educa-tion, Upper Saddle River.

l=

[Open Group 09]



The Open Group: TOGAF, Version 9. Online: www.opengroup.org/architecture/togaf9-doc/arch/

m=

[Parnas 1972] Parnas, D. L.: On the Criteria to be Used in Decomposig Systems into Modules. Communications of the ACM 1972; 15: p. 1053-1058. [POSA-1] siehe [Buschmann+96] [POSA-4] siehe [Buschmann+2007] [Posch 2004] Posch, T., K. Birken, M. Gerdom: Basiswissen Softwarearchitektur: Verstehen, entwerfen, bewerten und dokumentieren. Dpunkt, 2004. [Putman 2000] Putman, J.: Architecting with RM-ODP. Prentice Hall, 2000

R=

[Rechtin+2000] Rechtin. E., M. Maier: The Art of Systems Architecture. CRC Press, 2000 [Reussner+2006] Reussner, R. und Hasselbring, W. (eds.) (2006): Handbuch der Software-Architektur. dpunkt.verlag, Heidelberg.

p=

[Schmidt2000] Schmidt, D., M. Stal, H. Rohnert, F. Buschmann: Pattern-Oriented Software-Architecture – Patterns for Concurrent and Networked Objects. Vol. 2. Wiley, 2000. [Shaw 1996] Shaw, M., D. Garlan: Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice Hall, 1996. [Siedersleben 2004] Siedersleben, J. (2004): Moderne Softwarearchitektur: Umsichtig planen, robust bauen mit Quasar. dpunkt.verlag, Heidelberg [Starke 2008] Starke, G. (2008): Effektive Software-Architekturen - Ein praktischer Leitfaden. 3. aktualisierte und erweiterte Auflage 2008, Carl Hanser Verlag, München. [Starke+2009] Starke, Gernot und Peter Hruschka: Software-Architektur kompakt. Spektrum Akademischer Verlag, 2009.

s=

[Vogel+2005] Vogel, O., u.a.: Software-Architektur: Grundlagen – Konzepte – Praxis. Spektrum, 2005

Documents

Certified Professional for Software Architecture (CPSA ...isaqb.org/wp-content/uploads/2013/05/isaqb-Lehrplan-foundation.pdf · iSAQB Curriculum für Foundation Level Seite 6 von