Für meine DA benötige ich eine Fallstudie, wozu mir ein fiktives, einfach strukturiertes Ticketing-System (aka Task-Tracking-System oder Help-Desk-System) dient, das ich hier beschreiben möchte:

Szenario

Ein Ticketing-System findet zum Beispiel im User-Support eines Software-Herstellers Anwendung. Grundsätzlich können zwei Benutzergruppen eines solchen Systems identifiziert werden. Auf der einen Seite die Benutzer der Software (= Kunden des Softwareunternehmens), die in diesem Szenario entweder Probleme bei der Bedienung oder Anforderungen bezüglich Customizing/Features haben. Auf der anderen Seite gibt es die Mitarbeiter des Softwareunternehmens, die sich um die Probleme und Anforderungen der Kunden kümmern.

Beschreibung

Auf der Kundenseite sieht die Interaktion mit dem System wie folgt aus: Ein Kunde erstellt eine Anfrage über eine nicht näher definierte Schnittstelle (eine solche Schnittstelle könnte zum Beispiel ein Mail-System oder eine Webapplikation sein) und erzeugt damit automatisch ein Ticket. Das System teilt dem Kunden dann über eine Nachricht (OutgoingMessage) seine Ticket-Nummer mit. Mit dieser Ticket-Nummer kann der Kunde dann zu einem späteren Zeitpunkt weitere Nachrichten (IncomingMessage) an das System schicken, die dann dem Ticket zugeordnet werden können.

Auf der Seite des Softwareherstellers bedienen dann Mitarbeiter (=Benutzer) das System. Das System, das bei jeder Anfrage ein neues Ticket erzeugt, erzeugt zeitgleich eine initiale Aufgabe, die einem zuvor definierten Standard-Benutzer sowie dem erstellten Ticket zugeordnet wird. Diese initiale Aufgabe lautet in etwa “Anfrage bearbeiten”. Der Standard-Benutzer ist somit beauftragt, sich um die Anfrage zu kümmern. Anhand der Inhalts der Anfrage entscheidet er, ob er diese selbst beantworten kann, die Aufgabe “Anfrage bearbeiten” an einen Kollegen weiterleitet, oder ob er eine neue Aufgabe bezüglich des Tickets an einen Kollegen deligiert.

1. Fall “Anfrage beantworten”

Der Benutzer erzeugt eine OutgoingMessage an den Kunden. Für den Fall, dass dem Ticket keine weiteren offenen Aufgaben zugeordnet sind, wird auch die initiale Aufgabe als erledigt und somit das Ticket geschlossen. Die initiale Aufgabe kann nur auf diesem Weg oder über die Kundenseite geschlossen werden. Eine erneute Nachricht, die diesem Ticket zugeordnet werden kann, setzt den Status des Ticket wieder auf “offen”

2. Fall “Aufgabe weiterleiten”

2.1 Es handelt sich dabei um die initiale Aufgabe

Wird die initiale Aufgabe einem anderen Benutzer zugeordnet, “gehört” diesem das Ticket und ist für dessen Bearbeitung zuständig. Als Besitzer des Tickets kann er weitere Aufgaben erzeugen und diese auch wieder anderen Benutzern zuordnen. Er hat aber auch die Berechtigung erstellte Aufgaben zu löschen.

2.2 Es handelt sich um eine “normale” Aufgabe

siehe 3.

3. Fall “Aufgabe zugewiesen”

Der Benutzer, dem eine Aufgabe zugewiesen wurde, kann diese ausführen und danach im System als “erledigt” kennzeichnen, oder er leitet diese wiederum weiter. Er hat auch die Möglichkeit weitere Unteraufgaben zu erstellen, falls dies notwendig ist. (Auf diese Weise kann ein Aufgabenbaum erzeugt werden, mit der initialen Aufgabe als Wurzelknoten.) Der Benutzer hat in diesem Fall die Möglichkeit, die Unteraufgaben zu löschen. Um eine Aufgabe mit Unteraufgaben als “erledigt” kennzeichnen zu können, dürfen keine Unteraufgaben “offen” sein.

Sollte sich eine Anfrage von Kundenseite aus erledigt haben, gibt es die Möglichkeit, das Ticket zu schließen. Dadurch gibt das System allen offenen Aufgaben den Status “nicht notwendig” und der initialen Aufgabe den Status “erledigt”. Der Besitzer der Aufgaben mit Status “nicht notwendig” kann dann selbst entscheiden, ober er diese noch ausführt und dann als erledigt markiert, oder ob er diese löscht.

Soviel zunächst zur Beschreibung meiner CaseStudy. Ich denke, dass die entsprechenden KobrA2-Diagramme in einem weiteren Post folgen werden. Anregungen und Fragen bitte als Kommentar hinterlassen. Danke 🙂