VO 4

• Anforderungen des Kunden optimal abdeckt

• Beschreibung des Systems (auf technischer Ebene)

• Festlegung auf Architektur

• Aufteilung des Systems

• Beschreibung von System-Strukturen

• erste Artefakt zur Analyse der Einhaltung von Qualitätseigenschaften

• Beschreibung der Beziehung von Komponenten und Verbindungen

Sie besteht aus:

• den Strukturen

• der Zerlegung in Komponenten

• deren Schnittstellen

• deren Beziehungen undereinander

Auf Entwurfsentscheidungen

ZB bezüglich:

• des Entwurfs der Komponenten

• der Auswahl der eingesetzten Technologie

Eine Abbildung eines Systems, das Anforderungen optimal beschreibt

• Nicht funktionale Anforderungen (strategischer Entwurf)

  z.B. Zuverlässigkeit, Benutzbarkeit,…

• Funktionale Anforderungen (taktischer Entwurf)

  z.B. Verarbeitung von Eingaben, Erstellen von Ausgaben,…

• Simplicity/ Einfachheit

• Spezifische Entscheidungen

• Explizite Definitionen

• Erwartung von Änderungen/Fehlern

• Einhaltung von Qualitätsanforderungen

• Geringe Kopplung

  = Maß für die zwischen Bausteinen bestehenden Abhängigkeiten

• Hohe Kohäsion

  = Maß für den inneren Zusammenhalt von Bausteinen und Funktionen

• Seperation of Concern

  = jeweils spezifische Verantwortlichkeiten, Zuständigkeiten oder Aufgaben

• Zerlegung in Module

  = Jedes Modul sollte bestimmte Verantwortlichkeiten kapseln

  (-> über wohldefinierte Schnittstellen zugänglich)

• Abstraktion, Kapselung, Geheimprinzip

  = Internes vor äußerem verbergen und nur über öffentliche Schnittstelle zugänglich machen

• Konsitenz

• Keine Redundanz

• Keine zyklischen Abhängigkeiten

• Klassendiagramme - Festlegung der Struktur

• Zustands- und Sequenzdiagramme – Verhalten des Systems

• Komponentendiagramme – Abbildung der Systemkomponenten und deren Zusammenhang

• SRP (Single Responsibility Principle)

• OCP (Open-Closed Principle)

• LSP (Liskov Substitution Principle)

• ISP (Interface Segregation Principle)

• DIP (Dependency Inversion Principle)

Eine Klasse soll nur eine Aufgabe haben

( = Seperation of Concerns)

Künftige Erweiterungen der Klassen sollen ohne Änderungen von bestehendem Quellcode möglich sein

Unterklassen müssen grundsätzlich für ihre Oberklassen eingesetzt werden können (Vererbung)

Feingranulare, client-spezifische Schnittstellen statt ein großes Universal-Interface

Erlaube Abhängigkeiten von Abstraktionen, nicht von konkreten Implementierungen

1. Strukturierung der jeweiligen Fachdomäne

2. Modellieren der Sprache der Fachdomäne

3. Clustern im Großen (“Strategisches Design”)

4. Strukturieren im Kleinen (“Taktisches Design“)

5. Isolieren der Domäne in der Architektur

• Modellieren einer Abstraktion der Domäne und diskutieren der Abstraktion mit Fachexperten

• Freihalten des Domänenmodell von technischen Aspekten

Bounded Context - Fachgebiete oder Themenbereiche, die inhaltlich eng zusammengehören

Innerhalb des BC gilt:

• Konsistente Bedeutung von Begriffen

• Pro BC ein eigenes/ eigenständiges Modell möglich

Modellierung mehrerer BCs in einer Context Map

(z.B. Für Telefonanbieter: Netzbetrieb/Billing)

• Struktur und Konzepte der Fachdomäne sollen langfristig in der Architektur repräsentiert werden

• Implementierung der Domäne (etwa Aggregate, Entitäten, Services und Value-Objekte) in eine eigene Schicht der Architektur

• Kontextbegrenzung:

  Vogelperspektive & Nachbarsysteme

• Laufzeitsicht:

  Zusammenarbeit der Bausteine

• Bausteinsicht:

  Bausteine und Beziehungen (Statische Struktur)

• Verteilungssicht:

  Umgebung in der das System läuft

• Schnittstellen zum Nachbarsystem

• Interaktionen mit wichtigen Stakeholdern

• wesentlichen Teile der umgebenden Infrastruktur

Wie ist das System intern aufgebaut?

• statischen Strukturen der Architekturbausteine

• meist top-down beschrieben

• unterstützen Projektleiter und Auftraggeber bei der Projektüberwachung

• dienen der Zuteilung von Arbeitspaketen

Wie läuft das System ab?

• welche Bausteine des Systems existieren zur Laufzeit

• wie wirken die Bausteine zusammen

• beschreibt dynamische Strukturen

In welcher Umgebung läuft das System ab?

• beschreiben die Hardwarekomponenten, auf denen das System läuft

• Dokumentation der physischen Systemumgebung

• zeigt das System aus Betreibersicht

Basiert auf Refactoring von erstellten, lauffähigen Komponenten

(zuerst deliverables - dann design)

-> es ist ohne bewusste Steuerung gestaltetes Design

• Code conventions

• Code reviews

• test everything

• eliminate duplication

• express all ideas

• minimize entities

• benachbarte Systeme

• existierende Systemlandschaft

-> strategischer Rahmen muss definiert sein

• Prozedural zu objektorientierten Programmiersprachen

• Vom Großcomputer zum Heimcomputer

• Trend von monolithischen Applikationen zu modularen Systemen

• Früher: hauptsächlich Rich-Client-Applikationen

• Trend zu Webapplikationen, Self-Contained Systems (SCS, Microservices) und Service-orientierte Architektur (SOA)

• 2-Tier Architekturen

• 3-Tier Architekturen

• Service-orientierte Architekturen

• Microservice Architekturen

• Umspannt mehrere Abstraktionsebenen:

  • Service Layer

  • Component Layer

  • Class Layer

• Unterschiedliche Notationen je Layer

  • Webservice (Service Layer)

  • Komponentendiagramme (Component Layer)

  • Klassendiagramm (Class Layer)

• Geschäftsprozess-orientiert

• Anwendungen durch mehrere Services gelöst

• Services sollen auch aus anderen Anwendungen heraus aufgerufen werden können (Reuse/ Modularisierung)

• Zusammenstellung von Services in bestimmten Abläufen zur Umsetzung von Geschäftsprozessen (Orchestrierung)

• Services existieren auf mehreren Abstraktionsebenen (Business Service, Component Service, technisches Service, usw.)

• Beschreibt eine Architektur, keine Technologie

• Lose Kopplung

  Niedrige Kopplung der Services ermöglicht hohen Reuse und Flexibilität

• Abstraktion

  Reduktion von Neuentwicklungen

  – Spannungsfeld Abstraktion vs. Technische Anforderungen

• Standardisierung

  Standardisierung erlaubt die Zusammenarbeit von Services

• Composable

  Standardisierte Services können zu Komponenten zusammengefasst

  werden

bei SOA:

• ein Schritt in einem Geschäftsprozess extrahiert und gekapselt

  -> business service

• SOA = business driven (an Geschäftsprozesse angelehnt)

Einen Architekturstil, der die Aufteilung größerer Systeme in kleinere, einzeln entwickel-, deploy- und betreibbare Einheiten vorsieht

• Erhöhung der Wandelbarkeit und Flexibilität

• Bessere Time-to-Market (neue Features sowie Fixes sollen schneller in Produktion gehen)

• Schnellere Entwicklung (durch kleinere Einheiten)

• Mehr Innovationsfähigkeit sowie Flexibilität bezüglich Technologieauswahl

• Läuft in einer eigenen Ablaufumgebung, ist also unabhängig von anderen Microservices

• Modularisierung (anhand von fachlichen Funktionen/Aufgaben)

• Eigene Ablaufumgebung (Unabhängiges Deployement und Skalieren)

• Selbstständig agierende Endpunkte/ simple Kommunikationskanäle

• Dezentrales Management von Microservices (unabhängige teams)

• Dezentrale Datenverwaltung (jedes Mircoservice verwaltet eigene Daten)

• “Remote” Kommunikation zwischen Microservices (benötigt Werkzeuge zum gegenseitigen Auffinden von Service- Instanzen inklusive Failover („Service Discovery“))

• Evolutionäre Entwürfe (kürzere Release-Zyklen und risikoarme Änderungen)

Das Anpassen der Organisation entsprechend der Microservices

• funktionsübergreifende Teams (cross-functional teams) unterstützen

• Teams sollen sich von Anfang bis Ende, von Konzeption bis Produktion um „ihr Produkt“ kümmern

• Ein Team - mehrere Microservies (nie umgekehrt)

• Internetbasierte Systeme:

  z.B. eBusiness-Anwendungen

• Klassische Client/Server-Anwendungen

  (wenn die serverseitigen Anwendungen stärker modularisiert und voneinander entkoppelt werden)

Also: Wann immer unterschiedliche (fachliche) Funktionalitäten voneinander getrennt entwickelt und betrieben werden können

• Entwickeln, testen, bauen und deployen:

  muss das team jedes mal selbst machen

• Service-Discovery:

  die vielen Services müssen zur Laufzeit zueinander finden

• UI-Integration:

  eine einheitliche, konsistente Benutzeroberfläche

• Dezentralisierte Daten:

  d.h. Konsistenz von Daten sicherstellen

• Überwachung und Betrieb von Laufzeitumgebungen

allgemeine Lösungsstrategien für wiederkehrende Probleme

• abstrakt

• Technologie unabhängig (meistens)

• Wesentlicher Input in Entwurfsentscheidungen

• Design Patterns

  Muster auf Klassen-Ebene (Mikroarchitektur)

• Architektur Patterns

  Muster auf architektonischer Ebene (Makroarchitektur)

• Sammlung von Entwurfsmustern

• Schaffung einer einheitlichen Sprache für Probleme und Lösungen

Beschreiben:

wiederholt auftretende Strukturen von miteinander kommunizierenden Komponenten

Dienen:

zur Lösung eines allgemein definierten Problems innerhalb eines bestimmten Kontexts

Unter Architektur Patterns

Schablonen/Vorlagen für konkrete Softwarearchitekturen

Sie spezifizieren systemweite, strukturelle Eigenschaften einer

Anwendung

• Model-View-Controller

• Pipes and Filters

• Layered Architecture

• Model kapselt Daten und Funktionen

• View stellt Informationen dar

• Controller empfängt Events

1. Szenario: Interaktive Anwendungen mit einer flexiblen Schnittstelle zwischen Mensch und Computer

2. Problem: GUI wird oft geändert

3. Lösung: Aufteilung in Verarbeitung, Output und Input