Erläuterungen zu den Folien

---

Folie 1: Übersicht / Themen

Zum Titel des Vortrags: Aus der vielfältigen Bedeutung des Begriffs Postmoderne in der Kunst scheint mir eine Charakterisierung gut auf die heutige Kunst der Softwareentwicklung zu passen:

Die anscheinende "Rückbesinnung" auf Geschichte und Traditionen aber erweist sich als Versuch, die überlieferten Verfahrensweisen zu einem neuen Ganzen zu collagieren.

Die seit Jahrzehnten andauernde "Softwarekrise" wurde mit etlichen Rezepten und Vorgehensschemen versucht zu bändigen. Nach dem Boom der objektorientierten Analyse- und Designmethoden muss man feststellen, dass diese auch nur einen kleinen Bereich der Softwareentwicklung nachhaltig verbessert haben, und dass eine wohldosierte Kombination mehrerer vorteilhafter Ansätze erst zu durchgängigem Erfolg führen kann.
Auch in der Architektur, aus deren Umfeld die nützliche Welt der Patterns entlehnt worden ist, wird erst durch die Verbindung der Moderne mit traditionellem ästhetischen Empfinden wieder eine sowohl funktionale als auch menschenverträgliche Baukunst erreicht.

Folie 2: Softwareentwicklungstechniken

Eine Klassifikation wichtiger Techniken zur Unterstützung und Steuerung der Softwareentwicklung. Hierzu gehören neben sogenannten Entwicklungsmethoden auch Entwicklungsparadigmen / -philosophien / -strategien, Entwicklungsumgebungen, und organisierende Entwicklungsprozesse.

Folie 3: Patterns

Mit dem Prinzip der systematischen Sammlung von Patterns soll der Erfahrungsschatz aus Softwaredesign und -entwicklung zum generischen Lösungsansatz häufiger Probleme geordnet und leicht zugänglich gemacht werden.
Die Folie stellt ein Klassifizierungsschema für Patterns (nach Buschmann) und die schematische Beschreibung von Patterns dar.

Folie 4: Ein Architektur-Pattern

Das schon etwas länger bekannte sogenannte Model-View-Controller-Pattern dient der funktional entkoppelten Aufgabenteilung bei interaktiven Anwendungen.

Folie 5: Ein Programmierkultur-Pattern (im Vortrag ausgelassen)

Auch Programmierstile können als Patterns aufgefasst werden, da sie (wenn auch weniger problemorientiert) typische Herangehensweisen für die Programmieraufgabe nahebringen. Das Pattern des funktionalen Programmierens führt oft zu übersichtlicheren, kürzeren und leichter verständlichen, also auch besser wartbaren Programmen und hat im Zeitalter der Objektorientierung nichts von seiner Bedeutung verloren. (Viele Lehrbücher vernachlässigen das leider und verbreiten umständliche imperative Lösungen für im Kern funktionale Probleme.)

---

Folie 6: Beispiel Industrieprojekt

Zur exemplarischen Demonstration des Einsatzes verschiedener Techniken, zu denen auch spezifische Patterns gehören, werden Charakteristika eines Industrieprojekts vorgestellt, das mit der geforderten Hochverfügbarkeit besondere Anforderungen auch an die Entwicklungsumgebung stellt.

Folie 7: Einsatz von Entwicklungstechniken im Industrieprojekt

Relevanz und Verwendungsziel verschiedener Techniken für ein exemplarisches Projekt werden zusammengefasst.

---

Folie 8: Beispiel 0 (sequence diagram): Prozesse und Sessions im Framework

An der Komplexität (unter Vernachlässigung der Details) eines Sequenzdiagramms für Prozesskoordination im hochverfügbaren System wird das Pattern einer spezifischen Prozessorganisation gezeigt, bei der die Bearbeitung einer großen Zahl virtueller Nutzerprozesse durch deutlich weniger tatsächliche Prozesse (Threads) vorgenommen wird.

Folie 9: Beispiel 1 (sequence diagram): Komponentenmodell im Framework

Im Komponentenmodell ist einiges an expliziter und impliziter Initialisierung durchzuführen, bevor Komponenten von einander Dienstleistung in Anspruch nehmen können.

---

Folie 10: Beispiel 2 (use case diagram): Funktionalität einer Komponente XY

Für eine abstrahiert dargestellte Komponente wird der Einsatz von UML-Diagrammen für die Use-Case-Beschreibung gezeigt.

Folie 11: Beispiel 3 (class diagram): Implementierung einer Komponente XY

Dieses Klassendiagramm sah in der tatsächlichen Designphase der Komponente noch ganz anders aus. Das zeigt die relative Bedeutung des Ansatzes "Design-Methode" im dargestellten Beispiel.

Folie 12: Beispiel 4: Klassendiagram als Datenmodell-Beschreibung (im Vortrag ausgelassen)

Ein UML-Klassendiagram kann auch als Datenmodell-Beschreibung genutzt werden. So wird die einheitliche Notation zur Dokumentation eingesetzt.

---

Folie 13/14: Programmierbeispiel 1: Factory für Komponente XY

Das Programmierbeispiel Teil 1 zeigt einige Framework-spezifische Patterns, die in der Factory einer Komponente realisiert werden. Hierbei ist nicht zuletzt die Framework-eigene Realisierung des Variablen-Kontextes bemerkenswert; sie wird im Folgebeispiel noch klarer. Durch diesen Mechanismus wird das Mapping vieler virtueller auf wenige reale Threads möglich.

Folie 15: Programmierbeispiel 2: Framework-Einbettung eines XY-Objekts

Hier wird insbesondere dargestellt, wie ein Objekt eines realen Threads mit Hilfe des Frameworks auf Variablen des virtuellen Threads zugreifen kann.

---