Sitzung: Jeden Freitag in der Vorlesungszeit ab 16 Uhr c. t. im MAR 0.005. In der vorlesungsfreien Zeit unregelmäßig (Jemensch da?). Macht mit!

Martin Häcker/Java Kurs/Tag 4

<- Zurück zur Übersicht

LE 7: Strukturiertes Programmieren

Vortragende: Martin, Arthur Handout

  • Wiederholung von Tag 2
    • Da wirds viele studenten geben, die merkwürdige Vorstellungen von Objekten haben
    • Die wollen wir verarzten
  • Daran dann die Methodik erklären

Objektorientierung

  • public / private

Visualisierungen

  • Gedächtnisblase mit Programm/Spiel/Screenshot -> Sourcecode. Großes Fragezeichen in den Hintergrund.
  • Algorithmen als Java-Code hinschreiben?
  • Vier Gewinnt Bild auftreiben
  • Visualisierung Daumen

Methodik

  • Allgemein: Wie entwickelt man Programme Stück für Stück?
  • In der main-Funktion sachen aufrufen -> Da gehts dann bei Testen, weiter
    • Wie zerlegt man ein Problem in kleine Stücke
      • Top-Down vs. Bottom-Up <- letzteres empfiehlt sich für beginnende programmierer
    • Wie zeigt man das das kleine Stück das man schon hat funktioniert
  • Konkretes Vorgehen
    • Laufend kompilieren, nicht erst am Ende!
    • Laufend testen, nicht erst am Ende!
    • Wie man das macht

Praxis: Wie verwendet man das

Übungsaufgaben

  • Übung: kleines Spiel: "Vier Gewinnt"
    • In der Vorlesung schon anfangen wie man das designt
  • Selber ein schlechtes Programm "fehlerbeseitigen lassen"
  • schlechte Bezeichnungen durch bessere ersetzen lassen
  • Debuggen mit Eclipse
  • Fehler die hier eingetreten sind


Vier gewinnt

  • vier gewinnt
  • highscores
  • andere scores
  • = vorgabe GUI
  • = vorgabe evtl. billige KI die man evtl. im netz findet?

Tag 4

Komplexe Projektaufgabe als Gruppenarbeit

Projekt: Verschlüsselung

  • Ausarbeitung: Arthur
    • Häufigkeitsanalsyse -> dann entschlüsseln, doublettenhäufigkeit, triplettenhäufigkeit
    • Caesar Chifre, entschlüsseln, verschlüssseln
    • Gegenseitig Verschlüsselte Texte vorgeben

Nicht verwendete Vorschläge

  • Vorschlag C: Schiffe Versenken
  • Vorschlag B: Terminplaner
  • Vorschlag D: Studentenverwaltung
    • ein tool mit dem man
      • studenten in gruppen verwalten kann
      • den studenten gruppenweise noten geben kann
      • für jeden studenten eine statistik in eine datei schreiben kann
      • die daten in einer datei speichern und aus einer datei laden kann
      • = vorgabe GUI
  • Vorschlag F: eine netzwerk simulation
    • routing:
      • alle nodes broadcasten entlang ihrer links ins netz mit einer nachrichten-ID
      • die erste nachricht dieser node wird mit den entlang des pfades hinzugefügten nodes in einer routing tabelle statisch eingetragen
      • falls eine node ausfällt wird dies von einer node die dies feststellt ins gesamte netz gebroadcastet
      • wenn eine nodeA an eine nodeB etwas schicken will schickt sie dies an die node die in ihrer routing tabelle dieser node zugeordnet ist, diese schickt die daten dann weiter
    • für jeden link wird eine fehlerwahrscheinlichkeit eingetragen
    • die daten müssen geschützt werden..
    • am besten mit CRC
    • weiterhin könnte man die daten bitweise verschicken und eine weile im medium belassen und so eine propagation time ins spiel bringen
    • damit würden die links verschiedene qualitäten aufweisen
    • = vorgaben GUI zur anzeige des netzwerks
    • = das ganze müsste ja leider threadbased sein..
    • = vorgaben CRC?
    • zu schwer vom verständnis?
  • Vorschlag G: kratives zeichnen
    • man gibt ihnen eine GUI auf der sie einfach pixel linien und kreise zeichnen können
    • dann sollen sie möglichst kreativ irgendwelche styles darauf malen
    • irgendwelche effects?
    • für sowas braucht man schleifen evtl. arrays. da kann man ganz kreativ sein (was für einige leider nix ist)
    • = vorgabe: GUI und interface zum malen
  • Vorschlag H: eine fractal-application ähnlich der aus info1
    • = vorgabe: GUI und so
    • zu wenig für sie zu tun?
  • Vorschlag I: auswerter aussagenlogischer formeln
    • parsen einer DNF/KNF oder noch komplexerer logischer formeln und wahrheitswert bei (einer/allen) wahrheitsbelegung(en) untersuchen
  • Vorschlag J: textadventure
    • ein textadventure programmieren,
    • das über schnittstellen funktioniert und
    • wobei dann die ergebnisse aller gruppen die fertigwerden zusammengefügt werden können

Abschlussveranstaltung

  • Beste Lösung vorstellen
  • Schaum-Schokoladen-Küsse austeilen....
  • Abschließen
  • Feedback einsammeln
  • Ausblick
  • Anbindung an die Veranstaltung Info 2


Vielleicht noch

Robust Programmieren

Vielleicht zu fortgeschritten.... Siehe auch unser alter Vortrag zu Exceptions

Idee von Robuster Programmierung

  • wie kann man mit fehlern umgehen
    • fehler(un)freundliche systeme (Flugzeug, Auto)
    • bandbreite der fehler von lethal bis nervig, bis "man kann daraus etwas lernen" (feedback?)
    • Folgekosten abschätzen
  • was will man eigentlich:
    • etwas für die Benutzer tun
    • diese in die Lage versetzen Selbst etwas zu tun
    • Das ist eine Grundsätzliche Frage die man sich bei Software (und in der tat überall) stellen muss. Gleichzeitig ist das auch das Ziel einer persönlichen Weiterentwicklung, die sich eben auch (tja) in der Software die man schreibt wiederspiegelt.

Problemraum

  • Welche Fehler behandelt man?
  • welche gibt man an Benutzer weiter?
  • wie macht man das? (Schöne Dialogtexte, Gute Klare Fehlermeldungen)
    • Apple HIG schreibt: "Provide useful error messages to users when something does go wrong. An error message should clearly convey what happened, why it happened, and the options for proceeding. Offer a workaround if one is available and do whatever you can to prevent the user from losing any data. See "Alerts" for more information on how to provide useful error messages." Siehe auch: Writing good Alert messages
      • In fast allen nichttrivialen fällen, kann man den Fehler nicht selber behandeln, sondern nur dem Benutzer die Information geben sie zu beheben. (ex. "FileNotFoundException" -> "Bitte legen sie den externen Datenträger "Blub" ein, auf dem sich die Datei "Bla" befindet") Aufwendiger - ja, aber notwendig!

Wo treten Fehler auf:

  • Benutzereingaben die anders sind als Vorhergedacht
  • Code, der mit externen Systemen (Netzwerk, Dateisystem, Geräte, Messfühler, Benutzer) kommuniziert
  • Oder Code der Fehler / Bugs enthält
    • Nicht oder falsch verstandene eingabewerte für Methoden
    • dynamischer OO-Code, bei dem der Compiler nicht mehr alles prüfen kann
  • Tools
    • Eclipse
    • CVS/SVN?

<- Zurück zur Übersicht