SlideShare ist ein Scribd-Unternehmen logo
© ITech Progress GmbH
Version 7.0
Durchgeführt von unserem
Trainingspartner:
Entwurf und Entwicklung
von Softwarearchitekturen
Certified Professional for Software Architecture – Foundation Level (CPSA-F)
CPSA Foundation Level
• Einführung in das iSAQB Zertifizierungsprogramm
• Grundbegriffe
• Entwurf und Entwicklung von Softwarearchitekturen
• Beschreibung und Kommunikation von Softwarearchitekturen
• Softwarearchitektur und Qualität
• Beispiele für Softwarearchitekturen
Agenda
2 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf (Exkurs DDD)
Entwurf und Entwicklung von Softwarearchitekturen
3 von 95
CPSA Foundation Level
• Architekturen, Organisationen und Systeme
beeinflussen sich gegenseitig
• Kunden und Projektbeteiligte können
Anforderungen und Einflussfaktoren ändern
• Architekturentwurf und -entscheidungen sollten
iterativ angepasst werden
• Verhindert frühzeitig Probleme beim Entwurf
• Wünsche und Anforderungen werden frühzeitig mit
einbezogen
Architekturen entstehen iterativ
Kunde
Architekturentwurf
Umwelt &
Projektbeteiligte
Einflussfaktoren Anforderungen
ändern
beeinflussen
ändert
4 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Top-Down und Bottom-Up
Top-Down
➢ Zusammenbau
von Teillösungen
(Synthese)
➢ Ausgangspunkt:
Bibliotheken und
Teilfunktionen
Bottom-Up
➢ Zerlegung in Teilprobleme
(Analyse)
➢ Ausgangspunkt: Vision vom
Gesamtsystem
5 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Vorteile
• gutes Problemverständnis
• maschinen- und sprachunabhängig
• kein Verirren in Details
• saubere Schnittstellen
• Entwurf noch im Produkt
erkennbar
Nachteile
• kritische Integration am Ende
• Übersehen von existierenden (Teil-)
Lösungen
• gravierende Änderungen bei spät
erkannten Problemen
Top-Down
6 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Vorteile
• hoher Wiederverwendungsgrad
• hohe Funktionssicherheit durch
inkrementellen Test
• schrittweise Integration
Nachteile
• beginnt mit vermuteten
Teilproblemen
• Orientierung an technischen
Gegebenheiten statt an
Benutzeranforderungen
• Gefahr der frühzeitigen Optimierung
• „wild gewachsene“ Systemstruktur
Bottom-Up
7 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
• Modellgetriebene Architekturentwicklung
• Modellbasierte Abbildungen bieten insbesondere Vorteile hinsichtlich der Aspekte Abstraktion und Anschaulichkeit
• Beschränkung auf kontextrelevanten Sachverhalt
• Angemessene grafische Notationen
• Sichtenbasierte Architekturentwicklung:
• Sichten helfen, die Komplexität einer Architektur zu beherrschen
• Rollenspezifische Sichten
• Ausblenden von für konkrete Fragestellungen oder Aktivitäten irrelevanter Informationen
• Dabei kommen insbesondere Techniken der Modellgetriebenen Softwareentwicklung zum Einsatz
• Domain Driven Design
• Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit
Methoden beim Architekturentwurf
8 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Systematischer Entwurf
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
9 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Systematischer Entwurf
Wo stehen wir jetzt?
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
10 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Informationen sammeln
Informationen
Für das Projekt benötigtes Domänenwissen und
technisches Hintergrundwissen erarbeiten
In der Organisation vorhandene Systeme ermitteln und auf
Wiederverwendbarkeit prüfen
Von Dritten angebotene Systeme
ermitteln, die eine ähnliche Aufgabe
oder wenigstens Teile davon erfüllen,
wie das zu entwickelnde System
Passende technische Literatur für
benötigte Lösungsansätze und
Vorgehensmuster sichten
Systemidee entwickeln
11 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
• Beschreibung der Kernaufgabe des Systems
• Festlegung der Art der Steuerung
• Ereignisgetrieben (Event driven)
• Prozedurale Steuerung
• Parallele Steuerung / Nebenläufigkeit
• Deklarative oder regelbasierte Steuerung
• Beschreibung der Nutzungsart des Systems
Systemidee entwickeln
12 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
Interaktives Online-System /
operationales System
•Geschäftsprozesse
•Transaktionen auf aktuellen
Organisationsdaten
•Hohe Verfügbarkeit und Performanz
erforderlich
Unterstützendes System
•Berechnungen und Analysen
•Entscheidungsunterstützung
•Lesend auf Kopien der
Organisationsdaten
•Längere Laufzeiten üblich
Hintergrundsystem
•Offline- oder Batchsysteme
•Zeitversetzte Vor- und
Nachbearbeitung von Daten
Eingebettetes System
•Läuft innerhalb spezieller Hardware
und steuert diese
Echtzeitsystem
•Festgelegte Zeitgarantien für
zeitkritische Operationen
Nutzungsart des Systems
13 von 95
Entwurf und Entwicklung /
Vorgehensweisen beim Architekturentwurf
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf (Exkurs DDD)
Entwurf und Entwicklung von Softwarearchitekturen
14 von 95
CPSA Foundation Level
Systematischer Entwurf
Wo stehen wir jetzt?
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
15 von 95
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
CPSA Foundation Level
• Produktbezogene Faktoren
• Funktionale Anforderungen (required features)
• Nicht-funktionale Anforderungen (required constraints)
• Technische und betriebsbedingte Faktoren
• Zielplattform, Technologien, Standards, Werkzeuge
• Organisatorische / politische Faktoren
• Projektplan, Personal, Budget, Offshoring
• Trends
• Markttrends
• Technologietrends
Einflussfaktoren und Randbedingungen
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
16 von 95
CPSA Foundation Level
• Teilen sich auf in die funktionalen und nicht-funktionalen Anforderungen
• Funktionale Anforderungen
• Beschreiben gewünschte Funktionalitäten (was soll das System tun/können) eines Systems bzw.
Produkts, dessen Daten oder Verhalten
• Nicht-funktionale Anforderungen
• Anforderungen an die Qualität der geforderten Funktionalitäten
Produktbezogene Faktoren
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
17 von 95
CPSA Foundation Level
Technische Faktoren
Hardwareinfrastruktur
Softwareinfrastruktur
Systembetrieb
Verfügbarkeit der
Laufzeitumgebung
Grafische Oberfläche Bibliotheken, Frameworks
und Komponenten
Programmiersprachen
Referenzarchitekturen
Analyse- und
Entwurfsmethoden
Datenstrukturen
Programmierschnittstellen
Programmiervorgaben
Technische
Kommunikation
Technische
Faktoren
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
18 von 95
CPSA Foundation Level
Organisation und Struktur
•Organisationsstruktur des
Auftraggebers
•Organisationsstruktur des Projektteams
•Entscheidungsträger
•Partnerschaften / Kooperationen
•Verkaufsprodukt oder Eigennutzung
Ressourcen
•Zeitplan
•Funktionsumfang
•Release-Plan
•Budget
•Teammitglieder
Organisationsstandards
•Vorgehensmodell
•Qualitätsstandards
•Werkzeuge (Entwicklung, Konfiguration,
Versionierung)
•Testprozess
•Abnahme- und Freigabeprozess
Juristische Faktoren
•Haftungsfragen
•Datenschutz
•Nachweispflichten
•Internationale Rechtsfragen
Organisatorische Faktoren
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
19 von 95
CPSA Foundation Level
• Global Analysis nach [Hofmeister+2000]
• Einflussfaktoren werden in ihrer Gesamtheit betrachtet
• Gegenseitige Wechselwirkungen, Konflikte
• Wirken sich auf die gesamte Architektur aus
• Einflussfaktoren werden langfristig betrachtet
• Sie können sich ändern
• Ihre Auswirkung kann sich ändern
• Können wir diese Änderungen beeinflussen?
→Architekturentscheidungen müssen „global“ getroffen werden, um alle Einflussfaktoren in Einklang zu
bringen
Einflussfaktoren und Randbedingungen
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
20 von 95
CPSA Foundation Level
Systematischer Entwurf
Wo stehen wir jetzt?
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
21 von 95
CPSA Foundation Level
Typische Risiken
Fehlende Priorisierung
Enger Zeitplan
Eingeschränkte Eignung von Ressourcen
Unzureichende Anforderungen
Mangelnde Dokumentation
Kritische externe Schnittstellen
Widersprüche
Neue, unerprobte Produkte
Verfügbarkeiten der technischen Infrastruktur
Eingeschränkte Verfügbarkeit von
Fachwissen
Hohe Änderungsrate von Anforderungen
Eingeschränkte Verfügbarkeit von Ressourcen
Mehrdeutigkeit
Typische Risiken
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
22 von 95
CPSA Foundation Level
• Zusammenarbeit mit dem Projektmanagement bei organisatorischen Problemen (Zeit,
Budget, Know-how)
• Rechtzeitig und offen Hinweise zum Risikomanagement liefern:
• alternative Auslieferungsmodelle erarbeiten,
um zeitkritische Termine zu entschärfen
• Auswirkungen kritischer Anforderungen verdeutlichen und gegebenenfalls neu verhandeln
• Priorisierung
• Umfang
• Qualität
• Make-or-Buy Entscheidungen überdenken
Strategien gegen organisatorische Risiken
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
23 von 95
CPSA Foundation Level
• Niemand arbeitet unter hohem Druck produktiver oder schneller
• Steigende Fehlerrate und Quick-and-Dirty Lösungen
• Einem verspäteten Projekt mehr Mitarbeiter zu geben, macht das Projekt noch später
• Murphy‘s Law: zusätzliche Probleme tauchen von allein auf
• Schätzungen lieber zu hoch als zu niedrig ansetzen
• Sicherheitszuschläge einberechnen
• Wenn die Politik nicht mitspielt, wird das System niemals laufen
• KISS-Prinzip
Wichtige Projekterfahrungen
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
24 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf (Exkurs DDD)
Entwurf und Entwicklung von Softwarearchitekturen
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
25 von 95
CPSA Foundation Level
Systematischer Entwurf
Wo stehen wir jetzt?
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
Entwurf und Entwicklung /
Einflussfaktoren und Randbedingungen
26 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf (Exkurs DDD)
Entwurf und Entwicklung von Softwarearchitekturen
27 von 95
CPSA Foundation Level
• Ziel: Vom WAS zum WIE
• Gliederung des Entwurfsprozesses
• Grobentwurf: Gesamtstruktur des Systems (Architektur, Subsysteme, Schnittstellen, …)
• Feinentwurf: Detailstruktur des Systems (Komponentenentwurf, Datenstrukturentwurf, …)
• Entwurfsprinzipien
• Helfen dem Softwarearchitekt beim Entwurf
• Repräsentieren bewährte Grundsätze
• Behandeln meist folgende Hauptprobleme:
• Reduktion der Komplexität
• Erhöhung der Flexibilität
• Änderbarkeit einer Softwarearchitektur
Softwareentwurf
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
28 von 95
CPSA Foundation Level
• Horizontale Zerlegung in Schichten
• bieten klar definierte Schnittstellen
• nutzen Dienste darunter liegender Schichten
• Vertikale Zerlegung in funktionale Module
• Zerlegungskriterium kann fachlicher oder technischer Natur sein
• Modularität eines Systems gibt an, inwieweit ein System in jeweils in sich geschlossene Bausteine
(Module) zerlegt und gekapselt ist
Zerlegung: Divide et impera
Die zu lösende Aufgabe wird in immer kleinere Teilaufgaben zerlegt, bis die Komplexität dieser
Aufgaben eine beherrschbare Größe erreicht hat.
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
29 von 95
CPSA Foundation Level
• Bei beiden geht es um Abhängigkeiten:
• Kopplung: Abhängigkeiten zwischen Bausteine
• Kohäsion: Abhängigkeiten zwischen Funktionen innerhalb eines Bausteins
• Ziel: Bündelung und Verkapselung von Abhängigkeiten
Kopplung und Kohäsion
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
30 von 95
CPSA Foundation Level
• Zwei Bausteine, die lose gekoppelt sind, können interagieren, wissen aber sehr wenig
voneinander
• Wiederverwendung bleibt erhalten
• Änderungen wirken sich nur lokal aus
Lose Kopplung
Hoher Kopplungsgrad Niedriger Kopplungsgrad
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
31 von 95
CPSA Foundation Level
Kopplung
Aufruf
Erzeu-
gung
Daten
Zeit
Aus-
führungs-
ort
Code
Arten von Kopplung
•Gleiche Hardware/ Laufzeitumgebung
•Gleicher Prozess
•Gleiches Netzwerksegment
•Direkte Nutzung eines anderen Bausteins
•Ein Baustein erzeugt einen anderen
•Aufrufparameter
•Datenstrukturen
•Die zeitliche Abfolge von
Bausteinaktivitäten spielt eine Rolle
•Gemeinsame Bibliotheken und
andere Deployment-Artefakte
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
32 von 95
CPSA Foundation Level
• Auch Zusammenhangskraft (cohaerere, lat: zusammenhängen)
• Ein kohäsives Baustein
• Löst ein einziges Problem
• Besitzt eine spezifische Menge an stark zusammenhängenden Funktionalitäten
• Beispiel: Kohäsive Pakete beherbergen Klassen eines zusammenhängenden Funktionskomplexes
• Je höher die Kohäsion, desto stärker zusammenhängend ist die Zuständigkeit eines
Bausteins in der Anwendung
Hohe Kohäsion
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
33 von 95
CPSA Foundation Level
Prinzipien bei der Zerlegung
Konzeptionelle Integrität
Alle Standpunkte betrachten
Einfachheit
SOLID Prinzipien
Wiederverwendung von etablierten und erprobten
Strukturen
Prinzipien der
Zerlegung
Stärken und Schwächen ermitteln und bewerten
Fehler erwarten
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
34 von 95
Separation of Concerns
Information Hiding
CPSA Foundation Level
• Unterschiedliche Aspekte eines Problems voneinander trennen
• Jedes Teilproblem separat für sich behandeln
• Zurückzuführen auf das Prinzip „Divide et impera“
• Verantwortlichkeiten sollten auf allen Ebenen des Entwurfs betrachtet werden
• von einzelnen Klassen bis hin zu ganzen Systemen
• Trennung von fachlichen und technischen Teilen ist besonders wichtig
• fachliche Abstraktion wird von technischer Umsetzung getrennt
Separation of Concerns
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
35 von 95
CPSA Foundation Level
• 1972 von David L. Parnas entwickelt [Parnas1972]
• Kapseln der Komplexität in Komponenten
• Erhöht die Flexibilität
• Verbesserte Testbarkeit, Stabilität und Änderbarkeit
• Komponenten werden als „Blackbox“ betrachtet
• Unterbindung des direkten Zugriffs auf die interne Datenstruktur
• Zugriff nur über definierte Schnittstellen
• Missachtung der Kapselung führt zu
• Ungewollten, schwierigen Abhängigkeiten
• Höherer Komplexität
Information Hiding
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
36 von 95
CPSA Foundation Level
• Blackboxes
• Zeigen externe Schnittstellen
• Beschreiben Funktionalität nach dem Geheimnisprinzip
• Information Hiding (=> später)
• Whiteboxes
• Zeigen innere Struktur, Abhängigkeiten und Arbeitsweisen
• Die inneren Bausteine sind wiederum Blackboxes
Black- und Whiteboxes lassen sich in hierarchischer Top-Down-Art entwerfen
Information Hiding / Blackbox- und Whitebox-Beschreibung
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
37 von 95
CPSA Foundation Level
Blackbox- und Whitebox: Beispiel
https://de.wikipedia.org/wiki/Komponente_(UML)
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
38 von 95
CPSA Foundation Level
Blackbox Whitebox
Externe Schnittstellen Enthaltene Bausteine und deren Abhängigkeiten
Qualitätsanforderungen wie Performance Umsetzung der Qualitätsanforderungen
Integrationsaspekte mit anderen Bausteine Integrationsaspekte der enthaltenen Bausteine
Erfüllung funktionale Anforderungen Code Struktur
Datenformate und Signatur der externen Schnittstellen Entwurfsentscheidungen über enthaltene Bausteine wie
Einsatz von Patterns
Verantwortlichkeit Begründung des Entwurfs (interne Zerlegung)
Blackbox- und Whitebox Aspekte: Beispiele
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
39 von 95
CPSA Foundation Level
• Verfeinerung sollte redundanzfrei erfolgen
• Bei starker Abhängigkeit zweier Blackbox-
Bausteine:
• Whitebox-Darstellungen in einem gemeinsamen
Diagramm
• Prüfen, ob statt eigenen Bausteinen bestehende
Bausteine wiederverwendet werden können
Information Hiding / Hierarchische Verfeinerung
verfeinert
verfeinert
verfeinert
System
(Whitebox)
(Whitebox) (Whitebox)
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
40 von 95
CPSA Foundation Level
• Single Responsibility Prinzip
• Open Closed Prinzip
• Liskov Substitutionsprinzip
• Interface Segregation
• Dependency Inversion
SOLID Prinzipien
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
41 von 95
CPSA Foundation Level
• Jeder Baustein soll nur eine fest definierte Aufgabe erfüllen
• In einem Baustein sollten lediglich Funktionen vorhanden sein, die direkt zur Erfüllung dieser Aufgabe
beitragen.
• Vorteile:
• Bessere Änderbarkeit, bessere Wartbarkeit
• Erhöhung der Chance auf Mehrfachverwendung
• Regeln zur Umsetzung des Prinzips:
• Kohäsion erhöhen
• Kopplung verringern
Prinzip einer einzigen Verantwortung
Single Responsibility Prinzip
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
42 von 95
CPSA Foundation Level
• Geschlossen für Änderung
• Einmal festgelegte Schnittstelle ist unveränderlich
• Erfordert Definition von Erweiterungspunkten
• Offen für Erweiterung
• Erweiterung geschieht in abgeleiteten Bausteinen
• Abgeleitete Bausteine enthalten nur die Erweiterungen
• Reduziert die Auswirkungen von Änderungen
Offen Geschlossen Prinzip
Softwarebausteine sollen offen für Erweiterung sein,
aber geschlossen für Änderungen.
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
43 von 95
https://www.elbisch.ch/2018/10/25/solid-open-closed-principle/
CPSA Foundation Level
• Eine abgeleitete Klasse sollte
• Überall verwendet werden können, wo ihre Oberklasse verwendet
wird
• Sich genauso verhalten, wie die Oberklasse, wenn sie als solche
verwendet wird.
• Klassen, die das LSP nicht erfüllen, verwenden Vererbung
wahrscheinlich fehlerhaft und ändern die Aufrufsemantik.
• Indiz für Qualität für fachlichen Abstraktion
Liskov Substitutionsprinzip
Subtypen müssen anstelle ihrer Obertypen verwendet
werden können.
nach Barbara Liskov
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
44 von 95
https://medium.com/@bart.jacobs/liskov-substitution-
principle-a-misnomer-3a891c29d359
CPSA Foundation Level
• Bei vielfacher Nutzung einer umfangreichen Schnittstelle
• Zerlegung nach semantischem Zusammenhang
• Zerlegung nach Verantwortungsbereich
• Zerlegung in Einzelschnittstellen reduziert Anzahl abhängiger Nutzer und damit Folgeänderungen
• Kleine, fokussierte Schnittstellen sind leichter implementierbar
• Abhängigkeiten durch Schnittstellen auflösen
Interface Segregation
Mehrere spezifische Schnittstellen sind besser als
eine große Universalschnittstelle.
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
45 von 95
CPSA Foundation Level
• Gemeinsame Merkmale sollen in einer
gemeinsamen Schnittstelle abstrahiert werden
• Nicht zu verwechseln mit: Inversion of Control
(Umkehr des Kontrollflusses)
• Hollywood Prinzip: „Don’t call us, we’ll call you”
• Dependency Injection: Spezielle Ausprägung des
Inversion of Control Prinzips
Dependency Inversion
1. Module hoher Ebenen sollten nicht von Modulen niedriger
Ebenen abhängen. Beide sollten von Abstraktionen abhängen.
2. Abstraktionen sollten nicht von Details abhängen. Details sollten
von Abstraktionen abhängen.
Entwurf und Entwicklung /
Architekturen entwerfen/ Entwurfsprinzipien
46 von 95
https://en.wikipedia.org/wiki/Dependency_inversion_principle
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Architektur- und Entwurfsmuster
• Methoden beim Architekturentwurf
Entwurf und Entwicklung von Softwarearchitekturen
47 von 95
CPSA Foundation Level
Symptome von degeneriertem Design
Zerbrechlich
• Änderungen an einer
Stelle führen zu
unvorhergesehenen
Fehlern an anderer Stelle
Starr
• Modifikationen sind
schwierig
• Betreffen eine Vielzahl an
abhängigen Komponenten
Schlechte
Wiederverwendung
• Komponenten können
aufgrund zu vieler
Abhängigkeiten nicht
einzeln wiederverwendet
werden
Degeneriertes
Design
Entwurf und Entwicklung /
Architekturen entwerfen/ Umgang mit Abhängigkeiten
48 von 95
CPSA Foundation Level
• Schlüssel zu flexiblen, erweiterbaren Architekturen
• Verbieten von direkten Abhängigkeiten erlaubt Austauschbarkeit
von Bausteinen
• Konsequente Umsetzung des Offen Geschlossen Prinzips
Abhängigkeit nur von Abstraktionen
Erlauben Sie Abhängigkeiten nur von Abstraktionen,
nicht von konkreten Implementierungen.
Entwurf und Entwicklung /
Architekturen entwerfen/ Umgang mit Abhängigkeiten
49 von 95
CPSA Foundation Level
• Zyklische Abhängigkeiten verhindern getrennte Wiederverwendung
Zyklische Abhängigkeiten auflösen
A B
C
A B
C
CA
1. Aus A diejenigen Teile als Abstraktion CA heraustrennen,
die von C genutzt werden.
2. Auflösung geschieht durch Vererbungsbeziehung von
A zur Abstraktion CA
Entwurf und Entwicklung /
Architekturen entwerfen/ Umgang mit Abhängigkeiten
50 von 95
CPSA Foundation Level
• Beschreiben Lösungen für wiederkehrende Probleme
• Sind anwendbar auf unterschiedliche Systemstrukturen (Klassen, Komponenten, etc.)
• Werden nicht entwickelt sondern meistens per Zufall entdeckt
• Bieten Vorlagen für:
• Vorgehen bei der Zerlegung eines Systems
• Verteilen von Verantwortlichkeiten innerhalb eines Systems
Möglichkeiten zur Auflösung von Kopplung: Nutzung von
Muster
Entwurf und Entwicklung /
Architekturen entwerfen/ Umgang mit Abhängigkeiten
51 von 95
CPSA Foundation Level
• Hierarchische Architekturstile:
• z.B. Layer
• Sprachunabhängige Muster
• z.B. Adapter, Facade, Plugin, Broker, Observer
• Erzeugungsmuster
• z.B. Factory, Dependency Injection
• Datenfluss Muster:
• z.B Pipes & Filter
• Messaging, Events, Commands
• z.B. Publish-Subscribe
• Stability Muster
• z.B. Bulkhead, Timeout, Circuit Breaker
Möglichkeiten zur Auflösung von Kopplung: Nutzung von
Muster
Entwurf und Entwicklung /
Architekturen entwerfen/ Umgang mit Abhängigkeiten
52 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf
Entwurf und Entwicklung von Softwarearchitekturen
53 von 95
CPSA Foundation Level
• Strukturiert das System in aufeinander aufbauenden
Diensten
• Abstraktionsgrad steigt mit der Anzahl darunter liegender
Schichten
• Dienstnutzung findet nur zwischen direkt aufeinander
aufbauenden Schichten statt
• Dienstnutzung erfolgt gerichtet von der höheren Schicht
aus (Kommunikation erfolgt in beide Richtungen)
• Die umgekehrte Richtung oder das „Durchgreifen“ durch
eine Zwischenschicht sollte nur in begründeten
Ausnahmefällen erlaubt werden
Hierarchische Architekturstile
Schichten (Layer) Highest level
of abstraction
Lowest level
of abstraction
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
54 von 95
CPSA Foundation Level
Vorteile
• Schichten sind unabhängig
• In der Entwicklung (Arbeitsteilung)
• Im Betrieb
(Installation, Wartung)
• Implementierungen sind austauschbar
• Reduziert die Menge möglicher
Abhängigkeiten zwischen Komponenten
• Leicht verständliches Konzept
Nachteile
• Overhead, wenn Schichten für die Erbringung
bestimmter Dienste lediglich an die
Folgeschicht durchreichen
• Umgehbar, wenn Überspringen von Schichten
gezielt erlaubt
• Erhöht Abhängigkeiten
• Änderungen wie das Hinzufügen eines
Datenfelds ziehen sich vertikal durch alle
Schichten
Hierarchische Architekturstile
Schichten: Vor- und Nachteile
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster 55 von 95
CPSA Foundation Level
Hierarchische Architekturstile
Schichten: Übliche Untergliederung
Präsentationsschicht
Applikationsschicht
Fachdomäne
Infrastruktur
 Bedienelemente
 (Teil-) Ansichten der Fachdomäne
 Koordination von Fachobjekten
 Delegation an Fachdomäne / Infrastruktur
 Fachliche Aspekte: Datentypen, Verarbeitungsregeln, etc.
 Kapselt Komplexität der Infrastruktur
 Kann weiter untergliedert sein
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
56 von 95
CPSA Foundation Level
• Aspekte der Fachdomäne sollten nie in der Präsentationsschicht behandelt werden
• Negative Auswirkung auf Wartbarkeit
• Reduziert Wiederverwendbarkeit
• Schichten sind keine „Tiers“.
• „n-Tier-System“ spiegeln die physische Verteilung von Komponenten auf miteinander verbundene
Infrastruktur wieder
• Eine logische Schicht kann über mehrere Tiers verteilt sein, ein Tier kann mehrere logische Schichten
beherbergen
Hierarchische Architekturstile
Schichten: Anmerkungen
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
57 von 95
CPSA Foundation Level
• „to adapt“ (englisch) =„an-, einpassen“
• Auch bekannt als Wrapper (= Umwickler)
• Problemstellung:
• Zwei Klassen können wegen inkompatibler
Schnittstellen nicht zusammenarbeiten
• Adapter bewirkt Schnittstellen-Anpassung
Sprachunabhängige Muster
Adapter
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
58 von 95
CPSA Foundation Level
• Bietet vereinfachte Schnittstelle zu einer
Menge von Schnittstellen eines Subsystems
• Nützlich wenn Subsystem viele technisch
orientierte Klassen enthält, die selten von
außen verwendet werden
• Enthält eine häufig benötigte Untermenge an
Funktionalität des Subsystems
• Delegiert die Funktionalität an andere Klassen
des Subsystems
Sprachunabhängige Muster
Fassade
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
59 von 95
CPSA Foundation Level
• Zur Erweiterung der Funktionalität einer Klasse zur Laufzeit
• Wird an zuvor definiertem Erweiterungspunkt („extension point“) eingebunden
• Plugin-Klasse implementiert ein von der zu erweiternden Klasse vorgegebenes Interface,
über das das Plugin aufgerufen wird
• Folgt dem Prinzip der Umkehr von Abhängigkeiten
Sprachunabhängige Muster
Plugin
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
60 von 95
CPSA Foundation Level
Sprachunabhängige Muster
Broker
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
61 von 95
CPSA Foundation Level
• Server-Proxy
• Ruft Dienste des Servers auf
• Kapselt systemspezifische Funktionalität
• Vermittelt zwischen Server und Broker
• Bridge
• Kapselt netzwerkspezifische Funktionalität
• Vermittelt zwischen lokalen Broker und
Bridge eines entfernten Brokers
• Broker
• Lokalisiert und verwaltet Server
• Leitet Messages weiter
• Behandelt Fehler
• Stellt APIs zur Verfügung
• Client
• Implementiert Funktionalität auf User-
Seite
• Sendet Requests über Client-Proxy
• Server
• Implementiert die Services
• Registriert sich beim jeweiligen Broker
• Sendet Responses über Server-Proxy
• Client-Proxy
• Kapselt systemspezifische Funktionalität
• Vermittelt zwischen Client und Broker
Sprachunabhängige Muster
Broker
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
62 von 95
CPSA Foundation Level
• Subject weiß über Observer nur, dass sie das
Interface Observer implementieren
• Keine feste Bindung zwischen Observer und
Subject
• Änderungen haben keinen Einfluss auf den
anderen
• Beide können unabhängig voneinander
wiederverwendet werden
Sprachunabhängige Muster
Observer
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
63 von 95
CPSA Foundation Level
Erzeugungsmuster
Factory
• Ziele
• Geringere Kopplung
• Hohe Kohäsion
• Konkreter Erzeuger
• erbt die Fabrikmethode von Erzeuger
• implementiert sie so, dass
sie KonkretesProdukt erzeugt
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
64 von 95
CPSA Foundation Level
Erzeugungsmuster
Dependency Injection
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
65 von 95
CPSA Foundation Level
• Model
• enthält darstellbare Informationen
• View
• liest Informationen aus dem Modell und erzeugt auf Grundlage
dieser eine Darstellung
• Controller
• Nimmt Benutzer- und Systemereignisse (Eingaben) entgegen und
leitet diese bereinigt und normalisiert an das Model weiter
• Ein Modell kann von beliebig vielen View-/Controller-Paaren
verwendet werden.
• Erlaubt mehrere Sichten auf das selbe Modell
Muster für interaktionsorientierte Systeme
Model-View-Controller
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
66 von 95
CPSA Foundation Level
• Strukturierung von großen Systemen in fachliche
Einheiten
• Jeder Microservice soll eine eigene fachliche Einheit
repräsentieren
• Diese Microservices sind weitgehend entkoppelt und
laufen selbstständig
• Sprachunabhängige Kommunikation untereinander
• Werden parallel entwickelt und unabhängig von
einander deployed
• Fördert eine flexible Architektur
Muster für verteilte Systeme und deren Integration
Microservices
Anwendungslogik setzt sich aus mehreren
Microservices zusammen
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
67 von 95
CPSA Foundation Level
Datenfluss Muster
Pipes & Filter
• Typisches Anwendungsfeld
• Einzelne Phasen von Compilern
• Lexer, Parser und Codegeneratoren als Filter
• Digitale Signalverarbeitung
• Bilderfassung, Farbkorrektur, Bildeffekte, Kompression als Filter
• Multimedia lesen, Audio/Video trennen, Dekodieren, Hardwareausgabe
Entwurf und Entwicklung /
Architekturen entwerfen/ Architektur- und Entwurfsmuster
68 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Architektur- und Entwurfsmuster
• Methoden beim Architekturentwurf
Entwurf und Entwicklung von Softwarearchitekturen
69 von 95
CPSA Foundation Level
• Ein Querschnittsaspekt ist eine Anforderung an ein Softwareprodukt, die
systemübergreifend einzuhalten oder umzusetzen ist
• Beispiele sind Fehlerbehandlung, Logging, Tracing und Sicherheit
• Typischerweise gehören sie nicht zur Kernfunktionalität der Software, sondern
stellen Zusatz- oder Metaanforderungen dar
Querschnittliche Konzepte
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
70 von 95
CPSA Foundation Level
• Form
• Kann vielfältig sein
• Konzeptpapiere mit beliebiger Gliederung
• Übergreifende Modelle oder Szenarien
• Implementierung durch einzelne oder mehrere Bausteine
• Ein Querschnittskonzept kann Anforderungen an die Implementierung mehrerer Bausteine
stellen
• Querschnittskonzepte sollen explizit dokumentiert werden und systemübergreifend
wiederverwendbar sein
Querschnittliche Konzepte
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
71 von 95
CPSA Foundation Level
• Daten aus dem Hauptspeicher auf ein beständiges Medium bringen
• Flüchtige Speichermedien nicht für dauerhafte Speicherung ausgelegt
• Menge der Daten übersteigt oft die Kapazität des Hauptspeichers
• Entkopplung von Fachdomäne und (Datenbank-) Infrastruktur
Persistenz
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
72 von 95
CPSA Foundation Level
• Benutzungsoberfläche
• Notwendig für IT-Systeme, die interaktiv genutzt werden
• Sowohl grafisch als auch textuell
• Ergonomie
• Verbesserung/Optimierung der Benutzbarkeit
• Betrifft:
• Benutzungsoberfläche
• Reaktivität (gefühlte Performance)
• Verfügbarkeit
• Robustheit
Benutzungsoberfläche & Ergonomie
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
73 von 95
CPSA Foundation Level
• Vorhersehbare und angemessene Reaktionen definieren
• Kategorien und Schweregrad unterscheiden
• fachliche und technische Fehler unterscheiden
• Auswirkungen von Fehlern minimieren
• Diagnose von Fehlerursachen erleichtern
• Was ging schief?
• Wo ist es passiert?
• Warum ging es schief?
• Fehlerprävention
• Frühzeitig vor erkennbaren Gefahren warnen
• Verarbeitungstoleranzen erlauben
Fehlerbehandlung
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
74 von 95
CPSA Foundation Level
• Authentifizierung (authentication)
• Feststellung der Absenderidentität
• Autorisierung (authorization)
• Einräumung von Nutzungsrechten anhand der Identität
• Integrität (integrity)
• Erkennung der Manipulationen von gesicherten Daten
• Vertraulichkeit (confidentiality)
• Daten unzugänglich für Unbefugte übertragen und speichern
• Unleugbarkeit (non-repudiation)
• Eingegangene Nachrichten können nicht vom Sender abgestritten werden
• Verfügbarkeit (availabilty)
• Maßnahmen gegen unvorhergesehene oder mutwillige Systemstörung
Sicherheit
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
75 von 95
CPSA Foundation Level
• Schrittweise verlaufende Steuerung
• Ablaufsteuerung von IT-Systemen
• Sichtbare Abläufe an der grafischen Oberfläche
• Steuerung der Hintergrundaktivitäten
• Darstellung von Ablaufketten
• Zustandsdiagramme
• Sequential Function Chart
Ablaufsteuerung
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
76 von 95
CPSA Foundation Level
• Domänenspezifische Kausalzusammenhänge oder
bedingte Handlungsanweisungen („wenn…, dann…“)
• Komplexität der Regeln macht Quellcode unübersichtlich
• Quellcode als Definitionsort erschwert einfache Änderung
• Verteilung der Regeln über das gesamte System verhindert das Abschätzen der Auswirkungen von
Änderungen
• Explizit und zentralisiert deklarieren
Geschäftsregeln
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
77 von 95
CPSA Foundation Level
• Bestandteile der Softwaresysteme laufen auf unterschiedlichen und eventuell physikalisch
getrennten Rechnersystemen ab
• Übertragung der Daten an verteilte Kommunikationspartner
• Aufruf entfernter Methoden
• Remote procedure call, RPC
• Wahl passender Interaktionsstile oder Nachrichtenaustauschmuster
• Synchron/Asynchron
• Peer-to-peer
Verteilung
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
78 von 95
CPSA Foundation Level
Internationalisierung
Formatierung Währung
Kulturelle
Unterschiede
Maskenlayout
Beschriftungen Dokumentation Fehlertexte Tastenkürzel
Datum,
Uhrzeit,
Zeitzone
Zeichensätze
Anwendungs-
logik
Technische
Einheiten
Entwurf und Entwicklung /
Architekturen entwerfen/ Übergreifende technische Konzepte
79 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Architektur- und Entwurfsmuster
• Methoden beim Architekturentwurf
Entwurf und Entwicklung von Softwarearchitekturen
80 von 95
CPSA Foundation Level
Request-Response
• Ressourcenorientiert
• Serviceorientiert
(async.) Messaging
Shared Database
Filetransfer
• Schnittstellen
• anderer Systeme
• für andere Systeme
• Datenschnittstelle
• Funktionale Schnittstelle
• Synchron oder asynchron
• Performance
Wünschenswerte Eigenschaften:
• Einfach zu erlernen
• Einfach zu benutzen
• Einfach zu erweitern
• Schwer zu missbrauchen
• Funktional vollständig aus Sicht der Nutzer
Schnittstellen
---------------
---------------
---------
Need
Have
SPI
Provider
<<implements>>
Entwurf und Entwicklung /
Architekturen entwerfen/ Schnittstellen entwerfen und festlegen
81 von 95
CPSA Foundation Level
• Unterschiedliche Betrachtungsweisen / Architekturstile
• Ressourcenorientierter Ansatz
• REST (REpresentational State Transfer)
• Geschäftsobjekte werden als Web-Ressourcen adressiert
→ URI via HTTP(S)
• Verschiedene Repräsentationen / Formate (content types)
• Einheitliche Schnittstellendefinition → HTTP-Methoden (verbs)
• Service-orientierter Ansatz
• XML (WS-*, WSDL, SOAP)
• Methodenaufrufe werden in Nachrichtenpaketen geroutet
→ SOAP via HTTP(S)
• Spezifische Schnittstellendefinitionen für Geschäftsfunktionen
Betrachtungsweisen von Schnittstellen
Entwurf und Entwicklung /
Architekturen entwerfen/ Schnittstellen entwerfen und festlegen
82 von 95
CPSA Foundation Level
“sei streng bei dem was du tust und offen bei dem was
du von anderen akzeptierst.”
• Implementierungen sollen sich möglichst eng an bestehende Empfehlungen und Standards
halten, ohne diese Vorgehensweise von anderen Beteiligten zu erwarten
• Eingaben sollen weiterhin auf Fehlerhaftigkeit geprüft werden ohne zu Fehlern beim Empfänger
zu führen
• Softwaresysteme, die Nachrichten empfangen, sollten unvollkommene Eingaben akzeptieren,
solange die Bedeutung klar ist
• Die Einhaltung von Postel’s Law fördert die Robustheit des Systems aber kostet
Implementierungsauwand und verbirgt Risiken
Entwurf externer Schnittstellen
Robustheitsgrundsatz– Postel’s Law
Jonathan Bruce
Postel (1943 - 1998),
American computer scientist
http://www.postel.org/pr.htm
Entwurf und Entwicklung /
Architekturen entwerfen/ Schnittstellen entwerfen und festlegen
83 von 95
CPSA Foundation Level
• Vorgehensweisen beim Architekturentwurf
• Einflussfaktoren und Randbedingungen
• Architekturen entwerfen
• Entwurfsprinzipien
• Umgang mit Abhängigkeiten
• Architektur- und Entwurfsmuster
• Übergreifende technische Konzepte
• Schnittstellen entwerfen und festlegen
• Methoden beim Architekturentwurf (Exkurs DDD)
Entwurf und Entwicklung von Softwarearchitekturen
84 von 95
CPSA Foundation Level
• Sammlung von Entwurfsmustern
• Strukturierung von größeren Systemen nach Fachlichkeiten
• Jedes Subsystem soll eine eigene fachliche Einheit bilden
• Bei Änderungen oder neuen Features muss nur ein Subsystem geändert werden
• Parallelisierung der Entwicklung ohne großen Koordinierungsaufwand
• Im DDD kann ein System in folgende Domänen unterteilt werden:
• Core-Domain
• Generic-Domain
• Supporting-Domain
Domain-Driven Design (DDD)
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
85 von 95
CPSA Foundation Level
Core Domain
• Kernfunktionalität des
Systems
• Der Grund für die Existenz
des Systems
• Möglichst die erfahrensten
Entwickler einsetzen
Generic Subdomain
• Enthält Funktionalität, die
wichtig für das Geschäft ist,
aber nicht Teil der Core
Domain
• z.B.: Rechnungen
erstellen oder Briefe
versenden.
• Kann hinzugekauft oder
outgesourced werden
Supporting Subdomain
• Enthält unterstützende und
untergeordnete
Funktionalität
• Kann von weniger
erfahrenen Entwicklern
übernommen werden
• Sollte streng von der Core-
Domain getrennt werden
• z.B.: durch Anti-
Corruption-Layer
Arten von Domänen
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
86 von 95
CPSA Foundation Level
• Strukturierung auf rein fachlicher Basis
• Entwurf eines projektweit akzeptierten Domänenmodells
• Verbessert Kommunikation zwischen Fachexperten und Entwicklern
• Erlaubt Fachexperten präzisere Formulierung von Anforderungen
• Entstehung einer gemeinsamen, domänenspezifischen Sprache
• Ubiquitous Language
Fachmodelle als Basis
Beginnen Sie Ihren Entwurf mit der Strukturierung der Fachdomäne
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
87 von 95
CPSA Foundation Level
• Zentrales Konzept des Domain-driven Designs
• Alle Projektmitglieder nutzen dieselben Begriffe wie die
Domänenexperten
• z.B. im Quellcode, in Datenbanken -> keine Übersetzungen
• Software soll nur die wesentlichen Elemente und Strukturen der
Domäne enthalten
• Geschäftsfunktionen
• Geschäftsprozesse
• Geschäftsobjekte
Allgemeingültige Sprache
Ubiquitous Language
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
88 von 95
CPSA Foundation Level
Bausteine eines Domänenmodells
Ubiquitous Language
Entities
Value
Objects
Services Module
Aggregates Factories Repositories
Das Modell im Code darstellen
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
89 von 95
CPSA Foundation Level
Entities
• Unveränderliche Identität (Schlüssel)
• Definierter Lebenszyklus
• Sind persistent
Value Objects
• Keine eigene Identität
• Transportieren den Zustand anderer
Objekte
• Enthalten keine Entitäten
Services
• Abläufe oder Prozesse in der
Fachdomäne
• Operationen ohne eigenen Zustand
• Ein- und Ausgaben der Operationen
sind Domänenobjekte
Aggregate
• Kapselt vernetzte Domänenobjekte
• Besitzt genau ein Wurzelobjekt
• Extern darf nur die Wurzel referenziert
werden
Factories
• Kapselt nicht-triviale Konstruktion
komplexer Objektstrukturen
• Kein Zugriff auf andere Schichten,
dient ausschließlich der Konstruktion
Repositories
• Bietet Möglichkeiten Objektreferenzen
dauerhaft zu erhalten
• Kapselt die dazu nötigen
Infrastrukturaufrufe
• Insbesondere für Entitäten
Module
• Teilen das Domänenmodell in fachliche
(nicht technische) Bestandteile
• Sind gekennzeichnet durch starke
innere Kohäsion und
geringe Kopplung zwischen den
Modulen
Systematische Verwaltung der Domänenobjekte
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
90 von 95
CPSA Foundation Level
• Zerlegung nach Fachobjekten, wenn
• Wiederverwendung wichtig ist
• die Fachlogik komplex, umfangreich oder flexibel ist
• objektorientiertes Paradigma gut verstanden ist
• Strukturierung nach Benutzertransaktionen, bei
• simpler Datenbeschaffung und einfachen Operationen darauf
• Integration von Fremdsystemen
• einfacher oder wenig umfangreicher Fachlogik
• wenig Erfahrung mit objektorientierten Vorgehensweisen
Strukturierung der Fachdomäne
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
91 von 95
CPSA Foundation Level
• Published Language
• Gemeinsame Sprache zwischen zwei Domänen, über die sie interagieren können.
• z.B.: XML-Schema
• Open Host Service
• Domäne spezifiziert Protokoll, über das andere Domänen diese Nutzen können
• z.B.: RESTful web service
• Anti-Corruption-Layer
• Nutzt Services einer anderen Domäne unter Verwendung einer Isolationsschicht
• Seperate Ways
• Zwei Domänen sind vollständig getrennt und haben keine Integration.
Integration von Domänen
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
92 von 95
CPSA Foundation Level
Systematischer Entwurf
Wo stehen wir jetzt?
Risiken
identifizieren
Strukturen und technische
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
Entwurf und Entwicklung /
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
93 von 95
CPSA Foundation Level
• [Gharbi+2020] Gharbi, M., Koschel, A., Rausch, A., Starke, G.: Basiswissen für
Softwarearchitekten. 4., überarbeitete und aktualisierte Auflage, dpunkt.verlag, 2020
• [Starke2020] Starke, G.: Effektive Software-Architekturen. 9., überarbeitete Auflage, Carl Hanser
Verlag, 2020
• [Clements+2010] Clements, P. et al.: Documenting Software Architectures. 2., überarbeitete
Auflage, Addison-Wesley, 2010
• [Reussner+2008] Reussner, R., Hasselbring, W. (Hrsg.): Handbuch der Software-Architektur. 2.,
überarbeitete und erweiterte Auflage, dpunkt.verlag, 2008
• [Parnas1972] Parnas, D.: On the criteria to be used in decomposing systems into modules.
Volume 15 Issue12, Pages 1053-1058, Communications of the ACM, CACM Homepage archive,
1972
Referenzen (1)
Entwurf und Entwicklung /
Referenzen
94 von 95
CPSA Foundation Level
• [Fowler2003] Fowler, M.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2002
• [Martin2013] Martin, R. C.: Agile Software Development: Principles, Patterns and Practices. Pearson, 2013
• [Buschmann+1996] Buschmann, F., Meunier, R., Rohner, H., Sommerlad, P.: Pattern-Oriented Software
Architecture. Volume 1: A System of Patterns. John Wiley & Sons, 1996
• [Buschmann+2007] Buschmann, F., Henney, K., Schmidt, D.: Pattern-Oriented Software Architecture
Volume 4: A Pattern Language for Distributed Computing. John Wiley & Sons, 2007
• [Hofmeister+2000] Hofmeister, C., Nord, R., Soni, D.: Applied Software Architecture. Addison-Wesley
Professional, 1999
• [Douglass2002] Douglass, Bruce Powel: Real-Time Design Patterns. Addison-Wesley Longman, 2002
Referenzen (2)
Entwurf und Entwicklung /
Referenzen
95 von 95

Weitere ähnliche Inhalte

Ähnlich wie 02_Entwurf_Entwicklung_v7.0.pdf

Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
Kenner Soft Service GmbH
 
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
Lena Königsberger
 
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ..."Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
Bernhard Schimunek
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
QAware GmbH
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Aarno Aukia
 
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
IKS Gesellschaft für Informations- und Kommunikationssysteme mbH
 
Wjax Vortrag 2018: Von DevOps bis DesignThinking
Wjax Vortrag 2018: Von DevOps bis DesignThinkingWjax Vortrag 2018: Von DevOps bis DesignThinking
Wjax Vortrag 2018: Von DevOps bis DesignThinking
Annegret Junker
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Virtual Forge
 
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Community ITmitte.de
 
Agil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
Agil zum Ziel: Erfolgsfaktoren für agile IT-GroßprojekteAgil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
Agil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
QAware GmbH
 
Optimierte Vorgehensweisen für Intranet-Projekte [DE]
Optimierte Vorgehensweisen für Intranet-Projekte [DE]Optimierte Vorgehensweisen für Intranet-Projekte [DE]
Optimierte Vorgehensweisen für Intranet-Projekte [DE]
Stephan Schillerwein
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
Eduard van den Bongard
 
Certified Professional for Software Architecture - Advanced Level
Certified Professional for Software Architecture - Advanced LevelCertified Professional for Software Architecture - Advanced Level
Certified Professional for Software Architecture - Advanced Level
FutureNetworkCert
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
FotiosKaramitsos
 
IT Service Management mit ITIL
IT Service Management mit ITILIT Service Management mit ITIL
IT Service Management mit ITIL
Hendrik Kalb
 
Lean Development / Standardisierte Software-Entwicklung
Lean Development / Standardisierte Software-EntwicklungLean Development / Standardisierte Software-Entwicklung
Lean Development / Standardisierte Software-Entwicklung
SuperB2
 
The new job of qa was ein quality engineer zukünftig können muss
The new job of qa   was ein quality engineer zukünftig können mussThe new job of qa   was ein quality engineer zukünftig können muss
The new job of qa was ein quality engineer zukünftig können muss
raezz
 
ONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur AppONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur App
Netcetera
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
Dennis Wilson
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?
IBsolution GmbH
 

Ähnlich wie 02_Entwurf_Entwicklung_v7.0.pdf (20)

Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
 
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
Welche Prototyping-Methode passt zu meinen Anforderungen? – World Usability D...
 
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ..."Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
"Erfolgreiche Strategien zur Migration veralteter Software" Präsentation vom ...
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die CloudApplikationsmodernisierung: Der Weg von Legacy in die Cloud
Applikationsmodernisierung: Der Weg von Legacy in die Cloud
 
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
Softwarequalität: Definitionen, Grenzen, Wünsche - Vortrag IKS-Meeting im Jan...
 
Wjax Vortrag 2018: Von DevOps bis DesignThinking
Wjax Vortrag 2018: Von DevOps bis DesignThinkingWjax Vortrag 2018: Von DevOps bis DesignThinking
Wjax Vortrag 2018: Von DevOps bis DesignThinking
 
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
Case Study: Automatisierte Code Reviews in einer gewachsenen SAP-Applikations...
 
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Pa...
 
Agil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
Agil zum Ziel: Erfolgsfaktoren für agile IT-GroßprojekteAgil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
Agil zum Ziel: Erfolgsfaktoren für agile IT-Großprojekte
 
Optimierte Vorgehensweisen für Intranet-Projekte [DE]
Optimierte Vorgehensweisen für Intranet-Projekte [DE]Optimierte Vorgehensweisen für Intranet-Projekte [DE]
Optimierte Vorgehensweisen für Intranet-Projekte [DE]
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 
Certified Professional for Software Architecture - Advanced Level
Certified Professional for Software Architecture - Advanced LevelCertified Professional for Software Architecture - Advanced Level
Certified Professional for Software Architecture - Advanced Level
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
 
IT Service Management mit ITIL
IT Service Management mit ITILIT Service Management mit ITIL
IT Service Management mit ITIL
 
Lean Development / Standardisierte Software-Entwicklung
Lean Development / Standardisierte Software-EntwicklungLean Development / Standardisierte Software-Entwicklung
Lean Development / Standardisierte Software-Entwicklung
 
The new job of qa was ein quality engineer zukünftig können muss
The new job of qa   was ein quality engineer zukünftig können mussThe new job of qa   was ein quality engineer zukünftig können muss
The new job of qa was ein quality engineer zukünftig können muss
 
ONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur AppONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur App
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?SAP IdM Wartungsende 2027... und was nun?
SAP IdM Wartungsende 2027... und was nun?
 

02_Entwurf_Entwicklung_v7.0.pdf

  • 1. © ITech Progress GmbH Version 7.0 Durchgeführt von unserem Trainingspartner: Entwurf und Entwicklung von Softwarearchitekturen Certified Professional for Software Architecture – Foundation Level (CPSA-F)
  • 2. CPSA Foundation Level • Einführung in das iSAQB Zertifizierungsprogramm • Grundbegriffe • Entwurf und Entwicklung von Softwarearchitekturen • Beschreibung und Kommunikation von Softwarearchitekturen • Softwarearchitektur und Qualität • Beispiele für Softwarearchitekturen Agenda 2 von 95
  • 3. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf (Exkurs DDD) Entwurf und Entwicklung von Softwarearchitekturen 3 von 95
  • 4. CPSA Foundation Level • Architekturen, Organisationen und Systeme beeinflussen sich gegenseitig • Kunden und Projektbeteiligte können Anforderungen und Einflussfaktoren ändern • Architekturentwurf und -entscheidungen sollten iterativ angepasst werden • Verhindert frühzeitig Probleme beim Entwurf • Wünsche und Anforderungen werden frühzeitig mit einbezogen Architekturen entstehen iterativ Kunde Architekturentwurf Umwelt & Projektbeteiligte Einflussfaktoren Anforderungen ändern beeinflussen ändert 4 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 5. CPSA Foundation Level Top-Down und Bottom-Up Top-Down ➢ Zusammenbau von Teillösungen (Synthese) ➢ Ausgangspunkt: Bibliotheken und Teilfunktionen Bottom-Up ➢ Zerlegung in Teilprobleme (Analyse) ➢ Ausgangspunkt: Vision vom Gesamtsystem 5 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 6. CPSA Foundation Level Vorteile • gutes Problemverständnis • maschinen- und sprachunabhängig • kein Verirren in Details • saubere Schnittstellen • Entwurf noch im Produkt erkennbar Nachteile • kritische Integration am Ende • Übersehen von existierenden (Teil-) Lösungen • gravierende Änderungen bei spät erkannten Problemen Top-Down 6 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 7. CPSA Foundation Level Vorteile • hoher Wiederverwendungsgrad • hohe Funktionssicherheit durch inkrementellen Test • schrittweise Integration Nachteile • beginnt mit vermuteten Teilproblemen • Orientierung an technischen Gegebenheiten statt an Benutzeranforderungen • Gefahr der frühzeitigen Optimierung • „wild gewachsene“ Systemstruktur Bottom-Up 7 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 8. CPSA Foundation Level • Modellgetriebene Architekturentwicklung • Modellbasierte Abbildungen bieten insbesondere Vorteile hinsichtlich der Aspekte Abstraktion und Anschaulichkeit • Beschränkung auf kontextrelevanten Sachverhalt • Angemessene grafische Notationen • Sichtenbasierte Architekturentwicklung: • Sichten helfen, die Komplexität einer Architektur zu beherrschen • Rollenspezifische Sichten • Ausblenden von für konkrete Fragestellungen oder Aktivitäten irrelevanter Informationen • Dabei kommen insbesondere Techniken der Modellgetriebenen Softwareentwicklung zum Einsatz • Domain Driven Design • Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit Methoden beim Architekturentwurf 8 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 9. CPSA Foundation Level Systematischer Entwurf Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern 9 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 10. CPSA Foundation Level Systematischer Entwurf Wo stehen wir jetzt? Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern 10 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 11. CPSA Foundation Level Informationen sammeln Informationen Für das Projekt benötigtes Domänenwissen und technisches Hintergrundwissen erarbeiten In der Organisation vorhandene Systeme ermitteln und auf Wiederverwendbarkeit prüfen Von Dritten angebotene Systeme ermitteln, die eine ähnliche Aufgabe oder wenigstens Teile davon erfüllen, wie das zu entwickelnde System Passende technische Literatur für benötigte Lösungsansätze und Vorgehensmuster sichten Systemidee entwickeln 11 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 12. CPSA Foundation Level • Beschreibung der Kernaufgabe des Systems • Festlegung der Art der Steuerung • Ereignisgetrieben (Event driven) • Prozedurale Steuerung • Parallele Steuerung / Nebenläufigkeit • Deklarative oder regelbasierte Steuerung • Beschreibung der Nutzungsart des Systems Systemidee entwickeln 12 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 13. CPSA Foundation Level Interaktives Online-System / operationales System •Geschäftsprozesse •Transaktionen auf aktuellen Organisationsdaten •Hohe Verfügbarkeit und Performanz erforderlich Unterstützendes System •Berechnungen und Analysen •Entscheidungsunterstützung •Lesend auf Kopien der Organisationsdaten •Längere Laufzeiten üblich Hintergrundsystem •Offline- oder Batchsysteme •Zeitversetzte Vor- und Nachbearbeitung von Daten Eingebettetes System •Läuft innerhalb spezieller Hardware und steuert diese Echtzeitsystem •Festgelegte Zeitgarantien für zeitkritische Operationen Nutzungsart des Systems 13 von 95 Entwurf und Entwicklung / Vorgehensweisen beim Architekturentwurf
  • 14. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf (Exkurs DDD) Entwurf und Entwicklung von Softwarearchitekturen 14 von 95
  • 15. CPSA Foundation Level Systematischer Entwurf Wo stehen wir jetzt? Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern 15 von 95 Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen
  • 16. CPSA Foundation Level • Produktbezogene Faktoren • Funktionale Anforderungen (required features) • Nicht-funktionale Anforderungen (required constraints) • Technische und betriebsbedingte Faktoren • Zielplattform, Technologien, Standards, Werkzeuge • Organisatorische / politische Faktoren • Projektplan, Personal, Budget, Offshoring • Trends • Markttrends • Technologietrends Einflussfaktoren und Randbedingungen Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 16 von 95
  • 17. CPSA Foundation Level • Teilen sich auf in die funktionalen und nicht-funktionalen Anforderungen • Funktionale Anforderungen • Beschreiben gewünschte Funktionalitäten (was soll das System tun/können) eines Systems bzw. Produkts, dessen Daten oder Verhalten • Nicht-funktionale Anforderungen • Anforderungen an die Qualität der geforderten Funktionalitäten Produktbezogene Faktoren Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 17 von 95
  • 18. CPSA Foundation Level Technische Faktoren Hardwareinfrastruktur Softwareinfrastruktur Systembetrieb Verfügbarkeit der Laufzeitumgebung Grafische Oberfläche Bibliotheken, Frameworks und Komponenten Programmiersprachen Referenzarchitekturen Analyse- und Entwurfsmethoden Datenstrukturen Programmierschnittstellen Programmiervorgaben Technische Kommunikation Technische Faktoren Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 18 von 95
  • 19. CPSA Foundation Level Organisation und Struktur •Organisationsstruktur des Auftraggebers •Organisationsstruktur des Projektteams •Entscheidungsträger •Partnerschaften / Kooperationen •Verkaufsprodukt oder Eigennutzung Ressourcen •Zeitplan •Funktionsumfang •Release-Plan •Budget •Teammitglieder Organisationsstandards •Vorgehensmodell •Qualitätsstandards •Werkzeuge (Entwicklung, Konfiguration, Versionierung) •Testprozess •Abnahme- und Freigabeprozess Juristische Faktoren •Haftungsfragen •Datenschutz •Nachweispflichten •Internationale Rechtsfragen Organisatorische Faktoren Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 19 von 95
  • 20. CPSA Foundation Level • Global Analysis nach [Hofmeister+2000] • Einflussfaktoren werden in ihrer Gesamtheit betrachtet • Gegenseitige Wechselwirkungen, Konflikte • Wirken sich auf die gesamte Architektur aus • Einflussfaktoren werden langfristig betrachtet • Sie können sich ändern • Ihre Auswirkung kann sich ändern • Können wir diese Änderungen beeinflussen? →Architekturentscheidungen müssen „global“ getroffen werden, um alle Einflussfaktoren in Einklang zu bringen Einflussfaktoren und Randbedingungen Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 20 von 95
  • 21. CPSA Foundation Level Systematischer Entwurf Wo stehen wir jetzt? Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 21 von 95
  • 22. CPSA Foundation Level Typische Risiken Fehlende Priorisierung Enger Zeitplan Eingeschränkte Eignung von Ressourcen Unzureichende Anforderungen Mangelnde Dokumentation Kritische externe Schnittstellen Widersprüche Neue, unerprobte Produkte Verfügbarkeiten der technischen Infrastruktur Eingeschränkte Verfügbarkeit von Fachwissen Hohe Änderungsrate von Anforderungen Eingeschränkte Verfügbarkeit von Ressourcen Mehrdeutigkeit Typische Risiken Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 22 von 95
  • 23. CPSA Foundation Level • Zusammenarbeit mit dem Projektmanagement bei organisatorischen Problemen (Zeit, Budget, Know-how) • Rechtzeitig und offen Hinweise zum Risikomanagement liefern: • alternative Auslieferungsmodelle erarbeiten, um zeitkritische Termine zu entschärfen • Auswirkungen kritischer Anforderungen verdeutlichen und gegebenenfalls neu verhandeln • Priorisierung • Umfang • Qualität • Make-or-Buy Entscheidungen überdenken Strategien gegen organisatorische Risiken Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 23 von 95
  • 24. CPSA Foundation Level • Niemand arbeitet unter hohem Druck produktiver oder schneller • Steigende Fehlerrate und Quick-and-Dirty Lösungen • Einem verspäteten Projekt mehr Mitarbeiter zu geben, macht das Projekt noch später • Murphy‘s Law: zusätzliche Probleme tauchen von allein auf • Schätzungen lieber zu hoch als zu niedrig ansetzen • Sicherheitszuschläge einberechnen • Wenn die Politik nicht mitspielt, wird das System niemals laufen • KISS-Prinzip Wichtige Projekterfahrungen Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 24 von 95
  • 25. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf (Exkurs DDD) Entwurf und Entwicklung von Softwarearchitekturen Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 25 von 95
  • 26. CPSA Foundation Level Systematischer Entwurf Wo stehen wir jetzt? Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern Entwurf und Entwicklung / Einflussfaktoren und Randbedingungen 26 von 95
  • 27. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf (Exkurs DDD) Entwurf und Entwicklung von Softwarearchitekturen 27 von 95
  • 28. CPSA Foundation Level • Ziel: Vom WAS zum WIE • Gliederung des Entwurfsprozesses • Grobentwurf: Gesamtstruktur des Systems (Architektur, Subsysteme, Schnittstellen, …) • Feinentwurf: Detailstruktur des Systems (Komponentenentwurf, Datenstrukturentwurf, …) • Entwurfsprinzipien • Helfen dem Softwarearchitekt beim Entwurf • Repräsentieren bewährte Grundsätze • Behandeln meist folgende Hauptprobleme: • Reduktion der Komplexität • Erhöhung der Flexibilität • Änderbarkeit einer Softwarearchitektur Softwareentwurf Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 28 von 95
  • 29. CPSA Foundation Level • Horizontale Zerlegung in Schichten • bieten klar definierte Schnittstellen • nutzen Dienste darunter liegender Schichten • Vertikale Zerlegung in funktionale Module • Zerlegungskriterium kann fachlicher oder technischer Natur sein • Modularität eines Systems gibt an, inwieweit ein System in jeweils in sich geschlossene Bausteine (Module) zerlegt und gekapselt ist Zerlegung: Divide et impera Die zu lösende Aufgabe wird in immer kleinere Teilaufgaben zerlegt, bis die Komplexität dieser Aufgaben eine beherrschbare Größe erreicht hat. Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 29 von 95
  • 30. CPSA Foundation Level • Bei beiden geht es um Abhängigkeiten: • Kopplung: Abhängigkeiten zwischen Bausteine • Kohäsion: Abhängigkeiten zwischen Funktionen innerhalb eines Bausteins • Ziel: Bündelung und Verkapselung von Abhängigkeiten Kopplung und Kohäsion Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 30 von 95
  • 31. CPSA Foundation Level • Zwei Bausteine, die lose gekoppelt sind, können interagieren, wissen aber sehr wenig voneinander • Wiederverwendung bleibt erhalten • Änderungen wirken sich nur lokal aus Lose Kopplung Hoher Kopplungsgrad Niedriger Kopplungsgrad Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 31 von 95
  • 32. CPSA Foundation Level Kopplung Aufruf Erzeu- gung Daten Zeit Aus- führungs- ort Code Arten von Kopplung •Gleiche Hardware/ Laufzeitumgebung •Gleicher Prozess •Gleiches Netzwerksegment •Direkte Nutzung eines anderen Bausteins •Ein Baustein erzeugt einen anderen •Aufrufparameter •Datenstrukturen •Die zeitliche Abfolge von Bausteinaktivitäten spielt eine Rolle •Gemeinsame Bibliotheken und andere Deployment-Artefakte Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 32 von 95
  • 33. CPSA Foundation Level • Auch Zusammenhangskraft (cohaerere, lat: zusammenhängen) • Ein kohäsives Baustein • Löst ein einziges Problem • Besitzt eine spezifische Menge an stark zusammenhängenden Funktionalitäten • Beispiel: Kohäsive Pakete beherbergen Klassen eines zusammenhängenden Funktionskomplexes • Je höher die Kohäsion, desto stärker zusammenhängend ist die Zuständigkeit eines Bausteins in der Anwendung Hohe Kohäsion Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 33 von 95
  • 34. CPSA Foundation Level Prinzipien bei der Zerlegung Konzeptionelle Integrität Alle Standpunkte betrachten Einfachheit SOLID Prinzipien Wiederverwendung von etablierten und erprobten Strukturen Prinzipien der Zerlegung Stärken und Schwächen ermitteln und bewerten Fehler erwarten Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 34 von 95 Separation of Concerns Information Hiding
  • 35. CPSA Foundation Level • Unterschiedliche Aspekte eines Problems voneinander trennen • Jedes Teilproblem separat für sich behandeln • Zurückzuführen auf das Prinzip „Divide et impera“ • Verantwortlichkeiten sollten auf allen Ebenen des Entwurfs betrachtet werden • von einzelnen Klassen bis hin zu ganzen Systemen • Trennung von fachlichen und technischen Teilen ist besonders wichtig • fachliche Abstraktion wird von technischer Umsetzung getrennt Separation of Concerns Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 35 von 95
  • 36. CPSA Foundation Level • 1972 von David L. Parnas entwickelt [Parnas1972] • Kapseln der Komplexität in Komponenten • Erhöht die Flexibilität • Verbesserte Testbarkeit, Stabilität und Änderbarkeit • Komponenten werden als „Blackbox“ betrachtet • Unterbindung des direkten Zugriffs auf die interne Datenstruktur • Zugriff nur über definierte Schnittstellen • Missachtung der Kapselung führt zu • Ungewollten, schwierigen Abhängigkeiten • Höherer Komplexität Information Hiding Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 36 von 95
  • 37. CPSA Foundation Level • Blackboxes • Zeigen externe Schnittstellen • Beschreiben Funktionalität nach dem Geheimnisprinzip • Information Hiding (=> später) • Whiteboxes • Zeigen innere Struktur, Abhängigkeiten und Arbeitsweisen • Die inneren Bausteine sind wiederum Blackboxes Black- und Whiteboxes lassen sich in hierarchischer Top-Down-Art entwerfen Information Hiding / Blackbox- und Whitebox-Beschreibung Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 37 von 95
  • 38. CPSA Foundation Level Blackbox- und Whitebox: Beispiel https://de.wikipedia.org/wiki/Komponente_(UML) Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 38 von 95
  • 39. CPSA Foundation Level Blackbox Whitebox Externe Schnittstellen Enthaltene Bausteine und deren Abhängigkeiten Qualitätsanforderungen wie Performance Umsetzung der Qualitätsanforderungen Integrationsaspekte mit anderen Bausteine Integrationsaspekte der enthaltenen Bausteine Erfüllung funktionale Anforderungen Code Struktur Datenformate und Signatur der externen Schnittstellen Entwurfsentscheidungen über enthaltene Bausteine wie Einsatz von Patterns Verantwortlichkeit Begründung des Entwurfs (interne Zerlegung) Blackbox- und Whitebox Aspekte: Beispiele Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 39 von 95
  • 40. CPSA Foundation Level • Verfeinerung sollte redundanzfrei erfolgen • Bei starker Abhängigkeit zweier Blackbox- Bausteine: • Whitebox-Darstellungen in einem gemeinsamen Diagramm • Prüfen, ob statt eigenen Bausteinen bestehende Bausteine wiederverwendet werden können Information Hiding / Hierarchische Verfeinerung verfeinert verfeinert verfeinert System (Whitebox) (Whitebox) (Whitebox) Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 40 von 95
  • 41. CPSA Foundation Level • Single Responsibility Prinzip • Open Closed Prinzip • Liskov Substitutionsprinzip • Interface Segregation • Dependency Inversion SOLID Prinzipien Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 41 von 95
  • 42. CPSA Foundation Level • Jeder Baustein soll nur eine fest definierte Aufgabe erfüllen • In einem Baustein sollten lediglich Funktionen vorhanden sein, die direkt zur Erfüllung dieser Aufgabe beitragen. • Vorteile: • Bessere Änderbarkeit, bessere Wartbarkeit • Erhöhung der Chance auf Mehrfachverwendung • Regeln zur Umsetzung des Prinzips: • Kohäsion erhöhen • Kopplung verringern Prinzip einer einzigen Verantwortung Single Responsibility Prinzip Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 42 von 95
  • 43. CPSA Foundation Level • Geschlossen für Änderung • Einmal festgelegte Schnittstelle ist unveränderlich • Erfordert Definition von Erweiterungspunkten • Offen für Erweiterung • Erweiterung geschieht in abgeleiteten Bausteinen • Abgeleitete Bausteine enthalten nur die Erweiterungen • Reduziert die Auswirkungen von Änderungen Offen Geschlossen Prinzip Softwarebausteine sollen offen für Erweiterung sein, aber geschlossen für Änderungen. Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 43 von 95 https://www.elbisch.ch/2018/10/25/solid-open-closed-principle/
  • 44. CPSA Foundation Level • Eine abgeleitete Klasse sollte • Überall verwendet werden können, wo ihre Oberklasse verwendet wird • Sich genauso verhalten, wie die Oberklasse, wenn sie als solche verwendet wird. • Klassen, die das LSP nicht erfüllen, verwenden Vererbung wahrscheinlich fehlerhaft und ändern die Aufrufsemantik. • Indiz für Qualität für fachlichen Abstraktion Liskov Substitutionsprinzip Subtypen müssen anstelle ihrer Obertypen verwendet werden können. nach Barbara Liskov Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 44 von 95 https://medium.com/@bart.jacobs/liskov-substitution- principle-a-misnomer-3a891c29d359
  • 45. CPSA Foundation Level • Bei vielfacher Nutzung einer umfangreichen Schnittstelle • Zerlegung nach semantischem Zusammenhang • Zerlegung nach Verantwortungsbereich • Zerlegung in Einzelschnittstellen reduziert Anzahl abhängiger Nutzer und damit Folgeänderungen • Kleine, fokussierte Schnittstellen sind leichter implementierbar • Abhängigkeiten durch Schnittstellen auflösen Interface Segregation Mehrere spezifische Schnittstellen sind besser als eine große Universalschnittstelle. Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 45 von 95
  • 46. CPSA Foundation Level • Gemeinsame Merkmale sollen in einer gemeinsamen Schnittstelle abstrahiert werden • Nicht zu verwechseln mit: Inversion of Control (Umkehr des Kontrollflusses) • Hollywood Prinzip: „Don’t call us, we’ll call you” • Dependency Injection: Spezielle Ausprägung des Inversion of Control Prinzips Dependency Inversion 1. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen. 2. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen. Entwurf und Entwicklung / Architekturen entwerfen/ Entwurfsprinzipien 46 von 95 https://en.wikipedia.org/wiki/Dependency_inversion_principle
  • 47. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Architektur- und Entwurfsmuster • Methoden beim Architekturentwurf Entwurf und Entwicklung von Softwarearchitekturen 47 von 95
  • 48. CPSA Foundation Level Symptome von degeneriertem Design Zerbrechlich • Änderungen an einer Stelle führen zu unvorhergesehenen Fehlern an anderer Stelle Starr • Modifikationen sind schwierig • Betreffen eine Vielzahl an abhängigen Komponenten Schlechte Wiederverwendung • Komponenten können aufgrund zu vieler Abhängigkeiten nicht einzeln wiederverwendet werden Degeneriertes Design Entwurf und Entwicklung / Architekturen entwerfen/ Umgang mit Abhängigkeiten 48 von 95
  • 49. CPSA Foundation Level • Schlüssel zu flexiblen, erweiterbaren Architekturen • Verbieten von direkten Abhängigkeiten erlaubt Austauschbarkeit von Bausteinen • Konsequente Umsetzung des Offen Geschlossen Prinzips Abhängigkeit nur von Abstraktionen Erlauben Sie Abhängigkeiten nur von Abstraktionen, nicht von konkreten Implementierungen. Entwurf und Entwicklung / Architekturen entwerfen/ Umgang mit Abhängigkeiten 49 von 95
  • 50. CPSA Foundation Level • Zyklische Abhängigkeiten verhindern getrennte Wiederverwendung Zyklische Abhängigkeiten auflösen A B C A B C CA 1. Aus A diejenigen Teile als Abstraktion CA heraustrennen, die von C genutzt werden. 2. Auflösung geschieht durch Vererbungsbeziehung von A zur Abstraktion CA Entwurf und Entwicklung / Architekturen entwerfen/ Umgang mit Abhängigkeiten 50 von 95
  • 51. CPSA Foundation Level • Beschreiben Lösungen für wiederkehrende Probleme • Sind anwendbar auf unterschiedliche Systemstrukturen (Klassen, Komponenten, etc.) • Werden nicht entwickelt sondern meistens per Zufall entdeckt • Bieten Vorlagen für: • Vorgehen bei der Zerlegung eines Systems • Verteilen von Verantwortlichkeiten innerhalb eines Systems Möglichkeiten zur Auflösung von Kopplung: Nutzung von Muster Entwurf und Entwicklung / Architekturen entwerfen/ Umgang mit Abhängigkeiten 51 von 95
  • 52. CPSA Foundation Level • Hierarchische Architekturstile: • z.B. Layer • Sprachunabhängige Muster • z.B. Adapter, Facade, Plugin, Broker, Observer • Erzeugungsmuster • z.B. Factory, Dependency Injection • Datenfluss Muster: • z.B Pipes & Filter • Messaging, Events, Commands • z.B. Publish-Subscribe • Stability Muster • z.B. Bulkhead, Timeout, Circuit Breaker Möglichkeiten zur Auflösung von Kopplung: Nutzung von Muster Entwurf und Entwicklung / Architekturen entwerfen/ Umgang mit Abhängigkeiten 52 von 95
  • 53. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf Entwurf und Entwicklung von Softwarearchitekturen 53 von 95
  • 54. CPSA Foundation Level • Strukturiert das System in aufeinander aufbauenden Diensten • Abstraktionsgrad steigt mit der Anzahl darunter liegender Schichten • Dienstnutzung findet nur zwischen direkt aufeinander aufbauenden Schichten statt • Dienstnutzung erfolgt gerichtet von der höheren Schicht aus (Kommunikation erfolgt in beide Richtungen) • Die umgekehrte Richtung oder das „Durchgreifen“ durch eine Zwischenschicht sollte nur in begründeten Ausnahmefällen erlaubt werden Hierarchische Architekturstile Schichten (Layer) Highest level of abstraction Lowest level of abstraction Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 54 von 95
  • 55. CPSA Foundation Level Vorteile • Schichten sind unabhängig • In der Entwicklung (Arbeitsteilung) • Im Betrieb (Installation, Wartung) • Implementierungen sind austauschbar • Reduziert die Menge möglicher Abhängigkeiten zwischen Komponenten • Leicht verständliches Konzept Nachteile • Overhead, wenn Schichten für die Erbringung bestimmter Dienste lediglich an die Folgeschicht durchreichen • Umgehbar, wenn Überspringen von Schichten gezielt erlaubt • Erhöht Abhängigkeiten • Änderungen wie das Hinzufügen eines Datenfelds ziehen sich vertikal durch alle Schichten Hierarchische Architekturstile Schichten: Vor- und Nachteile Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 55 von 95
  • 56. CPSA Foundation Level Hierarchische Architekturstile Schichten: Übliche Untergliederung Präsentationsschicht Applikationsschicht Fachdomäne Infrastruktur  Bedienelemente  (Teil-) Ansichten der Fachdomäne  Koordination von Fachobjekten  Delegation an Fachdomäne / Infrastruktur  Fachliche Aspekte: Datentypen, Verarbeitungsregeln, etc.  Kapselt Komplexität der Infrastruktur  Kann weiter untergliedert sein Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 56 von 95
  • 57. CPSA Foundation Level • Aspekte der Fachdomäne sollten nie in der Präsentationsschicht behandelt werden • Negative Auswirkung auf Wartbarkeit • Reduziert Wiederverwendbarkeit • Schichten sind keine „Tiers“. • „n-Tier-System“ spiegeln die physische Verteilung von Komponenten auf miteinander verbundene Infrastruktur wieder • Eine logische Schicht kann über mehrere Tiers verteilt sein, ein Tier kann mehrere logische Schichten beherbergen Hierarchische Architekturstile Schichten: Anmerkungen Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 57 von 95
  • 58. CPSA Foundation Level • „to adapt“ (englisch) =„an-, einpassen“ • Auch bekannt als Wrapper (= Umwickler) • Problemstellung: • Zwei Klassen können wegen inkompatibler Schnittstellen nicht zusammenarbeiten • Adapter bewirkt Schnittstellen-Anpassung Sprachunabhängige Muster Adapter Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 58 von 95
  • 59. CPSA Foundation Level • Bietet vereinfachte Schnittstelle zu einer Menge von Schnittstellen eines Subsystems • Nützlich wenn Subsystem viele technisch orientierte Klassen enthält, die selten von außen verwendet werden • Enthält eine häufig benötigte Untermenge an Funktionalität des Subsystems • Delegiert die Funktionalität an andere Klassen des Subsystems Sprachunabhängige Muster Fassade Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 59 von 95
  • 60. CPSA Foundation Level • Zur Erweiterung der Funktionalität einer Klasse zur Laufzeit • Wird an zuvor definiertem Erweiterungspunkt („extension point“) eingebunden • Plugin-Klasse implementiert ein von der zu erweiternden Klasse vorgegebenes Interface, über das das Plugin aufgerufen wird • Folgt dem Prinzip der Umkehr von Abhängigkeiten Sprachunabhängige Muster Plugin Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 60 von 95
  • 61. CPSA Foundation Level Sprachunabhängige Muster Broker Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 61 von 95
  • 62. CPSA Foundation Level • Server-Proxy • Ruft Dienste des Servers auf • Kapselt systemspezifische Funktionalität • Vermittelt zwischen Server und Broker • Bridge • Kapselt netzwerkspezifische Funktionalität • Vermittelt zwischen lokalen Broker und Bridge eines entfernten Brokers • Broker • Lokalisiert und verwaltet Server • Leitet Messages weiter • Behandelt Fehler • Stellt APIs zur Verfügung • Client • Implementiert Funktionalität auf User- Seite • Sendet Requests über Client-Proxy • Server • Implementiert die Services • Registriert sich beim jeweiligen Broker • Sendet Responses über Server-Proxy • Client-Proxy • Kapselt systemspezifische Funktionalität • Vermittelt zwischen Client und Broker Sprachunabhängige Muster Broker Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 62 von 95
  • 63. CPSA Foundation Level • Subject weiß über Observer nur, dass sie das Interface Observer implementieren • Keine feste Bindung zwischen Observer und Subject • Änderungen haben keinen Einfluss auf den anderen • Beide können unabhängig voneinander wiederverwendet werden Sprachunabhängige Muster Observer Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 63 von 95
  • 64. CPSA Foundation Level Erzeugungsmuster Factory • Ziele • Geringere Kopplung • Hohe Kohäsion • Konkreter Erzeuger • erbt die Fabrikmethode von Erzeuger • implementiert sie so, dass sie KonkretesProdukt erzeugt Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 64 von 95
  • 65. CPSA Foundation Level Erzeugungsmuster Dependency Injection Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 65 von 95
  • 66. CPSA Foundation Level • Model • enthält darstellbare Informationen • View • liest Informationen aus dem Modell und erzeugt auf Grundlage dieser eine Darstellung • Controller • Nimmt Benutzer- und Systemereignisse (Eingaben) entgegen und leitet diese bereinigt und normalisiert an das Model weiter • Ein Modell kann von beliebig vielen View-/Controller-Paaren verwendet werden. • Erlaubt mehrere Sichten auf das selbe Modell Muster für interaktionsorientierte Systeme Model-View-Controller Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 66 von 95
  • 67. CPSA Foundation Level • Strukturierung von großen Systemen in fachliche Einheiten • Jeder Microservice soll eine eigene fachliche Einheit repräsentieren • Diese Microservices sind weitgehend entkoppelt und laufen selbstständig • Sprachunabhängige Kommunikation untereinander • Werden parallel entwickelt und unabhängig von einander deployed • Fördert eine flexible Architektur Muster für verteilte Systeme und deren Integration Microservices Anwendungslogik setzt sich aus mehreren Microservices zusammen Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 67 von 95
  • 68. CPSA Foundation Level Datenfluss Muster Pipes & Filter • Typisches Anwendungsfeld • Einzelne Phasen von Compilern • Lexer, Parser und Codegeneratoren als Filter • Digitale Signalverarbeitung • Bilderfassung, Farbkorrektur, Bildeffekte, Kompression als Filter • Multimedia lesen, Audio/Video trennen, Dekodieren, Hardwareausgabe Entwurf und Entwicklung / Architekturen entwerfen/ Architektur- und Entwurfsmuster 68 von 95
  • 69. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Architektur- und Entwurfsmuster • Methoden beim Architekturentwurf Entwurf und Entwicklung von Softwarearchitekturen 69 von 95
  • 70. CPSA Foundation Level • Ein Querschnittsaspekt ist eine Anforderung an ein Softwareprodukt, die systemübergreifend einzuhalten oder umzusetzen ist • Beispiele sind Fehlerbehandlung, Logging, Tracing und Sicherheit • Typischerweise gehören sie nicht zur Kernfunktionalität der Software, sondern stellen Zusatz- oder Metaanforderungen dar Querschnittliche Konzepte Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 70 von 95
  • 71. CPSA Foundation Level • Form • Kann vielfältig sein • Konzeptpapiere mit beliebiger Gliederung • Übergreifende Modelle oder Szenarien • Implementierung durch einzelne oder mehrere Bausteine • Ein Querschnittskonzept kann Anforderungen an die Implementierung mehrerer Bausteine stellen • Querschnittskonzepte sollen explizit dokumentiert werden und systemübergreifend wiederverwendbar sein Querschnittliche Konzepte Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 71 von 95
  • 72. CPSA Foundation Level • Daten aus dem Hauptspeicher auf ein beständiges Medium bringen • Flüchtige Speichermedien nicht für dauerhafte Speicherung ausgelegt • Menge der Daten übersteigt oft die Kapazität des Hauptspeichers • Entkopplung von Fachdomäne und (Datenbank-) Infrastruktur Persistenz Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 72 von 95
  • 73. CPSA Foundation Level • Benutzungsoberfläche • Notwendig für IT-Systeme, die interaktiv genutzt werden • Sowohl grafisch als auch textuell • Ergonomie • Verbesserung/Optimierung der Benutzbarkeit • Betrifft: • Benutzungsoberfläche • Reaktivität (gefühlte Performance) • Verfügbarkeit • Robustheit Benutzungsoberfläche & Ergonomie Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 73 von 95
  • 74. CPSA Foundation Level • Vorhersehbare und angemessene Reaktionen definieren • Kategorien und Schweregrad unterscheiden • fachliche und technische Fehler unterscheiden • Auswirkungen von Fehlern minimieren • Diagnose von Fehlerursachen erleichtern • Was ging schief? • Wo ist es passiert? • Warum ging es schief? • Fehlerprävention • Frühzeitig vor erkennbaren Gefahren warnen • Verarbeitungstoleranzen erlauben Fehlerbehandlung Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 74 von 95
  • 75. CPSA Foundation Level • Authentifizierung (authentication) • Feststellung der Absenderidentität • Autorisierung (authorization) • Einräumung von Nutzungsrechten anhand der Identität • Integrität (integrity) • Erkennung der Manipulationen von gesicherten Daten • Vertraulichkeit (confidentiality) • Daten unzugänglich für Unbefugte übertragen und speichern • Unleugbarkeit (non-repudiation) • Eingegangene Nachrichten können nicht vom Sender abgestritten werden • Verfügbarkeit (availabilty) • Maßnahmen gegen unvorhergesehene oder mutwillige Systemstörung Sicherheit Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 75 von 95
  • 76. CPSA Foundation Level • Schrittweise verlaufende Steuerung • Ablaufsteuerung von IT-Systemen • Sichtbare Abläufe an der grafischen Oberfläche • Steuerung der Hintergrundaktivitäten • Darstellung von Ablaufketten • Zustandsdiagramme • Sequential Function Chart Ablaufsteuerung Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 76 von 95
  • 77. CPSA Foundation Level • Domänenspezifische Kausalzusammenhänge oder bedingte Handlungsanweisungen („wenn…, dann…“) • Komplexität der Regeln macht Quellcode unübersichtlich • Quellcode als Definitionsort erschwert einfache Änderung • Verteilung der Regeln über das gesamte System verhindert das Abschätzen der Auswirkungen von Änderungen • Explizit und zentralisiert deklarieren Geschäftsregeln Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 77 von 95
  • 78. CPSA Foundation Level • Bestandteile der Softwaresysteme laufen auf unterschiedlichen und eventuell physikalisch getrennten Rechnersystemen ab • Übertragung der Daten an verteilte Kommunikationspartner • Aufruf entfernter Methoden • Remote procedure call, RPC • Wahl passender Interaktionsstile oder Nachrichtenaustauschmuster • Synchron/Asynchron • Peer-to-peer Verteilung Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 78 von 95
  • 79. CPSA Foundation Level Internationalisierung Formatierung Währung Kulturelle Unterschiede Maskenlayout Beschriftungen Dokumentation Fehlertexte Tastenkürzel Datum, Uhrzeit, Zeitzone Zeichensätze Anwendungs- logik Technische Einheiten Entwurf und Entwicklung / Architekturen entwerfen/ Übergreifende technische Konzepte 79 von 95
  • 80. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Architektur- und Entwurfsmuster • Methoden beim Architekturentwurf Entwurf und Entwicklung von Softwarearchitekturen 80 von 95
  • 81. CPSA Foundation Level Request-Response • Ressourcenorientiert • Serviceorientiert (async.) Messaging Shared Database Filetransfer • Schnittstellen • anderer Systeme • für andere Systeme • Datenschnittstelle • Funktionale Schnittstelle • Synchron oder asynchron • Performance Wünschenswerte Eigenschaften: • Einfach zu erlernen • Einfach zu benutzen • Einfach zu erweitern • Schwer zu missbrauchen • Funktional vollständig aus Sicht der Nutzer Schnittstellen --------------- --------------- --------- Need Have SPI Provider <<implements>> Entwurf und Entwicklung / Architekturen entwerfen/ Schnittstellen entwerfen und festlegen 81 von 95
  • 82. CPSA Foundation Level • Unterschiedliche Betrachtungsweisen / Architekturstile • Ressourcenorientierter Ansatz • REST (REpresentational State Transfer) • Geschäftsobjekte werden als Web-Ressourcen adressiert → URI via HTTP(S) • Verschiedene Repräsentationen / Formate (content types) • Einheitliche Schnittstellendefinition → HTTP-Methoden (verbs) • Service-orientierter Ansatz • XML (WS-*, WSDL, SOAP) • Methodenaufrufe werden in Nachrichtenpaketen geroutet → SOAP via HTTP(S) • Spezifische Schnittstellendefinitionen für Geschäftsfunktionen Betrachtungsweisen von Schnittstellen Entwurf und Entwicklung / Architekturen entwerfen/ Schnittstellen entwerfen und festlegen 82 von 95
  • 83. CPSA Foundation Level “sei streng bei dem was du tust und offen bei dem was du von anderen akzeptierst.” • Implementierungen sollen sich möglichst eng an bestehende Empfehlungen und Standards halten, ohne diese Vorgehensweise von anderen Beteiligten zu erwarten • Eingaben sollen weiterhin auf Fehlerhaftigkeit geprüft werden ohne zu Fehlern beim Empfänger zu führen • Softwaresysteme, die Nachrichten empfangen, sollten unvollkommene Eingaben akzeptieren, solange die Bedeutung klar ist • Die Einhaltung von Postel’s Law fördert die Robustheit des Systems aber kostet Implementierungsauwand und verbirgt Risiken Entwurf externer Schnittstellen Robustheitsgrundsatz– Postel’s Law Jonathan Bruce Postel (1943 - 1998), American computer scientist http://www.postel.org/pr.htm Entwurf und Entwicklung / Architekturen entwerfen/ Schnittstellen entwerfen und festlegen 83 von 95
  • 84. CPSA Foundation Level • Vorgehensweisen beim Architekturentwurf • Einflussfaktoren und Randbedingungen • Architekturen entwerfen • Entwurfsprinzipien • Umgang mit Abhängigkeiten • Architektur- und Entwurfsmuster • Übergreifende technische Konzepte • Schnittstellen entwerfen und festlegen • Methoden beim Architekturentwurf (Exkurs DDD) Entwurf und Entwicklung von Softwarearchitekturen 84 von 95
  • 85. CPSA Foundation Level • Sammlung von Entwurfsmustern • Strukturierung von größeren Systemen nach Fachlichkeiten • Jedes Subsystem soll eine eigene fachliche Einheit bilden • Bei Änderungen oder neuen Features muss nur ein Subsystem geändert werden • Parallelisierung der Entwicklung ohne großen Koordinierungsaufwand • Im DDD kann ein System in folgende Domänen unterteilt werden: • Core-Domain • Generic-Domain • Supporting-Domain Domain-Driven Design (DDD) Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 85 von 95
  • 86. CPSA Foundation Level Core Domain • Kernfunktionalität des Systems • Der Grund für die Existenz des Systems • Möglichst die erfahrensten Entwickler einsetzen Generic Subdomain • Enthält Funktionalität, die wichtig für das Geschäft ist, aber nicht Teil der Core Domain • z.B.: Rechnungen erstellen oder Briefe versenden. • Kann hinzugekauft oder outgesourced werden Supporting Subdomain • Enthält unterstützende und untergeordnete Funktionalität • Kann von weniger erfahrenen Entwicklern übernommen werden • Sollte streng von der Core- Domain getrennt werden • z.B.: durch Anti- Corruption-Layer Arten von Domänen Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 86 von 95
  • 87. CPSA Foundation Level • Strukturierung auf rein fachlicher Basis • Entwurf eines projektweit akzeptierten Domänenmodells • Verbessert Kommunikation zwischen Fachexperten und Entwicklern • Erlaubt Fachexperten präzisere Formulierung von Anforderungen • Entstehung einer gemeinsamen, domänenspezifischen Sprache • Ubiquitous Language Fachmodelle als Basis Beginnen Sie Ihren Entwurf mit der Strukturierung der Fachdomäne Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 87 von 95
  • 88. CPSA Foundation Level • Zentrales Konzept des Domain-driven Designs • Alle Projektmitglieder nutzen dieselben Begriffe wie die Domänenexperten • z.B. im Quellcode, in Datenbanken -> keine Übersetzungen • Software soll nur die wesentlichen Elemente und Strukturen der Domäne enthalten • Geschäftsfunktionen • Geschäftsprozesse • Geschäftsobjekte Allgemeingültige Sprache Ubiquitous Language Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 88 von 95
  • 89. CPSA Foundation Level Bausteine eines Domänenmodells Ubiquitous Language Entities Value Objects Services Module Aggregates Factories Repositories Das Modell im Code darstellen Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 89 von 95
  • 90. CPSA Foundation Level Entities • Unveränderliche Identität (Schlüssel) • Definierter Lebenszyklus • Sind persistent Value Objects • Keine eigene Identität • Transportieren den Zustand anderer Objekte • Enthalten keine Entitäten Services • Abläufe oder Prozesse in der Fachdomäne • Operationen ohne eigenen Zustand • Ein- und Ausgaben der Operationen sind Domänenobjekte Aggregate • Kapselt vernetzte Domänenobjekte • Besitzt genau ein Wurzelobjekt • Extern darf nur die Wurzel referenziert werden Factories • Kapselt nicht-triviale Konstruktion komplexer Objektstrukturen • Kein Zugriff auf andere Schichten, dient ausschließlich der Konstruktion Repositories • Bietet Möglichkeiten Objektreferenzen dauerhaft zu erhalten • Kapselt die dazu nötigen Infrastrukturaufrufe • Insbesondere für Entitäten Module • Teilen das Domänenmodell in fachliche (nicht technische) Bestandteile • Sind gekennzeichnet durch starke innere Kohäsion und geringe Kopplung zwischen den Modulen Systematische Verwaltung der Domänenobjekte Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 90 von 95
  • 91. CPSA Foundation Level • Zerlegung nach Fachobjekten, wenn • Wiederverwendung wichtig ist • die Fachlogik komplex, umfangreich oder flexibel ist • objektorientiertes Paradigma gut verstanden ist • Strukturierung nach Benutzertransaktionen, bei • simpler Datenbeschaffung und einfachen Operationen darauf • Integration von Fremdsystemen • einfacher oder wenig umfangreicher Fachlogik • wenig Erfahrung mit objektorientierten Vorgehensweisen Strukturierung der Fachdomäne Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 91 von 95
  • 92. CPSA Foundation Level • Published Language • Gemeinsame Sprache zwischen zwei Domänen, über die sie interagieren können. • z.B.: XML-Schema • Open Host Service • Domäne spezifiziert Protokoll, über das andere Domänen diese Nutzen können • z.B.: RESTful web service • Anti-Corruption-Layer • Nutzt Services einer anderen Domäne unter Verwendung einer Isolationsschicht • Seperate Ways • Zwei Domänen sind vollständig getrennt und haben keine Integration. Integration von Domänen Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 92 von 95
  • 93. CPSA Foundation Level Systematischer Entwurf Wo stehen wir jetzt? Risiken identifizieren Strukturen und technische Konzepte entwerfen Architektur kommunizieren Anforderungen und Einflussfaktoren klären Architektur bewerten Umsetzung überwachen Beginn: Informationen sammeln, Systemidee entwickeln Ende: System ausliefern Entwurf und Entwicklung / Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD) 93 von 95
  • 94. CPSA Foundation Level • [Gharbi+2020] Gharbi, M., Koschel, A., Rausch, A., Starke, G.: Basiswissen für Softwarearchitekten. 4., überarbeitete und aktualisierte Auflage, dpunkt.verlag, 2020 • [Starke2020] Starke, G.: Effektive Software-Architekturen. 9., überarbeitete Auflage, Carl Hanser Verlag, 2020 • [Clements+2010] Clements, P. et al.: Documenting Software Architectures. 2., überarbeitete Auflage, Addison-Wesley, 2010 • [Reussner+2008] Reussner, R., Hasselbring, W. (Hrsg.): Handbuch der Software-Architektur. 2., überarbeitete und erweiterte Auflage, dpunkt.verlag, 2008 • [Parnas1972] Parnas, D.: On the criteria to be used in decomposing systems into modules. Volume 15 Issue12, Pages 1053-1058, Communications of the ACM, CACM Homepage archive, 1972 Referenzen (1) Entwurf und Entwicklung / Referenzen 94 von 95
  • 95. CPSA Foundation Level • [Fowler2003] Fowler, M.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2002 • [Martin2013] Martin, R. C.: Agile Software Development: Principles, Patterns and Practices. Pearson, 2013 • [Buschmann+1996] Buschmann, F., Meunier, R., Rohner, H., Sommerlad, P.: Pattern-Oriented Software Architecture. Volume 1: A System of Patterns. John Wiley & Sons, 1996 • [Buschmann+2007] Buschmann, F., Henney, K., Schmidt, D.: Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing. John Wiley & Sons, 2007 • [Hofmeister+2000] Hofmeister, C., Nord, R., Soni, D.: Applied Software Architecture. Addison-Wesley Professional, 1999 • [Douglass2002] Douglass, Bruce Powel: Real-Time Design Patterns. Addison-Wesley Longman, 2002 Referenzen (2) Entwurf und Entwicklung / Referenzen 95 von 95