POC-UI: Process-oriented Construction of User Interfaces

“Klug fragen können ist die halbe Weisheit.”

Francis Bacon

Allgemeines

• Was ist POC-UI?
  POC-UI steht für “Process oriented Construction of User Interfaces” und beschreibt eine leichtgewichtige Methode um grafische Oberflächen software-technisch zu strukturieren.
• Wann sollte man POC-UI einsetzen?
  POC-UI hilft bei der Entwicklung grafischer Benutzeroberflächen. Es ist für Teams interessant, die ihre Effizienz durch durch Vereinheitlichung der Quellcodestruktur steigern wollen.
• Was bringt der Einsatz von POC-UI?
  Der Einsatz von POC-UI führt zu einheitlich entworfenen Klassenmodellen im Projekt. Dadurch können die Entwicklungs- und Wartungskosten in Software-Projekten erheblich gesenkt werden.
• Wie ist POC-UI entstanden?
  POC-UI wurde während mehrerer großer Software-Projekte bei einem großen Energieversorger in Deutschland entwickelt.
• Warum wird nicht das MVC (Mode-View-Controller) Pattern verwendet?
  Wir haben viele Zeilen MVC-konformen Codes gesehen, der sich trotzdem strukturell voneinander unterschied. Deshalb haben wir das MVC-Pattern verfeinert:
  • POC-UI beschreibt anhand welcher Kriterien eine komplexe View in kleinere Teilviews zerlegt werden kann.
  • POC-UI definiert einen Zustandsgraph für grafische Komponenten. Dieser hilft bei der Eingrenzung von Fehlern und bei der Suche nach geeigneten Stellen für Erweiterungen der Software.
  • POC-UI definiert einen Entwicklungsprozess und die beteiligten Rollen. Durch die explizite Definition eines Benutzungsmodells werden Kundenwünsche präzise erfasst und Missverständnisse frühzeitig erkannt.
• POC-UI führt dazu, dass sehr viele Widgets geändert werden, wenn die “setSelection” Methode oft hintereinander aufgerufen wird, auch wenn sich das Model evt. nur an einer Stelle geändert hat. Führt dies nicht zu erheblichen Performanceproblemen?
  Bevor ein Wert auf ein Widget gesetzt wird, prüfen POC-UI-Implementierungen, ob sich der neue von dem alten Wert unterscheidet. Dadurch werden Aktualisierungen nur bei Bedarf festgestellt.
• Was wird im POC-UI Umfeld unter Composite verstanden?
  Ein Composite ist eine grafische Komponente, die Widgets, andere Composites oder beides enthält. Jedes Composite dient einer bestimmten fachlichen Aufgabe und kann somit einem Prozesschritt des Benutzungsmodells zugeordet werden.
• Was sind Container?
  Container sind Rahmen für Composites. Jeder Container beinhaltet genau eine Referenz auf ein Composites. Container delegieren Methodenaufrufe in der Regel an ihr Composite weiter. Beispiele für Container sind Dialoge, Wizardpages oder ViewParts in der Eclipse Rich Client Platform.
• Welche Rolle spielt die Applikation?
  Die Applikation kann als Container für andere Container verstanden werden. Die Applikation hat die Aufgabe Infrastruktur für das Instanziieren der Composites und das Verwalten der Container bereit zu stellen.

Actions

• Was sind Actions?
  Actions sind in sich gekapselte Codefragmente, die als Parameter in Composites gereicht werden (über sog. ActionConfigurations). Da Actions von außen in die Composites gereicht werden, sind die Composites gut testbar (Mock-Objekte).
• Dürfen ActionConfigurations Instanzen anderer Klassen als “Actions” enthalten, z.B. andere ActionConfigurations?
  Nein! Die Initialisierung so entwickelter ActionConfigurations ist sehr umständlich zu programmieren, weil die gesamte BENUTZT-Hierachie der Composites in der ActionConfiguration gespiegelt wird.
  
• Wer erzeugt und initialisiert die ActionConfigurations?
  ActionConfigurations werden vor dem Erzeugen der Composites instanziiert und in den Constuktor übergeben. Im Falle eines Sub-Composites geschieht dies in der Methode initGUI() des Super-Composites. Das Composite auf oberster Ebene erhält seine ActionConfiguration von der Applikation.
• Wie unterscheiden sich Actions von statischen Helper-Methoden?
  Statische Helper werden hart referenziert und unterstützen keine Polymorphie. Deshalb sind sie für Testzwecke nicht ausführbar.
  

Selections

• Was sind Selections?
  Selections repräsentiere den fachlichen Zustand eines Composites. Jedes Composite referenziert genau eine zugehörige Selection.
• Was unterscheidet Selections von Modellen aus dem MVC-Umfeld?
  Selections enthalten nur fachliche Zustände, sowie die zugehörigen Setter und Getter.
• Warum beinhalten Selections nicht direkt die Selections möglicher Sub-Composites?
  Wenn ein Super-Composites die Selectiontypen der Sub-Composites kennen würde, würde eine starke Bindung der Composites entstehen!
  Dies hat zur Folge, dass zwischen den einzelnen Hierarchiestufen der Composites jeweils ein Mapping der Daten erfolgen muss.
  
• Referenzieren Container eigene Selections?
  Container haben keine eigenen Selections, da sie zur Anzeige von Composites dienen.
• Weshalb verwendet ihr eigene Datenstrukturen (und nicht z.B. Value Objects die in einer Client-Server-Architektur direkt vom Server kommen)?
  Die Datenstrukturen in Selections sind speziell für die visualisierende Oberfläche optimiert.
• Es ist möglich sich an meinen Composites als SelectionChangeListener anzumelden. Wann soll ich als Entwickler eines Composite das Change Event feuern?
  Das ChangeEvent muss dann gefeuert werden, wenn der zum Composite gehörende Prozesschritt des Benutzungsmodells abgeschlossen ist.
• Weshalb sind die Typen der In- und Out-Selections identisch?
  Keep it simple: wir benötigten beim Programmieren desöfteren die Eingangswerte, welche zu einer bestimmten Out-Selection geführt haben (z.B. zur Implementierung von Validierungen). Durch die Konvention der symmetrischen Selections wird die Implementierung an vielen Stellen einfacher, weil immer alle Eingangs- und Ausgangserte vorliegen. Alle Sonderfälle werden durch eine Konvention abgedeckt.

Resourcen

• Was sind Resourcen?
  Resourcen sind grundsätzlich Arbeitsmittel, die benötigt werden, damit ein Composites seinen Zweck erfüllen kann, d.h. damit die Daten wie erwartet angezeigt werden, z.B. Farben, Fonts, Bilder, etc.
  
• Was ist eine ResourceConfiguration?
  ResourcenConfigurations sind Container für Resourcen. Über die Resourcenconfigurationen werden Resourcen gebündelt an ein Composite übergeben. Außerdem erhalten alle Resourcen über die Methodenbezeichner der zugehörigen Getter eine Semantik, z.B. Icon zur Visualisierung eines ungültigen Preises.
• Wer erzegt und füllt die Resourcekonfigurationen?
  Siehe Frage “Wer erzeugt und initialisiert die ActionConfigurations?” (Analogon).

Testbarkeit

• Wie werden POC-UI-Oberflächen getestet?
  Schauen Sie sich dazu einmal die Klassen org.pocui.swing.components.test.CompositeViewer (Swing-Projekt) und org.pocui.test.CompositeTester (Example-Projekt) an.
  Neben dem reinen Testen von Komponenten ist es durch die lose Kopplung der “ActionConfigurations” leicht möglich Programmteile die für das Testen der Oberflächen nicht relevant sind zum Testzeitpunkt auszublenden, indem mit Mock Objekten gearbeitet wird.