Gibt es eine gute Architektur?
Jedes System hat eien Software-Architektur
(welche dokumentiert oder verbreitet sein kann)
Nein gute oder schlechte Architektur, entweder mehr oder weniger funktional für Ziel
Architekturen können anhand spezifisch gestetzter Ziele evaluiert werden
Komponentisierung und Abstraktion
Komponentiesierung versteckt Komplexität
- Abstraktion erlaubt lokale Veränderung
- verkürzt Zeit zum einschätzen
- Layering = wiederholte Abstraktion
Wert ist vertikal abgeleitet
Layers eines Information System
Client: jeder Benutzer oder Programm welches eine Operation über das System ausführen will
Presentation Layer: Clients interagieren mit System über PL
application logic layer: bestimmt was das System eigentlich macht
ressource management layer: kümmert sich um die Organisation der Daten um die application layer zu unterstützen (typischerweise Datenbank)
Pfeile und Boxen
Box als Teil des Systems
Pfeil als Verbindung
je mehr Boxen desto modularer -> mehr Möglichkeiten für Verteilung und Parallelisierung
je mehr Pfeile desto mehr sessions (Verbindungen) -> müssen gewartet, koordiniert werden. -> System komplexer
-> schlechtere Permormance
System Designer versuchen die flexibilität von modularem Design mit dem performance Ansprüchen von realen applications zu balancieren
Kein Problem kann nicht durch hinzufügen einer weiteren Stufe gelöst werden
Kein Performance Problem kann nicht gelöst werden indem eine Stufe entfernt wird
Software Components
- unit of composition
- spezifiziertes Interface
- explizite Abhängigkeiten
- kein spezifisches execution environment
- verschiedene Realisierunge möglich (Sprache, Code strucuture)
- zusammensetzbar aus anderen Software Components
Von Software Components zu Services
über:
- inter-process communication
- Netzwerk Protokolle
- Web Protokolle
Service als virtuelle Komponente
Impact of Software Architecture
hindert oder ermöglicht quality attributes eines systems
- Performance, Modifiability, security, Scalability, Reusability
Konsequenzen für change management
ermöglicht Kommunikation unter stakeholders
- verständlichkeit für alle (auch nicht IT-Menschen)
Trägt fundamentale Design Entscheidungen und Einschränkungen
Bottom-Up Design
- definiere access-channel und client platform
- Untersuche esistierende Ressourcen und deren Funktionalität
- verpacke existierende Ressourcen und integriere deren Funktionalität in einheitliches Interface
- passe output der application logic so an, das es von benötigten access-channel und client protocols benutzt werden kann
Hauptkosten bei wrappers und interfaces zu alten anwendungen
Top-Down Desing
- definiere access-channel und client-platform
- definiere presentation formats und protocols für den Client
- definiere die Funktionalität um content und format an die presentation layer zu liefern
- definiere date sources und data organization die für implementierung der application logic benötigt wird
Wrapper
adapter design pattern erlaubt inkompatible Klassen (Client und Adaptee) mitenander zu arbeiten indem das interface des Adaptee in ein vom Client erwartetes Interface konvertiert wird
One-tier
Vollzenetralisierte Architektur
User/Programs greifen auf das System durch display terminals zu, was gezeigt wird ist vom Server kontrolliert(“dumb terminals”).
höchst optimierbar
Two-tier
presentation layer bei Client
- Clients sind unabhägnig voneinander
- Zugriff über API
- ressource manager sieht nur einen client -> application logic
- server muss sich um alle möglichen Clients connections kümmern (maximale Anzahl an Verbindungen)
- Konkurrenz zwischen Clients
- Client als point of integration zwischen Systemen (fat clients)
- Sehr ineffizient
3-tier
komplett separierte Tiers
layers in der Regel verteilt
middleware als umweg zwischen client und anderen layers des system, zusätzliche layer die alle unterliegendenlayers umfasst
- redurziert anzahl der client interfaces
- transparenter zugriff auf untere systeme
- platform für inter-sytem funktionaitä
- übernimmt finden, zugriff und sammeln von ressourcen
N-tier
verbundene 3-tier systeme
web-server als zusätzliche layer für den zugriff von clients
web layer als presentation layer auf server seite
client greift durch web browser auf presentation layer zu
services
ein oder mehrere deployed, runnig (“always-on”) software programme, geräten und netzwerken die zusammenarbeiten um eine für den end-user zusammenhängende applikation zu liefern
Service oriented Computing (SOC)
deployed software einheiten die über ein netzwerk verteilt sind, welche benutzt werden können um business prozesse und - applikationen zu erstellen
Service oriented Architecture (SOA)
- Wiederverwendbarkeit
- geringer Aufwand beim - erstellen neuer Funktionen
- Bessere Skalierbarkeit
- Hohes Maß an Komplexität
- Höherere Initialaufwand
- Hohe Wiederverwendung kann zu zentraler Abhängigkeit führen
Reliability
Wahrscheinlichkeit R(t) das ein System in einem Intervall [0:t] zufriedenstellend funktionioniert. Wenn es in t=0 funktioniert hat.
R(t) = 1 - F(t)
R(t) = [f(tau) d tau]t-inf.
= 1 - [f(tau) d tau]0-t
Availability
A(t) Wahrscheinlichkeit das das System zu einem Zeitpunkt t zufreidenstellend funktioniert.
steady-state Availability:
As = MTTF/MTBF
Fault Intolerance vs Fault Tolerance
Intolerance -> Fehler vermeiden
- sehr zuverlässige Komponenten
- ausgearbeitete Design Techniken
- ausgearbeitete Herstellungs Techniken
- viele Tests
Tolerance -> Fehler tolerieren
- höhere Reliability
- manchaml niedrigere Gesamtkosten
- Kundenvertrauen
- Kosten für Redundanz
- manchmal höhere Komplexität
Redundancy
Duplizierung kritischer Komponenten
static -> alle Komponenten laufen kontinuierlich
dynamic -> Komponenten werden nach Bedarf dazu geschaltet
Triple Modular Redundancy
- mehrheit der Module muss funktionieren (2/3)
- Voter als kritische Komponente muss immer funktionieren
- Voter gibt richtiges Result wenn Mehrheit der Komponenten funktionieren
Structural vs. Time Redundancy
Structural -> Mehrere Ressourcen um redundancy
herzustellen
Time -> Eine Ressource wird länger benutzt um redundancy herzustellen
Performance
Ziel der performance hängt von spezifischen System Anforderungen ab
kann durch Benchmark bestimmt werde:
- Reales Programm
- Komponenten
- synthetische Benchmarks
