Entwicklung nutzerorientierter Anwendungen

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

2. 1. EinführungLernziele 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

3. 1. EinführungInhalte • 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

4. top-down ? bottom-up 1. EinführungPraktikum • 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

5. 1. EinführungKlausur • 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

6. 1. EinführungLiteratur (HCI und UID) • Keith Andrews: Human-Computer Interaction • http://courses.iicm.tugraz.at/hci/hci.pdf • 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 • http://www.oracle.com/technetwork/java/jlf-135985.html • Frank Thissen: Screen Design Handbuch • Hans-Peter Wiedling: Skript zur Parallelveranstaltung • Ralf Hahn: Skript "Objektorientierte Analyse und Design"

7. 1. EinführungLiteratur (Java) • Guido Krüger: Handbuch der Java-Programmierung • http://www.javabuch.de/ • David Flanagan: Java in a Nutshell, O'Reilly • Oracle: The Java Tutorial • http://docs.oracle.com/javase/tutorial/ • Oracle: Java Standard Edition API • http://docs.oracle.com/javase/7/docs/api/ • Oracle: Java Language Specification • http://docs.oracle.com/javase/specs/ • Eclipse Online Hilfe • F2, Open External Javadoc

8. 1. EinführungEntwicklungsumgebung • 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 • http://www.eclipse.org/

9. 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

10. 2. Softwaretechnik für BenutzungsschnittstellenVisionsdokument • 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

11. 2.1 Benutzer kennen und verstehenAdmins 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

12. 2.1 Benutzer kennen und verstehenBenutzer 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

13. 2.1 Benutzer kennen und verstehenStereotype "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

14. 2.1 Benutzer kennen und verstehenStereotype 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!

15. 2.1 Benutzer kennen und verstehenAnwendungsszenarien • 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: • https://www.fbi.h-da.de/online-belegsystem/dokumentation/ein-szenario.html • Übung: Ingo I. braucht ein Zwischenzeugnis für eine Bewerbung

16. 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 2.1 Benutzer kennen und verstehenSzenario  Use Case Beschreibung Use Cases werden später aus den Anwendungsszenarien erarbeitet

17. 2.1 Benutzer kennen und verstehenMethoden 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

18. 2.1 Benutzer kennen und verstehenFallen 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

19. 2.1 Benutzer kennen und verstehenz.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

20. 2.1 Benutzer kennen und verstehenz.B. Online Belegsystem • Studierende • Fb Informatik, Fb Media, sonstige Fb, Austausch, CNAM • ein Anwendungsszenario:https://www.fbi.h-da.de/online-belegsystem/dokumentation/ein-szenario.html • Lehrende • Sekretärinnen • Fachbereichsassistentin • Anwendungs-Administrator • System-Administrator • ESE-Tutoren • Laboringenieure

21. 2.1 Benutzer kennen und verstehenz.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 !

22. 2.2 Anwendungscharakter und ModellNicht-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 E-Mail-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 • ...

23. fließende Übergänge 2.2 Anwendungscharakter und ModellCharakter 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, ... ?

24. Ziel von Analyse und Entwurf:Diskrepanz dieser Modelle vermeiden ! 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"

25. 2.3 AnwendungsfallanalyseAnwendungsfä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

26. zur Übersicht vor dem Entwurf der Benutzungsoberfläche Geldautomat Geldvorrat prüfen Kontostand abfragen Geld nachfüllen Geld holen eingezogene Scheckkarten entnehmen Mitarbeiter Geldkarteladen Kunde 2.3 Anwendungsfallanalyse Use Case Diagramm (Geldautomat) eine Benutzerrolle sieht oft nicht die Funktionen der anderen Use Cases entsprechen oft der obersten Menüebene 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)

27. 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

28. 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

29. 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 stattSchließen und wieder Öffnen • das Beispiel ist problematisch, weil Benutzer dateiorientiertes Arbeiten gewohnt sind ...

30. 2.3 Anwendungsfallanalyse Beispiel: anwendungsfallorientiert Prodekan Sekretärin Stundenplaner

31.  2.3 Anwendungsfallanalyse Gegenbsp.: datenstrukturorientiert

32. 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

33. im Detail nach dem Entwurf der Benutzungsoberflächemit Bezug auf die geplanten Bedienelemente 2.3 Anwendungsfallanalyse Use Case Spezifikation im Praktikum: Konzentration auf das Wesentliche vgl. Skript R. Hahn: Objektorientierte Analyse und Design kann bei Bedarf erweitert werden ...

34. 2.4 AbläufeWorkflow • 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

35. 2.4 AbläufeBeispiel zum Workflow auf Benutzungsoberfläche visualisiert Prodekan Sekretärin Stundenplaner

36. 2.4 AbläufeAssistent • 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 oderfür unerfahrene Benutzer • Nachteil: langsam und schwerfällig für Profis

37. 2.4 AbläufeBeispiele 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

38. 2.5 GUI-DiagrammeSinn 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

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

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

41. spezielle Form eines Zustandsdiagramms 2.5 GUI-DiagrammeNavigationsü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

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

43. 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-DiagrammeLegende zur Navigationsübersicht

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

45. 2.5 GUI-DiagrammeVarianten 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: http://www.carmster.com/hci/uploads/Lectures/PrototypingForTinyFingers.pdf http://www.alistapart.com/articles/paperprototyping

46. 2.5 GUI-DiagrammeVorgehensweise 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 !

47. Eigenschaften Allgemein Allgemein Freigabe Freigabe Anpassen Anpassen 2.5 GUI-DiagrammeSpezialfall 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

48. 2.5 GUI-DiagrammeUML-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

49. Negativbeispielabstrahiert von GUI:so bringt es uns nichts 2.5 GUI-Diagrammevgl. Sequenzdiagramm "Geld holen" VolksbankAutomat1:CGeldautomat Ich:CBenutzer Screens = Zustände EC-Karte einlesen Ruhestellung Hauptmenü PIN-Dialog ... Geldholen 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

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