Entwicklung nutzerorientierter Anwendungen

Entwicklung nutzerorientierter Anwendungen
Wintersemester 2013/2014 Prof. Dr.-Ing. Bernhard Kreling Hochschule Darmstadt Fachbereich Informatik

1. Einführung Lernziele der Veranstaltung
Benutzerzentrierung verinnerlichen human computer interaction Kundenorientierung Grafische Benutzungsoberflächen intuitiv und ergonomisch gestalten visuell ansprechend entwerfen objektorientiert konstruieren Konzept der Ereignisorientierung verstehen Bausteine grafischer Oberflächen kennen lernen ... und das alles in Java mit Swing

User Research: Stereotypen, Szenarien
1. Einführung Inhalte User Research: Stereotypen, Szenarien SW-Technik: Use Case Analyse, GUI-Diagramme Trennung Datenverarbeitung/Oberfläche, Dokument/Ansicht Screen Design und Ergonomie Gruppierung, Formen, Farben, statisches / dynamisches Layout Java Kurs für Kenner von C++ GUI-Implementierungstechniken Bausteine: Datentypen, Attribute, Ereignisse Fenster und Dialoge, Layout-Manager Ereignisbehandlung Gute Beispiele, schlechte Beispiele Voraussetzung: PG1 bestanden, PG2 begonnen

1. Einführung Praktikum Semesterprojekt: Entwurf, prototypische Realisierung und Optimierung eines Systems vage Aufgabenstellung (wie im richtigen Leben) kein Erfolgserlebnis: man findet immer noch bessere Lösungen – darin liegt der Erfolg ! Problembewusstsein wird erst im Lauf des Semesters entstehen, deshalb sind optimierende Iterationen wichtig Projektmappe mit Dokumentation und Software semesterbegleitend erstellen und pflegen zu Beginn jeder Übung mit Ergebnissen der vorigen vorlegen dient Ihnen selbst in jeder Übung als Planungsunterlage top-down bottom-up ?

mit Papier und Bleistift
1. Einführung Klausur mit Papier und Bleistift Hilfsmittel: das Skript und sonstige eigene Unterlagen (nicht die des Nachbarn) auf Papier sind als Hilfsmittel zugelassen Termin und Anmeldung im Online Belegsystem Zulassungsvoraussetzung: regelmäßige und erfolgreiche Teilnahme am Praktikum Vorlage der vollständigen Projektmappe beim 6. Termin

1. Einführung Literatur (HCI und UID)
Keith Andrews: Human-Computer Interaction M. Dahm: Grundlagen der Mensch-Computer-Interaktion Shneiderman, Plaisant: Designing the User Interface Alan Cooper: About Face - The Essentials of User Interface Design Ivo Wessel: GUI-Design Oracle: Java Look and Feel Design Guidelines Frank Thissen: Screen Design Handbuch Hans-Peter Wiedling: Skript zur Parallelveranstaltung Ralf Hahn: Skript "Objektorientierte Analyse und Design"

1. Einführung Literatur (Java)
Guido Krüger: Handbuch der Java-Programmierung David Flanagan: Java in a Nutshell, O'Reilly Oracle: The Java Tutorial Oracle: Java Standard Edition API Oracle: Java Language Specification Eclipse Online Hilfe F2, Open External Javadoc

1. Einführung Entwicklungsumgebung
Eclipse mit WindowBuilder Java Applikation für Windows, Linux, Mac OS X braucht viel Arbeitsspeicher und großes Display Windows: 512 MB mindestens; 768 MB empfohlen Linux, Mac OS: 1 GB empfohlen Netbooks eher nicht geeignet kostenlos im Web Variante "Eclipse IDE for Java Developers" enthält als GUI Editor den "WindowBuilder" Homepage mit Download

Erforschung der Benutzer und Anwendungsszenarien
2. Softwaretechnik für Benutzungsschnittstellen Übersicht: Analyse und Entwurf Ergänzung zu OOAD, nicht Gegenposition UOAD User Oriented Analysis and Design  Visionsdokument Erforschung der Benutzer und Anwendungsszenarien auch Workflows Anwendungscharakter und Modell Nicht-funktionale Anforderungen Anwendungsfallanalyse Use Case Diagramm (UML) und Beschreibung Navigationsübersicht Screen-Diagramme abstrakt: Bedien- und Anzeigeelemente nur aufgelistet konkret: Layout-Skizze Klassen- und Sequenzdiagramme (UML) jeder Screen wird Objekt einer eigenen Klasse

2. Softwaretechnik für Benutzungsschnittstellen Visionsdokument
Sinn und Zweck der Anwendung/Website welche Ziele sollen erreicht werden? welche (Geschäfts-)Prozesse sollen unterstützt und optimiert werden? Beispiel Online Belegsystem: Gerechte Verteilung knapper Plätze verbesserte Verfügbarkeit von Restplätzen Verhinderung von Mehrfachbelegungen Teilnehmerlisten, die der Realität entsprechen Gleichmäßige Auslastung der Parallelzüge Vorrang für Studierende im Regelablauf

2.1 Benutzer kennen und verstehen Admins und User – ein Zerrbild
so unterteilen Informatiker gerne die Menschheit Admins kennen sich aus und haben die Macht User haben keine Ahnung Worst Case Betrachtung: DAU – dümmster anzunehmender User  völlig falscher Ansatz

2.1 Benutzer kennen und verstehen Benutzer 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 Allgemeinen und im Hinblick auf das System charakterisieren ? seltene / häufige / ständige Nutzer, Anfänger / Fortgeschrittene / Profis bezüglich der Anwendungsdomäne bezüglich der Anwendung bezüglich Rechner und Betriebssystem interessiert / widerwillig ? lernfähig / starr ? Kontextwissen ( inhaltliche Tiefe und Terminologie) ? im Stress ? Der DAU ist nicht blöd ! Er hat einfach nur Wichtigeres zu tun

2.1 Benutzer kennen und verstehen Stereotype
"Stereotyp" ist hier sozialwissenschaftlich gemeint, nicht im Sinn der UML lebendige, anschauliche Steckbriefe typischer Vertreter der Benutzergruppen Name, Bild, Alter, Geschlecht, Ausbildung, Vorlieben, Hobbys, Charaktereigenschaften typisches Verhalten, auch im Hinblick auf das System nicht durchschnittlich, lieber markant, dennoch glaubwürdig "Durchschnittsbenutzer" führen zu durchschnittlichen Entwürfen

2.1 Benutzer kennen und verstehen Stereotype und Benutzerrollen
englisch: Persona reale BenutzerInnen werden zusammengefasst zu Benutzergruppen Benutzergruppen werden veranschaulicht durch Stereotype realitätsnahe Schilderung vordergründig irrelevanter Details wenn echte Menschen bekannt sind, braucht man keine Stereotype dient der Überprüfung der folgenden Abstraktion Benutzergruppen werden abstrahiert zu Benutzerrollen haben unterschiedliche Anwendungsfälle bekommen differenzierte Zugriffsrechte bekommen unterschiedliche Hilfe-Informationen Benutzerrollen werden später implementiert erscheinen als Akteure im Use Case Diagramm nicht zu früh die Vielfältigkeit der BenutzerInnen wegabstrahieren!

2.1 Benutzer kennen und verstehen Anwendungsszenarien
ein Hilfsmittel, um den Gesamtzusammenhang zu sehen, bevor man sich dem Systementwurf widmet das künftige System und seine Benutzer in größerem Kontext schildern hilfsweise kann man vorab Szenarien für das bisherige System schreiben Szenarien werden für bestimmte Stereotype geschrieben "Geschichten" über Benutzer und Nicht-Benutzer z.B. Verwaltungsmitarbeiter und deren Kunden Ziele und Aufgaben Lebenssituation, Arbeitsumfeld, Workflows Beispiele: Übung: Ingo I. braucht ein Zwischenzeugnis für eine Bewerbung

2.1 Benutzer kennen und verstehen Szenario  Use Case Beschreibung
Anwendungsszenario anschaulich auch Umfeld der Akteure umfassend, überlappend unvollständig und ungenau ignoriert Fehler Use Case Beschreibung trocken nur Akteure und System klar abgegrenzt vollständig und präzise berücksichtigt Fehler Use Cases werden später aus den Anwendungsszenarien erarbeitet

2.1 Benutzer kennen und verstehen Methoden der Benutzerforschung
woher kommt das Material für Stereotype und Szenarien ? Interviews / Expertengespräche informelle Gespräche mit Kennern der Anwendungsdomäne Fokusgruppe moderierte Diskussion einer kleinen Gruppe künftiger AnwenderInnen geringer Aufwand, qualitative Ergebnisse bringt neue Aspekte, auch Antworten auf nicht gestellte Fragen Fragebogen quantitative (evtl. statistisch gesicherte) Ergebnisse Ergebnisse können nicht besser sein als die Fragen die "richtigen" Fragen zu stellen ist nicht trivial

2.1 Benutzer kennen und verstehen Fallen umgehen
Benutzer(in) beschreibt seine/ihre eigene Aufgabe, definiert nicht das System umgangssprachlich, informell, inkonsistent zwischen den Zeilen lesen – auf Feinheiten achten gängige Regeln des guten Brainstormings einhalten "schwierige" oder unkonventionelle Ideen aufgreifen, nicht im Keim ersticken Interviewer/Moderator ohne vorgefasste Meinung keine vorzeitige Festlegung auf Architektur- oder Implementierungsideen Gesprächspartner nicht beeinflussen

2.1 Benutzer kennen und verstehen z.B. Fahrkartenautomat
kleine, große, alte, junge, mit Sehschwäche ... und dann scheint noch die Sonne auf's Display wegfahren zu Termin / Besuch / ... ganz unterschiedliche Nutzungshäufigkeit interessiert? nein lernfähig? manche Stress? aber sicher! die Straßenbahn droht abzufahren

2.1 Benutzer kennen und verstehen z.B. Online Belegsystem
Studierende Fb Informatik, Fb Media, sonstige Fb, Austausch, CNAM ein Anwendungsszenario: Lehrende Sekretärinnen Fachbereichsassistentin Anwendungs-Administrator System-Administrator ESE-Tutoren Laboringenieure

2.1 Benutzer kennen und verstehen z.B. Stundenplanungssystem
Sekretärin: Eingabe von Wunschzetteln Ausdrucken von Plänen Beantworten von Anfragen Prodekan: Lehrveranstaltungsplanung (wer macht was) Stundenplaner: Stundenplanung (wann und wo) ist der LV-Bedarf klar? hat er eine Strategie? charakterisieren Sie die Benutzergruppen !

2.2 Anwendungscharakter und Modell Nicht-funktionale Anforderungen
technisch möglichst gering halten Client: Browser ab HTML 4.1, CSS, Frames, JavaScript aktiviert Client Bildschirm  1024 x 768 Pixel minimale Transferrate 56 kBaud Benutzer muss -Adresse haben mindestens 100 Benutzer gleichzeitig; Meldung bei Überlast ... gestalterisch Creative Design Brief Anwendungscharakter, Stil, Stimmung freundlich, hilfsbereit, seriös, verspielt, nüchtern, provokativ, ... Anrede des Benutzers: Du / Sie Corporate Identity Farbschema

2.2 Anwendungscharakter und Modell Charakter von Anwendungen
in Anlehnung an U- und E-Musik U-Software Spiele Funware Fotoalbum, Videoschnitt E-Software Bildbearbeitung, Videoschnitt Office-Anwendungen Kommerzielle Datenverarbeitung in diesem Stil machen wir das Praktikum ! Maschinensteuerungen wohin gehören Fahrplanauskunft, Geldautomat, Ticketservice, ... ? fließende Übergänge

2.2 Anwendungscharakter und Modell Modelle eines Systems
Modelle sind vereinfachte Darstellungen einer Wirklichkeit vgl. Atommodelle in der Chemie a) mentales Modell Sicht des Benutzers; anwendungsorientiert b) augenscheinliches Modell wie sich das System nach außen darstellt c) Implementierungsmodell Sicht des Entwicklers; technologisch orientiert interessant für die Wartung, nicht für den Benutzer kein Modell entspricht der "Wahrheit" Ziel von Analyse und Entwurf: Diskrepanz dieser Modelle vermeiden !

2.3 Anwendungsfallanalyse Anwendungsfälle (Use Cases)
hier nur zur Erinnerung siehe Skript R. Hahn: Objektorientierte Analyse und Design Teil der Unified Modeling Language UML High-Level-Beschreibung eines Systems erfasst die Benutzerrollen / Akteure erfasst, was diese mit dem System machen das System wird als Black Box betrachtet rückt immerhin den Menschen in den Blick ! nicht Datenstrukturen und -flüsse beschreibt nicht die Struktur des Systems ! aber arg abstrakt

2.3 Anwendungsfallanalyse Use Case Diagramm (Geldautomat)
zur Übersicht vor dem Entwurf der Benutzungsoberfläche 2.3 Anwendungsfallanalyse Use Case Diagramm (Geldautomat) eine Benutzerrolle sieht oft nicht die Funktionen der anderen Use Cases entsprechen oft der obersten Menüebene Kontostand abfragen Geld holen Geldvorrat prüfen Geldkarte laden Geld nachfüllen Kunde Geldautomat eingezogene Scheckkarten entnehmen Mitarbeiter ein Mitarbeiter kann zugleich Kunde seiner Bank sein, muss sich dann aber separat per EC-Karte authentifizieren (d.h. ein Benutzer kann auch zwei Rollen haben)

2.3 Anwendungsfallanalyse Use Case Diagramm (Belegsystem)
zur Übersicht vor dem Entwurf der Benutzungsoberfläche 2.3 Anwendungsfallanalyse Use Case Diagramm (Belegsystem) die Sekretärin braucht keinen zusätzlichen Fachschafts-Account um die Zugzuordnung einzutragen, d.h. jede(r) hat nur eine Rolle

2.3 Anwendungsfallanalyse z.B. 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 Wiederauffinden einer Stelle Lesezeichen weiterführende Information finden Literaturliste Kaufentscheidung treffen Inhaltsverz., Klappentext, Leseprobe vgl. Grundfunktionen eines Browsers vgl. dagegen einen Roman

2.3 Anwendungsfallanalyse 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 versionsorientiert: Meilensteine Änderungen vergessen statt Schließen und wieder Öffnen das Beispiel ist problematisch, weil Benutzer dateiorientiertes Arbeiten gewohnt sind ...

2.3 Anwendungsfallanalyse Beispiel: anwendungsfallorientiert
Prodekan Sekretärin Stundenplaner

2.3 Anwendungsfallanalyse Gegenbsp.: datenstrukturorientiert
 2.3 Anwendungsfallanalyse Gegenbsp.: datenstrukturorientiert

2.3 Anwendungsfallanalyse Von Use Cases zu Screens
Entwurf der Grobstruktur des Dialogsystems 2.3 Anwendungsfallanalyse Von Use Cases zu Screens ein Ansatz, aber kein Rezept, sondern ein kreativer Prozess Screen = Fenster, Maske, Seite, View jeder Use Case wird in einen Screen abgebildet Name des Use Case wird Titel des Screens ggf. 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 Benutzerrollen besser: Identifikation des Benutzers durch Anmeldung und Ausblendung der Use Cases anderer Benutzerrollen; jeder Benutzer bekommt nur Screens "seiner" Rolle zu sehen Hauptfenster enthält Übersicht der Use Cases und verzweigt dorthin im primitivsten Fall eine Liste

2.3 Anwendungsfallanalyse Use Case Spezifikation
im Detail nach dem Entwurf der Benutzungsoberfläche mit Bezug auf die geplanten Bedienelemente 2.3 Anwendungsfallanalyse Use Case Spezifikation Use Case Name Primary Actor (Further Actors) (Stakeholders and their Interests) (Success Guarantees) (Minimal Guarantees) Trigger Basic Course (Alternative Course) im Praktikum: Konzentration auf das Wesentliche vgl. Skript R. Hahn: Objektorientierte Analyse und Design kann bei Bedarf erweitert werden ...

2.4 Abläufe 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 oder spezialisierten Tools dargestellt werden

2.4 Abläufe Beispiel zum Workflow
auf Benutzungsoberfläche visualisiert Prodekan Sekretärin Stundenplaner

Assistenten geben dem Benutzer einen Ablauf vor
2.4 Abläufe Assistent Assistenten geben dem Benutzer einen Ablauf vor Assistenten serialisieren die Abfrage mehrerer Eingabewerte eines Use Cases oder mehrere Use Cases, die nacheinander ausgeführt werden müssen wichtig: später Abbruch nur auf Wunsch des Benutzers ! Vorteil: Benutzer muss zu einem Zeitpunkt nur über eine Frage nachdenken sinnvoll für selten benutzte Anwendungsfälle oder für unerfahrene Benutzer Nachteil: langsam und schwerfällig für Profis

2.4 Abläufe Beispiele zu Assistenten
a) Geldautomaten kennen wir nur als Assistenten die Benutzung ist i.a. schon zäh ... zum Vergleich der bekannte Geldautomat mal nicht als Assistent: b) Online Shop Ware in Warenkorb Adresse eingeben Versandart wählen Zahlungsweise wählen Bestellen

2.5 GUI-Diagramme Sinn und Zweck
kein geeignetes Diagramme für GUI-Entwurf in UML 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 Kommunikationsdiagramms kann man sich aber kein Bild von Aussehen und Benutzung machen ! Vorschlag: Navigationsübersicht + Screen-Diagramme im Grunde abgewandelte Zustandsdiagramme

2.5 GUI-Diagramme vgl. Flow Chart
zum Vergleich eine Flow Chart aus dem Bereich Design (auch Seitenstruktur oder Contentogramm genannt) aus Fröbisch, Lindner, Steffen: "MultiMediaDesign - Das Handbuch zur Gestaltung interaktiver Medien"

2.5 GUI-Diagramme vgl. Zustandsdiagramm
offen geschlossen öffnen schließen/rumms Tür aus an do/leuchten ausschalten einschalten Lampe Übergangsaktion Zustandsaktion

2.5 GUI-Diagramme Navigationsübersicht (abstrakt)
spezielle Form eines Zustandsdiagramms 2.5 GUI-Diagramme Navigationsübersicht (abstrakt) Knoten = Screens/Fenster/Seiten Übergänge = Bedienelemente übersichtlich durch "Bus" am Beispiel des OBS (Ausschnitt) Login für Studierende leer Passwort vergessen? timeout Logout 1. Login Belegungen kontrollieren FAQ Kontakt Persönliche Daten Passwort ändern Restplatz- belegung Meine Belegungen Was tun wenn... 1. Login 1A WP Inf. alle belegte Session Belegfristen Legende zu ... Terminplan Vermerke zu ... Stunden- pläne Tipps & FAQ

2.5 GUI-Diagramme Navigationsübersicht (detailliert)
Hauptmenü Übersicht mit Workflow Deputatserm. Studienprog. Lehrverans. Raum+Zeitw. Stundenplan Use Cases R rechter Mausklick Dep. St.gang Schwerp. FB Dozenten Kontextm. Pop-Ups Raum Notation und Vereinfachungen: Zustände als Screenshots Übergänge i.a. mit Linksklick R mit Rechtsklick Rücksprung / Schließen zurück Dup.Bel. Dup.Kür.

2.5 GUI-Diagramme Legende zur Navigationsübersicht
Anwendung starten beenden Aktionen neues Hauptfenster neuer Dialog/PopUp Rücksprung Ereignisse keine Angabe: linker Mausklick rechter Mausklick R Zustände Screen-Name (abstrakt im Entwurf) Layout-Skizze (konkret im Entwurf) Screenshot (konkret für Dokum.) Bedingungen mit Shift/Umschalttaste S mit Ctrl/Strg-Taste C mit Alt-Taste A

2.5 GUI-Diagramme Screen-Diagramme
Verfeinerung der Knoten aus der Navigationsübersicht abstrakt konkret LvPlanungAusgeben + Sortierung : {Semester, Dozent, ImpExp} + Fachbereich : String + VorschauAnzeigen() + Drucken() + inDateiAusgeben() + Schließen() skizziert detailliert "Klassendiagramm" beschränkt auf I/O-Elemente (im OOAD-Sinne: Analyseklasse der Oberfläche) mehrere Handskizzen (Wireframes, Paper Prototypes) Screenshot

2.5 GUI-Diagramme Varianten von Screen-Diagrammen
abstrakt kein echtes Klassendiagramm der implementierten Fensterklasse entspricht eher der Analyse-Klasse des Fensters Attribute: die Ein-/Ausgabe-Parameter des Fensters Methoden: die für den Benutzer verfügbaren Funktionen skizziert verschiedene Entwürfe mit unterschiedlichen Bedienelementen bewusst nur Handskizzen um die Vorläufigkeit zu dokumentieren grobe Anordnung, grobe Gestaltung detailliert Festlegung auf bestimmte Bedienelemente Gestaltung mit allen Details, ggf. Screenshot im Nachhinein Links zu Paper Prototyping:

2.5 GUI-Diagramme Vorgehensweise für Screen-Diagramme
theoretisch: abstrakt  n * skizziert  konkret abstrakt zu beginnen fällt aber vielen Leuten schwer, deshalb folgender iterativer Ansatz: Skizze eines konkreten Entwurfs Verallgemeinerung zu abstraktem Diagramm mehrere weitere konkrete Skizzen von Entwurfsalternativen Bewertung der Entwurfsalternativen und Auswahl der besten detaillierte Ausarbeitung des ausgewählten Entwurfs es sollten unbedingt mehrere Alternativen betrachtet werden !

2.5 GUI-Diagramme Spezialfall Karteireiter (JTabbedPane)
jede Karteikarte wird als eigener Screen abgebildet den wahlfreien Wechsel zwischen den Karteikarten implementiert die JTabbedPane automatisch Verfeinerung bildet Einbettung ab 1. Entwurf Allgemein Freigabe Anpassen Eigenschaften Allgemein Freigabe Anpassen

2.5 GUI-Diagramme UML-Sequenzdiagramm zur Erinnerung
stellt Objekte und deren Interaktion dar Interaktion: eine Methode ruft eine andere Methode auf Zeitachse von oben nach unten Lebensdauer des Objekts durch "Lebenslinie" dargestellt bietet sich an zur Modellierung ereignisorientierter Systeme gesucht: Verknüpfung zwischen Oberfläche und inneren Abläufen

2.5 GUI-Diagramme vgl. Sequenzdiagramm "Geld holen"
Negativbeispiel abstrahiert von GUI: so bringt es uns nichts 2.5 GUI-Diagramme vgl. Sequenzdiagramm "Geld holen" Ich: CBenutzer VolksbankAutomat1: CGeldautomat Screens = Zustände EC-Karte einlesen Ruhestellung Hauptmenü PIN-Dialog ... Geld holen Use Case wählen PIN-Nummer einlesen in diese Richtung kann man das innere Verhalten weitermo- dellieren Betrag einlesen EC-Karte ausgeben EC-Karte entnehmen Geld ausgeben Geld entnehmen

2.5 GUI-Diagramme Verbindung GUI  Sequenzdiagramm
LvPlanungView: CLvPlanungAusgDlg LvPlanungModel: CLvPlanungAusg OnSortClick SetSort(Sort) OnFbChange SetFb(Fb) OnDiskClick Output(D) OnPrintClick Output(P) Output(V) OnPreviewClick OnExitClick hier wird deutlich, woher die Aufrufe kommen

2.5 GUI-Diagramme Fokussteuerung definieren
7 8 1 2 3 4 5 6 OnReturn OnReturn vollständiger Weg mit TAB dabei können auch einzelne Elemente übersprungen werden abgekürzter Weg für häufig benötigten Sonderfall mit RETURN hilfreich bei Eingabe großer Datenmengen per Tastatur

2.5 GUI-Diagramme Drag&Drop
das beschreibt man besser in Listenform Raum löschen Anzeigezeile umschalten Shift: vertauschen Ctrl: duplizieren verschieben löschen Raum festlegen

2.5 GUI-Diagramme Komplexität beherrschen
Diagramme beanspruchen generell 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

2. Softwaretechnik für Benutzungsschnittstellen Klarstellung: Diagramme - für wen ?
Diagramme aus der Softwaretechnik sind nicht geeignet um mit Auftraggebern / Benutzern 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 zumindest Paper Prototypes oder "Clickable Wireframes" (erlauben das Umschalten zwischen einzelnen Wireframes) Diagramme helfen dem Entwickler beim Entwurf, dem Wartungsprogrammierer zum Verständnis

2. Softwaretechnik für Benutzungsschnittstellen Vorbild Architektur
Rückverfolgbarkeit bei der Modellierung (auch) visueller Objekte

2. Softwaretechnik für Benutzungsschnittstellen Grenzen der UML
viele Autoren versuchen UML zu erweitern, aber: SWT / UML veranschaulicht durch Diagramme ist ein Gewinn, solange der Gegenstand der Modellierung ein abstraktes / virtuelles Konzept ist Objekte, Klassen, Methodenaufrufe, Zustände, Zustandsübergänge... ist ungenügend, sobald der Gegenstand der Modellierung eine ureigene visuelle Ausprägung besitzt GUI-Objekte haben ein "Gesicht" Konsequenz: Designer und Benutzer können keinen Bezug zur natürlichen Sicht auf das System herstellen SWT sollte lernen von Disziplinen mit Erfahrung in der Modellierung gegenständlicher Objekte

2. Softwaretechnik für Benutzungsschnittstellen 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 zu fragen will gekonnt sein ... mit geeigneten Tools ist die Erstellung einer Bedienober-fläche nicht aufwändiger als mit einem Zeichenwerkzeug vgl. Photoshop / Flash  Visual Basic / Visual C++ / Eclipse

3.1 Arten von Benutzungsoberflächen Klassifikation
Bedien-Paradigmen veraltet: Kommandozeile, textbasierte Bildschirmmasken Arbeitspferd: WIMP-Oberflächen Windows, Icons, Menus & Pointing "seriöse Datenverarbeitung" Webbasierte Anwendungen (HTML im Browser) Infokiosk mit Touchscreen Mobile Endgeräte (Handy, PDA, Smartphone) Multitouch Table (MS Surface) Home & Fun: Multimedia-Freiform-Oberflächen Joystick / Spielekonsole (Spiele, Flugsimulator) natürlichsprachliche Kommunikation damit beschäftigt sich SW-Ergonomie unser Fokus

3.1 Arten von Benutzungsoberflächen Menüs und Dialoge
für ungeübte oder gelegentliche Benutzer in der Bedienung eher schwerfällig soll eine schnelle Einarbeitung ermöglichen logische hierarchische Gliederung der Befehle hoffentlich ! vollständige Übersicht aller Befehle Lernhilfen zum Umstieg auf schnellere Bedienweisen zugehörige Icons zugehörige Tastaturkürzel Menüs sind platzsparend, lassen Arbeitsfläche frei Dialoge für differenziertere / erklärungsbedürftige Interaktion

3.1 Arten von Benutzungsoberflächen Toolbars und Icons
schnelle Bedienung für einigermaßen geübte Benutzer Direktzugriff ohne stufenweises Aufblättern von Menüs empfehlenswert für häufig benutzte Funktionen lockern visuell auf Icons müssen gelernt werden ! kaum ein Icon ist selbsterklärend; z.B. Lesezeichen/Favoriten: Mozilla Internet Explorer DVB-T-Tuner Icons sollten unbedingt durch Tooltips "beschriftet" werden manche Standard-Icons sind bekannt, aber zumeist plattformabhängig gegenständliche Bilder für abstrakte Funktionen ? wird oft verkannt

3.1 Arten von Benutzungsoberflächen Tastaturkürzel / Hotkeys
moderner Ersatz für Kommandosprachen in WIMP-Systemen sehr effizient, aber nur für sehr geübte Benutzer besonders zweckmäßig, wenn große Datenmengen eingegeben werden müssen Hand sollte nicht zur Maus greifen müssen Qualitätskriterien: durchgängige Bedienung möglich? alle Tastaturkürzel im Menüsystem dokumentiert? eigene Tastaturkürzel definierbar (Makros)? durch zweckmäßige, am Arbeitsablauf orientierte Fokussteuerung unterstützt?

3.1 Arten von Benutzungsoberflächen Direkte Manipulation
meist aufwändiger zu programmieren als Menüs+Dialoge intuitive, problemorientierte Bedienung Beispiele: Drag&Drop im Windows Explorer Textblock verschieben in Textverarbeitung Pinsel, Radierer etc. in Malprogrammen Veranstaltung verschieben im Stundenplan klassisch mit der Maus; feinmotorisch anspruchsvoll "Feinarbeit" bei Bedarf mit Pfeil-Tasten mit dem Finger auf Touchscreens besonders intuitiv, auch für ungeübte Benutzer Manipulation und Visualisierung hängen eng zusammen adäquate grafische Darstellung ist nicht trivial

3.1 Arten von Benutzungsoberflächen Multi-Touch Gesten
Tap iPhone Double Tap Flick Drag Pinch Open Pinch Close Touch and Hold 3.1 Arten von Benutzungsoberflächen Multi-Touch Gesten ohne weitere Hilfsmittel (Stift, Maus) aber nicht selbstdokumentierend müssen entdeckt und gelernt werden

3.1 Arten von Benutzungsoberflächen Web-Oberflächen
richten sich an völlig ungeübte Benutzer dürfen absolut keine Einarbeitung verlangen fun factor ist teilweise wichtig wenige und einfache Funktionen häufig "Blättermaschinen" im weitesten Sinne nicht zu vergleichen mit Software-Tools aber neuer Trend: Rich Client Applications mit AJAX geringste motorische Anforderungen auf einfachen Mausklick reduziert kein Doppelklick, kein Drag&Drop, kein Rechtsklick keine "Arbeitsfläche", aber viel Platz für "Beschriftung" zu enge Beschränkung für manche Client/Server- Anwendungen

3.1 Arten von Benutzungsoberflächen Konventionen berücksichtigen
übergeordneter Aspekt Vertrautheit, Gewohnheit gleiches Verhalten in ähnlichen Situationen Gewohnheiten sind oft unbewusst Konventionen sind kulturabhängig Lichtschalter nach unten: in Amerika aus, in England an Wasserhahn öffnen: in Amerika links-, in England rechtsdrehen Anwendung starten: Windows Doppelklick, Mac Einfachklick Dilemma: was tun, wenn das Gewohnte nicht gut ist ... radikaler Bruch mit den Konventionen: Ribbons

3.2 Formen Gedanken zur Fenstergestaltung
Führung der Augen von links oben nach rechts unten Fenster eher breit als hoch (analog zum Bildschirm und Sichtfeld) Mehrspaltigkeit erleichtert das Lesen (vgl. Zeitung) Kanten der Komponenten bilden Fluchtlinien Anzahl der Fluchtlinien minimieren, ohne jedoch Komponenten sinnlos zu vergrößern nicht die ganze Fläche mit Komponenten pflastern; Freiflächen sind wichtige Gestaltungsmittel ! Proportionen, Balance, (Symmetrie), Einfachheit einheitliche Schriftart, abgestimmte Farben (Farbklima)

3.2 Formen z.B. Windows arabisch
von rechts oben nach links unten

3.2 Formen Prioritäten für Gruppierung
inhaltliche Gemeinsamkeiten (Funktionsgruppen) aufgabenbezogene Folge von Arbeitsschritten Benutzungshäufigkeit aber nicht dynamisch verändern ! alphabetische Anordnung, Nummerierung etc.

3.2 Formen 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

3.2 Formen z.B. MS Word Druckdialog

3.2 Formen Natürliche Anordnung
natural mapping (Um-)Denken vermeiden left right top bottom Border das Herdplattenproblem Cursortasten Border

3.2 Formen 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 beliebtester Fehler

3.2 Formen 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 ~ 10pt bei 40cm Leseabstand auf Papier unabhängig von System- konfiguration

3.2 Formen Umrechnung des Sehwinkels
(Notebook) in Wahrheit 117 dpi

3.2 Formen 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: Java 72 dpi kein echter Zoom bei gemischter Bemaßung vgl. Windows: Schriften und Controls in pt, Fenster in Pixel vgl. altes HTML: Schriften in pt, sonstige Maße in Pixel unterschiedliche Monitorgröße u. Grafikauflösung alles Fiktion: 800x600 auf 17" gibt 67 dpi d.h. 1 Pixel = 1 pt

3.2 Formen Dialog Units (DLU) unter Windows
MS Sans Serif 8pt Dauphin-Normal 14pt Windows unterstützt nur statische Layouts jeder Dialog hat einheitlichen Font Schriftgröße in pt Controls passen sich an in .RC-Datei stehen absolute Maße als DLUs DLU ist abhängig von Schriftgröße und damit auch vom Abbildungsmaßstab hor. DLU = mittlere Breite der Dialogschriftart / 4 vert. DLU = mittlere Höhe der Dialogschriftart / 8 nicht so exakt wie Layout-Manager, aber in der Praxis passt's

mit Serifen Times "Führungslinien" für das Auge
3.3 Schrift 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

3.3 Schrift Gut lesbare Bildschirm-Schrift
Problem niedriger Auflösung; relativiert sich bei Retina Display serifenlos für Bildschirm (Serifen nur für Druck) Proportionalschrift, Groß-/Kleinschreibung nicht unterstrichen, nicht blinkend, nicht kursiv horizontal ausgerichtet, linksbündig, kein Blocksatz begrenzte Spaltenbreite (vgl. Zeitungsspalten) Schrifthöhe mindestens 0.3° Sehwinkel besser 0.5°  12 pt (bei 15" Notebook, 1400x1050, 40 cm Abstand) deutlicher Kontrast zum Hintergrund Text- und Hintergrundfarbe beachten

3.3 Schrift 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 erst "ausführlich" formulieren, dann "verdichten" Label-Text nicht breiter als 5° Sehwinkel (= 1 Fixation) ca. 120 Pixel (bei 15" Notebook, 1400x1050, 40 cm Abstand)

3.3 Schrift Ausrichtung von Beschriftungen
einzeilige Steuerelemente: Label links; horizontal zentriert mehrzeilige Steuerelemente: Label links oberhalb mehrere verschieden lange Labels: etwa gleich: linksbündig sehr unterschiedlich: rechtsbündig einzeilig mehrzeilig minimal Tabulator mittel Makro maximal Einblendezeit

3.3 Schrift 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 beliebige Groß-/Kleinschreibung zulassen optimal !

Hörsaalübung Gestalten eines Eingabefensters
Was ist hier schlecht ? Verbessern Sie den Entwurf !

Darstellung in der Farbtafel
"unbunt" 780 520 380 nicht darstell- bare Farben Wellenlänge 550 nm 500 480 3.4 Farbe Was ist Farbe ? Physikalische Sicht Spektralfarben = "Regenbogenfarben" eine Frequenz; Wellenlänge in nm Rest: Überlagerung mehrerer Freq. Physiologische Sicht dieselbe Farbempfindung kann durch 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

Mischung von farbigem Licht additive Farbmischung Einsatzgebiete
Grün Rot Blau 3.4 Farbe 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

Mischung von Farbstoffen (Farbfiltern) subtraktive Farbmischung
Cyan Magenta Yellow Papier weißes Licht 3.4 Farbe Farbmodell CMYK Mischung von Farbstoffen (Farbfiltern) Grundfarben Cyan, Magenta, Yellow, Key (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 typische Probleme: geringere Farbsättigung als Bildschirm; schlechtere Dosierbarkeit = weniger Farbabstufungen; starke Abhängigkeit von Papierqualität

anwendungsorientiert, zielgerichtet manipulierbar
0.75 0.25 0.5 S H L 3.4 Farbe Farbmodell HSL anwendungsorientiert, zielgerichtet manipulierbar Farbart Hue Sättigung Saturation Helligkeit Luminance Lightness auch HSI Intensity HSB Brightness HSV Value S H L

3.4 Farbe Physiologische Aspekte
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 (Schärfe) für verschiedene Farben besonders schlecht: Blau farbabhängige Helligkeitsempfindung grün wirkt heller, blau dunkler kleine Objekte auf hellem Grund wirken dunkler als große die Iris (= Blende) passt sich an Farb- und Helligkeitsempfinden wird auch von der Umgebung beeinflusst, nicht nur vom Monitor Farbenblindheit  Galerie

3.4 Farbe Psychologische Aspekte
im allgemeinen kulturspezifisch Ägypten: Tod, Amerika: Gefahr, China: Glück, Indien: Leben 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

3.4 Farbe 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

3.4 Farbe 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 gibt Spielraum für helle und dunkle Kontraste angenehm für das Auge: entspricht der Umgebungshelligkeit dagegen hilft hohe Bildwiederholrate oder LCD

3.4 Farbe Farbschema / Farbklima
±5 verschiedene Farben + schwarz + weiß siehe auch

eher weniger Farbe als mehr eher weniger Farbsättigung als mehr
3.4 Farbe 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"

Farbe dient als "Skala" eines (physikalischen) Wertes
3.4 Farbe Farbcodierung Farbe dient als "Skala" eines (physikalischen) Wertes vgl. Landkarte, Wetterkarte suggestive Zuordnung von Farbcode zu Bedeutung unterschiedliche Farbarten wirken leicht "ungeordnet" sicherer: Abstufungen nur in Helligkeit und/oder Sättigung, nicht in Farbart (Hue) Hervorhebung durch Intensivierung "aktiv", "selektiert"  höhere Helligkeit oder Sättigung

3.5 Dynamisches Layout Begriffserklärung
bisher: Größe und Position von Komponenten in der Entwicklungsphase festgelegt jetzt: Komponenten bekommen eine zur Laufzeit variable Größe und/oder variable Position a) abhängig von der Fenstergröße kann sich an der Grafikkartenauflösung orientieren 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 auch ein typisches Problem beim Web-Design zweckmäßiger Einsatz ist nicht trivial

3.5 Dynamisches Layout Wo macht es Sinn ?
sorgfältig überlegen, welche Komponenten dynamisch werden sollen abhängig von der Fenstergröße: alle Komponenten mit Scrollbalken z.B. JList, JTree, JTable; evtl. auch JTextArea Scrollbalken können verschwinden mehr Inhalt wird sichtbar abhängig von der Schriftgröße: Buttons, Checkboxen, Labels, Ränder Größenverhältnis visueller Objekte ist wesentlich für den Gesamteindruck ! (Schrift/Komponente, Komponente/Freifläche) Buttons abhängig von Fenstergröße belegen nur sinnlos Fläche (beliebter Fehler bei Java-Programmierern) sofern man die Schriftgröße überhaupt variabel gestaltet

3.5 Dynamisches Layout 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

3.5 Dynamisches Layout Layout-Raster skizzieren
F S S,T Rest Icongröße max(I,S) Abstände u. Ränder =f(Schriftgröße) Fehler S Fenstergröße Schriftgröße u. Textlänge F(0.5) klicken Sie um die Skizze aufzubauen

3.5 Dynamisches Layout 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 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 Koordinaten in Pixel) das Auge ist sehr empfindlich ! Analyse  Gestaltung  Konstruktion

3.5 Dynamisches Layout 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 und/oder mehrere geschachtelte Panels feste und variable Zellengrößen frei kombinierbar

3.5 Dynamisches Layout Komponentengröße beeinflussen
Eigenschaften von Component können vom LayoutManager berücksichtigt werden setMinimumSize, setPreferredSize, setMaximumSize gleiche Größe für mehrere Komponenten: jComp2.setPreferredSize (jComp1.getPreferredSize()); PreferredSize eines Buttons ist z.B. abhängig von der Schriftgröße dieser Default wird durch explizites Setzen (Wert != null) zerstört manche Layout-Manager respektieren manche Attribute: Minimum Preferred Maximum BorderLayout eine Richtung BoxLayout X X X FlowLayout X GridBagLayout (X) fill hat Vorrang (X) GridLayout Führungselement Preferred wenn der Platz reicht, sonst Minimum

3.5 Dynamisches Layout Versuch mit geschachtelten Layouts
Grid- und Box- in BorderLayout kaum einzuhalten offenes Problem: variable Breite NORTH: 1 horizontale Box CENTER: GridLayout 1 Zeile, 2 Spalten EAST: vertikale Box WEST: entfällt SOUTH: 3 horizontale Boxen in 1 vertikalen Box erfordert Feinjustage mittels preferredSize

3.5 Dynamisches Layout besser mit GridBagLayout
alle Zellen in Zeilen 0,2,3,4: fill=HORIZONTAL Zeile horizontale Box; gridwidth=3 Grid; fill= HOR. gridwidth=2 fill=BOTH gridwidth=2 fill=BOTH 1 2 3 4 Spalte: 0 1 2 3 4 größte preferredSize setzt sich durch

3.5 Dynamisches Layout Hörsaalübung
Skizzieren Sie das Layout-Raster und wählen Sie geeignete Layout-Manager ! Notepad Editor Bearbeiten, Schriftart Datei, Seite einrichten Bearbeiten, Suchen DScript Autor Suchen Update, Verzeichnispfade Konfiguration, Betriebsart "Vorlesung" Windows Explorer Extras, Ordneroptionen Windows Taschenrechner Eigenschaften von Anzeige Darstellung, Farbauswahl Windows Media Player im Design "Business"

3.5 Dynamisches Layout Anmerkung 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 Größe von Buttons besser nicht mittels setPreferredSize manipulieren: die Größe ist damit festgelegt und orientiert sich nicht mehr an Schriftgröße und Textinhalt ?Bug? beim Erben des Font zusätzliche Aufrufe erforderlich für JComboBox setPrototypeDisplayValue(null) für deren CellRendererPane setFont(font)

3.6 Software-Ergonomie Begriffe (1)
Teilgebiet der Mensch-Computer-Interaktion (human computer interaction HCI) berücksichtigt Psychologie und Physiologie des Benutzers Software-Ergonomie bezieht sich primär auf Bildschirm-Arbeitsplätze z.B. vorgeschrieben in Bildschirmarbeitsverordnung (1996, Gesundheitsschutz bei Arbeit an Bildschirmen) übertragbar auf vielerlei Software, Themen nach wie vor aktuell aktueller unter der Bezeichnung Usability  auch für Websites, Mobile Devices, Embedded Systems, ...

3.6 Software-Ergonomie Begriffe (2)
Usability / Gebrauchstauglichkeit ISO definiert Gebrauchstauglichkeit als "das Maß, in dem ein Produkt von bestimmten Benutzern benutzt werden kann um bestimmte Ziele in einem bestimmten Umfeld effektiv, effizient und zufriedenstellend zu erreichen" effektiv: Ziel wird genau und vollständig erreicht effizient: Aufwand im Verhältnis zum Ergebnis zufriedenstellend: Wohlbefinden, positives Gefühl bei Benutzung Usability Engineering (vgl. Software Engineering) alle Aktivitäten im Produktlebenszyklus, die der Verbesserung der Usability dienen; iterativer Prozess

3.6 Software-Ergonomie Ergonomische Normen
Standards versus Innovation haben immer nur Richtliniencharakter ergonomischer und technischer Gestaltungsspielraum keine Normung eines Softwareproduktes es gibt nicht "den" Benutzer; Benutzerrollen müssen individuell charakterisiert werden Rahmenbedingungen (z.B. Arbeitsorganisation, Arbeitsumgebung) sind unterschiedlich sollen keine bestimmte Implementierung nahelegen enthalten meist nur Mindestanforderungen Vorschriften und Checkliste helfen nur begrenzt – entscheidend ist die Sensibilität für Benutzerbelange notwendig, aber nicht hinreichend

3.6 Software-Ergonomie Normen zur (Software-)Ergonomie
 h_da Bibliothek online 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 - 7: Anforderungen an visuelle Anzeigen bezüglich Reflexionen - 8: Anforderungen an Farbdarstellungen - 9: Anforderungen an Eingabemittel, ausgenommen Tastaturen sehr praxisorientiert und reichhaltig illustriert: hoch aktuell durch Verbreitung von Notebooks !

3.6 Software-Ergonomie Normen zur Software-Ergonomie
enthalten die folgenden 7 Prinzipien 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 Usability

3.6 Software-Ergonomie (1a) Aufgabenangemessenheit
Bietet das System die "richtigen" Funktionen ? orientiert an der (Arbeits-)Aufgabe, nicht an der Technik erforscht mittels Anwendungsszenarien bzw. Use Cases Unterstützung gängiger Arbeitsabläufe Bedienfolgen, Assistenten, Workflow (ggf. mit Anleitung) Einfachheit statt Featuritis nicht Benötigtes muss der Benutzer gedanklich herausfiltern Gewichtung: häufiges einfach, seltenes aufwändiger Nachrangiges erst auf zusätzlichen Knopfdruck keine unnötigen Informationen anzeigen "Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d. h., wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren, anstatt auf der zur Aufgabenerledigung eingesetzten Technologie."

3.6 Software-Ergonomie (1b) Aufgabenangemessenheit
Effizienz, Antwortzeiten, sinnvolle Vorgabewerte am schnellsten ist eine vermiedene Eingabe Direktheit: kurze Wege zur Information / Funktion mehrere Dialogebenen  Karteireiter  Assistenten geschachtelte Pulldown-Menüs Anzahl Mausklicks, Weglänge zur Position, Wechsel zur Tastatur flexible + schnelle Navigation: Querverweise (Orientierung?!) Unterstützung für wiederkehrende Aufgaben Formatierung übertragen, Makro(-recorder), Tastatursteuerung

3.6 Software-Ergonomie (2a) Selbstbeschreibungsfähigkeit
nicht zu verwechseln mit Dokumentation 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 "Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können."

3.6 Software-Ergonomie (2b) Selbstbeschreibungsfähigkeit
aktuellen Zustand und Kontext darstellen Kontextinformationen (z.B. Verzeichnispfad bei Datei öffnen) 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 lassen sich "drücken" bereichs-/objektabhängig veränderlicher Mauscursor

3.6 Software-Ergonomie (2c) Selbstbeschreibungsfähigkeit
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 Anwender- und problemkompatible Terminologie Begriffe, Befehle, Fehlermeldungen Begriffe aus Anwendungsdomäne aufgreifen (wie reden künftige Benutzer über ihre Arbeit ?)

3.6 Software-Ergonomie (3) Steuerbarkeit
kein "Eigenleben" des Systems, Benutzer ist der Chef beenden ohne "wollen Sie wirklich ?" freie Eingabereihenfolge auch bei Validierung von Eingabewerten (Validierung auf Fensterebene, nicht auf Elementebene) mehrstufige Rückgängig- (Undo-) Funktion Dialogfolgen und längere Abläufe jederzeit abbrechbar dem Arbeitstempo angepasste Steuerungsformen Menü  Toolbar  Tastatur "Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist."

3.6 Software-Ergonomie (4a) Erwartungskonformität
im Widerspruch zu Originalität und Innovation ?! leider wird es oft nur schlechter ... 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) Erforschung: Gehwegplanung mittels Trampelpfad auf Gras "Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht."

3.6 Software-Ergonomie (4b) Erwartungskonformität
Wiedererkennbarkeit und Konsistenz Einsatz von Steuerelementen für typische Aufgaben Checkbox für einzelnes boolean (schließt kein Fenster) Radiobuttons als Gruppe gegenseitig auslösend Standarddialoge verwenden Datei öffnen/speichern, Farbauswahl, Schriftauswahl, Seite einrichten, Drucken typische Mauszeiger-Formen schlechte Beispiele Strg+Alt+Del zum Anmelden Start  Beenden gute Lösungen fallen nicht auf

3.6 Software-Ergonomie (5) 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 Anwender- und problemkompatible Terminologie kann man das Problem visualisieren? Möglichkeiten zur Fehlerbehebung vorsehen Rückgängig/Undo, Abbrechen, Papierkorb Zustandsanzeige Standarddialog JOptionPane ist zu einfach "Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann."

3.6 Software-Ergonomie (6) Individualisierbarkeit
kein Ersatz für sorgfältig abgestimmte Grundeinstellung ! Anpassung an persönliche Benutzungshäufigkeit Gewohnheiten aus anderen Anwendungen persönliches Systemumfeld konfigurierbare Toolbars und Menüs eigene Teilmenge definieren; eigene Funktionen als Makros Favoriten, Last Used, Most Used Zeitabhängigkeiten Erscheinen von Tooltips, Doppelklick, Repeat-Funktion individuelle Einstellungen sichern und "mitnehmen" auf anderen Rechner oder bei SW-Upgrade Anpassung macht Arbeit mal was neues: konfig. Fokussteuerung "Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen."

3.6 Software-Ergonomie (7) Lernförderlichkeit
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 bei (nicht vor) der Arbeit lernen "Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet."

3.7 Usability Inspection Evaluation der Usability
Systematische Evaluation von Prototypen (mangels fertigem Produkt) durch QS-Abteilung: Usability Inspection vgl. Code Inspection im Software Engineering Prüfung gegen Richtlinien und Checklisten durch echte Benutzer: Usability Test Benutzer urteilen subjektiv und unbewusst wichtig: ohne jede Erläuterung / Beeinflussung kann sehr aufwändig werden zum Glück genügen oft schon wenige Test-Benutzer, um die Hauptprobleme zu identifizieren messbare Kriterien suchen subjektiv  objektiv, qualitativ  quantitativ, pauschal  konkret Probleme aus der Anwendungsdomäne werden leichter übersehen

3.7 Usability Inspection Methoden der Usability Inspection
Heuristische Auswertung einige wenige erfahrene Inspektoren prüfen (einzeln!) gegen eine kurze Checkliste allgemeiner Regeln siehe nächste Folie vgl. die 7 Grundsätze der Dialoggestaltung im Abschnitt 3.6 auch für neuartige Ansätze geeignet Cognitive Walkthrough kleine Gruppe spielt typische Anfängeraufgaben durch Richtlinien Prüfung oder Wertung einzelner Inspektor prüft/wertet gegen detailliertes Regelwerk wird leicht stupide

3.7 Usability Inspection Checkliste für Heuristik
System Status erkennbar was passiert gerade? System und reale Welt passen Begriffe, Konzepte, Metaphern Steuerbarkeit und Freiheit Notausgang, Undo, Redo Konsistenz und Standards Einheitlichkeit der Begriffe, Konventionen der Plattform Fehlervermeidung Auswahl statt Eingabe; Zustands-abhängigkeiten vermeiden Erkennbarkeit statt Erinnerung (Kurzzeit-)Gedächtnis nicht beanspruchen Flexibilität und Effizienz Tastaturkürzel, Makros, Bearbeiten früherer Befehle Ästhetisches und minimalistisches Design keine unnötigen Informationen zeigen; weniger ist mehr Erkennung, Diagnose und Behebung von Fehlern Problembeschreibung im Klartext, Lösungsvorschlag Hilfe und Dokumentation aufgabenorientiert, keine reine Replikation der Oberfläche frei nach Keith Andrews: "Human-Computer Interaction"

3.8 Usability Test Vorbereitung des Tests
Testgegenstand festlegen (der Prototyp, ggf. Teilbereich) Test-Moderator organisiert den Test und wertet ihn aus Mitarbeiter der Qualitätssicherung oder UI-Designer, nicht Entwickler ggf. zusätzliche Test-Beobachter zur Unterstützung Test-Benutzer führen den Test durch und werden beobachtet entsprechen idealer weise den Stereotypen mehrere/viele Personen pro Stereotyp für statistische Auswertungen Testumgebung (Usability Lab) vorbereiten Beobachtung und Protokollierung der Benutzer-Aktivitäten Eye Tracking Systeme, Mouse Capture, Screen Capture Aufgabenstellung formulieren ganze Anwendungsszenarien und gezielte Teilaufgaben (vorab selbst testen) Testkritierien definieren (evtl. nur Teilaspekte) messbare und vergleichbare Daten besser einer als keiner

3.8 Usability Test Prototypen
Handskizzen genügen: "Paper Prototyping" horizontaler Prototyp vertikaler Prototyp Funktionsumfang Funktionsumfang Tiefe der Funktio- nalität ganze Oberfläche mit nichts darunter kleiner Ausschnitt komplett realisiert

3.8 Usability Test Eröffnung
Moderator begrüßt Test-Benutzer stellt sich und die Beobachter nur mit Namen vor keine Titel, keine Information über Rolle im Projekt oder über Beziehung zum Produkt erläutert Zweck des Tests: Sammlung von Infos zur Verbesserung der Benutzungsschnittstelle betont: das System wird getestet, nicht der Benutzer das System ist neu und kann fehlerhaft arbeiten erklärt, was und wie aufgezeichnet wird fordert Test-Benutzer auf, Fragen zu stellen die Fragen werden aber erst nach dem Test beantwortet weist Test-Benutzer auf jederzeitige Abbruchmöglichkeit hin lässt Vertraulichkeitserklärung und Einverständniserklärung zur Aufzeichnung unterschreiben

3.8 Usability Test Durchführung Thinking aloud – laut denken
Test-Benutzer spricht eigene Gedanken aus bei der Abarbeitung der Aufgabe was er tun will; was er liest; Fragen, die sich stellen; Verwirrendes; Entscheidungen Methode liefert massenhaft Informationen, auch unerwartete (besonders wertvoll !) Auswertung muss eventuelle Missverständnisse nicht aus Aktivitäten erraten Test-Moderator animiert nur zu lautem Denken Was tun Sie jetzt? Ich kann Sie nicht hören! Was denken Sie? Keinesfalls: Warum tun Sie das? Haben Sie jenes nicht gesehen?

3.8 Usability Test Durchführung Co-Discovery – zu zweit erforschen
zwei Test-Benutzer erforschen eine Oberfläche gemeinsam sie interagieren und kommunizieren dabei spontan das wird protokolliert vermeidet unnatürliche Situation des lauten Denkens aber: ist eine Benutzung zu zweit realistisch für die Anwendung?

3.8 Usability Test Durchführung Interviews und Fragebogen
Test-Benutzer soll zunächst frei reden später gezielte Fragen und Nachhaken zeitaufwändig, schwer zu vergleichen Fragebogen Erstellung ist eine Wissenschaft für sich kann eine große Zahl von Test-Benutzern erreichen leicht statistisch auswertbar liefert keine Antworten auf nicht gestellte Fragen ...

3.8 Usability Test Durchführung Observierung
Aufzeichnung typischer Aktivitäten im echten Betrieb Produktivbetrieb vorab mit Testern simulieren eventuell auch noch im Beta-Test Speicherung in Log-Datei ausgewählte Kenndaten mit Zeitstempel viele Test-Benutzer, statistische Analyse welche Features werden häufig / selten / nie genutzt ? Videoauswertung ist sehr zeitaufwändig Benutzer sind oft abgeneigt, fühlen sich ausspioniert erfordert intensive Aufklärung über das Verfahren Anonymisierung, keine persönlichen Daten, Abschaltbarkeit

3.8 Usability Test Auswertung (1)
Effizienz der Interaktion Wie lange dauert die Durchführung einer Aufgabe? Wie viele Aufgaben können in einer vorgegebenen Zeit durchgeführt werden? Welche Reaktionszeiten zeigen die Testpersonen? Welche Aktionen treten besonders häufig auf? Wie häufig treten ineffiziente Interaktionen auf? Welche Strecke/Fläche wird mit den Augen abgesucht? Welche Strecke wird mit der Maus zurückgelegt? Wie viele Klicks werden benötigt, um eine Aufgabe zu lösen? Zeit Fein- motorik

Auftreten von Bedienfehlern Wie viele Aktionen sind erfolgreich bzw. fehlerhaft? Welche Bedienfehler treten besonders häufig auf? Wie lange dauert die Korrektur von Bedienfehlern? Wie viele positive/negative Kommentare werden geäußert? Wie groß ist der Anteil der Test-Benutzer, der eine Aufgabe richtig/schnell genug/auf optimalem Weg durchgeführt hat? Wie viele Kommandos (von den verfügbaren) werden genutzt? Wie oft und wie lange werden Anleitungen oder andere Hilfsmittel studiert?

Erlernbarkeit Wie lange braucht ein Test-Benutzer, um die Durchführung einer Aufgabe zu lernen? Wie ist die Vergessenskurve für die Anwendung nach einer bestimmten Zeit (Tage, Wochen, Monate)? Subjektive Zufriedenheit Wie fühlt sich der Benutzer / die Benutzerin mit der Software? sollte erfragt und dokumentiert werden

4. Java 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 zur Geschwindigkeitssteigerung: Just-In-Time-Compiler übersetzt Byte Code in Maschinencode der Zielhardware Hotspot VM tut dies partiell für häufig durchlaufenen Code

4. Java Dateitypen und Tools
Bibliotheken LIB H class jar auch IDE mit GUI-Editor mindestens eine Klasse enthält main h Editor java Compiler class Virtual Machine java class Editor Compiler

4. Java Java Development Kit (JDK)

4. Java Entwicklung nur 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=Pfad1;Pfad2 oder auch SET CLASSPATH=. damit die Java VM weiß, wo sie die Anwendungsklassen suchen soll JAVA MeineKlasse oder auch JAVA -classpath Pfad1;Pfad2 MeineKlasse Aufruf der Java Virtual Machine (Interpreter) MeineKlasse muss eine Methode main enthalten

Visuelle Objekte Klassenstruktur WindowBuilder Quellcode Editor
4. Java IDE Eclipse Visuelle Objekte "Java-Bean" Klassenstruktur "Gliederung" WindowBuilder mit Kompo- nenten-Palette Quellcode Editor vgl. Visual Studio, NetBeans, JBuilder, Rational Application Developer

4.1 Programmtypen Das einfachste Java-Programm
public class HelloCon { // muss in Datei HelloCon.java public static void main(String[] args) { System.out.println ("Hello, World!"); } siehe Beispiel ApplCon jede .java-Datei muss genau ein public Klasse enthalten 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 in String[] args werden Kommandozeilenparameter übergeben

4.1 Programmtypen 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: void toString() neu: System.out.printf wie in C

4.1 Programmtypen Die einfachste GUI-Applikation
siehe Beispiel ApplMin Hauptfensterklasse abgeleitet von JFrame (extends) Klassen-Methode static main erzeugt ein einziges Objekt wird nur in temporärer Referenz gespeichert Schließen des Fensters ist Standardmethode setDefaultCloseOperation sorgt für Beenden der Java VM Alternative zum Beenden der Java VM: System.exit JPanel wird erzeugt und mit JFrame.setContentPane zugeordnet Attribut setzen: setLayout=null; JLabel wird erzeugt und mit JPanel.add zugeordnet

4.1 Programmtypen HelloWorld Klassendiagramm
JFrame MainWindow JPanel JLabel erbt von Komposition: notwendiges Teil Aggregation: optionales Teil Assoziation: kennt

4.1 Programmtypen 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 wird dann die Referenz auf das Hauptfenster in Eclipse GUI-Applikationen nicht gespeichert ? main ist gleich 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

4.1 Programmtypen Seitenblick: Applet
siehe Beispiel Applet zur Einbettung in eine HTML-Seite meist nur für "kleine" Aufgaben – Downloadzeit bedenken ! inzwischen weitgehend von Adobe Flash und HTML+JavaScript verdrängt 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)

4.1 Programmtypen Applets und Sicherheit
Applets aus dem Web sind Code unbekannter Programmierer der Programmierer könnte böse Absichten haben Beschränkungen zur Sicherheit der Nutzer ein Applet wird in einer "Sandbox" ausgeführt, d.h. es 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

4.2 Grundlagen für Umsteiger 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 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 Ableitung wollten Sie doch schon immer 

4.2 Grundlagen für Umsteiger 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 macht das Laufzeitsystem, wann es will Destruktor gibt es nicht stattdessen Methode protected void finalize(); Aufruf vor dem Garbage Collector – d.h. unter Umständen nie ! 

4.2 Grundlagen für Umsteiger Initialisierung von Variablen
automatisch initialisiert werden Klassenvariable (=static) Instanzvariable (=Attribute) Array-Komponenten 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 die Initialisierung zu vergessen ist eine beliebte Fehlerquelle in C++

4.2 Grundlagen für Umsteiger Zugriffsrechte
public, protected, private (fast) wie in C++ protected ermöglicht auch Zugriff aus eigenem Package jedes Element muss sein eigenes Zugriffsrecht haben Definition gilt (im Gegensatz zu C++) nicht für die folgenden ohne Angabe bedeutet: private für Klassen public für Interfaces für Attribute und Methoden nur innerhalb des eigenen Packages verfügbar nicht in abgeleiteten Klassen statt friend in C++

4.2 Grundlagen für Umsteiger Datentypen
plattformunabhängig definiert Primitive Typen byte (8 Bit), short (16 Bit), int (32 Bit), long (64 Bit), alle als vorzeichenbehaftete 2er-Komplementdarstellung char (16 Bit vorzeichenlos, Unicode) float (32 Bit), double (64 Bit); beide IEEE Standard 754 jetzt auch enum; früher Klassen mit Konstanten (static final int) Referenztypen "Zeiger" für Klassen, Interfaces, Arrays C++ macht dagegen keinen Unterschied zwischen primitiven Typen und Klassen neue primitive Typen werden in C++ als Klassen realisiert (CBruch, CComplex, CString) ab Version 1.5 / 5.0 verfügbar

4.2 Grundlagen für Umsteiger Zeichenketten: String
Klasse String (ähnlich wie STL string) char* gibt es nicht ! Operator + zur Verkettung akzeptiert Werte beliebiger Typen oder Objekte beliebiger Klassen als Operand; verwendet Methode toString Besonderheit: Operator + allokiert implizit einen neuen String == ist Referenz- (d.h. Pointer-) Vergleich s1.equals(s2) vergleicht Textinhalte 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

4.2 Grundlagen für Umsteiger Arrays
ein Sprachkonstrukt: Klasse mit spezieller Syntax  sicher durch Indexprüfung zur Laufzeit vgl. Container in STL, CArray in MFC dynamisch allokierte Objekte float[] vector = new float[3]; float[][] matrix = new float[3][3]; int[] x = {1, 2, 3, 4, 5}; Parameterübergabe als Objekt-Referenz Zugriff wie gewohnt vector[2] = 5.3; matrix[0][1] = vector[2]; for (int i=0; i<vector.length; i++) { vector[i] = 0; } Array ist eigentlich 1-dimensional Array.clone() klont bei n-dimensionalen Arrays nur 1 Dimension Größe wird zur Laufzeit festgelegt und ist dann nicht mehr änderbar

4.2 Grundlagen für Umsteiger Ausnahmebehandlung
wie in C++, aber: throw-Deklaration im Funktionskopf ist ein Muss der Compiler erzwingt es (ausgenommen RuntimeException) alle möglichen Ausnahmen sollten auch eingefangen werden nur für Objekte von Klassen, die von Throwable abgeleitet sind hat als direkte Unterklassen: Error (Systemfehler, nicht behandeln) und Exception (Anwendungsfehler, behandeln) finally-Block hinter try...catch wird in jedem Fall ausgeführt anwendbar beispielsweise zum Freigeben von Ressourcen in C++ macht das der Destruktor automatisch Exception-Konstruktoren haben i.a. String als Parameter kann mit e.getMessage() zurückgewonnen werden

4.2 Grundlagen für Umsteiger 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.Vector; alle Klassen: import java.util.*; alle Klassen mit Kurzreferenz: import java.util; Kurzreferenz ist dann: util.Vector; weltweit eindeutige Namen für wichtige Packages package de.h-da.fbi.projekt.meinpackage; spiegelt die Schachtelung der Ordner wider

4.3 Weitere Details zu Java Zeiger versus Referenzen
Java Referenzen entsprechen gesicherten 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 Objekte werden immer per "call by reference" übergeben primitive Typen immer per "call by value" 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

4.3 Weitere Details zu Java Typumwandlung (cast)
Typumwandlung zwischen primitiven Typen ist wohldefiniert nicht einfach andere Interpretation des Bitmusters keine beliebigen Casts zwischen irgendwelchen Datentypen Typumwandlung zwischen Objektreferenzen wird zur Laufzeit überprüft nur die Umwandlung zwischen Basisklasse und abgeleiteter Klasse ist zulässig

4.3 Weitere Details zu Java Interface
Spezialfall einer abstrakten Klasse ein Interface ist eine abstrakte Basisklasse ohne Elementvariablen, besteht also ausschließlich aus abstrakten Methoden (abstract = pur virtuell in C++) Konstantendefinitionen (public final static) lokalen Klassen ein Interface kann anstelle einer Klasse zur Typisierung von Variablen und formalen Parametern verwendet werden 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 kann dann auf Objekte von Klassen zeigen, die dieses Interface implementieren

4.3 Weitere Details zu Java 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 Klasse, die als final markiert ist, kann nicht mehr als Basisklasse dienen (Anonyme) innere Klassen siehe Kapitel 6. Ereignisbehandlung

4.3 Weitere Details zu Java Mutter aller Klassen: class Object
alle Klassen sind implizit von class Object abgeleitet public class Object { // liefert Textdarstellung des Objekts: public String toString() {...} // vergleicht Objekt-Inhalte: public boolean equals(Object obj) {...} // dupliziert das Objekt: protected Object clone() //  Kopierkonstruktor aus C throws CloneNotSupportedException {...} // Aufruf vor der Garbage Collection: protected void finalize() throws Throwable {...} }

4.3 Weitere Details zu Java plattformunabhängig ?
alter Informatikertraum gut: Wertebereiche primitiver Datentypen 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 Java SE, Java EE, Java ME

4.3 Weitere Details zu Java sicher ?
etliche Methoden mittlerweile "deprecated", weil "inherently unsafe" z.B. Thread.stop(), Runtime.runFinalizersOnExit(...) Ausführungszeitpunkt von finalize und garbage collector undefiniert  Echtzeitanwendungen 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) Swing ist nicht thread safe Programmierer machen in jeder Sprache Fehler... 

4.4 Collection-Klassen Collection-Klassen
die Größe ist (im Gegensatz zum Array) auch nach der Erzeugung noch änderbar vgl. Standard Template Library STL in C++ JDK 1.0: Vector, Stack, Dictionary, Hashtable, BitSet Enumeration (unübliche Bezeichnung für Iterator); thread safe JDK 1.2: List, Set, Map empfohlen Iterator; nicht thread safe mehrere Implementierungen (als Array, als verkettete Liste) "thread safe" bedeutet: bequem, sicher, aber langsam vergeudet Performance wenn nur in einem Thread verwendet Elemente vom Typ Object d.h. von beliebiger Klasse wegen impliziter Typkonversion einfache Datentypen nur über Wrapper-Klassen (Integer für int, Double für double, ...) primär zu diesem Zweck eingeführt

4.4 Collection-Klassen Wrapper-Klassen
Klassen Integer, Long, Double ... kapseln einfache Datentypen int, long, double ... Anwendungen Elemente von Collection-Klassen Datentyp mit null-Wert in Datenbankanwendungen Reflection-API Ermittlung der Klasse gegebener Objekte zur Laufzeit nicht geeignet für call by reference Parameter, da "immutable" dafür muss man bei Bedarf eigene Wrapper-Klassen schreiben Automatische Umwandlung bei Bedarf Autoboxing / Autounboxing bei Wrappern Methode equals anstelle von == verwenden ! VM kann gleiche Zahlen durch ein Objekt darstellen (da "immutable"), muss es aber nicht Wert kann nicht verändert werden

4.4 Collection-Klassen Interface Iterator
zum Abarbeiten aller Elemente einer Collection abstrahiert Endebedingung und Fortschalteoperation einer Schleife Nachfolger der veralteteten "Enumeration" (unüblicher Name) Collection liefert Objekt einer passenden Iterator-Klasse Iterator i = c.iterator(); Methoden boolean hasNext(); // vgl. Enumeration.hasMoreElements() Object next(); // vgl. Enumeration.nextElement() void remove(); // fehlt in Enumeration Anwendung while (i.hasNext()) verarbeite(i.next());

4.4 Collection-Klassen Klassenhierarchie
kurios: einige Methoden sind optional, d.h. sie dürfen beim Aufruf eine Exception werfen ... diese Klassen sind zur Anwendung vorgesehen

4.4 Collection-Klassen AbstractList implements List
geordnete Liste von Elementen Zugriff wahlfrei per Index 0 .. n-1 sequentiell Implementierungen ArrayList: sich bei Bedarf erweiterndes Array schneller wahlfreier Zugriff; Einfügen/Entfernen langsam LinkedList: doppelt verkettete Liste wahlfreier Zugriff langsam; Einfügen/Entfernen schnell add(index, value); get(index); set(index, value);

4.4 Collection-Klassen AbstractSet implements Set
ungeordnete Menge kein Element doppelt - basierend auf Object.equals() wird beim Einfügen verhindert spätere Änderung eines Elements kann Set ungültig machen Implementierung HashSet add(value); contains(value); remove(value); Vereinigungsmenge: addAll(set); Schnittmenge: retainAll(set); im Mittel gleicher Aufwand für Einfügen, Löschen und Zugriff

4.4 Collection-Klassen AbstractMap implements Map
assoziativer Speicher bildet Schlüssel auf Werte ab Einfügen eines Schlüssel-Wert-Paares, dessen Schlüssel bereits vorhanden ist, überschreibt den bisherigen Wert Implementierung HashMap get(key); put(key, value); Iterator verfügbar über values().iterator(); "Collection View" Speicherort wird mit Hash-Funktion berechnet; kollidierende Elemente werden dort in verketteter Liste abgelegt Hash key

4.4 Collection-Klassen Generics: typsichere Collections
seit Java 5 kann die Klasse der Elemente definiert werden früher generell class Object, i.a. per Typecast gewandelt auch weiterhin möglich (Generics sind optional) keine einfachen Datentypen als Elemente; dazu weiterhin Wrapper Überprüfung zur Compile-Zeit Typecast wird überflüssig nicht verwechseln mit C++ Templates ! ArrayList<Integer> a = new ArrayList<Integer>(50); for (int i=0; i<5; i++) a.add(i, new Integer(i)); Iterator<Integer> it = a.iterator(); while (it.hasNext()) { Integer I = it.next(); System.out.println(I); } for (Integer I : a) System.out.println(I); oder Autoboxing Schleife mit Iterator neue for-Schleife statt Iterator

4.5 Dateien und Streams Streams / Datenströme
im Package java.io Abstraktion für sequentielle Ein-/Ausgabe bzw. Kommunikation (vgl. C++) Datei, Netzwerk, anderer Thread einheitliches Zugriffsprinzip Einlesen: Stream öffnen while (Daten im Stream) Daten lesen Stream schließen Ausgeben: Stream öffnen while (Programm liefert Daten) Daten schreiben Stream schließen D P D P

4.5 Dateien und Streams Byte- und Character-Streams
Byte-Streams abstrakte Basisklassen InputStream und OutputStream Byte-weises Lesen und Schreiben von Binärdaten Audio, Video, Bilder, Executables Character-Streams abstrakte Basisklassen Reader und Writer Lesen und Schreiben von Text, d.h. 16 Bit Unicode-Zeichen Zugriff aus verschiedenen Threads ist möglich (synchronized) ähnliche Methoden für beide Varianten Konstruktor öffnet den Stream Methode close schließt den Stream wenn close-Aufruf fehlt, tut es der Garbage Collector via finalize Datentyp byte Datentyp char

4.5 Dateien und Streams Lesen aus Streams
int read() liest einzelnes Byte/Zeichen und liefert es als Ergebnis ab int read(byte/char cbuf[]) liest verfügbare Bytes/Zeichen in Array cbuf berücksichtigt Länge des Arrays liefert Anzahl gelesener Bytes/Zeichen als Ergebnis int read(byte/char cbuf[], int offset, int length) liest maximal length Bytes/Zeichen in cbuf, beginnend an Position offset alle liefern –1 wenn das Ende des Streams erreicht ist leider keine benannte Konstante endOfStream o.ä. werfen ggf. IOException

4.5 Dateien und Streams Schreiben in Streams
void write(int c) schreibt Byte/Zeichen c in den Stream void write(byte/char cbuf[]) schreibt alle Bytes/Zeichen aus cbuf in den Stream void write(byte/char cbuf[], int offset, int length) schreibt length Bytes/Zeichen aus cbuf in den Stream, beginnend an Position offset void write(String str) nur in Klasse Writer void flush() gibt Pufferinhalt sofort aus (sofern Stream gepuffert ist)

4.5 Dateien und Streams Spezialisierte Streams
Byte-Streams Character-Streams Datei FileInputStream FileOutputStream FileReader FileWriter Arbeitsspeicher ByteArrayInputStream ByteArrayOutputStream CharArrayReader, StringReader CharArrayWriter, StringWriter Thread-Kommunikation PipedInputStream PipedOutputStream PipedReader PipedWriter Ausgabeformat PrintStream (System.out) PrintWriter zusätzliche Pufferung BufferedInputStream BufferedOutputStream BufferedReader BufferedWriter Zeilen zählen LineNumberInputStream LineNumberReader Konvertierung (Zeichensatz) InputStreamReader liest Bytes, liefert Characters OutputStreamWriter bekommt Char., schreibt Bytes I/O-Medien Filter

4.5 Dateien und Streams Beispiel: Kopieren einer Textdatei
File inputFile = new File("Source.txt"); File outputFile = new File("Destination.txt"); FileReader in = new FileReader(inputFile); FileWriter out = new FileWriter(outputFile); int c = in.read(); while (c != -1) { out.write(c); c = in.read(); } in.close(); out.close(); zum Kopieren einer Binärdatei einfach ersetzen durch FileInputStream FileOutputStream

4.5 Dateien und Streams Zerlegen von Texten: Scanner
 Beispiel "Einlesen einer CSV-Datei" 4.5 Dateien und Streams Zerlegen von Texten: Scanner zerlegt Text in einfache Datentypen und Strings anhand von regulären Ausdrücken Scanner s = new Scanner( new BufferedReader( new FileReader("Input.txt"))); einfachen Datentyp extrahieren boolean hasNextDouble() double nextDouble() String mit Trennzeichen extrahieren void useDelimiter(String pattern) String next() verbessert die Performance Alternative falls das Format festliegt: DataInputStream

4.5 Dateien und Streams Wahlfreier Datei-Zugriff
siehe auch java.nio für systemnahe Zugriffe 4.5 Dateien und Streams Wahlfreier Datei-Zugriff Lesen und Schreiben an beliebiger Position, nicht nur sequentiell verwaltet mittels gemeinsamen read/write-FilePointer Klasse RandomAccessFile (kein Stream!) Öffnungsmodus: r = nur Lesen, rw = Lesen und Schreiben übliche read- und write-Methoden zusätzlich readType und writeType mit Type = Boolean, Char, Float, Int, ... long getFilePointer() liefert aktuellen Wert des FilePointer seek(long pos) positioniert FilePointer auf pos haben Streams nicht

4.6 Serialisierung Serialisierung / Deserialisierung
Umwandlung von Objekten in einen Stream (und zurück) insbesondere auch Referenzen auf andere Objekte verschiedene Streamformate sind möglich Bytestream nur maschinenlesbar, kompakt, effizient verarbeitbar im Trend: XML-Format notfalls vom Menschen lesbar, selbstdokumentierend großer Speicherbedarf aufwändiges Generieren und Parsen (aufwändig für die Maschine, unaufwändig für Entwickler durch vorgefertigte Klassen) Anwendungsbereiche Persistente Speicherung (typischerweise in Dateien) für Datenbanken wird man Objekte eher in Datensätze abbilden Übertragung im Netz (remote procedure call, Verteilte Systeme)

4.6 Serialisierung Serialisierung in C++
Serialisierung gibt es in den meisten Sprachen mit spezieller Syntax oder als reguläre Bibliothek z.B. Bibliotheken für C++ passend zur STL Boost Serialization libs11n Sweet Persist z.B. integriert in MFC mit Unterstützung für MFC-Container

4.6 Serialisierung Interface java.io.Serializable
"Markierungsschnittstelle" (definiert keine Methoden) class MeineKlasse implements Serializable "implements Serializable" bedeutet nur: Entwickler gibt sein OK zur Serialisierung dieser Klasse Vorsicht, wenn die Superklasse nicht serialisierbar ist ! alle Unterklassen sind zwangsläufig serialisierbar vergleichbar mit einer versteckten impliziten Basisklasse, denn wenn die Standard-Implementierung nicht passt, kann man überschreiben: private void writeObject(ObjectOutputStream out) private void readObject(ObjectInputStream in) private void readObjectNoData() // Initialisierung im Sonderfall Object writeReplace() // ersetzen durch anderes Objekt Object readResolve()

4.6 Serialisierung Standard-Implementierung in Java
serialisiert Informationen über die Klasse, aber nicht die Klassendefinition selbst serialisiert in einen Bytestream serialisiert alle nicht-transienten und nicht-statischen Elemente serialisiert referenzierte Objekte rekursiv vorausgesetzt, deren Klasse ist ebenfalls serialisierbar kann auch mit zyklischen Referenzen umgehen transiente Elemente werden bei der Deserialisierung mit ihrem parameterlosen Konstruktor initialisiert class Point implements Serializable { int x, y; transient float rho, theta; } = nicht persistent

4.6 Serialisierung Praktischer Einsatz
Serialisieren FileOutputStream f = new FileOutputStream("datei.ser"); ObjectOutputStream s = new ObjectOutputStream(f); s.writeObject("Today"); // ruft string.writeObject s.writeObject(new Date()); s.flush(); // optional: Puffer ausgeben s.close(); Deserialisieren FileInputStream in = new FileInputStream("datei.ser"); ObjectInputStream s = new ObjectInputStream(in); String today = (String)s.readObject(); Date date = (Date)s.readObject(); Typ muss man wissen

4.6 Serialisierung Portabilität serialisierter Objekte
serialisierte Objekte setzen passende Version der Klasse voraus Swing-Objekte sind serialisierbar, aber nicht auf eine andere Version der Java VM (d.h. der Swing Bibliothek) übertragbar Kompatibilität wird erkannt anhand einer Versionsnummer explizit vom Entwickler verwaltet: private static final long serialVersionUID = 27L; alternativ implizit von Java ermittelt Vorsicht: stark compilerabhängig ! InvalidClassException bei unterschiedlichen Versionen

4.6 Serialisierung Mögliche Probleme
Serialisierung kann heikel sein wenn die Semantik des Objektzustands umgebungsabhängig ist z.B. Thread-Objekt nur sinnvoll in der aktuellen Virtual Machine z.B. Klasse zur Kapselung einer Datenbank das Objekt sensible private Elemente beinhaltet, z.B. Passworte unterschiedliche Versionen der Klasse bei Seriali- sierung und Deserialisierung eingesetzt werden Serialisierung ist i.a. unproblematisch bei reinen Datenklassen mit kurzer Persistenz nicht für Langzeitarchivierung wegen Abhängigkeit von der Version der Klasse und der Virtual Machine Alternative: "handgemachtes" versioniertes (Datei-)Format mit Fallunterschei-dung beim Einlesen  Externalizable

4.6 Serialisierung Interface java.io.Externalizable
für Sonderfälle: flexibler, aber aufwändiger das Objekt ist für seine Ein-/Ausgabe selbst zuständig keine Standard-Implementierung "normales" Interface: definiert Methoden, die implementiert werden müssen void readExternal (ObjectInput in) void writeExternal (ObjectOutput out) formal ein Subinterface von Serializable interface Externalizable extends Serializable

4.6 Serialisierung Marshalling / Unmarshalling
zur Abgrenzung und Einordnung allgemeinere Problemstellung Serialisierung ist ein Sonderfall anordnen / arrangieren von Daten zwecks Austausch zwischen Programmiersprachen Austausch zwischen Prozessen z.B. CORBA, RMI, Microsoft COM, Mozilla XPCOM Ziel: Plattform- und Sprachunabhängigkeit Byte Ordnung (little-endian, big-endian) Wortbreite (32 Bit, 64 Bit) Repräsentation von Gleitkommazahlen Repräsentation von Zeigern

statisches Layout  Definition von Koordinaten
4.7 Entwurfsphase mit statischem Layout Dynamische und statische Layouts Visual C++ 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

4.7 Entwurfsphase mit statischem Layout Vorgehensweise beim Entwurf
Java unterstützt dyn. Layout mit Layout-Managern Container-Klassen haben default Layout-Manager wir bauen als Vorstufe zunächst statische Layouts vergleichbar der Arbeitsweise mit MS Visual C++ entscheidende 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 unüblich in Java

4.7 Entwurfsphase mit statischem Layout Starter-Applikation
ausgehend von einer Eclipse Applikation mit Hauptfenster abgeleitet aus JFrame wird eine geeignete Größe für das Hauptfenster gesetzt das BorderLayout durch null (= absolute layout) ersetzt für alle visuellen Komponenten die Größe und Platzierung im Design-Editor manuell festgelegt das Beispiel "die einfachste GUI-Applikation" kann als Ausgangspunkt für das Praktikum dienen

4.8 GUI Klassenstruktur Architektur für kleine GUI-Anwendungen
Trennung von GUI, Programmlogik und Datenhaltung vgl. Model / View / Controller Architektur (MVC) View + Controller implementiert durch Fensterklassen View: Generierung der Widgets im Konstruktor Controller: Event-Handler als Methoden Model implementiert durch "normale" Klasse(n) wird ggf. persistent durch Serialisierung oder kapselt Datenbank Partitionierung / Modularisierung der GUI orientiert an Screens und Blöcken innerhalb von Screens Kapselung spezieller Hardware durch eigene Klasse(n) z.B. Elektronik des Fernsehers (Tuner, Verstärker, ...) Konkretisierung der Domänen- modellierung aus OOAD

4.8 GUI Klassenstruktur Model / View / Controller – Architektur
übliche Darstellung angepasst für OO-GUIs View GUI-Objekte Controller Ereignisbehandlung Model (Geschäftslogik) Datenhaltung View Controller Model

4.8 GUI Klassenstruktur Beispiel Model / View
Änderungen der Daten aktualisieren alle Sichten Mehrere Sichten auf gemeinsames Datenmodell

4.8 GUI Klassenstruktur Beispiel Model / ViewController
oft zusammen Beide Sichten sind interaktiv und ermöglichen eine Änderung der Daten Daten- bank

4.8 GUI Klassenstruktur Situation mit Eclipse WindowBuilder
generiert Widgets und deren Attribute im Konstruktor referenziert manche Widgets als Instanzvariable (JTextField), manche im Konstruktor als lokale Variable (JButton) registriert Event-Handler im Konstruktor (add...Listener) wird schnell chaotisch ... Zugriff aus Handlern auf das Fenster und manche Widgets ist schwierig aufräumen ! private JTextField txtInput; public MainWindow() { ... txtInput = new JTextField(); txtInput.setColumns(10); contentPane.add(txtInput); JButton btnOK = new JButton("OK"); btnOK.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent a) { } }); contentPane.add(btnOK); }

4.8 GUI Klassenstruktur Alle Widgets zu Instanzvariablen
Problem: lokale Variable im Konstruktor sind aus Event-Handlern nicht erreichbar z.B. für btnOK.setEnabled to do: im WindowBuilder sofort sinnvolle Namen für jedes Widget eintragen to do: alle lokalen Widget-Referenzen zu Instanzvariablen machen private JTextField txtInput; private JButton btnOK; public MainWindow() { txtInput = new JTextField(); txtInput.setColumns(10); contentPane.add(txtInput); JButton btnOK = new JButton("OK"); btnOK.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent a) { } }); contentPane.add(btnOK); }

4.8 GUI Klassenstruktur Handler als Methoden der Fensterklasse
to do: neue Methode anlegen widgetName_eventName hat Zugriff auf this und alle Widget-Referenzen hier wird der "Nutzinhalt" des Handlers implementiert außerhalb des Konstruktors to do: neue Methode aus ActionListener aufrufen bei Bedarf das Event-Objekt als Parameter übergeben private JTextField txtInput; private JButton btnOK; public MainWindow() { ... JButton btnOK = new JButton("OK"); btnOK.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent a) { btnOK_actionPerformed(); } }); contentPane.add(btnOK); } protected btnOK_actionPerformed() { }

4.8 GUI Klassenstruktur Statische GUI im Konstruktor verstecken
die Erzeugung der Widgets, deren Verknüpfung (add) und deren Attribute verbleiben im Konstruktor to do: Konstruktor "zuklappen" und "nicht mehr anschauen" GUI nur per WindowBuilder weiterentwickeln to do: try ... catch in jedem Handler einfügen private JTextField txtInput; private JButton btnOK;  public MainWindow() { ... } private btnOK_actionPerformed() { try { // "Nutzinhalt" des Handlers } catch (Exception e) { e.printStackTrace(); }

4.8 GUI Klassenstruktur Zugriff auf Model-Objekt
gilt entsprechend für HW-Kapselungsklasse die Model-Klasse wird in main instanziiert Beispiel siehe nächste Folie oder im Konstruktor der Hauptfensters eine Referenz auf das Model-Objekt wird Instanzvariable der Hauptfensterklasse via Hauptfenster-Objekt in Panelklassen verfügbar alternativ: Model-Referenz als public static Variable  nicht viel besser als eine globale Variable alternativ: Model als Singleton ok wenn es nur wenige Singletons im System gibt; sonst auch nicht viel besser als eine globale Variable

4.8 GUI Klassenstruktur main-Methode in Hauptfensterklasse
wird so von Eclipse generiert; kann man beibehalten Start der Anwendung == Öffnen des Hauptfensters alternativ: eine eigene Klasse "Applikation" mit main und Instanziierung von Model und HW-Kapselung public Model model; public static void main(String[] args) { EventQueue.invokeLater( new Runnable() { public void run() { try { MainWindow frame = new MainWindow(); frame.model = new Model(); frame.setVisible(true); } catch (Exception e) { e.printStackTrace(); } });

4.8 GUI Klassenstruktur Partitionierung der GUI
für komplexe Screens FrameMain extends JFrame PanelBottom extends JPanel PanelRight extends JPanel DialogConfig extends JDialog GUI Blöcke als eigene von JPanel abgeleitete Klassen in der Fensterklasse JPanel per WindowBuilder einfügen im Code manuell ersetzen durch abgeleitete Panel-Klasse Referenz auf FrameMain per Konstruktorparameter durchreichen an Panelklassen als Owner für DialogConfig Nebenwirkung im WindowBuilder akzeptieren:

4.8 GUI Klassenstruktur Klassendiagramm
Quellcode in DScript  Beispiele  Programmtypen  GUI Struktur

4.8 GUI Klassenstruktur Reaktionszeit und Event Queue
Wichtige Anforderung: die GUI muss jederzeit auf Benutzereingaben reagieren wenn bestimmte Funktionen (vorübergehend) nicht verfügbar sind, muss das dem Benutzer zumindest visualisiert werden alle GUI Aktivitäten werden sequentiell im Event Dispatching Thread ausgeführt insbesondere paint/repaint und alle Handler das erspart dem Programmierer die explizite Synchronisation Konsequenz: die Laufzeit der einzelnen Handler muss kurz sein (sonst "friert die GUI ein" und reagiert nicht auf Eingaben)

4.8 GUI Klassenstruktur Kurze Aktivitäten mit Wait-Cursor
was ist "kurz"? eine Faustregel: wenige 10 Millisekunden: ohne besondere Anzeige bis 1 Sekunde: Cursor "Sanduhr" zeigen mehr als 1 Sekunde: Worker Thread und JProgressBar Realisierung der "Sanduhr" mit Component.setCursor und Klasse Cursor: setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR)); // eigentliche Aufgabe des Handlers setCursor(Cursor.getDefaultCursor());

4.8 GUI Klassenstruktur Längere Aktivitäten im Worker Thread
siehe DScript  Beispiele  Programmtypen  Swing und Worker Threads Vorgehensweise Klasse Worker von Thread ableiten benötigte GUI-Objekte als Konstruktorparameter durchreichen run() überschreiben, darin die Aktivität implementieren Zugriff auf GUI-Objekte mittels SwingUtilities.invokeLater(...) invokeLater benötigt Instanzen von Hilfsklassen, die das Interface Runnable implementieren Zugriff auf GUI-Objekte ausschließlich in run() dieser Hilfsklassen statt Thread Synchronisation: invokeLater platziert Hilfsklasse.run() wie einen Handler in die Event Queue des Event Dispatching Thread weitere Möglichkeiten:

5. Fenster, Dialoge, Container GUI-Bibliotheken in Java SE
AWT - Abstract Window Toolkit verwendete Steuerelemente des Host-Betriebssystems "native widgets"  plattformabhängig schon wieder veraltet (gut, dass Sie es nicht lernen mussten...) 1.1 veränderte gegenüber 1.0 die Ereignisbehandlung fundamental (Listener statt virtueller Funktionen: ermöglicht Beans) SWT - Standard Widget Toolkit für IBM Eclipse, ebenfalls "native widgets" JFC/Swing - Java Foundation Classes rendert mit Java, verwendet nur grafische Primitive des Host-OS austauschbares "Look & Feel" (Java, Windows, Motif, Mac, ...) zum Download: sehr sauber strukturierte Klassenbibliothek, vielfältig erweiterbar nicht thread safe, deshalb Aufrufe in Event Queue auslagern die verwenden wir !

5. Fenster, Dialoge, Container Weitere Features von JFC/Swing
beliebige Schachtelung von Container-Objekten Standarddialoge JFileChooser, JColorChooser Model-View-Controller (MVC) Architektur auf der Ebene der Steuerelemente (Components) Accessibility Support: Unterstützung für Behinderte Sprachein-/ausgabe, Braille-Zeile etc. Interface Action zur Bündelung der Aktionen mehrerer Steuerelemente z.B. Menüpunkt + Toolbar Icon + Hotkey: Multiple Document Interface

5. Fenster, Dialoge, Container Container
sind die „Bauplätze”, auf denen die Bedienelemente aufgebaut werden eigenständige Fenster JFrame, JWindow, JDialog eingebettet in HTML-Seite: JApplet Unterteilung von Fenstern JPanel JScrollPane, JSplitPane, JTabbedPane, JToolBar Multiple Document Interface JDesktopPane, JInternalFrame (behandeln wir nicht)

5. Fenster, Dialoge, Container Top Level Container
JFrame, JWindow, JDialog, JApplet haben eine contentPane, die andere Panels oder Komponenten trägt sind Wurzel eines Objektbaums können eine Menüleiste (JMenuBar) tragen werden normalerweise als Basisklassen genutzt WindowBuilder leitet für jedes Fenster eine Unterklasse ab wir arbeiten i.a. nur mit der contentPane und nutzen weitere Panels/Panes zur räumlichen Gliederung

5. Fenster, Dialoge, Container Bereits bekannt: JFrame
Hauptfenster von Applikationen; normalerweise nur ein einziges JFrame-Objekt pro Anwendung ! mit Fenstertitel, Rand und Min/Max-Schaltflächen eigene Hauptfenster-Klasse deklarieren public class MainWindow extends JFrame {...} Fensterobjekt erzeugen (meist in function main) MainWindow thisFrame = new MainWindow(); Layout neu berechnen ohne Layout-Manager: thisFrame.setSize(...); thisFrame.validate(); mit Layout-Manager: thisFrame.pack(); Fenster sichtbar machen thisFrame.setVisible(true); Fenster schließen thisFrame.setDefaultCloseOperation(int); JWindow hat das nicht; für weitere unabhängige Fenster der Anwendung EXIT_ON_CLOSE HIDE_ON_CLOSE (default) DISPOSE_ON_CLOSE DO_NOTHING_ON_CLOSE

5.1 Panels und Panes Räumliche Gliederung
Panel Tafel, Platte, (vertieftes) Feld Pane (Fenster)Scheibe Komponenten werden gruppiert und platziert 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 für Panels und Panes ist normalerweise keine Ereignisbehandlung erforderlich

5.1 Panels und Panes JPanel: einfache Fläche
Fläche, die andere Komponenten trägt bekanntes Beispiel: contentPane JPanel meinPanel = new JPanel(); Layout-Manager zuordnen oder weglassen default ist FlowLayout meinPanel.setLayout(new BorderLayout()); // dynamisches Layout meinPanel.setLayout(null); // statisches Layout Komponenten zuordnen meinPanel.add(aComponent); Umrandung (Border) definieren Freiflächen und Abstände sind als EmptyBorder realisierbar Erstellung wird durch Eclipse komfortabel unterstützt  (unbedingt generierten Code ansehen !)

5.1 Panels und Panes Rand und Abstand mit Border
Interface Diverse Klassen abgeleitet von AbstractBorder LineBorder, EtchedBorder, BevelBorder, EmptyBorder, MatteBorder, TitledBorder, CompoundBorder Implementierung als benanntes Objekt EtchedBorder myBorder = new EtchedBorder(); meinPanel.setBorder(myBorder); anonymes Objekt meinPanel.setBorder(new EtchedBorder()); gemeinsam verwendetes anonymes Objekt meinPanel.setBorder(BorderFactory.createEtchedBorder());

5.1 Panels und Panes 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 empfohlen für komplexe Komponenten

5.1 Panels und Panes 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));

5.1 Panels und Panes JTabbedPane: Karteikarten mit Reitern
organisiert mehrere Panes "hintereinander" und mittels Karteireiter 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)

5.1 Panels und Panes CardLayout: reiterlose Karteikarten
eigentlich keine Pane, sondern ein Layout-Manager 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);

modale Dialoge blockieren das Hauptfenster, solange sie aktiv sind
5.2 Dialoge Überblick ein Dialog ist ein separates Fenster, das über dem Hauptfenster (oder einem anderen Dialog) schwebt 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 Dialoge erlauben die Aktivierung des Hauptfensters Beispiel: Editieren während "Suchdialog" in Textverarbeitung MessageBox ist einfache Form eines modalen Dialogs

für beide Arten: modal + moduslos JDialog (Frame owner, boolean modal)
5.2 Dialoge JDialog für beide Arten: modal + moduslos JDialog (Frame owner, boolean modal) auch Dialog statt Frame möglich setVisible(true) macht den Dialog sichtbar blockiert in modalen Dialogen terminiert sofort in moduslosen Dialogen validate() oder pack() notwendig um Layout neu zu berechnen setVisible(false) macht den Dialog unsichtbar hebt die Blockierung von setVisible (true) in modalen Dialogen auf zerstört nicht das Dialogobjekt: man kann danach noch auf seine Daten zugreifen

5.2 Dialoge JOptionPane: Standard-Dialoge
gängige modale Einfach-Dialoge Aufruf durch diverse static Methoden von JOptionPane: showMessageDialog, showInputDialog, showConfirmDialog diverse Icons zur Verschönerung per Konstante wählbar Button-Kombinationen ebenfalls per Konstante wählbar Auswahl des Benutzers wird Ergebnis der Methodenaufrufe vergleichbar mit MessageBox unter Windows etwas vergleichbares fehlt in AWT weitestgehende Konfigurationsmöglichkeit mittels showOptionDialog

5.2 Dialoge 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

5.2 Dialoge Datenübergabe
public class MeinDialog extends JDialog { private JButton OK = null; private JTextField Text = null; public MeinDialog(Frame owner, String Vorgabe) { super(owner, true); initialize(); Text.setText(Vorgabe); } private JButton getOK() { if (OK == null) { OK = new JButton(); OK.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { OK_actionPerformed(); } // this wäre hier ActionListener }); return OK; private void OK_actionPerformed() { this.setVisible(false); public String getTexteingabe() { return Text.getText(); public class Hauptfenster extends JFrame { private JButton jButton = null; private JButton getJButton() { if (jButton == null) { jButton = new JButton(); jButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { jButton_actionPerformed(); } // this wäre hier ActionListener }); } return jButton; private void jButton_actionPerformed() { MeinDialog d = new MeinDialog(this, "Hallo"); d.setVisible(true); System.out.println(d.getTexteingabe()); Initialisierung Rückgabe 221

5.3 Dynamisches Layout Layout-Manager in Swing
Java unterstützt dynamisches Layout durch verschiedene Layout-Manager-Klassen weil einfach einsetzbar, werden sie in Java eher zu oft verwendet fehlen unter Windows / MFC (könnte man selbst schreiben) verfügbar in .NET seit 2.0 (FlowLayoutPanel, TableLayoutPanel) 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 unsichtbarer Komponenten

5.3 Layout-Manager Überblick

5.3 Layout-Manager "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: Alignment: CENTER, LEFT, RIGHT Hgap, Vgap: Lücke zwischen Komponenten leider auch vor/über erster und hinter/unter letzter Komponente (wirkt wie Rand, allerdings nicht bei Zeilenumbruch)

5.3 Layout-Manager 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

5.3 Layout-Manager Zeile oder Spalte: BoxLayout
senkrechte oder waagrechte Reihe Ausrichtung jeder Komponente individuell wählbar setAlignmentX/Y (0.0=linksbündig =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

5.3 Layout-Manager BoxLayout Programmfragment
JPanel panel = new JPanel(); 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()); panel.add(jButton3);

5.3 Layout-Manager 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

5.3 Layout-Manager BorderLayout Programmfragment
JPanel panel = new JPanel(); 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);

5.3 Layout-Manager 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

5.3 Layout-Manager GridLayout Programmfragment
JPanel panel = new JPanel(); 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) panel.add(jButton1); // Komponenten zeilenweise ... panel.add(jButton2); // von links oben ... panel.add(jButton3); // nach rechts unten ... panel.add(jButton4); // hinzufügen panel.add(jButton5); variable Zeilenzahl

5.3 Layout-Manager Universell: GridBagLayout
1 2 1 2 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 aber jede Komponente bekommt ein eigenes GridBagConstraints-Objekt (reine Datenstruktur) zugeordnet vgl. HTML-Table

5.3 Layout-Manager GridBagLayout Programmfragment
JPanel panel = new JPanel(); 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); panel.add(jButton1); gc.weightx = 0.5; gc.gridx = 1; gc.gridy = 2; gbl.setConstraints(jButton2, gc); panel.add(jButton2); wird darin geklont (=kopiert) !  nicht dokumentiert; muss man im Quellcode nachlesen

5.3 Layout-Manager GridBagConstraints (1)
werden jeder einzelnen Komponente zugeordnet int gridx, int gridy adressiert 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) Padding = Innenabstand (d.h. Inhalt der Komponente  Rand) vergrößert die Minimalgröße der Komponente um 2*ipadx/y

5.3 Layout-Manager GridBagConstraints (2)
Insets insets (default new Insets (0,0,0,0)) Margin = Außenabstand (d.h. Rand der Komponente  Grid) 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 ) prozentuale Verteilung von freiem Platz auf Spalten bzw. Zeilen (max. weightx innerhalb Spalte bzw. max. weighty innerhalb Zeile gilt bei Konflikt zwischen mehreren Zellen)

5.3 Layout-Manager Weitere Layout-Manager
GroupLayout SpringLayout sehr mächtig und sehr elementar nicht für manuelle Programmierung empfohlen gedacht für GUI-Builder eingesetzt in NetBeans IDE

5.3 Layout-Manager Gemischt: statisch und dynamisch
eine Anwendung kann dynamische und statische Layouts in verschiedenen Fenstern bzw. Panels gemischt einsetzen interessant in der Übergangsphase vom statischen Entwurf zur dynamischen Konstruktion i.a. sind dann "äußere" Fenster dynamisch und "untergeordnete" Panels statisch für untergeordnete statische Panels müssen MinimumSize, PreferredSize und MaximumSize definiert werden statische Layouts haben dafür kein Default statische Layouts werden nicht sichtbar, wenn diese Werte nicht definiert sind ! 

6. Ereignisbehandlung Konsoledialoge
vgl. PG1 / PG2 DOS Box / Konsole / UNIX Shell als Bedienoberfläche 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-Antwort-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 der Benutzer reagiert auf die Fragen des Computers der Benutzer bedient den (= dient dem) Computer vgl. "der Kellner bedient den Gast" 

6. Ereignisbehandlung Ereignisorientierte Programmierung
Bei Programmen mit grafisch-interaktiven Benutzungsoberflächen kann die Reihenfolge der Eingaben beliebig variiert werden Eingabewerte können auch nachträglich geändert werden Neuberechnungen oder Berechnungsvariationen sind einfach möglich aus Sicht des Entwicklers erfordert 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 das Programm dient dem Benutzer 

6. Ereignisbehandlung Ereignisbegriff
Ereignisse (events) werden (meist) vom Benutzer ausgelöst, direkt oder indirekt 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 Behandlung erfolgt durch Ausführung eines "Handlers" (d.h. Funktion bzw. Methode) vgl. die Botschaft (message) unter Windows informiert über das Ereignis und enthält die Zusatzinformationen wParam und lParam

6. Ereignisbehandlung 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

6. Ereignisbehandlung 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 bisher kein Standard; jede Bibliothek macht es anders

6. Ereignisbehandlung bei Komponenten
ActiveX Control feuert Ereignis an MS Access "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 ein (normalerweise) visuelles Steuerelement stellt Eigenschaften, Methoden und Ereignisse bereit kann mit der umgebenden Anwendung kommunizieren liegt als fertig kompilierte jar- bzw. ocx-Datei vor Zuordnung Ereignis  Handler wird zur Laufzeit festgelegt erfordert dynamische Liste von Funktionszeigern oder Objekten; in Java: mit Methode add...Listener(Listenerobjekt)

6. Ereignisbehandlung Systemvergleich
Visual Basic, Lingo (Director), OpenScript (ToolBook) Zuordnung durch Verwendung vordefinierter Handlernamen jedes (Steuer-)Element hat eigenes Skript Director: on mouseUp, on exitFrame gemeinsames Skript für ganzes Formular Visual Basic: Sub ButtonXyz_Clicked() Windows API Callback-Funktion mit Ereigniscode Windows MFC (veraltet) Funktionszeiger über MessageMap zugeordnet typischerweise beim übergeordneten Fenster sehr übersichtlich: Tabelle bleibt verborgen  "Tabelle" als switch-Anweisung Tabelle sichtbar, leicht zu ignorieren

6. Ereignisbehandlung in Java AWT 1.0 (veraltet)
Basisklasse ruft für jedes Ereignis eine virtuelle Funktion auf die virtuelle Funktion wird in der abgeleiteten Anwendungsklasse vom Programmierer mit dem Handler überschrieben ähnlich wie das bekannte void processWindowEvent(WindowEvent e) {...} Nachteil: Zuordnung Ereignis  Handler zur Compile-Zeit festgelegt; keine Beans möglich

6. Ereignisbehandlung seit Java AWT 1.1 : Listener
streng OO flexibel unübersichtlich benötigt werden eigentlich Zeiger auf Funktionen gibt es nicht in Java (rein objektorientiert) 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 (z.B. ActionListener)

6. Ereignisbehandlung Listener und Adapter
manche Listener-Interfaces definieren etliche Methoden oft braucht man aber nur eine oder wenige 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) {} } d.h. nicht für Instanziierung gedacht

6. Ereignisbehandlung 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() { public void actionPerformed(ActionEvent e) { // Nutzinhalt des Handlers } } ); hat vollen Zugriff auf alle Variablen der umschließenden Klasse entfällt (Kurzschreibweise) AnonymeKlasse implements

6. Ereignisbehandlung Innere Klasse im Vergleich zu C++
Problem: keine Mehrfachvererbung, keine Freunde in Java MeinFrame abgeleitet von JFrame MeinListener abgeleitet von irgendeinem Adapter Listener soll Zugriff auf die Elemente von MeinFrame haben in C++ würde MeinFrame MeinListener zum Freund erklären oder MeinListener von MeinFrame und von Adapter abgeleitet werden nicht schön, denn ein Listener ist kein Frame  Ausweg: Listener als innere Klasse von MeinFrame Listener oft als einzige Instanz einer anonymen (namenlosen) Klasse realisiert

6. Ereignisbehandlung Observer-Pattern zum Vergleich
Observer-Pattern allgemein angewandt auf Listener

6. Ereignisbehandlung So macht es Eclipse
private JButton getQuit() { if (Quit == null) { Quit = new JButton(); Quit.setText("Quit"); Quit.addActionListener( new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println("TODO:actionPerformed()"); System.out.println(Quit.getText()); } ); return Quit; Handler mit Initialisierung vermischt Zugriff auf Fenster, aber this verweist auf Listener

6. Ereignisbehandlung So machte es JBuilder
private void jbInit() throws Exception { Quit.addActionListener( new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { Quit_actionPerformed(e); } ); void Quit_actionPerformed(ActionEvent e) { // Nutzinhalt; z.B. Messagebox zeigt Button-Beschriftung JOptionPane.showMessageDialog(this, Quit.getText()); Variante 1 im Beispiel vgl. Visual Basic: eine Methode pro Komponente und Ereignis Handler getrennt von Initialisierung voller Zugriff auf Fenster

6. Ereignisbehandlung Fenster als Listener seiner Komponenten
import java.awt.event.*; public class Fenster extends JFrame implements ActionListener { private void jbInit() throws Exception { Quit.addActionListener(this); } public void actionPerformed(ActionEvent e) { if (e.getSource()==Quit) // oder e.getActionCommand() auswerten // Handler für Button Quit else // Handler für andere Komponenten } } Variante 4 im Beispiel gemeinsamer Handler für alle Komponenten

6. Ereignisbehandlung zum Vergleich: MFC (1)
Ressourcendefinition wird mit grafischem Editor erstellt Windows erzeugt daraus unmittelbar die Steuerelemente MFC stellt Wrapper-Klassen zum Zugriff aus C++ bereit IDD_EVENT_DIALOG DIALOGEX 0, 0, 80, 70 STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION CAPTION "Event" FONT 8, "MS Sans Serif" BEGIN PUSHBUTTON "Increment",IDC_INCREMENT,7,7,66,14 EDITTEXT IDC_DISPLAY,7,28,66,14,ES_CENTER | ES_READONLY | NOT WS_TABSTOP PUSHBUTTON "Quit",IDC_QUIT,7,49,66,14 END

6. Ereignisbehandlung zum Vergleich: MFC (2)
class CEventDlg : public CDialog { public: CEventDlg():CDialog(IDD_EVENT_DIALOG) {} protected: virtual bool OnInitDialog() { CDialog::OnInitDialog(); return true; } void OnIncrement() { ... } void OnQuit() { EndDialog (IDCANCEL); } DECLARE_MESSAGE_MAP() }; BEGIN_MESSAGE_MAP(CEventDlg,CDialog) ON_BN_CLICKED(IDC_INCREMENT,OnIncrement) ON_BN_CLICKED(IDC_QUIT,OnQuit) END_MESSAGE_MAP() die MessageMap verknüpft das Ereignis (hier "ButtonClicked") eines Steuer-elements (identi-fiziert per ID) mit seinem Handler ist eine statische Tabelle und wird vom Assistenten generiert

6. Ereignisbehandlung zum Abschluss: Visual Basic
Private Sub FormEvent_Initialize() TextBox.Value = 0 End Sub Private Sub ButtonIncrement_Click() TextBox.Value = TextBox.Value + 1 Private Sub ButtonQuit_Click() Me.Hide grafische Attribute erscheinen überhaupt nicht im Programm kaum objektorientiert mäßig flexibel genial einfach manchmal kommt man schon ins Grübeln ...

7. Bausteine grafischer Bedienoberflächen Begriffe
Begriffe uneinheitlich Windows: Control / Steuerelement Motif: Widget Java: Component / Komponente Begriffsverwirrung: SW-Komponenten heißen dafür Beans visuelle Klassen Objekte zeichnen sich selbst auf den Bildschirm Erscheinungsbild und Verhalten über Attribute einstellbar vorzugsweise mittels WindowBuilder Ereignisbehandlung teilweise im Zusammenspiel mit übergeordnetem Fenster große Auswahl in Bibliotheken, Eigenkreation möglich

7. Bausteine grafischer Bedienoberflächen Swing Components in Eclipse
Schalt- flächen Textfelder Auswahl 1 aus n

7. Bausteine ... Klassenhierarchie

7.1 Schaltflächen 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 bei JButton permanent bei den anderen (durch Gruppierung auch 1 aus n) AbstractButton JButton JToggleButton Aktion Zustand JCheckBox JRadioButton

7.1 Schaltflächen JButton: löst nur Aktion aus
Schaltfläche beschriftet mit Text und/oder Icon setText(String); setIcon(ImageIcon); Ereignisse: actionPerformed(ActionEvent) // beim Anklicken I/O: keine Methoden: setEnabled(boolean); setVisible(boolean); setActionCommand(String); // wird Attribut von ActionEvent getRootPane().setDefaultButton(JButton); // übergeordnete Pane high level event

7.1 Schaltflächen JToggleButton: Zustand + Aktion
wie JButton, aber mit Zustandsanzeige "gedrückt" (= selected) Ereignisse: actionPerformed(ActionEvent) // beim Anklicken itemStateChanged(ItemEvent) // bei Zustandswechsel I/O: isSelected()  boolean ItemEvent.getStateChange()  SELECTED / DESELECTED Methoden: setSelected(boolean); setEnabled(boolean); setVisible(boolean); setActionCommand(String); // wird Attribut von ActionEvent

7.1 Schaltflächen JCheckBox: Wahrheitswert-I/O
wie JToggleButton, aber mit Zustandsanzeige "Häkchen" (= selected) Ereignisse: actionPerformed(ActionEvent) // beim Anklicken itemStateChanged(ItemEvent) // bei Zustandswechsel I/O: isSelected()  boolean ItemEvent.getStateChange()  SELECTED / DESELECTED Methoden: setSelected(boolean); setEnabled(boolean); setVisible(boolean); setActionCommand(String); // wird Attribut von ActionEvent funktional identisch, anderes Aussehen

7.1 Schaltflächen JRadioButton: Auswahl 1 aus n
wie JCheckBox, tritt aber typischerweise in Gruppen auf Gruppe mit gegenseitiger Auslösung: ButtonGroup grp = new ButtonGroup(); grp.add(jRadioButton1); grp.add(jRadioButton2); logisch: Auswahl 1 aus n (n konstant !) Ereignisse: actionPerformed(ActionEvent) // beim Anklicken I/O: ActionEvent.getActionCommand()  String Methoden: setActionCommand(String); // wird Attribut von ActionEvent setSelected(boolean); etc. möglich für alle Buttontypen, aber unüblich

7.2 Textfelder Textfelder: Charakterisierung
Textfelder dienen der Ein- und Ausgabe von Text sie integrieren einfache oder komplexe Editorfunktionen Cursor Selektion Kopieren, Einfügen mehrzeilige Textfelder können scrollen, wenn die Fläche nicht ausreicht können inaktiv (disabled) sein JTextComponent einzeilig mehrzeilig Editor für Text, HTML und RTF mit Formatierung JTextfield JTextArea JEditorPane JPasswordField JTextPane behandeln wir nicht

7.2 Textfelder 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 start, int end), selectAll() // markiert (selektiert) Text Konvertierung: int Zahl = Integer.parseInt(TextFeld.getText()); TextFeld.setText(String.valueOf(Zahl)); entsprechend für Byte, Double, Float, Long, Short Behandlung von Formatfehlern vorsehen! Wrapper-Klassen für einfache Typen

7.2 Textfelder JTextArea: mehrzeilige I/O
beliebiger, aber einheit- licher Font für Ein- oder Ausgabe von mehrzeiligen Texten kann scrollen, wenn innerhalb einer JScrollPane platziert: JTextArea ta = new JTextArea(5,80); JScrollPane scp = new JScrollPane(ta); contentPane.add(scp); 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

7.2 Textfelder Wertebereichsüberprüfung
"action validated" Überprüfung des eingegebenen Werts, nachdem "Return" gedrückt wurde Zwischenstände bei der Eingabe spielen keine Rolle und dürfen "falsch" sein  bequem zu Editieren im actionPerformed-Handler vor der Weiterverarbeitung "change validated" Inhalt eines Textfeldes muss jederzeit korrekt sein "Zwischenstände" beim Editieren werden ständig kontrolliert je nach Eingabesyntax ist eine Korrektur durch den Benutzer mit einem Zeichen gar nicht möglich  Software muss korrigieren im keyTyped-Handler

7.3 Auswahllisten Auswahllisten: Charakterisierung
Lineare, ungegliederte Liste oft besser als Textfeld mit Gültigkeitsüberprüfung Einfachauswahl (1 aus n) oder Mehrfachauswahl (m aus n) Vorteile gegenüber Gruppe aus Radiobuttons: große Zahl von Listenelementen ist möglich, aber: Überschaubarkeit und Suchaufwand für den Benutzer bedenken Listenelemente können zur Laufzeit geändert bzw. datenabhängig geladen werden ComboBox als platzsparende Variante Bedienung ist umständlicher

7.3 Auswahllisten JList: sichtbare Liste
Einfach- oder Mehrfachauswahl Strings oder Icons als Elemente ( ListCellRenderer für andere) Listenelemente aus Object[] oder DefaultListModel Konstantenliste am besten über String Werte[]={...}; kann scrollen, wenn innerhalb einer JScrollPane platziert Ereignis: boolean valueChanged(ListSelectionEvent) // Auswahländerung I/O: int, Object oder Array // Index oder ausgewähltes Objekt Methoden: boolean getValueIsAdjusting() // wird Auswahl noch geändert? (dynamisch) String

7.3 Auswahllisten 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

7.3 Auswahllisten JComboBox: ausklappbare Liste
"Dropdown Box" 7.3 Auswahllisten JComboBox: ausklappbare Liste nicht editierbar: Auswahl 1 aus n, auch Icons statt Text editierbar: wie Textfeld mit Vorgaben cb.setEditable(true); // false ist Standard statische oder dynamische Liste wie bei JList Ereignis: actionPerformed(ActionEvent) // Auswahl oder Return I/O: int oder Object ( String oder ImageIcon) Methoden: setSelectedIndex(int), int getSelectedIndex() // Index cb.getSelectedItem().toString() // Text (ImageIcon)(cb.getSelectedItem()) // Bild

7.3 Auswahllisten Dynamische Listen
bzw. einer Klasse die das Interface ListModel implementiert Änderung der Listenelemente zur Laufzeit erfordert Objekt der Klasse DefaultListModel 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(Listbox); contentPane.add(ScrollPane); Daten.addElement("neuer Eintrag"); Daten.insertElementAt("noch ein Eintrag", 5); Daten.removeElementAt(0); // oder removeElement(Object) DefaultComboBoxModel fast identisch für JList und JComboBox siehe auch class AbstractListModel

7.3 Auswahllisten ImageIcon: statische Bilder
nicht nur in Listen Buttons, Labels, Listen etc. können Icons darstellen Icons haben eine beliebige, aber feste Größe Darstellung von Bildern mit variabler Größe  Abschnitt "7.7 Grafik" Bilddateiformat GIF, JPEG oder PNG am einfachsten mit Bildbearbeitungsprogramm erstellen und in Datei ablegen GIF und PNG auch mit transparentem Hintergrund ("freigestellt") ImageIcon Bild = new ImageIcon("Verzeichnis/Bild.gif"); JLabel Label = new JLabel(); Label.setIcon(Bild); ImageIcon Bilder[] = { new ImageIcon("Bild0.gif"), new ImageIcon("Bild1.gif") }; JComboBox ComboBox = new JComboBox(Bilder); für JAR-Datei: this.getClass().getResource("...")

7.4 "Analogwerte" JSlider: analog mit Einrasten
nur grobe Einstellmöglichkeit per Maus wahlweise mit "Einrasten" bei Ticks: setSnapToTicks(true) 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);

7.4 "Analogwerte" JProgressBar: reine Anzeige
zur Anzeige länger dauernder Abläufe beruhigt den Benutzer Alternative: Klasse ProgressMonitor macht Dialog auf Ereignis: keines Output: void setValue(int) Eigenschaften: setMinimum(-20); setMaximum(80); setOrientation(JProgressBar.VERTICAL);

7.4 "Analogwerte" 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);

7.5 Komplexe Datenstrukturen Model / View / Controller – Architektur
übliche Darstellung angepasst für OO-GUIs View GUI-Objekte Controller Ereignisbehandlung Model (Geschäftslogik) Datenhaltung View Controller Model

7.5 Komplexe Datenstrukturen Beispiel Model / View
Änderungen der Daten aktualisieren alle Sichten Mehrere Sichten auf gemeinsames Datenmodell

7.5 Komplexe Datenstrukturen Beispiel Model / ViewController
oft zusammen Beide Sichten sind interaktiv und ermöglichen eine Änderung der Daten Daten- bank

7.5 Komplexe Datenstrukturen JTable: Charakterisierung
mehrspaltige Tabelle, Datenfelder editierbar Spalten in der Breite veränderbar und vertauschbar kann scrollen, wenn innerhalb einer JScrollPane platziert Spaltenüberschriften scrollen nicht mit ! Tabelle fester Größe durch Initialisierung mit Array verwendet Object[][] als Datenmodell Tabelle variabler Größe oder mit dynamischer Datenquelle über eigenes Datenmodell CellRenderer und CellEditor spaltenbezogen definierbar z.B. CheckBox für boolean, ComboBox für 1 aus n, Icon

7.5 Komplexe Datenstrukturen Model / View Architektur bei JTable
konsequente Trennung zwischen Datenhaltung und Sicht auf die Daten z.B. Datenhaltung: ArrayList von Arrays z.B. Sicht: 2-dim. Tabelle mit Spaltenüberschriften aufwändiger zu handhaben, aber flexibler Standard-Datenmodell für einfache Fälle Zusammenspiel von Model und View wird über Interfaces organisiert wird in Swing durchgängig eingesetzt (nicht nur bei JTable) Model-Klasse implementiert Interface TableModel Interface definiert Art des Zugriffs auf die Daten View-Klasse implementiert Interface TableModelListener Interface definiert Art der Information der Oberfläche über Änderungen ArrayList Arrays ArrayList ist ein Array variabler Länge

7.5 Komplexe Datenstrukturen Model / View als Observer-Pattern
Model/View-Architektur am Beispiel JTable als Observer-Pattern das bekannte Observer-Pattern

7.5 Komplexe Datenstrukturen Zugriff über Interface TableModel
Index der selektierten Zeile(n) holen jTable.getSelectionModel().getMinSelectionIndex() jTable.getSelectionModel().getMaxSelectionIndex() TableModel (Datenmodell) erhältlich mit: jTable.getModel() Methoden von TableModel: int getRowCount() int getColumnCount() Object getValueAt(int Zeile, int Spalte) Object setValueAt(Object, int Zeile, int Spalte) void addTableModelListener(TableModelListener l) so lässt sich JTable als Listener über Datenänderungen informieren

7.5 Komplexe Datenstrukturen Abstract Class AbstractTableModel
vereinfacht die Implementierung von TableModel verwaltet eine Liste von TableModelListener-Objekten (d.h. Views) nur dateninhaltsbezogene Methoden von TableModel müssen implementiert werden getRowCount, getColumnCount und getValueAt muss man selber schreiben zu diesem Zweck muss man endlich die Datenstruktur definieren setValueAt hat eine leere Implementierung für Read-Only-Daten bietet Methoden zur Information der Listener (=View)-Objekte über Änderungen der Daten fireTableCellUpdated, fireTableChanged, fireTableDataChanged, fireTableRowsDeleted, fireTableRowsInserted, fireTableRowsUpdated, fireTableStructureChanged

7.5 Komplexe Datenstrukturen JTree
für hierarchische Gliederung von Einträgen vgl. Kapitelstruktur eines Buches statisch (fester Inhalt) oder dynamisch (änderbar zur Laufzeit) Ereignis: valueChanged(TreeSelectionEvent e) Zugriff auf selektierten Eintrag: e.getPath().getLastPathComponent().toString() // Text TreePath jTree.getSelectionPath() // TreePath  Object[] (DefaultMutableTreeNode) // cast von Object (jTree.getSelectionPath().getLastPathComponent()) boolean isSelectionEmpty()

7.5 Komplexe Datenstrukturen DefaultMutableTreeNode
Standard-Knotentyp von JTree für statische und dynamische JTrees jedem Knoten kann ein beliebiges Object als "Inhalt" zugeordnet werden, z.B. im einfachsten Fall ein String mutable: Knoten können hinzugefügt, entfernt und geändert werden hat 1 übergeordneten Knoten (parent) Ausnahme: Wurzelknoten hat keinen parent hat ein "Array" von untergeordneten Knoten (children) werden senkrecht unter ihrem parent dargestellt Enumeration children(); int getChildCount(); TreeNode getChildAt(int childIndex); bietet diverse Enumerations (Iteratoren) zum Durchwandern des Unterbaums (preorder, postorder, breadthFirst, depthFirst)

7.5 Komplexe Datenstrukturen Tree als binärer Baum
weitere mögliche Sicht eines Tree Interface TreeNode: ein Knoten hat optional eine geordnete Liste von Unterknoten Klasse DefaultMutableTreeNode: ein Knoten hat optional einen Kind-Knoten und optional einen Geschwister-Knoten linker Unterknoten(-baum) verfügbar über getNextSibling() rechter Unterknoten(-baum) verfügbar über getFirstChild() + Name NextSibling FirstChild Knoten

7.5 Komplexe Datenstrukturen 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 model = new DefaultTreeModel(root); JTree jDynTree = new JTree(model); model.insertNodeInto(newNode, parent, parent.getChildCount()); model.removeNodeFromParent(selected);

7.6 Menüs Klassenhierarchie zu JMenu
alle MenuItems sind Buttons Flächen Knoten Blätter

7.6 Menüs 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 gut geeignet zum Erforschen einer unbekannten Anwendung relativ 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

7.6 Menüs Aufbau eines Menüs
ist in Eclipse am einfachsten in der Java Beans Ansicht aufzubauen 7.6 Menüs Aufbau eines Menüs Objekte erzeugen JMenu jMenuEdit = new JMenu(); JMenuItem jMenuItemCut = new JMenuItem(); Attribute setzen // weitere siehe Buttons jMenuEdit.setText ("Edit"); jMenuItemCut.setText ("Cut"); jMenuItemCut.setEnabled (false); Objekte verknüpfen jMenuBarMain.add (jMenuEdit); jMenuEdit.add (jMenuItemCut); jMenuBarMain.add (Box.createHorizontalGlue()); // nächstes rechts jMenuEdit.addSeparator (); // Trennlinie

7.6 Menüs JPopupMenu: Kontextmenü
verborgenes Menü belegt keine Bildschirmfläche, aber Benutzer muss suchen typischerweise für objektbezogene Funktionen verschiedene Objekttypen haben verschiedene Kontextmenüs Menüaufbau wie beim Hauptmenü JPopupMenu jPopupMenu = new JPopupMenu(); JMenuItem jMenuItemCut = new JMenuItem(); jMenuItemCut.setText ("Ausschneiden"); jPopupMenu.add (jMenuItemCut);

7.6 Menüs Kontextmenü-Ereignisbehandlung
Aufruf aus MouseListener des sensitiven Objekts void mouseReleased(MouseEvent e) { if (e.isPopupTrigger()) jPopupMenu.show( e.getComponent(), e.getX(), e.getY()); } Zugriff auf zugehöriges Objekt und MenuItem void actionPerformed(ActionEvent e) { JMenuItem actItem = (JMenuItem)e.getSource(); JPopupMenu actPopup = (JPopupMenu)actItem.getParent(); JObject angeklicktesObjekt = actPopup.getInvoker(); // irgendetwas damit machen } unter Windows und Motif mit rechtem Mausklick; für andere OS zusätzlich mousePressed

Menüs werden häufig ergänzt durch Toolbars
7.6 Menüs 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 gelernt werden ! eine gute Hilfe dazu sind Tooltips (d.h. Texte, die nur erscheinen, wenn die Maus auf dem Button verweilt)

für JAR-Datei: this.getClass().getResource("...")
7.6 Menüs JToolBar Objekte erzeugen JToolBar jToolBar1 = new JToolBar(); JButton jButtonCD = new JButton(); Attribute setzen jButtonCD.setIcon (new ImageIcon("Icons/img_cd.gif")); jButtonCD.setToolTipText ("CD abspielen"); Objekte verknüpfen (die contentPane muss ein BorderLayout haben) contentPane.setLayout(new BorderLayout()); // eigentlich default contentPane.add(jToolBar1, BorderLayout.NORTH); jToolBar1.add (jButtonCD, null); jToolBar1.addSeparator (); // Abstand einfügen für JAR-Datei: this.getClass().getResource("...")

7.7 Grafik Direkte Grafikausgabe
Painting: ein Teil der Benutzungsoberfläche wird durch eigenen Code gezeichnet z.B. Erstellung eigener Komponenten, Anzeige von Dokumenten, Visualisierung von Zuständen, ... (Neu-)Zeichnen kann vom System oder von der Anwendung veranlasst werden System: erstmalige Darstellung der Komponente, Änderung der Größe, Komponente war verdeckt und wird wieder sichtbar Anwendung: Änderung des visualisierten Zustands oder der visualisierten Daten  Anwendung ruft repaint() auf jegliche Grafikausgabe wird durch Überschreiben einer einzigen Methode implementiert void paintComponent(Graphics g) // für Swing-Komponenten void paint(Graphics g) // für AWT-Komponenten

Hilfsmittel zum Zeichnen: abstract class Graphics
7.7 Grafik Grafik Kontext Hilfsmittel zum Zeichnen: abstract class Graphics wird nicht instanziiert, sondern als Parameter an paint übergeben Clip: Fläche, die aktualisiert werden soll allerlei nützliche Methoden get/set Clip/Color/Font Text darstellen: drawString Bild aus Datei: drawImage grafische Primitive drawLine/Polygon/Rect/RoundRect/Arc/Oval fillPolygon/Rect/RoundRect/Arc/Oval Koordinaten x y

7.7 Grafik Beispiel: Bild anzeigen
auch mit variabler Größe import java.awt.*; import javax.swing.*; public class PictPanel extends JPanel { private Image Pict = null; public PictPanel() { super(); this.setLayout(null); Pict = getToolkit().getImage("bild.jpg"); } protected void paintComponent(Graphics g) { super.paintComponent(g); // zeichnet den Hintergrund g.drawImage(Pict, 0,0, getWidth(),getHeight(), this); für JAR-Datei: this.getClass().getResource("...") Laden vorbereiten linke obere Ecke skaliert auf Panelgröße registriert sich als ImageObserver (wird nach Laden des Bildes aktualisiert)

7.7 Grafik Grafikausgabe beschleunigen (1)
Aufwand zur Aktualisierung der eigenen Komponente reduzieren Einfachster Fall: repaint() verursacht Neuzeichnen der gesamten Komponente genügt für einfache Komponenten Pixel außerhalb des Clip-Bereichs werden ohnehin nicht ausgegeben Tuning: nur den Teilbereich neu zeichnen, der von einer Änderung betroffen ist ("dirty region", "smart painting") bei Anforderung mitteilen: void repaint(int x, int y, int width, int height) beim Zeichnen auswerten: Graphics.getClip() bzw. Graphics.getClipBounds() Beispiel:

7.7 Grafik Grafikausgabe beschleunigen (2)
unnötige Aktualisierung anderer Komponenten vermeiden boolean isOpaque(); void setOpaque(boolean o) Eigenschaft soll das Verhalten der paint-Methode signalisieren Konsistenz Opaque/Paint muss der Entwickler sicherstellen ! das Verhalten der Komponente wird i.a. nicht durch setOpaque geändert Ausnahme: JLabel, JTextfield, ... true: Komponente zeichnet jedes Pixel in ihrem Bereich darunter liegende Komponenten werden nicht neu gezeichnet false: Komponente zeichnet nicht jedes Pixel  Hintergrund scheint durch z.B. auch für Look & Feel mit runden Ecken boolean isOptimizedDrawingEnabled() { return true; }; true: Komponente garantiert, dass untergeordnete Komponenten sich nicht überlappen und nicht aktualisiert werden müssen true für alle Komponenten außer JLayeredPane, JDesktopPane und JViewPort blickdicht, nicht transparent ggf. überschreiben

7.8 Drag & Drop Mentales Modell und Anwendungsbereiche
GUI Operation mit zwei Parametern: Quelle und Ziel verschiebt ein Objekt auf bzw. in ein anderes verschiebt Datei in anderen Ordner verschiebt ein Objekt an eine andere Position verschiebt markierten Text in Textverarbeitung verschiebt Element in einer Liste (manuelles Sortieren) übergibt ein Objekt an ein anderes übergibt Dokument an Anwendung Operation wird erst beim Fallenlassen ausgeführt davor "nur" visuelles Feedback an Benutzer nicht verwechseln mit z.B. Malen im Malprogramm Operation wird "unterwegs" ausgeführt

7.8 Drag & Drop Zustandsdiagramm allgemein
die Cursor-Änderung signalisiert eine mögliche Interaktion Maus ist irgendwo Maus verlässt Objekt / Cursor = Standard Maus geht über Objekt / Cursor = Hand Maus ist über Objekt Maus innerhalb Objekt / — Maustaste loslassen / Zielposition erfassen Cursor = Hand Visualisierung deaktivieren Operation(Quelle, Ziel) Maustaste drücken / Quellposition speichern Cursor = Faust Visualisierung aktivieren Objekt wird gezogen Maus verschieben / Visualisierung aktualisieren

7.8 Drag & Drop Low Level mit Swing
Objekterkennung und Painting selbst implementiert ! isObjectPosition() siehe Beispiel 4.10 Drag & Drop mouseMoved / Cursor.DEFAULT_CURSOR mouseMoved / Cursor.HAND_CURSOR isObjectPosition() && source == null mouseMoved / — mouseReleased / MouseEvent.getPoint() paintComponent(...) Operation(Quelle, Ziel) mousePressed / MouseEvent.getPoint() Toolkit.createCustomCursor paintComponent(...) source != null entspricht mouseMoved bei gedrückter Taste; in anderen Systemen steht nur mouseMoved zu Verfügung mouseDragged / paintComponent(...)

7.8 Drag & Drop Abstract Class DragAndDropable
siehe Beispiel 4.10 Drag & Drop implementiert die Mouse Handler mit Zustandsverwaltung und Cursor-Umschaltung und provoziert das Neuzeichnen via repaint() void onMoved(Point source) void onPressed(Point source) void onDragged(Point actualPosition) void onReleased(Point destination) delegiert an die Subklasse MovableFigure boolean isObjectPosition(...) Mapping Point  Object void visualize(...) Objektdarstellung beim Schieben void operation(...) die eigentliche Nutzfunktion

7.8 Drag & Drop High Level mit Swing
Kopieren bzw. Verschieben von Objekten zwischen verschiedenen JComponents Mapping Point  Object übernimmt Swing Beispiele und Details siehe

Entwicklung nutzerorientierter Anwendungen

Ähnliche Präsentationen

Präsentation zum Thema: "Entwicklung nutzerorientierter Anwendungen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Entwicklung nutzerorientierter Anwendungen

Ähnliche Präsentationen

Präsentation zum Thema: "Entwicklung nutzerorientierter Anwendungen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback