Advanced Patterns and Frameworks

Advanced Patterns and Frameworks 

WAM: Framework Konstruktion 

Quelle: Prof. Heinz Züllighoven: 

Das objektorientierte Konstruktionshandbuch 

SS 2005 

Peter Sommerlad

Historie 

� Wie baut man Frameworks für fachliche 

(GUI-) Applikationen? 

� ein erfolgreicher Ansatz: WAM 

� GEBOS, C++ System für Banken (D) 

� UBS WAM-Team (bis ca. '99) 

� Projekte von Züllighoven und Mitarbeitern 

� Eclipse ! 

� siehe www.jwam.de als Java Inkarnation 

� Quelle Züllighoven: Objektorientiertes 

Konstruktionshandbuch 

� neuer als Heinz Züllighoven: Object-oriented 

Construction Handbook (2005) 

WAM: Werkzeug, Automat und Material Advanced Patterns and Frameworks 2

Anwendungsbereich WAM 

� Applikationen für Sachbearbeiter bzw. 

"Knowledge Worker" 

� Arbeitsfluss nicht strikt vorgegeben 

� Reichhaltige Landschaft von Aufgaben 

� Mensch braucht Kontrolle über Abläufe 

� er weiss am besten, was wie zu erledigen ist 

� kreative Freiheit notwendig 

� Flexibilität der Arbeit 

� neue Aufgaben und Abläufe 

� rascher Wandel der externen Anforderungen 

� unterstützende Software muss flexibel 

erweiterbar und anpasspar sein Framework! 


Leitbild/Metapher 

� Die Gestalt von Softwaresystemen sollte 

durch ein Leitbild/eine Metapher geprägt 

sein. 

� bringt konzeptuelle Einheitlichkeit 

� erleichtert Verständnis für Anwender 

� vereinfacht Software Design 

� Beispiel: Fabrik-Metapher 

� Anwender: 

� Maschinen-Bediener 

� Software: 

� Maschine 

� Zusammenarbeit: 

� Fliessband/Workflow 


Leitbild WAM 

Experten-Arbeitsplatz 

� typische Umgebung eines Sachbearbeiters 

Hamburger Sparkasse 

Datum, Unterschrift 

Kontonummer BLZ 

Kreditinstitut 

Empfänger 

Verwendungszweck 

Betrag 

Überweisungen 

Vertrag 

Kundenakten 

Rechner 

Post-Its 

Wiedervorlagemappe 

Formulare 

Accounts 

Agenda 

WAM: Werkzeug, Automat und Material Advanced Patterns and Frameworks 5 

Stift 

Stapel

Guiding 

Metaphor 

Leitbilder für Software 

(Guiding Metaphors) 

Object Worlds Virtual worlds 

populated with 

active objects (e.g. 

agents) 

Direct Manipulation Manipulating 

working objects like 

using our hands 

Factory Guiding and 

controling work in 

an assembly line 

like fashion 

Expert Workplace Supporting experts 

in their work by 

creating a work 

environment with 

adequate equipment 

Design Goal Role of Users Role of 

Developers 

Originators of initial 

orders; triggers 

Independent 

workers, acteurs 

Creators of mini 

worlds 

Constructors of 

artefacts 

Machine operators Machine 

constructors and 

machine fitters 

Experts Tool designers, 

work place 

designers 


Leitbild WAM 

� Expertenarbeitsplatz 

mit 

� Arbeitsbereich (workspace) 

auf dem 

� Materialien (materials) 

� Akten, Agenda, Formulare,... 

mit 

� Werkzeugen (tools) 

� Stift, Rechner, Mappen, ... 

bearbeitet werden. Zusätzlich 

� Automaten für repetitive Abläufe 

� Kopierer, Shredder, Belegscanner 


Material (material) 

� Materialien sind (virtuelle) Gegenstände, die 

schliesslich zum Arbeitsergebnis werden. 

� Materialien werden mit Werkzeugen und 

Automaten bearbeitet 

� Materialien repräsentieren domänenspezifische 

Konzepte 

� Materialien müssen für eine spezifische 

Aufgabe geeignet sein. 

� Oft können Eigenschaften (nicht-computerisierter) 

Arbeitsgegenstände auf Software-Materialien 

übertragen werden. 


Werkzeug (tool) 

� Ein Mensch kann mit Hilfe eines Werkzeugs 

Materialien bearbeiten oder anschauen um 

eine bestimmte Aufgabe durchzuführen. 

� Ein Werkzeug unterstützt wiederkehrende 

Tätigkeiten. 

� Ein Werkzeug kann für verschiedene 

Aufgaben nützlich sein. 

� Ein Werkzeug wird benutzt und wieder zur 

Seite gelegt. 

� Ein Software-Werkzeug ermöglicht den 

interaktiven Umgang mit Arbeitsgegenständen 


Arbeitsumgebung & -platz 

work environment - workspace 

� Eine Arbeitsumgebung ist der Ort, 

an dem Werkzeuge, Materialien und andere 

Objekte bereitliegen und dömanenspezifisch 

arrangiert sind. 

Desktop 

Metapher 

� Die Arbeitsaufgaben werden am Arbeitsplatz 

erledigt. Die Arbeitsumgebung beinhaltet weitere 

(öffentliche) Bereiche, die vom Arbeitsplatz aus 

zugänglich sind. 

� Der individuelle Arbeitsplatz ist in der Regel vor 

Fremdzugriff geschützt 

� In einem Ein-Benutzer System sind 

Arbeitsumgebung und Arbeitsplatz in der Regel 

identisch. 


Automat 

(automaton) 

� Ein Automat erledigt Routineaufgaben, die vorab 

festgelegt werden können und immer wieder 

identisch ablaufen. 

� Ein Automat benutzt und bearbeitet Materialien 

und liefert ein definiertes Resultat. 

� Normalerweise arbeiten Automaten im 

Hintergrund, sobald sie für die Arbeitsumgebung 

konfiguriert wurden. 

� Menschlicher Eingriff beschränkt sich dann auf das 

Starten eines Automaten oder die Abfrage des 

Zustands. 


Behälter 

Container 

� Ein Behälter beinhaltet, verwaltet, ordnet 

und liefert Materialien. 

� normalerweise besitzt er dazu ein 

Inhaltsverzeichnis. 

� Man kann gleichartige Objekte oder eine 

definierte Menge unterschiedlicher Objekte 

in einem Behälter speichern. 

� Behälter repräsentieren oft einen 

Arbeitsablauf und sammeln die dazu 

gehörenden Objekte. 

� Damit dienen sie Kooperation und Koordination 


WAM Patterns 

Originalversion deutsch 



modernere Version english 

Design-Patterns 

Konzept-Patterns 


Database 

GUI 

connection 

Message broker 

Architekturmodell mit 

Layers (JWAM) 

Domain-specific 

application 

Domain container 

Host 

encapsulation 

Domain values Testing 

Work environment 

Technology 

Handling and 

presentation 

Component model Design by Contract MOP 

Material 

construction 

Tool 

construction 

Desktop 

Registry 

Forms 

Language extensions 


Influencing 

factors 

leitmotiv 

domain knowledge 

user groups 

pilot 

organisations 

WAM Entwicklungsprozess 

Dokumente 

Glossaries 

System 

Visions 

documentation 

guidelines 

Scenarios 

Prototypes 

Development 

documents 

design 

guidelines 

programming 

guidelines 

Meta documents 

Concept 

Model 

Cooperation 

Pictures 

Purpose 

Tables 

design 

patterns 

Project 

documentation 

project 

agreement 

protocols 

identified 

requirements 

base lines 

project stages 


Handling 

& Presentation 

guiding metaphor & 

design metaphors 

Application 

domain 

analysis 

Entwicklungsmodell 

aus [Züllighoven2005] 

Model of 

application 

domain 

architecture & 

design patterns 

design 

design 

guidelines 

Model of 

application system 

usage 

model 

design 

model 

framework 

& libraries 

implementation 

model 

Technology 

used 

technology 

of system basis 

system 

basis 

application 

system 


WAM Konzeptpatterns 


Zusammenhang Werkzeug 

und Material 

� Wie teilen wir ein interaktives Anwendungssystem so 

in Komponenten auf, dass ein Anwender seine 

Aufgaben je nach Arbeitssituation erledigen kann? 

� Komponenten sollen fachlich motiviert sein. 

� Erkennbarer Zusammenhang mit den bereits am 

Arbeitsplatz vorhandenen Gegenständen bestehen 

� Übertrage die Metaphern WAM auf ein 

Anwendungssystem. 


Use Case 

Model 

System- 

Grenze 

Use 

Cases 

Zusammenhang Werkzeug 

und Material (Lösung) 

� Modelliere ein Anwendungssystem aus 

Anwendersicht im Kern als eine sinnvolle 

Ansammlung von Materialien und Werkzeugen, 

die dazu geeignet sind, die verschiedenen 

Aufgaben an einem Arbeitsplatz zu erledigen. 

� lege fest, welche der bisherigen Aufgaben vom 

zukünftigen System unterstützt werden sollen und 

welche weiterhin konventionell zu erledigen sind. 

� Die zu unterstützenden Aufgaben definieren den 

Kontext der jeweiligen Arbeitszusammenhänge, in 

denen Benutzer je nach Situation mit geeigneten 

Werkzeugen die entsprechenden Materialien 

bearbeiten. 


Materialentwurf 

� Wie können wir die wesentlichen Materialien in der 

Applikationsdomäne identifizieren? 

� Materialien sind konzeptuelle Elemente 

� Design der Materialklassen muss 

� Materialien sind 

� abfragbar, manipulierbar, eingebettet 

� Fokussiere beim Materialentwurf auf die fachliche 

Domäne 

� Aufgaben des Menschen definieren die Funktionalität der 

notwendigen Materialien 


Werkzeutentwurf 

� Wie modelliert man ein geeignetes Werkzeug? 

� Domänenfunktionalität 

� Aussehen, Bildschirmrepräsentation 

� Wiederholende Tätigkeiten in der Domäne prägen 

Werkzeuge 

� Ein Werkzeug vereinfacht die Tätigkeit, aber 

automatisiert sich nicht vollständig 

� Werkzeuge unterstützen kurze zusammenhängende 

Aufgaben, die jeweils algorithmisch implementiert 

werden können 


Material 

Werkzeugentwurf 

Beispiel 

Werkzeugname 

Behälter 


Werkzeuge 

Trade-offs 

� Ein Werkzeug sollte den Arbeitsprozess nicht 

unnötig vorgeben oder einschränken 

� Jede Teilfunktionalität eines Werkzeugs 

sollte jederzeit benutzbar sein 

� nicht-modal, ausser man informiert den 

Anwender geeignet über den Werkzeug- 

Zustand 

� Werkzeuge sollten nicht zu gross werden 

� Kohäsion! 


Werkzeug 

Design-Charakteristiken 

� Ein Werkzeug hat Identität, Namen und eine 

graphische Repräsentation 

� Werkzeuge zeigen eine Sicht (View) auf das aktuell 

bearbeitete Material und gibt unmittelbares Feedback 

über die Veränderung des Materials. 

� Das Material wird nie verdeckt! 

� Solange es benutzt wird, bleibt das Werkzeug im 

Blick. 

� Ausnahme: Materialarrangement auf dem Arbeitsplatz 

(nur Mauszeiger) 

� Das Werkzeug bietet die möglichen Handhabungen 

zur unterschiedlichen Bearbeitung des Materials an. 

� Werkzeuge haben ein "Gedächtnis" und können 

Einstellungen speichern. 

� Einstellungen und Stati werden dem Benutzer angezeigt. 


Arbeitsumgebung 

� Wie schafft man einen Ort an dem Menschen mit 

Werkzeugen Materialien bearbeiten können? 

� Gestaltung eines Softwaresystems mit räumlicher 

Dimension zum 

� organisieren der Gegenstände 

� zurgechtlegen, ordnen und ablegen 

� Modelliere den Arbeitsbereich explizit. 

� Erlaube Personalisierung 

� biete einen Ort wo Werkzeuge, Materialien und andere 

benötigte Dinge ihren Platz haben 

� Das Raumkonzept aus der Domäne wird als konzeptuelle 

Einheit im Design auch zur Abtrennung repräsentiert 


Aufgaben und Rollen der 


� Ort für persönliche Arbeit 

� mein Arbeitsbereich (Schreibtisch) 

� Ort für Werkzeuge und Materialien 

� Arrangement durch Benutzer konfigurierbar 

� Organisieren von Arbeit 

� Stapel (CH:Biege:-) von zu bearbeitenden Materialien 

� Ort für die Zusammenarbeit 

� Dinge für andere bereitlegen zur Kooperation 

� gemeinsam genutzte Orte (Mappen, Ablagen, Postfächer) 

� Darstellungsproblematik des Ortsbegriffs 

� Ortsbegriff muss abgebildet werden 

� UNIX hierarchische Namensräume (erster Ortsbegriff: Home 

directory) 

� Desktop Implementierungen (heute schwach gegenüber den 

Möglichkeiten einer Ortsrepräsentation) 

� bleibt schwierige Aufgabe 

� unterschiedliche Arbeitskontexte 

� multiple Desktops, konfigurierte Desktops 


Fachliche Behälter 

(Container) 

Material Design 

Container Form 

� Wie kann man Sammlungen von verwandten 

Objekten und ihre Verwaltung organisieren? 

� (Manager Pattern by Peter Sommerlad :-) 

� Representiere Sammlungen als Container 

� können auch als Materialien angesehen werden 

� welches Pattern? 

� speichern, sammeln, ordnen Materialien 

� Verwalten gespeicherte Materialien und geben 

Auskunft über diese (z.B. wie viele) 

� Container können zusammen mit ihren 

Materialien an andere Orte verschoben werden 

� Container unterstützen Kooperation und Koordination 


Formulare (Form) 

� Wie kann das Konzept eines (Papier-) Formulars in 

den Modellierungsanzatz eingebracht werden? 

� reicht es aus, Formulare als spezielles Material zu 

modellieren oder haben sie eigene besondere 

Charakteristiken? 

� Formulare sind konzeptuell eigenständig, weil sie 

spezielle Materialien darstellen 

� alle Formulare verhalten sich gleichartig 

� Formular-Editor 

� Formular-Viewer 

� Formular-Kopierer 

� Formular-Drucker 

Achtung: 

Hammer Syndrom! 

� können generisch realisiert und genutzt werden 

� effizienz, nicht für jedes Material einzeln programmiert 

� Abkürzung für "CRUD" Materialien, ohne weitere 

Funktionalität (Kombination ist möglich) 


Automat 

� Wie kann man Routineaktivitäten, die keinen 

menschlichen Eingriff benötigen und definierte 

Ergebnisse liefern, bereitstellen? 

� unter welchen Bedingungen kann eine solche Aktivität 

automatisiert werden bei WAM? 

� sich wiederholende Routinetätigkeiten werden als 

Automat implementiert. 

� Automaten operieren auf Materalien analog zu 

Werkzeugen. 

� Automaten werden vom Benutzer konfiguriert und 

gestartet, dann 

� laufen sie ohne Unterbruch bis sie ihr Resultat berechnet 

haben. 


Abgrenzung 

Werkzeug und Automat 

� Werkzeug ist für 

Benutzer Mittel zum 

Zweck 

� Einsatz abhängig vom 

Arbeitsfortschritt 

� Aktionen auf Material in 

beliebiger Reihenfolge 

aktivierbar 

� Einzeloperation atomar 

und unmittelbar für 

Benutzer 

� Benutzer hat Kontrolle 

über Arbeitsfortgang 

� Benutzer gibt Kontrolle 

über Arbeitsfortschritt an 

den Automaten ab 

� Fixe Vorgegebene 

Arbeitsschrittfolge durch 

den Automaten 

implementiert 

� Kein Eingriff in den 

Ablauf durch den 

Benutzer 

� "fire and forget" 

� Eher "kleine" Automaten 

� kapseln technische 

Schnittstellen 


Automat Diskussion 

� Es gibt einen Grenzbereich zwischen 

Werkzeug und Automat, sowie zwischen 

Automat und dem neueren Konzept des 

Domain Service Provider. 

� "Grosse" Automaten tendieren dazu, zu 

komplex zu konfigurieren zu sein und damit 

Aufgaben zu übernehmen, die man besser 

mit einem Werkzeug realisiert. 

� Konfiguration des Automaten selbst als 

Werkzeug 

� grosse Automaten wiedersprechen der 

Philosophie des selbstbestimmten Arbeitsplatz 

� Bedienung der Automaten? 

� Start ja, aber auch Reset, Restart? 


Domain Service Provider 

neueres Konzept 

� Wie kann man wiederverwendbare 

Geschäftslogik gestalten, die unabhängig 

von Interaktion und Repräsentation ist? 

� Nutzen unabhängig von Arbeitsplatztypen, 

Vertriebs/Nutzungs-Kanälen oder Technologien 

� Integriere unterschiedliche 

Nutzungsszenarien in einem Domain Service 

Provider als gemeinsame Infrastruktur 

� Dienst für verschiedene Anwendertypen 

� Fasst gemeinsam benötigte Dienste zusammen 

z.B. Kunde und Bankberater nutzen Konten des Kunden 

(Internet, Bankomat, Schalter), Zugang sollte nur einmal 

implementiert werdenmüssen 


Domain Service Provider 

Diskussion 

� Einfache zentrale Sammlungen von Arbeitsobjekten 

qualifizieren sich nicht als Domain Service Provider 

� kein Domänenwissen gekapselt 

� Management von Materialsammlungen mit 

Domänenbezug sind andererseits geeignete 

Kandidaten für Domain Service Provider 

� z.B. Kontoverwaltung, Car Pool Management 

� Geschäftstransaktionen, die von verschiedenen 

Akteuren ausgelöst werden, sind gute Kandidaten für 

D-S-P. 

� Organisationsübergreifende Workflows 

� Funktionssammlungen sind keine D-S-Ps 

� z.B. Steuerkalkulator 


und der Rest? 

� Technischer Automat 

� klassischer Zustandsautomat für 

Geräte(steuerungen) 

� Sonde (engl. Probe) 

� Zustandsabfrage für technischen Automat 

� Gerätezustand wird zum Arbeitsplatz 

transportiert 

� Einstellwerkzeug 

� Spezialwerkzeug für technische Automaten zur 

Wartung und Steuerung. 


WAM Entwurfsmuster 

� Wie implementiert man nun das ganze 

sinnvoll? 

� bisher nur Konzeptuelle WAM Patterns für die 

Modellierung kennengelernt 

� GOF Patterns und andere vorausgesetzt 

� Spezialitäten von WAM berücksichtigt 

� Framework für die Gestaltung eines 

Arbeitsbereichs als Ergebnis 



Originalversion deutsch 



modernere Version english 

Design-Patterns 

Konzept-Patterns 


Werkzeug- und Material- 

Kopplung (Aspect) 

� Wie kann man sicherstellen, dass Werkzeuge und 

Materialien zusammen passen 

� nicht nur 1:1, sondern n:m 

� Rerpäsentiere jede unterschiedliche Nutzung eines 

Materials durch einen separaten Aspekt des Materials 

� Aspekte sind Schnittstelle(n) des Materials 

� Material muss Aspekt erfüllen um mit einem bestimmten 

Werkzeug bearbeitet zu werden 

� Aspekte erlauben es unterschiedliche Schnittstellen und 

Protokolle zu kombinieren 

� Klassischer Fall des ??? Prinzips 

� welches SE-Prinzip ist es? 


Werkzeug- und Material- 

Kopplung (Aspect) 

� Werkzeuge werden gegen Aspekt 

programmiert 

� Mehrere Materialien können den gleichen 

Aspekt realisieren 

� Mehrere Werkzeuge können gegen den 

gleichen Aspekt realisiert werden 

�Polymorphie der Werkzeuge und Materialien 

abhängig voneinander! 

� Welche OO-Design bzw. 

Implementierungsalternativen gibt es? 

� Für den Anfang auf Abtrennung der Aspekte verzichten 

� beim Prototypenbau oder Spikes 

� erst später Refactoring! 


Tool uses interface Aspect 

Material implements Aspect 

Aspekte über Vererbung 

oder Interfaces 

Tool uses Aspect 

Material inherits Aspect 


Tool 

Aspekte über Adapter oder 

Decorator 

Aspect 

AspectImpl 

� Delegation statt Vererbung 

Material 

� geringere Kopplung, Nutzen in Java bedingt 

� Materialklassen einfacher, aber ggf. viele AspectImpl 

Klassen 

� Decorator bietet noch mehr Möglichkeiten 

� kann Problem der AspectImpl Klassen abschwächen, 

braucht aber wieder Vererbung 

� Instanziierung über Factories oder Builder ggf. 

aufwendig 

� Identitätsverlust der Materialien und Komplexität 


Trennung von Funktion und 

Interaktion 

� Wie kann man das Prinzip der "separation of 

concerns" beim Werkzeugdesign umsetzen? 

� Werkzeuge haben eine Handhabungs- und 

Visualisierungsschnittstelle (Interaktion) 

� Werkzeuge haben innere Funktionalität zur 

Materialbearbeitung (Funktion) 

� Zur Werkzeugimplementierung trenne es 

grundsätzlich konzeptionell in 

� Funktionsteil (FP – function part) 

� Interaktionsteil (IP – interaction part) 


Trennung von Funktion und 

Interaktion - Diskussion 

� Designalternativen 

� eine Komponente, zwei Schnittstellen 

� einfacher für Prototypen, frühe Entwicklung 

� analog Model-View-Controller Pattern 

� für "ausgereiftere" komplexe Werkzeuge 

� "dünne" Interaktionskomponente 

� neue Anforderungen durch Benutzung 

ungeachtet der eigentlichen Funktion sind 

typisch 

� Portierung auf unterschiedliche Oberflächen 

� separate Funktionskomponente 

� bessere Testbarkeit für Funktionskomponente 


Werkzeugkomposition 

� Wie baut man komplexe Werkzeuge, die aus 

einfacheren Werkzeugen zusammengesetzt 

sind? 

� Aufteilung dient der Komplexitätsbeherrschung 

� Wiederverwendung von Werkzeugbausteinen 

ist natürlicher Bedarf von OO Entwicklern 

� Zerlege komplexe Werkzeuge in Teile. Das 

Kombinationswerkzeug bietet einen 

gemeinsamen Kontext für die eingebetteten 

Werkzeuge 

� aka: Composite auf Werkzeuge anwenden. 

� Fördert Wiederverwendung 


� Sub-Werkzeug 

Werkzeugtypen bei 

Werkzeugkomposition 

Tool 

Sub Tool 

Simple Tool Combination Tool 

� kann in andere eingesetzt werden 

� Kontext-Werkzeug 

Context Tool 

Tool 

Composition 

� bettet Sub-Werkzeug(e) mit gemeinsamen Kontext ein 

� Kombi-Werkzeug – Domänenelement in Benutzung 

� Einfach-Werkzeug 


:Sub 

Functionality 

Feedback between 

Tool Parts 

� Wie kann man sicherstellen, dass ein Sub- 

Werkzeuge unabhängig vom Kontext- 

Werkzeug bleiben und trotzdem das Kontext- 

Werkzeug über Zustandsänderungen der 

Sub-Werkzeuge Rückkopplung erhält? 

:Context 

Functionality 

:Sub 

Functionality 


1. User Actions 7. Program Reactions 

2. System 

Events 

Tool 

3. Operations 

4. Operations 

:InteractionPart 

:FunctionalPart 

:Material 

6. Update of Presentation 

5. Events 

Rückkopplung zwischen 

Funktion und Interaktion 

� Wie können wir die Trennung im 

Werkzeug zwischen Funktion und 

Interaktion implementieren, so dass 

bei der Änderung der Interaktion der 

Funktionsteil möglichst nicht 

angepasst werden muss? 

� Umsetzung von Trennung Interaktion 

Funktion 

� Teile Werkzeug in 

Interaktionskomponente (IAK, IP) und 

Funktionskomponente (FK, FP) 

� IAK kennt und nutzt FK, aber FK kennt 

IAK so wenig wie möglich. 

� Zur Umsetzung braucht es einen 

Feedback Mechanismus. 


Feedback FK-IAK 

Implementierung IAK 

� IAK verarbeitet (System/Windows) Events 

� Präsentationsereignisse selbst interpretiert 

(z.B. Scrolling) 

� Applikationsspezifische Ereignisse an FK 

� IAK verwendet Interaktionstypen 

(interaction forms) 

� abbildung auf window toolkit elemente 


Feedback FK-IAK 

Implementierung FK 

� Funktionskomponente(FK, functional part-FP) 

� implementiert Domänenfunktionalität 

� bietet Abfragefunktion für IAK über eigenen 

internen Zustand und den des bearbeiteten 

Materials. 

� verwaltet Arbeitszustand und Werkzeug- 

"Gedächtnis" abhängig von Benutzeraktionen 

und Materialzustand 

� greift auf ein bestimmtes Material (über den 

Aspekt) zu 

� Verändert Material 

� Verwaltet Arbeitskontext zwischen Materialien 

und dem Werkzeug (Konsistenzerhaltung) 


Trennung von Handhabung 

und Präsentation 

� Wie kann die Interaktionskomponente (IAK) 

möglichst unabhänig vom User Interface 

Toolkit gestalten? 

� Kapsle die Arten unterschiedlicher Manipulation 

als Interaktionstypen (IAT - interaction forms) 

� Erstelle die IAK anhand der Interaktionstypen 

� IAK tauscht mit IAT nur Domänendaten aus 


Trennung von Handhabung 

und Präsentation (2) 

� Presentation Forms (PF) implementieren die 

spezifische Repräsentation und Interaktion der 

Interaktionstypen/interaktion forms für den Benutzer 

� PFs kapseln die Widgets eines GUI Tookits 

� PFs werden ausserhalb eines Werkzeugs verwaltet, sind 

aber mit den Interaktionsformen des Werkzeugs 

gekoppelt 

� Je nach Toolkit, können die Widgets direkt die PFs 

darstellen, extra Programmieraufwand für PFs ist nicht 

nötig. 

DeviceEditor 

 

FillIn 

JTextFieldPF 

JTextField 


Rückkopplung zwischen 

Interaktionstypen (IAT) und 

Interaktionskomponente (IAK) 

� Wie können wir Interaktionstypen mit der 

Interaktionskomponente koppeln? 

� Interaktionstypen sollen generisch sein und nicht von der 

Interaktionskomponente abhängen. 

� Gleichartige Interaktionstypen können unterschiedliche 

fachlichen Aktionen auslösen 

� unterschiedliche Interaktionstypen können die gleiche 

fachliche Aktion auslösen 

� Nutze das 

.............. Pattern 


Fachwerte 

Values again :-) 

� Wie kann man die eingebauten einfachen 

Datentypen der OO-Programmiersprache um 

Benutzerdefinierte Fachwerte ergänzen? 

� Wertesemantik statt OO-Referenzsemantik 

� siehe letzte Vorlesung. 

� Implementiere Klassen für Fachwerte als 

Value Object. 


Fachwerte 

Implementierungsoptionen 

� Fachwertklassen (�) 

� Immutable Domain Value Objects (�) 

� mit Anwendung des Flyweight Design Patterns um 

Speicher zu sparen 

� Handle-Body Idiom um Speicher bei "grossen" 

Fachwertobjekten zu sparen (C++) 

� Referenzzähler erlaubt freigabe von nicht mehr 

referenzierten Fachwertobjekten (bei Flyweight nicht 

ohne weiteres möglich) 

� Fachwerttyp als Stream 

� für sehr grosse Werte, die von externen Quellen(DB) 

abhängen 

� Fachwerttyp per Konfiguration 

� eine "Basisklasse", mehrere Konfigurationen 


Fachliche (und Technische) 

Behälter 

� Technische Behälter sind heute in 

Programmiersprachen/Umgebungen gut genug 

eingebaut 

� e.g. C++ STL, Java Collections 

� Wie modellieren wir fachlich motivierte Behälter als 

besonderes Material, das andere Materialien 

enthalten kann und ein Ordnungsprinzip für diese 

definiert? 

� Implementiere einen Fachbehälter als eigenständiges 

Domänenobjekt 

� stellt eine Art Material dar 

� hat spezielle Operationen (add, enumerate) 

� hat zusätzliche fachliche Constraints oder Operationen 

im Gegensatz zu technischen Behältern 


Fachbehälter 

Implementierungsoptionen (1) 

� vorhandene Collection Klasse verwenden 

� z.B. in C++ Container concept implementieren und auf 

vorhandenen passenden container delegieren 

� oder direkt Collection Klasse nutzen 

� typedef oder Vererbung (in Java) 

� gespeicherte Materialien laden (3 Ansätze) 

� enthaltene Materialien nur per Identifikator 

(Inhaltsverzeichnis) 

� Werkzeug bezieht Materialschlüssel und sorgt sich selbst 

um das "laden" des Materials, hinzufügen und löschen 

direkt auf dem Behälter möglich 

� Bei Benutzung wird Material vom Behälter automatisch 

"nachgeladen" 

� Container verwaltet Material-Proxies, die erst beim 

Zugriff das Material laden (Lazy Aquisition pattern) 


Fachbehälter 

Implementierungsoptionen (2) 

� Inhaltsverzeichnisse für Fachbehälter 

� z.B. Produktangebot 

� Inhaltsverzeichnisse als eigenständiges 

Material 

� Vorteil: einheitliches Konzept für Anwender 

� Inhaltsverzeichnis als Fachwert 

� einfacher, aber kein automatischer Update 

� z.B. Ordnerliste in Explorer (F5!) 

� Materialbearbeitung nur ausserhalb eines 

Behälters (oder direkt innerhalb) 

� Transportmetapher: bewege Material in 

Arbeitsbereich, bevor es bearbeitet werden 

kann 


Form System 

(Formularsystem) 

� Wie können (viele) Formulare günstig in 

einer Applikation bereitgestellt werden? 

� Formular: Dialog oder auch Papierform 

� Baue (oder benutze) ein generisches 

Formularsystem, das mit einem 

Formulareditor leicht neue Formulare 

erstellen lässt. 

� Bausteine: Formular, Formularschablone, 

Formularelement, Elementlisten, Felder 

� Felder (und Listen) auf Fachwerte beziehen 


Formularsystem 

� Beispiel für ein Formularsystem 

� und einen Editor 

Welche 

Patterns? 


Formularsystem 

Diskussion 

� kann grosse Vereinfachungen bringen 

� weniger Programmieraufwand 

� leichte Erweiterbarkeit und Anpassbarkeit 

� kann Materialkonzept untergraben 

� alles wird mit Formularen gelöst 

� Typsicherheit wird untergraben (alles String) 

� Evolution kann bedeuten vom Formular weg 

hin zum Werkzeug zu entwickeln 

� Material und Werkzeug zuerst sehr einfach -> 

Formular 

� später mehr Funktionalität -> Werkzeug 


Automatons in Embedded 

Systems 

� Wie kann man ein Embedded System mit 

einem technischen Automat an ein WAM 

Anwendungssystem koppeln? 

� embedded Systeme haben oft 

Echtzeitanforderungen 

� sollten nicht zu sehr "gestört" werden 

� Kommunikation notwendig, da eigener 

Prozessraum 

� Kopple Echtzeitsysteme asynchron an und 

verwende Sonden um mit ihm zu 

kommunizieren 


Automaten in Embedded 

Systemen 

Probe 

Interaction 

Functionality 

Automaton Automaton 


1. Registering 

2. Adjusting 

3. Announce 

Process 

ToolFP Automaton 

Proxy 

register() 

changeSettings() 

tell() 

probing 

Probe 

sendEvent() 

receipt 

sendEvent() 

receipt 

Automaton 

Proxy 

receiveEvent() 

Local 

Broker 

Event 

Event 

Event 

Entry 

constructor() 

Observer 

Proxy 

changeSettings() 

probing 

Automaton 

tell() 

probe 

produced 

data

Tool Process Automaton Process 

Tool FP 

ChangeValue() 

0 

Automaton Proxy 

SendPackage() 

1 

Broker Proxy 

SendEvent() 

2 

4 

3 

Broker Process 

Event Queue 

Event Event 

ReceiveEvent() 

ChangeValue() 

ReceivePackage() 

5 

Call 

Automaton 

7 8 

6 

Entry 

Broker Proxy 

Return from Call 

9 

10

Domain Services 

SOA 

Service-oriented 

Architecture 

� Wie implementiert man Fachfunktionalität, 

die über unterschiedliche Oberflächen 

genutzt werden kann? 

� unterschiedliche Arbeitsplätze 

� unterschiedliche Technologie (desktop, web, ... 

� Kombiniere Funktionalität und Wissen über 

einen Dienst ohne auf die Art des User 

Interface einzugehen in einen Domain 

Service 

� Dieser Dienst wird bereitgestellt 

� davon verwaltetes Material wird im Service 

gekapselt 


Desktop 

RMI 

Domain Service 

Beispiel Helpdesk 

HTML- 

Client 

Servlets 

HTTP 

Domain Service Helpdesk 

Queries in 

registry 

WML- 

Client 

Servlets 

WAP 

HTTP 

Email- 

Client 

Email- 

Gateway 

SMTP 

POP3 



� Schnittstelle ist wertorientiert (Values again!) 

� Schnittstelle beantwortet fachliche Anfragen 

� Clients delegieren normierte Subtasks an den 

Service 

� Kapselt Material und Implementierung der 

fachlichen Interaktionen damit 

� Macht keine Annahmen über das 

Interaktionsmodell und die Darstellung für 

den Benutzer 

� unterstützt multi-user und Verteilung 

� sollte Zustands- und Session Konzept haben 

� + sollte Autorisierungskonzept haben!!! 


Frontend / Client 

Workplace Type 

Interaction 

Service 

Domain 

Service 

Service Architektur: 

logische Schichten 

Server 

Server 

Backend / 

ERP-System 

Frontend 

represents and 

interacts 

Interaction Service 

selects and 

translates 


encapsulates 

domain knowledge 

Backends 

encapsulate 

the data 



Environment 

� Wie kann die Arbeitsumgebung 

implementiert werden, so dass sie alle 

Arbeitsplätze abstrahiert? 

� Wie kann die Arbeitsumgebung die Kopplung 

der geeigneten Werkzeuge und Materialien 

unterstützen? 

� Nutze eine Klasse für den Aufbau der 

Arbeitsumgebung. 

� beinhaltet workspace (Arbeitsplatz) in dem 

man alle notwendigen Objekt arrangieren kann 

� workspace beinhaltet fix verfügbare Behälter 

mit Basisobjekten 

� Schablonen, Werkzeugkasten, Papierkorb 



Environment 


Zusammenfassung und 

Ausblick 

� WAM bietet viele Konzepte für die 

Modellierung und Implementierung 

interaktiver Systeme 

� auch wenn JWAM nur ein paar wenige 

Infrastrukturkonzepte bietet lebt der 

grundsätzliche Ansatz 

� Projekte von Prof. Züllighoven und Mitarbeitern 

� Eclipse (Kernleute sind bei OTI im Eclipse- 

Team) 

� Meiner Meinung nach ist WAM ein Mittel um 

Eclipse und dessen RCP konzeptuell besser 

zu verstehen und in eigenen Projekten 

einzusetzen 


Q-Feedback 

� Hallo, es steht vom 3.6. bis 10.6. ein 

Formular für Sie zur Bewertung der 

Vorlesung zur Verfügung. 

� https://qfeedback.hsr.ch/ 

� Bitte ehrlich ausfüllen! 

� Auswertung wird für Sie zugänglich sein. 


Literatur/Quellen 

� Züllighoven et al: Das objektorientierte 

Konstruktionshandbuch, dpunkt 1999 

� Züllighoven et al: Object-oriented 

Construction Handbook 

� www.jwam.org 

� Vielen Dank an Prof. Züllighoven für die 

Bereitstellung der Diagramme aus dem 

Object-oriented Construction Handbook

Advanced Patterns and Frameworks

Verwandeln Sie Ihre PDFs in ePaper und steigern Sie Ihre Umsätze!

Template löschen?

Als Template speichern ?