Prozessorientierte Konstruktion von


Fachthema
Oberflächlich mit System
Prozessorientierte
Konstruktion von
Benutzeroberflächen
Jan Christian Krause, Kai Benjamin Joneleit
Die POC-UI-Methode ist ein leichtgewichtiges Verfahren zur softwaretechnischen Strukturierung von grafischen Oberflächen. Sie ist in JavaProjekten des Teams Trading & Plant Employment von Vattenfall Europe
Information Services GmbH entwickelt worden und ergänzt die bestehenden Architekturmuster für grafische Benutzeroberflächen um einen Entwurfsprozess. Mit Hilfe dieser Vorgehensweise konnte bei der Vattenfall
Europe Information Services GmbH die Effizienz des Entwicklungsprozesses spürbar optimiert werden.
Einführung
Die Entwicklung moderner Softwaresysteme ist häufig durch
E hohe Komplexität und hohe Kosten geprägt. Beides steht oft
in proportionalem Verhältnis zueinander. Erfahrungsgemäß tragen die Aufwände zur Entwicklung grafischer Benutzeroberflächen signifikant zur Kostenentwicklung eines Projektes bei.
Dieser Artikel stellt mit der POC-UI-Methode (Process Oriented Construction of User Interfaces) einen Konstruktionsleitfaden für den software-technischen Entwurf grafischer Benutzeroberflächen vor. Ziel ist es, den Entwurfsprozess von Oberflächen durch Konventionen zu standardisieren und dadurch
Entwicklungs- und Wartungskosten zu senken.
Die POC-UI-Methode ist in Java-Projekten des Teams Trading
& Plant Employment von Vattenfall Europe Information Services GmbH über anderthalb Jahre entwickelt und in mehreren
Projekten international erfolgreich angewandt worden. Vattenfall Europe Information Services ist IT-Full-Service-Anbieter
für die Energiewirtschaft. Das Leistungsspektrum reicht von
der strategischen Beratung, der Konzeption von IT-Systemen,
der Entwicklung und Implementierung von IT-Lösungen bis
hin zum Outsourcing der gesamten IT-Infrastruktur.
Bestehende Ansätze zur software-technischen
Konstruktion von Oberflächen
Grafische Oberflächen werden je nach Kunden und Organisationsform des Projektes auf verschiedene Arten, wie z. B.
durch Anwendungsfälle, grafische Skizzen oder Story- bzw.
Taskcards spezifiziert. Bei fehlenden Konventionen unterscheiden sich die Implementierungen derselben Spezifikation oft nach Erfahrungen, Vorlieben und fachlichem Verständnis der Entwickler. Dies kann zu wiederkehrenden hohen Einarbeitungs- und Wartungsaufwänden für Programmierer führen.
Meist existieren Konventionen in Projekten auf hohen
technischen Detailebenen, z. B. für Methoden- bzw. Klassenbezeichner oder Klammersetzungen. Jedoch zeigt die Praxis,
dass der Entwurf und die Struktur von Klassenmodellen
selten vollständig durch Konventionen definiert sind. Dieses
Problem ist unabhängig von den verwendeten Grafikbibliotheken (z. B. das Standard Widget Toolkit [SWT], Swing
usw.) oder speziellen Oberflächen-Editoren (z. B. [Jigloo],
[Matisse] usw.).
In der Literatur finden sich diverse software-technische Architekturvorschläge für grafische Oberflächen, aus denen sich
Klassenmodelle ableiten lassen. Fowler identifiziert vier verschiedene Architekturtypen und grenzt diese anhand der Lokalisierung des Codes für Layout, Daten und Logik sowie für
den Datenfluss voneinander ab [Fowl06].
Bei allen Vorschlägen wird die Software-Komplexität auf den
beiden technischen Ebenen „Steuerelement“ (hoher Detailgrad)
und „Formular/Bildschirm“ (niedriger Detailgrad) behandelt.
Ebenen zwischen beiden Extrema sind mit technisch-orientierter Argumentation unscharf abgrenzbar. Züllighoven et al.
zerlegen die Formular-/Bildschirm-Ebene deshalb anhand von
fachlichen Kriterien rekursiv in Teil-Formulare (Prinzip „Teileund-Herrsche“) [Züll98]. Diese Abgrenzung orientiert sich an
den fachlichen Objekten, die in der jeweiligen Teil-Oberfläche
bearbeitet werden. Teil-Oberflächen werden als Werkzeuge zur
Bearbeitung der Objekte verstanden.
Jedoch bleibt die Frage unbeantwortet, wie ein Entwickler
aus Spezifikationen wie Anwendungsfällen, grafischen Skizzen
usw. die jeweilige Architektur ableiten kann und welche Rollen
an diesem Prozess beteiligt sind. Züllighoven et al. beschreiben
die Identifikation von Werkzeugen anhand fachlicher Szenarien in Textform. Dieses Vorgehen impliziert jedoch viel kreative Entwurfsarbeit seitens des Entwicklers. Zudem definiert
keiner der Architekturtypen die verschiedenen Zustände der
beteiligten Komponenten sowie deren Übergänge ineinander
(z. B. einer View in einer Model-View-Controller-Architektur).
In der Praxis ist ein definierter Lebenszyklus sehr nützlich, beispielweise bei der Eingrenzung von Fehlern oder bei der Auswahl einer geeigneten Stelle für Erweiterungen im Quelltext.
Standardisierter Oberflächenentwurf
mit der POC-UI-Methode
Die POC-UI-Methode wird anhand eines einfachen Beispiels
erläutert: eine grafische Oberfläche ist in das bestehende Kundenverwaltungssystem eines Energieversorgers zu implementieren. Die Oberfläche dient der Anzeige der Vertragsdaten (u.
a. Bankverbindung, Stromtarif), der Anschrift und des Bemerkungstextes zu einem Privatkunden. Ein Kunde wird über seine Kundennummer oder seinen Namen gefunden (Vor- oder
Nachname als Volltextsuchkriterium). Das Anklicken des Kunden in der Trefferliste führt zum Visualisieren der zugehörigen
Kundendaten. Sollte der Kunde nicht im System vorhanden
sein, so wird dem Mitarbeiter ein Fehler angezeigt.
Aus Platzgründen wird in diesem Artikel kein Quelltext diskutiert. Eine Implementierung dieses Beispiels in Java/Swing
steht auf der Internetseite von POC-UI zum Download bereit
[POC-UI].
Beschreibung des Entwurfsprozesses
Die POC-UI-Methode ist ein software-technischer Konstruktionsleitfaden für grafische Oberflächen. Sie hilft Architekten
und Kunden bzw. Fachabteilungen beim Entwurf eines Benutzungsmodells sowie Programmierern bei der Strukturierung
des Quelltextes auf dessen Basis.
Abbildung 1 zeigt den Entwicklungsprozess nach der POCUI-Methode. Insgesamt sind drei Rollen an dem Prozess beteiligt: der Kunde/die Fachabteilung, der Architekt und der Programmierer. Ausgangspunkt des Prozesses ist die Spezifikation
 NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: [email protected]
27
Fachthema 
ändert der Kunde zunächst die Spezifikation. Anschließend
wird der Prozess in Phase 1 fortgesetzt. Fehlerhafte Implementierungen werden vom Programmierer gemäß Spezifikation
korrigiert (Phase 2).
Definition des Benutzungsmodells
Abb. 1: Entwurfsprozess nach der POC-UI-Methode
des Kunden. Da der Entwurfsprozess nicht auf eine bestimmte
Form der Kundenspezifikation ausgerichtet ist, kann die POCUI-Methode problemlos in verschiedene Vorgehensmodelle
wie das Wasserfallmodell, das V-Modell oder agile Ansätze wie
Scrum, XP usw. integriert werden.
Der Entwurfsprozess gliedert sich nach klassischer iterativer
Vorgehensweise in drei Phasen:
Phase 1: Definition des Benutzungsmodells
Zunächst definiert der Architekt gemeinsam mit dem Kunden
das Benutzungsmodell der zu implementierenden Oberfläche.
Dieses besteht aus:
Heinem Prozessmodell, welches die fachlichen Aufgaben enthält,
die mit der Oberfläche bearbeitet werden können. Ferner definiert es die logische Ausführungsreihenfolge der Aufgaben.
Heiner Spezifikation des Layouts, der zu verwendenden Steuerelemente (Knöpfe, Tabellen, Checkboxes, ...) und deren Interaktion.
Das Prozessmodell und die Layoutspezifikation werden in direkter Wechselwirkung erstellt.
Phase 2: Implementierung des Benutzungsmodells
Anschließend leitet der Programmierer aus dem Benutzungsmodell ein Klassenmodell ab und programmiert das Layout
sowie das Verhalten der Oberfläche.
Phase 3: Verifikation des Benutzungsmodells
Abschließend prüft der Kunde, ob die Implementierung seinen
Bedarf deckt. Sollten Änderungen an der Implementierung erforderlich sein, die nicht aus der Spezifikation hervorgehen,
Abb. 2: Einordnung des Benutzungsmodells
28

Das Benutzungsmodell ist das Bindeglied zwischen Spezifikation und Implementierung (s. Abb. 2). Es transformiert die
fachliche Spezifikation der Anforderungen in explizite Vorgaben zur Implementierung. Die Erfahrung zeigt, dass diese Transformation in der Praxis meist implizit durch den Programmierer vorgenommen wird. Während dieser Phase treten häufig erst sehr viel später erkannte Missverständnisse auf,
die zur negativen Beeinflussung der Entwicklungskosten beitragen. Die dargestellte Dreiteilung hat sich beim Entwurf von
Datenmodellen für Datenbanken bewährt und ist auf den Entwurf grafischer Oberflächen übertragbar (Aufteilung in konzeptuelles, logisches und physisches Modell).
Das Benutzungsmodell besteht aus einem Prozessmodell und
einer Layoutspezifikation. In der Layoutspezifikation legen
Kunde und Architekt die zu verwendenden Steuerelemente und
deren Anordnung fest. Das Prozessmodell enthält die Aufgaben, welche über die Oberfläche bearbeitet werden können, sowie deren logische Reihenfolge. Aufgaben, die durch das Backend oder den Benutzer allein ausgeführt werden, sind nicht
enthalten. Aufgaben können in Teilaufgaben aufgespalten werden (repräsentiert durch Subprozesse). Diese Aufgabenspezifikation bildet die Grundlage des Klassenmodells.
Der Programmieraufwand kann zwischen den Aufgaben aus
dem Prozessmodell variieren. Aus diesem Grund muss der Architekt software-technisch komplexe Aufgaben erkennen und
deren fachliche Zerlegung in Teilaufgaben gemeinsam mit dem
Kunden herbeiführen. Ebenso muss er den Kunden vor der, aus
software-technischer Sicht, zu detaillierten Formulierung von
Aufgaben bremsen. Der Hauptzweck des Prozessmodells ist die
fachliche Reduktion der Aufgabenkomplexität durch den Kunden. Es beschreibt deshalb unter anderem nicht alle möglichen
Durchläufe des Benutzers durch die Oberfläche oder Rücksprünge zwischen den Aufgaben. Für detaillierte Entwurfsleitlinien wird auf die POC-UI-Internetseite verwiesen [POC-UI].
Das Prozessmodell für das vorab erläuterte Beispiel ist in
Abbildung 3 enthalten. Als Notation wird die Business Process
Modelling Notation (kurz BPMN) verwendet, welche sich insbesondere aufgrund der Notationselemente Pool und Lane sehr
gut für das Modellieren der Prozesse nach der POC-UI-Methode eignet. Diese repräsentieren jeweils die Applikation und den
Container einer Oberfläche. Grundsätzlich sind aber auch andere Notationen wie UML-Aktivitätsdiagramme nutzbar.
Abb. 3: Prozessmodell für die Beispielanwendung
NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: [email protected]

Fachthema
Ableitung des Klassenmodells aus dem
Benutzungsmodell
Aus dem Prozessmodell des Benutzungsmodells leiten sich die
beteiligten Klassen und ihre Beziehungen untereinander ab.
Die beteiligten Klassen lassen sich in drei verschiedene Kategorien einteilen:
HContainer repräsentieren den äußeren Rahmen einer Oberfläche, z. B. als einfacher Dialog, Seite eines Assistenten oder
ViewPart. Über Container werden die Oberflächen in die
umgebende Applikation integriert.
HComposites kapseln das Layout und das Verhalten der
Oberfläche (Benennung nach dem Kompositum-Muster,
s. [GoF95]).
HSelections repräsentieren den fachlichen Zustand eines Composites. Dieser Zustand ist die Aggregation der Zustände
aller enthaltenen Steuerelemente und Sub-Composites. Die
Bezeichnung Selection ist in Anlehnung an den Begriff Selektion (eines Elements aus dem Wertebereich des Steuerelements) gewählt worden.
Eine Oberflächen-Implementierung nach der POC-UI-Methode
besteht im einfachsten Fall aus einem Container, einem Composite und einer Selection. Durch die Trennung von Container und
Composites wird der Austausch von Containern ermög­licht.
So können Composites ohne die Applikation über Testcontainer gestartet und manuell getestet werden. Dies minimiert den
Zeitaufwand für Compile-Debug-Zyklen erheblich. Der ViewBegriff der Model-View-Controller- und Model-View-Presenter-Architekturen sieht diese Unterscheidung nicht vor.
Die POC-UI-Methode definiert, dass für jede Aufgabe aus
dem Prozessmodell ein korrespondierendes Composite mit
eigenem Selection-Typ existiert. So ergibt sich aus der Aufgabenhierarchie im Prozessmodell eine analoge Composite-Hierarchie im Klassenmodell. Eine Composite-Klasse kapselt alle
zu einer Aufgabe minimal benötigten Steuerelemente und SubComposites. Die zu verwendenden Steuerelemente sind in der
Layoutspezifikation definiert.
Abbildung 4 zeigt alle am Beispiel beteiligten Composites und
ihre Aggregation. Da Container zu Testzwecken austauschbar
sein sollen, dürfen sie selbst kein Verhalten der Oberfläche im-
plementieren. Folglich kann der Container nur genau ein Composite referenzieren, welches die gesamte Oberfläche kapselt.
Diese Überlegung spiegelt sich in der Aufgabenhierarchie des
Prozessmodells wider, weil diese immer ein Baum mit einer
Wurzel-Aufgabe bzw. einem Wurzel-Composite ist. Hier wird
die Erstellung des Prozessmodells als eine software-technische
Modellierungsleistung des Architekten deutlich erkennbar.
Lebenszyklus eines Composites
Grundsätzlich durchläuft ein Composite zunächst die Initialisierungs-, dann die Nutzungs- und abschließend die Finalisierungsphase. Die Klasse AbstractComposite der Beispielimplementierung realisiert diesen Lebenszyklus als Superklasse jedes
Composites [POC-UI]. Sie definiert die Methoden für die Übergänge zwischen den Zuständen. Der Composite-Lebenszyklus
wird durch das Zustandsdiagramm in Abbildung 5 gezeigt.
Da vor allem Initialisierungsmethoden sehr lang und unübersichtlich werden können, wird die Initialisierungsphase in die Layout-, die Verhaltens- und die Wertinitialisierung
unterteilt. So ist die semantische Eindeutigkeit der einzelnen
Methoden gewährleistet und der Programmierer kann exakt
zuordnen, welcher Code in welcher Methode zu platzieren ist.
Die einzelnen Initialisierungsmethoden werden dadurch kürzer und übersichtlicher. Tabelle 1 gibt einen kurzen Überblick
über die Semantik der Methoden.
Abb. 5: Lebenszyklus eines Composites
Abb. 4: Analogie zwischen Aufgabenhierarchie und Composite-Hierarchie
 NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: [email protected]
29
Fachthema 
Methodenname
Kurzbeschreibung
void initGUI()
In initGUI() werden Layout, Steuerelemente und Sub-Composites instanziiert
void initListener()
In der Methode
Composites
void setSelection
Über diese Methode werden Selections an das Composite übergeben und auf dessen Steuerelemente
und Sub-Composites abgebildet. Dies ist die einzige Stelle im Composite, an der Datenübergaben an
Steuerelemente oder Sub-Composites implementiert sind
(ISelection selection)
void cleanUp()
initListener()
werden alle Beobachter instanziiert, z. B. für Steuerelemente oder Sub-
Diese Methode repräsentiert die Finalisierung des Composites, z. B. wenn dessen Container geschlossen worden ist. Hier werden z. B. Beobachter von den Steuerelementen und Sub-Composites wieder abgemeldet
Tabelle 1: Kurzübersicht wichtiger Methoden der Klasse AbstractComposite
Fehlerkategorie
Einstiegsmethode
Layoutfehler
initGUI()
Falsch angezeigte Werte
setSelection()
Unerwartetes Verhalten
initListener
Finalisierungsfehler
cleanUp()
Tabelle 2: Fehlerkategorien und Einstiegsmethoden in der Klasse AbstractComposite
In jeder der hier abgebildeten Phasen können spezifische
Fehlersituationen auftreten, welche sich in Kategorien einteilen lassen. Die zugehörigen Methoden der Zustandsübergänge
bieten Einstiegspunkte in den Code, wodurch es dem Programmierer möglich wird, Fehler schnell einzugrenzen. Es ist dabei
irrelevant, welcher Programmierer den Quelltext geschrieben
hat, da der Methodenaufbau und der Lebenszyklus bei allen
Composites auf dieselbe Weise definiert sind. Tabelle 2 enthält
identifizierte Fehlerkategorien und die jeweilige Einstiegsmethode zur Fehlerlokalisierung.
Modellierung des Datenflusses
Die POC-UI-Methode definiert, dass sich alle technischen Zustände eines Composites ausschließlich aus der zugehörigen
Selection ableiten müssen. Der Datenfluss folgt immer demselben Schema:
HSchritt 1: Zuweisung neuer Werte an die Selection-Instanz.
HSchritt 2: Übergabe der Selection-Instanz an das Composite
mittels Aufruf von setSelection().
In der Methode setSelection() ist die Zuweisung der SelectionAttribute auf die einzelnen Steuerelemente und Sub-Composites
implementiert. So wird beim Aufruf dieser Methode die gesamte
Sub-Composite-Hierarchie je nach Bedarf aktualisiert. Es ist irre-
levant, ob die Selection Composite-intern (z. B. durch einen ModifyListener eines Textfeldes) oder Composite-extern durch ein
hierachisch übergeordnetes Composite verändert worden ist.
Gemäß der Composite-Hierarchie melden Super-Composites an ihren Sub-Composites Beobachter an. Die Beobachter
werden benachrichtigt, sobald eine modellierte Aufgabe abgeschlossen ist. Abbildung 6 zeigt dieses Prinzip anhand der
Aufgabe „Öffne Kundendatensatz“ aus dem Prozessmodell
des Beispiels in Abbildung 3. Nachdem der Benutzer den Namen eines Kunden eingegeben hat, klickt er auf den Knopf
„Suchen“. Dadurch ist eindeutig definiert, dass die Aufgabe
„Erfasse Suchkriterium“ abgeschlossen ist.
Das Composite „Erfasse Suchkriterium“ feuert das entsprechende Ereignis (Schritt 1). Das hierarchisch nächsthöhere Composite hat jeweils einen Beobachter an seinen Sub-Composites registriert und kann so auf deren Zustandsänderungen reagieren.
Sobald ein Suchkriterium erfasst ist, startet dieser Beobachter die
Kundensuche und setzt die gefundenen Kunden in die Selection
des „Öffne Kundendatensatz“-Composites. Der anschließende
Aufruf von setSelection() führt dazu, dass beide Sub-Composites,
falls notwendig, aktualisiert werden (Schritt 2).
Das Benutzungsmodell des Beispiels definiert, dass die Aufgabe „Öffne Kundendatensatz“ erst abgeschlossen ist, wenn
ein gefundener Kunde aus der Trefferliste selektiert worden
ist. Aus diesem Grund wird das Ereignis nicht weiter nach
oben in der Hierarchie propagiert. Während der Erstellung des
Prozessmodells definiert der Architekt gemeinsam mit dem
Kunden für jede Aufgabe, nach welchen Ereignissen diese abgeschlossen ist. Das Sequenzdiagramm in Abbildung 7 zeigt
das skizzierte Beispiel im Detail.
Composites feuern Ereignisse ausschließlich nach Abschluss
einer modellierten Aufgabe. Diesen software-technischen Aspekt muss der Architekt beim Entwurf des Prozessmodells
berücksichtigen. Sobald mehrere Ereignistypen notwendig
werden, liegt erfahrungsgemäß ein Modellierungsproblem im
Prozessdiagramm vor. Durch den einheitlichen Lebenszyklus
Abb. 6: Datenfluss während der Kundensuche in der Beispielanwendung
30

Abb. 7: Datenfluss zur Suche eines Kunden im Beispiel
NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: [email protected]

Fachthema
und die daraus resultierenden einheitlichen Schnittstellen sind
Composites als in sich geschlossene Komponenten zu verstehen.
Bei Programmerweiterungen oder bei der Fehlersuche können
diese Komponenten als Blackboxes betrachtet werden und damit die Komplexität des zu betrachtenden Quelltextes reduzieren. Außerdem sind die Komponenten in verschiedenen Oberflächen wiederverwendbar.
Erfahrungen mit der POC-UI-Methode
Über die vergangenen anderthalb Jahre konnten Erfahrungen in
den Planungs-, Entwicklungs- und Wartungsphasen verschiedener Projekte der Vattenfall Europe Information Services GmbH
gesammelt werden. In der Planungsphase wird über das Benutzungsmodell explizit definiert, wie die zu implementierende
Oberfläche in fachlich und software-technisch identisch strukturierte Teilprobleme zu zerlegen ist. Auf diese Weise entstand bei
allen Beteiligten ein gemeinsames Verständnis und daraus resultierend eine weniger aufwändige, dafür präzisere Kommunikation. Entwickler konnten Aufwandschätzungen für einzelne Teilprobleme abgeben, die vom Projektleiter gemäß der Aufgabenhierarchie des Prozessmodells aggregiert wurden. Der Aufwand
für die so abgegrenzten Teilprobleme konnte einfacher und meist
auch präziser als für die gesamte Oberfläche geschätzt werden.
Während der Entwicklungsphase wurden spürbare Produktivitätsgewinne erzielt. Aufgrund des klar strukturierten Prozessund Klassenmodells arbeiteten mehrere Entwickler zeitgleich
an einem Dialog. Dies geschah praktisch ohne Integrationsaufwand durch z. B. Merge-Konflikte in der Versionskontrolle. Des
Weiteren wurde viel Entwurfszeit gespart, da kein Entwickler
ein umfangreiches Klassenmodell inklusive Lebenszyklus der
Komponenten und deren Datenfluss neu konzipieren musste.
In der Wartungsphase machten sich das iterativ dokumentierte Benutzungs- und Klassenmodell, der definierte Lebenszyklus und das Datenflusskonzept bezahlt. Entwickler fanden
sich sowohl in eigenem als auch in fremdem Quelltext sehr
schnell zurecht. So wurde die verfügbare Zeit größtenteils in
die Lösungsimplementierung und weniger in das Verständnis,
beispielsweise des Klassenmodells, investiert. Durch strukturierten Quelltext und Lebenszyklen waren Seiteneffekte durch
Änderungen an fremdem Quelltext für Entwickler abseh- und
eingrenzbarer. Dies ist ein nicht zu unterschätzender Gewinn,
da viele Entwickler vor Änderungen an fremdem Code gehemmt sind. Der durch diese Hemmungen verursachte Zeitverlust wird durch den Einsatz der POC-UI-Methode minimiert.
Außerdem führte der Einsatz der POC-UI-Methode meist
automatisch zu einfacher zu bedienenden Oberflächen, da alle Steuerelemente und Sub-Composites zur Bearbeitung einer
fachlichen Aufgabe in einem eigenen Composite zusammengefasst werden. Dies impliziert, dass diese nah beieinander in der
Oberfläche platziert sind. Nach dem Gesetz der Nähe aus der
Gestaltpsychologie ist es für den Benutzer so einfacher, einen
inhaltlichen Bezug zwischen den Komponenten herzustellen
[Wert23]. Dies bedeutet aber auch, dass die Steuerelemente und
Sub-Composites nicht völlig frei auf dem Bildschirm platziert
werden können, ohne die Konventionen zu verletzen.
Einige Entwickler bevorzugen Systeme mit wenigen, dafür
aber längeren Klassen. Es muss jedoch erwähnt werden, dass die
POC-UI-Methode ungeeignet für diese Entwickler ist. Ihr Einsatz
führt meist zu mehreren kürzeren Klassen. Des Weiteren wird
der Mehrwert durch Einsatz der POC-UI-Methode in eingespielten Teams mit ähnlich umfassenden Konventionen gering sein.
Hier bietet es sich an, einzelne POC-UI-Konzepte bei Bedarf in
die bestehende Menge an Konventionen zu übernehmen.
Fazit
Dieser Artikel stellt mit der POC-UI-Methode ein leichtgewichtiges Verfahren zur software-technischen Strukturierung von
grafischen Oberflächen vor. Sie ergänzt die bestehenden Architekturmuster um einen Entwurfsprozess, welcher die fachliche Zerlegung der Oberfläche in Komponenten vorgibt und
zeigt, wie diese in eine einheitlich strukturierte Implementierung überführt werden können. Ferner führt ein definierter Lebenszyklus der Komponenten zur schnelleren Lokalisierung von
Fehlern und geeigneten Stellen für Erweiterungen im Quelltext
der Oberfläche. Durch den Einsatz dieser Vorgehensweise konnte bei Vattenfall Europe Information Services die Effizienz des
Entwicklungsprozesses spürbar optimiert werden.
Die POC-UI-Methode wird durch eine sehr kleine Klassenbibliothek für Java/Swing unterstützt (für Download siehe
[POC-UI]). Die Methode ist im Kern von der Technologie unabhängig und lässt sich mit geringem Zeitaufwand portieren. Neben den hier beschriebenen Aspekten bietet sie Konventionen
für den Umgang mit Ressourcen (Bilder, Farben usw.), die Integration von Containern in die Applikation und die Kapselung
von Geschäftslogik. Als zukünftige Entwicklungsperspektiven
sind die Portierung auf andere Programmiersprachen sowie
die stärkere Integration der Applikation und der eventuell vorhandenen Server in die POC-UI-Methode zu nennen.
Literatur und Links
[Fowl06] M. Fowler, GUI Architectures, 2006;
http://martinfowler.com/eaaDev/uiArchs.html
[GoF95] E. Gamma, et al., Design Patterns – Elements of
Reuseable Object-Oriented Software, Addison-Wesley, 1995
[Jigloo] Jigloo SWT/Swing GUI Builder for Eclipse and WebSphere,
http://www.cloudgarden.com/jigloo/
[Matisse] Matisse GUI Editor,
http://www.netbeans.org/kb/articles/matisse.html
[POC-UI] Sourceforge-Projekt Process-Oriented-Construction of
User Interfaces, http://pocui.sourceforge.net
[SWT] The Standard Widget Toolkit, http://www.eclipse.org/swt/
[Wert23] M. Wertheimer, Untersuchungen zur Lehre von der
Gestalt, in: Psychologische Forschung: Zeitschrift für Psychologie und ihre Grenzwissenschaften 4, Seite 301-350, 1923
[Züll98] H. Züllighoven, et al., Das objektorientierte Konstruktionshandbuch nach dem Werkzeug & Material-Ansatz,
dpunkt Verlag, 1998
Jan Christian Krause ist Diplom-Wirtschaftsinformatiker (FH) und Berater beim Hamburger ConsultingHaus AKRA GmbH. Er verfügt über umfangreiche
Erfahrungen im Bereich der Rich-Client-Entwicklung,
insbesondere auf Basis der Eclipse RCP. Neben dem
Engagement in Projekten verfasst er seine Dissertation im Kontext serviceorientierter Architekturen und
maschineller Sprachverarbeitung an der Universität
Hamburg.
E-Mail: [email protected].
Kai Benjamin Joneleit ist Diplom-Medieninformatiker (FH) und arbeitet als Berater bei der CS
Consulting AG in Hamburg. Er hat langjährige Erfahrung in der Entwicklung von Enterprise-Applikationen,
insbesondere in der GUI-Entwicklung im Java-Umfeld.
E-Mail: [email protected].
 NUR für Abonnenten: Haben Sie schon Ihren Log-In für den kostenlosen Download aller Artikel-pdfs? Kontakt: [email protected]
31