Die modellgetriebene Softwareentwicklung ist ein etablierter Weg im Streben nach effizienteren Entwicklungsprozessen. Im Bereich der Geschäftslogik sind hier beachtliche Erfolge erzielt worden, welche auch zunehmend in unseren Projekt-Alltag einfließen. Die Anwendungsoberflächen entziehen sich diesem Pfad jedoch bislang hartnäckig. Modellierung bedeutet Reduktion auf das Wesentliche. Gerade im Bereich der GUIs sind die verschiedenen Facetten jedoch sehr umfassend. Welche Aspekte allgemeingültig und welche individuell behandelt werden wollen, unterscheiden sich je nach Fachlichkeit und technologischem Umfeld teils dramatisch. Für effizientere Wege in der GUI-Entwicklung erfordert diese Quadratur des Kreises jedoch Lösungen. Wie lassen sich Effizienz steigernde Abstraktionen schaffen, ohne sich auf einzelne Technologien, Layouts und Visualisierungen festzulegen? Wie passen individuelle Lösungen mit wieder verwendbaren Teilen zusammen? Welche Modelle sind überhaupt sinnvoll? Wir zeigen am Beispiel eines modell-orientierten Frameworks zur Erstellung datenzentrischer Benutzeroberflächen konkrete Architekturen und Konzepte, um die Bedürfnisse unterschiedlichster Projekte mit einem modellorientierten Vorgehen zu verbinden und zeigen an einer lebendigen Demo die dabei entstehenden Perspektiven auf.

1. Vielfalt vs. Abstraktion
Der Jakobsweg der modellbasierten GUI-Entwicklung
Benjamin Schmid

2. Ansätze zur GUI Entwicklung
Code
• Programmatisch
• GUI Designer
• Deklarative Sprachen
- XUL, XAML, XForms, JAXfront / KParts / ...
• Annotated Business Model
- Naked Objects, Trails, JMatter, ...
• Modellierungssprachen
Modell
- UML, UMLi, DiaMODL, ...
- MDA
#2

3. GUI-Entwicklung: Programmatisch
• Vorgehen & Struktur:
Technologiegebunden
• geringe Abstraktion
• keine Verwendung
von Modellwissen
class HelloWorldSwing {
public static void main(String[] args) {
Runnable guiCreator = new Runnable() {
public void run() {
JFrame f = new JFrame
("Hallo Welt mit Swing");
f.setDefaultCloseOperation(JFra...
// Fügt den "Hallo Welt"-Text hinzu
JLabel label = new JLabel("Hallo Welt");
f.getContentPane().add(label);
• Hohe Flexibilität &
Detailsteuerung
// Zeigt das Fenster an
f.setSize(300, 200);
f.setVisible(true);
}
• idR gute Basis für
aufbauende Konzepte
};
SwingUtilities.invokeLater(guiCreator);
}
}
#3

4. GUI-Entwicklung: GUI-Designer
oft: Visueller Editor für Swing mit Code Generator
• Werkzeug, niedrige Einstiegshürde, WYSIWYG
• behindert weitere Abstraktionen & komplexere UIs
#4

5. GUI Entwicklung: Deklarative Sprachen
Vertreter: XUL, XAML, XForms, JAXfront, KParts, ZUL, ...
• Sehr technisch / konkret / gegenständlich
• Betrachtet in der Regel nicht:
- Modellwissen
- GUI-Verhalten & -Logik
- dynamische GUI-Strukturen
Beispiel: XUL (Mozilla)
#5

6. GUI-Entw.: UI aus Business Model
• Basisannahme: BO-Modell : UI Funktion ~ 1:1
- gute Basis für einfachste CRUD-Anwendungen
- Praxisbedürfnisse gehen schnell darüber hinaus
(Dialogführung/-struktur/-verhalten/gestaltung, etc.)
• Abstraktion und Verwendung modellierten Wissens
• Reinform-Beispiel: „Naked Objects“-Architektur
#6

7. GUI Entwicklung: Weitere UI Modelle
Dialogsteuerungs-Modelle
z.B. Dialog Flow Notation (DFN)
• Webseiten-/Dialogorientiert
• Dialogsteuerung auf Makroebene
• Richtung: Prozessflußsteuerung
#7

8. GUI Entwicklung: MDA/MDD
• GUIs konzeptionell integraler Bestandteil von MDA
• ... in UML direkt gar nicht betrachtet. Dafür zahlreiche
erfolglose Modell-Versuche (UMLi, DiaMODL, ...)
• Es fehlen: Werkzeuge, praxistaugliche Lösungen, ...
#8

9. MDA/MDD
MDA: PIM -> PSM -> Fertige Anwendung - mit GUI?
#9

10. Dilemma: Abstraktion ...
• Inhalte
- Modellierte Attribute
(Labels, Eingabefelder)
- Modellierte Aktionen
(Buttons)
• Funktionen
- Business Funktionen
(„Löschen“)
- Navigation
#10

11. Dilemma: ... vs. Details
Tooltip / Pflichtfeld
•
•
Inhalt
Funktion
5px
5px
350px
•
Anordnung
Größen
Ausrichtung
Widgettypen
Farben
Interaktionsmuster
Tooltips & Hints
visuelle
Gruppierungen
...
5px
•
•
•
•
•
•
•
•
2px
500px
Fehlerhintergrund:
RGB(255,200,200)
5-Zeichen, numerisch
rechtsbündig
Länderliste aus
Datenbankabfrage
Fehlermeldungsbereich
#11

12. GUI-Modellierung: Ja oder nein?
Modellorientierte UI-Entwicklung birgt viel
Potential:
• Wiederverwendung bestehenden Modellwissens
- Domain Model
- Validierungen
- Zusatz-Infos / DSLs
(Entitäten, Attribute)
(Kardinalitäten, OCL)
(Namen, Rechteregeln, ...)
• Für eng abgegrenzte Domänen (Rapid
Prototyping, Dialogfluss,...) erscheinen auch
zusätzliche, reine UI Modelle attraktiv
#12

13. GUI-Modellierung: Ja oder nein?
Unmöglich alle GUI-Aspekte sinnvoll zu modellieren
• Erst starke Reduktion
ermöglicht sinnvolle Modellierung
• Reine Modell-GUIs nur unter
sehr engen Annahmen („Naked-Objects“)
• Vollwertige UIs erfordern
immer zusätzliche Detailsteuerung
- Implementierungszugriff/Code notwendig!
- Feinsteuerung auf allen Ebenen:
vom Querschnitt bis ins Detail
#13

14. Anforderungen datenzentrischer UIs (1)
GUI-Visualisierung
Visualisierung
mit div. Basistechnologien
Dynamische Layouts
für „Formulare“
Regelabhängige Präsentation
aufgrund Rechte, Zustände, ...
Benutzerführung und Feedback
#14

15. Anforderungen datenzentrischer UIs (2)
GUI-Inhalte
Datenbeschaffung
modellierte und modellfremder Inhalte
Eingabe-Validierungen
Attribut/Objekt-Prüfungen z.B. via OCL (Modell)
I18N
UI Ablaufsteuerung & Datenfluss
#15

16. Rückblick: GUIs in der MDA
?
?
?
?
PSM
?
PIM
PIM
?
#16

17. Rückblick: 100% GUI Modellierung
Inhalt
Funktion
Darstellung
Anwendungsrahmen
#17

18. GUIs durch Modell + Code, aber wie?
Anpassungen,
Erweiterungen &
Implementierung (Code)
Anwendungs-Details
Funktion
Darstellung
Anwendungsrahmen
Querschnitts-Verhalten
Querschnitts-Verhalten
Inhalt
Wir wollen: Baukasten, aus-/anpassbare
Einzelteile, Detailzugriff
#18

19. Was ist orchideo?
orchideo/suite
Modellierungs- und Entwicklungsumgebung für
unsere Projekte auf Eclipse-Basis
orchideo/views
Modell-orientiertes Abstraktionsframework zur
effizienten Erstellung datenzentrischer GUIs auf
unterschiedlichen GUI-Plattformen
#19

20. Der Weg…
1.
2.
3.
4.
Abstraktion
Modellnutzung
Deklaratives Vorgehen
Bausteine & -elemente
#20

21. Der Weg…
1.
2.
3.
4.
Abstraktion
Deklaratives Vorgehen
Delegation an Modellwissen
Bausteine & -elemente
•
Zergliederung in gröbere Strukturen
(Vereinfachung, DRY)
•
Entkopplung (Technologie/Domänen)
#21

22. Abstraktion: Representation
Representation : Darstellungsknoten mit „Features“
Fenster
Formular
Geschlecht
Name
Button Bereich
Importieren
OK
#22

23. Abstraktion: Features
Feature : Austauschbare Querschnittsfunktionen
aller Representations
• im Querschnitt
(Swing -> Echo3)
• als auch im Einzelnen
(Button -> Grafik-Button)
• Themen
-
Visualisierung
Data Binding
Validierung
Rechte & Editierbarkeiten
UI Ereignisse, ...
#23

24. Überblick: Abstraktionsebenen
Representation &
Feature
Process & View
Process
View
Flow
#24

25. Der Weg…
1.
2.
3.
4.
Abstraktion
Deklaratives Vorgehen
Delegation an Modellwissen
Bausteine & -elemente
• Beschreibung der GUI via Regeln
statt konkreter Einzelbefehle
• Tor zur Modellinterpretation
#25

26. Deklarative Formulierung von
• Datenanbindung
Lazy Loading, Transformation, etc.
• GUI-Layout
Dynamische Formulare
• Darstellungs-Modi
Regelbasierte Rechteabildung
• Dialogablauf
DatenbankTrefferliste
(Personen)
selektierter
Treffer
Adresse der
Person
davon:
Hausnr.
(Zahl)
Lesen &
Schreiben
als Text
Source<String> hnr = Provider.of(result).at(selectHandle).get(Person.ADRESS)
.get(Adress.HNR).as(String.class);
hnr.get();
hnr.set(„7“);
// Lesen
// Schreiben
Beispiel: Deklarative Datenanbindung
#26

27. Warum nun deklarative Struktur?
Beschreibung einer abstrakten Regel anstatt
konkreter Einzelbefehle
• Einfacher
• Robuster & Effizienter
• ermöglicht Beschreibung
- im Code
- in einem Modell!
#27

28. Strukturierung: Lebenszyklus & Phasen
Interaktions-Phasen
• Abbild des Dialogmodus von
Benutzeraktion und Systemreaktion
• Trigger für die Interpretation der deklarierten Regeln
#28

29. Der Weg…
1.
2.
3.
4.
Abstraktion
Deklaratives Vorgehen
Delegation an Modellwissen
Bausteine & -elemente
•
Modell-Abbildung
geeigneter Aspekte
•
GUI Deklaration:
Modellreferenz statt Code
#29

30. GUIs & Modelle?
Modellierung
• Der BO-Modelle
• zusätzlicher GUI Inhalte & Modelle,
wo sinnvoll DSLs
Realisierung der GUIs
• Basierend auf den Modell-Inhalten...
... aber auch abweichend davon
• Generativ & Interpretativ
#30

31. Modell-Artefakte & Nutzung
Laufzeit
Ladbares
LaufzeitModell
Modell
Entwicklung
Generierung/
Transformation
Entwicklung & Laufzeit
Modell-Editor
Business
Model Code
GUI-Gerüst/
Prototyp
Code Modell-Referenzen
#31

32. Modellwissen
Gut an das Modell delegierbar:
• Datenanbindung
• Präsentationdetails (Namen, Typen, ...)
• Eingabevalidierungen
• Fachlichkeiten
z.B. Rollenabhängige Schreibrechte
#32

33. Der Weg…
1.
2.
3.
4.
Abstraktion
Deklarative Struktur
Delegation an Modellwissen
Bausteine & -elemente
•
•
Flexibilität:
Vom Grundpfeiler bis ins Detail
Effizienz und Wiederverwendung
#33

34. Technologie- & Lösungs-„Kits“
Framework-Kern definiert
Abstraktionen & Strukturen
kits liefern
Implementierungs-Einzelteile
• Technologie/Modell-Adapter
• Lösungsbausteine
#34

35. Die Summe der Teile
effizient?
#35

36. Setups
• sind Templates
• Definieren Annahmen
- für die Interpretation des Modells
- in der Gestaltung der Projekt-API
• Liefern den sinnvollen ‚Standard‘fall
Setup
#36

37. ...und was ist nun mit den Details?
• Rahmencode in der Hand
• Tauschbare & konfigurierbare
Einzelteile
• API-‚Durchgriff‘ auf Technologie
myButton.getVisualizer().getUI().setWidth(..)
Core
Feature
Echo3 Kit Echo3
#37

38. Anwendung mit orchideo/views
#38

39. Live Demo
#39

40. Vielen Dank
für Ihre
Aufmerksamkeit!
Referenzen:
Naked Objects: http://www.nakedobjects.org/
Dialog Flow Notion: http://bit.ly/9XPg1c
XUL Tutorial: https://developer.mozilla.org/en/XUL
orchideo: http://www.exxcellent.de/
#40