Universität Bremen Fachbereich 3 Studiengang Informatik Karl ...
Universität Bremen Fachbereich 3 Studiengang Informatik Karl ...
Universität Bremen Fachbereich 3 Studiengang Informatik Karl ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Universität</strong> <strong>Bremen</strong><br />
<strong>Fachbereich</strong> 3<br />
<strong>Studiengang</strong> <strong>Informatik</strong><br />
<strong>Karl</strong>-Heinz Rödiger<br />
WiSe 2003/2004<br />
Soziotechnische Systeme<br />
VAK 03-901.01<br />
Tutor: Joachim Hinrichs<br />
Anforderungsspezifikation<br />
Erarbeitung eines Übungsanmeldesystems<br />
Gruppe sopra<br />
Stephan Großewinkelmann, Torben Hohn, Georg Lippold,<br />
Sebastian Offermann, Christian Peper, Hanene Samara<br />
Abgabedatum: 20. Februar 2004
Seite 2<br />
INHALTSVERZEICHNIS<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Inhaltsverzeichnis<br />
1 Einleitung 3<br />
2 Datenbankaufbau 5<br />
3 Die Klassendiagramme 7<br />
3.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
3.2 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
3.3 HTML Generierung . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
3.4 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
4 Pseudo Code 11<br />
5 Use-Case-Diagramm 14<br />
6 Ablauf 17<br />
6.1 Dozent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
6.1.1 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . 17<br />
6.1.2 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . 19<br />
6.1.3 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . 21<br />
6.2 Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
6.2.1 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . 24<br />
6.2.2 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . 34<br />
6.2.3 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . 36<br />
7 Anhang 38<br />
7.1 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
7.2 kommentierte Diagramme (als Beispiel: Teile des Aktivitätsdiagramms<br />
Studenten) . . . . . . . . . . . . . . . . . . . . . . 39<br />
7.3 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 3<br />
1 EINLEITUNG<br />
1 Einleitung<br />
Als Teilnehmer des Kurses ”Gestaltung soziotechnischer Systeme” ist es unser<br />
erklärtes Ziel, ein System zu erschaffen, dass auf automatischem Wege<br />
einen fairen, anwendbaren Studienplan für einen großen Personenkreis erstellt.<br />
Hierbei muss es sich natürlich um ein in höchstem Maße interaktives System<br />
handeln, da bei jedem Ablauf initiierend eine quantitativ bedeutende<br />
Datenmenge eingegeben werden muss.<br />
Interessanterweise kann man das zu erschaffende Übungsanmeldesystem mit<br />
einem Theater-Stück vergleichen: bei jedem Theaterstück wird am Anfang<br />
überlegt, welche Intentionen hinter dem Werk stehen sollen; welche Wirkung<br />
soll erzielt, welche Auswirkung verhindert werden. Ebenso ist es bei jedem<br />
größeren Projekt unabdingbar, sein Vorgehen vorher zu planen: sich als ersten<br />
Schritt zu überlegen, was das System können sollte und wo Schnittstellen<br />
mit Benutzern oder gar anderen Systemen existieren. Insofern war die<br />
Anforderungsdefinition, welche natürlich stark soziologisch ist, ähnlich der<br />
Vorüberlegung der Erschaffung eines Theaterstücks.<br />
Im zweiten Schritt der Erschaffung eines Theaterstücks muss überlegt werden,<br />
welche stilistischen Mittel zum Erreichen der gewünschten Wirkung einzusetzen<br />
sind, um diese in einem roten Handlungsfaden einzuweben. Ebenso<br />
haben wir nun im zweiten Schritt auf unserem Weg zu überlegen, wie man die<br />
an das System gestellten Anforderung und die benötigten Schnittstellen mit<br />
technischen Mitteln umsetzen kann. Wir müssen hier eine Brücke zwischen<br />
den soziologischen Anforderungen und den technologischen Gegebenheiten<br />
schlagen, genau wie es der Theater-Autor zwischen Intention und Handlung<br />
bzw. Stil tut. Dabei verwenden wir in der hier vorliegenden Anforderungsspezifikation<br />
natürlich die in der Anforderungsdefinition erarbeiteten Ergebnisse<br />
und nutzen sie, um uns eine Grundlage für den weiteren Verlauf zu kreiren.<br />
Diese Anforderungsspezifikation umfasst fünf Hauptabschnitte:<br />
Das Schema des Datenbankaufbaus, die Klassendiagramme, ein bißchen<br />
Pseduo-Code, das Use-Case-Diagramm und für die Benutzergruppen Dozenten<br />
und Studenten jeweils ein Aktivitäts-, ein Zustands- und ein Sequenzdiagramm.<br />
Abgerundet wird diese Spezifikation durch diese Einleitung, ein<br />
Fazit und natürlich den Anhang.<br />
Der nächste Schritt des Theaterautors ist natürlich das Schreiben des eigentlichen<br />
Theaterstücks unter Verwendung des vorher angelegten roten Fadens,<br />
ebenso wird unsere nächste Aufgabe das Schreiben des Quellcodes für unser<br />
System sein.<br />
Schließlich, wenn das Werk bzw. das System selbst vollendet ist, liegt es<br />
an den beteiligten Personengruppen, es sinnvoll zu inszenieren: jedes Semesopra
Seite 4<br />
1 EINLEITUNG<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
ster läuft das Programm einmal durch, was etwa einer Theater-Vorführung<br />
entspricht: dabei entspricht die Raumvergabestelle der Finanzabteilung der<br />
Geldgeber (<strong>Universität</strong> und Land), die die Mittel zur Verfügung stellt,<br />
während die Dozenten als Produzenten eingesetzt werden, die Admins führen<br />
die Regie und die quantitativ herausragendste Gruppe der Studenten ist die<br />
Schauspieler-Riege, während letztlich die Autoren - zwar um eine Erfahrung<br />
reicher - im Allgemeinen weitgehend leer ausgehen. Unser Vorteil gegenüber<br />
den Autoren eines Theater-Stücks ist es, dass wir in der Tat in den nächsten<br />
Studienjahren selber von unseren Leistungen profitieren können, wenn wir es<br />
schaffen, dieses System zum Standars zu erheben.<br />
Also, bereiten wir die Bühne...<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 5<br />
2 DATENBANKAUFBAU<br />
2 Datenbankaufbau<br />
Wir haben uns zuerst Gedanken darüber gemacht, was nachher die Basis<br />
unseres Übungs-Anmelde-System bilden soll. Dies ist sicherlich eine Datenbank.<br />
Also haben wir diese zuerst designed, damit dann die Dinge, die darauf<br />
aufbauen, eine gute Grundlage haben (vgl. Abb. 1). Wir haben uns beim Design<br />
der Datenbank an unsere Anforderungsdefinition gehalten und dabei ein<br />
paar Dinge umspezifiziert, damit alles gut maschinell verarbeitbar ist.<br />
Abbildung 1: Beziehungen und Datenfelder in der Datenbank<br />
Beispielsweise haben wir die Zeitspanne, in der eine Veranstaltung stattfindet,<br />
dadurch gekennzeichnet, dass sie eine Anfangs- und eine Endzeit bekommen<br />
hat.<br />
Die Primärschlüssel der Datenbank sind fett gedruckt, Felder, die in anderen<br />
Tabellen referenziert werden, sind durch Linien verbunden.<br />
Die Tabelle Veranstaltungen enthält alle für eine Veranstaltung wichtigen<br />
Daten und wird von den Tutorien referenziert. Ein Tutorium gehört immer<br />
zu einer Veranstaltung. Die weiteren Felder der Tutoriumstabelle sind unserer<br />
Ansicht nach selbsterklärend.<br />
Weiterhin hat eine Veranstaltung einen Dozenten, der vom Typ Mensch ist.<br />
Menschen teilen sich noch in die Untergruppen Tutoren, Administratoren,<br />
Studenten und Dozenten auf. Jeder dieser Gruppen kann eine bestimmte<br />
Rolle zugewiesen werden, teilweise haben sie auch noch Attribute, die über<br />
die von Mensch hinausgehen.<br />
sopra
Seite 6<br />
2 DATENBANKAUFBAU<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Ein Student ist immer Mitglied in einer Gruppe, dazu wird, sobald ein Student<br />
einem Tutorium beitritt, für ihn eine Gruppe angelegt, in der nur er<br />
Mitglied ist. Er ist gleichzeitig Administrator dieser Gruppe. Er kann weitere<br />
Studenten in seine Gruppe einladen, diese erhalten dann eine Mail mit<br />
einer Einladung. Wenn sie die Einladung annehmen, müssen sie ihre eigene<br />
Gruppe auflösen. Mitglieder von Gruppen können auch selbständig aus einer<br />
Gruppe wieder austreten, allerdings können sie keine Gruppen auflösen. In<br />
eine Gruppe können nicht mehr Mitglieder eingeladen werden, als die maximale<br />
Gruppengrösse für das Tutorium ist.<br />
Jeder Student einer Gruppe kann einem Tutorium eine Priorität zuordnen,<br />
die Gruppenpriorität für ein Tutorium ergibt sich dann zu dem Mittelwert<br />
aller Prioritäten.<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 7<br />
3 DIE KLASSENDIAGRAMME<br />
3 Die Klassendiagramme<br />
In diesem Abschnitt werden die Klassendiagramme erklärt. Wir haben vier<br />
verschiedene Bereiche identifiziert, die keine Abhängigkeiten zu einenander<br />
haben werden. Deswegen haben wir vier separate Klassendiagramme erzeugt.<br />
3.1 Servlets<br />
Da wir unsere Applikation als Java Servlets realisieren, müssen wir uns an die<br />
Servlet-API halten. Ein Servlet erbt von javax.servlet.http.HttpServlet<br />
und sollte dann mindestens eine der Methoden<br />
• doGet<br />
• doPost<br />
• doPut<br />
• doDelete<br />
• init, destroy<br />
• getServletInfo<br />
überschreiben.<br />
Da wir nicht zwischen den Verschiedenen Arten der HTTP Anfragen unterscheiden,<br />
haben wir erstmal eine Klasse definiert, die alle Methoden auf<br />
eine umleitet. Wir haben uns für doGet entschieden. Diese Methode ist dann<br />
von den einzelnen Seiten unseres Systems zu implementieren, wie auch aus<br />
Abb. 2 auf der nächsten Seite ersichtlich ist.<br />
Um diese Implementierung einigermaßen übersichtlich zu halten, definieren<br />
wir noch drei zusätzliche Pakete, die uns dann die Arbeit abnehmen werden:<br />
SuchServlet, UIList und UIElement.<br />
Mittels des PrintWriters können wir dann die Daten mit UIList und UI-<br />
Element zusammenschreiben lassen und schließlich von der doPost-Methode<br />
ausgeben lassen.<br />
Einige der Methoden, die unsere Servlets noch implementieren müssen, stehen<br />
auf dem Zustandsdiagramm des Dozenten. Hier sind dann auch immer die<br />
Return-Values (immer HttpSession) und einige Variablen entsprechend benannt.<br />
Eventuell werden wir die generate()-Methode in die doPost-Methode<br />
umverlagern, da dies eigentlich der sinnigere Ort ist. Die von den Servlets<br />
generierten Seiten werden dann mittels Buttons die nötigen Posts und Gets<br />
implementieren.<br />
sopra
Seite 8<br />
3 DIE KLASSENDIAGRAMME<br />
3.2 Datenbank<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
HttpServletResponse<br />
HttpServletRequest<br />
PrintWriter<br />
+ printLn(toprint : string) : void<br />
HttpServlet<br />
UIList<br />
SuchServlet<br />
UIElement<br />
OurServlet<br />
+ doGET() : void<br />
+ doPOST(request : HttpServletRequest, response : HttpServletResponse) : void<br />
ChangeOwnDataServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
ChangeSessionServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
ChoiceServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
ClassesListServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
LogoutServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
ModifyClassesServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
NewClassServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
AuthServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
LoginServlet<br />
+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void<br />
3.2 Datenbank<br />
Abbildung 2: Klassendiagramm des Servlet Pakets<br />
Die Entwicklung dieses Paketes begann mit der Identifizierung der Tabellen,<br />
die in der Datenbank enthalten sein sollen. Auf alle Objekte (besser Entities),<br />
mit denen das System arbeitet, kann mit Hilfe dieser Schnittstelle zugegriffen<br />
werden. Ein UML-Diagramm dieses Packages findet sich in Abb. 3 auf der<br />
nächsten Seite<br />
Die Assoziationen, die wir hier identifiziert haben, wurden mit einzelnen<br />
Methoden bedacht, die dann die SQL Statements enthalten werden, um die<br />
Assoziationen auszuwerten.<br />
3.3 HTML Generierung<br />
Um etwas bequemer html zu erzeugen, haben wir ein Paket definiert, das<br />
uns dabei ein wenig unter die Arme greift. Hierbei sind die einzelnen Klassen<br />
so gestaltet, dass sie nacheinander in der Reihenfolge, wie sie auf der Seite<br />
erscheinen sollen, aufgerufen werden. Wir können uns damit also unsere Seite<br />
hübsch zusammenbauen und dann nachher an das Servlet, das uns mit<br />
Daten gefüttert hat, zurückgeben. Das UML-Diagramm ist in Abb. 4 auf der<br />
nächsten Seite zu sehen.<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 9<br />
3 DIE KLASSENDIAGRAMME<br />
3.3 HTML Generierung<br />
Gruppe<br />
+ groesse : int<br />
+ gruender : Mensch<br />
+ name<br />
1..*<br />
: String<br />
+ tutorium : Tutorium<br />
- id : int<br />
+ get_members() : list<br />
+ Gruppe(gruender : Student, name : string) : void<br />
1..*<br />
1..*<br />
Tutorium<br />
+ get_groups() : list<br />
1<br />
+ Tutorium() : Tutorium<br />
1..*<br />
1..*<br />
Veranstaltung<br />
+ dozent : Dozent<br />
+ name : String<br />
1..*<br />
+ veranstaltungsKennziffer 1<br />
: String<br />
- id : int<br />
+ get_tutorien() : list<br />
Student<br />
+ matrikelNummer : int<br />
1..*<br />
+ get_veranstaltungen() : list<br />
+ add_veranstaltung(veranstaltung : Veranstaltung) : void<br />
+ remove_veranstaltung(veranstaltung : Veranstaltung) : void<br />
+ get_gruppen() : list<br />
1..*<br />
DBObject<br />
# connection : DBConnection<br />
+ finalize() : void<br />
+ sync(conn : DBConnection) : void<br />
1<br />
Dozent<br />
+ get_veranstaltungen() : list<br />
1<br />
Tutor<br />
+ get_tutorien() : list<br />
Mensch<br />
+ Vorname : String<br />
+ e_mail : String<br />
+ name : String<br />
+ passwort : String<br />
+ user : String<br />
- id : int<br />
Abbildung 3: Klassendiagramm des Datenbank Pakets<br />
Alle Objekte sind von<br />
Printable abgeleitet, damit<br />
sie alle eine print() Methode<br />
haben, und auf die Klassen<br />
Attribute zugreifen koennen.<br />
Link<br />
+ Link(url : char *)<br />
+ print() : void<br />
Header<br />
+ print() : void<br />
PrintableForm<br />
- action : char *<br />
+ PrintableForm(action : char *, method : char *, : List < Printable >)<br />
+ print() : void<br />
Footer<br />
+ print() : void<br />
Printable<br />
# req : HttpServletRequest *<br />
+ print() : void<br />
+ setRequest(req : HttpServletRequest *)<br />
PrintableList<br />
- lst : List<br />
+ PrintableList( : List < Printable >)<br />
+ append(p : Printable *) : void<br />
+ print() : void<br />
TableRow<br />
+ print() : void<br />
Table<br />
+ print() : void<br />
FormField<br />
# name : char *<br />
# value : char *<br />
+ FormField(name : char *, value : char *)<br />
Dann gibt es noch eine PrintableList.<br />
Diese kommt in verschiedenen Arten<br />
vor, die sich nur durch Einfassung und<br />
Trennzeichen unterscheiden.<br />
InputField<br />
- type : char *<br />
+ InputField(name : char *, val : char *, type : char *)<br />
+ print() : void<br />
SelectorField<br />
- lst : List<br />
+ SelectorField(name : char *, val : char *, : List < char * >)<br />
+ append(choice : char *) : void<br />
+ print() : void<br />
SubmitField<br />
+ SubmitField(value : char *)<br />
+ print() : void<br />
Abbildung 4: Klassendiagramm des HTMLUI Pakets<br />
sopra
Seite 10<br />
3 DIE KLASSENDIAGRAMME<br />
3.4 Backend<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
3.4 Backend<br />
Abbildung 5: Das Backend des Anmeldesystems<br />
Dieses Klassendiagramm beschreibt die Klassen, welche die eigentliche Verteilung<br />
der Studenten auf die verschiedenen Tutorien vornimmt. Kern dieser<br />
Klassen bildet das Interface Evolvable, welches die Methoden mutate() und<br />
recombine() vorgibt. Dieses Interface wird von allen beteiligten Klassen implementiert.<br />
Aus der Klasse Generation wird dann das zentrale Objekt instanziert. Dieses<br />
Objekt spiegelt eine Generation unserer Population wieder. Eine neue<br />
Generation wird durch einen Konstruktor erschaffen, der eine vorhergehende<br />
Generation erwartet. Aus dieser vorhergehenden Generation wird nun die<br />
neue Generation durch Rekombination der enthaltenen Member erzeugt. Um<br />
dies zu ermöglichen, muss jede Generation mindestens 2 Member enthalten.<br />
Anschließend werden eine festgelegte Anzahl Member selektiert und in der<br />
Generation gespeichert. Zu guter Letzt werden die übrig gebliebenen Member<br />
noch mutiert.<br />
Die Klassen Member und E Veranstaltung funktionieren im Wesentlichen<br />
ähnlich, denn sie rekombinieren jeweils die in sich liegenden Objekte.<br />
Die Klasse E Tutorium führt nun die eigentlichen Operationen aus, indem es<br />
intern rekombiniert.<br />
Die beiden Klassen Tutorium und Veranstaltung entsprechen den gleichnamigen<br />
Objekten aus dem Frontend. Sie sind hier nur der Vollständigkeit halber<br />
aufgeführt, da E Tutorium und E Veranstaltung jeweils von ihnen erben.<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 11<br />
4 PSEUDO CODE<br />
4 Pseudo Code<br />
Um noch einmal mehr zu verdeutlichen, wie die definierten Klassen benutzt<br />
werden, geben wir hier ein Stück Pseudocode an, welches das nochmal verdeutlichen<br />
soll.<br />
/∗<br />
∗ A u t h S e r v l e t .doGET( )<br />
∗<br />
5 ∗ Diese Methode wird aufgerufen , wenn der Benutzer seinen<br />
∗ Namen und das Passwort auf der L o g i n S e i t e eingegeben hat ,<br />
∗ und den Einloggen Knopf g e d r u e c k t hat .<br />
∗/<br />
10 void doGET( HttpServletRequest request ,<br />
HttpServletResponse response ) {<br />
15<br />
// I n i t i a l i s i e r t d i e Klassen A t t r i b u t e , damit s i e<br />
// den r i c h t i g e p r i n t w r i t e r f i n d e n koennen .<br />
P r i n t a b l e . setup ( response ) ;<br />
20<br />
// Holt d i e w i c h t i g e n parameter in l o k a l e Variablen<br />
S t r i n g user = r e q u e s t . getParam ( "user" ) ;<br />
S t r i n g password = r e q u e s t . getParam ( "password" ) ;<br />
25 // Sind d i e Parameter in Ordnung ?<br />
i f ( user == null | | password == null ) {<br />
// Wenn nicht , dann erzeuge eine Fehler S e i t e .<br />
30 P r i n t a b l e rp = new ErrorPage ( "Geben sie einen " ) ;<br />
// Und g i b s i e aus .<br />
rp . p r i n t ( ) ;<br />
35 return ;<br />
}<br />
sopra
Seite 12<br />
4 PSEUDO CODE<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
// Nun i n s t a n z i i e r e n wir einen Menschen , mit einem<br />
40 // der moeglichen Konstrukturen .<br />
Mensch m = new Mensch ( user ) ;<br />
45 // i s t das Passwort r i c h t i g ?<br />
i f ( md5( passwort ) ! = m. passwort ) {<br />
// Wenn nicht , dann Warnung ausgeben .<br />
50 P r i n t a b l e rp = new P r i n t a b l e L i s t ( ) ;<br />
rp . append ( new Header ( ) ) ;<br />
rp . append ( new P r i n t a b l e S t r i n g ( "Das Passwort war falsch" ) ) ;<br />
rp . append ( new Footer ( ) ) ;<br />
55 rp . p r i n t ( ) ;<br />
}<br />
return ;<br />
60 // J e t z t koennen wir davon ausgehen , das der Benutzer s i c h<br />
// h i e r anmelden d a r f .<br />
//<br />
// Wir erzeugen uns eine Session , und s e t z e n in Ihr<br />
// den Benutzer . In den z u k u e n f t i g e n S e i t e n koennen wir dann<br />
65 // h i e r u e b e r immer den Benutzer wieder f i n d e n .<br />
HttpSession s e s s i o n = r e q u e s t . n e w s e s s i o n ( ) ;<br />
70<br />
75<br />
s e s s i o n . s e t ( "user" , m ) ;<br />
// Und nun geben wir d i e Willkommensseite aus :<br />
P r i n t a b l e L i s t s e i t e = new P r i n t a b l e L i s t ( ) ;<br />
s e i t e . append ( new Header ( ) ) ;<br />
Table tab = new Table ( ) ;<br />
s e i t e . append ( tab ) ;<br />
TableRow row = new TableRow ( ) ;<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 13<br />
4 PSEUDO CODE<br />
80 tab . append ( row ) ;<br />
row . append ( new Link ( "Eigene Daten" ) ) ;<br />
row . append ( new Link ( "Veranstaltungen" ) ) ;<br />
85 // Und noch d i e w e iteren m o e g l i c h k e i t e n .<br />
s e i t e . append ( new Footer ( ) ) ;<br />
90 // Und nun noch ausgeben .<br />
s e i t e . p r i n t ( ) ;<br />
}<br />
sopra
Seite 14<br />
5 USE-CASE-DIAGRAMM<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
5 Use-Case-Diagramm<br />
Im Use-Case-Diagramm werden die Anwendungsfälle dargestellt. Es gibt vier<br />
Benutzergruppen, die hier berücksichtigt werden. Die Dozenten, die Studenten,<br />
die Tutoren und das Anmeldesystem. Der Akteur Anmeldesystem stellt<br />
hier nicht die gesamte Funktionalität des Systems dar, sondern nur die Anwendungen,<br />
die bei Anwendungen von anderen Akteuren für diese sichtbar<br />
werden.<br />
Eine kleine Veränderung im Vergleich zur Anforderungsdefinition ist hier,<br />
dass der Tutor sich selbst als Mensch dem System bekannt machen muss, bevor<br />
der Dozent ihn als Tutor auswählen kann. In der Anforderungsdefinition<br />
wurde der Tutor noch vom Dozenten angelegt.<br />
Es wird zunächst der Akteur Anmeldesystem näher betrachtet. Das Anmeldesystem<br />
hat nur zwei nach aussen sichtbare Anwendungsfälle. Dabei handelt<br />
es sich einerseits um das Überprüfen der Eingaben der anderen Akteure und<br />
deren Benachrichtigung durch das Anmeldesystem über die Ergebnisse der<br />
Anmeldung und andererseits die Endverteilung. Der Tutor kann nur einen<br />
Tutorennutzer anlegen. Dieser Anwendungsfall überschneidet sich mit dem<br />
Anlegen eines Studenten- oder Dozentennutzers, da der Tutor dem System<br />
bereits als Dozent oder Student bzw. als Mensch (siehe Klassendiagramm)<br />
bekannt sein muss. Als passiven Anwendungsfall enthält der Akteur Tutor<br />
das Benachrichtigtwerden durch das Anmeldesystem.<br />
Der Akteur Dozent besitzt fünf Anwendungsfälle. Der erste ist das Anlegen<br />
eines Dozentennutzer im System. Diesen Anwendungsfall können nur Personen<br />
starten, die im VV als Dozenten geführt sind. Der zweite Anwendungsfall<br />
des Dozenten ist das Anlegen einer Veranstaltung. Hierbei werden alle für die<br />
Klasse Veranstaltung notwendigen Informationen erfasst. Im dritten Anwendungsfall<br />
können diese Daten dann verändert werden. Der vierte und letzte<br />
aktive Anwendungsfall ist das Einpflegen von Sonderfällen und das manuelle<br />
Ändern der Ergebnislisten. Der fünfte Anwendungsfall ist wieder der passive<br />
Anwendungsfall, durch das Anmeldesystem benachrichtigt zu werden.<br />
Der Akteur Student besitzt drei aktive Anwendungsfälle und einen passiven<br />
Anwendungsfall. Wir nennen hier nur die aktiven Anwendungsfälle, da der<br />
passive wieder eine Benachrichtigung ist:<br />
Der erste ist das Anlegen eines Studentennutzers. Der zweite ist das<br />
Auswählen von Veranstaltungen und das Setzen oder Ändern der Prioritäten<br />
der einzelnen Termine. Der dritte ist das Erstellen von Arbeitsgruppen zu den<br />
einzelnen Veranstaltungen.<br />
Neben dem Use-Case-Diagramm mit der Gesamtansicht sind noch zwei weitere<br />
Use-Case-Diagramme dargestellt. Dies geschieht zur besseren Übersicht<br />
über die gesamten Anwendungsfälle. Beim ersten ist der Akteur Student aussopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 15<br />
5 USE-CASE-DIAGRAMM<br />
Abbildung 6: Use-Case-Diagramm des Anmeldesystems<br />
geblendet, damit man besser die Anwendungsfälle der anderen Akteure sehen<br />
kann. Beim zweiten ist dann dementsprechend nur der Akteur Student näher<br />
betrachtet worden. Die Anwendungsfälle sind dabei aber die selben wie im<br />
Gesamtdiagramm.<br />
sopra
Seite 16<br />
5 USE-CASE-DIAGRAMM<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 7: Das Anmeldesystem aus der Dozentensicht<br />
Abbildung 8: Das Anmeldesystem aus der Studentensicht<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 17<br />
6 ABLAUF<br />
6 Ablauf<br />
6.1 Dozent<br />
Die Rolle des Dozenten wurde von uns schon in der Anforderungsdefinition<br />
erläutert und wird jetzt hier präzisiert.<br />
Die Hauptaufgaben des Dozenten sind: Neue Kurse anlegen und bestehende<br />
Kurse modifizieren. Weiterhin soll der Dozent noch Änderungen an seinen<br />
Daten nachpflegen können.<br />
Wir haben einen typischen Arbeitsablauf im Folgenden dargestellt:<br />
6.1.1 Aktivitätsdiagramm<br />
Das Aktivitätsdiagramm (Abb. 9 auf der nächsten Seite) erläutert, was der<br />
Dozent während einer Sitzung am System für Möglichkeiten hat.<br />
Eine typische Sitzung des Dozenten beginnt mit dem Login. Dies kann er<br />
so oft versuchen, bis er einmal Erfolg hatte (eventuell sollte hier noch eine<br />
Sperre eingebaut werden, die vor automatisierten Angriffen schützt).<br />
Nach einem erfolgreichen LogIn kommt der Dozent auf eine Auswahlseite, auf<br />
der er drei Möglichkeiten hat: Zum Einen kann er seine eigenen Daten ändern,<br />
zum Anderen kann er Kurse ändern oder neu eingeben und als Drittes kann<br />
er sich vom System wieder abmelden.<br />
Wenn er Daten ändert, dann wird vor dem Zurückschreiben in die Datenbank<br />
noch eine Konsistenzprüfung ausgeführt. Dies ist insbesondere für das<br />
Setzen des Passworts wichtig, damit nicht ausversehen das Passwort falsch<br />
eingegeben wurde. Um das Passwort zu ändern, muss es zwei Mal in Folge<br />
richtig eingegeben werden.<br />
Eventuell kann man auch die E-Mail-Adresse des Dozenten automatisch<br />
überprüfen und nur, wenn der angegebene Mail-Provider diese akzeptiert,<br />
eine Änderung zulassen.<br />
Bei der Änderung von Veranstaltungen soll der Dozent zwei Möglichkeiten<br />
haben: zum Einen soll er neue Veranstaltungen anlegen können und zum<br />
Anderen bestehende Veranstaltungen modifizieren können. Hierfür wird es<br />
dann jeweils eine eigene Seite geben.<br />
Nachdem er die Veranstaltung ausgewählt hat, an der er Änderungen vornehmen<br />
will (oder sie neu erstellt hat), wird er zu einer Seite weitergeleitet,<br />
auf der er entweder einzelne Termine ändern bzw. hinzufügen (wieder mit<br />
Konsistenzprüfung) oder zurück zur Auswahlseite gelangen kann.<br />
Dadurch, dass mehrere Termine am Stück geändert werden können, ohne<br />
dass der Dozent jedes mal die Auswahlseite neu besuchen muss, sollte sich<br />
eine bessere Benutzerfreundlichkeit ergeben.<br />
sopra
Seite 18<br />
6 ABLAUF<br />
6.1 Dozent<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 9: Aktivitätsdiagramm des Dozenten<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 19<br />
6 ABLAUF<br />
6.1 Dozent<br />
6.1.2 Zustandsdiagramm<br />
Das Zustandsdiagramm des Dozenten (Abb. 10 auf der nächsten Seite) zeigt<br />
jetzt die einzelnen Zustände für die von uns geforderten Klassen am Beispiel<br />
des Aktivitätsdiagramms des Dozenten auf.<br />
Hierbei erzeugt der Dozent in der AuthServlet-Klasse eine gültige HttpSession,<br />
mit deren Hilfe dann der weitere Ablauf modelliert wird. Diese Session<br />
wird von javax.servlet verwaltet, wir brauchen uns darum also keine Gedanken<br />
machen. Sie ist immer für eine Sitzung persistent und wir können<br />
an sie Attribute setzen. Wenn eine neue Seite aufgerufen wird, kann sie die<br />
Session von der vorherigen Seite sozusagen übernehmen. Dies geschieht entweder<br />
durch Cookies oder, falls der Browser keine Cookies unterstützt, durch<br />
URL-Codierung. Die Auth-Servlet-Klasse hängt die User-ID an die erzeugte<br />
HttpSession mit an.<br />
Nach erfolgreicher Authentifizierung erzeugt das Choice-Servlet die Auswahlseite<br />
und leitet dann je nach oben erläuterter Aktion (Eigene Daten ändern,<br />
Veranstaltungen ändern, Logout) weiter.<br />
Das ChangeOwnDataServlet dient zur Änderung der eigenen Daten. Es<br />
überprüft die Eingaben und hat als einzigen Ausgang wieder das Choice-<br />
Servlet. Es nutzt die vom AuthServlet generierte User-ID, um auf die Daten<br />
des Benutzers zuzugreifen.<br />
Im ClassesListServlet, das auch über das ChoiceServlet erreichbar ist, werden<br />
dann erst einmal alle Veranstaltungen dargestellt, die der Dozent hält.<br />
Jetzt kann der Dozent sich entscheiden, entweder eine Veranstaltung zu modifizieren<br />
(ModifyClassServlet) oder eine neue anzulegen (NewClassServlet).<br />
Beide Objekte hängen dann das Attribut “selectedClass“ an die HttpSession<br />
an.<br />
Mittels der ausgewählten Veranstaltung (“selectedClass’”), die ja in der Session<br />
gespeichert ist, generiert das ListClassServlet eine Terminliste der Veranstaltung.<br />
Hier hat der Dozent jetzt wieder die Möglichkeit, einzelne Termine<br />
zu ändern oder neue hinzuzufügen. Wenn er einen Termin ändern will, setzt<br />
das ListClassServlet das Attribut “session“ in der HttpSession. Es gibt auch<br />
die Möglichkeit, wieder zur Auswahlseite zurückzugehen.<br />
Das Attribut “session“, das vom ListClassServlet gesetzt wurde, wird jetzt<br />
vom ChangeSessionServlet ausgelesen. Innerhalb dieser Klasse kann der Veranstaltungstermin<br />
verändert werden, es wird auch eine Konsistenzprüfung<br />
der Daten durchgeführt. Wenn der Veranstaltungstermin erfolgreich geändert<br />
wurde, geht es zurück zum ListOfSessionsServlet.<br />
Das Logout-Servlet ist dann der Endzustand, dieser ist auch von der Seite,<br />
die durch das ChoiceServlet generiert wird, zu erreichen. Es sorgt dafür, dass<br />
die HttpSession vernichtet wird.<br />
sopra
Seite 20<br />
6 ABLAUF<br />
6.1 Dozent<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 10: Zustandsdiagramm für die Klassen, mit denen der Dozent<br />
interagiert<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 21<br />
6 ABLAUF<br />
6.1 Dozent<br />
6.1.3 Sequenzdiagramm<br />
Das hier gezeigte Sequenzdiagramm (Abb. 11 auf der nächsten Seite) zeigt<br />
die Kommunikationswege zwischen den einzelnen Objekten, die für die Dozentenaktivität<br />
des Änderns der Veranstaltungsliste nötig sind.<br />
Dabei kommuniziert der Browser des Dozenten mit den kurzlebigen Objekten<br />
der Servletklassen. Beim Ansurfen der Loginseite, fordert der Browser das<br />
LoginServlet-Objekt dazu auf, ihm die Seite zu schicken (ab jetzt wird zur<br />
Vereinfachung im Text nicht mehr immer erwähnt, dass es sich um ein Objekt<br />
handelt; sollte mal auf die Klasse zugegriffen werden, so wird dieses speziell<br />
hervorgehoben). Bevor das LoginServlet aber die Seite zurückliefert, erzeugt<br />
es noch eine Session. Nachdem die Loginseite an den Browser zurückgeliefert<br />
wurde, beendet sich das LoginServlet. Nun kann der Dozent seine Logindaten<br />
eintragen und auf den Button Login klicken. Diese Aktion veranlasst den<br />
Browser, das AuthServlet mit diesen Daten aufzurufen. Dieses fragt dann<br />
in der Datenbank nach, ob diese Eingaben korrekt sind. Sind sie korrekt, so<br />
sendet die Datenbank diese Daten erst an die Session weiter, in der die Daten<br />
zwischengespeichert werden und gibt dann dem AuthServlet seine Antwort.<br />
Dieses erstellt dann die Auswahlseite und liefert sie an den Browser zurück.<br />
Danach beendet sich das AuthServlet. Waren die Eingaben falsch, so erstellt<br />
das AuthServlet wieder die Loginseite und der Dozent kann die Daten noch<br />
einmal eingeben.<br />
In diesem Aktionsfall wählt der Dozent den Button Veranstaltungen modifizieren.<br />
Diese Aktion veranlasst den Browser, beim ClassesListServlet die<br />
Veranstaltungsliste des Dozenten zu erfragen. Das ClassesListServlet fragt<br />
also die Session nach diesen Daten und, da die Session bisher noch nicht<br />
über diese Daten verfügt, fragt sie schließlich die Datenbank nach diesen Daten.<br />
Von der Datenbank gehen die Daten an die Session, diese speichert sie<br />
erst einmal ab und reicht sie dann an das ClassesListServlet weiter, welches<br />
mittels dieser Daten die Veranstaltungsliste-Seite generiert und liefert sie an<br />
den Browser zurück. Danach beendet sich das ClassesListServlet.<br />
Nun ändert der Dozent die Daten seiner Veranstaltung und klickt dann auf<br />
den Button Änderungen speichern. Dieses veranlasst das ModifyClassesServlet<br />
dazu, die Daten entgegenzunehmen und an die Session weiterzureichen, in<br />
der die Daten dann gespeichert werden. Nachdem das ModifyClassesServlet<br />
das Okay der Session erhalten hat, ruft es das ClassesListServlet mit den neuen<br />
Daten auf und beendet sich. Das ClassesListServlet generiert - wie oben<br />
schon beschrieben - die Seite für den Browser, sendet sie an den Browser und<br />
beendet sich. Nach dem Ändern klickt der Dozent auf den entsprechenden<br />
Button, um zur Auswahlseite zurückzugelangen. Diese Aktion ruft das ChoiceServlet<br />
auf, welches die Auswahlseite erstellt und sie an den Browser liefert<br />
sopra
Seite 22<br />
6 ABLAUF<br />
6.1 Dozent<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 11: Das Sequenzdiagramm des Dozenten<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 23<br />
6 ABLAUF<br />
6.1 Dozent<br />
und sich dann beendet.<br />
Auf der Auswahlseite wählt der Dozent dann den Logout Button. Diese Aktion<br />
ruft das LogoutServlet auf. Dieses teilt der Session mit, dass sie sich<br />
beenden soll. Die Session übermittelt daher der Datenbank alle relevanten<br />
Daten zum Abspeichern. Bekommt die Session das Okay der Datenbank, so<br />
sagt die Session dem LogoutServlet, dass sie sich jetzt beenden wird und beendet<br />
sich. Das LogoutServlet generiert daraufhin die Logoutseite und liefert<br />
sie an den Browser. Danach beendet sich das LogoutServlet und der Dozent<br />
hat erfolgreich die Daten seiner Veranstaltung geändert.<br />
sopra
Seite 24<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
6.2 Student<br />
Wie in der Einleitung erwähnt, handelt es sich bei den Studenten im Grunde<br />
um die Hauptakteure des Übungsanmeldesystems, nicht aufgrund ihrer<br />
qualitativen Rechte (die sind eher geringfügig gegenüber beispielsweise den<br />
Dozenten), sondern vielmehr aufgrund ihrer quantitativen Überlegenheit und<br />
der Tatsache, dass dieses Übungsanmeldesystem hauptsächlich die Verteilung<br />
von Studenten auf Tutorien und Veranstaltungen regelt und nicht deren Ansetzung.<br />
6.2.1 Aktivitätsdiagramm<br />
Das Aktivitätsdiagramm für Studenten wurde zur bessern Lesbarkeit aufgeteilt:<br />
zusätzlich zu dem Hauptdiagramm (Abb. 12 auf der nächsten Seite)<br />
existieren Unterdiagramme zu den Aktivitäten Anmelden (Abb. 13 auf<br />
Seite 27), Account anlegen (Abb. 14 auf Seite 28), Einloggen (Abb. 15 auf<br />
Seite 29), Dateneingabe (Abb. 16 auf Seite 30), Gruppenwahl (Abb. 17 auf<br />
Seite 32) und Abschluss (Abb. 18 auf Seite 33).<br />
Desweiteren wurde auf die In-Diagramm-Kommentierung weitgehend verzichtet,<br />
da diese zwar geringfügige Zusatzinformationen bereitstellt, aber die<br />
Übersicht stark einschränkt. Ein Beispiel ist in Abschnitt 7.2 auf Seite 39 zu<br />
finden. Stattdessen liegen die entsprechenden Kommentare nun in Fließtext<br />
zur sinnvollen Begleitung der Diagramme vor. Es wird zuerst das Hauptdiagramm<br />
und dann jedes Subdiagramm für sich erläutert:<br />
Im Hauptdiagramm (Abb. 12 auf der nächsten Seite) findet sich der grobe<br />
Aktivitätsablauf eines jeden Studenten, der mit dem Übungsanmeldesystems<br />
interagiert: die erste Aktivität ist natürlich das Anmelden beim System. Da<br />
es sich hierbei um eine komplexe Handlung handelt, ist der genaue Aktivitätsablauf<br />
in dem Unteraktivitäts-Diagramm Anmelden (Abb. 13 auf Seite 27)<br />
dargestellt.<br />
Nach dem Anmelden stellt sich erstmal die Frage, wie das Anmelden abgelaufen<br />
ist: ist das Anmelden solange fehlgeschlagen, bis die Anmeldezeit (AZ)<br />
vorbei war, so wird die Aktivität direkt zur Endaktivität geführt und terminiert.<br />
In diesem Fall wird der Student nicht berücksichtigt im Übungsanmeldesystem,<br />
da er leider nicht in der Lage war, sich rechtzeitig anzumelden. Im<br />
Normalfall allerdings wird das Anmelden positiv verlaufen sein, so dass nun<br />
mit der Dateneingabe fortgefahren werden kann.<br />
Die Dateneingabe ist das Herzstück des Aktivitätsdiagramms des Studenten:<br />
auch hierfür liegt ein weiteres Unteraktivitätsdiagramm (Dateneingabe;<br />
Abb. 16 auf Seite 30) vor, es umfasst die gesamte Dateneingabe-Routine<br />
inklusive der nachträglichen Datenänderungsmöglichkeiten des Studenten.<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 25<br />
6 ABLAUF<br />
6.2 Student<br />
Abbildung 12: Aktivitätsdiagramm des Studenten - Hauptübersicht<br />
sopra
Seite 26<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Während der Dateneingabe ist es natürlich durchgängig möglich, die Info-<br />
Dateien einzusehen, um sich Menüpunkte noch genauer erklären zu lassen<br />
oder - im Fall eines Studenten, dessen Muttersprache nicht deutsch ist - sich<br />
in den Info-Dateien die Übersetzungen und Erläuterungen auf englisch oder<br />
gar der eigenen Muttersprache anzeigen zu lassen (optionales Feature).<br />
Hat man die Dateneingabe und das Betrachten der Info-Dateien soweit abgeschlossen,<br />
ist man erstmal fertig. Solange die Anmeldezeit (AZ) noch läuft,<br />
besteht an dieser Stelle immer die Möglichkeit, dass man noch Informationen<br />
vom System zugeschickt bekommt, welche sowohl das Eliminieren einer Veranstaltung<br />
durch einen Dozenten, das Kreiren eines Tutorium durch selbige<br />
Personengruppe, die Feststellung der Voranalyse, dass ein Wunschtutorium<br />
des Studenten heillos überfüllt ist, oder ähnliche Ereignisse betreffen kann.<br />
Nun kann der Student wiederum entscheiden, ob er seine Daten ein weiteres<br />
Mal editieren soll, oder mit seinen Eingaben erstmal weiterhin zufrieden ist.<br />
Möchte er seine Eingaben ändern, so muss er sich erstmal ein weiteres Mal<br />
einloggen, was im Unteraktivitätsdiagramm Einloggen (Abb. 15 auf Seite 29)<br />
zusammengefasst ist.<br />
Möchte der Student zu dieser Zeit nichts ändern, so verbleibt ihm diese<br />
Möglichkeit trotzdem noch bis die Anmeldezeit abgelaufen ist. Ist dieses der<br />
Fall - also die Anmeldezeit abgelaufen -, lassen sich keine weiteren Änderungen<br />
mehr vornehmen und es beginnen die weitgehend passiven Abschluss-<br />
Aktivitäten des Studenten, die in dem Unteraktivitäts-Diagramm Abschluss<br />
(Abb. 18 auf Seite 33) zusammengefasst sind; hiernach terminiert die Aktivität<br />
des Studenten in Hinblick auf das Übungsanmeldesystem.<br />
Das Unteraktivitätsdiagramm Anmelden (Abb. 13 auf der nächsten Seite)<br />
stellt den ersten Schritt der Aktivität des Studenten in Hinblick auf das<br />
Übungsanmeldesystems dar: insofern ist der erste Schritt des Studenten<br />
natürlich das Aufsuchen eines Rechners. Ist dieses einmal geschafft, stellt<br />
sich die Frage, in welchem Zeitabschnitt wir gerade sind: hat die Anmeldezeit<br />
noch gar nicht begonnen, so bleibt dem Studenten nichts anders übrig,<br />
als auf den Anfang der Anmeldezeit zu warten; ist die Anmeldezeit hingegen<br />
bereits zu Ende, so kann der Student leider nicht mehr in das Übungsanmeldesystem<br />
dieses Semesters aufgenommen werden. Somit führt diese Bedingung<br />
zu einer Endaktivität, nämlich der zweiten Endaktivität dieses Unteraktivitätsdiagramms,<br />
welche im Hauptdiagramm direkt in die Endaktivität<br />
einmündet. In der Realität besteht natürlich auch hier noch die Möglichkeit<br />
bestimmter Härtefallregelungen und Absprachen mit Dozenten und Tutoren,<br />
das ist allerdings nicht mehr Teil dieses Systems und im Allgemeinen auch<br />
nicht praktikabel.<br />
Läuft hingegen die Anmeldezeit - und das ist der Normalfall bei der jahreszeitlichen<br />
Anfangsaktivität des Student -, so besteht natürlich die Möglichsopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 27<br />
6 ABLAUF<br />
6.2 Student<br />
Abbildung 13: Aktivitätsdiagramm des Studenten - Unterdiagramm Anmelden<br />
sopra
Seite 28<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
keit, einen Account anzulegen: hierbei ist die erste Möglichkeit für den Studenten,<br />
sich einfach über seinen FB3-LogIn zu authentifizieren, dafür muss<br />
dieser angegeben werden und dann vom System bestätigt werden; klappt<br />
dieses, kann der User sich mit dem FB3-LogIn authentifizieren. Ist allerdings<br />
kein FB3-LogIn vorhanden oder möchte man diesen aus irgendeinem Grund<br />
nicht dafür verwenden, reicht es auch, wenn man sich im UNI-Netz befindet.<br />
Auch über einen Zugriff vom UNI-Netz kann man sich nämlich einen Account<br />
anlegen.<br />
Ist man allerdings auch nicht im UNI-Netz zugegen, so sollte man sich schnellstens<br />
dorthin begeben und dort wiederum einen Rechner aufsuchen, um noch<br />
rechtzeitig im Übungsanmeldesystem berücksichtigt zu werden und nicht versehentlich<br />
bis nach dem Ende der Übungsanmeldezeit warten, da dann - wie<br />
oben gesagt - nur noch persönliche Absprachen mit Dozenten und Tutoren<br />
möglich sind, was das ganze System eher verkompliziert.<br />
Hat nun mit der Authentifizierung alles funktioniert, kann man fortfahren,<br />
sich einen Account anzulegen. Das Anlegen des Accounts ist wiederum in<br />
einem Unteraktivitäts-Diagramm Account anlegen (Abb. 14) dargestellt:<br />
Abbildung 14: Aktivitätsdiagramm des Studenten - Unterdiagramm Account<br />
Anlegen<br />
Das Unteraktivitätsdiagramm für die Anlage eines Accounts beginnt sinnigerweise<br />
mit der Eingabe des Benutzernamens. Dann wird geprüft, ob der<br />
gewünschte Username in dieser Form zulässig ist, das heisst, ob er erstens<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 29<br />
6 ABLAUF<br />
6.2 Student<br />
ausschließlich aus gültigen Zeichen besteht und zweitens noch nicht vergeben<br />
ist. Unter Umständen muss der neue User sich einen anderen UserName<br />
suchen!<br />
Nun muss ein Passwort gewählt werden, welches zur Bestätigung noch ein<br />
zweites Mal eingegeben werden muss, um Tippfehler zu vermeiden. Im Anschluss<br />
findet eine Konsistenzprüfung statt, ob die beiden Eingaben identisch<br />
sind, ist dieses nicht der Fall, muss die Passwort-Eingabe wiederum wiederholt<br />
werden. Im Erfolgsfall hingegen hat man sich erfolgreich einen Account<br />
angelegt.<br />
Abbildung 15: Aktivitätsdiagramm des Studenten - Unterdiagramm Einloggen<br />
Das Einloggen (Abb. 15) steht natürlich im engen Zusammenhang mit der<br />
Accountanlegung. Wie man leicht im Unteraktivitätsdiagramm sehen kann,<br />
muss hier erst der Username eingegeben werden und dann das zugehörige<br />
Passwort, hiernach gibt es wiederum eine Konsistenzprüfung: passt das<br />
eingebene Passwort nicht zum entsprechenden UserName oder existiert der<br />
Username schlichtweg überhaupt nicht, so muss der Einlog-Vorgang wiederholt<br />
werden. Im Erfolgsfall jedoch wird man direkt zur Voranalyse weitergeleitet,<br />
die einem einen kurzen, aber hoch-informativen, Überblick über die<br />
bisherige Verteilung der Tutoriumsplätze gibt und einem so die Möglichkeit<br />
gibt, selber an der Verbesserung des eigenen Studienplanes mitzuhelfen.<br />
Das Unteraktivitätsdiagramm für die Dateneingabe (Abb. 16 auf der<br />
nächsten Seite) beginnt direkt mit der Abfrage, ob die Liste der bisher vom<br />
User gewählten Veranstaltung (VerList) leer ist. Ist dieses der Fall, wird<br />
sopra
Seite 30<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 16: Aktivitätsdiagramm des Studenten - Unterdiagramm Dateneingabe<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 31<br />
6 ABLAUF<br />
6.2 Student<br />
der User direkt aufgefordert, eine erste Veranstaltung aus dem Veranstaltungsverzeichnis<br />
(VV) auszuwählen und seiner VerList hinzuzufügen (die<br />
weitere Verfahrensweise hierzu wird weiter unten bei Verzeichnis hinzufügen<br />
erläutert). Ansonsten (bei nicht leerer VerList) kommt der Student in ein<br />
Menü, in dem er eine Liste der bereits von ihm ausgewählten Veranstaltungen<br />
vor Augen und die Möglichkeit hat, aus folgenden Handlungen zu wählen:<br />
eine Veranstaltung löschen, eine Veranstaltung ändern, eine Veranstaltung<br />
aus dem VV hinzufügen oder Speichern & Ausloggen.<br />
Bei der Option Veranstaltung löschen wird die gerade gewählte Veranstaltung<br />
aus der VerList gelöscht, danach wird die Dateneingabe initial neu gestartet,<br />
d.h. es wird an der Stelle fortgefahren, wo die Prüfung stattfindet, ob<br />
die VerList leer ist. Wählt man die Option Veranstaltung ändern, so muss<br />
man als nächstes zu der gewählten Veranstaltung die Prioritäten auf die<br />
Tutorien verteilen, wobei die neuen Werte mit den bisherigen Werten vorinitialisiert<br />
sind und entsprechend auch so angezeigt werden, hierauf folgt<br />
eine Konsistenzprüfung, ob die Eingaben korrekt waren (entsprechend dem<br />
Schlüssel, dass jede Priorität (abgesehen von der 10) nur höchstens einmal<br />
vorkommt). Ist dies nicht der Fall, müssen die Prioritäten nochmals verteilt<br />
werden. Ist die Prioritätenverteilung formal korrekt, kann der Student nun<br />
mit der Gruppenverwaltung für die entsprechende Veranstaltung fortfahren,<br />
welche im Unteraktivitätsdiagramm Gruppenwahl (Abb. 17 auf der nächsten<br />
Seite) dargestellt ist. Auch hierauf folgt eine Konsistenzprüfung, welche bei<br />
Nichterfolg zurück und bei Erfolg wieder an den Anfang zur Prüfung auf<br />
leere Verzeichnis-Liste zurückkehrt.<br />
Als dritte Möglichkeit bietet sich das Hinzufügen einer weiteren Veranstaltung,<br />
dieses ist über ein Veranstaltungs-Verzeichnis gelöst, bei dem<br />
leicht über CheckBoxen die gewünschten Veranstaltungen ausgewählt werden<br />
können. Hierbei ist keine Konsistenzprüfung vonnöten, da hier nichts<br />
schief gehen kann. Danach hat man die Möglichkeit, entweder wieder ins<br />
Menü zurückzukehren oder gleich die Prioritäten und die Gruppenwerte zu<br />
setzen, was gleichbedeutend mit dem Menüpunkt Veranstaltung ändern ist.<br />
Schließlich verbleibt noch die Möglichkeit, den Menüpunkt ”Speichern &<br />
Ausloggen” zu wählen; dieser versendet den Datensatz, durch dessen Empfang<br />
automatisch eine Empfangs-Bestätigung als Email an den Studenten<br />
verschickt wird. Erst nach dem bestätigten Empfang des Datensatzes, wird<br />
der User ausgeloggt.<br />
Beim Unteraktivitätsdiagramm Gruppenwahl (Abb. 17 auf der nächsten Seite)<br />
spalten sich die Möglichkeiten in zwei Arten: einerseits die Optionen, die<br />
davon abhängen, ob man eine eigene (Einzel-)Gruppe hat oder Teil einer<br />
Gruppe ist und andererseits die Funktionen, die hiervon unabhängig sind.<br />
Im ersten Bereich sind die Optionen User in die Gruppe einladen, Einladung<br />
sopra
Seite 32<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 17: Aktivitätsdiagramm des Studenten - Unterdiagramm Gruppenwahl<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 33<br />
6 ABLAUF<br />
6.2 Student<br />
zurückziehen und Gruppenverwaltung beeden. Im zweiten Bereich befinden<br />
sich Gruppe beitreten und Gruppe verlassen.<br />
Einen weiteren User einladen kann man nur dann, wenn die Gruppe noch<br />
nicht voll ist (bzw. solange noch weniger Einladungen vorhanden sind als<br />
die Gruppe groß sein darf). In diesem Fall muss man dann den gewünschten<br />
User auswählen, der dann eine Einladung zugeschickt bekommt. Hiernach<br />
wird man automatisch wieder ins Menü zurückgeleitet.<br />
Eine Einladung zurückziehen kann man nur dann, wenn noch eine offene<br />
Einladung existiert, d.h. eine ausgesprochene Einladung, die noch nicht angenommen<br />
wurde. Hierzu muss man wiederum einen User auswählen, dieser<br />
wird natürlich darüber informiert, dass die Einladung zurückgezogen wurde.<br />
Danach kommt man automatisch wieder ins Menü. Es ist natürlich immer<br />
möglich, die Gruppenverwaltung zu beenden.<br />
Möchte man einer Gruppe beitreten, so darf man noch keiner Gruppe (ausser<br />
der eigenen Einzelgruppe) in dieser Veranstaltung angehören und muss außerdem<br />
natürlich eine Einladung einer anderen Gruppe haben. Nimmt man<br />
die Einladung an, so tritt man dieser Gruppe bei und kehrt ins Menü zurück.<br />
Um wiederum eine Gruppe zu verlassen, muss man natürlich Mitglied einer<br />
echten Gruppe sein. Einzelgruppen können natürlich auch nicht verlassen<br />
werden. Auch hiernach kehrt man ins Menü zurück.<br />
Das Abschluss-Unteraktivitätsdiagramm (Abb. 18) schließt schließlich das<br />
Aktivitätsdiagramm das Studenten ab. Dabei beginnt der Abschluss mit dem<br />
Versand der Ergebnis-E-Mail, die nach der Berechnung und Abnahme des<br />
Plans durch den Admin automatisch erstellt wird. Nun kann der Student,<br />
wenn ihn etwas an seinem Plan stört oder ihm gar als nicht erfüllbar erscheint<br />
und er sich somit für einen Härtefall hält, direkt noch Absprachen<br />
mit dem Dozenten treffen, den er dann von der Notwendigkeit seiner Anliegen<br />
überzeugen muss.<br />
Schließlich muss der Student noch entscheiden, ob er einen automatisch erstellten<br />
Stundenplan (ASP) haben möchte. Dieser ähnelt der Stundenplan-<br />
Version, die zur Zeit vom Online-Veranstaltungs-Verzeichnis angeboten wird,<br />
nur mit dem Unterschied, dass wirklich nur die eigenen Tutorien und nicht<br />
auch alle anderen Tutorien des entsprechenden Kurses angezeigt werden.<br />
Fordert der Student den ASP an, so erhält er ihn natürlich auch, auf jeden<br />
Fall ist die Aktivität des Studenten in Bezug auf das Übungsanmeldesystem<br />
somit beendet.<br />
sopra
Seite 34<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 18: Aktivitätsdiagramm des Studenten - Unterdiagramm Abschluss<br />
6.2.2 Zustandsdiagramm<br />
Es folgt nun die Beschreibung des Zustandsdiagramms für Studenten<br />
(Abb. 19 auf der nächsten Seite:<br />
Die typische Handlung eines Studenten ist die Dateneingabe. Dabei stellt<br />
sich als erstes die Frage, ob ein Account - in diesem Fall ist mit Account der<br />
temporäre Account gemeint, der die Eingabedaten entegegen nimmt vom<br />
User und sie zwischenspeichert, bis sie versendet werden; nicht gemeint ist<br />
der Account des jeweiligen Studenten in der Datenbank - vorhanden ist.<br />
Ist dieses nicht der Fall, landet man natürlich im Zustand kein Account, bei<br />
diesem ist die Funktion entry/ ausführbar und man kann einen Account anlegen.<br />
Hierdurch werden die Variablen vorinitialisiert (die String-Variablen<br />
UserName und Password durch User Input, die anderen (List of String Ver-<br />
List, List of List of Int prior, List of List of Student gruppe etc.) durch die<br />
bisherigen Werte des entsprechenden Users). Somit erreicht man nun den<br />
Zustand Account angelegt.<br />
Aus diesem kommt man nun leicht in den Zustand Account vorhanden. Von<br />
diesem aus geht es nun genauso weiter, als wäre bei der ersten Abfrage der<br />
Account bereits vorhanden gewesen. Als Erstes wird geprüft, ob die Liste<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 35<br />
6 ABLAUF<br />
6.2 Student<br />
Abbildung 19: Das Zustandsdiagramm für Studenten<br />
sopra
Seite 36<br />
6 ABLAUF<br />
6.2 Student<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
der vom User bereits gewählten Veranstaltungen VerList leer ist. Ist dieses<br />
der Fall, kommt man in den Zustand Account leer, ansonsten in den Zustand<br />
Account nicht leer.<br />
In beiden Fällen wird nun entweder (auf verschiedene Art und Weise:<br />
bei leerem Account wird die VerList() auf jeden Fall geändert(aufgefüllt);<br />
bei nicht-leerem Account stehen dem User alle Menü-Optionen offen) der<br />
Account geändert und dann über den Zustand Account geändert zu der<br />
Frage zurückgekehrt, ob die VerList leer ist oder ganz einfach die Daten<br />
übermittelt. Werden die Daten übermittelt, so gelangt man in den Zustand<br />
Daten übermittelt und es wird nun der Destruktor für den Account aufrufen<br />
und somit landen wir im Endzustand.<br />
6.2.3 Sequenzdiagramm<br />
Das Sequenzdiagramm der Studenten (Abb. 20 auf der nächsten Seite) entspricht<br />
im Wesentlichen dem Sequenzdiagramm des Dozenten. Da die Unterschiede<br />
bei der Datenmodifikation nicht im Sequenzdiagramm auffallen und<br />
auch das Einloggen und Ausloggen identisch sind, sind die beiden Diagramm<br />
inhaltsgleich.<br />
sopra
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Seite 37<br />
6 ABLAUF<br />
6.2 Student<br />
Abbildung 20: Das Sequenzdiagramm der Studenten<br />
sopra
Seite 38<br />
7 ANHANG<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
7 Anhang<br />
7.1 Glossar<br />
Aktivitätsdiagramm Quelle: [?]<br />
Klassendiagramm Quelle: [?]<br />
Sequenzdiagramm Quelle: [?]<br />
Ein Aktivitätsdiagramm dient zur Darstellung eines Systemablaufes in<br />
der <strong>Informatik</strong>. Mit einem solchen Diagramm wird häufig ein Use-Case<br />
(Geschäftsvorfall, Anwendungsfall) verfeinert.<br />
In der Regel besitzt ein Aktivitätendiagramm einen wohl definierten<br />
Start- und Endpunkt. Dazwischen können Aktivitäten, Entscheidungen,<br />
Zustände (States) modelliert werden.<br />
Das Aktivitätendiagramm ist eine objektorientierte Adapation des<br />
Fluss-Diagramms<br />
Klassendiagramme beschreiben in der <strong>Informatik</strong> Objekt-Klassen durch<br />
Angaben der Operationen (Methoden/Funktionen), Zustände (Attribute)<br />
und, Beziehungen (Assoziationen / Relationen) zwischen den Klassen.<br />
In der UML, einer generellen Beschreibungssprache der <strong>Informatik</strong>, beschreibt<br />
das Sequenz-Diagramm einzelne, Abläufe in ihrer exakten Reihenfolge.<br />
Im Gegensatz dazu muss bei einem Kollaborations-Diagramm<br />
nicht der genaue Zeitpunkt feststehen.<br />
Ein Sequenz-Diagramm stellt in der Regel einen Weg durch einen Entscheidungsbaum<br />
innerhalb eines Systemablaufes dar.<br />
Use-Case-Diagramm auch: Anwendungsfalldiagramm<br />
Quelle: [?]<br />
Anwendungsfälle beschreiben das gewünschte Systemverhalten aus der<br />
Sicht der Anwender. Es wird aufgezeigt, WAS möglich sein muss,<br />
aber nicht WIE. In einem Anwendungsfalldiagramm werden die Anwendungsfälle<br />
und die Akteure (Personen, Systeme) zusammengestellt.<br />
Die Beziehungen untereinander werden durch Pfeile (mit Beschriftung<br />
und ) ausgedrückt.<br />
Neben den Entitäten Anwender(gruppen) und Anwendungsfälle existiert<br />
noch die Systemgrenze (Swim-Lane). Hiermit werden verschiedene<br />
Systeme und/oder Verantwortlichkeiten voneinander getrennt.<br />
sopra
Seite 39<br />
Gestaltung soziotechnischer Systeme<br />
7 ANHANG<br />
7.2 3. Semester kommentierte Diagramme (als Beispiel: Teile des Aktivitätsdiagramms<br />
Anforderungsspezifikation<br />
Studenten)<br />
Zustandsdiagramm Quelle: [?]<br />
Nicht selten wird ein Anwendungsfall mit einem Aktivitätsdiagramm<br />
(Activity) verfeinert.<br />
Ein Zustands-Diagramm in der UML ist eine Darstellungsform in der<br />
<strong>Informatik</strong>. Es visualisiert die verschiedenen Zustände (z.B. Änderung<br />
von Attributwerten) einer Instanz (d.h. eines Objektes) einer Klasse.<br />
7.2 kommentierte Diagramme (als Beispiel: Teile des<br />
Aktivitätsdiagramms Studenten)<br />
Abbildung 21: das kommentierte Hauptteil des Aktivitätsdiagramms für Studenten<br />
7.3 Literatur<br />
sopra
Seite 40<br />
7 ANHANG<br />
7.3 Literatur<br />
Gestaltung soziotechnischer Systeme<br />
3. Semester<br />
Anforderungsspezifikation<br />
Abbildung 22: das kommentierte Unteraktivitätsdiagramm Anmelden für<br />
Studenten<br />
sopra