Ziele setzen!

Integration einer
objektorientierten Datenbank
in eine intranetbasierte
Lernumgebung
Inhalt
Kontext
Akt III
Szene 2
Diplomand:
Stefan Grimm
Funktionalität
Kontext
Betreuer:
Prof. Dr. M. Kerres
Prof. Dr. M. Waldowski
Diplomarbeit an der
Fachhochschule Furtwangen
Fachbereich Digitale Medien
Studiengang Medieninformatik
Sommersemester 1998
Funktionen
Daten
Objektmetapher
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
EIDESSTATTLICHE ERKLÄRUNG
Ich erkläre hiermit an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und ohne unzulässige fremde Hilfe angefertigt habe.
Sämtliche verwendeten Quellen und Hilfsmittel sind zitiert.
Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt
und auch noch nicht veröffentlicht.
Weil am Rhein, den 31. Juli 1998
Stefan Grimm
Seite 2
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
VORBERMERKUNGEN & DANKESCHÖNS
Diese Diplomarbeit entstand in Zusammenarbeit mit der Firma HQ Interaktive Mediensysteme
GmbH, Weil am Rhein. Die Firma HQ ist ein führender Hersteller computerunterstützter Lernprogramme und Anbieter von Assessment-Lösungen. Einige Aspekte der vorliegenden Arbeit sind deshalb maßgeblich von der Arbeitsweise und den Bedürfnissen von HQ beeinflußt.
Für die Unterstützung der Firma HQ bei meiner Arbeit und die zur Verfügung gestellten Resourcen
möchte ich mich an dieser Stelle herzlich bedanken.
Mein besonderer Dank gilt René Künzler für die intensive fachliche Betreuung, Lob und konstruktive
Kritik während des gesamten kreativen Prozesses, sowie Andreas Urwyler für die organisatorische
Unterstützung.
Ein „Dankeschön“ auch an die folgenden Firmen (in alphabetischer Reihenfolge), die mir diese Diplomarbeit durch die freundliche Bereitstellung von Infomaterialien erleichtert haben:
O2 Technology GmbH, Dortmund
POET Software GmbH, Hamburg
Versant Object Technology GmbH, Weiterstadt
Persönliche Thanx gehen an alle Freunde, HQler, meine Eltern und Geschwister.
Ich habe in der vorliegenden Diplomarbeit bei sämtlichen an sich „geschlechtsegalen“ Personenbezeichnungen ausschließlich die „traditionelle“, männliche Form verwendet. Nicht aus Gründen der
Diskriminierung oder Frauenfeindlichkeit – sondern ausschließlich zugunsten der Lesbarkeit („Lernerinnen und Lerner“) und der Vermeidung künstlicher Sprachbeugungen („LernerInnen“). Selbstverständlich beziehen die maskulinen Bezeichnungen immer auch die weibliche Leserschaft mit ein.
Seite 3
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
INHALTSVERZEICHNIS
1.
ZIELE SETZEN!
10
1.1.
1.2.
Multimediale Probleme, die der Lösung harren...
The Road to ...?
10
10
1.2.1. Authoring und Konzeption
1.2.2. Produktion
1.2.3. Rezeption und Navigation
11
11
11
1.3.
1.4.
1.5.
Die Welt ist eine Datenbank!
Roadmap
Fazit
12
12
13
2.
ERSTE SCHRITTE
14
Elemente eines Systementwurfs
14
2.1.1.
2.1.2.
2.1.3.
2.1.4.
2.1.5.
2.1.6.
14
15
15
16
16
17
2.1.
2.2.
2.3.
2.4.
Software-Engineering
Das Phasenmodell der Softwareentwicklung
Problem-/Systemanalyse
Pflichtenheft
Systementwurf
Implementierung eines Prototypen
Hypermediales System
Computerbasiertes Lernen
17
18
2.3.1.
2.3.2.
2.3.3.
2.3.4.
18
19
21
21
Wissen
Theorien des Lernens...
... und ihre Entsprechungen im Computerunterstützten Lernen
Bewertung & Fazit
Instruktionsdesign
22
2.4.1. Definition
2.4.2. Wegweiser...
22
23
2.5.
2.6.
2.7.
2.8.
2.9.
Systemkomponenten
Lernerfolg
„Integration einer objektorientierten Datenbank“
Einschränkungen
Weiterführendes
23
24
24
25
25
3.
MULTIMEDIALES LERNEN – WIE FUNKTIONERT DAS?
26
3.1.
3.2.
3.3.
3.4.
3.5.
„Lehrer taugen doch alle nichts!“
„Schön, daß wir darüber geredet haben ...“
Selbst ist der Lerner!
Chromglanz & Langeweile
Einordnung in die didaktische Theorie
26
27
28
29
30
3.5.1.
3.5.2.
3.5.3.
3.5.4.
31
31
31
32
3.6.
3.7.
Motivation
Interaktion
Wissensvermittlung
Inhaltliche Qualität
Grundlegende Anforderungen ...
... und mögliche Ansätze zur Umsetzung
32
32
3.7.1.
3.7.2.
3.7.3.
3.7.4.
3.7.5.
33
34
34
34
35
Wissensvermittlung
Motivation
Interaktion
Inhaltliche Qualität
Selbstorganisation
Seite 4
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
3.8.
Lernen & mehr?
35
3.9.
Fazit & Ausblick
38
4.
THE MAKING OF...
40
4.1.
4.2.
Wieso Produktion?
„Mach‘ mal...“
40
41
4.3.
Der große Zusammenhang
48
4.4.
„Programmierung ruft Grafik ...“
53
Ideen & Ziele – Die Mindmap
55
4.6.
Das Drehbuch
59
4.7.
Varianten & Archivierung
61
Von der Anforderung zu Attributen
62
4.8.1.
4.8.2.
4.8.3.
4.8.4.
4.8.5.
63
63
63
64
64
4.5.
4.8.
3.8.1.
3.8.2.
3.8.3.
3.8.4.
4.2.1.
4.2.2.
4.2.3.
4.2.4.
4.3.1.
4.3.2.
4.3.3.
4.3.4.
4.3.5.
4.4.1.
4.4.2.
4.4.3.
4.4.4.
4.5.1.
4.5.2.
4.5.3.
4.5.4.
4.6.1.
4.6.2.
4.6.3.
4.6.4.
4.6.5.
Didaktische Definition
Begründung
Formen multimedialer Lernumgebungen
Synthese
Phase I: Idee & Ausformulierung
Phase II: Inhaltliches Design
Phase III: Medienproduktion
Phase IV: Programmproduktion
Ziele aus produktionstechnischer Sicht
Die Ausgangssituation
Integriere!
Von der Struktur zum Programm
Das Rad neu erfinden?
Kreative Synergien
Fachliche Zusammenarbeit
Überarbeitungsmechansimen
Fazit
Zieldefinition
Mindmap – Eine Definition
Erweiterung, Abstraktion & Vertiefungsmöglichkeiten
Ebenen der Konzeption
Schreiben wie im Film?
Von der Mindmap zum Drehbuch
Look & Feel eines Drehbuchs
Designrichtlinien
Produktionsplanung
4.7.1. Varianten
4.7.2. Archivierung
Medienelemente
Konzeptionselemente
Aufbau der Varianten-Information
Aufbau der Überarbeitungsinformation
Medieneigenschaften bezüglich der Medienarchivierung
35
36
36
37
41
43
46
47
48
49
50
51
52
53
53
54
54
55
55
56
57
59
60
60
61
61
61
62
4.9.
Fazit
64
5.
„KONTUREN IM NEBEL“
66
5.1.
Situativer Kontext & Co.
66
5.1.1.
5.1.2.
5.1.3.
5.1.4.
5.1.5.
5.1.6.
5.1.7.
5.1.8.
67
67
68
69
70
70
71
72
Definition der Komponenten
Kernkomponenten
Lernmodule
Benutzerprofile
Betreuung & Kommunikation
Archiv
Systemadministration
Tools
Seite 5
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
5.2.
5.3.
5.4.
5.5.
5.6.
Authoring-Metaphern, Medienelemente & Co.
73
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
5.2.6.
5.2.7.
5.2.8.
5.2.9.
5.2.10.
Klassifizierung multimedialer Entwicklungssysteme am Beispiel
Grobstrukturierung
Metaphern & Strukturelemente
Interaktionsmöglichkeiten, Programmablauf & Ereignisse
Medienelemente
Strukturelemente
„Programmierung“ des Systems
Darstellungsmodule
Module
Die Rückkehr des Gesamtkontextes...
73
74
75
76
77
83
84
85
86
86
Typedef Struct { ? } Mindmap;
88
5.3.1. Grundstruktur der Konzeptionselemente
5.3.2. Diversifizierung?
5.3.3. Attribute von Konzeptionselementen
88
88
88
Kommunikationsmechanismen
89
5.4.1.
5.4.2.
5.4.3.
5.4.4.
89
90
90
91
Technische Voraussetzungen
eMail
Schwarzes Brett
Chat
Wechselwirkungen
91
5.5.1.
5.5.2.
5.5.3.
5.5.4.
91
92
92
92
Bewertung eines Lerners – wie soll sowas funktionieren?
Individuelle Zugriffsrechte
Spezialitäten einer Lern- und Produktionsumgebung
Technische Realisierung von Wechselwirkungen
Stau auf der Datenautobahn
93
5.6.1.
5.6.2.
5.6.3.
5.6.4.
93
93
94
95
Programm-Performance
Bandbreite
Der Server macht dicht!
Lösungsstrategien
5.7.
Erkenntnisse
96
6.
KNOTEN, LINKS, NETZE
97
Grundbausteine hypermedialer Systeme
97
6.1.1.
6.1.2.
6.1.3.
6.1.4.
97
98
98
98
6.1.
6.2.
Strukturbäume
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.3.
6.4.
6.5.
Informationsträger: Knoten
Zusammenhänge: Kanten
Ordnung ins System: Strukturen hypermedialer Systeme
Einordnung in den Gesamtkontext
Grundstruktur
Hierarchien
Die Hackordnung im System
Querverweise
99
99
100
100
100
„Wenn einer eine Reise tut...“
100
6.3.1.
6.3.2.
6.3.3.
6.3.4.
101
101
101
103
Kompaß und Polarstern – Navigationsinstrumente
„Lost in Hyperspace“ vs. „Guided Tour“
Automatisierung von Navigationsdesign?
Stadtplan & Co.
Brückenschlag – eine Systemstudie
103
6.4.1.
6.4.2.
6.4.3.
6.4.4.
103
104
107
107
Aufbau eines einfachen Lernmoduls
Phasenanimation konkret
Drehbuchansicht am Beispiel
Konzeptionselemente
Varianten zum Zweiten
110
6.5.1.
6.5.2.
6.5.3.
6.5.4.
6.5.5.
111
111
111
111
112
Charakterisierung
Schlüsseleigenschaften
Ausprägungen
Beispiele
Permanente Varianten
Seite 6
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
6.5.6. Temporäre Varianten
112
6.6.
Fazit & Folgerung
112
7.
DIE OBJEKTORIENTIERTE DATENBANK
7.1.
7.2.
Wieso eine Datenbank?
Wieso Objektorientierung?
113
113
7.3.
Eine Frage der Architektur ...
117
7.4.
Attribute, Methoden, Polymorphie, ...
119
7.4.1.
7.4.2.
7.4.3.
7.4.4.
7.4.5.
7.4.6.
7.4.7.
7.4.8.
7.4.9.
119
120
121
121
122
122
123
123
124
7.5.
7.2.1. Definition der drei wichtigsten Datenbanktypen
7.2.2. Begründung mit mediendiaktischen Erfordernissen
7.2.3. Begründung aus Sicht des Programmierers
7.3.1. Two-Tier-Architektur
7.3.2. Three-Tier-Architektur
7.3.3. Bewertung
Modellierung
Objektorientierte Technologien
Schema-Evolution
Fehlertoleranz
Sprachunabhängigkeit
Skalierbarkeit
Physikalische Datenbankstruktur
Optimierungsmöglichkeiten
Datenbankpflege
113
114
115
116
117
118
119
Viele Medienplattformen, ein Programm
124
7.5.1. Daten sind Daten sind Daten sind ...
7.5.2. Integriertes „Offline-Lernen“?
125
125
7.6.
7.7.
Achtung, Stolperstein!
Fazit & Weiterführendes
125
126
8.
EVALUATION
8.1.
Kriterien ...
127
8.1.1. Allgemeines Bewertungsraster
8.1.2. Spezielle Evaluationskriterien
127
131
... und Kandidaten
133
Die Testergebnisse!
136
8.3.1.
8.3.2.
8.3.3.
8.3.4.
8.3.5.
137
138
140
142
143
8.2.
8.3.
8.4.
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.5.
8.2.6.
8.2.7.
„Demystifying OODBMS“...
O2
GemStone
ObjectStore
Versant
POET
Objectivity/DB
O2
ObjectStore
Versant
POET
Objectivity/DB
Fazit
8.4.1.
8.4.2.
8.4.3.
8.4.4.
127
134
134
135
135
135
136
136
144
Serverkonzepte
Performance
Multimedia!
Das Finale...
9.
DER SYSTEMENTWURF
9.1.
9.2.
Zielsetzung
Datenstrukturen
145
145
145
146
147
147
148
Seite 7
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
9.3.
9.4.
9.5.
9.6.
9.7.
9.2.1. Die Mutter aller Objekte – Polymorphie
9.2.2. Varianten vs. Versionen & Transaktionen
9.2.3. Datenbankobjekte
148
148
148
Methoden
149
9.3.1.
9.3.2.
9.3.3.
9.3.4.
9.3.5.
9.3.6.
9.3.7.
9.3.8.
149
151
152
152
153
153
154
155
Grundfunktionalitäten
Fehlerbehandlung
Medienelemente
Medienkapselungen
Ablaufschablonen
Strukturelemente
Lernmodule
Benutzerprofile
Das Systemmodul
155
9.4.1.
9.4.2.
9.4.3.
9.4.4.
9.4.5.
9.4.6.
Struktur des Systemmoduls
Ereignisverwaltung
Ablauflogik
Darstellungsverwaltung
Kommunikation
Sonstiges
155
156
156
156
156
157
Schnittstellen
157
9.5.1. Ziele von Schnittstellengestaltung
9.5.2. Definiertheit
9.5.3. Erweiterbarkeit
157
158
158
Module
159
Fazit
166
9.6.1.
9.6.2.
9.6.3.
9.6.4.
9.6.5.
9.6.6.
9.6.7.
Systemmodul
Ereignisverwaltung
Ablaufverwaltung
Darstellungsmodule
„Benutzermodule“
Erweiterungen im Objektmodell
Einordnung in den Client/Server-Kontext
10. IN DIE PRAXIS
10.1. Systemwahl
10.2. Anatomie eines Dichters
10.2.1.
10.2.2.
10.2.3.
10.2.4.
10.2.5.
10.2.6.
10.2.7.
POET Universal Server
Client License Packages
Verity Search
SDKs
Tools
„POET-C++“ – Dialekt oder neue Hochsprache?
POETs Datenbankkonzept
159
160
160
161
164
165
165
168
168
168
169
169
169
169
170
170
171
10.3. Club der werdenden Dichter
171
10.4. Eier, Kartons & Co.
175
10.3.1.
10.3.2.
10.3.3.
10.3.4.
10.3.5.
10.3.6.
10.4.1.
10.4.2.
10.4.3.
10.4.4.
Vergängliches in aller Ewigkeit...
Grundlegende Objektverwaltung
Mengenlehre
Verweise aller Arten
Transaktionen & Co.
Allergische Reaktionen
Die Ei-Metapher
Datenbankmodellierung: Medienobjekte
Datenbankmodellierung: Kapselungsobjekte
Datenbankmodellierung: Strukturobjekte
10.5. Eier in der Datenbank?
10.5.1. Ein Blick „unter die Haube“
10.5.2. Die CD-ROM: Inhalt, Installation und Handhabung
10.5.3. Impressionen...
171
173
174
174
174
175
175
176
177
178
180
180
182
183
Seite 8
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Formalien/Inhaltsverzeichnis
10.6. Lyrisches Cross-Media-Publishing?
11. FAZIT & SCHLUß
11.1. Fachliches Fazit
11.1.1. Objektorientierte Datenbanken
11.1.2. Integratives Softwaredesign
11.1.3. Lernumgebungen
185
186
186
186
187
187
11.2. Persönliches Fazit
187
11.2.1. Erwartungen
11.2.2. Ergebnisse
187
187
11.3. Schlußwort
QUELLENVERZEICHNIS/LITERATUR
188
189
Seite 9
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Ziele setzen! – Überblick des „Projekt Diplomarbeit“
1.
Ziele setzen!
Überblick des „Projekt Diplomarbeit“
„Ziele“ sind ein zentraler Begriff des Projektmanagements: Ohne Ziele kein erfolgreiches Projekt –
also auch keine erfolgreiche Diplomarbeit. Aus diesem Grund tut auch der Diplomand gut daran,
schon ziemlich am Anfang die Ziele zu definieren, anhand derer er selbst und andere seine Arbeit
messen können. Zu Beginn dieser Arbeit soll deshalb die Zielvorgabe in Form einer Zusammenfassung stehen.
1.1.
MULTIMEDIALE PROBLEME, DIE DER LÖSUNG HARREN...
Abstract/Zusammenfassung
Heutige Autorensysteme wie Macromedias Director oder Asymetrix‘ ToolBook sind mächtige Werkzeuge zur vergleichsweise effizienten Programmierung von Multimedia-Anwendungen. Allerdings liegen all diesen Programmen erkennbar informatiknahe Ansätze zugrunde. Die mediendidaktischen
Anforderung an eine multimedialen Anwendung bleiben bei ihrer Erstellung größtenteils unberücksichtigt.
So werden dem Entwickler/Autor einer Anwendung keine Hilfsmittel zur Verbesserung bzw. Überprüfung der didaktischen Qualität seiner Arbeit zur Verfügung gestellt. Dem Lerner wird oftmals keine standardisierte Lernsituation angeboten. Navigationshilfen sind meist nur rudimentär implementiert. Aspekte netzbasierten Lernens werden bei konventionellen Tools vernachlässigt.
Aber auch produktionstechnische Anforderungen werden von den gängigen Tool nicht oder nur teilweise erfüllt: So stehen beispielsweise keine oder nur rudimentäre Funktionalitäten zum teamorientierten, netzwerkbasierten Entwickeln zur Verfügung. Auch die Wiederverwertbarkeit und Archivierung von Medien ist oft nicht gegeben.
Ziel dieser Diplomarbeit ist es deshalb, die mediendidaktischen Anforderungen eines zeitgemäßen
Lernsystems mit den technischen Möglichkeiten eines modernen Authoringtools und den Bedürfnissen von Autoren, Produzenten und Lernern zu einem modernen, intranetfähigen Systementwurf auf
der Basis eines objektorientierten Datenbanksystems zu verschmelzen.
In den hier vorgestellten Systementwurf sollen die mediendidaktischen und technischen Aspekte
gleichermaßen einfließen. Schließlich ist ein nicht realisierbarer, mediendidaktisch ausgereifter Entwurf genauso wenig sinnvoll wie ein technisch ausgereiftes System, das gegen mediendidaktische
Grundprinzipien verstößt.
1.2.
THE ROAD TO ...?
Vorgehensweise bei der Suche nach Lösungsansätzen
Ziele und Thematik sind definiert – nun müssen die Fragestellungen bestimmt werden, die aus der
Problematik folgen. Wie bereits im vorigen Unterkapitel angeschnitten, umfaßt die Herstellung eines
CBT viele komplexe Facetten, die sich aber m.E. in drei Kategorien unterteilen lassen. Deshalb wird
Seite 10
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Ziele setzen! – Überblick des „Projekt Diplomarbeit“
sich diese Diplomarbeit mit den drei Gebieten Authoring und Konzeption, Produktion, sowie Rezeption und Navigation beschäftigen. Für jedes dieser Gebiete wird der intranetorientierte Aspekte diskutiert werden müssen – in Form der titelgebenden Lernumgebung, aber auch in Form von teamorientierten Arbeitsweisen bei der Produktion.
1.2.1.
Authoring und Konzeption
Die konzeptionelle Arbeit eines qualifizierten Autoren bestimmt die Grundzüge eines Lernprogrammes und haucht dem oft trockenen Stoff Leben ein: Bei konventioneller Vorgehensweise wird in dieser Phase ein Drehbuch erstellt (meist auf dem „analogen“ Medium Papier), in dem Struktur, Handlung und Texte bereits festgeschrieben sind.
Hieraus ergibt sich die für diesen Bereich zentrale Frage, wie das Authoring möglichst effizient durch
den Computer unterstützt werden kann1. Insbesondere die direkte Umsetzung des Drehbuchs in eine ablauffähige Multimedia-Anwendung stellt eine große Herausforderung dar. Doch nicht nur die
nahtlose Integration des Drehbuchschreibens in den Produktionsprozeß liegt bei den am Markt verfügbaren Systemen im Argen: Nirgendwo finden sich Hilfen zur Erstellung von Anwendungen, die
sich an didaktischen Grundprinzipien orientieren. Der Autor hat sämtliche Freiheiten, seine Kreativität auszuleben – und damit gleichzeitig auch die Freiheit, selbst fatalste Fehler zu begehen.
Außerdem redet alle Welt von „Teamarbeit“ und „Netzwerken“ – aber selbst moderne AuthoringSysteme erlauben keine teamorientierte, netzwerkbasierte Entwicklung von CBT-Konzepten und
-Komponenten. Auch hier besteht Handlungsbedarf, da insbesondere im Verbund mit der Produktion große Synergieeffekte möglich erscheinen.
1.2.2.
Produktion
Die Produktion einer multimedialen Anwendung ist äußerst komplex und erfordert deswegen eine
größtmögliche Unterstützung durch das Autorensystem. Interessant sind hier beispielsweise Aspekte
der Wiederverwertbarkeit von Medien sowie deren sinnvoller Archivierung und Verwaltung. Ein weiteres Schlagwort ist „Cross-Media-Publishing“: Eine einmal erstellte Anwendung soll ohne zusätzlichen Produktionsaufwand auf verschiedene Medien-Plattformen (CD-ROM, Intranet, Printmedien,
...) portiert und wiedergegeben werden können. Selbstverständlich spielen auch bei der Produktion –
das „globale Dorf“ läßt grüßen – netzbasierte, teamorientierte Arbeitsmethoden eine immer entscheidendere Rolle.
Dennoch wird keiner der genannten Punkte in aktuellen Systemen ausreichend berücksichtigt.
1.2.3.
Rezeption und Navigation
Nachdem die bisherigen Punkte eher die Notwendigkeiten auf der Produzentenseite betrafen, bedürfen selbstverständlich die Erfordernisse des Rezipienten ausführlicher Würdigung. Für diesen As-
1
Diese Thematik wurde in der Diplomarbeit von Kleeberger/Eisenhauer bereits ausführlich behandelt. Ich will mich in diesem Punkt auf die
dort vorgestellte Argumentation stützen und vielversprechende Ansätze weiterentwickeln.
Seite 11
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Ziele setzen! – Überblick des „Projekt Diplomarbeit“
pekt sind folgende Thematiken zu untersuchen: Navigationsgestaltung2, netzbasiertes Lernen3 und
die mögliche Integration in ein objektorientiertes Datenbanksystem.
Ebenso spielen die mediendidaktischen Aspekte des Authoring in diesem Bereich hinein – Authoring
und Rezeption sind schließlich wechselseitig bedingt, denn eine gute Konzeption sollte auf einen
maximalen Lernerfolg zugeschnitten sein.
1.3.
DIE WELT IST EINE DATENBANK!
Datenbanken in Informatik und Multimedia
Datenbanken spielen die zentrale Rolle in der Informatik. Eigentlich basieren alle ernstzunehmenden
Anwendungen zumindest indirekt auf Datenbanken: Es werden Daten verarbeitet, die permanent
auf einem Massenspeichermedium verwaltet und verarbeitet werden müssen. Genau dies ist Sinn
und Zweck einer Datenbank.
Im Medienbereich präsentiert sich die Situation nicht anders: Auch hier müssen Daten verarbeitet
und dauerhaft auf einem Massenspeicher verewigt werden. Die Situation gegenüber anderen Bereichen der Informatik ist sogar eher noch verschärft, da die zu verarbeitenden Daten sehr komplex
und umfangreich sind. Außerdem bieten sämtliche aktuellen Datenbanksysteme bereits standardmäßig umfangreiche Unterstützung nahezu beliebiger Client-Server-Architekturen an – die Intranetfähigkeit einer datenbankbasierten Anwendung ist damit sozusagen bereits „erblich bedingt“.
Es bietet sich also geradezu an, eine Datenbank als Grundlage eines Autorenwerkzeuges zu verwenden. Aufgrund der Komplexität der zu verwaltenden Daten empfehlen sich objektorientierte Konzepte – so erhält das Fragment „objektorientierte Datenbank“ des Diplomarbeits-Titels seine Berechtigung. Doch sei an dieser Stelle noch nicht allzu viel verraten – die Datenbank-Thematik wird in zwei
Abschnitten ausführlich behandelt, ebenso wird dort die Entscheidung für den objektorientierten Ansatz begründet.
1.4.
ROADMAP
Der „Rote Faden“ durch diese Ausarbeitung
Die gesamte Arbeit ist am Phasenmodell der Softwareentwicklung orientiert, das im Kapitel 2.1,
„Elemente eines Systementwurfs“ dargelegt wird: Zuerst soll eine Betrachtung der unterschiedlichen
mediendidaktischen und technischen Aspekte erfolgen. Die aus dieser Betrachtung gezogenen
Schlüsse werden dann zuerst zu einem Systemkonzept und schließlich zu einem Systementwurf weiterentwickelt.
Eine besondere Stellung nehmen die ersten beiden Abschnitte ein: Hier erfolgen eine Definition dieser Diplomarbeit sowie die Darstellung wichtiger mediendidaktischer Grundlagen: Wie kann Lernerfolg als höchstes Ziel einer Lernumgebung erreicht werden – und wie kann eine AuthoringSoftware das Erreichen dieses Ziels unterstützen?
2
Zur Navigationsthematik existiert ebenfalls eine Diplomarbeit, deren Ergebnisse ich in meiner Ausarbeitung aufgreifen will (Lechner: Ergonomische Navigation in computerbasierten Informationssystemen).
3
Auch hier werde ich auf einer bestehenden Arbeit aufbauen – Steinke: Mediendidaktische Konzeption netzbasierten Lernens.
Seite 12
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Ziele setzen! – Überblick des „Projekt Diplomarbeit“
Der folgende Abschnitt befaßt sich dann mit produktionstechnischen Aspekten: Wie können Lernprogramme effizienter konzipiert und produziert werden? Wie können Autoren – auch unter Berücksichtigung mediendidaktischer und psychologischer Aspekte – in ihrem kreativen Prozeß unterstützt
werden? Können Konzeption und Produktion in einem System vereint werden? Wie könnte ein
Werkzeug aussehen, das derartige Features realisiert?
Sowohl mediendidaktische als auch produktionstechnische Aspekte definieren also den Funktionsumfang des hier diskutierten Systems ganz entscheidend mit – im folgenden Abschnitt „Konturen im
Nebel“ werden diese Anforderungen deshalb in entsprechende Datenstrukturen und Module umgesetzt.
Der Abschnitt „Knoten, Links, Netze“ befaßt sich mit Aspekten der Navigation und ihrer Umsetzung
in entsprechende Automatismen für ein entsprechendes System.
Die Abschnitte 7 und 8 beschäftigen sich dann mit dem Werkzeug, das für die Realisierung des in
dieser Diplomarbeit diskutierten Systems verwendet werden soll: Ich stelle wichtige Grundprinzipien
von objektorientierten Datenbanksystemen vor und evaluiere marktrelevante Systeme.
Der letzte theoretische Abschnitt befaßt sich mit Aspekten des Systementwurfs: Wie sollen die Datenstrukturen in Objekte überführt werden? Welche objektorientierten Techniken finden Anwendung? Welche Schnittstellen werden definiert, welche Module realisiert?
Im zehnten Abschnitt schließlich will ich den Systementwurf anhand eines Prototyps zumindest teilweise in die Praxis umsetzen.
1.5.
FAZIT
Eine kurze Zusammenfassung des ersten Kapitels
Diese Diplomarbeit wird die wichtigsten Ansätze zur Unterstützung von Autoren und Lernern in den
Bereichen Konzeption, Produktion und Rezeption aufgreifen und zu einem innovativen, netzwerkfähigen Datenbankentwurf verschmelzen, der die Einzelapsekte zu einem „höheren Ganzen“ führt –
schließlich ist das Ganze auch hier mehr als die Summe seiner Einzelteile!
In diese Diplomarbeit werden die Ergebnisse dreier an der Fachhochschule Furtwangen erarbeiteten
Diplomarbeiten, eigene Erfahrungen in den Bereichen Konzeption, netzbasiertes Arbeiten und Produktion & Programmierung von Autorensystemen, sowie eigenständige Recherchen auf den Gebieten Mediendidaktik und Systementwicklung einfließen.
Seite 13
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
2.
Erste Schritte
Definitionen und Abgrenzungen
Ganz zu Beginn möchte ich in angemessener Kürze ein paar grundlegende Definitionen abhandeln:
Was ist ein „Systementwurf“ überhaupt, bzw. welche Aspekte eines Systementwurfs werden in dieser
Arbeit überhaupt berücksichtigt? Oder: Welche mediendidaktischen Modelle existieren für computerbasiertes Lernen?
Außerdem ist es bei wissenschaftlichem Arbeiten wichtig, extakt zu definieren, welche Themen konkret bearbeitet werden sollen – Schlagworte wie „Hypermedia“ oder „Integration einer objektorientierten Datenbank“ müssen zuerst mit Bedeutung gefüllt werden. Zusätzlich müssen noch die Teilaspekte definiert werden, die bei dieser Diplomarbeit unberücksichtigt bleiben werden.
2.1.
ELEMENTE EINES SYSTEMENTWURFS
Darstellung der wichtigsten Gesichtspunkte
Zunächst möchte ich darstellen, welche Aspekte bei einem Systementwurf berücksichtigt werden
müssen. Die Darstellung richtet sich nach Walter (1994[47]).
2.1.1.
Software-Engineering
„Software-Engineering ist die genaue Kenntnis und gezielte Anwendung von Prinzipien, Methoden und
Werkzeugen für die Technik und das Management der Softwareentwicklung und -wartung, auf der Basis wissenschaftlicher Erkenntnisse und praktischer Erfahrungen unter Berücksichtigung des jeweiligen
technisch-ökonomischen Zielsystems.“ (Walter, 1994[47], S.7)
Die Softwareentwicklung kann nach Walter in ein Phasenmodell aufgeteilt werden, das ich im folgenden Kapitel darstellen werde. Die Gliederung der vorliegenden Ausarbeitung wird sich an den
Anforderungen des Phasenmodells orientieren – allerdings werden ab und zu zwei Phasen nahtlos in
einem einzigen Abschnitt ineinander übergehen, um einen besseren Lesefluß zu gewährleisten.
Üblicherweise spielen bei der Softwareentwicklung Kosten- und Projektmanagement-Aspekte eine
große Rolle. Da ich diese Aspekte aber soweit möglich in meiner gesamten Diplomarbeit ausklammern will (vgl. Kapitel 2.8), werde ich sie auch bei dieser Definition ausklammern. Eine Kosten/Nutzenkalkulation müßte allerdings spätestens bei der Realisierung des hier diskutierten Systems erfolgen. Da dabei das eine oder andere Feature wegfallen könnte, wird der Entwurf entsprechend
modular aufgebaut sein.
Seite 14
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
2.1.2.
Das Phasenmodell der Softwareentwicklung
Nach Walter (1994[47], S.13) kann die Softwareentwicklung in folgende Phasen aufgeteilt werden:
Tätigkeiten
Phasen
Ist-Zustand
Soll-Zustand
Machbarkeit
Problem-/Systemanalyse
Dokumente
Systemstudie
Pflichtenheft
Zerteilung des
Systems,
Modulentwurf
Systementwurf
Codieren,
Programmieren
Implementierung
Algorithmen,
Datenstrukturen,
Modulschnittstellen
Quellprogramme
Dokumentation
Modultests,
Performancetests
Tests
Testprotokolle
korrigierte Software
Systemtests,
Systemabnahme
Integration
Abnahmeprotokolle
Handbücher
Systemeinführung
Betrieb/Wartung
Betriebs- und
Wartungsprotokolle
In der vorliegenden Arbeit werden die ersten beiden Phasen auf einer relativ abstrakten Ebene komplett und die Implementierungsphase anhand eines Prototyps teilweise behandelt. Deshalb will ich
mich im folgenden auf die Erklärung der drei relevanten Phasen beschränken.
2.1.3.
Problem-/Systemanalyse
Wie aus dem Phasenmodell der Softwareentwicklung ersichtlich ist, bestehen die ersten Schritte darin, den vorhandenen Zustand zu analysieren, entsprechende Schlüsse zu ziehen und diese zu einem
gewünschten Soll-Zustand weiterzuentwickeln. Dabei muß die Machbarkeit im Auge behalten werden.
Für meine Diplomarbeit bedeutet dies, daß ich zunächst eine Analyse bestehender mediendidaktischer und technischer Realisierungsansätze zum gewählten Thema vornehmen werde (Ist-Zustand).
Danach müssen die Erkenntnisse zu einem groben Systemkonzept verdichtet werden (Soll-Zustand).
Abschließend müssen geeignete Werkzeuge zur Realisierung definiert und der Soll-Zustand auf seine
Umsetzbarkeit untersucht werden.
Die mediendidaktische Analyse und Verdichtung erfolgt im Abschnitt „Multimediales Lernen – wie
funktionert das?“. Fragen der konzeptionellen und produktionstechnischen Integration und Unterstützung werden im Abschnitt „The Making of...“ diskutiert. Mit fortschreitender Ausformulierung der
zu entwickelnden Datenstrukturen in den Abschnitten 4 und 5 geht die Problem- und Systemanalyse
langsam in den Systementwurf über. Eine Analyse der Grundstrukturen hypermedialer Systeme findet
Seite 15
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
sich im Abschnitt „Knoten, Links, Netze“. Abschließend erfolt eine Darstellung des Werkzeuges, mit
dem der Systementwurf realisiert werden soll: „Die objektorientierte Datenbank“.
Insgesamt wird sich der erste Teil dieser Arbeit also auf die folgenden Punkte fokusieren, die Walter
(1994[47], S.15ff) als Teilaspekte der Systemplanung nennt:
Ziele – Problemstellung des Projektes
Problemanalyse – Recherche bestehender Ansätze
Zielanalyse – Weiterentwicklung in Richtung der Zielsetzung
Schwachstellenanalyse – Formulieren möglicher Realisierungsprobleme
Verhaltensanalyse – Gedanken zur Benutzeroberfläche, Organisation, Modularität, usw.
Anforderungsanalyse – Festlegen der Features, aufgegliedert nach Wichtigkeit
Grobkonzipierung – Entwurf eines Grobmodelles (entspricht dem Systemkonzept)
Zwar ebenfalls im Zusammenhang der Systemanalyse erwähnt, für diese Arbeit aber nicht relevant:
Marktübersicht – allgemeine Marktentwicklung: Produktübersichten, Produktpositionierungen
Bewertungsanalyse – Bewertung und Einordnung des konzipiertes Systems
2.1.4.
Pflichtenheft
Das Pflichtenheft definiert den Leistungsumfang des Systems: Was soll realisiert werden? Es besteht
aus den folgenden Elementen [Walter, 1994[47], S.18f]:
Zielsetzung – entsprechend der Systemanalyse
Beschreibung der Voraussetzungen – Hard- & Softwarekonfigurationen, Produkte von Drittanbietern, verwendete Programmiersprachen und Tools
Funktionsumfang – Beschreibung der funktionalen Anforderungen an das zu realisierende System; folgt aus der Anforderungsanalyse und dem Systemkonzept
Funktionsprüfung – Definition möglicher Teststrategien, um die Funktionsfähigkeit zu überprüfen
Projektumwelt – Definition der Qualitätskontrollen und des technischen Kundendienstes
Kosten und Aufwendungen – wird in dieser Ausarbeitung vernachlässigt
Aus Gründen der Lesbarkeit fließt das Pflichtenheft in die Systemanalyse-Abschnitte dieser Arbeit ein.
2.1.5.
Systementwurf
Der Systementwurf folgt aus dem Pflichtenheft und definiert das wie der Realisierung. Hier werden
bereits Objektmodelle und Programmier-Schnittstellen definiert – der Systementwurf dient also als
direkte Vorlage zur Implementierung.
Walter (1994[47], S.20) nennt folgende Elemente eines Systementwurfs:
Zielsetzung/Anforderungen/Abgrenzung – wie im Pflichtenheft
Spezifikation – detaillierte Systembeschreibung mit Funktionsbeschreibung, Schnittstellenbeschreibung, Benutzerschnittstelle, Mengengerüst
Konstruktion – Basis für die technische Realisierung des Systems (Zerlegung in Module und beschreibung der Komponenten)
Der Systementwurf eines derartig umfangreichen Systems kann im Rahmen einer Diplomarbeit allerdings nur auf einer vergleichsweise abstrakten Ebene vorgenommen werden.
Seite 16
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
2.1.6.
Implementierung eines Prototypen
Am Ende dieser Diplomarbeit wird ein Prototyp stehen, der einen sehr begrenzten Teil des gesamten
Systementwurfs realisiert. Für die Erstellung des Prototypen findet das gesamte Phasenmodell Anwendung. Da der Prototyp aber nur einen kleinen Anteil dieser Diplomarbeit darstellt, möchte ich
für weitere Informationen über das Phasenmodell auf Walters Arbeit (1994[47]) verweisen.
2.2.
HYPERMEDIALES SYSTEM
Klärung im Begriffsdschungel rund um Multimedia und seine Bestandteile
Multimedia, Hypermedia, Hypertext, nicht zu vergessen „multiple Medien“ – ein großes Begriffschaos beherrscht die Welt der bunten Bilder, informativen Texte, schrillen Soundeffekte und gelegentlichen Mausklicks. Ich will deshalb zunächst einmal definieren, was in dieser Ausarbeitung unter
dem Begriff des „hypermedialen Systems“ verstanden werden soll. Die hier verwendete Klassifizierung ist mehr oder weniger willkürlich – sie soll an dieser Stelle m.E. nur die technischen Aspekte abdecken. Eine ausführliche Diskussion zur umfassenden Begriffsklärung findet sich beispielsweise in
Schulmeister (1996[15], S.15ff).
MULTIMEDIA
Unter Multimedia verstehe ich in dieser Arbeit lediglich die durch ein Programm kontrollierte und
koordinierte Integration verschiedener Medientypen auf digitale Weise mit dem Computer. Die
Struktur der dabei entstehenden Programme kann beliebig sein – computerbasierte Präsentationen,
die mehrere Medientypen einsetzen, fallen genauso unter den Begriff wie höchst interaktive Spiele.
Ich schließe bei dieser Diplomarbeit ausdrücklich computerunterstützte, aber „externe“ Medien wie
Dia-AV oder Bildplattenspieler aus, da sie nicht meinem Integrationsbegriff entsprechen.
Folgende Medientypen sollen in dieser Ausarbeitung berücksichtigt werden:
Text – mit den üblichen Attributierungen (Schriftart, -größe, -auszeichnungen, ...)
Grafische Darstellungen – Bilder, Zeichnungen, Grafikobjekte (Linien, Kreise, ...)
Ton – in Form von digitalisierten Schwingungen oder MIDI-Steuerbefehlen
Bewegtbild – in Form von digitalen Videos oder Animationssequenzen
Computererzeugte Medien – beispielsweise in Form von Simulationen, VR-Räumen oder Spielwelten
HYPERTEXT
Das Hypertext-Konzept fügt einem normalen Text eine Verzweigungsmöglichkeit hinzu: Beim Aktivieren einzelner Worte springt das Hypertext-System zu einem neuen Dokument oder Textabschnitt.
Ein Hypertext fügt also Interaktivität und somit Entscheidungsfreiheit & Verzweigungsmöglichkeiten
hinzu. Zur didaktischen Einordnung des Hypertext-Prinzips: vgl. Lechner, 1994[10], S.8ff.
HYPERMEDIA
Hypermedia kann als Schnittmenge der beiden anderen Ansätze betrachtet werden: Unterschiedliche Medientypen werden vom Computer integriert und kontrolliert. Über interaktive Elemente
(Hotspots) sind Verzweigungen und Benutzerentscheidungen möglich.
Seite 17
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
Über diesen hypertextbasierten Interaktionsbegriff hinaus sollen auf beliebige Benutzereingaben beliebige4 Reaktionen des Programmes realisierbar sein.
Auf technischer Seite wird der hier vorgestellte Entwurf also folgende hypermedialen Möglichkeiten
bieten:
Integration der beschriebenen Medientypen
Interaktion – Realisierung beliebige Programmreaktionen auf beliebige Benutzereingaben
Darüber hinaus werden die intranetbasierten Aspekte, die in dieser Definition von Hypermedia nicht
enthalten sind, berücksichtigt.
2.3.
COMPUTERBASIERTES LERNEN
Lern- und wissenspsychologische Modelle
Da sich diese Diplomarbeit als Ziel einen Systementwurf gesetzt hat, will ich die theoretischen
Grundlagen von „Lernen“ und „Wissen“ hier nur insoweit anreißen, wie sie für diese Ausarbeitung
auch notwendig sind. Dies bedeutet, daß ich die für computerbasierte Lernumgebungen relevanten
Modelle kurz darstellen und ihre konkrete Ausgestaltung anhand von Beispielen aufzeigen will.
2.3.1.
Wissen
Wissen ist der Hintergrund des Lernens – Lernen soll Wissen vermitteln. Deshalb will ich an dieser
Stelle kurz auf die Typologie des Begriffes „Wissen“ eingehen.
DEKLARATIVES WISSEN
Deklaratives Wissen ist Faktenwissen. Ziel ist, daß der Lerner Informationen abspeichert und diese
später wieder 1:1 reproduzieren können soll. Als Beispiel wäre hier das „Pauken“ geschichtlicher Daten zu nennen. [Faulhaber, 1996[3]]
PROZEDZURALES WISSEN
Prozedurales Wissen könnte als Handlungswissen definiert werden – also als Wissen, wie mit einer
zielgerichteten Handlung ein gegebenes Problem gelöst werden kann. Grundlage prozeduralen Wissens ist Faktenwissen, das abstrahiert und kontextgemäß wiederverwertet wird. Die prozedurale Vorgehensweise kann durch drei Merkmale definiert werden: Zielgerichtetheit, Zerlegung in Teilziele/-schritte, Wahl und Beschreibung der für die Umsetzung der Teilziele notwendigen Handlungen.
Beispielhaft für prozedurales Wissen sei die Recherche eines Themas genannt: Die Recherche wird
in mehrere Teilschritte zerlegt (Überblick verschaffen, Quellen suchen, Informationen aus Büchern
extrahieren, ...), die auf Faktenwissen basieren („In Büchern findet man Informationen“). [Faulhaber,
1996[3]]
4
Auf den Begriff der „Interaktion“ werde ich im Abschnitt „Multimediales Lernen – wie funktionert das?“ nochmals genauer eingehen. Dort
wird der hier verwendete, technische Interaktions-Begriff dann didaktischen Gesichtspunkten entsprechend wieder eingeschränkt werden.
Seite 18
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
HEURISTISCHES WISSEN
Schulmeister (1996[15], S.168) definiert zusätzlich noch den Begriff „heuristisches Wissen“ als „Erfahrungs- und Problemlösungswissen von Experten, das nicht an Inhalte gebunden ist“. Es „wird vom Tutor benötigt, um den Studierenden in seinen Lernprozessen und seinem Problemlöseverhalten anleiten
zu können“. Man könnte heuristisches Wissen also als Spezialfall des prozeduralen Wissens bezeichnen, bei dem die deklarative Basis vernachlässigbar ist.
2.3.2.
Theorien des Lernens...
Nach Schulmeister (1996[15], S.64) kann die Lern- und Wissenspsychologie in drei für hypermediale
Systeme relevante Ansätze aufgegliedert werden: Behaviorismus, Kognitive Psychologie und Konstruktivismus.
BEHAVIORISMUS
Das behavioristische Modell basiert auf dem „klassischen Konditionieren“ (Pawlow), nach dem von
bestimmten Reizen bestimmte Verhaltensreaktionen ausgelöst werden (Stimuli/Response; S/R). Skinner (1954[17], S.86ff) erweiterte das Modell des klassischen Konditionierens um spontan auftretendes
(„operantes“) Verhalten. Dies bedeutet, daß gewünschte Reaktionen gefördert werden können, indem geeignete „Verstärker“ (z.B. Belohnungen) zum Einsatz kommen. Unerwünschtes Verhalten hingegen wird mit Sanktionen belegt. Die jeweilige Verstärkung sollte möglichst eindeutig sein und unmittelbar auf eine entsprechende Reaktion des Lernenden erfolgen.
Skinner stellte die These auf, daß nach behavioristischen Prinzipien konstruierte Programme die erwähnte Verstärkung wesentlich besser dosieren könnten als menschliche Lehrer. Fischer (1985[4],
S.69ff) hingegen wies nach, daß die recht einfache Reiz-Reaktions-Theorie der komplexen Wirklichkeit nicht gerecht wird.
So erfreute sich das aus Skinners Theorie entwickelte Modell, die „Programmierte Instruktion“, zunächst großer Beliebtheit, verschwand aber bald wieder in der Versenkung. Trotz aller Kritik am Behaviorismus gibt es dennoch bestimmte Zwecke, insbesondere beim Erwerb von Faktenwissen, für
die Skinners Methoden durchaus gerechtfertigt sind. [Schulmeister, 1996[15], S.87f]
Kerres (1998[9], S.52ff) führt als zusätzliches Modell noch den kybernetischen Ansatz an: Dieser basiert zwar auf behavioristischen Konzepten, stellt aber nicht die Belohnung und Bestrafung, sondern
den Austausch von Informationen zwischen Lerner und Lehrendem in den Vordergrund: Der Lerner
erhält Informationen, die er speichert. Es folgen Fragen, bei der das gespeicherte Wissen wiedergeben werden muß, sowie eine entsprechende Rückmeldung zur Selbstanalyse und Revidierung eventueller falscher Antworten.
KOGNITIVE PSYCHOLOGIE
Die kognitive5 Psychologie beruht auf einem Modell, das Lernen als Austauschprozeß mit der Umwelt begreift. Dabei werden gemachte Erfahrungen an neue Gegebenheiten oder Situationen pragmatisch angepaßt und entsprechend verarbeitet und eingeordnet. Der kognitive Ansatz zielt darauf
ab, dem Lerner Freiheiten zu gewähren, um „vorhandene kognitive Konzepte zu aktivieren und neue
5
Laut Langenscheidts Fremdwörterbuch[44] bedeutet Kognition „Erkennen, Wahrnehmen“.
Seite 19
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
zu entwickeln“ (Schulmeister, 1996[15], S.65f). „Väter“ dieser Theorie sind Jean Piaget und Jerome S.
Bruners. [Schulmeister, 1996[15], S.64ff]
Im Kognitivismus wird wie im kybernetischen Ansatz ein informatives Rückmeldungsprinzip verwendet. Allerdings charakterisieren Fischer und Mandl (1988[5]) den Unterschied folgendermaßen: Im
Behaviorismus steht die simple Reiz/Reaktions-Kette im Fokus des Feedback, in der Kognitionspsychologie hingegen die Information zum Verhalten des Lernenden, aus der dieser selbst Rückschlüsse
ziehen soll. Doch auch diese Art des Feedback ist nicht unproblematisch: Zieht der Lerner „falsche“
Rückschlüsse, kann mehr Schaden angerichtet werden als mit dem vereinfachten, instrumentalisierten Menschenbild des Behaviorismus. [Fischer/Mandl, 1988[5], S.187ff]
Die kognitive Psychologie ist psychologisch-philosophische Grundlage des Konstruktivismus, auf den
in der folgenden Definition eingegangen werden soll. Auf der kognitiven Psychologie basieren Lernkonzepte wie Entdeckendes Lernen oder das Lernen mit Mikrowelten, die im Kapitel 2.3.3 beschrieben werden. Diese stellen die Suche nach Lösungen zu einem gegebenen Problem, also den Erwerb
von prozeduralem Wissen, in den Vordergrund. [Schulmeister, 1996[15], S.64ff, Faulhaber, 1996[3]]
KONSTRUKTIVISMUS6
Der Konstruktivismus basiert auf der Annahme, daß Menschen die Umwelt, in der sie sich befinden,
durch ihre Wahrnehmung definieren. Es gibt gemäß Konstruktivismus also keine objektive Realität –
das, was als Realität wahrgenommen wird, ist lediglich die Interpretation des durch die Sinnesorgane
Wahrgenommenen. Bedeutung wird aus der Sinneswahrnehmung konstruiert, da „jeder Akt des Erkennens eine Welt hervorbringt“ (Maturana/Varela, 1987[13]). Der Konstruktivismus betont also den
sozialen und situativen Kontext stärker als die Kognitionspsychologie.
Interessant ist die konstruktivistische These, daß Wissen an sich nicht existiert, sondern erst durch
den Akt des Erkennens konstruiert bzw. in Handlungen immer wieder neu konstruiert wird. Daraus
schließen Konstruktivisten, daß Lernen als aktive Auseinandersetzung mit den Inhalten erfolgen muß.
Nicht das bloße Zuhören, sondern erst das Arbeiten mit und kreative Verarbeiten von Inhalten kann
auch komplexen Themen gerecht werden. Aus diesem Ansatz entspringt auch die Theorie des „semantischen Netzes“, das als typisch konstruktivistisches Modell Schlußfolgerungen und Problemlösungen aus der vernetzten Darstellung der Sachverhalte ermöglichen soll [Schulmeister, 1996[15],
S.168].
Konstruktivistische Lernkonzepte sind beispielsweise Simulationen, geankertes Lernen oder Projektmethoden. Diese Konzepte zeichnen sich (im Gegensatz zu kognitivistischen) dadurch aus, daß nicht
nur die Lösungen, sondern auch die Probleme vom Lerner erkannt werden müssen. [Schulmeister,
1996[15], S.168] Die auf konstruktivistischen Ansätzen basierenden situierten Ansätze sind mithin eher
an praktischer Arbeit als an abstraktem Wissen orientiert: Gelernt wird „in der Praxis“, also durch eigenes Ausprobieren nach Anleitung eines Experten. [Kerres, 1998[9], S.71ff]
6
Kerres (1998[9]) verwendet statt „Konstruktivismus“ den Begriff „situiertes Lernen“. Er kritisiert in seiner Arbeit, daß „der Begriff des Konstruktivismus in der Diskussion über didaktisches Design wenig präzise“ sei. Es handle sich „um ein Konglomerat von didaktischen Ansätzen und Methoden sowie Vorstellungen über Menschenbilder, so daß eine prägnante Charakterisierung einer entsprechenden Position als didaktischer Ansatz
und Grundlage einer mediendidaktischen Konzeption schwer fällt“. Ich will dennoch den Konstruktivismus hier als eine Art Oberbegriff verwenden und auf den situierten Ansatz erst bei der detaillierteren Ausarbeitung des Systementwurfs eingehen.
Seite 20
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
2.3.3.
... und ihre Entsprechungen im Computerunterstützten Lernen
Jedem dieser drei Ansätze können verschiendene konkrete Lernkonzepte zugeordnet werden, die
ich im Folgenden kurz exemplarisch darstellen möchte.
PROGRAMMIERTES LERNEN
Das Programmierte Lernen basiert auf dem behavioristischen Modell und geht auf Skinner zurück.
Der Lernstoff wird in kleinste Einheiten (Frames) zerlegt; der Lerner muß sofort nach der Bearbeitung
eines solchen Frames Fragen zum behandelten Stoff geben. Die Antworten werden je nach Richtigkeit belohnend verstärkt oder mit einer negative Rückmeldung „bestraft“. Es wird zwischen linearen
und verzweigenden Programmen unterschieden; beide Typen bleiben allerdings letztlich auf dem
Niveau eines einfachen Frage-/Antwort-Spiels. [Schulmeister, 1996[15], S.87f]
ENTDECKENDES LERNEN/MIKROWELTEN
Entdeckendes Lernen basiert auf dem kognitionspsychologischen Modell: Wissen soll über selbständiges „Forschen“ in einer „virtuellen Mikrowelt“ angeeignet werden. Die Problemlösung geschieht also aus eigenem Antrieb und unter kreativem Einsatz von Verstand & Erfahrung des Lerners. Weniger
gefragt ist das sture Wiederkauen von Faktenwissen.
Beim Entdeckenden Lernen beschränkt sich die Rolle des Tutors darauf, dem Lerner Anstöße für die
„Entdeckungsreise“ zu geben. Er definiert weiterhin das zu lösende Problem und deutet die zugrundeliegenden Strukturen zumindest an. [Götze, 1997[6]]
Ein wichtiger Aspekt bei kognitionspsychologischen Konzepten wie dem Entdeckenden Lernen ist die
Sanktionsfreiheit: Der Lerner darf ausprobieren, was er will – er hat sozusagen die ausdrückliche „Lizenz zum Fehlermachen“. Dadurch, daß dem Rezipienten die Folgen seines Handelns aufgezeigt
werden, lernt er dennoch mögliche Konsequenzen kennen, muß aber nicht wie in der „wirklichen
Welt“ dafür geradestehen. [Schulmeister, 1996[15], S.45f]
GEANKERTES LERNEN
Das auf situativen Prinzipien basierende geankerte Lernen entstand aus der Aufgabe heraus, Medien
für Problemschüler zu entwickeln. Die von Bransford (u.a.) entwickelte Lösung ging von einem sog.
„Anker“ aus, der als Motivationsfaktor für den Lerner dient und somit die Aufmerksamkeit beim Lernen steigert. Als Beispiel für einen solchen Anker könnte eine Rahmenhandlung dienen, die einen situativen Kontext definiert, in den der Lerner einbezogen wird und die gleichzeitig als Träger des zu
vermittelnden Stoffes dient. [Kerres, 1998[9], S.71f]
2.3.4.
Bewertung & Fazit
Jede der genannten Ausprägungen von computerunterstütztem Lernen hat seine eigenen didaktischen Vor- und Nachteile. Deswegen werden die Typen in der Praxis meist gemischt verwendet. Bei
HQ-Lernprogrammen ist es beispielsweise so, daß das eigentliche CBT eher kognitionspsychologische und konstruktivistische Aspekte aufweist, d.h. der Lerner soll sich mit dem Stoff auseinandersetzen, indem er interaktiv in eine eigens geschaffene Mikrowelt eintaucht, in der er möglichst große
Freiheiten besitzt – auch die Freiheit, Fehler zu machen. Das Faktenwissen, das aus dem eigentlichen
CBT gezogen werden soll, wird dann mit dem sog. TestPool, einem Werkzeug nach behavioristischen Mustern, verifiziert. Dieses „Mischen“ verschiedener Lernmodelle wird im Instruktionsdesign
Seite 21
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
berücksichtigt. Auf das Thema Instruktionsdesign werde ich vertiefend im folgenden Unterkapitel
eingehen.
Schulmeister (1996[15]) weist explizit auf die Bedeutung der Rückmeldung/des Feedbacks hin: „Die
Fragen, die man an den Einsatz von Feedback in Lernprogrammen richten kann, können gar nicht differenziert genug gestellt werden.“ (S.102) Auch hier scheint der „goldene Mittelweg“ die praktikabelste Methode zu sein, um die zu einfache Sicht des Behaviorismus und das Problem falscher Rückschlüsse beim kognitionspsychologischen Ansatz in ein „besseres Ganzes“ aufzulösen. Ebenso zeigen
Forschungen, daß je nach Lernertyp unterschiedliche Feedbackansätze bevorzugt werden [van der
Linden, 1994[20], S.61ff].
Abschließend seien die Einsatzgebiete der einzelnen Lernmodelle noch einmal zusammenfassend in
einer Tabelle aufgeführt.
Modell/Aspekt
Vermittlung von...
Behaviorismus
Faktenwissen
Einsatz beim...
Aneignen von reinen
Informationen; in Prüfungs- und Testwerkzeugen
assoziativ
Das Verhalten des Lerners wird direkt beurteilt: explizites Feedback.
Lernstil
Feedback/Besonderheiten
Kognitionspsychologie
prozeduralem Wissen
Konstruktivismus
prozeduralem/heuristischem Wissen
Erlernen von Problemlö- ebenfalls Problemlösunsungsstrategien; in
gen; z.B. in ExpertensysLernprogrammen
temen, Simulationen
kognitiv
Das Verhalten des Lerners wird nicht direkt
bewertet; die Konsequenzen werden aber
aufgezeigt (implizites
Feedback). Sanktionsfreiheit.
konstruktiv/kognitiv
Das Verhalten führt nur
zu indirekten Konsequenzen, die vom Lerner eigenständig erkannt
und beurteilt werden
müssen (implizites
Feedback). Sanktionsfreiheit.
Klassifizierung der drei vorgestellten Lernmodelle
2.4.
INSTRUKTIONSDESIGN
Vom Lern- zum Instruktionsmodell
Alle drei im vorigen Kapitel vorgestellten Lernmodelle besitzen ihre Vor-, aber auch Nachteile. Die
Didaktik suchte deswegen eine Lösung in der Zusammenfassung und Weiterentwicklung der verschiedenen Lernmodelle zu Instruktionsmodellen. Eine erste Instruktionstheorie entstand, als Gagné
1965 versuchte, die existierenden Lerntheorien mit ihren jeweiligen Vor- und Nachteilen in einem
„idealen“ Instruktionssystem zusammenzuführen, wobei der Fokus immer noch auf behavioristischen
Methoden lag.
2.4.1.
Definition
Instruktion bedeutet nach Langenscheidts Fremdwörterbuch[44] „Unterweisung, Einweisung, Anleitung“. Während die im vorigen Unterkapitel dargestellten Lernmodelle das Erzeugen einer Veränderung im Lerner zum Ziel haben, bezieht die Instruktionstheorie Umgebung und Vorwissen als weitere
Dimensionen in ihre Betrachtungen ein. Der Lehrprozeß nach Gagné und Briggs (1979) wird als Sequenz von folgenden Instruktionsereignissen aufgefaßt:
Erlangen der Aufmerksamkeit
Information des Lernenden über die Lernziele
Seite 22
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
Erinnern der Lernvoraussetzungen (Wiederholung)
Präsentation neuer Informationen
Beratung des Lernenden
Demonstration neuer Fähigkeiten und Übung
Rückmeldung
Überprüfung der Performanz
Erweiterung
Transfer
Für die Entwicklung computerbasierten Lernens werden nach Gagné und Wager (1988[18], S.35ff) zusätzlich folgende Phasen unterschieden:
Zielfindung
Prototyping
Programmierung
Evaluation
Lowyck/Elen definieren Instruktionsdesign wie folgt: „Gemäß unserer Sichtweise ist Instruktionsdesign
eine Disziplin, die deskriptive Forschungsergebnisse mit der Praxis von Instruktion verbindet, indem sie
(1) auf der Basis von Ergebnissen von kognitionspsychologischer Grundlagenforschung Designparameter identifiziert, (2) diese sodann in Regeln, Prozeduren und Verfahrensvorschriften instrumentiert, und
(3) Präskriptionen7 für die Entwicklung der Instruktion liefert, um Lehren und Lernen zu optimieren.“
(Lowyck/Ellen, 1991[12], S.131ff)
Gerade diese drei Bereiche bieten Ansatzpunkte für softwaregestützte Konzeption. Kerres (1998[9])
folgert: „Die Aufmerksamkeit des didaktischen Designs8 muß sich [...] auf die didaktische Transformation von Lehrinhalten mit Lehrzielen zu Lernangeboten richten.“ Im Folgesatz hebt er nochmal die
konstruktivistisch begründete Bedeutung des situativen Kontexts – und damit der Lernumgebung –
hervor.
2.4.2.
Wegweiser...
Ich werde im folgenden Abschnitt „Multimediales Lernen – wie funktionert das?“ nochmals aus einer
etwas weniger theoretischen Sichtweise an das „Wie“ des Lernens herangehen, die dort getroffenen
Erkenntnisse dann allerdings abschließend wieder auf die hier aufgeführten Lern- und Instruktionsmodelle beziehen. Außerdem werde ich dort die bis jetzt noch unberücksichtigten Aspekte „Kreativität“ und „freie Gestaltung“ aufgreifen. Diese werden – neben den hier definierten didaktischen
Grundlagen – die Ausgestaltung des Systementwurfs entscheidend mitbestimmen.
2.5.
SYSTEMKOMPONENTEN
Technische Unterteilung des Systementwurfs
Der Systementwurf wird sich in vier inhaltliche Aspekte aufspalten: In Lernmodule und die sie umfassende Lernumgebung, sowie in eine Entwicklungsumgebung auf Produktionsseite. Als übergreifender
Aspekt muß auch die Systemverwaltung berücksichtigt werden.
7
Lt. Langenscheidts Fremdwörterbuch[44]: „Vorschrift, Verordnung“
8
Kerres verwendet den Begriff „didaktisches Design“ gleichbedeutend mit „Instruktionsdesign“.
Seite 23
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
Die Lernmodule sind Träger der Inhalte und somit mit konventionellen CBTs vergleichbar. Für den
Systementwurf bedeutet dies, daß technisch ein ähnlicher Funktionsumfang zur Verfügung gestellt
werden muß, wie ihn gängige Entwicklungstools wie Asymetrix‘ ToolBook oder Macromedias Director bieten.
Die Lernumgebung wiederum faßt die einzelnen Lernmodule zusammen und macht sie dem Lerner
zugreifbar. Der Zugriff kann auf unterschiedlichste Art und Weise erfolgen. Den eigentliche Lernmodulen wird ein Benutzerprofil zur Verfügung gestellt, so daß die eigentlichen CBTs auf ein Modell des
jeweiligen Benutzers zugreifen und sich in gewissen Grenzen an den Lerner anpassen können. Neben diesem Lernermodell werden auch noch die Kommunikationsfunktionen der Benutzer untereinander und mit Tutoren über die Benutzerverwaltung realisiert.
Die Produktions- oder Entwicklungsumgebung dient dem Erstellen der Lernmodule. Auch hier
werden die entsprechenden Kommunikationsmodule, die für eine optimale Produktionsphase notwendig sind, integriert werden. Außerdem stellt die Entwicklungsumgebung den Autoren entsprechende Konzeptionshilfen zur Verfügung.
Die Systemverwaltung schließlich dient als Schnittstelle zwischen Entwicklung und Rezeption: Hier
können Benutzerprofile erstellt und verwaltet, Lernmodule eingegliedert und sonstige administrative
Aufgaben erledigt werden.
2.6.
LERNERFOLG
Das Ziel eines jeden Lernprogrammes – wie kann Lernerfolg definiert werden?
Lernerfolg kann nach Kerres (1998[9], S.116) in Aspekte wie das Behalten von Fakten oder in das Verstehen, Anwenden und Handeln unterteilt werden. Lernerfolg ist also zunächst von einer Zieldefinition abhängig: Was soll dem Lernenden überhaupt beigebracht werden? Diese Zieldefinition begrenzt den dargebotenen Stoff und begründet gleichzeitig das Verhältnis der verwendeten Lernmodelle zueinander.
Ich will in dieser Arbeit „Lernerfolg“ als das Erreichen der von Autorenseite aus gesetzten didaktischen Ziele auffassen.
Ein dementsprechend hoher Stellenwert muß der Zieldefinition – vgl. die Theorie des Instruktionsmodells – eingeräumt werden. Sie steht am Anfang eines jeden Lernprogramms und muß von der
Autorenkomponente eines multimedialen Entwicklungssystems deshalb entsprechend berücksichtigt
werden.
2.7.
„INTEGRATION EINER OBJEKTORIENTIERTEN DATENBANK“
Eine Begriffsklärung
Eine objektorientierte Datenbank in ein Lernsystem zu integrieren, dafür kann man sich viele verscheidene Varianten denken: Von der Benutzerverwaltung über eine Bereitstellung von Mediendaten hin zur Storyboardverwaltung sind prinzipiell alle Möglichkeiten offen.
In der vorliegenden Ausarbeitung erhält die Datenbank die zentrale Rolle schlechthin – in ihr werden
sämtliche für den gesamten Produktionsprozeß, die Rezeption (also das „Abspielen“) und die BenutSeite 24
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Erste Schritte – Definitionen und Abgrenzungen
zerverwaltung benötigten Daten vorgehalten. Darüber hinaus werden strenggenommen auch sämtliche Programmroutinen im Datenbestand abgelegt – schließlich benutzt die hier vorgestellte Lösung
eine objektorientierte Datenbank!
Doch der Integrations-Begriff ist in dieser Diplomarbeit noch wesentlich weiter gefaßt: Die hier entworfene Datenbank ist ein wirklich integriertes System – die gleichen Daten und die gleichen Programmroutinen sollen für alle drei in der Einleitung erwähnten Kategorien einer MultimediaProduktion (Authoring, Produktion und Rezeption) verwendet weden.
2.8.
EINSCHRÄNKUNGEN
Welche Aspekte nicht betrachtet werden sollen
Der in dieser Ausarbeitung dargestellte Systementwurf läßt Aspekte des Projektmanagements bewußt
außen vor: Es soll ein Produktionswerkzeug und kein Kostenkalkulations- oder Managementtool geschaffen werden. Derartige Aspekte werden beispielsweise bei Kleeberger/Eisenhauer (1996[39]) ausführlich behandelt. Es sollte nicht schwierig sein, das hier vorgestellte System um die entsprechende
Funktionalität zu erweitern.
Ebenso wird der Kostenaspekt des Systems selber ausgeklammert: Ein derartig komplexes System
„einfach mal so“ zu budgetieren, erscheint unmöglich. Ausdrücklich in die Betrachtung einbezogen
wird hingegen der Kostenfaktor für die Produktion von Lernmodulen mit dem hier vorgestellten System: Schließlich sind Einsparungen in der Produktion ein gewichtiges Argument für den Einsatz von
derartig integrierten Systemen.
2.9.
WEITERFÜHRENDES
Literaturverweise
Im vorhergehenden Abschnitt wurden die verschiedenen didaktischen Theorien und Modelle nur
äußerst knapp angerissen. Eine ausführliche und vor allem gut strukturierte Darstellung der Lernmodelle findet sich beispielsweise in Kerres (1998[9]). Ebenso findet sich dort eine ausführliche Diskussion zum Thema „Didaktisches Design/Instruktionsdesign“. Ich werde diese Diskussion in den folgenden Kapitel aufgreifen. Ähnliche Themen werden in Schulmeister (1996[15]) abgehandelt.
Seite 25
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.
Multimediales Lernen – wie funktionert das?
Anforderungen an hypermediale Lernsysteme aus Lernersicht
Lernen ist für viele Menschen eine Erfahrung, die mit Schulstreß, Notendruck und mehr oder weniger schlechten Erfahrungen mit dem Lehrkörper in Verbindung gebracht wird. Dennoch ist und
bleibt Lernen in unserer hochentwickelten Informationsgesellschaft auch nach dem Schulalter ein essentieller Bestandteil unseres Lebens – der Mensch hört nie auf, zu lernen und neue Eindrücke zu
verarbeiten. Gerade im (Weiter-) Bildungssektor werden computerunterstützten Lernsystemen eine
große Bedeutung zugemessen – einige Wissenschaftler reden sogar von einer Zweiten Gutenbergschen Revolution. In letzter Konsequenz stellt sich gar die Frage, ob CBTs den Lehrer aus Fleisch und
Blut längerfristig nicht ganz ersetzen werden können. [Schulmeister, 1996[15], S.5ff]
In diesem Kapitel möchte ich zunächst einmal grundsätzliche didaktische Voraussetzungen für einen
guten Unterricht – egal, ob menschen- oder computergestützt – erörtern. Im Mittelpunkt dieser Betrachtungen soll der Lerner mit seinen Bedürfnissen und weniger die pure Technik stehen. Die zentralen Fragestellungen lauten: Welche Faktoren sind für eine erfolgreiche Rezeption entscheidend?
Wie „ereignet“ sich Lernen? Die Erkenntnisse dieses Kapitels werden in den folgenden Abschnitten
aufgenommen und bei Bedarf vertieft.
3.1.
„LEHRER TAUGEN DOCH ALLE NICHTS!“
Kritik am Status-Quo konventioneller Wissensvermittlung
Die gerne an Stammtischen geäußerte Kritik am verbeamteten Lehrkörper – viel Geld, noch mehr
Urlaub, aber wenig Arbeit – kratzt trotz ihrer Eindimensionalität an einem grundsätzlichen Problem
konventioneller Bildungsansätze: Die Qualität des Unterrichts hängt sehr stark von Person und Persönlichkeit des Unterrichtenden ab: Kann er (oder sie) Inhalte verständlich, umfassend und dennoch
fesselnd vermitteln? Schafft es der Unterrichtende also, seine „Zöglinge“ zur Mitarbeit und damit
zum Lernen zu motivieren? Wird der vom Lehrplan vorgeschriebene Stoff überhaupt vollständig und
stichhaltig aufbereitet und vermittelt? Stimmt die Gewichtung von wichtigen und weniger wichtigen
Inhalten? Schließlich sind ja auch Lehrer nur fehlerhafte Menschen aus Fleisch und Blut – und verfügen deshalb nur über ein begrenztes, unvollkommenem Wissen und haben ebenso mit dem allgegenwärtigen Information-Overflow zu kämpfen wie der Rest der Menschheit auch. [Schulmeister,
1996[15]]
Aus didaktischer Sicht könnte also der „Unsicherheitsfaktor Mensch“ in Form des „unvollkommenen
Lehrers“ als ein entscheidender Kritikpunkt am herkömmlichen, personalen Unterricht bezeichnet
werden.
Beispielhaft für diese Argumentation seien hier Jones und Elshout zitiert: „Many a student has been
frustrated by a professor who simply did not know how to teach.“ (Jones, 1992[8], S.1ff); „It seems that
formal education lets you get away with a great amount of half digested knowledge.“ (Elshout, 1992[2],
S.5ff)
Seite 26
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
Zusammenfassend kann aus diesen möglichen Fehlerquellen bereits ein grobes Anforderungsraster
an ein gutgemachtes Lernprogramm abgeleitet werden:
Vermittlung – Fähigkeiten des Lehrers/Instruktors, den Stoff zielgerichtet, rezipientengerecht, verständlich und strukturiert zu präsentieren
Motivationsfaktoren – Schaffen von Lernanreizen
inhaltliche Qualität – Vollständigkeit und Relevanz des Stoffes
Wie ein guter Lehrer muß also auch ein am Erfolg des Lerner orientiertes CBT zunächst Anreize
schaffen, um den Rezipienten überhaupt für den Stoff zu interessieren. Die Inhalte müssen so präsentiert werden, daß sie einerseits eingängig und verständlich sind, andererseits dennoch „in die Tiefe“ gehen. Auch sollte es möglichst wenige Motivationshemmer geben, um den Lerner auch über
längere Zeit bei der Stange zu halten. Letztendlich muß selbstverständlich auch der Inhalt selbst
stimmen – schließlich gibt es kaum etwas Peinlicheres als sachliche Fehler in einem der Wissensvermittlung verpflichteten Lernprogramm!
3.2.
„SCHÖN, DAß WIR DARÜBER GEREDET HABEN ...“
Dialog & Interaktion im Lernprozeß
Um die Diskussion um Sinn oder Unsinn unseres Bildungssystems erneut aufzugreifen: Eigentlich
müßten nach der vorigen Definition nur noch einige gute Lehrer dafür gewonnen werden, ihr Wissen niederzuschreiben, ein paar Grafiken und Sounds anzuhängen und das Ganze dann auf CDROM zu pressen – schon müßte man das Schulwesen in seiner heutigen Form ganz problemlos abschaffen können!
Oder?
Nun, ganz so einfach und problemlos, wie es zunächst vielleicht erscheinen mag, ist die Sache mit
Multimedia selbstverständlich nicht: Denn – wie bereits dargestellt – hängt Lernerfolg entscheidend
von der Motivation des Lerners ab. Und auf die individuellen Motivationsfaktoren oder die augenblickliche Verfassung des Rezipienten – also auf den Lernkontext – kann (noch) keine Maschine und
kein Programm eingehen.
Mehr noch: Ein Gutteil von Lernen geschieht in einem von gegenseitiger Verständigung geprägten
Dialog zwischen Menschen – ein Prozeß, den kein Computer auch nur im Entferntesten simulieren
kann. So zeigen Studien, daß Fernstudiengänge Abbrecherquoten von bis zu 50% aufweisen – derartige isolierte Lernmethoden erfordern eine hohe Eigenmotivation und Eigenverantwortung [Kerres,
1998[9], S.108].
Lernen ist also das Ergebnis einer Interaktion zwischen Instruktor, Lernendem und der Umgebung.
[Schulmeister, 1996[15]]
Und gerade in dieser für den Lernprozeß entscheidenden Interaktion liegt das große Problem von
CBT-Anwendungen: Computer sind schlichtweg zu „dumm“, einen nach menschlichen Maßstäben
auch nur annähernd zufriedenstellenden Dialog zustandezubringen. Für Lernprogramme müssen
deshalb spezielle Interaktionsmodelle entwickelt werden, die das Unvermögen des „Rechenknechtes“ kaschieren.
Multimedia wird Lehrer oder Instruktoren also nicht ersetzen, wohl aber in ihrer Arbeit unterstützen
können. Multimedia als Summe nicht-integrieter, linearer Medien kann aber durch seine ganz speSeite 27
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
ziellen – wenn auch nach menschlichen Maßstäben eingeschränkten – Interaktionsmöglichkeiten
neue Motivationsbereiche erschließen und andere Sichtwiesen eröffnen bzw. komplexe Zusammenhänge durch simuliertes Erfahren erst begreifbar machen.
Genau darauf sollte eine multimediale Entwicklungsumgebung abgestimmt sein.
3.3.
SELBST IST DER LERNER!
Die Rolle der Selbstorganisation im Lernprozeß
CBTs sind besonders im Weiterbildungskontext sehr gut dafür geeignet, autodidaktische Lernmaßnahmen zu unterstützen: Der Lerner kann sich – sofern er Zugriff auf einen Computer hat – unabhängig von Lehrpersonal den von ihm gewünschten Themen widmen. Er kann dabei – anders als im
personalen Unterricht – beispielsweise seine individuelle Lerngeschwindigkeit bestimmen oder eine
individuelle Stoffauswahl treffen. Und im Vergleich zu konventionellen autodidaktischen Medien
(Bücher, Videos, ...) stehen ihm zusätzlich interaktive Elemente, die bei entsprechendem Einsatz zu
einem besseren Stoffverständnis und Übung durch den praktische Anwendung führen können, sowie
ein wesentlich direkterer Zugriff auf die gewünschten Informationen zur Verfügung.
Problematisch bei der Selbstorganisation ist, daß der Lerner für die erfolgreiche Rezeption eine genügend hohe Lernmotivation mitbringen muß. Schließlich bestimmt nur er alleine, wann, wie und ob
überhaupt er den Lernstoff rezipiert. Die Initialzündung für die Beschäftigung mit einem Lernprogramm muß also meist aus eigenem Antrieb erfolgen – oder dieser Antrieb muß mit extrinsischen Anreizen, etwa einer drohenden Abschlußprüfung, geschaffen werden.
Darüber hinaus muß diese Lernmotivation aber auch von der Lernanwendung aufrecht erhalten
werden: Kann das CBT ihn nicht in seinen Bann ziehen, reicht ein einfaches Alt+F4, und die Lernumgebung ist beendet. Kein Lehrer „zwingt“ den Rezipienten zum Weiterarbeiten.
Laut Kerres (1998[9], S.115) zeigen sich „besondere Vorteile des mediengestützten selbstorganisierten
Lernens [...] im Hinblick auf die Lerndauer für Personen mit hoher Lernmotivation und selbständigem
Lernverhalten, die das mediale Lernangebot zu einer intensiven kognitiven Auseinandersetzung nutzen.“
Die Selbstorganisation wirft also weitere relevante Punkte für den hier vorgestellten Systementwurf
auf:
Die Inhalte alleine sollten eine hohe Lernmotivation garantieren, um den Rezipienten „bei der
Stange“ zu halten. Alternativ können auch andere, extrinsische Faktoren gefunden werden.
Das Interesse sollte bereits durch die Themenwahl, evt. auch durch die Titelwahl geweckt werden.
Ebenso müssen einfach zu benutzende Zugriffsmöglichkeiten auf die Lernprogramme angeboten
werden, damit der Lerner nicht bereits an der Auswahl einer Anwendung scheitert.
Der Lerner sollte die Möglichkeit erhalten, sowohl am Arbeitsplatz als auch zuhause mit den
Lernprogrammen arbeiten zu können.
Es sollten entsprechende Mechanismen vorhanden sein, die das autodidaktische Lernen unterstützen.
Seite 28
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.4.
CHROMGLANZ & LANGEWEILE
Über die Rolle von Gestaltung und Kreativität
Chromglänzende Dunkelheit umfängt sie. Eingeschlossen in eine Umgebung voller skurriler Formen,
Farben und Töne, sämtliche Sinne eher verwirrt als stimuliert, fragt sie sich nach dem Sinn dieser Tortur. Rechts rauschen bipolare Elektronenmassen dicht an ihren Augen vorüber. Ihr linkes Ohr registriert
einen irritierend hohen, nur unterschwellig wahrnehmbaren Ton. Sie wagt einige Schritte. Urplötzlich
tut sich ein Abgrund vor ihr auf. In einer Blitzreaktion kann sie ihren Körper noch herumreißen. Ist gerettet. Keuchend und mit zerspringen wollendem Herz läßt sie sich auf den harten Boden fallen. Und
sinkt augenblicklich in einen erschöpften, ruhe- und traumlosen Schlaf. Immer in der Hoffnung, daß
die Erinnerung am nächsten Morgen ausgelöscht sein möge...
Er hält sich die Hand vor dem Mund. Er weiß genau, wohin die nächste Abzweigung führen wird. Diese Stadt bietet keine Abwechslung, keine Aufregung. Die Straßen sind streng geometrisch angeordnet,
sie sind vorhersehbar ohne Ende. An jeder Kreuzung drei Schilder für jede Richtung – „gut gemeint,
aber zu viel Wegweisung führt auch in die Irre“, denkt er. An den Straßenrändern großflächige Plakate
mit Botschaften – alle gleich gestaltet, die Inhalte sind lang, viel zu lang, um während der Fahrt gelesen
zu werden. Und sie sind langweilig, so langweilig wie die ganze Stadt. Er beginnt zu gähnen, seine Gedanken schweifen ab. Er nickt kurz ein...
Die beiden vorangestellten Metaphern wollen – bewußt überspitzt – auf einen zentralen Zwiespalt
von multimedialen Lernanwendungen hinweisen: Einerseits existieren formal aufregende, zumindest
beim ersten Hinsehen äußerst interessante Anwendungen, die eher an einen Action-Film als an eine
sorgfältig durchgeplante Unterrichtsstunde erinnern. Die zweite Herangehensweise ist lernpsychologisch sicherlich begründet, sie bietet dem Lerner viele Hilfen, ist aber inhaltlich und ästhetisch durch
die Bindung an ein eher striktes, von starren didaktischen Prinzipien geprägtes Korsett sehr viel festgelegter als der erste Typ. Der Motivationsfaktor „Präsentation“ tritt in den Hintergrund; das Interesse
bei Lernern, die nicht unbedingt hochmotiviert sind, läßt schnell nach. Sie spricht eher den gezielt
nach bestimmten Informationen suchenden Rezipienten an.
So zeigen sich dann auch meist die oben karrikierten Schwächen bei beiden Typen: Sind Lernprogramme als Abenteuer oder „Erlebniswelten“ angelegt, leidet oft der Inhalt. Die Sinnesorgane des
Rezipienten werden nicht stimuliert, sondern eher überreizt, wenn es überall blinkt und blitzt, zischt
und klingelt. Oft fühlt sich der Anwender alleine gelassen, verliert die Orientierung – und mit ihr ein
gutes Stück Motivation. Von kleineren sprachlichen Unfällen und inhaltlichen Nachlässigkeiten mal
ganz abgesehen...
Andererseits kann die systematische, strukturierte Wiedergabe des Stoffes auch mit guten, gehaltvollen, aber für das Medium falsch aufbereiteten Inhalten ermüdend oder schlichtweg langweilig wirken. Gegen den Motivationskiller „Langeweile“ hilft in Zeiten des allseits propagierten „Infotainment“
auch keine noch so ausgefeilte Navigationshilfe.
Es gilt also die grundsätzliche Frage zu klären, in wieweit dem Autoren Freiheiten gewährt werden
dürfen, können, sollen und müssen. Ebenso muß diskutiert werden, in wieweit der Rezipient mit
ausgeklügelten Navigationshilfen „an die Hand genommen“ werden muß, soll und darf. Die hier getätigten Betrachtungen werden die Konfigurationsmöglichkeiten des in dieser Diplomarbeit entworfenen Systems entscheidend beeinflussen.
Zunächst einmal ist es schwierig, überhaupt formale didaktische Kriterien für erfolgreiches Lernen zu
definieren. Morris u.a. (1994[14]) fanden nur wenig Beispiele, bei denen nach gängiger Lehrmeinung
als „didaktisch wertvoll“ einzuschätzende Anwendungen auch über längere Zeit an mehreren Orten
einen Lernerfolg garantierten. Allgemein scheint es schwierig zu sein, den Erfolg eines CBTs anhand
Seite 29
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
didaktischer Kriterien festzumachen: „Die Entwicklung von Lehrprogrammen führte zu einer paradoxen Situation. Einerseits zeigte sich in empirischen Untersuchungen, daß die Lehrwirksamkeit guter
Lernprogramme den guten Unterricht erreichen und übertreffen kann. Andererseits zeigte sich, daß gerade die wirksamen Lehrprogramme von Autoren und Autorengruppen stammen, die sich in ihrer Praxis auf keine der bisher dargestellten Programmierungsstrategien berufen.“ (Weltner, 1978[19], S.56)
Auch Schulmeister (1996[15], S.115f) verweist auf den mangelnden Erfolg von Programmen mit zu
stark an die Instruktionstheorie angelehnten Zügen: Er zitiert Locatis und Park (1992[11], S.87ff), die
die Leistungsfähigkeit von nach starren Prinzipien generierter Lerneinheiten anzweifeln. Schulmeister
evaluiert im weiteren noch einige Systeme, die im praktischen Einsatz erforscht wurden:
Das PLATO-Projekt (vgl. Schulmeister, 1996[15], S.90) erreichte Erfolge durch die spielerisch angelegten Übungen und die Art der Rückmeldungen. Auch hier stellte sich die Bedeutung des Lehrer-Lerner-Dialoges heraus: Das Programm reagierte zwar auf viele Interaktionen, konnte mit
Problemen aber dennoch nicht so gut umgehen wie eine menschlische Lehrerin. Als dritter Gesichtspunkt wird die Bedeutung des situativen Kontexts erwähnt. [Schulmeister, 1996[15], S.90f]
TICCITT (vgl. Schulmeister, 1996[15], S.91) bleibt weiterhin kybernetischen Ansätzen mit Regel/Beispiel/Übungs-Sequenzen verhaftet: Schulmeister merkt an, daß selbst der „Vater“ des Projektes die Notwendigkeit hochkomplexer Interaktion begreift, obwohl er derartige Mechanismen
in TICCITT nicht implementiert hat: Das direkte Manipulieren der Lerninhalte sollte im Vordergrund stehen – Schulmeister stellt als Beispiel die Screenshots verschiedener grafisch orientierter,
interaktiver Lernprogramme den Textframes von TICCITT gegenüber [Schulmeister, 1996,
S.116ff]:
Diese Diskussion begründet auch, weshalb ich meinem Systementwurf keine abstrakten Lerntheorien
zugrunde legen, sondern das Ganze pragmatisch auf den in diesem Abschnitt geschilderten Aspekte
wie Motivation, Wissensvermittlung oder Interaktionsmöglichkeiten aufbauen will. Dennoch werde
ich diese Faktoren im folgenden Unterkapitel in die didaktische Theorie einordnen.
3.5.
EINORDNUNG IN DIE DIDAKTISCHE THEORIE
Motivationsfaktoren & Interaktion aus der Sicht von Lern- und Instruktionsmodellen
Nachdem ich in den bisherigen Unterkapiteln einige Thesen bezüglich der Charakteristika von „didaktisch guten“ Lernprogrammen aufgestellt habe, gilt es nun, diese in die im Abschnitt „Erste Schritte“ dargestellten Lern- und Instruktionsmodelle einzuordnen.
Seite 30
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.5.1.
Motivation
Der Faktor „Motivation“ ist in allen Lernmodellen enthalten: Der Behaviorismus beispielsweise sieht
die – positive oder negative – Verstärkung als den entscheidenden Motivationsfaktor an. Bei konstruktivistischen Ansätzen wie dem geankerten Lernen tritt ein komplexerer Motivationsbegriff in den
Vordergrund: Hier wird versucht, den Lerner zum Beispiel durch einen „Aufmacher“, den Anker,
zum Lernen zu motivieren. Durch diese Vorgehensweise (beispielsweise eine Rahmenhandlung, in
die das Lernen eingebettet wird) können auch Lerner, bei denen eine niedrige Lernbereitschaft zu
beobachten ist, zum Lernen auch abstrakter Konzepte bewegt werden. [Kerres, 1998[9], S.71f] Der zu
einfache Ansatz des Behaviorismus hingegen scheint bestenfalls für kurzfristige Motivationseffekte zu
taugen [Fischer, 1995[4], S.68ff].
Gerade Spiele und Simulationen, also vornehmlich konstruktivistische Ansätze, können eine hohe
Lernmotivation vermitteln. Auf sie trifft aber deswegen auch eine allgemeine Problematik des Konstruktivismus zu: Die zu vermittelnden Inhalte dürfen nicht aus den Augen verloren werden.
Andererseits kann alleine der vom Medium Computer immer noch ausgehende Reiz des Neuen als
wichtiger Motivationsanreiz gewertet werden [Schulmeister, 1996[15], S.7]. Genauso muß die „Verpackung“ – also aufregende Gestaltung, wohldosierte marktschreierische Effekte, etc. – als wichtiger
Motivationsfaktor betrachtet werden. Um eine plakative Parallele zum personalen Unterricht zu konstruieren: Erscheint die männliche Lehrperson in Frauenkleidern zum Unterricht, weiß er die Aufmerksamkeit seiner Schüler sofort und uneingeschränkt hinter sich – und hat einen prima Einstieg in
soziale Themenkreise wie Transsexualität usw.
3.5.2.
Interaktion
Die Interaktion ist eines der wichtigsten Themen im Sinne kognitionspsycholgischer und konstruktivistischer Ansätze: Das Bilden kognitiver Strukturen wird durch Interaktion unterstützt bzw. überhaupt erst möglich gemacht. [Kerres, 1998[9]], S.61f] Zwar kann keine wirkliche Interaktion zwischen
Mensch und Machine stattfinden, dies kann aber beispielsweise durch eine dieses Manko kaschierende Konzeption oder ein differenziertes Lernermodell, das ein Eingehen auf die Person zumindest
andeutet, wenigstens ansatzweise ausgeglichen werden. Außerdem bieten maschinengestützte Interaktionen wie Spiele oder Simulationen neuartige Möglichkeiten, die die des personalen Unterrichtes
übertreffen.
3.5.3.
Wissensvermittlung
Der Aspekt Wissensvermittlung bedarf genauerer Betrachtung: Wie bereits dargestellt, besitzen eigentlich alle Lernmodelle Stärken und Schwächen in der Vermittlung der Inhalte: Während kognitionspsychologische Ansätze eher die Vermittlung von Zusammenhängen fördern, sind behavioristische Ansätze besser zur Vermittlung harter Fakten geeignet. Das konstruktivistische Modell erlaubt
dem Lerner große Freiheiten und erzeugt deshalb bei vielen Lernern noch einen zusätzlichen Motivationsschub. Andererseits erfordert dieser Ansatz eine relativ große Selbstdisziplin, um den Inhalt,
die „Botschaft“, aus dem Spiel oder der Simulation zu extrahieren. Bei der Wissensvermittlung steht
also nicht ein einzelnes Lernmodell im Vordergrund, sondern eine Kombination von vielen – also ein
möglichst facettenreiches Instruktionsmodell. Ebenso ist bei der Wissensvermittlung der durch das Instruktionsmodell geforderte Zielaspekt entscheidend (vgl. Kapitel 2.4.1) – es müssen entsprechende
Fakten und Fähigkeiten vermittelt werden, die dem Lernziel entsprechen.
Seite 31
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.5.4.
Inhaltliche Qualität
Die inhaltliche Qualität kann von der didaktischen Einordnung ausgeschlossen werden, da es sich bei
der Forderung nach qualitativ hochwertigen Inhalten weniger um einen didaktischen als um einen
redaktionellen Aspekt handelt.
3.6.
GRUNDLEGENDE ANFORDERUNGEN ...
Zusammenfassendes
Es hat sich gezeigt, daß gut gemachte Lernprogramme insbesondere in den Gebieten Wissensvermittlung, Motivationsfaktoren und inhaltliche Qualität von schlechten abgegrenzt werden können. Diesen
Faktoren muß also im gesamten Herstellungsprozeß ein sehr hoher Stellenwert zugemessen werden.
Weiterhin hat sich gezeigt, daß Lernen stark von interaktiven Prozessen abhängig ist, die in Lernprogrammen auf eine computergerechte Form transformiert werden müssen. Lernen basiert auf dem
Dialog zwischen Instruktor und Lerner, sowie auf dem Eingehen auf den Rezipienten. Dieses Eingehen erfordert eine Individualisierung innerhalb einer Lernumgebung – Lernprogramme sollten also
im Rahmen ihrer technischen Möglichkeiten auf den Benutzer eingehen, seine Vorlieben, Tätigkeiten, bisherigen Weiterbildungsnahmen, usw. berücksichtigen.
Um auch eine Mensch-zu-Mensch-Interaktion innerhalb einer Lernumgebung anzubieten, sollten auf
Meta-Ebene9 teamorientierte Kommunikationsmöglichkeiten vorhanden sein, die genau diesen zwischenmenschlichen Interaktionstyp ermöglichen. Eine intranetbasierte Lernumgebung bietet sich für
solche Gruppenprozesse geradezu an.
Die Selbstorganisation kann unterstützt werden, indem möglichst automatisierte, standardisierte Navigationsmechanismen sowie ausgefeilte Zugriffsmöglichkeiten auf die einzelnen Lernmodule zur
Verfügung gestellt werden. Außerdem können durch ein geeignetes Lernermodell individualisierte
Inhalte zu einem zusätzlichen Motivationsfaktor werden.
Auf Autorenseite muß berücksichtigt werden, daß der Kreativität des Autors die entscheidende Rolle
zukommt. Sie darf auf keinen Fall unnötig eingeschränkt werden! Allerdings können ihm Hilfen zur
Hand gegeben werden, die seine Arbeit aufgrund numerisch verifizierbarer Aspekte überprüft und
ggf. Warnungen ausgibt, die der Autor allerdings nach Belieben ignorieren kann.
3.7.
... UND MÖGLICHE ANSÄTZE ZUR UMSETZUNG
Folgen für ein Multimedia-System
In diesem Unterkapitel soll diskutiert werden, wie die zuvor erwähnten Aspekte umgesetzt werden
können. Auch hier werde ich einmal mehr an der Oberfläche bleiben – die entsprechenden Punkte
werden im eigentlichen Systementwurf dann aufgegriffen und entsprechend vertieft.
9
Ich verwende den Begriff „Meta-Ebene“ hier, um deutlich zu machen, daß es sich nicht um einen Mensch-zu-Computer-Dialog innerhalb
eines Lernprogrammes handelt, sondern um einen computerunterstützten Mensch-zu-Mensch-Dialog, der auf einer übergeordneten Ebene –
also beispielsweise in einer Lernumgebung – abläuft.
Seite 32
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.7.1.
Wissensvermittlung
Wissensvermittlung ist ein Prozeß, den man zunächst in die Aspekte Aufbereitung des Stoffes und
Präsentation aufteilen kann. Wichtig sind dabei die folgenden Punkte:
Die Wissensvermittlung an sich ist entscheidend, nicht das Medium, das dafür verwendet wird.
Die spezifischen Vorteile des verwendeten Mediums sollten aber selbstverständlich entsprechend
berücksichtigt werden.
Die Zielgruppe und ihr sozialer Kontext müssen beachtet werden. Diesem Aspekt kann insofern
in einer integrierten Lernumgebung besonderen Wert zugemessen werden, da dank Lernermodell
individuelle Lernstile und persönliche Vorlieben auf allen Ebenen berücksichtigt werden können.
Die speziellen Möglichkeiten des Multimediums Computer sollten ausgenutzt werden können.
Dies bedeutet eine konkrete Unterstützung computerspezifischer Interaktionsmöglichkeiten und
die Möglichkeiten des schnellen, wahlfreien Zugriffs (vgl. Kapitel 5.1.6) auf die in der Datenbank
vorgehaltenen Lerninhalte.
Modularität der Inhalte: Da beinahe beliebige Zugriffsmöglichkeiten auf den Stoff bestehen, sollte dieser in möglichst kleine „Häppchen“ unterteilt werden. Dabei dürfen die Sinnzusammenhänge nicht verlorengehen, zu umfangreiche Lernmodule sind allerdings ebenfalls unerwünscht –
eine weitere Herausforderung für den Autor und sein Autorensystem!
AUFBEREITUNG DES STOFFES
Bei der Aufbereitung des Stoffes können die verschiedenen Lernmodelle gemäß Instruktionsmodell
nach Bedarf vermischt werden. Die „richtige“ Zusammenstellung der verschiedenen Aspekte wird
auf absehbare Zeit der Kreativität des Autors vorbehalten bleiben. Allerdings kann er bei dieser Aufgabe unterstützt werden, indem ihm zum Beispiel Hilfestellung mittels didaktischen Hinweisen oder
numerisch bewertbaren Faktoren gegeben wird: So kann der Autor beispielsweise auf zu komplizierte Texte, zu verzweigte hypermediale Strukturen oder grafische Inkonsistenzen aufmerksam gemacht
werden. Die Entscheidung, kritisierbare Konstrukte trotzdem beizubehalten, bleibt aufgrund der herausragenden Stellung der Kreativität aber auf jeden Fall dem Autor überlassen.
Im Zusammenhang mit den Einschränkungen computergestützter Interaktivität sind bei der Aufbereitung des Stoffes wesentlich höhere Anforderungen an die Qualität zu stellen als bei personalem Unterricht. Insbesondere spielt laut Kerres (1998[9], S.79) die Flexibiltät der Lehrperson eine entscheidende Rolle: Mängel in der Wissensvermittlung können vom Computer nicht durch Spontaneität in
der Interaktion ausgeglichen werden, wie dies menschliches Lehrpersonal ohne Probleme leisten
kann.
PRÄSENTATION
Bei der Präsentation sind neben didaktischen auch noch Aspekte der Wahrnehmungspsychologie zu
berücksichtigen: Grundsätzliche Gestaltungsgrundlagen wie „Nicht zuviel Text pro Bildschirm“, „Text
und Grafiken müssen zueinander passen“, konsistenter Gebrauch von Farben, Screenlayouts, etc.
sollten eingehalten werden. Derartige Designgrundlagen können relativ gut vom Autorensystem unterstützt bzw. beurteilt werden.
Aufgrund des Lernermodelles kann auch in der Präsentation von Inhalten auf Vorlieben bei den
Lerngewohnheiten des Rezipienten eingegangen werden: So könnten beispielsweise eine verspielte
Version eines Lernmoduls für „explorative“ Lerntypen generiert werden, eine zweite Version für Leute, die lieber nach behavioristischen Methoden vorgehen, eine dritte, die sich als Nachschlagewerk
präsentiert.
Seite 33
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
Selbstverständlich fließen bei der Präsentation der Inhalte auch noch Aspekte der Navigationsgestaltung ein. Diese werden im Kapitel 6.3 schwerpunktmäßig aufgegriffen.
3.7.2.
Motivation
Wodurch kann Motivation geschaffen werden? – Diese entscheidende Frage ist sehr schwierig zu beantworten: Ein wichtiger Gesichtspunkt ist wie bereits erwähnt, die Neuartigkeit des Mediums Computer. Diese kann momentan noch als gegeben angesehen werden und muß deshalb nicht explizit
durch ein Autorensystem gefördert werden. Weitere Motivationsfaktoren sind sicherlich aufregende
visuelle und inhaltliche Gestaltung, das Ansprechen des Spieltriebs (vgl. geankertes Lernen) und neuartige Interaktionsmöglichkeiten. Letztendlich ist die konkrete Ausprägung und Realisierung derartiger Faktoren aber niemals computergenerierbar, sondern ausschließlich der Kreativität des Autors
überlassen. Allerdings kann der Einsatz der erwähnten Motivationsfaktoren durch eine vergleichsweise einfache Erstellung entsprechender Programmstrukturen unterstützt werden.
3.7.3.
Interaktion
Als wünschenswerte Interaktionsmöglichkeiten von computerbasierten Lernprogrammen können definiert werden:
Gezielter, direkter Zugriff auf interessant erscheinende Inhalte. Dies kann in Form von verschiedenen Ausprägungen hyperlinkbasierter Navigation (vgl. Kapitel 6.3) oder in Form der Fortsetzung einer an sich linearen Handlung durch eine Benutzerentscheidung geschehen.
Interaktion in Form von Aufgaben. Dem Benutzer müssen Aufgaben gestellt werden können, es
muß eine Möglichkeit zur Auswertung der Antworten gegeben sein („interaktiver Film“).
Spezielle Interaktionsmöglichkeiten wie Spiele, Simulationen oder virtuelle Erlebnisräume. Hierfür müssen dem Autoren entsprechende Rapid-Development-Tools zur Verfügung gestellt werden, die den Aufbau entsprechender Strukturen sehr vereinfachen, aber dennoch die notwendige
Flexibilität gewährleisten können.
Darüber hinaus kann eine multimediale Lernumgebung Möglichkeiten bieten, daß sich Lernprogramme individuell an einen Lerner anpassen (beispielsweise über ein Benutzerprofil) und darüber
hinaus – dank des Einsatzes im Intranet – zusätzliche Mensch-zu-Mensch-Interaktionsmöglichkeiten
schaffen
3.7.4.
Inhaltliche Qualität
Inhaltliche Qualität ist als ein redaktioneller Faktor aufzufassen: Es muß eine Art „letzter Instanz“ im
Produktionsprozeß existieren, die Lerninhalte und ihre Umsetzung auf Fehler, Inkonsistenzen usw.
untersucht. Dafür muß ein Systementwurf entsprechende Mechanismen zur Verfügung stellen.
Denkbar sind hier beispielsweise eine Art „Überarbeiten“-Modus, in der der Schlußredakteur Kommentare zu den einzelnen Schritten anmerken kann. Derartige Aspekte werden im Abschnitt „The
Making of...“ behandelt.
Seite 34
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
3.7.5.
Selbstorganisation
Selbstorganisiertes Lernen kann durch eine Lernumgebung insofern zusätzlich unterstützt werden,
daß einzelne Lernmodule aus der Intranet-Umgebung gelöst werden können und – auf CD-ROM
gebrannt – auch auf einem „isolierten“ Rechner (also beispielsweise beim Lerner zuhause) rezipiert
werden können. Dieser Forderung nach „Cross-Media“-Publishing muß der Systementwurf Rechnung tragen und entsprechende Funktionalitäten bereitstellen.
Es wurde andiskutiert, daß dem Lerner auch innerhalb der intranetbasierten Lernumgebung Mechanismen zur Verfügung gestellt werden sollten, die das selbstorganisierte Lernen unterstützen. Dies
kann zum Beispiel durch das Zusammenstellen themen- oder rezipientenorientierter, individueller
Lehrgänge aus verschiedenen Lernmodulen erreicht werden. Ebenso spielen Navigationsaspekte
beim selbstorganisierten Lernen eine entscheidende Rolle – der Lerner muß sich im Stoff ohne die
Hilfe Dritter zurechtfinden können, er darf sich nicht verloren vorkommen. Äquivalent hierzu muß
die Mensch-zu-Mensch-Kommunikation durch entsprechende Mechanismen gewährleistet werden
können. Diese Ansätze werden in den Abschnitten „Konturen im Nebel“ und „Knoten, Links, Netze“
nochmals aufgegriffen und entsprechend ausgearbeitet.
Eine letzte Folgerung aus der Selbstorganisation: Um den Lerner „bei der Stange zu halten“, können
beispielsweise Tests eingeführt werden, die bei Weiterbildungsmaßnahmen auch bewertet werden.
Somit ist ein extrinsischer Faktor geschaffen, der (leider) sehr wirksam eine Beschäftigung mit dem
Lernprogramm erzwingen kann. Derartige Methoden sollen allerdings in der vorliegenden Arbeit
nicht weiter ausdiskutiert werden – vielmehr sollen Möglichkeiten gesucht werden, wie die Erstellung
eines Lernmoduls innerhalb einer Lernumgebung so unterstützt werden kann, daß derartige
Zwangsmaßnahmen erst gar nicht notwendig werden.
3.8.
LERNEN & MEHR?
Elemente einer Lernumgebung
Lernumgebung ist einer dieser Kaugummi-Begriffe, mit denen man wunderbar um sich werfen kann,
ohne damit etwas Konkretes bezeichnen zu müssen. Eine Lernumgebung ist sicher mehr als ein Arbeitsplatz mit Computer, Maus und CBT oder eine Schulklasse mit Lehrer. Ich will deshalb in diesem
Kapitel sowohl eine Begründung für den Einsatz als auch eine didaktische Definition des Begriffes
geben.
3.8.1.
Didaktische Definition
Zunächst muß der Begriff Lernumgebung definiert werden. Kerres (1998[9], S.16f) nennt folgende Eigenschaften:
Ansammlung unterschiedlicher Medien und Hilfsmittel
motivationsfördernde Aufbereitung der Medien
Eigenaktivitäten des Lerners als Basis
Schaffung eines sozialen Umfeldes
bewußte Planung und Steuerung des Lernverhaltens
Auf multimediale Lernumgebungen bezogen ergeben sich nach Kerres (S.17) folgende Forderungen:
Rezeption multimedial gestalteter Lernmodule
Seite 35
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
die Möglichkeit zur Bearbeitung und Verarbeitung der Inhalte
ggf. die Generierung neuer Information
Mensch-zu-Mensch-Kommunikation über das technische Medium, beispielsweise über netzwerkbasierte Technologien
3.8.2.
Begründung
Eine Lernumgebung schafft also gemäß Definition den in diesem Abschnitt bereits öfters erwähnten
situativen Kontext, indem sie Lernmodule in einer Art „Rahmen“ zusammenhält. Eine computergestützte Lernumgebung kann die soziale Dimension eines Klassenverbandes zwar immer noch nicht
ersetzen, versucht allerdings durch entsprechende interpersonelle Kommunikationsmöglichkeiten eine Milderung des Problems herbeizuführen. Auch wird die Rolle des Lehrers einbezogen: Ein Tutor
kann zumindest bei Problemen zur Unterstützung herangezogen werden. Damit können „starre“
Lernmodule die eigentliche Wissensvermittlung übernehmen, in Problemfällen kann der Tutor eine
ähnlich flexible Reaktion wie im „richtig“ personalen Unterricht leisten, ohne einen vergleichbaren
Personalaufwand zu erfordern – denn schließlich wird der Großteil der Wissensvermittlung von den
Lernmodulen erledigt.
3.8.3.
Formen multimedialer Lernumgebungen
Nach der Begründung für eine Lernumgebung möchte ich nun die Grundmodelle des netzbasierten
Lernens inklusive einer Kurzbewertung darstellen. Meine Ausführungen beziehen sich auf Steinke
(1997[32], S.24ff).
FERNUNTERRICHT/TELE-TEACHING
Diese beiden Varianten netzbasierten Lernens sind stark tutorenzentriert: Beim Tele-Teaching wird
personaler Unterricht per technischer Distribution ortsunabhängig gemacht. Fernunterricht stellt dem
Lerner neben vorgegebenen Lerneinheiten („Studienbrief“), die zu einem bestimmten Zeitpunkt bearbeitet werden muß, einen Tutor als Kursleiter, Korrektor und Betreuer zur Seite. Die Problematiken
computergestützten Lernens werden also umgangen.
Die eigentlichen Lerninhalte sind bei dieser Art der Lernumgebung also nicht in die Lernumgebung
integriert, sondern werden per Post, Fax oder ähnlichen konventionellen Distributionsmedien verteilt. Insbesondere machen diese Angebote keinen Gebrauch von multimedialen Vorteilen, sondern
beschränken sich auf die Aufbereitung des Lernstoffes wie in einem Lehrbuch. So sieht Steinke keine
entscheidenden Vorteile gegenüber konventionellem personalen Unterricht. Nachteilig ist die fehlende soziale Umgebung; zwar ist jedem Lerner ein Tutor zugeordnet, das Lernen in der Gruppe fällt
aber komplett weg. [Steinke, 1997[32], S.24ff und S.30f]
OPEN-DISTANCE LEARNING
Das Open-Distance-Learning verzichtet größtenteils auf die Betreuung durch einen Tutor oder Betreuer. Die Lerninhalte liegen zentral in einer Datenbank vor und können von den Lernern beliebig
abgerufen werden. Dadurch ist der Lerner ziemlich auf sich alleine gestellt. Deshalb steht auch in
Open Distance Learning-Systemen ein Tutor oder Betreuer bereit, der bei Bedarf kontaktiert werden
kann. Im Gegensatz zum Fernunterricht findet allerdings keine eindeutige Zuordnung von einem
Lerner zu einem Tutor statt, die Verbindung zwischen Lerner und Lehrendem ist wesentlich weniger
intensiv. Auch in diesem Modell fehlt der Aspekt des Lernens in Gruppen. [Steinke, 1997, S.28ff]
Seite 36
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
VERTEILTES, KOOPERATIVES LERNEN
Das Modell des verteilten, kooperativen Lernens (vgl. Steinke, 1997[32], S.32f) sieht die Bildung von
Lerngruppen, in die sich einzelne Lerner zusammenschließen können, und die Betreuung durch einen Tutor vor. Es soll eine Atmosphäre der Diskussions- und Zusammenarbeitsbereitschaft gefördert
werden. Die Diskussion fördert gleichzeitig eine aktive Auseinandersetzung mit den Lerninhalten.
Das System stellt zur Realisierung von Lerngruppen Diskussionsforen („Schwarzes Brett“) und Chats
zur Verfügung, die von einem Tutor oder Betreuer moderiert werden. Außerden müssen Kommunikationsmöglichkeiten innerhalb einer Lerngruppe geschaffen werden, sofern deren Mitglieder räumlich voneinander entfernt sind. [Steinke, 1997[32], S.33ff]
MISCHFORMEN
Wie üblich existieren neben den Reinformen auch noch zahlreiche „Bastarde“, die die positiven Aspekte der jeweiligen Grundmodelle miteinander kombinieren. Genau dies werde ich für meinen Systementwurf auch machen.
RÜCKSCHLÜSSE AUF DEN SYSTEMENTWURF
Der meinem System zugrunde liegende Begriff der „Lernumgebung“ soll dem „situierten Kontext“
besondere Bedeutung zumessen – es soll dem Lerner also eine Umgebung angeboten werden, die
ihn bei seinen Lernbemühungen unterstützt, indem sie
möglichst viele (didaktische) Vorlieben, Verhaltensweisen und Eigenschaften des Lerners in Form
eines differenzierten „Lernermodells“ abzubilden versucht
dieses Lernermodell auch für Lernmodule zu deren individuellen Anpassung zur Verfügung stellt
dem Lerner eine möglichst aktive Verarbeitung von Lerninhalten ermöglicht
dazu die entsprechenden Werkzeuge und vor allem Möglichkeiten zur Kommunikation mit anderen Personen zur Verfügung stellt
dem oder den Tutoren hinreichende Möglichkeiten zur Moderation bzw. „Überwachung” des
didaktischen Geschehens bietet
Diese Anforderungen werde ich im folgenden Unterkapitel zu einem didaktischen Konzept für die in
dieser Diplomarbeit skizzierte Lernumgebung verschmelzen.
3.8.4.
Synthese
Grundlage meines Systementwurfs sind einerseits die Lernmodule, die das zu vermittelnde Wissen
enthalten (vgl. Modell des Open-Distance Learning), und andererseits die Elemente der eigentlichen
Lernumgebung, die auf dem Benutzerprofil und den an das Modell des verteilten, kooperativen Lernens angelehnten Kommunikationsmöglichkeiten basieren.
Die Verbindung zwischen Lernmodulen und Lernumgebung soll verstärkt werden, indem
Lernmodule auf das Benutzerprofil zugreifen können
benutzergruppenspezifische Variationen in Lernmodule eingebaut werden können
Aktionen, die von einem Benutzer in einem Lernmodul ausgeführt werden, von der Lernumgebung weiterverarbeitet werden können
Die Kommunikationsmöglichkeiten zwischen den einzelnen Lernern und dem Tutor bestehen aus:
eMails
Schwarzes Brett (moderiert) als Diskussionsforum
Seite 37
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
moderierte und unmoderierte Chats zum direkten Austausch der Lerner untereinander, und zwar
sowohl lerngruppenspezifisch als auch lernumgebungsweit
Schließlich soll der Lerner durch entsprechend mächtige Werkzeuge bei der Selbstorganisation seines
Lernens unterstützt werden:
Umfassende und einfache Zugriffsmöglichkeiten auf die Lerninhalte (Archiv-Funktionalität)
Der Betreuer kann individuelle Lehrgänge für die Lerner beziehungsweise Lerngruppen zusammenstellen.
Gleichfalls kann dieses Zusammenstellen auch vom System anhand vom Benutzer vorgegebener
Kriterien und Stichworte vorgenommen werden.
Es ergibt sich folgendes Bild:
Betreuung/Rückfragen
Lerngruppe
Lerner
Lerngruppe
Lerner
Lerner
Lerner
Lerner
Lerner
Benutze rverwaltung
Moderation
Chats
Benutzerprofil
Benutzerprofil
Benutzerprofil
Lernmodul
Lernmodul
Verwaltung
Organisation
Lernumgeb
Benutzerprofil
Tutor/Betreuer
u ng
Schwarzes
Brett
Lernmodul
3.9.
FAZIT & AUSBLICK
Abschnitt 3, kurz zusammengefaßt
So schön es auch wäre: Die Konzeption einer didaktisch „guten“ und gleichzeitig erfolgreichen Lernanwendung läßt sich durch Computer nicht automatisieren. Die Kreativität und Beurteilungsfähigkeit
Seite 38
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Multimediales Lernen – wie funktionert das? – Anforderungen an hypermediale Lernsysteme aus Lernersicht
des Autors besitzt eine zu entscheidende Rolle. Bestenfalls können dem Autoren Hilfen bei der Konzeptionserstellung und eine Analyse numerisch erfaß- und verarbeitbarer Eckdaten zur Verfügung gestellt werden.
Die meiner Meinung wichtigste Folgerung aus diesem Abschnitt ist, daß die hier diskutierten Vorteile
des computerbasierten Lernens (z.B. spezielle Interaktionsformen) dem Autor so zur Verfügung gestellt werden sollten, daß er sie einfach, intuitiv und sinnvoll in seine Konzeption einbeziehen kann.
Ebenso kann der kreative Prozeß des Autors durch didaktisch begründete Werkzeuge unterstützt
werden.
Dieser Abschnitt hat ebenfalls die Bedeutung des situativen Kontextes gezeigt. Dies bedeutet, daß in
einer Lernumgebung ein besonderes Augenmerk auf Mensch-zu-Mensch-Kommunikationsmöglichkeiten sowie ein ausgefeiltes Lernermodell gelegt werden sollte.
In diesem Abschnitt habe ich also einige Kernaussagen getroffen, welche didaktischen Konzepte und
Methoden ich innerhalb meines Systementwurfs zur Verfügung stellen möchte. In den folgenden Abschnitten werde ich auf andere Aspekte, beispielsweise die Produktion oder den Intranetfaktor eingehen und dabei die hier getätigten Aussagen berücksichtigen.
Seite 39
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.
The Making of...
Die Erstellung eines Lernmoduls
Bisher habe ich hauptsächlich didaktische und grundlegende konzeptionelle Aspekte für den Funktionsumfang eines Systementwurfes diskutiert. Diese sollen nun in den Kontext der Produktion von
Lernmodulen eingeordnet werden: Wie läuft eine solche Multimediaproduktion ab? Welche Unterstützungsmöglichkeiten können den Produzenten angeboten werden? Und: Welche Folgerungen
können daraus für einen Systementwurf gezogen werden?
In diesem Abschnitt werden bereits wesentliche Anforderungen an des Systems definiert werden.
Dennoch muß sich die Antwort auf die letzte Frage auf eine eher abstrakte Charakterisierung von Eigenschaften der in diesem Abschnitt diskutierten Elemente beschränken. Außerdem umfaßt sie ausschließlich solche Elemente des Systementwurfs, die sich in diesem Stadium der Systemanalyse bereits sinnvoll beschreiben lassen.
Das endgültige und vor allem umfassende Konzept des Systems wird erst im Abschnitt „Knoten,
Links, Netze“ synthetisiert werden – in enger Wechselwirkung mit den bereits an dieser Stelle vorgenommenen Konkretisierungen.
4.1.
WIESO PRODUKTION?
Die „Existenzberechtigung“ für diesen Abschnitt
Der Titel dieser Diplomarbeit erwähnt den Produktionsaspekt mit keinem Wort. Ziel ist die „Integration einer objektorientierten Datenbank in eine [...] Lernumgebung“. Dies mag zunächst danach aussehen, als ob hier das Thema mißachtet würde.
Nur: Kann der Begriff „Lernumgebung“ überhaupt von der Produktion seines wichtigsten Bestandteils, den Lernmodulen, entkoppelt werden? Schließlich definiert die Produktion die Qualität dieser
Module – und damit der gesamten Lernumgebung – entscheidend mit. Da eine Lernumgebung nun
mal auf Lernmodulen aufbaut, müssen auch Wege zu deren Produktion aufgezeigt werden!
Ebenso sollte man Synergieeffekte nicht unterschätzen, die sich ergeben können, wenn der Lerner
die Möglichkeit erhält, dank der hier vorgestellten Produktionsfunktionalitäten eigene kleine Spiele
oder Slide-Shows zu erstellen. Dies fördert die aktive Auseinandersetzung mit den Inhalten gemäß
konstruktivstischer Theorie.
Außerdem bietet – wie sich zeigen wird – gerade der Einsatz von objektorientierter Technologie riesige Vorteile für die komplette und saubere Integration der Produktionsphase in die Lernumgebung.
Die entsprechenden Attribute und Funktionalitäten können also beim Systementwurf einer Lernumgebung ohne größeren Aufwand einfließen, wenn die entsprechenden Anforderungen erst einmal
definiert ist.
Aus den angeführten Gründen habe ich die Produktionsphase in diese Diplomarbeit miteinbezogen
– sozusagen als „Sahnehäubchen“ meiner Ausführungen.
Seite 40
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.2.
„MACH‘ MAL...“
Analyse einer ganz normalen Multimedia-Produktion
Die hier aufgezeigte Analyse basiert auf einem exemplarischen Produktionsprozeß, wie er beispielsweise bei der Firma HQ durchgeführt wird. Kerres (1998, S.327) beschreibt eine ähnliche Vorgehensweise, so daß die hier gemachten Aussagen durchaus verallgemeinernd betrachtet werden können. Zu Beginn soll ein entsprechendes Phasenmodell stehen, das sich direkt an den Anforderungen
der Praxis orientiert:
I. Idee & Ausformulierung
II. Inhaltliches Design
III. Medienproduktion
IV. Programmproduktion
Jede der hier aufgeführten Phasen unterteilt sich in weitere Unterphasen, die in den folgenden Unterkapiteln entsprechend ausgeführt sind. Konkrete Ziele/Meilensteine/Dokumente der einzelnen
Phasen sind in den Grafiken fett hervorgehoben. Ein besonderes Augenmerk habe ich dabei auf das
Prototyping10 gelegt, da ihm auch in der Praxis erfahrungsgemäß eine große Bedeutung zukommt.
Der Systementwurf sollte dieses Prototyping soweit als möglich unterstützen.
4.2.1.
Phase I: Idee & Ausformulierung
Die erste Phase eines „normalen“ Produktionsprozesses kann folgendermaßen unterteilt werden:
Grundgedanken
Exposé /
Treatment
Interne Überarbeitungen
Schlußredaktion
Abnahme durch
den Kunden
Kundenwünsche
Prototyping
In Produktionen für den Massenmarkt – also bei Produktionen ohne spezifischen Projektkunden –
übernehmen interne Kontrollinstanzen (Projektleiter, etc.) die entsprechenden Kundenfunktionen.
Zusätzlich muß in einem solchen Falle Marktforschung u.ä. getrieben werden, um das Produkt
marktgerecht plazieren zu können [vgl. Kerres, 1998[9], S.327]. Da derartige Aktivitäten mit einem
Systementwurf wenig zu tun haben, werde ich sie in meiner Arbeit außen vor lassen.
IDEE
Am Beginn eines Lernprogrammes steht eine Idee – und aus dieser Idee sollte eine Definition der didaktischen Ziele folgen.
Als Idee will ich im Zusammenhang der vorliegenden Arbeit den inhaltlichen Grundgedanken eines
Lernprogrammes ansehen. Ob die Idee nun aus einem umfassenden Handlungsstrang (vgl. geankertes Lernen) oder aus einem eher allgemein gefaßten Grundmotiv (beispielsweise „Lernen durch Un-
10
Unter Prototyping wird eine „teilweise gewollt unvollständige Implementierung eines Software-(Teil)-Systems zum Zwecke der frühzeitigen
Bewertung“ verstanden (Hesse u.a., 1992[38], S.65)
Seite 41
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
terhaltung mit vielen spielerischen Elementen“) besteht, soll dem Autor überlassen bleiben. Die Form
der Idee sollte allerdings den angestrebten Lernzielen angemessen sein.
Gemäß Field (1991[37], S.23) sollte die Idee für einen Film in drei oder vier Sätze gepackt werden
können. Dies mag für eine komplexe interaktive Multimedia-Anwendung zu wenig erscheinen –
dennoch ist es auch für Multimedia-Autoren äußerst sinnvoll, bereits ganz zu Beginn klar und prägnant die Idee zu seiner Anwendung darzulegen. Bleibt der Konzeptionist dann einmal in seinem kreativen Prozeß stecken, kann er sich problemlos seine Grundidee – also seinen „roten Faden“ –
nochmals vor Augen führen.
Ziele wiederum sind ein Element der didaktischen Konzeption (vgl. Instruktionstheorie) und dienen
dem Autoren dazu, seine Konzeptionen auf das Erreichen des Lernerfolges hin überprüfen bzw. seine Idee besser fokusieren zu können.
Idee und Ziele sollen gleichberechtigt nebeneinander stehen, da sie sich gegenseitig beeinflussen und
somit lediglich zwei unterschiedliche „Ansichten“ des gleichen Lernprogrammes darstellen: Die Idee
richtet sich nach den Zielen, Ideen können aber auch neue Ziele zur Folge haben. Ich möchte Ideen
in dieser Ausarbeitung als das kreative Element (das „Wie“) eines Lernmoduls verstehen, während die
Ziele eher die fachlichen Grundlagen („Was“, „Wem“, „Wieso“) festlegen.
Meist sind Ideen und Ziele das Ergebnis von mehr oder weniger ausgedehnten BrainstormingProzessen.
EXPOSÉ/TREATMENT
Im Folgenden möchte ich kurz die Merkmale von Exposé und Treatment zusammenfassen. Die Darstellung orientiert sich an Kleeberger/Eisenhauer (1996[39], S.34ff) und an der Praxis der Firma HQ.
Exposé
INHALTE:
Projektziele
inhaltliche Strukturen
ggf. Grad der Interaktivität
aber: keine konkreten Inhalte
grobe Zeitplanung
erste Kostenabschätzung
ZWECK:
Das Exposé soll einen ersten Überblick über ein
Projekt und seine Ziele geben.
Marketingmäßig dient das Exposé dazu, einen
potentiellen Kunden für das Projekt zu interessieren oder bei einer Projektausschreibung Mitbewerber auszustechen.
BETEILIGTE PERSONEN:
ein oder mehrere Autoren
ggf. Projektmanager
FORM:
Papier
Treatment
INHALTE:
Überblick über die Inhalte
kurze Definition der Programmstruktur
Kommunikationsziele
ggf. erste Überlegungen zu gestalterischen Aspekten
korrigierte Zeitplanung & Kostenabschätzung
ZWECK:
Das Treatment kann als direkter Leitfaden zur Umsetzung der Idee in ein Drehbuch verwendet werden:
Hier sind die Inhalte bereits grob dargestellt, evt. existieren bereits Gestaltungsprinzipien.
Bei der Gestaltung des Treatments wird der Kunde i.a.
bereits miteinbezogen, so daß dessen Wünsche bereits
in diesem Stadium sehr stark berücksichtigt werden
können.
BETEILIGTE PERSONEN:
ein oder mehrere Autoren
Redakteur(e)
Kunde
Projektmanager
FORM:
Papier
Ist der Ideenfindungsprozeß größtenteils abgeschlossen, muß das Grundkonzept also soweit aufbereitet werden, daß am Ende ein Exposé oder Treatment steht.
Seite 42
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Aus Sicht des Systementwurfs – projektmanagementbezogene Ansätze sollen ja nicht berücksichtigt
werden – besteht das Exposé11 also schwerpunktmäßig aus einer Darstellung der Projektziele. Für
den Systementwurf muß ein Weg gefunden werden, wie die Zieldefinitionen des BrainstormingProzesses in druckbare Inhalte für ein Exposé aufbereitet werden können.
Das Treatment wiederum konzentriert sich eher auf die inhaltliche Seite der Grundidee. Hierfür
müssen ebenfalls Mittel und Wege gefunden werden, die entsprechenden Inhalte des Brainstormings
in eine druckbare Form zu bringen.
SCHLUßREDAKTION
Die Schlußredaktion dient in dieser Phase dazu, das fertige Treatment auf Fehler, Inkonsistenzen
usw. zu überprüfen und dem Autor ggf. ein Feedback zur Überarbeitung zu geben. Die Schlußredaktion ist ein Instrument der Qualitätssicherung.
PROTOTYPING
Bereits am Beginn eines Projektes können erste Prototypen „gebastelt“ werden, die einen allerersten
Eindruck über das Projekt verschaffen oder die mögliche Realisierbarkeit ausgesuchter Funktionalitäten überprüfen.
4.2.2.
Phase II: Inhaltliches Design
Das inhaltliche Design läßt sich in folgende Vorgänge aufgliedern:
Recherche
inhaltliche
Redaktion
Prototyping
Kundenwünsche interne Überarb.
Ideen&Ziele
Konzeption/
Drehbuch
Kundenwünsche interne Überarb.
Schlußredaktion
Abnahme durch
den Kunden
Produktionsplanung
Auch hier wird wieder von einem „kundenzentrierten“ Vorgehen ausgegangen. Bei einer Produktion
für den Massenmarkt werden die entsprechenden Aufgaben von internen Instanzen wahrgenommen.
IDEEN & ZIELE
Die in der ersten Phase ausgearbeiteten Ideen & Ziele (in Form von Treatment und Exposé) bilden
die Grundlage des inhaltlichen Designs. Sie bleiben auch in diesem Produktionsabschnitt formbar –
neue Ideen können jederzeit eingeflochten werden.
11
alternativ: Offerte
Seite 43
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Ideen und Ziele behalten weiterhin ihre Bedeutung als zentrale Elemente, an denen sich die gesamte
Konzeption bis hin zum Drehbuch zu orientieren habt.
RECHERCHE
Die Recherche dient dazu, das Hintergrundwissen zum Lernprogramm zu sammeln und zu verdichten. Dabei wird sozusagen eine Art „Faktennetz“ aufgebaut, das alle für die Konzeption benötigten
Informationen aufnimmt, die vom Autor aufbereitet und in den kreativen Prozeß eingeflochten werden. Im allgemeinen wird die Recherche in enger Zusammenarbeit mit dem Kunden durchgeführt,
da die zu behandelnden Themengebiete üblicherweise von ihm bestimmt bzw. umgrenzt werden.
KONZEPTION/DREHBUCH
Das Drehbuch ist letztlich das Ziel des inhaltlichen Designs. Es ist die direkte Vorlage für die Medienproduktion und die Programmierung des Lernmoduls. Üblicherweise läßt es sich durch folgende
Elemente charakterisieren [vgl. Kleeberger/Eisenhauer, 1996, S.37ff]:
Drehbuch
INHALTE:
detaillierte Darstellung des Programmablaufs
detaillierte Darstellung der Handlung
Definition aller Interaktionsmöglichkeiten
ausformulierte Screen- und Sprechertexte
Umschreibung/skizzenhafte Darstellung aller visuellen Elemente (Grafiken, Videosequenzen, Zeichnungen)
Umschreibung der auditiven Elemente
Beschreibung von Simulationsszenarien, etc.
ZWECK:
Das Drehbuch dient als Grundlage des kompletten Produktionsprozesses. Aus ihm sind alle zu erstellenden Medienelemente ersichtlich. Ebenso werden Programmablauf und Interaktionsmöglichkeiten ersichtlich.
BETEILIGTE PERSONEN:
ein oder mehrere Autoren
Projektmanager
Kunde
Redakteur(e)
Medienproduzenten12 (Grafiker, Video- und Audioproduktion)
Programmierer12
FORM:
Papier. Je nach Anwendungstyp können grafische oder textorientierte
Drehbücher erstellt werden.
Parallel zur Drehbucherstellung müssen in dieser Produktionsphase neben dem inhaltlichen auch
andere Designprinzipien – hauptsächlich die visuelle, aber auch die auditive Gestaltung – festgelegt
werden. Dabei geht es noch nicht um die konkrete Ausdetaillierung von einzelnen Medienelementen, sondern um die Festlegung von Richtlinien. An diesen Richtlinien und den Beschreibungen/Skizzen des Drehbuchs folgt dann die Ausarbeitung des konkreten Medienelementes. Auch für
die Designrichtlinien möchte ich im Folgenden eine Kurzdarstellung geben:
12
Medienproduzenten und Programmierer sollten bereits in den Drehbuchentwurf integriert werden, damit die Realisierbarkeit des Entwurfs
gewährleistet werden kann.
Seite 44
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Designrichtlinien
INHALTE:
Verhältnisse der Medienelemente untereinander
prinzipielle Verwendung von Farbrastern
Screenlayout/Gestaltungsraster/Verwendung von Schriften/etc.
prinzipielle Festlegung der Verwendung von Audioelementen
ZWECK:
Die Designprinzipien sind eine – ggf. selbstgestellte – Vorgabe für die
Medienproduzenten, nach denen sie die Gestaltung ihrer Arbeit richten
sollten bzw. müssen.
BETEILIGTE PERSONEN:
Medienproduzenten
ein oder mehrere Autoren
Projektmanager
ggf. Kunde
FORM:
Papier (outgesourcte Produktion) oder elektronisch (Inhouse-Produktion).
Idealerweise beeinflussen sich Designrichtlinien und Drehbuch gegenseitig – Synergieeffekte zwischen Gestaltung und Konzeption sind ausdrücklich erwünscht! Deshalb werden diese beiden Konzeptionsinstrumente auch oft zusammengefaßt – beispielsweise beim grafischen Storyboarding (vgl.
Kapitel 4.6.1).
Bei der Erstellung von Drehbuch und Designrichtlinien sind wieder die üblichen qualitätssichernden
Maßnahmen in Form von Feedbackmechanismen vorhanden.
REDAKTION
Die Redaktion dient auch in dieser Phase dazu, sowohl die recherchierten Fakten als auch das Drehbuch selbst auf Inkonsistenzen und Fehler zu überprüfen und dem Autoren bzw. den Recherchierenden ein entsprechendes Feedback zu geben.
PRODUKTIONSPLANUNG
Die Produktionsplanung umfaßt organisatorische Aspekte wie die Erstellung eines Drehplans für die
Videosequenzen oder eine Auflistung sämtlicher zu produzierender Medien. Die Inhalte der Produktionsplanung gehen direkt aus dem Drehbuch hervor und werden um die entsprechenden organisatorischen Elemente ergänzt.
Auch die Produktionsplanung will ich hier darstellen:
Produktionsplanung
INHALTE:
Auflistung aller zu produzierenden Medienelemente
ggf. Erstellung spezieller Drehbücher (beispielsweise für die Videoproduktion, für die Aufnahme der Sprechertexte, etc.)
Drehplan (Videoproduktion) bzw. Studiobuchung (Audioproduktion)
prinzipielle Festlegung der Verwendung von Audioelementen
Abklärung von Rechten, wenn vorproduzierte Medienelemente verwendet werden sollen
ZWECK:
Die Produktionsplanung dient dazu, die Medienproduktion möglichst
reibungslos ablaufen zu lassen. Ebenso muß sichergestellt werden, daß
kein Element „vergessen“ wird.
Seite 45
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Produktionsplanung
BETEILIGTE PERSONEN:
Medienproduzenten
ein oder mehrere Autoren
Projektmanager
ggf. Kunde
FORM:
Papier (outgesourcte Produktion) oder elektronisch (Inhouse-Produktion).
PROTOTYPING
Auch in dieser Phase der Anwendungserstellung kann es notwendig sein, die Realisierungsmöglichkeiten bestimmter Programmelemente sicherzustellen. Hierfür werden wiederum Prototypen herangezogen.
4.2.3.
Phase III: Medienproduktion
Auch für die Phase der Medienproduktion will ich zunächst eine grafisch aufbereitete Darstellung
geben:
Medienbeschaffung
Produktionsplanung
Medienproduktion
Abnahme durch
den Kunden
Digitalisierung
Kunde
PRODUKTIONSPLANUNG
Die Produktionsplanung entstammt der vorangegangen Produktionsphase und ist Grundlage der Medienproduktion: Sie stellt auf den jeweiligen Medientyp zugeschnittene Drehbuchfassungen zur Verfügung und definiert den Produktionsablauf.
MEDIENPRODUKTION
Unter Medienproduktion verstehe ich die Erstellung von eigens für das Projekt konzipierten Medienelementen. Die Medienproduktion erfolgt außerhalb des hier vorgestellten Systems und wird deshalb
nicht weiter beachtet.
MEDIENBESCHAFFUNG
Unter Medienbeschaffung verstehe ich hier den Erwerb von Lizenzrechten für von Dritten bereits
vorproduzierten Medien (beispielsweise Tagesschau-Berichte o.ä.). Auch dieser Bereich wird nur insofern unterstützt, daß eine entsprechende Auflistung in die Produktionsplanung aufgenommen wird.
Seite 46
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
DER KUNDE
Bei kundenorientierten Projekten wird der Kunde meist in die Medienproduktion miteinbezogen:
Idealerweise ist er ist bei der eigentlichen Produktion anwesend, oder die fertiggestellten Medien
werden von ihm abgenommen. Dies ist insofern wichtig, daß auch hier (beispielsweise im Hinblick
auf die grafische Gestaltung des Benutzerinterfaces) Kontroll- und Demonstrationsmöglichkeiten greifen sollten.
DIGITALISIERUNG
Nachdem die Medien auf analogem (oder bereits digitalen) Wege produziert wurden, müssen sie digitalisert und/oder nachbearbeitet werden. Am Ende dieses Prozesses stehen die fertigen Medienelemente in den üblichen PC-Formaten (Wave-Sound, AVI-Video, Quicktime-Video, ...), die der Programmierer direkt in die Anwendung einbinden kann.
4.2.4.
Phase IV: Programmproduktion
Auch hier zunächst ein grafischer Überblick:
Drehbuch
Medien
Systementwurf
Programmierung
Tests
Abnahme/
Evaluation
interne Überarbeitung
Endprodukt
DREHBUCH
Das Drehbuch dient als Grundlage der Programmproduktion. Aus ihm folgen Programmablauf und
Medieneinsatz.
MEDIEN
Medien sind die fertig aufbereiteten Elemente aus der Medienproduktion. Sie sollten in der Programmproduktions-Phase nur noch in das Anwendungsgerüst eingebunden werden müssen. Es müssen allerdings auch in der Phase der Programmproduktion noch vollständige Nachbearbeitungsmöglichkeiten vorgesehen sein.
SYSTEMENTWURF
Zu jedem Programm sollte eine Art Systementwurf gehören, in dem zumindest die Lösungsstrategien
für durch die inhaltlichen Strukturen aufgeworfenen Probleme sowie ein Modell des Programmgerüstes festgehalten sind. Idealerweise richtet sich der Systementwurf nach dem Phasenmodell der Softwareentwicklung (vgl. Kapitel 2.1.2).
Seite 47
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
PROGRAMMIERUNG
Die Programmierung dient der Umsetzung des Drehbuches unter Berücksichtigung der Medienelemente in ein ablauffähiges Programm, welches vom Kunden eingesetzt werden kann. Für die Programmierung müssen die entsprechenden Voraussetzungen geschaffen werden: Oft benutzte Funktionalitäten müssen nach dem multimediatypischen Baukastenprinzip zusammengesetzt werden können. Die Ablauflogik sollte möglichst einfach und effizient aus dem Drehbuch übernommen werden
können – beispielsweise über vordefinierte Schablonen.
Während der Programmierung finden normalerweise Modultests statt, bei denen die gerade implementierten Funktionalitäten auf ihre Ablauffähigkeit geprüft werden.
TESTS
Aufgrund der hohen Komplexität von Computerprogrammen fällt der Testprozedur eine große Bedeutung zu. Der Testvorgang kann unterstützt werden, indem ein System beispielsweise automatisch
nach unaufgelösten Referenzen etc. sucht. Letztlich bildet aber auch hier der Mensch die letzte Instanz, die durch möglichst trickreiche Aktionen Fehler zu produzieren versucht. Der Programmierer
enthält vom Testpersonal entsprechendes Feedback in Form von Fehlerlisten, die abzuarbeiten sind.
Das überarbeitete Programm wird einem erneuten Test unterzogen, bis keine Fehler mehr zu provozieren sind.
ABNAHME/EVALUATION
Ist das Programm intern „freigegeben“ worden, geht eine Evaluationsversion an den Kunden. Dieser
kann dann nochmals Änderungswünsche äußern. Nach einer möglichen Überarbeitung ist die Produktion beendet; das Endprodukt geht an den Kunden.
4.3.
DER GROßE ZUSAMMENHANG
Wie sich Ideen, Drehbuch & Co. zu einem integrierten System ergänzen
Im vorigen Kapitel habe ich versucht, den Produktionsprozeß eines Multimedia-Programmes nachzuvollziehen. Ziel ist nun, die einzelnen Phasen zu einem so weit wie möglich integrierten Prozeß zu
verschmelzen, an dessen Ende ein fertiges Lernmodul steht. Dazu will ich zunächst versuchen, die
Ziele zu definieren, die der Systementwurf auf Produktionsseite erfüllen soll. Danach werde ich versuchen, diese Ziele zu einem integrativen Konzept zu verschmelzen und abschließend verschiedene
Aspekte daraus aufgreifen.
4.3.1.
Ziele aus produktionstechnischer Sicht
Folgende Ziele sollte ein integrierendes multimediales Entwicklungssystem aus produktionstechnischen Aspekten verfolgen:
höhere Qualität des Endproduktes
bessere Effizienz bei der Produktion (Kosteneinsparungen)
Zeitersparnis bei der Programmentwicklung
Seite 48
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
HÖHERE QUALITÄT
Zunächst bietet sich ein integriertes System dazu an, die inhaltliche und didaktische Qualität der
Lernmodule zu verbessern: Einerseits kann der kreative Prozeß der Autoren unterstützt und gefördert
werden. Andererseits bieten sich durch die Integration in den Kontext einer Lernumgebung zusätzliche Möglichkeiten, auf die individuellen Bedürfnisse des Lerners einzugehen.
Ebenso kann ein integriertes System die inhaltliche Qualität eines Lernmodules verbessern, indem
entsprechende Kontrollinstanzen obligatorisch eingebaut werden. In der Darstellung des Produktionsprozesses stellen beispielsweise alle redaktionellen Elemente solche Kontrollinstanzen dar.
Weiterhin kann ein integriertes System durch die Möglichkeit automatisierter Programmgenerierung
oder die halbautomatische Erstellung von Exposé, Drehbuch und Produktionsplanung dabei helfen,
lästige (und mithin teure) Fehler zu vermeiden.
BESSERE EFFIZIENZ
Durch einen integrierten Produktionsprozeß, wie ihn diese Arbeit einführen will, kann effizienter
produziert werden: Sämtliche notwendigen Information werden zentral vorgehalten und können ebenso zentral verarbeitet und abgerufen werden. Bei konsequenter Nutzung des Werkzeugs werden
„alte Übel“ wie parallel gegeneinander entwickelte Ideen, Drehbuchentwürfe, aber auch fehlende
Medienelemente, etc. wirkungsvoll vermieden. Überarbeitungsmechanismen gewähren eine bessere
Kontrolle über die verschiedenen Erstellungsschritte.
Damit einhergehend sollten umfangreiche und effiziente Archivierungs- und WiederverwertbarkeitsMechanismen für einmal produzierte Medienelemente eingeführt werden, um auch auf dieser Ebene
die Effizienz zu steigern.
ZEITERSPARNIS
Bei im allgemeinen eng gepackten Projektplänen spielt der Zeitfaktor eine wichtige Rolle. Hier kann
ein integriertes System entscheidende Vorteile bringen, da das Programmgerüst größtenteils automatisch aus dem Drehbuch generiert werden kann. Ebenso kann es lästigen Verwaltungsaufwand wie
das Erstellen von Produktionsplänen etc. größtenteils automatisieren.
4.3.2.
Die Ausgangssituation
Das Ausgangsmaterial des Produktionsprozesses – Ideen und Ziele – ist das Ergebnis von kreativen
Brainstorming-Aktionen. Ideen und Ziele bleiben während der gesamten ersten Phase eines Konzeptionsprozesses dynamisch veränderbar und werden immer weiter ausgearbeitet.
Zur Unterstützung und Förderung derartiger Kreativprozesse bieten sich beispielsweise vernetzte
Strukturen an (vgl. Kapitel 2.3.2 und 6.1.3), die unterschiedliche Ideenfragmente, Gedanken und
auch zunächst als nebensächlich Betrachtetes aufnehmen und miteinander verknüpfen können. Derartige Techniken werden auch „Mindmapping“ genannt. Sie basieren auf konstruktivistischen Prinzipien (semantische Netze) und sind deshalb sehr gut für kreative Brainstorming-Prozesse geeignet [vgl.
Schulmeister, 1996[15], S.236], wie sie in der ersten Phase einer Multimedia-Produktion erforderlich
sind [Kleeberger/Eisenhauer, 1996[39], S.33f].
Die netzartige Mindmap mit ihren Vertiefungen und Ausarbeitungen wird zentrales Element des hier
dargestellten integrierten Produktionsprozesses werden.
Seite 49
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.3.3.
Integriere!
Es besteht nun die Aufgabe, einen Weg zu finden, wie die einzelnen Elemente Mindmap, Drehbuch
und Endprodukt unter Berücksichtigung der genannten Ziele miteinander verschmolzen werden
können.
Dafür bietet es sich an, die konventionelle Denkweise „aus der Idee folgt das Drehbuch, aus dem
Drehbuch das Programm“ umzustoßen und diese Elemente als Einheit zu betrachten. Anders gesagt:
Ein Lernprogramm ist letztlich nur ein Drehbuch, das (mehr oder weniger) quellengetreu auf den
Computer umgesetzt wurde. Programm und Drehbuch sind also zwei unterschiedliche Ansichten der
selben Sache. Sie unterscheiden sich beispielsweise in der Detaillierung: Das Drehbuch verwendet
eine Umschreibung für die endgültige Grafik im Programm. Ebenso kann das Drehbuch als eine evolutionäre Weiterentwicklung der Idee angesehen werden.
Wie diese Ansichten in ein äquivalentes System integriert werden können, will ich in diesem Unterkapitel diskutieren.
MINDMAP, ...
Die Mindmap ist das Herz des Systems. Aus ihr folgen Exposé, Treatment, Drehbuch und somit letztlich auch das Endprodukt.
Technisch gesehen ist eine Mindmap nichts anderes als eine hypermediale Netzstruktur aus Knoten
und deren Verknüpfungen untereinander (vgl. Abschnitt 6, „Knoten, Links, Netze“), die mit einer
schnellen und ausgeklügelten Benutzerführung ausgestattet werden muß, um den Benutzern eine
möglichst effiziente Bearbeitung zu ermöglichen.
Die Mindmap soll eine (dreidimensionale) Tiefenstruktur besitzen, die die inhaltliche Vertiefungen
bis hin zum Drehbuch auch grafisch ausdrückt. Gleichzeitig sollten inhaltliche Knoten von zielgerichteten unterscheidbar sein.
Eine ausführliche Darstellung und Weiterentwicklung der Mindmap-Technik zu einem mächtigen
Konzeptionswerkzeug findet sich in Kapitel 4.5.
..., ANDERE DOKUMENTE, ...
Der Integrationsgedanke legt nahe, daß alle anderen Dokumente wie Treatment oder Drehbuch aus
der Mindmap folgen. Entsprechende Gedankenstrukturen müssen also „per Mausklick“ in die entsprechenden Dokumente übernommen werden können. Ebenso müssen entsprechende Änderungen im Dokument auf die Mindmap zurückübertragen werden können.
Der Integrationsgedanke legt ebenfalls nahe, daß alle Dokumente wie Exposé, Treatment und Drehbuch zumindest intern ebenfalls Netzstrukturen aufweisen – auch wenn der Autor nichts davon bemerken sollte13. Diese Knoten/Link-Struktur bietet sich insbesondere im Zusammenhang mit der automatischen Generierung des Programmgerüstes an: Wenn eine Grafik bereits im Drehbuch als Knoten (bzw. entsprechendes Datenobjekt) angelegt ist, müssen dem Objekt bei der eigentlichen Programmierung nur noch die entsprechenden Attribute wie Grafikposition oder Grafikdaten zugewiesen werden. Ebenso bei interaktiven Verzweigungen: Werden diese bereits auf Drehbuchebene als
Verknüpfungen zwischen zwei Knoten definiert, kann diese Verknüpfung später automatisch in eine
13
Dem Autor sollte die gewohnte Arbeitsumgebung geboten werden. Siehe auch Kapitel 4.6.
Seite 50
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
entsprechende Programmstruktur überführt werden. Ebenso können bereits auf Drehbuchebene „offene“ Links aufgespürt werden.
..., DAS ENDPRODUKT ...
Wie bereits erwähnt, kann durch die konsequente interne Repräsentation aller Produktionsschritte
und -dokumente als Netz von Knoten und Kanten eine automatische und vor allem „sichere“ Generierung zumindest des Programmgerüstes gewährleistet werden.
Ebenso ergeben sich Rückschlüsse von der Programmproduktionsphase auf die davorliegenden Phasen: Durch die automatische Generierung ergibt sich die Einschränklung, daß bei der Konzeption nur
Elemente verwendet werden können, die auch tatsächlich realisiert werden können. Anders formuliert: Ist kein Knotentyp „Grafik“ definiert, können auch keine Grafiken konzipiert werden. Dies wiederum legt die Forderung nach einfacher Erweiterung des ganzen Systems nahe: Dringend für die
Konzeption benötigte, noch nicht integrierte Elemente müssen einfach und problemlos einzubinden
sein.
.. UND ALLES ZUSAMMEN!
Faßt man die gewonnenen Erkenntnisse zusammen, ergibt sich folgendes Bild eines Systemaufbaus:
dreidimensionale Mindmap
Programm/Rezeption
Drehbuch
Szene
Visuelles
Audio
Texte
A1
Grafik: Hupendes
Auto (VW Golf)
Hupton
Ich bin ein
VW Golf
...
...
...
...
Ich bin ein
VW Golf
Datenstruktur
Szene
Bezeichnung
Objektliste
Grafik
Bezeichnung
Beschreibung
Eigenschaften
Daten
Sound
Bezeichnung
Beschreibung
Eigenschaften
Daten
Programmlogik
& -aufbereitung
Text
Bezeichnung
Beschreibung
Eigenschaften
Daten
Man sieht deutlich, daß sämtliche Phasen einer Multimedia-Produktion als ein einziger, integrierter
Prozeß implementiert werden können. Die zugrundeliegenden Datenstrukturen können in allen Phasen der produktion und Rezeption verwendet werden. Auf die hier vorgestellte Art und Weise kann
also eine Produktions- und Lernumgebung mit einem einzigen System integriert werden.
4.3.4.
Von der Struktur zum Programm
In Hinblick auf die Drehbucherstellung und das Prototyping ist es wichtig, daß die „semantische“
Struktur eines Programmes von der realen Daten-Repräsentation unabhängig bleibt. Konkret: Bei der
Drehbucherstellung muß ein Button erstellt werden können, ohne daß diesem bereits konkrete Attribute (also seine Position auf dem Bildschirm oder die Grafikdaten an sich) zugewiesen werden müsSeite 51
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
sen. Die realen Eigenschaften – also beispielsweise die verschiedenen Ausgestaltungsstufen einer Grafik von ihrer textuellen Umschreibung über eine Skizze zur ausgearbeiteten Endfassung – werden
während des Produktionsprozesses nach und nach zugewiesen.
Dieses Verhalten bietet ebenso Vorteile für das Protoyping: Noch nicht erstellte Medienelemente
können einfach und vor allem automatisch durch „Dummies“ ersetzt werden. Die Navigationsstruktur eines Programmes kann über solche Navigationsdummies bereits im Drehbuch festgelegt werden,
ohne daß dafür bereits konkret ausgestaltete Buttons vorliegen müssen.
4.3.5.
Das Rad neu erfinden?
Bis jetzt habe ich den Integrationsaspekt auf einer systemimmanenten Ebene diskutiert. Es gibt aber
handfeste Vorteile einer „externen Integration“, die nicht vernachlässigt werden sollten: In der Medienproduktions-Phase fallen Digitalisierungs- und Nachbearbeitungsarbeiten an. Ebenso müssen
Texte erstellt und verarbeitet werden (beispielsweise für das Drehbuch).
Hierfür können sicherlich eigene Module entwickelt werden. Doch wozu das Rad neu erfinden,
wenn zahlreiche sehr gute, funktionierende Standardapplikationen exisitieren? Und dank objektorientierten Verbundsystemen wie Microsofts OLE lassen sich diese Standardanwendungen auch problemlos in eigene Anwendungen integrieren!
Die hier verwendete Darstellung der OLE-Technologie stützt sich auf eine entsprechende Einführung
in Petzold/Yao (1996[46], S.1103ff).
OLE – EINE KURZDEFINITION
„Hinter dem Begriff OLE verbirgt sich eine Reihe von Spezifikationen zum Erstellen von Softwarekomponenten, die untereinander Verbindung aufnehmen können.“ (Petzold/Yao, 1996[46], S.1103) OLE
ermöglicht es also, Anwendungen von Drittanbietern über eine standardisierte Schnittstelle in eigene
Anwendungen einzubinden.
Im Zusammenhang mit dieser Arbeit interessant sind insbesondere Verbunddokumente – dies sind
Dokumente, die Daten unterschiedlicher Programme enthalten können. Eine Anwendung stellt die
Basis in Form eines umgebenden, sogenannten „compound document containers“ zur Verfügung.
Dieses Verbunddokument kann nun Inhalte von beliebigen anderen, OLE-kompatiblen Anwendungen in Form von „embedded objects“ aufnehmen. Seit OLE 2 können die eingebetteten Datenobjekte direkt im Verbunddokument editiert werden. Da weitergehende Aspekte den Rahmen dieser Arbeit sprengen würden, möchte ich an dieser Stelle auf Petzold/Yao (1996[46], S.1103ff) verweisen.
OLE – DIE NACHTEILE
Für das Abspielen der Lernprogramme sollten aus Lizenzgründen keine Programm-Module von Drittanbietern eingebunden werden – von gewollten Ausnahmen14 einmal abgesehen. Darüber hinaus
geht mit der Einbindung von Anwendungen als OLE-Servern die Plattformunabhängigkeit verloren.
Andere Systeme bieten andere Mechanismen, in Java ist beispielsweise die plattformunabhängige
CORBA-Architektur integriert. Leider fehlen für CORBA (noch) die entsprechenden Standardanwen-
14
Eine „gewollte Ausnahme“ wäre zum Beispiel eine Lernanwendung, die gleichzeitig eine Art Dokument-Verwaltung realisiert. In diesem Falle
kann selbstverständlich eine Textverarbeitung als OLE-Objekt in eine Lernanwendung integriert werden.
Seite 52
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
dungen. Außerdem noch als OLE-Nachteil zu werten: Die sehr komplizierte Einbindung von OLEFunktionalitäten in eigene Programme!
OLE – DAS FAZIT
OLE kann trotz der genannten Nachteile das leisten, was für einen integrativen Systementwurf zur Erstellung und Nachbearbeitung von digitalen Medien unter Einbeziehung von DrittherstellerAnwendungen notwendig ist.
4.4.
„PROGRAMMIERUNG RUFT GRAFIK ...“
Die Rolle von Teamwork und Feedback in der Produktion
Ein wichtiger Aspekt in größeren Projekten aller Art ist die Zusammenarbeit verschiedener Personen
zum Erreichen eines gemeinsamen Ziels. Neben der üblichen Projektmanagement-Problemen – die
ich in dieser Arbeit bewußt ausklammern möchte – stellt sich die Frage, wie das multimediale Konzeptionieren und Produzieren in einem solchen Team von einer integrierten Produktionsumgebung
unterstützt werden kann.
Der hier vorgestellte Systementwurf soll folgende Prozesse des teamorientierten Arbeitens unterstützen und soweit möglich fördern:
Kreative Synergien – also das gemeinsame Arbeiten im kreativen Prozeß
Fachliche Zusammenarbeit – z.B. bei der Recherche
Überarbeitungsmechanismen
Diese Punkte werde ich zum Abschluß dieses Unterkapitels zu einem Fazit verdichten.
4.4.1.
Kreative Synergien
Kreative Synergieeffekte ergeben sich zunächst aus der direkten Kommunikation zweier Menschen
miteinander: Person A gibt Person B durch Bemerkungen, Anmerkungen oder sein Verhalten Denkanstöße, die A weiterentwickelt. Diese Weiterentwicklung kann dann wiederum Person B zu einer
Weiterentwicklung anregen, usw.
Derartige Synergieen können mit der in Kapitel 4.3.2 eingeführten Mindmapping-Methode genutzt
werden – verschiedene Autoren können ihre eigenen Gedanken in das bestehende Netz einfügen
und somit Synergieeffekte bei anderen Autoren erzeugen. Hierzu ist prinzipiell möglich, komplett
neue Gedanken einzubringen, bestehende Gedankenfragmente eines Dritten zu kommentieren (überarbeiten) oder eigene Gedanken mit denen anderer in Verbindung zu bringen (verknüpfen).
4.4.2.
Fachliche Zusammenarbeit
Prinzipiell ähnelt dieser Aspekt dem Punkt „Kreative Synergien“. Allerdings liegt der Schwerpunkt
hier weniger darauf, kreative Prozesse durch Teamwork zu fördern, sondern eine eher parallele Arbeitsweise beim Recherchieren von Fakten zu unterstützen: Mehere Recherchierende müssen
gleichzeitig an der Faktenbasis eines Lernmoduls arbeiten können. Die Autoren andererseits müssen
Seite 53
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Anfragen stellen können, wenn sie detaillierte Informationen zu einem bestimmten Thema benötigen, um im Konzeptionsprozeß weiterzukommen.
Anders als bei der Nutzung von kreativen Synergieeffekten spielen bei der Erstellung der Faktenbasis
auch (redaktionelle) Überarbeitungsmechanismen eine sehr wichtige Rolle – es sei noch einmal auf
die Bedeutung der redaktionellen Nachbearbeitung im Hinblick auf die Fehlerfreiheit der durch ein
Lernmodul vermittelten Inhalte hingewiesen!
4.4.3.
Überarbeitungsmechansimen
Wie bereits in der einführenden Analyse eines Multimedia-Produktionsprozeß erwähnt, dienen redaktionelle Überarbeitungsmechanismen in erster Linie dem Ziel einer höheren Qualität: Die Inhalte
und Strukturen einer Anwendung werden von einer (hoffentlich) kompetenten dritten Instanz auf
Fehler überprüft. Dies entspricht der Funktion eines Schlußredakteuers in Printmedien.
Die redaktionelle Arbeit erfordert entsprechende Unterstützung im Produktionsprozeß: Oftmals gehen die Verbesserungsvorschläge im hektischen Konzeptions- und Produktionsalltag einfach unter,
werden verlegt oder vergessen.
Auch hier drängen sich die Möglichkeiten eines integrierten Systems geradezu auf: Werden die Verbesserungsvorschläge direkt an die entsprechenden Stellen in der Mindmap oder des Drehbuchs
„geklebt“, können sie nicht mehr übersehen werden oder verloren gehen. Ebenso können einfach
Übersichten noch zu verbessernder Elemente generiert werden (die beliebten „To-Do-Listen“).
Ein Beispiel für recht ausgeklügelte Überarbeitungsmechanismen findet sich beispielsweise im Textverarbeitungsprogramm „Word 97“ von Microsoft.
4.4.4.
Fazit
Zusammenfassend möchte die teamorientierten bzw. redaktionellen Prozesse, die von dem in dieser
Arbeit skizzierten System unterstützt werden sollen, in zwei Rubriken fassen:
Bearbeitungsfunktionen, die neue Ideen oder Fakten hinzufügen, das parallele Erstellen von Inhalts- und Faktennetzen ermöglichen oder neue Gesichtspunkte durch das Stellen von Fragen
aufwerfen, etc.
Überarbeitungsfunktionalitäten, die bestehende Inhalte hinterfragen, kommentieren oder als
fehlerhaft markieren können.
Es hat sich ebenfalls gezeigt, daß diese Punkte in den einzelnen Prozessen der Teamarbeit unterschiedlich repräsentiert sind: Kreative Prozesse setzen starke Bearbeitungsfunktionen, redaktionelle
Arbeit eher Überarbeitungsmöglichkeiten voraus.
Aus technischer Sicht ähneln sich die Überlegungen zu beiden Aspekten: Es sind prinzipiell zusätzliche Informationen in den Konzeptionsprozeß zu integrieren. Diese zusätzlichen Informationen müssen deutlich nach ihrer Bedeutung innerhalb des Produktionsprozesses gekennzeichnet werden, so
daß auf einen Blick die Relevanz eines Überarbeitungsvorschlages oder die Herkunft eines zusätzlichen Gedankens ersichtlich wird. Ebenso sollen verschiedene semantische Bedeutungen realisierbar
sein – also ob es sich beispielsweise um einen konzeptionellen Verbesserungsvorschlag oder eine faktische Fehlerkorrektur handelt.
Seite 54
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Die Bearbeitung erfolgt durch das Hinzufügen neuer Elemente zum bestehenden Informationspool.
Die Überarbeitung setzt an vorhandenen Elementen an und erweitert diese um zusätzliche Informationen.
Aus dem gezogenen Fazit folgert auch, daß es eine Instanz im Produktionsprozeß geben muß, die
Überarbeitungsvorschläge ablehnen oder annehmen kann. Dies kann, muß aber nicht der Autor
sein. Dieser Person verbleibt also die letzte Entscheidung, welche Ideen weiterverfolgt und welche
Verbesserungen integriert werden.
4.5.
IDEEN & ZIELE – DIE MINDMAP
Schritte der mediendidaktischen Konzeption
Die Mindmap ist die Grundstruktur des gesamten Produktionsprozesses. Sie erfaßt Ideen und Ziele
des Lernprogrammes und dient als Instrument zur Weiterentwicklung bis hin zum Drehbuch.
In diesem Unterkapitel will ich die Begründung für die Wahl dieser konstruktivistischen Technik vertiefen und eine entsprechende Einordnung in den Kontext des zu entstehenden Systems vornehmen.
4.5.1.
Zieldefinition
Am Anfang steht wie üblich eine Definition der Ziele, die bei der Entscheidung für ein adäquates
Konzeptionsinstrument entscheidend sind:
Kreative Prozesse sollen unterstützt und – soweit möglich – gefördert werden.
Es soll ein möglichst einfach zu bedienendes Werkzeug entstehen, das trotzdem die notwendige
Flexibilität bieten kann.
Die Ergebnisse sollen in den Produktionsprozeß eingebunden werden können (Integrationsaspekt)
4.5.2.
Mindmap – Eine Definition
Unter Mindmapping versteht man die Unterstützung des Denkprozesses durch die Visualisierung von
Gedanken. Die Methode geht auf Tony Buzan (1974[34]) zurück und macht sich die biologische Tatsache zunutze, daß das menschliche Gehirn aus zwei Hälften mit unterschiedlichen Funktionalitäten
besteht. Die linke Hälfte ist normalerweise für rationales und analytisches Denken, für Logik, Sprache
und Zahlen zuständig. Der rechte Teil hingegen kann als „kreative Hälfte“ angesehen werden – er
steuert Raumwahrnehmung, Phantasie, Farbwahrnehmung, Mustererkennung usw. Mindmapping
nutzt beide Hirnhälften, indem es textuelle Gedanken grafisch anreichert und ordnet.
Didaktische Grundlage des „Lernens“ oder „Kreativseins“ mit Hilfe von Mindmapping-Prozessen ist
der Konstruktivismus – Mindmaps fördern die Konstruktion von neuen Ideen durch Assoziationen
und Strukturen. Die größten Vorteile15 des Mindmapping sind die Konzentration auf zentrale Punkte,
die problemlose und kreative Einbindung neuer Informationen und Ideen in vorhandene Strukturen
und das Ansprechen sowohl der „kreativen“ als auch der „analytischen“ Gehirnhälfte.
15
Die Vorteile der Mindmap-Technik sind zitiert nach Levine, 1996[40].
Seite 55
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Um eine Mindmap zur Lösung eines Problemes verwenden zu können, sollte sie allerdings nach ihrer
Fertigstellung einer kritischen Analyse unterzogen werden: Aus der von Natur aus unstrukturiertkreative Mindmap müssen strukturierte, ergebnis- und zielorientierte Schlüsse gezogen werden.
FORM & FARBE
Damit sich der geneigte Leser einen Eindruck darüber verschaffen kann, wie „sowas“ aussieht, seien
hier zwei Beispiele für „klassische“ Mindmaps gegeben [Quelle: Levine, 1996[40]]:
Die Form einer konventionellen Mindmap ist dadurch bestimmt, daß das zentrale Objekt, der zentrale Gedanke (im Falle einer Konzeption also beispielsweise die Grundidee oder das Hauptziel) möglichst in einer visualisierten Repräsentation in die „Mitte“ des (virtuellen) Blattes Papier gesetzt wird.
Für jeden vertiefenden Gedanken oder Unterpunkt wird eine Linie gezeichnet. Auf diese Linien
werden Schlüsselworte16 zu den einzelnen Teilideen/Unterpunkten etc. geschrieben. Jede Linie kann
ihrerseits wieder Startpunkt neuer Linien sein.
Bei der Generierung einer klassischen Mindmap spielen grafische Darstellungen und Farben eine
große Rolle: Farben erhöhen die Übersichtlichkeit; grafische Darstellungen erleichtern die Erfassung
des Inhaltes und fördern die „kreative“ Hirnhälfte.
4.5.3.
Erweiterung, Abstraktion & Vertiefungsmöglichkeiten
Problem: Die Mindmap in der von Buzan skizzierten Form ist ein Instrument des kreativen Brainstormings. Innerhalb eines multimedialen Konzeptionsprozesses müssen die Gedanken des Brainstormings aber weiter vertieft und vor allem strukturiert werden können. Aus diesem Grunde muß
das Mindmap-Konzept erweitert werden: Aus Schlagwörtern sollen ausformulierte Ideen und Ziele
entstehen, die bis zur Drehbuchreife weiterentwickelt werden können.
Grundidee: Statt einer einfachen Mindmap soll eine dreidimensionale Netzstruktur verwendet werden. Der Raum soll als Metapher für die Vertiefung und Ausdetaillierung von Ideen und Zielen dienen, in dem die unstrukturierten Ideen und Gedanken des Brainstorming-Prozesses in einer zweiten
Phase strukturiert werden. Aus Ideenfragmenten müssen konkrete Konzeptionsbausteine entstehen.
Auch diese müssen im „Konzeptionsraum“ immer weiter strukturiert und ausdetailliert werden können, bis am Ende das Drehbuch entstanden ist.
Beim Thema „Mindmap“ bietet es sich natürlich an, dieses Instrument auch zur Darstellung des
Brainstorming-Prozesses zu verwenden, der zur in dieser Arbeit propagierten Lösung des oben be-
16
Es ist in diesem Zusammenhang wichtig, daß wirklich Stichworte – und keine vollständigen Sätze – verwendet werden, da Stichworte besser
zum Assoziieren geeignet sind als Satzkonstrukte, die zu viel unnütze Information enthalten.
Seite 56
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
schriebenen Problems geführt hat. Im Folgenden deshalb eine in Ziele und Ideen aufgeteilte, bereits
vorstrukturierte Mindmap.
Konzeptionstool schaffen
Brainstorming
das die Entwicklung einer Idee
kreatives, effizientes Arbeiten
unstrukturierte Inhalte
zunehmende Strukturierung
Ziele
Fakten
neue Ideen
neue Aspekte einordnen
Beziehungen von Ideen
Recherche
redaktionelle Bearbeitung
zunehmende Ausdetaillierung
Drehbuchstruktur
Medienobjekte
Abbildung auf den Bildschirm
Dreidimensionale Mindmap
Navigationskonzept
Farbsystem
semantische Unterschiede
Brainstorming
Ideen & Ziele
vorgegebene Bedeutung von Ebenen
Infonetz
Konsolidierung
Drehbuch
Idee
Hyperlinks
Medienobjekte
Strukturobjekte
Querverweise
strukturelle Verweise
Gruppieren von Gedanken
Verweise von Gedanken zueinander
strukturierte Mindmaps
erste Ebene
unstrukturierter Inhalte
klassische Mindmap
semantische Verweise auf darunterliegende Ebenen
Fazit: Die oberste Ebene der dreidimensionalen Mindmap ist also die klassische Mindmap des initialisierenden Brainstorming-Prozesses. Die zweite Ebene ist eine erste Strukturierungsebene; in ihr können Ideen und Gedanken der Mindmap zusammengefaßt (strukturiert) werden. Diese Ebene hat also
die Aufgabe, Ordnung ins Chaos der kreativen Gedanken eines Brainstormingprozesses zu bringen.
Erst auf dieser Ebene erfolgt eine mehr oder weniger endgültige Festlegung auf eine Grundidee und
die Definition der Ziele. Weitere Ebenen dienen der weiteren Strukturierung der Konzeption.
Die weiteren Ebenen dienen der weiteren Ausdetaillierung hin zum Drehbuch. Die Bedeutungen der
einzelnen Ebenen sind im folgenden Unterkapitel aufgeführt.
4.5.4.
Ebenen der Konzeption
Wie aus der Mindmap des vorhergehenden Unterkapitels ersichtlich ist, basiert das hier diskutierte
Konzeptionsmodell auf verschiedenen Ebenen, denen eine feste Bedeutung innerhalb des Konzeptionsprozesses zugeordnet ist und die durch das dreidimensionale Modell repräsentiert werden.
Es muß nun eine Beschreibung dieser Ebenen erfolgen. Die Bedeutung der Ebenen hat sich am Ziel
zu orientieren, daß sich die Mindmap zur Grundlage des Drehbuches entwickeln soll.
Die in dieser Ausarbeitung gewählten Ebenen basieren auf den in Kapitel 4.2.1 und 4.2.2 beschriebenen Produktionsvorgängen sowie dem immer wieder erwähnten Prinzip der zunehmenden Detaillierung.
Seite 57
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Ebene 1: BRAINSTORMING
Unstrukturiertes Netz zur Ideen- und Zielfindung.
Ebene 2: IDEE + ZIELE
Definiert die Grundzüge des Lernmoduls. Kann zur Zielkontrolle herangezogen werden. „Fazit“ der Brainstormingebene. Grundlage für Exposé und Treatment.
Ebene 3: GEDANKENFRAGMENTE
Brainstormingartige Gedanken und Ideen zur konkreten Realisierung. Sozusagen das „Brainstorming“ zum
Drehbuch und zu den gestalterischen Konzepten in Form einer oder mehrerer Mindmaps zu den unterschiedlichen Themenkreisen. Kann als „Ideenpool“ für die nachfolgenden Ebenen aufgefaßt werden, aus dem nach
Herzenslust gefischt werden darf.
Ebene 4: RAHMENSTRUKTUR
Auf dieser Ebene werden die inhaltlichen Grundstrukturen des Lernmoduls festgelegt: Kapitelstruktur, Rahmenhandlung(en), handelnde Personen, zu behandelnder Stoff. Die Rahmenstruktur dient als Grundlage für die
darunterliegenden Ebene – aus ihr werden die zu recherchierenden Fakten deutlich und sie definiert die Erzählstruktur (soweit vorhanden) bzw. die Lernmetapher.
Ebene 5: FAKTENNETZ
Das Faktennetz dient dazu, die durch den Recherchenprozeß gewonnen Fakten bereitzustellen. Diese Ebene
stellt praktisch die „Datenbank“ dar, aus der der Autor die sachlichen Informationen zur rezipientengerechten
Aufbereitung beziehen kann. Aufgrund dieser Trennung zwischen Fakten und Aufbereitung sind zwischen
Fakten- und Detaillierungsebene besondere Überarbeitungsmöglichkeiten in Form von Fragestellungen notwendig.
Ebene 6: DETAILLIERUNGSEBENE
Auf dieser Ebene werden Fakten und Rahmenstruktur zu Szenen zusammengeführt, ohne bereits konkret Medienelemente oder detaillierte Programmabläufe zu definieren. Die Detaillierungsebene muß als zusätzliche
Überarbeitungsmöglichkeit eine Art „Fragestellung“ in die Faktenebene erlauben, so daß gezielt zu einzelnen
unklaren Punkten in der Konzeption Recherchen angestellt werden können.
Ebene 7: DREHBUCH
Auf Drehbuchebene werden abschließend noch konkrete Medienelemente definiert, Texte geschrieben und
der (interaktive) Programmablauf festgelegt.
Sämtliche Ebenen sind „durchlässig“, d.h. es sind Verweise auf Gedanken anderer Ebenen möglich.
Inhalte anderer Ebenen sind auch direkt einbindbar, was die Forderung nach einer entsprechenden
Konsistenzsicherung nach sich zieht – schließlich sollten direkt eingebundene Inhalte auch im Ursprungsort bzw. an allen referenzierten Stellen verändert werden.
Intern sind die semantischen Netze aller Ebenen als Netze und Knoten (vgl. Kaitel 6.1) aufgebaut. Allerdings bedeutet dies nicht, daß der Autor das Drehbuch auch als Netzstruktur zu sehen bekommt:
Aus Sicht des Benutzers ist vielmehr entscheidend, wie die Datenstrukturen aufbereitet werden. Und
dies wird beim Drehbuch zumindest defaultmäßig im konventionellen Fließtextschema geschehen.
Seite 58
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.6.
DAS DREHBUCH
Überlegungen zum zentralen Dokument einer Multimedia-Produktion
Im Normalfall ist das Drehbuch das zentrale Dokument eines multimedialen Lernprogrammes: In
ihm sind sämtliche Abläufe, Interaktionsmöglichkeiten und die verwendeten Medienelemente beschrieben.
Im allgemeinen ist ein konventionelles Drehbuch linear aufgebaut; interaktive Verzweigungen werden lediglich umschrieben – eine beliebte Fehlerquelle. Mit Hilfe des Computers erstellte, integrierte
Drehbücher können Lösungsmöglichkeiten hierfür anbieten, indem sie derartige Verknüpfungen automatisch überprüfen und auf entsprechende „Löcher“ hinweisen.
Ich will mich in diesem Kapitel mit dem Aufbau eines konventionellen Drehbuches beschäftigen und
die gewonnenen Erkenntnisse dann in das zuvor diskutierte Mindmap-Prinzip einbeziehen.
4.6.1.
Schreiben wie im Film?
Der Begriff „Drehbuch“ stammt aus der Filmbranche. Die für Filme verwendeten StoryboardStrukturen werden oft für Multimedia-Produktionen übernommen und um die zusätzlich benötigten
Ausdrucksmöglichkeiten (beispielsweise Hilfskonstrukte für Interaktionen) erweitert.
Prinzipiell gibt es keine festgelegten Vorgaben für die Erstellung eines Drehbuchs. Auch hierfür ist
einmal mehr die Kreativität und Vorliebe des Drehbuchautors entscheidend. Dennoch müssen zumindest zwei Grundregeln beachtet werden:
Vollständigkeit – es dürfen keine Sequenzen oder Szenen fehlen. Spontane Änderungen sind
zwar möglich, müssen aber später im Drehbuch „nachgeführt“ werden. Zu einem vollständigen
Drehbuch gehören laut Kleeberger/Eisenhauer (1996[39], S.37) die folgenden Aspekte: sämtliche
Module, Elemente, interaktiven Verknüpfungen, Möglichkeiten, Vorkommnisse, Funktionalitäten,
sowie die Beschreibung von Navigations-, Interaktions- und Designkonzept.
Verständlichkeit – alle an der Realisierung des Drehbuchs Beteiligten müssen unmißverständlich
begreifen können, was mit Regieanweisungen, Kameraeinstellungen, etc. gemeint ist. Es sollte eine „allgemeinverständliche“ Sprache gefunden werden.
Für den beispielhaften Aufbau eines Drehbuchs sei wiederum auf Kleeberger/Eisenhauer (S.38) verwiesen. Im Folgenden möchte ich die beiden verbreitetsten Ansätze des „Schreibens für den Film“
kurz vorstellen.
TEXTORIENTIERTES STORYBOARDING
Textorientiertes Storyboarding umschreibt visuelle Elemente mit Worten. Für den Grafiker bedeutet
dies einen größeren Spielraum bei der Ausgestaltung der einzelnen Medienelemente während der
Medienproduktion. Dies ist insbesondere dann von Bedeutung, wenn der Konzeptioner keine Grafikkompetenz besitzt und der Grafiker in einem solchen Falle an ein unpassendes Korsett gebunden
wäre. Andererseits erfordert ein textorientiertes Drehbuch ein größeres visuelles Vorstellungsvermögen bei allen an der Produktion beteiligten Personen.
Seite 59
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
GRAFISCHES STORYBOARDING
Beim grafischen Storyboarding werden die Szenen bereits skizzenhaft visualisiert. Dieses Vorgehen
ermöglicht es, daß sich alle an der Produktion beteiligten Personen ein genaues Bild davon machen
können, wie das Ergebnis ihrer Arbeit am Ende aussehen soll.
Wie bereits erwähnt, sollte bei einem grafischen Storyboarding unbedingt ein professioneller Grafiker
hinzugezogen werden, um Qualitätseinbußen im Endprodukt zu vermeiden. Ein weiterer Nachteil ist
der Kostenfaktor, wenn für jede Szene eine eigene Skizze erstellt werden muß.
MISCHFORMEN & WEITERENTWICKLUNGEN
In der Praxis kommen am häufigsten Hybridformen zum Einsatz: Das eigentliche Drehbuch bleibt
beispielsweise textorientiert, das grafische Konzept wird allerdings visualisiert; ebenso Schlüsselszenen oder andere wichtige Elemente. Dies entspricht der im Kapitel 4.2.2 vorgenommenen Unterscheidung in Drehbuch und Designrichtlinien.
Bei einem integrierten System wie dem hier dargestellten verwischen sich die Grenzen weiter: Neben Visualisierungen können auch Geräusch-Skizzen u.ä. eingebunden werden. Aus den Skizzen im
Drehbuch können die Designrichtlinien erstellt werden, Grafiken aus den Designrichtlinien können
ins Drehbuch übernommen werden.
Drehbuch, Prototyping und Endprodukt verschmelzen einmal mehr miteinander – für’s Protoyping
kann die Skizze des Drehbuchs verwendet werden, die erst nach der endgültigen Medienproduktion
durch die korrekte Grafik ersetzt wird.
4.6.2.
Von der Mindmap zum Drehbuch
An dieser Stelle möchte ich noch auf die technischen Zusammenhänge zwischen Mindmap und
Drehbuch eingehen. Wie bereits im Kapitel 4.3.3 dargestellt, ist eine Mindmap datentechnisch nichts
weiter als eine Interpretation eines hypermedialen Netzes aus Knoten und Kanten. Ebenso kann ein
Drehbuch als stark strukturierte Ansammlung von Elementen betrachtet werden – und damit wieder
als eine hypermedial verknüpfte Ansammlung von Knoten und Kanten.
Intern ist das Überführen der einzelnen Strukturen ineinander also kein Problem. Es müssen lediglich
die entsprechenden Module geschaffen werden, um die Datenstrukturen je nach Wunsch für die
Darstellung als Mindmap respktive Drehbuch aufzubereiten. Ebenso ist die Möglichkeit denkbar, ein
Drehbuch in Form einer komplett hypermedialen Struktur zu erstellen und erst für die Medienproduktion in die papiertauglichere Form eines linearen Textes zu bringen.
4.6.3.
Look & Feel eines Drehbuchs
Das Drehbuchlayout sollte den vielseitigen Varianten entsprechend möglichst frei definiert werden
können. Denkbar sind auch neue, auf die Möglichkeiten des Computers zugeschnittene Drehbuchformen – so wäre zum Beispiel auch ein richtig interaktives Drehbuchformat denkbar. Auch hier
müssen dem Autor zumindest Hilfen in Form von Drehbuchvorlagen angeboten werden, um ein effizientes Handling zu ermöglichen.
Denkbar wären Vorlagen, die die in Kapitel 4.6.1 geschilderten Grundtypen abdecken und eine
leichte Anpassung an eigene Bedürfnisse ermöglichen.
Seite 60
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.6.4.
Designrichtlinien
Die Designrichtlinien können (bei einem grafischen Storyboard) bereits im Drehbuch integriert sein
oder als eigenständiges Dokument vorliegen, das nur die Grundzüge definiert. Auch dieses Dokument kann direkt und frei aus der dreidimensionalen Mindmap generiert und gelayoutet werden.
4.6.5.
Produktionsplanung
Die Produktionsplanung kann direkt aus den entsprechend definierten Drehbuchelementen ermittelt
werden. Ebenso können automatisch medienspezifische Drehbücher erstellt werden. Auch in diesem
Schritt können den Produzenten weitergehende Hilfen in Form von „Assistenten“, also vorgegebenen
Checklisten und Hinweisen, angeboten werden.
4.7.
VARIANTEN & ARCHIVIERUNG
Mediendidaktische & Produktionstechnische „Stars“
Dem Ziel der effizientieren Produktion dienen die Varianten-Option und Archivierungsmöglichkeiten: Einerseits müssen Spezial-Versionen (z.B. fremdsprachige Varianten oder didaktische Anpassungen an die Zielgruppe) effizient produziert werden können, andererseits sollen einmal produzierte
Medien effektiv zugreifbar bleiben.
4.7.1.
Varianten
Insbesondere im Produktionsprozeß und beim Einsatz von Anwendungen in technisch, sprachlich
oder sonstig heterogenen Umgebungen ist eine Varianten-Option sehr interessant und nützlich: Das
gleiche Objekt kann mehrere Fassungen seines Inhaltes in sich tragen.
Ob sich die enthaltenen Versionen nun inhaltlich – zum Beispiel verschiedene Sprachen – oder
technisch – Bilder mit verschiedenen Farbtiefen – unterscheiden: Dank dieser Möglichkeit der Variantenbildung lassen sich Medienobjekte flexibel und vor allem dynamisch dem jeweiligen Anwendungsort und -zweck anpassen.
Eine interessanter Synergieeffekt zwischen didaktischer Forderung und Varianten ergibt sich in Hinblick auf die individuelle Präsentation von Lernmodulen (vgl. Kapitel 3.7.1): Im Zusammenhang des
situativen Kontextes und der Benutzerverwaltung einer Lernumgebung sind hier beispielsweise auch
zielgruppenspezifische Inhalte machbar: Für einen Lehrling ist ein Text anders (z.B. einfacher und
oberflächlicher) formuliert als für einen Top-Manager. Darüber hinaus können die den unterschiedlichen Varianten eines Lernmodules zugrundeliegenden Texte, Medien und – wenn sinnvoll – auch
Programmstrukturen beibehalten und somit wiederverwendet werden. Sie können in einer Variante
aber anders angeordnet oder mit zusätzlichen Elementen angereichert werden.
Ein weiteres Einsatzgebiet von Varianten, vielleicht programmtechnisch das wichtigste überhaupt:
Die dynamische Struktur des Lernmodules. Schließlich können von verschiedenen Lerner aufgrund
verschiedener Bearbeitungsstände unterschiedliche dynamische Zustände ein und desselben Elementes auftreten: Während es bei Lerner A noch sichtbar ist, ist Lerner B zur gleichen Zeit schon weiter;
das selbe Grafikelement ist aufgrund eines zusätzlichen Mausklicks bereits wieder verborgen. Durch
die Variantenmöglichkeit wird zur Laufzeit für jeden Benutzer eine temporäre Kopie der dynamiSeite 61
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
schen Daten eines Elementes angelegt, so daß die tatsächlichen Zustände aus der Varianteninfo abhängig vvom Lerner ausgelesen wird. Varianten sind also für Mehrbenutzerbetrieb unabdingbar.
4.7.2.
Archivierung
Die Archivierung im Produktionsprozeß dient dazu, einmal produzierte Medien wiederverwertbar zu
halten und dem Produktionsteam effektiv zugreifbar zur Verfügung zu stellen.
WIEDERVERWERTBARKEIT
Grundziel einer Archivierung sollte sein, den vorhandenen Medienbestand wiederverwertbar zu gestalten. So können alle Anwendungen, die diese Mediendatenbank verwenden, auch auf die Medienobjekte anderer Anwendungen zugreifen. Der Zugriff soll dabei möglichst flexibel und modulübergreifend gestaltet werden, um die zu verwaltenden Datenmengen möglichst gering zu halten.
ZUGRIFFSMÖGLICHKEITEN
Über umfangreiche Katalog- und Suchfunktionen können Medien thematisch eingegrenzt, eingesehen, verwaltet und somit zur besseren und effizienteren Wiederverwendung zugreifbar gemacht
werden. Für die Zugreifbarkeit entscheidend ist eine möglichst effektive Gliederung und inhaltliche
Einordnung. Hierfür sind unterschiedliche Ansätze denkbar:
Zugriffsmöglichkeit
Direkter Zugriff
Themensuche
Stichwortsuche/-recherche
Volltextsuche/-recherche
Kurzbeschreibung
Menügesteuerter Zugriff auf die Medienelemente. Die Medien
können bei der Archivierung hierarchisch und nach Themen in
das bestehende Medienarchiv eingegliedert werden.
Medien können gemäß Themengebiet angewählt werden.
Suche nach den entsprechenden Stichworten, die den Medien
beim Archivieren zugewiesen werden können.
Vergleichbar mit der Stichwortsuche, nur daß hierbei sämtliche
textlich erfaßbaren Elemente der Medien in die Suche einbezogen werden.
Die geschilderten Methoden können miteinander kombiniert werden, also beispielsweise die Volltextsuche ab einem bestimmten Knotenpunkt der Kataloghierarchie.
INTEGRATION IN DIE PRODUKTION
Auch bei der Archivierung schlägt der Integrationsaspekt gnadenlos, aber äußerst positiv zu: Gerade
beim Einsatz einer Datenbank ist ein Lernmodul gleichzeitig auch Medienarchiv – es müssen den
Medienelementen lediglich die entsprechenden (systemweiten) Eigenschaften hinzugefügt werden.
4.8.
VON DER ANFORDERUNG ZU ATTRIBUTEN
Schlüsse von der Analyse des Produktionsprozesses auf das Systemkonzept
Nachdem ich den Produktionsprozeß in den vorigen Kapiteln ausführlich durchleuchtet und entsprechende Lösungsmöglichkeiten entwickelt habe, will ich nun die entsprechenden Schlüsse für das Systemkonzept ziehen, indem ich – soweit möglich – die diskutierten Anforderungen mit entsprechenden Attributen verbinde.
Seite 62
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
4.8.1.
Medienelemente
Medienelemente bilden den Grundstock der Lernmodule. Da sich dieser Abschnitt mit dem Prozeß
der Konzeption und der Produktion, nicht aber mit seiner konkreten Ausgestaltung beschäftigt, erfolgt die Definition der Medieneigenschaften erst im folgenden Abschnitt, der sich konkreter mit der
technischen Realisierung des Systems befaßt.
4.8.2.
Konzeptionselemente
Der Begriff „Konzeptionselemente“ faßt alle Daten und Module zusammen, die in direktem Zusammenhang mit konzeptionellen Aspekten stehen. Unter diesen Begriff fallen also die Elemente der
Mindmap, des Drehbuchs und die dazugehörigen Funktionen.
Prinzipiell enthalten alle Konzeptionselemente eine inhaltliche Information in Form eines Medienelementes, die dem Element seinen eigentlichen „Sinn“ gibt. Daneben müssen Hierarchie- und Verknüpfungsinformationen verwaltet werden, also wie die einzelnen Konzeptionselemente untereinander zusammenhängen. Zusätzlich müssen die in den Kapiteln 4.4.1 und 4.4.3 diskutierten Bearbeitungs- und Überarbeitungsinformationen verwaltet werden. Nicht zuletzt sollen auch alle Konzeptionselemente vom Produktionsarchiv erfaßt werden – entsprechend angepaßte Archivinformationen sind also ebenfalls zu implementieren.
Die konkrete Ausgestaltung der Konzeptionselemente muß wegen ihres integrativen Charakters im
Gesamtzusammenhang des kompletten Systems – und deshalb erst im Abschnitt „Konturen im Nebel“ – erfolgen.
4.8.3.
Aufbau der Varianten-Information
Es werden prinzipiell zwei Arten von Varianten unterschieden: permanente und temporäre Varianten. Permanente Varianten werden nur auf explizite Anforderung beispielsweise des Programmes,
des Lerners oder des Systemadministrators angelegt und gelöscht. Temporäre Varianten wiederum
werden selbständig zur Laufzeit angelegt und nach ihrer festgelegten Lebensdauer (z.B. Anfang und
Ende eines Strukturelementes) automatisch wieder gelöscht.
Die Varianteninfo selbst besteht aus einer Charakterisierung des alternativen Inhaltes, also unter
welchen Bedingungen eine Variante angewendet wird. Zusätzlich sind die alternativen Inhalte selbst
in der Varianteninfo enthalten.
Die Charakterisierung läßt sich in folgende Gruppen gliedern:
technische Charakterisierung des alternativen Inhaltes
• Vorgaben für die Darstellung (z.B. andere Seitengestaltung bei kleineren Auflösungen; Grafikvarianten für unterschiedliche Farbtiefen, ...)
• Ausstattung des Rezeptionsgerätes (z.B. kleineres Video bei schwächeren Prozessoren, Text
statt Ton bei Rechnern ohne Soundkarte, ...)
inhaltliche & didaktische Charakterisierung
• Lokalisierung (deutsche, englische, französische, japanische, ... Varianten eines Textes, einer
Grafik, eines Sounds, eines Videos, ...)
• Produktversionen (für unterschiedliche Kunden z.B. unterschiedliche Logos, branchenspezifische Inhalte, etc.)
Seite 63
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
• Anpassungen anhand des Benutzerprofils (individuelle Inhalte anhand von Zielgruppenspezifikation, individuellen Lernervorlieben, etc. – vgl. Attribute eines Lernermodells, Kapitel 5.1.4.
Auch bei der Varianten-Information ist eine Ausdetaillierung erst im Gesamtzusammenhang des Systems sinnvoll. Es sei hierfür wieder auf den Abschnitt „Knoten, Links, Netze“ verwiesen.
4.8.4.
Aufbau der Überarbeitungsinformation
Folgende Informationen sind für Überarbeitungen relevant:
Überarbeitungs-Eigenschaften
Verfasser der Überarbeitung, Datum und Uhrzeit der
Herkunft/Info
Überarbeitung, usw.
semantische Bedeutung der Überarbeitung (FehlerkorTyp
rektur, Verbesserungsvorschlag, Kommentar, etc.)
Inhalt der Überarbeitung (Text, Grafik, Sound, ...)
Inhalt
Status
4.8.5.
Statusinformation (Überarbeitung angenommen/abgelehnt/zur Diskussion gestellt/...)
Medieneigenschaften bezüglich der Medienarchivierung
Die folgende Tabelle zeigen die Eigenschaften von Medienelementen im Zusammenhang des Medienarchivs auf Produktionsebene auf.
Archivierungs-Eigenschaften
benutzerdefinierte Bezeichnung des Elementes („MeName & Info
dienname“), ausführliche textuelle Beschreibung des
Mediums, Autor, Copyright, etc.
als Auswahl aus einer erweiterbaren Menge von TheThemengebiet
mengebieten.
frei definierbar; redaktionelle Bearbeitung
Schlagwörter
Hierarchieinformation
Archivierungsattribute
4.9.
Informationen zur hierarchischen Zuordnung des
Medienelementes
Element ist in digitalisierter Form oder nur als Skizze
im Archiv enthalten; Lizenzrechte müssen hinzugekauft werden oder sind vorhanden, etc.
FAZIT
Zusammenfassendes zum Produktionsprozeß
Ich möchte die verschiedenen Erkenntnisse, die dieser Abschnitt aus Sicht des Produktionsprozesses
erbracht hat, hier noch einmal kurz zusammenfassen.
Es hat sich gezeigt, daß ein System den Produktionsprozeß durch folgende Aspekte verbessern kann:
interne Integration – ein einheitliches System für Konzeption, Produktion und Rezeption
externe Integration – Nachbearbeitung von Medien innerhalb des Systems mit Standardapplikationen
Varianten – technische und inhaltliche Variationen werden auf einfache Art und Weise verfügbar
gemacht
Archivierung – die einfache und effiziente Wiederverwendbarkeit von Medien
Seite 64
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
The Making of... – Die Erstellung eines Lernmoduls
Integration, Varianten und Archivierung können eine positive Rückwirkung auf didaktische und inhaltliche Qualität, Effizienz und die damit einhergehende Zeitersparnis einer Produktion haben.
Deshalb sollten diese Aspekte in einen Systementwurf einfließen – auch wenn sie den „Rahmen“ einer reinen Lernumgebung erweitern.
In diesem Abschnitt habe ich mich hauptsächlich mit dem Prozeß der Produktion und möglicher Unterstützung durch eine integrierte, datenbankbasierte Produktionsumgebung gewidmet. Ein besonderer Aspekt muß jetzt noch auf die konkrete Festlegung des Funktionsumfangs gelegt werden – sowohl
für die Lernumgebung, als auch für die Lernmodule: Welche Komponenten sollen unterstützt werden, welche multimedialen Möglichkeiten kann/sollte ein derartiges System unterstützen? Wie müssen entsprechende Datenstrukturen aussehen?
Auf diese Fragen werde ich im folgenden Abschnitt eingehen, bei dem die Systemanalyse in die Phase des Systementwurfs übergeht.
Seite 65
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
5.
„Konturen im Nebel“
Komponenten einer netzbasierten Lern- und Produktionsumgebung
Alle Welt spricht vom „Web“. Die Internet-Technologie scheint sich durchzusetzen – in Form des
Intranets auch in firmeninternen Netzen. Und gerade die durch die interne Vernetzung bereitgestellte Infrastruktur bietet sich an, zum Lernen „mißbraucht“ zu werden: Der „virtuelle Klassenraum“, in
dem sich bei multinationalen Konzernen Menschen aus aller Welt zu Lerngruppen zusammenschließen und zentral mit Lernprogrammen versorgt werden, scheint Wirklichkeit werden zu können. Anders ausgedrückt: Intra- und Internet ermöglichen die Mensch-zu-Mensch-Interaktion im computerbasierten Lernen und bieten im Unternehmenseinsatz zentralisiertes (und damit kosteneffizientes)
Ausbildungsmanagement.
In diesem Abschnitt soll sowohl die multimediale Funktionalität des Systems als auch Aspekte der intranetbasierten Lernumgebung beschrieben werden. Dabei werde ich die Detaillierung der Attribute
der einzelnen Lernumgebungs-Komponenten auf inhaltlicher Ebene so weit vorantreiben, daß diese
direkt in entsprechende Datenbankstrukturen umgesetzt werden können.
Wegen der hohen Integration zwischen Produktion und Einsatz der Lernmedien wird in diesem Abschnitt öfters von einer „Lern- und Produktionsumgebung“ statt nur von einer „Lernumgebung“ die
Rede sein.
5.1.
SITUATIVER KONTEXT & CO.
Komponenten einer Lern- und Produktionsumgebung
Ich möchte hier definieren, welche (inhaltlichen) Komponenten eines Lern- und Produktionssystems
ich in meinem Systementwurf berücksichtigt habe. Insbesondere möchte ich bei den beschriebenen
Komponenten Wert auf die Mensch-zu-Mensch-Kommunikation (vgl. Kapitel 3.7.5) und die Anpassung an den Benutzer (vgl. Kapitel 3.7.3) legen.
In diesem Zusammenhang scheint das Lernen in einer netzbasierten Umgebung – insbesondere bei
der Moderation durch einen fachkundigen Instruktor – nämlich recht positiv einzuschätzende Perspektiven zu eröffnen: Die eigentlichen Lerninhalte werden zwar weiterhin von der computerbasierten Interaktion getragen, allerdings können über das technische Medium auch Mensch-zu-MenschInteraktionen aufgebaut und die Problematik der starren Computerreaktion somit entschärft werden.
Die Produktionsseite bedarf ebenfalls einer genaueren Betrachtung: Für sie existiert ein erweitertes
Systemkonzept, das zwar die Kernkomponenten mit der Lernumgebung gemeinsam hat, dafür aber
über andere Erweiterungs-Module (Erstellung von Lernmodulen gegenüber Benutzerverwaltung) verfügt.
Die Einzelaspekte werden dann in den folgenden Kapitel vertieft und insbesondere in Hinblick auf
den Systementwurf konkretisiert.
Seite 66
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
5.1.1.
Definition der Komponenten
Mit der folgenden Grafik will ich einen technischen Überblick über die einzelnen Komponenten des
Systems geben, wobei die unterschiedlichen Anforderungen von Produktions- und Lernumgebung
berücksichtigt sind. Auswahl und Umfang begründen sich mit den in den Abschnitten 3 und 4 diskutuerten mediendidaktischen und produktionstechnischen Erfordernissen.
Produktionsumgebung
Lernumgebung
Konzeptionsoberfläche
Benutzermodule & -oberfläche
Produktionsmodule
Archiv
Distributionsmodule
Kommunikationsmodule
Lernmodule
Systemadministration
Systemadministration
Kernkomponenten
Datenbestand
5.1.2.
Zugriffsmechanismen
Darstellungsfunktionen
Netzwerkprotokolle
Kernkomponenten
Die Kernkomponenten sind die Grundlage des kompletten Systemes und für Produktions- und Lernumgebung identisch. Sie decken die grundsätzlichen Funktionalitäten wie Objekte anlegen, verwalten und darstellen ab. Außerdem sind die Grundfunktionen des netzwerkbasierten Arbeitens hier integriert. Die übergeordneten Module greifen ausschließlich über die Kernkomponenten auf den Datenbestand zu.
Da die Kernkomponenten hauptsächlich technische Aspekte beinhalten, werde ich mich ihnen erst
im eigentlichen Systementwurf detailliert widmen.
DATENBESTAND
Der Datenbestand enthält alle benötigten Informationen, die in der gesamten Lern- und Produktionsumgebung benötigt werden. In ihm sind also sämtliche Mediendaten, Programmablaufdaten, sowie
Benutzer- und Produktionsdaten abgelegt.
ZUGRIFFSMECHANISMEN
Die Zugriffsmechanismen verwalten den Datenbestand: Es können beliebige Objekte angelegt, bearbeitet, gelöscht, archiviert und miteinander verknüpft werden. Die Zugriffsmechanismen stellen also
die „Low-Level“-Funktionen zur Verfügung, mit denen der Datenbestand bearbeitet werden kann.
Seite 67
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
DARSTELLUNGSFUNKTIONEN
Die im Datenbestand vorgehaltenen Informationen sollen kein Selbstzweck sein – irgendwie müssen
sie rezipientengerecht aufbereitet auf den Bildschirm gebracht werden. Hierzu dienen die Darstellungsfunktionen: Sie übernehmen den Aufbau der Inhalte und verarbeiten die Interaktionen des Benutzers.
Die Darstellungsfunktionen sind also letztlich „das Herz“ des Systems. Sie sind bei den Kernkomponenten angesiedelt, weil sie sowohl für die Produktion (Prototyping, Tests) als auch für den Einsatz im
harten „Bildungsalltag“ benötigt werden.
Um ein möglichst breites Spektrum an darstellbaren Medientypen zu erreichen (beispielsweise
VRML), werden die Darstellungsfunktionen modular konzipiert, so daß auch externe Module zur
Darstellung verwendet werden können. Die Funktionalität für die multimediale Grundausstattung (also Text, Grafik, Audio und Video) wird selbstverständlich durch interne Module abgedeckt.
NETZWERKPROTOKOLLE
Sowohl Lern- als auch Produktionsumgebung machen regen Gebrauch von netzwerkorientierten
Funktionalitäten. Deshalb wird ein „Grundstock“ bereits in den Kernkomponenten zur Verfügung gestellt, der von den einzelnen übergeordneten Modulen benutzt und erweitert werden kann.
5.1.3.
Lernmodule
Die Lernmodule sind eigentlicher Träger des Lernstoffs und damit zentraler Bestandteil einer Lernumgebung. Aufgrund dieser herausragenden Stellung muß ihnen die Lernumgebung entsprechende
Bedeutung beimessen: Die Lernmodule müssen dem Lerner auf optimale Art und Weise zugreifbar
gemacht werden. Neben der üblichen, menügesteuerten Auswahl müssen zusätzliche Möglichkeiten
wie die Zusammenstellung verschiedener Module zu einem Lehrgang, die gezielte Zusammenstellung nach Stichworten usw. angeboten werden.
ATTRIBUTE EINES LERNMODULS
Folgende Eigenschaften sollen den Lernmodulen im Zusammenhang mit ihrer Integration in eine
Lernumgebung zugewiesen werden können. Sie sind im Zusammenhang mit dem Benutzerprofil (vgl.
folgendes Unterkapitel) und den im Unterkapitel „Archiv“ diskutierten Zugriffsmöglichkeiten zu sehen.
Eigenschaften eines Lernmoduls bzgl. einer Lernumgebung
Autor, Copyright, etc.
Titel & Info
Themengebiet
Hierarchieinformation
Schlagwörter
Zielgruppe
Schwierigkeitsgrad/Vorwissen
verfügbare Sprachvarianten
Querverweise
Als Auswahl aus einer vom Systemadminstrator vorgegebenen Menge
Informationen zur hierarchischen Einordnung des
Lernmoduls
frei definierbar; redaktionelle Bearbeitung
Kombination von Attributen gemäß Benutzerprofil;
vom Systemadministrator definiert
geeignete numerische Skalen, für die jeweiligen Fachgebiete getrennt – Fachgebiete vom Systemadministrator definiert
Auswahl aus einer vorgegebenen, erweiterbaren Liste
zu thematisch vergleichbaren Lernmodulen und externen Medien (vgl. Unterpunkt „Archiv“)
Seite 68
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Eigenschaften eines Lernmoduls bzgl. einer Lernumgebung
Verweis auf ein Testwerkzeug zum Thema
Verifizierungsmöglichkeit
Didaktisches Info
benötigte Resourcen
Aufbau des Lernmodules – z.B. als Spiel, Infodatenbank, etc. Kann im Zusammenhang mit den Vorlieben
des Lerners aus dem Benutzerprofil zum Zusammenstellen von Kursen verwendet werden.
Rechnerplattform, Grafikauflösungen, Bandbreite, etc.
SPEZIALFALL VERIFIZIERUNG
Neben den eigentlichen Lernmodulen, die eigentlich ausschließlich der Stoffvermittlung dienen, existieren noch Test-Module, mit deren Hilfe der (hoffentlich) gelernte Stoff durch eine Reihe von Aufgaben verifizieren werden soll. Hierfür müssen spezielle Auswertungsmechanismen zur Verfügung
gestellt werden, die dem Lerner ein entsprechendes Feedback geben. Die Sequenzierung erfolgt generell nach behavioristischen Prinzipien (also schnelle Rückmeldung; vgl. „Programmiertes Lernen“
in Kapitel 2.3.3), kann aber auf Autorenwunsch auch freier gestaltet werden. Es müssen entsprechende Programmstrukturen geschaffen werden, die eine computergerechte Auswertung überhaupt
erst ermöglichen – erwähnenswert hierbei sind Multiple-Choice-, Lückentext- und Zuordnungsaufgaben.
In diesem Zusammenhang muß beachtet werden, daß eine Lernumgebung durchaus auch für Prüfungszwecke verwendet werden kann. Neben den Tests, die der Lerner freiwillig zur eigenen Kontrolle absolviert, müssen auch „Prüfungsmodule“ mit den entsprechenden Zugriffsbeschränkungen
berücksichtigt werden.
5.1.4.
Benutzerprofile
Neben den üblichen Verwaltungsfunktionalitäten wie System-Logins etc. sollen die Benutzerprofile
auch ein möglichst präzises Abbild des Lerners erlauben. Diese Daten können von den Lernmodulen
aufgegriffen werden und entsprechend weiterverarbeitet werden („Eingehen auf den Lerner“). Auf
diese Weise sind direkt auf den Benutzer zugeschnittene Inhalte möglich – beispielsweise eine an die
Gegebenheiten des Heimatlandes des Lerners angepaßte Version des Lernprogrammes, in dem dann
statt in DM oder SFr in US-Dollar gerechnet wird. Dies ist auf Seiten des Lernmoduls ein weiterer Fall
für Varianten (vgl. Kapitel 4.7.1)
Das Benutzerprofil enthält drei Seiten: Durch den Systemadministrator zugeteilte Attribute wie Lernername, Zugriffsrechte etc. und durch den Benutzer selbst festlegbare Attribute wie persönliche
Vorlieben etc. Daneben müssen noch dynamisch veränderte Eigenschaften verarbeitet werden: Eine
Protokollierung bearbeiteter Lehrgänge und die Ergebnisse von Tests. Ebenso diverse statistische Informationen über die Sitzungen des Lerners. Und benutzergenerierte Daten wie Notizen, eigene
Lehrgänge usw.
Alle diese Daten können vom Instruktor zur Analyse des Lernverhaltens und -erfolgs verwendet werden.
ATTRIBUTE EINES LERNERMODELLS
Ich will meine Ausführungen hier in vom Systemadministrator änderbaren Parameter und benutzereditierbare Eigenschaften aufteilen. Der dritte Teil der Darstellung befaßt sich mit den dynamischen
Attributen.
Seite 69
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Eigenschaften eines Lerners (vom Administrator änderbar)
Name, Login-Name, Adresse, usw.
persönliche Daten
Zugriffsrechte
externe Charakterisierung
der Person
externe Vorgaben
Welche Aktionen darf der Benutzer durchführen? –
sehr detaillierte Abstufungen.
beispielsweise Stellung in einer Firma, Abteilung,
Zugehörigkeit zu einer (Schul-) Klasse, fachliches
Vorwissen, Lokalisierungsinfo.
vom Systemadministrator bzw. Instruktor zusammengestellte Lehrgänge, Tests, usw.
Eigenschaften eines Lerners (vom Lerner änderbar)
Paßwort.
Zugriffsschutz
interne Charakterisierung
der Person
interne Vorgaben
eigene Vorlieben, persönliche Herangehensweisen,
usw.
vom Lerner erstellte Lehrgänge, Tests, usw.
Kommunikationsprotokolle
Mails an den Tutor, an Lerngruppenmitglieder; Beiträge zu Diskussionsforen.
Dynamische Lernerattribute
Ablaufinformationen
Sitzungsprotokolle
Tooldaten
5.1.5.
bearbeitete Lernmodule, Tests, etc. mit detaillierten
Infos.
statistische Infos zu Sitzungszeitpunkt, -dauer, etc.
Notizen, Rechenergebnisse, Nachrichten, Verweise
auf selbsterstellte Module.
Betreuung & Kommunikation
Die in diesem Systementwurf integrierten Betreuungs- und Kommunikationsfunktionalitäten richten
sich nach dem Modell des verteilten, kooperativen Lernens (vgl. Kapitel 3.8). Zusätzlich wird auch
der Lernstoff über technische Medien (eben Intra- oder Internetstrukturen) transportiert; ebenso
dient „das Netz“ als Medium für die Kommunikation der Lerner und Lerngruppen via eMail, Schwarzem Brett und Chat untereinander.
5.1.6.
Archiv
Das Archivmodul stellt vielseitige Zugriffsmöglichkeiten auf Lernmodule, aber auch auf externe Medien (also beispielsweise analogen Videos oder schriftlichen Lernmaterialien) bereit. Für den zweiten
Fall ist optional eine direkte Einbindung einer digitalisierten Form (z.B. als elektronischer „Thumbnail“) des externen Mediums vorgesehen – so kann eine Art „Vorschau“-Funktionalität realisiert werden. Technisch gesehen sind externe und interne Medien gleichgesetzt – sie basieren auf den selben
Medienelementen.
Auch die Produktionsmodule stellen Archivierungsfunktionen zur Verfügung, die allerdings auf die
speziellen Bedürfnisse der Produktion zugeschnitten sind (vgl. Kapitel 4.7). Die der Archivfunktionalität zugrundeliegenden Eigenschaften sind allerdings ähnlich.
In der folgenden Tabelle sind die erwähnten „vielseitigen Zugriffsmöglichkeiten“ aufgeführt. Es sei
hierzu auch auf das Kapitel 4.7.2, das sich mit den Zugriffsmöglichkeiten auf das Produktionsarchiv
beschäftigt, verwiesen.
Seite 70
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Zugriffsmöglichkeit
Direkter Zugriff
Zusammenstellen von
individuellen Lehrgängen
Zugriff auf vorbereitete Lehrgänge
Stichwortsuche/-recherche
Volltextsuche/-recherche
Medienarchiv
5.1.7.
Kurzbeschreibung
Menügesteuerter Zugriff auf die Lernmodule. Die Lernmodule
können dazu vom Systemadministrator hierarchisch nach Themen gegliedert werden.
Der Benutzer kann sich von der Lernumgebung anhand eigener
Themenwahl und der Auswahl verschiedener Kriterien aus dem
didaktischen Info der Lernmodule individuelle Lerngänge generieren. Außerdem können äquivalente Verweise auf externe
Medienangebote abgerufen und die entsprechenden Lernmaterialien ggf. vorbestellt werden.
Es kann hierbei eine differenzierte Zusammenstellung anhand
von Zielgruppendefinition und externer sowie interner Charakterisierung des Rezipienten getroffen werden.
Der Systemadminstrator/Tutor kann für jeden Benutzer oder
Benutzergruppen Lehrgänge zusammenstellen, beispielsweise
um seinen personalen Unterricht zu ergänzen. Ebenso wäre die
Zusammenstellung von Prüfungsfragen möglich – durch das
Mitprotokollieren der Sitzungen kann der Prüfungshergang
später – manuell oder automatisch – ausgewertet werden.
Individuelle Zusammenstellung eines Lehrganges durch Eingabe
eines Stichwortes. Kann durch die Angabe zusätzlicher Kriterien
wie einem Themengebiet (vgl. Kapitel 5.1.3) genauer definiert
bzw. eingeschränkt werden.
Die Relevanz der gefundenen Lernmodule wird wiederum
nach Zielgruppendefinition und externer sowie interner Charakterisierung des Rezipienten gewichtet.
Vergleichbar mit der Stichwortsuche, nur daß hierbei sämtliche
textlich erfaßbaren Elemente der Lernmodule in die Suche
einbezogen werden.
Zugriff auf als „extern“ gekennzeichnete Medien gemäß dessen
Eigenschaften im Medienarchiv
Systemadministration
Die Systemadministration hat zwei Seiten: Einerseits erfolgen am Einsatzort die Benutzerverwaltung,
die Pflege bestehender und das Hinzufügen neuer Lernmodule. Auf Produzentenseite wiederum sind
die Aufgaben des Systemadministrators um die Freigabe und Archivierung neu erstellter Lernmodule
erweitert.
Hinsichtlich der Systemadministration muß ein Systementwurf also ein differenziertes ZugriffsrechteSystem unterstützen, das die Freiheiten der einzelnen Benutzer gemäß ihrer Rechte regelt.
Dem Systemadministrator müssen Funktionen zur Verfügung gestellt werden, um Benutzerprofile erstellen und pflegen zu können. Außerdem muß er die Kontrolle über alle Lernmodule zu jeder Zeit
behalten. Weiterhin obliegt ihm die Pflege der dem System zugrundeliegenden Datenbank – näheres
hierzu findet sich im Kapitel 7.4.9.
Die Benutzerverwaltung umfaßt Aspekte wie Benutzerprofile einrichten, löschen, bearbeiten,
Zugriffsrechte verteilen sowie Lehrgänge und Prüfungsaufgaben zusammenzustellen. Letzteres entspricht der Tätigkeit eines Tutors, so daß auch „Tutorkonten“ mit entsprechenden didaktischen
„Machtbefugnissen“ eingerichtet werden können sollten, falls technische Administration und Lernerbetreuung nicht in einer Person vereint sind.
Auf Produktionsseite muß ebenfalls eine Art „Überwachungsinstanz“ geschaffen werden, die Ideen,
Vorschläge und Überarbeitungen annehmen oder abblocken kann (vgl. Kapitel 4.4). Auch hier sollte
Seite 71
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
eine Trennung zwischen dieser Person und dem eigentlichen (technischen) Systemadministrator
möglich sein.
Ebenso müssen Mechanismen entwickelt werden, die fertig produzierten Lernmodule für die Distribution vorzubereiten. Die entsprechenden Installationsroutinen müssen einerseits sämtliche vom
Programm verwendeten Medienelemente erfassen, andererseits aber einen Abgleich zwischen eventuell bereits installierten und neu hinzuzufügenden Medien auf Zielplattform und Distributions-CD
vornehmen, damit der Wiederverwendbarkeits-/Archivierungsaspekt nicht ad absurdum geführt wird.
Aus urheberrechtlichen Gründen darf die Distributions-CD keine Informationen zur Reproduktion
des Drehbuchs enthalten. Die entsprechende Funktionalität des Distributionsmoduls entschlackt als
gewünschten Nebeneffekt zusätzlich die Größe der Distributionsdateien.
Ebenfalls im Distributionsmodul angesiedelt sind die Funktionalitäten zum Cross-Media-Publishing,
wie sie im Kapitel 7.5 beschrieben sind.
In der folgenden Übersichtsgrafiken, die den Prozeß von der Entstehung eines Lernmoduls bis zu seinem Einsatz in einer Lernumgebung unter Berücksichtigung der jeweils anfallenden Datentypen skizziert, sind die Aufgaben des Systemadministrators fett dargestellt.
Wartung/Überwachung
Benutzerdaten
Produktionssystem
Konz.-.
daten
Prg.
ablauf
Lernmodul
Medien-.
daten
Prg.
ablauf
Medien-.
daten
Distribution
5.1.8.
dynam.
Daten
Verwaltung/Wartung
Lernumgebung/
Verwaltung
Produktion
Integration
Tools
Neben den „schwergewichtigen“ Komponenten wie Benutzerverwaltung, Systemadministration und
Lernmodule sollten in einer Lernumgebung nützliche Helfer wie Notizblock und Rechner vorhanden
sein. Auch diese sollten in einen Systementwurf integriert werden.
Dabei spielt wiederum der situative Kontext eine Rolle – die jeweilige Notiz oder Anmerkung muß
mit dem entsprechenden Inhalt eines Lernmoduls verknüpft werden können. So kann sich der Lerner
seine eigene Notizen-Sammlung anlegen. Zur Verwaltung kann er diese wie in einem Karteikasten
thematisch verwalten. Optional kann er auch die „Fortgeschrittenen“-Version eines Notizblocks aufrufen – in Form eines (zweidimensional arbeitenden) Mindmap-Werkzeuges (vgl. Kapitel 4.4)...
Diese Möglichkeiten entspringen wiederum der konstruktivistischen Theorie – der Lerner faßt seine
eigenen Gedanken zu einem mehr oder weniger komplexen Wissensgebilde zusammen und kann
bei Bedarf direkt in das dazugehörige Lernmodul und damit zu den gewünschten Informationen
springen. Auch hier können problemlos Grafiken, Sounds oder Videos in die Mindmap einbezogen
werden. Dieses Werkzeug entspricht einmal mehr einer hypermedialen Struktur wie in Abschnitt 6
beschrieben.
Seite 72
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Zur Unterstützung der Kommunikationsmechanismen müssen ebenfalls entsprechende Tools eingeflochten werden, also beispielsweise ein Nachrichtenmodul für eMail und Diskussionsforum sowie
Funktionalitäten, um Real-Time-Chats realisieren zu können.
5.2.
AUTHORING-METAPHERN, MEDIENELEMENTE & CO.
Konkretes zum multimedialen Funktionsumfang
In diesem Kapitel möchte ich skizzieren, über welche multimedialen Möglichkeiten das in dieser Arbeit diskutierte System verfügen soll: Welche Medientypen können wie integriert werden? Wie sind
Programmabläufe und -logik programmierbar? Wie präsentiert sich die Programmierung dem Autoren? Wie wird die Integration von Konzeption, Produktion und Rezeption unterstützt?
5.2.1.
Klassifizierung multimedialer Entwicklungssysteme am Beispiel
Multimediale Entwicklungssysteme können anhand ihres Funktionsumfanges und der verwendeten
Metapher unterschieden werden: Der Funktionsumfang bestimmt, welche Medienelemente wie
miteinander verknüpft werden können. Außerdem beeinflußt in diesem Zusammenhang das Vorhandensein und die Mächtigkeit einer Skriptsprache die Leistungsfähigkeit eines solchen MultimediaSystems nachhaltig.
Die Metapher wiederum definiert, wie die Medienelemente verwaltet und der Programmablauf
strukturiert werden.
Ich werde eine Klassifizierung hier exemplarisch an den verbreitetsten Entwicklungsumgebungen
Macromedia Director und Asymetrix ToolBook vornehmen. Die Funktionalität (nicht aber der Funktionsumfang) dieser Werkzeuge wird die Grundlage des multimedialen Funktionsumfanges des hier
skizzierten Systems bilden: Letztlich sollen Lernmodule mit dem in dieser Diplomarbeit skizzierten
System realisiert werden können, die ähnliche Möglichkeiten wie die hier evaluierten Systeme bieten. Schließlich soll ja auch eine adäquate Präsentation der Inhalte als Motivationsfaktor möglich sein
– vgl. Kapitel 3.4.
Beiden in diesem Unterkapitel vorgestellten Systemen gemeinsam ist eine allgemeine Objektorientierung, die zwar nicht den strengen Standards genügen, die „richtige“ OOP-Sprachen wie C++ setzen, aber dennoch wichtige und vor allem praxisbezogene Objekt-Aspekte realisieren.
TOOLBOOK
ToolBook ist ein seitenorientiertes Autorensystem. Dabei ist jede Seite in Vorder- und Hintergrund
aufgeteilt. Die Multimedia-Elemente sind als grafische Objekte auf den Vorder- und Hintergründen
abgelegt. Vorder- und Hintergründe selbst sind ebenfalls Objekte. Jedem Objekt sind Eigenschaften
(properties) zugeordnet. Eigenschaften sind beispielsweise die Position eines Elementes auf dem Bildschirm, eine momentane Sichtbarkeit, usw. Zusätzlich zu diesen Standardeigenschaften können jedem Objekt auch benutzerdefinierte Eigenschaften (user-properties) zugeordnet werden.
ToolBook ist über die relativ mächtige Skriptsprache OpenScript programmierbar. Animationen und
andere zeitgesteuerte Elemente müssen im allgemeinen über OpenScript-Funktionen realisiert werden. Hier werden die Nachteile des seitenorientierten Ansatzes deutlich. Andererseits sind gerade
deswegen aber auch alle erdenklichen Arten von Animationen realisierbar.
Seite 73
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
ToolBook unterstützt die folgenden Medienelemente und Objekte:
Texte – als „Nur-Text“ und im Rich-Text-Format
Hypertexte –im Rich-Text-Format
Grafiken – im Bitmap-Format (nicht skalierbar, dafür mit Transparenz) oder in anderen, durch die
jeweiligen Importfilter vorgegebenen Formaten (skalierbar, dafür – außer im GIF89a-Format –
ohne Transparenz)
Grafikgrundelemente: Ellipsen, Kreise, Kreissegmente, Rechtecke, Polygone, Linien, Kreisbögen;
jeweils mit unterschiedlicher Rahmen- und Füllfarbe sowie Füll- bzw. Linienmuster
„Multimedia-Objekte“: Video, vorberechnete Animationen (FLI/FLC-Format) und Audio
Strukturelemente: Objekt-Gruppierungen, Seiten und Hintergründe
Windows-Standardelemente (Buttons, ComboBoxes, etc.)
Fenster – in der ToolBook-Terminologie als „viewer“ bezeichnet
DLLs – zur Funktionserweiterung
vorgefertigte CBT-Elemente – „Widgets“
Drag & Drop-Automatisierung
OLE-Objekte (seit Version 6.0)
DIRECTOR
Anders als ToolBook orientiert sich Director an einer Art virtuellem „Drehbuch“ – es handelt sich also
um ein sogenanntes timeline-basiertes System: Im Drehbuch wird festgehalten, welches Medienelement sich zu welcher Zeit an welchem Ort des Bildschirmes und (bei zeitorientierten Objekten wie
Videos oder Sounds) an welcher Abspielposition befindet.
Director ermöglicht über seine Skriptsprache Lingo ebenfalls eine Programmierung des Systems, wobei die Möglichkeiten um einiges eingeschränkter sind als bei Asymetrix‘ OpenScript.
Director unterstützt die folgenden Medienelemente und Objekte:
Texte – als „Nur-Text“ und im Rich-Text-Format
Grafiken – in verschiedensten Pixel-Formaten (skalierbar, mit verschiedenen Transparenz-Arten);
während der Programmentwicklung direkt in Director editierbar
Grafikgrundelemente: Ellipsen, Rechtecke, Linien; jeweils mit unterschiedlicher Rahmen- und
Füllfarbe sowie Füll- bzw. Linienmuster
„Multimedia-Objekte“: Video, vorberechnete Animationen (z.B. als „filmLoop“) und Audio
Drehbuch – zur „Programmierung“ des Ablaufs und der Programmlogik
Buttons – in Form von Radio-, Check- und Auswahlbuttons; das einzige GUI-Standardelement;
auch auf Windows-Rechnern im Mac-Look&Feel
XTras zur Erweiterung der Funktionalität; ähnlich wie DLLs, aber plattformunabhängig
5.2.2.
Grobstrukturierung
Aus der Untersuchung bestehender Lösungen läßt sich folgende Klassifizierung vorhandener Elemente vornehmen:
Medienelemente – die multimedialen Bestandteile eines Lernmoduls
Strukturelemente – die die Medienelemente zu Strukturen wie Objektgruppen, Seiten oder Timelines zusammenfassen
Ablaufschablonen – die Interaktionen ermöglichen und Programmablauf und -logik definieren
Seite 74
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Diese Einteilung berücksichtigt die Integration von Konzeptionselementen wie im vorherigen Abschnitt definiert noch nicht. Ich werde auf diesen Aspekt allerdings noch im Unterkapitel 5.2.10 eingehen.
5.2.3.
Metaphern & Strukturelemente
Die unterschiedlichen Multimedia-Systeme verwenden unterschiedliche Ansätze oder Metaphern für
die interne Organisation ihrer Medienelemente und Objekte:
der sehr verbreitete seitenorientierte Ansatz, bei dem die Inhalte wie in einem Buch auf „virtuellen Seiten“ angeordnet sind
dokumentorientierte Ansätze, wie sie beispielsweise bei Web-Projekten, die HTML verwenden,
üblich sind
die kartenorientierte Metapher, bei der die Inhalte auf virtuellen Karten angordnet sind
die timelineorientierte Metapher, bei der die Objekte auf einem virtuellen Zeitstrahl drehbuchartig angeordnet sind
Mischformen aller Art
Seiten-, dokument- und kartenorientierte Systeme ähneln sich strukturell – sie basieren auf einem
statischen Systemkonzept (beispielsweise Hypertexte, Präsentationen ohne dynamische Elemente).
Eine prinzipiell andere Herangehensweise hingegen stellen die timelineorientierten Systeme dar, da
sie von vorneherein auf dynamische Konzepte wie Animationenssequenzen oder Präsentationen mit
dynamischen Elementen ausgelegt sind.
FAZIT
Jede der hier vorgestellten Metaphern hat ihre eigenen Vor- und Nachteile bzw. speziellen Einsatzgebiete. Aus diesem Grunde erscheint es sinnvoll, beide in ein System zu integrieren: Statische Metaphern für statische Inhalte, dynamische Metaphern für Animationen und ähnliche zeitabhängige
Abläufe. Aus diesem Grunde sollen sowohl die seiten- als auch die timelineorientierte Metapher berücksichtigt werden.
UMSETZUNG
Zunächst erscheint es nicht gerade einfach, zwei von ihrem Wesen her unterschiedliche Metaphern
in einem System zu vereinen. Doch auf Datenebene ist dies zunächst kein Problem; sowohl zeitabhängige als auch statische Metapher sind lediglich Objekte, die ihre Daten anders interpretieren und
die Darstellungsfunktionalitäten ihrer jeweiligen Natur entsprechend unterschiedlich nutzen.
Für einen Systementwurf bedeutet dies, daß bei den Elementen, die die Metapher-Ebene darstellen,
eine Schnittstelle geschaffen werden muß, die zunächst von der verwendeten Metapher unabhängig
ist. Erst die Schnittstellenfunktionen selbst „entscheiden“, was sie mit ihren Daten anfangen. Dies bedeutet gleichzeitig auch, daß das System modular um neue Metaphern oder Varianten von Metaphern erweiterbar ist – so lange die entsprechenden Schnittstellendefinitionen eingehalten werden
können.
Die Elemente, durch die eine Metapher charakterisiert wird – also beispielsweise Seiten, Animationsgruppen oder Elementverbunde – definieren die Struktur einer Anwendung und nehmen die Medienelemente auf.
Seite 75
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
5.2.4.
Interaktionsmöglichkeiten, Programmablauf & Ereignisse
Wie die meisten anderen Multimedia-Umgebungen auch soll sich die hier diskutierte Lösung an ereignisorientierten Modellen orientieren, wie sie auch von modernen grafischen Betriebssystemen wie
Windows, OS/2, MacOS und vielen anderen verwendet werden: Je nach ihrem aktuellen Zustand
senden Elemente Botschaften oder Meldungen über vorgefallene Ereignisse an andere Elemente. So
verschickt der Mauspfeil ein Ereignis beim Überfahren eine entsprechende Meldung an das betroffene Element, ebenso beim Verlassen. Das betroffene Element kann jetzt darauf reagieren, indem es
beispielsweise sein Aussehen ändert. Bei einer Mausklick-Botschaft wiederum kann es eine entsprechende Meldung an ein übergeordnetes Strukturelement schicken, das den gesamten Seiteninhalt
verändert, beispielsweise bei einer Simulation. Ebenso wäre das Abspielen einer Animationssequenz
oder das Weiterblättern in einem buchartigen Lernmodul denkbar.
Die von dem hier diskutierten System unterstützten Ereignisse lassen sich in die folgenden Kategorieen einteilen:
einfache Mausereignisse wie das Überfahren oder Anklicken eines Elementes
Drag & Drop – das Ziehen und Loslassen von Objekten in verschiedenen Varianten
Medienereignisse wie der Beginn oder das Ende einer Wiedergabe
Zustandsänderungen wie Beginn oder Ende des Darstellens einer Grafik, Anfang oder Ende bzw.
Betreten oder Verlassen eines Strukturelementes
Im allgemeinen erfolgt auf ein Ereignis eine Reaktion des Elementes. Die konkrete Ausprägung dieses
Regelkreises bestimmt letztendlich Programmablauf und -logik. Die hier vorgestellte Ereignis-Architektur wird deshalb die Grundlage der Gestaltung von interaktiver Struktur und Ablauf der Lernmodule bilden.
EINFACHE MAUSEREIGNISSE
Diese Ereignisgruppe kann sich an den Standards grafischer Benutzeroberflächen orientieren: Standardmäßig werden das Überfahren und das Anklicken von Elementen (Links-, Rechts-, Doppelklick)
unterstützt. Ebenso können Strukturelemente auf allgemeine Ereignisse wie das bloße Verschieben
des Zeigers reagieren.
DRAG & DROP
Drag & Drop als eine der Grundtechnologieen computergestützter Interaktion muß explizit unterstützt werden. Der Autor muß auf einfache Art und Weise gängige Drag & Drop-Aktionen definieren
können:
Zuordnungen – durch Ziehen eines Objektes auf ein anderes
bewertete Zuordnungen – es können „richtige“ oder „falsche“ Zuordnungen getroffen werden
Neuzusammenstellen von Medienelementen – beispielsweise bei Spielen können verschiedene
grafische Elemente neu angeordnet werden
bewertetes Neuzusammenstellen von Medienelementen – Medienelemente müssen an eine
„korrekte“ Position gezogen werden
Drag & Drop innerhalb von GUI-Elementen – beispielsweise das Umsortieren von Listen
Drag & Drop-Ereignisse sind – technisch gesehen – die Verknüpfung mehrerer einfacher Mausereignisse mit nachfolgender Manipulation der dargestellten Grafikelementen und dem Auslösen einer
entsprechenden Meldung über das Ergebnis der Aktion.
Seite 76
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
MEDIENEREIGNISSE
Unter Medienereignissen können all jene Meldungen aufgefaßt werden, die direkt mit Medienelementen zusammenhängen: So beispielsweise der Beginn oder das Ende eines Videos oder eines Sounds, das Erreichen eines bestimmten Frames oder Samples, aber auch eine Änderung an einem
GUI-Element wie die Auswahl eines Menüpunktes.
(ALLGEMEINE) ZUSTANDSÄNDERUNGEN
Schließlich kann eine beliebige Zustandsänderung eines Elementes ganz allgemein ein Ereignis nach
sich ziehen: So kann beispielsweise innerhalb einer Animationssequenz, die über ein Strukturelement realisiert wurde, auf Anfang, Ende oder das Erreichen eines definierten Fortschrittes reagiert
werden. Ähnlich bei anderen Strukturelementen: Es kann auf das Betreten oder Verlassen einer Seite, das Beenden des Moduls u.ä. reagiert werden.
EREIGNISHIERARCHIE
Ereignisse werden hierarchisch „nach oben“ weitergeleitet, wenn ein Element ein Ereignis nicht bearbeitet: Reagiert ein Button nicht auf einen Mausklick, wird das übergeordnete Strukturelement, also beispielsweise eine Seite, über das Ereignis informiert. Reagiert auch dieses Element nicht, wird
das Ereignis solange immer noch eine Ebene in der Objekthierarchie weiter nach oben geleitet, bis
die oberste Ebene, also das Lernmodul selbst, erreicht ist.
5.2.5.
Medienelemente
Die Definition der zu unterstützenden Medienelemente orientiert sich an der zuvor vorgenommenen
Analyse der Autorensysteme ToolBook und Director. In diesem Kapitel werde ich allerdings ausschließlich auf Objekte eingehen, die „klassische“ Medien beinhalten. Komplexere Elemente werden
über externe Module realisiert und werden deshalb im entsprechenden Kapitel von Abschnitt 9 behandelt.
Folgende Medientypen sollen unterstützt werden:
Text & Hypertext – im Rich-Text-Format17, charakterisiert durch einen rechteckigen Darstellungsbereich, in dem ein automatischer Umbruch durchgeführt wird.
Bitmap-Grafiken – BMP standardmäßig; durch Filtermodule zusätzliche Formate. Die Grafiken
können über eine Maske „ausgestanzt“ werden, um auch nicht-rechteckige Grafiken realisieren
zu können. Außerdem sind Vergrößerungen und Verkleinerungen der Bildinhalte möglich.
folgende Grafikgrundelemente:
• Rechtecke
• Polygone
• Ellipsen/Kreise
GUI-Elemente – Standardelemente wie Listboxen, Combo-Boxen, Menüs
„Multimedia“-Elemente – je nachdem, welche Medientypen von „angedockten“ Darstellungsmodulen unterstützt werden (vgl. Kapitel 5.1.2). Video und Audio werden standardmäßig von
internen Modulen unterstützt.
17
Das Rich-Text-Format (RTF) ist ein von Microsoft eingeführtes Standard-Textformat, das von allen gängigen Textverarbeitungsprogrammen
verarbeitet werden kann. Mit RTF kann neben den eigentlichen Textinformationen auch die Formatierung des Textes festgelegt werden. Eine
sehr ausführliche Formatdefinition findet sich im Web beispielsweise unter der Adresse ftp://ftp.primate.wisc.edu/pub/RTF/.
Seite 77
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
KAPSELUNG
Das Prinzip der Wiederverwertbarkeit erfordert eine Trennung zwischen eigentlichen Medien und
ihrer Verwendung im Kontext eines Lernmoduls: Würden einem Medienelement irgendwelche Darstellungsattribute direkt beigeordnet, wäre z.B. seine Position in allen Lernmodulen, die das Objekt
verwenden, gleich.
Aus diesem Grunde wird das Prinzip der „Kapselung“ eingeführt: Statt ein Medienelement direkt inein Lernmodul einzubetten, wird ein Kapselungselement generiert, das einen Verweis auf das Medium enthält und diesem weitere, für den jeweiligen Einsatzort spezifische Eigenschaften – im Beispiel u.a. die Darstellungsparameter – hinzufügt. In den Lernmodulen selbst finden sich also keine
„physikalischen“ Medienelemente, nur entsprechende Verweise auf das Medienarchiv. Um dennoch
dynamische Änderungen an den Inhalten zur Laufzeit eines Lernprogrammes vornehmen zu können
– beispielsweise um eine textuelle Benutzereingabe zu realisieren – können Kopien der Inhalte eines
Medienelementes in die Kapselung übernommen werden, sofern dies sinnvoll erscheint. Die veränderten Daten können dann direkt ins Benutzerprofil übernommen werden, so daß sie beim nächsten
Bearbeiten des Lernmoduls wieder zur Verfügung stehen. Dieser Fall wird einmal mehr über Varianten abgedeckt.
Ich möchte die Kapselungs-Technik anhand der folgenden Grafik verdeutlichen:
Medienkapselung
variable Eigenschaften
Verweis auf Medienelement
Medienelement
statische Grunddaten
Wichtig ist in diesem Zusammenhang noch die Definition der Begriffe „variable Eigenschaften“ und
„statische Grunddaten“: Unter statische Grunddaten fallen all diejenigen Attribute, die fest mit einem Medienelement verbunden sind, dieses also charakterisieren und damit „einzigartig“ im System
machen. Der Begriff „variable Eigenschaften“ hingegen bezeichnet „flüchtige“ Attribute wie die aktuelle Position auf dem Bildschirm, die Sichtbarkeit des Elementes und vergleichbare Eigenschaften.
Für den Autor bzw. den Produzenten muß die Trennung von Medienelement und -kapselung möglichst transparent sein, ohne daß ihm Unannehmlichkeiten daraus entstehen: Es muß also möglich
sein, „einfach so“ ein Textfeld in die Konzeption oder das Lernmodul zu integrieren, ohne dafür umständlich zuerst ein Medienelement anzulegen, danach auf das entsprechende Strukturelement im
Lernmodul zu wechseln und dort eine entsprechende Medienkapselung zu erstellen.
Bei den dynamischen Daten ist zu beachten, daß Inkonsistenzen bei gleichzeitigem Zugriff mehrerer
Benutzer auf das gleiche Objekt auftreten können: Während eine Grafik im Kontext des ersten Lerners angezeigt wird, ist sie beim zweiten ausgeblendet (beispielsweise, weil sich beide an unterschiedlichen Positionen der gleichen Phasenanimation befinden). Um diese Problematik zu umgehen, kennzeichnen die eigentlichen dynamischen Daten lediglich einen Standardzustand, der beim
ersten Benutzen zum Anlegen einer benutzerspezifischen, temporären Variante führt. Diese wird
nach Ende einer festlegbaren Lebensdauer (Lernmodul, Strukturelement) wieder freigegeben. So
findet bei entsprechend festgelegter Lebensdauer der entsprechenden Varianten der Lerner das
Lernprogramm immer in dem Zusatnd vor, in dem er es verlassen hat.
Das hier beschriebene Konzept der Kapselung hat den Vorteil, daß sich eine Änderung am Medienelement immer noch direkt auf alle seine Vorkommen auswirkt. Sollte dieser Effekt von Fall zu Fall
einmal unerwünscht sein, ist es immer noch ohne größeren Aufwand möglich, einzelne Kapselungen
Seite 78
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
durch das Anlegen einer Kopie des betroffenen Medienelementes von diesem Vorgang auszuschließen und somit im alten Zustand zu belassen.
GROBSTRUKTUR
Die Attribute lassen sich für Medienelemente in die folgenden Kategorien fassen:
Mediendaten – der eigentliche Inhalt des Medienelementes. Bei Texten die Textinformation, bei
Grafiken die Pixeldaten, bei Videos ein Verweis auf die entsprechende Datei.
Objektinfo – Verwaltungsinformationen zum Objekt, beispielsweise Objektname, Erstellungsdatum, Bildgröße, Farbtiefe, etc.
Archivinfo – wie in den Kapiteln 4.7.2 und 4.8.5 beschrieben
Überarbeitungsinfo – vgl. Kapitel 4.8.4
Varianten – vgl. Kapitel 4.7.1 und 4.8.3
Die Medienkapselungen wiederum lassen sich wie folgt klassifizieren:
Verweis auf das zugrunde liegende Medienelement
Objektinfo – Verwaltungsinformationen; ähnlich wie bei Medienelementen
Darstellungsinformationen – Infos zur Bildschirmposition, dem gewählten Bildausschnitt, etc.
Konzeptionsinfo – zusätzliche Informationen, die für die Drehbuchdarstellung und -verwaltung
notwendig sind
Archiv-, Überarbeitungs- und Varianten-Informationen – ähnlich wie bei Medienelementen, allerdings ist die Archivierungsinformation aufgrund der nicht allzu zentralen Stellung der Medienkapselungen im Gesamtsystem eingeschränkt.
KONKRETE ATTRIBUTE
Die folgende Darstellung ist gemäß der vorangegangenen Ausführungen in Medienelemente und
Kapselungen aufgeteilt. Die Eigenschaften orientieren sich an den von ToolBook unterstützten Eigenschaften (vgl. Asymetrix[33], 1994, S.1-2ff). Ich habe ToolBook als Basis der zu unterstützenden Eigenschaften gewählt, da meine eigenen Erfahrungen mit dieser Entwicklungsumgebung sehr positiv ausgefallen sind: Nahezu alle denkbaren multimedialen Ideen – von extrem zeitkritischen mal abgesehen – können mit ToolBook realisiert werden. Die hier aufgeführten Attribute müssen allerdings zumindest teilweise im Gesamtzusammenhang des Systementwurfs noch erweitert werden.
Medienelement: TEXT & HYPERTEXT
Inhalt des Textobjektes im Rich-Text-Format
Mediendaten
ID & Herkunft – eindeutige Kennung (vom System vergeben) & ErstellungsdaObjektinfo
tum
Bearbeitungsstand – kennzeichnet, ob es sich beim Inhalt des Textobjektes um
ein Schlagwort, eine Textskizze oder bereits um den ausgearbeiteten Text
handelt
Font – Voreinstellungen für Schrifttyp, -schnitt, -größe und Schriftfarbe. Kann
durch den Rich-Text überschrieben werden.
Absatz – Voreinstellungen für Zeilenabstand, Ausrichtung (links, rechts, zentriert, Blocksatz), Absatzabstände (vor, nach). Kann ebenfalls vom Rich-Text
überschrieben werden.
Ränder & Einzüge – Standardeinstellung. Kann durch den Rich-Text geändert
werden.
Fontersetzungstabelle – alternative Fonts, wenn ein Zeichensatz auf einem
Objektinfo
System nicht installiert ist
textuelle Umschreibung – eine textuelle Umschreibung des Bildinhaltes, für die
Konzeptionsphase (Rich-Text-Format)
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
vgl. Kapitel 4.8.5
Archivinformation
Seite 79
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Kapselung: TEXT & HYPERTEXT
Verweis auf das entsprechende Medienelement
Verweis
Kopie der Mediendaten des Medienelementes – für Änderungen am Text zur
Laufzeit.
Typ der zur Laufzeit vorgenommenen Änderungen – temporär, permanent in
Form einer Variante oder permanent (also direkt im Medienelement)
ID, Herkunft & Info – eindeutige Kennung, Bearbeiter und Erstellungsdatum
Objektinfo
Position – linke obere Ecke des umgebenden Rechtecks; relativ zum übergeDarstellungsinfo
ordneten Strukturelement
Größe – Breite und Höhe des umgebenden Rechtecks
Sichtbarkeit – wird das Medienelement im Moment dargestellt oder nicht?
Drag & Drop – vgl. Kapitel 5.2.3
Typ – sind Benutzereingaben zur Laufzeit in den Text möglich oder nicht?
Rahmendefinition – Linientyp, -farbe und -dicke des umgebenden Rechtecks;
Hintergrundfarbe des Rechtecks
vgl. Kapitel 5.3
Konzeptionsinfo
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
benutzerdefinierte Kennung – „Name“ der Kaspelung
Archivinfo
Beschreibungstext, der in Suchanfragen einbezogen werden kann.
Medienelement: BITMAP-GRAFIKEN
Inhalt des Grafikobjektes im geräteunabhängigen Windows-Format. Es kann
Mediendaten
ein einfacher (und schneller) Packalgorithmus für die Daten vorgeschaltet
werden.
ID & Herkunft – eindeutige Kennung (vom System vergeben) & ErstellungsdaObjektinfo
tum
Bearbeitungsstand – kennzeichnet, ob es sich beim Inhalt des Grafikobjektes
um eine textuelle Umschreibung, eine Skizze, eine Rohfassung oder bereits
um die ausgearbeitete Version handelt
Maske – Transparenz-Information zum Ausstanzen von nicht-rechteckigen
Bitmap-Grafiken; wird auch zur Bestimmung der realen Form bei Verwendung
der Grafik als Hotspot verwendet.
Farbtiefe – Anzahl der Bitplanes
Palette – Farbpalette des Bildes (wenn vorhanden).
Ausmaße – Höhe und Breite der Grafik in Pixeln
textuelle Umschreibung – eine textuelle Umschreibung des Bildinhaltes, für die
Konzeptionsphase (Rich-Text-Format)
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
vgl. Kapitel 4.8.5
Archivinformation
Kapselung: BITMAP-GRAFIKEN
Verweis auf das entsprechende Medienelement
Verweis
ID, Herkunft & Info – eindeutige Kennung, Bearbeiter und Erstellungsdatum
Objektinfo
Ausschnitt – Ausschnittsdefinition bezüglich des Medienelementes: So können
Darstellungsinfo
verschiedene Ausschnitte einer einzigen Grafik wiederverwertet werden, ohne
daß für jeden Ausschnitt ein eigenes Medienelement generiert werden muß.
Position – linke obere Ecke auf dem Bildschirm; relativ zum übergeordneten
Darstellungsinfo
Strukturelement
Größe – Höhe, Breite des gewählten Ausschnittes auf dem Bildschirm; ggf.
werden die Bildinformationen vergrößert oder verkleinert.
Sichtbarkeit – wird das Medienelement im Moment dargestellt oder nicht?
Drag & Drop – vgl. Kapitel 5.2.3
vgl. Kapitel 5.3
Konzeptionsinfo
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
Seite 80
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Kapselung: BITMAP-GRAFIKEN
benutzerdefinierte Kennung – „Name“ der Kaspelung
Archivinfo
Beschreibungstext, der in Suchanfragen einbezogen werden kann.
Medienelement: GRAFIKGRUNDELEMENTE
Eckpunkte des Grafikobjektes – als Liste mit Koordinatenpaaren, relativ zum
Mediendaten
Ursprung des Objektes
ID & Herkunft – eindeutige Kennung (vom System vergeben) & ErstellungsdaObjektinfo
tum
Bearbeitungsstand – kennzeichnet, ob es sich beim Inhalt des Grafikobjektes
um eine textuelle Umschreibung, eine Skizze, oder um die fertige Version
handelt
Farben – Farben der Fläche und der Umrandung (getrennt)
Füllung – Füllmuster der Fläche
Rand – Linientyp, -farbe und -dicke
textuelle Umschreibung – eine textuelle Umschreibung des Bildinhaltes, für die
Konzeptionsphase (Rich-Text-Format)
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
vgl. Kapitel 4.8.5
Archivinformation
Kapselung: GRAFIKGRUNDELEMENTE
Verweis auf das entsprechende Medienelement
Verweis
ID, Herkunft & Info – eindeutige Kennung, Bearbeiter und Erstellungsdatum
Objektinfo
Position – linke obere Ecke auf dem Bildschirm; relativ zum übergeordneten
Darstellungsinfo
Strukturelement
Größe – Höhe, Breite des Grafikgrundelementes auf dem Bildschirm; ggf. wird
das zugrundeliegende Element skaliert.
Sichtbarkeit – wird das Medienelement im Moment dargestellt oder nicht?
Drag & Drop – vgl. Kapitel 5.2.3
vgl. Kapitel 5.3
Konzeptionsinfo
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
benutzerdefinierte Kennung – „Name“ der Kaspelung
Archivinfo
Beschreibungstext, der in Suchanfragen einbezogen werden kann.
Medienelement: GUI-ELEMENTE
Grunddefinition der Inhalte – Menütexte, Listbox-Inhalte, etc. Werden von der
Mediendaten
Medienkapselung übernommen und können dort zur Laufzeit verändert werden.
ID & Herkunft – eindeutige Kennung (vom System vergeben) & ErstellungsdaObjektinfo
tum
Bearbeitungsstand – kennzeichnet, ob es sich beim Inhalt des Grafikobjektes
Objektinfo
um eine textuelle Umschreibung, eine Skizze, oder um die fertige Version
handelt
GUI-Eigenschaften18 – beispielsweise automatisches Sortieren, aktuelle Auswahl, Aktivierbarkeit (enabled/disabled) etc.
Ausdehnung – Breite und Höhe des Elementes. Kann von der Kapselung überschrieben werden.
textuelle Umschreibung – eine textuelle Umschreibung des GUI-Elementes, für
die Konzeptionsphase (Rich-Text-Format)
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
vgl. Kapitel 4.8.5
Archivinformation
18
vgl. z.B. Petzold/Yao, 1996[46], verschiedene Seiten
Seite 81
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Kapselung: GUI-ELEMENTE
Verweis auf das entsprechende Medienelement
Verweis
Kopie der Mediendaten des Medienelementes – für Änderungen an Menüstrukturen, Listenfeldern, etc. zur Laufzeit.
Typ der zur Laufzeit vorgenommenen Änderungen – temporär, permanent in
Form einer Variante
ID, Herkunft & Info – eindeutige Kennung, Bearbeiter und Erstellungsdatum
Objektinfo
Position – linke obere Ecke auf dem Bildschirm; relativ zum übergeordneten
Darstellungsinfo
Strukturelement
Größe – Höhe, Breite des Multimedia-Elementes auf dem Bildschirm; überschreibt die Vorgaben des Medienelementes.
Sichtbarkeit – wird das Medienelement im Moment dargestellt oder nicht?
Drag & Drop – vgl. Kapitel 5.2.3
vgl. Kapitel 5.3
Konzeptionsinfo
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
benutzerdefinierte Kennung – „Name“ der Kaspelung
Archivinfo
Beschreibungstext, der in Suchanfragen einbezogen werden kann.
Medienelement: „MULTIMEDIA“-ELEMENTE
Definition der Inhalte – Verweis auf die entsprechende Datei oder die MeMediendaten
diendaten selbst im vom jeweiligen Darstellungsmodul benötigten Format
Verweis auf Darstellungsmodul – Verweis auf das zu verwendende Wiedergabemodul (internes oder externes Modul)
ID & Herkunft – eindeutige Kennung (vom System vergeben) & ErstellungsdaObjektinfo
tum
Bearbeitungsstand – kennzeichnet, ob es sich beim Inhalt des Grafikobjektes
um eine textuelle Umschreibung, eine Skizze, oder um die fertige Version
handelt
Ausdehnung – Breite und Höhe des Elementes; kann von der Kapselung überschrieben werden
Zeitliche Information – Dauer des Mediums, wenn es sich um ein
Charakterisierung – interaktives (z.B. VRML), dynamisches (z.B. Video) oder
statisches (z.B. Grafik) Medium, visuelles oder nicht-visuelles (z.B. Audio)
Medium
spezifische Informationen – Informationen, die vom Medientyp abhängen; z.B.
ein Anfangszustand einer VRML-Welt, etc.
textuelle Umschreibung – eine textuelle Umschreibung des GUI-Elementes, für
die Konzeptionsphase (Rich-Text-Format)
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
vgl. Kapitel 4.8.5
Archivinformation
Kapselung: „MULTIMEDIA“-ELEMENTE
Verweis auf das entsprechende Medienelement
Verweis
spezifische Informationen – Informationen, die vom Medientyp abhängen; z.B.
ein aktueller Zustand einer VRML-Welt, etc. Kann in Interaktionsprozeße
einbezogen werden.
ID, Herkunft & Info – eindeutige Kennung, Bearbeiter und Erstellungsdatum
Objektinfo
Position – linke obere Ecke auf dem Bildschirm; relativ zum übergeordneten
Darstellungsinfo
Strukturelement
Größe – Höhe, Breite des Elementes auf dem Bildschirm; je nach Funktionalität des Darstellungsmoduls wird der Inhalt skaliert oder lediglich ein Ausschnitt
gewählt.
Sichtbarkeit – wird das Medienelement im Moment dargestellt oder nicht?
Abspielposition – aktuelle Position bei einem dynamischen Medium, beispielsweise das gerade gespielte Frame eines Videos
Drag & Drop – vgl. Kapitel 5.2.3
vgl. Kapitel 5.3
Konzeptionsinfo
Seite 82
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Kapselung: „MULTIMEDIA“-ELEMENTE
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
benutzerdefinierte Kennung – „Name“ der Kaspelung
Archivinfo
Beschreibungstext, der in Suchanfragen einbezogen werden kann.
5.2.6.
Strukturelemente
Strukturelemente leiten sich direkt aus dem Metapherbegriff ab: Es existieren also statische und dynamische Strukturelemente. Strukturelemente fassen Medienelemente zusammen und stellen sie in
einen entsprechenden Kontext: So werden Grafiken bei einem Animationselement anders interpretiert als bei einer reinen Elementgruppierung. Im ersten Fall werden die referenzierten Grafikobjekte
beispielsweise eine nach der anderen in Form einer Diashow abgespielt, im zweiten werden lediglich
inhaltlich zusammengehörende Grafiken zu einer Einheit zusammengefaßt.
STATISCHE STRUKTUREN
Als statische Strukturen wären anzuführen:
Elementgruppierungen – das logische Zusammenfassen inhaltlich zusammengehöriger Elemente
Seiten, Karten o.ä. – an der Bildschirmdarstellung orientierte Strukturen
Hierarchiestrukturen – die der Gliederung eines Lernmoduls dienen
Verknüpfungs- und Verweisstrukturen – um das Verhältnis und Verweise zwischen Elementen
realisieren zu können (beispielsweise das Festlegen eines linearen Ablaufs, etc.)
DYNAMISCHE STRUKTUREN
Als dynamische Strukturen wären zu nennen:
AV-Sequenzen der unterschiedlichsten Arten: Phasenanimationen mit und ohne synchronisiertem Ton, Pfadanimationen, etc.
Videosequenzen – ähnlich wie AV-Sequenzen, allerdings mit digitalen Videos anstatt Einzelbildern
Simulationen, beispielsweise in Form von VRML-Welten oder anderen, hochinteraktiven Strukturen.
SPEZIELLE STRUKTUREN
Als „spezielle Struktur“ existiert in diesem Systementwurf lediglich die Verifizierung (vgl. Kapitel
5.1.3). Daneben sind aber auch andere inhaltliche Spezialfälle denkbar, die die ihr untergeordneten
Elemente auf eine ganz spezielle Art und Weise behandeln – beispielsweise eine Simulation mit verschiedenen Komponenten, wobei die Simulation ein spezielles Strukturelement darstellen würde;
ebenso könnten die Komponenten dieser Simulation ihrerseits wieder strukturelle Spezialfälle darstellen.
AUFBAU
Strukturelemente beinhalten folgende Eigenschaften:
Objektinfo – allgemeine Daten zum Strukturelement (ID/Herkunft/Bearbeitungsstand)
Hierarchieinfo – Stellung des Strukturelementes hinsichtlich anderer Strukturelemente. Hier sind
auch Navigationsinformationen untergebracht – vgl. Kapitel 6.3.3.
Seite 83
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Darstellungsinfo – Informationen zur Darstellung auf dem Bildschirm
Verweise – Liste mit Verweisen auf die an der Struktur beteiligten Elemente (beispielsweise Grafiken) und Ablaufschablonen. Die Verweise enthalten neben dem eigentlichen Zeiger Zusatzinformationen; bei einer Phasenanimation beispielsweise Start- und Endzeit der jeweiligen Phase. Die
Reihenfolge in dieser Liste legt auch die „Ebene“ eines visuellen Elementes fest – weiter hinten
definierte Grafiken überschreiben die gemeinsamen Bildbereiche mit zuvor definierten Elementen.
Konzeption – zusätzliche zur Darstellung in der Drehbuchansicht notwendige Informationen
Archivinfo – vgl. Kapitel 4.8.5
Überarbeitungsinformationen – vgl. Kapitel 4.8.4
Varianten – vgl. Kapitel 4.8.3
5.2.7.
„Programmierung“ des Systems
Nachdem ich nun definiert habe, welche Medienelemente wie in die Lernmodule eingebunden
werden können, müssen noch Aussagen über die Programmierbarkeit bzw. das Festlegen der Programmlogik getroffen werden. Wie bereits erwähnt (vgl. Kapitel 5.2.4), orientiert sich die Programmierung an einem schablonenhaften Ereignis-Reaktions-Modell.
ANFORDERUNGEN
Programmstrukturen sollen möglichst einfach erzeug- und handlebar bleiben – es gilt der Grundsatz,
„die hier diskutierten Vorteile des computerbasierten Lernens [...] dem Autor so zur Verfügung [zu stellen], daß er sie einfach, intuitiv und sinnvoll in seine Konzeption einbeziehen kann“ (Kapitel 3.8, S.39).
Die strikte Trennung von Programmierer und Autor fällt durch dieses schablonenartige Prinzip weg –
solange die vom Autor gewünschten Programmstrukturen auch vom System unterstützt werden. Dadurch ist leider die Konzeptionsfreiheit eingeschränkt – denn bei dem gewählten Konzept muß für
jeden neuen, innovativen Einfall, der sich mit den vorhandenen Möglichkeiten nicht realisieren läßt,
ein C++-Programmierer herangezogen werden.
Es muß die Transparenz zwischen Konzeption, Produktion und Rezeption gewährleistet werden: Der
Autor muß die entsprechenden Programmstrukturen bereits in der Konzeptionsphase anlegen können. Diese Strukturen werden in der Produktionsphase mit Inhalten gefüllt und realisieren dann Programmlogik und -ablauf für die Rezeption.
Um auch Benutzereingaben verarbeiten zu können, sollten Elemente jeder Art auch zur Laufzeit angelegt werden können. Die Einbindung erfolgt über Varianten: Die zur Laufzeit erzeugten Elemente
werden automatisch den Ursprungselementen als benutzerspezifische Variante zugeordnet.
ALLGEMEINE ANFORDERUNGEN AN DIE PROGRAMMIERBARKEIT
Um vielseitige Programmabläufe und Interaktionen realisieren zu können, müssen Bedingungen („if
... then ... else ...“), Programmverzweigungen („go to page ...“) und die Manipulation von Elementen
(„hide“/„show“) unterstützt werden. Weiterhin ist wichtig, daß Objekt-Zustände bei der Formulierung von Bedingungen berücksichtigt werden können. Ebenso müssen umfangreiche textliche und
mathematische Funktionalitäten realisierbar sein, um beispielsweise Berechnungen durchführen zu
können oder Zwischenergebnisse abspeichern und verarbeiten zu können.
Seite 84
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
In diesem Zusammenhang muß ein „Ersatz“ für das Variablen-Konzept herkömmlicher Programmiersprachen gefunden werden. Mögliche Lösungen hierfür sind „Variablenelemente“ oder direkte Zuordnungen zu Objekten (vergleichbar mit ToolBooks-Konzept der „user-properties“).
UMSETZUNG
„Programmiersprache“ ist aufgrund der vorher genannten Aspekte „die Lernumgebung selbst“ – für
ein Lernmodul zusätzlich benötigte Funktionalitäten werden innerhalb des bestehenden Systems integriert. Die neue Funktionalität steht damit auch zukünftigen Lernmodulen zur Verfügung, ohne daß
Kombatibilitätsprobleme mit alten Lernmodulen auftreten. Dazu ist neben der Einhaltung von den
üblichen Anforderungen der Abwärtskompatibilität vor allem eine strenge Versionskontrolle notwendig, damit neue Module nicht mit alten Systemversionen integriert werden können. Näheres zu einer
solchen Versionskontrolle unter objektorientierten Basis: vgl. Kapitel 7.4.3 und 7.4.7.
Um die genannte Funktionalität gewährleisten zu können und gleichzeitig eine für den Autoren
durchschaubare und integrative Handhabung zu ermöglichen, müssen sämtliche Möglichkeiten in
der notwendigen Flexibilität als vorgefertigte „Schablonen“ zur Verfügung gestellt werden. Dies bedeutet, daß statt üblicher Programmstrukturen – also „if ... then ... else ...“ oder „go to page ...“ –
Objekte verwendet werden, die diese Programmstrukturen in Form von Ereignis–Reaktionsketten
nachbilden. Insbesondere die Forderungen nach Transparenz zwischen den einzelnen Prozessen und
damit nach der Verschmelzung von Autor und Lernmodule-Programmierer verbieten den Einsatz einer Skriptsprache.
Um dem geneigten Leser einen Eindruck der beiden Methoden zu vermitteln, habe ich sie anhand
eines vereinfachten Beispiels nebeneinander gestellt:
OpenScript-Code
Skript des Buttons “btnBeispiel”:
to handle buttonClick
go to page “pgNeu”
end buttonClick
Ablaufschablone – Attribute und Inhalte
Mausklick
Ereignis
direkte Programmverzweigung
Reaktion
Bezugselement Verweis auf die entsprechende Medienkapselung – hier die GUIKapselung „btnBeispiel“
Verweis auf das Ziel – hier das StrukturZielelement
element „pgNeu“
Diese Art der „Pseudoprogrammierung“ kann leider nicht alle Eventualitäten abdecken, wie es eine
Skriptsprache könnte. Deshalb muß für diese Eventualitäten eine Art „freie Ablaufschablone“ existieren, über die eine beliebige textuelle Umschreibung des kritischen Ablaufs von einem Systemprogrammierer in entsprechenden Code der „Muttersprache“ der Lern- und Produktionsumgebung (also
beispielsweise C++) umgesetzt werden kann.
Die große Herausforderung an dieser „Baustelle“ des Systementwurfs wird es sein, Ablaufschablonen
zu entwickeln, die einen Großteil der möglichen Programmabläufe erfassen.
5.2.8.
Darstellungsmodule
Die Darstellungsmodule müssen sich aufgrund ihrer erweiterbaren modularen Struktur ebenfalls an
eine genaue Schnittstellendefinition halten. Aus Gründen der Flexibilität wird für die Darstellungsmodule eine eigene Schnittstellendefinition erarbeitet; die mögliche Übernahme von „Standards“
wie Browser-Plugins wird mangels ausreichender Dokumentation und Flexibilität verworfen.
Seite 85
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Ich möchte diese Schnittstellen erst im eigentlichen Systementwurf definieren, da vorher Kontext und
Datenstrukturen des kompletten Systems definiert sein sollten.
5.2.9.
Module
Um externe Module, die die Funktionalität des Systems erweitern, einbinden zu können, müssen
wiederum genaue Schnittstellen definiert und Objektzugriffsmöglichkeiten definiert werden. Dies
macht erst dann Sinn, wenn das komplette System größtenteils definiert ist – deshalb verschiebe ich
nähere Ausführungen hierzu auf den eigentlichen Systementwurf.
Einen Aspekt möchte ich allerdings an dieser Stelle aufgreifen: In dem in Kapitel 5.1.1 vorgestellten
Komponentenentwurf sind Module wie Produktionsoberfläche, Lernumgebungsoberfläche oder Archiv enthalten. Doch was sind die Benutzeroberflächen letztlich anderes als Medienelemente, die
auf bestimmte Ereignisse reagieren? Mit anderen Worten: Ist die Grundfunktionalität (also die Kernkomponenten) des Systemes erst einmal implementiert, können die „höheren“ Module aus diesen
Kernkomponenten zusammengesetzt werden. Sicherlich muß zusätzliche Funktionalität über C++Module hinzugefügt werden – aber dies machen Entwicklungsumgebungen wie ToolBook auch nicht
anders: Alle Funktionen, die über die einfache Objektmanipulation hinausgehen, sind in den OpenScript-basierten Systembüchern und ggf. in DLLs abgelegt.
5.2.10.
Die Rückkehr des Gesamtkontextes...
Die bisherigen Ausführungen dieses Kapitels waren äußerst techniklastig. Ich will sie deshalb hier
noch einmal in den Gesamtkontext eines integrierten Systems stellen.
KONZEPTION UND STRUKTURELEMENTE
Im Abschnitt „The Making of...“ habe ich mich ausführlich mit der Verschmelzung von Konzeptionsund Produktionsprozessen befaßt. Ich möchte diese Verschmelzung nun konkret auf die hier diskutierten Datenmodelle beziehen.
Ich habe die These aufgestellt, daß Drehbuch und Endprodukt letztlich nur verschiedene Ansichten
von ein und derselben Sache sind. Folglich können Drehbuchelemente direkt mit Struktur- oder Medienelementen in Verbindung gebracht werden: Wird in das Drehbuch eine Grafik aufgenommen,
kann sie direkt in ein Grafikelement des eigentlichen Lernmoduls überführt werden. Ebenso werden
aus der textuellen Beschreibung der Interaktionsmöglichkeiten direkt die benötigten Ablaufschablonen generiert.
Die Mindmap und ihre Ausdetaillierungen erfordern allerdings eigenständige Konzeptionselemente,
die auch das Drehbuch betreffen – ich werde diese im folgenden Kapitel „Typedef Struct { ? }
Mindmap;“ näher beschreiben.
KONZEPTION, PRODUKTION UND MEDIENELEMENTE
Die in der Konzeption angelegten Medienelemente werden in der Produktion von der textuellen Beschreibung oder der Skizze zu den tatsächlich verwendeten Medien weiterentwickelt, d.h. die entsprechenden Konzeptionsvorgaben und -umschreibungen durch konkrete Inhalte ersetzt. Da das
Drehbuch direkt auf die entsprechenden Ablaufschablonen, Struktur- und Medienlemente verweist,
Seite 86
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
wird es mit zunehmender Produktion automatisch ebenfalls detaillierter und „fertiger“. So können
digitalisierte Videos auch in der Drehbuchansicht betrachtet werden.
KONZEPTION UND ABLAUFSCHABLONEN
Die textuelle Beschreibung des Programmablaufs soll also direkt in entsprechende Ablaufschablonen
überführt werden. Im Umkehrschluß bedeutet dies:
Es können lediglich Programmabläufe konzipiert werden, für die auch Ablaufschablonen vorhanden sind. Abhilfe schaffen hier die bereits andiskutierten „freien“ Ablaufschablonen, die später
von einem Systemprogrammierer mit der entsprechenden Funktionalität gefüllt werden müssen.
Es müssen einheitliche, eindeutige Formulierungen für die Abläufe definiert werden, daß das System entsprechend reagieren und automatisch Schablonen generieren kann. Dies entspricht der
Festlegung auf eine genau definierte Konzeptions-Sprache, die als willkommener Nebeneffekt
Kommunikationsschwierigkeiten bei den an der Produktion Beteiligten vermindern kann.
ZUSAMMENGEFAßT...
Ich möchte die Zusammenhänge zwischen den einzelnen Elementen und Ansichten noch einmal
überblickartig in einer Grafik zusammenfassen.
Konzeption
Konzeptionselemente
erste
Skizzen
Mindmap
Rezeption
Ausdetaillierung
Strukturelemente
Drehbuch
. . .
. . .
. . .
Verweis
. . .
Medienelemente
Ablaufschablonen
Lernmodul
Ich bin ein
VW Golf
DIE ANDERE SEITE: HARDCORE-PROGRAMMIERUNG & CO. – EIN EXKURS
Bisher habe ich das System ausschließlich aus Sicht des Autors beleuchtet, der möglichst einfach und
effizient Lernmodule entwickeln will und dabei Unterstützung während Konzeption und Produktion
erhofft. Dennoch will ich noch kurz einen Abstecher zu den Bedürfnissen der „anderen Seite“, also
die Anforderungen eines „Hardcore-Programmierers“ einlegen, denn: Aus Sicht des SystemProgrammierers kann der hier vorgestellte Systementwurf als einfach erweiterbares Baukastensystem
für beliebig komplexe Lernanwendungen dienen, in dem ihn keine langsame, unvollständige Skriptsprache in seinen Möglichkeiten einschränkt – schließlich kann er benötigte Zusatzfunktionen direkt
und performanceoptimiert in C++ programmieren, ohne auf den Komfort und die Einfachheit eines
Autorensystems verzichten zu müssen.
Seite 87
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
5.3.
TYPEDEF STRUCT { ? } MINDMAP;
Gedanken zu Konzeptionselementen
Nachdem ich bisher auf die multimedialen Fähigkeiten und ihre Realisierung eingegangen bin,
möchte ich nun noch auf spezielle Konzeptionselemente eingehen. Die inhaltliche und strukturelle
Form und Funktion dieser Elemente habe ich bereits im Abschnitt „The Making of...“ definiert. Allerdings bin ich dort auf einem vergleichsweise undetaillierten Level wieder ausgestiegen. Da jetzt die
übrigen Systemkomponenten größtenteils definiert sind, will ich das Thema „Konzeptionselemente“
an dieser Stelle erneut aufgreifen und auf den Detaillierungsstand der übrigen Elemente bringen.
5.3.1.
Grundstruktur der Konzeptionselemente
Konzeptionselemente sind letztlich nichts anderes als die Strukturelemente während der Konzeptionsphase: Sie strukturieren Gedanken, Ideen und Visualisierungen. Nun sind Gedanken, Ideen und
Visualisierungen auf Datenebene auch nichts anderes als Texte, Grafiken und Sounds – also Medienelemente –, und somit stellt sich natürlich wieder die Frage der Integration: Medienelemente der
Konzeption können, müssen aber nicht in die Produktionsphase übernommen werden. Diese Unterscheidung ist insofern von Bedeutung, daß Medienelemente, die ausschließlich konzeptionellen
Zwecken dienen, bei der Distribution „außen vor“ gelassen werden können/müssen.
5.3.2.
Diversifizierung?
Anders als bei Medienelementen gibt es bei den Konzeptionselementen keine weitere Unterteilung –
die Konzeption geschieht also in einer Art einheitlichen „freien Struktur“, über dessen konkrete Nutzung letztlich der Autor allein entscheidet. Die Bedeutung gemäß Kapitel 4.5.4 wird ausschließlich
über die Hierarchieinfo vorgenommen. Es wird nicht überprüft, ob die Ebenen gemäß ihrer Intention
verwendet werden, somit stellen sich auf Datenebene sämtliche Konzeptionsebenen gleich dar – als
Netz mit gleichartigen Knoten sowie hierarchischen und Querverweisen (vgl. Abschnitt „Knoten,
Links, Netze“).
5.3.3.
Attribute von Konzeptionselementen
Ich möchte im Folgenden die Attribute von Konzeptionselementen definieren. Ich werde sie im Abschnitt „Knoten, Links, Netze“ in den Kontext des Gesamtsystems stellen.
Eigenschaften: Mindmap-Elemente
Verweis auf Medienelement Verweis auf ein beliebiges Medienelement, das den eigentlichen
Inhalt des Konzeptionselementes trägt.
Stellung des Elementes innerhalb des dreidimensionalen MinHierarchie-Information
map-Gebildes: Konzeptions-Ebene, Stellung innerhalb der Ebene
(übergeordnetes Element, Liste mit untergeordneten Elementen)
Liste mit Verweisen auf andere Elemente, incl. ZusatzinformatioQuerverweise
nen (semantische Bedeutung oder textuelle Beschreibung des
Verweises).
Hier wird lediglich eine Stichwortliste und ein Beschreibungstext
Archivierungsinfo
verwaltet, die zur Suche verwendet werden können.
vgl. Kapitel 4.8.4
Überarbeitungsinfo
vgl. Kapitel 4.8.3
Varianten
Seite 88
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
5.4.
KOMMUNIKATIONSMECHANISMEN
Realisierung von Mensch-zu-Mensch-Interaktionen
Nachdem ich die Datenstrukturen, die das System prägen werden, bereits recht ausführlich beschrieben habe, werde ich mich in diesem Kapitel mit dem Kommunikationsaspekt einer intranetbasierten Lernumgebung befassen. Zunächst will ich die technischen Gegebenheiten definieren, danach die Realisierung der vom Modell des verteilten, kooperativen Lernens geforderten Module
„Schwarzes Brett“ und „Chat“.
5.4.1.
Technische Voraussetzungen
Sämtliche netzwerkbasierten Funktionen basieren auf dem OSI-Schichtenmodell (vgl. Gutschmidt,
1996[29]): Es dient dazu, physikalische und logische Kommunikationsebene voneinader zu trennen, so
daß sich der Anwendungsprogrammierer nicht darum kümmern muß, welche Netzwerkkarte er wie
ansteuern muß. Dazu werden verschiedene Schichten eingeführt, die aufeinander aufbauen und jeweils über exakt definierte Schnittstellen miteinander kommunizieren. Die Schichten sind teilweise
austauschbar, so können verschiedene Protokolle der oberen Ebenen auf dem gleichen Protokoll einer niedrigeren Ebene aufbauen.
TCP/IP – DIE „MUTTER“ ALLER NETZWERKPROTOKOLLE IN INTRA- UND INTERNET
Intra- und Internet sind dadurch charakterisiert, daß sie in der Transportschicht das TCP-Protokoll
(Schicht 4) und auf Netzwerkebene (Schicht 3) das IP-Protokoll verwenden. TCP/IP wird als verbindungsloses Protokoll bezeichnet, da keine physikalische Verbindung zwischen den miteinander
kommunizierenden Rechnern aufgebaut wird. Dies bedeutet gleichzeitig, daß für jede Kommunikation eine eigene, temporäre Verbindung aufgebaut werden muß. [Uni-Rechenzentrum Mannheim,
1997[30]]
SMTP/POP3/TELNET/...
Auf den elementaren TCP/IP-Schichten bauen dann die dem Anwender bekannten Protokolle wie
FTP, HTTP, SMTP, POP3 oder TELNET (um nur eine Auswahl zu nennen) in der Anwendungsschicht
auf. Letztlich werden diese Protokolle von Anwendungsprogrammen benutzt. [Uni-Rechenzentrum
Mannheim, 1997[30]]
UNTERSTÜTZUNG DURCH DAS BETRIEBSSYSTEM
Netzwerkfunktionen werden von modernen Betriebssystemen standardmäßig unterstützt, indem die
entsprechenden Anwendungsschichten durch ein entsprechendes Programmierinterface (API) gekapselt wird. Die konkrete Implementierung der einzelnen Protokollschichten oder gar die zugrundeliegende Hardware spielen bei der Programmierung keine Rolle mehr.
Auf 32-Bit-Windows-Betriebssystemen existiert das sogenannte WinInet API, das die drei Protokolle
HTTP (Webseiten-Transfer), FTP (Dateiübertragungen) und Gopher realisiert; das MAPI (Message
Application Programming Interface) unterstützt das Versenden von Messages. [Microsoft, 1997[45],
mk:@ivt:intcsdk/intc6566.htm#wininet_ovr_0419000100000000, mk:@ivt:vccore/F50D/D512/S26AC.HTM]
Seite 89
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
FAZIT
Dank OSI-Schichtenmodell und Betriebssystem-spezifischen Programmierschnittstellen muß sich der
Programmierer (und damit auch der Systementwickler) nicht mit der konkreten Implementierung der
jeweiligen Protokolle beschäftigen. Deshalb ist die Definition hier recht kurz ausgefallen – sie reicht
aber zur Anwendungsprogrammierung vollkommen aus – zumal die objektorientierte Datenbank
auch noch diese Arbeit größtenteils übernimmt, wie sich zeigen wird.
5.4.2.
eMail
Die eMail-Kommunikation zwischen den einzelnen Lernern und zwischen Lernern und Tutor soll
privat bleiben und von Seiten Dritter nicht „abgehört“ werden können. Zu diesen Zwecken sollte ein
eMail-Client eingebaut sein. Eingegangene und gesendete Nachrichten sowie die Entwürfe und vom
Lerner angelegte Unterverzeichnisse werden über das Benutzerprofil verwaltet. Die entsprechenden
Strukturen präsentieren sich folgendermaßen:
Eigenschaften: Nachrichten
eMail-Adresse oder Verweis auf das Benutzerprofil
Absender/Autor
eMail-Adresse oder Verweis auf das Benutzerprofil; für Nachrichten
Empfänger
des Diskussionforums: Verweis auf das Themenelement.
Verwaltungsinformationen Erstellungsdatum und -zeit
Betreff der eMail (Text)
Subject
Textinhalt (Rich-Text-Format oder HTML19)
Inhalt
Verweise auf vorhergehende Nachrichten und Replies
Referenzen
Für Kommentare zu eMails.
Überarbeitungsinfo
5.4.3.
Schwarzes Brett
Das Schwarze Brett (oder Diskussionsforum) basiert ebenfalls auf Nachrichten (s.o.), die zu einem
Thema zugeordnet werden können. Themen sollen hierarchisch in Unterthemen gliederbar sein.
Eigenschaften: Thema/Unterthema
Themenbeschreibung („Subject“)
Titel
Verwaltungsinformationen Erstellungsdatum und -zeit
Erläuterungen zum Thema – welche Beiträge sind erwünscht, welche
Beschreibung
Ziele verfolgt das Thema?
Liste mit Verweisen auf Beiträge zum Thema (Nachrichten)
Beiträge
Verweise auf übergeordnetes Thema und Liste mit untergeordneten
Hierarchieinfo
Themen
Die Gesamtmenge aller Themen bildet ein Diskussionsforum. Diskussionsforen können wiederum
unter ein Gesamtmotto gestellt werden. Eine Lernumgebung kann mehrere Diskussionsforen verwalten – jedes mit für bestimmte Attribute des Lernermodells individuelle Zugriffsrechten. So können
abteilungs-, rang- oder vorbildungsspezifische Foren geschaffen werden, die nur den entsprechenden
Zielgruppen angeboten werden.
Eigenschaften: Diskussionsforum
Name des Diskussionsforums
Titel
Verwaltungsinformationen Erstellungsdatum und -zeit
19
HTML kann unterstützt werden, wenn eine entsprechende Komponente auf den jeweiligen Systemen installiert iost – beispielsweise die
HTML-Authoring-Komponente des Microsoft Internet Explorers.
Seite 90
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Eigenschaften: Diskussionsforum
Zugriffsrechte anhand von allgemeinen Lernereigenschaften
Zugriffsrechte
Liste mit Verweisen auf alle Themen des Diskussionsforums
Themen
5.4.4.
Chat
Für Chats wird seitens der Lernumgebung die entsprechenden Benutzeroberfläche sowie die Möglichkeit einer Protokollierung (Nur-Text) unterstützt. Der eigentliche Chat läuft ausschließlich textbasiert ab. Es soll eine Untermenge des IRC-Standards unterstützt werden: Chat-Grundfunktionalitäten,
Channels, Nicknames für eine relative Anonymität und Moderatorenrechte. Die Channels können
wieder zielgruppenspezifisch freigeschalten werden.
Grundfunktionalität/Chat
Nicknames
Kommunikation
Verwaltung und Zuordnung der Nicknames zu Benutzern
Kommunikationsfunktionalität: Darstellen/Versenden von ChatBeiträgen (direkt über TCP/IP)
Verwaltungsinformationen/Channel
Name des Channels
Channelname
Kurzbeschreibung des Channelthemas
Thema
ausführliche Infos zum Thema
Beschreibung
Liste mit Verweisen auf alle momentan Beteiligten
Teilnehmer
Zugriffsrechte anhand von allgemeinen Lernereigenschaften
Zugriffsrechte
Liste mit gesperrten Benutzern (temporäre/permanente Sperren)
Sperren
5.5.
WECHSELWIRKUNGEN
Möglichkeiten der Verknüpfung verschiedener Module
Der Lerner hinterläßt Spuren in dieser Lernumgebung: Seine Vorgehensweise, seine Lösungsansätze
und Interaktionen werden aufgezeichnet (vgl. Kapitel 5.1.4, dynamische Daten). Dies ist natürlich eine Möglichkeit für den Betreuer, den Lernfortschritt anhand dieser Tracking-Daten abzuschätzen. Ein
Problem dabei ist selbstverständlich die pure Menge an Daten – es müssen also vorgefertigte Filter
bereitstehen, die ausschließlich relevante Informationen – beispielsweise das Verhalten an bestimmten neuralgischen Punkten eines Lernmoduls oder die Ergebnisse einer Verifizierung – aufbereiten.
Doch mit der Auswertung durch einen Tutor ist die Sache noch nicht erledigt, insbesondere im Zusammenhang mit Aspekten des situativen Kontextes: Rechte und Status des einzelnen Lerners innerhalb der Lernumgebung oder seiner Lerngruppe können individuell nach seinem Verhalten festgelegt
werden, bestimmte besonders interessante Inhalte können erst ab einem bestimmten Lernfortschritt
rezipiert werden.
5.5.1.
Bewertung eines Lerners – wie soll sowas funktionieren?
Die „Bewertung“ eines Menschen – das ist immer eine äußerst diffizile Angelegenheit, die aber in
unseren modernen Zeiten, in denen alles taxier- und bewertbar sein und Leistung sich wieder lohnen muß, eine wichtige Angelegenheit bleibt.
Seite 91
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Zunächst einmal muß definiert werden, welcher Instanz die individuelle Einschätzung des Lerners
zukommen soll – Computer oder Tutor. Aufgrund der Sensibilität dieses Bereichs ist die Antwort auf
diese Frage ganz klar: Die Entscheidung bleibt dem Tutor vorbehalten, er kann sich allerdings vom
Computer durch die Anzeige statistischen Materials unterstützen lassen.
Eine besondere Rolle spielen die Verifizierungen, die speziell dafür ausgelegt sind, von Maschinen
ausgewertet zu werden (vgl. Kapitel 5.1.3). Allerdings sollten die Ergebnisse nicht als „absolut“ hingenommen werden – erstens sind vom Computer auswertbare Aufgabenstrukturen oftmals nicht dazu
geeignet, die Komplexität unserer Umwelt zu erfassen, zweitens können uneindeutig formulierte
Auswahlmöglichkeiten beispielsweise bei Multiple-Choice-Fragen das Ergebnis wertlos machen.
5.5.2.
Individuelle Zugriffsrechte
Anhand der Bewertung oder der Einschätzung eines Lerners kann der Tutor ihm erweiterte Rechte
geben: Er darf einen Chat moderieren, kann ein eigenes Diskussionsforum leiten oder erhält Zugriff
auf „Geheimräume“ in den Lernmodulen. Allgemein können in alle Elemente der Lernumgebung die
Lernereinschätzung des Tutoren einbezogen werden – so wäre, im Zusammenhang mit dem folgenden Unterkapitel – auch eine Art „Best-Of“-Board möglich, in dem die „besten“ Lerner aufgeführt
sind.
Durch diese Art der „Belohnung“ soll ein weiterer extrinsischer Motivationsfaktor geschaffen werden.
Inwieweit solche Methoden tatsächlich eingesetzt werden sollen, bleibt dem Tutor überlassen.
5.5.3.
Spezialitäten einer Lern- und Produktionsumgebung
Die Kombination von Produktions- und Lernumgebung birgt einige zusätzliche Möglichkeiten in sich:
So können neben den festen, von außen angelieferten Lernmodulen auch kleine GruppenSpielchen, Animationen oder ähnliches vom Tutor produziert werden, an denen zu einem bestimmten Zeitpunkt alle Mitglieder einer Lerngruppe teilnehmen können oder die einen bestimmten Lernerfolg „belohnen“ können. Erlaubt ist alles, was Motivation schaffen kann, interessant ist oder den
harten Lernalltag auflockern kann.
Wie bereits erwähnt, können dem Lerner auch Möglichkeiten geboten werden, selbst kreativ zu
werden und Inhalte in die Lernumgebung zu stellen, die von anderen Lernern rezipiert und diskutiert
werden können. Derartige Möglichkeiten entsprechen erstens konstruktivistischen Prinzipien, fördern
also die aktive Auseinandersetzung mit Inhalten. Zweitens ist die Gruppendynamik, die durch das
gemeinsame Erstellen oder Kommentieren von Inhalten entsteht, ein nicht zu unterschätzender Motivationsfaktor. Unerwünschte (weil destruktive) Kommentare oder Bloßstellungen des Urhebers
können durch moderierte Foren abgemildert werden
Voraussetzung für die Einbindung derartiger Gimmicks ist natürlich, daß dem Tutor und dem Lerner
neben der Lernumgebung auch die zur Produktion notwendigen Module zur Verfügung stehen. Dies
ist allerdings weniger ein datentechnisches als ein vertriebstechnisches Problem.
5.5.4.
Technische Realisierung von Wechselwirkungen
Die Bewertung des Lerners ist letztlich nichts anderes als eine weitere Lernereigenschaft. Und genauso können davon abhängige Inhalte – und nichts anderes sind die hier diskutierten Wechselwirkungen –als Variante eingebunden werden, die auf genau diese Eigenschaften abgestimmt ist. ZusatzanSeite 92
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
gebote wie Gruppenspiele wiederum sind datentechnisch nichts weiter als Lernmodule mit den gleichen Möglichkeiten, müssen allerdings von der Benutzeroberfläche der Lernumgebung getrennt behandelt werden, beispielsweise in einer „Aktuell“- oder „Neu“-Sparte.
Tooldaten und eigene Module sind in den dynamischen Lernerdaten abgelegt und werden über das
Benutzerprofil verwaltet.
5.6.
STAU AUF DER DATENAUTOBAHN
Technische Probleme im Intranet
Eine Aufgabe der Systemanalyse ist es, mögliche Problematiken aufzuzeigen. Dies will ich hier mit
eindeutigen Fokus auf den Netzaspekt tun.
5.6.1.
Programm-Performance
Ein Grundproblem der Informatik: Programme sind nie schnell genug, sie können es einfach nie sein!
Wenn ich hier den Begriff „Programm-Performance“ diskutiere, beziehe ich mich zunächst auf den
subjektiven Eindruck, den ein Lerner bei der Rezeption eines Lernmodules bekommt.
Dieser subjektive Eindruck setzt sich bei einer intranetbasierten Lernumgebung allerdings aus mehreren Aspekten zusammen:
Geschwindigkeit des Netzes – wie lange dauert es, bis die Arbeitsstation, die Inhalte verfügbar
gemacht kriegt? Hier spielen die in den folgenden Unterkapiteln dargestellten Begriffe „Bandbreite“ und „Serverüberlastung“ die entscheidende Rolle
Darstellungsgeschwindigkeit – die Geschwindigkeit, mit der eine Arbeitsstation Inhalte visuell
aufbaut, Interaktionen verarbietet; ob die Wiedergabe von Medien unvermittelt ins Stocken gerät
oder gar abbricht; ob ruckelfreies Bewegen in virtuellen Welten möglich ist, etc.
5.6.2.
Bandbreite
Bandbreite ist das Hauptproblem in allen netzwerkbasierten Umgebungen: Mögen in kleinen Netzen
auch noch megabytegroße Daten problemlos und in annehmbarer Zeit transportiert werden können,
wird es in Intranets multinationaler Konzerne trotz gut ausgebauter Netz-Infrastruktur ungemütlich
eng, wenn multimediale Datenmengen hin- und hergeschaufelt werden sollen. Vom Internet ganz zu
schweigen...
PHYSIKALISCHE EIGENSCHAFTEN DES NETZES
Es existieren verschiedenste Vernetzungstechnologien mit unterschiedlichsten Leistungsdaten. Ich
möchte hier nur übersichtsartig die wichtigsten Technologien darstellen. [Gateway 5/97[31], S.38ff;
Christ, 1995[28]]20
20
Ich habe die gesamte Netzwerktechnologie hier vereinfacht abgehandelt, da sie zwar die Grundlage der folgenden Ausführungen, nicht aber
eigentliches Thema dieser Diplomarbeit sind. Zur Vertiefung seien die angegebenen Literaturverweise empfohlen.
Seite 93
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Technologie
Ethernet
Fast Ethernet
Giga Ethernet
FDDI
Fiber Distributed Data
Interface
ATM
Asynchronous Transfer
Mode
Charakterisierung
„Quasi-Standard“; derzeit noch am häufigsten im Intranet eingesetzt. Verwendet CSMA/CD, was zu hohen Leistungseinbußen
führt. Die angegebene Leistung ist deshalb nur ein theoretischer
Wert.
Synchrone Übertragungen sind nicht möglich.
Weiterentwicklung von Ethernet, immer noch auf CSMA/CD
basierend, deshalb Leistungswert rein theoretisch: Statt rechnerisch 10facher Leistung in der Praxis Steigerung nur um Faktor
1,7 bis 2,3.
Synchrone Übertragungen sind nicht möglich.
Zukünftige Weiterentwicklung des Ethernet-Standards, basierend auf erweitertem CSMA/CD. Realistische Übertragungsraten: 300-700 MBit/s.
Synchrone Übertragungen sind nicht möglich.
Zugriffsverfahren: Token-Ring-Passing. Es können Netze mit
vielen Stationen und großer Ausdehnung aufgebaut werden.
Synchrone Übertragungen sind möglich: Echtzeitdaten wie
Videostreams können eine höhere Priorität erhalten als unkritische Inhalte.
Aufspaltung in kleine, schnell verarbeitbare Datenpakete mit
einheitlicher Größe. Prinzip der virtuellen Kanäle; dadurch sind
synchrone Übertragungen möglich.
Leistung
10 MBit/s
100 MBit/s
1000 MBit/s
80-90 MBit/s
34->622 MBit/s
Besonders geeignet für multimediale Daten sind synchrone Übertragungen, bei denen eine gewisse
Bandbreite garantiert werden kann und so eine unterbrechungsfreier Zugriff auch auf Echtzeitdaten
mit konstanter Übertragungsrate möglich wird. Die Zukunft für intranetbasierte Multimedia-Systeme
scheint also eindeutig bei FDDI und ATM zu liegen.
DER ETHERNET-STATUS-QUO
Nun sind ATM und FDDI leider noch in den wenigsten Intranets zu finden. Hier wird immer noch
mit Ethernet oder Fast-Ethernet-Strukturen gearbeitet. Auch werden Modernisierungen und Aufrüstungen eher in Richtung Giga-Ethernet denn in Richtung neuer Technologien gehen – bestehende
Investitionen in die Ethernet-Technologie wollen schließlich bewahrt werden.
Betrachtet man den Status-Quo, wird das an sich multimedia-untaugliche Ethernet mit seinen Nachfolgern auf absehbare Zeit die Netzwerkplattform bilden, auf der intranetbasierte Lernumgebungen
aufbauen müssen. Und selbst bei Fast-Ethernet ist – laut Gateway 5/97[31], S.42 – mit vier (!) angeschlossenen Multimedia-Stationen Schluß!
Selbst wenn ATM und FDDI irgendwann einmal verbreiteter sind: Das Intranetprotokoll TCP/IP ist in
seiner heutigen Form ebenfalls nicht echtzeittauglich; für Echtzeitanwendungen müßten also spezielle, intranetfremde Protokolle verwendet oder die Weiterentwicklung von TCP/IP abgewartet werden.
5.6.3.
Der Server macht dicht!
Neben der Bandbreite des physikalischen Netzwerkes spielt die Performance des Servers eine entscheidende Rolle: Schließlich müssen alle Zugriffe auf die Datenbank von ihm zentral durchgeführt
werden; je nach Realisierungsstrategie (vgl. Kapitel 7.3) muß der Server zusätzlich noch die Aufbereitung der Daten in ein clientgerechtes Format übernehmen. Bei größeren Intranets sind auch großzügig ausgestattete Server schnell am Ende.
Seite 94
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Für diese Problematik gibt es hardwaretechnische Lösungen; so können, wenn das Datenbanksystem
dies unterstützt, einfach weitere Server hinzugekauft werden, die die Daten unter sich aufteilen. Eine
genauere Definition dieser „Skalierbarkeit“ genannten Technik findet sich im Kapitel 7.4.6.
5.6.4.
Lösungsstrategien
Aufgrund der doch recht happigen Probleme, die an sich für Multimedia untaugliche Netzinfrastrukturen aufwerfen, müssen entsprechende Lösungsstrategien ausgearbeitet werden.
DRAMATURGISCHE PROGRAMMIERUNG?
„Dramaturgische Programmierung“ klingt recht eindrucksvoll – bedeutet allerdings nicht mehr, als
daß Ladezeiten, die in einer Intranetumgebung durchaus problematisch sein können, so gelegt werden, daß für eine Szene ein flüssiger Ablauf gewährleistet werden kann. Es wäre schließlich für die
Dramaturgie tödlich, wenn die Wiedergabe eines Videos kurz vor dem Plotpoint aufgrund akuter
Netzüberlastung abbricht.
Aus diesem Grunde müssen in den Strukturelementen entsprechende „dramaturgische Informationen“ enthalten sein, so daß das Programm diese Medienelemente in unkritischeren Stellen vorladen
kann. Dies sollte über intelligente Algorithmen geschehen: Beispielsweise können während einer
längeren Drag & Drop-Aufgabe, die ja vollkommen auf der Clientseite (und damit ohne Netzbelastung) abläuft, bereits die Medienelemente der voraussichtlich nächsten Szenen vorgeladen werden.
NETZWERKTAUGLICHE DATENFORMATE
Wenn die Netzinfrastruktur dem Programmierer nicht entgegenkommen kann, kommt eben der Programmierer dem Netz entgegen und versucht, die zu übertragenden Datenmengen zu verkleinern.
Hierfür gibt es verschiedene Möglichkeiten: Besser packende Datenformate (z.B. die Verwendung
von JPEG statt BMP), Beschränkung der Qualität (beispielsweise durch die Verwendung von 8 Bit
mono und 22kHz-Samples statt Sound in CD-Qualität) oder die geschickte Kaschierung des Mangels
durch entsprechende Rücksichtsnahme in der Konzeptionsphase (beispielsweise die Nachbildung
großflächiger grafischer Elemente mit Grafikgrundelementen wie Kreisen, Polygonen oder Rechtecken.
Eine ausführliche Darstellung der verschiedenen netztauglichen Datenformate findet sich in Steinke
(1997[32], S.38ff). In meinem Systementwurf will ich unterschiedliche Datenformate durch Filtermodule realisieren, die die Daten vor der Übertragung über das Netz entsprechend komprimieren können.
„STILBRÜCHE“
Neben der Möglichkeit, die Last auf verschiedene Server zu verteilen, bietet sich noch eine radikale
Art der Netzentlastung: Die Daten der Lernmodule, die den Löwenanteil der Übertragungen ausmachen, werden auf CD-ROM ausgelagert und von dort abgespielt. Über das Netz selbst werden nur
noch Benutzerdaten aktualisiert. Alles in allem ist eine deratige Lösungsstrategie ein Fall für CrossMedia-Publishing – die technische Grundlagen derartiger „Stilbrüche“ werden in Kapitel 7.5 ausführlich behandelt.
Aus datentechnischer Sicht problematisch sind die Varianteninformationen eines Lernmoduls, da diese ja gemäß Definition während der Laufzeit eines Moduls dynamisch erweiterbar bleiben müssen.
Seite 95
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
„Konturen im Nebel“ – Komponenten einer netzbasierten Lern- und Produktionsumgebung
Mögliche Lösungen für dieses Problem: Kopien dieser dynamischen Elemente werden wiederum über das Netz angelegt und verwaltet, der Arbeitsrechner muß dabei allerdings bei jedem Objekt eine
Anfrage über die Varianteninfo an den Server schicken.
Ein weiteres infrastrukturelles Problem eines derartigen Ansatzes: die Distribution. Schließlich ist ein
entscheidender Vorteil einer Intranet-Lösung eine ständige Aktualität der Inhalte. Durch die Auslagerung auf CD-ROM entsteht ein Versionschaos; aktualisierte Versionen kollidieren mit „alten“ Fassungen auf CD-ROM. Aus diesem Grunde muß eine strenge Versionskontrolle erfolgen, die ggf. die aktualisierten Inhalte zum erneuten Brennen von Intranet zieht (insbesondere bei geografisch sehr weit
voneinander entfernten Standorten innerhalb eines Firmennetzes ein wichtiger Aspekt) oder aber,
bei nur wenigen oder geringfügigen Änderungen, einfach bei Bedarf diese Änderungen über das Intranet anfordert.
CLIENTPROGRAMMIERUNG
Als letzten Punkt gilt es noch, die Programmierung der Lernumgebung für die Arbeitsplatzrechner zu
optimieren. Für eine flüssige Bildschirmdarstellung sollten Betriebssystemerweiterungen wie DirectX
(Windows 32Bit), QuickDraw (Apple Macintosh) oder OpenGL (verschiedene Betriebssysteme) verwendet werden. Sie können durch Techniken wie Double-Buffering oder das direkte Ansprechen eines Blitters erstens einen flackerfreien Bildschirmaufbau gewährleisten und sind zweitens schneller
als die Standardfunktionen des jeweiligen GUI.
Insgesamt spricht sowohl die Verwendung solcher Spezialerweiterungen als auch die allgemein erreichbare Performance für eine Realisierung der Clients in einer relativ maschinennahen Sprache wie
C++, die Programme trotzdem einigermaßen portabel gestalten kann.
5.7.
ERKENNTNISSE
Fazit des Abschnittes 5
Die Systemanalyse verdichtet sich immer mehr in Richtung Objektorientierung: Sämtliche Medien
können als Objekte aufgefaßt werden, die über übergeordnete, strukturierende Objekte zusammengehalten werden. Der Programmablauf wird ebenfalls über Objekte realisiert, die die verschiedenen
Bereiche des Interaktionsraumes abdecken. Der insgesamt modulare Aufbau des Systems „schreit“
ebenfalls förmlich nach objektorientierten Technologieen.
Das Wort „Elemente“, das ich sehr häufig in diesem Abschnitt verwendet habe, kann ohne weiteres
durch den Begriff „Objekt“ ersetzt werden. Für den eigentlichen Systementwurf bleibt, die hier vorgestellten Strukturen und Elemente in ein Verhältnis zueinander zu bringen, Eigenschaften, Funktionalitäten und Schnittstellen zu definieren bzw. genauer zu spezifizieren, als es in diesem Abschnitt
möglich war. Damit die Angelegenheit nicht zu theoretisch wird, will ich auch die exakten Abläufe
und Vorgänge anhand eines Beispiels beschreiben. Dieses Beispiel wird dann gleichzeitig auch einen
Prototypen definieren, der den hier geschilderten Systementwurf zumindest teilweise umsetzen wird.
Das Intranet erfordert als exzellente Perfomancebremse eine besondere Berücksichtigung – es müssen entsprechende Tricks verwendet werden, um den Lerner nicht allzusehr in Frustration ob der
unmöglichen Ladezeiten von Lernmodulen versinken zu lassen.
Seite 96
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.
Knoten, Links, Netze
Strukturen eines hypermedialen Systems
Dieser Abschnitt beschäftigt sich mit den strukturellen Grundlagen eines jeden hypermedialen Systems. Es wird dargestellt, auf welche Art und Weise komplexe Informationseinheiten miteinander
verknüpft werden können. Aus dieser Betrachtung werde ich direkte Rückschlüsse auf die im vorigen
Abschnitt diskutierten Strukturelemente ziehen. Außerdem nehme ich Stellung zu grundlegenden
Fragen der Navigation und wie sie von einer Lern- und Produktionsumgebung effizient unterstützt
werden können.
Am Ende dieses Abschnittes werde ich konkrete Besipiele für die Umsetzung der bisher dargestellten
Konzepte geben, um die trockene Theorie etwas greifbarer zu machen.
6.1.
GRUNDBAUSTEINE HYPERMEDIALER SYSTEME
Von Knoten, Kanten und Netzen
Zu Beginn dieses Abschnittes möchte ich definieren, aus welchen Grundbausteinen alle hypermedialen Systeme bestehen und diese Bausteine in den Kontext eines objektorientierten Systementwurfs
einordnen. Diese Aspekte werde ich bei der Begründung für die Wahl einer objektorientierten Datenbank dann entsprechend aufgreifen.
6.1.1.
Informationsträger: Knoten
Knoten (engl. nodes) sind die Informationsträger in hypermedialen Systemen. Ein Knoten kann jede
nur vorstellbare Information enthalten – egal, ob es sich um Text, Grafik oder andere multimediale
Daten handelt. [Lechner, 1994[10], S.9f] Knoten können im Sinne der Informatik also als Objekte mit
genau definierten Eigenschaften und Methoden aufgefaßt werden.
Ein Knoten kann andere Knoten enthalten und diese „Kindknoten“ somit organisierend zusammenfassen. [Lechner, 1994[10], S.9f] Softwaretechnisch bedeutet dies, daß die „Information“ eines solchen
zusammenfassenden Knotens zusätzlich zum eigentlichen Inhalt (wenn vorhanden) noch Verweise
(Zeiger) auf die ihm unter- und übergeordneten Knoten enthält.
Kann eine Information nicht weiter unterteilt werden, so wird ein Knoten, der genau diese nicht
mehr teilbare Informationsgrundmenge enthält, als Elementarknoten (oder atomarer Knoten) bezeichnet. [Lechner, 1994[10], S.9f] Für einen objektorientierten Entwurf bedeutet dies, daß die Gesamtmenge der Informationen (Informationsbasis, Domäne; engl. domain) in solche nicht mehr teilbaren Grundelemente zerlegt werden muß. Die Abstraktion dieser Grundelemente ergeben dann die
Klassen eines objektorientierten Systems. So könnte man beispielsweise ein Bild als nicht mehr weiter
teilbares Grundelement auffassen. Dementsprechend enthielte ein objektorientiertes System eine
Bildklasse, von dem dann konkrete Objekte – also die eigentlichen Bilder – gebildet werden können.
Seite 97
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.1.2.
Zusammenhänge: Kanten
Kanten oder Verknüpfungen (engl. links) drücken die Zusammenhänge zwischen den einzelnen Knoten aus. Die Relationen können semantischer, organisierender oder abstrakt-logischer Natur sein.
Links verknüpfen immer zwei Knoten miteinander. Die Kante kann dabei nur in eine Richtung (gerichteter oder unidirektionaler Link) oder aber in beide Richtungen (ungerichteter Link) verweisen.
[Lechner, 1994[10], S.10] Im Sinne der Informatik bedeutet die Verknüpfung zweier Knoten, daß
Verweise in Form von Zeigern auf die betroffenen Knotenobjekte verwendet werden. Bidirektionale
Links können über eine gegenseitige Verzeigerung der betroffenen Knoten realisiert werden.
Navigationstechnisch kann anhand der Links zwischen den einzelnen Knoten hin- und hergesprungen werden – nur wo ein Link ist, ist auch ein Weg. Die Repräsentation eines Links (also das Bedienelement, das einen Sprung/eine Navigation auslöst) wird Anker (engl. anchor) genannt. [Lechner,
1994[10], S.10]
6.1.3.
Ordnung ins System: Strukturen hypermedialer Systeme
Die Art und Weise, wie Knoten über Links miteinander verknüpft werden, ist für die Struktur eines
Lernmoduls entscheidend: Sie bestimmt die Präsentation der Inhalte und ist damit für die Vermittlung des Stoffs mitentscheidend. Lechner (1994[10], S.11ff) definiert folgende Typen:
Tour – die einfache Aneinanderreihung von Knoten. Hiermit können lineare Programmstrukturen
realisiert werden.
hierarchische Struktur – definiert inhaltliche Verhältnisse in Form von Unter- und Überordnung.
Kann beispielsweise zur Gliederung von komplexen Inhalten in mundgerechte Häppchen verwendet werden.
Netzstruktur – bezeichnet die unstrukturierte Verknüpfung von verschiedenen Knoten. Markantestes Beispiel für Netzstrukturen sind Hypertext.
überlagerte Strukturen – Kombination von zwei oder mehreren der Grundstrukturen. So können
lineare Pfade durch eine hierarchisch gegliederte Informationsbasis angelegt werden, die zusätzlich noch über Hyerlinks verfügt.
Eine detaillierte Darstellung (mit zusätzlichen Modellen, die ich in diesem Systementwurf allerdings
nicht berücksichtigen möchte, da sie sich aus den dargestellten Modellen ergeben) findet sich beispielsweise in Lechner (S.11ff).
Letztendlich bestimmen also die Links die Struktur einer hypermedialen Domäne. Sie lassen sich
nach Lechner folgenden strukturellen Bedeutungen zuordnen:
Lineare Links – führen den Benutzer auf einem linearen Weg durch die Domäne.
Hierarchische Links – Auf-/Abwärts-Bewegungen innerhalb der hierarchischen Struktur
Transversale oder Hypertext-Links – verzweigen zu thematisch verwandten (assoziierten) Knoten
Knoteninterne Links – geben bei Aktivierung zusätzliche Information frei („Info-On-Demand“) –
indem beispielsweise ein zusätzlicher Text angezeigt, ein Video abgespielt oder eine Animation
gestartet wird.
6.1.4.
Einordnung in den Gesamtkontext
Was hat das Ganze nun mit Medienelementen, -kapselungen und Strukturelementen zu tun? – Naja,
sehr viel natürlich: Alle Elemente eines objektorientierten Systemes sind Knoten, deren Verhältnis
Seite 98
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
zueinander über Kanten oder Verweise ausgedrückt wird. So kann beispielsweise ein Animationselement als ein Knoten aufgefaßt werden, der auf andere, ihm hierarchisch untergeordnete (Grafik-)
Knoten – also die jeweiligen Phasen – verweist.
Animationsstruktur
von
bis
von
bis
von
bis
Phase 1
von
bis
Phase 3
Phase 2
Phase 4
Interessant ist auch, daß die Verweise nicht nur einen Zeiger auf das verbundene Element darstellen,
sondern noch zusätzliche Informationen in sich tragen können – im Beispiel die Zeiten, von wann bis
wann eine Animationsphase dargestellt werden soll.
6.2.
STRUKTURBÄUME
Hierarchischer Aufbau eines Lernmoduls und einer Lernumgebung
Ich habe also definiert, daß Lernmodule aus Knoten und Verknüpfungen dieser Knoten untereinander bestehen sollen. Doch wie sieht dieses Prinzip konkret aus? Wie kann es auf die komplette Lernumgebung übertragen werden?
6.2.1.
Grundstruktur
Ein Lernmodul ist aufgebaut wie ein Baum (im Sinne der Informatik): Jedes Lernmodul besteht aus
einem Wurzelobjekt, dem alle Knoten/Objekte untergeordnet sind, die für das Lernmodul benötigt
werden.
WURZELN...
Das Wurzelobjekt definiert das Lernmodul – es handelt sich also um ein in Kapitel 5.1.3 definiertes
Lernmodul-Objekt, das um entsprechende Verwaltungsdaten erweitert werden muß.
Diese Verwaltungsdaten bestehen aus einer Liste, die sämtliche Zweige der obersten Ebene (also beispielsweise Seiten-Elemente) beinhaltet.
ZWEIGE
Die Zweige eines Baumes definieren seine Struktur: In meinem System sind auf dieser Ebene deshalb die Strukturelemente angesiedelt. Wie in einem natürlichen Baum auch existieren Äste mit unterschiedlich komplexen Verzweigungen: Manchmal ist bereits nach einer Verästelung Schluß, andere Teile des Baumes sind äußerst komplex vezweigt.
BLÄTTER
Am Ende eines Zweiges befinden sich in der Natur die Blätter – genauso, wie am Ende eines Strukturelementes die Medienelemente (bzw. -kapselungen) stehen, die von der jeweiligen Struktur zusammenghalten und mit Bedeutung gefüllt werden.
Seite 99
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.2.2.
Hierarchien
Die Aufteilung in einen Baum deutet es schon an: Das hier skizzierte System ist ein System mit Überund Unterordnung; an der Spitze des Lernmoduls steht eben ein Element, das dieses Lernmodul charakterisiert und das Verweise auf die ihm untergeordneten Strukturelemente, also beispielsweise Seiten, hat. Diese Strukturelemente können sich wiederum andere Strukturelemente oder Grafikkapselungen „untertan machen“. Diese Unterordnung findet bis in die kleinsten Elemente, also Meidenelemente oder Ablaufschablonen statt.
Global betrachtet sind selbstverständlich nicht die Lernmodule die „Wurzel allen Lernens“, sondern
die Lernumgebung. Das System wird also ein zentrales Lernumgebungsobjekt enthalten, das ausschließlich aus Verweisen auf Lernmodule, Benutzerprofile, Chats und Diskussionsforen besteht (vgl.
Kapitel 3.8.4).
6.2.3.
Die Hackordnung im System
Das System besitzt folgenden hierarchischen Aufbau, der auf den Kapiteln 3.8.4 und 5.1 bis 5.4 basiert. Im Gegensatz zu Kapitel 5.1.1, dessen Strukturmodell sich an der Funktionalität orientiert, liegt
dieser Darstellung das Datenmodell des Systems zugrunde.
Lern- und Produktionsumgebung
Benutzerprofil
Lernerdaten
eMails
Protokolldaten
Kommunikation
Chat
Forum
eMails
eMails
Lernmodul
Strukturelement
Konzeptionselement
Ablaufschablone
Kapselung
Medienelemente
6.2.4.
Querverweise
Querverweise sind Verweise, die aus dem hierarchischen Grundaufbau des Systems herausfallen:
Dies wäre zum Beispiel ein linearer Ablauf, der über Strukturelemente gelegt werden kann, oder innerhalb einer Ablaufschablone ein durch eine Bedingung ausgelöster Programmsprung. Auf konzeptionsebene können durch Querverweise Zusammenhänge zwischen Elementen oder Ebenen ausgedrückt werden. Ein weiterer Fall für Querverweise sind Benutzerprofile, die ja nicht den Lernmodulen untergeordnet sind, sondern diesen nur zur Auswertung „beigefügt“ werden.
6.3.
„WENN EINER EINE REISE TUT...“
Navigation in hypermedialen Systemen
Navigation in hypermedialen Systemen – ganz sicher ein Kapitel für sich: Horden von Kommunikationsdesignern streiten sich um Kommunikationskonzepte, in denen der möglichst effiziente Zugriff
auf meist hierarchisch gegliederte Wissensbasen eindeutig im Mittelpunkt steht.
Seite 100
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.3.1.
Kompaß und Polarstern – Navigationsinstrumente
Es existieren bereits einige sehr gute Arbeiten zum Thema „Navigation in multimedialen Umgebungen“. Beispielhaft möchte ich hier Lechners Arbeit „Ergonomische Navigation in computerbasierten
Informationssystemen“ (1994[10]) nennen. Im aus dieser Arbeit hervorgegangenen CBT „HyperDisc“
des Deutschen Instituts für Fernstudienforschung (1997[7]) steht der Aspekt des „An-die-HandNehmens“ eindeutig im Vordergrund: Die an sich recht konservativ gestalteten Inhalte werden dem
Lerner optimal zugreifbar zur Verfügung gestellt. Der Stoff liegt in Form von Knoten, die ToolBookSeiten referenzieren, vor, die über entsprechende Links in eine hierarchische Kapitelstruktur gegliedert sind; Querverweise sind in Form von Hyperlinks möglich. Auch hier wird die gesamte Aufbereitung der Information von einer (selbstgestrickten) Datenbank-DLL im Hintergrund vorgenommen.
HyperDisc implementiert folgende Aspekte der Navigationsgestaltung.
„Fischaugenbrowser“ – hierarchische Darstellung der Kapitelstruktur mit direkten Sprungmöglichkeiten.
lineare Pfade durch die Informationsbasis – es können verschiedene lineare Abfolgen definiert
werden, die den Stoff beispielsweise unter verschiedenen Gesichtspunkten oder Herangehensweisen in eine jeweils optimale Reihenfolge bringen.
Zusätzliche Infos zu den Knoten – die Darstellung kann so konfiguriert werden, daß verschiedene Zustände – „gesehen“, „in Tour enthalten“, etc. – den Knotennamen in Form von Icons vorangestellt werden.
Bookmarks – an interessanten oder wichtigen Stellen kann sich der Lerner Lesezeichen setzen,
die in eine Bookmarkliste zusammengefaßt und zum direkten Anspringen verwendet werden
können. Zu den einzelnen Bookmarks können Notizen abgelegt werden.
Navigation über eine Volltextsuche – die Inhaltsknoten werden nach eingegebenen Stichworten
durchsucht, die Ergebnisse wieder in Form einer Knotenliste aufbereitet.
Navigation anhand der History – die Reihenfolge der besuchten Knoten kann rückwärts und
vorwärts durchwandert werden oder es können gezielt bereits besuchte Knoten erneut angesprungen werden.
6.3.2.
„Lost in Hyperspace“ vs. „Guided Tour“
HyperDisc beweist also „Führungsqualitäten“, indem es den Lerner an die Hand nimmt und durch
die Wissensbasis leitet. Aber manchmal ist es ja durchaus erwünscht, den Lerner ein wenig im Dunkeln zu lassen: So wird eine Entdeckungsreise ja erst dann so richtig spannend, wenn nicht bereits
auf der Karte das Geheimnis am Ende des Weges verraten wird. Das Unbekannte hat eben auch so
seine Reize, insbesondere fördert es den Motivationfaktor „Neugierde“.
Für ein flexibles System bedeutet dies wieder mal ein „sowohl-als-auch“ – beide Möglichkeiten sollten sich einfach integrieren lassen.
6.3.3.
Automatisierung von Navigationsdesign?
Navigationsdesign ist aber auch auf Produktionsseite ein extrem wichtiger Punkt: Selbst „simple“ lineare Vor- und Rückwärtssprünge können den Programmierer erfahrungsgemäß an den Rand des
Scheiterns bringen; es müssen sehr viele Eventualitäten berücksichtigt werden. So muß beispielsweise
der Bildschirm gemäß des Sprunges neu aufgebaut werden, Elemente müssen korrekt initialisiert
werden, oft sind auch Vor- und Rückwärtspfad nicht identisch.
Seite 101
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
Ein integriertes System kann auch hier Hilfe in Form von Automatisierung bieten: Pfade können über
Strukturelemente gelegt werden, so daß anhand der Top-Level-Strukturelemente (beispielsweise Seiten) ein korrekter Bildschirmaufbau gewährleistet werden kann. Ebenso können über Objektgruppierungen Eigenschaften zugewiesen werden, um unterhalb der Top-Level-Elemente Navigation realisieren zu können. Ich habe die Navigationsinformationen in die Hierarchieinformationen eingeordnet,
da sie zum strukturellen Gesamtkontext eines Lernmodules wesentliche Teile beitragen.
KONKRETE AUSGESTALTUNG DER NAVIGATIONSINFORMATION
Ich möchte auch hier die Ausdetaillierung nicht schuldig bleiben. Die Navigationsinformation basiert
unterhalb des Top-Level-Seitenelementes auf einem Phasenmodell, wobei jede Phase eine konkrete
Einsprungmöglichkeit für andere Strukturelemente oder Ablaufschablonen darstellt.
Eigenschaften: NAVIGATIONSINFORMATIONEN
Verweis auf den lineare Vorgänger-Strukturelement
Verweis auf Vorgänger
Verweis auf das lineare Nachfolge-Strukturelement
Verweis auf Nachfolger
Verweis auf übergeordnetes Sollte das Lernprogramm eine hierarchische Gliederung besitzen,
ist hier der inhaltlich übergeordnete Knoten referenziert. Nicht zu
Element
verwechseln mit der restlichen Hierarchieinfo, die die hierarchischen Verhältnisse auf datentechnischer Ebene festlegt.
Verweise auf untergeordne- Liste mit inhaltlich untergeordneten Knoten. Auch hier: bitte
nicht mit der datentechnischen Hierarchie verwechseln!
te Elemente
Phase des Strukturelementes (Textdefinition + ID), vorangehenPhaseninfo
de Phase (ID), nachfolgende Phase (ID). Vorgänger- und Nachfolgephase werden – wenn möglich – automatisch generiert.
bei dynamischen Strukturen, beispielsweise, wenn in einer Phase
Zeitinformationen
mehrere Phasenanimationen zusammengefaßt sind. Angabe
relativ zur Phase.
Um einen korrekten Bildschirmaufbau und eine korrekte Initialisierung zu gewährleisten, wird bei
einem Sprung zunächst das zugehörige Top-Level-Element gesucht, also besipielsweise die Seite.
Danach müssen alle untergeordneten Elemente, deren Phasen zeitlich vor der darzustellenden Phase
liegen, durchgegangen werden und in ihrem Endzustand dargestellt werden – sie liegen ja vor dem
Einsprungspunkt und müssen sich sozusagen selbst in den abgespielten Zustand versetzen können.
Gleichzeitige und zeitlich nachfolgende Elemente müssen in ihrem Anfangszustand initialisiert werden. Um eine effektive Verwaltung dieses Automatismus‘ zu bieten, müssen entsprechende Funktionalitäten in den Strukturelementen zur Verfügung gestellt werden, die dazu führen, daß entweder
ein Anfangs- oder Endzustand automatisch hergestellt werden kann. Vgl. Abschnitt „Der Systementwurf“.
Inhaltliche Querverweise – also klassische Hyperlinks – werden übrigens über Ablaufschablonen realisiert, die anhand einer Bedingung (Hyperlink angeklickt) direkt auf das Zielelement verweisen. Sie
tragen an sich auch nichts zum strukturellen Kontext eines Moduls bei, so daß ich sie bei der Navigationsinfo nicht berücksichtigt habe.
VARIANTENREICHE NAVIGATION...
Problematisch erscheint die automatisierte Navigation im Zusammenhang mit Varianten: Soll bei einem erneuten Sprung an ein Strukturelement dieses in seinem Urszustand belassen oder mit den in
der Variante abgespeicherten Informationen initialisiert werden? Die Lösung liegt hier wieder in der
Lebensdauer einer Variante: Liegt eine permanente Variante vor, wird diese verwendet. Andernfalls
werden die Ursprungsdaten aus der Datenbank geladen. Für eine Phasenanimation bedeutet dies,
daß eine temporäre Variante zwischen Start und Ende erzeugt wird, so daß beim nächsten Aufruf der
Animation wieder vom Start an begonnen werden kann. Eine Benutzereingabe hingegen kann auch
Seite 102
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
permanent in einer Variante abgelegt werden, so daß sie auch beim nächsten Aufruf des Lernmoduls
an der entsprechenden Stelle übernommen wird.
6.3.4.
Stadtplan & Co.
Neben einer Vereinfachung der Programmierung können natürlich auch Werkzeuge wie die von
HyperDisc zur Verfügung gestellten realisiert werden. Über die hierarchischen Verknüpfungen der
Navigationsinfo können automatisch Karten oder Inhaltsverzeichnisse erstellt werden.
6.4.
BRÜCKENSCHLAG – EINE SYSTEMSTUDIE
Beispiele intranetbasierter Lernmodule
An dieser Stelle ist die Systemstruktur soweit definiert, daß ich meine doch recht abstrakten und theoretischen Ausführungen anhand der folgenden Beispielen visualisieren möchte. Außerdem möchte
ich diese Beispiele dazu nutzen, die Verbindungen zwischen Programm, Drehbuch und Konzeptionselementen ganz konkret und nachvollziehbar darzustellen.
6.4.1.
Aufbau eines einfachen Lernmoduls
Im Folgenden möchte ich den prinzipiellen strukturellen Aufbau eines einfachen Lernmodules als
Menge von Knoten und Verknüpfungen darstellen. Der Übersichtlichkeit halber handelt es sich um
ein sehr einfaches Modul.
Lernmodul
Seite
Seite
Ablauf
Sprung
Sprung
Text
Animation
Grafik
Text
wenn...
dann
Seite
sonst
Seite
Seite
Sprung
Grafik
Programmende
Ablauf
Ablauf
Grafik
Grafik
Grafik
Ablauf
Button
Text
Grafik
Grafik
Sound
Videoseq.
Video
Ablauf
Ablauf
Grafik
Folgende Konstrukte sind interessant:
Navigation (lila Kasten) – es wird eine Ablaufschablone definiert, die ein Mausklick-Ereignis definiert, welches auf das Buttonobjekt und den Zielknoten verweist („bei Klick auf den Button springe zum Zielknoten“).
Phasenanimation (grüner Kasten) – das Ablaufelement reagiert auf das Ereignis „Animation beendet“ und löst dann einen automatischen Seitenwechsel nach dem Aspielen der Sequenz aus.
Seite 103
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
Videosequenz (roter Kasten) – das linke Ablaufelement kann beispielsweise dazu benutzt werden, eine Grafik an einer bestimmten Videoposition ein- oder/und wieder auszublenden. Das
rechte Ablaufelement reagiert wieder auf das Ende des Videos und löst einen automatischen
Sprung zur nächsten Seite aus.
Programmverzweigung (blauer Kasten) – je nach Erfüllung eines „Bedingungsobjektes“ (aus
Gründen der Übersichtlichkeit nicht in der Darstellung enthalten) wird die linke oder die rechte
untergeordnete Seite aufgerufen.
6.4.2.
Phasenanimation konkret
Um einmal einen wirklich konkreten Eindruck einer Ablaufstruktur auf Objektebene zu bekommen,
will ich eine Phasenanimation in ihre Einzelteile zerlegen und diese darstellen.
Ausgangsmaterial ist die folgende Sequenz von Einzelbildern, die zusammen den Eindruck eines aufbrechenden Eis ergeben.
Prinzipiell hätte das Phasenanimations-Strukturelement für diese Animation folgenden Aufbau:
Phasenanim.: Schlüpfendes Küken
Objektinfo
Hierarchieinfo Darstellung
Archivinfo
Varianten
Zusatzinfo
Überarb.info
Ablauf: am Ende weiter
Ereignis
Überarb.info
Varianten
Bezugselement
Archivinfo
Zusatzinfo
Grafikkapselung: Ei, erste Anim.phase
Grafikkapselung: Ei, zweite Anim.phase
Grafikkapselung: Ei, achte Anim.phase
Medienverweis
Medienverweis
Medienverweis
Überarb.info
Varianten
Darstellung
Archivinfo
Zusatzinfo
Varianten
Überarb.info
Darstellung
Archivinfo
Zusatzinfo
...
Überarb.info
Varianten
Darstellung
Archivinfo
Zusatzinfo
Grafik: Ei, erste Animationsphase
Grafik: Ei, zweite Animationsphase
Grafik: Ei, achte Animationsphase
Pixelinfo
Überarb.info
Pixelinfo
Überarb.info
Pixelinfo
Überarb.info
Objektinfo
Varianten
Archivinfo
Zusatzinfo
Objektinfo
Varianten
Archivinfo
Zusatzinfo
Objektinfo
Varianten
Archivinfo
Zusatzinfo
Ich will die konkreten Eigenschaften der einzelnen Elemente an je einem exemplarisch herausgegriffenen Objekt aufzeigen. Dabei gehe ich von der Annahme aus, daß die Animation innerhalb des
Lernprogrammes dazu dient, Grundlagen der objektorientierten Programmierung zu erklären (Ei als
Metapher für Objekt).
Grafikelement: EI, ERSTE ANIMATIONSPHASE
Mediendaten
Seite 104
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
Grafikelement: EI, ERSTE ANIMATIONSPHASE
ID – vom System vergebene, eindeutige Nummer
Objektinfo
Herkunft – 5. Juli 1998, 11.20h
Bearbeitungsstand – ausgearbeitete Fassung des Elementes
Maske:
Farbtiefe – 8 Bit
Palette:
Überarbeitungsinfo
Varianten (perm.)
Archivinformation
Ausmaße – Höhe: 260 Pixel, Breite: 180 Pixel
textuelle Umschreibung – Ei in unversehrtem Zustand. Comicartig aufbereitet.
Farbverlauf von weiß nach gelb; Schatteneffekt am linken unteren „Bauch“.
Datum – 6. Juli 1998, 10.00h
zuletzt bearbeitet – 6. Juli 1998, 10.00h
Bearbeiter – Beta-Tester
Typ – Fehlerbeschreibung
Inhalt – Pixelfehler linke obere Ecke
Entscheidung – wird verbessert
Entscheider – Stefan Grimm
Status – noch zu erledigen
24-Bit-Version:
Titel – Ei, erste Animationsphase
Autor – Stefan Grimm
Umschreibung – unversehrtes Ei
Copyright – HQ Interaktive Mediensysteme GmbH
Themengebiet – Grundlagen objektorientierter Programmierung
Hierarchieinfo – objektorientierte Programmierung, Grundlagen, Demonstration
Schlagwörter – OOP Grundlagen, Eier-Metapher, objektorientierte Technologien
Archivierungsattribute – digitale Endversion
Grafik-Kapselung: EI, ERSTE ANIM.PHASE
Verweis auf die ID des Grafikelements „Ei, erste Animationsphase“ (s.o.)
Verweis
ID – vom System vergebene eindeutige Nummer der Kapselung
Objektinfo
Herkunft – 5. Juli 1998, 22.00h
Ausschnitt – gesamte Grafik21: Start: X - 0, Y - 0; Ausdehnung: Höhe - 260
Darstellungsinfo
Pixel; Breite - 180 Pixel
Position – X - 0, Y - 022
Größe – Höhe - 260 Pixel, Breite - 260 Pixel
Sichtbarkeit – ja
Drag & Drop – keine Drag & Drop-Optionen aktiviert
Hintergrundbild: heiles Ei
Konzeptionsinfo
–
Überarbeitungsinfo
21
Bei entsprechender Definition der Animationsstruktur können für die folgenden Animationsphasen nur die Ausschnitte aus der Basisgrafik
gewählt werden, die sich von Phase zu Phase auch wirklich ändern.
22
Hier relativ zum übergeordneten Strukturelement, also zum Ursprung des Phasenanimationselementes.
Seite 105
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
Grafik-Kapselung: EI, ERSTE ANIM.PHASE
–
Varianten (perm.)
benutzerdefinierte Kennung – Ei, erste Anim.phase
Archivinfo
Beschreibungstext – Erste Phase der Eieranimation; Hintergrundbild
Ablaufschablone: AM ENDE WEITER
Ende der Animation
Ereignis
direkte Programmverzweigung
Reaktion
Verweis auf Struktur XYZ, die nach Ende der Animation angesprungen werden
Bezugselement
soll
Verweis auf die Phasenanimations-Struktur
Zielelement
Name – „am Ende weiter“
Objektinfo
–
Konzeptionsinfo
–
Varianten (perm.)
–
Archivinfo
–
Überarbeitungsinfo
Phasenanimations-Struktur: SCHLÜPFENDES KÜKEN
ID – vom System vergebene eindeutige Nummer des Strukturelementes
Objektinfo
Herkunft – 6. Juli 1998, 00.30h
Bearbeitungsstand – vollständige & ausgearbeitete Fassung des Elementes
Anzahl der Animationsphasen – 8 (incl. Hintergrundbild)
Anzahl der untergeordneten Elemente der nächsten Ebene – 9
Hierarchieinfo
Anzahl der untergeordneten Elemente insgesamt – 17
Verweis auf übergeordneten Knoten – nicht definiert; beispielsweise ein Seitenelement
Position – X - 50; Y - 50 (beliebige Werte)
Darstellung
Größe – Breite - 180 Pixel; Höhe - 260 Pixel
Sichtbarkeit – ja
Sichtbarkeit nach Ende – letzte Phase: die letzte Phase (incl. Hintergrundbild)
bleibt sichtbar.
Hintergrundbild – ja, es wird automatisch die erste Phase definiert
Drag & Drop – keine Drag & Drop-Optionen aktiviert
Verweise auf die Medienelemente – die IDs der Kapselungen aller acht Phasen
Veweise
Verweise auf Ablaufschablonen – die ID der Ablaufschablone „am Ende weiter“
hier nicht definiert; hängt vom Kontext der Phasenanimation ab
Konzeptionsinfo
Datum – 6. Juli 1998, 10.00h
Überarbeitungsinfo
zuletzt bearbeitet – 6. Juli 1998, 10.00h
Bearbeiter – Beta-Tester
Typ – Fehlerbeschreibung
Inhalt – Animation ein Pixel nach links verschiben
Entscheidung – wird verbessert
Entscheider – Stefan Grimm
Status – erledigt
–
Varianten (perm.)
Titel – Schlüpfendes Küken
Archivinformation
Autor – Stefan Grimm
Umschreibung – Das Ei als Metapher für ein Objekt öffnet sich dem Lerner
Copyright – HQ Interaktive Mediensysteme GmbH
Themengebiet – Grundlagen objektorientierter Programmierung
Hierarchieinfo – objektorientierte Programmierung, Grundlagen, Demonstration
Schlagwörter – OOP Grundlagen, Eier-Metapher, objektorientierte Technologien
Archivierungsattribute – digitale Endversion
Seite 106
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.4.3.
Drehbuchansicht am Beispiel
Ich möchte am vorangegangenen Beispiel der Phasenanimation verdeutlichen, wie man sich den Zusammenhang zwischen Drehbuch und Programm vorstellen muß. Hier also die entsprechende
Drehbuchansicht der Phasenanimation...
Strukturen
PHASENANIMATION:
Hintergrundbild:
heiles Ei, dieses bekommt Knackser (7
Phasen).
Ablauf
Ende der Animation:
Sprung zum Strukturelement
„XYZ“
Grafik
Hintergrund:
Ei in unversehrtem Zustand.
Comicartig aufbereitet. Farbverlauf von weiß nach gelb; Schatteneffekt am linken unteren
„Bauch“.
Sound
–
Phasen:
Ei in zunehmend angeknackstem
Stadium.
XYZ:
...
...
...
...
Aus dieser Tabelle lassen sich die Konventionen für die Konzeptionsinfos der entsprechenden Kapselungen und Strukturelemente erkennen: Die Elemente der Strukturspalte sind durch die Eigenschaften des Phasenanimationselementes vorgegeben. Die Bezeichnung „x Phasen“ ist ebenfalls vorgegeben, da sie die Anzahl der Medienelemente definiert, die in der Phasenanimation verwendet werden.
Die Kapselung des Grafikelementes ersten Phase (hier gleichzeitig als Hintergrundbild verwendet) erhält als Konzeptionsinfo die Umschreibung „Hintergrundbild: heiles Ei“ zugewiesen. Das zugrundeligende Grafikelement hat die textuelle Umschreibung „Ei in unversehrtem Zustand. Comicartig ...“.
Die Kapselungen der übrigen Phasen enthalten die Konzeptionsinfo „dieses bekommt Knackser“, die
entsprechenden Grafikelemente die textuelle Umschreibung „Ei in zunehmend angeknackstem Stadium“. Enthalten die einzelnen Phasen unterschiedliche textuelle Umschreibungen, sind diese entsprechend numerisch aufgelistet.
Die Ablaufschablone definiert das Ereignis („Ende der Animation“) und die Aktion („Sprung zu Strukturelement...“. Beide sind gemäß der Funktionalität der Ablaufschablone vorgegeben.
Wenn dies vom Autor so konfiguriert ist, sind sämtliche Elemente anklickbar, worauf sich ein entsprechendes Bearbeitungsmodul öffnet bzw. bei Abläufen die entsprechende Zielstelle im Drehbuch
angeprungen wird.
6.4.4.
Konzeptionselemente
Bisher habe ich die Konzeptionselemente ausgeklammert. Sie stehen sozusagen „neben“ den anderen Elementen und bilden den kreativen Entwicklungsprozeß einer Idee zu den „produktiven“ Elementen ab.
Ich möchte meiner Darstellung wieder das Beispiel der Phasenanimation aus Kapitel 6.4.2 zugrundelegen und zuerst die Minmaps der ersten beiden Ebenen darstellen und diese dann in Datenstrukturen überführen. Ausgangslage der hier beispielhaft dargestellten Konzeption ist, daß ein Lernmodul
Seite 107
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
über objektprogrammierte Programmierung für Studierende der Medieninformatik erstellt werden
soll.
BRAINSTORMING-MINDMAP (KONZEPTIONS-EBENE 1)
Daten
Methoden
Zugriffsrechte
Praxisorientierung
viele Animationen
virtuelle Welt
Ausnutzung von Multimedia
"Infomation-Hiding"
Metapher
Gedanken
aus dem Alltag
Nachvollziehbarkeit
fachliche Relevanz
Objektorientierte Programmierung
Grundlagen
Themengebiete
locker
unterhaltsam
nicht zu tiefgreifend
Praxis (C++)
MI-StudentInnen
Zielgruppe
gewisse Vorkenntnisse
schwer zu definieren
Nebenzielgruppe
Techniken
Interessierte
BRAINSTORMING-MINDMAP23: ZIELE (KONZEPTIONS-EBENE 2)
Grundlagen:
Prinzipien, Aufbau,
Theorieunterbau
Definition
Zielgruppe:
MI-StudentInnen
Interessierte
Verweise von Ebene 1:
Themengebiete,
Zielgruppe
Techniken:
Instanzenbildung,
Vererbung, Polymorphie
Praxis:
Klassenkonzept,
Umsetzung der
Techniken
Inhalte
Übernahme/Verweis,
Ebene 1: Themengebiete
Ziele:
Einführung in
objektorientierte
Programmierung
Unterziele
Grundlagenvermittlung
Problembewußtsein vermitteln
Unterhaltung
23
Verweise innerhalb dieser Konzeptionsebene sind selbstverständlich auch möglich; aus Gründen der Übersichtlichkeit hier allerdings nicht
dargestellt.
Seite 108
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
BRAINSTORMING-MINDMAP: IDEEN (KONZEPTIONS-EBENE 2)
Identifikationsfigur:
„Vermenschlichung“
des Alltagsobjektes
Eigenschaften:
Charakter der
Objektorientierung
treffen
Rahmenhandlung:
Hauptfigur erlebt
themenorientierte
Abenteuer
Metapher:
Objektorientierung
an Alltagsobjekt
Grundstimmung:
OOP ist nicht
schwierig!
Aufbau:
verschiedene Szenen,
inhaltlich unabhängig,
frei zugreifbar
Struktur
Verweis/Übernahme
Ebene 1: Metapher
Ideen:
Gestaltung als
„interaktive Story“
Verweise von Ebene 1:
Metapher, Gedanken, Zielgruppe
Stil
formal:
schnell, comicartig, lässig, hemdsärmelig
inhaltlich:
provokativ, witzig,
unterhaltsam,
trotzdem sachlich
IDEENFINDUNG: METAPHER (TEIL DER EBENE 3)
Wurzel
Baum
Stamm
Zweige
Tastatur
Computer
Alltagsobjekte
Monitor
Zentraleinheit
Dotter
Ei
Schale
Metaphernfindung
Schale verleiht Form und Farbe
Daten
Eigenschaften
Methoden
Kontext
Objekte
Information-Hiding
Vererbbarkeit
Objekthierarchieen
Seite 109
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
AUSGEWÄHLTE DATENSTRUKTUREN
Mindmap-Element: OBJEKTORIENTIERTE PROGRAMMIERUNG (Ebene 1)
Verweis auf Medienelement Zeiger auf Textelement, das die Zeichenfolge „Objektorientierte
Programmierung“ in sich trägt.
Konzeptions-Ebene: Level 1
Hierarchie-Information
Stellung innerhalb der Ebene:
- kein übergeordnetes Element (Wurzelknoten)
- Zeiger auf die Elemente „Metapher“, „Gedanken“, „Themengebiete“ und „Zielgruppe“
–
Querverweise
Themenvorgabe des Lernmoduls
Archivierungsinfo
Datum – 8. Juli 1998, 04.27h
Überarbeitungsinfo
zuletzt bearbeitet – 8. Juli 1998, 05.00h
Bearbeiter – Stefan Grimm
Typ – Kommentar
Inhalt – zur Diskussion freigegeben!
Entscheidung – keine
Entscheider – keiner
Status – keiner
–
Varianten
Mindmap-Element: METAPHER (Ebene 1)
Verweis auf Medienelement Zeiger auf Textelement „Metapher“
Konzeptions-Ebene: Level 1
Hierarchie-Information
Stellung innerhalb der Ebene:
- Zeiger auf Element „Objektorientierte Programmierung“
- Zeiger auf die Elemente „Repräsentation für Objekt“ und
„Verständlichkeit“
Zeiger auf die Elemente „MI-StudentInnen“ (Ebene 1 -> ZielQuerverweise
gruppe) und auf „Metapher“ (Ebene 2).
–
Archivierungsinfo
–
Überarbeitungsinfo
–
Varianten
6.5.
VARIANTEN ZUM ZWEITEN
Die letzten Geheimnisse werden gelüftet
Ganz am Ende dieser Systemkonzeption möchte ich mich noch einmal dem Thema „Varianten“
widmen. Wie sich in diesem und den beiden vorangegangenen Abschnitten immer wieder gezeigt
hat, fallen diesen Elemente die Rolle einer „Vielzweckwaffe“ zu:
Didaktische Funktion: benutzer- und zielgruppenspezifische Inhalte
Ablaufspezifische Funktion: Der komplette automatische Ablauf für mehrere gleichzeitige Benutzer ist über Varianten geregelt.
Programmtechnische Funktion: Anpassungen an heterogene Zielplattformen; sowohl layout- als
auch hardwaretechnisch.
Aufgrund dieser zentralen Stellung möchte ich, das Kapitel „Datenstrukturen“ komplett abschließend, auch dieses letzte noch nur vage definierte Element konkretisieren.
Seite 110
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.5.1.
Charakterisierung
Die Charakterisierung einer Variante – also welches konkrete Element wann eingesetzt wird – ist
zweigeteilt: Zunächst muß eine Schlüsseleigenschaft definiert werden, die die Auswahl bestimmt. Bei
sprachspezifischen Inhalten wäre dies beispielsweise eine Eigenschaft „Sprache“, bei farbtiefenspezifischen Grafiken die Eigenschaft „Farbtiefe“.
In einer Liste mit möglichen Varianten ist dann die von der jeweiligen Variante repräsentierte Ausprägung dieser Schlüsseleigenschaft festgehalten. Es wird diejenige Variante ausgewählt, die der Vorgabe aus der Schlüsseleigenschaft entspricht. Kann keine gefunden werden, wird das Standardelement verwendet.
6.5.2.
Schlüsseleigenschaften
Schlüsseleigenschaften können aus den folgenden Bereichen definiert werden:
beliebige Objekteigenschaften von Benutzerprofilen, Medienelementen und -kapselungen, Ablaufschablonen, Strukturelementen, Lernmodulen, Kommunikationselementen – im Prinzip also
von allen Elementen der Lernumgebung
freidefinierte Objekte, beispielsweise Benutzereigenschaften, Variablenobjekte, Ergebnisse von
Berechnungen, etc.
kontextuelle & technische (System-) Eigenschaften – aktuelles Benutzerprofil, Sprache, Bildschirmauflösung, Farbtiefe, technische Ausstattung des Zielsystems, etc.
6.5.3.
Ausprägungen
Die Definition der Ausprägungen können in der Variante selbst definiert sein (beispielsweise ist bei
einem als Variante definierten Grafikelement ja die Farbtiefe automatisch definiert), oder es müssen
benutzerdefinierte Werte miteingegeben werden – beispielsweise existiert keine TextelementEigenschaft „Sprache“, so daß hier eine entsprechende zusätzliche Information abgelegt werden
müßte.
6.5.4.
Beispiele
Es soll eine farbtiefenunabhängige Grafikdarstellung ermöglicht werden. Die Grundgrafik besitzt eine
Farbtiefe von 8 Bit, es werden Varianten zu 24 und 4 Bit angelegt. Die Schlüsseleigenschaft wäre also
„aktuelle Farbtiefe der Client-Zielplattform“, die zur Laufzeit vom System zur Verfügung gestellt wird.
Stößt das System auf eine solche Grafik, wird zunächst die entsprechende Systemfarbtiefe ermittelt,
dann sämtliche Varianz-Grafiken durchgegangen und die passende ausgewählt. Wird keine passende
gefunden (z.B. bei einer Schwarz-Weiß-Auflösung) wird die Standardgrafik (also 8-Bit) verwendet.
Eine Grafik mit wichtigen (und vor allem geheimen) Geschäftszahlen soll nur dem Personenkreis der
„Manager“ zugänglich gemacht werden. Anderen Personenkreisen soll stattdessen die Geschäftszahlen einer fiktiven Firma präsentiert werden. Letzteres wäre das Medienelement, ersteres die Variante.
Die Schlüsseleigenschaft wäre in diesem Falldas Merkmal „Zielgruppe“ des aktuellen Benutzerprofils.
Trifft das Darstellungsmodul auf eine derartige Grafik, wird anhand des Benutzersprofils entschieden,
ob die fiktiven oder die realen Zahlen gezeigt werden.
Seite 111
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Knoten, Links, Netze – Strukturen eines hypermedialen Systems
6.5.5.
Permanente Varianten
Permanente Varianten dienen zur beständigen Abspeicherung von spezifischen Informationen, also
beispielsweise unterschiedliche Varianten eines Textes oder einer Grafik. Sie werden nur auf ausdrücklichen „Befehl“ des Benutzers, des Programms, des Produzenten oder Lernumgebungsadminstrators angelegt, bearbeitet oder gelöscht.
Eigenschaften: VARIANTEN-INFORMATION
permanent
Typ
Identifizierung der Schlüsseleigenschaft
Schlüsseleigenschaft
Verweise auf die Varianten-Elemente, ggf. mit zusätzlicher InformaListe mit Verweisen
tion bezüglich der Ausprägung der Schlüsseleigenschaft
wer die Varianten-Information löschen, bearbeiten, etc. darf
Zugriffsrechte
6.5.6.
Temporäre Varianten
Temporäre Varianten dienen zur zeitlich begrenzten Abspeicherung von spezifischen Informationen,
also beispielsweise unterschiedliche Varianten eines Textes oder einer Grafik. Sie werden vom System bei Bedarf automatisch angelegt und auch wieder gelöscht – sie dienen dazu, dynamische Prozesse auch im mehrbenutzerbetrieb zu ermöglichen.
Eigenschaften: VARIANTEN-INFORMATION
temporär
Typ
Identifizierung der Schlüsseleigenschaft
Schlüsseleigenschaft
Verweise auf die Varianten-Elemente, ggf. mit zusätzlicher InformaListe mit Verweisen
tion bezüglich der Ausprägung der Schlüsseleigenschaft
Verweis auf ein Element, das als Bezugspunkt verwendet wird,
Lebensdauer
sowie eine Referenzierung innerhalb dieses Elementes (beispielsweise Start und Ende einer Phasenanimation). Dieser Verweis ist
von Elementtyp zu Elementtyp unterschiedlich.
6.6.
FAZIT & FOLGERUNG
Konsequenzen für den Systementwurf
Der komplette Systementwurf wird auf dem hypermedialen Grundprinzip basieren: Sämtliche Elemente können als Knoten aufgefaßt werden, die über Links miteinander verknüpft oder zu Gruppen
zusammengefaßt sind. Dieses Konzept wird sich von der konzeptionellen Phase bis zur Programmproduktion durchziehen. Die hypermediale Struktur stellt aufgrund ihrer Eigenschaften die Forderungen nach Objektorientierung – Knoten und Verknüpfungen können sehr organisch durch Objekte
und Zeiger ausgedrückt werden.
Die Lern- und Produktionsumgebung wird eine hierarchische Struktur besitzen, die in den oberen
Ebenen die Lernumgebung selbst, Lernmodule, Benutzerprofile und Kommunikationsdaten enthält.
Medienelemente bilden die Grundlage, also die untergeordneten Knoten des Systems.
Über diese hierarchische Struktur können noch weitere, inhaltlich begründete hierarchische und lineare Strukturen gelegt werden. Diese Strukturen können zur Automatisierung der Navigation beitragen – eine wichtige Forderung an ein Autorensystem, wie die Praxis zeigt.
Seite 112
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
7.
Die objektorientierte Datenbank
Begriffsklärung und Begründung
Es ist soweit: Nachdem eine Analyse der didaktischen und produktionstechnischen Vorgaben und
wünschenswerten Funktionalität eines intranetbasierten Lernsystems erfolgt ist, muß die technologische Plattform für eine Realisierung festgelegt werden. In der vorliegenden Diplomarbeit wurde dafür
eine objektorientierte Datenbank gewählt. Diese Wahl soll in diesem Abschnitt begründet werden,
indem die didaktischen Anforderungen den technischen Möglichkeiten gegenüber gestellt werden.
Außerdem sollen verschiedene Aspekte des objektorientierten Datenbankansatzes dargestellt werden, welche die technische Umgebung definieren, in die der Systementwurf eingebettet werden
muß.
Übrigens habe ich mich in diesem Abschnitt auf die Grundlagen der Technologie und ihre Bezüge
zum in dieser Arbeit skizzierten System konzentriert. Tiefergehende Erkenntnisse über die
OODBMS24-Technologie (allerdings ohne direkten Bezug auf den Rest des Systementwurfs) bringt
der folgende Abschnitt „Evaluation“.
7.1.
WIESO EINE DATENBANK?
Eine Begründung im Sinne der Informatik
Wie bereits ganz zu Beginn dieser Diplomarbeit dargestellt, verwendet beinahe jedes Computerprogramm zumindest indirekt eine Datenbank: In der „Elektronischen Datenverarbeitung“ geht es darum, anfallende Daten möglichst effizient zu verwalten. Und Datenbanken haben sich für diesen
Zweck als am Geeignetsten erwiesen.
Gemäß des in Kapitel 5.1.1 skizzierten Komponentenentwurfs entspricht die Datenbank also dem
Datenbestand. Außerdem soll die Datenbank möglichst effizient die Verwaltung des Datenbestandes
– sowohl in den Kernkomponenten als auch in den übergeordneten Modulen – übernehmen.
Auch herkömmliche multimediale Entwicklungssysteme verwenden im Hintergrund eine Datenbank,
in der die Mediendaten und ihre Attribute abgelegt sind. Dabei wird allerdings meist auf herstellerspezifische Lösungen zurückgegriffen, die weder richtig portabel noch wirklich modular erweiterbar
sind. Auch die Netzwerkunterstützung ist bestenfalls halbherzig.
7.2.
WIESO OBJEKTORIENTIERUNG?
Relationale vs. objektorientierte Datenbankmodelle
Während die grundsätzliche Entscheidung für ein Datenbanksystem als Grundlage einer multimedialen Umgebung noch ziemlich naheliegend erscheint, wird es bei der Entscheidung für den Datenbanktyp schon diffiziler: Im allgemeinen bieten sich heute drei Arten von Datenbanken an, nämlich
relationale, objektorientierte und objekt-rationale Systeme.
24
Kurform von Object-Oriented Database Modelling System.
Seite 113
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
Nach einem sehr kurz gehaltenen Überblick über die verschiedenen Datenbankansätze möchte ich
die Entscheidung für den objektorientierten Ansatz dann sowohl mediendidaktisch als auch aus Sicht
des Programmierers begründen.
7.2.1.
Definition der drei wichtigsten Datenbanktypen
RELATIONALE DATENBANKEN
Relationale Datenbanken sind aus Tabellen (entities) aufgebaut, die über Schlüssel miteinander verbunden sind: Die Inhalte der jeweiligen Tabellen sind gemäß ihrer Beziehungen (relations) zueinander verknüpft (Entity-Relationship- oder ER-Modell). Diese Verknüpfungen können entweder über
Verweise, die direkt auf den Schlüssel einer anderen Tabelle zeigen, oder aber über eigene Verweistabellen realisiert sein, die die Verknüpfungen der verschiedenen Schlüssel untereinander in Form
einer Matrix enthalten.
Aus Anwender-/Programmierersicht ist eine beliebige relationale Datenbank über die standardisierte
Abfragesprache SQL (Structured Query Language) ansprechbar; die zugrundeliegenden SystemMechanismen werden vor dem Anwender „versteckt“. SQL ist eine universelle deklarative Sprache,
die die Bereiche Datenbankmodellierung25, Datenmanipulation26 und Datenabfrage27 abdeckt.
OBJEKTORIENTIERTE DATENBANKEN
Objektorientierte Datenbanksystem durchbrechen die starre Tabellenstruktur ihrer relationalen Kollegen und legen den zu verwaltenden Daten ein Objektmodell zugrunde. Dieses Modell orientiert
sich an OOP-Sprachen wie C++ und übernimmt von diesen die wichtigsten Eigenschaften – die objektorientierten Grundbegriffe sind im Kapitel 7.4.2 erklärt:
Aufteilung in Klassen und Instanzen dieser Klassen
Vererbung/Ableitung von Klassen
Polymorphie
Verschachtelung über Komponentenobjekte und Objektreferenzen – Objekte müssen andere
Objekte aufnehmen und auf andere Objekte verweisen können.
Verwaltung der Objektidentität – zwei in Struktur und Inhalt völlig identische Objekte müssen
von der Datenbank dennoch unterschieden werden können.
Im Grunde stellen objektorientierte Datenbanksysteme die Fortführung einer objektorientierten Programmiersprache wie C++ auf Massenspeicher dar, indem sie die Klassen einer Datenbank – und
zwar sowohl deren Daten als auch die Methoden – persistent (also dauerhaft) auf dem jeweiligen
Speichermedium verwalten. Dieser Grundfunktionalität fügen sie typische Datenbankfunktionalitäten, beispielsweise mächtige Suchoperationen, hinzu.
Für den Programmierer fügt sich die Datenbank nahtlos in die bestehenden Sprachstrukturen ein: Ein
einmal als persistent definiertes Objekt unterscheidet sich in seiner Handhabung (im Idealfall) durch
nichts von einem „normalen“ Objekt – außer, daß es automatisch in der Datenbank statt im Hauptspeicher verwaltet wird, deshalb auch nach Programmende und -neustart wieder zur Verfügung steht
25
Datenbankmodellierung: Das Schema einer Datenbank, also deren Struktur wird erstellt; die Tabellen mit ihren Spalten sowie die Verknüpfungen der Tabellen untereinander definiert.
26
Datenmanipulation: Die Inhalte der Datenbank werden eingegeben bzw. geändert; entspricht dem Füllen der Tabellenspalten mit Werten.
27
Datenabfrage: Dient zur strukturierten Wiedergewinnung von in der Datenbank enthaltenen Informationen. Hier wäre beispielhaft das
Durchsuchen der Datenbank nach Einträgen zu nennen.
Seite 114
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
– und daß vielseitige, datenbanktypische Such- und Abfragefunktionen (ähnlich SQL) auf die Objekte
angewendet werden können.
Die Beziehungen zwischen den einzelnen Objekten sind nicht wie bei relationalen Datenbanken in
eigenen Tabellen bzw. in Beziehungsobjekten gespeichert, sondern können den jeweiligen Objekten
direkt zugeordnet werden.
Objektorientierte Datenbanken sind also sehr „organische“ Systeme, die dem Entwickler ihm bekannte und effiziente objektorientierte Technologien auf Datenbankebene zur Verfügung stellt.
In der Welt der objektorientierten Datenbanken bemüht sich die Object Data Management Group
(ODMG) um eine Standardisierung, wie sie mit SQL im relationalen Bereich bereits existiert. Im
Moment markiert die ODMG 2.0-Spezifikation vom Juli 1997 den De-facto-Standard für die Programmierung von objektorientierten Datenbanken. [Meier/Wüst, 1997[23], S.11ff]
OBJEKTRELATIONALER ANSATZ
Objektrelationale Datenbanksysteme erweitern die relationale Technologie evolutionär um objektorientierte Modellierungsansätze. Dabei gelten folgende objektorientierten Techniken als Standard
und sollten somit von jedem objekt-relationalen System unterstützt werden:
komplexe Objekte
Objektidentifikationen
erweiterbares Typsystem
Mehrfachvererbung
Polymorphismus (incl. spätes Binden)
benutzerdefinierbare Zugriffsmethoden
Leider beherrschen nicht alle objektrelationalen Systeme diese Grundanforderungen. So scheitert
beispielsweise das bekannte Oracle selbst in der 8er-Version am Polymorphismus, der als eine
Schlüssel-Technologie für objektorientierte Modellierung betrachtet werden kann.
Objektrelationale Datenbanksysteme behalten ihre relationale Eigenschaften und die Abfragesprache
SQL bei. Um eine Standardisierung der objektorientierten Erweiterungen zu erreichen, wird gegenwärtig der SQL3-Standard diskutiert. [Meier/Wüst, 1997[23], S.173] In ihm enthalten sind spezielle
Multimedia-Erweiterungen, die unter dem Begriff SQL-MM zusammengefaßt werden.
7.2.2.
Begründung mit mediendiaktischen Erfordernissen
Im Kapitel „Knoten, Links, Netze“ habe ich die Grundelemente hypermedialer Lernsysteme diskutiert
und bin dabei bereits auf die objektorientierten Entsprechungen der jeweiligen didaktischen Elemente eingegangen. Als Fazit bleibt: Knoten und Links – also die Grundelemente des hier diskutierten
Systems – lassen sich durch Objekte sehr einfach darstellen und effizient verarbeiten. Außerdem
werden sämtliche zur Bearbeitung der Nutzdaten benötigten Methoden dem Knoten-Objekt zugeordnet. Dies möchte ich durch die folgende Abbildung demonstrieren, die darstellt, wie Knoten und
ihre Verknüpfungen zu einem einzigen Objekt zusammengefaßt werden können. Die Nutzdaten
sind in der Abbildung weiß, die Verweise grau und die Programmroutinen schwarz unterlegt.
Seite 115
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
Knoten
Link
Link
Attribute (Knotenname, ...)
Attribute (Linkname, -typ, etc.)
Verweis auf Zielknoten
Attribute (Linkname, -typ, etc.)
Verweis auf Zielknoten
(weitere Links) ...
Klassenmethoden (C++)
Modellierung als Objekt
Anders in der Tabellenform einer relationalen Datenbank: Hier sind aufwendige Hilfskonstrukte in
Form von zusätzlichen Tabellen notwendig, um die Verhältnisse von Knoten und Links auszudrücken. Insbesondere die dritte Normalform steigert die Komplexität eines hypermedialen Systems enorm. In der folgenden Abbildung werden drei Tabellen verwendet, um das gleiche Objekt wie oben
zu modellieren. Die weißen Tabellenteile stellen die Nutzdaten dar, die grau unterlegten definieren
die Verknüpfungsstrukturen der Entitäten miteinander. Wie aus der Abbildung außerdem ersichtlich
ist, werden die Funktionen (schwarz unterlegt), die zur Bearbeitung der Daten notwendig sind, i.a.
von den Daten getrennt vorgehalten und bieten somit keinerlei Kapselungsmöglichkeiten28.
Tabelle mit Knoten
Primärschlüssel
Primärschlüssel
Primärschlüssel
Primärschlüssel
...
Tabelle mit Links
Attribute
Attribute
Attribute
Attribute
Primärschlüssel
Primärschlüssel
Primärschlüssel
Primärschlüssel
...
Attribute
Attribute
Attribute
Attribute
Tabelle mit Relationen
Schlüssel Startknoten
Schlüssel Startknoten
Schlüssel Startknoten
Schlüssel Zielknoten
Schlüssel Zielknoten
Schlüssel Zielknoten
Schlüssel Link
Schlüssel Link
Schlüssel Link
...
Progammfunktionen (SQL/C++) zum Bearbeiten der Tabellen
mögliche Modellierung als relationale Tabellenstruktur (3. Normalform)29
7.2.3.
Begründung aus Sicht des Programmierers
Aus Sicht des Programmierers stellt sich eine objektorientierte Datenbank als homogene Erweiterung
einer bekannten objektorientierten Programmiersprache dar. Er kann so problemlos auch komplexeste Strukturen mit Mehrfachvererbung, Polymorphie oder komplexen Objekten dauerhaft speichern
und verwalten, ohne komplizierte Transformationen vom Tabellen- zum objektorientierten Modell
und zurück durchführen zu müssen. Dies führt zu einer rationelleren Programmierung. Außerdem
können sämtliche Vorteile objektorientierter Programmierung genutzt werden. Hierbei sind insbesondere Aspekte wie Modularität, Erweiterbarkeit oder Qualitätssicherung (fehlerfreiere Programme)
hervorzuheben.
Mit objektorientierten Datenbanken lassen sich also drei der vier Kernkomponenten des Modells aus
Kapitel 5.1.1 homogen als in sich abgeschlossenes Modul nach objektorientierten Prinzipien imple-
28
Die hier gemachten Aussagen treffen in vollem Ausmaß nur auf rein relationale Datenbanksysteme zu – die meisten aktuellen Systeme bieten
ebenfalls objektorientierte SQL-Erweiterungen an (z.B. in Form von sog. „stored procedures“).
29
Hierbei bleibt unberücksichtigt, daß die Tabelle mit den Relationen i.a. selbst noch einen Primärschlüssel beinhaltet. Dieser ist für die Darstellung des Sachverhaltes allerdings nicht relevant und wurde deshalb und aus Gründen der Übersichtlichkeit weggelassen.
Seite 116
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
mentieren; Datenbestand, Zugriffsmethoden und Darstellungsfunktionen können organisch und modular verschmolzen werden. Auf dieses Kernmodul können die übergeordneten Module nach allen
Regeln der objektorientierten Programmierkunst aufgesetzt werden.
Die Objektorientierung ist auch der Grund, warum in meiner bisherigen Ausarbeitung weniger von
objektorientierten Datenbanken als von Datenstrukturen die Rede war – letztlich handelt es sich bei
einer objektorientierten Datenbank um nicht mehr und nicht weniger als eine Sammlung von Datenstrukturen und Methoden, die darauf zugreifen. Die praktischen Aspekte eines objektorientierten
Datenbanksystems werde ich erst ab diesem Abschnitt abhandeln, nachdem die Anforderungen an
eine derartige Lösung endlich klar definiert sind.
7.3.
EINE FRAGE DER ARCHITEKTUR ...
Objektorientierte Datenbanken im Netz
Ich will in diesem Unterkapitel darstellen, wie mögliche Client/Server-Architekturen aussehen können, die als Grundlage einer multimedialen Datenbankarchitektur dienen können.
Prinzipiell können mögliche Intranet-Architekturen darin unterschieden werden, wie viel der Arbeit
vom Client, wie viel vom Server erledigt wird. Dementsprechend werde ich im Folgenden zwischen
„Thin-Client“ und „Fat-Client“-Architektur unterscheiden.
Sämtliche Funktionalitäten, die zur Darstellung der Inhalte benötigt werden, können mit dem Begriff
„Frontend“ bezeichnet werden. Die Programmlogik, der Datenbankzugriff und die Datenbank selber
sind unter dem Begriff Backend zusammengefaßt.
7.3.1.
Two-Tier-Architektur
Diese auch als Fat-Client bezeichnete Architektur basiert auf zwei Säulen: Dem Datenbankserver
und dem Clientmodul.
Daten/Objekte
DB-Server
Workstation mit Clientmodul
DATENBANKSERVER
Der Datenbankserver hält sämtliche Daten zentral (Programmstruktur und Medien, nicht aber Klassenmethoden) vor. Optional kann das verwendete Datenbank die Möglichkeit unterstützen, die Daten auf mehrere Datenbankserver zu verteilen (Crossdatabase-Referenzen).
Seite 117
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
CLIENTMODUL
Das Clientmodul übernimmt die komplette Programmlogik, die Verarbeitung von Benutzerinteraktionen und das Darstellen der Inhalte. Dazu fordert es bei Bedarf die notwendigen Daten vom Datenbankserver an. Im Clientmodul sind sämtliche Klassenmethoden der Datenbankobjekte enthalten.
Bei der Two-Tier-Architektur sind im Clientmodul also sowohl Backend- als auch Frontendfunktionalitäten enthalten. Die Kommunikation kann über eigene Schnittstellenprotokolle realisiert werden,
die allerdings auf gängigen Standards basieren sollten.
7.3.2.
Three-Tier-Architektur
Die Thin-Client- oder Three-Tier-Architektur basiert auf drei Säulen: Dem Datenbankserver, einem
Applikationsserver und einem Client-Frontend.
Daten/Objekte
DB-Server
Dokumente
Applikationsserver
Workstation mit Frontend
DATENBANKSERVER
Auch in diesem Modell halten ein oder mehrere Datenbankserver sämtliche Daten zentral vor.
APPLIKATIONSSERVER
In einem Three-Tier-System dient der Applikationsserver als Zwischenstück, der die Daten des Datenbankservers in clientgerechte Häppchen aufbereitet. Dazu übernimmt er sämtliche Datenbankzugriffe und gibt die aufbereiteten Daten in einem exakt festgelegten Protokoll an das ClientFrontend weiter. Außerdem übernimmt der Applikationsserver die Verwaltung von Benutzerinteraktionen und damit auch die Programmlogik.
Die Rolle eines Applikationsservers kann bei Three-Tier-Architekturen beipielsweise von einem Webserver übernommen werden, der die Inhalte in HTML-Seiten aufbereitet.
CLIENT-FRONTEND
Das Client-Frontend übernimmt ausschließlich das Darstellen der Inhalte und das Weitermelden von
Benutzerinteraktionen an den Applikationsserver über die entsprechenden Schnittstellen.
Seite 118
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
In einem webbasierten System könnte beispielsweise einer der gängigen Web-Browser, evt. mit zusätzlichen Plug-Ins und Java-Applets, als Client-Frontend dienen. Als Schnittstellenprotokolle wären
beispielsweise die Webstandards CGI30, ISAPI oder NSAPI31 denkbar.
7.3.3.
Bewertung
Jede der vorgestellten Architekturen hat Vor- und Nachteile: Two-Tier-Architekturen können Netz
und Server entlasten, da die Hauptarbeit auf dem Clientrechner erledigt wird. Dafür wird für jeden
Arbeitsplatz eine eigene Client-Lizenz benötigt (vgl. Kapitel 7.6).
Die Three-Tier-Architektur hingegen benötigt auf den Arbeitsplatzrechnern keine Client-Lizenzen –
dafür wird die komplette Aufbereitung der Inhalte auf den Applikationsserver abgeschoben. Dieser
läuft daher in die Gefahr, relativ schnell überlastet zu werden. Andererseits kann durch das Einrichten weiterer Applikationsserver (vgl. Skalierbarkeit, Kapitel 7.4.6) das System entlastet werden.
Die Architektur spielt beispielsweise bei der Auswahl des Servertyps eine entscheidende Rolle – vgl.
Kapitel 8.4.1.
7.4.
ATTRIBUTE, METHODEN, POLYMORPHIE, ...
Eigenschaften objektorientierter Datenbanken
Objektorientierte Datenbanken bauen auf den bewährten Konzepten objektorientierter Modellierung und objektorientierten Systemdesigns auf. Ich will die entsprechenden Konzepte hier kurz darstellen, soweit sie den Systementwurf betreffen. Außerdem werde ich auf weitere Aspekte, die Datenbanken betreffen und die in den Systementwurf eingeflossen sind, eingehen.
7.4.1.
Modellierung
Ein guter Teil dieser Diplomarbeit beschäftigt sich mit der Modellierung der dem ganzen System
zugrundeliegenden Datenbank.
Die Modellierung einer objektorientierten Datenbank erfolgt äquvalent zum Entwurf eines allgemeinen objektorientierten Systems. Als Standard existiert UML (Unified Modelling Language) – eine
„Sprache“, die eine grafische Modellierung und Darstellung der verwendeten Klassen und ihrer Beziehung untereinander unterstützt. Die entsprechenden Entwürfe lassen sich direkt in Strukturen der
verwendeten Programmiersprache überführen.
Leider ist der hier vorgestellte Systementwurf noch nicht konkret genug, um bereits mit UML ausmodelliert zu werden. Dies wäre der nächste Schritt, wenn es um die Feinkonzeptionierung einzelner
Komponenten ginge.
30
Common Gateway Interface – standardisiertes Kommunikationsprotokoll zwischen Client und Server
31
ISAPI und NSAPI sind die – performanceoptimierten – Gegenstücke zu CGI, die nur auf den entsprechenden Servern von Microsoft respektive Netscape funktionieren.
Seite 119
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
7.4.2.
Objektorientierte Technologien
Der in dieser Arbeit diskutierte Systementwurf wird von einigen objektorientierten Techniken intensiven Gerauch machen. Aus diesem Grunde möchte ich diese Basistechniken hier kurz vorstellen
und in einen ersten Zusammenhang zum späteren Systementwurf bringen.
DAS OBJEKT
Alle modernen Softwareentwürfe verwenden die Objekt-Metapher: Daten und Methoden, die diese
Daten verarbeiten und für andere Objekte zugreifbar machen, werden zu Objekten zusammengefaßt. Die Struktur eines Objektes – also die Definition der enthaltenen Daten und Methoden – wird
als Klasse bezeichnet. Alle strukturell gleichartigen Objekte sind Instanzen einer Klasse.
Die Daten werden auch als Attribute oder Eigenschaften bezeichnet und sind Träger der eigentlichen
Informationen. Idealerweise dürfen die Daten nur von den Klassenmethoden verarbeitet oder verändert werden (Prinzip des „Information Hiding“). Ein Zugriff aus anderen Objekten oder Klassen sollte
im Sinne eines sauberen Programmierstils tunlichst vermieden werden.
MENGEN
Mengen sind Ansammlungen von Elementen. Die Datenbank muß entsprechende Funktionalitäten
zum Anlegen, Verwalten und Löschen zur Verfügung stellen. Der ODMG-Standard definiert verschiedene Arten von Mengen – vgl. Schader (1997[26], S.13f).
VERERBUNG
Die objektorientierte Technologie der Vererbung ermöglicht es, semantische Beziehungen der Art „B
ist ein spezielles A“ auf eine sehr elegante Art und Weise auszudrücken. Für eine multimediale Datenbank bedeutet dies, daß die unterschiedlichen Medientypen alle von einer einzigen Mediengrundklasse abgeleitet werden können. So wäre dann zum Beispiel eine Grafik eine spezielle Ausformung, die die allgemeinen Attribute eines Mediums übernimmt und ihnen die speziellen Eigenschaften (und Methoden) einer Grafik (z.B. Bilddaten, Bildgröße, Farbtiefe, usw.) hinzufügt. Selbstverständlich können so ganze „Erbhierarchien“ aufgebaut werden.
Verschiedene objektorientierte Programmiersprachen (beispielsweise C++) unterstützen neben der
einfachen Vererbung („B ist ein spezielles A“) auch noch das Konzept der Mehrfachvererbung („C ist
ein spezielles A und ein spezielles B“). Die Mehrfachvererbung ist allerdings mit Vorsicht zu genießen, da sie nicht von allen objektorientierten Sprachen unterstützt wird. Dieser Aspekt ist insbesondere im Zusammenhang mit der Forderung nach Sprachunabhängigkeit (vgl. Kapitel 7.4.5) zu beachten.
Der unschätzbare Vorteil der Vererbung – insbesondere in Verbindung mit der Polymorphie – ist die
außerordentlich einfache Erweiterbarkeit eines entsprechenden Systementwurfs: Soll ein neuer Medientyp integriert werden, muß nur die entsprechende, von der Basisklasse abgeleitete Medienklasse
realisiert und „bekanntgegeben“ werden – ansonsten sind bei einem entsprechend angelegten Softwaredesign keine weiteren Programmanpassungen vorzunehmen!
Seite 120
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
POLYMORPHIE
Als zentraler Vorteil objektorientierter Programmiertechniken für eine multimediale Datenbank wird
sich die Polymorphie32 erweisen: Durch sie können die unterschiedlichen Medientypen von einer
Medien-Grundklasse abgeleitet werden und trotzdem einheitlich angesprochen werden – das Programm sucht sich automatisch die zum konkreten Medientyp passende Methode aus.
Dieser Mechanismus ist für die Erweiterbarkeit einer Datenbank entscheidend: Durch die automatische Suche nach der richtigen Methode können auch „unbekannte“, also erst später definierte, von
der Basisklasse abgeleitete Klassen angesprochen werden, ohne daß Programmanpassung notwendig
wären.
7.4.3.
Schema-Evolution
Der Autor hat eine schöne Idee („Könnten wir nicht. ...?“), die mit dem bisherigen System nicht umsetzbar ist (vgl. Kapitel 5.2.7). Eine Erweiterung steht also an, bestehende Datenklassen müssen verändert, neue hinzugefügt werden. Aber: Da das System bereits im Einsatz ist, dürfen die bestehenden Daten nicht verlorengehen. Die Lösung nennt sich „Schema-Evolution“ – alle Objekte, die von
den Veränderungen betroffen sind, werden automatisch angepaßt, indem
neu hinzugekommene Klassenvariablen in bestehenden Objekten hinzugefügt und mit Standardwerten oder mit vom Programmentwickler vorgesehenen Inhalten initialisiert werden
obsolet gewordene Klassenvariablen aus bestehenden Objekten entfernt werden
Die Klassenmethoden müssen aufgrund der physikalischen Struktur einer objektorientierten Datenbank durch eine Neukompilierung der C++-Projekte angepaßt werden – vgl. Kapitel 7.4.5. Idealerweise funktioniert die Schema-Evolution ohne eine „Offline“-Schaltung der Datenbank, also bei laufendem Betrieb.
7.4.4.
Fehlertoleranz
Wir befinden uns im Authoring-Prozeß: Schnell noch eine Änderung im „letzten Textfragment links
unten“ gemacht, den Update-Befehl auf die Datenbank abgeschickt – und das gesamte System stürzt
ab! Zwar wurde das eigentliche Textfragment bereits in der Datenbank aktualisiert, nicht aber die
Verweise darauf. Die Datenbank verbleibt in einem inkonsistenten Zustand, Folgefehler und Instabilitäten werden mit an Sicherheit grenzender Wahrscheinlichkeit auftreten.
Um derartige „Horrorszenarien“ zu vermeiden, existieren sogenannte Transaktionsmechanismen:
Vor Beginn einer Änderung an der Datenbank wird ihr dieser Änderungswunsch mitgeteilt. Sämtliche
Änderungen werden nun in einem temporären Buffer statt in der Datenbank direkt vorgenommen.
Sind sämtliche Änderungen erfolgt, wird die Transaktion für beendet erklärt – und die Datenbank
übernimmt sämtliche Änderungen auf einmal. Tritt während der Änderungen ein Fehler auf, verbleibt die Datenbank in ihrem alten Zustand, die Änderungen werden verworfen. Dies entspricht
dem Prinzip, daß Änderungen innerhalb einer Sequenz ganz oder gar nicht ausgeführt werden sollen. Die entsprechenden Mechanismen für den Fehlerfall werden als „Rollback“-Mechanismen bezeichnet.
32
Polymorphie wird von Langenscheidts Fremdwörterbuch[44] als „Vielgestaltigkeit, Verschiedengestaltigkeit“ umschrieben.
Seite 121
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
Transaktionsmechanismen sollten die folgenden Bedingungen erfüllen, die auch als ACID-Prinzip bezeichnet werden [Blummer, 1997[21], S.285]:
atomarer Charakter: Das bereits erwähnte „Ganz-oder-gar-nicht“-Prinzip.
Konsistenz: Die Datenbank wird immer in einem schlüssigen, fehlerfreien Zustand gehalten.
Isolation: Jede Transaktion ist von anderen völlig unabhängig.
Dauerhaftigkeit: Bei Erfolg einer Transaktion werden die Änderungen dauerhaft übernommen.
Weiterführendes zu Transaktionen und der zugrundeliegenden Technologie, den Sperren, in Kapitel
8.1.1.
7.4.5.
Sprachunabhängigkeit
Sprachunabhängigkeit bedeutet, daß die Objekte auch von Programmen, die in anderen Sprachen
als der Objekterzeuger geschrieben wurden, gelesen und verarbeitet werden können: Selbst wenn
die Datenobjekte von einem C++-Modul angelegt wurden, sollten sie von einem Java-Client-Modul
gelesen und dargestellt werden können.
Es gibt zwei Arten von Sprachenunabhängigkeit:
Strukturbasierte Sprachunabhängigkeit: Die Eigenschaften und Attribute der Objekte können
von jeder Sprache, die von dem Datenbanksystem unterstützt wird, erzeugt, gelesen und verarbeitet werden. Die Methoden allerdings müssen in jeder Sprache neu programmiert werden.
Verhaltensbasierte Sprachunabhängigkeit: Bei der verhaltensbasierten Sprachunabhängigkeit
sind sowohl Daten als auch Methoden von der Sprache der zugreifenden Anwendungen unabhängig.
Die Sprachunabhängigkeit ist insbesondere deshalb schwierig zu gewährleisten, da nicht alle Sprachen die selben objektorientierten Techniken unterstützen. So kennen Smalltalk und Java beispielsweise keine Mehrfachvererbung, während dieses Konzept unter C++ voll unterstützt wird. Andererseits existieren bei den sogenannten dynamischen Sprachen“ (eben Java oder Smalltalk) Konzepte
wie der Garbage Collector, der für ein automatisches „Aufräumen“ nicht mehr referenzierter Objekte
sorgt, oder eine andere Form der Zeigerimplementierung, die in C++ unbekannt sind. All diese Unterschiede stellen hohe Anforderungen an ein Datenbanksystem.
7.4.6.
Skalierbarkeit
Ein weiterer wichtiger Punkt ist die Skalierbarkeit von Datenbankanwendungen: Reicht die Kapazität
eines Servers nicht aus, muß ein zweiter eingerichtet werden können, der den ersten entlastet.
Bei objektorientierten Datenbanken ist deshalb oft ein Feature enthalten, das sich Cross-DatabaseReferenzen nennt: Ein Objekt kann Verweise auf Objekte enthalten, die in einer anderen Datenbank
auf einem beliebigen anderen Server abgelegt sind. So kann eine große Datenbank auf mehrere kleine, die auch auf unterschiedlichen Servern abgelegt sein können, aufgeteilt werden. Idealerweise
findet das Datenbanksystem selbständig den Server, auf dem ein Objekt tatsächlich abgelegt ist, ohne
daß sich das Anwendungsprogramm explizit darum kümmern muß.
Ähnlich kann bei einer Three-Tier-Architektur die Aufbereitung der Daten auf mehrere Applikationsserver verteilt werden – so könnte beispielsweise jede Abteilung in einem Großunternehmen seinen
eigenen Webserver erhalten, um dieses Nadelöhr so durchlässig als nur möglich zu gestalten.
Seite 122
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
7.4.7.
Physikalische Datenbankstruktur
Die bisherigen Darstellungen haben sich immer auf die Sicht des Programmentwicklers bezogen, der
eine Datenbank mehr oder weniger als „black box“ verwenden und sich nicht um die Mechanismen,
die sich „im Hintergrund“ abspielen, kümmern will. Im Hinblick auf die folgende Diskussion möglicher Intranet Architekturen in Kapitel 7.3 möchte ich an dieser Stelle dennoch einen Blick „unter die
Haube“ einer objektorientierten Datenbank werfen.
Die hier getätigten Aussagen orientieren sich an einer Analyse von Programmierumgebung und Dateien des Datenbanksystems POET. Die Kurzanalyse anderer Systeme zeigt aber, daß diese bei der
Aufteilung von Daten und Methoden gleich oder zumindest ähnlich vorgehen.
Dem C++-Entwickler präsentiert sich eine objektorientierte Datenbank als homogene Erweiterung
seines bekannten Sprach-Universums: Er fügt seinem konventionellen Programmcode nur einige wenige Zeilen hinzu – schon sind seine Objekte mitsamt ihren Verknüpfungen auf einem Massenspeicher gespeichert und können von diesem Massenspeicher problemlos wieder eingelesen werden. Da
die objektorientierte Metapher der Datenkapselung erhalten bleibt, werden aus Entwicklersicht sowohl Methoden als auch die Daten auf Platte geschrieben.
Dem ist allerdings nicht so: Da die Klassenmethoden für alle Instanzen einer Klasse identisch sind,
werden nur die Daten selbst in der Datenbank vorgehalten. Die Methoden werden dem Anwendungsprogramm (oder der Serverapplikation) hinzugefügt, ohne daß der Programmierer dies bemerken würde oder daß es für ihn von direkter Bedeutung wäre.
Für den Programmierer ist diese Tatsache dann an sich unerheblich, nicht aber für eine netzbasierte
Systemarchitektur: Die Trennung von Code und Daten bedingt nämlich, daß
1. der Umfang der Clients33 größer wird – schließlich müssen die entsprechenden Module zum
Zugriff auf den Datenbankserver im Client vorgehalten werden
2. andererseits das Netz entlastet wird, da die Methoden nicht explizit übertragen werden müssen
3. jeder Client, der Zugriff auf den Datenbankserver haben soll, eine eigene Zugriffssoftware („DBRuntime“) benötigt.
Diese Erkenntnisse spielen eine wichtige Rolle bei der Wahl der Intranet-Architektur für das System –
der ökonomische Aufwand für die Lizenzierung der Clients muß den Performanceeinbußen einer
solchen Thin-Client-Umgebung und evt. Einschränkungen der Darstellungsmöglichkeiten (bei HTMLbasierten Systemen) entgegengestellt werden.
Eine weiterer wichtiger Aspekt der Aufteilung in Daten (Server) und ausgelagerte Methoden (Client):
Dank Schema-Evolution kann auf dem Datenbankserver eine andere Version der Datenbank vorliegen als die Zugriffsmethoden auf den Clients voraussetzen. Dies könnte fatale Folgen haben. Aus diesen Gründen ist eine Versionsverwaltung integriert, die derartige Inkonsistenzen vermeiden hilft: Bei
inkompatiblen Daten und Methoden löst die Datenbank einen Fehler aus.
7.4.8.
Optimierungsmöglichkeiten
Datenbanksysteme bieten einige Optimierungsmöglichkeiten außer dem Verteilen auf mehrere Datenbankserver. Ich will zwei hier andiskutieren: Clusterbildung und Indizierung. [vgl. Meier/Wüst,
1997[23], S.137ff]
33
Ich verstehe in diesem Falle unter „Client“ nur die Software, die auf den Datenbankserver zugreift. Dieser Client kann bei Three-TierArchitekturen aber auch als sog. Middleware auf dem Anwendungsserver laufen (und somit selbst zum Server werden).
Seite 123
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
CLUSTERBILDUNG
Unter Clusterbildung versteht man eine Effizienzsteigerung durch die Optimierung der physikalischen
Objekt-Anordnung auf dem Massenspeicher. Dabei wird berücksichtigt, daß Objekte meist nicht
einzeln vom physikalischen Datenträger gelesen werden, sondern immer noch auch Objekte und
Objektteile davor und danach (Seiten-Caching; vgl. auch Kapitel 8.1.1).
Sind die Objekte nun so auf der Platte verteilt, daß voneinader abhängige (also referenzierte) Objekte direkt hintereinander liegen, können die (langsamen) Zugriffe auf den Datenträger minimiert werden. Konkrete Entwurfskriterien für Cluster finden sich in Meier/Wüst (1997[23], S.138).
INDIZIERUNG
Indizes beschleunigen den Zugriff auf einzelne Objekte oder Objektmengen: Durch das Anlegen von
zusätzlichen Datenstrukturen mit Informationen über die Lage von bestimmten Informationen können Datenbasen schneller und effizienter durchforstet werden, als wenn jedes Objekt einzeln bearbeitet werden müßte. Legt man beispielsweise einen Index für ein Attribut an, welches das Erstellungsdatum eines Medienelementes ausdrückt, können schnell Aussagen wie „vor dem 23.7.1998“
oder „heute erstellt“ beantwortet werden.
7.4.9.
Datenbankpflege
Zur Pflege einer Datenbank müssen entsprechende Tools zur Verfügung gestellt werden: Die Objekte müssen im Falle eines Systemcrashes wiederhergestellt werden können, Indizes müssen aktualisiert
bzw. neu festgelegt werden können. Außerdem sollten allgemeine Reorganisationen (z.B. das physikalische Vernichten gelöschter Objekte oder die Optimierung von Datenbankstrukturen) mit entsprechenden Tools ausgeführt werden können.
Im Hinblick auf Datensicherheit sind ausgefeilte Backup-Lösungen erforderlich, die neben dem VollBackup auch inkrementelle Sicherung – nur Änderungen zum letzten Backup werden archiviert –
ermöglichen.
Im Idealfall existieren neben den GUI-basierten Benutzertools auch entsprechende APIs, so daß die
Tools auch vollautomatisch von Anwendungen angesprochen werden können.
7.5.
VIELE MEDIENPLATTFORMEN, EIN PROGRAMM
Cross-Media Produktion
Ein weiteres aktuelles Problem für Multimedia-Produzenten: Programme sollen sowohl auf dem Intranet als auch Offline, also beispielsweise von CD-ROM, rezipierbar sein. Auch aus mediendidaktischer Sicht ist die mögliche Loslösung eines Lernmodules aus der Lernumgebung im Sinne des
selbstorganisierten Lernens interessant (vgl. Kapitel 3.7.5). Doch für jedes Medium ein neues Programm zu produzieren, ist ineffizient und teuer. Das Prinzip des „Cross-Media-Publishing“ (vgl.
Screen Multimedia, 1/98[36], S.16ff) verspricht Lösungen, indem es ohne größeren Aufwand die
grundlegenden Daten und Programmstrukturen für beliebige Plattformen verwenden kann.
„Cross-Media-Publishing“ ist also nicht nur eines dieser beliebten neuen Modeworte, sondern bietet
sowohl aus Sicht der Produktion als auch der Didaktik greifbare Vorteile – deshalb stelle ich in diesem Kapitel die Frage, wie eine objektorientierte Datenbank dieses Vorhaben unterstützen kann.
Seite 124
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
7.5.1.
Daten sind Daten sind Daten sind ...
Ob ein Programm von CD-ROM abgespielt werden soll, ob es über das Firmennetz rezipiert oder gar
eine der Interaktivität beraubte Print-Version erstellt werden soll: Die zugrundeliegenden Daten bleiben immer gleich und können prinzipiell von der Abspielplattform unabhängig verwendet werden.
Was hingegen von Plattform zu Plattform geändert werden muß, sind die Abspielprogramme: Für eine CD-ROM-Version kann beispielsweise eine EXE-Datei realisiert werden, die über eine Single-User
DB-Runtime die Daten von der Datenbank anfordert, aufbereitet und dann entsprechend darstellt.
Bei einer HTML-basierten Intranetumgebung kann diese Aufgabe beispielsweise von einem JavaApplet übernommen werden. Was sich ebenfalls ändert, sind die Schnittstellenprotokolle, also die
Aufbereitung der Benutzerinteraktionen.
Technisch sind die hier geschilderten Vorgänge kein Problem. Es muß allerdings für jede zu unterstützende Medienplattform ein eigener Viewer realisiert werden. Außerdem muß die Unabhängigkeit
von der Medienplattform beim Systementwurf entsprechend berücksichtigt werden: Bei einer Lösung
über ein HTML-Konzept müssen beispielsweise die eingeschränkten Layoutfähigkeiten beachtet und
ein Konvertermodul integriert werden, das Grafikfremdformate in GIF- oder JPG-Dateien aufbereiten
kann. Plattformspezifische Layouts wiederum sind ein weiterer Fall für Varianten.
7.5.2.
Integriertes „Offline-Lernen“?
Technisch ist das Crossmedia-Publishing also weniger ein Problem – allerdings gehen mit dem Verlassen der Netzwerk-Umgebung sämtliche speziellen Features verloren.
Andererseits kann dem Lerner auf seinem Privatrechner auch eine komplette Lernumgebung – ohne
intranetspezifische Kommunikationsmöglichkeiten – angeboten werden. Idealerweise können der
Datenbestand von Intranet-Arbeitsplatz und privater Lernumgebung abgeglichen werden, so daß beispielsweise benutzerspezifische Varianten oder Notizen nicht verlorengehen.
Insgesamt gesehen sollte der Lerner auch bei der Benutzung am eigenen PC möglichst alle nichtnetzabhängigen Features nutzen können.
7.6.
ACHTUNG, STOLPERSTEIN!
Ökonomische Anmerkung zu Datenbanken
Friede, Freude, Eierkuchen – so scheint sich die Datenbankwelt bisher für meinen Systementwurf zu
präsentieren. Doch die ganze Sache hat leider noch einen ganz gewaltigen Haken: Datenbanken
sind High-Tech. Und dafür zahlt man dann eben auch entsprechend...
Als Vergleich seien hier die Preise34 verschiedener intranetfähiger relationaler und objektorientierter
Datenbanksysteme genannt:
34
Quellen: SQL-Server: Programmer’s Paradise (www.pparadise.de); Poet: Poet GmbH, Hamburg; O2: O2 Technology GmbH, Dortmund.
Seite 125
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Die objektorientierte Datenbank – Begriffsklärung und Begründung
System
Microsoft SQL-Server
(relationales System)
POET 5.0.2
(objektorientiertes System)
O2
(objektorientiertes System)
Preise (incl. 16% MWSt)
Server-Lizenz:
2.612,00 DM
Client-Lizenzen:
230,99 DM
SDKs:
–
Server-Lizenz:
8.700,00 DM
Client-Lizenzen:
284,20 DM
SDKs (je):
2.900,00 DM
Server-Lizenz:
6.960,00 DM
Client-Lizenzen:
k.a.
SDKs (je):
6.960,00 DM
Insbesondere die Tatsache, daß für jeden Arbeitsplatz eine eigene, nicht ganz billige Lizenz gekauft
werden muß, ist für Produktionsfirmen wie HQ ein entscheidender Pferdefuß der gesamten Datenbanktechnologie, da die Produktmargen deutlich verringert werden.
Mögliche Lösungen für dieses Problem sind Three-Tier-Architekturen, die ja den gesamten Datenbankzugriff auf den Web-Server verlegen, so daß nur eine vergleichsweise geringe Anzahl von Clients
für das komplette System benötigt wird.
Für Crossmedia-Produktionen wiederum sind Systeme wie ObjectStore interessant, die eine auch für
kommerzielle Zwecke kostenlose Single-User Runtime-Version zur Verfügung stellen. Deren Einschränkungen (keine Transaktionen und keine Schema-Evolution) sind für Single-User-Umgebungen
(also beispielsweise CD-ROM-Varianten), in denen die Datenbank nur lesend als Abspiel-Backend
verwendet wird, unerheblich.
7.7.
FAZIT & WEITERFÜHRENDES
Literatur zum Thema
Dieser Abschnitt sollte den Zweck erfüllen, dem Leser einen Überblick über die grundlegende Technologie objektorientierter Datenbanken zu geben. Ich habe die wichtigsten Funktionalitäten aufgezeigt und immer versucht, den entsprechenden Nutzen für das in dieser Arbeit akizzierte System aufzuzeigen.
Für einen tiefgreifenden Einstieg seien die Handbücher verschiedener Systeme oder die unten angeführten Bücher empfohlen. Ich werde mich aber im folgenden Abschnitt ebenfalls tiefer mit der Materie beschäftigen, soweit dies für die Evaluation der Systeme notwendig sein wird.
Eine sehr ausführliche und tiefgreifende Darstellung der Thematik „objektorientierte Datenbanken“
findet sich in Heuer (1996[22]). Hier wird auch ausführlich auf die Abgrenzung zwischen relationalen
und objektorientierten Systemen eingegangen. Zusätzlich ist auch eine Kurzdarstellung des relationalen Modells enthalten.
Für eine kompaktere, sehr verständliche Darstellung der objektorientierten Datenbanktechnologie
können Meier/Wüst (1996[23]) herangezogen werden. Eine praxisorientierte Einführung anhand des
ODMG-C++-Sprachstandards findet sich in Schader (1997[26]).
Grundlegende Begriffe der objektorientierten Programmierung werden in gängigen C++-Lehrbüchern, ansatzweise auch in Meier/Wüst (1997[23]) dargelegt. Eine Einführung in die Unified Modelling Language findet sich im Internet unter http://www.rational.com/uml/html/summary/.
Seite 126
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
8.
Evaluation
Marktrelevante OODBMSes auf dem Prüfstand
Nachdem die Grundstrukturen des Systems definiert sind, muß nun das passende Werkzeug, also eine adäquate objektorientierte Datenbank, gefunden werden. Hierfür möchte ich zunächst die entsprechenden Evaluationskriterien definieren und anschließend marktrelevante objektorientierte Datenbanken anhand dieser Aspekte bewerten.
Hierbei mußte ich mich (leider) auf Beschreibungen aus Büchern und Prospekten verlassen, da es
keine direkten Vergleiche objektorientierter Datenbanken gibt, die erschwinglich oder frei verfügbar
wären35. Anders als bei SQL-basierten Datenbankanwendungen, bei denen sich – dank Schnittstellen
wie ODBC – sehr einfach unterschiedliche Datenbanksysteme „dahinterhängen“ und somit vergleichen lassen, erfordert die nahtlose Integration eines OODBMS in die Anwendung meist eine komplette Überarbeitung des Programmes bei der Migration zu einem anderen System. Außerdem sind
die verschiedenen Systeme unterschiedlich konzeptioniert; paßt man ein Programm nur 1:1 oder gar
über die eigentlich standardisierte ODMG-Schnittstelle an, wird dies den speziellen Features der einzelnen OODBMSes nicht gerecht.
So ist dann auch der einzige Performance- und Verfügbarkeitstest, den ich im WWW aufspüren
konnte, entstanden: Die Hersteller verschiedener objektorientierter Datenbanken wurden aufgefordert, eine Problemstellung für ihr eigenes System zu bearbeiten. Die jeweiligen herstellerspezifischen
Lösungen wurden dann hinsichtlich Verfügbarkeit und Serverperformance getestet.
8.1.
KRITERIEN ...
Welche Aspekte bei dieser Evaluation berücksichtigt werden sollen
Den hier verwendeten Evaluationskriterien liegt das von Meier/Wüst (1997[23], S.170ff) definierte
Bewertungsraster zugrunde, das ich um eigene Kriterien, die speziell im Hinblick auf das konkrete
Einsatzziel relevant sind, erweitert habe.
8.1.1.
Allgemeines Bewertungsraster
Unter dieser Kategorie finden sich allgemeine Kriterien zur Bewertung von objektorientierten Datenbanksystemen. Dabei will ich die entsprechenden Punkte genauer ausführen – und somit einen tiefergreifenden Einstieg in die Welt der objektorientierten Datenbanken vornehmen.
GRUNDLEGENDES
Ein handelsübliches OODBMS sollte mindestens eine strukturbasierte Sprachunabhängigkeit bieten,
damit auch ein Windows-Client Objekte von einem UNIX-Hochleistungsserver anfordern kann.
Desweiteren müssen die grundsätzlichen Anforderungen – wie in Kapitel 7.2.1 und in Meier/Wüst
(1997[23], S.144) beschrieben – bezüglich der Einbindung in die objektorientierte „Muttersprache“ er-
35
vgl. Heuer, 1997[22], S.556. Ich habe nach der dort angegebenen Literatur über den schweizerischen Bibliothekenverbund gesucht – sie ist
allerdings weder in Basel, Bern noch in Zürich zur Ausleihe verfügbar.
Seite 127
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
füllt werden. Systeme, die diese Bedingungen nicht erfüllen, habe ich erst gar nicht in diese Evaluation aufgenommen.
SERVERKONZEPTE
Prinzipiell sollten objektorientierte Datenbanken Client/Server-Architekturen unterstützen. Darüber
hinaus ist es interessant, ob und wie Objekte auf mehrere physikalische Datenbankserver verteilt
werden können (Skalierbarkeit).
Diesen Anforderungen werden im allgemeinen zwei Grundtypen von objektorientierten Datenbankservern gegenübergestellt: Objekt- und Seitenserver. Objektserver verwenden Objekte als kleinste
Einheit, während Seitenserver eine Ebene näher am physikalischen Hauptspeicher ansetzen: Es werden komplette Speicherseiten36 verwaltet – egal, wie viele Objekte oder Teilobjekte darin enthalten
sind. Ist eine solche Seite nicht in den Hauptspeicher geladen, fordert sie der Client vom Server an.
Beide Servertypen haben Vor- und Nachteile: So sind Seitenserver schneller und sehr klein, da die
gesamte Aufbereitung der gelieferten Seiten zu Objekten dem Client aufgebürdet wird. Diese Entlastung des Servers (meist sehr gut ausgestatte Rechner der Pentium Pro-, Pentium II- oder Workstation-Klasse) kann sich aber ins Gegenteil verkehren, wenn die Clients auf schwachen 486er-Terminals
die komplette Objektaufbereitung übernehmen müssen.
Ebenso kann ein Seitenserver nicht auf die in ihm gespeicherten Objekte zugreifen, da er die Struktur der von ihm verwalteten Seiten nicht kennt. Somit sind anspruchsvollere Funktionalitäten wie
beispielsweise das Bearbeiten von Suchanfragen (Queries) auf dem Server unmöglich.
Bei einem Objektserver wiederum können Objekte arbeitsteilig bearbeitet werden. So müssen bei
Suchanfragen nicht alle Seiten zum Client über das Intranet übertragen werden, um die Suche nach
abgeschlossener Übertrtragung lokal durchführen zu können, sondern lediglich das Suchergebnis
nach Beendigung der lokalen, serverseitigen Suche. Es werden nur die Objekte angefordert und übertragen, die auch wirklich benötigt und nicht bereits im clientseitigen Cache verfügbar sind. Andererseits führt diese Architektur bei vielen zu übertragenden Objekten zu einer riesigen Anzahl von
Requests – hier ist der Seitenserver im Vorteil, da er mehrere Objekte gleichzeitig übertragen kann.
[Meier/Wüst, 1997[23], S.139ff, vgl. auch Blummer, 1997[21], S.288f]
Abschließend möchte ich den Aufbau der beiden unterschiedlichen Systeme noch schematisch aufzeigen [Quelle: Meier/Wüst, 1997[23], S.139f].
Client
Objektablage
Server
Anwendungsprogramm
Objektmanager
Objektmanager
Datei- u. Indexverwaltung
Kommunikationssoftware
Ein-/Auslagerung
von Seiten
Objektablage
Seitenpuffer
Objektserver
36
Das Betriebssystem Windows beispielsweise arbeitet ebenfalls mit einer Seitenarchitektur: Dort werden immer 4096 zusammenhängende
Bytes zu einer solchen Einheit zusammengefaßt, die bei Bedarf beliebig verschoben, neu angeordnet oder in den virtuellen Speicher ausgelagert werden kann.
Seite 128
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Client
Server
Anwendungsprogramm
Seitenpuffer
Objektmanager
Seitenverwaltung
Datei- u. Indexverwaltung
Ein-/Auslagerung
von Seiten
Seitenpuffer
Kommunikationssoftware
Seitenserver
Dadurch, daß beim Objektserver-Konzept sowohl auf dem Server als auf dem Client Objektmanager
integriert sind, ist dieses Prinzip deutlich flexibler.
OBJEKTIDENTITÄTEN
OODBMSes arbeiten in der Regel mit Objektidentitäten, um die Nutzung von konkreten Speicheradressen (wie von Zeigern verwendet) zu vermeiden. Das Verwenden von physikalischen Zeigern
über das Ende einer Applikation hinaus würde zu Problemen führen, da physikalische Adressen sich
bei jedem Programmaufruf mit ziemlicher Wahrscheinlichkeit ändern. Sämtliche Verweise würden
somit auf falsche Objekte oder ganz ins Nichts zeigen.
Der Objektmanager eines Datenbanksystemes muß also die logische Objektidentität zur Laufzeit in
physikalische Adressen (beim Laden eines Objektes) und wieder zurück (beim Speichervorgang)
umwandeln. Meist besteht die Objektidentität aus einer mindestens 64bittigen Integerzahl, die nur
einmal pro Datenbank vergeben wird (Eindeutigkeit). Auch die IDs gelöschter Objekte werden nicht
mehr wiederverwendet. Die Objektidentität wird über Tabellen in tatsächliche Adressen umgewandelt – und umgekehrt.
TRANSAKTIONSMECHANISMEN & LOCKING
Transaktionen dienen, wie in Kapitel 7.4.4 beschrieben, der toleranten Behandlung von Fehlern und
dem definierten Hochfahren des Servers nach einem Systemcrash. Nun ist es in gewissen Fällen nicht
sinnvoll, eine komplette Transaktion scheitern zu lassen, sondern nur einen Teil der vorgenommenen
Änderungen.
Dies führt zum Konzept der langandauernden Transaktionen: Eine „inhaltliche Einheit“, die sich über einen längeren Zeitraum erstreckt – beispielsweise das Bearbeiten einer Seite in einem multimedialen Entwicklungssystem – wird als langandauernde Transaktion aufgefaßt, die in kleinere Transaktionen – beispielsweise das Bearbeiten einer Animation – aufgeteilt werden. Schlägt nun die Bearbeitung der Animation fehl – beispielsweise durch einen Undo-Befehl des Anwenders –, scheitert ausschließlich diese untergeordnete Transaktion, die zuvor vorgenommenen Änderungen bleiben trotzdem erhalten.
Geschachtelte Transaktionen erweitern das Konzept der langandauernden Transaktionen und machen das Gelingen einer Transaktion vom Verlauf untergeordneter Transaktionen abhängig. Eine untergeordnete Transaktion kann so beispielsweise die komplette übergeordnete Transaktion scheitern
lassen. Geschachtelte Transaktionen erlauben eine flexible Verwaltung und können dazu dienen,
Teiltransaktionen zu parallelisieren. [Meier/Wüst, 1997[23], S.128ff; Heuer, 1997[22], S.540ff]
Seite 129
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Grundlage von Transaktionen sind Locking-Funktionalitäten: Während der Bearbeitung können einzelne Objekte oder Objektgruppen mit verschiedenen Sperren versehen werden: So kann ein Objekt, wenn es von einem Client bearbeitet wird, für alle anderen gesperrt werden. Auch selektive
Sperren – also das Sperren nur von Schreibzugriffen – sollte möglich sein. Auf diese Art und Weise
kann das „Reinpfuschen“ von konkurrierenden Transaktionen in den Bearbeitungsprozeß vermieden
werden. [Meier/Wüst, 1997[23], S.133ff]
Es wird zwischen zwei Arten von Transaktionen unterschieden: optimistische und pessimistische. Bei
einer optimistischen Transaktion nimmt der Server an, daß die Transaktion als Ganzes schon gutgehen wird. Die Objekte werden nicht gesperrt. Stellt der Server nach Beendigung einer Transaktion
fest, daß eine konkurrierender Transaktion Objekte verändert hat, werden allerdings alle beteiligten
Transaktionen automatisch für gescheitert erklärt. Diese Methode kann in Umgebungen, die wenig
Schrieb- aber viele Lesezugriffe haben, zu erheblichen Performancegewinnen führen.
Anders pessimistische Transaktionen: Sie sperren die Objekte vorsorglich, so daß eine Transaktion
nicht von konkurrierenden Transaktionen beeinflußt werden kann.
VERSIONSKONTROLLE
Versioning ermöglicht es, unterschiedliche Versionen eines Objektes gleichzeitig in der Datenbank zu
verwalten. Der Anwendungsprogrammierer hat die volle Kontrolle über alle Versionen, d.h. er kann
in der Menge aller versionierten Objekte navigieren, neue Versionen erstellen, verarbeiten und löschen, sowie eine der Versionen als „aktuell“ definieren – diese aktuelle Version wird beim Ansprechen des Objektes über einen Zeiger defaultmäßig ausgewählt.
Neben diesen „inhaltlichen“ Versionen sind auch temporale Versionen vorgesehen, also Objektversionen, die einen bestimmten zeitlichen Gültigkeitsbereich besitzen. Der Inhalt einer Version ist also
nur für einen exakt definierten Zeitraum gültig, davor und danach sind jeweils andere Versionen aktuell. [Meier/Wüst, 1997[23], S. 123ff]
Die Möglichkeiten sind enorm: Man stelle sich ein Informationssystem vor, das einen vielstufigen
Prozeß abbilden soll. In einer Rubrik „aktuell“ können nun über zeitabhängige Versionen des „Aktuell“-Objektes immer genau die zur aktuellen Prozeßphase passenden Informationen abgerufen werden – und das immer über den Zeiger auf das gleiche Objekt. Die korrekte Zuordnung übernimmt
das Datenbanksystem.
BENUTZERGRUPPEN/AUTORISIERUNG
Ein objektorientiertes Datenbanksystem muß Autorisierungs- und Schutzmechanismen enthalten –
schließlich darf nicht jeder Benutzer Zugriff auf jedes Objekt bekommen. Es müssen verschiedene
Benutzergruppen eingerichtet werden können, denen jeweils individuelle, möglichst detailliert definierbare Rechte zugewiesen werden (vgl. auch Kapitel 5.1.7).
Im Idealfall können die Zugriffsrechte von einzelnen User auf einzelne Objektklassen definiert werden. [Meier/Wüst, 1997[23], S.117ff]
HERSTELLERSPEZIFISCHE APIS VS. IMPLEMENTIERUNG DES ODMG-STANDARDS
Ein modernes objektorientiertes Datenbanksystem sollte konform zum ODMG-Standard sein: Dieser
soll (zumindest in der Theorie) die Austauschbarkeit des Datenbank-Backends (ähnlich ODBC)
garantieren. Dafür werden standardisierte Abstraktionsebenen für die Definition des DatenbankscheSeite 130
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
mas (ODL), der Implementierung der Sprachschnittstelle (OML) und der Abfragesprache geschaffen
(OQL; eine Obermenge von SQL). Eine ausführliche Darstellung dieser drei Komponenten findet
sich in Schader (1997[26]).
Im allgemeinen sind die ODMG-Komponenten – soweit überhaupt vorhanden – eine Ebene über
der eigentlichen, herstellerspezifischen APIs angesiedelt. In meinem im Abschnitt 10 vorgestellten
Prototyp verwende ich das POET-API anstatt des ODMG-Standards – denn ersteres ist schlicht und
ergreifend komfortabler zu programmieren als der „kleinste gemeinsame Nenner“ in Form eines
Standards. [ODMG, 1997[24]]
Der ODMG-Standard ist meiner Meinung nach insgesamt eher mit Vorsicht zu genießen, da er die
speziellen Leistungsmerkmale der einzelnen Systeme bei weitem nicht ausnutzt. Außerdem ist das
Siegel „ODMG-konform“ (zumindest für die Version 1.2) ziemlich nichtssagend: Die Implementierung eines der Standards ODL, OQL oder OML genügt, um diese „Auszeichnung“ auf die Verpackung kleben zu dürfen. Und die Implementierung der OML-Teilkomponente ist ziemlich einfach...
[Blummer, 1997[21], S.286] In ODMG 2.0 wiederum wird zumindest kein allgemeines „ODMG
Compliant“-Siegel mehr vergeben, sondern ein in die Teilkomponenten unterteiltes. [ODMG,
1997[24]]
SCHNITTSTELLEN: CORBA, ODBC, SQL UND KONSORTEN
CORBA (Common Object Request Broker Architecture) ist ein von der Object Management Group
(OMG) standardisiertes Gegenstück zu proprietären Lösungen wie Microsofts OLE: CORBA stellt Mechanismen zur Verfügung, die es Anwendungen oder Komponenten ermöglicht, unabhängig von ihrem physikalischen Standort auch über das Inter- oder Intranet miteinander zu kommunizieren.
CORBA bedingt eine Three-Tier-Architektur und setzt sich selbst als Middleware zwischen Clients
und Server. So können Clients über diese Object Request Broker-Middleware (ORB) einheitlich auf
Serverobjekte zugreifen. [vgl. OMG[25]] Diese Schnittstelle wird von nahezu allen OODBMSes unterstützt.
Ähnlich bieten viele Systeme Schnittstellen zur Konkurrenz an: SQL-Schnittstellen, Mappings von
und auf relationale Schemata (also das objektorientierte Ansprechen eines relationalen Backends und
umgekehrt) oder die Anbindung über den Windows-Standard ODBC sind übliche Zusatzkomponenten, um Anwendungsprogrammieren die gewohnte Entwicklungsumgebung vorzugaukeln.
8.1.2.
Spezielle Evaluationskriterien
Neben diesem eher allgemein gehaltenen Bewertungsraster für objektorientierte Datenbanksysteme
müssen im Hinblick auf das hier skizzierte System noch einige ganz spezielle Aspekte untersucht
werden:
PERFORMANCE/NETZPERFORMANCE
Ein wichtiger Punkt: Wie schnell ist ein objektorientiertes Datenbanksystem, wie verhält es sich unter
(Über-) Last? Und leider liegt hier auch ein großes Problem: Wie kann dieser Punkt in einem mittleren Intranet, wie HQ dies besitzt, überhaupt überprüft werden?
In mittleren Intranetzen dürften im Regelfall auch eher Bandbreitenengpässe zu Problemen führen
als mangelnder Datenbankdurchsatz – und der Bandbreite kann besser durch eine Auslagerung auf
Seite 131
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
„Hilfskonstrukte“ wie Medieninhalten auf CD-ROM beigekommen werden – dank verteilter Datenbanken sollte dies ja keine größeren Probleme aufwerfen...
Außerdem stellt sich bei ständig purzelnden Hardwarepreisen die Frage, ob nicht einfach neue Server hinzugekauft werden, um Engpässe zu bereinigen, anstatt in teure Programmiererstunden mit
Ziel der Optimierung zu investieren.
Dennoch gibt es einige Forderungen, die Datenbankserver erfüllen sollten: Das System sollte ein zeitlich lineares Verhalten bei Einfüge-, Lösch- und Abfrageoperationen aufweisen. Die in Kapitel erwähnten Optimierungsmöglichkeiten (Index- und Clusterbildung) sollten unterstützt werden, darüber
hinaus Parallelverarbeitung, wo möglich. [Meier/Wüst, 1997[23], S.182f]
Insgesamt werden sich zu diesem Themenkomplex also lediglich allgemeine Aussagen finden, die in
der Praxis eventuell nicht einmal besonders aussagekräftig sind – weil andere Faktoren als die Serverperformance eben meist einen größeren Einfluß auf die Systemgeschwindigkeit haben.
SERVERVERFÜGBARKEIT
Insbesondere bei unternehmenskritischen Anwendungen (was ein Lernsystem zwar kaum sein
wird...) ist die Serververfügbarkeit ein extrem wichtiger Faktor: Schließlich darf bei einer Bank nicht
der gesamte Zahlungsverkehr zum Erliegen kommen, nur weil der Hauptprozessor des Datenbankservers „abgeraucht“ ist. Hierfür müssen Notfall-Server in ein System integriert werden, die automatisch auf dem aktuellen Stand des Hauptservers gehalten werden und bei einem Versagen des selben
selbständig einspringen.
Dies ist für das hier vorgestellte System vielleicht eine etwas übertriebene Anforderung, dennoch will
ich darstellen, mit welchen Mechanismen die hier vorgestellten Datenbanken eine Rund-um-dieUhr-Verfügbarkeit garantieren wollen.
MULTIMEDIALE UNTERSTÜTZUNG?
Multimediale Unterstützung erfordert zumindest einen BLOB37-Datentyp, in dem beliebige Inhalte
(also beispielsweise Pixeldaten etc.) abgelegt werden können.
Interessant wären auch direkte Anbindungen an ein bestehendes Autorensystem wie Director oder
ToolBook, die in einem solchen Falle als „Frontend“ dienen könnten. ToolBook bietet zwar die Möglichkeit, (relationale) Datenbanken über mitgelieferte DLLs oder eine getrennt vertriebene ODBCSchnittstelle anzubinden – allerdings ist diese Lösung bestenfalls als einfache Lösung ohne integrierte
Intranetanbindung anzusehen. Und: Um als wirkliches Frontend benutzt zu werden, müßte zumindest die Wiedergabe der Medienelemente direkt aus der Datenbank möglich sein. Und dies kann
keines der heutigen Autorensysteme. Und die mögliche Alternative, das Darstellungsmodul über
Skripte zu simulieren, scheitert an der mangelnden Performance der entsprechenden Zeichenfunktionen.
Die einzige praktikable Lösungen für bereits existierende Frontends scheinen HTML-Browser zu sein.
In diesem Zusammenhang werde ich auf evt. vorhandene Web-Lösungen für die einzelnen Systeme
eingehen, die übrigens mittlerweile von beinahe jedem Hersteller angeboten werden.
37
Binary Large Objects
Seite 132
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
LIZENZIERUNGSPOLITIK
Extrem wichtig ist auch die Lizenzierungspolitik der einzelnen Hersteller: Meist wird sowohl für die
Server- als auch für jede einzelne Client-Lizenz kräftig zugelangt. Dies ist leider für den MultimediaSektor, wo doch ziemlich viele kleinere Firmen plaziert sind, ein entscheidendes Hemmnis für den
Einsatz der Technologie – die Margen sind auch so meist schon gering genug. Oder andersrum: Eine
moderate Lizenzierungspolitik eines Herstellers kann letztlich zum Hauptargument für die Wahl des
einen oder anderen Produktes werden.
So interessant dieser Punkt für eine Evaluation wäre: Die Hersteller rücken nicht gerne mit entsprechen Daten heraus oder untersagen die Veröffentlichung – auch im Rahmen einer Diplomarbeit –
ausdrücklich. Aussage der ansonsten sehr freundlichen und hilfsbereiten Dame bei Versant: Versant
stelle seinen Kunden individuelle Lösungen zur Verfügung, dementsprechend individuell sei die Lizenzierungskonditionen, und dementsprechend ungern würde man sich auf konkrete Angaben festlegen.
POET war etwas auskunftsfreudiger (hier ging es allerdings um ein konkretes Projekt der HQ): Dort
handhabt man Lizenzierungen ähnlich flexibel – entweder der Kunde bezahlt für jeden einzelnen
Client Lizenzgebühren oder führt einen bestimmten prozentualen Anteil des Projektvolumens an den
Datenbankhersteller ab.
Insgesamt scheint das Lizenzierungsmodell ein entscheidendes Hemmnis für den Einsatz von
OODBMSes in multimedialen Systemen zu sein: Selbst Großkunden scheuen die Investition in die
neue Technologie, wenn bewährte SQL-Systeme (die mithin auch nicht gerade billig in der Anschaffung waren) bereits installiert sind und auch brav ihre Arbeit verrichten.
8.2.
... UND KANDIDATEN
In diese Evaluation einbezogene objektorientierte Datenbanken
Zu Beginn soll eine Marktübersicht stehen. Folgende Systeme werden in Heuer (1997, S.555ff) und
Meier/Wüst (1997, S.143ff), eine Untermenge ebenso in Blummer (1997[21], S.290ff) beschrieben:
System
O2
Hersteller
O2 Technology/Ardent
Sprachinterfaces
C++, Java, C
GemStone/S
GemStone
Smalltalk, Java
ObjectStore 5.0
Object Design
C++, Java, Smalltalk, Active X
Versant 5.0
Versant Object Technology
C++, Java, Smalltalk
POET 5.0
POET Software
Objectivity/DB
Objectivity Inc.
C++, Java, Visual
Basic
C++, Java, Smalltalk
Plattformen
Solaris, HP-UX, AIX, IRIX,
Digital Unix, Windows NT,
SCO, Linux
Windows 3.1x/95/NT
3.51/NT 4.0, OS/2 3.0 &
Warp, HP-UX, AIX, Solaris,
Mac OS
Solaris, Windows 95/NT,
OS/2, HP-UX, Irix, AIX, Digital Unix, SNI Reliant UNIX,
NEC UNIX
Solaris, AIX, Digital UNIX,
HP-UX, IRIX, OS/2 Warp,
Windows 95/NT 4.0
Windows 95/NT, HP-UX,
Solaris, Novell Netware
Digital UNIX, HP-UX, AIX,
Windows 95/NT 4.0, IRIX,
Solaris
Seite 133
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Die Auswahl der in diesem Abschnitt vorgestellten Datenbanksysteme erfolgte mit Blick auf die Praxis: So fallen Datenbanksysteme, die auf „unüblichen“ Sprachen wie Smalltalk, Lisp oder ähnlichen
Exoten basieren, aus der engeren Auswahl gleich wieder heraus. Ebenso habe ich einen Fokus auf
„marktrelevante“ Systeme gelegt, d.h. objektorientierte Systeme, die nicht nur für Nischenanwendungen benutzt werden. Für die Bestimmung des Faktors „Marktrelevanz“ habe ich die Anzahl der
mit dem jeweiligen System erstellten Anwendungen berücksichtigt.
Der entscheidende Faktor aber waren die Informationen, die über das jeweilige Produkt verfügbar
sind – und zwar aus mindestens zwei unabhängigen Quellen. Schließlich kann es nicht Sinn und
Zweck einer Diplomarbeit sein, Werbebotschaften aus Websites oder Prospekten abzupinseln.
8.2.1.
„Demystifying OODBMS“...
Zu Beginn möchte ich ganz allgemein auf einige Vorurteile, die objektorientierten Datenbanksystemen so anhängen, eingehen. Die Darstellung basiert auf Wetmore, 1996[27], S.58.
PERFORMANCEPROBLEME
Im allgemeinen wird angenommen, daß objektorientierte Datenbanksysteme ihren relationalen Kollegen performancemäßig hinterherhinken. Tatsächlich sind objektorientierte Systeme normalerweise
sogar schneller, da sie komplexe Datenstrukturen, wie sie bei objektorientierter Programmierung
vorkommen, einfacher handhaben können.
PROBLEME BEI DER STUFENLOSEN SKALIERUNG
... ist bei den meisten modernen Systemen absolut unproblematisch, wie diese Evaluation zeigen
wird.
OODBMSES KÖNNEN KEINE SUCHANFRAGEN DURCHFÜHREN
Oftmals werden objektorientierte Systeme als „Nur-Datenspeicher“ angesehen. Doch alle moderne
Systeme fügen über vergleichbare oder bessere Datenbankfunktionalitäten wie ihre relationalen
Konkurrenten
OBJEKTORIENTIERTE SYSTEME SIND NOCH IM VERSUCHSSTADIUM
Objektorientierte Systeme sind dem Versuchsstadium bereits längst entwachsen, was die langen Referenzlisten der einzelnen Produkte beweisen.
8.2.2.
O2
O2 wird von der französischen Firma O2 Technology (Websites: http://www.o2tech.com/ oder
http://www.o2tech.de/) seit 1991 entwickelt. Firmensitz ist Versailles, das System wird in Deutschland über die O2 Technology GmbH mit Sitz in Dortmund vertrieben. Das System entstand in einem
Konsortium aus Industrie und hochschulnahen Forschungseinrichtungen. Die Firma O2 nimmt für
sich in Anspruch, mit der aktuellen Version 5.0 die erste kommerzielle, voll ODMG-kompatible Objektdatenbank anzubieten.
Seite 134
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Neben dem eigentlichen Datenbanksystem bietet O2 Reportgeneratoren, Komponentenbibliotheken,
eine Anbindung an relationale Datenbanksysteme und CORBA, sowie eine Web-Schnittstelle
(O2Web) an. Als Serviceleistungen bietet O2 Consulting, Projekt-Coaching und Schulungen für das
Datenbanksystem an.
O2 wird beispielsweise bei AEG, British Telecom, Sun, Motorola, Thomson, France Telecom, Xerox
oder Alcatel eingesetzt.
8.2.3.
GemStone
GemStone wird von GemStone Systems (Website: http://www.gemstone.com/) aus Beaverton (Oregon/USA) seit 1987 entwickelt. Aktuelle Version ist 5.1.2. Deutscher Distributor ist die GemStone
Systems-Germany in Unterföhring bei München. GemStone bietet laut Eigenaussage als erster Hersteller einen komplett javabasierten Server (GemStone/J) an.
GemStone ist zwar ein sehr interessantes System, das nicht unbedeutende Marktanteile hat und sich
in vielen Konzernen im Alltagseinsatz bewährt. Da es aber trotz Java-Anbindung auf der SmalltalkLinie aufbaut, will ich es hier nicht weiter evaluieren.
8.2.4.
ObjectStore
ObjectStore wird von ObjectDesign (Website: http://www.odi.com/) mit Sitz in Burlington (Massachusetts/USA) hergestellt und in Deutschland von der Niederlassung in Wiesbaden betreut. Das System liegt momentan in der Version 5.0 vor. Das „kleine“ ObjectStore – ObjectStore PSE – hat sich
zum Quasi-Standard für Webapplikationen gemausert: Sowohl Netscape als auch Microsoft haben
das System für ihre Browser als Java-Komponente lizenziert.
Neben dem eigentlichen Datenbanksystem bietet ObjectDesign noch zahlreiche Rapid Application
Development (RAD)-Tools an. Als Tools stehen eine Webanbindung (ObjectForms), Anbindungen an
relationale Systeme (DBconnect) und Integrationswerkzeuge für Windowsanwendungen (Active
Toolkit) zur Verfügung.
ObjectDesigns Kundenliste: Netscape, Microsoft, Telstra (australische Telefongesellschaft), Sun, Symantec u.a.
8.2.5.
Versant
Versant liegt momentan in der Version 5.0 vor und wird von Versant Object Technology (Website:
http://www.versant.com/ oder http://www.versant.de/), Menlo Park, Kalifornien/USA hergestellt. Die
deutsche Niederlassung hat ihren Sitz in Weiterstadt bei Frankfurt.
Die Produktpalette umfaßt neben Server, Clients und C++-, Java-, sowie Smalltalk-APIs noch eine
„Fault-Tolerant-Option“, eine Webintegration namens „Versant Web“, Backup & Restore Utilities
und Administrationstools wie den GUI-basierten Zugriff & die GUI-basierte Verarbeitung von Datenbanken, eine Userverwaltung oder Monitoring-Tools zur Performanceüberwachung. Ebenso sind
Komponenten enthalten, die eine ODBC-Anbindung ermöglichen, indem Objekte in das vereinfachende Tabellenkonzept heruntergebrochen werden.
Seite 135
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Referenzen für Versant sind (hier nur auszugsweise wiedergegeben) Alcatel, British Telecom, der
Konkurrent Informix, Siemens, Panasonic oder Fujitsu. Das System wird an der Chicagoer Börse mit
großem Erfolg als Transaktionssystem eingesetzt und kommt dort auch spielend mit Überlast klar.
8.2.6.
POET
Die „Persistent Objects and Extended Database Technology“ ist ein Produkt „Made in Germany“,
das Entwicklerteam sitzt in Hamburg. Eigentlicher Firmensitz ist allerdings San Mateo, Kalifornien/USA. POET (Website: http://www.poet.com/ oder http://www.poet.de/) ist speziell auf Windows
NT ausgerichtet – und mithin das einzige System, das auf dieser Plattform neben Microsofts Visual
C++ auch noch den ansonsten eher stiefmütterlich behandelten Borland C++-Compiler unterstützt.
Die Produktpalette umfaßt neben den Standardkomponenten auch eine auf der objektorientierten
Datenbank basierende SGML/XML-Content Suite sowie die sogenannte „Web Factory“ – ein Tool,
das HTML serverseitig auf SGML-Basis um Befehle zum Datenbankzugriff erweitert. Als standardmäßige Tools liegen Entwicklungswerkzeuge, ein Objektbrowser und eine Administrationsoberfläche
bei.
Auch POET hat einige Referenzen zum Vorzeigen: So wurde beispielsweise Pixelparks Produktkatalog für adidas auf Basis von POET realisiert. Das Projekt realisierte Cross-Media-Publishing auf Basis
des objektorientierten Datenbanksystems. Daneben zählt POET Firmen wie CompuServe, Hewlett
Packard, Novell, Ericsson, Siemens, Bosch oder Mannesmann zu seinen Kunden.
8.2.7.
Objectivity/DB
Auch Objectivity/DB liegt mittlerweile in der Version 5.0 vor. Das System wird von Objectivity Inc.
(Website: http://www.objectivity.com/) aus Mountain View in Kalifornien/USA entwickelt und in
Deutschland durch die MICRAM Object Technology GmbH (Website: http://www.micram.de/) mit
Sitz in Bochum vertrieben. Gemäß Meier/Wüst (1997[23], S.147) ist Objectivity/DB das OODBMS mit
den ausgeprägtesten objektorientierten Features.
Objectivity bietet neben Server und verschiedenen APIs eine erweiterte SQL-Anbindung nach dem
SQL/3-Standard an; desweiteren kann eine „Fault-Tolerant-Option“ und eine „Data Replication Option“ (siehe Punkt „Besonderheiten“ im Unterkapitel 8.3.5) hinzugekauft werden. Standardmäßig liegen umfangreiche Administrationstools für Backupzwecke, Monitoring, Clustering, Objektbrowsing
usw. bei.
Referenzen: Cray Research, Hitachi, Nousoft (Multmedia-Informationssysteme), Toshiba, Citibank,
Exxon, Motorola, NEC, Nortel, Qualcomm, Siemens, SEH.
8.3.
DIE TESTERGEBNISSE!
Features der evaluierten Datenbanksysteme
Nachdem ich die Kandidaten kurz vorgestellt habe, werde ich nun die in Kapitel 8.1 definierten Kriterien auf sie anwenden. Allerdings möchte ich auf eine Bewertung nach Schulnoten verzichten, da
die Informationen zumindest teilweise aus Werbeprospekten stammen und ich nicht für mich in AnSeite 136
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
spruch nehmen kann, jedes der in diese Evaluation einbezogenen Produkte so ausgetestet zu haben,
daß ich ein eigenständiges Urteil abzugeben imstande wäre.
Die zu Beginn dieses Kapitels aufgezeigten Kriterien habe ich in Tabellenform abgehandelt; zusätzlich finden sich die Besonderheiten sowie Stärken und Schwächen des jeweiligen Systems als ausführliche Beschreibung am Ende der jeweiligen Produktbeschreibung.
Die Angaben entstammen Meier/Wüst (1997[23], S.170ff), Heuer (1997[22], S.557ff), Blummer
(1997[21], S.292ff) und Herstellerprospekten bzw. den Angaben auf der jeweiligen Hersteller-Website.
Interessanterweise widerspricht sich die Fachliteratur hinsichtlich mancher Details. So bezeichnet
beispielsweise Heuer (S.586) das Versionskonzept von ObjectStore 5.0 als eines der ausgefeiltesten
überhaupt, während Blummer (S.295) dem gleichen System eine Versionsverwaltung gänzlich abspricht. In einem solchen Falle habe ich die nachvollziehbarere Quelle verwendet – im Beispiel also
Heuer, der das wohl doch vorhandene Versionssystem ziemlich detailliert beschreibt.
8.3.1.
O2
GRUNDSÄTZLICHES
Eigenschaft
Objektidentität
primäre Datenbanksprache
Spracherweiterungen
Metaschema39
Vererbung
Sprachunabhängigkeit
Abfragesprache
Ausprägung
physikalische Objekt-ID
O2C/C++
Mengen gemäß ODMG-Definition38 (set, bag, list, array), Strings
Ja
Mehrfachvererbung unterstützt
unterstützt
OQL. Innerhalb von Abfragen können Methoden aufgerufen werden.
KONZEPTE
Eigenschaft
Serverkonzept
Ausführungsort
verteilte Objekte
Optimierungsmöglichkeiten
Architekturen
Schema-Evolution
Ausprägung
Seitenserver
Client
unterstützt
Indizierung: Indizierung nach Werten, Objekten und Pfaden
Clusterbildung: manuell (auch programmierbar)
One40-, Two- und Three-Tier-Architekturen
unterstützt
SPRACHANBINDUNGEN/APIS/ODMG
Eigenschaft
herstellerspezifische APIs
ODMG-Unterstützung
38
Ausprägung
Es existiert ein API zum direkten Zugriff auf die O2-Engine als Zusatzmodul.
O2 nimmt für sich in Anspruch, den kompletten ODMG-Standard zu
unterstützen: ODMG-Objektdatenmodell, C++-Anbindung, OQL.
Allerdings läßt sich in den mir vorliegenden Unterlagen keine Anbindung an ODL feststellen.
vgl. Schader 1997[26], S.13f
39
Metaschema: Informationen über den Aufbau von Klassen, Attributen und Methoden. So kann beispielsweise der Klartextname eines Attributes ermittelt werden (was beispielsweise in reinem C++ i.a. nicht möglich ist)
40
One-Tier-Architekturen: Lokale Anwendungen (Client und Server auf einem Rechner)
Seite 137
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Eigenschaft
CORBA
relationale Anbindung
Ausprägung
unterstützt (Zusatzmodul)
über Gateways
TRANSAKTIONEN & LOCKING
Eigenschaft
Lockingmechanismen
Transaktionsmechanismen
Ausprägung
„adaptives“ Locking: zunächst wird die Seite gesperrt, beim Zugriff
einer konkurrierenden Transaktion wird die Seite freigegeben und
auf Objekt-Ebene gesperrt (Performancegewinne). Automatische
Deadlock-Erkennung.
Konventionelle Transaktionen. Unterstützt das ACID-Prinzip.
VERSIONSKONTROLLE
Eigenschaft
inhaltliches Versioning
zeitliches Versioning
Ausprägung
als Zusatzmodul
–
SONSTIGES
Eigenschaft
Fehlertoleranz
Autorisierung
Ausprägung
Transaktionen, automatisches Hochfahren nach Ausfall, automatische
Replikation durch redundante Server
teilweise unterstützt
BESONDERHEITEN
Auf der UNIX-Plattform bietet O2 eine eigene Sprache an: O2C, eine objektorientierte Obermenge
von C (Werbeaussage des Herstellers: „O2C – eine objekt-orientierte Sprache der 4. Generation, Superset der C-Programmiersprache“).
Das Konzept des adaptiven (oder granularen) Sperrens kann gewisse Nachteile des SeitenserverPrinzips.
STÄRKEN
adaptives Sperren
OQL-Anbindung
Online-Garbage Collector
SCHWÄCHEN
Mir sind keine nennenswerten Schwächen aufgefallen.
8.3.2.
ObjectStore
GRUNDSÄTZLICHES
Eigenschaft
Objektidentität
primäre Datenbanksprache
Spracherweiterungen
Metaschema
Ausprägung
physikalische Objekt-ID
C++, Smalltalk
Mengen: os_set, os_bag, os_list, os_collection
Ja
Seite 138
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Eigenschaft
Vererbung
Sprachunabhängigkeit
Abfragesprache
Ausprägung
Mehrfachvererbung unterstützt
teilweise unterstützt
Proprietär. Keine Anbindung an OQL.
KONZEPTE
Eigenschaft
Serverkonzept
Ausführungsort
verteilte Objekte
Optimierungsmöglichkeiten
Architekturen
Schema-Evolution
Ausprägung
Seitenserver
Client
unterstützt
Indizierung: Indizierung nach Werten, Objekten und Pfaden
Clusterbildung: unterstützt (auch programmiert)
One- und Multi-Tier-Architekturen.
nur offline möglich
SPRACHANBINDUNGEN/APIS/ODMG
Eigenschaft
herstellerspezifische APIs
ODMG-Unterstützung
CORBA
relationale Anbindung
Ausprägung
vorhanden
OML vorhanden, kein OQL
unterstützt
über Gateways
TRANSAKTIONEN & LOCKING
Eigenschaft
Lockingmechanismen
Transaktionsmechanismen
Ausprägung
Sperren auf Seitenbasis. „Callback Locking“-Technologie (siehe Besonderheiten). Automatische Deadlock-Erkennung.
Lange & geschachtelte Transaktionen.
VERSIONSKONTROLLE
Eigenschaft
inhaltliches Versioning
zeitliches Versioning
Ausprägung
unterstützt
teilweise unterstützt
SONSTIGES
Eigenschaft
Fehlertoleranz
Autorisierung
Ausprägung
Transaktionen, automatisches Hochfahren nach Ausfall, automatische
Replikation durch redundante Server
teilweise unterstützt
BESONDERHEITEN
Die physikalische Objekt-ID entspricht bei ObjectStore einer konkreten Adresse im Speicherraum
des Computers. Ist ein Objekt im Hautspeicher geladen, kann direkt und ohne Zeitverlust darauf zugegriffen werden. Ist ein Objekt hingegen nicht geladen, erzeugt der Zugriff auf die entsprechende
Speicheradresse einen Seitenfehler des Betriebssystems. Dieser wird von ObjectStore abgefangen –
das Datenbanksystem lädt dann die entsprechende Seite nach. Dieses mittlerweile patentierte,
VMMA41 genannte System bringt eine außerordentliche Performancesteigerung, da keine Umrechnungen von logischen Objektidentifikationen in reale Hauptspeicheradressen erfolgen müssen
41
Virtual Memory Mapping Architecture
Seite 139
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
ObjectStores Cache-Forward Architektur ist bezeichnend für den vom System verfolgten Ansatz: Der
Datenbankserver ist lediglich dazu da, möglichst effektiv Seiten an Clients bzw. Anwendungsserver
zu liefern. Daher erhält jeder Client einen eigenen Cache, in dem er möglichst viele Bearbeitungsfunktionen unabhängig vom Server durchführt, bevor er am Ende einer Transaktion den Cache wieder an den Server zurückschreibt. Hierfür sind speziell abgestimmte Locking-Mechanismen erforderlich, die bei ObjectStore mit dem Begriff „Callback-Locking“ bezeichnet werden.
STÄRKEN
extrem hohe Performance durch die hardwarenahe VMM-Architektur
Netzwerkentlastung durch Cache-Forward-Architektur
ObjectStore bietet eine nahtlose und transparente Einbettung in das C++-System wie kaum ein
anderes System.
ausgereiftes Versionierungskonzept
SCHWÄCHEN
ObjectStore ist ein Seitenserver in Reinkultur – er erfordert starke Clients oder eine Three-TierArchitektur mit starken Anwendungsservern.
Schema-Evolution nur offline möglich und meist mit einer Neukompilierung der Anwendung verbunden
8.3.3.
Versant
GRUNDSÄTZLICHES
Eigenschaft
Objektidentität
primäre Datenbanksprache
Spracherweiterungen
Metaschema
Vererbung
Sprachunabhängigkeit
Abfragesprache
Ausprägung
logische Objekt-ID
C++
Mengen und Strings
Ja
Mehrfachvererbung unterstützt
unterstützt
eigener SQL-Dialekt (Versant/SQL)
KONZEPTE
Eigenschaft
Serverkonzept
Ausführungsort
verteilte Objekte
Optimierungsmöglichkeiten
Architekturen
Schema-Evolution
Ausprägung
Objektserver
Client und Server
unterstützt, auch auf Archivierungsmedien
Indizierung: Indizierung nach Werten
Clusterbildung: automatisch
One-, Two- und Three-Tier-Architekturen.
auch online möglich
SPRACHANBINDUNGEN/APIS/ODMG
Eigenschaft
herstellerspezifische APIs
ODMG-Unterstützung
CORBA
relationale Anbindung
Ausprägung
vorhanden
OML vorhanden, teilweise OQL-konformer SQL-Dialekt
unterstützt
über Zusatzmodule
Seite 140
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
TRANSAKTIONEN & LOCKING
Eigenschaft
Lockingmechanismen
Transaktionsmechanismen
Ausprägung
Sehr vielseitige Sperralgorithmen auf Objektbasis (z.B. Absichtssperren). Automatische Deadlock-Erkennung.
Lange & geschachtelte Transaktionen. Verwendung einer „privaten
Datenbank“
VERSIONSKONTROLLE
Eigenschaft
inhaltliches Versioning
zeitliches Versioning
Ausprägung
unterstützt; auch mit verteilten Versionsobjekten
unterstützt; auch mit verteilten Versionsobjekten
SONSTIGES
Eigenschaft
Fehlertoleranz
Autorisierung
Ausprägung
Transaktionen, automatisches Hochfahren nach Ausfall, automatische
Replikation durch redundante Server
teilweise unterstützt
BESONDERHEITEN
Versant ermöglicht als „echter“ Objektserver auch die lokale Verarbeitung von Objekten direkt auf
dem Datenbankserver. Dies wirkt sich sehr positiv auf die Netzbelastung aus. Positiv sind auch die
sehr vielseitigen Sperrmechanismen, die unter anderem auch benutzerdefinierte Locks zulassen.
Lange Transaktionen spielen sich komplett auf dem Client ab. Dazu legt Versant eine sogenannte
„private Datenbank“ lokal an. Dort können die Objekte auch ohne Verbindung mit dem Server verarbeitet werden. Nach Beendigung der Transaktion werden die Daten wieder zum Server zurückgeschrieben werden.
Versants Sprachunabhängigkeit geht soweit, daß auch C++-unspezifische Konzepte wie beispielsweise ein Online-Garbage-Collector unterstützt werden.
STÄRKEN
Sperrmechanismen
gute Umsetzung des Objektserverkonzeptes
unabhängige Bearbeitung auf Client möglich
Online-Garbage Collector auch unter C++
ausgereiftes Versionierungskonzept
SCHWÄCHEN
Indexbildung nur auf Wertbasis möglich
Seite 141
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
8.3.4.
POET
GRUNDSÄTZLICHES
Eigenschaft
Objektidentität
primäre Datenbanksprache
Spracherweiterungen
Metaschema
Vererbung
Sprachunabhängigkeit
Abfragesprache
Ausprägung
logische Objekt-ID
C++
Mengen, Strings
Ja
Mehrfachvererbung unterstützt
unterstützt
Proprietär und OQL.
KONZEPTE
Eigenschaft
Serverkonzept
Ausführungsort
verteilte Objekte
Optimierungsmöglichkeiten
Architekturen
Schema-Evolution
Ausprägung
Seitenserver
Client
unterstützt
Indizierung: Indizierung nach Werten, Objekten und Pfaden. Es
können externe Index-Module eingebunden werden (beispielsweise
eine Volltextsuche).
Clusterbildung: nicht unterstützt
One- und Multi-Tier-Architekturen.
nur offline möglich
SPRACHANBINDUNGEN/APIS/ODMG
Eigenschaft
herstellerspezifische APIs
ODMG-Unterstützung
CORBA
relationale Anbindung
Ausprägung
vorhanden
vorhanden
unterstützt
über SQL-Factory und ODBC-Treiber
TRANSAKTIONEN & LOCKING
Eigenschaft
Lockingmechanismen
Transaktionsmechanismen
Ausprägung
definierbare Sperren auf Objektbasis; Deadlock-Erkennung
Lange & geschachtelte Transaktionen; erlaubt die Verwendung von
Workspaces.
VERSIONSKONTROLLE
Eigenschaft
inhaltliches Versioning
zeitliches Versioning
Ausprägung
nicht unterstützt
nicht unterstützt
SONSTIGES
Eigenschaft
Fehlertoleranz
Autorisierung
Ausprägung
Transaktionen
unterstützt
Seite 142
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
BESONDERHEITEN
POET erlaubt bei langen Transaktionen die Verwendung von Workspaces – Objekte können lokal
kopiert, serverunabhängig bearbeitet und abschließend wieder auf den Server zurückkopiert werden.
Erwähnenswert sind auch die umfangreichen Authentifizierungsmöglichkeiten.
STÄRKEN
Externe Indexmodule einbindbar
Flexible Objektsperren
OQL-Anbindung
Benutzerverwaltung
Workspace-Konzept
SCHWÄCHEN
keine Versionierung möglich
keine Clusterbildung möglich
Schema-Evolution nur offline möglich und meist mit einer Neukompilierung der Anwendung verbunden
schwache Sicherheitsfunktionen – so ist kein Einsatz von redundanten Servern bei Systemausfällen vorgesehen
8.3.5.
Objectivity/DB
GRUNDSÄTZLICHES
Eigenschaft
Objektidentität
primäre Datenbanksprache
Spracherweiterungen
Metaschema
Vererbung
Sprachunabhängigkeit
Abfragesprache
Ausprägung
Surrogat (log. ID)
C++
Mengen, Strings
Ja
Mehrfachvererbung unterstützt
unterstützt
Proprietär und SQL++ (auf SQL-92 basierend)
KONZEPTE
Eigenschaft
Serverkonzept
Ausführungsort
verteilte Objekte
Optimierungsmöglichkeiten
Architekturen
Schema-Evolution
Ausprägung
Seitenserver
Client
unterstützt
Indizierung: Indizierung nach Werten, Objekten und Pfaden.
Clusterbildung: nicht unterstützt
One- und Multi-Tier-Architekturen.
auch online möglich
SPRACHANBINDUNGEN/APIS/ODMG
Eigenschaft
herstellerspezifische APIs
ODMG-Unterstützung
Ausprägung
vorhanden
eingeschränkt; OQL wird nicht unterstützt
Seite 143
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
Eigenschaft
CORBA
relationale Anbindung
Ausprägung
unterstützt
über SQL++ und ODBC-Treiber
TRANSAKTIONEN & LOCKING
Eigenschaft
Lockingmechanismen
Transaktionsmechanismen
Ausprägung
definierbare Sperren auf Objekt- oder Seitenbasis; DeadlockErkennung
unterstützt; auch lokal möglich
VERSIONSKONTROLLE
Eigenschaft
inhaltliches Versioning
zeitliches Versioning
Ausprägung
unterstützt
nicht unterstützt
SONSTIGES
Eigenschaft
Fehlertoleranz
Autorisierung
Ausprägung
Transaktionen, automatisches Hochfahren nach Ausfall, automatische
Replikation durch redundante Server
nicht unterstützt
BESONDERHEITEN
Auch Objectivity/DB erlaubt das lokale Auslagern von Transaktionen auf den Client. Der Objectivity/DB-Server läßt sich zu lokalen Anwendungen hinzulinken.
STÄRKEN
granulares Locking
lokale Bearbeitung möglich
Sperren wahlweise auf Objekt- oder Seitenebene
SCHWÄCHEN
keine Clusterbildung möglich
fehlende Benutzerautorisierung
fehlende OQL-Unterstützung
8.4.
FAZIT
Ergebnisse der Evaluation
Ich möchte in diesem abschließenden Kapitel des Evaluation-Abschnittes noch ein kurzes Fazit ziehen und dabei auf die Bedeutung verschiedener allgemeiner und spezieller Kriterien für meinen Systementwurf eingehen.
Seite 144
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
8.4.1.
Serverkonzepte
Beinahe das wichtigste Entscheidungskriterium für die Systemwahl dürfte das Serverkonzept sein:
Seitenbasierte Systeme verlagern viel Arbeit auf die Clients und entlasten gleichzeitig den Server. Da
Multimedia-Anwendungen sowieso starke Clients benötigen, scheinen Seitenserver zumindest unter
diesem Gesichtspunkt erste Wahl zu sein.
Andererseits sind die riesigen Datenmengen zu beachten, die multimediale Anwendungen so nach
sich ziehen: Müssen erst megabytegroße Videodaten auf den Client gezogen werden, um eine einfache Volltextsuche realisieren zu können, verursachen Seitenserver statt eines Geschindigkeitsrausches
eher einen Stau im Intranet.
8.4.2.
Performance
Performance ist ja im allgemeinen extrem wichtig – und sehr schwer objektiv zu beurteilen. Es
scheint vielmehr so, daß jedes der hier vorgestellten Systeme in ganz besonderen Bereichen seine
Performancestärken hat. So nimmt dann auch beinahe jede Objektdatenbank eine „BestPerformance“-Auszeichnung für sich in Anspruch.
Soll ein konkretes System mit einer objektorientierten Datenbank realisiert und dabei maximale Performance erreicht werden, bleibt dem Programmierer keine andere Wahl, als sich Evaluationsversionen der verschiedenen Systeme zu besorgen, sich in die Systeme einzuarbeiten und dann je nach
Problemstellung entsprechende Performancetests zu entwickeln. [vgl. auch Meier/Wüst, 1997[23],
S.181]
Allgemein sollten Seitenserver allerdings performanter als Objektserver sein, da das zeitaufwendige
Aufbereiten der Rohdaten in Objekte dem Client überlassen wird (Flaschenhals Objektmanager). Besonders ObjectStore kann hier mit seiner hardwarenahen Implementation punkten. Dieser Vorteil
kann sich aber je nach Anwendung aufgrund höherer Netzbelastung ins Gegenteil verkehren (Flaschenhals Netzlast). Auch hier muß im konkreten Anwendungsfall abgewogen werden.
Im Vergleich zum relationalen Modell ist auf jeden Fall ein allgemeiner Perfomancevorsprung für
komplexe Daten wie Multimediaobjekte festzustellen, da die Transformation von Objektdaten in Tabellen komplett wegfällt.
8.4.3.
Multimedia!
Das Grundelement BLOB bietet jedes der hier vorgestellten Systeme in unterschiedlichen Ausprägungen – und damit die Möglichkeit, unstrukturierte Daten mit variabler Länge wie Bilder, Videos
oder Sounds aufzunehmen.
Interessant ist das Versionskonzept hinsichtlich Varianten, wobei hier insbesondere ObjectStore und
Versant überzeugen können.
Ansonsten läßt sich kaum eine besondere Eignung eines einzelnen Systems für multimediale Daten
feststellen – mit Versants Konzept, auch auf dem Server einen Objektmanager zur Verfügung zu stellen, ließen sich eventuell vorgeschaltete Komprimierungsalgorithmen realisieren – vgl. Kapitel 5.6.4.
Und eine der Haupt(-heraus-)forderungen von netzbasiertem Multimedia, nämlich die Garantie eines konstanten Datenstroms, liegt sowieso weniger in der Hand der Datenbankserver als bei der
verwendeten Netzwerktechnologie (vgl. Kapitel 5.6.2)
Seite 145
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Evaluation – Marktrelevante OODBMSes auf dem Prüfstand
8.4.4.
Das Finale...
Leider war in dieser Evaluation keine wirklich stichhaltige Abgrenzung der einzelnen Systeme möglich – hierzu müßte man sich wirklich intensiv in jedes einzelne der hier vorgestellten Datenbanksysteme einarbeiten. Und da die Evaluation objektorientierter Datenbanken nicht das Hauptthema dieser Diplomarbeit war, habe ich auf einen derartig tiefgreifenden Einstieg verzichtet.
Dennoch: Müßte ich zu diesem Zeitpunkt die Wahl für ein bestimmtes System treffen, würde meine
Wahl wohl zugunsten ObjectStores ausfallen: Ich setze für multimediale Anwendungen gut ausgestattete Clients voraus, so daß sich die Vorteile des Seitenserver-Prinzips voll entfalten können. Ebenso
scheint das Cache-Forward-Prinzip geradezu ideal dafür geeignet zu sein, zeitkritische MultimediaInhalte möglichst vollständig lokal zu verarbeiten und nicht wegen jedes einzelnen Objektes einen
zeitraubenden Serverzugriff fahren zu müssen. Als einziger Nachteil fallen mir Suchanfragen ein, die
dank des strikten Serverkonzeptes bei ungeschickter Programmierung zu enormer Netzbelastung führen können. Hier ist eine entsprechende Programmierung und ggf. die Zwischenschaltung eines eigenen Query-Servers mit superschneller Anbindung an den eigentlichen Datenbankserver gefordert.
Dem ausgereiften Versionierungskonzept würde im Zusammenhang mit Varianten (vgl. auch Kapitel
9.2.2) ein exzellentes Anwendungsfeld geboten.
Nicht zu verachten ist auch, daß ObjectDesign mit ObjectStore PSE eine kostenlos nutzbare SingleUser-Version des Systems anbietet, so daß sich CD-ROM-Produktionen ohne weitere Lizenzgebühren realisieren lassen.
Aber auch die anderen Systeme, allen voran Versant, bieten interessante Lösungen und individuelle
Stärken.
Als Fazit bleibt: Prinzipiell lassen sich alle der hier vorgestellten Systeme problemlos professionell einsetzen – auch und gerade für multimediale Datenbestände. Die zahlreiche Referenzen beweisen,
daß die objektorientierte Datenbanktechnologie längst den Kinderschuhen entwachsen ist. Die Faktoren bei der Wahl eines Produktes präsentieren sich nicht anders als bei der Entscheidung für ein
konkretes relationales System: Ob es letztlich ein Microsoft SQL-Server oder ein Oracle-System wird,
hängt meist weniger von der Leistungsfähigkeit des Systems als von den Vorlieben des Programmierers, von speziellen Anforderungen einer Anwendung oder von Kundenvorgaben ab.
Genauso stellt sich mittlerweile die Lage in der Welt der objektorientierten Datenbanken dar. Mit allen Systemen können professionelle und stabile Anwendungen entwickelt werden. Der Leistungsumfang der Systeme ist meist ähnlich. Und diese Alltagstauglichkeit kann beruhigen.
Seite 146
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.
Der Systementwurf
Zusammenführung, Schnittstellen & mehr
Der größte Teil der Arbeit ist geleistet: Ich habe definiert, was meine Lern- und Produktionsumgebung alles können soll und mit welchen Attributen die entsprechenden Objekte ausgestattet werden
müssen, um eine derartige Funktionalität gewährleisten zu können. Außerdem habe ich eine Evaluation geeigneter Datenbanksysteme vorgenommen.
In diesem letzten theoretischen Abschnitt möchte ich noch die fehlenden Objektdefinitionen nachschieben und vor allem auf notwendige Schnittstellen und Methoden eingehen. Dabei werde ich
immer auf einer abstrakten, umschreibenden Ebene bleiben, da eine konkrete Ausgestaltung der jeweiligen Elemente den Rahmen dieser Diplomarbeit endgültig sprengen würde.
Ich unterscheide bei diesem Systementwurf zwischen Objekten und Modulen: Objekte sind die in
den vorangegangenen Abschnitten ausführlich diskutierten Elemente, also Medien, Strukturen oder
Ablaufschablonen. Sie werden in der Datenbank möglichst plattformübergreifend vorgehalten. Module sind die benötigten Grundfunktionalitäten, die bespielsweise die Darstellung oder Systemverwaltung übernehmen. Sie sind plattformabhängig und werden von den Objekten über genau definierte Schnittstellen und Funktionalitäten benutzt.
Ich habe als Programmiersprache für Beispiele ein um POET-spezifische Feinheiten erweitertes C++
verwendet.
9.1.
ZIELSETZUNG
Zusammengefaßt: Ziele des Systems
Ziel ist es, eine integrierte Lern- und Produktionsumgebung zu entwickeln, die
den Autor beim kreativen Prozeß durch entsprechende Konzeptionswerkzeuge unterstützt,
die inhaltliche Qualität eines Produktes durch ausgefeilte teamorientierte Überarbeitungsmechanismen steigert,
die Effizenz des Produktionsprozesses erhöht,
die Qualität des Programmes steigert, indem Automatismen zur Programmerstellung angeboten
werden und so Fehler vermieden werden können,
dem Lerner Anreize durch eine entsprechende Lernumgebung bietet,
und die die Kommunikation während des gesamten Produktionsprozesses unter den Beteiligten
durch standardisierte Protokolle und Sprachen verbessert.
Der „Killer“-Aspekt dieser Applikation besteht in der Integration der drei Hauptaspekte Authoring,
Produktion und Rezeption in einem System.
Seite 147
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.2.
DATENSTRUKTUREN
Konkretisierungen
Ich habe die Ausprägung der verschiedenen Datenstrukturen in den vorangegangenen Abschnitten
bereits detailliert beschrieben. Ich möchte deshalb an dieser Stelle hauptsächlich auf die konkrete
Umsetzung mit Hilfe objektorientierter Techniken eingehen. Eine Beispiels-Ausformulierung – allerdings mit bei weitem nicht allen Attributen – findet sich im folgenden Abschnitt „In die Praxis“ anhand eines einfachen Prototyps.
9.2.1.
Die Mutter aller Objekte – Polymorphie
Das komplette System wird auf ein „Urobjekt“ zurückgreifen können, von dem alle anderen Objekte
abgeleitet sind (Polymorphie). Dies gewährleistet, daß beliebige Objekttypen (also sowohl Strukturelemente als auch Konzeptionsobjekte oder Benutzerprofile) einheitlich und universell in entsprechenden Listen angesprochen werden können. Das System kann dann selbständig entscheiden, um
welches Objekt es sich konkret handelt – und damit die richtigen Funktionen aufrufen und entsprechende Dateninterpretationen vornehmen.
Genauso basieren alle Medienklassen auf einer Mediengrundklasse; die einzelnen Typen werden
durch Ableitungen erzeugt. Ähnlich verhält es sich mit allen anderen Elementen, die durch den objektorientierte Beziehung „ist ein spezielles“ ausgedrückt werden können: Ein Systemadministrator ist
beispielsweise ein spezieller Benutzer, eine Phasenanimation ein spezielles Strukturelement.
Die Urelemente enthalten die jeweils grundlegenden Attribute, die bei sämtlichen Ableitungen gleich
sind, also beispielsweise die Archivinformation oder allgemeingültige Objektinfos.
9.2.2.
Varianten vs. Versionen & Transaktionen
Objektorientierte Datenbanksysteme bieten die Möglichkeit der Versionsbildung von Objekten, d.h.
von ein und demselben Objekt können mehrere Ausprägungen existieren (vgl. Kapitel 8.1.1). Somit
stellen Versionen eine sehr elegante und organische Möglichkeit dar, Varianten zu implementieren:
Für jede neue Variante wird einfach eine neue Version des Grundobjektes angelegt, den Rest erledigt
die Datenbank.
Bietet das verwendete Datenbanksystem die Möglichkeit, Objekte lokal im Rahmen einer Transaktion zu bearbeiten, ist dies ein ideales Anwendungsgebiet für temporäre Varianten: Zu Beginn der Lebensdauer wird die Transaktion begonnen und die Objekte in den lokalen Cache kopiert. Während
der Lebensdauer werden die Objekte nur lokal bearbeitet. Zum Ende der Lebensdauer wird die
Transaktion einfach abgebrochen, so daß die lokalen Objekte nicht auf dem Server aktualisiert werden.
9.2.3.
Datenbankobjekte
Da ich die eigentlichen Daten bereits in den vorhergehenden Abschnitten beschrieben habe, möchte
ich an dieser Stelle lediglich eine Übersicht darüber geben, welche grundlegenden Objektkomponenten in der meinem System zugrundeliegenden Datenbank vorkommen und in welchem Kapitel
sie definiert sind.
Seite 148
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Elemente
Mediengrundelement
Medienelemente
Medienkapselungen
Ablaufschablonen
Strukturelemente
Lernmodule
Konzeptionselemente
Benutzerprofile
Chats
Diskussionsforen
Kommunikationselemente („eMail“)
Lernumgebung
Archivinformation
Überarbeitungsinfo
(Varianten)
definiert in...
Kapitel 9.2.1
Kapitel 5.2.5
Kapitel 5.2.5
Kapitel 5.2.7
Kapitel 5.2.6
Kapitel 5.1.3
Kapitel 5.3.3
Kapitel 5.1.4
Kapitel 5.4.4
Kapitel 5.4.3
Kapitel 5.4.2
Kapitel 6.2.2
Kapitel 4.8.5
Kapitel 4.8.4
Kapitel 6.5
Wohlgemerkt, es handelt sich bei diesen Objekten um die Elemente der Datenbank – und selbstverständlich nicht um eine vollständige Darstellung sämtlicher im gesamten System vorkommender Klassen.
9.3.
METHODEN
Was Objekte können sollten
Bei einem objektorientierten Datenmodell – das ja eben die Einheit von Daten und die sie bearbeitenden Funktionen hervorhebt – ist es wichtig, die Objektmethoden zu definieren: Was muß ein
Medienelement können, was eine Medienkapselung? Über welche Funktionalitäten muß ein Strukturobjekt verfügen?
Ich bin bei meinen Definitionen auf einer abstrakten Ebene geblieben, die aufzeigt, welche Dinge zu
beachten sind, ohne jede einzelne Funktion zu beschreiben. Dies ist im Rahmen einer Diplomarbeit
weder möglich noch sinnvoll. Eine Konkretisierung anhand einer Untermenge findet sich aber im Abschnitt „In die Praxis“.
Ebenso habe ich nicht alle Objekte in meine Darstellung aufgeführt, da sich die Funktionalitäten
recht ähnlich sind und fehlende Definitionen aus den dargestellten Objekten leicht abgeleitet werden können. Dies sollte insofern einsichtig sein, da eine detaillierte Darstellung der „spektakulären“
und für die einzelnen Objekttypen wirklich unterschiedlichen Funktionalität (Darstellung und Verarbeitung der Interaktionen) in dieser Diplomarbeit zu weit führen würde.
9.3.1.
Grundfunktionalitäten
Die objektorientierte Programmierweise definiert einige wichtige Grundsätze: Objekte sollten sich
selbständig verwalten können. Zugriffe auf Objekte dürfen nur über genau definierte Schnittstellen
geschehen.
Seite 149
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
ANLEGEN UND LÖSCHEN EINES OBJEKTES
Objekte müssen sich beim Anlegen selbständig initialisieren. Die entsprechenden Defaultwerte sind
zu setzen, insbesondere muß sichergestellt werden, daß die Integrität des Systems erhalten bleibt –
beispielsweise, daß Verweise korrekt initialisiert werden.
Ebenso ist beim Löschen eines Objektes auf die Integrität des Systems zu achten: ggf. müssen hierarchisch untergeordnete Objekte mitgelöscht werden, zumindest aber neu verzeigert werden. Hierfür
sollten die im Anschluß beschriebenen Verwaltungs- und Verarbeitungsfunktionen intern aufgerufen
werden, damit sich der Verwaltungs- und Wartungsaufwand in möglichst engem Rahmen hält.
Die entsprechenden Initialisierungen und Aufräumarbeiten werden idealerweise im Konstruktor bzw.
Destruktor eines Objektes vorgenommen. Ein evt. vorhandener Garbage-Collector sorgt dafür, daß
nicht mehr referenzierte Objekte automatisch aus der Datenbank gelöscht werden.
VERWALTEN UND VERARBEITEN EINES OBJEKTES
Zunächst müssen die Elemente in der Lage sein, alle ihre Attribute zu setzen und auszulesen. So
müssen Objektname, hierarchische Informationen, Archivierungsinformationen usw. von übergeordneten Modulen oder Funktionen ausgelesen und gesetzt werden können.
Ein Objekt muß sich aber auch selbst innerhalb der Objekthierarchie korrekt einordnen und verschieben können. Hierfür sind die entsprechenden Integritäts-Bedingungen zu beachten, so daß keine Zirkelschlüsse, offene Verweise oder „verwaiste“, d.h. nicht in die Objekthierarchie der Lernumgebung eingebundene Objekte entstehen.
Zirkelschlüsse entstehen dann, wenn ein Objekt einem der ihm untergeordneten Objekte untergeordnet werden soll. Dies kann verhindert werden, indem die untergeordneten Objekte vor der Hierarchieänderung nach dem neuen Wurzelobjekt durchsucht werden.
Offene Verweise können beim Löschen oder Verschieben entstehen, wenn „vergessen“ wird, in einem anderen Objekt den Verweis zu löschen oder anzupassen. Um alle Verweise problemlos zu erfassen, sollte prinzipiell eine doppelte Verzeigerung verwendet werden – eine Unterordnung wird also nicht nur im übergeordneten, sondern auch in allen untergeordneten Knoten „rückwärts“ vermerkt.
Verwaiste Objekte können entstehen, wenn beim Löschen eines Objektes mit untergeordneten Elementen diese untergeordneten Objekte nicht mitgelöscht oder neu verzeigert werden. Dies muß bei
den entsprechenden Verwaltungsfunktionen berücksichtigt werden, wenn kein Garbage-Collector
vorhanden ist, der diese Aufgabe automatisiert übernimmt.
In Mengen bzw. Listen wird ein Cursor-Prinzip eingeführt, über das einfach in der jeweiligen Menge
navigiert werden kann: Soll beispielsweise die erste untergeordnete Medienkapselung eines Strukturelementes ermittelt werden, wird der Cursor auf die erste Position der Verweisliste gesetzt und die
Kapselung dann über die Auslesen-Methode zur weiteren Verarbeitung verfügbar gemacht.
DARSTELLUNG VON MEDIENOBJEKTEN
Medienelemente enthalten noch eine zusätzliche Grundfunktionalität: Sie müssen in der Lage sein,
sich über das in Kapitel 9.6.1 diskutierte Darstellungsmodul selbst darzustellen.
In der Praxis erhalten die Objekte vom System die Aufforderung, einen bestimmten Ausschnitt ihrer
visuellen Daten darzustellen. Bei statischen Elementen genügt dann der Aufruf der entsprechenden
Seite 150
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Grundfunktionen des Darstellungsmoduls, bei dynamischen Medienelementen wie Videos müssen
zusätzlich noch Zeitinformationen ausgewertet werden – sofern hier nicht das Betriebssystem die
komplette Aufbereitung übernimmt (vgl. das MCI von Windows).
LEERLISTEN FÜR NOCH NICHT ZUGEORDNETE ELEMENTE
Soll ein Objekt nach seiner Erzeugung noch nicht direkt in die Hierarchie der Lern- und Produkionsumgebung integriert werden, wird es zunächst in entsprechende „Leerlisten“ des Systems eingehängt. Dort kann die Bearbeitung zunächst unabhängig vom Rest der Objekte erfolgen, bevor das Element dann doch endgültig über die entsprechenden hierarchischen Funktionen in die bestehende
Umgebung integriert wird.
9.3.2.
Fehlerbehandlung
Ein wichtiger Aspekt für die Stabilität eines komplexen Systems ist das Fehlerhandling: Fehler müssen
möglichst tolerant abgefangen werden, es dürfen auf keinen Fall Inkonsitenzen auftreten, weil einzelne Operationen fehlgeschlagen sind. Ich möchte hier objektorientierte Ansätze dieses äußerst
wichtigen Systemaspektes erläutern, die in der hier skizzierten Lern- und Produktionsumgebung implementiert werden sollen.
GUTER PROGRAMMIERSTIL...
Einen ersten Beitrag zur korrekten Behandlung von Fehlern liefert ein entsprechender Programmierstil: Jede einzelne Operation, die von einer anderen abhängig ist, muß auch von deren Erfolg oder
Mißerfolg abhängig sein. Ist das Anlegen eines Objektes fehlgeschlagen, dürfen diesem nicht existenten Element selbstverständlich auch keine Attribute zugewiesen werden!
„normale“ Programmierung
fehlertolerante Programmierung
fopen (...);
// hoffentlich
fwrite (...);
fwrite (...);
fclose (...);
err= fopen (...)
// öffnen
// alles ok?
if (err != FERR)
{ written= fwrite (...);
// schreiben
// wurde alles geschrieben?
if (written == BYTES_TO_WRITE)
{ fwrite (...);
// Fehler abfangen
if (written != BYTES_TO_WRITE) err= FERR;
}
// ggf. Fehler auslösen
else err= FERR;
// Datei nur schließen, wenn sie auch ge// öffnet werden konnte.
fclose (...); // hier kann nix schiefgehen
}
// Datei
passiert
// Daten
// Daten
// Datei
öffnen
nix...
schreiben
schreiben
schließen
Dieses sehr einfache Beispiel zeigt, wie ein fehlertolerantes Programm vorgehen muß: Folgefehler
dürfen keine Rolle spielen!
Eine weitere wichtige Rolle bei der Fehlerbehandlung spielen die C++-Exceptions, die von den meisten C++-SDKs objektorientierter Datenbanksysteme unterstützt werden: Ein Fehler innerhalb eines
solchen Ausnahmeblocks kann an übergeordnete Funktionen weitergeleitet werden. Die vielen „if“Blöcke im obigen Beispiel erübrigen sich dann, da das System nach einem Fehler ohne weiteren
Seite 151
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Einfluß des Anwendungsprogrammes eine Ausnahme in der aufrufenden Instanz auslöst und die Abarbeitung der Unterfunktion sofort abbricht. Dies kann zur Zentralisierung und damit zur vereinfachten Fehlerhandhabung beitragen. Übrigens sind Exceptions die einzige Möglichkeit, auf Fehler wie
Speichermangel bei grundlegenden Funktionen wie der dynamischen Speicherallokierung (newOperator) zu reagieren.
TRANSAKTIONEN!
Die objektorientierte Datenbank unterstützt fehlertolerantes Arbeiten durch Transaktionen: Veränderungen können so vorgenommen werden, daß entweder alle oder keine der Teiländerungen übernommen werden (vgl. Kapitel 7.4.4). Sind also beispielsweise mehere Änderungen an der hierarchischen Struktur der Lernumgebung notwendig und schlägt eine fehl, kann durch das Scheiternlassen
der Transaktion der alte Zustand wiederhergestellt werden, ohne daß das System in einen undefinierten Zustand fällt.
9.3.3.
Medienelemente
Neben den in Kapitel 9.3.1 beschriebenen Grundfunktionalitäten enthalten die Medienelemente folgende Darstellungsfunktionen:
Bereich
Mediendaten
Objektinfo
Überarbeitungsinfo
Varianten
Archivinfo
Verwaltung
Objekthierarchie
Ablaufsteuerung
9.3.4.
Detaillierung
Daten auslesen/setzen/gemäß Anforderung des Systemmoduls
(Rechteck, Zeitinformation) darstellen
Attribute lesen/schreiben (ID & Erstellungsdatum nur lesen)
Überarbeitungsinfo hinzufügen/löschen/auswählen
Varianten hinzufügen/löschen/auswählen
– (über die Schnittstelle des Archivinfo-Komponentenobjektes)
Anlegen: Defaultwerte initialisieren, in entsprechende Leerliste
der Lernumgebung einhängen oder direkt einem Objekt unterordnen.
Löschen: Alle Verweise von übergeordneten Kapselungen umbiegen oder die Kapselungen löschen und Verweise von Strukturelementen auf die Kapselungen entfernen. Varianten- und
Überarbeitungsobjekte löschen. Ablaufschablonen anpassen/löschen.
übergeordnete Kapselungen ermitteln
Hierarchische Objektnavigation.
Bei dynamischen Medien: Start/Stop/Vorwärts/ZurückSchnittstelle.
Medienkapselungen
Die Medienkapselungen enthalten praktisch ausschließlich Grundfunktionalitäten in folgender Ausprägung:
Bereich
Verweisinfo
Objektinfo
Konzeptionsinfo
Überarbeitungsinfo
Varianten
Archivinfo
Detaillierung
vgl. Objekthierarchie
Attribute lesen/schreiben (ID & Erstellungsdatum nur lesen)
Verknüpfen/Verknüpfungen lösen
Infos zuweisen/auslesen
Überarbeitungsinfo hinzufügen/löschen/auswählen
Varianten hinzufügen/löschen/auswählen
Lesen und Schreiben der Attribute
Seite 152
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Bereich
Verwaltung
Objekthierarchie
Ablaufsteuerung
9.3.5.
Detaillierung
Anlegen: Defaultwerte initialisieren, in entsprechende Leerliste
der Lernumgebung einhängen oder direkt einem Objekt unterordnen.
Löschen: Alle Verweise von übergeordneten Strukturen löschen; Verweise von Medienelementen auf die Kapselungen
entfernen. Ist die zu löschende Kapselung die letzte Kapselung,
muß das Medienelement in die Leerspeicherliste des Systemmoduls eingehängt werden. Varianten und Überarbeitungsinformationen sowie Verweise von Konzeptionselementen entfernen. Ablaufschablonen anpassen/löschen.
Kopieren: Es muß eine bis auf die ID identische Kopie des
Objektes angelegt werden können. Dabei müssen Varianten,
Überarbeitungsobjekte und Verweise auf Konzeptionselemente
ebenfalls dupliziert werden.
übergeordnete Strukturelemente und untergeordnete Medienelemente ermitteln; Stellung in der Objekthierarchie ändern.
Hierarchische Objektnavigation.
Bei dynamischen Strukturen: Start/Stop/Vorwärts/ZurückSchnittstelle, die ggf. an die Medienelemente weitergegeben
wird.
Ablaufschablonen
Die Ablaufschablonen enthalten folgende Funktionalität:
Bereich
Ereignis
Reaktion
Bezugselement
Zielelement
Verwaltung
Objekthierarchie
Ablaufsteuerung
9.3.6.
Detaillierung
Ereignistyp setzen/lesen
Reaktionstyp und Verweis setzen/lesen
Verknüpfen/Verknüpfung lösen/Bezugselement ermitteln
Verknüpfen/Verknüpfung lösen/Zielelement ermitteln
Anlegen: Defaultwerte initialisieren, in entsprechende Leerliste
der Lernumgebung einhängen oder direkt Objekten zuweisen.
Löschen: Alle Verweise von übergeordneten Strukturen löschen.
Kopieren: Es muß eine bis auf die ID identische Kopie des
Objektes angelegt werden können.
übergeordnete Strukturelemente ermitteln; Stellung in der
Objekthierarchie ändern. Hierarchische Objektnavigation.
Exakt definierte Schnittstellen für alle Arten von Ereignissen;
Rückkanal zur Systemmodul (für Verzweigungen); Ablaufalgorithmen, die die einzelnen Ereignisse verarbeiten.
Strukturelemente
Die Strukturelemente enthalten folgende Funktionalität:
Bereich
Objektinfo
Verweise
Konzeptionsinfo
Darstellungsinfo
Überarbeitungsinfo
Varianten
Detaillierung
Attribute lesen/schreiben (ID & Erstellungsdatum nur lesen)
Verweise einfügen/löschen/auswählen/sortieren
Verknüpfen/Verknüpfungen lösen
Infos zuweisen/auslesen
– (über die Schnittstelle des Archivinfo-Objektes)
Überarbeitungsinfo hinzufügen/löschen/auswählen
Varianten hinzufügen/löschen/auswählen
Seite 153
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Bereich
Archivinfo
Verwaltung
Objekthierarchie
Ablaufsteuerung
9.3.7.
Detaillierung
Lesen und Schreiben der Attribute
Anlegen: Defaultwerte initialisieren, in entsprechende Leerliste
der Lernumgebung einhängen oder direkt einem Objekt unterordnen.
Löschen: Alle Verweise von übergeordneten Strukturen löschen; untergeordnete Kapselungen entfernen. Ist eine der zu
löschende Kapselung die letzte Kapselung, muß das zugrundeliegende Medienelement in die Leerspeicherliste des Systemmoduls eingehängt werden. Varianten und Überarbeitungsinformationen sowie Verweise von Konzeptionselementen müssen entfernt werden. Ablaufschablonen anpassen/löschen.
Kopieren: Es muß eine bis auf die ID identische Kopie des
Objektes angelegt werden können. Dabei müssen Varianten,
Überarbeitungsobjekte und Verweise auf Konzeptionselemente
ebenfalls dupliziert werden. Kapselungen können ebenfalls
dupliziert oder aber doppelt verwendet werden.
Eigenschaften ermitteln (Typ der Struktur, Größe bei Darstellung, Phasen, etc.)
übergeordnete Strukturelemente und untergeordnete Medienelemente ermitteln; Stellung in der Objekthierarchie ändern.
Hierarchische Objektnavigation.
Schnittstellen für Zeitereignisse (Timer-Events), Mausereignisse
(einfache Events, Drag & Drop), die entweder vom Strukturelement selbst verarbeitet (z.B. Einblenden der Phasen einer
Phasenanimation) oder an entsprechende Ablaufschablonen
weitergereicht werden.
Definierte Ein- und Austrittspunkte.
Außerdem: Navigationsfunktionalitäten, bei dynamischen
Strukturen Start/Stop/Vorwärts/Zurück-Schnittstelle, die ebenfalls ggf. an Medienkapselungen weitergegeben wird. Hierbei
sind insbesondere die Phaseninformationen zu berücksichtigen.
Lernmodule
Lernmodule stellen folgende Funktionalitäten zur Verfügung:
Bereich
Objektdaten
Kontextfunktionen
Verwaltung
Objekthierarchie
Archivinfo
Detaillierung
Attribute setzen/ermitteln
Navigationsfunktionalitäten: lineare Pfade definieren, verwalten
und löschen.
Verarbeitung der inhaltlichen Hierarchiestellung des Moduls:
setzen, verändern, ermitteln.
Anlegen: Defaultwerte initialisieren, in die Liste von Lernmdulen der Lernumgebung einhängen.
Löschen: Alle untergeordneten Strukturen löschen, sofern diese
nicht von anderen Lernmodulen referenziert werden. Dabei
ggf. Benutzerprofile updaten: sämtliche Verweise auf das
Lernmodul durch Klartextinformation ersetzen oder ganz löschen.
Distribution: Herauslösen eines Lernmoduls aus dem Gesamtkontext von System A, Einklinken in den Gesamtkontext von
System B. Dabei Berücksichtigung aller referenzierten Elemente
(von temporären Varianten abgesehen) bzw. Abgleich mit
vorhandenen Medienelementen in der Zieldatenbank.
untergeordnete Strukturelemente ermitteln.
Hierarchische Objektnavigation.
– (über die Schnittstelle des Archivinfo-Komponentenobjektes)
Seite 154
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.3.8.
Benutzerprofile
Benutzerprofile verwalten sich über die folgenden Methoden:
Bereich
Objektdaten
Kommunikationsprotokolle
Protokollierungsfunktionalitäten
Verwaltung
Objekthierarchie
9.4.
Detaillierung
Attribute setzen/ermitteln
Mails/Messages anlegen, löschen, auswählen, hierarchisch
organisieren
Sitzungsprotokolle: Aufzeichnungen von Lerneraktivitäten anlegen, löschen, verwalten (automatisiert).
Ablaufinfo: Aufzeichnungen von Lerneraktivitäten anlegen,
löschen, verwalten (auf Befehl des Benutzers, des Tutors oder
halbautomatisch über das Lernmodul).
Tooldaten: anlegen, löschen, verwalten (über die entsprechenden Toolklassen).
Anlegen: Defaultwerte initialisieren, in die Benutzerliste der
Lernumgebung einhängen.
Löschen: Alle abhängigen Strukturen löschen, ggf. Absenderangaben in Mails an Drittpersonen durch Klartextangeben ersetzen.
untergeordnete Strukturelemente (Mails) ermitteln. Hierarchische Objektnavigation.
DAS SYSTEMMODUL
Systemweite Basisfunktionalitäten
Neben den Datenbankobjekten müssen auch noch andere Komponenten existieren, die die Objekte
„zusammenhalten“ und dem Benutzer verfüg- und benutzbar machen – vgl. Kapitel 5.1.1. In dem in
diesem Kapitel beschriebenen Systemmodul sind alle Teilkomponenten zusammengefaßt, die systemweit ansprechbar sein müssen. Diesen Teilkomponenten habe ich mich im Kapitel 9.6 detailliert
gewidmet.
Die in Kapitel 5.1.1 vorgenommene inhaltliche Trennung der Komponenten gebe ich hier auf, da sie
auf der programmiertechnischen Ebene wenig sinnvoll erscheint: Funktionalitäten doppelt und dreifach zu implementieren, um einer strikten Modularität zu genügen, widerspricht effizienter Programmierung. Aus diesem Grunde existiert das Systemmodul, das die Grundlage aller Komponenten
aus Kapitel 5.1.1 bildet.
9.4.1.
Struktur des Systemmoduls
Das Systemmodul übernimmt folgende Funktionalitäten und stellt sie den übrigen Komponenten zur
Verfügung:
Ablauflogik. Das Systemmodul sorgt dafür, daß die korrekten Objekte zur richtigen Zeit gemäß
Ablaufschablonen geladen und ausgeführt werden.
Darstellungsverwaltung. Das Systemmodul steuert den Bildschirmaufbau, indem es die Befehle
zur Darstellung nach Bedarf an neu zu zeichnenden Objekte verschickt.
Ereignisverwaltung. Übernimmt auf dem Client die Überwachung der Benutzeraktivität und leitet die entsprechenden Weiterleitungen ein.
Kommunikation – alle Grundfunktionalitäten für den Netzwerkbetrieb.
Seite 155
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Sonstiges: Andere Funktionalitäten, z.B. das Abspeichern und Laden von Dateien außerhalb des
Datenbankkonzeptes.
9.4.2.
Ereignisverwaltung
Die Ereignisverwaltung ist die Schnittstelle zum Betriebssystem: Sie verarbeitet sämtliche Messages,
die (beispielsweise) Windows anliefert, und verteilt sie an Ablauflogik (Benutzerinteraktionen, also
beispielsweise Mausereignisse) oder Darstellungsverwaltung (Redraw-Befehle etc.).
9.4.3.
Ablauflogik
Primäre Aufgabe der Ablauflogik ist es, die von der Ereignisverwaltung angelieferten InteraktionsEreignisse zu verarbeiten und an die entsprechenden Ablaufschablonen zu verteilen.
Der ablaufbezogene Teil des Systemmoduls muß aber auch den Ablaufschablonen Funktionalitäten
zum direkten Anspringen von Strukturelementen bieten. Dazu müssen die entsprechenden Routinen
des Darstellungsmoduls aufgerufen werden, die eine entsprechende Aufbereitung des Sprunges für
den Bildschrm übernehmen.
Ebenso müssen die Ablauffunktionalitäten die interne Koordination gewährleisten – es müssen die
korrekten Ablaufschablonen gefunden und entsprechend verarbeitet und verwaltet werden.
9.4.4.
Darstellungsverwaltung
Die Darstellungsverwaltung übernimmt die Aufgabe, Befehle zum (Neu-) Zeichnen von Bildschirmausschnitten auf die Medienelemente zu „verteilen“. Hierzu müssen die von der Ereignisverwaltung
(und damit vom Betriebssystem) gelieferten Rechtecklisten analysiert und in objektgerechte Rechteck-Teillisten aufbereitet werden, die an die jeweils betroffenen Objekte verschickt werden. Hierbei
wird die Reihenfolge der Objekte in den Listen der übergeordneten Strukturelemente zugrundegelegt – somit werden übereinanderliegende Objekte automatisch korrekt dargestellt.
9.4.5.
Kommunikation
Hier sind die Kommunikationsfunktionen angesiedelt, die von übergeordneten Modulen für das
Chatten und für das Versenden von Mails aus dem Intranet heraus verwendet werden können. Dies
entspricht einem Teil der in Kapitel 5.1.2 vorgestellten Netzwerkkomponente.
Die grundlegenden Netzwerkprotokolle hingegen werden schon von der objektorientierten Datenbank auf Basis von TCP/IP bereitgestellt. Übrigens können durch die umfassende TCP/IP-Einbindung
objektorientierter Datenbanken sämtliche nicht-echtzeitabhängige Kommunikation innerhalb der
Lernumgebung vollständig über die Datenbank erfolgen: Das „Versenden“ von Mail oder das Verfassen eines Diskussionsbeitrages entspricht dem Anlegen eines entsprechenden Objektes; das Lesen
eines solchen Beitrags besteht aus dem Abruf und der anschließenden visuellen Aufbereitung des jeweiligen Objektes. Die eigentliche Intranet-Kommunikation übernimmt die Datenbank selbständig.
Seite 156
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.4.6.
Sonstiges
Im Systemmodul sind zusätzlich noch die üblichen „nützlichen kleinen Helferlein“ integriert wie beispielsweise das Abspeichern von Daten in Dateien („Export“) statt in die Datenbank. Auch auf diese
Funktionalitäten, die in diesem Stadium des Systementwurfs noch nicht ausdetailliert werden können, können die Lernmodule über eine exakt definierte Schnittstelle zugreifen.
9.5.
SCHNITTSTELLEN
Kommunikation der Objekte untereinander
Was bedeutet „Kommunikation von Objekten untereinander“? – Nun, letztlich dabei werden nur
genau definierte Schnittstellenmethoden aufgerufen, die dann eine exakt definierte Aufgabe/Funktionalität erledigen. Sollen neue Medien- oder Strukturelemente unterstützt werden, müssen
diese lediglich die bestehenden Konventionen beachten – sind die Schnittstellen entsprechend flexibel gestaltet, kann der Umfang der Lern- und Produktionsumgebung problemlos und vor allem einfach erweitert werden.
Ich werde in diesem Kapitel einige allgemeinen Aussagen über die meinem Systementwurf zugrundeliegenden Schnittstellenprinzipien treffen. Konkretere Schnittstellenentwürfe finden sich beispielhaft (soweit in diesem Stadium des Systementwurfs überhaupt möglich) im folgenden Kapitel über
Module.
9.5.1.
Ziele von Schnittstellengestaltung
Zunächst muß das „Pflichtenheft“ erstellt werden: Welche Fähigkeiten und Möglichkeiten sollen die
Schnittstellen des hier vorgestellten Systems erfüllen können?
DEFINIERTHEIT
Extrem wichtig ist eine sehr genaue und exakte Beschreibung, was jede einzelne Schnittstellenmethode leisten kann und muß. Es dürfen hier keine Interpretationsmöglichkeiten gelassen werden, die
zu ungenau implementierten Modulen und damit zu „Seiteneffekten“ führen können.
Um es vorweg zu nehmen: Eine derartige Feindefinition für die hier vorgestellten Objekte würde den
Rahmen dieser Diplomarbeit bei weitem sprengen. Ich möchte diesen Punkt nur für den Anforderungskatalog für eine Realisierung vormerken und in dieser Arbeit wiederum eine themenbezogene,
aber allgemein gehaltene Abhandlung zu diesem Thema vornehmen.
ERWEITERBARKEIT
Ganz entscheidend in modernen Computer-Systemen ist die einfache Erweiterbarkeit, die sich beispielsweise in komponentenbasierten Systemen wie OLE/COM (Windows) oder OpenDoc (Apple
MacIntosh) widerspiegeln. Komponententechnologie ist ein wichtiger Bestandteil objektorientierter
Programmierung – und dementsprechend modular ist auch das hier vorgestellte System aufgebaut.
Auch auf diesen Gesichtspunkt möchte ich nur beispielhaft eingehen, da seine ausführliche Darstellung nicht Sinn und Zweck dieser Diplomarbeit sein kann.
Seite 157
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.5.2.
Definiertheit
Definiertheit bedeutet, daß eine Schnittstellenmethode
prinzipiell immer die gleiche Funktionalität aufweist
immer die selben Eigenschaften ihres Objektkontextes bei der Ausführung miteinbezieht
ihren Kontext immer in einem genau definierten Zustand hinterläßt.
Am Beispiel einer Schnittstellenmethode zum Zeichnen einer Linie bedeutet dies, daß jedes Darstellungsmodul die Linie genau von dem ihr übergebenen Start- und Endpunkt immer auf die gleiche
Weise zeichnen muß – also als beispielsweise als Gerade und nicht als Bezierkurve oder B-Spline.
Die Einbeziehung des Objektkontextes besagt, welche Parameter beim Zeichnen wie berücksichtigt
werden müssen (vgl. auch die Bedeutung des „Device Context“ in Windows-Anwendungen; Petzold/Yao, 1996[46], S.115ff) – also beispielsweise die Liniendicke, der Linienstil, die Farbe, der Zeichenmodus, das verwendete Koordinatensystem; aber auch, wie die Start- und Endkoordinaten interpretiert werden müssen, wenn die Liniendicke mehr als einen Pixel beträgt.
Die Forderung, einen „genau definierten Zustand zu hinterlassen“, besagt, daß von einer Schnittstellenmethode, die nicht explizit dafür vorgesehen ist, keine Kontext-Eigenschaften verändert werden
dürfen. Komplexe Zeichenoperationen, die ggf. aus mehreren einfachen zusammengesetzt sind und
deshalb während ihrer Ausführung den Kontext verändern, müssen, den Ausgangszustand selbständig
wiederhergestellen. Doch das Prinzip wird auch auf nicht-öffentliche Eigenschaften eines Moduls angewandt: Für jedes Attribut muß genau festgelegt werden, in welchem Zustand es von einer Schnittstellenfunktion vorgefunden wird und wie es hinterlassen werden muß.
Auf eine Windows-Grafikschnittstelle übertragen bedeutet dies beispielsweise, daß eine Schnittstellenfunktion einen gültigen Device Context als Attribut vorfindet, den sie zwar zur Ausgabe verwenden muß, aber auf keinen Fall verändern darf.
All diese Aspekte müssen bei einer Systemkonkretisierung auf den jeweiligen Einzelfall übertragen
werden, um das System stabil zu gestalten.
9.5.3.
Erweiterbarkeit
Prinzipiell lassen sich erweiterbare Schnittstellensysteme sowohl über Polymorphie – erweiterte
Funktionalitäten werden in einer abgeleiteten Klasse definiert – oder über die Abfrage der Fähigkeiten des jeweiligen Moduls realisieren:
Polymorphie:
Klassifizierung:
// Basis-Darstellungsmodul:
// allgemeines Darstellungsmodul
class BasicDisplayModule
{
private:
// hier sind die Daten, z.B. Device Context,
// Font- oder Menühandles gespeichert.
class DisplayModule
{
private:
// hier die Daten
public:
// hier sind die Schnittstellenfunktionen,
// z.B. Kreis zeichnen, Textausgabe, etc.
// abgelegt.
};
public:
// hier die Methoden - grundlegende und
// erweiterte, bunt gemischt
...
// ... und zusätzlich: Klassifizierung
// der Möglichkeiten des Moduls
DWORD getClassification (...);
};
Seite 158
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Polymorphie:
Klassifizierung:
// erweitertes Modul:
class ThreeDDisplayModule :
public BasicDisplayModule
{
private:
// hier sind die erweiterten Daten, z.B.
// DirectX-Surfaces, Interafces, etc.
// gespeichert.
public:
// hier sind die erweiterten Schnittstellen// funktionen, z.B. Polygon darstellen,
// Modell rendern, etc. abgelegt.
};
Die linke Methode (Polymorphie) bietet den unschätzbaren Vorteil der (beinahe) unbegrenzten Erweiterbarkeit; allerdings birgt diese Lösung die Gefahr, daß Module auf bestimmten Plattformen
nicht abgespielt werden könnnen, weil die von den erweiterten Medienobjekten aufgerufenen Funktionen auf einzelnen Rezeptionssystemen nicht installiert sind. Man betrachte die Vorteile beispielsweise beim Einsatz einer 3D-Add-On-Karte (wie Vodoo 2): Die Basisfunktionalitäten werden von
Standard-DirectX- oder GDI-Modulen abgedeckt, 3D-Funktionen können in einer erweiterten Darstellungsklasse speziell für die herausragende Performance des Vodoo-Chips angepaßt werden.
Die zweite Methode bietet keine nennenswerten Vorteile – auch hier werden nicht implementierte
Funktionen selbstverständlich nicht ausgeführt. Das Programm kann allerdings durch die Klassifizierungsmethode flexibler reagieren. Darüber hinaus ist diese Lösung aber wesentlich unflexibler – eine
quasi beliebige Erweiterbarkeit ist schon gar nicht möglich. Ebensowenig kann ein erweiterter Treiber
auf einem bestehenden aufgesetzt werden.
Aus diesen Gründen wird das von mir skizzierte System einmal mehr auf objektorientierte Technologien – hier Polymorphie – zurückgreifen. Objekthierarchien und Polymorphie sind also auch bei der
Schnittstellengestaltung wichtige Schlüsseltechnologien: Sie ermöglichen ein einfaches und effizientes
Erweitern der Funktionalität eines Systems, ohne bestehende Konzepte „über den Haufen zu
schmeißen“.
9.6.
MODULE
Konkretisierungen
Die Module sind das Herz eines objektorientierten, erweiterbaren Systems: Über sie können Funktionalitäten erweitert oder ergänzt werden; sie stellen alle benötigten Funktionalitäten zur Verfügung,
die von den Objekten der Lern- und Produktionsumgebung benötigt werden. Ich habe dabei für
meine Ausführungen die interessantesten Aspekte herausgepickt.
9.6.1.
Systemmodul
Das Systemmodul habe ich bereits in Kapitel 9.4 beschrieben. Die wichtigsten Komponenten – das
Darstellungsmodul, die Ablauflogik und die Ereignisverwaltung – sind in den folgenden Unterkapiteln
noch einmal detaillierter beschrieben. Da ein Großteil der Kommunikationsfunktionen bereits durch
Seite 159
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
das Datenbanksystem abgedeckt sind (und die entsprechenden Schnittstellen damit bereits festgelegt
sind), schließe ich sie in diesem Kapitel von einer näheren Betrachtung aus.
9.6.2.
Ereignisverwaltung
Gemäß der Philosophie ereignisorientierter Betriebssysteme (Windows, Mac, ...) beinhaltet die Ereignisverwaltung eine zentrale Stelle in der Schnittstelle zum Betriebssystem: Das Betriebssystem als
„Herrscher über Maus, Tastatur und Bildschirm“ teilt den Anwendungsprogrammen alles Wissenswerte über die Umtriebe des Benutzers mit.
VERTEILUNGSMECHANISMEN
Betriebssysteme wie Windows unterscheiden meist zwischen Darstellungs- (Redraw, Fensteränderungen, etc.) und Ablauf-Ereignissen (Benutzer-Interaktionen, zeitgesteuerte Ereignisse). Dementsprechend können die Ereignisse ziemlich eindeutig den Komponenten „Darstellungsmodul“ und „Ablaufverwaltung“ bzw. den zugrundeliegenden Medienelementen oder Ablaufschablonen zugeordnet
werden.
AUFTEILUNG
Neben einer Weitergabe an die jeweiligen Objekte werden diverse Ereignisse auch im Systemmodul
selbst bearbeitet: Wird beispielsweise die Fenstergröße auf der Abspielplattform verändert, wird nur
bei Bedarf eine entsprechende Redraw-Aufforderung an die betroffenen Medienelemente geschickt.
Anders ausgedrückt: Interaktionen, die sich lediglich auf die Benutzeroberfläche auswirken, werden
soweit möglich mit clientseitigen „Hausmittelchen“ bearbeitet.
Es ergibt sich folgende Aufteilung:
OS-Event
Ereignisverwaltung
Weiterleitung gemäß Typ
Ablaufmodul
Aufbereitung
Darstellungsmodul
Rückmeldung
Aufbereitung
Rückmeldung
Datenbank-Objekte
Das OS-Event wird also an die anderen Komponenten des Systemmoduls weitergegeben. Diese bereiten es in entsprechende Redraw- bzw. Ablaufschablonen-Aufrufe auf. Die Ablaufschablonen bzw.
Redraw-Methoden der Medienelemente können dann wiederum das Darstellungsmodul bzw. die
Ablaufverwaltung aufrufen, um auf das Ereignis korrekt zu reagieren.
9.6.3.
Ablaufverwaltung
Die Ablaufverwaltung stellt Schnittstellen zur Realisierung von Programmverzweigungen zur Verfügung. Dies bedeutet, daß anhand eines gegebenen Zielstrukturelementes der korrekte Bildschirmaufbau automatisch erledigt werden können muß. Die dafür zuständigen Schnittstellenfunktionen
müssen die Objekthierarchie bis zu einem übergeordneten Strukturelement durchforsten, das für einen Neuaufbau des Bildschirms zuständig ist, also beispielsweise ein Seitenobjekt. Von dort aus werSeite 160
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
den alle untergeordneten Elemente gemäß Phase des Zielstrukturelementes zur Darstellung „aufgefordert“ – vgl. Kapitel 6.3.3.
Weiterhin gewährleistet die Ablaufverwaltung, daß die korrekten Ablaufschablonen für eine Benutzerinteraktion aufgerufen wird – das Modul übernimmt also das Aufbereiten und Weiterleiten der
Ereignisse der Ereignisverwaltung (vgl. voriges Unterkapitel). Hierfür müssen Funktionalitäten integriert sein, die beispielsweise vom Ort eines Klicks auf das Zielobjekt unter Berücksichtigung der visuellen Objektschichtung schließen, dieses nach einer geeigneten Ablaufschablone durchforsten und
dann die entsprechende Schnittstellenfunktion auslösen. Ebenso muß die Ablaufverwaltung ggf. das
Ereignis die Hierarchie aufsteigen lassen, falls das Zielelement das Ereignis nicht verarbeitet.
Da Funktionalitäten wie Rechteck- oder Polygonberechnungen, aber auch erweiterte Darstellungsmöglichkeiten wie bei 3D-Objekten, in enger Abhängigkeit mit den Darstellungsmodulen erfolgen,
existieren hierfür entsprechende „intermodulare“ Schnittstellen.
9.6.4.
Darstellungsmodule
Darstellungsmodule kapseln die Grafikfunktionen des jeweiligen Betriebssystems. So können die
Medienobjekte zumindest teilweise von der Plattform des Betriebssystems unabhängig gehalten werden – statt die Medienobjekte komplett neu zu programmieren, muß lediglich ein plattformspezifisches Darstellungsmodul zur Verfügung gestellt werden.
Darstellungsmodule sind auch die Grundlage von Cross-Media-Publishing, insbesondere wenn zusätzlich noch speziell auf die jeweilige Medienplattform zugeschnittene Designs über Varianten realisiert werden: Es muß dann „nur“ ein Darstellungsmodul zur Verfügung gestellt werden, das die notwendigen Umrechnungen in das durch die Variante angepaßte, medienspezifische Format vornimmt. Durch diese zweifache Anpassung der Darstellung können nahezu beliebige Medienplattformen optimal unterstützt werden.
STANDARD-DARSTELLUNGSMODUL: AUSGABE ÜBER DAS WINDOWS GDI
Das Windows GDI („Graphical Device Interface“) stellt eine standardisierte Schnittstelle zur Verfügung, über die von der Grafikhardware unabhängig Ausgaben auf dem Bildschirm realisiert werden
können. Somit ist es bereits eine Art betriebssystemabhängiges Darstellungsmodul. Da sich die Definition der Objekte und ihrer Funktionalitäten eng an der Definition des GDI-Standards orientiert
(schließlich ist ToolBook, das ja als Grundlage der Objektdefinitionen diente, eine reine WindowsAnwendung), würde das GDI-Darstellungsmodul lediglich aus einer Kapselung der entsprechenden
Windows-Funktionen bestehen.
Ein interessanter Aspekt in einem Windows-Modul ist sicherlich die Unterstützung von beschleunigten Funktionen – Stichwort „DirectX“: Für maximale Performance können bei installierter Betriebssystemerweiterung die entsprechend getunedten Funktionen aufgerufen werden. Diese Beschleunigung kann von den Lernmodulen unbemerkt geschehen, indem das Windows-Modul automatisch
zwischen GDI und DirectX hin- und herschaltet, oder über ein spezielles DirectX-Darstellungsmodul,
welches vom Benutzer explizit eingebunden werden muß.
Interessant beispielsweise für virtuelle Welten: Unterstützen die entsprechenden Darstellungsmodule
(Direct3D oder OpenGL) eine Funktionalität, können die entsprechenden Funktionen direkt aufgerufen werden. Werden 3D-Funktionalitäten vom Betriebssystem oder der Medienplattform nicht unterstützt (z.B. bei Windows ohne DirectX), kann entweder eine Fehlermeldung ausgegeben oder eine
entsprechende selbstprogrammierte Emulation verwendet werden. Da eine Emulation der entspreSeite 161
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
chenden Betriebssystemerweiterung wohl einen nicht zu rechtfertigenden Aufwand bedeuten würde,
wäre die Bereitstellung alternativer Seiteninhalte ohne virtuelle Welten über Varianten ein geeigneter
Kompromiß.
EIN „EXOTISCHES“ DARSTELLUNGSMODUL: GRAFIKEN & INTERAKTIONEN MIT DHTML
Das Darstellen eines Bildes mittels DHTML erfordert zunächst das Anlegen eines Layers, der das entsprechende Bild umfaßt. Die Bilddaten müssen ins GIF-Format konvertiert werden und über ein
temporäres Verzeichnis dem DHTML-Dokument zur Verfügung gestellt werden (und nach Verlassen
der Seite wieder gelöscht werden).
DHTML-Beispiel (Netscape Communicator 4.x):
...
<!-- Grafik: erste Animationsphase -->
<LAYER ID=”Phase_01” VISIBILITY=”true” TOP=”150” LEFT=”150” HEIGHT=”150” WIDTH=”150”>
<IMG SRC=”tmp071523621234.gif” WIDTH=”150” HEIGHT=”150” BORDER=”0” VSPACE=”0” HSPACE=”0”>
</LAYER>
...
Bei derartigen clientseitigen Konstrukten tritt ein Problem auf: Darstellung und Programmablauf können nicht mehr strikt getrennt werden – schließlich müssen Interaktionen in den „Darstellungscode“
integriert werden – und diese Interaktionen werden laut Systemdefinition ja nicht vom Darstellungs-,
sondern vom Anlaufmodul generiert:
DHTML-Beispiel für Interaktionen (Netscape Communicator 4.x):
...
<!-- anklickbare Grafik -->
<LAYER ID=”Phase_01” VISIBILITY=”true” TOP=”150” LEFT=”150” HEIGHT=”150” WIDTH=”150”>
<A HREF=”javascript:doLink ();”><IMG SRC=”tmp071523621234.gif” WIDTH=”150” HEIGHT=”150”
BORDER=”0” VSPACE=”0” HSPACE=”0”></A>
</LAYER>
...
Eine Lösung ist beispielsweise die Anwendung von serverseitigen Skripts, die erstens die notwendigen
Informationen des Darstellungsmoduls anfordern und zweitens bei Bedarf den Ablauf durch die entsprechende Aufrufe des Ablauflogik-Moduls ergänzen. Derartige serverseitige Skripts nennen sich bei
Micorsoft „Active Server Pages“ (im Beispiel verwendet) und auf Linux-Basis („Apache“) „PHP“.
DHTML-Beispiel für Interaktionen (ASP):
...
<!-- anklickbare Grafik -->
<% Call StartRectArea (150, 150, true, ...) %> <!-- Darstellungsmodul -->
<% Call StartInteractionOutOfDatabase (“event”, “action”) %> <!-- Ablaufmodul -->
<% Call GenerateImage (“OBJ_ID_Phase_01”, ...) %> <!-- Darstellungsmodul -->
<% Call EndInteractionOutOfDatabase %> <!-- Ablaufmodul -->
<% Call EndRectArea () %> <!-- Darstellungsmodul -->
...
Der ASP-Code übernimmt also letztlich die Kommunikation mit den unterschiedlichen Systemkomponenten – nachdem er vom Darstellungsmodul generiert wurde. Die Verschachtelung erfolgt über
CGI-Programme (bzw. ISAPI oder NSAPI) und COM.
Der Name von temporär angelegten Dateien kann übrigens direkt aus der eindeutigen Nummer des
jeweiligen Objektes abgeleitet werden. Um intranetfähig zu bleiben – also keine Dateien zu löschen,
die noch von anderen Benutzern benötigt werden, können die temporären Dateien in einem für den
jeweiligen Benutzer spezifischen Unterverzeichnis vorgehalten werden.
Seite 162
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Probleme machen spezielle Features wie unregelmäßige Hotspots, die von DHTML nicht oder nur
unzureichend unterstützt werden: Hier sollte wiederum auf die Verwendung von Designvarianten
ausgewichen werden, die dieses Problem dann elegant umgehen können.
SCHNITTSTELLENDEFINITION
Die Schnittstellenfunktionen müssen neben allgemeinen Verwaltungs- und Initialisierungsfunktionen
einen dem Umfang der unterstützten Medienobjekte entsprechenden Funktionsumfang realisieren:
Es müssen einerseits einfache Grafikgrundelemente wie Rechtecke, Kreise, Texte oder Bitmaps gezeichnet, andererseits aber auch komplexe Elemente wie Videos oder virtuelle Welten dargestellt
werden können.
Um diesen sehr unterschiedlichen Anforderungen gerecht zu werden, wird nicht ein einziges, monolithisches Darstellungsmodul implementiert, sondern aufeinander aufbauende Darstellungsmodule
mit unterschiedlichen Fähigkeiten: Beispielsweise ein Modul, das die Grundfunktionen abdeckt, und
eine Zusatzkomponente, die weiterführende Funktionalitäten wie 3D-Darstellungen realisiert (vgl.
Kapitel 9.5.3.
GRUNDLEGENDE FUNKTIONALITÄTEN
Jedes Darstellungsmodul muß aufgrund der in dieser Arbeit vorgenommenen Mediendefinitionen
folgende Funktionalitäten unterstützen:
Funktionalität
Darstellung
Fensterverwaltung
Bereichsberechnungen
Überlappungen
Auswirkungen
Darstellung eines statischen Elementes anhand von Bildschirmposition, Sichtbarkeit und Ausschnitt. Oder: Darstellung eines dynamischen Elementes anhand von
Bildschirmposition, Sichtbarkeit, Ausschnitt und zeitabhängigen Infos. Hierbei
müssen alle Medientypen aus Kapitel 5.2.5 unterstützt werden.
Ebenso sollten Double-Buffering-Mechanismen für einen flackerfreien Bildschirmaufbau zur Verfügung gestellt werden: Das Bild wird unsichtbar in einem
Hintergrundbuffer aufgebaut und erst nach vollendetem Aufbau am Stück in den
Bildschirmspeicher kopiert.
Fensterverwaltung, ähnlich wie in Windows. Es müssen unabhängige „Unterfenster“ ansprechbar sein, außerdem muß auf Größen- und Positionsänderungen
entsprechend reagiert werden können.
Hier werden Bereichsberechnungen vorgenommen, um beispielsweise den genauen Hotspot eines Polygons oder einer Bitmap zu bestimmen. Die Funktion ist
im Darstellungs-Modul untergebracht, da so auch diverse Hardwarebeschleunigungen ausgenützt werden können (beispielsweise Dreicks-Generatoren von 3DGrafikkarten, etc.)
Von den Bereichsberechnungen abhängig sind die Überlappungsberechnungen:
Diese Funktionen berechnen, ob sich zwei – auch unförmige – Objekte überlappen. Wird beispielsweise von der Ablaufverwaltung verwendet, um einen Mausklick zuzuordnen.
ERWEITERTE FUNKTIONALITÄTEN
Erweiterte Funktionalitäten wie 3D-Welten beinhalten gleichzeitg erweiterte Medien- und Strukturelemente (ebenfalls aus Knoten und Kanten bestehend). Dementsprechend kann in diesem Systementwurf keine konkrete Aussage über derartig erweiterte Schnittstellenfunktionalitäten gemacht werden – sie ist einfach zu eng mit der erweiterten Darstellung verknüpft: so wird ein 3D-Modul beispielsweise die entsprechenden Routinen zur dreidimensionalen Darstellung und Kollisionsabfrage
bereitstellen.
Seite 163
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
9.6.5.
„Benutzermodule“
Zuletzt möchte ich noch auf die „Benutzermodule“, also die Komponenten aus Kapitel 5.1.1 eingehen. Sie bilden sozusagen die Benutzerschnittstelle. Forderungen sind daher:
Unterstützung aller Möglichkeiten einer Lern- und Produktionsumgebung (vgl. Abschnitte 4
und 5).
Einfache und möglichst flexible Konfigurierbarkeit. Dies entspricht der mediendidaktischen
Forderung nach dem situativen Kontext – und damit nach einer individuell gestaltbaren Umgebung. Gute Beispiele für eine weitgehende Konfigurierbarkeit sind beispielsweise die Produkte
aus der „Office“-Reihe von Microsoft.
Einheitliches Look & Feel. Dies ist eine Aufgabe des Interface-Designs und soll deshalb hier nicht
weiter behandelt werden.
VERWENDUNG VON ALLGEMEINEN FUNKTIONALITÄTEN
Die Benutzermodule können alle Funktionalitäten des Grundsystems verwenden. Mit anderen Worten: Die Benutzeroberfläche selbst kann als eine Menge von standardisierten Medienelementen,
Strukturen und Abläufen aufgefaßt werden, die ggf. um spezielle Funktionalitäten erweitert werden.
Die Verwaltung erfolgt durch das Systemmodul, spezielle Funktionalitäten werden über spezielle,
erweiterte Elemente oder Ablaufschablonen realisiert.
Beispiel Login-Prozeß: Die Dialogbox zur Eingabe von Benutzername und Paßwort ist eine Gruppe
von Medienelementen, das Einloggen selbst wird durch spezielle Ablaufschablonen, die auf den Einlog-Button reagieren, Name und Paßwort verschlüsseln und (aus Sicherheitsgründen) zur serverseitigen Autorisierung verschickt.
WIE FUNKTIONIERT’S?
Der konkrete Aufbau der Benutzeroberfläche der Lernumgebung ist ebenfalls in das Systemmodul integriert: Es können Objekte innerhalb des Anwendungs-Hauptfensters definiert werden, die entweder das Benutzermodul selbst oder einen Link zu einem entsprechenden Inhalt beinhalten. Dies entspricht der Forderung nach maximaler Konfigurierbarkeit. Das Benutzermodul selbst ist wieder wie
im vorigen Unterpunkt beschieben aus Elementen des Systems mit entsprechenden Erweiterungen
aufgebaut.
So kann ein Inhaltsfenster der Anwendung beispielsweise so definiert werden, daß dort großflächige
Benutzermodule wie die Zugriffsfunktionalitäten oder die Lernmodule selbst abgespielt werden. Um
dieses Inhaltsfenster herum sind Buttons für den Aufruf großflächiger Module und Module, die wenig
Platz beanspruchen oder permanent benutzt werden können (beispielsweise Chat), direkt angeordnet.
BEISPIEL
Das folgende Beispiel zeigt, wie Benutzeroberflächen mit Benutzermodulen realisiert werden können. Es handelt sich dabei aber ausdrücklich um kein ausgearbeitetes Design – vielmehr als Anregung, wie man sich eine von vielen möglichen Benutzeroberflächen vorstellen kann.
Seite 164
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Die Buttonleiste links ist ein Beispiel für verlinkte Module: Bei Klick auf einen Button wird das entsprechende Modul über eine Ablaufschablone aktiviert und rechts im Inhaltsfenster geöffnet. Das
Chatmodul hingegen ist direkt in die Oberfläche integriert (unten).
9.6.6.
Erweiterungen im Objektmodell
Module, die bestehende Funktionalitäten erweitern, sollen auch auf bestehenden Modulen aufbauen. So sollte eine 3D-Erweiterung den Prinzipien des 2D-Darstellungsmoduls folgen, muß allerdings
nicht dessen Methoden mitbenutzen. Objekttechnisch gesprochen sind Erweiterungsmodule Ableitungen ihrer Grundmodule – und es findet sich immer ein Grundmodul:
Bei erweiterten Medienelementen: das Mediengrundelement bzw. die Mediengrundkapselung.
Sie haben meist erweiterte Darstellungsmodule zur Folge.
Bei erweiterten Strukturelementen: das Grund-Strukturelement. Erweiterungen hier können erweiterte Ablaufschablonen nach sich ziehen.
Bei erweiterten Ablaufschablonen: die allgemeinen Ablaufschablonen
Bei erweiterten Darstellungsmodulen: das Basis-Darstellungsmodul
Bei erweiterten Benutzerprofilen: das Grundprofil. Sollen die erweiterten Funktionen auch Auswirkungen auf die Benutzeroberfläche bzw. die Funktion von Benutzermodulen haben, müssen
die entsprechenden Benutzermodule ebenfalls erweitert werden.
Bei erweiterten Benutzermodulen: das jeweilige Basis-Benutzermodul. Hierbei dürfen die
Schnittstellen nicht erweitert werden, ohne das System selbst mit diesen Erweiterungen neu zu
definieren.
Bei erweiterten Lernmodulen: das Basis-Lernmodul. Auch hier müssen die entsprechenden Erweiterungen über Erweiterungen anderer Module „aktiviert“, also dem Benutzer verfügbar gemacht werden.
9.6.7.
Einordnung in den Client/Server-Kontext
Abschließend möchte ich noch kurz eine Einordnung der Module in das Client/Server-Modell eines
Intranets vornehmen.
Prinzipiell können alle Module entweder serverseitig oder auf dem Client ausgeführt werden (vgl.
hierzu auch die Definition relevanter Intranet-Architekturen in Kapitel 7.3). Durch die Funktionalität
der einzelnen Module ist allerdings eine mehr oder weniger genaue Zuordnung möglich und notwendig:
Seite 165
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
Komponente
Objekte
Module
Ort
Daten auf Datenbankserver
Methoden und Runtime-Bibliotheken auf Client (TwoTier-Architektur) oder Anwendungsserver (Three-TierServer)
auf Client (Two-Tier Architekturen) oder Anwendungsserver (Three-Tier-Architekturen)
In diesem Zusammenhang ist sicher noch eine kurze Betrachtung der klassischen Three-TierArchitektur für das Web interessant: Ein Anwendungsserver bereitet alle Inhalte in HTML-, Java- und
JavaScript-Code auf; der Lerner benötigt nur einen Browser zur Darstellung.
HTML-BASED TRAINING
Prinzipiell sind HTML-basierte Multimedia-Anwendungen kein Problem – wenn ein entsprechendes
Darstellungsmodul geschrieben wird und die Einschränkungen von HTML beim Design beachtet
werden.
Diese beiden Punkte zeigen schon die Problematik HTML-gestützten Lernens mit dem hier geschilderten System auf: Ein entsprechendes Darstellungsmodul muß recht aufwendige Konvertierungen
vornehmen, da viele der gemäß dieser Ausarbeitung unterstützten Elemente nicht direkt von HTML
unterstützt werden. Dies zwingt den Anwendungsserver schnell in die Knie. Außerdem lassen sich
die prinzipiellen Designschranken von HTML auch mit einem ausgeklügelten Darstellungsmodul
nicht völlig umgehen.
Dennoch ist HTML-basiertes Lernen eine echte Alternative – wenn vergleichsweise einfache Inhalte
mit spezialisierten Designs umgesetzt werden sollen. Nur innerhalb eines vorgegebenen Rasters positionierbare Grafiken als erweiterte Medienelemente ersparen beispielsweise die freie Positionierung
von HTML-Elementen; fehlen komplexe Interaktionen, können Standardelemente wie HTMLFormulare verwendet werden. Außerdem könnten spezielle Funktionalitäten als Java-Applets, PlugIns oder ActiveX-Controls42 (für den Internet Explorer) außerhalb des HTML-Korsetts eingebunden
werden. Hier müßte eine Kosten/Nutzen-Rechnung erstellt werden, ob ein einigermaßen vollständiges HTML-Modul nicht aufwendiger als ein spezielles Darstellungsmodul in Form eines Plug-Ins wäre.
9.7.
FAZIT
Am Ende der Theorie
An dieser Stelle möchte ich die theoretischen Ausführungen abbrechen: Die Grundpfeiler einer intranetbasierten Lern- und Produktionsumgebung sind ausreichend definiert, und es ist in diesem Stadium unmöglich, noch tiefer in die Materie einzusteigen, ohne die hier aufgestellten Theorien und
Entwürfe durch Prototypen zu verifizieren und ggf. auch zu überarbeiten.
Deshalb möchte ich im nächsten Abschnitt einen Prototypen vorstellen, der die Grundprinzipien anhand eines sehr eingeschränkten Funktionsumfanges realisiert und deshalb auch zu einem besseren
Verständnis der hier dargelegten, doch ziemlich abstrakten Vorgaben führen sollte. Der Prototyp enthält die technischen Grundlagen – also wie Lernmodule prinzipiell aufgebaut und dargestellt werden
42
Im Intranet sind die Sicherheitsmängel des ActiveX-Konzeptes vertretbar – schließlich kann davon ausgegangen werden, daß der IntranetAdministrator keine „feindlichen“ Controls installiert.
Seite 166
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Der Systementwurf – Zusammenführung, Schnittstellen & mehr
können. Die Konzeptionsebene mußte komplett weggelassen werden, da dies den Rahmen bei weitem gesprengt hätte. Produktions- und Rezeptionsoberfläche wurden aus den gleichen Gründen auf
eine einfache Windows-Anwendung mit wertebasiertem Interface reduziert. Dennoch werden die
Grundprinzipien von „Multimedia aus einer objektorientierten Datenbank“ meiner Meinung nach
sehr schön aufgezeigt.
Seite 167
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
10.
In die Praxis
Implementierung & Prototyp
Nachdem ich den Systementwurf soweit es mir sinnvoll erschien detailliert habe, möchte ich nun die
graue Theorie ein wenig verlassen und anhand eines konkreten Beispiels den praxisorientierten Umgang mit einem objektorientierten Datenbanksystem schildern. Am Ende steht ein Prototyp, der auf
eine extrem vereinfachte Art und Weise einige grundsätzliche der in dieser Arbeit geschilderten Ansätze umsetzt.
Dieser Abschnitt ist aber mehr als nur ein Anhang: Nachdem ich in den vorangegangenen neun Abschnitten die Vision eines großen Ganzen erschaffen habe, möchte ich nun an einer kleinen Untermenge konkrete Wege zur Realisierung aufzeigen.
10.1.
SYSTEMWAHL
Wieso POET, warum C++?
Die Systemwahl fiel aus rein praktischen Gründen auf POET: Von POET ist eine kostenlose und vor
allem
zeitlich
unbegrenzt
nutzbare
Evaluationsversion
auf
dem
Web
verfügbar
(http://www.poet.com/). Außerdem war POET das einzige System, das mir auch schon vor Beginn
meiner Diplomarbeit ein Begriff war.
Um den Prototyp, der inklusive Quellcode auf der beiliegenden CD-ROM enthalten ist, zum Laufen
zu bringen, muß übrigens diese Evaluationsversion vom Netz geladen und auf dem Zielrechner installiert werden. Aus lizenzrechtlichen Gründen konnte ich sie nicht mit auf CD-ROM brennen.
Als Sprache des zu entwickelnden Prototyps habe ich C++ gewählt, weil ich in dieser Sprache die
weitreichendsten Kenntnisse habe und weil mir Java (die einzige für mich mögliche Alternative) darüberhinaus noch zu absturzanfällig und langsam erschien.
10.2.
ANATOMIE EINES DICHTERS
„Komponententheorien“
POET besteht aus verschiedenen Komponenten, die zusammen das Datenbanksystem bilden. Neben
den Hauptmodulen existieren noch unterschiedliche Werkzeuge, die der Wartung und Pflege der
Datenbanken dienen. Sämtliche Module sind auf einer CD zusammengefaßt; zum Freischalten der
einzelnen Komponenten werden die entsprechenden Lizenzierungsschlüssel benötigt.
Die Trennung der Komponenten ist übrigens ausschließlich aus Gründen der Modularisierung bedingt; bei Kauf eines SDKs wird automatisch eine Single-User-Lizenz des Objekt-Servers installiert, so
daß zu Entwicklungszwecken nicht der komplette, nicht ganz billige Objektserver erworben werden
muß.
Seite 168
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
10.2.1.
POET Universal Server
Der Objekt-Server ist das eigentliche Herzstück des Systems: Er bearbeitet sämtliche Datenanforderungen der Clients und verwaltet die Daten zentral – nur er hat direkten Zugriff auf die physikalischen Datenbankdateien. Der POET-Server ist extrem klein: Die Windows NT-Version belegt laut
POET-Webseite lediglich 1-2 MByte Speicher.
Der Server verwendet ein eigenes, auf TCP/IP basierendes Protokoll für die Intranet-Kommunikation.
Es werden die Ports 6001 und 6002 verwendet. Um die entsprechenden Ports zu definieren, müssen
sie in der „services“-Datei des Windows-Verzeichnisses definiert werden.
Neben der Bekanntgabe des Protokolles muß auch noch der Servername mitsamt IP-Adresse in die
„hosts“-Datei (ebenfalls im Windows-Verzeichnis) aufgenommen werden.
hosts
127.0.0.1
localhost
193.141.33.120 poet-srv.hq.de
services
poet
6001/tcp
_poet
6002/tcp
Nachdem diese Ergänzungen an den Systemdateien vorgenommen wurden, kann der Server nach
einem Neustart des Systems direkt verwendet werden. Im Beispiel könnte der Server unter der URL
„poet-srv.hq.de“ angesprochen werden.
10.2.2.
Client License Packages
Für jeden Arbeitsplatzrechner wird eine Client License Package benötigt, die die Objektanforderungen des Anwendungsprogrammes an den Server übermittelt. Die Freischaltung über Keys, die für jeden Client einzeln durchgeführt werden muß, ist leider extrem umständlich und aufwendig, was bei
großen, zentral zu wartenden Intranets zu infrastrukturellen Problemen führen kann.
10.2.3.
Verity Search
Das Verity-Search-Modul, das seit der Version 5 von POET mitgeliefert wird, ermöglicht eine Volltextsuche in den Datenbeständen. Dazu muß der Datenbestand mit einem Volltextindex versehen
sein, der entsprechende Attribute der Objekte indiziert. Es können unterschiedliche Instanzenvariablen (üblicherweise vom POET-Stringtyp oder einer Menge von POET-Strings) definiert werden, die
bei einer Volltextsuche einbezogen werden.
Eine Volltextsuche ist ideal für Textsammlungen mit äußerst variablen Inhalten, da diese von üblichen Suchmechanismen nur unzureichend erfaßt werden können.
10.2.4.
SDKs
Die SDKs sind die Schnittstelle zur Programmiersprache der auf der Datenbank aufbauenden Anwendung: Es werden die entsprechenden Headerdateien und Bibliotheken zur Verfügung gestellt,
um die Datenbank in eigene Programme einbinden zu können. Das C++-SDK von POET integriert
sich leider nicht in die Entwicklungsumgebung – es müssen entsprechende Pfade zu den jeweiligen
POET-Verzeichnissen beim Projekt bzw. in der IDE angegeben werden.
Seite 169
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Das POET-SDK stellt neben der reinen Datenbankfunktionalität auch noch eine Klassenbibliothek zur
Verfügung, die grundlegende Funktionalitäten wie String- (Klasse PtString), BLOB- (Klasse PtBLOB)
oder Mengenverwaltung (Klassen Pt...Set) realisieren.
10.2.5.
Tools
Neben den „Brocken“, die die Datenbankfunktionalität und die Einbindung in eigene Programme
ermöglichen, existieren noch Werkzeuge zur Verwaltung der Datenbanken.
DEVELOPER
Der POET-Developer enthält einen Pre-Compiler, der die POET-C++-Quelltexte (Endung: .hcd) in
ANSI-C++ umwandelt – und damit die proprietären Objektdefinitionen in eine Objekthierarchie
mit der POET-Basisklasse PtObject auflöst. Sämtliche Objekte einer POET-Datenbank sind also von
der Klasse PtObject abhängig –diese Klasse regelt die grundlegenden Funktionalitäten der Datenbank, also das Einlesen, Speichern, Sortieren, etc.
Der Pre-Compiler ruft automatisch den Schema-Evolver auf, der eine evt. vorhandene alte Version
der Datenbank auf den neuesten Stand bringt. Überflüssige Elemente werden gelöscht, neu hinzukommende mit Standard- oder benutzerdefinierten Werten initialisiert.
Neben diesen Entwicklungstools ist noch ein Objekt-Browser integriert, mit dem der Bestand einer
Datenbank durchforstet werden kann. Das Tool kann alle Standarddatentypen wie Werte, Zeichen
und Strings darstellen, bei BLOBs fehlt allerdings die Möglichkeit, beispielsweise einen externen Viewer für die gespeicherten Bitmap-Grafikdaten aufzurufen.
Der Developer verfügt über eine Entwicklungsoberfläche, die projektorientiert (in Form von sogenannten „Workbooks“) arbeitet. In einem Workbook sind Datenbankdateien, Suchpfade, Compileroptionen und zu precompilierende POET-C++-Dateien definiert.
ADMINISTRATOR
Der POET-Administrator verwaltet die Datenbank. Mit ihm können Reorgansierungen, Reparaturen,
Indexupdates und vieles mehr erledigt werden. In der Praxis habe ich den Administrator hauptsächlich eingesetzt, um Fehler, die durch Versionssprünge oder nicht upgedatedte Indizes entstanden
sind, zu korrigieren.
10.2.6.
„POET-C++“ – Dialekt oder neue Hochsprache?
Eine objektorientierte Datenbank muß den „Sprachschatz“ von C++ zwangsläufig erweitern –
schließlich muß definiert werden, welche Objekte in die Datenbank gehören, welche nicht.
POET verwendet folgende Methode: Es werden die zusätzlichen Schlüsselworte persistent und
transient eingeführt. persistent bedeutet, daß ein Objekt in die Datenbank aufgenommen werden können soll, transient wiederum kennzeichnet „flüchtige“ Elemente innerhalb eines persistenten Kontextes, also beispielsweise Elemente, die nur zur Laufzeit benötigt werden und deshalb keinen wertvollen Plattenplatz auf dem Server verschwenden sollen. Um diese Schlüsselwörter in ANSIC++-Code umzuwandeln, ist der Zwischenschritt über den Developer (siehe voriges Unterkapitel)
notwendig.
Seite 170
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Sämtliche anderen Anpassungen werden „transparent“ vorgenommen; d.h. es werden zusätzliche
C++-Templates oder -Klassen zur Verfügung gestellt (Konzept der Klassenbibliotheken).
POET ist also eher als ein ein wenig erweitertes C++ aufzufassen als eine komplett neue Programmiersprache. Eine Auflistung interessanter Features findet sich in Kapitel 10.3.
10.2.7.
POETs Datenbankkonzept
In POET ist es möglich, logische Datenbanknamen zu vergeben: Statt den genauen Ort einer Datenbank auf dem Server anzugeben, wird ein Alias vergeben, unter dem die Datenbank angesprochen
werden kann, zum Beispiel „mediaDb“ für eine Mediendatenbank. Die Zuordnung zu einer physikalischen Datei erfolgt auf dem Datenbankserver (über die Datei ptserver.cfg).
POET verwendet zwei Ordner, um eine Datenbank auf dem Massenspeicher abzulegen: Die eigentlichen Objekte werden im Verzeichnis base in den Dateien objects.dat (Objekte) und objects.idx
(Index) abgelegt. Das sogenannte „Dictionary“ (entspricht der Metastruktur der Datenbank) beinhaltet das Schema der Datenbank, also Informationen über den Aufbau der Objekte. Dieses „Wörterbuch“ wird bei der Schema-Evolution zur Erweiterung des Datenbankbestandes herangezogen und
auch zur Verwaltung der Objekthierarchie zur Laufzeit herangezogen – beispielsweise für das Ermitteln des korrekten Objekttyps. Das Dictionary befindet sich im Verzeichnis dict und besteht aus den
Dateien _objects.dat (Definitionen) und _objects.idx (Index).
10.3.
CLUB DER WERDENDEN DICHTER
„POET-Programmierung in einer Stunde“?
Ich kann und will in dieser Diplomarbeit (von einer ganz kurzen, prinzipiellen Darstellung der
„Denkweise“ von POET abgesehen) keine Einführung in die Programmierung von POET geben. Dies
können die mitgelieferten Handbücher und Tutorials viel besser (vgl. POET Software GmbH,
1997[42]). Viel interessanter ist es, konkrete Lösungsstrategien darzustellen, die ein Gefühl für die
Möglichkeiten, die in der Programmierung eines objektorientierten Datenbanksystems stecken, vermitteln können.
10.3.1.
Vergängliches in aller Ewigkeit...
Wie bereits erwähnt, unterscheidet POET zwischen zwei Arten von Objekten: Persistente (also dauerhaft auf Massenspeicher verewigte) und transiente (also flüchtige, beim Programmende oder durch
den delete-Operator vernichtete) Objekte.
Soll einer Klasse die Möglichkeit gegeben werden, daß die aus ihr gebildete Instanzen in der Datenbank abgelegt werden können, muß diese als persistent deklariert werden und vom Precompiler in
„normales“ C++ konvertiert werden (vgl. Kapitel 10.2.6). Die restliche Klassendefinition erfolgt wie
in C++ üblich, allerdings können in den Klassen die von POETs Klassenbibliothek zur Verfügung gestellten Elemente wie Mengen oder Strings verwendet werden.
Seite 171
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Beispielhafte Klassendefinition einer persistenten Klasse
persistent class BeispielKlasse
{ // hier sind die private-Eigenschaften
...
// hier die private-Methoden
...
// und zum Schluß noch die Schnittstellenmethoden
...
};
Nachdem diese Definition durch den Precompiler „gejagt“ wurde und die daraus erzeugten, C++kompatiblen Headerdateien in das Anwendungsprojekt eingebunden wurden (s.u.), kann es losgehen.
Einbindung in Anwendungsprogramm
// POET-Grundfunktionalitäten
#include <poet.hxx>
// vom POET-Precompiler erzeugte Headerdatei (Standard C++)
#include "beispiel.hxx"
Aber die Klassendefinition ist selbstverständlich noch nicht das Ende der objektorientierten Fahnenstange: Die Klassen müssen mit Funktionalität gefüllt werden – dies geschieht in Standard C++ (wobei die POET-Bibliotheken benutzt werden können) und diesmal ohne den Umweg über einen Precompiler.
Ausprogrammierung der Klassenmethoden
...
// Standard-Konstruktor
BeispielKlasse::BeispielKlasse (void)
{ // Initialisierungen, etc.
...
}
// Destruktor
BeispielKlasse::~BeispielKlasse (void)
{ // Aufräumen
...
}
// Klassenmethode
BeispielKlasse::sagHallo (void)
{ printf (“Hallo da draußen!”);
}
...
Das Erstellen einer Datenbank und die Einbindung in ein Anwendungsprogramm nimmt also prinzipiell immer den folgenden Weg:
Seite 172
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Klassendefinition in POET-C++ (beispiel.hcd)
Developer
Generierung
Klassendefinition in Standard-C++ (beispiel.hxx)
Klassenausgestaltung in Standard-C++ (beispiel.cpp)
definieren
Einbinden
Zugriff
Anwendung
Client-Access-Packg.
Datenbank
Generierung
physikalische
Struktur/Dictionary
Einbinden
POET-Bibliotheken
POET-Header (poet.hxx)
Die Grafik zeigt, daß neben den POET-Headerdateien noch die POET-Bibliotheken eingebunden
werden müssen, so daß die POET-Funktionalitäten dem Anwendungsprogramm beim Linken hinzugefügt werden und so zur Laufzeit zur Verfügung stehen.
10.3.2.
Grundlegende Objektverwaltung
Nachdem ich dargelegt habe, wie eine Datenbank generiert und in ein Anwendungsprogramm eingebunden werden kann, möchte ich nun die grundlegende Objektverwaltung darstellen: Wie können Objekte in die Datenbank eingefügt, wie geladen, verändert und zurückgeschrieben werden?
OBJEKT ANLEGEN
Nachdem eine Instanz von einer als persistent deklarierten Klasse mittels new-Operator gebildet
wurde, hat das neu gebildete Objekt zunächst gar nichts mit der Datenbank zu tun. Erst nach Aufruf
der Objektmethode Assign (von der Basisklasse PtObject geerbt) wird dem Objekt eine eindeutige
Kennung („Surrogate“ oder Objekt-ID) zugewiesen – und somit die Forderung nach Objektidentität
erfüllt.
Noch ist das Objekt aber nicht in der Datenbank abgelegt: Dies geschieht erst nach Aufruf der Store-Methode. Sie muß auch nach jeder Änderung des Objektinhaltes aufgerufen werden, damit diese
Änderungen auch in die Datenbank übernommen werden.
OBJEKT LESEN
Objekte werden automatisch eingelesen, sobald über einen Verweis auf sie zugegriffen wird. Dabei
werden alle unterverzeigerten Objekte miteingelesen, was sehr schnell zu einem gewaltigen Speicherverbrauch führen kann. Vgl. hierzu Kapitel aber auch 10.3.4.
Um einen Verweis auf ein bestimmtes Objekt zu erhalten, können Suchanfragen (vgl. POET Software
GmbH, 1997[42], S.263ff) oder Objekt-Mengen (vgl. Kapitel 10.3.3) verwendet werden.
Seite 173
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
OBJEKT LÖSCHEN
Objekte können wahlweise mit dem delete-Operator oder mit der Forget-Methode gelöscht werden. Der Unterschied besteht darin, daß delete das Objekt radikal löscht – es können also verwaiste
Verweise zurückbleiben, die zu Programmabstürzen führen können. Forget hingegen arbeitet mit
Referenzzählern, so daß Objekte nur dann vollständig gelöscht werden, wenn kein anderes Objekt
mehr auf sie verweist. Andernfalls wird lediglich der Referenzzähler erniedrigt.
10.3.3.
Mengenlehre
Was das Statement „SELECT * FROM table“ für eine relationale Datenbank erledigt, wird in POET
über Mengen („Sets“) gehandhabt: Es existieren vorgefertigte Mengen, die zum Beispiel Listen mit
Verweisen auf alle Objekte, alle Objekte eines bestimten Typs, usw. enthalten. Diese Sets sind vom
Precompiler vordefinierte Klassen. Um eine Liste mit allen Objekten der Beispielklasse zu generieren,
wird beispielsweise der Befehl BeispielKlasseAllSet *shellList= new BeispielKlasseAllSet
(dbPtr); verwendet. Über die entsprechenden Methoden dieser Klasse kann die Menge verwaltet
werden.
10.3.4.
Verweise aller Arten
Verweise entsprechen dem C++-Konzept der Pointer; d.h. Verweise von einem Objekt zu einem
anderen werden als Zeiger realisiert, die beim Laden des Objektes in eine reale Speicheradresse umgewandelt und beim Schreiben auf Platte wieder durch das entsprechende Objekt-Surrogat ersetzt
werden – schließlich können die Zeiger nicht „einfach so“ gespeichert werden, da sie bei einem erneuten Laden mit an Sicherheit grenzender Wahrscheinlichkeit nicht mehr auf das korrekte Objekt
zeigen würden.
AUF VERLANGEN...
Beim Zugriff auf ein Objekt werden sämtliche von ihm über einen Zeiger referenzierten Unterobjekte ebenfalls in den Hauptspeicher geladen. Da dies sehr schnell zu einer kollabierenden Auslagerungsdatei führen kann, ist in der POET-Klassenbibliothek das ondemand-Template definiert, welches
sicherstellt, daß ein Objekt nur bei wirklichem Bedarf – also bei einem direkten Zugriff über einen
Zeiger – nachgeladen wird. Beispiel: ondemand <BeispielKlasse> testKlasse; würde ein Klassenmitglied definieren, das nur bei einem Zugriff der Art testKlasse->sagHallo (); nachgeladen
wird.
10.3.5.
Transaktionen & Co.
Transaktionen und andere weiterführende Features von POET möchte ich hier nicht vorstellen, da
sie zum grundsätzlichen Verständnis der Arbeitsweise eines objektorientierten Datenbanksystems
nicht erforderlich sind. Es sei in diesem Zusammenhang aber auf das POET-Handbuch verwiesen
(POET Software GmbH, 1997[41])
Seite 174
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
10.3.6.
Allergische Reaktionen
Was POET nicht besonders mag, sind Verweise, die ins Leere zeigen, also noch keinem Zielobjekt
zugewiesen sind oder deren Zielobjekte gelöscht wurden, ohne den Zeiger ebenfalls zu aktualisieren.
Problematisch ist, daß der Dichter nicht etwa eine lyrische Fehlermeldung verfasst, sondern Windows die unschöne Botschaft in Form einer allgemeinen Schutzverletzung vermelden läßt. Für den
Anfänger ist dies eine ziemlich verwirrende Reaktion, da die Schutzverletzung in einem POET-Modul
ausgelöst wird – es hat deshalb den Anschein, als ob das Datenbanksystem nicht einmal ein einfaches Objekt ohne Absturz abspeichern könnte.
Und offene Verweise können ziemlich schnell auftreten: Objekt mit delete gelöscht, dann ein Objekt, das noch einen Verweis enthält, mittels Store-Methode gesichert – das war’s dann!
10.4.
EIER, KARTONS & CO.
Beispielhafte Klassendefinitionen aus einer multimedialen Datenbank
In diesem Abschnitt will ich endlich konkret eine auf den vorhergehenden Abschnitten basierende
Multimedia-Datenbank aufbauen. Sie ist Grundlage des Prototyps, enthält aber nur einen sehr beschränkten Funktions- und Eigenschaftenumfang. Außerdem fehlt das im Systementwurf definierte
„Urelement“, da dieses bei dem hier skizzierten Prototyp nicht benötigt wird. Andererseits existiert
dafür ein Gruppierungsobjekt, mit dem verschiedene Medien inhaltlich gegliedert werden können
(nicht zu verwechseln mit dem Objektgruppierungs-Strukturelement). In meinem Systementwurf entspricht dieses Gruppierungsobjekt einem Teil der Archivierungsinformation, ist dort aber den betroffenen Elementen direkt zugeordnet.
Sämtliche Datenbank-Definitionen finden sich übrigens auf der beiliegenden CD-ROM im Verzeichnis „\EggBase\MediaDb“ in der POET-C++ Datei „EggBase.hcd“.
10.4.1.
Die Ei-Metapher
Als Programmierer tut man gut daran, sich seine komplexe und vor allem abstrakte Welt der Objekte, Datenstrukturen und C++-Compiler durch Vergleiche mit dem „W2“, also der wirklichen Welt,
etwas freundlicher, wärmer und vor allem verständlicher zu machen. Blühende Landschaften für Metaphern!
Ich habe für meine Mediendatenbank die Metapher des Eis gewählt: Die Daten, also die eigentlichen Medieninhalte, stellen das Eigelb dar, das vom Eiweiß, also den Darstellungs- und Bearbeitungsmethoden, umgeben ist. Das Eiweiß schützt den Dotter – ohne den Umweg über das Eiweiß
hat niemand eine Chance, an das Eigelb zu gelangen. Genau dies entspricht dem objektorientierten
Prinzip des Information-Hiding: Auf die (Medien-) Daten darf nur über genau definierte Schnittstellenmethoden zugegriffen werden.
Die Kapselungen entsprechen den Schalen: Sie geben dem Medienobjekt seine Form, indem sie die
Position und ähnliche Darstellungsparameter im Kontext eines Lernmoduls bestimmen. Ein Eierkarton schließlich strukturiert die Eier, faßt sie zu unterschiedlichen Mustern zusammen und sorgt für
einen sicheren Transport. Nicht anders die Strukturelemente in meinem Systementwurf: Sie halten
die Medienelemente zusammen, definieren die Art und Weise, wie sie in den Ablauf eines Lernmoduls eingebunden sind.
Seite 175
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Auch wenn der Vergleich manchmal ein wenig hinken mag (wie dies übrigens bei den meisten Metaphernder Fall ist) halte ich den Vergleich für ziemlich passend und habe ihn deshalb auch schon
zuvor in einigen Beispielen dieser Ausarbeitung verwendet.
10.4.2.
Datenbankmodellierung: Medienobjekte
GRUNDELEMENT
Definition Klasse „MediaEgg“
// MediaEgg: Das Grundelement, von dem alle Medienobjekte abgeleitet sind.
//
Enthält die wichtigsten Grunddaten aller Medienelemente.
persistent class MediaEgg
{
private:
GroupEgg
PtString
PtString
PtString
PtString
PtString
*parent;
name;
author;
copyright;
keywords;
description;
//
//
//
//
//
//
übergeordnete Gruppe
Name des Mediums
Autoren-Info
Copyright-Info
Schlagwörter für das Medienobjekt
Beschreibung des Medienobjektes
public:
MediaEgg (void);
virtual ~MediaEgg (void);
};
// Konstruktor
// virtueller Destruktor
// Standardfunktionen
int getName (PtString &);
//
int setName (PtString);
//
int getAuthor (PtString &);
//
int setAuthor (PtString);
//
int getCopyright (PtString &);
//
int setCopyright (PtString);
//
int getKeywords (PtString &);
//
int setKeywords (PtString);
//
int getDescription (PtString &);
//
int setDescription (PtString);
//
int getParent (GroupEgg *&);
//
int setParent (GroupEgg *, int flag=FALSE); //
int setParentByName (PtBase *, PtString); //
virtual int remove (void);
//
Objektname auslesen
Objektname setzen
Autor auslesen
Autor setzen
Copyright auslesen
Copyright setzen
Schlagwörter auslesen
Schlagwörter setzen
Beschreibung auslesen
Beschreibung setzen
übergeordnete Gruppe ermitteln
übergeordnete Gruppe setzen
übergeordnete Gruppe nach Namen setzen
Medienobjekt löschen
MEDIENELEMENTE
Ich möchte hier nur beispielhaft ein Medienelement – ein Grafikobjekt – in diese Ausarbeitung übernehmen. Die anderen Medientypen sind ähnlich definiert, so daß es Platzverschwendung wäre, sie
hier ebenfalls aufzuführen.
Seite 176
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Definition Klasse „ImageEgg“
// ImageEgg: Das Medienobjekt für ein Bild. Abgeleitet von der Grundklasse.
//
Enthält die Bildinformation im BMP-Format.
persistent class ImageEgg : public MediaEgg
{
private:
PtString bmpFile;
PtBlob imgData;
rgbColor imgPal[IE_MAXPAL];
bmpInfo imgInfo;
//
//
//
//
Verweis auf die Quell-Bitmapdatei
Bilddaten als “Binary Large Object”/Rohdaten
Palette des Bildes (IE_MAXPAL=256)
Bildinformationen...
//
//
//
//
//
//
//
//
Konstruktor
virtueller Destruktor
Dateinamen ermitteln
Dateinamen setzen
X-Größe bestimmen
Y-Größe bestimmen
Bild einlesen
Bild rekonstruieren
public:
ImageEgg (void);
virtual ~ImageEgg (void);
int getBmpFile (PtString &);
int setBmpFile (PtString);
int getXSize (int &);
int getYSize (int &);
int load (PtString);
int reconstruct (HBMP *);
};
10.4.3.
Datenbankmodellierung: Kapselungsobjekte
GRUNDELEMENT
Definition Klasse „MediaShell“
// MediaShell: Grundelement der Medienkapselung. Hiervon sind sämtliche
//
Kapselungsobjekte abgeleitet.
persistent class MediaShell
{
private:
ondemand <MediaEgg> shelledMedia;
PtString shellName;
// gekapseltes Medienelement
// Name der Shell
protected:
transient int loadedFlag;
transient long lockCounter;
// "loadedFlag"; zeigt an, ob Medium geladen ist
// "Lock-Counter" -> wie oft die Kapselung benutzt wird
public:
MediaShell (void);
virtual ~MediaShell (void);
virtual void Activate (void);
int setMedia (MediaEgg *);
int getMedia (MediaEgg *&);
int ungetMedia (MediaEgg *);
int setName (PtString);
int getName (PtString &);
virtual int startLoading (void)= 0;
virtual int breakLoading (void)= 0;
virtual int yieldLoading (void)= 0;
//
//
//
//
//
//
//
//
//
//
//
Konstruktor
Destruktor
Konstruktor für transiente Member
Medienelement setzen
Medienelement ermitteln
Medienelement freigeben
Name der Kapselung setzen
Name der Kapselung ermitteln
Funktion, um das Laden eines Elementes zu starten
Funktion zum Abbrechen des Ladens eines Elementes
regelmäßig aufgerufene Methode zum Fortsetzen
Seite 177
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Definition Klasse „MediaShell“
int checkLoadState (void);
// Ermitteln des Ladestatus
int waitUntilLoaded (void);
// wartet, bis das Element vollständig geladen ist
virtual int unload (void)= 0;
// Funktion zum Aufräumen
virtual int remove (void);
// Kapselung entfernen
virtual void redraw (redrawContext *, redrawRect *)= 0; // Redraw-Methode
};
MEDIENKAPSELUNGEN
Definition Klasse „ImageShell“
// ImageShell: Kapselung von Bildobjekten
persistent class ImageShell : public MediaShell
{
private:
transient HBMP hImage;
int xPos, yPos, xExt, yExt;
// Handle des geladenen Bitmap-Objektes
// Bildausschnitt aus dem Medienelement
public:
};
10.4.4.
virtual void Activate (void);
int startLoading (void);
int breakLoading (void);
int yieldLoading (void);
int setExtent (int, int);
int getExtent (int &, int &);
int setPosition (int, int);
int getPosition (int &, int &);
int unload (void);
void redraw (redrawContext *, redrawRect *);
//
//
//
//
//
//
//
//
//
//
Transient-Konstruktor
Ladevorgang starten
Ladevorgang abbrechen
Ladevorgang abbrechen
Ausschnittsgröße setzen
Ausschnittsgröße ermitteln
Ausschnittsposition setzen
Ausschnittsposition ermitteln
Aufräumen!
Redraw-Funktion
Datenbankmodellierung: Strukturobjekte
GRUNDELEMENTE
Die Strukturobjekte sind in zwei Teile gegliedert: Das eigentliche Strukturelement und die Elemente
der Liste, die von dem Strukturelement referenziert werden.
Definition Klasse „StructureBag“ (Strukturelement)
// StructureBag: Das Grundelement, von dem alle Strukturobjekte abgeleitet sind.
//
Enthält die wichtigsten Grunddaten aller Strukturen.
persistent class StructureBag
{
private:
PtString name;
bagSet bagItems;
// Name des Strukturelementes
// die verschiedenen Bag-Items
transient int strucDoneFlag;
// Struktur komplett abgearbeitet?
Seite 178
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Definition Klasse „StructureBag“ (Strukturelement)
public:
virtual void Activate (void);
// Transient-Konstruktor
int setName (PtString);
// Name setzen
int getName (PtString &);
// Name ermitteln
int getItemNumber (void);
// Anzahl der Strukturelemente ermitteln
int getItem (int, BagItem *&);
// Strukturelement ermitteln
int ungetItem (BagItem *);
// dazugehöriger "Unget"
int addItem (BagItem *);
// Strukturelement hinzufügen
int removeItem (BagItem *);
// Strukturelement löschen
virtual int remove (void);
// Struktur incl. BagItems löschen
virtual void reinit (void);
// Reinitialize
void doInit (void);
// Initialisierung
void doTick (redrawContext *);
// zeitabhängige Verwaltung
void doUpdate (redrawContext *, redrawRect *);
// Verwaltung des Bildschirmupdates
void doUninit (void);
// Aufräumen
int checkIfDone (void);
// Testet, ob abgearbeitet
};
Definition Klasse „BagItem“ (Teilelement eines Strukturobjektes)
// BagItem: Teilelement eines Strukturobjektes.
persistent class BagItem
{
private:
PtString name;
// Name des Objektes
protected:
ondemand <MediaShell> mediaShell;
// Kapselung, auf die sich das Bag bezieht
public:
};
int setName (PtString);
int getName (PtString &);
int setShell (MediaShell *);
int getShell (MediaShell *&);
int ungetShell (MediaShell *);
virtual void doInit (void)= 0;
virtual void doTick (redrawContext *, redrawRect *)= 0;
virtual void doUpdate (redrawContext *, redrawRect *)= 0;
virtual void doUninit (void)= 0;
virtual int checkIfDone (void)= 0;
//
//
//
//
//
//
//
//
//
//
Name setzen
Name ermitteln
Kapselung setzen
Kapselung ermitteln
Kapselung freigeben
Initialisierung
zeitabhängige Verwaltung
Verwaltung/Bildschirmupdate
Aufräumen
Testet, ob BI abgearbeitet
TEILELEMENT EINES STRUKTUROBJEKTES
Im Prototyp exisiert ausschließlich die Strukturelement-Grundklasse. Allerdings sind die Teilelemente
funktionsspezifisch deklariert; in dieser Darstellung handelt es sich um die Phasen einer Phasenanimation.
Seite 179
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
Definition Klasse „BI_Animation“ (Phase einer Phasenanimation)
// BI_Animation: Animations-BagItem.
persistent class BI_Animation : public BagItem
{
private:
int timerType;
long startTime;
long endTime;
ondemand<MediaShell> tmrRef;
int displayAfterEnd;
int scrXOffs, scrYOffs;
//
//
//
//
//
//
Art des verwendeten Zeitgebers
Startzeit der Animation
Endzeit der Animation
ggf. Medienreferenz für Timer
was nach dem Ablaufen der Zeit?
Bildschirmoffset
transient
transient
transient
transient
//
//
//
//
Ist das Objekt im Moment sichtbar?
BagItem abgespielt?
referenzierte Shell
tatsächliche Position des Objektes
int visibleFlag;
int doneFlag;
MediaShell *ref;
absCoords scrPos;
public:
};
10.5.
int setScreenOffset (int, int);
// Bildschirmoffset setzen
int getScreenOffset (int &, int &);
// Bildschirmoffset ermitteln
int setTimerType (int);
// Timertyp setzen
int getTimerType (int &);
// Timertyp ermitteln
int setTimerRef (MediaShell *);
// Kapselreferenz für Timer setzen
int getTimerRef (MediaShell *&);
// Kapselreferenz für Timer ermitteln
int ungetTimerRef (MediaShell *);
// Kapselreferenz für Timer freigeben
int setStartTime (long);
// Startzeit setzen
int getStartTime (long &);
// Startzeit ermitteln
int setEndTime (long);
// Endzeit setzen
int getEndTime (long &);
// Endzeit ermitteln
int setDisplayAfterEnd (int);
// Verhalten nach Ende der "Lebensdauer" setzen
int getDisplayAfterEnd (int &);
// Verhalten nach Ende der "Lebensdauer" ermitteln
void doInit (void);
// Initialisierung
void doTick (redrawContext *, redrawRect *);
// zeitabhängige Verwaltung
void doUpdate (redrawContext *, redrawRect *);
// Verwaltung des Bildschirmupdates
void doUninit (void);
// Aufräumen
int checkIfDone (void);
// Testet, ob abgearbeitet
EIER IN DER DATENBANK?
„The EggBase“ – Prototyp eines multimedialen Datenbanksystems
Nachdem ich im vorigen Kapitel aufgezeigt habe, wie ein Modell für eine objektorientierte Multimedia-Datenbank konkret aussehen könnte, will ich mich im Folgenden auf das „Drumherum“, also die
Entwicklung und Programmierung der Eingabe-, Verarbeitungs und Darstellungsfunktionen konzentrieren.
10.5.1.
Ein Blick „unter die Haube“
In der „EggBase“ sind hinsichtlich des „großen“ Systementwurfs einige interessante Techniken enthalten. Ich möchte sie hier näher erläutern und in Bezug zum Gesamtsystem setzen.
Seite 180
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
WINDOWS-KLASSENBIBLIOTHEK, „MARKE EIGENBAU“
Objektorientierte Programmierung und Windows scheinen sich zunächst zu widersprechen: Windows kennt weder Klassen noch Vererbung oder andere objektorientierte Technologien. Es arbeitet
mit einem vergleichsweise einfachen Ereignismodell.
Im Beispiel: Bei einem Mausklick sendet Windows eine entsprechende Meldung an eine Fensterfunktion, die dem grafischen Objekt, in das geklickt wurde, zugeordnet ist. Objektorientiert wäre es,
wenn jedes grafische Element ein Objekt mit entsprechender Schnittstelle wäre und bei einem
Mausklick die passende Methode aufgerufen und die Fensterprozedur damit also umgangen würde.
Objektorientierte GUI-Programmierung
Windows-Programmierung
// Klasse für einen beliebigen OK-Button
// Definition des Buttons (RC-Datei):
PUSHBUTTON "OK",IDC_OK,131,87,50,13
class OkButton
{
private:
int xPos, yPos;
// Position
int xSize, ySize; // Größe des Buttons
char text[]= ”OK”; // Buttontext
public:
bool init (...);
bool click (...);
bool show (...);
bool hide (...);
bool redraw (...);
};
//
//
//
//
//
Initialisierung
Klick
anzeigen
nicht mehr zeigen
neu zeichnen
// Generieren, darstellen usw.
btnOk= new OkButton ();
btnOk.init ();
btnOk.show ();
// übergeordn. Dialog generieren & darstellen:
DialogBox (hInst, MAKEINTRESOURCE(IDC_OK),
hWnd, (DLGPROC) dlgCallback);
// Funktion in der Callbackroutine der
// zugehörigen Dialogbox:
BOOL CALLBACK dlgCallback (...)
{ // was passiert gerade?
switch (iMsg)
{ case WM_INITDIALOG:
// Dialog initialisieren
...
case WM_COMMAND:
// Mausklick auswerten
...
}
...
}
Normalerweise leisten Klassenbibliotheken die Aufgabe, Windows in ein ordentliches objektorientiertes System zu kapseln. Bekannteste Beispiele: die „Microsoft Foundation Classes“ (MFC) oder die
„Object Windows Library“ (OWL) von Borland. Ich habe für die „EggBase“ eine eigene Kapselung
entwickelt – da im Systementwurf ja eine eigene, geräte- und möglichst auch betriebssystemunabhängige Darstellungsschnittstelle geschaffen werden soll, sicherlich eine sinnvolle Arbeit.
Ich möchte die Art und Weise, wie diese Kapselung funktioniert, hier aus Platzgründen nicht weiter
ausführen, dafür aber beispielhaft auf den ausführlich kommentierten Quellcode der dialogbezogenen Methoden der Klasse System hinweisen, die sich in der Datei sysDialog.cpp finden.
REDRAW-FUNKTIONALITÄTEN
Sämtliche modernen grafischen Benutzeroberflächen verwenden das Redraw-Prinzip in irgendeiner
Form: Wird ein Bildschirmbereich ungültig, wird an das entsprechende Fenster die Aufforderung egschickt, den entsprechenden Bereich neu zu zeichnen. In Windows muß sich nun die Fensterprozedur um diese Aufgaben kümmern.
Hier kann ein nach den gerade vorgestellten Prinzipien gekapseltes System ansetzen: Die zentrale
Fensterprozedur der „EggBase“ „verteilt“ den Redraw an die entsprechenden Methoden aller in dem
entsprechenden Bildschirmausschnitt lokalisierten Medienkapselungen (entspricht der Ereignisverwaltung gemäß Kapitel 9.6.2). Diese müssen sich selbständig um eine korrekte Darstellung kümmern,
indem sie die entsprechenden Funktionen des Darstellungsmoduls aufrufen. Das Darstellungsmodul
Seite 181
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
der EggBase ist sehr einfach gehalten – es handelt sich lediglich um ein einfaches Objekt, das die entsprechenden Aufrufe 1:1 an das GDI weiterleitet (vgl. Quellcode der Klasse GdiInterface in Datei
ifcGdi.cpp).
Die Redraw-Routine der Medienkapselungen nennt sich redraw und ist in der Kapselungs-Basisklasse
als „pure virtual“ definiert – jede abgeleitete Kapselungsklasse muß diese also zwingend implementieren.
10.5.2.
Die CD-ROM: Inhalt, Installation und Handhabung
Die beiliegende CD-ROM enthält sowohl die Quelltexte als auch das ausführbare Programm. Aus Lizenzgründen konnte die POET-Runtime nicht zur Verfügung gestellt werden – eine entsprechende
Evaluationsversion findet sich unter http://www.poet.com/.
INHALT
Die Quelltexte finden sich im Verzeichnis „\EggBase\Sources“ und seinen Unterverzeichnissen. Die
Datenbank residiert im Verzeichnis „\EggBase\MediaDb“ und den entsprechenden Unterverzeichnissen. Das ausführbare Programm und die Konfigurationsdatei befinden sich im Verzeichnis „\EggBase“
INSTALLATION
Zunächst muß die Evaluationsversion von POET installiert werden. Hierzu bitte den Anweisungen
des Setup-Programmes folgen. Zur Installation der EggBase selbst genügt es, die Dateien des Programmverzeichnisses in ein beliebiges Unterverzeichnis zu legen. Danach müssen nur noch die entsprechenden Einträge in der eggBase.cfg (siehe unten) eingetragen werden.
Wird das EggBase-Verzeichnis vom Hauptverzeichnis der CD in das Hauptverzeichnis von Festplatte
C:\ kopiert, sind keine Anpassungen notwendig.
Die auf der CD-ROM enthaltene Demo-Version kann mit und ohne Server verwendet werden – entscheidend ist der Inhalt der Datei eggBase.cfg.
Aufbau der eggBase.cfg
[Server]
name=LOCAL
; oder der Servername; Achtung: Groß-/Kleinschreibung beachten!
[MediaDb]
name=C:\EggBase\MediaDb ; oder der logische Datenbankname
Wird ein Server verwendet, muß dessen ptserver.cfg gemäß Kapitel 10.2.1 oder Handbuch/ReadmeDatei angepaßt werden, damit die logische Bezeichnung auf das korrekte Verzeichnis gemappt wird.
DATENBLATT
Programmiert in Visual C++ 5.0.
POET 5.0.2-Backend.
Verwendet die „reine“ Win32-API, also keine MFC – deshalb muß das Programm nicht installiert
werden (und läuft auch sonst recht flott).
Seite 182
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
10.5.3.
Impressionen...
Ich möchte hier anhand einiger Screenshots kurz die Bedienung der Eggbase erläutern. Zur Demonstration ist bereits eine Demoanimation vordefiniert, die über das Menü Strukturen, Punkt Bearbeiten und in der darauf erscheinenden Dialogbox mit Klick auf den Eintrag „Ei der Daus!“ und den
Button Abspielen! gestartet werden kann.
Viel Spaß beim Rumprobieren – und: Es handelt sich um einen Prototypen! Es können also durchaus
Fehler oder nicht vollständig implementierte Funktionalitäten enthalten sein.
DIE BENUTZEROBERFLÄCHE
Die Menüpunkte und ihre Bedeutung:
Datei -> Beenden: beendet das Programm
Medien -> Einbinden: erstellt ein Medienelement
Medien -> Bearbeiten: bearbeitet ein Medienelement
Kapselung -> Erstellen: erstellt eine Medienkapselung aus einem Medienelement
Kapselung -> Bearbeiten: bearbeitet eine Medienkapselung
Strukturen -> Erstellen: erstellt ein neues Strukturelement
Strukturen -> Bearbeiten: bearbeitet ein Strukturelement
Die übrigen Menüpunkte sind nicht implementiert.
Seite 183
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
DEFINITION EINES GRAFIKELEMENTES43
Zunächst kann eine Bitmapdatei ausgewählt werden, die die Bilddaten des Medienelementes enthält. Im oben dargestellten Dialog können dann die übrigen Attribute (hauptsächlich zu Archivierungszwecken) erfaßt werden. OK übernimmt das Grafikelement, Abbrechen verwirft alle Eingaben.
BEARBEITEN VON MEDIENKAPSELUNGEN
Im oben dargestellten Dialog können Medienkapselungen zur Bearbeitung ausgewählt werden. Nach
Klick auf Bearbeiten erscheint ein Dialog, in dem die Attribute geändert werden können. Wird eine
Kapselung nicht mehr benötigt, kann sie über den Löschen-Button vernichtet werden.
43
Im Prototyp sind lediglich Grafikelemente realisiert.
Seite 184
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
In die Praxis – Implementierung & Prototyp
BEARBEITEN EINER PHASENANIMATION44
Der Screenshot zeigt den Bearbeiten-Dialog für Strukturelemente und gleichzeitig die Eingabemaske
für Strukturteilelemente. Die Teilelemente enthalten die zeitlichen Daten sowie den Offset zum darstellungstechnischen Nullpunkt der Animation.
10.6.
LYRISCHES CROSS-MEDIA-PUBLISHING?
Plattformübergreifendes mit POET
Zum Abschluß dieses Kapitels möchte ich noch ganz kurz auf den Cross-Media-Aspekt eingehen:
Wie gesehen, läßt sich eine POET-Applikation extrem einfach von einer Intranet- zu einer netzunabhängigen Anwendung konvertieren – im Falle der „EggBase“ reicht das Ändern zweier Einträge in einer Konfigurationsdatei aus.
Intern werden Datenbanken über zwei Methoden von der Anwendung angebunden:
PtBase->Connect (server); – stellt die Verbindung zum Server her
PtBase->Open (base); – öffnet die Datenbank auf dem zuvor kontaktierten Server
„server“ bezeichnet dabei den Namen des Servers. Dabei ist bei Angabe von LOCAL kein expliziter
Server nötig, hier übernimmt die Client-Runtime das Datenmanagement – und schon ist die Datenbank vom Intranet unabhängig.
Weiterhin wird durch diese Architektur die Möglichkeit geboten, verteilte Anwendungen zu erstellen: Ein Teil der Daten liegt auf Servern, ein anderer lokal auf CD-ROM (beispielsweise Mediendaten). Die Unterscheidung erfolgt immer über die Angabe eines Servernamen oder LOCAL!
Einfacher läßt Cross-Media-Publishing von der technischen Seite gesehen fast nicht mehr realisieren!
Es muß lediglich beachtet werden, daß bei lokalen Connects keine logischen Datenbankennamen
möglich sind (zumindest ist mir diese Möglichkeit verborgenen geblieben).
44
Auch hier gilt: Es sind im Prototyp lediglich Phasenanimationen möglich!
Seite 185
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Fazit & Schluß – Bewertung der gewonnenen Erkenntnisse
11.
Fazit & Schluß
Bewertung der gewonnenen Erkenntnisse
Am Ende noch die „salbungsvollen Worte“: Ein Fazit muß gezogen, die gewonnenen Erkenntnisse
eingeordnet und bewertet werden. Ich will diesen Abschnitt in die Bereiche fachliches & persönliches Fazit gliedern und ein zusammenfassendes Schlußstatement abgeben.
11.1.
FACHLICHES FAZIT
Zu Lernumgebungen, Integration & objektorientierten Datenbanksystemen
Zunächst möchte ich ein fachliches Fazit für jeden der in dieser Arbeit berücksichtigten Teilaspekte
ziehen.
11.1.1.
Objektorientierte Datenbanken
Objektorientierte Datenbanken sind faszinierende Werkzeuge zur Entwicklung moderner Anwendungen, die dem Programmierer die gewohnte Sprachumgebung auch auf Massenspeicher erschließen und seine Lieblingssprache um viele datenbankorientierte Elemente erweitern.
In Hinblick auf das zu entwickelnde System existieren einige OODBMS-Techniken, die Forderungen
eines multimedialen Systementwurfs direkt unterstützen (komplexe Objekte, Polymorphie, Varianten).
Ganz anders als bei relationalen Systemen!
Kurzum: Ein OODBMs ist ein System, das sich im Idealfall „unsichtbar“ macht und seine Arbeit verrichtet, ohne daß es dem Anwendungsprogrammierer irgendwelche Restriktionen hinsichtlich der zu
verwaltenden Daten auferlegt. Was die Programmiersprache kann, kann auch die Datenbank – und
noch einiges mehr...
Ganz anders als bei relationalen Systemen!
Aus diesem Grunde konnte ich mich in dieser Diplomarbeit auch auf die Anwendung konzentrieren
und die Datenbank-Hintergründe in zwei Abschnitten ausreichend abhandeln.
Allerdings wäre die Thematik „OODBMS-Evaluation“ eine separate Diplomarbeit wert, die sich dann
wirklich ausführlich mit den jeweiligen Systemen befassen und entsprechende BenchmarkAnwendungen implementieren könnte.
Für diese Arbeit lag der Fokus aber eindeutig auf der Entwicklung eines Systems, das eine objektorientierte Datenbank benutzt, so daß ein noch tiefergreifender Einstieg nicht gerechtfertigt gewesen
wäre.
Seite 186
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Fazit & Schluß – Bewertung der gewonnenen Erkenntnisse
11.1.2.
Integratives Softwaredesign
Dies ist für mich eindeutig der Killeraspekt dieser Arbeit: Eingefahrene Denkschemata von der absoluten Trennung zwischen Konzeption, Produktion und Rezeption werden aufgebrochen und neue,
integrative Wege bei der teamorientierten Entwicklung von Lernmodulen und anderen multimedialen Anwendungen aufgezeigt. Nicht der Gegensatz zwischen kreativem Autoren-Halbgott und
schmächtigem, blassem Hacker-Klischee steht im Mittelpunkt des hier konzipierten Systems, sondern
Menschen mit Gefühl für dramaturgische Handlungsbögen und technischem Verständnis.
Daß und wie dies möglich ist – gerade durch ein innovatives Werkzeug wie eine objektorientierte
Datenbank – hat dieser Systementwurf auf einer abstrakte Daten- und Funktionalitätsebene ziemlich
konkret gezeigt.
In diesem Sinne ist diese Arbeit sicherlich sehr „medieninformatisch“ geworden – sie integriert Kreativität und Technik zu einem einzigen, innovatven System.
11.1.3.
Lernumgebungen
Diese Arbeit hat die Wichtigkeit des situativen Kontextes für ein erfolgreiches Lernen aufgegriffen
und auf ein Konzept für netzbasiertes Lernen übertragen, welches konventionelle Ansätze wie das
verteilte, kooperative Lernen mit den Möglichkeiten eines integrierten Systems anreichert.
Auch hier stand die Realisierung eines mediendidaktisch begründeten Konzeptes auf einer technischen Plattform mit einer objektorientierten Datenbank im Vordergrund. Und auch hier habe ich
mein System bis zu einer abstrakten Daten- und Funktionsebene ausgearbeitet.
11.2.
PERSÖNLICHES FAZIT
Analyse der Erwartungen und Ergebnisse
Lang, lang ist’s her: Selbstverständlich hatte ich zu Beginn dieser Diplomarbeit bereits konkrete Vorstellungen darüber, was an diesem nun erreichten Ende herauskommen hätte sollen. Es ist sicher interessant, diese Erwartungen mit den Ergebnissen zu vergleichen und daraus ein persönliches Fazit zu
ziehen.
11.2.1.
Erwartungen
Was erwartet man sich von einer Diplomarbeit? Neue Erkenntnisse? Ja, „objektorientierte Datenbanken“, das hörte sich schon interessant an, und Multimedia sollte sich mit denen ja auch machen lassen... Mit dieser ziemlich techniklastigen Einstellung bin ich an diese Diplomarbeit herangegangen.
Naja, wenn ich diese Richtung weiterverfolgt hätte, wäre dann wohl schon so etwas wie die angeregte Großevaluation von Datenbanksystemen aus dieser Arbeit geworden.
11.2.2.
Ergebnisse
Als Ergebnis ist ein kompletter Entwurf für ein innovatives Autorensystem herausgekommen, das einige neuartige Denkansätze umzusetzen versucht. Das für mich recht herbe Durchbeißen durch die
Seite 187
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Fazit & Schluß – Bewertung der gewonnenen Erkenntnisse
didaktische Theorie hatte als Effekt, daß der Funktionsumfang des Systems größtenteils durch mediendidaktische oder psychologische Aspekte begründet ist. Also kein wirklich technisches System,
sondern ein interdisziplinäres... Medieninformatik eben!
11.3.
SCHLUßWORT
Das Ende.
Diese Diplomarbeit hat ein sehr komplexes System skizziert. Obwohl ich versucht habe, alle notwendigen Aspekte zu berücksichtigen, dürfte mir die eine oder andere Feinheit entgangen sein. Die
Komplexität des Systems wird dann auch bei einer möglichen Realisierung ihren Tribut fordern:
Manche der hier vorgeschlagenen Lösungswege können sich als Sackgasse erweisen, andere mögen
nur in der Theorie von Nutzen sein, manchmal wird alleine die Technik einfach nicht mitspielen –
ob es sich dabei nun um mangelnde Performance, unzureichende Treiber oder Fehler in den Datenbanksystemen handeln mag.
Dies ist aber nicht weiter tragisch, wie uns die teilweise jahrzehntelange Entwicklungsphase moderner, aber oft immer noch nicht hundertprozentig ausgereifter Standardsoftware lehrt: Auch dort fehlen manchmal nützliche Kleinigkeiten, die sich der Benutzer wirklich wünschen würde. Andererseits
erschlägt dieselbe Software den gleichen Benutzer mit Megamodulen, die niemand wirklich braucht.
In diesem Sinne möchte ich auch diese Arbeit verstanden wissen: Als innovativen Ansatz, der noch
Ecken und Kanten enthalten mag, aber interessante Blickwinkel aufzeigt; ein Ansatz, der Fragen aufwirft, aber auch kreative Antworten gibt.
Seite 188
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Quellenverzeichnis/Literatur
Quellenverzeichnis/Literatur
MEDIENDIDAKTISCHE GRUNDLAGEN
[1]
Conklin, J.: Hypertext: An Indruduction and Survey. In: IEEE Computer Sept. 20 (1987)
[2]
Elshout, J.J.: Formal Education vs. Everyday Learning. In: De Corte, E./Linn, M.C. u.a. (Hrsg.):
Computer Based Learning Environments and Problem Solving (NATO ASI Series. Series F: Computer
and Systems Sciences; 84). Springer, 1992, Berlin/Heidelberg
[3]
Faulhaber, S.: Einsatz und Entwicklung von computerunterstützten Lernprogrammen in der medizinischen Aus- und Weiterbildung. Bayerische Julius-Maximilians-Universität Würzburg, 1996,
Würzburg – Web: http://ki-server.informatik.uni-wuerzburg.de/HTMLs/ls6-info/publikationen/sonstiges/Studienarbeiten/Faulhaber/index.html
[4]
Fischer, P.M.: Wissenserwerb mit interaktiven Feedbacksystemen. In: Mandl, H./Fischer, P.M.
(Hrsg.): Lernen im Dialog mit dem Computer. Urban & Schwarzenberg, 1985, München/Wien/Baltimore
[5]
Fischer, P.M., Mandl, H.: Improvement of the Acquisition of Knowledge by Informing Feedback.
In: Diaper, H./Lesgold, A.M. (Hrsg.): „Learning Issues for Intelligent Tutoring Systems“. Springer,
1988, Belin/Heidelberg
[6]
Götze, T.: Hypermedia im Informatikunterricht. Technische Hochschule Darmstadt, 1997, Darmstadt – Web: http://www.informatik.th-darmstadt.de/PI/StudArb/SichtenTG/diplom/node2.html
[7]
Harms, U., Lechner, M., Tergan, S.-O., Wedekind, J., u.a.: HyperDisc. CD-ROM aus der Reihe
CBTs über CBT. Deutsches Institut für Fernstudienforschung an der Universität Tübingen, 1997, Tübingen – Web: http://www.hyperdisc.diff.uni-tuebingen.de
[8]
Jones, M.: Instructional Systems Need Instructional Theory: Comments on a Truism. In: Scanlon,
E./O’Shea, T. (Hrsg.): New Directions in Educational Technology (NATO ASI Series. Series F: Computer and Systems Sciences; 96). Springer, 1992, Berlin/Heidelberg
[9]
Kerres, M.: Multimediale und telemediale Lernumgebungen: Konzeption und Entwicklung. R.
Oldenbourg Verlag, 1998, München/Wien
[10]
Lechner, M.: Ergonomische Navigation in computerbasierten Informationssystemen. Fachhochschule Furtwangen, 1994, Furtwangen
[11]
Locatis, C., Park, O-C.: Some uneasy inquiries into ID expert systems. In: Educational Technology,
Research and Development 3 40, 1992
[12]
Lowyck, J., Elen, J.: Wandel der theoretischen Fundierung des Instruktionsdesigns. In: Unterrichtswissenschaft 19, 1991
[13]
Maturana, H.R., Varela, F.J.: Der Baum der Erkenntnis. Die biologischen Wurzeln des menschlichen Erkennens. Scherz Verlag, 1987 (Original: 1984), Bern/München
[14]
Morris, P., Ehrman, S.C., Goldsmith, R., Howard, K., Kumar, V.: Valuable, viable software in education: Case studies and analysis. Primis Division of McGraw Hill, 1994, New York.
[15]
Schulmeister, R.: Grundlagen hypermedialer Lernsysteme – Theorie, Didaktik, Design. AddisonWesley, 1996, Bonn/Paris (u.a.)
Seite 189
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Quellenverzeichnis/Literatur
[16]
Siemon, J.: Instruktionsdesign. Universität Göttingen, 1996, Göttingen – Web:
http://www.wiso.gwdg.de/~jsiemon/dipl_id.htm
[17]
Skinner, B.F.: The Science of Learning and the Art of Teaching. In: Harvard Educational Review 24.
1954
[18]
Wager, W., Gagné, R.M.: Designing Computer-Aided Instruction. In: Jonassen, D.H. (Hrsg.): Instructional Designs for Microcomputer Courseware. Lawrence Erlbaum Ass., 1988, Hillsdale
[19]
Weltner, K.: Autonomes Lernen: Theorie und Praxis der Unterstützung selbstgeregelten Lernens
in Hochschule und Studium. Klett-Cotta, 1978, Stuttgart
[20]
van der Linden, E.: Does Feedback Enhance Computer-Assisted Language Learning? In: Computers and Education 1/2, 1994
OBJEKTORIENTIERTE DATENBANKEN
[21]
Blummer, T.: Objektverwalter. In: c’t 5/97, Heise Verlag, 1997, Hannover
[22]
Heuer, A.: Objektorientierte Datenbanken – Konzepte, Modelle, Standards und Systeme. Addison-Wesley, 1997, Bonn/Paris (u.a.)
[23]
Meier, A., Wüst, T.: Objektorientierte Datenbanken – Ein Kompaß für die Praxis. dpunkt.verlag,
1997, Heidelberg
[24]
Object Database Management Group: Standard Overview. ODMG, 1997, Burnsville – Web:
http://www.odmg.org/standard/standardoverview.htm
[25]
Object Management Group: What is CORBA???? OMG, unbekanntes Veröffentlichungsdatum, Framingham – Web: http://www.omg.org/about/wicorba.htm
[26]
Schader, M.: Objektorientierte Datenbanken – Die C++-Anbindung des ODMG-Standards.
Springer Verlag, 1997, Berlin/Heidelberg
[27]
Wetmore, B.: Object Technology 101. In: Telephony, 6.5.1996, S.38ff. Intertec Publishing, 1996,
Chicago
INTRANET/NETZBASIERTES LERNEN
[28]
Christ, P.: ATM - RUS, urbi et orbi. Universität Stuttgart, 1995 (Original), Stuttgart – Web:
http://x500.belwue.de/BelWue/spots/96/ATM.frame.html
[29]
Gutschmidt, H.: Drahtlose Rechnernetzkopplung. TU Chemnitz-Zwickau, 1996, Chemnitz/Zwickau – Web: http://rnvs.informatik.tu-chemnitz.de/~hgu/diplom/title.html
[30]
Rechenzentrum der Uni Mannheim: Netze - Allgemein - Rechnernetze. Uni Mannheim, 1997,
Mannheim – Web: http://www.uni-mannheim.de/rum/netze/rechnernetze/
[31]
Reder, B.: Die Hunderter-Klasse. In: Gateway, 5/97, Heise Verlag, Hannover
[32]
Steinke, I.: Mediendidaktische Konzeption netzbasierten Lernens. Fachhochschule Furtwangen,
1997, Furtwangen
Seite 190
Integration einer objektorientierten Datenbank in eine intranetbasierte Lernumgebung
Quellenverzeichnis/Literatur
AUTHORING/PRODUKTION
[33]
Asymetrix (Hrsg.): OpenScript Referenz. Asymetrix Corporation, 1994, Bellevue
[34]
Buzan, T.: Kopftraining – Anleitung zum kreativen Denken. Goldmann Verlag, 1974, München
[35]
Buzan, T.: The Mind Map Book. Penguin Group, 1993, Dutton – verwendete Auszüge aus dem
Web: http://www.ozemail.com.au/~caveman/Creative/Mindmap/Radiant.html
[36]
Eckert, A., Röscheisen, H. E.: Der Mix macht‘s. In: Screen Multimedia, 1/98, MACup-Verlag, Hamburg
[37]
Field, S.: Das Handbuch zum Drehbuch. Zweitausendeins, 1991 (Original: 1984), Frankfurt am
Main
[38]
Hesse, W., Merbeth, G., Fröhlich, R.: Software-Entwicklung: Vorgehensmodelle, Projektführung,
Produktverwaltung. Oldenbourg, 1992, München
[39]
Kleeberger, J., Eisenhauer, A.: Design and Prototype Development of a Software based Support of
Multimedia Script Authors. Fachhochschule Furtwangen, 1996, Furtwangen
[40]
Levine, A.: Lerntechniken – Mindmapping. – Web: http://www.lerniversum.com/Lerniversum/Deutsch/Learn/Tech/map.html
[41]
POET Software GmbH: POET C++ SDK – Programmer‘s Guide (Version5.0). POET Software
GmbH, 1997, Hamburg/San Mateo (PDF-Version)
[42]
POET Software GmbH: POET Verity Search Plugin. POET Software GmbH, 1997, Hamburg/San
Mateo (PDF-Version)
[43]
Zmija, M.: Mind Mapping. Universität Essen, 1996, Essen – Web: http://www-stud.uniessen.de/~sw0844/mind.htm
SONSTIGES
[44]
Langenscheidts Fremdwörterbuch – Web: http://www.langenscheidt.aol.de
[45]
Microsoft (Hrsg.): Developer Network Library/October 1997. MSDN, 1997, Redmond (CD-ROM)
[46]
Petzold, C., Yao, P.: Windows 95 Programmierung. Microsoft Press Deutschland, 1996, Unterschleißheim
[47]
Walter, W.: Arbeitsmaterial zur Vorlesung Informatik II. Fachhochschule Furtwangen, 1994, Furtwangen
Seite 191