new - beim Fachbereich Informatik

Entwicklung nutzerorientierter 

Anwendungen 

ENA 

Wintersemester 2012/13 

Fachbereich Informatik: 3. Semester Bachelor Studiengang 

Prof. Dr.-Ing. Hans-Peter Wiedling

Wenn Microsoft Autos bauen würde … 

� Die Warnlampen für Öldruck, Lichtmaschine, Benzin und andere wären 

durch eine einzige Warnlampe mit der Aufschrift „Allgemeiner 

Autofehler“ ersetzt . 

� Der Airbag würde bei einem Unfall „Sind Sie sicher?“ fragen, bevor er 

aufginge. 

� Das Lenkrad würde durch eine Maus oder einen Trackball ersetzt 

werden. 

�� Sie müssten sich Tastenkombinationen für „Bremsen“ merken. 


Prof. Dr.-Ing. Hans-Peter Wiedling 

Seite 2

Wenn Microsoft Autos bauen würde … 

� Beim Versuch, das Auto zu starten, würden Sie oft die 

Fehlermeldung „Abbruch, Wiederholen, Ignorieren“ erhalten. 

� Der Tachometer würde 70 anzeigen, auch wenn Sie nur 40 km/h 

fahren. 

� Der Motor wäre nicht gleich nach dem Starten voll funktionsfähig. 

Stattdessen würde das Auto stehen bleiben und wieder losfahren, 

während der Motor versucht, die nötigen Zubehörteile 

anzuschrauben. 

�� Jedes Mal, wenn Sie einen neuen Fahrgast mitnehmen, müssten Sie 

die Zusammenstellung des Autos ändern. Diese würde natürlich 

auch erhalten bleiben, wenn der Passagier schon lange ausgestiegen 

ist. 



Seite 3

Benutzer sind nur Menschen! 



Seite 4

Entwicklung nutzerorientierter Anwendungen 

� Gestaltung von grafisch-interaktiven Systemen 

�� Bedürfnisse, Fähigkeiten und Erwartungen der (spezifischen) 

Endanwender stehen im Mittelpunkt 

� Endanwender identifizieren 

� Bedürfnisse befriedigen 

� Fähigkeiten unterstützen 

� Erwartungen erfüllen 

� Interdisziplinäres Gebiet (Psychologie, Design, Softwareentwicklung, ...) 

�� Usability steht in den verschiedenen Phasen im Vordergrund 

� Anforderungen erfassen und analysieren 

� Prototypen entwerfen, umsetzen, testen und reflektieren 

� Ergebnisse evaluieren 



Seite 5

Überblick 

� „Java for Run-aways“ 

�� Human Computer Interaction: 

� Usability 

Konsistenz, Intuitive Bedienbarkeit, Erlernbarkeit, ... 

� Layout 

Gestaltung/Farbe, Schrift, Anordnung 

� Entwurf: benutzerzentrierte Analyse, Design, Rapid Prototyping 

� Konstruktion unter Java/Swing mit Tool (eclipse): 

�� Componenten, Container, LayoutManager, Eventhandling 

� Programmiermuster 

� Model-View-Control, Observer 

� Beispiele in der Vorlesung: Trouble Tickets Systeme, Turtle Grafik 



Seite 6

Lernziele der Veranstaltung 

� Grafisch-interaktive Benutzungsoberflächen (GO) 

�� Benutzerorientierung verinnerlichen 

(Benutzergruppen/Rollen identifizieren, Usability-Überlegungen einsetzen, ...) 

� intuitiv und ergonomisch gestalten 

� visuell ansprechend entwerfen 

� GO-Entscheidungen - Verwendung bestimmter Componenten - 

begründen können 

� objektorientiert konstruieren 

� gute GOs spiegeln sich im Entwurfs- und Realisierungsaufwand wider 

�� Methodisch Vorgehen lernen 

� Konzept der Ereignisorientierung verstehen 

� Bausteine grafischer Oberflächen (Componenten) kennen lernen 

� ... und das alles in Java und mit Swing 



Seite 7

Inhalte 

� SW-Technik: Rollenerfassen, Nutzungsfall, Szenario, Screen-Diagramm 

�� Trennung Datenverarbeitung �� Oberfläche, Dokument ��> ��> Ansicht 

� MVC als Architektur- und Designpattern 

� Screen-Design und Ergonomie 

� Gruppierung, Formen, Farben, statisches/dynamisches Layout 

� Java Crash-Kurs für Kenner von C++ 

� Implementierungstechniken 

� Bausteine: Datentypen, Attribute, Ereignisse 

� Fenster und Dialoge, Layout-Manager 

� Ereignisbehandlung 

� U.U. zusätzliche Klassen (Dateihandling, Serialisierung, …) 

� Gute Beispiele, schlechte Beispiele 



Seite 8



Seite 9

Praktikum 

Semesterprojekt: Entwurf, prototypische Realisierung und Verfeinerung eines 

Systems 

� Problembewusstsein 

entsteht im Laufe des 

Semesters; 

optimierende Iterationen 

sind wichtig 

�� http://www.eclipse.org/downloads/ (und http://www.eclipse.org/archived/) 

� http://www.eclipse.org/windowbuilder/download.php 

� http://netbeans.org 



Seite 10

Prüfung/Klausur 

� mit Papier und Kugelschreiber ☺ 

� Am 04.02.2013 von 10.15 Uhr bis 11.45 Uhr; Raum siehe OBS 

(Anmeldung bis 20.01.2013; Abmeldung bis 31.01.2013) 

� regelmäßige Teilnahme am Praktikum – es sind 6 Termine - 

wird kontrolliert und ist Voraussetzung; 

Beginn am 18. (donnerstags) bzw. 19.10. (freitags) 

� alte Klausur vom Vorsemester und „Übungs-/Vorbereitungstermin“ 

Tipp: 

Aktive Mitarbeit macht einen guten Teil der Prüfungsvorbereitung aus! 



Seite 11

Grundlagen-Literatur 

� http://www.javabuch.de 

Guido Krüger, Addison-Wesley, ISBN 3-8273-1949-8 

� http://openbook.galileocomputing.de/javainsel8/index.htm 

� http://www.dpunkt.de/java/index.html 

� http://www.java2s.com/Tutorial/Java/CatalogJava.htm und 

� http://java.sun.com/docs/books/tutorial/index.html 

� Sun: The Java Tutorial + Suchapplet 

http://java.sun.com/docs/books/tutorial/uiswing/components/components.html 

http://java.sun.com/docs/books/tutorial/information/download.html 

http://www.siteforum.com/sun/download/jtutorial_dfi.zip 

� Sun: Java 2 SDK API documentation + Suchapplet 

http://java.sun.com/products/jdk/1.3/index.html#docs 

http://www.siteforum.com/sun/download/jdk13_dfi.zip 



Seite 12

Weiterführende Literatur 

� Bernhard Preim: Entwicklung interaktiver Systeme 

� Ivo Wessel: GUI-Design 

� Alan Cooper: About Face - The Essentials of User Interface Design 

� Sun: Java Look and Feel Design Guidelines 

� Online http://java.sun.com/products/jlf/dg/index.htm 

� Sun: Sonstiges rund um Java 

�� http://java.sun.com/docs/ 

� Helmut Balzert: Lehrbuch Grundlagen der Informatik 



Seite 13

Analyse-Design-Realisierung-Test-Evaluation 

Den gesamten Prozess 

Analyse 

wollen wir im Praktikum 

�� Benutzorientiertes RequirementsEngineering: zumindest einmal 

Usability-Engineering 

durchlaufen. 

� Heuristic – GUI wird ohne Benutzer(in) testet und bewertet 

� Observation – Benutzer(in) wird beim Bedienen beobachtet 

� Thinking-Aloud – Beim Bedienen denkt der Benutzer „laut“ und 

äußert sich so zusätzlich 

� Questionnaire – mit Hilfe eines Fragebogens werden Information 

über den Benutzer, die Wünsche und Anforderungen gesammelt 

� Interview – Befragung, Stärken und Schwächen werden 

herausgearbeitet 

� U.U. Erarbeitung von Anwendungswissen 

� U.U. Erarbeitung von zusätzlichem technischem (Hintergrund-)Wissen 



Seite 14


Design 

� Legen Sie Designziele fest 

� Welche Benutzergruppen adressieren Sie? 

� Entlasten Sie den Benutzer! 

� Beschreiben Sie Anwendungsszenariien und Use Cases 

� Skizzieren Sie das Layout (es sollte dynamisch sein) 

� Überlegen und begründen Sie Gestaltungsentscheidungen 



Seite 15


Realisierung 

� Entwickeln Sie die Funktionalität getrennt von der GUI! 

� Überlegen Sie, wie Sie Funktionalität und Dialog(Controls) koppeln: 

Model-View-Control 

� Denken Sie auch an 

� die Navigation im Systeme, 

� die Arbeitsabläufe und 

�� den generellen Workflow 

� Rapid Prototyping: 

� iterativ, unter Einbeziehung der Nutzer 

� Früh Machbarkeit demonstrieren 



Seite 16


Test 

� Wer von Ihnen würde ein nicht getestetes Programm benutzen? 

� Überlegen Sie von Beginn an Testfälle 

� Wie lange dauert es, um eine bestimmte Aufgabe zu lösen? 

� Wie viele Klicks/Interaktionen werden benötigt, um die Aufgabe 

zu lösen? 

� Wie schnell erlernbar ist das GUI? 

�� Wie viele Fehler werden gemacht? Wie sicher ist die GUI? 

� Testen Sie die Gebrauchstauglichkeit (Usability) 



Seite 17


Evaluation der Umsetzung 

� Welche Ziele werden erreicht? 

� Wie gut werden Ziele erreicht? 

� Evaluationsmethoden: 

� Experteninspektionen, kognitiver Walkthrough, Usability-Tests, 

Fragebogenverfahren 

�� Klassifikation von Evaluationsmethoden: 

analytisch vs. empirische bzw. 

deskriptiv vs. präskriptive Evaluationsmethoden 

� Formen der Evaluation: summative und formative Evaluation 

� Bestimmung von Evaluationskriterien 



Seite 18

Bedeutung der Entwurfsphase 

� Beim Entwurf und der Realisierung muss insbesondere in der Praxis 

darauf geachtet werden, dass 

� das Projekt 

„in-time“ und „in-budget“ 

bleibt und 

� die User Requirements erfüllt werden. 

… muss auch etwas mit 

Qualität zu tun haben 

�� Fehler in der Analyse und Konzeption haben dabei dramatische 

Auswirkungen auf die beiden erstgenannten Punkte! 

� Ein erstes, wichtiges Ziel muss also sein, die Anforderungen der 

Benutzer richtig und vollständig zu erfassen 



Seite 19



Softwaretechnik für User Interfaces 

Arten von Applikationen 

� U-Software in Anlehnung an 

� Spiele 

U- und E-Musik 

� Funware 

� Heim-Software 

� E-Software 

� Office-Anwendungen 

� Kommerzielle Datenverarbeitung 

fließende Übergänge 

• in diesem Stil machen wir das Praktikum ! 

� Inhouse-Applikationen 

� Maschinensteuerungen 

Kiosksysteme, 

POI (Point of Interest), 

POS (Point of Sales) 

Hoher GO/UI Anteil 

� wohin gehören Fahrplanauskunft, Geldautomat, Ticketservice, ... ? 



Seite 21

Gelegenheit, über Usability nachzudenken 

� Ständiger Technologiewandel verlangt permanente 

Auseinandersetzung mit Organisationsabläufen und den Systemen 

� Anstehende System- oder Versionswechsel sind zusätzlich günstige 

Zeitpunkte, dabei müssen gerade die unterschiedlichen Nutzer 

überzeugt und mitgenommen werden 

� Bereitschaft, sich mit Arbeitsabläufen und der Einbindung von 

IT - Prozessen auseinander zusetzen mit dem Ziel 

� Produktivität/Wirtschaftlichkeit zu steigern 

�� Ressourcen zu schon und Kosten (Durchlaufzeit) zu reduzieren 

� Qualität und Kundenzufriedenheit zu verbessern 

� Neben den Aspekten Preis, Lizenzen, Standards, branchentypischen 

Lösungen, verkauften Systemen, Schnittstellen und Integration spielt 

die Nutzerzufriedenheit eine wichtige Rolle 



Seite 22

Mensch-Maschine-Schnittstelle - 

Graphische Benutzungsoberfläche 

kreativ, intuitiv 

Beobachten, 

Bedienen 

Interaktion 

Präsentation, 

Visualisierung 

monoton, schnell 



Phänomene nicht nur im Zusammenhang 

mit grafischen Benutzungsoberflächen (1/2) 

Kognitive Dissonanz 

� entsteht, wenn man zwischen verschiedenen Alternativen wählen 

muss und die Vor- und Nachteile dieser Systeme abwägt. 

� Hat man eine Entscheidung getroffen, ist man bemüht, sich zu 

versichern, dass man die richtige Wahl getroffen hat und nimmt 

Argumente besonders wahr, die die Entscheidung unterstützen und 

verharmlost/ignoriert Gegenargumente. 

� Beispiel: 

� Festhalten an möglicherweise kryptisch und schwer zu 

benutzenden oder teueren Systeme 

� Anordnung der Tasten auf der qwertz-Tastatur 

[Alternative siehe z.B. http://en.wikipedia.org/wiki/Dvorak_Simplified_Keyboard ] ... 



Seite 24

Phänomene nicht nur im Zusammenhang 

mit grafischen Benutzungsoberflächen (2/2) 

Magisches Denken 

� bezieht sich darauf, dass sich Benutzer eine Vorstellung (mentales 

Modell) von dem System/Geräte machen, mit dem sie arbeiten. 

Diese hängt von der Erfahrung und Vorbildung ab. 

� Die Modelle sind so konstruiert, dass sie Analogieschlüsse zulassen: 

„wenn das Mail-Tool geöffnet ist, stürzt die Textverarbeitung bei 

der Rechtschreibprüfung ab“ 

�� Benutzer sind sehr bemüht an diesen Modellen festzuhalten; 

auch dann wenn gedankliche Verrenkungen nötig werden: 

„wenn das Mail-Tool offen ist und mehr als zehn neue Mails 

eingetroffen sind, dann stürzt die Textverarbeitung ab“ 



Seite 25

Entwickler und Anwender … (1/4) 

… spielen einen neuen Dialog durch: 

Entwickler: … So, jetzt hast Du einen Teil der Aufgabe bereits 

ausgeführt. Willst Du nun noch etwas verändern? 

Anwender: Ja, ich möchte eine Komponente löschen. Was muss ich tun? 

E: Deute auf das Menu mit dem Namen ‘CD‘. 

A: CD ? 

E: CD bedeutet ‘Component Delete‘. 

A: OK, ich habe verstanden … Oh, was passiert jetzt? 



Seite 26


E: Du bist jetzt im Analyse-Modus. 

Du musst aus Versehen ‘AM‘ ausgewählt haben. 

A: Ach so, ich dachte, ich hätte ‘CD‘ ausgewählt. 

Wie verlasse ich den Analyse-Modus? 

E: Kein Problem. Gib einfach ‘control Q‘ ein. 

A: [tippt C O N T R O L …] 

E: Nein! Drücke die ‘Strg‘-Taste und die ‘Q‘-Taste. 

A: Wie dumm von mir. … Ich versuch‘s noch einmal. 

… Es passiert gar nichts. Was habe ich falsch gemacht? 



Seite 27


E: Du hast nichts falsch gemacht. Die Komponente ist gelöscht aber 

noch nicht vom Bildschirm entfernt. Gib noch ‘control-J‘ ein. 

A: Ich habe verstanden. Wenn ich die nächste Komponente lösche, gebe 

ich wieder ‘control-Q‘ ein. 

… Hoppla, warum ist der Bildschirm jetzt weiß? 

E: Du hast nur ‘Q‘ eingegeben. ‘Q‘ bedeutet Quit und beendet das 

Programm. Jetzt musst Du leider alles noch einmal eingeben! 

A: Wenn das so ist, machen wir nächste Woche weiter. 



Seite 28


Folgende Fehler wurden gemacht: 

� Kommandos (CD, AM) sind nicht intuitiv 

� erzeugt unnötige Belastung für den Anwender 

� Auf welches Objekt wird das Kommando angewendet? 

� Keine Statusinformation zu Zustandsänderungen 

� Kryptische Kommandos (control-J, control-Q) sind ungeeignet für 

unerfahrene, gelegentliche Benutzer 

�� Kein Feedback bei Delete 

� erzeugt Frustration und Ablehnung bei dem Anwender 

� ergibt Negativausstrahlung auf das Gesamtsystem 



Seite 29

Allgemeine Tipps (1/4) 

� Unklare Verwendung von Dialogbausteine: 

� Element sieht aus wie ein Buttons, es löst aber keine Aktion aus 

� Für exklusive Alternativen werden keine Radiobuttons verwendet 

� Anwender reagieren sensibel auf diese Inkonsistenzen 

� Zu wenig oder kein Feedback 

� Aktionen (Suchen, Filtern, …) müssen bestätigt werden 

� Hinweise auf fehlerhafte Eingaben sollten in räumlicher und 

zeitlicher Nähe erfolgen 

� Meldungen müssen einen Hinweis auf die Fehlerursache geben 

bzw. einen Tipp auf die korrekte Eingabe geben 

� Anwender können nur so den nächsten Schritt planen 



Seite 30


� Unüberwindbare Formulare: 

�� Die Felder sind zu klein für die Texte 

� Tabulatorweiterschaltung ist nicht umgesetzt 

� Die Reihenfolge ist nicht sinnvoll 

� Standardtasten (z.B. Enter-Taste) ist nicht erwartungskonform 

� Anwender ist irritiert und erwartet doch Standardverhalten 

� Abfrage zu vieler Daten an der falschen Stelle 

� Das Anlegen eines Konto etwa vor der ersten (Produkt-)Auswahl 

ist eher hinderlich als verkaufsfördernd 

� Voreinstellungen sinnvoll wählen 

� Vorseinstellungen können Interaktionen beschleunigen 

� Hinweise geben, wie Felder auszufüllen sind 



Seite 31


� Umständliche und zu lange Texte vermeiden 

�� Kurz und prägnant formulieren 

� Aufforderungen, Meldungen und Hinweise leicht verständlich 

angeben 

� Bestätigungen sollten klar erkennbar sein und leicht aufzufinden 

sein 

� Konventionen überraschen den Anwender nicht; 

er „weiß“, was passiert und kann der Anwendung vertrauen 

�� Bedienoberflächen sind kein Selbstzweck! 

Sie sollen helfen, die Aufgabe 

� effizient (mit geringem Aufwand) und 

� effektiv (Aufgabe vollständig lösen) 

zu erledigen 



Seite 32


� Eine gute Bedienoberfläche kann man nicht „berechnen“ 

� Eine gute Bedienoberfläche muss man „erfahren“ 

� Eine geeignete Methode, 

� um die Ideen der Entwickler zu demonstrieren und 

� deren Umsetzbarkeit zu belegen 

und auch 

� um die Anwender frühzeitig zu beteiligen 

ist die Erstellung eines Prototypen 



Seite 33

Ziele (1/2) 

� Benutzerführung gemäß Regeln 

� Motto: Fehlervermeidung statt Fehlerbehebung 

� Trennung von Anwendung und graphischer Benutzungsoberfläche 

� Einheitliches Look-and-Feel 

� Innerhalb einer Applikation und applikationsübergreifend 

� einfache Anpassung von Text und Schrift; 

relative Positionierung ist zusätzlich sehr hilfreich: 

„Componente C1 links von C2 und oberhalb von C3“ 

� Methode 

Dialoge mit Hilfe von Zustände und 

Objekthierarchien (z.B. Fenster) modellieren 



Seite 34

Ziele (2/2) 

� Aufgabenangemessene Präsentation und Interaktion 

� Direkte Manipulation 

� Benutzerunterstützung beim 

� Gestalten und Steuern 

� Erstellen und Modifizieren 

� Inspizieren und Prüfen 

� Navigation(sunterstützung) in komplexen Situationen 

�� Beherrschung der Komplexität und Menge durch 

Informationsaufbereitung: selbsterklärend, kontextbezogene Hilfe 

� Realitätsnähe �� Abstraktion 

� Joy of Use: begeistern, stimulieren, motivieren, überzeugen, fesseln, ... 



Seite 35

Usability-Kriterien 

� Usability-Kriterien sind: 

�� Effizienz (Efficiency) 

• Wenig Interaktion (Benutzer entlasten) 

• Fokussteuerung an Hauptabläufen orientiert (Benutzer führen) 

� Effektivität (Effectiveness) 

• Können alle Aufgaben vollständig gelöst werden? 

� Erlernbarkeit (Learnability) 

• Kann die BO aus der Benutzererfahrung heraus bedient werden? 

�� Erinnerbarkeit (Memorability) 

• Kann man die BO nach einer gewissen Zeit noch sicher bedienen? 

� Zufriedenheit/Wohlbefinden/Spaß (Satisfaction; Emotional Usability) 

• Gestaltung, Feedback, Klarheit 

� Fehlersituation durch Bedienung (Error) 



Seite 36

Usability-Aspekte 

� Struktur (Layout, Design) planen und festlegen 

� Dazu gehört auch 

• Elemente identifizieren 

• Elemente sinnvoll benennen („Sprache der Nutzer sprechen“) 

• Skizze erstellen und 

schrittweise (zunächst abstrakt dann konkret) verfeinern 

� An Anforderungen orientiert: 

• Welche Aufgaben möchte der Benutzer lösen 

� An Aufgaben und Bedürfnissen der unterschiedlichen 

Benutzergruppen angemessen 

• Welche unterschiedlichen Benutzergruppen gibt es? 



Seite 37

Emotional Usability: Joy of Use 

� Merkmale 

� Die Software muss den Benutzer unauffällig unterstützen, indem es 

interessante Funktionen als zu lösende Aufgaben präsentiert und 

Neugier weckt sowie Anreiz zum eigenständigen Lernen gibt 

� Die Aufgabenstellung wird in eine Geschichte integriert 

(und die Bearbeitung einer Teilaufgabe ist ein Schritt in einer 

größeren Aufgabenstellung). 

� Die Glaubwürdigkeit der Arbeitswelt wird durch Konsistenz und 

Aufmerksamkeit für Details gesichert 

(� Erwartungskonformität). 

Quelle: Marc Hassenzahl: Attraktive Software – Was Gestalter von Computerspielen 

lernen können; In: J Machate&M.Burmester: User Interface Tuning; 

Benutzerschnittstellen menschlich gestalten; Software & Support Verlag 2003 



Seite 38

Componenten und Events 

� Componenten (Dialogbausteine) und Events (Dialogbausteine) 

spielen eine zentrale Rolle in grafischen Benutzungsoberflächen 

� Dabei wird ein wiederkehrendes Entwurfsmuster angewendet: 

Observer-Pattern 



Seite 39

Observer Pattern (1/4) 



Seite 40


� Objekte werden über Zustandsänderungen informiert. Gleichzeitig 

soll eine möglichst geringe Kopplung zwischen den beteiligten 

Objekten bestehen. 

� Typisches Anwendungsbeispiel ist, dass es zu einem Objekt 

verschiedene Sichten (Views) gibt, die synchron über Veränderungen 

informiert werden. 

� Dabei übernehmen die Sichten die Rolle des Beobachters 

(Observers) und das Objekt (Observable) selbst wird beobachtet. 

� Es ergeben sich markante Muster zwischen den beteiligten 

Objekten: 



Seite 41


� Das beobachtete Objekt verfügt über die folgenden Methoden: 

� add – füge Beobachter hinzu, 

� remove – entferne Beobachter, 

� notify – benachrichtige Beobachte, 

� get – erfrage Objektzustand und 

� set – setze Objektzustand 

� Das beobachtende Objekt verfügt über Methode(n) zum Aktualisieren 

der Sicht (z. B. refresh). 

� Das Objekt kennt seine Beobachter nicht 

� Das Pattern wird entweder durch Vererbung umgesetzt oder 

durch Implementierung einer Schnittstelle (interface) realisiert. 



Seite 42


� In der konkreten Situation benachrichtigt das überwachte Objekt alle 

Beobachter (Broadcast) 

� Jeder Beobachter entscheidet für sich, wie er mit der Information 

umgeht; 

ggfls. können zusätzlich verschiedene Ereignisse unterschieden 

werden 

� In komplexen Situation (z. B. bei Tabellen) kann es auch zu unnötigen 

Aktualisierungen kommen 



Seite 43

Wie wird das Oberserver-Patern unter 

Java/Swing umgesetzt? 

� Die Componenten können überwacht werden: 

� _____________________ 

_____________________ 

� Beobachter werden angemeldet/registriert: 

� _____________________ 

_____________________ 

� Ereignisse werden an die Beobachter gemeldet: 

�� _____________________ 

_____________________ 



Seite 44

Observer Pattern – Codemuster (1/3) 

import java.util.Observer; 

public class Hauptprogramm { 

public static void main(String[] args) { 

ApplModel ap = new ApplModel(); 

Beobachter b1 = new Beobachter(); 

Beobachter b2 = new Beobachter(); 

ap.addObserver(b1); 

ap.addObserver(b2); 

// löst Benachrichtigung aus: 

ap.setValue("Observer Test"); 

} 

} 



Seite 45


// Observable 

// stellt die Methoden addObserver, notifyObservers bereit 

import java.util.Observable; 


public class ApplModel extends Observable 

{ 

private String value; 

ApplModel() { value = “ “; } 

public void setValue(String s) { 

value = s; 

setChanged(); // z.B. Flag setzen 

notifyObservers(value); // Beobachter informieren 

} 

} 



Seite 46


import java.util.Observable; 


public class Beobachter implements Observer { 

} 

// Methode muss objektspezifisch realisiert werden 

public void update(Observable am, Object value) { 

} 

System.out.println("update: " + am + " " + value); 



Seite 47

Umsetzung des Observer Patterns 

� Wie müssen die Methoden addObserver und notifyObservers 

implementiert sein? 

� _____________________ 

_____________________ 

_____________________ 

_____________________ 

_____________________ 

_____________________ 

�� Wie müssen Sie das bei der GUI-Programmierung unter Java/Swing 

umsetzen? 

� _____________________ 

_____________________ 



Seite 48



Seite 49

Java Crash-Kurs: Interpreter-Prinzip 

� Compiler übersetzt Quellcode in Byte Code 

� Quellcode in .java-Datei 

� Bytecode in .class-Datei 

� Bytecode ist hardware-unabhängiger Befehlssatz für einen 

Interpreter 

• wird z.B. im Internet übertragen 

�� Java Virtual Machine interpretiert Byte Code 

� teilweise zur Geschwindigkeitssteigerung: 

Just-In-Time-Compiler übersetzt Byte Code 

in Maschinencode der Zielhardware 



Seite 50

"Java ist streng objektorientiert" 

� In Java gibt es 

�� dynamische Feldobjekte 

� Laufzeitkontrolle (bzgl. Typen als auch bzgl. Feldgrenzen) 

� Systemunabhängige Festlegung der elementaren Datentypen 

� Garbage Collection ist Bestandteil der Sprache 

� "keine" Pointer �� alle Objektvariable sind Pointer 

� kein call-by-reference 

� keine structs 

� kein Dereferenzieren 

�� keines Pointerarithmetik 

� spezielle Klassen zur Unterstützung der (einfachen) Entwicklung 

internetbasierter Anwendungen 

(Client-Server Komponenten: Applets und Servlets) 

� Hauptprogramme verlieren an Bedeutung 



Seite 51

Java ist streng objektorientiert! 

Java = C++-- 

� Klassen, Objekte, Konstruktoren, Instanziierung wie unter C++ 

Syntax fast wie unter C++ (aber konsequenter) 

� Vererbung/Inheritance 

� Polymorphismus: gleicher Methodenname in unterschiedl. Klassen 

� Überladen: 

• gleicher Methodenname in gleicher Klasse bei unterschiedl. 

Parametern (Typ/Anzahl) 

� kein Überladen von Operatoren 

('+' hat immer die Bedeutung einer Addition; Ausnahme: Strings) 

� "keine" Multiple Inheritance sondern interfaces 



Seite 52

“plattformunabhängig“ 

Informatikervision 

� gut: Wertebereiche primitiver Datentypen sind festgelegt 

� die Sprache ist meist nicht das Problem, sondern die Bibliotheken 

� AWT 1.0, AWT 1.1, Swing, SWT 

� vgl. MFC, OWL, Qt 

� Zugriff auf Betriebssystemfunktionen 

� die Implementation der Virtual Machine und ihrer Bibliotheken wird 

zur neuen Plattform 

�� VMs von Sun, Netscape, Microsoft, ... 

� Versionsnummern ... 

� hohe HW-Anforderung: viel Rechenleistung, viel RAM 



Seite 53

“sicher“ 

� etliche Methoden mittlerweile "deprecated„ (ablehnen, missbilligen), 

weil "inherently unsafe" 

� z.B. Thread.stop(), Runtime.runFinalizersOnExit(...) 

� Ausführungszeitpunkte von finalize und garbage collector undefiniert 

� Zuweisungen für double und long (64-Bit-Werte) sind nicht atomar 

� d.h. können als 2 Maschinenbefehle implementiert und damit 

unterbrechbar sein (müssen aber nicht) 

Programmierer machen in jeder Sprache Fehler... 

� Sie sind nicht von Ihrer Sorgfaltspflicht entbunden! 



Seite 54

“ausgereift“ 

� große Zahl von "deprecated" Klassen, Feldern und Methoden 

� grundlegender Wechsel der Ereignisverarbeitung 

von 1.0 auf 1.1 

� Java war ursprünglich für kleine Anwendungen gedacht; wurde dann 

zur Universalsprache mit vielen Spezialbibliotheken ausgebaut 



Seite 55

Dateitypen und Tools 

auch IDE mit 

GUI-Editor 

� 

� 

� 

Bibliotheken 

LIB 

LIB class 

jar 

mindestens 

eine Klasse 

enthält main 

Editor java Compiler class Virtual Machine 

Editor java Compiler 

class 



Seite 56

Java Development Kit (JDK) 



Seite 57

Entwicklung mit JDK 

� JDK enthält alle nötigen Werkzeuge 

� Aufruf von der Kommandozeile (DOS-Box) 

� Vorgehensweise 

� MeineKlasse.java mit Notepad erstellen 

� JAVAC MeineKlasse.java 

• Compiler-Aufruf; erzeugt MeineKlasse.class 

� SET CLASSPATH=vollständigerPfadname oder auch 

SET CLASSPATH=. 

• damit die Java VM weiß, wo sie die Klassen suchen soll 

� JAVA MeineKlasse 

• Aufruf der Java Virtual Machine (Interpreter) 

• MeineKlasse muß eine Methode main enthalten 



Seite 58

Entwickeln mit 

Eclipse 

�� Project View 

� zugehörige Dateien (Klassen) 

� Structure View (dateibezogen) 

� Source Klasse, Attribute, 

Methoden, Importe 

� Design Elemente der GUI-Oberfläche 

� Content View 

�� Source Text-Editor für mehrere Dateien 

� Design Quelltext, grafischer Editor 

� Doc Dokumentation wenn vorhanden 

� Message View 

� Meldungen von Compiler und VM 



Seite 59

„Hello, World“ 

public class hello { // Datei: hello.java 

public static void main(String[] args) { 

System.out.println ("Hello, World!"); 

} 

} 

� jede .java-Datei enthält genau eine public Klasse 

� Klassenname = Dateiname; Groß-/Kleinschreibung beachten ! 

�� weitere Klassen ohne Angabe von public sind möglich 

� die Java VM braucht ein Klasse mit einer Methode main als Start 

� es gibt keine freistehenden Funktionen/Methoden 

(in einer objektorientierten Programmiersprache) 

� in String[] args werden Kommandozeilenparameter übergeben 



Seite 60

Ausgabe auf die Konsole 

public class System { 

public static PrintStream out; 

} 

public class PrintStream extends FilterOutputStream { 

public void println(String x) {...} 

public void println(Object x) {...} 

} 

� der println-Aufruf verwendet obige Klassen der Standardbibliothek 

System.out.println ("Hello, World!"); 

� println ist überladen für alle einfachen Datentypen boolean, int, ... 

� jede Klasse, die von Object abgeleitet ist, hat eine Methode, die eine 

Textdarstellung des Objekts abliefert: String toString() 



Seite 61

Konsole vs. GUI/GO (I) 

„Hello, World“ ist das Programm, das immer wieder als erstes Beispiel 

herangezogen wird: 

#include 

main () 

{ cout

Konsole vs. GUI/GO (II) 

� Aus heutiger Sicht stellt sie die Situation wie folgt dar: 

�� Verschiedene Programme konkurrieren nicht nur um Speicherplatz und 

Prozessorleistung sondern auch um die Darstellungsfläche 

� Woher kann das Programm wissen, wo (in welchem Kontext) der String 

ausgegeben werden soll? 

� An welcher Position soll der Text ausgeben werden? 

Wenn der Text zentriert ausgeben werden soll, dann müssen zusätzlich 

gerätespezifische Control-Codes angegeben werden 

� Kann das gleiche Programm mehrfach gestartet werden und 

ablaufen ohne dass es sich gegenseitig stört? 

�� Wenn das Programm beendet wurde, ist dennoch die Ausgabe sichtbar. 

Die Ausgabe wird nicht aufgeräumt. 

� Das „Hello, World“-Programm wurde in einer Zeit geschaffen als man ein 

noch sehr einfaches Modell/Verständnis von Interaktion und Präsentation 

hatte. 



Seite 63

Die einfachste GUI-Applikation 

� Hauptfensterklasse abgeleitet von JFrame (extends) 

� Referenz auf einziges Objekt als Klassenvariable ( (static) ) 

� wird von main-Funktion erzeugt 

� Konstruktor gibt Fensterereignisse frei (setvisible();...) 

� processWindowEvent ist zugehörige Behandlungsroutine 

� beendet Java VM mit System.exit(); 

� Untergeordnetes Objekt von JPanel (Fläche, Armaturenbrett) 

�� wird mit add der contentPane (Scheibe, Fläche) zugeordnet 

� Initialisierung diverser Attribute der visuellen Komponenten 



Seite 64

GUI-Applikation mit Eclipse 

� Applikationsklasse enthält eine main-Methode 

� diese wählt das Look & Feel 

� diese erzeugt das Applikationsobjekt 

� der Konstruktor des Applikationsobjekts erzeugt das Hauptfensterobjekt 

und macht es sichtbar 

� Fensterklasse ist abgeleitet von javax.swing.JFrame 

� erzeugt und verwendet ein Border-Layout 

�� gibt sich eine feste Fenstergröße 

ohne gibt es ein 

statisches Layout 

� überschreibt processWindowEvent, um beim Schließen des 

Fensters durch System.exit(0) die VM zu beenden 

nicht am Ende von main ! – warum? 



Seite 65

Allgemein 

� package (1. Anweisung in der Datei) ordnet eine Klasse einem Paket (= 

Gruppe von logisch zusammenhängenden Klassen) zu 

� Die Import Anweisung macht die entsprechende Klasse 

sichtbar/verfügbar 

� instanceof - testet, ob ein Objekt Instanz einer best. Klasse ist: 

... if (obj instanceof class) ... 

� int, float, double, boolean, … sind intrinsic (= elementarer 

Bestandteil), Wrapper-Klassen (Integer, Float, Double, Boolean, …) 

existieren etwa für Typumwandlungen 



Seite 66

Bibliotheken: Packages 

� Package ist ein Ordner im Dateisystem 

� enthält mehrere .java-Dateien und Subpackages (=Unterordner) 

� Zugehörigkeit zu Package package meinpackage; 

� Import-Anweisung macht andere Packages verfügbar 

� eine Klasse: import java.util.ArrayList; 

� alle Klassen: import java.util.*; 

� alle Klassen mit Kurzreferenz: import java.util; 

Kurzreferenz ist dann: util.ArrayList; 

� weltweit eindeutige Namen für wichtige Packages 

� package de.h-da.fbi.projekt.meinpackage; 

� spiegelt die Schachtelung der Ordner wider 



Seite 67

Klassen 

public class NeueKlasse extends Basisklasse { ... } 

�� Konstruktor 

� Vorinitialisierungsliste gibt es nicht 

� super(...) ruft den Konstruktor der Basisklasse auf 

� Attribute können an der Deklarationsstelle 

oder im Konstruktor initialisiert werden 

Ableitung 

� alle Methoden sind standardmäßig virtuell 

�� Schlüsselwort final (="nicht-virtuell") verhindert 

Überschreiben 

� keine separaten Header-Dateien 

� jede Klasse kann zum Testen eine main-Methode haben 



Seite 68

Mutter aller Klassen: class Object 

� viele Klassen sind (indirekt) von class Object abgeleitet 

public class Object 

{ 

public String toString() {...} 

//liefert Textdarstellung des Objekts 

public boolean equals(Object obj) {...} 

// vergleicht Objekt-Inhalte 

protected Object clone() // dupliziert das Objekt 

throws CloneNotSupportedException {...} 

protected void finalize()// Aufruf vor der Garbage Collection 

throws Throwable {...} 

} 



Seite 69

Klassenhierarchie 

class NeueKlasse extends Basisklasse 

implements Interface1, Interface2 

� keine Mehrfachvererbung, nur Einfachvererbung 

� aber Implementierung mehrerer interfaces möglich 

� damit wird das Problem in verschiedenen Basisklassen eventuell 

doppelt vorhandener Elementvariablen umgangen; virtuelle 

Ableitung ist daher überflüssig 

� Besonderheiten 

�� eine Klasse muss mit abstract markiert werden, wenn sie 

abstract Methoden enthält 

� eine abstract Klasse kann nicht instantiiert werden! 

� eine Klasse, die als final markiert ist, kann nicht mehr als 

Basisklasse dienen! 



Seite 70

Objekte 

� Objekte werden immer dynamisch allokiert 

� new liefert einen Zeiger auf das neue Objekt 

� Klasse Objektreferenz = new Klasse (Parameter); 

� delete gibt es nicht 

� dynamisch allokierter Speicher wird automatisch vom Garbage 

Collector freigegeben, nachdem kein Zeiger mehr darauf zeigt 

� der Aufrufzeitpunkt des Garbage Collector ist undefiniert; 

das Laufzeitsystem macht das irgendwann 

� Destruktor gibt es nicht 

� stattdessen Methode protected void finalize(); 

� Aufruf von dem Garbage Collector – d.h. unter Umständen nie ! 



Seite 71

Zur Lebensdauer von Objekten 

„Tricks“ im generierten Code 

� grundsätzlich existiert ein Objekt in Java so lange, wie eine Referenz 

darauf existiert ! 

� manchmal auch ein bisschen länger, 

wie es dem Garbage Collector gerade gefällt 

� warum werden dann die Referenzen in Eclipse GUI-Applikationen nicht 

gespeichert ? 

� das Applikationsobjekt ist tatsächlich nur temporär und insofern 

ziemlich nutzlos – dort sollte man keine Attribute ansiedeln ! 

• main ist auch sofort wieder zu Ende 

� die Klasse Frame verwaltet eine eigene Liste von Referenzen 

auf alle ihre Instanzen – dadurch bleiben diese am Leben 

• jede Instanz hat einen eigenen Thread – dadurch läuft die VM weiter 



Seite 72

Datentypen 

� Primitive Typen 

plattformunabhängig definiert 

� byte (8 Bit), short (16 Bit), int (32 Bit), long (64 Bit), 

alle als vorzeichenbehaftete 2er-Komplementdarstellung 

� char (16 Bit vorzeichenlos, Unicode � Umlaute in Variablen erlaubt) 

� float (32 Bit), double (64 Bit); beide IEEE Standard 754 

� kein enum in Sinne von C++; stattdessen Klassen/Interfaces: 

enum TurtleT {LION, RABBIT, TURTLE, TIGER, MONKEY} 

�� Referenztypen 

� "Zeiger" für Klassen, Interfaces, Arrays 

� C++ macht keinen Unterschied zwischen primitiven Typen und Klassen! 

� neue primitive Typen werden in C++ als Klassen realisiert 

(CBruch, CComplex, CString) 



Seite 73

Initialisierung von Variablen 

� automatisch initialisiert werden 

� Klassenvariable ( = static) ) 

� Instanzvariable ( = Attribute) 

� Array-Komponenten (wenn es sich um Grundtypen handelt) 

� Initialisierungswerte sind 

� 0 für Zahlentypen 

� false für boolean 

�� null für Objektreferenzen 

� lokale Variable werden nicht automatisch initialisiert! 

� Zugriff auf nicht initialisierte Variable bringt Fehler 



Seite 74

Zeichenketten: String 

� Klasse String (ähnlich wie CString in MFC) 

� char* gibt es nicht ! 

(Inhalts- und Addressoperator gibt es nicht) 

� Operand + zur Verkettung 

� akzeptiert Werte beliebiger Typen oder Objekte beliebiger 

Klassen als Operand – verwendet Methode toString() 

� Besonderheit: Operator + allokiert implizit einen neuen String! 

�� class Object hat die Methode toString() 

� liefert eine textliche Repräsentation des Objekts 

� jede abgeleitete Klasse sollte diese Methode sinnvoll 

überschreiben 

� nützlich auch zur Fehlersuche 



Seite 75

Objektvariable: Zeiger versus Referenzen 

� Java Referenzen entsprechen C++ Zeigern: 

� Java Referenz kann null sein 

� man kann damit z.B. verkettete Listen schreiben 

� Zugriff auf Elemente des Objekts mit . statt -> 

� ein Pendant zu C++ Referenzen gibt es nicht! 

� größere Sicherheit gegen Programmierfehler 

� es gibt keine Zeigerarithmetik 

(so kann man sich auch nicht verrechnen...) 

� man kann kein Objekt löschen, auf das noch Zeiger zeigen 



Seite 76

Arrays 

� sicher durch Indexprüfung zur Laufzeit 

� sind dynamisch allokierte Objekte 

� float[] vector = new float[3]; 

� int punkt[] = {40, 50}; 

� float[][] matrix = new float[3][3]; 

� int[][] brett = new int[3][]; // Array mit 3 Referenzen 

brett[0][] = new int[10]; 



�� int brett[3][3]; ist nicht möglich! 

� Array ist eigentlich 1-dimensional 

� array.clone() 

klont auch bei mehrdimensionalen Arrays nur eine Dimension 



Seite 77

Beispiel Turtlegrafik 

� Die Bewegungen einer Schildkröte (Turtle) hinterlassen eine Spur. 

� Zunächst wird eine Linie gezogen von der letzten Position zur aktuellen 

Position. 

� Die Bewegungen nach links, rechts, oben oder unten werden mit Hilfe 

von Buttons gesteuert 

� Auf der Zeichenfläche ist der Punkt (0,0) links oben; 

die x-Werte nehmen nach rechts zu, 

die y-Werte wachsen nach unten 

� Machen Sie sich mit der Klassenbibliothek von Java und deren 

Dokumentation vertraut 

Betrachten Sie folgende Klassen: Graphics, ArrayList, Point, Color… 



Seite 78

Verwenden Sie die Klasse Graphics 



Seite 79

Überlegungen zur Turtlegrafik 

� Werden in der Anwendung keine Standarddialogbausteine verwendet, 

muss die Anwendung selber für sinnvollen Update sorgen - nur sie 

kann wissen, was wirklich geschehen soll - 

� Der Window-Manager kann Ausschnitte, die auf den Desktop (z.B. 

durch Verschieben, Verkleinern oder Iconifizieren anderer Fenster) 

sichtbar werden, nur sehr primitiv rekonstruieren: 

Bitmaps werden kopiert 

� die Anwendung muss den Inhalt verwalten und bei Bedarf aktualisieren 

– die betroffene Klasse muss die paint-Methode implementieren: 

public void paint (Graphics g) 

� Die Klasse ArrayList kann dabei sehr hilfreich sein: 

beliebige Objekte können bequem verwaltet werden 



Seite 80

Die Klasse 

ArrayList 

Quelle: 

http://download.oracle.com/javase/1.4.2/docs/api/java/util/ArrayList.html 



Seite 81

Die Klasse 

ArrayList 

Quelle: 

http://download.oracle.com/javase/1.4.2/docs/api/java/util/ArrayList.html 



Seite 82

… und ein bisschen Kosmetik 

� Fenster zentrieren 

frame.setLocationRelativeTo(null); null 

� Handler für Fensterereignisse: 

protected void processWindowEvent(WindowEvent e) { 

} 

if (e.getID() == WindowEvent.WINDOW_CLOSING) { 

// … versuchen JOptionPane zu verwenden 

System.exit(0); // Java VM beenden 

} 

} else 

super.processWindowEvent(e); // und jetzt das 

Standardverhalten 



Seite 83

Java-Sprachelemente: 

�Abläufe/Workflow 

�exception – throws try catch finally – 

�Iterator �Iterator 

�Casting 

�Instanceof 

�Generizität 

�Zusicherungen (Assertions) 

�Aufzählungstypen: �Aufzählungstypen: enum 

�Property-Dateien 

�Java-Archivdateien: jar 

�strukturierte Kommentare: javadoc 



Exception Handling 

� wie in C++, aber: 

� throw-Deklaration -Deklaration müssen im Funktionskopf angegeben werden 

„public void search () throws NotFoundException … “ 

• der Compiler erzwingt es! 

� alle möglichen Ausnahmen müssen auch eingefangen werden 

� nur für Objekte von Klassen, die von Throwable abgeleitet sind 

• hat als direkte Unterklassen: Error und Exception 

�� try … catch (Exception e) … [finally] 

Die Anweisungen im finally-Block werden grundsätzlich ausgeführt 

� Exception-Konstruktoren haben i. a. String-Objekt als Parameter 

� kann mit e.getMessage() zurück gewonnen werden 



Seite 85

iterator 

Ein Iterator ermöglicht, dass alle Elemente eines Collection-Objekts kontrolliert 

(Element für Element) durchlaufen wird. Der Iterator ist ein interface, welches von 

allen Collections (Set, HashSet, SortedSet, List, ArrayList) implementiert ist und die 

folgende Schnittstelle zu Verfügung stellt: 

public boolean hasNext() true, wenn noch ein Element existiert 

public Object next () liefert jeweils das nächste Element 

public void remove() entfernt, das zuletzt mit next 

angesprochene Element 

Beispiel: 

for (Iterator x = menge.iterator(); i.hasNext()) 

System.out.println (x); 

oder (vereinfachte Schleife) 

for (Object x : menge) System.out.println (x); 



Seite 86

Typumwandlung/Casting (I) 

� Typumwandlung zwischen primitiven Typen ist wohldefiniert 

� nicht einfach Uminterpretation des Bitmusters 

� keine beliebigen Casts zwischen irgendwelchen Datentypen (Java 

ist da sehr streng!) 

� Typumwandlung zwischen Objektreferenzen wird zur Laufzeit 

überprüft 

�� nur die Umwandlung zwischen Basisklasse und abgeleiteter 

Klasse ist zulässig 

� Umwandlung einer Objekt-Instanz in ein spezifisches Objekt geht 

– wenn es sich tatsächlich um ein entsprechendes Objekt handelt 



Seite 87

Casting 

class zahl 

{ int z; 

zahl () 

{ z = 0; 

System.out.println 

("Wert von z ist "+ z); 

} 

} 

public class demo 

{ positive p; 

public void init (){ 

} 

} 

zahl z = (zahl)new positive(30); 

class positive extends zahl 

{ positive (int i) 

{ z = i; 


("Wert von z ist "+z); 

} 

} 

// Casting geht nur entlang der Klassenhierarchie 

// p = (positive) z;// geht nicht, wenn z ein zahl-Objekt ist! 

p = new positive (20); 



Seite 88

instanceof 

� Die ArrayList allMyTickets beinhaltet unterschiedliche Tickets: 

FatalError, Exception, Warning, Hint. 

Es sollen Merkmale geprüft werden. instanceof liefert eine Aussage 

darüber, welche Klasse ein Objekt instanziiert: 

public class FatalError 

{public String showCrashed (){return “Crashed“;} } 

public class Exception 

{public String showSystemDown (){return “Down“;} } 

public class Warning 

{... public String showWarning (){return myWarning;} } 

public class Hint 

{... public String showHint (){return myHint;} } 



Seite 89

instanceof 

for (int i = 0; i < allMyTickets.size(); i++) 

{ 

} 

Object x = allMyTickets.get(i); 

if (x instanceof FatalError) 

System.out.println(( (FatalError)x).showCrashed()); 

if (x instanceof Exception) 

System.out.println(((Excpetion)x).showSystemDown()); 

if (x instanceof Warning) 

System.out.println(((Warning)x).showWarning()); 

if (x instanceof Hint) 

System.out.println(((Hint)x).showHint()); 



Seite 90

Generizität – Generische Klasse 

� Idee: allgemein nutzbare Klasse, die gleichzeitig Typsicherheit 

gewährleistet (siehe auch ArrayList): 

public class GenericObject 

{ 

} 

private T t1, t2; 

public T gett1 () 

{ return t1; } 



Seite 91

assert 

� Seit Java 1.4 bietet Java eine elegante Lösung für die Überprüfung von 

Annahmen/Bedingungen - sogenannter Assertions (Zusicherungen): 

Beispiel: 

... 

boolean ok = list.isEmpty(); 

Exception 

assert ok; (oder: assert expr1 : string_expr2 ) 

� Java überprüft während der Ausführung den Zustand der Variablen ok. 

Wird der Wert der Variablen false, wird ein AssertionError (Error 

extends Throwable) geworfen. Dies verringert die 

Wahrscheinlichkeit, dass ein Programmierfehler unentdeckt bleibt. 

� Das Programm muss mit javac .source 1.4 asserttest.java compiliert 

und mit java -ea assertest (enable assertions) ausgeführt werden. 



Seite 92

assert - Beispiel 

class Asserttest 

{ 

public static double kehrwert (double x) 

{ 

assert x != 0 : ">>> Division durch 0

Aufzählungstypen – Enumeration 

� Syntaktisch ähnelt die Deklaration eines Aufzählungstyps der einer 

Klasse: 

public enum TicketCategory { 

} 

Software, Hardware, Bedienung, Betriebssystem, 

Netzwerk 

� Jedes durch die Deklaration eines Aufzählungstyps festgelegten enum- 

Objektes besitzt automatisch die Instanzmethoden: 

� String toString(), boolean equals (Object o), int ordinal() und values() 

... 

for (TicketCategory tc : TicketCategory.values()) 

System.out.println(tc + “ hat den Wert “ + tc.ordinal()); 



Seite 94

Interface 

Spezialfall einer abstrakten Klasse 

� ein Interface ist eine abstrakte Basisklasse ohne Elementvariablen, 

besteht also ausschließlich ausschließlich aus 

� abstrakten Methoden (abstract = entspricht virtuell in C++) 

� Konstantendefinitionen (public final static …) 

� lokalen Klassen 

� spezielle Form der Vererbung 

class Klasse implements Interface 

�� die Klasse muss alle Methoden des Interface implementieren 

� ein Programm hat eine Interfacereferenz und ruft deren 

Methoden auf 

� die Interfacereferenz zeigt dann auf Objekte von Klassen, 

die dieses Interface implementieren 



Seite 95

Interfaces am Beispiel Turtlegrafik 

� In der Grafik sollen verschiedene Symbole/Spuren möglich sein 

� Festgelegt wird einerseits das Verhalten 

� es muss eine spezielle paint-Methode geben interface 

� … 

� Objektmerkmale, die allen gemeinsam sind, 

werden identifiziert und zusammengestellt 

abstract class 

� Vorteil: 

Der Objektverwaltung ist es egal, um welches Objekt es sich in einem 

konkreten Fall handelt (jedes Objekt weis alleine, was es tun muss) 

+ Erweiterbarkeit 

+ Pflege und Wartung 

+ bei der Verwaltung der Objekte sind spezielle Merkmale nicht relevant 



Seite 96

Turtle, Lion, Rabbit 



Seite 97

Aufzählungstyp 

enum TraceType { 

}; 

Lion, Monkey, Rabbit, Tiger, Turtle 



Seite 98

interface Trace 

interface Trace 

{ 

} 

public void paint (Graphics g); 

public int getX(); 

public int getY(); 

KEIN Konstruktor! 

Jedes Objekt 

muss sich im 

angegebenen 

Kontext selbst 

darstellen 

diese Methode müssen 

alle Objekte besitzen 



Seite 99

abstract class genericTrace 

abstract class genericTrace 

{ 

} 

Point position; 

kann in allen 

Subklassen 

verwendet werden 

Muss aufgrund von 

getX(), getY() 

interface 

implementieren 

es gibt keine 

Objekte/Instanzen 

dieser Klasse! 



Seite 100

class Rabbit extends 

genericTrace implements Trace 

class Rabbit extends genericTrace implements Trace 

{ 

int radius; 

Rabbit (int x, int y, int r) 

{ 

position = new Point (x,y); 

radius = r; 

} 

spezifische 

Attribute 

klassenspezifischer 

Konstruktor 


{ 

g.drawOval( position.x-radius/2, position.y-radius/2, 

radius, radius); 

} 

} objektspezifisches 

Verhalten 



Seite 101

class Lion extends 

genericTrace implements Trace 

class Lion extends genericTrace implements Trace 

{ 

int width, height; 

Lion (int x, int y, int w, int h) 

{ 

position = new Point (x,y); 

width = w; 

height = h; 

} 


spezifische 

Attribute 

klassenspezifischer 

Konstruktor 

{ 

g.drawRect( position.x-width/2, position.y-height/2, 

width, height); 

} 

} 



Seite 102

SingletonPattern zu Objektverwaltung (1/2) 

public class TraceContainer 

{ 

/** Verwaltung aller Objekte */ 

public static ArrayList allTraces; 

public static int x = 0, y = 0; 

private static TraceContainer instance = null; 

/* private Default-Konstruktor, der nicht außerhalb dieser Klasse */ 

private TraceContainer () {} 

/* Methode, liefert die einzige Instanz dieser Klasse zurück */ 

public static ArrayList getInstance() { 

} 

if (instance == null) instance = new TraceContainer (); 

return instance; 



Seite 103

SingletonPattern zur Objektverwaltung (2/2) 

public void add (TraceType animal, int x, int y) { 

Trace trace; 

trace = TraceFactory (animal, x, y); 

allTraces.add(trace); 

} // add 

public void paint (Graphics g) { 

for (int i = 0; i < allTraces.size(); i++) 

(allTraces.elementAt(i)).paint(g); 

} // paint 

/* Bei Bedarf weitere Methoden 

... Z.B. ein Factory Pattern 

*/ 



Seite 104

FactoryPattern zum Erzeugen der Spuren 

private Trace TraceFactory(TraceType animal, int posx, int posy) { 

Trace aNewTrace; 

int width = 5, height = 8; 

String anId = "T"; 

switch (animal) { 

case Lion: aNewTrace = new Lion(posx, posy, width, height); 

break; 

case Tiger: aNewTrace = new Tiger(posx, posy, anId); 

break; 

case Monkey: Image img = 

Toolkit.getDefaultToolkit().createImage("cross.gif"); 

aNewTrace = new Monkey(posx, posy, img); 

break; 

case Turtle: 

case Rabbit: 

default: aNewTrace = new Rabbit(posx, posy, 8); 

} 

return aNewTrace; 

} 

} //TraceContainer 



Seite 105

Dateihandling: übliche Vorgehensweise 

Lesen von Datei (Schreiben entsprechend): 

Verbindung zur Datei herstellen fin = fopen ("name.txt", "r"); 

// Datei und Zugriffsmodus! 

Lesen 

� zeilenweise fgets (100, str, fin); 

� byteweise fread(fin, 100, feld); 

� formatiert fscanf (fin, "%d %d %d", &x, &y, &z); 

Datei schließen, Verbindung beenden fclose (fin); 

Weitere Formen sind möglich, z.B. 

� Eingabe puffern 

�� in Stream schreiben 

� 

oder 

über Netz auf anderen Daten zugreifen 

� 

ABER: 

aus einem String lesen: sscanf (fin, "%d %d %d", &x, &y, &z); 

Die Lesebefehle sind nicht unabhängig von dem Objekt (z.B. „lies etwas, egal woher, Methode von Object“) 

� Java handhabt dies streng(er) objektorientiert! 



Seite 106

Ein- und Ausgabeströme 

Pipe 

Pipe 

Datei 

Zeichenkette Bytefeld 

Format Puffer 

Eingabefilter 

Verarbeitung 

Format Puffer 

Ausgabefilter 

Datei 

Zeichenkette Bytefeld 



Seite 107

I/O unter Java:Ein Beispiel für Kapselung 

Objekt 

Einzelne Zugriffsoperationen 

Zugriff (lesend,schreibend) 

� Objekt 

� File (lokal,via Netz) 

� Stream 

� String 

� Zugriff 

� lesend/schreibend 

� Gepuffert 

� Klartext/binär/… 

�� Zugriffsoperation 

� Grundtyp 

� Objekt 



Seite 108

Kommunikation zwischen Programmen: 

Streams 

� Streams 

� Transparente Operationen 

� Kontinuierlicher Zugriff 

Daten/Objekte 

Schreiben Lesen 

Stream 

� Objektorientiert 

� interface Serializable erlaubt bequemes Lesen und Schreiben von Objekten 

� Objekte werden dadurch in einem internen Format gespeichert und gelesen. 

� java.io.Serializable ist ein sogenanntes "flag interface„, d.h. es enthält keine einzige 

Deklaration einer Methode, die man implementieren muss. 

� Die beim Serialisieren benutzte Methode writeObject wird standardmäßig vom 

Runtimesystem bereitgestellt. 

� eignet sich sehr gut für das temporäre Speichern von Objekten zwischen 

Programmläufen (� persistente Objekte/Applikationen) 

� Weitere Möglichkeit: java.io Externalizable 



Seite 109

Auswirkung auf die Anwendungsklassen 

im Beispiel Turtlegraphik 

� Die Ergänzungen in unseren Anwendungsklassen sind sehr gering: 

� abstract class genericTrace implements Serializable 

. . . 

� class Rabbit extends genericTrace implements Trace, 

Serializable 

. . . 

� class Turtle extends genericTrace implements Trace, 

Serializable 

. . . 



Seite 110

Serialisiertes Speichern 

public void speichern() 

} 

{ 

// “import java.io.*;“ angeben! 

try 

{ 

} 

Aufruf erfolgt bei 

Programmende 

FileOutputStream fos = new FileOutputStream ("stream.tmp"); 

ObjectOutputStream oos = new ObjectOutputStream (fos); 

oos.writeObject (spuren); 

System.out.println("schreiben: " + spuren.size()); 

catch (Exception e) 

{System.out.println("Exception (schreiben):"+e.getMessage()); } 



Seite 111

Serialisiertes Laden 

public void laden() 

{ 

//import java.io.*; 

try 

{ 

FileInputStream fis = new FileInputStream ("stream.tmp"); 

ObjectInputStream ois = new ObjectInputStream (fis); 

spuren = (ArrayList)ois.readObject (); 

System.out.println("lesen: "+spuren.size()); 

} 

catch (Exception e) 

{System.out.println("Exception (laden):"+e.getMessage()); } 

}// laden 

Aufruf erfolgt im 

Konstruktor 



Seite 112

Dateien unter Java lesen 

// Datei zeilenweise lesen 

// import java.io.*; 

File eingabedatei = new File (“eingabe.dat“); 

FileReader fr = new FileReader(eingabedatei); 

BufferedReader br = new BufferedReader (fr); 

line = br.readLine(); 

while (line != null) 

{ 

... 

line = br.readLine(); 

}// while 



Seite 113

Lesen aus einem jar oder via Internet 

� Um das Laden aus einem jar zu ermöglichen, wird statt des direkten 

Dateinamens die folgende Konstruktion eingesetzt: 

� URL filename = getClass().getResource(„myFile.dat"); 

� Beispiel: 

� try { 

URL url = this.getClass().getResource("nicelogo.gif"); 

myicon = new ImageIcon(url); 

myLabel.setIcon(iicon); 

} 

catch (Exception e){ } 

� try { 

InputStream is; 

URL url = his.getClass().getResource("parameter.prop"); 

is = url.openStream(); 

Properties p = new Properties(); 

p.load(is); 

} 

catch (Exception e){ } 



Seite 114

Vereinfachte Eingabe (ab Java Version 5.0) 

import java.util.Scanner; 

import java.io.*; 

... 

File f = new File("numbers.dat" ); 

Scanner sc = new Scanner( f ); 

while (sc.hasNextLong()) 

{ 

} 

long aLong = sc.nextLong(); 

... 



Seite 115

Datei schreiben 

// import java.io.*; 

// - in ASCII Datei schreiben -------- 

FileWriter fw; 

String zeile = "Hello World"; 

try 

{ 

fw = new FileWriter (“strings.dat"); 

fw.write (zeile); 

fw.write ("\n"); 

fw.close(); 

} 

catch (FileNotFoundException e) {} 

catch (IOException e) {} 



Seite 116

Property-Dateien 

� Um ein Programm einfacher konfigurieren bzw. (an sprachliche 

Anforderungen) anpassen zu können, bietet es sich an, Zeichenfolgen 

aus einer Konfigurationsdatei einzulesen. In Java wird dies mit der 

Klasse java.util.Properties unterstützt. 

� Dateien, oder allgemeiner Eingabe-Streams, in denen Properties 

definiert sind, können mit der Methode load() der Klasse 

java.util.Properties gelesen werden. 

�� In der Datei werden paarweise Property-Name und Property-Wert 

aufgeführt. 

� Kommentar beginnt mit dem Zeichen # oder ! Und steht in einer 

separaten Zeile. 



Seite 117

Property-Dateien 

# einfaches Beipiel 

bezeichner=H.-P. Wiedling, 2011 

// Properties lesen 

String copyright = ““; 

try 

{ 

InputStream is; 

is = new URL 

(getDocumentBase(),"parameter.properties").openStream(); 

// oder 

// InputStream is =new FileInputStream ("plan.prop"); 

Properties p = new Properties(); 

p.load( is ); 

copyright = p.getProperty("bezeichner"); 

} 

catch (Exception e ) 

{ 

System.out.println (e.getMessage()); 

System.out.println ("plan.prop Fachbereich Informatik: nicht 3. gefunden?!"); 

Semester Bachelor Studiengang 

} 


... 

Property-Datei parameter.properties: 

Bezeichner, Trennzeichen (=, : oder Whitespace), 

Wert des Bezeichners 

Seite 118

... und als ResourceBundle ist die Datei 

einfach verfügbar 

import java.util.MissingResourceException; 

import java.util.ResourceBundle; 

public class Messages { 

private static final String BUNDLE_NAME = "parameter"; 

private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle 

.getBundle(BUNDLE_NAME); 

private Messages() { } 

public static String getString(String key) { 

try 

{ return RESOURCE_BUNDLE.getString(key); } 

catch (MissingResourceException e) 

{ return '!' + key + '!'; } 

} 

} 

Aufruf: 

Messages.getString(„bezeichner") 



Seite 119

Java-Archive (I) 

� jar ist ein Werkzeug, mit dem Java-Archivdateien erzeugt und verändert 

werden können. Eine jar-Datei ist eine ZIP-Datei; 

sie enthält i. d. R. kompakt mehrere Dateien. 

C:>jar 

Syntax: jar {ctxu}[vfm0Mi] [JAR-Datei] [Manifest-Datei] [-C dir] Dateien ... 

Optionen: 

-c neues Archiv erstellen 

-t Inhaltsverzeichnis für Archiv auflisten 

-x benannte (oder alle) Dateien aus dem Archiv extrahieren 

-u vorhandenes Archiv aktualisieren 

-v ausführliche Ausgabe für Standardausgabe generieren 

-f Namen der Archivdatei angeben 

-m Manifestinformationen aus angegebener Manifest-Datei einbeziehen 

-0 nur speichern; keine ZIP-Komprimierung verwenden 

-M keine Manifest-Datei für die Einträge erstellen 

-i Indexinformationen für die angegebenen JAR-Dateien generieren 

-C ins angegebene Verzeichnis wechseln und folgende Datei einbeziehen 



Seite 120

Java Archive (II) 

Falls eine Datei ein Verzeichnis ist, wird sie rekursiv verarbeitet. 

Der Name der Manifest-Datei und der Name der Archivdatei müssen in der gleichen 

Reihenfolge wie die Flags 'm' und 'f‚ angegeben werden. 

Beispiel 1: 

Archivieren von zwei Klassendateien in einem Archiv mit dem Namen 

classes.jar: 

jar cvf turtle.jar helloworld.class frame.class 

Beispiel 2: 

Verwenden der vorhandenen Manifest-Datei ‘manf‘ und archivieren aller Dateien im 

Verzeichnis mygui/ in 'classes.jar': 

jar cvfm turtle.jar manf -C mygui/ 



Seite 121

Java Archive: Manifest 

manf 

Main-Class: mygui/Main 

Sealed: true 

Main-Class: class-Datei, die main-Methode enthält 

Sealed: benötigte Pakete sind Bestandteil der Archivdatei 



Seite 122

Archivdateien 

Archiv anlegen 

� jar cvfm turtle.jar manf mygui/*.class 

� c: create 

� v: verbose (d.h. Meldungen anzeigen) 

� f: Archiv, welches erzeugt wird 

� m: Manifestdatei 

Archiv ausführen 

�� java -jar turtle.jar 

eclipse 

� Unter eclipse werde unter dem Menüpunkt "Export/Java.." .jar 

erstellt. Dort werden auch weitere Einstellungen (z.B. Main- 

Class) vorgenommen 



Seite 123

Archive (jar) 

� Classpath: 

set path=%; C:\JBuilder2007\jre\bin 

set CLASSPATH=%;. 

� Manifest (Datei manf): 

Main-Class: mygui/Main 

Sealed: true 

� Erstellen: 

jar cvfm turtle.jar manf *.class 

erzeugt eine jar-Datei mit allen *.class Dateien; manf ist eine Datei, die 

Informationen enthält über Klasse mit der main-Methode (sog. Manifest) 

� jar-Datei ansehen 

jar tvf turtle.jar 

� Starten: 

java -jar turtle.jar 



Seite 124

Zugriffsrechte 

� public, protected, private wie in C++ 

� jedes Element hat sein eigenes Zugriffsrecht 

� Definition gilt (im Gegensatz zu C++) nicht für die nachfolgenden 

Elemente 

� ohne Angabe bedeutet: 

� private für Klassen 

� public für Interfaces 

�� für Attribute und Methoden 

• protected innerhalb des eigenen Packages 

• private außerhalb des eigenen Packages 

� zur Sicherheit immer angeben 



Seite 125

(Auswahl von) Modifier (I) 

� void, int, long, normaler Rückgabewert; 

float, double, 

boolean, char,... 

spez. Obj. 

� Konstruktoren haben KEINEN Rückgabewert 

� private Methoden/Komponenten können nur 

klassenintern verwendet werden 

� protected Das Element ist nur innerhalb des Paketes zu 

erreichen, in dem es definiert ist sowie über 

entsprechende Subklassen 

� public Methoden/Komponenten/Klasse/Interface 

stehen für Aufrufe von außen (=überall) zur 

Verfügung. 



Seite 126

(Auswahl von) Modifier (II) 

� ohne Zugriff ist innerhalb des Paketes möglich 

(oft als "friendly" oder "package private " 

bezeichnet). 

� final Komponenten: Konstanten, die 

unmittelbar mit einem Wert versehen werden 

Bei Klassen verhindert das Schlüsselwort die 

weitere Verfeinerung der Klasse. 

Bei Methode: die Methode kann nicht 

überschrieben werden. 



Seite 127

(Auswahl von) Modifier (III) 

� static klassenweite Methoden/Komponenten, sie 

sind nicht an best. Objekte gebunden 

(das dann auch nicht zur Verfügung steht); 

sie werden so auch mit dem Klassennamen 

aufgerufen und nur einmal initialisiert, wenn 

das Programm geladen/initialisiert wird 



Seite 128

(Auswahl von) Modifier (IV) 

� abstract Klassen die eine abstract Methode 

beinhalten müssen als abstract deklariert 

werden. Abstrakte Klassen enthalten 

nicht implementierte Methoden und 

können nicht instanziiert werden. 

Abstracte Methoden müssen auch 

implementiert werden, sie werden allerdings 

in Subklassen spezifisch überschrieben 

(vgl. virtual in C++) 

Wenn es nur abstract Methoden gibt, dann 

kann man die Klasse auch als interface 

deklarieren. Bei interfaces ist der 

Modifikator optional 



Seite 129

Sichtbarkeit 

Public Protected Package Private 

Gl. Klasse Ja Ja Ja ja 

Klasse im gl. Paket Ja Ja Ja Nein 

Subklasse in 

anderem Paket 

Nicht Subklasse, 

and. Paket 

Ja Ja Nein Nein 

Ja Nein Nein Nein 



Seite 130

Vorgehensweise bei Entwurf und Doku 

� Analyse der Benutzergruppen 

� Anwendungsfälle (Use Case Diagramm, UML) 

� Workflow (Geschäftsprozess) 

� zeitliche Verkettung einzelner Use Cases 

(�Flussdiagramm, PAP) 

� abstraktes Screen-Diagramm 

� Bedien- und Anzeigeelemente nur aufgelistet 

�� konkretes Screen-Diagramm 

� Detailliierte Layout-Skizze 

� Sequenzdiagramm (UML) 

� jeder Screen wird Objekt einer eigenen Klasse 



Seite 131

Benutzergruppen charakterisieren 

� welche Leute sollen mit dem System arbeiten? 

� was sind ihre eigentlichen Aufgaben und Ziele ? 

� in welchem Zusammenhang nutzen sie das System ? 

� wie kann man sie im Hinblick auf das System charakterisieren ? 

� seltene / häufige / ständige Nutzer, 

Anfänger / Fortgeschrittene / Profis 

• bezüglich der Anwendung 

• bezüglich Rechner und Betriebssystem 

� interessiert / widerwillig ? lernfähig / starr ? 

im Stress ? 

Der DAU ist nicht blöd ! 

Er hat oft einfach nur 

Wichtigeres zu tun 

� problematisch: 

Wie viel Kontextwissen (� inhaltliche Tiefe und Terminologie) ist 

erforderlich? 



Seite 132

Benutzerzentriertes 

Requirement Engineering 

� Ausgangspunkt muss der/die Benutzer/-in sein mit den Aufgaben, 

die er/sie bewältigen muss: 

� Benutzer beschreibt Aufgabe (umgangssprachlich, informell) 

� Interviewsituationen (Frage-Antwort-Spiel) werden in Form von 

Protokollen festgehalten 

� Aus dem Text ergibt sich ein Modell, das die reale Situation auf die 

benötigten Merkmale vereinfacht: 

Klassen, Methoden, Attribute, … 

� Eine Orientierungshilfe kann die Methode von Abbott sein: 



Seite 133

Beispiel Fahrkartenautomat 

� kleine, große, alte, junge, mit Sehschwäche ... 

� wegfahren zu Termin / Besuch / Urlaub ... 

� ganz unterschiedliche Nutzungshäufigkeit 

� Einmal im Jahr, täglich; vertraute vs. Fremde Ziele 

� interessiert? Nein 

� Es geht nicht um den Fahrkartenautomat – es geht um die Reise! 

�� lernfähig? Manche 

� Das nächste Mal soll‘s besser klappen 

� Stress? aber sicher! 

� Die (Straßen-)Bahn droht abzufahren! 



Seite 134

Beispiel Stundenplanungssystem 

� Sekretärin: Eingabe von Wunschzetteln 

Ausdrucken von Plänen 

Beantworten von Anfragen 

� Prodekan: Lehrveranstaltungsplanung 

(wer macht was) 

� Stundenplaner: Stundenplanung 

(wann und wo) 

Anwendungswissen ist erforderlich! 

� charakterisieren Sie die Benutzergruppen ! 



Seite 135

Anwendungsbeispiel Ticketsystem (1/2) 

� Trouble-Ticket- bzw. Help-Desk-Systeme sind sehr gut geeignet, um 

den Fortgang der Bearbeitung gemeldeter Problembeschreibungen 

zu beobachten. 

� Kunden können die Bearbeitung direkt verfolgen und die 

Serviceorientierung eines Dienstleistungsunternehmens 

nachvollziehen. Außerdem kann eine Wissensbasis für die Bearbeiter 

aufgebaut werden. 

Quelle: http://de.wikipedia.org/wiki/Issue-Tracking-System (Stand: 

Mai 2010) 



Seite 136

Anwendungsbeispiel Ticketsystem (2/2) 

� Mit einem Ticketsystem werden 

�� also Problemsituationen erfasst und ein Vorschlag einer ersten 

Kategorisierung gemacht 

� anschließend erfolgt mit ihrer Hilfe eine Zuordnung zu einem 

Mitarbeiter 

� daneben auch festgehalten, in welchem Bearbeitungszustand des 

Tickets ist; Durch einen Kommentar werden nach Behebung des 

Fehlers die Ursache und der Test (kurz) erläutert und dieser 

ebenfalls vermerkt; 

� die Kategorisierung gegebenenfalls korrigiert 

� nach Test und Qualitätskontrolle (der Test wird von einer 

weiteren Person nachvollzogen – Stichwort „Vier-Augen-Prinzip“) 

wird das Ticket freigeben. 



Seite 137

Anwendungsfälle (Use Cases) 

� High-Level-Beschreibung eines Systems Wie findet man 

� skizziert die Benutzergruppen 

Use Cases? 

� skizziert, was diese mit dem System machen 

� das System wird als Black Box betrachtet 

� rückt den Menschen ins Blickfeld ! 

� nicht Datenstrukturen und -flüsse 

� beschreibt nicht die Struktur des Systems ! 

� Teil der Unified Modeling Language UML 

� wird durch andere Diagrammtypen verfeinert 

Man frage 

unvorbelastete 

Benutzer: 

"Was wollen Sie tun?" 

�siehe entsprechende 

Vorlesung 



Seite 138

Die Methode Abbott (1/3) 

� KISS – Keep it simple and stupid: 

Halte es einfach und leicht verständlich 

� Gehen Sie schrittweise vor und verfeinern Sie dabei Ihren Entwurf 

� Wenden Sie das Paradigma „code a little, test a little“ auf den 

gesamten Prozess an und setzen Sie „Peer-Review“ sein 

� Ausgangspunkt für eine umgangssprachliche Beschreibung der 

Aufgaben der Benutzer sein, die zu bewältigen sind: 

�� Benutzer beschreiben ihre Aufgabe (umgangssprachlich, 

informell) 

� Interviewsituationen (Frage-Antwort-Spiel) werden in Form von 

Protokollen festgehalten 



Seite 139


� Aus dem Text ergibt sich ein Modell, das die reale Situation auf die 

benötigten Merkmale vereinfacht: 

� Klassen 

� Methoden 

� Attribute 

� Instanzen, … 

�� Ein Einstieg, eine Orientierungshilfe kann die Methode von Abbott 

sein: 



Seite 140


� Abbott hat bereits 1983 gezeigt, dass sich eine verbale Spezifikation 

(� (� Erstellung von Use Cases) als Grundlage eines Entwurfs eignet. 

� Er empfiehlt ein Vorgehen, bei dem bestimmte Wortarten (Hauptund 

Zeitwörter) in der Spezifikation gesucht werden und aus ihnen 

der Entwurf abgeleitet wird. 

�� Abbott hat abstrakte Datenstrukturen und Operationen gebildet. Es 

hat sich gezeigt, dass dieses Verfahren auch als Grundlage für einen 

objektorientierten Entwurf verwendet werden kann. 

Man geht dabei etwa nach folgendem Schema vor: 



Seite 141

Vom Problem zur Problemlösung (1/3) 

� Herausfiltern von Hauptwörtern 

Die Relevanz eines Hauptwortes hängt von seiner Art ab 

� Gattungsnamen („Ticket, Kunde, Sachbearbeiter, …“) spielen eine 

zentrale Rolle; jeder dieser Begriffe ist ein Kandidat für eine Klasse 

� Eigennamen dienen als Bezeichner für bestimmte Objekte („mein 

Ticket, …“). Sie können indirekt auch zur Klassenbildung führen 

(„Kategorie, Administrator , …“) 

� Mengen- und Größenangaben („MByte, Liter…“) sowie 

Materialbezeichnungen („Holz, …“) eignen sich oft nicht zur Bildung 

von Klassen; entsprechendes gilt für abstrakte Begriffe („Arbeit, 

Leistung, Schönheit, …“) 

� Zeitwörter, die als Hauptwörter verwendet werden, deuten auf 

Aktionen hin und können Methoden werden 



Seite 142


� Dies kann nur eine erste Orientierung sein. 

Falsche Granularität des Entwurfs (zu fein - zu grob) zwingt i. d. R. den 

Entwurf zu verbessern! 

� Suchen von Gemeinsamkeiten 

Die Antwort auf die Frage „Gleich oder verschieden“ geht oft aus der 

Aufgabe hervor. Wenn für zwei verwandte Begriffe feststeht, dass sie 

verschiedene Dinge bezeichnen, sollte geklärt werden in welcher 

Beziehung sie stehen. So entstehen „Ist-ein-Beziehungen“ und damit 

Klassenhierarchien („Jeder schwerwiegender Fehler ist auch ein 

Ticket“) oder Attribute („Jedes Ticket hat einen Zustand und eine 

Beschreibung“). 



Seite 143


� Auffinden von relevanten Zeitwörtern 

Zeitwörter bezeichnen Aktionen mit Objekten. Sie stehen immer in 

Verbindung mit Objekten bestimmter Klassen. Aus den Zeitwörtern 

können Methoden gebildet werden, die auf die entsprechenden 

Objekten angewendet werden: 

� „… Alle Tickets werden für den Administrator in einer Übersicht 

dargestellt; er ordnet Tickets einem Sachbearbeiter zu; wenn die 

Ticketbehandlung überprüft wurde, dann wird das Ticket 

freigegeben, …“ 



Seite 144

� Anwendungsbeispiel Ticketsystem (1/2) 

� Trouble-Ticket- bzw. Help-Desk-Systeme sind sehr gut geeignet, um 

den Fortgang der Bearbeitung gemeldeter Problembeschreibungen 

zu beobachten. 

� Kunden können die Bearbeitung direkt verfolgen und die 

Serviceorientierung eines Dienstleistungsunternehmens 

nachvollziehen. Außerdem kann eine Wissensbasis für die 

Bearbeiter (Sachbearbeiter, Administrator) aufgebaut werden. 

Quelle: 

http://de.wikipedia.org/wiki/Issue-Tracking-System (Stand: Mai 2010) 



Seite 145

� Anwendungsbeispiel Ticketsystem (2/2) 

� Mit Ticketsystemen werden also Problemsituationen erfasst und ein 

Vorschlag einer ersten Kategorisierung gemacht. 

� Mit Hilfe des Ticketsystems wird anschließend eine Zuordnung zum 

Mitarbeiter hergestellt. Daneben hält das Ticketsystem auch fest, in 

welchem Bearbeitungszustand des Tickets ist: 

• neu_erfasst, in_Bearbeitung, bearbeitet, getestet, freigegeben 

� Durch einen Kommentar werden nach Behebung des Fehlers die 

Ursache und der Test (kurz) erläutert und ebenfalls vermerkt; die 

Kategorie(n) werden gegebenenfalls korrigiert. Nach Test und 

Qualitätskontrolle (der Test wird von einer weiteren Person 

nachvollzogen – Stichwort „Vier-Augen-Prinzip“) wird das Ticket 

freigeben. 



Seite 146

Darstellung/Beschreibung eines Use Cases (1/2) 

� Die graphische Beschreibung eines 

Anwendungsfalls hält neben dem 

System die (Haupt-)Akteure 

und die von ihnen 

durch geführten 

Aktionen fest. 

Kunde/Client 

� Eine Aussage 

über die Struktur des Systems 

wird dabei nicht gemacht. 

erstellt 

neu 

sichtet 

Ergebnis 

prüft, 

gibt frei 

sichtet 

beschreibt 

Problem- Problemlösung 

korrigiert 

Kategorie 

ordnet 

Tickets 

zu 

Sachbearbeiter 

/ Consultant 

Administrator/Dispatcher 

� Neben einer einfachen graphischen Darstellung 

bietet sich eine tabellarische Beschreibung eines Anwendungsfalls an. 



Seite 147


� Name des Anwendungsfalles 

Wahl eines prägnanten, sinngebenden Namens (telling name) 

� Bereich 

Zu welchem Aufgabenteil gehört der Anwendungsfall 

� Ziele 

Was soll mit dem Anwendungsfall erreicht werden? 

� Beteiligte, Anwendungskontext 

Wer nutzt das System unter welchen Bedingungen/in welcher 

Umgebung für welches Ziel? 

�� Weitere Betroffene/Stakeholder 

Wer ist neben dem direkten Anwender betroffen? Welche Interessen 

gibt es? 

� Hauptakteur 

Wer ist der Hauptakteur? Was löst den Anwendungsfall aus? 



Seite 148


� Voraussetzung/Vorbedingung 

Welchen Ausgangszustand der Umgebung benötigt der 

Anwendungsfall? 

� Hauptablauf 

Wie sieht der wesentliche Ablauf in dem Anwendungsfall aus? 

� Nachbedingung im Erfolgsfall/im Fehlerfall 

Welchen Systemzustand garantiert der Anwendungsfall im 

Erfolgsfall und im Fehlerfall? 

� Ausnahmen, Fehlerfälle 

Welche Ausnahmen sind möglich? 



Seite 149

Ticketklassen unter Java (1/3) 

� Was macht ein Ticket aus? 

Festlegung von Getter und Setter-Methoden als Interface unter Java 

public interface TicketInterface { 

public String getClient (); 

public String getComment (); 

public String getEmail (); 

public String getDescription (); 

public String getConsultant (); 

public TicketState getTicketState (); 

public ArrayList 

getTicketCategory (); 



Seite 150


} 

public void setClient (String client); 

public void setComment (String comment); 

public void setEmail (String email); 

public void setDescription ( String descript); 

public void setConsultant (String consult); 

public void setTicketState (TicketState ts); 

public void setTicketCategory 

(ArrayList categories); 



Seite 151


� TicketManagement: eine ArrayList zur Verwaltung der Tickets 

ArrayList allMyTickets; 

� Ticketkategorien 

public enum TicketCategory { 

Software, Hardware, Bedienung, Betriebssystem, 

Netzwerk 

} 

� Modellierung der Zustände 

public enum TicketState { neu_erfasst, 

in_Bearbeitung, bearbeitet, getestet, 

freigegeben } 



Seite 152

class Ticket 

public class Ticket implements TicketInterface { 

private String 

client, comment, email, descript, consultant; 

private TicketState ts; 

private ArrayList categories; 

public Ticket (String client, String comment, 

String email, 

ArrayList categories) 

{ ... } 

public String toString () { return comment; } 

... 

} 



Seite 153

AWT – Swing – SWT: ein kurzer Vergleich 

� AWT implementiert eigene GUI-Elemente 

und Grafikoperationen in Java oder C 

� Swing setzt auf AWT auf mit weiteren 

reinen Javaimplementierungen 

Swing 

JFace 

SWT 

� SWT 

� plattformunabhängige Schnittstelle zu 

den GUI-Elementen des jeweiligen 

Windowing-Systems 

� reicht größtenteils einfach Funktionsjava.awt 

sun.awt 

operating 

system 

JNI *) 

� reicht größtenteils einfach Funktions- 

windowing 

system 

operating 

system 

aufrufe weiter *) JNI: Java Native Interface 



Seite 154

Exkurs: Applets (I) 

� Bei Applets handelt es sich i. d. R. um unbekannten Code 

� Bei der Ausführung von Applets müssen aufgrund des verständlichen 

Sicherheitsbedürfnisses des Nutzers bzw. dessen Systems 

Sicherheitsbeschränkungen eingehalten werden. 

� Ein Applet darf 

� nicht auf das lokale Dateisystem zugreifen - es sei denn der Benutzer lässt 

es ausdrücklich zu 

� keine Verzeichnisse ansehen, Existenz von Dateien prüfen 

� keine Dateiattribute (Größe, Zugriffsrechte) prüfen 

� keine Dateien lesen, schreiben, löschen, umbenennen 

� keine Netzwerkverbindungen zu irgendeinem Computer aufbauen 

� die Ausführung nicht über exit() beenden 



Seite 155

Exkurs: Applet (II) 

� Geeignet zur Einbettung in eine HTML-Seite 

� (meist nur für "kleine" Aufgaben – Downloadzeit bedenken) 

� spezialisierte Fensterklasse JApplet 

� Größe wird in der HTML-Seite festgelegt 

� ansonsten Bestückung mit Komponenten wie bei JFrame 

� Steuerung durch den Browser 

� init Initialisierung beim ersten Aufruf der HTML-Seite 

�� start Applet wird sichtbar gemacht (z.B. Animation starten) 

� stop Applet wird verborgen (z.B. Animation stoppen) 

� destroy das Applet wird entladen (Wechsel der HTML-Seite) 



Seite 156

Dokumentieren mit Java 

� In Java wird es der Entwicklerin/dem Entwickler sehr leicht gemacht, 

eine (Online-)Programmdokumentation im Stil der Java-Online 

Dokumentation zu erstellen, wenn man sich an die folgenden 

Konventionen hält: 

� Spezieller Kommentar zur Erläuterung der Klasse bzw. der 

Methoden/Komponenten steht zwischen /** und */; 

� spezielle Markierungen beginnen mit dem @-Zeichen und stehen 

dann innerhalb dieser Kommentare. 

� Die Sichtbarkeitsmodifikatoren (public, private, protected) 

müssen angegeben werden. 



Seite 157

javadoc 

� Hier eine Auswahl: 

�� @see name Hyperlink auf eine Klasse 

� @see name#methode Hyperlink auf eine Methode 

� @version text steht (nur) vor Klassendefinition 

� @author text steht (nur) vor Klassendefinition 

� @param name beschr. Parameterbeschreibung vor Methoden 

� @return beschr. steht (nur) vor Methoden 

� @exception Klassenname Beschreibung steht vor Methode 

�� Erzeugt wird die Dokumentation mit dem Befehl 

javadoc datei.java –version –author –windowtitle bsp 

� Nutzen Sie diese Dokumentationsmöglichkeiten in Ihrem Programmcode für 

die von Ihnen (weiter-)entwickelten Klassen im Praktikum! 



Seite 158

javadoc Beispiel 

Klassenübersicht 

Dokumentation zur 

gesamten Klasse 

Version und Autor 

Erläuterung 

des Konstruktors/ 

der Methode und 

Sprung zur Methode 

Titel 

(aus javadoc Aufruf) 



Seite 159

Die JNLP-Datei: Deployment von Java-Code 

� Mithilfe von JNLP-Dateien kann die plattform-übergreifende zu Verfügung 

Stellung und Verteilung (Deployment) von Java-Applikation sehr komfortabel 

genutzt werden. 

� Man sollte sich allerdings dabei sowohl als Anbieter als auch als möglicher 

Nutzer der Applikation darüber bewusst sein, dass man mit dem Laden und 

anschließendem Ausführen der Applikation sämtliche Zugriffsrechte auf den 

Client hat und man damit clientseitig ein Sicherheitsrisiko eingeht. 

� Die Beschreibungsdatei für eine Anwendung ist in XML-Notation geschrieben 

und wird auf dem Webserver abgelegt, damit kann eine entsprechende 

Internetseite auf diese verweisen und immer die aktuellste Version anbieten 

(es ist darauf zu achten, dass diese Datei auf dem Webserver mit dem MIME- 

Type application/x-java-jnlp-file assoziiert ist; diese XML-Dateien 

haben i. d. R. die Endung .jnlp). 



Seite 160

JNLP: Java Network Launch Protocol 

Zusätzlich zu der jar-Datei wird eine jnlp-Datei erstellt: 

 

 

 

Beisipiel einer JNLP-Datei in ENA 

Prof. Dr. H.-P. Wiedling 

 

Demonstration von JNLP für ENA 

 

 

 

 

 

JNLP-Sicherheitsaspekte 

� Wenn die Applikation signiert ist, können unter diesem Element die 

benötigten Sicherheitseinstellungen angefordert werden. Wenn dieses 

Element (und das entsprechende Unterelement) nicht angegeben ist, läuft 

die Applikation in der Applet-ähnlichen Sandbox, mit strengen 

Zugriffsrechten. 

� all-permissions 

� Wenn diese Option angegeben ist und die Applikation signiert ist, werden der 

Applikation alle Rechte eingeräumt. 

�� j2ee-application-client-permissions 

� Mit dieser Option möchte die Applikation die Zugriffsmöglichkeiten, die es als 

J2EE-Client benötigt. Damit darf die Applikation beispielsweise nicht auf 

lokale Ressourcen zugreifen, dafür aber auf alle Hosts auf allen Ports. 



Seite 162

JNLP erstellen 

� jar-Datei erstellen: 

jar cvfm turtle.jar manf *.java *.class 

� Verschlüsselung erstellen: 

keytool -genkey -keystore myKeys -alias turtle 

... es folgen Abfragen von Schlüsselinformationen 

(inkl Pw für Keystore und turtle) u.a. „keytool -list -keystore myKeys“ 

� jar-Datei signieren: 

jarsigner -keystore myKeys turtle.jar turtle 

Quelle: 

http://java.sun.com/developer/technicalArticles/Programming/jnlp/ (überholt) 

http://download.oracle.com/javase/tutorial/deployment/webstart/deploying.html oder 

http://www.dpunkt.de/java/Programmieren_mit_Java/Deployment/9.html#id502 

auf pw für 

Keystore und 

Eintrag achten! 



Seite 163

Entwurf: 

�� Diagramme 

� Rapid Prototyping 

� Modelle und Metapher 

� Gestaltungskriterien 

� Screens (abstrakt, konkret) 

� Navigationsübersicht 

� Abläufe/Workflow 



Seite 164

Ein kleines Beispiel 

� Überlegen Sie, wie ein Anwender den Dialog mit einem 

Geldautomaten wahrnimmt und auch beschreibt 

� Zugangsberechtigung kontrollieren 

(EC-Karte und Ihre 4stellige Geheimnummer) 

� Betrag angeben 

�� Betrag ausgeben 

� Automat wieder in den Ausgangszustand 

versetzen 



Seite 165

Notation des Sequenzdiagramms 

Objekt 

Methodenausführung 

Lebenslinie 

Meth.aufrufen 

eigene 

Methode 

aufrufen 

Bedingung 

siehe auch SWT-Skript 

Ablauf objektorientiert 

beschrieben 

Objekt 

erzeugen 

Objekt 

zerstören 



Seite 166

Sequenzdiagramm "Geld holen" 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

E�� 

�� 

�� 

�� 

�� 

�� 

�� 

E�� 

�� 

�� 

E�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 

�� 



Seite 167

Sequenzdiagramm "Geld abheben" 

Ich: 

CBenutzer 

Geld 

holen 

EC-Karte einlesen 

Use Case wählen 

PIN-Nummer einlesen 

Betrag einlesen 

EC-Karte ausgeben 

EC-Karte entnehmen 

Geld entnehmen 

VolksbankAutomat1: 

CGeldautomat 

Geld ausgeben 

in diese 

Richtung 

kann man 

das innere 

Verhalten 

weitermodellieren 

Screens= 

Zustände 

Ruhestellung 

Hauptmenü 

PIN-Dialog 

... 



Seite 168

Geldautomat als "Assistent“ (üblich) 

� "Assistenten" serialisieren die Abfrage mehrerer Eingabewerte vom 

Benutzer 

� Vereinfachung: Benutzer muss zu einem Zeitpunkt nur 

über eine Frage nachdenken 

� sinnvoll für selten benutzte Anwendungsfälle oder 

für unerfahrene Benutzer 

� langsam und schwerfällig für Profis 

� zum Vergleich der bekannte Geldautomat 

nicht als Assistent: 



Seite 169

Szenario "Kontostand abfragen" 

Benutzer Automat 

führt EC-Karte ein 

wählt "Kontostand abfragen" 

gibt PIN-Nummer ein 

nimmt EC-Karte 

bietet Hauptmenü an 

erfragt PIN-Nummer 

gibt EC-Karte heraus 

zeigt Kontostand an 

geht in Ruhestellung 



Seite 170

Szenario "Geld holen" 

Benutzer Automat 

führt EC-Karte ein 

wählt "Auszahlung" 

gibt PIN-Nummer ein 

gibt Betrag ein 

nimmt EC-Karte 

nimmt Geld 

Sicht der Bank 

Sicht des Kunden 

bietet Hauptmenü an 

erfragt PIN-Nummer 

erfragt Betrag 

gibt EC-Karte heraus 

gibt Geld heraus 

geht in Ruhestellung 



Seite 171

Geldautomat: Use Case Diagramm 

Use Cases 

entsprechen 

oft der 

obersten 

Menüebene 

Kunde 

Geldautomat 

Kontostand 

abfragen 

Geld holen 

Schecks 

bestellen 

Geldvorrat 

prüfen 

Geld 

nachfüllen 

eingezogene 

Scheckkarten 

entnehmen 

eine Benutzergruppe sieht oft nicht die Funktionen der anderen 

Mitarbeiter 



Seite 172

Sequenzdiagramme - Notation 

� stellen Objekte und deren Interaktion dar 

� Interaktion: eine Methode ruft eine andere Methode auf 

� Zeitachse von oben nach unten 

� Lebensdauer des Objekts durch "Lebenslinie" dargestellt 

� vgl. Flussdiagramm / Programmablaufplan 

� ältere Diagrammtypen, die nicht objektorientiert sind 



Seite 173

Sequenzdiagramme - Bewertung 

� Diagramme für GUI-Entwurf in UML nur beschränkt geeignet: 

� UML konzentriert sich auf die Architektur von SW-Systemen 

� vernachlässigt den visuellen Aspekt 

� ein GUI wird zwar mit Klassen realisiert, anhand eines Klassen- oder 

Kollaborationsdiagramms kann man sich aber kein Bild von 

Aussehen und Benutzung machen ! 

� Vorschlag: Screen-Diagramme 

� im Grunde abgewandelte Zustandsdiagramme 



Seite 174

abstrakt und konkret 

Beispiel: Lehrangebote 

ansehen 

� abstrakte Elementliste 

� konkretes Layout 

(Stichwortliste, Halbsätze) (konkrete Anordnung, Festlegung 

auf Componenten) 

Sortierung wählen: 

Semester, Dozent, Import/Export 

Fachbereich wählen 

Vorschau 

Drucken 

Ausgabe in Datei 

Schließen 



Seite 175

Verbindung zum Sequenzdiagramm 

OnSortClick 

OnFbChange 

OnDiskClick 

OnPrintClick 

LvPlanungView: 

CLvPlanungAusgDlg 

OnPreviewClick 

OnExitClick 

SetSort(Sort) 

SetFb(Fb) 

Output(P) 

LvPlanungModel: 

CLvPlanungAusg 



Seite 176

Komplexität beherrschen 

� Diagramme beanspruchen viel Platz 

� Problem beim Zeichnen 

� Problem beim Verstehen 

� sinnvolle Zerlegung in Teildiagramme ist wichtig 

� insbesondere auch hierarchische Gliederung 

� Abstraktion 

�� nicht einfach orientiert an der Papiergröße zerschneiden 

� aussagekräftige Bezeichnung für jedes Teildiagramm 

� analog zu sinnvollen Klassen- und Funktionsnamen 

gilt für alle, 

nicht nur für 

Zustandsdiagramme 



Seite 177

Zustandsdiagramme: Idee und Notation 

� ein Objekt kann im Lauf der Zeit 

verschiedene Zustände annehmen 

� Haben einen Anfang und ein Ende 

� Zustandswechsel werden durch 

Ereignisse ausgelöst 

� unterschiedliche Folgezustände sind 

möglich abhängig von Bedingungen 

(Verzweigungen im Diagramm) 

�� Aktionen können ausgeführt werden 

� beim Übergang in den Folgezustand 

(notiert mit Ereignis/Aktion) 

� während des Verweilens in einem 

Zustand (notiert mit do/...) 

siehe auch OOAD-Skript! 

Objekt wird erzeugt 

durchläuft 

mehrere 

Zustände 

und wird vernichtet 

Zustand 

do/Aktion 

Ereignis[Bedingung]/Aktion 



Seite 178

Beispiele: Tür und Lampe 

Tür 

Schließen(“rumms“) 

Übergangsaktion 

offen 

Öffnen 

geschlossen 

Einschalten 

Lampe 

aus 

an 

do/leuchten 

Ausschalten 

Zustandsaktion 



Seite 179

Implementierung 

� Zustand: Kombination von Attributwerten des Objekts 

� Ereignis: empfangene Nachricht / Handler-Aufruf 

� Bedingung: wird im Handler ausgewertet 

� Zustandsübergang: Funktionskörper eines Handlers 

� Übergangsaktion: Methodenaufruf für anderes Objekt 

� Zustandsaktion: Methodenaufruf (in separatem Thread) 

speziell bei GUIs: 

� Screens / Dialoge sind Zustände des Objekts "Bedienoberfläche" 

� Hauptfenster hat Zeiger auf untergeordnete Fenster als Attribute 

� objektorientiert + ereignisorientiert 



Seite 180

Diagramme – für wen? 

� Diagramme aus der Softwaretechnik sind nicht geeignet, um mit 

Auftraggebern zu kommunizieren 

� selbst konkrete Screen-Diagramme nicht ! 

� allenfalls, wenn die Auftraggeber selbst Informatiker sind 

� zur Kommunikation mit Auftraggebern und Benutzern braucht man 

Prototypen 

�� visuell und funktional konkret, nicht erklärungsbedürftig 

� Diagramme helfen dem Entwickler beim Entwurf, 

dem Wartungsprogrammierer zum Verständnis 



Seite 181

Manifest und Prinzipien der agilen 

Softwareentwicklung (kurzer Exkurs) 

� ... 

Durch die[se] Arbeit haben wir Folgendes schätzen gelernt: 

Individuen und Interaktionen mehr als Prozesse und Tools 

Funktionierende Software mehr als umfassende Dokumentation 

Zusammenarbeit mit Kunden mehr als Vertragsverhandlungen 

Reaktion auf Änderungen mehr als einen Plan zu befolgen 

... 

� We follow these principles: 

� Our highest priority is to satisfy the customer 

through early and continuous delivery of valuable software. 

� Welcome changing requirements, even late in development. Agile processes 

harness change for the customer's competitive advantage. 

� Deliver working software frequently, from a couple of weeks to a couple of 

months, with a preference to the shorter timescale. 

� Business people and developers must work together daily throughout the project. 

� http://www.agilemanifesto.org/ und 

http://www.agilemanifesto.org/principles.html 



Seite 182

Einschub: Modelle eines Systems 

� Modelle sind vereinfachte Darstellungen 

einer Wirklichkeit 

� Paradebeispiel Atommodelle in der Chemie 

a) mentales Modell 

� Sicht des Benutzers; 

an der Anwendung orientiert 

b) augenscheinliches Modell 

hoffentlich identisch 

� wie sich das System nach außen darstellt 

c) Implementierungsmodell 

� Sicht des Entwicklers; technologisch orientiert 

kein kein Modell 

entspricht der 

„Realität" 



Seite 183

Use Cases eines Buchs 

� der Leser? der gründliche Leser, der eilige Sucher, der Schenkende 

� Fachbuch = System zur Informationsspeicherung 

� von Anfang bis Ende lesen umblättern 

� Überblick bekommen Inhaltsverzeichnis 

� Information zu einem Thema suchen Inhaltsverzeichnis 

� Detailinformation / Stichwort suchen Index 

� Wieder Auffinden einer Stelle Lesezeichen 

�� weiterführende Information finden Literaturliste 

Literaturliste 

� Kaufentscheidung treffen Inhaltsverz., Klappentext, Leseprobe; Preis 

� vgl. Grundfunktionen eines Browsers 

� vgl. dagegen einen Roman 



Seite 184

z.B. Dokument- statt Datei-Menü 

� das bekannte Datei-Menü ist nahe am 

Betriebssystem 

� für einige Funktionen muss man die Datei 

erst schließen 

� wie wollen Benutzer mit Dokumenten arbeiten ? 

� offenes Dokument umbenennen oder 

verschieben 

� Version orientiert: Meilensteine 

�� Änderungen vergessen statt 

Schließen und wieder Öffnen 

� ABER: 

das Beispiel ist problematisch, weil Benutzer 

Datei orientiertes Arbeiten gewohnt sind ... 



Seite 185

Entwurf der Grobstruktur des Dialogsystems 

Von Use Cases zu Bildschirmmasken 

eine Möglichkeit 

� jeder Use Case wird in eine Bildschirmmaske abgebildet 

� Benennung des Use Case wird Titel des Screens 

"Screen" 

� ggfs. weitere untergeordnete Dialoge bei komplexen Use Cases 

� keine Funktionen oder Daten in einen Screen, 

die nicht unmittelbar zu diesem Use Case gehören ! 

� Gruppierung der Screens nach Benutzergruppen 

� besser: Identifikation des Benutzers durch Anmeldung und 

Ausblendung der Use Cases anderer Benutzergruppen; 

jeder Benutzer bekommt nur Screens "seiner" Gruppe zu sehen 

� Hauptfenster enthält Übersicht der Use Cases 

� und verzweigt dorthin 

im primitivsten Fall eine Liste 



Seite 186

(Rapid) Prototyping 

� ob ein Entwurf "funktioniert", erkennt man nicht mit Hilfe von 

Diagrammen 

� Begriff "funktionieren" unter Designern: "seinen Zweck erfüllen" 

� frühzeitiger Test mit Benutzern ist notwendig 

� erfordert weitgehend arbeitsfähigen Prototyp 

� Benutzertest braucht eigentlich mehr als nur die Oberfläche ... 

� Benutzer fragen will gekonnt sein ... 

�� mit geeigneten Tools ist die Erstellung einer Bedienoberfläche nicht 

aufwendiger als mit einem Zeichenwerkzeug 

� vgl. Photoshop / Director � Visual Basic / Visual C++ / Eclipse 



Seite 187

Der erste Eindruck zählt … 

� (Rapid) Prototyping 

�� Fake (Schwindel, Betrug, Fälschung, etwas vortäuschen) 

� Mock Up (Fälschung, Schein, Imitation) 

Diese drei Begriffe beschreiben eine Idee: 

Um als Entwickler bereits in der frühen Phase einer 

Programmentwicklung mit dem Anwender Effekte an der 

Bedienoberfläche diskutieren zu können, entstehen unvollständige 

Prototypen, anhand derer das Look&Feel der 

Applikation und deren Wirkung auf den Anwender erörtert 

werden können. 

Verschiedene Softwareprototypen vermitteln in frühen 

Planungsphasen einen brauchbaren Eindruck für die gestellte 

Aufgabe. 

Kommunikationsprobleme zwischen IT-Experten und Kunden 

lassen sich mit Prototypen verringern. 



Seite 188

Der erste Eindruck zählt: Prototyping 

� Grob lassen sich Prototypen unterteilen in Demonstrations-, 

Analyse-, Architektur- und Designprototypen 

� Prototyp als Kommunikationsbasis für Entwickler und Anwender 

� Proof-of-Concept (POC) im Sinne einer Machbarkeitsstudie 

� GUI-Prototyping zielt darauf ab, den Anwender frühzeitig in den 

Entwicklungsprozess einzubeziehen 

�� Bewusst/Unbewusst entstehen Systemgrenzen bzw. Prototyp gibt 

Hinweise auf Strukturen 

ABER: Anwender ändert seine Meinung! 



Seite 189

Prototypen - vertikal 

� Vertikale Prototypen sollen helfen, Aussagen über die Architektur 

machen zu können; es ist darauf zuachten, dass der Ausschnitt der 

realisiert wird, nicht zu trivial ist! 



Seite 190

Prototypen - horizontal 

� Horizontale Prototypen decken den kompletten Satz der Funktionen 

in einer Anwendungsebene ab; die technische Korrektheit spielt eine 

untergeordnete Rolle 



Seite 191

Direkte Manipulation (1/2) 

� Einfach erlernbar: intuitiv 

� Leichte Ausnutzung aller Möglichkeiten des Systems 

� Hohe subjektive Befriedigung 

� Keine komplizierte Kommandosprache 

� Reduzierung des kognitiven Overheads 

� Point-and-Click �� Remember-and-Type 



Seite 192

Direkte Manipulation (2/2) 

Dabei ist zu beachten, dass 

� Aktionen umständlich werden können, 

� eine adäquate graphische Darstellung unter Umständen 

schwierig ist, 

� die Bedienung des Zeigegerätes für Experten zu langsam ist und 

sogar zur Ausbremsung des Arbeitsflusses führen kann, 

� sie aufwändig zu programmieren ist 



Seite 193

Bildliche Darstellung (Icons) 

Dabei ist zu beachten 

� Bild schneller zugänglich als Text 

� Grafisches Zeigeinstrument anstelle Kommandoeingabe 

� Einfache Operationen: 

� Move, Size, Scroll, Open, Close, Iconify, Highlight, Drag-and- 

Drop, … 

� Direkte Manipulation: unmittelbare Wirkung und sofortige 

Anzeige des neuen Zustandes 



Seite 194

Gestaltungskriterien (1/2) 

� Performanz: 

�� Speicherkapazität, Rechnerleistung, Netzleistung, Datenmenge 

in der Anwendung, Antwortzeiten 

� Wiederverwendbarkeit: 

� Nutzen bereits implementierter Bausteine, parametrisierte 

Standarddialoge, Produktivität 

� Konsistenz/Konformität: 

�� Vertrautheit, gleiches Verhalten in ähnlichen Situationen, 

keine sinnlosen Aktionen 

(z.B. kein Delete anbieten, wenn kein Objekt existiert) 



Seite 195

Gestaltungskriterien (2/2) 

� Realitätsnähe: 

� Vertraute Objekte bedeuten Komfort �� Reduktion der 

Komplexität 

� Mentale Modell: 

� Vorstellung des Benutzers vom System muss mit dem 

Systemverhalten zusammen passen 

� Einsatz von Metapher 

�� Mediengerecht: 

� Interaktion, Dynamik, Kombinierbarkeit, 

Informationsaufbereitung 



Seite 196

Gestaltungskriterien 

Performanz 

Mentales Mentales 

Modell 

Medien 

gerecht 

Wieder- Wiederverwendbarkeit 

Realitätsnähe 

Konsistenz 



Seite 197

Layoutüberlegungen 1/2 

� Layoutentscheidungen müssen nachvollziehbar und begründet sein; 

Entscheidungen nicht aus dem Bauch heraus treffen! 

� Geeignete Ansatzpunkte bieten die Anforderungen durch die 

Aufgabenstellungen und die Benutzerprofile 

� Beachten Sie kulturelle Eigenarten: 

Bedeutung von Farben, Informationswahrnehmung 

� Achten Sie auf kognitive Fähigkeiten: 

Was bzw. wie viel kann man sich merken? 



Seite 198

Layoutüberlegungen 2/2 

� Hilfreich kann sein, bekannte Begrifflichkeiten und Metapher aus der 

Anwendungsdomäne gezielt einzusetzen 

� Akten durchlaufen einen bestimmten Prozess, 

� es gibt eine Ablage, das Vier-Augen-Prinzip ist bekannt, … 

dadurch wird die Akzeptanz, das Vertrauen und das intuitive 

Verständnis und die Bereitschaft, das System zu erlernen erhöht und 

gefördert. 

�� Ein vertrautes Mentales Modell hilft dem Nutzer, sich zurecht zu 

finden. 



Seite 199

Benutzerprofile - Ticketbeispiel 

� Kunde (Client): 

�� meldet/erfasst neues Ticket; 

� erhält Rückmeldung/Feedback 

(aus System und per Email nach erfolgreicher Bearbeitung) 

� Abteilungsleiter (Dispatcher) 

� verteilt/ordnet Ticket Sachbearbeiter zu und 

� überprüft/sichert Qualität/testet/erteilt Freigabe 

� Sachbearbeiter (Consultant) 

� bearbeitet (d.h. fügt Kommentar ein, ordnet Fehlerkategorie neu zu) und 

testet 

� Weitere Profile (Administrator, Hotline-Mitarbeiter oder 1st-,2nd und 3rd-Level- 

Supportmitarbeiter) lassen sich aus der Beschreibung nicht entnehmen 

� Es lassen sich auch keine Kontakte zwischen Kunden und Mitarbeiter oder 

Prioritäten erkennen 



Seite 200

Design/Layout: Use Case(s) beachten 

� Wie sind die Arbeitsabläufe? Sind alle Schritte/Aktionen klar ersichtlich? 

�� Was passiert vorher? Was passiert nachher? 

� Welche Benutzergruppe(n) nutzt/nutzen den Screen? 

� Welche Aufgaben sollen bearbeitet werden? Gibt es einen Standardablauf 

� Was geschieht bei dynamischen Veränderungen? 

� Die Größe des Screens wird verändert 

� Die Anzahl der Componenten verändert sich 

� Welches Feedback bekommt der Benutzer? 

� Wird der Benutzer geführt? 

� Gibt es Orientierungshilfe? Welche Schritte stehen noch an? 

� Können Entscheidungen/Interaktionen rückgängig gemacht werden? 

� Kann der Benutzer Fehler machen bzw. werden diese verhindert? 



Seite 201

Screens - Ticketbeispiel 

Screen „Anmeldung“ (login) als Kunde, Abteilungsleiter oder Sachbearbeiter: 

als Kunde/Client: 

1 Erfassung und Bearbeitungsfortgang 

• Ticket neu erfassen 

• (Bearbeitungszustand eigener Tickets betrachten/inspizieren) 

als Abteilungsleiter/Dispatcher: 

2 Monitoren (insgesamt) – Sachbearbeitern zuordnen 

• Bearbeitungszustand aller Tickets betrachten 

• (alle) neu erfassten Tickets anhand Beschreibung sichten und Mitarbeiter zu 

ordnen 

• Qualitätskontrolle und abschließende Freigabe 

als Sachbearbeiter/Consultant: 

3 Bearbeiten/Kommentieren und testen 

• zu gewiesene Tickets untersuchen/bearbeiten (Angabe d. Fehlerursache) 

Ticket mit Kommentar versehen 

• testen (Angabe des Testprotokolls) und damit Zustand ändern 



Seite 202

Layout: Analyse � Design � Konstruktion 

� Analyse 

� Die fachlichen Anforderungen führen zu einem ersten groben 

Ablauf 

� abstrakte Screens 

� Use Cases geben eine Hinweis auf sinnvolle Begriffe/Bezeichner 

und Ablauffolgen/Workflows 

� Das Überlagern eines Screens mit Rasterlinien ist 

aufschlussreich und liefert wertvolle Hinweise zur Struktur und 

dem Aufbau des Screens 

� Die verschiedenen Bestandteile (Componenten, Container und 

LayoutManager) werden grafisch identifiziert 



Seite 203


� Gestaltung 

�� Konkrete Auswahl der Container: 

Scrollen? Splitten? Was passiert beim Vergrößern/Verkleinern des Screens? 

� Auswahl und Festlegung des Farbklimas (� Style Guides entstehen) 

� Schrift-, Fenster- und Icongröße beeinflussen die Gesamtgröße 

� Was soll passieren, wenn sich die Componenten in Anzahl und Typ ändern? 

� Das User Interface führt den Nutzer … durch Zustandsanzeige, durch 

Feedback, durch Konsistenz, … durch Fokussteuerung, … 

� Das User Interface entlastet den Nutzer … durch Voreinstellung, durch 

Vorsorge zur Fehlervermeidung … 

� Das User Interface ist selbsterklärend … durch Tooltips, Statusbar, … 



Seite 204


� Konstruktion 

� Konkretes Programmieren und Zusammenfügen von 

• Componenten (Dialogbausteine), 

• Container (hier: diverse Panel) und 

• LayoutManager 

� Anbindung an die Objekte in der Anwendung 

� MVC Architektur mit interface und/oder Adapterklassen 

�� Kodierung in Java/Swing 



Seite 205

Navigationsübersicht: Screens und Abläufe 

Abteilungsleiter verteilt/ordnet zu, hat 

Termine und Auslastung im Auge (macht 

Qualitätssicherung) 

Anmeldung/ Login als 

Kunde, Mitarbeiter oder 

Abteilungsleiter 

Kunde macht 

Ersterfassung 

• Prozess vollständig 

und am Arbeitsablauf 

orientiert? 

Mitarbeiter • Screens voll- 

bearbeitet und testet ständig und nicht 

überfrachtet 

Fachbereich Informatik: 3. Semester Bachelor (d.h. Studiengang 

aufgaben- 

Prof. Dr.-Ing. Hans-Peter angemessen)? 

Wiedling 

Seite 206

Navigationsübersicht 

Übersicht 

mit 

Workflow 

zurück 

Notation und Vereinfachungen: 

– Zustände als 

Skizzen/Screenshots 

– Übergänge i.a. mit Linksklick 

– R mit Rechtsklick 

– Rücksprung / Schließen 

Use 

Cases 

UML passt nur bedingt für GUI; 

Zustandsdiagramm weiterentwickelt 



Seite 207

Notation der Navigationsübersicht 

Anwendung 

• starten 

• beenden 

Aktionen 

• neues Hauptfenster 

• neuer Dialog/PopUp 

• Rücksprung 

Ereignisse 

• keine Angabe: linker Mausklick 

• rechter Mausklick R 

Zustände 

• Elementliste (abstrakter Screen) oder 

• Layout-Skizze (konkreter Screen) oder 

• Screenshot (konkret, Dokumentation) 

Bedingungen 

• mit Shift/Umschalttaste S 

• mit Ctrl/Strg-Taste C 

• mit Alt-Taste A 



Seite 208

High Level: Workflow 

� ein Arbeitsablauf (Workflow) verkettet mehrere 

Anwendungsfälle verschiedener Benutzer (Mitarbeiter) 

� Beispiel: 

Bestellung verbuchen � Lieferung zusammenstellen 

� Lieferschein schreiben � Rechnung schreiben 

� Zahlungseingang verbuchen 

� Metapher: der Weg einer Akte durch eine Verwaltung 

� typischerweise wird der nächste Mitarbeiter vom System 

durch eine Botschaft informiert, wenn der vorige seine 

Teilaufgabe erledigt hat 

� kann mit Flussdiagramm / Programmablaufplan dargestellt werden 



Seite 209

Low Level: Szenarien 

� Szenario: Ablauf hinter einem Anwendungsfall / Screen 

� Verfeinerung des Anwendungsfalls 

� verbale Beschreibung aus Sicht des Benutzers 

� jetzt unter Berücksichtigung wichtiger systeminterner Objekte 

� systeminterne Objekte sollten dem mentalen Modell des 

Benutzers entsprechen 

� formale Beschreibung mittels Sequenzdiagramm 

� Präzisierung der verbalen Beschreibung 

� Benutzerereignisse rufen Methoden der Fensterklasse auf 



Seite 210

Fokussteuerung definieren 

2 

4 

6 

8 

� vollständiger Weg mit >>Tab

Focus unter Java verändern 

� Bezieht sich auf Instanzen der Klasse Component 

� Reihenfolge wird zunächst implizit durch das Erzeugen festgelegt 

� mit >>Tab>Shift>Tab

Layout/Fenstergestaltung 

• Anordnung 

• Gruppierung 

• Hervorheben 

• Größen/Sehwinkel 

• Ästhetik 

• Farbe 

• Physiologische Aspekte 

• Psychologische Aspekte 

• Schrift/Beschriftung/Text 

• Ausrichtung 



Seite 213

Gedanken zur Fenstergestaltung 

� Proportionen, Balance, (Symmetrie), Einfachheit 

�� nicht die ganze Fläche mit Komponenten pflastern; 

Freiflächen sind wichtige Gestaltungsmittel ! 

� Führung der Augen von links oben nach rechts unten 

� Mehrspaltigkeit erleichtert das Lesen (vgl. Zeitung) 

� Fenster eher breit als hoch (analog zum Bildschirm und Sichtfeld) 

� Kanten der Komponenten bilden Fluchtlinien 

� Anzahl der Fluchtlinien minimieren, ohne jedoch Komponenten sinnlos 

zu vergrößern 

� einheitliche Schriftart, abgestimmte Farben (Farbklima) 



Seite 214

Prioritäten für Gruppierung 

� inhaltliche Gemeinsamkeiten (Funktionsgruppen) 

� aufgabenbezogene Folge von Arbeitsschritten 

� Benutzungshäufigkeit 

� aber nicht dynamisch verändern ! 

�� alphabetische Anordnung, Nummerierung etc. 



Seite 215

Hinweise zur Gruppierung 

� Elemente im oberen Bereich einer Gruppe werden schneller 

entdeckt als im unteren 

� Komponenten in Gruppe besser spalten- als zeilenweise anordnen 

� Gruppenrahmen mit Überschriften erhöhen die Übersichtlichkeit 

� besser Freiflächen als Gruppenrahmen ohne Überschrift 

� 4-5 Gruppen, 4-5 Komponenten pro Gruppe 

� Gruppen sollten als solche erkennbar sein und sich von 

Nachbargruppen abgrenzen 

� Gruppen so ausrichten, dass nur wenige Fluchtlinien entstehen 

� Eigene Gestaltungsregeln in allen Gruppen konsistent anwenden 



Seite 216

Natürliche Anordnung 

bottom 

left 

right 

top 

Border 

Border 

natural mapping 

das Herdplattenproblem 

Cursortasten 

� Wichtig: (Um-)Denken vermeiden! � Haben Sie eine Idee? 



Seite 217

Hervorheben von Komponenten 

� Hervorhebungen trennen Informationen, gewichten, erleichtern 

Suchen und Finden, lenken Aufmerksamkeit 

� Größe der hervorzuhebenden Komponente 

� abweichende Orientierung oder Form 

� Isolierung, Einzelstellung, Umrandung 

� Farben (wenige !), Hell-Dunkel-Kontrast, Inversdarstellung 

� fetter Schriftfont oder Großbuchstaben 

�� Blinken (aber sparsam und nur an einer Stelle) 

� nicht mehr als 10-20% aller Informationen hervorheben 

� gewählte Darstellungsart der Hervorhebung durchgängig benutzen 

beliebter 

Fehler, dies 

nicht zu tun 



Seite 218

Minimal- und Maximalgrößen 

� physiologische Gegebenheiten des durchschnittlichen menschlichen 

Auges berücksichtigen 

� empirisch ermittelt und in Normen festgehalten 

� der Entwickler darf nicht das eigene Auge als Maßstab nehmen ! 

� begrenzte Sehschärfe erfordert Mindestgröße 

� für ermüdungsfreies Lesen 

�� Schriftgröße mindestens 0.3 Grad Sehwinkel, besser 0.5 Grad 

� schnelle Fixation empfiehlt Maximalgröße 

� für schnelles Erfassen "auf einen Blick" 

� Komponentengruppe maximal 5 Grad Sehwinkel 

unabhängig 

von Systemkonfiguration 



Seite 219

eine Bemerkung zum Sehwinkel 

Abstand 

1pt = 1/72 inch 

1 inch = 2,54 cm 

Höhe 

Beispiel: 8pt = 0,282cm 

Abstand: a = 50cm 

Sehwinkel: α = 0,3° 

cos α = 50 / Hypotenuse 

sin α = Höhe / Hypotenuse 

� Höhe = 50 * sin .3/cos .3 

Höhe = 0,262 cm 



H 

Seite 220

Abbildungsmaßstab 

� Angabe von Schriftgrößen 

traditionell in "Punkt" 

� 1 pt = 1/72 Zoll; 1 Zoll = 1 inch = 2,54 cm 

� korrekt auf Papier, problematisch am Bildschirm 

� Abbildungsmaßstab systemabhängig 

� MacIntosh 72 dpi, Unix GUIs (Motif, KDE, ...) ?, 

Windows 96 dpi (kleine) / 120 dpi (große Schriften) 

� plattformübergreifend: Director und Java 72 dpi 

�� gemischte Bemaßung ist problematisch 

� HTML: Schriften in pt, sonstige Maße in Pixel 

� Windows: Schriften und Controls in pt, 

Fenster in Pixel 

unterschiedliche 

Monitorgröße u. 

Grafikauflösung 



Seite 221

Ästhetik 

� Ästhetik ist nicht einfach Geschmackssache 

� unterliegt jedoch zeitbedingten Sehgewohnheiten 

� wichtiger Aspekt moderner Produkte 

kein ergonomisches Thema mehr 

� um so bedeutender, je ausgereifter und vergleichbarer 

die Grundfunktion konkurrierender Produkte ist 

� wird von Ingenieuren gerne wegdiskutiert 

bzw. nicht richtig eingeschätzt 

�� regelmäßiges Face Lifting beim SW-Upgrade 

� z.B. Windows und MS Office 

� suggeriert Wertigkeit und Modernität 

� läuft Kontinuität und Konsistenz zuwider 

vergleiche 

Autos, 

U-Elektronik, 

Parfume, 

Geschirr, 

... 



Seite 222

Farbe - Was ist Farbe ? 

� Physikalische Sicht 

�� Spektralfarben = "Regenbogenfarben" 

• eine Frequenz; Wellenlänge in nm 

� Rest: Überlagerung mehrerer Freq. 

� Physiologische Sicht 

520 

nicht 

darstellbare 

Farben 

500 

480 

Wellenlänge 

550 nm 

� dieselbe Farbempfindung kann durch 380 

verschiedene Mischungen von mind. 3 Farben erzeugt werden 

� Darstellung in der Farbtafel 

� Spektralfarben auf Bogen, Rot-Blau-Mischung auf Purpurgerade 

� Ordnungsprinzip: Mischfarben liegen auf Verbindungsgeraden 

� Dreieck umschließt mögliche Mischfarben aus 3 Primärvalenzen 

� berücksichtigt nicht die Luminanz (Helligkeit, Farbintensität) 

780 

"unbunt" 



Seite 223

Farbmodell RGB 

� Mischung von farbigem Licht 

� Grundfarben Rot, Grün, Blau 

� additive Farbmischung 

� Projektion der Primärvalenzen auf dieselbe Fläche 

� Einsatzgebiete 

� Wiedergabe über Monitor 

• Primärvalenzen durch Leuchtstoffe bestimmt 

�� Aufnahme mit Scanner oder Kamera 

• Primärvalenzen durch Farbteiler/Farbfilter bestimmt 

� 3D-Farbraum mit kartesischen Koordinaten 

� Mischung entspricht vektorieller Addition 

Grün 

Blau 

Rot 



Seite 224

Farbmodell CMYK 

� Mischung von Farbstoffen (Farbfiltern) 

�� Grundfarben Cyan, Magenta, Yellow, blacK 

� subtraktive Farbmischung 

� Beleuchtung mit weißem Licht 

• Cyan schluckt R transparent für B und G 

• Magenta schluckt G transparent für R und B 

• Yellow schluckt B transparent für R und G 

� Mischung von CMY ergibt (fast) Schwarz 

• Schwarz als 4. Grundfarbe wegen Unsauberkeit 

� Einsatzgebiet: Wiedergabe über Drucker 

Cyan 

� typische Probleme: geringere Farbsättigung als Bildschirm; 

schlechtere Dosierbarkeit = weniger Farbabstufungen; 

starke Abhängigkeit von Papierqualität 

weißes 

Licht 

Yellow 

Magenta 

Papier 



Seite 225

Farbmodell HLS 

� anwendungsorientiert, 

zielgerichtet 

manipulierbar 

� Farbart Hue 

� Helligkeit Luminance 

� Sättigung Saturation 

H 

S L S 

L 

H 



0.75 

0.5 

0.25 

Seite 226



Seite 227

Orange wirkt unterschiedlich hell/dunkel bzw. mehr/weniger gesättigt 



Seite 228

Physiologische Aspekte – 

Informationsverarbeitung durch das menschl. 

Auge 

� höhere Auflösung für Helligkeit als für Farbe 

� Kanten u. Formen werden besser anhand der Helligkeit erkannt 

(wird bei Videokompression ausgenutzt) 

� unterschiedliche Auflösung für verschiedene Farben 

� besonders schlecht: Blau 

� farbabhängige Helligkeitsempfindung 

�� grün wirkt heller, blau dunkler 

� kleine Flächen wirken stärker gesättigt als große 

� Farb- und Helligkeitsempfinden wird auch von der Umgebung 

beeinflusst, nicht nur vom Monitor! 



Seite 229

Psychologische Aspekte 

� im allgemeinen kulturspezifisch; bei uns: 

� weiß neutral 

� rot Anhalten, Gefahr, Fehler, Alarm, Hitze 

� orange Warnung, Achtung, Aufmerksamkeit 

� grün Losfahren, OK, Verfügbarkeit, Wachstum 

� blau Kälte, Ferne, Hintergrund 



Seite 230

Farbkombinationen 

� Vordergrund- und Textfarben 

� Weiß, Schwarz, mittel- bis langwellige Farben (Rot, Gelb, Grün) 

� kein Blau 

� Hintergrundfarben 

� hell (Positivdarstellung), schwach gesättigt (Pastelltöne) 

� kurzwellige (Blau, Cyan) und unbunte Farben (helles Grau) 

� kein gesättigtes Rot oder Braun 

�� kritische Farbkombinationen 

� vermeiden: Rot/Grün, Gelb/Blau, Rot/Blau 

� Gelb/Weiß wird leicht verwechselt 



Seite 231

Heller oder dunkler Hintergrund ? 

� Dunkel auf Hell ? freundlich 

� Papiermetapher 

� Monitor-Flimmern unangenehm bei großen hellen Flächen 

� Hell auf Dunkel ? finster 

� Farben leuchten intensiver auf dunklem Untergrund 

� dunkler Hintergrund zur Hervorhebung von Bildern 

� weiß überstrahlt leicht, weil Iris weit geöffnet ist 

�� mittlere Hintergrundhelligkeit 

� angenehm für das Auge: entspricht der Umgebungshelligkeit 



Seite 232

Farbschema / Farbklima 

� ±5 verschiedene Farben 

+ schwarz + weiß 



Seite 233

Im Zweifelsfall 

� eher weniger Farbe als mehr 

� eher weniger Farbsättigung als mehr 

� Codierung und Unterscheidung eher 

mittels Layout und Form als mittels Farbe 

�� Farben visuell überprüfen, nicht "berechnen" 



Seite 234

Farbcodierung 

� Farbe dient als "Skala" eines physikalischen Wertes 

� vgl. Landkarte, Wetterkarte 

� suggestive Zuordnung von Farbcode zu Bedeutung 

� unterschiedliche Farbarten wirken "ungeordnet" 

� besser: Abstufungen nur in Helligkeit und/oder Sättigung, nicht in 

Farbart (Hue) 

� Hervorhebung durch Intensivierung: 

"aktiv", "selektiert" � höhere Helligkeit oder Sättigung 



Seite 235

Schriftarten 

� mit Serifen Times 

� "Führungslinien" für das Auge 

� erfordern hohe Druck-Auflösung; am 

Bildschirm nur unvollkommen / unschön darstellbar 

� serifenlos Helvetica, Arial 

� schlechter lesbar; bei geringer Auflösung jedoch zu bevorzugen 

� Bildschirmschrift MS Sans Serif, Fixedsys 

�� serifenlos, auf Pixelraster optimiert 

(vorteilhaft für kleine Schrift) 

� nur in ausgewählten Größen verfügbar 

� Druckerschrift 



Seite 236

Gut lesbare Bildschirm-Schrift 

� serifenlos für Bildschirm (Serifen nur für Druck) 

� Proportionalschrift, Groß-/Kleinschreibung 

Problem: niedrige Auflösung 

� nicht unterstrichen, nicht blinkend, keinesfalls kursiv 

� horizontal ausgerichtet, linksbündig, kein Blocksatz 

� begrenzte Spaltenbreite (vgl. Zeitungsspalten) 

�� Schrifthöhe mindestens 0.3° Sehwinkel 

� besser 0.5°: ca. 8 pt bei 17", 800x600, 50 cm Abstand 

� deutlicher Kontrast zum Hintergrund 

� Text- und Hintergrundfarbe beachten 



Seite 237

Beschriftung mittels Label 

� Label deutlich dem Steuerelement zuordnen 

� minimaler Abstand = 1 Zeichenbreite 

� aber kein Doppelpunkt zwischen Label und Steuerelement 

� Label-Text kurz, aussagekräftig, eindeutig, präzise, allgemein 

bekannt, informativ, aber keine Abkürzung 

� vorzugsweise nur ein Wort 

� Label-Text nicht breiter als 5° Sehwinkel (= 1 Fixation) 

� ca. 100 Pixel bei 17", 800x600, 50 cm Abstand 



Seite 238

Ausrichtung von Beschriftungen 

� einzeilige Steuerelemente: 

Label links; horizontal zentriert 

� mehrzeilige Steuerelemente: 

Label links oberhalb 

einzeilig 

mehrzeilig 

� mehrere verschieden lange Labels: 

etwa gleich: linksbündig sehr unterschiedlich: rechtsbündig 

minimal 

mittel 

maximal 

Tabulator 

Makro 

Einblendezeit 



Seite 239

Eingabe von Text 

� Kommandos 

� Auswahl aus Textliste 

� Freitexteingabe 

� generell: mit Enter abschließen 

� Kurzformen für Kommandos und Auswahlworte anbieten 

� Auto-Vervollständigen in Combo-Boxen 

�� mnemonisch günstiger als Tastaturkürzel optimal ! 

� beliebige Groß-/Kleinschreibung zulassen 



Seite 240

Gestalten eines Eingabefensters 

Was ist hier 

schlecht ? 

Verbessern Sie den 

Entwurf ! 



Seite 241

Umsetzung der gestalterischen Anforderungen mit 

Java/Swing 

� Container 

� Dynamisches vs. Statisches Layout 

• Layout Manager 

� Dialogbausteine (Controls, Componenten) 

� (non-)modale Dialoge 

� Entwurfsmuster (MVC, ...) 

� Ereignisbehandlung/Eventhandling 



Seite 242

Top Level Container 

� JFrame, JDialog, JApplet, JWindow 

� haben eine contentPane, 

die andere Panels oder 

Komponenten trägt 

� sind Wurzel eines 

Objektbaums 

�� können eine Menüleiste (JMenuBar) haben 

� wir arbeiten i.a. nur mit der contentPane und nutzen weitere 

Panels/Panes zur räumlichen Gliederung 



Seite 243

Fenster, Container, Dialoge: JFrame … (1/2) 

� eigene Hauptfenster-Klasse deklarieren 

� public class MainWindow extends JFrame {...} 

� Fensterobjekt erzeugen 

� MainWindow myFrame = new MainWindow(); 

� Layout (im Konstruktor) neu berechnen 

� ohne Layout-Manager: 

myFrame.setSize(new Dimension (…)); 

myFrame.validate(); 

� mit Layout-Manager: 

myFrame.pack(); 

� Fenster sichtbar machen 

myFrame.setVisible(true); 

Hauptfenster 

von Applikationen 



Seite 244

Fenster, Container, Dialoge: JFrame … (2/2) 

� Fenstertitel und –icon (z.B. im Konstruktor ) einsetzen: 

�� this.setTitle("Fenstername"); 

� Image desktopIcon = 

Toolkit.getDefaultToolkit().getImage("C:\\..\\aIcon.gif"); 

this.setIconImage(desktopIcon); 

� Fenster im Desktop zentrieren: 

� frame.setLocationRelativeTo(null); oder 

� Dimension screenSize = 

Toolkit.getDefaultToolkit().getScreenSize(); 

Dimension frameSize = myFrame.getSize(); 

if (frameSize.height > screenSize.height) 

{ frameSize.height = screenSize.height; } 

if (frameSize.width > screenSize.width) 

{ frameSize.width = screenSize.width; } 

frame.setLocation((screenSize.width - frameSize.width) / 2, 

(screenSize.height - frameSize.height) / 2); 



Seite 245

Modale und non-modale Dialoge 

� Ein Dialog ist modal, wenn er die ganze Aufmerksamkeit des 

Benutzer auf sich zieht. Die geschieht dadurch, dass die 

Interaktionen mit den anderen Teilen verhindert/blockiert werden. 

Die anderen Interaktionen werden erst wieder erlaubt wenn, der 

modale Dialog vollständig bearbeitet und abgeschlossen ist. 

� Ein non-modaler Dialog fügt sich in den Gesamtdialog ein und kann 

gleichberechtigt wie jeder andere benutzt werden. 



Seite 246

Dialoge 

� ein Dialog ist ein separates Fenster, das über dem Hauptfenster 

(oder einem anderen Dialog) schwebt/liegt 

� wird oft zur Ein-/Ausgabe von Parametergruppen verwendet 

� frei positionierbar, nicht bildschirmfüllend 

� wird von seinem Hauptfenster minimiert 

� modale Dialoge blockieren das Hauptfenster, solange sie aktiv sind 

� Moduslose/non-modale Dialoge erlauben die Aktivierung des 

Hauptfensters 

� Beispiel: Editieren während "Suchdialog" in Textverarbeitung 

� MessageBox ist einfache Form eines modalen Dialogs 



Seite 247

JDialog 

� für beide Arten: modal und non-modal 

�� JDialog (Frame owner, boolean modal) 

� Als owner sowohl JDialog als auch JFrame möglich 

� show() macht den Dialog sichtbar 

� blockiert in modalen Dialogen 

� terminiert sofort in moduslosen Dialogen 

(� Wie greifen Sie auf Werte zu?!) 

� validate() oder pack() notwendig um Layout neu zu 

berechnen 

� hide()/dispose() macht den Dialog unsichtbar 

� hebt die Blockierung von show() in modalen Dialogen auf 

� zerstört nicht das Dialogobjekt 



Seite 248

JOptionPane: Standard-Dialoge 

� gängige modale Einfach-Dialoge 

� Aufruf durch verschiedene static Methoden von JOptionPane: 

showMessageDialog, showInputDialog, showConfirmDialog 

� diverse Icons zur Anreicherung per Konstante wählbar 

� Button-Kombinationen sind ebenfalls per Konstante wählbar 

� Auswahl des Benutzers wird Ergebnis der Methodenaufrufe 

� vergleichbar mit MessageBox unter Windows 

�� Bemerkung: etwas vergleichbares fehlt in AWT 

� weitestgehende Konfigurationsmöglichkeit 

mit Hilfe von showOptionDialog 



Seite 249

Spezielle Dialoge 

� JFileChooser 

� zur Auswahl einer Datei (vollständiger Pfad) 

� Varianten "Öffnen" und "Speichern unter" 

� gewählter Pfad als Ergebnis von getSelectedFile() 

� OK oder Cancel als Ergebnis von showOpenDialog(...) 

� JColorChooser 

�� zur Auswahl einer Farbe 

� static Methode showDialog (parent, title, color) liefert als 

Ergebnis ein Color-Objekt 

� Color-Objekt ist null bei Cancel 

leider uneinheitlich! 



Seite 250

Räumliche Gliederung 

� Komponenten werden gruppiert und plaziert 

durch Zuordnung zu Panels und Panes 

� Panes haben spezifische Sonderfunktionen 

� komplexe Layouts sind möglich durch 

Schachtelung von Panels und Panes (� Objektbaum) 

� jedes Panel/Pane kann einen anderen Layout-Manager haben 

� keine spezielle Ereignisbehandlung nötig 

Panel 

Tafel, Platte, 

(vertieftes) Feld 

Pane 

(Fenster)Scheibe 



Seite 251

Ein Beispiel zum 

Objektbaum 

... 

JPanel p1 = new JPanel (); 

JPanel p2 = new JPanel (new BorderLayout() ); 

JButton b1 = new JButton ("Flip"); 

JButton b2 = new JButton ("Flop"); 

JButton b3 = new JButton ("Toggle"); 

p1.setBackground(Color.cyan); 

p2.setBackground(Color.blue); 

p2.add (b1, BorderLayout.NORTH); 

p2.add (b2, BorderLayout.SOUTH); 

p1.add (p2); 

... 

p2.add (b3); 

contentPane.add (p1); 

... 

JButton 

JPanel 

JFrame 

JPanel 

JPanel 

JButton JButton 



Seite 252

JPanel: einfache Fläche 

// ein Panel ist ein Container: 

JPanel p = getJContentPane(); 

JButton jb; 

for (int i = 0; i < p.getComponentCount(); i++) 

{ 

if ( p.getComponent(i) instanceof JButton ) 

{ 

jb = (JButton)p.getComponent(i); 

� Fläche, die andere Komponenten trägt 

// jb manipulieren 

�� bekanntes Beispiel: contentPane 

}// if 

� JPanel meinPanel = 

}// for 

new JPanel(); 

... 

� Layout-Manager zuordnen oder weglassen 

� default ist FlowLayout 

� meinPanel.setLayout(new BorderLayout());// oder null 

� Komponenten zuordnen 

�� 

meinPanel.add(aComponent); 

� Umrandung (Border) definieren 

� auch Freiflächen und Abstände sind als EmptyBorder realisierbar 

� Erstellung durch Eclipse komfortabel unterstützt � 



Seite 253

Rand und Abstand mit Border 

� Diverse Klassen abgeleitet von AbstractBorder 

Interface 

� LineBorder, EtchedBorder, BevelBorder, EmptyBorder, 

MatteBorder, TitledBorder, CompoundBorder 

� Implementierung als 

� benanntes Objekt 

• EtchedBorder meinBorder = new EtchedBorder(); 

meinPanel.setBorder(meinBorder); 

� anonymes Objekt 

• meinPanel.setBorder(new EtchedBorder()); 

� gemeinsam verwendetes anonymes Objekt 

• meinPanel.setBorder(BorderFactory.createEtchedBorder()); 



Seite 254

1-aus-n Auswahl 

Anzeige und Interaktion mit dem Ticketzustand 

�� in einem modalen Dialog 

� Ergebnis wird vom Fensterobjekt (JDialog) erfragt 

� Entscheidung für eine Darstellungsart 

� ComboBox, Menue, RadioButtonGroup, … oder ganz anders (wie)!? 

� Entscheidungsgrundlage 

� Gewohnheit der Nutzer (vertraut mit best. Controls), Einbettung in 

Gesamtablauf, Anzahl Klicks, ... 

�Anzeige aller Alternativen, freie Auswahl, kein Platzproblem, ein Klick 

�Control Control mit Anwendungsobjekt(en) verbinden, 

� gegenseitigen Ausschluss sicherstellen 

� Interaktion mit entsprechenden Events realisieren 

� Wertänderungen könnten auch direkt am Objekt ausgeführt werden � wie? 



Seite 255

JRadioButton, ButtonGroup (1/3) 

JPanel radioButtonPanel; 

radioButtonPanel = new JPanel(); 

radioButtonPanel.setBackground(new Color(250, 250, 0)); 

Border border = new TitledBorder ("TicketStates"); 

radioButtonPanel.setBorder(border); 

radioButtonPanel.setLayout(new GridLayout(0, 1)); 

JRadioButton rb; 

int actionCommand = 0; 

… 

Separates Panel mit 

• Hintergrundfarbe, 

• Rahmen und 

• GridLayout 

erstellen 



Seite 256


int actionCommend = 0; 

for (TicketState t : TicketState.values()) { 

rb = new JRadioButton(t.name()); 

rb.addActionListener(this); 

rb.setActionCommand(Integer.toString(actionCommand)); 

actionCommand++; 

rb.setOpaque(false); 

group.add(rb); 

if (t.equals(TicketState.neu_erfasst)) 

rb.setSelected(true); 

radioButtonPanel.add(rb); 

} 

return radioButtonPanel; 

•Listener registrieren 

•Index mitgeben 

•Damit die Farbe des 

Panels sichtbar wird 

•In die Gruppe einfügen 

•Default setzen 

•Im Layout einfügen 



Seite 257


... 

private TicketState selectedTicketState // Objektattribut 

... 

public void actionPerformed(ActionEvent arg0) { 

// so möglichst variabel 

String actionCommand = arg0.getActionCommand(); 

selectedTicketState = 

TicketState.values()[Integer.valueOf(actionCommand)]; 

} 

Eventhandling: letzte 

Zustandsänderung wird festgehalten 

bzw. könnte auch direkt im 

Ticketobjekt verändert werden 



Seite 258

JScrollPane: verschiebbare Sicht 

� verschiebbare Sicht auf eine (größere) Komponente 

� JScrollPane zwischen Panel und Komponente schalten 

� textArea = new JTextArea(5, 30); 

JScrollPane scrollPane = new JScrollPane(textArea); 

contentPane.add(scrollPane); 

� JList, JTextComponent, JTree, JTable sind dafür vorbereitet 

� implementieren Interface Scrollable; damit wird die "Skalierung" 

der ScrollBars definiert: 

getScrollableBlockIncrement, 

getScrollableUnitIncrement, 

getPreferredScrollableViewportSize, ... 

� andere Klassen können dieses ebenfalls implementieren 



Seite 259

JSplitPane: zweigeteilt 

� zwei Panes durch verschiebbare Trennlinie geteilt 

� Erzeugen 

� JSplitPane splitPane = new JSplitPane( 

JSplitPane.HORIZONTAL_SPLIT, pane1, pane2); 

� Verschiebung durch Mausklick aktivieren 

� splitPane.setOneTouchExpandable(true); 

� Trennlinie positionieren 

�� splitPane.setDividerLocation(150); // 150 Pixel 

splitPane.setDividerLocation(0.25); // 25% 

� Mindestgröße für den Inhalt festlegen 

� pane1.setMinimumSize(new Dimension(100, 50)); 



Seite 260

JTabbedPane: Karteikarten 

� organisiert mehrere Panes "hintereinander" und 

mittels Karteikartenreiter umschaltbar 

� sehr gut: Reiter in der 2. Reihe behalten ihre Position 

(wechseln nicht die Reihe wie unter Windows) 

� Erzeugen 

� JTabbedPane tabbedPane = new JTabbedPane(); 

� Karteikarte einfügen und beschriften 

�� tabbedPane.addTab("Titel", icon, pane1, "Tooltip"); 

� Karteikarte aktivieren 

� tabbedPane.setSelectedIndex(int) 

tabbedPane.setSelectedComponent(Component) 



Seite 261

eigentlich keine Pane, sondern 

ein Layout-Manager 

CardLayout: reiterlose Karteikarten 

� Anwendung ähnlich wie JTabbedPane, aber Umschaltung kann/muss selbst 

programmiert werden 

� Erzeugen 

� CardLayout cardLayout = new CardLayout(); 

JPanel cardPanel = new JPanel(); 

cardPanel.setLayout(cardLayout ); 

� Karteikarte einfügen 

� cardPanel.add(pane1, "Text1");// Text muss eindeutig sein 

�� Karteikarte aktivieren 

� cardLayout.show(cardPanel, "Text1");// oder sequentiell: 

cardLayout.first(cardPanel); 

cardLayout.next(cardPanel); 



Seite 262

Dynamische und statische Layouts 

� statisches Layout: �� Definition von Koordinaten 

� die Größe und Position der einzelnen Komponenten ist in einem 

absoluten Koordinatensystem (z.B. Pixel) festgelegt 

� Bildschirmmaske ist für eine bestimmte Gesamtgröße gemacht 

� unter Windows gewisse Anpassung über Bildschirmschriftgröße 

� dynamisches Layout: �� Definition von Regeln 

� die Größe und Position der einzelnen Komponenten kann von der 

Größe bzw. Auflösung des Bildschirms und von der Fenstergröße 

abhängen 

� kann plattform- bzw. bildschirmunabhängig gemacht werden 

� aber: schwieriger zu entwickeln 



Seite 263

Vorgehensweise beim Entwurf 

� Java unterstützt dynamische Layout: Layout-Managern 

� Eclipse setzt von vornherein einen solchen ein 

� wir bauen als Vorstufe zunächst statische Layouts 

� Vorteile: 

� man entwirft visuell und konzentriert sich auf die Oberfläche; 

Gestaltung wird nicht durch Realisierungsprobleme eingeengt 

�� man bekommt mit wenig Aufwand einen Prototypen und hat 

weniger Hemmungen, diesen mehrfach zu ändern 

� wenn der Entwurf schließlich steht, dann wird ein dynamisches 

Layout konstruiert 

Wir haben diesen 

bisher 

ausgeschaltet! 



Seite 264

Vorgehensweise mit und ohne Layout 

� bisher: 

Größe und Position von Komponenten in der Entwicklungsphase 

festgelegt 

� jetzt: 

Position (und/oder Größe) der Komponenten ändert sich zur Laufzeit 

� a) abhängig von der Fenstergröße 

� kann sich an der Grafikkartenauflösung 

orientieren 

zweckmäßiger Einsatz 

ist nicht trivial 

� b) abhängig von der Größe der Komponente 

� jede Komponente hat eine Wunschgröße (preferred size) 

� z.B. abhängig von der Schriftgröße 



Seite 265

Wo macht es Sinn ? 

� abhängig von Fenstergröße: 

alle Komponenten mit Scrollbalken 

� z.B. JList, JTree, JTable; evtl. auch JTextArea 

� Scrollbalken können verschwinden 

� mehr Inhalt wird sichtbar 

� allenfalls abhängig von Schriftgröße: 

Buttons, Checkboxen, Labels, Ränder 

�� Größenverhältnis visueller Objekte 

ist wesentlich für den Gesamteindruck ! 

(Schrift/Komponente, Komponente/Freifläche) 

sorgfältig überlegen, 

welche Komponenten 

dynamisch werden sollen 

sofern man 

die Schriftgröße 

überhaupt 

variabel gestaltet 

� Buttons abhängig von Fenstergröße belegen nur sinnlos Fläche 



Seite 266

Parameter dynamischer Layouts 

� Fenstergröße 

� großes Fenster ermöglicht Darstellung von mehr Information 

und bessere Gestaltung mit Hilfe von Freiflächen 

� begrenzt durch Bildschirmgröße und -auflösung 

� Schriftgröße 

� idealerweise vom Benutzer wählbar entsprechend individueller 

Sehkraft (vgl. Browserschriftgröße und Windows Grafiktreiber) 

�� sollte bei hochauflösenden Bildschirmen vergrößert werden 

� Extremfall Touchscreen: dicker Finger statt spitzer Maus 

� Textlänge 

� abhängig von der Sprache 

“Speichern unter“ 

“Save as“ 



Seite 267

Layout-Manager in Swing 

� Java unterstützt dynamisches Layout durch 

verschiedene Layout-Manager-Klassen 

� gibt es nicht unter Windows / MFC; 

könnte man sich aber selbst schreiben 

� weil einfach einsetzbar, werden sie in Java eher zu oft verwendet 

� ein Layout-Manager-Objekt wird einem Fenster / Panel / Pane 

zugeordnet und verwaltet dessen Komponenten 

�� Layout wird neu berechnet, wenn sich 

a) die Fenstergröße ändert oder 

b) die Wunschgröße (preferred size) einer Komponente ändert 

� Layout-Manager können geschachtelt werden 

� Freiflächen mittels leerem Rand oder unsichtbaren Komponenten 



Seite 268

Überblick 

� Nutzen Sie die Layout-Manager für das von Ihnen entwickelte User 

Interface im Praktikum! 



Seite 269

"Fließtext": FlowLayout 

� für einfache Reihe von Komponenten 

� Standard bei JPanel 

� Komponenten behalten eigene Größe (PreferredSize) 

� Panel zu schmal � Zeilenumbruch 

� Panel zu groß � Gruppe oben zentriert (oder links- 

/rechtsbündig) 

� wichtige Attribute: 

�� setAlignment: CENTER, LEFT, RIGHT 

� setHgap, setVgap: Lücke zwischen Komponenten 

• Hinweis: auch vor/über erster und hinter/unter letzter Komponente 

(wirkt wie Rand, allerdings nicht bei Zeilenumbruch) 



Seite 270

FlowLayout Programmfragment 

JPanel panel = new JPanel(); 

FlowLayout fl = new FlowLayout(); 

fl.setAlignment(FlowLayout.LEFT); // Ausrichtung 

fl.setHgap(9); // horizontale Lücke 

fl.setVgap(12); // vertikale Lücke 

panel.setLayout(fl); 

// oder gleich: 

panel.setLayout(new FlowLayout (FlowLayout.LEFT, 9, 12)); 

// (Alignment, Hgap, Vgap) 

panel.add(jButton1); // usw.: Komponenten hinzufügen 

Window.pack(); // bewirkt Berechnung des Layouts 



Seite 271

Zeile oder Spalte: BoxLayout 

� senkrechte oder waagrechte Reihe setAlignmentX 

� Ausrichtung jeder Komponente individuell wählbar 

setAlignmentX/Y (1.0=linksbündig ... 0.0=rechtsbündig) 

� Achtung: Default-Alignment ist unterschiedlich je nach Klasse ! 

� leere Komponenten als Platzhalter für Freiflächen 

� RigidArea: Freifläche fester Größe (eine Dimension kann 0 sein) 

ohne: mit: 

�� Glue: Freifläche, die den "Rest" füllt 

ohne: mit: 

� Filler: Freifläche mit Minimum-, Preferred- und MaximumSize 

(ähnlich wie RigidArea, aber variabler) 

� Strut: wird nicht empfohlen; besser RigidArea verwenden 

setAlignmentX 

(0.5) 

Glue hält nicht 

zusammen, sondern 

drückt auseinander 



Seite 272

BoxLayout Programmfragment 


BoxLayout bl = new BoxLayout(panel, BoxLayout.Y_AXIS); 

panel.setLayout(bl); // oder gleich: 

panel.setLayout(new BoxLayout(panel, BoxLayout.X_AXIS)); 

// (Container, Alignment) 

// Alignment der Komponente definieren (wichtig!): 

jButton1.setAlignmentX(Component.CENTER_ALIGNMENT); 

panel.add(jButton1); // Komponenten + Abstände hinzufügen 

panel.add(Box.createRigidArea(new Dimension(5,0))) 

panel.add(jButton2); 

panel.add(Box.createHorizontalGlue()); 




Seite 273

Mitte maximal: BorderLayout 

� maximiert mittlere Kompo- 

nente fensterabhängig; 

reiht andere Komponenten am Rand 

� Layout-Strategie: CENTER maximal 

WEST / EAST möglichst schmal 

NORTH / SOUTH möglichst niedrig 

� häufig ist außer CENTER nur ein weiteres Feld belegt 

� Felder enthalten oft andere Layout-Manager 

� optional mit Hgap / Vgap: Lücken zwischen den Feldern 

� Standard-Layout von JFrame.contentPane 



Seite 274

BorderLayout Programmfragment 


BorderLayout bl = new BorderLayout(); // Hgap=Vgap=0 

panel.setLayout(bl); // oder gleich: 

panel.setLayout(new BorderLayout(9, 12)); // (Hgap, Vgap) 

panel.add(jButton1, BorderLayout.NORTH); 

panel.add(jButton2, BorderLayout.CENTER); 

panel.add(jButton3, BorderLayout.WEST); 

panel.add(jButton4, BorderLayout.SOUTH); 

panel.add(jButton5, BorderLayout.EAST); 



Seite 275

Gleiche Tabellenzellen: GridLayout 

� 2-dim. Raster für Komponenten 

� Komponenten werden auf 

Rastermaß gestreckt 

� Anzahl der Zeilen und/oder Anzahl der Spalten 

muss festgelegt werden 

� Konstruktorparameter oder setRows / setColumns 

� 0 definiert variable Anzahl 

(entweder für Zeilen oder für Spalten) 

� optional mit Hgap / Vgap: Lücken zwischen den Feldern 



Seite 276

GridLayout Programmfragment 


GridLayout gl = new GridLayout (3,2); // Hgap=Vgap=0 

panel.setLayout(gl); // oder gleich: 

panel.setLayout(new GridLayout (0, 2, 9, 12)); 

// (Rows, Columns, Hgap, Vgap) 

0: variable Zeilenzahl 

panel.add(jButton1); // Komponenten zeilenweise ... 

panel.add(jButton2); // von links oben ... 

panel.add(jButton3); // ... nach rechts unten ... 

panel.add(jButton4); // hinzufügen 




Seite 277

Universell: GridBagLayout 

� sehr flexibles Raster-Layout 

� freie Adressierung der Rasterposition 

� Komponenten können gestreckt werden 

� Komp. können sich über mehrere Zeilen 

und/oder Spalten erstrecken 

� Andockkante in größerem Rasterfeld wählbar 

� rasterfeldbezogene Füllattribute 

�� x- und y-"Gewichte" bestimmen Verteilung von Restplatz 

� parameterloser Konstruktor, keine wichtigen Attribute 

0 

1 

2 

0 1 2 

� aber jede Komponente bekommt ein eigenes 

GridBagConstraints-Objekt (reine Datenstruktur) zugeordnet 



Seite 278

GridBagLayout Programmfragment 


GridBagLayout gbl = new GridBagLayout(); 

panel.setLayout(gbl); 

GridBagConstraints gc = new GridBagConstraints(); 

gc.fill = GridBagConstraints.HORIZONTAL; 

gc.gridx = 0; gc.gridy = 0; 

gbl.setConstraints(jButton1, gc); 


gc.weightx = 0.5; 

gc.gridx = 1; gc.gridy = 2; 

gbl.setConstraints(jButton2, gc); 


wird darin geklont (=kopiert) ! 

! nicht dokumentiert; muß 

man im Quellcode nachlesen 



Seite 279

GridBagConstraints (1) 

� int gridx, int gridy 

werden immer einer 

Komponente zugeordnet 

� addressiert Spalte und Zeile für die Komponente 

(Zelle oben links angeben, wenn mehrere Zellen belegt werden) 

� int gridwidth, int gridheight (default 1) 

� Anzahl der von der Komponente belegten Spalten und Zeilen 

� Sonderfall REMAINDER belegt den Rest einer Spalte bzw. Zeile 

� fill = NONE (default), HORIZONTAL, VERTICAL, BOTH 

�� gibt an, ob und wie die Komponente gestreckt werden soll, 

um die ganze Zelle zu füllen 

� int ipadx, int ipady (default=0) 

� vergrößert die Minimalgröße der Komponente um 2*ipad 



Seite 280

GridBagConstraints (2) 

� Insets insets (default new Insets (0,0,0,0)) 

� definiert einen Mindestrand um die Komponente für T, L, B, R 

� anchor = CENTER (default), NORTH, NORTHEAST, EAST, 

SOUTHEAST, SOUTH, SOUTHWEST, WEST, NORTHWEST 

� definiert den Andockpunkt, falls Komponente kleiner als Zelle ist 

� double weightx, double weighty 

(default=0.0; Wertebereich 0.0 ... 1.0) 

�� prozentuale Verteilung von freiem Platz auf Spalten bzw. Zeilen 

(max. weightx innerhalb Spalte bzw. max. weighty innerhalb Zeile 

gilt bei Konflikt zwischen mehreren Zellen) 



Seite 281

Layout-Raster skizzieren 

Fenstergröße 

S 

Fehler 

Icongröße 

S F(Rest) S F(Rest) 

F(0.5) 

F 

Abstände/Ränder 

=f(Schriftgröße) 

max(I,S) 


F(0.5) Prof. Dr.-Ing. Hans-Peter Wiedling 

klicken Sie um die Skizze aufzubauen 

S 

F 

Schriftgröße 

+Textlänge 

S 

Seite 282

Beispiel mit geschachtelten Layouts 

WEST: 

entfällt 

kaum einzuhalten 

NORTH: 1 horizontale Box 

CENTER: 

GridLayout 

1 Zeile, 2 Spalten 

SOUTH: 3 horizontale Boxen in 1 vertikalen Box 

erfordert Feinjustage mittels preferredSize 

Grid- und Box- in BorderLayout 

offenes Problem: 

variable Breite 

EAST: 

vertikale 

Box 



Seite 283

esser mit GridBagLayout 

alle Zellen in Zeilen 0,2,3,4: fill=HORIZONTAL 

gridwidth=2 

fill=BOTH 

horizontale Box; gridwidth=3 

gridwidth=2 

fill=BOTH 

Grid; 

fill= 

HOR. 

Spalte: 0 1 2 3 4 

größte preferredSize setzt sich durch 

Zeile 



0 

1 

3 

4 

2 

Seite 284

Vorgehensweise beim Layout 

� notwendige Komponenten aus Use Cases ermitteln 

� Komponenten freihändig gruppieren und positionieren 

� Flucht- und Symmetrielinien identifizieren / definieren 

� Anzahl der Fluchtlinien klein halten 

� Fluchtlinien können gezeichnete Linien 

ersetzen: "gutes Design braucht keine (gezeichneten) Linien" 

� Rasterzeilen und -spalten bemaßen 

das Auge ist da 

sehr empfindlich ! 

�� dyn. Layout: abhängig von Schrift-, Fenster- und Icongröße 

• bei mehrsprachigen Anwendungen auch abhängig von Textlänge 

• im allgemeinsten Fall sind alle Maße variabel! 

� (statisches Layout: absolute Zahlen in Pixel) 



Seite 285 

Analyse - Gestaltung - Konstruktion

Auswahl anwendungsfallorientiert 

� möglichst viel Platz für eine Komponente 

� BorderLayout: im CENTER 

� GridBagLayout: constraint.fill = GridBagConstraints.BOTH 

� ein paar Komponenten kompakt in einer Zeile oder Spalte 

in deren jeweils eigener Standardgröße: 

� auf JPanel mit FlowLayout (nur Zeile) oder BoxLayout 

� ein paar Komponenten gleicher Größe: 

�� GridLayout (evtl. nur 1 Zeile oder 1 Spalte) 

� komplexes Layout mit vielen Komponenten 

� GridBagLayout oder mehrere geschachtelte Panels 

� feste und variable Zellengrößen frei kombinierbar 



Seite 286

Komponentengröße beeinflussen 

Achtung: Abhängigkeit von Schriftgröße wird durch explizites Setzen zerstört ! 

� setMinimumSize, setPreferredSize, setMaximumSize 

� nach Änderung revalidate und repaint aufrufen 

Führungselement 

� gleiche Größe für mehrere Komponenten: 

jComp2.setPreferredSize (jComp1.getPreferredSize()); 

� manche Layout-Manager respektieren manche Attribute: 

BorderLayout 

Minimum Preferred Maximum 

BoxLayout X X 

FlowLayout X 

GridBagLayout X 

GridLayout 



Seite 287

Bemerkung zur Schriftgröße 

� Änderung der Schriftgröße 

erfordert neues Font-Objekt 

� Methode setFontSize fehlt 

� Zuordnung des Font-Objekts zu 

allen betroffenen Komponenten 

mit setFont 

oder 

�� setFont(null) für alle 

� dann erben sie vom Parent 

� nur contentPane bekommt 

gewünschtes Font-Objekt 

zugeordnet 

� Problem bei Optimierung der 

Größe von Buttons mittels 

setPreferredSize: 

� die Größe ist damit festgelegt 

und orientiert sich nicht mehr 

an Schriftgröße und Textinhalt 

�� Bug beim Erben des Font: 

� JComboBox bestimmt ihre 

preferredSize nicht neu 



Seite 288

Screen zur Erfassung einer Problembeschreibung 

... für unser 

Ticketsystem 



Seite 289

Screen zur Erfassung einer Problembeschreibung 

Ziel zunächst: 

•Aufbau des 

Screens 

identifizieren 

•Container 

benennen 

•LayoutManager 

auswählen 



Seite 290

Layout – Analyse: Rasterlinien einzeichnen 



Seite 291

Layout – Analyse: Bestandteile identifizieren 

Im WEST- 

Bereich: 

JPanel 

(clientPanel) 

mitGridLayout 

mit JLabel und 

JTextField 

ContentPane 

mit 

BoderLayout 

Im EAST- 

Bereich: 

JPanel 

(catPanel) mit 

GridLayout mit 

JLabel, 

5 CheckBoxen 

und 2 JButton 

Im CENTER-Bereich: JPanel (descrPanel) 


mit FlowLayout mit JLabel und 


JScrollPane und TextArea 

Seite 292

Layout–Kodierung: Programmcode in Java 

// Panel: 

private JPanel jContentPane // steht zu Verfügung 

private JPanel clientPanel; 

private JPanel descrPanel; 

private JPanel catPanel; 

// CheckBox: 

private JCheckBox software = new JCheckBox("Software"); 

private JCheckBox hardware= new JCheckBox("Hardware"); 

private JCheckBox bedienung= new JCheckBox("Bedienung"); 

private JCheckBox betriebssystem= new 

JCheckBox("Betriebssystem"); 

private JCheckBox netzwerk= new JCheckBox("Netzwerk"); 

// text. Beschreibung 

private JTextArea description;; 

// Button: 

private JButton abbrechen = new JButton ("Abbruch"); 

private JButton erfassen = new JButton ("Erfassen"); 



Seite 293

clientPanel und descrPanel erstellen 

clientPanel = new JPanel (new GridLayout (0,1)); 

clientPanel.add(new JLabel ("Kunde")); 

clientPanel.add(new JTextField ("Kunde")); 

clientPanel.add(new JLabel ("Email")); 

clientPanel.add(new JTextField ("@kunde.com")); 

this.jContentPane.add(clientPanel, BorderLayout.WEST); 

descrPanel = new JPanel (); 

descrPanel.setLayout (new 

BoxLayout(descrPanel,BoxLayout.Y_AXIS)); 

JLabel describLbl = new JLabel ("Beschreibung"); 

describLbl.setAlignmentX(Component.LEFT_ALIGNMENT); 

descrPanel.add(describLbl); 

description = new JTextArea (5, 8); 

descrPanel.add(new JScrollPane( description )); 

this.jContentPane.add(descrPanel, BorderLayout.CENTER); 



Seite 294

catPanel erstellen 

catPanel = new JPanel (new GridLayout (0,1)); 

software.setSelected(true); 

catPanel.add(new JLabel("Kategorie(n)")); 

catPanel.add(software); 

catPanel.add(hardware); 

catPanel.add(bedienung); 

catPanel.add(betriebssystem); 

catPanel.add(netzwerk); 

catPanel.add(Box.createRigidArea(new Dimension(0, 10))); 

erfassen = new JButton ("Erfassen"); 

catPanel.add(erfassen); 

abbrechen = new JButton ("Abbruch"); 

catPanel.add(abbrechen); 

this.jContentPane.add(catPanel, BorderLayout.EAST); 



Seite 295

Aufgabe 

Skizzieren Sie das Layout-Raster und wählen Sie geeignete Layout-Manager ! 

� Notepad Editor:Datei -> Seite einrichten � Windows Taschenrechner 



Seite 296

Dialogbausteine 

� Ein Dialog besteht aus 2 Komponenten: 

� Layout/Präsentation 

Dialogelement und Dialogablauf (grafische Darstellung von Dialogelemente, 

Einbettung in das Gesamtsystem) 

� Logik/Semantik 

anwendungsabhängige Bearbeitung der Eingabe (Methode, die wir angeben, 

um ein von Benutzer initiiertes Ereignis zu bearbeiten) 

� Komplexe Dialoge werden anhand der Dialogbausteine wie in einem 

Baukasten zusammengesetzt 



Seite 297

Logische Eingabeklasse 

� Ein wichtiges Element grafischer Oberflächen zur Generalisierung eines 

Ansatzes ist die Modellierung einer Schnittstelle nach log. Gesichtspunkten 

(mit dem Ziel der Wiederverwendbarkeit, Entlastung der 

Applikationsentwicklung, Konsistenz, …) 

� Man kann dabei im Wesentlichen zwei Arten von Interaktionsgruppen 

unterscheiden: 

� Aufgaben zur diskreten Eingabe 

�� Aufgabe zur dynamischen Steuerung 

� Typischerweise kann man bei einer eingabeorientierten Ausgabe die 

folgenden elementaren Dialoge unterscheiden: 



Seite 298

Klassifikation diskrete Eingabe 

Logischer Dialog Kommentar Realisierungbeispiel 

�� 1-aus-n Auswahl diskrete sehr begrenzte JMenu, JComboBox, 

Auswahl (z.B. Kommando) JButtonGroup (JRadioButtons), 

JButton 

� n-aus-m Auswahl diskrete (sehr) begrenzte JToggleButton, JCheckbox, 

Auswahl (z.B. Parameter) JList, JButtons 

� Punkteingabe i. A. Punkt in Problem- JTextField, 

koordinaten Mausklick (anwendungsspez.) 

� Obj. Auswahl Identifikation JTextField, 

Mausklick (anwendungsspez.) 

� Text Name, Kommentar, ... JOptionPane, JTextField, 

Kommando JTextArea 

� Wert Skalar, 

(z.B. Temperatur) … 

JTextField, JSlider, JScrollbar 



Seite 299

Klassifikation dynamische Steuerung (I) 

� Hier steuert der Benutzer das Verhalten von sichtbaren Elementen in einer 

dynamischen und direkt gekoppelten Art und Weise. 

� Charakteristisch für die dynamische Steuerung ist eine sehr enge Kopplung 

zwischen Eingabe und Ausgabe, um dem Benutzer eine kontinuierliches 

Feedback zu geben: 



Seite 300

Klassifikation dynamische Steuerung (II) 

Logischer Dialog Kommentar Realisierungsbeispiel 

�� Dehnen Objekt skalieren Gummiband, Rechteck 

� Zeichnen Freiformkurven Stift, Pinsel 

� Manipulieren Drehen, Verschieben, “Drag&Drop“ 

Ablegen, Löschen, 

Papierkorb, Scrollbar 

� Formen Kurven Stützstellen, Kurve 

(z.B. Beziér, NURBS) 

Viele dieser Techniken werden weitgehend durch standardisierte 

Interaktionselemente realisiert. Sie spiegeln die Schnittstellenmetapher 

direkt-manipulativer Anwendungen etwa aus dem Bürobereich wider und 

werden in vielen unterschiedlichen Anwendungen eingesetzt. 



Seite 301

GUI- und Anwendungsobjekte 

Wichtig in allen Fällen ist die Rückkopplung aller benutzergesteuerten Aktionen: 

�� anwendungsunabhängig 

durch aktuelle Position des (Text-/Maus-)Cursors und 

� anwendungsabhängig 

durch Zugriff auf die Modelldaten 

� Einerseits wird die konsequente Trennung zwischen Applikation und grafischer 

Oberfläche angestrebt 

�� Andererseits muss die Kontrolle zwischen Dialogteilen und 

Anwendungsprogrammteilen gegeben sein 

� Neben der Übersicht über die Dialogbausteine werden wir sowohl die Kopplung 

zwischen Anwendung und GO als auch die Ereignisbehandlung betrachten 



Seite 302

Bausteine grafischer Bedienoberflächen 

� Begriffe uneinheitlich 

�� Windows: Control/Steuerelement 

� Java: Component 

� Motif: Widget 

Window Gadget: 

Gadget: Ding(s), Teilchen, Vorrichtung, Dingsbums 

� Widget: Fensterobjekt 

� WIMP-System := { Window, Icon, Menu, Pointing Device } 

� visuelle Klassen 

�� Objekte aktualisieren/zeichnen sich selbst auf den Bildschirm 

� Erscheinungsbild und Verhalten über Attribute einstellbar 

� Ereignisbehandlung 

• teilweise im Zusammenspiel mit übergeordnetem Fenster 

� große Auswahl in Bibliotheken, Eigenkreation möglich 



Seite 303

Swing Components 

Schaltflächen 



Textfelder Auswahl 1 aus n 

Seite 304




Seite 305

Schaltflächen: Charakterisierung 

� Buttons dienen dem 

Auslösen einer Aktion 

� meist beschriftet, 

manchmal mit Bild 

� können zu Buttonleisten 

aneinandergereiht werden 

� Gruppen von RadioButtons 

� Toolbars 

�� können inaktiv (disabled) sein 

� haben Boole'schen Zustand 

� temporär (d.h. nur Feedback) bei JButton 

AbstractButton 

JButton JToggleButton 

Aktion 

JCheckBox JRadioButton 

� permanent bei den anderen (durch Gruppierung auch 1-aus-n) 

Zustand 



Seite 306

JButton löst nur Aktion aus 

� Schaltfläche mit Icon und/oder Text 

high level event 

� Ereignisse: actionPerformed(ActionEvent) // beim Anklicken 

� I/O: keine 

� Methoden: 

� setEnabled(boolean); 

� setVisible(boolean); 

�� setActionCommand(String); 

// wird Attribut von ActionEvent 

� getRootPane().setDefaultButton(JButtonX); 

// übergeordnete Pane: JButtonX erhält Event 



Seite 307

ImageIcon: statische Bilder 

auch für großes Hintergrundbild 

� Buttons, Labels, Listen etc. können Icons darstellen 

� Bilddateiformat GIF oder JPEG 

� am einfachsten mit Bildbearbeitungsprogramm erstellen 

und in Datei ablegen 

� GIF auch mit transparentem Hintergrund ("freigestellt") 

ImageIcon Bild = new ImageIcon("Verzeichnis/Bild.gif"); 

JLabel Label = new JLabel(); 

Label.setIcon(Bild); 

nicht nur in Buttons! 

ImageIcon Bilder[] = { new ImageIcon("Verzeichnis/Bild0.gif"), 

new ImageIcon("Verzeichnis/Bild1.gif")}; 

JComboBox ComboBox = new JComboBox(Bilder); 



Seite 308

Buttons und Bilder: Icons 

JButton jButton1 = new JButton(); 


... 

ImageIcon ii = new ImageIcon ("contact.gif"); 

jButton1.setPreferredSize( 

new Dimension(ii.getIconWidth(), ii.getIconHeight() )); 

jButton1.setIcon (ii); 

... 

jButton2.setText("Kontakt"); 

contentPane.add (jButton1, ...); 

contentPane.add (jButton2, ...) 



Seite 309

JToggleButton: Zustand + Aktion 

� wie JButton, aber mit Zustandsanzeige "gedrückt" 


itemStateChanged(ItemEvent)// bei Zustandswechsel 

� I/O: isSelected() // boolean 

ItemEvent.getStateChange() // SELECTED / DESELECTED 

� Methoden: 

� setSelected(boolean); 



� setActionCommand(String); //wird Attribut von ActionEvent 



Seite 310

JCheckBox: Wahrheitswert 

� wie JToggleButton, aber mit Zustandsanzeige "Häkchen" 


itemStateChanged(ItemEvent) // bei Zustandswechsel 

� I/O: isSelected() // boolean 

ItemEvent.getStateChange() // SELECTED / DESELECTED 

� Methoden: 




� setActionCommand(String);// wird Attribut von ActionEvent 



Seite 311

JRadioButton 

� wie JCheckBox, tritt aber typischerweise in Gruppen auf 

�� Gruppe mit gegenseitiger Auslösung: 

ButtonGroup grp = new ButtonGroup(); 

grp.add(jRadioButton1); 

grp.add(jRadioButton2); 

ButtonModel bm = grp.getSelection(); 


� Merkmal: ActionEvent.getActionCommand() // String 

� Methoden bei JRadioButton: 

�� setActionCommand(String); // wird Attribut von ActionEvent 


� setMnemonic(KeyEvent.VK_B); // virt. Key Code (hier für „B“) 

� setSelected(true); 

� etc. 



Seite 312

JMenuBar, JMenu: Hauptmenü 

� Platzsparende Form der Gruppierung mehrerer Buttons 

� normale Schaltflächen, aber auch Checkboxen und Radiobuttons 

� vorzugsweise für "globale" Funktionen 

� ermöglicht hierarchische Gliederung durch Kaskadierung 

• durch Überstreichen gut geeignet zum Erforschen einer unbekannten 

Anwendung 

� u. U. umständlich zu bedienen, besonders bei Kaskadierung 

�� am oberen Rand von JFrame, JDialog, JApplet 

JMenuBar meinMenu = new JMenuBar(); 

this.setJMenuBar(meinMenu); 

� Ereignisbehandlung über ActionListener der MenuItems wie bei Buttons 



Seite 313

Aufbau eines Menüs 

� Objekte erzeugen 

JMenu jMenu2 = new JMenu(); 

JMenuItem jMenuItem21 = new JMenuItem(); 

in Eclipse durch eigene Variante 

des Visual Editors unterstützt 

� Attribute setzen // weitere siehe Buttons 

jMenuItem21.setText ("Ausschneiden"); 

jMenuItem21.setEnabled (false); 

� Objekte verknüpfen 

jMenuBar1.add (jMenu2); 

jMenu2.add (jMenuItem21); 

jMenuBar1.add (Box.createHorizontalGlue());//nächstes rechts 

jMenu2.addSeparator (); // Trennlinie 



Seite 314

JPopupMenu: Kontextmenü 

� verborgenes Menü 

� belegt keine Bildschirmfläche, aber Benutzer muß suchen! 

� typischerweise für objektbezogene Funktionen 

� verschiedene Objekttypen haben verschiedene Kontextmenüs 

� Menüaufbau wie beim Hauptmenü: 

JPopupMenu jPopupMenu1 = new JPopupMenu(); 

JMenuItem jMenuItemP1 = new JMenuItem(); 

jMenuItemP1.setText ("Ausschneiden"); 

jPopupMenu1.add (jMenuItemP1); 



Seite 315

Kontextmenü-Ereignisbehandlung 

� Aufruf aus MouseListener des 

sensitiven Objekts 

void mouseReleased(MouseEvent e) 

{ 

} 

unter Windows und Motif 

mit rechtem Mausklick; 

für andere OS zusätzlich 

mousePressed 

if (e.isPopupTrigger()) 

jPopupMenu1.show(e.getComponent(), e.getX(), e.getY()); 

� Zugriff auf zugehöriges Objekt und MenuItem 

void actionPerformed(ActionEvent e) { 

JMenuItem aktItem = (JMenuItem)e.getSource(); 

JPopupMenu aktPopup = (JPopupMenu)aktItem.getParent(); 

JObject geklicktesObjekt = aktPopup.getInvoker(); 

// irgendetwas wird damit gemacht ... 

} 



Seite 316

Toolbars 

� Menüs werden häufig ergänzt durch Toolbars 

� schnellerer Zugriff für Fortgeschrittene 

� der Toolbar enthält eine häufig verwendete Teilmenge der Menü- 

Funktionen 

� als Gruppe von Buttons, meist mit Icons gekennzeichnet 

� kann vom Rand des Fensters "abgerissen" werden (hoch/quer) 

� oft vom Benutzer selbst konfigurierbar 

�� Icons sind fast nie selbsterklärend: sie müssen erlernt werden! 

� eine gute Hilfe dazu sind Tooltips (d.h. Texte, die nur erscheinen, 

wenn die Maus auf dem Button verweilt) 



Seite 317

JToolBar 

� Objekte erzeugen 

JToolBar jToolBar1 = new JToolBar(); 


� Attribute setzen 

jButton1.setIcon (new ImageIcon("Icons/img_cd.gif")); 

jButton1.setToolTipText ("CD abspielen"); 

� Objekte verknüpfen 

(die contentPane muß ein BorderLayout haben) 

contentPane.setLayout(new BorderLayout());// i.d.R. default 

contentPane.add(jToolBar1, BorderLayout.NORTH); 

jToolBar1.add (jButton1, null); 

jToolBar1.addSeparator (); // Abstand einfügen 



Seite 318

Textfelder: Charakterisierung 

� Textfelder dienen der Ein- 

und Ausgabe von Text 

� sie integrieren einfache oder 

komplexe Editorfunktionen 

� Cursor 

� Selektion 

JTextComponent 

JTextfield JTextArea 

JEditorPane 

� Kopieren, Einfügen 

JPasswordField JTextPane 

� mehrzeilige Textfelder 

können Scrollen, wenn die 

einzeilig mehrzeilig Editor für 

Fläche nicht ausreicht 

Text, HTML 

� können inaktiv (disabled) sein behandeln wir nicht 

und RTF mit 

Formatierung 



Seite 319

JTextField: einzeilige I/O + Aktion 

� für Ein- oder Ausgabe von kurzen Texten oder Zahlenwerten, oft mit 

anschließender Aktion 

� Ereignis: actionPerformed(ActionEvent) // bei Return 

� Methoden: 

� getText(), setText(String) // Zugriff auf gesamten Inhalt 

� select(int, int), selectAll() // markiert (selektiert) Text 



Seite 320

JTextArea: mehrzeilige I/O 

� für Ein- oder Ausgabe von mehrzeiligen Texten 

beliebiger, aber 

einheitlicher Font 

� kann scrollen, wenn innerhalb einer JScrollPane plaziert: 

contentPane.add(jScrollPane, null); 

jScrollPane.getViewport().add(jTextArea, null); 

� Ereignis: actionPerformed(ActionEvent) // bei Return 

� Methoden: 

�� getText(), setText(String); // Zugriff auf gesamten Inhalt 

� append(String); // hängt Text am Ende an 

� insert(String, int); // fügt Text an Position ein 

� replaceRange(String, int, int); // ersetzt einen Textbereich 



Seite 321

Wertebereichsüberprüfung 

� "action validated" 

� Überprüfung des eingegebenen Werts, nachdem "Return" 

gedrückt wurde 

• Zwischenzustände bei der Eingabe spielen keine Rolle 

• bequem zu Editieren 

� im actionPerformed-Handler vor der Weiterverarbeitung 

- So machen Sie es im Rahmen des Praktikums! - 

� Weiter Möglichkeiten werden wir im Rahmen der 

Ereignisbehandlung betrachten 



Seite 322

Auswahllisten: JComboBox, JList 

� Lineare, ungegliederte Liste 

� oft besser als Textfeld mit Gültigkeitsüberprüfung 

� Einfachauswahl oder Mehrfachauswahl 

� Vorteile gegenüber Gruppe aus Radiobuttons: 

� große Zahl von Listenelementen ist möglich 

ABER: Überschaubarkeit und Suchaufwand für den Benutzer sind 

zu bedenken 

�� Listenelemente können zur Laufzeit geändert bzw. 

datenabhängig geladen werden 

� JComboBox als platzsparende Variante 



Seite 323

JList: sichtbare Liste 

� Einfach- oder Mehrfachauswahl 

� Strings oder Icons als Elemente 

(� ListCellRenderer für anwendungsspezifische Darstellung) 

� Listenelemente aus Object[] oder DefaultListModel 

• Konstantenliste am besten über String Werte[]={...}; 

� kann scrollen, wenn innerhalb einer JScrollPane plaziert 

� Ereignis: 

(dynamisch) 

�� boolean valueChanged(ListSelectionEvent)// Auswahländerung 

� I/O: int, Object oder Array // Index oder ausgewähltes Objekt 

� Methoden: 

String 

� boolean getValueIsAdjusting()// wird Auswahl noch geändert? 



Seite 324

JList: Auswahlmodus und Selektion 

� Auswahl des Auswahlmodus 

jL.setSelectionMode(ListSelectionModel.SINGLE_SELECTION); 

� SINGLE_SELECTION 

� int getSelectedIndex() 

� Object getSelectedValue() 

� SINGLE_INTERVAL_SELECTION 

� int getMinSelectionIndex() 

� int getMaxSelectionIndex() 

� MULTIPLE_INTERVAL_SELECTION 

� int[] getSelectedIndices() 

� Object[] getSelectedValues() 

Auswahl mit Festhalten 

der Umschalt-Taste 

Auswahl mit Festhalten 

der Strg-Taste 



Seite 325

JComboBox: ausklappbare Liste 

� nicht editierbar: Auswahl 1-aus-n, auch Icons statt Text oder 

� editierbar: wie Textfeld mit Vorgaben 

� ComboBox.setEditable(true); // false ist Standard 

� statische oder dynamische Liste wie bei JList 

� Ereignis: actionPerformed(ActionEvent) // Auswahl oder Return 

� I/O: int oder Object (� String, ImageIcon oder ... ) 

� Methoden: 

�� setSelectedIndex(int), int getSelectedIndex() // Index 

� ComboBox.getSelectedItem().toString() // Text 

� (ImageIcon)(ComboBox.getSelectedItem()) // Bild 



Seite 326

Dynamische Listen (I) 

� Änderung der Listenelemente zur Laufzeit 

erfordert Objekt der Klasse DefaultListModel 

fast identisch für 

JList und JComboBox 

� dieses enthält die Daten und informiert JList bzw. JComboBox 

über Änderungen 

DefaultListModel Daten = new DefaultListModel(); 

JList Listbox = new JList(Daten); 

JScrollPane ScrollPane = new JScrollPane(); 

ScrollPane.getViewport().add(Listbox, null); 

contentPane.add(ScrollPane, null); 

Daten.addElement("neuer Eintrag"); 

bzw. DefaultComboBoxModel 

Daten.removeElementAt(0); // oder removeElement(Object) 



Seite 327

Dynamische Listen (II) 

1.: Registrieren 

DefaultListModel List3 = new 

DefaultListModel(); 

JList jList3 = new 

JList(List3); 

... 



Seite 328

Dynamische Listen (III) 

2.: Neues Element zur 

Liste hinzufügen 

//(z.B. in der Ereignisbehandlung eines Textfeldes): 

List3.addElement(jTextField1.getText()); 

// das neue (letzte) Element selektieren: 

jList3.setSelectedIndex(List3.size()-1); 



Seite 329

Dynamische Listen - Prinzip 

View 

JList Objekt 

Registrierung 

( new JList(...) ) 

... 

Benachrichtigung 

( addElement ... ) 

Model 

DefaultListModel Objekt 

„2“ 

„Beispiel“ 

„Dienstag 

“ 

... 

Durch Model- und View- Objekte 

wird die Applikation weitgehend 

entlastet! 



Seite 330

JComboBox 

private JComboBox comboSelect = new JComboBox( ); 

... 

comboPanel.setBackground(new Color(250, 250, 0)); 

• Objekte werden der 

for (TicketState t : TicketState.values()) 

ComboBox per 

addItem hinzugefügt 

comboSelect.addItem(t); 

oder mit 

comboPanel.add(comboSelect); 

• removeItemAt (i) 

entfernt 

comboSelect.addActionListener(new • ActionListener wird 

java.awt.event.ActionListener() { registriert 

public void actionPerformed(ActionEvent e) { 

comboBox_actionPerformed(e); 

} 

}); 



Seite 331

JComboBox mit DefaultComboBoxModel 

private DefaultComboBoxModel daten = new DefaultComboBoxModel(); 

private JComboBox comboSelect = new JComboBox(daten); 

... 

comboPanel.setBackground (new Color(250, 250, 0)); 

for (TicketState t : TicketState.values()) 

daten.addElement(t); 

comboPanel.add(comboSelect); 

comboSelect.addActionListener( new 

java.awt.event.ActionListener() { 


comboBox_actionPerformed(e); 

} 

}); 

• Objekte werden einer 

Modelklasseninstanz 

per addElement 

zugeordnet 

(Vorteil: 

Daten sind veränderbar) 

• ActionListener wird 

registriert 



Seite 332

JList mit DefaultListModel 

DefaultListModel daten = new DefaultListModel(); 

JList listSelect = new JList(daten); 

listPanel.setBackground(new Color(250, 250, 0)); 

for (TicketState t : TicketState.values()) daten.addElement(t); 

listPanel.add(listSelect); 

listSelect.addListSelectionListener(new ListSelectionListener() { 

public void valueChanged(ListSelectionEvent evt) { 

// When the user release the mouse button and completes the 

// selection getValueIsAdjusting() becomes false 

if (!evt.getValueIsAdjusting()) { 

JList list = (JList) evt.getSource(); 

Object[] selected = list.getSelectedValues(); 

// Iterate all selected items 

for (int i = 0; i < selected.length; i++) { 

Object sel = selected[i]; 

System.out.println(sel); 

}// for 

}// if 

}// valueChanged 

}); 

• Objekte werden einer 

Modelklasseninstanz 

per addElement 

zugeordnet (Vorteil: 

Daten sind veränderbar) 

• ListSelectionListener 

wird registriert 



Seite 333

Interface ListCellRenderer: 

� … und für das Darstellen gibt es auch Interfaces: 

Das Interface ListCellRenderer besitzt nur die folgende Methode: 

� public Component getListCellRendererComponent 

( 

JList list, Componente/Liste 

Object value, darzustellendes Objekt aus dem Model; 

entspricht: list.getModel().getElementAt(index) 

int index, Position in der Liste 

boolean isSelected, Element ausgewählt 

boolean cellHasFocus Element hat Focus 

) 

� Der Rückgabewert ist eine Componente (JLabel), die dargestellt wird. 

� Wird mit der Methode list.setCellRenderer(new MyRenderer()); 

JList-Instanz gesetzt 



Seite 334

JSlider: diskrete Werte mit Einrasten 

� nur grobe Einstellmöglichkeit per Maus 

� wahlweise mit "Einrasten" bei Ticks 

� spezielle Beschriftung mittels Hashtable (Assoziativtabelle, 

Schlüssel/Wert-Paare) 

� Ereignis: stateChanged(ChangeEvent) 

� I/O: void setValue(int); int getValue() 

�� Eigenschaften: 

setMinimum(-20); setMaximum(80); 

setMinorTickSpacing(5); setMajorTickSpacing(20); 

setPaintLabels(true); setPaintTicks(true); 



Seite 335

JProgressBar: reine Anzeige 

� zur Anzeige länger dauernder Abläufe 

� beruhigt den Benutzer 

� Alternative: Klasse ProgressMonitor macht Dialog auf 

� Ereignis: keines (darstellungsorientiert) 

� Output: void setValue(int) 

� Eigenschaften: 

setMinimum(-20); setMaximum(80); 

setOrientation(JProgressBar.VERTICAL); 



Seite 336

JScrollBar: meist für Fenster 

� grobe Einstellmöglichkeit per Maus 

� Feineinstellung mit 

� Unit Increment (Klicken auf Buttons) und 

� Block Increment (Klicken auf Leiste) 

� Ereignis: adjustmentValueChanged(AdjustmentEvent) 

� I/O: void setValue(int); int getValue() 

�� Eigenschaften: 

setMaximum(90); setMinimum(-20); 

setBlockIncrement(20); setUnitIncrement(2); 



Seite 337

Architektur: Model-View-Control 

� Data Model: 

zugrunde liegende Anwendungsfunktionen und -datenstrukturen 

„WAS wird angezeigt“ 

� View: 

Präsentation der Daten – GUI Componente 

„WIE wird etwas angezeigt“ 

� Control: 

Reaktion (Prüfung und Weiterleitung) auf Eingaben oder Modelländerungen 

� Das Ziel ist, jede Komponente getrennt zu entwickeln, testen und 

u.U. auch im Gesamtsystem auszutauschen (lose Kopplung der Objekte) 

� Manchmal findet ein Observer-Pattern (oder das Publisher-Subscriber- 

Framework) Anwendung: Beim Start meldet sich Observer beim 

beobachtenden Objekt an; beobachtenden Objekt informiert Beobachter. 



Seite 338

MVC – Model View Control 

Model/Document 

MyModel/ 

MyDocument 

Applikation 

Object 

View Control 

MyView MyControl 

GO Objekte 

Ereignisbehandlung 

(Callbacks) 


Anwendung 



Seite 339

Arbeitsweise von MVC 

(1) 

(2) 

View 

Control 

Model 

(3) 

(4) 

(1) View empfängt ein Dialogereignis vom Benutzer und ruft 

eine entsprechende Funktion von Control zur Umsetzung 

des Ereignisses auf. 

(2) Control manipuliert das Model entsprechend der 

Operation mit passenden Funktionen, die das Model 

anbietet. 

(3) Control löst Änderungen in der Darstellung von 

View aus, die sich als Folge der abgewickelten 

Operation ergeben haben. 

(4) View holt sich nach Bedarf weitere Daten von Model, 

um sie zu präsentieren. 



Seite 340

Umsetzung: Model-View-Control 

� View (als Buttons, Checkboxen, …) und 

Control (als Listener) sind in den Komponenten festgelegt 

� Konsequenz für die Realisierung: 

� Anwendungsfunktionalität und Graphische Oberfläche sind getrennt! 

� Anwendungsfunktionen sind nicht unmittelbar als Code in den Methoden 

zur Ereignisbehandlung eingebaut und 

� die Anwendungsfunktionen können vollständig separat in eigenen 

Klassen formuliert werden; Zugriff erfolgt über definierte Schnittstellen 

�� Vorschlag: Modell als Interface vereinbaren 

Modell oder View kann variiert werden! 

� Es bieten sich Default-Klassen (Container) für die Anwendung an (z.B. 

ArrayList, …) 



Seite 341

Beispiel: JTable 

� Verwenden Sie JTable oder JTree in 

Ihrem Programmcode im Praktikum! 

Statische 

Tabelle 

Dynamische 

Tabelle 

(sollte Ihr 

Favorit sein) 



Seite 342

Model-View-Control Architektur 

� konsequente Trennung zwischen 

Datenhaltung und Sicht auf die Daten 

� z.B. Datenhaltung: ArrayList von Arrays 

� z.B. Sicht: 2-dim. Tabelle mit Spaltenüberschriften 

� aufwendiger zu handhaben, aber flexibler 

� Standard-Datenmodell für einfache Fälle 

� View-Klasse erwartet von der Model-Klasse, 

dass sie bestimmte Methoden implementieren/bereitstellen 

ArrayList 

Arrays 



Seite 343

DynamischeTabelle 

extends AbstractTableModel (I) 

class DynamischeTabelle extends AbstractTableModel 

{ 

final int AnzahlSpalten; // feste Breite 

ArrayList tabelle = new ArrayList(); // Menge mit Anwendungsobjekten 

public DynamischeTabelle (int AnzahlSpalten, ArrayList tabelle ) { 

} 

this.AnzahlSpalten = AnzahlSpalten; 

this.tablle = tabelle; 

public Class getColumnClass (int columnIndex) { 

} 

try { // Spalte 5 wird als Boolean interpretiert: 

} 

if (columnIndex==4) return Class.forName("java.lang.Boolean"); 

else return Class.forName("java.lang.Object"); 

catch (ClassNotFoundException ce) { 

} 

System.out.println(ce.getMessage()); return null; 



Seite 344


extends AbstractTableModel(II) 

public boolean isCellEditable (int rowIndex, int columnIndex) 

{ 

// nur Spalte 5 soll editierbar sein: 

return (columnIndex == 4); 

} 

public int getRowCount () 

{ 

return tabelle.size(); 

} 

public int getColumnCount () 

{ 

return anzahlSpalten; 

} 

public Object getValueAt (int row, int column) 

{ 

Object[] tabellenzeile = (Object[])tabelle.get(row); 

return tabellenzeile[column]; 

} 



Seite 345


extends AbstractTableModel(III) 

public void setValueAt (Object aValue, int rowIndex, int columnIndex) 

{ 

Object[] tabellenzeile; 

if (rowIndex < tabelle.size()) 

tabellenzeile = (Object[])tabelle.get(rowIndex); // Zeile existiert schon 

else if (rowIndex == tabelle.size()) { 

tabellenzeile = new Object[AnzahlSpalten]; // neue Zeile allokieren ... 

tabelle.add(tabellenzeile); // und an DisplayList hängen 

fireTableRowsInserted(rowIndex, rowIndex); // über Änderung informieren 

} 

else 

throw new ArrayIndexOutOfBoundsException( 

"DynamischeTabelle erlaubt nur anhängen"); 

tabellenzeile[columnIndex] = aValue; // neuen Wert eintragen 

fireTableCellUpdated(rowIndex, columnIndex); // über Änderung informieren 

} 

public String getColumnName (int i) // liefert Spaltenüberschrift 

{ 

return “Entity"; 

} 

} // DynamischeTabelle 



Seite 346

JTable 

� Details siehe auch: 

http://java.sun.com/docs/books/tutorial/uiswing/components/table.html#renderer 

bzw. 

http://download.oracle.com/javase/tutorial/uiswing/components/table.html#renderer 

� Swing Tutorial: 

http://java.sun.com/docs/books/tutorial/uiswing/components/dialog.html#create 

bzw. 

http://download.oracle.com/javase/tutorial/uiswing/components/index.html 



Seite 347

Tabellen 

� Schneller Überblick auf viele Merkmale gleichartiger Objekte 

� Neben dem reinen Markieren/Auswählen gibt es noch weitere 

nützliche Eigenschaften: 

Typprüfungen/-einhaltungen beim Editieren 

� für String, Integer, Float/Double, Boolean 

� aber auch für 1-aus-n und n-aus-m Auswahl bei den einzelnen 

Merkmalen in den Tabellenzellen bieten sich sehr geeignete 

Konstrukte an: 

• In TableCellRenderer werden Darstellungsmerkmale ausgedrückt 

• Im AbstractCellEditor wird die Übergabe/Empfang der Merkmale an 

das Model beschrieben 

� Die Objekte in der Tabelle können sortiert und/oder gefiltert werden. 



Seite 348

Sichere Typen in Tabellenzellen 

� Allgemein kann die Methode getValueAt(rowIndex, columnIndex).getClass(); 

die spezifische Klasse liefern 

� String (Class.forName("java.lang.String")) und Integer 

(Class.forName("java.lang.Integer")) 

erfordern keine weiteren Einstellungen 

� Für Class.forName("java.lang.Boolean") 

sollte eine JCheckBox als CellRenderer eingesetzt werden: 

jTable2.setDefaultEditor(Class.forName("java.lang.Boolean"), 

new DefaultCellEditor(new JCheckBox())); 

� Für Class.forName("java.lang.JComboCox") 

sollte ein JComboBox –Objekt eingerichtet werde 

� Class.forName("java.lang.JList") 

benötigt einen CellRenderer und einen CellTableEditor 

� Der geschickte Einsatz macht Tabellen sicherer, flexibel und reduziert letztendlich den 

Programmieraufwand 



Seite 349

JTable: Model und View für 1-aus-n Auswahl 

TicketState 

anzeigen 

TicketState 

ändern 



Seite 350

Klasse, Editor und Renderer bereit stellen 

public Class getColumnClass(int columnIndex) { 

return getValueAt(0, columnIndex).getClass(); } 

� Editor für TicketState erstellen und einfügen: 

TableColumn col = 

jTable.getColumnModel().getColumn(3); 

JComboBox comboBox = new JComboBox(); 

for (TicketState ts : TicketState.values()) 

comboBox.addItem(ts); 

Weder für Renderer 

noch für CellEditor 

sind spez. Klassen 

erforderlich 

stateColumn.setCellEditor(new DefaultCellEditor(comboBox)); 

�� Tool Tips für TicketState setzen: 

DefaultTableCellRenderer renderer = new DefaultTableCellRenderer(); 

renderer.setToolTipText(„Anklicken, um Zustand zu ändern"); 

stateColumn.setCellRenderer(renderer); 



Seite 351

1-aus-n Auswahl: JComboBox in JTable 

� Setter-Abschnitt in der Ableitung vom DefaultTableModel: 

... 

TicketState state = (TicketState)aValue; 

Tabellenzeile.setTicketState(state); 

... 

� Getter-Abschnitt in der Ableitung vom DefaultTableModel: 

... 

obj = Tabellenzeile.getTicketState(); 

... 



Seite 352

JTable: Model und View für n-aus-m Auswahl 

TicketCategory 

anzeigen 

TicketCategory ändern (hier: 

MULTIPLE_INTERVAL_SELECTION) 



Seite 353

CellEditor, Renderer 

� Spezifischen CellEditor 

class MeinListEditor extends AbstractCellEditor 

implements TableCellEditor 

� realisieren: 

Übernahme der Werte ins Model beschreiben 

� Spezifischen Renderer 

class MeinCellRenderer extends JList /* z.B. */ 

implements TableCellRenderer 

� realisieren: 

Aussehen der Componente (Größe, Hervorheben beim Selektieren, 

…) beschreiben 



Seite 354

n-aus-m Auswahl: JList in JTable 

Auch hier wird ein spez. Editor und CellRenderer zugeordnet und in die 

Tabelle reingefügt: 

... 

TableColumn col = 

jTable.getColumnModel().getColumn(5); 

col.setCellEditor(new MeinListEditor()); 

col.setCellRenderer(new MeinCellRenderer()); 

... 



Seite 355

ListEditor (1/2) 

class MeinListEditor extends AbstractCellEditor implements 

TableCellEditor { 

} 

JList mlist; 

public MeinListEditor() { mlist = new JList(); } 

public Object[] getCellEditorValue() { 

int j = 0; 

Object werte[] = mlist.getSelectedValues(); 

for (Integer i : mlist.getSelectedIndices()) 

System.out.println(" (MeinListCellEditor) ausgewählt: 

" + i + " " + werte[j++]); 

return mlist.getSelectedValues(); 



Seite 356

ListEditor (2/2) 

// Zelle wird editiert 

public Component getTableCellEditorComponent 

(JTable table, Object value, boolean isSelected, 

int row, int column) { 

mlist.setListData((Object[]) value); 

return mlist; 

} // getTableCellEditorComponent 

}// MeinListEditor 



Seite 357

CellRenderer (1/2) 

class MeinCellRenderer extends JList implements 

TableCellRenderer { 

public MeinCellRenderer() { super(); } 

public Component getTableCellRendererComponent 

(JTable mtable, Object value, 

boolean isSelected, boolean hasFocus, 

int rowIndex, int vColIndex) { 

// Hervorheben bei Auswahl 

if (isSelected) 

setBackground(mtable.getSelectionBackground()); 

else 

setBackground(Color.white); 



Seite 358

CellRenderer (2/2) 

// Höhe der Liste für die Tabellenzeile berechnen 

int rowHight = 

mtable.getRowHeight()+mtable.getRowMargin()+1; 

String[] mlist = (String[]) value; 

int fold = mlist.length; 

if (mtable.getRowHeight(rowIndex)!= fold*rowHight) 

mtable.setRowHeight(rowIndex, fold * rowHight); 

setListData((String[]) value); 

return this; 

} 

}// MeinCellRenderer 



Seite 359

n-aus-m Auswahl: JList in JTable 

� Getter-Abschnitt in der Ableitung vom DefaultTableModel: 

String[] sArray; 

sArray = new String[TicketCategory.values().length]; 

int i = 0; 

for (TicketCategory tc : TicketCategory.values()) 

sArray[i++] = tc.name(); 

obj = sArray; 

return obj; 

� Setter-Abschnitt in der Ableitung vom DefaultTableModel: 

Object[] selCategroies = (Object[]) aValue; 

for (Object aCategory : selCategroies) 

System.out.println(" " + aCategory); 



Seite 360

Sortieren und Filtern in Tabellen (1/2) 

� Tabellenzeilen können in Java elegant sortiert werden. 

� Ein Instanz der Klasse TableRowSorter sowie deren 

Identifikation als Sortierer der Tabelle sorgt für entsprechende 

Sortierungen 

� TableRowSorter sorter = 

new TableRowSorter(table.getModel()); 

table.setRowSorter(sorter); 

Exkurs 

� TableRowSorter benutzt java.util.Comparator Objekt zum Sortieren 

der Zeilen. Die Klass, die das Interface implementiert, muss die 

Methode compare zum Vergleich von zwei Objekten anbieten. 



Seite 361

Sortieren und Filtern in Tabellen (2/2) 

� Durch das Sortieren oder Filtern wird die Reihenfolge 

der Zeilen verändert! 

Exkurs 

� Die „View-Koordinaten“ müssen auf die „Model“-Koordinaten transformiert 

werden. 

� JTable bietet Methoden an, um von „Model“-Koordinaten auf die „View“- 

Koordinaten zu transformieren: 

� convertColumnIndexToView und convertRowIndexToView und 

� Methoden die von „View“-Koordinaten nach „Model“-Koordinates konvertieren: 

�� convertColumnIndexToModel und convertRowIndexToModel. 

Hinweis: Achten Sie bei der Verwendung eines Sorters/Filters also darauf, dass 

die Tabellenzeilen verschoben sind und auf die tatsächlichen Indices vor 

Änderungen transformiert werden müssen.. 



Seite 362

Beispiele - MVC 

� TurtleGrafik: Objekte verwalten und darstellen 

(interface und abstract class) 

� JComboBox/JList: DefaultListModel verwenden 

� JTextField: extends PlainDocument 

�� JTable: extends AbstractTableModel 

� JTree: DefaultMutableTreeNode und DefaultTreeModel 

verwenden 



Seite 363

JTree 

� für hierarchische Gliederung von Einträgen 

�� Kapitelstruktur in einem Buch 

� Organisationsformen 

(Unternehmen, Institutionen) 

� Produktbeschreibungen 

� Klassenhierarchien 

� contentPane im GUI 

� HTML/XML Dokumente 

weisen diese Struktur auf 

� statisch (fester Inhalt) oder 

dynamisch (änderbar zur Laufzeit) 



Seite 364

JTree 

� Ereignis: valueChanged(TreeSelectionEvent e) 

// aus TreeSelectionListener 

� Zugriff auf selektierten Eintrag: 

e.getPath().getLastPathComponent().toString() // Text 

TreePath 

Object 

� TreePath jTree.getSelectionPath() // TreePath � Object[] 

� � (DefaultMutableTreeNode) // cast von Object 

(jTree.getSelectionPath().getLastPathComponent()) 

� boolean isSelectionEmpty() 

� Siehe Klasse TreePath! 



Seite 365

DefaultMutableTreeNode 

� Standard-Knotentyp von JTree 

� für statische und dynamische JTrees 

� hat 1 übergeordneten Knoten (parent) 

� Ausnahme: Wurzelknoten hat keinen parent 

� hat ein Array von untergeordneten Knoten (childs) 

� werden senkrecht unter ihrem parent dargestellt 

� jedem Knoten kann ein beliebiges Object zugeordnet werden 

(im einfachsten Fall auch ein String) 

� bietet Enumerations (einfache Iteratoren) zum Durchwandern des 

Unterbaums 



Seite 366

DefaultTreeModel 

� notwendig für dynamische JTrees 

�� einfügen, löschen, verschieben von Einträgen 

� informiert JTree über Änderung an seinen Einträgen 

� Einträge auch editierbar 

DefaultMutableTreeNode root = new DefaultMutableTreeNode ("Text"); 

DefaultTreeModel treemodel = new DefaultTreeModel( root ); 

JTree jDynTree = new JTree( treemodel ); 

... 

treemodel.insertNodeInto(newNode, parent, parent.getChildCount()); 

treemodel.removeNodeFromParent(selected); 

... 

void jDynTree_valueChanged(TreeSelectionEvent e) { 

jTextField1.setText(e.getPath().getLastPathComponent().toString()); 

} 



Seite 367

DefaultTreeModel und 

DefaultMutableTreeNode (1/2) 

Einfügen: 

void jButtonInsert_actionPerformed(ActionEvent e) 

{ 

if (jDynTree.isSelectionEmpty()) 

JOptionPane.showMessageDialog 

(this, "Bitte selektieren Sie zuerst einen Knoten!"); 

else 

{ 

DefaultMutableTreeNode newNode = new 

DefaultMutableTreeNode(jTextField1.getText()); 

DefaultMutableTreeNode parent = (DefaultMutableTreeNode) 

(jDynTree.getSelectionPath().getLastPathComponent()); 

// neuen Knoten am Ende der Child-Liste anhängen: 

treeModel.insertNodeInto(newNode, parent,parent.getChildCount()); 

} 

} 



Seite 368

DefaultTreeModel und 

DefaultMutableTreeNode (2/2) 

Löschen: 

void jButtonDelete_actionPerformed(ActionEvent e) 

{ 

if (jDynTree.isSelectionEmpty()) 


(this, "Bitte selektieren Sie zuerst einen Knoten!"); 

else 

{ 

DefaultMutableTreeNode selected = (DefaultMutableTreeNode) 

(jDynTree.getSelectionPath().getLastPathComponent()); 

if (selected==treeModel.getRoot()) 


(this, "Der Wurzelknoten kann nicht gelöscht werden."); 

else 

treeModel.removeNodeFromParent(selected); 

} 

} 



Seite 369

Editierbare Bäume 

DefaultMutableTreeNode dynRoot; 

DefaultTreeModel treeModel; 

JTree jTree1; 

Treeview () 

{ 

dynRoot = new DefaultMutableTreeNode ("Spline"); // Wurzel 

treeModel = new DefaultTreeModel(dynRoot); 

jTree1 = new JTree(treeModel); 

jTree1.setEditable(true); 

TreeIcons tcr; // eigene Klasse 

tcr = new TreeIcons (); 

jTree1.setCellRenderer(tcr); 

} 

... 



Seite 370

TreeIcon reagiert auf Veränderungen 

class TreeIcons implements TreeCellRenderer 

{ 

TreeIcons () 

{} 

public Component getTreeCellRendererComponent 

(JTree tree, Object value, boolean selected, boolean 

expanded, boolean leaf, int row, boolean hasFocus) 

{ 


("getTreeCellRendererComponent " + value.toString()); 

return new JLabel(value.toString()); 

} 

} 

anwendungs- 

spez. 

Verhalten 



Seite 371

Klassenhierarchie zu JMenu 

Flächen 

Knoten 

alle MenuItems 

sind Buttons 

Blätter 



Seite 372

„Konsoledialoge“ 

� Das Programm durchläuft nacheinander verschiedene Zustände. 

Jede Eingabe wird mit der Return-Taste bestätigt oder 

mit der Escape-Taste abgebrochen. 

� Der Programmablauf gleicht einem Frage-Anwort-Spiel, in dem der 

Computer die führende Rolle übernimmt. Der Benutzer kann nur die 

Frage des Computers beantworten oder den Programmablauf ganz 

abbrechen und im Fehlerfall wieder komplett von vorne beginnen. 

� Man kann sich leicht vorstellen, dass diese Vorgehensweise in 

komplexeren Programmen für den Benutzer sehr problematisch wird: 

� der Benutzer reagiert auf die Fragen des Computers; 

� der Benutzer wird eine ablehnende Haltung einnehmen, wenn er das 

Programm nicht als Arbeitserleichterung empfindet! 



Seite 373

Ereignisgesteuerte Programmierung 

� Bei Programmen mit grafisch-interaktiven Benutzungsoberflächen 

kann die Reihenfolge der Eingabe beliebig variiert und Werte auch 

nachträglich geändert werden; 

Neuberechnungen oder Berechnungsvariationen sind einfach 

möglich. 

� Aus der Sicht der Entwicklerin/des Entwicklers bedeutet diese Art 

des Benutzerdialogs zusätzliche Überlegungen. 

� Der Benutzer entscheidet, was er als nächstes tut. 

Die Aufgabe des Programms besteht nun darin, Benutzereingaben 

wahrzunehmen und zu interpretieren. 

Für das Programm sind Benutzereingaben Ereignisse, auf die es in 

geeigneter Weise reagieren muss. 



Seite 374

Ereignisbegriff 

Events := Ereignisse, 

die i. d. R. vom Benutzer direkt oder indirekt ausgelöst werden und 

eine Eingabe darstellen, auf die das Programm auf eine bestimmte 

Art und Weise reagieren muss (Berechnung neu durchführen, 

Darstellung aktualisieren, Fenster verschieben ...) 

� Ereignisse sind weder Klassen, noch Objekte, noch Methoden ! 

� Objekte von Event-Klassen sind Parametersätze, die zur 

Behandlung von Ereignissen als Zusatzinformation übergeben 

werden (nicht zu verwechseln mit den Ereignissen selbst) 

� Ereignisse müssen vom Programm behandelt werden 

� die Behandlung erfolgt durch Ausführung eines "Handlers" 

(= Funktion/Methode) 



Seite 375

Eventhandling 

Beispiele: 

�� Eingabe über Tastatur (� (� KeyEvent) 

� Mausklick (� MouseEvent, MouseMotionEvent) 

� Menueauswahl, Scrollbalken bewegen, Buttons anklicken 

(� ActionEvent) 

� Fenster verschieben, vergrößern, verkleinern, schließen, iconifizieren (� 

WindowEvent) 

� Dateiauswahl (�komplexer, zusammengesetzter Dialog) 

� ... 

�� Der Benutzer erwartet bestimmtes (Standard-)Verhalten! 

� Das Fenstersystem (Windowmanager, Betriebssystem) verteilt die Eingabe dazu 

an die betreffende Anwendung 

� die Anwendung reagiert anwendungsspezifisch (unterschiedlich Anwendungen 

reagieren unterschiedlich z. B. auf einen Mausklick) 



Seite 376

Eventhandling 

Events 

Fenstersystem, 

Windowmanager 

Prüfung der 

Events und 

Verteilung an 

Anwendung 

Reaktion/Behandlung 

von Eventtyp 1 


von Eventtyp i 


von Eventtyp n 

Anwendung 2 

Anwendung 1 

� In diesem Zusammenhang spricht man auch davon, dass der 

Programmablauf benutzergesteuert (user driven) ist. 



Seite 377

Zuordnung von Handlern 

� Ereignisse werden vom Betriebssystem erkannt oder erzeugt und an 

die Anwendung weitergeleitet 

� Maus/Tastatur � Betriebssystem � Anwendung 

� Basisklassen aus Bibliothek � eigene abgeleitete Klassen 

� letztlich sollen Methoden in der Anwendung aufgerufen werden 

� dabei werden i. a. ereignisspezifische Parameter übergeben 

(Mauskoordinaten, Tastencode, ButtonID, ...) 

�� Zuordnung: Systemereignis �� Handler 

� vom Wesen her: Tabelle mit Funktionszeigern 

(siehe Eventliste in der Design-Ansicht von Eclipse) 

� bisher kein Standard; jede Bibliothek macht es anders 



Seite 378

ei Komponenten 

� "normale" Programmierung 

�� Zuordnung Ereignis �� Handler wird zur Compile-Zeit festgelegt 

� erlaubt konstante Arrays von Funktionszeigern oder 

virtuelle Funktionen (basieren ebenfalls auf konstanter vtable) 

� Komponententechnik (Java Beans, ActiveX Controls) 

� Komponente ist visuelles Steuerelement 

� stellt Eigenschaften, Methoden und Ereignisse bereit 

�� kann mit der umgebenden Anwendung kommunizieren 

� liegt als fertig kompilierte jar- vor 

� Zuordnung Ereignis � Handler wird zur Laufzeit festgelegt 

� erfordert dynamische Liste von Funktionszeigern oder Objekten; 

in Java: mit Methode add...Listener(Listenerobjekt) 



Seite 379

Listener 

� benötigt werden eigentlich Zeiger auf Funktionen 

� Dies gibt es nicht in Java (rein objektorientiert)! 

streng OO, 

flexibel und 

unübersichtlich 

� Stattdessen: 

Objekte von Klassen, die eine passende (Handler-) Methode haben 

� Methoden werden spezifiziert als interface "...Listener" 

� beliebige Klassen können dieses Interface implementieren, 

d.h. sich um die (Handler-)Methode ergänzen 

�� Referenzen auf Objekte dieser Klassen werden anstelle von 

Zeigern auf Funktionen übergeben ("als Listener registriert") 

� manche Listener-Interfaces definieren nur eine einzige Methode 



Seite 380

Delegation 

� die Ereignisbehandlung wird abgeordnet/übertragen 

Ereignisquelle 

Benachrichtigung (2) Registrierung (1) 

Eventlistener 

Verweis auf 

Eventlistener 

implements XXXListener 



Seite 381

Delegation 

� Bei dieser Technik registrieren sich Objekte direkt bei der Quelle eines 

bestimmten Ereignisses. Daraufhin werden diese Objekte „automatisch“ über das 

Auftreten dieses Ereignisses informiert. 

� Damit ein Objekt über den Eintritt eines Ereignisses unterrichtet werden kann, 

muss eine Verbindung zwischen der Quelle des Ereignisses und den 

Komponenten , die auf das Ereignis reagieren, geschaffen werden (Registrierung). 

Die Quelle speichert einen Verweis auf die Komponente, die informiert werden 

möchte. 

� Tritt das Ereignis ein, wird die Komponente über den Eintritt unterrichtet 

(Benachrichtigung). Da die Reaktion auf das Ereignis nicht direkt in der 

Komponente stattfindet, in der es eingetreten ist, spricht man von einem 

Delegatiosmodell. 

Bemerkung: 

� Nur ein Objekt, das das zu einem Ereignis zugehörigen Interface implementiert, 

kann über das Delegationsmodell auf ein Ereignis reagieren! 



Seite 382

Ereignisklassen – ein Ausschnitt 

ActionEvent 

EventObject 

AWTEvent 

AdjustmentEvent ComponentEvent ItemEvent 

ContainerEvent FocusEvent InputEvent WindowEvent 

MouseEvent 

... 

KeyEvent 

PaintEvent 

TextEvent 

ListSelectionEvent 



Seite 383

Ereignisklassen (I) 

� ActionEvent: 

Ein ActionEvent definiert die Auslösung eines bestimmten Ereignisses, 

durch das eine andere Aktion angestoßen wird (z.B. Druck eines 

Buttons). 

� Adjustment Event: 

Ein AdjustmentEvent zeigt an, dass in einer Komponente ein 

Einstellvorgang vorgenommen wurde. Das ist der Fall, bei denen ein 

Wert zwischen zwei vorgegebenen Werten eingestellt werden kann (z.B. 

Scrollbar). 



Seite 384

Ereignisklassen (II) 

� ComponentEvent: 

Dieses Event wird ausgelöst, wenn in einer Komponente eine 

Operation ausgeführt wird. Darunter fallen das Verändern der Größe, 

das Anzeigen, Entfernen von Komponenten am Bildschirm und 

Eingabeereignisse (z.B. Maus, Key) 

� ListSelectionEvent: 

Ein ListSelectionEvent wird in Komponenten ausgelöst, bei denen 

aus einer bestimmten Menge ausgewählt werden kann (z.B. JList, 

JTable). 



Seite 385

Aktivitäten und Eventklassen 

Aktivität des Benutzers Swing-Eventklasse 

Klick auf Button, Return in Textfeld, Menüauswahl ActionEvent 

Tabellen- oder Listenauswahl wird geändert ListSelectionEvent 

Benutzer schließt das Hauptfenster WindowEvent 

Benutzer drückt Maustaste über Komponente MouseEvent 

Benutzer bewegt Maus über Komponente MouseEvent 

(MouseMotionListener) 

Komponente wird sichtbar ComponentEvent 

Komponente bekommt den Tastaturfokus FocusEvent 



semantic 

low level 

Seite 386

Eventhandling – beim Ticketsystem 

class TicketJDialog extends JDialog implements ActionListener 

{ 

JLabel zustand = new JLabel (); 

JTextArea ta = new JTextArea(10,10); 

JComboBox cb; 

Ticket t; 

TicketJDialog (JFrame aJFrame, Ticket aTicket, String[] consultant) 

{ 

this.setSize(300, 200); 

this.setTitle("ConsultantAssign"); 

this.getContentPane().setLayout(new GridLayout (1,3)); 

this.t = aTicket; 

cb = new JComboBox (consultant); 

cb.addActionListener(this); 

this.getContentPane().add(cb); 

ta.setText(“Endloschleife"); 

this.getContentPane().add(ta); 

zustand.setText(aTicket.state.toString()); 

this.getContentPane().add(zustand); 

} // Konstruktor 

public void actionPerformed (ActionEvent ae) 

{ 

t.state = TicketState.in_Bearbeitung; 

zustand.setText ("in Bearbeitung"); 

} 

} // TicketDialog 



Seite 387

Beispiel: ActionEvent 

Methoden 

� public String getActionCommand() 

� int getModifiers() // CTRL, ALT, Shift 

� String paramString() 

� public Object getSource()//ererbt von der Klasse EventObject 



Seite 388

Beispiel: ListSelectionEvent 

Methoden 

� int getFirstIndex() 

� int getLastIndex() 

� boolean getValueIsAdjusting() // true, wenn mehrere 

Änderungen gemacht werden, 

d.h. Maus wird über Liste 

gezogen 

� String toString() 

�� public Object getSource()//ererbt von der Klasse EventObject 



Seite 389

Beispiel: MouseEvent 

Methoden 

� int getClickCount() 

� Point getPoint() 

� int getX() 

� int getY() 

� boolean isPopupTrigger() 

� String paramString() 

� void translatePoint (int x, int y) 

� public Object getSource()//ererbt von der Klasse EventObject 



Seite 390

� Anonyme innere Klasse 

� eine ganze Klasse zu schreiben, wenn man eigentlich nur eine 

Methode braucht, wäre ebenfalls unpraktisch 

� Lösung: 

eine anonyme Klasse, von der nur ein einziges, ebenfalls anonymes 

Objekt erzeugt wird 

� ergibt eine zusätzliche Datei Klasse$n.class 

jButton1.addActionListener(new ActionListener() { 


// entsprechende Aktionen ausführen 

} 

}); 

� hat vollen Zugriff auf alle Variablen der umschließenden Klasse 



Seite 391

(Anonyme) innere Klassen 

� Problem: keine Mehrfachvererbung, keine Freunde 

�� MeinFrame abgeleitet von JFrame 

� MeinListener abgeleitet von irgendeinem Adapter (= 

Standardimplementierung eines Interfaces) 

� Listener soll Zugriff auf die Elemente von MeinFrame haben 

� in C++ würde 

• MeinListener von MeinFrame und von Adapter abgeleitet werden 

oder 

• MeinFrame würde MeinListener zum Freund erklären 

� Ausweg: Listener als innere Klasse von MeinFrame 

� Listener oft als anonyme (namenlose) Klassen definiert; 

� sie können dann nur eine einzige Instanz haben 



Seite 392

Aufgabe: Zuordnung einer Methode zum 

Ereignis ActionEvent des Buttons 

Ereignisbehandlung (1/2): anonyme Klasse 

private void jbInit() throws Exception { 

entfällt 

jButton1.setActionCommand("Hallo"); 

jButton1.addActionListener(new 

anonymeKlasse implements 

java.awt.event.ActionListener() { 


jButton1_actionPerformed(e); 

} 

}); 

ActionListener ist ein Interface, das nur die 

} 

Methode actionPerformed definiert 

void jButton1_actionPerformed(ActionEvent e) { 

// Nutzinhalt; hier: Messagebox zeigt "Hallo" 

JOptionPane.showMessageDialog(this, e.getActionCommand()); 

} 



Seite 393

Ereignisbehandlung (2/2): implements Interface 

import java.awt.event.*; 

class jButton1_Listener implements ActionListener 

{ 


jButton1_actionPerformed(e); 

} 

} 

public class MainWindow extends JFrame { 


jButton1_Listener B1L = new jButton1_Listener(); 

jButton1.addActionListener(B1L); 

} 

} 

so ist es, wenn die Listener- 

Klasse nicht anonym ist ... 



Seite 394

Event-Adapter 

Ereignisquelle 

Benachrichtigung (2) Registrierung (1) 

Benachrichtigung (3) 

Verweis auf Adapter 

EventAdapter 

r 

Objekt 

implements XXXListener 

Verweis auf Objekt 



Seite 395

Listener und Adapter 

� manche Listener-Interfaces definieren mehrere Methoden 

� oft braucht man aber nur eine davon 

� alle notgedrungen zum implementieren wäre unpraktisch 

� hilfsweise abstrakte Adapter-Klasse mit lauter leeren Methoden 

public abstract class MouseAdapter implements 

MouseListener { 

public void mouseClicked(MouseEvent e) {} 

public void mousePressed(MouseEvent e) {} 

} 

public void mouseReleased(MouseEvent e) {} 

public void mouseEntered(MouseEvent e) {} 

public void mouseExited(MouseEvent e) {} 



Seite 396

Erweiterte Adapterklasse 

class mymouse extends MouseAdapter 

{ 

mymouse () {} 

public void mouseClicked (MouseEvent e) 

{ 

System.out.println("Maus clickt!"); 

} 

public void mousePressed (MouseEvent e) 

{ 

System.out.println("Maus presst: "+e.getX()+" "+e.getY()); 

} 

} 

public class listenerbeispiel extends JFrame 

... 

mymouse maus = new mymouse(); 

addMouseListener (maus); 

... 



Seite 397

Eventhandling mit Eclipse 

� Die Realisierung im IDE ist einfach: 

� Die Methodennamen und Parameter sind vorgegeben und werden 

durch Anklicken ausgewählt; 

� dann können anwendungsspezfische Aktionen eingefügt werden. 

� Mit setActionCommand() und getActionCommand() 

können Componenten spezifische Informationen übergeben 

werden 



Seite 398

Fenster als Listener seiner Komponente 

import java.awt.event.*; 

public class Fenster extends JFrame 

implements ActionListener 

{ 


jButton1.addActionListener(this); 

} 


if (e.getSource()==jButton1) 

// Handler für jButton1 

else 

// Handler für andere Komponenten 

} 

} 

ein Handler pro 

Ereignis für alle 

Komponenten 



Seite 399

Beschreibung der Componenten mit Ressourcen 

� Konfigurieren statt Codieren 

�� Steigerungen der Produktivität bei entsprechender 

Werkzeugunterstützung 

� Deskriptiver Ansatz - GUI- Elemente werden generiert: 

� zur Beschreibung des Layouts und 

� der Componenten 

wird XML verwendet 

� Bei strikter Einhaltung führt Ansatz führt zu deutlichen Trennung 

zwischen GUI und Applikation: 

� Mehrsprachigkeit 

� Rapid Prototyping 

� Beispiel: GUI-Entwicklung unter Android ( ) 



Seite 400

Beschreibung des User Interfaces mithilfe von 

XML-Ressourcen (am Beispiel von Android) 1/4 

package BMI.calc; 

import android.app.Activity; 

import android.os.Bundle; 

public class calcBMI extends Activity 

{ 

/** Called when the activity is first created. */ 

@Override 

public void onCreate(Bundle savedInstanceState) 

{ 

super.onCreate(savedInstanceState); 

setContentView(R.layout.main); 

}// onCreate 

} 



Seite 401



strings.xml: 

 

 

App zur Berechnung des BMI 

Body Mass Index 

Masse in kg 

70 

Größe in cm 

170 

Ergebnis 

calculate 

#ffff00 

18px 

 



Seite 402



main.xml: 

 

 





Seite 404

Usability - Gebrauchstauglichkeit 

�Usability �Usability Engineering: 

� Benutzer (Sinus-Mileu-Studie) 

� Benutzerzentrierte Analyse und Design 

� Softwareergonomieaspekte 

�Usability Inspection/Usability Test: 

� Evaluationskriterien 

� Voraussetzung und Durchführung 



Seite 405

Usability 

� Es nützt wenig, ein funktional einwandfreies Produkt zu erstellen, 

wenn es von der Mehrheit der potentiellen Nutzer nicht akzeptiert 

wird! 

� Usability ist ein sehr entscheidender Faktor, 

um den wirtschaftlichen Erfolg eines Produktes am Markt zu 

bewerten. 

� Vorgehensweise: 

�� Anforderungen zusammentragen (Requirement Engineering) 

� Benutzerprofile erstellen (Stereotypen, Lebenslagen, Milieus) 

� Modellbildung (Modelle und Metapher) 

� Rapid Prototyping als Vorgehensweise involviert frühzeitig Betroffene 

� Einsatz von Bibliotheken, Frameworks 



Seite 406

Usability-Engineering 

� Usability Engineering bezieht den Benutzer des Programms bei der 

Entwicklung mit ein: 

� Dinge, die für den Entwickler einfach und klar sind, können dem 

Benutzer Schwierigkeiten bereiten und ihm nicht zugänglich sein 

� Relevante Überlegungen können sehr plakativ formuliert werden: 

Quelle: Nielsen, Jakob: Usability Engineering, 1993 



Seite 407

„Your best guess is not good enough“ 

� Was einem zuerst als Problemlösung einfällt, muss nicht immer das 

Beste sein. Man sollte noch einmal genau überlegen, ob der 

Benutzer damit Probleme haben könnte. 



Seite 408

„The user is always right“ 

� Die Benutzungsoberfläche soll so entwickelt werden, dass sie dem 

Benutzer gefällt, die gute Bedienbarkeit muss im Mittelpunkt der 

Überlegungen stehen. 

� Dies gilt insbesondere auch dann, wenn die Umsetzung aufwendiger 

ist oder man es selber gerne anders machen würde. 



Seite 409

„Less is more“ 

� Man darf eine Benutzungsoberfläche nicht mit Funktionen 

überfrachten. 

Viele Programm weisen zwar einen großen Funktionsumfang auf; in 

der Regel führt dies aber zu Unsicherheiten und dazu, das eigentlich 

nur eine relativ kleine Untermenge von den einzelnen Benutzern 

beherrscht wird. 

� Klare, kompakte Oberflächen, die auf die Bedürfnisse der Benutzer 

und ihrer Aufgabenstellungen zugeschnitten sind, sollten angestrebt 

werden. 



Seite 410

„Designers are not users“ 

� Für einen Designer kann es schwer sein, sich in die Lage des 

Benutzers zu versetzen, da er mehr Erfahrung im Umgang mit dem 

Computer hat und er dadurch möglicherweise Probleme aus Sicht 

des Benutzer zu übersehen. 



Seite 411

Kein mentaler Overhead - 

kein "menschliches RAM" 

� „Gestalte die Bedienung so einfach wie möglich“ 

Dialoge sollten für den Benutzer so einfach und „direkt“ wie möglich 

sein und so gut wie möglich die konkrete Aufgabe des Benutzers 

treffen, damit die Belastung des Benutzer zur Realisierung einer 

anwendungsspezifischen Aufgabe durch spezifische Dinge der 

Benutzungsoberfläche so wenig wie möglich überlagert wird (z.B. 

erlernen der Syntax und Semantik einer Kommandosprache). 

� Stichworte hierfür sind 

� direkte Manipulation, Point-and-Click und Drag&Drop 

� Die menschliche Informationsverarbeitung im Kurzzeitgedächtnis ist 

begrenzt; der Anwender sollte bei einem Fensterwechsel keine Werte 

behalten müssen. Faustregel: „Man kann sich an 7 +|- 2 Informationen 

erinnern“ 



Seite 412

„Die Sprache des Benutzers sprechen“ 

� In der Benutzungsoberfläche sollten anwendungsspezifische Begriffe 

und nicht systemspezifischen Begriffe verwendet werden. 

� Einfache und natürliche Dialoge tragen zur einfachen Bedienung bei. 

� Auf den Wiedererkennungswert von vertrauten Icons/Symbolen 

setzen. 

� Die Wiederverwendung von parametrisierten Elementen ist 

wesentlicher Bestandteil von fensterorientierten Systemen (WIMP - 

Window, Icon, Menue, Pointing Device). 



Seite 413

Kunden und Entwickler – Erwartungen und Umsetzungen 



Seite 414

Software-Ergonomie 

Usability-Überlegungen (I) 

� Eine zentrale Aufgabe in der Anwendungsentwicklung ist es, auf die 

speziellen Erwartungen, Anforderungen und Bedürfnisse der 

Anwender und insbesondere der Zielgruppe einzugehen. Dies 

bedeutet, dass das Programm „die Sprache“ des Benutzers sprechen 

sollte. 

� Den Aspekten der einfachen Bedienbarkeit und intuitiven 

Handhabung kommt bei der Planung/Konzeption der Mensch- 

Maschine-Schnittstelle eine wesentliche Rolle zu. 

� Es ist somit nicht verwunderlich, dass sich mit dieser kritischen 

Softwarekomponente nicht nur Softwareentwickler beschäftigen 

sondern auch (Software-)Ergonomen, Psychologen, und Designer. 



Seite 415


Usability-Überlegungen (II) 

�� Eine schlechte und wenig durchdachte Benutzungsoberfläche kann 

einem guten Anwendungsprogramm mehr schaden als eine gute 

Benutzungsoberfläche einer schlechten Anwendung nutzen kann. 

� Neben der korrekten Anwendungssoftware ist die Mensch- 

Maschine-Schnittstelle mit entscheidend dafür, 

� wie gut das Softwareprodukt von den Benutzern akzeptiert und 

somit 

�� wie erfolgreich sich das Produkt am Markt entwickelt. 

� Die Entwicklung der Mensch-Maschine-Komponente in einem 

Programmsystem macht einen signifikanten Anteil des 

Entwicklungsaufwandes aus (i.d.R. mehr als 70%!). 



Seite 416


Usability-Überlegungen (III) 

� Neben (teilweise sehr umfangreichen) firmenspezifischen 

Guidelines/Style Guides, die Richtlinien darstellen, wie bestimmte 

Dialogelemente zu verwenden sind und wo diese Elemente innerhalb 

einer Applikation und applikationsübergreifend zu verwenden sind, 

haben sich auch einige „Grundregeln“ herauskristallisiert, die man 

generell beachten sollte: 



Seite 417


Usability-Überlegungen (IV) 

�� Auf Konsistenz achten: immer wiederkehrende Elemente 

� stehen an der gleichen Stelle (Layout), 

� haben immer das gleiche Aussehen (Design und Farbgebung) und 

die gleiche Bedeutung (Semantik) 

� das (mentale) Modell sollte konsistent sein; Metapher sollten 

durchgängig sein und auch zum Ausdruck gebracht werden 

�� Auf die strenge Trennung von Anwendungsfunktionalität und 

Komponenten der Benutzungsoberfläche achten; 

dies gewinnt mit der Komplexität/Umfang der Entwicklung an 

Bedeutung 



Seite 418


Usability-Überlegungen (V) 

�� Feedback - Rückmeldungen aus der Anwendung 

Der Benutzer muss eine Reaktionen auf seine Aktionen erhalten 

(Mauscursor ändert sich, Button zeigt Zustand an, …) 

� Einfache und deutliche Elemente 

Short Cuts erlauben erfahrenen Benutzer , sich schnell im 

Programm zu bewegen; 

Abbruchmöglichkeiten vermindern die Angst, Fehler zu machen 

Bemerkung: Funktionen an Graphischen Oberflächen sind durchaus 

redundant, d.h. es gibt mehrere Möglichkeiten, eine Aufgabe zu lösen 



Seite 419


Usability-Überlegungen (VI) 

�� Sinnvolle (Fehler-)Meldungen 

Fehlermeldungen müssen einfach und klar zu verstehen sein; 

sie sind für den Anwender und nicht für den Entwickler 

� Fehlervermeidung statt Fehlerbehebung 

Der Benutzer sollte keine ernsthaften Fehler machen können 

�� Die Benutzungsoberfläche führt, entlastet und bietet 

situationsorientierte (kontextsensitive) Hilfe an 



Seite 420

Kaufverhalten bei tech. innovativen Produkten 



Seite 421

An Innovation culture combines 

Dreamers who do 

(„Innovators“) 

Geoffrey Moore: Crossing the Chasm 

Folie aus einem Vortrag von Prof. G. Dueck, Chief Technologist , ibm 

Doers who dream 

(„Sponsors“) 



Seite 422

Crossing the Chasm (1/3) 

� Eine kleine Zahl von interessierten Techies „spielt“ schon sehr früh 

mit der neuen Technologie. 

� Dadurch werden die „Visionäre“ auf die Technologie aufmerksam; 

sie sehen darin kreative, neue Möglichkeiten, sich einen Wettbewerbsvorteil 

zu verschaffen (auch wenn die Technologie noch an 

Kinderkrankheiten leidet). Solche Visionäre sind in der Regel die 

ersten Kunden (First Mover) für den Anbieter der neuen Technologie. 

� Wenn die Technologie dann schon etwas ausgereifter ist - das Risiko 

also nicht mehr so groß erscheint und der Kundennutzen klarer zu 

Tage tritt -, dann interessiert sich auch die große Gruppe der 

„Pragmatiker“ dafür. Sie wollen i. a. einen in Geld messbaren Vorteil 

(schneller, billiger, bequemer, besser, …) mit der neuen Technologie 

erzielen (lazy user model). 



Seite 423


� Wenn die ebenfalls große Gruppe der „Konservativen“ dann im Laufe 

der Zeit sieht, dass viele andere die Technologie mit Erfolg ein-setzen, 

springen auch sie auf den Zug auf, denn jetzt scheint das Risiko 

minimal und der Nutzen bewährt. 

� Die letzte Gruppe, die die neue Technologie dann aufnimmt, sind die 

„Nachzügler“. Siegreifen erst dann zu einer neuen Technologie, wenn 

die alte immer schwieriger erhältlich ist oder nur noch unter hohen 

Kosten aufrechterhalten werden kann. 

�� Geoffrey Moore hat untersucht, warum sich viele – auch Erfolg 

versprechende - technologische Ansätze am Markt nicht bewährt 

haben und wieder untergegangen sind. Er zeigt, dass es fundamentale 

Unterschiede zwischen den ersten Kunden, den „Visionären“ und der 

viel größeren Gruppe der „Early Majority“ des „Mainstreams“ gibt. 



Seite 424


� Diese Unterschiede sind verantwortlich für eine Kluft im „Technology 

Adoption Life Cycle“ (TALC), die Moore „Chasm“ nennt. 

� Es reicht nicht aus, die neue Technologie nur für die Visonäre zu 

vermarkten. Die Argumente müssen sich ändern und auf die 

Nutzergruppen zugeschnitten werden, um diese unsichtbare Kluft zu 

überbrücken. Andernfalls landen sie unweigerlich im „Tal des 

Misserfolgs“. Gerade die Anfangserfolge bei den „Early Adopters“ 

machen eine notwendige radikale Strategieänderung so schwierig, 

denn diese Erfolge scheinen ja der Beweis für die Richtigkeit des 

eingeschlagenen Weges. 

� Es macht daher sehr viel Sinn, die Kundengruppen und deren 

Bedürfnisse sehr genau zu kennen. 



Seite 425

Die Sinus-Milieus® in Deutschland 2007 

� Länderspezifische Segmentation von Gesellschaften auf Grundlage von 

Wertorientierungen und Lebensstilen in 17 Nationen 

� Unterschiede in der Alltagswirklichkeit kennzeichnen den Menschen stärker als 

die Unterschiedlichkeit sozioökonomischer Lebensbedingungen. 

� Seine lebensweltliche Zugehörigkeit wird immer weniger von 

schichtspezifischen und demografischen Merkmalen gesteuert als von seinen 

Vorstellungen vom Leben, seinen alltagsästhetischen Leitbildern und 

Konsumstilen. 

� Von oben nach unten: Nach sozialer Lage in Schichten, auf der Grundlage von 

Bildung, Beruf und Einkommen 

� Von links nach rechts: Nach der Grundorientierung, in einem Spannungsbogen 

von traditionell bis postmodern 

� Oben sind die gesellschaftlichen Leitmilieus angesiedelt, am linken Rand die 

Traditionellen Milieus, in der Mitte die Mainstream Milieus und rechts die 

Hedonistischen Milieus. 



Seite 426

http://www.sinus-sociovision.de/ 



Seite 427

Sinus A12 (Konservative): 5% 

Das alte deutsche Bildungsbürgertum: 

konservative Kulturkritik, humanistisch geprägte Pflichtauffassung und gepflegte Umgangsformen 

Lebenswelt: 

Die Konservativen repräsentieren das alte deutsche Bildungsbürgertum. Sie pflegen die bewährten 

Traditionen, eine humanistisch geprägte Pflichtauffassung und gehobene Umgangsformen. Entsprechend 

leiden sie unter dem "Verfall der Werte und guten Sitten". Sie legen großen Wert auf Abgrenzung durch 

die Betonung ihrer gehobenen Stellung in der Gesellschaft. Heute sind viele im Ruhestand, nach einer 

erfolgreichen, verantwortungsbewussten Berufskarriere. Ihr Engagement richtet sich inzwischen - noch 

mehr als früher - auf ehrenamtliche Tätigkeiten. 

Familie und familiärer Zusammenhalt sind den Konservativen sehr wichtig. Vom Zeitgeist und dessen Folgen 

distanzieren sie sich kritisch. Sie interessieren sich für klassische Kunst und Kultur (Theater, Oper, 

Museen) und verfolgen besorgt das Zeitgeschehen in Politik, Gesellschaft und Wirtschaft. 

Da sie mit allem - zum Teil sehr gut - ausgestattet sind, genießen sie heute vor allem immaterielle Werte und 

kümmern sich um Wohlbefinden und Gesundheit. Wenn sie Anschaffungen vornehmen, dann sind es die 

besonderen Dinge wie wertvolles Porzellan, Echt-Schmuck, Kulturreisen oder ein (teures) Auto. 

Soziale Lage: 

Altersschwerpunkt ab 60 Jahre; meist Zwei-Personen-Haushalte 

Akademische Abschlüsse sind überrepräsentiert, aber auch Volksschulabschlüsse mit qualifizierter 

Berufsausbildung (Frauen) 

Hoher Anteil von Personen im Ruhestand; typische (ehemalige) Berufe: Höhere Angestellte und Beamte sowie 


Selbständige und freie Berufe 


Mittleres bis gehobenes Einkommensniveau, teilweise größere Vermögen 

© Sinus Sociovision 2007 

Seite 428

Sinus A23 (Traditionsverwurzelte): 14% 

Die Sicherheit und Ordnung liebende Kriegsgeneration: 

verwurzelt in der kleinbürgerlichen Welt bzw. in der traditionellen Arbeiterkultur Lebenswelt: 

Die Traditionsverwurzelten sind die sicherheits- und ordnungsliebende Kriegs- und 

Nachkriegsgeneration. Ihre Wurzeln haben sie entweder in der kleinbürgerlichen Welt oder in der 

traditionellen Arbeiterkultur. Sie verstehen sich als die Bewahrer der traditionellen Werte 

Pflichterfüllung, Disziplin, Bescheidenheit und Moral. 

Inzwischen sind die meisten Rentner oder Pensionäre, nach einem Arbeitsleben in der unteren Mitte 

der Gesellschaft (kleine Angestellte und Beamte, Arbeiter, Bauern). 

Sie setzen fort, was sie auch früher gelebt haben: die Pflege von Familien- und Nachbarschaftsbanden, 

die Suche nach Anerkennung im unmittelbaren sozialen Umfeld. Sich selbst in den Mittelpunkt 

stellen, Traditionelles und Bewährtes aufzugeben, kommt für sie nicht in Frage. 

Ihre Interessen kreisen eng um die eigenen vier Wände, die Familie und vor allem inzwischen um die 

eigene Gesundheit. Fernsehen, Basteln, Gartenarbeit, manchmal auch Ausflüge und Kaffeefahrten 

füllen die freie Zeit. Nach einem arbeitsreichen Leben genießen sie es, "sich auszuruhen". 

Die Traditionsverwurzelten sind sehr zurückhaltende Konsumenten. Ein Leben lang haben sie gespart 

und nur "Sinnvolles" und Notwendiges angeschafft. Auch heute halten sie ihr Geld zusammen und 

sind für sich selbst sehr sparsam. Kinder und Enkelkinder unterstützen sie dagegen gerne. 

Soziale Lage: 

Altersschwerpunkt in der Kriegs- und Nachkriegsgeneration (65 Jahre und älter); 

entsprechend hoher Frauenanteil 

Überwiegend Hauptschule mit abgeschlossener Berufsausbildung 

Hoher Anteil von Rentnern und Pensionären; früher: kleine Angestellte und Beamte, Arbeiter, 

Facharbeiter und Bauern 


Meist kleine bis mittlere Einkommen 



Seite 429

Sinus B1 (Etablierte): 10% 

Das selbstbewusste Establishment: 

Erfolgs-Ethik, Machbarkeitsdenken und ausgeprägte Exklusivitätsansprüche 

Lebenswelt: 

Die Etablierten sind die gebildete, gutsituierte und selbstbewusste Elite. Sie haben hohe 

Exklusivitätsansprüche und zeigen entsprechende Kennerschaft. Damit grenzen sie sich bewusst 

von anderen ab ("die feinen Unterschiede"). 

Beruflicher Erfolg ist ihnen wichtig. Dabei verfolgen sie klare Karrierestrategien. Sie übernehmen 

Verantwortung und Führung, und sie sind sicher, ihre hohen Ziele zu erreichen. 

Sie haben eine pragmatische Lebensphilosophie, reagieren mit Flexibilität auf neue Situationen und 

engagieren sich in Vereinigungen, Verbänden und Clubs - nicht zuletzt, um auch soziale Ziele zu 

fördern. 

Kunst, Kultur und individuelle Reisen gehören zum Lebensgenuss der Etablierten. Andererseits 

beschäftigen sie sich auch nachhaltig mit Politik und Wirtschaft. Sie sind sehr aufgeschlossen 

gegenüber technologischem Fortschritt und den beruflichen wie privaten Vorteilen, die er bringt. 

Sie konsumieren edel und haben ein sicheres Gespür für das Besondere. Sie genießen den Luxus, den 

sie sich auf Grund ihrer privilegierten finanziellen Situation leisten können. Alles, was dem eigenen 

Well Being zuträglich ist, hat viel Raum in ihrer Lebensführung. 

Soziale Lage: 

Mittlere Altersgruppen ab 30 Jahre (Schwerpunkt: 40 bis 60 Jahre); meist verheiratet, Drei- und Mehr- 

Personenhaushalte 

Überdurchschnittlich hohes Bildungsniveau 

Viele leitende Angestellte, höhere Beamte sowie Selbständige, Unternehmer und Freiberufler 

Hohe und höchste Einkommensklassen Fachbereich Informatik: 3. Semester Bachelor Studiengang 



Seite 430

Sinus AB2 (DDR-Nostalgische): 5% 

Die resignierten Wende-Verlierer: 

Festhalten an preußischen Tugenden und altsozialistischen Vorstellungen von Gerechtigkeit und 

Solidarität 

Lebenswelt: 

Die DDR-Nostalgischen (sie stellen fast ein Viertel der ostdeutschen Bevölkerung) sehen sich als 

Verlierer der Wende. Das führt zu einer gewissen Verklärung der Vergangenheit und Verbitterung 

gegenüber der Gegenwart. 

Früher waren sie oft Führungskader in Politik, Verwaltung, Wirtschaft, Kultur, heute haben sie einfache 

Berufe oder sind arbeitslos. Diese Situation verstärkt die Verbitterung und den Rückzug aus der 

"westlich" geprägten Welt. 

Sie führen ein - zum Teil demonstrativ - einfaches Leben, konzentriert auf Familie, gleichgesinnte 

Freunde und Vereine. Die Betonung der alten Werte des Sozialismus (Gerechtigkeit, Solidarität) 

paart sich mit Kritik am "Turbo-Kapitalismus''. 

Die Interessen und Freizeitaktivitäten der DDR-Nostalgischen konzentrieren sich auf Heimwerken, 

Renovieren, bescheidenes Modernisieren des Haushaltes, aber auch auf das Engagement in 

Vereinen und lokaler Politik. 

Prestigekonsum lehnen sie demonstrativ als westliche Unart ab. Geld geben sie nur für das 

Notwendigste aus. Dazu gehören Anschaffungen für Haus und Haushalt, die Basisausstattung mit 

technischen Geräten zum Heimwerken, moderne Haushaltsgeräte und Unterhaltungselektronik, 

manchmal auch ein Computer. 

Soziale Lage: 

Schwerpunkt bei den über 45jährigen 

Meist einfache bis mittlere Bildung; aber auch Hochschulabschlüsse sind leicht überrepräsentiert 

Früher häufig Führungskader in Partei, Verwaltung, Wirtschaft und Kultur; heute einfache Angestellte, 

Arbeiter / Facharbeiter oder arbeitslos Fachbereich Informatik: 3. Semester Bachelor Studiengang 

Kleine bis mittlere Einkommen (Doppelverdiener); hoher Anteil an Beziehern Prof. Dr.-Ing. von Altersübergangsgeld 

Hans-Peter Wiedling 

und Rente 


Seite 431

Sinus B2 (Bügerliche Mitte): 15% 

Der statusorientierte moderne Mainstream: 

Streben nach beruflicher und sozialer Etablierung, nach gesicherten und harmonischen 

Verhältnissen 

Lebenswelt: 

Lebensziel der bürgerlichen Mitte ist es, in gut gesicherten, harmonischen Verhältnissen zu leben. 

Cocooning im gepflegten Ambiente, umgeben von gleichgesinnten und gleichsituierten Freunden 

prägt ihren Lebensrahmen. 

Sie zeigen Leistung und Zielstrebigkeit. Beruflicher Erfolg, eine gesicherte Position und die Etablierung 

in der Mitte der Gesellschaft sind ihnen wichtig. Manchmal sind sie geplagt von Abstiegsängsten. 

Sie wollen sich einen angemessenen Wohlstand erarbeiten, sich leisten können, worauf sie Lust haben. 

Dabei bleiben sie aber flexibel und realistisch. 

Ein angenehmes, komfortables Leben, Harmonie im familiären Umfeld und im Freundeskreis 

charakterisieren den Lebensstil der Bürgerlichen Mitte. Dazu gehört Gäste einladen, gemeinsames 

Kochen, Vereinsengagement, sportliche Betätigung in der Gruppe oder im Verein ebenso wie die 

intensive Beschäftigung mit den Kindern. 

Sie konsumieren gerne und mit Genuss, sind convenienceorientiert und haben ein ausgeprägtes 

Selbstbewusstsein als Verbraucher (Smart Shopper). Sie bevorzugen eine Mischung aus 

konventionell und modern, aus gediegen und repräsentativ. Sie investieren viel in die Ausstattung 

ihrer Wohnung / ihres Hauses, lassen dabei aber auch nicht ihr eigenes Outfit zu kurz kommen. 

Soziale Lage: 

Altersschwerpunkt: 30 bis 50 Jahre, oft Mehr-Personen-Haushalte, kinderfreundliches Milieu 

Qualifizierte mittlere Bildungsabschlüsse 

Einfache / mittlere Angestellte und Beamte; Facharbeiter 


Mittlere Einkommensklassen 



Seite 432

Sinus B3 (Konsum-Materialisten): 12% 

Die stark materialistisch geprägte Unterschicht: 

Anschluss halten an die Konsum-Standards der breiten Mitte als Kompensationsversuch sozialer 

Benachteiligungen 

Lebenswelt: 

Gerade wegen seiner sehr beschränkten finanziellen Mittel zeigt dieses Milieu einen ausgeprägten 

Konsum-Materialismus. Viele Milieuangehörige konzentrieren sich ganz auf das Hier und Jetzt, auf 

spontanen und prestigeträchtigen Konsum, um zu beweisen, dass sie mithalten können. 

Sie möchten als "normale Durchschnittsbürger" gelten, haben aber häufig das Gefühl, in der 

Gesellschaft benachteiligt zu sein. Ihre Wünsche von einem komfortablen Leben und ihre Träume 

vom plötzlichen Reichtum stehen oft im krassen Kontrast zur Realität. 

Ihre beruflichen Chancen sind häufig eingeschränkt durch mangelnde Ausbildung und ungünstige 

persönliche Rahmenbedingungen. Der Anteil der Arbeitslosen ist hoch. 

In ihrer Freizeit möchten sie Unterhaltung, Ablenkung, Action und Spaß. Ausgehen (Kneipen, 

Fußballveranstaltungen, Einkaufsbummel) ist ebenso beliebt wie zu Hause fernsehen, Videos 

ansehen, Videospiele, Musik und Radio hören. 

Wichtige Konsumziele sind für sie die Ausstattung mit moderner Unterhaltungselektronik 

(Stereoanlage, DVD-Player, Fernsehgerät, Handy), ein "repräsentatives" Auto, Urlaub (Kurzreisen, 

Besuch von Freizeitparks) und alles, was die eigene Erscheinung ins "rechte Licht" setzt 

(dekorative Kosmetik, Modeschmuck, Duftwässer). 

Soziale Lage: 

Breite Altersstreuung bis 60 Jahre 

Meist Volks-/ Hauptschulabschluss mit oder ohne Berufsausbildung 

Überdurchschnittlich viele Arbeiter / Facharbeiter Fachbereich Informatik: 3. Semester Bachelor Studiengang 

Untere Einkommensklassen 


Häufig soziale Benachteiligungen (Arbeitslosigkeit, Krankheit unvollständige Familien) 


Seite 433

Sinus B12 (Postmaterielle): 10% 

Das aufgeklärte Nach-68er-Milieu: 

Liberale Grundhaltung, postmaterielle Werte und intellektuelle Interessen 

Lebenswelt: 

Die Postmateriellen sind überwiegend hochgebildet, kosmopolitisch und tolerant. Gewöhnt, in globalen 

Zusammenhängen zu denken, setzen sie sich kritisch mit den Auswirkungen von 

Übertechnisierung und Globalisierung auseinander. Höchster Wert ist die Lebensqualität des 

einzelnen. 

Sie haben großes Vertrauen in ihre eigenen Fähigkeiten und gehen souverän mit beruflichen 

Herausforderungen um. Sie wollen Erfolg im Beruf - aber nicht um jeden Preis. 

Ihre postmateriellen Ansprüche richten sich auf die Entfaltung ihrer individuellen Bedürfnisse und 

Neigungen, auf das Schaffen von Freiräumen für sich und auf mehr Zeitsouveränität. 

In hohem Maße sind sie interessiert an Literatur, Kunst und Kultur. Weiterbildung ist ein 

lebenslängliches Thema, weil sie sich mehr über Intellekt und Kreativität definieren als über Besitz 

und Konsum. 

Ihr Lebensstil ist umwelt- und gesundheitsbewusst (Balance zwischen Körper, Geist und Seele). Sie 

schätzen subtile Genüsse, die durchaus einen hohen Preis haben dürfen. Überflüssigen Konsum 

lehnen sie aber ab. Nach dem Motto "weniger ist mehr" kaufen sie selektiv und mit hoher 

Kennerschaft. 

Soziale Lage: 

Breites Altersspektrum - von Anfang 20 bis zur Generation der "jungen Alten"; häufig größere 

Haushalte mit Kindern 

Hohe bis höchste Formalbildung (Abitur, Studium) 

Qualifizierte und leitende Angestellte und Beamte, Fachbereich Freiberufler, Informatik: Studenten 3. Semester Bachelor Studiengang 

Hohes Einkommensniveau 



Seite 434

Sinus C12 (Moderne Performer): 10% 

Die junge, unkonventionelle Leistungselite: 

intensives Leben - beruflich und privat, Multi-Optionalität, Flexibilität und Multimedia-Begeisterung 

Lebenswelt: 

Die Modernen Performer sind die junge, unkonventionelle Leistungselite. Sie wollen ein intensives 

Leben, in dem sie ihre Multioptionalität und Flexibilität ausleben und ihre beruflichen wie 

sportlichen Leistungsgrenzen erfahren können. 

Ihr ausgeprägter Ehrgeiz richtet sich auf "das eigene Ding", oft die eigene Selbständigkeit (Start-ups). 

Dabei haben sie nicht nur den materiellen Erfolg im Auge. Treibendes Motiv ist ebenso, zu 

experimentieren, spontan Chancen zu nutzen, wenn sie sich auftun und die eigenen Fähigkeiten zu 

erproben. 

Die Modernen Performer sind mit Multimedia groß geworden. Die modernen 

Kommunikationstechnologien nutzen sie intensiv und lustvoll, im beruflichen wie im privaten 

Leben. 

Neben der Multimedia-Begeisterung zeigen sie großes Interesse an sportlicher Betätigung und 

Outdoor-Aktivitäten (Kino, Kneipe, Kunst). 

Ihr Konsumstil ist geprägt durch Lust auf das Besondere, das Integrieren von Einflüssen aus anderen 

Kulturen und Szenen. Anspruchvolles "Multikulti" ist die Devise. Dafür geben sie auch viel Geld 

aus. 

Soziale Lage: 

Jüngstes Milieu in Deutschland, Altersschwerpunkt unter 30 Jahre 

Hohes Bildungsniveau; (noch) viele Schüler und Studenten, zum Teil aber mit Jobs 

Unter den Berufstätigen hoher Anteil (kleinerer) Selbständiger 

und Freiberufler (Start-ups), sowie qualifizierte Fachbereich und leitende Informatik: Angestellte 3. Semester Bachelor Studiengang 

Hohes Haushaltsnettoeinkommen (gutsituierte Elternhäuser); bei den Berufstätigen Prof. Dr.-Ing. gehobenes Hans-Peter Wiedling 

eigenes Einkommen 


Seite 435

Sinus C2 (Experimentalisten): 8% 

Die individualistische neue Bohème: 

Ungehinderte Spontaneität, Leben in Widersprüchen, Selbstverständnis als Lifestyle-Avantgarde 

Lebenswelt: 

Die Experimentalisten haben große Lust am Leben und Experimentieren. Sie sind tolerant und offen 

gegenüber unter-schiedlichsten Lebensstilen, Szenen und Kulturen. Gleichzeitig lehnen sie Zwänge, 

Routinen und Rollenvorgaben ab. Vielmehr leben sie lustvoll unterschiedliche Rollen und auch 

Widersprüche aus (Lifestyle-Avantgarde, neue Bohème). 

Weniger wichtig sind ihnen materieller Erfolg, Status und Karriere. Ihre Ablehnung, sich "lebenslänglich" 

festzulegen, führt oft zu ungewöhnlichen Patchwork-Biografien und -Karrieren. 

Die Experimentalisten sind mit Multimedia groß geworden und nutzen intensiv Online-Angebote, Videound 

Computerspiele. Sie engagieren sich aber auch für gesellschaftliche Randgruppen, betreiben 

Esoterik, machen mentales Training und gehen kreativen Tätigkeiten nach. Ihr Hauptinteresse richtet 

sich auf Musik, Kunst, Kultur, auf einschlägige Filme und Bücher. Sie haben ein großes Bedürfnis nach 

Kommunikation und Unterhaltung, sind ständig in Bewegung und dort zu finden, wo etwas 

Spannendes, Neues los ist. 

Die Experimentalisten geben ihr Geld gerne für Ungewöhnliches, für Dinge abseits des Mainstreams aus. 

Spontan kaufen sie, was ihnen ins Auge fällt oder in die Nase sticht. Zudem reizen sie moderne 

Unterhaltungselektronik und vielfältige Outdoor-Aktivitäten (Raves, Techno-Events, Rock- und Pop- 

Konzerte, Disco, Szene-Lokale, Extremsportarten). 

Soziale Lage: 

Junges Milieu, Altersschwerpunkt unter 30 Jahre; viele Singles 

Gehobene Bildungsabschlüsse; viele Auszubildende, Schüler und Studenten 

(Mittlere) Angestellte, (kleinere) Selbständige und Fachbereich Freiberufler; Informatik: auch Arbeiter 3. Semester (Jobber) Bachelor Studiengang 

Vergleichsweise hoher Anteil von Personen ohne eigenes Einkommen Prof. Dr.-Ing. Hans-Peter Wiedling 

Haushaltsnettoeinkommen im Durchschnitt (gutsituierte Elternhäuser) 


Seite 436

Sinus BC3 (Hedonisten): 11% 

Die spaßorientierte moderne Unterschicht /untere Mittelschicht: 

Verweigerung von Konventionen und Verhaltenserwartungen der Leistungsgesellschaft 

Lebenswelt: 

Die Hedonisten sind die spaßorientierte untere Mittel- bis Unterschicht, immer auf der Suche nach Fun 

und Action, Unterhaltung und Bewegung (on the road). Nur nicht sein wie "die Spießer". 

Gleichzeitig haben sie oft Träume von einem geordneten Leben mit Familie, geregeltem 

Einkommen und schönem Auto / Motorrad. 

Bezogen auf den Beruf führen viele eine Art Doppel-Leben, angepasst an den Berufsalltag, im 

Gegensatz zum hedonistischen Lebensstil in der Freizeit. Trotz und auf Grund dieser partiellen 

Anpassung haben sie häufig aggressive Underdog-Gefühle gegenüber ihrer (Arbeits-) Umwelt. 

Die Hedonisten leben ganz im Hier und Jetzt, möchten sich wenig Gedanken um die Zukunft machen. 

Dabei zeigen sie Spaß an der Provokation der "Spießer" und der Identifikation mit "krassen" 

Szenen, Clubs und Fangemeinden. 

In besonderem Maße interessieren sie sich für Fernsehen, Video, Musik, Computerspiele, Sport 

(Fußball, Squash), Kino-, Disco- und Kneipenbesuche. 

Sie konsumieren gern und viel - soweit das ihr limitiertes Budget zulässt. Gemäß ihrem ausgeprägten 

Unterhaltungsbedürfnis interessieren sie sich für Produkte wie Stereo- und HiFi-Anlagen, 

Multimedia-Ausstattung, Videos, CDs, aber auch für "Klamotten", Modeschmuck, Uhren, Kosmetik, 

Duftwässer, Sportausstattung und -bekleidung, und natürlich Autos und Motorräder. 

Soziale Lage: 

Jüngere und mittlere Altersgruppen bis 50 Jahre; Schwerpunkt unter 30 Jahre 

Einfache bis mittlere Formalbildung - relativ oft ohne abgeschlossene Berufsausbildung 

Einfache Angestellte und Arbeiter; viele Schüler Fachbereich und Auszubildende Informatik: 3. Semester Bachelor Studiengang 

Vergleichsweise großer Anteil von Personen ohne eigenes Einkommen; Prof. keine Dr.-Ing. erkennbaren Hans-Peter Wiedling 

Schwerpunkte beim Haushaltseinkommen 


Seite 437

Analysephase 

� Benutzer in Bezug auf ihren Umgang mit dem System (z.B., durch 

Beobachtung und/oder Interviews) erfassen und beschreiben. 

� Für jeden Gruppe von Benutzern ein Profil erstellen, welches 

unterschiedliche Aspekte (Verhalten, demographischer Hintergrund). 

berücksichtigt. 

� Ziele und Einstellungen der Benutzer erarbeiten. 

� Arbeitsabläufe und Arbeitskontext freilegen und beschreiben. 

�� Typische Benutzerszenarien herausarbeiten. 

� Welche Software wird eingesetzt? Wie wird die Software eingesetzt? 

Wofür wird die Software eingesetzt? 



Seite 438

Usability Engineering Lifecycle 

1. Benutzer und seine Bedürfnisse verstehen lernen 

2. Gebrauchstauglichkeit vergleichen und bewerten 

3. Ziele für das Design festlegen 

4. Iteratives Designprozess: 

(a) Prototyping 

(b) Usability Evaluation (Inspektion und/oder Tests) 

5. Nachfolgende Schritte (Verbesserungen, Erweiterungen) 



Seite 439

Einen Eindruck von den Benutzern verschaffen 

� Bedürfnisse, Wünsche, Ziele, Aufgaben, 

Hintergründe/Rahmenbedingungen 

� erfassen und 

� visualisieren 

� Einsetzbare Techniken: 

� Persona beschreiben 

�� Moodboard einsetzen 



Seite 440

Persona – Rollen/Stereotypen 

� Mit der Beschreibung potentieller Benutzer und ihren Eigenschaften kann 

man ein lebendiges Bild von den Zielgruppen machen. Es entsteht ein 

Verständnis und ein erster Zugang zur Entwicklung realistischer 

Nutzungsszenarien (Tipp: http://www.usability.gov/). 

� Diese können dann für die Entwicklung und Prüfung von Produktentwicklungen 

genutzt werden Eine Form der Benutzerbeschreibung ist die 

Aufbereitung als "Persona". Dabei wird eine Art Steckbrief verfasst, der 

neben Alter, Geschlecht, Ausbildung, Vorlieben, Hobbys, Charaktereigenschaften 

sogar einen Namen oder "Nickname" eines repräsentativen 

Zielgruppenvertreters beinhaltet 

Rollen helfen, 

� sich repräsentative Bilder von den Benutzergruppen zu machen, 

� die Produktqualität zu verbessern und 

� Entwicklungszeiten zu verkürzen 



Seite 441

Rollen, Stereotypen 

� „Benutzer“ sind unspezifisch - sie müssen für alles und jedes 

herhalten! 

� Designs für den „Durchschnittsbenutzer“ führen zu Ergebnissen, 

welche niemanden wirklich beeindrucken. 

� Verweisen Sie nicht auf den „User“, 

verweisen Sie auf spezifische Rollen; 

sie sind die Prototypen für tatsächliche Nutzer. 

� Unterscheiden Sie unterschiedliche Benutzer(-gruppen) und 

designen Sie für diese! 

� Persona erzeugen Betroffenheit und geben den Personen ein Gesicht 



Seite 442

Typische Rollen/Stereotypen 

� Ein geeigneter Stereotyp ist 

�� nicht durchschnittlich, aber typisch und glaubwürdig, und 

� ein Eindruck eines Stereotyps ergibt sich etwa aufgrund einer Befragung 

(Interviews); 

Stereotypen können markante Charakteristiken ausdrücken; 

andere, die nicht so scharf abgegrenzt werden, können die Anwendung 

dann ebenso nutzen. 

� Legen Sie die Stereotypen möglichst exakt fest: 

� Vergeben Sie Name und Alter; 

� Beschreiben Sie typisches Verhalten 

(gerade auch im Zusammenhang mit der zu entwickelnden Applikation); 

� Geben Sie der beschriebenen Person ein Gesicht (verwenden Sie ein 

Bild); 

� Definieren Sie Ziele für jede Rolle; 

� Definieren Sie Szenarien für jede Rolle. 

� Diese sollten gerade den dann folgenden Umsetzungen stand halten. 



Seite 443

Beispiel Persona - Buchhandlung 

� Beschreibung typischer Benutzer für unterschiedliche Benutzergruppen 

Name: Udo Fischer 

Alter: 49 Jahre, Single 

Kategorie: 

Liest gelegentlich im Urlaub; ist an Reiseberichten 

interessiert; kocht gerne. 

Name: Konrad Naumann 

Alter: 72 Jahre 

Kategorie: Vielleser, 2 Enkelkinder 

Liest viel und regelmäßig ist an einem breiten Angebot an 

Romanen und Biographien interessiert. Verschenkt auch gerne 

ein Buch an seine beiden Enkelkinder Jasmin und Kai. 



Seite 444

Moodboard – thematische Stimmungsbilder 

� Gespaltene Gesellschaft (http://www.sinus-sociovision.de/) 



Seite 445

Moodboard – thematische Stimmungsbilder 

� Moodboards sind meist Collagen aus Bildern unterschiedlicher Art, 

Schlüsselwörtern und Farbstimmungen. 

� Sie bieten gestalterische Orientierung, und sie sind hilfreich bei der 

Visualisierung von Produktwelten oder Zielgruppenassoziationen. 

Bildcollagen, Farbharmonien und Schlüsselworten stellen 

atmosphärische Eindrücke her, die eine bestimmte Zielgruppe, ein 

zu gestaltendes Produkt bzw. das Umfeld, für dass das Produkt oder 

eine Dienstleistung gestaltet werden soll, charakterisieren. 

�� Ziel ist die Visualisierung einer Grundstimmung, in die die 

Applikation oder der Service passen soll. Häufig können Farbklimata 

direkt aus dem Moodboard generiert werden. 



Seite 446

Ergonomische Normen 

� haben immer nur Richtliniencharakter 

� ergonomischer und technischer Gestaltungsspielraum 

� keine Normung eines Softwareproduktes 

� es gibt nicht "den" Benutzer; 

Benutzergruppen müssen individuell charakterisiert werden 

Standards 

vs. 

Innovation 

� Rahmenbedingungen (z.B. Arbeitsorganisation, Arbeitsumgebung) sind 

unterschiedlich 

� sollen keine bestimmte Implementierung nahe legen 

notwendig, 

aber nicht 

hinreichend 

� enthalten meist nur Mindestanforderungen 

� spiegeln lediglich den gegenwärtigen (bzw. damaligen) Stand des 

Wissens wider – noch sehr lückenhaft 



Seite 447

Normen zur (Software-)Ergonomie 

� DIN EN ISO 9241: Ergonomische Anforderungen für Bürotätigkeiten 

mit Bildschirmgeräten 

� Hardware und Arbeitsplatzgestaltung 

- 1: Allgemeine Einführung 

- 4: Anforderungen an die Tastatur 

- 5: Anforderungen an Arbeitsplatzgestaltung und Körperhaltung 

- 6: Leitsätze für die Arbeitsumgebung 

http://www.din.de 

- 7: Anforderungen an visuelle Anzeigen bezüglich Reflexionen 

- 8: Anforderungen an Farbdarstellungen 

- 9: Anforderungen an Eingabemittel, ausgenommen Tastaturen 



Seite 448

Normen zur Software-Ergonomie 

� Fortsetzung DIN EN ISO 9241 

� Aussagen zur Softwareergonomie 

- 10: Grundsätze der Dialoggestaltung 

- 11: Richtlinien zur Gebrauchstauglichkeit 

- 12: Informationsdarstellung 

- 13: Benutzerführung 

- 14: Dialogführung über Menüs 

- 15: Dialogführung über Kommandosprachen 

- 16: Dialogführung über direkte Manipulation 

- 17: Dialogführung über Bildschirmformulare 

� DIN EN ISO 13407 

Benutzer-orientierte Gestaltung interaktiver Systeme 

enthalten die 

folgenden 

7 Prinzipien 



Seite 449

Entwurfs- und Gestaltungsprinzipien 

� Aufgabenangemessenheit 

�� Selbstbeschreibungsfähigkeit 

� Steuerbarkeit 

� Erwartungskonformität 

� Fehlertoleranz 

� Individualisierbarkeit 

� Erlernbarkeit 



Seite 450

Aufgabenangemessenheit (I) 

� Direktheit: kurze Wege zur Information / Funktion 

�� mehrere Dialogebenen �� Karteireiter �� Assistenten 

� geschachtelte Pulldown-Menüs 

� Anzahl Mausklicks, Weglänge zur Position, 

(häufige) Wechsel zwischen Tastatur und Maus 

� flexible + schnelle Navigation: Querverweise (Orientierung?!) 

� Gewichtung: häufiges einfach, seltenes aufwändiger 

�� Nachrangiges erst auf zusätzlichen Knopfdruck 

� keine unnötigen Informationen anzeigen 

� Einfachheit statt Featuritis 

� nicht Benötigtes muss der Benutzer gedanklich herausfiltern 

� KEIN menschliches RAM 



Seite 451

Aufgabenangemessenheit (II) 

� Effizienz, Antwortzeiten, sinnvolle Vorgabewerte 

� am schnellsten ist eine vermiedene Eingabe 

� Unterstützung für wiederkehrende Aufgaben 

� Formatierung übertragen, Makro(-recorder), Tastatursteuerung 

� Unterstützung gängiger Arbeitsabläufe 

� Bedienfolgen, Assistenten (Wizards) 

� Workflow 



Seite 452

Selbstbeschreibungsfähigkeit (I) 

Systemzustand muss auf einen Blick erkennbar sein 

� Wo bin ich ? Ort 

� momentaner Aufenthaltsort im System 

� Was kann ich hier tun ? Modus 

� zur Verfügung stehende Operationen 

� Wie kam ich hierher ? Weg 

� Vorgeschichte, Kontext 

� Wohin kann ich gehen ? Weg 

� Ziel eines Buttons (Verweises) soll erkennbar sein 

nicht zu 

verwechseln mit 

Dokumentation 



Seite 453

Selbstbeschreibungsfähigkeit (II) 

� aktuellen Zustand und Kontext darstellen 

� Kontextinformationen (z.B. Verzeichnispfad bei Datei öffnen) 

� Statusbar/Statusanzeige 

� aktuelle Möglichkeiten zeigen 

� Bedienelemente inaktiv machen: besserer Überblick 

� Bedienelemente verbergen: aufgeräumteres Design 

� visuell direkt erkennbare sensitive Bereiche 

�� nicht erst durch "Scannen" (Webseiten ��, ��, Adventure Games ☺) 

� Reaktion / Rückkopplung / Feedback 

� Tasten(Buttons) lassen sich "drücken" 

� bereichs-/objektabhängig veränderlicher Mauscursor 



Seite 454

Selbstbeschreibungsfähigkeit (III) 

� keine versteckten Funktionen / Tastaturkürzel 

� alle Tastaturkürzel in Menüs aufführen; 

eine Seite in der Dokumentation genügt nicht 

� Icons mit Tooltips beschriften 

� Information über länger dauernde Abläufe 

� Sanduhr, Fortschrittsanzeige, Zwischenergebnisse 

� Ablauf abbrechbar (und umkehrbar) 

� Anwender- und problemkompatible Terminologie 

� Begriffe, Befehle, Fehlermeldungen 

� Begriffe aus Anwendungsdomäne aufgreifen und verwenden 

(wie reden künftige Benutzer über ihre Arbeit ?) 



Seite 455

Steuerbarkeit 

� kein "Eigenleben" des Systems 

Benutzer agiert, System reagiert 

� beenden ohne "wollen Sie wirklich ?" 

� freie Eingabereihenfolge 

� auch bei Validierung von Eingabewerten 

(Validierung auf Fensterebene, nicht auf Elementebene) 

� mehrstufige Rückgängig- (Undo-) Funktion 

� dafür muss man etwas tun! 

�� Dialogfolgen und längere Abläufe jederzeit abbrechbar und 

umkehrbar 

� dem Arbeitstempo angepasste Steuerungsformen 

� Menü � Toolbar � Tastatur 



Seite 456

Erwartungskonformität (I) 

� im Widerspruch zu Originalität und Innovation ?! 

� es kann auch schlechter werden ... 

� plattformspezifisches Standardverhalten (Look&Feel) 

� definiert in Style Guides 

� gewohnt, aber leider nicht immer optimal 

� besonders kritisch, weil unterbewusst: Tastatur + Klickverhalten 

� Erwartungen aus der Anwendungsdomäne erfassen 

�� nicht immer "logisch", historisch gewachsen 

� oft unbewusst (Interview und Fragebogen hilft nicht) 

� Beispiel: Gehwegplanung via Trampelpfad auf Gras 



Seite 457

Erwartungskonformität (II) 

� Wiedererkennbarkeit und Konsistenz 

� Einsatz von Steuerelementen für typische Aufgaben 

• Checkbox für einzelnen Boolean (schließt kein Fenster!) 

• Radiobuttons als Gruppe gegenseitig auslösend 

� Standarddialoge verwenden 

• Datei öffnen/speichern, Farbauswahl, 

Schriftauswahl, Seite einrichten, Drucken 

�� Mauszeiger 

� schlechte Beispiele 

� Strg+Alt+Del zum Anmelden 

� Start � Beenden 



Seite 458

Fehlertoleranz 

Entwickler konzentrieren sich lieber 

auf die "eigentliche" Funktion 

� "Urängste" etwas (am Computer) verkehrt zu machen 

� vertrauensbildende Maßnahmen erforderlich � Gefühl 

� Einarbeitung durch Entdeckungsreise ermöglichen 

� Vorbeugung: Bedienelemente deaktivieren 

� Rückfrage/Warnung bei "gefährlicher" Aktion 

� Vorsicht: viele lesen nicht, sondern nehmen unbesehen Default 

� Möglichkeiten zur Fehlerbehebung vorsehen 

�� Rückgängig/Undo, Abbrechen, Papierkorb 

Zustandsanzeige 



Seite 459

Individualisierbarkeit 

� Anpassung an 

� persönliche Benutzungshäufigkeit 

� Gewohnheiten aus anderen Anwendungen 

� persönliches Systemumfeld 

� konfigurierbare Toolbars und Menüs 

kein Ersatz für 

sorgfältig abgestimmte 

Grundeinstellung ! 

� eigene Teilmenge definieren; eigene Funktionen als Makros 

� Favoriten, Last Used, Most Used 

�� Zeitabhängigkeiten 

Anpassung 

macht 

Arbeit 

konfigurierbare Fokussteuerung 

� Erscheinen von Tooltips, Doppelklick, Repeat-Funktion 

� individuelle Einstellungen sichern und "mitnehmen" 

� auf anderen Rechner oder bei SW-Upgrade 



Seite 460

Erlernbarkeit 

� damit Einsteiger zu Fortgeschrittenen und Profis werden 

� ausführliche Hinweisdialoge für Einsteiger 

� mit Checkbox "Dialog künftig nicht mehr anzeigen" 

� Tooltips für Icons und Buttons 

� viele Bilder und Begriffe müssen erst gelernt werden 

� Statuszeilentexte für Eingabefelder 

�� Tooltip würde Eingabefeld verdecken 

� kontextabhängige Hilfe für ausführlichere Erklärungen 

� Guided Tour vermittelt Arbeitsabläufe 

� kann man das Problem visualisieren? 

Bei (nicht vor) 

der Arbeit 

lernen 



Seite 461

Benutzerzentriertes Design - Kriterien 

� Lernaufwand: 

Wie lange benötigt ein typischer Benutzer, um die Durchführung 

einer definierten Aufgabe zu lernen? 

� Arbeitsgeschwindigkeit: 

Wie schnell lassen sich typische Aufgaben von typischen 

Benutzern ausführen 

� Fehlerrate: 

Wie viele und welche Fehler treten bei der Durchführung der Aufgabe auf? 

�� Erinnerungsvermögen: 

Was und wie viel behalten Benutzer in ihrer Erinnerung bezüglich 

Aufgaben über einen definierten Zeitraum hinweg? 

� Joy-of-Use/(subjektive) Zufriedenheit: 

Wie empfindet der Benutzer persönlich die Arbeit mit einem System? 



Seite 462

Usability Inspection - Ziele 

� Usability Inspection wird durch geführt, um gezielt Probleme auf zu 

spühren, 

� die gravierend die Handhabbarkeit behindern oder 

� leicht beseitigt werden können. 

� Dabei werden die folgenden Fragen beantwortet: 

� Welche Bedienhandlungen erfordern einen hohen Lernaufwand (was 

erschwert das Lernen)? 

� Welche Fehler entstehen leicht? 

�� Welche Fehler haben gravierende Folgen? 

� Welche Bedienelemente sind ungünstig gestaltet 

(unübliche Beschriftung, oder grafische Darstellung, mangelhafte 

Strukturierung von Dialogen)? 

� Welche Systemnachrichten sind unangemessen formuliert oder nicht 

aussagekräftig? 



Seite 463

Usability Test - Voraussetzung 

� Festlegung des Testgegenstandes (hier unser Prototyp) 

� Tester, die den Test vorbereiten, durchführen und auswerten; 

es ist besser, dabei nicht (nur) auf Entwickler zu setzen! 

� Testpersonen 

Festlegung der teilnehmenden Personen (wie viele und welche) und 

Erstellung eines Zeitplanes 

� Testumgebung 

Die Tests dürfen soweit möglich nicht gestört werden und 

müssen wiederholt werden können (� Usability Lab) 

�� Testkritierien (Definition von Schwerpunkten): 

Insbesondere bei komplexen Systemen wird selten versucht, alle 

denkbaren Aktionen zu überprüfen. 

Typisch ist, dass die Inspektion anhand von Szenarien erfolgt. 

Es müssen messbare und vergleichbare Daten entstehen! 



Seite 464

Durchführung 1/4 

Effizienz der Interaktion: 

� Wie lange dauert die Durchführung einer Aufgabe? 

� Wie viele Aufgaben können in einer vorgegeben Zeit durchgeführt 

werden? 

� Welche Antwortzeiten brauchen die Testpersonen? 

� Welche Aktionen treten besonders häufig auf? 

� Wie häufig treten sehr ineffiziente Interaktionen auf? 



Seite 465


Auftreten von Fehlern: 

� Wie viele Aktionen waren erfolgreich/fehlerhaft? 

� Welche Fehler treten besonders häufig auf? 

� Weil lange dauert die Behebung von Fehlern? 

� Wie viele positive/negative Kommentare werden geäußert? 

� Wie groß ist der Anteil der Benutzer, der eine Aufgabe (richtig/schnell 

genug/auf optimalem Weg) durchgeführt hat? 

�� Wie viele Kommandos (von allen möglichen) wurden genutzt? 

� Wie oft und wie lange wurden Anleitungen oder andere Hilfsmittel 

studiert? 



Seite 466


Erlernbarkeit: 

� Wie lange braucht ein Anwender, 

um die Durchführung einer Aufgabe zu lernen? 

� Wie ist die Vergessenkurve für die Anwendung nach einer 

bestimmten Zeit (Tagen, Wochen, Monaten)? 

Subjektive Zufriedenheit sollte zudem erfragt und dokumentiert werden 



Seite 467


Bemerkungen: 

Messgrößen: 

� Strecke: Welche Strecke wird mit der Maus zurückgelegt wird? 

� Zeit: Wie lange dauert es, um eine Aufgabe zu lösen 

� Anzahl: Wie viele Klicks werden benötigt, um eine Aufgabe zu lösen? 

Auch kleine und mittelgroße Projekte können erheblich von 

Evaluationstests profitieren! 



Seite 468

Usability Test im Rahmen des Praktikums 

� Usability Test aktiv mit definiertem Aufwand einsetzen 

� Tester und Testgegenstand (Getestete) festlegen 

� Konzept & Entwurf formal überprüfen 

Szenario, Use Case, Screen Diagramme, Workflow, Dokumentation/javadoc 

� Applikationsspezifische Merkmale überprüfen 

Persistenz, Abbruchmöglichkeiten, Verknüpfung mit Anwendungsobjekten, 

Unterstützung versch. Benutzergruppen 

�� GUI 

Übersichtlichkeit, Benutzerführung, Konsistenz, Erwartungskonformität, 

Dynamisches Layout, komplexe Komponenten, … 

� Besonderheiten 

Freier Kommentar 



Seite 469

Beispiele: 

�Direkte �Direkte Manipulation (Drag&Drop) 

�Auto-Ergänzung 



Ziel: intuitive, problemorientierte Bedienung 

Beispiele: 

�� Ballerspiel 

Meist aufwändiger 

� 

� 

Drag&Drop im Windows Explorer 

Textblock verschieben in Textverarbeitung 

zu programmieren 

als Menüs+Dialoge! 

� Größenänderung und Platzierung in Zeichenwerkzeugen 

� Pinsel, Radierer etc. in Malprogrammen 

� Veranstaltung verschieben im Stundenplan 

� Verschieben einer Datei auf eine Fläche: Inhalt anzeigen/Datei öffnen 

� i.d.R. mit der Maus; feinmotorisch anspruchsvoll 

� "Feinarbeit" bei Bedarf mit Pfeil-Tasten 

� Manipulation und Visualisierung hängen eng zusammen 

(� dynamische Interaktion) 



Seite 471

Drag&Drop 

� Wie der Entwurf eines (größeren) Programms zunächst erst konzipiert/geplant 

werden muss genauso ist es notwendig komplexe/zusammengesetzte Dialoge 

zu modellieren. 

� Besonders geeignet zur Dialogmodellierung sind Zustandsdiagramme bzw. - 

graphen. Dabei können die einzelnen Programm- bzw. Dialogzustände als 

Knoten beschrieben werden, und alle Übergänge werden als Kanten 

dargestellt, die durch Ereignisse ausgelöst werden. 

Für eine Drag&Drop-Interaktion bedeutet das: 

� Sobald ein Objekt ausgewählt wurde und der Mausknopf gedrückt bleibt, kann 

das Objekt verschoben werden. Wird der Mausknopf wieder losgelassen, soll 

der Inhalt des Objektes (=Datei) dargestellt werden. 



Seite 472

Zustandsdiagramme 

� Die unterschiedlichen Zustände 

und Übergänge können 

wie folgt beschrieben werden 

(weitere Übergänge sind 

vorstellbar; sie werden aber 

nicht benötigt): 

Objekt bewegen 

z1 z2 z3 

Objekt auswählen 

Objekt im Ziel loslassen 

Zustand Ereignis Folgezustand: Aktionen 

z1 (start) Maustaste wird gedrückt und 

Objekt ausgewählt 

z2: Objekt ausgewählt 

kein Objekt ausgewählt z1 

z2 Objekt bewegen 

Objekt im Ziel loslassen 

z2: neue Position setzen; neu zeichnen 

z3 Objekt im Ziel z3: anwendungsspezifische Aktion: 

Datei lesen, ..., „Aufräumen“, 

z1: Ausgangszustand 

z3 



Seite 473

Aufgabe 

Mit dem Loslassen des 

Objektes werden 

Dateiattribute und 

der Dateiinhalt zeilenweise 

in die JTextArea geschrieben. 

Über eine JTextArea-Instanz sollen 

Objekte (z.B. Icons) gezogen werden 

können. 



Seite 474

Realisierung: JTextArea als Zielbereich 

public class DropTest extends JFrame 

{ 

DropTarget dt; 

JTextArea ta; 

public DropTest() // alles erzeugen und in Anfangszustand versetzen 

{ 

super ("Drag&Drop Test"); 

this.setSize(400,300); 

setDefaultCloseOperation (EXIT_ON_CLOSE); 

ta = new JTextArea(); 

this.getContentPane().add(ta, BorderLayout.CENTER); 

dt = new DropTarget(ta, new MyDropListener(ta)); // Ziel ist die TextArea 

this.setVisible(true); 

} 

public static void main (String args[]) 

{ 

new DropTest(); 

} 

} 



Seite 475

Drag&Drop interfaces 

interface DropTargetListener 

{ 

public void dragEnter (DropTargetDragEvent dte) { } 

public void dragExit (DropTargetEvent dte) { } 

public void dragOver (DropTargetDragEvent dtde) { } 

public void dropActionChanged (DropTargetDragEvent dtde) { } // move/copy 

public void drop (DropTargetDropEvent dtde) { } 

} 

... 

interface DropSourceListener 

{ 

public void dragEnter (DragSourceDragEvent dsde) { } 

public void dragOver (DragSourceDragEvent dsde) { } 

public void dragExit (DragSourceEvent dse) { } 

public void dropActionChanged (DragSourceDragEvent dsde) { } // move/copy 

public void dragDropEnd (DragTargetDropEvent dsde) { } // Benachrichtigung 

} 

... 

interface dragSourceMotionListener 

{ public void dragMouseMoved (DragSourceDragevent dsde) {} } 



Seite 476

Realisierung: Dynamische Interaktion 

Interface DropTargetListener realisieren: 

class MyDropListener implements DropTargetListener 

{ 

JTextArea ta; 

DropListener (JTextArea ta) 

{ 

super(); 

this.ta = ta; 

} 

public void dragEnter (DropTargetDragEvent dte) {...} 

public void dragExit (DropTargetEvent dte) {...} 

public void dragOver (DropTargetDragEvent dtde) {...} 

public void dropActionChanged (DropTargetDragEvent dtde) {...} 

public void drop (DropTargetDropEvent dtde) {...} // entscheidendes Ereignis 

} 



Seite 477

public void drop (DropTargetDropEvent dtde) {...} (I) 

Interface DropTargetListener realisieren: 

public void drop (DropTargetDropEvent dtde) 

{ 

System.out.println (dtde.getSource()); 

try 

{ 

Transferable tr = dtde.getTransferable(); 

DataFlavor[] flavor = tr.getTransferDataFlavors(); 

for (int i = 0; i < flavor.length; i++) 

{ 

// genutzt zum Übertragen von Datei von und nach Java: java.util.List 

ta.append(flavor[i].getMimeType().toString()+"\n"); 

if (flavor[i].isFlavorJavaFileListType()) 

{ 

dtde.acceptDrop(DnDConstants.ACTION_COPY); 

java.util.List list = (java.util.List) tr.getTransferData(flavor[i]); 

DataInputStream br; 

String line = null; 



Seite 478

public void drop (DropTargetDropEvent dtde) {...} (II) 

for (int j=0; j < list.size(); j++) // da sind u.U. mehrere Objekte! 

{ 

ta.append(list.get(j) + \n"); // Dateiname 

DataFlavor bestTextFlavor = DataFlavor.selectBestTextFlavor(flavor); 

ta.append ("bestTextFlavor: "+bestTextFlavor+"\n"); // Empfehlung für Font 

} 

} 

FileInputStream fis = new FileInputStream (list.get(j).toString()); 

br = new DataInputStream (fis); 

line = br.readLine(); // Zeile aus Datei lesen 

while (line != null) 

{ 

ta.append(line+"\n"); // Zeile einfügen 

line = br.readLine(); // Versuch, nächste Zeile zu lesen 

} 

ta.append ("-----------------\n"); 

} 

} 

dtde.dropComplete(true); // Erfolg melden 

} 

catch (Exception e) { System.out.println (e); } 

} 



Seite 479

Auto-Ergänzung (1/2) 

� Auch bei dem Beispiel machen wir uns zunächst deutlich, was wir erreichen 

möchten: 

� Durch das automatische Vervollständigen eines Wortes 

(z.B. Befehls oder Namens) soll die Eingabe der Benutzerin/des Benutzers 

sicherer und schneller gemacht werden; 

bei langen Begriffen werden zu dem Fehler durch Verschreiben vermieden 

�� Das ist ein Beispiel, bei dem die Eingabe nicht erst mit dem RETURN überprüft 

und weiterverarbeitet wird, sondern mit jedem Zeichen betrachtet wird 

(Zwischenzustände spielen eine Rolle). 



Seite 480

Auto-Ergänzung (2/2) 

� Beispiel: 

für den Anfangsbuchstaben ‘w‘ stehen die folgenden Wörter zu 

Verfügung: 

"wiedling", "wiesmann" 

� ‘wies‘ wird ergänzt zu wiesmann , 

� ‘wied‘ wird ergänzt zu wiedling 



Seite 481

Realisierung (1/3) 

class AutoFill extends PlainDocument { 

private String[] terms; 

String eMail[] = { "hahn", "kreling", "wiedling", "wiesmann" 

}; 

private JTextField Recognizer; 

public AutoFill(AutoFillField aRecognizer) { 

super(); 

this.Recognizer = aRecognizer; 

this.terms = eMail; 

} 



Seite 482


public void insertString(int offs, String str, AttributeSet a) 

throws BadLocationException { 

String input, begriff; 

input = Recognizer.getText(0, offs) + str; 

} 

// best match suchen 

begriff = ""; 

for (int i = 0; i < terms.length; i++) 

if (terms[i].startsWith(input)) begriff = terms[i]; 

// no match, dann bleibt der input 

if (begriff.matches("")) begriff = input; 

// alten Text entfernen insertString 

super.remove(0, Recognizer.getText().length()); 

// neuen Text einfügen 

super.insertString(0, begriff, a); 

// Differenz markieren 

Recognizer.select(offs + 1, Recognizer.getText().length()); 

} 

an Erfordernisse 

anpassen 



Seite 483


class AutoFillField extends JTextField { 

} 

public AutoFillField(int cols) { 

} 

super(cols); 

protected Document createDefaultModel() { 

} 

... 

return new AutoFill(this); 

AutoFillField ta; 

ta = new AutoFillField(10); 

ta.setText("AutoFillField"); 

autoErgänzung 

anwenden 

spez. Document 

verwenden 



Seite 484

ENDE. 



Seite 485

new - beim Fachbereich Informatik

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?