Architektur Pattern

Organisation und Interaktion zwischen den Komponenten

Einteilung

Es gibt verschiedenste Architekturmuster welche abhängig vom Projektumfang und -umfeld sinnvoll verwendet werden: Model-View-Controller, Model-View-ViewModel

Rich Client, GUI Applikation Multitier- und Layer- Architektur

Web Bereich, JavaEE , .Net, Client-Server Service-Oriented (Prozess-Orientiert), Peer-to-Peer, ...

Verteilte Systeme

Domain Driven Design, Hexagonale Architektur

– Innerer Aufbau von Softwarekomponenten Reflection, Inverstion of Control, Dependency Injection,...

Adaptive (Komponenten) Systeme, Entkoppelung

Model View Controller

Modell-Präsentation-Steuerung

Problem/Umfeld

ASD: 95CJA: 64FBU: 109JPQ: 152SGD: 204

ASD: 95CJA: 64FBU: 109JPQ: 152SGD: 204

95 15%

64 10%

109 18%

152 24%

204 33%

ASD

CJA

FBU

JPQ

SGD

View 1: Pie Chart View 2: Bar Chart View 3: Spread Sheet

Verschiedene Nutzer oder Sichten der gleichen Daten

Problem/Umfeld Zur Präsentation eines Models werden ein oder

mehrere Views erzeugt. Jedes View muss sicherstellen, dass es den

aktuellen Zustand des Models korrekt wiedergibt. Lösung: Observer

Jedes View meldet sich beim Model als Observer an.

Wenn sich das Model ändert, benachrichtigt es alle Observer. Dadurch erhalten die Views die Möglichkeit, sich anzupassen.

Problem: User-Events

Model-View-Controller

Drei Teile

BenutzerBenutzer

Eingabe

Ausgabe

ControllerController

ViewModelModel

Model Daten und ihre VerarbeitungView Präsentation der DatenController Benutzer-Eingaben

Entkoppelung der verschiedenen Teile der Applikation mehr Flexibilität

View Stellt die Daten / Informationen dar (Präsentation)

Leitet Benutzereingaben an den Controller weiter

Kennt Controller und Model

Wird vom Model über Datenänderungen informiert (Observer)

Controller Verwaltet eine oder ev. mehrere Views

Nimmt von der View die Benutzeraktionen (Events) entgegen und wertet sie aus.

Leitet die Aktionen an das Model weiter

Wird ev. vom Model über Datenänderungen informiert (Observer) um auf Zustandsänderungen zu reagieren.

Kann die View steuern (Ansicht wechseln, auf andere Seite wechseln)

Model

Der Funktionale Teil der Applikation

Zuständig für die Daten-Verwaltung und die Business Logik

Observable

Kennt die angemeldeten Observer (Views und Controller)

Benachrichtigt alle Observer über Daten- oder Zustands-Änderungen

Funktionaler Ablauf

MVC mit Observable / Observer

Event Handling im MVC Pattern

Verweis auf andere Muster

Observer

Wird im MVC üblicherweise benutzt

Model View Presenter View agiert nur mit Presenter, dieser ist

Bindeglied zwischen Model und View steuert die logischen Abläufe zwischen den beiden anderen.

Model View ViewModel MVP mit Command- und Data-Binding

Offene Punkte

Aufteilung der Logik zwischen Controller und Model?

Ansiedlung von Formatierung und Internationalisierung?

Ort für die Validierung der Benutzer-Eingaben?

→ Werden in verschiedenen Implementierungen / Frameworks unterschiedlich gelöst.

Model View ViewModel

Data-Binding / Model View Presenter

Umfeld/Zweck Analog zu MVC Pattern

Trennung von Darstellung und LogikVereinfachung der Schnittstelle durch Data-

Binding

Eigenschaften

Auftrennung in separate Teile Die View kapselt den UI Aufbau (z.B. HTML5).

Das ViewModel kapselt die Präsentationslogik.

Das Model kapselt die Businesslogik und deren Daten.

View interagiert mittels Data-Binding und Events mit dem ViewModel

→ Lose Kopplung

View Stellt die Daten / Informationen dar (Präsentation)

Nimmt Benutzeraktionen entgegen.

Kennt das ViewModel aber nicht das Model.

Nicht für die Verarbeitung der Benutzerdaten zuständig.

Definiert die Daten- und Befehls-Bindung zumViewModel.

Enthält im Idealfall keine Businesslogik.

Model Enthält Daten und Geschäftslogik.

Greift - falls notwendig – auf Backend zu.

Unabhängig von Präsentation (View) und Steuerung (ViewModel).

Zuständig für Daten und Methoden zurDatenmanipulation (CRUD Operationen).

ViewModel

Stellt die Daten aus dem Model und die Befehle für die (eine) View bereit.

Implementiert die Aktionslogik der View.

Kennt das Model, jedoch nicht die View (nur via DataBinding).

Abonniert das Model als Observer.

Wird über Veränderungen im Model benachrichtigt.

Funktionalität

Beispiel: Angular

Quelle: https://angular.io/guide/architecture

Beispiel: Angular (View und ViewModel)

View:<h2>Hero List</h2>

<p><i>Pick a hero from the list</i></p><ul> <li *ngFor="let hero of heroes" (click)="selectHero(hero)"> {{hero.name}} </li></ul>

<hero-detail *ngIf="selectedHero" [hero]="selectedHero"></hero-detail>

ViewModel:

export class HeroListComponent implements OnInit { heroes: Hero[]; selectedHero: Hero;

constructor(private service: HeroService) { }

ngOnInit() { this.heroes = this.service.getHeroes(); }

selectHero(hero: Hero) { this.selectedHero = hero; }}

Beispiel: Angular (Model)

Model:

@Injectable()export class HeroService { private heroes: Hero[] = [];

constructor( private backend: BackendService, private logger: Logger) { }

getHeroes() { this.backend.getAll(Hero).then( (heroes: Hero[]) => { this.logger.log(`Fetched ${heroes.length} heroes.`); this.heroes.push(...heroes); // fill cache }); return this.heroes; }}

Vorteile Einfachere View (fast kein GlueCode) Einfach austauschbar Strikte Trennung von Design und Logik Gute Testbarkeit Datengebunde View updatet sich automatisch

Nachteile Grössere Komplexität Zweiseitiger Observer → Grosser Rechenaufwand

Anwendung MVVM wird eingesetzt in

XAML/WPF

JavaFX

HTML5 (HTML/JavaScript, z.B. Angular, Knockout, ...)

. . .

Multitier- and Layered Architecture

Umfeld Als Multitier Architecture wird ein Architekturmuster

bezeichnet, bei der eine Applikation in mehrere eigenständige Schichten (Tiers) unterteilt wird, welche separate Laufzeitinstanzen sind.

Das Layered Architecture Architekturmuster unterteilt die Anwendung ebenfalls in mehrere Schichten, welche jedoch typischerweise nicht alle eigenständig und separate Laufzeitinstanzen sind.

Bei beiden erfolgt der Aufruf immer von der «höheren» zu der «tieferen» Schicht/Tier.

Vorbild ist das OSI-Schichtenmodell (Betriebssystem-Theorie).

Kategorie/Zweck der Layered Architecture

Eine Schichten-Architektur ist ein häufig angewandtes Strukturierungsprinzip

Durch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems reduziert

Klare Aufgabenteilung

Geringe Kopplung

Schichten verhindern Zyklen im Abhängigkeitsgraph

Schichten werden (wegen ihrer wohldefinierten Aufgabe) gut verstanden.

Kategorie/Zweck der Multitier Architecture

Die Unterteilung der Anwendung in mehrere Laufzeiteinheiten mit klar definierten Aufgaben ermöglicht eine bedarfsgerechte Skalierung der Anwendung.

Jeder Tier hat seine klare Aufgabe: Klare Aufgabenteilung Geringe Kopplung

3-Tier Architektur: Aufteilung der Anwendung in:

Client (z.B. JavaScript Client, läuft im Browser des Benutzers)

Server (Businesslogik, läuft auf Server X oder in Cloud)

Datenbank (Persistenz, läuft auf Server Y oder in Cloud)

Eine Multitier Architektur bedingt den Einsatz von Layers, jedoch nicht umgekehrt.

Beispiel Layered Architecture

Quelle: Software-Referenzarchitektur des EJPD

Beispiel Multitier Architecture

Quelle: https://www.lucidchart.com/pages/uml/deployment-diagram

Vorteile Multitier- / Layered- Architecture

Multitier-Architekturen sind gut skalierbar und weisen einen hohen Grad an Flexibilität auf.

Einzelne Tiers resp. Layers sind einfach austauschbar.

Bei Veränderung der Schnittstellen/Interfaces sind nur die beiden angrenzenden Tiers resp. Layers betroffen.

Multitier-Architekturen kapseln Maschinen-Abhängigkeiten und sind daher leicht portierbar.

Multitier-Architekturen erlauben die örtliche Verteilung der Tiers (Hochverfügbarkeit, Katastrophenvorsorge)

Skalierbarkeit

● Scale-Up meist nur mit teurer Hardware möglich● Multitier Architektur ist meist Voraussetzung für Scale-Out● In der Cloud ist Scale-Out der Standard● Cloud kann Scale-Out dynamisch anhand der Last vornehmen● Multitier- und damit auch Layered Architecture ist heute Standard

für Enterprise Anwendungen.

Nachteile

Es ist oft schwierig Systeme sauber in Schichten zu strukturieren.

Zwischen den Schichten sind zusätzliche Klassen/Interfaces oder sogar Remote-Schnittstellen nötig

Zusätzlicher Overhead durch die Auftrennung in Schichten (Weiterleitung der Meldungen)Performanz-Probleme

Eine (zu) grosse Anzahl Schichten verursacht eine unnötig komplexe Struktur

Verwendung

Multitier- und Layered- Architekturen sind von Vorteil wenn grosse Skalierbarkeit und Flexibilität der Applikation

erfordert ist. der Austausch einzelner Schichten einfach sein soll. Schnittstellen stabil bleiben (Standardschnittstellen). Komponenten und Hardware/Software-Plattformen

austauschbar sein sollen. Man die Hardware/Software Plattformen einkauft →

Cloud. es möglich sein soll Komponenten mit komplexer

Funktionalität weiter aufzuteilen. das System von mehreren Teams mit klaren

Verantwortlichkeiten erstellt werden soll.

Praxisbeispiel: Netflix „So hat sich die Anzahl der Streaming-Mitglieder seit 2008 verachtfacht und auch die Streaming-Nachfrage pro Nutzer ist stark gestiegen, was in acht Jahren zu einem 1.000-fachen Anstieg des Streaming-Aufkommens geführt hat. Strukturell sind wir von einer monolithischen App auf Hunderte von Mikrodiensten umgestiegen und haben unser Datenmodell mithilfe von NoSQL-Datenbanken denormiert.“

Quellen: https://openconnect.netflix.com, https://media.netflix.com/de/company-blog/completing-the-netflix-cloud-migration

Verweis auf andere Muster

Verwandte (Strukturierungs-) Muster sind Microservices: Eine Anwendung besteht aus

mehreren Services, welche eine genau abgegrenzte Funktionalität der Anwendung zur Verfügung stellen. Sie basieren auf der Multitier- und auch auf der Layered- Architecture.

Hexagonal Architecture: Beispiel für Layered Architecture.

Quelle: http://alistair.cockburn.us/Hexagonal+architecture