Wartbare, Plattformunabhängige Grafische Benutzeroberflächen Schnell Entwickeln

Transkript

1 Wartbare, Plattformunabhängige Grafische Benutzeroberflächen Schnell Entwickeln Axel Pospischil Mai 2006 Version 1.4

2 Zusammenfassung Der Autor sucht nach Möglichkeiten, plattformunabhängige grafische Benutzerschnittstellen mittlerer Größe zu erstellen, die den Anspruch auf Enterprise Niveau haben (Multiple Fenster, zentraler Datenbestand), jedoch von kleinen Entwicklerteams (2+) in kurzer Zeit erstellt werden können. Dazu soll ein robustes, gut dokumentiertes und gewartetes natives GUI Framework verwendet werden (JFace, ein freies Klassenframework von IBM (eclipse.org) für die Java Plattform 5). Die erstellte Applikation soll dabei übersichtlich, gut wartbar und erweiterungsfähig sein. Auf die Verwendung von GUI Buildern wird verzichtet. Es wird zum Einen ein Prozess zum Mappen von Entwurfsmustern auf konkrete Anwendungen vorgestellt. Zum Anderen durch Reverse Engineering des Musters Actions and Contributions aus JFace gezeigt, wie man Muster in quelloffenen Umgebungen identifizieren und für die weitere Verwendung im Team dokumentieren kann.

3 Copyright Wartbare, Plattformunabhängige Grafische Benutzeroberflächen Schnell Entwickeln. Copyright: Axel Pospischil, Wiesbaden, Mai 2006 Die Weitergabe und Veröffentlichung im Bereich der öffentlich geförderten Forschung und Lehre ist ausdrücklich erlaubt. Jede Weitergabe, Vervielfältigung, Veröffentlichung, Veränderung - auch in Auszügen - für kommerzielle Zwecke ist ohne Genehmigung des Autors untersagt. Dies gilt auch für die Entfernung oder Änderung des Passwortschutzes der PDF Version dieser Arbeit. Änderungen Version 1.4 (9/2009) Rechtschreibkorrekturen. Leichte Änderungen am LATEX Style hitec_book. Marken für Kapitel hinzugefügt, diese werden nun in der Fußzeile angezeigt (durch Hinzufügen von markboth {Name}{}... ) Version 1.3 (4/2008) Größere Rechtschreibkorrektur. Umstellung des Stils der Literaturverweise von alphadin [AUT99] auf apalike [Autorname, 1999]. LATEX Style geändert auf neuen Style hitec_book (abgeleitet von lyx2webook_hitec). Preamble komplett von der Lyx Layout Datei ausgelagert in das Lyx Dokument (Einstellungen->Preamble). Schriftgröße / - art auf 11pt / Serifen geändert. Einige Grafiken auf Seitenbreite vergrößert. Algorithmenumgebung für Code ersetzt durch L Y X Programmlistings (LATEX listings Paket). Umbruchprobleme im Blocksatz durch Verwendung von \sloppy gelöst. Version 1.2 (2007) Geringe Änderungen, Korrekturen Anpassung des Ausgangsformates an L Y X Version 1.5.x. Version 1.1 ( ) Erste kommerzielle Version nach der Bachelorarbeit HCI Pattern ergänzt um das Beispielprogramm Glossar, Index und Algorithmenverzeichnis hinzugefügt nach Behebung von Fehlern im LATEX Indizierungssystem (makeindex.sh und xindy) Zahlreiche Rechtschreibkorrekturen. Version 1.0 ( ) Bachelorarbeit Abgabe (Begonnen am ). Hochschule Darmstadt, Fachbereich Informatik. Betreuer: Prof. Dr. B. Humm. Zweitkorrektor: Prof. Dr. H. Schneider. Die Arbeit wurde erfolgreich mit 1.3 benotet.

4 Inhaltsverzeichnis Inhaltsverzeichnis Vorwort Zielgruppe i vi vii I Plattformunabhängig 1 1 Programmiersprachen 3 1 Die Rolle der Codebasis 4 2 Komplexität 6 3 Virtualisierte Codeplattformen Virtualisierung Java C# - Mono Fazit 13 5 Quellen und weiterführende Hinweise 14 2 Grafische Entwicklungframeworks 15 1 Auswahl der Kandidaten QT GTK wxwidgets Swing SWT/JFace Fazit 21 3 Quellen und weiterführende Hinweise 21 II Wartbar 22 I

5 3 Benutzerschnittstellen 23 1 Motivation Komplexität Wie könnte man mit dieser Komplexität umgehen? Abgrenzung und Einordnung Analyse eines fiktiven Projektverlaufs Irrige Überzeugungen All in One Entwicklungsumgebungen machen die Arbeit leichter Abhängigkeit von der verwendeten Programmierumgebung Unzureichende Trennung von Designcode und GUI Code Stabilitätsprobleme der GUI nach Codeänderungen Codegenerierung mit einem GUI Builder Optionen, die vom Kunden als selbstverständlich vorausgesetzt werden Quellen und weiterführende Hinweise 33 4 Den Entwicklungsprozess managen 34 1 User Interface Standards 36 2 Der softwaretechnische Entwurf Entwurfsprinzipien Heuristiken Refactoring Fazit Entwurfsmuster Beschreibung Musterkataloge Mustersprachen HCI (Human Computer Interaction) Faktor Implementierung Fazit II

6 4 Erneute Bestandsaufnahme Werkzeuge GUI Builder Softwarentwurf mit UML Entwicklungsumgebung Vorgehen Klassische Entwurfsmuster identifizieren Mustermapping Mappingbeispiel: Command Anforderung Informationssammlung Anwenden auf das eigene Problem Testen und Einordnen Dokumentation Weiteres Vorgehen Fazit Actions and Contributions Motivation Benutzerinteraktionen implementieren ist teuer Unbekannte Muster identifizieren Verfahren: Reverse Engineering Erfassen der Dokumente Das Konzept von Actions and Contributions in JFace Extraktion des UML Modells Reduzierung auf relevante Klassen Der Zustand - Actions Die Darstellung - Contributions Statische Sicht ContributionItems ContributionManager ActionContributionItem Dynamische Sicht Implementierung Dokumentation Implementierung von Actions am Beispiel Fazit III

7 7 Erneute Mustersuche Entwurf Weitere Vorüberlegungen UML Modell Implementierung Fazit Behandlung komplexerer Fensterinhalte Gruppierung von Actions Reengineering - Refactoring Fazit Zusammengesetzte Muster für Multifensteranwendungen Observer MVC - Model View Controller Presentation Model, Model View Presenter Fazit Quellen und weiterführende Hinweise Fazit Plattformunabhängigkeit Schnelle Entwicklung Wartbarkeit Benutzerinteraktionen Multifensteranwendungen Schlusswort 108 Verzeichnisse 110 Literaturverzeichnis 110 Abbildungsverzeichnis 113 IV

8 Tabellenverzeichnis 114 Programmlistenverzeichnis 114 Stichwortverzeichnis 115 Anhang 117 Mustermapping 118 Actions and Contributions Klassenbeschreibungen Action ActionContributionItem Cookbook 121 V

9 Vorwort Wer kennt das nicht? Die ersten Gespräche mit dem Kunden verlaufen vielversprechend. Die vielfältigen Möglichkeiten zur Softwareentwicklung im Kopf, finden sich schnell zahlreiche Anforderungen auf der Liste wider, ohne dass genau klar ist, wie diese tatsächlich umgesetzt werden können. Benutzerfreundlichkeit oder Usability ist dabei eine Standardanforderung für grafische Oberflächen. Moderne Entwicklungsumgebungen für grafische Benutzerschnittstellen lassen einen leicht vergessen, dass diese maschinell erstellte Software später auch gewartet werden muss. Doch wie kann man sich von diesen Werkzeugen unabhängig machen? Wie kann verhindert werden, dass das Rad immer wieder neu erfunden wird? Der Autor zeigt auf, wie die objektorientierte Vorgehensweise helfen kann, die Komplexität der Anforderungen an grafische Benutzerschnittstellen in den Griff zu bekommen. Ein Softwareprojekt verbringt heutzutage nur noch 10-25% seines Lebenszyklus in der eigentlichen Entwicklungsphase % werden für Wartungsund Erweiterungsarbeiten eingeplant. Dies bedeutet zwangsläufig auch, dass für die Entwicklung immer weniger Zeit zur Verfügung steht. Wie kann dies organisiert werden und welche Hilfsmittel stehen dem Entwickler und Softwarearchitekten dabei zur Verfügung? Entwurfsmuster speichern das Wissen über softwaretechnische Fragestellungen. Doch wie lässt sich dieses Wissen für reale Anwendungen nutzen? Die wichtigsten Standardwerke über Entwurfsmuster stammen aus der Mitte der 90er Jahre. Konzepte und Muster für die Entwicklung grafischer Oberflächen und deren Implementierung gehen bis auf die frühen 80er Jahre und weiter zurück. Schon bei deren Lektüre wird rasch klar, dass ein tieferes Verständnis der Quellen notwendig und das objektorientierte Programmierparadigma mehr ist, als die stereotype Anwendung von Entwurfsmustern. Sie ist ein kreativer Prozess, der tief mit den realen Anforderungen verbunden ist. Hinzu kommen eine Fülle an Möglichkeiten zur Implementierung grafischer Benutzerschnittstellen: auf verschiedenen Betriebssystemplattformen, Programmiersprachen und Rechnerarchitekturen. Weitere Faktoren sind die stetig wachsende Zahl an verfügbaren Klassensammlungen, deren Anzahl auch für Ex- VORWORT VI

10 perten schwer überschaubar ist. Welche Produkte eignen sich für das konkrete Ziel, grafische Oberflächen plattformübergreifend zu realisieren, ohne dabei zu stark von einem Hersteller abhängig zu sein? Und wie kann man das Wissen, welches in quelloffenen Klassensammlungen vorhanden ist, für eigenen Projekte nutzbar machen und dokumentieren? Viele Entwickler sehen sich als Mitglied einer weltweiten Gemeinschaft, die versucht, die Probleme der Informatik und deren Forschungsgegenstände zu dokumentieren, zu kommentieren und zu beschreiben. Dies schliesst Laien, Akademiker, Fachleute und Anwender mit ein. Ihre wesentliche Kommunikationsplattform ist die Entwicklung und Nutzung von Open Source Software. Der Zuwachs an freien Programmiersprachen, Frameworks und Werkzeugen ist enorm. Demgegenüber steht eine gut ausgestattete Konkurenz mit kommerziellen, hochintegrierten Entwicklungsumgebungen und Plugins, die natürlich auch Ihren Preis haben. Zahlreiche Schenkungen von Software an die Community und eine Standardisierungswelle sondergleichen dokumentieren diesen Vorgang deutlich: IBM: Eclipse.org. Sun: OpenSolaris, Java. Apple: MacOSX. Microsoft: CLR und C# u.s.w. Der Autor ist der festen Überzeugung, dass dies nicht aus reiner Gutmütigkeit geschieht. Die Anforderungen an Software sind mittlerweile so komplex, dass es für eine Firma alleine zu kostspielig ist, diese Software zu warten und weiterzuentwickeln. Man ist dringend auf eine weltweite Zusammenarbeit angewiesen. Der Autor wird Vorgehensweisen aufzuzeigen, um das bereits in hohem Masse und ausgezeichneter Qualität verfügbare Wissen aus Sekundärliteratur, Entwurfsmustern, aber auch aus quelloffenen Klassensammlungen zu extrahieren und für die eigene Softwareentwicklung zugänglich zu machen. Dabei soll nicht verschwiegen werden, dass dies im ersten Anlauf keinesfalls schnell vonstatten geht. Hat man aber erst einmal ein Grundverständnis erlangt und die Umsetzung der Prinzipien des objektorientierten Paradigmas praktiziert, kann dies die Effizienz der Entwicklung und die Qualität der Softwareprodukte erheblich steigern. Zielgruppe Für wen diese Arbeit geschrieben ist Diese Arbeit ist etwas für Sie, wenn... Sie selbständiger Programmierer sind, keine große Programmierabteilung hinter Ihnen steht und sie mit fertigen GUI Code versorgt. Noch nicht so genau wissen, wie sie Entwurfsmuster in konkreten Programmcode umsetzen können. Mehr Zeit mit der Anwendung guten Softwaredesigns verbringen wollen, als mit dem Schreiben von GUI Code. ZIELGRUPPE VII

11 SWT kennen, aber sich schon immer geärgert haben, warum die Dinge eigentlich genauso kompliziert sind, wie mit SWING und sie zusätzlich noch Allokieren/Deallokieren müssen. Open Source mögen, aber auch gerne Anwendungen schreiben, die sie vermarkten können. Eclipse als Programmierumgebung schätzen, weil Sie das objektorientierte Programmieren und Refactoring optimal unterstützt. Sie ein UML Werkzeug mit Roundtripengineering besitzen oder ausprobieren wollen, weil Sie der Überzeugung sind, dass gutes Softwaredesign für wartungsfreundlichen Code mindestens ebenso wichtig ist, wie der Code, der darunter liegt. Ihre Anwendungsentwicklung so planen möchten, dass spätere Erweiterungen und Änderungen möglich sind, weil Sie wissen dass ein Softwareprojekt den überwiegenden Teil seiner Zeit in der Wartung verbringt. Sie de Schaffung einer konkreten Umgebung für die Entwicklung kleinerer performanter, plattformunabhängiger Software vorhaben oder sich darauf vorbereiten möchten. GUIs lieber per Hand erstellen, als mit einem GUI Builder. Diese Arbeit ist (wahrscheinlich) nicht für Sie, wenn... Sie meinen, diese Arbeit sei ein schnelles HowTo für den Umgang mit einem hochintegrierten Entwicklungswerkzeug wie Rational Rose, Together Control Center oder mit GUI Buildern, wie JBuilder & Co. Sie eine Arbeit über HCI (Human Computer Interaction) erwarten. Sie etwas über die Anforderungen an Tests und deren Umsetzung zu diesem Thema erfahren möchten. Sie etwas über das Deployment von SWT/JFace Anwendungen für verschiedene Plattformen wissen möchten. Sie eine Arbeit über User Interface Design oder Usability von grafischen Benutzeroberflächen vermuten. Sie alles über die Lizenzproblematik bei der Entwicklung kommerzieller Software mit Open Source Anwendungen erfahren möchten. Sie etwas über Entwicklungsprozesse für die Anwendungsentwicklung (Rapid Development, FURPS+) erfahren möchten in Anlehnung an Prozesse wie [Rosenberg and Scott, 2001], [Rational, ], [Bruegge and Dutoit, 2004] oder [Larman, 2001] Sie die Daten über Kosten Zeitaufwand TCO, Vergleiche und Erfahrungen mit anderen Projekten suchen. Sie genaues über die Anforderungprofile auf Seiten der Hardware / Software erfahren möchten. ZIELGRUPPE VIII

12 Wie diese Arbeit geschrieben ist 1. Die Community ist ein immer wiederkehrender Begriff in dieser Arbeit. Darum verwende ich das auktorale Wir zur Beschreibung vieler Sachverhalte oder spreche Sie direkt an, um Sie mit ins Boot zu nehmen. 2. Englische Zitate werden von mir nicht übersetzt. Ich gehe davon aus, dass der Leser als Informatiker (Quereinsteiger ausdrücklich eingeschlossen) Englisch als Arbeits- und Publikationssprache beherrscht. Dies trifft auch für aus original englischen Quellen übernommenes Bildmaterial. 3. Die Quellcodedokumentation in den Beispielen erfolgt bewusst ausschließlich in Englisch (siehe 2.). 4. Zum Stil möchte ich sagen, dass ich an manchen Stellen bewusst keine trockene wissenschaftliche Sprache verwende, da ich der festen Überzeugung bin, dass es dem Inhalt weder zuträglich, noch dem Leser dienlich ist, wenn er allzu schwere Kost vorgesetzt bekommt. Ich selbst ziehe englische Fachbücher meist den deutschen Übersetzungen vor (abgesehen von [Freeman et al., 2006]), da sie wesentlich lockerer zu lesen sind. Der Autor entschuldigt sich auch für die synonyme Verwendung deutscher und englischer Fachbegriffe in gleichen Textpassagen. 5. Die Bebilderung stammt aus einer Sammlung unter der Creative Common Licence veröffentlichten Bilderserie eines italienischen Grafikers Coresis auf Open Graphics Voraussetzungen Skills Grundkenntnisse über die objektorientierte Vorgehensweise, Entwurfsmuster, die Programmiersprache Java, einige wenige Grundkenntnisse in SWT (Eclipse.org). Grundkenntnisse über den Softwareentwicklungsprozess. Es sollten Ihnen die wesentlichen Darstellungsweisen der UML geläufig sein. Sie finden am Ende jedes Kapitels und innerhalb der Arbeit konkrete Hinweise auf einschlägige Literatur, die nach den Erfahrungen des Autors für ein echtes Verständnis der Objektorientierung nötig sind: ad fontes. Software Zur Arbeit mit Java bietet sich das Entwicklungstool Eclipse an. Eclipse unterstützt besonders die Arbeit des objektorientierten Entwurfs, Refactoring und zum Testen JUnit, was für diese Arbeit aber keine Voraussetzung ist. Jede beliebige andere Editor, der diese Prinzipien unterstützt ist prinzipiell geeignet. Grundsätzlich können sie die hier beschriebenen Prinzipien mit jedem Texteditor in Verbindung mit einem Javacompiler umsetzen. Wenn Sie in einer anderen objektorientierten Sprache arbeiten, müssen Sie jedoch beachten, dass das letzte Kapitel nicht ohne weiteres ohne großen Aufwand in anderen Sprachen implementiert werden kann, da es die Implementierung eines Musters aus dem JFace Framework verwendet. VORRAUSSETZUNGEN IX

13 Die UML getriebene Entwicklung setzt ein Werkzeug zur Objektmodellierung mit Roundtrip Engineering voraus. Hier ist neben Rational Rose natürlich Together und Poseidon zu nennen ohne dabei einen Anspruch auf Vollständigkeit zu haben. Es müssen nicht alle Generierungsfunktionen (z.b. für Sequenzdiagramme) unterstützt werden, wenngleich es natürlich nicht hinderlich ist. Die Generierung von Code aus Klassendiagrammen und umgekehrt reicht völlig aus. VORRAUSSETZUNGEN X

14 Teil I Plattformunabhängig Welche Komponenten ihrer Software müssen wirklich plattformunabhängig sein? Das Wissen wird immer mehr, und Verstand und Vernunft bleiben immer dieselben. Goethe Ich habe diesen Teil vorangestellt, da es - jedenfalls noch zum gegenwärtigen Zeitpunkt - eine entscheidende Rolle für die schnelle Entwicklung wartbarer und plattformunabhängiger Software spielt, welche Codebasis oder auch Klassensammlung zur Verfügung steht. Eine Festlegung hat weitreichende Konsequenzen für eine spätere Wartung und Erweiterung Ihrer Software, da sie sich in meisten Fällen von einem Hersteller abhängig machen. Begriffsdefinitionen Plattformunabhängigkeit meint in dieser Arbeit immer die Unabhängigkeit sowohl von einer Rechnerarchitektur, als auch dem Betriebssystem. Wir be- 1

15 schränken uns dabei auf die drei gängigsten Betriebssystemplattformen Windows, GNU/Linux und Mac OSX als auch die gängigsten Rechnerarchitekturen Intel/x86 (32 und 64 bit) sowie PowerPC. Als Codebasis definieren wir diejenige Menge an standardisierten abstrakten Schnittstellen und implementierten Komponenten, die dem Programmierer für eine spezielle Programmiersprache zur Verfügung stehen. Im weiteren Sinne kann sie auch als Framework bezeichnet werden. Die deutsche Wikipedia bezeichnet mit Klassenframework wohl am besten das, was ich mit dem Wort Codebasis verstanden wissen möchte: Class Frameworks fassen Klassen und Methoden zusammen, die Unterstützung auf einer bestimmten Abstraktionsebene für ein breites Anwendungsfeld bieten. Dies kann sich dann, wie im nächsten Kapitel auf die Programmiersprache an sich und wie im übernächsten Kapitel auf die Konstruktion grafischer Oberflächen erstrecken. Hinzu kommt, dass - meist bei quelloffenen Implementierungen - mehrere Anbieter die Codebasis um Klassensammlungen erweitern. Hybrid ist im historischen Gebrauch eine Programmiersprache, wenn Sie sowohl low level (z.b. betriebssystemsnahe) als auch high level Formen der Programmierung (z.b. Objektorientierung) in ein und demselben Codestück direkt unterstützt. Die Hybridität moderner Implementierungen ist durch eine Zwischenschicht abgesichert: Sie bieten Erweiterungen mit Schnittstellen nach unten, um ein Maximum an Betriebssicherheit zu gewährleisten. Die Modularität nimmt zu, der direkte, ungeschützte Zugriff auf betriebssystemnahen Code verschwindet zusehends. Eine Community ist in der Programmierszene eine virtuelle Gemeinschaft, die über das Internet, Foren, Newsgroups und listen Kontakt pflegt, Quellcode und Dokumentation für die Verwendung einer Programmiersprache, eines Werkzeugs oder eines Betriebssystems gegenseitig zur Verfügung stellt, diskutiert und entwickelt. Akteure bilden auf der einen Seite die Entwicklergemeinde (developers), die zur Community zählt, und die ein Hersteller an sich binden möchte, in dem er seine Codequellen unter einer freien Lizenz zur Verfügung stellt. Aber auch die beteiligten Benutzer (users), Firmen und Standardisierungsgremien können aktiv in diesen Prozess eingebunden sein. Open Source wird oft mit frei verfügbarer Software gleichgesetzt. Ein Blick auf die Webseite der OSI (Open Source Initiative ) zeigt, wie komplex der Sachverhalt in Wirklichkeit ist. Wenn im weiteren von Open Source die Rede ist, so bezieht sich der Autor dabei auf Lizenzen, welche kompatibel zu den Richtlinien der OSI sind. Dabei muss eine OSI Lizenz im wesentlichen folgendes erfüllen: Die Veränderung und die Weiterverwendung des Quellcodes muss gestattet sein. Freie Verwendung und Weitergabe der Lizenz. Die Verwendung und Weitergabe als ausführbare Datei muss erlaubt sein. Keine Restriktionen gegen oder Ausschluss von Benutzergruppen. In dieser Arbeit wird Open Source Software synonym zu quelloffener Software oder freier Software verwendet. Einen Vergleich der wichtigsten Lizenzformen findet der Leser problemlos mit Hilfe eine Suchmaschine im Internet mit Hilfe des Stickworts Opensource Lizenzen. 2

16 Als Programmierparadigma bezeichne ich - in Anlehnung an Thomas S. Kuhn s Pradigmenbegriff ([Kuhn, 1962][Pajares, 1998]) - die in der Informatik herrschende einheitliche Überzeugung über die Anwendung von Softwaretechnik Methoden auf eine Problembeschreibung. Solche Methoden sind grundsätzlich unabhängig von einer Programmiersprache. Die Fachlogik eines Programms kann zum einen die wenige Zeilen Code umfassende konkrete Lösung innerhalb einer Methode sein, als auch die gesamte Logik (im Sinne eines Model) des Programms umfassen. Wenn hier von Fachlogik die Rede ist, bezieht der Autor sich immer auf die wohl abgetrennten, logischen Module eines Programms, die ohne eine Anbindung an grafische Oberflächen oder betriebssystemnahe Komponenten entwickelt und getestet werden können. Eine GUI (Graphical User Interface) ist eine grafische Benutzeroberfläche, besser Benutzerschnittstelle. Sie ist die Schnittstelle zwischen Mensch und Maschine. Synonyme dafür sind: UI (User Interface), grafische Oberfläche und View. 3

17 1. Kapitel 1 Programmiersprachen The art of programming is the art of organizing complexity. Edsger W. Dijkstra 1 Die Rolle der Codebasis Im Mittelpunkt unserer Betrachtungen steht die schnelle und plattformunabhängige Entwicklung grafischer Benutzeroberflächen. Der Autor möchte Ihre Aufmerksamkeit jedoch zuvor auf Programmiersprachen und ihre Eignung lenken, Schnittstellen- und Klassensammlungen anzubieten, welche für das Programmieren im Großen vorausgesetzt werden. Für die plattformunabhängige Entwicklung gibt es rein theoretisch eine Vielzahl von Möglichkeiten. Von C, C++, C# bis hin zu Java und sogar Skriptsprachen, wie Perl, Python und Ruby werden zur Erstellung von Applikationen mit Benutzeroberflächen verwendet. Die Entscheidung für oder gegen eine Programmiersprache ist zwar für die Implementierung einer plattformunabhängigen Fachlogik eher unwichtig, aber derzeit noch von entscheidender Bedeutung, wenn Sie die produzierten Ergebnisse Ihrer Fachlogik auch einem oder mehreren Benutzern präsentieren möchten. Damit geht immer ein nicht unerheblicher Entwicklungsaufwand für die Erstellung der GUI einher. Auch wenn Sie Ihr System zu einem späteren Zeitpunkt an die Umwelt anschließen wollen, sich die Datenschnittstelle ändert, sie gar netzwerktransparent darauf zugreifen oder ihre Anwendung verteilt betreiben möchten sind sie derzeit auf die für die jeweilige Programmiersprache, die Plattform und/oder den Hersteller angebotene Lösung angewiesen. Eine weit verbreitete ausgereifte Programmiersprache wie C++ zu verwenden scheint auf den ersten Blick eine gute Idee, um plattformunabhängige Anwendungen zu schreiben. Die Codebasis ist reif, frei, kann kommerziell PROGRAMMIERSPRACHEN 4

18 1.1 DIE ROLLE DER CODEBASIS genutzt werden und läuft auf praktisch allen verfügbaren Plattformen. Informationen gibt es genügend, denn die Entwicklergemeinde ist groß. Programmiermethodiken, wie die Objektorientierung werden unterstützt. So bietet C++ theoretisch alles, was man benötigt, um das hehre Ziel einer großen plattformunabhängigen Applikation umzusetzen. Da man aber nicht alles von Grund auf selbst neu entwickeln kann (Time to Market), gelangt man auf der Suche nach geeigneten Bausteinen schnell an eine Grenze. Wenn die Schnittstellen einer gut funktionierenden Fachlogik einer GUI ausgestattet werden soll, gibt es eine Fülle von Insellösungen mit unterschiedlichsten Ansätzen, die im Grunde immer eines gemeinsam haben: die Realisierung ist mit erheblichem Aufwand verbunden. Dies wird besonders deutlich, wenn die einfachen vertikalen Prototypen (die einzelnen Applikationsteile) zu einem großen horizontalen Ganzen zusammengebunden werden sollen. C++ bietet durch die Verwendung verschiedener Programmierparadigmen eine große Angriffsfläche für Fehler und wartungsintensiven Code. Die Plattformabhängigkeit, aber auch die Anbindung der logischen Programmmodule nach oben hat dort ihre Grenzen, wo diese Fähigkeiten in einer verwendeten Codebasis nicht vorhanden oder nur schwer zugänglich ist. Diese Fähigkeiten können extern in Form von Know How über den Entwurf oder intern in Form von Klassensammlungen verfügbar sein. Aufgrund der natürlich begrenzten Ressourcen jedes realen Softwareprojektes (Know How, Geld, Zeit, Manpower) sind Versuche, diese Fähigkeiten mit Projektbeginn erst zu erwerben mit einem hohen Risiko gekoppelt. Schwer kalkulierbare Faktoren können auch inkompatible proprietäre Standards oder die Komplexität der Aufgabe sein, den Quellcode auf zusätzliche Plattformen anzupassen und diese Veränderungen zu warten. C++ ist ein schönes Beispiel für das Vorhandensein gut gepflegter proprietärer Codebasen, die jedoch meist untereinander inkompatibel sind, oder softwaretechnisch so unterschiedlicher Natur, dass Anpassung und Adaption an die konkreten Bedingungen des Projektes einen erheblichen Aufwand mit sich bringen. Wenn es an die Entwicklung grafischer Oberflächen geht, stehen schnell proprietäre Klassenbibliotheken, wie z.b. die Microsoft Foundation Classes (MFC) und weitgehend standardisierte, wie z.b. die Standard Template Library (STL) miteindander im Konflikt. Ohne aufwendige und ressourcenfressende Adaption sind beide Systeme nicht ohne weiteres miteinander zu verknüpfen. Die plattformunabhängige Entwicklung komplexerer Systeme mit C++ ist deshalb oft aufwendig, teuer, stark herstellerabhängig und wartungsintensiv (siehe auch Abbildung 1 auf Seite 6). Eine moderne Codebasis muss standardisierte Schnittstellen definieren welche die reibungslose Integration auch höherwertiger Anwendungskomponenten (1) sicher stellt. Man muss sich dabei auf gut gepflegte, quelloffene Standards stützen können, deren Anforderungen möglichst von herstellerübergreifenden Gremien überwacht werden. Weil Sie erhebliches Erfahrungswissen in Ihren Klassenbibliotheken speichern, können Sie die Arbeit des Entwickelns komplexer Anwendungen erheblich erleichtern und diese robuster machen. Dieses Wissen ist jedoch für den Ungeübten normalerweise nicht (1) Damit sind z.b. Speicherfunktionen, Listenfunktionalität, Suchfunktionen, Datenbankanbindungen gemeint, um nur einige zu nennen. PROGRAMMIERSPRACHEN 5

19 1.2 KOMPLEXITÄT Abbildung 1: Entwickler weltweit und ihre bevorzugten Programmiersprachen. Quelle: [namics ag CH, 2002] leicht zugänglich, da es sich um softwaretechnisches Expertenwissen handelt, dessen Zugang man sich erst erarbeiten muss. Grady Booch zitiert zu diesem Sachverhalt einen anderen bekannten Software Designer (L. Peters in [Booch, 1994, Seite 3]): The world is only sparsely populated with geniuses. There is no reason to believe that the software engineering community has an inordinately large proportion of them Software in Form einer umfangreichen und gut gewarteten Codebasis kann diese Lücke schließen. Erfahrungswissen in wiederverwendbarer und wissenschaftlich fundierter Weise zu speichern und den Entwicklern zugänglich zu machen hat in den Augen des Autors keinesfalls an seiner Aktualität eingebüßt. Die Gründe dafür werden wir im nächsten Abschnitt erläutern. 2 Komplexität Was sind die Triebfedern der Softwareentwicklung? Die Programmiersprachen sind es sicher nicht, sie spiegeln nur den aktuellen Trend in der Softwaretechnik wieder. Auf der Suche nach übergeordneten Prinzipien und Methoden im Softwarelebenszyklus spielen Sie keine entscheidende Rolle. Sie sind lediglich die Werkzeuge zur Abbildung abstrakterer Prinzipien. Die technische Weiterentwicklung und die Forderung, reale Probleme auf immer neue Schichten der Abstraktion zu abzubilden führt automatisch zu einem Komplexitätszuwachs. Ein Professor des Autors machte dies anschaulich klar am Beispiel der vier großen Krisen der Informatik, die seit den 40er Jahren in immer neue Paradigmen für die Lösung softwaretechnischer Probleme mündeten ([Quibeldey-Cirkel, 1994], [Kuhn, 1962]). Der Komplexität ist eine wesentliche Größe, die die Entwicklung der Softwaretechnik in immer abstraktere Bereiche vorantreibt. Der Faktor Zeit kommt PROGRAMMIERSPRACHEN 6

20 1.2 KOMPLEXITÄT Abbildung 2: Levels einer standardisierten Codebasis. Für die hybriden Eigenschaften von Java und C# muss hinzugefügt werden, das diese Fähigkeiten nicht mehr sprachimmanent sind, sondern durch standardisierte Schnittstellen nach unten angeboten werden. hinzu und die Anforderung fehlerarme, wiederverwendbare und erweiterbare Software zu schreiben. Krisen bilden darin den Motor für die jeweils nächsten Stufen. Die aktuelle Komplexitätsstufe der Informatik erleben wir seit Jahren auf verschiedenen Ebenen, welche die Anwendungsentwicklung direkt oder indirekt beeinflusst: Einen Boom an Betriebssystemen, die auf Grund einer quelloffenen Basis weltweite Strömungen aus Forschung und Praxis in rasendem Tempo integrieren und einem breiten Publikum verfügbar machen (Linux, FreeBSD, OS X). Die freie Verfügbarkeit hochwertiger Klassensammlungen zur Umsetzung auch abstrakterer softwaretechnischer Probleme (Java, C#). Die Steigerung der Leistungsfähigkeit der Rechner, welche die hohen Level an Abstraktionen in Software salonfähig macht oder per Hardware direkt unterstützt (Virtualisierung bei Programmiersprachen; Komplexe objektorientierte Systeme, wie Swing). Reale Probleme mit Software zu lösen und diese in Code abzubilden setzt voraus, eine bestimmtes Konzept beim Entwurf von Software anzuwenden. Das Wissen über den guten Entwurf liegt in einer nicht codierten Form vor. Die Objektorientierung war ein erster wichtiger Schritt zur Bewältigung der Informatikrise der 70er Jahre, dem Wechsel zwischen der reinen Programmierkunst und dem Software-Engineering [F.L.Bauer 1968]. In dieser Zeit entstanden Sprachen, wie Smalltalk [Alan C. Kay], das vollkommen auf dem Paradigma der Objektorientierung aufbaut. In den allermeisten neueren Entwürfen von Programmiersprachen (Java, C#) werden diese Techniken intensiv eingesetzt. Selbst keine der großen Skriptsprachen wie Perl, Python, oder Exoten wie Ruby können es sich leisten, ohne entsprechende Erweiterungen zu aufzuwarten. PROGRAMMIERSPRACHEN 7

21 1.2 KOMPLEXITÄT Abbildung 3: Komplexitätszuwachs von Software in Bezug auf ihr Potential, reale Probleme abzubilden. K1 bis K4 bezeichnen die 4 Krisen der Informatik nach einer Vorlesung von [Quibeldey-Cirkel, 1994]. Dadurch wird die Auswahl einer Programmiersprache zur Lösung eines konkreten Problems in Zukunft höchstwahrscheinlich immer nebensächlicher und die Beschäftigung mit gespeichertem Wissen in Form von Softwarebausteinen und standardisierten Komponenten immer wichtiger. Dies ist jedoch nur dann der Fall und bringt keine erneute Steigerung der Komplexität mit sich, wenn diese Sprachen über gemeinsame Programmierparadigmen verbunden sind. Die Funktionsweise und innere Mechanismen dieser Paradigmen zu verstehen setzt zusätzliche Skills beim Programmierer voraus, deren Qualifikation er sich erst erwerben muss. Er kann sonst keinen Nutzen aus diesen Softwarebausteinen ziehen oder deren universellen Charakter für andere Programmiersprachen nutzbar machen. Die Grenzen zwischen dem Lager der hybriden Sprachen wie C++ und den paradigmenorientierten Sprachen, wie z.b. Smalltalk haben sich bereits zusehends aufgelöst. Moderne, zum Teil quelloffene Implementierungen (siehe Abschnitt 3 auf Seite 9) bieten beides, die Unterstützung verschiedener Programmierparadigmen und die modularisierte Einbindung höher- und systemnaher Komponenten. Dies wird über die Bereitstellung von Schnittstellen nach unten und oben realisiert. Beispiele dafür sind in Java zu finden mit Schnittstellen nach unten zur Programmiersprache C mit JNI (Java Native Interface) und nach oben zu Komponenten zur Anwendungsrealisierung mit EJB (Enterprise Java Beans). Für die schnelle Anwendungsentwicklung ist entscheidend, dass die Umsetzung eines Programmierparadigmas elegant und einfach implementiert werden kann. Die Bausteine für gezielte Anforderungen sollten in Form von fertigem Code - einem Framework - vorliegen und nicht erst angefertigt werden müssen. Dies ist zumindest das Fernziel. Insofern ist die Auswahl der Programmiersprache und die mit ihr verheiratete Klassensammlung eine wichtige strategische Entscheidung. Sie ist immer auch ein Kompromiss im Rahmen der vorhanden Skills an Wissen, Erfahrung und Lernbereitschaft auf Seiten des Teams und den Anforderungen Zeit, Geld und Manpower auf Seiten PROGRAMMIERSPRACHEN 8

22 1.3 VIRTUALISIERTE CODEPLATTFORMEN des Projektes. 3 Virtualisierte Codeplattformen Es klaffen immer noch große Lücken zwischen den Möglichkeiten einer Programmiersprache und der Fähigkeit der Community oder eines Herstellers von Entwicklungswerkzeugen, standardisierte Schnittstellen für abstraktere Probleme anzubieten, die über Plattformgrenzen hinweg funktionieren. Diese Lücke wird sich mit der Zeit schließen, denn der Transfer von Fachwissen in die Community geht in rasend schnellem Tempo vor sich. Firmen wie IBM mit Eclipse, SUN mit der Java Platform 5, Microsoft mit C# und.net und renommierte Institute wie das MIT und Projekten wie XEN zeigen, in welche Richtung der Trend führt: weg von rein proprietären Standards hin zu offenen und wohlorganisierten Prozessen der Anwendungsentwicklung. Als Triebfeder für die Softwareentwicklung haben wir die Komplexität der Anwendungsentwicklung identifiziert. Um dieser gerecht zu werden, stützen sich moderne Implementierungen von Programmiersprachen wie Java und C# deswegen auf die Beschreibung von Standards, die herstellerübergreifend diskutiert und unter mehr oder weniger restriktiven Lizenzen quelloffen zur freien Verfügung gestellt werden. Den Prozess der Standardisierung pflegt man in Gremien wie z.b. der ECMA, dem W3C, OASIS oder der OMG (siehe Abschnitt 5 auf Seite 14 auf Seite 14). Darüber hinaus tragen Hersteller und Community der Notwendigkeit der Verzahnung von Programmiersprache und höherwertigen Komponenten Rechnung, in dem Sie entsprechend standardisierte und gepflegte Schnittstellen zur Verfügung stellen. Alle modernen Implementierungen unterstützen das objektorientierte Programmieparadigma und bieten auf Seiten der Komponenten hochwertige Musterlösungen für alltäglicher Probleme an. Quelloffenheit oder zumindest freie Verwendungsmöglichkeit fördern die rasche Verbreitung und Weiterentwicklung von Strategien für die Lösung komplexerer Aufgaben. Die Freiheit in der Verwendung des Quellcodes oder der Klassensammlungen drückt sich dabei in Lizenzierungsformen aus. Völlige Freiheit bei gleichzeitigem Verbot der Nutzung für kommerzielle Anwendungen bietet die GPL (General Public Licence). Unter der Kontrolle eines Herstellers, aber in der Verwendung für die Nutzung in freien und kommerziellen Anwendungen sieht sich sie Lizenz für die Programmiersprache Java. Die Nutzung in kommerziellen und freien Anwendungen ermöglichen dagegen die Lizenzen der Apache Foundation, BSD-artige Lizenzen, die CPL (Common Public Licence) des Eclipse Projektes oder die LGPL (Lesser General Public Licence). Der Autor hat sich zwar bei der Auswahl der Programmiersprachen für diese Arbeit festgelegt. Er ist aber nicht der Überzeugung, dass es die Programmiersprache ist, welche über den guten Entwurf entscheidet, sondern die PROGRAMMIERSPRACHEN 9

23 1.3 VIRTUALISIERTE CODEPLATTFORMEN Möglichkeit, das objektorientierte Paradigma konsequent zu nutzen. Es existieren zudem Randbedingungen, wie die freie Wahl der Rechnerarchitektur und die generelle Unabhängigkeit von Betriebssystemplattformen. Derzeit gibt es im Rahmen dieser Bedingungen nur eine sinnvolle Lösung um mit vertretbarem Aufwand grafische Oberflächen zu realisieren: Java und die mit ihm vergesellschaftete Klassenbibliotheken. Das man dabei keineswegs auf einen Hersteller angewiesen ist, werden wir noch zeigen. 3.1 Virtualisierung Eine Technologie, um die Ausführung von Programmen auf verschiedenen Rechnerarchitekturen zu ermöglichen ist die Einführung einer Abstraktionsschicht zwischen der maschinennahen Umgebung und dem eigentlichen Programmcode: die virtuellen Maschine. Virtualisierung bedeutet hier: eine abstrakte Umgebung für die Ausführung von Code. Besonders bei netzwerkbasierten Anwendungen, die verteilt auf verschiedenen Architekturen lauffähig und an unterschiedlichen Orten platziert sind, spielt dieses Feature eine entscheidende Rolle. Wenn die virtuelle Maschine auf verschiedenen Plattformen verfügbar ist, kann ein Code dort problemlos ausgeführt werden. Bei der Anforderung an plattformunabhängige Software ist insbesondere darauf zu achten, ob eine dynamische Anpassung auf verschiedene Plattformen zur Laufzeit erforderlich ist. Man sollte deshalb genau festlegen, welche Komponenten des Programms entfernt auf anderen Systemen und welche lokal ausgeführt werden müssen. Wir werden im nächsten Kapitel über Klassensammlungen für grafische Benutzerschnittstellen darauf zurückkommen, denn man muss nicht immer alle Teile eines Frameworks in einer virtualisierten Umgebung ansiedeln: SWT kontra Swing. Zwei Techniken der Virtualisierung stehen im hier betrachteten Kontext zur Verfügung: die Verwendung eines Interpreters für den als plattformneutrale Zwischenschicht vorhandenen Bytecode und die dynamische Übersetzung desselben zur Laufzeit (JIT - Just in Time). JIT Compiler sorgen jedoch dafür, dass der erstmalige Programmstart durch die Übersetzung etwas verzögert wird. Dynamische Optimierungsverfahren können dieses Verhalten zusätzlich verbessern (AOT - Ahead of Time Compiler). Es ist in Zukunft davon auszugehen, dass die Nachteile der Virtualisierung, wie der Ressourcenverbrauch und die Startverzögerung durch weitere Optimierungen und kommende Hardwareunterstützung immer mehr in den Hintergrund treten. Zwei auf diese Techniken aufsetzende Programmiersprachen möchte der Autors in Bezug auf ihre Eignung für die plattformübergreifende Anwendungsprogrammierung mit grafischen Benutzeroberflächen kurz darstellen. Im nächsten Kapitel werden wir dies auf die Programmierung von plattformübergreifenden grafischen Oberflächen erweitern. Es ist zur Zeit noch nötig auf die Differenzen bezüglich der Plattformunabhängigkeit hinzuweisen, da hier erhebliche Unterschiede bestehen. Dies betrifft sowohl Rechnerarchitekturen, als auch Betriebssysteme. PROGRAMMIERSPRACHEN 10

24 1.3 VIRTUALISIERTE CODEPLATTFORMEN Abbildung 4: Vergleich zwischen J2EE und.net. Quelle: [namics ag CH, 2002] 3.2 Java Die Plattformunabhängigkeit stand bei der Entwicklung von Java im Vordergrund. Der SUN Slogan Write once, run anywhere bedeutet, dass kompilierte Javaprogramme auf jeder JVM lauffähig sind, völlig unabhängig von der darunter liegenden Hardware. Die API ist entsprechend ausgelegt und bietet dem Programmierer eine vom Betriebssystem unabhängige und eindeutige Schnittstelle. Durch die Verfügbarkeit der Java Virtual Machine auf praktisch allen gängigen Plattformen sind Javaprogramme tatsächlich auf allen diesen Plattformen lauffähig. Besonderes Augenmerk wurde auf das Thema Betriebssicherheit gelegt. Dies heißt, dass es keine ungewollten Zugriffe auf Speicherbereiche geben kann die zum Absturz des Betriebssystems führen. Java bietet alle nötigen Konstrukte zur objektorientierten Programmentwicklung, ist jedoch keine vollständig objektorientierte Sprache, da Ihre Grunddatentypen und Literale keine Objekte sind. Java unterstützt auch keine Mehrfachvererbung. Dafür unterscheidet sie explizit Schnittstelle (interface) und Klasse (class). Mehrfachverbung kann durch Schnittstellenvererbung ersetzt werden. Bibliotheken für die Erzeugung grafischer Oberflächen gibt es gleich mehrere, nicht nur vom Hersteller Sun, sondern auch von anderen Firmen, z.b. von IBM. Die Kompilierung von Java Programmen erzeugt Bytecode für die interpretierende JVM. Die Laufzeitumgebung (JRE - Java Runtime Environment) lädt den Bytecode und kompiliert ihn mit Hilfe eines JIT Kompilers. Die Verwendung von JVM s oder Java Compilern anderer Hersteller oder aus der Open Source Gemeinde ist möglich, dies hat der Autor aber nicht geprüft und kann daher keine Aussage dazu treffen. J2EE (Java 2 Plattform Enterprise Edition), die eigentliche Kernkomponente seit 2001, bietet darüber hinaus eine Standardarchitektur für komponentenbasierte Anwendungen. Damit können hersteller- und plattformübergreifend ver- PROGRAMMIERSPRACHEN 11

25 1.3 VIRTUALISIERTE CODEPLATTFORMEN teilte, mehrschichtige Anwendungen erstellt werden. Für professionelle, unternehmensweit eingebundene Applikationen und deren Entwicklung, bietet Sun von der Entwicklungsumgebung bis zum Serverbetriebssystem alle notwendigen Werkzeuge und Software - natürlich auch zu angemessenen Preisen. Sun legt großen Wert auf die Beteiligung der Community und pflegt innerhalb des sogenannten Java Community Process alle Referenzimplementierungen. Dieser Prozess ist seit jeher lebhaften Diskussionen unterworfen, da Sun die letztendliche Kontrolle über seine Produkte nicht ganz an die Community abgeben möchte. Die Sun Java Lizenz ist keine Open Source Lizenz. Der Quellcode von Java an sich ist damit nicht quelloffen, und die Verwendung und Verbreitung unterliegen einer kommerziellen Lizenz. Diese ist jedoch für alle Beteiligten insofern frei, als weder der Anwender noch der Entwickler für die Laufzeitumgebung zu Kasse gebeten werden. Lizenzkosten entstehen keine, wenn der Quellcode unverändert zur Entwicklung von Software verwendet wird und vom Endanwender über den offiziellen Vertriebsweg bezogen wird (auf Medien direkt von SUN oder über deren Webseite). Die Java Virtual Machine darf deshalb nicht mit vertrieben werden, sondern muss vom Kunden separat heruntergeladen werden (siehe Deutsche Übersetzung der Linzenzvereinbarung Diese Produkte dürfen dann auch kommerziell weiter vertreiben werden. Durch die Offenlegung der Standards existieren mittlerweile eine Fülle von Kernkomponenten der Java Technologie, so z.b. JVM s von anderen Herstellern oder als Open Source. Hinzuzufügen ist: Java wurde und wird von Microsoft nicht offiziell unterstützt. Auch wenn namhafte Hersteller wie IBM oder Apple sich in aktiv am Java Community Process beteiligen, und Sun selbst für die Microsoft Plattform alle entsprechenden Komponenten anbietet. 3.3 C# - Mono C# ist Teil des Microsoft.NET (sprich Dot NET ) Frameworks und eine vollkommene Neuentwicklung (2001). Sie ist nur eine der Programmiersprachen, welche die Ausführungsschicht von.net, die Common Language Runtime (CLR) bedienen kann. Die CLR ist die abstrakte Zwischenschicht, welche auf Java Seite der JVM entspricht, auch wenn unterschiedliche Techniken zum Einsatz kommen. Alle.NET Sprachen sind einheitlich typisiert (Common Type System - CTS) und verwenden dafür ein Set von Basisklassen (Base Classes). CTS unterstützt alle für die objektorientierte Programmierung wichtigen Objekttypen (Interfaces, Delegates, Referenzen und Werttypen). Die CLR lädt den dem Standard der Common Language Infrastructure (CLI) entsprechenden Bytecode und bereitet Ihn für die Übersetzung mit einem Compiler (z.b. JIT) vor. Im sogenannten managed Code laufen alle Programme unter der Aufsicht der CLR. Zugriffe auf betriebssystemnahe Bibliotheken (DLL s) sind in diesem Modus nicht möglich, was eine hohe Speichersicherheit garantiert. Im Unterschied zu Java wird der Bytecode nicht interpretiert, sondern direkt kompiliert und ausgeführt, was die Komplexität der Verarbeitung reduziert. PROGRAMMIERSPRACHEN 12

26 1.4 FAZIT Benutzeroberflächen werden mit den sogenannten Window Forms erstellt. Eine Linux Implementierung der kompletten.net Basisklassen und des WindowForms Toolkit in der Version 1.0 ist mit MONO in Vorbereitung und zu einem Großteil abgeschlossen. Für den produktiven Einsatz ist die Linux Implementierung von Windows Forms jedoch noch nicht geeignet. Erfolgversprechender für die Entwicklung grafischer Oberflächen scheint die Bindung von C# an das GimpToolkit GTK+ (siehe Kapitel 2) zu sein. Plattformunabhängigkeit unter C# ist deshalb zur Zeit nicht sichergestellt. Die Kontrolle über die Common Language Infrastructure wurde der ECMA übergeben (siehe Quellen am Ende dieses Kapitels). Mit diesem Schritt unterstellt Microsoft zum ersten Mal eine Kernkomponente seiner Produkte einem anerkannten Standardisierungsgremium. Dies ist besonders für die Implementierung von plattformübergreifenden CLR s wichtig. Generell kann jedoch jedwede Art von Bytecode auf beliebigen Systemen kompiliert werden, wenn sie die Spezifikation der CLI repräsentieren. Der Schwerpunkt bei der Entwicklung von C# wurde auf eine sehr gute Anbindung an höherwertige Komponenten (.NET Components, Webservices, COM+) und eine hervorragende Integration in andere Microsoftprodukte geachtet. Es bleibt abzuwarten, was die Zukunft der Common Language Infrastructure bringt und welche Plattformen sie unterstützen werden. Bis dato bringt die Programmierung mit C# eine enge Bindung an ein Softwarehaus und ein Betriebssystem mit sich: Microsoft und Windows. Wenn die bisherige Firmenpolitik fortgesetzt wird, ist nicht davon auszugehen, dass der Hersteller selbst plattformübergreifende CLR s anbieten wird. 4 Fazit Bei der Auswahl einer Programmiersprache für ein Projekt spielt deren Lizenzierung und das Umfeld der verfügbaren Klassensammlungen eine große Rolle. Die Java Plattform bietet derzeit die einzige Umgebung, die nahtloses Entwickeln plattformübergreifender Software ermöglicht. Sie bietet eine solide Codebasis, eine durchgängige architekturneutrale API und die Unterstützung verschiedener Oberflächenframeworks. Mit J2EE besitzt die Java Plattform der Firma Sun eine standardisierte Architektur für die Erstellung von Komponenten und Diensten für den weiteren Ausbau. Der Autor verwendet deshalb die bei Sun vertriebene aktuelle Java Umgebung in der Version 5.0. Als einzigen Nachteil könnte man die propietäre Lizenz ansehen, die jedoch durch die freie Verfügbarkeit ausgeglichen wird. C# ist für eine wirklich plattformunabhängige Entwicklung von grafischen Oberflächen zur Zeit uninteressant. Dies könnte sich aber in Zukunft ändern, wenn CLR s anderer Hersteller vorliegen. Denn C# ist vom Lizenzmodell, seiner ECMA standardisierten Sprache und der schlankeren Virtualisierungstechnik her gegenüber Java der modernere Kandidat. PROGRAMMIERSPRACHEN 13

27 1.5 QUELLEN UND WEITERFÜHRENDE HINWEISE Von Seiten der Architektur und Funktionsumfang sind die übergeordneten Platformen.NET und Sun ONE praktisch identisch. Mit.NET bindet man sich jedoch klar an Produkte der Windows Familie und die zur Verfügung stehenden (Intel)Hardwarearchitekturen. Deshalb ist derzeit die Entwicklung plattformübergreifender Anwendungen mit grafischen Oberflächen ausser im Bereich von Browserbasierten Lösungen nicht sinnvoll. Der Einsatz von C++ ist nur dann ratsam, wenn gut gepflegte Klassenframeworks verwendet werden und entsprechende C++ Programmierskills im Team vorhanden sind. 5 Quellen und weiterführende Hinweise Auf Developers Slashdot gibt Bjarne Stoustrup am eine Fragestunde mit über 550 Fragen von Entwicklern, in dem er u.a. die Rolle der Objektorierung für C++ darstellt. Es ist nicht schwer im Nachhinein eine Programmiersprache mit pradigmenorientierten Bausteinen auszurüsten. Aber das Beispiel C++ zeigt, das nicht einmal unabhängige Bibliotheken, wie die Standard Template Library (STL) es geschafft haben, namhafte Hersteller von Entwicklungsumgebungen zu bewegen, kompatible Schnittstellen für Ihre proprietären Komponenten anzubieten. Bjarne Stoustrups C++ Buch [Stoustrup, 1997] sollte Pflichtlektüre jedes Informatikers werden. Er selbst, der in seinem Buch über C++ diese Probleme schon in den frühen 90er Jahren addressierte, hat immer wieder darauf hingewiesen, dass die konsequente Ausrichtung an Standards, wie der STL dringend nötig wären, um die Anbindung nach draussen zu gewährleiten. Da C++ von der Natur her eine hybride Struktur bietet, also ein hohes Mass an Flexibilität zur Implementierungsweise ermöglicht, ist die Anwendungspraxis jedoch entsprechend heterogen und inkonsistent. Die Idee quelloffener paradigmenorientierter Programmiersprachen, sowie die Idee der Virtualisierung über Bytecode ist keinesfalls eine Erfindung der Neuzeit, sondern geht in die 70er Jahre und weiter zurück. Sie findet in dem aus dieser Zeit stammenden Smalltalk immer noch einen würdigen Vertreter. Smalltalk ist der einzige Vertreter einer Programmiersprache, die das objektorientierte Vorgehensmodell konsequent realisiert. Natürlich kann man damit auch grafische Oberflächen implementieren. Diese sind plattformunabhängig lauffähig, denn Smalltalk ist von vorne herein entsprechend konzipiert worden. Ich möchte Sie an dieser Stelle nur der Vollständigkeit halber erwähnen. Wer Smalltalk ausprobieren oder lernen möchte, erhält mit VisualWorks ein interessantes Programm zum Erstellen von Applikationen. Ecma International - European association for standardizing information and communication systems org/, World Wide Web Consortium Organisation for the Advancement of Structered Information Standards oasis-open.org/, Object Management Group PROGRAMMIERSPRACHEN 14

28 ... sind einige Beispiele für wichtige herstellerübergreifende Standardisierungsgremien im informationstechnischen Bereich. Die Entscheidungsprozesse sind demokratischer Natur (Mitglieder orientiert), die Anforderungserfassung durch Einreichen von Anfragen (Request of Comments) organisiert. Greg Papandopoulos gab im Juni 2004 (damals war er Sun CTO) im ZD- Net ein interessantes Interview zum Thema Komplexität und Zukunft der Datenverarbeitung: Sun Microsystems startet Feldzug gegen die Komplexität Beim Thema.NET stütze ich mich hauptsächlich auf das Buch.NET Framework Essentials, dass 2001 zum ersten Mal erschienen ist und ausführlich die wichtigsten Aspekte des Frameworks beschreibt: [Thai and Lam, 2002] Zum Thema.Net contra J2EE sind zahlreiche Artikel und Arbeiten verfügbar, welche überwiegend zum selben Schluss kommen: Die Plattformen ähneln sich konzeptionell fast wie ein Ei dem anderen, wobei der plattformübergreifende Aspekt und die stärkere Abstraktion der Komponenten bei J2EE überwiegt..net dagegen spielt seinen Vorteil auf den Produkten der Windows Familie voll aus. Der Leser möge sich selbst ein Urteil bilden. Ich stütze mich hier auf eine Studie von 2002: [namics ag CH, 2002], und einer Diplomarbeit an der Züricher Hochschule Winterthur vom Oktober 2004:[Biotti, 2004]. Besonders betriebswirtschaftliche Aspekte zu beiden Konzepten werden dort erörtert. Es gibt neben der Java Virtual Machine von Sun zahlreiche andere Implementierungen der virtuellen Java Maschine. Es würde jedoch den Rahmen dieser Arbeit sprengen, diese im Hinblick auf die Zusammenarbeit mit den später besprochenen grafischen Entwicklungstoolkits zu betrachten. Es ist dem Autor bekannt, dass besonders in der Open Source Szene (Kaffee), aber auch auf kommerzieller Seite einige sehr interessante Alternativen zur SUN JVM verfügbar sind (IBM). PROGRAMMIERSPRACHEN 15

29 2. Kapitel 2 Grafische Entwicklungframeworks Auf der Suche nach dem plattformunabhängigen GUI Framework 1 Auswahl der Kandidaten Bevor wir im nächsten Teil auf die mehr softwaretechnischen Aspekte bei der Erstellung einer konkreten grafischen Benutzerschnittstelle eingehen, möchte der Autor Frameworks vorstellen, mit denen plattformunabhängige und betriebssystemunabängige Entwicklung möglich ist. Diese Liste besitzt keinen Anspruch auf Vollständigkeit. Der Autor hat sich bei der Auswahl von seiner Erfahrung mit der Arbeit diverser grafischer Oberflächenframeworks (von Visual Basic, über die MFC, GTK+ bis hin zu Java AWT/Swing) und seiner Neigung zu offenen Standards und Linux leiten lassen. Darüber hinaus bieten die vorgestellten Klassenbibliotheken ausreichenden Support und Möglichkeiten zur Anbindung höherwertiger Komponenten (z.b. Webservices), Datenbanken und netzwerktransparente Techniken (z.b. RMI - Remote Method Invocation). Für alle existiert ein großes Angebot an freien und kommerziellen Entwicklungswerkzeugen. Der Autor nimmt an dieser Stelle vorweg, dass er sich für das SWT/JFace Framework entscheiden wird. Der bereits informierte Leser kann, wenn er möchte gleich zu Unterabschnitt 1.5 auf Seite 19 springen. 1.1 QT Die Firma Trolltech bietet mit QT kommerzielles, plattformübergreifendes Framework für C++ an. Es ist für die Betriebssysteme Windows, Mac OSX und Linux verfügbar. QT ist in mittlerweile der Version 4 erschienen und bietet neben einem Set von Basisklassen alle für die Erstellung größerer C++ Anwendungsapplikationen notwendigen Module. Der Leser möge sich selbst ein Bild davon machen. Drei wichtige Bedingungen muss man bei der Entwicklung von Applikationen mit QT jedoch beachten: GRAFISCHE ENTWICKLUNGSFRAMEWORKS 16

30 2.1 AUSWAHL DER KANDIDATEN 1. Eine Lizenz für die Entwicklung eines kommerziellen Programms muss VOR Beginn der Entwicklungsarbeiten vorhanden sein 2. Die Lizenzen sind jeweils pro Entwickler zu erwerben 3. Für die Entwicklung von Open Source Anwendungen existiert eine spezielle Open Source Edition Der erste und dritte Punkt sind entscheidend, wenn man die Entwicklung von Open Source Software plant. Unter der QT Open Source Lizenz darf kein Code entwickelt werden, der später für kommerzielle Produkte verwendet werden soll. Diese Einschränkung macht QT nur für reine Open Source Projekte oder solche, welche die Kosten für den Erwerb einer Lizenz von vornherein berücksichtigen sinnvoll. Der Autor selbst hat keine Erfahrungen mit QT und möchte an dieser Stelle deshalb nur auf die Existenz dieses Frameworks hinweisen, da es eine bedeutende Rolle bei der Entwicklung von Open Source Software eingenommen hat (KDE Desktop). Dementsprechend existiert zahlreiche Sekundärliteratur für die GUI Programmierung unter C++ mit QT, wie eine Suche auf Amazon schnell zeigt. Ob sich QT wirklich als Standard für die Entwicklung von grafischen Benutzerschnittstellen in C++ auch außerhalb der Open Source Szene etablieren wird, hängt wohl entscheidend vom zukünftigen Lizenzierungsmodell des QT Frameworks ab. 1.2 GTK+ Eine weitere Alternative aus dem Open Source Umfeld ist das Gimp Toolkit (GTK Unterprojekte des GTK kümmern sich um die Portierung auf verschiedenen Plattformen (Linux, Windows, Mac OSX). Es ist das für den Standard Linux Desktop GNOME verwendete Framework und bietet verschiedene Bindungen an unterschiedliche Programmiersprachen wie C, C++, Java, C#/Mono und einige Skriptsprachen an. Am besten ausgereift sind derzeit die C/C++ Bindungen unter Linux. Beschränkt man sich auf dieses Betriebssystem, so stellt GTK+ eine freie, stabile und zukunftsträchtige Basis dar. GTK+ unterliegt der LGPL gnu.org/copyleft/lesser.html und bietet damit auch die Möglichkeit für die Entwicklung und den Vertrieb kommerzieller Anwendungen. Plattformübergreifendes Entwickeln für größere Applikationen auf verschiedenen Betriebssystemen wird jedoch erheblich durch die Tatsache erschwert, dass die plattformspezifischen Unterprojekte von GTK+ einen sehr unterschiedlichen Status hinsichtlich Stabilität und Reifegrad aufweisen. Die Java, aber besonders die C# Bindungen für GTK+ erfreuen sich zunehmender Beliebtheit. Es handelt sich dabei im wesentlichen um Wrapper- und Adapterklassen, die die Einbindung des GTK+ Frameworks in C# Applikationen erlauben. Die Forcierung der Implementierung von Mono durch Novell könnte in Zukunft eine interessante Möglichkeit bieten, plattformunabhängige Software für das Linux GRAFISCHE ENTWICKLUNGSFRAMEWORKS 17

31 2.1 AUSWAHL DER KANDIDATEN Betriebssystem zu entwickeln, welches per se auf vielen Computerarchitekturen zu Hause ist. Der Autor hat nur geringe Erfahrungen mit dieser Technik sammeln können, hält aber auf Grund der Tatsache, dass einige interessante neue Desktopapplikationen der Linux Community, wie Beagle oder F-Spot auf dieser Bindung basieren GTK+ und MONO für zukunftsträchtige Kandidaten. 1.3 wxwidgets Ein Framework, welches durchaus in die engere Wahl kommen könnte. Ich verweise den Leser auf die ausgezeichnete und umfassende Darstellung für plattformübergreifendes Entwickeln von GUI s mit diesem Framework in [Smart et al., 2005]. wxwidgets ist unter der LGPL copyleft/lesser.html lizenziert und dadurch sowohl für die Entwicklung von Open Source, als auch für kommerzielle Anwendungen geeignet. Es ist C++ basiert und nach kurzer Sicht auf die Codebasis objektorientiert mit vererbungszentrierter Tendenz implementiert. Es existieren zahlreiche Bindungen zu anderen Sprachen wie wxpython, wx.net, wx4j (Java) und viele andere mehr. Leider hat der Autor keine Erfahrung mit diesem Framework, und kann auch über die Qualität der Bindungen keine Aussage treffen. Es eignet sich aber sehr gut zur Portierung älterer MFC basierter Software, um diese für andere Plattformen verfügbar zu machen, da sich die Frameworks von MFC und wxwidgets nach Aussage von [Smart et al., 2005, Apendix K] sehr ähnlich sind. 1.4 Swing Swing wurde zusammen mit der Java2 Plattform 1998 von der Firma SUN vorgestellt. SUN Microsystems Incorporation ist ein seit den 80er Jahren weltweit operierendes IT Unternehmen. Es vertreibt und entwickelt Hardware und Software. Darunter die auf der SPARC Rechnerarchitektur basierende SUN Server, sowie die Programmiersprache Java und das Betriebssystem Solaris. Letzteres basiert vollkommen auf Java. Nach anfänglicher Begeisterung über eine Benutzeroberfläche im Stil Write Once, Run Anywhere, wurde Swing jedoch zu einem Synonym für aufwändige Entwicklung und geringe Performance. Üblicherweise übernimmt der betriebssystemeigene Fenstermanger die Kontrolle über die grafische Darstellung. Swing jedoch führt diese Operationen selbst Pixel für Pixel auf der virtuellen Java Maschine aus und erstellt leicht gewichtige grafische Objekte jedes Mail von Grund auf neu. Es kann die vom Betriebssystem vorgehaltenen schwergewichtigen Objekte nicht nutzten und benötigt daher weitaus mehr Systemressourcen. Ein vergleichbares Programm, dass auf dem nativen Windows Toolkit aufsetzt, ist - ohne besondere Performance Tricks - erheblich flinker. Benutzer möchten häufig im bekannten Look and Feel des Betriebssystems arbeiten. Aus diesem Grunde findet man dieses Framework kaum in Standarddesktopanwendungen, von im industriellen Umfeld gefertigten Oberflächen einmal abgesehen (z.b. SAP). Betriebssystem abhängige Design Fragen spielen hier offensichtlich eine geringere Rolle. Dies könnte sich jedoch GRAFISCHE ENTWICKLUNGSFRAMEWORKS 18

32 2.1 AUSWAHL DER KANDIDATEN angesichts der Forderung nach gesteigerter Mitarbeiterproduktivität und geringeren Einarbeitungszeiten ändern. Swing verwendet die von Java zur Verfügung gestellte automatische Speicherbereinigung AGC (Automatic Garbage Collection). Die Vorteile und Nachteile von AGC sind hinreichend bekannt (siehe Abschnitt 3 auf Seite 33). Im Umfeld komplexer GUI Anwendungssoftware, die die ständige Allokation und Deallokation von großen Applikationsobjekten mit sich bringt, kann dies zu seltsamen Verhalten führen. Die Unvorhersehbarkeit des automatischen Speichermanagements, plattform- und systemabhängige Performance Unterschiede können zu unerwünschten Nebeneffekten führen und den Prozessor stark belasten ([Scarpino et al., 2005]). 1.5 SWT/JFace Das Standard Widget Toolkit (SWT) wurde von IBM als Alternative zu Swing ( Firma Sun) entwickelt. SWT bietet sowohl eine Steigerung der Performance der Benutzerschnittstelle, als auch die Integration in das dem Betriebssystem eigene look and feel. Im Gegensatz zu Swing, benutzt SWT die betriebssystemeigenen Ressourcen zur Darstellung seiner Grafik. Bewerkstelligt wird dies durch die Verwendung des Java Native Interface (JNI). Java sieht (ähnlich wie C#) die Einbindung von anderen Programmiersprachen vor: JNI ist eine Anwendung dieser Möglichkeit und die Basis von SWT. SWT verwendet bewusst keinen Carbage Collector, um Speicher für erzeugte Objekte zu deallokieren. Die Verwendung grafischer Applikationen erfordert ein vorhersagbares und genaues Verständnis der Vorgänge von Allokation und Deallokation. SWING verwaltet und erstellt seine leicht gewichtigen Objekte selbst, SWT dagegen greift (in)direkt auf Systemressourcen zu. Der Autor [Scarpino et al., 2005,, Seite 8] von SWT/JFace in Action beschreibt dies folgendermaßen: [...] Using AGC [Anm.: Automatic Garbage Collection] with operating system resources is difficult. Since Swing builds its lightweight components at such a high level, this isn t as large a concern. However, automatic disposal of low-level resources, such as SWT s widgets, is error-prone an erratic accros different platforms. If these objects take too much time to be deleted, the memory leaks can crash the program. Or, if these resources are deallocated in the wrong order, then the system s operation can grind to a halt. [..] SWT ermöglicht die Deallokation von Objekten mit dem einfachen Aufruf einer dispose() Methode. Man könnte diese Vereinfachung durch das Framework als halbautomatisch [MANNING: semi-automatic] bezeichnen. Die Darstellung der grafischen Benutzeroberfläche wird unter Linux mit GTK 2.0 oder Motif, unter Solaris, IBM PowerPC und HP Systemen derzeit mit Motif, unter QNX x86 mit Photon und unter Mac OSX mit Carbon realisiert. (2) (2) Motif, Photon und Carbon sind native Windows Toolkits. Der Autor verweist an dieser Stelle auf die Dokumentation bei den jeweiligen Herstellern. GRAFISCHE ENTWICKLUNGSFRAMEWORKS 19

33 2.1 AUSWAHL DER KANDIDATEN Ein weitaus wichtigerer Aspekt, ist jedoch die Vereinfachung der Erstellung komplexer grafischer Benutzeroberflächen durch JFace, welches den Kernpunkt dieser Arbeit in Abschnitt 9 auf Seite 102 darstellt. JFace ermöglicht es, Benutzeraktionen an zentraler Stelle zu definieren. Darüber hinaus bietet es noch weitere interessante Möglichkeiten, die Komplexität der Implementierung einer grafischen Benutzeroberfläche drastisch zu reduzieren. In SWT sind UI Komponenten (widgets) in eine Shell eingebettet. Diese wieder ist das eigentliche Top-Level Fenster, welches Benutzerinteraktionen auf Betriebssystem Ebene entgegen nimmt. JFace ist mit diesem Shellfenster verbunden. Das folgende vereinfachte UML Diagramm zeigt diesen Zusammenhang. Das JFace Fenster referenziert die SWT Shell. Es ist kein Wrapper um um dieses Objekt, sondern stellt Muster bereit, um SWT Shells zu erstellen bzw. zu editieren ([Emmenis, 2003]). Somit stellt JFace ein Framework für eine einfachere Verwendung von SWT zur Verfügung. Abbildung 5: Der Zusammenhang zwischen dem eigenen Code, dem JFace Fenster und der SWT Shell. Quelle: [Emmenis, 2003] Für die Programmierung mit Java gilt die jeweilige Lizenz der verwendeten Java Virtual Machine - diese muss nicht notwendigerweise von SUN sein. SWT und JFace wurde von IBM im Rahmen des Eclipse Projektes entwickelt und unter die CPL (Common Public Licence licenses/cpl.php) gestellt. Sie erhalten damit die vollen Rechte zur Verwendung und Verbreitung dieser Software. Dies macht es möglich, dass kommerzielle Anwendungen ohne Einschränkung für alle Plattformen erstellt werden können. Die CPL ist darüber hinaus OSI konform und damit auch uneingeschränkt für Open Source Projekte zu empfehlen (wenn man kein Problem mit SUNs Java an sich hat). Die Tatsache, dass IBM ein von SUN unabhängiges Unternehmen ist, und die Codebasis von Eclipse sozusagen ein Geschenk an die Community ist, und durch eine unabhängige Stiftung (Eclipse Foundation) verwaltet wird, spricht zusätzlich für SWT/JFace. IBM selbst setzt die Eclipse Technik für seine internen Enterprise Produkte ein und gibt Codeverbesserungen umgehend weiter. Aus der Sicht des Autors ist dies - ähnlich wie die Vorgehensweise von Sun bei Java - Garant für eine gute Qualität von Code, da Sie vom Unternehmen selbst, wie auch den Anwendern gepflegt und überwacht wird. GRAFISCHE ENTWICKLUNGSFRAMEWORKS 20

34 2.2 FAZIT Abbildung 6: Die Eclipse Umgebung, SWT und JFace. Quelle: [Emmenis, 2003] 2 Fazit Der Autor hat sich im vorigen Kapitel für Java als Programmiersprache entschieden. Der erste Java GUI Kandidat Swing bringt aus den genannten Gründen für die Erstellung von grafischen Oberflächen Nachteile mit sich, die man je nach Projekt abwägen muss (Performance, Benutzerakzeptanz). Das Gespann SWT und JFace ist der Kandidat für weitere Betrachtungen im Ramen des schnellen plattformübergreifenden Entwickelns von grafischen Benutzeroberflächen. Entscheidend war zudem die Tatsache, dass JFace sehr elegante Möglichkeiten zum Entwurf grafischer Benutzerschnittstellen bietet und mit IBM als unabhängigem Hersteller, sowie einer OSI konformen Open Source Lizenz eine langfristig sichere Basis darstellt. Die Javabindungen von GTK+ und wxwidgets konnten vom Autor aus mangelnder Erfahrung nicht bewertet werden, bieten jedoch interessante Alternativen zur plattformunabhängigen Entwicklung. Der Reifegrad der Bindungen für unterschiedliche Betriebssysteme wird überwiegend als sehr heterogen beschrieben stellt damit keine ausreichend verlässliche Basis für eine seriöse Anwendungsentwicklung bereit. QT fällt auf Grund seiner Lizenzform und reinen C++ Bindung aus dem Rennen. 3 Quellen und weiterführende Hinweise Ein Vergleich zwischen Swing, SWT und JFace auf Design Ebene und zum Ressourcen Verbrauch findet sich auch in Kapitel 1 von [Scarpino et al., 2005]. Auf den Seiten des Linux Dokumentation Project nedmirror.nl/linuxfocus/deutsch/october2004/article350.shtml gibt es eine schöne Zusammenfassung der für verschiedene Betriebssysteme verfügbaren grafischen Entwicklungframeworks. Common Public Licence, CPL html Eclipse Projekt: Eclipse Eine Übersicht über die technischen Details, Plattform Abhängigkeiten findet man im Whitepaper Eclipse Plattform Technical Overview. Siehe auch nächstes Kapitel. GRAFISCHE ENTWICKLUNGSFRAMEWORKS 21

35 2.3 QUELLEN UND WEITERFÜHRENDE HINWEISE Eine ausgezeichnete Einführung (englisch) in SWT und JFace findet sich bei[scarpino et al., 2005]. Sie geht auch genauer auf die Einrichtung der Entwicklungsumgebung Eclipse 3.0 ein. Mit Eclipse 3.1 hat sich das Prozedere zur Verwendung von JFace erheblich vereinfacht. GRAFISCHE ENTWICKLUNGSFRAMEWORKS 22

36 Teil II Wartbar [...] Wenn man sich damit beschäftigt, "wie die Komponenten zueinander passen, wie sie zusammenarbeiten und wie das Ganze funktioniert", kommt man im Ergebnis jedes Mal zu dem Schluss, dass es sich um eine Einzellösung für den jeweiligen Kunden handelt. Es ist wie in der Zeit vor der industriellen Revolution, als Schuhe noch einzeln hergestellt wurden. Auf dieser Entwicklungsstufe stehen wir. In unserer Branche fertigen wir ausschließlich Einzelstücke. Wir müssen diese Dinge weit mehr vereinheitlichen wie bei der konfektionierten Software. Allerdings ist dies eine der größten Schwellen, die wir beim Nachdenken über und neu bewerten von Datenverarbeitung allgemein überwinden müssen. In Zahlen ausgedrückt werden 20 Prozent eines Budgets für Hardware aufgewandt und 80 Prozent für Service. Das ist ein krasses Missverhältnis. Das ist wie des Kaisers neue Kleider. Wo sonst laufen die Geschäfte eines Unternehmens so ab? Wenn man ein Auto kauft, erwartet man schließlich auch etwas anderes. Da kalkuliert man für die Wartung vielleicht 10 Prozent der Gesamtkosten ein. [...] Greg Papadopoulos (3) (3) Ein Interview auf ZDnet mit dem Sun-CTO vom 07. Juni

37 3. Das Konzept geht der Realisierung voraus. Kapitel 3 Benutzerschnittstellen 1 Motivation 1.1 Komplexität Noch einmal muss die Komplexität herhalten. Diesmal um den Aufwand zu begründen, den die Softwaretechnik treibt, um die Erstellung grafischer Oberflächen zu vereinfachen. Die Informatik Krise der 90er Jahre, die den Mensch als Benutzer in den Mittelpunkt der Anwendungsentwicklung rückte und ganz neue Herausforderungen an die Mensch-Maschine Schnittstelle stellte, war nur die Vorhut der nächsten: das Erstellen dieser Schnittstelle für den Softwarearchitekten zu simplifizieren und standardisieren. Eine grafische Benutzeroberfläche ist in erster Linie eine besondere, visuelle Form einer Schnittstelle zwischen Mensch und Maschine. Diese Definition ist jedoch bei weitem noch nicht ausreichend, die Komplexität der Erstellung zu erfassen. Wie sich schnell zeigen lässt: Es sind unterschiedliche visuelle Darstellungsformen möglich: eine rein textuelle, iconifizierte oder aus beiden Typen gemischte Formen. Diese Darstellung soll in Zukunft vielleicht durch einen räumli- BENUTZERSCHNITTSTELLEN 24

38 3.1 MOTIVATION chen Parameter ergänzt werden (3D Desktop) und wir haben noch nicht darüber nachgedacht, wie diese Komponenten gegenseitig in Beziehung stehen. Sowohl räumlich als auch funktionell. Ich denke zum Beispiel an einen Monitor für Blindenschrift oder die Sprachausgabe via TTS (Text To Speech). Mit der Funktion kommt ein weiterer Aspekt hinzu. Die grafischen Elemente erfüllen entweder rein informative Funktionen oder bieten reaktive Komponenten an, die den Benutzer zur Interaktion auffordern. Der Dialog zwischen Programm und Benutzer kann mit unterschiedlichsten Mitteln erfolgen: taktil durch direkte Auswahl (Touchscreen), ein Zeigeinstrument (Maus), über eine Tastatureingabe (Tastenkombination) aber auch sprachlich. Die Kommunikation mit der Benutzeroberfläche ist also keineswegs immer über die Maus festgelegt (4). Die Farbgebung kann auf eine bestimmte Funktion verweisen (Rot=Stop, Grün=OK), aber auch die Form, ein Zeichen oder eine Kombinationen aus beiden. Hinzu kommt, dass ergonomische Betrachtungen berücksichtigt werden sollen. Die Reaktionszeit auf Benutzereingaben sollte das 3 Sekunden Fenster nicht überschreiten um den Arbeitsablauf nicht zu stören und die Zuordnung von Aktion und Funktion nicht zu verfälschen. Die Anordnung und Farbgebung der Elemente soll bestimmten ergonomischen Voraussetzungen genügen. Die Art und Weise der Darstellung unterliegt einer ständig wechselnden Mode (Skinning). Auf verschiedenen Betriebssystemen wird der Benutzer auf unterschiedliches Verhalten trainiert: Befindet sich der Ja Knopf rechts oder links vom Nein Knopf, und welcher von beiden ist standardmäßig aktiviert? Der Benutzer erwartet darüber hinaus Anwenderfreundlichkeit. Die grafische Oberfläche soll Ihm schließlich helfen, sein Problem zu lösen und Ihn nicht in der Ausübung dieser Tätigkeit behindern. Er möchte auch in seiner gewohnten Umgebung arbeiten und reagiert empfindlich, wenn Anwendungen nicht dem gewohnten look and feel entsprechen. Gewohnheitsaspekte spielen hier eine große Rolle. Für den Benutzer zählt langfristig der Gebrauchsnutzen (Usability) der Software, welcher eng mit dem Anforderungen der Softwareergonomie verbunden ist. Der Softwarearchitekt hat wieder eine andere Sicht: Die grafische Benutzeroberfläche kommuniziert mit der Fachlogik, welche Kontakt zum wie auch immer gearteten Datenhaltung herstellt. Sie muss also die notwendigen Schnittstellen bieten, um mit dem darunter liegenden System zu kommunizieren. Vom softwaretechnischen Aspekt her - und der interessiert uns hier natürlich am meisten - ist dies nicht unbedingt davon abhängig, wie die Implementierung an sich von statten geht und in welcher Sprache dies geschieht. Wie wir noch sehen werden, spielt dieser abstrakte Eigenschaft des softwaretechnischen Entwurfs eine erhebliche Rolle. Entwickler müssen dann diesen Entwurf umsetzen und sind mit einer Vielzahl an Implementierungsstrategien im Umfeld der vorhandenen Frameworks und Entwicklungsumgebungen konfrontiert. Als wäre das noch nicht genug, fügen wir unserer Anwendung noch die Plattformunabhängigkeit hinzu. (4) Man denke an das System, mit dem der von Hals abwärts an gelähmte Physiker Steven Hawkin seinen PC steuert BENUTZERSCHNITTSTELLEN 25

39 3.1 MOTIVATION 1.2 Wie könnte man mit dieser Komplexität umgehen? Abgrenzung und Einordnung Die Plattformunabhängigkeit dürfen wir - Gott sei gedankt - etwas bei Seite stellen, da wir diese Anforderung Sie durch die sorgfältige Auswahl eines geeigneten Oberflächenframeworks bereits weitgehend erfüllt haben. Wir werden deshalb in dieser Arbeit auch keine weiteren Aussagen über das Deployment von Plattform übergreifende Software treffen. Zurück zur Komplexität: Es gibt eine kurze Antwort, wie Softwareingenieure mit Ihr umgehen: Meistens gar nicht! Der Softwarearchitekt delegiert das Problem weiter an Designer, dieser spricht mit dem Ergonomen, dieser mit dem Anwender, dieser befragt den Analysten. Zum Schluss soll der Programmierer die Anforderungen umsetzten (den Plan dazu erstellt natürlich der Softwarearchitekt) und dieser delegiert dann das Problem oft genug aus Mangel an Zeit oder konkretem Know How an eine integrierte Entwicklungsumgebung. (5) Wir haben es mit der deskriptiven Natur von Komplexität zu tun (siehe [Booch, 1994], [Quibeldey-Cirkel, 1994]). Wir können auf der einen Seite nicht genau fassen, ob das System hinreichend genau beschrieben ist (Design, Kundenwunsch, Ergonomie) und wo auf der anderen Seite die Ungewissheiten liegen (was ist überhaupt implementierbar, wie ist es implementierbar). So haben wir gelernt: Ein menschliches Prinzip, um Komplexität zu reduzieren ist Delegation an einen Experten, was sinnigerweise ein echtes Softwaretechnik Prinzip ist. Wer aber ist der Experte für die Umsetzung des Expertenwissens in einen softwaretechnischen Entwurf? Wir wollen einen ganz praktischen Weg einschlagen und dabei das strategische Prinzip Führe den Entwurf auf die Anforderungen zurück [Boehm, 1974] anwenden. Fassen wir in einem ersten Schritt in Tabelle 1 auf Seite 27 noch einmal zusammen, welche Experten für welche Anforderungen bei der Realisierung moderner, grafischer Benutzerschnittstellen zuständig sind. Schnell wird klar, dass das Erfahrungswissen vieler Experten nötig ist, um diese Aufgabe zu lösen. Es ist - besonders für junge Unternehmen mit wenig Erfahrung - praktisch unmöglich dieses Expertenwissen aus dem Stand heraus für eine größere Anwendung umzusetzen. Aus diesem Grunde vertraut man sich gerne Werkzeugen an, welche einen Teil dieses Wissens schnell verfügbar machen, oder zumindest die Erstellung von grafischen Oberflächen erheblich erleichtern. Schauen wir auf eine Projektgeschichte, welche prototypisch Krisen eines Softwarezyklus nachzeichnet. (6) (5) Diese zugegebenermaßen etwas überspitzt formulierte Zusammenhang trifft aber die Sache im Kern. Komplexität lässt sich nicht reduzieren, nur auslagern. (6) Diese Projektsituation wird jedoch schon in aktueller Zeit immer seltener, da die goldenen Zeiten der Softwareentwicklung mit risikofreudigen Geldgebern sich einem Ende zuneigt. BENUTZERSCHNITTSTELLEN 26

40 3.1 MOTIVATION Anforderung Zuständige Experten, Instanzen im Softwareentwicklungsprozess Visuelle Darstellung Designer, Grafiker, Programmierer, Softwarearchitekt Funktion Designer, Softwareergonom, Analysten, Programmierer, Softwarearchitekt Ergonomie Designer, Softwareergonomen, Anwender, Softwarearchitekt Anwenderfreundlichkeit Designer, Softwareergonom, Anwender, Programmierer, Softwarearchitekt Gebrauchsnutzen Designer, Softwareergonom, Anwender Implementierung Softwarearchitekt, Programmierer Plattformunabhängigkeit Softwarearchitekt, Programmierer Tabelle 1: Anforderungen und beteiligte Personenkreise bei der Realisierung einer modernen grafischen Oberfläche (Teil I) Eine kleine Projektgeschichte (7) (aus der Sicht des Softwarearchitekts): Die Analyse liegt vor und dem Projektmanager ist es gelungen eine größere Auseinandersetzung zwischen Programmierer und Designer zu vermeiden. Der Softwarearchitekt hat darüber hinaus ein schöne Entwicklungsumgebung - nennen wir sie einfach No. 2 - gefunden, da er mit No. 1 bereits schlechte Erfahrungen gemacht hat. Er weiß nicht genau warum, denn während seines Studiums hat er sich nie tiefer mit der Arbeitsweise dieser Umgebungen beschäftigen müssen. Er vertraut schließlich einem Hersteller, der seine eigenen Produkte damit entwickelt. Zusätzlich hat er einen jungen und fähigen Programmierer engagiert, der schon einmal mit No. 2 gearbeitet hat. No. 2 ermöglicht dem Programmierer diesmal eine Vorschau der grafischen Oberfläche in Echtzeit, somit sind die Ergebnisse direkt ohne Kompilierung sofort sichtbar! Endlich kann auch er selbst mit der neuen Umgebung aus seinen UML Diagrammen direkt Code generieren lassen, dass spart Ihm viel Schreibarbeit. Und die Projektdokumentation lässt sich nun viel einfacher erstellen. Wichtig für die Zertifizierung! Das neue Look and Feel der nächsten Betriebssystem Generation wird auch unterstützt, das war dem Kunden besonders wichtig. Zusätzlich müssen neue Ergonomie Richtlinien für die Farbgebungen beim Kunden umgesetzt werden. Wenn er doch nur dem Designer einfach die Entwicklungsumgebung in die Hand drücken könnte - er würde sich einen Haufen Diskussionen und Ärger ersparen. Und jedes Mail, wenn der Kunde einen Button dazu haben möchte, dies selben Diskussionen über den goldenen Schnitt und der Programmierer ist 3 Tage außer Gefecht gesetzt. (7) Sie ist fiktiv und doch wieder nicht und beschreibt sehr genau die Probleme beim Erstellen eines Programms zur Verwaltung von Daten für Außendienstmitarbeiter mit C++ und MFC. Softwarearchitekt und Programmierer dieses Projektes waren hierbei dieselbe Person: der Autor in seinem 2. Informatiksemester. BENUTZERSCHNITTSTELLEN 27

41 3.1 MOTIVATION Der erste Prototyp wurde dem Kunden erfolgreich vorgeführt. Die Entwicklungsumgebung No. 2 schien ihren Zweck zu erfüllen und diesmal hatte der Softwarearchitekt auch peinlich darauf geachtet, die Schnittstellen für die Prototypen genau festzulegen. Die Probleme mit den vertikalen Prototypen waren diesmal weniger schlimm, aber immer noch hatten Sie ganze drei Wochen gebraucht, bis alle Ungereimtheiten überwunden waren und ein Wechsel zwischen einzelnen Fensterkomponenten stabil funktionierte. Das lag daran, dass der Code von Entwicklungsumgebung No. 2 für die Erstellung von Fenstern ganz anders aussah, als der von No. 1. Der Programmierer konnte die ursprüngliche Implementierung nicht mehr verwenden, da der GUI Builder dann nicht mehr funktionierte und alles per Hand eingegeben werden musste. Der Kunde hatte nach 3 Monaten Änderungsvorschläge eingebracht, die die Erstellung einer zusätzlichen Eingabemaske notwendig machten und der Projektleiter hatte sich breitschlagen lassen. Die zusätzliche Eingabemaske hatte es in sich. Schnell war zwar ein Klone eines Fensters erstellt und die Entwicklungsumgebung No. 2 leistete dabei gute Dienste, aber der Kundenwunsch sah ausdrücklich vor, dass die Daten, die darin geändert wurden auch in allen beteiligten Komponenten des Programms umgehend zu einer entsprechenden Anpassung führten. Es ist ja meinen Leuten nicht zuzumuten, dass sie ihre Arbeit unterbrechen müssen, nur um ein paar Daten zu ändern, wer soll das bezahlen! Der Programmierer und der Softwarearchitekt machten einige Nächte durch, um das Problem zu lösen. Schnell wurde klar, dass das Programm für eine solche Aufgabe nicht geschrieben worden war. Mittlerweile hatte sich die Entwicklungsumgebung No. 2 leider auch nicht als das Gelbe vom Ei herausgestellt. Es kam immer wieder zu Situationen, in denen die Programmstruktur der Oberfläche einfach nicht mit den Anforderungen der Fachlogik in Übereinstimmung zu bringen war. Tagelang musste herumprobiert werden, bis durch Zufall der Programmierer im Internet eine Kniff gefunden hatten, um das Problem zu lösen. Die Implementierung der Abfragealgorithmen war dagegen in 2 Tagen erledigt. Wie man sich vorstellen kann, wird unser fiktives Entwickler Team spätestens dann, wenn die Firma von einem größeren Unternehmen aufgekauft wird und das beschriebene Programm in eine Business Intelligence Infrastruktur eingebunden werden soll, wahrscheinlich die Lizenz zum Programmieren entzogen bekommen. Ohne im Einzelnen die Projekterfahrung des Programmierers oder Softwareentwicklers (und die des Lesers) zu kennen, spiegelt Sie doch eine Erfahrung wieder: nach der Oberflächenentwicklung kommt mit Sicherheit die Oberflächenwartung. Die Ursache für die Schwierigkeiten ist in der Verwendung der RAD Methode (Rapid Application Development) unter Zuhilfenahme einer hoch integrierten Entwicklungsumgebung inklusive Codebuilder zu suchen, welche BENUTZERSCHNITTSTELLEN 28

42 3.1 MOTIVATION offensichtlich Fachlogik und Oberflächencode eng miteinander verknüpfte. Das Team war sich über die tieferen Zusammenhänge, wie das Werkzeug diese Verknüpfung vornimmt nicht im klaren. Frei nach Joe Spolskys (8) Kardinal Axiom für das Interface Design, stellt der Autor dieser Arbeit folgende These auf: Eine grafische Oberfläche besitzt ein gutes Software Design, wenn sie sich exakt so verhält, wie der Programmierer und Softwarearchitekt dies anhand ihrer Änderungsanforderungen erwarten und diese bei ihrer Aufgabe, Anwenderprobleme zu lösen nicht behindert. Das bedeutet aber auch, dass wir uns zwangsläufig ein tieferes Verständnis für den Aufbau und das softwaretechnische Zusammenspiel der verwendeten grafischen Oberflächenelemente aneignen müssen. Dies kann jedoch leicht in ein reines Expertenwissen über die Funktionsweise des verwendeten Werkzeugs münden, verbunden mit einer engen Bindung und Abhängigkeit zum Hersteller. Wie auch immer - mit oder ohne Werkzeug - der Softwarearchitekt muss die Umgebung kennen und wird wieder zurückgeworfen auf den handgestrickten Entwurf. Fasst alle Aufgaben im Entwicklungsprozess werden dem Programmierer und Softwarearchitekten zugeschrieben. Zumindest dann, wenn dies die Personen in unserem Team sind, die über die notwendigen Skills zum Umsetzen der Anforderungen verfügen. Es stellt sich an dieser Stelle natürlich die Frage, wo das Expertenwissen gespeichert ist, welches wir weiter oben als elementare Voraussetzung für den Einsatz von grafischen Benutzerschnittstellen identifiziert haben? Wir werden erst im nächsten Kapitel eine Antwort darauf finden. Zuvor möchte der Autor auf einige irrige Überzeugungen hinweisen und den geschilderten Projektverlauf analysieren. 1.3 Analyse eines fiktiven Projektverlaufs Wir wollen die konkreten Hürden, welche im Laufe des dargestellten Projektes zu offensichtlich erheblichem Stress geführt haben zusammenfassen. Wir beschränken uns dabei auf die Analyse der GUI zentrierten Probleme. Dem erfahrenen Projektleiter werden natürlich noch zahlreiche andere Fehler auffallen. 1. Einführung einer neuen Entwicklungsumgebung, die viele neue Funktionen bot (UML Quellcodegenerierung, Designvorschau), aber offensichtlich auch jede Menge Probleme hervorrief. Daraufhin konnten No. 2 s neue Funktionen dann doch nicht hundertprozentig genutzt werden (Vorschau, Codegenerierung). 2. Starke Bindung an das Werkzeug: Look and Feel abhängig von der verwendeten Programmierumgebung. (8) siehe Abschnitt 3 auf Seite 33 BENUTZERSCHNITTSTELLEN 29

43 3.2 IRRIGE ÜBERZEUGUNGEN Anforderung Wartungsfreundlichkeit (Designänderungen, Funktionale Änderungen) Erweiterbarkeit (Zusätzliche Menüs, Buttons, Design, zusätzliche Fenster) Zuständige Experten, Instanzen im Softwareentwicklungsprozess Softwarear- Programmierer, chitekt Programmierer, chitekt (Designer), Programmierer, Softwarearchitekt (Designer), Softwareergonom, Analysten, Programmierer, Softwarearchitekt Programmierer, Softwarearchitekt Automatische Aktualisierung aller geöffneten Fenster bei Zugriff auf eine gemeinsame Datenbasis. Trennung von der Fachlogik und dem Designentwurf. Unabhängigkeit von Entwicklungswerkzeugen. Softwarear- Tabelle 2: Anforderungsmanagement für eine grafische Oberfläche (Teil II) 3. Unzureichende Trennung von GUI Logik und GUI Design ( Wenn die Designer mal ran müssen, gibt es wieder Diskussionen und der Programmierer ist für 3 Tage außer Gefecht gesetzt. ). 4. Stabilitätsprobleme der GUI, nachdem Codeänderungen vorgenommen wurden. Wenn Fenster zur Applikation hinzugefügt wurden, führte dies beim Fensterwechsel zum Programm Absturz. GUI s wurden durch einfaches Copy and Paste erzeugt, da offensichtlich die Erstellung eines neuen Fensters mit allen notwendigen Optionen - trotz GUI Builder - sehr aufwendig ist. 5. Starke Abhängigkeit vom und Wechsel des GUI Builders im Produktzyklus: die Codegenerierung des GUI Builders der Entwicklungsumgebung No. 2 unterscheidet sich so stark zum vorherig verwendeten Werkzeug, dass ursprünglicher Code nicht mehr wieder verwendet werden kann. Fachlogik und GUI Logik laufen einander entgegengesetzt, dies führt zu starken Entwicklungsverzögerungen und steht in keinem Verhältnis zum Aufwand für die Realisierung der eigentlichen Anforderungen. Die Funktionsweise des verwendeten GUI Frameworks wurde nicht verstanden. 6. Eine funktionale Erweiterung zur transparenten Dateneingabe über Fenstergrenzen hinweg konnte nicht realisiert werden. Es fehlte das nötige Know How. Diese Option wurde vom Kunden als selbstverständlich vorausgesetzt. 2 Irrige Überzeugungen Gehen wir nun zusammen Stück für Stück die sieben Punkte durch, die weiter oben zu großen Problemen geführt haben. BENUTZERSCHNITTSTELLEN 30

44 3.2 IRRIGE ÜBERZEUGUNGEN 2.1 All in One Entwicklungsumgebungen machen die Arbeit leichter Entwicklungsumgebungen sind ein Segen. Sie machen die Arbeit tatsächlich leichter. Jedoch ist es gefährlich - besonders in kleinen Projekten - verschiedene Aspekte des Projektes von einem Werkzeug abhängig zu machen. UML Generierung, Dokumentationserstellung und GUI Code Generierung sollten unabhängig voneinander existieren können, denn sie bringen bei Ausfall eines Werkzeugs das gesamte Projekt in Gefahr. Verfügt man über genügend Erfahrung, so kann man sich natürlich seiner Lieblingsumgebung anvertrauen, sollte jedoch darauf achten, dass man immer genau weiß, was beim Drücken auf die Buttons der Entwicklungsumgebung Kompiliere, erzeuge Dokumentation, Generiere Code aus UML oder Füge einen Button ein geschieht und/oder welche Programme im Hintergrund für die Ausführung zuständig sind. Wenn man auf unterschiedlichen Plattformen unterwegs ist, und keine virtualisierten Programmiersprachen verwendet ist dieser Punkt um so nachhaltiger. Fazit Klare Zuordnung bei Projektbeginn, welche Anforderungen von welchem Werkzeug ausgeführt werden sollen. Werkeugwechles, wenn möglich im Produktzyklus vermeiden! Dabei ist zu berücksichtigen, welche Helferapplikationen (Compiler, Dokumenterzeugung) im Hintergrund arbeiten und wie diese funktionieren. 2.2 Abhängigkeit von der verwendeten Programmierumgebung Wenn schon, dann sollte die Programmierumgebung so flexibel sein, dass jederzeit neue Variationen eines Frameworks verwendet werden können. Vielleicht bietet Sie sogar eine Plugin Technik. Den Kundenwunsch zu erfüllen, das aktuelle Look and Feel des Frameworks zu verwenden, sollte niemals abhängig von einer Programmierumgebung sein! Es kann für spezielle Anwendungsbereiche sinnvoll sein diese Abhängigkeit zuzulassen, jedoch sollte man sich immer bewusst sein, dass damit die spezielle Implementierungsmethode des Herstellers gewählt wird und diese in der Regel nicht auf andere Werkzeuge übertragbar ist. Eine weitere Abhängigkeit entsteht, die sie dazu zwingt bestimmte Releasezyklen des Herstellers mitzumachen. Vielleicht gibt es eine gute quell offene Alternative, die durch ein kommerzielles Plugin aufgewertet werden kann. Fazit Programmierumgebungen sollten unabhängig von bestimmten Frameworks sein. Das heißt auch, sich unabhängig von (hochintegrieten) GUI Buildern zu machen. Herstellerabhängigkeiten sollte man - es sei denn, sie sind ausdrücklich erforderlich - vermeiden. 2.3 Unzureichende Trennung von Designcode und GUI Code Damit im Team sinnvoll, parallel und effizient gearbeitet werden kann, sollten GUI Logik und GUI Design voneinander getrennt sein. In der Theorie ist das natürlich bei allen wichtigen Programmierumgebungen der Fall. In der Realität ist es jedoch nicht einfach möglich, den GUI Code einfach dem Designer zu geben ohne Angst haben zu müssen, dass hinterher alles noch reibungslos funktioniert. BENUTZERSCHNITTSTELLEN 31

45 3.2 IRRIGE ÜBERZEUGUNGEN Fazit Arbeiten am Code sollten verteilt im Team möglich sein, ohne dass die Teams dabei voneinander abhängig sind. Fachlogik, GUI Code und Design müssen voneinander entkoppelt werden. 2.4 Stabilitätsprobleme der GUI nach Codeänderungen Dieser Punkt hängt eng mit dem Vorherigen zusammen. Oft müssen zu vorhandenen Applikationen neue Fenster hinzugefügt werden. Dabei wird häufig durch einfaches Copy and Paste von altem GUI Code neuer erzeugt. Die Komplexität der Verwaltung aller GUI Elemente und die oftmalige Vermischung von Programmlogik und GUI Code können dabei zu Seiteneffekten führen, die auch durch intensives Debuggen einfach nicht zu finden sind. Wann wird an welcher Stelle welches Objekt instantiiert, deallokiert, übergeben, referenziert, konvertiert, gecastet u.s.w. Es können ernste Probleme auftauchen, die zu schwer lösbaren bis hin zu unlösbaren Problemen führen. Solche Oberflächenmonster (siehe Abschnitt 3 auf Seite 33) sind sehr teuer in der Wartung und empfindlich gegen kleinste Eingriffe in die Programmstruktur der GUI. Fazit Entkoppeln Sie die GUI Logik ihres Frameworks von Ihrer Fachlogik. Kennen sie Ihr Framework genau und eignen sie sich die notwendigen softwaretechnischen Skills zum Aufbau grafischer Benutzerschnittstellen an. 2.5 Codegenerierung mit einem GUI Builder GUI Code oder GUI Logik sind ein wertvoller Bestandteil ihrer Software, wie die Fachlogik selbst. GUI Builder folgen einer batchprozessartigen Vorgehensweise, um GUI Code einzubauen. Was als enorme Zeitersparnis gepriesen wird, stellt sich für reale Projekte oft als Spaghetticode heraus, dessen innere Logik schwer zu durchschauen ist. Meist ist der GUI Code über verschiedene Klassen verteilt und die Initialisierung wird auf verschiedene Methoden verteilt. Dadurch wird das System leicht unübersichtlich. Wenn die Programmlogik eng mit der Oberflächenlogik verheiratet wird, kann dies zur Verschleierung der Fachlogik führen. Diese muss meist an unterschiedlichen Stellen des GUI Codes platziert werden, um eine ordnungsgemäße Funktion zu gewährleisten. Diese Dinge in den Griff zu bekommen, erreicht man meist nur durch eine saubere softwaretechnische Entkoppelung von Fachlogik, GUI Logik und GUI Design. Es ist auch ein guter Stil, Oberflächen nicht zu sehr mit Elementen zu überladen (9). Dann hält sich die Komplexität bei selbst geschriebenem Code meist in Grenzen. Zudem gibt das selbst Schreiben die Möglichkeit den Entstehungsprozess und die zugeteilten Verantwortlichkeiten zu dokumentieren. GUI Builder eigenen sich deshalb hervorragend zum Prototyping, den schnellen Draufblick oder einfache Anwendungen. Eine Ausnahme bildet beispielsweise der GUI Builder Glade für GTK+ Anwendungen, der die GUI Beschreibung unabhängig von der Programmlogik in einer XML Datei ablegt. (9) siehe auch Miller, The Magical Number Seven [Miller, 1956] BENUTZERSCHNITTSTELLEN 32

46 3.3 QUELLEN UND WEITERFÜHRENDE HINWEISE Fazit GUI Builder haben in der Regel prototypische Funktionen. Für das Erstellen komplexer Anwendungen ist entweder ein genaues Verständnis zur Funktionsweise vonnöten, oder man entwickelt besser von Grund auf selbst. 2.6 Optionen, die vom Kunden als selbstverständlich vorausgesetzt werden Der Kunde hat immer Recht. Es ist nicht seine Schuld, dass 10 Jahre Informatik ins Land gegangen sind, und sich in Sachen Benutzerfreundlichkeit leider nicht sehr viel getan hat. Wir müssen uns deshalb bemühen, eine Lösung für Forderungen des Kunden suchen, die eigentlich selbstverständlich sein sollten: zum Beispiel Datenkonsistenz über Fenster hinweg sicherzustellen. Hinzukommen noch Eigenschaften des Programms, die mittlerweile für grafische Oberflächen allgemein als selbstverständlich vorausgesetzt werden: Menüleisten, Toolbars, die Zugänglichkeit zu Programmfunktionen über Tastenkombinationen u.s.w. Fazit Es gibt Anforderungen an grafische Benutzerschnittstellen, die offensichtlich einen erheblichen Implementierungsaufwand erfordern. Es stellt sich die Frage, wo dieses Wissen gespeichert ist und wie man diesen Aufwand reduzieren kann. 3 Quellen und weiterführende Hinweise Eine sehr schönes Kapitel über Komplexität aus der Mitte der 90er Jahre findet sich in [Quibeldey-Cirkel, 1994]. Quibeldey-Circel ist bemüht die Hintergründe der objektorientierten Entwicklungspraxis wieder in deren historischen Kontext zu stellen und vom Hype abzugrenzen. Der Autor hat in den Jahren zahlreiche seiner Vorlesungen über Softwaretechnik im Rahmen seiner Ausbildung gehört. Oberflächenmonster : in Anlehnung an Frederick P. [Brooks 1987] no Silver Bullet: Essence and Accidents of Software Engineering, der den Charakter von gewöhnlichen Softwareprojekten mit den Monstern in den Alpträumen der Menschen vergleicht. Der interessierte Leser findet auf einen interessanten Artikel von Joe Spolsky (Blog von Joe Spolsky joelonsoftware.com/) zum Thema User Interface Design aus der Sicht eines gestandenen Programmierers. Dem Human Interface Design Guide projects/gup/hig/ des Gnome Projektes wurde eine interessante Literaturliste hinzugefügt: Human Interface Guide - Literaturliste http: //developer.gnome.org/projects/gup/hig/2.0/bibliography.html. Man beachte die Häufung von Titeln aus den 90er Jahren. Eine ausführliche Seite mit vielen Querverweisen zum Thema Softwareergonomie finden Sie auf Usernomics - User Interface Design http: // BENUTZERSCHNITTSTELLEN 33

47 Wer sich für dafür interessiert, wie ein GUI Builder arbeitet, der kann sich den Java GUI Builder einmal anschauen - quell offene Open Source. BENUTZERSCHNITTSTELLEN 34

48 Kapitel 4 Den Entwicklungsprozess managen Vom dezentralen Eventhandling zur zentralen Beschreibung von Benutzeraktionen. [...] The more you feel that you can control your environment, and that the things you do are actually working, the happier you are. When you find yourself frustrated, angry, and upset, it s probably because of something that happened that you could not control: even something small. The space bar on your keyboard is not working well. When you type, some of the words are stuck together. This gets frustrating, because you are pressing the space bar and nothing is happening. The key to your front door doesn t work very well. When you try to turn it, it sticks. Another tiny frustration. These things add up; these are the things that make us unhappy on a day-to-day basis. Even though they seem too petty to dwell on (I mean, there are people starving in Africa, for heaven s sake, I can t get upset about space bars), nonetheless they change our moods. [...] Joe Spolsky [Spolsky, 2001] Die Benutzersicht (Anm. des Autors) DEN ENTWICKLUNGSPROZESS MANAGEN 35

49 4.1 USER INTERFACE STANDARDS Im Mittelpunkt dieses Kapitels steht ein Prozess. Wir entlehnen dazu die in der Betriebswirtschaft üblichen Beschreibungsformen von Geschäftsprozessen um mit Hilfe eines Flowchartdiagramms den Entwicklungsprozess für unsere Zwecke zu beschreiben (siehe z.b. [Wikipedia, 2006, Geschäftsprozess]). Es soll eine typische Multifensteranwendung an Hand objektorientierter Grundsätze verbessert werden. Zusätzlich zu den im letzten Kapitel vorgestellten fachlichen Anforderungen kommen für unsere Anwendung damit noch hinzu: Es ist handelt sich um eine Multifensteranwendung deren einzelne Fenster jeweils verschiedene Komponenten des Programms realisieren. Sie sind vollständig voneinander unabhängig und greifen auf eine gemeinsame Datenbasis zu. Jedes Fenster besitzt ein eigenes Menü, Toolbar und die Möglichkeit, Eingaben und Aktionen über beliebig hinzugefügte Komponenten des Frameworks durchzuführen. Alle gängigen Standards für die Benutzerinteraktion müssen dabei implementiert werden. Wir entwickeln nicht alles von Grund auf selbst, sondern suchen nach Möglichkeiten bereits vorhandenes Erfahrungswissen zu adaptieren. Unser primäres Ziel ist es, die Entwurfskomplexität so gering wie möglich zu halten und dabei Wartbarkeit und Erweiterungsmöglichkeiten für zukünftige Anwendungen zu erhalten. Wie wir sehen werden, wird dies erst durch die Kombination und den kreativen Einsatz von Entwurfsprinzipien, das Adaptieren von Entwurfsmustern sowie der Analyse der Möglichkeiten des verwendeten Klassenframeworks möglich. Wir zeigen dies am Beispiel des Klassenframeworks JFace. Der Autor wird keinen Softwareentwicklungsprozess vorstellen. Er selbst verwendet den ICONIX Prozess ([Rosenberg and Scott, 2001]) für kleinere Projekte. Es wird vorausgesetzt dass der Leser mit den wesentlichen Prinzipien der Softwareentwicklung vertraut ist. Der Autor wird einen strukturierten Weg aufzeigen, vorhandenes Expertenwissen in Form von Mustern auf konkrete Anforderungen zurückzuführen und dies im Team zu dokumentieren. Zum Zweiten werden die Komplexitätstreiber bei der Entwicklung von GUIs identifiziert und gezeigt, wie man sich das Wissen quell offener Klassenbibliotheken bei der Lösung dieses Problems zu Nutze machen kann. Das extrahierte Wissen soll im Rahmen von HCI Mustern dokumentiert werden (siehe weiter oben in 7 auf Seite 46). 1 User Interface Standards Tabelle 2 auf Seite 30 gab uns eine erweiterte Sicht auf die Anforderungen, eine konkrete grafische Oberfläche zu realisieren. Zur Umsetzung dieser Anforderungen ist eine neue, konkrete softwaretechnische Sicht nötig. DEN ENTWICKLUNGSPROZESS MANAGEN 36

50 4.1 USER INTERFACE STANDARDS Die Anforderungen an eine GUI hängen zunächst sehr vom konkreten Projekt und den Kundenwünschen ab. Man könnte aber auch sagen, dass diese Wünsche ein abstrakteres Benutzerverhalten widerspiegeln, welches weit über das hinausgeht, was wir bei einer oberflächlichen Sicht auf unsere Systemarchitektur vermuten. Ist es nicht eigentlich wirklich selbstverständlich, dass Teile einer Anwendung Programm- und Fenster übergreifend auf konsistente Daten zugreifen können müssen? Jan Borchers beschreibt die Benutzersicht auf das Programm folgendermaßen: As we know, users generally identify a software system with what its user interface shows them, without caring about its inner works. [Borchers, 2000] Gehen wir einmal davon aus, dass angesichts der weitgehend standardisierten Betriebssystem Oberflächen - alle Apple Benutzer mögen mir verzeihen - übergreifende, sagen wir vorerst Übereinkünfte gibt, die von einem modernen Computerprogramm erwartet werden. Diese Leitlinien sind eine Mischung aus dem, was der Benutzer gewohnheitsmäßig erwartet - das Modell des Benutzers im Kopf [Spolsky, 2001] - dem, was Designer, Softwareergonomen und andere (siehe Abschnitt 3 auf Seite 33) unter gutem Oberflächendesign subsumieren und was die Hersteller an konkreten Komponenten anbieten. Designer oder Softwareergonomen kümmern sich dabei um alle Aspekte des User Interface Design (siehe z.b. [Wood, 1997]), Softwarearchitekten um eine abstrakte Sicht auf dieses Design und Entwickler kümmern sich um die Implementierung. Konkrete Standards für Benutzerschnittstellen sind meist herstellerspezifisch in User Interface Guide s (UIG) zusammengefasst. So hilfreich diese Kataloge sind, sich einen Überblick über die Möglichkeiten für das User Interface Design zu verschaffen, sie geben dem Softwaretechniker keine Anleitung für die Minimierung des Implementierungsaufwands. Sie sind im wesentlichen Kataloge zur Beschreibung von Komponenten zum Bau grafischer Benutzerschnittstellen - zu simpel, abstrakt um dem Softwaretechniker eine wirkliche Hilfe für den Entwurf zu sein. Wenn wir zusammenfassen wollten, was die User Interface Guide s verschiedener Hersteller an Komponenten aufführen, die für grafische Oberflächen ihrer Meinung nach obligatorisch sind, dann stellen wir fest, dass sich die Beschreibungen überwiegend gleichen. Unterschieden wird jeweils nur in der Art und Weise, wie im entsprechenden System das Verhalten einzelner Komponenten gehandhabt werden soll (siehe Tabelle Tabelle 3 auf Seite 38). Darüber hinaus muss sich der Programmierer an Hand der Schnittstellenbeschreibung für das verwendete Framework (API - Application Programming Interface) kundig machen, wie die einzelnen Elemente erzeugt, eingebunden und wieder entfernt werden. Eine Aufgabe, deren Aufwandsschätzung für die resultierende Anwendung schwierig ist. Versuchen wir, die für die Anwendungsrealisierung maßgeblichen Komplexitätstreiber zu identifizieren: Betrachtet man die einzelnen Komponenten einer grafischen Benutzerschnittstelle für sich - Buttons, Textfelder, Listboxen u.s.w. - so ist die Standardisierung und Abstraktion ihrer Implementierung meist so weit fortgeschritten, dass man sich die Mühe einer Analyse an dieser Stelle sparen kann. DEN ENTWICKLUNGSPROZESS MANAGEN 37

51 4.1 USER INTERFACE STANDARDS Hersteller GUI Richtlinenbeschreibung GNOME Human Interface Guidelines: HIG org/projects/gup/hig/ Apple Human Interface Guidelines: Apple Developer apple.com/-> The Aqua Interface Official Guidelines for User Interface Developers and Designers: Microsoft Developers Network msdn.microsoft.com-> Windows Interface Components Gnome Apple Windows x x x Tabelle 3: Design Style Guides der jeweiligen Hersteller: Es ist davon auszugehen, dass die Hersteller in Abwägung zwischen Funktionsvielfalt, Flexibilität und Machbarkeit bei der Realisierung einen Stand erreicht haben, die sich softwaretechnisch auf sehr hohen Niveau bewegt (10). Der Autor möchte zeigen, dass die softwaretechnische Hauptarbeit in folgenden Bereichen liegt, auch wenn dies vorerst eine triviale Feststellung zu sein scheint: Im Hinzufügen einer Benutzerfunktionalität für einzelne Komponenten, Im wiederholten Tun desselben an verschiedenen Stellen im Anwendungscode. Zusätzlich muss auf der einen Seite die Anbindung zur Fachlogik berücksichtigt werden, auf der anderen Seite muss die GUI Logik entsprechend vom Design entkoppelt werden. Es lässt sich leicht zeigen, dass z.b. für das Hinzufügen eines Button Objektes zu einer Oberflächenkomponente ein einfacher Zweizeiler genügt: 1. Festlegen einer Instanzvariablen und 2. anschließende Allokierung des Objektes mit new durch Aufrufen des Konstruktors. Im wesentlichen lassen sich alle Elemente grafischer Oberflächen auf diese Weise erzeugen. Aber wie soll das Objekt auf Benutzereingaben reagieren? Über einen Mausklick, Sprache, die Tastatur? Über welche Kanäle soll dies geschehen? Rechte Maustaste, mittlere oder linke? Über einen Doppelklick? Soll direkt Text über die Tastatur eingegeben werden, soll vorher ein Feld über einen Doppelklick zur Eingabe verfügbar gemacht werden? Oder über einen einfachen Klick? Welche visuelle Darstellung wird dabei gewählt? Gibt es ein (10) Der Autor verwendet keine Beta Software - zumindest nicht für diese Arbeit. DEN ENTWICKLUNGSPROZESS MANAGEN 38

52 4.1 USER INTERFACE STANDARDS visuelles oder akustisches Feedback? Wie wird dies programmiertechnisch realisiert? Ist diese Realisierung im Code leicht lokalisierbar? Ist sie transparent zugänglich oder ist sie über viele Stellen des Programms verteilt? Wie eng ist die Kopplung zwischen diesen Codeteilen? Soviel zur Trivialität der Aufgabe! An dieser Stelle möchte ich erwähnen, dass es die wissenschaftliche Disziplin der Softwareergonomie ist, die Güte von grafischen Oberflächen (... elementen) und ihre Eignung für die Benutzerinteraktion festzustellen. Die Liste der Anforderungen lässt sich in der Normenreihe ISO entstanden 1996 bis nachlesen, welche als DIN und europäische Norm übernommen wurde (siehe z.b. [Wikipedia, 2006, ISO 9241], [ISO, 1995]). Unter dem Titel Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten sind 17 Teilschriften zusammengefasst. In Teil 11 werden die Anforderungen an die Gebrauchstauglichkeit definiert: Effektivität zur Lösung einer Aufgabe Effizienz der Handhabung des Systems Zufriedenheit der Nutzer einer Software Es zeichnet sich ab: die Vielfalt der Anforderungen an grafische Benutzerschnittstellen ist mit einem enormen Zuwachs an wartungspflichtigem Code und mit einer Vielzahl an schier nicht mehr berechenbaren Seiteneffekten versehen: nicht nur implementierungstechnischen, sondern auch benutzerzentrierten Seiteneffekten (siehe [Spolsky, 2001]). Wir greifen uns einen Punkt heraus: die Handhabung des Systems. Auch diese Betrachtung wäre für sich gesehen zu umfangreich. Wir müssen uns auf eine definierte Untermenge beschränken. In dieser Untermenge müssen wir den softwaretechnischen Zugriff analysieren und vereinfachen. Dazu benötigen wir softwaretechnische Regeln, die es uns erlauben, die volle gestalterische Freiheit zu bewahren, aber gleichzeitig den Entwurf übersichtlich und wartbar zu halten. Aus der Fülle der Komponenten für grafischen Benutzerschnittstellen möchte der Autor für die folgenden Betrachtungen deshalb einige wenige auswählen, deren Entwurf und Implementierung für einen hohen Programmieraufwand sorgen: Menüs, Toolbars und alle anderen Arten der Auswahlelemente (einfache Buttons, Checkbuttons, Dropdownfelder...), die sich in Applikationsfenstern wiederfinden, deren Informationselemente, wie Tooltiptext, Beschreibung, deren Iconifizierung (bildliche Darstellung), die Verwaltung dieser Elemente. DEN ENTWICKLUNGSPROZESS MANAGEN 39

53 4.2 DER SOFTWARETECHNISCHE ENTWURF Die Palette an Komponenten, welche dem Softwarearchitekten zur Verfügung steht, und die in modernen Anwendungen üblich sind, umfasst natürlich eine erheblich größere Anzahl. Die Grundprinzipien lassen sich jedoch später auf beliebige Oberflächenobjekte ausdehnen und somit die Verwaltungsaufgaben der gesamten Anwendung vereinfachen. 2 Der softwaretechnische Entwurf Es gibt verschiedene Wege, die Komplexität von Anwendungsprogrammen mit grafischer Benutzerschnittstelle zu reduzieren. Der Autor hat für sich entdeckt - andere mögen das Problem z.b. durch Delegation an einen Experten erledigen - dass die objektorientierte Modellierung der Anwendungsdomäne eine sehr hilfreiche Angelegenheit ist, um diese Anforderungen in den Griff zu bekommen. Die Darstellung des softwaretechnischen Modells erfolgt dabei mit Hilfe der Unified Modelling Language (UML, siehe [OMG (Object Modeling Group Inc.), 1999] [Rumbaugh et al., 1999]). Das so entstandene abstrakte softwaretechnische Systemmodell nennt man Entwurf. Die Phasen im Entwicklungsprozess meist Analyse und Design ([Booch, 1994]). Man unterscheidet weiterhin zwischen Entwurfsprinzipien und Heuristiken für den Entwurf. Die Prinzipien der Softwaretechnik gehen schon auf Arbeiten, wie von David Parnas (Information Hiding, 1972) oder A. Simon (schwache Kopplung zwischen und starke Kohäsion in den Modulen, 1962) zurück. Sie stellen praxiserpropte und bewährte Problemlösungsstrategien dar. Heuristiken dagegen sind Regeln, die im Umfeld des objektorientierten Entwurfs für die einzelnen Komponenten - Klassen, Interfaces, Pakete, Vererbungs- und sonstige Beziehungen - zur Anwendung kommen. Sie treffen nicht immer in jeder Situation zu und müssen besonders geprüft werden, ob Ihr Einsatz an einer bestimmten Stelle im Entwurf sinnvoll ist. Die erfolgreiche und qualitativ hochwertige Abbildung der gestellten Aufgabe in einem objektorientierten Entwurf (siehe z.b. [Booch, 1994, Balzert, 1997, Larman, 2001]) gehört zu den schwierigsten softwaretechnischen Aufgaben. Die notwendigen Fertigkeiten für die Anwendung objektorientierter Programmierprinzipien zu erwerben, ist eine langwierige Sache, da sie sich vom normalen prozeduralen Programmierschema völlig unterscheidet und ein hohes Maß an Abstraktionsfähigkeit und Übung verlangt. Es gehört eine ebenso große Portion Kreativität und Erfahrung dazu, um einen eleganten und wartbaren Entwurf zu erreichen. Entwerfen ist primär ein Suchproblem und keine Optimierungsprozess, schreibt [Quibeldey-Cirkel, 1994, Kap. 2.1]. Aus diesem Grunde lässt sich ein globaler Entwurf auch nicht algorithmisch lösen, sondern erfordert immer eine an die jeweilige Aufgabe adaptierte Vorgehensweise (siehe [Reißing, 2002, Booch, 1994]). 2.1 Entwurfsprinzipien Ein Prinzip ist nach dem Fremdwörterbuch (1990, Duden Verlag): DEN ENTWICKLUNGSPROZESS MANAGEN 40

54 4.2 DER SOFTWARETECHNISCHE ENTWURF Prin zīp [lat.] das; -s, -ien [...i e n] (seltener, im naturwissenschaftlichen Bereich meist: -e): a) Regel, Richtschnur; b) Grundlage, Grundsatz; c) Gesetzmäßigkeit, Idee, die einer Sache zugrunde liegt, nach der etw. wirkt; Schema, nach dem etw. aufgebaut ist Die wichtigsten Prinzipien findet man in den Standardwerken zur Objektorientierung ausführlich beschrieben (siehe [ISTE, 2006]). Der Autor möchte an dieser Stelle jedem Entwickler die Lektüre dieser Klassiker objektorientierter Vorgehensweisen ans Herz legen, ohne die objektorientierte Entwürfe nur oberflächlich verstanden, aber nur schwer kreativ auf einen andere Problembereiche übertragen werden können. Sie spielen für den Entwurfsprozess eine so zentrale Rolle, dass ich die Wichtigsten hier kurz erwähnen möchte, ohne dass dabei eine umfassende Darstellung des Gebietes erfolgt. Sie werden in den weiteren Verlauf als Kenntnis vorausgesetzt. Jedes Team, dass sich mit dem Entwurf von Software nach objektorientierten Prinzipien beschäftigt, sollte Zeit in die Schulung dieser Prinzipien investieren. Leider werden nach Auffassung des Autors diese Prinzipien selbst an der Hochschullehre nicht in ausreichendem Masse gelehrt und ihre Ursprünge, welche ganz und gar nicht nur in der Informatik liegen zu wenig beleuchtet. Nach der Meinung des Autors legen diese Prinzipien jedoch erst die Grundlage zum Verständnis komplexer grafischer Klassensammlungen, welche fast allesamt auf dem objektorientierten Paradigma beruhen. Eine Auflistung von Entwurfsprinzipien der Universität Stuttgart [ISTE, 2006] erwähnt, [...] dass es für die meisten von Ihnen wenig empirische Untersuchungen über ihre Wirksamkeit und ihre Relevanz gibt. Sie stellen eher eine Art Tradition im Software Engineering dar, die durch überwiegend positive Erfahrungen aufrecht erhalten wird. Obwohl der empirische Nachweis der Brauchbarkeit fehlt, werden in vielen wissenschaftlichen Arbeiten diese Prinzipien herangezogen, um aus ihnen Entwurfsziele zu extrahieren [...] Auch diese Arbeit wird sich immer wieder auf diese Prinzipien berufen, ohne einen genauen empirischen Nachweis liefern zu können. [Freeman et al., 2006] schafft mit seinem Werk eine didaktisch gelungene Mischung aus Lehrbuch und Praxiswissen über objektorientierte Prinzipien (und Entwurfsmuster). Er identifiziert z.b. folgendes Entwurfsprinzipien als wesentlich (eine Auswahl): Identifiziere die Aspekte der Anwendung, die sich ändern können, und trenne Sie von denen, die konstant bleiben. Programmiere auf eine Schnittstelle, nicht auf eine Implementierung. Ziehe Komposition der Vererbung vor. DEN ENTWICKLUNGSPROZESS MANAGEN 41

55 4.2 DER SOFTWARETECHNISCHE ENTWURF Eine sehr gute Zusammenfassung bietet die Software Engineering Abteilung der Universität Stuttgart ([ISTE, 2006]) und nennt dabei praktisch alle wichtigen Standardwerke zum softwaretechnischen Entwurf. Sie unterscheidet taktische von strategischen Prinzipien. Einige strategische Prinzipien daraus sind z.b. : Führe den Entwurf auf die Anforderungen zurück. Minimiere die Komplexität. Vermeide Redundanz. Einige taktische Prinzipien daraus sind: Strukturiere hierarchisch. Trenne Verhalten und Implementierung. Trenne Schnittstelle und Implementierung. Es wäre dem Zweck und auch dem Umfang dieser Arbeit nicht angemessen, diese Prinzipien im Einzelnen zu beschreiben. Wo nötig, wird der Autor seine Entwurfsentscheidungen entsprechend begründen. 2.2 Heuristiken Die Anwendung der oben genannten Prinzipien lässt sich im objektorientierten Umfeld auf praktische Regeln abbilden. Das Fremdwörterbuch (Duden Verlag, 1990) definiert Heuristik wie folgt: Heu rị stik [gr.-nlat.] die; -: Lehre, Wissenschaft von den Verfahren, Probleme zu lösen; methodische Anleitung, Anweisung zur Gewinnung neuer Erkenntnisse. In diesem Sinne können Heuristiken helfen, für das konkrete Design bewährte Regeln zur Verfügung zu stellen. Wesentliche Methoden werden bei [Booch, 1994] und in späteren Werken zur UML vorgestellt (z.b. [Rumbaugh et al., 1999]). Die folgenden Ausführungen beziehen sich auf diese Werke. Heuristiken für das objektorientierte Paradigma lassen sich in fünf Bereiche aufteilen: Heuristiken für Klassen, Interfaces, Pakete, Vererbungsbeziehungen und sonstige Beziehungen. Damit sind die wesentlichsten Elemente des objektorientierten Entwurfs genannt. Für Klassen ist z.b. folgende Heuristik anzuwenden: Sie [Anm.: die Klasse] ist eine abgegrenzte Abstraktion eines Begriffs aus dem Problem- oder Lösungsbereich. Interfaces: Es stellt alle nötigen (aber nicht mehr) Operationen für einen einzigen Dienst zu Verfügung. DEN ENTWICKLUNGSPROZESS MANAGEN 42

56 4.2 DER SOFTWARETECHNISCHE ENTWURF Pakete: Es hat einen hohen Zusammenhalt und ist eine klare Abgrenzung einer Menge zusammengehöriger Elemente. Vererbungsbeziehungen: Vererbungshierarchien sollten balanciert sein: nicht tiefer als (etwa) fünf Stufen und nicht zu breit. Um die Breite zu reduzieren, können zur Gruppierung abstrakte Zwischenklassen in die Vererbungshierarchie eingefügt werden. Sonstige Beziehungen: Benutzt-Beziehungen sollen nur dann verwendet werden, wenn es sich nicht um eine strukturelle Beziehung handelt. Letztere sollten durch Assoziationen modelliert werden. Diese Auswahl beschreibt sowohl die statische (Klasse, Interface, Paket) und die dynamische Sicht (Beziehungen) auf den objektorientierten Entwurf. Wir werden bei dem Ziel, wartbare grafische Benutzeroberflächen zu entwickeln auch Verfahren aus anderen wissenschaftlichen Prinzipien, wie dem Ingenieurwesen einsetzen, zum Beispiel das Reverse Engineering (Unterabschnitt auf Seite 75). Dies wir durch Werkzeuge der Softwaretechnik gut unterstützt (siehe Abschnitt 4.1 auf Seite 51) Refactoring Eine besondere Leistung haben Martin Fowler, Kent Beck, John Brant, William Opdyke und Don Roberts mit der Veröffentlichung ihres Werkes Refactoring: Improving the Design of Existing Code erbracht ([Fowler et al., 2000]). Damit wurde erstmalig in diesem Umfang Expertenwissen über Heuristiken zur Restrukturierung von bestehendem objektorientiertem (!) Code herausgebracht. Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written. [Fowler et al., 2000] Refactoring fasst viele konkrete objektorientierte Vorgehensweisen zur Verbesserung der Wartbarkeit zusammen. Es wird zum Beispiel von der Eclipse Programmierumgebung im Java Umfeld standardmäßig unterstützt. Auch wenn in der für diese Arbeit zur Verfügung stehenden Zeit kein vollständiges Refactoring nach FOWLER vorgenommen werden konnte, so wurden an der ein oder anderen Stelle diese Prinzipien berücksichtigt. In jedem DEN ENTWICKLUNGSPROZESS MANAGEN 43

57 4.3 ENTWURFSMUSTER Fall ist ein Refactoring des softwaretechnischen Entwurfs bzw. der Implementierung eine bewährte Methode zur Verbesserung der Wartbarkeit und Güte des Systems. Fowler beschreibt in der sogenannten Stink Parade of Bad Smells einige der wichtigsten no good s beim Implementieren objektorientierter Systeme. Dies sind unter anderem duplizierter Code lange Methoden große Klassen lange Parameterlisten und viele mehr. Diese Fehler lassen sich auch als Checkliste für das Erstellen von objektorientierten Systemen lesen. Sie gehen aber grundsätzlich alle auf die ehernen Prinzipien des objektorientierten Entwurfs zurück wie sie - und ihre Macher - in diesem Abschnitt bereits Erwähnung fanden. Grundsätzlich gilt für alle Heuristiken: Ihre Anwendung ohne ein Verständnis der zu Grunde liegenden Entwurfsprinzipien und ohne eine Betrachtung im Kontext der Anwendung führt keineswegs zu besserer Software. 2.3 Fazit Das Ziel des Entwicklungsprozesses soll eine stabile und robuste Anwendung sein. Die objektorientierte Vorgehensweise bietet zahlreiche Prinzipien und Heuristiken, welche erfahrungsgemäß zu wartbaren Anwendungen führen. Bleibt die Frage, an welcher Stelle das Expertenwissen zu suchen ist, welches wir zum Bau grafischer Benutzerschnittstellen benötigen und wie es praktisch in den Entwicklungsprozess integriert werden kann. 3 Entwurfsmuster 3.1 Beschreibung Aktuelle Literatur über den guten softwaretechnischen Entwurf von GUI Oberflächen wird man leider nur selten finden. Wie an anderer Stelle schon gesagt, stammen die meisten grundsätzlichen Arbeiten zu diesem Thema aus der Zeit Mitte der 90er Jahre und sind eng mit der Musterkultur (z.b. [Gamma et al., 1994]) verbunden. Der Begriff Entwurfsmuster (engl. design pattern) geht historisch auf den Architekten Christopher Alexander zurück und wurde eigentlich für die Gebäudearchitektur und Stadtplanung in den 70er Jahren entwickelt. Entwurfsmuster sind eine Form, abstraktes Wissen über die Lösung eines Entwurfproblems zu speichern und es einem breiten Fachpublikum zugänglich zu machen. DEN ENTWICKLUNGSPROZESS MANAGEN 44

58 4.3 ENTWURFSMUSTER Ihre Beschreibung unterliegt einem gebräuchlichen Schema, welche in der folgenden Tabelle zusammengefasst ist (in Klammern stehen die im Englischen verwendeten Begriffe, falls sie nicht mit den Deutschen identisch sind): Name und Klassifikation Zweck (Intent) Synonyme (Also Known As) Motivation Anwendbarkeit (Applicability) Struktur (Structure) Beteiligte Akteure (Participants) Zusammenspiel (Collaborations) Konsequenzen (Consequences) Beispielcode (Sample Code) Praxiseinsatz (Known Uses) Querverweise (Related Patterns) des Musters des Musters Andere bekannte Namen des Musters. (Hinter-)Gründe für den Einsatz des Musters. Einsatzbereiche für das Muster. Beschreibung der allgemeinen Struktur des Musters. Klassen, die an dem Muster beteiligt sind. der beteiligten Klassen. Praxisrelevante Tipps, Tricks und Techniken sowie Warnung vor Fehlern, die leicht passieren könnten. Quellcodefragment, das den Einsatz des Musters zeigt. Wo wird das Muster bereits eingesetzt? Wie spielt das Muster mit anderen Mustern zusammen? Tabelle 4: Beschreibung von klassischen Entwurfsmustern Quelle: [Wikipedia, 2006, Entwurfsmuster], siehe [Gamma et al., 1994], [Buschmann et al., 1996] Autoren von Mustern selbst weisen immer wieder darauf hin, dass das Entwickeln und Anwenden von Musterkonzepten ein kreativer und anforderungszentrierter Prozess ist. Das bedeutet auch, dass diese Methoden nur im praktischen Tun und anhand der Lösung einer konkreten Aufgabe erfahren und erlernt werden können. Zusammengesetzte Muster Die Zusammenfassung mehrerer Muster zu einem komplexen Gesamtsystem nennt man zusammengesetztes Muster. Ein klassisches zusammengesetztes Muster ist das von Kent Beck und Ward Cunningham 1987 entwickelte Model View Controller (MVC) Pattern für die grafische Benutzerschnittstelle von Smalltalk - einer vollständig auf dem Paradigma der Objektorientierung basierenden Programmiersprache. 3.2 Musterkataloge Eine wesentliche Forderung bei der Entwicklung objektorientierter Entwürfe ist Wiederverwendung (engl. reuse). Die Entdeckung und Entwicklung von Mustern brachte schon früh die Notwendigkeit zur Klassifizierung mit sich DEN ENTWICKLUNGSPROZESS MANAGEN 45

59 4.3 ENTWURFSMUSTER Abbildung 7: HCI Pattern von Borchers ([Borchers, 2001]). Quelle: Patterns from the Book borchers/patternindex.html um sie in bestimmte Anwendungsbereiche einordnen zu können. Erich Gamma [Gamma et al., 1994] war einer der ersten, der einen Katalog von Mustern heraus brachte und damit eine solche Klassifizierung vornahm. Es folgten weitere, wie das Buch des Teams um Frank Buschmann bei der deutschen Siemens AG Pattern oriented Software Architecture [Buschmann et al., 1996]. Dies war der Beginn einer Reihe von drei Werken über Software Architektur: Patterns for Concurrent and Networked Objekts und A Pattern Approach to Interaction Design [Borchers, 2001]. 3.3 Mustersprachen Ganze Gruppen von Mustern, die einer eigenen Aufgabedomäne angehören, nennt man Mustersprache (engl. pattern language) HCI (Human Computer Interaction) Es hat sich ein besonderes Teilgebiet der Informatik herausgebildet, welches sich mit der Mensch Computer Interaktion beschäftigt (engl. Human Computer Interaction oder auch HCI, siehe ). Im Rahmen einer Teildisziplin des HCI, dem User Interface Design, haben sich in den letzten Jahren mehr als 250 Muster herausgebildet, welche die Anforderungen von Benutzerschnittstellen modellieren (siehe [Welie and Veer, 2003] und HCI Pattern Page Die Impulse für diese Arbeiten gegen auf verschiedene Bewegungen zur Entwicklung von Mustersprachen zurück. Unter anderem auf die internationalen PLoP Workshops zur Musterfindung: Pattern Languages of Programming (1994, 1996,...,2000, siehe z.b. PLoP Wiki cgi?welcomevisitors). DEN ENTWICKLUNGSPROZESS MANAGEN 46

60 4.3 ENTWURFSMUSTER Das bereits erwähnte Werk von Jan Borchers über Interaction Design war einer der ersten (11) Versuche, die Anforderungen an interaktive Benutzerschnittstellen mit Hilfe einer Mustersprache zu beschreiben. In seinem Artikel Interaction Design Pattern: Twelve Theses geht er sogar soweit zu behaupten, das Design Pattern Buch von [Gamma et al., 1994] enthalte überhaupt keine Muster (siehe [Borchers, 2000, Claim 2]). Er bezieht dabei auf das Publikum, welches Christopher Alexander einst mit Mustern erreichen wollte: Hochqualifizierte Spezialisten nebst Anwendern! Diese Idee, welche in die 90er Jahre zurückgeht (z.b. [Coplien and Schmidt, 1995]) und ihre ehernen Wurzeln bei Christopher Alexander [Alexander et al., 1977] hat, möchte Muster für ein breites Publikum zugänglich machen, besonders für den Nicht-Experten. Auf HCI übertragen fordert er, dass es nicht hochspezialisierten Softwarearchitekten vorbehalten sein darf, über Muster und deren Anwendung zu kommunizieren. Auch normale Entwickler, die nicht über die notwendigen objektorientierten Skills verfügen, sollen sich problemlos über dieses Wissen im Team austauschen können. Bei erstem Durchsehen der verschiedenen HCI Mustersammlungen handelt es sich um High Level Muster, welche im Umfeld grafischer Benutzerschnittstellen immer wieder auftreten. Beispiele dafür sind Simple Search (einfache Suchfunktion z.b. auf einer Webseite) - ausführlich beschrieben in [Acosta and Zambrano, 2004] The Shield (Benutzerdialog zum Fehlermanagement) - [Welie and Veer, 2000] The Wizard (Benutzerführung für die Bewältigung einer komplexeren Aufgabe) - [Welie and Veer, 2000] WELIE verwendet in seinem Artikel über Patterns as Tools for User Interface Design [Welie and Veer, 2000]) eine ähnliche Syntax zur Beschreibung seiner Muster, wie dies für Entwurfsmuster der Fall ist. Wie in Tabelle 5 auf Seite 48 zu sehen ist, werden Implementierungsdetails - wie in der klassischen Musterbeschreibung üblich - nicht aufgeführt. Tabelle 5 auf Seite 48 zeigt den Ansatz zur Beschreibung von Mustern im Kontext grafischer Benutzerschnittstellen (HCI): (11) Es ist schwierig in diesem Bereich von zuerst zu sprechen. Sollte dem Autor bei der Fülle der Werke also ein Fehler unterlaufen sein, so ist er für jeden Hinweis dankbar. DEN ENTWICKLUNGSPROZESS MANAGEN 47

61 4.3 ENTWURFSMUSTER Name, Autor Problem (problem) Prinzip (usability principle) Kontext (context) Konflikte (forces) Lösung (solution) Gebrauchsnutzen (Usability) Beispiele (examples) Bekannte Anwendung (known uses) Verwandte Muster (related patterns) Beschreibt das Problem, dass gelöst werden soll aus der Sicht des Benutzers. Gründet sich auf eine Klassifikation im Rahmen des Interaction Design Beschreibt die Bedingungen unter welchen das Muster Anwendung findet. Listet das Konfliktfeld auf, welches den Benutzer bei der Anwendung der präsentierten Lösung erwartet. Beschreibt in textueller, eventuell in grafischer Form die Lösung des Problems (im Sinne eines Use Case). Beschreibt den Gebrauchsnutzen des Musters aus Sicht der Anwendung durch den Benutzer. Zeigt Beispiele, aber auch Gegenbeispiele zur vorgestellten Lösung. Aufzählung bekannter Anwendungen dieses Musters. Aufzählung verwandter Muster. Tabelle 5: Beschreibung der Struktur von Mustern für Benutzerschnittstellen (Interaction Design), nach [Welie and Troetteberg, 2000] Viele weitere Autoren haben sich diesem Thema gewidmet und zahlreiche Ansätze für die Verwendung von Mustern im Entwicklungsprozess verfolgt. Zwei sollen beispielhaft an dieser Stelle genannt werden. JAVAHERY und SEFFAH schlagen im Rahmen der Entwicklung von Webapplikationen in ihrem Artikel On the Usability of Usability Patterns [Seffah and Javahery, 2002] den Prozess eines Pattern Oriented Design (POD) vor. Dabei werden Muster unter Verwendung eines Werkzeugs - UPADE (Usability Patterns-Assisted Design Environment) - dokumentiert. Dabei wird eine spezielle UML Notation verwendet. Darüber hinaus tragen die Autoren der Forderung von GAMMA [Gamma et al., 1994] Rechnung, dass die Betrachtung der Beziehungen von Mustern untereinander ein Schlüsselelement für das Verständnis und die Benutzung von Mustern darstellt. UPADE definiert daher auch Beziehungen zwischen Mustern. JAVAHERY und SEFFAH haben Befragungen bei Entwicklern durchgeführt und festgestellt, dass diese kaum Probleme haben, gut dokumentierte Muster in Code zu transformieren. Die Entwickler hatten eher Probleme, das selbe Muster mehrere Male auf unterschiedlichen Plattformen zu implementieren. [Seffah and Javahery, 2002] fordern deshalb, dass die Beschreibung von Usability Pattern Implementierungsstrategien für die verbreitetsten Benutzerschnittstellen vorsehen sollte: GUI (PC), Web und Handheld. DEN ENTWICKLUNGSPROZESS MANAGEN 48

62 4.3 ENTWURFSMUSTER Abbildung 8: Pattern-Supported Approach von Granlund, Lafrenière, Carr Quelle: [Granlund et al., 2001] [Granlund et al., 2001] gehen über die reine Dokumentation von HCI Mustern hinaus und stellen ein System zur Integration von Mustern während des gesamten benutzerzentrierten Design- und Entwicklungsprozess eines Produktes vor: den PSA Prozess (Pattern-Supported Approach). Im Rahmen der GUI Design Patterns beziehen Sie sich auf Arbeiten von [Tidwell, 2005]. 3.4 Faktor Implementierung Expertenwissen für den Bau grafischer Benutzerschnittstellen ist sowohl in den klassischen Entwurfsmustern als auch Musterbüchern, sowie in Mustersprachen wie der HCI zu finden. Die Standards im Sinne des HCI Ansatzes für die Entwicklung von grafischen Benutzerschnittstellen sind sehr heterogener Natur. Sie eignen sich als Kommunikationsbasis über Muster für Benutzerschnittstellen und ermöglichen dem Entwickler und Softwarearchitekten anhand einer Klassifizierung eine Einordnung in den Entwicklungsprozess [Granlund et al., 2001]. Es zeigt sich, dass die Hauptschwierigkeiten in der Auswahl von geeigneten Lösungen und im Implementierungsaufwand zu suchen sind, besonders wenn verschiedene Plattformen bedient werden müssen [Seffah and Javahery, 2002]. Es lässt sich anhand von Methoden der Aufwand- und Kostenschätzung (12) leicht zeigen, wie Strukturkomplexität von GUI Anwendungen und Projektaufwand miteinander in Verbindung stehen. Eine wesentlich Metrik zur Beschreibung des Aufwandes sind z.b. bei COCOMO die KDSI (Kilo Delivered Source Instructions) (13), also die Anzahl der niedergeschriebenen Codezeilen eines Programms. (12) z.b. IFPUG oder COCOMO II research/cocomoii/ (13) Quellcode ohne Kommentar- und Dokumentationszeilen, sowie Hilfsroutinen für Programmtests. Gemessen in Einheiten von 1000 Zeilen. DEN ENTWICKLUNGSPROZESS MANAGEN 49

63 4.4 ERNEUTE BESTANDSAUFNAHME COCOMO II, die Anpassung des Verfahrens an aktuelle Softwaretechniken, bezieht an Metriken schon die Anzahl angezeigter Bildschirmmasken als wesentliche Größe in die Aufwandberechnung mit ein (Application Composition Model). Diese werden dann anhand Ihrer Komplexität und Wiederverwendung gewichtet. Wiederverwendung aber ist ein Grundgedanke der Musterkultur. Der Wille zu Komplexitätsreduzierung deren Antrieb. Wir werden auch hier konkret auf Implementierungshürden zurückgeworfen. Diese allein zu identifizieren genügt jedoch nicht, wir müssen die Komplexitätstreiber im Entwicklungsprozess reduzieren. 3.5 Fazit Entwurfsmuster sind eine Möglichkeit, softwaretechnisches Erfahrungswissen verfügbar zu machen. Der Autor sucht nach einer konkreten Strategie, wie dies effizient umgesetzt werden kann. Dazu müssen wir einen Prozess des Musterfindens anwenden, um die Formen (die Muster) innerhalb des Kontext (das Entwurfsproblem) zu identifizieren. HCI Muster setzen eine Schicht darüber an. Sie sind, hat man einmal ein System zur Applikation von Mustern auf das konkrete System erlernt, eine erheblich Rolle bei der Dokumentation und Kommunikation über Muster für grafische Benutzerschnittstellen im Team übernehmen. 4 Erneute Bestandsaufnahme Das bisher Gesagte führt uns schnell wieder auf die konkrete Bewältigung der Aufgabe zurück: das zugrunde liegende Softwaredesign für eine grafischen Benutzerschnittstelle. Diese soll schnell entwickelt werden, sowie eine gute Wartbarkeit des Programms ermöglichen. Dabei soll sie den ersten vier Anforderungen in Tabelle 2 auf Seite 30 genügen: 1. Wartungsfreundlichkeit (a) Designänderungen (b) funktionale Änderungen 2. Erweiterbarkeit (a) Zusätzliche Funktionen (Menüs, Buttons) (b) Zusätzliche Fenster 3. Datenkonsistenz über die Anwendung und verschiedene Fenster hinweg 4. Trennung der Fachlogik von der GUI Logik DEN ENTWICKLUNGSPROZESS MANAGEN 50

64 4.4 ERNEUTE BESTANDSAUFNAHME Alle diese Probleme lassen sich durch konsequente Anwendung von Mustern und objektorientierten Programmierprinzipien lösen. Zumindest verspricht dies die objektorientierte Vorgehensweise. Es ist schwierig zu beschreiben, welchen Weg man gehen muss, um die richtige Mischung von Mustern zu bekommen und zu begründen, an welcher Stelle man welche Entwurfsentscheidung warum getroffen hat. Oft fehlt den Teams die nötige Übung oder Fachkenntnis, um den Prozess des Mustermappings erfolgreich anzuwenden. Folgende Faktoren stellen die Ausgangsbedingungen für unser Vorgehen dar: Konkrete Anforderungen an das Produkt. Anwendung der objektorientierten Programmierprinzipien. Entwurfsmuster zur Vorlage von bereits gelösten Problemen. Machen wir uns also Stück für Stück an Hand der gestellten Anforderungen auf den (Entwurfs)weg. 4.1 Werkzeuge In diesem Abschnitt ist von Programmen die Rede, welche den Programmierer, Designer und Softwarearchitekten helfen sollen, sowohl einen abstrakten Entwurf anzufertigen, sowie dessen Umsetzung in Programmcode durchzuführen. Dies bezieht sich auf die Erstellung und Wartung (!) des Software Entwurfs mit UML, die Programmierung, Wartung (!) und Dokumentation von Code. Es soll auf keinen Fall (!) der Eindruck entstehen, wie auch immer geartete Werkzeuge könnten dem Softwarearchitekten oder Programmierer die Kreativität abnehmen, die zum Entwurf eines Softwaresystems unabdingbar ist (14). Auf der anderen Seite hat der Autor selbst durch Verwendung dieser Tools viel gelernt. Leider haben sich im Laufe der Zeit nur sehr wenige als wirklich produktive und ökonomische Helfer herausgestellt. Frei nach Joe Spolskys Kardinal Axiom [Spolsky, 2001] für das Interface Design, stellt der Autor dieser Arbeit erneut fest: Ein Programmier- oder Softwaretechnik Werkzeug besitzt eine gute Eignung, wenn es sich exakt so verhält, wie der Programmierer und Softwarearchitekt dies anhand ihrer Änderungsanforderungen erwarten und diese bei ihrer Aufgabe, Anwenderprobleme zu lösen nicht behindert. (14) Geben Sie zu, diese Überschrift stand beim Durchblättern mit an erster Stelle. DEN ENTWICKLUNGSPROZESS MANAGEN 51

65 4.4 ERNEUTE BESTANDSAUFNAHME GUI Builder Was braucht man zum Entwickeln wartbarer grafischer Oberflächen? Einen GUI Builder? Grundsätzlich kann man diese Antwort mit Ja beantworten. Anhand einer GUI lässt sich manches besser zeigen. Screendiagramme (15) sind eine gute Art und Weise mit dem Kunden durch zusprechen, was machbar ist und frühzeitig zukünftige Kundenanforderungen abzuklopfen. Für diesen Zweck sind diese Instrumente auch hervorragend geeignet. Wenn Sie sich auf die Suche nach Literatur zum Thema GUI Builder machen, dann finden sie zu 95% Beschreibungen über die Funktionsvielfalt von GUI Buildern: HowTo s wie man mit diesen Werkzeugen umgeht, wohin man Klicken muss um Elemente auf der Arbeitsoberfläche zu platzieren, welche Elemente in welche geschachtelt werden dürfen u.s.w.... Funktionsbeschreibungen. Vorweg dürfte eine Faustregel für den Umgang mit GUI Buildern gelten: Sind sie mit dem produzierten Ergebnissen ihres Werkzeugs zufrieden, so bleiben Sie dabei. Sind sie nicht zufrieden, dann haben Sie bereits entsprechende Erfahrungen gemacht, kennen entweder nun doch endlich die Funktionszusammenhänge Ihres GUI Frameworks und werden für neue größere Projekte einen großen Bogen darum machen, oder haben noch nicht das Richtige gefunden. Probieren Sie aus! Alle namhaften Hersteller bieten Downloadversionen ihrer Produkte an. Ein wichtiger Aspekt, der sehr oft vernachlässigt wird ist das Testen (auch der Autor macht - dem Umfang der Arbeit wegen - keine Ausnahme). Mit GUI Builder erzeugter Code schafft meist starke Bindungen zwischen UI Code und Fachlogik. Er erschwert damit das Testen der Fachlogik, da die Ausgabe auf GUI Elemente beschränkt bleibt. Es gibt zwar Werkzeuge zum Testen von GUI s, diese sind jedoch meist sehr teuer und aufwendig in der Einrichtung für das spezielle GUI Problem. Sie sollten Ihren GUI Builder Code immer so designen, dass sie die Fachklassen jederzeit ohne die GUI testen können. Das Testen einzelner Fachklassen ist viel einfacher durchzuführen und auch zu automatisieren, als das Testen von GUIs Softwarentwurf mit UML Die Menge an Design Werkzeugen für die Unified Modeling Language (UML) ist in den letzten Jahren stark angewachsen. Je nach Hersteller integrieren sich diese Werkzeuge zum Teil in vorhandene Entwicklungsumgebungen. Nach den Erfahrungen des Autors ist dies jedoch nicht zwingend nötig. Um wirklich produktiv zwischen Entwurf und Programmierung im Code hin und her wechseln zu können sollten folgende Möglichkeiten genutzt werden können: (15) Screenshots werden zum Aufzeigen der Funktionen des Anwendungsprogramms benutzt, ähnlich wie in einem Zustandsdiagramms. DEN ENTWICKLUNGSPROZESS MANAGEN 52

66 4.4 ERNEUTE BESTANDSAUFNAHME 1. Reverse Engineering von Source Code 2. Generierung von Quellcode 3. 1 & 2 zusammen: Roundtrip Engineering genannt 4. Export/Import des Modells im XMI Format Mit Reverse Engineering ist hier das Erstellen einer UML Repräsentation des importiertem Quellcode gemeint. So kann man bereits gelöste Probleme visualisieren, leichter verstehen und auf andere Programmiersprachen übertragen. Die Quellcodegenerierung ermöglicht, aus UML Modellen Code für verschiedene Programmiersprachen zu erzeugen. Meist ist sie um komfortable Dokumentationsfunktionen bereichert. Roundtrip Engineering ermöglicht das Importieren von geändertem Quellcodes in und die Erzeugung von Quellcode aus dem dem UML Modell. Eine sehr schöne, aber optionale Funktion ist die Generierung von Code aus Sequenzdiagrammen heraus, wobei dies in der Programmierpraxis eher selten vorkommt. Doch Vorsicht, auch hier sollte man genau prüfen, nach welcher Methode das Werkzeug den UML Entwurf umsetzt. Es gelten dieselben Aussagen, wie für alle Generierungstools: kenne deren Arbeitsweise. XMI (XML Metadata Interchange) Export- und Importfunktionen ermöglichen den standardisierten Austausch des UML Modells mit anderen UML Werkzeugen Entwicklungsumgebung Eine IDE (Integrated Development Environment) ist für viele Entwickler der Dreh- und Angelpunkt. Eine Entwicklungsumgebung sollte die folgenden Aufgaben unterstützen: 1. Refactoring 2. Testen 3. Teamarbeit / Versionierung 4. Dokumentation Dabei spielt es keine Rolle, wie die Umsetzung im Einzelnen geschieht. Es gilt: halten sie sich an Standards. Mehrere gut standardisierte Werkzeuge, die ausgereifte Konsolenprogramme verwenden sind wertvoller, als ein All- In-One-Tool, welches Sie auf eine bestimmte, vielleicht sogar proprietäre Arbeitsweise oder Formate festlegt. DEN ENTWICKLUNGSPROZESS MANAGEN 53

67 4.4 ERNEUTE BESTANDSAUFNAHME Anforderung Generelles Vorgehen - Zielorientierung - Was brauchen wir? Designänderungen sollen einfach möglich sein Funktionale Änderungen Zusätzliche Funktionen (Menüs, Buttons) Zusätzliche Fenster Datenkonsistenz Trennung von Fachlogik und GUI Auslagern des GUI Codes in eine Klasse, die locker mit der GUI Logik (Funktionalität) verbunden ist. Kapseln der Funktionen an zentraler Stelle. Ganzes / Teil - Beziehung modellieren Methoden / Klassen, die die Erstellung von Fenstern kapseln Daten an zentraler Stelle lagern und in Fenster auf diese referenzieren. GUI referenziert Fachlogik Aufkommende Fragen dazu? Wie und wann geschieht der Datenabgleich? Tabelle 6: Erste Überlegungen zur Anwendung von Mustern auf gegebene Anforderungen. 4.2 Vorgehen Um die Besteigung des Projektberges etwas übersichtlicher zu gestalten, zeigt Tabelle 6 auf Seite 54, wie man in einem ersten Schritt ganz pragmatisch an den Entwurf herangehen kann, ohne sich dabei schon auf spezielle Muster festzulegen. Dabei verwendet man wesentliche Prinzipien des objektorientierten Entwurfs (welche nicht primäres Thema dieser Arbeit sind). Dann erst sollte man - etwas Übung vorausgesetzt - nach Mustern suchen, die den gestellten Anforderungen entsprechen könnten. Tabelle 7 auf der nächsten Seite zeigt, wie nach der Lektüre Ihrer Musterbibliothek konkrete Muster zugeordnet werden könnten. Doch wie gelang man dort hin? Der Autor greift an dieser Stelle etwas vor, da wir erst im nächsten Abschnitt auf Seite 56 eine Methode vorstellen werden, wie man diese Muster praktischer weise identifiziert. Dieses zweischrittige Vorgehen empfiehlt sich, da ansonsten leicht eine bereits vorhandene Lösung übersehen werden kann oder man vielleicht den Bezugsrahmen zum eigenen Projekt verliert und Lösungen verwendet, die schlicht zu umfangreich sind. So gelingt es, die Anforderungen auf eine geringst mögliche Anzahl konkreter Muster abzubilden, ohne dabei den Kontext aus dem Auge zu verlieren. In welcher Reihenfolge Sie die vorgenommenen Probleme angehen, hängt von Ihrem persönlichen Geschmack - Topdown, BottomUp, ihrem Team - der Designer ist noch 2 Tage in Urlaub, der Programmierer aber schon da - und DEN ENTWICKLUNGSPROZESS MANAGEN 54

68 4.4 ERNEUTE BESTANDSAUFNAHME Designänderungen Muster Bei der Realisierung auftauchende Fragen Funktionale Änderungen Command, Action(Template) Wie werden Events dabei behandelt? An vielen Stellen redundanter Aufruf. Zusätzliche Funktionen Composite (Menüs, Buttons) Zusätzliche Fenster CreationalPatterns Datenkonsistenz Observer Trennung von Fachlogik und GUI MVC, PresentationController Tabelle 7: Erste Überlegungen zur Anwendung von Mustern auf gegebene Anforderungen. natürlich dem Projektplan ab. Es ist natürlich immer sinnvoll, zuerst kleinere, klar abgrenzbare Einheiten anzugehen. Da wir vorhaben ein System zu entwickeln, dass nach den Grundregeln der losen Kopplung zwischen den Hauptteilen gebaut ist - also darauf achten, dass die Einzelkomponenten nicht zu sehr voneinander abhängen, stört es uns nicht, das der Designer noch nicht da ist. Wir nutzten die Zeit und überlegen, wie wir den GUI Code vom Design abkoppeln können. Vorher müssen wir uns jedoch in einem Abschnitt mit dem Mapping von klassischen Entwurfsmustern auf unsere Anwendung beschäftigen. DEN ENTWICKLUNGSPROZESS MANAGEN 55

69 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN 5 Klassische Entwurfsmuster identifizieren Die klassischen Entwurfsmuster dürfen als bekannt, gut dokumentiert und zugänglich vorausgesetzt werden. Sie bilden neben den Anforderungen die Ausgangsbasis für die Erstellung des softwaretechnischen Entwurfs. 5.1 Mustermapping Stellen Sie sich vor, Sie müssen in einem Team von Entwicklern - ausgestattet mit Musterbüchern, dem Internet und vielleicht einer firmeninternen Dokumentation - konkrete Anforderungen an ein Programm umsetzen. Die folgende Vorgehensweise soll Ihnen dabei helfen: 1. Feststellen der eigenen Anforderungen. 2. Sammeln aller Informationen aus Musterbüchern anhand [1.]. 3. Anwendung auf das eigene Problem. 4. Testen und Einordnen in den Gesamtkonzept des Programms. 5. Dokumentation. 6. Festlegen des weiteren Vorgehens.. Anforderungen In jedem Fall muss der Kontext, in dem die gewünschte Funktion softwaretechnisch gelöst werden soll hier nochmals aufgeführt werden. Dazu sollte man wenige konkrete Anwendungsfälle formulieren, die in einem Prototypen umgesetzt werden können. Die Anforderungen sollten daher so minimal, wie möglich sein. Dies setzt in der Regel Erfahrung und/oder gezielte Vorbereitung beim Leiter der Sitzung voraus! Auch hier ist es möglich, die Gruppe zu befragen, oder mit Hilfe von Karteikarten (CRC - [Ambler, 1998, Beck and Cunningham, 1989]) zu arbeiten, um Vorschläge zu sammeln und anschließend in einer kurzen Abstimmungsrunde auszuwerten. Sie können dabei ähnlich mehrschrittig vorgehen, wie dies im letzten Kapitel gezeigt wurde. Abbildung 9: Mustermapping 1. Anforderungserfassung Nun können die Musterbücher durchsucht werden. Hierbei sollte man verschiedene Quellen benutzen, um so viele Optionen wie möglich für ein Muster zu erfassen. Eventuell kommen auch mehrere Muster in Betracht. Für das Informationssammlung DEN ENTWICKLUNGSPROZESS MANAGEN 56

70 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Vorgehen im Team können hierbei bewährte Methoden zum Tragen kommen: Ein Schwarzweiß Kopierer liefert die Möglichkeit zum Sammeln von Informationen. Ein Scanner und Laserdrucker erfüllen natürlich denselben Zweck. Wir benötigen keine hoch aufgelösten Grafiken. Eine Weißtafel, ein großer Flipchart Block, ein großer Tisch, sowie die nötigen Beschriftungsmaterialien zum Hervorheben von Text, Scheren und Klebestifte sind obligatorisch. Die Ergebnisse müssen für alle Beteiligten gut zugänglich sein, man hängt Sie am Besten an eine gut zugängliche Wand. Auf diese Weise erhält man im Laufe der Zeit ein eigenes Musterarchiv, dass immer wieder für Projekte wiederverwendet werden kann. Eine Einteilung in 2er oder 3er Teams bei mehreren Anwesenden ist sinnvoll. Ihre Aufgabe: Muster identifizieren, die zur Lösung des gestellten Problems dienlich sind und diese anschließend übersichtlich darzustellen. Bei der Suche nach relevanten Textteilen in den Musterarchiven sollte man sowohl die Anforderung, als auch die Fragestellungen hinzuziehen, welche man sich während der Vorüberlegungen bereits notiert hat. Wir vergleichen die uns aus Musterbüchern oder andern Quellen vorliegenden Beschreibungen und vergleichen Sie mit unseren Anforderungen. Quellenangaben sind für jede Kopie beizufügen. Sind die Anforderungen komplexer, so ist es möglich, ähnlich wie bei der objektorientierten Domänenanalyse vorzugehen und die Textanalyse nach Russel J. Abbott anzuwenden (von Grady Booch 1983 popularisiert): siehe Abschnitt 10 auf Seite 104. Auch Erfahrungen und/oder Bedenken der Teammitglieder sollten in diesen Teil notiert werden. Jeder Hinweis kann später hilfreich sein, die weitere Vorgehensweise festzulegen oder frühzeitig Gefahren oder Sackgassen zu erkennen. Da das Book of Design Pattern [Gamma et al., 1994] dem Autor nur in englischer Sprache vorlag, hat er relevante Textteile für diese Arbeit selbst frei übersetzt. In den wenigsten Teams wird es möglich sein, jedwede Form von Fachliteratur in der Muttersprache der Entwickler vor zuhalten. Man muss sich deshalb vor Sitzungsbeginn auf eine Sprache einigen und diese Entscheidung dann nicht mehr ändern. DEN ENTWICKLUNGSPROZESS MANAGEN 57

71 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Abbildung 10: Mustermapping 2. Extraktion Adaptieren und Implementieren Anwendung auf das eigene Problem. Dies geschieht in der Regel durch Modellierung und anschließende Kodierung. Ein Laptop mit Beamer, eine Pairprogramming Situation, wie beim Extreme Programming [Beck and Fowler, 2000] oder ein Laptop mit entspiegelter Anzeige und hellem Weitwinkeldisplay können wertvolle Partner sein. Dazu gehört auch eine schnurlose Tastatur und Maus. Entscheidend ist das vorherige Modellieren des gegebenen UML Schemas und die Adaption an das eigene Problem. Der Autor selbst arbeitet dabei immer vom Modell zum Code. Wenn die Entwicklungsumgebung besondere Funktionen zum Refactoring zur Verfügung stellt, die denjenigen des UML Werkzeugs überlegen ist, sollte man diese vorziehen. Hat man sich auf ein Muster geeinigt, sollte man an dieser Stelle die Teammitglieder zu Paaren an die Rechner entsenden, wobei der eine immer die Programmierrolle, der andere die des Führenden übernimmt. Jeweils abwechselnd (siehe [Beck and Fowler, 2000]). Dabei ist es möglich, erst mehrere Muster identifizieren, anschließend getrennt in die Kodierungsphase gehen. Für sehr anspruchsvolle Aufgaben kann es auch nötig sein, mehrere Programmierteams mit je demselben Muster los zusenden um die geeignete Lösung festzustellen. Die Kodierungszeit sollte dabei auf eine genaue Zeitspanne festgelegt werden. DEN ENTWICKLUNGSPROZESS MANAGEN 58

72 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Abbildung 11: Mustermapping 3. Adaption Testen Dokumentation Testen kann auf vielfältige Weise geschehen. Es sollte jedoch unter keinen Umständen vergessen werden. Softwaretests sind zwar nicht Teil dieser Arbeit, der Autor möchte in diesem Kontext aber zwei Methoden erwähnen: Kennt man die Endbedingungen sehr genau, können z.b. Unit Tests (XUnit) eine sinnvolle Vorgehensweise sein, schon beim Programmieren, den Code zu Testen: siehe Abschnitt 10 auf Seite 104. Aber auch das einfache Erstellen eines Prototypen ohne Unittest macht oft Sinn. Man kann einfache Testklassen erstellen, die gegen den Prototypen getestet werden. Dadurch werden offensichtliche Fehler meist schnell gefunden. Allgemein gilt: Die Prototypen sollten die Testsituation im Kontext der späteren Verwendung abbilden (16). Der Prototyp wird dann im nächsten Schritt der gemeinsamen Betrachtung vorgelegt. Ist man alleine, sollte man sich eine ausgiebige Pause gönnen (nicht am Rechner). Die Dokumentation zur Entwurfsentscheidung sollte in Form von UML- Diagrammen erfolgen (alle Diagrammformen möglich). Alle coderelevanten Entscheidungen nimmt man mit Hilfe einer geeigneten Kennzeichnung zur späteren Auswertung direkt im Code vor (z.b. Javadoc). Weitere Dokumentationen sind in der Regel nicht sinnvoll, denn es handelt sich hier nur um einen Zwischenschritt zur späteren Anwendung. Abbildung 12: Mustermapping 5. Dokumentation Gemeinsame Begutachtung In der Regel wird man an dieser Stelle den bisherigen Vorgang gemeinsam (16) Zum Beispiel: Das Testen auf eine in der Anforderung geforderte Fließkommazahl in der GUI sollte nicht mit ganzzahligen Werten erfolgen. DEN ENTWICKLUNGSPROZESS MANAGEN 59

73 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN begutachten. Die Prototypen werden vorgestellt, kritisch von allen befragt, eventuell Tests hinzugefügt. Wurden die Ziele erreicht? Ist die Implementierung hinreichend? Laufen die Tests durch? Hat man sich im Vorfeld Fragen bei der Zielorientierung gestellt, ist hier der Punkt diese nochmals zu erörtern, um sie in die nächste Phase mitzunehmen. Diese Prozedur kann z.b. nach den Regeln von Reviews ablaufen. Anschließend entscheidet man sich gemeinsam für eine Lösung und dokumentiert die Ergebnisse. Schlussendlich sollte man die nächste zu adressierende Anforderung festlegen. Gibt es Nebenbedingungen, die zu beachten sind? Diese Fragen sollte man einer Tabelle aufschreiben, den Status dokumentieren, die einzelnen Schritte priorisieren, Verantwortlichkeiten zuweisen sowie Termine für deren Bearbeitungsdauer notieren. Abbildung 13: Mustermapping 6. Review Der Prozess kann nun von vorne beginnen, bis alle Anforderungen durchlaufen wurden. Eine Gesamtgrafik zum Prozess finden Sie im Anhang Kapitel 6 auf Seite Mappingbeispiel: Command Der Autor möchte am Beispiel des Command Musters zeigen, wie man diese Methode beim Mapping der Anforderungen auf Muster verwenden kann. Wir werden uns dabei auf die allgemein übliche Beschreibung von Mustern stützen (siehe Seite 45). Nicht alle Punkte der Musterbeschreibung sind jedoch in einer ersten Analyse immer von Bedeutung. Wir werden auch sehen, wie man mit Problemen, die sich als im ersten Durchlauf nicht lösen lassen, verfahren kann. Das erste Team hat folgende erste Anforderung mit auf den Weg bekommen: Anforderung 1 Kapseln der Funktionen an zentraler Stelle. DEN ENTWICKLUNGSPROZESS MANAGEN 60

74 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Kontext: Benutzeraktionen innerhalb der GUI sollen zentralisiert werden. Das Muster soll uns dabei helfen, Programm übergreifend immer wieder verwendete Prozeduren in einem Objekt zu kapseln Anwendungsfälle: 1. Der Benutzer klickt auf den Exit-Button und die Anwendung schließt sich. 2. Der Benutzer klickt auf den Fenster öffnen Button und ein neues Anwendungsfenster öffnet sich. Die Informationsleiste (statusline) gibt eine kurze Information aus. 3. Der Benutzer hat die Möglichkeit für 1. und 2. aus einem Menü, einer Toolbar und einem Button auszuwählen. 4. Der Benutzer findet ein Textfeld vor mit dem Inhalt: Name Vorname. Er soll diesen Test verbessern, und anschließend auf einen Speichern Knopf drücken. Beim Drücken diese Knopfes soll der verbesserte Text in einem Label darunter zusätzlich angezeigt werden. Ein Rückgängig - Knopf soll den Inhalt des Textfeldes zurücksetzen. Dies soll bis zu 10 mal hintereinander durchgeführt werden können Informationssammlung Das Team hat auf Grund der Begriffe Funktion, kapseln, zentral und (Benutzer)Aktion das Command Muster als viel versprechenden Kandidaten auserkoren. Diese Informationssammlung sollte für alle Teammitglieder gut sichtbar (z.b. Flipchartblock) für jedes Muster einzeln erstellt werden. Schlüsselbegriffe sollten dabei hervorgehoben werden. Es folgt eine beispielhafte Zusammenfassung einer Recherche: Zweck Kapselt einen Auftrag als ein Objekt und ermöglicht es so, andere Objekte mit verschiedenen Aufträgen zu parametrisieren, Aufträge in Warteschlangen einzureihen oder zu protokollieren oder das Rückgängig machen von Operationen zu unterstützen [Freeman et al., 2006]. [...] das Command Pattern leitet eine Anfrage an ein spezielles Modul weiter. Es kapselt diese Anfrage für eine spezifische Aktion innerhalb eines Objektes und stellt es einem bekannten Publikum zu Verfügung [Cooper, 1998]. Synonyme: Aktion, Transaktion [Gamma et al., 1994]. Motivation: Anfragen in Objekte kapseln, ohne das der Aufrufer oder Empfänger etwas über deren Inhalt weiß. Beispielsweise besitzen UI Toolkits Objekte, wie Buttons und Menüs, die eine Anfrage des Benutzers beantworten. Das Toolkit kann diese Anfrage nicht im Button oder Menü implementieren, weil nur Applikationen, die dieses Toolkit verwenden wissen können, was mit welchem Objekt geschehen soll [Gamma et al., 1994]. [...] Wenn Sie Java Benutzerschnittstellen anfertigen, dann stellen Sie Menüelemente, Buttons, Checkboxen und so fort zur Verfügung... [Cooper, 1998]. Anwendbarkeit: siehe Zweck. DEN ENTWICKLUNGSPROZESS MANAGEN 61

75 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Struktur: [Gamma et al., 1994, Pattern CD] [Freeman et al., 2006] Beteiligte Akteure: Command = Befehl: deklariert die Schnittstelle, um eine Operation auszuführen. ConcreteCommand = konkreter Befehl: definiert die Bindung zwischen Empfängerobjekt und einer Aktion; implementiert execute(), in dem er die korrespondierende Funktion auf dem Empfänger aufruft, Client = die Applikation: erzeugt ein konkretes Befehlsobjekt, Invoker = Aufrufer - z.b. ein Menüelement: richtet die Anfrage an den Befehl, seine Befehlsfunkion - execute() - auszuführen.), Receiver =Empfängerapplikation: weiß, wie eine konkrete Operation durchzuführen ist, die von der Anfrage ausgelöst wird. Jede Klasse kann als Empfänger fungieren. Zusammenspiel Der Klient erzeugt ein konkretes Befehlsobjekt und spezifiziert den Empfänger. Der Aufrufer speichert das konkrete Befehlsobjekt. Der Aufrufer erzeugt eine Anfrage, indem er die ausführen Methode (execute() oder run()) auf dem Befehlsobjekt ausführt. Im Bild wird anschaulich dargestellt, wie das Befehlsobjekt den Aufrufer vom Empfänger entkoppelt. DEN ENTWICKLUNGSPROZESS MANAGEN 62

76 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Quelle: [Gamma et al., 1994, Pattern CD] Konsequenzen: Das Befehlsobjekt entkoppelt das Objekt, welches den Aufruf erzeugt, von demjenigen, das weiß, wie dies zu geschehen hat. Befehle können manipuliert und abgeleitet werden, wie jedes andere Objekt. Man kann Befehle in einem Kompositum (Composite) Befehl einsetzen. Siehe Composite. Man kann einfach neue Befehle hinzufügen, weil man keine existierenden Klassen ändern muss. Implementierung und Beispielcode: An dieser Stelle sollte eine Sammlung von Beispielcode stehen. Es ist sinnvoll, Code der verwendeten Programmiersprache zu suchen. Andernfalls genügen auch Codeschnipsel anderer Sprachen. Praxiseinsatz: dito Querverweise: dito Anwenden auf das eigene Problem Das Muster muss nun kreativ auf die eigene Domäne übertragen werden. Sie sollten in jedem Fall zuerst in der UML Beschreibung die beteiligten Akteure (Klassennamen) den beteiligten Klassen der konkreten Anwendung zuzuordnen. Dabei sollen die tatsächlichen Begriffe der Anwendungsdomäne verwendet werden [Booch, 1994]. Noch wird also kein Quellcode geschrieben. Die Gefahr bestünde sonst, dass man sich zu sehr mit Schreiben und Ändern von Code aufhält, und dabei der Lerneffekt ausschließlich auf den Programmierer beschränkt bleibt. Abstraktes Denken soll geschult werden. Sowohl bei der Zuordnung von Klassennamen, als auch bei deren Dokumentation muss man sich einigen, welche Sprache zum Einsatz kommt. Da Objektorientierte Bezeichnungen so nah wie möglich an der Domäne sein sollen, aber gleichzeitig von allen verstanden werden müssen, einigt man sich am besten übergreifend auf die englische Sprache. Dies ist natürlich nicht zwingend notwendig, in der Open Source Gemeinde zum Beispiel aber obligatorisch. Der Autor hat in seiner Übersicht deutsche und englische Quellen gemischt. Auch dies ist möglich (und sinnvoll, weil pragmatisch und schnell). DEN ENTWICKLUNGSPROZESS MANAGEN 63

77 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Anwendungsfall 1 Der Benutzer klickt auf den Exit-Button und die Anwendung schließt sich. Für den Kontext der Anwendung heißt das: Wir verwenden das SWT/JFace Framework zur Bildung von Anwendungsfenstern. Der Client ist eine Fensteranwendung (ApplicationWindow): nennen wir es StartView. Command ist eine abstrakte Klasse. ConcreteCommand ist ein von Command abgeleitetes Objekt, dass eine Referenz auf Receiver enthält. Invoker ist der Button, welcher den konkreten Befehl kapselt. Reiceiver ist in unserem Fall die eigene Applikation. Nun, unschwer lässt sich damit folgendes UML Diagramm entwickeln. Wir taufen dabei die execute() Methode um in run(): Abbildung 14: Command Klasse für Prototyp 1 Das Team hat nun die Klassen in Java umgeschrieben. Dabei sind einige Feststellungen zu treffen. Werfen wir also einen Blick auf den Code. Hier, und in allen weiteren Codebeispielen sind der Übersichtlichkeit wegen alle Importanweisungen weggelassen. Auch hier kodieren wir nur das wirklich für die Umsetzung der Aufgabe Nötige. Wir treffen die Entscheidung auf eine Schnittstelle zu implementieren und schaffen das Java Interface Command. Dabei hat das Team festgestellt, dass es für die Implementierung einer Exit Funktion wichtig ist, dass diese eine Referenz auf das aktuelle Fenster benötigt, um darauf die close() Methode auszuführen. DEN ENTWICKLUNGSPROZESS MANAGEN 64

78 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN public c l a s s CommandExitWindow implements Command { ApplicationWindow view ; CommandExitWindow ( ApplicationWindow aview ) { t h i s. view = aview ; / / TODO t e s t i f null, / / TODO e v t. add method / / s e t A p p l i c a t i o n W i n d o w ( aview ) / / i n s t e a d o f C o n s t r u c t o r ( aview ) } public void run ( ) { view. c l o s e ( ) ; } Programmcode 4.1: Konkrete Command Klasse public c l a s s StartView extends ApplicationWindow { Command commandexitwindow ; public StartView ( ) { super ( null ) ; commandexitwindow = new CommandExitWindow ( t h i s ) ; } public Control createcontents ( Composite parent ) { / /... c r e a t e a group e l e m e n t... Button bexitwindow = new Button ( group, SWT.NONE) ; bexitwindow. addmouselistener ( new MouseAdapter ( ) { } ) ; public void mousedown( MouseEvent e ) { commandexitwindow. run ( ) ; return parent ; } } Programmcode 4.2: JFace/SWT - Erzeugen eines Applikationsfensters mit Button. DEN ENTWICKLUNGSPROZESS MANAGEN 65

79 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Welche zusätzlichen Probleme haben sich ergeben? Es ist wichtig, zu beachten auf welche Objekte das Command Objekt Zugriff haben muss, damit es den den Empfängerbefehl auch ausführen kann. Dies schafft für den Anwendungsfall Schließen eines Anwendungsfensters eine zusätzliche Abhängigkeit. Wir müssen dem Button ein Fensterobjekt mitgeben. Alternativ könnte dies auch durch eine Methode setappwindow(applicationwindow) geschehen und in der run() Methode auf das Vorhandensein (==null) des Objektes getestet werden. Dies ist eine reine Entwurfsentscheidung. Notieren Sie diese Entscheidung im Quelltext eventuell mit einer TODO Marke. Anwendungsfall 2 Der Benutzer klickt auf den "Fenster öffnen" Button und ein neues Anwendungsfenster öffnet sich. Die Informationsleiste (statusline) gibt eine kurze Information aus. (17) Diese Anforderungen lassen sich mit JFace scheinbar sehr einfach umsetzen. Zuerst das Fenster mit Statuszeile: public c l a s s StartView extends ApplicationWindow { Command commandexitprogram ; StatusLineManager status_line_manager ; public StartView ( ) { / /... commandexitprogram = new CommandExitProgram ( t h i s ) ; status_line_manager = new StatusLineManager ( ) ; } public Control createcontents ( Composite parent ) { / /... addstatusline ( ) ; } } protected StatusLineManager createstatuslinemanager ( ) { return status_line_manager ; } Programmcode 4.3: JFace - Erzeugen einer Informationsleiste. Eine neue Command Klasse muss erstellt werden. Diese setzt die Erstellung einer neuen Fensterklasse AnotherView voraus: An dieser Stelle kommen wir vorläufig nicht weiter, da wir nicht wissen, wie wir den StatusLineManager zu einer Nachricht in der Statuszeile veranlassen. (17) Sieh z.b. Abbildung 15 auf Seite 72 DEN ENTWICKLUNGSPROZESS MANAGEN 66

80 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN public c l a s s CommandExitWindow implements Command { / /... public void run ( ) { AnotherView anotherview = new anotherview ( ) ; View. paint ( ) ; / / TODO How t o c a l l t h e s t a t u s _ l i n e _ m a n a g e r from h e r e? / / Giving t h e c o n s t r u c t o r t h e o b j e c t w i l l make no / / s e n s e c a u s e i t has no f u n c t i o n t o s e t a message! } Programmcode 4.4: Öffnen eines neuen Fensters Welche zusätzlichen Probleme haben sich ergeben? Das Hinzufügen eines StatusLineManagers erfordert die Erstellung einer create Methode, die automatisch von der Superklasse aufgerufen wird. Das Team stellt fest, dass die Verwendung der StatusLineManager Klasse mehr Wissen über das Framework erfordert. Das StatusLineManager Objekt besitzt keine Methode, die es erlauben würde, direkt eine Mitteilung an die Statuszeile zu senden. Sie sollten sich nicht zu lange an diesen ungelösten Aufgaben aufhalten. Das Problem muss jedoch dokumentiert und im Sourcecode markiert werden (// TODO ). Anwendungsfall 3 Der Benutzer hat die Möglichkeit für 1. und 2. aus einem Menü, einer Toolbar und einem Button auszuwählen. Das Hinzufügen eines Menüs gestaltet sich in JFace relativ einfach, jedoch das Setzen der Parameter für ein Menüelement erscheint ungewöhnlich: Auch hier kommen wir vorerst nicht weiter. Es fehlen die sonst üblichen Methoden, um beliebige Objekte einem Menü bzw. einer Toolbar hinzuzufügen, bzw. diese zu benennen. Man stelle das Problem zurück und dokumentiere: Welche zusätzlichen Probleme haben sich ergeben? Die Methode add() des MenuManager erwartet ein Objekt vom Typ IAction, das nicht bekannt ist. Interessanterweise enthält das IAction eine run() Methode, was ein Commandmuster erhoffen lässt. Wir hatten an erwartet, für die jeweilige Toolbar und Menübar eigene Objekte und Listener instantiieren zu müssen wie dies bei anderen Frameworks der Fall ist. Anwendungsfall 4 DEN ENTWICKLUNGSPROZESS MANAGEN 67

81 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN public c l a s s StartView extends ApplicationWindow { MenuManager main_menu ; / /... in c r e a t e C o n t e n t s (... ) MenuManager menu = new MenuManager ( TitleOfMenu ) ; main_menu. add (menu ) ; / / menu. add ( / / TODO e x p e c t s I A c t i o n / / ) ; / /... protected MenuManager createmenumanager ( ) { main_menu = new MenuManager ( null ) ; return main_menu ; Programmcode 4.5: JFace - Erzeugen einer Menübar. Der Code zur Erzeugung einer Toolbar ist fast identisch und wurde der Übersichtlichkeit halber hier weggelassen. Der Benutzer findet ein Textfeld vor mit dem Inhalt: Name Vorname. Er soll diesen Test verbessern, und anschließend auf einen Speichern Knopf drücken. Beim Drücken diese Knopfes soll der verbesserte Text in einem Label darunter zusätzlich angezeigt werden. Ein Rückgängig - Knopf soll sowohl den Inhalt des Textfeldes als auch des Labels zurücksetzen. Dies soll bis zu 10 mal hintereinander durchgeführt werden können. Sowohl bei [Gamma et al., 1994] als auch bei [Freeman et al., 2006] finden wir Hinweise, dass das Command Muster zur Implementierung von Makrobefehlen bzw. einer Rückgängigfunktion benutzen kann. Dies geschieht durch Hinzufügen eines Zustands (state) zur Befehlsklasse. Auch hier erreichen wir einen Punkt, an dem wir für das konkrete Problem, Textänderungen zu speichern, mehr recherchieren müssen. Wir dokumentieren: Welche zusätzlichen Probleme haben sich ergeben? Wie konkret setzt man eine Rückgängig Funktionalität um? Mustersprachen wie HCI oder weitere Literatur müssen an dieser Stelle mit einbezogen werden (siehe Unterabschnitt 3.3 auf Seite 46). (Hinweis: Wir werden die Anforderung 4 im Rahmen der Arbeit nicht mehr weiter verfolgen) Testen und Einordnen Nun testen Sie die einzelnen Prototypen, ob sie das gewünschte Verhalten zeigen. Nicht erfolgte Umsetzungen müssen mit Begründung dokumentiert werden. DEN ENTWICKLUNGSPROZESS MANAGEN 68

82 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Dokumentation Für jedes Muster müssen im Rahmen des Gesamtkontext die aufgetauchten Fragen dokumentiert werden. Dies dient ihnen im weiteren Verlauf auch als Wegweiser für die Projektorganisation. Es spielt auch eine erhebliche Rolle, um eventuellen Beziehungen zu anderen Mustern auf die Spur zu kommen. Die folgende Tabelle zeigt, wie dies aussehen kann: Anforderung No. 1 - Funktionale Änderungen Lösungsbeschreibung Command Muster Bei der Realisierung auftauchende Fragen Wie werden Events dabei behandelt?: Eventbehandlung je Element. 2 Erwartet wurde: An vielen Stellen redundanter Aufruf von Command Objekten. Je Menübutton, Toolbarbutton, sonstg. Elemente. Aber: Einfügen in JFace- Menü erfordert Benutzung des Interface IAction. Das Framework muss auf das Verhältnis der Klassen hin untersucht werden. 3 Wie wird eine Rückgängig Funktion für die String Behandlung umgesetzt (Textfeld). 4 Wie wird eine anwendungsübergreifenden Rückgängig Funktion umgesetzt? 5 Wie erzeugt man eine Statusmeldung in der Informationsleiste Status gelöst offen 1 offen 2 offen 3 offen 4 Priorität... Tabelle 8: Dokumentation zum ersten Musterdurchlauf Hinweise zur Dokumentationsform Die hier gezeigten Tabellen sind auf das in unserem Zusammenhang Wesentliche reduziert. Im realen Projekt muss diese Tabelle natürlich mit Daten zu personellen Verantwortlichkeiten, Datum bzw. Zeitplan, sowie den aktuellen Projektdaten versehen sein. Sie sollte für alle Teammitglieder jederzeit einsehbar sein. Ein Trouble- Ticketsystem (18) bietet hierfür zum Beispiel die geeigneten netzwerktransparenten Hilfsmittel an. (18) z.b. OTS - Open Trouble Ticket System DEN ENTWICKLUNGSPROZESS MANAGEN 69

83 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Weiteres Vorgehen Wir adressieren die nächste Frage (Priorität 1): Wie ist das IAction Interface von JFace zu verwenden? Dies ist eine wichtige Frage, da die gewünschte Funktionalität des Programms sonst nicht erreicht werden kann. Zum Zweiten muss sich das Team über die Implementierung der Rückgängigfunktion informieren. Die Ausgabe einer Statusmeldung priorisieren wir gering, da sie vordergründig keine notwendige Funktion darstellt. Die festgestellten Aufgaben kann man dazu verwenden, eine weitere Runde der Musterfindung nach dem vorgestellten Prinzip durchzuführen. Nur, dass diesmal nicht die Anforderungen des Kunden im Vordergrund stehen, sondern sozusagen als zweiter Level, die Anforderungen von Framework und Muster Berücksichtigung finden. 5.3 Fazit Konkret erreicht wurde folgendes: Ein Muster (Command) hat sich als praktikabel für die Kapselung von Befehlen erwiesen. Dies kann für spätere Projekte wiederverwendet werden. Es wurde zum ersten Mal mit einem neuen Framework gearbeitet, und offensichtlich erwartet dieses für GUI-Elemente, wie Toolbar und Menübar etwas befehlsobjektartiges (run()). Wir haben also ein Pattern entdeckt - Actions and Contributions. Die Bedingungen für Menü- und Toolbarerstellung mit dem neuen Framework wurden erfasst, verstanden (!) und dokumentiert. die weiteren Aufgaben und Fragen (was ist eine Action) liegen geordnet vor uns. Die konsequente Anwendung der objektorientierten Prinzipien (Abschnitt 2 auf Seite 40), Restrukturierung des Quellcodes durch Refactoring und die immer wiederkehrende Dokumentation, Überprüfung und Bewertung des Erstellten kann für eine gute Qualität von Entwurf und Implementierung sorgen. Diese Vorgehensweise birgt jedoch auch Gefahren in sich. [Reißing, 2002] zeigt, warum Objektorientierung - ohne dabei das Ergebnis kritisch zu prüfen - kein Garant für einen wartbaren Entwurf darstellt. Wir haben gesehen, dass nicht allein die Beschreibung der Anforderung genügt, zuverlässig klassische Entwurfsmuster zuzuordnen. Definierte Zwischenschritte und eine genaue Kenntnis darüber, wie implementiert werden kann oder muss, sind Voraussetzung für eine gelungene Zuordnung. Wie am einfachen Beispiel des Command Musters gezeigt, entstehen beim Mustermapping zahlreiche neue Fragen, deren Komplexität zwar schwer abzuschätzen ist, die es dem Team aber ermöglichen, sich schrittweise und geplant dem der Lösung zu nähern. Dabei setzen wir konsequent Mustersammlungen als Quellen für Umsetzung ein. DEN ENTWICKLUNGSPROZESS MANAGEN 70

84 4.5 KLASSISCHE ENTWURFSMUSTER IDENTIFIZIEREN Um ein einfaches Muster systematisch in den Kontext unserer Anwendung zu integrieren, war ein erheblicher Aufwand nötig. Die Dokumentation zum Speichern dieses Wissens im Team ist daher unerlässlich. Mit der Zeit entsteht so teamspezifisches Know How, welches in anderen Projekten wiederverwendet werden kann. Wie wir gesehen haben ist der wichtigste Schritt zur Identifizierung von Mustern für das konkrete Problem die Anforderungsbeschreibung. Wir haben auch gesehen, wie schnell aus der Kundenanforderung eine komplexe softwaretechnische Anforderung wird. Für die Erstellung von grafischen Oberflächen ist die Kenntnis zahlreicher klassischer Entwurfsmuster notwendig. Durch die eben gezeigte Methode ist es möglich, sich Stück für Stück das Verständnis für weitergehende Entwurfsentscheidungen anzueignen, die in auf den jeweiligen Anwendungszweck angepassten zusammengesetzten Mustern münden. Die Adaption von Mustern auf die eigene Anwendung ist immer noch eine äußerst kreative und aufwendige Arbeit. Lassen Sie uns aber zuvor schauen warum Benutzeraktionen zentral organisiert werden sollten. Das JFace Framework, also die Entwickler selbst, stellen uns hierbei eine in Java Quelltext gegossene Methode vor. Wir werden dabei den bereits gezeigten Prozess erneut anwenden können. DEN ENTWICKLUNGSPROZESS MANAGEN 71

85 4.6 ACTIONS AND CONTRIBUTIONS 6 Actions and Contributions Im diesem Abschnitt stellt uns JFace vor die Aufgabe, ein zusammengesetztes Muster zu verstehen, welches das Framework vorgibt: Actions and Contributions. Wenn wir das Framework sinnvoll verwenden wollen, müssen wir seine Wirkungsweise und Struktur analysieren. Wir wenden uns dem Reverse Engineering des JFace Action Paketes zu und werden dabei ein interessantes Pattern für die zentrale Definition von Benutzeraktionen identifizieren. 6.1 Motivation Benutzerinteraktionen implementieren ist teuer Betrachten wir unseren GUI Code, so müssen wir uns fragen, worin die Hauptarbeit der Implementierung besteht: der Entwickler muss jedem einzelnen GUI Element die notwendige Funktionalität hinzufügen. Warum ist dies aufwendig? Abbildung 15: Eine Multifensteranwendung in JFace, mit Menüleiste, Toolbar und Statusleiste wie sie der Autor für diese Arbeit prototypisch entwickelt hat. Die meisten aufwendigen GUI Elemente, wie Listen oder Baumdarstellungen sind bereits beispielhaft implementiert, so dass die Fachlogik meist problemlos angegliedert werden kann. Kompliziert wird es, wenn die Benutzerinter(!)-aktion implementiert werden muss. In der Regel müssen jedem Objekt je Benutzerinteraktion ein oder mehrere Listener Objekte hinzugefügt werden. DEN ENTWICKLUNGSPROZESS MANAGEN 72

86 4.6 ACTIONS AND CONTRIBUTIONS Dadurch wird die Interaktion mit den unterschiedlichen Eingabegeräten - Maus, Tastatur... - erst ermöglicht. Schauen wir uns dazu das - zugegebenermaßen triviale - Java Codefragment für einen SWT Button kurz an: / / D i e s e r Code stammt vom D e s igner : Button button = new Button ( s h e l l, SWT.PUSH SWT.CENTER) / / J e t z t muss d i e F u n k t i o n a l i t ä t / / i m p l e m e n t i e r t werden. / / M o u s e L i s t e n e r h i n z u f ü g e n button. addmouselisterner ( new MouseAdapter ( ) { public void mousedown ( MouseEvent e ) { clkdwneventhandler ( ) ; } } ) ; / /... und i m p l e m e n t i e r e n s t a t i c void clkdwneventhandler ( ) { System. out. p r i n t. ln ( Click down ) ; } Programmcode 4.6: Button hinzufügen. Ein Listener kann nur für einen konkreten Button verwendet werden. Deswegen wird man den Listener Code entweder in einer selbst geschriebenen separaten Klasse kapseln, oder - wie hier geschehen - mit Hilfe von MouseAdaptern, den Code reduzieren. Der Vorteil von Adaptern liegt vor allen Dingen in der Tatsache, dass nicht jede Listener Methode des Listerner Interface implementiert werden muss. Für den Leser vielleicht unbemerkt haben wir dabei die Maus auf die Verwendung eines einfachen Klicks festgelegt - eine nicht immer gern gesehene aber effektive Methode zur Minimierung der Strukturkomplexität und im Übrigen für einen Button durchaus sinnvoll. Für andere Elemente z.b. Listboxen sollte man ähnliche Überlegungen anstellen. OS X (Apple) macht dies in seiner Dock genannten Applikation sehr elegant vor: Drückt der Benutzer die (eine) Maustaste für kurze Zeit, wird ein Programm gestartet. Verharrt der Benutzer jedoch für eine kurze Zeit (ca. 1/2 Sekunde) mit gedrückter Taste auf einem Symbol, erscheint ein Menü. Rechte Maustaste - linke Maustaste? Gibt es nicht. Ein ähnliches Verhalten realisiert Microsofts PocketPC Software für die Bedienung mit einem Stift (also eigentlich einer Taste). IBM hat z.b. Richtlinien für die Entwicklung seiner Software herausgegeben (19) und gibt darin den dringenden Rat, plattformübergreifende Software so zu gestalten, dass alle betriebssystemüblichen Eingabemethoden unterstützt werden. Wir werden also noch mehr Listener hinzufügen müssen. (19) Ins Deutsche übersetzt in Leitlinien zur Entwicklung zugänglicher Software werner-krausse.de/dl/leitlinien_softwareentwickler.html DEN ENTWICKLUNGSPROZESS MANAGEN 73

87 4.6 ACTIONS AND CONTRIBUTIONS Wie man sich unschwer vorstellen kann, ist das dezentrale Hinzufügen entsprechender Listener sehr aufwendig. Sprechen Sie daher in jedem Fall mit Ihrem Auftraggeber diese Implementierungsdetails genau ab und vereinbaren Sie gegebenenfalls Änderungen in Zusatzvereinbarungen. Zusätzliche Implementierungen und deren Tests können sehr teuer werden. Ergebnis 6 LOC (Lines of Code) gegenüber 1 LOC (20) Kleine Ursache, große Wirkung! Der richtige Komplexitätszuwachs steht uns noch ins Haus: Wie wir schon vorher festgestellt haben, ergibt sich die eigentliche Komplexität einer Anwendung nicht allein aus der Menge, sondern der Struktur und ihrer Verteilung. Es müssen z.b. noch für die Tastatureingabe KeyAdapter implementiert werden, die genau auf das Programm zugeschnitten sind: mehrere Dutzend LOC s je nach Anzahl von Tastaturkürzeln, mindestens jedoch zwei für jeden Button, der mit einem Accelerator (englisches Synonym für eine Tastenkombination) erreichbar sein soll. Es folgt ein Beispiel für SWT und die Tastenkombination ALT+TAB: button. addkeylisterner ( new KeyAdapter... { public void keypressed ( KeyEvent e ) { S t r i n g s t r i n g = ; i f ( ( e. statemask & SWT.ALT)!= 0 ) s t r i n g += Alt ; [... ] switch ( e. KeyCode ) { case SWT.TAB: s t r i n g += TAB; break ; [... ] Programmcode 4.7: KeyListener hinzufügen. Ergebnis 8 LOC gegenüber 1 LOC - mindesten + 2 LOC für jeden Button und KeyAdapter Diese Prozeduren müssen wir für jeden Button der Oberfläche implementieren. Und auch für jeden Button jeder weiteren Oberfläche. Dies gilt ebenso für alle weiteren GUI Elemente - wie Listboxen oder Textfelder - welche über Kontextmenüs verfügen. Sie sind dabei vielleicht sogar redundant vorhanden, lösen also Programm übergreifend die selben Funktionen aus wie z.b. Kopieren, Ausschneiden, Einfügen oder das Öffnen des Druckdialogs. Ergebnis Pro Oberfläche verdoppelt sich durchschnittlich die Anzahl der LOC, je nach Komplexität der Schnittstelle. Sehr schnell wird klar, dass dieser Zuwachs nicht linear erfolgt. Mit Hilfe entsprechender Kosten- und Aufwandschätzmethoden kann der interessierte (20) Der Autor ist sich ziemlich sicher, dass der Designer nicht das 6-fache des Programmierers verdient. Vielleicht erinnern wir uns an dieser Stelle an so manchen Streit zwischen User Interface Designer und Programmierabteilung? DEN ENTWICKLUNGSPROZESS MANAGEN 74

88 4.6 ACTIONS AND CONTRIBUTIONS Leser vor Projektbeginn den Aufwand grob überschlagen, der für das einfache Hinzufügen einer weiteren Oberfläche entsteht. Für solche Fälle gibt es Consulting (Beratungs-) Unternehmen, die sich auf diesen wunden Punkt der Softwareentwicklung spezialisiert haben. Sie werden feststellen: das wird schnell sehr teuer (... das Consulting). Einen Schritt weiter gedacht, ergeben sich noch ganz andere Konsequenzen: Soll später die Oberfläche z.b. internationalisiert (21) werden (natürlich on the fly - im laufenden Betrieb), oder Änderungen hinzugefügt werden, führt die Unübersichtlichkeit der meisten GUI Implementierungen unweigerlich zum Anstieg der Strukturkomplexität. Softwaretechnik Bücher für das Studium (z.b. [Balzert, 1997]) machen deshalb früh darauf aufmerksam, in dem sie die penible Dokumentation jedes GUI Elements fordern, um die spätere Wartung zu vereinfachen. Die Anwendung dieses Prinzips verschleiert jedoch die wahre Problematik der Praxis, Benutzeraktionen immer wieder aufs neue dezentral zu implementieren, dies an mehreren Stellen im Code vorzunehmen zu müssen und den redundanten Code zu warten.... Never change... (22) Was für den Anwender oder Designer eine simple Benutzer-Aktion ist, wird dem Software Hersteller ein wild wucherndes Gebüsch, in welchem zahlreiche Kuckucksnester verborgen sein können. Leider machen diese sich meist nicht so lautstark bemerkbar, wie die Jungvögel des eben genannten Brutschmarotzers. These Anstelle Benutzeraktionen redundant für verschiedene GUI Elemente immer wieder zu definieren, sollten diese in Objekten gekapselt werden, damit alle dazugehörigen Eigenschaften (Tooltiptext, Tastenkombination, Icon... Verhalten) an zentraler Stelle definiert werden können. 6.2 Unbekannte Muster identifizieren Verfahren: Reverse Engineering Man könnte unser Tun als Reverse Engineering bezeichnen, da wir bestehende Codefragmente auf Strukturen, Zustände und Verhaltensweisen hin untersuchen (siehe z.b. [Wikipedia, 2006, Reverse Engineering]). Wir tun dies durch Visualisierung der betrachteten Klassensammlung mit Hilfe der UML. Anschließend verwenden wir unser neues Strukurverständnis, um unseren eigenen Code zu verbessern und weiterzuentwickeln. Da es sich bei JFace um quelloffenen und entsprechend CPL lizensierten Code handelt, ist es möglich, die Konzepte auf andere Frameworks zu übertragen und wieder unter derselben Lizenz zu veröffentlichen. (21) Dem Autor ist bekannt, dass man die Anforderungen nach Internationalisierung einer Anwendung durch entsprechende Auslagerung der GUI-Inhalte in z.b. XML Dateien in den Griff bekommen kann. (22)... a running system. DEN ENTWICKLUNGSPROZESS MANAGEN 75

89 4.6 ACTIONS AND CONTRIBUTIONS Abbildung 16 auf Seite 77 zeigt das Vorgehen schematisch in Form eines Prozessdiagramms. Sichtung Visualisierung Reduzierung Am Anfang steht die Sichtung der Dokumentation zum Framework. Sowohl Quelltexte und Sekundärliteratur sollten dabei anhand der Relevanz für das betrachtete Paket gesichtet werden. Diese kann ähnlich wie in Unterabschnitt 5.1 auf Seite 56 dokumentiert werden. Das Paket sollte in einem nächsten Schritt in das UML Werkzeug importiert werden. Die Visualisierung mit UML steht dabei als wesentliche Hilfe zur Komplexitätsreduzierung eines objektorientierten Entwurfs - und nur bei diesem - im Vordergrund. Das Ergebnis ist jedoch noch nicht zu verwenden, da es in der Regel viel zu viele Klassen beinhaltet, die zur Klärung der gewünschten Funktionsweise nicht betrachtet werden müssen (siehe Abbildung 18 auf Seite 81). Das UML Modell muss daher auf die relevanten Klassen reduziert werden. Dies ist unter Umständen ohne eine genauere Kenntnis der Sachverhalte nicht ganz einfach. Sie können jedoch die zuvor erstellte Dokumentation verwenden und auch Hinweise der Quelltext Dokumentation hinzuziehen. Das unbekannte zusammengesetzte Muster sollte nun im Groben sichtbar sein. DEN ENTWICKLUNGSPROZESS MANAGEN 76

90 4.6 ACTIONS AND CONTRIBUTIONS Abbildung 16: Prozess des Reverse Engineering eines Musters aus einem vorhanden Framework. DEN ENTWICKLUNGSPROZESS MANAGEN 77

91 4.6 ACTIONS AND CONTRIBUTIONS Statik Dynamik Mustermapping Auch diese Ansicht ist meist noch zu grob. Zunächst muss die statische Struktur der Klassen untersucht werden. Die Inspektion der Attributlisten und Quelltext Dokumentation lässt meist auf die Verantwortlichkeiten schließen. Zur Veranschaulichung und besseren Zuordnung kann die Methode des CRC Modeling (Class Responsibility Cards) verwendet werden (siehe [Beck and Cunningham, 1989] und [Ambler, 1998]). Sind die Verantwortlichkeiten und Zuständigkeiten der einzelnen Klassen klar, muss die Beziehungsstruktur des vorliegenden Musters untersucht werden. Dazu bildet man anhand der vorliegenden Dokumentation Untergruppen von wenigen Klassen. Im wesentlichen geht es hier um die Identifizierung der Vererbungshierarchien. Sind diese klar, sollte die Vererbungshierarchie auf Beziehungen zu anderen Klassenhierarchien untersucht werden. Vergleichen Sie dabei pro Vererbungshierarchie immer nur eine Beziehung. Die Dokumentation gibt hierzu meist die entscheidenden Hinweise. Das Verständnis der Zusammenhänge muss nun an Hand einer konkreten Implementierung sowohl in UML als auch in Code umgesetzt werden. Vergessen Sie dabei nicht den Kontext der Anforderungen. Sie verwenden dabei den bereits erwähnten Prozess des Mustermapping ab dem Prozessschritt Adaptieren und Implementieren (siehe Abbildung 11 auf Seite 59). Wir wollen nun das konkrete Reverse Engineering in der Praxis durchführen. 6.3 Erfassen der Dokumente Eine Internet Recherche ergibt: Neben dem JFace Framework taucht das Action Konzept auch in QT auf und erklärt wahrscheinlich dessen Beliebtheit für der Erstellung von KDE Open Source Anwendungen, da es die GUI Erstellung wesentlich vereinfacht (siehe Kapitel 2 auf Seite 16 und siehe im Abschnitt 10). Actions bei Eclipse werden im Zusammenhang mit der Rich Client Plattform (RCP) vorgestellt. Sucht man jedoch nach einem Action -Pattern im Internet, so erhält man zahlreiche Links über die Implementierung von Actions in RCPs. Diese beziehen sich ausschließlich auf die Erstellung eines Eclipse Plugins (23). Der eigentliche Mechanismus von Actions and Contributions bleibt verborgen Das Konzept von Actions and Contributions in JFace Bei näherer Beschäftigung mit den Patterns des JFace Framework fällt auf, dass IBM offensichtlich eine Lösung für die zentrale Definition von Benutzeraktionen für die Eclipse Plattform bereitstellt. Dort nennt man das Konzept Actions and Contributions (24). Zur Erinnerung: Die JFace Klassen implementieren puren SWT Code, sie stellen also kein neues GUI Framework für (23) Ein Eclipse Plugin wird zentral in einer XML-Datei definiert. (24) siehe help.eclipse.org eclipse.platform.doc.isv/guide/jface_actions.htm DEN ENTWICKLUNGSPROZESS MANAGEN 78

92 4.6 ACTIONS AND CONTRIBUTIONS Java zur Verfügung. Voraussetzung, um später eigene Oberflächenelemente in Ihre Anwendung zu integrieren ist daher ein elementares Verständnis von SWT. Ein Versuch, funktionell ähnliche Klassen für andere grafischen Schnittstellen wie z.b. GTK, wxwidgets oder WindowsForms (.NET) zu erstellen, würde ebenfalls eine genaue Kenntnis der zugrunde liegenden Low Level Komponenten voraussetzen. (a) Eventmodell von SWT - Events werden vom Betriebssystem entgegengenommen und in einer SWT Applikation weiterverarbeitet. (b) Eventmodell von JFace - Listener und Widgets werden in Contributions zusammengefasst. Dieser Code ist wesentlich einfacher zu schreiben. Abbildung 17: Zum Eventmodell von SWT und JFace. Quelle: [Scarpino et al., 2005, Kapitel 4, Abbildung 4.1 und 4.3] Doch nun zu JFace: Die Autoren des Eclipse Frameworks haben zur Vereinfachung des Eventhandling innerhalb der Rich Client Architektur ein zusammengesetztes Muster implementiert, dass eine Benutzeraktion an zentraler Stelle definiert: die sogenannte Action-Klasse. Solche Benutzeraktionen - wir werden diesen Begriff synonym zu Action verwenden - werden in Action Objekten einmalig gekapselt und registrieren sich bei deren Instantiierung bei einer Gruppe GUI Elementen selbst: z.b. in Toolbars, Statusleisten oder Menüelementen. Diese stellen dann das jeweilige Action-Objekt auf die im Kontext typische Weise dar: In der Toolbar als Icon mit Tooltip, in der Statusleiste als Hinweistext, im Menü als benanntes Element mit passenden Tastaturkommando u.s.w. Die Aufgaben der beteiligten Klassen lassen sich grob in drei Bereiche gliedern: Aktion - Befehlsausführung (Action) Darstellung (ContributionItem) Verwaltung (ContributionManager) DEN ENTWICKLUNGSPROZESS MANAGEN 79

93 4.6 ACTIONS AND CONTRIBUTIONS Erreicht wird dadurch zweierlei: eine Minimierung der LOC (25) an selbst geschriebenen Code sowie der Strukturkomplexität durch Zusammenfassung und Zentralisierung von immer wiederkehrenden Aufgaben. Doch bisher nur in der Theorie. Erst die Analyse des zugehörigen Frameworks wird uns Aufschluss darüber geben, wie hier im Detail verfahren wird. 6.4 Extraktion des UML Modells Das Klassenframework des Java Paketes org.eclipse.jface.action, welches alle Schnittstellen und Klassendefinitionen für Actions beinhaltet ist sehr umfangreich. In der Version 3.0 von Eclipse besteht es aus 11 Schnittstellen und 21 Klassen. Benutzeraktionen anwendungsübergreifend zu organisieren ist also keine triviale Aufgabe. Diese Dimensionen sind für einzelne (!) Pakete eines objektorientierten Frameworks durchaus üblich. Eine Online Dokumentation findet sich auf help.eclipse.org ([IBM Corporation, 2004]). Wir im portieren also das entsprechende Paket org.eclipse.jface.action zuerst in ein UML Werkzeug. Damit erhalten wir eine visuelle Darstellung sowohl der statischen als auch der dynamischen Struktur des Klassenverbandes (Klassen bzw. Beziehungen). Wie im letzten Abschnitt beim Mustermapping muss auch hier eine Reduzierung der Komplexität vorgenommen werden. Abbildung 18 auf Seite 81 zeigt deutlich, warum dies geschehen muss. Doch zurück zu den Anforderungen. Tabelle 8 auf Seite 69 gibt uns für das Vorgehen den ersten nötigen Hinweis. Mit Priorität 1 haben wir folgende Anforderung bewertet: Erwartet wurde: An vielen Stellen redundanter Aufruf von Commandobjekten. Je Menübutton, Toolbarbutton, sonstige Elemente. Aber: Einfügen in JFace-Menü erfordert Benutzung des Interface IAction. Das Framework muss auf das Verhältnis der Klassen hin untersucht werden. 6.5 Reduzierung auf relevante Klassen In einem ersten Schritt entfernen wir deshalb alle Klassen aus dem Diagramm, welche nicht direkt mit den im Dokumentationstext im Zusammenhang mit Actions and Contributions erwähnt werden. Dann konzentrieren wir uns auf eine beliebige erste Vererbungshierarchie: hier ausgehend von der Schnittstelle IAction. Zudem lesen wir die zugehörige Dokumentation im Quellcode und/oder in verfügbarer Sekundärliteratur Der Zustand - Actions In der Eclipse Online Dokumentation werden Actions folgendermaßen beschrieben: (25) Line of Codes DEN ENTWICKLUNGSPROZESS MANAGEN 80

94 4.6 ACTIONS AND CONTRIBUTIONS Abbildung 18: JFace - Paket Übersicht Action nach dem initialen Import in das UML Werkzeug. The action classes allow you to define user commands independently from their presentation in the UI. Benutzeraktionen (user commands) können somit unabhängig von der Präsentationsoberfläche der Anwendung implementiert werden. Für das Eclipse UI existieren zahlreiche konkrete Implementierungen für Benutzeraktionen: z.b. für das Öffnen eines Objekts in einem neuen Fenster, das Erstellen eines neuen Projektes u.v.m. Diese Klassen sind eng mit der Arbeitsoberfläche von Eclipse selbst (eclipse workbench), RCP Applikationen, sowie Plugins verbunden und außerhalb dieses Kontextes nicht einsetzbar. Wir brauchen Sie daher nicht weiter zu betrachten. Eine Online Dokumentation findet sich auf help.eclipse.org ([IBM Corporation, 2004]). Für Anwendungen allein unter Verwendung von JFace jedoch schweigt sich das Eclipse Manual aus. [Scarpino et al., 2005, Kapitel4, Seite 63] gibt eine kurze Einführung in das Event Modell von SWT und JFace, ebenso findet man eine kurze Einführung bei [Emmenis, 2003], jeweils nur wenige Abschnitte umfassend. Lassen Sie uns deshalb einen Blick in die offen JFace Quellen legen. Sie befinden sich in jeder Eclipse Anwendung im Plugin Verzeichnis als komprimierte Datei mit dem Namen src.zip und können leicht extrahiert werden. Mit der Eclipse IDE lassen sich dann die Javadoc (26) Dateien erzeugen. Ein gutes UML Werkzeug kann anschließend den Quellcode importieren, um die Klassendiagramme zu extrahieren. Das Interface IAction stellt die Repräsentation der Nicht-grafischen Seite (help.eclipse.org: non-ui side) eines Befehls dar. Wie ein Befehlsobjekt (com- (26) SUN Javadoc http: // java. sun. com/ j2se/ javadoc/ DEN ENTWICKLUNGSPROZESS MANAGEN 81

95 4.6 ACTIONS AND CONTRIBUTIONS Abbildung 19: Klassendiagramm zu JFace Action (mit implementierter Action Klasse). mand) definiert sie daher eine run() Methode zur Ausführung eines beliebigen Codes. Die abstrakte Klasse Action implementiert einen Standard dieses Interface. Für jede Benutzeraktion muss davon in einer Anwendung eine konkrete Aktionsklasse abgeleitet werden (als Beispiel hier: concreteaction - beliebig so benannt). Abbildung 19 auf Seite 82 zeigt diese Vererbungsbeziehung. Neben der run() Methode werden in dieser abstrakten Klasse alle wichtigen Details zum Verhalten des Action Objektes verwaltet. Damit wird das Verhalten einer Action angepasst, wenn es in seiner zugeordneten Komponente (Contribution) zur Anwendung kommt. Dabei wird jedoch nicht direkt GUI Code erzeugt, sondern man beschränkt sich auf die Logik dieser Vorgänge: Steuerung der Darstellung als Button, Checkbox, Dropdown Menü oder Radiobutton, sowie deren Eigenschaften Verwaltung von Attributen wie Tooltip Text, Tastaturkürzel, zugehöriges Bild (Get/Set Methoden), Beschreibung Verwaltung verschiedener Listener, Listener zur Anzeige von Hilfefenstern (helplistener), Listener, die über den Statuswechsel eines Action Objektes informieren (propertychangelistener) Gesteuert wird der Zustand eines Action Objektes durch einfache Get/Setter Methoden oder durch Aufruf eines der zur Verfügung gestellten Konstruktoren. Somit kann das Verhalten sowohl bei der Instantiierung als auch zur Laufzeit festgelegt bzw. verändert werden. Die Darstellung der UML Klasse Action finden Sie im Anhang (Abbildung 25 auf Seite 119). DEN ENTWICKLUNGSPROZESS MANAGEN 82

96 4.6 ACTIONS AND CONTRIBUTIONS Die Darstellung - Contributions Als Contributions (engl. Mitwirkung, Beitrag) werden diejenigen Klassen bezeichnet, welche diese Benutzeraktionen mit Hilfe entsprechenden GUI Elemente (items) in der jeweilig beteiligten GUI umsetzen (managen) sollen. Diese Klassen werden nicht vom Programmierer selbst programmiert, sondern sind für die verschiedenen GUI Komponenten der Codebasis von Eclipse bereits implementiert. Da wir keine Eclipse Applikation schreiben, sondern JFace im Sinne einer unabhängigen Einzelapplikation (Standalone) verwenden, sind Contributions in unserem Fall Menüs, Werkzeugleisten oder die Statusleiste. Der Übersichtlichkeit halber schauen wir uns zunächst den Vererbungsweg einer Menüleiste an: Abbildung 20: JFace - Contribution Manager Wie wir sehen, setzt JFace stark auf Interface Vererbung und ermöglicht es so, dass mit absteigender Hierarchie stark spezialisierte Klassen entstehen, die jeweils die benötigten Eigenschaften hinzu erben. Die Umsetzung des Prinzips: Programmiere auf eine Schnittstelle, nicht auf eine Implementierung. Bewusst werden dabei einzelne abstrakte Klassen gebildet, weil Implementierungen für weiter unten in der Hierarchie stehende Klassen angeboten werden sollen. An der Spitze der Klassenhierarchie stehen die Schnittstellen I(!)ContributionManager und I(!)ContributionItem (siehe Abbildung 21 auf Seite 86). 6.6 Statische Sicht ContributionItems Die Verbindung zur Außenwelt stellen sogenannte ContributionItems her. Sie halten eine Referenz auf ein Action Objekt. Ein Blick auf den Quellcode zeigt, dass diese Objekte die eigentliche Dynamik der Benutzerschnittstellen Elemente verwalten und implementieren: die Listener. Hier werden diejenigen in Unterabschnitt 6.1 auf Seite 72 erwähnten Benutzeraktionen zentral verwaltet, welche uns in normalen Anwendungen viele Lines of Codes an wartbarem Code bescheren würden. DEN ENTWICKLUNGSPROZESS MANAGEN 83

97 4.6 ACTIONS AND CONTRIBUTIONS ContributionManager Alle ContributionManager, die von der gleichnamig abgeleiteten abstrakten Klasse an instantiiert werden bilden den Grundstock für Toolbar-, Menu- und StatusLineManager Objekte. ContributionManager stellen im wesentlichen Operationen (Methoden) zur Verfügung. Methoden, um Actions oder ActionContributionItems einer Liste hinzuzufügen. Dabei ist es möglich, diese innerhalb der Listen zu gruppieren. Da jede Action darüber hinaus eine eindeutige Identifikationsnummer besitzt, kann man komfortabel größere Menüs oder Toolbars zu erstellen. Die konkreten Manager Implementierungen kümmern sich dabei auch um alle notwendigen Allokations- und Deallokationsaufgaben. Jeder Manager hält über eine Referenz die Verbindung zur übergeordneten Komponente und folgt dabei dem Composite Muster zum Aufbau komplexerer Teil-/Ganzes Strukturen. Der Auslöser unserer Suche war die Frage, wie einem JFace Menü ein Command Objekt hinzufügt werden kann. Auf der Suche nach einer add() Methode, werden wir im Quellcode von MenuMangager seltsamerweise nicht fündig. Ein Blick auf das UML Diagramm lässt vermuten, dass die abstrakte Klasse ContributionManager diese Funktion für alle Manager Objekte implementiert. Es ist ein sehr schönes Beispiel für die gezielte Verwendung von abstrakten Klassen zur genauen Festlegung der Verantwortlichkeiten von Objekten: hier die Verwaltung von ContributionItems. Die weiter spezialisierte Unterklasse MenuManager fügt lediglich die für ein Menü typischen Funktionen hinzu. Wie wir sehen können, ist auch ein MenuManager ein ContributionItem. Wir dürfen an dieser Stelle vermuten, dass es sich um eine Teil/Ganzes Beziehung (Composite) mit ContributionManager als Komponente und ContributionItem als Kompositum handelt. Dies macht natürlich auch Sinn, denn es entspricht dem Aufbau aller anderen GUI JFace Elemente. Somit ist es auch möglich, Untermenüs zu realisieren (Menü im Menü). Generell kann man hier aber den Vorteil von Kompositionsbeziehungen gegenüber einer reinen Vererbungshierarchie erkennen. So wird es möglich das Verhalten verschiedener Klassen miteinander zu kombinieren (Manager Verhalten, Item Verhalten) und gleichzeitig lose Kopplung zu gewährleisten (der Manager weiß nicht, welches Item er beherbergt und umgekehrt). Für Toolbars und auch den StatusLineManager sind die gleichen Mechanismen realisiert, wenngleich speziell auf deren Verhältnisse abgestimmt ActionContributionItem Dem ContributionItem kommt eine weitere besondere Rolle zu, welche jedoch erst in der Vererbungsstufe als ActionContributionItem (ACI) sichtbar wird. Erst an dieser Stelle wird erkennbar, dass über eine Referenz zur Action Klasse die Verbindung zu den Verwaltungsklassen (den Managern) hergestellt wird. Der Quellcode dieser Klasse verrät uns, dass hier eine Art Chamäleon Logik versteckt ist: Das ACI kann nicht wissen, in welchem Container es zu Liegen DEN ENTWICKLUNGSPROZESS MANAGEN 84

98 4.6 ACTIONS AND CONTRIBUTIONS kommt: Menü, Toolbar oder in Folge einer abgefeuerten Aktion in der Statusleiste. Was im Menü als Text erscheint, soll in der Toolbar als Bild erscheinen. Nach dem Drücken auf einen Toolbarknopf oder einen Menüpunkt soll in der Statusleiste eine Meldung erscheinen. Alle drei Anforderungen sind Erscheinungen ein und desselben Action Objekts. Das ACI ist in der Lage, diese Zustände auszuprägem. Es handelt sich sozusagen um einen Multibutton, der alle notwendigen Erscheinungsformen anbietet, welche eine Benutzeraktion in einer JFace GUI annehmen kann: verschiedene Buttons, textuelles Objekt im Menü u.s.w. Der jeweilige Container oder der Programmierer über entsprechende Methoden zur Manipulation dieses Aussehens entscheidet dann zur Laufzeit darüber, welche Erscheinung dominiert. 6.7 Dynamische Sicht Es wird nun klar, warum ein MenuManager lediglich ein Action Objekt benötigt - erinnern Sie sich an die menu.add(iaction) Methode. Er verwaltet für Ihn anonyme ContributionItems, welche selbst wiederum eine Referenz auf ein Action Objekt halten. Der aufmerksame Leser mag an dieser Stelle verwirrt sein, denn wir übergeben ein Action Objekt und kein ActionContributionItem. Ein Blick auf die add(...) Methode von ContributionItem.java zeigt aber sehr schnell, wie die wahren Verhältnisse sind: public a b s t r a c t c l a s s ContributionManager implements IContributionManager { / /... public void add ( IAction a c t i o n ) { add (new ActionContributionItem ( a c t i o n ) ) ; } / /... Programmcode 4.8: Klasse ContributionItem.java Es wird in jedem Fall intern ein ActionContributionItem erstellt! Das ACI (ActionContributionItem) als eigentliches Bindeelement zwischen Manager Objekten und Action Objekten ist an dieser Stelle erst zu erkennen. Es folgt das UML Diagramm, welches abschließend die Zusammenhänge zwischen Actions und Contributions aufzeigt, womit die Analyse der zu Grunde liegenden Klassen beendet wäre: DEN ENTWICKLUNGSPROZESS MANAGEN 85

99 4.6 ACTIONS AND CONTRIBUTIONS Abbildung 21: JFace - ActionContributionItem 6.8 Implementierung Diesem Schritt werden wir auf Seite 89 einen eigenen Abschnitt widmen. 6.9 Dokumentation Wir werden dazu die vorgestellten Verfahren zur Dokumentation von HCI Mustern verwenden (siehe Unterabschnitt 3.3 auf Seite 46). Dies bietet sich an, weil sie im Umfeld der konkreten Applikation anschaulich die praktische Umsetzung des Musters beschrieben werden kann. Es kann auch ein Abschnitt über die Implementierung angegeben werden oder zumindest ein Hinweis, an welcher Stelle im Quellcode die Umsetzung zu finden ist. Wie bei jeder Dokumentation ist es auch hier nochmals angebracht, die Anforderungen auf Vollständigkeit zu prüfen. Der Autor möchte an dieser Stelle den Prozess der Abarbeitung von Tabelle 8 auf Seite 69 abkürzen, da die Vorgehensweise im Wesentlichen deutlich gemacht wurde. Name, Autor Actions and Contributions (27) Problem (problem) Prinzip (usability principle) Eine Benutzeraktion soll Programm übergreifend auf verschiedene Weise zugänglich sein: über einen Hauptmenüpunkt, innerhalb einer Toolbar, einen Button der Anwendungsoberfläche oder über ein Kontextmenü. Nach Auslösen der Aktion soll die Statusleiste der Anwendung einen Hinweis ausgeben. Eine Anwendungshilfe soll über einen Tooltip Text zugänglich sein. Die Benutzeraktion soll zudem über Tastenkombinationen zugänglich sein. Die visuelle Darstellung soll Programm übergreifend eindeutig sein (Iconifizierung). Benutzerinteraktion DEN ENTWICKLUNGSPROZESS MANAGEN 86

100 4.6 ACTIONS AND CONTRIBUTIONS Name, Autor Actions and Contributions (28) Kontext (context) Konflikte (forces) Fensterapplikationen oder Teile davon, welche über eine oder mehrere Menüleisten, Kontextmenüs, Toolbars, Buttons und eine Statusleiste verfügen. Der Benutzer möchte Programm übergreifend auf Funktionen zugreifen, welche Er erwartet die im Kontext seiner verwendeten Oberfläche angebotenen Möglichkeiten zur Steuerung des Programms. Dabei hat er eine bestimmte Neigung, Programme zu bedienen: nur mit der Tastatur, nur mit der Maus, abwechselnd, Menü orientiert (textuell), Button orientiert (Icons), Kontextmenü orientiert. Die Menüführung soll dem erwarteten Anwendungsworkflow entsprechen. Lösung (solution) Gebrauchsnutzen (Usability) Stelle dem Benutzer als Standard alle geforderten Zugänge zur Benutzerinteraktion zur Verfügung. Gruppiere die verwendeten Benutzeraktionen auf Grund der Anforderungen des Benutzerworkflows. Beschreibt den Gebrauchsnutzen des Musters aus Sicht der Anwendung durch den Benutzer. DEN ENTWICKLUNGSPROZESS MANAGEN 87

101 4.6 ACTIONS AND CONTRIBUTIONS Name, Autor Actions and Contributions (28) Beispiele (examples) Beispiel 1: Multifensteranwendung mit Menü, Toolbar, Statusleiste und immer wiederkehrenden Aufgaben: Beispiel 2: Datei Explorer Quelle: [Emmenis, 2003] Bekannte Anwendung (known uses) Actions: KDE (Open Source Desktop Umgebung auf Basis vonqt Actions and contributions: Eclipse.org Framework (IBM): JFace, Framework für SWT. Paket org.eclipse.jface.action. JFace Action DEN ENTWICKLUNGSPROZESS MANAGEN 88