Das didaktische und technische Konzept des virtuellen MootCourts

Didaktische Konzeption

Kurzbeschreibung
Der virtuelle MootCourt ermöglicht es, das Strafprozeßrecht induktiv im Sinne eines juristischen Rollenspiels am PC zu erlernen. Im Internet werden dazu realitätsnah gestaltete Rechtsfälle präsentiert, welche es für die Teilnehmer aus Verteidigersicht zu bearbeiten gilt, indem sie "gegen den PC antreten". Ergänzend werden Wissenskontrollen, Lernhilfen, Diskussionsforen etc. im Internet angeboten.

Teilnehmerkreis
Mitmachen kann jeder, der Kenntnisse im Strafverfahrensrecht zur Anwendung bringen, früher erworbenes Wissen auffrischen oder praxisbezogen lernen möchte. Insbesondere sind Studierende der Rechtswissenschaft, Rechtsreferendare und anwaltliche Berufsanfänger eingeladen, teilzunehmen. Um aus dem virtuellen MootCourt optimalen Nutzen ziehen zu können, erscheint ein Mindestmaß an Vorkenntnissen im Strafprozeßrecht jedoch sinnvoll. Es empfiehlt sich daher, vor der Teilnahme am MootCourt bereits eine Vorlesung zu den Grundzügen der StPO gehört zu haben bzw. eine solche parallel zum MootCourt zu besuchen.

Dem MootCourt zugrundeliegende Problemlage
Die Inhalte des Strafprozeßrechts sind auf herkömmliche Art und Weise, also allein in universitären Vorlesungen und Übungen sowie durch Lehrbücher, nur schwer vermittelbar. Diese Rechtsmaterie sträubt sich gewissermaßen gegen eine deduktive Vermittlung. Das Prozeßrecht braucht zwangsläufig die Lebendigkeit und das "Spielerische" der Rechtswirklichkeit. Andererseits sind vertiefte Kenntnisse im Strafverfahrensrecht bedeutsam für den Erfolg in der juristischen Berufspraxis. Es ist jedoch zu beobachten, daß auf diesem Gebiet der Kenntnisstand zahlreicher Kandidaten in den juristischen Prüfungen nur mäßig ist. Die Relevanz des Strafprozeßrechts wird vielen jungen Juristen erst beim Einstieg in die Berufspraxis klar. Dann bleibt aber oft keine Zeit mehr für eine gründliche, wissenschaftlich reflektierte Einarbeitung.
Hinzu kommt, daß die juristische Ausbildung an vielen Universitäten gegenwärtig immer noch stark auf die Richterperspektive bezogen ist. Dadurch ergeben sich Defizite im Bereich der Ausbildung in der spezifischen Sicht- und Denkweise von Strafverteidigern sowie im anwaltlichen Handeln. Die Arbeitsmarktsituation erfordert jedoch eine anwaltsorientierte Juristenausbildung, denn etwa drei Viertel der Studierenden werden nach Ablegen der juristischen Prüfungen als Rechtsanwälte tätig.

Der innovative Lösungsansatz: Virtueller MootCourt
Der virtuelle MootCourt ist dazu konzipiert, zur Lösung dieser Problemlage beizutragen. Als "MootCourts" bezeichnet man üblicherweise Lehrveranstaltungen mit dem Charakter von Prozeßrollenspielen, bei denen Studierende in die Rolle jeweils eines der Verfahrensbeteiligten schlüpfen und aus dessen Sicht einen Fall zu bearbeiten haben, indem sie die jeweils erforderlichen Prozeßhandlungen ausführen. In derartigen Lehrveranstaltungen wurden positive Erfahrungen gemacht, da Relevanz und Strukturen des Prozeßrechts hier anschaulich und praxisnah zu erfahren sind. Allerdings werden solche realen MootCourts - so erfolgversprechend sie unter didaktischen Gesichtspunkten auch sind - gegenwärtig an den Universitäten nicht flächendeckend für alle Studierenden angeboten, zumal sie sehr personalintensiv sind und gerade in der Juristenausbildung das zahlenmäßige Verhältnis von Lehrenden zu Lernenden ungünstig wie in keinem anderen Studiengang ist.
Diese Schwierigkeiten realer MootCourts vermeidet der virtuelle MootCourt mit seinem neuartigen didaktischen Konzept. Hier ist die Teilnehmerzahl prinzipiell unbegrenzt. Der Lernende bekommt anhand von Texten, insbesondere originalgetreu gestalteten Aktenstücken, einen Fall auf dem Spielbildschirm präsentiert, den er aus Verteidigersicht interaktiv am Computer zu bearbeiten hat. Er tritt dabei gewissermaßen "gegen den PC" an. Es gilt, durch zweckmäßige Verteidigungshandlungen (Ausübung von Frage- und Erklärungsrechten, Stellen von Beweisanträgen, Einlegen von Rechtsbehelfen etc.) die weitere Verfahrensentwicklung für den "virtuellen Mandanten" möglichst günstig zu beeinflussen. Dabei bewertet das Programm die Verteidigungshandlungen des Spielers und liefert Rückmeldungen. Diese sind  - je nach Fall - unterschiedlich ausgestaltet. Entweder bekommt der Teilnehmer sofort nach einer unzweckmäßigen Verteidigungshandlung einen Hinweis auf den Bildschirm oder das "virtuelle Strafverfahren" wird zunächst fortgeführt und der Spieler sieht dann in der weiteren Entwicklung des Falles, daß er eine unzweckmäßige Handlung ausgeführt oder eine zweckmäßige unterlassen hat, und wie sich sein Fehler auswirkt.  Diese Rückkopplung erlaubt es dem Lernenden, sein Verhalten zu reflektieren und sichert den Lernerfolg.
Durch die spielerische Ausgestaltung des virtuellen MootCourts soll auch der "Spaßfaktor" nicht zu kurz kommen.
Dabei soll das virtuelle Rollenspiel herkömmliche universitäre Veranstaltungen zum Strafprozeßrecht - also Vorlesungen, Übungen etc. - nicht ersetzen, sondern ergänzen und das dort erworbene Wissen anwendungsbezogen vertiefen. Ergänzend zu dem virtuellen Rollenspiel werden im Internet Wissenskontrollen, Lernhilfen, Diskussionsforen, Links etc. angeboten, um dem Interessierten eine Vertiefung und Wiederholung des in den Fällen vermittelten Stoffs zu ermöglichen. Die durch den virtuellen MootCourt vermittelten Inhalte betreffen den strafverfahrensrechtlichen Pflichtstoff in der ersten juristischen Prüfung. Der MootCourt eignet sich ferner für die Vorbereitung auf einschlägige Universitätsveranstaltungen in straf- oder strafverfahrensrechtlich geprägten Schwerpunktbereichen.  Sein Konzept ist auf die postuniversitäre Ausbildung im Referendariat übertragbar. Inzwischen wurde die Software - ergänzend zu den Vorlesungen und Arbeitsgemeinschaften - auch mehrfach erfolgreich im Rahmen des Bielefelder Kompaktkurses Anwalts- und Notartätigkeit eingesetzt, wobei sowohl Demonstration durch den Dozenten als auch Einzel- oder Gruppenarbeit der Kursteilnehmer möglich sind. Prinzipiell ist es sogar denkbar, ohne grundlegende Änderungen des MootCourt-Konzeptes auch Fälle aus dem Zivilprozeßrecht oder dem Verwaltungsprozeßrecht zu gestalten.

Technische Konzeption

Grundprinzip
Der virtuelle MootCourt ist in erster Linie eine webbasierte Anwendung. Jede Sitzung wird vom Benutzer über seinen Internet-Browser gestartet und beginnt mit dem Login-Vorgang. Dabei muß man das Bild einer Client-Server-Anwendung vor Augen haben, bei dem der Browser den Client bildet und der Server aus dem eigentlichen MootCourt-Programm besteht. Alle Anfragen des Internet-Browsers werden über den Webserver (in diesem Fall Apache) zur in Java geschriebenen Verteilerstation für die Datenpakete, dem "MootCourt Servlet Handler", weitergeleitet. Um hierbei allerdings eine - für eine bessere Übersichtlichkeit gebotene - Strukturierung mit Klassen und Paketen umsetzen zu können, tritt aus technischen Gründen zwischen den Apache-Server und den "Servlet Handler" noch ein "Servlet Wrapper", der im übrigen bezüglich der empfangenen Anfragen und Rückmeldungen transparent ist, d.h. diese unverändert weiterleitet.

Login
Baut ein Benutzer eine neue Verbindung auf, erhält er zunächst den Login-Bildschirm. Wie alles, was auf dem Bildschirm des MootCourt-Anwenders auftaucht, besteht dieser aus einer HTML-Seite, die vom "HTML-Generator" erzeugt worden ist. Der "HTML-Generator" wurde dabei vom "Servlet Handler" direkt aufgerufen. Nach Eingabe der persönlichen Daten reagiert der "Servlet Handler" auf das Login-Begehren, indem er diese Anfrage an den "User Agent" weiterleitet, der im Zusammenspiel mit dem "Case Handler" das eigentliche Gehirn des gesamten Projektes bildet. Während der "User Agent" für den Spielerstatus verantwortlich ist, wertet der "Case Handler" die Aktionen des Spielers in Abhängigkeit vom Spielstand aus und greift dabei auf das Aufbauschema des Falles zurück, durch das der Spielverlauf bestimmt wird. Bevor der "Case Handler" also in Aktion treten kann, muß der "User Agent" den neuen Spieler initialisieren. Alle dazu notwendigen Werte werden in einer Datenbank abgelegt, die über die Klasse "UserDB" angesprochen wird. Außerdem erzeugt der "User Agent" eine eindeutige Session-ID, damit die gestartete Sitzung von anderen laufenden Sitzungen unterschieden und bei Bedarf aus dem Speicher gelöscht werden kann.  Diese Session-ID wird an den Browser weitergereicht, dort als Cookie abgelegt und bei jeder weiteren Aktion an den "Servlet Handler" übermittelt, so daß sich alle Anfragen exakt einem Benutzer zuordnen lassen.

Fallauswahl
War der Login-Vorgang erfolgreich, erhält also der "Servlet Handler" vom "User Agent" eine positive Antwort statt einer Fehlermeldung, so fordert er vom "HTML Generator" die Seite mit der Liste der verfügbaren Fälle an, damit der MootCourt-Teilnehmer den Fall seiner Wahl bestimmen kann. Trifft dieser seine Entscheidung, kann das eigentliche Spiel seinen Lauf nehmen. Der "Servlet Handler" weist den "Case Handler" an, den Fall am Startknoten zu beginnen.

Knotenstruktur
Ein solcher Knoten ist das Grundelement der Fallstruktur. Er ist in etwa einem bestimmten Spielzustand gleichzusetzen, der definiert ist durch die zur Verfügung stehenden Hilfsmittel (z.B. Akten) und die von dort aus möglichen Aktionen sowie die damit erreichbaren Folgeknoten. Darüber hinaus liegt ein Anteil des Spielstandes in Variablen fest, die vom "User Agent" verwaltet werden, z.B. die bereits gelesenen Dokumente oder schon eingelegte Rechtsmittel. Diese Variablen sind ausschlaggebend dafür, ob die für einen Knoten vorgesehenen Handlungsmöglichkeiten oder Hilfsmittel tatsächlich verfügbar sind. Durch die Beschreibung der Knoten und der durch die Aktionen ausgelösten Veränderungen in den Statusvariablen ist ein Fall also bereits hinreichend definiert, hinzu kommen nur noch die jeweiligen Ton-, Bild- oder Textressourcen.
Das Format, in dem die Knoten abgelegt werden, ist die moderne Sprache XML ("Extensible Markup Language"). Sie bietet ein verbreitetes, also softwaretechnisch bereits gut unterstütztes und leicht zu implementierendes Format für den Austausch strukturierter Daten. Das Konzept von XML sieht die Erstellung von sogenannten DTD's (Dokument-Typ-Definitionen) vor, in denen der Aufbau, also das Grundschema der Daten, die der Benutzer archivieren/verwenden will, festgelegt wird. Zu einer solchen DTD können dann entsprechende XML-Dateien verfaßt werden. Für das Projekt virtueller MootCourt wurden in einer DTD (Mnode.dtd) die Merkmale und Eigenschaften eines Fall-Knotens allgemein festgelegt. Jeder Fall besteht aus mehreren XML-Dateien, die sich alle an diese DTD halten und jeweils einen Knoten aus dem Spielgeschehen beschreiben.
Zur Weiterverarbeitung werden die XML-Dateien in ein proprietäres Format konvertiert, die sogenannten JNF-Dateien ("Java Node Format"). Diese Aufgabe übernimmt der "JNFConverter", um die Bereitstellung bei Bedarf (d.h. bei Anfragen durch den "Case Handler") kümmert sich das Modul "JNFStorage". Letzteres lädt und entlädt die angeforderten Knoten dynamisch und sorgt dabei durch Caching für ein angemessenes Verhältnis zwischen Geschwindigkeit und Speichereffizienz.
Ein Spiel ist beendet, wenn der "CaseHandler" einen Endknoten erreicht und die erforderlichen Bedingungen erfüllt sind.
 
 

Der "Case Maker" - Mittler zwischen Jurisprudenz und Informatik

Problemlage
Bei der Gestaltung des virtuellen MootCourts prallten zwei Welten aufeinander: Jurisprudenz und EDV, Geisteswissenschaft und moderne Technologie. Nur wenige sind Wanderer zwischen diesen Welten, fähig, abstrakt wie ein Jurist zu denken und zugleich analytisch wie Programmierer. Im Rahmen des virtuellen MootCourts führte diese Ausgangssituation zu konkreten Schwierigkeiten bei der Falleingabe. Hier stellt sich das Problem, die zunächst gedanklich oder auf dem Papier fertiggestellten neuen Fälle aus der Vorstellung des juristischen Autors in eine Form zu bringen, die vom PC verstanden wird. Doch welcher Jurist spricht schon fließend die Programmiersprache XML?
Es liegt auf der Hand, daß es unpraktikabel ist, die gleichen Personen, die juristisch anspruchsvolle Fälle ausarbeiten, mit der ebenfalls nicht einfachen Codierung dieser Strukturen gemäß der XML-Syntax zu betrauen. Dies würde eine Doppelqualifikation voraussetzen, eine natürlich ungewollte Einschränkung des eingabefähigen Personenkreises. Darüber hinaus sind große XML-Dateien, solange sie im Quelltext bearbeitet werden, unübersichtlich. Auch gängige, DTD-unabhängige XML-Editoren erleichtern die Eingabe nur marginal, da sie nicht auf die speziellen, durch die Datenstruktur vorgegebenen Anforderungen des MootCourt-Systems zugeschnitten sind.
Es stellte sich also die Frage, wie man auf effizientem und für Nichtinformatiker beschreitbarem Wege das MootCourt-System mit neuen Fällen "füttern" konnte.

Lösung: Ein eigenes Programm zur Eingabe der Fälle
Naheliegend war, die komplizierte Umwandlungsarbeit selbst wieder einem Computerprogramm zu übertragen. Es müßte für Juristen, also für jedermann, bedienbar sein und die Eingabe neuer Fälle erlauben, als Ergebnis sollte es die berüchtigten XML-Dateien liefern. Genau diesen Zweck erfüllt der im Zuge des Projekts entwickelte CaseMaker. Dieser stellt ein leicht handhabbares, intuitiv bedienbares Programm dar, mit dem ohne weitere Hilfsmittel die Fälle vom Reißbrett weg direkt in das System eingespeist werden können. Dem Wesen nach ist der CaseMaker ein spezialisierter XML-Editor, mit dem sich die XML-Dateien anlegen lassen, welche die Fallstruktur in sich tragen. Spezialisiert deshalb, weil er an die für die MootCourt-Fälle entworfene DTD angepaßt ist und daher auch nur für die Bearbeitung von XML-Dateien tauglich ist, die diesem Schema entsprechen.
Während als Plattform für den MootCourt-Server und den darauf laufenden Kern des MootCourt-Programms Linux dient, läuft der CaseMaker unter Microsoft Windows (Windows 9x und spätere), damit er zur leichteren Erstellung und Bearbeitung von Dokumenten auf die für dieses Betriebssystem bekannten HTML-Editoren (Netscape Composer / Word etc.) und Grafikprogramme zugreifen kann. Darüber hinaus ist Windows auf den Arbeitsrechnern in der Universität das Standardsystem.
Um jederzeit Aktualisierungen an den vorhandenen Fällen durchführen zu können, liest der CaseMaker unabhängig vom Arbeitsplatz, von dem aus er ausgeführt wird, die zu bearbeitenden Daten per Netzwerkverbindung direkt vom MootCourt-Server und speichert vorgenommene Änderungen in gleicher Weise wieder auf dem Webserver ab, so daß sie ohne Verzögerung im Internet wirksam werden.
Die Basis der Fallstruktur bildet - wie vorangehend dargestellt - das Knoten-Konzept. Jeder Knoten entspricht dabei einer Spielsituation, die durch Dokumente, Handlungsmöglichkeiten und sonstige Hilfsmittel gekennzeichnet ist. Je nach dem Verhalten, für das sich der Spieler entscheidet, kann er dann zu einem folgenden Knoten gelangen. Die einzelnen Knoten sind dabei jeweils in einer XML-Datei beschrieben. Hier finden sich insbesondere auch Verweise auf Grafiken und HTML-Dateien, die die Situations- und Handlungstexte enthalten. Der CaseMaker zeigt nun den Inhalt jeweils eines der Spielknoten an und ordnet dabei Begrüßungstext, Handlungen, Navigationsleiste etc. übersichtlich an. Zur Anzeige von HTML-Dokumenten ist eine Browserfunktionalität integriert. Für Bearbeitungszwecke wird der jeweils im Windowssystem festgelegte Standard-HTML-Editor nachgeladen, also z.B. Netscape Composer, MS Frontpage, DreamWeaver pp.. Alle für die Fallgestaltung wichtigen Variablen sind in entsprechenden Feldern repräsentiert und lassen sich verändern. Dies sind vor allem Handlungsoptionen, Dokumente und die Bedingungen, unter denen beide angezeigt werden bzw. ausführbar sind.
Durch die automatische Syntaxüberprüfung wird gewährleistet, daß nur der DTD entsprechende (= valide) XML-Dokumente angelegt und abgespeichert werden. Etwaige Unregelmäßigkeiten werden beim Laden mit genauen Angaben über den aufgetretenen Fehler behandelt. Dies ist ein enormer Fortschritt gegenüber einer Eingabe von Hand, bei der stets Fehler unterlaufen, die dann nur sehr mühsam zu finden sind. Voraussetzung dafür ist die Fähigkeit des CaseMakers, XML-Dateien zu parsen.
Der CaseMaker zeigt nun den Inhalt jeweils eines der Spielknoten an und ordnet dabei Begrüßungstext, Handlungen, Navigationsleiste etc. übersichtlich an. Zur Anzeige von HTML-Dokumenten ist eine Browserfunktionalität integriert. Für Bearbeitungszwecke wird der jeweils im Windowssystem festgelegte Standard-HTML-Editor nachgeladen, also z.B. Netscape Composer, MS Frontpage oder DreamWeaver.
Damit stellt der CaseMaker ein Instrument dar, mit dem ohne große Spezialkenntnisse im Bereich der Informatik jederzeit evtl. notwendig werdende Aktualisierungen der Fälle durchgeführt oder auch neue Fälle gestaltet werden können.
 

MootCourt in der Literatur
Ein Aufsatz über den virtuellen MootCourt von Barton, Berenbrink und Freund ist in der Jura 2002, S. 641 ff. erschienen.