Universität Bremen Fachbereich 3 Studiengang Informatik Karl ...

Universität Bremen 

Fachbereich 3 

Studiengang Informatik 

Karl-Heinz Rödiger 

WiSe 2003/2004 

Soziotechnische Systeme 

VAK 03-901.01 

Tutor: Joachim Hinrichs 

Anforderungsspezifikation 

Erarbeitung eines Übungsanmeldesystems 

Gruppe sopra 

Stephan Großewinkelmann, Torben Hohn, Georg Lippold, 

Sebastian Offermann, Christian Peper, Hanene Samara 

Abgabedatum: 20. Februar 2004

Seite 2 

INHALTSVERZEICHNIS 

Gestaltung soziotechnischer Systeme 

3. Semester 


Inhaltsverzeichnis 

1 Einleitung 3 

2 Datenbankaufbau 5 

3 Die Klassendiagramme 7 

3.1 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

3.2 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

3.3 HTML Generierung . . . . . . . . . . . . . . . . . . . . . . . . 8 

3.4 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

4 Pseudo Code 11 

5 Use-Case-Diagramm 14 

6 Ablauf 17 

6.1 Dozent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

6.1.1 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . 17 

6.1.2 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . 19 

6.1.3 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . 21 

6.2 Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

6.2.1 Aktivitätsdiagramm . . . . . . . . . . . . . . . . . . . 24 

6.2.2 Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . 34 

6.2.3 Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . 36 

7 Anhang 38 

7.1 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

7.2 kommentierte Diagramme (als Beispiel: Teile des Aktivitätsdiagramms 

Studenten) . . . . . . . . . . . . . . . . . . . . . . 39 

7.3 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

sopra


3. Semester 


Seite 3 

1 EINLEITUNG 

1 Einleitung 

Als Teilnehmer des Kurses ”Gestaltung soziotechnischer Systeme” ist es unser 

erklärtes Ziel, ein System zu erschaffen, dass auf automatischem Wege 

einen fairen, anwendbaren Studienplan für einen großen Personenkreis erstellt. 

Hierbei muss es sich natürlich um ein in höchstem Maße interaktives System 

handeln, da bei jedem Ablauf initiierend eine quantitativ bedeutende 

Datenmenge eingegeben werden muss. 

Interessanterweise kann man das zu erschaffende Übungsanmeldesystem mit 

einem Theater-Stück vergleichen: bei jedem Theaterstück wird am Anfang 

überlegt, welche Intentionen hinter dem Werk stehen sollen; welche Wirkung 

soll erzielt, welche Auswirkung verhindert werden. Ebenso ist es bei jedem 

größeren Projekt unabdingbar, sein Vorgehen vorher zu planen: sich als ersten 

Schritt zu überlegen, was das System können sollte und wo Schnittstellen 

mit Benutzern oder gar anderen Systemen existieren. Insofern war die 

Anforderungsdefinition, welche natürlich stark soziologisch ist, ähnlich der 

Vorüberlegung der Erschaffung eines Theaterstücks. 

Im zweiten Schritt der Erschaffung eines Theaterstücks muss überlegt werden, 

welche stilistischen Mittel zum Erreichen der gewünschten Wirkung einzusetzen 

sind, um diese in einem roten Handlungsfaden einzuweben. Ebenso 

haben wir nun im zweiten Schritt auf unserem Weg zu überlegen, wie man die 

an das System gestellten Anforderung und die benötigten Schnittstellen mit 

technischen Mitteln umsetzen kann. Wir müssen hier eine Brücke zwischen 

den soziologischen Anforderungen und den technologischen Gegebenheiten 

schlagen, genau wie es der Theater-Autor zwischen Intention und Handlung 

bzw. Stil tut. Dabei verwenden wir in der hier vorliegenden Anforderungsspezifikation 

natürlich die in der Anforderungsdefinition erarbeiteten Ergebnisse 

und nutzen sie, um uns eine Grundlage für den weiteren Verlauf zu kreiren. 

Diese Anforderungsspezifikation umfasst fünf Hauptabschnitte: 

Das Schema des Datenbankaufbaus, die Klassendiagramme, ein bißchen 

Pseduo-Code, das Use-Case-Diagramm und für die Benutzergruppen Dozenten 

und Studenten jeweils ein Aktivitäts-, ein Zustands- und ein Sequenzdiagramm. 

Abgerundet wird diese Spezifikation durch diese Einleitung, ein 

Fazit und natürlich den Anhang. 

Der nächste Schritt des Theaterautors ist natürlich das Schreiben des eigentlichen 

Theaterstücks unter Verwendung des vorher angelegten roten Fadens, 

ebenso wird unsere nächste Aufgabe das Schreiben des Quellcodes für unser 

System sein. 

Schließlich, wenn das Werk bzw. das System selbst vollendet ist, liegt es 

an den beteiligten Personengruppen, es sinnvoll zu inszenieren: jedes Semesopra

Seite 4 

1 EINLEITUNG 


3. Semester 


ster läuft das Programm einmal durch, was etwa einer Theater-Vorführung 

entspricht: dabei entspricht die Raumvergabestelle der Finanzabteilung der 

Geldgeber (Universität und Land), die die Mittel zur Verfügung stellt, 

während die Dozenten als Produzenten eingesetzt werden, die Admins führen 

die Regie und die quantitativ herausragendste Gruppe der Studenten ist die 

Schauspieler-Riege, während letztlich die Autoren - zwar um eine Erfahrung 

reicher - im Allgemeinen weitgehend leer ausgehen. Unser Vorteil gegenüber 

den Autoren eines Theater-Stücks ist es, dass wir in der Tat in den nächsten 

Studienjahren selber von unseren Leistungen profitieren können, wenn wir es 

schaffen, dieses System zum Standars zu erheben. 

Also, bereiten wir die Bühne... 

sopra


3. Semester 


Seite 5 

2 DATENBANKAUFBAU 

2 Datenbankaufbau 

Wir haben uns zuerst Gedanken darüber gemacht, was nachher die Basis 

unseres Übungs-Anmelde-System bilden soll. Dies ist sicherlich eine Datenbank. 

Also haben wir diese zuerst designed, damit dann die Dinge, die darauf 

aufbauen, eine gute Grundlage haben (vgl. Abb. 1). Wir haben uns beim Design 

der Datenbank an unsere Anforderungsdefinition gehalten und dabei ein 

paar Dinge umspezifiziert, damit alles gut maschinell verarbeitbar ist. 

Abbildung 1: Beziehungen und Datenfelder in der Datenbank 

Beispielsweise haben wir die Zeitspanne, in der eine Veranstaltung stattfindet, 

dadurch gekennzeichnet, dass sie eine Anfangs- und eine Endzeit bekommen 

hat. 

Die Primärschlüssel der Datenbank sind fett gedruckt, Felder, die in anderen 

Tabellen referenziert werden, sind durch Linien verbunden. 

Die Tabelle Veranstaltungen enthält alle für eine Veranstaltung wichtigen 

Daten und wird von den Tutorien referenziert. Ein Tutorium gehört immer 

zu einer Veranstaltung. Die weiteren Felder der Tutoriumstabelle sind unserer 

Ansicht nach selbsterklärend. 

Weiterhin hat eine Veranstaltung einen Dozenten, der vom Typ Mensch ist. 

Menschen teilen sich noch in die Untergruppen Tutoren, Administratoren, 

Studenten und Dozenten auf. Jeder dieser Gruppen kann eine bestimmte 

Rolle zugewiesen werden, teilweise haben sie auch noch Attribute, die über 

die von Mensch hinausgehen. 

sopra

Seite 6 

2 DATENBANKAUFBAU 


3. Semester 


Ein Student ist immer Mitglied in einer Gruppe, dazu wird, sobald ein Student 

einem Tutorium beitritt, für ihn eine Gruppe angelegt, in der nur er 

Mitglied ist. Er ist gleichzeitig Administrator dieser Gruppe. Er kann weitere 

Studenten in seine Gruppe einladen, diese erhalten dann eine Mail mit 

einer Einladung. Wenn sie die Einladung annehmen, müssen sie ihre eigene 

Gruppe auflösen. Mitglieder von Gruppen können auch selbständig aus einer 

Gruppe wieder austreten, allerdings können sie keine Gruppen auflösen. In 

eine Gruppe können nicht mehr Mitglieder eingeladen werden, als die maximale 

Gruppengrösse für das Tutorium ist. 

Jeder Student einer Gruppe kann einem Tutorium eine Priorität zuordnen, 

die Gruppenpriorität für ein Tutorium ergibt sich dann zu dem Mittelwert 

aller Prioritäten. 

sopra


3. Semester 


Seite 7 

3 DIE KLASSENDIAGRAMME 

3 Die Klassendiagramme 

In diesem Abschnitt werden die Klassendiagramme erklärt. Wir haben vier 

verschiedene Bereiche identifiziert, die keine Abhängigkeiten zu einenander 

haben werden. Deswegen haben wir vier separate Klassendiagramme erzeugt. 

3.1 Servlets 

Da wir unsere Applikation als Java Servlets realisieren, müssen wir uns an die 

Servlet-API halten. Ein Servlet erbt von javax.servlet.http.HttpServlet 

und sollte dann mindestens eine der Methoden 

• doGet 

• doPost 

• doPut 

• doDelete 

• init, destroy 

• getServletInfo 

überschreiben. 

Da wir nicht zwischen den Verschiedenen Arten der HTTP Anfragen unterscheiden, 

haben wir erstmal eine Klasse definiert, die alle Methoden auf 

eine umleitet. Wir haben uns für doGet entschieden. Diese Methode ist dann 

von den einzelnen Seiten unseres Systems zu implementieren, wie auch aus 

Abb. 2 auf der nächsten Seite ersichtlich ist. 

Um diese Implementierung einigermaßen übersichtlich zu halten, definieren 

wir noch drei zusätzliche Pakete, die uns dann die Arbeit abnehmen werden: 

SuchServlet, UIList und UIElement. 

Mittels des PrintWriters können wir dann die Daten mit UIList und UI- 

Element zusammenschreiben lassen und schließlich von der doPost-Methode 

ausgeben lassen. 

Einige der Methoden, die unsere Servlets noch implementieren müssen, stehen 

auf dem Zustandsdiagramm des Dozenten. Hier sind dann auch immer die 

Return-Values (immer HttpSession) und einige Variablen entsprechend benannt. 

Eventuell werden wir die generate()-Methode in die doPost-Methode 

umverlagern, da dies eigentlich der sinnigere Ort ist. Die von den Servlets 

generierten Seiten werden dann mittels Buttons die nötigen Posts und Gets 

implementieren. 

sopra

Seite 8 


3.2 Datenbank 


3. Semester 


HttpServletResponse 

HttpServletRequest 

PrintWriter 

+ printLn(toprint : string) : void 

HttpServlet 

UIList 

SuchServlet 

UIElement 

OurServlet 

+ doGET() : void 

+ doPOST(request : HttpServletRequest, response : HttpServletResponse) : void 

ChangeOwnDataServlet 

+ doGET(request : HttpServletRequest, response : HttpServletResponse) : void 

ChangeSessionServlet 


ChoiceServlet 


ClassesListServlet 


LogoutServlet 


ModifyClassesServlet 


NewClassServlet 


AuthServlet 


LoginServlet 


3.2 Datenbank 

Abbildung 2: Klassendiagramm des Servlet Pakets 

Die Entwicklung dieses Paketes begann mit der Identifizierung der Tabellen, 

die in der Datenbank enthalten sein sollen. Auf alle Objekte (besser Entities), 

mit denen das System arbeitet, kann mit Hilfe dieser Schnittstelle zugegriffen 

werden. Ein UML-Diagramm dieses Packages findet sich in Abb. 3 auf der 

nächsten Seite 

Die Assoziationen, die wir hier identifiziert haben, wurden mit einzelnen 

Methoden bedacht, die dann die SQL Statements enthalten werden, um die 

Assoziationen auszuwerten. 

3.3 HTML Generierung 

Um etwas bequemer html zu erzeugen, haben wir ein Paket definiert, das 

uns dabei ein wenig unter die Arme greift. Hierbei sind die einzelnen Klassen 

so gestaltet, dass sie nacheinander in der Reihenfolge, wie sie auf der Seite 

erscheinen sollen, aufgerufen werden. Wir können uns damit also unsere Seite 

hübsch zusammenbauen und dann nachher an das Servlet, das uns mit 

Daten gefüttert hat, zurückgeben. Das UML-Diagramm ist in Abb. 4 auf der 

nächsten Seite zu sehen. 

sopra


3. Semester 


Seite 9 


3.3 HTML Generierung 

Gruppe 

+ groesse : int 

+ gruender : Mensch 

+ name 

1..* 

: String 

+ tutorium : Tutorium 

- id : int 

+ get_members() : list 

+ Gruppe(gruender : Student, name : string) : void 

1..* 

1..* 

Tutorium 

+ get_groups() : list 

1 

+ Tutorium() : Tutorium 

1..* 

1..* 

Veranstaltung 

+ dozent : Dozent 

+ name : String 

1..* 

+ veranstaltungsKennziffer 1 

: String 

- id : int 

+ get_tutorien() : list 

Student 

+ matrikelNummer : int 

1..* 

+ get_veranstaltungen() : list 

+ add_veranstaltung(veranstaltung : Veranstaltung) : void 

+ remove_veranstaltung(veranstaltung : Veranstaltung) : void 

+ get_gruppen() : list 

1..* 

DBObject 

# connection : DBConnection 

+ finalize() : void 

+ sync(conn : DBConnection) : void 

1 

Dozent 

+ get_veranstaltungen() : list 

1 

Tutor 

+ get_tutorien() : list 

Mensch 

+ Vorname : String 

+ e_mail : String 

+ name : String 

+ passwort : String 

+ user : String 

- id : int 

Abbildung 3: Klassendiagramm des Datenbank Pakets 

Alle Objekte sind von 

Printable abgeleitet, damit 

sie alle eine print() Methode 

haben, und auf die Klassen 

Attribute zugreifen koennen. 

Link 

+ Link(url : char *) 

+ print() : void 

Header 


PrintableForm 

- action : char * 

+ PrintableForm(action : char *, method : char *, : List < Printable >) 


Footer 


Printable 

# req : HttpServletRequest * 


+ setRequest(req : HttpServletRequest *) 

PrintableList 

- lst : List 

+ PrintableList( : List < Printable >) 

+ append(p : Printable *) : void 


TableRow 


Table 


FormField 

# name : char * 

# value : char * 

+ FormField(name : char *, value : char *) 

Dann gibt es noch eine PrintableList. 

Diese kommt in verschiedenen Arten 

vor, die sich nur durch Einfassung und 

Trennzeichen unterscheiden. 

InputField 

- type : char * 

+ InputField(name : char *, val : char *, type : char *) 


SelectorField 

- lst : List 

+ SelectorField(name : char *, val : char *, : List < char * >) 

+ append(choice : char *) : void 


SubmitField 

+ SubmitField(value : char *) 


Abbildung 4: Klassendiagramm des HTMLUI Pakets 

sopra

Seite 10 


3.4 Backend 


3. Semester 


3.4 Backend 

Abbildung 5: Das Backend des Anmeldesystems 

Dieses Klassendiagramm beschreibt die Klassen, welche die eigentliche Verteilung 

der Studenten auf die verschiedenen Tutorien vornimmt. Kern dieser 

Klassen bildet das Interface Evolvable, welches die Methoden mutate() und 

recombine() vorgibt. Dieses Interface wird von allen beteiligten Klassen implementiert. 

Aus der Klasse Generation wird dann das zentrale Objekt instanziert. Dieses 

Objekt spiegelt eine Generation unserer Population wieder. Eine neue 

Generation wird durch einen Konstruktor erschaffen, der eine vorhergehende 

Generation erwartet. Aus dieser vorhergehenden Generation wird nun die 

neue Generation durch Rekombination der enthaltenen Member erzeugt. Um 

dies zu ermöglichen, muss jede Generation mindestens 2 Member enthalten. 

Anschließend werden eine festgelegte Anzahl Member selektiert und in der 

Generation gespeichert. Zu guter Letzt werden die übrig gebliebenen Member 

noch mutiert. 

Die Klassen Member und E Veranstaltung funktionieren im Wesentlichen 

ähnlich, denn sie rekombinieren jeweils die in sich liegenden Objekte. 

Die Klasse E Tutorium führt nun die eigentlichen Operationen aus, indem es 

intern rekombiniert. 

Die beiden Klassen Tutorium und Veranstaltung entsprechen den gleichnamigen 

Objekten aus dem Frontend. Sie sind hier nur der Vollständigkeit halber 

aufgeführt, da E Tutorium und E Veranstaltung jeweils von ihnen erben. 

sopra


3. Semester 


Seite 11 

4 PSEUDO CODE 

4 Pseudo Code 

Um noch einmal mehr zu verdeutlichen, wie die definierten Klassen benutzt 

werden, geben wir hier ein Stück Pseudocode an, welches das nochmal verdeutlichen 

soll. 

/∗ 

∗ A u t h S e r v l e t .doGET( ) 

∗ 

5 ∗ Diese Methode wird aufgerufen , wenn der Benutzer seinen 

∗ Namen und das Passwort auf der L o g i n S e i t e eingegeben hat , 

∗ und den Einloggen Knopf g e d r u e c k t hat . 

∗/ 

10 void doGET( HttpServletRequest request , 

HttpServletResponse response ) { 

15 

// 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 

// 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 . 

P r i n t a b l e . setup ( response ) ; 

20 

// Holt d i e w i c h t i g e n parameter in l o k a l e Variablen 

S t r i n g user = r e q u e s t . getParam ( "user" ) ; 

S t r i n g password = r e q u e s t . getParam ( "password" ) ; 

25 // Sind d i e Parameter in Ordnung ? 

i f ( user == null | | password == null ) { 

// Wenn nicht , dann erzeuge eine Fehler S e i t e . 

30 P r i n t a b l e rp = new ErrorPage ( "Geben sie einen " ) ; 

// Und g i b s i e aus . 

rp . p r i n t ( ) ; 

35 return ; 

} 

sopra

Seite 12 

4 PSEUDO CODE 


3. Semester 


// Nun i n s t a n z i i e r e n wir einen Menschen , mit einem 

40 // der moeglichen Konstrukturen . 

Mensch m = new Mensch ( user ) ; 

45 // i s t das Passwort r i c h t i g ? 

i f ( md5( passwort ) ! = m. passwort ) { 

// Wenn nicht , dann Warnung ausgeben . 

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 ( ) ; 

rp . append ( new Header ( ) ) ; 

rp . append ( new P r i n t a b l e S t r i n g ( "Das Passwort war falsch" ) ) ; 

rp . append ( new Footer ( ) ) ; 

55 rp . p r i n t ( ) ; 

} 

return ; 

60 // J e t z t koennen wir davon ausgehen , das der Benutzer s i c h 

// h i e r anmelden d a r f . 

// 

// Wir erzeugen uns eine Session , und s e t z e n in Ihr 

// 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 

65 // h i e r u e b e r immer den Benutzer wieder f i n d e n . 

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 ( ) ; 

70 

75 

s e s s i o n . s e t ( "user" , m ) ; 

// Und nun geben wir d i e Willkommensseite aus : 

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 ( ) ; 

s e i t e . append ( new Header ( ) ) ; 

Table tab = new Table ( ) ; 

s e i t e . append ( tab ) ; 

TableRow row = new TableRow ( ) ; 

sopra


3. Semester 


Seite 13 

4 PSEUDO CODE 

80 tab . append ( row ) ; 

row . append ( new Link ( "Eigene Daten" ) ) ; 

row . append ( new Link ( "Veranstaltungen" ) ) ; 

85 // Und noch d i e w e iteren m o e g l i c h k e i t e n . 

s e i t e . append ( new Footer ( ) ) ; 

90 // Und nun noch ausgeben . 

s e i t e . p r i n t ( ) ; 

} 

sopra

Seite 14 

5 USE-CASE-DIAGRAMM 


3. Semester 


5 Use-Case-Diagramm 

Im Use-Case-Diagramm werden die Anwendungsfälle dargestellt. Es gibt vier 

Benutzergruppen, die hier berücksichtigt werden. Die Dozenten, die Studenten, 

die Tutoren und das Anmeldesystem. Der Akteur Anmeldesystem stellt 

hier nicht die gesamte Funktionalität des Systems dar, sondern nur die Anwendungen, 

die bei Anwendungen von anderen Akteuren für diese sichtbar 

werden. 

Eine kleine Veränderung im Vergleich zur Anforderungsdefinition ist hier, 

dass der Tutor sich selbst als Mensch dem System bekannt machen muss, bevor 

der Dozent ihn als Tutor auswählen kann. In der Anforderungsdefinition 

wurde der Tutor noch vom Dozenten angelegt. 

Es wird zunächst der Akteur Anmeldesystem näher betrachtet. Das Anmeldesystem 

hat nur zwei nach aussen sichtbare Anwendungsfälle. Dabei handelt 

es sich einerseits um das Überprüfen der Eingaben der anderen Akteure und 

deren Benachrichtigung durch das Anmeldesystem über die Ergebnisse der 

Anmeldung und andererseits die Endverteilung. Der Tutor kann nur einen 

Tutorennutzer anlegen. Dieser Anwendungsfall überschneidet sich mit dem 

Anlegen eines Studenten- oder Dozentennutzers, da der Tutor dem System 

bereits als Dozent oder Student bzw. als Mensch (siehe Klassendiagramm) 

bekannt sein muss. Als passiven Anwendungsfall enthält der Akteur Tutor 

das Benachrichtigtwerden durch das Anmeldesystem. 

Der Akteur Dozent besitzt fünf Anwendungsfälle. Der erste ist das Anlegen 

eines Dozentennutzer im System. Diesen Anwendungsfall können nur Personen 

starten, die im VV als Dozenten geführt sind. Der zweite Anwendungsfall 

des Dozenten ist das Anlegen einer Veranstaltung. Hierbei werden alle für die 

Klasse Veranstaltung notwendigen Informationen erfasst. Im dritten Anwendungsfall 

können diese Daten dann verändert werden. Der vierte und letzte 

aktive Anwendungsfall ist das Einpflegen von Sonderfällen und das manuelle 

Ändern der Ergebnislisten. Der fünfte Anwendungsfall ist wieder der passive 

Anwendungsfall, durch das Anmeldesystem benachrichtigt zu werden. 

Der Akteur Student besitzt drei aktive Anwendungsfälle und einen passiven 

Anwendungsfall. Wir nennen hier nur die aktiven Anwendungsfälle, da der 

passive wieder eine Benachrichtigung ist: 

Der erste ist das Anlegen eines Studentennutzers. Der zweite ist das 

Auswählen von Veranstaltungen und das Setzen oder Ändern der Prioritäten 

der einzelnen Termine. Der dritte ist das Erstellen von Arbeitsgruppen zu den 

einzelnen Veranstaltungen. 

Neben dem Use-Case-Diagramm mit der Gesamtansicht sind noch zwei weitere 

Use-Case-Diagramme dargestellt. Dies geschieht zur besseren Übersicht 

über die gesamten Anwendungsfälle. Beim ersten ist der Akteur Student aussopra


3. Semester 


Seite 15 


Abbildung 6: Use-Case-Diagramm des Anmeldesystems 

geblendet, damit man besser die Anwendungsfälle der anderen Akteure sehen 

kann. Beim zweiten ist dann dementsprechend nur der Akteur Student näher 

betrachtet worden. Die Anwendungsfälle sind dabei aber die selben wie im 

Gesamtdiagramm. 

sopra

Seite 16 



3. Semester 


Abbildung 7: Das Anmeldesystem aus der Dozentensicht 

Abbildung 8: Das Anmeldesystem aus der Studentensicht 

sopra


3. Semester 


Seite 17 

6 ABLAUF 

6 Ablauf 

6.1 Dozent 

Die Rolle des Dozenten wurde von uns schon in der Anforderungsdefinition 

erläutert und wird jetzt hier präzisiert. 

Die Hauptaufgaben des Dozenten sind: Neue Kurse anlegen und bestehende 

Kurse modifizieren. Weiterhin soll der Dozent noch Änderungen an seinen 

Daten nachpflegen können. 

Wir haben einen typischen Arbeitsablauf im Folgenden dargestellt: 

6.1.1 Aktivitätsdiagramm 

Das Aktivitätsdiagramm (Abb. 9 auf der nächsten Seite) erläutert, was der 

Dozent während einer Sitzung am System für Möglichkeiten hat. 

Eine typische Sitzung des Dozenten beginnt mit dem Login. Dies kann er 

so oft versuchen, bis er einmal Erfolg hatte (eventuell sollte hier noch eine 

Sperre eingebaut werden, die vor automatisierten Angriffen schützt). 

Nach einem erfolgreichen LogIn kommt der Dozent auf eine Auswahlseite, auf 

der er drei Möglichkeiten hat: Zum Einen kann er seine eigenen Daten ändern, 

zum Anderen kann er Kurse ändern oder neu eingeben und als Drittes kann 

er sich vom System wieder abmelden. 

Wenn er Daten ändert, dann wird vor dem Zurückschreiben in die Datenbank 

noch eine Konsistenzprüfung ausgeführt. Dies ist insbesondere für das 

Setzen des Passworts wichtig, damit nicht ausversehen das Passwort falsch 

eingegeben wurde. Um das Passwort zu ändern, muss es zwei Mal in Folge 

richtig eingegeben werden. 

Eventuell kann man auch die E-Mail-Adresse des Dozenten automatisch 

überprüfen und nur, wenn der angegebene Mail-Provider diese akzeptiert, 

eine Änderung zulassen. 

Bei der Änderung von Veranstaltungen soll der Dozent zwei Möglichkeiten 

haben: zum Einen soll er neue Veranstaltungen anlegen können und zum 

Anderen bestehende Veranstaltungen modifizieren können. Hierfür wird es 

dann jeweils eine eigene Seite geben. 

Nachdem er die Veranstaltung ausgewählt hat, an der er Änderungen vornehmen 

will (oder sie neu erstellt hat), wird er zu einer Seite weitergeleitet, 

auf der er entweder einzelne Termine ändern bzw. hinzufügen (wieder mit 

Konsistenzprüfung) oder zurück zur Auswahlseite gelangen kann. 

Dadurch, dass mehrere Termine am Stück geändert werden können, ohne 

dass der Dozent jedes mal die Auswahlseite neu besuchen muss, sollte sich 

eine bessere Benutzerfreundlichkeit ergeben. 

sopra

Seite 18 

6 ABLAUF 

6.1 Dozent 


3. Semester 


Abbildung 9: Aktivitätsdiagramm des Dozenten 

sopra


3. Semester 


Seite 19 

6 ABLAUF 

6.1 Dozent 

6.1.2 Zustandsdiagramm 

Das Zustandsdiagramm des Dozenten (Abb. 10 auf der nächsten Seite) zeigt 

jetzt die einzelnen Zustände für die von uns geforderten Klassen am Beispiel 

des Aktivitätsdiagramms des Dozenten auf. 

Hierbei erzeugt der Dozent in der AuthServlet-Klasse eine gültige HttpSession, 

mit deren Hilfe dann der weitere Ablauf modelliert wird. Diese Session 

wird von javax.servlet verwaltet, wir brauchen uns darum also keine Gedanken 

machen. Sie ist immer für eine Sitzung persistent und wir können 

an sie Attribute setzen. Wenn eine neue Seite aufgerufen wird, kann sie die 

Session von der vorherigen Seite sozusagen übernehmen. Dies geschieht entweder 

durch Cookies oder, falls der Browser keine Cookies unterstützt, durch 

URL-Codierung. Die Auth-Servlet-Klasse hängt die User-ID an die erzeugte 

HttpSession mit an. 

Nach erfolgreicher Authentifizierung erzeugt das Choice-Servlet die Auswahlseite 

und leitet dann je nach oben erläuterter Aktion (Eigene Daten ändern, 

Veranstaltungen ändern, Logout) weiter. 

Das ChangeOwnDataServlet dient zur Änderung der eigenen Daten. Es 

überprüft die Eingaben und hat als einzigen Ausgang wieder das Choice- 

Servlet. Es nutzt die vom AuthServlet generierte User-ID, um auf die Daten 

des Benutzers zuzugreifen. 

Im ClassesListServlet, das auch über das ChoiceServlet erreichbar ist, werden 

dann erst einmal alle Veranstaltungen dargestellt, die der Dozent hält. 

Jetzt kann der Dozent sich entscheiden, entweder eine Veranstaltung zu modifizieren 

(ModifyClassServlet) oder eine neue anzulegen (NewClassServlet). 

Beide Objekte hängen dann das Attribut “selectedClass“ an die HttpSession 

an. 

Mittels der ausgewählten Veranstaltung (“selectedClass’”), die ja in der Session 

gespeichert ist, generiert das ListClassServlet eine Terminliste der Veranstaltung. 

Hier hat der Dozent jetzt wieder die Möglichkeit, einzelne Termine 

zu ändern oder neue hinzuzufügen. Wenn er einen Termin ändern will, setzt 

das ListClassServlet das Attribut “session“ in der HttpSession. Es gibt auch 

die Möglichkeit, wieder zur Auswahlseite zurückzugehen. 

Das Attribut “session“, das vom ListClassServlet gesetzt wurde, wird jetzt 

vom ChangeSessionServlet ausgelesen. Innerhalb dieser Klasse kann der Veranstaltungstermin 

verändert werden, es wird auch eine Konsistenzprüfung 

der Daten durchgeführt. Wenn der Veranstaltungstermin erfolgreich geändert 

wurde, geht es zurück zum ListOfSessionsServlet. 

Das Logout-Servlet ist dann der Endzustand, dieser ist auch von der Seite, 

die durch das ChoiceServlet generiert wird, zu erreichen. Es sorgt dafür, dass 

die HttpSession vernichtet wird. 

sopra

Seite 20 

6 ABLAUF 

6.1 Dozent 


3. Semester 


Abbildung 10: Zustandsdiagramm für die Klassen, mit denen der Dozent 

interagiert 

sopra


3. Semester 


Seite 21 

6 ABLAUF 

6.1 Dozent 

6.1.3 Sequenzdiagramm 

Das hier gezeigte Sequenzdiagramm (Abb. 11 auf der nächsten Seite) zeigt 

die Kommunikationswege zwischen den einzelnen Objekten, die für die Dozentenaktivität 

des Änderns der Veranstaltungsliste nötig sind. 

Dabei kommuniziert der Browser des Dozenten mit den kurzlebigen Objekten 

der Servletklassen. Beim Ansurfen der Loginseite, fordert der Browser das 

LoginServlet-Objekt dazu auf, ihm die Seite zu schicken (ab jetzt wird zur 

Vereinfachung im Text nicht mehr immer erwähnt, dass es sich um ein Objekt 

handelt; sollte mal auf die Klasse zugegriffen werden, so wird dieses speziell 

hervorgehoben). Bevor das LoginServlet aber die Seite zurückliefert, erzeugt 

es noch eine Session. Nachdem die Loginseite an den Browser zurückgeliefert 

wurde, beendet sich das LoginServlet. Nun kann der Dozent seine Logindaten 

eintragen und auf den Button Login klicken. Diese Aktion veranlasst den 

Browser, das AuthServlet mit diesen Daten aufzurufen. Dieses fragt dann 

in der Datenbank nach, ob diese Eingaben korrekt sind. Sind sie korrekt, so 

sendet die Datenbank diese Daten erst an die Session weiter, in der die Daten 

zwischengespeichert werden und gibt dann dem AuthServlet seine Antwort. 

Dieses erstellt dann die Auswahlseite und liefert sie an den Browser zurück. 

Danach beendet sich das AuthServlet. Waren die Eingaben falsch, so erstellt 

das AuthServlet wieder die Loginseite und der Dozent kann die Daten noch 

einmal eingeben. 

In diesem Aktionsfall wählt der Dozent den Button Veranstaltungen modifizieren. 

Diese Aktion veranlasst den Browser, beim ClassesListServlet die 

Veranstaltungsliste des Dozenten zu erfragen. Das ClassesListServlet fragt 

also die Session nach diesen Daten und, da die Session bisher noch nicht 

über diese Daten verfügt, fragt sie schließlich die Datenbank nach diesen Daten. 

Von der Datenbank gehen die Daten an die Session, diese speichert sie 

erst einmal ab und reicht sie dann an das ClassesListServlet weiter, welches 

mittels dieser Daten die Veranstaltungsliste-Seite generiert und liefert sie an 

den Browser zurück. Danach beendet sich das ClassesListServlet. 

Nun ändert der Dozent die Daten seiner Veranstaltung und klickt dann auf 

den Button Änderungen speichern. Dieses veranlasst das ModifyClassesServlet 

dazu, die Daten entgegenzunehmen und an die Session weiterzureichen, in 

der die Daten dann gespeichert werden. Nachdem das ModifyClassesServlet 

das Okay der Session erhalten hat, ruft es das ClassesListServlet mit den neuen 

Daten auf und beendet sich. Das ClassesListServlet generiert - wie oben 

schon beschrieben - die Seite für den Browser, sendet sie an den Browser und 

beendet sich. Nach dem Ändern klickt der Dozent auf den entsprechenden 

Button, um zur Auswahlseite zurückzugelangen. Diese Aktion ruft das ChoiceServlet 

auf, welches die Auswahlseite erstellt und sie an den Browser liefert 

sopra

Seite 22 

6 ABLAUF 

6.1 Dozent 


3. Semester 


Abbildung 11: Das Sequenzdiagramm des Dozenten 

sopra


3. Semester 


Seite 23 

6 ABLAUF 

6.1 Dozent 

und sich dann beendet. 

Auf der Auswahlseite wählt der Dozent dann den Logout Button. Diese Aktion 

ruft das LogoutServlet auf. Dieses teilt der Session mit, dass sie sich 

beenden soll. Die Session übermittelt daher der Datenbank alle relevanten 

Daten zum Abspeichern. Bekommt die Session das Okay der Datenbank, so 

sagt die Session dem LogoutServlet, dass sie sich jetzt beenden wird und beendet 

sich. Das LogoutServlet generiert daraufhin die Logoutseite und liefert 

sie an den Browser. Danach beendet sich das LogoutServlet und der Dozent 

hat erfolgreich die Daten seiner Veranstaltung geändert. 

sopra

Seite 24 

6 ABLAUF 

6.2 Student 


3. Semester 


6.2 Student 

Wie in der Einleitung erwähnt, handelt es sich bei den Studenten im Grunde 

um die Hauptakteure des Übungsanmeldesystems, nicht aufgrund ihrer 

qualitativen Rechte (die sind eher geringfügig gegenüber beispielsweise den 

Dozenten), sondern vielmehr aufgrund ihrer quantitativen Überlegenheit und 

der Tatsache, dass dieses Übungsanmeldesystem hauptsächlich die Verteilung 

von Studenten auf Tutorien und Veranstaltungen regelt und nicht deren Ansetzung. 

6.2.1 Aktivitätsdiagramm 

Das Aktivitätsdiagramm für Studenten wurde zur bessern Lesbarkeit aufgeteilt: 

zusätzlich zu dem Hauptdiagramm (Abb. 12 auf der nächsten Seite) 

existieren Unterdiagramme zu den Aktivitäten Anmelden (Abb. 13 auf 

Seite 27), Account anlegen (Abb. 14 auf Seite 28), Einloggen (Abb. 15 auf 

Seite 29), Dateneingabe (Abb. 16 auf Seite 30), Gruppenwahl (Abb. 17 auf 

Seite 32) und Abschluss (Abb. 18 auf Seite 33). 

Desweiteren wurde auf die In-Diagramm-Kommentierung weitgehend verzichtet, 

da diese zwar geringfügige Zusatzinformationen bereitstellt, aber die 

Übersicht stark einschränkt. Ein Beispiel ist in Abschnitt 7.2 auf Seite 39 zu 

finden. Stattdessen liegen die entsprechenden Kommentare nun in Fließtext 

zur sinnvollen Begleitung der Diagramme vor. Es wird zuerst das Hauptdiagramm 

und dann jedes Subdiagramm für sich erläutert: 

Im Hauptdiagramm (Abb. 12 auf der nächsten Seite) findet sich der grobe 

Aktivitätsablauf eines jeden Studenten, der mit dem Übungsanmeldesystems 

interagiert: die erste Aktivität ist natürlich das Anmelden beim System. Da 

es sich hierbei um eine komplexe Handlung handelt, ist der genaue Aktivitätsablauf 

in dem Unteraktivitäts-Diagramm Anmelden (Abb. 13 auf Seite 27) 

dargestellt. 

Nach dem Anmelden stellt sich erstmal die Frage, wie das Anmelden abgelaufen 

ist: ist das Anmelden solange fehlgeschlagen, bis die Anmeldezeit (AZ) 

vorbei war, so wird die Aktivität direkt zur Endaktivität geführt und terminiert. 

In diesem Fall wird der Student nicht berücksichtigt im Übungsanmeldesystem, 

da er leider nicht in der Lage war, sich rechtzeitig anzumelden. Im 

Normalfall allerdings wird das Anmelden positiv verlaufen sein, so dass nun 

mit der Dateneingabe fortgefahren werden kann. 

Die Dateneingabe ist das Herzstück des Aktivitätsdiagramms des Studenten: 

auch hierfür liegt ein weiteres Unteraktivitätsdiagramm (Dateneingabe; 

Abb. 16 auf Seite 30) vor, es umfasst die gesamte Dateneingabe-Routine 

inklusive der nachträglichen Datenänderungsmöglichkeiten des Studenten. 

sopra


3. Semester 


Seite 25 

6 ABLAUF 

6.2 Student 

Abbildung 12: Aktivitätsdiagramm des Studenten - Hauptübersicht 

sopra

Seite 26 

6 ABLAUF 

6.2 Student 


3. Semester 


Während der Dateneingabe ist es natürlich durchgängig möglich, die Info- 

Dateien einzusehen, um sich Menüpunkte noch genauer erklären zu lassen 

oder - im Fall eines Studenten, dessen Muttersprache nicht deutsch ist - sich 

in den Info-Dateien die Übersetzungen und Erläuterungen auf englisch oder 

gar der eigenen Muttersprache anzeigen zu lassen (optionales Feature). 

Hat man die Dateneingabe und das Betrachten der Info-Dateien soweit abgeschlossen, 

ist man erstmal fertig. Solange die Anmeldezeit (AZ) noch läuft, 

besteht an dieser Stelle immer die Möglichkeit, dass man noch Informationen 

vom System zugeschickt bekommt, welche sowohl das Eliminieren einer Veranstaltung 

durch einen Dozenten, das Kreiren eines Tutorium durch selbige 

Personengruppe, die Feststellung der Voranalyse, dass ein Wunschtutorium 

des Studenten heillos überfüllt ist, oder ähnliche Ereignisse betreffen kann. 

Nun kann der Student wiederum entscheiden, ob er seine Daten ein weiteres 

Mal editieren soll, oder mit seinen Eingaben erstmal weiterhin zufrieden ist. 

Möchte er seine Eingaben ändern, so muss er sich erstmal ein weiteres Mal 

einloggen, was im Unteraktivitätsdiagramm Einloggen (Abb. 15 auf Seite 29) 

zusammengefasst ist. 

Möchte der Student zu dieser Zeit nichts ändern, so verbleibt ihm diese 

Möglichkeit trotzdem noch bis die Anmeldezeit abgelaufen ist. Ist dieses der 

Fall - also die Anmeldezeit abgelaufen -, lassen sich keine weiteren Änderungen 

mehr vornehmen und es beginnen die weitgehend passiven Abschluss- 

Aktivitäten des Studenten, die in dem Unteraktivitäts-Diagramm Abschluss 

(Abb. 18 auf Seite 33) zusammengefasst sind; hiernach terminiert die Aktivität 

des Studenten in Hinblick auf das Übungsanmeldesystem. 

Das Unteraktivitätsdiagramm Anmelden (Abb. 13 auf der nächsten Seite) 

stellt den ersten Schritt der Aktivität des Studenten in Hinblick auf das 

Übungsanmeldesystems dar: insofern ist der erste Schritt des Studenten 

natürlich das Aufsuchen eines Rechners. Ist dieses einmal geschafft, stellt 

sich die Frage, in welchem Zeitabschnitt wir gerade sind: hat die Anmeldezeit 

noch gar nicht begonnen, so bleibt dem Studenten nichts anders übrig, 

als auf den Anfang der Anmeldezeit zu warten; ist die Anmeldezeit hingegen 

bereits zu Ende, so kann der Student leider nicht mehr in das Übungsanmeldesystem 

dieses Semesters aufgenommen werden. Somit führt diese Bedingung 

zu einer Endaktivität, nämlich der zweiten Endaktivität dieses Unteraktivitätsdiagramms, 

welche im Hauptdiagramm direkt in die Endaktivität 

einmündet. In der Realität besteht natürlich auch hier noch die Möglichkeit 

bestimmter Härtefallregelungen und Absprachen mit Dozenten und Tutoren, 

das ist allerdings nicht mehr Teil dieses Systems und im Allgemeinen auch 

nicht praktikabel. 

Läuft hingegen die Anmeldezeit - und das ist der Normalfall bei der jahreszeitlichen 

Anfangsaktivität des Student -, so besteht natürlich die Möglichsopra


3. Semester 


Seite 27 

6 ABLAUF 

6.2 Student 

Abbildung 13: Aktivitätsdiagramm des Studenten - Unterdiagramm Anmelden 

sopra

Seite 28 

6 ABLAUF 

6.2 Student 


3. Semester 


keit, einen Account anzulegen: hierbei ist die erste Möglichkeit für den Studenten, 

sich einfach über seinen FB3-LogIn zu authentifizieren, dafür muss 

dieser angegeben werden und dann vom System bestätigt werden; klappt 

dieses, kann der User sich mit dem FB3-LogIn authentifizieren. Ist allerdings 

kein FB3-LogIn vorhanden oder möchte man diesen aus irgendeinem Grund 

nicht dafür verwenden, reicht es auch, wenn man sich im UNI-Netz befindet. 

Auch über einen Zugriff vom UNI-Netz kann man sich nämlich einen Account 

anlegen. 

Ist man allerdings auch nicht im UNI-Netz zugegen, so sollte man sich schnellstens 

dorthin begeben und dort wiederum einen Rechner aufsuchen, um noch 

rechtzeitig im Übungsanmeldesystem berücksichtigt zu werden und nicht versehentlich 

bis nach dem Ende der Übungsanmeldezeit warten, da dann - wie 

oben gesagt - nur noch persönliche Absprachen mit Dozenten und Tutoren 

möglich sind, was das ganze System eher verkompliziert. 

Hat nun mit der Authentifizierung alles funktioniert, kann man fortfahren, 

sich einen Account anzulegen. Das Anlegen des Accounts ist wiederum in 

einem Unteraktivitäts-Diagramm Account anlegen (Abb. 14) dargestellt: 

Abbildung 14: Aktivitätsdiagramm des Studenten - Unterdiagramm Account 

Anlegen 

Das Unteraktivitätsdiagramm für die Anlage eines Accounts beginnt sinnigerweise 

mit der Eingabe des Benutzernamens. Dann wird geprüft, ob der 

gewünschte Username in dieser Form zulässig ist, das heisst, ob er erstens 

sopra


3. Semester 


Seite 29 

6 ABLAUF 

6.2 Student 

ausschließlich aus gültigen Zeichen besteht und zweitens noch nicht vergeben 

ist. Unter Umständen muss der neue User sich einen anderen UserName 

suchen! 

Nun muss ein Passwort gewählt werden, welches zur Bestätigung noch ein 

zweites Mal eingegeben werden muss, um Tippfehler zu vermeiden. Im Anschluss 

findet eine Konsistenzprüfung statt, ob die beiden Eingaben identisch 

sind, ist dieses nicht der Fall, muss die Passwort-Eingabe wiederum wiederholt 

werden. Im Erfolgsfall hingegen hat man sich erfolgreich einen Account 

angelegt. 

Abbildung 15: Aktivitätsdiagramm des Studenten - Unterdiagramm Einloggen 

Das Einloggen (Abb. 15) steht natürlich im engen Zusammenhang mit der 

Accountanlegung. Wie man leicht im Unteraktivitätsdiagramm sehen kann, 

muss hier erst der Username eingegeben werden und dann das zugehörige 

Passwort, hiernach gibt es wiederum eine Konsistenzprüfung: passt das 

eingebene Passwort nicht zum entsprechenden UserName oder existiert der 

Username schlichtweg überhaupt nicht, so muss der Einlog-Vorgang wiederholt 

werden. Im Erfolgsfall jedoch wird man direkt zur Voranalyse weitergeleitet, 

die einem einen kurzen, aber hoch-informativen, Überblick über die 

bisherige Verteilung der Tutoriumsplätze gibt und einem so die Möglichkeit 

gibt, selber an der Verbesserung des eigenen Studienplanes mitzuhelfen. 

Das Unteraktivitätsdiagramm für die Dateneingabe (Abb. 16 auf der 

nächsten Seite) beginnt direkt mit der Abfrage, ob die Liste der bisher vom 

User gewählten Veranstaltung (VerList) leer ist. Ist dieses der Fall, wird 

sopra

Seite 30 

6 ABLAUF 

6.2 Student 


3. Semester 


Abbildung 16: Aktivitätsdiagramm des Studenten - Unterdiagramm Dateneingabe 

sopra


3. Semester 


Seite 31 

6 ABLAUF 

6.2 Student 

der User direkt aufgefordert, eine erste Veranstaltung aus dem Veranstaltungsverzeichnis 

(VV) auszuwählen und seiner VerList hinzuzufügen (die 

weitere Verfahrensweise hierzu wird weiter unten bei Verzeichnis hinzufügen 

erläutert). Ansonsten (bei nicht leerer VerList) kommt der Student in ein 

Menü, in dem er eine Liste der bereits von ihm ausgewählten Veranstaltungen 

vor Augen und die Möglichkeit hat, aus folgenden Handlungen zu wählen: 

eine Veranstaltung löschen, eine Veranstaltung ändern, eine Veranstaltung 

aus dem VV hinzufügen oder Speichern & Ausloggen. 

Bei der Option Veranstaltung löschen wird die gerade gewählte Veranstaltung 

aus der VerList gelöscht, danach wird die Dateneingabe initial neu gestartet, 

d.h. es wird an der Stelle fortgefahren, wo die Prüfung stattfindet, ob 

die VerList leer ist. Wählt man die Option Veranstaltung ändern, so muss 

man als nächstes zu der gewählten Veranstaltung die Prioritäten auf die 

Tutorien verteilen, wobei die neuen Werte mit den bisherigen Werten vorinitialisiert 

sind und entsprechend auch so angezeigt werden, hierauf folgt 

eine Konsistenzprüfung, ob die Eingaben korrekt waren (entsprechend dem 

Schlüssel, dass jede Priorität (abgesehen von der 10) nur höchstens einmal 

vorkommt). Ist dies nicht der Fall, müssen die Prioritäten nochmals verteilt 

werden. Ist die Prioritätenverteilung formal korrekt, kann der Student nun 

mit der Gruppenverwaltung für die entsprechende Veranstaltung fortfahren, 

welche im Unteraktivitätsdiagramm Gruppenwahl (Abb. 17 auf der nächsten 

Seite) dargestellt ist. Auch hierauf folgt eine Konsistenzprüfung, welche bei 

Nichterfolg zurück und bei Erfolg wieder an den Anfang zur Prüfung auf 

leere Verzeichnis-Liste zurückkehrt. 

Als dritte Möglichkeit bietet sich das Hinzufügen einer weiteren Veranstaltung, 

dieses ist über ein Veranstaltungs-Verzeichnis gelöst, bei dem 

leicht über CheckBoxen die gewünschten Veranstaltungen ausgewählt werden 

können. Hierbei ist keine Konsistenzprüfung vonnöten, da hier nichts 

schief gehen kann. Danach hat man die Möglichkeit, entweder wieder ins 

Menü zurückzukehren oder gleich die Prioritäten und die Gruppenwerte zu 

setzen, was gleichbedeutend mit dem Menüpunkt Veranstaltung ändern ist. 

Schließlich verbleibt noch die Möglichkeit, den Menüpunkt ”Speichern & 

Ausloggen” zu wählen; dieser versendet den Datensatz, durch dessen Empfang 

automatisch eine Empfangs-Bestätigung als Email an den Studenten 

verschickt wird. Erst nach dem bestätigten Empfang des Datensatzes, wird 

der User ausgeloggt. 

Beim Unteraktivitätsdiagramm Gruppenwahl (Abb. 17 auf der nächsten Seite) 

spalten sich die Möglichkeiten in zwei Arten: einerseits die Optionen, die 

davon abhängen, ob man eine eigene (Einzel-)Gruppe hat oder Teil einer 

Gruppe ist und andererseits die Funktionen, die hiervon unabhängig sind. 

Im ersten Bereich sind die Optionen User in die Gruppe einladen, Einladung 

sopra

Seite 32 

6 ABLAUF 

6.2 Student 


3. Semester 


Abbildung 17: Aktivitätsdiagramm des Studenten - Unterdiagramm Gruppenwahl 

sopra


3. Semester 


Seite 33 

6 ABLAUF 

6.2 Student 

zurückziehen und Gruppenverwaltung beeden. Im zweiten Bereich befinden 

sich Gruppe beitreten und Gruppe verlassen. 

Einen weiteren User einladen kann man nur dann, wenn die Gruppe noch 

nicht voll ist (bzw. solange noch weniger Einladungen vorhanden sind als 

die Gruppe groß sein darf). In diesem Fall muss man dann den gewünschten 

User auswählen, der dann eine Einladung zugeschickt bekommt. Hiernach 

wird man automatisch wieder ins Menü zurückgeleitet. 

Eine Einladung zurückziehen kann man nur dann, wenn noch eine offene 

Einladung existiert, d.h. eine ausgesprochene Einladung, die noch nicht angenommen 

wurde. Hierzu muss man wiederum einen User auswählen, dieser 

wird natürlich darüber informiert, dass die Einladung zurückgezogen wurde. 

Danach kommt man automatisch wieder ins Menü. Es ist natürlich immer 

möglich, die Gruppenverwaltung zu beenden. 

Möchte man einer Gruppe beitreten, so darf man noch keiner Gruppe (ausser 

der eigenen Einzelgruppe) in dieser Veranstaltung angehören und muss außerdem 

natürlich eine Einladung einer anderen Gruppe haben. Nimmt man 

die Einladung an, so tritt man dieser Gruppe bei und kehrt ins Menü zurück. 

Um wiederum eine Gruppe zu verlassen, muss man natürlich Mitglied einer 

echten Gruppe sein. Einzelgruppen können natürlich auch nicht verlassen 

werden. Auch hiernach kehrt man ins Menü zurück. 

Das Abschluss-Unteraktivitätsdiagramm (Abb. 18) schließt schließlich das 

Aktivitätsdiagramm das Studenten ab. Dabei beginnt der Abschluss mit dem 

Versand der Ergebnis-E-Mail, die nach der Berechnung und Abnahme des 

Plans durch den Admin automatisch erstellt wird. Nun kann der Student, 

wenn ihn etwas an seinem Plan stört oder ihm gar als nicht erfüllbar erscheint 

und er sich somit für einen Härtefall hält, direkt noch Absprachen 

mit dem Dozenten treffen, den er dann von der Notwendigkeit seiner Anliegen 

überzeugen muss. 

Schließlich muss der Student noch entscheiden, ob er einen automatisch erstellten 

Stundenplan (ASP) haben möchte. Dieser ähnelt der Stundenplan- 

Version, die zur Zeit vom Online-Veranstaltungs-Verzeichnis angeboten wird, 

nur mit dem Unterschied, dass wirklich nur die eigenen Tutorien und nicht 

auch alle anderen Tutorien des entsprechenden Kurses angezeigt werden. 

Fordert der Student den ASP an, so erhält er ihn natürlich auch, auf jeden 

Fall ist die Aktivität des Studenten in Bezug auf das Übungsanmeldesystem 

somit beendet. 

sopra

Seite 34 

6 ABLAUF 

6.2 Student 


3. Semester 


Abbildung 18: Aktivitätsdiagramm des Studenten - Unterdiagramm Abschluss 

6.2.2 Zustandsdiagramm 

Es folgt nun die Beschreibung des Zustandsdiagramms für Studenten 

(Abb. 19 auf der nächsten Seite: 

Die typische Handlung eines Studenten ist die Dateneingabe. Dabei stellt 

sich als erstes die Frage, ob ein Account - in diesem Fall ist mit Account der 

temporäre Account gemeint, der die Eingabedaten entegegen nimmt vom 

User und sie zwischenspeichert, bis sie versendet werden; nicht gemeint ist 

der Account des jeweiligen Studenten in der Datenbank - vorhanden ist. 

Ist dieses nicht der Fall, landet man natürlich im Zustand kein Account, bei 

diesem ist die Funktion entry/ ausführbar und man kann einen Account anlegen. 

Hierdurch werden die Variablen vorinitialisiert (die String-Variablen 

UserName und Password durch User Input, die anderen (List of String Ver- 

List, List of List of Int prior, List of List of Student gruppe etc.) durch die 

bisherigen Werte des entsprechenden Users). Somit erreicht man nun den 

Zustand Account angelegt. 

Aus diesem kommt man nun leicht in den Zustand Account vorhanden. Von 

diesem aus geht es nun genauso weiter, als wäre bei der ersten Abfrage der 

Account bereits vorhanden gewesen. Als Erstes wird geprüft, ob die Liste 

sopra


3. Semester 


Seite 35 

6 ABLAUF 

6.2 Student 

Abbildung 19: Das Zustandsdiagramm für Studenten 

sopra

Seite 36 

6 ABLAUF 

6.2 Student 


3. Semester 


der vom User bereits gewählten Veranstaltungen VerList leer ist. Ist dieses 

der Fall, kommt man in den Zustand Account leer, ansonsten in den Zustand 

Account nicht leer. 

In beiden Fällen wird nun entweder (auf verschiedene Art und Weise: 

bei leerem Account wird die VerList() auf jeden Fall geändert(aufgefüllt); 

bei nicht-leerem Account stehen dem User alle Menü-Optionen offen) der 

Account geändert und dann über den Zustand Account geändert zu der 

Frage zurückgekehrt, ob die VerList leer ist oder ganz einfach die Daten 

übermittelt. Werden die Daten übermittelt, so gelangt man in den Zustand 

Daten übermittelt und es wird nun der Destruktor für den Account aufrufen 

und somit landen wir im Endzustand. 

6.2.3 Sequenzdiagramm 

Das Sequenzdiagramm der Studenten (Abb. 20 auf der nächsten Seite) entspricht 

im Wesentlichen dem Sequenzdiagramm des Dozenten. Da die Unterschiede 

bei der Datenmodifikation nicht im Sequenzdiagramm auffallen und 

auch das Einloggen und Ausloggen identisch sind, sind die beiden Diagramm 

inhaltsgleich. 

sopra


3. Semester 


Seite 37 

6 ABLAUF 

6.2 Student 

Abbildung 20: Das Sequenzdiagramm der Studenten 

sopra

Seite 38 

7 ANHANG 


3. Semester 


7 Anhang 

7.1 Glossar 

Aktivitätsdiagramm Quelle: [?] 

Klassendiagramm Quelle: [?] 

Sequenzdiagramm Quelle: [?] 

Ein Aktivitätsdiagramm dient zur Darstellung eines Systemablaufes in 

der Informatik. Mit einem solchen Diagramm wird häufig ein Use-Case 

(Geschäftsvorfall, Anwendungsfall) verfeinert. 

In der Regel besitzt ein Aktivitätendiagramm einen wohl definierten 

Start- und Endpunkt. Dazwischen können Aktivitäten, Entscheidungen, 

Zustände (States) modelliert werden. 

Das Aktivitätendiagramm ist eine objektorientierte Adapation des 

Fluss-Diagramms 

Klassendiagramme beschreiben in der Informatik Objekt-Klassen durch 

Angaben der Operationen (Methoden/Funktionen), Zustände (Attribute) 

und, Beziehungen (Assoziationen / Relationen) zwischen den Klassen. 

In der UML, einer generellen Beschreibungssprache der Informatik, beschreibt 

das Sequenz-Diagramm einzelne, Abläufe in ihrer exakten Reihenfolge. 

Im Gegensatz dazu muss bei einem Kollaborations-Diagramm 

nicht der genaue Zeitpunkt feststehen. 

Ein Sequenz-Diagramm stellt in der Regel einen Weg durch einen Entscheidungsbaum 

innerhalb eines Systemablaufes dar. 

Use-Case-Diagramm auch: Anwendungsfalldiagramm 

Quelle: [?] 

Anwendungsfälle beschreiben das gewünschte Systemverhalten aus der 

Sicht der Anwender. Es wird aufgezeigt, WAS möglich sein muss, 

aber nicht WIE. In einem Anwendungsfalldiagramm werden die Anwendungsfälle 

und die Akteure (Personen, Systeme) zusammengestellt. 

Die Beziehungen untereinander werden durch Pfeile (mit Beschriftung 

und ) ausgedrückt. 

Neben den Entitäten Anwender(gruppen) und Anwendungsfälle existiert 

noch die Systemgrenze (Swim-Lane). Hiermit werden verschiedene 

Systeme und/oder Verantwortlichkeiten voneinander getrennt. 

sopra

Seite 39 


7 ANHANG 

7.2 3. Semester kommentierte Diagramme (als Beispiel: Teile des Aktivitätsdiagramms 


Studenten) 

Zustandsdiagramm Quelle: [?] 

Nicht selten wird ein Anwendungsfall mit einem Aktivitätsdiagramm 

(Activity) verfeinert. 

Ein Zustands-Diagramm in der UML ist eine Darstellungsform in der 

Informatik. Es visualisiert die verschiedenen Zustände (z.B. Änderung 

von Attributwerten) einer Instanz (d.h. eines Objektes) einer Klasse. 

7.2 kommentierte Diagramme (als Beispiel: Teile des 

Aktivitätsdiagramms Studenten) 

Abbildung 21: das kommentierte Hauptteil des Aktivitätsdiagramms für Studenten 

7.3 Literatur 

sopra

Seite 40 

7 ANHANG 

7.3 Literatur 


3. Semester 


Abbildung 22: das kommentierte Unteraktivitätsdiagramm Anmelden für 

Studenten 

sopra

Universität Bremen Fachbereich 3 Studiengang Informatik Karl ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?