Konzeption und Ziele eines Lernsystems

Die besprochenen Modelle haben vor allem das Ressourcenmanagement und den Betrieb in allumfassenden Lernplattformen vor Augen. Solange das geplante Lernsystem innerhalb der Möglichkeiten bleibt, könnenn diese verwendet werden, um auch fremden Content mit angemessenen Aufwand verwenden zu können.

Ein Lernsystem, das nicht abgedeckt wird wäre beispielsweise ein Übungsprogramm für Programmiersprachen, welches den Quelltext testet. Die Auswertung dieser Aufgaben ist bislang in den üblichen Modellen nicht enthalten. So ein System besteht etwa mit eduComponents.[6] Die Bearbeitung einer Aufgabe kann man sich dabei so vorstellen:

Geben sie eine Javascript-Funktion add5 an,
die 5 auf ihr einziges Argument addiert.

Auswerten

Eine Aufgabe zur Programmevaluation

Die Auswertung erfolgt durch Blackbox Softwaretests. Anstatt der üblichen Antwortauswahl-Fragen muss also ein Aufgabentyp erschaffen werden, der Testparameter und entweder eine Referenzfunktion oder aber erwartete Resultatwerte beinhaltet. Wenn wir Resultatwerte betrachten wollen, so wären das Parameter/Resultat-Paare. Bei Verwendung wird für jedes dieser Paare wird ein Ergebnis erzeugt, im einfachsten Fall ok, nicht ok und eine davon unabhängige Kategorie Laufzeitfehler. Dies allein wird für ein realistisches System jedoch nicht ausreichend sein, da die Lernressource unter Umständen bestimmten Tests spezielle Rückmeldungen zuordnen soll. Diese sollten jedoch getrennt von den eigentlichen Tests angegeben werden, da sie nicht durch das Evaluationsmodul, sondern durch den Coach der LTSA Referenzarchitektur ausgewertet werden. Eine Lösung ist die Referenzierung durch IDs.

LTSA-Position

Im LTSA Modell entspricht die vordefinierte Assessment Perspektive am ehesten unseren Anforderungen, die Betonung liegt auf der Auswertung. Wenn der Lerner mit einem Browser Lerncontent bearbeitet, wird die entsprechend Ressource in einer Session mitgeführt (Interaction Context). Das Evaluationsmodul sucht nun innerhalb der Ressource nach den Tests und führt diese zusammen mit der in der Anfrage mitgelieferten Funktion aus. Die Möglichkeiten mit einer einzelnen Funktion sind jedoch recht schnell erschöpft. Interessanter wird die Bearbeitung eines Moduls aus mehreren, zusammenarbeitenden Codeteilen.

data Tree a = Leaf | Branch a (Tree a) (Tree a)

foldTree :: b -> (a -> b -> b -> b) -> Tree a -> b
foldTree val fn Leaf = val
foldTree val fn (Branch x l r) = fn x (foldTree val fn l) (foldTree t b r)

traverseTree :: (a->b) -> Tree a -> Tree b
traverseTree _ Leaf = Leaf
traverseTree fn (Branch x l r) = Branch (fn x) (traverseTree fn l) (traverseTree fn r)

sumTree :: Num a => Tree a -> a
sumTree = foldTree 0 sum3
where sum3 x l r = x + (sumTree l) + (sumTree r)

data Tree a = Leaf | Branch a (Tree a) (Tree a)

foldTree :: b -> (a -> b -> b -> b) -> Tree a -> b
foldTree val fn Leaf = val
foldTree val fn (Branch x l r) =
traverseTree :: (a->b) -> Tree a -> Tree b
traverseTree _ Leaf = Leaf
traverseTree fn (Branch x l r) = Branch (fn x) (traverseTree fn l) (traverseTree fn r)

sumTree :: Num a => Tree a -> a
sumTree =
where sum3 x l r = x + (sumTree l) + (sumTree r)

Ein Haskell Modul und eine Lückentext Version

Diese Art von Test sollte nicht nur Fehler erkennen, sondern auch, an welcher der Stellen Fehler aufgetreten sind und welche Eingaben korrekt waren. Dies kann durch die Angabe von Beispielslösungen für jede Lücke gelöst werden, in der Auswertungsphase wird jede Lücke einzeln getested und die anderen Lücken mit den Beispielslösungen gefüllt. Solche Anforderungen müssen jedoch bei der Spezifikation der Ressourcen vorausgesehen werden.