Softwaretechnik 2004: Beispielanwendung

LVV - Lehrveranstaltungs-Verwaltungs-Programm

Use-Case-Diagramm

Aufbau der Use-Case-Beschreibung

Die Beschreibung des Use-Case-Diagramms besteht aus zwei Teilen: Der Beschreibung der einzelnen Aktoren in der Anwendung sowie der Beschreibung der einzelnen Use-Cases.

In der Aktoren beschreibung muss schon ein grober Überblick über die Use-Cases dieses Aktoren gegeben werden. Hier wird wiederum viel aus der Anforderungsdefinition auftauchen (in diesem Fall ist sogar die Strukturierung ähnlich), trotzdem darf nicht gekürzt oder auf die Anforderungsdefinition verwiesen werden. Jeder Dokumentationsteil sollte ohne Detailkenntnis der anderen Teile verständlich sein. Der Lehrbeauftragte sieht die Einzelteile über einen Zeitraum von mehreren Wochen als Stückwerk und kann sich nicht jedes Detail von 5 oder mehr Arbeitsgruppen merken.

Administrator

Der Administrator ist der einzige Benutzer, der Stammdaten verwalten darf.

Das bedeutet:

• Er legt Lehrbeauftragte an, bearbeitet ihre Daten und löscht sie.

• Er legt Studenten an, bearbeitet ihre Daten und löscht sie.

• Er legt Allgemeine Lehrveranstaltungen an, bearbeitet ihre Daten und löscht sie.

• Er legt konkret durchgeführte Lehrveranstaltungen eines Semesters an, bearbeitet ihre Daten und löscht sie.

Er hat Einsicht in alle weiteren Daten. Außerdem darf er Abgaben / Bewertungen innerhalb einer beliebigen Lehrveranstaltung bearbeiten. Der Grund hierfür ist, dass nach dem Ausscheiden eines Lehrbeauftragten ansonsten keine nachträgliche Korrektur der Note mehr möglich wäre.

Sonderfälle dokumentieren:

Hier hat sich während der Beschreibung der Aktoren herausgestellt, dass es sinnvoll sein kann, dem Administrator das Bearbeiten von Bewertungsinformationen zu gestatten (obwohl in der Anforderungsdefinition hiervon nicht die Rede war). Solche Besonderheiten müssen mit Begründung definiert werden.

Lehrbeauftragter

Der Lehrbeauftragte ist für die Durchführung einer Lehrveranstaltung zuständig.

• Er muss Studenten in Arbeitsgruppen einteilen.

• Er muss anstehende Abgaben erfassen und die konkreten Abgaben der Studenten ins System eintragen (eventuell mit anhängenden Dateien) und bewerten. Bei einer Benotung steht ihm die Möglichkeit offen, die Bewertung dem Studenten per Mail durch einen Klick mitzuteilen. Alternativ kann er dem Studenten auch einen individuellen Ausdruck erstellen.

• Am Semesterende erklärt er die durchgeführten Veranstaltungen als abgeschlossen, und erzeugt eine Notenliste pro Veranstaltung. Nach dem Abschließen kann kein Student mehr Abgaben bearbeiten, der Lehrbeauftragte kann aber nachkorrigieren.

Der Lehrbeauftragte darf nur Lehrveranstaltungen bearbeiten, bei denen er der Durchführende ist.

Die Aktoren „Lehrbeauftragter“ und „Administrator“ können in einer Person vereinigt sein, d.h. ein Lehrbeauftragter kann auch Stammdaten administrieren. Im Programm wird es so aussehen, dass Lehrbeauftragte und Administratoren über das selbe Stammdatenobjekt verwaltet werden und die Unterscheidung der Rollen nur durch Attribute des Stammdatenobjekts erfolgt.

Falls ein Lehrbeauftragter auch Administrator ist, dann darf er diese Rechte für alle vorhandenen Lehrveranstaltungen durchführen.

Verbindungen zwischen Aktoren:

Manchmal kann ein Benutzer eines Programms in mehreren Rollen auftauchen. Falls dies der Fall ist, sollten diese Verbindungen genau dokumentiert werden. Die Verbindung muss nur in einer Rolle detailliert beschrieben werden, aber den anderen Verbindungspunkten sollte ein Verweis auf diese Beschreibung auftauchen.

Auf jeden Fall gehört in die Beschreibung der Aktoren, unter welchen Bedingungen ein Programmbenutzer in einer bestimmte Rolle auftaucht.

• Ein Student darf alle Abgaben seiner eigenen Arbeitsgruppe einschließlich der Bewertungen einsehen (wobei er mehrfach pro Semester die Arbeitsgruppe wechseln kann).

• Außerdem darf er eine anstehende Aufgabe abgeben. Eventuell ist es nötig, dass eine solche Abgabe in mehreren Teilen erfolgt (z.B. weil in einer Arbeitsgruppe mehrere Studenten jeweils Teile der Gesamtabgabe bearbeitet haben und diese einzeln abgeben).

• Er kann eine Übersicht über alle bisher geleisteten Abgaben einsehen.

• Er darf die in im Stammdatenobjekt „Student“ hinterlegte E-Mail-Adresse bearbeiten.

Er darf keinen Zugriff auf Daten anderer Studenten haben (weder Stammdaten noch Studenten). Ein lesender Zugriff auf z.B. Lehrveranstaltungsdaten wäre zwar denkbar, ist im Rahmen dieser Anwendung allerdings nicht notwendig.

Dokumentation dessen, was eine Rolle nicht darf:

Im Beispiel des Studenten ist es extrem wichtig, dass seine Rechte eingeschränkt sind, da der Datenschutz es nicht zuläßt, dass er Daten anderer Studenten frei einsehen kann (vom Bearbeiten ganz zu schweigen). Solche Fälle müssen ebenfalls dokumentiert werden.

Beschreibung der Use-Cases

Alles in einen logischen Zusammenhang bringen !

Bei der Beschreibung der Use-Cases sollte ein „Roter Faden“ erkennbar sein. Man arbeitet die Anwendung von unten nach oben (von der Eingabe der Stammdaten zu den sog. Bewegungsdaten) und von vorne nach hinten (zeitlicher Ablauf) ab. Dadurch kann man bei einem „höherwertigen“ Use-Case auf bereits Erklärtes verweisen und für den Leser präsentiert sich die Dokumentation wie aus einem Guß.

Im folgenden wird begonnen mit der Benutzeranmeldung, weil dies der erste Schritt für jeden Benutzer ist. Anschließend wird zuerst das Anlegen der Stammdaten beschrieben (die Administration), danach das Anlegen von Abgaben und Arbeitsgruppen in einer Lehrveranstaltung (die sogenannten Bewegungsdaten) sowie die Bewertung von Abgaben, abschließend die Rolle des Studenten.

Anmelden:

Für jeden Benutzer, egal in welcher Rolle, sieht die Anwendung zuerst einmal generell gleich aus: es erscheint ein Anmeldebildschirm, in dem nach Login-Namen und Passwort gefragt wird. Nach dem Verifizieren der Eingabedaten wird er einer der drei oben genannten Rollen zugeordnet (es wird geprüft, ob er Student oder Lehrbeauftragter ist, in letzterem Fall kann er außerdem Administrator sein), dadurch entstehen für ihn die Eingabeoptionen, die im folgenden als einzelne Use-Cases beschrieben werden.

Stammdatenverwaltung: Lehrbeauftragten anlegen

Lehrbeauftragte darf nur ein Administrator anlegen. Es müssen folgende Daten erfaßt werden: Name, Anmeldeinformationen (Login und Passwort) sowie die Angabe, ob dieser Lehrbeauftragte das Administrationsrecht hat.

Bei der Eingabe des Logins muss sichergestellt werden, dass es keinen weiteren Lehrbeauftragten oder Studenten mit dem gleichen Login gibt. Ein leerer Login ist nicht zulässig, ebensowenig wie das leere Passwort.

Die Option, den Login nur in bestimmten Zeiträume zuzulassen, wird nicht implementiert. Dies kann über die Benutzerverwaltung des FH-Rechnernetzes ausgeschlossen werden.

Für welche Rolle gilt der Use-Case ?

In diesem Fall ist die Aktion nur von der Administrator-Rolle ausführbar.

Sonderfälle beachten:

Bei der Eingabe des Login-Namens sind diverse Sonderfälle zu beachten (keine Duplikate, keine leeren Logins und keine leeren Passworte).

Eingrenzung der Features:

Falls naheliegende Features nicht implementiert werden, müssen diese explizit ausgeschlossen werden (hier: ein Ungültigwerden des Logins bzw. Sperren des Benutzers).

Beim Bearbeiten eines Lehrbeauftragten gelten die selben Einschränkungen wie beim Anlegen. Es ist nur vom Administrator ausführbar.

Stammdatenverwaltung: Lehrbeauftragten löschen

Das Löschen eines Lehrbeauftragten ist nur dem Administrator erlaubt. Ein Löschen ist nicht mehr möglich, wenn dem Lehrbeauftragten bereits Lehrveranstaltungen zugewiesen wurden. Haben diese Lehrveranstaltungen allerdings noch keine erfaßten Abgaben (d.h. werden sie noch nicht durchgeführt), können sie zuerst gelöscht werden, und dadurch wird der Lehrbeauftragte löschbar.

Stammdatenverwaltung: Student anlegen

Nur der Administrator darf Studenten erfassen. Hierbei werden Matrikelnummer, Name, Einstiegssemester und Mailadresse erfasst. Dem Studenten werden ein Login und ein Passwort zugewiesen. Ein Login darf nicht leer sein (genausowenig wie das Passwort), außerdem darf ein Login nicht schon für einen anderen Studenten oder für einen Lehrbeauftragten vergeben sein. Die Matrikelnummer muss ebenfalls einzigartig sein.

Stammdatenverwaltung: Studentendaten bearbeiten

Nur der Administrator darf Studenten bearbeiten. Es gelten die selben Beschränkungen wie beim anlegen eines Studenten.

Als Besonderheit sei hier darauf verwiesen, dass Studenten ihre eigene Mailadresse bearbeiten können und Lehrbeauftragte bei allen Studenten einer laufenden Veranstaltung die Adressen bearbeiten können. Dies wird in einem separaten Use-Case beschrieben.

Verweise auf verwandte Use-Cases:

In diesem Fall wurde eine Funktionalität beschrieben, die ähnlich in einem anderen Use-Case ebenfalls auftaucht. Deshalb hier einen Verweis anbringen, damit der Leser nicht diese scheinbar fehlende Funktionalität moniert.

Nur der Administrator darf Studenten löschen. Ein Student kann nur gelöscht werden, wenn er keiner Lehrveranstaltung zugewiesen ist. D.h. jeder Student bleibt auch nach dem Ende seines Studiums im Programm erhalten.

Stammdatenverwaltung: Lehrveranstaltung anlegen

Hier werden die allgemeinen Daten einer Lehrveranstaltung gemäß Vorlesungsverzeichnis angelegt, also die LV-Nummer, die Bezeichnung und die Semesterwochenstunden. Keine LV-Nummer darf doppelt vorkommen. Dies ist nur dem Administrator erlaubt.

Stammdatenverwaltung: Lehrveranstaltung bearbeiten

Hier werden die allgemeinen Daten einer Lehrveranstaltung gemäß Vorlesungsverzeichnis bearbeitet. Keine LV-Nummer darf doppelt vorkommen. Der Benutzer kann nachträglich alle Daten ändern und dadurch z.B. aus „Softwaretechnik“ die Veranstaltung „Analysis 1“ machen, wodurch auch alle (bereits abgehaltenen) Veranstaltungstermine „Analysis 1“ hießen. Solchen Unfug zu verhindern bleibt der Intelligenz des Benutzers überlassen. Dies ist nur dem Administrator erlaubt.

Stammdatenverwaltung: Lehrveranstaltung löschen

Das Löschen einer Lehrveranstaltung ist nur dem Administrator möglich. Falls bereits Veranstaltungstermine angesetzt sind, ist ein Löschen nicht mehr möglich. Kann der Benutzer allerdings alle einzelnen Termine manuell löschen (Einschränkungen siehe dort), kann er auch die Lehrveranstaltung löschen.

Stammdatenverwaltung: Veranstaltungstermin anlegen

Der Administrator wählt eine Lehrveranstaltung aus und erzeugt in dieser einen neuen Veranstaltungstermin. Er gibt folgende Daten ein: Semester (z.B. SS 2004), Beginn und End-Datum, Bezeichnung (wird meistens in der Form „Gruppe x“ sein und darf nicht zweimal in der selben Veranstaltung vorkommen) und Wochentag und Uhrzeit. Er wählt einen Lehrbeauftragten aus, der die Veranstaltung durchführen soll.

Die Zuordnung der teilnehmenden Studenten zur Veranstaltung wird in einem weiteren Use-Case beschrieben, da sie nicht bei Anlegen der Veranstaltung erfolgt, sondern erst nach der Belegung.

Stammdatenverwaltung: Veranstaltungstermin bearbeiten

Der Administrator bearbeitet innerhalb einer Lehrveranstaltung einen einzelnen Termin. Er kann Semester, Beginn oder Ende, den durchführenden Lehrbeauftragten sowie die Bezeichnung anpassen. Dies ist nur solange möglich, bis er ihn als „gestartet“ erklärt.

Das Anpassen des Wochentags oder der Uhrzeiten hingegen soll solange möglich sein, bis der Lehrbeauftragte den Termin als „Abgeschlossen“ erklärt, da sich die Zeiten während des Semesters ändern können.

Stammdatenverwaltung: Veranstaltungstermin starten

Sobald der Administrator einen Veranstaltungstermin als „gestartet“ erklärt wird (d.h. die Veranstaltung hat begonnen), darf der Lehrbeauftragte mit ihm arbeiten. Nach dem „Starten“ des Termins können einige Felder nicht mehr bearbeitet werden (siehe Use-Case „Veranstaltungstermin bearbeiten“). Das Starten ist nicht rückgängig zu machen.

Zu beachten ist, dass der Termin nicht gestartet werden darf, wenn kein Lehrbeauftragter festgelegt ist, der ihn durchführt. Das selbe gilt, wenn keine Studenten zugeordnet sind.

Sich gegenseitig beeinflussende Use-Cases:

Der Use-Case „Veranstaltungstermin bearbeiten“ hängt am Use-Case „Veranstaltungstermin starten“. Deshalb in ersterem beschreiben, wie er sich je nach Use-Case „Starten“ verhält. Beim „Starten“ muss beschrieben werden, welche Auswirkungen dies auf das Bearbeiten der Veranstaltungstermine hat. Es reicht eine kurze Zusammenfassung und ein Verweis auf den Use-Case, in dem diese Auswirkungen bereits detailliert geschildert ist.

Der Administrator kann vor dem Start einer Veranstaltung Studenten zur dem Termin zuordnen. Dies sind die Studenten, die bei der Belegung die Veranstaltung gewählt haben. Er kann auch Studenten wieder aus dem Termin entfernen.

Nach dem Start der Veranstaltung ist es nur noch dem Lehrbeauftragten möglich, neue Studenten hinzuzufügen (wobei ein Administrator jeden Veranstaltungstermin wie ein Lehrbeauftragter bearbeiten kann). Ein Entfernen von Studenten ist nicht mehr möglich.

Stammdatenverwaltung: Veranstaltungstermin löschen

Das Löschen eines Veranstaltungstermins ist einem Administrator nur erlaubt, wenn der Termin nicht gestartet ist.

Nachdem die Stammdaten eingegeben wurden, kann der Lehrbeauftragte seinen Job tun. Wie oben in der Beschreibung der Rollen schon erwähnt, kann der Administrator für alle Termine die Rolle des Lehrbeauftragten übernehmen, also alle Termine aller Lehrbeauftragten bearbeiten. Aus diesem Grund wurden dem Administrator keine separaten Use-Cases für die Bearbeitung der Veranstaltungstermine zugewiesen, sondern er wechselt in die Rolle des Lehrbeauftragten, wenn auch mit mehr Rechten.

Die folgenden Use-Cases werden immer aus Sicht des Lehrbeauftragten geschildert. Für den Administrator gilt jeweils das gleiche, nur nicht mit der Beschränkung auf einzelne Lehrveranstaltungstermine.

Mut zum verbindenden Kommentar:

Die Use-Case-Beschreibung als reine Aufzählungs-Liste aufzubauen, genügt nicht immer. Manchmal ist ein Kommentar nötig, der das Ganze strukturiert oder etwas über den folgenden Block aussagt.

Lehrbeauftragter: Auswahl des Veranstaltungstermins

Da alle folgenden Aktionen des Lehrbeauftragten innerhalb eines Termins stattfinden, muss er zuerst einmal einen Termin wählen. Dazu wählt er zuerst in einer Liste aller Lehrveranstaltungen die gewünschte aus. Anschließend muss er aus allen Semestern, in denen die Veranstaltung durchgeführt wird, das gewünschte Semester wählen. Ihm wird eine Liste mit allen Terminen dieser Veranstaltung in diesem Semester angeboten, bei denen er als Durchführender eingetragen ist. Alle anderen Termine sieht er nicht.

Alternativ könnte man ihm alle Termine anzeigen, aber nur die Auswahl solcher erlauben, bei denen er der Durchführende ist.

Der Administrator sieht hier alle Termine und kann auch alle auswählen.

Erfolgen in den folgenden Use-Cases Aktionen innerhalb eines Termins, kann das nur ein Termin sein, der gemäß dieses Use-Cases gewählt wurde.

Die Auswahl des Veranstaltungstermins ist eigentlich kein eigener Use-Case, sondern immer nur ein Teil des Wegs zu einem der folgenden Use-Cases (die Vorbedingung „Veranstaltungstermin muss ausgewählt sein“). Sie wird hier als Include modelliert, damit die Auswahl-Logik nicht bei jedem Use-Case beschrieben werden muss.

Lehrbeauftragter: Zufügen von Studenten zum Veranstaltungstermin

Vorbedingung: Veranstaltungstermin ist gewählt.

Ein Lehrbeauftragter muss die Möglichkeit haben, zusätzlich zu den vom Administrator zugeordneten Studenten im Laufe des Semesters Nachzügler hinzuzufügen. Hierzu kann er beliebige Studenten auswählen.

Es ist ihm nicht möglich, einen Studenten aus der Veranstaltung zu entfernen, er wird immer auf den Teilnehmerlisten auftauchen.

Einschub: Erklärung der Logik von Arbeitsgruppen

Arbeitsgruppen werden pro zu leistender Abgabe erstellt. Falls die Abgabe in Einzelarbeit zu erledigen ist, bildet jeder Student eine eigene Arbeitsgruppe. Falls es eine Projektarbeit ist, werden mehrere Studenten zu einer Gruppe zusammengefaßt. Nimmt der Student nicht mehr an der Lehrveranstaltung teil, wird ihm jegliche Arbeitsgruppe entzogen. Dadurch kann er keine Abgaben mehr leisten.

Aus Sicht des Programms besteht kein Zusammenhang zwischen einer Arbeitsgruppe „Gruppe A“, in der ersten Abgabe, und einer „Gruppe A“ in der zweiten, dritten, ... Abgabe. Der Grund ist, dass Studenten gelegentlich zwischen Gruppen wechseln. In einem solchen Fall müßte man, falls die Arbeitsgruppen über das ganze Semester bestehen blieben, mitführen, welche Studenten ab wann dazugehören und welche Studenten bis wann dazugehörten, um eine Endnote für den gewechselten Studenten errechnen zu können. Wird die Arbeitsgruppe nur pro Abgabe geführt, so ist ein Wechsel kein Problem.

Beim Erstellen einer Abgabe wird das Programm automatisch Arbeitsgruppen erstellen, indem alle Studenten so eingeteilt werden, wie sie in der direkt davor liegenden Abgabe eingeteilt waren. Gibt es eine solche nicht (z.B. bei der ersten Abgabe des Semesters) wird pro Student eine Arbeitsgruppe angelegt. Eine solche Arbeitsgruppe hat als Bezeichnung den Nachnamen des Studenten.

Das Entziehen der Arbeitsgruppe kann sinnvoll sein bei Studenten, die im Semester den Kurs wechseln. Würde man ihnen nicht die Arbeitsgruppe entziehen, hätten sie in beiden Kursen ein großes Punktedefizit wegen nicht geleisteter Abgaben.

Lehrbeauftragter: Anlegen von Abgaben

Vorbedingung: Veranstaltungstermin ist gewählt.

Für die Benotung jeder Lehrveranstaltung ist eine Reihe von Abgaben nötig. Hierzu legt der Lehrbeauftragte beliebig viele Abgaben an, in denen er festlegt, was abzugeben ist (durch einen Klartext-Kommentar, also z.B. „Aufgabe 13 + 15“ oder „Use-Case-Diagramm und –Beschreibung“), wann diese Abgabe zu erfolgen hat und wieviele Punkte zu vergeben sind.

Das Programm erstellt automatisch Arbeitsgruppen gemäß dem oben beschriebenen Verfahren.

Diese Änderungen sind erst möglich, wenn der Termin vom Administrator gestartet wurde. Es ist nicht mehr möglich, nachdem der Lehrbeauftragte die Veranstaltung als abgeschlossen erklärt hat.

Lehrbeauftragter: Bearbeiten von Abgaben

Vorbedingung: Veranstaltungstermin ist gewählt.

Jede der zu leistenden Abgaben kann der Lehrbeauftragte nachträglich bearbeiten, d.h. er kann die Bezeichnung ändern, das Abgabedatum oder die Maximalpunktzahl.

Das Bearbeiten der Arbeitsgruppen ist ein eigener Use-Case.

Bearbeiten ist nur möglich, wenn die Veranstaltung gestartet wurde und nicht abgeschlossen ist.

Lehrbeauftragter: Löschen von Abgaben

Vorbedingung: Veranstaltungstermin ist gewählt.

Jede der zu leistenden Abgaben kann der Lehrbeauftragte jederzeit löschen, sogar wenn schon Aufgaben abgegeben wurden. Diese werden dabei mitgelöscht.

Ein Löschen ist nur möglich, wenn die Veranstaltung gestartet wurde und nicht abgeschlossen ist.

Lehrbeauftragter: Zusammenfassen von Studenten zu Arbeitsgruppen innerhalb einer Abgabe

Vorbedingung: Veranstaltungstermin ist gewählt.

Der Lehrbeauftragte hat die Möglichkeit, festzulegen, von welchen Studenten er die Abgabe erwartet (soll jeder Student einzeln abgeben oder sind mehrere Projektgruppen möglich ?). Beim Erstellen der Abgabe werden automatisch die Arbeitsgruppen so angelegt wie in der letzten Abgabe. Der Lehrbeauftragte kann die Möglichkeit, Studenten von einer Arbeitsgruppe in eine anderen zu verschieben. Entsteht durch dieses Verschieben eine leere Arbeitsgruppe (z.B. weil der Student aus einer Einzelgruppe in eine Projektgruppe verschoben wird), so wird diese automatisch vom Programm gelöscht. Es soll umgekehrt möglich sein, einen Studenten aus einer Projektgruppe wieder in eine Einzelgruppe umzuwandeln.

Dies kann rückwirkend bei bereits geleisteten Abgaben geschehen, dann verliert der Student allerdings die Punktzahlen, die er in seiner Ursprungs-Arbeitsgruppe erhalten hatte. Vor diesen nachträglichen Manipulationen wird gewarnt.

Lehrbeauftragter: Studenten ohne Arbeitsgruppe

Vorbedingung: Veranstaltungstermin ist gewählt.

Der Lehrbeauftragte muss die Möglichkeit haben, einem Studenten die Arbeitsgruppe komplett zu entziehen. Sobald ein Student keine Arbeitsgruppe mehr hat, nimmt er nicht mehr an der Veranstaltung teil. Dies erspart dem Lehrbeauftragten den Aufwand, den Studenten bei jeder Abgabeaufgabe mitzuführen und ihn jedesmal mit null Punkten zu bewerten.

Leistet der Student nur eine einzelne Abgabe nicht, so bleibt er für diese Abgabe in der Arbeitsgruppe, seine Arbeit wird mit 0 Punkten gewertet.

Falls der Student zu einem anderen Kurs gewechselt ist, wird er dort durch Abgaben weitere Punkte erhalten. Eine Aufsummation der Einzelnoten dieses Studenten könnte intelligent genug sein, zu erkennen, dass er Abgaben in zwei verschiedenen Gruppen geleistet hat und die einzelnen Noten korrekt aufaddieren. Eine solche Auswertung soll allerdings nicht Thema dieser Dokumentation sein.

Lehrbeauftragter: Abgabe-Dateien der Studenten erfassen

Vorbedingung: Veranstaltungstermin, Abgabe und Arbeitsgruppe sind gewählt.

Der Lehrbeauftragte wechselt zu der Arbeitsgruppe, deren Abgabe er erfassen will. Hier besteht die Möglichkeit, beliebig viele Dateien anzuhängen. Zu jedem Dateianhang (beispielsweise Quellcode, ein Word-Dokument oder eine Zip-Datei) wird gespeichert, wann die Abgabe erfolgte. Außerdem hat der Benutzer die Möglichkeit, einen beliebigen Kommentar anzugeben. Dies kann z.B. der Name des oder der Studenten sein, von denen dieser Teil stammt. Gerade bei größeren Projekten kann eine Abgabe von den Studenten in Einzelteile unterteilt werden, und jeder Teil wird von einem anderen Student erledigt. Dies ist bei der Bewertung zu berücksichtigen, wird aber nicht im Datenmodell der Anwendung abgebildet.

Lehrbeauftragter: Abgabe-Dateien der Studenten bearbeiten

Vorbedingung: Veranstaltungstermin, Abgabe und Arbeitsgruppe sind gewählt.

Der Lehrbeauftragte hat die Möglichkeit, die einzelnen Datei-Abgaben nachträglich zu bearbeiten. Dies beschränkt sich darauf, die Bemerkungen zu einer Datei-Abgabe zu ändern (z.B. ein Verweis, dass diese Datei durch eine neuere ersetzt wird).

Lehrbeauftragter: Abgabe-Dateien der Studenten löschen

Vorbedingung: Veranstaltungstermin, Abgabe und Arbeitsgruppe sind gewählt.

Der Lehrbeauftragte kann sogar eine abgegebene Datei wieder löschen. Dies kann z.B. geschehen, wenn sie durch eine neue Version ersetzt wird, und kein Grund besteht, die Originalversion nach aufzuheben. Das Löschen kann sogar bei in der Vergangenheit liegenden Abgaben geschehen. Es hat keine Auswirkungen auf die Noten der Abgaben, da diese separat eingegeben werden.

Lehrbeauftragter: Abgabe bewerten

Vorbedingung: Veranstaltungstermin, Abgabe und Arbeitsgruppe sind gewählt.

Nachdem die Studenten die Aufgabe abgegeben haben, bewertet der Lehrbeauftragte deren Arbeit. Die Bewertung erfolgt auf Arbeitsgruppen-Ebene. Die Punktzahlen selbst sowie eine Bemerkung werden allerdings pro Studenten gespeichert. Dadurch ist es möglich, die Studenten einer Projektgruppe nach der geleisteten Arbeit zu bewerten.

Um dem Benutzer die Arbeit zu erleichtern, sollte das Programm die Bewertung des ersten Studenten der Arbeitsgruppe bei allen anderen Studenten ebenfalls eintragen. Der Benutzer kann bei Bedarf trotzdem Einzelwertungen verteilen.

Lehrbeauftragter: Bewertung versenden

Vorbedingung: Veranstaltungstermin, Abgabe und Arbeitsgruppe sind gewählt.

Der Lehrbeauftragte hat die Möglichkeit, beim Bewerten einer Arbeitsgruppe diese Bewertung als Mail direkt an alle Mitglieder der Gruppe zu versenden.

Die Mail soll eine Liste aller abgegebenen Dateien (nur die Dateinamen) sowie der jeweiligen Bemerkungen dazu enthalten, außerdem pro Student die Bewertungskommentare sowie die Punktzahl.

Nach dem Versenden einer Mail soll dies in der Arbeitsgruppe hinterlegt werden, und zwar mit Datum und allen Empfängern.

Dieser Use-Case könnte den Use-Case „Abgabe bewerten“ erweitern („extends“). Allerdings habe ich ihn als eigenen Use-Case belassen, da es auch möglich sein soll, die Mail unabhängig von der Bewertung zu versenden (z.B. weil der Lehrbeauftragte nach einer ungenügenden Abgabe auf Nachbesserung wartet, und weil diese nicht erfolgt, bei Ablauf der Frist die unveränderte Bewertung versendet).

Modellierung begründen:

In diesem Fall lag eine andere als die gewählte Modellierung nahe. In solchen Fällen sollte begründet werden, warum gerade diese Methode gewählt wurde.

Lehrbeauftragter: Lehrveranstaltungstermin abschliessen

Vorbedingung: Veranstaltungstermin ist gewählt.

Nachdem eine Lehrveranstaltung durchgeführt wurde, wird sie vom Lehrbeauftragten explizit als „Abgeschlossen“ markiert. Ab diesem Zeitpunkt ist es nur noch dem Administrator möglich, Daten der Veranstaltung zu ändern (z.B. Bewertungen).

Lehrbeauftragter: Studentendaten bearbeiten

Der Lehrbeauftragte soll die Möglichkeit haben, E-Mail-Adressen von Studenten zu korrigieren. Dies soll für alle Studenten möglich sein, nicht nur für solche in seinen Lehrveranstaltungen.

Lehrbeauftragter: Bewertungsliste pro Student erstellen

Der Lehrbeauftragte hat die Möglichkeit, pro Student einen Ausdruck aller Bewertungen dieses Studenten zu erstellen. Hierzu muss er einen Lehrveranstaltungstermin und einen Studenten auswählen. Die Liste enthält alle Abgaben, pro Abgabe eine Auflistung von abgegebenen Dateien (jeweils mit dem Abgabekommentar) sowie die Bewertung und die Punktzahl.

Lehrbeauftragter: Bewertungsliste pro Veranstaltung erstellen

Der Lehrbeauftragte hat die Möglichkeit, für den gesamten Kurs eine Notenübersicht zu erstellen. Diese enthält in den Zeilen die Matrikelnummern der Studenten und in den Spalten die Punktzahlen der einzelnen Abgaben. Dieser Ausdruck wird bei Semesterende zur Notenbekanntmachung ausgehängt.

Student: Veranstaltungstermin auswählen

Der Student wählt eine Lehrveranstaltung aus, anschließend ein Semester. Innerhalb des Semesters wird ihm der Lehrveranstaltungstermin angezeigt, an dem er teilnimmt (falls es einen solchen gibt). Alternativ könnte man ihm alle Veranstaltungstermine anzeigen und die Auswahl der Termine verbieten, an denen er nicht teilnimmt.

Dieser Use-Case wurde ebenso wie die Auswahl des Veranstaltungstermins durch den Lehrbeauftragten als Include modelliert, da er als Vorbedingung für weitere Use-Cases dient.

Alternative Modellierung:

Es fällt auf, dass der Use-Case „Veranstaltungstermin wählen“ beim Aktor „Lehrbeauftragter“ und beim Aktor „Student“ auftaucht, und in beiden Fällen fast identische Aktionen erfolgen.

Hier könnte man die Use-Cases generalisieren. Man würde einen abstrakten Use-Case „Veranstaltungstermin wählen“ definieren:

Der Aktor wählt eine Lehrveranstaltung aus, anschließend ein Semester. Innerhalb des Semesters werden ihm die Lehrveranstaltungstermine angezeigt, für die er die Berechtigung hat. Er wählt einen der Termine aus.

Der spezialisierte Use-Case „Lehrbeauftragter: Termin wählen“ würde so aussehen: Der Aktor „Lehrbeauftragter“ kann nur die Termine wählen, bei denen er der Durchführende ist. Falls der Lehrbeauftragte auch Administrator ist, kann er alle Termine wählen.

Der spezialisierte Use-Case „Student: Termin wählen“ würde so aussehen: Der Aktor „Student“ kann nur die Termine wählen, an denen er teilnimmt.

Die Use-Cases des Lehrbeauftragten würden wie bisher auf den spezialisierten Use-Case „Lehrbeauftragter: Termin wählen“ verweisen, die des Studenten auf „Student: Termin wählen“. Man hätte sich aber ein wenig Schreibarbeit gespart.

Student: Abgabe tätigen

Der Student wählt einen Veranstaltungstermin (der sich gerade in Durchführung befinden muss) und eine Abgabe. Das Programm prüft, ob für diese Abgabeaufgabe überhaupt noch das Abgeben von Dateien möglich ist (oder ob die Abgabefrist abgelaufen ist).

Ist eine Abgabe möglich, wird das Programm automatisch die Arbeitsgruppe suchen, in der der Student für diese Abgabe eingetragen ist. Existiert sie nicht (z.B. weil noch keine Gruppen vom Lehrbeauftragten erfasst sind oder weil der Student ausgeschlossen wurde), erhält er eine Fehlermeldung.

Anschließend kann der Student Dateien an die Abgabe anhängen. Zu jeder Datei ist ein Kommentar möglich. Das Programm merkt sich, welcher Student angemeldet war und wann die Abgabe erfolgte.

Alternative Modellierung:

Dieser Use-Case enthält eine Reihe von Sonderfällen. Diese könnte man als „Alternative Pfade“ oder auch „Szenarios“ modellieren.

Auf diese Weise käme man zu vier weiteren Szenarios, von denen drei „Fehlerfälle“ sind:

• Der Termin wurde bereits abgeschlossen oder befindet sich noch nicht in der Durchführung.

• Abgabeaufgabe liegt zu weit in der Vergangenheit als dass eine Abgabe noch möglich wäre.

• Der Student ist in keiner Arbeitsgruppe eingetragen.

• Student hängt erfolgreich eine Datei an.

Student: Einsehen eigener Abgaben

Der Student wählt einen Veranstaltungstermin (der sich gerade in Durchführung befinden muss) und eine Abgabe. Das Programm erkennt, in welcher Arbeitsgruppe er sich gerade befindet und zeigt ihm die Bewertung und die Übersicht der abgegebenen Dateien dieser Arbeitsgruppe an. Der Student hat die Möglichkeit, die abgegebenen Dateien zur Ansicht abzurufen.

Student: Erstellen eines Bewertungsausdrucks einer Abgabe

Dieser Use-Case erweitert den Use-Case „Student: Einsehen eigener Abgaben“, indem der Student beim Einsehen einer Abgabe die Möglichkeit hat, sich einen Ausdruck dieser Abgabe zu erstellen.

Student: Erstellen einer Bewertungsübersicht

Der Student hat die Möglichkeit, nach Auswahl eines Lehrveranstaltungstermins eine komplette Bewertungsübersicht aller eigener Bewertungen zu erstellen, analog zum Use-Case „Lehrbeauftragter: Bewertungsliste pro Student erstellen“.

Für diese beiden Use-Cases wäre eine Generalisierung denkbar.

Student: Mailadresse anpassen

Der Student kann seine eigene im System hinterlegte Mailadresse korrigieren. Er kann keine weiteren Daten ändern, nur die Mailadresse selbst, und dies ist nicht für andere Studenten möglich.