Kernaktivitäten der Softwareentwicklung

• Anforderungsspezifikation (Fachliche Komponenten, Anforderungen): Pflichtenheft
• Analyse: Analysenmodell
• Design (Grobskizze der Systemarchitektur): Software Architektur
• Implementierung (Systemrealisierung: Lauffähiges System)
• Testing

Qualitätseigenschaften

• Verfügbarkeit
• Interoperabilität
• Änderbarkeit
• Performance
• Sicherheit
• Testbarkeit
• Benutzerfreundlichkeit

Werkzeuge von Software Architekten

• Modelle: Vereinfachte Abbildungen bzw Abstraktionen
• Heuristiken: Erfahrungswerte, Regeln, Tipps
• Muster bzw Patterns: Vorlagen/Schablonen - dienlich der Wiederverwendung
• Zerlegung (Partitionierung): Architekten beherrschen Komplexität durch Zerlegung in Teilprobleme
• Zusammenfasssung (Aggregation): Architekten setzen Einzelteile zu Software-Systemen zusammen

Komponenten (Begriff)

• Logische (fachliche) Komponente
• Wird auf Basis der Schnittstellen anderer Einheiten unabhängig entwickelt
• Implementierung kann unter Wahrung der Schnittstelle ausgetauscht werden
• Softwarekomponente
• Lauffähige Softwareeinheit
• Verfügt über Schnittstelle, mit welcher die Softwarekomponente ohne Änderungen mit anderen verbunden ist
• im Kontext von Frameworks und Plattformen wie Corba, Java EE, .Net, Webservices

Fachliche Sicht vs Technische Sicht

• Fachliche Sicht
• Zerlegung in fachliche Kompnenten
• Definition von Schichten (Präsentation, Presistenz, ...)
• Definition von Komponenten nach Anwendungsfeldern (Adressverwaltung, Bestellungsabwicklung)
• Technische Sicht
• Beschreibung der Technischen Komponenten des Systems (Plattformen, Struktur, DB)
• Realisierung der in der Anwendungsarchitektur beschriebenen Komponenten

UML

• Unified Modeling Language
• Standardisierte Sammlung von Notationen zur graphischen Bearbeitung von Softwaresystemen

Klassen

Assoziationen

Assoziationen mit Kardinalität .z.b (a...b -> mindestens a und hächstens b), (1..1 -> genau 1), (0..1 -> 0 oder 1), (0..* -> beliebig viele), (1..* -> beliebig viele aber min 1)

Aggregation und Komposition

Spezielle Art von Assoziationen: "Teil-Ganzes" Beziehung

Abhängigkeitsbeziehungen z.b. A hängt von B ab oder "Client" hängt von "Server" ab

Generalisierung bzw Vererbung

Interfaces

Komponenten (1)

• Können in UML als Klassen dargestellt werden und damit auch Eigenschaften besitzen
• Fachliche Komponentendiagramme beschreiben die Komponenten bzw ihre Schnittstellen und Abhgängigkeiten
• Mit Hilfe der Kompositionsbeziehungen können komponenten-Hierarchien beschreiben werden
• Neben den Komponentendiagrammen beschreiben eine Vielzahl weiterer Diagramme verscheidene Schichten einer SW Architektur: Verteilungsschicht, Interaktion zwischen Komponenten, DB Schema

Komponenten (2)

UML Cheat Sheeet

UML Sequenzdiagramme

• Beschreibt komplexe Interaktion zwischen Objekten in bestimmten Rollen
• Beschreibt die Zeitliche Abfolge dieser Interaktionen
• Wird zur Beschreibung der fachlichen Sicht (Laufzeitsicht) verwendet

Nachrichten

• Allgemein ist eine Nachriccht eine Informationseinheit, die von einem Senderobjekt zu einem Empfängerobjekt gesendet wird
• In unserem Kontext sind Nachrichten Methodenaufrufe

Wir verwenden Sequenzdiagramme im folgenden, um beispielhafte Nachrichtenflüsse darzustellen

• Eine prinzipielle Art und Weise, wie Objekte miteinander kommunizieren, wrid dargestellt
• Das Giagramm ist keine exakte Repräsentation von Programmabläufen Nicht alle beteiligten Objekte und Nachrichten sind dargestellt bzw es dürfen Parameter fehlen

Allgemeiner werden Sequenzdiagramme im Systementwurf dazu eingesetz, Nachrichten und Objektkommunikation beispielhaft und abstrakt darzustellen

Komponentenbildung

• Kohäsion
• Klassen innerhalb einer Komponente bilden ein enges Beziehungsgeflecht (hohe Kohäsion)
• Gegenseitige Bezüge und Aufrufbeziehungen von Klassen einer Komponente
• Kopplung
• Klassen in untereschiedlichen Komponenten sind nur lose gekoppelt
• Möglichst wenig Aufrufbeziehungen und gegenseitige Bezüge

Eine klare Schnittstelle zwischen den Teilsystemen ist die Basis für

• Eine unabhängige Realisierung der Komponenten
• Wiederverwendbarkeit von Kopmonenten
• Austausch von Komponenten

bzw. Vertragsprinzip (rely-guarantee) auf die jeweils anderen Komponenten (Verfügbarkeit, Funktionalität)

Vorteile der Komponentenbildung

• Unabhängigkeit: Komponenten können unabhängig von einander entwicklet werden, wenn die Schnittstellen festgelegt sind
• Testbarkeit: Komponenten können einzeln getestet werden
• Austauschbarkeit: Komponenten können unter beibehaltung der Schnittstelle ausgetauscht werden ohne dass die anderen Komponenten davon betroffen sind
• Austauschbarkeit

Code Konventionen

• Satz von Regeln, nach welchen der Quelltext eines Programms erstellt wird
• Bezieht sich auf Einrückung, Positionierung umschließender Syntaxelemente z.b. Klammer, Einsatz von Kommentaren, Namenskonventionen für Symbole, Reihenfolge der Deklaration von Symbole, Länge und Umfang von Symbole, Schachtelungsziefe, Maximale Zeilenlänge, ...
• Regeln darüber hinaus werden für die statische Qualitätssicherung von Code verwendet (in der Softwarenetwicklung & Projektmanagement VO)

• Hintergrund
• 80% der Lebenszeit eines Softwareproduktes entfallen auf Wartung
• Code wird von vielen Autoren bearbeitet
• Einhalten von Standards bei Auslieferung des Source Codes
• Verbesserung von
• Lesbarkeit
• verständlichkeit
• Wartbarkeit

Code Conventions for the Java Programming Language

• Behandelt den ganzen Entwicklungsprozess damit auch die Einteilung von Dateien, Klassen, File Strukture, ...

Google Java Style Guide

• CamelCase
• Klassifiert auch Sonderzeichen bzw Escaping, Codierung, ...

Hungarian Notation

• Behandelt die Namensvergebung (Sprachen unabhängig)
• CamelCase
• Flags wie z.b. p für pointer, i für index, c für count, f für flag, m_ für member, g_ für globale, ..."

Linux Kernel Coding Style

• Behandelt die Einrückung, verwendung von Klammern (Sprache C)
• Einrückung 8 Zeichen
• 80 Zeichen Zeilenbreite
• Öffnungsklammern in der Oberen 1. zeile beginnen
• Leerzeichen zwischen zuweisungen

Checkstyle

• Tool welches Source Code parst
• Evaluiert entweder Sun Code Conventions oder Google Java Styles
• Visualisiert richtlinien innerhalb des Editors

Java Doc

• Erstellung von HTML-Dokumentationsdateien aus Java Quelltextdateien durch Steuerung durch Meta Tags
• Ziel: Unterstützung des Vertragsprinzips / Spezifikation von Schnittstellen

Versionskontrolle

• Nachvollziehbarkeit: Wann hat sich ein Fehler in das System eingeschlichen?
• Koordination: Wie können mehrere Entwickler gleichzeitig an einer CodeBase arebiten
• Releasemanagement & Archivierung: Einen bestimmten Punkt markieren
• Wiederherstellbarkeit: Auf einen bestimmten Punkt zurück springen

Probleme:

• Beim Pessimitischen Locking kann immer nur 1er schreiben/Lesen
• Beim Optimitischen Locking können alle Lesen. Gelockt wird nur wenn 1er schreibt. Will dann der andere schreiben bekommt er einen fehler und muss zuerst erneut lesen und mergen

Zentrale Versionsskontrolle z.b. svn, cvs

Dezentrale Versionskontrolle z.b. git

CVS Concurrent Versions System

• Für OS Entwicklung
• 2008 eingestellt
• Zentrales Repository
• Delta kodierung / Nur Änderungen der Dateien werden gespeichert daher kann niccht auf einen bestimmten Commit rückgeführt werden
• Unbenannte Files werden nicht Versioniert
• eine Gesamtversionsnummer
• Umgang mit Verzeichnissen Kompliziert

SVN Subversion

• Nachfolger von CVS
• Brauch mehr speicher, hatte nicht alle CVS Features (z.b. tagging)
• Gesamtversionsnummer Revision
• Keine spezielle Semantic für Tagging/Branching (Eigene Filestruktur für z.b. Versionen nötig)

GIT

• Verteiltes VCS
• Sehr flexible workflows (kann cvs, svn workflow simuliern)
• Lokale Commits (Performance Vorteile, Offline Arbeiten möglich)
• Commits indiziert via Hash
• Extrem Populär durch Github (OpenSource bzw Social Coding)
• Jede Datei wird bei jedem Commit festgehalten daher kann man immer überall hin springen

Git Zyklus

Intern funktionieren branches wie pointer

Git Workflow

Build Zyklus

• Compile
• Test
• Package
• Java Doc generierung
• Integration ins Test System
• Automatisches Deployment (Optional)

Make

• Kompilieren von C, C++ QuellCode
• Sinnvoll, wenn kompilierung aus vielen einzelnen Schritten bzw Abhängigkeiten besteht

Ant

• XML Basiert (Schlechte Usability)
• Sehr flexibel, da skripting möglich
• Kein Dependency Management
• Keine Standard Tasks

Maven

• XML Syntax => Pom.xml
• Hat dependency Management revolotioniert (Zentrales Repo, Transitive Abhängigkeiten autom. geladen)
• Legt lokales dependency repository an im "~/.m2" Folder
• Konventionsbasiert (Fixe Ordnerstruktur z.b. java, ressource, test)
• Standardfälle einfach abgedeckt (Compile, test, package, deploy) dafür Spezialfälle schwierig da kein skripting
• Deklarativer Ansatz -> compile, test, deploy müssen nicht angegeben werden

Gradle

• Kombiniert Vorteile von Ant und Maven
• Basiert auf Domänen spezifischer Sprache DSL in Groovy
• Plugin Mechanismus für verschiedene anwendungsfälle z.b. WebApps
• Flexibler als Maven bei der Depenencyauflösung
• Offizielles build Tool für Android

Vagrant

• Tool zur Unterstützung von Software Deployments in unabhängigen Environments
• Open Source Werkzeug
• Automatisches Erzeugen von virtuellen Maschinen
• Platform unabhängig
• Komplette Konfiguration in einer Text-Datei "Vagrantfile"

Einsatzzwecke

• Entwicklungsumgebung für Softwareentwicklung: Platformunabhängig, Portable, Isoliert, Gleiche Umgebung für alle Entwickler
• Eintwicklung + Testing von Deployments: Lokal VirtualBox, Remote Digital Ocean
• Sandboxing = neue Programme testen ohne eigenes System zu "verunreinigen"

Vagrantfile

• Konfiguriert die Virtuelle Maschine
• Ruby Syntax: Keine Ruby Kentnisse notwendig
• Vagrantfile wird im Versionskoontrollsystem abgelegt

Provider

• Virtualiserungslösung
• Standard: VirtualBox
• Vielzahl von Alternativen
• Box = Name für Images verschiedener Provider ... erhältlich im Internet über ein Repository

Provisioning

• Automatisiert die Ausführung
• Softwareinstallation
• Konfiguration
• Projekt Einrichtung
• Beispiel: Shell Script

Workflow

• Start: "vagrant up"
• Programmierung (wärend dessen "vagrant status", "global-statu"s, "ssh", "reload")
• Ende ("vagrant suspend", "halt")

Gesamtkosten eines Softwareprojektes

• Auf 20% Entwicklung kommen 80% Wartung
• Code wird von vielen Autoren bearbeitet
• Projektlaufzeit überdauert oft Projektmitarbeiter
• Hauptarbeit in großen Softwareprojekten besteht im Verstehen des Codes
• Fehlerbehebung in unverständlichen Code kann neue Fehler hervorrufen
• Schlechte Codequalität kostet Geld und Ressourcen in Softwareprojekten

SOLID Prinzipien

Jene Prinzipien sind nicht an die Programmiersprache gebunden

• [S] Single Responsibility Prinzip
• [O] Open Closed Prinzip
• [L] Liskovsches Substitutionsprinzip
• [I] Interface Segregation (Trennung) Prinzip
• [D] Dependency Inversion (Umkehrung) Prinzip

Single Responsibility Prinzip

• Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (C. Martin, 2002)
• Jede Klasse soll nur EINE Verantowrtlichkeit implementieren
• Änderungen der Funktionalitäten sollen nur Auswirkungen auf wenige Klassen haben
• Die Klasse darf nur einen Grund zur Änderung haben daher wenn sich zwei Anforderungen ändern, darf nur eine davon Auswirkungen auf die Klasse haben
• Vermeidung von "Universalklassen" -> Besser Viele kleine Klassen

Open Closed Prinzip

• Module sollten sowohl offen (für Erweiterungen), als auch geschlossen (für Modifikationen) sein
• Klassen sollen offen für Erweiterungen sein
• Klasse sollte geschlossen gegenüber Modifikationen sein (bestehender Code wird nicht verändert)
• Ereichen des Open Closed Prinzips durch Vererbung, Interfaces
• Es können neue Funktionen hinzugefügt werden, ohne den bestehenden Code zu verändern
• Beispiel: Qsort in C (Muss nicht umgeschrieben werden um sortieren neuer Datentypen zu ergmöglichen - eigene Vergleichsfunktion als parameter)

Liskovsches Substitutionsprinzip

• Klassen sollen in jedem Fall durch ihre Unterklassen ersetzbar sein
• Abgeleitete Klassen müssen immer anstelle ihrer Basisklasse einsetzbar sein
• Subtypen müssen sich so verhalten, wie die Basisklasse daher eine abgeleitete Klasse darf ihre Basisklasse erweitern aber nicht einschränken oder verändern

Interface Segregation (Trennung) Prinzip

• Software Elemente sollten nicht von Schnittstellen abhängen, die sie nicht benötigen. Daher dürfen Interfaces auch nur die Funktionen enthalten, die auch wirklich eng zusammen gehöhren
• Vermeidung von "umfangreichen" Interfaces
• Großes Interface = mehr Anhängigkeiten
• Interface Pollution: Klassen müssen Methoden implementieren, die sie nicht benötigen
• Viele kleine Interfaces und keine "fat" Interfaces
• Beispiel: Leere methoden wie beim Java iterator die Methode remove (wird evtl nicht gebraucht)

Dependency Inversion (Umkehrung) Prinzip

• Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Interfaces abhängen. Interfaces sollten nicht on Details Abhängen sondern umgekehrt
• Klassen auf einem höhren Abstraktionslevel sollten nicht von Klassen auf einem niedrigen Abstrakationslevel abhängig sein
• Ziel: Abhängigkeit zwischen Klassen soll es nicht mehr geben und es sollen nur noch Abhängigkeiten zu Interfaces bestehen (beidseitig)
• Abstraktion durch Interfaces/abstrakte Basisklasssen
• Üblich wird zum Auflösen der Interfaces ein Dependency Inversion Container verwendet

Prinzipien der Komponentenkohäsion

Welche Klassen gehöhren zu welchen Komponenten? Diese Entscheidung wird leider oft Spontan und rein kontext bezogen getroffen!

• Reuse-Release-Equivalence Prinzip (REP)
• Common-Closure-Prinzip (CCP)
• Common-Reuse-Prinzip (CRP)

Reuse-Release-Equivalence Prinzip (REP)

• Jede Komponente allein muss releasbar sein! (Die Granularität der Widerverwendung ist die Granularität des Release)
• Eine physische Einheit, die widerverwendet werden soll muss als Release zur Verfügung stehen
• Klassen und Modue aus denen eine Komponente gebildet wird, müssen einer kohärenten Gruppe angehöhren. Klassen und Module einer Komponente müssen einem jeweils gemeinsamen zugeordneten Zweck oder Thema dienen
• Beispiel: Versionierte Bibliotheken, Frameworks, usw bzw Tags und andere Identifier im Versionsverwaltungssystem

Common-Closure-Prinzip (CCP)

• Klassen die aus denselben Gründen zur selben Zeit modifiziert werden, sollen in den selben Komponenten zusammengefasst werden. Anders sollen sie verschiedenen Komponenten zugeordnet werden
• Klassen, von denen zu erwarten ist, dass sie gemeinsam geändert werden müssen, sollten in derseben Komponente zusammengefasst werden.
• Variante des Single Responsibility Prinzips auf Komponentenebene: Es sollte nie mehr als einen Grund geben eine Komponente zu modifizieren
• Beispiel: Gemeinsame Änderung umso warscheinlicher, je mehr Abhängigkeiten zwischen 2 Typen existieren -> strukturelle Kohäsion!

Common-Reuse-Prinzip (CRP)

• Zwingen Sie User einer Komponente nicht in eine Abhängigkeit von Elementen, die sie nicht benötigen
• Klassen und Module, die im Allgemeinen gemeinsam widerverwendet werden gehöhren in dieselbe Komponente
• Klassen zwischen denen keine enge wechselseitige Bindung besteht nicht in dieselbe Komponente
• Beispiel: Containerklasse mit dazugehörigen Iteratoren. Werden gemeinsam widerverwendet weil sie eng miteinander verknüpft sind daher sollten sie in derselben Komponente sein

Spannungsdiagramm

Prinzipien der Komponentenkopplung

• Acylcic Dependencies Prinzip (ADP)
• Stable Denendencies Prinzip (SDP)
• Stable Abstractions Prinzip (SAP)

Acylcic Dependencies Prinzip (ADP)

• Lassen Sie im Schema der Komponentenabhängigkeiten keine Zyklen zu
• Zyklen können z.b. aus großen Entwicklungsteams welche an der gleichen Code Basis isoliert arbeiten resultieren
• Maßnahmen: Weekly Build, Unterteilung der Entwicklungsumgebung in Release fähige Komponenten, Komponenten werden von Entwicklugnsteams explizit freigegeben, Anhängigkeitsstruktur aller Komponentne muss bekannt sein

Auflösen möglich auf 2 Arten

Stable Denendencies Prinzip (SDP)

• Abhängigkeiten sollten in dieselbe Richtung verlaufen wie die Stabilität
• Module, die leicht anzupassen sind, sollen nicht von Modulen abhängig sein, die sich nur mit größerem Aufwand ändern lassen
• Eine Komponente mit vielen eingehenden Abhängigkeiten ist sehr stabil, weil es einen hohen Aufwand bedarf, jegliche Modifikation daran mit allen abhängigen Kompnenten in Einklang zu bringen

Stabilitätskriterien:

• Fanin: Eingehende Abhängigkeiten
• Fanout: Ausgehende Abhängigkeiten
• I: Instabilität = ${Fanout} \over {Fanin +Fanout}$. Dieser Wert schwankt zwischen 0 (maximal stabil) und 1 (maximal instabil)

${I={{1} \over {3+1}}} = {{1}\over{4}}$

• Messgröße I einer Komponente sollte gößer sein als die Messgröße I der von ihr abhängigen Komponente. Daher: Sie sollte in richtung der Abhängigkeit Abnehmen
• Nicht alle Komponenten sollten stabil sein! System wäre sonst unveränderbar

Stable Abstractions Prinzip (SAP)

• Eine Komponente sollte ebenso abstrakt sein, wie sie stabil ist!
• Wie kann eine Komponente, die maximal Stabil ist ($I=0$) auch flexibel genug sein um Anpassungen standzuhalten? Open-Closed Prinzip also offen für Erweiterungen, geschl. für Modifikation z.b. Abstrakte Klassen
• Beziehungen zwischen Stabilität und Abstraktheit: Stabile Komponenten sollen aus Schnittstellen und Abstrakten Klassen bestehen. Stabile und erweiterbare Komponenten erweisen sich als felxibel und beschränken zudem die Softwarearchitektur nicht übermäig
• Abhängigkeiten sollten in Richtung der Abstraktion verlaufen

Bemessung der Abstraktion

• "A" Beschreibt den Grad der Abstraktion einer Komponente
• Verhältnis der Schnittstelleund und abstrakten Klassen zur Gesamtzahl der Klassen in derselben Kopmonente
• "Nc": Anzahl der Klassen in Komponente
• "Na" Anzahl der Abstrakten Klassen und Schnittstellen in Kompinente
• "A" Grad der Abstraktheit $A={{Na}\over{Nc}}$
• Messwertebereich von A liegt bei 0 bis 1
• $A=0$: Komponente enhält keine Abstrakten Klassen
• $A=1$: Komponente besteht ausschließlich aus Abstrakten Klassen

Der I/A Graph

Interpretation

• Zone of Pain: Äußerst Stabile und Konkrete Komponenten z.b. DBS Schema, Utility, Library
• Zone of Uselessness: Nicht implementierte Abstrakte Klassen
• Komponenten sollten an hauptreihe gereiht sein
• Abstand $D=|A+I-1]$: Wenn 0, dann befindet sich die Komponente auf der Hauptreihe. Bei 1 größtmöglich davon Enternt. Solte in der Nähe von 0 (z.b. max 0,1) liegen!

Streu Diagramm

Vererbung

• Vorteile
• Einfache Methode für Wiederverwendung
• Polymorphismus
• Sprachunterstützung
• Nachteile
• Statischer Mechanismus, da die Implementierung der Superklasse nicht dynamisch geändert werden kann (Kompilierzeit)
• Veränderung an der Superklasse können Subklassen beeinflussen (Proble der instabilen Basisklasse)
• Wiederverwendung der Subklase wird eingeschränkt (Abhängigkeit der Subklasse von Superklasse)
• Kapselung wird durhc enge Verdrahtung evtl aufgehoben

Komposition

• Vorteile
• Dynamischer Mechanismus, da die Referenz auf ein anderes Objekt zur Laufzeit bestimmt werden kann
• Kapselung wird nicht verletzt (nur Interface bercksichtigen)
• Nachteile
• Code muss oft mehrmals implementiert werden
• Mehr Klassen müssen implementiert werden
• Systemverhalten ist nicht mehr in einer klassse definiert daher hängt von Klassen Beziehungen ab

Klassifikation von Mustern

• Architekturmuster: Makroarchitektur
• Entwurfsmuster (Design Patterns): Mikroarchitektur
• Analysemuster: Frühe Phasen der Softwareentwicklung

Überblick Entwurfsmuster

• Ein Muster ist eine schematische Lösung für eine Klasse verwandter Probleme
• Muster sind konstruktiv, daher liefen Instruktion zur Lösung
• Abstrakt daher bieten bereits Anwendungsspektrum in vielen Fällen
• Stabil, daher erfassen den stabilen Teil einer Lösung
• Nutzen von Mustern
• Widerverwendung bewährter Lösungen
• Identifierbar: Jedes Muster hat einen Namen -> effiziente Kommunikation durch Standardvokabular

• Ein gutes Entwurfsmuster sollte ein oder mehrere Probleme lösen, erprobtes Konzept bieten, auf Realen Designs asierne, über das offensichtliche hinausgehen, de benutzer in den entwurfsprozess einbinden
• Es sollte beinhalten:
• Name
• Problem
• Lösung: Abstrakte Beschreibung bzw einzelnen Elemente wie Klassen und deren Beziehungen
• Auswirkung bzw Trad-offs

Klassen von Design Patterns

• Erzeugungsmuster: Erzeugung unterstützen bzw entkopeln der Konstruktion eines Objektes von seiner Repräsentation
• Strukturmuster: Klassen, interfaces verbinden um Objekte zu erzeugen die eine neue Funktionalität realisieren?
• Verhaltensmuster: Interaktion zwischen Objekten und Algorhithmen beschreiben bzw Objekte gruppieren um Aufgaben zu lösen, welche nicht von einem Objekt alleine gelöst werden können.

Weiter Muster

• Analysemuster
• Architekturmuster
• Antimuster: Wie man es nicht machen sollte z.b. Gottbjekt, Spaghetti Code

Composite Pattern (Strukturmuster)

• Ein Objekt, welches Instanzen von sich selbst (Branching) oder Instanzen der atomaren bestandteile (Leafes) aufnehmen kann
• Somit kann man baumartige Strutkuren belieber typen erstellen/verwalten
• Beispiel: Shapes die sich aus Kreisen, Dreiecken, Vierecken zusammensetzen
• Push: Das Observable pusht die Neueigkeiten zu den Observern
• Pull: Die Observer pullen die Neuigkeiten von den Observables

Iterator Pattern (Verhaltens muster)

• Sequenzieller Zugriff
• Mehrere Traversierungsarten
• Benutzer soll sich nicht um die interne Struktur kümmern müssen
• Wer kontrolliert iterieren? Wer definiert Algorithmus? Modifikation? Privilegien?

Beteiligte Akteure

• Iterator: definiert eine Schnittstelle für den Zugriff und das Traversieren
• ConcreteIteratr: implementiert Schnittstele, verwaltet die aktuelle Position
• Aggregate: Definiert Schnittstelle für die Erzeugung des Iterators
• ConcreteAggregate: implementiert Schnittstelle fr das Erzeugen eines konkreten Iterators

Zusammenspiel: der konkrete Iterator verwaltet das traversieren und kann den Nachfolger des aktuellen Elements berechnen

Observer Pattern (Verhaltensmuster)

• Subject: Kennt seine Beobachter (Observer). Stellt eine Schnittstelle für das Hinzufügen, entfernen und Benachrichtigen von Beobachtern zur Verfügung
• Observer: Definiert eine Schnittstelle für das Aktualisieren der Beobachter
• ConcreteSubject: Speicehrt den Relevanten Zustand und verschickt Benachrichtigungen an die Beobachter bei einer Zustandsänderung
• ConcreteObserver: Verwaltet eine Referenz auf ConreteSubject. Speichert einen Zustand, der mit dem Zustand des Subjekts konsistent sein sollte. Implementiert die entsprechende Schnittstelle für den Beobachter

Zusammenspiel

• ConreteSubject benachrichtigt seine Beobachter bei jeder Zustandsänderung
• ConcreteObserver kann nach der Benachrichtigung die Zustandsänderung abfragen und den gespeicherten Zustand aktualisieren
• ConcreteObserver kann eine Zustandsänderung im ConcreteSubject auslösen. Es wartet aber auf die Benachrichtung und ändert erst dann den lokal gespeicherten Zustand

• Vorteile: Abstrakte minimiale Kopplung zwischen Objekt und Beobachter. Unterstützung von Multicasting: mehrere Observer können gleichzeitig benachrichtigt werden
• Nachteile: Hohe Änderungskosten: Viele Beobachter! Eine Aktualisierung kann viele Aktualisierungen in anderen Objekten nach sich ziehen.
• -Zusätzliches Protokoll bei Zustandsänderung, wenn man genauere Informationen haben möchte
• Zustandsänderung während einer Aktualisierung

Singleton Pattern (Erzeugungsmuster)

Vorteile:

• Kontrolliert Zugriff auf einzige Instanz
• Erlaubt auch eine ariable Anzahl von Instanzen
• Flexibler als Klassen methoden

Nachteile:

• Exzessive Verwendung vn Singletons simuliert globale Variable
• In welchen Umgebungen ist das Singleton tatsächlich "einzeln"?
• Die Testbarkeit von Singletons ist schwierig
• Synchronisation muss bei nebenläufigen Programmen berücksichtit werden
• In einigen objektorientierten Programmiersprachen gibt es keine Möglichkeit, Klassenmethoden zu schreiben

Abstrakte Fabrik (Erzeugungsmuster)

• Schnittstelle für das Erzeugen von Objektfamilien oder verwandte Obejekte anbieten
• Eine Abstrakte Fabrik (Klasse) wird von mehreren Konkreten Fabriken implementiert weclhe die selben Objekte auf unterschiedliche Art und weise erstellen können
• Die konkreten Klassen sind aber nicht bekannt
• Motivation: GUIs (untereschiedliche look und feels)

Beteiligte Akteure:

• Abstract Factory: Schnittstelle fr Operationen die zur Erzeugung abstrakter Produkte dienen
• Concrete Factory: Implementiert die Operationen fr die ERzeugung konkreter Produktobjekte
• Abstract Product: Definiert eine Schnittstelle für einen Produkttyp
• Concrete Produce: Konkrete Implementierung eines Produkts
• Client: Benutzt nur die Schnittstellen von AbstractFactory, AbstractProduct

Zusammenspiel

• Eine Instanz einer ConcreteFactory zur Laufzeit
• Erzeugt Produktobjekte mit einer bestimmten Implementierung
• Vorteile: ISoliert konkrete Klassen, Austausch von PRoduktfamilien ist sehr einfach, Fördert die Konsistenz zwischen Produkten und Produt familien
• Nachteile: Erweiterung mit neuen Produktfamilien umständlich, Schnittstelle der abstrakten Fabrik legt die Produkte fest

Architekturmuster

Architekturmuster beschreiben den Grundaufbau eines Systems (Makroarchitektur)

Kategorien:

• Modulstrukturen: Ordnen die Komponenten eines Systems in kooperierende Subsysteme (z.b. Schichtenarchitektur)
• Komponenten und Verbindungsstrukturen: Beschreiben Komponenten und deren Interaktion (z.b. Client-Server Pattern)
• Allokationsstrukturen: Zuordnung von Softwarekomponenten zu technischen Komponenten (z.b. Multi Tier Pattern)

Modulstrukturen

• Elemente dieser Struktur sind Module (Softwareeinheit mit definierten Schnittstellen die eine Menge an Services zur verfügung stellen)
• Module repräsentieren einen quellcodegetriebenen Ansatz um eine System zu strukturieren
• Beschreiben die primären Funktionen eines Moduls
• Sind primär statisch und werden aus der Kompilierzeitperspektive heraus angelegt und nicht aus der eigentlichen Laufzeitperspektive

Komponenten und Verbindungsstrukturen

• Zeigen die Laufzeitkomponenten und deren Verbindungen auf
• Schwerpunkt liegt auf der Zusammenarbeit einzelner Systemteile um ein gesamtheitliches Verhalten zu produzieren
• Hauptfokus liegt auf der Prozessstruktur, Ablage und Nutzungssystematik der Daten

Allokationsstrukturen

Beschreiben dei Verwendung von internen und externen Ressourcen durch Softwareelemente zur Laufzeit

Es gibt 3 Arten von Allokationsstrukturen

• Assignmentstruktur: Steltl die explizite Verbindung zwischen Organisationsstruktur und Softwarestruktur dar
• Implementationsstruktur: Stellt die Abbildung der Softwarelemente auf die Dateisystemstrukturen bei der Entwicklung, Integration und Konfiguration dar
• Deploymentstruktur: Stellt die Zuordnung der Softwareelemente zur Hardware und der Kommunikationsstruktur dar

Überblick Architekturmuster

• Modulstrukturen: Layered Pattern
• Komponenten & Verbindungsstrukturen: Client-Server Pattern, Broker Pattern, Peero-to-Peer Pattern, Service Oriented Achritecutre Pattern, Publish-Subscribe Pattern, Model-View-Controller Pattern, Pipe und Filter Pattern, Shared Data Pattern
• Allokationsstrukturen: Map-Reduce Pattern, Multi-Tier Pattern

Layered Pattern (Schichtenarchitektur)

• Schichten sind übereinander angeordnet
• Elemente einer Schicht besitzen einen ähnlichen Abstraktionsgrad
• Unidirektionale "Allowed-to-Use" Bezioehung zwischen den Schichten (Eine Schicht bietet der darüber liegenden Schicht seine Servicces an nicht umgekehrt)
• Beispiele: Kommunikationsprotokolle, Informationssysteme, Betriebssysteme
• Bei der Strikten Schichtenarchitektur darf nur auf die direkt darunterliegende Schicht zugegriffen werden. Ansonsten darf auch auf tieferliegende Schichten direkt zugegriffen werden

Schichten können auch nach rechts oder unten verwendet werden

3 Schichten Architektur (Präsentationsschicht, Anwendungsschicht, Presistenzschicht)

Präsentationsschicht

• Darstellung der fachlichen Oberjekte auf der Bedienoberflächte
• Auslösen und Steuern von Use Cases
• Sendet Daten an die Anwendungsschicht und bereitet die von erhaltenen Daten auf
• Soll möglcihst wenig von der Geschäftslogik wissen
• Keine Kenntnis über die Presistenzschicht
• Sorgt für Dialogkontrolle (Ereignisse wie Buttons lösen Geschäftsprozesse aus)

Typische Fehler der Präsentationsschicht

• Implementiert fachliche Abläufe
• Enthälht keinen Controller (keine Klassen zum Dialogkontroller z.b. Anwendungsschicht übernimmt Controlleraufgaben)
• Enthält redundaten Code (Buttons, Menüs, ...)

Typisch verwendete Entwurfsmuster in der Präsentationsschicht

• Observer Pattern
• MVC Pattern (Kein Design Pattern sondern Archritekturmuster)

Anwendungsschicht

• Realisieren der fachlichen Funktionalitäten der Applikation
• Oft trennung in Vorgangssteuerung und fachliches Modell
• Besitzt keinerlei Wissen über Fensterobjekte usw
• Greift auf die Persistenzschicht über eine Schmale Schnittstelle zu (kein Wissen über DBS, ...)
• Befreiung sämtlicher technischer Aspekte
• Aufgrund projektspez. Aspekte ist die Wiederverwendung relativ gering. Dennoch weist diese Schicht oft ähnliche Strukturen auf

Entwurfsziel

• Die Anwendungsschicht enhält alle Entitätsklassen (Kunde, Konto, Rechnung, ...)
• Die Anwendungsschicht enthält alle Geschäftsprozessklassen (fachliche Abläufe wie z.b. Sitzplatzreservierungen, Anlegen von Konten ...). Ebenso behandelt sie weitreichend Ausnahmen
• Die Anwendungsschicht bestimmt, welche Daten gespeichert werden sollen

Anforderungen an die Anwendungsschicht

• Kohärenz: Sie realisiert ausschließlich die fachlichen Anforderungen
• Self Containment: Realisiert vollständig die fachlichen Anforderungen
• Lose Kopplung: Befreiung möglichst vieler technischer Aspekte
• Information Hiding: Kapselung der fachlichen Abläufe über eine schmale Schnittstelle

Typische Fehler der Anwendungsschicht

• Unvollständigkeit Fachlicher Abläufe
• DBS zugriff
• Verwaltet Objekte aus der Präsentationsschicht

Typisch verwendete Entwurfsmuster in der Anwendungsschicht

• Singleton: für Geschäftsprozessklassen
• Fassade Pattern: Entkoppelung der Anwendungsschicht von der Präsentationsschicht bzw der Persistenzschicht
• Factory Pattern: Auslagerung der Objekterzeugung in eigene Klassen bzw Entkoppelung der Anwendungsschicht von verschiedenen Realisierungen der Presistenzschicht

Presistenzschicht

• Dauerhafte Speicherung der fachlichen Objekte
• Bei verwendung einer relationalen DBS: Abbildung der Objekte auf Tabellen mittels OR Mapping (Objekt-Relationales Mapping)
• Entitätsklassen: Datentragende Klassen z.b. Kunde, Konto realisieren den konsistten Zugriff auf Daten. Ebenso müssen Beziehungen zwischen Entitäten nachgebildet werden. Sie sollen keine Anwendungsspezischen Sonderfunktionen enthalten

Vorteile der 3-Schichten Architektur

• Verständlichkeit: Jede Schicht behandelt eine abgegrenzte Aufgabe, benötigtes Wissen ist Schichtenspezifisch
• Verbessere Projektorganisation
• Widerverwendbarkeit
• Redundanzfreiheit: Jede Fkt ist eindeutig einer Schicht zugeordnet
• Robustheit: Änderungen pflanzen sich nicht auf die benachbarte Schicht fort
• Reduzierter Datenaustausch: Verteilung auf verschiedene physikalische Rechner möglich

Beispiel OSI-Modell

Client-Server Pattern

• Marshalling: Umandeln von Daten z.b. Java Objekte in ein Format z.b. XML, Json.... wird auch als Serialization bezeichnet
• Kommunikationsparadigmen: IPC Inter Process Communication, Remote Invocation z.b. HTTP oder ICMP aber auch RCP Remote Procedure Call
• Indirekte Kommunikation: Über 3.
• Message Queues: Punkt zu Punkt Service -> Producer bzw Consumer Process
• Tuple Spaces: Prozesse speichertn beliebige Elemente in Tupel, andere können diese aus dem Speicher laden bzw löschen

TCP

Transmission Controll Protocol

In Java Socket und Serversocket

UDP

User Datagram Protocol

In Java Datagram Socket und Datagram Packet

Broker Pattern

• Kontext: Implementierung eines Systems mit gemeinschaftlich genutzten Services
• Problem: Strukturierung eines verteilten Systems sodass Clients nicht Art und Ort von Servern kennen müssen?
• Lösung: Definition einer Laufzeitkomponente "Broker" welche die Kommunikation zwischen einer Reihe von Clients un Servern vermittelt

Elemente

• Client
• Server
• Client Side Proxy: Intermediär der die Kommunikation mit dem Broker verwaltet
• Server Side Proxy: Intermediär der die Kommunikation mit dem Broker verwaltet
• Broker

RMI (Remote Methode Invocation)

• JAVA RMI basiert auf dem Broker prinzip
• RMI erlaubt den Aufruf von Methoden entfernter Objekte und folgt dabei typischerweise einem Request-Reply Protokoll

Peer to Peer Pattern

• Gleichwertige Komponenten die Services zur verfügung stellen bzw von einander konsumieren
• Bestehen aus Peers bzw Request/Reploy Connector mit dem verbindungen zum Peer Netzwerk und in weiterer Folge zu anderen Peers hergestellt werden
• Beispiele: File Sharing (BitTorrent, ...), Instant Messageing (GNU Talk, Sype)

Service Oriented Architecture (SOA) Pattern

• Verschiedene Services (z.b. DBS, HTTP) in Dienste kapseln und zu koordinieren

Publish Subscriber Pattern

• Problem: Mehrere Producer bzw Consumer die die gegenseitige Existenz nicht kennen
• Komponenten veröffentlichen (publish) und abonieren (subscribe) Ereignisse (Events)
• Indirekte Kommunikation: Die Kommunikation erfolgt nicht über die Kommunikationseiheiten sonder über einen dritten Teilnehmer (Proxy)
• Message Queues: Punkt zu Punkt Service wobei ein Producer Prozess Nachrichten an die Queue sendet und Consumer Prozesse diese aus der Queue erhalten
• Publisher und Subscriber sind entkoppelt (Ansonsten gleich wie Observer allerdings durch die entkoppelung parallellisierbar)

MVC Pattern

• Trennung in 3 Schichten
• Model: Persistenzschicht
• View: Präsentationsschicht
• Controller: Anwendungsschicht

Pipe und Filter Pattern

• Konvertierung von Datenströmen
• Eingabe -> Konvertierung -> Ausgabe
• Elemente: Filter (liest input, tranfsofmiert und gibt aus output aus), Pipe (connector der output daten eines filters zum input eines anderen transportiert)
• Parallelle Konvertierungen möglich

Shared Data Pattern

• Komponenten müssen große Datenmengen gemeinsam nutzen und bearbeiten
• Die Daten gehören nicht nru zu einer dieser Komponenten
• Lösung: Kommunikation zwischen Komponenten wird durch gemeinsam genutzten Datenspeicher realisiert.

Map Reduce Pattern

• Programme zur Analyse großer Datenmengen sollten verteilt Funktionieren
• Lösung: Lösung für das verteilen der Daten auf Systeme. Dadurch wird eine niedrige Latenzzeit sowie eine hohe verfügbarkeit ermöglicht
• Elemente: Map (führt Extraktions und Tansformationsschritte der Analyse aus), Reduce (Zwischenergebnisse zusammenfassen)

Multi-Tier Pattern

• Mischfoorm aus Komponenten & Verbindungsstrukturen und Allokationsstrukturen
• Problem: Verteilung der Infrastruktur auf verschiedene Geräte (rechtliche, betriebliche, hardware gründe)
• Lösung: Ausführungsstrukturen vieler Systeme als logische Gruppe von Komponenten organisieren (Tier)

Architektur und Anforderungen

• Funktionale Anforderungen
• Qualitätsanforderungen
• Einschränkungen (Entscheidungen die bereits getroffen wurden z.b. System, Kapazitäten, ...)

Quallitätseigenschaften

• Eigenschaften zur Systemlaufzeit: Verfügbarkeit, Leistungsfähigkeit, Verwendbarkeit
• Eigenschaften zur Enticklung: Modifizierbarkeit, Testbarkeit
• Konflikte Möglich: Kompromiss findung bei Architektur Entscheidung

Qualitätsszenario

• Stimulus: Ereignis
• Stimulus Source: Auslöser
• Response: Wie reagiert das System auf das Ereignis
• Response Measure: Bestimmt ob die Qualitätsanforderung zufriedenstellend erfüllt ist
• Environment: Umgebung in der das Szenario statt findet
• Artifact: Teilsystem welche die Qualitätsanforderungen betrifft
A

Guideline für Qualitätsentscheidungen

7 Kategorien von Designentscheidungen

• Aufteilung der Verantwortlichen
• Koordinaten Modell (Mechanismen zur Interaktion architektonischer Elemente)
• Datenmodell
• Management von Ressourcen
• Zuordnung zwischen architektonischen Elementen
• Build Time Entscheidungen
• Technologieauswahl

Überblick Qualitätseigenschaften

• Verfügbarkeit
• Interoperabilität
• Modifizierbarkeit
• Leistungsfähgikeit
• Sicherheit
• Testbarkeit
• Verwendbarkeit

Verfügbarkeit

• Fehler maskieren bzw reparieren
• Wie oft bzw wie lange ist ein Service verfügbar Uptime Downtime
• Finden: Ping, Monitor, Heartbeat, TimeStamp, Self-Test
• Recover: Redundancy, Spare, Rollback, Upgrade, Retry
• Reintroduction: Shadow, Resync
• Prevention: Transaction, Predictive Model, Exception Prevention, Increase Competence Set

Interoperabilität

• Definiert in welchem Maße 2 oder mehr Systeme sinvoll Informationen über eine Schnittstelle zu einem bestimmten Kontext austauschen können
• Taktiken: Locate (Discover), Manage Interfaces (Orchestrate)

Modifizierbarkeit

• beschreibt wie leicht eine große Komponente veränderbar ist ohne dass dies große Auswirkungen auf andere Komponenten im System hat
• Taktiken: Modul verkleinern / splitten, Kohäsion erhöhren, Kopplung vermindern (Refactoring), Bindings verschieben

Leistungsfähgikeit

• Beschreibt die Fähigkeit eines Systems, Zeitvorgaben zu erfüllen
• Taktiken: Ressourcen Anforderungen kontrollieren, Overhead reduzieren, Ausführungszeiten begrenen, Ressourcen anders verwalten (kopien, queue größen, scheduling), Algorithmen verbessern?

Sicherheit

• Vertraulichkeit (Schutz vor Offenlegung der Daten), Integrität (Schutz gegen Manipulation), Verfügbarkeit (Schutz vor Beeinträchtigung des Zugriffs auf Ressource)
• CIA Triade = Availabilty - Integrity - Confidentiality
• Taktiken: Angriffe Erkennen (Detect Intrusion, Service Denial, Verify Message Integrity, Detect Message Delay), Angriffe Abwehren (Aktoren identifizieren/authentifizieren, Zugriff limitieren, Daten vershclüsseln, Entitäten aufteilen), Reagieren: (Zugriff einschränken, Aktoren informieren, Sperren), Recover (Audit Tail, Restore)

Testbarkeit

• Ist der Grad zu dem ein Softwareartefakt den Test in einem gegebenen Testkontext unterstützt
• Taktiken: System Status Kontrollieren (Interfaces spezalisieren, record/playback, Abstract Data Sources, Sandbox, Assertions), Komplexität einschränken (Struktur einschränlen, Nicht deterministisches verhalten einschränken)

Verwendbarkeit

• Die Benutzerfreundlichkeit beschreibt wie einfach der Benutzer eine gewünschte Aufgabe ausführen kann und welche Art von Benutzerunterstützung das System bietet
• Taktiken: User Initiativen implementieren (Cancel, Undo, Pause/Resume, Aggregate), System initiative (maintain Task Model, maintain User Model, maintain System Model)

Spring Framework

• Quelloffenes Applikationsframework
• Stellt umfassende Infrastruktur zur verfügung
• Basieriert auf existierenden Frameworks (ORM Mapping, JEE Framework, Logging)
• Ziele: Abhängigkeiten im Code reduzieren, Ganzheitliche Lösungen bereitstellen, Reduzierungt von Etnwicklungskosten bzw Aufwand
• Entwicklung basiert auf Plain Old Java Objects POJO

POJO

• Normake Java Klassen ohne komplexe Strukturen
• Niedrige Kopplung und Starke Kapselung
• Erben von keiner Elternklasse, Implementieren kein Interface

Architektur Spring Basierter Web Anwendungen

• Präsentationsschicht: Java Server Faces, Spring MVC
• Anwendungsschicht: Java Beans
• Persistenzschicht: JDBC, JPA, Hibernate

Spring Architektur

Module des Spring Frameworks

Spring ist streng modular aufgebaut mit möglichst wenig Abhängigkeiten zwischen den einzelnen Modulen

Wichtige Module:

• Core: Der Dependency Injection Container (Grundlage des Framworks)
• Web: Eigene Webframeworks und Unterstützung für diverse Weitere Frameworks/Technologien (JSF,JSP)
• Data Access/Integration: Datenbanktugriff, ORM Mapping, Transaktionsmanagement
• Spring Boot: Einfaches Deployment von Spring Applikationen

Spring Vorteile

• Effektive Verwaltung der Objekte in der Mittelschicht
• Es müssen keinerlei Singletons mehr per Hand geschrieben werden
• Es müssen keinerlei Konfigurationsformate mehr erdacht und implementiert werden
• Der Aufwand gegen Interface szu implementiert wird fast auf null reduziert
• Leicht zu testen
• Leichtgewichtige Architektur

Java Bean

• Write once, run everywhere (WORA)
• Eigenständige (self-contained) platform-unabhängige Softwarekomponente implementiert in Java
• Eigenschaften: ÜBertragbar, Widerverwendbar, Interoperatibilität
• Scope: z.b. @Scope("session")

Dependency Injection

• Entwurfsmuster um lose gekoppelte Anwendunge zu entwickeln
• Form von Steuerungsumkehr (Hollywood: Dont call us, we call you)
• Funktionen eines Anwendungsprogrammes werden bei einer Standardbibliothek registriert und von dieser zu einem späteren Zeitpunkt aufgerufen
• Das Framework steuert den Lebenszyklus von Objekten
• Vorteile: Trennung zwischen Konfiguration und Verwendung eines Services, Imeplmentierungen können leicht durch die Konfiguration abgeändert werden, Verbesserung der Testbarkeit von komplexen Anwendungen, Lose gekoppelte Komponenten

• Konstruktor Injection: Abhängigkeiten andere Klassen werden über den Konstruktor zur Verfügung gestellt
• Setter Injection: Abhängigkeiten andere Klassen werden über eine Methode z.b. setter zur Verfügung gestellt
• Interface Injection: Das Modul der injizierten Klasse definiert eine SChnittstelel, die von abhängigen Klassen implementiert werden muss um zur Laufzeit die Abhängigkeiten zur Verfügung gestellt zu bekommen

Spring Funktionssweise

Spring Container

• Mit Hilfe des Spring Containers könenn aus Java Beans Anwendungen in belieber Umgebung lauffähig gemacht werden
• Er erzeugt alle Objekte und verknüpft (wires) diese miteinander durch setzen der benötigten Properties
• Führt dependency injection durch
• Das Interface "org.springframework.context.ApplicationContext" repräsentiert den Spring IoC Container
• Ist verwantowrtlich für die Instanzierung, Kinfugration, Zusamensetzung der Geschäftsobjekte POJOs
• Bekommt Instruktionen durch das lesen eines Config-Metadata Files oder von Annotationen in Java Klassen
• Verschiedenste Implementierungen des ApplicationContext Interface werden zur Verfügung gestellt

Configuration Metadata

• Teilt dem Spring Container mit weid ie Objekte instanziert, konfiguriert und zusammengesetzt werden sollen
• xml format
• kann auch als Annotation oder Java Code bestehen
• Min. 1 Java Bean Definition
• Beans repräsentieren Objekte aus denen sich Anwendung zusammensetzt

Spring Container Instanziierung

Spring Boot

• Erzeugt automatisch Standalone Spring Applikation
• Erleichtert die Konfiguration und das Deployment von Spring Applikationen
• Erleichtert den Einsteig in die Entwicklung von Spring Applikationen
• Liefert eine Vielzahl von nicht-funktionalen Anforderungen
• Keine Codegenerierung
• Keine XML Konfigurationen notwendig

Annotationen

• @Component: Komponente
• @Controller: MVC
• @Service: Geschäftslogik
• @Repository: Datenbankzugriff

Scope Annotation

• Singleton: Eien Isntanz der Bean pro Spring IoC Container
• Prototype: Beliebige Anzzahl von Bean Instanzen in der Klasse
• Request: Eine Instanz der Bean pro HTTP Request
• Session: Eine Instanz der Bean pro HTTP Session
• Weitere: Globalsession, Application, Wesocket, ...

OR Mapping Schritte

• Auswahl der persistenten Klassen
• Hinzufügen des OID Attributs (Objektreferenz, Primärschlüssel in der DB)
• Abbildung der Klassen auf Entitäten
• Abbilden der Beziehungen und Überführung ins physikalische Datenmodell

DB Synchronisationszustände

• New: Obj noch nicht in db (insert)
• Clean: Zustände gleich
• Dirty: Zustände unglich -> UPDATE
• DELETE: Obj soll gelöscht werden

Vererbung

• 1 Tabelle für die gesamte Hierarchie: Einfache Implementierung, einfacher zugriff, sehr hohe kopplung, schneller datenzugriff, mittlerer Polymorphismus
• 1 Tabelle für Jede Konkrete Klasse: Mittlere Implementierung, einfacher zugriff, hohe kopplung, schneller datenzugriff, geringer Polymorphismus
• 1 Tabelle für jede Klasse: Schwierige Implementierung, mittlerer zugriff, geringe kopplung, schneller datenzugriff, hoher Polymorphismus

Persistenzschicht Spring garantiert

• Alle an transaktion beteiligten objekte werden upgedatet
• commit wenn erfolgreich
• rollback bei fehler

JPA Java Persistene API

• Objekt relationales Mapping von Java objekten in Relationale Datenbnaken
• Ermögliocht das persistieren von POJOs
• Stellt Objekt Relationale Anootation bzw Metadaten zur verfügung
• Implementiert Dienste der Persistenzschicht
• Ermöglicht DB Abfragen über Java Persistence Query JPQL (ähnlich SQL) "@Query(...)"
• Jedes Pojo wird aufeine einzelne Tabelle abgebilded

Java Persistence Annotations

• Entitäten: @Entity, @Table, @Column, @Id, @GeneratedValue
• Beziehungen: @OneToOne, @OneToMany, @ManyToOne, @ManyToMany
• Vererbung: @Inheritance

H2 Datenbank

• relationales DBMS in Java
• Open Source und Platformunabhängig
• In Memory DB
• Schnittstellen: SQL, JDBC (Java Database Connectivity)

Java Server Faces

• Java framework für WEB UIs
• MVC Konzept (View: Baumstruktur aus JSF Komponenten, Controller: Beans, Model: Pojos)

XHTML

• Extensible Hyptertext Markup Language
• Html ist nicht xml konform und hat zu viele freiheiten
• Leichter zu verarbeiten
• Tags, Attribute muessen klein geschrieben werden, attribute muessen immer wert haben, immer abgeschlossener tag notfalls /

Lebenszyklus einer http anfrage in JSF

HTTP

• Hypertext Transfer Protokoll
• Get, Post, Put, Delete
• StatusCodes: 1XX (nicht abgeschlossen), 2XX (Empfangen und akzeptiert), 3XX (Weitere Aktion erforderlich), 4XX (Client seitiger fehler), 5XX (Server Seitiger Fehler)

Anforderungen an eine effektive Dokumentation

• Hilfreich
• Korrekt
• Aktuell
• Einfach zu finden
• Leicht verständlich
• Leicht änderbar

Tipps für eine effektive Dokumentation

• Ernenn Sie eine verantwortliche Person
• Dokumentieren Sie methodisch sparsam (weniger ist oft mehr)
• Klären Sie immer top-down, arbeiten Sie nach Bedarf anders
• Fokussieren Sie auf Gründe statt auf Tatsachen
• Stellen Sie Anforderungen immer vor Prinzipien
• Trennen Sie volatile und bleibende Dokumentation
• Dokumentieren Sie redundanzfrei, falls Möglich
• Erklären Sie "eindeutig"
• Etablieren Sie eine positive Haltung zur Dokumentation
• Dokumentieren Sie vom Standpunkt ihrer Leserschaft

Dokumentation mittels arc42

Grundlagen

• Bewährter, praxisnaher Standard zur Dokumentation und Kommunikation von Softwarearchitekturen
• Zielsetzung: Was ssollen wir über unsere Architektur aufschreiben bzw wie sollen wir es Dokumentieren?
• Aktuelle Version 7
• Seit 2005 in vielen Unternehmen im Einsatz
• Grundprinzipien: Klare Struktur, Unabhängig von Entwicklungsvorgehen, Architekturdokumentation mit wenig Aufwand

Überblick

• Einführung und Ziele
• Randbedingungen
• Kontextabgrenzung
• Lösungsstrategie
• Bausteinsicht
• Laufzeitsicht
• Verteilungssicht
• Querschnittliche Konzepte
• Entwurfsentscheidungen
• Qualitätsanforderungen
• Risiken und technische Schulden
• Glossar

Einführung und Ziele

• Beschreibt die wesentlichen Anforderungen und treibenden Kräfte, die Softwarearchitekten und Entwicklungsteams berücksichten müssen
• Wesentliche Aufgabenstellung und fachlichen Anforderungen, Motivation, als text oder tabellarische Use-Case form
• Qualitätsziele für die Architektur: Top3-Top5. z.b. Sicherheit, Testbarkeit, ... Motivation auch hier (Form=Tabelle)
• Relevante Stakeholder und deren Erwartungshaltung: Personen, Rollen, Organisationen (Form=Tabelle)

Randbedingungen

• Inhalt: Vorgaben die den Entwurf bzw die Implementierung einschränken (Firmen einschränkungen, Budged, hardware, personal, ...)
• Motivation: WO liegen Freiheitsgrade?
• Form: Einfache Tabellenfrom der Randbeidngungen mit Erläuterung

Kontextabgrenzung

• Inhalt: Grenz das System von allen Kommunikationspartnern ab. Externe Schnittstellen werden festgelegt! Ein und Ausgaben sowie der Technische Kontext (Kanäle, Protokolle, Hardware) wird definiert.
• Motivation: Die Schnitstellen sind Kritische aspekte! Sie müssen gut verstanden werden
• Form: Kontextdiagramme, Listen
• Fachlicher Kontext: Hierzu gehöhren user, detaien und andere ressourcen
• Technischer Kontext: Geräte, verwendete Protokolle, Übertragungsmedien, ...

Lösungsstrategie

• Inhalt: Kurzer Einblick über die Grundlegenden Entscheidungen und Lösungsansetze: Technologieentscheidungen, Zugänge, Erreichen der Qualitätsanforderungen, relevante Organisatorische Entscheidungen
• Motivation: Die allerwichtigsten Entscheidungen bilden wesentliche Eckpfeiler der Architektur
• Form: Kurze Zusammenfassung

Bausteinsicht

• Inhalt: Statische Zerlegung des Systems in Bausteine: Module, Komponenten, Subsysteme, Klassen, Interfaces, Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers, Funktionen, Karkos, Operationen, Datenstrukturen sowie deren Beziehungen
• Motivation: Überblick über den Quellcode behalten indem die Struktur durch Abstraktion verständlich gemacht wird
• Form: Hierarchische Sammlung von Black und Whiteboxen in 3 Ebenen

Laufzeitsicht

• Inhalt: Erklärt konkrete Abläufe und Beziehungen zwischen Bausteinen in Form von Szenarien aus folgenden Bereichen: Abläufe der Features, Interaktion an kritischen externen Schnittstellen, Betrieb &Administration, Fehler und Ausnahmeszenarien
• Motivation: Wie werden die Bausteine ihre Aufgaben erfüllen und zur Laufzeit miteinander kommunizieren
• Form: Aufzählung, Umgangssprache, Aktivitäts oder Flussdiagramme, Sequenzdiagramme

Verteilungssicht

• Inhalt: Technische Infrastruktur auf der das System ausgeführt wird bzw die Abbildung von Software-Bausteinen auf diese Infrastruktur
• Motivation: Software läuft nicht ohne Infrastruktur
• Form:

Querschnittliche Konzepte

• Inhalt: Beschreibt übergreifende prinzipiell Regelungen und Lösungsansätze die an mehreren Stellen (querschnittlich) relevant sind. Fachliche Modelle, Implementierungsregeln, Entwurf und Architekturmuster, ....
• Motivation: Konzepte bilden die Grundlage für konzeptionelle Integrität
• Form: Beliebig z.b. MindMap

Entwurfsentscheidungen

• Inhalt: Wichtige, teure, große oder riskante Architektur oder Entwurfsentscheidungen inklusive der jeweiligen Begründungen
• Motivation: Stakeholder sollten die wichtigsten Entscheidungen verstehen
• Form: Liste/Tabelle nach Wichtigkeit geoordnet, Einzelne Unterkapitel je nach Entscheidung

Qualitätsanforderungen

• Inhalt: Qualitätsanforderung als Qualitätsbaum mit Szenarien an den Blättern dargestellt
• Motivation: Überblick
• Form: Baumstruktur
• Qualitätsszenarien: Beschreiben wwas beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht

Risiken und technische Schulden

• Inhalt: Nach prioritäten geordnete Lsite der erkannten Architekturrisken und/oder Teschnischen Schulden
• Motivation: Die Architekturrisiken und/oder Teschnischen Scchulden sollen gezielt ermitteln, bewertet und ihren Management-Stakeholdern (Projektleitung, ..) transparent gemacht werden
• Form: Liste oder Tabelle, eventuell mit vorgeschlagenen Maßnahmen zur Risikovermeidung, Minimierung oder dem Abbau der teschnischen Schulden

Glossar

• Inhalt: Die Wesentlichen Technischen/Fachlichen Begriffe die Stakeholder im Zusammenhang mit dem System verwenden
• Motivation: Relevante Begriffe klar definieren, so dass alle Beteilgiten diese Begriffe identisch verstehen, vermeiden können
• Form: 2 Spaltige Tabelle mit Begriff und Definition. Eventuell weitere Spalten mit Übersetzungen falls notwendig