ENA Entwicklung nutzerorientierter Anwendungen

Transkript

1

2

3 ENA Entwicklung nutzerorientierter Anwendungen 3V + 1P SWS 5 CP Belegnummer: [PVL/Praktikum: ] Wintersemester 2014/15

4 Entwicklung nutzerorientierter Anwendungen Gestaltung von grafisch-interaktiven Systemen (hier: Smartphone mit Android) Bedürfnisse, Fähigkeiten und Erwartungen der (spezifischen) Nutzergruppen stehen im Mittelpunkt Nutzergruppe(n) identifizieren Bedürfnisse befriedigen Fähigkeiten unterstützen Erwartungen erfüllen Interdisziplinäres Gebiet(auch Psychologie, auch Design, auch Softwareentwicklung,...) Usability steht in den verschiedenen Phasen im Vordergrund Anforderungen erfassen und analysieren Prototypen entwerfen, umsetzen, testen und reflektieren Ergebnisse evaluieren Entwicklung nutzerorientierter Anwendungen, Seite 4

5 Überblick Java und Android for Run-aways Human Computer Interaction Usability Intuitive Bedienbarkeit, Erlernbarkeit, Konsistenz,... Gestaltung Layout, Farbe, Schrift, Anordnung Entwurf: benutzerzentrierte Analyse, Design, Rapid Prototyping Konstruktionunter Android mit Tool (eclipse): Views (Controls, Componenten), Container, Layouts, Eventhandling, Ressourcenkonzept Programmiermuster Model-View-Control, Observer, Adapter, Singleton Beispiele in der Vorlesung Entwicklung nutzerorientierter Anwendungen, Seite 5

6 Inhalte SW-Technik: Rollen erfassen, Nutzungsfall identifizieren, Szenario und Screen-Diagramm erstellen Trennung Datenverarbeitung Oberfläche, Dokument Ansicht MVC als Architektur- und Designpattern Screen-Design und Ergonomie Gruppierung, Formen, Farben, statisches/dynamisches Layout Java/Android Crash-Kurs für Kenner von C++ Implementierungstechniken Baukasten: Views, Attribute, Ereignisse Screens (Activities) mit Layouts und Views Ereignisbehandlung auch zusätzliche Klassen (z.b. Collection, Persistenz: Dateihandling, ) Gute Beispiele, schlechte Beispiele Entwicklung nutzerorientierter Anwendungen, Seite 6

7 Lernziele der Veranstaltung Grafisch-interaktive Benutzungsoberflächen (GO) Benutzerorientierung verinnerlichen (Benutzergruppen/Rollen identifizieren, Usability-Überlegungen einsetzen,...) intuitiv und ergonomisch gestalten visuell ansprechend entwerfen GO-Entscheidungen - Verwendung bestimmter Componenten - begründen können objektorientiert konstruieren gute GOs spiegeln sich im Entwurfs- und Realisierungsaufwand wider methodisch Vorgehen lernen Konzept der Ereignisorientierung verstehen Bausteine grafischer Oberflächen kennen und anwenden lernen... und das alles in Android (und Java) Entwicklung nutzerorientierter Anwendungen, Seite 7

8 Prüfung/Klausur mit Papier und Kugelschreiber Raum und Zeit siehe OBS (achten Sie auf Anmelde- und Abmeldefristen) regelmäßige Teilnahme am Praktikum es sind 6 Terminewird kontrolliert und ist Voraussetzung; Beginn am 9. Oktober (donnerstags) bzw. am 10. Oktober (freitags) alte Klausur und Übungs-/Vorbereitungstermin Tipp: Aktive Mitarbeit macht einen guten Teil der Prüfungsvorbereitung aus! Entwicklung nutzerorientierter Anwendungen, Seite 8

9 Literatur zu Java Guido Krüger, Addison-Wesley, ISBN und Oracle (Sun): Java Documentation + Suchapplet Entwicklung nutzerorientierter Anwendungen, Seite 9

10 Literatur und Tutorials zu Android Arno Becker, Marcus Pant: Android Grundlagen und Programmierung; dpunkt Verlag; ISBn Mike Bach: Mobile Anwendungen mit Android Entwicklung und praktischer Einsatz; Addison-Wesley; ISBN und viele weitere Online-Tutorials Entwicklung nutzerorientierter Anwendungen, Seite 10

11 Weiterführende Literatur Bernhard Preim: Entwicklung interaktiver Systeme Ivo Wessel: GUI-Design Alan Cooper: About Face - The Essentials of User Interface Design Sun: Java Look and Feel Design Guidelines Online Sun: Sonstiges rund um Java Helmut Balzert: Lehrbuch Grundlagen der Informatik Entwicklung nutzerorientierter Anwendungen, Seite 11

12 Praktikum Semesterprojekt: Entwurf, prototypische Realisierung und Verfeinerung eines Systems Problembewusstsein entsteht im Laufe des Semesters optimierende Iterationen sind wichtig! Implementierung mit Eclipse: Get the Android SDK: Entwicklung nutzerorientierter Anwendungen, Seite 12

13 Usability, Benutzeranforderungen, Rapid Prototyping ENTWURFSPHASE Entwicklung nutzerorientierter Anwendungen, Seite 13

14 Gelegenheit, über Usability nachzudenken Ständiger Technologiewandel verlangt permanente Auseinandersetzung mit Organisationsabläufen und den Systemen Anstehende System-oder Versionswechsel sind zusätzlich günstige Zeitpunkte, dabei müssen gerade die unterschiedlichen Nutzer überzeugt und mitgenommen werden Bereitschaft, sich mit Arbeitsabläufen und der Einbindung von IT -Prozessen auseinander zusetzen mit dem Ziel Produktivität/Wirtschaftlichkeit zu steigern Ressourcen zu schon und Kosten (Durchlaufzeit) zu reduzieren Qualität und Kundenzufriedenheit zu verbessern Mobile Geräte bieten die Möglichkeit, Fragen neu zu beantworten oder Abläufe neu zu realisieren Neben den Aspekten Preis, Lizenzen, Standards, branchentypischen Lösungen, verkauften Systemen, Schnittstellen und Integration spielt die Nutzerzufriedenheit eine wichtige Rolle Entwicklung nutzerorientierter Anwendungen, Seite 14

15 Bedeutung der Entwurfsphase Beim Entwurf und der Realisierung muss in der Praxis insbesondere darauf geachtet werden, dass man den Entwickleraufwand kalkulieren kann und dann auch einhält, das Projekt also in-time und in-budget bleibt und den Support nicht überstrapaziert die User Requirements erfüllt werden. Das muss auch etwas mit Qualität zu tun haben! Fehler in der Analyse und Konzeption haben dabei dramatische Auswirkungen auf die o.g. genannten Punkte! Ein erstes, wichtiges Ziel muss also sein, die Anforderungen der Benutzer richtig und vollständig zu erfassen Entwicklung nutzerorientierter Anwendungen, Seite 15

16 Phänomene nicht nur im Zusammenhang mit grafischen Benutzungsoberflächen (1/2) Kognitive Dissonanz entsteht, wenn man zwischen verschiedenen Alternativen wählen muss und die Vor-und Nachteile dieser Systeme abwägt. Hat man eine Entscheidung getroffen, ist man bemüht, sich zu versichern, dass man die richtige Wahl getroffen hat und nimmt Argumente besonders wahr, die die Entscheidung unterstützen und verharmlost/ignoriert Gegenargumente. Beispiel: Festhalten an möglicherweise kryptisch und schwer zu benutzenden oder teueren Systeme Anordnung der Tasten auf der qwertz-tastatur [Alternative siehe z.b. ]... Entwicklung nutzerorientierter Anwendungen, Seite 16

17 Phänomene nicht nur im Zusammenhang mit grafischen Benutzungsoberflächen (2/2) Magisches Denken bezieht sich darauf, dass sich Benutzer eine Vorstellung (mentales Modell) von dem System/Geräte machen, mit dem sie arbeiten. Diese hängt von der Erfahrung und Vorbildung ab. Die Modelle sind so konstruiert, dass sie Analogieschlüsse zulassen: wenn das Mail-Tool geöffnet ist, stürzt die Textverarbeitung bei der Rechtschreibprüfung ab Benutzer sind sehr bemüht an diesen Modellen festzuhalten; auch dann wenn gedankliche Verrenkungen nötig werden: wenn das Mail-Tool offen ist und mehr als zehn neue Mails eingetroffen sind, dann stürzt die Textverarbeitung ab Entwicklung nutzerorientierter Anwendungen, Seite 17

18 Entwickler und Anwender (1/4) spielen einen neuen Dialog durch: Entwickler: So, jetzt hast Du einen Teil der Aufgabe bereits ausgeführt. Willst Du nun noch etwas verändern? Anwender: Ja, ich möchte eine Komponente löschen. Was muss ich tun? E: Deute auf das Menu mit dem Namen CD. A: CD? E: CD bedeutet Component Delete. A: OK, ich habe verstanden Oh, was passiert jetzt? Entwicklung nutzerorientierter Anwendungen, Seite 18

19 Entwickler und Anwender (2/4) E: Du bist jetzt im Analyse-Modus. Du musst aus Versehen AM ausgewählt haben. A: Ach so, ich dachte, ich hätte CD ausgewählt. Wie verlasse ich den Analyse-Modus? E: Kein Problem. Gib einfach control Q ein. A: [tippt C O N T R O L ] E: Nein! Drücke die Strg -Taste und die Q -Taste. A: Wie dumm von mir. Ich versuch s noch einmal. Es passiert gar nichts. Was habe ich falsch gemacht? Entwicklung nutzerorientierter Anwendungen, Seite 19

20 Entwickler und Anwender (3/4) E: Du hast nichts falsch gemacht. Die Komponente ist gelöscht aber noch nicht vom Bildschirm entfernt. Gib noch control-j ein. A: Ich habe verstanden. Wenn ich die nächste Komponente lösche, gebe ich wieder control-q ein. Hoppla, warum ist der Bildschirm jetzt weiß? E: Du hast nur Q eingegeben. Q bedeutet Quit und beendet das Programm. Jetzt musst Du leider alles noch einmal eingeben! A: Wenn das so ist, machen wir nächste Woche weiter. Entwicklung nutzerorientierter Anwendungen, Seite 20

21 Entwickler und Anwender (4/4) Folgende Fehler wurden gemacht: Kommandos (CD, AM) sind nicht intuitiv erzeugt unnötige Belastung für den Anwender Auf welches Objekt wird das Kommando angewendet? Keine Statusinformation zu Zustandsänderungen Kryptische Kommandos (control-j, control-q) sind ungeeignet für unerfahrene, gelegentliche Benutzer Kein Feedback bei Delete erzeugt Frustration und Ablehnung bei dem Anwender ergibt Negativausstrahlung auf das Gesamtsystem Entwicklung nutzerorientierter Anwendungen, Seite 21

22 Usability-Kriterien Usability-Kriterien sind: Effizienz (Efficiency) Wenig Interaktion (Benutzer entlasten) Fokussteuerung an Hauptabläufen orientiert (Benutzer führen) Effektivität (Effectiveness) Können alle Aufgaben vollständig gelöst werden? Erlernbarkeit (Learnability) Kann das UI aus der Benutzererfahrung heraus bedient werden? Erinnerbarkeit (Memorability) Kann man das UI nach einer gewissen Zeit noch sicher bedienen? Zufriedenheit/Wohlbefinden/Spaß (Satisfaction; Emotional Usability) Gestaltung, Feedback, Klarheit Fehlersituation durch Bedienung (Error) Entwicklung nutzerorientierter Anwendungen, Seite 22

23 Analyse-Design-Realisierung-Test-Evaluation Analyse Benutzorientiertes RequirementsEngineering: Usability-Engineering Heuristic ohne Benutzer testen Observation Benutzer beim bedienen beobachten Thinking-Aloud Beim Bedienen laut denken Questionnaire - Fragebogen Interview Befragung u.u. Erarbeitung von Anwendungswissen u.u. Erarbeitung von zusätzlichem technischem Wissen Diesen Prozess wollen wir im Praktikum zumindest einmal durchlaufen Entwicklung nutzerorientierter Anwendungen, Seite 23

24 Analyse-Design-Realisierung-Test-Evaluation Design Legen Sie Designziele fest Welche Benutzergruppen adressieren Sie? Entlasten Sie den Benutzer! Welche Vorteile, welchen Nutzwert liefert ihre App Beschreiben Sie Anwendungsszenariien und Use Cases Skizzieren Sie das Layout (es sollte dynamisch sein) Überlegen und begründen Sie Gestaltungsentscheidungen Entwicklung nutzerorientierter Anwendungen, Seite 24

25 Analyse-Design-Realisierung-Test-Evaluation Realisierung Überlegen Sie, wie Sie Funktionalität und Dialog(Controls) koppeln: Model-View-Control Entwickeln Sie die Funktionalität getrennt von der GUI! Denken Sie auch an die Navigation im Systeme, die Arbeitsabläufe und den generellen Workflow Rapid Prototyping: iterativ, unter Einbeziehung der Nutzer Machbarkeit demonstrieren Entwicklung nutzerorientierter Anwendungen, Seite 25

26 Analyse-Design-Realisierung-Test-Evaluation Test Wer von Ihnen würde ein nicht getestetes Programm benutzen? Überlegen Sie von Beginn an Testfälle Wie lange dauert es, um eine bestimmte Aufgabe zu lösen? Wie viele Klicks/Interaktionen werden benötigt, um die Aufgabe zu lösen? Wie schnell erlernbar ist das GUI? Wie viele Fehler werden gemacht? Wie sicher ist die GUI? Testen Sie die Gebrauchstauglichkeit (Usability) Entwicklung nutzerorientierter Anwendungen, Seite 26

27 Analyse-Design-Realisierung-Test-Evaluation Evaluation der Umsetzung Welche Ziele werden erreicht? Wie gut werden die Ziele erreicht? Evaluationsmethoden: Experteninspektionen, kognitiver Walkthrough, Usability-Tests, Fragebogenverfahren Klassifikation von Evaluationsmethoden: analytisch vs. empirische bzw. deskriptiv vs. präskriptive Evaluationsmethoden Formen der Evaluation: summative und formative Evaluation Vereinbarung von Evaluationskriterien Entwicklung nutzerorientierter Anwendungen, Seite 27

28 Usability-Aspekte Struktur (Layout, Design) planen und festlegen Dazu gehört auch Elemente präzise zu identifizieren Elemente sinnvoll zu benennen ( Sprache der Nutzer sprechen ) Skizzen (und Entwürfe zu) erstellen und schrittweise (zunächst abstrakt dann konkret) zu verfeinern Die Anforderungen orientieren sich an den Aufgaben Welche Aufgaben möchte der Benutzer lösen? Aufgaben und Bedürfnissen der unterschiedlichen Benutzergruppen sind unterschiedlich Welche unterschiedlichen Benutzergruppen gibt es? Entwicklung nutzerorientierter Anwendungen, Seite 28

29 Ziele (1/2) Einheitliches Look-and-Feel (Konsistenz) Innerhalb einer Applikation und applikationsübergreifend Benutzerführung gemäß Regeln Motto: Fehlervermeidung statt Fehlerbehebung Trennung von Anwendung und graphischer Benutzungsoberfläche einfache Anpassung von Text und Schrift; relative Positionierung ist zusätzlich sehr hilfreich: Methode Componente C1 links von C2; C3 oberhalb von C4 Dialog(schritt)e bilden Zustände ab Screens werden in separaten Ressource-Dateien (in XML) beschrieben Entwicklung nutzerorientierter Anwendungen, Seite 29

30 Ziele (2/2) Aufgabenangemessene Präsentation und Interaktion Direkte Manipulation Benutzerunterstützung beim Gestalten und Steuern, Erstellen und Modifizieren, Inspizieren (surfen) und Prüfen, Navigation(sunterstützung) in komplexen Situationen Beherrschung der Komplexität und Menge durch Informationsaufbereitung: selbsterklärend, kontextbezogene Hilfe Realitätsnähe Abstraktion Auch auf mobilen Endgeräten und unter deren speziellen Einsatzbedingungen (unterwegs, draußen, bei widrigen Lichtverhältnissen, ) Joy of Use: begeistern, stimulieren, motivieren, überzeugen, fesseln,... (Tipp: Schauen Sie unter youtube piano stairs Entwicklung nutzerorientierter Anwendungen, Seite 30

31 Emotional Usability: Joy of Use Merkmale die Software unterstützt den Benutzer unauffällig bzw. weckt dessen Interesse, indem es interessante Funktionen als zu lösende Aufgaben präsentiert und Neugier weckt sowie Anreiz zum eigenständigen Lernen gibt die Aufgabenstellung wird in eine Geschichte integriert -die Bearbeitung einer Teilaufgabe ist ein Schritt in einer größeren Aufgabenstellung - die Glaubwürdigkeit in der Arbeitswelt wird durch Konsistenz und Aufmerksamkeit für Details gesichert ( Erwartungskonformität) Quelle: Marc Hassenzahl: Attraktive Software Was Gestalter von Computerspielen lernen können; In: J Machate&M.Burmester: User Interface Tuning; Benutzerschnittstellen menschlich gestalten; Software & Support Verlag 2003 Entwicklung nutzerorientierter Anwendungen, Seite 31

32 1. Vollständiges Beispiel: BMI APP Entwicklung nutzerorientierter Anwendungen, Seite 32

33 Aufgabenstellung: BMI-App Der BMI bezieht die Körper-Masse auf das Quadrat der Körpergröße. Der BMI ist lediglich ein grober Richtwert, da er weder Statur und Geschlecht noch die individuelle Zusammensetzung der Körpermasseaus Fett-und Muskelgewebe eines Menschen berücksichtigt. Der Body Mass Index (BMI) bewertet einfach das Körpergewicht Die (vereinfachte) Formel zu Berechnung des BMI lautet BMI = Masse in kg / (Größe in Meter) 2 Dabei bedeutet ein BMI zwischen 18,50 und 24,99 Idealgewicht; Werte unter 18,50 bedeuten Untergewicht und ein Wert von 25,00 oder mehr weist auf Übergewicht hin. Ein BMI Rechner soll als App realisiert werden Entwicklung nutzerorientierter Anwendungen, Seite 33

34 Vorbereitung der BMI-App Funktional ist (zunächst) die Formel umsetzen (minimaler Aufwand) Zur Erfassung von Größe und Gewicht und zur Darstellung des BMI wird ein User Interface benötigt zumindest die Eingaben sollten auf Plausibilität überprüft werden! Eine Strukturierung des Ablaufs/Workflows in mehrere Screens/Schritte ist hier offensichtlich nicht erforderlich (weitere) Systemressourcen werden nicht benötigt Entwicklung nutzerorientierter Anwendungen, Seite 34

35 Entwicklungsschritte Erster Entwurf Konkretisierung Umsetzung und Tests - grob und abstrakt - - mit Controls/Views - - funktional und bzgl. Usability i.d.r. sollten Verbesserungen erfolgen Entwicklung nutzerorientierter Anwendungen, Seite 35

36 Umsetzung der BMI-App benötigt werden eine Layoutbeschreibung (Ressource), eine Activity unter Android, die die Anwendungslogik umsetzt und ein Manifest, in welchem Berechtigungen, Icons und weitere Spezifika weitere Activities und Services benannt werden Entwicklung nutzerorientierter Anwendungen, Seite 36

37 src/com.example.bmiapp/mainactivity.java public class MainActivity extends Activity protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); Layoutressource setcontentview(r.layout.activity_main); Button button; button = (Button) findviewbyid(r.id.bmi); button.setonclicklistener(new OnClickListener() { public void onclick(view view) { float masse; float groesse; Verbindung zum Button Eventhandling EditText etgroesse = (EditText) findviewbyid(r.id.groesse); EditText etmasse = (EditText) findviewbyid(r.id.masse); Entwicklung nutzerorientierter Anwendungen, Seite 37

38 src/com.example.bmiapp/mainactivity.java } } Editable e = etmasse.gettext(); masse = Float.valueOf(e.toString()); e = etgroesse.gettext(); groesse = Float.valueOf(e.toString()); float bmi = masse / (groesse * groesse); EditText result = (EditText) findviewbyid(r.id.result); result.settext(string.valueof(bmi)); public boolean oncreateoptionsmenu(menu menu) { } } getmenuinflater().inflate(r.menu.activity_main, menu); return true; macht gglfs. die Menu- Einträge verfügbar Entwicklung nutzerorientierter Anwendungen, Seite 38

39 Entwicklung nutzerorientierter Anwendungen, Seite 39

40 res/layout/activity_main.xml <RelativeLayout xmlns:android=" xmlns:tools=" android:layout_width="match_parent" android:layout_height="match_parent" tools:context=".mainactivity" > <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_centervertical="true" android:text="groesse" Wesentliche Merkmale derviews und das Layout der Activity wird hier festgelegt Hinweis, dass der Benutzer die Größe eingeben soll android:textappearance="?android:attr/textappearancemedium" /> Entwicklung nutzerorientierter Anwendungen, Seite 40

41 res/layout/activity_main.xml <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:ems="10" /> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:layout_alignparenttop="true" android:layout_marginleft="26dp" android:layout_margintop="50dp" android:text="masse" Eingabefeld für die Größe Hinweis, dass der Benutzer die Masse eingeben soll android:textappearance="?android:attr/textappearancemedium" /> Entwicklung nutzerorientierter Anwendungen, Seite 41

42 res/layout/activity_main.xml <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:layout_margintop="33dp" android:ems="10" /> <EditText android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentbottom="true" android:layout_alignparentleft="true" android:layout_marginbottom="58dp" android:ems="10" /> Eingabefeld für die Masse Ergebnisfeld Entwicklung nutzerorientierter Anwendungen, Seite 42

43 res/layout/activity_main.xml <Button android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignparentleft="true" android:text="bmi" /> Anklicken des Buttons soll bewirken, dassdie Formel ausgeführt wird </RelativeLayout> Entwicklung nutzerorientierter Anwendungen, Seite 43

44 Entwicklung nutzerorientierter Anwendungen, Seite 44

45 bin/res/androidmanifest.xml <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android=" package="com.example.bmiapp" android:versioncode="1" android:versionname="1.0" > <uses-sdk android:minsdkversion = "14" android:targetsdkversion = "17" /> Entwicklung nutzerorientierter Anwendungen, Seite 45

46 bin/res/androidmanifest.xml <application android:allowbackup="true" > <activity android:name=".mainactivity" > <intent-filter> Mitdieser Activity wirddie App gestartet <action android:name="android.intent.action.main" /> <category android:name="android.intent.category.launcher" /> </intent-filter> </activity> </application> </manifest> Angabe weiterer Activities und der Berechtigungen Entwicklung nutzerorientierter Anwendungen, Seite 46

47 Bewertung der BMIApp App ist erster rudimentärer Ansatz App kann nicht mit fehlerhaften Eingaben umgehen! (kritisch!) Aufbereitung und -auch grafische -Interpretation des Ergebnisses wäre wünschenswert (so nicht sehr benutzerfreundlich) Aufzeigen von Trends (gegenüber der letzten Berechnung) wär wertvoll Entwicklung nutzerorientierter Anwendungen, Seite 47

48 Dialogstruktur, Navigationsübersicht, Diagramme DIALOG(SCHRITT)E Entwicklung nutzerorientierter Anwendungen, Seite 48

49 Mensch-Maschine-Schnittstelle - Graphische Benutzungsoberfläche Präsentation, Visualisierung kreativ, intuitiv Interaktion monoton, schnell Beobachten, Bedienen

50 Kommunikation und Mobiliät Kommunikation (der Austausch mit anderen) Mobilität (unterwegs und Information über die Umgebung) geschützt, vertraut, sicher, komfortabel Entwicklung nutzerorientierter Anwendungen, Seite 50

51 Ein kleines Beispiel Überlegen Sie, wie ein Anwender den Dialog mit einem Geldautomaten wahrnimmt und auch beschreibt Zugangsberechtigung kontrollieren (EC-Karte und Ihre 4stellige Geheimnummer) Betrag angeben Betrag ausgeben Automat wieder in den Ausgangszustand versetzen Entwicklung nutzerorientierter Anwendungen, Seite 51

52 siehe auch SWT-Skript Notation des Sequenzdiagramms Objekt Methodenausführung Lebenslinie Meth.aufrufen Bedingung Ablauf objektorientiert beschrieben Objekt erzeugen Objekt zerstören eigene Methode aufrufen Entwicklung nutzerorientierter Anwendungen, Seite 52

53 Sequenzdiagramm "Geld holen" E! " $% +,,! '! E ' E '!! &!'! $!!./ 0% &' ()* +,-!' 111 Entwicklung nutzerorientierter Anwendungen, Seite 53

54 Sequenzdiagramm "Geld abheben" Geld holen Ich: CBenutzer EC-Karte einlesen Use Case wählen PIN-Nummer einlesen Betrag einlesen EC-Karte ausgeben EC-Karte entnehmen VolksbankAutomat1: CGeldautomat Geld ausgeben in diese Richtung kann man das innere Verhalten weiter modellieren Screens= Zustände Ruhestellung Hauptmenü PIN-Dialog... Geld entnehmen Entwicklung nutzerorientierter Anwendungen, Seite 54

55 Geldautomat als "Assistent (üblich) "Assistenten" serialisieren die Abfrage mehrerer Eingabewerte vom Benutzer Vereinfachung: Benutzer muss zu einem Zeitpunkt nur über eine Frage nachdenken sinnvoll für selten benutzte Anwendungsfälle oder für unerfahrene Benutzer langsam und schwerfällig für Profis zum Vergleich der bekannte Geldautomat nicht als Assistent: Entwicklung nutzerorientierter Anwendungen, Seite 55

56 Szenario "Kontostand abfragen" Benutzer führt EC-Karte ein wählt "Kontostand abfragen" gibt PIN-Nummer ein nimmt EC-Karte Automat bietet Hauptmenü an erfragt PIN-Nummer gibt EC-Karte heraus zeigt Kontostand an geht in Ruhestellung Entwicklung nutzerorientierter Anwendungen, Seite 56

57 Szenario "Geld holen" Sicht des Kunden Benutzer Automat führt EC-Karte ein wählt "Auszahlung" gibt PIN-Nummer ein gibt Betrag ein nimmt EC-Karte nimmt Geld Sicht der Bank bietet Hauptmenü an erfragt PIN-Nummer erfragt Betrag gibt EC-Karte heraus gibt Geld heraus geht in Ruhestellung Entwicklung nutzerorientierter Anwendungen, Seite 57

58 Geldautomat: Use Case Diagramm Use Cases entsprechen oft der obersten Menüebene Geldautomat Kontostand abfragen Geldvorrat prüfen Geld Geld holen nachfüllen Kunde Schecks bestellen eingezogene Scheckkarten entnehmen Mitarbeiter eine Benutzergruppe sieht oft nicht die Funktionen der anderen Entwicklung nutzerorientierter Anwendungen, Seite 58

59 Sequenzdiagramme -Notation stellen Objekte und deren Interaktion dar Interaktion: eine Methode ruft eine andere Methode auf Zeitachse von oben nach unten Lebensdauer des Objekts durch "Lebenslinie" dargestellt vgl. Flussdiagramm / Programmablaufplan ältere Diagrammtypen, die nicht objektorientiert sind Entwicklung nutzerorientierter Anwendungen, Seite 59

60 Sequenzdiagramme -Bewertung Diagramme für GUI-Entwurf in UML nur beschränkt geeignet: UML konzentriert sich auf die Architektur von SW-Systemen vernachlässigt den visuellen Aspekt ein GUI wird zwar mit Klassen realisiert, anhand eines Klassen-oder Kollaborationsdiagramms kann man sich aber kein Bild von Aussehen und Benutzung machen! Vorschlag: Screen-Diagramme im Grunde abgewandelte Zustandsdiagramme Entwicklung nutzerorientierter Anwendungen, Seite 60

61 abstrakt und konkret Beispiel: Lehrangebote ansehen abstrakte Elementliste (Stichwortliste, Halbsätze) Sortierung wählen: Semester, Dozent, Import/Export konkretes Layout (konkrete Anordnung, Festlegung auf Componenten) Fachbereich wählen Vorschau Drucken Ausgabe in Datei Schließen Entwicklung nutzerorientierter Anwendungen, Seite 61

62 Verbindung zum Sequenzdiagramm LvPlanungView: CLvPlanungAusgDlg LvPlanungModel: CLvPlanungAusg OnSortClick OnFbChange SetSort(Sort) SetFb(Fb) OnDiskClick OnPrintClick Output(P) OnPreviewClick OnExitClick Entwicklung nutzerorientierter Anwendungen, Seite 62

63 Komplexität beherrschen Diagramme beanspruchen viel Platz Problem beim Zeichnen Problem beim Verstehen gilt für alle, nicht nur für Zustandsdiagramme 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 Entwicklung nutzerorientierter Anwendungen, Seite 63

64 siehe auch OOAD-Skript! Zustandsdiagramme: Idee und Notation ein Objekt kann im Lauf der Zeit verschiedene Zustände annehmen Haben einen Anfang und ein Ende Zustandswechsel werden durch Ereignisse ausgelöst unterschiedliche Folgezustände sind möglich abhängig von Bedingungen (Verzweigungen im Diagramm) Aktionen können ausgeführt werden beim Übergang in den Folgezustand (notiert mit Ereignis/Aktion) während des Verweilens in einem Zustand (notiert mit do/...) Objekt wird erzeugt durchläuft mehrere Zustände und wird vernichtet Zustand do/aktion Ereignis[Bedingung]/Aktion Entwicklung nutzerorientierter Anwendungen, Seite 64

65 Beispiele: Tür und Lampe Tür Lampe offen aus Schließen( rumms ) Öffnen Einschalten Ausschalten Übergangsaktion geschlossen an do/leuchten Zustandsaktion Entwicklung nutzerorientierter Anwendungen, Seite 65

66 Implementierung Zustand: Kombination von Attributwerten des Objekts Ereignis: empfangene Nachricht / Handler-Aufruf Bedingung: wird im Handler ausgewertet Zustandsübergang: Funktionskörper eines Handlers Übergangsaktion: Methodenaufruf für anderes Objekt Zustandsaktion: Methodenaufruf (in separatem Thread) speziell bei GUIs: Screens / Dialoge sind Zustände des Objekts "Bedienoberfläche" Hauptfenster hat Zeiger auf untergeordnete Fenster als Attribute objektorientiert + ereignisorientiert Entwicklung nutzerorientierter Anwendungen, Seite 66

67 Diagramme für wen? Diagramme aus der Softwaretechnik sind nichtgeeignet, um mit Auftraggebern zu kommunizieren selbst konkrete Screen-Diagramme nicht! allenfalls, wenn die Auftraggeber selbst Informatiker sind zur Kommunikation mit Auftraggebern und Benutzern braucht man Prototypen visuell und funktional konkret, nicht erklärungsbedürftig Diagramme helfen dem Entwickler beim Entwurf, dem Wartungsprogrammierer zum Verständnis Entwicklung nutzerorientierter Anwendungen, Seite 67

68 Manifest und Prinzipien der agilen Softwareentwicklung (kurzer Exkurs)... Durch die[se] Arbeit haben wir Folgendes schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Tools Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit Kunden mehr als Vertragsverhandlungen Reaktion auf Änderungen mehr als einen Plan zu befolgen... We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. und Entwicklung nutzerorientierter Anwendungen, Seite 68

69 Einschub: Modelle eines Systems Modelle sind vereinfachte Darstellungen einer Wirklichkeit siehe Atommodelle in der Chemie kein Modell entspricht der Realität" a) mentales Modell hoffentlich identisch Sicht des Benutzers; an der Anwendung orientiert b) augenscheinliches Modell wie sich das System nach außen darstellt c) Implementierungsmodell Sicht des Entwicklers; technologisch orientiert Entwicklung nutzerorientierter Anwendungen, Seite 69

70 Use Cases eines Buchs der Leser? der gründliche Leser, der eilige Sucher, der Schenkende Fachbuch = System zur Informationsspeicherung von Anfang bis Ende lesen umblättern Überblick bekommen Inhaltsverzeichnis Information zu einem Thema suchen Inhaltsverzeichnis Detailinformation / Stichwort suchen Index Wieder Auffinden einer Stelle Lesezeichen weiterführende Information finden Literaturliste Kaufentscheidung treffen Inhaltsverz., Klappentext, Leseprobe; Preis vgl. Grundfunktionen eines Browsers vgl. dagegen einen Roman Entwicklung nutzerorientierter Anwendungen, Seite 70

71 Von Use Cases zu Bildschirmmasken eine Möglichkeit jeder Use Case wird in eine Bildschirmmaske abgebildet Benennung des Use Case wird Titel des Screens ggfs. weitere untergeordnete Dialoge bei komplexen Use Cases keine Funktionen oder Daten in einen Screen, die nicht unmittelbar zu diesem Use Case gehören! Gruppierung der Screens nach Benutzergruppen Entwurf der Grobstruktur des Dialogsystems "Screen" besser: Identifikation des Benutzers durch Anmeldung und Ausblendung der Use Cases anderer Benutzergruppen; jeder Benutzer bekommt nur Screens "seiner" Gruppe zu sehen Hauptfenster enthält Übersicht der Use Cases und verzweigt dorthin im primitivsten Fall eine Liste Entwicklung nutzerorientierter Anwendungen, Seite 71

72 (Rapid) Prototyping ob ein Entwurf "funktioniert", erkennt man nicht mit Hilfe von Diagrammen Begriff "funktionieren" unter Designern: "seinen Zweck erfüllen" frühzeitiger Test mit Benutzern ist notwendig erfordert weitgehend arbeitsfähigen Prototyp Benutzertest braucht eigentlich mehr als nur die Oberfläche... Benutzer fragen will gekonnt sein... mit geeigneten Tools ist die Erstellung einer Bedienoberfläche nicht aufwendiger als mit einem Zeichenwerkzeug vgl. Photoshop / Director 2Visual Basic / Visual C++ / Eclipse Entwicklung nutzerorientierter Anwendungen, Seite 72

73 Der erste Eindruck zählt (Rapid) Prototyping Fake(Schwindel, Betrug, Fälschung, etwas vortäuschen) Mock Up(Fälschung, Schein, Imitation) Diese drei Begriffe beschreiben eine Idee: Um als Entwickler bereits in der frühen Phase einer Programmentwicklung mit dem Anwender Effekte an der Bedienoberfläche diskutieren zu können, entstehen unvollständige Prototypen, anhand derer das Look&Feel der Applikation und deren Wirkung auf den Anwender erörtert werden können. Verschiedene Softwareprototypen vermitteln in frühen Planungsphasen einen brauchbaren Eindruck für die gestellte Aufgabe. Kommunikationsprobleme zwischen IT-Experten und Kunden lassen sich mit Prototypen verringern. Entwicklung nutzerorientierter Anwendungen, Seite 73

74 Der erste Eindruck zählt: Prototyping Grob lassen sich Prototypen unterteilen in Demonstrations-, Analyse-, Architektur- und Designprototypen Prototyp als Kommunikationsbasis für Entwickler und Anwender Proof-of-Concept (POC) im Sinne einer Machbarkeitsstudie GUI-Prototyping zielt darauf ab, den Anwender frühzeitig in den Entwicklungsprozess einzubeziehen Bewusst/Unbewusst entstehen Systemgrenzen bzw. Prototyp gibt Hinweise auf Strukturen ABER: Anwender ändern ihre Meinung! Entwicklung nutzerorientierter Anwendungen, Seite 74

75 Prototypen -vertikal Vertikale Prototypen sollen helfen, Aussagen über die Architektur machen zu können; es ist darauf zuachten, dass der Ausschnitt der realisiert wird, nicht zu trivial ist! Entwicklung nutzerorientierter Anwendungen, Seite 75

76 Prototypen -horizontal Horizontale Prototypen decken den kompletten Satz der Funktionen in einer Anwendungsebene ab; die technische Korrektheit spielt eine untergeordnete Rolle Entwicklung nutzerorientierter Anwendungen, Seite 76

77 Screens -Ticketbeispiel Screen Anmeldung (login) als Kunde, Abteilungsleiter oder Sachbearbeiter: als Kunde/Client: 1 Erfassung und Bearbeitungsfortgang Ticket neu erfassen (Bearbeitungszustand eigener Tickets betrachten/inspizieren) als Abteilungsleiter/Dispatcher: 2 Monitoren (insgesamt) Sachbearbeitern zuordnen Bearbeitungszustand aller Tickets betrachten (alle) neu erfassten Tickets anhand Beschreibung sichten und Mitarbeiter zu ordnen Qualitätskontrolle und abschließende Freigabe als Sachbearbeiter/Consultant: 3 Bearbeiten/Kommentieren und testen zu gewiesene Tickets untersuchen/bearbeiten (Angabe d. Fehlerursache) Ticket mit Kommentar versehen testen (Angabe des Testprotokolls) und damit Zustand ändern Entwicklung nutzerorientierter Anwendungen, Seite 77

78 Layout: Analyse Design Konstruktion Analyse Die fachlichen Anforderungen führen zu einem ersten groben Ablauf abstrakte Screens Use Cases geben eine Hinweis auf sinnvolle Begriffe/Bezeichner und Ablauffolgen/Workflows Das Überlagern eines Screens mit Rasterlinien ist aufschlussreich und liefert wertvolle Hinweise zur Struktur und dem Aufbau des Screens Die verschiedenen Bestandteile (Views und LayoutManager) werden grafisch identifiziert Ein Layout passt nicht zwingend für alle Displaygrößen! Entwicklung nutzerorientierter Anwendungen, Seite 78

79 Layout: Analyse Design Konstruktion Gestaltung Konkrete Auswahl der Container: Scrollen? Splitten? Was passiert beim Vergrößern/Verkleinern des Screens? Auswahl und Festlegung des Farbklimas ( Style Guides entstehen) Schrift-, Fenster- und Icongröße beeinflussen die Gesamtgröße Was soll passieren, wenn sich die Componenten in Anzahl und Typ ändern? Das User Interface führt den Nutzer durch Zustandsanzeige, durch Feedback, durch Konsistenz, durch Fokussteuerung, Das User Interface entlastet den Nutzer durch Voreinstellung, durch Vorsorge zur Fehlervermeidung Das User Interface ist selbsterklärend durch Tooltipps, Statusbar, Entwicklung nutzerorientierter Anwendungen, Seite 79

80 Layout: Analyse Design Konstruktion Konstruktion Konkretes Programmieren und Zusammenfügen von Compnenten (Dialogbausteine), Container (hier: diverse Panel) und LayoutManager Anbindung an die Objekte in der Anwendung MVC Architektur mit interface und/oder Adapterklassen Kodierung in Android (Java) Entwicklung nutzerorientierter Anwendungen, Seite 80

81 Dialogstruktur, Navigationsübersicht Entwicklung nutzerorientierter Anwendungen, Seite 81

82 Navigationsübersicht: Screens und Abläufe Abteilungsleiter verteilt/ordnet zu, hat Termine und Auslastung im Auge (macht Qualitätssicherung) Anmeldung/ Login als Kunde, Mitarbeiter oder Abteilungsleiter Kunde macht Ersterfassung Mitarbeiter bearbeitet und testet Prozess vollständig und am Arbeitsablauf orientiert? Screens vollständig und nicht überfrachtet (d.h. aufgaben- Entwicklung nutzerorientierter Anwendungen, angemessen)? Seite 82

83 Navigationsübersicht Übersicht mit Workflow Notation und Vereinfachungen: Zustände als Skizzen/Screenshots Übergänge i.a. mit Linksklick Rmit Rechtsklick Rücksprung / Schließen Use Cases zurück UML passt nur bedingt für GUI; Zustandsdiagramm weiterentwickelt Entwicklung nutzerorientierter Anwendungen, Seite 83

84 Notation der Navigationsübersicht Anwendung starten beenden Aktionen neues Hauptfenster neuer Dialog/PopUp Rücksprung Ereignisse keine Angabe: linker Mausklick rechter Mausklick R Zustände Elementliste (abstrakter Screen) oder Layout-Skizze (konkreter Screen) oder Screenshot (konkret, Dokumentation) Bedingungen mit Shift/Umschalttaste mit Ctrl/Strg-Taste mit Alt-Taste S C A Entwicklung nutzerorientierter Anwendungen, Seite 84

85 High Level: Workflow ein Arbeitsablauf (Workflow) verkettet mehrere Anwendungsfälle verschiedener Benutzer (Mitarbeiter) Beispiel: Bestellung verbuchen Lieferung zusammenstellen Lieferschein schreiben Rechnung schreiben Zahlungseingang verbuchen Metapher: der Weg einer Akte durch eine Verwaltung typischerweise wird der nächste Mitarbeiter vom System durch eine Botschaft informiert, wenn der vorige seine Teilaufgabe erledigt hat kann mit Flussdiagramm / Programmablaufplan dargestellt werden Entwicklung nutzerorientierter Anwendungen, Seite 85

86 Low Level: Szenarien Szenario: Ablauf hinter einem Anwendungsfall / Screen Verfeinerung des Anwendungsfalls verbale Beschreibung aus Sicht des Benutzers jetzt unter Berücksichtigung wichtiger systeminterner Objekte systeminterne Objekte sollten dem mentalen Modelldes Benutzers entsprechen formale Beschreibung mittels Sequenzdiagramm Präzisierung der verbalen Beschreibung Benutzerereignisse rufen Methoden der Fensterklasse auf Entwicklung nutzerorientierter Anwendungen, Seite 86

87 Elemente der Programmiersprache, Bibliotheken JAVA UND ANDROIDCRASHKURS Entwicklung nutzerorientierter Anwendungen, Seite 87

88 Java Crash-Kurs: Interpreter-Prinzip Compiler übersetzt Quellcode in Byte Code Quellcode in.java-datei Bytecode in.class-datei Bytecode ist hardware-unabhängiger Befehlssatz für einen Interpreter wird z.b. im Internet übertragen Java Virtual Machine interpretiert Byte Code teilweise zur Geschwindigkeitssteigerung: Just-In-Time-Compiler übersetzt Byte Code in Maschinencode der Zielhardware Entwicklung nutzerorientierter Anwendungen, Seite 88

89 "Java ist streng objektorientiert" In Java gibt es dynamische Feldobjekte Laufzeitkontrolle (bzgl. Typen als auch bzgl. Feldgrenzen) Systemunabhängige Festlegung der elementaren Datentypen Garbage Collection ist Bestandteil der Sprache "keine" Pointer alle Objektvariable sind Pointer kein call-by-reference keine structs kein Dereferenzieren keines Pointerarithmetik spezielle Klassen zur Unterstützung der (einfachen) Entwicklung internetbasierter Anwendungen (Client-Server Komponenten: Applets und Servlets) Hauptprogramme verlieren an Bedeutung Entwicklung nutzerorientierter Anwendungen, Seite 89

90 Java ist streng objektorientiert! Java = C++-- Klassen, Objekte, Konstruktoren, Instanziierung wie unter C++ Syntax fast wie unter C++ (aber konsequenter) Vererbung/Inheritance Polymorphismus: gleicher Methodenname in unterschiedl. Klassen Überladen: gleicher Methodenname in gleicher Klasse bei unterschiedl. Parametern (Typ/Anzahl) kein Überladen von Operatoren ('+' hat immer die Bedeutung einer Addition; Ausnahme: Strings) "keine" Multiple Inheritance sondern interfaces Entwicklung nutzerorientierter Anwendungen, Seite 90

91 Informatikervision plattformunabhängig gut: Wertebereiche primitiver Datentypen sind festgelegt die Sprache ist meist nicht das Problem, sondern die Bibliotheken AWT 1.0, AWT 1.1, Swing, SWT vgl. MFC, OWL, Qt Zugriff auf Betriebssystemfunktionen die Implementation der Virtual Machine und ihrer Bibliotheken wird zur neuen Plattform VMs von Sun, Netscape, Microsoft,... Versionsnummern... hohe HW-Anforderung: viel Rechenleistung, viel RAM Entwicklung nutzerorientierter Anwendungen, Seite 91

92 sicher etliche Methoden mittlerweile "deprecated (ablehnen, missbilligen), weil "inherently unsafe" z.b. Thread.stop(), Runtime.runFinalizersOnExit(...) Ausführungszeitpunkte von finalize und garbage collector undefiniert Zuweisungen für double und long (64-Bit-Werte) sind nicht atomar d.h. könnenals 2 Maschinenbefehle implementiert und damit unterbrechbar sein (müssen aber nicht) Programmierer machen in jeder Sprache Fehler... Sie sind nicht von Ihrer Sorgfaltspflicht entbunden! Entwicklung nutzerorientierter Anwendungen, Seite 92

93 ausgereift große Zahl von "deprecated" Klassen, Feldern und Methoden grundlegender Wechsel der Ereignisverarbeitung von 1.0 auf 1.1 Java war ursprünglich für kleine Anwendungen gedacht; wurde dann zur Universalsprache mit vielen Spezialbibliotheken ausgebaut Entwicklung nutzerorientierter Anwendungen, Seite 93

94 Dateitypen und Tools auch IDE mit GUI-Editor LIB LIB class Bibliotheken ( jar ( h mindestens eine Klasse enthält main Editor java Compiler class Virtual Machine Editor java Compiler class Entwicklung nutzerorientierter Anwendungen, Seite 94

95 Java Development Kit (JDK) Entwicklung nutzerorientierter Anwendungen, Seite 95

96 Entwicklung mit JDK JDK enthält alle nötigen Werkzeuge Aufruf von der Kommandozeile (DOS-Box) Vorgehensweise MeineKlasse.java mit Notepad erstellen JAVAC MeineKlasse.java Compiler-Aufruf; erzeugt MeineKlasse.class SET CLASSPATH=vollständigerPfadname oder auch SET CLASSPATH=. damit die Java VM weiß, wo sie die Klassen suchen soll JAVA MeineKlasse Aufruf der Java Virtual Machine (Interpreter) MeineKlasse muß eine Methode main enthalten Entwicklung nutzerorientierter Anwendungen, Seite 96

97 Entwickeln mit Eclipse Project View zugehörige Dateien (Klassen) Source Klasse, Attribute, Methoden, Importe ResourceElemente der GUI-Oberfläche,,, Editor für mehrere Dateien Source Text-Editor Design Quelltext, grafischer Editor Doc Dokumentation wenn vorhanden Message View (Konsole, LogCat, Properties) Meldungen von Compiler und VM, Systemausgaben Entwicklung nutzerorientierter Anwendungen, Seite 97

98 Hello, World public class hello { public static void main(string[] args) { System.out.println ("Hello, World!"); } } // Datei: hello.java jede.java-datei enthält genau eine public Klasse Klassenname = Dateiname; Groß-/Kleinschreibung beachten! weitere Klassen ohne Angabe von public sind möglich die Java VM braucht ein Klasse mit einer Methodemainals Start es gibt keine freistehenden Funktionen/Methoden (in einer objektorientierten Programmiersprache) in String[] args werden Kommandozeilenparameter übergeben Entwicklung nutzerorientierter Anwendungen, Seite 98

99 Ausgabe auf die Konsole public class System { public static PrintStream out; } public class PrintStream extends FilterOutputStream { public void println(string x) {...} public void println(object x) {...} } der println-aufruf verwendet obige Klassen der Standardbibliothek System.out.println ("Hello, World!"); println ist überladen für alle einfachen Datentypen boolean, int,... jede Klasse, die von Object abgeleitet ist, hat eine Methode, die eine Textdarstellung des Objekts abliefert: String tostring() Entwicklung nutzerorientierter Anwendungen, Seite 99

100 Java-Sprachelemente Klassen, Objektvariable, Datentypen array exception throws try catch finally Iterator instanceof Generizität Zusicherungen (Assertions) Aufzählungstypen: enum strukturierte Kommentare: javadoc ArrayList interface Entwicklung nutzerorientierter Anwendungen, Seite 100

101 Allgemein package(1. Anweisung in der Datei) ordnet eine Klasse einem Paket (= Gruppe von logisch zusammenhängenden Klassen) zu (und werden auf Verzeichnissstrukturen abgebildet) Die Import Anweisung macht die entsprechende Klasse sichtbar/verfügbar instanceof-testet, ob ein Objekt Instanz einer best. Klasse ist:... if (obj instanceof class)... int, byte, short, long, float, double, boolean, char, sind intrinsic (= elementarer Bestandteil), Wrapper-Klassen (Integer, Float, Double, Boolean, ) existieren, weil Methoden nur auf Objekte angewendet werden können (z.b. Umwandlung von String in Wert, spezielle Vergleichsoperationen, ) Entwicklung nutzerorientierter Anwendungen, Seite 101

102 Bibliotheken: Packages Package ist ein Ordner im Dateisystem enthält mehrere.java-dateien und Subpackages (=Unterordner) Zugehörigkeit zu Package Import-Anweisung macht andere Packages verfügbar package meinpackage; eine Klasse: import java.util.arraylist; alle Klassen: import java.util.*; alle Klassen mit Kurzreferenz: import java.util; Kurzreferenz ist dann: util.arraylist; weltweit eindeutige Namen für wichtige Packages package de.h-da.fbi.projekt.meinpackage; spiegelt die Schachtelung der Verzeichnise wider Entwicklung nutzerorientierter Anwendungen, Seite 102

103 Klassen public class NeueKlasse extends Basisklasse {... } Konstruktor Ableitung 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) Entwicklung nutzerorientierter Anwendungen, Seite 103

104 Mutter aller Klassen: class Object viele Klassen sind (indirekt) von class Object abgeleitet public class Object { public String tostring() {...} //liefert Textdarstellung des Objekts public boolean equals(object obj) {...} // vergleicht Objekt-Inhalte protected Object clone() // dupliziert das Objekt throws CloneNotSupportedException {...} protected void finalize()// Aufruf vor der Garbage Collection throws Throwable {...} } Entwicklung nutzerorientierter Anwendungen, Seite 104

105 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 abstractmarkiert werden, wenn sie abstract Methoden enthält eine abstract Klasse kann nicht instantiiert werden! eine Klasse, die als finalmarkiert ist, kann nicht mehr als Basisklasse dienen! Entwicklung nutzerorientierter Anwendungen, Seite 105

106 Objekte Objekte werden immer dynamisch allokiert newliefert einen Zeiger auf das neue Objekt Klasse Objektreferenz = new Klasse (Parameter); delete gibt es nicht dynamisch allokierter Speicher wird automatisch vom Garbage Collector freigegeben, nachdem kein Zeiger mehr darauf zeigt der Aufrufzeitpunkt des Garbage Collector ist undefiniert; das Laufzeitsystem macht das irgendwann Destruktor gibt es nicht stattdessen Methode protected void finalize(); Aufruf von dem Garbage Collector d.h. unter Umständen nie! Entwicklung nutzerorientierter Anwendungen, Seite 106

107 Lebensdauer und Zugriffsrechte Ein Objekt existiert in Java/Android so lange, wie eine Referenz darauf existiert! manchmal auch ein bisschen länger, wie es dem Garbage Collector gerade gefällt public, protected, private wie in C++ jedes Element hat sein eigenes Zugriffsrecht Definition gilt (im Gegensatz zu C++) nicht für die nachfolgenden Elemente ohne Angabe bedeutet: private für Klassen public für Interfaces für Attribute und Methoden protected innerhalb des eigenen Packages private zur Sicherheit immer angeben außerhalb des eigenen Packages Entwicklung nutzerorientierter Anwendungen, Seite 107

108 Datentypen Primitive Typen plattformunabhängig definiert byte (8 Bit), short (16 Bit), int (32 Bit), long (64 Bit), alle als vorzeichenbehaftete 2er-Komplementdarstellung char (16 Bit vorzeichenlos, Unicode Umlaute in Variablen erlaubt) float (32 Bit), double (64 Bit); beide IEEE Standard 754 kein enum in Sinne von C++; stattdessen Klasse bzw. Interface: public enum Size { SMALL, MEDIUM, LARGE; } Referenztypen sind "Zeiger" Objektinstanzen, Interfaces oder Arrays Bem.: C++ macht keinen Unterschied zwischen primitiven Typen und Klassen! neue primitive Typen werden in C++ als Klassen realisiert (CBruch, CComplex, CString) Entwicklung nutzerorientierter Anwendungen, Seite 108

109 Initialisierung von Variablen automatisch initialisiert werden Klassenvariable ( = static) Instanzvariable ( = Attribute) Array-Komponenten (wenn es sich um Grundtypen handelt) Initialisierungswerte sind 0 für Zahlentypen false für boolean null für Objektreferenzen lokale Variable werden nicht automatisch initialisiert! Zugriff auf nicht initialisierte Variable bringt Fehler Entwicklung nutzerorientierter Anwendungen, Seite 109

110 Zeichenketten: String Klasse String char* gibt es nicht! (Inhalts- und Addressoperator gibt es nicht) Operand + zur Verkettung akzeptiert Werte beliebiger Typen oder Objekte beliebiger Klassen als Operand verwendet Methode tostring() Besonderheit: Operator + allokiert implizit einen neuen String! class Object hat die Methode tostring() liefert eine textliche Repräsentation des Objekts jede abgeleitete Klasse sollte diese Methode sinnvoll überschreiben nützlich auch zur Fehlersuche Entwicklung nutzerorientierter Anwendungen, Seite 110

111 Objektvariable: Zeiger versus Referenzen Java Referenzen entsprechen C++ Zeigern: Java Referenz kann nullsein man kann damit z.b. verkettete Listen schreiben Zugriff auf Elemente des Objekts mit. statt -> ein Pendant zu C++ Referenzen gibt es nicht! größere Sicherheit gegen Programmierfehler es gibt keine Zeigerarithmetik (so kann man sich auch nicht verrechnen...) man kann kein Objekt löschen, auf das noch Zeiger zeigen Entwicklung nutzerorientierter Anwendungen, Seite 111