Ausarbeitung - Universität Paderborn

Transcription

Diplomarbeit
Eine visuelle Sprache zur
Konfiguration der Datenverwaltung
von Lehrveranstaltungen
vorgelegt bei
Herrn Prof. Dr. Uwe Kastens
Jana Schäfer
Fakultät für Elektrotechnik, Informatik und Mathematik
der Universität Paderborn
Paderborn, April 2006
Danksagung
An dieser Stelle möchte ich allen danken, die mich bei der Erstellung dieser Arbeit
unterstützt haben. Mein erster Dank geht an Prof. Dr. Uwe Kastens, der diese Diplomarbeit ermöglicht und durch wertvolle Hinweise zum Gelingen dieser Arbeit beigetragen
hat. Herrn Dr. Carsten Schmidt möchte ich meinen besonderen Dank aussprechen, weil
er mich in jeder Phase der Arbeit sehr sachkundig und richtungsweisend begleitete und
viel Geduld zeigte. Ich bedanke mich bei all denen, die meine Diplomarbeit durch Korrekturlesen verbessert haben.
Mein besonderer Dank gilt meiner Familie für Verständnis und Aufmunterung zu jeder Zeit.
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung
2
2 Grundlagen
2.1 Aspektorientierte Programmierung . . . . . . . . . . . . . . . . . . . . .
2.2 Visuelle Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Klassifikation des Gebiets der visuellen Programmierung . . . . . . . . .
2.4 DEViL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Das StudInfo{flex}-System . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 StudInfo{flex} aus Benutzersicht . . . . . . . . . . . . . . . . . .
2.5.2 Konfiguration und Benutzung von StudInfo{flex}-Veranstaltungen
4
4
6
7
9
17
17
18
3 Sprachentwurf
3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . .
3.2 Überblick über die Sprache . . . . . . . . . . . . . . . . .
3.3 Grundsätzliche Entwurfsüberlegungen . . . . . . . . . . .
3.4 Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Konfiguration der Weboberfläche im Studierendenmodul
3.6 Datenerfassung . . . . . . . . . . . . . . . . . . . . . . .
3.7 Permissions . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 Abfragen . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Tabellenmodellierung . . . . . . . . . . . . . . . . . . . .
3.11 Tutoren-Logins . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
28
28
29
30
31
34
37
39
42
44
45
47
.
.
.
.
49
49
51
51
52
.
.
.
.
.
.
.
.
.
.
.
4 Realisierung
4.1 Konfigurationsprozess einer StudInfo{flex}- Veranstaltung
4.2 Generierung von Datenbankschlüsseln . . . . . . . . . . . .
4.3 Aktualisierbarkeit einer laufenden Veranstaltung . . . . . .
4.4 Konsistenzprüfungen . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Evaluation
55
5.1 Grundlagen der Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Umsetzung der Standardveranstaltung . . . . . . . . . . . . . . . . . . . 56
5.3 Kontrolliertes Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Zusammenfassung
61
1
1 Einleitung
1 Einleitung
Universitätsveranstaltungen mit vielen Teilnehmern erfordern einen großen Verwaltungsaufwand. Studierende müssen gleichmäßig auf Übungsgruppen verteilt werden, Korrektoren von Hausaufgaben müssen Listen mit erreichten Punkten abliefern und Klausuren
müssen geplant und durchgeführt werden. Dadurch entstehen wachsende Anforderungen
an effiziente Datenhaltung und -verarbeitung. StudInfo{flex} [4] ist ein System, welches
den Beteiligten ermöglicht, die Teilnehmerdaten von Lehrveranstaltungen an der Universität Paderborn prozessbegleitend und unter Berücksichtigung des Datenschutzes zu
verwalten. Es stellt eine Web-Schnittstelle zur Verfügung, mit der Studierende, Veranstalter und Tutoren die jeweils für sie wichtigen Daten einer Veranstaltung einsehen und
ändern können. Das zugrundeliegende Datenbankschema sorgt für hinreichende Flexibilität in Bezug auf individuelle Anforderungen unterschiedlicher Lehrveranstaltungen.
Entsprechende Einstellungen werden dort in so genannten Konfigurationstabellen gespeichert.
Standardmäßig ist das StudInfo{flex}-System auf Veranstaltungen mit vielen Teilnehmern ausgelegt. Für solche Veranstaltungen werden Übungen und am Ende des Semesters schriftliche Klausuren angeboten. Einfache Änderungen, wie der Name der Veranstaltung oder des Professors, lassen sich ganz einfach durchführen. Andere Erweiterungen
oder Änderungen, wie zum Beispiel eine Veranstaltung mit einer mündlichen Prüfung
anstelle von Klausuren, können ohne SQL- und Datenbankkenntnisse nicht umgesetzt
werden. Die in der Datenbank in Tabellen gespeicherte Konfiguration ist in bestehender Form nicht intuitiv verständlich und die daraus resultierenden Konfigurationsfehler
werden erst zur Laufzeit erkannt.
Seit Ende der 70er Jahre wird intensiv nach Möglichkeiten gesucht, Programme verständlicher sowie die Programmierung leichter und damit für Anwender zugänglicher zu machen. Es ist bekannt, dass dem Menschen komplexe Zusammenhänge und Abläufe häufig
besser über anschauliche visuelle Elemente als über eine abstrakte Beschreibung vermittelt werden können. So kann die Erstellung eines Programms durch das Zusammensetzen
verschiedener visueller Elemente erfolgen.
In dieser Diplomarbeit soll eine visuelle Sprache zur Konfiguration des StudInfo{flex}Systems entwickelt werden, die die Konfiguration einer Veranstaltung einfacher und
intuitiver macht. Ein wichtiges Entwurfsziel der Sprache ist die Unterstützung aspektorientierter Spezifikation. Dabei wird die StudInfo{flex}-Konfiguration nach bestimmten
Kriterien in verschiedene Teilfunktionalitäten (Aspekte) zerlegt. Diese Aspekte können
bei jeder neuen Veranstaltung von den Administratoren beliebig zusammengesetzt, neu
angelegt und entsprechend angepasst werden. Es soll ebenfalls möglich sein, eine Teil-
2
1 Einleitung
konfiguration, zum Beispiel für die Übungsverwaltung, von einer Konfiguration in eine
andere zu übernehmen.
Die Implementierung der visuellen Sprache wird mit Hilfe des DEViL-Systems entwickelt. Mit dieser visuellen Sprache können Benutzer neue StudInfo{flex}-Veranstaltungen
konfigurieren, ohne direkt mit der Datenbank interagieren zu müssen.
Diese Diplomarbeit ist in sechs Kapitel unterteilt. Nach der Einführung in diesem Kapitel werden im zweiten Kapitel theoretische und technische Grundlagen für alle weiteren
Überlegungen vorgestellt. Im dritten Kapitel wird die zu implementierende visuelle Sprache entworfen und detailliert beschrieben. Im vierten Kapitel wird auf Realisierungsaspekte der implementierten visuellen Sprache eingegangen. Das fünfte Kapitel beschreibt die Evaluation anhand der Anwendbarkeit des vorher vorgenommenen Entwurfes und die Nutzbarkeit der konkreten Implementierung. Abschließend beinhaltet
das sechste Kapitel eine Zusammenfassung der Erkenntnisse.
3
2 Grundlagen
2 Grundlagen
In diesem Kapitel werden Grundlagen der aspektorientierten und visuellen Programmierung erläutert. Im Falle der aspektorientierten Programmierung wird insbesondere die
Bildung von Aspekten verdeutlicht. Bei der visuellen Programmierung werden die wichtigsten Begriffe erklärt um nachfolgende Überlegungen verständlicher zu machen. Die
darauf folgende Klassifikation zeigt die Einteilung visueller Programmierung in verschiedene Bereiche. Die abschließenden Abschnitte dieses Kapitels beschreiben Grundlegendes
zum Generator DEViL [1] und das StudInfo{flex}-System. Dabei werden die einzelnen
Ebenen des StudInfo{flex}-Systems genau untersucht.
2.1 Aspektorientierte Programmierung
Seit dem es Programmiersprachen gibt, werden immer wieder neue Ansätze zur Verbesserung entwickelt, angefangen bei der Programmierung in Assembler über prozedurales
und funktionales Programmieren, bis hin zu objektorientierten Sprachen. Zweck der
Weiterentwicklung jeder einzelner Sprache war es, den Entwicklern die Arbeit zu erleichtern und somit höhere Effizienz bei der Softwareentwicklung zu erzielen. Eines der
zugrunde liegenden Prinzipien, welches bei allen neuen Programmierkonzepten angewendet wird, ist die Kapselung von Funktionalität [7].
Bei der Umsetzung komplexer technischer Aufgaben geht man häufig nach dem Prinzip
devide et impera“ vor, was bedeutet: teile eine Aufgabe in kleine, überschaubare Kom”
ponenten auf und betrachte jede Komponente für sich. Damit wird die Komplexität in
einer Komponente reduziert und die Aufgabe leichter lösbar [6]. Das kann auf verschiedene Arten geschehen, beispielsweise prozedural oder objektorientiert [7]:
• Prozedurale Programmierung erlaubt die Strukturierung vom Code nur in einer
Dimension: Die Zerlegungen in Unterprogramme ermöglichen eine geringe Strukturierung.
• Objektorientierte Programmierung (OOP) erweitert die prozedurale Programmierung um Objekte. OOP erlaubt die Kapselung konzeptionell zusammengehöriger
Funktionen und Variablen in unabhängigen Modulen (Objekten) mit klar definierten Schnittstellen. Ziel ist eine stärkere Strukturierung und eine höhere Wiederverwendbarkeit einzelner Module.
Die Art der Zerlegung einer Aufgabe mit objektorientierter Programmierung ist für viele
Aufgabenstellungen gut geeignet, weil man viele Probleme gut und natürlich mit Hilfe
von Objekten ausdrücken kann. Manchmal gibt es jedoch Probleme: die Aufgabenteile
4
2 Grundlagen
schneiden gewissermaßen mitten durch das Objektmodell und lassen sich nicht ordentlich
herausfaktorisieren. In solchen Fällen kann das Problem mit Hilfe von aspektorientierter
Programmierung, die OOP um eine Dimension, nämlich die Aspekte, erweitert, gelöst
werden. Aspektorientierte Programmierung ist wie folgt definiert:
Aspektorientierte Programmierung ist ein Programmierparadigma, um räumlich getrennte Programmbestandteile (zum Beispiel Funktionen) von zentraler Stelle mit bestimmten Eigenschaften (zum Beispiel die Protokollierung
von Aufrufen) auszustatten. Dazu werden so genannte Aspekte definiert.
Aspektorientierte Programmierung basiert hinsichtlich Entwurf und Implementierung
auf Konzepten, die den oft hochgradig verschachtelten Code entzerren und die CodeTeile, die viele Klassen gemeinsam haben, in eigene Klassen auslagert. Dies ermöglicht
eine hohe Modularität des Codes und vermeidet insbesondere doppelten Code [9]. Die
Aspekte kapseln Eigenschaften und Anforderungen eines Softwaresystems, die das System an mehreren Stellen beeinflussen und somit durchdringen. Ein Aspekt sollte einen
möglichst kompakten, starken Zusammenhalt aufweisen und gleichzeitig möglichst wenig mit anderen Aspekten zu tun haben [6]. Aspektorientierte Programmierung ist keine
definierte Methode, die aus einer klar definierten Semantik einen minimalen Satz von
Softwareartefakten herleitet, welche dann die Programmiersprachen umsetzen. Aspektorientierte Programmierung besitzt keine vorgegebene Sprachstruktur. Stattdessen werden die Eigenschaften eines Softwaresystems in Anliegen oder Merkmalen modelliert [5].
Die Aspektbildung spielt bei der Entwicklung von Softwaresystemen eine zentrale Rolle. Man spricht auch von der Trennung der Verantwortlichkeiten ( Separation of Con”
cerns“). Mit der Bildung von Aspekten soll durch aspektorientierte Programmierung die
Komplexität von Software besser bewältigt und die Wiederverwendung von Komponenten verbessert werden [5].
Das Konzept der aspektorientierten Programmierung soll beim Entwurf der visuellen
Sprache für das StudInfo{flex}-System verwendet werden. Eine StudInfo{flex}-Konfiguration wird in einzelne unabhängig funktionierende Aspekte, zum Beispiel Studenten und Übungsverwaltung, aufgeteilt. Falls bei der Konfiguration einer neuen StudInfo{flex}-Veranstaltung Aspekte gebraucht werden, die schon in einer früheren StudInfo{flex}-Veranstaltung angelegt wurden, können diese einfach in die neue Konfiguration übernommen werden. Dies ermöglicht die Wiederverwendung von einzelnen Aspekten und erleichtert die Erstellung neuer StudInfo{flex}-Konfigurationen.
5
2 Grundlagen
2.2 Visuelle Programmierung
In diesem Abschnitt werden Definitionen aus der Literatur zu zentralen Begriffen der
visuellen Programmierung erklärt.
Der Begriff visuell“
”
Der Begriff visuell“ bedeutet im Allgemeinen das Sehen“ oder den Gesichtssinn be”
”
”
treffend“ und bezeichnet somit eine bestimmte Wahrnehmungsart. Diese Wahrnehmung
bezieht sich nicht nur auf graphische Elemente, sondern auch auf sichtbaren Text, wie
etwa ein Piktogramm. Ein Beispiel dafür ist das visuelle Gedicht Schweigen“ (Abbil”
dung 1) von Eugen Gomringer [2], welches die visuelle Dichtung darstellt:
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
schweigen
Abbildung 1: Schweigen“
”
Der Begriff visuelle Sprache“
”
Chang [2] schreibt, dass der Begriff visuelle Sprache“ unterschiedlich verstanden wird:
”
Der Begriff visuelle Sprache hat für verschiedene Personen unterschiedliche
Bedeutung. Einige verstehen darunter, dass die Sprache visuelle Objekte erfasst. Andere verstehen darunter, dass die Sprache selbst visuell ist. Für die
erste Gruppe heißt visuelle Sprache“ eine Sprache für die Verarbeitung vi”
sueller Informationen. Für die zweite Gruppe heißt visuelle Sprache“ eine
”
Sprache für die Programmierung mit visuellen Ausdrücken bzw. eine visuelle
Programmiersprache.
Die Sprachen für die Verarbeitung visueller Informationen beruhen auf verbaler Syntax,
was bedeutet, dass diese Sprachen textuelle Sprachen sind. Der Name visuelle Sprache“
”
ist in diesem Zusammenhang irreführend, denn eine Sprache ist nur dann visuell“, wenn
”
sie visuelle Sprachelemente enthält.
6
2 Grundlagen
Der Begriff visuelle Programmierung“
”
Eine eindeutige Definition für visuelle Programmierung ist in der Literatur schwer zu
finden. Burnet und McIntyre [2] erklären die visuelle Programmierung folgendermaßen:
Bei visueller Programmierung verwendet man visuelle Ausdrücke, wie Diagramme, Freihandskizzen, Piktogramme oder sogar graphische Manipulationen. Wenn die Syntax einer Programmiersprache solche Ausdrücke enthält,
dann wird sie eine visuelle Programmiersprache genannt.
Visuelle Programmierung unterstützt also die Softwareentwicklung, um sie intuitiver
und einfacher zu machen. Das Ziel visueller Programmierung ist die Steigerung der
Verständlichkeit von Programmen und die Erleichterung der Programmierung selbst.
Mit Hilfe der visuellen Programmierung sollen Benutzer Anwendungen selbstständig erstellen können ohne professionelle Programmierkenntnisse zu haben. Visuelle Sprachen
sollen dabei helfen komplexe Zusammenhänge darzustellen und Teile eines Programms
schneller zu erfassen.
Bei visueller Programmierung werden visuell informative Elemente verwendet. Es sind
nach Schiffer [2] solche Komponenten, die nur visuell wahrgenommen werden können,
wie zum Beispiel:
• graphische Komponenten (Diagramme, Piktogramme, Farben etc.),
• geometrische Attribute (Form, Größe, Seitenverhältnisse etc.),
• topologische Eigenschaften (Verbindungen, Überlagerungen, Berührungen etc.),
• typographische Merkmale (Schriftart, Seitengestaltung, Einrückungen etc.).
2.3 Klassifikation des Gebiets der visuellen Programmierung
Es existieren in der Literatur viele unterschiedliche Klassifikationen für die visuelle Programmierung. Hier wird eine der bekanntesten Klassifikationen von Shu [2] vorgestellt.
Shu unterscheidet zwei grundlegende Bereiche für die visuelle Programmierung: visuelle Umgebungen und visuelle Sprachen. Visuelle Umgebungen umfassen
• die Visualisierung von Daten oder Informationen über Daten
• die Visualisierung von Programmen und der Programmausführung
7
2 Grundlagen
• die Visualisierung von Softwaredesign und
• visuelles Instruieren.
Der Bereich visuelle Sprachen umfasst
• Sprachen zur Bearbeitung visueller Informationen
• Sprachen zur Unterstützung visueller Interaktion
• visuelle Programmiersprachen basierend auf Diagrammen
• visuelle Programmiersprachen basierend auf Formularen.
Die ersten beiden Kategorien der visuellen Sprachen umfassen beliebige Programmiersprachen, die nur visuelle Informationen verarbeiten. Die visuelle Programmierung wird
von den letzten zwei Kategorien in diesem Bereich erlaubt.
Abbildung 2 zeigt die Klassifikation für visuelle Programmierung nach Shu. Hier wird
die Trennung von den oben genannten Bereichen deutlich dargestellt.
Abbildung 2: Klassifikation für visuelle Programmierung nach Shu
Die in dieser Diplomarbeit zu entwerfende visuelle Programmiersprache zur Konfiguration der Datenverwaltung von Lehrveranstaltungen des StudInfo{flex}-Systems soll leicht
erlernbar und intuitiv bedienbar sein. Die Konfiguration von Lehrveranstaltungen soll
nicht mehr über direkte Eingriffe in die Datenbank, sondern über eine graphische Benutzungsoberfläche durchgeführt werden. Die Eigenschaften der visuellen Sprache können
gut in das Klassifikationsschema von Shu eingeordnet werden. Sie umfasst die Visualisierung von Datenbankschemata und visuellen Programmiersprachen, die diagrammbasierend sind.
8
2 Grundlagen
2.4 DEViL
DEViL (Development Environment for Visual Languages, Nachfolger des VL-Eli-Systems) ist ein Generator, der in der Fachgruppe Programmiersprachen und Übersetzer“
”
der Universität Paderborn entwickelt wird. DEViL generiert graphische Struktureditoren aus textuellen Spezifikationen. Dazu wird zunächst das Sprachmodell, die abstrakte Struktur, das die Grundlage eines Struktureditors bildet, spezifiziert. Im Anschluss
werden bestimmte Muster der visuellen Darstellung identifiziert und an das Sprachmodell gebunden. DEViL generiert aus diesen Spezifikationen vollständige Struktureditoren
einschließlich Interaktionsmechanismen. Die vorgefertigten Lösungen können durch den
Sprachentwickler beliebig an eine gewünschte Zielsprache angepasst werden.
Aus der Sprachspezifikation (Abbildung 3) generiert DEViL einen vollständigen visuellen
Struktureditor. Dieser enthält Analyse- und Übersetzungsprozessoren. Der Struktureditor unterstützt mehrere verschiedene visuelle Sichten auf Teile der abstrakten Struktur,
die jeweils einen bestimmten Teil des visuellen Programms repräsentieren. Jede Sicht
wird in einem separaten Fenster dargestellt. Auf der linken Seite jeder Sicht befindet
sich eine Menge von Schaltflächen, mit denen neue Sprachkonstrukte eingefügt werden
können (Abbildung 4).
Die abstrakte Struktur stellt die Grundlage einer Spezifikation dar. Sie basiert auf einem
klassenbasierten Entwurf. Auf Sprachelemente der abstrakten Struktur, die intern in eine
kontextfreie Grammatik übersetzt wird, können Attributberechnungen angewendet werden, um eine konkrete Repräsentation zu erreichen. Des Weiteren verfügt DEViL über
eine Baumsicht. Die Baumsicht repräsentiert genau die zugrundeliegende Sprachstruktur und enthält alle Informationen des konstruierten Programms. Mit der Baumsicht
kann der Kontext eines Sprachkonstrukts überblickt oder alle Daten eingesehen werden.
Die Speicherung einer Instanz eines Struktureditors erfolgt in einer XML-Datei, die die
abstrakte Struktur widerspiegelt.
Die graphische Darstellung visueller Elemente wird mit den so genannten generischen
Zeichnungen beschrieben. Die konstruierten generischen Zeichnungen beschreiben die
konkrete graphische Repräsentation bestimmter Klassen der abstrakten Struktur. Die
generischen Zeichnungen lassen sich in einem visuellen Editor erstellen.
Eine DEViL-Spezifikation lässt sich in abstrakte Struktur, visuelle Darstellung, Analyse
und Transformation unterteilen. Im Folgenden werden diese Bereiche genauer beschrieben.
9
2 Grundlagen
Abbildung 3: Generierung der visuellen Entwicklungsumgebung
Abbildung 4: Visuelle Sicht einer Datentabelle
10
2 Grundlagen
Abstrakte Struktur
Die abstrakte Struktur einer Spezifikation in DEViL ist die Grundlage für graphische
Struktureditoren. Die abstrakte Struktur einer Sprache basiert auf Modellierungskonzepten, wie Klassen, Attributen und der Vererbung. Die Instanz einer Klasse beschreibt in
einem graphischen Struktureditor die Darstellung eines visuellen Objekts. Den Klassen
können Attribute zugeordnet werden, die Eigenschaften des Sprachelements modellieren.
Es gibt drei Attributarten:
• VAL-Attribute: speichern Werte von vordefinierten Datentypen, wie zum Beispiel
VLString oder VLInt. Es können auch Vorgabewerte definiert werden, die bei der
Initialisierung eines Sprachelements gesetzt werden.
• SUB-Attribute: speichern je nach Multiplizität einen Unterbaum, eine Liste von
Unterbäumen oder sind leer.
• REF-Attribute: speichern Referenzen zu anderen Sprachobjekten.
An SUB-Attribute können folgende Multiplizitäten vergeben werden:
• *“ bedeutet, dass das Attribut eine Liste von Knoten speichert (End-Multiplizität
”
0..*, Editier-Multiplizität 0..*).
• !“ bedeutet, dass das Attribut genau einen Knoten speichert, beim Editieren aber
”
zwischenzeitlich auch leer sein kann (End-Multiplizität 1..1, Editier-Multiplizität
0..1).
• ?“ bedeutet, dass das Attribut höchstens einen Knoten der angegebenen Klasse
”
speichert (End-Multiplizität 0..1, Editier-Multiplizität 0..1).
• %“ bedeutet, dass genau ein Unterobjekt fest mit dem Attribut verbunden ist
”
(End-Multiplizität 1..1, Editier-Multiplizität 1..1). Das Unterobjekt wird automatisch beim Erzeugen des übergeordneten Knotens angelegt. Damit das möglich ist,
muss der Typ eine nicht-abstrakte Klasse sein.
Abstrakten Klassen werden benutzt, um eine bessere Struktur zu erzeugen und gemeinsame Attribute verschiedener Klassen zu definieren. Von abstrakten Klassen darf es keine
Instanzen geben. Die Vererbung ist nur von abstrakten Klassen möglich, Mehrfachvererbung ist jedoch erlaubt.
Es folgt ein Beispiel, in dem die Zustandsdiagramme modelliert werden. Die Spezifikation der abstrakten Struktur enthält immer eine Klasse namens Root“. Diese Klasse
”
11
2 Grundlagen
enthält ein Attribut diagrams“, welches eine Menge von Unterklassen vom Typ Dia”
”
gram“ definiert. Die Beispiele für verschiedene Arten von Attributen werden mittels drei
Klassen beschrieben. Die abstrakte Klasse Diagram“ enthält ein Attribut name“ vom
”
”
Typ VAL, welches den Namen dieser Klasse speichert und an Klasse StatechartDia”
gram“ vererbt. Die Klasse StatechartDiagram“ definiert ein Attribut states“ vom Typ
”
”
SUB, welches eine Liste von Zuständen speichert. Die Klasse Transition“ enthält die
”
Attribute from“ und to“ vom Typ REF, welche die Referenzen auf diese Zustände
”
”
speichern.
12
2 Grundlagen
CLASS Root {
diagrams: SUB Diagram*;
}
ABSTRACT CLASS Diagram {
name: VAL VLString;
}
CLASS StatechartDiagram INHERITS Diagram {
setSize: VAL VLPoint? INIT "400 300" EDITWITH "None";
states: SUB State*;
transitions: SUB Transition*;
}
ABSTRACT CLASS State {
position: VAL VLPoint? EDITWITH "None";
}
CLASS InitialState INHERITS State {}
CLASS FinalState INHERITS State {}
CLASS SimpleState INHERITS State {
name: VAL VLString;
}
CLASS XORState INHERITS State {
name: VAL VLString;
subStates: SUB State*;
setSize: VAL VLPoint? INIT "140 80" EDITWITH "None";
}
CLASS Transition {
position: VAL VLPoint? EDITWITH "None";
from: REF State;
to: REF State;
anchorPoints: VAL VLPointArray? EDITWITH "None";
}
Abbildung 5: Spezifikation der abstrakten Struktur
13
2 Grundlagen
Visuelle Darstellung
Die visuelle Repräsentation der abstrakten Struktur wird mittels attributierter Grammatiken spezifiziert. Durch Attributberechnungen wird die graphische Repräsentation
berechnet und gezeichnet.
Zur weiteren Vereinfachung der Spezifikation wurden in DEViL häufig auftretende graphische Darstellungskonzepte in wieder verwendbaren Spezifikationsmodulen gekapselt.
Die darin enthaltenen Implementierungen so genannter visueller Muster können instanziiert, parametrisiert und miteinander kombiniert werden. Visuelle Muster beschreiben,
wie eine bestimmte Informationsstruktur graphisch repräsentiert werden kann.
Ein oft verwendetes visuelles Muster ist zum Beispiel das Mengen-Muster VPSet“. Es
”
beschreibt, dass ein graphisches Element Unterelemente enthält, die in einem bestimmten Bereich der graphischen Repräsentation beliebig positionierbar sind. Weitere visuelle
Muster sind Listen, Formulare, Tabellen, etc. Einige visuelle Muster sind in Abbildung
6 dargestellt.
Abbildung 6: Visuelle Muster
Visuelle Muster werden angewendet, indem bestimmte Grammatiksymbole von bestimmten Symbolrollen erben. Um zum Beispiel auszudrücken, dass ein Zustandsdiagramm
14
2 Grundlagen
graphisch als Menge“ und die Zustände graphisch als frei bewegliche Mengenelemen”
”
te“ repräsentiert werden sollen, werden die Rollen VPSet“ und VPSetElement“ des
”
”
Mengenmusters verwendet.
Zur Definition der graphischen Repräsentation von Formular-Darstellungen ist ein visueller Editor verfügbar, mit dem sich generische Zeichnungen erstellen lassen (Abbildung
7). Bei generischen Zeichnungen handelt es sich um graphische Spezifikationen, mit denen sich Ausprägungen bestimmter Formular-Darstellungen einfach und komfortabel
beschreiben lassen. Generische Zeichnungen können bei Anwendung des Formularmusters referenziert werden.
Abbildung 7: Generische Zeichnung
Eine Zeichnung (Abbildung 7) besteht aus drei Teilen:
• Einfache graphische Elemente, wie Linien, Rechtecke oder Kreise, legen das grundlegende Erscheinungsbild des Sprachelements fest
15
2 Grundlagen
• Container (gelb) bestimmen, wo Unterelemente des Sprachelements positioniert
und eingeschachtelt werden sollen. In Eigenschaftsdialogen kann die Ausrichtung
des Containerinhalts festgelegt werden.
• Dehnungsintervalle auf der X- und Y-Achse bestimmen, wie die Zeichnung transformiert werden soll, um Platz für den Inhalt der Container zu schaffen.
Analyse und Transformation
Analyse und Codegenerierung von visuellen Programmen werden ebenfalls durch attributierte Grammatiken spezifiziert. Zur Lösung bestimmter Teilaufgaben können alle
Spezifikationssprachen und Modulbibliotheken des bewährten Eli-Systems, dass DEViL
zugrunde liegt, verwendet werden.
Das wichtigste Werkzeug zur Spezifikation von Zielcode eines Struktureditors ist PTG
(Pattern-based Text Generator). PTG kann Textmuster für die Ausgabe des Zielcodes
definieren. Diese können Einfügestellen enthalten, an denen andere Textmuster eingefügt
werden. Auf diese Weise lässt sich der Ausgabetext Schritt für Schritt zusammensetzen.
In einer LIDO-Datei zur Codegenerierung wird eine attributierte Grammatik spezifiziert,
in der PTG-Funktionen aufgerufen werden können.
Im folgenden Beispiel ist ein Teil der Spezifikation zur Codegenerierung für das Sprachkonstrukt DataTableDefinition“ dargestellt. Bei der Definition einer Datentabelle wer”
den ein Name, ein Kommentar, Primärschlüssel vergeben und Spalten angelegt. Alle
diese Werte sind wichtig für den Code, welcher nach der Konfiguration einer Veranstaltung generiert wird. Für das Sprachelement DataTableDefinition“ müssen spezielle
”
Attributberechnungen zugeordnet werden.
SYMBOL codeGen_DataTableDefinition
COMPUTE
SYNT.code = PTGDataTableDefinition (THIS.pers_name,
CONSTITUENTS codeGen_ColumnData.code WITH
(PTGNode, PTGNewLine, IDENTICAL, PTGNull),
THIS.pers_primaryKey,
THIS.pers_comment;
END;
Es wird eine Funktion PTGDataTableDefinition“ generiert welche vier Parameter er”
wartet. Die Werte werden in das entsprechende PTG Textmuster eingefügt:
16
2 Grundlagen
DataTableDefinition:
"CREATE TABLE IF NOT EXISTS "$1 string" ("
$2
"PRIMARY KEY ("$3 string")"
") ENGINE=MyISAM DEFAULT CHARSET=latin1 COMMENT=’"$4 string"’;"
Einfügestellen (wie $1“) ermöglichen den Zugriff auf die Attribute in der Reihenfolge,
”
in der sie in der Funktion aufgerufen werden. So wird eine Datentabelle generiert.
Solche oder ähnliche Attributberechnungen müssen für alle Sprachelemente durchgeführt
werden, die für den Zielcode relevant sind.
2.5 Das StudInfo{flex}-System
Das StudInfo{flex}-System ist eine datenbankbasierte Anwendung, welche Daten einer
Veranstaltung verwaltet. Es bietet verschiedene Benutzungsrollen an. Die Vorlage ist
eine StudInfo{flex}-Standardkonfiguration, welche angepasst wird. Diese Standardkonfiguration speichert Studentendaten, bietet Übungen, drei schriftliche Klausuren und
eine Wunschvorlesung an.
In diesem Abschnitt wird StudInfo{flex} genauer beschrieben. Als erstes wird ein Überblick gegeben, was StudInfo{flex} leistet. Danach werden die drei Module des StudInfo{flex}-Systems vorgestellt. Der darauf folgende Abschnitt zeigt die aktuellen Konfigurationsmöglichkeiten und abschließend werden die vier Konfigurationsebenen des StudInfo{flex}-Systems erklärt.
2.5.1 StudInfo{flex} aus Benutzersicht
Das StudInfo{flex}-System bietet eine Web-Schnittstelle, die über drei Module mit unterschiedlichen Funktionalitäten verfügt:
• Administratormodul
• Tutorenmodul
• Studierendenmodul
Im Administratormodul kann der Administrator die StudInfo{flex}-Standardkonfiguration bearbeiten und verwalten. Jeder Veranstalter von Lehrveranstaltungen kann für
17
2 Grundlagen
seine Vorlesung individuell festlegen, welche Informationen über die Studenten gespeichert und verarbeitet werden sollen. Dabei können individuelle Regeln, zum Beispiel
zur Vergabe von Plätzen in Übungsgruppen oder die Bonuspunkte für Klausuren, frei
konfiguriert werden. Der Administrator einer Veranstaltung hat den Zugriff auf das Tutorenmodul sowie auf einzelne Konten von Studierenden.
Die StudInfo{flex}-Standardkonfiguration unterstützt Tutoren bei der Verwaltung ihrer Übungsgruppen und liefert vielfältig konfigurierbare Teilnehmer- und Ergebnislisten.
Das StudInfo{flex}-System stellt auf Studierendenseite eine Weboberfläche zur Verfügung. Studenten, die an einer Veranstaltung teilnehmen möchten, richten sich ein
neues Teilnehmerkonto ein, indem sie sich zu dieser Veranstaltung anmelden. Die StudInfo{flex}-Standardkonfiguration bietet den Studenten ein Teilnehmerkonto, in dem zum
Beispiel Plätze in Übungsgruppen belegt oder An- und Abmeldungen für Klausuren vorgenommen werden können. Des Weiteren erhalten Studierende eine Übersicht aller beim
Veranstalter gespeicherten Daten, zum Beispiel erreichte Punkte aus der Bearbeitung
von Übungszetteln sowie das Klausurergebnis.
2.5.2 Konfiguration und Benutzung von StudInfo{flex}-Veranstaltungen
Eine StudInfo{flex}-Standardveranstaltung besteht aus mehreren Tabellen, welche in einer Datenbank angelegt sind (Abbildung 8). Jede neue Veranstaltung wird über direkten
Eingriff in diese Tabellen konfiguriert.
Wenn eine Vorlesung konfiguriert werden muss, die sich von der Standardveranstaltung wenig unterscheidet, dann sind nur geringe Änderungen nötig. Bei einer solchen
Änderung müssen jedoch mehrere Tabellen bearbeitet werden. Als erstes muss der Benutzer die richtigen Tabellen mit dem entsprechenden Inhalt finden. Dabei braucht er
bei der Suche nach den richtigen Elementen oft viel Zeit. Die Datensätze in den Tabellen
sind recht kompliziert und unübersichtlich, falls die Inhalte zu lang sind. Bei der Eingabe
von vielen Elementen muss auf die Syntax geachtet werden. Auch problematisch ist die
Vergabe von Identifikationsnummern (IDs), welche die Elemente eindeutig machen. Der
Administrator muss immer den Überblick über alle schon vergebene Nummern behalten
(Abbildung 9).
18
2 Grundlagen
Abbildung 8: Datenbank einer Standardveranstaltung
Abbildung 9: Tabelle aus der Datenbank
19
2 Grundlagen
Das StudInfo{flex}-System lässt sich auf vier verschiedenen Ebenen benutzen (Abbildung 10).
Abbildung 10: Benutzungssebenen des StudInfo{flex}-Systems
Auf der ersten Benutzungsebene spezifiziert der Administrator eine Instanz mit der
StudInfo{flex}-eigenen Konfigurationssprache. Das geschieht in den Konfigurationstabellen (Config-Tabellen). Je nach Inhalt dieser Tabellen kann ein beliebiges Verwaltungssystem, d.h. nicht nur eine Veranstaltung, sondern zum Beispiel auch eine Schlüsselverwaltung, definiert werden. Dieser Ebene liegt die Implementierung der Konfigurationssprache in Perl [13] zugrunde, welche die Konfiguration liest und eine entsprechende
Web-Schnittstelle bereitstellt. Sie bildet die Basis auf dem ein System aufgebaut werden
kann. Die Konfigurationstabellen stellen den variablen Teil dieser Ebene dar und werden
je nach Verwendung mit dem entsprechenden Inhalt gefüllt.
Auf der zweiten Ebene passt der Administrator lediglich eine vorgefertigte Standardkonfiguration an. Hier sind die meisten Konfigurationstabellen mit Werten gefüllt, welche für die Datenverwaltung einer Veranstaltung nötig sind. Die Standardkonfiguration
bietet unter anderem eine Übungsanmeldung, Klausur- und Übungspunktevergabe und
die Auswahl einer Wunschvorlesung. Die Werte für die Durchführung dieser Aktionen
(zum Beispiel Themen für die Wunschvorlesung) werden in den Wertebereichstabellen
(Values-Tabellen) gesetzt und können auf dieser Ebene beliebig definiert werden.
20
2 Grundlagen
Auf der dritten Ebene wird die StudInfo{flex}-Veranstaltung über die Weboberfläche
konfiguriert. Hier sind einige Werte aus Wertebereichstabellen als Auswahllisten dargestellt. Die zu konfigurierenden Teile auf dieser Ebene, sind die Werte für Grundkonfigurationsvariablen und die Phasenschaltung. Die Grundkonfigurationsvariablen (Abbildung 11), wie zum Beispiel der Name der Veranstaltung und des Professors, sowie die
Freischaltung von einzelnen Vorlesungsphasen werden über die Weboberfläche des Administratormoduls geändert.
Abbildung 11: Aktuelle Grundkonfiguration
Auf der vierten Ebene erfolgt die Benutzung der fertigen StudInfo{flex}-Instanz über die
Weboberfläche. Auf dieser Ebene können die Studenten, Tutoren und der Administrator
die Vorlesungsdaten einsehen und bearbeiten. Das sind Informationen, wie allgemeine
Daten von Studierenden oder erreichte Punkte in den Übungen und Klausuren.
In den folgenden Abschnitten werden die einzelnen Ebenen genauer beschrieben.
21
2 Grundlagen
Erste Benutzungsebene
Dieser Abschnitt beschreibt die abstrakte Sprache, in der eine StudInfo{flex}-Konfiguration formuliert wird. Diese Beschreibung ist wichtig, weil auf Grundlage dieser abstrakten Sprache der Entwurf der visuellen Sprache zur Konfiguration von StudInfo{flex}Veranstaltungen erfolgt.
Auf der ersten Benutzungsebene spezifiziert der Administrator eine Instanz mit der
StudInfo{flex}-eigenen Konfigurationssprache. Dabei füllt er die Konfigurationstabellen
mit den Werten, welche ein System zur Datenverwaltung von Lehrveranstaltungen darstellen. Dieses System unterscheidet drei Benutzungsrollen und zwar den Studierenden,
den Administrator und den Tutor.
Jede Konfigurationstabelle stellt einen Spezifikationsteil einer Veranstaltung dar. Diese Spezifikationsteile enthalten Operationen bzw. Elemente zu einem der drei Module.
Eine Konfigurationstabelle, zum Beispiel für den Spezifikationsteil Abfrage“ des Studie”
rendenmoduls, enthält SQL-Abfragen zu Übungsameldung, Übungspunkteberechnung,
Klausurteilnahme, Klausurergebnis sowie Wahl des Wunschthemas. Es sind also in der
Konfigurationstabelle nur solche Abfragen enthalten, welche die Daten in einem Modul
anzeigen, bearbeiten und aufbereiten. Die Konfigurationstabellen für gleiche Spezifikationsteile haben gleichen Aufbau. Gleicher Aufbau bedeutet, dass die Tabellen gleiche
Spaltennamen besitzen und im Allgemeinen identisch funktionieren.
Folgende Konfigurationstabellen sind in Gruppen aufgeteilt, welche gleiche Spezifikationsteile für das Studierenden-, Tutoren- und Administratormodul enthalten:
• Konfigurationstabellen mit Grundkonfigurationsvariablen: setzt die Grundkonfigurationsvariablen, zum Beispiel den Vorlesungsnamen.
• Konfigurationstabellen mit Abfragen: enthalten die Abfragen (Queries) in SQL für
die Beschaffung der gewünschten Daten, die angezeigt werden sollen.
• Konfigurationstabellen mit Aktualisierungsabfragen: enthalten die Aktualisierungsabfragen (Updates) für die Datenerfassung in Modulen.
• Konfigurationstabellen mit Berichten: hier werden die Berichte (Reports) definiert.
Im Administrator- und Tutormodul werden Berichte mittels des Report-Generators
gewählt. Im Studierendenmodul werden die Berichte verwendet, um An- und Abmeldungsformulare für Klausuren zu erstellen.
Zusätzlich existieren noch weitere Konfigurationstabellen, welche Spezifikationsteile definieren, die nicht für alle drei Module gültig sind. Zum Beispiel die Konfigurationstabellen
22
2 Grundlagen
nur für Administrator- und Tutorenmodul:
• Konfigurationstabellen mit Typschlüsselspezifikation: hier werden die Typschlüsseln
für die automatische Datenerfassung per Barcode spezifiziert.
Und nur für das Studierendenmodul:
• Konfigurationstabelle mit Weboberflächendarstellung: enthält Elemente, welche
die Weboberfläche des Studierendenmoduls (Display) beschreiben.
Außer Konfigurationstabellen sind auf der ersten Ebene weitere Arten von Tabellen
vorzufinden. In der Datenbank einer Lehrveranstaltung sind weiterhin folgende Tabellen
angelegt (siehe Abbildung 8):
• Datentabellen (Data)
• Wertebereichstabellen (Values)
Die Datentabellen werden auf der vierten und die Wertebereichstabellen auf der zweiten Benutzungsebene benutzt. Dabei speichern die Datentabellen die Werte, die über
die Weboberfläche von Studenten, Tutoren und dem Administrator eingegeben werden.
Die Wertebereichstabellen werden verwendet, um die Konfiguration einer Veranstaltung
anzupassen. Neue Tabellen von diesen Typen können angelegt werden.
Zweite Benutzungsebene
Auf der zweiten Ebene passt der Administrator eine vorgefertigte Standardkonfiguration an. Dazu füllt er die Wertebereichstabellen (Values-Tabellen) mit dem gewünschten
Inhalt. Der Administrator definiert unter anderem Übungs-, Klausurtermine, mögliche
Punkte in Übungen und Klausuren sowie Themen zur Wunschvorlesung. Auf der Grundlage dieser Standardveranstaltung werden beim Entwurf der visuellen Sprache die Aspekte gebildet.
Die Wertebereichstabellen werden vor allem für die Darstellung von Auswahlmöglichkeiten in Dropdown-Listenfeldern auf der Weboberfläche, sowie in SQL-Anweisungen zur
Festlegung von gültigen Wertebereichen verwendet. Ein Beispiel dafür ist die Liste von
möglichen Studiengängen (Abbildung 12), welche für Studenten beim Anlegen des Kontos angezeigt wird.
23
2 Grundlagen
Abbildung 12: Auswahlliste von möglichen Studiengängen
Dritte Benutzungsebene
Auf der dritten Benutzungsebene konfiguriert der Administrator eine Vorlesung über
die Weboberfläche des Administratormoduls. Auf dieser Ebene werden keine weiteren
Änderungen direkt in den Datenbanktabellen durchgeführt. Die Weboberfläche bietet
eine Liste von Phasen sowie eine Übersicht über alle Grundkonfigurationsvariablen. Der
Benutzer nutzt diese Ebene zum Aktivieren von Phasen und gegebenenfalls zur Anpassung von Grundkonfigurationsvariablen.
Eine Phase beschreibt ein Abschnitt einer Veranstaltung. Dieser Abschnitt beginnt, sobald die Phase mittels des Phasenschalters aktiviert wird (Abbildung 13). So wird je nach
aktiver Phase zum Beispiel die Möglichkeit gegeben sich für eine Übungsgruppe anzumelden, den Klausurteilnahmestatus zu ändern oder die entsprechenden Formulare zur
An- bzw. Abmeldung von einer Prüfung herunter zu laden. Später kann dann ebenfalls
das Klausurergebnis angezeigt werden. Da die aktiven Phasen jederzeit änderbar sind,
können gezielt die Zeiträume für unterschiedliche Phasen einer Veranstaltung bestimmt
werden. Beispiele für typische Phasen sind:
• An- und Abmeldung von der Prüfung möglich
• nur noch Abmeldung von der Prüfung zulässig
• weder An- noch Abmeldung ist erlaubt
• Veröffentlichung des Klausurergebnisses.
24
2 Grundlagen
Abbildung 13: Aktivierung von Phasen
Die Auswahl der aktiven Phasen beeinflusst unter anderem
• welche Informationen in den Modulen angezeigt werden,
• welche Datenerfassung möglich ist,
• welche Abfragen zur Beschaffung und Aktualisierung der Daten verwendet werden
und
• welche Reports ausgewählt werden können.
Auf dieser Benutzungsebene kann der Administrator auch die Anpassungen bezüglich
Grundkonfigurationsvariablen durchführen. Die Grundkonfigurationsvariablen sind unter anderem der Name der Vorlesung, der Name des Professors und die Sekretariatsdaten
(Abbildung 14). Die Variablen werden an vielen Stellen verwendet, zum Beispiel in automatisch versandten E-Mails, generierten Berichten, Formularen für Klausuran- und
-abmeldungen, Klausurinformationen, etc.
25
2 Grundlagen
Abbildung 14: Grundkonfigurationsvariablen einer Standardveranstaltung
Vierte Benutzungsebene
Auf der vierten Benutzungsebene erfolgt die Benutzung der angepassten StudInfo{flex}Veranstaltung über die Weboberfläche des Studierenden-, Tutoren- und Administratormoduls.
Während des Vorlesungsbetriebs füllen die Studenten bestimmte Formulare mit Daten
über die Weboberfläche des Studierendenmoduls aus. Das sind Daten, welche Studenten
eingeben, wenn sie sich ein Konto zur Veranstaltung anlegen (Abbildung 15), sich für
eine Übungsgruppe anmelden und an der Klausur teilnehmen. Des Weiteren können die
Studenten ein Wunschthema aus einer Liste der angebotenen Themen aussuchen.
Die Tutoren verwalten auf dieser Ebene deren Übungsgruppen, in dem sie unter anderem den Studenten Übungspunkte für abgegebene Hausaufgaben gutschreiben.
26
2 Grundlagen
Der Administrator trägt auf dieser Ebene die erreichten Klausurpunkte ein und kann
sich verschiedene Statistiken und andere Berichte zur Vorlesung anzeigen lassen.
Abbildung 15: Formular zum Anlegen eines Kontos
27
3 Sprachentwurf
3 Sprachentwurf
In diesem Kapitel wird der Entwurf der visuellen Sprache für das StudInfo{flex}-System
vorgestellt. Die folgenden Abschnitte beschreiben die konkreten Anforderungen an die
zu entwickelnde Umgebung, die entwickelten Konzepte sowie die Spezifikationssprache
für das StudInfo{flex}-System.
3.1 Anforderungen
Ein wichtiges Ziel des Entwurfs einer visuellen Sprache für das StudInfo{flex}-System
ist die Entwicklung der intuitiv bedienbaren Benutzungsoberfläche, im Folgenden auch
StudInfo{flex}-Designer genannt. Die Benutzungsoberfläche soll die wichtigen und zentralen Elemente des StudInfo{flex}-Systems abbilden. Die Konfiguration von StudInfo{flex}-Veranstaltungen soll einfach und schnell erfolgen können. Da einige Schritte
nur in Abhängigkeit von anderen durchgeführt werden können, muss der Arbeitsfluss
gekennzeichnet werden.
Der Lernaufwand für die Benutzung der visuellen Umgebung soll möglichst gering gehalten werden. Die Einarbeitungszeit des Benutzers soll durch eine intuitiv bedienbare
Benutzungsoberfläche und eine gut strukturierte visuelle Sprache minimiert werden. Die
visuelle Sprache für das StudInfo{flex}-System soll einen Geschwindigkeitsvorteil gegenüber der herkömmlichen Konfiguration bieten und den Benutzer dabei unterstützen,
den Umgang mit dem StudInfo{flex}-System zu erlernen, um auch komplexere Konfigurationen erstellen zu können. Dabei soll der Benutzer eine neue Konfiguration erstellen
können ohne die generierten Konfigurationstabellen noch manuell nachbearbeiten zu
müssen.
Eine weitere wichtige Anforderung an den Entwurf der Sprache ist die Unterstützung
aspektorientierter Spezifikation. Mit ihrer Hilfe erfolgt die Bildung von Aspekten. Ein
Aspekt ist eine Teilfunktionalität einer Konfiguration, zum Beispiel die Klausurverwaltung. Die Aspekte sollen bei jeder neuen Konfiguration der StudInfo{flex}-Veranstaltungen von den Administratoren beliebig zusammengesetzt, neu angelegt und entsprechend
angepasst werden können. Die bereits vorhandenen Aspekte oder Daten aus den Aspekten von früheren Veranstaltungen sollen wieder verwendet werden können. Auch die
Erstellung von neuen Aspekten, wie zum Beispiel Mündliche Prüfung“ soll einen gerin”
gen Schwierigkeitsgrad besitzen.
Als Ergebnis der fertigen StudInfo{flex}-Konfiguration soll SQL-Code generiert werden,
der die entsprechenden Konfigurationstabellen in der StudInfo{flex}-Datenbank anlegt.
28
3 Sprachentwurf
3.2 Überblick über die Sprache
Bei dem Entwurf einer visuellen Sprache für das StudInfo{flex}-System wurden die
Konfigurations-, Daten- und Wertebereichstabellen sehr genau untersucht. Die Tabellen
einer StudInfo{flex}-Konfiguration wurden in verschiedene Spezifikationsteile zerlegt.
Aus den Spezifikationsteilen wurden die Sichten zur übersichtlichen Modellierung von
StudInfo{flex}-Veranstaltungen definiert (Abbildung 16). Diese sind:
• Properties-Sicht: In dieser Sicht werden alle Grundkonfigurationsvariablen, außer read only“-Variablen, einer Veranstaltung definiert. Diese Variablen sind
”
die zentralen Werte und Einstellungen einer StudInfo{flex}-Veranstaltung. Einige
Grundkonfigurationsvariablen, wie zum Beispiel der Name der Vorlesung, werden
auf der Weboberfläche angezeigt. Andere sind wichtig für die Modellierung von
Aspekten. Dort werden sie in automatisch versandten E-Mails, generierte Berichte,
Formularen für Klausuranmeldungen und -abmeldungen, Klausurinformationen,
etc. verwendet.
• Tutorusers-Sicht: In dieser Sicht werden die Daten aller Tutoren hinterlegt, die
eine Übung zu einer Veranstaltung leiten. Hier werden Daten, wie Name, Vorname,
E-Mail, Login und Passwort von jedem Tutor verwaltet. Dadurch haben sie den
Zugriff auf das Tutorenmodul. Über das Tutorenmodul werden die Punkte für
Übungsaufgaben vergeben und verschiedene E-Mails an Übungsgruppenteilnehmer
verschickt. Des Weiteren werden die Daten von Tutoren bei der Modellierung des
Aspekts für Übungen verwendet.
• Aspect-Sicht: In dieser Sicht erfolgt die Gestaltung einzelner Aspekte. Ein Aspekt
ist eine Teilfunktionalität einer Veranstaltung und enthält Elemente wie Zugriffsrechte, Datentabellen, Wertebereichstabellen, Abfragen, Datenerfassung, Berichte
und Darstellung des Studierendenmoduls (Display). Dabei werden in einem Aspekt
nur solche Elemente definiert, welche logisch zum aktuellen Aspekt passen. Zum
Beispiel gehören zum Aspekt Klausuren“ die Tabelle mit Klausuraufgaben, eine
”
Abfrage zur Berechnung des Klausurergebnisses und ein Formular zur Klausuranmeldung.
• Phases-Sicht: In dieser Sicht werden die Zugriffsrechte (Permissions) zu Phasen
zusammengefasst und deren gewünschte Reihenfolge definiert. Die Phasen werden im Vorlesungsbetrieb vom Administrator nacheinander freigeschaltet. Dies
ermöglicht die Aktivierung von Aspekten.
In der Hauptsicht sind alle vier Spezifikationsteile einer StudInfo{flex}-Veranstaltung
abgebildet (Abbildung 16). Diese stellen die wichtigsten Grundbausteine dar.
29
3 Sprachentwurf
Abbildung 16: Hauptsicht der StudInfo{flex}-Standardvorlesung
Der Zugriff auf einzelne Spezifikationsteile ist nur aus der Hauptsicht möglich. So behält
der Benutzer den Überblick und kann schneller ein Element finden, welches er anpassen möchte. Jedes Spezifikationsteil hat seine eigene Sicht. Für die Modellierung von
Aspekten gibt es ein Sprachelement Aspect“. Es können also mehrere Aspekte angelegt
”
werden.
3.3 Grundsätzliche Entwurfsüberlegungen
Die Repräsentation von Daten wurde durch Zuhilfenahme von Farben dargestellt. Es
wurden die Farben verwendet, die über die Weboberfläche des StudInfo{flex}-Systems
erkennbar sind. Einige Darstellungen von Sprachelementen, zum Beispiel für die Übersicht
der Grundkonfigurationsvariablen, wurden direkt aus der StudInfo{flex}-Standardkonfiguration übernommen. Jedoch haben nicht alle Sprachelemente eine Entsprechung in
30
3 Sprachentwurf
der Weboberfläche. Zum Beispiel gibt es für die Tutorendaten keine Webseite wie für die
Grundkonfigurationsvariablen. Darum wurde die graphische Darstellung der TutorusersSicht an die Properties-Sicht angepasst. In der Aspect-Sicht können die entsprechenden
Aspektelemente in hell-blauen Containern in eine vertikale Liste eingefügt werden. Sie
werden mit einer weißen Linie voneinander getrennt. Eine solche Darstellung ist bei der
Trennung von einzelnen Grundkonfigurationsvariablen wieder zu finden. In der AspectSicht wird über einer Gruppe von Elementen immer die Bezeichnung des Aspektselements angezeigt. Auch in Detailsichten von Aspektselementen sind solche Überschriften
über größeren Sprachelemente platziert. Dies ermöglicht eine bessere Trennung von einzelnen Elementen und dadurch einen besseren Überblick in den Sichten. Solche graphische Darstellung wurde aus Webseiten des Studierendenmoduls übernommen. So werden
dort die Abschnittüberschriften aufgeführt.
Die immer wieder verwendeten Elemente aus einzelnen Sichten, wie zum Beispiel Kommentare, werden in verschiedenen Sichten der Aspektelemente immer gleich angeordnet
und haben die gleiche visuelle Darstellung. Zur besseren Übersicht wurden an solchen
Elementen verschiedene Symbole angebracht.
Diese graphischen Entwurfsentscheidungen sind wichtig, damit die komplette graphische Darstellung der Benutzungsoberfläche einheitlich wirkt und der Übergang von der
Konfiguration einer Lehrveranstaltung mit StudInfo{flex}-Designer zur Darstellung dieser Veranstaltung in StudInfo{flex}-System fließend ist.
Um den Arbeitsfluss des Benutzers zu lenken, wurden die Spezifikationsteile und Aspektelemente mit römischen Zahlen versehen. Diese geben dem Benutzer eine Reihenfolge
vor, in der die Sichten abgearbeitet werden sollen. Das bedeutet, dass die Konfiguration
von StudInfo{flex}-Veranstaltung von oben nach unten bearbeitet werden soll. Denn es
ist nicht möglich eine Phase zu definieren, wenn noch keine Zugriffsrechte (Permissions)
in den einzelnen Aspekten angelegt worden sind.
3.4 Aspekte
Die Aspekte beschreiben wichtige Teilfunktionalitäten einer Vorlesung. Zu solchen Teilfunktionalitäten gehören unter anderem Übungen und Klausuren. Die Elemente, welche ein Aspekt darstellen, werden in der Aspect-Sicht aufgelistet. Ein Aspekt enthält
Elemente wie Zugriffsrechte, Datentabellen, Wertebereichstabellen, Abfragen, Datenerfassung, Berichte und die Darstellung des Studierendenmoduls. Dabei werden in einem
Aspekt nur solche Elemente definiert, welche logisch zum aktuellen Aspekt gehören. Zum
Beispiel eignen sich die Tabelle mit Klausuraufgaben, eine Abfrage zur Berechnung des
31
3 Sprachentwurf
Klausurergebnisses und ein Formular zur Klausuranmeldung zum Aspekt Klausuren“.
”
In der Aspect-Sicht werden die Aspektelemente nur angelegt (Abbildung 17). Sie werden
in den einzelnen Detailsichten bearbeitet.
Abbildung 17: Aspect-Sicht
32
3 Sprachentwurf
Eine Standardveranstaltung besteht aus vier Aspekten:
• Student
• Übungen
• Klausuren
• Wunschvorlesung
Der Aspekt Student“ bietet eine Wertebereichstabelle, in der mögliche Studiengänge
”
zu einer Vorlesung eingetragen sind. Dieser Aspekt verfügt über ein Display, welches die
Webseite Persönliche Daten“ des Studierendenmoduls definiert. Weiterhin stellt der
”
Aspekt Student“ mehrere Berichte (Reports) zur Verfügung, mit denen Nachrichten an
”
Veranstaltungsteilnehmer bei Kontoproblemen verschickt werden können.
Der Aspekt Übungen“ verfügt über mehrere Wertebereichstabellen, in denen Übungs”
gruppen und Punkte pro Übungsblatt definiert sind. Dieser Aspekt bietet ein Display,
welches die Webseite Übungen“ des Studierendenmoduls definiert. Auch mehrere Re”
ports mit denen Nachrichten an Übungsteilnehmer verschickt und Übungsstatistiken
angezeigt werden können, sind in diesem Aspekt enthalten. Der Aspekt bietet eine Datenerfassung, welche die Webseite im Tutorenmodul zu Vergabe von Übungspunkten an
einzelne Studenten darstellt.
Der Aspekt Klausuren“ bietet Wertebereichstabellen, in denen mögliche Klausurter”
mine, Klausurpunkte und Klausurnoten eingetragen wurden. Dieser Aspekt liefert ein
Display, welches die Webseiten Erste Klausur“, Zweite Klausur“ und Dritte Klausur“
”
”
”
im Studierendenmodul definiert. Der Aspekt bietet mehrere Reports mit denen Nachrichten an Veranstaltungsteilnehmer bei Klausuran- bzw. abmeldungsproblemen verschickt
und Klausurergebnislisten generiert werden. Der Aspekt Klausuren“ stellt eine Daten”
erfassung zur Verfügung, welche die Webseite im Administratormodul zur Vergabe von
Klausurpunkten an einzelne Studenten anzeigt.
Der Aspekt Wunschvorlesung“ liefert eine Wertebereichstabelle mit möglichen Themen
”
einer Vorlesung. Dieser Aspekt bietet ein Display, welches die Webseite Wunschvorle”
sung“ des Studierendenmoduls definiert. Ein Report, welcher eine Liste der drei meist
gewünschten Themen anzeigt, wird nur mit diesem Aspekt angeboten.
Alle Aspekte funktionieren unabhängig voneinander. Sie können beliebig kombiniert
und gelöscht werden. Wenn ein Aspekt definiert wird, kann er immer wieder verwendet
werden. Bei der Konfiguration einer neuen Veranstaltung kann der Benutzer die Aspekte
aus anderen Veranstaltungen importieren. Das gilt auch für alle Aspektelemente.
33
3 Sprachentwurf
3.5 Konfiguration der Weboberfläche im Studierendenmodul
Die Weboberfläche des Studierendenmoduls musste herkömmlich durch Bearbeitung
mehrerer Tabellen angepasst werden. Zum einen war es die Tabelle, in der die Darstellung von Webseiten (Display) spezifiziert und zum anderen eine Tabelle, in der Webseiten zu Aktualisierungsabfragen (Updates) konfiguriert wurden. Abbildung 18 zeigt die
Tabelle für Display. Man sieht, dass das Durchführen von Änderungen sehr unbequem
Abbildung 18: Herkömmliche Konfiguration von Display
und unübersichtlich ist.
Beim Entwurf der visuellen Sprache wurden das Display und die Updates zusammengefasst. Jetzt kann der Administrator bei der Gestaltung einer Webseite wichtige Elemente
auf einem Blick betrachten.
Alles was für Studenten im Studierendenmodul sichtbar ist, wird in einer Display-Sicht
zusammengesetzt. In jeder Display-Sicht wird mindestens eine Webseite definiert. Dazu gehören die Strukturelemente für die Webseite und Updates (Abbildung 19). Die
Strukturelemente Navigationspunkt“ (CHAPTER), Abschnittsüberschrift“ (SECTI”
”
ON) und Datenfeld“ (FIELD) werden mit den gleichnamigen Sprachelementen ein”
gefügt. In Abbildung 20 ist Persönliche Daten“ ein Navigationspunkt und Hauptab”
schnitt einer Seite, Ihre Daten“ ein Abschnittsüberschrift und Name“ ein Datenfeld.
”
”
34
3 Sprachentwurf
Abbildung 19: Display mit Updates
Der Wert des Datenfeldes, der über eine Abfrage festgelegt wird, kann an eine Variable gebunden werden, indem ein so genannter Identifier eingegeben wird. Wenn ein
Identifier gesetzt wird, dann wird er visuell angezeigt. Zum Beispiel ist das Datenfeld
Nachname“ an den Identifier name“ gebunden (Abbildung 19). Die Bindung wird mit
”
”
einem Pfeil angedeutet. So kann der Benutzer sofort erkennen, welche Identifier die Datenfelder haben.
Bei den Datenfeldern, welche von Studenten verändert werden können, zum Beispiel
Vorname“, wird ein Link, wie ändern“, angezeigt (Abbildung 20). Betätigt der Stu”
”
dent diesen Link, wird er auf eine Seite geleitet, auf der die Änderungen durchgeführt
werden können (Abbildung 21). Abbildung 19 zeigt die Spezifikation dieser Funktionalität.
35
3 Sprachentwurf
Abbildung 20: Display mit persönlichen Daten
Abbildung 21: Auswirkungen von Update Nachname“
”
Für Datenfelder, welche von Studenten geändert werden dürfen, werden die Aktualisierungsabfragen mit dem Sprachelement Update“ angelegt. Sie werden auf der rechten
”
Seite der Display-Sicht platziert (Abbildung 19). Ein Update enthält einen Button und
eine Variable. In Abbildung 19 enthält das Update Nachname“ ein Button ÄNDERN“
”
”
und eine einfache Variable Nachname“ vom Typ string“. Um zu zeigen, zu welchem
”
”
Datenfeld ein Update gehört, muss von Update aus eine Referenz auf das gewünschten
Datenfeld gesetzt werden. Durch die Referenz wird ein Pfeil vom Datenfeld zum Update gezeichnet (Abbildung 19). Dies sagt aus, dass nach dem Anklicken auf den Link
[ändern]“ der Student auf eine andere Seite geleitet wird, auf der er die Änderungen
”
durchführen kann.
36
3 Sprachentwurf
3.6 Datenerfassung
Nicht nur Studenten haben Webseiten, auf denen sie ihre Angaben machen können.
Die Tutoren und der Administrator müssen ebenfalls über die Weboberfläche einige
Daten für Studenten eingeben oder ändern, zum Beispiel Punkte für Übungsaufgaben.
Für jede Art der Eingabe muss eine Datenerfassung (DataEntry) definiert werden, in
der die Weboberfläche des Tutoren- und Administratormoduls gestaltet wird. Bei der
Bearbeitung muss der Benutzer beachten, dass nach dem Anlegen eines DataEntry ein
Typschlüssel definiert wird, was leicht vergessen werden kann. Aus diesem Grund enthält
die Datenerfassungssicht die Definition des Typschlüssels.
Die Datenerfassung von Studentendaten für Tutoren und den Administrator wird mit
dem Sprachelement DataEntry“ definiert. Dabei werden unter dem Abschnitt Signa”
tur eine Schaltfläche und Variablen angelegt, die letztendlich auf der Webseite angezeigt werden (Abbildung 22). Wenn ein DataEntry angelegt wurde, dann muss ein
Typschlüssel (EnterType) definiert werden. Der Typschlüssel wird in der Datenerfassungssicht immer ganz unten in einem grauen Rechteck dargestellt (Abbildung 22).
Per Doppelklick können die Eigenschaften eines Typschlüssels im Dialogfenster definiert
werden. Der Pfeil signalisiert, dass es nach der Bearbeitung vom Datenerfassungsformular unmittelbar weiter zu Definition des Typschlüssels geht. Die graue Farbe soll
das Element hervorheben. Der Typschlüssel sorgt dafür, dass in der Datenerfassung des
Administrator- oder Tutormoduls (je nach Gültigkeitsbereich) der Typschlüssel-Name
in der Navigationsleiste erscheint (Abbildung 23) und der Code des Typschlüssels bei
der automatischen Datenerfassung per Barcode erkannt wird.
37
3 Sprachentwurf
Abbildung 22: Datenerfassungssicht
38
3 Sprachentwurf
Abbildung 23: Manuelle Eingabe von Übungspunkten
3.7 Permissions
Eine Veranstaltung soll mit einer Übung beginnen und mit dem Klausurergebnis der letzten Klausur enden. Um diese Reihenfolge darstellen zu können, werden Phasen benötigt
(Abbildung 24). Jede Phase besteht aus einer Menge so genannter Permissions. Zum Beispiel hat die Phase Start der Vorlesung“ in Abbildung 24 die Permission {UE}“. Die
”
”
Permissions sind Zugriffsrechte, welche bei vielen Aspektelementen definiert werden. Sie
erlauben in bestimmten Abschnitten einer Vorlesung, dass im Studierendenmodul diese
Elemente funktionieren bzw. sichtbar werden. So ist zum Beispiel die Klausurabmeldung
nur bis zu zwei Wochen vor der Klausur möglich. Die Klausurabmeldung hat eine bestimmte Permission. Und nur dann, wenn die Phase mit dieser Permission aktiviert ist,
kann die Klausurabmeldung durch Studenten vorgenommen werden.
39
3 Sprachentwurf
Abbildung 24: Phasenschalter
Bei dem Entwurf der visuellen Sprache wurden die Permissions zu den Aspekten zugeordnet. In jedem Aspekt werden Permissions definiert, welche nur für diesen Aspekt
gültig sind (Abbildung 25). Dabei wird im Hintergrund immer der Aspektname mitgespeichert.
Abbildung 25: Permissions
40
3 Sprachentwurf
Jedes Aspektelement verfügt über ein Attribut, welches die zugehörige Permission definiert (Abbildung 26).
Abbildung 26: Referenz auf eine Permission bei Abfrage
Bei der Definition einer Phase kann der Administrator die Permissions aus einzelnen
Aspekten verwenden. Wenn eine Phase über die Weboberfläche vom Administrator frei
geschaltet wird, dann werden alle Aspektelemente, bei denen die Permissions dieser Phase gesetzt sind, gezielt aktiviert.
41
3 Sprachentwurf
3.8 Abfragen
Ein wichtiges Sprachelement für einen Aspekt ist eine Abfrage (Query). Die Abfragen beschaffen die Daten, welche über die Weboberfläche in verschiedenen Modulen angezeigt
und für Reports bearbeitet und aufbereitet werden. Die meisten Abfragen enthalten viel
SQL-Text und waren in Konfigurationstabellen nur schlecht überschaubar (Abbildung
27).
Abbildung 27: Konfigurationstabelle mit Abfragen
42
3 Sprachentwurf
Um eine Abfrage besser bearbeiten zu können, wurde beim Entwurf der visuellen Sprache großer Wert auf gute Darstellung von SQL-Text gelegt. Daher wird der SQL-Text
einer Abfrage in Query-Sicht direkt angezeigt (Abbildung 28).
Alle wichtigen Abfrageelemente werden in der Query-Sicht visuell dargestellt (Abbildung 28). Dadurch hat der Administrator einen Überblick über alle Elemente, die eine
Abfrage ausmachen. Eine Query-Sicht enthält einen Kommentar, welcher die Abfrage
textuell beschreibt, SQL-Text, eine Referenz auf eine Permission, in der die Query aktiviert wird und einen Gültigkeitsbereich.
Abbildung 28: Query-Sicht
Ein Kommentar wird hier in grauer Schrift angezeigt, was bedeutet, dass dieser auf der
Weboberfläche nicht sichtbar ist. Vor dem Kommentar ist ein Symbol angebracht, welches dem Benutzer sofort erkennen lässt, dass es sich um einen Kommentar handelt. Der
SQL-Text einer Abfrage wird vom Administrator im Dialogfenster von Abfrageeigenschaften eingegeben. Um einen besseren Überblick über den SQL-Text zu haben, wird
dieser ebenfalls in der Query-Sicht direkt angezeigt. Der SQL-Text ist zusätzlich in ein
Rechteck mit gestichelter Linie gesetzt, damit er besser von anderen Elementen getrennt
wird (Abbildung 28). An der oberen linken Ecke ist ein Symbol angebracht, welches den
SQL-Text kenntlich machen soll.
In dieser Sicht wird ebenfalls der Name der referenzierter Permission sowie der Gültigkeitsbereich angezeigt. Vor dem Namen der Permission ist ein Symbol angebracht, welches beschreiben soll, dass eine Query erst dann aktiviert wird, wenn die Permission
durch den Phasenschalter aktiviert wird. Das andere Symbol, welches vor dem Namen
des Gültigkeitsbereichs steht, zeigt die verschiedene Module, die zusammen ein Ganzes
43
3 Sprachentwurf
darstellen.
3.9 Mapping
Um einen Bericht (Report) zu generieren, werden Daten benötigt, die aufbereitet werden
sollen. Das geschieht durch Mappings. Ein Mapping beschafft die Daten nur für den Report, in welchem es angelegt wird. Die Mappings bereiten Tabellen auf, welche direkt in
dem Report verwendet werden. Die Erstellung von Mappings im StudInfo{flex}-System
ist kompliziert und aus diesem Grund wurde versucht dieses durch eine gute visuelle
Repräsentation einfacher zu gestalten.
Beim Mapping wird eine Ergebnistabelle definiert. Der Name der Tabelle ist über Spaltennamen platziert, welche in dieser Ergebnistabelle angelegt werden müssen. In Abbildung 29 sind BonusGrenzen“, Uebungsergebnis“ und Ergebnis“ die Namen von
”
”
”
Ergebnistabellen. Die Spalten werden mittels Sprachelementen hinzugefügt, bei denen
die Spaltennamen aus einer Referenzliste ausgewählt oder vom Benutzer selbst definiert
werden können. Gleichzeitig werden sie intern auch als Variablen definiert und können
somit als Platzhalter verwendet werden. Die Spaltennamen müssen mit den Spalten
der angegebenen Abfrage assoziiert werden. Die Spalten BonusID“, BonusTxt“ und
”
”
PunkteVon“ der Tabelle BonusGrenzen“ (Abbildung 29) assoziieren mit den Spalten
”
”
ID“, Bonus“ und PunkteVon“ der folgenden Abfrage UebungsBonusGrenzen“.
”
”
”
”
SELECT ‘ID‘, ‘Bonus‘, ‘PunkteVon‘
FROM ‘Values_Bonus‘
ORDER BY ‘ID‘;
Es können auch mehrere Mappings hintereinander angelegt und miteinander verknüpft
werden. Dafür kann ein Sprachelement verwendet werden, das visuell als ein Plus dargestellt wird (Abbildung 29). Die Verknüpfung verursacht, dass zuerst die erste Abfrage
ausgeführt und die entsprechende Ergebnistabelle temporär generiert wird. Daraufhin
wird auf jeden Datensatz der Ergebnistabelle die zweite Abfrage, welche nach dem Plus
kommt, ausgeführt.
Da eine Tabelle dargestellt werden muss, wurden die Spalten in einer horizontalen Liste
platziert. Die Assoziation von Spaltennamen mit Spalten der angegebenen Abfrage wurde durch eine große geschweifte Klammer, welche alle Spalten umfasst, dargestellt. Ein
Plus zeigt, dass zwei Mappings miteinander verknüpft sind.
44
3 Sprachentwurf
Abbildung 29: Mappings
3.10 Tabellenmodellierung
Bei der Konfiguration einer StudInfo{flex}-Veranstaltung werden außer Konfigurationstabellen noch zwei weitere Arten von Tabellen benötigt, Daten- und Wertebereichstabellen. Auch diese sollen in Aspekten definiert werden. Zur Verbesserung der Übersicht
wurden die Daten- und Wertebereichstabellen visuell dargestellt.
Die Wertebereichstabellen werden vor allem für die Darstellung von Auswahlmöglichkeiten in Dropdown-Listenfeldern, sowie in SQL-Anweisungen zur Festlegung von gültigen Wertebereichen verwendet. Die Datentabellen werden während des Vorlesungsbetriebs mit Inhalt gefüllt, welcher durch Studenten, Tutoren und den Administrator über
die Weboberfläche der StudInfo{flex}-Veranstaltung eingegeben wird. Dazu zählen unter
anderem die persönlichen Daten von Studierenden, die Klausurteilnahme sowie erreichte
Punkte in den Übungen und Klausuren. Auf die Daten- und Wertebereichstabellen wird
über vielfältige SQL-Statements in den Konfigurationstabellen zugegriffen. Sie werden
vor allem für Abfragen und Berichte verwendet.
45
3 Sprachentwurf
Die wichtigsten Tabellenelemente, wie Name, Kommentar, Primärschlüssel und die Tabelle selbst, werden in den Sichten von Daten- und Wertebereichstabellen visuell dargestellt (Abbildung 30). Ein Kommentar, welcher den Inhalt der Tabelle beschreibt, wird
hier in grauer Schrift angezeigt, was bedeutet, dass dieser Kommentar auf der Weboberfläche nicht sichtbar ist. Vor dem Kommentar ist ein Symbol angebracht, welches
den Benutzer sofort erkennen lässt, dass es sich um einen Kommentar handelt. Weiter
unten wird der Primärschlüssel einer Tabelle angezeigt. Auch hier wurde ein Symbol,
in Form eines Schlüssels, platziert. So kann der Benutzer einer Tabelle besser erkennen,
um welche Tabellenelemente es sich handelt.
Abbildung 30: Konfiguration einer Datentabelle
Eine Datentabelle wird bei der Konfiguration einer neuen Veranstaltung nicht mit Werten gefüllt. Die Tabellenform wird durch das Einfügen von Spalten in eine horizontale
Liste erreicht. Dazu wurde das visuelle Muster einer Liste verwendet.
Die Wertebereichstabellen werden, im Gegensatz zur Datentabellen, mit Inhalt gefüllt
(Abbildung 31). Die Darstellung der Tabelle wurde hier durch das visuelle Muster einer
Matrix erreicht. Jeder Spalte ist ein SQL-Datentyp zugeordnet. Diese Eigenschaft gilt
dann ebenfalls für jede Zelle einer Spalte. So etwas konnte nicht durch andere visuelle
Muster erreicht werden.
46
3 Sprachentwurf
Abbildung 31: Konfiguration einer Wertebereichstabelle
3.11 Tutoren-Logins
Die Tutoren haben die Möglichkeit über das Tutorenmodul die Punkte für Übungsaufgaben zu vergeben und verschiedene E-Mails an Übungsgruppenteilnehmer zu verschicken. Um diese Aktivitäten durchführen zu können, werden die Daten von Tutoren, die
eine Übung einer StudInfo{flex}-Veranstaltung leiten, in einer Konfigurationstabelle angelegt. Hier werden Daten, wie Name, Vorname, E-Mail, Login und Passwort für jeden
Tutor gespeichert. Mit diesen Daten haben die Tutoren Zugriff auf das Tutorenmodul.
Wenn während des Vorlesungsbetriebs neue Übungsgruppen mit neuen Tutoren angeboten oder gestrichen werden, müssen in der Datenbank Tutoren angelegt bzw. gelöscht
werden. Um diese direkten Zugriffe auf die Datenbank zu vermeiden, wurden die Tutorendaten beim Entwurf der visuellen Sprache in ein eigenes Spezifikationsteil umgewandelt.
Über eine eigene Tutorusers-Sicht (Abbildung 32) kann der Administrator die Tutoren
mit dem Sprachelement Tutoruser“ anlegen oder direkt aus der Liste herauslöschen. So
”
wird vollständig vermieden, dass zur Konfiguration einer Veranstaltung direkt auf die
Datenbank zugegriffen werden muss.
47
3 Sprachentwurf
Abbildung 32: Tutorusers-Sicht
Zusammenfassung Dieses Kapitel hat die visuelle Sprache für das StudInfo{flex}System beschrieben. Mit dem Entwurf dieser Sprache wurde die zugehörige Benutzungsoberfläche StudInfo{flex}-Designer“ entwickelt. Diese bietet dem Benutzer die
”
Möglichkeit eine Veranstaltung zu konfigurieren, ohne direkt in die Datenbank eingreifen zu müssen. Dabei helfen viele Sprachelemente eine Konfiguration einfach und schnell
zu bearbeiten. Vor allem kann durch die Bildung von Aspekten einer Veranstaltung ein
besserer Überblick gewährt werden. Auch die Integration von Permissions in Aspekte
erlaubt eine gezielte Aktivierung von einzelnen Aspekten bzw. Aspektelementen. Das
Zusammenfügen von Datenerfassung und Typschlüssel in eine Sicht verhindert, dass
die Definition von wichtigen Elementen übersehen wird. In die Display-Sicht wurde das
Sprachelement Update integriert. Das erlaubt dem Benutzer den Aktualisierungsprozess
einfacher zu gestalten. Um die Zugriffe auf die Datenbank zu vermeiden, wurden auch
die Tutorendaten zu einem Spezifikationsteil zusammengefasst.
48
4 Realisierung
4 Realisierung
In diesem Kapitel wird auf einige interessante Teile der Implementierung der in Kapitel 3 vorgestellten visuellen Sprache eingegangen. Dabei wird als erstes ein Überblick
über den kompletten Ablauf einer Konfiguration gegeben. Danach wird die Generierung
von Datenbank-Schlüsseln erläutert und im darauf folgenden Abschnitt erklärt, wie eine
laufende Veranstaltung aktualisiert wird. Als letztes wird auf Konsistenzprüfungen eingegangen.
4.1 Konfigurationsprozess einer StudInfo{flex}- Veranstaltung
Abbildung 33 zeigt den Ablauf einer visuellen Konfiguration einer StudInfo{flex}-Veranstaltung. Zuerst muss der Benutzer über die Benutzeroberfläche des StudInfo{flex}Designers eine vordefinierte StudInfo{flex}-Standardvorlesung anpassen oder eine neue
StudInfo{flex}-Veranstaltung anlegen. Dazu nutzt er verschiedene Sprachelemente der
in dieser Diplomarbeit entworfenen visuellen Sprache für das StudInfo{flex}-System.
Als nächstes generiert der Benutzer den SQL-Code. Dieser enthält Konfigurations-,
Wertebereichs- und Datentabellen, die bisher vom Administrator direkt angepasst werden mussten. Der letzte Schritt ist das Importieren des SQL-Codes in das StudInfo{flex}System.
49
4 Realisierung
Abbildung 33: Ablauf der Konfiguration einer Veranstaltung
50
4 Realisierung
4.2 Generierung von Datenbankschlüsseln
Bei der bisherigen StudInfo{flex}-Konfiguration musste der Benutzer für Reports, Displayelemente und Phasen selbst die Identifikationsnummern (IDs) vergeben. Dabei muss
er immer darauf achten, dass die IDs für verschiedene Elemente eindeutig sind und sich
nicht wiederholen. Die IDs sind auch maßgeblich für die Reihenfolge, in der Informationen in Modulen präsentiert werden. Reports, Displayelemente und Phasen werden
aufsteigend nach IDs sortiert angezeigt. Damit der Benutzer die IDs nicht mehr pflegen
muss, wurde die Generierung automatisiert.
Für die Generierung von IDs wurde das LIDO Konstrukt CHAIN“ verwendet (Ab”
bildung 34). Mit Hilfe dieses Konstrukts werden die IDs automatisch vergeben. Dabei
wird an einer Klasse begonnen, dessen Elemente verschiedene IDs enthalten müssen
(in diesem Fall Report). Hier wird zunächst eine Startzahl definiert. Jetzt werden die
Klassenelemente von links nach rechts gezählt. Sie erhalten der Reihenfolge nach verschiedene Zahlen. Dies geschieht, indem für jedes neue Element eine fest definierte Zahl
aufaddiert wird. Wenn alle Elemente einer Klasse erfasst sind, kann garantiert werden,
dass die IDs eindeutig sind.
Abbildung 34: CHAIN-Konstrukt
4.3 Aktualisierbarkeit einer laufenden Veranstaltung
Der Benutzer hat auch im Vorlesungsbetrieb die Möglichkeit mit Hilfe von StudInfo{flex}Designer die Konfiguration zu ändern. Dabei werden nach dem Import des SQL-Codes
nicht alle Tabellen überschrieben. Die Konsistenz von Daten wird beibehalten.
51
4 Realisierung
Falls während der laufenden Vorlesung Änderungen an der Konfiguration getätigt werden müssen, die über die Weboberfläche des Administratormoduls nicht möglich sind,
werden diese mit Hilfe des StudInfo{flex}-Designers gemacht. Danach muss der SQLCode neu generiert und importiert werden. Beim Import in das StudInfo{flex}-System
werden alle bestehende Konfigurations- und Wertebereichstabellen der StudInfo{flex}Veranstaltung automatisch überschrieben. Die vorhandenen Datentabellen bleiben bestehen bzw. neue werden hinzugefügt.
Im Abschnitt 4.2 wurde die Generierung von IDs beschrieben. Die automatische Vergabe von IDs ist nur für Elemente aus Konfigurationstabellen sinnvoll. IDs werden neu
vergeben, wenn die Reihenfolge von Elementen in einer Konfigurationstabelle geändert
wird oder neue Elemente hinzukommen. Die IDs für Wertebereichstabellen müssen weiterhin per Hand eingegeben werden. Dies ist notwendig, weil Daten in Data-Tabellen
sich darauf beziehen. Würden die IDs für Wertebereichtabellen automatisch vergeben,
so würden sie sich ändern, wenn die Reihenfolge von Zeilen geändert wird oder neue
hinzugefügt werden. Die neu vergebenen IDs stimmen nicht mit denen, die in Datentabellen von Studenten gespeichert sind, überein. Zum Beispiel muss beim Anlegen des
Kontos am Anfang einer Veranstaltung ein Student einen Studiengang wählen. Dabei
wird die ID des gewählten Studienganges in der Datentabelle Data Student“ in der
”
Spalte Studiengang“ gespeichert. Wenn jedoch die Reihenfolge von Studiengängen in
”
der Tabelle Values Studiengang“ geändert wird, werden ebenfalls die IDs neu vergeben.
”
Das heißt, dass nach dem Import in den Studentendaten ein falscher Studiengang steht.
Die beschriebe Eigenschaft des Imports ermöglicht das Erhalten von bereits eingegebenen Daten von Studenten, Tutoren und dem Administrator. So kann der Administrator jederzeit problemlos Änderungen bei der laufenden Veranstaltung mittels des
StudInfo{flex}-Designers vornehmen.
4.4 Konsistenzprüfungen
Bei der herkömmlichen Konfiguration wurden die Werte einfach in Konfigurationstabellen geschrieben. Dabei treten häufig Eingabefehlern auf. Erst im Vorlesungsbetrieb
kann festgestellt werden, dass ein Element nicht richtig funktioniert und die Fehlersuche
beginnt. Beim Entwurf des StudInfo{flex}-Designers wurde versucht, auf die Eingabe
von Text durch den Benutzer zu verzichten. Da dies jedoch nicht möglich war, wurden
reichlich Tests definiert, welche eingegebene Daten auf Konsistenz prüfen. Einige davon
werden im Folgenden beschrieben.
Bei der Konfiguration einer Lehrveranstaltung kann der Benutzer neue Daten- und Wer-
52
4 Realisierung
tebereichstabellen mit eigenen Namen definieren. Dieser Name darf keine Leerzeichen
enthalten. Falls der Benutzer im Dialogfenster einen Namen mit Leerzeichen eingibt
und dies bestätigt, wird eine Fehlermeldung angezeigt, welche ihn auf unerlaubte Zeichen im Namen aufmerksam macht. Der Benutzer muss daraufhin den Tabellennamen
ändern. Analog wird die Eingabe von Spaltennamen geprüft.
Andere Konsistenzprüfungen sorgen dafür, dass in Eingabefelder bei der Definition von
Spalteneigenschaften nur zugelassene Zeichen eingefügt werden.
Bei der Konfiguration von Lehrveranstaltung muss der Benutzer oft bei vielen Elementen die Namen von Permissions, Tabellen, Spalten, Abfragen und Reports eingeben. Da
man sich diese Namen schlecht merken kann und eine manuelle Eingabe fehleranfällig
ist, können diese per Auswahlliste definiert werden (Abbildung 35). Die Auswahllisten
sind nur für Elemente dargestellt, die semantisch sinnvoll sind.
Bei der Definition von Elementeigenschaften dürfen einige Felder nicht leer gelassen
werden. Wenn der Benutzer die Pflichtfelder nicht ausfüllt oder nicht referenziert, dann
führt dies zu Fehlermeldungen, die auf unvollständige Angaben hinweisen.
53
4 Realisierung
Abbildung 35: Referenzen
54
5 Evaluation
5 Evaluation
In diesem Kapitel wird der in dieser Diplomarbeit entwickelte StudInfo{flex}-Designer
hinsichtlich Usability getestet. Dabei wird zunächst auf die Grundlagen der Evaluation
und Usability eingegangen. Danach wird beschrieben, wie der StudInfo{flex}-Designer
durch mehrere Probanden getestet und welche Ergebnisse erzielt wurden.
5.1 Grundlagen der Evaluation
Wottawa [10] definiert Evaluation als
das Sammeln und Kombinieren von Daten mit einem gewichteten Satz von
”
Skalen mit denen entweder vergleichende oder numerische Beurteilungen erlangt werden sollen“.
Evaluation von Software dient dazu, die Usability einer Benutzungsschnittstelle zu testen und zu verbessern.
Usability oder Benutzerfreundlichkeit ist definiert als die Effektivität, Effizienz und Zufriedenheit bei der Benutzung einer Anwendung. Die Effektivität beschreibt dabei, ob
der Benutzer mit dem StudInfo{flex}-Designer seine Ziele erreichen kann. Das Kriterium Effizienz betrifft den Aufwand, der zum Erreichen des Ziels nötig ist. Ziel ist es, den
Aufwand für die Problemlösung möglichst gering zu halten. So sollen möglichst wenig
Schritte zu einer konfigurierten StudInfo{flex}-Veranstaltung führen. Bei dem Kriterium
Zufriedenheit wird einbezogen, ob der Benutzer den visuellen StudInfo{flex}-Designer
für die Konfiguration von Lehrveranstaltungen gut, angemessen und zufriedenstellend
findet [11].
Wenn alle drei Kriterien Effektivität, Effizienz und Zufriedenheit für einen bestimmten Nutzungskontext des StudInfo{flex}-Designers erfüllt sind, kann der StudInfo{flex}Designer als eine benutzerfreundliche Anwendung betrachtet werden.
Baumgartner [12] hat bei der Durchführung einer Evaluation vier Phasen vorgeschlagen:
1. Formulierung von Wertekriterien: Kriterien werden ausgewählt und definiert,
die das Produkt erfüllen muss, um als gut, wertvoll usw. gelten zu können.
2. Formulierung von Leistungsstandards: Für die oben eingeführten Kriterien
wird eine Norm definiert, die das Produkt erreichen muss, damit das Kriterium als
erfüllt angesehen werden kann.
55
5 Evaluation
3. Messung und Vergleich (Analyse): Das Produkt wird unter Anwendung der
Kriterien untersucht, gemessen und mit den vorgegebenen Leistungsstandards verglichen.
4. Werturteil (Synthese): In dieser letzten Phase werden die verschiedenen Ergebnisse zu einem einheitlichen Werturteil verknüpft.
5.2 Umsetzung der Standardveranstaltung
Beim Entwurf der visuellen Sprache wurde jedes Sprachelement anhand eines Beispieles
auf seine Funktionalität getestet. Abschließend wurde eine komplette Standardveranstaltung umgesetzt, welche als Ausgangspunkt für den Usability-Test diente. Die Konfiguration wurde auch durch einen Mitarbeiter der Arbeitsgruppe Programmiersprachen
”
und Übersetzer“ getestet und hat sich als stabil, zuverlässig und flexibel erwiesen.
Die umgesetzte Standardveranstaltung bietet Übungen, drei schriftliche Klausuren und
eine Wunschvorlesung an. In Übungsgruppen werden die Aufgaben zur Vorlesung bearbeitet. Die Standardveranstaltung bietet ein Bonusmodell an. Dabei haben die Studenten die Möglichkeit die Übungszettel allein oder in Gruppen zu lösen und bei Tutoren
abzugeben. Pro Übungszettel wird eine bestimmte Anzahl von Punkten vergeben. Die
Lösungen werden korrigiert und die erreichten Punkte den Studenten gutgeschrieben.
Der Student hat die Möglichkeit sich zu Klausuren an- bzw. abzumelden. Am Ende
der Vorlesung werden die Übungspunkte zusammengezählt und ein Klausurnotenschritt
ausgerechtet. Die Klausurnote wird dann um diesen Notenschritt verbessert. Eine Standardveranstaltung bietet ebenfalls eine Wunschvorlesung. Dabei können die Studenten
im Vorlesungsbetrieb drei Wunschthemen wählen, welche sie gern hören wollen. Das am
meisten gewünschte Thema wird in der Vorlesung vorgestellt.
5.3 Kontrolliertes Experiment
Mit der Evaluation wird untersucht, wie bequem der Benutzer eine Veranstaltung mit
dem StudInfo{flex}-Designer konfigurieren und ob er alle Aufgabe bewältigen kann. Die
Zielfragestellungen lauten deshalb:
• Wie einfach lässt sich eine neue StudInfo{flex}-Veranstaltung aus einer StudInfo{flex}-Standardveranstaltung konfigurieren?
• Wie einfach lässt sich eine bestehende StudInfo{flex}-Standardveranstaltung ändern?
56
5 Evaluation
• Macht der Benutzer bei der Konfiguration viele Fehler?
• Können auch Anfänger die StudInfo{flex}-Veranstaltung konfigurieren?
• Wo liegen Schwächen des StudInfo{flex}-Designers?
Es werden in der Literatur viele verschiedene Methoden zur Usability-Evaluation beschrieben. Zum Testen des StudInfo{flex}-Designers wurde ein kontrolliertes Experiment
und ein nachfolgendes Interview durchgeführt. Bei einem kontrollierten Experiment löst
eine Testperson, allein und nur mit wenig Hilfestellung, unter genau kontrollierten Bedingungen bestimmte Aufgaben mit dem StudInfo{flex}-Designer. Diese Methode soll
zeigen, dass Veranstaltungen mit dem StudInfo{flex}-Designer einfach konfiguriert und
geändert werden können. Dabei wurde beobachtet, wie das Ziel erreicht und wo die Testpersonen Fehler machten bzw. Hilfe benötigten. Die Testpersonen wurden abschließend
mittels eines Fragenkatalogs befragt.
Der StudInfo{flex}-Designer wurde durch drei Probanden getestet. Dabei hatten alle
drei Tester keine Erfahrungen im Bereich der Konfiguration von Lehrveranstaltungen.
Sie kannten nur die Weboberfläche des Studierendenmoduls.
Vor dem Test wurde eine Einführung zu visuellen Sprachen, DEViL und zum StudInfo{flex}-System von ca. 30 Minuten gegeben.
Die Testpersonen mussten drei Aufgaben absolvieren. Die erste Aufgabe bestand aus
mehreren Teilen. Die Testpersonen mussten eine neue Grundkonfigurationsvariable anlegen und benennen. Dabei sollten sie den richtigen Spezifikationsteil finden, in dem die
Grundkonfigurationsvariablen definiert werden. Als nächstes mussten die Testpersonen
einen neuen Tutor mit seinen Daten anlegen. Des Weiteren gab es einige Änderungen
bei einem Aspekt, die sie durchführen mussten. Der letzte Teil der ersten Aufgabe war
das Anlegen einer neuen Phase.
Die zweite Aufgabe bestand darin, einen Aspekt zu löschen und zu importieren. Die
Schwierigkeit war dabei, dass die Testpersonen nach dem Löschen bzw. Importieren alle
Aspekte und gegebenenfalls die Phases-Sicht anpassen mussten. Das war notwendig, weil
die übrigen Aspekte Tabellen aus dem gelöschten Aspekt für die Abfragen verwenden.
Bei der dritten Aufgabe mussten die Testpersonen aus einer StudInfo{flex}-Standardveranstaltung eine neue StudInfo{flex}-Veranstaltung konfigurieren. Dabei sollen sie folgende Änderungen durchführen:
• neuen Namen der Vorlesung, Namen des Professors und Semester vergeben
57
5 Evaluation
• neue Zeiten für Übungsgruppen eintragen
• neue Klausurtermine anlegen.
Nach Bearbeitung der Aufgaben wurden den Testpersonen einige Fragen gestellt. Sie
konnten auf einer 5-stufigen Likert-Skala beantwortet werden, bei der sich zwei gegensätzliche Extremaussagen gegenüberstehen. Die linke Seite wird mit der Note 1 (sehr
gut), die rechte Seite mit der Note 5 (schlecht) bewertet.
Die Tabelle in Abbildung 36 zeigt die Mittelwerte, welche bei der Bearbeitung von drei
Aufgaben entstanden sind. Erkennbar ist, dass die Anpassungen bei der ersten Aufgabe
sehr schnell durchgeführt worden sind. Zu beachten ist, dass alle Testpersonen vorher nie
eine StudInfo{flex}-Veranstaltung konfiguriert hatten. Bei der zweiten Aufgabe hatten
die Testpersonen Schwierigkeiten bei der Suche nach Tabellennamen in SQL-Abfragen,
weil sich keiner von ihnen mit der Standardkonfiguration auskannte. Die dritte Aufgabe
wurde ohne Hilfe mit Leichtigkeit erledigt.
Abbildung 36: Zeitverbrauch bei der Bearbeitung der Aufgaben
Nach dem alle Aufgaben gelöst waren, wurden die Testpersonen befragt. Dabei wurden
die Fragen im Durchschnitt wie folgt beantwortet:
58
5 Evaluation
Abbildung 37: Fragen und Antworten beim Interview
Die Ergebnisse des kontrollierten Experiments sowie die Befragung ergaben, dass
viele Änderungen mit dem StudInfo{flex}-Designer einfach durchzuführen sind. Der
StudInfo{flex}-Designer enthält eine konfigurierte Standardveranstaltung. Darum
braucht der Benutzer nur wenige Anpassungen zu tätigen, um daraus eine neue ähnliche
Vorlesung zu erstellen. Schwierigkeiten gab es beim Löschen bzw. Importieren von
Aspekten. Das lag daran, dass diese Aspekte auf Tabellen aus anderen Aspekten
zugegriffen haben. Beim Löschen muss dem Benutzer bekannt sein, ob andere Aspekte
die Tabellen aus dem gelöschten Aspekt nutzen. Beim Importieren eines Aspekts aus
anderen Konfigurationen muss geprüft werden, ob alle Tabellen, auf welche dieser
zugreift, wirklich vorhanden sind oder ob sie umbenannt bzw. neue angelegt werden
müssen. Die zweitschlechteste Note von 3,8 kam zustande beim Anlegen neuer Aspekte.
Dies erfordert Kenntnisse über die Konfiguration von Veranstaltungen. Da keine
Testperson vorher Lehrveranstaltungen konfigurierte, wurde diese Aufgabe nur schwer
bewältigt.
Die Evaluation hat gezeigt, dass die Konfiguration von Lehrveranstaltungen mit
dem StudInfo{flex}-Designer auch von Anfängern durchgeführt werden kann. Mit
einigen Erklärungen zur visuellen Oberfläche und zum StudInfo{flex}-System können
Änderungen schnell und einfach getätigt werden. Die Testpersonen fanden die Bedienung der Benutzungsoberfläche leicht verständlich und intuitiv. Die Sprachelemente des
StudInfo{flex}-Designer waren selbsterklärend. Bei der Bearbeitung von Aufgaben haben sie die Darstellung von Elementen als gut, überschaubar und einheitlich befunden.
Die Wiederverwendung von Aspekten und deren Elemente wurde eingesetzt und als
benutzerfreundlich eingestuft. Die einheitliche Darstellung der Benutzungsoberfläche
59
5 Evaluation
des StudInfo{flex}-Designers und des StudInfo{flex}-Systems erlaubt einen fließenden
Übergang zwischen beiden Anwendungen.
60
6 Zusammenfassung
6 Zusammenfassung
In dieser Diplomarbeit wurde eine visuelle Sprache und eine zugehörige Benutzungsoberfläche, der StudInfo{flex}-Designer, zur Konfiguration von StudInfo{flex}-Veranstaltungen entwickelt. Der Benutzer kann hiermit die gesamte Konfiguration visuell erstellen
und muss nicht mehr direkt auf die Datenbanktabellen zugreifen. Die Benutzungsoberfläche ist übersichtlich, einfach und intuitiv benutzbar. Das Einfügen von inkonsistenten
Eingaben durch den Benutzer wurde durch viele Konsistenzprüfungen verhindert.
Die Konfiguration lässt sich in einzelne Aspekte zerlegen. Sie bilden die Hauptteile einer Vorlesung. Dank der Aspekte erhält der Benutzer einen guten Überblick
über die Konfiguration und die zur Verfügung stehenden Elemente. Beim Anlegen
von Aspekten wird dem Benutzer eine Liste mit Elementen angezeigt, welche definiert
werden müssen. Diese können bequem und intuitiv in einzelnen Sichten bearbeitet
werden. Die Wiederverwendung von Aspekten und Aspektelementen ist besonders
vorteilhaft bei der Konfiguration neuer Veranstaltungen. Bei der Bildung von Aspekten
wurden die Permissions in diese integriert, was dem Benutzer einen zusätzlichen Vorteil
bietet. Bei der Definition einer Phase werden die Permissions aus einzelnen Aspekten
verwendet. Das führt dazu, dass die einzelnen Aspekte gezielt aktiviert werden können.
Bei dem Entwurf der graphischen Benutzungsoberfläche für StudInfo{flex}Designer wurden einige Darstellungen aus den Webseiten des StudInfo{flex}-Systems
übernommen. Es gab jedoch nicht für alle Sprachelemente im StudInfo{flex}-Designer
einen Pendant auf der Webseite. Deshalb wurden neue Sprachelemente im Designer an
die Weboberfläche angepasst.
Die entworfene visuelle Sprache wurde auf ihre Konsistenz und Korrektheit hin
untersucht. Es wurde eine komplette StudInfo{flex}-Standardveranstaltung über die
graphische Benutzungsoberfläche konfiguriert. Auch eine benutzerdefinierte Vorlesung
mit mündlichen Prüfungen, anstelle von drei schriftlichen Klausuren, konnte mit
der entworfenen visuellen Sprache erstellt werden. Weiterhin wurde eine Evaluation
durchgeführt, welche den StudInfo{flex}-Designer auf Usability untersuchte. Durch
die Evaluation wurden die Schwachpunkte der visuellen Sprache erkannt und verbessert. Vor allem gab es Verbesserungen im Bereich der Konsistenzprüfungen. In
einem kontrollierten Experiment konnte gezeigt werden, dass Lehrveranstaltungen mit
dem StudInfo{flex}-Designer auch durch Benutzer mit nur wenigen Vorkenntnissen
konfiguriert werden können.
61
Abbildungsverzeichnis
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Schweigen“ . . . . . . . . . . . . . . . . . . . . . . . . . .
”
Klassifikation für visuelle Programmierung nach Shu . . . .
Generierung der visuellen Entwicklungsumgebung . . . . .
Visuelle Sicht einer Datentabelle . . . . . . . . . . . . . . .
Spezifikation der abstrakten Struktur . . . . . . . . . . . .
Visuelle Muster . . . . . . . . . . . . . . . . . . . . . . . .
Generische Zeichnung . . . . . . . . . . . . . . . . . . . . .
Datenbank einer Standardveranstaltung . . . . . . . . . .
Tabelle aus der Datenbank . . . . . . . . . . . . . . . . . .
Benutzungssebenen des StudInfo{flex}-Systems . . . . . .
Aktuelle Grundkonfiguration . . . . . . . . . . . . . . . . .
Auswahlliste von möglichen Studiengängen . . . . . . . . .
Aktivierung von Phasen . . . . . . . . . . . . . . . . . . .
Grundkonfigurationsvariablen einer Standardveranstaltung
Formular zum Anlegen eines Kontos . . . . . . . . . . . . .
Hauptsicht der StudInfo{flex}-Standardvorlesung . . . . .
Aspect-Sicht . . . . . . . . . . . . . . . . . . . . . . . . . .
Herkömmliche Konfiguration von Display . . . . . . . . . .
Display mit Updates . . . . . . . . . . . . . . . . . . . . .
Display mit persönlichen Daten . . . . . . . . . . . . . . .
Auswirkungen von Update Nachname“ . . . . . . . . . .
”
Datenerfassungssicht . . . . . . . . . . . . . . . . . . . . .
Manuelle Eingabe von Übungspunkten . . . . . . . . . . .
Phasenschalter . . . . . . . . . . . . . . . . . . . . . . . .
Permissions . . . . . . . . . . . . . . . . . . . . . . . . . .
Referenz auf eine Permission bei Abfrage . . . . . . . . . .
Konfigurationstabelle mit Abfragen . . . . . . . . . . . . .
Query-Sicht . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konfiguration einer Datentabelle . . . . . . . . . . . . . .
Konfiguration einer Wertebereichstabelle . . . . . . . . . .
Tutorusers-Sicht . . . . . . . . . . . . . . . . . . . . . . . .
Ablauf der Konfiguration einer Veranstaltung . . . . . . .
CHAIN-Konstrukt . . . . . . . . . . . . . . . . . . . . . .
Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zeitverbrauch bei der Bearbeitung der Aufgaben . . . . . .
Fragen und Antworten beim Interview . . . . . . . . . . .
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
8
10
10
13
14
15
19
19
20
21
24
25
26
27
30
32
34
35
36
36
38
39
40
40
41
42
43
45
46
47
48
50
51
54
58
59
Literatur
Literatur
[1] DEViL (Development Environment for Visual Languages) Online: http://agkastens.uni-paderborn.de/forschung/devil/index.php
[2] S. Schiffer: Visuelle Programmierung, Addison-Wesley-Longman Verlag, 1998
[3] Carsten Schmidt, Uwe Kastens: Implementation of visual languages using patternbased spezifications, Software - Practice and Experience, 33:1471-1505, 2003
[4] Daniel Warner: StudInfo{flex}-Dokumentation, 2005
[5] Andreas Knauer, Christopher Kristes: Aspektorientierte Programmierung: AspectJ und HyperJ, Köln, 2004; http://www.gm.fh-koeln.de/ẽhses/
seminar/ergebnisse03/Aspektorientierte-Programmierung/ausarbeitung.pdf
[6] Newsletter vom 21.06.2004: Aspektorientierte Programmierung - Zur Architektur
Objektorientierter Anwendungen: http://www.it-fws.de/publics/aop062004.pdf
[7] Aspektorientierte Programmierung: http://www.computerbase.de/lexikon/Aspektorientierte Programmierung
[8] Thomas Baustert: AOP in Kürze; http://www.software-coach.de/swdev/aop/aopkurz/, April 2004
[9] Crosscutting Concerns - Warum Objektorientierung manchmal nicht ausreicht
http://wwwse.fhs-hagenberg.ac.at/se/berufspraktika/2002/se99047/contents/german/aop.html
[10] Wottawa, H.: Evaluation, Weinheim : Beltz PVU, 2001
[11] Frank Tissen: Screen-Design Handbuch, Springer Verlag, 2003
[12] Baumgartner, P.: 10 Testmethoden in der Evaluation interaktiver Lehr- und Lernmedien, Waxmann Verlag, 1999
[13] Krienke, R.: Programmieren in Perl, Hanser, 2002
[14] Bastian Cramer: Generierung von graphischen Struktureditoren aus visuellen Spezifikationen, Diplomarbeit, 2005
63
Eidesstattliche Erklärung
Ich versichere, dass ich diese Diplomarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt habe. Alle
Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche
gekennzeichnet.
————————————————————————————————————
Ort, Datum
Unterschrift

Ausarbeitung - Universität Paderborn

Transcription

Similar documents

fortran - Department of Information Systems

Fristenübersicht

Berufsträume Rêves de profession - Schule für Gestaltung Bern und

ERASMUS-Erfahrungsbericht 1. Vorbereitung

DSML`08 Domain-Specific Modeling Languages - CEUR

PDF zum

sound vision 2005/06

Falk Navigator 7 Benutzerhandbuch - Falk

Technische Universität Darmstadt

Das Technikgebiet XML: Herkunft, praktische Anwendung

Folien - Institut für Computerlinguistik