Dienstag, 29. März 2011

Lernkartei I – Das Szenario

Flow-Design verspricht evolvierbare Software. Wenn ich ein Flow-Design Diagramm zeichne, ist das allerdings noch nicht nachzuvollziehen. So ein Diagramm mag verständlicher sein als andere Diagramme, doch warum sollte Software deshalb evolvierbarer sein?

Um die Evolvierbarkeit von Flow-Designs zu zeigen, ist mehr als ein Diagramm nötig. Nur eine Reihe von Diagramme, die zeigt, wie sich eine Software weiterentwickeln lässt, kann das Versprechen Evolvierbarkeit transportieren.

Deshalb habe ich mich entschlossen hier im Blog eine Software in kleinen Schritten zu entwickeln, zu evolvieren. Ich tue das live, d.h. ohne vorherige Planung. Ich sitze also nicht erst stundenlang, probiere herum und dokumentiere dann nur das wirklich funktionierende Endergebnis. Hier will ich vielmehr simulieren, was in größeren Projekten an der Tagesordnung ist: Unsicherheit.

Welche Features sollen wirklich in die Software rein? Welche Technologien sind die besten für den Zweck? Welcher Ansatz verspricht am meisten Erfolg? Wohin wird sich die Software entwickeln? Diese und andere Fragen treiben die Softwareentwicklung ständig um; damit will auch ich leben. Deshalb mache ich mir zunächst gar keine großen Gedanken über die Anforderungen; so ist garantiert, dass ich mich selbst mit Änderungswünschen überrasche.

Einen Ausgangspunkt muss das Ganze aber natürlich haben. Hier mein grober Wunsch, was ist haben möchte:

Auftrag Lernkartei

Ich möchte ein Lernkartei-Programm entwickeln. Mit dem kann ich dann zum Beispiel Vokabeln lernen. Der Lernstoff steht auf Karteikarten in Form von Fragen und Antworten. Auf der einen Seite jeder Karte die Frage, auf der anderen Seite die zugehörige Antwort.

Mehrere solcher Lernkarteikarten sind zusammengefasst zu einer Lernkartei, z.B. Karteikarten mit Französich-Vokabeln.

Der Trick bei einer Lernkartei ist nun, dass man ihre Karten nicht einfach von oben nach unten lernt, so wie sie auf dem Karteikartenstapel der Lernkartei liegen. Die Karten werden vielmehr in einen Kasten gesteckt, der mehrere Fächer hat.

image
Quelle: http://lernkartei.de/prinzip.php

Das Vorgehen beim Lernen ist einfach:

  • Neue Karten kommen ins erste Fach.
  • Sich abfragen kann man mit Karten in jedem Fach. Wird die Antwort gewusst, kommt die Karte ins nächste Fach; bei falscher Antwort wandert sie jedoch zurück in Fach 1.
  • Die Fächer haben unterschiedliche Kapazität. Deshalb kommen die Karten immer seltener dran, je weiter sie in den Fächern gewandert sind. Anfangen sollte man immer mit den Karten im ersten Fach. Die weiteren Fächer kommen dran, wenn sie voll sind.

Nicht alle Fächer sind also gleich. Das erste hat eine gewisse Sonderstellung, weil dorthin alle nicht gewussten Karten zurückwandern. Es füllt sich also am schnellsten mit neuen Karten und nicht gewussten.

Dazu kommen noch zwei weitere Fächer, die ich mal Halde und Archiv nenne. Die Halde sind enthält alle Karteikarten, die noch nicht in Fach 1 waren. Wer nicht kontinuierlich Karten anlegt und gleich in Fach 1 steckt, sondern eine fertige Lernkartei nutzen will, der fängt mit einer großen Halde an, von der dann einige Karteikarten in Fach 1 gesteckt werden.

Das Archiv bilden andererseits alle Karten, die aus dem letzten Fach als gewusst entnommen werden.

Bei einem Karteikasten mit n Fächern (1..n) hat die Halde die Fachnummer 0 und das Archiv die Nummer n+1.

Die Lernkarteien soll das Programm aus Textdateien laden. Ich stelle mir ein sehr einfaches Format vor:

Frage 1
Antwort 1

Frage 2
Antwort 2

Frage 3
Antwort 3

Fragen und Antworten stehen auf je einer Zeile und werden als Paare durch Leerzeilen getrennt.

Dieses Format nutzt ein Lernkarteiprogramm, das mir auf dem iPad ganz gut gefallen hat: iMemento Lernkarten. Ich möchte, dass meine Lernkartei-Dateien mit seinen kompatibel sind.

image

Die beiden Screenshots von iMemento zeigen, wie ich mir mein Programm auch ungefähr vorstelle. Es gibt ein Fenster mit einer Übersicht aller Lernkarteien und ein Fenster für das Lernen mit einer Lernkartei.

Das Programm soll zunächst mal auf dem Desktop als WPF-Anwendung laufen. Später könnte es umgestellt werden auf Silverlight oder MonoTouch oder sogar auf ASP.NET. Mal sehen…

Los geht´s…

Ich finde, das ist ein überschaubares, aber kein triviales Szenario. Es bietet mir (und vielleicht Ihnen auch) Nutzen, die Entwicklung lohnt sich also. Zu lernen gibt es immer etwas. Ein Lernkartei-Programm kann man immer mal zur Hand haben.

Zu diesem Szenario könnte ich nun natürlich viele Fragen stellen. Aber ich tue das bewusst nicht, sondern werfe mich im nächsten Artikel der Serie einfach in die Entwicklung. So will ich die in größeren Projekten quasi immer herrschende Unterspezifikation simulieren. Die übt ja einen nicht geringen Druck auf die Evolvierbarkeit aus.

WPF ist auch eine Herausforderung für mich. Mit der Technologie habe ich nicht viel Erfahrung. Allerdings treibt mit ein Ideal an: Ich möchte mit WPF eine strikte Trennung von GUI und dem Rest leben.

Wenn Sie mögen, grübeln Sie mit. Wie würden Sie dieses Szenario angehen?

Im nächsten Artikel mache ich den ersten kleinen Schritt in der Implementation. Jeder Artikel soll einen kleinen Anwendernutzen produzieren. Es gibt keine lange Planung oder Infrastrukturbastelei. Ran, rauf, rüber – aber mit Methode.

8 Kommentare:

Mike Bild hat gesagt…

Schöne Idee! Hab das bereits mal mit Stefans dotnet.pro dojo Vorschlag TodoList durch und gerade mal auf GitHub https://github.com/MikeBild/Demos_Samples veröffentlicht. Leider fehlt der Post zu Modell und vorgehen... mhh

-Cheers Mike

Thomas Sczyrba hat gesagt…

Hi Ralf,
tolle Idee - da bin ich gern dabei. "Es gibt eine lange Planung oder Infrastrukturbastelei." -> Sollte hier nicht statt "eine" eher "keine" stehen? ;-)

Gruß Thomas Sczyrba

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Danke für den Hinweis. Natürlich k(!)eine lange Planung :-)

Gerhard Völkl hat gesagt…

Hallo,

wo kann ich mehr über Flow-Design finden?

Gibt es darüber Bücher?

Viele Grüße

Gerhard Völkl

Ralf Westphal - One Man Think Tank hat gesagt…

@Gerhard: Hier ist eine Seite mit Links zum Thema:

http://clean-code-advisors.com/ressourcen/flow-design-ressourcen

Hannes Kochniß hat gesagt…

Bin mir gerade nicht bewusst, ob eine strikte Trennung von UI und Logik in WPF von Haus aus 100% möglich ist, in Silverlight braucht man dafür sowas wie Caliburn/Caliburn.micro (was ich persönlich als sehr elegant empfinde, der Eisenberg Effekt halt ;)).
Wenn es so ist, gehört das mMn zu einer sauberen Lösung.. bin mal gespannt, wie du da EBC einsetzt, warte mal auf nen grösseres praktisches Beispiel, bis jetzt mehr Theorie gelesen.

mythicrider hat gesagt…

Cool, bin auch schon gespannt auf ein echtes Beispiel!

Anonym hat gesagt…

Ja, auf ein sinnvoll großes Projekt mit "Flow Design" bzw. "EBC" warte ich schon lange. Karteikarten ... aha

In diesem Zusammenhang ein Hinweis auf eine Sendung auf 3sat aus der Reihe "Scobel":

"More is diffeernt" - Skalierungsprobleme und die Grenzen des Wissens
3sat.de/page/?source=/scobel/147661/index.html

Die Sendung war (und insbesondere die Studiogäste waren) sehr interessant und das Thema ist - glaube ich - auch in diesem Zusammenhang nicht unerheblich.

Kommentar veröffentlichen

Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.