Please enable JavaScript.
Coggle requires JavaScript to display documents.
Effektive Softwarearchitekturen - Coggle Diagram
Effektive
Softwarearchitekturen
2: Architektur + Architekten :checkered_flag:
2.1 Was ist SA?
Ziele + Nutzen
Qualitätsanforderungen erfüllen
Konsistenz
Verständlichkeit des Systems
Starker Fokus auf Langfristigkeit
Unterstützung des ges. Lebenszyklus
Vereinfachung der Wiederverwendung Systembestandteile + Konzepte
2.2 Aufgaben von Architekten
abstrakt:
Berater für Manager + Team
Anwälte der Auftraggeber
Konstruieren, entwerfen, implementieren
Entscheiden
Erfüllung von Anforderungen garantieren
Beraten
Dokumentieren
Diplomat + Akrobat sein
Gummiband-Diagramm
Vereinfachen
Kommunizieren
Bewerten
Mut haben
Explizieren
Werkzeuge
Modelle
Doku
Heuristiken
Muster
Zerlegung (Partitionierung)
Zusammensetzung (Aggregation)
Iteration
Entwicklungsumgebung
2.3 Wie entstehen SA
Zyklen + Iterationen
Moving Target
Architecture Business Cycle
(Wechselwirkung Org., Arch., System)
In kleinen Teams (mit Verantwortlichem, z. B. CTO)
2.4 In welchem Kontext steht SA
Anforderungsanalyse
Analyse => Scope (das Richtige entwickerln)
Entwurf (richtig entwickeln)
Entwicklungsplanung (Stories...)
Implementierung
Risikoanalyse
Organisationskontext
Betrieb
Hardwarearchitektur
Qualitätssicherung
3: Vorgehen bei Architekturentwicklung
3.1 Informationen sammeln
3.2 Anforderungen klären
Kernaufgabe
Kategorie des Systems
Qualitätsanforderungen :checkered_flag:
Szenarien
Ermittlung: Interview, Brainstorming
(weniger: schriftliche Anforderungen)
Bestandteile
Quelle
Auslöser
Artefakt
Umgebung
Antwort
Antwort-Metrik
Merkmale
(ISO 25010)
Effizienz
Wartbarkeit
Benutzbarkeit
Kompatibilität
Zuverlässigkeit
Funktionale Brauchbarkeit
Sicherheit
Übertragbarkeit
Stakeholder
Kontext (fachlich + technisch) :checkered_flag:
3.3 Einflussfaktoren + Randbedingungen
Organisatorische / politische
Technische
3.4 Entwerfen + kommunizieren
3.5 Umsetzung begleiten
3.6 Lösungsstrategien entwickeln
4: Entwurf
4.1 Grundlagen :checkered_flag:
4.1.1 Grundsätze
(indiskutabel)
KISS
(Spezifisch)
Explizit statt implizit
Erwarte Änderungen
Erwarte Fehler
Halte Qualitätsanforderungen immer ein (siehe z. B.Szenarien)
4.1.2 Prinzipien
(etablierte Regeln)
Wäge Prinzipien gegen Anforderungen ab
Lose Kopplung
Hohe Kohäsion
Trenne Verantwortlichkeiten/Belange
Zerlege Systeme in Module
Abstraktion, Kapselung und Geheimnisprinzip
Konsistenz
DRY
Vermeide zyklische Abhängigkeiten
Erkläre angemessen
4.1.3 SOLID-Prinzipien
OCP: Open-closed Principle
SRP: Single Responsibility Principle
LSP: Liskov Substitution Principle
ISP: Interface Segregation Principle
DIP: Dependency Inversion Principle
4.2 Heuristiken
(Ratschläge/Hinweise,
Daumenregeln)
Recherchiere gründlich
Verfeinere schrittweise
Trial-and-Error
Generalisiere
Spezialisiere
Wechsle die Perspektive
Trenne Fachlichkeit von Technik
Achte auf Schnittstellen
Kenne die Risiken
Beachte die Geselligkeit von Fehlern
4.3 Entwurfsmethoden
4.3.1 DDD :checkered_flag:
Modelliere die Sprache der Fachdomäne (
Ubiquitous Language
)
Clustere im Großen (Strategisches Design) =>
Bounded Contexts
,
Context Map
Strukturiere im Kleinen (taktisches Design) =>
Entity, Value-Object, Domain Event, Service
Isoliere die Domäne in der Architektur =>
Domain Layer
Verwalte Domänenobjekte systematisch =>
Aggregat, Factory, Repository
4.3.2 WAM-Ansatz
Fachwerte
Materialien
Fachliche Services
Werkzeuge
Automaten
Technische Services
4.3.3 Quality-Driven Software Architecture
Zyklus
Aim
Szenarien (mit Prio)
Plan
Sammeln (Brainstorming) + analysieren von mögl. Maßnahmen
Konsequenzanalyse: Wirkungen von Maßnahmen auf versch Ziele)
Bsp.-Strategien
Hohe Performance
Anpassbarkeit + Flexibilität
Hohe Verfügbarkeit
Build
Check
4.3.4 Top-down und Bottom-up :checkered_flag:
4.4 Schnittstellen entwerfen :checkered_flag:
4.4.1 Anforderungen an Schnittstellen
4.4.2 Herausforderungen
4.4.3 Tipps zum Entwurf
Unit Tests als Doku
Consumer bekommt immer das, was er erwartet
Sprechende Namen
Fehlerfälle berücksichtigen + dokumentieren
4.5 Architekturstile u. -muster :checkered_flag:
4.5.1 Datenflussarchitekturstil
Batch sequentiell
Pro:
einfache Aufteilung
einfache/ähnliche Schnittstellen, z. B. Ein-Aausgabedateien
Con: Externer Baustein zur Steuerung notwendig
Pipes und Filter
Pro:
einfache Struktur
lose Kopplung
Con:
Fehlerbehandlung
Zentrale Steuerung notwendig
kein gemeinsamer Zustand der Filter (alle Daten müssen übertragen werden
ungeeignet für interaktive Systeme
4.5.2 Datenzentrierter Architekturstil
Repository
Blackboard
Pro:
Hinzufügen weiterer Agenten ist einfach
Agenten können parallel arbeiten
Con:
Agenten-Synchronisierung kan aufwendig + schwierig sein
günstiger Zeitpunkt für Ende der Berechnung kann schwer zu ermitteln sein
schwere Tests und Fehlersuche
4.5.3 Hierarchische Architekturstile
Master-Slave
Durch Redundanz sinnvoll, wenn Verfügbarkeit + Zuverlässigkeit wichtig sind
Schichten (Layer)
Pro:
Implementierung einer Schicht kann ausgetauscht werden (wenn selbe Dienste enthalten)
kann helfen, Abhängigkeiten zw. Komponenten versch. Schichten zu reduzieren
leicht verständlich
Con:
kann Performance beeinträchtigen
Systemänderungen können alle Schichten betreffen
Standard-Vorschlag
Con, wenn Wanderung fachlicher Logik in Appl.- oder Präsentationsschicht:
Testbarkeit der Fachlichkeit sinkt
alternative Systemnutzung über neue Schnittstelle braucht diese Logik erneut
Verständlichkeit des Gesamtsystems sinkt
Außerdem Con: Fachliche Schicht kennt oft Details der Persistenzschicht
Ports und Adapter
aka Hexagonale Architektur
aka Clean Architecture
Aufbau
Use Cases
Schnittstellenadapter
Frameworks, externe Systeme
Fachdomäne
sekundäre Ports
primäre Ports
Anwendungskriterien
bei langlebigen fachlichen Strukturen (in kommerziellen Informationssystemen meist der Fall)
wenn hohe Testabdeckung der Fachlichkeit notwendig
Pro:
Fachlichkeit kann frei von Infrastruktur implementiert werden
hohe Wartbarkeit + Änderbarkeit des ges. Systems durch hohe Modularisierung
Infrastruktur leicht austauschbar
Con: saubere + konsistente Modellierung + Impl. der Fachdomäne nötig (oft nicht gegeben)
4.5.4 Verteilte Systeme
Client-Server
Pro:
hohe Flexibilität
klare Trennung der Verantwortlichkeiten
Con:
Sicherheit
hoher Entwicklungsaufwand
vielfältige Fehlerquellen
Command Query Responsibility Segregation
Broker
Peer-to-Peer
Pro:
potentiell höchste Ausfallsicherheit
Peers können sich selbständig finden
Con:
Daten können durch Peers (bewusst) verfälscht werden
Beschäftigung mit möglichen Fehlerquellen nötig
Anwendung wenn:
hohe Ausfallsicherheit nötig
keine bes. Anforderung an Schutzwürdigkeit der Daten
verfügbare Serverkapazitäten sind zu gering
SOA => Kapitel 10
4.5.5 Ereignisbasierte Systeme - System Events
Ungepufferte Event-Kommunikation
Broadcast
Subscriber
Message- oder Event-Queue-Architekturen
Wenn Erzeuger Rückmeldung braucht => Erweiterung
Message-Service-Architekturen
Anwendungskriterien:
Erzeuger benötigt keine Rückmeldung
Es müssen mehrere untersch. Systeme zusammenarbeiten
Sender erzeugt Nachrichten schneller, als Empfänger sie verarbeiten können
Pro:
Sender und Empfänger können unterschiedliche Technologien + Programmiersprachen verwenden
Message Queues (insb. mit reliable messaging) können Verfügbarkeit + Robustheit erheblich steigern
Con:
Message Queues sind komplexe Systeme mit hohem Einführungs- u, Administrationsaufwand
asynchrone + nachrichtenbasierte Entwicklung ist deutlich aufwändiger
4.5.6 Interaktionsorientierte Systeme
Model-View-Controller
Pro:
klare Trennung von Verantwortlichkeiten
mehrere Views pro Model möglich
viele Frameworks verfügbar
Con:
Implementierung + Debugging kann wegen Notifikation aufwendig sein
Notifikation von Modellen mit mehreren Controller-View-Paaren kann langsam sein
Presentation Model
Anwendungskriterien:
falls das Verhalten der UI ausgiebig automatisiert getestet werden soll
Rich Internet Application mit vielen Eingaben und Validierungen
Pro:
Model kann reines Domänen-Modell bleiben (z. B: POJO) => einfacher + testbarer
View bleibt frei von Logik oder Prüfungen
Con:
Synchronisations- oder Notifikationsmechanismus nötig (was aber bei interaktiven graf. Systemen meist ohnehin nötig ist)
4.5.7 Weitere
REST-Architektur
Anwendungskriterien:
Web-API
unternehmensinternes Integrationsumfeld
Pro:
viele ausgereifte Werkzeuge + Bibliotheken, hohe Interoperabilität
gute Skalierung durch statuslose Kommunikation
besonders geringe Kopplung zw. Kommunikationspartnern
Con:
Nachrichten werden über das Netz gesendet, nicht lokale Methoden aufgerufen
4.6 Entwurfsmuster :checkered_flag:
4.6.2 Adapter
4.6.3 Beobachter
4.6.4 Dekorierer
4.6.5 Proxy
4.6.6 Fassade
4.6.7 Zustand
5: Kommunikation + Dokumentation :checkered_flag:
6:Modellierung
6.2 UML2
6.2.1 Diagrammarten :checkered_flag:
Strukturdiagramme
Klassendiagramm
Objektdiagramm
Paketdiagramme
Komponentendiagramm
Kompositionsstukturdiagramm
Verteilungsdiagramm
Verhaltensdiagramme
Aktivitätsdiagramm
Zustandsdiagramm
Anwendungsfalldiagramm
Interaktionsdiagramme
Sequenzdiagramm
Kommunikationsdiagramm
Zeitverhaltensdiagramm
Interaktionsübersichtdiagramm
7:Techn. Konzepte
7.2 Geschäftsregeln
Motivation
Funktionsweise von Regelmaschinen
Pro & Contra
Mögliche Probleme
8: Bewertung von SA
8.1 Qualitative Architekturbewertung :checkered_flag:
Bewertungsgrundlagen
Qualitative Bewertung nach ATAM
Maßgebliche Stakeholder identifizieren
ATAM vorstellen
Geschäftsziele vorstellen
Architektur vorstellen
Architekturansätze detailliert erläutern
Spezifischen Qualitätsbaum erstellen
Durch Szenarien verfeinern
Architektur hinsichtlich Szenarien analysieren
(Maßnahmen definieren)
Resultate vorstellen
8.2 Quantitative Bewertung durch Metriken :checkered_flag:
9: Modernisierung + Evolution
10: Microservices
11: Enterprise IT Architektur
12:Beispiele
13: Werkzeuge :checkered_flag:
13.1 Kategorien
Anforderungsmanagement
Modellierung
Generierung von Code / sonstigen Artefakten
Generierung von Dokumentation
Codemanagement / Implementierung
Statische Codeanalyse
Laufzeitanalyse von Software
Build- und Konfigurationsmanagement
Test von Software
Dokumentation
13.2 Typische Auswahlkriterien
Technische Kriterien
Organisatorische Kriterien