02_Entwurf_Entwicklung_v7.0.pdf

© 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

• 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

• 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

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

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

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

• 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

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

Wo stehen wir jetzt?
Risiken
identifizieren
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
10 von 95

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

• 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

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

14 von 95

Risiken
identifizieren
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
15 von 95
Einflussfaktoren und Randbedingungen

• 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
16 von 95

• 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
17 von 95

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
18 von 95

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
19 von 95

• 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
20 von 95

Risiken
identifizieren
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
21 von 95

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
22 von 95

• 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
23 von 95

• 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
24 von 95

25 von 95

Risiken
identifizieren
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
26 von 95

27 von 95

• Ziel: Vom WAS zum WIE
• Gliederung des Entwurfsprozesses
• Grobentwurf: Gesamtstruktur des Systems (Architektur, Subsysteme, Schnittstellen, …)
• Feinentwurf: Detailstruktur des Systems (Komponentenentwurf, Datenstrukturentwurf, …)
• 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
Architekturen entwerfen/ Entwurfsprinzipien
28 von 95

• 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.
29 von 95

• 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
30 von 95

• 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
31 von 95

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
32 von 95

• 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
33 von 95

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
34 von 95
Separation of Concerns
Information Hiding

• 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
35 von 95

• 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
36 von 95

• 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
37 von 95

Blackbox- und Whitebox: Beispiel
https://de.wikipedia.org/wiki/Komponente_(UML)
38 von 95

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
39 von 95

• 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)
40 von 95

• Single Responsibility Prinzip
• Open Closed Prinzip
• Liskov Substitutionsprinzip
• Interface Segregation
• Dependency Inversion
SOLID Prinzipien
41 von 95

• 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
42 von 95

• 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.
43 von 95
https://www.elbisch.ch/2018/10/25/solid-open-closed-principle/

• 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
44 von 95
https://medium.com/@bart.jacobs/liskov-substitution-
principle-a-misnomer-3a891c29d359

• 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.
45 von 95

• 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.
46 von 95
https://en.wikipedia.org/wiki/Dependency_inversion_principle

• Methoden beim Architekturentwurf
47 von 95

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
Architekturen entwerfen/ Umgang mit Abhängigkeiten
48 von 95

• 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.
49 von 95

• 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
50 von 95

• 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
51 von 95

• 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
52 von 95

53 von 95

• 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
Architekturen entwerfen/ Architektur- und Entwurfsmuster
54 von 95

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
Schichten: Vor- und Nachteile
Architekturen entwerfen/ Architektur- und Entwurfsmuster 55 von 95

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
56 von 95

• 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
Schichten: Anmerkungen
57 von 95

• „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
58 von 95

• 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
Fassade
59 von 95

• 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
Plugin
60 von 95

Broker
61 von 95

• 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
Broker
62 von 95

• 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
Observer
63 von 95

Erzeugungsmuster
Factory
• Ziele
• Geringere Kopplung
• Hohe Kohäsion
• Konkreter Erzeuger
• erbt die Fabrikmethode von Erzeuger
• implementiert sie so, dass
sie KonkretesProdukt erzeugt
64 von 95

Erzeugungsmuster
Dependency Injection
65 von 95

• 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
66 von 95

• 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
67 von 95

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
68 von 95

69 von 95

• 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
Architekturen entwerfen/ Übergreifende technische Konzepte
70 von 95

• 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
71 von 95

• 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
72 von 95

• 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
73 von 95

• 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
74 von 95

• 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
75 von 95

• 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
76 von 95

• 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
77 von 95

• 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
78 von 95

Internationalisierung
Formatierung Währung
Kulturelle
Unterschiede
Maskenlayout
Beschriftungen Dokumentation Fehlertexte Tastenkürzel
Datum,
Uhrzeit,
Zeitzone
Zeichensätze
Anwendungs-
logik
Technische
Einheiten
79 von 95

80 von 95

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>>
Architekturen entwerfen/ Schnittstellen entwerfen und festlegen
81 von 95

• 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
82 von 95

“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
83 von 95

84 von 95

• 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)
Architekturen entwerfen/ Methoden beim Architekturentwurf (Exkurs DDD)
85 von 95

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
86 von 95

• 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
87 von 95

• 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
88 von 95

Bausteine eines Domänenmodells
Ubiquitous Language
Entities
Value
Objects
Services Module
Aggregates Factories Repositories
Das Modell im Code darstellen
89 von 95

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
90 von 95

• 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
91 von 95

• 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
92 von 95

Risiken
identifizieren
Konzepte entwerfen
Architektur
kommunizieren
Anforderungen
und
Einflussfaktoren
klären
Architektur
bewerten
Umsetzung
überwachen
Beginn:
Informationen
sammeln,
Systemidee
entwickeln
Ende:
System
ausliefern
93 von 95

• [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)
Referenzen
94 von 95

• [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)
Referenzen
95 von 95

02_Entwurf_Entwicklung_v7.0.pdf

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie 02_Entwurf_Entwicklung_v7.0.pdf

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

02_Entwurf_Entwicklung_v7.0.pdf