scieee Science in your language
[en] (orig)
Entwurf und Implementierung einer
vollst¨
andigen Infrastruktur f¨
ur
modulare E-Learning-Inhalte
Zur Erlangung des akademischen Grades
DOKTORINGENIEUR (Dr.-Ing.)
der Fakult¨
at f¨
ur Elektrotechnik, Informatik und Mathematik
der Universit¨
at Paderborn
vorgelegte Dissertation
von
Dipl.-Inform. Michael Bungenstock
aus Hamburg
Referent: Prof. Dr.-Ing. B¨
arbel Mertsching
Korreferent: Prof. Dr.-Ing. Reinhard Keil-Slawik
Tag der m¨
undlichen Pr¨
ufung: ............
6.4.2006
Paderborn, den 18.4.2006
Diss. 14/219
Kurzfassung
Mit dem Einzug des E-Learnings in Lehre und Ausbildung haben sich neue Anforderungen an
die IT-Infrastrukturen ergeben, die mit den verf¨
ugbaren Techniken nicht ad¨
aquat gel¨
ost wer-
den k¨
onnen. Viele der neuen Teilaspekte, wie z.B. Lernobjekte, Metadaten und Kodierungen,
werden zwar in wissenschaftlichen Arbeiten und Spezifikationen behandelt, aber leider fehlen
die Zusammenh¨
ange f¨
ur die Implementierung eines vollst¨
andigen Systems. Hierdurch werden
Seiteneffekte und Abh¨
angigkeiten ignoriert, die in der Praxis zu essentiellen Problemen f¨
uhren
und propriet¨
are L¨
osungen hervorbringen. Der Akzeptanz von E-Learning ist diese Entwicklung
abtr¨
aglich, denn inkompatible E-Learning-Inhalte verursachen Kosten durch Konvertierung
oder Neuentwicklung und mindern die Bereitschaft zur Verwendung. Die Verf¨
ugbarkeit von
Inhalten beim E-Learning als wesentlicher Vorteil gegen¨
uber konventionellen Formen wird auf
diese Weise leider aufgehoben.
In dieser Arbeit wird ein ganzheitliches Konzept f¨
ur modulare E-Learning-Inhalte herge-
leitet und als praktische Anwendung realisiert. Als Grundlage dienen andere wissenschaftliche
Arbeiten, die bereits wichtige und allgemein akzeptierte Ergebnisse hervorgebracht haben. Sie
werden miteinander verbunden oder durch neue Konzepte erg¨
anzt. Ein wesentliches Merkmal
dieser Arbeit ist die Verwendung der Metaphern ”multimedialer Baukasten“ und ”Baustein“,
die als Leitbild f¨
ur alle Entscheidungen dienen. Sie vereinfachen den Entwurf der einzelnen
Komponenten und pr¨
agen die sp¨
atere Benutzung des Systems. Hierdurch tragen die Metaphern
zur Konsistenz und Vollst¨
andigkeit der Infrastruktur bei.
Entwurf und Umsetzung erfolgen in dieser Arbeit objektorientiert und bedienen sich der
g¨
angigen Mittel der Softwaretechnik. Aus Sicht der Benutzer/-innen wird ein fachliches Modell
beschrieben, das durch Komponentenbildung in ein technisches ¨
uberf¨
uhrt wird. Eine geringe
Abh¨
angigkeit gekoppelt mit einer hohen Koh¨
asion der Funktionen soll eine gute Skalierbarkeit
f¨
ur die unterschiedlichsten Einsatzgebiete garantieren. Durch die Flexibilit¨
at dieses Rahmen-
werks lassen sich Einzelplatzl¨
osungen genauso wie verteilte Anwendungen realisieren. Zur De-
monstration werden in dieser Arbeit das Autorenwerkzeug Lyssa und ein Repository f¨
ur die
zentrale Datenhaltung entwickelt und in der Programmiersprache Java implementiert.
Das Rahmenwerk ist so konzipiert, dass es heutigen Standards entspricht und auch zuk¨
unf-
tigen Entwicklungen gerecht wird. Ein Anliegen dieser Arbeit ist die Kompatibilit¨
at zu anderen
Systemen, um eine breite Akzeptanz zu erreichen. Hierf¨
ur werden neben den Kodierungen in
Standardformaten auch Konstruktionen zur Konvertierung auf Ebene der Standards, z.B. bei
den Metadaten zwischen IEEE LOM und Dublin Core, sowie auf konzeptioneller Ebene, z.B.
von verschachtelten zu einfachen Lernobjekten, vorgestellt. Denn die Wiederverwendbarkeit
und die Vielseitigkeit von Inhalten geh¨
oren neben den multimedialen M¨
oglichkeiten zu den
herausragenden St¨
arken des E-Learnings. Mit dem Rahmenwerk dieser Arbeit sind nun die
technischen Voraussetzungen geschaffen.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Problemstellung.................................... 2
1.2 Zielsetzung ...................................... 3
1.3 Methodik ....................................... 4
1.4 Systematik ...................................... 4
I Stand der Wissenschaft 7
2 Lerntheorie 9
2.1 Kompetenzstufen................................... 9
2.2 Lernparadigmen ................................... 10
2.2.1 Behaviorismus ................................ 10
2.2.2 Kognitivismus ................................ 11
2.2.3 Konstruktivismus............................... 12
2.3 Lehrer/-in, Tutor/-in und Coach . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Ein heuristisches Lernmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 E-Learning-Historie.................................. 14
3 Lernobjekte 17
3.1 Warum werden Lernobjekte ben¨
otigt? ....................... 17
3.2 WasisteinLernobjekt? ............................... 18
3.2.1 Lernobjekte nach Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Lernobjekte nach Hodgins . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Lernobjekte nach Wiley . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4 Lernobjekte nach Downes . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5 Lernobjekte nach Baumgartner . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Granularit¨
at...................................... 23
3.4 Sequenzierung..................................... 25
3.5 IMS Content Packaging Specification . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Sharable Content Object Reference Model . . . . . . . . . . . . . . . . . . . . . 30
3.7 Formate........................................ 31
4 Metadaten 33
4.1 Resource Description Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 DublinCoreMetadata................................ 40
4.3 Learning Object Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Autorenwerkzeuge 45
5.1 Klassifizierung .................................... 45
5.1.1 Professionelle Autorenwerkzeuge . . . . . . . . . . . . . . . . . . . . . . 46
5.1.2 WYSIWYG-HTML-Editoren . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1.3 ContentConverter .............................. 49
ii INHALTSVERZEICHNIS
5.1.4 Live Recording Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.5 Screen Movie Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.6 Rapid E-Learning Content Development . . . . . . . . . . . . . . . . . . 51
5.2 Bewertung....................................... 51
6 Lernplattformen 57
6.1 Definitionen...................................... 58
6.2 Evaluation....................................... 60
6.2.1 Blackboard .................................. 61
6.2.2 WebCT .................................... 61
6.2.3 SmartBLU .................................. 64
6.3 Bewertung....................................... 64
7 Web-Technologie 67
7.1 Infrastruktur ..................................... 68
7.2 WebApplications................................... 72
7.3 WebServices ..................................... 73
7.4 WebDAV ....................................... 75
8 Metapher 77
8.1 MetaphorischerProzess ............................... 77
8.2 Metaphern und Software-Technik . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9 Bewertung 81
9.1 Res¨
umee........................................ 82
II Entwurf 83
10 System-Vision 85
10.1 Rollen und Anwendungsf¨
alle............................. 86
10.1.1Author .................................... 87
10.1.2Developer................................... 88
10.1.3Composer................................... 89
10.1.4Publisher ................................... 90
10.1.5User...................................... 91
10.1.6Student .................................... 91
10.1.7Professor ................................... 92
10.1.8Administrator................................. 92
10.2Komponenten..................................... 93
10.2.1Basis...................................... 94
10.2.2 Learning Object Development . . . . . . . . . . . . . . . . . . . . . . . . 94
10.2.3 Structure Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
10.2.4 Publishing Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10.2.5UserEnvironment .............................. 98
10.2.6Administration................................ 99
10.3Architektur ......................................100
10.4Baukasten-Metapher.................................106
10.4.1 Metaphorischer Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
10.5Aufteilung.......................................107
INHALTSVERZEICHNIS iii
11 Basiskomponenten 109
11.1Dateizugriff ......................................110
11.1.1 Dateisystem Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.1.2 Virtuelles Dateisystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.2Metadaten.......................................119
11.2.1Datenstruktur ................................121
11.2.2Operationen..................................124
11.2.3Kodierungen .................................126
11.3 Unterst¨
utzungvonMultimedia ...........................127
12 Baustein und Kurs 133
12.1BindunganStandards................................133
12.2PhysikalischeDateien ................................136
12.3Manifest........................................138
12.4ContentPackage ...................................143
13 Rahmenwerk 147
13.1 Zusammengesetzte Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 148
III Implementierung 151
14 Baukasten 153
14.1Script-Steuerung ...................................154
14.2 Grafische Basiskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.3 Rahmenwerk f¨
urWerkzeuge.............................157
14.4 Visualisierung der Bausteine und Kurse . . . . . . . . . . . . . . . . . . . . . . 159
14.5SteuerungdesExports................................162
14.6Lyssa .........................................163
15 Repository 167
15.1 Construction Kit Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
15.2 Web-Oberfl¨
ache....................................169
IV Analyse 171
16 Ausgew¨
ahlte Beispiele 173
16.1 Erstellung neuer Bausteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
16.2ErstellungneuerKurse................................175
16.3Inhaltepublizieren ..................................177
16.4Explorationsumgebung................................179
17 Zusammenfassung und Bewertung 183
18 Ausblick 185
Abbildungsverzeichnis
1.1 Das B¨
ucherrad.................................... 2
2.1 Schematisches Modell des Behaviorismus [Baumgartner99, S.102] . . . . . . . 11
2.2 Schematisches Modell des Kognitivismus [Baumgartner99, S.105] . . . . . . . 12
2.3 Schematisches Modell des Konstruktivismus [Baumgartner99, S.108] . . . . . . 12
2.4 Drei Lehrmodelle [Baumgartner97] . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Ein heuristisches Lernmodell [Baumgartner99, S.96] . . . . . . . . . . . . . . . 14
2.6 Entwicklung der computerunterst¨
utzten Ausbildung nach [Bodendorf90, S.15] 15
2.7 Begriffsbildung von WBT und CBT nach [Kerres98, S.14] . . . . . . . . . . . 15
3.1 RLO-RIO-Struktur ................................. 19
3.2 Lernobjekt-Hierarchie nach [Hodgins00, S. 28] . . . . . . . . . . . . . . . . . . 20
3.3 Reusable Learning Objects nach [Baumgartner02b, S. 24] . . . . . . . . . . . . 23
3.4 Lernobjekt-Hierarchie aus [Hodgins02, S. 78] . . . . . . . . . . . . . . . . . . . 24
3.5 Linear-sukzessive Sequenzierung und Spiral-Sequenzierung nach [Reigeluth99,
S.432] ........................................ 26
3.6 Die verschiedenen Bereiche innerhalb eines Packages [IMS04a] . . . . . . . . . 27
3.7 Datenstruktur eines Manifests [IMS04a] . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Einfache Aufl¨
osungvonReferenzen ........................ 29
3.9 Aufl¨
osung von Referenzen mit Subknoten . . . . . . . . . . . . . . . . . . . . . 29
3.10 Runtime Environment aus [Dodd04b, S. 1-8] . . . . . . . . . . . . . . . . . . . 30
4.1 Schichten f¨
ur Metadaten-Umsetzung nach [Baker03, S. 6] . . . . . . . . . . . . 35
4.2 RDF-Graph f¨
ur den Mitarbeiter Michael Bungenstock . . . . . . . . . . . . . 37
4.3 RDF-Graph mit Ressourcen und Literalen . . . . . . . . . . . . . . . . . . . . 37
4.4 RDF-Graph mit typisierten Literalen . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 StrukturierteAdresse................................ 39
4.6 Beispiele f¨
ur Strukturen in LOM (von [IEE02a] abgeleitet) . . . . . . . . . . . 42
4.7 Aufbau von LOM als Baum nach [IMS03b] . . . . . . . . . . . . . . . . . . . . 43
5.1 Systematik der Autorenwerkzeuge [H¨
afele03]................... 46
5.2 Macromedia Authorware 7 ............................. 47
5.3 Macromedia CourseBuilder-Erweiterung f¨
ur Dreamweaver ........... 48
5.4 Einsatz von Lecturnity (Aus einer Werbebrosch¨
ure)............... 50
5.5 Screenshot von Lectora ............................... 52
6.1 Idealtypische Architektur einer Lernplattform nach [Schulmeister03, S. 11] . . 59
6.2 Screenshot von Blackboard ............................. 62
6.3 Screenshot von WebCT ............................... 63
6.4 Screenshot von SmartBLU ............................. 65
7.1 Schichten von J2EE-Anwendungen [Bodoff04, S. 3] . . . . . . . . . . . . . . . 68
7.2 Client und Server [Bodoff04, S. 6] . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.3 Sechs Schritte einer Anfrage [Bodoff04, S. 84] . . . . . . . . . . . . . . . . . . 70
vi ABBILDUNGSVERZEICHNIS
7.4 Schichten der Repr¨
asentation [Bodoff04, S. 85] . . . . . . . . . . . . . . . . . . 70
7.5 Interne Modulstruktur [Bodoff04, S. 90] . . . . . . . . . . . . . . . . . . . . . . 71
7.6 Model,View und Controller f¨
ur Web Applications ................ 72
7.7 JAX-RPC-Aufruf [Bodoff04, S. 321] . . . . . . . . . . . . . . . . . . . . . . . . 75
8.1 Metaphorischer Prozess nach [Busch98, S. 25] . . . . . . . . . . . . . . . . . . 78
10.1 ¨
UbersichtderRollen ................................ 87
10.2 Anwendungsf¨
alle der Rolle Author ......................... 88
10.3 Anwendungsf¨
alle der Rolle Developer ....................... 89
10.4 Anwendungsf¨
alle der Rolle Composer ....................... 90
10.5 Anwendungsf¨
alle der Rolle Publisher ....................... 91
10.6 Anwendungsf¨
alle der Rolle User .......................... 91
10.7 Anwendungsf¨
alle der Rolle Student ........................ 92
10.8 Anwendungsf¨
alle der Rolle Professor ....................... 93
10.9 Anwendungsf¨
alle der Rolle Administrator ..................... 93
10.10 Komponenten f¨
ur die Rolle Author ........................ 94
10.11 Komponente f¨
ur die Rolle Developer ....................... 95
10.12 Komponente f¨
ur die Rolle Composer ....................... 96
10.13 Komponente f¨
ur die Rolle Publisher ........................ 97
10.14 Komponente f¨
ur die Rolle User .......................... 98
10.15 Komponente f¨
ur die Rolle Administrator ..................... 99
10.16 Funktionale Komponente des Autorensystems . . . . . . . . . . . . . . . . . . 101
10.17 Zwei Komponenten zur Steuerung des Autorensystems . . . . . . . . . . . . . 101
10.18 Komponente f¨
ur die zentrale Datenhaltung (Repository) . . . . . . . . . . . . 102
10.19 Komponente f¨
ur den Web-basierten Zugriff auf das Repository .........103
10.20 Zugriff der Autoren/-innen auf das Repository ..................103
10.21 Komponente f¨
ur den Web-basierten Zugriff auf die Lernplattform . . . . . . . 104
10.22 Zugriff der Benutzer/-innen auf die Lernplattform und das Repository . . . . . 104
10.23 Vollst¨
andige Architektur des Systems . . . . . . . . . . . . . . . . . . . . . . . 105
11.1 Extended Filesystem Architecture [Sun99].....................111
11.2 Aufbau von Verzeichniseintr¨
agen aus [Tanenbaum97, S. 411] . . . . . . . . . . 112
11.3 Ein UNIX Verzeichnisbaum aus [Tanenbaum97, S. 414] . . . . . . . . . . . . . 113
11.4 Interne Abbildungen im VFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.5 Aufbau der Dateistruktur in zwei Schritten . . . . . . . . . . . . . . . . . . . . 115
11.6 Beispiel f¨
urdenAufbaudesVFS .........................116
11.7 Klasse VFSNode ...................................117
11.8 Verschiedene Unterklassen der Klasse VFSNode ..................117
11.9 Klasse VFS ......................................118
11.10 Verschiedene Unterklassen der Klasse VFS ....................118
11.11 Dateistruktur im Arbeitsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.12 Aggregation von String und VFS .........................119
11.13 Bildung der Komponente File Management ...................119
11.14 Architektur f¨
ur heterogene Metadatenformate . . . . . . . . . . . . . . . . . . 120
11.15 Klassenhierarchien der Reader und Writer ....................121
11.16Metadatenkategorien ................................122
11.17 Produktion der internen Metadatenstruktur . . . . . . . . . . . . . . . . . . . 124
11.18 Manipulation der internen Metadatenstruktur . . . . . . . . . . . . . . . . . . 125
11.19 Datenbankschema f¨
ur die Kategorie ”General“ aus [Turan04] . . . . . . . . . . 128
11.20 Bildung der Komponente Metadata ........................128
11.21 Interfaces f¨
ur den Zugriff und die Erstellung von Dateien . . . . . . . . . . . . 130
11.22 Drei Handler ....................................130
ABBILDUNGSVERZEICHNIS vii
11.23 Klasse MimeTypeHandler ..............................131
11.24 Klasse MimeTypeMap .................................131
11.25 Objektdiagramm mit zwei unterst¨
utzen MIME-Types . . . . . . . . . . . . . . 132
11.26 Bildung der Komponente Multimedia Environment ..............132
12.1 Ein einfacher Baustein aus [Bungenstock04a] . . . . . . . . . . . . . . . . . . . 134
12.2 Baustein mit Submanifesten aus [Bungenstock04a] . . . . . . . . . . . . . . . . 134
12.3 Verschachtelte Bausteine aus [Bungenstock04a] . . . . . . . . . . . . . . . . . 135
12.4 Klasse TempFSNode .................................137
12.5 Klasse TempFS ....................................137
12.6 Klasse SavableFS ..................................138
12.7 Die Unterklasse ZipFS und DirectoryFS .....................138
12.8 StrukturierteAdresse................................139
12.9 Klasse HierarchicalElement ...........................140
12.10 Sequenzdiagramm f¨
ur den Benachrichtigungsmechanismus . . . . . . . . . . . 140
12.11 Klasse MDElement ..................................140
12.12 Klasse IDElement ..................................141
12.13 Die Klassen Item,Manifest,Resource und Organization ...........142
12.14 Klasse File .....................................142
12.15 Klasse Dependency .................................143
12.16 Klassenhierarchie der Manifest-Elemente . . . . . . . . . . . . . . . . . . . . . 143
12.17 Klasse ContentPackage ...............................144
12.18 Klasse Brick .....................................144
12.19 Klasse Course ....................................145
12.20 Klassenhierarchie der Content Packages .....................145
12.21Komponentenbildung................................146
13.1 Das Muster Fassade [Gamma95,S.185] .....................148
13.2 Bildung der Komponente LOBDevelopment ....................148
13.3 Aufbau der Komponente CBK-Management-Application nach [Vollmann04, S.
128]..........................................149
13.4 Bildung der Komponente StructureDevelopment ................149
13.5 Bildung der Komponente AuthoringSystem ...................150
14.1 Screenshot der BeanShell ..............................155
14.2 Visualisierung physikalischer Dateien in Content Packages ...........156
14.3 Komponente f¨
urMetadaten ............................156
14.4 Klasse JSavablePanel ................................157
14.5 Verschachtelte Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.6 Klasse JNestedPanel ................................158
14.7 Klassenhierarchie der grafischen Basisklassen . . . . . . . . . . . . . . . . . . . 159
14.8 Klasse JCPPanel ...................................159
14.9 Manifest mit farblicher Syntax-Hervorhebung . . . . . . . . . . . . . . . . . . 160
14.10 Komponente f¨
urBausteine.............................160
14.11 Komponente f¨
urKurse ...............................161
14.12 Ansicht der Item-Properties ............................162
14.13 Dialog f¨
ur Export-Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . 163
14.14ScreenshotvonLyssa................................164
14.15 Screenshot der Toolbar ...............................165
14.16 Screenshot der erweiterten Toolbar ........................165
14.17 Screenshot der Workbench .............................165
15.1 Aufbau des Construction Kit Servers .......................168
15.2 Screenshot der CKS-Anmeldemaske . . . . . . . . . . . . . . . . . . . . . . . . 169
viii ABBILDUNGSVERZEICHNIS
15.3 Screenshot der CKS-Dateiansicht . . . . . . . . . . . . . . . . . . . . . . . . . 169
16.1 Screenshot des Applets f¨
ur komplexe Zahlen . . . . . . . . . . . . . . . . . . . 174
16.2 Erstellung eines Bausteins in vier Momentaufnahmen . . . . . . . . . . . . . . 176
16.3 Erstellen eines Kurses in zwei Varianten . . . . . . . . . . . . . . . . . . . . . 178
16.4 ¨
Ubersetzungsergebnis im Layout des GET Labs (HTML)............179
16.5 ¨
Ubersetzungsergebnis im Layout von mαth-kit (HTML) . . . . . . . . . . . . 180
16.6 ¨
Ubersetzungsergebnis im Layout von mαth-kit (PDF) . . . . . . . . . . . . . . 180
16.7 Theorieteil......................................181
16.8 Explorationsteil ...................................182
16.9 ¨
Ubungsteil......................................182
Tabellenverzeichnis
4.1 RDF-Terminologie .................................. 36
5.1 ¨
Ubersicht der Autorensysteme (Teil 1) . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 ¨
Ubersicht der Autorensysteme (Teil 2) . . . . . . . . . . . . . . . . . . . . . . . 55
6.1 ¨
Ubersicht der Lernplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10.1 Arbeitsteilung f¨
ur systemunabh¨
angige Komponenten . . . . . . . . . . . . . . . 108
10.2 Arbeitsteilung f¨
ur propriet¨
areKomponenten....................108
12.1 Gemeinsame Eigenschaften der Manifest-Elemente aus [Bungenstock04b] . . . . 139
Abk¨
urzungsverzeichnis
AICC ............ Aviation Industry CBT Committee
API . . . . . . . . . . . . . Application Program Interface
ARIADNE . . . . . . . Alliance Of Remote Instructional Authoring And Distribution Networks
for Europe
AWT ............ Abstract Window Toolkit
BMBF ........... Bundesministerium f¨
ur Bildung und Forschung
BSCW ........... Basic Support for Cooperative Work
CAI ............. Computer-Assisted Instruction
CBR ............. Case-Based Reasoning
CBT ............. Computer Based Training
CKS ............. Construction Kit Server
CMS ............ Content Management System
CP .............. IMS Content Packaging Information Model
CSS ............. Cascading Style Sheets
DC .............. Dublin Core
DCAP ........... DC Application Profile
DII .............. Dynamic Invocation Interface
DRM ............ Digital Rights Management
DSSSL .......... Document Style Semantics and Specification Language
DTD ............ Document Type Defintions
GET ............ Grundlagen der Elektrotechnik
GUI ............. Graphical User Interface
HTML ........... Hypertext Markup Language
HTTP ........... Hypertext Transfer Protoco
I18N ............. Internationalization
IEEE ............ Institute of Electrical and Electronics Engineers
IGD . . . . . . . . . . . . . Fraunhofer Institut f¨
ur Graphische Datenverarbeitung
ILS .............. Integrated Learning Management System
IMC ............. International Mail Consortium
J2EE ............ Java 2Platform, Enterprise Edition
J2SE ............ Java 2Platform, Standard Edition
JAX-RPC . . . . . . . Java API for XML-Based RPC
JAXM ........... Java API for XML Messaging
JPEG ........... Joint Photographic Experts Group
JSP ............. Java Server Pages
KI ............... K¨
unstliche Intelligenz
LCMS ........... Learning Content Management System
LMS ............. Learning Management Systemen
LO .............. Learning Object
LODAS .......... Learning Object Design and Sequencing Theory
LOM ............ Learning Objects Metadata
LORI ............ Learning Object Review Instrument
MathML ......... Mathematical Markup Language
xii ABK ¨
URZUNGSVERZEICHNIS
MDI ............. Multiple Document Interface
MIME ........... Multipurpose Internet Mail Extensions
MVC ............ Model, View, Controller
NFS ............. Network File System
PC .............. Personal Computer
PDA ............. Personal Digital Assistants
PDF ............. Portable Document Format
PIF .............. Package Interchange File
PNG ............ Portable Network Graphics
QName .......... Qualified Name
RDF ............. Resource Description Framework
RIO ............. Reusable Information Objects
RLO ............. Reusable Learning Objects
RPC ............. Remote Procedure Call
SCO ............. Sharable Content Objects
SCORM ......... Sharable Content Object Reference Model
SCORM RTI . . . . SCORM Runtime Interface
SDK ............. Software Development Kit
SGML ........... Standard Generalized Markup Language
SMB ............ Server Message Block
SOAP ........... Simple Object Access Protocol
SWT ............ Standard Widget Toolkit
TCP/IP ......... Transmission Control Protocol / Internet Protocol
TGN ............ Thesaurus of Geographic Names
TP .............. Transformation Package
UCS ............. Universal Multiple-Octet Coded Character Set
UI ............... User Interface
UML ............ Unified Modeling Language
URI ............. Uniform Resource Identifier
URIref ........... URI Reference
URL ............. Uniform Resource Locator
VFS ............. Virtual File System
VLE ............. Virtual Learning Environment
VM .............. Virtual Machine
W3C ............ WWW Consortium
WAM ............ Werkzeug, Automat, Material
WBT ............ Web Based Training
WebDAV . . . . . . . . Web-based Distributed Authoring and Versioning
WSDL ........... Web Services Description Language
WWW .......... World Wide Web
WYSIWYG . . . . . What You See IsWhat You Get
XML ............ Extensible Markup Language
XPath ........... XML Path Language
XSD ............. XML Schemas Definition Language
XSL ............. Extensible Stylesheet Language
XSL-FO ......... XSL Formatting Objects
XSLT ............ XSL Transformations
Kapitel 1
Einleitung
”Non scholae, sed vitae discimus.“ ”Nicht f¨
ur die Schule, sondern f¨
ur das Leben lernen wir“,
steht es schon ungef¨
ahr seit Beginn unserer Zeitrechnung geschrieben.1Moderner wird heute
im Kontext des stetigen gesellschaftlichen und wirtschaftlichen Strukturwandels vom Lebens-
langen Lernen sowie der Wissensgesellschaft gesprochen. Jedem Individuum, unabh¨
angig vom
sozialen Stand, soll durch Wissen die M¨
oglichkeit auf pers¨
onliche Verwirklichung und Aner-
kennung gegeben sein. Nur so l¨
asst sich der Wohlstand einer Gesellschaft wahren und f¨
ur eine
ressourcenarme Nation wie Deutschland gilt dies um so mehr. Durch die Globalisierung steigt
der weltweite Konkurrenzdruck, sodass Kompetenz und Qualifikation einen Standortvorteil
bedeuten. Wissen muss folglich effektiv und effizient vermittelt werden.
Das Bundesministerium f¨
ur Bildung und Forschung (BMBF) hat diesen Umstand erkannt
und f¨
ordert unter anderem das Programm ”Neue Medien in der Bildung“. Hierbei geht es um
die breite Nutzung didaktisch hochwertiger Lehr- und Lern-Software in allen Bildungsberei-
chen, also einen Bereich des E-Learnings. Mit Hilfe von Maschinen soll die Wissensvermitt-
lung verbessert werden.
Ein Projekt dieses F¨
orderprogramms ist mαth-kit [Unger04; Unger02; Schiller02], das
den Kontext dieser Arbeit darstellt. Ziel des Projekts ist die Erstellung eines multimedia-
len Baukastens [Thiere03b] zur Unterst¨
utzung der Mathematikausbildung im Grundstudi-
um Mathematik, Technische Informatik, Maschinenbau und anderer Ingenieurwissenschaften
[Thiere03a; Padberg02b; Padberg02a; Rehberg03]. Die Elemente des Baukastens eignen sich
f¨
ur Lehrende in Pr¨
asenz- und Fernlehre sowie f¨
ur Studierende beim Selbststudium [Bauch03].
Als technische Realisierung ist eine flexible E-Learning-Plattform mit integriertem Autoren-
system gedacht, die eine reibungslose Zusammenarbeit mit existierenden Systemen erlaubt.
Da vier Universit¨
aten2an diesem Projekt beteiligt sind, gilt ein besonderes Augenmerk der
Erstellung bzw. Verwaltung von Inhalten in Gruppen. Insgesamt umfasst das Projekt mαth-
kit somit die Erstellung sowie Ver¨
offentlichung mathematischer Inhalte mit Hilfe eines eigens
entwickelten Systems.
Der Fokus dieser Arbeit liegt auf der technischen Handhabung von Lehr- und Lerninhalten.
Hierzu geh¨
oren neben Kodierungen, Protokollen und Datenhaltungsformen auch die geeignete
Begriffs- bzw. Modellbildung. Beispiele f¨
ur den konkreten Einsatz von E-Learning finden sich
z.B. in [Dittler03].
1Laut B¨
uchmann [B¨
uchmann94] handelt es sich um die Umkehrung des Ausspruchs ”Non vitae, sed scholae
discimus“ aus den Epistulae morales von Seneca.
2Universit¨
aten Paderborn, Hamburg, Bayreuth und Fernuniversit¨
at Hagen
2 Einleitung
1.1 Problemstellung
Bestrebungen nach technischen Vereinfachungen bei der Wissensvermittlung reichen bis ins 16.
Jahrhundert zur¨
uck, wie ein Kupferstich aus dem Jahre 1588 von Agostino Ramelli belegt.3
Abbildung 1.1 zeigt ein B¨
ucherrad, das wahrscheinlich nie gebaut wurde.
Abbildung 1.1: Das B¨
ucherrad
Heute werden Computer als Hilfsmittel beim Lernen eingesetzt, weil sie den Zugriff auf
Lerninhalte vereinfachen und die Darstellung komplexer Sachverhalte erm¨
oglichen. Mit Hil-
fe des Internets kann von einfachen Abbildungen ¨
uber Animationen bis hin zu interaktiven
Simulationen alles auf heimischen PCs dargestellt werden. Tragbare Laptops und Personal
Digital Assistants (PDA) erlauben in Kombination mit drahtlosen ¨
Ubertragungswegen eine
arbitr¨
are Verf¨
ugbarkeit von Daten an fast jedem Ort der Erde. Die M¨
oglichkeiten scheinen
schier endlos zu sein. Doch reichen Internet und eine breite Palette von Anzeigeprogrammen
f¨
ur das E-Learning aus?
In Hinblick auf die Erwartungen und Hoffnungen, die sich an das E-Learning richten,
kann die Antwort freilich nur ”Nein“ lauten. Zu hoch sind die Anspr¨
uche der Lehrenden und
Lernenden, als dass sie in einfache HTML-Seiten gefasst werden k¨
onnten. Begriffe wie Wie-
derverwendbarkeit,Sequenzing oder Personalized Learning lassen erahnen, dass monolithisch
erstellte Inhalte unzureichend sind. Es bedarf daher eines modularen Aufbaus, der auf die
Anforderungen des E-Learnings eingeht.
3Agostino Ramelli (1531–1600) war ein italienischer Ingenieur des K¨
onigs von Frankreich. Der Originaltitel
des Buches lautete ”Le diverse et artificiose machine“.
1.2 Zielsetzung 3
Die Realisierung eines solchen Konzepts wirft jedoch in Theorie wie Praxis eine F¨
ulle neu-
er Fragen auf, deren Beantwortung Bestandteil dieser Arbeit ist. Zwar gibt es eine Reihe von
Modellen, Spezifikationen und Implementationen, die sich ausgiebig mit Teilfragen besch¨
afti-
gen, aber der globale Zusammenhang fehlt. Besonders die L¨
ucke zwischen den theoretischen
Modellen und den existierenden Anwendungen scheint besonders groß zu sein. Konkret lassen
sich folgende Fragen ableiten:
•Was ist ein Modul im E-Learning-Kontext? Die existierenden Auffassungen variieren in
Umfang, Form und Funktion. F¨
ur die Beantwortung aller weiteren Fragen ist es wich-
tig, dass die gew¨
ahlte Definition in Hinblick auf Didaktik und technischer Realisierung
gen¨
ugend Spielraum gew¨
ahrt.
•Wie k¨
onnen mehrere Module organisiert werden? Von Interesse sind die verschiedenen
Strukturen und Anordnungen, da sie die m¨
oglichen Aggregationen bestimmen.
•Wie sollen Inhalte klassifiziert werden? Die Module m¨
ussen mit Metadaten versehen
werden, um auffindbar zu sein.
•Wie sieht die technische Umsetzung eines Moduls aus? Die Kodierung der Module spielt
eine wesentliche Rolle f¨
ur die Akzeptanz eines Systems.
•Wie werden Module erzeugt und bearbeitet? Entwicklungs- und Wartungsprozess m¨
ussen
vom System unterst¨
utzt werden.
•Wo werden Module gespeichert? Es stehen z.B. Dateisysteme, Datenbanken und spezielle
Repositories zur Verf¨
ugung.
•Wie werden Module und deren Aggregate einheitlich dargestellt? Inhalte aus verschiede-
nen Quellen sehen zwangsl¨
aufig unterschiedlich aus.
•Wie lassen sich Objekte, Funktionen und Merkmale umgangssprachlich beschreiben? Me-
taphern sind z.B. ein probates Mittel in der Informatik, um komplexe Sachverhalte zu
veranschaulichen.
Die Vorteile des Computers beim Lernen k¨
onnen nur genutzt werden, wenn Produktion,
Pr¨
asentation und Archivierung von E-Learning-Inhalten auf einem durchdachten Fundament
beruhen. Um Allgemeing¨
ultigkeit zu erlangen, ist darauf zu achten, dass Einfl¨
usse sozialer
Art, wie z.B. Didaktik und Kultur, auf die technischen Konzepte vermieden werden. Bei der
Umsetzung gilt es letztendlich, auf propriet¨
are L¨
osungen zu verzichten.
1.2 Zielsetzung
Das Ziel dieser Arbeit ist, Entwurf, Implementation und Einsatz eines ganzheitlichen Kon-
zepts f¨
ur modulare E-Learning-Inhalte zu realisieren. Ihre Produktion, Pr¨
asentation und Ar-
chivierung soll gesamt abgedeckt werden, um einen konsistenten Umgang zu gestatten. Das
reduziert die Kosten f¨
ur Entwicklung, Wartung und Nutzung bei gleichzeitiger Qualit¨
atsstei-
gerung. Wenn vorhanden, sollen bew¨
ahrte Modelle, Spezifikationen und Implementationen als
Grundlage f¨
ur die Realisierung eines technischen Systems dienen, das die genannten Merkmale
aufweist. F¨
ur eine angemessene Verifikation und Validierung soll es als Prototyp implementiert
werden.
Als Ausgangspunkt dient die Baukasten-Metapher des Projekts mαth-kit, die als Leitbild
f¨
ur das System dient. Alle Objekte, die w¨
ahrend des Entwurfs benannt werden, sollen sich an
den Begriff Baukasten anlehnen. Ein zentraler Gegenstand dieser Arbeit sind die modularen
Inhalte und ihr Funktionsumfang. Sie sollen zu gr¨
oßeren Einheiten kombiniert und umgekehrt
auch jederzeit in ihre Bestandteile zerlegt werden k¨
onnen. Durch eine Trennung von Inhalt
4 Einleitung
und Darstellung innerhalb der Module lassen sich so beliebige Lehr- und Lernmaterialien
erstellen, die wie aus einem Guss wirken. Dies f¨
ordert die Wiederverwendung, unterst¨
utzt
die Wartung und erm¨
oglicht die Teamarbeit bei der Produktion. Auch Redundanzen bei der
Archivierung lassen sich durch diesen Ansatz verhindern. Bei zentraler Datenhaltung muss
jedes Modul nur einmal vorliegen, weil es lediglich referenziert wird. Die Metadaten gestatten
bei der Pr¨
asentation eine gezielte Auswahl, da sie auch bei Aggregationen von Modulen den
Zugriff auf einzelne Inhalte erm¨
oglichen.
F¨
ur den Umgang mit modularen Inhalten werden passende Werkzeuge ben¨
otigt. Um den
Aufwand der Implementation so gering wie m¨
oglich zu halten, sollen viele bew¨
ahrte Applika-
tionen eingesetzt werden. Hierzu geh¨
oren z.B. Web-Server, Datenbanken und Web-Browser.
Nur Funktionen, die von anderen Programmen oder Libraries noch nicht angeboten werden,
sollen in eigenen Werkzeugen umgesetzt werden.
1.3 Methodik
Diese Arbeit ist im angewandten Bereich angesiedelt, sodass die Ergebnisse durch Praxistaug-
lichkeit ¨
uberzeugen m¨
ussen. Ausgehend von der allgemeinen Problemstellung modularer E-
Learning-Inhalte soll ein theoretisches Konzept entwickelt werden, das in einer speziellen Im-
plementierung m¨
undet. Die abstrakte Problemstellung konkretisiert sich somit durchgehend
in immer genauere Teilprobleme. Am Ende steht ein Prototyp, mit dessen Hilfe die Funkti-
onst¨
uchtigkeit des Konzepts induktiv bewiesen werden soll.
Es gibt verschiedene Wege, einen Prototypen zu erstellen. In dieser Arbeit soll das inkre-
mentelle Modell [Balzert00] eingesetzt werden, bei dem bereits am Anfang alle Anforderungen
des Systems vollst¨
andig erfasst werden. Die Umsetzung gliedert sich in Ausbaustufen, die peu
`a peu die aufgestellten Anforderungen abdecken. Ein Vorteil dieses Verfahrens ist die schnelle
Verf¨
ugbarkeit eines lauff¨
ahigen Systems, mit dem erste Tests gefahren werden k¨
onnen. Des
Weiteren besteht keine Gefahr, dass die n¨
achsten inkrementellen Erweiterungen nicht zu dem
bestehenden System passen, da bereits im Vorfeld alle Anforderungen bekannt sind. Weil sich
gewisse Abl¨
aufe bei den einzelnen Ausbaustufen wiederholen, wird bei dieser Art Prototyp
von einem iterativen Modell gesprochen.
Bei der Entwicklung soll auf die Konzepte der objektorientierten Software-Entwicklung
zur¨
uckgegriffen werden. Zur Notation wird die Unified Modeling Language (UML) [Obj03] ver-
wendet, die sich als Standard durchgesetzt hat. Sie ist eine Sammlung verschiedener Diagram-
marten, mit der sich dynamische wie statische Zusammenh¨
ange darstellen lassen. Die eigent-
liche Implementierung wird mit der objektorientierten Programmiersprache Java [Gosling96]
durchgef¨
uhrt, da sie einfach im Funktionsumfang und plattformunabh¨
angig ist.
1.4 Systematik
Der Aufbau dieser Arbeit leitet sich aus der Methodik ab und besteht aus vier Teilen. Der erste
Stand der Wissenschaft gibt einen ¨
Uberblick der aktuellen Arbeiten, die sich mit Aspekten
der Problemstellung besch¨
aftigen. Es wird jeweils erl¨
autert, wie sich das vorliegende Thema
in den Kontext der Arbeit f¨
ugt und welche relevanten Beitr¨
age es gibt. Am Schluss dieses
Teils wird eine Bewertung durchgef¨
uhrt, indem die Zielsetzung den beschriebenen Arbeiten
gegen¨
uber gestellt wird, um bestehende Forschungsl¨
ucken aufzudecken.
Der Teil Entwurf beschreibt detaillierter den ben¨
otigten Leistungsumfang und vermittelt
ein theoretisches Modell vom System. F¨
ur die Beschreibung einzelner Komponenten, Bezie-
hungen und Merkmale werden die Methoden der Software Technik herangezogen. Alle wichti-
gen Definitionen werden in UML-Notation angegeben und sind Basis f¨
ur die Realisierung des
Systems.
Die wird im Teil Prototyp ausf¨
uhrlich erl¨
autert. Zuerst werden die koh¨
arenten Funktionen
in einzelne Libraries eingeteilt, um einen flexible Verwendung zu erm¨
oglichen. Es wird n¨
a-
1.4 Systematik 5
her auf interessante Implementationsdetails eingegangen und beschrieben, wie ein praktischer
Einsatz aussehen k¨
onnte. Danach werden die Applikationen von der Architektur bis zur Ober-
fl¨
achengestaltung vorgestellt und zu einem System zusammengef¨
uhrt.
Abschließend wird im Teil Analyse die geleistete Arbeit untersucht und bewertet. Anhand
ausgew¨
ahlter Beispiele werden typische Situationen beim Umgang mit dem System durch-
gespielt. Hierbei stehen Praxistauglichkeit und Ergonomie im Vordergrund. Es folgt eine Be-
schreibung der erreichten Ergebnisse und eine Abschlussbewertung. Abgerundet wird die Ana-
lyse mit einem Ausblick auf weiterf¨
uhrende Themen, die sich w¨
ahrend der Arbeit abzeichneten,
aber nicht in dem vorgegebenen Zeitrahmen behandelt werden konnten.
Nat¨
urliche Sprachen unterliegen dem Zeitgeist. Aus diesem Grund sollen kurz ein paar
formale Gesichtspunkte genannt werden, die f¨
ur diese Arbeit gelten. Der Text h¨
alt sich an
die 1996 reformierte deutsche Rechtschreibung. Soweit m¨
oglich, werden geschlechtsneutrale
Substantive genutzt, wie z.B. Lernende statt Lerner und Lernerin. L¨
asst sich kein geeigneter
Begriff bilden, werden beide Formen durch Schr¨
ag- und Bindestrich abgek¨
urzt angegeben, wie
z.B. Autor/-in. Anglizismen werden sparsam genutzt, jedoch sind sie in einer Dom¨
ane wie
der Informatik unvermeidbar. Viele Begriffe haben sich bereits etabliert und sind in den all-
t¨
aglichen Sprachgebrauch ¨
ubergegangen. So wird niemand ernsthaft E-Learning mit E-Lernen
oder Server mit Diener ¨
ubersetzen. Zitate werden in ihrer Originalform belassen und weder
¨
ubersetzt noch in der Rechtschreibung angepasst.
F¨
ur eine bessere Lesbarkeit des Textes werden bestimmte W¨
orter mit Formatierungen
versehen, die sich vom restlichen Text abheben. Es soll folgende Konvention gelten:
Italic: Namen und nicht integrierte englische W¨
orter, z.B. Java, Repository
Bold: Einf¨
uhrung wichtiger Begriffe, z.B. E-Learning
Typewriter: Quellcode, z.B. System.out.println("Hello");
Der Name des Projekts mαth-kit wird stets klein und mit dem griechischen Buchstaben
Alpha geschrieben. Das wurde am Anfang von allen Beteiligten beschlossen und soll auch hier
gelten.
Teil I
Stand der Wissenschaft
Kapitel 2
Lerntheorie
Die Hauptmotivation bei der Einf¨
uhrung neuer Medien beim Lernen ist die Optimierung des
Lernprozesses. Alle Theorien, Entw¨
urfe und Umsetzungen, die bei der Realisierung eines tech-
nischen Systems f¨
ur E-Learning entstehen, m¨
ussen daher auf dieses Ziel ausgerichtet sein.
Die Verbesserung eines Prozesses l¨
asst sich jedoch nur erreichen, wenn die theoretischen Hin-
tergr¨
unde bekannt sind. Aus diesem Grund wird ein kurzer ¨
Uberblick ¨
uber die Theorie des
Lernens gegeben und ein Modell ausgew¨
ahlt, mit dessen Hilfe weitere Klassifikationen von
Lerninhalten durchgef¨
uhrt werden.
2.1 Kompetenzstufen
Die Br¨
uder Dreyfus haben ein f¨
unfstufiges hierarchisches Lernmodell entwickelt, mit dem sich
der Entwicklungsprozess von Lernenden beschreiben l¨
asst [Dreyfus86; Humbert05; Klein99;
Metzinger99]. Die zentrale Idee des Modells ist, dass Lernende von einem statischen Fak-
tenwissen ¨
uber ein dynamisch theoretisches Wissen zu intuitiven Fertigkeiten gelangen. Ein
Mensch, der einer bestimmten Stufe zugeordnet werden kann, ist hierbei immer besser, als
die h¨
ochstbegabten Menschen der darunter liegenden Stufen. Die f¨
unf Stufen werden Novice
(Neuling), Advanced Beginner (Fortgeschrittene/-r Anf¨
anger/-in), Competent (Kompetenz),
Proficient (Gewandtheit) und Expertise (Expertentum) genannt.
Neuling:
Der ersten Stufe sind alle Lernende zugeordnet, die sich einem ihnen unbekannten The-
ma zum ersten Mal ann¨
ahern. Sie erlernen das Erkennen von Fakten und Mustern, um
mit vorgegebenen Regeln ihre Handlungen zu bestimmen. Bei den Regeln handelt es
sich um ”kontextfreie Regeln“, da sie situationsunabh¨
angig anhand eindeutig erkennba-
rer Elemente vom Neuling eingesetzt werden. Die Bewertung des Lernerfolgs umfasst
lediglich, wie die erlernten Regeln befolgt wurden.
Fortgeschrittene/-r Anf¨
anger/-in:
Beim ausgiebigen Lernen sammeln Menschen vielf¨
altige Erfahrungen, wie mit realen Si-
tuationen umzugehen ist. Dies bef¨
ahigt sie, mehr und kompliziertere kontextfreie Regeln
in ihre ¨
Uberlegungen einzubeziehen. Lernende fangen an, relevante Elemente selbst¨
andig
und schneller zu erkennen, da sie aus vorherigen Beispielen schon bekannt sind. Auch
f¨
ur diese ”situationalen“ Elemente gibt es Verhaltensregeln. Der Lernerfolg der Fort-
geschrittenen zeigt sich in der gewonnenen Erfahrung, die nicht objektiv beschreibbar
ist.
Kompetenz:
Die Handlung von Menschen auf dieser Stufe ist durch die Wahl eines Organisationsplans
gepr¨
agt. Sie kennen bereits viele relevante Fakten und Regeln, die sie auf ein breites
Spektrum von F¨
allen anwenden k¨
onnen. Durch die Organisation einer Situation muss
10 Lerntheorie
nur noch eine kleine Menge an Faktoren eines Plans ber¨
ucksichtigt werden, wodurch
die Komplexit¨
at einer Aufgabe reduziert wird. F¨
ur die Auswahl des Planes ben¨
otigt die
kompetente Person jedoch einige ¨
Uberlegungen, da die Tragweite der Wahl das gesamte
Vorgehen entscheidet. Der Lernerfolg zeigt sich im Wandel der eigenen Beziehung zu
der Umwelt. Die Kompetenten f¨
uhlen sich verantwortlich f¨
ur ihr eigenes Handeln und
den sich ergebenden Konsequenzen. Obwohl sie w¨
ahrend des Entscheidungsprozesses
Abstand zu den Dingen bewahren, sind sie mit den Auswirkungen ihres Handelns zutiefst
verbunden.
Gewandtheit:
Die Fertigkeit der Lernenden nicht nur schlichte Regeln anzuwenden, sondern bewusst
Entscheidungen zu treffen, wird mit wachsender Erfahrung intuitiver ausgepr¨
agt sein. Ei-
ne gewandte Person f¨
uhlt sich wie der Kompetente mit ihrem Problem verbunden, jedoch
w¨
ahlt sie ihren Organisationsplan nicht aufgrund distanzierter und reflektierter Bewer-
tungen. Vielmehr geschieht die Handlung automatisch, ohne bestimmte ¨
Uberlegungen,
da auf Erfahrungen vergangener Situationen zur¨
uckgegriffen wird. Diese Intuition ist
eine F¨
ahigkeit bei allt¨
aglichen Problemen, und kein Raten oder eine ¨
ubernat¨
urliche In-
spiration. Der Lernerfolg zeigt sich durch die intuitive Benutzung von Mustern, die nicht
in einzelne Komponenten zerlegt werden m¨
ussen.
Expertentum:
Das Handeln von Personen auf dieser Stufe ist nicht distanziert von den Problemen, nicht
von Gedanken der Auswirkungen gepr¨
agt und verl¨
auft nicht nach Organisationspl¨
anen
— es ist bereits Bestandteil der Person geworden. Dies bedeutet allerdings nicht, dass
Experten/-innen un¨
uberlegt wichtige Entscheidungen treffen oder sich ihrer Handlungen
nicht bewusst sind. Auch ihnen unterlaufen Fehler und unvorhersehbare Ereignisse k¨
on-
nen Probleme bereiten. Der Lernerfolg zeigt sich deshalb durch das Eingebunden-Sein
in Problemsituationen.
2.2 Lernparadigmen
Neben den verschiedenen Stufen, die Menschen w¨
ahrend des Lernens erreichen k¨
onnen, sind
auch die verschiedenen Paradigmen des Lernens — historisch gewachsene Theorien, die in sich
abgeschlossen sind — von Bedeutung. Im letzten Jahrhundert sind, hier in chronologischer
Reihenfolge angegeben, Behaviorismus,Kognitivismus und Konstruktivismus als maß-
gebliche Theorien zu nennen [Baumgartner97]. Sie basieren alle auf bestimmten Annahmen
zur Arbeits- und Funktionsweise des Gehirns, wodurch sich unterschiedliche Lehrstrategien
und Lernziele ergeben.
2.2.1 Behaviorismus
Im Behaviorismus wird Lernen als konditionierter Reflex betrachtet, der durch Adaption erwor-
ben wird. Als Begr¨
under des Behaviorismus gilt der amerikanische Psychologe John Broadus
Watson von der Johns Hopkins Universit¨
at [Wozniak94]. Seit seiner Arbeit ”Psychology as
the behaviorist views it“ (1913) werden alle Forschungen unter diesem Begriff zusammenge-
fasst, deren Basiseinheiten aus Reiz-Reaktions- bzw. Stimulus-Response-Verbindungen (S-R-
Verbindungen) bestehen. In den f¨
unfziger Jahren wurde der Behaviorismus zum beherrschen-
den Paradigma der amerikanischen Psychologie und nur wenige Jahre im sp¨
ateren Nachkriegs-
europa ¨
ubernommen.
Im Prinzip betrachtet der Behaviorismus das menschliche sowie das tierische Gehirn als
eine Black-Box, bei der ein Input (Reiz) einen deterministischen Output (Reaktion) erzeugt
(Abbildung 2.1).
Ob der gew¨
unschte Output zum Input passt, also das gezeigte Verhalten richtig war, wird
¨
uber ein extern gesteuertes Feedback vermittelt, den so genannten Konsequenzen. Sie sollten
2.2 Lernparadigmen 11
Output Input
extern gesteuertes Feedback
Gehirn ist eine Black−Box
Abbildung 2.1: Schematisches Modell des Behaviorismus [Baumgartner99, S.102]
in einem kurzen Zeitraum, am besten unmittelbar, auf das Verhalten folgen, um eine Ver-
st¨
arkung bei positiven Leistungen bzw. eine Abschw¨
achung oder L¨
oschung bei negativen zu
erreichen [Kerres98].
Die behavioristische Lehrstrategie setzt daher voraus, dass die Lehrenden genau wissen,
was richtig und was falsch ist, da sie f¨
ur die Konsequenzen verantwortlich sind. Dagegen stellt
sich der Lernprozess f¨
ur die Lernenden als eine Art Verhaltenssteuerung dar und steht damit
im Gegensatz zum kognitiven Lernen. Obwohl diese Art des Lehrens heute als nicht mehr
zeitgem¨
aß erachtet wird, hat sie in gewissen Bereichen noch ihre Existenzberechtigung. Als
Beispiel sei das Drill & Practice Muster in Sprachlabors genannt oder das erlernen k¨
orperlicher
Fertigkeiten wie Maschinenschreiben, Jonglieren und Autofahren.
2.2.2 Kognitivismus
Die haupts¨
achliche Kritik am Behaviorismus, dass die inneren Prozesse des Gehirns ausge-
blendet werden und folglich die komplexen Vorg¨
ange des menschlichen Lernens keine Ber¨
uck-
sichtigung finden, hat zum Kognitivismus gef¨
uhrt.
”Die kognitionstheoretische Grundposition unterscheidet sich von der behavioris-
tischen zun¨
achst dadurch, daß der Lernende als ein Individuum begriffen wird,
das ¨
außere Reize aktiv und selbst¨
andig verarbeitet und nicht einfach durch ¨
außere
Reize steuerbar ist.“ [Tulodziecki96, S. 43]
Der Kognitivismus ist heute das noch dominierende Paradigma und es gibt eine Reihe
von verschiedenen Auspr¨
agungen. Allen gemein ist der Begriff der Informationsverarbeitung,
was zu einer gewissen ¨
Aquivalenz von Computer und Gehirn f¨
uhrt. Abh¨
angig von der Ein-
sch¨
atzung dieser Annahme, kann von ”starker“ oder ”schwacher“ K¨
unstlicher Intelligenz (KI)
gesprochen werden [Searle86]. Die ”starke“ KI geht von dem Standpunkt aus, dass die Be-
ziehung zwischen menschlichem Gehirn und Computern eine Analogie ist und nicht bloß ein
methodisches Verfahren. Minsky, als Vertreter dieser Ansicht, schreibt in dem Prolog seines
Buchs Mentopolis:
”Die meisten Leute glauben immer noch, daß keine Maschine je ein Gewissen,
Ehrgeiz, Neid, Humor entwickeln oder andere geistige Lebenserfahrungen machen
kann. Nat¨
urlich sind wir weit davon entfernt, Maschinen mit menschlichen F¨
ahig-
keiten bauen zu k¨
onnen. Aber das bedeutet, daß wir bessere Theorien ¨
uber die
Denkf¨
ahigkeit brauchen.“ [Minsky94, S. 19]
Anh¨
anger der ”schwachen“ KI gehen nicht so weit und sehen die Analogie als eine heuris-
tische Annahme. Unabh¨
angig von der Sichtweise sind sich die Kognitivisten darin einig, dass
die Prozesse innerhalb des menschlichen Gehirns modelliert werden m¨
ussen. Hierf¨
ur m¨
ussen
geeignete Wissensrepr¨
asentationen und Algorithmen gefunden werden, mit denen die F¨
ahig-
keiten Lernen, Erinnern, Vergessen etc. modelliert werden k¨
onnen. Denkprozesse sind dann
12 Lerntheorie
Output Input
extern modelliertes Feedback
Verarbeitungsprozesse interessieren
interne
Abbildung 2.2: Schematisches Modell des Kognitivismus [Baumgartner99, S.105]
Wechselwirkungen von externen Angeboten und internen Strukturen. Abbildung 2.2 verdeut-
licht diesen Zusammenhang.
Beim Lernen muss der Kognitivismus daher von einem objektiven externen Wissen aus-
gehen, welches in der Realit¨
at unabh¨
angig vom Bewusstsein existiert. In dem schematischen
Modell wird die Steuerung des externen Einflusses auf den Lernenden durch das Feedback an-
gedeutet. Eine bedeutende Schw¨
ache dieses Paradigmas ist die unm¨
ogliche bzw. umst¨
andliche
Modellierung k¨
orperlicher Fertigkeiten.
2.2.3 Konstruktivismus
Im Konstruktivismus wird Lernen als aktiver Prozess betrachtet, bei dem der Mensch durch
seine Sinne die Umwelt wahrnimmt und in Beziehung mit fr¨
uheren Erfahrungen zu einem indi-
viduellen Wissen konstruiert. ”Die Umwelt, so wie wir sie wahrnehmen, ist unsere Erfindung.“
[Foerster95, S.40]. Das Gehirn wird als selbstreferentielles System betrachtet, das Energien
— nicht Informationen — ¨
uber die Sinnesorgane verarbeitet und daraus neue individuelle
Informationen erzeugt (Abbildung 2.3).
energetisch offen −
informationell geschlossen
Gehirn ist ein selbstreferentielles System
Wahrnehmung
Kopplung
Realität
Abbildung 2.3: Schematisches Modell des Konstruktivismus [Baumgartner99, S.108]
Damit bildet dieses Paradigma den Gegensatz zum Kognitivismus, bei dem objektive In-
formationen aufgenommen und verarbeitet werden. Freilich verleugnet der Konstruktivismus
nicht eine existierende Realit¨
at, jedoch geht er davon aus, dass sie nicht objektiv empfunden
werden kann.
F¨
ur das Lehren und Lernen zieht diese Ansicht Konsequenzen nach sich. Streng genommen
kann es z.B. keine optimale Wissensvermittlung geben, da sie individuell und unvorhersagbar
ist. Die Lehrenden k¨
onnen unterst¨
utzend wirken, indem sie die Aktivierung von Vorkenntnis-
sen, ihre Ordnung, Korrektur, Erweiterung, Ausdifferenzierung und Integration f¨
ordern.
”Lernen bedeutet nach dem konstruktivistischen Paradigma: Wahrnehmen, Erfah-
ren, Handeln, Erleben und Kommunizieren, die jeweils als aktive, zielgerichtete
Vorg¨
ange begriffen werden.“ [Klimsa93, S. 22]
Sie begleiten den Lernprozess und verhelfen den Lernenden zu eigenen Problemstellungen,
die selbst¨
andig entwickelt und gel¨
ost werden m¨
ussen. Die Problemfindung kann ein chaotischer,
verwirrender Prozess sein, der aber dem Lernen zutr¨
aglich ist. Als einziges Paradigma der drei
2.3 Lehrer/-in, Tutor/-in und Coach 13
genannten orientiert sich der Konstruktivismus mehr am Lernenden und macht die Qualit¨
at
der Wissensvermittlung nicht nur an der Eingabe der Lehrenden fest.
Ende der achtziger, Anfang der neunziger Jahre haben sich drei Ans¨
atze des ”gem¨
a-
ßigten“ Konstruktivismus hervorgetan, denen gemein ist, dass sie Situiertheit und Anwen-
dungsbezogenheit in den Vordergrund stellen. Die Anchored-Instruction-Theorie [CTGV90;
CTGV93] verpackt authentische Probleme in Geschichten, die Cognitive-Flexibility-Theorie
[Spiro88; Spiro91] setzt auf den Facettenreichtum realer Problemstellungen und die Cognitive-
Apprenticeship-Theorie [Spiro88] nutzt authentische Aktivit¨
aten und soziale Interaktionen in
Expertenkulturen.
2.3 Lehrer/-in, Tutor/-in und Coach
Die beschriebenen Lernparadigmen wirken sich erwartungsgem¨
aß auf die Lehre bzw. die Art
der Wissensvermittlung aus. In [Baumgartner97] wird f¨
ur jede der drei Theorien ein Begriff
und eine Eigenschaftsbeschreibung f¨
ur Lehrende definiert. Demnach werden Lehrende im Be-
haviorismus als Lehrer/-innen bezeichnet, die als Autorit¨
atspersonen auftreten und genau
wissen, was sie vermitteln m¨
ochten. Sie m¨
ussen nur die geeigneten Mittel und Wege f¨
ur den
”
Wissenstransfer“ finden.
Im Kognitivismus werden gestellte Aufgaben von den Lernenden relativ selbst¨
andig bear-
beitet, weshalb die Lehrenden den L¨
osungsprozess als Tutoren begleiten. Sie beobachten und
geben bei Bedarf Hilfestellungen.
Im Konstruktivismus nehmen Lehrende die Rolle eines Coaches ein. Lernende generieren
sich die Problemstellungen selbst, um komplexe Situation zu bew¨
altigen. Hierdurch verlieren
die Lehrenden ihre Unfehlbarkeit, da sie sich der Kritik der praktischen Situation aussetzen.
Ihre lehrende Funktion nehmen sie durch ihre Erfahrung und die F¨
ahigkeit der Betreuung war.
Abbildung 2.4 stellt die verschiedenen Lehrmodelle gegen¨
uber und z¨
ahlt die relevanten
Eigenschaften auf.
Lehrer/-in Tutor/-in Coach
• Faktenwissen,
"know-that"
• Vermittlung
• wissen,
erinnern
• Wiedergabe korrekter
Antworten
• Merken,
Wiedererkennen
• lehren,
erklären
• Prozeduren, Verfahren,
"know-how"
• Dialog
• (aus)üben,
Problemlösen
• Auswahl und Anwendung
der korrekten Methoden
• Fähigkeit,
Fertigkeit
• beobachten, helfen,
vorzeigen
• soziale Praktiken,
"knowing-in-action"
• Interaktion
• reflektierend handeln,
erfinden
• Bewältigung komplexer
Situationen
• Verantwortung,
Lebenspraxis
• kooperieren,
gemeinsam umsetzen
Abbildung 2.4: Drei Lehrmodelle [Baumgartner97]
14 Lerntheorie
2.4 Ein heuristisches Lernmodell
Die beschriebenen Kompetenzstufen mit ihren Lernelementen und das Lehrmodell k¨
onnen zu
einem heuristischen Lernmodell zusammengef¨
ugt werden [Baumgartner99]. Hierdurch ergibt
sich ein Modell, das die drei wichtigen Variablen Lernziele, Lerninhalte und Lehrstrategi-
en beinhaltet. Die Beziehungen und Zusammenh¨
ange zwischen den gleichrangigen Variablen
k¨
onnen so dreidimensional dargestellt werden. Abbildung 2.5 zeigt das Modell als W¨
urfel.
anwenden
erinnern
rezipieren
nachahmen
auswählen
entscheiden
verstehen
entdecken
handeln
entwickeln
Fakten,
kontext−
freie
Regeln
kontext−
abhängige
Regeln
Problem−
lösung komplexe
Situation Gestalt,
Muster−
erkennung
(Coach)
betreuen, kooperieren
lehren, erklären
(Tutor)
beobachten, helfen
(Lehrer)
Lernziele
Lehrstrategie
Lerninhalte
Expertentum
Gewandtheit
Kompetenz
Anfängertum
Neuling
Abbildung 2.5: Ein heuristisches Lernmodell [Baumgartner99, S.96]
Ein wichtiger Punkt bei diesem Modell ist, dass es nur f¨
ur Untersuchungszwecke einge-
setzt werden kann und kein Entscheidungs- oder Vorgehensmodell ist. Schulmeister gibt in
[Schulmeister03] die implizite Abgeschlossenheit zu bedenken. Ein W¨
urfel kann nicht um eine
vierte Dimension erweitert werden und die Skalierung der drei Dimensionen muss feststehen.
Ob dieses Modell allen auftretenden Szenarien gerecht wird, kann in dieser Arbeit nicht be-
trachtet werden.
Dennoch soll Baumgartners Modell in dieser Arbeit als eine L¨
osung f¨
ur die Taxonomie
subjektiver Metadaten gesehen werden, wie sie in Kapitel 4 vorgestellt werden. Bei einer
Beschreibung von Lernmaterialien kann mit Hilfe des Modells eine Beziehung zwischen dem
Wissen in einer Disziplin, dem angestrebten Niveau des Lernens und den lerntheoretischen An-
s¨
atzen angegeben werden. Dies ist bereits viel mehr, als die verbreiteten Metadaten-Standards
zu bieten haben.
2.5 E-Learning-Historie
Der Begriff E-Learning ist die Kurzfassung f¨
ur Electronic Learning und umfasst die Gruppe
der Lehr- und Lernverfahren, die Informations- und Kommunikationstechnologien einsetzen.
Abh¨
angig vom jeweiligen Stand der Technik, haben sich in der Entwicklung des E-Learnings
unterschiedliche Systeme und Verfahren entwickelt. Bodendorf teilt diesen Prozess in drei
Phasen ein, die in Abbildung 2.6 dargestellt sind.
2.5 E-Learning-Historie 15
Großrechner Personal Computer Workstations
"Intelligente"
Lehrsysteme
Testsysteme
Tutorial−, Trainings−,
Simulations−, Spiel−,
Programmierte
Unterweisung
50 er 70 er60 er 80 er 90 er Jahre
Abbildung 2.6: Entwicklung der computerunterst¨
utzten Ausbildung nach [Bodendorf90, S.15]
Burrhus Skinner entwickelte in den f¨
unfziger Jahren eine erste ”Lernmaschine“ [Skinner54].
Um das Lernen effizienter zu gestalten, zerlegte er den Lernprozess in so viele Teile, dass dieser
nicht mehr von einer Lehrerin oder einem Lehrer vermittelt werden konnte und eine maschi-
nelle Unterst¨
utzung bedurfte. Mit dem Einzug der Großrechner wurde zun¨
achst versucht, den
g¨
angigen Unterricht nachzuimplementieren, allerdings mit m¨
aßigem Erfolg. Die Programme
waren in der Bedienung schlichtweg zu kompliziert und verlangten spezielle EDV-Kenntnisse.
In den siebziger Jahren kam mit dem Personal Computer (PC) eine preiswerte Alter-
native zu den Großrechnern auf den Markt. Sie wurden zun¨
achst wie die Telemedien —
hierzu z¨
ahlen z.B. Diaprojektoren, Videorecorder und Bildplattenspeicher — als unterst¨
utzen-
de Hilfsmittel eingesetzt. Mit der Zeit entwickelte sich dann das Computer Based Training
(CBT), bei dem den Lernenden komplexe Sachverhalte multimedial vermittelt werden. Der
Begriff Multimedia ist hierbei als technisches Attribut zu sehen:
”The mixing of audio, video, and data is called multimedia; it sounds complicated,
but is nothing more than commingled bits.“ [Negroponte96, S. 18]
Mit der Verbreitung des Internets entwickelte sich aus dem CBT das Web Based Trai-
ning (WBT) und befreite die Lernenden aus ihrer Isolation. Neben der besseren Verf¨
ugbarkeit
der Lernmaterialien ¨
uber das Netzwerk werden verschiedene Kommunikationsmethoden wie
z.B. E-Mail, Forum und Chat angeboten. Abbildung 2.7 verdeutlicht noch einmal die Gemein-
samkeiten und Unterschiede von CBT und WBT als Diagramm.
Multimedien Telemedien
CBT
WBT
Abbildung 2.7: Begriffsbildung von WBT und CBT nach [Kerres98, S.14]
Kapitel 3
Lernobjekte
Inhalte f¨
ur E-Learning ben¨
otigen eine gewisse Form, um sie elektronisch verarbeiten zu k¨
onnen.
In der Literatur wird diese ¨
uberwiegend als Lernobjekt (Learning Object) bezeichnet, ohne
dass es einen gemeinsamen Konsens dar¨
uber gibt, was sich eigentlich hinter diesem Begriff
verbirgt. Viele, die sich mit diesem Thema intensiv besch¨
aftigen, stellen dieses Faktum fest
und tragen ihre pers¨
onliche Definition bei, sodass ein Wust an Beschreibungen entstanden ist,
der m¨
uhsam zu durchschauen ist.
F¨
ur diese Arbeit ist eine pr¨
azise Definition des Begriffs Lernobjekt von tragender Be-
deutung, da er das Fundament f¨
ur die Umsetzung des Baukastens ist. Aus diesem Grund
werden verschiedene Aspekte der Lernobjekte betrachtet, um den gesamten Kontext dieses
Begriffs auszuleuchten. Zuerst soll gekl¨
art werden, was ein Lernobjekt ausmacht und welche
Eigenschaften es im idealen Fall besitzt. Anschließend wird die Problematik der geeigneten
Granularit¨
at angegangen (Abschnitt 3.3), die sich in der Praxis oft als schwierigste Aufgabe
erweist.
3.1 Warum werden Lernobjekte ben¨
otigt?
Bevor die Lernobjekte n¨
aher untersucht werden k¨
onnen, muss als erstes ihr Bedarf festgestellt
werden. Ein Beispiel von Stephen Downes [Downes00a] in leicht abgewandelter Form soll als
erster Anhaltspunkt dienen.
Alle Universit¨
aten in Europa zusammengenommen bieten sicherlich hunderte von Veran-
staltungen an, in denen trigonometrische Funktionen behandelt werden. Die Mehrheit der Do-
zenten werden ihre selbst entwickelten Lehrmaterialien einsetzen, sodass die trigonometrischen
Funktionen viele Male mit geringf¨
ugigen Unterschieden behandelt werden. Unter ¨
okonomischen
Gesichtspunkten ist diese Redundanz nicht akzeptabel, da die Erstellung guter Lehrmateriali-
en mit erheblichen Kosten verbunden ist. Es ist somit besser, ein Thema einmalig ersch¨
opfend
aufzubereiten und als Lernobjekt in allen Veranstaltungen — individuellen Animosit¨
aten bei-
seite gelassen — einzusetzen. Eine Kostenreduzierung durch Wiederverwendung ist somit ein
Argument f¨
ur Lernobjekte.
Aber nicht nur aus finanziellen Gr¨
unden, sondern auch f¨
ur die Verwirklichung der Mehr-
werte des E-Learnings, die bereits 1969, noch unter dem Namen Computer-Assisted Instructi-
on (CAI), ausf¨
uhrlich in [Atkinson69] beschrieben wurden, sind Lernobjekte von Bedeutung.
Demnach soll Lehrstoff beim E-Learning adaptiv,generisch und skalierbar sein [Gibbons02].
Die ersten zwei Adjektive sind Grundlage f¨
ur ein individuelles, verbessertes Lernen und fin-
den sich heute im personalisierten Lernen wieder [Martinez00]. Adaptiver Lehrstoff passt sich
dem Wissens- und Leistungsstand der Lernenden an, indem z.B. geeignete Lernpfade oder
ausgew¨
ahlte ¨
Ubungen angeboten werden. Daher kann die Zusammenstellung nicht im Voraus
sondern nur generisch erfolgen. Es ist somit m¨
oglich, dass zwei Studierende mit ungleichen
Voraussetzungen unterschiedlichen Lehrstoff bearbeiten, obwohl beide das gleiche Thema in
einem Kurs behandeln. Personalisiertes Lernen ben¨
otigt zur Aufteilung der Inhalte folglich ei-
18 Lernobjekte
ne technische Einheit wie das Lernobjekt, die von einem System selbst¨
andig verarbeitet wird.
Eine Verbesserung der Lehre ist somit ein weiteres Argument f¨
ur Lernobjekte. Die Forderung
des CAI nach skalierbaren Inhalten hingegen, bedeutet die Vervielf¨
altigung von Lehrmateriali-
en nach industriellen Maßst¨
aben und deckt sich mit den Anforderungen der Kostenreduktion,
die bereits im Beispiel von Downes beschrieben sind.
3.2 Was ist ein Lernobjekt?
Das Lernobjekt ist f¨
ur die technische Realisierung von E-Learning unerl¨
asslich, doch wie ist
es nun genau definiert? Um dieser Frage nachzugehen, werden verschiedene Ans¨
atze erl¨
autert
und bewertet. Abschließend wird eine genaue Definition gegeben, die als Grundlage f¨
ur weitere
Betrachtungen gilt.
Bevor es weiter in die Details geht, soll hier ein etymologischer Fehler des Begriffs Lernob-
jekt ausger¨
aumt werden, der sehr h¨
aufig in der Literatur zu finden ist: Das Lernobjekt r¨
uhre
vom objektorientierten Paradigma der Software-Technik her. Diese Herleitung ist definitiv
falsch, da es weder Klassen noch erzeugte Objekte gibt. Wenn die N¨
ahe zur Software-Technik
gew¨
unscht ist, w¨
are der Begriff Modul mit seinen Eigenschaften angebrachter. Tats¨
achlich
gibt es in Wissenschaft und Wirtschaft eine Reihe anderer Begriffe, aber im Prinzip beschrei-
ben sie und ihre Permutationen immer das gleiche Konzept, sodass sie als Synonyme f¨
ur das
Lernobjekt angesehen werden. Dies sind z.B.:
•Learning Module
•Instruction Object
•Educational Object
•Content Object
•(Reusable) Information Object
•Training Component
•Nugget
•Chunk
Weitere Bestrebungen f¨
ur Lernobjekt-Ontologien finden sich z.B. in [Mosley05; Qin04].
3.2.1 Lernobjekte nach Cisco Systems
Das Unternehmen Cisco Systems beschreibt in seinem Strategie-Papier [Cis99] einen Ansatz
f¨
ur Lernobjekte auf Basis von Reusable Information Objects (RIO). Ein RIO ist eine gra-
nulare und wiederverwendbare Informationseinheit, die einmal entwickelt, auf verschiedenen
Medien eingesetzt werden kann. Sie ist unabh¨
angig von anderen RIOs, kann aber bei Be-
darf mit ihnen zu h¨
oheren Strukturen, den Reusable Learning Objects (RLO), kombiniert
werden. Ein RLO sollte, wie in Abbildung 3.1 dargestellt, aus ¨
Uberblick, Zusammenfassung,
Bewertung und 5–9 RIOs bestehen.
Mit diesem Ansatz soll ein Paradigmen-Wechsel herbeigef¨
uhrt werden, weg von den tra-
ditionellen Kursen, die als unflexible, monolithische Bl¨
ocke daherkommen, hin zu den wieder-
verwendbaren Lernobjekten. Die Hauptkritik am Kurs liegt am vorgegebenen Lernpfad, der
von den Lehrenden einmalig entwickelt wird und somit nur kognitivistisches Lernen (siehe z.B.
[Searle86; Tulodziecki96]) erlaubt. Auf die individuellen Voraussetzungen der Lernenden, wie
z.B. Vorwissen und Begabung, kann bei dieser uniformen Lehre nicht eingegangen werden.
Cisco unterscheidet zwischen den Vorteilen eines RIOs f¨
ur Autoren und Lernende. Die
Autoren profitieren von den RIO-spezifischen Templates als Grundlage f¨
ur ein konsistentes
3.2 Was ist ein Lernobjekt? 19
Abbildung 3.1: RLO-RIO-Struktur
Design, der Wiederverwendbarkeit von RIOs in zuk¨
unftigen Projekten und der Erstellung von
h¨
oheren Strukturen, den so genannten RLOs. F¨
ur die Lernenden sind die RIOs konsistent in
Design und Struktur, stehen jederzeit zur Verf¨
ugung und erlauben individuelle Lernpfade, die
sich ihrem Wissen und ihren F¨
ahigkeiten anpassen.
3.2.2 Lernobjekte nach Hodgins
Wayne Hodgins motiviert in seinem Whitepaper [Hodgins00] den Einsatz von Lernobjekten
als Container f¨
ur Information. In unserer Wissensgesellschaft ist das Wissen in den K¨
opfen von
Experten die wertvollste Ressource, die, nat¨
urlichen Ressourcen gleich, ihren wahren Wert erst
durch Extraktion, Aufbereitung und Ver¨
offentlichung erh¨
alt. Ziel muss also sein, das vorhan-
dene Wissen zu konvertieren, um es mit anderen in Konversation, Abbildung, geschriebenem
Wort, Modell, Simulation und anderen Formen auszutauschen. Es ist jedoch wichtig, dass die
Lernenden nur mit den Informationen konfrontiert werden, die sie wirklich ben¨
otigen.
Die Gr¨
oße der Informationseinheiten spielt f¨
ur Hodgins eine wesentliche Rolle:
”Size matters: Smaller is better.“ [Hodgins00, S. 27]
Er kritisiert die bisherigen Kursgr¨
oßen, weil aus Gr¨
unden der Effizienz Kurse allumfassend und
uniform gestaltet werden, um sie vielen Lernenden zur Verf¨
ugung zu stellen. Zudem werden
meist propriet¨
are Datenformate genutzt, sodass es neben den bekannten Einschr¨
ankungen mit
dem vorgegebenen Lernpfad auch noch zu Kompatibilit¨
atsproblemen kommt. Informationen
m¨
ussen also im Sinne der Wiederverwendbarkeit in kleinen, kompatiblen Einheiten bereit
gestellt werden, die sich beliebig rekombinieren lassen. Hodgins schl¨
agt f¨
ur die technische
Realisierung die Reusable Information Objects (RIO) von Cisco vor (siehe Abschnitt 3.2.1),
die sich nach der Hierarchie in Abbildung 3.2 richten.
F¨
ur die Generierung dieser Strukturen werden zus¨
atzlich Metadaten ben¨
otigt, die den
Inhalt des jeweiligen Lernobjekts charakterisieren. Sie k¨
onnen entweder objektiv sein, d.h., eine
automatische Vergabe durch das System ist m¨
oglich (z.B. das Erstellungsdatum), oder sind
subjektiv und unterliegen der pers¨
onlichen Einsch¨
atzung einzelner Personen oder Gruppen.
Um die Eigenschaften der Lernobjekte verst¨
andlicher zu beschreiben, bedient sich Hodgins
des LEGO-Bausteins als Metapher1. Mit den gleichen Bausteinen lassen sich Br¨
ucken, H¨
auser
oder Raumschiffe bauen. Es ist zudem jederzeit m¨
oglich, die Gebilde wieder in ihre Bestandteile
1Eine Reihe weiterer Autoren (z.B. [Mason00]) gebraucht ebenfalls LEGO-Bausteine als Metapher. Es l¨
asst
sich jedoch nicht mehr genau feststellen, wer der Urheber ist.
20 Lernobjekte
Eg. Simulation
Topical Unit
Reusable
Learning Object
Information
Objects
Abbildung 3.2: Lernobjekt-Hierarchie nach [Hodgins00, S. 28]
zu zerlegen und neu zu kombinieren. Genauso flexibel verhalten sich Lernobjekte, die beliebig
kombinierbar bzw. zerlegbar sind und die Grundlage f¨
ur ein personalisiertes Lernen bilden.
3.2.3 Lernobjekte nach Wiley
F¨
ur David A. Wiley hat das Internet die Kommunikation zwischen den Menschen ver¨
andert
und wird auch die zuk¨
unftige Art des Lernens beeinflussen [Wiley02]. Daher ist es unver-
meidlich, dass sich auch die Form des Lernmaterials anpassen wird. Er nennt als f¨
uhrende
Technologie die Lernobjekte, da sie wiederverwendbar, generisch, anpassbar und skalierbar
sind. Eine allgemeine Akzeptanz in Universit¨
aten und Wirtschaft kann jedoch nur durch die
Einigung auf verbindliche Standards erreicht werden.
”
Without such standards, universities, corporations, and other organizations around
the world would have no way of assuring the interoperability of their instructional
technologies, specifically their learning objects.“ [Wiley02, S. 4]
Wichtige Organisationen auf dem Gebiet der Lernobjekt-Standards sind z.B. LTSC2, IMS3,
ADL4und ARIADNE5. Als Ausgangspunkt seiner eigenen Definition f¨
ur Lernobjekte dient
Wiley daher die des IEEE-LOM-Standards (siehe Abschnitt 4.3):
”For this Standard, a learning object is defined as any entity — digital or non-
digital — that may be used for learning, education or training.“ [IEE02a, S. 5]
Er st¨
ort sich an dem ”non-digital“, da es nicht zu seiner Internet-Philosophie passt, und dem
”may be used“, wodurch nicht wiederverwendbare Ressourcen einbezogen werden. Seine Um-
formulierung lautet nun:
”... will define a learning object as ‘any digital resource that can be used to support
learning.“ [Wiley02, S. 7]
Beim Umgang mit Lernobjekten m¨
ussen didaktische Theorien eine Rolle spielen, wenn sie
die Lehre verbessern sollen. F¨
ur eine dynamisch automatische Komposition von Lernobjek-
ten, die Voraussetzung f¨
ur personalisiertes Lernen, m¨
ussen Metadaten ¨
uber die angewandte
2http://ieeeltsc.org (29.10.05)
3http://www.imsglobal.org (29.10.05)
4http://www.adlnet.org (29.10.05)
5http://www.ariadne-eu.org (29.10.05)
3.2 Was ist ein Lernobjekt? 21
Didaktik zur Verf¨
ugung gestellt werden. Nur auf diesem Weg kann eine sinnvolle Struktur mit
Lernobjekten aufgebaut werden. Es reicht jedoch nicht aus, einfach Titel, Autoren und Ver-
sionen zu speichern, weil so lediglich eine einfache Suche nach Daten m¨
oglich ist. Leider finden
die didaktischen Belange zu wenig Ber¨
ucksichtigung bei den Standardisierungsprozessen.
Die von Hodgins angef¨
uhrte LEGO-Metapher f¨
ur Lernobjekte lehnt Wiley kategorisch
ab, da sie falsche Assoziationen wecke und schl¨
agt stattdessen das Atom als Alternative
vor [Wiley99]. Wesentliche Eigenschaften des LEGO-Bausteins sind beliebige Kombinationsf¨
a-
higkeit — jeder Baustein kann mit jedem zusammengesteckt werden—, keine Einschr¨
ankungen
in der Struktur des Gebildes und eine ”kinderleichte“ Bedienung. ¨
Ubertragen auf das Lern-
objekt, bedeutet dies eine inad¨
aquate Vereinfachung, die schwerwiegende Konsequenzen hat.
Lernobjekte m¨
ussen demnach lerntheoretisch neutral sein, weil sonst keine beliebige Kombinie-
rung bzw. Strukturierung m¨
oglich ist. Hierdurch werden sie aber zu bloßen Informationsbeh¨
al-
tern degradiert, worin Wiley ein ernstes Problem f¨
ur die weiter Entwicklung der Lernobjekte
sieht:
”The learning object field must quickly make up its mind: are we in the information
or the instruction business?“ [Wiley99, S. 3]
Die gleichen Probleme verursacht die Eigenschaft der ”kinderleichten“ Bedienung, durch
die jegliche Didaktik außen vor gelassen wird. Nur Experten mit einem lerntheoretischen Hin-
tergrundwissen k¨
onnen sinnvolle Lernobjekte erstellen und deren geeignete Kombination si-
cherstellen.Die LEGO-Metapher hat sich somit selbst¨
andig gemacht und tr¨
agt maßgeblich zur
Ungenauigkeit im Umgang mit Lernobjekten bei.
Mit Hilfe der Atom-Metapher versucht Wiley diesen Trend aufzuhalten. Ein Atom ist eine
kleine Einheit, die mit anderen Atomen zu gr¨
oßeren Einheiten kombiniert werden kann. Soweit
besteht eine ¨
Ahnlichkeit zu den LEGO-Steinen. Der wesentlich Unterschied liegt jedoch in den
Bedingungen, unter denen der Aufbau geschehen kann, denn es gibt Einschr¨
ankungen. Atome
k¨
onnen nicht willk¨
urlich kombiniert werden, es gibt Vorgaben f¨
ur die Struktur und der Umgang
mit ihnen erfordert einiges an Wissen und ¨
Ubung. Bei genauer Betrachtung offenbart die
Metapher, dass Personen ohne didaktisches Wissen so wenig Lernobjekte sinnvoll kombinieren
k¨
onnen, wie Personen ohne chemisches Wissen Kristalle aus Atomen wachsen lassen. Anstatt
LEGO-Steine als Leitbild zu nehmen, sollten Lernobjekte lieber zu ”Lernkristallen“ kombiniert
werden.
3.2.4 Lernobjekte nach Downes
Stephen Downes m¨
ochte Lernobjekte nicht ¨
uber ihre Eigenschaften, sondern ¨
uber ihre Funk-
tionen definieren, wie sie bestehende Probleme digitaler Lerneinheiten l¨
osen k¨
onnen. Einer
seiner Gr¨
unde f¨
ur diese Betrachtungsweise ist die Uneinigkeit ¨
uber eine genaue Definition im
Lager der Lernobjekt-Forschung. Prinzipiell hat Downes nichts gegen die vorgestellten Model-
le von Hodgins oder Wiley einzuwenden, da sie f¨
ur sich betrachtet in ihrem Kontext sicher
sinnvoll sind [Downes00b]. Doch die Unterschiede zwischen den Modellen sind zu groß und
keines kann Allgemeing¨
ultigkeit f¨
ur sich beanspruchen. Konsens herrscht nur dar¨
uber, dass
die vom LOM-Standard vorgesehene Definition zu ungenau ist.
Als Rahmen f¨
ur die Funktionen von Lernobjekten sieht Downes die Lernobjekt-Wirt-
schaft (Learning Object Economy). Hierbei handelt es sich um eine Verbindung von Netz-
werken und Systemen, mit der Lehr- und Lernprozesse unterst¨
utzt werden. Innerhalb dieses
Komplexes werden Lernobjekte erstellt und verteilt, wobei beliebige Materialien gemeint sind.
Die genaue Interpretation, was ein Lernobjekt eigentlich ist, wird den Menschen ¨
uberlassen.
Egal ob nun Baustein oder Atom als Metapher herangezogen wird: Hauptsache eine gewisse
Funktionalit¨
at ist vorhanden.
Ausgangspunkt f¨
ur Downes ¨
Uberlegungen ist das Online-Lernen. Durch das Internet
er¨
offnen sich M¨
oglichkeiten, die es vorher nicht gab. Als wesentliche Neuerungen nennt er den
verbesserten Zugriff auf Materialien, bei dem unabh¨
angig von Raum und Zeit mit eigener
22 Lernobjekte
Geschwindigkeit gelernt werden kann. Ein bedeutender Nachteil sind hingegen die mit der
Produktion von E-Learning-Angeboten verbundenen Kosten. Auf herk¨
ommliche Weise erstellt,
sind sie sogar teurer als traditionelle Materialien wie z.B. Skripte oder Folien. Ursache dieser
Diskrepanz ist die h¨
ohere Komplexit¨
at interaktiver Medien. Eine L¨
osung des Problems ist, wie
in Abschnitt 3.1 bereits vorgeschlagen, die Wiederverwendung.
Es stellt sich die Frage, welche Form und Gr¨
oße sich am besten f¨
ur dieses Unterfangen
eignet (mehr dazu auch in Abschnitt 3.3). Nach Downes sind es Kurse, die das aktuelle Angebot
pr¨
agen. Kurse lassen sich aber nur schwer in verschiedene Veranstaltungen integrieren, weshalb
Wiederverwendung bis jetzt wenig praktiziert wird. Durch eine Aufteilung von Kursen in
Komponenten l¨
asst sich jedoch auch diese Problematik entsch¨
arfen. Die einzelnen Teile k¨
onnen
dann als Lernobjekte betrachtet werden. In diesem Zusammenhang tauchen auch Tausch und
Zusammenstellung von Lernobjekten als weitere Fragestellungen auf.
Dritte k¨
onnen auf Komponenten nur zugreifen, wenn ihnen ad¨
aquate Suchm¨
oglichkeiten
angeboten werden. Zentrale Systeme wie z.B. Portale k¨
onnen diese Aufgabe gut ¨
ubernehmen.
Zum Nachteil gereicht diesem Ansatz die erschwerte Distribution ¨
uber mehrere Portale. Was
auf dem einen System angeboten wird, kann auf dem n¨
achsten fehlen. Auch die Konsistenz der
verschiedenen Materialien muss kritisch betrachtet werden. Unterschiedliche Formate, Pr¨
asen-
tationen und Methoden verhindern die Kombination inhaltlich koh¨
arenter Komponenten.
Aus den gestellten Anforderungen lassen sich leicht die Funktionen bestimmen, die aus
einer Online-Ressource ein Lernobjekt machen. Eine Definition l¨
asst sich aus den folgenden
Eigenschaften ableiten:
•Teilbar6: Lernobjekte sind ¨
uber das Internet erreichbar. Sie werden an einer zentralen
Stelle erstellt und lassen sich beliebig in andere Kurse integrieren. Teilweise wird die-
se Eigenschaft unter ”wiederverwendbar“ gefasst, was aber nicht das Gleiche bedeutet.
”Teilbar“ schließt zus¨
atzlich zur Wiederverwendung den Zugriff ¨
uber Institutsgrenzen
hinaus mit ein.
•Digital: Diese Eigenschaft ist Voraussetzung f¨
ur das Online-Lernen. Physikalische Ein-
heiten, wie z.B. B¨
ucher, Mappen, Skripte, werden so von vornherein als Lernobjekte
ausgeschlossen.
•Modular: Die Gr¨
oße bestimmt die Wiederverwendbarkeit. Ein Lernobjekt ist nicht ein
kompletter Kurs, aber ein Bestandteil von ihm. Daher m¨
ussen mehrere Lernobjekte
wie Module zu gr¨
oßeren Einheiten zusammenf¨
uhrbar sein. Zudem soll ein Lernobjekt
unabh¨
angig von anderen sein.
•Interoperabel: Es muss m¨
oglich sein, Lernobjekte auch aus verschiedenen Quellen zu
kombinieren. F¨
ur Personen, die einen Kurs zusammenstellen, darf es keine Rolle spielen,
woher die einzelnen Komponenten stammen. Auch die Werkzeuge und die Infrastruktur
sollten keinen Einschr¨
ankungen unterliegen.
•Entdeckbar: F¨
ur durchschnittliche Anwender/-innen muss es in vertretbarer Zeit m¨
og-
lich sein, die gew¨
unschten Lernobjekte zu finden. Auf keinen Fall darf Spezialwissen
vorausgesetzt werden.
Downes res¨
umiert seine eigene Definition folgendermaßen:
”In conclusion, learning objects are digital materials used to create online cour-
ses where these materials are sharable, modular, interoperable and discoverable.“
[Downes02]
6Downes benutzt das Wort ”sharable“, das mehr auf die gemeinsame Nutzung abzielt als ”teilbar“.
3.3 Granularit¨
at 23
3.2.5 Lernobjekte nach Baumgartner
Peter Baumgartner f¨
uhrt ein recht einfaches Modell ein, bei dem der Begriff Lernobjekt, ¨
ahn-
lich wie bei Cisco (vgl. Abschnitt 3.2.1), als Reusable Learning Object (RLO) definiert
ist. Zu Konfusion hinsichtlich der Verwendung des Begriffs Lernobjekt in dieser Arbeit kann
es kommen, wenn Baumgartners Definition herangezogen wird:
”Ein LO (Learning Object) ist die kleinste sinnvolle Lerneinheit, in die ein Online-
Kurs zerlegt werden kann. Demnach kann ein LO entweder aus einem einzelnen
Bild, einer Grafik, einem Text, einer Flash-Animation oder auch aus einer kurzen
Anweisung mit einem definierten Lernziel und einem Test zur Lernerfolgskontrolle
bestehen.“ [Baumgartner02b, S. 24]
Erst wenn ein Lernobjekt mit Metadaten angereichert wird, kann es wieder verwendet und
zu h¨
oheren Kurseinheiten kombiniert werden. Diese eigenwillige Definition ist in Abbildung
3.3 zusammengefasst.
Informationseinheiten
RLO´s (Wiederverwendbare Lerneinheiten)
Kurs
Lehrgang
Abbildung 3.3: Reusable Learning Objects nach [Baumgartner02b, S. 24]
3.3 Granularit¨
at
Durch die Gr¨
oße der Lernobjekte sind freilich Aspekte wie Entwicklung und Wiederverwen-
dung tangiert. Sehr kleine Einheiten, oft auch Atome genannt, sind schnell realisiert und
¨
außerst flexibel, jedoch ist ihre Verwendung mit Mehrarbeit verbunden. Eine simple Abbil-
dung reicht beispielsweise meist nicht aus. Sie muss schon mit einem Text versehen werden, der
sich in einen Gesamtkontext einbettet. Hingegen ist der Entwicklungsaufwand umfangreicher
Einheiten enorm. Inhaltlich sind sie festgelegt und schwer an eigene Bed¨
urfnisse anzupassen,
sodass zwangsl¨
aufig Kompromisse bez¨
uglich der Themen, Darstellung, Umfang, etc. einge-
gangen werden. Ein kompletter Kurs f¨
ur ein Semester z.B. l¨
asst kaum Spielr¨
aume f¨
ur eigene
W¨
unsche.
Doch wie lassen sich subjektive Gr¨
oßenangaben ¨
uberhaupt definieren? Welche Gr¨
oße ist
gemeint, wenn der Umfang eines Lernobjekts angegeben ist? Bezieht sie sich auf den Inhalt
oder das Medium? Mit Hilfe verschiedener Definitionen des Begriffs Granularit¨
at sollen diese
24 Lernobjekte
Fragen aufgekl¨
art werden. Der bereits f¨
ur seine einfache Definition eines Lernobjekts geschol-
tene Standard LOM sieht vier Granularit¨
atsstufen vor (der Attributname lautet aggregation
level), die jeweils eine Aggregation der darunter liegenden darstellen. Angegeben durch ara-
bische Zahlen (1–4), l¨
asst diese Notation wahrlich Raum f¨
ur Auslegungen. Als Beispiel f¨
ur
eine Interpretation soll die Festlegung der Firma Autodesk7dienen, die in Abbildung 3.4 illus-
triert ist. Es handelt sich um eine Definition mit f¨
unf Ebenen, die nach [Duval03] auf die vier
Granularit¨
aten von LOM abgebildet werden:
1. Data oder Raw Media Elements sind die kleinsten Lernobjekte in diesem Modell. Es
handelt sich um reine Daten, die nicht weiter zerlegt werden k¨
onnen, wie z.B. Abs¨
atze,
Abbildungen und Animationen. Daten auf dieser Ebene k¨
onnen propriet¨
ar sein.
2. Die Ebene Information Objects ist unabh¨
angig von bestimmten Medien. Lernobjek-
te dieser Gr¨
oße enthalten soviel Informationen, dass sie oft wieder verwendet werden
k¨
onnen.
3. Koh¨
arente Information Objects zu einem Thema werden auf der Ebene Application
Objects zusammengefasst. In der Regel ist dies die bevorzugte Gr¨
oße zur Wiederver-
wendung von Lernobjekten.
4. Verschiedene Themenbereiche werden in den Ebenen Aggregate Assemblies oder Col-
lections zusammengefasst. Um auf LOM abbildbar zu bleiben, haben sie beide die Gr¨
o-
ße 4.
Principle
e
Fact
Process
s
Overview
w
Procedure
Text
Audio
Summary
y
Concept
t
Principle
e
Process
s
Concept
t
Procedure
e
Fact
Overview
w
Summary
y
Objective
“Raw”
Data
Media
Elements
Information
Objects
Application
Objects
(Learning Objects,
Support Objects,
Marketing,
Reference, etc.)
Aggregate
Assemblies
(Lessons,
Chapters, Units,
Brochure, etc.)
Collections
(Stories, Courses,
Books, Movies)
Modular Content Hierarchy
Animation
n
Simulation
n
Illustration
n
Objective Theme
Enabling
Objective
Terminal
al
Objective
e
Corporate Wide Application Specific Profiles
REUSABILITY
+ MOST + - LEAST-
CONTEXT + MOST +- LEAST -
©2001Learnativity
Alliance
Abbildung 3.4: Lernobjekt-Hierarchie aus [Hodgins02, S. 78]
Eine alternative Definition der Granularit¨
at stellt Wiley in [Wiley00b] vor. Anstatt die
Aggregationstiefe als Maß zu nehmen, kann auch die Komplexit¨
at von Inhalten herangezogen
7Autodesk ist der Arbeitgeber von Wayne Hodgins
3.4 Sequenzierung 25
werden. Auch wenn es eine Korrelation zwischen der Gr¨
oße eines Lernobjekts und dessen
Komplexit¨
at gibt, steht bei dieser Herangehensweise der Inhalt im Vordergrund. Folgende
Erfahrung unterst¨
utzt diese Form von Granularit¨
at:
”The optimal level of granularity must be determined for each project based on its
individual goals. From the perspective of instructional developers, our experience
is that it is most useful to move from the course level of granularity down to the
concept level when designing, but not so far down as the individual media asset
level. For our instructional needs, objects have the greatest potential for reuse when
they center on a single, core concept.“ [South02, S. 6]
Eine praktische Anwendung, die sich intensiver mit der Aufteilung existierender Doku-
mente besch¨
aftigt, ist Slicing Books [Dahn01; Dahn02]. Existierende Dokumente werden in
semantische Einheiten aufgeteilt, die sp¨
ater individuell zusammengesetzt werden k¨
onnen.
3.4 Sequenzierung
Eng verbunden mit der Granularit¨
at von Lernobjekten ist die Problemstellung der Reihenfol-
ge, in der sie durchgegangen werden sollen. Diese Abfolge wird Sequenz genannt und ist ein
didaktisches Grundproblem bei der Strukturierung von Lehr- und Lernmaterialien. Es lassen
sich verschiedene Relationen zwischen den Lernobjekten bestimmen, aus denen sich die Se-
quenz ableiten l¨
asst. Reigeluths ”Evaluationstheorie“ [Reigeluth80; Reigeluth83; Reigeluth99]
beinhaltet Vorschl¨
age zur Sequenzierung von Lernmaterialien verschiedener Granularit¨
aten.
Ausschlaggebend f¨
ur die Art der Sequenzierung sind Umfang und Zusammenhang der ein-
zelnen Themen. Je enger die thematischen Verkn¨
upfungen sind, desto st¨
arker wirkt sich die
Menge des Lernstoffes aus. Lernenden f¨
allt es bei gr¨
oßeren Umf¨
angen zunehmend schwerer,
Schw¨
achen und Ungereimtheiten in der Anordnung von Lernobjekten selbst¨
andig zu kompen-
sieren. Hingegen erlaubt eine geringere Menge an Lernstoff, solche M¨
angel durch Erinnerung
und Schlussfolgerungen auszugleichen.
Durch die Sequenzierung wird eine Relation zwischen den Lernobjekten festgelegt. ¨
Ubli-
cherweise wird zwischen der chronologischen Abfolge (historische Sequenz), der Praxis ¨
ubli-
chen Abfolge von T¨
atigkeiten (Prozeduren) und den Voraussetzungen bzw. dem Ausmaß der
Komplexit¨
at unterschieden [Niegemann04]. Bei mehreren Themen wird zwischen der linear-
sukzessiven und der Spiral-Sequenzierung Unterschieden. Abbildung 3.5 zeigt beide Se-
quenzmuster.
Bei der linear-sukzessiven Sequenzierung wird ein Thema intensiv durchgenommen, bevor
es zum n¨
achsten geht. Vorteil dieser Herangehensweise ist die Kontinuit¨
at, mit der ein Thema
behandelt wird. Die Anordnung etwaiger Materialien f¨
allt leichter und Lernende k¨
onnen sich
auf ein Thema konzentrieren. Jedoch kann es bei einem Themenwechsel leicht passieren, dass
zu spezielles Wissen verloren geht. Auch sind die Zusammenh¨
ange zwischen den Themen
nicht immer offensichtlich, da es durch die Separation nur wenig Ankn¨
upfungspunkte gibt.
Mit ¨
Uberblicken, R¨
uckblicken und Querverweisen kann diesem Problem allerdings in einem
gewissen Maß entgegen gewirkt werden.
Bei der Spiral-Sequenzierung wird jedes Thema mehrmals durchlaufen. Erst werden die
Grundlagen der einzelnen Themen behandelt, um sie jeweils soweit zu vertiefen, bis die
erw¨
unschte Kompetenzstufe erreicht ist. Im Gegensatz zur Sequenzierung gibt es viele Be-
r¨
uhrungspunkte zwischen den Themen, sodass sich die Zusammenh¨
ange leichter erschließen.
Nachteil dieser Herangehensweise sind die h¨
aufigen Unterbrechungen, die eine kontinuierliche
Vertiefung erschweren.
Es gibt noch eine Reihe von Faktoren f¨
ur die Sequenzierung, die st¨
arker didaktisch aus-
gelegt sind. So werden z.B. die zu vermittelnden Kompetenzen unterschieden, ob sie mehr
aufgaben- oder dom¨
anenorientiert sind [Reigeluth99]. Eine enge Verkn¨
upfung von Reigeluths
26 Lernobjekte
Start
End
Topic
A
Topic
B
Topic
C
(a) Linear-sukzessive Sequenzierung
Start
End
Topic
A
Topic
B
Topic
C
(b) Spiral-Sequenzierung
Abbildung 3.5: Linear-sukzessive Sequenzierung und Spiral-Sequenzierung nach [Reigeluth99,
S. 432]
Arbeiten mit Lernobjekten findet sich in Wileys Learning Object Design and Sequencing Theo-
ry (LODAS) [Wiley00a] wieder.
Andere Kriterien f¨
ur die Segmentierung sind unter anderen die Kapazit¨
at des menschlichen
Arbeitsged¨
achtnisses [Case78; Case85]. Hierbei wird darauf geachtet, dass die ”Informations-
einheiten“ nur so groß sind, wie die Lernenden sie verarbeiten k¨
onnen.
3.5 IMS Content Packaging Specification
Die Spezifikation IMS Content Packaging Information Model (CP) [IMS04a] beschreibt Da-
tenstrukturen, um die Zusammenarbeit von Internet-basierten Inhalten mit Autorensystemen,
Learning Management Systemen (LMS) und Laufzeitumgebungen zu gew¨
ahrleisten. Der Da-
tenaustausch von E-Learning-Inhalten erfolgt ¨
uber Packages, die im Wesentlichen aus einem
Manifest und koh¨
arenten Ressourcen, den Physical Files, bestehen. Weil das Manifest in XML
(Extensible Markup Language) kodiert ist — es hat immer den Dateinamen imsmanifest.xml
—, sind zus¨
atzliche Kontrolldateien (DTD und XSD) f¨
ur die Validierung enthalten. Im Inneren
teilt sich das Manifest in die Bereiche Metadata (Metadaten), Organizations (Organisationen),
Resources (Ressourcen) und (sub)Manifest auf. Abbildung 3.6 veranschaulicht den gesamten
Aufbau eines Packages.
Physikalisch wird ein Package durch ein logisches Verzeichnis in einem Dateisystem repr¨
a-
sentiert, was f¨
ur einen Datenaustausch, z.B. ¨
uber das Internet, recht unhandlich ist. Anstatt
das Package irgendwo in der Verzeichnisstruktur zu speichern, kann es inklusive aller Unter-
verzeichnisse auch in einer einzelnen Datei zusammengefasst werden, der Package Interchange
File (PIF). G¨
ultige Dateiendungen sind .zip,.jar,.cab und dergleichen. Wichtig ist ledig-
lich, dass die interne Kodierung der Datei kompatibel zu RFC 1951 [Deutsch96] ist.
Als Austauschformat kommen jedoch nicht nur die Package Interchange Files in Frage,
sondern auch Wechselmedien, wie z.B. die CD-ROM. In diesem Fall kann auf eine Kompri-
mierung verzichtet werden. Nur Manifest sowie Kontrolldateien m¨
ussen im Wurzelverzeichnis
liegen, um aus einem Datentr¨
ager ein g¨
ultiges Package zu machen.
Inhaltlich ist ein Package eine Einheit f¨
ur wieder verwendbare E-Learning-Inhalte, z.B. als
Teil eines Kurses, als eigenst¨
andiger Kurs oder als eine Sammlung verschiedener Kurse. Es
muss m¨
oglich sein, ein Package mit anderen Packages zu kombinieren oder solche Verb¨
unde
in ihre Einzelteile zu zerlegen. Dies setzt voraus, dass ein Package f¨
ur sich stehen kann und
3.5 IMS Content Packaging Specification 27
Assessment, Collaboration,
and other files)
(The actual Content, Media
PHYSICAL FILES
Resources
(sub)Manifest(s)
Organizations
Meta−Data
Manifest
PACKAGE
Abbildung 3.6: Die verschiedenen Bereiche innerhalb eines Packages [IMS04a]
keine Abh¨
angigkeiten zu anderen Dateien besitzt. Wird es entpackt, m¨
ussen alle relevanten
Daten f¨
ur einen reibungslosen Ablauf vorhanden sein.
Der Aufbau des Packages und die Beschreibung der enthaltenen Ressourcen wird ¨
uber das
Manifest angegeben. Die interne Struktur ist stets statisch und kann in einer beliebigen Anzahl
von Varianten angegeben sein. Durch die verschiedenen Funktionen und Gr¨
oßen eines Packages
ist der semantische G¨
ultigkeitsbereich der Strukturen nicht festgelegt, da es von einer kleinen
Lerneinheit bis zur Kurssammlung alles beschreiben kann. Auf jeden Fall muss ein Package
auf oberster Ebene, also direkt im logischen Verzeichnis, genau ein in XML kodiertes Manifest
beinhalten, das als Beschreibung dient und Top-level Manifest genannt wird. Es kann auch
(sub)Manifeste enthalten, die eine eigene semantische Ebene ausmachen. Enth¨
alt ein Package
z.B. einen Kurs, dann k¨
onnen einzelne Kapitel oder Lerneinheiten durch (sub)Manifeste be-
schrieben werden. Dies ist sinnvoll, wenn der Inhalt so stark gekoppelt ist, dass er nicht f¨
ur
sich alleine stehen kann.
Eine sinnvolle aber freigestellte Herangehensweise ist, die Inhalte als Lernobjekte zu be-
trachten, sodass sie beliebig kombiniert, auseinander genommen und wieder verwendet werden
k¨
onnen. Jedes Lernobjekt ist dann ein Package und besitzt sein eigenes Manifest. Bei einer
Aggregation mehrerer Lernobjekte zu einem Kurs werden alle Lernobjekt-Manifeste in einem
neuen Kurs-Manifest auf h¨
oherer Ebene zusammengef¨
uhrt. Der Kurs kann wiederum mit an-
deren Kursen kombiniert werden, wobei das gleiche Procedere f¨
ur die Manifeste zum Tragen
kommt. Durch die Allgemeing¨
ultigkeit der Packages und die rekursive Definition des Mani-
fests ist somit eine arbitr¨
are Aufteilung von Inhalten m¨
oglich. Wie sie genau aussieht, liegt
letztendlich bei den Autoren/-innen.
Die Ressourcen eines Packages sind beliebige Daten in Dateiform, wie z.B. HTML-Seiten,
Texte, Sounds, Grafiken und Animationen. Sie sind entweder Bestandteil des Packages —
sie liegen im Wurzel- bzw. einem Unterverzeichnis — oder werden ¨
uber eine g¨
ultige URL
referenziert, die eine Einbindung zur Laufzeit erm¨
oglicht. ¨
Uber eine definierte Auszeichnung
k¨
onnen Ressourcen im Manifest deklariert werden, beispielsweise mit dem <resource>-Tag
in XML-Notation. Da Ressourcen auch aus mehreren Dateien bestehen k¨
onnen, sollten inte-
grierte Dateien explizit ¨
uber das <file>-Tag bekannt gegeben werden. Im Falle einer URL-
Adressierung ist diese Deklaration freilich nicht m¨
oglich, weil ben¨
otigte Dateien wiederum nur
¨
uber URLs und nicht innerhalb des Packages erreichbar sind. Abh¨
angigkeiten jeglicher Art
zwischen Ressourcen k¨
onnen als Dependency (<dependency>-Tag) angegeben werden.
Handelt es sich bei den Ressourcen z.B. um Abschnitte und Unterabschnitte eines inhaltlich
zusammenh¨
angendes Textes, befinden sie sich strukturell auf verschiedenen Ebenen, die nicht
28 Lernobjekte
durch die einfache Deklaration im Manifest beschrieben sind. Mit Hilfe einer eigenen Daten-
struktur, der Organisation (<organization>-Tag), werden solche hierarchischen Relationen
angezeigt. Sie ist als Baum realisiert, dessen Knoten als Items (<item>-Tag) bezeichnet wer-
den und Referenzen auf Ressourcen oder Submanifeste beinhalten. Die Submanifestverweise
sind unerl¨
asslich f¨
ur die beschriebene Zusammenf¨
uhrung verschiedener Packages. Weil es m¨
og-
lich ist, Manifeste mit mehreren Organisationen zu erstellen, k¨
onnen die gleichen Ressourcen
und Submanifeste innerhalb eines Packages verschieden angeordnet werden.
Nicht nur das Manifest kann mit Metadaten versehen werden, sondern auch Ressourcen,
Dateien, Organisationen und Knoten. Die Beschreibung ist im IMS-eigenen Metadatenformat
[IMS01] anzugeben und steht im <meta-data>-Tag. Abbildung 3.7 verdeutlicht nochmal die
gesamte Datenstruktur eines Manifests.
Manifest
Meta−data
Organizations
Organization
Meta−data
Item
Meta−data
Item
Manifest
Resources
Resource
Meta−data
File
Dependency References to another resource whose
files this resource depends upon
Locally referenced files that this
resource is dependent on
(or zero)
One−to−one (zero or more)
One−to−many (one or more)
One−to−many
One−to−one
Meta−data Meta−data describing the file
Meta−data describing the resource
A specific resource
A collection of references to resources
Meta−data describing the item
A node within a hierarchical organization
Meta−data describing the organization
A particular hierarchical organization tree
Organizational structure for this package
Meta−data describing the package
A reusable unit of instruction
Abbildung 3.7: Datenstruktur eines Manifests [IMS04a]
Die Spezifikation des IMS CP ist f¨
ur eigene Erweiterungen ausgelegt. Es ist erw¨
unscht,
dass Implementationen die Basisstrukturen der Organisationen erweitern und neue Typen f¨
ur
Ressourcen einf¨
uhren. Bew¨
ahrte Erg¨
anzungen k¨
onnten letztendlich in zuk¨
unftige Versionen
der Spezifikation aufgenommen werden.
Es werden aber nicht nur Datenstrukturen von der Spezifikation vorgegeben, sondern auch
Algorithmen. F¨
ur diese Arbeit ist die Zusammenf¨
uhrung von Organisationen aus Manifesten
und Submanifesten von Bedeutung, weshalb diesbez¨
uglichen Verfahren besonderes Augenmerk
3.5 IMS Content Packaging Specification 29
gilt. Immer wenn ein Knoten ein Submanifest anstatt einer Ressource referenziert, m¨
ussen die
Strukturen beider Organisationen kombiniert werden. Je nach Anordnung und Aufbau der
beiden Manifeste treten verschiedene F¨
alle auf, die differenziert behandelt werden. F¨
ur eine
erfolgreiche Zusammenf¨
uhrung ist mindestens eine Organisation im Submanifest Vorausset-
zung. Ansonsten gilt die Referenz auf das Submanifest als nicht gesetzt. Stehen stattdessen
mehrere Organisationen zur Auswahl, dann wird entweder die explizit deklarierte oder, wenn
diese Auszeichnung fehlt, die erste verwendet. Mit der Zusammenf¨
uhrung selbst verh¨
alt es sich
folgendermaßen. Die Organisation wird direkt mit dem referenzierenden Knoten vereint, wobei
Konflikte durch gleiche Attribute — es sei z.B. ein Titel angef¨
uhrt, welcher von Knoten und
Organisation bestimmt werden kann — stets zugunsten des Knoten gel¨
ost werden. Abbildung
3.8 veranschaulicht diesen Vorgang f¨
ur einen Knoten ohne Subknoten.
Resource X
Resource Y Resource B
Resource A
About X
About Y
About A
About B
About Z
About B
Submanifest
About X
About Y
About Z
About A
Abbildung 3.8: Einfache Aufl¨
osung von Referenzen
Das gleiche Beispiel f¨
ur einen Knoten mit Subknoten ist in Abbildung 3.9 zu sehen.
Resource B
Resource A
About B
Submanifest
About A
Resource YX
Resource YY
Resource Y
Resource X
About Y
About X
About Z
About YX
About YY
About A
About B
About YX
About YY
About Y
About X
About Z
Abbildung 3.9: Aufl¨
osung von Referenzen mit Subknoten
Beispiele f¨
ur den Einsatz von IMS CP finden sich in [Low02].
30 Lernobjekte
3.6 Sharable Content Object Reference Model
Beim Sharable Content Object Reference Model (SCORM) von Advanced Distributed Learning
(ADL) [Dodd04c] handelt es sich um eine Spezifikation, die auf den Standards von AICC, IMS
und IEEE aufbaut. SCORM definiert ein Content Aggregation Model und eine Runtime En-
vironment f¨
ur Lerneinheiten, die ¨
uber das Internet ver¨
offentlicht werden sollen. Das Content
Aggregation Model beschreibt, wie kleinere Dateneinheiten zu Lerneinheiten, Kapiteln oder
ganzen Kursen zusammengestellt werden. Im wesentlichen basiert es auf dem Content Packa-
ging von IMS. Die Runtime Environment gibt einen Rahmen vor, wie die erzeugten Lerninhalte
durch eine Lernplattform (siehe Kapitel 6) verwaltet und gesteuert werden. Abbildung 3.10
zeigt eine schematische Darstellung aus der Spezifikation.
Learning Management System
(LMS)
LMS Server
Web Browser
SCO Asset
ECMAScript
API
Instance
Server Side
Client Side
Launch
API:
Communications Link between a SCO
and LMS
Data Model:
Data is requested to be
retrieved from and stored in the LMS from the
SCO.
Data Model:
Actual data sent
back and forth
between a SCO
and LMS
Communication
with backend
server is not
specified in
SCORM.
Asset
AssetAsset
Abbildung 3.10: Runtime Environment aus [Dodd04b, S. 1-8]
¨
Uber einen Startmechanismus (Launch) werden die Web-basierten Inhalte aufgerufen und
die Initialisierung durchgef¨
uhrt. Die eigentliche Kommunikation erfolgt ¨
uber eine API, die in
der Abbildung beispielhaft ¨
uber JavaScript angesprochen wird. ¨
Uber definierte Datenstruktu-
ren (DataModel) informiert der Client den Server (LMS) ¨
uber den aktuellen Status.
Die gesamte Steuerung der Kommunikation auf Seiten des Clients l¨
auft im Inhalt selbst ab
und nicht im Content Package. Aus diesem Grund soll an dieser Stelle nicht weiter auf dieses
Thema eingegangen werden. Mit dem Einsatz von SCORM setzen sich [Letts02; Shackelford02]
auseinander und Beispiele f¨
ur den Einsatz finden sich in [Newman03].
3.7 Formate 31
3.7 Formate
Die Inhalte von Lernobjekten m¨
ussen in einer Form vorliegen, dass die gesamte Infrastruktur,
von den Autorensystemen bis hin zu den Lernplattformen, sie verarbeiten kann. Zu den g¨
an-
gigen Formaten f¨
ur E-Learning Inhalte d¨
urfen freilich HTML, PDF, Microsoft Word/Power-
Point oder Macromedia Flash z¨
ahlen. Systeme mit einem solchen Repertoire sind hinsichtlich
der Kompatibilit¨
at auf der sicheren Seite. Dennoch reichen diese ¨
uberwiegend propriet¨
aren
Formate f¨
ur die Anspr¨
uche des E-Learnings nicht aus. Die Gr¨
unde hierf¨
ur sind vielf¨
altig. Zur
Erstellung sowie Anzeige werden oft spezielle Programme ben¨
otigt, die teilweise horrende Kos-
ten verursachen und oft nicht f¨
ur alle Betriebssysteme zur Verf¨
ugung stehen. Folglich kommt
es zu Einschr¨
ankungen, die zu Lasten der Lernenden gehen. Nicht selten m¨
ussen private Res-
sourcen eingesetzt werden, sodass hier ein geringer finanzieller Spielraum gew¨
ahrt ist.
Ein anderes Problem ist die mangelnde Flexibilit¨
at der angesprochenen Formate. Unzu-
l¨
angliche Strukturinformationen erschweren die technische Umsetzung von Lernobjekten. Ei-
genschaften aus Abschnitt 3.2, wie z.B. Modularit¨
at, verschiedene Granularit¨
aten, individuelle
Lernpfade etc., sind nicht immer umsetzbar. Hinzu kommt die Vermengung von Darstellung
und Inhalt. Beispielsweise kennt das Dateiformat von MS Word keine strukturelle Aufteilung
eines Dokuments durch Kapitel, Abschnitt oder Absatz. Stattdessen hat eine Kapitel¨
uber-
schrift eine bestimmte Formatierung, die sich in Schriftart und Gr¨
oße ausdr¨
uckt. Ein anderes
Textfragment mit zuf¨
allig gleichen Eigenschaften ist demnach nicht unterscheidbar. F¨
ur eine
automatische Verarbeitung kann diese Verquickung un¨
uberwindbare Probleme bereiten.
Abhilfe schafft wieder die Extensible Markup Language (XML), die bereits Gegen-
stand vieler Untersuchungen und Projekte war [Roisin98; Freitag02b; Teege02; Belqamsi02;
Wollowski02; Balbieris02]. XML ist inzwischen so weit akzeptiert und bekannt, dass in dieser
Arbeit nicht weiter auf technische Details eingegangen werden soll. Interessante Einf¨
uhrungen
zu diesem Thema finden sich in [Ammelburger03; Mintert02; Ray01].
Ein Grund f¨
ur die breite Akzeptanz von XML ist die einfache Definition eigener bzw.
Anpassung existierender XML-Applikationen. Durch automatische Validierungsverfahren, die
entweder durch Document Type Definitions (DTD) oder XML Schemas (XSD) [Binstock02;
Vlist02] gesteuert werden, kann die G¨
ultigkeit von XML-Dokumenten ¨
uberpr¨
uft werden. Die
DTDs stammen noch von der Standard Generalized Markup Language (SGML) [Goldfarb91]
ab, aus der XML einst hervorging. Aufgrund verschiedener M¨
angel wurde vom W3C XML-
Schema als Nachfolger der DTD eingef¨
uhrt, dessen genaue Vorteile in [Hansch02] nachgelesen
werden k¨
onnen.
Die Darstellung von XML-Dokumenten wird von außen gesteuert, wodurch verschiedene
Layouts und Dateiformate unterst¨
utzt werden. Abh¨
angig von der jeweiligen Anwendung, k¨
on-
nen XML-Dokumente z.B. in einem Webbrowser direkt dargestellt oder in einem zus¨
atzlichen
Verarbeitungsschritt umgewandelt werden. Die Steuerung erfolgt durch verschiedene Mecha-
nismen. Mit Hilfe der Extensible Stylesheet Language (XSL) k¨
onnen Struktur und Darstellung
gleichermaßen beeinflusst werden. Sie besteht aus drei Teilen: XSL Transformations (XSLT)
zur Umwandlung der Struktur [Tidwell01], XML Path Language (XPath) zur Adressierung von
XML-Fragmenten [Simpson02] und den XSL Formatting Objects (XSL-FO) zur Festlegung von
Darstellungsregeln [Pawson02]. Auch die von HTML bekannten Cascading Style Sheets (CSS)
[Meyer02] oder die Document Style Semantics and Specification Language (DSSSL) f¨
ur SGML
[Farreres03] lassen sich zur Formatierung von XML-Dokumenten nutzen.
F¨
ur die Kodierung von E-Learning-Inhalten gibt es bereits eine Reihe von XML-Appli-
kationen, wie z.B. DocBook [Walsh02a; Walsh02b], OmDoc [Kohlhase00; Kohlhase02] und
LMML [Freitag02a].
Kapitel 4
Metadaten
Die Lernobjekte aus Kapitel 3 k¨
onnen, wenn sie flexibel genug realisiert wurden, in vielen ver-
schiedenen Kontexten eingesetzt werden. F¨
ur einen sinnvollen Einsatz durch Dritte ist jedoch
eine pr¨
azise Identifizierung der Lern- und Lehrmaterialien unerl¨
asslich. V¨
ollig inakzeptabel
ist, bei jeder Recherche nach geeigneten Materialien ¨
uber die Inhalte selbst zu suchen. Bei
Angeboten mit mehreren hundert oder sogar tausenden Lernobjekten steht der Nutzen in kei-
ner Relation zum Aufwand. Auch mit etwaigen maschinellen Hilfen, wie z.B. Volltextsuche,
ist diesem Problem nicht beizukommen. Aus diesem Grund sollten Lernobjekte mit zus¨
atz-
lichen Beschreibungen versehen werden. Da sie nicht direkt zum Inhalte geh¨
oren, werden sie
Metadaten genannt. Im Umgang mit Metadaten ist der Mensch vertraut und sie sind aus
dem allt¨
aglichen Leben nicht wegzudenken. Beispielsweise steht auf einer Milchverpackung,
dass es sich um Milch handelt, wie hoch der Fettgehalt ist und das Mindesthaltbarkeitsdatum.
Niemand w¨
urde auf die Idee kommen, die Verpackung zu ¨
offnen, um den Inhalt festzustellen.
Die Metadaten reichen als Information f¨
ur eine Auswahl aus.
¨
Ahnlich verh¨
alt es sich bei E-Learning-Angeboten, wenn auch ganz andere Metadaten be-
n¨
otigt werden. Doch welche sind es? Zus¨
atzliche Daten ¨
uber den/die Autoren/-in und das In-
stitut k¨
onnen helfen, die Qualit¨
at der Inhalte abzusch¨
atzen. Ein Lebenslauf oder unterrichtete
Lehrveranstaltungen helfen, die Reputation zu beurteilen [Kortzfleisch99, 54]. Aber auch tech-
nische Voraussetzungen, rechtliche Rahmenbedingungen, ben¨
otigte Vorkenntnisse, didaktische
Methoden, etc. spielen eine Rolle. Nach [Gill98] gibt es drei wesentliche Eigenschaften, die bei
allen Informationsobjekten — einschließlich Lernobjekten — durch Metadaten beschrieben
werden k¨
onnen: Inhalt, Kontext und Struktur. Bedauerlicherweise herrscht Uneinigkeit dar-
¨
uber, welche einzelnen Attribute der Metadaten relevant sind, besonders zwischen den Lagern
Technik und Didaktik. Dennoch hat es wenig Sinn, auf individuelle L¨
osungen zu setzen, weil
dies die Vorteile der Metadaten kompensiert.
Metadaten brauchen einen gemeinsamen logischen Raum, der Strukturen und Datenty-
pen vorgibt [Simon01]. Dieser l¨
asst sich nur ¨
uber Standards bilden, die formal und infor-
mell Vorgaben machen. Welchen Umfang solch eine Spezifikation haben sollte, wird z.B in
[Griffin97; Ahronheim98] beschrieben, wobei es haupts¨
achlich um Strukturelemente, Datenele-
mente, Methoden zur Manipulation, Verf¨
ugbarkeit von Werkzeugen und Verantwortlichkeiten
geht.
”Mit Hilfe von E-Learning-Standards l¨
asst sich also die Recherchierbarkeit, Aus-
tauschbarkeit und Wieder- bzw. Weiterverwendung von Lernressourcen gew¨
ahrleis-
ten, indem sie mit Metadaten nach einem einheitlichen Muster in maschinenlesba-
rer Form beschrieben werden. Diese Standards sind eine zwingende Voraussetzung
f¨
ur die Interoperabilit¨
at von Lernressourcen und Lernsystemen, da sie die Schnitt-
stellen und Referenzmodelle f¨
ur den E-Learning-Bereich definieren.“ [Niegemann04,
S. 270]
Im Zusammenhang mit Metadaten tauchen immer wieder Begriffe auf, die teilweise ver-
schieden interpretiert werden. Um Konfusionen zu vermeiden, werden kurz die wichtigsten
34 Metadaten
benannt und f¨
ur diese Arbeit definiert. Ein Metadaten-Element ist als abstrakte Einheit zu
verstehen, die zur Strukturierung — umfasst die erlaubten Unterelemente und ihre Kardinali-
t¨
at — und Notation von Daten — gibt die Syntax g¨
ultiger Literale (Zeichenketten) vor, auch
Wertebereich genannt — dient. Das Metadaten-Element ”Ersteller“ k¨
onnte z.B. ein Unter-
element ”Namen“ haben, dessen Wertebereich die Namen aller Mitarbeiter/-innen eines Unter-
nehmens ist. Mehrere koh¨
arente Metadaten-Elemente werden zu einem Metadaten-Schema
zusammengefasst und mit einem Namen versehen. Wenn nun f¨
ur Metadaten bekannt ist, nach
welchem Schema sie sich richten, k¨
onnen z.B. Validierungen und Interpretationen durchgef¨
uhrt
werden.
Bei der anschließenden Beschreibung der heute relevanten Metadaten-Standards wird sich
zeigen, dass die Spezifikationen entweder einen technischen oder didaktischen Schwerpunkt
haben. In der praktischen Anwendung f¨
uhren solche Spezialisierungen jedoch zu Problemen.
Kein Satz an dom¨
anenspezifischen Metadaten-Elementen wird ausreichen, um alle Aspekte
des Lernobjekts zu beschreiben. Abhilfe versprechen Application Profiles f¨
ur Metadaten,
bei denen verschiedene Metadaten-Schemata zusammengef¨
uhrt und angepasst werden.
”An application profile is an assemblage of metadata elements selected from one
or more metadata schemas and combined in a compound schema. Application
profiles provide the means to express principles of modularity and extensibility.
The purpose of an application profile is to adapt or combine existing schemas into
a package that is tailored to the functional requirements of a particular application,
while retaining interoperability with the original base schemas.“ [Duval02]
Ein Application Profile bedient sich mehrerer Mechanismen, bei denen die semantische
Interoperabilit¨
at bestehen bleibt. Durch Namespaces lassen sich Datenelemente der einzel-
nen Schemata direkt adressieren, sodass auch gleichnamige Attribute unterscheidbar sind. Sie
erlauben ebenfalls die Erweiterung mit eigenen Elementen. Eine Applikation, die nur standar-
disierte Schemata verarbeitet, wird zwar die selbst definierten Elemente nicht ad¨
aquat inter-
pretieren k¨
onnen, aber ohne weiteres die bekannten. Hierdurch bleiben die Metadaten f¨
ur die
einzelnen Dom¨
anen immer g¨
ultig. Handelt es sich bei Namespaces noch um eine echte Erweite-
rung, sind die restlichen Mechanismen Einschr¨
ankungen der g¨
ultigen M¨
oglichkeiten. In einem
Application Profile k¨
onnen die Kardinalit¨
aten strenger ausgelegt werden, als sie urspr¨
ung-
lich waren. Dann ist z.B. ein optionales Element als ein obligatorisches umdefiniert. ¨
Ahnlich
restriktiv k¨
onnen die g¨
ultigen Wertebereiche verkleinert werden. Mit der Festlegung von Be-
ziehungen zwischen Datenelementen und ihren Wertebereichen k¨
onnen bestimmte Strukturen
zugelassen werden. So kann z.B. die Existenz eines Datenelements ein anderes ausschließen,
oder ein bestimmter Wert den Wertebereich eines anderen Datenelements einschr¨
anken. Mehr
zu dem Thema Application Profile mit Beispielen findet sich in [Heery00; Dekkers01; Baker01].
Ein weiterer Ansatz zur Handhabung verschiedener Metadaten-Standards sind die Me-
tadata Registries. Hierbei handelt es sich um Systeme, die eine Reihe bestimmter Dienst-
leistungen anbieten. Der Funktionsumfang kann dabei stark variieren. Nach [Baker03, S. 12]
k¨
onnen folgende Fokusse f¨
ur Metadata Registries ausgemacht werden:
•Individueller Standard: Beinhaltet allgemeine Informationen ¨
uber einen bestimmten
Metadaten-Standard und Richtlinien zur Verwendung.
•Erweiterungen: Gibt an, wie ein Standard von Gruppen erweitert bzw. in eine andere
Sprache ¨
ubersetzt wurde.
•Data Warehouse: Speichert Definitionen von Datenelementen und Typen mit dem Ziel,
verschiedene Datenbanken an einer zentralen Stelle zu halten.
•Dom¨
ane: Benennt interessante Metadaten-Schemata f¨
ur Dom¨
anen, wie z.B. E-Learning,
Kultur und Wirtschaft.
4.1 Resource Description Framework 35
•Funktionen: Ordnen Metadaten-Schemata bestimmten Funktionen zu, wie z.B. Suchen,
Rechteverwaltung oder Leistungsbewertung.
•Unternehmen: Zugriff auf Taxonomien von Unternehmen oder anderen Gruppen.
•Anwendung: Bietet Schemata in verschiedenen Formaten und Syntaxen f¨
ur spezielle
Anwendungen an.
•Konvertierung: ¨
Ubersetzt Metadaten in das Format eines anderen Metadaten-Standards.
Ein interessantes Konzept zur Konvertierung auch inkompatibler Standards findet sich in
[Blanchi01]. Entw¨
urfe von Systemen werden in [Heery03; Heery02; Nagamori01] beschrieben.
Die technische Umsetzung von Metadaten l¨
asst sich in drei Schichten einteilen (vgl. Ab-
bildung 4.1).
a) Attribute Space
(e.g. LOM, Dublin Core, indecs)Layer 3
b) Value Space
(e.g. ontologies, classifications,
controlled vocabularies, taxonomies)
(e.g. XML, RDF)
Layer 2
Layer 1 Transport and Exchange
(e.g. HTTP Get)
Representation
Abbildung 4.1: Schichten f¨
ur Metadaten-Umsetzung nach [Baker03, S. 6]
Schicht 3 beinhaltet Strukturen und Wertebereiche, die von verschiedenen Organisationen
empfohlen bzw. standardisiert wurden. In dieser Arbeit wird besonders auf die Standards von
Dublin Core (DC, siehe Abschnitt 4.2) und Learning Objects Metadata (LOM, siehe
Abschnitt 4.3) eingegangen. Wegen ihrer Verbreitung und der Relevanz f¨
ur die Praxis sind
sie in die engere Wahl gekommen. Schicht 2 umfasst die m¨
oglichen Kodierungen, die auch
maschinell verarbeitbar sind, wie z.B. das allgemeine Rahmenwerk f¨
ur Metadaten Namens
Resource Description Framework (RDF). F¨
ur DC und LOM gibt es jeweils entsprechende
Abbildungen. XML wurde bereits in Abschnitt 3.7 als Format f¨
ur Inhalte vorgestellt, eignet
sich aber auch hervorragend f¨
ur die Kodierung komplexer Datenstrukturen wie Metadaten.
Andere Kodierungen werden aufgrund ihrer geringen Bedeutung nicht betrachtet. Auch der
Transport von Metadaten, in der Schicht 1 beschrieben, wird nicht weiter behandelt, weil
etablierte Infrastrukturen, wie z.B. das Protokoll HTTP, genutzt werden.
4.1 Resource Description Framework
Das Resource Description Framework (RDF) dient zur Auszeichnung von Web-Ressourcen
mit zus¨
atzlichen Metadaten. Dies sind z.B. Angaben ¨
uber den/die Autor/-in, das Datum der
¨
Anderung oder Lizenzbedingungen. Als Web-Ressource kann jedes Objekt bezeichnet werden,
welches sich ¨
uber das Web identifizieren l¨
asst. Auf eine direkte Verf¨
ugbarkeit ¨
uber das Internet
kommt es dabei nicht an. Gegenst¨
ande eines Web-Shops k¨
onnen z.B. mit Preisen, Verf¨
ugbarkeit
etc. ausgezeichnet sein, obwohl sie freilich nur ¨
uber den Postweg zu den Kunden gelangen.
RDF dient in erster Linie der maschinellen Verarbeitung und ist weniger f¨
ur eine direkte
Verwendung durch Menschen gedacht. Mit seiner Hilfe sollen Metadaten direkt von einer An-
wendung zur n¨
achsten ¨
ubertragen werden, ohne dass es zu einem Informationsverlust kommt.
Weil RDF eine offene, allgemein gehaltene Spezifikation ist, k¨
onnen die Autoren/-innen von
Web-Ressourcen auf eine Reihe von RDF-Libraries und Werkzeugen zur¨
uckgreifen. Die fol-
gende Beschreibung beruht auf dem RDF Primer von [Manola03].
36 Metadaten
Die Identifikation von Ressourcen erfolgt ¨
uber die Uniform Resource Identifier (URI)
[Berners-Lee98]. Im Gegensatz zu den Uniform Resource Locators (URL) [Berners-Lee94],
die im World Wide Web (WWW) den Zugriff auf physikalisch existierende Ressourcen regeln,
sind die URIs allgemeiner definiert1. Mit ihrer Hilfe k¨
onnen alle Dinge bezeichnet werden, die
Bestandteil einer Modellierung sind und bilden somit die Grundlage f¨
ur die Auszeichnung von
Web-Ressource mit Metadaten. Um den Inhalt einer Ressource genauer differenzieren zu k¨
on-
nen, nutzt RDF die Fragment Identifier, die stets durch ein #an eine URI angeh¨
angt werden.
Dieses Konstrukt nennt sich dann URI Reference (URIref), dargestellt im folgenden Beispiel:
http://www.upb.de/index.html =⇒eine HTML-Seite
http://www.upb.de/index.html#section2 =⇒ein Abschnitt
Alle zus¨
atzlichen Metadaten einer Ressource werden durch Properties (Eigenschaften) an-
gegeben, die jeweils aus einem Namen und zugeh¨
origen Werten bestehen. Beispielsweise kann
die HTML-Seite mit dem Ersteller ”Michael Bungenstock“ versehen werden, was in nat¨
urlicher
Sprache wie folgt beschrieben werden kann:
http://www.upb.de/index.html hat ein Ersteller mit dem Wert Michael Bungenstock
Die wichtigen Bestandteile dieser Aussage sind durch Formatierung hervorgehoben. F¨
ur
eine genauere Strukturbeschreibung besitzt RDF eine eigene Terminologie, die in Tabelle 4.1
erl¨
autert ist.
Wort Begriff Beschreibung
http://www.upb.de/index.html Subjekt Ressource
Ersteller Pr¨
adikat Eigenschaft
Michael Bungenstock Objekt Wert
Tabelle 4.1: RDF-Terminologie
Nun dient RDF in erster Linie der maschinellen Verarbeitung, sodass eine Sprache ben¨
otigt
wird, mit deren Hilfe Subjekt, Pr¨
adikat und Objekt eindeutig angegeben werden k¨
onnen. Da
f¨
ur den Zugriff auf Ressourcen bzw. das Subjekt bereits die URIs eingef¨
uhrt wurden, liegt es
nahe, dies auch f¨
ur die beiden anderen Begriffe zu tun.
http://www.upb.de/index.html =⇒Subjekt
http://purl.org/dc/elements/1.1/creator =⇒Pr¨
adikat
http://www.getlab.de/staffid/83427 =⇒Objekt
Die URI f¨
ur das Subjekt ist klar, da sie gleichzeitig als URL f¨
ur das Dokument inter-
pretiert werden kann. Bei der Wahl des Pr¨
adikats ist nicht auf den ersten Blick ersichtlich,
warum diese kryptische URI eines anderen Anbieters eingesetzt wird. W¨
urde ein einfaches
Literal wie z.B. creator nicht ausreichen? Das Problem ist die Eindeutigkeit, die bei einem
einfachen Wort wie creator sicherlich nicht gew¨
ahrleistet w¨
are. Abh¨
angig vom Kontext kann
es zu verschiedenen Interpretationen kommen, da kein eindeutiges Konzept identifiziert wird.
Bei der Beispiel-URI ist das anders. Eine mit Dublin Core (siehe Abschnitt 4.2) vertraute
Person kann sofort die Bedeutung des Pr¨
adikats erkennen. Aus dem Beispiel l¨
asst sich eben-
falls die Schlussfolgerung ziehen, dass bekannte URIs eigenen vorzuziehen sind. Was n¨
utzen
die sch¨
onsten URIs, wenn weder Mensch noch Maschine sie sinnvoll interpretieren k¨
onnen?
Beim Objekt ist dies freilich anders, weil die Werte zu speziell sind, als dass sie allgemein
definiert werden k¨
onnten. Je nach Komplexit¨
at des Wertes, k¨
onnen entweder Ressourcen oder
Literale als Objekt dienen. Im Beispiel werden Daten ¨
uber Mitarbeiter/-innen als Ressourcen
modelliert, um mehr Informationen ¨
uber die betreffende Person bereitstellen zu k¨
onnen, wie
z.B. Abteilung, Telefonnummer und E-Mail-Adresse.
1Alle URLs sind eine echte Teilmenge der URIs
4.1 Resource Description Framework 37
Diese Relationen lassen sich auch in Form von Graphen illustrieren: Subjekt und Objekt
sind Knoten, die durch das Pr¨
adikat, dargestellt als Pfeil, verbunden sind. Abbildung 4.2 zeigt
das gleiche Beispiel in grafischer Form.
http://www.upb.de/index.html
http://www.getlab.de/staffid/83427
http://purl.org/dc/elements/1.1/creator
Abbildung 4.2: RDF-Graph f¨
ur den Mitarbeiter Michael Bungenstock
Nun soll das Beispiel durch zwei weitere Aussagen ¨
uber Erstellungsdatum und Sprache
erweitert werden:
http://www.upb.de/index.html hat ein Erstellungsdatum mit dem Wert 4.11.2002
http://www.upb.de/index.html hat eine Sprache mit dem Wert deutsch
Diese Werte werden als Zeichenketten angegeben, weil sie keine weitere relevante Struktur
aufweisen und die Interpretation des Wertes von der Applikation abh¨
angt. Es sei ausdr¨
ucklich
darauf hingewiesen, dass Literale lediglich f¨
ur Objekte genutzt werden und nie f¨
ur Subjekte
bzw. Pr¨
adikate. Durch den Zeichensatz Unicode [Aliprand03] k¨
onnen Werte in vielen Spra-
chen direkt dargestellt werden. Bei der grafischen Darstellung werden die Literale in K¨
asten
gezeichnet, wie in Abbildung 4.3 zu sehen ist.
http://www.upb.de/index.html
4.11.2002
http://www.getlab.de/staffid/83427
de
http://purl.org/dc/elements/1.1/creator
http://www.upb.de/terms/creation_date
http://purl.org/dc/elements/1.1/language
Abbildung 4.3: RDF-Graph mit Ressourcen und Literalen
Um die maschinelle Verarbeitung dennoch stabiler zu halten, k¨
onnen in RDF Typed Lite-
rals definiert werden. Das sind Zeichenketten mit einem bestimmten Typ — wie von Program-
miersprachen oder Datenbanken her bekannt —, der Wertebereich, Ordnung, und Operationen
festlegt. Anstatt das Erstellungsdatum “4.11.2002” als bloße Aneinanderreihung von Zeichen
zu deuten, lassen sich Tag, Monat und Jahr ablesen. Ohne eine Interpretation des Literals w¨
ur-
den syntaktische und semantische Fehler (z.B. ein falsches Datum ”4.13.2002” oder ”.11.2002”)
nicht fr¨
uhzeitig erkannt werden. Im Gegensatz zu den genannten Programmiersprachen und
Datenbanken bietet RDF keine eingebauten Datentypen an, weshalb sie extern definiert und
¨
uber Datentypen-URIs referenziert werden. Ein Vorteil dieses Ansatzes ist die Flexibilit¨
at beim
Umgang mit Datentypen aus verschiedenen Quellen, da f¨
ur eine direkte Darstellung der Werte
keine Umwandlung auf vordefinierte Datentypen n¨
otig ist. Bei der Definition orientiert sich
RDF konzeptionell an einer Typdefinition der XML-Schemata-Spezifikation [Biron01], wonach
ein Datentyp wie folgt beschrieben ist:
•eine definierte Menge von Werten (Wertebereich genannt),
38 Metadaten
•eine definierte Menge von Zeichenketten (lexikalischer Bereich genannt)
•und eine Abbildung vom lexikalischen Bereich in den Wertebereich.
Die Zeichenkette “4.11.2002” des Beispiels kann folglich bei einem Datumstypen auf das
Datum 4. April 2002 abgebildet werden. Vorstellbar sind auch die Schreibweisen “2002-11-
4”, “11/4/2002”, etc. als g¨
ultige Literale f¨
ur dasselbe Datum, wenn es eine entsprechende
Abbildung gibt.
Die Notation von typisierten Literalen in RDF setzt sich aus einer Zeichenkette und einer
URIref f¨
ur den Datentyp zusammen. Als Separator dient die Zeichenfolge ^^, sodass auch
in der grafischen Repr¨
asentation lediglich ein Knoten ben¨
otigt wird. Abbildung 4.4 zeigt das
Beispiel aus Abbildung 4.3 erweitert um Typinformationen.
http://www.upb.de/index.html
http://www.getlab.de/staffid/83427
"de"^^http://www.w3c.org/2001/XMLSchema#language
"2002−11−4"^^http://www.w3c.org/2001/XMLSchema#date
http://purl.org/dc/elements/1.1/creator
http://purl.org/dc/elements/1.1/language
http://www.upb.de/terms/creation_date
Abbildung 4.4: RDF-Graph mit typisierten Literalen
Gelegentlich ist die grafische Darstellung von RDF-Daten ungeeignet und eine schriftliche
vorzuziehen. Anstatt der nat¨
urlichsprachlichen Schreibweise sieht RDF Tripel vor, die aus
Subjekt, Pr¨
adikat und Objekt bestehen. URIrefs werden in spitzen Klammern geschrieben,
Literale in Anf¨
uhrungszeichen und jedes Tripel entspricht einem Pfeil im Graphen mit Start-
sowie Endpunkt.
<http://www.upb.de/index.html> <http://purl.org/dc/elements/1.1/creator> ←-
<http://www.getlab.de/staffid/83427>
<http://www.upb.de/index.html> <http://www.upb.de/terms/creation_date> ←-
"2002-11-4"^^<http://www.w3c.org/2001/XMLSchema#date>
<http://www.upb.de/index.html> <http://purl.org/dc/elements/1.1/language> ←-
"de"^^<http://www.w3c.org/2001/XMLSchema#language>
Augenf¨
allig ist der Platzbedarf dieser Darstellung, bei der die Tripel nicht in eine Zeile
passen (←-zeigt den Fortgang des Tripels ohne Zeilenumbruch). Dies liegt einerseits an der
Redundanz, da ein Subjekt bzw. Objekt in jedem Tripel explizit angegeben werden muss, an-
dererseits an den langen URIrefs. Letztere lassen sich durch qualifizierte Namen (QNames)
in eine k¨
urzere Form ¨
uberf¨
uhren. Ein QName besteht aus einem Pr¨
afix, das f¨
ur eine Namespace
URI steht, einem Doppelpunkt als Separator und einem lokalen Bezeichner. F¨
ur das Beispiel
werden nun folgende QName-Pr¨
afixe definiert:
Pr¨
afix dc, Namespace http://purl.org/dc/elements/1.1/
Pr¨
afix xsd, Namespace http://www.w3.org/2001/XMLSchema#
Pr¨
afix upb, Namespace http://www.upb.de/
Pr¨
afix upbt, Namespace http://www.upb.de/terms/
Pr¨
afix get, Namespace http://www.getlab.de/staffid/
4.1 Resource Description Framework 39
Daraus folgt f¨
ur die Tripel des Beispiels:
upb:index.html dc:creator get:83427
upb:index.html upbt:creation_date "2002-11-4"^^xsd:date
upb:index.html dc:language "de"^^xsd:language
Bei RDF werden Mengen zusammenh¨
angender URIrefs als Vokabular bezeichnet. Wenn
sich alle URIrefs ein gemeinsames Pr¨
afix teilen, dann lassen sich mit QNames effizient die Ele-
mente der Menge bestimmen. Teilweise werden die Pr¨
afixe der QNames selbst als Bezeichner
f¨
ur Vokabulare genutzt, z.B. dc-Vokabular f¨
ur die Menge der URIrefs von Dublin Core.
Abschließend soll noch auf komplexere Datenstrukturen eingegangen werden, wie sie in
praktischen Anwendungen vorkommen. Als Ausgangspunkt dient die Ressource get:83427
des vorangegangen Beispiels, die den Mitarbeiter Michael Bungenstock identifiziert. Eine Rei-
he von Metadaten bieten sich an, die mit dieser Person in Verbindung stehen, wie z.B. die
Adresse. In Tripel-Form, das Pr¨
adikat wird als ungetyptes Literal geschrieben, sieht diese Ei-
genschaft wie folgt aus:
get:83427 upbt:address "Pohlweg 47-49, 33098 Paderborn"
Eine Analyse des Literals f¨
allt der vielen Daten wegen — Straße, Hausnummer, Postleit-
zahl und Ort m¨
ussen unterschieden werden — recht aufwendig aus. Daher ist es sinnvoll, die
Adresse in ihre Bestandteile zu zerlegen. Die Konsequenz dieser Umstrukturierung ist eine
neue Ressource address f¨
ur jeweils jede/-n Mitarbeiter/-in mit vier neuen Pr¨
adikaten. Zur
Identifikation dieses Objekts wird der Namespace http://www.getlab.de/addrid/ mit dem
Pr¨
afix getaddr definiert. Die Tripel lauten:
get:83427 upbt:address getaddr:83427
getaddr:83427 upbt:street "Pohlweg"
getaddr:83427 upbt:street_no "47-49"
getaddr:83427 upbt:city "Paderborn"
getaddr:83427 upbt:zip "33098"
Abbildung 4.5(a) zeigt den passenden Graphen.
http://www.getlab.de/staffid/83427
http://www.getlab.de/addrid/83427
47−49 Paderborn
Pohlweg 33098
http://www.upb.de/terms/address
http://www.upb.de/terms/cityhttp://www.upb.de/terms/street_no
http://www.upb.de/terms/street http://www.upb.de/terms/zip
(a) Eigene Ressource f¨
ur Adressen
http://www.getlab.de/staffid/83427
47−49 Paderborn
Pohlweg 33098
http://www.upb.de/terms/address
http://www.upb.de/terms/cityhttp://www.upb.de/terms/street_no
http://www.upb.de/terms/street http://www.upb.de/terms/zip
(b) Anonyme Ressource
Abbildung 4.5: Strukturierte Adresse
Auf diese Weise m¨
ussen bei komplexen Datenstrukturen eine Reihe von zus¨
atzlichen UR-
Irefs erzeugt werden, die aber niemals ben¨
otigt werden. Es gibt keinen vern¨
unftigen Grund,
die Ressource getaddr:83427 jemals direkt aufzurufen. Sie ist nur ein Konstrukt, um eine
Adresse ad¨
aquat zu modellieren. Abbildung 4.5(b) zeigt eine alternative Darstellung, bei der
die zus¨
atzliche URIref ausgelassen wird.
40 Metadaten
Knoten ohne URIref werden als leere Knoten bezeichnet und referenzieren anonyme
Ressourcen. Sie k¨
onnen beliebig oft in Graphen eingesetzt werden, sind aber nicht unter-
scheidbar. Diese Eigenschaft f¨
uhrt bei der Tripel-Darstellung unweigerlich zu Problemen. Da
Tripel nur indirekt ¨
uber Bezeichner verbunden sind, muss ein Symbol f¨
ur anonyme Ressourcen
definiert sein. Wenn keine zus¨
atzlichen Regeln bei der Verarbeitung gelten, wie z.B. die Rei-
henfolge oder eine Trennung durch Leerzeilen, dann ist die korrekte Interpretation unm¨
oglich.
Aus diesem Grund definiert RDF f¨
ur die Tripel-Schreibweise leere Knoten mit Bezeichner.
Die Notation ist ein Unterstrich, gefolgt von einem Doppelpunkt und einem Namen, wie z.B.
_:bungeaddr. Daraus ergibt sich f¨
ur die Tripel des Beispiels:
get:83427 upbt:address _:bungeaddr
_:bungeaddr upbt:street "Pohlweg"
_:bungeaddr upbt:street_no "47-49"
_:bungeaddr upbt:city "Paderborn"
_:bungeaddr upbt:zip "33098"
Neben den Graphen und Tripel hat RDF noch eine Syntax f¨
ur XML, die RDF/XML
[Beckett03] genannt wird. Sie ist die normative Syntax f¨
ur RDF, auf die sich alle Implemen-
tationen st¨
utzen. F¨
ur die direkte Betrachtung durch den Menschen sind die XML-Konstrukte
jedoch wenig geeignet und bringen konzeptionell nichts Neues, weshalb eine ausf¨
uhrliche Be-
handlung an dieser Stelle nicht erforderlich ist. Weitere Informationen finden sich in z.B.
[Powers03; Hjelm01]. Die Realisierung von Application Profiles mit Hilfe von RDF wird in
[Hunter01] beschrieben und Anfragen auf Metadaten im RDF-Format in [Nejdl02].
4.2 Dublin Core Metadata
Bei den Dublin Core Metadaten (DC) [Dub99] handelt es sich um einen Konsens ¨
uber Kern-
elemente, dessen Ursprung und Namensgebung in einem Workshop im M¨
arz 1995 in Dublin
(Ohio) liegt. Zur Beschreibung von Ressourcen sind f¨
unfzehn verschiedene Elemente definiert,
deren Semantik durch internationale, interdisziplin¨
are Gruppen von Bibliothekaren, Informati-
kern und Angeh¨
origen verwandter Wissenschaften definiert wurde. Die Werte f¨
ur jedes Element
k¨
onnen frei gew¨
ahlt werden, jedoch gibt es teilweise Empfehlungen f¨
ur den Einsatz definierter
Vokabulare.
1. Title: Ist der Name, unter dem eine Ressource bekannt ist.
2. Creator: Sind beispielsweise Personen, Organisationen oder Dienste, die sich verant-
wortlich f¨
ur die Erstellung zeigen.
3. Subject: Umfasst das Thema der Ressource. Meist werden Schl¨
usselw¨
orter oder Codes
f¨
ur Kategorien eingesetzt.
4. Description: Beschreibt den Inhalt. Hierzu geh¨
oren z.B. Zusammenfassungen oder In-
haltsverzeichnisse.
5. Publisher: Sind beispielsweise Personen, Organisationen oder Dienste, die sich verant-
wortlich f¨
ur die Ver¨
offentlichung zeigen.
6. Contributor: Sind beispielsweise Personen, Organisationen oder Dienste, die in irgend-
einer Form beteiligt sind.
7. Date: Ist ein Datum eines Ereignisses im Lebenszyklus einer Ressource. Empfehlenswert
ist das Erstellungsdatum.
8. Type: Beschreibt den Typ oder die Art einer Ressource.
4.3 Learning Object Metadata 41
9. Format: Gibt die physikalische Form einer Ressource an.
10. Identifier: Ist eine eindeutige Referenz in einem gegebenen Kontext.
11. Source: Referenziert eine andere Ressource, von der die beschriebene abgeleitet wurde.
12. Language: Identifiziert die Sprache des Inhalts.
13. Relation: Beschreibt Beziehungen jeglicher Art zu anderen Ressourcen.
14. Coverage: Gibt den r¨
aumlichen und zeitlichen Rahmen vor.
15. Rights: Informiert ¨
uber Eigentums- und Nutzungsrechte.
Wie das Wort Core im Namen bereits andeutet, handelt es sich um einen Satz funda-
mentaler Metadaten, die sich ebenfalls in koexistierenden Spezifikationen wiederfinden. DC ist
somit pr¨
adestiniert f¨
ur Application Profiles (siehe Empfehlungen f¨
ur den Einsatz in [CEN03]).
F¨
ur eine Identifizierung der Elemente sieht z.B. [Bearman99] Qualifizierer vor. Eine andere
M¨
oglichkeit ist, Dublin Core als eine Art Sprache auszulegen, in der bestimmte Klassen von
Begriffen f¨
ur Ressource definiert sind [Baker00]. In diesem Fall sind es Nomen f¨
ur die Elemen-
te und Adjektive als Kennzeichen, die zusammen mit den Nomen in einer einfachen Syntax,
wie z.B. RDF (siehe Abschnitt 4.1), notiert werden. Aus dieser einfachen Definition l¨
asst sich
schließen, dass Dublin Core einfach einzusetzen, jedoch weniger f¨
ur komplexe Beziehungen oder
Konzepte geeignet ist. In [CEN03] stehen Empfehlungen f¨
ur den Einsatz von DC Application
Profiles (DCAP) und ein Erfahrungsbericht findet sich z.B. in [Friesen02].
Die Bedeutung dieses Standards f¨
ur diese Arbeit zeigt sich in den Elementabbildungen
anderer relevanter Metadaten-Standards wie z.B. LOM (n¨
achster Abschnitt). In der Spezifika-
tion von LOM steht genau beschrieben, wie einzelne Eintr¨
age auf die f¨
unfzehn Elemente von
DC abgebildet werden.
4.3 Learning Object Metadata
Der Standard Learning Object Metadata (LOM) [IEE02a] spezifiziert die Semantik und Syntax
von Metadaten f¨
ur Lernobjekte (siehe Kapitel 3). Haupts¨
achlich geht es um Datenstrukturen,
mit denen die Eigenschaften von Lernobjekten vollst¨
andig beschrieben werden. Neben dem
Konzept, das hier vorgestellt wird, gibt es noch Spezifikationen f¨
ur XML- [IEE02b] sowie RDF-
Bindings [IEE; Nilsson03] (siehe Abschnitt 4.1), die jedoch nur f¨
ur technische Umsetzungen
interessant sind und an dieser Stelle nicht weiter behandelt werden.
F¨
ur LOM sind Lernobjekte alle digitalen oder nicht digitalen Einheiten, die zum Lernen
bzw. Lehren genutzt werden. Mit Hilfe der Metadaten k¨
onnen sie charakterisiert werden, was
ihre Suche, Evaluation, Beschaffung und Nutzung vereinfacht. Ein Problem ist die große Menge
an potentiellen Attributen, die sich als Metadaten eignen. Um Struktur in die Datenmenge
zu bringen, erfolgt eine Aufteilung in Kategorien, von denen es bei LOM insgesamt neun
gibt: General,Life Cycle,Meta-Metadata,Technical,Educational,Rights,Relation,
Annotation und Classification. Der Aufbau der Attribute kann recht unterschiedlich sein.
Es gibt einfache Werte, zusammengesetzte Felder, Listen und hierarchische Datenstrukturen,
die alle als obligatorisch oder optional markiert werden k¨
onnen. Da auch die besten Strukturen
nur dann helfen, wenn die Anzahl der jeweiligen Attribute handhabbar ist, wurde bei der
Festlegung von LOM darauf geachtet, ihre Menge so gering wie m¨
oglich zu halten.
In der Datenstruktur von LOM bilden die neun Kategorien die oberste Ebene mit folgender
Bedeutung:
a) General: Umfasst generelle Daten, die sich auf das gesamte Lernobjekt beziehen.
b) Life Cycle: Gruppiert alle Eigenschaften, die mit dem Verlauf bzw. dem aktuellen Stand
des Lernobjekts in Verbindung stehen.
42 Metadaten
c) Meta-Metadata: Beschreibt zus¨
atzliche Daten ¨
uber die Metadaten selbst.
d) Technical: Gibt die technischen Voraussetzungen an, die f¨
ur einen reibungslosen Einsatz
notwendig sind.
e) Educational: Charakterisiert die didaktischen Eigenschaften der Inhalte.
f) Rights: Erm¨
oglicht Nutzungsklauseln und Copyright-Vermerke.
g) Relation: Beschreibt Beziehungen und Abh¨
angigkeiten zu anderen Lernobjekten.
h) Annotation: Speichert alle Kommentare inklusive Verfasser/-in ¨
uber den eigentlichen
Einsatz.
i) Classification Erlaubt die Nutzung eigener Klassifikationssysteme.
Der Aufbau der Struktur l¨
asst sich auch grafisch darstellen. Abbildung 4.6(a) zeigt die neun
Kategorien mit den m¨
oglichen Kardinalit¨
aten (im folgenden durch nabgek¨
urzt). Das Symbol
?
steht f¨
ur ein optionales Element (n∈ {0,1}). Mit
*
wird eine beliebige Kardinalit¨
at
angegeben (n∈ {0,1,2,3, ...}).
general
lifecycle
technical
rights
relation
*
*
*
?
?
?
?
?
?
lom
classification
annotation
metametadata
educational
(a) Die oberste Ebene
*
?
?
?
?
*
*
*
*
**
general
entry
catalog
*
identifier
title
catalogentry
language
description
keyword
coverage
structure
aggregation
(b) Die Kategorie General
Abbildung 4.6: Beispiele f¨
ur Strukturen in LOM (von [IEE02a] abgeleitet)
Die komplette Struktur von LOM ist zu umfangreich, als dass sie hier vollst¨
andig er¨
ortert
werden k¨
onnte. Abbildung 4.6(b) zeigt exemplarisch die Kategorie General. Unterhalb des
Elements general kommen die eigentlichen Datenelemente, die verschieden komplex sind. Es
gibt einfache Datenelemente f¨
ur Werte und zusammengesetzte f¨
ur komplexere Strukturen. In
Anlehnung an einen Baum in der Graphentheorie spricht die LOM-Spezifikation bei einfachen
Datenelementen von Bl¨
attern, bei zusammengesetzten von Knoten. Abbildung 4.7 zeigt die
verschiedenen Ebenen innerhalb des Baums.
Jeder Knoten, wie z.B. das Datenelement catalogentry, dient nur zur Strukturierung
und kann niemals einen eigenen Wert besitzen. Neben dem Namen sieht die Spezifikation
f¨
ur jedes Datenelement noch eine Kardinalit¨
at und — wenn es sich um Bl¨
atter mit einer
Kardinalit¨
at n > 0 handelt — eine Ordnung vor. Trifft die letztgenannte Bedingung zu, wird
auch von einer Liste gesprochen. Bei einer geordneten Liste muss die Reihenfolge der Bl¨
atter
ber¨
ucksichtigt werden, wohingegen sie bei einer ungeordneten Liste keine Bedeutung hat.
Einfache Datenelemente sind zudem noch mit einem Typ versehen, der den Wertebereich
der erlaubten Werte angibt. Vorgesehen sind die Typen LangString,DateTime,Duration,
Vocabulary,CharacterString und Undefined.
4.3 Learning Object Metadata 43
general
title
langstringtype
catalogenty
language: "en−US"
string: "Becoming a Meta−Data Expert
catalog: "ISBN"
entry: "0−226−10389−7"
lifecycle
(version, status, etc.)
lom
"Leaves""Branches""Root"
Abbildung 4.7: Aufbau von LOM als Baum nach [IMS03b]
Ein LangString wird f¨
ur unterschiedliche lokale Werte eingesetzt, dient also der Inter-
nationalisierung (I18N2) von Metadaten. Er besteht aus einem Sprach-Code nach ISO-639
[Int88; Int98] in Kombination mit einem optionalen L¨
ander-Code [Int97] und dem eigentli-
chen Literal in der Codierung Universal Multiple-Octet Coded Character Set (UCS) [Int02].
F¨
ur jede unterst¨
utze Sprache wird ein LangString angelegt, was z.B. in XML folgendermaßen
aussieht:
1<desciption>
<langstring xml:lang=”en”>Leaving Certificate</langstring>
3<langstring xml:lang=”en−GBR”>A−Level</langstring>
<langstring xml:lang=”fr−FRA”>Baccalaur´eat</langstring>
5<langstring xml:lang=”de−DEU”>Abitur</langstring>
<langstring xml:lang=”de−AUT”>Matura</langstring>
7</description>
Mit DateTime werden Datums- und Zeitangaben ab dem Jahr 1 gemacht. Daten ab dem
15. Oktober 1582 gelten nach dem gregorianischen Kalender, davor liegende nach dem juliani-
schen. Die Werte werden als Zeichenketten angegeben, deren Wertebereich in ISO-8601 [Int00]
definiert ist. G¨
ultige Literale f¨
ur Datums- und Zeitangaben sind z.B. 1984,1857-06-06 und
1969-07-21T03:53. Zeitspannen basieren auf der Norm ISO-8601 und werden ebenfalls als
Zeichenketten mit dem Typ Duration notiert.
Eine Eigenheit dieser Notation sind die vielen Kombinationsm¨
oglichkeiten der Werte,
durch die leider keine Eindeutigkeit mehr gegeben ist. So entsprechen z.B. PT2H30M,PT150M,
PT120M1800S, etc. ein und der selben Zeitspanne. Noch problematischer ist die Interpretation
von Monaten und Jahren. Ein Monat kann 28, 29, 30 oder 31 Tage haben und bei einem Jahr
kann es sich eventuell um ein Schaltjahr handeln. Das Literal P1M steht folglich f¨
ur verschiedene
Zeitspannen, die unterschiedlich sind.
P1M=P30T ∧P1M=P31T aber P30T6=P31T
Es liegt somit in den H¨
anden der Entwickler/-innen, eine einheitliche Darstellung in ihren
Anwendungen zu finden.
2I18N ist das Akronym f¨
ur den englischen Begriff Internationalization.
44 Metadaten
Metadaten sind oft subjektiver Natur, was zu einer individuellen Begriffsbildung f¨
uhren
kann. Die nat¨
urliche Sprache l¨
asst genug Raum f¨
ur Interpretationsschwierigkeiten, sodass der
Nutzen von Metadaten f¨
ur Mensch und Maschine beeintr¨
achtigt werden kann. Um diesem
Problem entgegen zu treten, definiert LOM den Datentyp Vocabulary, mit dem eine Menge
von Zeichenketten als g¨
ultiger Wertebereich definiert wird. Durch ihn wird die semantische
Interoperabilit¨
at erh¨
oht, da nur eine begrenzte Anzahl von Begriffen zur Auswahl steht. Bei
der Festlegung dieser Wortmengen ist es sogar m¨
oglich, die Semantik der einzelnen Begriffe
explizit zu erl¨
autern. Auch die maschinelle Verarbeitung wird sicherer, da eine ¨
Uberpr¨
ufung
durch das System m¨
oglich ist.
F¨
ur beliebige Werte sieht LOM den Typ CharacterString vor, bei dem nicht einmal die
Codierung vorgegeben wird. Lediglich die zu unterst¨
utzende Mindestl¨
ange der Zeichenketten
muss von den Systemen unterst¨
utzt werden. Bei manchen Datenelementen wird der Wer-
tebereich auf einen anderen Standard eingeschr¨
ankt, wie z.B. f¨
ur Personendaten (VCard
[Howes98; Dawson98]) und Formatkennungen (MIME Types [Freed96]). Datenelemente vom
Typ Undefined sollten nicht gesetzt werden, da sich ihre Bedeutung im weiteren Verlauf des
Standardisierungsprozesses ¨
andern kann.
Anhand der verf¨
ugbaren Anwendungen und Systeme kann mit Recht behauptet werden,
dass sich LOM als der Standard im E-Learning-Bereich durchgesetzt hat. Hiervon zeugen
auch die vielen Publikationen zu diesem Thema. In [Neven02] werden verschiedene Reposito-
ries evaluiert, die LOM zur Auszeichnung der Metadaten nutzen. Eine Erweiterung von LOM
f¨
ur multimediale Komponenten wird in [Saddik00; Saddik01] vorgestellt. Das europ¨
aische Pro-
jekt ARIADNE (Alliance Of Remote Instructional Authoring And Distribution Networks for
Europe), hat ein eigenes Application Profile auf Basis von LOM entwickelt [Najjar03; Duval00]
und ist der Versuch, mehr auf die europ¨
aischen Anforderungen f¨
ur Metadaten einzugehen.
Die Beschreibung von LOM verdeutlicht, dass der Schwerpunkt der beschriebenen Meta-
daten eindeutig technisch ist. Die bestehende Kritik, besonders aus dem didaktischen Lager,
soll nicht verschwiegen werden.
”Zurzeit ist es weder m¨
oglich, die Eignung von Ressourcen f¨
ur konkrete didaktische
Methoden zu bestimmen, noch k¨
onnen p¨
adagogische Planungsdetails (wie zum Bei-
spiel die Kommunikationsstruktur, Evaluation) erschlossen werden. Die Akzeptanz
der weniger technisch orientierten Lehrenden und Trainer h¨
angt maßgeblich von
derartigen Erweiterungen ab.“ [Pawlowski01, S. 107]
”Die von der IEEE LTSC empfohlenen LOM-Spezifikationen werden zunehmend in
aktuelle Lernplattformen implementiert und erlangen damit immer mehr prakti-
sche Relevanz. Zugleich stellen sie aber auch die p¨
adagogische Eignung dieser Ler-
numgebungen in Frage. Der Verzicht auf die Beschreibung didaktisch-methodischer
Aspekte, z.B der Verweis auf wichtige Kontextinformationen oder der Bezug zu
konkreten Anwendungsszenarien, provoziert geradezu bereits jetzt zu beobachten-
de Extremformen des elektronisch vermittelten Lernens, die als
just enough lear-
ning
,
granulares Lernen
und bisweilen auch als
Fast-Food-Learning
bezeich-
net werden.“ [Niegemann04, S. 272]
Kapitel 5
Autorenwerkzeuge
F¨
ur die Erstellung von Lernobjekten werden spezielle Werkzeuge gebraucht, so genannte Au-
torenwerkzeuge. Abh¨
angig von der gew¨
unschten Granularit¨
at (siehe Abschnitt 3.3) und dem
Format (siehe Abschnitt 3.7) k¨
onnen durchaus verschiedene Programme zum Einsatz kommen.
In der Regel werden z.B. Abbildungen mit Grafikprogrammen, Java Applets mit Programmier-
umgebungen und XML-Seiten mit XML-Editoren erstellt. Eine Anwendung f¨
ur alle Aufgaben
scheint daher wegen der vielf¨
altigen Inhalte unrealistisch zu sein. Aufgrund der Komplexit¨
at
des Erstellungsprozesses ist auch eine gemeinsame Betrachtung mit Lernplattformen (siehe
Kapitel 6) nicht ratsam, da die jeweiligen Anforderungen zu weit auseinander liegen. Den-
noch muss ein Kriterium bei der Bewertung von Autorensystemen und Lernplattformen die
M¨
oglichkeit zum Datenaustausch sein.
Andere Kriterien wie z.B. Funktionsumfang, Einarbeitungsaufwand, Preis, Systemvoraus-
setzungen und Kompatibilit¨
at werden allerdings ausschlaggebender sein. Ausgehend von der
Fragestellung, was eigentlich produziert werden soll, muss das richtige Produkt gew¨
ahlt wer-
den. Manche der Kriterien wirken gegeneinander. So sind Autorenwerkzeuge mit einem gr¨
oße-
ren Funktionsumfang teurer und anspruchsvoller in der Bedienung. Was aber n¨
utzt das beste
Autorenwerkzeug, wenn es nicht f¨
ur das eingesetzte Betriebssystem erh¨
altlich ist?
Neben den Werkzeugen sind auch Vorgehensmodelle f¨
ur den Erstellungsprozess von Be-
deutung. H¨
aufig sollen multimediale Inhalte erschaffen werden, was den Entwicklungsaufwand
massiv erh¨
oht. Um eine gewisse Qualit¨
at zu erreichen, wird Wissen aus verschiedenen Diszi-
plinen ben¨
otigt, wobei die Vorgehensmodelle hierbei meist auf Modellen der Softwaretechnik
basieren, wie z.B. in [Depke99] beschrieben.
Zu der Gruppe der Autorenwerkzeuge z¨
ahlen viele Programme, die sich in Aufgabe, Dar-
stellung und Funktionsumfang teilweise sehr unterscheiden. Es ist daher sinnvoll, vorweg eine
Klassifizierung einzuf¨
uhren, um eine bessere Vergleichbarkeit zwischen den Systemen anzubie-
ten, die ¨
ahnliche Aufgaben erf¨
ullen. Im n¨
achsten Abschnitt werden nur externe Programme
vorgestellt, die nicht Bestandteil einer Lernplattform sind.
5.1 Klassifizierung
Alle vorgestellten Programme dienen zur Erstellung Web-basierter E-Learning-Inhalte, wobei
die hierf¨
ur n¨
otigen Sprachen bzw. Formate f¨
ur die Anwender/-innen keine Rolle spielen sollen.
Grafische Oberfl¨
achen, m¨
oglichst mit ”
What You See Is What You Get“ (WYSIWYG), erlau-
ben eine schnelle Einarbeitung und vereinfachen die Arbeit. Anstatt z.B. HTML-Seiten direkt
zu erstellen, k¨
onnen Texte, Grafiken und dergleichen intuitiv mit der Maus zusammengestellt
werden. Es ist dann Aufgabe des Autorensystems, die Inhalte in eine entsprechende Kodierung
zu ¨
uberf¨
uhren. Trotz dieser verallgemeinerten Anforderung nach grafischer Bedienbarkeit gibt
es wesentliche Unterschiede, die eine Klassifizierung rechtfertigen.
Nach [H¨
afele03] lassen sich Autorensysteme grunds¨
atzlich in 6 Gruppen einteilen:
1. Professionelle Werkzeuge mit integrierter Programmiersprache und hohem Einarbei-
tungsaufwand
46 Autorenwerkzeuge
2. Standard WYSIWYG-HTML-Editoren mit speziellen Plugins f¨
ur E-Learning-Inhalte
3. Rapid Content Development Tools mit geringem Einarbeitungsaufwand
4. Content Converter f¨
ur eine Umwandlung bestehender Dokumente in geeignete Formate
5. Live Recording zum Mitschneiden von Vorlesungen, Vortr¨
agen und Pr¨
asentationen
6. Screen Movie Recorder zur Aufzeichnung von Programmsteuerungen
Eine Ausnahme sind noch die Editoren f¨
ur mathematische Formeln, da sie meist nicht
Bestandteil der anderen Autorensysteme sind. Obwohl es sich um eigenst¨
andige Programme
handelt, werden sie in der Klassifizierung nicht explizit hervorgehoben. Die ersten beiden
Klassen 1 und 2 geh¨
oren zu den klassische Autorensysteme, wie sie heute g¨
angig sind. Der
Trend geht jedoch hin zur schnellen Entwicklung von E-Learning-Inhalten, erm¨
oglicht durch
Programme der Klassen 3 bis 6. Abbildung 5.1 illustriert die Klassifizierung und nennt bereits
passende Produkte.
Autorenwerkzeuge
Professionelle WYSIWYG−HTML−
mit Plug−Ins
Editoren Rapid Content
Development Tools Systeme
Recording
Live Screen
Movie
Recorder
Content Converter
Lecturnity
Suite
WebLearner
etc. Builder etc.
Viewlet
Studio
Camtasia
etc.
Clix Content Converter
etc.
Powertrainer
Dynamic
Lectora Publisher
etc.
Microsoft Frontpage
Dreamweaver
MacromediaMacromedia
Authorware
Click2learn Toolbook
etc.
Learning Content Autorenwerkzeuge
Einarbeitungsaufwand
Abbildung 5.1: Systematik der Autorenwerkzeuge [H¨
afele03]
5.1.1 Professionelle Autorenwerkzeuge
Zu den hier vorgestellten professionellen Werkzeugen geh¨
oren Macromedia Authorware1,
Click2Learn ToolBook2und Matchware Mediator3. Sie zeichnen sich alle durch eine
detaillierte Programmierbarkeit und Gestaltung der Inhalte aus, setzen jedoch ein gewisses
Expertenwissen voraus.
Die aktuelle Version 7 von Authorware ist f¨
ur die Erstellung von multimedialen E-Learning-
Anwendungen auf CD-ROM/DVD und im Internet ausgerichtet. Zu den neuen Leistungen
dieses Produkts z¨
ahlen die Unterst¨
utzung von Standards f¨
ur Lernplattformen und der Import
von Microsoft PowerPoint-Folien. Durch eine automatische ¨
Uberwachung k¨
onnen die Lerner-
folge der Lernenden verfolgt werden. Personen, die bereits mit anderen Macromedia Produkten
vertraut sind, werden sich schnell an das Graphical User Interface (GUI) gew¨
ohnen und einen
schnellen Einstieg finden. Viele Arbeitsschritte k¨
onnen mit Drag’n’Drop erledigt werden und
durch das One-button publishing, bei dem lediglich ein Knopfdruck f¨
ur die Erstellung des
Endprodukts get¨
atigt wird. Automatisch wird ein Content Package (siehe Kapitel 3) erzeugt
und auf die Lernplattform hochgeladen. Auf diese Weise lassen sich sehr schnell Ergebnisse
erzielen. Die eigentliche St¨
arke liegt aber in der Programmierbarkeit, die jedoch einiges an
Erfahrung mit Skriptsprachen, z.B. JavaScript, abverlangt. F¨
ur Standardanwendungen, wie
z.B. Logins, Kurs-Rahmenwerke, ¨
Ubungen und Quiz, gibt es Templates und Wizards, die ohne
Programmierung auskommen. Abbildung 5.2 zeigt einen exemplarischen Screenshot.
1http://www.macromedia.com/software/authorware (29.10.05)
2http://www.toolbook.com (29.10.05)
3http://www.matchware.net/ge/products/mediator/default.htm (29.10.05)
5.1 Klassifizierung 47
Abbildung 5.2: Macromedia Authorware 7
Bei ToolBook handelt es sich um eine Produktlinie, die aus ToolBook Instructor und
ToolBook Assistant besteht. Beide Programme sind f¨
ur die Erstellung von Web-basierten
E-Learning-Inhalten in Unternehmen ausgelegt, unterscheiden sich aber in der Zielgruppe.
Richtet sich der Assistant mehr an fachliche Experten, die wenig technisches Wissen haben,
k¨
onnen mit dem Instructor Simulationen und interaktive Inhalte programmiert werden. Eine
WYSIWYG-Oberfl¨
ache mit Drag’n’Drop erlaubt eine einfache Nutzung beider Produkte und
Wizards,Templates sowie eine große Auswahl an fertigen Objekten erleichtern eine schnelle
Produktion. Die erzeugten Inhalte k¨
onnen von beiden Programmen verarbeitet werden. So
ist es z.B. m¨
oglich, komplexere Templates mit dem Instructor zu erstellen, die dann im As-
sistant zum Einsatz kommen. Ein weiteres Plus von ToolBook ist die nahtlose Anbindung zu
verschiedenen Lernplattformen.
Den Mediator in der Version 7 gibt es als Standard,Pro und EXP. Die Ausgabe Standard
bietet einen Einstieg in die Erstellung multimedialer CDs und Flash-Seiten. Ohne Program-
mierkenntnisse und mit Drag’n’Drop k¨
onnen auf diese Weise einfache Ergebnisse produziert
werden. F¨
ur die Erstellung von E-Learning-Inhalten empfiehlt der Hersteller selbst die Ver-
sion Pro, da weitergehende Funktionen angeboten werden. In einem Ereignisdialog k¨
onnen
Ereignisse wie ”Maus loslassen“ oder ”Taste gedr¨
uckt“ mit Aktionen wie ”Seitenwechsel“ oder
”Cursor verschieben“ grafisch verkn¨
upft werden. Hierdurch k¨
onnen echte Interaktionen reali-
siert werden, aber eine direkte Programmierung mit JavaScript ist nur in der Ausgabe EXP
m¨
oglich.
5.1.2 WYSIWYG-HTML-Editoren
Mit WYSIWYG-HTML-Editoren k¨
onnen auf einfache Weise HTML-Seiten erstellt werden.
Per Maus lassen sich Texte, Bilder, Animation etc. kombinieren und ausrichten, ¨
ahnlich einer
Textverarbeitung. Mittlerweile sind die Programme so weit im Funktionsumfang fortgeschrit-
48 Autorenwerkzeuge
ten, dass so gut wie keine Programmierung von Hand mehr durchzuf¨
uhren ist. Besonders bei
der Erstellung von L¨
osungen wiederkehrender Aufgaben in JavaScript, wie z.B. Navigation
oder der Wert¨
uberpr¨
ufung in Formularen, stellen die WYSIWYG-HTML-Editoren eine große
Hilfe dar. Zu den oft genutzten Programmen dieser Gattung z¨
ahlen sicherlich Macromedia
Dreamweaver4,Adobe GoLive5,NetObjects Fusion6und Microsoft Frontpage7. F¨
ur
die direkte Erstellung von E-Learning-Inhalten sind sie jedoch nur bedingt geeignet, weil sie
meist keine Standards wie SCORM oder AICC unterst¨
utzen.
F¨
ur Dreamweaver gibt es eine Reihe an Erweiterungen speziell f¨
ur E-Learning-Inhalte, die
als Plugins direkt in das Programm integriert werden und kostenfrei bei Macromedia im E-
Learning-Bereich8heruntergeladen werden k¨
onnen. Die wichtigste Erweiterung ist der Cour-
seBuilder, mit dem ¨
uber 40 vorgefertigte Lerninteraktionen, Quiz- und Bewertungsvorlagen
zur Verf¨
ugung stehen. Abbildung 5.3 zeigt das Dialogfenster dieser Erweiterung.
Abbildung 5.3: Macromedia CourseBuilder-Erweiterung f¨
ur Dreamweaver
Mit Hilfe der Learning Site-Befehlserweiterung k¨
onnen Kursaktivit¨
aten, wie z.B. ein
Quiz, aus verschiedenen Quellen zusammengestellt werden. ¨
Uber integrierte Navigationsfunk-
tionen und Tracking-Features lassen sich die Aktivit¨
aten der Lernenden in einer Datenbank
protokollieren. Durch die SCORM RTI-Erweiterung (Sharable Content Object Reference
Model Runtime Interface) k¨
onnen die Inhalte so gespeichert werden, dass sie den SCORM-
Standards f¨
ur die Runtime-Umgebung entsprechen. Die Manifest Maker-Erweiterung gene-
riert aus der Struktur eine Manifest-Datei in XML, die allen Spezifikationen des IMS Content
Packaging entspricht (siehe Abschnitt 3.5).
4http://www.macromedia.com/software/dreamweaver (29.10.05)
5http://www.adobe.com/products/golive (29.10.05)
6http://www.netobjects.com (29.10.05)
7http://www.microsoft.com/frontpage (29.10.05)
8http://www.macromedia.com/de/resources/elearning/extensions/dw_ud (29.10.05)
5.1 Klassifizierung 49
5.1.3 Content Converter
Aus gehaltenen Vorlesungen, Vortr¨
agen und Pr¨
asentationen existieren oftmals Materialien in
digitaler Form, die sich jedoch nicht direkt f¨
ur das E-Learning eignen. Durch Anpassung bzw.
Umwandlung k¨
onnen jedoch ad¨
aquate Ergebnisse erreicht werden, die eine einfache Integration
in ein LMS erm¨
oglichen. Die Klasse der Content Converter richtet sich an Personen mit
erstellten Inhalten in g¨
angigen Formaten, wie z.B. OpenOffice9oder PowerPoint10, die mit
wenigen Schritten solche Dateien in E-Learning-Inhalte umwandeln wollen. Das Zielformat ist
meistens HTML und ein typisches Programm dieser Gattung ist der Content Converter11
des LMS Clix Campus.
Der Content Converter liest Word-Dokumente ein, analysiert die Struktur, erzeugt ein
XML-Dokument und extrahiert Abbildungen in separaten Dateien. Hierbei wandelt das Sys-
tem den Dokumentaufbau in eine Navigationslogik um, die f¨
ur die sp¨
atere Steuerung ben¨
o-
tigt wird. Hierbei ist darauf zu achten, dass die ¨
Uberschriften richtig gesetzt sind, da sie
die Anhaltspunkte der Analyse darstellen. Abschließend erfolgt die Umwandlung des XML-
Dokuments in einzelne HTML-Seiten und eine Navigation. ¨
Uber Format- und Design-Vorlagen
kann das Layout den eigenen Bed¨
urfnissen angepasst werden.
Mittlerweile k¨
onnen auch Textverarbeitungsprogramme ihre Dokumente in HTML oder
XML speichern, weshalb die Relevanz der einfachen Content Converter abnimmt. Die Re-
sultate ¨
ahneln jedoch mehr Texten als multimedialen E-Learning-Inhalten. Umfangreichere
Content Converter, die z.B. Metadaten extrahieren, feinere Granularit¨
aten erlauben und Stan-
dards wie SCORM oder AICC unterst¨
utzen, haben jedoch das Potential, eine echte Alternative
gegen¨
uber spezialisierten Programmen zu sein.
5.1.4 Live Recording Systeme
Systeme zur Aufzeichnung von Audio- und Videodaten erm¨
oglichen eine schnelle Erstellung
multimedialer E-Learning-Inhalte. Auf diese Weise lassen sich Vorlesungen, Vortr¨
age und Pr¨
a-
sentationen festhalten und bei Bedarf abrufen. Nach der Aufzeichnung lassen sich die Daten
bearbeiten, z.B. durch Anmerkungen oder die Erstellung eines Indexes. Im Gegensatz zu ei-
ner herk¨
ommlichen Aufzeichnung mit einer einfachen Videokamera erlauben die Live Recor-
ding Systeme eine Verkn¨
upfung mit dem pr¨
asentierten Material, wie z.B. einer PowerPoint-
Pr¨
asentation. Exemplarisch f¨
ur diese Klasse werden IMC Lecturnity Suite12 und Tegrity
WebLearner13 vorgestellt.
Ausgangspunkt der Lecturnity Suite ist eine PowerPoint-Pr¨
asentation, die im Vorwege
erstellt wird. Ausgestattet mit einem Headset oder Mikrofon tr¨
agt der/die Dozent/-in wie
gewohnt die Vorlesung vor und wird von einer Kamera aufgezeichnet. Eventuelle Annotationen
lassen sich auf einem Smart- oder Whiteboard anbringen. Abbildung 5.4 zeigt ein Szenario f¨
ur
den Einsatz von Lecturnity. Alle Quellen werden synchron aufgezeichnet und in ein Lernmodul
gepackt, das anschließend mit dem Lecturnity Player abgespielt werden kann oder mit dem
Lecturnity Converter in ein Format f¨
ur den Real Media Player14 oder Windows Media
Player15 umgewandelt wird.
Das Prinzip der Aufzeichnung ist beim Tegrity WebLearner gleich. Ein besonderer Punkt
ist das WebLearner Studio, ein Komplettpaket versehen mit der n¨
otigen Hardware (PC,
Bildschirm, Projektor, Kamera und Mikrofon), das f¨
ur die Aufgabe optimal abgestimmt ist.
Probleme mit inkompatibler Hardware treten somit nicht auf. Eine Nachbearbeitung der Auf-
zeichnung ist mit dem WebLearner Editor m¨
oglich und eine Wiedergabe erfolgt ¨
uber den
9http://www.openoffice.org (29.10.05)
10http://office.microsoft.com (29.10.05)
11http://www.im-c.de (29.10.05)
12http://www.im-c.de (29.10.05)
13http://www.tegrity.com (29.10.05)
14http://www.real.com (29.10.05)
15http://www.microsoft.com/windows/windowsmedia (29.10.05)
50 Autorenwerkzeuge
Abbildung 5.4: Einsatz von Lecturnity (Aus einer Werbebrosch¨
ure)
WebLearner Server. Zus¨
atzliche Module bieten Funktionen an, die in der Lecturnity Sui-
te nicht angeboten werden. Beispielsweise erm¨
oglicht das Modul Webcast synchrone Live-
Sessions mit anderen Teilnehmern/-innen, inklusive Interaktionen via Chat und Mikrofon.
5.1.5 Screen Movie Recorder
Screen Movie Recorder dienen zur direkten Aufzeichnung von Aktivit¨
aten am Rechner und
einer gleichzeitigen oder sp¨
ateren Vertonung. Der Bildschirm oder ein ausgew¨
ahltes Fenster
wird direkt ”abgefilmt“ und an zus¨
atzlicher Hardware werden lediglich ein Headset oder Mikro-
fon ben¨
otigt. Auf diese Weise lassen sich Tutorien f¨
ur die Bedienung von Programmen einfach
und schnell erstellen. Stellvertretend f¨
ur diese Klasse werden Camtasia Studio16,Turbo
Demo17 und Qarbon ViewletBuilder18 vorgestellt.
Das Camtasia Studio ist ein sehr professionelles Programm, mit dem z.B. Microsoft seine
How-To-Videos erstellt hat. Es besteht aus den drei Komponenten Recorder,Producer und
Effects. Der Recorder erstellt einen Film, der mit dem Producer nachbearbeitet werden kann,
wie z.B. Schneiden, Vertonen und Konvertieren in andere Videoformate. Spezielle Erg¨
anzungen
wie Annotationen, Bilder und dergleichen werden mit Effects eingef¨
ugt.
Bei Turbo Demo und ViewletBuilder werden im Gegensatz zum Camtasia Studio keine
kompletten Filme aufgenommen. Eine Animation besteht bei diesen Programmen aus einzel-
nen Bildern, auch Schl¨
usselszenen genannt, zu denen lediglich die Mausbewegung und Ereignis-
se aufgezeichnet werden. Dieser Ansatz erzeugt wesentlich kleinere Dateien als eine vollst¨
andige
Aufzeichnung. Auch die nachtr¨
agliche Bearbeitung erweist sich als einfacher, da Screenshots
hinzugef¨
ugt oder misslungene ausgetauscht werden k¨
onnen. Neben der Erg¨
anzung mit Text-
feldern, Sprechblasen, Bildern und Vektorgrafiken sind sogar einfache Interaktionen mit der
Maus m¨
oglich.
16http://www.techsmith.com (29.10.05)
17http://www.turbodemo.de (29.10.05)
18http://www.qarbon.com (29.10.05)
5.2 Bewertung 51
5.1.6 Rapid E-Learning Content Development
Die Rapid E-Learning Content Development Werkzeuge kommen ohne jegliche Programmie-
rung aus und erlauben dennoch die Entwicklung interaktiver Elemente wie Quiz und Tests in
standardkompatiblen Formaten. Hierf¨
ur stehen Schablonen einzelner Seiten zur Verf¨
ugung, die
mit eigenen Texten, Abbildungen und Animationen ausgef¨
ullt werden. Mehrere Seiten lassen
sich in Kapiteln organisieren und zu vollst¨
andigen Kursen zusammensetzen. Alle Programme
bieten WYSIWYG und Drag’n’Drop f¨
ur eine einfache Benutzung an. Je nach Leistungsum-
fang k¨
onnen Fremdformate f¨
ur Audio, Video und Multimedia eingebunden werden, sodass
auch komplexere Elemente m¨
oglich sind. Bekannte Vertreter dieser Klasse sind NIAM-TMS
EasyGenerator19 ,ITACA EasyProf20 und Trivantis Lectora Publisher21.
Der EasyGenerator ist eine E-Learning-Suite und teilt die Arbeit in vier Bereiche auf,
die jeweils von einer Komponente unterst¨
utzt werden. Schulungen und Tests werden mit dem
EasyGenerator erzeugt und gewartet. Die Resultate lassen sich in einem Format speichern,
das mit Hilfe des EasyPlayers von einer CD-ROM oder des EasyWebPlayers ¨
uber das Internet
abgespielt wird. Zudem werden SCORM und AICC f¨
ur den Einsatz in einem LMS unterst¨
utzt.
Welche Fortschritte die Lernenden machen, wird durch EasyProgress ¨
uberwacht. S¨
amtliche
Verwaltungst¨
atigkeiten, die bei der Erstellung, Bereitstellung und Einsatz anfallen, werden
mit EasyCourseManager erledigt.
Mit EasyProf lassen sich einfach multimediale E-Learning-Inhalte und Pr¨
asentationen in
den Ausgabeformaten HTML, HTML mit SCORM sowie CD-ROM erzeugen. Ein Schwerpunkt
dieses Programms liegt bei Testfragen, die sich mit der Maus zusammenstellen lassen. Die
Tracking-Daten werden in XML kodiert und k¨
onnen entweder per E-Mail oder FTP ¨
ubertragen
werden.
Neben den Schablonen bietet Lectora zus¨
atzlich Assistenten an, mit denen Kursstruktu-
ren automatisch erzeugt werden. ¨
Ahnlich den programmierbaren Konkurrenzprodukten, lassen
sich Ereignisse — ausgel¨
ost von Maus und Tastatur — mit Grafik- und Textobjekten verkn¨
up-
fen. Zu den St¨
arken des Programms geh¨
ort die Vielfalt an unterst¨
utzen Fremdformaten, wie
z.B. das IPIX-Format22, das 360 ×360 Grad Panorama Bilder erm¨
oglicht. Als Ausgabeformat
stehen AICC sowie SCORM zur Wahl, HTML, CD-ROM/DVD und die Erstellung eines aus-
f¨
uhrbaren Programms (.exe) f¨
ur Windows. Abbildung 5.5 zeigt einen typischen Screenshot
von Lectora.
5.2 Bewertung
In den Tabellen 5.1 und 5.2 sind die vorgestellten Programme f¨
ur einen direkten Vergleich auf-
gelistet. Auch wenn die Ans¨
atze teilweise sehr verschieden sind, wie z.B. programmierbare und
aufzeichnende Systeme, lassen sich Parallelen beim Erstellungsprozess erkennen, die problema-
tisch sind. Hierzu geh¨
ort die Wiederverwendung, da die meisten Autorensysteme nur optimale
Ergebnisse erzielen, wenn die Ergebnisse in propriet¨
aren Formaten gespeichert werden. Dateien
verschiedener Anwendungen lassen sich dann nur mit Aufwand kombinieren und die Resultate
sind oft suboptimal. Ein einheitliches Layout ist nur mit viel Disziplin bei der Erstellung zu
erreichen und Inhalte fremder Anbieter stechen schon aufgrund des Erscheinungsbildes her-
vor. Da die vorgestellten Programme meist auf Systemen mit dem Betriebssystem Windows
laufen, werden einige Zielformate auf Rechnern mit Linux oder Mac OS X nicht unterst¨
utzt.
Folglich wird beim Einsatz eines propriet¨
aren Formats bereits durch das Autorensystem die
Infrastruktur eingeschr¨
ankt. Mit den Definitionen f¨
ur Lernobjekte aus Kapitel 3, besonders
Downes essentielle Anforderung an die Interoperabilit¨
at (siehe S. 22) sei hier hervorgehoben,
ist dies freilich schwer vereinbar.
19http://www.easygenerator.de (29.10.05)
20http://www.easyprof.com (29.10.05)
21http://www.lectora.com (29.10.05)
22http://www.ipix.com (29.10.05)
52 Autorenwerkzeuge
Abbildung 5.5: Screenshot von Lectora
Ein ¨
ahnliches Problem ergibt sich aus der unterst¨
utzten Granularit¨
at. Viele der Programme
erlauben lediglich in sich abgeschlossene Einheiten, wie z.B. Kurse oder Vortr¨
age. Dies f¨
uhrt
zu Behinderungen bei einer nachtr¨
aglichen ¨
Anderung der Sequenzierung (siehe Abschnitt 3.4),
was wiederum zu Lasten der Wiederverwendung geht. Programmen mit kleineren Einheiten,
wie z.B. Dreamweaver oder die Screen Movie Recorder, fehlen hingegen die ad¨
aquaten Mittel
f¨
ur komplexere Strukturen. Auch wenn Dreamweaver einer guten Autorenumgebung schon
nahe kommt, ist der Ansatz falsch gew¨
ahlt. Anstatt einen HTML-Editor mit E-Learning-
Plugins zu erweitern, sollte besser eine E-Learning-Umgebung mit HTML-Plugins gew¨
ahlt
werden.
Ganz anders stellt sich das Problem Standardkompatibilit¨
at dar. Wahrscheinlich liegen
die Gr¨
unde im Marketing begr¨
undet, dass auf vielen Produkten dieses Siegel zu finden ist
und in der Tat erm¨
oglichen es diese Programme auch, Dateien in Formaten wie beispielsweise
SCORM,IMS Content Packaging und LOM zu speichern. Doch genauer betrachtet, zeigt
sich schnell der Etikettenschwindel. Die Ursachen liegen wieder in den propriet¨
aren Formaten
und den eingeschr¨
ankten Granularit¨
aten. Eine mit Authorware gespeicherte SCORM-Datei er-
n¨
uchtert schnell. Die Strukturierungsm¨
oglichkeiten des Manifests (siehe Abschnitt 3.5) werden
nicht genutzt, denn es handelt sich vielmehr um eine Flash-Datei, eingepackt als Ressource,
was sicherlich nicht der Sinn eines Sharable Content Objects (SCO) ist. Als Fazit auf ein an-
deres Produkt umzuschwenken l¨
ost das Problem nicht. Die anderen Produkte schneiden nicht
besser ab.
Bei der Zusammenarbeit mit Learning Management Systemen wird nur von wenigen Auto-
rensystemen, wie z.B. Authorware und ToolBook, eine direkte Verbindung angeboten. Gerade
bei der Erstellung neuer Inhalte ist aber wichtig, das Layout auf der Zielplattform zu ¨
uber-
pr¨
ufen. Funktionen wie WYSIWYG unterst¨
utzen die Autoren/-innen bei der Arbeit, jedoch
5.2 Bewertung 53
pr¨
agt letztendlich das LMS das Erscheinungsbild. In Hinblick auf eine Separation von Inhalt
und Darstellung, wie in Abschnitt 3.7 beschrieben, gilt dies besonders zu ber¨
ucksichtigen. Aus
diesem Grund muss sich die Daten¨
ubertragung nahtlos in den gesamten Prozess der Erstellung
und Kontrolle einf¨
ugen.
Die vorgestellten Autorensysteme geh¨
oren zu den Programmen, die heutzutage im Einsatz
sind. Ihre Analyse hat die in Abschnitt 1.1 angesprochene Diskrepanz zwischen Theorie und
Praxis best¨
atigt, sodass folglich neue Ans¨
atze f¨
ur Autorensysteme gefunden werden m¨
ussen.
54 Autorenwerkzeuge
System Bedienung Eingabe Import Ausgabe Standard Gr¨
oße
Professionell
Authorware 7 Drag’n’Drop,
WYSIWYG,
Programmie-
rung
Text, Grafik,
Audio, QuickTime,
Director, Flash,
JavaScript, ActiveX
PowerPoint,
XML, RTF
Flash, Windows
Media Player,
DVD, Mac OS
X Playback
SCORM,
IMS,
AICC,
LOM
Kurse,
Templates
ToolBook
(Instructor)
Drag’n’Drop,
WYSIWYG,
Programmie-
rung
Text, Grafik, Audio,
PowerPoint, Word,
Flash, JavaScript,
ActiveX, RealMedia
HTML, .exe SCORM,
AICC
Kurse,
Templates
Mediator 7
(EXP)
Drag’n’Drop,
WYSIWYG,
Programmie-
rung
Text, Grafik,
Audio, Flash,
JavaScript, Visual
Basic, ActiveX,
QuickTime
Flash DHTML, Flash,
CD-ROM/DVD,
ScreenSaver,
.exe, Mediator
Kurse,
Templates
HTML
Dreamweaver
(mit Plugins)
Drag’n’Drop,
WYSIWYG,
Programmie-
rung
Text, Grafik, Audio,
Video, Flash,
ActiveX, JavaScript
HTML,
XML, Ta-
bellendaten
HTML,
XHTML, JSP,
PHP
SCORM,
IMS,
AICC,
LOM
Seiten,
Kurse
Conv.
Clix Campus
Content
Converter
Maus MS Word XML, HTML Abschnitte,
Kurse
Live Recording
Lecturnity
Suite
Maus,
Tastatur
Text, Grafik PowerPoint,
analoge
Videodaten
CD/DVD,
Internet-
Streaming,
RealMedia,
Windows Media
Vortrag,
Film
Tegrity
WebLearner
Maus,
Tastatur
Text, Grafik PowerPoint,
Windows
Media,
QuickTime,
Videodaten
CD-ROM,
Windows Media,
QuickTime
SCORM,
IMS,
AICC
Vortrag,
Film
Tabelle 5.1: ¨
Ubersicht der Autorensysteme (Teil 1)
5.2 Bewertung 55
System Bedienung Eingabe Import Ausgabe Standard Gr¨
oße
Screen Recorder
Camtasia
Studio
Maus,
Tastatur
Text, Grafik,
Audio, HTML,
PowerPoint, Word
AVI, Flash,
Windows Media,
QuickTime,
RealMedia, .exe,
Animated GIF
Film
Turbo Demo Maus,
Tastatur
Text, Grafik, Audio Java/HTML,
Flash, AVI,
.exe, Animated
GIF, PDF
Film
Viewlet-
Builder
Maus,
Tastatur,
Text, Grafik, Audio Flash Flash, .exe,
PDF, Bilder
SCORM Film
Rapid Development
Easy-
Generator
Maus,
Drag’n’Drop,
WYSIWYG,
Tastatur
Text, Grafik, Audio Eigenes Format SCORM,
AICC
Kurs, Scha-
blone
EasyProf Maus,
Drag’n’Drop,
WYSIWYG,
Tastatur
Text, Grafik,
Audio, RealMedia,
Windows Media,
QuickTime, Flash
PowerPoint,
Word
HTML,
CD-ROM, .exe,
.jar
SCORM,
AICC
Kurs, Scha-
blone
Lectora Maus,
Drag’n’Drop,
WYSIWYG,
Tastatur
Text, Grafik,
Audio, RealMedia,
Windows Media,
Flash
HTML, .exe SCORM,
AICC
Kurs, Scha-
blone
Tabelle 5.2: ¨
Ubersicht der Autorensysteme (Teil 2)
Kapitel 6
Lernplattformen
Der Einsatz von E-Learning l¨
asst sich nur mit einer geeigneten Infrastruktur sinnvoll realisie-
ren, weil viele Inhalte inklusive Metadaten einer großen Zahl von Personen mit unterschiedli-
chen Aufgaben zug¨
anglich gemacht werden m¨
ussen. Einen wesentlichen Anteil ¨
ubernimmt die
Lernplattform, die eine zentrale Anlaufstelle f¨
ur ein breites Angebot an Diensten ist. Um
den Leistungsumfang eines solchen Systems genauer bestimmen zu k¨
onnen, werden folgend
die Rollen und T¨
atigkeiten beschrieben, die haupts¨
achlich mit einer Lernplattform zu tun
haben. Ein/eine Dozenten/-in plant und organisiert Lehrveranstaltungen f¨
ur Studierende
und wird bei der Durchf¨
uhrung zumeist von Tutoren/-innen unterst¨
utzt. Jede dieser Rollen
muss ¨
uber eine Benutzerverwaltung dem System bekannt gegeben werden. In der Regel legt
die Rolle Administrator/-in den/die Dozenten/-in an, eventuell auch die Tutoren/-innen.
Diese k¨
onnen wiederum Studierende eintragen, die sich f¨
ur einen Kurs angemeldet haben.
An dieser Stelle wird bereits erkennbar, dass eine Rollen- und Rechtevergabe ben¨
otigt
wird. Lediglich den Administratoren/-innen soll gestattet sein, neue Zug¨
ange f¨
ur Dozenten/-
innen anzulegen. Dozenten/-innen und Tutoren/-innen werden mit weniger Rechten bedacht
und bei Studierenden sollte im Hinblick auf m¨
oglichen Missbrauch ganz von jeglichen admi-
nistrativen M¨
oglichkeiten abgesehen werden.
Eine Lernplattform muss also ”wissen“, wer gerade mit ihr arbeitet, um die Rechte der
Rolle ¨
uberpr¨
ufen zu k¨
onnen. Hierbei sei erw¨
ahnt, dass es durchaus ¨
ublich ist, wenn ein und
die selbe Person in mehreren Rollen auftritt. So kann z.B. der/die Dozent/-in in die Rolle
Designer/-in wechseln, in der andere Rechte zugebilligt werden. Dieses Vorgehen erlaubt
eine bessere Kontrolle der einzelnen Aktivit¨
aten und erh¨
oht die Sicherheit des Systems. Eine
Person identifiziert sich ¨
uber die Authentifizierung der Lernplattform und bekommt eine
Rolle zugewiesen. Vorwiegend erfolgt der Zugang ¨
uber einen Namen und ein Passwort, aber
auch Schl¨
ussel in Dateien oder Cookies der Web-Browser sind denkbar. Nach einer erfolg-
reichen Authentifizierung ¨
uberpr¨
uft die Lernplattform jede Aktion ¨
uber die Autorisierung.
Anhand der eingenommenen Rolle und den vergebenen Rechten wird kontrolliert, ob die ge-
w¨
unschte Operation ausgef¨
uhrt werden darf oder die n¨
otige Berechtigung fehlt. Komfortable
Systeme zeigen allein die Operationen an, die auch ausgef¨
uhrt werden d¨
urfen. So w¨
urde z.B.
die Rolle Designer/-in eine Operation ”Bearbeiten“ in ihrer Kursansicht vorfinden und die
Rolle Studierende nicht.
Neben der Benutzerverwaltung muss eine Lernplattform auch eine Kursverwaltung an-
bieten. Hierbei sind die unterst¨
utzten Granularit¨
aten (siehe Abschnitt 3.3) und Formate (siehe
Abschnitt 3.7) wesentliche Merkmale. Je nach Abstraktionsniveau k¨
onnen u.a. HTML-Seiten,
Bilder, Lernobjekte oder vollst¨
andige Kurse in einem Repository gespeichert werden. Die Lern-
plattform sollte den/die Dozenten/-in bei der Suche nach geeigneten Materialien unterst¨
utzen
und beliebige Kombination fremder und eigener Inhalte erm¨
oglichen. Durch Wiederverwen-
dung k¨
onnen somit Kosten reduziert werden. Verschiedene Ausgabeformate, wie z.B. HTML
oder PDF runden den Funktionsumfang ab, wobei die direkte Erstellung von Inhalten nicht zu
den Aufgaben einer Lernplattform geh¨
ort. Im folgenden Abschnitt 6.1 wird allerdings auf Sys-
58 Lernplattformen
teme eingegangen, die diesen Prozess unterst¨
utzen, z.B. durch einen einfachen Datenaustausch
mit Autorensystemen.
Begleitend zu einem Kurs sollte eine Lernplattform Daten ¨
uber die Leistungen der Studie-
renden sammeln: ”
Wie lange ist die letzte Anmeldung her?“, ”
Wie viel Zeit wurde in welchem
Bereich verbracht?“ und ”
Welche Aufgaben wurden absolviert?“ sind nur einige Informationen,
die in Statistiken die Lernaktivit¨
aten veranschaulichen. Auf diese Weise k¨
onnen individuelle
Probleme erkannt und gezielt behoben werden.
Auch die Kommunikation zwischen den Personen soll eine Lernplattform unterst¨
utzen. Be-
kannte Kommunikationsmethoden sind u.a. Foren, in denen Beitr¨
age nach Themen geord-
net sind und Threads (Diskussionsf¨
aden) entstehen. Dozent/-in und Tutoren/-innen k¨
onnen
bei Bedarf Hilfestellungen geben, indem sie eigene Beitr¨
age hinzuf¨
ugen. Schneller geht es beim
Chat zu. Texteingaben werden direkt auf den Bildschirmen aller oder ausgew¨
ahlter Personen
angezeigt und Reaktionen k¨
onnen prompt folgen, sodass im Vergleich zu den Foren agilere
Diskussionen m¨
oglich sind. Beide Kommunikationsmethoden, Foren und Chat, sollten bei Be-
darf moderierbar sein, d.h. eine Person oder Gruppe ist mit Sonderrechten ausgestattet. Sie
¨
uberwacht das ”Niveau“ der Beitr¨
age und kann gegebenenfalls intervenieren. Wichtige Nach-
richten f¨
ur alle Studierenden, wie z.B. Terminank¨
undigungen oder Termin¨
anderungen, sollten
per E-Mail bekannt gegeben werden.
Der Lernprozess der Studierenden soll von der Lernplattform unterst¨
utzt werden. Beson-
ders die Organisation und Vorgehensweise sollen durch Werkzeuge f¨
ur Studierende ver-
einfacht werden, wie z.B. mit einem Notizbuch f¨
ur pers¨
onliche Annotationen zu den Inhalten
oder einem Kalender. In eigenen Bereichen soll die M¨
oglichkeit zum Nachlernen und zur Selbs-
tevaluation gegeben sein.
6.1 Definitionen
Es soll nun der Versuch unternommen werden, eine Definition bzw. einen Anforderungskatalog
f¨
ur Lernplattformen zu erstellen. Da es sich um komplexe Systeme handelt, bei denen es auf
Praxistauglichkeit ankommt, gibt es so gut wie keine theoretischen Arbeiten. Vielmehr handelt
es sich um Praxiserfahrungen, die in eigenen Implementierungen oder Evaluationen (siehe
Abschnitt 6.2) gesammelt wurden.
Von der damaligen EDUCOM-Kommission (heute: EDUCAUSE) stammt folgender Ver-
such, die wesentlichen Eigenschaften einer Lernplattform festzulegen. Die Definition stammt
aus [Schulmeister01, S. 132ff]:
Kurse: Die Einrichtung und Durchf¨
uhrung von Kursen ist m¨
oglich.
Akteure: Lernsysteme sollten mindestens die Rollen f¨
ur folgende Akteure vorsehen: Studie-
rende, Dozenten, Tutoren, Administratoren.
Dienste: Dienste m¨
ussen ¨
uber eine eigene Funktionalit¨
at verf¨
ugen:
Administrative Dienste: Kurskalender, Schwarzes Brett, etc.
Kommunikationsdienste: Chat, E-Mail, Foren
Lehrfunktionen: Folien, Referenzen zu Netzadressen, etc.
Evaluationsdienste: Tests, Selbstevaluation, etc.
Dokumente: Dokumente m¨
ussen Teil der Lernobjekte und der Dienste sein.
Gruppen: Kollaboratives Arbeiten muss m¨
oglich sein, wobei mehrere Benutzer gleichzeitig
kommunizieren.
Institutionen: Die Lernumgebung ist an jede Institution anpassbar.
Sprache: Kurse in mehreren Sprachen m¨
ussen unterst¨
utzt sein.
Interface: Anpassungen der grafischen Schnittstelle an die Lernumgebung sind m¨
oglich.
Navigationsstruktur: Anpassung der Navigation an das Lernumfeld ist m¨
oglich.
6.1 Definitionen 59
Eigentlich erf¨
ullt keine der heute verf¨
ugbaren Lernplattformen diesen Leistungskatalog
und dennoch ist er nicht vollst¨
andig. Die Beschreibung am Anfang dieses Kapitels l¨
asst
erahnen, dass noch weitere Funktionen zum Umfang geh¨
oren. Es fehlt z.B. eine Kursver-
waltung, die Wartung und Suche beinhaltet. Auch das Rollenmodell wird erst durch einen
Authentifizierungs- und Autorisierungsmechanismus vollst¨
andig. Die Forderung nach anpass-
baren grafischen Schnittstelle sollte in eine strikte Trennung von Inhalt und Darstellung ¨
uber-
f¨
uhrt werden, um neben dem wandelbaren Aussehen verschiedene Ausgabeformate wie HTML
und PDF zu erm¨
oglichen. Zudem sind eine n¨
ahere Anbindung von Autorensystemen an Lern-
plattformen sowie die statistische Erfassung der Lernaktivit¨
aten sinnvolle Erg¨
anzungen f¨
ur
eine umfassende Definition.
Ausgehend von der gegebenen Definition, kennzeichnet Schulmeister in [Schulmeister03,
S. 10] folgende Punkte als relevant, um eine Lernplattform von einer bloßen Kollektion von
Skripten oder Hypertextsammlungen zu unterscheiden:
•Eine Benutzerverwaltung (Anmeldung mit Verschl¨
usselung)
•Eine Kursverwaltung (Kurse, Verwaltung der Inhalte, Dateiverwaltung)
•Eine Rollen- und Rechtevergabe mit differenzierten Rechten
•Kommunikationsmethoden (Chat, Foren) und Werkzeuge f¨
ur das Lernen (Whiteboard,
Notizbuch, Annotationen, Kalender etc.)
•Die Darstellung der Kursinhalte, Lernobjekte und Medien in einem netzwerkf¨
ahigen
Browser
Durch diese Erg¨
anzung fallen eine Reihe von Systemen heraus, die allgemein f¨
ur die Grup-
penarbeit bzw. den Datenaustausch konzipiert wurden, wie z.B. der BSCW-Server des Pro-
jekts Basic Support for Cooperative Work (BSCW) [Bentley95]. Lernplattformen zeichnen sich
gegen¨
uber solchen Systemen durch eine leistungsf¨
ahigere Administration, verschiedene Kom-
munikationsmethoden und einem gr¨
oßeren Repertoire an Werkzeugen f¨
ur das Lernen aus.
Der funktionale Aufbau einer Lernplattform l¨
asst sich auch grafisch darstellen, wie Abbil-
dung 6.1 zeigt.
Kursdaten
Administration
Benutzerdaten
Content Management
Lernobjekte
Metadaten
Administration
Evaluation
Institutionen
Kurse
Benutzer
Authoring
Interfacedesign
Lernobjekte
Aufgaben
Tests
Lernumgebung
Personalisierung
Werkzeuge
Kurse
Schnittstellen−APIextern intern
Repository−Datenbasis
Kommunikation
Abbildung 6.1: Idealtypische Architektur einer Lernplattform nach [Schulmeister03, S. 11]
Demnach besteht eine Lernplattform im Wesentlichen aus drei Schichten. Die erste Schicht
h¨
alt alle Daten f¨
ur den Betrieb vor, wie z.B. die Lernobjekte und Benutzerdaten. Dar¨
uber
60 Lernplattformen
liegt Schicht Zwei mit den Programmierschnittstellen (API) f¨
ur den Zugriff auf die wesent-
lichen Funktionen. Auf oberster Ebene liegt Schicht Drei, die zur Visualisierung der Daten
und zur Steuerung der Lernplattform dient. Bei normalem Betrieb arbeiten alle Rollen mit
den Werkzeugen aus der Schicht Drei und nur bei Anpassungen oder Erweiterungen kann es
vorkommen, dass auch auf die darunter liegenden Schichten zugegriffen werden muss.
Neben dem Begriff Lernplattform gibt es noch weitere, die sich meist nur in Nuancen unter-
scheiden. Der g¨
angige Begriff im anglophonen Gebiet ist Learning Management System (LMS).
Speziell in England wird aber auch oft von Virtual Learning Environments (VLE) gesprochen,
wenn die didaktische Ausrichtung hervorgehoben werden soll [Britain00]. Ein Beispiel f¨
ur eine
Klassifizierung von VLEs findet sich in [Milligan00]. Hier werden klassische, lernzentrierte und
kollaborative VLEs unterschieden sowie deren Erweiterungen. Die klassischen VLEs gliedern
die Lerninhalte hierarchisch: Ein Kurs wird in Lektionen aufgeteilt, die wiederum aus Seiten
bestehen und ¨
Ubungen enthalten. Abschließend werden Tests angeboten, bevor es zum n¨
achs-
ten Thema geht, sodass die Sequenzierung ¨
uberwiegend linear-sukzessiv ist (siehe Abschnitt
3.4). Lernzentrierte VLEs zeichnen sich durch die Unterst¨
utzung von Methoden der Projektar-
beit aus [Schulmeister01]. Kollaborative VLEs erlauben mehreren Personen an gemeinsamen
Projekten oder Objekten zu arbeiten. Es handelt sich um ein Netzwerk verschiedener Pro-
gramme, die z.B. ¨
uber das Internet miteinander verbunden sind [Schwabe01; Wessner00]. Als
Erweiterungen werden alle Programme betrachtet, die VLEs um zus¨
atzliche Spezialfunktionen
erg¨
anzen, z.B Editoren, Animationswerkzeuge und Programme f¨
ur Videokonferenzen.
Eine andere Kategorisierung bringt die Definition von Brandon Hall [Hall00]. Demnach
ist ein LMS haupts¨
achlich f¨
ur die Administration der Lerninhalte und der Anwenderdaten
zust¨
andig. K¨
onnen die Inhalte zus¨
atzlich ver¨
andert und zusammengestellt werden, handelt
es sich um ein Integrated Learning Management System (ILS). Ein ¨
ahnlicher Begriff ist das
Learning Content Management System (LCMS), der eine Vermischung von Content Manage-
ment System (CMS) und LMS ist. Schulmeister h¨
alt all diese Verfeinerungen jedoch nicht f¨
ur
sinnvoll:
”Diese Begriffsunterscheidung zwischen LMS und ILS ist nicht wirklich trennscharf,
selbst die Unterscheidung von Content Management System (CMS) oder Learning
Content Management System (LCMS) und LMS ist nicht sehr hilfreich. Die Inte-
gration eines Editors f¨
ur Autoren ist nicht konstitutiv f¨
ur ein LMS, das Authoring
kann auch mit einem externen Editor erfolgen.“ [Schulmeister03, S. 14,15]
6.2 Evaluation
Die Auswahl der geeigneten Lernplattform ist ein komplexes und zeitaufwendiges Unterfangen.
Zuerst sollte der eigene Bedarf bestimmt werden, um die Kriterien f¨
ur das ben¨
otigte System
festzulegen. Hiernach erfolgt die Recherche nach den Lernplattformen und ihren Funktionen.
Es sollten m¨
oglichst viele der aufgestellten Kriterien erf¨
ullt sein, um etwaige Erweiterungen zu
sparen. Aufgrund des riesigen Angebots an Lernplattformen, sollte auf bereits vorhandene Un-
tersuchungen zur¨
uckgegriffen werden. Die st¨
andige Weiterentwicklung, gelegentliche ¨
Ubernah-
me durch andere Firmen oder die komplette Einstellung von Produkten bereitet auch Experten
arge Probleme. Offensichtlich muss die Evaluation von Lernplattformen bis zur Kaufentschei-
dung im Auge behalten werden, denn eine falsche Wahl kann erhebliche finanzielle Nachteile
in sich bergen.
Eine ¨
altere Recherche von Schulmeister [Schulmeister00] hat 108 Software-Produkte unter-
sucht, die in der Stichprobe ”Evaluation von Lernplattformen“ (EVA:LERN) [Schulmeister03]
auf 171 aufgestockt wurde. Brandon Hall f¨
uhrt in seiner Studie [Hall03] 72 Systeme an, von
denen 44 auch in EVA:LERN vorkommen. Aus dem gleichen Hause gibt es zus¨
atzlich eine
Studie ¨
uber LCMS [Chapman03]. In der Untersuchung von Baumgartner [Baumgartner02a]
werden 133 Lernplattformen angegangen. Anhand dieser ausgew¨
ahlten Arbeiten wird bereits
6.2 Evaluation 61
offensichtlich, wie kompliziert und subjektiv die Auswahl eines geeigneten Systems ist. Im fol-
genden werden die Lernplattformen Blackboard 61,WebCT2und smartBLU3vorgestellt,
weil sie bei dieser Arbeit zur Verf¨
ugung standen. Der Installationsaufwand einer Lernplatt-
form ist enorm und kann nur von Experten mit Erfahrungen auf diesem Gebiet durchgef¨
uhrt
werden.
6.2.1 Blackboard
Blackboard Inc. bietet die Lernplattform Blackboard an, die aus CourseInfo hervorgegangen
ist. Bei der aktuellen Version Blackboard 6 handelt es sich um verschiedene Komponenten, die
nach den eigenen Bed¨
urfnissen kombiniert werden k¨
onnen. An dieser Stelle wird die Black-
board Academic Suite n¨
aher betrachtet, die sich aus den Systemen Blackboard Learning
System4,Blackboard Content System und Blackboard Portal System zusammensetzt.
Das Blackboard Learning System ist ein Web-basiertes Werkzeug zur Verwaltung von Kur-
sen, mit dem Lehrende eigene Lehrpl¨
ane erstellen und ihre zugeh¨
origen Inhalte abspeichern.
F¨
ur die ¨
Uberpr¨
ufung des Lernerfolgs unterst¨
utzt das System die Erstellung und den Einsatz
von Tests. Lernende profitieren von virtuellen Klassenr¨
aumen, in denen die Kommunikati-
on und Zusammenarbeit gef¨
ordert werden. Sollte Blackboard eine gew¨
unschte Funktion nicht
anbieten, so kann es ¨
uber die Building Blocks erweitert werden. Hierbei handelt es sich
um eigene Anwendungen oder Erg¨
anzungen, die mit einem speziellen Software Development
Kit (SDK) entwickelt wurden. ¨
Uber spezielle APIs erlangen die selbst entwickelten Module
den vollen Zugriff auf Blackboard. Ein gutes Beispiel ist der Building Block zum Einlesen von
SCORM-Dateien, durch den Blackboard erst standardkompatibel wird. Abbildung 6.2 zeigt
einen typischen Screenshot des LMS.
Bei dem Blackboard Content System handelt es sich um eine Erweiterung, die Autoren/-
innen bei ihrer Arbeit unterst¨
utzt. So lassen sich Inhalte versionieren, ¨
Anderungen ¨
uberwa-
chen und Arbeitsabl¨
aufe bestimmen. Einmal erstellt, k¨
onnen Dateien zentral gehalten und in
verschiedenen Kursen eingesetzt werden. Einen ¨
ahnliche Funktionalit¨
at wird auch den Studie-
renden angeboten. In ”virtuellen Speicherbereichen“ k¨
onnen sie eigene Daten halten, auf die
sie ¨
uber Blackboard zugreifen k¨
onnen.
Mit dem Blackboard Portal System l¨
asst sich ein anpassbares Portal f¨
ur Firmen und Univer-
sit¨
aten aufbauen, das die Lernplattform mit anderen Diensten in einer einheitlichen Oberfl¨
ache
vereint.
6.2.2 WebCT
WebCT Inc. bietet die beiden Ausf¨
uhrungen WebCT Campus Edition und WebCT Vista
ihres E-Learning-Systems f¨
ur die Hochschulausbildung an. Die WebCT Campus Edition
ist ein System zur Erstellung, Verwaltung und Nutzung von Kursen. Abbildung 6.3 zeigt eine
typische Pr¨
asentation von Inhalten.
Den Lehrenden wie Lernenden werden diverse Werkzeuge an die Hand gegeben, mit de-
nen der Zugriff auf das System vereinfacht wird. So lassen sich alle g¨
angigen Kursinhalte, wie
z.B. Texte, Bilder, Videos und Quiz, per Drag’n’Drop einstellen. Lehrende k¨
onnen Lernpfade
vorgeben, indem sie Leistungskriterien aufstellen, die mit Tests auf Basis von Multiple Choi-
ce und offenen Aufgaben ¨
uberpr¨
uft werden. Der gesamt Lernfortschritt l¨
asst sich festhalten,
sodass sich auch R¨
uckschl¨
usse auf die Qualit¨
at der Kurse ziehen lassen. So k¨
onnen die Inhal-
1http://www.blackboard.com (29.10.05) Mein besonderer Dank gilt Prof. Dr. Hans-J¨
urgen Appelrath und
dem ”Oldenburger Forschungs- und Entwicklungsinstitut f¨
ur Informatik-Werkzeuge und -Systeme“ (OFFIS) f¨
ur
die Nutzung der Installation.
2http://www.webct.com (29.10.05) Mein besonderer Dank gilt dem ”Multimedia Kontor Hamburg“
(MMKH) f¨
ur die Nutzung der Installation.
3http://www.smartblu.de (29.10.05)
4http://www.blackboard.com (29.10.05)
62 Lernplattformen
Abbildung 6.2: Screenshot von Blackboard
6.2 Evaluation 63
Abbildung 6.3: Screenshot von WebCT
64 Lernplattformen
te st¨
andig verfeinert und verbessert werden, um optimale Lernerfolge zu erreichen. F¨
ur die
Kommunikation der Lernenden werden Chat,Whiteboard, E-Mail, und Foren angeboten.
Mit dem WebDAV-Zugang haben Autoren/-innen einen flexiblen Zugang zu WebCT,¨
uber
den Inhalte schnell eingespielt und ver¨
andert werden k¨
onnen. Moderne Betriebssysteme k¨
on-
nen WebDAV bereits nahtlos integrieren, sodass auch nicht unterst¨
utzte Autorenwerkzeuge
direkten Zugriff haben. Mit einem sehr einfachen HTML-Editor k¨
onnen Seiten auch direkt in
WebCT bearbeitet werden, wovon jedoch abzuraten ist, weil die Funktionen zu rudiment¨
ar
sind.
WebCT Vista ist f¨
ur gr¨
oßere Installationen ausgelegt, bei denen z.B. verschiedene Internet-
auftritte einer Universit¨
at auf einem System betrieben werden. Diese Ausf¨
uhrung von WebCT
steht dieser Arbeit leider nicht zur Verf¨
ugung und kann nicht weiter betrachtet werden.
6.2.3 SmartBLU
Das LMS SmartBLU ist aus dem System CMS-W3 hervorgegangen und wird seit 1996 vom
Fraunhofer Institut f¨
ur Graphische Datenverarbeitung (IGD) entwickelt. Im Gegensatz zu den
anderen vorgestellten Systemen beschr¨
ankt sich SmartBLU auf die Pr¨
asentation von Lernma-
terialien und nutzt Chat sowie Foren als Kommunikationsmittel. Obwohl Portale, Organizer
sowie andere Funktionen nicht zum Leistungsumfang geh¨
oren, ist es dennoch eine interessante
Alternative, da es von den hier vorgestellten LMS die beste Standardunterst¨
utzung anbie-
tet. So kann SmartBLU selbst¨
andig eine Navigation aus einem Manifest generieren, was bei
den Konkurrenzprodukten nicht ohne weiteres geht. Abbildung 6.4 zeigt einen exemplarischen
Screenshot des Systems.
SmartBLU hat ein eigenes Rollenkonzept und unterscheidet zwischen Lerner,Betreu-
er,Fachautor sowie Administrator. Die Rolle Lerner nutzt das System zum lernen und
kann verschiedene Kurse belegen. Eine Kontrolle des Lernerfolgs wird ¨
uber Tests angeboten,
von denen es L¨
uckentexte, Zuordnungsaufgaben, Multiple- und Single-Choice-Aufgaben gibt.
Der Betreuer begleitet die Lernenden und kann die Ergebnisse der Tests ¨
uberpr¨
ufen. F¨
ur die
Erstellung der Inhalte sind die Fachautoren zust¨
andig, die sich um Konzeption, Gestaltung
und Implementierung k¨
ummern. Alle Verwaltungsaufgaben, wie z.B. die Benutzerverwaltung,
werden von der Rolle Administrator durchgef¨
uhrt.
Die Strukturierung der Kurse orientiert sich an der ”Buchmetapher“, sodass sich Lern-
inhalte wie in einem Buch in Kapitel und Abschnitte aufteilen. Die kleinste Einheit sind
Module, z.B. Texte, Grafiken sowie Animationen, und entsprechen im Sinne der Metapher
einem Abschnitt. Ein Modul kann in mehreren Kursen eingesetzt werden, wodurch die Wie-
derverwendbarkeit gef¨
ordert wird.
6.3 Bewertung
Im Abschnitt 6.1 wurde bereits darauf hingewiesen, dass die heutigen Lernplattformen den
Anspr¨
uchen bzw. den Definitionen nicht vollends gen¨
ugen. Sicherlich darf die Komplexit¨
at
eines solchen Systems nicht untersch¨
atzt werden, aber bereits bei der Basisfunktionalit¨
at, dem
Pr¨
asentieren der Lernmaterialien, gibt es Gr¨
unde zur Kritik. F¨
ur einen besseren Vergleich
listet Tabelle 6.1 einige Merkmale der drei vorgestellten Lernplattformen auf.
Es beginnt mit dem Datenaustausch zwischen Autorensystem und Lernplattform, wie in
[Bungenstock03a; Bungenstock03b] genauer untersucht wurde. Nur WebCT erm¨
oglicht mit
WebDAV unter den vorgestellten Lernplattformen eine einfache Anbindung. Die anderen Pro-
dukte bieten lediglich umst¨
andliche Web-Oberfl¨
achen an, was bei vielen ¨
Anderungen und An-
passungen, wie sie besonders w¨
ahrend des Erstellungsprozesses neuer Lernmaterialien auf-
treten, schnell l¨
astig werden kann. Wird noch in Betracht gezogen, wie viele Dateien einem
vollst¨
andigen Kurs in HTML angeh¨
oren, zeigt sich schnell das Ausmaß der Arbeit. Auch L¨
o-
sungen mit gepackten Dateien, wodurch lediglich eine Datei hochgeladen werden muss, k¨
onnen
6.3 Bewertung 65
Abbildung 6.4: Screenshot von SmartBLU
h¨
ochstens als ”fauler Kompromiss“ gewertet werden. Die Verbindung zwischen Autorensystem
und Lernplattform muss transparent erfolgen, daran f¨
uhrt kein Weg vorbei.
Grunds¨
atzlich zeigt sich, dass Lernplattformen nur bedingt f¨
ur den Erstellungsprozess von
Lernmaterialien geeignet sind. Hier hebt sich Blackboard mit seinem Content System von den
anderen Produkten ab, da es Versionierung und Verkn¨
upfungen von Dateien anbietet. So muss
ein Baustein mit einem Rechtschreibfehler, der bereits in vielen Kursen eingesetzt wurde, nur
ein Mal angepasst werden. Durch die Verkn¨
upfung ”propagiert“ sich die ¨
Anderung durch.
Auch die Unterst¨
utzung der Standards k¨
onnte besser sein. Viele Lernplattformen beschr¨
an-
ken sich auf das Entpacken und direkte Anzeigen von Dateien in den Formaten SCORM oder
IMS Content Packaging. Nur SmartBLU ist in der Lage, aus den Strukturinformationen des
enthaltenen Manifests eine Navigation zu generieren. Bei den anderen Lernplattformen muss
dies von den Autoren/-innen erledigt werden, was nicht nur Mehrarbeit verursacht, sondern
auch schlechtere Ergebnisse. Neben der eigenen Navigation des LMS muss parallel die des
Kurses untergebracht werden, wie es deutlich in den Screenshots der Abbildungen 6.2 und 6.3
zu erkennen ist. Letztendlich bleibt f¨
ur die eigentlichen Inhalte weniger Platz auf dem Bild-
schirm. Ein anderes Problem dieser Darstellung ergibt sich aus der Verwendung von Frames
bei HTML, wodurch die Bookmark-Funktionalit¨
at des Browsers nicht genutzt werden kann.
Leider wird von keiner Lernplattform die ¨
Ubersetzung von XML-Dateien in Formate wie
beispielsweise HTML oder PDF angeboten. Es werden auch keine Alternativen zur Trennung
von Inhalt und Layout angeboten, einer wichtigen Voraussetzung f¨
ur die Wiederverwendung
von Inhalten aus unterschiedlichen Quellen. Hier muss bei allen Systemen nachgebessert wer-
den.
66 Lernplattformen
System Anbindung Standards Kommunikation Organization Gestaltung
Blackboard Web-
Formular
SCORM,
IMS
Chat, Foren,
Whiteboard,
E-Mail
Kalender,
Terminplan,
Adressbuch
Unterst¨
utzung von
Fremdsprachen,
Layout beschr¨
ankt
anpassbar
WebCT WebDAV,
Web-
Formular
SCORM,
IMS,
AICC
Chat, Foren,
Whiteboard,
E-Mail
Kalender,
Aufgabenliste
Unterst¨
utzung von
Fremdsprachen,
Layout beschr¨
ankt
anpassbar
SmartBLU Web-
Formular
SCORM,
AICC
Chat, Foren,
Info-Bord
Unterst¨
utzung von
Fremdsprachen,
festgelegtes Lay-
out, Anpassung
der Oberfl¨
achen-
gr¨
oße
Tabelle 6.1: ¨
Ubersicht der Lernplattformen
Die Kommunikations- und Organisationsm¨
oglichkeiten sind bei allen Systemen sehr gut,
da gibt es nicht viel zu beanstanden. Zudem hat sich gezeigt, dass sie alle ihre St¨
arken f¨
ur
bestimmte Aufgaben haben. Ließen sie sich zu einem System vereinen, was technisch leider
nicht machbar ist, dann w¨
are das Ziel einer ausgereiften Lernplattform schon n¨
aher. Es bleibt
bei den kommerziellen Systemen nichts anderes ¨
ubrig, als auf entsprechende Erweiterungen
der Hersteller zu warten.
Kapitel 7
Web-Technologie
Im vorherigen Kapitel 6 ¨
uber Lernplattformen hat sich gezeigt, dass ihre Funktionalit¨
at auf
die t¨
agliche Lehre ausgerichtet ist. F¨
ur eine Archivierung von Lernmaterialien, gleich welcher
Form, eignen sie sich hingegen nur bedingt, denn oft sind die Verwaltungs- und Suchm¨
oglich-
keiten auf einfache Operationen beschr¨
ankt. Daher wird ein spezielles Datenhaltungssystem
f¨
ur Lernobjekte ben¨
otigt, das in dieser Arbeit als Repository bezeichnet wird. Zu seinen
wesentlichen Eigenschaften geh¨
ort eine direkte Anbindung an Lernplattformen sowie Auto-
rensysteme. Das Repository koordiniert die Arbeit und den Datenaustausch in Teams, sodass
es als zentrale Komponente zur Verf¨
ugung stehen muss.
Zur Zeit ist leider kein entsprechendes System f¨
ur modulare E-Learning-Inhalte erh¨
altlich,
weshalb seine Entwicklung als Teil dieser Arbeit abzusehen ist. Weil Java als Programmierspra-
che bereits feststeht und das Repository ¨
uber ein Rechnernetzwerk angesteuert werden soll,
wird in diesem Kapitel die Verf¨
ugbarkeit existierender Server, Rahmenwerke sowie Libraries
er¨
ortert.
Grundlage f¨
ur alle heutigen Netzwerk-Anwendungen ist das Protokoll TCP/IP [Stevens94;
Wright95], welches jedes moderne Betriebssystem von Haus aus beherrscht. F¨
ur die ¨
Ubertra-
gung von HTML-Seiten setzt das Protokoll HTTP [Stevens96; Gourley02] auf TCP/IP auf
und muss somit vom Repository unterst¨
utzt werden. Obwohl HTTP vom Aufbau her recht
einfach ist und mit den Klassen der Java-Standard-Library leicht umzusetzen ist, soll auf fer-
tige L¨
osungen zur¨
uckgegriffen werden. Im n¨
achsten Abschnitt werden verschieden Produkte
vorgestellt und ihre Vorteile sowie Schw¨
achen herausgearbeitet. Wesentlicher Gegenstand der
Betrachtung sind die verschiedenen etablierten Schichtenmodelle, die in Abschnitt 7.1 vorge-
stellt werden.
Die Steuerung des Repositories ¨
uber einfache HTML-Seiten wird nicht m¨
oglich sein. Viel-
mehr wird eine Web Application ben¨
otigt, also ein richtiges Programm, das HTML-Seiten
zur Repr¨
asentation der Daten einsetzt und die so genannte Gesch¨
aftslogik in Komponenten
auslagert. F¨
ur die Erstellung von Web Applications mit Java gibt es bereits eine Reihe von
fertigen Rahmenwerken, die in Abschnitt 7.2 vorgestellt werden.
F¨
ur die Steuerung der Web Application ¨
uber RPC bietet sich geradezu ein Web-Server an.
Das auf HTTP aufsetzende Protokoll Simple Object Access Protocol (SOAP) ist ideal f¨
ur diese
Aufgabe und soll daher die Fernsteuerung erm¨
oglichen. Neben der Spezifikation Java API
for XML Messaging (JAXM) von Sun, die eine rudiment¨
are Ansteuerung dieses Protokolls
erm¨
oglicht, gibt es auch Programmpakete, die eine Nutzung dieser Technologie auf einem
h¨
oheren Abstraktionsniveau erlauben. In Abschnitt 7.3 werden einige erh¨
altliche Produkte
vorgestellt.
Als letzte Funktion des Repositories soll kurz der Datenaustausch ¨
uber WebDAV erl¨
au-
tert werden. Weil WebDAV ebenfalls auf HTTP aufbaut, soll wieder eine integrierte L¨
osung
gefunden werden. Abh¨
angig vom ausgew¨
ahlten Web-Server stehen hier verschiedene Module
zur Auswahl.
68 Web-Technologie
7.1 Infrastruktur
Eine Errungenschaft der Software-Technik ist die Wiederverwendung von Modulen bzw. Kom-
ponenten, wodurch die Entwicklungszeit reduziert und die Stabilit¨
at des Produkts erh¨
oht wird.
Bei einer komplexen Anwendung wie einer Web Application gibt es eine Vielzahl potentieller
Kandidaten, die praktisch in jeder Web Application auftauchen. Die Firma Sun hat diesen Um-
stand zum Anlass genommen, neben der bekannten Java 2 Platform, Standard Edition (J2SE)
f¨
ur g¨
angige Applikationen, die Java 2 Platform, Enterprise Edition (J2EE) zu ver¨
offentlichen
[Shannon04]. Sie definiert einen Standard f¨
ur komponentenbasierte mehrschichtige Unterneh-
mensanwendungen, die Web-Technologien einsetzen. Abbildung 7.1 zeigt die grunds¨
atzlichen
Schichten einer Anwendung, auf die folgend eingegangen wird.
Abbildung 7.1: Schichten von J2EE-Anwendungen [Bodoff04, S. 3]
Ganz unten steht die Datenhaltung, die hier als Datenbank dargestellt ist. In den meisten
F¨
allen wird es sich in der Tat um eine relationale Datenbank handeln, aber die Daten k¨
on-
nen auch im Dateisystem oder einer anderen Datenhaltungsform gespeichert sein. Wichtig ist
lediglich die zur n¨
achsten Schicht pr¨
asentierte Schnittstelle, die den Komponenten mit der Ge-
sch¨
aftslogik, hier als Enterprise Beans bezeichnet, einen standardisierten Zugriff erm¨
oglicht.
Abh¨
angig von der Art des Clients, entweder handelt es sich um eine Anwendung (in der Ab-
bildung als Application Client bezeichnet) oder dynamische HTML-Seiten in einem Browser,
sitzt ¨
uber den Enterprise Beans eine Schicht mit Java Server Pages (JSP). Kurz umrissen ist
eine JSP eine Schablone, die aus HTML-Fragmenten und Java-Befehlszeilen besteht. Auf diese
Weise werden Inhalt und Logik der Enterprise Beans in die Darstellung integriert. Soll z.B.
ein bestimmter Wert angezeigt werden, der in einer Enterprise Bean gespeichert ist, gen¨
ugt
ein kurzer Befehl in Java f¨
ur das Auslesen und Umwandeln in HTML. Dieser Schritt entf¨
allt
bei eigenst¨
andigen Anwendungen, da sie sich um die Darstellung selbst k¨
ummern m¨
ussen. Auf
diese Weise soll z.B. das Autorensystem auf Lernobjekte zugreifen, indem es sie vom Server
herunterl¨
adt und in einer grafischen Oberfl¨
ache anzeigt. Zu Kontrollzwecken soll das Reposi-
tory aber auch ohne Autorensystem genutzt werden, sodass beide J2EE-Architektur-Modelle
f¨
ur modulare E-Learning-Inhalte ben¨
otigt werden.
Die J2EE umfasst eine Vielzahl von Technologien, Modellen und APIs, auf die bisher
noch nicht eingegangen wurde. Aufgrund der Komplexit¨
at kann dies im Rahmen dieser Arbeit
auch nicht vollst¨
andig geschehen. Weil J2EE f¨
ur eine große Zahl von Anwendungen konzi-
piert wurde, ist es sehr vielschichtig. In der Praxis wird jedoch h¨
aufig nur ein Bruchteil der
7.1 Infrastruktur 69
Funktionalit¨
at ben¨
otigt, was besonders bei unerfahrenen Entwicklern/-innen zu Konfusionen
f¨
uhrt. Welche Schichten sind wichtig und mit welcher Technologie erfolgt die Umsetzung? Wer
nicht den gesamten Umfang von J2EE kennt, l¨
auft leicht Gefahr, vorhandene L¨
osungen selbst
zu implementieren oder kompliziertere Wege als n¨
otig einzuschlagen. Auch f¨
ur das angestreb-
te Repository wird nicht der volle Funktionsumfang ben¨
otigt, sodass sich der Entwurf durch
Weglassung einzelner Schichten vereinfachen l¨
asst.
Bei den Enterprise Beans handelt es sich um ein Komponentenmodell, das f¨
ur die Imple-
mentierung der gesamten Funktionalit¨
at genutzt wird. Alle technischen Details werden hierbei
vom Komponenten-Container gekapselt, wodurch die Gesch¨
aftslogik in den Vordergrund r¨
uckt.
Es gibt einige Merkmale bei Anwendungen, die den Einsatz von Enterprise Beans anzeigen.
Muss das System mit der Anzahl von Benutzer/-innen skalieren, also ¨
uber mehrere Server
verteilt werden oder sollen Transaktionen unterst¨
utzt werden, dann sind Enterprise Beans die
geeignete Wahl.
In Hinblick auf das Repository werden die Eigenschaften der Enterprise Beans wohl nicht
ben¨
otigt. Abbildung 7.2 zeigt daher die beiden schematischen Schichten des J2EE-Servers an,
die f¨
ur die Umsetzung des Repositories relevant sind.
Abbildung 7.2: Client und Server [Bodoff04, S. 6]
Es gibt zwei Arten von Clients, die das Repository unterst¨
utzen soll: Web-Browser, die ¨
uber
die Web Tier auf die Business Tier zugreifen und selbst geschriebene Programme mit direktem
Zugriff. Wie viel der Server leisten muss, h¨
angt von den verwendeten Schichten ab. Ein Server
f¨
ur Enterprise Beans in der Business Tier ist wesentlich anspruchsvoller und umfangreicher
als einer, der lediglich die Web Tier unterst¨
utzt. Da f¨
ur die Business Tier die entwickelten
Komponenten aus den vorherigen Kapiteln zum Einsatz kommen, gen¨
ugt f¨
ur das Repository
ein Web- Server als J2EE-Umgebung. F¨
ur ein besseres Verst¨
andnis sind in Abbildung 7.3 sechs
Schritte aufgef¨
uhrt, die von der Infrastruktur zu leisten sind. Eine Anwendung als Client sieht
im Prinzip gleich aus, nur kann hier der Schritt 3 entfallen.
Zun¨
achst stellt der Client eine Anfrage an den Server ¨
uber das Protokoll HTTP, den so
genannten HTTP Request, der als Schritt 1 deklariert ist. Obwohl HTTP f¨
unf unterschied-
liche Methoden1kennt, treten in der Praxis ¨
uberwiegend GET- und POST-Anfragen auf, z.B.
wenn Daten ¨
uber eine Formular-Seite gesammelt und ¨
ubertragen werden. Auf der Server-Seite
werden die Daten von einem Web-Server entgegen genommen, in ein HTTPServletRequest
umgewandelt und in Schritt 2 an eine JSP oder ein Servlet weitergereicht. Ein Servlet ist
eine Java-Klasse mit genau definierter Schnittstelle, die in einem Container eingebettet ist
und die Anfragen des Clients verarbeitet. Neben den ¨
ubertragenen Parametern werden dem
Servlet zus¨
atzlich eine Reihe von kontextabh¨
angigen Daten, wie z.B. Cookies, IP-Adresse und
User-Daten ¨
ubergeben. JSPs und Servlets k¨
onnen in Schritt 3. die Daten auf zwei m¨
ogliche
Weisen verarbeiten. Neue sowie ver¨
anderte Daten werden an die Java Beans ¨
ubergeben und
1HEAD,GET,POST,PUT und DELETE
70 Web-Technologie
Abbildung 7.3: Sechs Schritte einer Anfrage [Bodoff04, S. 84]
anzuzeigende Daten ausgelesen. Bei Java Beans handelt es sich um Klassen, deren Schnitt-
stelle einer genauen Definition unterliegt [Englander97]. Wie die Daten persistent gehalten
werden, ist Bestandteil des Schritts 4, und kann z.B. ¨
uber Datenbanken, XML-Dateien oder
Serialisierung erfolgen. Der direkte Zugriff von den Web Components auf die Datenhaltungs-
schicht, ebenfalls als Schritt 4 bezeichnet, ist zwar theoretisch m¨
oglich, f¨
uhrt aber zu einer
sehr engen Verzahnung die sich nachteilig auswirkt. Wenn z.B. SQL-Anweisungen direkt in
eine JSP integriert sind, wird praktisch die Trennung zwischen Darstellung und Datenhaltung
aufgehoben, sodass sp¨
atere Erweiterungen, Anpassungen, Fehlerbehebungen, etc. beeintr¨
ach-
tigt werden. Aus diesem Grund soll in dieser Arbeit die Kommunikation stets zwischen Web
Components und Java Beans erfolgen. Nachdem alle Berechnungen und Operationen durchge-
f¨
uhrt wurden, wird in Schritt 5 das Ergebnis in Form eines HTTPServletResponse aufbereitet
und an den Web-Server ¨
ubergeben. Der schickt dem Client in Schritt 6 per HTTP Response
eine anzeigbare HTML-Seite.
Aus diesem Ablauf l¨
asst sich gut ableiten, was f¨
ur die Umsetzung des Repositories ben¨
otigt
wird, n¨
amlich ein Web-Server mit einem Container f¨
ur Web Components. Um die M¨
oglichkei-
ten der Web Components differenzierter darzustellen, ist diese Schicht in Abbildung 7.4 weiter
aufgegliedert.
Abbildung 7.4: Schichten der Repr¨
asentation [Bodoff04, S. 85]
7.1 Infrastruktur 71
Die Basis aller zur Verf¨
ugung stehenden Technologien sind die Servlets. Sie erm¨
oglichen
eine sehr genaue Steuerung der Vorg¨
ange, setzen aber umfangreiche Kenntnisse voraus. Um
die Arbeit zu vereinfachen, gibt es abstraktere Mechanismen wie die Java Server Pages, die
eine Verquickung von HTML und Java-Code erm¨
oglichen. Technisch gesehen, werden JSPs
wiederum zu Servlets ¨
ubersetzt. Weil auch JSPs meist nicht um eine Programmierung in Ja-
va umhin kommen, wenn z.B. die Kommunikation mit den Java Beans erfolgt, wurden die
Standard Tag Library eingef¨
uhrt. JSPs lassen sich n¨
amlich um eigene Tags erweitern, sodass
sich auch anspruchsvollere Operationen kapseln lassen. Im optimalen Fall kann eine Person
ohne Java-Kenntnisse JSPs erzeugen und auf Java Beans zugreifen, ohne programmieren zu
m¨
ussen. Die Java Server Faces sind eine recht neue Technologie und orientieren sich an der
klassischen Programmierung grafischer Oberfl¨
achen. Es gibt einzelne Komponenten f¨
ur Be-
nutzerinteraktionen, die sich beliebig kombinieren lassen und auf Events reagieren. Praktisch
gesehen, abstrahiert dieser Mechanismus die drei anderen Schichten, indem die eingesetzten
Techniken weitestgehend verdeckt werden.
Stellt sich noch die Frage, wie eng die einzelnen Komponenten mit dem Web-Server ver-
bunden sind. F¨
ur das Repository l¨
asst sich bereits absehen, dass es aus vielen Klassen, JSP
und anderen Dateien bestehen wird, die sich auf diverse Verzeichnisse verteilen. ¨
Uber eine
Konfiguration wird festgelegt, wie diese Dateien in Beziehung stehen und welche Aufgabe sie
haben. Wie viel Einfluss nimmt aber die eingesetzte Software? Muss bei einem Wechsel des
Web-Servers die gesamte Anordnung und Konfiguration angepasst werden? Die Antwort lautet
”Nein“, denn die Spezifikation von J2EE sieht auch diesen Fall vor. Alle ben¨
otigten Dateien
lassen sich in einem Paket zusammenfassen und in einen Web-Server ”deployen“. Dieser Begriff
hat sich durchgesetzt und wird auch in anderen Kontexten verwendet, in dem Komponenten
oder Pakete integriert werden. Abbildung 7.5 zeigt die vorgeschriebene interne Struktur eines
solchen Pakets.
Abbildung 7.5: Interne Modulstruktur [Bodoff04, S. 90]
An oberster Stelle liegt das Hauptverzeichnis, das hier als Assembly Root bezeichnet ist.
Der Verzeichnisname kann beliebig gew¨
ahlt werden und wird bei manchen Web-Servern zum
Bestandteil der sp¨
ateren Aufruf-URL. Um als Paket zu gelten, muss es mindestens das Ver-
zeichnis WEB-INF, das genau so geschrieben sein muss, und die Datei web.xml enthalten. Sie
72 Web-Technologie
wird oft auch Deployment Descriptor genannt, weil sie beschreibt, wie welche Komponenten
verbunden und adressiert werden. Eigene Libraries werden im Verzeichnis lib abgelegt und
lose Klassen in classes. Die enthaltenen Dateien werden automatisch in den Klassenpfad ein-
getragen, weshalb keine weitere Konfiguration notwendig ist. Im letzten Verzeichnis tags sind
alle n¨
otigen Dateien f¨
ur die Tag Libraries enthalten, die ebenfalls automatisch eingelesen wer-
den. Bleiben noch die JSP-Dateien, die sich innerhalb des Pakets beliebig positionieren lassen.
Allerdings sollte das Verzeichnis WEB-INF ausgenommen werden, da nicht alle Web-Server
diesen Ort f¨
ur JSP unterst¨
utzen. Gepackt zu einer Datei, kann diese Struktur dann einfach in
ein System integriert werden.
Bleibt zu kl¨
aren, welche Produkte es ¨
uberhaupt gibt. Neben vielen kommerziellen Anbie-
tern, wie z.B. WebSphere2von IBM, WebLogic3von BEA und WebObjects4von Apple, gibt
es auch einige frei erh¨
altliche Produkte. Die St¨
arken der kommerziellen Systeme sind auf jeden
Fall ihr hoher Leistungsumfang und die bessere Bedienbarkeit, die durch eine Reihe mitgelie-
ferter Werkzeuge erreicht wird. Da nur die Web Tier von J2EE ben¨
otigt wird, gen¨
ugt f¨
ur das
Projekt mαth-kit aber eine freie L¨
osung. Zur n¨
aheren Auswahl stehen hier Tomcat5,Jetty6
und Resin7. In Funktionsumfang und der Leistung stehen sich die Produkte im Großen und
Ganzen in nichts nach.
7.2 Web Applications
Mit J2EE wird gr¨
oßeren Projekten eine Vielzahl von Techniken und Mechanismen angeboten,
die eine strukturierte Gestaltung sowie Planung erm¨
oglicht. Der generische Ansatz bereitet kei-
ne großen Einschr¨
ankungen, sodass nach eigenem Belieben vorgegangen werden kann. Durch
Auslassen oder Hinzuf¨
ugen bestimmter Teile sind der individuellen Umsetzung keine Grenzen
gesetzt. Der Preis f¨
ur diese Flexibilit¨
at ist die Suche nach dem eigenen geeigneten Vorgehen.
Eine M¨
oglichkeit ist die Verwendung des Entwurfsmusters MVC, das die Aufteilung des Sys-
tems in Model,View und Controller (MVC) vorgibt. Urspr¨
unglich f¨
ur grafische Anwendungen
gedacht, hat es sich mit ein paar Anpassungen als Systemarchitektur f¨
ur Web Applications
durchgesetzt. Abbildung 7.6 verdeutlicht die Zusammenh¨
ange zwischen den einzelnen Kom-
ponenten.
ControllerView
Model
JSPs Servlet
Query
State State
Change
Components
View Selection
Input
Abbildung 7.6: Model,View und Controller f¨
ur Web Applications
In dieser Aufteilung sind View und Controller als Elemente der Web Tier realisiert, wobei
von außen betrachtet lediglich der Controller angesprochen wird (als Input eingezeichnet).
Jeder Aufruf einer URL geht somit direkt auf das Servlet, welches die Eingabe aufbereitet,
die entsprechende Komponente des Models ausw¨
ahlt und den gew¨
unschten Befehl aufruft. Die
Komponente verarbeitet anschließend die ¨
ubergebenen Daten und gibt einen R¨
uckgabewert
zur¨
uck, von dem der Controller seinen n¨
achsten Arbeitsschritt abh¨
angig macht. War z.B. eine
2http://www-306.ibm.com/software/websphere (29.10.05)
3http://www.bea.com (29.10.05)
4http://www.apple.com/webobjects (29.10.05)
5http://jakarta.apache.org/tomcat (29.10.05)
6http://jetty.mortbay.org (29.10.05)
7http://caucho.com (29.10.05)
7.3 Web Services 73
Eingabe fehlerhaft oder konnte der Befehl aufgrund anderer Umst¨
ande nicht ordnungsgem¨
aß
durchgef¨
uhrt werden, ruft das Servlet eine JSP f¨
ur die erneute Eingabe oder eine Fehlerseite
auf. Bei erfolgreicher Ausf¨
uhrung wird eine andere JSP ausgew¨
ahlt, die ¨
uber den weiteren
Fortgang informiert. Unabh¨
angig vom zur¨
uck gegebenen Status, ben¨
otigen ann¨
ahernd alle JSP
einen Zugriff auf die Daten des Modells, um den aktuellen Zustand anzuzeigen. Der Zugriff
selbst ist nur lesend, weil andernfalls der Controller umgangen w¨
urde, was nicht gew¨
unscht
ist. Nachdem die JSP ausgef¨
uhrt und als Ergebnis eine HTML-Seite produziert wurde, wird
diese als View an den Client gesendet.
Das Entwurfsmuster MVC gibt einen Leitfaden, wie eine Web Application zu strukturieren
ist, l¨
asst die Implementierung aber offen. Auch das J2EE bietet keine Bordmittel an, die eine
Entwicklung solcher Anwendungen vereinfacht. Als L¨
osungen dieses Problems bleiben somit
entweder eine Eigenentwicklung oder der Einsatz eines existierenden Rahmenwerks ¨
ubrig. Die
Eigenentwicklung spielt ihren Vorteil bei kleinen Systemen aus, die sich nicht oft ¨
andern.
Hier kann eine kleine schnelle L¨
osung wesentlich effizienter sein als eine umfangreiche. Ist die
Anwendung aber etwas gr¨
oßer und ben¨
otigt eine gewisse Flexibilit¨
at, dann sollte von diesem
Ansatz Abstand genommen und stattdessen auf ein Rahmenwerk zur¨
uckgegriffen werden. Der
Nachteil hierbei liegt in der Komplexit¨
at, die nicht zu untersch¨
atzen ist. In dieser Arbeit
werden kurz zwei Produkte vorgestellt: Struts und Spring.
Mit Struts8bietet die Apache Group ein Rahmenwerk an, dass sich perfekt in den ausge-
w¨
ahlten Web-Server Tomcat integrieren l¨
asst. Ein zentrales Konzept zur Konfiguration und
Adaption sind die bereits erw¨
ahnten Java Beans. Ihre Schnittstelle ist so ausgelegt, dass sie zur
Laufzeit ohne vorherige Bindung beim Kompilieren initialisiert und genutzt werden k¨
onnen.
Struts nutzt diese Eigenschaften zur Konfiguration des Controllers, der durch eigene Klassen
erweitert werden kann. Mit Hilfe einer XML-Datei werden die einzelnen Komponenten zur
Laufzeit erzeugt und miteinander verkn¨
upft. Aber auch zum Datenaustausch zwischen den
Komponenten von Struts und den eigenen Klassen kommen Java Beans zum Einsatz. So wer-
den Eingaben ¨
uber Formulare in HTML Seiten automatisch in Java Beans umgewandelt und
weitergereicht. Wenn gew¨
unscht, ¨
uberpr¨
ufen so genannte Validatoren die Werte auf G¨
ultig-
keit, indem sie vorher festgelegte Regeln anwenden. Weitere Informationen zu Struts finden
sich z.B in [Turner03; Carnell03; Cavaness04].
Das Rahmenwerk Spring9geht indes einen wesentlichen Schritt weiter. Es ist selbst in
Schichten eingeteilt, und schickt sich an, eine Alternative bzw. Erg¨
anzung zu den Architekturen
mit Enterprise Beans zu sein. Neben der Unterst¨
utzung des Entwurfsmusters MVC gibt es viele
weitere Bausteine in Spring, mit denen sich Web Applications aufziehen lassen. Anstatt auf
die umfangreichen aber technisch anspruchsvollen Enterprise Beans zuzugreifen, werden die
Daten und die Gesch¨
aftslogik in einfachen Beans sowie POJOs10 gehalten. Spezielle Klassen
nach dem Entwurfsmuster Factory [Gamma95] erm¨
oglichen die Trennung der Konfiguration
von Beans und der Programmlogik. Auf diesem Prinzip beruht das gesamte Rahmenwerk.
Dank der Flexibilit¨
at und Unabh¨
angigkeit der einzelnen Komponenten k¨
onnen mit Spring
von kleinen Web-Pr¨
asentationen bis zu Unternehmensanwendungen fast alle Projektformen
realisiert werden. Mehr Informationen zu Spring finden sich z.B. in [Johnson04; Tate04].
7.3 Web Services
Web Services erm¨
oglichen den Zugriff auf Daten und das Ausf¨
uhren von Befehlen ¨
uber eta-
blierte Techniken. Mittlerweile sind die Spezifikationen, Standards und Implementierungen
verschiedener Hersteller jedoch so vielf¨
altig geworden, dass eine pauschale Aussage ¨
uber die
F¨
ahigkeiten von Web Services schwer f¨
allt. Grunds¨
atzlich werden Daten ¨
uber das Simple Object
Access Protocol (SOAP) mit Hilfe des Internets ¨
ubertragen. Obwohl es bei der physikalischen
8http://struts.apache.org (29.10.05)
9http://www.springframework.org (29.10.05)
10POJO steht f¨
ur Plain Old Java Object und bezeichnet schlicht alle Klassen, die keine Beans sind.
74 Web-Technologie
¨
Ubermittlung der Daten keine Vorgaben gibt — der Einsatz per Mail wird z.B. von vielen
Implementierungen unterst¨
utzt —, ist in der Praxis das Protokoll HTTP die erste Wahl. Zur
Laufzeit werden bei SOAP interne Datenstrukturen zu XML ¨
ubersetzt, ¨
ubertragen und vom
Kommunikationspartner zur¨
uck transformiert. Hierdurch ist SOAP unabh¨
angig von jeglichen
Programmiersprachen, ben¨
otigt aber spezielle Mechanismen, die eine Verbindung zwischen
diesen beiden Welten herstellen. Denn Methodenaufrufe sollen auf Seiten der Clients m¨
og-
lichst transparent durchgef¨
uhrt werden, sodass die Entwickler/-innen mit so wenig Details wie
n¨
otig belastet werden.
Zun¨
achst muss die Gesch¨
aftslogik implementiert werden und die nach außen angebotene
Schnittstelle auf m¨
oglichst wenig Klassen verteilt werden. Als so genanntes Package werden die
zusammengefassten Dateien in einen speziellen Server integriert, der die n¨
otige Infrastruktur
zur Ausf¨
uhrung bereit h¨
alt. Hiernach k¨
onnen die Clients bestimmte Parameter zur Nutzung des
Web Service abfragen, wie z.B. Kodierungen, Datenstrukturen und Protokolle. Die Antworten
werden in der Web Services Description Language (WSDL) [Walsh02a] ¨
ubermittelt, einer vom
WWW Consortium (W3C) spezifizierten Sprache in XML. Mit diesen Informationen k¨
onnen
in Java drei verschiedene Formen von Clients gebaut werden: Static Stub,Dynamic Proxy und
Dynamic Invocation Interface (DII).
Die ersten beiden Varianten ben¨
otigen ein spezielles Werkzeug, mit dem die WSDL-Daten
einmalig im Voraus in Klassen umgewandelt werden. Bei einem Client mit Static Stub werden
alle Klassen erzeugt, die f¨
ur die Serialisierung und Deserialisierung der Daten ben¨
otigt wer-
den11. Ein Nachteil dieser Vorgehensweise ist der Aufwand bei ¨
Anderungen der WSDL-Daten,
die immer eine vollst¨
andige Neu¨
ubersetzung nach sich ziehen. Dieses Problem wird bei Cli-
ents mit Dynamic Proxy teilweise umgangen, denn es werden lediglich Schnittstellen von den
Werkzeugen erzeugt und keine Klassen mit einer Implementierung. Die wird erst zur Laufzeit
automatisch erzeugt und eingebunden, wodurch kleine ¨
Anderungen Ber¨
ucksichtigung finden.
Der Preis f¨
ur diesen ”Komfort“ liegt in der verz¨
ogerten Ausf¨
uhrung des ersten Aufrufs, denn im
Hintergrund laufen komplexe Prozesse ab, die den Dynamic Proxy erzeugen. Volle Kontrolle,
weniger Ressourcen-Bedarf und volle Flexibilit¨
at lassen sich nur mit dem Dynamic Invocation
Interface erreichen. Diese Schnittstelle ist Bestandteil der JAX-RPC-API, auf die gleich n¨
aher
eingegangen wird. Die Auswertung der WSDL-Daten bleibt bei DII den Entwicklern/-innen
¨
uberlassen, um z.B. einen sehr schlanken und optimierten Client zu schreiben, der aber nicht
automatisch auf ¨
Anderungen des Web Services reagieren kann.
Um eine richtige Abw¨
agung treffen zu k¨
onnen, m¨
ussen die Vor- sowie Nachteile von Static
Stub,Dynamic Proxy und DII verglichen werden. F¨
ur die Belange des Projekts mαth-kit ist
der Static Stub vollkommen ausreichend, denn es werden keine gravierenden ¨
Anderungen an
den Schnittstellen der Komponenten erwartet. Diese L¨
osung ist somit schlanker und schneller
in der Ausf¨
uhrung als der Dynamic Proxy und einfacher in der Umsetzung als die Ansteuerung
¨
uber DII.
Die Steuerung der vorgestellten drei Methoden erfolgt ¨
uber die Java API for XML-Based
RPC (JAX-RPC). Abh¨
angig vom gew¨
ahlten Typ sind nur wenige Befehle n¨
otig, bis ein Web
Service initialisiert und angesteuert ist. Abbildung 7.7 zeigt ein typisches Szenario.
Der Client greift direkt auf den Stub zu, der intern wiederum JAX-RPC-Aufrufe nutzt.
¨
Uber das Netz werden dann in beide Richtungen SOAP-Nachrichten verschickt. Auf der Seite
des Servers ruft die JAX-RPC-Laufzeitumgebung mit Hilfe von so genannten Ties die Service-
Methoden auf. Bei den Ties handelt es sich um den ”Klebstoff“ zwischen den Service-Klassen,
der von dem Server automatisch generiert wird.
Neben den kommerziellen Anbietern, wie z.B. Systinet Server for Java12 von Systinet,
11Unter Serialisierung bzw. Deserialisierung wird die Umwandlung bzw. R¨
uckumwandlung von Daten in einen
Daten-Stream verstanden, der z.B. ¨
uber ein Netzwerk transportiert wird.
12http://www.systinet.com (29.10.05)
7.4 WebDAV 75
Abbildung 7.7: JAX-RPC-Aufruf [Bodoff04, S. 321]
Cape Clear 613 von Cape Clear und Artix14 von Iona, gibt es leider nur das Projekt Axis15
von der Apache Group, das eine ernst zu nehmende freie Alternative anbietet.
7.4 WebDAV
WebDAV steht f¨
ur Web-based Distributed Authoring and Versioning und bezeichnet eine Er-
weiterung des HTTP-Protokolls. In erster Linie soll es die gemeinsame Arbeit in Gruppen
erm¨
oglichen und sich in die existierende Infrastruktur einbetten. Die genaue Funktion, die
weder die Entwickler/-innen noch die Benutzer/-innen interessieren d¨
urfte, ist in zwei Doku-
menten [Slein98; Goland99] festgelegt. Im Grunde genommen wird HTTP um ein paar Header
und Methoden erweitert, die das Auslesen von Dateistrukturen gestattet. Leider fehlt bei
WebDAV die Versionierung, obwohl der Begriff Bestandteil des Namens ist, weshalb eine Er-
g¨
anzung mit dem Namen DeltaV n¨
otig war. Auch die Details dieser Spezifikation [Clemm99]
sind unerheblich, weil auf fertige L¨
osungen zur¨
uckgegriffen werden soll.
Der Web-Server Tomcat wird beispielsweise mit einem eigenen WebDAV -Modul ausge-
liefert, sodass auf der Server-Seite lediglich ein wenig Konfigurationsarbeit ansteht. Auf der
Client-Seite ist die Auswahl freier Libraries leider wieder beschr¨
ankt. Mit Jakarta Slide16
stellt die Apache Group eine vollst¨
andige Umsetzung von WebDAV und eine rudiment¨
are von
DeltaV bereit.
13http://www.capeclear.com (23.10.05)
14http://www.iona.com (29.10.05)
15http://ws.apache.org/axis (29.10.05)
16http://jakarta.apache.org/slide/ (29.10.05)
Kapitel 8
Metapher
Ein wichtiger Aspekt des Projekts mαth-kit ist der Einsatz der Baukasten-Metapher, um den
Benutzern/-innen ein besseres Verst¨
andnis der Funktionalit¨
at zu vermitteln. In der Informatik
spielen Metaphern seither eine bedeutende Rolle bei der Begriffsbildung, was bei einer so
jungen Wissenschaft nicht weiter verwunderlich ist, da nicht f¨
ur jeden neuen Gegenstand des
Interesses ein neues Wort erfunden werden kann. Begriffe wie M¨
ause, Schlangen, B¨
aume, Keller
und viele mehr stammen aus dem allt¨
aglichen Sprachgebrauch, werden aber in einer anderen
Bedeutung eingesetzt, die ihrem urspr¨
unglichen Kontext enthoben ist. Nur bestimmte Aspekte
des Begriffs werden ¨
ubernommen, andere hingegen ignoriert. Was zeichnet aber eine Metapher
genau aus, wie ist sie definiert? In der Brockhaus-Enzyklop¨
adie findet sich hierzu folgendes:
”Ausdrucksmittel der uneigentlichen Rede; das eigentlich gemeinte Wort wird er-
setzt durch ein anderes, das eine sachl. oder gedankl. ¨
Ahnlichkeit oder dieselbe
Bildstruktur aufweist, z.B.
Quelle
f¨
ur
Ursache
. Die Sprache springt dabei,
im Unterschied zur Metonymie, gleichsam von einem Vorstellungsbereich in einen
anderen.“ [Bro91, S. 521]
Wie die gegebene Definition vermuten l¨
asst, gibt es eine Reihe anderer sprachliche Begriffe,
die gewisse Eigenschaften mit der Metapher gemein haben, aber nicht mit ihr verwechselt wer-
den sollten. Die Allegorie ist eine bildhafte Darstellung eines Begriffs (Frau mit verbundenen
Augen f¨
ur ”Gerechtigkeit“), das Homonym ein gleich lautendes Wort mit anderer Bedeutung
(der Gehalt/das Gehalt), die Katachrese ein bildlicher Ausdruck f¨
ur eine fehlende Bezeichnung
(Schl¨
ussel”bart“) und die Metonymie eine Bedeutungsvertauschung (”Stahl“ f¨
ur ”Schwert“), um
nur einige Beispiele zu nennen.
Metaphern k¨
onnen aus mehreren W¨
ortern, so genannte Wortfelder, bestehen, die in einem
gr¨
oßeren Bedeutungszusammenhang stehen. Die Fl¨
ussigkeitsmetapher in der Elektrotechnik
sei stellvertretend als Beispiel genannt, bei der die Begriffe Strom, Kanal, Quelle, Kondensator
usw. ein Wortfeld bilden. Es ist daher zweckm¨
aßig, die metaphorische Definition nicht auf
einzelne Begriffe zu reduzieren.
Als rein sprachliches Mittel ist die Metapher f¨
ur den Einsatz in der Software-Technik
freilich nicht hinreichend, sondern bedarf einer weitergehenden, umfassenderen Definition, die
den Menschen und die Gegenst¨
ande des Interesses in einen Zusammenhang bringt. Werner
Ingendahl f¨
uhrt den Begriff metaphorischer Prozess in [Ingendahl71] ein, der umfassend die
verschiedenen Kontexte der Metaphorik beschreibt.
8.1 Metaphorischer Prozess
Der Metaphorische Prozess wird nun auf Basis von [Busch98] aus verschiedenen Theorien und
Ansichten hergeleitet. Abbildung 8.1 gibt einen ¨
Uberblick ¨
uber die verschiedenen Begriffe, die
mit ihm verbunden sind, und deren Relationen.
78 Metapher
Wortgruppe
Kontext
üblicher
Wortgruppe
Kontext
unüblicher
Metapher
Übertragung
Interaktion
Produzent Rezipient
Funktion
Sache,
Neues,
Bezeichnetes
Wirklichkeit,
...
Gegenstand
Sonntag
August
27
Metaphorischer Prozess
Situation
Abbildung 8.1: Metaphorischer Prozess nach [Busch98, S. 25]
Jedes Wort hat in Aristoteles’ Poetik [Aristoteles82] genau eine ”eigentliche“ Bedeutung
und ist außerhalb des Zusammenhangs ”uneigentlich“ verwendet. Die ¨
Ubertragung (griech.
µεταϕoρα) eines Wortes aus einem ¨
ublichen Kontext in einen un¨
ublichen ist daher ein
zentraler Aspekt des aristotelischen Metapher-Begriffs. Jedoch ist die Beschr¨
ankung auf einzel-
ne Worte zu restriktiv, weshalb lieber die bereits definierte Wortgruppe genutzt werden soll.
Max Black kritisierte die einseitig gerichtete Beziehung der ¨
Ubertragung als unzureichend und
hat daher die Interaction View entwickelt [Black62]. Diese beschreibt, wie sich die Wortgrup-
pen aus dem ¨
ublichen und dem un¨
ublichen Kontext gegenseitig beeinflussen. Es werden die
implizierten Bedeutungselemente der Wortgruppe aus dem ¨
ublichen Kontext ¨
ubernommen,
die mit denen des Gegenstandes ¨
ubereinstimmen. Hierdurch werden dessen ¨
ubertragbare
Charaktermerkmale verdeutlicht, wohingegen die nicht erfassten an Bedeutung verlieren. In
den Worten von Max Black heißt es:
”Die Metapher kommt dadurch zustande, daß auf den Hauptgegenstand1ein Sys-
tem von
assoziierten Implikationen
angewandt wird, das f¨
ur den untergeordneten
Gegenstand2charakteristisch ist.“ Black zitiert nach [Haverkamp83, S. 75]
”Die Metapher selegiert, betont, unterdr¨
uckt und organisiert charakteristische Z¨
uge
des Hauptgegenstands, indem sie Aussagen ¨
uber ihn einbezieht, die normalerweise
zum untergeordneten Gegenstand geh¨
oren“ Black zitiert nach [Haverkamp83, S. 76]
Der Gegenstand im Schaubild 8.1 steht mit der Metapher ebenfalls in einer Wechselbe-
ziehung, da der Zustand des Gegenstandes Einfluss auf die Metapher selbst aus¨
ubt. Carsten
Busch nennt als Beispiel den Mond, bei dem die Bezeichnungen ”Zitronenmond“ und ”Silber-
sichel“ von dessen momentanen Eigenschaften gepr¨
agt sind [Busch98, S. 15–16]. Angemerkt
sei noch, dass der Begriff ”Gegenstand“ im Zusammenhang mit Metaphern offensichtlich un-
gl¨
ucklich gew¨
ahlt ist, da unter dieser Kategorie auch Menschen und Tiere verstanden sind,
und wird hier ausschließlich zur Konsistenzwahrung mit den referierten Arbeiten verwendet.
1Das ist der ¨
uber die Wortgruppe im un¨
ublichen Kontext beschriebene Gegenstand.
2Das ist der ¨
uber die Wortgruppe im ¨
ublichen Kontext beschriebene Gegenstand.
8.1 Metaphorischer Prozess 79
Die Beziehungen zwischen den Wortgruppen, der Metapher und dem Gegenstand existie-
ren selbstverst¨
andlich nicht um ihrer selbst willen, sondern nur indirekt ¨
uber den Menschen, in
seinem Denken, Sprechen und F¨
uhlen. Der Mensch ist es, der durch kreative Leistungen eine
sprachliche Handlung durchf¨
uhrt. Im Schaubild tritt er als Produzent/-in und Rezipient/-
in auf, der/die jeweils mit der Metapher und dem Gegenstand in Wechselbeziehung steht. Im
Grunde sind sich Produzent/-in und Rezipient/-in sehr ¨
ahnlich, da sie die gleiche geistige Leis-
tung erbringen m¨
ussen. Der wesentliche Unterschied besteht darin, wie sie zu einer Metapher
gekommen sind. Bei dem/der Produzent/-in kommt die Metapher, bewusst oder unbewusst,
aus dem Inneren, hingegen empf¨
angt der/die Rezipient/-in sie von außen. Auch wenn diese
Unterscheidung oftmals verschwimmt bzw. umgekehrt wird, ist diese Betrachtung sinnvoll, um
die pragmatische Dimension — wie also (Sprach)-Zeichen auf einen Menschen wirken — aus-
machen zu k¨
onnen. Metaphern k¨
onnen demnach vom/von der Rezipient/-in ”nicht erkannt“,
”erkannt aber nicht verstanden“, ”verstanden aber abgelehnt“ und ”v¨
ollig anders verstanden“
werden. Die Kommunikation beschr¨
ankt sich hierbei nicht nur auf das gesprochene Wort,
sondern umfasst den gesamten Habitus.
Der Gebrauch einer Metapher hat eine Funktion, eine Absicht, die mit ihm verbunden
ist. Walter Seifert beschreibt in seinem Aufsatz [Seifert80] sieben Funktionen, von denen in
dieser Arbeit eine als besonders wichtig f¨
ur die Entwicklung und Nutzung eines Software-
Systems erachtet wird: die Pr¨
adikationsfunktion. Sie dient dem Erfassen der Realit¨
at durch
Modellbildung sowie Analogiebeziehungen und soll in diesem Kontext den Entwicklern/-innen
beim Entwurf und der Kommunikation eine h¨
ohere Produktivit¨
at verleihen. Diese Funkti-
on kann ebenfalls die Benutzer/-innen bei der sp¨
ateren Gew¨
ohnung an die Arbeit mit dem
System unterst¨
utzen. F¨
ur diesen Personenkreis kann auch eine weitere Funktion, die affektiv-
emotionale, beabsichtigt sein. Dabei geht es um die Vermittlung von Gef¨
uhlsnuancen, mit
Ausrichtung auf intuitive Erfahrungen. So k¨
onnen z.B. ¨
Angste minimiert werden, welche kom-
plexe Software-Systeme in Laien ausl¨
osen k¨
onnen.
Die Funktion an sich ist abh¨
angig von der Situation, in der eine Metapher produziert oder
rezipiert wird. Es besteht schon ein Unterschied, ob eine Metapher in einem Software-Entwurf,
im Schulunterricht oder einem Gedicht Verwendung findet. Somit umfasst die Situation alles,
was bei der Metaphorik von Bedeutung ist. Als drei wesentliche Elemente zur Bestimmung
oder Unterscheidung von Situationen lassen sich die ¨
Ortlichkeit, der Zeitpunkt bzw. die Dauer
und die beteiligten Personen benennen.
Die Zeit spielt im metaphorischen Prozess eine besondere Rolle, und ist daher im Schaubild
explizit aufgef¨
uhrt. Sie bestimmt wie und ob eine Metapher verstanden wird. Der ”Gully“
z.B. ist eine Metapher, die in den allgemeinen Sprachgebrauch ¨
ubergegangen ist und wohl
im 19. Jahrhundert aus dem englischen ”gullet“ (Schlund) hervorgegangen ist. Solche nicht
ohne weiteres identifizierbare Metaphern werden tote bzw. lexikalisierte Metaphern genannt.
In [Wolff82] werden neben diesem drei weitere Typen von Metaphern unterschieden: kreative
Metaphern (spontan, innovativ), konventionelle Metaphern (Klischees) und Remetaphosierung
(Reaktivierung eines Bildes durch eine Abwandlung). Um welchen Typen einer Metapher es
sich im Einzelnen handelt, ist abh¨
angig von der jeweiligen Gruppe von Rezipienten/-innen
und dem relativen Verwendungszeitraum innerhalb dieser ”Sprachgemeinschaft“.
Zusammengefasst ist ein metaphorischer Prozess eine ¨
Ubertragung einer Wortgruppe von
einem ¨
ublichen in einen un¨
ublichen Kontext, bei der es zu einer Interaktion kommt, die im
g¨
unstigen Fall zu einem besseren Verst¨
andnis eines Gegenstandes f¨
uhrt. Die Metapher wird
meist bewusst von Produzenten/-innen erzeugt und von Rezipienten/-innen nachvollzogen,
wobei eine bestimmte Funktion beabsichtigt ist, deren Wirkung von der Situation und dem
Zeitpunkt bzw. der Dauer abh¨
angt.
80 Metapher
8.2 Metaphern und Software-Technik
Metaphern sollen in dieser Arbeit zwei wesentliche Aufgaben erf¨
ullen: Beim Entwurf erlau-
ben sie einen selbstverst¨
andlichen Umgang mit abstrakten Begriffen und f¨
ur die sp¨
ateren
Anwender/-innen beschleunigen sie den Zugang zum erstellten Programm. Besonders bei der
Arbeit im Team und einem Austausch von Ideen k¨
onnen Metaphern die Kommunikation ver-
einfachen. Letztendlich werden Softwaresysteme aber nicht um ihrer selbst willen erstellt,
sondern sollen Menschen bei der Erledigung ihrer T¨
atigkeit unterst¨
utzen.
In der Software-Technik spielen Metaphern bereits auf der Ebene der Programmiersprache
eine wichtige Rolle. Genau genommen handelt es sich bereits bei dem Wort ”Programmier-
sprache“ um eine Metapher. In Anlehnung an nat¨
urliche Sprachen wie Englisch, k¨
onnen Pro-
grammtexte auch von Menschen gelesen werden, die nicht mit den technischen Details vertraut
sind [Louden94]. Abstrakt und formal beschriebene Kontroll- und Datenstrukturen erhalten
durch Metaphern ,wie beispielsweise Schleifen, B¨
aume und Schlangen, sprechende Bezeich-
ner, durch die wesentliche Merkmale erfasst werden. Auch die Vererbung in objektorientierten
Sprachen ist eine Metapher, mit der die kontrollierte Weitergabe bestimmter Eigenschaften
umschrieben wird. Um dem metaphorischen Prozess aus dem vorherigen Abschnitt gerecht
zu werden, folgen Buschs Spezifika f¨
ur Metaphern aus der Sichtweise der Programmierung
[Busch98, S. 151]:
•Als Metaphern-Produzenten/-innen kommen in erster Linie Programmierer/-innen
und Entwickler/-innen in Betracht.
•Die Rezipienten/-innen lassen sich weniger genau eingrenzen, aber in Frage kommen
vor allem wiederum Programmierer/-innen und eventuell Benutzer/-innen.
•Metaphern auf dieser Ebenen nehmen vor allem eine Pr¨
adikations- und eine heuristische
Funktion wahr.
•Gegenstand der Metapher sind das Programmieren, Programmiersprachen und alle
enger damit zusammenh¨
angende Aspekte.
•Als ¨
ubliche Kontexte dienen eine Vielzahl verschiedenster Bereiche. Die vorherrschen-
den sind sicherlich nach wie vor die Bedeutungsfelder ”Sprache“ und ”
Vorschrift“.
•Den un¨
ublichen Kontext bildet wie so oft die Informatik.
Metaphern auf einem h¨
oheren Abstraktionsniveau dienen grundlegenden Sichtweisen des
Entwurfs und der Programmierung von Software. Ein gutes Beispiel sind John Shores Software-
Geb¨
aude in [Shore85]. Er vergleicht den Entwurf und Bau eines Hauses mit dem von Program-
men. Zuerst steht ein Idee von einem Haus, die in einer Reihe bekannter Schritte verfeinert
wird, bis am Ende eine physikalische Struktur entsteht. Einen anderen Ansatz verfolgt die Me-
tapher Werkzeug, Automat, Material (WAM) in [Z¨
ullighoven98]. Fachliche Gegenst¨
ande und
Konzepte werden als Material betrachtet, das Anwendern/-innen mit Werkzeugen bearbeiten.
Wiederkehrende Aufgaben, die ohne menschliches Zutun abgearbeitet werden k¨
onnen, lassen
sich durch Automaten abarbeiten.
Auch Bertrand Meyer h¨
alt Metaphern f¨
ur ein wichtiges Instrument bei der Entwicklung und
Nutzung von Software. Besonders neue Ideen lassen sich mit ihnen ¨
uberzeugend vermitteln:
”Metaphors can be excellent teaching tools. The great scientist-expositors — the
Einsteins, Feynmans, Sagans — are peerless in conveying difficult ideas by ap-
pealing to analogies with concepts from everyday’s experience. This is the best.“
[Meyer97, S. 672]
Er warnt aber auch vor den Gefahren, die mit dem Gebrauch von Metaphern verbunden
sind. Leicht k¨
onnen Dinge verwechselt oder falsche Schl¨
usse gezogen werden. Aus diesem Grund
m¨
ussen Metaphern immer mit Bedacht gew¨
ahlt werden.
Kapitel 9
Bewertung
In diesem Teil der Arbeit wurden die wichtigsten Themen und Aspekte f¨
ur den Umgang mit
modularen E-Learning-Inhalten vorgestellt. Ausgehend von der Zielsetzung dieser Arbeit in
Abschnitt 1.2 soll nun eine Bewertung des aktuellen Stands der Wissenschaft erfolgen. Die
genaue Benennung der bestehenden L¨
ucken ergibt die Grundlage f¨
ur das Vorgehen in den
n¨
achsten Teilen dieser Arbeit.
Die Lernobjekte in Kapitel 3 sind Container f¨
ur Lerninhalte und haben durch ihre Gr¨
oße
(siehe Abschnitt 3.3) und Anordnung (siehe Abschnitt 3.4) Einfluss auf die Didaktik. Die
zahlreichen Theorien und Definitionen der Lernobjekte verdeutlichen, dass mittlerweile der
Begriff Lernobjekt im E-Learning verankert ist. Auch wenn es Differenzen bei dem einen
oder anderen Detail gibt, scheint ¨
uber die wesentlichen Funktionen Einigkeit zu herrschen. In
Hinblick auf die Zielsetzung dieser Arbeit sind Lernobjekte somit die ideale Einheit f¨
ur die
Module. Sie sind ein zentrales Thema dieser Arbeit und Ausgangspunkt f¨
ur die Bewertung
der Autorensysteme sowie Lernplattformen. Mit den Standards IMS Content Packaging (siehe
Abschnitt 3.5) und SCORM (siehe Abschnitt 3.6) stehen Kodierungen f¨
ur Lernobjekte zur
Verf¨
ugung, die weithin akzeptiert sind.
Eng verkn¨
upft mit den Lernobjekten sind die Metadaten aus Kapitel 4. Sie sind unerl¨
asslich
f¨
ur die Identifizierung von Lernmaterialien, besonders in großen Systemen. Es wurden einige
Definitionen und Standards vorgestellt, bei denen teilweise die Meinungen stark auseinander
liefen. Besonders schwierig scheint die Vereinigung von Technik und Didaktik zu sein. An der
Standardisierung f¨
uhrt dennoch kein Weg vorbei und mit LOM (siehe Abschnitt 4.3) ist ein
erster Schritt getan. Wenn diese Spezifikation nicht ausreichen sollte, gibt es noch diverse
Spezialisierungen in Form von Application Profiles.
Auf der Seite der Lernobjekte und Metadaten stehen also die n¨
otigen Mittel f¨
ur modulare
E-Learning-Inhalte bereit. Aus den Bewertungen f¨
ur Autorenwerkzeuge (siehe Abschnitt 5.2)
und Lernplattformen (siehe Abschnitt 6.3) l¨
asst sich aber ersehen, dass diese M¨
oglichkeiten
nicht genutzt werden. Keines der vorgestellten Produkte benutzt den Begriff Lernobjekt, ge-
schweige denn bietet die damit verbundene Funktionalit¨
at an. Meist lassen sich keine Module
definieren, sondern nur Kurse. Wenn dann auch noch fremde Inhalte integriert werden sollen,
ist schon aufgrund der verschiedenen Layouts und Notationen eine Inkonsistenz vorhanden.
Mit der Metadatenunterst¨
utzung sieht es zwar ein wenig besser aus — immerhin bieten einige
LOM an —, aber das vorhandene Potential der Standards wird nicht genutzt. Es reicht nicht
aus, die Metadaten anzuzeigen und gegebenenfalls bearbeiten zu lassen. Hierdurch werden sie
zum Selbstzweck degradiert. Lehrende und Lernende m¨
ussen durch Metadaten einen schnellen
Zugang zu den Materialien erlangen, die sie f¨
ur ihren Einsatz ben¨
otigen. Nur so l¨
asst sich auf
Seiten der Lehrenden die Mehrfachentwicklung bereits existierender Inhalte vermeiden. Wenn
passende Lernobjekte, fremde wie eigene, ¨
uber ein paar Stichworte in einer Datenbank gefun-
den werden, dann hat sich die M¨
uhe der Metadateneingabe gelohnt. F¨
ur Lernende erschließt
sich so das gesamte Angebot und im Selbststudium lassen sich einfacher individuelle L¨
ucken
schließen.
82 Bewertung
Von der Unterst¨
utzung der Lerntheorien aus Kapitel 2 kann bei den Autorenwerkzeugen
und Lernplattformen keine Rede sein. Lediglich der Behaviorismus wird in Form von Quiz
und Tests angeboten. Wenigstens gibt es keine technischen Hindernisse, eigene Lernmodelle
zu integrieren, aber hier muss auf geeignete Programmen noch gewartet werden.
9.1 Res¨
umee
Die Beschreibung des Standes der Wissenschaft hat deutlich gezeigt, dass die angestrebte
Zielsetzung mit den heutigen Mitteln nicht in dem gew¨
unschten Umfang realisierbar ist. Es
muss insbesondere eine bessere Verbindung zwischen den Theorien und der Technik hergestellt
werden. Mit den vorhandenen Theorien l¨
asst sich ohne Probleme ein System f¨
ur modulare E-
Learning-Inhalte modellieren, aber die Umsetzung ist kompliziert. Das liegt unter anderem an
den abstrakten Funktionsbeschreibungen. Gewiss ist es einfach, die Wiederverwendbarkeit von
Lernobjekten einzufordern, doch impliziert dies eine Reihe von H¨
urden, die bereits in Kapitel 3
¨
uber Lernobjekt angerissen wurden. So ist es nicht weiter verwunderlich, dass jedes Produkt
f¨
ur sich genommen, sei es ein Autorenwerkzeug oder eine Lernplattform, f¨
ur seine Aufgabe
einen guten Dienst erweist. Hierbei wird jedoch nur ein spezielles Problem aufgegriffen und
der Blick f¨
ur das Gesamte fehlt. Als einziger Ausweg bietet sich ein ganzheitliches Konzept an,
das von der Herstellung bis zur Pr¨
asentation von E-Learning-Inhalten alle Aspekte abdeckt.
Dieses Konzept ist der rote Faden, der sich durch diese Arbeit ziehen soll. Im folgenden wird
eine Vision des Systems skizziert, die etwas detaillierter als die Zielsetzung ist und die bereits
vorgestellte Funktionen als Anregung nimmt.
Konkret soll ein System angeboten werden, dessen Kern modulare E-Learning-Inhalte sind
und von dem Autoren/-innen, Lehrende sowie Lernende profitieren. Bei der Erstellung neu-
er Inhalte sollen Autoren/-innen alle technischen M¨
oglichkeiten an die Hand bekommen, mit
denen sie moderne Lernobjekte produzieren k¨
onnen. Hierzu geh¨
oren unter anderem eine Ein-
bettung multimedialer Komponenten oder die Darstellung eines Dokuments in verschiedenen
Layouts. Aber auch die Integration existierender Inhalte in propriet¨
aren Formate — quasi
eine Umwandlung in ein allgemeines Format — und die Kombination mit fremden Lernobjek-
ten m¨
ussen m¨
oglich sein. Im Interesse einer vielseitigen Nutzung auch mit anderen Systemen
sollen international anerkannte Standards verwendet werden. F¨
ur die Autoren/-innen d¨
urfen
sich hieraus aber keine Einschr¨
ankungen in der Gestaltung ergeben und die Kodierung sollte
transparent ablaufen. Bei der Entwicklung von Inhalten in Teams, wom¨
oglich an verschiedenen
Orten, muss es eine zentrale Datenhaltung geben, die eine synchronisierte Entwicklung erlaubt.
Unn¨
otige Mehrarbeit oder der totale Verlust von ¨
Anderungen, z.B. durch das gleichzeitige Ar-
beiten an einer Datei, wobei der/die letzte Schreibende ”gewinnt“, d¨
urfen nicht auftreten.
F¨
ur Lehrende soll das System einen Pool verschiedener E-Learning-Inhalte bereithalten, die
sie f¨
ur Pr¨
asenzveranstaltungen, Fernveranstaltungen und zum Selbststudium anbieten. Sollte
ein Thema nur unvollst¨
andig oder nicht vorhanden sein, k¨
onnen Lehrende selbst als Autoren/-
innen auftreten bzw. diese Aufgabe delegieren. Die neuen Lernobjekte werden ebenfalls in
den Pool gestellt und stehen damit allen zur Verf¨
ugung. Hier k¨
onnen sich auch die Lernenden
bedienen, und ¨
uber Suchmasken ihre Materialien finden. Die Vision sind thematisch verkn¨
upfte
Lernobjekte, die manuell oder automatisch Exkurse zu einem Thema erm¨
oglichen. Diesen
Mechanismus soll das folgende Beispiel verdeutlichen: Ein Lernobjekt beschreibt das Ohmsche
Gesetz, in dem die Beziehung zwischen Strom, Spannung und Widerstand erkl¨
art wird, die
Begriffe selbst aber nicht. Ohne vorherige direkte Verkn¨
upfung kann das System ¨
uber die
Metadaten verwandte Lernobjekte anbieten, in denen diese Begriffe erkl¨
art werden. Da der
Mechanismus auch f¨
ur die herangezogenen Lernobjekt z¨
ahlt, kann er beliebig oft wiederholt
werden. Auf diese Weise entsteht regelrecht ein Netzwerk unter den Lernobjekten, das nicht
statisch sein muss, sondern je nach Bedarf neu berechnet werden kann.
Diese Abstrakte Sicht auf die Zielsetzung muss freilich verfeinert werden. Ein Mittel zur
besseren Erschließung der wesentlichen Merkmale ist die Metapher des Baukastens, die Entwi-
cklern/-innen wie Benutzer/-innen ein intuitives Verst¨
andnis gibt.
Teil II
Entwurf
Kapitel 10
System-Vision
Die Bewertung im vorherigen Kapitel hat eindeutig gezeigt, dass die Zielsetzung dieser Arbeit
nicht mit den heute verf¨
ugbaren Mitteln zu realisieren ist. Deshalb soll nun eine verfeinerte,
eine technischere Sicht auf das angestrebte System erstellt werden. Diese System-Vision gibt
den Bauplan f¨
ur die Implementierung vor und ist eine verbindliche Vorgabe. Sie wird f¨
ur die
Entscheidung herangezogen, welche existierenden Programme, Libraries1und Standards zum
Einsatz kommen. Fehlende Komponenten werden benannt und so modelliert, dass sie einfach
implementiert werden k¨
onnen. Einige Rahmenbedingungen, die alle Projektbeteiligten von
mαth-kit als sinnvoll erachten, wurden bereits im Abschnitt 1.3 ¨
uber die Methodik erw¨
ahnt.
Wesentliche Entscheidungen f¨
ur die System-Vision sind die objektorientierte Modellierung und
der Einsatz der Programmiersprache Java.
Zuerst muss ein fachliches Modell erstellt werden, aus dem das technische abgeleitet wer-
den kann. Hierbei gilt zu beachten, dass es vollst¨
andig ist und alle gew¨
unschten Funktionen
beinhaltet. Eine ¨
Uberpr¨
ufung zwischen fachlichem Modell und der realen Welt, auch Veri-
fizierung genannt, gibt Aufschluss hier¨
uber. Danach kann das technische Modell hergestellt
werden, wobei es sich um eine Abbildung des fachlichen handelt. Die abschließende ¨
Uber-
pr¨
ufung zwischen technischem und fachlichem Modell heißt Validierung. Hieraus wird auch
ersichtlich, warum so sorgf¨
altig bei der fachlichen Modellierung gearbeitet werden muss. Fehler
und L¨
ucken, die sich an dieser Stelle eingeschlichen haben, wirken sich m¨
oglicherweise erst bei
der Implementierung oder bei der Arbeit aus. ¨
Uber die Validierung sind sie nicht zu erfas-
sen und eine Verifizierung ist zu diesem Zeitpunkt zu sp¨
at. Jede nachtr¨
agliche ¨
Anderung im
fachlichen Modell kann schwerwiegende Konsequenzen nach sich ziehen.
Steht dieses Vorgehen aber nicht im Widerspruch zu dem iterativen Prototyping, wie es
eingangs bei der Methodik festgelegt wurde? Diese Frage ist wichtig, da ihre Antwort eini-
ge Missverst¨
andnisse ausr¨
aumt. Bei der iterativen Vorgehensweise werden bewusst bestimmte
Bereiche nicht sofort modelliert, um schnellst m¨
oglich vorzeigbare Ergebnisse zu haben. Da-
mit ist aber nicht gemeint, dass in irgendeiner Form schlampig gearbeitet werden darf und
L¨
ucken im Modell erlaubt sind. Das Gegenteil ist der Fall. Es muss eine genaue Vorstellung
vom Aufgabenbereich geben, um absch¨
atzen zu k¨
onnen, welche Funktionen sich nachtr¨
ag-
lich hinzuf¨
ugen lassen. Bei dem iterativen Vorgehen werden somit bewusst Abw¨
agungen und
Priorit¨
aten gesetzt, die ein genaues Wissen ¨
uber das Zielsystem voraussetzen. Dennoch bleibt
bei der Implementierung gen¨
ugend Spielraum, um unvorhergesehene Schwierigkeiten oder ¨
An-
derungsw¨
unsche zu ber¨
ucksichtigen. Auf keinen Fall sollen hier Vorgehensmodelle wie das
Wasserfallmodell proklamiert werden.
Bei der fachlichen Modellierung stellt sich immer wieder die Frage, wie die Fakten aus
der Realit¨
at gezogen und formal festgehalten werden. Eine beliebte Vorgehensweise sind Inter-
views. Mit ihnen wird versucht, sich von den Benutzern/-innen die Prozesse erkl¨
aren zu lassen,
die vom System unterst¨
utzt werden sollen. Hieraus werden Prosatexte entwickelt, die eine um-
1In dieser Arbeit wird der Begriff Library f¨
ur Programmbibliotheken, wie z.B. von Java oder C++, verwen-
det.
86 System-Vision
gangssprachliche Beschreibung der Funktionalit¨
at bilden. Im Fall des Projekts mαth-kit wurde
bereits im Vorwege festgehalten, welche Vorstellung von dem System existiert. Als Teil des
Antrags und der Projektbeschreibung wurde quasi eine fachliche Beschreibung vorgelegt, die es
genauer zu untersuchen gilt. In mehreren Projekttreffen wurde dann weiter herausgearbeitet,
was einen multimedialen Baukasten ausmacht und welche Funktionen w¨
unschenswert sind.
Aus diesem Grund waren bei dem Projekt mαth-kit keine Interviews f¨
ur eine Beschreibung in
Prosa n¨
otig.
Das Res¨
umee (siehe Abschnitt 9.1) des Standes der Wissenschaft ist bereits eine Verfeine-
rung der Zielsetzung, angeregt durch die neuen Erkenntnisse der Untersuchung. Dennoch l¨
asst
sie einige Interpretationsfreir¨
aume zu, die durch eine formalere Beschreibung eingeschr¨
ankt
werden sollen. Hierzu werden die Fakten bestimmt, die bereits bekannt sind. Ein wichtiger
Anhaltspunkt sind die verschiedenen Personen, die mit dem System interagieren. Danach
werden Feststellungen abgeleitet, aus denen optimale L¨
osungen hervorgehen. So soll z.B. die
bestm¨
ogliche Aufteilung der gesamten Architektur gefunden werden. Ein gesundes Gleich-
gewicht zwischen existierenden L¨
osungen und Eigenentwicklungen ist freilich erstrebenswert.
Folglich muss ein Kompromiss zwischen den beiden Extremen ”alles neu entwickeln“, mit einer
optimalen Erf¨
ullung der Anspr¨
uche, und ”alles zusammensetzen“, daf¨
ur aber Abstriche in der
Funktionalit¨
at, gefunden werden.
Nach der Fertigstellung des fachlichen Modells erfolgt die ¨
Uberf¨
uhrung in das technische.
Zuerst wird eine grobe Architektur aufgestellt, die einzelne Programme und die Beziehung-
en untereinander verdeutlicht. Dann folgen die Komponenten, aus denen sich die Programme
zusammensetzen, die wiederum in Klassen zerlegt werden. Neben diesen starren Relationen
gibt es auch Algorithmen und Interaktionen, die n¨
aher modelliert werden sollen. Dies erfolgt
¨
uber Sequenz- und Ablaufdiagramme, mit denen sich dynamische Zusammenh¨
ange beschrei-
ben lassen. Letztendlich wird die Modellierung so weit getrieben werden, dass eine pr¨
azise
¨
Ubersetzung in eine objektorientierte Programmiersprache m¨
oglich ist.
Um den Begriff Komponente im Kontext der Software-Technik richtig zu verwenden, sollte
eine erg¨
anzende bzw. erkl¨
arende Erl¨
auterung angef¨
uhrt sein. Denn im Gegensatz zur Objekt-
orientierung divergieren die Meinungen der Gelehrten sowie die technischen Umsetzungen bei
diesem Begriff [Szyperski98; Griffel98]. Die folgende Definition soll weitestgehend f¨
ur diese
Arbeit gelten:
”A software component is a unit of composition with contractually specified interfa-
ces and explicit context dependencies only. A software component can be deployed
independently and is subject to composition by third parties.“ [Szyperski98, S. 164]
10.1 Rollen und Anwendungsf¨
alle
Wie erw¨
ahnt, soll das fachliche Modell ¨
uber die T¨
atigkeiten der handelnden Personen, manch-
mal auch Akteure genannt, entwickelt werden. Da manche Aktivit¨
aten nicht von Einzelnen
sondern von Mehreren ausgef¨
uhrt werden k¨
onnen, ist das Konzept Rollen eine wichtige Ab-
straktion. Es handelt sich um eine Gruppierung, bei der alle f¨
ur eine Aktion in Frage kommen-
den Personen durch die stellvertretende Rolle beschrieben werden. Dieser Ansatz bietet eine
Reihe von Vorteilen. Mit einer Rolle ist immer ein genau definierter Aufgabenbereich verbun-
den, der eine bestimmte Anzahl von T¨
atigkeiten umfasst. Somit ist eine Person nicht an eine
Rolle gebunden, sondern kann je nach durchzuf¨
uhrender T¨
atigkeit eine andere annehmen.
Die einzelnen Aktivit¨
aten werden in dieser Arbeit als Anwendungsf¨
alle beschrieben. Von
Ivar Jacobsen in den sp¨
aten 60er Jahren entwickelt, fanden sie Ende der 80er Jahre ihren Ein-
zug in die objektorientierte Analyse. Um eine falsche Annahme gleich vorweg auszur¨
aumen:
In erster Linie handelt es sich um Beschreibungen in Form von Texten und nicht um Strich-
m¨
annchen und Ellipsen, wie sie von vielen CASE-Tools angeboten werden. Die Diagramme
der UML sind kein echter Ersatz f¨
ur die schriftliche Form, weil sie keine Abl¨
aufe beschreiben
k¨
onnen. Sie haben aber trotzdem ihre Daseinsberechtigung, denn es ist f¨
ur diese Arbeit nicht
10.1 Rollen und Anwendungsf¨
alle 87
sinnvoll, in den folgenden Abschnitten alle Anwendungsf¨
alle in ihrer vollen L¨
ange aufzulisten.
F¨
ur das Verst¨
andnis dieser Arbeit ist dieses Detailwissen nicht von Belang und w¨
urde den
Rahmen sprengen. Deshalb werden die UML-Diagramme als Inhaltsverzeichnisse genutzt, die
eine ¨
Ubersicht der Beziehungen zwischen den Anwendungsf¨
allen untereinander und zu den
Rollen geben. Grunds¨
atzlich wird f¨
ur Anwendungsf¨
alle keine Form vorgeschrieben. Der Ein-
satz formloser Anwendungsf¨
alle ist genauso legitim wie eine Vorgabe durch Schablonen, in
denen definierte Felder ausgef¨
ullt werden m¨
ussen.
Im Stand der Wissenschaft werden bereits alle Personen genannt, die bei der Arbeit mit
dem System auftreten. Zur eindeutigen Identifizierung erh¨
alt jede Rolle einen Bezeichner,
der aus Pr¨
agnanz und K¨
urze in Englisch angegeben wird. Im folgenden stehen sie jeweils in
Klammern hinter der genannten Personengruppe.
Die zentralen Gruppen sind die Lehrenden (Professor) und Lernenden (Students), da
letztendlich alle Bem¨
uhungen dieser Arbeit ihr Streben unterst¨
utzen soll. Allgemeiner defi-
niert handelt es sich um Benutzer/-innen (User) der Lernplattform, ¨
uber die sie alle Aktivi-
t¨
aten durchf¨
uhren. Im Zusammenhang mit den Autorensystemen treten die Autoren/-innen
(Author) in Erscheinung, deren Aufgaben so vielf¨
altig sind, dass eine Spezialisierung dieser
Rolle, wie in [Bungenstock02; Baudry02b] vorgeschlagen, sinnvoll ist. Zwischen der Erstellung
von Lernobjekten (Developer), deren Kombinierung zu h¨
oheren Strukturen (Composer)
und der Ver¨
offentlichung auf einem Server (Publisher) soll durch drei Rollen unterschieden
werden. Die T¨
atigkeiten der Administratoren/-innen (Administrator) sind so vielf¨
altig, dass
sie sich nur schwer vollst¨
andig beschreiben lassen. Da sie neben den Verwaltungsaufgaben
die anderen Rollen bei der Arbeit unterst¨
utzen, werden sie h¨
aufiger mit unvorhersagbaren
Schwierigkeiten konfrontiert. Denn, wann immer ein technisches Problem auftritt, ist dessen
Beseitigung Aufgabe der Rolle Administrator.
Bevor nun die Anwendungsf¨
alle der einzelnen Rollen beschrieben werden, gibt Abbildung
10.1 eine ¨
Ubersicht aller definierten Rollen. Die Pfeile zwischen ihnen dr¨
ucken die Spezialisie-
rung aus.
Author
Developer PublisherComposer
Administrator
Professor
User
Student
Abbildung 10.1: ¨
Ubersicht der Rollen
10.1.1 Author
Die Rolle Author dient zur Abstraktion allgemeiner Aufgaben der Autoren/-innen und kann
in ihrer Funktion etwa mit einer abstrakten Klasse verglichen werden. Aus diesem Grund wird
in dieser Rolle kein Anwendungsfall f¨
ur die Erstellung von E-Learning-Materialien eingef¨
uhrt.
Dies geschieht erst in den drei Spezialisierungen Developer,Composer und Publisher, die alle
Anwendungsf¨
alle ”erben“ und manche auch erweitern.
Die Rolle Author beschreibt alle T¨
atigkeiten, die auf dem Weg zur Produktion anfallen.
Hierzu geh¨
ort der Umgang mit Dateien, der das Erstellen, Bearbeiten und L¨
oschen einschließt.
Weil jede spezialisierte Rolle mit den Dateiformaten vertraut ist, mit denen sie t¨
aglich zu tun
hat, ist dies ein gutes Beispiel f¨
ur die Erweiterung von Anwendungsf¨
allen. Ein potentieller
Anwendungsfall ist ”Datei bearbeiten“, der in der Rolle Author allgemein g¨
ultig beschrieben
88 System-Vision
ist. Erst in der Spezialisierung lassen sich dann die Abl¨
aufe f¨
ur ein spezielles Format, z.B.
ein Lernobjekt, genau angeben. Zu den weiteren Operationen auf Dateiebene geh¨
oren die
Versionierung und das Sperren bzw. Freigeben von Dateien. Bei der Versionierung werden die
¨
Anderungen zwischen zwei Zeitpunkten protokolliert, sodass sich alle Arbeitsschritte jederzeit
nachvollziehen oder r¨
uckg¨
angig machen lassen.
”
Versioning is the management of multiple copies of the same evolving resource,
captured at different stages of its evolution.“ [Vitali99]
Mit dem Sperren von Dateien l¨
asst sich die parallele Bearbeitung verhindern. Weil diese
Anwendungsf¨
alle f¨
ur alle Formate gleich sind, werden keine Erweiterungen in den abgeleiteten
Rollen erwartet.
Bis jetzt sind die Aufgaben der Rolle Author so allgemein gefasst, dass sie bei jeder T¨
atig-
keit mit dem Rechner auftreten k¨
onnen. Zu der Rolle geh¨
oren aber auch spezifischere Anwen-
dungsf¨
alle, wie z.B. der Umgang mit Metadaten, deren Erstellung bzw. Bearbeitung Aufgabe
aller Autoren/-innen ist. Zwar werden bei der Erstellung von Lernobjekten inhaltlich andere
Metadaten vergeben als bei der Festlegung des Layouts und Formats, aber durch den Einsatz
von Standards werden sich die Eingabemasken wenig unterscheiden. ¨
Ahnlich sieht es mit einer
Voransicht auf die geleistete Arbeit aus. So unterschiedlich die erstellten Materialien auch sein
m¨
ogen, die auszuf¨
uhrenden Schritte zur Kontrolle des Resultats sind die gleichen. Abbildung
10.2 zeigt eine ¨
Ubersicht aller Anwendungsf¨
alle in UML-Notation.
Author
Datei erstellen
Datei bearbeiten
Datei löschen
Datei versionieren
Metadaten erstellen
Metdaten bearbeiten
Metadaten löschen
Datei sperren/freigeben
Abbildung 10.2: Anwendungsf¨
alle der Rolle Author
10.1.2 Developer
Die Erstellung und Wartung von Lernobjekten ist die wesentliche Aufgabe der Rolle Developer.
Weil sie mit vielen verschiedenen Theorien und Techniken umgehen muss, sind die Anspr¨
uche
an ihre Fertigkeiten sehr hoch. Normalerweise l¨
auft die Arbeit dieser Rolle wie folgt ab: Die
Rolle Professor hat ein didaktisches Konzept entwickelt und eine grobe Vorstellung von den
ben¨
otigten Inhalten. Da ihr kein hohes technisches Wissen abverlangt werden darf, hilft die
Rolle Developer bei der Umsetzung der Gedanken, wobei an dieser Stelle ausdr¨
ucklich auf die
Trennung der Aufgaben dieser beiden Rollen eingegangen werden soll. So k¨
onnte die Erstellung
von Texten und Abbildungen gewiss der Rolle Professor zugeschrieben werden, da sie eher
fachlichen als technischen Sachverstand voraussetzt. Dennoch soll aus Gr¨
unden der Konsistenz
dieser Prozess des ”Kodierens“ der Rolle Developer zugeschrieben werden, denn auf diese Weise
wird eine Vermengung ¨
ahnlicher T¨
atigkeiten vermieden. Dies ist ohne Weiteres m¨
oglich, da
Personen nicht an Rollen gebunden sind und es sich jeweils nur um eine Sicht auf das System
handelt. Eine Dozentin kann also ihre Texte und Abbildungen selbst erstellen, ohne sich an
eine reale Technikerin wenden zu m¨
ussen.
10.1 Rollen und Anwendungsf¨
alle 89
Neben diesen einfachen Umsetzungen gibt es aber auch komplexere Aufgaben, wie z.B. die
Erstellung von Animationen und Videos oder die Programmierung von interaktiven Kompo-
nenten und Simulationen. Obwohl die professionellen Autorenwerkzeuge aus Abschnitt 5.1.1
komplexe Details verdecken, braucht es Erfahrung, um die technischen M¨
oglichkeiten zu nut-
zen. Noch anspruchsvoller ist die Entwicklung von Java Applets, bei der wirklich nur noch
Experten Ergebnisse in akzeptabler Zeit erreichen. Hier zeigt sich, wie unterschiedlich die
Anspr¨
uche an die Rolle Developer sind, denn das Spektrum reicht von Drag’n’Drop mit WY-
SIWYG bis zur Programmierung in Entwicklungsumgebungen.
Ein weiterer Anwendungsfall ist die Umwandlung existierender Inhalte in das Hauptformat
des Systems. Oft hat die Rolle Professor Skripte, ¨
Ubungsaufgaben und Vortr¨
age aus bereits
gehaltenen Veranstaltungen, die wiederverwendet werden sollen. Da es sich um umfangreichere
Dokumente handelt, k¨
onnen sie nicht 1:1 in Lernobjekte umgewandelt werden und m¨
ussen per
Hand verkleinert werden. Neben den technischen Problemen, wie einzelne Daten extrahiert
und konvertiert werden, sollten auch die Belange der Granularit¨
at und Sequenzierung aus den
Abschnitten 3.3 und 3.4 bedacht werden. Abbildung 10.3 zeigt die Rolle Developer, welche aus
der Rolle Author inklusive der genannten Anwendungsf¨
alle abgeleitet ist.
Author
Developer
Fremde Inhalte importieren
Fremde Inhalte zerlegen
Multimedia bearbeiten
Datei bearbeiten
Multimedia erstellen
Datei erstellen
Lernobjekt erstellen
Lernobjekt bearbeiten
<<extends>>
<<extends>>
<<extends>>
<<extends>>
Abbildung 10.3: Anwendungsf¨
alle der Rolle Developer
10.1.3 Composer
Die fertigen Lernobjekte werden von der Rolle Composer zu h¨
oheren Strukturen zusammen-
gesetzt, wobei keine Aufteilungen vorgegeben sind. Es kann sich z.B. um Abschnitte, Kapitel
und Kurse handeln, aber auch andere Strukturen wie ¨
Ubungen, Tests und Explorationsberei-
che sind denkbar. Im Gegensatz zu der Rolle Developer stehen die technischen Fragen eher
im Hintergrund, denn die Rolle Composer muss einen fachlichen Gesamt¨
uberblick haben —
m¨
oglicherweise von der Rolle Professor angeleitet —, um bei der Sequenzierung vorteilhafte
Lernpfade auszuarbeiten.
Richtig effizient kann die Rolle Composer nur arbeiten, wenn sie gezielt aus m¨
oglichst vielen
Inhalten die passenden herausnehmen kann. Hierf¨
ur muss das System raffinierte Suchmecha-
nismen ¨
uber die Metadaten anbieten, die allgemeine und detaillierte Anfragen anbieten. Nach
einer Suche muss die Rolle Composer das Suchergebnis analysieren und entscheiden, ob pas-
sende Inhalte enthalten sind. Stellt sich heraus, dass ein Lernobjekt nur bedingt geeignet ist,
kann die Rolle Developer entsprechende Anpassungen vornehmen. L¨
asst sich zu einem Thema
gar kein Material finden, m¨
ussen die Rollen Professor und Developer es erst entwickeln.
Bei der Zusammenstellung der Lernobjekte k¨
onnen zwei Anwendungsf¨
alle unterschieden
werden, die sich auf die Wartung und Aktualit¨
at der erzeugten Struktur auswirken. Entweder
wird eine Kopie eines Lernobjekts oder ein Verweis erzeugt. Bei der Kopie wird das Lernobjekt
90 System-Vision
vervielf¨
altigt und direkt im Kurs abgespeichert, wobei etwaige Korrekturen im Original keine
Auswirkung auf die Kopien haben. Da dies auch umgekehrt gilt, Anpassungen der Kopie nur
lokal wirken, kann dies aber ein gew¨
unschter Effekt sein, denn auf diese Weise lassen sich In-
halte nach eigenen W¨
unschen ¨
andern, ohne andere Kurse zu beeinflussen. Kann ein Lernobjekt
wie gefunden ¨
ubernommen werden, sollten lieber Verweise eingesetzt werden. Sie verbrauchen
weniger Platz, da jedes Lernobjekt nur ein Mal vorliegt, und die Inhalte sind immer auf dem
neuesten Stand. Ist der letzte Effekt nicht gew¨
unscht, kann dieser bei eingeschalteter Versio-
nierung durch einen Verweis auf eine bestimmte Version vermieden werden.
Fertige Strukturen k¨
onnen selbstverst¨
andlich wieder in ihre Bestandteile zerlegt werden,
um z.B. den Pool an Lernobjekten aufzuf¨
ullen. Dies ist besonders wichtig f¨
ur die Wiederver-
wendbarkeit fremder Materialien (siehe Abschnitt 3.1).
Auch die Rolle Composer kann wie die Rolle Developer fremde Inhalte importieren. Da
es sich aber um einen automatisierten Prozess handelt, ist das Ergebnis von der Qualit¨
at des
Ursprungsdokuments abh¨
angig. Enth¨
alt es nur unzureichende Strukturinformationen, m¨
ussen
die Lernobjekte m¨
oglicherweise von der Rolle Developer zerkleinert werden. Abbildung 10.4
fasst die beschriebenen Anwendungsf¨
alle zusammen.
Author
Composer
Datei bearbeiten
Struktur bearbeiten
Kopie einfügen Verweis einfügen
Struktur erstellen
Datei erstellen
Fremde Inhalte importieren
Fremde Inhalte zerlegen
Lernobjekt suchen
<<uses>><<uses>>
<<extends>>
<<extends>>
Abbildung 10.4: Anwendungsf¨
alle der Rolle Composer
10.1.4 Publisher
F¨
ur die ¨
asthetischen und praktischen Belange der Pr¨
asentation modularer E-Learning-Inhalte
ist die Rolle Publisher zust¨
andig. Sie k¨
ummert sich um die Integration der Materialien in die
Lernplattform, sodass die Rollen Professor und Student sie mit ihren Anzeigeprogrammen
nutzen k¨
onnen. Hierbei muss die Rolle Publisher einige Punkte beachten, denn von der Rolle
Composer erh¨
alt sie in der Regel einen Kurs, dessen Inhalte lediglich semantisch beschrieben
sind. F¨
ur die Darstellung muss zuerst ein Layout erstellt bzw. ausgew¨
ahlt werden, in dem der
Kurs erscheinen soll. Dann muss das Ausgabeformat, z.B. HTML oder PDF, auf die Anzeige-
programme und die Lernplattform abgestimmt werden, damit es zu keinen Inkompatibilit¨
aten
kommt. Im Idealfall unterst¨
utzt die Lernplattform einen der genannten Content Packaging
Standards (siehe Abschnitt 3.5 und 3.6), sodass die Rolle Publisher die Ausgabe parametri-
sieren kann, ob z.B. Submanifeste generiert werden oder welche Metadaten enthalten sind.
Nach der ¨
Ubersetzung des Kurses muss das Resultat auf die Lernplattform hochgeladen
werden. Die einzelnen Schritte dieses Anwendungsfalls h¨
angen ausschließlich von der Lern-
plattform ab und variieren von System zu System. Bei einem gemeinsam nutzbaren Speicher-
bereich, z.B. in Form eines Netzlaufwerks, ist dieser Schritt obsolet. Abbildung 10.5 zeigt
zusammenfassend die genannten Anwendungsf¨
alle.
10.1 Rollen und Anwendungsf¨
alle 91
Author
Datei bearbeiten
Datei erstellen
Publisher
Layout erstellen
Layout bearbeiten
Übersetzen
<<extends>>
<<extends>>
Ausgabeformat einstellen
In Lernplattform integrieren
Abbildung 10.5: Anwendungsf¨
alle der Rolle Publisher
10.1.5 User
Die Rolle User beschreibt die Anwendungsf¨
alle aller Personen, die Dienstleistungen und Inhal-
te einer Lernplattform nutzen. Hierbei geht es in erster Linie um die Mechanismen des Zugriffs
und weniger um die Verwendung des Angebots. Diese Details werden als Anwendungsf¨
alle in
den beiden Spezialisierungen Student und Professor beschrieben. ¨
Uber bestimmte Anzeigepro-
gramme, wie z.B. Webbrowser oder Media-Player, werden die Inhalte von der Lernplattform
heruntergeladen und angezeigt. Mit den angebotenen Kommunikations- und Organisations-
diensten k¨
onnen die Abl¨
aufe mit anderen Personen besser abgestimmt werden.
Die Rolle User dient der Kapselung administrativer Anwendungsf¨
alle und tritt nie real
in Erscheinung. Durch diesen Ansatz lassen sich die beiden Spezialisierungen Student und
Professor ¨
ubersichtlicher gestalten, da sich ihre Beschreibung auf die wesentlichen Aufgaben
beschr¨
ankt. Zu den Anwendungsf¨
allen der Rolle User geh¨
oren beispielsweise das An- bzw. Ab-
melden am System, Lesen von E-Mails und der Einsatz eines Terminkalenders. Es handelt sich
um wiederkehrende T¨
atigkeiten, die wenig mit den eigentlichen Zielen Lehren und Lernen zu
tun haben, aber dennoch modelliert werden m¨
ussen. Abbildung 10.6 listet die administrativen
Anwendungsf¨
alle der ¨
Ubersicht halber auf.
User
An−/abmelden
Inhalte nutzen
Inhalte suchen
Organisieren
Kommunizieren
Abbildung 10.6: Anwendungsf¨
alle der Rolle User
10.1.6 Student
Alle Aktivit¨
aten der Lernenden werden durch die Rolle Student beschrieben, die das Angebot
entweder im Selbststudium oder in Pr¨
asenz- bzw. Fernveranstaltungen nutzt. Ziel dieser Rolle
ist gewiss, so schnell und viel wie m¨
oglich zu lernen. Neben dem Zugriff auf Materialien und
deren Betrachtung — bereits durch die Rolle User angegeben — geh¨
ort das Absolvieren von
¨
Ubungen und Tests zu den Anwendungsf¨
allen.
Obwohl von der geplanten Infrastruktur kein direktes Lernparadigma vorgegeben wird, soll
an dieser Stelle auf die Vorgehensweise im Projekt mαth-kit eingegangen werden. Ein zentra-
92 System-Vision
ler Aspekt von mαth-kit sind die Explorationsumgebungen, die konstruktivistisch organisiert
sind. Anstatt starre Lernpfade vorzugeben, kann die Rolle Student eine individuelle Lerner-
fahrung machen. Neben der Vermittlung theoretischer Grundlagen, die jederzeit auch nach-
geschlagen werden k¨
onnen, gibt es einen multimedialen Explorationsbereich, der interaktiv
bedient wird. Zur Kontrolle des erreichten Lernerfolgs beinhaltet die Explorationsumgebung
einen ¨
Ubungsbereich, in dem Quiz, Puzzles und Multiple-Choice-Aufgaben Aufschluss ¨
uber
den Wissensstand geben.
In Chats und Foren k¨
onnen mit anderen Lernenden Arbeitsgruppen gegr¨
undet werden, die
gemeinsam Aufgaben und Probleme l¨
osen. Wenn angeboten, k¨
onnen Verst¨
andnisfragen auch
direkt an die Rolle Professor gerichtet werden, die den Lernvorgang betreut. Abbildung 10.7
stellt den Lernprozess als Verfeinerung des Anwendungsfalls ”Inhalte nutzen“ dar.
User
Student
Üben
Inhalte nutzen
Lernen
Testen
<<extends>> <<extends>>
<<extends>>
Abbildung 10.7: Anwendungsf¨
alle der Rolle Student
10.1.7 Professor
F¨
ur die fachlichen bzw. inhaltlichen Anwendungsf¨
alle ist die Rolle Professor zust¨
andig, die
Personen in der Rolle Student begleitet und den Rollen Developer,Composer sowie Publisher
bei didaktischen Fragen hilft. In anderen Worten koordiniert die Rolle Professor die gesamte
Lehre. Einen wesentlichen Teil der Arbeit machen Vorbereitungen aus, wobei neben den Inhal-
ten passende ¨
Ubungen und Tests entwickelt werden m¨
ussen. Hierbei kann die Rolle Professor
im Vorwege Ideen entwickeln, wie bestimmte Themen multimedial aufbereitet werden, um sie
gemeinsam mit der Rolle Developer zu realisieren.
Neben der Vermittlung von Wissen muss die Rolle Professor den Lernfortschritt der Ler-
nenden ¨
uberpr¨
ufen und bewerten. Auf diese Weise kann gegebenenfalls auftretenden Defiziten
entgegen gewirkt werden. Ein Instrument sind die Quiz und Tests, deren Positionierung Be-
standteil der Lernpfadgestaltung ist. Bei einer automatischen Auswertung k¨
onnen zus¨
atzlich
Statistiken angeboten werden, mit denen sich die Begutachtung, z.B. auf ganze Gruppen,
ausdehnen l¨
asst.
Weil die Rolle Professor auch die Funktionen der Lernplattform nutzt, erweitert sie die
Rolle User, sodass sie beispielsweise in der Pr¨
asenzlehre eine Vorlesung mit multimedialen
Inhalten bereichert oder Fragen in Foren beantwortet. Abbildung 10.8 zeigt eine Auflistung
der vorgestellten Anwendungsf¨
alle.
10.1.8 Administrator
Die Rolle Administrator unterst¨
utzt alle anderen Rollen bei der Arbeit, indem sie f¨
ur f¨
ur einen
einwandfreien Zustand des Systems sorgt und Ansprechpartner/-in bei technischen Schwierig-
keiten ist. Besonders bei unvorhersagbaren Problemen, wie z.B. falsch konfigurierten Program-
men oder wiederkehrenden Abst¨
urzen, ist die Rolle Administrator eine Anlaufstelle. Meist hin-
10.2 Komponenten 93
User
Professor
Lehren
Inhalte nutzen
Tests auswerten
Inhalte planen
Lehre vorbereiten
Übungen planen Tests planen
Didaktische Konzepte anwenden
<<extends>>
<<uses>><<uses>> <<uses>>
Abbildung 10.8: Anwendungsf¨
alle der Rolle Professor
ter den Kulissen werden alle Verwaltungst¨
atigkeiten von dieser Rolle durchgef¨
uhrt. F¨
ur einen
geordneten Ablauf legt sie Zug¨
ange f¨
ur Benutzer/-innen an und vergibt Zugriffsrechte, die f¨
ur
Dateien, Kurse, Foren, Chats, etc. gelten. Bei Bedarf installiert sie neue Programme und f¨
uhrt
Updates installierter Software durch. Abbildung 10.9 fasst die Anwendungsf¨
alle zusammen.
Programme installieren
Zugriffsrechte setzen
Accounts verwalten
Technische Probleme lösen
Updates durchführen
Administrator
Abbildung 10.9: Anwendungsf¨
alle der Rolle Administrator
10.2 Komponenten
Mit den Rollen und Anwendungsf¨
allen wurde ein externer Blick auf das Verhalten des Sys-
tems gegeben. F¨
ur die detaillierte Beschreibung der internen Vorg¨
ange werden in der Regel
aus den Anwendungsf¨
allen Aktivit¨
atsdiagramme hergeleitet. Dieser Diagrammtyp ist Bestand-
teil der UML mit vorgegebener Notation und ist z.B mit Flussdiagrammen vergleichbar, in
denen mit Bedingungen, Verzweigungen, Schleifen, Zust¨
anden, Synchronisationen, etc. Abl¨
au-
fe modelliert werden. Abh¨
angig vom gew¨
ahlten Abstraktionsniveau k¨
onnen sogar Algorith-
men genauestens beschrieben werden. F¨
ur den Entwurf der geplanten Systemarchitektur ist
dieses Vorgehensmodell aber ungeeignet, denn wenn m¨
oglich, sollen vorhandene Programme
und Komponenten eingesetzt werden, weshalb die Anwendungsf¨
alle mit ihrer externen Sicht
als Entscheidungskriterien hinreichend sind. Lediglich f¨
ur die Eigenentwicklungen ist dieser
Schritt sinnvoll, weil die Ergebnisse weiterverwendet werden k¨
onnen. Da aber noch nicht be-
schlossen wurde, welche Teile neu entwickelt werden, wird in dieser Arbeit ein abge¨
anderter
Weg eingeschlagen. Die Komponenten werden nicht aus den Aktivit¨
atsdiagrammen gebildet,
sondern direkt aus den Anwendungsf¨
allen.
Mit dieser Herangehensweise lassen sich offensichtlich nicht sehr kleine Komponenten bil-
den, aber sie hilft bei der Aufteilung auf Programmebene. Manche Anwendungsf¨
alle lassen
94 System-Vision
sich ¨
uber eine Komponente bearbeiten, sodass sich die Hauptkomponente f¨
ur eine Rolle in
Teilkomponenten aufteilen l¨
asst. Auch die Hauptkomponenten setzen sich aus kleineren Be-
standteilen zusammen, wodurch eine Sicht mit verschiedenen Abstraktionsniveaus entsteht.
Auf diese Weise lassen sich exakt die existierenden und fehlenden Komponenten bestimmen.
10.2.1 Basis
Es wird mit den Anwendungsf¨
allen der Rolle Author begonnen, die eine Art Basis f¨
ur die
Spezialisierungen darstellt. Dementsprechend werden die Teilkomponenten so gestaltet, dass
sie sehr allgemeine Dienste anbieten und leicht ansteuerbar sind. Bei der Rolle Author lassen
sich zwei wesentliche Bereiche ausmachen: der Umgang mit Dateien und die Verwendung von
Metadaten. Die sich ergebenden Komponenten sind in Abbildung 10.10 dargestellt.
File Management Metadata
Abbildung 10.10: Komponenten f¨
ur die Rolle Author
Mit der Komponente File Management wird der Zugriff auf das Dateisystem des Be-
triebssystems abstrahiert. Anstatt einer Reihe primitiver Systemaufrufe, mit denen sich kom-
plexere Operationen zusammensetzen lassen, werden einfache Befehle f¨
ur oft genutzte Funk-
tionen angeboten. Hierzu geh¨
oren unter anderem das Suchen von Dateien mit regul¨
aren Aus-
dr¨
ucken, das Entpacken komprimierter Dateien und das Kopieren bzw. Verschieben von Ver-
zeichnissen sowie Dateien. In Hinblick auf die Content Packages (siehe Abschnitt 3.5) und
Lernplattformen mit WebDAV (siehe WebCT in Abschnitt 6.2.2) wird zus¨
atzlich die Ab-
straktion des Zugriffs zum Wunsch. So unterschiedlich die zugrunde liegenden Techniken auch
sein m¨
ogen, die Operationen sind fast immer gleich. Zusammengefasst ist die Dienstleistung
der Komponente File Management eine transparente Behandlung unterschiedlichster Medien,
Formate und Protokolle verbunden mit umfassenden Operationen.
Prinzipiell kann jedes Datum mit Metadaten versehen werden. Die hierf¨
ur n¨
otige Funk-
tionalit¨
at stellt die Komponente Metadata bereit, durch die sich einzelne Werte bis hin zu
komplex verschachtelte Strukturen mit den ben¨
otigten Metadaten versehen lassen. Dabei m¨
us-
sen die g¨
angigen Standards und Kodierungen unterst¨
utzt werden bzw. ¨
Anderungen und neue
Versionen leicht integrierbar sein. Hierf¨
ur ist intern eine modulare Struktur n¨
otig, bei der
Module erg¨
anzt und neue hinzugef¨
ugt werden k¨
onnen. Zus¨
atzlich m¨
ussen generische Funk-
tionen angeboten werden, wie z.B. die Generierung objektiver Metadaten, eine Umrechnung
von Zeiteinheiten oder komplexe Operationen wie das Zusammenf¨
ugen von Metadaten aus
verschiedenen Quellen. Insgesamt erledigt diese Komponente alle Aufgaben rund um die Me-
tadaten, von der Eingabe ¨
uber die Speicherung bis hin zur kompletten Umwandlung in diverse
Formate der Metadatenstandards.
10.2.2 Learning Object Development
Die Anwendungsf¨
alle der Rolle Developer beschreiben drei wesentliche Aufgaben, die sich
in Teilkomponenten aufteilen lassen: die Erstellung von Multimedia und Lernobjekten sowie
die Integration fremder Inhalte. Abbildung 10.11 zeigt die zusammengesetzte Komponente
Learning Object Development.
Mit der Komponente Multimedia Environment soll eine Entwicklungsumgebung f¨
ur
multimediale Inhalte angeboten werden. Weil es f¨
ur alle Formen von Multimedia bereits Pro-
gramme gibt, soll an dieser Stelle nicht das Rad neu erfunden werden. Genauer betrachtet ist
es auch nicht leistbar, f¨
ur die vielen M¨
oglichkeiten und Anwendungen eigene Werkzeuge zu
entwickeln. Daher wird in dieser Arbeit der Einsatz bew¨
ahrter Programme f¨
ur diese Aufgabe
bevorzugt, weil sich hieraus wesentliche Vorteile ergeben: Im idealen Fall werden optimale
10.2 Komponenten 95
Import Engine
Multimedia
Environment
Learning Object
Engine
File Management
Metadata
Learning Object Development
Abbildung 10.11: Komponente f¨
ur die Rolle Developer
Ergebnisse mit geringer Einarbeitungszeit erzielt. F¨
ur die Realisierung wird ein Mechanis-
mus ben¨
otigt, mit dem sich individuelle Verbindungen zwischen den Multimedia-Dateien und
-Programmen herstellen lassen. ¨
Ahnlich wie im Explorer von Windows werden Dateiformaten
unterschiedliche Medientypen zugewiesen, die wiederum ¨
uber ein Verb eine Verkn¨
upfung zu
einem Programm besitzen. Bei dem Verb handelt es sich um Anweisungen wie z.B. ”drucke“,
”bearbeite“ und ”sende an“. Der Aufruf ist dann ein Tupel, das aus einem Dateinamen und
dem Verb besteht. Beispielsweise ¨
uberpr¨
uft die Komponente f¨
ur ein ¨
ubergebenes Wertepaar
(test.avi, edit) die Verbindung zu dem eingetragenen Werkzeug und ruft in diesem Fall
das zugewiesene Videobearbeitungsprogramm auf.
Die Komponente Import Engine liest fremde Inhalte ein und konvertiert sie zu dem in-
tern genutzten Format. Um m¨
oglichst viele Formate unterst¨
utzen zu k¨
onnen, muss die interne
Architektur sehr flexibel sein, doch leider gibt es keinen generischen Mechanismus wie XSLT,
mit dem sich ¨
Ubersetzungsregeln beschreiben lassen. Weil die Kodierungen der einzulesenden
Formate sehr verschieden sind, von L
A
T
EX-Dateien in ASCII bis hin zu propriet¨
aren MS Word-
Dateien, ist eine automatisierte Interpretation unm¨
oglich. Hieraus folgt, dass f¨
ur jedes Format
ein eigens entwickelter Reader ben¨
otigt wird. Um die Programmierung einfacher zu gestalten,
bietet die Komponente f¨
ur das Zielformat eine ¨
ubersichtliche Schnittstelle, die Inhalte in meh-
rere Elemente aufteilt, wie z.B. ¨
Uberschrift, Abbildung und Tabelle. Hierdurch beschr¨
ankt sich
die Entwicklung des Readers auf das Auslesen der Elemente mit anschließender Abbildung in
das Zielformat. Geb¨
undelt in einem Paket, werden Reader nur ein Mal implementiert und
anderen Orts installiert. Teilweise enthalten die fremden Inhalte zus¨
atzliche Metadaten, deren
Konvertierung und Aufbereitung ¨
uber die Komponenten Metadata erfolgt.
Die eigentlichen Lernobjekte werden mit der Komponente Learning Object Engine
verwaltet, die alle g¨
angigen Standards unterst¨
utzt und intern eine festgelegte Struktur von
physikalischen Dateien, Einstiegspunkten sowie Metadaten einsetzt. Dank einer Konsistenz-
pr¨
ufung mit Fehlerbehebung ist garantiert, dass nicht ungewollt defekte Lernobjekte erzeugt
werden. Der Speicher- und Lademechanismus ist modular aufgebaut und unterst¨
utzt Dateisys-
teme, Datenbanken sowie Datei-Server. Weil alle Speicher- und Ladevorg¨
ange ¨
uber die interne
Struktur ablaufen, ergibt sich ein optimales Werkzeug f¨
ur die Konvertierung verschiedener
Standards. F¨
ur den Einsatz dieser Komponente ist freilich ein grafisches Frontend (View)
sinnvoll, mit dem sich die Manipulationen per Maus steuern lassen. Eine Aufteilung nach
dem MVC-Muster [Gamma95] soll daher als ¨
ubliche Vorgehensweise angenommen werden, die
durch einen speziellen Nachrichtendienst f¨
ur Views unterst¨
utzt wird.
96 System-Vision
10.2.3 Structure Development
F¨
ur die Erstellung h¨
oherer Strukturen oder Kurse aus Lernobjekten und deren Kompositionen
steht der Rolle Composer die Komponente Structure Development zur Verf¨
ugung. Ihre
Teilkomponenten entstehen wieder aus der Zusammenfassung der Anwendungsf¨
alle, die sich
aus dem Importieren fremder Kurse, dem Suchen von Inhalten und dem eigentlichen Aufbau
der Struktur ergeben. Abbildung 10.12 illustriert die resultierende Aufteilung.
Import Engine
Search Engine
Structure Engine
File Management
Metadata
Structure Development
Abbildung 10.12: Komponente f¨
ur die Rolle Composer
Die gleiche Namensgebung der Komponente Import Engine wie in der Learning Object
Development ist nicht zuf¨
allig gew¨
ahlt. Da die Aufgaben sehr ¨
ahnlich sind, aber die Anwen-
dungsf¨
alle im Detail anders gehalten sind, ist aus konzeptioneller Sicht diese Trennung ein-
zuhalten. Bei der sp¨
ateren Implementierung kann auf sie wahrscheinlich verzichtet bzw. ¨
uber
den Zugriff durch zwei Schnittstellen nachgebildet werden. An dieser Stelle wird die Aufteilung
eines fremden Kurses in mehrere Lernobjekte plus einer Strukturierung unter dem Importieren
fremder Inhalte verstanden. Im Gegensatz hierzu k¨
onnen auf Ebene der Lernobjektentwick-
lung nur einzelne Lernobjekte eingelesen werden, weil sich die Rolle Developer sonst in den
Aufgabenbereich der Rolle Composer begibt. Anders herum kann die Rolle Developer aber
ein Lernobjekt in beliebig viele andere aufbrechen, was wiederum der Rolle Composer nicht
gestattet ist.
Mit Hilfe der Komponente Search Engines k¨
onnen Suchanfragen gestellt werden, die
entweder auf lokale Datenbest¨
ande angewendet oder an spezielle Server delegiert werden. Als
Resultat werden Listen von Referenzen auf Lernobjekte und Kurse geliefert, die sich in die
eigene Struktur integrieren lassen. Diese Komponente implementiert selbst keine Suchalgo-
rithmen, sondern benutzt Module f¨
ur die verschiedenen Anfragen. So kann ein Suchmodul
durch ein effizienteres ausgetauscht werden, ohne dass es Auswirkungen auf die Darstellung
der Suchmaske hat. Bei den Umsetzungen der Module gibt es keine Einschr¨
ankungen: Von
der einfachen Suche ¨
uber Dateien, bei der jedes Content Package f¨
ur die Metadaten ge¨
offnet
wird, bis hin zu verteilten Datenbanken, in denen ¨
uber Indizes optimale Zugriffszeiten erreicht
werden, sind alle Ans¨
atze denkbar. Zu ber¨
ucksichtigen sind nur die Vorgaben der Komponente
Metadata, damit alle Felder der Metadatenstandards abgefragt werden k¨
onnen. Da die Syntax
der Abfragesprache f¨
ur die Architektur von geringer Priorit¨
at ist, soll diese Entscheidung auf
den Klassenentwurf bzw. die Implementierung verschoben werden.
Der Aufbau der Struktur l¨
auft ¨
uber die Komponente Structure Engine, mit der standard-
kompatible Content Packages erzeugt werden. Angelehnt an die Struktur eines Manifests (siehe
Abschnitt 3.5) k¨
onnen verschiedene Organisationen f¨
ur die Lerninhalte erzeugt und bearbei-
10.2 Komponenten 97
tet werden, wodurch sich unterschiedliche Lernpfade definieren lassen, die sogar Bedingungen
und Verzweigungen erm¨
oglichen. ¨
Uber Referenzen sind die einzelnen Elemente der Struktur
mit physikalischen Ressourcen verbunden, die entweder Bestandteil des Content Package sind
oder ¨
uber eine URL auf einen externen Bereich verweisen. Bei Bedarf wandelt die Kompo-
nente solche externen Referenzen in physikalische Dateien um. Da neben Lernobjekten auch
zusammengesetzten Strukturen als Ressourcen erlaubt sind, unterst¨
utzt die Komponente die
Aggregation sowie Disaggregation der Organisationen. Weiter gedacht sind auch Operationen
zur Umstrukturierung von Submanifesten oder zur Reduzierung mehrerer Content Packages
zu einem n¨
utzliche Funktionen. Wie bei der Komponente Learning Object Environment sind
Lade- und Speichermechanismus modular gehalten und interne Ver¨
anderungen werden ¨
uber
einen eigenen Nachrichtendienst propagiert.
10.2.4 Publishing Environment
Mit der Ver¨
offentlichung der erzeugten E-Learning-Inhalte wird der letzte Schritt im Erstel-
lungsprozess vollzogen. Die Rolle Publisher nutzt bei ihrer Arbeit die Komponente Publis-
hing Environment, deren Teilkomponenten wieder aus den Anwendungsf¨
allen hergeleitet
sind. Abbildung 10.13 zeigt, wie die Gruppierung der Einzelt¨
atigkeiten zur Erstellung von
Layout- sowie Formateinstellung und ¨
Ubersetzung die interne Struktur pr¨
agt.
Compiler
File Management
Metadata
Layout Engine
Format Engine
Publishing Environment
Abbildung 10.13: Komponente f¨
ur die Rolle Publisher
Bei einem Layout handelt es sich um eine Beschreibung von Farbgestaltungen, Schriften,
Seitenaufteilungen, Abst¨
anden und Navigationen, dessen Gestaltung ¨
uber die Komponente
Layout Engine erfolgt. Es werden quasi Schablonen erstellt, die bei der ¨
Ubersetzung nur noch
mit den Inhalten der Lernobjekte ausgef¨
ullt werden. Bis auf den Punkt Navigation sollten die
beschriebenen Parameter selbsterkl¨
arend sein. Weil nicht alle Lernplattformen in der Lage sind,
aus den Manifesten eine geeignete Navigation abzuleiten, kann diese Funktion ¨
uber das Layout
gesteuert werden. Die Komponente zur ¨
Ubersetzung wird durch die erzeugte Beschreibung
angewiesen, zus¨
atzlich eine entsprechende Navigation zu erstellen. Ein anderer Punkt sind
Elemente wie Fuß- und Kopfzeilen, Logos, Verweise auf das Impressum, etc., die automatisch
in alle Seiten generiert werden. Streng genommen wird hierdurch die Trennung von Darstellung
und Inhalt verletzt, weil ”Inhalte“ zum Bestandteil der Layout-Beschreibung werden. Technisch
gesehen tritt diese Vermischung aber nicht ein, sodass sie auf fachlicher Ebene toleriert werden
darf.
Mit den Kodierungsanweisungen tr¨
agt die Komponente Format Engine die zweite Be-
schreibungsform bei, die zusammen mit dem Layout die ¨
Ubersetzung steuert. Sie wandelt ein
98 System-Vision
bekanntes Quellformat in ein beliebiges Zielformat um, auch in ein bin¨
ares oder propriet¨
a-
res. Aus dieser Funktionsbeschreibung leitet sich ab, dass eine ¨
Ubersetzung nur mit XSLT
nicht hinreichend ist. Zwar gibt es Mechanismen wie die XSL Formatting Objects (XSL-FO)
[Pawson02], deren Prozessoren aus XML PDF- und PS-Dateien generieren, aber andere wich-
tige Formate fehlen. Deshalb kann die Komponente um selbst entwickelte Module erweitert
werden, mit denen sich einzelne Aufgaben oder komplette Umsetzungen realisieren lassen.
Beispielsweise kann ein Modul MathML-Formeln2in PNG-Abbildungen umwandeln, um ¨
alte-
re Browser bei der HTML-Darstellung nicht auszuschließen. Wie bei anderen Komponenten
zuvor, erfolgt die Speicherung der XML-Formatierungen und Module in eigenen Paketen, die
mit anderen Systemen austauschbar sind.
Die eigentliche ¨
Ubersetzung f¨
uhrt die Komponente Compiler durch. Ziel ist die Erzeugung
einer oder mehrerer Dateien in einem Format, das mit einem Anzeigeprogramm dargestellt
werden kann. Hierf¨
ur wird der Inhalt aus den Lernobjekten entnommen, nach der Layout-
Vorlage arrangiert und anschließend ¨
uber die Formatbeschreibung ausgegeben. Mit einem
XSLT-Parser, einem XSL-FO-Renderer und einer Laufzeitumgebung f¨
ur Module stellt diese
Komponente die n¨
otige Infrastruktur bereit.
10.2.5 User Environment
Aus der Definition der Rolle User als Stellvertreter f¨
ur den generellen Umgang mit einer
Lernplattform folgt unausweichlich, dass ihre Hauptkomponente eine Lernplattform ist. Weil
die Anwendungsf¨
alle dieser Rolle aus der Funktionsbeschreibung von Lernplattformen in Ab-
schnitt 6.1 abgeleitet sind, k¨
onnten sie als bereits gegeben angesehen werden. Um die Konsis-
tenz zu wahren, wird wie bei den anderen Komponenten verfahren, indem die Teilkomponenten
durch Gruppierung der Anwendungsf¨
alle entstehen. Im Wesentlichen geht es bei den Aufga-
ben um die Organisation und Kommunikation mit anderen Personen und die Nutzung der
Inhalte. In Abbildung 10.14 wird neben diesen Teilkomponenten vollst¨
andigkeitshalber auch
eine Verwaltungskomponente Administration definiert, die grundlegender Bestandteil einer
Lernplattform ist.
Content Viewer
Organizer
Administration
Communicator
User Environment
Abbildung 10.14: Komponente f¨
ur die Rolle User
Bei der Komponente Communicator handelt es sich um eine Zusammenfassung aller
g¨
angigen Kommunikationsmethoden, wie z.B. E-Mail, Chat, Foren, Whiteboard und Video-
Conferencing. Obwohl diese Mittel sich grunds¨
atzlich in Bedienung und Technik unterscheiden,
ist die Verallgemeinerung in einer Komponente f¨
ur die angestrebte Architektur sinnvoll. In
der Bewertung des Standes der Wissenschaft wurde bereits angedeutet, dass die heutigen
Lernplattformen im Bereich Kommunikation gut ausgestattet sind, sodass es auf den Einsatz
einer existierenden L¨
osung hinauslaufen wird.
2MathML ist eine Auszeichnungssprache f¨
ur mathematische Formeln
10.2 Komponenten 99
¨
Ahnlich verh¨
alt es sich mit der Komponente Organizer, die alle Mittel zur Planung der
Arbeitsabl¨
aufe einschließt. Die Kalender, To-Do-Listen und Notizbl¨
atter der heutigen Lern-
plattformen sind bereits auf einem Stand, der eine Eigenentwicklung praktisch ausschließt.
Wenn die Lernplattformen bereits die gesamte Funktionalit¨
at liefern, die von der Rolle
User ben¨
otigt wird, stellt sich die Frage, wozu eine Aufteilung in Komponenten erfolgt? Eine
Antwort ist die Komponente Content Viewer, mit der die Inhalte recherchiert und angezeigt
werden. Das Ziel dieser Arbeit im Hinterkopf wird schnell die Schw¨
ache aktueller Lernplatt-
formen deutlich, denn sie sind f¨
ur die Pr¨
asentation ”monolithischer“ Inhalte ausgelegt, die
starre Strukturen vorgeben. Adaptives bzw. personalisiertes Lernen wird nicht unterst¨
utzt
und ¨
uberspitzt ausgedr¨
uckt, leisten Lernplattformen beim Suchen oder Anzeigen nicht mehr
als gew¨
ohnliche Web-Server. Die Komponente Content Viewer hingegen kennt modulare Inhal-
te, kann f¨
ur mehrere Lernpfade Navigationen erzeugen und unterst¨
utzt eine kontextabh¨
angige
Suche in nicht explizit zugewiesenen Lernobjekten. Hierdurch sind beispielsweise Exkurse zu
bestimmten Themen m¨
oglich, da die Komponente aus den Metadaten ”weiß“, welche Lernob-
jekte inhaltlich zusammen passen.
Die Komponente Administration unterst¨
utzt die Rolle User bei Einstellungen und wie-
derkehrenden T¨
atigkeiten. Funktionsumfang und Benutzung h¨
angen wieder stark vom einge-
setzten System ab, sodass keine pauschale Beschreibung m¨
oglich ist. Nur wenige grundlegende
Funktionen, wie die Bearbeitung der pers¨
onlichen Daten, z.B. das Zugangspasswort, sind ob-
ligatorisch.
Bei den Anwendungsf¨
allen dient die Rolle User zur Zusammenfassung ¨
ahnlicher T¨
atigkei-
ten der Spezialisierungen Professor und Student. Aus der Komponentenbildung f¨
ur die Rolle
Author ließe sich nun schließen, dass auch die Komponente User Environment allgemeine
Dienste anbietet, die von den Komponenten der spezialisierten Rollen aufgerufen werden. Dies
ist aber nicht der Fall, weil f¨
ur die Rollen Professor und Student keine eigenen Komponen-
ten definiert werden. Der Grund liegt in den erweiterten Anwendungsf¨
allen, die zwar eine
semantische Differenzierung bringen, technisch aber keine Auswirkung haben. Ob aus dem
Fall ”Inhalte Nutzen“ nun ”Lernen“ oder ”Lehren“ wird, ist f¨
ur das System irrelevant. Durch
diese Trennung zwischen fachlicher und technischer Bedeutung vereinfacht sich die Architek-
tur, ohne dass es zu fachlichen L¨
ucken im System kommt. Alle definierten Anwendungsf¨
alle,
auch die der Rollen Professor und Student, lassen sich ohne Einschr¨
ankungen abarbeiten.
10.2.6 Administration
Die Komponentenbildung f¨
ur die Rolle Administrator gestaltet sich schwierig, weil sie neben
den Verwaltungst¨
atigkeiten den anderen Rollen bei technischen Problemen zur Seite steht.
Dementsprechend vage sind auch die Teilkomponenten in Abbildung 10.15.
User Accounts Access Rights
Software Manager Operating System
Administration
Abbildung 10.15: Komponente f¨
ur die Rolle Administrator
100 System-Vision
Als Teil der Lernplattform verwaltet die Komponente User Accounts die Personen- und
Zugangsdaten sowie etwaige Gruppenzugeh¨
origkeiten. Die Einstellung der Zugriffsrechte f¨
ur
Ressourcen und Bereiche der Lernplattform erfolgt ¨
uber die separate Komponente Access
Rights.
In den Aufgabenbereich des Betriebssystems geht die Komponente Software Manager,¨
uber
die alle Installationen und Updates verwaltet werden. Da sich die gesamte Architektur aus ver-
schiedenen Programmen zusammenstellt, hilft eine zentrale Verwaltung, wie z.B. die Packa-
ge-Mechanismen der Linux Distributionen Debian und Red Hat, den ¨
Uberblick zu wahren.
In einer Datenbank werden alle Dateipfade, Versionen, Abh¨
angigkeiten, etc. gespeichert, um
bei ¨
Anderungen der Programmkonstellation m¨
ogliche Konflikte aufzudecken. Diese Werkzeuge
sind so weit fortgeschritten, dass von einer Eigenentwicklung abzusehen ist.
Gleiches gilt f¨
ur die Komponente Operating System, die stellvertretend f¨
ur alle ¨
Uberwach-
ungs-, Analyse- und Konfigurationswerkzeuge der Betriebssysteme steht. Wenn technische
Probleme auftreten, kann die Rolle Administrator mit diesen Programmen interne Vorg¨
ange
nachvollziehen und Konfigurationen ver¨
andern. Die M¨
oglichkeiten sind dermaßen vielf¨
altig,
dass sie sich nicht vollst¨
andig spezifizieren lassen. Auch wenn der Begriff Komponente in diesem
Fall ¨
uberstrapaziert wird, kann durch diese vereinfachte Sicht ein Bereich der Architektur
ber¨
ucksichtigt werden, der absolut unvorhersehbar ist.
10.3 Architektur
Nach der Komponentenbildung kann nun die Architektur des gesamten Systems f¨
ur die Bear-
beitung modularer E-Learning-Inhalte erstellt werden. Zuerst erfolgt eine Zusammenfassung
der verschiedenen Komponenten zu Programmen, die fachliche und technische Bez¨
uge haben,
denn nicht jede Rolle bekommt ein eigenes Programm. Durch geschickte Kombination lassen
sich manche Komponenten zu einer zusammensetzen, wodurch bei der sp¨
ateren Implementie-
rung weniger Arbeit anf¨
allt.
Die ¨
Ubersicht der Rollen in Abbildung 10.1 enth¨
alt bereits eine Aufteilung in drei Gruppen,
die folgend n¨
aher analysiert wird: Bearbeitung von E-Learning-Inhalten, verk¨
orpert durch
die Rolle Author, Nutzung von E-Learning-Inhalten, vertreten durch die Rolle User, und die
Administration des Systems. Pauschal jedem Aufgabenbereich ein Programm zur Seite zu
stellen, wird einer vern¨
unftigen Architektur leider nicht gerecht. Auf jeden Fall stehen die
Komponenten der Rolle Administrator außen vor, denn die sind entweder Bestandteil der
anderen Programme oder Werkzeuge des Betriebssystems. Die grobe Trennung in Erstellung
und Nutzung von Inhalten bleibt somit als erster Anhaltspunkt ¨
ubrig.
F¨
ur die Erstellung modularer E-Learning-Inhalte werden die Komponenten der Rollen De-
veloper,Composer und Publisher in einer Komponente vereint. Dieses Vorgehen hat mehrere
Vorteile, weil es bei der Arbeit in einer Rolle h¨
aufiger vorkommt, dass f¨
ur bestimmte T¨
atigkei-
ten ein Wechsel in eine andere Rolle n¨
otig ist. Andeutungen f¨
ur enge Kooperationen haben sich
schon bei den Rollenbeschreibungen abgezeichnet. Ein gutes Beispiel ist die Rolle Composer,
die bei einer vollst¨
andigen Produktion im Mittelpunkt steht. In ihrer Hauptt¨
atigkeit kombi-
niert sie fremde und eigene Lernobjekte bzw. Strukturen zu Kursen. Was soll aber geschehen,
wenn ein fremdes Lernobjekt nicht zu 100% passt und eine leichte Modifikation ben¨
otigt? Es
entnehmen und unter anderer Rolle in einem neuen Programm ¨
offnen? Das ist gewiss sehr
umst¨
andlich und sicher nicht erw¨
unscht. Eine bessere L¨
osung ist die direkte Bearbeitung des
Lernobjekts in der Struktur, wodurch zwar beide Rollen (Developer und Publisher) Einblick
in die Arbeit der jeweils anderen Rolle bekommen, aber konzeptionell ergibt sich hieraus kein
Problem. An dieser Stelle sei noch einmal explizit betont, dass ein und die selbe Person in
verschiedenen Rollen auftreten darf. Durch die Zusammenlegung der Komponenten werden die
¨
Uberg¨
ange unsch¨
arfer, was bei der t¨
aglichen Arbeit aber durchaus w¨
unschenswert ist, denn
ein schnelles Umschalten zwischen den Rollen erlaubt einen ungest¨
orten Arbeitsfluss. Gleiches
gilt auch f¨
ur die Rolle Publisher, die beispielsweise zu Kontrollzwecken bei der Bearbeitung
10.3 Architektur 101
von Lernobjekten oder Kursen eingenommen wird. Abbildung 10.16 zeigt die resultierende
Komponente Authoring Environment.
Structure
Development
Learning Object
Development
Publishing
Environment
Authoring Environment
Abbildung 10.16: Funktionale Komponente des Autorensystems
Aufgrund der engen Zusammenh¨
ange und Arbeitsabl¨
aufe stellt diese Komponente das
ideale Werkzeug f¨
ur die Bearbeitung modularer E-Learning-Inhalte dar. Doch bis jetzt han-
delt es sich um eine funktionale Komponente, die keine grafische Darstellung oder direkte
Ansteuerung hat. Um ein vollwertiges Autorenwerkzeug zu erhalten, wird die Komponente
Authoring Environment mit den Komponenten Graphical User Interface und Scripting
Environment verbunden. Abbildung 10.17 verdeutlicht diese Erweiterung.
Graphical
User Interface
Scripting
Environment
Authoring
Environment
Abbildung 10.17: Zwei Komponenten zur Steuerung des Autorensystems
Hauptaufgabe beider Komponenten ist die Ansteuerung der Funktionen, entweder ¨
uber
eine grafische Oberfl¨
ache oder durch Scripts. Die Komponente Graphical User Interface ist
beliebig und gibt keine konkrete Darstellung vor. Von der statischen Repr¨
asentation eines
Lernobjekts bis hin zu Modifikationen mit Drag’n’Drop in verschachtelten Strukturen ist alles
m¨
oglich. Weil aber die Akzeptanz eines Programms mit der Leistung der Oberfl¨
ache steht und
f¨
allt, sei eine benutzerfreundliche Bedienung angemahnt, die alle M¨
oglichkeiten der Kompo-
nente Authoring Environment offenbart. Es w¨
are ¨
außerst ungl¨
ucklich, wegen der einger¨
aumten
Gestaltungsm¨
oglichkeiten das Potential des Systems einzuschr¨
anken. Dennoch soll auf spezi-
fischere Angaben verzichtet werden, um nicht von vornherein bestimmte Ans¨
atze auszuneh-
men. ¨
Ahnlich verh¨
alt es sich mit den zu unterst¨
utzenden Scripts. Lediglich die M¨
oglichkeit zur
Stapelverarbeitung wird eingefordert, um einen Mechanismus f¨
ur wiederkehrende T¨
atigkeiten
anbieten zu k¨
onnen. Welche Sprache letztendlich eingesetzt wird, bleibt der Implementierung
¨
uberlassen. Interessant ist auch die Verbindung der beiden Steuerungskomponenten, durch die
sich das grafische Autorenwerkzeug mit Hilfe von Scripts beliebig erweitern l¨
asst.
Das zusammengesetzte Autorenwerkzeug ist f¨
ur sich genommen vollst¨
andig, gen¨
ugt aber
nicht der festgelegten Zielsetzung in Abschnitt 1.2 bzw. des verfeinerten Res¨
umees in Abschnitt
9.1. Da ist von zentraler Datenhaltung und der Unterst¨
utzung von Teamarbeit die Rede. Wie
lassen sich diese Anforderungen mit den bisherigen Komponenten vereinen? Warum tauchen
sie bei keiner Rolle als Anwendungsfall auf? Die Antwort ist einfach: Diese Aspekte sind f¨
ur
102 System-Vision
die Rollen unwichtig. Es ist bei der Arbeit egal, ob eine Ressource im eigenen Dateisystem
liegt, oder Bestandteil einer komplexen Datenbank ist. Synchronisation und nahtloser Zugriff
sind Aufgabe des Systems und d¨
urfen die Rollen bei ihrer Arbeit nicht belasten. F¨
ur die
Implementierung sind die Themen Teamarbeit und zentrale Datenhaltung umso wichtiger,
weil technische Details hinter einem allgemeinen Mechanismus versteckt werden m¨
ussen. Dieser
kann nur ¨
uber die Teilkomponente File Management aus Unterabschnitt 10.2.1 laufen, die auch
Funktionen wie Sperren und Versionierung anbietet. Sie ist die ohnehin geplante Schnittstelle
zur Ressourcenverwaltung und muss intern die n¨
otigen Dienste bereitstellen.
Wenn die zentrale Datenhaltung f¨
ur die Realisierung eine so hohe Bedeutung besitzt, muss
sie auch in der Architektur ber¨
ucksichtigt werden. Hierf¨
ur wird eine neue Komponente einge-
f¨
uhrt, die keinen direkten Kontakt zu den Rollen hat, aber mit dem Autorenwerkzeug kommu-
niziert. Abbildung 10.18 zeigt sie mit ihren bekannten Teilkomponenten, die alle Bestandteil
bereits vorgestellter Komponenten sind.
Learning Object
Engine
Search Engine
Structure Engine
Compiler
Learning Content Repository
Abbildung 10.18: Komponente f¨
ur die zentrale Datenhaltung (Repository)
Wie der Name Learning Content Repository andeutet, ist diese Komponente f¨
ur die
Haltung modularer E-Learning-Inhalte zust¨
andig. Da sie nur aus bekannten Teilkomponen-
ten besteht, h¨
alt sich der zus¨
atzliche Entwicklungsaufwand in Grenzen. Aus Gr¨
unden der
¨
Ubersicht ist die Komponente Authoring Environment bzw. deren Teilkomponente File Ma-
nagement in der Abbildung nicht eingezeichnet. Implizit wird diese Funktionalit¨
at ¨
uber die
Komponenten Learning Object Engine und Structure Engine angeboten, die einen transparen-
ten Zugriff erm¨
oglichen, ihn selbst aber nicht implementieren. Neben der Datenhaltung von
E-Learning-Inhalten ist auch ihr Auffinden ein zentrales Anliegen. Hierf¨
ur ist die Komponente
Search Engine zust¨
andig, die Suchanfragen entgegennimmt und entsprechend delegiert. F¨
ur
die serverseitige Kontrolle der Arbeit ist auch die Komponente Compiler integriert, um direkt
Kurse ¨
ubersetzen zu k¨
onnen, ohne den Umweg ¨
uber ein Autorensystem als Client gehen zu
m¨
ussen.
Genau wie beim Autorensystem bietet die Komponente Learning Content Repository ihre
Funktionalit¨
at an und besitzt keine direkte Ansteuerung durch die Anwender/-innen. Eine
grafische Oberfl¨
ache oder Steuerung ¨
uber Skripten ist nur bedingt sinnvoll, darf aber nicht
ausgeschlossen werden. Besonders wichtig ist die Verf¨
ugbarkeit ¨
uber ein Netzwerk und der
simultane Zugriff mehrerer Autorenwerkzeuge. Aus diesem Grund wird die Komponente Web
Server als Schnittstelle eingef¨
uhrt, die ¨
uber die vorhandene Internet-Infrastruktur angespro-
chen wird. Ob nun Dienste als Remote Procedure Calls (RPC) oder ¨
uber eine Web-Oberfl¨
ache
aufgerufen werden, ist zun¨
achst von untergeordneter Wichtigkeit, denn die verschiedenen Zu-
g¨
ange schließen sich nicht aus und k¨
onnen jederzeit um neue erweitert werden. Abbildung
10.19 verdeutlicht diese Konstellation der Komponenten.
Nun ist die Entwicklungsumgebung modularer E-Learning-Inhalte vollst¨
andig, jedoch auf
einem hohen Abstraktionsniveau. Die Verbindungen zwischen den einzelnen Programmen und
10.3 Architektur 103
Learning Content
Repository
Web Server
Abbildung 10.19: Komponente f¨
ur den Web-basierten Zugriff auf das Repository
Rollen ist noch nicht in allen Details beschrieben und l¨
asst Raum f¨
ur Interpretationen. Um
diese einzuschr¨
anken, wird in Abbildung 10.20 eine vereinfachte Ansicht auf die Architektur
gegeben, bei der die Beziehungen zwischen den Rollen, Programmen und Daten offensichtlich
ist.
Authoring Tool
Authoring Tool
Author 1
Author 2
Author n
Learning Content
Repository
Authoring Tool
Abbildung 10.20: Zugriff der Autoren/-innen auf das Repository
Stellvertretend f¨
ur alle Spezialisierungen nutzt die Rolle Author das Autorenwerkzeug. Zur
Verdeutlichung der zentrale Datenhaltung und parallelen Bearbeitung sind nPersonen einge-
zeichnet, die sich an getrennten Orten befinden. Die Pfeile in beide Richtungen stehen f¨
ur den
Datenfluss der Lernobjekte und Kurse. Existierende und neue Inhalte lassen sich transparent
auf dem Learning Content Repository bearbeiten bzw. einspielen. Solche ¨
Anderungen m¨
ussen
keine direkten Auswirkungen auf die Arbeit der anderen Personen haben. Sogar wenn das sel-
be Lernobjekt in Arbeit ist, muss es nicht zwangsl¨
aufig zu Konflikten kommen. Wann immer
m¨
oglich und n¨
otig, verdeckt die Infrastruktur die ”technische“ Pr¨
asenz anderer Entwickler/-
innen. Nur beim ausdr¨
uckliche Wunsch auf Synchronisation bzw. Absprache bei der gemein-
samen Arbeit, erlaubt das Learning Content Repository eine Aufhebung dieser Transparenz.
Um Missverst¨
andnissen entgegen zu wirken, sei darauf hingewiesen, dass es nicht um die Ver-
heimlichung der fachlichen Zusammenarbeit geht. Die Koordination l¨
auft nur nicht ¨
uber das
Autorensystem, z.B. mit Kommunikationsmitteln wie Chat oder E-Mail, sondern muss ex-
tern geleistet werden. Auf der Seite der Entwicklungsumgebung fallen nur keine zus¨
atzlichen
Absprachen an, die in der technischen Umsetzung begr¨
undet liegen.
Mit der vollst¨
andigen Entwicklungsumgebung f¨
ur modulare E-Learning-Inhalte steht die
erste S¨
aule der Architektur. Nun werden mit Hilfe der Rolle User und ihren beiden Spezia-
lisierungen die Programme f¨
ur die Nutzung der Inhalte auf gleiche Weise hergeleitet. Wie
bereits angedeutet, soll diese Aufgabe von einer Lernplattform ¨
ubernommen werden, die ¨
uber
einen g¨
angigen Webbrowser angesprochen wird. ¨
Ahnlich der Komponente Learning Content
Repository bietet User Environment lediglich ihre Funktionalit¨
at an und ben¨
otigt f¨
ur die An-
steuerung eine separate Komponente. Weil ¨
uber die internen Abl¨
aufe der eingesetzten Lern-
plattform zu diesem Zeitpunkt nichts bekannt sein kann, ist die Komponente Web Server in
Abbildung 10.21 schematischer Natur.
Im Unterabschnitt 10.2.5 ¨
uber die Komponente User Environment wurde die Schw¨
ache
der Lernplattformen im Umgang mit modularen Inhalten diskutiert. Die Leistungen auf den
104 System-Vision
User EnvironmentWeb Server
Abbildung 10.21: Komponente f¨
ur den Web-basierten Zugriff auf die Lernplattform
Gebieten Suche und Darstellung sind so unzureichend, dass eine zus¨
atzliche L¨
osung unum-
g¨
anglich ist. In allen Lernplattformen ist es m¨
oglich, auch externe Inhalte zu referenzieren
bzw. ¨
uber bestimmte Mechanismen direkt durch das System darstellen zu lassen. Auf diese
Weise soll das Learning Content Repository eingebunden werden, das die geforderten Funk-
tionen anbietet. Diese Komponente erlaubt die Kombination von Lernobjekten und h¨
oheren
Strukturen zur Laufzeit, sodass sich beim Lernen individuelle Pfade einschlagen lassen. Dank
der ¨
Ubersetzungsf¨
ahigkeit erscheinen alle Inhalte im gleichen Design und die redundante Da-
tenhaltung mehrerer Kopien des selben Lernobjekts in verschiedenen Kursen entf¨
allt. Auf
diese Weise kann selbst eine leistungsschwache Lernplattform mit geringem Aufwand in ein
modernes E-Learning-Portal verwandelt werden. Anwender/-innen in der Rolle Professor oder
Student ben¨
otigen f¨
ur ihre T¨
atigkeiten nicht den vollen Leistungsumfang des Learning Con-
tent Repositories, der bei der Entwicklung von Inhalten ben¨
otigt wird. Ihnen gen¨
ugt eine
eingeschr¨
ankte Nutzung, bei der sie lesend auf alle Inhalte zugreifen k¨
onnen.
Jetzt sind alle Programme und Komponenten benannt, die f¨
ur die Nutzung der Inhalte
notwendig sind. ¨
Uber eine vereinfachte Darstellung sollen sie in Relation gebracht werden, um
eine genauere Vorstellung ¨
uber ihren Einsatz zu geben. In Abbildung 10.22 greift die Rolle
User stellvertretend f¨
ur die Spezialisierungen mit einem Browser auf das System zu.
User 1
User 2
User n
Browser
Browser
Browser
Learning Content
Repository
Learning Management
System
Abbildung 10.22: Zugriff der Benutzer/-innen auf die Lernplattform und das Repository
Im Gegensatz zu Abbildung 10.20 geht der Datenfluss der Inhalte, erkennbar an den Pfei-
len, nur von der Lernplattform und dem Learning Content Repository zu den Browsern. In
umgekehrter Richtung werden keine Inhalte transportiert. Gleichwohl es einen bidirektionalen
Datenfluss gibt, wenn beispielsweise ¨
uber ein Chat kommuniziert wird, ist er f¨
ur das Ver-
st¨
andnis unbedeutend und wird vernachl¨
assigt. Die nPersonen nutzen gleichzeitig die ¨
ubli-
chen Dienste der Lernplattform und beziehen die modularen Inhalte vom Learning Content
Repository. Im idealen Fall bekommen die Anwender/-innen von der Teilung auf zwei Server
nichts mit.
Da in diesem Entwurf f¨
ur die Rolle Administrator keine eigenen Programme modelliert
werden, sind nun alle Rollen mit Werkzeugen versorgt. F¨
ur eine ¨
Ubersicht der gesamten Ar-
chitektur werden die Abbildungen 10.20 und 10.22 zusammengefasst. Es werden allerdings die
spezialisierten Rollen anstatt der allgemeinen angegeben, um alle Facetten der Infrastruktur
10.3 Architektur 105
zu ber¨
ucksichtigen. Zus¨
atzlich sind die Pfeile f¨
ur den Datenfluss mit den Formaten und Typen
beschrieben. Als Ergebnis ergibt sich eine Architektur, die in Abbildung 10.23 dargestellt ist.
Authoring Tool
Developer
+
Authoring Tool
Composer
Learning Management
System
Browser
Professor Student
Browser
Authoring Tool
Publisher
+
Administrator
Document
Learning Object
Learning Content
Repository
Higher Structure
Abbildung 10.23: Vollst¨
andige Architektur des Systems
Unten befinden sich alle Rollen, die mit der Entwicklung von modularen E-Learning-
Inhalten besch¨
aftigt sind. Die Rolle Developer arbeitet mit Lernobjekten, die sie auf dem
Server speichern bzw. von ihm herunterladen kann. Diese Lernobjekte kombiniert die Rolle
Composer mit anderen Inhalten zu neuen Aggregationen. Durch die Wiederverwendung von
Strukturen kann eine beliebige Aufteilung der Inhalte erfolgen, sodass es von der technischen
Seite aus keine Einschr¨
ankungen f¨
ur das didaktische Konzept gibt. Lernobjekte sowie Kurse
werden anschließend von der Rolle Publisher mit einem individuellen Layout versehen und
in ein unterst¨
utztes Zielformat ¨
ubersetzt. Das Aufspielen des Resultats auf die Lernplattform
kann auf zwei Wegen erfolgen. Entweder importiert das Autorenwerkzeug die Daten direkt
oder steuert die ¨
Ubersetzung auf demLearning Content Repository. Zwischen den beiden Ser-
ver wurde n¨
amlich eine neue Verbindung eingetragen, die in Abbildung 10.22 noch nicht vor-
handen ist. Weil die Komponente zur ¨
Ubersetzung im Autorensystem und Learning Content
Repository identisch ist, ergibt sich hieraus technisch keine Neuerung. Diese Verbindung ist
auch sehr praktisch f¨
ur die transparente Integration der Inhalte auf der Lernplattform. Ent-
weder erhalten die Rollen Professor und Student den direkten Zugang zu den Lernmaterialien
¨
uber die Lernplattform oder, wenn ein Datenaustausch zwischen den Servern nicht unterst¨
utzt
ist, werden ¨
uber Links auf das Learning Content Repository weitergeleitet. Welche technische
106 System-Vision
L¨
osung letztendlich zum Einsatz kommt, ist beiden Rollen gleich. Die Rolle Administrator ist
vollst¨
andigkeitshalber am Rand aufgef¨
uhrt.
Der gestrichelte Rahmen schließt die Systeme und Programme ein, die bei der Entwicklung
des Systems ber¨
ucksichtigt werden. Nur die Lernplattform wird als gegeben angesehen und
soll nicht ver¨
andert bzw. neu entwickelt werden. Um m¨
oglichst flexibel bei der Auswahl der
Lernplattform zu bleiben, m¨
ussen alle anderen Programme so ausgelegt sein, dass sie mit dem
eingesetzten System kooperieren k¨
onnen. Das Autorenwerkzeug muss auf jeden Fall vollst¨
an-
dig neu entwickelt werden. Modulare E-Learning-Inhalte, die den Theorien ¨
uber Lernobjekte
entsprechen, k¨
onnen mit heutigen Autorenwerkzeugen nicht erstellt werden. Hieraus folgt auch
die vollst¨
andige Neuentwicklung des Learning Content Repository, das modulare Inhalte ana-
lysieren und aufbereiten soll. Da auch neue Dienste ¨
uber die Browser aufgerufen werden, sind
sie Bestandteil des ausgezeichneten Bereichs.
10.4 Baukasten-Metapher
Der Entwurf des Systems soll mit Hilfe von Metaphern effizienter entwickelt werden und sp¨
ate-
ren Benutzern/-innen die Gew¨
ohnung erleichtern. Dies gelingt aber nur mit geeigneten Meta-
phern, deren Bedeutung allgemein bekannt ist und die einen wirklichen Bezug zu Teilaspekten
des Systems haben. Aus diesem Grund ist es wichtig, deren Sinnhaftigkeit im Vorfeld zu ¨
uber-
pr¨
ufen, denn eine falsche Auswahl kann sich nachteilig auswirken.
Als Grundlage der folgenden Er¨
orterungen dient der metaphorische Prozess aus Kapitel 8,
der die Rahmenbedingungen der Begriffsbildung vorgibt. Die Idee dieser Arbeit, Lerneinhei-
ten als einzelne Module zu betrachten, die flexibel erstellt, kombiniert, gewartet, gespeichert
und wiederverwendet werden, assoziiert ein System mit gewissen Eigenschaften, die ¨
uber die
Metapher des Baukastens verst¨
arkt werden sollen. F¨
ur eine differenziertere Betrachtung der
Details wird sie als Wortgruppe aufgefasst, die des Weiteren die Metaphern Baustein, und
Bauplan beinhaltet. Die Bildung dieser Wortgruppe bedeutet eine Verteilung von Eigenschaf-
ten des Baukastens auf mehrere Begriffe, sodass gewisse Aspekte des Systems in kleineren, in
sich abgeschlossenen Metaphern, betrachtet werden k¨
onnen. Jede von ihnen vereinfacht die
Analyse und Bewertung von Anwendungsf¨
allen, indem die wichtigen Eigenschaften der betei-
ligten Objekte und Handlungen hervorgehoben werden.
Es gibt eine Reihe weiterer Metaphern, wie z.B. ”
Werkzeug“, ”
Werkbank“ und ”Stecksys-
tem“, die sich auf den ersten Blick in die vorgeschlagene Wortgruppe einreihen k¨
onnten, jedoch
hat sich in der praktischen Arbeit gezeigt, dass die vier Substantive f¨
ur die Beschreibung des
Systems v¨
ollig ausreichend sind [Bungenstock02; Baudry02b]. Detaillierte Metaphern k¨
onnen
den Entwurf sogar erschweren, wenn sie nicht ben¨
otigte Eigenschaften implizieren.
10.4.1 Metaphorischer Prozess
Der Gegenstand dieses metaphorischen Prozesses ist das Software-System, mit dessen Hilfe
modulare E-Learning-Inhalte genutzt werden sollen. Die ¨
Ubertragung der Wortgruppe Bau-
kasten, Baustein und Bauplan vollzieht sich aus dem ¨
ublichen Kontext des Kinderspielzeugs
in den un¨
ublichen der Software. Es werden nun die einzelnen Aspekte des metaphorischen
Prozesses beschrieben:
•Die Metaphern-Produzenten/-innen f¨
ur diese Wortgruppe lassen sich in der Litera-
tur nicht genau ausmachen. Lernmaterialien als Bausteine zu betrachten ist seit Hodgins
(siehe Abschnitt 3.2.2) sehr beliebt, aber er ist gewiss nicht der Urheber dieser Metapher.
Auch wenn ihm die Idee beim Betrachten seiner spielenden Kinder kam, wird die Meta-
pher seit l¨
angerem im Kontext modularer Aufteilungen genutzt. Die anderen Metaphern
Baukasten und Bauplan leiten sich konsequenterweise vom Baustein ab, lassen sich in
der Literatur im Kontext modularer E-Learning-Inhalte aber nicht belegen. Dennoch soll
Hodgins in dieser Arbeit als Produzent betrachtet werden, weil so eine sehr interessante
10.5 Aufteilung 107
und hilfreiche Perspektive auf diese Wortgruppe entsteht. Da er nicht aus der Informatik
kommt, sind die Rezipienten/-innen auf der Anwendungsebene zu sehen.
•Die Rezipienten/-innen sind alle Personen, die mit modularen E-Learning-Inhalten
arbeiten. Aus Sicht der Rollen geh¨
oren hierzu Developer,Composer,Publisher,Professor
und Student. Sie alle profitieren mehr oder weniger von den Metaphern. W¨
urde die Rolle
Developer auch gut ohne die Metapher Baustein auskommen, passt sie im Gegenzug ideal
zu den Aufgaben der Rolle Composer. Zudem ist es ein leichtes, diese Metaphern auf
die Entwickler/-innen auszuweiten, um ihnen beim Entwurf ein Leitbild an die Hand
zu geben. Neben den bisherigen Komponenten helfen die Metaphern zus¨
atzlich bei der
Strukturierung und Umsetzung.
•Die Funktionen der Metaphern h¨
angen von der Intention der Produzenten/-innen ab.
Sehr wichtig ist die affektiv-emotionale Funktion des Begriffs ”Baukasten“: Es wirkt
vertraut und suggeriert einen kindlich einfachen Umgang. Auf diese Weise sollen Ber¨
uh-
rungs¨
angste genommen und Interesse geweckt werden. Diese Metapher l¨
adt einfach zum
”Spielen“ mit dem System ein. In die gleiche Richtung wirkt die Pr¨
adikationsfunktion.
Die gewollte Analogie zielt besonders auf die Bedienung des Systems ab, indem modulare
E-Learning-Inhalte wie Bausteine einfach zusammengesetzt werden.
•Das System selbst bzw. Teile von ihm und die E-Learning-Inhalte sind Gegenstand der
Metaphern.
•Der ¨
ubliche Kontext erstreckt sich ¨
uber verschiedene Bereiche, wobei der beherrschen-
de sicherlich Spielen bzw. Spielzeug ist.
•Den un¨
ublichen Kontext bildet in diesem Fall die Informatik.
10.5 Aufteilung
In diesem Kapitel sind so viele Komponenten entstanden, dass in dieser Arbeit nicht der Platz
ist, ihre Entwicklung in allen Details zu beschreiben. Zudem ist die Entwicklung komplexer
Anwendungen eine Aufgabe f¨
ur Teams, so auch hier. Fast alle Ergebnisse des Projekts mαth-
kit wurden von mehreren Personen entwickelt, diskutiert und ver¨
offentlicht. F¨
ur eine besse-
re Koordination wurden die Verantwortungen f¨
ur die jeweiligen Komponenten auf Einzelne
¨
ubertragen. In diesem Abschnitt werden nun die Arbeiten der Beteiligten vorgestellt, die maß-
geblich mitgewirkt haben. Die resultierenden Komponenten werden dann mit den Ergebnissen
dieser Arbeit im Teil ”Implementierung“ zu einem System zusammengesetzt.
Im Rahmen seiner Dissertation ¨
ubernimmt Andreas Baudry neben der Komponenten Im-
port Engine — es handelt sich um die Teilkomponente f¨
ur die Rollen Developer sowie Composer
aus den Abbildungen 10.11 und 10.12 — alle Komponenten f¨
ur die Rolle Publisher. Die bishe-
rigen Ergebnisse dieser Arbeit finden sich in [Baudry04b; Baudry04a; Baudry03; Baudry02a]
und entsprechen den Anforderungsbeschreibungen aus Unterabschnitt 10.2.4.
In der Diplomarbeit von Marc Vollmann [Vollmann04] werden verschiedene Suchalgorith-
men auf Basis des fallbasierten Schließens untersucht, die in die Komponente Search Engine
aus Abbildung 10.12 einflossen. Die Ansteuerung erfolgt ¨
uber das Simple Object Access Pro-
tocol (SOAP), sodass sich eine Integration in das eigene Programm problemlos vollzieht.
Mit der Diplomarbeit [Turan04] wurde die Implementierung der bereits genannten Kom-
ponenten Import Engine und der zur Authoring Foundation geh¨
orenden Teilkomponente Me-
tadata aus Abbildung 10.10 unterst¨
utzt.
Alle bis jetzt nicht aufgef¨
uhrten Komponenten, die f¨
ur die Umsetzung des Autorenwerk-
zeugs und des Learning Content Repository’s von Bedeutung sind, werden nun in den nach-
folgenden Kapiteln hergeleitet und zu einem System f¨
ur modulare E-Learning-Inhalte zusam-
mengesetzt.
108 System-Vision
Komponente Typ Kapitel Verantwortung Kontext
File Management Basis 11 MB Dissertation
Metadata Basis 11 MB Dissertation
Multimedia Environment Basis 11 MB Dissertation
Import Engine Basis - AB Dissertation
LOB Engine Basis 12 MB Dissertation
LOB Development Aggregation 13 MB Dissertation
Search Engine Basis - MV Diplomarbeit
Import Engine Basis - AB Dissertation
Structure Engine Basis 12 MB Dissertation
Structure Development Aggregation 13 MB Dissertation
Layout Engine Basis - AB Dissertation
Format Engine Basis - AB Dissertation
Compiler Basis - AB Dissertation
Publishing Environment Aggregation - AB Dissertation
Authoring Environment Aggregation 13 MB Dissertation
MB: Michael Bungenstock AB: Andreas Baudry MV: Marc Vollmann
Tabelle 10.1: Arbeitsteilung f¨
ur systemunabh¨
angige Komponenten
Komponente Typ Kapitel Verantwortung Kontext
User Environment Extern -
Administration Extern -
Graphical User Interface Basis 14 MB Dissertation
Scripting Environment Basis 14 MB Dissertation
Learning Content Repository Aggregation 15 MB Dissertation
Web-Server Basis 15 MB Dissertation
MB: Michael Bungenstock
Tabelle 10.2: Arbeitsteilung f¨
ur propriet¨
are Komponenten
Kapitel 11
Basiskomponenten
Aus den Komponenten und der Architektur des vorherigen Kapitels soll nun ein objektorien-
tiertes Modell erstellt werden. Um m¨
oglichst effizient das angestrebte Ziel zu erreichen, werden
die einzelnen Aufgaben der Komponenten genauer betrachtet und als Klassen dargestellt. Hier-
bei kann es durchaus vorkommen, dass sich ganz unterschiedliche Komponenten die gleichen
Klassen teilen. Aus diesem Grund ist es nicht sinnvoll, stur die einzelnen Komponenten in
Klassen herunterzubrechen, weil es so m¨
oglicherweise zu Mehrfachentwicklungen kommt. Zu-
sammenh¨
angende Klassen werden daher in Libraries oder nach der UML Notation in Paketen
zusammengefasst, wobei der Unterschied zu einer Komponente in der Benutzung liegt. Ist die
Komponente durch ihr Funktionsangebot eher auf der fachlichen Ebene definiert, geht es bei
der Bildung von Paketen um die physikalische Zusammenfassung korrelierender Dateien. Die-
ser modulare Ansatz vereinfacht auch die sp¨
atere Implementierung, weil jeweils eine in sich
geschlossen Klasse Gegenstand der Programmierung ist. Eine lose Kopplung zwischen Klassen
unterschiedlicher Pakete ist daher Voraussetzung f¨
ur diese Vorgehensweise.
Es sollen aber nicht die vermeintlichen Nachteile verschwiegen werden. Freilich ist es leich-
ter, die Funktionen der Klassen auf eine Komponente zu beschr¨
anken. Alle ben¨
otigten Funk-
tionen lassen sich bei sorgf¨
altiger Planung sicher benennen und es d¨
urfte selten zu b¨
osen
¨
Uberraschungen kommen. Dem steht der generischere Ansatz der allgemein g¨
ultigen Pakete
gegen¨
uber, die sich vielf¨
altiger einsetzen lassen. Hier muss von wesentlich mehr Eventualit¨
a-
ten und M¨
oglichkeiten ausgegangen werden, weil die Funktionalit¨
at in mehreren Kontexten
ben¨
otigt wird. Dies f¨
uhrt nicht nur zu unspezifischeren Operationen, sondern verlangt auch
eine stabilere Umsetzung. Innerhalb einer Komponente k¨
onne Annahmen getroffen werden,
wodurch kritische Situationen nicht entstehen oder besonders behandelt werden k¨
onnen. Als
Beispiel sei eine Verbindung zu einer Datenbank angegeben, die innerhalb einer Komponente
ben¨
otigt wird. Alle Klassen k¨
onnen ”wissen“, wann die Verbindung aufgebaut wird und fallen
entsprechend schlanker im ¨
Uberpr¨
ufungsteil aus. Bei einem generischen Paket darf von solchen
Voraussetzungen nicht ausgegangen werden und jede Operation muss so stabil implementiert
sein, dass sie ordentlich abgeschlossen wird. Hierdurch ist die Entwicklung von Paketen auf-
w¨
andiger. Die Entwicklung einer allgemeinen Schnittstelle verbunden mit den n¨
otigen ¨
Uber-
pr¨
ufungen kostet Zeit und macht den Code nicht k¨
urzer. Letztendlich f¨
uhrt dieses Vorgehen
aber zu stabileren Programmen, die dank der Wiederverwendung kleiner sind. Zudem werden
Fehler durch die intensivere Nutzung schneller entdeckt und behoben.
Mit der Komponente Authoring Foundation in Abbildung 10.10 ist bereits eine wichti-
ge Vorbereitung f¨
ur die Aufteilung in Pakete geleistet. Die Teilkomponenten sind bereits f¨
ur
bestimmte Aufgaben ausgelegt und entsprechen schon ungef¨
ahr der geplanten Aufteilung in
Klassen. Alle Zugriffe auf Dateien, von bin¨
aren Multimediadateien ¨
uber Lernobjekte bis hin
zu den ¨
ubersetzten Kursen, erfolgt ¨
uber die Komponente File Management. Durch die Ar-
chitektur bedingt, beschr¨
ankt sich der Zugriff nicht nur auf lokale Dateien, sondern schließt
auch verteilte Ressourcen ein, die auf unterschiedlichen Rechnern liegen. Auch die Betrach-
tung verschachtelter Bausteine und Modelle l¨
asst erahnen, dass eine intelligente Realisierung
110 Basiskomponenten
wichtig ist. Zusammengefasst ist die Aufgabe dieser Komponente die Abstraktion jeglicher
Ressourcenzugriffe ¨
uber einen einheitlichen Mechanismus bzw. eine Schnittstelle. Alle hierf¨
ur
n¨
otigen Klassen ergeben ein Paket.
Die Komponente Metadata ist wegen der verschiedenen Standards mit ihren vielen Elemen-
ten und Attributen in ihrer Struktur sehr umfangreich. Zus¨
atzlich m¨
ussen verschiedene Spezi-
fikationen, Kodierungen und Speichertechniken unterst¨
utzt werden, die m¨
oglichst ineinander
¨
uberf¨
uhrbar sein sollen. Die Herausforderung bei der Umsetzung dieser Komponente liegt in
der Findung eines Kompromisses zwischen generischer und einfacher Nutzung. Weil die Meta-
daten einem st¨
andigen Wandel unterlegen sind, soll durch geschickte Wahl der Schnittstellen
ein Paket geschaffen werden, das auch zuk¨
unftigen Entwicklungen gerecht wird.
11.1 Dateizugriff
Die bereitgestellten Funktionen der Komponente File Management werden eigentlich in fast
allen Programmen ben¨
otigt, die auf Dateien zugreifen. In der Regel ¨
ubernimmt diese Aufgabe
das Betriebssystem, das ¨
uber spezielle Libraries angesprochen wird. Nun stellt sich die Fra-
ge, warum f¨
ur ein E-Learning-System eine spezielle Komponente ben¨
otigt wird? Schließlich
bieten moderne Betriebssysteme viele Dienste an, die auch die Einbindung verteilter Daten
einschließt. In die Dateisysteme lassen sich ohne weiteres WebDAV, SMB und NFS einbinden.
Warum soll dieser zus¨
atzliche Aufwand geleistet werden?
Die Antwort liegt in der Heterogenit¨
at der Betriebssysteme und der angestrebten Reali-
sierung in der Programmiersprache Java. F¨
ur lediglich eine bestimmte Zielplattform w¨
are der
Einsatz nativer Mechanismen die erste Wahl. Die Implementierung k¨
onnte alle St¨
arken des
Betriebssystems nutzen und die Schw¨
achen umgehen bzw. ausgleichen. Dies beschr¨
ankt sich
nicht auf den Dateizugriff an sich. Bei manchen Systemen erstrecken sich die Funktionen bis
hin zu Verkn¨
upfungen mit Programmen durch Mime Types oder sogar in die grafische Oberfl¨
a-
che beim Drag’n’Drop. Muss auf all diese Vorz¨
uge zu Gunsten einer Plattformunabh¨
angigkeit
verzichtet werden? Dank des Aufbaus der Virtuellen Maschine (VM) von Java wird letzt-
endlich doch das Betriebssystem f¨
ur den Zugriff auf Dateien genutzt, nur ¨
uber eine einheitliche
Schnittstelle. Die Methoden der Java-Klassen rufen intern Betriebssystemfunktionen auf, wes-
halb die mitgelieferten Libraries der Virtuellen Maschinen selbst nicht plattformunabh¨
angig
sind. Sie m¨
ussen f¨
ur jedes Betriebssystem neu erstellt werden.
Java bringt also eine Schnittstelle f¨
ur den Zugriff auf Dateien von sich aus mit, sodass keine
neuen Klassen f¨
ur die Komponente File Manager entwickelt werden m¨
ussen. Dieser voreilige
Schluss wird jedoch durch eine genauere Betrachtung der aktuellen JavaTM2 Platform, Stan-
dard Edition (J2SETM) widerlegt. Alle Zugriffe auf das Dateisystem finden ¨
uber die Klasse
java.io.File statt. Laut der zugeh¨
origen Dokumentation [Sun01] repr¨
asentiert diese Klas-
se einen plattformunabh¨
angigen, abstrakten Pfadnamen, der aus zwei Komponenten besteht:
einer systemabh¨
angigen Pr¨
afixzeichenkette (z.B. ”/“ bei UNIX) und einer Sequenz von Null
oder mehr Namen. Jeder Name, bis auf den letzten, repr¨
asentiert hierbei ein Verzeichnis.
Die Umwandlung des abstrakten Pfadnamens in einen konkreten Systempfad des Datei-
systems ist abh¨
angig vom Betriebssystem, oder genauer betrachtet, vom Separationszeichen
innerhalb der Pfade. Diese Umwandlung und das systemabh¨
angige Pr¨
afix erschweren die Ent-
wicklung portabler Anwendungen, die z.B. auf Microsoft Windows und parallel auf UNIX-
Derivaten ohne Neu¨
ubersetzung laufen.
Neben dem Problem der Portierbarkeit, ist der Funktionsumfang der Klasse java.io.File
sehr spartanisch. Es k¨
onnen gewisse Attribute von Dateien und Verzeichnissen abgefragt wer-
den, wie z.B. Datum der letzten Bearbeitung, L¨
ange der Datei in Bytes und die Rechtevergabe
zum Schreiben oder Lesen. Die Manipulationsm¨
oglichkeiten beschr¨
anken sich lediglich auf das
Erstellen, L¨
oschen und Umbenennen. Eine Operation wie Kopieren oder die Unterst¨
utzung
Regul¨
arer Ausdr¨
ucke, wie sie in diversen Kommandozeilen Verwendung findet, muss bereits
selbst implementiert werden.
11.1 Dateizugriff 111
Die Definition der Komponente File Management sieht solche komfortablen Operationen
und noch speziellere vor. Besonders die gepackten sowie verschachtelten Dateien und der naht-
lose Netzwerkzugriff m¨
ussen unterst¨
utzt werden. Bei der Realisierung der Komponente m¨
ussen
somit zumindest erg¨
anzende Klassen, wenn nicht sogar ein komplett neuer Zugriff auf Dateien
eingeplant werden. Auch Sun als Urheber von Java hat bemerkt, dass die Funktionalit¨
at der
Klasse java.io.File nicht ausreicht und hat daher das WebNFSTM Client SDK entwickelt.
Mit diesem SDK wird der Zugriff auf Dateien und Verzeichnisse verschiedener Dateisyste-
me ¨
uber eine Schnittstelle realisiert. Die Referenzierung erfolgt ¨
uber URLs [Berners-Lee94]
und erm¨
oglicht so die Portierbarkeit von Programmen ohne Neu¨
ubersetzung. Kernst¨
uck die-
ses Ansatzes ist die XFile-Schicht, die durch beliebige Dateisysteme erweitert werden kann.
Abbildung 11.1 zeigt das Schichtenmodell von WebNFS.
nfs: cifs: file: native:
com.sun.xfile.*
Java Application
Abbildung 11.1: Extended Filesystem Architecture [Sun99]
Der Dateizugriff ¨
uber das Netzwerk (TCP/IP) ist das Hauptmerkmal von WebNFS. Es
wundert daher nicht, dass die Schicht com.sun.xfile.* bez¨
uglich der Attribute und Datei-
operationen nicht mehr Funktionalit¨
at als die Klasse java.io.File anbietet und damit den
Anspr¨
uchen nicht vollends gen¨
ugt.
Von anderen Herstellern bzw. Entwicklergruppen werden eine Reihe an weiteren kleinen
APIs und Erweiterungen der Standardklassen angeboten, die meist einen erweiterten Zugriff
auf betriebssystemspezifische Daten geben. Jedoch gibt es zu diesem Zeitpunkt kein Produkt,
das einen sauberen Entwurf, bei dem allzu technische Details verborgen sind, in der geforderten
Form erm¨
oglicht. Um diesem Wunsch dennoch Rechnung zu tragen, wird daher eine eigene
Dateisystem-API f¨
ur Java entwickelt.
11.1.1 Dateisystem Grundlagen
Zuerst muss eine Idee formuliert werden, wie das zu entwickelnde Dateisystem aufgebaut sein
soll. Hieraus ergibt sich automatisch die Schnittstelle nach außen, die zur Ansteuerung von an-
deren Komponenten genutzt wird. Nun soll das Rad nicht neu erfunden werden, weshalb kurz
festgehalten wird, was an Libraries und Funktionen bereits zur Verf¨
ugung steht. Als erstes ist
die mitgelieferte Klasse java.io.File zu nennen, die den Zugriff auf das lokale Dateisystem
erm¨
oglicht. Freilich soll ihre Funktion nicht nachimplementiert werden, denn die Umsetzung
dieser Klasse ist propriet¨
ar und eine Eigenentwicklung w¨
are nicht mehr plattformunabh¨
angig.
Die von Java angebotene Klasse soll das Fundament f¨
ur den Dateizugriff auf das lokale Datei-
system sein. Im Falle der verteilten Daten m¨
ussen Protokolle wie z.B. WebDAV, NFS oder
SMB implementiert werden. Dies kann und soll auch nicht geleistet werden, weil Aufwand
und Nutzen in keiner Relation stehen. Besser ist der Einsatz existierender Libraries, die we-
sentlich zuverl¨
assiger sind. Damit wird zwar die Einbindung vieler verschiedener Schnittstellen
als Nachteil in Kauf genommen, aber dieses Vorgehen sichert die h¨
ochstm¨
ogliche Flexibilit¨
at.
Um dieser Vielf¨
altigkeit zu begegnen, muss das Dateisystem eine abstrahierende Schnittstelle
anbieten, die mit Hilfe von Adaptern auf die eigentliche Funktionalit¨
at der Libraries zugreift.
So bleibt das Dateisystem auch f¨
ur zuk¨
unftige Techniken erweiterbar.
Der Begriff Dateisystem an sich ist gepr¨
agt vom Einsatz in Betriebssystemen. Insofern
sollen die Erfahrungen und Theorien aus diesem Bereich bei der Entwicklung des eigenen
Dateisystems ber¨
ucksichtigt werden. Im Grunde genommen handelt es sich bei dem Datei-
system um eine Verwaltung anderer Dateisysteme, sodass es beispielsweise dem Virtual File
System (VFS) von Linux ¨
ahnlich ist. Beim VFS geht es zwar in erster Linie um die Abstraktion
von physikalischen Medien und Ger¨
atetreibern, aber das Prinzip ist sehr ¨
ahnlich.
112 Basiskomponenten
Wegen der existierenden Libraries kann das Abstraktionsniveau sehr hoch gew¨
ahlt wer-
den, schließlich muss sich das Java-Dateisystem nicht um die physikalische Repr¨
asentation
k¨
ummern. Die Aufteilung der Festplatten und die Adressierung ¨
ubernehmen die jeweiligen
Betriebssysteme. Aufgabe des Dateisystems ist daher die einheitliche Adressierung von Res-
sourcen und die Delegation von Operationen ¨
uber Library-Grenzen hinweg.
Moderne Dateisystem ordnen ihre Dateien in Verzeichnissen an, die technisch gesehen meist
selbst Dateien sind. Sie enthalten eine bestimmte Anzahl an Eintr¨
agen, wobei jeder f¨
ur eine
Datei steht. Abbildung 11.2(a) zeigt eine Form der Speicherung, bei der Dateiname, Attribute
und die Adresse in einem Eintrag gespeichert sind.
mail
games
news
work
attributes
attributes
attributes
attributes
(a) Attribute im Verzeichni-
seintrag
Data structure
containing the
attributes
mail
games
news
work
(b) Externe Attribute
Abbildung 11.2: Aufbau von Verzeichniseintr¨
agen aus [Tanenbaum97, S. 411]
Zu den Attributen z¨
ahlen diverse Daten (Erstellungsdatum, Bearbeitungsdatum, etc.),
Zugriffsrechte, Eigent¨
umer, Dateil¨
ange und viele weitere systemspezifische Felder. Die Adres-
se h¨
angt im Falle des Java-Dateisystems vom eingebundenen Dateisystem ab, also wie das
Quellsystem das Zielsystem ansteuern muss. Handelt es sich beispielsweise um ein WebDAV-
Dateisystem, ist die Adresse, die das Java-Dateisystem speichert, eine URL.
Eine andere Form des Verzeichniseintrags ist die Referenzierung einer externen Struktur,
wie in Abbildung 11.2(b) zu sehen ist. Sie ist nur der Vollst¨
andigkeit halber aufgef¨
uhrt und
hat keinen weiteren Einfluss auf den Entwurf. Historisch gesehen lassen sich ”echte“ Dateisys-
teme auf diese Weise besser erweitern. Aufgrund des objektorientierten Ansatzes des Java-
Dateisystems ist dieses Argument aber hinf¨
allig.
Weil auch Verzeichnisse normale Dateien sind, k¨
onnen sie problemlos verschachtelt werden.
Zyklen sind aber nicht erlaubt, weshalb die resultierende Struktur ein Baum ist. Aus heutiger
Sicht mag dieser Aufbau einer Dateistruktur selbstverst¨
andlich erscheinen, aber in den An-
f¨
angen der Betriebssysteme gab es entweder ein Hauptverzeichnis oder Unterverzeichnisse in
sehr geringer Zahl.
F¨
ur den Zugriff auf die Dateien wird eine Adressierung ben¨
otigt, die jeden Knoten im Baum
eindeutig identifiziert. Jeder Baum hat genau ein Wurzelverzeichnis das alle Unterverzeichnis-
se direkt oder indirekt beinhaltet. Wenn jeder Dateiname innerhalb eines Verzeichnisses nur
ein Mal verwendet werden kann, dann l¨
asst sich diese Datei ¨
uber die Namen der h¨
oher lie-
genden Verzeichnisse eindeutig ansprechen. Diese Adressierung wird Pfad genannt und kann
in zwei Varianten notiert werden. Bei einem absoluten Pfad werden alle Namen vom Wur-
zelverzeichnis bis zum Dateinamen angegeben, getrennt durch einen Separator. Bei Windows
¨
ubernimmt das Zeichen ”\“ diese Aufgabe und bei Unix ”/“. Ein Beispiel f¨
ur einen absolu-
ten Pfad ist /usr/jim/mails. Das Wurzelverzeichnis ”/“ enth¨
alt das Unterverzeichnis usr,
das wiederum das Unterverzeichnis jim und schließlich folgt die Datei mails. Abbildung 11.3
zeigt eine passende Dateistruktur.
Die andere Schreibweise f¨
ur einen Pfad nennt sich relativer Pfad und steht in Verbin-
dung mit dem Konzept des Arbeitsverzeichnisses. Dahinter verbirgt sich die M¨
oglichkeit,
anstatt des Wurzelverzeichnisses ein beliebiges Verzeichnis anzugeben, von dem aus alle Pfade
11.1 Dateizugriff 113
bin
tmp
usr
lib
etc
libetcbin
jim
usr
ast
tmp
ast jim
/
/usr/jim
Root directory
Abbildung 11.3: Ein UNIX Verzeichnisbaum aus [Tanenbaum97, S. 414]
beginnen. Wenn z.B. das Verzeichnis /usr/jim als aktuelles Arbeitsverzeichnis ausgew¨
ahlt
ist, kann die Datei /usr/jim/mails einfach ¨
uber den Pfad mails aufgerufen werden. Relati-
ve Pfade vereinfachen somit den Zugriff auf Dateien, besonders wenn auf viele Dateien eines
Unterverzeichnisses zugegriffen wird. Es wird noch angemerkt, dass absolute Pfade in keiner
Weise vom Arbeitsverzeichnis beeinflusst werden. Bei Betriebssystemen hat jeder Prozess ein
eigenes Arbeitsverzeichnis, was f¨
ur das Java-Dateisystem nur bedingt gelten soll. Um flexibler
zu sein, soll jedes Objekt der Dateisystemklasse ein eigenes erhalten k¨
onnen. Wie viele Objekte
es geben kann, h¨
angt von der jeweiligen Implementation ab.
Es gibt noch zwei spezielle Verzeichniseintr¨
age, die eigentlich von allen hierarchischen
Dateisystemen unterst¨
utzt werden. Mit ”.“ wird auf das Verzeichnis selbst zugegriffen und
mit ”..“ auf das h¨
oher liegende, dem Elternverzeichnis. Der absolute Pfad /usr/jim/. adres-
siert also /usr/jim und /usr/jim/.. das h¨
oher liegende Verzeichnis /usr.
Nachdem sich die Dateien adressieren lassen, sollen nun einige wichtige Operationen be-
schrieben werden. Obwohl Verzeichnisse regul¨
are Dateien sind, gibt es bei den Operationen
dennoch Unterschiede. Hierzu geh¨
ort der Zugriff auf den Inhalt einer Datei, der bei einem
Verzeichnis nicht m¨
oglich ist. Von den g¨
angigen Betriebssystemen werden zwei verschiedene
Methoden f¨
ur normale Dateien unterst¨
utzt, die sich in den unterschiedlichen Medien, wie z.B.
B¨
andern und Festplatten, begr¨
unden. Beim sequentiellen Zugriff k¨
onnen die Daten der Rei-
he nach vom Anfang bis zum Ende ausgelesen oder geschrieben werden, wobei ein Zugriff in
beliebiger Reihenfolge nicht m¨
oglich ist. Die Klasse java.io.File bietet wie die erh¨
altlichen
Libraries den sequentiellen Zugriff ¨
uber Ein- und Ausgabestr¨
ome zu einer Datei an.
L¨
asst sich auf Bereiche der Datei direkt zugreifen, heißt diese Form beliebiger Zugriff.
F¨
ur viele Anwendungen, wie z.B. Datenbanken, ist dieser Zugriff sehr wichtig, denn besonders
bei vielen Daten kann nicht jedes Mal die Datei von Anfang an durchgegangen werden, wenn
am Ende ein kleines Datum ben¨
otigt wird. Leider sieht es bei der Unterst¨
utzung in Java
eher schlecht aus. Zwar gibt es die Klasse java.io.RandomAccessFile, aber besonders die
114 Basiskomponenten
zus¨
atzlichen Libraries f¨
ur den Netzwerkzugriff haben ihre Probleme. Manche Protokolle, wie
z.B. WebDAV, sehen den beliebigen Zugriff nicht einmal vor. Um unn¨
otige Komplikationen im
Vorwege zu vermeiden, soll das Java-Filesystem diese Form des Zugriffs nicht unterst¨
utzen.
Dies ist nicht weiter schlimm, da E-Learning-Inhalte in der Regel recht klein sind und sich
komplett im Speicher halten lassen.
Zu den Operationen, die f¨
ur Dateien wie Verzeichnisse g¨
ultig sind, geh¨
oren unter anderem
Erstellen, L¨
oschen und Umbenennen. Es gibt noch eine Reihe weiterer Funktionen, wie z.B.
das Auflisten aller Verzeichniseintr¨
age oder das Anh¨
angen von Daten, die entweder f¨
ur Ver-
zeichnisse oder Dateien gelten, aber auf sie soll nicht weiter eingegangen werden. Wenn solche
Funktionen von Bedeutung sind, werden sie als Methoden in die Klassen aufgenommen.
11.1.2 Virtuelles Dateisystem
In Anlehnung an das abstrahierende Dateisystem von Linux sollen die zentralen Klassen als
virtuelles Dateisystem betrachtet werden. Hierunter wird im Kontext dieser Arbeit ein Me-
chanismus verstanden, der verschiedene existierende Dateisysteme in einer neuen Dateistruk-
tur zusammenfasst. Das virtuelle Dateisystem bietet somit eine einheitliche Adressierung f¨
ur
Dateien an und die Delegation von Operationen. Aus diesem Grund werden die angesteuerten
Dateisysteme auch Zieldateisysteme genannt.
Im Gegensatz zu den Dateisystemen der Betriebssysteme, wird die Dateistruktur beim vir-
tuellen Dateisystem komplett im Speicher gehalten und nicht direkt auf dem Medium gespei-
chert. Jeder Zugriff auf Verzeichnisse und Dateien hat somit zur Folge, dass eine entsprechende
Struktur im Speicher erzeugt wird, die von der physikalischen Repr¨
asentation abstrahiert. Um
die Struktur eines virtuellen Dateisystems persistent zu machen, m¨
ussen sie an anderer, frei
w¨
ahlbarer Stelle gespeichert werden. Die Dateien selbst werden freilich in ihrem jeweiligen
Zieldateisystem gehalten.
Im Java-Dateisystem wird es daher eine Klasse geben, mit der entsprechende Strukturen
im Speicher aufgebaut werden k¨
onnen. Anhand des Beispiels in Abbildung 11.4, sollen die
Zusammenh¨
ange f¨
ur ein stellvertretendes WebDAV-Dateisystem erl¨
autert werden.
start.xml
title.xml title.xml
start.xml
WebDAV
/repository webdav://get1.upb.de/
webdav://get1.upb.de/start.xml
webdav://get1.upb.de/title.xml
Abbildung 11.4: Interne Abbildungen im VFS
Ein Server mit der Internetadresse get1.upb.de stellt das auf der rechten Seite liegende
Zieldateisystem zur Verf¨
ugung. Wie und wo die Dateistruktur gespeichert ist, soll an dieser
Stelle nicht interessieren. Wichtiger ist die interne Struktur des virtuellen Dateisystems auf
der linken Seite, die sich auf einem anderen Client-Rechner befindet. Verzeichnisknoten sind
als Quadrate dargestellt und Dateien als Kreise. Ein Pfeil in den Knoten weist auf die Adres-
sierung einer anderen Ressource hin. In dem Beispiel werden URLs genutzt, die als zus¨
atzliche
Kantenbeschriftung angegeben sind. Das oberste Verzeichnis hat keinen Namen und deutet die
Beliebigkeit der Position im Dateisystem an. Wichtiger ist das Unterverzeichnis repository,
das eine Referenz auf das WebDAV-Verzeichnis ”/“ besitzt. Die unterschiedlichen Namen sind
kein Problem, da die absoluten Pfade sowieso nicht identisch sein k¨
onnen.
11.1 Dateizugriff 115
Weil der Knoten repository auf ein Wurzelverzeichnis eines anderen Dateisystems ver-
weist, wird er als Mount-Punkt bezeichnet. Es ist quasi der Einstiegspunkt, der ”manuell“
gesetzt werden muss. Alle anderen Knoten, im Beispiel sind es start.xml und title.xml,
werden automatisch abgefragt und im virtuellen Dateisystem neu erzeugt. Nun k¨
onnen sol-
che eingeh¨
angten Dateisysteme mit tausenden von Unterverzeichnissen recht umfangreich sein
und es w¨
are ein erheblicher Aufwand, die gesamte Struktur auf ein Mal zu ¨
ubertragen. Viele
Verzeichnisse werden m¨
oglicherweise nie aufgerufen, sodass sich diese Herangehensweise nicht
lohnt. Daher soll die interne Struktur nur f¨
ur Dateien aufgebaut werden, die tats¨
achlich ben¨
o-
tigt werden. Der Struktur in Abbildung 11.4 sind ein paar Operationen voraus gegangen, wie
sie in Abbildung 11.5 dargestellt sind.
repository
mount()
(a)
WebDAV
repository
list()
(b)
start.xml
title.xml
WebDAV
repository
(c)
Abbildung 11.5: Aufbau der Dateistruktur in zwei Schritten
Der Ausgangszustand des virtuellen Dateisystems ist in Abbildung 11.5(a) dargestellt,
der aus zwei Knoten besteht, die keine externen Ressourcen referenzieren. Mit dem Befehl
mount() an den Knoten repository wird ihm die Adresse einer WebDAV-Datei zugewiesen.
Das Resultat ist in Abbildung 11.5(b) zu sehen. Zu diesem Zeitpunkt hat sich an der Struktur
des virtuellen Dateisystems nichts ge¨
andert. Dies geschieht erst durch den Aufruf des Befehls
list(), der die Namen aller Dateien des Verzeichnisses ausliest. Hierf¨
ur delegiert der Knoten
repository den Befehl an die Zieldatei und generiert aus dem Resultat alle Knoten mit ihren
Attributen, einschließlich der Adressen. Erst jetzt entspricht der Zustand in Abbildung 11.5(c)
dem vorherigen Beispiel.
Selbstverst¨
andlich lassen sich beliebig viele Zieldateisysteme verschiedenen Typs in das
virtuelle Dateisystem einh¨
angen, wie in Abbildung 11.6 dargestellt. Der ¨
Ubersicht halber sind
nicht alle Verbindungen zwischen den Knoten und Dateien eingezeichnet.
Auch verschiedene Laufwerke eines Windows Systems lassen sich problemlos hinzuf¨
ugen
und durch die direkte Einbindung in die Dateistruktur werden keine Laufwerksbuchstaben
mehr ben¨
otigt. Beim Zieldateisystem WebDAV wird zudem gezeigt, dass sich jedes beliebige
Verzeichnis mit einem Mount-Punkt verbinden l¨
asst. Lediglich die dar¨
uber liegenden Ver-
zeichnisse bzw. die Geschwister auf gleicher H¨
ohe lassen sich dann nicht ¨
uber einen Pfad im
virtuellen Dateisystem ansprechen.
Aus den geschilderten Funktionen des virtuellen Dateisystems l¨
asst sich nun die gew¨
unschte
Klasse zur Strukturierung ableiten. Da es sich bei der Dateistruktur um einen Baum handelt,
der aus vielen Knoten besteht, ergibt sich die Klasse VFSNode, in der alle Attribute gespeichert
sind. Abbildung 11.7 zeigt sie mit ihren wichtigen Methoden, die aufgrund der vorherigen
Beschreibungen in Abschnitt 11.1.1 keiner weiteren Erkl¨
arungen bed¨
urfen.
Offensichtlich bietet diese Klasse aber nur rudiment¨
are Operationen an, obwohl in den
vorherigen Ausf¨
uhrungen Funktionen wie das Kopieren oder Entpacken von Dateien eingefor-
dert wurden. Auch das beschriebene Einh¨
angen anderer Dateisystem ist anscheinend nicht auf
dieser Ebene realisiert.
Der Grund hierf¨
ur ist einfach. Solche Operationen schließen immer mehrere Knoten ein
und ben¨
otigen eine zus¨
atzliche Verwaltung. Als Beispiel sei nochmals das Einh¨
angen eines
116 Basiskomponenten
A C
A: C:
std get1 repository
/ Root directory
WebDAV
Network file system (NFS)
Standard file system (Windows)
Abbildung 11.6: Beispiel f¨
ur den Aufbau des VFS
Zieldateisystems genannt. Die Operation mount() bedeutete f¨
ur einen Knoten, alle Attribute
und Eigenschaften des neuen Zieldateisystems zu kennen. Hierdurch w¨
urden aber die Vorteile
des objektorientierten Entwurfs leichtfertig aufgegeben, da die Klasse VFSNode als universeller
Knoten auftritt. Um m¨
oglichst flexibel zu bleiben, sollte sie lieber als Schnittstelle f¨
ur spezielle
Implementationen dienen, was in Abbildung 11.7 durch den Stereotyp abstract angezeigt ist.
Ein paar erbende Klassen f¨
ur jeweils ein Zieldateisystem sind in Abbildung 11.8 zu sehen.
Die Verwaltung des Einh¨
angens und anderer komplexer Operationen wird in einer eigenen
Klasse Namens VFS implementiert. Neben einigen Vereinfachungen bietet diese Klasse auch
Dienstleistungen an, die alle Knoten eines Dateisystems betreffen. Es ist beispielsweise f¨
ur
eine grafische Darstellung eines Dateisystems notwendig, nach ¨
Anderungen den aktuellen Zu-
stand neu zu zeichnen. Um nicht st¨
andig alle Knoten ¨
uberpr¨
ufen zu m¨
ussen, bietet die Klasse
VFS einen Benachrichtigungsmechanismus an, der angemeldete Zuh¨
orer ¨
uber alle ¨
Anderun-
gen informiert. Jede Klasse kann zum Zuh¨
orer werden, indem sie eine einfache Schnittstelle
implementiert, ¨
uber die sie die Benachrichtigungen empfangen kann. Bei manchen Benach-
richtigungen k¨
onnen die Zuh¨
orer sogar Einfluss auf das Geschehen nehmen. Wenn z.B. eine
Datei gel¨
oscht werden soll, werden die Zuh¨
orer ¨
uber dieses Vorhaben benachrichtigt. Nach dem
Empfang k¨
onnen sie den/die Anwender/-in mit Hilfe eines Dialogs hier¨
uber informieren und
das Einverst¨
andnis abfragen. Sollte das L¨
oschen doch nicht gew¨
unscht sein, wird der Abbruch
dieser Operation an das Dateisystem zur¨
uckgeschickt. Die wichtigen Methoden der Klasse VFS
sind in Abbildung 11.9 dargestellt.
Auch bei dieser Klasse sind die Methoden weitestgehend selbsterkl¨
arend. Mit der Methode
zip lassen sich mehrere Dateien zu einem Archiv zusammenfassen und komprimieren. Um
wieder an die einzelnen Dateien zu kommen, lassen sich die Archive mit unzip entpacken.
Interessant ist die Klasse des Parameters, den beide als Argument akzeptieren. Bei Virtu-
alFile handelt es sich um eine Pfadbeschreibung im virtuellen Dateisystem. Da sie intern
den Zugriff auf das Dateisystem ben¨
otigt, wird sie erst anschließend n¨
aher erl¨
autert. Neben
11.1 Dateizugriff 117
canRead():Boolean
canWrite():Boolean
exists():Boolean
getInputStream():In
getOutputStream():Out
getName():String
getParent():VFSNode
isHidden():Boolean
length():int
list():VFSNode[]
mkDir():Boolean
isDir():Boolean
VFSNode
{abstract}
Abbildung 11.7: Klasse VFSNode
WebDAVFSNode NetworkFSNodeStandardFSNode
VFSNode
Abbildung 11.8: Verschiedene Unterklassen der Klasse VFSNode
einzelnen Knoten lassen sich auch Zieldateisysteme direkt in das Dateisystem einh¨
angen. Dies
ist besonders praktisch bei Dateistrukturen, wie sie von Windows angeboten werden. Auf diese
Weise m¨
ussen nicht alle Laufwerke einzeln eingeh¨
angt werden.
Wie bei den Knoten die Klasse VFSNode, ist auch die Klasse VFS abstrakt definiert und eine
Schnittstelle f¨
ur die unterschiedlichen Implementationen. Abbildung 11.10 zeigt eine m¨
ogliche
Vererbungshierarchie.
Eine Konsequenz aus diesem Ansatz ist, dass jedes Zieldateisystem gleichzeitig als virtu-
elles Dateisystem auftritt. Dies f¨
uhrt zwangsl¨
aufig zu einem Problem mit Windows, da im
vorherigen Abschnitt11.1.1 immer von einem Wurzelverzeichnis ausgegangen worden ist, ¨
uber
das alle absoluten Pfade definiert sind. Unter Windows gibt es nun historisch bedingt bis zu
26 Wurzelverzeichnisse (Laufwerk A:–Z:), sodass die Pfadbeschreibung ein wenig anders ist.
Das virtuelle Dateisystem soll aber mit nur einem Wurzelverzeichnis auskommen, weshalb das
bestehende Konzept um eine Ebene erweitert werden muss. Neben dem Wurzelverzeichnis,
das ¨
uber die Methode getRootNode erreichbar ist, werden deshalb die Volumes eingef¨
uhrt.
Dieser Name ist absichtlich aus der Windows Welt entnommen, weil es das einzige verbreitete
Betriebssystem mit dieser Aufteilung ist.
Volumes liegen direkt unter dem Wurzelverzeichnis und sind eine Art privilegiertes Ver-
zeichnis. Bei der Pfadangabe muss nicht der echte absolute Pfad angegeben werden, sondern
kann mit dem Namen eines Volumes beginnen. Mit diesem Verfahren lassen sich die Laufwer-
ke simulieren. ¨
Uber die Methode getVolumes gibt ein Dateisystem eine Liste aller Volumes
zur¨
uck. Bei einem UNIX-Dateisystem wird eine leere Zeichenkette zur¨
uckgegeben, sodass der
absolute Pfad immer mit ”/“ anf¨
angt.
Die Methode getRootNode deutet bereits an, dass der Zugriff auf die Knoten ¨
uber das
Dateisystem l¨
auft. Nun hat der interne Baum, wie er bis jetzt dargestellt wurde, einen gra-
vierenden Nachteil. ¨
Anderungen auf Seiten des Zieldateisystems werden nicht weitergereicht,
was zu Inkonsistenzen f¨
uhren kann. Wird z.B. der Inhalt eines Verzeichnisses mit list aus-
gelesen und nachfolgend direkt im Zieldateisystem eine der aufgelisteten Dateien gel¨
oscht, so
bleibt der Knoten im virtuellen Dateisystem bestehen. Erst beim Zugriff auf die Datei of-
fenbart sich dieser Zustandsunterschied. Abh¨
angig von der Implementation der Knoten kann
dieses Problem fr¨
uher oder sp¨
ater auftreten. Bei einer einfachen Umsetzung mit einer direk-
118 Basiskomponenten
addListener(Listener)
removeListener()
copy(VirtualFile, VirtualFile)
move(VirtualFile, VirtualFile)
remove(VirtualFile)
zip(VirtualFile)
unzip(VirtualFile)
mount(VirtualFile, VirtualFile)
mount(VFS, VirtualFile)
umount(VirtualFile)
getVolumes():VirtualFile[]
#getRootNode():VFSNode
#getNode(String):VFSNode
{abstract}
VFS
Abbildung 11.9: Klasse VFS
StandardFS NetworkFS
VFS
WebDAVFS
Abbildung 11.10: Verschiedene Unterklassen der Klasse VFS
ten Referenzierung der Knoten kann es sogar vorkommen, dass auch wiederholte Aufrufe von
list den alten Zustand anzeigen. Daher sollte bei jeder Operation ¨
uberpr¨
uft werden, ob die
Dateistruktur des virtuellen Dateisystems mit dem des Zielsystems ¨
ubereinstimmt. F¨
ur eine
grafische Darstellung w¨
are es sogar sinnvoll, in regelm¨
aßigen Zeitabst¨
anden diese ¨
Uberpr¨
ufung
durchzuf¨
uhren. Leider kann diese Abfrage bei komplexen Dateisystemen sehr teuer sein, zumal
ein Zugriff ¨
uber das Netzwerk zus¨
atzlich Zeit ben¨
otigt. Auf der anderen Seite ist die Pflege
eines Baums mit den verschiedenen Dateisystemoperationen sehr umst¨
andlich und kann bei
sehr großen Dateisystemen immer noch viel Platz in Anspruch nehmen.
Die L¨
osung liegt in einer ”flachen“ Organisation der Knoten. Anstatt die Dateistruktur
als Ganzes zu betrachten, kann jeder Knoten eindeutig ¨
uber einen Pfad identifiziert werden.
Um einen angemessenen Kompromiss zwischen Speicherbedarf und Laufzeit zu finden, werden
lediglich nKnoten gleichzeitig im Speicher gehalten. Abbildung 11.11 zeigt die angestrebte
Variante.
/repository/title.xml
/repository
/repository/start.xml
title.xml
start.xml
repository
n)
2)
1)
3)
4) /.../.../...
/.../.../...
...
...
...
...
Abbildung 11.11: Dateistruktur im Arbeitsspeicher
Es handelt sich quasi um eine Hash-Map mit einer internen Ordnung. Jeder der nEintr¨
age
repr¨
asentiert einen Knoten mit zugeh¨
origem Pfad. Der zuletzt genutzte Knoten ist auf Position
1, der vorherige auf 2 und der letzte auf n. Wird nun auf einen Knoten zugegriffen, der zuvor
nicht in der Liste aufgef¨
uhrt war, wird Knoten nherausgenommen und alle n−1 Knoten
11.2 Metadaten 119
um eine Position nach hinten verschoben. An Position 1 wird abschließend der neue Knoten
eingetragen. Die ganze Anordnung kann als Cache betrachtet werden, auch wenn er nicht so
leistungsf¨
ahig ist, wie ihn manche Dateisysteme anbieten. So k¨
onnte beispielsweise eine zweite
Liste angeschlossen werden, in der die H¨
aufigkeit der Zugriffe ber¨
ucksichtigt werden. Sollte die
Leistungsf¨
ahigkeit des gew¨
ahlten Ansatzes wider Erwarten nicht ausreichen, k¨
onnten solche
Funktionen immer noch nachtr¨
aglich f¨
ur eine Optimierung sorgen.
Wie angek¨
undigt, soll nun die letzte wichtige Klasse des virtuellen Dateisystems n¨
aher
vorgestellt werden. Bei dem VirtualFile handelt es sich sich um eine Aggregation von Pfad
und Referenz auf ein Dateisystem, um den Zugriff zu vereinfachen. Abbildung 11.12 zeigt das
zugeh¨
orige Klassendiagramm.
VFS
VirtualFile
String
Abbildung 11.12: Aggregation von String und VFS
Diese Klasse bietet alle Methoden der Klasse VFSNode an, weshalb kein detaillierteres
Diagramm angegeben werden muss. Intern werden die Methodenaufrufe an die Knoten mit
dem passenden Pfad weitergegeben. Die Programmierer/-innen nutzen folglich die Knoten-
Klassen nie direkt, sondern bedienen sich des vereinfachten Zugriffs. Bei einfachen Operationen
ist kein Unterschied in der Bedienung zu der Klasse java.io.File auszumachen, sodass einer
gewohnten Verwendung bzw. der Umstellung existierenden Programm-Codes nichts im Wege
steht.
Wie es nach der UML vorgesehen ist, kann nun, da die Klassen vollst¨
andig f¨
ur den Umgang
mit Dateien erschlossen sind, die erste Komponente File Management gebildet werden, wie
sie in Abbildung 10.10 zu sehen ist. Hierf¨
ur werden einfach alle vorgestellten Klassen zusam-
mengefasst und als eine Einheit ausgegeben. Der Prozess dieser Kombination ist in Abbildung
11.13 schematisch dargestellt und enth¨
alt freilich nur ein paar ausgew¨
ahlte Klassen.
File Management
VFS
VFSNode
VirtualFile
Abbildung 11.13: Bildung der Komponente File Management
Im n¨
achsten Abschnitt wird die n¨
achste Komponente f¨
ur die Rolle Author hergeleitet, um
Abbildung 10.10 zu vervollst¨
andigen.
11.2 Metadaten
Das Kapitel 4 mit seinen theoretischen Ausf¨
uhrungen und detaillierten Vorstellungen der g¨
an-
gigen Standards bildet die Basis f¨
ur die folgenden ¨
Uberlegungen. Die zugeh¨
orige Komponente
f¨
ur die Metadaten l¨
asst sich, ¨
ahnlich der Komponente File Management, vollst¨
andig in Form
einer allgemeinen Library aufziehen. Hierdurch wird die ben¨
otigte Flexibilit¨
at erreicht, die f¨
ur
eine solch zentrale Funktion unabdinglich ist.
120 Basiskomponenten
Grundlegend wird eine allgemeine Architektur f¨
ur die Erstellung, Bearbeitung und den
Austausch von Metadaten entwickelt. Eine besondere Schwierigkeit dieses Unternehmens ist
die Vielf¨
altigkeit der unterschiedlichen Standards und deren Kodierungen. Das angestrebte Ziel
kann folglich nur eine interne Repr¨
asentation sein, die allen Belangen gerecht wird. Hierf¨
ur
m¨
ussen die zu unterst¨
utzenden Standards festgelegt und ihre Gemeinsamkeiten erkannt wer-
den. Auf jeden Fall sollen die im Teil ”Stand der Wissenschaft“ vorgestellten Spezifikationen
von Dublin Core und IEEE LOM in verschieden Kodierungen unterst¨
utzt werden. Neben dem
definierten Format in XML soll auch die direkte Unterst¨
utzung von Datenbanken angeboten
werden. Hieraus ergibt sich eine Architektur, die schematisch in Abbildung 11.14 dargestellt
ist.
Dublin Core
LOM
Ariadne
XML−Reader
Dublin Core
LOM
Ariadne
XML−Writer
XML
DB
...
MD Structure
...
...
Data Flow
Uses
DB−Reader
DB−Writer
Meta Data API
Abbildung 11.14: Architektur f¨
ur heterogene Metadatenformate
Aus den verschiedenen Datenquellen, XML-Datei und Datenbank, werden die Metadaten
¨
uber die Reader eingelesen und unter Zuhilfenahme der unten stehenden API zu einer hier-
archischen Struktur zusammengesetzt. Eine der Gemeinsamkeiten ist n¨
amlich der Aufbau als
Baum, auf den sich alle wichtigen Metadatenspezifikationen abbilden lassen. ¨
Uber die Writer
kann die Metadatenstruktur wieder in die Formate der Datenquellen umgewandelt werden.
Neben dem Aufbau der Metadatenrepr¨
asentation im Speicher, erm¨
oglicht die Metadaten-API
auch die Manipulation der Struktur.
Die gesamte Flexibilit¨
at dieses Entwurfs begr¨
undet sich in den unterschiedlichen Reader-
und Writer-Modulen, deren Aufbau n¨
aher betrachtet werden soll. Da es f¨
ur Datenbanken
keine verbindlichen Anordnungen bzw. Datenbankschemata gibt, kann der Zugriff sehr indivi-
duell gestaltet werden. Eine denkbare L¨
osung ist eine Klasse, die aus einer festgelegten Quelle
die n¨
otigen SQL-Skripte auslesen kann. Hierdurch wird zwar Programmlogik außerhalb der
Applikation angesiedelt, was im Normalfall zu vermeiden ist, aber die gewonnene Flexibilit¨
at
rechtfertigt m¨
oglicherweise diese Vorgehensweise. Alternativ kann auch eine Klasse mit der
vollst¨
andigen Datenbankansteuerung erstellt werden und in frei definierbaren Unterklassen er-
folgt die Zuordnung zu den Tabellen. Welcher Ansatz letztendlich gew¨
ahlt wird, soll erst in
der Implementierungsphase entschieden werden.
Anders sieht es bei der Kodierung in XML aus. Weil alle relevanten Spezifikationen ein
XML-Binding beinhalten, muss dieser Umstand bereits beim Entwurf ber¨
ucksichtigt werden.
In Abbildung 11.14 sind die Standards eingetragen, die von der angestrebten Implementierung
11.2 Metadaten 121
unterst¨
utzt werden sollen. Zu den gestellten Anforderungen l¨
asst sich elegant eine passende
Klassenstruktur bilden, deren Diagramme f¨
ur Reader und Writer in Abbildung 11.15 darge-
stellt sind.
LOMReader
AriadneReader
DCReader
XMLReader DBReader
MDReader
(a) Metadaten-Reader
LOMWriter DCWriter
XMLWriter DBWriter
MDWriter
AriadneWriter
(b) Metadaten-Writer
Abbildung 11.15: Klassenhierarchien der Reader und Writer
Der Zugriff auf alle Metadaten-Reader sowie -Writer erfolgt ¨
uber die Klassen MDReader
und MDWriter, die eine einheitliche Schnittstelle nach außen darstellen. Implementierungen
spezieller Methoden sind auf dieser Ebene nicht zu erwarten, sodass es sich im Sinne von Java
um echte Interfaces handelt und nicht um abstrakte Klassen. Auf der n¨
achsten Ebene, den
Klassen XMLReader und DBReader bzw. XMLWriter und DBWriter verh¨
alt es sich anders. Hier
werden grundlegende Funktionen angeboten — meist technische Details verdeckend —, die
in den Unterklassen genutzt werden. In den jeweiligen Klassen f¨
ur LOM und Dublin Core
auf der darunter liegenden Vererbungsebene steckt die Logik, die f¨
ur den Zusammenbau der
allgemein g¨
ultigen Metadatenstruktur bzw. die Abbildung in das entsprechende Zielformat
ben¨
otigt wird. Am Beispiel von Ariadne wird gezeigt, wie der Entwurf durch Application
Profiles erweiterbar ist. Durch Vererbung k¨
onnen existierende Reader und Writer um neue
Metadateneintr¨
age erweitert werden.
11.2.1 Datenstruktur
Im vorigen Abschnitt wurde bereits erw¨
ahnt, dass die interne Struktur hierarchisch als Baum
aufgebaut ist. Diese Anordnung ist pr¨
adestiniert, weil sich alle g¨
angigen Standards ohne Auf-
wand in diese Form bringen lassen. Sei es nun Dublin Core mit seinen 15 Elementen, die
gleichberechtigt auf der obersten Ebene liegen, oder LOM mit der semantischen Aufteilung
in 9 Kategorien und weiteren Unterkategorien. Letztendlich bietet ein allgemeiner Baum mit
beliebiger Tiefe die Freir¨
aume, um heutigen und k¨
unftigen Entwicklungen gerecht zu werden.
Mit der Bildung von Kategorien f¨
ur alle Knoten im Baum bietet LOM einen ¨
außerst
flexiblen Mechanismus zur Strukturierung. Er wird daher in die allgemeine Datenstruktur
mit aufgenommen, denn so lassen sich eigene Application Profiles durch Hinzuf¨
ugen neuer
Kategorien oder Metadatenfelder einfach entwickeln.
In der Entwurfsphase k¨
onnen bereits grob ein paar Kategorien benannt werden, die eine
hohe Relevanz f¨
ur den t¨
aglichen Einsatz haben. So sollte eine Kategorie f¨
ur die didaktischen
Eigenschaften enthalten sein, die Kontext, Zielgruppe, Benutzung, Schwierigkeitsgrad und
andere subjektive Angaben umfasst. In LOM gibt es entsprechend die Kategorie Educational
(siehe Abbildung 4.6(a)) und bei Ariadne P¨
adagogik. Bei Dublin Core m¨
ussen diese Angaben
gezielt auf einzelne Elemente abgebildet werden, z.B. bietet sich Subject f¨
ur die Klassifizierung
und Type f¨
ur die Form an. Letzteres gibt an, ob das Lernobjekt z.B. ein Text, ein Bild oder
interaktiv ist.
122 Basiskomponenten
Zu den relevanten objektiven Metadaten geh¨
oren Attribute wie beispielsweise ”Titel“, ”Au-
tor“, ”Typ“ und ”Format“. LOM und Ariadne bieten hier eine große Auswahl vordefinierter
Felder, die als obligatorisch oder optional festgelegt werden k¨
onnen. Im Interesse der einfachen
Nutzbarkeit sollten Metadaten, wann immer m¨
oglich, als optional definiert sein. Lediglich ein
Mindestsatz f¨
ur Daten, die oft ben¨
otigt werden, wie z.B. bei Suchanfragen, muss obligatorisch
sein. In der Regel sind Autoren/-innen gering motiviert, viele Metadaten einzugeben, sodass
die Akzeptanz stark vom Komfort abh¨
angt. M¨
ussen bei der Erstellung von Lernobjekten erst
zig Metadaten eingegeben werden, bevor die Speicherung durchgef¨
uhrt wird, ist schnell die
Toleranzschwelle ¨
uberschritten. Da es sich aber um objektive Metadaten handelt, sollte das
System in der Lage sein, wenigstens Vorschl¨
age, wenn nicht sogar die richtigen Daten, einzu-
tragen.
Eine besondere Bedeutung besitzen die technischen Rahmenbedingungen, die eigentlich
auch zu den objektiven Metadaten geh¨
oren, aber wegen ihres Umfangs eine eigene Kategorie
zugeteilt bekommen. Diese Kategorie gibt in erster Linie die Bedingungen vor, die f¨
ur eine
optimale Pr¨
asentation erf¨
ullt sein m¨
ussen. Von der Bildschirmaufl¨
osung ¨
uber den einzusetzen-
den Browser bis hin zu Speicher- und Prozessoranforderungen reicht das Spektrum m¨
oglicher
Angaben. Abbildung 11.16 zeigt schematisch den Baum f¨
ur die drei beschriebenen Kategorien.
Sprache Kontext
Objektiv
... ... ZielgruppeTitel Auflösung ... Prozessor
Technisch
...
...
...
...
...
...
Metadaten
Didaktisch
Abbildung 11.16: Metadatenkategorien
Neben der Anordnung der Metadaten sind auch die eingesetzten Datentypen der Attribu-
te von Bedeutung. Hierunter werden verschiedene Wertebereiche verstanden, wie z.B. Text,
Datum und Zahl. Sie m¨
ussen so allgemein gehalten sein, dass sie von allen Metadaten verarbei-
tenden Applikationen interpretiert werden k¨
onnen. Dem gegen¨
uber steht der uneingeschr¨
ank-
te Einsatz eigener Metadaten, die durchaus exotischer sein d¨
urfen. Hier muss ein geeigneter
Kompromiss zwischen Verarbeitbarkeit und Flexibilit¨
at gefunden werden. Hinzu kommen noch
komplexere Strukturen, die nicht vollst¨
andig durch die Basistypen abgedeckt werden. Im Fol-
genden werden wesentliche Merkmale der Datentypen diskutiert.
Manch ein Metadatum enth¨
alt ein oder mehrere W¨
orter, um eine bestimmte Eigenschaft
eines Lernobjekts zu beschreiben. Soll beispielsweise der Schwierigkeitsgrad einer Aufgabe an-
gegeben werden, bieten sich W¨
orter wie ”schwierig“, ”mittel“ und ”einfach“ an. Eine ¨
ahnliche
Bedeutung kann aber auch mit ”anspruchsvoll“, ”durchschnittlich“ und ”leicht“ erreicht wer-
den. Reicht die Aufl¨
osung dieser Bewertung nicht aus, k¨
onnen auch Gradpartikeln wie ”sehr“,
”ziemlich“ und ”wenig“ hinzugef¨
ugt werden. Der Fantasie sind in nat¨
urlichen Sprachen kaum
Grenzen gesetzt. F¨
ur die maschinelle Verarbeitung ergibt sich aus dieser Vielseitigkeit jedoch
ein Problem, da eine Interpretation kaum m¨
oglich ist. Auf eine maschinennahe Kodierung, z.B.
in Form eines Wertebereichs 1–6, sollte im Interesse der Anwender/-innen dennoch verzichtet
werden. Die ad¨
aquate L¨
osung sind W¨
orterb¨
ucher, die einerseits das Verst¨
andnis nat¨
urlich-
sprachlicher W¨
orter beinhalten, andererseits wenig Komplexit¨
at in die Programmierung der
Applikationen bringen.
Ein W¨
orterbuch ist eine vorgegebene Menge an W¨
ortern, die f¨
ur ein Metadatum einge-
setzt werden d¨
urfen. Festgehalten in einem Standard, gew¨
ahrleistet ein W¨
orterbuch f¨
ur ein
Metadatenfeld die semantische Interoperabilit¨
at beim Austausch zwischen unterschiedlichen
Systemen. Obwohl die Standards explizit die Angabe nicht enthaltener W¨
orter erlauben, ist
eine Einhaltung stark empfohlen, damit der Sinn eines W¨
orterbuchs nicht untergraben wird.
11.2 Metadaten 123
Die Standards LOM und Dublin Core definieren eine Reihe von W¨
orterb¨
uchern, die in den
jeweiligen Klassen der Metadaten-API unterst¨
utzt werden sollten. F¨
ur die Datenhaltung wird
die Klasse Dictionary definiert, die eine schnelle ¨
Uberpr¨
ufung erm¨
oglicht, ¨
ahnlich einer Hash-
Menge. Um nicht an Unterschieden in der Groß- und Kleinschreibung zu scheitern, wird f¨
ur
eine ¨
uberschaubare Anzahl von Eintr¨
agen eine sortierte Liste f¨
ur die Implementierung emp-
fohlen.
Nicht alle Inhalte der W¨
orterb¨
ucher sind direkt in den Standards definiert, sondern verwei-
sen auf externe Quellen, was bei der Realisierung der Klasse Dictionary zu ernsten Hindernis-
sen f¨
uhren kann. L¨
asst sich ein umfangreiches W¨
orterbuch mit den existierenden MIME-Types
in Form einer Liste mit Aufwand umsetzen, sieht es beim ”Thesaurus of Geographic Names“
(TGN) problematisch aus. Hierbei handelt es sich um eine strukturierte Sammlung von Voka-
beln, die Millionen von Ortsnamen und andere Informationen wie Koordinaten enth¨
alt. Von
Kontinent bis Provinz ist alles vertreten. Abgesehen von der Implementierung ist die eigen-
st¨
andige Pflege solcher Daten nur mit erheblichem Aufwand m¨
oglich. Daher m¨
ussen solche
Daten extern eingekauft oder von entsprechenden Dienstleistern online ¨
uberpr¨
uft werden. Wie
die Realisierung der Klasse Dictionary letztendlich aussieht, h¨
angt von den verwendeten
Metadaten ab, sodass in der Entwurfsphase keine weiteren Details festgelegt werden k¨
onnen.
Ein anderes Problem beim Umgang mit Metadaten adressiert die Internationalisierung
(I18N)1. Dieser Begriff wird ¨
uberwiegend bei Programmen verwendet, die eine Anpassung an
sprachliche und kulturelle Gegebenheiten erlauben. Hierzu geh¨
oren beispielsweise Texte in der
Landessprache, W¨
ahrungen sowie physikalische Einheiten wie Zeit, L¨
angen und Gewichte. Im
Bereich der Metadaten ist neben der Kodierung der unterschiedlichen Daten auch die Deklara-
tion von Land und Sprache Gegenstand der Internationalisierung. Die passenden Regeln samt
Standards wurden bereits bei der Vorstellung von LOM in Abschnitt 4.3 detailliert erl¨
autert.
Bei den Werten handelt es sich um Tupel, bestehend aus einem einfachen oder zusammenge-
setzten Code und einer Ressource. Hierbei ist es prinzipiell gleich, ob es Texte, Bilder oder
andere Daten sind. Im Falle der Metadaten l¨
asst sich diese Vielfalt auf Informationen in Form
von Texten beschr¨
anken.
Der Entwurf einer Klasse f¨
ur die Vorhaltung internationalisierter Daten gestaltet sich ein-
fach. Neben der Speicherung von Schl¨
ussel-Wert-Paare — wobei der Schl¨
ussel beispielsweise
eine Verbindung aus L¨
ander- und Sprach-Code ist — muss die G¨
ultigkeit der verwendeten Co-
des ¨
uberpr¨
uft werden. Bei einer Programmiersprache wie Java liefert der Standardsatz an Li-
braries bereits solche Mechanismen, sodass die Implementierung schnell verrichtet ist. Weniger
gute Unterst¨
utzung bieten die Programmiersprachen bei personenbezogenen Daten, die sich
aus mehreren einfachen Daten, wie z.B. Name, Adresse und Organisation, zusammensetzen.
Da der Austausch dieser Daten zwischen unterschiedlichen Systemen das Hauptanliegen ist,
soll wie bisher verfahren werden und auf etablierte Vereinbarungen zur¨
uckgegriffen werden.
Hierzu geh¨
oren die VCards, eine Art elektronische Visitenkarten, deren Inhalt und Form vom
International Mail Consortium (IMC) vorgegeben wird. Dieser Standard wird ¨
uberwiegend in
Mails, HTML-Seiten, elektronischen Adressverwaltungen und im mobilen Sektor, wie z.B. dem
Handy, eingesetzt. Eine ¨
ubliche Kodierung, die alle Programme lesen k¨
onnen, ist ein Text mit
folgender Struktur. Das Beispiel ist aus der Spezifikation der IMC entnommen.
1BEGIN:VCARD
N:Wason;Thomas;D.;Dr.;Sr.
3FN:Thomas D.Wason,Ph.D.
ORG:IMS Project;Meta Data Team
5ADR:;IMS Project;1421 Park Drive;;North Carolina;27605−1727;USA
TEL:+1 919.839.8187
7EMAIL;INTERNET:twason@imsproject.org
LABEL;QUOTED−PRINTABLE:IMS Project=0A= 1421 Park Drive
9=0A=Raleigh,NC 27605−1727=0A=USA
END:VCARD
1Die Abk¨
urzung I18N stammt aus dem Englischen und steht f¨
ur das Wort Internationalization. Mit der Zahl
18 werden die achtzehn Buchstaben zwischen ”I“ und ”N“ angegeben.’
124 Basiskomponenten
Ohne auf die Details eingehen zu m¨
ussen, l¨
asst sich f¨
ur die Datenhaltung ein bekanntes
Schema entdecken. Schl¨
ussel werden mit Werten zu Paaren kombiniert. Auf diese Weise lassen
sich auch einfache Parser realisieren, die dieses Muster erkennen. Ist eine genauere syntaktische
Analyse gew¨
unscht, sollte auf Produkte Dritter zur¨
uckgegriffen werden.
Abschließend soll die Kodierung von Zeit und Zeitspannen thematisiert werden. In Verbin-
dung mit dem Standard LOM wurden die verwendeten Zeitformate kritisiert, weil sie Mehrdeu-
tigkeiten zulassen. Doch wie sehen die Alternativen zu diesen Standards aus, besonders wenn
sie explizit vorgeschlagen sind? Die Metadaten-API kommt also nicht umhin, diese Formate
zu unterst¨
utzen. Ansonsten w¨
are die Kompatibilit¨
at zu anderen Anwendungen gef¨
ahrdet, was
wesentlich schlimmer ist, als die genannten Probleme.
11.2.2 Operationen
Mit einer Metadatenstruktur ist wenig anzufangen, wenn sie nicht ver¨
andert bzw. auf Rich-
tigkeit ¨
uberpr¨
uft werden kann. Aus diesem Grund bieten die Klassen der Metadaten-API
verschiedene Operationen an. In dieser Arbeit sollen drei Formen unterschieden werden: Pro-
duktion,Manipulation und Validierung. Unter Produktion wird die eigentliche Erstellung
neuer Metadaten verstanden. Ver¨
anderungen an existierenden Daten geh¨
oren zur Manipula-
tion und die ¨
Uberpr¨
ufung der syntaktischen Korrektheit ist Aufgabe der Validierung. Weil
diese Aufteilung essentiell f¨
ur die Gestaltung der Klassen ist, erfolgt nun eine detailliertere
Ausf¨
uhrung.
Alle Methoden in den Klassen der Metadaten-API, mit denen die interne Metadatenstruk-
tur aufgebaut wird, geh¨
oren zur Produktion. Es gibt verschiedene Kontexte f¨
ur die Aufrufe,
von denen die wichtigen in Abbildung 11.17 dargestellt sind.
XML−Reader
XML
DB DB−Reader
Import
DOC
Author Metadata Tool
...
MD Structure
...
...
Standard Reader
Abbildung 11.17: Produktion der internen Metadatenstruktur
In der Mitte befinden sich die Reader-Klassen, die in Abschnitt 11.2 vorgestellt wurden.
Auch wenn es sich um die Konvertierung einer Repr¨
asentation, in diesem Falle XML-Datei
und Datenbank, in einen Objektbaum handelt, ist es aus Sicht der API ein neuer Aufbau von
Metadaten. ¨
Ahnlich verh¨
alt es sich mit dem Import fremder Daten, ganz unten in der Abbil-
dung. Angedeutet durch die Dateiendung DOC des Formats von MS Word, steht diese Art der
Produktion f¨
ur die Integration beliebiger Metadaten aus anderen Quellen. Hierbei ist festzu-
halten, dass es niemals eine vollst¨
andige Abbildung geben kann. Im Falle des Word-Formats
sind nur wenige Metadaten enthalten und die beschr¨
anken sich auf die Autoren/-innen, den
Entwicklungsprozess und den Inhalt. Vielf¨
altiger ist beispielsweise das Format DocBook aus-
gestattet, bei dem gezielt bestimmte Teile des Dokuments mit Metadaten versehen werden
k¨
onnen. In der Praxis zeigt sich jedoch, dass eine 1:1 Abbildung auf die Standards wie Dublin
Core oder LOM nicht m¨
oglich ist. Teilweise m¨
ussen Daten sogar verworfen werden, was die
vollst¨
andige Automatisierung von Importprozessen schwieriger macht.
11.2 Metadaten 125
Freilich gibt es noch die M¨
oglichkeit, Metadaten von Hand aufzubauen, was durch die
Rolle Author mit ihrem Werkzeug, dem Metadata Tool, angedeutet ist. Besonders die subjek-
tiven Daten zu einem Lernobjekt m¨
ussen vom Menschen festgelegt werden. In Anbetracht der
Komplexit¨
at der Metadatenstandards stellt die ad¨
aquate Pr¨
asentation eine Herausforderung
dar. Einerseits soll kein Metadatum vorenthalten werden, andererseits darf eine komplizierte
Darstellung nicht verschrecken. Wie der Kompromiss aussieht, ist f¨
ur die Metadaten-API von
geringer Bedeutung. Sie kommt nicht umhin, alle M¨
oglichkeiten anzubieten.
Doch wie gestaltet sich jetzt die Produktion von Metadaten? Zuerst muss ein Hauptkno-
ten f¨
ur die hierarchische Struktur erstellt werden, der nicht zwangsl¨
aufig Attribute beinhaltet.
An ihn lassen sich die ersten Knoten f¨
ur bestimmte Kategorien einh¨
angen. Die Erzeugung
dieser Objekte geschieht am besten ¨
uber die Konstruktoren selbst, die bereits erste Attribu-
te als Parameter annehmen. Bei weniger genutzten Attributen ist es sinnvoll, sie erst ¨
uber
spezielle Methoden zu setzen, um die Konstruktoren nicht unn¨
otig umfangreich zu gestalten.
Hiernach k¨
onnen weitere Unterkategorien eingeh¨
angt werden, die wiederum Unterkategorien
mit jeweiligen Attributen akzeptieren. Auf diese Weise erfolgt die komplette Produktion der
Metadatenstruktur.
Liegen die Metadaten nach der Produktion im Speicher vor, k¨
onnen sie ¨
uber geeignete
Methoden der API manipuliert werden. Grunds¨
atzlich wird die Bearbeitung in Ver¨
anderun-
gen der Struktur und der Inhalte unterschieden. Die Objekte der Klassen zur Kategorisierung
lassen sich l¨
oschen, verschieben oder neu erzeugen, sodass eine neue Anordnung erstellt wird.
Bei diesen Operationen muss besonders darauf geachtet werden, dass anschließend eine Ab-
bildung auf standardkompatible Strukturen m¨
oglich ist. Weniger kritisch sieht es hingegen
bei den Attributen aus. Als Bestandteil der Klassen zur Kategorisierung k¨
onnen sie entweder
gesetzt oder gel¨
oscht werden. Da bei allen g¨
angigen Abbildungen die Attribute optional sind
— eine sehr wichtige Eigenschaft f¨
ur Application Profiles —, gibt es bis auf die Einhaltung
des Wertebereichs wenig zu beachten.
Die Manipulation der Metadaten kann nur auf zwei Wegen geschehen, wie in Abbildung
11.18 dargestellt. Entweder nehmen die Anwender/-innen die Bearbeitung selbst vor oder ein
Mechanismus eines Programms ¨
andert die Metadaten, die bekannt sind oder sich ableiten
lassen.
...
MD Structure
...
...
Objective Metadata
Author Metadata Tool
Abbildung 11.18: Manipulation der internen Metadatenstruktur
Alle Methoden zur semantischen und syntaktischen ¨
Uberpr¨
ufung fallen unter die Katego-
rie der Validierung. F¨
ur diese Operationen ist besonders der Zeitpunkte der Konvertierung
zwischen den Formaten kritisch, denn hierbei kann es im schlimmsten Fall zu unerw¨
unschten
Datenverlusten kommen, weil sich Metadaten nicht abbilden lassen. Da alle Standards Vorga-
ben zur Kodierung machen, k¨
onnen entsprechende Mechanismen meist problemlos realisiert
werden.
Als Beispiel soll die Klasse LOMReader eine LOM-Datei im XML-Format einlesen und auf
syntaktische Korrektheit ¨
uberpr¨
ufen. Es wird eine vorhandene XML-Library genutzt, sodass
im Entwurf die Entwicklung eines Parsers nicht ber¨
ucksichtigt werden muss. Bei komplexeren
Typen, wie einem Datum oder einer VCard, muss die Validierung nachtr¨
aglich durchgef¨
uhrt
werden. Wird ein Fehler entdeckt, m¨
ussen die Anwender/-innen davon in Kenntnis gesetzt
werden und gegebenenfalls bei der Behebung zu Rate gezogen werden. Sind die Fehler zu
gravierend, sollte von einem Einlesen ganz abgesehen werden.
126 Basiskomponenten
Bei dieser Richtung der Konvertierung kann die Metadaten-API wenig Einfluss nehmen.
Anders sieht es bei Manipulationen des Objektbaums aus. Hier m¨
ussen die jeweiligen Klas-
sen Methoden anbieten, mit denen sich Struktur und Werte der Attribute ¨
uberpr¨
ufen lassen.
Dies setzt freilich die Festlegung eines Formats voraus, auf das hin die Validierung erfolgt.
Zwar sind besonders viele Standards erstrebenswert, aber die Relation zwischen Aufwand und
Nutzen muss gewahrt sein. Aus diesem Grund wird wenigstens die Unterst¨
utzung von LOM
empfohlen, weil es zu den wichtigsten Formaten z¨
ahlt. Eine ¨
Uberpr¨
ufung nach Dublin Core
d¨
urfte wegen der geringen Komplexit¨
at ebenfalls schnell implementiert sein, hat aber nicht die
Bedeutung wie LOM. Letztendlich sind Umfang und Genauigkeit Sache der Implementation.
Beim Entwurf muss nur ber¨
ucksichtigt werden, dass eine Integration der Validierungsmecha-
nismen m¨
oglich ist.
11.2.3 Kodierungen
Die interne Metadatenstruktur als Objektbaum ist der ideale Ausgangspunkt f¨
ur die Erstellung
und Bearbeitung von Metadaten, jedoch ist sie wenig f¨
ur den direkten Austausch zwischen
Applikationen geeignet. Es kann zwar auf Mechanismen der Programmiersprachen zur¨
uckge-
griffen werden, wie z.B. die Serialisierung bei Java, aber dies f¨
uhrt zu einer zu engen Bindung
an eine bestimmte Implementation. Auch Middleware-L¨
osungen, wie z.B. Corba, schr¨
anken
die Nutzung zu sehr ein und haben hohe Anforderungen an die Technik. Der Weg ¨
uber den
Objektbaum im Speicher kann daher nie direkt begangen werden, sondern erfolgt immer ¨
uber
die Reader- und Writer-Klassen aus Abbildung 11.14. ¨
Uber das Format XML soll in diesem
Abschnitt nicht viele Worte verloren werden. Es ist obligatorisch und die Spezifikation der
vorgestellten Metadatenstandards LOM und Dublin Core geben ausf¨
uhrlich Auskunft. Hin-
gegen ist die Speicherung in Datenbanken ein wenig beachtetes Thema, obwohl sie gerade f¨
ur
Suchanfragen optimal geeignet ist.
Die direkte Repr¨
asentation im Speicher ist f¨
ur diese Aufgabe n¨
amlich nur bedingt geeignet.
Es ist wenig sinnvoll, die Metadaten aller Lernobjekte im Speicher vorzuhalten, um eine schnel-
le Suche durchf¨
uhren zu k¨
onnen. Der Bedarf der hierf¨
ur n¨
otigen Ressourcen steht in keiner
Relation zum Nutzen. Auch die Kodierung in XML bringt keine nennenswerte Verbesserung,
weil die resultierende Rechenzeit zu hoch ist. Zuerst m¨
ussten die Metadaten aller Lernobjekte
geladen werden, um sie danach mit der Suchanfrage zu vergleichen. Abgesehen vom Zeitbedarf
der Dateizugriffe sollte auch der Aufwand f¨
ur die Berechnung bereits wenig komplizierterer
Verkn¨
upfungen nicht untersch¨
atzt werden. Nicht ohne Grund gibt es hierf¨
ur Datenbanken, die
genau f¨
ur diese Art von Aufgaben optimiert sind. Es stellt sich nur die Frage, welche Daten-
banktechnik gew¨
ahlt wird, da diese Entscheidung Einfluss auf die entsprechenden Reader und
Writer hat.
Neben den klassischen relationalen Datenbanksystemen gibt es auch XML-Datenbanken.
Sie speichern ihre Daten nativ in XML und scheinen die ideale L¨
osung f¨
ur Suchanfragen ¨
uber
Metadaten zu sein, weil sie eine direkte Abspeicherung der in XML vorliegenden Datens¨
atze
erlauben. Hierdurch entfallen l¨
astige Konvertierungen in beide Richtungen, beim Import von
Lernobjekten und beim Export. Leider ist die Technologie noch relativ jung und im Gegen-
satz zu etablierten Techniken nicht leistungsf¨
ahig genug. Besonders bei großen Datenmengen
sind die Unterschiede gravierend, sodass den XML-Datenbanken erst ein prototypischer Stand
attestiert werden kann und auf relationale Systeme zur¨
uckgegriffen werden muss. Sie profitie-
ren von einem fundierten mathematischen Ansatz, der sich in der Praxis bew¨
ahrt hat. F¨
ur
die Modellierung bedeutet diese Entscheidung hingegen, dass Umst¨
ande in Kauf genommen
werden. Zwar bieten einige Hersteller relationaler Datenbanken Erweiterungen an, die eine
automatische Abbildung von XML-Daten auf ihr Produkt erm¨
oglichen, aber trotzdem kann es
bei unvorsichtiger Konfiguration zu Datenverlusten kommen. Details zu diesem Thema finden
sich z.B. in [Sch¨
oning03].
Leider sind die Verfahren dermaßen unterschiedlich, dass es keinen einheitlichen Mecha-
nismus f¨
ur diese Aufgabe gibt. Als Konsequenz wird bei Verwendung dieser vorgefertigten
11.3 Unterst¨
utzung von Multimedia 127
L¨
osungen Logik aus dem Programm in die Datenbank verlagert, was eine echte Schw¨
ache
des Entwurfs w¨
are und unter allen Umst¨
anden verhindert werden muss. Eine echte Unabh¨
an-
gigkeit kann daher nur mit einer eigenen Abbildung erreicht werden, die bereits im Entwurf
Ber¨
ucksichtigung findet.
Die Struktur und Daten eines XML-Dokuments m¨
ussen folglich ”per Hand“ auf die Tabel-
len abgebildet werden. Hierf¨
ur soll das object-relational Mapping von [Bourret99] eingesetzt
werden, bei dem eine hierarchische Struktur aus Objekten gebaut wird, die sich besonders
einfach auf ein relationales Modell abbilden lassen. Es werden zwei XML-Elemente unterschie-
den: komplexe Elemente mit Unterelementen und einfache Elemente, die nur Text enthalten2.
Die komplexen Elemente werden jeweils als Typ Klasse bezeichnet und die einfachen als Typ
Eigenschaft. Eine Klasse hat immer andere Klassen und Eigenschaften als Attribute, wobei
Eigenschaften lediglich aus einem einfachen oder zusammengesetzten Wert bestehen.
Vater-Kind-Beziehungen zwischen zwei Elementen eines XML-Dokuments werden als inter-
class-Beziehung bezeichnet, wenn beide Elemente vom Typ Klasse sind. Ist das Kind-Element
vom Typ Eigenschaft, so liegt eine class-property-Beziehung vor. Mit Hilfe dieser Unterschei-
dung kann das object-relational Mapping durchgef¨
uhrt werden.
•Klassen auf Tabellen
•Eigenschaften auf Tabellenspalten
•inter-class-Beziehungen werden zu Prim¨
ar-Fremdschl¨
ussel-Paaren
•Eigenschaften mit einem einfachen Wert k¨
onnen auf eine Spalte einer Klassen-Tabelle
oder als separate Tabelle abgebildet werden
•Eigenschaften mit zusammengesetztem Wert m¨
ussen auf separate Tabellen abgebildet
werden
•Das Wurzelelement wird ignoriert, weil es nur eine syntaktische Funktion erf¨
ullt
•Klassen, die nur Eigenschaften als Attribute besitzen, k¨
onnen aufgel¨
ost werden, indem
die Eigenschaften als Attribute der Basisklasse definiert werden
Anhand der Kategorie General des Standards LOM soll das Ergebnis dieses Verfahrens ex-
emplarisch verdeutlicht werden. Die in Abbildung 4.6(b) angegebenen Unterkategorien ergeben
das vereinfachte Resultat in Abbildung 11.19.
Die Unterkategorie Identifier ist reserviert und kann nicht ber¨
ucksichtigt werden. Aus
Gr¨
unden des Platzes und der ¨
Ubersicht sind Structure und Aggregation ebenfalls nicht dar-
gestellt, weil sie Vokabulare nutzen, die weitere Tabellen nach sich ziehen. Eine vollst¨
andige
Umsetzung ist dann Aufgabe der Implementation.
Mit der Vollst¨
andigkeit der Klassen f¨
ur den Umgang mit Metadaten kann nun wieder
abschließend eine Komponente gebildet werden, wie sie in Abbildung 10.10 zu sehen ist. Auf-
grund der Vielzahl von Klassen umfasst die Darstellung dieses Prozesses nur die besonders
herausragenden. Andere Klassen, die zwar auch essentiell sind, werden in Abbildung 11.20 zu
Gunsten der ¨
Ubersicht nicht angezeigt.
11.3 Unterst¨
utzung von Multimedia
Bei der Erstellung modularer E-Learning-Inhalte kommt eine Autorenumgebung nicht um-
hin, multimediale Inhalte zu unterst¨
utzen. Die Anforderungsbeschreibung der Komponente
Multimedia Environment in Unterabschnitt 10.2.2 beschrieb bereits grob den n¨
otigen Funk-
tionsumfang und soll nun verfeinert werden. Grundlegend wurde beschlossen, dass externe
2In XML-Notation tritt dieses Element als Parsed Character Data (PCDATA) oder Character Date (CDA-
TA) auf.
128 Basiskomponenten
1n
n
1
n
n
Structure_Source
Structure_Value
AggreLevel_Source
AggreLevel_Value
n n
Language
Coverage
Text
Language
LANGUAGE
Katalog
Eintrag
CATALOG_ENTRYGENERAL
Language
Text
Keyword
Lanuage
Text
DESCRIPTION
KEYWORD
COVERAGE
General_ID
General_ID
General_ID
General_ID General_ID
General_ID
TITLE
Language
Text
General_ID
Abbildung 11.19: Datenbankschema f¨
ur die Kategorie ”General“ aus [Turan04]
MDWriter
MDReader
Metadata
Abbildung 11.20: Bildung der Komponente Metadata
Programme f¨
ur die Bearbeitung multimedialer Inhalte aufgerufen werden und eine Eigenent-
wicklung nicht in Frage kommt. In Anbetracht des Aufwands, den die ad¨
aquate Umsetzung
eines Format wie z.B. Flash verursacht, ist diese Entscheidung vern¨
unftig. Als L¨
osung wird
nun eine Art Verkn¨
upfung zwischen Anwendungen und Dateien vorgestellt.
Zun¨
achst erhalten die Dateien eine Typisierung, um ihre Inhalte und deren Kodierungen
unterscheiden zu k¨
onnen. Eine M¨
oglichkeit sind die so genannten Multipurpose Internet Mail
Extensions (MIME), deren Spezifikation sich ¨
uber 5 RFCs erstreckt. F¨
ur diese Arbeit ist ledig-
lich der zweite Teil, RFC 2046 [Freed96], interessant, weil er definiert, wie Haupt- und Nebenty-
pen verschiedener Formate kodiert werden. Zur Zeit sind die sieben Haupttypen text,appli-
cation,image,audio,video,message und multipart festgelegt. Ohne weitere Ausf¨
uhrungen
l¨
asst sich bereits erkennen, dass alle relevanten Typen multimedialer E-Learning-Inhalte un-
terst¨
utzt werden. Die Nebentypen geben genauere Auskunft dar¨
uber, was und vor allem wie
es in einer Datei kodiert ist. Als Beispiel sei der Haupttyp image angef¨
uhrt, der f¨
ur Grafiken
und Abbildungen jeglichen Formats steht. Einem Programm zur Anzeige oder Bearbeitung
solcher Dateien reicht diese Information noch nicht aus, denn es gibt viele verschiedene Kodie-
rungen, die ihre Vor- und Nachteile besitzen. Mit verlustbehafteten Komprimierungsverfahren
wie z.B. JPEG lassen sich gut nat¨
urliche Bilder wie Fotografien komprimieren. Hingegen gehen
bei synthetischen Grafiken mit vielen Linien, gleichfarbigen Fl¨
achen und Schriften wesentliche
11.3 Unterst¨
utzung von Multimedia 129
Merkmale verloren. Gravierend wirkt sich die Unterabtastung auf die Qualit¨
at aus, wodurch
das Bild unscharf erscheint. Durch verlustfreie Verfahren wie z.B. PNG werden bessere Ergeb-
nisse erzielt. F¨
ur eine genaue Unterscheidung der Dateien gibt es folglich die Typen jpeg und
png, die voll ausgeschrieben mit den Haupttypen angegeben werden, also image/jpeg bzw.
image/png.
In der Praxis stellt sich jedoch die Erkennung eines Datentyps als Problem heraus, denn
einer Datei ist von außen nicht ohne weiteres anzusehen, was sie enth¨
alt. Viele Dateiforma-
te sind bin¨
ar kodiert und zudem propriet¨
ar, sodass es schwer ist, ein allgemeines Verfahren
zu benennen. Eine M¨
oglichkeit ist die Erstellung so genannter Fingerprints. Mit Hilfe von
Byte Frequency Analysis,Byte Frequency Cross-Correlation Analysis und File Header/Trailer
Analysis werden Muster erkannt, die typisch sind f¨
ur ein Dateiformat [McDaniel03]. Andere
Verfahren erkennen ”Magic Numbers“, also ganz bestimmte Byte-Folgen. Der große Nachteil
gegen¨
uber den Fingerprints ist die mangelnde Allgemeing¨
ultigkeit, denn f¨
ur jedes Format muss
mindestens eine eigene Regel hinterlegt sein.
Egal, welcher Erkennungsmenchanismus letztendlich eingesetzt wird, haben sie alle ein
Problem gemein: Die zu untersuchende Datei muss mindestens ein Mal ge¨
offnet und analysiert
werden, was entsprechende Rechenzeit ben¨
otigt. In Hinblick auf das geplante Einsatzgebiet,
bei dem in verschachtelten Lernobjekten mit m¨
oglicherweise hunderten von Dateien gearbeitet
wird, kann es schnell zu Engp¨
assen kommen. Bereits f¨
ur die Anzeige der enthaltenen Dateien
m¨
ussen die Dateitypen bekannt sein, um sie z.B. in einer grafischen Darstellung durch eigene
Icons hervorzuheben. Die genannten Verfahren sind folglich ungeeignet und es muss nach einer
anderen L¨
osung gesucht werden.
Das Betriebssystem Windows von Microsoft benutzt dreistellige Dateiendungen, um den
Dateityp zu bestimmen. Aber nicht nur die auf den ersten Blick zu erkennende Fehldeutung,
ausgel¨
ost durch eine falsch eingegebene Dateiendung, offenbart Schw¨
achen dieses Systems.
Noch schlimmer sind Angriffe auf den Rechner mit Hilfe kompromittierter Dateien. Ein Mail-
Filter, der sich auf diese Weise austricksen ließe, w¨
are nicht viel wert. Doch so schwerwiegend
solche Argumente auch sein m¨
ogen, f¨
ur das angestrebte Ziel sind sie wenig von Bedeutung.
Schließlich sollen aus dem Autorensystem Programme aufgerufen werden, die bereits instal-
liert sind. Der gewonnene Geschwindigkeitsvorteil gegen¨
uber den analysierenden Verfahren
rechtfertigt letztendlich die Verwendung von Dateiendungen.
Steht der Typ einer Datei erst fest, muss noch die gew¨
unschte Operation bestimmt wer-
den. Abh¨
angig vom Typ lassen sich Dateien ¨
offnen, bearbeiten, drucken, ¨
ubersetzen und in
vielen anderen unterschiedlichen Formen nutzen. Die Auswahl kann z.B. ¨
uber ein Kontextme-
n¨
u aufgerufen werden, das ¨
uber eine bestimmte Taste oder Mausaktion ge¨
offnet wird und alle
m¨
oglichen Operationen anzeigt. Auf diese Weise ist es m¨
oglich, eine Datei mit verschiedenen
Programmen zu ¨
offnen, was die Flexibilit¨
at erh¨
oht. Die Auswahl der gew¨
unschten Operation
erfolgt ¨
uber ein Verb, das als Argument an das System ¨
ubergeben wird. Weil das allgemei-
ne ¨
Offnen in der Praxis die am meisten genutzte Funktion ist, sollte sie in den Programmen
mit dem Doppelklick der Maus verbunden sein. Dieses Verhalten hat sich auf vielen Syste-
men als Standard etabliert und sollte den Anwendern/-innen zuliebe beibehalten werden. Eine
Sonderrolle spielt noch das Erstellen neuer Dateien eines Typs, denn dieser Prozess ist nicht
abh¨
angig vom Kontext irgendeiner Datei. Wo auch immer das aktuelle Arbeitsverzeichnis ist,
sollte diese Aktion mit wenigen Handgriffen m¨
oglich sein.
Anhand der beschriebenen Funktionen lassen sich nun die Schnittstellen und Klassen be-
stimmen, die f¨
ur die Unterst¨
utzung multimedialer Dateien ben¨
otigt werden. Ein wesentliches
Merkmal ist die Vielzahl der m¨
oglichen Operation f¨
ur einen Dateityp, die irgendwie angesteu-
ert werden wollen. Aus diesem Grund werden sie in einer eigenst¨
andigen Klasse zusammenge-
fasst, die sich ¨
uber eine einheitliche Schnittstelle ansteuern l¨
asst. Abbildung 11.3 zeigt, dass
f¨
ur den Aufruf lediglich zwei Methoden ausreichen. Der Signatur nach kann eine Datei plus
ein optionales Verb f¨
ur die Auswahl der Operation als Argumente ¨
ubergeben werden. Ist kein
Verb angegeben, soll eine Standardoperation, wie das bereits erw¨
ahnte ¨
Offnen, ausgef¨
uhrt wer-
130 Basiskomponenten
den. Die Erstellung einer neuen Datei kommt sogar mit einer Methode aus, wie in Abbildung
11.21(b) zu sehen ist.
processFile(VirtualFile)
processFile(String,VirtualFile)
<<interface>>
ProcessFile
(a) Interface ProcessFile
newFile(VirtualFile)
<<interface>>
NewFile
(b) Interface NewFile
Abbildung 11.21: Interfaces f¨
ur den Zugriff und die Erstellung von Dateien
Es steht den Entwicklern/-innen frei, ob sie f¨
ur die Bearbeitung und Erstellung jeweils
unterschiedliche Klassen entwerfen oder sie in einer vereinen. Der Entwurf dieser Arbeit soll
die wichtigsten Formate unterst¨
utzen, damit beim Einsatz nicht f¨
ur jede ”Standarddatei“ erst
eigene Klassen erstellt werden m¨
ussen. Zu den unterst¨
utzten Formaten geh¨
oren Bausteine,
Kurse und eine Beschreibungssprache f¨
ur Inhalte in XML. Anstatt von Klassen zu reden, die
zwei Schnittstellen implementieren, soll der Begriff Handler eingef¨
uhrt werden. Zusammen
mit einer Abk¨
urzung des Dateiformats ergeben sich dann Klassen mit Namen, wie sie in
Abbildung 11.22 verwendet werden3.
<<interface>>
NewFile
LobHandler CobHandler MKMLHandler
<<interface>>
ProcessFile
Abbildung 11.22: Drei Handler
Im folgenden Kapitel 12 wird auf die internen Details der Formate f¨
ur Bausteine und Mo-
delle eingegangen. An dieser Stelle sei festgehalten, dass die Klasse LobHandler f¨
ur Bausteine
zust¨
andig ist und CobHandler f¨
ur Kurse. Beide Handler erlauben es, standardkompatible E-
Learning-Inhalte unter Ber¨
ucksichtigung der Metaphern zu laden, bearbeiten und speichern.
Die Abk¨
urzung ”MKML“ steht f¨
ur die mαth-kit-Markup-Language, die in [Baudry03] genauer
beschrieben steht. Diese Sprache erm¨
oglicht die Trennung von Inhalt und Darstellung, wie sie
in Abschnitt 3.7 f¨
ur moderne Lernobjekte gefordert wird.
Mit den Handlern an sich lassen sich einzelne Dateitypen mit Verben erstellen, aber sie
reichen nicht aus, um eine vollst¨
andige Dateiverarbeitung anzubieten. Wie soll beispielsweise
mit verschiedenen Klassen f¨
ur einen Dateityp umgegangen werden, denn bei aufwendigen
Operationen kann es durchaus sinnvoll sein, diese auf mehrere Klassen aufzuteilen, was die
Schnittstellen auch erlauben. Oder was soll passieren, wenn ein Verb aufgerufen wird, das
von mehreren Handlern unterst¨
utzt wird? Diesen Fragen wird die Klasse MimeTypeHandler
entgegengesetzt, deren Diagramm in Abbildung 11.23 dargestellt ist.
Diese Klasse verwaltet alle Handler eines MIME-Typs und delegiert von außen kommende
Aufrufe an sie weiter. ¨
Uber die Methode setExtensions() werden die Dateiendungen an-
gegeben, auf die der MimeTypeHandler reagieren soll. Ein Aufruf der Methode processFile
f¨
uhrt die gew¨
ahlte Operation aus und sollte kein Verb ¨
ubergeben worden sein, wird automa-
3Die Abk¨
urzungen ”Lob“ und ”Cob“ sind historisch bedingt und haben sich w¨
ahrend der Zeit ergeben, als
die Metaphern sich noch nicht endg¨
ultig bis zur Ebene der Implementierung durchgesetzt hatten. Sie stehen
f¨
ur Learning Object bzw. Course Object und sind auch heute noch die verwendeten Dateiendungen. Weil sich
alle Beteiligten des Projekts daran gew¨
ohnt haben und diese Abk¨
urzungen zu festen Begriffen verankert haben,
soll von einer ¨
Anderung abgesehen werden.
11.3 Unterst¨
utzung von Multimedia 131
addVerbHandler(String, ProcessFile)
removeVerbHandler(String)
setNewHandler(NewFile)
clearNewHandler()
setExtensions(String[])
setDefaultVerb(String)
newFile(VirtualFile)
processFile(VirtualFile)
processFile(String, VirtualFile)
getDefaultVerb():String
getExtensions():String[]
getSupportedVerbs():List
MimeTypeHandler
Abbildung 11.23: Klasse MimeTypeHandler
tisch das zuvor mit setDefaultVerb() gesetzte genommen. Neue Dateien des unterst¨
utzten
MIME-Typs werden durch den Aufruf newFile erzeugt.
Mit dieser Klasse ist die Umsetzung des Aufrufmechanismus f¨
ur einen MIME-Typ vollst¨
an-
dig umgesetzt. Nun fehlt noch eine Verwaltung aller MimeTypeHandler-Objekte, die anhand
der Dateiendung schnell einen passenden Handler ausw¨
ahlt und diesen zur¨
uck gibt. F¨
ur diese
Aufgabe gen¨
ugt eine Klasse, wie sie in Abbildung 11.24 zu sehen ist.
setDefaultHandler(MimeTypeHandler)
getHandler(VirtualFile):MimeTypeHandler
addHandler(MimeTypeHandler)
removeHandler(MimeTypeHandler)
clearDefaultHandler()
getNewHandlers():List
getHandlerForExtension(String):MimeTypeHandler
getHandlerForType(String):MimeTypeHandler
MimeTypeMap
Abbildung 11.24: Klasse MimeTypeMap
Wie zu erwarten, bietet sie Methoden zum Hinzuf¨
ugen, L¨
oschen und Auffinden von Hand-
lern an. Neben den geforderten Dateiendungen (getHandlerForExtension()) kann auch der
MIME-Typ direkt f¨
ur die Auswahl herangezogen werden (getHandlerForType()). Eine sehr
interessante Methode ist getDefaultHandler(), mit dem Dateien eines Typs ge¨
offnet werden,
f¨
ur die kein expliziter Handler definiert ist. Auf diese Weise kommt die Komponente f¨
ur die
Bearbeitung multimedialer Inhalte nie in die Verlegenheit, mit einer Datei nichts anfangen
zu k¨
onnen. F¨
ur die Implementierung sind betriebssystemabh¨
angige Standard-Handler vorge-
sehen, die bei Bedarf von dieser Methode zur¨
uckgegeben werden. Sie delegieren den Aufruf
an das Betriebssystem weiter und k¨
onnen sogar weitere Informationen liefern, wie z.B. die
unterst¨
utzten Verben. Der vorgestellte MIME-Typ-Mechanismus bietet somit mindestens die
gleichen M¨
oglichkeiten im Umgang mit Dateien an wie das Betriebssystem. Zuletzt sei noch
die Methode getNewHandlers() erw¨
ahnt, die einen kontextfreien Zugriff auf alle Handler zur
Erstellung einer Datei eines bestimmten Typs gestattet.
Ein kleines Beispiel soll anhand eines Objektdiagramms das Zusammenspiel der vorge-
stellten Klassen verdeutlichen. Der Einfachheit halber kommt der MIME-Typ-Mechanismus
in Abbildung 11.25 mit zwei MIME-Typen aus, die von insgesamt sechs Handlern verarbeitet
werden k¨
onnen.
Abschließend soll aus den erstellten Klassen eine Komponente f¨
ur die Rolle Developer
erstellt werden, wie sie in Abbildung 10.11 zu sehen ist. Der Herleitungsprozess in Abbildung
11.26 enth¨
alt wie immer der ¨
Ubersicht halber nicht alle Klassen.
132 Basiskomponenten
verb=Edit
:ProcessFile
verb=Print
:ProcessFile
verb=Open
:ProcessFile
:NewFile
:MimeTypeMap
type=TEXT/HTML
:MimeTypeHandler verb=Open
:ProcessFile
:NewFile
type=TEXT/XML
:MimeTypeHandler
Abbildung 11.25: Objektdiagramm mit zwei unterst¨
utzen MIME-Types
MimeTypeMap
MimeTypeHandler
<<interface>>
NewFile
<<interface>>
ProcessFile
Multimedia
Environment
Abbildung 11.26: Bildung der Komponente Multimedia Environment
Kapitel 12
Baustein und Kurs
In diesem Kapitel werden alle Komponenten zur Erstellung, Bearbeitung und Verwaltung
von modularen E-Learning-Inhalten entworfen. Hierbei unterscheidet sich die Vorgehenswei-
se gegen¨
uber dem in Kapitel 11 beschriebenen durch eine andere Klassenbildung. Gleichwohl
auch bei diesen Komponenten das Ziel die Erstellung generischer Libraries ist, wird aufgrund
der inh¨
arenten ¨
Ahnlichkeit von Baustein sowie Kurs zum Content Packages eine abstraktere
Abbildung entstehen. Nach außen pr¨
asentieren die Komponenten Learning Object Deve-
lopment und Structure Development unterschiedliche Schnittstellen, aber intern wird zu
einem großen Teil auf die gleiche Klassen zur¨
uckgegriffen. Die grafische Ansteuerung ist sehr
individuell und sollte nicht als Teil des Entwurfs betrachtet werden. Ein konkretes Beispiel
f¨
ur eine grafische Oberfl¨
ache, wie sie im Projekt mαth-kit eingesetzt ist, wird im Teil ¨
uber die
Implementierung gegeben.
12.1 Bindung an Standards
Ein erster Versuch der Modellierung w¨
are, das Problem bzw. den Prozess zu analysieren und
daraus die passenden Klassen herzuleiten. Aus dieser Ӭ
ublichen“ Perspektive geht allerdings
schnell ein wichtiges Detail verloren: der Austausch von Inhalten mit anderen Systemen. Im
Kapitel 3¨
uber Lernobjekte wurde der Einsatz von Standards vorgeschlagen, um Inkompati-
bilit¨
aten vorzubeugen. Die Gestaltung des Klassenmodells kommt somit nicht umhin, diesen
bedeutenden Aspekt zu ber¨
ucksichtigen. Hierbei treten die selben Widerspr¨
uche zwischen ge-
ringer Komplexit¨
at und Vielseitigkeit auf, wie bereits im vorherigen Kapitel 11 bei den Meta-
daten. Dem Wunsch, m¨
oglichst viele Standards unterst¨
utzen zu wollen, steht eine einheitliche
und ¨
ubersichtliche Schnittstelle der API entgegen. Wenn m¨
oglich, sollten keine Spezialf¨
alle
ber¨
ucksichtigt werden, um nicht die Koh¨
asion der Klassen abzuschw¨
achen.
Zu den verbreitetsten Standards f¨
ur Lernobjekte sind das IMS Content Packaging und das
Sharable Content Object Reference Model (siehe Abschnitt 3.5 und 3.6) zu z¨
ahlen, die sich zum
Gl¨
uck sehr ¨
ahneln. Sie bieten sich an, den technischen Rahmen f¨
ur den Entwurf von Baustein
und Kurs zu stellen. F¨
ur die fachliche Beschreibung dienen die Definitionen der Metaphern
aus Abschnitt 10.4, deren Eigenschaften das wesentliche Erscheinungsbild pr¨
agen.
Diese Herangehensweise, die Standards dermaßen einzubeziehen, ist nicht offensichtlich
und bedarf einer Erkl¨
arung. Denn selbst den Spezifikationen ist eine derartige N¨
ahe zu den
Implementierungen nicht entnehmbar. Eigentlich sind die Standards f¨
ur den Austausch zwi-
schen den Systemen gedacht und nicht f¨
ur die direkte Verwendung in Applikationen. Doch
warum soll dieser ungew¨
ohnliche Weg beschritten werden? Weil sich hieraus verschiedene Vor-
teile ergeben. Zwar ist es beim Entwurf freilich angenehmer, ein Klassenmodell zu erstellen,
das keinen externen technischen Einschr¨
ankungen unterliegt, aber sp¨
atestens beim Austausch
mit anderen Systemen muss die Standardkompatibilit¨
at bedacht werden. Mit mehr oder we-
niger M¨
uhen muss dann das eigene Modell auf die vorgegebenen Datenstrukturen abgebildet
werden, oft mit m¨
aßigem Erfolg. Die beiden vorgeschlagenen Standards sind leider so flexibel,
134 Baustein und Kurs
dass Content Packages im schlimmsten Fall propriet¨
are Daten enthalten, die doch wieder nur
mit speziellen Programmen genutzt werden k¨
onnen. Echte Austauschbarkeit bleibt so auf der
Strecke und die resultierenden Konsequenzen zeigen sich in den vorgestellten Produkten aus
Kapitel 5. Sie produzieren letztendlich inkompatible Dateien, die im Gewand der Standard-
konformit¨
at daher kommen und Versprochenes nicht einl¨
osen.
Durch die direkte Verwendung der Standards tritt dieses Problem erst gar nicht auf. Doch
wie steht es mit den Anforderungen der Metaphern? Lassen sich die Standardformate so nut-
zen, dass sie sich wie Bausteine zu h¨
oheren Strukturen zusammensetzen lassen? Auch wenn
diese Funktion abermals nicht explizit den Spezifikationen zu entnehmen ist, l¨
asst sich solch ein
rekursiver Ansatz verwirklichen. ¨
Uber komplexer werdende Bausteine und Kurse wird sich der
eigentlichen L¨
osung gen¨
ahert. Abbildung 12.1 zeigt die einfachste Variante eines Lernobjekts
als Content Package, angelehnt an die Bausteinmetapher.
HTML
HTML
HTML
HTML
WAV
PNG
PNG
Applet
PNG
HTML
Abbildung 12.1: Ein einfacher Baustein aus [Bungenstock04a]
Auf der linken Seite ist das Manifest zu erkennen, das eine hierarchische Struktur enth¨
alt.
Die Knoten haben als Attribute Referenzen auf die rechts stehenden physikalischen Dateien,
die den Inhalt des Lernobjekts ausmachen. Es handelt sich um einen Baustein, wie er von der
Rolle Developer erstellt wird. Bei dieser ¨
ublichen Form des Content Packages gibt es wenig
technische Herausforderungen. Lediglich die Speicherung der Dateien und der Aufbau das
Manifests m¨
ussen modelliert werden. Auch wenn diese Funktionen bereits einige ¨
Uberlegungen
ben¨
otigen, um zu einer geschickten L¨
osung zu gelangen, stellt der n¨
achste Schritt, n¨
amlich die
Komposition verschiedener Bausteine zu einem Kurs, die eigentliche Herausforderung dar.
Es stehen zwei M¨
oglichkeiten f¨
ur die Umsetzung zur Auswahl. Die erste, bei der Bausteine
auf Submanifeste abgebildet werden, ist von den Spezifikationen explizit vorgesehen. Bei der
Komposition von Bausteinen werden die Dateien in ein Content Package kopiert und die
Manifeste zu einem großen Manifest zusammengef¨
uhrt. Jedes Manifest eines Bausteins wird
auf diese Weise zu einem Submanifest, das ¨
uber ein Item referenziert wird. Das Resultat ist
in Abbildung 12.2 wieder als vereinfachte Bausteingrafik dargestellt.
HTML
HTML
HTML
HTML
WAV
PNG
PNG
Applet
PNG
HTML
Abbildung 12.2: Baustein mit Submanifesten aus [Bungenstock04a]
12.1 Bindung an Standards 135
Im Gegensatz zur vorherigen Abbildung setzt sich die hierarchische Struktur aus Subma-
nifesten zusammen. Bei den Dateien hat sich gegen¨
uber der ersten Variante nichts ge¨
andert,
denn sie liegen zusammen auf einer physikalischen Ebene. Es gibt aber dennoch einen Un-
terschied, der den Prozess der Komposition betrifft. Wenn zwei Bausteine zusammengesetzt
werden, kommt es zu einer Vermischung der Dateien auf Verzeichnisebene. So lange die Datei-
en unterschiedliche Namen haben, ist dieser Vorgang unkritisch. Doch sobald sie sich gleichen,
m¨
ussen die Dateien mit unterschiedlichen Namen oder an verschiedenen Orten gespeichert
werden. Letzteres kann ¨
uber Verzeichnisse geregelt werden, die in Content Packages erlaubt
sind. Diese Strategie f¨
uhrt zwar zu richtigen, aber m¨
oglicherweise nicht zu optimalen Ergebnis-
sen. Es sei z.B. ein Java Applet angenommen, das ¨
uber einen Konfigurationsmechanismus eine
Vielzahl von Aufgaben und Tests erm¨
oglicht. Aufgrund dieser Flexibilit¨
at ist es 2 MB groß
und wird in f¨
unf Bausteinen verwendet, die zu einer h¨
oheren Struktur kombiniert werden. Das
Ergebnis ist ein Content Package mit einer Gr¨
oße von mindestens 10 MB, obwohl eine Gr¨
oße
von ca. 2 MB m¨
oglich ist. Es kann sich folglich lohnen, die Dateien inhaltlich zu vergleichen,
um solche Redundanzen zu vermeiden.
Diese Form der Komposition von Bausteinen ist einfach umzusetzen, weil sie dem Aufbau
eines einzelnen Bausteins ¨
ahnelt. Lediglich Submanifeste und eine etwas umfangreichere Da-
teiverwaltung m¨
ussen integriert werden. Kritisch betrachtet, ¨
ahnelt dieser Ansatz aber nicht
zusammengesetzten Bausteinen, denn f¨
ur die Dekomposition von Kursen muss zuvor die inter-
ne Struktur analysiert werden. Aus einem Submanifest wird dann ein oberstes Manifest und
ergibt zusammen mit allen Dateien einen neuen Baustein. Die urspr¨
ungliche Form steht nicht
mehr zur Verf¨
ugung, weil sie bei der Komposition verworfen wurde.
Um eine n¨
ahere Verbindung zu den Bausteinen und ihren Eigenschaften zu erm¨
oglichen,
wird nun die zweite M¨
oglichkeit der Komposition vorgestellt. Anstatt die beteiligten Content
Packages bei diesem Prozess aufzul¨
osen, sollen sie lieber direkt als physikalische Ressourcen
genutzt werden. Abbildung 12.3 zeigt die verschachtelten Content Packages in Form von Bau-
steinen und verdeutlicht den Unterschied zu der L¨
osung mit Submanifesten.
Abbildung 12.3: Verschachtelte Bausteine aus [Bungenstock04a]
Diese Kombination von Lernobjekten erscheint wesentlich intuitiver, zieht aber technische
Konsequenzen nach sich, die nicht untersch¨
atzt werden d¨
urfen. Da es sich bei jedem Content
Package um eine geschlossene physikalische Einheit handelt, ist der Aufwand f¨
ur die Dar-
stellung der Gesamtstruktur erh¨
oht. Es ist nicht auf den ersten Blick ersichtlich, wie viele
und welche Dateien in allen Bausteinen enthalten sind. Auch die Strukturbeschreibung liegt
¨
uber mehrere Manifeste verteilt, die erst zusammengetragen werden m¨
ussen, bevor sie genutzt
werden k¨
onnen. Im Sinne der Verst¨
andlichkeit und der Metaphern lohnt sich dieser Aufwand
dennoch.
Doch wie steht es mit der Kompatibilit¨
at zu anderen Anwendungen? Sie ist ein wirkliches
Problem, dass bereits im Entwurf angegangen werden muss. Andere Autorensysteme und
Lernplattformen sind freilich nicht in der Lage, eine richtige Interpretation zu leisten. Nun
ist aber genau der Austausch zwischen unterschiedlichen Systemen das Hauptargument f¨
ur
136 Baustein und Kurs
den Einsatz der Standards gewesen und sollte nicht durch das Konzept verhindert werden.
Diesem Manko kann durch Umwandlung begegnet werden, indem verschachtelte Bausteine zu
einem einfachen Content Package konvertiert werden. Hierf¨
ur wird einfach der Prozess der
Komposition nachgebildet, wie er bereits f¨
ur Kurse mit Submanifesten beschrieben wurde.
Werden die in den Abbildungen 3.8 und 3.9 dargestellten Regeln aus dem Abschnitt 3.5 auf
die Submanifeste angewandt, k¨
onnen verschachtelte Bausteine sogar mit einem Hauptmanifest
erzeugt werden. Dieses sehr einfache Format aus Abbildung 12.1 m¨
ussen alle Anwendungen
interpretieren k¨
onnen, die sich als standardkompatibel ausgeben.
Eine Umsetzung der Bausteine und Kurse unter Einhaltung der Kompatibilit¨
at ist also
konzeptionell m¨
oglich. F¨
ur die physikalische Speicherung der Daten innerhalb der Content
Packages kann die Dateisystem-API aus dem Kapitel 11 herangezogen werden. Mit Hilfe
der Vererbung entstehen neue Dateisysteme, die genau den Anspr¨
uchen, insbesondere den
Schwierigkeiten durch die m¨
ogliche Verschachtelung, gerecht werden. Letztendlich wird nur
noch eine API f¨
ur den Aufbau von Manifesten gebraucht, um die Umsetzung der Standards
zu vervollst¨
andigen. Die n¨
achsten beiden Abschnitte beschreiben die Herleitungen im Detail.
12.2 Physikalische Dateien
Wie in Abschnitt 3.5 beschrieben, unterscheidet die Spezifikation des IMS Content Packa-
ging zwei Formen der physikalischen Datenhaltung: logische Verzeichnisse, Package genannt,
und die Zusammenfassung in einer Datei, als Package Interchange File (PIF) bezeichnet. Wie
gehabt wird der Begriff Package als Synonym f¨
ur PIF genutzt, es sei denn, ein wesentlicher
Unterschied soll herausgestellt werden. Da es sich bei dieser Unterscheidung eigentlich um ein
technisches Detail handelt, soll der Zugriff ¨
uber eine Schnittstelle, genauer gesagt eine Klasse,
erfolgen. F¨
ur den Entwurf der Klassen ist es dennoch ungemein wichtig, diesen Unterschied
zu ber¨
ucksichtigen, um verschiedenen Implementationen und zuk¨
unftigen Entwicklungen ge-
wachsen zu sein. Die Basisklassen f¨
ur die folgenden ¨
Uberlegungen sind die Klassen VFSNode
(siehe Abbildung 11.7) und VFS (siehe Abbildung 11.9) aus Unterabschnitt 11.1.2.
Aus den Gemeinsamkeiten von Package und PIF kann eine Klasse entstehen. Doch wel-
che Eigenschaften sind gleich, welche unterschiedlich? Besonders die PIFs k¨
onnen in ihrer
Umsetzung stark variieren. Da die Spezifikation die unbedingte Unterst¨
utzung von RFC 1951
(ZIP) verlangt, soll sie als Referenzimplementation dienen. Eigentlich f¨
ur die Archivierung und
den Datenaustausch gedacht, weist dieses Format Schw¨
achen auf, die sich auf die Umsetzung
auswirken. So ist es beispielsweise nicht m¨
oglich, in eine bestehende Datei neue Dateien hinzu-
zuf¨
ugen, sie zu entfernen oder in irgendeiner Form zu bearbeiten1. Als Konsequenz muss jedes
PIF vor der Bearbeitung entpackt werden, z.B. in ein Verzeichnis eines anderen Dateisystems.
Dieser Schritt entspricht einer Umwandlung von einem PIF zu einem Package, sodass, wenn er
transparent erfolgt, lediglich ein Mechanismus f¨
ur den Umgang mit Packages entwickelt wer-
den muss. Eine abschließende R¨
uckumwandlung bei PIFs, es wird der Vollst¨
andigkeit halber
erw¨
ahnt, vollzieht sich genauso automatisch.
Die Idee f¨
ur die Umsetzung dieser Funktionalit¨
at ist ein Dateisystem, das ein tempor¨
a-
res Verzeichnis erstellt, in dem das Dateisystem eines Packages vor¨
ubergehend gespeichert
wird. Hierf¨
ur werden beim ¨
Offnen alle Dateien umkopiert und nach Abschluss der Bearbei-
tung wieder zu einem Package zusammengesetzt. Eine interne ¨
Ubersetzung der Pfade auf die
tempor¨
aren erfolgt ¨
uber die Klasse TempFSNode, die in Abbildung 12.4 dargestellt ist.
Es wurden keine neuen Methoden hinzugef¨
ugt, sondern die abstrakten implementiert. Ein
kurzes Beispiel soll ein besseres Verst¨
andnis der Funktionalit¨
at geben. Innerhalb eines Packages
befinden sich zwei Dateien, ein Manifest in XML (imsmanifest.xml)und eine HTML-Seite
(index.html). Das Dateisystem f¨
ur tempor¨
are Dateien, auf das gleich genauer eingegangen
1Ohne weiter auf Details eingehen zu wollen, erschließt sich diese Aussage aus der Natur der Kodierung mit
einem Huffman-Code. Jegliche ¨
Anderung des Inhalts zieht eine ¨
Anderung am Alphabet nach sich und erfordert
eine Umkodierung der anderen Inhalte.
12.2 Physikalische Dateien 137
VFSNode
TempFSNode
Abbildung 12.4: Klasse TempFSNode
wird, kopiert diese beiden Dateien in ein tempor¨
ares Verzeichnis mit dem Pfad /var/tmp/pifs,
was den Anwendern/-innen nicht mitgeteilt wird. Sie benutzen in ihrer Anwendung die Pfade
des Packages, also /index.html anstatt /var/tmp/pifs/index.html. Umgewandelt werden
die Pfade in der Klasse TempFSNode.
Um nicht den Eindruck aufkommen zu lassen, dass dieser Mechanismus nur f¨
ur PIFs be-
n¨
otigt wird, sei auf die M¨
oglichkeit des Abbruchs hingewiesen. Alle ausgef¨
uhrten Operationen
m¨
ussen umkehrbar sein, wenn die ¨
Anderungen doch nicht gespeichert werden. Wurde die Be-
arbeitung auf dem Original ausgef¨
uhrt, dann ist eine Herstellung des urspr¨
unglichen Zustands
schwierig. Deshalb ist es besser, auf einer Kopie zu arbeiten, die bei Bedarf zur¨
uckgespeichert
wird. Doch bevor auf diese Operation n¨
aher eingegangen wird, soll noch das Dateisystem f¨
ur
tempor¨
are Dateien behandelt werden. Abbildung 12.5 zeigt die Klasse TempFS, die zwei neue
Methoden einf¨
uhrt.
dispose()
getTmpFile(VirtualFile):VirtualFile
VFS
TmpVFS
Abbildung 12.5: Klasse TempFS
Die Methode dispose() entfernt alle tempor¨
aren Dateien und mit Hilfe von getTmpfile()
lassen sich die lokalen Dateien auf die tempor¨
aren physikalischen abbilden.
Weil die API allgemein gehalten wird und diese Klasse optimal f¨
ur die Haltung tempor¨
a-
rer Dateien ist, wird der R¨
uckweg, die tempor¨
aren Dateien in Packages zu speichern, in eine
andere Klasse ausgelagert. Dies mag auf den ersten Blick nicht ersichtlich sein, aber durch die
n¨
achste Ebene, die lediglich eine allgemeine Schnittstelle f¨
ur den Zugriff auf die Implementatio-
nen gestattet, wird der Entwurf klarer strukturiert. Bei der Speicherung m¨
ussen verschiedene
Zust¨
ande ber¨
ucksichtigt werden, die sich in den Methoden der Klasse SavableFS widerspie-
geln. Weil sich keine strukturellen Ver¨
anderungen auf der Ebene der Dateien ergeben, muss
f¨
ur dieses Dateisystem keine eigenen Knoten-Klasse erstellt werden. Abbildung 12.6 zeigt das
entsprechende Diagramm f¨
ur das Dateisystem.
Entweder wird ein existierendes Package ge¨
offnet, oder es wird neu erzeugt. Die Feststel-
lung des initialen Ausgangspunkt erfolgt ¨
uber die Methode getFile(). Wenn der Inhalt des
Dateisystems die Kopie aus einer Datei ist, wird genau diese zur¨
uckgegeben. Andernfalls ist
der Wert null. Als Vereinfachung f¨
ur den Test in booleschen Ausdr¨
ucken wird das Pr¨
adikat
hasFile() angeboten. ¨
Uber die Methode save() wird, wenn das Pr¨
adikat den Wert ”wahr“
liefert, der aktuelle Zustand des tempor¨
aren Verzeichnisses in die Datei geschrieben. Hiernach
kann mit dem Dateisystem normal weiter gearbeitet werden, bis die Methode close() aufge-
rufen wird, die endg¨
ultig alle belegten Ressourcen freigibt. Die eigentliche Speicherung erfolgt
¨
uber die Methode save(VirtualFile), der eine Datei als Ziel mitgegeben wird. Sie ist als
abstrakt definiert und muss in den Unterklassen implementiert werden. Da bereits am Anfang
138 Baustein und Kurs
save()
getFile():VirtualFile
hasFile():Boolean
save(VirtualFile) {abstract}
TmpVFS
{abstract}
SavableVFS
Abbildung 12.6: Klasse SavableFS
dieses Abschnittes festgestellt wurde, dass es nur zwei Formen der Speicherung gibt, sind in
Abbildung 12.7 die Pendants abgebildet. Beide Klassen, ZipFS und DirectoryFS, bieten keine
neue Methoden an, sondern implementieren die Speicherung.
SavableFS
ZipFS DirectoryFS
Abbildung 12.7: Die Unterklasse ZipFS und DirectoryFS
Es bleibt festzuhalten, dass ¨
uber die Schnittstelle der Klasse SavableFS ein einheitlicher
Zugriff auf verschiedene Typen von Content Packages m¨
oglich ist, der die Konstruktion von
Baustein- und Kurs-Klassen sehr einfach h¨
alt. Auch die Handhabung verschachtelter Inhalte
ist durch den orthogonalen Ansatz kein Problem mehr. Was noch fehlt, ist die Modellierung
der Manifeste, die im folgenden Abschnitt behandelt wird.
12.3 Manifest
Das Manifest beschreibt die Struktur sowie Ressourcen der Bausteine und Kurse. Eine Mo-
dellierung dieses ”Bauplans“ l¨
asst sich leicht aus den Spezifikationen der Standards IMS CP
und SCORM ableiten. Da die Manifeste f¨
ur Bausteine eine echte Untermenge der Manifeste
f¨
ur Kurse sind, k¨
onnen beide ¨
uber einen Entwurf dargestellt werden. Auch die marginalen
Unterschiede zwischen den beiden Standards, die nur in zus¨
atzlichen Attributen liegen, behin-
dern dieses Vorhaben nicht. So wie es bereits XML-Bindings f¨
ur Manifeste gibt, soll nun ein
objektorientiertes Modell hinzukommen, das sich in dieser Arbeit OO-Binding nennt. Die
Datenstruktur eines Manifests in Abbildung 3.7 ist ein guter Ausgangspunkt, um die folgenden
¨
Uberlegungen besser nachvollziehen zu k¨
onnen.
In den XML-Bindings werden 10 Elemente mit ihren Attributen definiert. F¨
ur eine objek-
torientierte Darstellung ist es wichtig, Gemeinsamkeiten sowie Unterschiede deutlich heraus-
zustellen und die Assoziationen untereinander zu benennen. Tabelle 12.1 listet alle Elemente
sowie deren relevanten Eigenschaften auf.
Eltern-Elemente k¨
onnen andere Elemente als Kind-Elemente enthalten und obligato-
rische Elemente sind Elemente, die immer mit ihrem Eltern-Element bzw. als Wurzelelement
im Manifest enthalten sein m¨
ussen. Nach UML wird diese Assoziation als Komposition be-
zeichnet, da die Existenzberechtigung obligatorischer Elemente vom Aggregat (dem Ganzen)
abh¨
angt. Ausnahmen sind die Elemente manifest und item, weil sie kontextabh¨
angig sind.
Als oberstes Element verk¨
orpert manifest schlichtweg ein Manifest und ist obligatorisch ein-
12.3 Manifest 139
Eltern-Element
Kind-Element
Obligatorisch
Bezeichner
Referenziert
XML:Base
Metadaten
¨
Anderungen
dependency # # # # #
file # # # # #
item G# #
manifest G# #
metadata # # # # #
organization # # #
organizations # # # #
resource # #
resources # # #
title # # # # # #
: ja #: nein G#: beides
Tabelle 12.1: Gemeinsame Eigenschaften der Manifest-Elemente aus [Bungenstock04b]
zusetzen. Tritt es jedoch als Submanifest auf, ist es optional. ¨
Ahnlich verh¨
alt es sich mit dem
item, denn in einem Element organization ist es obligatorisch und als Subitem optional.
Manche Elemente sind mit Bezeichnern (ID) versehen, um sie von anderer Stelle aus refe-
renzieren zu k¨
onnen. Diese IDs m¨
ussen innerhalb des gesamten Manifests eindeutig sein. Die
Eigenschaft XML:Base ist f¨
ur Kind-Elemente mit URLs als Attributwerten von Bedeutung,
weil relative URLs immer gegen die n¨
achste XML:Base aufgel¨
ost werden. Metadaten sind
zus¨
atzliche Daten, wie sie in Kapitel 4 beschrieben sind. Mit der Eigenschaft ¨
Anderungen
ist die Modifizierbarkeit der Elemente gemeint, die f¨
ur alle zutrifft.
Bevor aus den Werten der Tabelle 12.1 die n¨
otigen Klassen hergeleitet werden, k¨
onnen ein
paar Elemente als relevante Klasse ausgeschlossen werden. Bei title handelt es sich mehr
um ein Attribut als ein eigenst¨
andiges Element, sodass es durch eine einfache Zeichenkette
dargestellt werden kann. Die Klasse Title in Abbildung 12.8(a) ist somit Bestandteil der
Klassen Organization sowie Item und kann entfallen.
Item
Title
Organization
(a) Kompositionen mit Title
Organizations
Manifest
Resources
(b) Komposition mit Resources und Orga-
nizations
Abbildung 12.8: Strukturierte Adresse
Auch resources und organizations tragen keine komplexen Strukturen bei und k¨
onnen
durch einfache Basistypen wie Array oder Liste realisiert werden. Abbildung 12.8(b) zeigt die
m¨
ogliche Komposition, welche die Klassen Resources und Organizations ¨
uberfl¨
ussig macht.
Aus Tabelle 12.1 ist ersichtlich, dass alle Elemente zwei Eigenschaften besitzen, die sich in
einer gemeinsamen Basisklasse zusammenfassen lassen: Jedes Element kann als Kind-Element
auftreten und ist modifizierbar. Um der hierarchischen Struktur gerecht zu werden, lautet ihr
Name HierarchicalElement. Abbildung 12.9 zeigt die Basisklasse aller Elemente.
Die ersten drei Methoden sind f¨
ur die Benachrichtigungen bei Ver¨
anderungen zust¨
andig.
Jede Klasse, die ¨
uber ¨
Anderungen in einem Element in Kenntnis gesetzt werden m¨
ochte,
muss das Interface ModificationListener implementieren und sich zur Laufzeit ¨
uber die
Methode addListener() als Objekt anmelden. Sobald ein Element eine ¨
Anderung erf¨
ahrt, ruft
140 Baustein und Kurs
addListener(listener:ModificationListener)
removeListener(listener:ModificationListener)
#propagateModification(mod:Modification)
setParentElement(parent:HierarchicalElement)
clearParentElement()
HierarchicalElement
{abstract}
hasParentElement():Boolean
getParentElement():HierarchicalElement
Abbildung 12.9: Klasse HierarchicalElement
es die Methode propagateModification() auf, die alle angemeldeten Objekte benachrichtigt.
Abbildung 12.10 zeigt das zugeh¨
orige Sequenzdiagramm.
setValue()
propagateModification()
processModification()
processModification()
processModification()
listener 1 listener 2 listener nelement
Abbildung 12.10: Sequenzdiagramm f¨
ur den Benachrichtigungsmechanismus
Soll ein Objekt nicht weiter ¨
uber Ver¨
anderungen benachrichtigt werden, kann es dies ¨
uber
die Methode removeListener bekannt geben. Die restlichen Methoden sind f¨
ur das Elternele-
ment zust¨
andig, mit denen es gesetzt, gel¨
oscht und abgefragt werden kann.
Die Metadaten werden selbstverst¨
andlich ¨
uber die Klassen aus Abschnitt 11.2 verwaltet.
F¨
ur den Zugriff ¨
uber das Manifest wird die Klasse MDElement eingef¨
uhrt, die eine Spezialisie-
rung von HierarchicalElement ist. ¨
Uber ihre Methoden k¨
onnen Metadatenstrukturen mit
der Schnittstelle MetaData gesetzt und abgefragt werden, sodass keine direkte Verbindung zu
einem bestimmten Standard besteht. Abbildung 12.11 zeigt das entsprechende Diagramm.
setMetaData(md:MetaData)
clearMetaData()
getMetaData():MetaData
hasMetaData():Boolean
MDElement
{abstract}
HierarchicalElement
Abbildung 12.11: Klasse MDElement
Vier Elemente haben Bezeichner, ¨
uber die sie eindeutig identifiziert werden k¨
onnen. Hierf¨
ur
muss gew¨
ahrleistet sein, dass jeder Bezeichner eindeutig ist und im Falle einer Referenzierung
auch tats¨
achlich existiert. Da alle Elemente mit einem Bezeichner auch Metadaten haben
12.3 Manifest 141
k¨
onnen, kann die Klasse IDElement direkt von MDElement erben. Abbildung 12.12 zeigt das
zugeh¨
orige Klassendiagramm.
{abstract}
MDElement
setID(String)
adaptID()
IDElement
getID():String
getDefaultID():String
containsID():Boolean
#freeID()
#reserveID()
isUnique():Boolean
Abbildung 12.12: Klasse IDElement
Wenn ein Objekt mit den Eigenschaften der Klasse IDElement erzeugt wird, gibt es ver-
schiedene M¨
oglichkeiten, den Bezeichner zu bestimmen. Initial wird die Methode getDefaul-
tId() im Konstruktor aufgerufen und mit setID() gesetzt. Letztere Methode kann auch nach-
tr¨
aglich aufgerufen werden, um einen eigenen Bezeichner zu vergeben. Hierbei wird allerdings
keine Konsistenzpr¨
ufung durchgef¨
uhrt, sodass entweder durch das Pr¨
adikat isUnique() die
Eindeutigkeit best¨
atigt wird oder gleich mit adaptID() eine automatische Anpassung erfolgt.
Die ¨
Uberpr¨
ufung selbst ist keine triviale Angelegenheit, weil sie in einer hierarchischen
Struktur erfolgt. Aus diesem Grund gibt es zwei Methoden, die bei der Reservierung und
Freigabe von Bezeichnern unterst¨
utzend wirken. Mit reserveID() wird im gesamten Baum
bekannt gegeben, dass ein Element einen bestimmten Bezeichner f¨
ur sich beansprucht. Ob dies
¨
uberhaupt m¨
oglich ist, kann mit containsID() vorab ¨
uberpr¨
uft werden. Bei der Entfernung
eines Elements wird ¨
uber freeID() der Bezeichner freigegeben, damit er bei Bedarf neuen
Elementen zur Verf¨
ugung steht.
Eine weitere Aufteilung der gemeinsamen Eigenschaften auf allgemeine Klassen l¨
asst sich
nicht sinnvoll weiterf¨
uhren. Daher sollen nun die Klassen f¨
ur die konkreten Manifest-Elemente
hergeleitet werden. In umgekehrter Reihenfolge der entwickelten Basisklassen, also von ID-
Element zu HierarchicalElement, werden sie vorgestellt. Aus Tabelle 12.1 wird entnommen,
dass es genau vier Elemente mit Bezeichnern gibt, n¨
amlich item,manifest,organization
und resource. Abbildung 12.13 zeigt das entsprechende Klassendiagramm.
Die einzelnen Klassen zeigen bei Weitem nicht alle Methoden, denn zu spezielle Funkti-
onen und Attribute wurden ¨
ubersichtshalber ausgelassen. Aus dieser Vereinfachung darf freilich
nicht eine Irrelevanz f¨
ur die Implementierung gefolgert werden. Im Wesentlichen verwalten die
vier Klassen ihre Unterelemente, deren genauen Beziehungen sich gut in Abbildung 3.7 nach-
vollziehen lassen. Einige der Methoden bieten Zusatzfunktionen zur Umsetzung der Metaphern
an. Beispielsweise integriert flatten() alle Submanifeste in das oberste Manifest, sodass die
Umwandlung von verschachtelten Bausteinen zu flachen Content Packages vereinfacht wird.
Die Klasse File erbt direkt von MDElement, weil sie zwar Metadaten zu der jeweiligen
Datei anbietet, aber keinen Bezeichner erh¨
alt. Abbildung 12.14 zeigt das Klassendiagramm.
Intern nutzt diese Klasse eine URL zum Adressieren einer physikalische Datei. Neben
den Methoden zur Manipulation dieser Referenz bietet File das Pr¨
adikat isLocal() an, mit
dem ¨
uberpr¨
uft wird, ob die Datei Bestandteil des Content Packages ist. Diese Funktion ist
besonders f¨
ur die Datenhaltung von E-Learning-Inhalten wichtig, weil sie das Auffinden von
Abh¨
angigkeiten vereinfacht.
Das letzte Element ist dependency und dessen Klasse erbt direkt von der Hierarchical-
142 Baustein und Kurs
addItem(Item)
removeItem(Item)
decPosition()
incPosition()
setTitle(String)
clearTitle()
getItem(String):Item
getItem(int):Item
getItems():List
getItemCount():int
getTitle():String
Item
addFile(File)
removeFile(File)
addDependency(Dependency)
removeDependency(Dependency)
incPosition()
decPosition()
getFile(int):File
getFiles():List
getFileCount():int
getDependency(int):Dependency
getDependencies():List
getDependencyCount():int
Resource
getItem(String):Item
addItem(Item)
removeItem(Item)
decPosition()
incPosition()
setTitle(String)
clearTitle()
getItem(int):Item
getItems():List
getItemCount():int
getTitle():String
Organization
addManifest(Manifest)
removeManifest(Manifest)
addOrganization(Organization)
removeOrganization(Organization)
addResource(Resource)
removeResource(Resource)
incPosition()
decPosition()
flatten()
getManifest(String):Manifest
getManifest(int):Manifest
getManifests():List
getManifestCount():int
getOrganization(String):Organization
getOrganization(int):Organization
getOrganizations():List
getOrganizationCount():int
getResource(String):Resource
getResource(int):Resource
getResources():List
getResourceCount():int
Manifest
IDElement
Abbildung 12.13: Die Klassen Item,Manifest,Resource und Organization
setHref(String)
setHref(URL)
clearHref()
getHref():String
getFile():VirtualFile
hasHref():Boolean
isLocal()
MDElement
File
Abbildung 12.14: Klasse File
12.4 Content Package 143
Element. Sie enth¨
alt lediglich eine Referenz auf ein anderes Resource-Objekt, das f¨
ur eine
ordentliche Ausf¨
uhrung ben¨
otigt wird. Abbildung 12.15 zeigt das Klassendiagramm.
HierarchicalElement
Dependency
setResource(String)
setResource(Resource)
clearResource()
getResource():Resource
hasResource():Boolean
Abbildung 12.15: Klasse Dependency
Nun ist das OO-Binding vollst¨
andig und kann zur Erstellung und Bearbeitung von Ma-
nifesten genutzt werden. Die Klassenhierarchie in Abbildung 12.16 fasst die Ergebnisse dieses
Abschnitts zusammen.
Dependency
File
Item Manifest Organization Resource
MDElement
IDElement
Hierarchical Element
Abbildung 12.16: Klassenhierarchie der Manifest-Elemente
12.4 Content Package
Mit den Klassen f¨
ur die Speicherung der physikalischen Dateien und des Manifests sind die
Grundlagen f¨
ur die Modellierung des Content Packages gelegt. Weil bereits auf dieser Ebene
die Standardkompatibilit¨
at gew¨
ahrleistet ist, f¨
allt die folgende Klassenstruktur ¨
ubersichtlich
und kompakt aus. Im Grunde genommen sind die Klassen SavableFS und Manifest Aggregate
in einer kapselnden Klasse, die hier den Namen ContentPackage tr¨
agt. Abbildung 12.17 zeigt
die Komposition und die relevanten Methoden.
Die Schnittstelle setzt sich im Wesentlichen aus Methoden zusammen, die Aufrufe an Datei-
system und Manifest weiterleiten. Lediglich die Unterscheidung, ob es sich bei einem Content
Package um ein logisches Verzeichnis oder eine gepackte Datei handelt, wird in dieser Klas-
se verwaltet. Hierzu wird im Konstruktor der ¨
ubergebene Pfad ¨
uberpr¨
uft und das jeweilige
Objekt erzeugt. Ist dies bei einem Verzeichnis noch recht einfach, die Klasse VirtualFile bie-
tet entsprechende Methoden an, kann die Unterscheidung zwischen ZIP-, CAB- und anderen
Dateien aufwendiger sein. Das folgende Verfahren ist recht simpel und kann in der Imple-
mentierung durch ein effizienteres ersetzt werden. In der Regel erkennen die Klassen f¨
ur das
144 Baustein und Kurs
addFile(VirtualFile)
removeFile(VirtualFile)
readManifest()
writeManifest()
getManifest():Manifest
getFileSystem():SavableFS
getFile()
save()
save(VirtualFile)
merge()
hasFile():Boolean
isPIF():Boolean
isPackage():Boolean
isModified()
ContentPackage SavableFS
Manifest
Abbildung 12.17: Klasse ContentPackage
Einlesen eines bestimmten Dateityps, ob sie die Datei ordnungsgem¨
aß verarbeiten k¨
onnen. Ist
dies nicht der Fall, werfen sie eine Ausnahme (Exception), die abgefangen werden muss. Der
Reihe nach werden alle verf¨
ugbaren Klassen zum Lesen eines Content Packages aufgerufen,
bis die Operation erfolgreich durchgef¨
uhrt wurde. Schlugen alle Aufrufe fehl, dann wird das
Format nicht unterst¨
utzt oder die Datei ist fehlerhaft. Dieser Mechanismus kann noch ein
wenig verfeinert werden, indem z.B. die Dateiendungen ¨
uberpr¨
uft werden.
Eine sehr wichtige Funktion f¨
ur die Umsetzung der Metaphern stellt die Methode merge()
bereit, die eine Konvertierung von verschachtelten Content Packages zu einem mit mehre-
ren Submanifesten durchf¨
uhrt. Dies entspricht der Umwandlung eines Kurses aus Abbildung
12.3 zu einem Kurs aus Abbildung 12.2. Mit der Methode flatten() aus dem vorherigen
Abschnitt (siehe Abbildung 12.13) k¨
onnen die Submanifeste noch zu einem Manifest zusam-
mengefasst werden, sodass Kurse wie aus Abbildung 12.1 entstehen, die auch einfache Systeme
unterst¨
utzen.
Mit der Klasse ContentPackage k¨
onnen modulare E-Learning-Inhalte in standardkompa-
tiblen Formaten erstellt und bearbeitet werden. Jetzt gilt es, die Metapher Baustein explizit
anzuwenden, um die gew¨
unschte Modellierung zu erhalten. Abbildung 12.18 illustriert, wie die
Umsetzung eines Bausteins ¨
uber Vererbung realisiert ist.
setEntryPoint(VirtualFile)
clearEntryPoint()
addAuxililaryFile(VirtualFile)
removeAuxiliaryFile(VirtualFile)
getEntryPoint():VirtualFile
setEntryPoint(String)
getAuxiliaryFiles():List
getAuxiliaryFileCount():int
Brick
ContentPackage
Abbildung 12.18: Klasse Brick
Ein Baustein ist im Kontext dieser Arbeit die kleinste technische Einheit, die von der
Infrastruktur f¨
ur modulare E-Learning-Inhalte verarbeitet wird. Er enth¨
alt eine Datei als Ein-
stiegspunkt und mehrere zugeh¨
orige Dateien, die zur Darstellung notwendig sind. Die Schnitt-
stelle der Klasse Brick bietet f¨
ur die Erstellung und Bearbeitung verschiedene Methoden an,
12.4 Content Package 145
die intern auf die Methoden der Klasse ContentPackage abgebildet werden. Es wird somit
keine echte Funktionalit¨
at hinzugef¨
ugt, sondern der Blick aufs Wesentliche konzentriert. An-
statt beliebige Dateien in das Content Package zu kopieren, wird zwischen Einstiegspunkt
und Hilfsdateien unterschieden. Bei der Implementierung kann auch darauf geachtet werden,
dass alle anderen Elemente, wie z.B. Organisationen, ausgeschaltet sind. Letztendlich besitzt
die Klasse Brick eine ¨
uberschaubare Schnittstelle und die technischen Details sind in den
Basisklassen gekapselt.
Ein Kurs ist rekursiv definiert und beinhaltet andere Kurse und Bausteine. Diese flexible
Definition erlaubt den Aufbau beliebiger Strukturen, f¨
uhrt aber bei der Schnittstelle zu ei-
nem komplexeren Aufbau. Nicht alle Funktionen lassen sich direkt ¨
uber eine Klasse steuern,
weil auch hierarchische Datenstrukturen verwaltet werden. Dies ¨
andert freilich nichts an der
Vererbungshierarchie, wie Abbildung 12.19 verdeutlicht.
addCourse(Course, Item)
removeCourse(Course)
addBrick(Brick, Item)
removeBrick(Brick)
addOrganization(Organization)
removeOrganization()
getOrganizations():List
getCourses():List
getBricks():List
getCourseCount()
getBrickCount()
getOrganization(int):Organization
getMainOrganization():Organization
getOrganizationCount():int
ContentPackage
Course
Abbildung 12.19: Klasse Course
Die Methoden der Klasse Course unterst¨
utzen das Hinzuf¨
ugen und Entfernen von Baustei-
nen und Kursen. Wie schon bei der Klasse Brick ist die Schnittstelle eine spezialisierte Sicht
auf ein Content Package mit der Einschr¨
ankung, dass es nur Bausteine und Kurse anstatt phy-
sikalischer Dateien gibt. Abschließend zeigt Abbildung 12.20 die gesamte Klassenhierarchie f¨
ur
Content Packages.
Brick Course
SavableFS
Manifest
ContentPackage
Abbildung 12.20: Klassenhierarchie der Content Packages
Mit den Klassen Brick und Course sind die letzten Klassen beschrieben, die f¨
ur eine
Komponentenbildung notwendig sind. Sie sind es, deren Funktionen ¨
uber die Schnittstellen
der Komponenten Learning Object Engine (siehe Abbildung 10.11) und Structure Engine
(siehe Abbildung 10.12) angesprochen werden. In den Abbildungen 12.21(a) und 12.21(b) sind
die jeweiligen Prozess zu sehen, die wie gehabt nur ausgew¨
ahlte Klassen anzeigen.
Der wesentliche Unterschied zu den vorhergegangen Komponentenbildungen ist die Wie-
derverwendung einer ganzen Reihe von Klassen in zwei Komponenten. Dieser Sachverhalt
146 Baustein und Kurs
Brick
ContentPackage
Manifest
SavableFS
Learning Object
Engine
(a) Bildung der Komponente Learning Object Engi-
ne
ContentPackage
Manifest
SavableFS
Model
Structure Engine
(b) Bildung der Komponente Structure Engine
Abbildung 12.21: Komponentenbildung
verdeutlicht auf praktische Weise, warum es wenig ratsam ist, Komponenten zur physikali-
schen Gruppierung einzusetzen. In diesem Fall tr¨
ate eine unerw¨
unschte Redundanz auf, die
fachlich motiviert w¨
are, aber technisch nicht n¨
otig ist.
Kapitel 13
Rahmenwerk
Im zweiten Teil der Arbeit wurde am Anfang ein fachliches Modell f¨
ur den Umgang mit modu-
laren E-Learning-Inhalten aufgestellt, das am Ende in ein weit technischeres ¨
uberf¨
uhrt wurde.
Dieser Prozess ist noch nicht vollends abgeschlossen, denn es fehlen noch die Kompositionen
der entwickelten Basiskomponenten zu vollst¨
andigen Werkzeugen der einzelnen Rollen. Zudem
soll noch eine Zusammenfassung zu Libraries bzw. Paketen erfolgen, wie es in Kapitel 11 ein-
leitend angef¨
uhrt wurde. Erst in dieser Konstellation mit einer geeigneten Beschreibung der
API l¨
asst sich das entwickelte Gesamtmodell als Rahmenwerk nutzen.
Ohne eine genaue Definition eines Rahmenwerks zu geben und alle Aspekte dieses Themas
auszuloten, soll kurz eine Unterscheidung zwischen Rahmenwerk und Library gegeben werden.
Die wesentlichen Unterschiede lassen sich in der Nutzung ausmachen. Geht es bei Libraries
in erster Linie um die Zusammenfassung koh¨
arenter Klassen, die nach außen hin eine ein-
heitliche Schnittstelle bilden, steht beim Rahmenwerk die Erweiterung um eigene Funktionen
im Vordergrund. Nach dem Hollywood-Prinzip ”Don’t call us, we call you“ [Sweet85] werden
die hinzugef¨
ugten Unterklassen ¨
uber Nachrichten des Rahmenwerks aufgerufen. Dieses Prin-
zip wird in allen Klassen der erstellten Komponenten eingehalten. So lassen sich z.B. eigene
Dateisysteme, Metadaten und multimediale Erg¨
anzungen auf einfache Art hinzuf¨
ugen.
Obwohl die Begriffe Komponente, Library und Rahmenwerk im ersten Anschein wider-
spr¨
uchlich erscheinen, sind alle drei Betrachtungsweisen mit dem vorgestellten Entwurf rea-
lisierbar. Dies ist nur m¨
oglich, weil nicht dogmatisch Definitionen befolgt werden, die in der
Praxis wenig Bedeutung haben und kontraproduktiv sind. Im n¨
achsten Teil dieser Arbeit wird
eine Implementation vorgestellt, die auf die verschiedenen Weisen eingesetzt werden kann.
Die fertigen Komponenten lassen sich mit wenig Aufwand zu vollst¨
andigen Anwendungen zu-
sammensetzen oder erg¨
anzen Eigenentwicklungen um spezielle Funktionalit¨
aten. Wird mehr
Kontrolle gew¨
unscht, lassen sich Teile der API wie eine Library ansprechen, mit denen sich
umfangreiche Eigenentwicklungen hochziehen lassen. Erst wenn spezielle Erweiterungen be-
n¨
otigt werden, die entweder zu exotisch waren, um sie in die Implementierung aufzunehmen,
oder sich zu einem sp¨
ateren Zeitpunkt etablierten, kommt der Charakter eines Rahmenwerks
zum Vorschein. Es sei an dieser Stelle abermals darauf hingewiesen, dass der bisherige Entwurf
unabh¨
angig von jeglicher Programmiersprache ist.
Im n¨
achsten Abschnitt werden nun die letzten drei Komponenten der Entwurfsphase er-
stellt. Dieser Prozess entspricht dem Muster der Erstellung einer Fassade, wie in Abbildung
13.1 illustriert ist.
Diese Architektur verdeckt die Kommunikation und Abh¨
angigkeiten unter den einzelnen
Teilkomponenten und bietet eine vereinfachte, einheitliche Schnittstelle nach außen. Die nun
entstehenden Komponenten bieten somit keine neue Funktionalit¨
at, wodurch der Erstellungs-
prozess sehr einfach gehalten ist.
148 Rahmenwerk
Facade
client classes
subsystem classes
Abbildung 13.1: Das Muster Fassade [Gamma95, S. 185]
13.1 Zusammengesetzte Komponenten
Nach Tabelle 10.1 fehlen im Bereich des Entwurfs noch die zwei zusammengesetzten Kom-
ponenten Learning Object Development (siehe Abbildung 10.11) und Structure Develop-
ment (siehe Abbildung 10.12). Die Komponente Publishing Environment (siehe Abbildung
10.13) wird, wie in der Tabelle angegeben, in anderen Arbeiten ausf¨
uhrlich beschrieben und
soll an dieser Stelle als gegeben betrachtet sein.
Die Rolle Developer benutzt die Komponenten Multimedia Environment,Import Engi-
ne und Learning Object Engine zur Erstellung sowie Bearbeitung modularer E-Learning-
Inhalte. Bis auf die Import Engine wurde in den letzten Kapiteln die Herleitung und Funk-
tionalit¨
at dieser Komponenten beschrieben, sodass sie keiner weiteren Erkl¨
arung bed¨
urfen.
Auch ihr Zusammenspiel ist nicht sonderlich kompliziert. Grundlage f¨
ur den Umgang mit
standardkompatiblen Lernobjekten ist die Learning Object Engine, sei es nun beim Import
fremder Inhalte oder der Bearbeitung enthaltender Multimedia-Dateien. Letztendlich m¨
ussen
f¨
ur das Zusammenspiel ein paar Initialisierungen und Abh¨
angigkeiten bei den gegenseitigen
Aufrufen beachtet werden, die von einer neuen Klasse ¨
ubernommen werden. Ihre Schnittstelle
bietet weitestgehend die gleiche Funktionalit¨
at wie die Einzelkomponenten an, weshalb auf
eine ausf¨
uhrliche Beschreibung verzichtet wird. Die wesentliche Struktur ist Abbildung 13.2
zu entnehmen.
Import Engine Learning Object
Engine
Multimedia
Environment
LOBDevelopment
Abbildung 13.2: Bildung der Komponente LOBDevelopment
Mit der Klasse LOBDevelopment bekommen die Entwickler/-innen eine einheitliche Schnitt-
stelle an die Hand, mit der sich auf einfache Weise eigene Erweiterungen, wie z.B. eine grafische
Repr¨
asentation oder ein Kommandozeilenprogramm, erstellen lassen. Die bisher eingesetzte
Komponentenbildung, wie z.B. in Abbildung 12.21 dargestellt, wird aufgrund der Trivialit¨
at
des Prozesses — schließlich wird nur die Klasse LOBDevelopment hinzugef¨
ugt — an dieser
Stelle nicht angef¨
uhrt. Das Endresultat ist aus Abbildung 10.11 bekannt.
Auch bei den T¨
atigkeiten der Rolle Composer werden haupts¨
achlich drei Komponenten ein-
gesetzt, namentlich als Import Engine,Search Engine und Structure Engine vorgestellt.
13.1 Zusammengesetzte Komponenten 149
Letztere ist die zentrale Komponente, beschrieben im vorherigen Kapitel. Egal ob nun frem-
de Inhalte importiert werden, oder eine Aufarbeitung bestehender Lerninhalte f¨
ur die Suche
erfolgt. Es wird stets der Zugriff auf die internen Strukturen und die inhaltlichen Zusam-
menh¨
ange ben¨
otigt. Die Komponente CBK-Management-Application aus der Diplomarbeit
[Vollmann04] wird als Search Engine verwendet, die nach dem Verfahren Case-Based Rea-
soning (CBR) arbeitet [Kolodner93; Lenz98]. Abbildung 13.3 zeigt den inneren Aufbau. Wer
Interesse an der umfangreichen Schnittstelle hat, findet in der Diplomarbeit eine ausf¨
uhrliche
Beschreibung.
Module
Keyword
Association
View
Language
CBK−Management−Application
Abbildung 13.3: Aufbau der Komponente CBK-Management-Application nach [Vollmann04,
S. 128]
Die Initialisierungen und Abh¨
angigkeiten unter den Komponenten werden wieder ¨
uber das
Entwurfsmuster Fassade gekapselt, um einen einfachen Zugriff zu erm¨
oglichen. Abbildung 13.4
zeigt die hierf¨
ur eingef¨
uhrte Klasse. StructureDevelopment.
Structure EngineSearch EngineImport Engine
StructureDevelopment
Abbildung 13.4: Bildung der Komponente StructureDevelopment
Auf die Darstellung einer expliziten Komponentenbildung soll wiederum verzichtet werden,
denn auch hier ist das Endresultat aus Abbildung 10.12 bekannt.
Nun sind alle Komponenten erstellt, mit denen gr¨
oßere oder kleinere Aufgaben im Bereich
modularer E-Learning-Inhalte ¨
ubernommen werden k¨
onnen. Es lassen sich Lernobjekte als
Bausteine erstellen sowie bearbeiten, mit anderen Lernobjekten zu Kursen zusammensetzen
und in jedes beliebige Ausgabeformat ¨
uberf¨
uhren. Alle beteiligten Funktionen stehen in den
drei Komponenten Learning Object Development,Structure Development und Publis-
hing Environment zur Verf¨
ugung, doch der Zusammenhang zwischen ihnen fehlt. Mit Hilfe
einer Komponente soll quasi die Funktionalit¨
at einer vollst¨
andigen Applikation angeboten wer-
150 Rahmenwerk
den. Es wird wieder nach dem Muster Fassade verfahren, dessen Resultat in Abbildung 13.5
zu sehen ist.
Structure
Development
Learning Object
Development Publishing
Environment
AuthoringSystem
Abbildung 13.5: Bildung der Komponente AuthoringSystem
Die Klasse AuthoringSystem kapselt die Initialisierungen und k¨
ummert sich um Abh¨
an-
gigkeiten. Zus¨
atzlich erlaubt sie die Steuerung der Konfiguration ¨
uber Umgebungsvariablen
und spezielle Dateien. Auf diese Weise l¨
asst sich das Verhalten der Anwendung ohne Program-
mierung steuern, sodass im optimalen Fall f¨
ur den Einsatz dieser Komponente keine Entwick-
lungsarbeit notwendig ist. Freilich kann es sich hierbei nur um rudiment¨
are T¨
atigkeiten ohne
Interaktion mit den Anwendern/-innen handeln.
Der Entwurf ist jetzt so weit, dass die n¨
achsten Entwicklungsschritte nur noch in Abh¨
angig-
keit von Programmiersprachen, Libraries und Betriebssystemen sinnvoll vorangetrieben wer-
den k¨
onnen. Hier endet nun die kreative Arbeit und geht ¨
uber in T¨
atigkeiten, die zunehmend
von konkreten Erfahrungen gepr¨
agt sind. So wird beispielsweise Wissen ben¨
otigt, wie sich
grafische Oberfl¨
achen am elegantesten zusammenstellen lassen, wie Ressourcen des Rechners
m¨
oglichst effizient genutzt werden und wie sich Programmieraufwand reduzieren l¨
asst. Diese
¨
Uberlegungen passen nicht in einen unabh¨
angigen Entwurf, weshalb nun zur Implementierung
¨
ubergegangen wird.
Teil III
Implementierung
Kapitel 14
Baukasten
Im vorherigen Teil dieser Arbeit wurden die fachlichen Klassen und Komponenten entwickelt,
die f¨
ur die technische Kodierung und Bearbeitung modularer E-Learning-Inhalte ben¨
otigt
werden. Sie sind weitestgehend unabh¨
angig von jeglichen Programmiersprachen und sonstigen
Implementierungsdetails. Aus Sicht der Entwickler/-innen ist eine API entstanden, die eine
gute Basis f¨
ur die Erstellung eigener Anwendungen darstellt. In Anbetracht der Zielsetzung
dieser Arbeit muss aber noch ein Schritt weitergegangen werden, denn es soll eine komplette
Infrastruktur geschaffen werden, nicht nur ein konzeptioneller Entwurf. Was also fehlt, ist die
grafische Darstellung (View), um das MVC-Muster zu vervollst¨
andigen. Sie ist stark von der
Implementierung abh¨
angig und deshalb in diesem Teil der Arbeit untergebracht, obwohl auch
hier ¨
uberwiegend konzeptionelle ¨
Uberlegungen angef¨
uhrt werden.
Da bis jetzt lediglich die Daten modelliert sind, n¨
amlich Bausteine, Kurse und ihre Meta-
daten, sollen nun die passenden Werkzeuge entwickelt werden. Hierbei handelt es sich um die
Komponenten aus Abschnitt 10.2, die nun zu einer prototypischen Anwendung zusammenge-
setzt werden.
F¨
ur die Programmiersprache Java gibt es verschiedene Libraries, die bei der Erstellung
grafischer Oberfl¨
achen helfen. Implementierungen der Virtual Machine von Java unterst¨
utzen
in der Regel die Standard-Libraries Abstract Window Toolkit (AWT) und Swing. Sie m¨
ussen
im Gegensatz zu den Alternativen, wie z.B. das Standard Widget Toolkit (SWT) des Projekts
Eclipse1, nicht zus¨
atzlich installiert werden. Das AWT ist die ¨
alteste Library und bietet wenig
Komfort, da lediglich wenige Standardkomponenten direkt angeboten werden. B¨
aume, Tabel-
len und weitere komplexere Widgets stehen erst in Swing zur Verf¨
ugung, das intern auf dem
AWT aufbaut. Im Gegensatz zu AWT und SWT sind die Widgets unabh¨
angig vom Betriebs-
system, da sie als Lightweight Components realisiert sind, sich also selbst in eine vorgegebene
Fl¨
ache zeichnen. Heavyweight Components basieren hingegen auf den Widgets nativer Libraries
oder dem Betriebssystem und ben¨
otigen unter Umst¨
anden mehr Ressourcen zur Ausf¨
uhrung.
Die Entscheidung in dieser Arbeit f¨
allt zu Gunsten von Swing aus, weil es einen Kom-
promiss zwischen der Verf¨
ugbarkeit bei Standardinstallationen und der Anzahl von Widgets
darstellt. Das AWT steht wegen seines Alters und des wenig durchdachten Entwurfs — die
Entwickler beteuern selbst, dass es am Zeitdruck bis zur ersten Ver¨
offentlichung von Java lag
— außen vor. Bei dem SWT sieht es mit der Verf¨
ugbarkeit und der Stabilit¨
at heute wesent-
lich besser aus, als zu Beginn des Projekts mαth-kit, sodass Der Vorzug von Swing historisch
bedingt ist.
In den folgenden Abschnitten werden die grafischen Komponenten hergeleitet, mit denen
Bausteine sowie Kurse erstellt, bearbeitet und konvertiert werden. Wie in dem Teil Entwurf,
werden erst die Basisfunktionen Dateizugriff und Metadaten angegangen, um anschließend die
Komponenten f¨
ur die Rollen Developer,Composer und Publisher fertig zu stellen.
1Eclipse ist eine offene flexible Plattform f¨
ur die Integration von Entwicklungswerkzeugen. Die grafische
Oberfl¨
ache basiert auf dem SWT. Mehr Details finden sich unter http://www.eclipse.org (29.10.05)
154 Baukasten
14.1 Script-Steuerung
F¨
ur eine direkte Ansteuerung ohne aufw¨
andige Programmierung soll eine Komponente zur
Script-Ansteuerung angeboten werden. Mit ihr lassen sich kleinere Routinet¨
atigkeiten elegant
erledigen, ohne jedes Mal aufw¨
andig programmieren zu m¨
ussen. F¨
ur die Anwender/-innen
bieten Script-Sprachen den idealen Kompromiss zwischen direkter Kontrolle und komplizier-
ten Aufrufen von Komponenten. Die Position der Komponente Scripting Environment im
Autorensystem kann in Abbildung 10.17 nachvollzogen werden.
Java ist eine stark typisierte Programmiersprache, was nichts anderes bedeutet, als dass
der Quellcode ¨
ubersetzt wird und w¨
ahrend dieses Prozesses einer Pr¨
ufung der Typkonsistenz
erfolgt. Passen irgendwelche Datentypen nicht zusammen, wird die ¨
Ubersetzung mit einer
entsprechenden Fehlermeldung abgebrochen. Dieses Konzept ist freilich schwer mit Script-
Sprachen zu kombinieren, da sie in der Regel erst zur Laufzeit interpretiert werden. Es ist z.B.
durchaus ¨
ublich, dass eine Variable im gleichen Geltungsbereich verschiedene Typen annimmt.
In Java ist dies nicht m¨
oglich, doch wie lassen sich diese beiden Welten vereinen?
Klassische Script-Sprachen wie TCL2, Perl3oder gar PHP4sind imperativ und kommen
f¨
ur diese Aufgaben freilich nicht in Frage, denn sie lassen sich nur sehr schwer oder gar nicht
mit Java verbinden. Eine objektorientierte Script-Sprache wie Python5ist da wesentlich besser
geeignet und es gibt interessante Implementierungen auf dem Markt. Herausragend ist z.B. der
Interpreter Jython6, der vollst¨
andig in Java umgesetzt wurde und eine nahtlose Verbindung
zwischen Python und Java schafft. Aus technischer Sicht scheint dieser Ansatz eine gangbare
L¨
osung zu sein.
Bei genauer Betrachtung von Python zeigt sich, dass es sich um eine vollst¨
andige Program-
miersprache handelt, deren Merkmale z.B. Module, Klassen, Exceptions und h¨
ohere Daten-
typen sind. Nun unterscheidet sich die Syntax zu Java teilweise wesentlich und wer Python
nicht kennt, hat einen gewissen Lernaufwand zu leisten. Bei den vielen Projekttreffen von
mαth-kit hat sich deutlich herausgestellt, dass der gr¨
oßte Teil der Partner/-innen im Umgang
mit Java vertraut ist bzw. sich in diese Richtung weiterbildet. Die Bereitschaft, eine weitere
Programmiersprache zu erlernen, war verst¨
andlicher Weise gering. Aus diesem Grund ist die
Entscheidung auf die BeanShell7gefallen, einen Interpreter speziell f¨
ur Java. Die Syntax dieser
Script-Sprache ist stark an Java angelehnt, wie das Beispiel in Abbildung 14.1 zeigt.
Es wird ein neuer Baustein erzeugt und der Bezeichner der Ressource ausgegeben. Weil
die BeanShell kompakt ist und bereits mit einer eigenen grafischen Oberfl¨
ache ausgestattet
ist, m¨
ussen keine weiteren Entwicklungsschritte vorgenommen werden, um die Komponente
Scripting Environment aus Abbildung 10.17 zu erstellen. Lediglich bei der Initialisierung der
BeanShell werden ein paar n¨
utzliche Objekte in den Scope8geladen, wie z.B. das speziel-
le Dateisystem. Dies reduziert den Aufwand f¨
ur neu entwickelte Scripte, weil alle wichtigen
Komponenten im direkten Zugriff vorliegen.
14.2 Grafische Basiskomponenten
In Kapitel 11 wurden die funktionalen Klassen f¨
ur den Zugriff auf Dateien und Metadaten
definiert. Nun werden sie um eine grafische Repr¨
asentation erg¨
anzt, um sie als Komponenten
leichter wieder verwenden zu k¨
onnen. Bei der Darstellung eines Dateisystems gibt es zwei we-
sentliche Ans¨
atze mit kleinen Varianten. Entweder erfolgt die Anzeige als Baum oder Liste,
was verschiedene Vor- und Nachteile mit sich bringt. Beim Baum profitieren die Anwender/-
2http://www.tcl.tk (29.10.05)
3http://www.perl.org (29.10.05)
4http://www.php.net (29.10.05)
5http://www.python.org (29.10.05)
6http://www.jython.org (29.10.05)
7http://www.beanshell.org (29.10.05)
8Mit Scope wird der Bereich bezeichnet, in dem eine Variable definiert ist.
14.2 Grafische Basiskomponenten 155
Abbildung 14.1: Screenshot der BeanShell
innen von einer guten Gesamt¨
ubersicht und sie erreichen schnell die gew¨
unschten Dateien,
auch wenn mehrere Verzeichnisse gleichzeitig ge¨
offnet sind. Diese Datenf¨
ulle gereicht der Ge-
schwindigkeit dieser Darstellung aber zum Nachteil, denn es m¨
ussen einige Informationen aus
dem Dateisystem gesammelt werden. Angefangen bei der Unterscheidung von Dateien und
Verzeichnissen, ¨
uber Dateiattribute bis hin zu den grafischen Icons erh¨
ohen viele Operationen
die Belastung. Hinzu kommt ein ¨
Uberwachungsmechanismus zur Aktualisierung der Darstel-
lung, wenn von Dritten ¨
Anderungen im Dateisystem erfolgen. Auf dem lokalen Dateisystem
des Betriebssystems mag eine ad¨
aquate Geschwindigkeit noch gegeben sein, aber sp¨
atestens
bei einem Dateisystem im Netzwerk oder tief verschachtelten Content Packages sind massive
Verz¨
ogerungen m¨
oglich.
Die Darstellung als Liste ist von diesen Probleme weniger betroffen, weil lediglich der
Inhalt eines Verzeichnisses angezeigt wird. Die Anzahl der Dateien und Verzeichnisse h¨
alt sich
somit in Grenzen. Bei der gleichzeitigen Arbeit mit vielen Verzeichnissen wirkt sich die Liste
nachteilig aus, denn entweder wird oft die Ansicht gewechselt oder es werden mehrere Listen
nebeneinander ge¨
offnet. Es sei an dieser Stelle nicht verschwiegen, dass bei sehr vielen Dateien
in einem Verzeichnis auch die Liste vor Verz¨
ogerungen nicht gefeit ist.
Die Darstellung von B¨
aumen und Listen l¨
asst sich beschleunigen, indem sie in mehrere
Schritte aufgeteilt wird. Zun¨
achst werden alle Namen der Dateien und Verzeichnisse abgefragt,
um sie danach sofort anzuzeigen. Danach werden die Eintr¨
age von einem Prozess oder Thread
im Hintergrund um weitere Attribute erg¨
anzt. Der Vorteil dieser ”dynamischen“ Darstellung
liegt auf der Hand: Die Anwender/-innen bekommen den Inhalt des Dateisystems schneller
angezeigt und haben sofort Zugriff auf die Dateien. Wer sich an kleinen Icons und anderen
Eigenschaften orientieren m¨
ochte, muss die ben¨
otigte Wartezeit in Kauf nehmen.
In Anbetracht der Aufgabenstellung ist die Liste die geeignetere Darstellungsform f¨
ur
Dateisysteme, denn es sollen in erster Linie die Inhalte von Bausteinen und Kursen angezeigt
werden, die meist eine flache Struktur haben. Deswegen wird in dieser Arbeit die grafische
Komponente verwendet, wie sie in Abbildung 14.2 zu sehen ist.
In diesem Screenshot wird der Inhalt des Verzeichnisses Eigene Dateien angezeigt, der aus
drei Verzeichnissen besteht. Die Anzeige des aktuellen Verzeichnisses ist eine Combobox, die
alle h¨
oher liegenden Verzeichnisse anzeigt und einen Aufstieg im Verzeichnisbaum erm¨
oglicht.
¨
Uber einen Doppelklick auf einen Verzeichnisnamen wird dessen Inhalt angezeigt, was einem
Abstieg im Verzeichnisbaum entspricht. Mit den ersten beiden Kn¨
opfen in der rechten oberen
Ecke kann direkt zu oft genutzten Verzeichnissen gesprungen werden und mit dem letzten wird
ein neues Verzeichnis angelegt.
156 Baukasten
Abbildung 14.2: Visualisierung physikalischer Dateien in Content Packages
Die Entwicklung einer grafischen Komponente f¨
ur Metadaten ist aufgrund ihrer Kom-
plexit¨
at umfangreich und wurde im Projekt mαth-kit als Diplomarbeit [Turan04] vergeben.
Ausgangspunkt waren die Klassen f¨
ur Metadaten aus Abschnitt 11.2, deren Elemente und
Attribute auf geeignete Weise visualisiert werden mussten. Das Ergebnis ist in Abbildung 14.3
zu sehen.
Abbildung 14.3: Komponente f¨
ur Metadaten
F¨
ur die Unterteilung der einzelnen Kategorien wurden Reiter gew¨
ahlt, deren Seiten den ge-
samten Inhalt anzeigen. Ohne zu sehr in die Details gehen zu wollen, l¨
asst sich aus Abbildung
14.3 gut die Vorgehensweise bei der Umsetzung nachvollziehen. Zuerst wurden f¨
ur alle Daten-
typen der Metadatenbeschreibung die passenden Widgets festgelegt und bei Bedarf angepasst.
W¨
orterb¨
ucher lassen sich beispielsweise gut als Comboboxen umsetzen, wie bei den Elementen
Structure und Aggregationlevel zu sehen ist. Mehrsprachige Daten, die sich aus einem
Sprachk¨
urzel und dem Text zusammensetzen, sind in Tabellen gut aufgehoben. Um doppelte
Eintr¨
age von vornherein zu vermeiden, lassen sich die Sprachk¨
urzel in der Spalte Language nur
¨
uber eine Combobox ausw¨
ahlen, die alle unterst¨
utzten Sprachen enth¨
alt. Diese Tabelle l¨
asst
sich f¨
ur viele Elemente anwenden, wie die sichtbaren Elemente Title und Description be-
weisen. Es gibt auch Datentypen, die sich nicht in vorhandenen Widgets darstellen lassen, wie
z.B. die Datumsauswahl oder die VCards, und eigene Implementierungen ben¨
otigen. Genaue
Ausf¨
uhrungen hier¨
uber finden sich in der genannten Diplomarbeit.
14.3 Rahmenwerk f¨
ur Werkzeuge 157
14.3 Rahmenwerk f¨
ur Werkzeuge
Bevor mit den eigentlichen Komponenten f¨
ur Bausteine und Kurse begonnen wird, soll ein
kleines Rahmenwerk geschaffen werden, dass ihren Aufbau und Einsatz vereinfacht. In einer
Anwendung f¨
ur modulare E-Learning-Inhalte ist es praktisch, mehrere Bausteine und Kurse
zur gleichen Zeit ge¨
offnet zu haben. Dies bedeutet jedoch f¨
ur alle Implementierungen einen
zus¨
atzlichen Aufwand, der ein tieferes Verst¨
andnis der gesamten Klassenstruktur voraussetzt.
Um potentiellen Entwicklern/-innen den Einstieg zu vereinfachen, sollen daher f¨
ur typische
Konstruktionen vorgefertigte Klassen angeboten werden, die eine Integration in die eigene
Anwendung vereinfachen.
Besonders die Verschachtelung von Kursen stellt eine Herausforderung bei der Visualisie-
rung dar. Ein einfacher Baum, der sonst bei hierarchischen Strukturen zum Einsatz kommt,
ist nicht geeignet, da sich die Inhalte der Bausteine und Kurse nur schwer als Bl¨
atter umset-
zen lassen. Hinzu kommen die vielen M¨
oglichkeiten zur Platzierung von Metadaten und wie
Abbildung 14.3 deutlich zeigt, ist die Komponente in ihren Ausmaßen nicht klein.
In einem ersten Prototyp f¨
ur das Projekt mαth-kit wurde jeder Baustein und Kurs in einem
eigenen Fenster angezeigt, auch wenn es sich um verschachtelte Inhalte handelte. Die Bezugs-
losigkeit der Fenster untereinander ist an dieser Form besonders gravierend, denn auf den
ersten Blick ist nicht mehr ersichtlich, welche von ihnen zusammen geh¨
oren. Daher muss eine
bessere Darstellung gefunden werden, die einen n¨
aheren Bezug zur Verschachtelung besitzt.
Zun¨
achst l¨
asst sich feststellen, dass Bausteine, Kurse und Metadaten nach der Erstellung
bzw. Bearbeitung entweder verworfen oder gespeichert werden k¨
onnen. Hierf¨
ur erbt die Klasse
JSavablePanel von der Swing-Klasse JPanel und stellt verschiedene Actions zur Verf¨
ugung,
wie in Abbildung 14.4 zu sehen ist.
JSavablePanel
setModified(Boolean)
save(VirtualFile)
save()
JPanel
showCancelDialog()
getFile():VirtualFile
getSaveAction():Action
getCancelAction():Action
isModified():Boolean
Abbildung 14.4: Klasse JSavablePanel
Bei einer Action handelt es sich um einen Steuerungsbefehl, der von Kn¨
opfen oder Men¨
uein-
tr¨
agen abgeschickt wird, sodass eine Ansteuerung des JSavablePanel von außen m¨
oglich ist.
Zus¨
atzlich k¨
onnen Objekte dieser Klasse mit isModified() ¨
uberpr¨
ufen, ob sich ihr Inhalt ver-
¨
andert hat. Soll das Objekt geschlossen werden und es wurde modifiziert, dann geht automa-
tisch ein Dialog auf, der auf den m¨
oglichen Datenverlust hinweist und explizit eine Best¨
atigung
verlangt. Auf diese Weise gehen nicht ungewollt Daten verloren.
F¨
ur die Verwaltung der Verschachtelungen soll eine eigene Klasse zust¨
andig sein, die meh-
rere Objekte von JSavablePanel aufnehmen kann. Abbildung 14.5 gibt eine schematische
Ansicht.
Es sind vier verschiedene Ebenen mit verschachtelten Inhalten, die ¨
ubersichtshalber ver-
setzt dargestellt sind. Beispielsweise ist Panel 4 in Panel 3 enthalten und Panel 3 in Panel
2. Im Moment kann nur auf Panel 4 gearbeitet werden, bis eine andere Ebene ausgew¨
ahlt
wird. F¨
ur die Navigation ist auf dem Panel 1 eine Combobox angebracht, mit der auf h¨
oher
liegende Ebenen zugegriffen wird. Bei der Auswahl, z.B. von Panel 2, werden Panel 4 und
158 Baukasten
Panel 1
Panel 2
Panel 1
Panel 2
Panel 3
Panel 4 Panel 3
Panel 4
Abbildung 14.5: Verschachtelte Inhalte
Panel 3 geschlossen. Bevor dies geschieht, werden diese selbstverst¨
andlich auf ¨
Anderungen
gepr¨
uft, um eine Speicherung zu erm¨
oglichen.
Um das Beispiel weniger abstrakt zu halten, kann auch der Inhalt von Panel 4 als Baustein
angenommen werden, der in einem anderen Kurs, dargestellt auf Panel 3, enthalten ist. Die
Ebenen Panel 2 und Panel 1 m¨
ussen selbstverst¨
andlich ebenfalls f¨
ur Kurse stehen.
Bei der Klasse JNestedPanel handelt es sich um eine Spezialisierung der Klasse JSavable,
wie in Abbildung 14.6 dargestellt.
getPanels():List
getPanelCount():int
getPanel(int):JSavablePanel
addPanel(JSavablePanel)
removePanel(JSavablePanel)
jumpToPanel(int)
JSavablePanel
JNestedPanel
Abbildung 14.6: Klasse JNestedPanel
Hauptaufgabe der Klasse ist die Verwaltung der Ebenen. Mit den Methoden addPanel()
und removePanel() werden Objekte der Klasse JSavablePanel hinzugef¨
ugt bzw. entfernt. Bei
der Auswahl einer anderen Ebene in der Combobox wird jumpToPanel() aufgerufen, woraufhin
alle Ebenen zwischen der aktuellen und der ausgew¨
ahlten geschlossen werden. Ansonsten w¨
are
die Navigation in der Combobox inkonsistent.
Metadaten k¨
onnen ebenfalls auf verschiedenen Ebenen auftreten, sodass es sinnvoll ist, die-
se Komponente aus Abbildung 14.3 in den Mechanismus zu integrieren. Als Spezialisierung der
Klasse JSavablePanel bettet sich die Darstellung und Speicherung der Metadaten nahtlos ein.
Da keine neuen Funktionen hinzugef¨
ugt werden, soll an dieser Stelle auf ein Klassendiagramm
verzichtet werden.
Bei vielen gleichzeitig ge¨
offneten Bausteinen und Kursen bietet sich die Darstellung meh-
rerer Fenster in einem Hauptfenster an, die auch als Multiple Document Interface (MDI) be-
zeichnet wird. Swing sieht hierf¨
ur die zwei Klassen JDesktopPane und JInternalFrame vor,
mit denen solche Anwendungen schnell erstellt sind. Um das Rahmenwerk auch f¨
ur diese Form
auszurichten, wird es um die Klassen JSavableInternalFrame und JNestedInternalFrame
erg¨
anzt. Sie nehmen die Panels des Rahmenwerks auf und steuern die Kommunikation. Abbil-
dung 14.7 zeigt die vollst¨
andige Vererbungshierarchie, um die beschriebenen Zusammenh¨
ange
zu verdeutlichen.
14.4 Visualisierung der Bausteine und Kurse 159
JNestedPanel JMDPanel
JSavablePanel
JPanel
JSavableInternalFrame
JNestedInternalFrame
JInternalFrame
Abbildung 14.7: Klassenhierarchie der grafischen Basisklassen
14.4 Visualisierung der Bausteine und Kurse
In diesem Abschnitt werden grafische Komponenten f¨
ur die Erstellung und Bearbeitung von
Bausteinen und Kursen hergeleitet. Sie visualisieren die Funktionen der Komponenten Lear-
ning Object Engine aus Unterabschnitt 10.2.2 und Structure Engine aus Unterabschnitt 10.2.3.
Zuerst wird eine allgemeine Klasse JCPPanel f¨
ur Content Packages definiert, die interne Ver-
waltungsaufgaben ¨
ubernimmt und noch keine Visualisierung der Inhalte durchf¨
uhrt, denn diese
ist in spezialisierte Klassen ausgelagert. Abbildung 14.8 zeigt das Klassendiagramm.
JNestedPanel
JCPPanel
showSaveDialog()
showExportDialog()
showManifest()
getExportAction():Action
getPreviewAction():Action
Abbildung 14.8: Klasse JCPPanel
JCPPanel erlaubt ¨
uber die Methode showSaveDialog() die Auswahl einer bestimmten
Datei, in die der Baustein oder Kurs als Content Package gespeichert wird. Nach erfolgreicher
Bestimmung einer Datei wird die Methode save() der Klasse JSavablePanel aufgerufen. Hin-
ter den Methoden showExportDialog,getExportAction() und getPreviewAction verbergen
sich Aufrufe f¨
ur Werkzeuge der Rolle Publisher, deren Funktionalit¨
at im n¨
achsten Abschnitt
erl¨
autert wird. An dieser Stelle soll gen¨
ugen, dass mit dem Export-Dialog Bausteine und Kurse
in andere Formate ¨
ubersetzt werden. In der Regel handelt es sich beim Quellformat um XML
und bei dem Zielformat um HTML oder PDF. Die Methode showManifest() ¨
offnet ein neues
Fenster, in dem das in XML kodierte und formatierte Manifest zu sehen ist. Abbildung 14.9
zeigt eine typische Darstellung, in der die Organisation mit ihren Eintr¨
agen und Verweisen auf
die Referenzen gut zu sehen ist.
Jetzt sind die Voraussetzungen f¨
ur die Visualisierung von Bausteinen und Kursen gelegt.
Die resultierenden Klassen bieten keine neue Funktionalit¨
at an, da sie praktisch eine einge-
schr¨
ankte, auf das Wesentliche reduzierte Darstellung allgemeiner Content Packages sind. Aus
diesem Grund wird auf entsprechende Klassendiagramme verzichtet und die interessantere Ge-
staltung der Komponenten diskutiert. Abbildung 14.10 zeigt zun¨
achst die Bausteinkomponente
mit einem ge¨
offneten Beispiel.
Im unteren Teil der Komponente ist die Dateisystemkomponente eingebettet, in der die
physikalischen Dateien des Content Packages zu sehen sind. Neben den vier Dateien ist auch
ein Verzeichnis mit dem Namen data enthalten. Welche Dateien darin liegen, soll an dieser
160 Baukasten
Abbildung 14.9: Manifest mit farblicher Syntax-Hervorhebung
Abbildung 14.10: Komponente f¨
ur Bausteine
14.4 Visualisierung der Bausteine und Kurse 161
Stelle nicht interessieren, vielmehr soll die m¨
ogliche Strukturierung der Dateien innerhalb eines
Bausteins verdeutlicht werden. Obwohl mit Verzeichnissen in Bausteinen sparsam umgegangen
werden soll, ist ihre Verwendung bei sehr vielen Dateien sinnvoll. In der oberen Combobox mit
der Beschriftung ”Start File“ ist die Datei mkml.xml als Einstiegspunkt f¨
ur diesen Baustein
festgelegt. Alle anderen Dateien des Bausteins werden von ihr referenziert und nie direkt aufge-
rufen. Die Metadaten f¨
ur diesen Baustein werden ¨
uber die Metadatenkomponente eingegeben,
die ¨
uber einen Klick auf den Knopf ”Meta Data“ als neue Ebene eingeblendet wird.
Durch die Dateisystemkomponente ist die Arbeit mit den enthaltenen Dateien sehr ein-
fach. Neue Dateien werden ¨
uber ein Kontextmen¨
u neu erzeugt oder per Drag’n’Drop von außen
hinzugef¨
ugt. F¨
ur die Bearbeitung stehen je nach Datentyp unterschiedliche Operationen be-
reit, die externe Programme aufrufen. Zur besseren Strukturierung der physikalischen Dateien
k¨
onnen zus¨
atzlich Unterverzeichnisse angelegt werden.
Die Visualisierung der Kurse ist im Gegensatz zu den einfachen Bausteinen etwas um-
fangreicher, denn neben den physikalischen Dateien m¨
ussen auch Ressourcen und die internen
Strukturen abgebildet werden. Abbildung 14.11 zeigt einen Screenshot mit einem ge¨
offneten
Kurs.
Abbildung 14.11: Komponente f¨
ur Kurse
Der Titel des Kurses, The Java Language Specification, ist der obersten Zeile zu entneh-
men und kann bearbeitet werden. Allgemeine Metadaten, die den gesamten Kurs betreffen,
k¨
onnen wieder ¨
uber den entsprechenden Knopf aufgerufen werden. Die Herausforderung bei
der Visualisierung ist es, die ¨
Ubersicht beizubehalten. ¨
Uber eine Zweiteilung des Panels, ge-
kennzeichnet mit den Beschriftungen Course Structure und Used Bricks and Courses, soll eine
klare Trennung zwischen Struktur und Ressourcen angezeigt werden. Der obere Baum ent-
spricht der Item-Struktur einer Organization, wobei als Attribute lediglich Titel und Referenz
angezeigt werden. F¨
ur eine genauere Steuerung der Lernpfade werden allerdings wesentlich
mehr Attribute ben¨
otigt, um z.B. Vorbedingungen, Zeiten, Punkte, etc. anzugeben. Jedoch
ist die Baumdarstellung nicht f¨
ur diese Anzahl von darzustellenden Werten ausgelegt, weshalb
162 Baukasten
¨
uber ein Kontextmen¨
u ein separates Fenster ge¨
offnet werden kann. Abbildung 14.12 zeigt alle
unterst¨
utzten Attribute, wobei die Felder f¨
ur SCORM-Werte extra gekennzeichnet sind. Soll-
te ein Baustein oder Kurs im IMS-Format gespeichert werden, k¨
onnen diese Attribute nicht
¨
ubernommen werden.
Abbildung 14.12: Ansicht der Item-Properties
Die Darstellung der Ressourcen in Abbildung 14.11 ist dank der eingeschr¨
ankten Definition
aus Abschnitt 12.4 sehr einfach gehalten: Kurse d¨
urfen n¨
amlich nur Bausteine und andere
Kurse als Ressourcen enthalten. In der zweiten Spalte mit dem Titel ”Href“ steht die jeweilige
URL9, mit der die Ressource verbunden ist. Alternativ k¨
onnen die Bausteine und Kurse auch
als physikalische Dateien angezeigt werden, indem diese Darstellung ¨
uber den Reiter ”Files“
ausgew¨
ahlt wird.
14.5 Steuerung des Exports
Obwohl in dieser Arbeit die Komponenten f¨
ur die Rolle Publisher lediglich hergeleitet wurden
(siehe Abschnitt 10.2.4), aber eine detaillierte Beschreibung des inneren Aufbaus ausblieb, soll
wenigstens kurz auf die grafische Repr¨
asentation eingegangen werden. Sie reicht vollkommen
aus, um eine Idee der T¨
atigkeit zu vermitteln. Im Wesentlichen geht es um die Umwandlung von
Bausteinen und Kursen, die intern XML zur Kodierung verwenden (siehe Abschnitt 3.7). Die
g¨
angigsten Zielformate sind HTML und PDF und k¨
onnen mit XSLT sowie XSL-FO generiert
werden. Zusammen mit einigen Hilfsklassen, auf die an dieser Stelle nicht weiter eingegangen
wird, bilden diese Umwandlungssprachen die Transformation Packages (TP), die wesentlich
Ausgabeformat und Erscheinungsbild pr¨
agen. Zus¨
atzlich k¨
onnen Module aktiviert werden,
mit denen z.B. Konvertierungen von Formeln oder Bildern durchgef¨
uhrt werden. Sie sind
unabh¨
angig von den TPs und k¨
onnen als Pr¨
aprozessoren verstanden werden. Abbildung 14.13
zeigt die genannten Funktionen in einem Dialog-Fenster an.
In der Combobox ist das GET Lab HTML Package ausgew¨
ahlt, das HTML-Dateien in der
Corporate Identity des GET Labs10 erzeugt. Von den optionalen Modulen ist ein Formelkon-
verter f¨
ur L
A
T
EX eingeschaltet, was am H¨
akchen in der Spalte Active zu erkennen ist. Da in
HTML keine L
A
T
EX-Formeln dargestellt werden k¨
onnen und die Unterst¨
utzung von MathML in
den g¨
angigen Browsern nicht vorausgesetzt werden darf, m¨
ussen die Formeln mit Hilfe dieses
9Das Zeichen %20 steht f¨
ur das Leerzeichen.
10http://getwww.upb.de (29.10.05)
14.6 Lyssa 163
Abbildung 14.13: Dialog f¨
ur Export-Einstellungen
Moduls als Grafiken eingebunden werden. Die Checkbox Uncompress content package legt fest,
ob ein Content Package erzeugt wird oder lose Dateien. Im Feld Processing werden der ak-
tuelle Baustein und die in ¨
Ubersetzung befindliche Datei angezeigt. Sind mehr Informationen
¨
uber den aktuellen Durchlauf erw¨
unscht, kann ¨
uber die Checkbox show log eine detailliertere
Ausgabe hinzugeschaltet werden. Soll das Ergebnis einer vorherigen Pr¨
ufung unterzogen wer-
den, kann ¨
uber den Knopf Preview eine Voransicht erzeugt werden. Ein Klick auf den Knopf
Save schreibt das Resultat direkt in eine auszuw¨
ahlende Datei.
14.6 Lyssa
Mit den erstellten Komponenten aus den letzten Kapiteln kann nun das Autorenwerkzeug
entsprechend den Abbildungen 10.20 und 10.23 zusammengesetzt werden. In Abschnitt 10.3
wurde festgelegt, dass eine einzelne Anwendung den Belangen der Rollen Developer,Composer
und Publisher gerecht werden muss. Durch diese enge Verzahnung der Komponenten ist ein
rasches Wechseln zwischen den Rollen m¨
oglich, was den Arbeitsablauf verbessert. Weil bisher
alle grafischen Komponenten Java Swing verwenden, soll auch das Autorenwerkzeug diese
Library nutzen.
Im Projekt mαth-kit hat sich Lyssa11 als Name f¨
ur das Autorenwerkzeug durchgesetzt
und wird stellvertretend als Begriff f¨
ur das Programm verwendet. Ein wesentliches Merkmal
von Lyssa ist die ¨
ubersichtliche und einfache Bedienung. Hierzu geh¨
ort auch der Aufbau der
grafischen Oberfl¨
ache, die aus drei Teilen besteht und nur so viele Daten anzeigt wie n¨
otig.
Abbildung 14.14 zeigt einen typischen Screenshot w¨
ahrend der Arbeit.
Ganz oben befindet sich die Toolbar, die eine Ansteuerung der Basisfunktionen erlaubt
und sich dem jeweils ausgew¨
ahlten Baustein oder Kurs im Arbeitsbereich anpasst. Abbildung
14.15 zeigt die Toolbar im initialen Zustand, wenn kein Baustein oder Kurs ge¨
offnet ist. Eigent-
lich w¨
aren die Kn¨
opfe Speichern und Speichern als ausgegraut, denn ihre Funktion steht
nur mit ge¨
offneten Dateien zur Verf¨
ugung. Zur besseren Identifikation sind sie aber aktiviert
dargestellt.
11Dieser merkw¨
urdig anmutende Name hat sich aus der Entwicklungsgeschichte ergeben. Jedes Teilprojekt
wurde intern nach einem Gott oder einer G¨
ottin aus der griechischen Mythologie benannt. Nach der Fertig-
stellung der ersten Version des Autorensystems wurde der Name beibehalten, obwohl freilich inhaltlich keine
Verbindung zu ihm besteht. Lyssa ist n¨
amlich die G¨
ottin der Rage und hat Herakles mit einer vor¨
ubergehenden
Verstandstr¨
ubung dazu gebracht, seine Frau und Kinder umzubringen.
164 Baukasten
Toolbar
Workbench Arbeitsbereich
Abbildung 14.14: Screenshot von Lyssa
¨
Uber den Knopf Laden wird ein Dateidialog ge¨
offnet, der die Auswahl eines Bausteins oder
Kurses anbietet. Mit den Kn¨
opfen Neuer Baustein und Neuer Kurs werden entsprechende
Objekte neu angelegt und auf der Arbeitsfl¨
ache pr¨
asentiert. Sobald ein oder mehrere Inhalte
angezeigt werden, erweitert sich die Toolbar um abh¨
angige Funktionen. Ist z.B. ein Kurs
ausgew¨
ahlt, dann sieht die Toolbar wie in Abbildung 14.16 aus.
Bei den Erweiterungen der Toolbar handelt es sich um ausgelagerte Ansteuerungen der
Komponenten aus den Abbildungen 14.10 und 14.11. Die Motivation f¨
ur dieses Vorgehen liegt
in der besseren ¨
Ubersicht begr¨
undet. Anstatt die gleichen Funktionen in die Komponenten zu
stecken und somit ¨
uber die Arbeitsfl¨
ache zu verteilen, befinden sich die Kn¨
opfe immer an der
selben Stelle. Ein Klick auf den Knopf Preview ¨
ubersetzt den ausgew¨
ahlten Inhalt mit einem
voreingestellten Transformation Package und ¨
offnet das Resultat in einem Anzeigeprogramm.
Ist mehr Kontrolle gew¨
unscht, kann ¨
uber Export der bekannte Dialog aus Abbildung 14.13
ge¨
offnet werde, mit dem sich die ¨
Ubersetzungsparameter einstellen lassen. Der letzte Knopf
Manifest ¨
offnet die Manifestansicht aus Abbildung 14.9.
Die bereits erw¨
ahnte Arbeitsfl¨
ache arrangiert alle ge¨
offneten Bausteine und Kurse in eige-
nen Fenstern. Wie ”normale“ Fenster auch, lassen sie sich verkleinern, vergr¨
oßern und verschie-
denartig ausrichten. ¨
Uber Befehle in der Men¨
uleiste k¨
onnen einzelne Fenster gezielt ausgew¨
ahlt
werden.
Als letzter Bestandteil von Lyssa bleibt die in Abbildung 14.14 auf der linken Seite liegende
Workbench ¨
ubrig, die f¨
ur den Datenaustausch mit dem Betriebssystem und anderen Rechnern
zust¨
andig ist. Im Prinzip ist es die um ein spezielles Dateisystem erweiterte Komponente zur
14.6 Lyssa 165
Laden Speichern als
Neuer BausteinSpeichern
Neuer Kurs
Abbildung 14.15: Screenshot der Toolbar
Export
Preview Manifest
Abbildung 14.16: Screenshot der erweiterten Toolbar
Dateiansicht aus Abbildung 14.2. Im Gegensatz zu anderen Programmen bietet Lyssa eine
abstraktere Sichtweise auf Dateien und ihre Verteilung. Die Struktur des Hauptverzeichnisses
ist in Abbildung 14.17 dargestellt.
Abbildung 14.17: Screenshot der Workbench
F¨
ur eigene erstellte Bausteine und Kurse sind die Verzeichnisse Brick und Courses vor-
gesehen. Wo die Dateien physikalisch gespeichert werden, ist nicht festgelegt und kann von
der voreingestellten Festplatte z.B. auf ein Netzlaufwerk umgestellt werden. Das Verzeichnis
My Home ist mit dem Home-Verzeichnis des eingeloggten User Accounts verbunden und Sys-
tem mit dem Wurzelverzeichnis des Betriebssystems. ¨
Uber das Kontextmen¨
u der Workbench
k¨
onnen noch beliebig weitere Verzeichnisse mit unterschiedlichen Dateisystemen hinzugef¨
ugt
werden. Im n¨
achsten Kapitel wird z.B. ein Server zur zentralen Datenhaltung vorgestellt, der
seine Inhalte ¨
uber WebDAV anbietet. So ein WebDAV-Laufwerk l¨
asst sich ohne weiteres in
die Workbench integrieren.
Kapitel 15
Repository
F¨
ur die Vervollst¨
andigung der angestrebten Architektur aus Abbildung 10.23 muss noch das
Repository f¨
ur die zentrale Datenhaltung implementiert werden. Die hierf¨
ur notwendigen Klas-
sen und Komponenten stehen gr¨
oßtenteils aus den vorherigen Kapiteln zur Verf¨
ugung, wie
Abbildung 10.18 mit der Komponente Learning Content Repository zu entnehmen ist. Al-
le eingezeichneten Subkomponenten sind bereits beschrieben worden. Was noch fehlt, ist die
Umsetzung der Infrastruktur f¨
ur den parallelen Zugriff mehrerer Autorensysteme ¨
uber das
Netzwerk. Sie wird durch die Komponente Web Server aus Abbildung 10.19 repr¨
asentiert, die
eine Web-gest¨
utzte Oberfl¨
ache und Remote Procedure Calls (RPC) anbietet.
In Kapitel 7 wurden bereits die Web-Technologien vorgestellt, die f¨
ur eine Umsetzung
des Repositories geeignet scheinen. Als Res¨
umee dieser Betrachtung ergibt sich, dass mit Hilfe
vorhandener Server, Module und Rahmenwerke anspruchsvolle Web Applications bei angemes-
senem Aufwand realisiert werden k¨
onnen. Teilweise wurden mehrere Produkte f¨
ur eine L¨
osung
vorgestellt, weshalb nun eine konkrete Entscheidung f¨
ur die Implementierung getroffen wird.
Als zentraler Web-Server wird Tomcat der Apache Group eingesetzt, weil die meisten Beteilig-
ten des Projekts mαth-kit mit diesem Programm vertraut sind. F¨
ur die strukturierte Imple-
mentierung der Web Application wurden kurz die Rahmenwerke Struts und Spring vorgestellt,
die ganz unterschiedliche Qualit¨
aten besitzen. Struts stellt eine einfache, robuste Umsetzung
des Entwurfsmusters MVC dar, die sich in vielen Projekten bew¨
ahrt hat. Sie deckt genau die
Anspr¨
uche ab, die sich aus der Umsetzung eines Repositories f¨
ur modulare E-Learning-Inhalte
ergeben. Spring hingegen macht einen moderneren, ganzheitlichen Eindruck f¨
ur die gesamte
Umsetzung von Web Applications. In Anbetracht der bisher entwickelten Komponenten ist der
Aufwand jedoch recht hoch, diese mit Spring zu verbinden. Dies liegt unter anderem am Kon-
zept der Beans f¨
ur die Datenhaltung, die ¨
uber eine eindeutige Identit¨
at verf¨
ugen und somit
f¨
ur Datenbanken pr¨
adestiniert sind. Bausteine und Kurse bestehen aber aus vielen Dateien,
teilweise in bin¨
aren Formaten und lassen sich nur schwer mit Beans modellieren. Aus dieser
Erw¨
agung heraus f¨
allt die Entscheidung f¨
ur die Verwendung von Struts.
Mit Axis steht eine freie Implementierung des SOAP-Protokolls f¨
ur Web Services zur
Verf¨
ugung, die sehr gut mit dem Web-Server Tomcat zusammen arbeitet. ¨
Uber die Web-
Service-Schnittstelle soll die Suchfunktionalit¨
at der Komponente Search Engine durch andere
Applikationen aufgerufen werden. Somit k¨
onnen Autorensysteme wie Lyssa Suchanfragen f¨
ur
Bausteine und Kurse direkt an das Repository schicken, ohne zwingend eine Web-Oberfl¨
ache
nutzen zu m¨
ussen. Der Datenaustausch selbst soll ¨
uber die ¨
Ubertragungstechnik WebDAV
erfolgen. Weil der Web-Server Tomcat mit WebDAV -Unterst¨
utzung ausgeliefert wird, ist le-
diglich ein wenig Konfigurationsarbeit zu leisten.
Ein Vorteil der freien Software soll noch hervorgehoben werden, der sich in der Praxis als
¨
außerst n¨
utzlich erwiesen hat. Alle Programme und Pakete liegen im Quellcode vor, sodass die
internen Vorg¨
ange wesentlich einfacher nachzuvollziehen sind. Im Fall der WebDAV -Library
konnte sogar ein Fehler selbst behoben werden, der w¨
ahrend der Tests aufgetreten war.
168 Repository
15.1 Construction Kit Server
Auch f¨
ur das Repository wurde im Projekt mαth-kit ein eigener Produktname vergeben. Um
den modularen Ansatz hervorzuheben, der auf der Baustein-Metapher beruht, lautet er Con-
struction Kit Server (CKS). Durch den Einsatz des Rahmenwerks Struts ist die Architektur
des CKS bereits grob vorgegeben. Der gr¨
oßte Teil der Programmlogik zum Aufrufen der Kom-
ponente Learning Content Repository liegt ¨
uber mehrere Controller verteilt, die ¨
uber eine
definierte Schnittstelle von Struts aufgerufen werden. ¨
Uberwiegend handelt es sich um die
Steuerung von Standardabl¨
aufen, wie z.B. die Eingabe einer Suchanfrage, die auf Richtigkeit
¨
uberpr¨
uft werden muss und gegebenenfalls mehrere Berichtigungszyklen durchl¨
auft. Bei einer
erfolgreichen Anfrage kann das Suchergebnis so viele Eintr¨
age enthalten, dass diese nicht ¨
uber-
sichtlich auf einer Seite dargestellt werden k¨
onnen. Dank mitgelieferter Komponenten, die sich
¨
uber Vererbung erweitern lassen, werden die l¨
astigen Routineaufgaben ¨
ubernommen.
Es ist daher im Gegensatz zur Herleitung des Autorensystems Lyssa nicht sinnvoll, an dieser
Stelle die involvierten Klassen aufzuz¨
ahlen, denn die Schnittstellen sind ¨
uberwiegend gleich.
Auch der Einsatz von Sequenzdiagrammen ist nicht angebracht, weil ¨
uberwiegend Methoden
des Rahmenwerks Struts involviert sind. Von daher reicht es aus, den Aufbau des Repositories
schematisch darzustellen. Abbildung 15.1 zeigt, wie Web-Server, Module, Rahmenwerke und
die selbst entwickelte Komponente zusammenwirken.
File System
DB
Author Authoring Tool Browser Author
Repository
Web Server
(Tomcat)
(Tomcat)
WebDAV Web Application
(Struts) Web Service
(Axis)
Connector Connector
Abbildung 15.1: Aufbau des Construction Kit Servers
Als Web-Server nimmt der Tomcat alle Anfragen der Clients entgegen, entweder vom
Autorenwerkzeug oder einem Web-Browser. Hiernach wird die Eingabe verarbeitet und an
das entsprechende Modul, entweder WebDAV,Web Application oder Web Service, delegiert.
Die Boxen mit der Beschriftung ”Connector“ kennzeichnen die zus¨
atzlich entwickelten Klassen,
die das Rahmenwerk Struts und die Komponente Learning Content Repository verbinden. Die
eingezeichnete Datenbank sowie das Dateisystem dienen zur Speicherung der Kurse, Bausteine
und Metadaten.
15.2 Web-Oberfl¨
ache 169
15.2 Web-Oberfl¨
ache
Der CKS verf¨
ugt auch ¨
uber eine eigene Web-Oberfl¨
ache, die den Zugriff auf die wichtigs-
ten Funktionen zur Baustein- und Kursrecherche erm¨
oglicht. Eine eigene Authentifizierung
und Autorisierung auf Dateiebene sch¨
utzt die Daten gegen¨
uber unbefugten Zugriffen. Daher
m¨
ussen sich die Benutzer/-innen zun¨
achst ¨
uber die CKS-Anmeldemaske aus Abbildung 15.2
anmelden.
Abbildung 15.2: Screenshot der CKS-Anmeldemaske
Nach erfolgter Anmeldung kann ¨
uber die gespeicherten Bausteine und Kurse navigiert
werden. Abbildung 15.3 zeigt einen kleinen Datenbestand, mit allgemeinen Zusatzdaten.
Abbildung 15.3: Screenshot der CKS-Dateiansicht
Neben Gr¨
oße, Datum, Besitzer/-in sind besonders die Versionsnummern (Revision) und
der Freigabestatus (Locked) interessant. Wird ein Baustein oder Kurs ver¨
andert, dann erh¨
oht
sich die Versionsnummer, sodass jede Speicherung nachvollzogen und bei Bedarf wieder r¨
uck-
g¨
angig gemacht werden kann. Ist ein exklusiver Zugriff auf eine Datei erw¨
unscht, l¨
asst sie sich
f¨
ur andere Autoren/-innen sperren (angezeigt durch das Vorh¨
angeschloss). Erst nach einer
expliziten Freigabe steht die Datei wieder f¨
ur alle Berechtigten zur Verf¨
ugung.
Teil IV
Analyse
Kapitel 16
Ausgew¨
ahlte Beispiele
In den vorangegangenen Teilen ”Entwurf“ und ”Implementierung“ wurde ein ganzheitliches
Konzept f¨
ur modulare E-Learning-Inhalte erstellt und umgesetzt. Aufgrund der Detailvielfalt
kann der Blick f¨
ur das Wesentliche verloren gehen, sodass in diesem Kapitel eine Reihe aus-
gew¨
ahlter Beispiele die Funktionalit¨
at verdeutlichen soll. Von der Erstellung von Bausteinen,
¨
uber die Aggregation zu Kursen bis hin zum Datenaustausch mit anderen Systemen wird
Schritt f¨
ur Schritt die Arbeit in der Praxis gezeigt. Freilich k¨
onnen nicht alle Aspekte und
M¨
oglichkeiten abgedeckt werden, aber der gr¨
oßte Teil des Systems wird durch die Beispiele
veranschaulicht.
16.1 Erstellung neuer Bausteine
Zur Erstellung von Bausteinen nehmen die Benutzer/-innen die Rolle Developer ein, in der
ihnen alle Funktionen des Autorensystems zur Verf¨
ugung stehen, die sie f¨
ur die Erf¨
ullung ihrer
Aufgabe ben¨
otigen. Es gibt verschiedene Szenarien bei der T¨
atigkeit, die zu leicht abgewan-
delten Arbeitsschritten f¨
uhren, aber letztendlich sind die Unterschiede nicht so gravierend,
weshalb die Darstellung eines Beispiels in mehreren Schritten ausreichend ist. An dieser Stelle
wird davon ausgegangen, dass die Texte, Bilder und ein Java Applet bereits vorliegen. Die
Erstellung solcher Materialien ist stark von den eingebundenen Programmen abh¨
angig, die
¨
uber die Komponente Multimedia Environment aus Abbildung 10.11 angesteuert werden.
Aus diesem Grund sollen die atomaren Dateien als gegeben angesehen werden, damit nicht zu
viel Zeit auf andere Programme verwendet wird.
Als Beispiel soll nun ein Baustein erstellt werden, wie er sich tats¨
achlich in der Praxis des
Projekts mαth-kit ergeben hat. Ein Thema unter vielen sind die komplexen Zahlen, die sich
sehr gut als repr¨
asentatives Beispiel anbieten. F¨
ur die komplexen Zahlen werden zum einen
sehr allgemeine Bausteine ben¨
otigt, die sich sehr flexibel in verschiedene Kontexte einbetten
m¨
ussen, und zum anderen aber auch sehr spezielle Bausteine, die nur f¨
ur ein spezielles Thema
geeignet sind. Da die Gruppen des Projekts mαth-kit in sehr unterschiedlichen Bereichen t¨
atig
sind — hier sind Technische Informatik, Mathematik und Ingenieurwissenschaften zu nennen
— und mit komplexen Zahlen in Ber¨
uhrung kommen, l¨
asst sich an ihnen der interdisziplin¨
are
Einsatz und die Wiederverwendung gut demonstrieren.
Zun¨
achst muss die Idee f¨
ur einen Baustein reifen und es schadet nicht, ¨
Uberlegungen zu den
sp¨
ateren Einsatzgebieten einfließen zu lassen. An dieser Stelle soll ein einf¨
uhrender Baustein
entwickelt werden, der unterschiedliche Darstellungen der komplexen Zahlen verdeutlicht. Weil
das Leitbild von mαth-kit der multimediale Baukasten ist, soll das Beispiel auch um eine multi-
mediale Komponente bereichert werden. Nach reiflicher ¨
Uberlegung ist der Entschluss gefallen,
dieses Vorhaben mit einem Java Applet zu realisieren, denn die geplanten Interaktionen setzen
ein hohes Maß an Steuerbarkeit voraus. Mit der Unterst¨
utzung mehrerer Entwickler/-innen
wurde eine L¨
osung erstellt, die der Screenshot in Abbildung 16.1 nur ansatzweise ¨
ubermitteln
kann.
174 Ausgew¨
ahlte Beispiele
Abbildung 16.1: Screenshot des Applets f¨
ur komplexe Zahlen
Nicht nur die reine Umsetzung der Funktionalit¨
at verdient eine explizite Erw¨
ahnung, die
mit Umschaltung von Koordinatensystemen, Zoom-Funktion und unterschiedlichen Rechen-
operationen die verschiedenen Facetten des Themas abdeckt, sondern auch die Anpassungsf¨
a-
higkeit an den einbettenden Kontext. Rahmen, Hilfe, Farben, Zeichens¨
atze, Schriftgr¨
oßen und
viele weitere Parameter lassen sich n¨
amlich von außen konfigurieren, sodass dasselbe Applet
in unterschiedlichen Ausgaben nicht durch ein einmal festgelegtes ¨
Außeres als Fremdk¨
orper
hervorsticht. Die st¨
orenden Auswirkungen bei fehlender Adaptierbarkeit d¨
urfen nicht unter-
sch¨
atzt werden.
Nach der Entwicklung des Applets wird der Text geschrieben. Das Autorensystem selbst
enth¨
alt keinen eigenen Editor zum Schreiben von Texten oder XML-Dokumenten. Hier gibt es
aber viele freie sowie kommerzielle Programme auf dem Markt, die aus der allt¨
aglichen Arbeit
bereits bekannt sind und sich f¨
ur diese Aufgabe anbieten. Der Vorteil dieser Vorgehensweise
ist die Freiheit f¨
ur die Anwender/-innen, denn sie nutzen das Werkzeug ihrer Wahl und haben
im idealen Fall keine Einarbeitungszeit. Folgender Ausschnitt des XML-Codes soll eine Idee
des Textes vermitteln:
<?xml version=”1.0” encoding=”ISO−8859−1” ?>
2
<tco title=”Polar Coordinates, Geometrical Interpretation of Complex Multiplication”
4xml:lang = ”en”>
<p>
6Let
<formula text=”true”>
8z=a+ib \not= 0
</formula>
10 be an arbitrary point in the complex plane.We draw a line from 0to
<formula text=”true”>
16.2 Erstellung neuer Kurse 175
12 z\,
</formula>
14 </p>
16 ...
18 <p>
Hence,the multiplication of two complex numbers means the
20 multiplication of the two absolute values and the addition of
the arguments. (The following applet visualises this calculation.)
22 </p>
24 <p>
<mmo type=”applet”
26 code=”ComplexApplet.class”
archive=”complex.jar”
28 width=”800”
height=”600”>
30 <param name=”showPolar” value=”true”></param>
<param name=”language” value=”en”></param>
32 <param name=”copyright” value=”Copyright 2002”></param>
<param name=”help” value=”help.html”></param>
34 </mmo>
</p>
36 </tco>
Nach der Erstellung einer Abbildung — wieder mit einem Programm der Wahl — ergeben
das Applet, der XML-Text und die Bilddatei zusammen einen Baustein. Sie werden in ein Con-
tent Package kopiert und anschließend bestimmt die Auswahl einer Datei den Einstiegspunkt
des Bausteins. Eine Angabe von Metadaten vervollst¨
andigt den Baustein, sodass er auch in
gr¨
oßeren Datenbest¨
anden, wie z.B. dem Repository, leicht aufzufinden ist. Die Bildfolge in
Abbildung 16.2 illustriert die einzelnen Arbeitsschritte.
Nach dem Start des Autorensystems ¨
offnet sich ein Fenster, das die Workbench auf obers-
ter Ebene und eine leere Arbeitsfl¨
ache zeigt (Abbildung 16.2(a)). Durch Dr¨
ucken des Knopfs
”Neuer Baustein“ in der Werkzeugleiste geht ein Baustein ohne Namen auf. Weil die ben¨
otigten
Dateien bereits vorliegen, muss lediglich das entsprechende Verzeichnis in der Workbench ge¨
off-
net werden (Abbildung 16.2(b)). Nachdem alle Dateien mit der Maus markiert wurden, lassen
sie sich per Drag’n’Drop in den Dateibereich des Bausteins ziehen. Obwohl die XML-Datei
automatisch als Einstiegspunkt angegeben wird, kann es zu Dateikonstellationen kommen,
bei denen diese Entscheidung nicht einwandfrei getroffen werden kann. Ist die zugewiesene
Datei nicht korrekt, l¨
asst sie sich durch eine Combobox manuell ausw¨
ahlen, die alle Dateien
des Bausteins anzeigt (Abbildung 16.2(c)). Nun ist der Baustein grundlegend fertig gestellt,
sollte aber durch die Vergabe von Metadaten erkl¨
art werden (Abbildung 16.2(d)). Wenigstens
die Daten der Kategorie General sind einzugeben, sodass die Suchmaschine des Repositories
den Baustein ¨
uber die Schl¨
usselw¨
orter identifizieren kann. Abschließend wird der Baustein an
einem beliebigen Ort gespeichert, entweder lokal, wenn er z.B. noch nachbereitet werden soll,
oder im Repository, um ihn zentral zur Verf¨
ugung zu stellen.
16.2 Erstellung neuer Kurse
In der Rolle Composer erstellen Benutzer/-innen Kurse aus Bausteinen und anderen Kursen.
Hierbei ist weniger technisches Wissen gefragt, sondern der Blick f¨
ur das Gesamte. Lediglich
das Verst¨
andnis f¨
ur die Rahmenbedingungen, die einen reibungslosen Einsatz gestatten, darf
vorausgesetzt werden. Um das Beispiel nicht zu ¨
uberfrachten, wird in diesem Abschnitt nicht
weiter auf die Suche in Repositories eingegangen. Im vorherigen Beispiel 16.1 wurde bereits
176 Ausgew¨
ahlte Beispiele
(a) Initialer Zustand (b) Leerer Baustein
(c) Auswahl der Einstiegsdatei (d) Eingabe der Metadaten
Abbildung 16.2: Erstellung eines Bausteins in vier Momentaufnahmen
16.3 Inhalte publizieren 177
ein Baustein f¨
ur komplexe Zahlen erstellt, der nun mit weiteren Bausteinen zu einem Kurs
zusammengesetzt wird.
Es gibt zwei wesentliche Varianten, einen Kurs zusammenzusetzen, die sich auch kom-
binieren lassen. Bei der ersten werden alle Bausteine auf ein Mal in den Kurs gezogen und
anschließend zu einer Struktur verkn¨
upft. Dieser Aufbau wird bei der zweiten Variante direkt
gesteuert, indem jeder Baustein einzeln in die Struktur und nicht in den Ressourcenbereich ge-
zogen wird. Besonders bei vielen Bausteinen ist letzteres Vorgehen ¨
ubersichtlicher. Abbildung
16.3 verdeutlicht die einzelnen Schritte, wobei die erste Reihe die Variante mit der nachtr¨
ag-
lichen Verkn¨
upfung zeigt und die zweite Reihe die direkte.
In dieser Darstellung wurden die ersten Schritte ausgelassen, weil sie denen aus Abbildung
16.2(a) gleichen. Nach dem Start befindet sich das Autorensystem im gewohnten Anfangs-
zustand und eine Bet¨
atigung des Knopfs ”Neuer Kurs“ ¨
offnet einen leeren Kurs. Neben der
Auswahl des Verzeichnisses, das die gew¨
unschten Bausteine enth¨
alt, wird noch der Titel des
Kurses eingegeben, der in diesem Fall ”Mathematics for Engineers“ lautet. Anschließend wer-
den alle Dateien ausgew¨
ahlt und per Drag’n’Drop in den Ressourcenbereich gezogen. Nun
kann die Struktur aufgebaut werden, indem ¨
uber das Kontextmen¨
u des Strukturbereichs der
Befehl New Item aufgerufen wird. Befindet sich der Mauszeiger beim ¨
Offnen des Men¨
us auf
einem bereits existierenden Knoten, dann wird ein neuer Unterknoten eingeh¨
angt. Andernfalls
erscheint der Knoten auf oberster Ebene. Abbildung 16.3(a) zeigt den Zustand des Kurses,
nachdem bereits zwei Knoten auf oberster Ebene und ein Unterknoten erstellt wurden. Da das
Kontextmen¨
u auf H¨
ohe des Knotens ”Polar Coordinates“ ge¨
offnet ist, wird der neue Knoten
unter diesem erscheinen, wie in Abbildung 16.3(b) zu sehen ist. Die Auswahl der Ressource
erfolgt ¨
uber eine spezielle Combo Box, die eine vollst¨
andige Liste aller Ressourcen anbietet.
Sobald eine ausgew¨
ahlt ist, wird auch der Knoten automatisch benannt. Eine Eingabe von
Metadaten ist selbstverst¨
andlich auch f¨
ur Kurse angeraten, wird aber aus Platzgr¨
unden nicht
in einer Abbildung dargestellt. Wenn auch dieser Schritt abgeschlossen ist, kann der Kurs an
beliebiger Position gespeichert werden.
Abbildung 16.3(c) zeigt die Variante mit dem separaten Einf¨
ugen jedes Bausteins in die
Struktur. Es ist gerade der Baustein Application.lob ausgew¨
ahlt, der mit der Maus auf
den Knoten ”Polar Coordinates“ gezogen wird. In Abbildung 16.3(d) ist das Resultat zu se-
hen. Neben dem neuen Unterknoten wurden gleichzeitig Titel und Referenz auf die Ressource
angelegt, sodass mit einer Mausbewegung ein vollst¨
andiger Knoten entsteht. Da ein Knoten
mehr Eigenschaften besitzt als gleichzeitig in der Baumdarstellung pr¨
asentiert werden k¨
onnen,
wird ein zus¨
atzliches Eigenschaftsfenster eingeblendet, in dem sich alle Werte einstellen lassen.
Wenn der Kurs fertig gestellt ist, folgt nach der Metadateneingabe das Speichern.
16.3 Inhalte publizieren
Die Rolle Publisher ist f¨
ur die ¨
Ubersetzung von Bausteinen und Kursen in andere Formate,
wie z.B. HTML oder PDF, zust¨
andig. F¨
ur diese T¨
atigkeit stehen verschiedene Werkzeuge zur
Verf¨
ugung, von denen in diesem Beispiel lediglich die ¨
Ubersetzungsprozesssteuerung vorge-
stellt wird. Alle wesentlichen Funktionen wurden bereits in Abschnitt 14.5 erl¨
autert, weshalb
sich folgender Text mehr auf die Resultate konzentriert. Zu den anderen Werkzeugen sei noch
gesagt, dass ihre Bedienung relativ komplex ist und sie in der Regel nicht oft eingesetzt wer-
den. Ihr wesentlicher Zweck ist die Erstellung der Transformation Packages (TP), in denen
Java-Klassen, ¨
Ubersetzungsregeln und sonstige Ressourcen enthalten sind. Einmal erstellt, was
durchaus viel Arbeit bereiten kann, sollte das TP nach einer kurzen Anpassungszeit nur noch
wenige ¨
Anderungen ben¨
otigen.
Welche Auswirkungen ein TP auf das Resultat hat, wird nun anhand drei verschiedener
Beispiele f¨
ur den gleichen Inhalt demonstriert. Bei dem Inhalt handelt es sich um ein Skript
zur Technischen Informatik von Prof. Dr.-Ing. B¨
arbel Mertsching, das urspr¨
unglich in L
A
T
EX
gesetzt und mit Hilfe des Importmechanismus konvertiert wurde. Das erste TP ist im Stil des
178 Ausgew¨
ahlte Beispiele
(a) Hinzuf¨
ugen eines neuen Knotens (b) Ausw¨
ahlen der Referenz
(c) Separates Einf¨
ugen von Bausteinen (d) Bearbeitung der Eigenschaften eines Knotens
Abbildung 16.3: Erstellen eines Kurses in zwei Varianten
16.4 Explorationsumgebung 179
GET Lab-Web-Auftritts gehalten, wodurch sich erstellte Kurse nahtlos in die Site integrieren.
Abbildung 16.4 zeigt einen Screenshot des Ergebnisses mit einer Seite ¨
uber ”Codes“. Es handelt
sich um HTML-Seiten f¨
ur einen g¨
angigen Web-Server, weshalb auch eine Navigation erzeugt
wurde. W¨
are der Inhalt f¨
ur ein LMS bestimmt, ließe sich dieser zus¨
atzliche ¨
Ubersetzungsschritt
selbstverst¨
andlich auslassen.
Abbildung 16.4: ¨
Ubersetzungsergebnis im Layout des GET Labs (HTML)
Das zweite Beispiel in Abbildung 16.5 zeigt den gleichen Inhalt, ¨
ubersetzt mit dem TP
des Projekts mαth-kit. Abgesehen von den Farben und den Logos ¨
ahnelt die Darstellung dem
ersten Beispiel, wo hingegen die Darstellung in einem anderen Format auch zu einem unter-
schiedlichen Ergebnis f¨
uhrt, wie Abbildung 16.5 verdeutlicht. In diesem Screenshot ist der
Inhalt als PDF zu sehen, das mit einem weiteren TP des Projekts mαth-kit ¨
ubersetzt wurde.
Die sichtbare Navigation wurde im Gegensatz zur HTML-Variante nicht generiert, weil PDF
diese Funktionalit¨
at automatisch anbietet. Ein wesentlicher Unterschied macht die Platzierung
der Bausteine auf dem Bildschirm aus. Aufgrund der kleineren Darstellung werden bei PDF
mehrere Bausteine auf eine Seite gesetzt. Weil HTML haupts¨
achlich f¨
ur die Bildschirmdarstel-
lung genutzt wird, darf mit dem Platz großz¨
ugiger umgegangen werden. Jeder Baustein wird
zu einer HTML-Seite umgewandelt, die sich bei Bedarf vertikal scrollen l¨
asst.
16.4 Explorationsumgebung
Die in dieser Arbeit vorgestellte Infrastruktur f¨
ur modulare E-Learning-Inhalte unterst¨
utzt
eine Vielzahl verschiedener Lernparadigmen. In diesem Beispiel soll nun aus Sicht der Rolle
Student die Arbeit mit einer Explorationsumgebung verdeutlicht werden, einem wesentlichen
Konzept im Projekt mαth-kit. Eine Explorationsumgebung dient in erster Linie zur prakti-
schen Vertiefung von bereits angeeignetem Wissen, also z.B. als Erg¨
anzung zu einer Vorlesung.
180 Ausgew¨
ahlte Beispiele
Abbildung 16.5: ¨
Ubersetzungsergebnis im Layout von mαth-kit (HTML)
Abbildung 16.6: ¨
Ubersetzungsergebnis im Layout von mαth-kit (PDF)
16.4 Explorationsumgebung 181
Benutzer/-innen in der Rolle Student k¨
onnen auf diese Weise im Selbststudium ihren aktuellen
Wissensstand ¨
uberpr¨
ufen und erweitern. Die zugrundeliegende Lerntheorie f¨
ur Explorations-
umgebungen ist der Konstruktivismus (siehe Abschnitt 2.2.3).
In diesem Beispiel sollen die bereits verwendeten komplexen Zahlen als Anschauungsobjekt
dienen. Eine Explorationsumgebung beginnt zun¨
achst mit einem theoretischen Teil, der das
n¨
otige Grundwissen vermittelt. Abbildung 16.7 zeigt den Unterabschnitt ”Geometrische Inter-
pretation der komplexen Zahlen“ des Abschnitts ”Gaußsche Zahlenebene“. Sollten die theoreti-
schen Grundlagen bereits vorhanden sein, kann auch direkt zum Explorationsteil ¨
ubergegangen
werden. Abbildung 16.8 zeigt ein Applet zum Rechnen mit komplexen Zahlen im kartesischen
Koordinatensystem. Nach der konstruktivistischen Sichtweise gibt der Explorationsteil keine
starre Aufgabe oder Ausf¨
uhrungsfolge vor, sondern erlaubt der Rolle Student eine individuelle
Erfahrung. In diesem Beispiel erlaubt das Applet, verschiedene Operationen mit komplexen
Zahlen interaktiv durchzuf¨
uhren. Um den Transfer des neu erlangten Wissens in die Praxis
ein wenig zu vereinfachen, folgt ein Anwendungsteil mit spezifischen Beispielen.
Viel wichtiger als dieser Praxisbezug ist jedoch der ¨
Ubungsteil, der den aktuellen Lernfort-
schritt wiedergibt. Ohne diese ¨
Uberpr¨
ufung kann die eigene Leistung der Rolle Student nur
schwer eingesch¨
atzt werden. Noch gravierender wirken sich falsche R¨
uckschl¨
usse oder Miss-
verst¨
andnisse aus, die sich vielleicht aus dem Explorationsteil ergeben. Um ihnen entgegen zu
wirken, sollten die ¨
Ubungen das gesamte Spektrum einer Explorationsumgebung abdecken.
In welcher Form dies genau geschieht, ist dabei von geringer Wichtigkeit. Mit dem Autoren-
system Lyssa lassen sich z.B. Quiz, Puzzles und Multiple-Choice-Aufgaben ohne Aufwand
integrieren. In Abbildung 16.9 ist z.B. eine ¨
Ubung zur Umwandlung der Darstellungsarten
zu sehen, die mit der eigenen Auszeichnungssprache des Projekts mαth-kit erstellt wurde
[Baudry03; Baudry04b].
Abbildung 16.7: Theorieteil
182 Ausgew¨
ahlte Beispiele
Abbildung 16.8: Explorationsteil
Abbildung 16.9: ¨
Ubungsteil
Kapitel 17
Zusammenfassung und Bewertung
Das Ziel dieser Arbeit ist, Entwurf, Implementation und Einsatz eines ganzheitlichen Kon-
zepts f¨
ur modulare E-Learning-Inhalte zu realisieren. Der vorgegebenen Systematik folgend
wurden im ersten Teil der Stand der Wissenschaft wiedergegeben und die aktuellen Grenzen
aufgezeigt. Als besondere Herausforderung stellte sich die vorherrschende Betrachtung von
Einzelproblemen in der wissenschaftlichen Gemeinschaft heraus. Keine der Arbeiten deckt
das gesamte Spektrum dieses Gebietes ab, sondern betrachtet Details, die f¨
ur sich genommen
wichtig sind, sich als Teil eines Ganzen jedoch in der Praxis anders verhalten. So galt es, die
einzelnen Theorien, Definitionen sowie Umsetzungen zu kombinieren und um neue Ideen bzw.
eine erweiterte Sicht anzureichern. Dass dieses Unterfangen nicht einfach wird, zeichnete sich
bereits in Kapitel 3¨
uber die Lernobjekte ab. Viele Definitionen, die teilweise ¨
ahnlich und doch
wieder sehr verschieden sind, zeigten, wie unterschiedlich die Ansichten und Bed¨
urfnisse sind.
Auch in dieser Arbeit wird die Problemstellung aus einem eigenen Blickwinkel betrachtet.
Herausgekommen ist deshalb eine L¨
osung, die stark technisch angelegt ist, aber durch ihre
generische Struktur keine Barrieren f¨
ur unterschiedliche didaktische Konzepte aufstellt.
Mit den erworbenen Erkenntnissen wurde in Kapitel 10 eine Vision f¨
ur das angestrebte
System entwickelt. Ein besonderes Augenmerk lag auf der genauen Feststellung des Bedarfs
der sp¨
ateren Benutzer/-innen, indem ¨
uber Rollen die einzelnen T¨
atigkeiten gruppiert wurden.
Einerseits lassen sich durch diese Abgrenzungen die einzelnen Anwendungsf¨
alle leichter finden
und vervollst¨
andigen, andererseits wird ein modularer Aufbau des sp¨
ateren Systems gef¨
ordert.
Jede T¨
atigkeit l¨
asst sich n¨
amlich wieder einer bestimmten Anzahl von Komponenten zuordnen,
die f¨
ur sich einen abgeschlossenen Funktionsumfang besitzen. Hierdurch lassen sich einzelne
Teile des Systems auch in anderen Kontexten einsetzen, was die Wiederverwendbarkeit des
Systems erh¨
oht. Aus diesem Grund muss nicht die gesamte Anwendung installiert und kon-
figuriert werden, nur weil eine bestimmte Funktionalit¨
at ben¨
otigt wird. Die Abh¨
angigkeiten
der Komponenten untereinander sind durch den umfangreichen Entwurf auf ein Minimum
reduziert.
F¨
ur ein besseres Verst¨
andnis wurde zus¨
atzlich die Metapher ”Baukasten“ eingef¨
uhrt, die
weitere Begriffe wie z.B. den Baustein implizierte. Diese zus¨
atzlich im Entwurf eingezoge-
ne Ebene gibt Entwicklern/-innen wie Benutzern/-innen eine vereinfachte Ansicht auf das
komplexe System, indem sie Assoziationen und eine gewisse Vertrautheit hervorruft. Anstatt
technische Details zu betonen, werden die wesentlichen Eigenschaften des Systems in den
Vordergrund gestellt: Bausteine lassen sich vielf¨
altig und ”kinderleicht“ kombinieren. Die Me-
tapher wirkte sich nicht nur auf das User Interface (UI) aus. Jede einzelne Komponente, sei
sie noch so klein oder allgemein, wurde speziell auf dieses Prinzip ausgelegt, sodass sich ein
konsistenter Entwurf ergab, der ohne Hilfskonstruktion auskommt.
Der Entwurf der einzelnen Komponenten gestaltet sich orthogonal, indem neue Kompo-
nenten die bestehenden f¨
ur ihre Aufgaben nutzen. Auf unterster Ebene befinden sich die Basis-
komponenten aus Kapitel 11, die auf den ersten Blick wenig mit E-Learning zu tun haben. Sie
184 Zusammenfassung und Bewertung
bereiteten jedoch den Weg f¨
ur die eigentlich genutzten Komponenten, indem sie den techni-
schen Zugriff auf Dateien und externe Anwendungen abstrahieren. Erst durch die vereinfachte
Sicht auf die Inhalte der Bausteine und Kurse war es m¨
oglich, die komplexen Konvertierungs-
und Integrationsfunktionen in der Form anzubieten. In Kapitel 12 wurde gezeigt, wie sich
die Basiskomponenten mit vorherrschenden Standards sowie Metaphern zu einer vielseitigen
Komponente f¨
ur modulare E-Learning-Inhalte vereinen lassen. Diese Komponente f¨
ur Baustei-
ne und Kurse bietet sich an, auch außerhalb dieser Arbeit in anderen Projekten verwendet zu
werden. Unabh¨
angig von den eingesetzten Metaphern — es handelt sich um eine austauschbare
Schicht —, erlaubt sie die Erstellung, Wartung und Nutzung standardkompatibler Lernobjek-
te. Sollte in einem Projekt die Auffassung vorherrschen, z.B. lieber Wileys Atom-Metapher
aus Abschnitt 3.2.3 einzusetzen, ist der Aufwand f¨
ur die Anpassung der Schnittstelle gering.
Zusammen mit den anderen Komponenten f¨
ur den Import von Inhalten, der Suche und
der ¨
Ubersetzung in andere Formate ergab sich ein vollst¨
andiges Rahmenwerk in Kapitel 13.
Es wurden die Bereiche Erstellung von Inhalten, ihre Komposition und die Konvertierung ab-
gedeckt, auf denen Komponenten zur Darstellung sowie Steuerung aufsetzen. Hierdurch war
der funktionale Grundstein gelegt, um die angestrebte Umgebung f¨
ur modulare E-Learning-
Inhalte im vollen Umfang zu realisieren. Die mit den Benutzern/-innen kommunizierenden
Komponenten k¨
onnen beliebig nach eigenen didaktischen Gesichtspunkten gestaltet werden,
weil das Rahmenwerk hier¨
uber keine Vorgaben macht. Auch technische Entscheidungen, ob
das System z.B. verteilt mit vielen Autoren/-innen arbeiten soll oder doch als Einzelplatzan-
wendung realisiert wird, sind noch offen. Dank der Skalierbarkeit des Rahmenwerks, k¨
onnen
auch wesentlich kleinere oder spezialisierte L¨
osungen umgesetzt werden, als sie hier angedacht
sind. Es stehen alle M¨
oglichkeiten offen.
F¨
ur das gesetzte Ziel musste auch eine konkrete Implementierung umgesetzt werden, die
sich in der Praxis bew¨
ahrt. Die Systemvision in Abbildung 10.23 gibt genau vor, dass die
Entwicklungsumgebung f¨
ur modulare E-Learning-Inhalte aus einem zentralen Repository be-
steht, auf das die Autoren/-innen mit einem Werkzeug zugreifen. Angelehnt an die gew¨
ahlte
Metapher Baukasten, wird in Kapitel 14 das Autorenwerkzeug umgesetzt. Der Fokus lag hier-
bei auf einer einfachen wie flexiblen Anwendung, bei der mit wenigen Arbeitsschritten die
gew¨
unschten Ergebnisse erzielt werden. Wenn immer m¨
oglich, wurden grafische Komponen-
ten herausgearbeitet, wie z.B. die Dateiansicht, die in vielen Kontexten ihren Einsatz finden.
Hierdurch wird die ohnehin kurze Einarbeitungszeit reduziert. Auch beim Autorenwerkzeug
soll die Skalierbarkeit betont werden, denn durch den Zugriff ¨
uber die Workbench kann das
Programm als Einzelplatzl¨
osung oder als Teil einer verteilten Anwendung betrieben werden.
Das Repository in Kapitel 15 setzt sich gr¨
oßtenteils aus fertigen Servern und Libraries
zusammen, die aber entsprechend konfiguriert und angepasst wurden. Auch bei dieser Auf-
gabe kam der Komponentenentwurf entgegen, weil sich die ben¨
otigte Funktionalit¨
at einfach
integrieren ließ. Der Entwicklungsaufwand war relativ gering und das Ergebnis ¨
uberzeugend.
Eine Reihe verschiedener Protokolle sowie Mechanismen erm¨
oglichen nun den Zugriff auch von
anderen Programmen, die nicht in dieser Arbeit entwickelt wurden. Wenn nun z.B. ein anderes
Autorenwerkzeug genutzt wird, das standardkompatibel ist und WebDAV unterst¨
utzt, kann
es auf das Repository zugreifen.
In Anbetracht der Zielsetzung aus Abschnitt 1.2 und ihrer Verfeinerung aus Abschnitt
9.1 wurde in dieser Arbeit eine ad¨
aquate L¨
osung herausgearbeitet, die teilweise sogar ¨
uber
die Anspr¨
uche hinausgeht. Dank der Skalierbarkeit des gesamten Systems k¨
onnen nicht nur
große Infrastrukturen f¨
ur modulare E-Learning-Inhalte aufgebaut werden. Je nach Belieben
k¨
onnen einzelne Komponenten entnommen werden, die sich aufgrund ihrer Standardkompa-
tibilit¨
at mit Systemen gleicher Ausrichtung wirkungsvoll integrieren lassen. Mit dieser Arbeit
ist es gelungen, das differente Feld der Lernobjekte von der Theorie bis zur Implementierung
zusammenzufassen und ein ganzheitliches Konzept zu liefern.
Kapitel 18
Ausblick
In dieser Arbeit haben sich neben den behandelten Fragestellungen viele weitere interessante
Themen aufgetan, die nicht weiter behandelt werden konnten. Gr¨
unde hierf¨
ur sind zum einen
der zu große Umfang, den eine gerecht werdende Diskussion einnehmen w¨
urde, oder der sp¨
ate
Zeitpunkt des Auftretens, der eine direkte Ber¨
ucksichtigung unm¨
oglich machte. In diesem
Kapitel nun sollen diese Themen wenigstens angesprochen werden, um ihre wissenschaftliche
Behandlung in anderen Arbeiten anzuregen.
Viele in der Arbeit vorgestellten Standards unterliegen einer stetigen Weiterentwicklung.
Ein besonders wichtiger im Zusammenhang mit modularen E-Learning-Inhalten ist SCORM
(siehe Abschnitt 3.6), der mittlerweile SCORM 2004 [Dodd04a; Dodd04b; Dodd04c] heißt und
neben einigen Verbesserungen auch neue Aspekte behandelt. So wird die Sequenzierung von In-
halten (siehe Abschnitt 3.4) nun ausf¨
uhrlich in einem eigenen Dokument behandelt [Dodd04c].
All diese Neuerungen sollten in einer n¨
achsten Version des entwickelten Rahmenwerks einflie-
ßen, um die Standardkompatibilit¨
at auch f¨
ur neue SCORM-Lernobjekte zu garantieren.
Einige Standards haben keinen Einfluss auf diese Arbeit gefunden, weil sie zum Zeitpunkt
der Entwicklung noch nicht die n¨
otige Reife erlangt hatten. Hierzu geh¨
ort das IMS Digital
Repositories Interoperability [IMS03a], das andere Standards wie z.B. IMS Meta-Data und
IMS Content Packaging nutzt, um ein digitales Repository f¨
ur Lernobjekte aufzubauen. Im
Grunde genommen werden in diesem Standard die formalen Rahmenbedingungen festgelegt,
wie sie im Entwurf des Repositories dieser Arbeit (siehe Kapitel 15) befolgt werden. Da auch
hier die Einhaltung der Standards einen wesentlichen Punkt ausmachte, sollte es ein leichtes
sein, durch leichte Modifikationen ein f¨
ur diesen Standard kompatibles Repository zu erzeugen.
Ein anderes Themengebiet, das in dieser Arbeit nicht wesentlich behandelt wurde, sind
die M¨
oglichkeiten bei der inhaltlichen Gestaltung von Lernobjekten. Neben den Formaten zur
Kodierung der Inhalte (siehe Abschnitt 3.7) und den Metadaten (siehe Kapitel 4), gibt es
Standards f¨
ur das Verhalten von Lernobjekten zur Laufzeit. Da w¨
aren zum einen Quiz, mit
denen die Studierenden z.B. ihren Wissensstand selbst ¨
uberpr¨
ufen oder Leistungsnachweise er-
bringen k¨
onnten. Grundlage f¨
ur den Einsatz in modularen E-Learning-Inhalten w¨
aren freilich
Standards, wie z.B. IMS Question and Test Interoperability [IMS04b], die vom Autorensys-
tem und von der Lernplattform korrekt verarbeitet werden. Zu den erg¨
anzenden Verfahren
geh¨
ort auch das Sammeln von Daten ¨
uber die Studierenden, die z.B. nach einem Standard wie
dem IMS Learner Information Package [IMS05] in der Lernplattform oder dem Repository
gespeichert werden.
Den Urhebern/-innen digitaler Inhalte gereichen die eigentlich positiven Eigenschaften des
Internets oft zum Nachteil. ¨
Uber das Internet k¨
onnen Lernobjekte ubiquit¨
ar verbreitet wer-
den und eine Kopie ist so gut wie das Original. Diese Verteilung l¨
asst sich ohne geeignete
Mittel nicht kontrollieren, sodass gewollt oder ungewollt die Urheberrechte schnell verletzt
sind. Denn sobald Lizenzgeb¨
uhren mit dem geistigen Eigentum verbunden sind, reichen ein-
fache Copyright-Vermerke in den Metadaten nicht aus. Das zeigt sich eindeutig an der Be-
186 Ausblick
liebtheit freier P2P-Netzwerke (Peer-to-Peer), in denen vorwiegend Raubkopien gehandelt
werden. Es m¨
ussen technische Vorkehrungen getroffen werden, mit denen die Verbreitung
und Nutzung kontrolliert wird. Der dahinter stehende Mechanismus nennt sich Digital Rights
Management (DRM) [Downes03; Iannella01] und wird in anderen Medienbereichen, wie z.B.
Handy-Klingelt¨
one, Musikst¨
ucke oder Videos bereits kommerziell genutzt. Inhalte werden ver-
schl¨
usselt ¨
ubertragen und k¨
onnen nur mit spezieller Software oder Hardware in das urspr¨
ung-
liche Format ¨
ubertragen werden. Voraussetzung hierf¨
ur ist eine g¨
ultige Lizenz.
Auf dem Gebiet der Lernobjekte hat diese Technik in der Praxis noch keinen Einzug
gefunden und auch die Standardisierung ist nicht weit fortgeschritten. Hier gibt es noch For-
schungsgebiete, die wissenschaftlich erschlossen werden m¨
ussen, um sie in das Rahmenwerk
dieser Arbeit zu integrieren. Auf jeden Fall ist DRM f¨
ur die kommerzielle Nutzung von modu-
laren E-Learning-Inhalten ein wichtiges Thema, das zuk¨
unftige Systeme anbieten sollten. Ein
Beispiel f¨
ur ein einfaches DRM-Rahmenwerk f¨
ur Lernobjekte ist z.B. in [Santos04] zu finden.
Ein anderes interessantes Thema im Zusammenhang mit Lernobjekten ist die Einf¨
uhrung
semantischer Ontologien, um Dokumente untereinander zu verkn¨
upfen [Krieg-Br¨
uckner04].
Dies k¨
onnte ein Schl¨
ussel in Richtung personalisiertes Lernen sein, bei dem Lernende ihr ei-
genes Wissen mit genau auf ihre Bed¨
urfnisse angepassten Lernmaterialien aufbauen. Jeder
Mensch bringt beim Lernen andere Voraussetzungen mit, denen mit individuellen, angepass-
ten Lernpfaden [Farrell04; Atif03] begegnet werden soll. Hierf¨
ur muss das System Annahmen
treffen, die auf Daten ¨
uber die Lernenden, z.B. durch automatische Tests oder Bewertungen
durch Lehrende, und den Metadaten der Lernobjekte beruhen. Auch auf diesem Gebiet gibt es
zur Zeit mehr Fragen als Antworten, die von der Wissenschaft erst noch beantwortet werden
m¨
ussen. Erste Ans¨
atze gibt es z.B. in [Dolog04; Brusilovsky04]. Andere Systeme versuchen
einen einfacheren Weg einzuschlagen, indem sie Empfehlungen f¨
ur einzelne Lernobjekte geben
[Rashid02]. Das Rahmenwerk dieser Arbeit sollte um entsprechende Algorithmen f¨
ur perso-
nalisiertes Lernen erweitert werden, sobald die Forschung einen akzeptablen Stand erreicht
hat.
F¨
ur das Problem des Auffindens geeigneter Lernobjekte gibt es auch andere Vorschl¨
age,
die nicht auf direkte Automatisierung setzen. Menschen k¨
onnen besser absch¨
atzen, was sich
hinter einem bestimmten Lernobjekt verbirgt, welche Voraussetzungen f¨
ur einen erfolgreichen
Einsatz notwendig sind und wie sie sich mit anderen Lernobjekten kombinieren lassen. Die
Daten hier¨
uber werden an einer zentralen Stelle gespeichert und anderen Interessierten zur
Verf¨
ugung gestellt. Solch ein Bewertungssystem f¨
ur Lernobjekte bietet z.B. das Learning Ob-
ject Review Instrument1(LORI) an [Leacock04; Nesbit04]. Eine ¨
Uberlegung f¨
ur die zuk¨
unftige
Entwicklung des Rahmenwerks ist die Integration eines Bewertungssystems in das Rahmen-
werk, um es an verschiedenen Stellen, z.B. direkt im Autorensystem oder im Repository, zur
Verf¨
ugung zu stellen.
1http://www.eLera.net (29.10.05)
Literaturverzeichnis
[Ahronheim98] Judith R. Ahronheim: Descriptive metadata: Emerging standards. In:
Journal of Academic Librarianship, 24(5), 1998, pp. 395–403.
[Aliprand03] Joan Aliprand, Julie Allen and Ken Whistler (eds.): The Unicode Standard
Version 4.0. Addison Wesley, 2003.
[Ammelburger03] Dirk Ammelburger: XML. Hanser Fachbuchverlag, 2003.
[Aristoteles82] Aristoteles: Poetik, griechisch-deutsch.¨
Ubersetzt von Manfred Fuhrmann,
Reclam, 1982.
[Atif03] Yacine Atif, Rachid Benlamri and Jawad Berri: Learning objects based
framework for self-adaptive learning. In: Education and Information Tech-
nologies, 8(4), 2003.
[Atkinson69] Richard C. Atkinson and H. A. Wilson (eds.): Computer-assisted instruc-
tion: a book of readings. Academic Press, 1969.
[Baker00] Thomas Baker: A grammar of dublin core. In: D-Lib Magazine, 6(10),
2000.
[Baker01] Thomas Baker, Makx Dekkers, Rachel Heery, Manjula Patel and Gau-
ri Salokhe: What terms does your metadata use? application profiles as
machine-understandable narratives. In: Journal of Digital Information,
2(2), 2001.
[Baker03] Thomas Baker, Thomas Baker, Dan Brickley, Erik Duval, Erik Duval, Pete
Johnston, Pete Johnston, Heike Neuroth and Heike Neuroth: Principles of
metadata registries. Technical report, DELOS Working Group on Regis-
tries, 2003.
[Balbieris02] Giedrius Balbieris and Vytautas Reklaitis: Reshaping e-learning content to
meet the standards. In: Informatics in Education, 1(1), 2002, pp. 5–16.
[Balzert00] Helmut Balzert: Lehrbuch der Software-Technik. Spektrum Akademischer
Verlag, 2000.
[Bauch03] Manfred Bauch and Luise Unger: Interactive mathematics with math-kit —
distance learning versus face-to-face learning. In: Proc. 21st ICDE World
Conference on Open Learning & Distance Education, 2003.
[Baudry02a] A. Baudry, M. Bungenstock and B. Mertsching: Architecture of an e-
learning system with embedded authoring support. In: Margaret Driscoli
and Thomas C. Reeves (eds.): E-LEARN 2002–World Conference on E-
Learning in Corp., Govt., Health., & Higher Ed., 2002, pp. 110–116.
188 LITERATURVERZEICHNIS
[Baudry02b] A. Baudry, M. Bungenstock and B. Mertsching: Ein multimediales Rah-
menwerk f¨
ur die Mathematiklehre nach der Baukastenmetapher. In:
Klaus P. Jantke, Wolfgang S. Wittig and J¨
org Herrmann (eds.): Von e-
Learning bis e-Payment. Das Internet als sicherer Marktplatz (LIT ’02).
Infix, 2002, pp. 300–307.
[Baudry03] A. Baudry, M. Bungenstock and B. Mertsching: Nyx - a tool for generating
standard compatible e-learning courses with consistent and adaptable pre-
sentation. In: The IASTED International Conference on Computers and
Advanced Technology in Education (CATE 2003), 2003, pp. 265–269.
[Baudry04a] A. Baudry, M. Bungenstock and B. Mertsching: Administration and deve-
lopment of modular learning units with the construction kit server. In:
Proc. ED-MEDIA 2004–World Conference on Educational Multimedia,
Hypermedia & Telecommunications, 2004.
[Baudry04b] A. Baudry, M. Bungenstock and B. Mertsching: Reusing document formats
for modular course development. In: IASTED International Conference on
WEB-BASED EDUCATION (WBE 2004), 2004, pp. 535–537.
[Baumgartner97] Peter Baumgartner and Sabine Payr: Konstruktivismus und Kognitions-
wissenschaft. Kulturelle Wurzeln und Ergebnisse, chapter Erfinden lernen,
pp. S. 89–106. Springer, 1997.
[Baumgartner99] Peter Baumgartner and Sabine Payr: Lernen mit Software. Studienverlag
Ges. mbH, 1999. ISBN:3706514443.
[Baumgartner02a] Peter Baumgartner, Hartmut H¨
afele and Kornelia Maier-H¨
afele: E-
Learning Praxishandbuch, Auswahl von Lernplattformen. Studien Verlag,
2002.
[Baumgartner02b] Peter Baumgartner, Kornelia H¨
afele and Hartmut H¨
afele: E-Learning: Di-
daktische und technische Grundlagen. In: CD Austria, 5, pp. 4–32.
[Bearman99] David Bearman, Godfrey Rust, Stuart Weibel, Eric Miller and Jennifer
Trant: A common model to support interoperable metadata. In: D-Lib
Magazine, 5(1), 1999.
[Beckett03] Dave Beckett. Rdf/xml syntax specification (revised), December 2003.
[Belqamsi02] Youssef Belqamsi: Using XML in elearning courses. In: E-LEARN 2002–
World Conference on E-Learning in Corp., Govt., Health., & Higher Ed.,
2002, pp. 1183–1186.
[Bentley95] Richard Bentley, Thilo Horstmann, Klaas Sikkel and Jonathan Trevor: Sup-
porting collaborative information sharing with the world wide web: The
bscw shared workspace system. In: The World Wide Web Journal: Procee-
dings of the 4th International WWW Conference, pp. 63–74.
[Berners-Lee94] T. Berners-Lee, L. Masinter and M. McCahill: Uniform Resource Locators
(URL). RFC 1738, Internet Engineering Task Force, December 1994.
[Berners-Lee98] T. Berners-Lee, R. Fielding, U.C. Irvine and L. Masinter: Uniform Resource
Identifiers (URI). RFC 2396, Internet Engineering Task Force, August
1998.
[Binstock02] Cliff Binstock, David Peterson and Mitchell Smith: The XML Schema
Complete Reference. Addison-Wesley, 2002.
LITERATURVERZEICHNIS 189
[Biron01] Paul V. Biron and Ashok Malhotra. Xml schema part 2: Datatypes, May
2001.
[Black62] Max Black: Models and Metaphorsr. Studies in language and Philosophy.
Cornell University Press, 1962.
[Blanchi01] Christophe Blanchi and Jason Petrone: Distributed interoperable metadata
registry. In: D-Lib Magazine, 7(12), 2001.
[Bodendorf90] Freimut Bodendorf: Computer in der fachlichen und universit¨
aren Ausbil-
dung. Oldenbourg, 1990.
[Bodoff04] Stephanie Bodoff, Eric Armstrong, Jennifer Ball and Debbie Bode Carson:
The J2EE Tutorial, Second Edition. Addison Wesley, 2004.
[Bourret99] Ronald Bourret, Christof Bornh¨
ovd and Alejandro P. Buchmann: A generic
load/extract utility for data transfer between xml documents and relational
databases. Technical Report DVS99-1, Department of Computer Science -
Darmstadt University of Technology, December 1999.
[Britain00] Sandy Britain and Oleg Liber: A framework for the pedagogical evaluation
of virtual learning environments. In: Proc. of: ALT-C 2000, 2000.
[Bro91] Brockhaus-Enzyklop¨
adie, Bd. 14: mag.–mod., 1991.
[Brusilovsky04] Peter Brusilovsky: Knowledgetree: A distributed architecture for adapti-
ve e-learning. In: Proceedings of the 13th international World Wide Web
conference on Alternate Track Papers & Posters, 2004, pp. 104–113.
[Bungenstock02] M. Bungenstock, A. Baudry and B. Mertsching: The construction kit me-
taphor for a software engineering design of an e-learning system. In: Philip
Barker and Samuel Rebelsky (eds.): Proc. ED-MEDIA 2002–World Con-
ference on Educational Multimedia, Hypermedia & Telecommunications,
2002, pp. 216–217.
[Bungenstock03a] M. Bungenstock, A. Baudry and B. Mertsching: Data exchange between
lyssa and learning management systems. In: E-Learn 2003–World Con-
ference on E-Learning in Corporate, Gov ernment, Healthcare, & Higher
Education, 2003, pp. 31–34.
[Bungenstock03b] M. Bungenstock, A. Baudry and B. Mertsching: Datenaustausch zwischen
Lyssa und Learning Management Systemen. In: Von e-Learning bis e-
Payment. Das Internet als sicherer Marktplatz (LIT ’03), 2003, pp. 126–
132.
[Bungenstock04a] M. Bungenstock, A. Baudry and B. Mertsching: Design of a common api for
learning objects. In: The IASTED International Conference on Computers
and Advanced Technology in Education (CATE 2003), 2004, pp. 345–350.
[Bungenstock04b] M. Bungenstock, A. Baudry and B. Mertsching: Entwicklung eines techni-
schen Rahmenwerks f¨
ur standardkompatible Lernobjekte. In: DELFI 2004
— Tagungsband der 2. e-Learning Fachtagung Informatik, 2004, pp. 151–
162.
[Busch98] Carsten Busch: Metaphern in der Informatik: Modellbildung, Formalisie-
rung, Anwendung. Deutscher Universit¨
ats-Verlag GmbH, 1998.
[B¨
uchmann94] Georg B¨
uchmann and Eberhard Urban: Der neue B¨
uchmann. Gefl¨
ugelte
Worte. Bassermann, 1994.
190 LITERATURVERZEICHNIS
[Carnell03] John Carnell, J. Linwood and M. Zawadzki: Professional Struts Applicati-
ons. Apress, 2003.
[Case78] R. Case: A developmentally based theory and technology of instruction.
In: Review of Educational Research, 48, pp. 439–463.
[Case85] R. Case: Thinking and Learning Skills — Research and Open Questions,
vol. 2, chapter A Developmentally based Approach to the Problem of In-
structional Design, pp. 537–545. Lawrence Erlbaum Assoc, 1985.
[Cavaness04] Chuck Cavaness: Programming Jakarta Struts. O’Reilly, 2004.
[CEN03] European Committee For Standardization: CEN Workshop Agreement
CWA 14855: Dublin Core Application Profile Guidelines, November 2003.
[Chapman03] Bryan Chapman: LCMS Report: Comparative Analysis of Enterprise Lear-
ning Content Management Systems. brandon-hall.com, 2003.
[Cis99] Cisco Systems: Reusable Information Object Strategy, June 1999. Version
3.0.
[Clemm99] G. Clemm, J. Amsden, T. Ellison, C. Kaler and J. Whitehead: Versioning
extensions to webdav. RFC 3253, Network Working Group, Februar 1999.
[CTGV90] CTGV: Anchored instruction and its relationship to situated cognition. In:
Educational Researcher, 19(6), 1990, pp. 2–10.
[CTGV93] CTGV: Anchored instruction and situated cognition revisted. In: Educa-
tional Technology, 33(3), 1993, pp. 52–70.
[Dahn01] Ingo Dahn: Slicing book technology — providing online support for text-
books. In: ICDE 2001, International Conference on Distant Education,
2001.
[Dahn02] Ingo Dahn, Michael Armbruster, Ulrich Furbach and Gerhard Schwa-
be: Writing hypertext and learning: Conceptual and empirical approaches,
chapter Slicing Books The Authors’ Perspective. Pergamon, 2002.
[Dawson98] F. Dawson and T. Howes: vcard mime directory profile. RFC 2426, Network
Working Group, September 1998.
[Dekkers01] Makx Dekkers: Application profiles, or how to mix and match metadata
schemas. In: Cultivate Interactive, 3.
[Depke99] Ralph Depke, G. Engels, K. Mehner, S. Sauer and A. Wagner: Ein Vor-
gehensmodell f¨
ur die Multimedia-Entwicklung mit Autorensystemen. In:
Informatik Forschung und Entwicklung, 14, pp. 83–94.
[Deutsch96] Peter Deutsch: DEFLATE compressed data format specification version
1.3. RFC 1951, Aladdin Enterprises, May 1996.
[Dittler03] Ullrich Dittler (ed.): E-Learning : Einsatzkonzepte und Erfolgsfaktoren des
Lernens mit interaktiven Medien. Oldenbourg, 2003.
[Dodd04a] Philip Dodd and Schawn E. Thropp: Sharable content object reference
model (scorm) — content aggregation model (cam) version 1.3.1. Technical
report, Advanced Distributed Learning, 2004.
LITERATURVERZEICHNIS 191
[Dodd04b] Philip Dodd and Schawn E. Thropp: Sharable content object reference mo-
del (scorm) — run-time environment (rte) version 1.3.1. Technical report,
Advanced Distributed Learning, 2004.
[Dodd04c] Philip Dodd and Schawn E. Thropp: Sharable content object reference
model (scorm) 2004 — overview. Technical report, Advanced Distributed
Learning, 2004.
[Dolog04] Peter Dolog, Nicola Henze, Wolfgang Nejdl and Michael Sintek: Personali-
zation in distributed e-learning environments. In: Proceedings of the 13th
international World Wide Web conference on Alternate Track Papers &
Posters, 2004, pp. 170–179.
[Downes00a] Stephen Downes. Learning objects. Presented at Leaders in Learning 2000,
May 2000.
[Downes00b] Stephen Downes: Nine rules for good technology. In: The Technology Sour-
ce.
[Downes02] Stephen Downes. The learning object economy. Published by Contact
North, October 2002.
[Downes03] Stephen Downes, Magda Mourad, Harry Piccariello and Robby Robson:
Digital rights management in e-learning — problem statement and terms of
reference. In: E-Learn 2003–World Conference on E-Learning in Corporate,
Gov ernment, Healthcare, & Higher Education, 2003.
[Dreyfus86] Hubert L. Dreyfus, Stuart E. Dreyfus and T. Anthanasiou: Mind Over
Machine: The Power of Human Intuition and Expertise in the Era of the
Computer. The Free Press, 1986. ISBN: 0743205510.
[Dub99] Dublin Core Metadata Initiative: Dublin Core Metadata Element Set, Ver-
sion 1.1: Reference Description, July 1999.
[Duval00] Eric Duval, E. Vervaet, B. Verhoeven, K. Hendrikx, K. Cardinaels, H. Oli-
vi´e, E. Forte, F. Haenni, K. Warkentyne, M. Wentland-Forte and F. Si-
million: Managing digital educational resources with the ariadne metadata
system. In: Journal of Internet Cataloging, 3(2/3), 2000, pp. 145–171.
[Duval02] Erik Duval, Wayne Hodgins, Stuart Sutton and Stuart L. Weibel: Metadata
principles and practicalities. In: D-Lib Magazine, 8(4), 2002.
[Duval03] Erik Duval and Wayne Hodgins: A lom research agenda. In: WWW2003 -
Twelfth InternationalWorldWideWeb Conference, May 2003.
[Englander97] Robert Englander: Developing Java Beans. O’Reilly, 1997.
[Farrell04] Robert G. Farrell, Soyini D. Liburd and John C. Thomas: Dynamic assemb-
ly of learning objects. In: Proceedings of the 13th international World Wide
Web conference on Alternate Track Papers & Posters, 2004, pp. 162–169.
[Farreres03] Javier Farreres: The Dsssl Book: An XML/SGML Programming Language.
Kluwer Academic Publishers, 2003.
[Foerster95] Heinz von Foerster: Die erfundene Wirklichkeit. Wie wissen wir, was wir zu
wissen glauben., chapter Das Konstruieren einer Wirklichkeit. Paul Watz-
lawick and Peter Krieg, 1995.
192 LITERATURVERZEICHNIS
[Freed96] N. Freed and N. Borenstein: Multipurpose internet mail extensions — (mi-
me) part two: Media types. RFC 2046, Network Working Group, November
1996.
[Freitag02a] Burkhard Freitag: LMML — Eine XML-Sprachfamilie f¨
ur eLearning Con-
tent. In: Informatik bewegt: Informatik 2002 — 32. Jahrestagung der Ge-
sellschaft f¨
ur Informatik e.v. (GI), 2002, pp. 349–353.
[Freitag02b] Burkhard Freitag, Christian S¨
uß and Claus Dziarstek: Adaptation und
Wiederverwendung von XML-basiertem eLearning-Content. In: Informatik
bewegt: Informatik 2002 — 32. Jahrestagung der Gesellschaft f¨
ur Informa-
tik e.v. (GI), 2002, pp. 354–358.
[Friesen02] Norm Friesen, Jon Mason and Nigel Ward: Building educational metadata
application profiles. In: Proceedings of the International Conference on
Dublin Core and Metadata for e-Communities 2002, 2002, pp. 63–69.
[Gamma95] Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Desing
Patterns: elements or reusable object-oriented software. Addison Wesley,
1995.
[Gibbons02] Andrew S. Gibbons, Jon Nelson and Robert Richards: The Instructional
Use of Learning Objects, chapter The Nature and Origin of Instructional
Objects. AIT/AECT, 2002.
[Gill98] Tony Gill, Anne Gilliland-Swetland and Murtha Baca: Introduction to Me-
tadata: Pathways to Digital Information. Getty Research Institute, 1998.
[Goland99] Y. Goland, E. Whitehead, A. Faizi, S. Carter and D. Jensen: Http exten-
sions for distributed authoring — webdav. RFC 2518, Network Working
Group, Februar 1999.
[Goldfarb91] Charles F. Goldfarb and Yuri Rubinsky: SGML Handbook. Oxford Univer-
sity Press, 1991.
[Gosling96] James Gosling, Bill Joy and Guy L. Steele: The Java Language Specifica-
tion. Addison Wesley, 1996.
[Gourley02] David Gourley and Brian Totty: HTTP, The Definitive Guide. O’Reilly,
2002.
[Griffel98] Frank Griffel: Componentware. dpunkt-Verlag, 1998.
[Griffin97] Steve Griffin and Tom Wason: The year of metadata. In: Educom Review,
32(6), 1997, pp. 56–58.
[Hall00] Brandon Hall: Learning Management Systems 2001: How to Choose the
Right System for Your Organization. brandon-hall.com, 2000.
[Hall03] Brandon Hall: LMS 2003: Comparison of Enterprise Learning Management
Systems. brandon-hall.com, 2003.
[Hansch02] Matthias Hansch, Stefan Kuhlins and Martin Schader: XML Schema. In:
Informatik Spektrum, 25(3), 2002, pp. 363–366.
[Haverkamp83] Anselm Haverkamp: Theorie der Metapher, chapter Die Metapher, von
Max Black. Wissenschaftliche Buchgesellschaft, 1983.
LITERATURVERZEICHNIS 193
[Heery00] Rachel Heery and Manjula Patel: Application profiles: mixing and mat-
ching metadata schemas. In: Ariadne, 25.
[Heery02] Rachel Heery, Pete Johnston, Dave Beckett and Damian Steer: The meg
registry and scart: complementary tools for creation, discovery and re-use
of metadata schemas. In: Proceedings of the International Conference on
Dublin Core and Metadata for e-Communities 2002, 2002, pp. pp 63–69.
[Heery03] Rachel Heery, Pete Johnston, Csaba F¨
ul¨
op and Andr´as Micsik: Metadata
schema registries in the partially semantic web: the cores experience. In:
Proceedings of the 2003 Dublin Core Conference: Supporting Communities
of Discourse and Practice - Metadata Research and Applications, Septem-
ber/October 2003.
[Hjelm01] Johan Hjelm: Creating the Semantic Web with RDF. John Wiley & Sons,
2001.
[Hodgins00] Wayne Hodgins. Into the future - a vision paper. erh¨
altlich bei Commissi-
on on Technology & Adult Learning of the American Society for Training
& Development (ASTD) und National Governors’ Association (NGA), Fe-
bruary 2000.
[Hodgins02] Wayne Hodgins: The future of learning objects. In: Proc. of the 2002 eTEE
Conference, August 2002, pp. 76–82.
[Howes98] T. Howes, M. Smith and F. Dawson: A MIME content-type for directory
information. RFC 2425, Network Working Group, September 1998.
[Humbert05] Ludger Humbert: Didaktik der Informatik. Teubner, 2005. ISBN:
3835100386.
[Hunter01] Jane Hunter and Carl Lagoze: Combining rdf and xml schemas to enhance
interoperability between metadata application profiles. In: Proc. of the
Tenth International Conference on World Wide Web. ACM, 2001, pp. 457–
466.
[H¨
afele03] Hartmut H¨
afele and Kornelia Maier-H¨
afele. Autorenwerkzeuge f¨
ur Lear-
ning Content. Portal des bm:bwk bildung.at, 2003.
[Iannella01] Renato Iannella: Digital rights management (drm) architectures. In: D-Lib
Magazine, 7(6), 2001.
[IEE] IEEE P1484.12: Standard for Resource Description Framework (RDF) bin-
ding for Learning Object Metadata data model.
[IEE02a] IEEE P1484.12: Draft Standard for Learning Object Metadata, 2002.
[IEE02b] IEEE P1484.12: Standard for XML binding for Learning Object Metadata
data model, 2002.
[IMS01] IMS. IMS learning resource meta-data information model — version 1.2.1
final specification, 2001.
[IMS03a] IMS. IMS digital repositories interoperability, 2003.
[IMS03b] IMS. Ims learning resource meta-data best practice and implementation
guide - version 1.2.1 final specification, 2003.
194 LITERATURVERZEICHNIS
[IMS04a] IMS. IMS content packaging information model — version 1.1.4 final spe-
cification, 2004.
[IMS04b] IMS. IMS question and test interoperability, 2004.
[IMS05] IMS. Ims learner information package, 2005.
[Ingendahl71] Werner Ingendahl: Der methaphorische Prozess. Methodologie zu seiner
Erforschung und Systematisierung. P¨
adagogischer Verlag Schwann, 1971.
[Int88] International Organization for Standardization (ISO): ISO 639-1:2002. Co-
des for the representation of names of languages — Part 1: Alpha-2 code,
first edition, April 1988.
[Int97] International Organization for Standardization (ISO): ISO 3166-1:1997.
Codes for the representation of names of countries and their subdivisions
— Part 1: Country codes, first edition, September 1997.
[Int98] International Organization for Standardization (ISO): ISO 639-2:1998. Co-
des for the representation of names of languages — Part 2: Alpha-3 code,
first edition, November 1998.
[Int00] International Organization for Standardization (ISO): ISO 8601:2000. Da-
ta elements and interchange formats — Information interchange — Repre-
sentation of dates and times, second edition, December 2000.
[Int02] International Organization for Standardization (ISO): ISO/IEC 10646-
1:2000. Information technology — Universal Multiple-Octet Coded Cha-
racter Set (UCS) — Part 1: Architecture and Basic Multilingual Plane,
second edition, December 2002.
[Johnson04] Rod Johnson and Juergen Hoeller: Expert One-on-One J2EE Development
without EJB. Wrox, 2004.
[Kerres98] M. Kerres: Multimediale und telemediale Lernumgebungen - Konzeption
und Entwicklung. Oldenbourg Verlag, 1998.
[Klein99] Gary Klein: Sources of Power: How People Make Decisions. The MIT
Press, 1999. ISBN: 0262611465.
[Klimsa93] Paul Klimsa: Neue Medien und Weiterbildung. Anwendung und Nutzung
in Lernprozessen der Weiterbildung. Deutscher Studienverlag, 1993.
[Kohlhase00] Michael Kohlhase: Omdoc: An infrastructure for openmath content dic-
tionary information. In: Bulletin of the ACM Special Interest Group for
Algorithmic Mathematics SIGSAM, 2000.
[Kohlhase02] Michael Kohlhase: Omdoc: An open markup format for mathematical do-
cuments (version 1.1). Technical report, Carnegie Mellon University, 2002.
[Kolodner93] Janet Kolodner: Case-Based Reasoning. Morgan Kaufmann Publishers,
1993.
[Kortzfleisch99] Harald von Kortzfleisch, Ulrike Heller and Udo Winand: Perspektiven der
Medienwirtschaft. Kompetenz, Akzeptanz, Gesch¨
aftsfelder. Telekommuni-
kation & Mediendienste 5, chapter Das ”Forum Virtuelle Lernwelten”, pp.
51–73. Josef Eul Verlag, 1999.
LITERATURVERZEICHNIS 195
[Krieg-Br¨
uckner04] Bernd Krieg-Br¨
uckner, Arne Lindow, Christoph L¨
uth, Achim Mahnke and
George Russell: Semantic interrelation of documents via an ontology. In:
DELFI 2004 — Tagungsband der 2. e-Learning Fachtagung Informatik,
2004, pp. 271–282.
[Leacock04] Tracey L. Leacock, Griff Richards and John C. Nesbit: Teachers need sim-
ple, effective tools to evaluate learning objects: Enter elera.net. In: Seventh
IASTED International Conference — Computers and Advanced Technolo-
gies in Education, 2004, pp. 333–338.
[Lenz98] Mario Lenz, Brigitte Bartsch-Sp¨
orl, Hans-Dieter Burkhard and Stefan Wess
(eds.): Case-Based Reasoning Technology: From Foundations to Applicati-
ons. Springer Verlag, 1998.
[Letts02] Mike Letts: ADL and SCORM: Creating a standard model for publishing
courseware. In: Seybold Report - Analyzing Publishing Technologies, 2(1),
2002, pp. 3–8.
[Louden94] Kenneth C. Louden: Programmiersprachen. Grundlagen, Konzepte, Ent-
wurf. VMI Buch AG, 1994.
[Low02] Boon Low: Packaging educational content using IMS specifications. In:
VINE, 127, pp. 40–46.
[Manola03] Frank Manola and Eric Miller. Rdf primer, December 2003.
[Martinez00] Margaret Martinez: The Instructional Use of Learning Objects, chapter
Designing Learning Objects to Personalize Learning. AIT/AECT, 2000.
[Mason00] Jon Mason, Graham Adcock and Albert IP: Modeling information to sup-
port value-adding: Edna online. In: WebNet Journal: Internet Technologies,
Applications & Issues, 2(3), 2000, pp. 38–45.
[McDaniel03] Mason McDaniel and M. Hossain Heydari: Content based file type detection
algorithms. In: Proceedings of the 36th Hawaii International Conference
on System Sciences - 2003, 2003.
[Metzinger99] Thomas Metzinger: Subjekt und Selbstmodell. Mentis-Verlag, 1999. ISBN:
3897850818.
[Meyer97] Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall,
1997.
[Meyer02] Eric A. Meyer: On CSS. New Riders Publishing, 2002.
[Milligan00] Colin Milligan: The role of virtual learning environments in the online deli-
very of staff development. Technical Report 44, Joint Information Systems
Committee, 2000.
[Minsky94] Marvin L. Minsky: Mentopolis. Klett-Cotta, 1994.
[Mintert02] Stefan Mintert: XML & Co. Die W3C-Spezifikationen f¨
ur Dokumenten-
und Datenarchitektur. Addison-Wesley, 2002.
[Mosley05] Pauline Mosley: A taxonomy for learning object technology. In: J. Comput.
Small Coll., 20(3), 2005, pp. 204–216.
196 LITERATURVERZEICHNIS
[Nagamori01] Mitsuharu Nagamori, Thomas Bakery, Tetsuo Sakaguchi and Tetsuo Sa-
kaguchi Mitsuharu Nagamori, Thomas Bakery: A multilingual metadata
schema registry based on rdf schema. In: Proc. Int l. Conf. on Dublin Core
and Metadata Applications 2001, 2001, pp. pp 209–212.
[Najjar03] Jehad Najjar, Stefaan Ternier and Erik Duval: The actual use of metadata
in ariadne: an empirical analysis. In: 3rd Annual Ariadne Conference, 2003.
[Negroponte96] Nicholas Negroponte: Being Digital. Vintage, 1996.
[Nejdl02] Wolfgang Nejdl, B. Wolf, C. Qu, S. Decker, M. Sintek, A. Naeve, M. Nilsson,
M. Palm´er and T. Risch: Edutella: A p2p networking infrastructure based
on rdf. In: Proc. of the Eleventh International Conference on World Wide
Web. ACM, 2002, pp. 604–615.
[Nesbit04] John C. Nesbit, Tracey L. Leacock and Cindy Xin: Learning object eva-
luation and convergent participation: Tools for professional development in
e-learning. In: Seventh IASTED International Conference — Computers
and Advanced Technologies in Education, 2004, pp. 339–344.
[Neven02] Filip Neven and Erik Duval: Reusable learning objects: a survey of lom-
based repositories. In: Proc. of ACM Multimedia. ACM, 2002, pp. 291–294.
[Newman03] Tabetha Newman: Scorm force. In: Conspectus, pp. 18–20.
[Niegemann04] Helmut M. Niegemann, Silvia Hessel, Dirk Hochscheid-Mauel, Kristina
Aslanski, Markus Deimann and Gunther Kreuzberger: Kompendium E-
Learning. Springer-Verlag, 2004.
[Nilsson03] Mikael Nilsson, Matthias Palm´er and Jan Brase. The lom rdf binding -
principles and implementation. Paper to 3rd Annual Ariadne Conference,
Katholieke Universiteit Leuven, Belgium, November 2003.
[Obj03] Object Management Group: Unified Modeling Language (UML), version
1.5, formal/03-03-01 edition, 2003.
[Padberg02a] Kathrin Padberg and Sabine Schiller: Web-based drills in maths using a
computer algebra system. In: Proc. ED-MEDIA 2002–World Conference
on Educational Multimedia, Hypermedia & Telecommunications, 2002.
[Padberg02b] Kathrin Padberg and Andreas Sorgatz: Webbasierte ¨
Ubungselemente mit
MuPAD. In: Computeralgebra in Lehre, Ausbildung und Weiterbildung III,
2002.
[Pawlowski01] Jan M. Pawlowski: Das Essener-Lern-Modell (ELM): Ein Vorgehensmo-
dell zur Entwicklung computerunterst¨
utzter Lernumgebungen. PhD thesis,
Universit¨
at Essen, 2001.
[Pawson02] Dave Pawson: XSL-FO. O’Reilly, 2002.
[Powers03] Shelley Powers: Practical RDF. O’Reilly, 2003.
[Qin04] Jian Qin and Naybell Hern&#225;ndez: Ontological representation of lear-
ning objects: building interoperable vocabulary and structures. In: Procee-
dings of the 13th international World Wide Web conference on Alternate
Track Papers & Posters, 2004, pp. 348–349.
LITERATURVERZEICHNIS 197
[Rashid02] Al Mamunur Rashid, Istvan Albert, Dan Cosley, Shyong K. Lam, Sean M.
McNee, Joseph A. Konstan and John Riedl: Getting to know you: Learning
new user preferences in recommender systems. In: Proceedings of the 7th
international conference on Intelligent user interfaces, 2002, pp. 127–134.
[Ray01] Erik T. Ray: Learning XML — Guide to Creating Self-Describing Data.
O’Reilly, 2001.
[Rehberg03] Bettina Rehberg and Ulrich Rehberg: Efficient development of multimedia
applets for elearning. In: Proc. 21st ICDE World Conference on Open
Learning & Distance Education, 2003.
[Reigeluth80] Charles M. Reigeluth, M.D. Merrill, B.G. Wilson and R.T. Spiller: The
elaboration theory of instruction: A model for structuring instruction. In:
Instructional Science, 9, pp. 125–219.
[Reigeluth83] Charles M. Reigeluth and F.S. Stein: Instructional Design Theories and
Models: An Overview of Their Current Status, chapter The Elaboration
Theory of Instruction. Lawrence Erlbaum, 1983.
[Reigeluth99] Charles M. Reigeluth: Instructional Design — Theories and Models. A New
Paradigm of Instructional Theory, chapter The Elaboration Theory: Gui-
dance for Scope and Sequence Decisions, pp. 425–453. Lawrence Erlbaum,
1999.
[Roisin98] C´ecile Roisin: Authoring structured multimedia documents. In: SOF-
SEM ’98: Theory and Practice of Informatics: 25th Conference on Current
Trends in Theory and Practice of Informatics, 1998, pp. 222–239.
[Saddik00] Abdulmotaleb El Saddik, Amir Ghavam, Stephan Fischer and Ralf Stein-
metz: Metadata for smart multimedia learning objects. In: Proc. of the
Australasian conference on Computing education, December 2000, pp. 87–
94.
[Saddik01] Abdulmotaleb El Saddik, Stephan Fischer and Ralf Steinmetz: Reusability
and adaptability of interactive resources in web-based educational systems.
In: Journal on Educational Resources in Computing (JERIC), 1(4), 2001.
[Santos04] Osvaldo A. Santos and Fernando M. S. Ramos: Proposal of a framework
for internet based licensing of learning objects. In: Comput. Educ., 42(3),
2004, pp. 227–242.
[Schiller02] Sabine Schiller and Luise Unger: Math-kit: a multimedia project for lear-
ning and teaching mathematics. In: Proceedings 10th Meeting of European
Women in Mathematics, 2002, pp. 383–386.
[Schulmeister00] Rolf Schulmeister: Selektions- und Entscheidungskriterien f¨
ur die Aus-
wahl von Lernplattformen und Autorenwerkzeugen. Technical report, ¨
Os-
terreichisches Bundesministeriums f¨
ur Bildung, Wissenschaft und Kultur
(bm:bwk), 2000.
[Schulmeister01] Rolf Schulmeister: Virtuelle Universit¨
at — Virtuelles Lernen. Oldenbourg,
2001.
[Schulmeister03] Rolf Schulmeister: Lernplattformen f¨
ur das virtuelle Lernen. Oldenbourg,
2003.
198 LITERATURVERZEICHNIS
[Schwabe01] Gerhard Schwabe, Norbert Streitz and Raine Unland (eds.): CSCW-
Kompendium Lehr- und Handbuch zum computerunterst¨
utzten kooperati-
ven Arbeiten . Springer, 2001.
[Sch¨
oning03] Harald Sch¨
oning: XML und Datenbanken. Carl Hanser Verlag, 2003.
[Searle86] John R. Searle: Geist, Hirn und Wissenschaft : die Reith lectures 1984.
Suhrkamp, 1986.
[Seifert80] Walter Seifert: Sprachbetrachtung und Kommunikationsanalys, chapter Di-
daktik rhetorischer Figuren: Metapher als Unterrichtsgegenstand, pp. 129–
138. K¨
onigstein/Taunus, 1980.
[Shackelford02] Bill Shackelford: A scorm odyssey. In: T+D, 56(8), 2002, pp. 31–35.
[Shannon04] Bill Shannon, Mark Hapner, Vlada Matena, James Davidson, James Da-
vidson and Larry Cable: Java 2 Platform, Enterprise Edition: Platform
and Component Specifications. Addison Wesley, 2004.
[Shore85] John Shore: Sachertorte Algorithm and Other Antidotes to Computer An-
xiety. Viking Press, 1985.
[Simon01] Bernd Simon: E-Learning an Hochschulen: Gestaltungsr¨
aume und Erfolgs-
faktoren von Wissensmedien. Josef Eul Verlag, 2001.
[Simpson02] John E. Simpson: XPath and XPointer. O’Reilly, 2002.
[Skinner54] Burrhus F. Skinner: The science of learning, and the art of teaching. In:
Harvard Educational Review, 24(2), 1954, pp. 86–97.
[Slein98] J. Slein, F. Vitali, E. Whitehead, U.C. Irvine and D. Durand: Requirements
for a distributed authoring and versioning protocol for the world wide web.
RFC 2291, Network Working Group, Februar 1998.
[South02] Joseph B. South and David W. Monson: The Instructional Use of Learning
Objects, chapter A University-wide System for Creating, Capturing, and
Delivering Learning Objects. AIT/AECT, 2002.
[Spiro88] Rand J. Spiro, Richard L. Coulson, Paul J. Feltovich and Michael J. Ja-
cobson: Cognitive flexibility theory: Advanced knowledge acquisition in
ill-structured domains. In: Proceedings of the 10th Annual Conference of
the Cognitive Science Society. Lawrence Erlbaum Associates, 1988.
[Spiro91] Rand J. Spiro, Paul J. Feltovich, Michael J. Jacobson and Richard L. Coul-
son: Cognitive flexibility, constructivism, and hypertext: Random access
instruction for advanced knowledge acquisition in ill-structured domains.
In: Educational Technology, 31(5), 1991, pp. 24–33.
[Stevens94] W. Richard Stevens: TCP/IP Illustrated, Vol.1 : The Protocols. Addison-
Wesley, 1994.
[Stevens96] W. Richard Stevens: TCP/IP Illustrated, Vol.3 : TCP for Transactions,
HTTP, NNTP, and the UNIX Domain Protocols. Addison-Wesley, 1996.
[Sun99] Sun Microsystems, Inc.: WebNFS Client SDK, 1999.
[Sun01] Sun Microsystems, Inc.: Java 2 Platform, Standard Edition, v 1.3.1, API
Specification, 2001.
LITERATURVERZEICHNIS 199
[Sweet85] Richard E. Sweet: The mesa programming environment. In: SIGPLAN
Notices, 20(7), 1985, pp. 216–229.
[Szyperski98] Clemens Szyperski: Component Software: beyond object-oriented software.
Addison Wesley, 1998.
[Tanenbaum97] Andrew S. Tanenbaum and Albert S. Woodhull: Operating Systems: Design
and Implementation — 2nd ed. Prentice Hall, 1997.
[Tate04] Bruce A. Tate and Justin Gehtland: Better, Faster, Lighter Java. O’Reilly,
2004.
[Teege02] Gunnar Teege and Peter Breitling: Targeteam: Adaptierbare Lehrinhalt auf
Basis on XML und XSLT. In: Informatik bewegt: Informatik 2002 — 32.
Jahrestagung der Gesellschaft f¨
ur Informatik e.v. (GI), 2002, pp. 364–368.
[Thiere03a] Bianca Thiere, Gudrun Oevel and Kathrin Padberg: Mathematics in engi-
neering education with math-kit. In: Proc. of 7th Baltic Region Seminar
on Engineering Education, Septembe 2003.
[Thiere03b] Bianca Thiere, Kathrin Padberg and Gudrun Oevel: Learning mathematics
through a multimedia construction kit. In: Proc. SITE2003, March 2003,
pp. 24–29.
[Tidwell01] Doug Tidwell: XSLT. O’Reilly, 2001.
[Tulodziecki96] G. Tulodziecki, W. Hagemann, B. Herzig, S. Leufen and C. M¨
utze: Neue
Medien in den Schulen: Projekte-Konzepte-Kompetenzen. Verlag Bertels-
mann Stiftung, 1996.
[Turan04] Nurdan Turan and Yıldız S¨
unneli: Entwicklung einer Software-
Komponente zur Integration bestehender Lehr- und Lernmaterialien und
deren Metadaten in das mαth-kit-System. Master’s thesis, Universit¨
at
Hamburg, 2004.
[Turner03] James Turner and Kevin Bedell: Struts. Addison-Wesley, 2003.
[Unger02] Luise Unger, Gudrun Oevel and B¨
arbel Mertsching: Web-based teaching
and learning with math-kit. In: Proc. 2th International Conference on the
Teaching of Mathematics, 2002.
[Unger04] Luise Unger, M. Bauch, A. Baudry, M. Bungenstock, B. Mertsching, G. Oe-
vel, K. Padberg and B. Thiere: math-kit — Ein multimedialer Baukas-
ten f¨
ur die Mathematikausbildung im Grundstudium. In: Softwaretechnik-
Trends, 24(1), 2004, pp. 62–71.
[Vitali99] Fabio Vitali: Versioning hypermedia. In: ACM Comput. Surv., 31(4es),
1999, pp. 24.
[Vlist02] Eric van der Vlist: XML Schema. O’Reilly, 2002.
[Vollmann04] Marc Vollmann: Modellierung und Implementation eines Werkzeugs mit
Methoden fallbasierten Schließens zur generischen Anbindung an schlag-
wortbasierte Wissenssysteme. Master’s thesis, Universit¨
at Hamburg, 2004.
[Walsh02a] Norman Walsh: The docbook document type - committee specification 4.2.
Technical report, OASIS, 2002.
200 LITERATURVERZEICHNIS
[Walsh02b] Norman Walsh and Leonard Muellner: DocBook: The Definitive Guide.
O’Reilly & Associates, Inc., 2002. Version 2.0.8.
[Wessner00] Martin Wessner and Hans-R¨
udiger Pfister: Points of cooperation: Inte-
grating cooperative learning into web-based courses. In: Proceedings of
NTCL2000 International Workshop on New Technologies for Collaborative
Learning, 2000, pp. 33–41.
[Wiley99] David A. Wiley. The post-lego learning object. Homepage, 1999.
[Wiley00a] David A. Wiley: Learning object design and sequencing theory. PhD thesis,
Department of Instructional Psychology and Technology Brigham Young
University, 2000.
[Wiley00b] David A. Wiley, Mimi Recker and Andy Gibbons. A reformulation of the
issue of learning object granularity and its implications for the design of
learning objects. Homepage, 2000.
[Wiley02] David A. Wiley: The Instructional Use of Learning Objects, chapter
Connecting learning objects to instructional design theory: A definition,
a metaphor, and a taxonomy. AIT/AECT, 2002.
[Wolff82] Gerhart Wolff: Metaphorischer Sprachgebrauch. Reclam, 1982.
[Wollowski02] Michael Wollowski: Xml based course websites. In: E-LEARN 2002–World
Conference on E-Learning in Corp., Govt., Health., & Higher Ed., 2002,
pp. 1043–1048.
[Wozniak94] Robert H. Wozniak: Reflex, habit and implicit response: The early elabora-
tion of theoretical and methodological behaviourism, chapter Behaviourism:
the early years. Routledge/Thoemmes Press, 1994.
[Wright95] Gary R. Wright and W. Richard Stevens: TCP/IP Illustrated, Vol.2 : The
Implementation. Addison-Wesley, 1995.
[Z¨
ullighoven98] Heinz Z¨
ullighoven, Dirk B¨
aumer and Wolf-Gideon Bleek: Das objektorien-
tierte Konstruktionshandbuch. Dpunkt Verlag, 1998.