TGI als Beispiel für einen Workflow

Für die Anforderungsanalyse wurden Workflows für die Vorlesung Technische Grundlagen der Informatik, für das Rechnernetzepraktikum, für ein Fopra und eine Diplomarbeit erstellt und analysiert. Der Workflow zu TGI (siehe Abbildung ) wurde nach der Implementierung der Anwendung als Beispiel realisiert und nach der Einrichtung des Systems in der Praxis getestet. Der Workflow besteht aus 10 Schritten, wobei der Schritt ``Klausur'' einen Sub-Workflow mit seinerseits 11 Schritten enthält. Der Subworkflow wurde eingerichtet, da mehrere Klausuren abgehalten wurden. Im folgenden werden die einzelnen Workflow-Schritte kurz beschrieben.

 

Abbildung:  Der TGI-Workflow

1.

Der Workflow-Schritt ``Personaleinteilung'' nutzt die Modul-Skripte 'module_Personal.inc.php' und 'modul_SQLBedingung'. Letzteres Ermöglicht die Angabe mehrerer SQL-Bedingungen, die erfüllt sein müssen, bevor der Schritt als erledigt gekennzeichnet werden kann. In diesem Schritt wird überprüft, ob in der Relation 'arbeitet_für_vorlesung' ein Tupel für diese Vorlesung eingetragen wurde. Das erste Modul-Skript enthält drei DBTable-Submodule. Das erste stellt das Personal für die Vorlesung dar. Die beiden anderen geben eine Liste der Mitarbeiter bzw. Studenten wieder. Aus diesen Listen können Personen ausgewählt werden, die dann zum Vorlesungspersonal hinzugefügt werden.

2.

Im Schritt ``Raumeinteilung'' wird wieder das Modul für SQL-Bedingungen verwendet. Hier wird geprüft, ob ein Raum für die Vorlesung (Relation 'vorlesung_findet_statt_in') reserviert wurde. Das Modul 'module-Raum.inc.php' besteht aus zwei DBTable-Submodulen, eines für die Liste der reservierten Räume, eines für eine Liste aller Räume. Aus der zweiten Lisete können Räume ausgewählt werden, die dann zu den reservierten Räumen hinzugefügt werden. In der Tabelle der reservierten Räume kann der Wochentag, die Uhrzeit und Belegungsdauer festgelegt werden.

3.

Der Schritt ``Vorbesprechung planen'' ist ein reiner Informationsschritt, der nur einen Text ausgibt. Es wird kein Modul eingebunden.

4.

Der Schritt ``Festlegen der Übungsgruppen'' verwendet wieder das Modul für die Überprüfung einer SQL-Bedingung. Diesmal wird kontrolliert, ob eine Übundelgsgruppe für die Vorlesung angelegt wurde. Nur wenn dies der Fall ist, kann der Schritt erledigt werden. Des weiteren wird das Modul 'module-Uebungsgruppen.inc.php' eingebunden. Es besteht aus zwei DBTable-Submodulen. Das erste spiegelt die angelgten Übungsgruppen wieder, wobei der Tutor ausgewählt werden kann. Das zweite stellt die reservierten Räume. Aus dieser Liste können die für die Übungsgruppen vorgesehenen Räume ausgewählt werden, die dann in der oberen Tabelle als neue Übungen erscheinen.

5.

``Anmeldung zur Vorlesung'' ist einer der aufwändigsten Schritte. Er ruft das Modul 'module-Vorlesungsanmeldung.inc.php' auf, das mehrere Submodule enthält. Als erstes gibt es ein Extmod-Submodul, mit dessen Hilfe eine temporäre, öffentliche Tabelle in der Datenbank angelegt wird. In diese Tabelle werden die Daten der Studenten aufgenommen, die sich zur Vorlesung angemeldet haben. Die vier folgenden Submodule sind vom Typ DBTable. Im ersten wird eine Liste der angemeldeten Studenten dargestellt, die bereits in den geschützten Bereich der DB übernommen wurden. Die nächste Tabelle stellt die in der temporären Tabelle enthaltenen Anmeldungen gruppiert nach Matrikelnummer und Universität dar. Dies ist notwendig, weil davon ausgegangen werden muss, dass Merhfachanmeldungen vorkommen. Zur jeweils obersten Zeile dieser Tabelle werden in der Tabelle des nächsten Submoduls alle zugehörigen Tupel (nicht gruppiert) dargestellt. Außerdem wird ein Eintrag aus der Relation 'student' hinzugenommen, wenn dort einer zur aktuellen Kombination aus Matrikelnummer und Universität passt. Aus dieser Tabelle kann dann der richtige Datensatz ausgewählt werden, wodurch er in die Relation 'student_besucht_vorlesung' eingetragen wird. Gleichzeitig werden alle zur aktullen Matrikelnummer/Universität gehörenden Tupel aus der temporären Tabelle gelöscht. Der Benutzer der Anwendung kann sich außerdem dafür entscheiden, dass die Tupel nur gelöscht werden, ohne Übernahme in den geschützten Bereich der DB. Das letzte DBTable-Submodul gibt die Relation 'student' wieder. Auch daraus können Studenten in die Relation 'student_besucht_vorlesung' übernommen werden. Als zweites Modul verwendet dieser Workflow-Schritt wieder 'module-SQLBedingung.inc.php', wobei überprüft wird, ob ein Eintrag in 'student_besucht_vorlesung' vorliegt.

6.

Der Schritt ``Einteilung der Übungsgruppen'' verwendet das Modul 'module-Uebungseinteilung.inc.php', das zwei Submodule und weitere interessante Details enthält. Das erste Submodul ist vom Typ DBTable und zeigt die aktuelle Belegung der Übungsgruppen, bietet aber keine Möglichkeit der Datenmanipulation. Das zweite Submodul, ebenfalls vom Typ DBTable, gibt einen Überblick, wie sich die Präferenzen Studenten über die einzelnen Übungsgruppen verteilen. Die Tupel mit den gleichen Präferenzen aus der Relation 'student_besucht_uebung' werden dabei gruppiert. Wird die Aktion ``Ändern'' ausglöst, so werden die gruppierten Tupel einzeln aufgeschlüsselt und der Mitarbeiter kann bei Bedarf auf die Übungsgruppeneinteilung Einfluss nehmen. Neben den Submodulen wird im PHP-Skript eine Funktion implementiert, die eine automatische Übungsgruppeneinteilung vornimt. Allerdings wird dabei nur die erste Präferenz der Studenten berücksichtigt. Außerdem enthält das Modul-Skript nicht nur eine main-Funktion, sondern auch eine fullpage-Funktion. Damit wird im Browser eine Liste mit allen Übungsteilnehmern und den zugewiesenen Übungsgruppen ausgegeben. Diese Liste kann mit Hilfe des Browsers ausgedruckt und als Aushang verwendet werden. Das Modul für die SQL-Bedingungen prüft schließlich, dass allen Studenten, die an den Übungen teilnehmen wollen, eine Gruppe zugeteilt wurde.

7.

Der Workflow-Schritt Klausur dient als Einstiegspunkt in den gleichnamigen Unterworkflow. Dazu dient das Modul 'parent_module-Klausur.inc.php'. Modul 'module-Klaururtabelle.inc.php' enthält ein DBTable-Submodul für die Verwaltung der einzelnen Klausuren. Das Modul für die SQL-Bedingungen stellt sicher, dass eine Klausur existiert.

(a)

Der erste Schritt im Klausur-Subworkflow heisst ``Klausurräume festlegen'' und nutzt das Modul 'module-KlausurRaum.inc.php'. Er enthält zwei DBTable-Submodule, das eine stellt die ausgewählten, das andere alle verfügbaren Räume dar. Wie üblich überprüft das SQLBedingung-Modul, ob mindestens ein Klausurraum ausgewählt wurde, bevor der Schritt erledigt werden kann.

(b)

Als nächstes folgt der Schritt ``Ankündigung der Klausur''. Hier wird das Modul 'module-ExternesProgramm.inc.php' eingebunden, das ein ExtProg-Submodul zum Aufruf eines externen Programms enthält. Hiermit könnte das Ausdrucken eines Aushangs oder das Freischalten einer Web-Seite initiiert werden.

(c)

Der Schritt ``Anmeldung zur Klausur'' ist mit dem Schritt ``Anmeldung zur Vorlesung'' weitestgehen identisch.

(d)

Der Schritt ``Personal für die Klausuraufsicht'' enthält im Modul 'module-KlausurAufsicht.inc.php' drei DBTable-Submodule. Die letzten beiden enthalten je eine Liste der Lehrstuhlmittarbeiter und der Studenten. Aus diesen Listen können Personen für die Klausuraufsicht ausgewählt werden und erscheinen dann in der Tabelle des ersten DBTable-Submoduls. Bevor der Schritt als erledigt markiert werden kann, muss mindestens eine Aufsichtsperson ausgewählt worden sein. Dies stellt eine entsprechende SQLBedingung sicher, die vom Modul 'modul-SQLBedingung.inc.php' geprüft wird.

(e)

Das Modul 'module-KlausurRaumeinteilung.inc.php' enthält zunächst eine Funktion mit der die Verteilung der Studierenden auf die Klausurräume durchgeführt werden kann. Die Verteilung erfolgt alphabetisch. Die aktuelle Einteilung wird von einem DBTable-Submodul dargestellt, wobei nach den Klausurräumen gruppiert werden. Möchte der Betreuer der Vorlesung ändern, kann er auf den Ändern-Button klicken. Die zur Gruppe gehörenden Tupel werden dann einzeln aufgelistet und die Räume können geändert werden. Darüber hinaus verwendet der Workflows-Schritt ``Verteilung auf die Klausurräume'' auch wieder das Modul zur Überprüfen einer SQL-Bedingung. Sie stellt diesmal sicher, dass jeder Student einen Sitzplatz hat.

(f)

Der Workflow-Schritt ``Festelgen der Klausuraufgaben'' nutzt die Module 'module-KlausurAufgaben.inc.php' und 'module-SQLBedingung.inc.php'. Das erste Modul enthält ein DBTable-Submodul, mit dessen Hilfe die Aufgaben verwaltet werden können. Das andere Modul kontrolliert, ob auch Aufgaben in die Datenbank eingetragen wurden.

(g)

Der Workflow-Schritt ``Ausdrucken der Klausurunterlagen'' ruft das Modul 'module-Drucken.inc.php' auf, das seinerseits ein ExtProg-Submodul enthält.

(h)

Der Workflow-Schritt ``Klausur abhalten'' verwendet kein Modul, es dient nur als ``Platzhalter'' bis die Klausur geschrieben ist.

(i)

Der Schritt ``Klausur korregieren'' bedient sich des Moduls 'module-KlausurKorrektur.inc.php'. Es enthält ein ExtMod-Submodul, mit dessen Hilfe ein View erzeugt und verwaltet wird. Dieser View wird für die Korrektoren freigeschaltet und dient der Eingabe der Klausurpunkte in die Datenbank. Damit auch alle Klausuraufgaben korregiert worden sind, führt das Modul 'module-SQLBedingung.inc.php' eine entsprechende Überprüfung durch.

(j)

Für die ``Auswertung der Klausur'' ist das Modul 'module-KlausurAuswertung.inc.php' vorgesehen. Es enthält zwei Submodule vom Typ DBTable. Das erste Submodul zeigt in einer Tabelle für jeden Student die erreichten Punkte und die entsprechende Note an. Das zweite Submodul enthält eine Liste aller Studenten. Aus ihr kann ein Student in die erste Tabelle eingefügt werden, falls noch eine Klausur auftaucht die bisher nicht korregiert wurde. Darüber hinaus enthält das Modul eine Funktion, die die Noten automatisch vergibt. Der dazu notwendige Notenschlüssel kann über ein HTML-Formular eingegeben werden. Dem Erzeugen eines Aushangs dient die fullpage-Funktion im Modul. Das Modul 'module-SQLBedingung.inc.php' stellt diesmal sicher, das jeder Klausurteilnehmer mit einer Note bedacht wurde.

(k)

Der Schritt ``Klausur-Ende'' bindet das Modul 'end_module-Klausurende.inc.php' ein. Es schließt den Subworkflow ``Klausur'' ab.

8.

Im Hauptworkflow geht es weiter mit der ``Vergabe der Scheine''. Das Modul 'module-Scheinvergabe.inc.php' enthält zwei DBTable-Submodule. Die erste listet die vergebenen Scheine auf und ermöglicht bei Bedarf Korrekturen. Die zweite Tabelle stellt die in den Klausuren erzielten Ergebnisse der einzelnen Studenten dar. Ist der Betreuer der Vorlesung der Meinung, dass das erzielte Ergebnis eines Studenten ausreicht, kann für ihn ein entsprechender Schein eingetragen werden.

9.

Was noch zu tun bleibt, ist die ``Fertigstellung der Scheine''. Dazu dient das Modul 'module-Scheinfertigstellung.inc.php'. Es verwendet ein ExtProg-Submodul, mit dessen Hilfe ausgewählt werden kann, welche Scheine gedruckt werden sollen. Das Drucken übernimmt ein exterenes Programm, dem die notwendigen Daten aus der Datenbank übergeben werden.

10.

Der Schritt ``TGI-Ende'' schließt den Workflow ab.