Document [original]

Ein Modell zur strukturellen Beschreibung von

formatierbaren Lernmodulen f¨

ur die orthogonale

Konstruktion konsistenter Lerneinheiten

Zur Erlangung des akademischen Grades

DOKTORINGENIEUR (Dr.-Ing.)

der Fakult¨

at f¨

ur Elektrotechnik, Informatik und Mathematik

der Universit¨

at Paderborn

vorgelegte Dissertation

von

Dipl.-Inform. Andreas Baudry

aus Ahrensburg

Referent: Prof. Dr.-Ing. B¨

arbel Mertsching

Korreferent: Prof. Dr.-Ing. Reinhard Keil-Slawig

Tag der m¨

undlichen Pr¨

ufung: 06.04.2006

Paderborn, den 19.04.2006

Diss. 14/218

Kurzfassung

Die Entwicklung multimedialer Lernmaterialien sowie die Konstruktion technischer Lern-

systeme, hat in den letzten Jahren einen zunehmenden Einfluss auf die Hochschullehre und

die betriebliche Ausbildung genommen. Neben zahlreichen Learning Management Syste-

men (LMS) zur Verwaltung von Kursen und Studierenden sowie technischen Systemen

zur Unterst¨

utzung des Konstruktionsprozesses, sind insbesondere Standardisierungen im

Kontext strukturierter Kursinhalte und deren Verwaltung durch Metadaten entstanden.

Die Entwicklung fach¨

ubergreifender Lernmaterialien setzt jedoch die Modellierung ab-

strakter modularer Materialien voraus, die bei konventionellen Ans¨

atzen meist wenig oder

gar nicht ber¨

ucksichtigt werden. Daher stellt die Integration bestehender Ressourcen in

einen Entwicklungsprozess oft ein un¨

uberwindbares und meist kostspieliges Problem dar.

Aus diesem Grund wird in dieser Arbeit ein technisches Modell vorgestellt, das die Ent-

wicklung technischer Systeme zur Erstellung modularer und darstellungsfreier Lernobjekte

erm¨

oglicht. Das Modell ist unter anderem durch das SCORM-Referenzmodell motiviert

und erweitert das dort definierte Aggregation-Model um ein Content-Model. W¨

ahrend

des zweistufigen Entwicklungsprozesses werden zun¨

achst ausschließlich der Inhalt sowie

die Struktur der Materialien spezifiziert. Beide werden separat in formatierbaren Baustei-

nen organisiert, wodurch sich frei skalierbare Aggregationslevel ergeben. In einem zweiten

Schritt wird anhand spezifischer Regeln ein Pr¨

asentationsformat abgeleitet und aus den

abstrakten Bausteinen ein spezialisierter Kurs generiert. Des weiteren beinhaltet das Mo-

dell einen Ansatz zur Integration bestehender Lernmaterialien, die in ihre Bestandteile

Kursstruktur, Inhalt, Metadaten und Ressourcen zerlegt und auf das abstrakte Kursmo-

dell abgebildet werden.

Im Gegensatz zu herk¨

ommlichen Systemen, unterst¨

utzt dieser Ansatz den kooperativen

Entwicklungsprozess von Teams. Abstrakt formulierte Lernbausteine und Kursfragmente

werden in einem zentralen Repository mit dem Ziel koordiniert, interdisziplin¨

are, auf das

Lernszenario angepasste Lernmaterialien, zu erzeugen.

Die Leistungsf¨

ahigkeit des Modells wird durch die Referenzimplementierung im Au-

torenwerkzeug Lyssa vorgestellt. Es enth¨

alt neben einem Autorensystem zur Aggregation

und Transformation auch ein Werkzeug zur Layoutdefinition sowie ein zentrales Repository

zur Verwaltung von abstrakten Lernmaterialien.

Inhaltsverzeichnis

1 Einleitung 1

1.1 ZielsetzungderArbeit .............................. 2

1.2 Eingliederung der Arbeit in das Projekt mαth-kit .............. 3

1.3 Vorgehensweise und Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . 4

I Stand der Forschung und Technik 7

2 Grundlagen 9

2.1 MultimedialesLernen .............................. 9

2.1.1 Multimedia ................................ 10

2.1.2 E-Learning ................................ 11

2.2 Lerntheorie .................................... 12

2.2.1 Lernprozess................................ 13

2.2.2 Lernparadigmen ............................. 16

2.2.3 Ein Heuristisches Lernmodell . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Standardisierung im E-Learning . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.1 ADL(SCORM).............................. 20

2.3.2 IMS .................................... 25

2.3.3 IEEE-LTSC(LOM) ........................... 27

2.3.4 AICC ................................... 28

2.3.5 ARIADNE ................................ 30

2.3.6 Analyse .................................. 31

2.4 Lernobjekte (Learning Objects) . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.1 Metaphern ................................ 34

2.4.2 Analyse .................................. 36

2.4.3 Granularit¨

at ............................... 37

3 Technologien 39

3.1 Wiederverwendung von Lernmaterialien . . . . . . . . . . . . . . . . . . . . 39

3.1.1 SlicingBooks............................... 39

3.1.2 ITO-Projekt ............................... 40

3.1.3 Analyse .................................. 41

vi INHALTSVERZEICHNIS

3.2 Formale Beschreibung von Lernmaterialien . . . . . . . . . . . . . . . . . . 42

3.2.1 SGML/XML .............................. 43

3.2.2 DocBook ................................. 47

3.2.3 OMDoc/OpenMath........................... 48

3.2.4 MathML ................................. 50

3.2.5 Learning Material Markup Language (LMML) . . . . . . . . . . . . 51

3.2.6 Educational Modelling Language (EML) . . . . . . . . . . . . . . . . 53

3.2.7 Analyse .................................. 55

3.3 Lernplattformen – Learning Management Systeme . . . . . . . . . . . . . . 56

3.4 Autorenwerkzeuge ................................ 58

3.4.1 Ausgew¨

ahlteSysteme .......................... 60

3.4.2 Analyse .................................. 64

4 Bewertung 67

II Modellierung und Umsetzung 69

5 Ein Modell zur Entwicklung konsistenter Lernmaterialien 71

5.1 DasBaukastenprinzip .............................. 71

5.1.1 Bausteine................................. 72

5.1.2 Kurse ................................... 73

5.1.3 Prozess .................................. 74

5.2 Formatierbare Lernbausteine . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.1 Dokumentstruktur ............................ 78

5.2.2 Spezialisierte Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2.3 Dateistruktur............................... 85

5.3 FormatierbareKurse............................... 87

5.3.1 Granularit¨

at ............................... 90

5.3.2 Abstrakte Kursmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.4 Abbildung von Lernmaterialien . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.4.1 Analyse .................................. 94

5.4.2 Abbildung auf das Kursmodell . . . . . . . . . . . . . . . . . . . . . 96

5.4.3 Nachbearbeitung............................. 98

5.5 Transformation.................................. 99

5.5.1 Aggregation................................ 99

5.5.2 Transformationspaket . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.5.3 Prozessoren................................105

5.5.4 Layout...................................105

5.6 Kooperation....................................109

5.6.1 Der kooperative Entwicklungsprozess . . . . . . . . . . . . . . . . . . 110

5.6.2 Operationen................................111

INHALTSVERZEICHNIS vii

6 Umsetzung 115

6.1 Das Autorenwerkzeug Lyssa . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.1.1 Systembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.1.2 Formatierbare Bausteine . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.1.3 Formatierbare Kurse . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.1.4 DasKursmodell .............................127

6.1.5 Abbildung bestehender Formate . . . . . . . . . . . . . . . . . . . . 130

6.1.6 Transformation..............................135

6.1.7 Framework ................................138

6.2 Das Layoutwerkzeug Lyssa-Designer . . . . . . . . . . . . . . . . . . . . . . 140

6.2.1 Implementierung.............................143

6.3 Construction Kit Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

6.3.1 Slide....................................147

7 Beispiele 149

7.1 Technische Informatik - Exemplarische Kursentwicklung . . . . . . . . . . . 149

7.1.1 Analyse ..................................150

7.1.2 Aufbau einer Lerneinheit . . . . . . . . . . . . . . . . . . . . . . . . 150

7.1.3 Kurskonstruktion.............................150

7.2 Wiederverwendung bestehender Skriptteile . . . . . . . . . . . . . . . . . . . 160

7.3 Exemplarische Entwicklung eines Formats zur Pr¨

asentation . . . . . . . . . 162

7.3.1 Festlegung des Layouts . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.3.2 Festlegung des Formats . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.4 Ausgew¨

ahlteBausteine..............................166

III Analyse 173

8 Zusammenfassung 175

8.1 Evaluation.....................................176

9 Bewertung 179

10 Ausblick 183

IV Anlagen 185

A Abk¨

urzungsverzeichnis 187

B Glossar 189

C Attribute 193

Literaturverzeichnis 197

viii INHALTSVERZEICHNIS

Abbildungsverzeichnis

2.1 Begriffsbeschreibung (vgl. [Kerres98],Seite14) ................ 11

2.2 Lernparadigmen (Quelle: [Baumgartner97],Seite5).............. 18

2.3 Ein Heuristisches Lehr- und Lernmodell (Quelle: [Baumgartner97], Seite 8) 19

2.4 Kooperation internationaler Standardisierungsgremien und -Organisationen 20

2.5 Beispiel: Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Beispiel: Content Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7 SCORM Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.8 IMS Digital Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.9 Variable Kursstruktur f¨

ur Lernmodule zum leichten Transfer von einem

CMI-System auf ein anderes System. . . . . . . . . . . . . . . . . . . . . . . 30

2.10 Das modulare Prinzip der Reusable Learning Objects (RLO) . . . . . . . . 32

2.11 Modulare Content-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.12 Aggregationslevel f¨

ur Lernobjekte nach dem IEEE Standard f¨

ur Metadata

(LOM) ...................................... 37

3.1 System Modules of Slicing Books . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Import....................................... 41

3.3 Export....................................... 42

3.4 Syntax eines XML-Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.5 Eindeutige Zuordnung von Elementbezeichnern durch Pr¨

afixnotation . . . . 45

3.6 Beispiel: XSL-Transformation einer einfachen XML-Struktur in eine FO-

Repr¨

asentation .................................. 47

3.7 TeachwareModell ................................ 52

3.8 XML-Schema Bindung des EML Rahmenwerkes . . . . . . . . . . . . . . . 54

3.9 Idealtypische Architektur eines Learning Mangement Systems . . . . . . . . 57

3.10 Verschiedene Kategorien von Autorenwerkzeugen . . . . . . . . . . . . . . . 59

3.11Toolbook ..................................... 60

3.12Authorware.................................... 62

3.13 Macromedia Dreamweaver MX . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Basisformat f¨

urLernbausteine.......................... 73

5.2 Basisformat f¨

urKurse .............................. 74

5.3 InteraktionderRollen .............................. 76

x ABBILDUNGSVERZEICHNIS

5.4 Struktur eines formatierbaren Bausteins . . . . . . . . . . . . . . . . . . . . 78

5.5 Syntaktische Struktur des LOB-Elements . . . . . . . . . . . . . . . . . . . 79

5.6 Textgruppe .................................... 80

5.7 Strukturgruppe.................................. 82

5.8 MdeiaGruppe .................................. 84

5.9 Lerngruppe .................................... 85

5.10Mathematikgruppe................................ 86

5.11 IMS Content Package Information Model . . . . . . . . . . . . . . . . . . . 87

5.12FormatierbarerKurs............................... 88

5.13VerschachtelteKurse............................... 91

5.14 Kursmodell Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.15 Abbildung eines Kurses auf die Bausteinstruktur . . . . . . . . . . . . . . . 93

5.16 Wiederverwendung von Lernmaterialien . . . . . . . . . . . . . . . . . . . . 95

5.17 Abbildung auf das Kursmodell . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.18Kursaggregation ................................. 99

5.19 Transformationspaket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.20 Modell des Transformationspakets . . . . . . . . . . . . . . . . . . . . . . . 103

5.21Abbildung.....................................104

5.22Prozessorpipeline.................................106

5.23Rollen .......................................107

5.24 Abbildung des Layouts auf die Transformatoren . . . . . . . . . . . . . . . . 108

5.25 Spezifikation des Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.26 Der Construction Kit Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.1 Das Autorenwerkzeug Lyssa ...........................117

6.2 Ansicht des Bausteinfensters . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.3 DerExport-Dialog ................................119

6.4 UML-Diagramm f¨

ur ein OO-Binding-Beispiel . . . . . . . . . . . . . . . . . 123

6.5 UML-Diagramm einer abstrakten Fabrik f¨

ur die Kursumwandlung . . . . . 127

6.6 Sequenzielle Darstellung eines Objekt Diagramms zur Veranschaulichung

einer bottom-up Kurskonstruktion........................129

6.7 UML-Klassendiagramm des Kursmodells . . . . . . . . . . . . . . . . . . . . 130

6.8 OpenOfficeScreenshot..............................132

6.9 Datenfluss eines Latex-Dokuments bei der Konvertierung in einen Forma-

tierbarenKurs. ..................................135

6.10 UML-Diagramm der Transformation Package Klasse . . . . . . . . . . . . . 136

6.11 Framework vs. Klassenbibliothek . . . . . . . . . . . . . . . . . . . . . . . . 139

6.12DasFramework..................................140

6.13 Lyssa Designer – Konfigurationsansicht . . . . . . . . . . . . . . . . . . . . 142

6.14 Lyssa Designer – Entwicklungsansicht . . . . . . . . . . . . . . . . . . . . . 143

6.15 Lyssa Designer – Grundeinstellung . . . . . . . . . . . . . . . . . . . . . . . 144

6.16 UML-Diagramm des Designers . . . . . . . . . . . . . . . . . . . . . . . . . 144

ABBILDUNGSVERZEICHNIS xi

6.17 CKS Browser – Erm¨

oglicht das Navigieren in verteilten Dateisystemen und

die ¨

Uberwachung nebenl¨

aufiger Aktionen . . . . . . . . . . . . . . . . . . . 146

6.18 CKS Administration – Eine Eingabemaske, mit der Benutzer und Benutze-

rinnen angelegt und gel¨

oschtwerden. .....................146

6.19 Schichtenmodell des Construction Kit Server . . . . . . . . . . . . . . . . . 147

7.1 Basisformat f¨

urKurse ..............................151

7.2 Kursmaterialien f¨

ur die Pr¨

asenzveranstaltung Technische Informatik in der

Grundstudiumsausbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.3 Der Baustein Minimierungsverfahren zusammengestellt aus einer Content-

Datei und mehreren Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . 153

7.4 Das Autorenwerkzeug Lyssa mit dem ge¨

offneten Kurs Grafische Minimierung154

7.5 Der Kurs Grafische Minimierung ¨

ubersetzt mit einem Transformationspa-

ket f¨

ur die Erstellung eines GET-Lab-Kurses. . . . . . . . . . . . . . . . . . 155

7.6 Ansicht einer interaktiven ¨

Ubung zur Minimierung mit KV-Diagrammen . . 156

7.7 Der Kurs Wechselstromschaltungen mit Zugriff auf den CKS . . . . . . . . 159

7.8 Pr¨

asentationsfolie Sinusf¨

ormige Signale aus dem Skript Systemtheorie . . . 160

7.9 Die Kursansicht von Lyssa mit dem importierten Systemtheorie-Skript . . . 161

7.10 Sinusf¨

ormige Signale als Onlinekurs. Bei dieser Pr¨

asentation wurde das

mαth-kit Layout verwendet . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.11 Screenshot des Lyssa-Designers . . . . . . . . . . . . . . . . . . . . . . . . . 166

7.12 Der Kurs Technische Informatik als PDF-Dokument . . . . . . . . . . . . . 167

7.13 Wahrscheinlichkeitstabelle des Bausteins Kodierungsverfahren nach Huffman168

7.14 Konstruktionsbreich des Bausteins Kondierungsverfahren nach Huffman . . 168

7.15 Auswertungsbereich des Bausteins Kondierungsverfahren nach Huffman . . 169

7.16 Baustein zur Zahlenumwandlung . . . . . . . . . . . . . . . . . . . . . . . . 170

7.17 Baustein Quiz-Umgebung Komplexe Zahlen . . . . . . . . . . . . . . . . . . 170

7.18 ¨

Uberlagerung zweier harmonischer Schwingungen . . . . . . . . . . . . . . . 171

7.19 Rechnen mit komplexen Zahlen (Kartesische Koordinaten) . . . . . . . . . . 171

xii ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis

2.1 Katalog mit kategorisierten Aspekten der Problembeschreibung . . . . . . . 10

2.2 Fertigkeitsstufen ................................. 15

2.3 Neun Kategorien f¨

ur Lernobjekte nach der Learning Object Metadata Spe-

zifikation(LOM) ................................. 28

3.1 Kategorien f¨

ur Elemente zur Strukturierung von DocBook Dokumenten . . 48

3.2 Gegen¨

uberstellung der analysierten Systeme . . . . . . . . . . . . . . . . . . 66

5.1 Attribute des cell-Elements .......................... 81

5.2 Attribute des mmo-Elements ........................... 83

5.3 Das Item Element der IMS Content Package Spezifikation . . . . . . . . . . 89

5.4 Layouttypen....................................109

6.1 Arbeitsteilung f¨

ur Systemkomponenten . . . . . . . . . . . . . . . . . . . . . 116

6.2 Abbildung Strukturelemente auf XML-Elemente . . . . . . . . . . . . . . . 120

6.3 Abbildung zwischen OpenOffice-Elementen und denen des Kursmodells . . 133

6.4 Abbildung zwischen OpenOffice-Elementen und dem Kursmodell . . . . . . 134

7.1 Integration der Komplexen Zahlen in unterschiedliche Fachrichtungen . . . 157

C.1 Attribute und Elemente des Transformationspakets . . . . . . . . . . . . . . 194

C.2 Attribute und Elemente des Kursmodells . . . . . . . . . . . . . . . . . . . 195

C.3 Attribute und Elemente des Layouts . . . . . . . . . . . . . . . . . . . . . . 196

xiii

xiv TABELLENVERZEICHNIS

Kurzfassung

Die Entwicklung multimedialer Lernmaterialien sowie die Konstruktion technischer Lern-

systeme, hat in den letzten Jahren einen zunehmenden Einfluss auf die Hochschullehre und

die betriebliche Ausbildung genommen. Neben zahlreichen Learning Management Syste-

men (LMS) zur Verwaltung von Kursen und Studierenden sowie technischen Systemen

zur Unterst¨

utzung des Konstruktionsprozesses, sind insbesondere Standardisierungen im

Kontext strukturierter Kursinhalte und deren Verwaltung durch Metadaten entstanden.

Die Entwicklung fach¨

ubergreifender Lernmaterialien setzt jedoch die Modellierung ab-

strakter modularer Materialien voraus, die bei konventionellen Ans¨

atzen meist wenig oder

gar nicht ber¨

ucksichtigt werden. Daher stellt die Integration bestehender Ressourcen in

einen Entwicklungsprozess oft ein un¨

uberwindbares und meist kostspieliges Problem dar.

Aus diesem Grund wird in dieser Arbeit ein technisches Modell vorgestellt, das die Ent-

wicklung technischer Systeme zur Erstellung modularer und darstellungsfreier Lernobjekte

erm¨

oglicht. Das Modell ist unter anderem durch das SCORM-Referenzmodell motiviert

und erweitert das dort definierte Aggregation-Model um ein Content-Model. W¨

ahrend

des zweistufigen Entwicklungsprozesses werden zun¨

achst ausschließlich der Inhalt sowie

die Struktur der Materialien spezifiziert. Beide werden separat in formatierbaren Baustei-

nen organisiert, wodurch sich frei skalierbare Aggregationslevel ergeben. In einem zweiten

Schritt wird anhand spezifischer Regeln ein Pr¨

asentationsformat abgeleitet und aus den

abstrakten Bausteinen ein spezialisierter Kurs generiert. Des weiteren beinhaltet das Mo-

dell einen Ansatz zur Integration bestehender Lernmaterialien, die in ihre Bestandteile

Kursstruktur, Inhalt, Metadaten und Ressourcen zerlegt und auf das abstrakte Kursmo-

dell abgebildet werden.

Im Gegensatz zu herk¨

ommlichen Systemen, unterst¨

utzt dieser Ansatz den kooperativen

Entwicklungsprozess von Teams. Abstrakt formulierte Lernbausteine und Kursfragmente

werden in einem zentralen Repository mit dem Ziel koordiniert, interdisziplin¨

are, auf das

Lernszenario angepasste Lernmaterialien, zu erzeugen.

Die Leistungsf¨

ahigkeit des Modells wird durch die Referenzimplementierung im Au-

torenwerkzeug Lyssa vorgestellt. Es enth¨

alt neben einem Autorensystem zur Aggregation

und Transformation auch ein Werkzeug zur Layoutdefinition sowie ein zentrales Repository

zur Verwaltung von abstrakten Lernmaterialien.

TABELLENVERZEICHNIS xv

xvi TABELLENVERZEICHNIS

Listings

3.1 Beispiel einer XML-Deklaration . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 EntityNotation.................................. 45

3.3 Beispiel einer Element-Definition . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4 DocBook Beispiel f¨

ur einen einfachen Artikel . . . . . . . . . . . . . . . . . 48

3.5 OMDoc Repr¨

asentation einer Definition . . . . . . . . . . . . . . . . . . . . 49

3.6 MathML-Beispiel einer Formel mit presentation encoding . . . . . . . . . . 50

3.7 MathML-Beispiel einer Formel mit content encoding . . . . . . . . . . . . . 51

3.8 Ein einfaches LMML-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Algorithmus Disaggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.1 Ein einfaches BrickML-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.2 BrickML Tabellen-Definition mit XML-Schema . . . . . . . . . . . . . . . . 121

6.3 Beispiel eins Manifests f¨

ur einen Grundlagenkurs Technische Informatik. . . 124

6.4 ¨

Ubersetzungsregel eines Listenelements mit XSL beschrieben . . . . . . . . 137

7.1 Dieses einfache Beispiel stammt aus einem Baustein zur Erl¨

auterung des Mi-

nimierungsverfahrens nach Quine-McCluskey und veranschaulicht ein XML-

basiertesLernobjekt ...............................151

7.2 Definition eines Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.3 XSL:FO-Dokument f¨

ur einen PDF-Kurs . . . . . . . . . . . . . . . . . . . . 164

7.4 XSL:FO-Liste f¨

ureinenPDF-Kurs .......................165

xvii

xviii LISTINGS

Kapitel 1

Einleitung

Seit der rasanten Entwicklung des Internets hat sich der menschliche Lernprozess grundle-

gend ver¨

andert. Wo fr¨

uher teure und langwierige Experimente durchgef¨

uhrt werden mus-

sten, k¨

onnen heute Methoden, Verfahren und Ergebnisse weltweit innerhalb weniger Se-

kunden abgerufen und evaluiert werden. Komplexe Probleme k¨

onnen aufgrund des großen

Fundus an Wissen schnell und effektiv gel¨

ost werden. Hierbei unterst¨

utzen Wissensdaten-

banken ebenso wie Disskusionsforen, in denen Fragestellungen mit Experten und Exper-

tinnen analysiert werden.

Das Fachgebiet, das einerseits aus der Kombination der technischen M¨

oglichkeiten

durch Computer und Netzwerke und andererseits durch das p¨

adagogische Lernen entstan-

den ist, wird als E-Learning bezeichnet. Der Einsatz von E-Learning-Anwendungen weitet

sich zunehmend auf Privathaushalte, Universit¨

aten, Schulen und Firmen aus, die ihre Mit-

arbeiter und Mitarbeiterinnen bzw. Lernende effizienter schulen und ausbilden k¨

onnen.

Der in den letzten zehn Jahren entstandene E-Learning-Hype hat sich auch betr¨

acht-

lich auf die Forschung ausgewirkt. Zunehmend werden nationale und internationale For-

schungsprojekte ins Leben gerufen, die sich mit Fragestellungen und Problemen zur Erstel-

lung und Anwendung von E-Learning-Inhalten befassen. In Deutschland hat das Bundes-

ministerium f¨

ur Bildung und Forschung (BMBF) im Jahr 2000 das Schwerpunktprogramm

“Neue Medien in der Bildung”gestartet und f¨

ordert seither mehr als 100 Projekte, an denen

Hochschulen und Unternehmen gleichermaßen beteiligt sind.

Im Rahmen von Forschungsprojekten, der Universit¨

atslehre und der betrieblichen Fort-

bildung, sind in den letzten Jahren zahlreiche E-Learning-Inhalte entstanden, die die in-

dividuelle Ausbildung unterst¨

utzen und verbessert haben. Oft sind multimediale Inhalte

durch den Einsatz hoher Personalkosten entwickelt worden, wodurch Problemen, wie Nach-

haltigkeit und Wiederverwendbarkeit, wenig Beachtung geschenkt wurde. Obwohl es im

Hochschulbereich zahlreiche ¨

Uberschneidungen bei Themen in der Grundlagenausbildung

gibt, sind die meisten Inhalte jedoch derart aufbereitet, dass sie nicht in verwandten Fach-

disziplinen eingesetzt werden k¨

onnen. Daraus resultiert, dass E-Learning-Inhalte mehrfach

f¨

ur dasselbe Thema produziert werden und außerdem nicht in bestehende Inhalte integriert

werden k¨

onnen. Das liegt insbesondere an der individuellen Gestaltung und Aufbereitung,

der Ber¨

ucksichtigung didaktischer Aspekte sowie an der Festlegung des Granularit¨

atsle-

2 KAPITEL 1. EINLEITUNG

vels bei der Themenzusammenstellung. Obwohl es theoretische ¨

Uberlegungen, wie z. B. die

Formulierung der Inhalte als Lernobjekte [Wiley00b] und technische Rahmenbedingungen,

wie Standardisierungen (vgl. Kapitel 2.3) im E-Learning-Bereich gibt, fehlt es dennoch an

Methoden und Verfahren Kurse derart zu gestalten, dass Autoren und Autorinnen bereits

bestehende Materialien nahtlos ¨

ubernehmen und auf ihre Bed¨

urfnisse anpassen k¨

onnen.

Aus diesem Bedarf heraus ist es Ziel dieser Arbeit, ein Modell zu entwickeln, nach dem

es m¨

oglich ist, E-Learning-Inhalte semantisch zu modellieren, ohne sich auf individuelle

Auspr¨

agungen, didaktische Konzepte oder gar auf spezielle Anwendungen festzulegen.

1.1 Zielsetzung der Arbeit

Ziel dieser Arbeit ist die Entwicklung eines Modells zur formalen Beschreibung von E-

Learning-Inhalten, das Autoren und Autorinnen eine nachhaltige Generierung von Inhalten

erm¨

oglicht. Der Bedarf eines solchen Modells hat sich gerade am Anfang des Projekts

mαth-kit (vgl. Abschnitt 1.2) herausgestellt, da Inhalte der Mathematik fach¨

ubergreifend

entwickelt werden sollten und es keinen Mechanismus zur modularen Konstruktion gab,

der die Integration erm¨

oglicht h¨

atte. Ohne ein entsprechendes Modell, w¨

aren individuell

gestaltete Einzell¨

osungen produziert worden, die mit den Mitteln des World Wide Web

(WWW) durch Hyperlinks zusammengesetzt worden w¨

aren. Aus diesem Bedarf heraus,

soll in dieser Arbeit ein theoretisches Modell zur Konstruktion solcher E-Learning-Inhalte

entwickelt werden und die technische Realisierung im Projekt mαth-kit prototypisch zum

Einsatz kommen.

Das dargelegte Problem tritt naturgem¨

aß nicht nur im Projekt mαth-kit auf, sondern

l¨

asst sich ebenso auf anderer Projekte ¨

ubertragen. Deshalb wird die Forschungsfrage all-

gemein formuliert:

“Wie lassen sich E-Learning-Inhalte unabh¨

angig von einer individuellen

Darstellung, einem didaktischen Konzept und einem Pr¨

asentationsformat for-

mulieren, damit sie von anderen Autoren und Autorinnen nahtlos integriert

und unabh¨

angig vom ausgew¨

ahlten Lernszenario eingesetzt werden k¨

onnen?”

Aus dieser allgemeinen Fragestellung lassen sich weitere, detaillierte Fragestellungen

ableiten, die das Gesamtziel deutlicher darlegen:

•Wie k¨

onnen Lerneinheiten kontextunabh¨

angig mit anderen Lerneinheiten aggregiert

werden, ohne sich w¨

ahrend des Konstruktionsprozesses auf ein konkretes Pr¨

asenta-

tionsformat festzulegen (Formatierbarkeit)?

•Wie lassen sich Struktur und Inhalt von Lerneinheiten formal von ihrer Pr¨

asentation

entkoppeln (Modularit¨

at)?

•Welche Granularit¨

at von Lernmodulen sollte f¨

ur eine Wiederverwendung gew¨

ahlt

werden?

1.2. EINGLIEDERUNG DER ARBEIT IN DAS PROJEKT MαTH-KIT 3

•Wie m¨

ussen Lerneinheiten beschaffen sein, damit sie in verschiedenen Fachdisziplinen

einsetzbar sind (Interdisziplinarit¨

at)?

•Durch welche Maßnahmen k¨

onnen Lerneinheiten nachhaltig von Bestand sein?

•Welche Mechanismen sind notwendig, um bereits existierende Lernmaterialien in den

Entwicklungsprozsess mit einzubeziehen (Intergrierbarkeit)?

•Wie kann der kooperative Entwicklungsprozess f¨

ur E-Learning-Inhalte in Projekt-

teams unterst¨

utzt werden (Kooperation)?

•Auf welche technische und p¨

adagogische Weise findet die Wissensvermittlung mit E-

Learning Materialien statt und welche Methoden und Paradigmen m¨

ussen modelliert

werden?

•Welchen Einfluss haben didaktische Aspekte f¨

ur den Entwicklungsprozess? Hierbei

ist festzustellen, wie der Dialog zwischen Lernmaterialen und Anwendern bzw. An-

wenderinnen stattfindet.

Wie bereits erw¨

ahnt wurde, setzt sich der Themenbereich E-Learning nicht nur aus

technischen Systemen oder Werkzeugen zur Gestaltung von Inhalten zusammen, sondern

auch aus didaktischen und p¨

adagogischen Methoden und Verfahren. Der Fokus dieser

Arbeit richtet sich vor allem auf die technischen Aspekte der Modellierung und l¨

asst p¨

dagogische Gesichtspunkte, sofern sie nicht von zentralem Interesse sind oder notwendig

f¨

ur die Entwicklung des technischen Modells, weitestgehend außer acht. Ferner besteht

auch kein Interesse an einem Verfahren, welches auf linguistischer Ebene Inhalte analy-

siert und bewertet. Vielmehr soll das entwickelte Modell bei der technischen Modellierung

von Softwaresystemen und der Konstruktion von Inhalten herangezogen werden, damit sie

kooperativ und nachhaltig genutzt werden k¨

onnen.

1.2 Eingliederung der Arbeit in das Projekt mαth-kit

Die in dieser Arbeit produzierten Ergebnisse und durchgef¨

uhrten Untersuchungen sind

im Rahmen des Forschungsprojekts mαth-kit 1[Mat05a] entstanden, welches im M¨

arz

2001 durch das Bundesministerium f¨

ur Bildung und Forschung (BMBF) im Schwerpunkt-

programm “Neue Medien in der Bildung” ins Leben gerufen wurde. Im Mittelpunkt des

Vorhabens stand die Konzeption und Entwicklung eines Baukastensystems f¨

ur multime-

diale Lerninhalte mit dem Schwerpunkt Mathematik. Die verfolgten Projektziele waren

die Verbesserung der Grundstudiumsausbildung durch den Einsatz von Lerneinheiten zur

Exploration, ¨

Ubungen mit direkter Erfolgskontrolle und Lerneinheiten zur Pr¨

asentation

in Lehrveranstaltungen. Die in einem virtuellen Baukasten aufbewahrten Lerneinheiten

und Lernmodule sollten wie in einem richtigen Baukasten gelagert und verwaltet werden,

1Gef¨

ordert vom Bundesministerium f¨

ur Bildung und Forschung (BMBF), Projekt math-kit (08NM084)

4 KAPITEL 1. EINLEITUNG

um sie in Lehrmaterialien verschiedener Fachdisziplinen2, basierend auf einem Fundus

mathematischer Grundlagen, einsetzen zu k¨

onnen. Die Inhalte sind im Rahmen eines Ver-

bundprojekts der Universit¨

aten Hamburg, Bayreuth, Paderborn und Hagen entstanden,

die unterschiedliche Expertisen und Erfahrungen einbrachten.

Zun¨

achst an der Universit¨

at Hamburg, sp¨

ater an der Universit¨

at Paderborn fortge-

f¨

uhrt, wurde ein Baukastensystem zur allgemeinen Verwaltung modularer Lerneinheiten

entwickelt und Lerneinheiten f¨

ur die Grundstudiumsveranstaltung Technische Informatik

entwickelt. Zudem wurden an der Universit¨

at Paderborn Materialien f¨

ur die Veranstaltung

Mathematik f¨

ur Maschinenbauer produziert.

Dar¨

uber hinaus verbesserte das Projekt mαth-kit auch die Lehre an der Fernuniversi-

t¨

at Hagen. Die dort ans¨

assige Gruppe entwickelte spezielle Lernmaterialien zum Thema

Lineare Algebra, die spezielle Aspekte des Fernstudiums ber¨

ucksichtigen. Damit die ent-

wickelten Inhalte Studierenden zug¨

anglich waren und der Dialog zwischen Anwendern und

Lernmaterialen stattfand, evaluierte die Gruppe der Universit¨

at Bayreuth die Inhalte und

brachte Beitr¨

age zur didaktischen Gestaltung ein. Neben universit¨

aren Instituten liefer-

te auch eine industrielle Einrichtung dem Projekt wichtige Ergebnisse. So wurde von der

Firma Sci-Face, im Rahmen der Projektlaufzeit, ein Computing Server (MCS) f¨

ur das Ma-

thematikprogramm MuPad umgesetzt, der f¨

ur die Berechnung komplexer mathematischer

Formeln herangezogen werden konnte.

Das in dieser Arbeit vorgestellte Modell liefert einen wichtigen Beitrag zu dem im

Projekt mαth-kit entwickelten Baukastensystem. Es beschreibt auf theoretischer und kon-

zeptioneller Ebene einen Rahmen, der als Grundlage f¨

ur die Implementierung eines Au-

torensystems gilt, welches von den am Projekt beteiligten Arbeitsgruppen eingesetzt und

bewertet wurde.

1.3 Vorgehensweise und Aufbau der Arbeit

Diese Arbeit dokumentiert die Vorgehensmethodik und den Arbeitsprozess der zur L¨

osung

der in Kapitel 1.1 beschriebenen Problemstellung gew¨

ahlt wurde. Zu Beginn der Arbeit

steht die Forschungsfrage im Mittelpunkt der Untersuchung. Es wird ¨

uberpr¨

uft, welche

Ergebnisse hinsichtlich der gestellten bzw. aufgeworfenen Fragen bereits erzielt worden

sind und anschließend bewertet. Die gewonnen Resultate fließen in die konzeptionelle Phase

und die Umsetzung des Modells mit ein. Damit das Modell evaluiert und bewertet werden

kann, wird ein Prototyp entwickelt, an dem die Richtigkeit sowie die Praxistauglichkeit

abgeleitet werden kann. Abschließend findet eine Bewertung der erzielten Ergebnisse statt,

die in Relation zu den aufgeworfenen Fragen diskutiert wird.

In Kapitel 2 und Kapitel 3 wird der aktuelle Stand der Forschung in Zusammenhang

mit der in diesem Kapitel gestellten Forschungsfrage dargelegt. F¨

ur die Analyse und die

abschließende Bewertung wird ein Kriterienkatalog herangezogen, mit dem sich Grundla-

2Im Zeitraum der Projektlaufzeit sollen multimediale Lerneinheiten zur Evaluierung in den Veran-

staltungen Mathematik f¨

ur Maschinenbauer,Mathematik f¨

ur Informatiker,Digitale Systeme und in den

Fernstudiumskurs Lineare Algebra eingesetzt werden.

1.3. VORGEHENSWEISE UND AUFBAU DER ARBEIT 5

gen, Verfahren und bestehende Systeme einsch¨

atzen und bewerten lassen. Hierbei werden

Forschungsergebnisse, die sich mit den Themen Formatierbarkeit, Modularit¨

at, Granu-

larit¨

at, Interdisziplinarit¨

at und Nachhaltigkeit von Lernmaterialien befassen, ausgewer-

tet und analysiert. Es werden sowohl technische als auch theoretische Grundlagen, die

zum Verst¨

andnis der beschriebenen Systeme beitragen, vorgestellt und er¨

ortert. Hierzu

z¨

ahlen neben lerntheoretischen Grundlagen die Definitionen der Begriffe Multimedia und

E-Learning. Die abschließende Bewertung aktueller Arbeiten dient als Grundlage f¨

ur die

Modellierung und Implementierung.

Kapitel 5 beschreibt das Modell zur konsistenten Kursentwicklung von E-Learning-

Inhalten. Als Basis f¨

ur die Modellierung dient das Baukastenprinzip, welches aus dem

Kontext und der Aufgabenstellung des Projekts mαth-kit f¨

ur einen technischen L¨

osungs-

ansatz abgeleitet wird. Ausgehend von diesem Prinzip wird zun¨

achst die Konstruktion for-

matierbarer Lernbausteine beschrieben. An diesem Punkt fließen neben technischen auch

p¨

adagogische ¨

Uberlegungen in die Modellierung mit ein. Weiterhin wird auf die Kurskon-

struktion eingegangen und ein Konzept zur abstrakten Beschreibung von Inhalten vorge-

stellt, welches vor allem f¨

ur die Integration bereits existierender digitaler Lehrmaterialien

und Onlinekurse ben¨

otigt wird. Weiterhin wird gezeigt, wie Kurse von Studierenden und

Lehrenden in Abh¨

angigkeit eines pr¨

aferierten Lernszenarios publiziert und angewendet

werden k¨

onnen. Insbesondere wird das Transformationspaket vorgestellt, mit dessen Hilfe

sich individuelle und gestalterische Elemente separieren lassen. Abschließend wird auf den

Entwicklungsprozess kooperierender Projektteams eingegangen und dargelegt, wie die ko-

operative Entwicklung von Lerninhalten, unterst¨

utzt durch eine dezentrale Datenhaltung,

mit dem Kursmodell verbessert und effizienter gestaltet werden kann.

Kapitel 6 stellt den Prototyp vor, der zur Realisierung der theoretischen ¨

Uberlegun-

gen implementiert worden ist. Der Prototyp ist ein Autorenwerkzeug zur Gestaltung von

formatierbaren Lerninhalten, die adaptiert und publiziert werden k¨

onnen. Neben dem

Autorenwerkzeug ist ein weiteres Werkzeug zur Entwicklung von Pr¨

asenationsformaten

und deren Layouts entstanden sowie ein Server zur kooperativen Entwicklung. Zus¨

atzlich

stehen die technischen Aspekte, die bei der Umsetzung des Prototyps herausgearbeitet

wurden, im Vordergrund und werden im jeweiligen Kontext er¨

ortert.

In Kapitel 7 wird exemplarisch ein Kurs zum Technische Informatik vorgestellt, im

Rahmen des Projekts mαth-kit erstellt wurde. Es wird der Einfluss der erzielten Ergebnis-

se auf den Erstellungsprozess diskutiert und der daraus entstehende Mehrwert verdeutlicht.

Dabei wird der kooperative Entwicklungsprozess und die damit verbundene projekt¨

uber-

greifende Nutzung von Lernmaterialien verdeutlicht.

Nach der Zusammenfassung in Kapitel 8, werden in Kapitel 9 die Resultate der Arbeit

in Anlehnung an die Aufgabenstellung bewertet. Es wird auf die Erfahrungen im Umgang

mit dem Prototypen und auf Kooperationen mit industriellen Partnern zur¨

uckgegriffen.

Insbesondere wird gezeigt, dass der Prototyp die zu Beginn der Projektlaufzeit auftreten-

den Probleme l¨

ost und ein effektives und effizientes Arbeiten erm¨

oglicht.

Abschließend wird in Kapteil 10 ein Ausblick auf weitere interessante Fragestellungen

gegeben, die im zeitlichen Projektrahmen nicht weiter untersucht werden konnten.

6 KAPITEL 1. EINLEITUNG

Teil I

Stand der Forschung und Technik

Kapitel 2

Grundlagen

In diesem Kapitel werden zun¨

achst die f¨

ur diese Arbeit relevanten Grundlagen und For-

schungsergebnisse auf dem Gebiet E-Learning dargelegt. Zu Beginn werden die grundle-

genden Begriffe Multimedia und E-Learning eingef¨

uhrt. Es soll ein Grundverst¨

andnis der

g¨

angigen Lerntheorien entwickelt werden, um eine Charakterisierung und Zuordnung mo-

derner Lernsysteme leichter durchzuf¨

uhren. Zu diesen theoretischen Grundlagen wird der

aktuelle Stand der Forschung im Bereich der Standardisierung von E-Learning-Inhalten

vorgestellt, der sich ¨

uber die Jahre hin aus den Ergebnissen zahlreicher Forschungsprojekte

entwickelt hat und deren Ergebnisse sich mit der Unterst¨

utzung unterschiedlicher Gremien

gerade zu etablieren beginnen. Einige dieser wissenschaftlichen Arbeiten besch¨

aftigen sich

mit Lernobjekten, die f¨

ur das in dieser Arbeit vorgestellte Modell eine solide Grundlage

bilden und einen wichtigen Beitrag f¨

ur den Modellierungsprozess leisten.

Damit die Analyse bestehender Systeme, Plattformen, Standardisierungen, Materiali-

en und Theorien im Kontext des in dieser Arbeit verfolgten Ziels stehen, werden zu den

in Kapitel 1 aufgeworfenen Fragestellungen Bewertungskriterien definiert. Auf diese wird

bei den anstehenden Analysen sowie bei der abschließenden Bewertung Bezug genommen,

so dass der Zusammenhang zum eigentlichen Thema dieser Arbeit hergestellt wird. Ta-

belle 2.1 zeigt die aus der Zielsetzung abgeleiteten Bewertungskriterien f¨

ur diesen Teil der

Arbeit.

2.1 Multimediales Lernen

Bei der Analyse von Autorensystemen, Lernplattformen (vlg. Kapitel 3.3) und multime-

dialen Lernangeboten gibt es eine Vielzahl unterschiedlicher Systeme und Produkte. Bei

genauerer Betrachtung wird schnell ersichtlich, dass sie sowohl in ihrer Anwendung als

auch in ihrer Qualit¨

at erhebliche Unterschiede aufweisen. Je nach Anwendungskontext

unterst¨

utzen solche Systeme den Erstellungsprozess von Lehrinhalten und deren Verwal-

tung. Um sie bewerten zu k¨

onnen und im Verlauf dieses Kapitels Position zu beziehen,

sollen die Fragen “Was ist multimediales Lernen?” und “Wie lernt der Mensch?” beant-

wortet werden. Hierzu ist es zwingend notwendig, die Begriffe Multimedia und E-Learning

[Frerich00,Lytras,Reglin03] genau zu definieren. Dies ist jedoch keineswegs einfach, da die

10 KAPITEL 2. GRUNDLAGEN

Bewertungskriterien Fragestellungen

Formatierbarkeit Besteht die M¨

oglichkeit, die Struktur der Lerneinheit von

der Pr¨

asentation zu entkoppeln?

Modularit¨

at K¨

onnen Lerneinheiten mit anderen kontextunabh¨

angig ag-

gregiert werden?

Granularit¨

at Wie l¨

asst sich die Granularit¨

at der Lernmodule justieren?

Interdisziplinarit¨

at Ist dieselbe Lerneinheit in verschiedenen Kontexten einsetz-

bar?

Nachhaltigkeit K¨

onnen Lerneinheiten nachhaltig bestehen?

Integrierbarkeit Ist es m¨

oglich, bestehende Ressourcen wiederzuverwenden?

Kooperation Wird die kooperative Arbeit in Projektteams unterst¨

utzt?

Mathematik Wie werden mathematische Lehrinhalte behandelt?

Didaktik Wie ist der Dialog zwischen Lerneinheiten bzw. Plattformen

und Lernenden definiert und welche Lernformen, also die Art

der Wissensvermittlung, werden unterst¨

utzt ?

Tabelle 2.1: Katalog mit kategorisierten Aspekten der Problembeschreibung

Begriffe nicht immer einheitlich verwendet werden, sondern speziell formuliert sind, d. h.

auf eine bestimmte Anwendungsdom¨

ane bezogen. Aus diesem Grund soll in den folgenden

Abschnitten eine einheitliche Sicht auf die grundlegenden Begriffe erarbeitet werden.

2.1.1 Multimedia

F¨

ur den Begriff Multimedia existieren abh¨

angig vom Betrachtungswinkel unterschiedli-

che Definitionen. Grunds¨

atzlich beschreibt der Begriff das kombinierte Auftreten ver-

schiedener visueller und akustischer Medien. Aus technischer Sicht definiert Negroponte

[Negroponte96] den Begriff Multimedia als die Vermischung digitaler Daten wie Bilder,

Animationen oder Musik. Neben diesem technischen Ansatz gibt es auch die informati-

onstechnische Betrachtungsweise, bei der der Begriff Multimedia nicht nur die Datenty-

pen einschließt, sondern speziell den Informationsbegriff ber¨

ucksichtigt [Schulmeister96].

Hiermit ist insbesondere die Informationsverarbeitung des Benutzers bzw. der Benutzerin

gemeint, die aus den unterschiedlichen Daten erst Informationen ableiten. Ein weiterer

Aspekt konzentriert sich auf die Interaktivit¨

at von Multimedia. Damit ist vor allem das

interaktive Einwirken durch Anwender und Anwenderinnen auf den sequenziellen Ablauf

von Multimedia gemeint. Schulmeister fasst diese unterschiedlichen Sichtweisen auf den

Multimediabegriff zu einer allgemeinen Definition zusammen:

”... dass Multimedia als eine interaktive Form des Umgangs mit symbolisch-

em Wissen in einer computergest¨

utzten Interaktion betrachtet werden muss

([Schulmeister96], Seite 18).”

Kerres [Kerres98] betrachtet bei seiner Definition von Multimedia außerdem das Me-

dium, welches sich nicht nur durch analoge oder digitalisierte Daten auszeichnet, sondern

2.1. MULTIMEDIALES LERNEN 11

ebenso durch das ¨

Ubertragungsmedium, wie z. B. das Kabelnetz, Telefonnetz oder das In-

ternet. Diese Gruppe von Medien werden als Telemedien bezeichnet und sind zum gr¨

oßten

Teil disjunkt mit Multimedien, da sie sich schlichtweg auf ¨

Ubertragungswege und Techni-

ken reduziert.

2.1.2 E-Learning

Der Begriff E-Learning wurde Mitte der neunziger Jahre gepr¨

agt und bezeichnet im Kern

die Wissensvermittlung mit Hilfe elektronischer Ger¨

ate. Hinzu kommt die Unterst¨

utzung

des Lernprozesses durch unterschiedliche Medientypen, wie z. B. Multimedia oder Teleme-

dien. Die urspr¨

ungliche Form der computergest¨

utzten Wissensvermittlung reicht bis in die

sechziger Jahre zur¨

uck, in denen Skinner und Holland Lernmaschinen entwickelt haben,

die Wissen auf Textbasis vermittelten, das anschließend durch gezielte Fragen ¨

uberpr¨

uft

wurde [Niegemann03]. In den achtziger Jahren ist der Begriff CBT (Computer Based Trai-

ning) eingef¨

uhrt worden, der als allgemeiner ¨

Uberbegriff f¨

ur die Wissensvermittlung mit

Computern verstanden wird. Erst mit der Entwicklung des World Wide Web (WWW)

hat sich eine neue Dimension der Wissensvermittlung ergeben. Seither konnten computer-

gest¨

utzte Lernprogramme ¨

uber das Internet ¨

ubertragen werden. Seitdem haben Lernende

die M¨

oglichkeit, mit anderen Lernenden in Kontakt zu treten, Erfahrungen auszutauschen

und gemeinsame Fragestellungen zu ergr¨

unden (kooperatives Lernen). Diese Art der Wis-

sensvermittlung wird als WBT (Web Based Training) bezeichnet.

Multimedien

CBT

WBT

Telemedien

Abbildung 2.1: Begriffsbeschreibung (vgl. [Kerres98], Seite 14)

Der Begriff E-Learning wird also als Oberbegriff f¨

ur alle Arten der Wissensvermittlung

uber das Internet verstanden [Kerres98]. In der Tat l¨

asst sich der Begriff nur vage definie-

ren, weil er neben p¨

adagogischen, sozialen und didaktischen Aspekten auch technische mit

einschließt. Demnach sollen zwei grundlegende Begriffsdefinitionen vorgestellt werden:

”... e-Learning als einen ¨

ubergeordneten Begriff f¨

ur softwareunterst¨

utztes

Lernen verstehen ([Baumgartner02], Seite 5)”.

12 KAPITEL 2. GRUNDLAGEN

”e-Learning findet statt, wenn Lernprozesse in Szenarien ablaufen, in denen

gezielt multimediale und (tele-) kommunikative Technologien integriert sind

[Seufert02].”

Wie bereits erw¨

ahnt wurde, hat das E-Learning gerade zu Beginn des 21. Jahrhun-

derts einen starken Einfluss auf die Organisation der Lehre an Hochschulen ausge¨

ubt.

Dieses zeigt sich insbesondere durch die zahlreichen F¨

orderprogramme des Bundesmini-

steriums f¨

ur Bildung und Forschung (BMBF), wie z. B. die Programme “Neue Medien in

der Bildung” und “Notebook Universities”. Hierbei steht f¨

ur die Hochschulen die Effizienz-

und Effektivit¨

atssteigerung der Lehre im Blickpunkt. Simon [Simon02] leitet den Begriff

Effizienz am Verh¨

altnis der Input-Output-Qualit¨

at der Lehre ab. Demnach ist eine Bil-

dungseinrichtung effizienter, wenn sie bei gleichbleibender Qualit¨

at der Lehre mehr Stu-

dierende betreut. Dieses l¨

asst sich zweifellos durch den Einsatz von E-Learning erreichen,

wodurch die dezentrale Wissensvermittlung – d. h. die zeit- und ortsunabh¨

angige Wissens-

aufnahme von Studierenden – unterst¨

utzt wird. Daniel [Daniel98] weist darauf hin, dass

die Ursache f¨

ur eine solche Effizienzsteigerung in der strikten Trennung zwischen dem Ent-

wicklungsprozess von Materialien und deren Inhaltsvermittlung liegt. Ein Beispiel hierf¨

ist die Fernuniversit¨

at Hagen. Durch den digitalen Vertrieb von Lehr- und Lernmaterialien,

anstatt der herk¨

ommlichen Zuteilung ¨

uber den Postweg [Bauch03], wird eine erhebliche

Reduktion des logistischen und finanziellen Aufwands seitens der Fernuniversit¨

at erreicht.

Eine solche Effizienzsteigerung ist auch das Ziel dieser Arbeit. In Kapitel 1.2 wurde das

Forschungsprojekt mαth-kit vorgestellt, in dessen Rahmen diese Arbeit ausgewertet wird

und verschiedene Formen der Wissensvermittlung, wie z. B. Pr¨

asenzlehre oder Fernlehre

mit einfließen. Es sollen also Mechanismen untersucht und entwickelt werden, mit deren

Unterst¨

utzung eine Effizienzsteigerung durch Reduktion des Inputs erzielt werden kann.

2.2 Lerntheorie

Bei der Entwicklung von E-Learning Inhalten ist es bereits in der Konzeptionsphase wich-

tig, festzulegen, mit welcher Methodik Lernprogramme das Wissen an Studierende wei-

tergeben. Die Festlegung auf eine bestimmte Lernstrategie h¨

angt zum einen von dem zu

vermittelnden Stoff ab, den Lehrende ausw¨

ahlen und zum anderen von den Fertigkeiten der

Studierenden. Um ein grundlegendes Verst¨

andnis f¨

ur den Lernprozess zu entwickeln, und

diesen bei der Konstruktion zu ber¨

ucksichtigen, wird zun¨

achst das von Dreyfus [Dreyfus86]

eingef¨

uhrte hierarchische Lernmodell vorgestellt, bei dem Lernende von Anf¨

angern mit

einfachen Faktenwissen zu Experten mit intuitiven F¨

ahigkeiten fortschreiten. Hierbei wird

sukzessiv auf jede Entwicklungsstufe eingegangen und dabei auf m¨

ogliche Gefahren mit

dem Umgang des Wissens hingewiesen. Ausgehend vom Prozess, wie der Lernende sich ent-

wickelt, sind auch die Mechanismen und Verfahren zum Wissens- und F¨

ahigkeitserwerb

von Interesse. Aus diesem Grund werden die drei wichtigsten Lernparadigmen Behavioris-

mus,Kognitivismus und Konstruktivismus vorgestellt. Aufbauend auf diesen Grundlagen

erlaubt das von Baumgartner [Baumgartner99] eingef¨

uhrte Heuristische Lernmodell, Wei-

terbildungsprozesse hinsichtlich der variablen Lernziele, Lehrinhalte und Lehrstrategie zu

2.2. LERNTHEORIE 13

betrachten.

2.2.1 Lernprozess

Im Folgenden werden die einzelnen Stufen des Lernprozesses nach Baumgartner

[Baumgartner97,Baumgartner99,Baumgartner95] beschrieben.

Anf¨

anger/-in

Der bzw. die Anf¨

anger/-in ist im Umgang mit Fachwissen noch nicht vertraut. Er bzw.

sie sammelt Schritt f¨

ur Schritt Wissen an, indem objektive Fakten erlernt werden, die

in einem allgemeinen Kontext g¨

ultig sind. Ausgehend von den gelernten Fakten und Re-

geln ist der Lernende in der Lage, Merkmale und Strukturen wieder zu erkennen. Dem

Lernenden ist also die Existenz bestimmter Regeln und Fakten bewusst, ohne den Hinter-

grund tiefgr¨

undig zu verstehen. Er bzw. sie ist daher nicht in der Lage, die Regeln ohne

nachzufragen bzw. einem Einwirken von außen anzuwenden, weil er bzw. sie noch nicht

selbst entscheiden kann, welche die richtige Regel ist. Als Beispiel wird eine Person be-

trachtet, die das Schachspielen erlernt. Zu Beginn wird versucht, jeden Figurentausch auf

ein Punktesystem zur¨

uckzuf¨

uhren, indem jeder Figur eine bestimmte Anzahl von Punkten

zugeordnet wird. Ein Tausch mit einer gegnerischen Figur lohnt sich nach dieser Regel

nur, wenn ein Punktevorsprung erzielt wird. Ihm bzw. ihr ist zu diesem Zeitpunkt nicht

klar, dass es Situationen gibt, in denen ein Tausch mit der gegnerischen Figur trotz Punk-

teverlust einen Vorteil liefert. Ein weiteres Beispiel ist der bzw. die Fahranf¨

angerin, die zu

Beginn lernt, bei einer bestimmten Geschwindigkeit das Getriebe zu schalten.

Fortgeschrittene/-r

Die erworbenen kontextfreien Regeln, d. h. Regeln und Merkmale die isoliert betrachtet

werden, m¨

ussen durch ¨

Ubungen in konkreten praktischen Situationen angewendet werden.

Durch diese Form des erfahrenden Lernens erwirbt der bzw. die Anf¨

angerin die F¨

ahigkeit,

erlernte Regeln auf situationsabh¨

angige Ereignisse anzuwenden und Situationen richtig

einzusch¨

atzen. Der bzw. die Schachspieler/-in erkennt beispielsweise nach einer gewissen

Zeit, dass bestimmte situationsabh¨

angige Stellungen ung¨

unstig f¨

ur die Deckung strategi-

scher Figuren sind, ohne daf¨

ur auf definierte Regeln zur¨

uckzugreifen. Ebenso ver¨

andert

sich das Schaltverhalten einer Autofahrerin je nach Situation und Motorenger¨

ausch. Die

Gefahr, die Lernenden in den ersten zwei Stufen droht, ist eine zu starke Generalisie-

rung der Fakten und Regeln. Der bzw. die Lernende versucht, die sehr allgemeinen Regeln

auf spezielle Situationen anzuwenden ohne sie gegebenenfalls an das fokussierte Problem

anzupassen.

Kompetenz

Diese Lernstufe ist erreicht, wenn eine Person die relevanten Fakten und Regeln kennt und

sie in den meisten F¨

allen auch anwenden kann. Hierdurch ist die kompetente Person in

14 KAPITEL 2. GRUNDLAGEN

der Lage, eine Vielzahl von Problemen zu l¨

osen und selbst¨

andig zu handeln. Es wird also

das Erreichen des Ziels gegen¨

uber dem Anwenden von Regeln in den Vordergrund gestellt.

Der Schachspieler wird nach dem einfachen Anwenden der Regeln an den Punkt gelangen,

den gegnerischen K¨

onig anzugreifen mit dem Ziel das Spiel zu gewinnen. Ebenso wird sich

der oder die Autofahrer/-in nach einer gewissen Zeit mehr auf das Erreichen des Ziels

konzentrieren, als auf das genaue Einhalten der Verkehrsregeln. Bei dieser Stufe kann es

jedoch leicht zur Selbst¨

ubersch¨

atzung kommen.

Gewandtheit

Haben Lernende die vierte Lernstufe erreicht, besitzen sie die F¨

ahigkeit gewandt zu han-

deln. Dies bedeutet, dass in bestimmten Situationen der Entscheidungsprozess f¨

ur eine

anzuwendende Regel nicht mehr evaluiert werden muss, sondern aufgrund der bereits ge-

sammelten Erfahrungen getroffen wird. Durch eine auf Erfahrungen basierte Subsummie-

rung von Merkmalen und durch Vernachl¨

assigung nicht relevanter Eigenschaften, gestaltet

sich die Wahl der anzuwendenden Regel intuitiv. Die Eigenschaft, intuitiv Muster auf Sze-

nen anzuwenden und nur bestimmte Merkmale zu betrachten nennt Dreyfuss “holistisches

Erkennen von ¨

Ahnlichkeiten”. Ein bzw. eine Autofahrer/-in, die mit hoher Geschwindig-

keit bei nasser Fahrbahn auf eine Kurve zuf¨

ahrt, muss sich entscheiden, ob sie bremst,

das Gas wegnimmt oder den Motor zum Bremsen einsetzt. Gewandte Autofahrer und Au-

tofahrerinnen entscheiden sich aufgrund ihrer bereits gesammelten Erfahrungen, ohne die

einzelnen M¨

oglichkeiten durchzugehen. Der bzw. die gewandte Schachspieler/-in besitzt

entsprechend die Fertigkeit sich je nach der Spielsituation die Strategie auszuw¨

ahlen, f¨

die lediglich eine kleine Menge m¨

oglicher Z¨

uge in Frage kommen.

Expertentum

Eine Person, die Expertise in einem Gebiet erworben hat, vermag intuitiv zu handeln. Sie

muss nicht ¨

uber anzuwendende Regeln nachdenken, sondern trifft in jeder Situation en-

gagiert und verantwortungsbewusst eine Entscheidung. Das intuitive Handeln verschmilzt

mit dem K¨

orper zu einer Einheit. So ist z. B. das Gehen einer erwachsenen Person ei-

ne intuitive Handlung eines Experten. Die Gefahr, die sich f¨

ur diese und die vorherige

Lernstufe ergibt, ist das Beibehalten einer bestimmten Sichtweise, ohne unnat¨

urliche Er-

eignisse einzubeziehen. Hieraus ergibt sich der so genannte “Tunnelblick”. Tabelle 2.2 zeigt

die einzelnen Attribute jeder Lernstufe (Tabelle aus [Baumgartner99], Seite 85).

2.2. LERNTHEORIE 15

Stufe Lernelemente Perspektive Entschei-

dung

Einstellung Gefahr

Anf¨

angertum Fakten und kontextfreie

Regeln

keine keine, passive

Rezeption

distanziert ¨

Ubergene-

ralisierung

Fortgeschritten Anwendung von

Fakten/kontextfreien

Regeln in Situationen;

sammeln Erfahrungen

keine Nachahmung

und Imitati-

distanziert ¨

Ubergeneralisierung

einzelner Erfahrun-

gen bzw. gelernter

Regeln

Kompetenz Anwendung von Fakten

und kontextfreien Regeln;

Einbeziehung eigener

Erfahrungen

bewusst

gew¨

ahlt

analytisch distanziertes

Verstehen u.

Entscheiden; an

Ergebnissen

gef¨

uhlsm¨

aßig

beteiligt

Ubersch¨

atzung eige-

ner F¨

ahigkeiten, er-

h¨

ohte Unfallgefahr

Gwandtheit Gestaltwahrnehmung,

holistisches Erkennen von

Ahnlichkeiten

implizit

durch

Erfahrung

vorhanden

analytisch teilnehmendes

Verstehen;

distanziertes

Entscheiden

Tunnelperspektive

Expertentum Gestaltwahrnehmung,

holistisches Erkennen von

Ahnlichkeiten

implizit

durch

Erfahrungen

vorhanden,

im K¨

orper

integriert

intuitiv gef¨

uhlsm¨

aßig be-

teiligt, pers¨

onliche

Verantwortung

Tunnelperspektive

Tabelle 2.2: Fertigkeitsstufen

16 KAPITEL 2. GRUNDLAGEN

2.2.2 Lernparadigmen

Nachdem die Fertigkeitsstufen des Lernens beschrieben wurden, soll nun der Frage nach-

gegangen werden, wie der Lernende von einer Lernstufe zur n¨

achsten gelangt, bzw. wie

der menschliche Lernprozess funktioniert. Hierzu werden im Folgenden die wichtigsten

Lernparadigmen betrachtet. Eine Zusammenstellung ihrer Thesen findet sich in Werken

von Baumgartner, Schulmeister, Thissen und Kerres [Baumgartner97,Baumgartner99,

Kerres98,Schulmeister81,Thissen97,Thissen99a,Thissen99b].

Behaviorismus

Der Behaviorismus beschreibt die Theorie des Lernens durch Verst¨

arkung. Der Begr¨

under

dieser Theorie war Iwan Petrowitsch Pawlow, der der ¨

Uberzeugung war, dass Verhalten auf

Reaktion beruht und nannte dieses Prinzip Konditionierung. Er bemerkte eher zuf¨

allig,

dass seine Versuchshunde bereits bei dem Klingelsignal zur F¨

utterung Speichel abson-

derten ohne das Futter zu sehen. Aus diesem Versuch schloss er, dass die Hunde einen

Zusammenhang zwischen dem Signal und der F¨

utterung erlernt hatten. Johan B. Watson

hat diese Reiz-Reaktions-Steuerung auf den Menschen ¨

uberf¨

uhrt und vertrat die Annahme,

dass jedes Verhalten konditionierbar ist. Skinner erweiterte diese Theorie um das operan-

te Konditionieren, das besagt, dass das Verhalten von Menschen durch Belohnung und

Bestrafung beeinflusst werden kann (vgl. [Skinner78], Seite 9-11). Dabei “steht das Ver-

halten in Verbindung mit den Ereignissen, die ihm nachfolgen. Verhalten hat bestimmte

Konsequenzen und diese entscheiden ¨

uber das zuk¨

unftige Auftreten ([Edelmann96], Seite

110).”

Nach Baumgartner wird der innerhalb einer Person stattfindende Lernprozess von au-

ßen konditioniert. Lehrende kennen zu jedem Zeitpunkt den zu vermittelnden Stoff und

entscheiden, was Lernende zu erlernen haben. Das Gehirn wird als Blackbox betrachtet,

deren interne Vorg¨

ange nicht interessieren. In dieser Lerntheorie wird davon ausgegan-

gen, dass das menschliche Gehirn nur auf eine geeignete Art und Weise gereizt werden

muss, um eine gew¨

unschte Reaktion auszul¨

osen. (vgl. Abbildung 2.2). Durch entsprechen-

des Feedback k¨

onnen Lehrende auf den Lernprozess eingehen und bestimmte Fertigkeiten

verst¨

arken oder verringern. Das Feedback kann sowohl positiv als auch negativ sein. Durch

eine negative R¨

uckmeldung oder durch Ignorieren des Verhaltens kann Verhalten langfri-

stig vom Lernenden reduziert werde, wo hingegen eine positive Bewertung des Verhaltens

- diese sollte sich jedoch im Rahmen bewegen - eine Verst¨

arkung hervorruft. Ein großer

Nachteil des Behaviorismus ist, dass der Verhalten-Feedback-Prozess nicht die geistigen

F¨

ahigkeiten des lernenden Menschen erfassen kann. Nur f¨

ur solche Fertigkeiten, die sich

auf k¨

orperliche Eigenschaften beschr¨

anken, lassen sich Fortschritte erzielen. Ein Beispiel

f¨

ur den sinnvollen Einsatz dieses Paradigmas sind ¨

Ubungsaufgaben f¨

ur Maschinenschrei-

ber oder Klavierspieler. Im E-Learning-Kontext basierten die ersten computergest¨

utzen

Lernprogramme (CBT) (vgl. Abschnitt 2.1.2) auf diesem Paradigma. Hierbei handelte es

sich um einfache Wissensfragen mit anschließender Erfolgskontrolle.

2.2. LERNTHEORIE 17

Kognitivismus

Der Kognitivismus (Lernen durch Einsicht) stellt im Gegensatz zum Behaviorismus interne

Verarbeitungsprozesse des Lernenden in den Vordergrund. Es werden die internen - also

im Gehirn - ablaufenden komplexen Prozesse untersucht, jedoch nicht das Verhalten der

Lernenden (vgl. Abbildung 2.2). Folglich stehen nicht die Stimuli als Reaktion auf bestim-

mte Verhaltensmuster im Vordergrund, sondern das Lernen von Methoden und Verfahren

zur Probleml¨

osung, um zu einem sp¨

ateren Zeitpunkt zu den richtigen Antworten zu ge-

langen. Hierbei werden eingehende Informationen (bottom-up) mit bereits vorhandenen

Erfahrungen (top-down) einer Person gepaart. Neue Informationen werden also immer auf

Basis von vorhandenen Wissen interpretiert und verstanden. Als Beispiel f¨

ur den Kogniti-

vismus im Bereich von Softwaresystemen kann ein Programm betrachtet werden, welches

dem Anf¨

anger bzw. der Anf¨

angerin, mit Hilfe einer tutoriellen Unterst¨

utzung, den Lehr-

stoff anhand von Beispielen veranschaulicht. Durch den Einsatz von Animationen und

Begriffserkl¨

arungen kann das Wissen dem Lernenden illustrativ demonstriert werden. Tre-

ten Fragen zu der Thematik oder zu den gestellten Aufgaben auf, kann ein ’virtueller’

Tutor konsultiert werden.

Konstruktivismus

Die wesentliche Eigenschaft des Konstruktivismus ist es, das Lernen als aktiven Prozess

anzusehen. Fragestellungen sollen vom Lernenden durch Konstruktion verstanden wer-

den. Hierbei stehen im Gegensatz zum Kognitivismus nicht die Probleml¨

osungen im Vor-

dergrund, sondern vielmehr das mit dem Konstruktionsprozess einhergehende Erzeugen

neuer Probleme und Fragestellungen. Beim Konstruktivismus stellt sich der Lernprozess

durch das Einbringen eigener Erfahrungen, Explorationsergebnisse, Fehlentscheidungen so-

wie durch das Entdecken von Zusammenh¨

angen ein. Abbildung 2.2 zeigt schematisch die

drei Lernparadigmen mit den auf den menschlichen Organismus einwirkenden externen

Reizen. Der Konstruktivismus ist hierbei ein weitestgehend geschlossenes System, welches

lediglich multimodal energetische Stimuli von ’außen’ aufnimmt. Das bedeutet, dass es

keinen informationellen Input und Ouput mit der Umwelt gibt. Der Organismus erzeugt

selbst¨

andig Informationen, die im Lernprozess verarbeitet werden. Lernsysteme, die auf

dem konstruktivistischem Paradigma basieren, besitzen eine explorative Umgebung, in

der Lernende, durch praktisches Konstruieren, Erkenntnisse und Erfahrungen sammeln

k¨

onnen.

2.2.3 Ein Heuristisches Lernmodell

Das Heuristische Lernmodell dient der lerntheoretischen Kategorisierung von Lehrinhalten,

Lernszenarien und Lernformen. Es wird ein W¨

urfel zur r¨

aumlichen Darstellung verwendet,

um monokausale und hierarchische Zusammenh¨

ange zu ¨

uberwinden. Das W¨

urfelmodell

erm¨

oglicht, je nach Fragestellung und Blickwinkel auf den W¨

urfel, die Ansicht einer der

drei Kategorien Handlungsebene,Lehr-/ Lernebene und Ebene der sozialen Organisation.

Bedingt durch die dreidimensionale Darstellung wirken die anderen Kategorien auf die

18 KAPITEL 2. GRUNDLAGEN

Input

Output Output

Black−Box

externes Feedback

intervenierende

Variable

modelliertes

Feedback

interessieren zirkuläres System

selbstreferentielles,

interne

Verarbeitungsprozesse

informationell

geschlossen

offen

energetisch

strukturelle

Koppelung

Behaviorismus Kognitivismus Konstruktivismus

Gehirn ist

Abbildung 2.2: Lernparadigmen (Quelle: [Baumgartner97], Seite 5)

fokussierte ein. Außerdem unterst¨

utzt das Modell die Konkretisierung von Fragestellun-

gen, die bei der Gestaltung von Aus- und Weiterbildungen auftreten. Hierbei geht es z.

B. um folgende Frage: Welche Fertigkeitsstufe soll auf welcher Stufe der Handlungsf¨

ahig-

keit mit welcher Lernform erworben werden? Abbildung 2.3 zeigt das von Baumgartner

[Baumgartner97,Baumgartner99] beschriebene heuristische Lernmodell.

2.3 Standardisierung im E-Learning

Bereits in der Vergangenheit hat sich gezeigt, dass Standardisierungsinitiativen durch Or-

ganisationen und Gremien, wie z. B. die Deutsche Industrie Norm (DIN), das Institute

of Electrical and Electronics Engineers (IEEE) sowie die International Organization for

Standardization (ISO), Einzug in s¨

amtliche Anwendungsdom¨

anen gehalten haben. Eine

Standardisierung erm¨

oglicht es Anbietern eigene Produkte mit denen anderer Anbieter zu

kombinieren. Hierdurch sind Hersteller in der Lage, sich auf die Produktion ausgew¨

ahlter

Teile zu spezialisieren, so dass fehlende Teile von Drittanbietern bezogen werden k¨

onnen.

Zudem unterst¨

utzen Standards die Entwicklung von Produkten dahingehend, dass sie das

Risiko und die Kosten, die w¨

ahrend der Entwicklungszeit anfallen, erheblich reduzieren.

In [Wilson99] wird hierzu ein life-cycle Modell illustriert. ¨

Außerst n¨

utzliche Standardi-

sierungen sind z. B. elektrische Stecker und das OSI-Referenzmodell f¨

ur Netzwerkproto-

kolle. Sogar Kinder profitieren von Standardisierungen, wie es z. B. bei Lego Bausteinen

der Fall ist. Diese lassen sich von Kindern aller Altersstufen zusammensetzen und aus-

einander bauen, ungeachtet von ihrer Farbe und ihrer Form. In der E-Learning-Dom¨

ane

werden neben zahlreichen Online-Lernangeboten eine Vielzahl an Learning Management

Systemen (LMS)1entwickelt, wodurch eine Standardisierung unumg¨

anglich ist. Entwickel-

te Lerneinheiten sollen unabh¨

angig von Lernplattformen konzipiert und vertrieben werden.

1Learning Management Systeme (LMS) bzw. Lernplattformen werden detailliert in Kapitel 3.3 vorge-

stellt. Eine Begriffsdefinition befindet sich im Glossar (vgl. Anhang B)

2.3. STANDARDISIERUNG IM E-LEARNING 19

Abbildung 2.3: Ein Heuristisches Lehr- und Lernmodell (Quelle: [Baumgartner97], Seite

Damit eine nahtlose Integration solcher Materialien funktioniert, sind Organisationen und

Gremien f¨

ur Standardisierung mit folgenden Fragestellungen besch¨

aftigt: “Wie lassen sich

Lehrinhalte einfach und sinnvoll kombinieren?”, “Wie k¨

onnen Lernmaterialien, basierend

auf unterschiedlichen Formaten, zusammenwirken?” und“Wie ist sicherzustellen, dass ent-

wickelte Lehrinhalte mit Lernplattformen anderer Anbieter kompatibel sind?”. Dar¨

uber

hinaus werden auch technische Fragen diskutiert, wie z. B. die Definition von Metadaten

oder Lernobjekte2. Im folgenden werden die wichtigsten und einflussreichsten Organisa-

tionen vorgestellt und deren Abh¨

angigkeiten dargelegt:

•ADL Advanced Distributed Learning Initiative (vgl. Abschnitt 2.3.1)

•IMS Instructional Management Systems Project (vgl. Sbschnitt 2.3.2)

•IEEE LTSC IEEE Learning Technology Standard Committee (vgl. Sbschnitt 2.3.3)

•ARIADNE Aliance of Remote Instructional Authoring and Distibution Networks

for Europe (vgl. Abschnitt 2.3.5)

2Die Begriffe Metadaten und Lernobjekte werden erst in den Abschnitten 2.3.3 und 2.4 eingef¨

uhrt. Eine

kurze Begrifssdefinition ist im Glossar (vgl. Anhang B) zu finden.

20 KAPITEL 2. GRUNDLAGEN

•AICC Aviation Industry Computer Based Training Committee (vgl. Abschnitt

2.3.4)

W3C

ANSI

ARIADNE

IMSADL (SCORM)AICC

IEEE LTSC

Liefert Spezifikationen

stellt

Anforderungen Anforderungen

stellt

Initiativen durch Standardisierung

Beinflusst Spezifikationen der einzelnen

ISO

Internationaler Standard

Nationaler Standard

kooperiert

Abbildung 2.4: Kooperation internationaler Standardisierungsgremien und -

Organisationen

Die vier Konsortien AICC, ADL, IMS und ARIADNE haben zu Beginn ihrer Arbeit

damit angefangen, Standardisierungsvorschl¨

age f¨

ur die Dom¨

ane E-Learning zu erarbeiten.

Es hat sich jedoch herausgestellt, dass Arbeitsergebnisse ausgetauscht und konsolidiert

werden k¨

onnen. Diese Bem¨

uhungen sind unter anderen dadurch entstanden, weil nur das

IEEE das Recht besitzt, Spezifikationen f¨

ur die Etablierung eines Standards bei den re-

levanten Organisationen wie z. B. dem ANSI (Amercan National Standards Institute)

einzureichen [Baumgartner02]. Abbildung 2.4 veranschaulicht diese Zusammenh¨

ange.

2.3.1 ADL (SCORM)

Die Advanced Distributed Learning (ADL) Initiative wurde 1997 vom amerikanischen Ver-

teidigungsministerium Department of Defense (DoD) gegr¨

undet, um Standardisierungen

im Bereich E-Learning zu entwickeln, die potenzielle Kooperationen zwischen den Vor-

haben der Wirtschaft, Wissenschaft und Regierung erm¨

oglichen und erleichtern. Hierbei

wurden vor allem die Themen Wiederverwendbarkeit, Langlebigkeit und Zug¨

anglichkeit

fokussiert. Als Resultat hat die ADL Initiative im Fr¨

uhjahr 1999 damit begonnen, Spe-

zifikationen und Standardisierungen anderer Organisationen im E-Learning-Sektor aufzu-

greifen, und zu einem generellen Referenzmodell, dem Sharable Content Object Reference

Model (SCORM) [ADL04] zusammenzuf¨

uhren. Die erste ¨

offentlich zug¨

angliche Version

2.3. STANDARDISIERUNG IM E-LEARNING 21

0.7.3 des SCORM-Referenzmodells wurde Mitte 1999 verabschiedet und bis zur Version

2004 weiterentwickelt. Das SCORM-Referenzmodell fast im Wesentlichen zwei Standards

f¨

ur Lernobjekte zusammen: das Content Aggregation Model und das Run-Time Environ-

ment. Das Content Aggregation Model spezifiziert die Struktur von Lernobjekten, damit

sie aus Sicht der Anbieter von Lehrinhalten integrierbar, wiederverwendbar und zugreifbar

sind. Dagegen erm¨

oglicht das Run-Time Environment die Auswertung von Lernobjekten

und die Kommunikation mit Lernplattformen (vgl. Kapitel 3.3).

Content Aggregation Model

Das Content Aggregation Model definiert durch Mechanismen zur Entwicklung von Ele-

mentarteilen einen Rahmen f¨

ur die Erstellung und den Vertrieb von Lehrinhalten. Das

Elementarteil – genannt Asset – ist ein Sammelbegriff f¨

ur s¨

amtliche Dateien, die zu einer

Lerneinheit geh¨

oren, wie z. B. Java Applets, Texte, Bilder oder auch Videos. Sie werden

aggregiert und zu h¨

oheren, komplexeren Lerneinheiten zusammengefasst. Hierbei definiert

der Standard drei wesentliche Aspekte: das Content Model, die Metadaten und das Con-

tent Packaging. Das Content Model ist eine Nomenklatur zur Definition der Komponenten,

durch die eine Lerneinheit aufgebaut ist. Dazu geh¨

oren die bereits erw¨

ahnten Assets, die

Sharable Content Objects (SCOs) sowie deren Aggregation. SCOs sind eine sinnvolle und

inhaltlich abgeschlossene Komposition von Assets, die als eigenst¨

andige Lernmodule in

ein Learning Management System (LMS) (vgl. Abschnitt 3.3) geladen werden und mit

diesem kommunizieren k¨

onnen. Hierbei ist die Festlegung ihrer Granularit¨

at ¨

außerst wich-

tig. SCOs m¨

ussen kontextuell abgeschlossen sein, so dass sie nicht auf andere Lernmodule

verweisen oder gar von ihnen abh¨

angig sind. Dar¨

uber hinaus enth¨

alt ein SCO – wenn

es die Kommunikation zu einem LMS aufbauen soll – ein spezielles Asset, welches die

Kommunikations-API kapselt. Die Kommunikations-API wird durch JAVA-Skript-Befehle

aufgerufen, die direkt in der Einstiegsseite des SCOs verankert sind, und baut so die Ver-

bindung zum LMS (vgl. Abschnitt 3.3) auf. Im Minimalfall wird die Auswertungsinstanz

des LMS mit dem Aufruf LMSInitialise initialisiert und mit LMSFinish abgeschlossen.

Sind SCOs und Assets definiert, k¨

onnen sie auf unterschiedliche Weise organisiert werden,

so dass der Kursinhalt Lernenden mit unterschiedlichen Lernpfaden pr¨

asentiert werden

kann. Dieser Vorgang wird als Content Aggregation bezeichnet. Ein Beispiel f¨

ur unter-

schiedlich organisierte Inhalte ist die Bereitstellung verschiedener komplexer Lehrinhalte

f¨

ur entsprechend geeignete Fertigkeitsstufen (vgl. Abschnitt 2.2.1). Ein Kurs f¨

ur Anf¨

anger

bzw. Anf¨

angerinnen wird beispielsweise Grundlagen und Regeln enthalten, die f¨

ur einen

kompetenten Lernenden uninteressant sind und deshalb nicht in der Organisationsstruktur

des Kurses vorkommen. Abbildung 2.53zeigt schematisch die Struktur bzw. die Organisa-

tion von Assets und SCOs. Die Knotenpunkte der Organisationen werden Items genannt

und verweisen auf genau eine Ressource. Ressourcen wiederum sind eine Liste eines oder

mehrerer Assets bzw. SCOs. Sie gruppieren semantisch abh¨

angige Dateien.

Der im SCORM-Standard verwendete Metadaten-Ansatz wurde aus der IEEE LTSC

3Quelle: ADL, Sharable Content Object Referenz Model (SCORM) Version 2004,

http://www.adlnet.org (29.10.2005) [ADL04]

22 KAPITEL 2. GRUNDLAGEN

Abbildung 2.5: Beispiel: Organisation

Learning Object Metadata (LOM) Spezifikation ¨

ubernommen und im Content Aggrega-

tion Model (CAM) eingebunden. Metadaten k¨

onnen unterschiedlichen Komponenten des

Modells zugeordnet werden. Sie gehen mit dem Content Aggregation Model einher und

spezifizieren Daten zur Klassifizierung von Kursstrukturen. Dar¨

uber hinaus k¨

onnen sie

auch SCOs zugeordnet werden. Sie sind dann wichtig, wenn Lernende Informationen zu

einer Lerneinheit erhalten m¨

ochten, wie z. B. den Schwierigkeitsgrad oder das Lernziel.

In manchen F¨

allen scheint es sogar sinnvoll zu sein, Assets, wie z. B. Video-Dateien, mit

Metadaten auszustatten. Der Standard sieht f¨

ur jenen Fall die direkte Behaftung von Me-

tadaten an Assets vor. An dieser Stelle ist anzumerken, dass es ebenso Standardisierungen

f¨

ur Assets gibt, wie sie z. B. das Videoformat MPEG-7 anbietet, die beschreiben, in welcher

Weise auf Metadaten innerhalb digitaler Formate zugegriffen wird [Klamma03]. Allgemein

formuliert helfen Metadaten Anwendern und Anwenderinnen bei der Suche von Kursen

bzw. deren Fragmenten in so genannten Repositories (vgl. Abschnitt 2.3.2) mit der Ab-

sicht, Lehrinhalte durchzuarbeiten oder sie in h¨

ohere selbstdefinierte Strukturen gezielt

einzuordnen.

Abschließend wird betrachtet, wie ein Content Package physikalisch organisiert ist.

Hierzu f¨

uhrt der SCORM-Standard das Package Interchange File (PIF) ein. Es be-

steht physikalisch aus einer Manifest-Datei und beliebig vielen kursrelevanten Assets. Die

Manifest-Datei, welche in XML (vgl. Abschnitt 3.2.1) definiert wird, enth¨

alt die bereits

oben beschriebenen Komponenten Meta-Daten, Organisationen, Ressourcen und Manife-

2.3. STANDARDISIERUNG IM E-LEARNING 23

ste4. Die folgende Abbildung 2.65zeigt grafisch den Aufbau eines Content Packages.

Abbildung 2.6: Beispiel: Content Package

Das Konzept der PIF-Datei wurde einerseits zum Datenaustausch zwischen verschiede-

nen standardkompatiblen LMS entwickelt und andererseits, um direkt auf Kurse zuzugrei-

fen, die beispielsweise auf einer CD-ROM abgelegt sind. F¨

ur den Fall der Kursinstallation

in einem LMS bietet sich der Einsatz komprimierter Archive geradezu an. Alle Kursdatei-

en, einschließlich der Assets und Manifest-Datei, werden zu einer komprimierten PIF-Datei

zusammengefasst, die sich dadurch wesentlich einfacher handhaben l¨

asst. Der Vorteil liegt

auf der Hand: Sollen Kurse, bestehend aus einer großen Anzahl von Bild-, Audio- oder

Textdateien, in ein LMS geladen werden, muss jede Datei sukzessiv in das System einge-

stellt werden. Genau diese Unterteilung wird jedoch ben¨

otigt, damit die Kursinhalte durch

einen Browser im Dateisystem ge¨

offnet werden k¨

onnen. Des weiteren hat das Canadian

Department of National of Defence eine Erweiterung des SCORM-Standards eingebracht,

die sich mit der Darstellung der Kursstruktur befasst [National Defence02].

Runtime Environment

Das Konzept der im SCORM-Standard 1.2 vorgestellten Laufzeitumgebung (Runtime En-

vironment) erm¨

oglicht grunds¨

atzlich die Kommunikation zwischen Lernumgebungen und

den dort eingeladenen Lerneinheiten. Die ausschließlich statischen Inhalte (SCOs und As-

4An dieser Stelle ist anzumerken, dass Manifeste innerhalb anderer Manifeste rekursiv verschachtelt

werden k¨

onnen.

5Quelle: ADL, Sharable Content Object Referenz Model (SCORM) Version 2004, www.adlnet.org

(29.10.2005) [ADL04]

24 KAPITEL 2. GRUNDLAGEN

sets) werden in Kombination mit einem standardkonformen LMS eingelesen und gestartet

(Launch). So kann das LMS durch die stattfindende Dynamisierung Benutzerinformationen

bzw. Lernfortschritte statistisch protokollieren und auswerten. Kernst¨

uck der Kommunika-

tion ist ein in das Lernmodul eingebetteter API-Adapter, der als Bindeglied zwischen LMS

Server und SCO fungiert. ¨

Uber ihn werden bidirektional Daten, z. B. der Initialisierungs-

aufruf oder Fehlermeldungen, vom SCO zum LMS geschickt. F¨

ur den Datenaustausch

existiert das sogenannte Data Model. Mit diesem Modell werden laufzeitbezogene Daten,

wie z. B. die Bearbeitungszeit oder der aktuelle bzw. maximal zu erreichende Punktestand,

ubertragen. Abbildung 2.76zeigt grafisch den Zusammenhang zwischen LMS-Server, API-

Adapter und SCO.

Abbildung 2.7: SCORM Laufzeitumgebung

6Quelle: ADL, Sharable Content Object Referenz Model (SCORM) Version 2004, www.adlnet.org

(29.10.2005) [ADL04]

2.3. STANDARDISIERUNG IM E-LEARNING 25

2.3.2 IMS

Das Instructinal Management Systems Project (IMS) [IMS05b] ist aus der National Lear-

ning Infrastructure Initiative der EDUCAUSE entstanden und befasst sich seit 1997 mit

unterschiedlichen Fragestellungen aus dem Bereich verteilter Lerntechnologien. Hierzu z¨

ah-

len nicht nur Systeme oder Inhalte, die an institutionellen Einrichtungen, wie z.B Schulen

oder Hochschulen, eingesetzt werden, sondern auch solche, die in Heimarbeit am priva-

ten Computer einsetzbar sind. Das IMS hat sich mit dieser Frage eingehend besch¨

aftigt

und eine Reihe wichtiger de facto Standards durchgesetzt, die den Umgang mit statischen

und dynamischen Inhalten sowie asynchronen und synchronen Lernszenarien spezifizieren.

Hierzu geh¨

ort die IMS Metadaten Specification [IMS03d], die im ¨

Ubrigen auch in den

LOM Standard (vgl. Abschnitt 2.3.3) aufgenommen wurde und Lernenden das Auffinden

von Materialien erm¨

oglicht, gleichg¨

ultig, ob sie auf einer DVD gespeichert wurden oder im

Internet zur Verf¨

ugung stehen. Zudem wird ein Austauschformat, basierend auf der IMS

Content Package Specification [IMS03a] entwickelt, das den Austausch von Lernmateriali-

en zwischen standardkompatiblen Lernplattformen und Autorensystemen erm¨

oglicht. Das

IMS Content Package wird in seinen Grundz¨

ugen in Abschnitt 2.3.1 beschrieben, und soll

an dieser Stelle nicht weiter vertieft werden.

Zudem hat das IMS ein Datenformat spezifiziert (IMS Question and Test Interoperabi-

lity Specification [IMS05a]), mit dem es m¨

oglich ist, Quiz-Elemente zwischen Anwendun-

gen auszutauschen. Sie wird haupts¨

achlich zur Definition von Test- und Quizumgebungen

verwendet, die dann von einem LMS ausgewertet und ausgef¨

uhrt werden k¨

onnen. Au-

torensysteme oder Quizeditoren k¨

onnen mit Hilfe dieses Standards die intern verwendete

Datenstruktur auf eine XML-Instanz abbilden. Die IMS-QTI Spezifikation wurde im M¨

arz

2000 verabschiedet und spezifiziert die drei Grundelemente Item,Section und Assessment.

•Ein Item ist eine elementar austauschbare Frage, die zus¨

atzlich Instruktionen, wie

Darstellungen, Antworten, Hinweise und Metadaten, mit einschließt.

•Das Assessment Element beschreibt eine Sequenz von Item-Elementen, die, je nach

dem Wissen des Kandidaten, angepasst werden kann. Dar¨

uber hinaus existieren In-

struktionen zur Auswertung der vom Lernenden bearbeiteten Fragen mit dem Re-

sultat einer globalen Punktewertung.

•Das Section-Element erm¨

oglicht die hierarchische Anordnung von Fragen. Dieses

ist z. B. gew¨

unscht, wenn Fragestellungen an die Struktur der Themenbeschreibung

angeglichen werden sollen. Zudem lassen sich mit Hierarchien unterschiedliche Fra-

gesequenzen erzeugen.

Zus¨

atzlich zur IMS Content Package Spezifikation und den IMS Metadaten wurde die

IMS Digital Repositories Interoperability Spezifikation (DRI) zur Schnittstellenbeschrei-

bung digitaler Repositories [IMS03b] verabschiedet. Diese Spezifikation verwendet mehrere

Spezifikationen, unter anderen das IMS Content Packaging und die IMS Metdaten, mit

dem Ziel, eine einheitliche Schnittstelle f¨

ur die Verwaltung von Ressourcen zu definieren.

Hierbei k¨

onnen beliebige Ressourcen unter Ber¨

ucksichtigung festgelegter Regeln in das

26 KAPITEL 2. GRUNDLAGEN

Repository eingepflegt und wiedergefunden werden. F¨

ur den Zugriff auf ein Repository

spezifiziert das IMS die folgenden Kernfunktionen:

•Search/Expose

•Gather/Expose

•Submit/Store

•Request/Deliver

•(Alert/Expose)

Abbildung 2.8 veranschaulicht den Zusammenhang zwischen den Rollen, Kernfunktio-

nen und Diensten.

Abbildung 2.8: IMS Digital Repository

2.3. STANDARDISIERUNG IM E-LEARNING 27

Durch die festgelegten Kernfunktionen ist es f¨

ur unterschiedliche Anwendungen, wie

z. B. Learning Content Management Systeme (LCMS)(vgl. Abschnitt 3.3), Learning Ma-

nagement Systeme (LMS) oder Portale, m¨

oglich, auf Repositories zuzugreifen. Zus¨

atzlich

wird von der einzusetzenden Repsoitory-Implementierung und somit von dem technischen

Konzept abstrahiert, welches sich hinter ihnen verbirgt. Beispielsweise kann so der her-

k¨

ommliche Repoitory Standard Z39.50 mit XML-Respoitories vernetzt werden. F¨

ur den

Zugriff auf XML-Datenbanken wird f¨

ur die Suchoperation Search vom IMS eine XQuery

[W3C05c] Empfehlung angegeben, mit dem Metadaten durchsucht werden k¨

onnen. Des

weiteren spezifiziert die DRI den Zugriff auf mehrere Repositories, indem Kernfunktionen

zum Zusammensammeln (Gather) verteilter Metadaten und deren Auswertung angeboten

werden. Das Einstellen neuer Daten in ein Repository findet bei herk¨

ommlichen, nicht

DRI-Repositories, per FTP- oder HTTP-Zugang statt. Werden jedoch DRI-Repositries

eingesetzt, so gibt der Standard ein XML-Binding7vor, das beliebigen Clients den Zugriff

auf SOAP-Webservices [Chappell03,Snell02] erm¨

oglicht, welche als Zugangspunkte f¨

ur die

DRI-Repositories dienen.

2.3.3 IEEE-LTSC (LOM)

Der Learning Object Metadata (LOM) Standard wurde seit 1997 durch das IEEE-Learning

Technology Standards Committee (LTSC) entwickelt, und im Juni 2002 in seiner ersten

Version verabschiedet. Den Grundstein der von der Metadata Working Group verfassten

Spezifikation haben parallel laufende Projekte der ARIADNE [Duval02] und des IMS (vgl.

Kapitel 2.3.2) gelegt. Der LOM Standard beschreibt generell die Semantik und Struktur

von Daten, die Informationen ¨

uber Lernobjekte (Learning Objects) (vgl. Kapitel 2.4) ent-

halten. Gerade aus dieser unidirektionalen Abbildung von Daten auf andere Daten wurde

der Begriff Metadaten abgeleitet. Durch die Verwendung von Metadaten werden folgende

Vorteile erzielt [Saddik01b,Saddik02]:

•Zusammenfassung des Inhalts und der Bedeutung von Lernobjekten,

•Suchen nach speziellen Lernobjekten wird erm¨

oglicht,

•Lernenden die Auswahl von Lernobjekten, die f¨

ur den eigenen Lernfortschritt rele-

vant sind (Sequencing), zu erm¨

oglichen,

•Der Zugriff auf Lernobjekte ist kontrolliert,

•Vermittlung von Informationen ¨

uber Daten, wie z. B. das Format.

Der LOM-Standard vereinfacht die Beschaffung, das Suchen und die Auswertung von

Lernressourcen durch Dritte, d. h. Lernende oder Lehrende. Dar¨

uber hinaus erm¨

oglicht

der auf XML (vgl. Kapitel 3.2.1) basierende Standard eine Auswertung bzw. Bearbei-

tung durch ein technisches System. Diese Anforderungen treten vor allem bei Sammlun-

gen von Lernmodulen in Repositories oder Katalogen auf, bei denen Lernmodule anhand

7Mit dem Begriff Binding wird hier die technische Umsetzung durch eine bestimmte Technologie, wie

in diesem Fall XML bezeichnet.

28 KAPITEL 2. GRUNDLAGEN

verschiedener Kategorien eingeordnet werden. Die LOM-Spezifikation sieht hierf¨

ur neun

Kategorien vor, die in Tabelle 2.3 [Electrical02] aufgef¨

uhrt sind.

Kategorie Erkl¨

arung

General Besitzt generelle Informationen ¨

uber das Lernobjekt.

Lifecycle Dokumentiert den historischen Verlauf sowie den aktuellen Status des

Lernobjekts. Dar¨

uber hinaus werden Lernobjekte ¨

uber den Zeitraum der

Lebensdauer erfasst.

Meta-Metadata Verwaltet Informationen ¨

uber die Metadaten-Instanz.

Technical Beschreibt technische Anforderungen und technische Eigenschaften des

Lernobjekts.

Educational Erfasst die p¨

adagogischen und die f¨

ur die Lehre relevanten Informationen

uber das Lernobjekt.

Rights Verwaltet die f¨

ur das Lernobjekt geltenden Nutzungsbestimmungen so-

wie die Urheberrechte.

Relation Spezifiziert die Beziehung mit anderen Lernobjekten und deren Zusam-

menhang.

Annotation Legt Anmerkungen ¨

uber das Lernobjekt ab. Es wird das Lernszenario

beschrieben und das Erstellungsdatum der Anmerkung.

Classification Einordnung des Lernobjekts in ein Klassifizierungssystem.

Tabelle 2.3: Neun Kategorien f¨

ur Lernobjekte nach der Learning Object Metadata Spezi-

fikation (LOM)

Als Beispiel f¨

ur die Umsetzung des Standards stellt Shen [Shen02] das webbasier-

te Learning Resource Metadata Management System (LRMMS) vor, welches als System

bestehend aus untereinander kooperierenden Servern ein dezentrales Rahmenwerk pr¨

asen-

tiert, mit dem Lernende Inhalte publizieren, verwalten und recherchieren k¨

onnen. Ebenso

wurde im ARIADNE Projekt (vgl. Abschnitt 2.3.5) das Knowledge Pool System (KPS)

entwickelt, das nicht nur den LOM-Standard umsetzt, sondern ihn zus¨

atzlich um lernp¨

ad-

agogische Eigenschaften erweitert.

2.3.4 AICC

Das Aviation Industry Computer-Based Training Committee (AICC) [AIC03] ist eine inter-

national operierende Vereinigung und wurde 1988 mit dem Ziel gegr¨

undet, Vorschl¨

age f¨

die Entwicklung, Bewertung und den Vertrieb von computerunterst¨

utzten Lern- und Trai-

ningseinheiten zu erarbeiten. Der AICC Standard erm¨

oglicht die von einem Learning Ma-

nagement System (LMS) unabh¨

angige Entwicklung von Lerneinheiten und bietet Firmen

langfristig Investitionssicherheit, weil durch die Einhaltung des Standards Lerneinheiten

(Computer Based Training (CBT)) mit Lernplattformen (Computer Manage Instruction

Systems (CMI)) verschiedener Anbieter lauff¨

ahig sind. Der CMI-Standard verwaltet aber

nicht nur Kursinhalte, sondern auch Studierende. Lehrende k¨

onnen Studierenden Inhalte

zur Verf¨

ugung stellen und den Lernfortschritt der Studierenden auswerten. Grunds¨

atzlich

2.3. STANDARDISIERUNG IM E-LEARNING 29

gibt es in einem CMI-System [Bergstrom01] f¨

unf Komponenten, die durch den Standard

spezifiziert werden:

•Die Kursstruktur, aufgeteilt in courses,blocks und lessons, die hierarchisch ange-

ordnet werden k¨

onnen,

•eine Komponente f¨

ur Tests,

•eine Verwaltungskomponente f¨

ur Studierende, die sowohl die Registrierung als

auch demographische Erhebungen vorsieht,

•eine Betreuungskomponente f¨

ur Studierende, die Aufgaben Studierenden zuweist

und deren Lernfortschritt ¨

uberwacht,

•die Datenverwaltung, die Lehrenden und Entwicklern das Auffinden und das Ver-

walten von Kursinhalten erleichtert.

Ein wichtiger Aspekt, der durch den AICC CMI-Standard beleuchtet wird, behan-

delt die Frage, wie Kurse unter verschiedenen CMI-Systemen ausgetauscht werden k¨

onnen

und wie Kurse, die von Drittanbietern entwickelt wurden, in das eigene CMI eingebunden

werden k¨

onnen. Zur Kl¨

arung dieser Frage untersucht der Standard drei Aspekte der Inte-

roperabilit¨

at: Die ¨

Ubertragbarkeit von Kursstrukturen, Verhalten und Inhalt auf andere

Systeme, die Kommunikation zwischen Kursen und dem CMI-System sowie das Abspei-

chern bzw. das Verwalten von Informationen ¨

uber Studierende. Im Zuge der weiteren

Analyse des Standards steht vor allem der Kurs als modulare Lerneinheit im Mittelpunkt

des Interesses, der wie folgt definiert wird:

”A course may be as simple as a few lessons to be viewed sequentially, or

it may be as complex as hundreds of lessons, some of which are prerequisites

to others and some of which may be experienced in any order. Basically, cour-

ses have three components: instructional elements, structure, and behavioral

elements ([Bergstrom01], Seite 45)”.

Der Leitgedanke, der hier verfolgt wird, ist die Aufteilung von Kursen in kleine Ein-

heiten, wie Lessons oder Tests, die ungeachtet von ihrer Reihenfolge definiert werden.

Eine separate Struktur legt fest, ob und wie einzelne Kurselemente strukturell angeordnet

und eingesetzt werden und h¨

angt von der Expertise des Lernenden ab. Abh¨

angig vom

Vorwissen des Studierenden kann die Kursstruktur eher einfach oder sehr viel komplexer

konsumiert werden. Diese Struktur hilft ebenso bei der ¨

Uberf¨

uhrung von Kursinhalten

auf andere Systeme, weil hiermit einzelne Kurseinheiten nicht m¨

uhevoll von Hand kopiert

werden m¨

ussen. Abbildung 2.9 zeigt exemplarisch eine vom Kurs separierte Struktur, die

mit mehreren Kurseinheiten assoziiert ist.

30 KAPITEL 2. GRUNDLAGEN

Structure Content

Lesson 1

Lesson 2

Lesson 3

Lesson 4

Test 1

Intro

Abbildung 2.9: Variable Kursstruktur f¨

ur Lernmodule zum leichten Transfer von einem

CMI-System auf ein anderes System.

2.3.5 ARIADNE

Die Aliance of Remote Instructional Authoring and Distibution Networks for Europe (ARI-

ADNE) [Ari05] ist ein EU-Projekt im 4. Rahmenprogramm und wurde mit der Zielsetzung

gegr¨

undet, Werkzeuge und Methoden zur Produktion, Verwaltung und Wiederverwendung

von rechnergest¨

utzten und p¨

adagogischen Lerneinheiten sowie f¨

ur die Erstellung von Cur-

riculae zu entwickeln. Hierbei wird nicht nur der technische Rahmen definiert, sondern

auch kulturelle und sprachliche Aspekte bei der Entwicklung ber¨

ucksichtigt. Insbesondere

soll die Indexierung, wie z.B die Eingabe von Metadaten, und das Auffinden von p¨

adago-

gischen Inhalten erheblich vereinfacht werden.

Als Ergebnis dieses Vorhabens pr¨

asentiert ARIADNE die Erg¨

anzung der im LOM-

Standard fehlenden Einstellungen zu p¨

adagogischen Merkmalen sowie die Entwicklung des

international vernetzten Knowledge Pools (KPS), der als Referenzimplementierung f¨

die am LOM-Standard neu eingebrachten Vorschl¨

age dient. Die entstandene Spezifikation

ist ein Klassifizierungs-Schema, das aus sechs Kategorien besteht:

•generelle Informationen ¨

uber Ressourcen,

•Semantik der Ressourcen,

•p¨

adagogische Attribute,

•technische Charakterisierung,

•Nutzungsbedingungen,

2.4. LERNOBJEKTE (LEARNING OBJECTS) 31

•Meta-Metadaten.

Das KPS ist als verteiltes Repsoitory f¨

ur Lerneinheiten realisiert, auf das mit von-

einander unabh¨

angigen Werkzeugen zugegriffen wird. Einerseits k¨

onnen Lehrende Inhalte

einstellen und pflegen und andererseits ist es Studierenden m¨

oglich, durch Verwendung von

Werkzeugen zur Indizierung und Suche, Inhalte ¨

uber das Netzwerk verteilter Repositories

zu beschaffen.

2.3.6 Analyse

In den letzten zehn Jahren gab es in den verschiedenen Zweigen des E-Learnings intensive

Bem¨

uhungen, die auf diesem Gebiet erzielten Ergebnisse der Forschungsinstitutionen und

Gruppen, wie dem IMS, durch Standardisierungsorganisationen (ISO oder IEEE) in in-

ternationale Standards umzusetzen. Diese relativ jungen Gruppen haben, im Vergleich zu

anderen Dom¨

anen, den Einzug in internationale Unternehmen noch nicht abgeschlossen. Es

werden voraussichtlich noch Jahre vergehen, bis sich der LOM- und der SCORM-Standard

als unverzichtbar erweisen. Dieses f¨

allt vor allem bei der Betrachtung von Autorensyste-

men (vgl. Abschnitt 3.4) oder Learning Management Systemen (vgl. Abschnitt 3.3) auf,

die bem¨

uht sind, junge Standards als neue Leistungsindikatoren, sowohl aus der Sicht

der Technik als auch aus der des Marketings, anzubieten. Die g¨

angigen Systeme sind je-

doch noch weit von der Akzeptanz durch Endbenutzer und Endbenutzerinnen entfernt.

Im Alltag ist jeder Mensch st¨

andig mit einer Reihe von Standards konfrontiert, ohne es

uberhaupt zu bemerken. So wird beispielsweise von jeder Tankstelle der gleiche Kraftstoff

zum Betanken f¨

ur Kraftfahrzeuge angeboten, unabh¨

angig vom Modell oder Land. Ebenso

k¨

onnen Videoger¨

ate, Fernseher und DVD-Player ¨

uber die gleichen Kabel und Stecker pro-

blemlos verbunden werden. Im E-Learning ist dieser Grad an Integrit¨

at jedoch noch nicht

erreicht. Viele Forschungseinrichtungen und industrielle Institutionen entwickeln proprie-

t¨

are L¨

osungen, die inkompatibel zu existierenden Systemen sind und daher die Akzeptanz

von E-Learning-Standards nicht gerade f¨

ordern [Saddik01a][Bohl02].

2.4 Lernobjekte (Learning Objects)

Bei der Erstellung und Entwicklung von multimedialen Inhalten kommt es h¨

aufig vor, dass

Inhalte f¨

ur eine spezielle Thematik unter hohem Zeit- und Kostenaufwand entwickelt und

getestet werden. Gerade f¨

ur den Hochschulbereich, in dem an zahlreichen Instituten und

Einrichtungen dieselben Grundlagenveranstaltungen durchgef¨

uhrt werden und nahezu der

gleiche Stoff vermittelt wird, ist eine mehrfache Neuentwicklung lernbegleitender Inhalte

ungew¨

unscht. Aus diesem Grund werden im folgenden Ans¨

atze vorgestellt, die Konstruk-

tionsprinzipien f¨

ur Kurse vorstellen, bei denen nicht die Entwicklung monolithischer Kurse

im Vordergrund steht, sondern vielmehr auf die modulare Konstruktion mit Learning Ob-

jects (LO) [Hodgins02,Downes00,Downes04,Heng03,Ignatiadis03,Wiley00a] verwiesen

wird. Lernobjekte werden f¨

ur die Wiederverwendung von Lehrinhalten benutzt. Hierbei ist

es wichtig, den Lehrinhalt derart aufzuteilen, dass modulare Einheiten entstehen, die in an-

32 KAPITEL 2. GRUNDLAGEN

deren Lernmaterialien eingebunden und wiederverwendet werden k¨

onnen. Die Aufteilung

in modulare Lerneinheiten ist in seinen Grundz¨

ugen durch das Paradigma der objekt-

orientierten Programmierung (OOP) [Wiley00b,Balzert00,Z¨

ullighoven98,Rumbaugh91,

Meyer97] motiviert, bei der Software-Komponenten klassifiziert und durch Objekte re-

pr¨

asentiert werden. Ein wichtiger Aspekt bei der Konstruktion von Lernobjekten ist ihre

Abgeschlossenheit. Das bedeutet, dass sie thematisch abgeschlossen sein m¨

ussen und nicht

von anderen Inhalten abh¨

angen. Eine solche Abh¨

angigkeit tritt insbesondere dann auf,

wenn z. B. in einer Aufgabenstellung zu dem Themenkomplex Komplexe Zahlen ein Hin-

weis auf die Definition der zugeh¨

origen Operationen existiert. Deshalb wird grunds¨

atzlich

gefordert, die kleinste sinnvolle Gr¨

oße bei der Entwicklung zu w¨

ahlen.

Learning Objects bestehen in der Regel aus einer Menge von Informationseinheiten

oder Datenobjekten, wie z.B Texte, Videos oder Programmen. Aus ihnen k¨

onnen durch

Aggregation bzw. Komposition unterschiedliche Kurse zusammengestellt werden, die wie-

derum zu kompletten Lehrg¨

angen kombiniert werden k¨

onnen (vgl. Abbildung 2.10, Baum-

gartner [Baumgartner02], Seite 33).

Kurs

Informationseinheit

Lehrgang

RLO (wiederverwendbare Lerneinheit)

Abbildung 2.10: Das modulare Prinzip der Reusable Learning Objects (RLO)

Eine andere Darstellung von Lernobjekten wurde bei der Firma Autodesk eingef¨

uhrt

(vgl. Abbildung 2.11)[Hodgins02]. In dieser f¨

unfstufigen Darstellung werden Informati-

onsobjekte aus atomaren Medienelementen und Assets gebildet. Aus diesen Informations-

objekten lassen sich Lernobjekte bauen, die zu h¨

oheren Lerneinheiten oder kompletten

Kapiteln zusammengesetzt werden. Werden diese ebenso kombiniert, ist das Resultat ein

Kurs oder ein Buch. Je h¨

oher die Aggregationsstufe, desto schwieriger wird die Wieder-

verwendung der erzeugten Inhalte.

Das Learning Technology Standard Commitee (LTSC) (vgl. Abschnitt 2.3.3) hat den

Begriff Learning Objekt wie folgt definiert:

2.4. LERNOBJEKTE (LEARNING OBJECTS) 33

Abbildung 2.11: Modulare Content-Hierarchie

”A learning object is defined as any entry -digital or non-digital that may

be used for learning, education or training.([Electrical02], Seite 5)”

Baumgartner verwendet eine speziellere Begriffsbeschreibung f¨

ur Learning Objects und

definiert zus¨

atzlich den Begriff Reusable Learning Object (RLO):

”Ein LO (Learning Object) ist die kleinste sinnvolle Lerneinheit, in die

ein Online-Kurs zerlegt werden kann. Demnach kann ein LO entweder aus

einem einzelnen Bild, einer Grafik, einem Text, einer Flash-Animation oder

aus einer kurzen Anweisung mit einem definierten Lernziel und einem Test zur

Lernerfolgskontrolle bestehen.

Wenn diese LOs mit Metadaten versehen und zu gr¨

oßeren Online-

Kurseinheiten kombiniert werden k¨

onnen, dann spricht man von RLOs (Reu-

sable Learning Objects = wieder verwendbare Lernobjekte) ([Baumgartner02],

Seite 31).”

Wie bereits herausgearbeitet wurde, sind Learning Objects modular und universell

einsetzbar. Jedoch stellt sich die Frage, wie eine große Anzahl von ihnen moderat gehand-

habt werden soll: Stellt man sich einen Pool zahlloser Lernobjekte vor und will gerade ein

34 KAPITEL 2. GRUNDLAGEN

bestimmtes Lernobjekt entnehmen, welches f¨

ur einen zu erzeugenden Kurs ben¨

otigt wird,

so wird zwangsl¨

aufig nach Mechanismen zur Selektion verlangt. Beispielsweise w¨

are eine

Suchfunktion auf Schlagwortbasis eine plausible L¨

osung, wie es die Suchmaschinen beim

Auffinden von Webseiten anwenden. Es gibt jedoch gravierende Unterschiede hinsicht-

lich Metainformationen zwischen Webseiten und Lernobjekten, die sich auf den jeweiligen

Lernkontext beziehen. Die Daten, die Aufschluss ¨

uber ein Lernobjekt geben, werden als

Metadaten bezeichnet. Sie liefern beispielsweise Informationen ¨

uber die maximale Lern-

dauer, den Grad der Schwierigkeit oder das Fachgebiet.

Metadaten gliedern sich in objektive und subjektive Metadaten. Erstere repr¨

asentieren

generelle Daten ¨

uber ein Lernobjekt, die in den meisten F¨

allen durch ein Softwaresystem

generiert werden. Hierzu z¨

ahlen das Erstellungsdatum, der Autor, die Kosten oder die

Lerndauer. Im Gegensatz dazu definieren subjektive Metadaten bewertende Einsch¨

atzun-

gen ¨

uber ein Lernobjekt, die f¨

ur eine m¨

ogliche Identifikation eines Lernobjektes ausschlag-

gebend ist. Damit Metadaten von Lernplattformen und Repositories ausgewertet werden

k¨

onnen, wurde soeben der Learning Objects Metadaten (LOM) Standard durch das IEEE

verabschiedet (vgl. Abschnitt 2.3.3).

Ein zweiter wichtiger Aspekt der Lernobjekte bezieht sich auf deren Sequenzierung.

In Abh¨

angigkeit von individuellen Vorkenntnissen und F¨

ahigkeiten kann die Reihenfolge

von Lernobjekten adaptiert werden. Dieses erm¨

oglicht Learning Management Systemen

(vgl. Abschnitt 3.3) ein Profil des Lernenden zu erstellen und einen auf den Lernenden

abgestimmten Lehrstoff selektiv anzubieten. Das hat den Vorteil, dass Lernende nicht

Lernobjekte abarbeiten m¨

ussen, deren Inhalte bereits erlernt wurde. Dar¨

uber hinaus lassen

sich Ordnungsrelationen f¨

ur Lernobjekte definieren. Ein Beispiel f¨

ur eine Relation auf

Lernobjekten ist die chronologische Anordnung von Kursen oder der Komplexit¨

atsgrad

von Aufgaben.

2.4.1 Metaphern

Bei der Entwicklung neuer Verfahren und Systeme dienen oft Entwicklungen anderer Do-

m¨

anen oder die Natur als inspiratives Vorbild. Diese zumeist durch Metaphern beschrie-

benen Sachverhalte erm¨

oglichen den Anwendern und Entwicklern einen m¨

oglichst raschen

Zugang zu einer Thematik, in der sie nicht zwingend Fachkompetenz mitbringen m¨

us-

sen. Hierbei findet eine kontextuelle Abbildung eines Sachverhaltes einer Dom¨

ane ohne

Fachkompetenz und Erfahrung auf den Sachverhalt einer anderen Dom¨

ane statt, in der

ein zumindest substantielleres Wissen zu erwarten ist. Der Begriff der Metapher wird in

Seufert [Seufert02] wie folgt definiert:

”Metapher (griech.: meta pherein=anderswo hintragen) ist das sprachliche

Bild, dessen Bedeutungs¨

ubertragung auf Bedeutungsvergleich beruht: das ei-

gentlich gemeinte Wort wird durch ein anderes ersetzt, das eine sachliche oder

gedankliche ¨

Ahnlichkeit oder dieselbe Bildstruktur aufweist wie z. B. Quelle

f¨

ur Ursache (aus [Rieser00], Seite 400).”

2.4. LERNOBJEKTE (LEARNING OBJECTS) 35

Der Mehrwert, der durch die Nutzung von Lernobjekten hervorgebracht wird, kann

ebenso durch die Verwendung von Metaphern beschrieben werden. Hodgins [Hodgins02]

gilt als Vater der Lernobjekte und hat sie anhand der LEGO-Baustein Metapher abgeleitet.

Die Vision, die sich hinter dieser Metapher verbirgt, versinnbildlicht eine Welt, in der jede

Lerneinheit in kleine handliche St¨

ucke aufgeteilt ist, entsprechend der LEGO-Bausteine,

die als elementare Teile zu einem komplexen Gebilde zusammengesetzt werden k¨

onnen,

die auf unterschiedliche Arten zu einem individuellen, je nach Vorkenntnissen ausgerich-

teten Kurs aggregiert werden k¨

onnen. Hodgins hat ebenso bemerkt, dass die Verwendung

von LEGO-Bausteinen unabh¨

angig vom individuell pr¨

aferierten lerntheoretischen Ansatz

ist, d. h., dass neben einem konstuktivistischen (vgl. Kaptiel 2.2.2) Vorgehen ebenso ein

behavioristisches Vorgehen m¨

oglich ist. Die Grundlage f¨

ur die universelle Verwendung

der LEGO-Bausteine bildet ihr standardisierter Aufbau. Durch die einheitliche Gr¨

oße der

Stecker ergeben sich folgende Eigenschaften [Wiley99]:

•jeder LEGO-Baustein ist kompatibel mit jedem anderen,

•LEGO-Bausteine k¨

onnen in beliebiger Weise zusammengesetzt werden,

•LEGO-Bausteine sind so einfach aufgebaut, dass sie von jedem zusammengesetzt

werden k¨

onnen.

Diese Vorteile sollen auch f¨

ur die Verwendbarkeit von Lernobjekten gelten. Standar-

disierungsbem¨

uhungen f¨

ur Lernobjekte wurden bereits in Abschnitt 2.3.2 eingef¨

uhrt und

nehmen eindeutig Bezug auf die durch die LEGO-Metapher motivierten Eigenschaften.

Hodgins verfeinert den Ansatz zu der robusteren Analogie der Bauindustrie (Quelle:

[Hodgins02], Seite 76). Laut Hodgins werden rund 85-95 Prozent der bei der Konstruk-

tion neuer Bauwerke verwendeten Komponenten vorgefertigt und in Abh¨

angigkeit vom

Bauvorhaben ausgew¨

ahlt. Als Komponenten werden unter anderen T¨

uren, Schr¨

anke oder

Fenster bezeichnet. Obwohl diese Komponenten einen immensen Spielraum an Kreativi-

t¨

at bieten, werden globale Richtlinien bei deren Fertigung ber¨

ucksichtigt. So ist z. B. zu

gew¨

ahrleisten, dass der Konstrukteur beim Entwurf einer T¨

ur die vorgegebene H¨

ohe und

Breite ber¨

ucksichtigt, damit der Architekt auf eine m¨

oglichst große Auswahl vorgefertig-

ter T¨

uren zur¨

uckgreifen kann und sich nicht von vornherein auf ein bestimmtes Modell

festlegen muss.

David Willy schl¨

agt hingegen eine andere Form der Konkretisierung trivialer LEGO-

Bausteine vor [Wiley99]: Er favorisiert die ATOM-Metapher als abstraktes und reales

Vorstellungsmodell f¨

ur Lernobjekte, die eine festgelegte Aggregationsbeziehung zwischen

Atomen vorsieht, aus der sich gr¨

oßere Kristallstrukturen ergeben. Willy hat dies mit fol-

gendem Satz beschrieben:

”Rather than thinking about LEGOs or Lincoln Logs, perhaps our minds

should be pointed toward something like a “learning crystal”, in which indi-

vidual learning objects are combined into useful structure ([Wiley00a], Seite

20).”

36 KAPITEL 2. GRUNDLAGEN

Gegen¨

uber der LEGO-Metapher zeichnet sich das Atom-Modell durch folgende Eigen-

schaften aus:

•Nicht jedes Atom kann mit einem beliebigen Atom kombiniert werden,

•Atome k¨

onnen nur auf bestimmte Weise, vorgegeben durch ihre Struktur, zusam-

mengesetzt werden,

•f¨

ur das Zusammensetzen von Atomen wird neben dem n¨

otigen Verst¨

andnis auch die

Erfahrung ben¨

otigt.

2.4.2 Analyse

Nachdem die drei wesentlichen Denkweisen auf dem Gebiet der Metaphern f¨

ur Lernobjekte

eingef¨

uhrt wurden, soll nun in Hinblick auf die Fragestellung dieser Arbeit eine abschließen-

de Diskussion stattfinden. Die LEGO-Metapher zeichnet sich als einfaches Mittel aus, um

bei der Erstellung von Inhalten komplexe Vorgehensmodelle zu beschreiben und diese zu

diskutieren. Ein solcher Ansatz bietet eine solide Basis f¨

ur die Erstellung modularer Kurs-

einheiten, die speziell f¨

ur interdisziplin¨

ar einsetzbare Kurse unbedingt notwendig ist. Das

bedeutet, dass Entwickler und Entwicklerinnen von Inhalten die selbe modulare Denkweise

f¨

ur den Konstruktionsprozess entwickeln, damit eine m¨

ogliche Kursaggregation erst m¨

og-

lich wird. Bedauerlicherweise befasst sich die Metapher ausschließlich mit der Aggregation

von Bausteinen und nicht mit deren Lagerung und Auswahl, wodurch weitere interessante

Betrachtungsfelder und Fragen aufgeworfen werden. Die Atom-Metapher bietet im Ver-

gleich zu der LEGO-Metapher einen stark restriktiven Ansatz, der die Handlungsfreiheit

bei der Konstruktion von Kursen massiv einschr¨

ankt. Demnach lassen sich nur sinnvol-

le Konstrukte erzeugen, was sicherlich nicht im Sinne der Autoren und Autorinnen ist.

Des weiteren l¨

asst die auferlegte hierarchische Ordnung Kristall, Atom, Proton und Quark

keine verschachtelte Struktur zu, die bei der Kombination unterschiedlich großer Kurse

zwangsl¨

aufig zu großen Problemen f¨

uhrt. Als Beispiel stelle man sich zwei Kurse vor: Ei-

ner enth¨

alt ein umfangreiches Vorlesungsskript ¨

uber Analysis und der andere kleinere einen

Kurs mit dem Thema Nullstellenberechnung. Bei dieser Betrachtung ist absolut unklar,

ob der kleine Kurs einem Kristall, einem Atom oder sogar einem Proton entspricht. Eine

derart restriktive Kurshierarchie unterbindet die Aggregation mit Kursen anderer Ebenen.

Die Bauindustrie-Metapher bietet hingegen die Verwendung komplexer Komponenten

an, was mit der zeitaufw¨

andigen und langwierigen Entwicklung von Lernobjekten ver-

gleichbar ist. Ein wichtiger, von Hodgins nicht beleuchteter Aspekt ist die Rolle des Ar-

chitekten, der zwangsl¨

aufig in den Entwicklungsprozess eines Geb¨

audes involviert ist. Die

Auswahl einer speziellen T¨

ur, mit allen individuellen Merkmalen, wird meistens zu Beginn

eines Bauvorhabens festgelegt und trifft auf alle Objekte desselben Typs zu. W¨

urde die-

ses nicht ber¨

ucksichtigt werden, ließe sich das Haus sicherlich schwieriger verkaufen, denn

wer m¨

ochte schon in einem Haus wohnen, in dem jedes Objekt eine andere Auspr¨

agung

besitzt. Was bei der Entwicklung von Bauvorhaben jedem klar zu sein scheint, wird bei

der Konstruktion von Lernobjekten v¨

ollig außer Acht gelassen.

2.4. LERNOBJEKTE (LEARNING OBJECTS) 37

2.4.3 Granularit¨

Die vorgestellten Metaphern haben bereits gezeigt, dass die Aussage, wie groß ein Lern-

objekt sein sollte, nicht ohne weiteres zu beantworten ist. Die LEGO-Metapher beschreibt

kleine Bausteine, von denen tausende ein komplexes Gebilde ergeben. Im Gegensatz wer-

den sowohl bei der ATOM- als auch bei der Bauindustrie-Metapher komplexere, aus ande-

ren elementareren Teilen zusammengesetzte Bausteine herangezogen. Ein großes Problem

tritt bei der Festlegung der Granularit¨

at eines Lernobjektes auf. Je nach Einsch¨

atzung

der konstruierenden Person wird sie relativ angegeben und kann dadurch zu Kompa-

tibilit¨

atsproblemen f¨

uhren. Pauschal l¨

asst sich jedoch sagen, dass je kleiner Lernobjek-

te konstruiert werden, desto leichter k¨

onnen sie in andere Kontexte eingebettet werden

[Hodgins02,Wiley04,Weitl04]. Der Nachteil liegt auf der Hand: Bei einer enorm großen

Anzahl an Lernobjekten erh¨

oht sich der Aufwand bei der Suche nach einem speziellen

Lernobjekt und es m¨

ussen wesentlich mehr Metadaten zur eindeutigen Identifikation her-

angezogen werden. Letzteres erfordert ein hohes Maß an Bereitschaft, wie es z. B. bei der

Metadatenspezifikation von OMDoc-Inhalten (vgl. Abschnitt 3.2.3) der Fall ist und ist von

den meisten Autoren und Autorinnen wohl nicht zu erbringen.

Als L¨

osungsvorschlag wird in der IEEE LOM Spezifikation (vgl. Abschnitt 2.3.3) der so

genannte Aggregationslevel eingef¨

uhrt (siehe Abb. 2.4.3), mit dem der Granularit¨

atsgrad

explizit eingestellt werden kann (LOM-Spezifikation [Electrical02], Seite 15).

Aggregation Level - The functional granularity of this learning object:

1. the smallest level of aggregation, e.g. raw media data or fragments.

2. a collection of level 1 learning objects, e.g., a lesson.

3. a collection of level 2 learning objects, e.g., a course.

4. the largest level of granularity, e.g., a set of courses that lead to a certificate.

Abbildung 2.12: Aggregationslevel f¨

ur Lernobjekte nach dem IEEE Standard f¨

ur Metadata

(LOM)

Die vom IEEE eingef¨

uhrten Aggregationsstufen widersprechen zun¨

achst den Aussagen

von Hodgins und Wiley und zwar, indem ein Lernobjekt so klein wie m¨

oglich sein soll.

Ignatiadis beschreibt dieses wie folgt:

”A Learning Object must be able to satisfy a single learning objective and

should not introduce many different ideas. There is no reason why a large

learning object should be designed, since a compound learning object consisting

of two or more other Learning Objects can be built, which can serve the same

purpose ([Ignatiadis03], Seite 10).”

Verfolgt man diesen Ansatz weiter, so w¨

urden alle Kurse oder Module aus der maxi-

malen Anzahl von Lernobjekten bestehen, die bei großen Kursen schnell un¨

ubersichtlich

werden und schlecht zu warten sind. Wird jedoch der Aspekt der Verschachtelung ber¨

uck-

sichtigt, so k¨

onnten Lernobjekte aus anderen bestehen, wobei eine gew¨

unschte Dekomposi-

38 KAPITEL 2. GRUNDLAGEN

tion sicherlich kein allzu großes Problem darstellt. Aufgrund der Generalit¨

at von Standards

ist die Festlegung von Aggregationsstufen sinnvoll, weil die subjektive Selektion einer Gra-

nularit¨

atsstufe unterschiedlich motiviert sein kann. Ein solches Auswahlkriterium k¨

onnte

die Zeit sein, die f¨

ur die Bearbeitung eines Lernobjekts ben¨

otigt wird, die Sequenzierung

eines Kurses oder der Aspekt der Wiederverwendbarkeit von Lernobjekten.

Kapitel 3

Technologien

In diesem Kapitel werden technische Realisierungen von Lerninhalten analysiert und Re-

sultate aus ausgew¨

ahlten Projekten vorgestellt. Danach findet eine Auswertung kommerzi-

eller und wissenschaftlicher Systeme statt, um einerseits deutlich zu machen, welche zum

Teil großen Defizite die analysierten Systeme aufweisen und andererseits, um wichtige

Erkenntnisse aus diesen Arbeiten zu gewinnen.

3.1 Wiederverwendung von Lernmaterialien

Dieser Abschnitt diskutiert den aktuellen Stand der Entwicklung von Systemen und Tech-

nologien zur modularen Kurskonstruktion mit dem Fokus einer konsistenten Kurserzeu-

gung und Wiederverwendung bestehender Ressourcen. Hierbei soll der Aufbau und die

daf¨

ur entwickelten Datenstrukturen untersucht werden, die Aufschluss ¨

uber die techni-

sche Modellierung eines Systems f¨

ur interdisziplin¨

ar nutzbare Lerneinheiten geben sollen.

Im Folgenden werden zwei technisch verschiedene Ans¨

atze betrachtet, die unterschiedliche

Strategien f¨

ur das Einlesen, Verwalten und Transformieren von Materialien verfolgen.

3.1.1 Slicing Books

Am Koblenzer Institut f¨

ur Informatik wurde die Slicing-Book-Technologie [Dahn02,

Dahn01] entwickelt, mit der es m¨

oglich ist, digitale B¨

ucher, unabh¨

angig von einer spe-

ziellen Fachrichtung, derart aufzubereiten, dass sie in kleine Teile, so genannte Slices, zer-

legt werden, um sie dann zu neuen B¨

uchern zusammen setzen zu k¨

onnen. Dahn [Dahn05]

definiert den Begriff Slice wie folgt:

“A potential slice is a connected part of a document that can be reused

under well defined conditions (aus [Dahn05], Seite 3).”

Der Inhalt wird hierarchisch angeordnet, wobei Relationen zwischen Slices mit Hil-

fe von Metadaten definiert werden [Valerius01]. Dabei sind insbesondere Abh¨

angigkeiten

von Slices gemeint, die bei der Dekomposition von elektronischen B¨

uchern beachtet werden

m¨

ussen. Ein Beispiel hierf¨

ur ist die Abh¨

angigkeit eines Beweises von einer zugeh¨

orenden

40 KAPITEL 3. TECHNOLOGIEN

Definition. Ohne die Definition kann der Beweis nicht in ein anderes Buch eingebunden

werden. Die Slices und die zugeh¨

origen Metainformationen werden auf einem zentralen

Server gespeichert, der, abh¨

angig vom Benutzer- bzw. Benutzerinnenprofil, eine individu-

elle Zusammenstellung von Kursunterlagen erlaubt. Zus¨

atzlich zu der Wiederverwendung

von bestehenden elektronischen B¨

uchern, wird die Neuentwicklung von Slices unterst¨

utzt.

Abbildung 3.1: System Modules of Slicing Books

Abbildung 3.1 (aus [Dahn02]) zeigt die Interaktion der Module, die f¨

ur die Verarbei-

tung eines Dokuments notwendig sind. Der erste Disaggregationsschritt wird vom Splitter

ubernommen. Zun¨

achst werden Metadaten, wie z. B. Referenzen oder Schl¨

usselw¨

orter

(Keywords) durch den Splitter aus dem Dokument extrahiert. Da viele Dokumente nicht

ausreichend mit Schl¨

usselw¨

ortern versehen sind, werden sie in einem zweiten Schritt au-

tomatisch den extrahierten Slices zugewiesen. Das Ergebnis wird dem Reengineering Tool

ubergeben, das mit einem Schl¨

usselwort-Server verbunden ist. Dieser liefert Verweise auf

Slices anderer B¨

ucher und bietet dem Anwender bzw. der Anwenderin eine Liste m¨

ogli-

cher Schl¨

usselw¨

orter, die f¨

ur die anstehende ¨

Uberarbeitung des Dokuments relevant sein

k¨

onnen.

3.1.2 ITO-Projekt

Das Ziel des ITO-Projekts [Finsterle02] der Universit¨

at Stuttgart ist die Entwicklung von

modularen Lehreinheiten f¨

ur die F¨

acher Elektrotechnik, Informatik und Informationstech-

nik. Die realisierten Module sollen im Rahmen des Projekts Multimediale englischsprachige

Vorlesungen f¨

ur den Studiengang Information Technology aufbereitet werden.

In diesem Projekt wurde ein System entwickelt, mit dem es m¨

oglich ist, bereits ver-

fasste Skripte und Unterlagen, die speziell f¨

ur die Lehre entwickelt wurden, derart zu

konvertieren, dass sie f¨

ur die Einbettung in eine Online-Pr¨

asentation geeignet sind. F¨

die Wiederverwendung von MS Word, MS Powerpoint und OpenOffice Dokumenten wurde

die OpenOffice-Anwendung als Mediator verwendet. Durch die zahlreichen Import- und

Export-Filter und das auf XML basierte Dokumentenformat [OOS02], bietet sich diese

Anwendung sehr gut f¨

ur eine Dokument Transformation an. Ein Transformator zerlegt

Dokumente in die Teile Inhalt,Metadaten,Objekte,Struktur und Layout und speichert

diese Informationen zusammen mit dem Quelldokument in einer Datenbank ab (vgl. Ab-

bildung 3.2).

3.1. WIEDERVERWENDUNG VON LERNMATERIALIEN 41

Abbildung 3.2: Import

Das analysierte Dokument kann jetzt f¨

ur die Gernerierung unterschiedlicher Ausga-

beformate eingesetzt werden (vgl. Abbildung 3.1.3). Soll z. B. eine WEB-Pr¨

asentation

erstellt werden, wird die gespeicherte Strukturinformation in Verbindung mit den vor-

handenen Metadaten f¨

ur die Generierung einer Navigation verwendet. Der unterhalb der

Navigation angezeigte Inhalt wird entsprechend aus der Struktur, dem Inhalt und den vor-

handenen Objekten generiert. Um eine inhaltliche Bearbeitung durchzuf¨

uhren, wird auf

das urspr¨

ungliche Dokument zur¨

uckgegriffen.

3.1.3 Analyse

Die in diesem Abschnitt vorgestellten Ans¨

atze, bestehende Dokumente technisch zu ver-

arbeiten, beziehen sich auf die beiden zu untersuchenden Themen Integrierbarkeit und

Formatierbarkeit (vgl. Tabelle 2.1). Der Ansatz der bei der Slicing Book-Technik gew¨

ahlt

wurde, zerlegt ein bestehendes Dokument in kleine, voneinander abh¨

angige Teile, die mit

Hilfe von Metadaten vernetzt werden. Hierbei wird das Reengineering mit Metadaten

als aktiver Prozess verstanden, der maßgeblich an der Gestaltung neuer Dokumente bei-

tr¨

agt. Dieses schließt ebenso die Definition der Metadaten mit ein, die je nach Umfang des

zu transformierenden Dokuments einen nicht zu untersch¨

atzenden Zeitaufwand mit sich

bringt.

Das ITO-Projekt bietet eine technische L¨

osung, um unterschiedliche Formate in ein all-

gemeines Zwischenformat zu ¨

uberf¨

uhren, dass, zu einem sp¨

ateren Zeitpunkt, in ein anderes

Ausgabeformat konvertiert werden kann. Hierbei ist die Aufspaltung in die Teilelemente

Inhalt, Metadaten, Objekte, Struktur und Layout ein guter Ansatz, der in dieser Arbeit

ber¨

ucksichtigt werden muss. Dennoch fehlen Mechanismen, um die Aspekte Modularit¨

at,

42 KAPITEL 3. TECHNOLOGIEN

also die Aggregation mit anderen Dokumenten, und die damit verbundene Granularit¨

umzusetzen.

Abbildung 3.3: Export

3.2 Formale Beschreibung von Lernmaterialien

Im Zuge der anstehenden Betrachtungen soll analysiert werden, wie Lernmaterialien be-

schaffen sind, formuliert und konstruiert werden. Lernmaterialien werden voranging als

HTML-Dokumente oder als PDF-Dokumente Studierenden angeboten. Es hat sich aller-

dings gezeigt, dass es auf diesem Gebiet vielseitige Bem¨

uhungen gibt, Definitionen und

Spezifikationen f¨

ur Lehrinhalte vorzuschlagen, die es teilweise bis zur Standardisierung ge-

schafft haben. Die meisten in diesem Zusammenhang dargelegten Vorschl¨

age basieren tech-

nisch auf der Auszeichnungssprache XML (eXtendable Markup Language, vgl. Abschnitt

3.2.1). In Arbeiten von [Gersdorf02,Freitag02a,Kohlhase02,Belqamsi02,Baudry02b,

Baudry03,Roisin98,Net05,Verbert04] werden Ergebnisse bei der Konstruktion von E-

Learning-Inhalten pr¨

asentiert, die mit XML formal beschrieben werden. Sie zeigen außer-

dem, dass der Einsatz von XML die Implementierung von Suchsystemen f¨

ur Kursinhalte

erheblich vereinfacht [Wollowski02]. Aus diesem Grund wird eine kleine Einf¨

uhrung in

die Grundlagen der Markupsprachen gegeben, um das notwendige Verst¨

andnis f¨

ur die an-

stehenden Ausf¨

uhrungen, Analysen und Bewertungen zu vermitteln. In diesem Abschnitt

sollen allein die technischen M¨

oglichkeiten aufgezeigt werden; Themen wie z. B. Adaptive

Lerninhalte (vgl. [Brusilovsky01],[Brusilovsky98]) bleiben daher unber¨

ucksichtigt.

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 43

3.2.1 SGML / XML

Mitte der 80er Jahre wurde nach einer M¨

oglichkeit gesucht, Daten auf einfache Weise

abzuspeichern, zu bearbeiten und zwischen Anwendungen auszutauschen. Hierbei wurde

insbesondere der Forderung nachgegangen, die inhaltliche Struktur von Dokumenten von

ihrer Darstellung so zu trennen, dass sie f¨

ur unterschiedliche Anwendungszwecke eingesetzt

werden k¨

onnen. So k¨

onnen beispielsweise Verlage mit einem solchen Format Dokumente

bzw. Artikel austauschen und abh¨

angig vom vorgegebenen Layout Konvertierungen vor-

nehmen. Jedoch gibt es auch Anwendungsszenarien, bei denen Daten zwischen Applika-

tionen ausgetauscht werden m¨

ussen, die frei von Layout-Eigenschaften sind. Aus diesem

Grund hat das ISO-Gremium (International Strandard Organization) 1986 die normier-

te Auszeichnungssprache SGML verabschiedet [Szillat95,Goldfarb90]. SGML bietet die

M¨

oglichkeit, eigene Strukturelemente, wie z. B. Abs¨

atze, ¨

Uberschriften oder textuelle Her-

vorhebungen, zu definieren, ohne zu spezifizieren, mit welcher Schriftgr¨

oße, Schriftart oder

Farbe sie gedruckt werden. Des weiteren wird durch SGML die Reihenfolge der Auszeich-

nungen festgelegt und durch ein spezielles Programm, den so genannten Dokumentparser,

wie z. B. Xerces [Xer05] analysiert und ¨

ubersetzt. SGML erwies sich jedoch auf Grund

seiner Komplexit¨

at als zu unhandlich, um schnelle und preisg¨

unstige Parser entwickeln zu

k¨

onnen. Deshalb gibt es seit Beginn der 90er Jahre Bem¨

uhungen eine vereinfachte Form

zu entwickeln. Als Ergebnis wurde Mitte der 90er Jahre die Extensible Markup Language

(XML) vom W3C (World Wide Web Consortium) verabschiedet. Der wesentliche Unter-

schied zu SGML liegt in der ¨

Uberpr¨

ufung der Dokumente. Zur Vereinfachung f¨

uhrt XML

das Prinzip der Wohlgeformtheit ein, welches besagt, dass die Struktur von Dokumenten

eindeutig sein muss. Dieses erm¨

oglicht dem Parser, das Dokument einzulesen, ohne An-

nahmen ¨

uber die Struktur treffen zu m¨

ussen, indem eine DTD (siehe Abschnitt 3.2.1) zur

Uberpr¨

ufung herangezogen wird. Des Weiteren wird gew¨

ahrleistet, dass nachfolgende Pro-

gramme fehlerfrei arbeiten, da die Integrit¨

at und Konsistenz gew¨

ahrleistet wird [Ray01].

Zentrales Konstrukt ist das Element, das zur Textstrukturierung dient. Ein Dokument

besitzt grunds¨

atzlich ein Wurzelelement, welches mehrere Kindelemente beinhaltet. Diese

Kindelemente k¨

onnen weitere Kindelemente enthalten. Elemente sind also Container, die

genau einem ¨

ubergeordneten Element unterstellt sind. Zudem k¨

onnen sie eine Kombinati-

on von Elementen und Textknoten enthalten, die vom Parser wie Objektknoten behandelt

werden, jedoch nicht ¨

uber ein syntaktisches Konstrukt verf¨

ugen. Dieses impliziert, dass

aus jedem Dokument eine Repr¨

asentation als Baumstruktur abgeleitet werden kann. Da-

mit ein Parser die Struktur analysieren kann, werden zur Hervorhebung Sonderzeichen

verwendet, welche sich vom eigentlich zu verwendeten Zeichensatz des Dokuments unter-

scheiden. Der XML- und SGML-Standard sehen hierf¨

ur die Schreibweise von Elementen

in spitzen Klammern vor, in die der Bezeichner eingeschlossen wird. Dem XML-Standard

entsprechend, muss jedes ge¨

offnete Element auch wieder geschlossen werden. Dieses wird

wiederum durch einen in spitzen Klammern eingeschlossenen Bezeichner erreicht, mit dem

Unterschied, dass dieser einen Schr¨

agstrich als Pr¨

afix f¨

uhrt. Das folgende Beispiel zeigt

eine einfache XML-Struktur eines Buchs mit zugeh¨

origem Titel und Autor.

44 KAPITEL 3. TECHNOLOGIEN

Listing 3.1: Beispiel einer XML-Deklaration

1<Buch>

<Title>

Einf¨

uhrung in XML

4</Title>

<Autor>

Erik T.Ray

7</Autor>

</Buch>

Das Attribut ist ein wichtiger Zusatz zum Elementbegriff. Er fungiert als Informati-

onsspeicher und kann dazu benutzt werden, Elementen eindeutige Zust¨

ande zuzuordnen.

Abbildung 3.1 illustriert den syntaktischen Aufbau eines Elements mit zwei Attributen.

Attributwerte werden in Anf¨

uhrungszeichen gesetzt und d¨

urfen innerhalb eines Elements

genau einmal vorkommen. In einer Element-Definition k¨

onnen Attribute – im Gegensatz

zum Funktionsaufruf einer Prozedurdefinition – an beliebige Positionen gesetzt werden.

Die Reihenfolge ist f¨

ur den Parser nicht relevant.

</Name>

Text

Schließen des Elements Inhalt

Attribute

Bezeichner

Abbildung 3.4: Syntax eines XML-Elements

Ein weiteres Leistungsmerkmal von XML ist das Konzept der Namensr¨

aume. Ein Na-

mensraum beschreibt eine Menge oder Gruppe von Elementen und Attributen, die genau

einem Kontext zugeordnet werden. G¨

abe es kein solches Mittel, w¨

urden beim ¨

Ubersetzen

von Dokumenten zwangsl¨

aufig Konflikte auftreten. Als Beispiel sei hier die Analogie zum

Wortumfang der deutschen Sprache genannt [Ray01]. Es gibt zahlreiche kontextabh¨

angige

Begriffe, wie z. B. das Wort Golf. Der Mensch ist in der Lage, kontextabh¨

angig zu ent-

scheiden, ob es sich um das Spiel, das Auto oder einen Einschnitt des Meeres im Festland

handelt. Die Maschine handelt hingegen deterministisch und trifft keine eindeutige Zuord-

nung. Die XML-Spezifikation sieht hierf¨

ur eine Pr¨

afixnotation vor, die – abgetrennt durch

das Doppelpunktsymbol – den Kontext des Attribut- bzw. Elementbezeichners festlegt.

Ein eher technisches Beispiel ist der Einsatz von Namensr¨

aumen bei der Transformati-

onssprache XSL (vgl. Abschnitt 3.2.1): Elemente lassen sich in die zwei Gruppen Befehle

und Ausgabeelemente unterteilen. Letztere werden dem resultierenden Dokument hinzu-

gef¨

ugt. Befehle geh¨

oren dagegen zum Sprachumfang von XSL und besitzen deshalb das

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 45

Pr¨

afix xsl:. Der XSLT-Prozessor erkennt w¨

ahrend der Verarbeitung des Dokuments eine

Instruktion und f¨

uhrt sie aus. Elemente, die zum Inhalt geh¨

oren, k¨

onnen entweder kei-

nem Namensraum oder einem zu xsl unterschiedlichen Namensraum zugeordnet sein. Zur

Deklaration eines Namensraums wird das reservierte Attribut xmlns: verwendet. Es signa-

lisiert dem Parser, dass alle Nachkommen eines Elements Teil des im Attribut spezifizierten

Namensraums sind.

Schach

<automobile:golf>

Käfer Volvo

Golf

Volleyball

Basketball

<sport:golf>

Namensraum: Sport Namensraum: Automobile

Ford

Abbildung 3.5: Eindeutige Zuordnung von Elementbezeichnern durch Pr¨

afixnotation

Als letztes wesentliches Konzept der Markupsprache XML sind Entities zu nennen.

Sie werden als Platzhalter f¨

ur Zeichen, W¨

orter, Wortgruppen oder XML-Fragmente be-

nutzt und k¨

onnen an unterschiedlichen Stellen im Dokument vorkommen. W¨

ahrend der

Dokument-Analyse substituiert der Parser die Entities mit den ihnen zugewiesenen Wer-

ten. Dar¨

uber hinaus k¨

onnen mit ihnen extern eingebundene XML-Fragmente referenziert

werden. Die Entity-Notation am Anfang eines Dokuments l¨

asst sich wie folgt formulieren:

Listing 3.2: Entity Notation

1<!ENTITY Bezeichner ”Wert”>

Bisher wurden die Basiskonzepte von XML eingef¨

uhrt, um deren syntaktische Struktur

zu erl¨

autern. Zudem wird im Folgenden die syntaktische Struktur semantischer Regeln

und Beziehungen vorgestellt. Dokumentenmodelle werden formal spezifiziert und lassen

sich durch eine entsprechende Grammatik formulieren. In diesem Abschnitt werden nun

zwei Konzepte vorgestellt: Die DTD (Document Type Definition), die grunds¨

atzlich eine

Sammlung von Regeln darstellt, sowie das XML-Schema [W3C05a], ein ausdrucksstarker

und flexibler Mechanismus, zur datentyporientierten Definition von Dokumentenmodellen.

Validierung

Das zurzeit popul¨

arste Dokumentenmodell ist die DTD. Sie wurde bereits mit SGML vor

der Verabschiedung von XML eingef¨

uhrt und besteht aus einem Regelwerk, das die in

einem Dokument zul¨

assigen Elemente definiert. Ferner wird festgelegt, aus welchen Ele-

menten ein Element besteht, deren genaue Reihenfolge und ob sie an einer bestimmten

46 KAPITEL 3. TECHNOLOGIEN

Position auftreten d¨

urfen. In [Ray01] wird die Typdefinition f¨

ur ein Element als Content-

Model bezeichnet. Neben der Elementstrukturierung werden außerdem deren Attribute

spezifiziert. Es wird festgelegt, welche Attribute ein Element verwenden darf, dessen Da-

tentyp und das Auftreten von Elementen an bestimmten Positionen. Im Folgenden ist eine

Beispielregel zu sehen, die die Schablone f¨

ur das Element Dokument definiert.

Listing 3.3: Beispiel einer Element-Definition

<!ELMENT Dokument

2(Autor∗, Title, Jahr?, ( Absatz |Aufzaehlung )∗)

Diese Notation ¨

ahnelt derer f¨

ur regul¨

are Ausdr¨

ucke und bestimmt, dass jedes Doku-

ment beliebig viele Autoren besitzt, genau ein Titel enth¨

alt, eventuell genau ein Erschei-

nungsjahr notiert und einer Sequenz willk¨

urlich angeordneter Abs¨

atze und Aufz¨

ahlungen

folgt.

Neben dem bereits veralteten DTD-Konzept findet die Strukturdefinition mit XML-

Schemata (XSD) immer gr¨

oßeren Zuspruch. Das XML-Schema dient – genau wie die DTD

– zur Definition syntaktischer Regeln und deren Strukturierung. Es wurde vom W3C

eingef¨

uhrt, weil das DTD Konzept erhebliche Schw¨

achen aufwies. In [Hansch02] sind die

Vorteile des XML-Schema gegen¨

uber dem DTD-Konzept herausgearbeitet:

•Jedes XML-Schema ist selbst ein XML-Dokument, wodurch keine spezielle Syntax

definiert werden muss. Ferner kann ein XML-Schema wiederum durch ein Schema

validiert werden, ohne eine weitere Metaebene einzuf¨

uhren,

•komplexe Strukturen sind beschreibbar,

•Typpr¨

ufung wird durch vordefinierte und selbstdefinierte Typen erm¨

oglicht,

•bei Datentypen wird Vererbung und Substitution unterst¨

utzt,

•Nullwerte k¨

onnen dargestellt werden,

•das Modularisieren und Wiederverwenden von XML-Schemata ist m¨

oglich,

•Namensr¨

aume verhindern Benennungskonflikte.

Tranformation

Nachdem die Struktur von XML-Dokumenten eingef¨

uhrt wurde, stellt sich zwangsl¨

aufig

die Frage, wie diese Dokumente bearbeitet werden k¨

onnen. Zu diesem Zweck gibt es so ge-

nannte Transformatoren, deren Aufgabe die Verarbeitung und Abbildung einer vorliegen-

den Struktur auf eine andere ist. Einerseits besteht die M¨

oglichkeit, die den Dokumenten

zugrunde liegende Baumstruktur auf die Datenstruktur einer Programmiersprache abzu-

bilden und diese daraufhin zu modifizieren. F¨

ur die Sprache Java existiert z. B. die JDOM

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 47

[Harold02a] Bibliothek, die durch Einsatz von Entwurfsmustern, wie z. B. dem Fabrikmu-

ster [Gamma95], eine abstrakte Schnittstelle zur Erzeugung und Manipulation von Ob-

jektb¨

aumen anbietet. Auf der anderen Seite wurde die auf XML basierende Skriptsprache

XSL [XSL99,Harold02b] (eXtendable Stylesheet Language) entwickelt, die ein m¨

achtiges

Mittel zur Dokumententransformation darstellt. XSL basiert auf dem Paradigma der funk-

tionalen Programmierung und bietet daher keine Wertzuweisung an. Der Dokumentparser

arbeitet das einzulesende XML-Dokument hierarchisch ab und wendet eine dem Element

durch das XSL-Skript zugewiesene Regel an.

<xsl:template match="lob">

<xsl:stylesheet>

<xsl:template match="exercise">

<xsl:block font−size="12pt">

Excercise:

XSL

<fo:root>

<fo:layout−master−set/>

<fo:page−sequence>

<fo:flow>

</fo:flow>

</fo:root>

<xsl:apply−templates select="exercise"/>

XML

</fo:page−sequence>

<lob>

Zerlegen Sie die ...

</exercise>

</lob>

</xsl:block>

</xsl:stylesheet>

</xsl:block>

<xsl:value−of select="."/>

<fo:root>

<fo:layout−master−set/>

<fo:page−sequence>

<fo:flow>

<xsl:block font−size="12pt">

Excercise:

</xsl:block>

</fo:page−sequence>

</fo:flow>

</fo:root>

</xsl:block>

Zerlegen Sie die ...

<xsl:block font−size="10pt">

XML:FO

<xsl:template/>

Abbildung 3.6: Beispiel: XSL-Transformation einer einfachen XML-Struktur in eine FO-

Repr¨

asentation

Die Regel beschreibt unter Verwendung von funktionalen Mitteln den zu generieren-

den Ausgabestrom. Mit entsprechenden XSL-Befehlen lassen sich komplex verschachtelte

Strukturen mit wenig Aufwand konstruieren und warten. Zudem bieten XPath [W3C99]

und XQuery [W3C05b] Mechanismen an, um auf andere Elemente an beliebigen Positionen

im Dokument zuzugreifen. Abbildung 3.6 zeigt exemplarisch die f¨

ur einen Transformator

relevanten Dokumente. Das XSL-Dokument enth¨

alt jeweils eine Regel f¨

ur die Elemente

lob und exercise, die, ineinander verschachtelt, vom Transformator in die Ausgabedatei

geschrieben werden.

3.2.2 DocBook

DocBook ist 1991 aus einer Kooperation des O’Reilly-Verlages und der Firma Hal. Compu-

ter Systems entstanden. Der auf XML basierende Standard zur strukturellen Beschreibung

48 KAPITEL 3. TECHNOLOGIEN

von B¨

uchern, Artikeln und anderen Dokumenten [Walsh02], liegt als DTD und als XML-

Schema vor. Seit 1991 wurde DocBook in vielen Projekten, wie z. B. dem KDE2-Projekt,

zur technischen Dokumentation eingesetzt. Die Struktur eines Reports oder eines Buchs

kann mit DocBook modular und strukturiert aufgebaut werden. Hierzu wird in [Walsh02]

eine kategorische ¨

Ubersicht der verf¨

ugbaren Elemente angegeben (vgl. Tabelle 3.1). Listing

3.4 zeigt exemplarisch den Aufbau einer DocBook-Datei.

Kategorien Erkl¨

arung

Set Beschreibt eine B¨

uchersammlung

Book Definiert das Wurzelelement f¨

ur ein Buch

Division Gliedert ein Buch in verschiedene Teile auf

Component Gliedert B¨

ucher und Teile in Kapitel auf

Section Kapitel k¨

onnen verschachtelte Abschnitte enthalten

Meta-information Alle Elemente ¨

uberhalb der Abschnitte k¨

onnen Metadaten anhaften

Block Entsprechen einem Absatz und enthalten Listen, Tabellen, Abbildungen,

usw.

Inline Legt fest, ob ein Element innerhalb des Textflusses positioniert werden

soll

Tabelle 3.1: Kategorien f¨

ur Elemente zur Strukturierung von DocBook Dokumenten

Listing 3.4: DocBook Beispiel f¨

ur einen einfachen Artikel

<!DOCTYPE article PUBLIC ”−//OASIS//DTD DocBook V3.1//EN”>

3<artheader>

<title>My Article</title>

6<honorific>Dr</honorific>

<firstname>Emilio</firstname>

<surname>Lizardo</surname>

9</author>

</artheader>

12<sect1>

<title>On the Possibility of Going Home</title>

15</sect1>

</article>

3.2.3 OMDoc / OpenMath

Seit der Entwicklung des Hypertextes gibt es zahlreiche Bem¨

uhungen, mathematische In-

halte mit einem Webbrowser ad¨

aquat darzustellen. Neben der Formeldarstellung als Grafi-

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 49

ken, die sich im ¨

Ubrigen nicht skalieren lassen und eine nicht zu untersch¨

atzende Ladezeit

seitens der Browser verursachen, wurden auch weitgehende Bem¨

uhungen zur Standardi-

sierung von Formelbeschreibungen unternommen. Als Ergebnis entstanden die zwei mit-

einander konkurrierenden Standards OpenMath [Caprotti02] und MathML [Mat05b], von

denen MathML bereits von den Browsern Mozilla und Amaya unterst¨

utzt werden. Mathe-

matische Dokumente bestehen jedoch nicht nur aus Formeln, sondern auch aus Definitio-

nen, Lemmata und Beweisen. Um diese Elemente ebenfalls spezifizieren zu k¨

onnen, wur-

de das Datenmodell Open Mathematical Documents (OMDoc) [Kohlhase00,Kohlhase02]

entwickelt. OMDoc ist ebenfalls eine Markup Language und erweitert den OpenMath-

Standard, indem Onthologien mathematischer Dokumente festlegt werden. Zu der einfa-

chen Formelbeschreibung werden Aussagen ¨

uber die Beziehungen zwischen den mathe-

matischen Objekten getroffen. Mathematische Objekte k¨

onnen z. B. Theoreme, Beweise

mit zugewiesenen Eigenschaften und Relationen sein. Außerdem unterst¨

utzt OMDoc den

Metadaten-Standard Dublin Core, um Dokumente repr¨

asentieren zu k¨

onnen, sowie p¨

ada-

gogische Elemente zur Festlegung von Lernszenarien.

Listing 3.5: OMDoc Repr¨

asentation einer Definition

1<definition id=”def order” for=”order” type=”simple”>

4Definition of the order of a group element

</title>

7<field use=”mathematics”/>

10<ref theory=”elementary” name=”positive integer”/>

</depends−on>

</metadata>

13<CMP xml:lang=”en” verbosity=”3”>

If <OMOBJ><OMV name=”G”/></OMOBJ>is a

<ref xref=”Th1 def group”>group </ref>and <OMOBJ><OMA>

16<OMS cd=”set1” name=”in”/><OMV name=”g”/><OMV

name=”G”/></OMA></OMOBJ>,then the order of <OMOBJ>

<OMV name=”g”/></OMOBJ>is the smallest positive

19integer <OMOBJ><OMV name=”m”/> </OMOBJ>with

<OMA>

22<OMS cd=”relation1” name=”eq”/>

<OMA>

25<OMV name=”g”/>

</OMA>

28<OMS cd=”Th1” name=”unit”/>

50 KAPITEL 3. TECHNOLOGIEN

</OMA>

</OMOBJ>.

31...

</definition>

Listing 3.5 (aus [Melis03], Seite 13) zeigt exemplarisch eine OMDoc-Definition mit

dem Titel Definition of the order of a group element. Die Definition ist mit Metadaten

angereichert, welche die Definition beschreiben und deren genauen Einsatzkontext ange-

ben. Zudem wird eine Abh¨

angigkeitsrelation definiert, welche jene Objekte festlegt, die

f¨

ur das Verst¨

andnis essenziell sind. Im zweiten Abschnitt ist die Definition informell mit

dem <CMP>-Element angegeben. Es enth¨

alt neben dem Definitionstext auch die Formelbe-

schreibung mit OpenMath.

Die in diesem Beispiel integrierte OpenMath Formelbeschreibungen beginnen mit

dem XML-Element <OMOBJ> und enthalten Variablen (<OMV>), Symbole (<OMS>) und

Applikationen (<OMA>). Die Variable gwird z. B. durch den OpenMath-Ausdruck <OM-

OBJ><OMV name="g"/></OMOBJ> definiert und die Potenz durch eine Applikation mit ei-

ner Funktion und zwei zugeordneten Paremetern: <OMA><OMS cd=Th1name=power"/><OMV

name="g"/><OMV name=m"/></OMA>.

3.2.4 MathML

MathML [Mat05b] ist ebenso wie OpenMath eine auf XML basierende Auszeichnungsspra-

che zur Definition von Formeln. Sie wurde zum Datenaustausch zwischen technischen Sys-

temen, zur Anzeige im WebBrowser oder als Datenstruktur f¨

ur Computer-Algebra-Systeme

entwickelt. Je nach Anwendungskontext unterst¨

utzt MathML zwei Verarbeitungsmodi, das

content encoding und das presentaition encoding.

Das presentaition encoding beschreibt den syntaktischen Aufbau einer Formel und ver-

wendet ca. 30 XML-Elemente. Hierbei wird jedes Element der Formel durch ein eigenes

XML-Element angegeben, so dass Anzeigeprogramme die Semantik der Formel nicht in-

terpretieren m¨

ussen, sondern lediglich die grafische Darstellung zeichnen m¨

ussen. Listing

3.6 zeigt ein einfaches Beispiel dieser Kodierungsvariante f¨

ur die Formel (a+b)2.

Listing 3.6: MathML-Beispiel einer Formel mit presentation encoding

1<msup>

4<mo>+</mo>

</mfenced>

7<mn>2</mn>

</msup>

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 51

Dieses Beispiel zeigt, dass es f¨

ur Variablen und Operationen XML-Elemente gibt, die

eine Zeichenfolge einschließen. die Variablen aund bwerden durch das <mi>-Element

eingeschlossen und der Operator + durch das Element <mo>. Das Klammernpaar wird

durch das Element <mfenced> angegeben und die Zahl 2 wird durch das <msup>-Element

hochgestellt.

Das bloße Anzeigen von Formeln reicht jedoch f¨

ur die Verarbeitung in einem Computer-

Algebra-System nicht aus. Hier werden semantische Informationen ¨

uber eine Formel be-

n¨

otigt, um sie richtig interpretieren zu k¨

onnen. Das content encoding verwendet ca. 100

XML-Elemente – also deutlich mehr als das presentation encoding – und definiert den

strukturellen Aufbau einer Formel. Listing 3.7 zeigt ein einfaches Beispiel dieser Kodie-

rungsvariante f¨

ur die Formel (a+b)2.

Listing 3.7: MathML-Beispiel einer Formel mit content encoding

1<apply>

<apply>

4<plus/>

7</apply>

</apply>

Dieses Beispiel zeigt, dass die Variablen aund bnicht durch einen Infix-Operator

getrennt werden, sondern die Addition durch das <apply>-Element definiert wird. Der

erste Parameter spezifiziert die Operation oder Funktion und die folgenden Parameter die

Argumente. Ebenso wird die Potenz durch das <apply>-Element definiert.

3.2.5 Learning Material Markup Language (LMML)

LMML wird seit 1999 an der Universit¨

at Passau entwickelt und steht f¨

ur Learning Material

Markup Language. Zentrale Idee ist die Entwicklung eines allgemeinen Modells – dem

Passauer Teachware Modell – zur Konstruktion von E-Learning-Inhalten, das je nach

Bedarf an individuelle Anspr¨

uche adaptiert und erweitert werden kann. LMML basiert

auf XML (vgl. Abschnitt 3.2.1) und ist die konkrete Umsetzung des Teachware Modells

und wird zuweilen auch als LMML-Framework bezeichnet. Im Gegensatz zu anderen auf

XML basierenden Sprachen definiert LMML genau genommen eine erweiterbare Familie

von XML-Sprachen, deren Elemente f¨

ur spezielle Anwendungsdom¨

anen, wie z.B Informatik

oder Politikwissenschaften modifiziert werden k¨

onnen.

Das Passauer Teachware Metamodell [Freitag02b,Freitag02a] definiert den modularen

Aufbau von Lerneinheiten. Die Architektur dieses Modells (vgl. Abbildung 3.7) sieht vier

Modellierungsebenen vor: Die reale Welt, die hypermedia Ebene, das Dom¨

anenmodell sowie

52 KAPITEL 3. TECHNOLOGIEN

das abstrakte Modell [S¨

uß99]. Diese Ebenen sind ¨

ubereinander angeordnet und beschreiben

aufsteigend ein immer abstrakter werdendes Modell zur Spezifikation von Lernmodulen.

Auf der untersten Ebene, der realen Welt, siedeln sich je nach Anwendungsdom¨

ane unter-

schiedliche Themen zur Wissensvermittlung an. Diese sind auf der n¨

achst h¨

oheren Ebene,

der hypermedialen Ebene durch verlinkte Hypertexte, unter spezieller Ber¨

ucksichtigung

von Navigationskonzepten realisiert. Besonderes Interesse genießt die n¨

achst h¨

ohere Ebe-

ne, das sogenannte Dom¨

anenmodell, mit dessen Hilfe eine dom¨

anenspezifische Modellie-

rung der Hyperdokumente erm¨

oglicht wird. Auf dieser Ebene werden f¨

ur den Autor bzw.

die Autorin vordefinierte Content Objekte, wie z. B. Texte oder unsortierte Listen, zur

Konstruktion individueller Modelle bereitgestellt. Dar¨

uber hinaus werden fachspezifische

Objekte, wie z. B. Definitionen oder Theoreme aus den vorgegebenen Objekten gebildet.

Das abstrakte Modell vereinigt die Gemeinsamkeiten, denen die Gesamtheit der Dom¨

anen-

modelle zugrunde liegt. Dieses schließt sowohl die abstrakte Modellierung von Materialien

bestehend aus Content-Objekten, als auch die abstrakte Definition der Navigationsstruk-

tur ein.

Abbildung 3.7: Teachware Modell

Das LMML-Rahmenwerk wird als XSD-Schema oder als DTD-Modul angeboten und

erm¨

oglicht die Spezifikation neuer Elemente durch die Erweiterung bestehender Modelle.

Durch diesen Mechanismus wird beispielsweise eine Sprache f¨

ur die Anwendungsdom¨

ane

Informatik erzeugt, die spezialisierte Elemente f¨

ur Definitionen und Illustrationen charak-

terisiert. Der folgende LMML-Code zeigt einen Kurs zum Thema Datenbank-Theorie mit

je zwei unterschiedlich schwierigen Definitionen f¨

ur B-Trees:

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 53

Listing 3.8: Ein einfaches LMML-Beispiel

<?xml version=”1,0” standalone=”no”?>

<!DOCTYPE LearningMaterial ... >

3<LearningMaterial>

<courseunit author=”Hans Meier” date=”99/04/10”

discipline =”computer science” language=”english” title=”B−tree”

6topics=”B−trees,database index,search key,records,space

, efficiency ”>

<illustration title =”Search Key” topics=”search key,records”

9difficulty =”medium”/>

A B−tree is a multi level index.

12<ul>

<li>The file is organized as a balanced multipath tree

width</li>

15<li>reorganization capabilities.</li>

</ul>

</definition>

18<definition title =”B−Tree” topics=”B−Tree” difficulty=”high”>

A B−tree of height h and fan out of 2k+1 is either empty or

an ordered tree width the following properties:

21...

</definition>

...

24</courseunit>

</LearningMaterial>

3.2.6 Educational Modelling Language (EML)

Die Open University der Niederlande hat die Educational Modelling Language (EML) mit

dem Ziel entwickelt, Lerneinheiten um ein umfangreiches p¨

adagogisches Informationsmo-

dell zu erweitern. Dieses soll die Wiederverwendbarkeit von Lerneinheiten sowie deren

Zusammenwirken erheblich verbessern. Die Modellierung wird unter Einsatz der Uni-

fied Modelling Language UML durchgef¨

uhrt, wobei die konkrete Umsetzung ¨

uber XML-

Schemata [Koper04,Koper01] erfolgt. Im Gegensatz zu der Content Package Spezifikation

von IMS und ADL pr¨

asentiert EML eine p¨

adagogische Komponente und kompensiert hier-

mit die Unzul¨

anglichkeiten der bestehenden Standards. Die grundlegende Erstellung von

Lernobjekten und die dazugeh¨

orende Anreicherung mit Metadaten, reicht f¨

ur die p¨

adago-

gische Sicht nicht aus. Stattdessen ist die Typisierung von Lernobjekten notwendig. Genau

wie im objektorientierten Ansatz (OOA) gibt es unterschiedliche Klassen von Lernobjek-

ten, wie der zu vermittelnde Lehrstoff oder zu l¨

osende Aufgaben.

Abbildung 3.8 zeigt die XML-Schema-Bindung des EML-Rahmenwerkes (aus

[Koper04], Seite 8). Ausgangspunkt ist die unit of study, die eine Lerneinheit aus ver-

schiedenen Granularit¨

atsstufen zusammensetzt [Koper04,Pawlowski02]. Neben Metada-

54 KAPITEL 3. TECHNOLOGIEN

! Unit-of-study ~

Metadata

Roles

? Learning-objectives

? Prerequisites

? Content

Method

Title

Learner

Staff ~

Environment ~

Activity ~

* Activity-structure ~

+ Play ~

* Conditions ~

Subtitle

Creator

Description

Study-load

Property ~

Property-group ~

* Role ~

? Metadata !

Knowledge-object ~

Knowledge-object-ref ~

Announcement-object ~

Communication-object ~

Tool-object ~

Questionnaire-object ~

Role-information-object ~

Index-search-object ~

Environment ~ !

Environment-ref ~

Metadata !

Obectives

? Prerequisites

Activity-description ~

? Introduction

What

Completed

? Feedback-description

? Metadata !

Activity-sequence ~

Activity-selection ~

? Comment

Then

? Else

Abbildung 3.8: XML-Schema Bindung des EML Rahmenwerkes

ten muss auch die jeweilige Rolle des Benutzers bzw. der Benutzerin angegeben werden.

Dieses k¨

onnen Lernende sein, die sich in beliebig viele Untergruppen aufteilen lassen, oder

Betreuende, die den Lernfortschritt verfolgen. Zudem k¨

onnen das Lernziel sowie Voraus-

setzungen, wie z. B. der notwendige Wissensstand, optimal angegeben werden. Anhand

3.2. FORMALE BESCHREIBUNG VON LERNMATERIALIEN 55

dieser Methode wird der Ablauf des Lernprozesses spezifiziert. Hierzu geh¨

ort beispielswei-

se die Zurodnung der Lernobjekte zu den Rollen. Im Content-Bereich wird der Inhalt durch

Objekte definiert, wie z. B. Verweise auf externe Dateien oder intern formulierte Inhalte,

die aus einer Mischung von DocBook- und HTML-Elementen bestehen. Zudem lassen sich

zahlreiche Lernaktivit¨

aten definieren, anhand derer Studierende aktiv auf die Reihenfolge

des Inhalts eingehen k¨

onnen.

Die durch das EML-Informationsmodell erziehlten Erkenntnisse sind zu einem relevan-

ten Teil in die IMS Learning Design Information Model Spcification [IMS03c] eingeflossen.

3.2.7 Analyse

Die in diesem Abschnitt vorgestellten Markupsprachen zur formalen Beschreibung von

Inhalten sollen in Hinblick auf die eingef¨

uhrten Bewertungskriterien untersucht und aus-

gewertet werden. Zu diesem Zweck werden die in dieser Arbeit geforderten Kriterien Gra-

nularit¨

at und Modularit¨

at in der anstehenden Analyse reflektiert und bewertet.

DocBook ist eine Auszeichnungssprache zum Beschreiben von B¨

uchern und Artikeln.

F¨

ur die Beschreibung von Lerninhalten ist sie jedoch nur bedingt einsetzbar, weil es vor-

wiegend f¨

ur die Erzeugung ganzer B¨

ucher entwickelt wurde und sich der Autor bzw. die

Autorin bei der Dokumenterstellung immer auf das ganze Dokument bezieht. Zudem be-

sitzt die DocBook DTD ca. 400 Elemente, die derart orthogonal entworfen sind, dass sie

dem Anwender bzw. der Anwenderin eine m¨

oglichst flexible Kombinationsvielfalt bieten,

was die Entwicklung eines Parsers erheblich erschwert. Hinzu kommt die Unterst¨

utzung

des Metadatenstandards Dublin Core, der einzelnen Textteilen direkt zugewiesen werden

kann. F¨

ur das in dieser Arbeit verfolgte Ziel ist jedoch die vom Dokument gel¨

oste Me-

tadatendefinition die bessere L¨

osung. Erstens, weil E-Learning-Metadaten ber¨

ucksichtigt

werden m¨

ussen und zweitens, weil die Metadaten in weiteren Verarbeitungsschritten durch

eine Softwareschnittstelle vom Dokument getrennt werden m¨

ussen.

OMDoc ist ein sehr m¨

achtiges Modell zur strukturellen Abbildung mathematischer Do-

kumente. Es eignet sich vor allem f¨

ur den Datenaustausch zwischen Wissenssystemen wie

Computer Algebrasystemen, die spezielle Relationen zwischen mathematischen Elementen

auswerten k¨

onnen. Hinzu kommen p¨

adagogische Elemente, die ein bestimmtes Lernszena-

rio festlegen. OMDoc ist kein allgemeines Strukturmodell f¨

ur Inhalte, das dar¨

uber hinaus

eine derart komplexe Struktur besitzt, dass die Semantik nicht ohne einen gewissen Einar-

beitungsaufwand seitens der Autoren und Autorinnen zu erkennen ist. OMDoc setzt zwar

auf Standards wie OpenMath f¨

ur die Formelrepr¨

asentation, unterst¨

utzt jedoch keinen all-

gemeinen Mechanismus zur Modularisierung, wie es das IMS Content Packaging anbietet.

Die logische Strukturierung, die sich auf Definitionen und Beweise bezieht, f¨

uhrt zu ei-

ner ¨

außerst feingranularen Struktur. Außerdem werden Metadaten nicht vom Dokument

getrennt, sondern den jeweiligen Elementen direkt zugewiesen.

Das Datenmodell der Markupsprache LMML erm¨

oglicht die dom¨

anenspezifische Erwei-

terung mit einer grundlegenden Sprachsyntax zur Formulierung spezialisierter Lerninhal-

te. Dieses ist dann sinnvoll, wenn f¨

ur einen bestimmten Anwendungsbereich spezialisierte

Strukturen ben¨

otigt werden. Ferner erm¨

oglicht das Modell die adaptive Erweiterung von

56 KAPITEL 3. TECHNOLOGIEN

Materialien. Das bedeutet, dass ein f¨

ur ihn oder sie angepasster Schwierigkeitsgrad, ab-

h¨

angig vom Wissensstand des Lernenden durch den Lehrenden eingestellt werden kann.

Leider vermischt LMML ebenso wie OMDoc die Metadaten mit dem Inhalt und es werden

keine E-Learning-Standards unterst¨

utzt. Das Prinzip der Lernobjekte bzw. der Aspekt der

Modularit¨

at wird in diesem Konzept nicht weiter ber¨

ucksichtigt.

EML ist ein umfangreiches Modell zur Gestaltung von Lerninhalten. Der Fokus zielt

in diesem Projekt eindeutig auf die fehlenden p¨

adagogischen Regeln gegenw¨

artiger Stan-

dards. Diese werden um das sogenannte Informationsmodell erweitert, was letztendlich die

Grundlage f¨

ur die IMS Learning Design Information Model Spezifikation gebildet hat.

Die in diesem Abschnitt eingef¨

uhrten Strukturmodelle beschreiben zwar grundlegend

die vom Layout getrennten Inhalte, haben jedoch ihren Fokus eindeutig auf die Imple-

mentierung p¨

adagogischer Konzepte ausgerichtet. Kein Ansatz unterst¨

utzt die modula-

re Konstruktion orthogonaler Kurseinheiten, die beliebig miteinander kombiniert werden

k¨

onnen.

3.3 Lernplattformen – Learning Management Systeme

Lernplattformen bzw. Learning Management Systeme (LMS) sind technische Systeme,

die das institutionelle Lernen ¨

uberhaupt erst erm¨

oglichen. Vor allem Hochschulen, aber

auch Betriebe, setzen zunehmend auf Plattformen, mit denen sie einerseits Lehrinhalte

Studierenden und Mitarbeitern anbieten k¨

onnen und andererseits deren Lernfortschritt

verfolgen und auswerten k¨

onnen. In diesem Sinn liegt die Hauptaufgabe eines LMS nicht

in der Unterst¨

utzung der Konzeption und Entwicklung von Lehrinhalten, sondern viel-

mehr in der Verwaltung von Lernobjekten, Ressourcen und deren Anwendern bzw. An-

wenderinnen. Verf¨

ugt eine Hochschule ¨

uber ein LMS wie Loncapa [LON05], ILIAS [ILI04],

WebCT [WEB05] oder Blackboard [Bla03], so k¨

onnen Dozenten s¨

amtliche Unterlagen wie

Skritpe, ¨

Ubungen, multimediale Inhalte, etc., Studierenden unabh¨

angig von Ort und Zeit

zug¨

anglich machen. Studierende erhalten ein pers¨

onliches Benutzerkonto, das nicht nur

den Benutzerkreis f¨

ur einen bestimmten Kurs einschr¨

ankt, sondern auch die Auswertung

des Lernfortschritts eines jeden Studierenden erm¨

oglicht. Ferner ist es f¨

ur Studierende

m¨

oglich, ¨

uber unterschiedliche Kommunikationskan¨

ale, wie Diskussionsforen, Chats oder

E-Mail, mit anderen Kommilitonen und wissenschaftlichen Mitarbeitern Probleme zu dis-

kutieren und Erfahrungen auszutauschen. Baumgartner hat die Definition einer webba-

sierten Lernplattform wie folgt definiert:

”Unter einer webbasierten Lernplattform ist eine serverseitig installierte

Software zu verstehen, die beliebige Lehrinhalte ¨

uber das Internet zu vermitteln

hilft und die Organisation der dabei notwendigen Lernprozesse unterst¨

utzt

([Baumgartner02], Seite 14).”

Der Schwerpunkt dieser Definition liegt bei der Unterst¨

utzung des Lernprozesses, wie

z. B. Lernflussmanagement. Damit werden einfache Content Management Systeme (CMS),

die zur reinen Erzeugung von digitalen Inhalten dienen, systematisch ausgeschlossen.

3.3. LERNPLATTFORMEN – LEARNING MANAGEMENT SYSTEME 57

Es gibt zahlreiche Anbieter von Lernplattformen mit unterschiedlichen Schwerpunkten

und Auspr¨

agungen. In [Schulmeister03] werden im Rahmen einer Studie zur Evaluation

von Lernplattformen Bewertungskriterien festgelegt, anhand derer sich die Vielzahl un-

terschiedlicher Systeme bewerten l¨

asst. Dieses l¨

asst bereits darauf schließen, dass es keine

glasklare Definition f¨

ur ein LMS gibt, sondern vielmehr einen Anforderungskatalog der

beschreibt, welche Funktionen ein LMS besitzen sollte. Hierf¨

ur werden die folgenden f¨

unf

Kategorien festgelegt:

•Benutzerverwaltung,

•Kursverwaltung,

•Rollen und Rechte,

•Kommunikationsmethoden und Werkzeuge,

•Darstellung von Kursinhalten, Lernobjekten und Medien.

Administration Lernumgebung Authoring

Benutzer

Kurse

Institutionen

Evaluation

Kurse

Kommunikation

Werkzeuge

Personalisierung

Interfacedesign

Lernobjekte

Aufgaben

Tests

Schnittstellen−API

extern intern

Repository−Datenbasis

Administration

Benutzerdaten

Kursdaten

Content Management

Lernobjekte

Metadaten

Abbildung 3.9: Idealtypische Architektur eines Learning Mangement Systems

Nach Schulmeister [Schulmeister03] besteht ein idealtypisches LMS aus genau drei

Schichten (vgl. Abbildung 3.9). In der untersten Schicht, der Datenbankschicht, werden

58 KAPITEL 3. TECHNOLOGIEN

Lernobjekte und die dazugeh¨

origen Metadaten gespeichert. Dieses erm¨

oglicht der dar-

uberliegenden Schicht den Zugriff auf singul¨

are Lernobjekte und sichert deren konsistente

Verwaltung.

Zus¨

atzlich werden administrative Daten wie Benutzerobjekte und Kursinformationen

gespeichert. Damit die Datenbank nicht nur vom LMS benutzt werden kann, bietet die

Schnittstellen-API sowohl interne als auch externe Zugriffsm¨

oglichkeiten an, durch die ex-

terne Applikationen Datenbest¨

ande auswerten k¨

onnen. Die oberste Schicht spaltet sich in

die drei S¨

aulen Administration,Lernumgebung und Authoring auf und bildet die Schnitt-

stelle zum Anwender bzw. zur Anwenderin. Abh¨

angig von der Rolle, mit der sich ange-

meldet wurde, k¨

onnen unterschiedliche Aspekte des LMS genutzt werden. Mit der Rolle

Administration lassen sich neue Benutzer oder Kurse erzeugen. Der Bereich Lernumgebung

bietet Lernenden den Zugang zu Lernobjekten und ¨

offnet dar¨

uber hinaus Kommunikati-

onswege zu anderen Anwendern und Anwenderinnen. Die dritte S¨

aule repr¨

asentiert den

Bereich f¨

ur kreative Aufgaben, wie z. B. das Interface-Design oder die Entwicklung neuer

Lernobjekte.

3.4 Autorenwerkzeuge

Der Abschnitt ¨

uber Learning Management Systeme hat gezeigt, wie Lehrinhalte Studie-

renden angeboten werden und wie Statistiken bzw. Analysen ¨

uber den Lernerfolg eines

Studierenden erstellt werden. F¨

ur die Content-Entwicklung sind diese Systeme jedoch nur

unzureichend geeignet. Einige Plattformen, wie z.B das LMS Ilias, bieten eine Autore-

numgebung an, die die direkte Eingabe von HTML-Seiten erlaubt. F¨

ur die Erstellung

von Inhalten existieren so genannte Autorenwerkzeuge, mit deren Hilfe es m¨

oglich ist, auf

einfache Weise multimediale Inhalte zu erzeugen. Bei n¨

aherer Betrachtung existierender

Inhalte ist eine allgemeine Definition dieses Begriffs jedoch nicht m¨

oglich, weil es unter-

schiedliche Anwendungsf¨

alle f¨

ur den Einsatz von Autorensystemen gibt. Zwei Beispiele

sollen den Unterschied verdeutlichen: Das erste Szenario beschreibt einen Schullehrer, der

bestimmte Inhalte f¨

ur seine Sch¨

uler und Sch¨

ulerinnen multimedial aufbereitet hat und

sie in Form von interaktiven Animationen und Videos pr¨

asentiert. Anschließend findet ei-

ne Multiple Choice-Auswertung am Rechner statt. Diesem behavioristischen Ansatz folgt

das eher konstuktivistische (vgl. Kapitel 2.2) Beispiel eines Physikstudenten, der neben

ausf¨

uhrlichen und hochqualitativen Texten auch virtuelle Experimente durchf¨

uhrt. Aus

diesem Beispiel geht eindeutig hervor, dass es verschiedene Betrachtungsweisen ¨

uber den

zu vermittelnden Inhalt gibt. F¨

unfst¨

uck [F¨

unfst¨

uck00] spricht in beiden F¨

allen von multi-

medialen Anwendungen, teilt sie jedoch in zwei Gruppen auf: den dokumentenbestimmten

Anwendungen und den programmbestimmten Anwendungen. Die bei der dokumentenbe-

stimmten Anwendung formulierte Semantik zeichnet sich durch die zugrundeliegende Do-

kumentenbeschreibungssprache HTML oder XML [Farinetti00] (vgl. Abschnitt 3.2.1) aus.

Interaktionsobjekte geh¨

oren nicht zwangsl¨

aufig zum Dokument und werden zumeist extern

gespeichert. Bei programmbestimmten Anwendungen wird die Semantik und das zugeh¨

ori-

ge Anwendungslayout durch eine Programmiersprache festgelegt. Multimediale Daten sind

3.4. AUTORENWERKZEUGE 59

entweder elementarer Bestandteil der Anwendung und werden als Datenstruktur gespei-

chert oder werden in Dateien abgelegt. F¨

unfst¨

uck beschreibt Multimediale Autorensysteme

wie folgt:

”Autorensysteme erm¨

oglichen die Entwicklung multimedialer Anwendun-

gen in einer grafisch-interaktiven Form unter weitgehendem Verzicht auf die

Programmierung, verwenden hierzu visuelle interface development tools sowie

Werkzeuge zur Erstellung und Bearbeitung von Medien. Sie gehen vom Ent-

wurfsprozeß der Benutzungsoberfl¨

ache aus und unterst¨

utzen die anderen Pha-

sen des Entwicklungsprozesses h¨

aufig nur unvollst¨

andig. Die Vorgehensweisen

sind weniger an herk¨

ommlichen Programmiertechniken ausgerichtet, sondern

beruhen auf einpr¨

agsamen Metaphern und einem leichten Zugang der an Ge-

staltung und Inhalten orientierten Entwickler (aus [F¨

unfst¨

uck00], Seite 16).”

Eine andere Form der Klassifizierung von Autorensystemen richtet sich nach dem not-

wendigen Einarbeitungsaufwand f¨

ur den Benutzer bzw. f¨

ur die Benutzerin. Abbildung

3.10 (aus [Heafele05], Seite 2, [Niegemann03], Seite 266) zeigt f¨

unf verschiedene Klassen

von Autorenwerkzeugen, die im Bezug auf Komplexit¨

at und Benutzbarkeit von links nach

rechts sortiert sind.

Editoren

WYSIWYG−

DevelopmentAutorensysteme

Professionelle Rapid Content

Macromedia

Authorware

Click2Learn

Toolbook

Macromedia

Dreamweaver

NIAM Easy

Generator

Dynamic

Powertrainer

Live

Recording

System

Screen

Movie

Recorder

Lecturnity

Suite

Weblearner

Camtasia

Studio

Viewlet

Builder

Autorenwerkzeuge

Einarbeitungsaufwand

Content Converter

Clix Content

Converter

Abbildung 3.10: Verschiedene Kategorien von Autorenwerkzeugen

Zu der Gruppe professioneller Autorensysteme geh¨

oren Macromedia Authorware

[Mac05] und Click2Learns Toolbook. Diese Autorensysteme z¨

ahlen zu den programmbe-

stimmten Anwendungen, weil sie als Resultat Lehrinhalte, basierend auf interaktiven Vi-

deos produzieren, die keine eindeutige Dokumentenstruktur besitzen. Die zweite Gruppe

umfasst HTML-Editoren, welche ¨

uberwiegend f¨

ur die Produktion von WBT-Inhalten ein-

gesetzt werden. Neben diesen recht kompliziert zu nutzenden Werkzeugen, kann jedoch

auf einfache Alternativen zur¨

uckgegriffen werden. Die Gruppe der Autorenwerkzeuge, die

60 KAPITEL 3. TECHNOLOGIEN

zu schnell entwickelten Inhalten f¨

uhren, wird in dieser Darstellung mit Rapid Content

Development bezeichnet. Dar¨

uber hinaus werden auch Aufnahmesysteme f¨

ur Videopro-

duktionen und Bildschirmaufzeichnungswerkzeuge zum Erstellen von E-Learning-Inhalten

eingesetzt, die in der Regel Zusatzwerkzeuge f¨

ur den Erstellungsprozess sind. Die letzte

Gruppe der Autorenwerkzeuge beschreibt s¨

amtliche Konvertierungswerkzeuge, die z. B.

zur Umwandlung spezieller Dateiformate herangezogen werden.

3.4.1 Ausgew¨

ahlte Systeme

Die Auswahl eines Autorensystems richtet sich subjektiv nach der Einsatzdom¨

ane des

zu erstellenden Materials. Im Schulbereich und im Ausbildungssektor gr¨

oßerer Firmen

werden vorzugsweise multimediale Applikationen (MMA) [F¨

unfst¨

uck00] mit zahlreichen

Videos und Quizumgebungen ben¨

otigt. Im Hochschulbereich hingegen werden eher Do-

kumentbezogene Inhalte eingesetzt, die oft als Erg¨

anzung zu vorhandenen Lehrb¨

uchern

und ausgedruckten Skripten verstanden werden. Aus diesem Grund wird nachfolgend eine

Auswahl kommerzieller sowie wissenschaftlicher Systeme der Gruppen programmbestimm-

te und dokumentbestimmte Autorensysteme verglichen und in Relation zu der in dieser

Arbeit aufgeworfenen Forschungsfrage ausgewertet.

Programmbestimmte Autorensysteme

Abbildung 3.11: Toolbook

3.4. AUTORENWERKZEUGE 61

Toolbook1wartet als erster Vertreter dieser Gruppe mit einer recht interaktiven Schnitt-

stelle zum Benutzer auf. Ziel ist es, multimediale Inhalte durch technisch nicht versierte

Personen zu erstellen, die ¨

uber das Internet Lernenden angeboten werden k¨

onnen. In Ab-

h¨

angigkeit des pr¨

aferierten Lernszenarios, lassen sich unterschiedliche Strukturen f¨

ur einen

Kurs in Form von Templates ausw¨

ahlen, die Kurseigenschaften wie Navigationen, Inhalts-

verzeichnisse oder Tests bestimmen. Jeder Kurs besteht aus einer linearen Folge von Seiten,

die durch den Autor bzw. durch die Autorin frei gestaltet werden. Toolbook bietet eine

Reihe vordefinierter Objekte an, wie z. B. Tests oder Videos, die auf Seiten positioniert

werden. Kurse k¨

onnen als HTML-Seiten exportiert werden und unterst¨

utzen die AICC

und ADL-SCORM Standards.

Mit Authorware 2lassen sich Applikationen und Quizumgebungen erstellen. Diese ba-

sieren auf Macromedia Flash und werden ¨

uber das Internet angeboten. Die Kursstruktur

wird bei Authoreware mit einem Zeichenbrett konstruiert und erm¨

oglicht so einen intui-

tiven Kursaufbau. Um w¨

ahrend der Bearbeitung zu einem speziellen Thema zu gelangen,

kann es außerdem als Navigationshilfe f¨

ur die Entwicklung herangezogen werden. Die ei-

gentlichen Quizzes und Applikationen basieren auf Macromedia Flash und werden durch

die Anordnung multimedialer Objekte sowie Objekte f¨

ur die Ablaufsteuerung frei gestal-

tet. Als Resultat wird ein interaktiv zu steuernder Film generiert. Authorware unterst¨

utzt

ADL-SCROM und bietet f¨

ur die Generierung entsprechende Werkzeuge an.

Ein weiterer Vertreter der programmbestimmten Autorenwerkzeuge ist DazzlerMax3.

Genau wie mit seinen Kontrahenten Authorware und Toolbook k¨

onnen Multimedia Pr¨

sentationen auf einfache Weise erstellt und bearbeitet werden. Jeder Kurs wird in einem

Strukturfenster angezeigt und l¨

asst sich spielend per Drag’n’Drop durch multimeidale Ob-

jekte erweitern. Kurse bestehen aus Sequenzen von Aufgaben, die sich jeweils in Aktionen

und Antworten gliedern. Aktionen sind Abbildungen,Kl¨

ange,Transitionen oder Texte und

f¨

ur den Aufbau einer Szene verantwortlich. Antworten, die ebenso zu einer Aufgabe geh¨

ren, beschreiben das Verhalten des Lernsystems, ausgel¨

ost durch das interaktive Einwirken

des Benutzers bzw. der Benutzerin.

Dokumentbestimmte Autorensysteme

Als erster Vertreter der dokumentbestimmten Autorensysteme wird Macromedia Dream-

weaver MX 4vorgestellt. Dreamweaver wurde als klassischer HTML-WYSIWYG Editor

entwickelt, dem eine umfangreiche Erweiterung f¨

ur multimediale Inhalte beigesteuert wur-

de. Neben den ¨

ublichen Funktionen eines HTML-Editors, (Einf¨

ugen von Hyperlinks, Gra-

fiken oder Framesets) unterst¨

utzt Dreamweaver ebenso das Erstellen von dynamisierten

Seiten wie z. B. Active-Server-Pages (ASP). Zudem k¨

onnen Flashfilme in bestehende Seiten

eingebunden werden, was durch das gemeinsame Ausliefern mit Macromedia Authorware

eine gute Kombination einer dokumentbasierten und programmbasierten Entwicklungs-

1Quelle: http://www.sumtotalsystems.com/ (29.10.2005)

2http://www.macromedia.com/software/authorware/ (29.10.2005)

3http://www.dazzler.net/ (29.10.2005)

4http://www.macromedia.com/ (29.10.2005)

62 KAPITEL 3. TECHNOLOGIEN

Abbildung 3.12: Authorware

umgebung ergibt. Mit Macromedia MX lassen sich auch Lernobjekte (vgl. Abschnitt 2.4)

erzeugen. In Cuthbert [Cuthbert02] wird detailliert beschrieben, wie die Erzeugung von

Lernobjekten mit Dreamweaver stattfindet. Hierbei ist die Curriculum-Entwicklung ein

mehrstufiger Prozess eines Teams, bestehend aus Curiculum Designer,Flash Specialist,

Interface Designer und Database Specialist. Je nach Kompetenz fallen verschieden Auf-

gaben, wie z. B. die Assetentwicklung oder die Gestaltung eines Designs, das auf der

eben vorgestellten Rolle beruht. Abbildung 3.4.1 zeigt die Designansicht von Macromedia

Dreamweaver.

Microsoft hat mit dem LRN-Toolkit 5ein Werkzeug entwickelt, das die Erstellung von

IMS kompatiblen Paketen erm¨

oglicht. Hierzu wird auf der linken Seite der Programman-

sicht das Manifest des Dokuments als Baumstruktur angezeigt, das interaktiv mit Assets

verkn¨

upft werden kann. Hierbei k¨

onnen auch Untermanifeste angelegt und von einem Item

eines auf h¨

oherer Ebene definierten Manifests referenziert werden. LRN unterst¨

utzt sowohl

das kopierende Einbinden von Assets sowie das Einf¨

ugen referenzierter Assets, die ¨

uber

eine URL eingebunden oder an einer festgelegten Stelle im Dateisystem abgelegt werden.

Der exportierte Kurs wird dann mit Hilfe des Internet-Explorers angezeigt, wobei ein ¨

uber

Stylesheets einstellbarer Rahmen generiert wird. Das LRN-Toolkit ist also ein Werkzeug

zum Zusammenschn¨

uren von IMS kompatiblen Paketen mit dem Ziel, sie reibungslos in

ein LMS zu integrieren.

5http://www.microsoft.com/elearn/ (29.10.2005)

3.4. AUTORENWERKZEUGE 63

Abbildung 3.13: Macromedia Dreamweaver MX

Das Passauer Knowledge Management System (PaKMaS) [S¨

uß00] ist zugleich ein Au-

torensystem und eine Benutzerumgebung, die auf der bereits vorgestellten Auszeichnungs-

sprache Learning Material Markup Language (LMML) (vgl. Abschnitt 3.2.5) basiert. Es

unterst¨

utzt die Erstellung von Lern- und Lehrmaterialen bestehend aus einer Menge un-

tereinander vernetzter Wissensmodule. Das System kombiniert ein XML-Content Mana-

gement System mit einem adaptiven Lernsystem. Ein wesentlicher Kernpunkt ist die in-

dividuelle Adaptierbarkeit von Wissensmodulen durch den Nutzer bzw. die Nutzerin f¨

einen speziellen Lernzweck. Zudem werden auch Funktionalit¨

aten von Learning Manage-

ment Systemen (LMS) bereitgestellt (vgl. Abschnitt 3.3), wie z. B. die f¨

ur ein LMS gefor-

derten Kommunikationsmethoden E-mail, News und Chat. Ein wichtiges Merkmal dieser

Architektur ist die Trennung zwischen Inhalt und Visualisierung. Hierbei werden Inhalte

durch XSLT 3.2.1 in verschiedene Ausgabeformate ¨

ubersetzt. Ein weiterer wichtiger Bei-

trag ist die Vernetzung der Wissenseinheiten und die daraus resultierende Orientierung f¨

Dozenten und Lernende innerhalb des Systems. Lernpfade werden durch Dozenten vorge-

schlagen, k¨

onnen jedoch durch Lernende dynamisch modifiziert und an ihre Bed¨

urfnisse

angepasst werden. Neben diesen sogenannten gef¨

uhrten Touren werden dar¨

uber hinaus

auch herk¨

ommliche Strukturierungen nach Kapiteln und Abschnitten angeboten.

64 KAPITEL 3. TECHNOLOGIEN

3.4.2 Analyse

Die in diesem Abschnitt vorgestellten Autorensysteme geben gewiss keinen vollst¨

andigen

Uberblick ¨

uber alle g¨

angigen Systeme, die zurzeit in der Wirtschaft verbreitet sind oder

an denen wissenschaftlich entwickelt wird. Allerdings werden die weitgehenden Einsatz-

m¨

oglichkeiten und der damit zusammenh¨

angende Bedarf anschaulich demonstriert.

Die erste Kategorie, die Gruppe der programmgesteuerten Systeme, erm¨

oglicht vor

allem die Entwicklung interaktiver Animationen und Sequenzen, die durch den Anwen-

der bzw. durch die Anwenderin frei aufgebaut werden und im Regelfall ein individuelles

Programm liefern, ¨

ahnlich wie bei der Erstellung eines Films. Authorware erzeugt z. B.

einen Flash-Film, der mit Hilfe des Macromedia Flash-Plugins f¨

ur nahezu jeden Brow-

ser anzeigbar ist. Die entstehenden interaktiven Videos werden durch den Benutzer bzw.

durch die Benutzerin interaktiv gesteuert, wodurch ein chronologischer Ablauf entsteht,

der u.a. die Visualisierung von 2-D Transitionen auf Objekten erm¨

oglicht. Die strukturelle

Kursdefinition oder sogar die formale Auszeichnung von Inhalten ist hierbei jedoch nicht

gew¨

unscht und wird auch nicht unterst¨

utzt. Diese Art von Autorensystemen sieht es grund-

s¨

atzlich nicht vor, modulare Kurse zu erzeugen, die sich frei kombinieren lassen und somit

eine autoren¨

ubergreifende Entwicklung erm¨

oglichen. Auch das Einbeziehen bestehender

Kursmaterialien ist in diesen Systemen nicht vorgesehen, wenn von einer Microsoft-OLE-

Integration abgesehen wird. Interessanterweise unterst¨

utzen diese Werkzeuge allesamt den

SCORM 1.2 Standard und scheinen dadurch strategisch am Markt positioniert zu sein. Bei

n¨

aherer Betrachtung zeigt sich jedoch, was bereits aus der bloßen Strukturierung der Kur-

se hervorgeht: es werden lediglich die IMS-Ressourcen mit den eingebundenen Videos und

Flash-Filmen versehen. Aufgrund der faktisch nicht vorhandenen Kursstruktur kann sie

beim Exportieren naturgem¨

aß nicht erzeugt werden, obwohl das Resultat in Verbindung

mit Learning Management Systemen (LMS), die bem¨

uht sind aus den SCORM-Paketen

eine dem Kurs entsprechende Struktur zur Navigation aufzubauen, zwar kompatible ist,

aber keineswegs im Sinn der Standards ist.

Um Antworten f¨

ur die in dieser Arbeit aufgeworfenen Fragestellungen zu finden, lie-

fert eine Betrachtung der zweiten Kategorie, der Gruppe der dokumentgetriebenen Sy-

steme, erheblich mehr Aufschluss. Im Gegensatz zu den programmgetriebenen Systemen

werden in dieser Gruppe Dokumente anstatt Videos und Animationen durch das Auto-

rensystem produziert. Der große Unterschied beider Gruppen liegt darin, dass es keine

chronologische Abh¨

angigkeit einzelner Lernsequenzen gibt und Inhalte in der Regel ei-

ne innere Struktur aufweisen. Dieses wird bei Macromedia Dreamweaver ersichtlich. Der

HTML-Editor mit multimedia extension (MX) erm¨

oglicht die Erstellung dokumentbasier-

ter Inhalte. Leider wird hierbei die Visualisierung nicht vom Inhalt getrennt, was das

kooperative Arbeiten oder zumindest die substanzielle Wiederverwendung nicht m¨

oglich

macht. Zwar k¨

onnen Stylesheets ausgetauscht werden, eine absolute formatunabh¨

angi-

ge Repr¨

asentation und eine entsprechende Modularisierung wird jedoch nicht angeboten.

Zwar wird die Curriculum-Entwicklung von Teams verfolgt, allerdings handelt es sich hier-

bei um ein Team mit disjunkten Aufgabengebieten, wie z. B. die Layoutentwicklung oder

das Entwickeln von Flash-Quizzes. Die Entwickler und Entwicklerinnen kommunizieren

3.4. AUTORENWERKZEUGE 65

uber definierte Schnittstellen und kommen sich fachlich, im Gegensatz zu dem in dieser

Arbeit verfolgten Ziel der gemeinsamen Entwicklung, nicht nahe.

Im Gegensatz zu diesem Ansatz konzentriert sich das LRN-Toolkit lediglich auf die

Struktur von Lerninhalten. Der auf der IMS Content Package Spezifikation basierende

Inhalt setzt dabei kein bestimmtes Format voraus, sondern erlaubt das Zusammenstellen

beliebiger Inhalte. Das Werkzeug unterst¨

utzt zwar die modulare Kursentwicklung, ver-

bietet jedoch die konsistente Kombination von Kursteilen verschiedener Autoren und das

Zusammensetzen zu einem heterogenen Kurs. Das Passauer Knowledge Management Sy-

stem stellt zugleich ein Autorenwerkzeug und eine Lernumgebung f¨

ur Studierende bereit.

Der besondere Fokus dieses Systems liegt auf den adaptiven Wissensmodulen, die nicht

nur von Lehrenden sondern auch von Studierenden in Abh¨

angigkeit von ihrer Qualifika-

tion und ihrem Wissensstand angepasst werden k¨

onnen und auf diese Weise individuelle

Lernpfade generieren. Obwohl dieses auf wissenschaftlichen Arbeiten beruhende System,

aufgrund seiner stark auf adaptive Lernsysteme ausgerichteten Funktionalit¨

at, ein anderes

Ziel verfolgt, wurden in Bezug auf die dom¨

anenspezifische und formale Datenmodellierung

interessante Erkenntnisse gewonnen, die in dieser Arbeit ber¨

ucksichtigt werden m¨

ussen.

Die Ergebnisse sind in Tabelle 3.2 noch einmal ¨

ubersichtlich zusammengefasst.

66 KAPITEL 3. TECHNOLOGIEN

System Formatierbarkeit Modularit¨

at Granularit¨

at Nachhaltigkeit Wiederverwend-

barkeit

Kooperation

Programmbestimmt

Toolbook Freie Layoutgestaltung im Po-

werpoint Stil

Keine modulare

Kursstruktur

Erstellung kom-

pletter Inhalte

AICC, SCORM

1.2 (nur Res-

sourcen)

Inkompatible zu

Dokumenten,

Unterst¨

utzt aber

OLE-Objekte

Kooperative

Konstruktion

wird nicht

unterst¨

utzt

Macromedia Aut-

horware

Unterst¨

utzt die Erstellung von

interaktiven Flash-Filmen f¨

Quiz-Umgebungen, jedoch nicht

die formale Beschreibung von

Inhalten

Keine modulare

Verarbeitung von

Inhalten

Erstellung kom-

pletter Inhalte

Standard-

kompatibel

durch SCORM

1.2

Wiederver-

wendung beste-

hender Inhalte

wird nicht unter-

st¨

utzt

Kooperative

Konstruktion

wird nicht

unterst¨

utzt

DazzlerMax Strukturierung durch Platzie-

rung von Aktionen und Antwor-

ten

Nur Entwicklung

kompletter Kurse

Granularit¨

auf Aufgaben-

Ebene

IMS und

SCORM 1.2

kompatibel

Bestehende In-

halte k¨

onnen

nicht eingebun-

den werden

Kooperation

nicht m¨

oglich

Dokumentbestimmt

Dreamweaver MX Unterst¨

utzt die Erstellung von

Webseiten und interaktiven

Flash-Filmen jedoch nicht die

Trennung zwischen Inhalt und

Darstellung

Template-

mechanismus

unterst¨

utzt

Entwicklerteams

Erstellung kom-

pletter Curricu-

Standard-

kompatibel

durch SCORM

1.2

Wiederver-

wendung beste-

hender Inhalte

wird nicht unter-

st¨

utzt

Teamarbeit

wird nur

durch Ar-

beitszuweisung

unterst¨

utzt

Microsoft LRN Das LRN Toolkit ist ein Werk-

zeug zum Erstellen von Content

Packages mit beliebigen For-

maten. Hierdurch wird nur die

Struktur festgelegt und nicht

die Inhalte

Modulare Ag-

gregation von

Assets, HTML-

Seiten und

Applikationen

Nicht einge-

schr¨

ankt

IMS Con-

tent Package

kompatibel

Aggregation be-

liebiger Formate

Nicht unter-

st¨

utzt

Passauer Knowled-

ge Management Sy-

stem

Unterst¨

utzt semantische Aus-

zeichnungen mit LMML

Speichert Wis-

sensmodule in

Datenbanken

Frei w¨

ahlbare

Granularit¨

Standards wer-

den nicht unter-

st¨

utzt

Integration

verschiedener

Dokumenttypen

auch anderer

Autoren

Kooperative

Konstruktion

wird nicht

unterst¨

utzt

Tabelle 3.2: Gegen¨

uberstellung der analysierten Systeme

Kapitel 4

Bewertung

In diesem Abschnitt findet die abschließende und zusammenfassende Bewertung aktueller

wissenschaftlicher Arbeiten und Technologien statt.

Der Abschnitt Lernparadigmen hat gezeigt, dass es drei grundlegende Paradigmen (vgl.

Abschnitt 2.2.2) zur Wissensvermittlung gibt. Obwohl eine Reihe von Lernprogrammen

existieren, die gerade auf eine Wissensvermittlung, basierend auf dem behavioristischen

Paradigma anhand von Multiple-Choice-Tests setzen, wird in dieser Arbeit ein generel-

ler Ansatz pr¨

aferiert, der Autoren und Autorinnen keine Einschr¨

ankungen bez¨

uglich des

Paradigmas vorgibt.

Die E-Learning-Standards bieten bereits L¨

osungsans¨

atze f¨

ur einige Teilprobleme dieser

Arbeit an. So umfasst beispielsweise der SCORM-Standard und die IMS-Spezifikation (vgl.

Abschnitt 2.3) ein Modell zur Gruppierung und Strukturierung von Kursen, inklusive der

enthaltenen Assets. Durch diese generelle Struktur k¨

onnen beliebige Kurse in ein Format

uberf¨

uhrt werden, welches kompatibel zu anderen Systemen ist, insbesondere zu Learning

Management Systemen. Dieses f¨

ordert neben der Kompatibilit¨

at auch die Nachhaltigkeit

von Lerninhalten. Bei der Analyse der Autorensysteme hat sich herausgestellt, dass Kur-

se, die keine eigene Struktur aufweisen, trotzdem durch die Standards abgebildet werden

k¨

onnen. Zwar werden die Standards in diesem Fall ausschließlich zum Datenaustausch

verwendet, jedoch besitzen sie aufgrund ihrer Aggregationsf¨

ahigkeit eine Eigenschaft, die

zu einer m¨

achtigen Datenstruktur f¨

ur die programminterne Repr¨

asentation von Lerninhal-

ten f¨

uhrt. Die Kriterien Modularit¨

at und Granularit¨

at k¨

onnen unter Ber¨

ucksichtigung der

Standards mit in die Modellierung einfließen. Die Begriffe Modularit¨

at und Granularit¨

werden ebenso f¨

ur Lernobjekte (vgl. Abschnitt 2.4) auf theoretische Weise beleuchtet.

Mit der Einf¨

uhrung von Metaphern wird versucht, ein allgemeines Verst¨

andnis f¨

ur den

Aufbau gut strukturierter Inhalte zu erarbeiten. Vor allem geht es – wie sich bereits in

anderen Disziplinen gezeigt hat – um eine verbesserte Nutzung bestehender Ressourcen,

also um deren Wiederverwendung. Vergleiche mit der Bauindustrie haben gezeigt, dass

heute Lernmaterialien oft neu entwickelt und bestehende Inhalte nicht gen¨

ugend weiter

genutzt werden. In der Bauindustrie, wo bereits vor Jahren Standards und Normen festge-

legt wurden, werden gleiche Hauskomponenten von verschiedenen Herstellern konstruiert

und kombiniert.

68 KAPITEL 4. BEWERTUNG

F¨

ur die Konstruktion von Lerneinheiten ist die Ber¨

ucksichtigung der modularen und

granularen Gestaltung ein ¨

außerst wichtiges Ziel. Denn nur so k¨

onnen einzelne Komponen-

ten aus Kursen entnommen und wiederum in andere Kurse eingebettet werden. Die Ana-

lyse der Autorensysteme (vgl. Abschnitt 3.4.2) hat jedoch gezeigt, dass bis auf das LRN-

Toolkit keins der vorgestellten Systeme eine wie von Hodgins und Downes (vgl. Abschnitt

2.4.1) vorgeschlagene modulare Struktur anbieten. Zwar gibt es Bem¨

uhungen, diese The-

orien mit aktuellen Autorensystemen zu koppeln (vgl. Abschnitt 3.4.2 und [Cuthbert02]),

wobei einem ¨

uber die Jahre entstandenen System sicherlich nicht einfach postum ein neues

Konzept angehaftet werden kann. Hinzu kommt, dass die bis jetzt unternommenen Bem¨

hungen bei der Umsetzung der Metaphern lediglich die Aspekte der modularen Strukturie-

rung aufgreifen. Das Problem, dass Inhalte ebenso thematisch zu anderen Inhalten passen

m¨

ussen, wurde bis jetzt v¨

ollig außer Acht gelassen.

Die Kategorie Wiederverwendung bezieht sich nicht nur auf entwickelte Lernobjekte,

sondern ebenso auf Ressourcen, die bereits mit anderen konventionellen Systemen, wie z.

B. Latex oder Office-Produkten, studienbegleitend entwickelt wurden. Gerade die partielle

Wiederverwendung solcher Inhalte ist ein wichtiger Aspekt dieser Arbeit. Die Slicing Book

Technik und die im ITO-Projekt entwickelten Abbildungsverfahren (vgl. Abschnitt 3.1),

liefern interessante Aspekte, die im n¨

achsten Kapitel konzeptionell aufgegriffen werden.

Die Notwendigkeit, Inhalte von ihrer Darstellung zu trennen, wird immer h¨

aufiger bei

der Entwicklung von E-Learning-Systemen ber¨

ucksichtigt. Hierbei werden im Besonde-

ren zwei Ziele verfolgt: Inhalte werden mit einem einfachen Dokumentparser maschinell

eingelesen und verschiedene Ausgabeformate werden generiert. Das DocBook-Format ist

beispielsweise ein Vertreter der Markupsprachen, das f¨

ur die Erstellung technischer Do-

kumentationen eingesetzt wird, die unabh¨

angig von einem Zielformat formuliert werden.

Im Gegensatz dazu ist OMDoc ein generisches Austauschformat f¨

ur mathematische In-

halte. Leider unterliegen die vorgestellten Sprachen, wie z. B. EML, einem zu starken

p¨

adagogischen Einfluss, so dass modulare Strukturen nur unzureichend ausgepr¨

agt sind.

Die Begriffe Lernplattformen und Autorensysteme sind nicht eindeutig definiert, weil

sie je nach Anwendungszweck unterschiedliche Dienste anbieten oder auf unterschiedli-

chen Konzepten basieren (vgl. Abschnitt 3.4 und 3.3). Die Auswertung dieser Systeme

hat ergeben, dass kein aufgef¨

uhrtes System die in Kapitel 1 geforderten Eigenschaften

implementiert. Insbesondere der kooperative Entwicklungsprozess, der gerade bei der Ent-

wicklung interdisziplin¨

arer Inhalte notwendig ist, wird nicht ber¨

ucksichtigt.

Abschließend ist festzuhalten, dass die theoretischen Modelle viel Potential f¨

ur die

Konzeption eines modularen E-Learning-Systems liefern, es bislang jedoch nicht ausge-

nutzt wurde. Aus diesem Grund besteht der Bedarf ein technisches Modell zu entwickeln,

welches erstmals zus¨

atzlich zu der Struktur von Kursen auch deren Inhalte im Sinne der

Metaphern formal als Lernobjekte modelliert, um die zu Beginn dieser Arbeit aufgeworfe-

nen Fragestellungen zu l¨

osen. Folglich sollen Lernobjekte f¨

ur E-Learning-Systeme ¨

ahnliche

Eigenschaften wie Pr¨

asentationsfolien in PowerPoint besitzen. Folien von anderen Autoren

lassen sich bequem und mit geringem Aufwand in den eigenen Vortrag einbinden, da sie

an das Layout und die Struktur des neuen Vortrags durch das System angepasst werden.

Teil II

Modellierung und Umsetzung

Kapitel 5

Ein Modell zur Entwicklung

konsistenter Lernmaterialien

In diesem Kapitel wird ein technisches Modell vorgestellt, das als Grundlage f¨

ur die Kon-

zeption von E-Learning-Systemen dient, bei denen Kooperation und Interdisziplinarit¨

im Vordergrund steht. Das Modell beschreibt die hierf¨

ur notwendige Kursstrukturierung,

um eine optimale Kompatibilit¨

at mit anderen Kursen zu erreichen. Zuerst wird das Bauka-

stenprinzip er¨

ortert, welches im Rahmen des mαth-kit Projekts entstanden ist, und dessen

Komponenten vorgestellt. Nach diesem ¨

Uberblick findet eine detaillierte Betrachtung der

jeweiligen Komponenten statt, bei der technische Realisierungsvorschl¨

age pr¨

asentiert wer-

den.

Der zweite wesentliche Aspekt des Modells befasst sich mit der Verarbeitung bereits in

digitaler Form vorliegender Lehrinhalte, sowie mit der Entwicklung von Lehrinhalten f¨

unterschiedliche Lehrformen, wie z. B. dem Pr¨

asenzunterricht oder dem Selbststudium.

Im letzten Abschnitt wird gezeigt, wie das Modell f¨

ur ein kooperativ arbeitendes Team,

bestehend aus Entwicklern f¨

ur E-Learning-Inhalte, genutzt werden kann.

5.1 Das Baukastenprinzip

Das Ziel, das im Projekt mαth-kit verfolgt wurde, war die Entwicklung eines multimedia-

len Baukastens f¨

ur die Mathematikausbildung im Grundstudium. Der Aspekt des Bauka-

stens wurde als Metapher f¨

ur die Konzeption eines Modells gew¨

ahlt [Bungenstock02], um

eine allgemeine Leitidee sowohl f¨

ur Entwickler und Entwicklerinnen als auch f¨

ur Anwen-

der und Anwenderinnen zu vermitteln. Das Baukastenprinzip basiert auf den in Kapitel

2.4.1 vorgestellten Metaphern und erweitert die dort vorgestellten Ideen um eine zentrale

Verwaltungsstelle f¨

ur Lehrinhalte, das Baukastensystem, sowie ein einheitliches Erschei-

nungsbild. Hierbei wird der Frage nachgegangen, was mit einer Konstruktionen nach ihrer

Fertigstellung geschieht. Diese beiden Aspekte beziehen sich vor allem auf die zu Beginn

dieser Arbeit aufgeworfenen Fragestellungen nach kooperativer Konstruktion und dem

damit verbundenen Problem einer konsistenten Pr¨

asentation.

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

5.1.1 Bausteine

Zentraler Begriff des Baukastenprinzips ist der Baustein. Ein real existierender Bauka-

sten besteht aus einer Sammlung unterschiedlicher Baukl¨

otze. Sie unterscheiden sich in

ihrer Form und Farbe und k¨

onnen unter Ber¨

ucksichtigung physikalischer Gesetze vielseitig

zusammengesetzt werden. Ein Baukasten enth¨

alt zumeist mehrere Exemplare eines Bau-

steins, die hinsichtlich ihrer Form gleiche Eigenschaften besitzen. Dieses k¨

onnen z. B. Kegel,

Zylinder oder Quader sein. Bausteine identischer Form m¨

ussen jedoch nicht zwangsl¨

aufig

die gleiche Farbe besitzen. W¨

ahrend der Konstruktion komplexer Bauwerke wird zumeist

versucht, diejenigen Bausteine zusammenzusetzen, die auch optisch zueinander passen.

Entsprechend der Leitidee nach Hodgins und Willy (vgl. Abschnitt 2.4) besitzt der

primitive Baustein zun¨

achst die Eigenschaft mit anderen Bausteinen kompatibel zu sein

und in beliebiger Weise miteinander kombiniert werden zu k¨

onnen:

•Jeder Baustein ist kompatibel mit jedem anderen,

•Bausteine k¨

onnen in beliebiger Weise zusammengesetzt werden,

•Bausteine sind so einfach aufgebaut, dass sie von jedem zusammengesetzt werden

k¨

onnen.

Zu diesen drei formalen Eigenschaften m¨

ussen weitere Regeln festgelegt werden, nach

denen festgestellt werden kann, ob es sinnvoll ist, Bausteine ¨

uberhaupt zusammenzusetzen.

Die folgenden Regeln m¨

ussen w¨

ahrend der Konstruktion zus¨

atzlich ber¨

ucksichtigt werden:

•Jeder Baustein soll auch optisch zu anderen passen,

•Konstruktionen sollten m¨

oglichst stabil sein,

•Bausteine sollen kontextfrei sein.

Diese Regeln erscheinen auf den ersten Blick trivial und werden intuitiv angewen-

det. Wie verhalten sich jedoch Entwickler bzw. Entwicklerinnen von realen E-Learning-

Systemen? Werden diese Regeln bei der Entwicklung komplexer E-Learning-Systeme be-

achtet und wie sehen Kurse strukturell aus, die aus mehreren Lernobjekten verschiedener

Entwickler zusammengesetzt werden? Der SCORM und IMS Standard (vgl. Kapitel 2.3)

bieten zwar eine technische L¨

osung zum Archivieren bestehender Inhalte an, die es jedem

Kursfragment erm¨

oglicht, ganz gleich wie es intern strukturiert ist, mit anderen Kursen

kombiniert zu werden, legen damit aber eine neue Form f¨

ur den Baustein fest. Lernmate-

rialien bestehen h¨

aufig aus unterschiedlichen Dateiformaten, wie z. B. Flash-Filmen oder

PDF-Dokumenten und besitzen damit eine grundlegend unterschiedliche interne Struktur

und Pr¨

asentation. Werden sie einfach zusammengef¨

uhrt, fehlen gerade die in dieser Arbeit

wichtigen Aspekte der konsistenten Kursstruktur und die einheitliche Pr¨

asentation. An-

statt die Lernmaterialien einfach einzupacken, sollte vielmehr ein generelles Zwischenfor-

mat entwickelt werden, das dem Kursentwickler bzw. der Kursentwicklerin die Verwendung

optimal zusammenpassender Bausteine erm¨

oglicht. Abbildung 5.1 zeigt exemplarisch einen

5.1. DAS BAUKASTENPRINZIP 73

generischen Baustein, der unabh¨

angig formuliert ist und je nach Bedarf des Lehrenden auf

ein f¨

ur ihn zutreffendes Pr¨

asentationsformat abgebildet werden kann. Das Beispiel zeigt

einen Baustein, bestehend aus dem Inhalt, den zugeh¨

origen Abbildungen und einer Anima-

tion. Dieser wird f¨

ur eine Online-Pr¨

asentation, abh¨

angig von den gestalterischen Aspekten,

die von einem zugeh¨

origen Kurs vorgegeben wird, auf zwei verschiedene HTML-Versionen

abgebildet. Ebenso soll eine druckbare Version f¨

ur eine Pr¨

asenzveranstaltung angefertigt

werden. Hierf¨

ur muss der Baustein in ein Dokumentformat, in diesem Beispiel das Por-

table Document Format (PDF), ¨

uberf¨

uhrt werden, um es ggf. in ein bereits existierendes

Skript einzuflechten.

AnimationAbbildung Abbildung

Abbildung Abbildung Animation Animation

PDF

Abbildung AnimationAbbildung

HTML

Inhalt

HTML

Presentation 1

Generischer Baustein

Präsentation 3Präsentation 2

Format A Format B

Abbildung 5.1: Basisformat f¨

ur Lernbausteine

5.1.2 Kurse

Kurse entsprechen in der Analogie eines Baukastens, den entwickelten Bauwerken, oder

auch Modellen bestehend aus einer Vielzahl von Bausteinen. Dem Baukasten liegt in der

Regel eine Anleitung mit Konstruktionshinweisen bei. Sie kann Angaben ¨

uber die Anord-

nung der Bausteine und deren Typ enthalten. Anhand des Bauplans wird dem Geb¨

aude

eine gewisse Struktur auferlegt, mit der der Konstrukteur bzw. die Konstrukteurin ent-

scheiden kann, welche Bausteine dem Baukasten zu entnehmen sind. Nun kann es vor-

kommen, dass entwickelte Bausteingruppen – aufgrund von Symmetrieeigenschaften eines

Bauwerks – mehr als einmal verwendet werden. Wenn das Bauwerk fertig konstruiert ist,

kann es je nach Bedarf fixiert und ggf. lackiert werden. Dieser Zustand verhindert zwar,

dass die verwendeten Bausteine f¨

ur andere Konstruktionen eingesetzt werden k¨

onnen, fi-

xiert jedoch das Gesamtresultat.

E-Learning-Systeme verwenden – wie bereits in Abschnitt 3.4 gezeigt – ganz unter-

schiedliche Kursstrukturen. Die Spanne reicht von Videosequenzen, die Studierende in-

teraktiv steuern, ¨

uber sequenzielle Abfolgen von Kursfragmenten und hierarchisch aufge-

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

bauten Kursen bis hin zu vernetzten personalisierten Kursstrukturen. Um f¨

ur eine solche

Vielfalt ein kompatibles Austauschformat zu entwickeln, das Learning Management Sys-

temen die Verarbeitung beliebiger Kurse erm¨

oglicht, wurde der SCORM-Standard und

die IMS-Content Package Specification entwickelt (vgl. Abschnitt 2.3.1). Das dort ent-

worfene hierarchische Modell f¨

ur E-Learning-Kurse bietet sich f¨

ur die Strukturierung von

Kursen geradezu an, da es neben der Verwaltung ganz normaler Kursstrukturen auch das

Einbinden von Subkursen unterst¨

utzt.

Inhalt Inhalt

Inhalt

Animation

Video 1 Applet

Viedo 2Abbildung 2Abbildung 1

HTML 1 HTML 2 HTML 3

Video 1 Viedo 2 Applet Abbildung 1

Abbildung 2 Animation

Animation Video 1 Viedo 2

Baustein A

Baustein B

Baustein C

Baustein B

Baustein C

Baustein A

Kursstruktur Generischer Kurs

PDF

Format A

Presentation 1 Präsentation 3

Format B

Abbildung 5.2: Basisformat f¨

ur Kurse

Die in Abschnitt 5.1.1 eingef¨

uhrten Lernbausteine m¨

ussen durch eine Kursstruktur

zusammengesetzt werden. Abh¨

angig vom gew¨

unschten Ausgabeformat wird diese Struktur

auf ein Format abgebildet, welches dem eigentlichen Lernmaterial entspricht. Abbildung

5.2 zeigt exemplarisch die Zusammenstellung der drei Lernbausteine A, B und C. Baustein

B ist den Bausteinen A und C hierarchisch ¨

ubergeordnet und befindet sich in der zu

generierenden Kursstruktur auf der dar¨

uber liegenden Ebene. Aufgrund der Kursstruktur

und der Inhalte der Bausteine ist es nun m¨

oglich, aus der universellen Kursstruktur einen

kompletten Kurs zu generieren, mit einer konsistenten Struktur und einer einheitlichen

Darstellungsform.

5.1.3 Prozess

Bei der Entwicklung von E-Learning-Inhalten werden unterschiedliche Fachkompetenzen

ben¨

otigt, die in der Regel nicht nur bei einer Person liegen. So f¨

allt beispielsweise die Zu-

5.1. DAS BAUKASTENPRINZIP 75

sammenstellung und die Auswahl von studienbegleitenden Lernmaterialien in den Kompe-

tenzbereich von Professoren und Professorinnen. Die eigentliche Entwicklung von Anima-

tionen, Flash-Filmen und Programmen, wird hingegen oft von studentischen Hilfskr¨

aften

durchgef¨

uhrt. Eine solche Rollenverteilung soll im Folgenden f¨

ur das Baukastenprinzip auf-

gestellt werden. Anhand der festgelegten Rollen soll der Umgang mit dem Baukastensystem

erl¨

autert werden, sowie der sich daraus ergebende Entwicklungsprozess von Lernmateria-

lien. In [Baudry02b,Baudry02a] nehmen die bei der Entwicklung beteiligten Personen

folgende Rollen an.

Teacher: Der Teacher verwendet einzelne Bausteine als Erg¨

anzung zu Pr¨

asenzveranstal-

tungen und Fernlehre. Aufgabe dieser Rolle ist das Suchen und Archivieren von

Lernbausteinen und Kursen.

Student: Der Student arbeitet mit einem Learning Management System (LMS) an ge-

nerierten Kursen. Hierf¨

ur stehen spezielle Lernbausteine zur Exploration und Auf-

gabenbearbeitung zur Verf¨

ugung. Dar¨

uber hinaus k¨

onnen Studierende bei Bedarf

Inhalte nachschlagen und vertiefen, die der Lehrende im Lehrplan nicht explizit vor-

gesehen hat.

Composer: Diese Rolle ist f¨

ur die Kurserzeugung zust¨

andig. F¨

ur einen Kurs m¨

ussen aus-

gew¨

ahlte Bausteine gesucht und zu einem Kurs f¨

ur Studierende zusammengesetzt

werden. Gibt es zu einem Thema keinen geeigneten Baustein um die L¨

ucke zu schlie-

ßen, muss in die Rolle Developer gewechselt werden.

Developer: Der Developer erzeugt multimediale Bausteine und pflegt sie in das Bau-

kastensystem ein. Hierbei m¨

ussen Assets, wie z. B. Applets, Flash-Filme, Texte,

Grafiken und Animationen, erzeugt und zu Bausteinen kombiniert werden. Dar¨

uber

hinaus wird der Inhalt in einem allgemeinen, darstellungsfreien Format definiert und

kann somit anderen Autoren zur Verf¨

ugung gestellt werden.

Publisher: Diese Rolle passt einen zusammengestellten Kurs an die gew¨

unschte Lehr-

veranstaltung an. Kurse k¨

onnen in verschiedene Darstellungen und Ausgabeformate

ubersetzt werden.

Administrator: Diese Rolle unterst¨

utzt w¨

ahrend der Entwicklung die anderen Rollen

und ist f¨

ur den reibungslosen Funktionsablauf des Baukastensystems verantwortlich.

Als Beispiel soll im Folgenden der Entwicklungsprozess und das damit verbundene

Zusammenspiel der Rollen anhand eines Beispiels, das die schrittweise Entwicklung eines

Grundlagenkurses f¨

ur die Technische Informatik veranschaulicht, vorgef¨

uhrt werden. In

Abbildung 5.3 werden zun¨

achst die vier Bausteine Allgemeine Aufgaben,Definition Kom-

plexe Zahlen,Explorationswerkzeug Komplexe Zahlen und Elektrotechnik Aufgaben von

der Rolle Developer erzeugt 1. Um aus ihnen einen Kurs ¨

uber Schaltkreise zu entwerfen,

1Diese Bausteine wurden im Rahmen des mαth-kit Projekts fach¨

ubergreifend erstellt und enthalten

Aufgaben, ¨

Ubungen und Explorationsumgebungen f¨

ur das Thema Komplexe Zahlen. In Kapitel 7.1.3 wird

der Konstruktionsprozess n¨

aher beschrieben.

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Allgemine

Aufgaben

Definition

Komplexe Zahlen

Explorationswerkzeug

Definition

Komplexe Zahlen

Aufgaben

Elektrotechnik

Aufgaben

Elektrotechnik

Kurs

Komplexe ZahlenKurs

Komplexe Zahlen

Kurs

Komplexe Zahlen

Kurs Format C

Format B

Format A

Administrator

Schaltkreise im

Frequenzbereich

Developer

Publisher

Teacher Student

Publisher

Abbildung 5.3: Interaktion der Rollen

werden aus dem Bestand der verf¨

ugbaren Bausteine diejenigen ausgew¨

ahlt, die f¨

ur den zu

erstellenden Kurs von Interesse sind. In diesem Fall nimmt der Composer die Bausteine De-

finition Komplexe Zahlen und Elektrotechnik Aufgaben und kombiniert sie zu einem Kurs.

Der Publisher nimmt diesen Kurs, der sich zu diesem Zeitpunkt in einem Zwischenformat

befindet und nicht von Studierenden oder Lehrenden genutzt werden kann, und transfor-

miert ihn in das gew¨

unschte Ausgabeformat. Dieser Prozess ist vom jeweiligen Lernszenario

abh¨

angig, denn soll der Kurs Studenten studienbegleitend angeboten werden, bietet sich

die Erstellung eines Online-Kurses mit zus¨

atzlichen Aufgaben und Animationen an. Soll

der Kurs jedoch eine Pr¨

asenzveranstaltung begleiten und dort in gedruckter Form verteilt

werden, ist eine Transformation in das PDF-Format eine gute L¨

osung.

5.2 Formatierbare Lernbausteine

Nachdem der Lernbaustein als zentraler Gegenstand des Entwicklungsprozesses in einer

metaphorischen Abbildung eingef¨

uhrt worden ist, wird im Folgenden die Modellierung be-

5.2. FORMATIERBARE LERNBAUSTEINE 77

schrieben. Der Frage nach den Eigenschaften eines allgemeing¨

ultigen Lernbausteins wurde

bereits in der Metapher nachgegangen. Demgegen¨

uber stehen die zu Beginn dieser Arbeit

definierten Ziele Modularit¨

at,Granularit¨

at,Kooperation und Wiederverwendbarkeit.

Die Analysen aus Kapitel 2 haben ergeben, dass es keine Beschreibungssprache f¨

Lerneinheiten gibt, die nicht nur eine modulare Aufteilung erm¨

oglichen, sondern auch we-

sentliche Strukturmerkmale enth¨

alt. DocBook ist z. B. f¨

ur die Definition ganzer B¨

ucher

oder Artikel konzipiert und nicht f¨

ur die Beschreibung kleiner Kursfragmente. Dagegen

hat die Analyse der Auszeichnungssprache OMDoc ergeben, dass sie nicht f¨

ur die Einga-

be großer Dokumente geeignet ist, sondern vielmehr f¨

ur die Definition von Formeln und

mathematischen Regeln.

Ein weiterer Aspekt betrifft die physikalische Strukturierung von Lernbausteinen, ins-

besondere die Verwaltung von eingebundenen Dateien, wie z. B. Videos oder Applets.

Das IMS hat f¨

ur dieses Problem die in Abschnitt 2.3.1 vorgestellte Context Aggregation

Model-Spezifikation entwickelt. Sie regelt das physikalische Speichern von Assets, wie Vi-

deos oder Applets, in einem Lernobjekt. Jedes Paket enth¨

alt ein Manifest, das in einer

XML-Kodierung die Dateien der eingebundenen Ressourcen verwaltet.

Aufbauend auf diesen Erkenntnissen soll in diesem Abschnitt ein Strukturmodell ent-

wickelt werden, mit dem es m¨

oglich ist, Bausteine unterschiedlicher Granularit¨

at zu ent-

werfen, die von anderen Autoren oder Autorinnen ¨

ubernommen werden k¨

onnen. Dieses ist

jedoch nur unter Ber¨

ucksichtigung der in Kapitel 5.1.1 eingef¨

uhrten Regeln zu erreichen.

Aus ihnen l¨

asst sich der folgende technische Bausteinbegriff ableiten:

Ein formatierbarer Baustein (FB) besteht aus einem generellen, dar-

stellungsfreien Dokument beliebiger Granularit¨

at zur strukturierten Speiche-

rung des Inhalts und wird erst in Verbindung mit einem Regelwerk f¨

ur ein

beliebiges Pr¨

asentationsformat zu einem Lernobjekt. Formatierbare Bausteine

besitzen einen definierten Rahmen, der die Aggregation mit anderen forma-

tierbaren Bausteinen erm¨

oglicht.

Abbildung 5.4 zeigt den prinzipiellen Aufbau eines formatierbaren Lernbausteins. Auf

der linken Seite befinden sich Assets, die in einer Dateistruktur verwaltet werden. Je-

der Baustein enth¨

alt einen Satz zugeordneter Assets, in diesem Fall Bild1,Bild2,Applet

und Video, und verf¨

ugt ¨

uber exakt ein Dokument, das die interne Dokumentstruktur des

Bausteins kapselt.

Die Dokumentenstruktur l¨

asst sich als Baum mit einer Wurzel und untergeordneten

Teilb¨

aumen oder Bl¨

attern darstellen. In diesem Beispiel teilt sich das Dokument auf ober-

ster Ebene in eine ¨

Uberschrift und in einen Paragraphen auf. Letzterer enth¨

alt zwei Bilder,

zwischen denen ein Textabschnitt positioniert ist. Die ¨

Uberschrift besitzt ebenfalls einen

Paragraphen, der neben einem Textblock noch eine Tabelle enth¨

alt, die sich ¨

uber die An-

zahl ihrer Zeilen definiert. Die Abbildung beschreibt die Struktur einer Tabelle, die auf der

linken Seite Textbl¨

ocke enth¨

alt und auf der rechten Seite multimediale Elemente. Die Bl¨

at-

ter des Baums, f¨

ur die es im ¨

Ubrigen keine textuelle Entsprechung gibt, sondern lediglich

Bin¨

ardaten, referenzieren die in der externen Struktur verwalteten Dateien.

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Text

Überschrift

Paragraph

Tabelle

Bild1

Text Bild2

ZeileZeile

Spalte SpalteSpalte

Applet Text VideoText

Dokument

Bild1

Bild2

Applet

Video

Formatierbarer Baustein (FB)

Wurzel

Paragraph

Dateistruktur Dokumentstruktur

Abbildung 5.4: Struktur eines formatierbaren Bausteins

5.2.1 Dokumentstruktur

F¨

ur die Strukturierung des Dokuments wurde die Sprache BrickML entwickelt, die eine

Vielzahl an Basiselementen zur formalen Beschreibung anbietet. W¨

ahrend der Entwicklung

hat sich herausgestellt, dass die syntaktische Struktur einfach aufgebaut werden muss,

damit sie sowohl leicht zu erlernen ist und sich gut zum ¨

Uberpr¨

ufen von Fehlern eignet.

Dieses Ziel wird erreicht, indem s¨

amtliche Formatierungseigenschaften nicht Bestandteil

der Dokumentstruktur sind, sondern in einem Regelwerk separat definiert werden.

Wurzelobjekt

Zun¨

achst wird der Wurzelknoten durch das lob-Element (Learning Object) definiert. Er ist

der Einstiegspunkt f¨

ur einen Baustein und enth¨

alt entweder reinen Text oder komplexere

Strukturen, wie Tabellen oder Listen. lob-Elemente besitzen jedoch keine Strukturierungs-

elemente, wie z. B. Kapitel oder Abschnitte, weil sie ausschließlich zur Strukturierung von

Kursen dienen und daher in der Regel thematisch abgeschlossen sind. Aus diesem Grund

wird innerhalb der Bausteine auf solche Elemente verzichtet, damit der zu erzeugende Kurs

konsistent ist und sich Kapitelinformationen innerhalb des Dokuments nicht mit denen der

Kapitelstruktur vermischen.

Der Typ des lob-Elements enth¨

alt mehrere thematisch getrennte Elementgruppen:

textGroup,structureGroup,learnGroup,mathGroup und mediaGroup. Jedes Element

dieser Gruppen kann beliebig oft und in einer nicht spezifzierten Reihenfolge unter einem

lob-Element auftreten. Zudem lassen sich p-Element (Paragraphen) f¨

ur die Definition von

5.2. FORMATIERBARE LERNBAUSTEINE 79

Abs¨

atzen unter einem lob-Element einf¨

ugen. Abbildung 5.5 veranschaulicht die syntakti-

sche Struktur eines lob-Elements.

lob

1..*

structureGroup

learnGroup

mathGroup

textGroup

lobType

mediaGroup

Abbildung 5.5: Syntaktische Struktur des LOB-Elements

Textbl¨

ocke

Der Typ textGroup enth¨

alt Elemente, die haupts¨

achlich zur Auszeichnung von Texten ver-

wendet werden. Dieses sind highlight (zum Hervorheben von Textpassagen) und italic

(zur kursiven Darstellung von Textabschnitten). Sollen Texte unterstrichen werden, k¨

on-

nen sie mit dem underline-Element definiert werden. Hin und wieder sollen Textstellen

jedoch in einen Schreibmaschinen ¨

ahnlichen Schriftstil gesetzt werden. Zu diesem Zweck

existiert das typewriter-Element. Dieses Element spezifiziert zwar die Textformatierun-

gen, legt jedoch nicht ihre genaue Pr¨

asentation fest. Es wird z. B. keine Aussage dar¨

uber

getroffen, wie oft eine Textpassage unterstrichen ist, oder wie die Hervorhebung auszusehen

hat.

Der praktische Einsatz hat ergeben, dass Texte noch weitere Formatierungselemente

ben¨

otigen. Dazu z¨

ahlen Tabulatoren t, Zeilenumbr¨

uche br und Leerzeichen ws. Auch diese

Elemente dienen ausschließlich der Strukturierung und besitzen keine eigene Pr¨

asentations-

form. Des weiteren muss die aus Hypertext bekannte Verkn¨

upfung modelliert werden. Wie

in HTML-Dokumenten ¨

ublich, verweisen Inhalte unter Verwendung des link-Elements auf

andere Hypertext Dokumenten. Weiterhin werden die Elemente anchor und ref ben¨

otigt.

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Sie werden f¨

ur Verweise innerhalb von Bausteinen verwendet und erm¨

oglichen dar¨

uber

hinaus auch eine Referenzierung auf Inhalte anderer Bausteine. Abbildung 5.6 zeigt den

strukturellen Aufbau der Textgruppe.

highlight

textGroup

italic

underline

typewriter

link

code

anchor

ref

Abbildung 5.6: Textgruppe

Strukturen

Das Verfassen einfacher Texte reicht jedoch f¨

ur die Gestaltung von Inhalten meist nicht

aus. Vielmehr werden Elemente, wie z. B. Aufz¨

ahlungen oder Tabellen, ben¨

otigt, die un-

erl¨

asslich f¨

ur den Aufbau von Dokumenten sind. Aus diesem Grund werden in der struc-

tureGroup die Typen f¨

ur Tabellen, Aufz¨

ahlungen, Nummerierungen und ¨

Uberschriften

zusammengefasst. Eine Tabelle besteht aus einer Sequenz beliebig vieler column-Elemente,

5.2. FORMATIERBARE LERNBAUSTEINE 81

die zum einen die Anzahl der Spalten der Tabelle angeben und zum anderen Daten ¨

uber die

Spalten enthalten, wie die Zeilenbreite, gefolgt von einer beliebigen Anzahl row-Elemente.

Letztere enthalten jeweils eine Sequenz von cell-Elementen, deren Eigenschaften, wie

z. B. die Ausdehnung angrenzender Spalten und Zeilen zur Konfiguration dienen. Tabelle

5.1 zeigt die einstellbaren Attribute des col-Elements.

Innerhalb einer Tabellenzelle muss es m¨

oglich sein, Texte und andere strukturelle Ele-

mente einzubinden. Aus diesem Grund schließt der Zellentyp neben dem p-Element, zur

Definition weiterer Paragraphen, auch die Gruppen textGroup,mediaGroup und struc-

tureGroup ein. An dieser Stelle sei angemerkt, dass die Strukturgruppe rekursiv definiert

ist, was eine notwendige Vorraussetzung bei der Erstellung rekursiver Strukturen, wie bei-

spielsweise verschachtelte Tabellen oder verschachtelte Aufz¨

ahlungen, ist. Aufz¨

ahlungen

und Nummerierungen benutzen den gemeinsamen Elementtyp enumerationType. Er er-

laubt das Einbinden beliebiger item-Elemente, die die gleiche Struktur wie der Zelltyp

besitzt, jedoch unterschiedliche Eigenschaften aufweist. Dadurch wird ebenfalls das rekur-

sive Einbinden von Tabellen und Nummerierungen innerhalb einer Aufz¨

ahlung erm¨

oglicht.

Zu guter Letzt enth¨

alt die Strukturgruppe ¨

Uberschriften. Sie dienen lediglich zur Trennung

von Textabschnitten und werden bei der Generierung von Kursstrukturen ber¨

ucksichtigt.

Name Typ Verwendung

valign normalizedString optional

width decimal optional

height decimal optional

colspan byte optional

rowspan byte optional

unit normalizedString optional

Tabelle 5.1: Attribute des cell-Elements

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

0 ..*

row

0 ..*

structureGroup

enumerate

enumerateType

item

0 ..*

table

0 ..*

column

cell

rowType

tableType

heading

itemize item

0 ..*

enumerateType

structureGroup

textGroup

itemType

mediaGroup

structureGroup

textGroup

cellType

mediaGroup

Abbildung 5.7: Strukturgruppe

5.2. FORMATIERBARE LERNBAUSTEINE 83

Media Gruppe

Die Media Gruppe (vgl. Abbildung 5.8) verwaltet jene Elemente, die zur Darstellung mul-

timedialer Inhalte ben¨

otigt werden. Sie besteht aus den Elementen image-Element und

mmo-Element. Das image-Element bindet Abbildungen in s¨

amtlichen Bildformaten, unter

anderen png,jpg,gif,pdf, ein. Es wurde in Anlehnung an das HTML-Element img defi-

niert, mit dem Unterschied, dass zu den Bitmap-Grafiken auch Vektorformate angeboten

werden. Die Verwendung eines Bildformats ist abh¨

angig von dem zu erzeugenden Ausga-

beformat und muss ggf. konvertiert werden. Hierzu wird in Abschnitt 5.5.3 der Einsatz

von Prozessoren diskutiert. Zeitabh¨

angige Formate, wie Videos oder interaktive Flashfil-

me, werden mit dem mmo-Element eingebunden. Das mmo-Element verf¨

ugt ¨

uber mehrere

Konfigurationsparameter, die in Tabelle 5.2.1 n¨

aher erl¨

autert werden. In Abh¨

angigkeit

vom type-Attribute erfolgt eine kontextsensitive Auswertung der optionalen Attribute.

Name Typ Verwendung

type normalizedString required

width decimal optional

height decimal optional

code normailzedString optional

archive normailzedString optional

unit normalizedString optional

data normalizedString optional

src normalizedString optional

target normalizedString optional

Tabelle 5.2: Attribute des mmo-Elements

Die in diesem Abschnitt vorgestellten Gruppen beschreiben lediglich den Aufbau eines

Bausteins. Die konkrete Implementierung kann daher mit unterschiedlichen Ans¨

atzen reali-

siert werden. In sp¨

ateren Kapiteln wird Bezug auf die hier vorgestellte Struktur genommen

und die Implementierungsvarianten XML-Bindig (vgl. Abschnitt 6.1.2) und OO-Binding

(vgl. Abschnitt 6.2) vorgestellt. Die eingef¨

uhrte Bausteinstruktur wird mit BrickML be-

zeichnet und deckt die Basisfunktionalit¨

at, die bei der Erstellung von multimedialen Kur-

sen ben¨

otigt wird, ab. Im n¨

achsten Abschnitt wird gezeigt, wie der Funktionsumfang f¨

eine spezielle Anwendungsdom¨

ane erweitert werden kann.

5.2.2 Spezialisierte Inhalte

Die Entwicklung multimedialer Inhalte und die damit verbundene Strukturierung des Lern-

materials ist abh¨

angig vom Themengebiet, den der Kurs beschreiben soll. So werden bei-

spielsweise in der Mathematik zahlreiche Formeln und Definitionen ben¨

otigt, die explizit

von einem Dokumentenmodell unterst¨

utzt werden m¨

ussen. Im Gegensatz dazu werden

in einem Fachgebiet wie der Theologie weniger Definitionen, sondern Verse und B¨

ucher

referenziert. Ein weiteres Beispiel ist das Fachgebiet Rechtswissenschaften, in dem es un-

umg¨

anglich ist, Gesetzesparagraphen zu beschreiben. Dieser Gedanke wurde bereits in

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

0 ..*

mmoType

parammmo

image

mediaGroup

Abbildung 5.8: Mdeia Gruppe

Arbeiten von [Freitag02b] (vgl. Kapitel 3.2.5) aufgegriffen und soll in das hier vorgestellte

Modell mit aufgenommen werden.

Die zwei wesentlichen Eigenschaften sind das Erweitern der Grundstruktur, um neue

Elemente, sowie die Spezialisierung bestehender Elemente f¨

ur dieselbe Fachdom¨

ane mit

anderen Eigenschaften. Erweiterungen sind dann notwendig, wenn fachbezogene Struktu-

ren einem Dokument hinzugef¨

ugt werden m¨

ussen, die zur Integration dom¨

anenspezifischer

Elemente, wie z. B. Paragraphen eines juristischen Textes, dienen. In diesem Fall werden

Elemente mit einem neuen Namensraum (vgl. Abschnitt 3.2.1) versehen und der Grund-

struktur hinzugef¨

ugt. Diese Form der Erweiterung f¨

uhrt zwangsl¨

aufig zu einer Einschr¨

an-

kung der in dieser Arbeit geforderten Kompatibilit¨

at mit Bausteinen anderer Autoren, weil

eine Erweiterung des Regelwerks zur Formatierung mit einhergeht. Obwohl formatierbare

Bausteine anderer Autoren m¨

uhelos in einen erweiterbaren Kurs mit aufgenommen werden

k¨

onnen, ist jedoch deren Verwendung in einem herk¨

ommlichen Kurs nicht m¨

oglich, weil

entsprechende Formatierungsregeln fehlen. Aus diesem Grund muss eine Normalisierung

durchgef¨

uhrt werden, die spezialisierte Bausteine auf den Basissprachumfang zur¨

uckf¨

uhrt.

Dabei findet eine surjektive Abbildung des neu definierten Strukturbaums auf die Stan-

dardelemente statt. Einfacher hingegen ist die Verwendung von Spezialisierungen. Hierbei

werden neue Elemente von bereits bestehenden Element-Typen abgeleitet und kommen

bei der Normalisierung ohne eine Neudefiniton der Formatierungsregeln aus.

Im Folgenden werden die im Projekt mαth-kit (vgl. Abschnitt 1.2) notwendigen Er-

weiterungen exemplarisch vorgestellt.

Spezialisierung f¨

ur die Mathematik

W¨

ahrend der Laufzeit des mαth-kit Projekts hat sich der Bedarf einer Quizumgebung f¨

Studierende herausgestellt. Sie soll die ¨

Uberpr¨

ufung des erlernten Wissens anhand von

Multiple-Choice-Tests erm¨

oglichen. Hierbei kamen zwei Varianten einer Quizumgebung

zum Einsatz. Der erste Quiz-Typ wertet ausgew¨

ahlte Felder aus und pr¨

asentiert die richtige

L¨

osung in Form einer Antwort. Der zweite Typ behandelt lediglich die Auswertung von

5.2. FORMATIERBARE LERNBAUSTEINE 85

0 ..*

text

0 ..*

questionType

answerType

quizType

shortquizType

sqquestionType

shortquiz

text

textGroup

question

quiz

sqquestion

text

solution

sqanswer

text

learnGroup

mediaGroup

answer

Abbildung 5.9: Lerngruppe

Fragestellungen und liefert die Anzahl richtig ausgew¨

ahlter Antworten. Abbildung 5.9

stellt die Struktur der beiden Quiz-Elemente quiz und shortquiz vor. Zu beiden Quizzes

gibt es einen optional einf¨

uhrenden Text, gefolgt von einer variablen Anzahl Fragen. Im

Gegensatz zu dem quiz-Element enth¨

alt das shortquiz-Element die passende Antwort zu

der Frage, die zwingend definiert werden muss.

Ein Beispiel f¨

ur eine Spezialisierung ist die mathGroup. Da im Projekt mαth-kit ¨

uber-

wiegend mathematische Inhalte entstanden sind, werden die ben¨

otigten Elemente defi-

nition,conclusion,lemma,corollary,notice,hint und example als Spezialisierung

des allgemeinen theorem-Elements in einer eigenen Gruppe zusammengefasst.

5.2.3 Dateistruktur

Zur Strukturierung der Dateien eines Bausteins bietet sich das bereits in Kapitel 2.3.1

vorgestellte IMS Content Package Information Model an. Es organisiert beliebige Datei-

en in einem komprimierten Archiv. Kern des Content Package ist das Manifest, welches

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

0 ..*

formula ##any

any

formulaType

definition

conclusion

lemma

corollary

notice

hint

theorem

mathGroup

Abbildung 5.10: Mathematikgruppe

durch ein Manifest-Element als Wurzelknoten gekenntzeichnet ist2. Die enthaltenen Datei-

en werden durch Resource-Elemente referenziert, die mit dem Resources-Element grup-

piert werden. Jede dieser einzelnen Ressourcen verweist jedoch nicht nur auf eine Datei,

sondern verwaltet mehrere von ihnen. Eine solche Gruppierung ist vor allem dann sinn-

voll, wenn mehrere Dateien, wie Abbildungen oder Applets, zu einer HTML-Seite geh¨

oren.

Gekennzeichnet werden sie als File-Element.

Weiterhin k¨

onnen Metadaten zugewiesen werden, die Aufschluss ¨

uber den Inhalt der

Ressource geben und ggf. zur Suche herangezogen werden. Hierbei wird der LOM-Standard

(vgl. Kapitel 2.3.3) mit seinen speziell auf Lerninhalte abgestimmten Gruppen verwendet.

Abschließend ist hinzuzuf¨

ugen, dass jede Ressource optional auf andere Ressource-

gruppen verweisen kann, die mit ihr in einer Abh¨

angigkeitsbeziehung stehen, um so die

Integrit¨

at des Bausteins zu gew¨

ahrleisten. Abbildung 5.11 verdeutlich diese Zusammen-

h¨

ange.

Da der technische Rahmen f¨

ur die formatierbaren Bausteine steht, muss jetzt noch

die Schnittstelle zu anderen Bausteinen und Kursen definiert werden. Damit Kursen der

Inhalt von Bausteinen korrekt zugeordnet werden kann, reicht die Bereitstellung eines

Manifests nicht aus. Vielmehr muss ein Einstiegspunkt festgelegt werden, mit dem der

Ubersetzer bzw. die ¨

Ubersetzerin die richtige Ressource ausw¨

ahlen und transformieren

kann. Diese Ressource wird mit dem speziellen Attribut transformable versehen. Der

Standard bietet zwar den generellen Typ webcontent an, dieser signalisiert jedoch, dass es

2Diese Betrachtung bezieht sich auf die im XML-Binding vorkommenden Element-Knoten

5.3. FORMATIERBARE KURSE 87

File

Meta−data

Manifest

Resource

Resources Eine Liste von Resourcen

Eine spezielle Resource

Wurzelknoten des Pakets

1..*

Metabeschreibung der Resource

Verwaltet Referenzen auf

Dateien, die zu dieser Resource gehören

Beschreibt die Abhängigkeit zu anderen

Resourcen

Metabeschreibung für eine Datei

Dependency

0..*

Meta−data

Inhalt des Bausteins

1content

Abbildung 5.11: IMS Content Package Information Model

sich um einen Teil einer Webpr¨

asentation handelt. Durch das Modifizieren dieses Attributes

wird w¨

ahrend der Erzeugung einer Pr¨

asentation das Dokumentmodell erkannt und mit dem

zugrundeliegenden Regelwerk weiterbearbeitet.

Mit dem Einsatz des IMS Content Packages und des im vorigen Abschnitt eingef¨

uhr-

ten Strukturmodells, entsteht eine in sich geschlossene Form, die, unabh¨

angig von anderen

Bausteinen, in beliebigen Kursen genutzt werden kann. Hiermit wird der Forderung nach-

gekommen, Inhalte von Lernmaterialien von ihrer konkreten Darstellung zu entkoppeln

und somit einen skalierbaren und orthogonalen Ansatz zu schaffen.

5.3 Formatierbare Kurse

Bisher wurde lediglich der technische Rahmen f¨

ur Bausteine betrachtet, jedoch nicht de-

ren Aggregation modelliert. Da sie keine Kursstruktur enthalten, sondern ausschließlich

Textstrukturen, muss f¨

ur sie ebenso ein technischer Rahmen geschaffen werden, der die

Integration von Bausteinen regelt und zudem ein formatierbares Basisformat besitzt. Aus

diesem Grund wir im Folgenden der Begriff Formatierbarer Kurs eingef¨

uhrt und das zu-

geh¨

orige Modell n¨

aher erl¨

autert.

Ein formatierbarer Kurs (FK) besteht aus mindestens einem formatier-

baren Baustein und einer beliebigen Anzahl Assets und definiert zugleich deren

Organisation. Erst in Verbindung mit einem Regelwerk f¨

ur ein Pr¨

asentations-

format entsteht eine nutzbare Kurseinheit. Formatierbare Kurse besitzen einen

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

definierten Rahmen, der die Aggregation mit anderen formatierbaren Kursen

erm¨

oglicht.

Zun¨

achst muss entschieden werden, wie Kurse organisiert sind, da deren Ressourcen

sich auf unterschiedliche Arten anordnen lassen. M¨

oglich sind sequenzielle Abfolgen von

Lerneinheiten, wie es bei einigen g¨

angigen Autorensystemen der Fall ist (vgl. Abschnitt

3.4), hierarchische Anordnungen, die einer Baumdarstellung entsprechen sowie vernetzte

Strukturen, die Querverbindungen zu anderen Lerneinheiten erm¨

oglichen. Wie bereits in

den Abschnitten 2.3.1 und 2.3.4 eingef¨

uhrt wurde, beziehen sich g¨

angige Standards auf

hierarchische Kurse, deren Aufbau sich als sinnvolles Strukturierungsmittel durchgesetzt

hat. Der n¨

achste Schritt ist die Zuordnung der formatierbaren Bausteine zu der ¨

uberge-

ordneten Kursstruktur. Abbildung 5.12 zeigt zur Verdeutlichung einen Kurs, der aus den

sechs hierarchisch gegliederten Lernobjekten A-F besteht. Die Lernobjekte B-D sind direkte

Nachfolger des Lernobjekts Aund sind ihm thematisch untergeordnet. Eine solche Zuord-

nung wird vorgenommen, wenn z. B. die Lerneinheit Komplexe Zahlen in die Einheiten

Einf¨

uhrung,Definitionen und Exploration unterteilt ist. Die Lerneinheiten A-C enthalten

jeweils einen Verweis auf einen formatierbaren Baustein, der den Inhalt des entsprechen-

den Kursknotens kapselt. Lernobjekt Dwiederum besteht aus Lernobjekte Eund F, enth¨

alt

jedoch – im Gegensatz zu den vorher beschriebenen Lernobjekten – keinen eigenen Inhalt.

Dieser Kursknoten dient ausschließlich zur Kursstrukturierung und gruppiert thematisch

die Bausteine Eund F. Als Beispiel k¨

onnte es sich um einen Aufgabenblock handeln, der

eine Liste themenbezogener Aufgaben anbietet.

Assets

Content

Assets

Content

Assets

Content

Assets

Content

Assets

Content

Lerneinheit A

Lerneinheit C

Lerneinheit E

Lerneinheit F

Lerneinheit D

Lerneinheit B

Kurs

Abbildung 5.12: Formatierbarer Kurs

Die durch die IMS Content Package Spezification festgelegten Bausteine werden als

komprimiertes Archiv gespeichert. Dadurch lassen sie sich ohne weiteres aus einer Kurs-

struktur entnehmen und in andere Strukturen einbinden, was vor allem den Einsatz von

5.3. FORMATIERBARE KURSE 89

Lernobjekten anderer Autoren beg¨

unstigt. Da Bausteine ¨

uber keine Layoutinformationen

verf¨

ugen, passen sie sich nahtlos an ¨

ubergeordnete Kurse an.

Die hier vorgestellte Struktur soll als allgemeines Schema verstanden werden, das sich

nach Bedarf mit verschiedenen Techniken implementieren l¨

asst. Eine Variante ist die Ab-

bildung der Kursstruktur auf eine Relationale Datenbank, bei der zu jedem Knoten ein

entsprechender Tabelleneintrag vorgenommen wird. Hierarchische Strukturen k¨

onnen ¨

uber

Fremdschl¨

ussel-Beziehungen zwischen den jeweiligen Knoten hergestellt werden. Ferner

ist auch die Verwendung eines XML-Bindings denkbar, das die Kursstruktur in einem

XML-Manifest speichert. In Abh¨

angigkeit von der pr¨

aferierten L¨

osung, ist eine Umset-

zung mit der in Kapitel 2.3.2 vorgestellten IMS Content Package Spezification m¨

oglich,

wie es in Abbildung 5.11 illustriert wird. Die eingebundenen Ressourcen sind jedoch kei-

ne Lernmaterialien, sondern formatierbare Bausteine. In einem Kurs-Manifest lassen sich

mehrere Organisationsger¨

uste anlegen, wobei jedes einen eigenen Baum verschachtelter

item-Elemente enth¨

alt. Diese verschachtelte Struktur entspricht der Kursstruktur und

enth¨

alt Referenzen auf formatierbare Bausteine.

Name Erkl¨

arung Ben¨

otigt Typ

Item A node that describes the shape of the orga-

nization.

M Container

dentifier An identifier, for the Item, that is unique wi-

thin the Manifest file.

M ID

IdentifierRef A reference to an identifier in the resources

section or a (sub)Manifest

O String (2000)

Title Title of the item. O String (200)

IsVisible Indicates whether or not this item is dis-

played when the structure of the Package is

displayed or rendered.

O Boolean

Parameters Static parameters to be passed to the resour-

ce at launch time.

O String (1000)

Item A sub-node within this organization. O Container

Meta-data Meta-data describing this item. O Container

Tabelle 5.3: Das Item Element der IMS Content Package Spezifikation

Tabelle 5.3 zeigt einen Auszug aus dem Information Model zur Charakterisierung des

Item-Elements. Item-Elemente besitzen die Attribute Identifier,IdentifierRef,IsVi-

sible und Parameters. Mit dem Attribut IdetifierRef wird einem Item eine Ressource

zugeordnet, indem auf den Identifier einer beliebigen, im Manifest beschriebenen Ressour-

ce, verwiesen wird. Zudem dient das Item-Element als Container f¨

ur weitere Item-Elemente

und kann mit LOM-Metadaten (vgl. Kapitel 2.3.3) angereichert werden. Der Vorteil, der

sich aus dieser Struktur ergibt, ist die gew¨

unschte layoutfreie Beschreibung von Kursstruk-

turen, aber auch die erlangte Standardkompatibilit¨

at mit Learning Management Systemen

(vgl. Kapitel 3.3), die immer mehr Standards unterst¨

utzen und entsprechende Mechanis-

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

men zur ad¨

aquaten Anzeige implementieren. Jedes LMS kann die Darstellungen seiner

eingebundenen Kurse individuell auf seine Web-Darstellung anpassen und in das Pr¨

asen-

tationskonzept einbauen.

5.3.1 Granularit¨

Genau wie formatierbare Bausteinen sollen auch Kurse bzw. Teile von ihnen wiederver-

wendet werden. Eine solche Modularit¨

at ist vor allem dann notwendig, wenn die Bausteine

eines zu entnehmenden Kursabschnitts feingranular konstruiert sind. In diesem Fall m¨

us-

sen neben formatierbaren Bausteinen auch formatierbare Kurse (FK) in eine Kursstruktur

eingebunden werden. Da Kurse – genau wie Bausteine – dem IMS-Standard folgen, lassen

sie sich ebenso als Archiv mit zugeh¨

origem Manifest speichern. Dieses Archiv kann dann als

Ressource genutzt werden und l¨

asst sich von item-Elementen eines ¨

ubergeordneten Kurses

referenzieren. Diese Herangehensweise erm¨

oglicht eine flexible Festlegung der Granulari-

t¨

atsstufen einzelner Subkurse und erh¨

oht damit die Modularit¨

at des Konstruktionsprozess.

Abbildung 5.13 veranschaulicht diese Zusammenh¨

ange. Der formatierbare Kurs A besteht

aus den Lektionen 1 und 1.2, wobei die letztere der ersten untergeordnet ist. Beide Lektio-

nen verweisen auf Dateien, wobei Lektion 1 auf einen Baustein und Lektion 1.2 auf einen

Kurs verweist. Wird Baustein 1 ge¨

offnet, so enth¨

alt er zwei weitere Dateien, von denen die

erste den Inhalt des Bausteins in Form einer XML-Datei beschreibt und die zweite eine

Abbildung. Die Archiv-Datei von Kurs B speichert hingegen einen Kurs mit einer eigenen

Item-Struktur und den referenzierten Baustein 2. Dieser kapselt wieder eine XML-Datei,

die den Inhalt des formatierbaren Bausteins enth¨

alt.

Aufgrund der separat gekapselten Strukturinformationen k¨

onnen formatierbare Kurse

und deren Bausteine durch Aufl¨

osung der Referenzen aus einem Kurs seziert werden.

Damit Kurse als solche erkannt werden, m¨

ussen sie, wie bereits die Bausteine, einen eigenen

Typ besitzen. Die Typdefinition erfolgt in Anlehnung an die Typzuweisung der XML-

Dokumente innerhalb von Bausteinen. F¨

ur Kurse und Bausteine werden die Typen fk

und fb verwendet. Sie werden w¨

ahrend der Erzeugung eines Zielformats herangezogen

und legen fest, ob es sich um eine Kursstruktur handelt oder einen zu transformierenden

Baustein.

5.3.2 Abstrakte Kursmodell

Nachdem die formatierbaren Bausteine und Kurse eingef¨

uhrt wurden, besteht eine soli-

de Grundlage, auf der darstellungsunabh¨

angige und modulare Kurse entwickelt werden

k¨

onnen. Dieses Modell eignet sich zur Entwicklung von Teilkursen, die in andere Kurse

eingebettet werden k¨

onnen. Ein solches Maß an Flexibilit¨

at und Orthogonalit¨

at f¨

uhrt je-

doch zwangsl¨

aufig zu einem komplexeren Benutzungsmodell. Kurse werden nicht mehr als

ein gesamtes Werk erstellt, sondern in kleinen Teilst¨

ucken konzipiert und bearbeitet. Dar-

uber hinaus sollen bereits f¨

ur die Lehre eingesetzte Materialien und bestehende Dokumente

wiederverwendet werden. Aufgrund der bestehenden Formatvielfalt, wie z. B. Latex,Micro-

soft PowerPoint oder Microsoft Word, ist es sinnvoll, eine Abstraktion der formatierbaren

5.3. FORMATIERBARE KURSE 91

Dateiansicht

Referenziert

Datei

document.xml

Lektion 1

Lektion 1.2

Baustein (FB) 1

Kurs (FK) B

Kurs (FK) A

document.xml

image.png

Kurs (FK) B

Leaktion 1

Baustein (FB) 2

Baustein (FB) 1

Abbildung 5.13: Verschachtelte Kurse

Kurse zu finden, die die konkrete modulare Kurskonstruktion verbirgt. Die vorliegenden

Formate unterscheiden sich hinsichtlich ihrer internen technischen Struktur sowie in ihrem

eigentlichen Verwendungszweck. Sollen sie auf das in dieser Arbeit definierte Kursmodell

abgebildet werden, muss eine einheitliche Schnittstelle definiert werden, so dass w¨

ahrend

des Abbildungsprozesses ausschließlich die Analye des Quellformats im Vordergrund steht.

Aus diesem Grund wird das Abstrakte Kursmodell eingef¨

uhrt (vgl. [Baudry04b]), welches

die Bearbeitung der vollst¨

andigen Kurssturktur, inklusive aller Texte und multimedialer

Komponenten, erm¨

oglicht und dabei kein explizites Wissen ¨

uber verschachtelte Bausteine

oder Standards voraussetzt. Zu diesem Zweck wird eine komplette Baumstruktur erzeugt,

die sowohl die Kurshierarchie als auch den Lerninhalt enth¨

alt.

Abbildung 5.14 zeigt den schematischen Aufbau des Kursmodells3. Jedes Kursmodell

besitzt als Wurzelknoten das course-Element, das sich nach Bedarf mit LOM-Metadaten

anreichern l¨

asst. Direkt unter dem Kurs-Element werden rekursiv lesson-Elemente defi-

niert, die sp¨

ater der Kursstruktur entsprechen. Sie k¨

onnen entweder aus der in Abschnitt

5.2.1 vorgestellten Dokumentstruktur mit Elementen aus den Gruppen textGroup,struc-

3Es handelt sich bei dieser Abbildung keineswegs um die vollst¨

andige Darstellung des Modells, sondern

vielmehr um das Fragment einer Organisation, das ausschließlich zur Vorstellung dient.

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Meta−data

Paragraph

Column

Table

Course

Lesson

0..* Lesson

Row

Cell

0..*

Itemize

Item

0..*

Mmo

0..*

Wurzelknoten des Kurses

Daten über den Kurs

Enthält den den Inhalt einer Lektion.

Daten über die Lektion.

Enthält beliebig viele Unterlektionen.

Lektionen bestehen aud Paragraphen

Paragraphen können Tabellen enthalten

Richtet die Saplten einer Tabelle aus

Definiert eine Zeile

Definiert eine Tabellenzelle

Definiert eine Aufzählung

Entspricht einem Aufzählungspunkt

Fügt ein Multimeida Objekt ein

0..*

Abbildung 5.14: Kursmodell Spezifikation

tureGroup und mediaGroup bestehen oder als einfacher Knoten zur Gruppierung verwen-

det werden. In Abbildung 5.14 wird zur Veranschaulichung ein Abschnitt mit Tabellen,

Aufz¨

ahlungen und Multimedia Objekte dargestellt. Die Verschachtelungsstruktur des Kur-

ses geht jedoch nicht verloren, weil sie aus dem Kursmodell eindeutig abgeleitet wird. In

der Regel beschreibt jede Lektion den Inhalt eines Bausteins. Treten jedoch starke Abh¨

an-

gigkeiten zwischen Bausteinen auf oder weisen sie einen derart abgeschlossenen Inhalt auf,

dass sie sich in andere Kurse einbauen lassen, kann eine Lektion als Subkurs definiert wer-

den. Hierzu beschreibt Tabelle C.2 die bereits in Abbildung 5.14 vorgestellten Elemente.

Das Attribut courseObject (1.2.1) entscheidet, ob es sich bei der zugeordneten Lektion

tats¨

achlich um einen Baustein oder um einen Teilkurs handelt.

Die Abbildung auf einen formatierbaren Baustein erfolgt, indem die Unterstruktur der

Lektionen ¨

ubernommen wird und als neues Dokument in das Datei-Archiv des formatier-

baren Bausteins kopiert wird. Des weiteren m¨

ussen die in der Lektion verwendeten Dateien

in den Baustein kopiert werden. In Tabelle C.2 besitzt das MMO-Element (1.2.8) hierf¨

ur das

href-Attribut, mit dem ein assoziertes Asset eingebunden werden kann.

Im Gegensatz zu einem Kurs ben¨

otigt ein Baustein immer einen festen Bezugspunkt

5.3. FORMATIERBARE KURSE 93

um seine Assets abzulegen und zu verwalten. Ein solcher Bezugspunkt ist stets ein ¨

uber-

geordneter formatierbarer Kurs. Diese Abh¨

angigkeit ist deshalb wichtig, weil der fachliche

Zusammenhang sich zwangsl¨

aufig auf die verwendeten Assets ¨

ubertr¨

agt und sich bei ei-

ner Disaggregation entsprechend auf die beteiligten Datein der Unterlektionen auswirkt.

Abbildung 5.15 veranschaulicht exemplarisch diesen Zusammenhang. Ein abstrakter Kurs

wird genau einem formatierbaren Kurs zugewiesen. Wird dem Kurs dynamisch die er-

ste Lektion hinzugef¨

ugt, kann entweder ein Subkurs oder ein Baustein erzeugt werden,

der als Teil des formatierbaren Kurses angelegt wird. Lektion 1 besitzt den Parameter

courseObject mit dem Wert true und wird deshalb dem Subkurs Kurs 2 (FK) zugeord-

net. Letzterer dient als Container f¨

ur weitere untergeordnete Lektionen. Lektion 1.1 und

1.2 werden deshalb jeweils auf Baustein 1 (FB) und Baustein 2 (FB) abgebildet, wobei

die zu Lektion 1.2 geh¨

orende Dokumentstruktur, bestehend aus einem Paragraphen, einem

Textblock und einem Video, ebenfalls Baustein 2 (FB) zugeordnet werden. Im Gegensatz

zu Lektion 1 ist der Parameter courseObject von Lektion 2 auf den Wert false gesetzt

und bewirkt, ebenso wie bei Lektion 1.1 und Lektion 1.2, die Erzeugung eines einfachen

Bausteins. Baustein 3 besitzt als Bezugspunkt wieder Kurs 1 (FK). Durch die ¨

Anderung

des Parameters courseObject k¨

onnen jetzt komplexe, rekursive Strukturen definiert und

modifiziert werden.

Course Object = true

Course Object = false

Paragraph

Baustein 1 (FB)

Baustein 2 (FB)

Baustein 3 (FB)

Baustein 4 (FB)

Lektion 1

Text

Kurs

Kurs 2 (FK)

Kurs 1 (FK)

Video

Lektion 2

Lektion 2.1

Lektion 1.2

Lektion 1.1

Abbildung 5.15: Abbildung eines Kurses auf die Bausteinstruktur

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

5.4 Abbildung von Lernmaterialien

Bei der Entwicklung von E-Learning-Inhalten werden zur Anfertigung neuer Kurse h¨

aufig

bestehende Skripte, Pr¨

asentationsfolien und andere Kursmaterialien herangezogen. Jedoch

weisen diese Inhalte grundlegende Unterschiede sowohl in ihren inhaltlichen Strukturen

als auch in ihrem Format auf. Einerseits existieren Skripte, die in Vorlesungen studienbe-

gleitend eingesetzt werden und Studierenden eine solide Grundlage bieten, sich in bestim-

mte Themen einzuarbeiten und anderseits existieren Pr¨

asentationsfolien, anhand derer ein

Uberblick ¨

uber ein bestimmtes Themengebiet w¨

ahrend einer Pr¨

asenzveranstaltung vermit-

telt wird. Der Unterschied liegt hierbei in der inhaltlichen Ausarbeitung der Folien, die

bei der Verwendung in Pr¨

asenzveranstaltungen, im Gegensatz zu Skripten, h¨

aufig Aufz¨

ah-

lungscharakter aufweisen. F¨

ur die Realisierung eines neuen Kurses werden meistens keine

vollst¨

andigen Skripte oder Foliens¨

atze ben¨

otigt, sondern vielmehr einzelne Textpassagen

oder Abbildungen. Deshalb wird in diesem Abschnitt eine L¨

osung pr¨

asentiert, anhand der

beliebige Lehrinhalte auf das in Kapitel 5.3 vorgestellte modulare Kurskonzept ¨

ubertragen

werden k¨

onnen. Ausgangspunkt ist das zuvor eingef¨

uhrte Abstrakte Kursmodell, welches

als allgemeine Schnittstelle f¨

ur Kursmaterialien verstanden wird, mit der modulare und

darstellungsfreie Kurse konstruiert werden k¨

onnen, ohne die zugrunde liegende technische

Realisierung ber¨

ucksichtigen zu m¨

ussen.

5.4.1 Analyse

Das grundlegende Problem, das bei der Konzeption auftritt, ist der Umgang mit der For-

matvielfalt, die bestehende Materialien aufweisen. Mit dem Begriff Format ist hier die

technische Realisierung eines Zwischenformats gemeint, mit dem Materialien abgespei-

chert und ausgetauscht werden. So wird in der Regel die Pr¨

asentation eines Vortags mit

MS PowerPoint-Folien durchgef¨

uhrt, wogegen Skripte h¨

aufig mit MS Word,Latex oder

Framemaker erstellt werden. Jedes dieser Formate besitzt individuelle Eigenschaften und

Vorz¨

uge. Die MS Office-Formate Porwerpoint und MS Word werden in einem Bin¨

arfor-

mat kodiert, in dem alle Daten – selbst Abbildungen und Videos – eingebettet werden.

Latex-Dokumente werden hingegen textuell kodiert und verweisen auf externe Daten, wie

z. B. Bilder, die dem Dokument im urspr¨

unglichen Format beiliegen. Abbildung 5.16 zeigt

auf der linken Seite die Autorenwerkzeuge MS-Word,OpenOffice,XML-Editoren und Lyx.

Jedes dieser Autorenwerkzeuge verwaltet seine Ressourcen auf unterschiedliche Art. MS-

Word speichert seinen Dokumentinhalt in einem propriet¨

aren Bin¨

arformat in einer einzel-

nen Datei ab. OpenOffice verwendet eine auf mehrere Dateien ausgelegte Dateistruktur, die

als komprimiertes ZIP-Archiv bearbeitet wird. XML-Editoren speichern Inhalte in XML-

Dokumenten, wobei das jeweilige Format der eingesetzten Ressource beibehalten wird.

Dieses Beispiel zeigt eine Bild-Referenz auf eine PNG-Datei. Der letzte Vertreter der Bear-

beitungswerkzeuge ist der WYSIWYG-Editor Lyx. Er wurde speziell f¨

ur Latex-Dokumente

konzipiert, und abstrahiert von der textuellen Gestaltung der Latex-Dokumente. Das Ab-

speichern hinzugef¨

ugter Ressourcen erfolgt bei dieser Variante ebenfalls extern.

Es unterscheiden sich jedoch nicht nur die technischen Formate, sondern auch der in-

5.4. ABBILDUNG VON LERNMATERIALIEN 95

Assets

Content

Lektion

Kursmodell

Assets

Content

Abbildung

Loader A

.sxw

.doc

Loader B

.png

.xml

Loader C

.jpg

.tex

Loader DLyx

XML−Editor

OpenOffice

MS Word

Abbildung 5.16: Wiederverwendung von Lernmaterialien

terne Dokumentaufbau. Bei Latex werden Dokumente hierarchisch, d. h. aus Kapiteln und

Abschnitten, aufgebaut. Das Dokument wird ohne feste Bindung an ein Layout definiert

und speichert es in sogenannten Style-Dateien. Im Gegensatz hierzu erfolgt bei MS-Word

bzw. OpenOffice-Dokumenten die Definition des Layouts w¨

ahrend der Dokumenterstel-

lung. Hieraus folgt jedoch, dass derart gestaltete Dokumente aus einer Sequenz formatier-

ter Texte bestehen und keineswegs hierachisch strukturiert sind. ¨

Uberschriften werden als

normale Texte gespeichert, die zur Darstellung den Typ ¨

Uberschrift mit einer zugeord-

neten Verschachtelungstiefe verwenden [OOS02]. Die abzubildenden Materialien k¨

onnen

jedoch noch andere Strukturen enthalten. Mit MS-PowerPoint werden Foliensequenzen

erstellt, die Abbildungen, Videos, kleine Textabschnitte und Aufz¨

ahlungen enthalten. Da-

mit jedoch m¨

oglichst viele Formate auf formatierbare Kurse abgebildet werden k¨

onnen,

soll das in Abschnitt 5.3.2 vorgestellte abstrakte Kursmodell eingesetzt werden. Dieses

Modell erleichtert, bedingt durch seine einfache Struktur, die Konvertierung bestehender

Materialien. Ohne dieses Modell m¨

usste jedes Format, entsprechend seiner Spezifikation,

verarbeitet werden und eine komplexe verschachtelte Kurstruktur erzeugt werden, die aus

formatierbaren Bausteinen und Kursen besteht. Aus diesem Grund soll hier eine strikte

Trennung zwischen dem Loader, f¨

ur ein spezielles Format, und dem Kursmodell stattfin-

den. Diese Trennung bewirkt, dass sich die Implementierung eines Loaders komplett auf

die technischen Gegebenheiten des zu analysierden Formats bezieht und dabei der kom-

plexe Abbildungsprozess auf formatierbare Kurse nicht ber¨

ucksichtigt werden muss. Der

Vorteil liegt auf der Hand, denn die Implementierung bewirkt, bedingt durch die geringere

Komplexit¨

at des Loaders, eine Kosteneinsparung und erh¨

oht zugleich die Wartbarkeit. Ab-

bildung 5.16 zeigt, dass f¨

ur jedes Format ein eigener austauschbarer Loader implementiert

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

werden kann.

5.4.2 Abbildung auf das Kursmodell

Die Loader sind f¨

ur die Abbildung eines Formats auf das Kursmodell zust¨

andig. Wie

bereits im vorigen Kapitel ausgearbeitet wurde, verwenden die abzubildenden Formate

verschiedene technische Realisierungen. Wird z. B. ein Loader f¨

ur OpenOffice implemen-

tiert, muss zun¨

achst, f¨

ur die Anaylse der Datenstrukur, ein XML-Parser vorgeschaltet

werden. Wird hingegen ein Flash-Film abgebildet, muss die Bin¨

ar-Datei Bit f¨

ur Bit ein-

gelesen werden, weil es sich hierbei um ein Format handelt, bei dem es vor allem auf eine

– durch die ¨

Ubertragung im Internet bedingte – komprimierte Datenhaltung ankommt.

Sobald die technischen H¨

urden ¨

uberwunden sind, muss das Dokument in seine Grund-

bestandteile Struktur,Metdadaten,Inhalt,E-Learning Komponenten,Assets und Layout

zerlegt werden. Eine solche Separation wird in Abbildung 5.17 illustriert.

Der Begriff Struktur beschreibt den bereits im vorigen Abschnitt erw¨

ahnten Materi-

alaufbau. Strukturen sind hierarchisch oder sequenziell aufgebaut und werden sukzessiv

auf die Lektionen des Kursmodells ¨

ubertragen. Als Beispiel dient ein Office-Dokument, in

dem eine ¨

Uberschrift erkannt wird und der Titel als Name f¨

ur die zu erstellende Lektion

fungiert. An dieser Stelle kann der Lektion mitgeteilt werden, ob es sich um ein umfang-

reiches und abgeschlossenes Thema handelt und es somit auf einen Subkurs abgebildet

werden soll oder eher auf einen einfachen Baustein.

Materialien verf¨

ugen in der Regel ¨

uber unterschiedlich viele Metadaten, die sich in die

Gruppen der objektiven und subjektiven Metadaten aufteilen lassen. Objektive Metadaten

sind solche, die eindeutig festgelegt werden k¨

onnen, wie z. B. das Erstellungsdatum und

die im Anschluss protokollierten Lebenszyklen. Subjektive Metadaten werden hingegen

vom Autor bzw. von der Autorin definiert. Es k¨

onnen anvisierte Lernziele oder definierte

Nutzungsrechte an einem Material sein. In Abschnitt 2.3.3 wurde bereits das vom Kurs-

modell unterst¨

utzte Metadaten-Modell LOM eingef¨

uhrt. Dieses Kursmodell erm¨

oglicht die

Definition der Metadaten bei Lektionen und Ressourcen, die mit externen Datenquellen

verkn¨

upft werden. In Abh¨

angigkeit von dem jeweiligen Kontext der Lektion, sind Mata-

daten fester Bestandteil eines Bausteins oder Kurses.

Inhalte bestehen im Allgemeinen aus Grundelementen wie Tabellen, Aufz¨

ahlungen,

Nummerierungen, Abbildungen und Animationen. Sie werden durch den Loader erkannt

und mit der Modellierungssprache BrickML einer Lektion zugeordnet. Eine allgemeing¨

ul-

tige Schnittstelle kann jedoch nicht alle Eigenschaften eines Formats detailliert abbilden.

So gibt es beispielsweise f¨

ur Kopfzeilen, die in Office-Formaten ¨

ublich sind, keine eindeu-

tige Entsprechung, da sie zwar in Office-Dokumenten sinnvoll sind, sich jedoch nicht auf

beliebige Ausgabeformate ¨

ubertragen lassen. Vielmehr ist die Erzeugung einer Kopfzeile,

mit Seitenzahlen und ¨

Uberschriften, abh¨

angig von dem zu generierenden Format und wird

im n¨

achsten Abschnitt weiter er¨

ortert.

Im E-Learning-Kontext werden Quiz-Umgebungen gern zur Wissens¨

uberpr¨

ufung her-

angezogen. Lernobjekte k¨

onnen in Kombination mit einem LMS gestartet und durch das

LMS ausgewertet werden. Damit lassen sich z. B. zeitliche Limitierungen f¨

ur eine Ler-

5.4. ABBILDUNG VON LERNMATERIALIEN 97

Lektion

Assets

Content

transformable

webcontent

Metadaten

E−learning

Module

Inhalt

Struktur

Assets

Loader

DocBook

Latex

Office

XML−Sprachen

Layout

Assets

daten

BrickML

Lektionen

LOM−Meta−

Kursmodell

SCORM

Abbildung 5.17: Abbildung auf das Kursmodell

neinheit festlegen oder Punktekontos f¨

ur Studierende f¨

uhren. Diese Eigenschaften sind

f¨

ur ein allgemeines Kursmodell unerl¨

asslich und m¨

ussen auf dieses abbildbar sein. Quiz-

Umgebungen lassen sich auf das in Abschnitt 5.2.1 beschriebene Dokuementenmodell ¨

uber-

tragen, wobei die Funktionalit¨

at von Lernobjekten auf den SCORM-Standard (vgl. Ab-

schnitt 2.3.1) zur¨

uckzuf¨

uhren ist.

Die in das abzubildende Format eingebetteten Daten sowie die von ihnen referenzierten

Assets, m¨

ussen vom Loader erfasst und dem Kursmodell ¨

ubergeben werden. Die Zuord-

nung der Daten zu einem formatierbaren Baustein erfolgt auch hier kontextsensitiv, in-

dem der einem Baustein zugeordnete Kurs wieder als Bezugspunkt f¨

ur die Dateizuordnung

dient. Trifft der Loader w¨

ahrend der Verarbeitung des Quell-Dokuments jedoch auf do-

kumentspezifische Formatierungsregeln, so d¨

urfen diese nicht weiterbearbeitet werden. Die

vorhandenen Formatierungen m¨

ussen genau an diesen Stellen vom Inhalt getrennt werden,

damit neue, separate Formatierungsregeln den zu erzeugenden formatierbaren Bausteinen

zugewiesen werden k¨

onnen.

Dar¨

uber hinaus kann das Kursmodell zu einem anderen Zweck verwendet werden. Mit

Hilfe des Kursmodells und der damit verbundenen Abbildungsmechanismen, k¨

onnen auch

Fremdformate als integraler Bestandteil der formatierbaren Bausteine eingesetzt werden.

Dieses ist vor allem dann sinnvoll, wenn ein Dokument in seinem Quell-Format weiter-

bearbeitet werden soll und erst bei der Generierung des Ziel-Formats zu einem Baustein

oder Kurs konvertiert wird. So kann z. B. ein Office-Dokument den Inhalt eines Bausteins

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

repr¨

asentieren, der fortlaufend modifiziert wird. Dieses hat zur Folge, dass der, aus dem

Office-Dokument erzeugte, Subkurs an Stelle des Bausteins in den formatierbaren Kurs

eingebunden und anschließend, in einem zweiten Verarbeitungsschritt, in das gew¨

unschte

Format ¨

ubersetzt wird. Abbildung 5.17 zeigt die Typen webcontent,transform und map.

Dateien, die als abbildbar gekennzeichnet sind, werden mit dem entsprechenden Loader

wieder auf einen verschachtelten Kurs abgebildet.

5.4.3 Nachbearbeitung

Der Abbildungsprozess von Lernmaterialien setzt einen logisch strukturierten Kurs voraus.

Dieser kann jedoch bei der Nutzung bereits erstellter Materialien nicht zwingend vorraus-

gesetzt werden. Handelt es sich bei der Quelle um ein Dokument, das nicht aus abge-

schlossenen Kapiteln besteht und s¨

amtliche Verweise auf andere Textstellen enth¨

alt, ist

eine Segmentierung in eigenst¨

andige Objekte ¨

außerst schwierig und Kurse werden schnell

zu großen ’Klumpen’, die sich nicht mehr austauschen lassen. Ist jedoch Wiederverwen-

dung das langfristige Ziel, so m¨

ussen generierte Kurse ¨

uberarbeitet werden. Der f¨

ur ei-

ne Modularisierung notwendige Aufwand h¨

angt naturgem¨

aß vom Quellmaterial ab. Nun

l¨

asst sich einfach sagen: “Das Dokument muss ¨

uberarbeitet werden!”, aber wie sollte damit

begonnen werden und wie k¨

onnen Lernbausteine ¨

uberhaupt seiteneffektfrei ¨

uberarbeitet

werden? ¨

Ahnliche Probleme treten bei der objektorientierten Programmierung und bei

der Komponenten orientierten Programmierung auf [Griffel98,Szyperski97]. Treten nach

der Abbildung vom fachlichen auf das technische Modell ¨

Anderungen an den Schnittstel-

len der Objekte auf, oder sollen schlecht strukturierte Objekte im Sinne des Paradigmas

verbessert werden, so wird im Allgemeinen von Refactoring [Fowler99] gesprochen. Einige

Mechanismen und Maßnahmen, die bei der Software-Entwicklung [Pomberger96], zu guten

und anspruchsvollen L¨

osungen f¨

uhren, k¨

onnen durch leichte Modifikationen auf die ¨

Uber-

arbeitung von Lernobjekten angewendet werden. Zun¨

achst m¨

ussen jedoch die Unterschiede

bzw. Gemeinsamkeiten zwischen Lernobjekten und Objekten der objektorientierten Pro-

grammierung (OOP) [Taylor96] herausgearbeitet werden. Ein wesentlicher Aspekt in der

OOP ist die Vererbung. Sie erm¨

oglicht es Objekten die Funktionalit¨

at von anderen Objek-

ten zu ¨

ubernehmen und selbst anzubieten. Des weiteren kennt das Paradigma eine zweite

Objektrelation, die Aggregation. Sie stellt im Wesentlichen eine Benutztbeziehung zwi-

schen zwei Objekten dar. Lernobjekte besitzen diese Formen der Relation nicht, werden

aber thematisch anderen Lernobjekten untergeordnet. Die nachfolgenden Regeln werden

dahingehend adaptiert, dass der Sinn und Zweck auf die hierarchische Beziehung zwischen

Lernobjekten ¨

ubertragen wird. Ein weiterer Unterschied bezieht sich auf die in der OOP

vorkommenden Schnittstellen und der damit verbundenen Datenkapselung. Methoden er-

weitern das Angebot von Objekten, ¨

ahnlich wie es Lernabschnitte in einem Lernobjekt

tun. Die Regeln f¨

ur das Refactoring von Objekt-Methoden wird also auf die Bearbeitung

von Textabschnitten projiziert. Im Folgenden werden wichtige Maßnahmen und Regeln

vorgestellt, die speziell f¨

ur die Nachbearbeitung von Lernobjekten angepasst worden sind.

Extract Block: Separiere einen Textabschnitt innerhalb des Bausteins und eleminiere

alle auftretenden Bez¨

uge.

5.5. TRANSFORMATION 99

Extract Learning Object: Verschiebe einen Textabschnitt, der einen semantisch ande-

ren Bezug hat, in einen neuen, eigenst¨

andigen Baustein.

Move Block: Verschiebe einen zusammengeh¨

orenden Textabschnitt in einen anderen

Baustein.

Collapse Hierarchy: Entnehme den Inhalt eines Bausteins und f¨

uge ihn in den Inhalt

des in der Kursstruktur ¨

ubergeordneten Bausteins ein.

Extract Hierarchy: Teile den Inhalt eines Bausteins auf mehrere Bausteine auf und

ordne sie als Unterbausteine in die Kursstruktur ein.

Remove Middelman: Entferne einen Kursknoten, der ausschließlich zur Gruppierung

anderer dient und verteile dessen Inhalt auf seine Unterbausteine.

5.5 Transformation

Bisher wurden Modelle vorgestellt, mit denen Kurse darstellungsfrei entwickelt werden

k¨

onnen. Diese Kurse sind jedoch in der bis jetzt definierten Form nicht f¨

ur einen Einsatz mit

Studierenden geeignet, weil f¨

ur die ¨

Ubersetzung auf ein spezielles Format das Regelwerk

fehlt. In diesem Abschnitt wird erl¨

autert, wie die modulare Kursstruktur prozessiert wird

und die formatierbaren Bausteine und Kurse f¨

ur die Generierung eines speziellen Formats

dabei herangezogen werden.

5.5.1 Aggregation

In Abbildung 5.13 wurde bereits gezeigt, dass Bausteine in Kursen abgelegt werden, die

wiederum weitere Subkurse enthalten k¨

onnen. Abbildung 5.18 verdeutlicht die Aggregati-

onsbeziehung zwischen Kursen und Bausteinen.

Lektion

Assets

Content

Abbildung 5.18: Kursaggregation

Damit ein solcher Kurs ¨

ubersetzt werden kann, muss er in eine f¨

ur Studierende lesba-

re Form gebracht werden. Hierbei wird die Kurs- bzw. Bausteinaggregation durchlaufen

und jeder Baustein ¨

ubersetzt. Anschließend muss anhand der Zwischenergebnisse das ge-

w¨

unschte Format erzeugt werden. Kurse verwenden die in Abschnitt 5.3.1 eingef¨

uhrten

Ressource-Typen webcontent,fk und fb. Ressourcen, die mit webcontent gekennzeich-

net sind, werden w¨

ahrend der ¨

Ubersetzung umkopiert und nicht weiterverarbeitet. Tritt

100

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

einer der beiden Typen fk oder fb auf, so handelt es sich bei dem Asset um ein Paket, das

weiteren Inhalt aggregiert. Diese Pakete m¨

ussen – je nachdem, ob es sich um einen Subkurs

oder einen Baustein handelt – rekursiv weiterverarbeitet werden, wobei das Resultat in

den aktuellen Kurs eingeh¨

angt wird. Demgegen¨

uber wird der Inhalt von Bausteinen in das

gew¨

unschte Zielformat transformiert. Die Assets eines Bausteins lassen sich mit folgenden

Typen assoziieren: webcontent,transform und map (vgl. Abschnitt 5.4.2). Assets mit

dem Typ webcontent werden beibehalten und der Typ transform bewirkt die ¨

Uberset-

zung des Assets. Der Typ map bewirkt zun¨

achst eine Abbildung der Asset-Datei auf einen

formatierbaren Kurs, der im Anschluss den Typ fk erh¨

alt und vom ¨

Ubersetzungsprozess

weiterverarbeitet wird. Listing 5.1 4zeigt einen umgangssprachlichen Algorithmus, der das

Durchwandern eines formatierbaren Kurses formuliert.

Listing 5.1: Algorithmus Disaggregation

Bearbeite Kurs (Disaggregation)

21. ¨

Offne FK

2. Bearbeite Ressourcen

Wenn Ressource vom Typ:

5webcontent: ¨

Ubernehme Ressource

fk: [Bearbeite (Sub)Kurs]und binde seine Struktur in

diesen ein

8fb: [Bearbeite Baustein]und binde seine Assets in

diesen ein

3. Durchlaufe Kursstruktur

11Wenn Knoten referenziert:

fk: Setze Referenz auf neue Substruktur (Submanifest)

fb: Referenziere die Startdatei des Bausteins

Bearbeite Baustein

1. ¨

Offne FB

172. Durchlaufe Ressourcen

Wenn Ressource vom Typ:

webcontent: ¨

Ubernehme Ressource

20transform: ¨

Ubersetze Ressource

map: Nutze Loader und [bearbeite Kurs]

5.5.2 Transformationspaket

Nachdem die Datenhaltung der modularen E-Learning-Inhalte detailiert beschrieben wur-

de, wird im Folgenden das zu einer ¨

Ubersetzung definierte Regelwerk erl¨

autert. Die Verwal-

tung der ¨

Ubersetzungsregeln soll ebenso austauschbar sein, wie die Bausteine selbst. Das

4Die in eckigen Klammern gesetzten Textfragmente bezeichnen rekursive Aufrufe und bewirken einen

Sprung zu einer anderen Zeile.

5.5. TRANSFORMATION 101

Ziel ist die Erzeugung m¨

oglichst vieler unterschiedlicher Formate, die zudem mit spezifi-

schen Layoutmerkmalen versehen sind. Hierf¨

ur ist es zweckm¨

aßig, alle f¨

ur die ¨

Ubersetzung

relevanten Daten in einem Paket zusammenzufassen, das ¨

uber einheitliche Schnittstellen

verf¨

ugt. Ein solcher Ansatz erm¨

oglicht, die f¨

ur die Kurserzeugung relevanten Daten, aus-

zutauschen, um unterschiedliche Repr¨

asentationen f¨

ur einen Kurs zu produzieren. Ebenso

wird die Entwicklung spezieller Werkzeuge erm¨

oglicht, die ¨

uber diese einheitliche Schnitt-

stelle Layouts anpassen oder neue erzeugen k¨

onnen. Hieraus ergibt sich folgende Beziehung:

formatierbarerKurs +T ransformationspaket =Lernobjekt (5.1)

Wird das Transformationspaket ausgetauscht, ¨

andert sich zwangsl¨

aufig das zu erstel-

lende Lernobjekt. Das Transformationspaket enth¨

alt die Ressourcen, die f¨

ur eine ¨

Uber-

setzung des formatierbaren Kurses notwendig sind. Hierzu geh¨

oren neben Anwendungen,

einem Schema und der Beschreibung auch die assoziierten ¨

Ubersetzungsregeln. Letztere

werden durch so genannte Transformatoren angegeben, die mit verschiedenen Techniken

implementiert werden. F¨

ur die ¨

Ubersetzung kann z. B. die in Abschnitt 3.2.1 vorgestellte

extended Stylesheet Language (XSL) eingesetzt werden. Ferner lassen sich andere Tech-

niken verwenden, wie z. B. die Java XML-Schnittstelle JDOM [Harold02a,JDO05]. Mit

dieser Schnittstelle k¨

onnen XML-Dokumente spielend durchlaufen und gestaltet werden.

Weiterhin werden Anwendungen ben¨

otigt. Sie bearbeiten Dokumente f¨

ur den Fall, dass

erst ein Zwischenformat generiert werden muss. Dieses wird beispielsweise bei der Erstel-

lung von Formating Objects Dokumenten (FO) generiert, da es mit einem FO-Prozessor in

ein PDF-Dokument konvertiert werden muss. Ein anderes Beispiel ist die Erzeugung von

Latex-Dokumenten, aus denen erst mit einem Latex-Prozessor das PDF- oder DVI-Format

erzeugt wird.

Jedes Transformationspaket enth¨

alt die Sprachdefinition f¨

ur die formatierbaren Bau-

steine. Der Sinn und Zweck, der mit der Zuordnung eines beliebigen Schemas erf¨

ullt wird,

liegt in der Allgemeing¨

ultigkeit der Pakete. Somit lassen sich je nach Anwendungskontext

andere Sprachen bestimmen, die mit diesem Paket ¨

ubersetzt werden k¨

onnen. Außerdem

lassen sich spezialisierte Spracherweiterungen und die damit verbundene Anreicherung der

Ubersetzungsregeln f¨

ur einen Transformator in demselben Paket durchf¨

uhren.

Bei der ¨

Ubersetzung einzelner Bausteine wird in vielen F¨

allen eine Nachbearbeitung

ben¨

otigt. M¨

ogliche Anwendungsf¨

alle sind die ¨

Ubersetzung von Formeln in eine bestimmte

Darstellung, die Anpassung der Bausteine an ein einheitliches metrisches System sowie die

Konvertierung von Bildformaten. Diese Spezialaufgaben sollen m¨

oglichst flexibel einstell-

bar sein. Deshalb k¨

onnen jedem Transformator Prozessoren zugeordnet werden, die den

Baustein entweder vor der ¨

Ubersetzung oder im Anschluss bearbeiten. Prozessoren sind

ebenso wie Anwendungen Programme, die sich innerhalb des Pakets befinden.

Abbildung 5.19 veranschaulicht in Anlehnung an das IMS Content Package Informati-

on Model den Aufbau des Transformationspakets. Es sind komprimierte Archive mit einem

Manifest und einer variablen Anzahl an Dateien. Das Manifest entspricht einer Beschrei-

bung der enthaltenen Ressourcen und ordnet ihnen gewisse Aufgaben zu. Aufgrund des

102

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Dateien

(Zur Erstellung eines

Layouts, Stylesheets, Icons)

Manifest

Manifest Datei

Transformationspaket

Schema

Prozessoren

Transformatoren

Anwendungen

Layout

Abbildung 5.19: Transformationspaket

spezifizierten Aufbaus, kann ein beliebiges Programm das Transformationspaket verarbei-

ten und f¨

ur die ¨

Ubersetzung eines formatierbaren Kurse heranziehen.

Der strukturelle Aufbau des Manifests wird in Abbildung 5.20 illustriert. Das Mani-

fest ist zugleich das Wurzelelement und der Container f¨

ur die Elemente Transformatoren,

Anwendungen, Schemata, Ressourcen und Layout. Tabelle C.2 enth¨

alt eine detaillierte

Beschreibung der Elemente mit ihren Attributen. Jedes Manifest enth¨

alt eine Ressourcen-

Liste, von denen mehrere Dateieintr¨

age besitzen. Diese Ressourcen dienen zur allgemeinen

Dateiverwaltung und k¨

onnen via Identifier referenziert werden.

In jedem Manifest m¨

ussen mindestens zwei Transformatoren definiert werden, damit

den Minimalanspr¨

uchen f¨

ur die ¨

Ubersetzung gen¨

uge getan wird. Ein Transformator wird

f¨

ur die ¨

Ubersetzung, der in einem Baustein definierten Dokumente, ben¨

otigt und ein wei-

terer f¨

ur die Umwandlung der Kursstruktur in das Ausgabeformat. Jeder Transformator

verf¨

ugt ¨

uber einen Namen, eine Id, einen Typ, der den Transformator die gew¨

unschte

Aufgabe zuordnet, sowie eine Dateiendung, die f¨

ur das zu erstellende Format notwendig

ist. Zu einem Transformator geh¨

oren in der Regel eine oder mehrere Dateien. Wird z. B.

ein XSL-Transformator eingesetzt, ist dieser auf mehrere Stylesheets angewiesen. Diese

werden im Transformationspaket als Ressourcen deklariert und lassen sich per identi-

fierRef attributieren. Ein Programm, welches das Transformationspaket verwendet, kann

anhand des Identifiers den Ressourcen-Ast durchwandern, bis der referenzierte Identifer

5.5. TRANSFORMATION 103

Transformer

2..*

Manifest

Liste der Transformatoren

Wurzelknoten des Transformations−

pakets

Definiert einen Transformer

0..* Prozessor Definiert einen Prozessor

Transformers

0..* Resource

Resourcen

0..* Task

Tasks Liste der Anwendungen

Definiert Anwendung

Definiert ein Schema

Sceme

File

1..*

Dateien der Resource

Definiert eine Resource

Liste der Resourcen

Layout Transformationspakets

Speicher das Layout zu einem

Abbildung 5.20: Modell des Transformationspakets

mit dem der Ressource ¨

ubereinstimmt, und die Dateien verarbeiten. Zus¨

atzlich k¨

onnen

einem Transformator mehrere Prozessoren zugewiesen werden, die ebenso wie Transfor-

matoren mit einer Ressource assoziiert sind. F¨

ur den Fall, dass sie als aktiv markiert sind,

werden sie in der durch das Attribut order festgelegten Reihenfolge aufgerufen, um den

Inhalt zu verarbeiten.

Die Liste der Anwendungen werden mit dem tasks-Element gruppiert. Ein Task ent-

h¨

alt den ausf¨

uhrbaren Programmcode, der wieder mit einer Ressource assoziiert ist. Die

zugrunde liegende Sprache wird ¨

uber das lang-Attribut angegeben. Der Typ gibt Auf-

schluss dar¨

uber, ob die Anwendung vor der ¨

Ubersetzung gestartet werden soll, oder erst

nachdem der Kurs komplett ¨

ubersetzt wurde. Anwendungen, die vor der ¨

Ubersetzung ge-

startet werden, k¨

onnen z. B. Systemvariablen setzen, wogegen Anwendungen, die nach der

Ubersetzung laufen, das Resultat prozessieren, wie der bereits erw¨

ahnte FO-Prozessor.

Abschließend werden Schema und Layout des Transformationspakets definiert. Ge-

104

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

nauso wie die Transformatoren und Prozessoren, verweisen Schema- und Layout-Knoten

ebenfalls auf Ressourcen und damit auf die Dateien, die die jeweiligen Sprach- und Layout-

Definition enthalten.

Die Bezeichnung des Transformationspakets wird direkt im Manifest-Element mit dem

Attribut desc hinterlegt. Durch die Referenz auf eine Ressource l¨

asst sich außerdem eine

Icon-Datei hinterlegen. Diese zus¨

atzlichen Attribute werden zur Anzeige innerhalb von

Applikationen oder Servern genutzt, um ¨

uber deren Inhalt und Ausgabeziel zu informieren.

Navigation

Inhalt

Dateien

Prozessor

Navigation

Inhalt

Dateien

Navigation

Inhalt

Dateien

Prozessor

Frame

PDF

HTML

PDF

TEX

TP A

TP B

TP C

Assets

Frame

Inhalt (HTML)

Navigation

Assets

Dokument

Assets

Dokument

Lektion

Assets

Content

Abbildung 5.21: Abbildung

Abbildung 5.21 demonstriert die Vielseitigkeit von Transformationspaketen, indem ein

formatierbarer Kurs auf die drei unterschiedlichen Formate HTML,PDF (FOP) und PDF

(Latex) abgebildet wird. Die Kursstruktur der FK-Komponente wird mit dem jeweiligen

Transformator Navigation in eine Repr¨

asentation des Ausgabeformats ¨

ubersetzt.

Die FB-Komponenten enthalten neben dem Inhalt auch die dazugeh¨

orenden Assets

und werden mit dem Transformator Inhalt in das Ausgabeformat ¨

ubersetzt. Diese beiden

Transformatoren sind Bestandteil aller abgebildeten Transformationspakete. TP A ver-

5.5. TRANSFORMATION 105

f¨

ugt im Gegensatz zu TP B und TP C ¨

uber einen weiteren Transformator, der f¨

ur die

Erzeugung eines HTML-Framesets zwingend ben¨

otigt wird. Das Frameset ist eine HTML-

Seite, die die erzeugte Navigation mit den generierten HTML-Seiten verbindet und den

Inhalt der Bausteine anzeigt. Dadurch ist es m¨

oglich, die Navigation w¨

ahrend der Abar-

beitung des Kurses permanent pr¨

asent zu haben. Anwendungen werden f¨

ur dieses Format

nicht ben¨

otigt, da bereits die Transformatoren das Endergebnis liefern. Die Gestaltung von

PDF-Dokumenten ben¨

otigt hingegen einen weiteren Verarbeitungsschritt, wodurch f¨

ur TP

Bund TP C jeweils eine Anwendung eingesetzt wird. TP B erzeugt, im Gegensatz zu

TP A, nur ein FO-Dokument und wird anschließend, mit dem FO-Prozessor, in ein PDF-

Dokument ¨

ubersetzt. ¨

Ahnlich wie bei TP B wird bei TP C pdflatex eingesetzt, um aus

den erzeugten TEX-Quellen ein PDF-Dokument zu generieren.

5.5.3 Prozessoren

Prozessoren wurden bereits im vorigen Abschnitt erw¨

ahnt und sollen hier n¨

aher erl¨

autert

werden. Bei der ¨

Ubersetzung von Inhalten treten immer wieder individuelle W¨

unsche und

Bed¨

urfnisse auf, die nicht mit herk¨

ommlichen Abbildungsverfahren, wie z. B. Stylesheets,

zu realisieren sind. Vielmehr werden eigenst¨

andige Prozesse ben¨

otigt, die spezielle, f¨

ur das

Ausgabeformat angepasste, Mechanismen zur Verf¨

ugung stellen. Ein Beispiel hierf¨

ur ist

die Verarbeitung von Formeln. Aus heutiger Sicht ist es durchaus sinnvoll, Formeln als

Grafiken in Webseiten einzubauen, wie es bei herk¨

ommlichen Latex zu HTML-Konvertern

ublich ist. Es ist jedoch abzusehen, dass MathML oder OpenMath (vgl. Kapitel 3.2.4)

von den f¨

uhrenden Browser-Herstellern in naher Zukunft unterst¨

utzt werden. Aus diesem

Grund ist die Erzeugung verschiedener Formelrepr¨

asentationen zweckm¨

aßig.

Des weiteren wurde das Baukastenprinzip eingef¨

uhrt, um m¨

oglichst unabh¨

angig vom

Ausgabeformat zu sein. Soll beispielsweise Latex generiert werden, so m¨

ussen Formeln

in Latex gesetzt werden, wodurch eine Formel¨

ubersetzung notwendig ist. Genau f¨

ur sol-

che Anwendungsf¨

alle muss ein allgemeiner Mechanismus gefunden werden, der sowohl die

Definition individueller L¨

osungen unterst¨

utzt als auch flexibel einzusetzen ist. Abbildung

5.22 zeigt hierf¨

ur einen Ansatz, der Dokumente seriell durch eine Prozessor-Pipeline de-

legiert. Jeder Prozessor bearbeitet das Quelldokument und ¨

ubergibt sein Resultat an den

in der Reihenfolge als n¨

achsten nominierten Prozessor. Sie werden entweder durch eine

externe Applikation als ¨

Ubersetzungsoption zur Auswahl angeboten oder direkt in das

Transformationspaket verankert.

5.5.4 Layout

Das Transformationspaket ist ein allgemeiner Container f¨

ur Transformatoren und Pro-

zessoren. Zwar wurde bis jetzt noch nicht n¨

aher auf die ¨

Ubersetzungsregeln eingegangen,

es ist jedoch festzuhalten, dass ihre Beschreibung in Abh¨

angigkeit von dem zu erzeugen-

den Format technisch formuliert werden. Die Frage, die sich jetzt stellt, ist, wie zu einem

festgelegten Format ein korrespondierendes Layout erstellt werden kann, ohne dass in den

technischen Abbildungprozess eingegriffen wird. Hierf¨

ur ist eine strikte Trennung zwischen

106

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

P1 P2 Pn

P1 P2 Pm

Quelle

Ziel

Transformationspaket

Extern

Abbildung 5.22: Prozessorpipeline

den Regeln, die f¨

ur die Formaterzeugung ben¨

otigt werden, und der Pr¨

asentation bzw. dem

Layout notwendig. Bei der Vielfalt der verschiedenen Ausgabeformate ist jedoch die pr¨

zise Festlegung des Layouts f¨

ur das zu erzeugende Format nicht m¨

oglich. Jedes Format

besitzt spezielle Eigenschaften und l¨

asst nur einen begrenzten Spielraum f¨

ur eine allge-

meine Beschreibung zu. Als Beispiel dienen die bereits erw¨

ahnten Ausgabeformate HTML

und PDF. Bei PDF-Dokumenten wird z. B. die Seitengr¨

oßen angegeben, wogegen HTML-

Seiten dynamische L¨

angen und Breiten ben¨

otigen. Außerdem lassen sich HTML-Seiten

durch den Einsatz von Framesets und Tabellen wesentlich flexibler gestalten, als es bei

PDF-Dokumenten m¨

oglich ist. Aus diesem Grund muss ein abstrakter Beschreibungsme-

chanismus gefunden werden, der die wesentlichen stilistischen Einstellungen speichert und

diese den Transformatoren zur Verf¨

ugung stellt.

Aus dieser Separation folgt die Modifikation, ohne detaillierte Kenntnisse ¨

uber das

zu erzeugende Format zu besitzen. Dieses f¨

uhrt zu den zwei Benutzersichten bzw. Rollen

Formaterzeuger/-in und Layoutanpasser/-in, die im Folgenden n¨

aher erl¨

autert werden.

•Formatentwickler/-in: Die Rolle des Formaterzeugers ben¨

otigt ein fundiertes Wissen

uber das zu erstellende Format. Sie definiert das Basis-Layout und legen dar¨

uber

hinaus die einstellbaren Merkmale fest, die ¨

uber eine festgelegte Schnittstelle der

Rolle Layoutentwickler/-in bekannt gegeben werden.

•Layoutentwickler/-in: Diese Rolle ben¨

otigt nicht das technische Wissen ¨

uber das

zu erzeugende Format. Sie entscheidet ¨

uber die Darstellung des Ausgabeformats,

indem sie ein Layout definiert und es ¨

uber die von der Rolle Formatentwickler/-in

bereitgestellte Schnittstelle verbindet.

Abbildung 5.23 veranschaulicht diesen Zusammenhang. Die Rolle Formatentwickler/-

in erzeugt die notwendigen Transformatoren T1bis Tnund definiert dar¨

uber hinaus die

Stellen, an denen Layoutmerkmale Bestandteil des Formats sind und sp¨

ater dynamisch

5.5. TRANSFORMATION 107

zugewiesen werden sollen. Sie erzeugt das Layout, indem zun¨

achst die Maße f¨

ur die Pr¨

sentation definiert werden. Des weiteren werden Layouteigenschaften wie Schriftentypen

und Farben f¨

ur einzelne Transformatoren spezifiziert.

T 2

T 1

T n

Layout

erzeugt

erzeug

Layoutenwickler/−inFormatentwickler/−in

verbindet

Abbildung 5.23: Rollen

Im Folgenden wird der strukturelle Aufbau des Layouts untersucht. Das Layout be-

steht aus zwei Teilen: dem Master-Layout, zur Definition der Seitenformatierung, und den

Style-Eigenschaften, die als Auswahlkatalog f¨

ur Transformatoren dienen. Mit dem Seiten-

Master werden detailierte Angaben ¨

uber den Aufbau einer Seite definiert. Hierzu geh¨

oren

die H¨

ohe und Breite einer Seite, genaue Angaben ¨

uber den zu verwendenden Seitenaus-

schnitt (Body) sowie Kopf- und Fußzeilen. Diese Angaben sind jedoch nicht zur Definition

eines Layouts ausreichend. Es werden weitere Angaben ¨

uber stilistische Merkmale einer

Pr¨

asentation ben¨

otigt, wie Schrifttypen, Schriftgr¨

oßen oder auch Farbwerte. Liegt eine

umfangreiche Liste mit Layouteigenschaften vor, werden sie auf die jeweiligen Transfor-

matoren abgebildet. Hierbei findet die Zuordnung der im Layout festgelegten Eigenschaften

zu den in den Transformatoren verwendeten Ressourcen statt. Der Vorteil, der sich aus

einer solchen Abbildung ergibt, ist die Mehrfachnutzung definierter Eigenschaften. So k¨

on-

nen festgelegte Farben durch mehrere Transformatoren verwendet werden und m¨

ussen nur

an einer Stelle, dem Layout, ge¨

andert werden. Abbildung 5.24 zeigt das Zusammenspiel

zwischen Transformationspaket und Layout.

Das Layout l¨

asst sich, ebenso wie das Manifest eines Transformationspakets, hierar-

chisch aufbauen (vgl. Abbildung 5.25 und Tabelle C.3). Der Wurzelknoten Layout dient

als Container f¨

ur Master,Styles und Mapping Elemente. Das Master-Element ist selbst

ein Container f¨

ur die Elemente, die den Aufbau einer Seite beschreiben. Es enth¨

alt das

Page-Element, zur Speicherung der genauen metrischen Maße einer Seite, sowie das Body-

108

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Master

Properties

Transfromator 2

Transfromator 1

Transfromator n

Dateien

Mapping

Layout

Abbildung 5.24: Abbildung des Layouts auf die Transformatoren

Element, zur Spezifikation der Seitenr¨

ander. Zus¨

atzlich k¨

onnen Kopf- und Fußzeilen defi-

niert werden, soweit sie f¨

ur das zu erzeugende Ausgabeformat relevant sind.

Neben den Gr¨

oßenangaben enth¨

alt ein Layout Styles. Jeder Style entspricht selbst

einer Aggregation aus Eigenschaften, die einen Typ besitzen, der aussagt, um welches Lay-

outmerkmal es sich handelt. Aufgrund der Formatvielfalt, die mit Transformationspaketen

erzeugt werden kann und die damit verbundene individuelle technische Umsetzung, ist eine

separate Speicherung der Layouteigenschaften notwendig, damit sie an beliebigen Stellen

von Transformatoren abgerufen werden k¨

onnen. Diesbez¨

uglich sollen ausschließlich die in

Tabelle 5.5.4 definierten Typen eingesetzt werden. Der Vorteil, der sich aus diesem Ansatz

ergibt, liegt auf der Hand. Die Struktur der Dokumente wird innerhalb der ¨

Ubersetzungsre-

geln bearbeitet, wobei der eindeutige Bezug zur Sprachdefinition der Bausteine hergestellt

wird. Genau solch ein Bezug soll in der Layout-Definition nicht vorhanden sein. Vielmehr

muss eine lose Kopplung zwischen der Layoutbeschreibung und den Transformatoren be-

stehen, damit eine Ver¨

anderung des Layouts nicht zwangsl¨

aufig zu einer Modifikation der

Transformatoren f¨

uhrt. Dieses ist vor allem dann vorteilhaft, wenn Transformatoren nicht

als Skriptsprachen implementiert werden und deshalb nicht modifiziert werden k¨

onnen.

Um letztendlich die Verbindung zu den Transformatoren herzustellen, muss die Zu-

ordnung der definierten Styles zu den festgelegten Layoutmerkmalen hergestellt werden.

Realisiert wird diese Zuordnung durch eine Liste von Reference-Elementen, die einerseits

definierte Styles mit Identifier referenzieren und andererseits den Namen des im Trans-

formator festgelegten Merkmals enthalten. Hierdurch findet die eindeutige Abbildung der

Style-Definitionen zu den Transformatoren statt. Das Ergebnis ist ein separiertes Lay-

out, das sich unabh¨

angig von Transformatoren ver¨

andern l¨

asst. Hierbei k¨

onnen sowohl die

Layout-Eigenschaften als auch deren Zuordnungen angepasst werden.

5.6. KOOPERATION 109

Typ Verwendung

integer Eine ganze Zahl

dezimal Eine Zahl mit Nachkommastellen

boolean Definiert einen boolschen Wert

align Legt die Textausrichtung fest

percent Speichert einen Prozentwert

string Definiert einen variablen Text

image Verweist auf eine austauschbare Abbildung

color Eine Farbe in RGB-Notation

font Legt einen Schrifttyp fest

fontsize Schriftgr¨

oße in Punkten

fontfamily Name einer Schriftart

chooser Auswahlliste f¨

ur eine Zeichenkette

Tabelle 5.4: Layouttypen

5.6 Kooperation

Nachdem das Modell zur Konstruktion von formatierbaren und modularen Lernmateriali-

en vorgestellt worden ist, wird in diesem Kapitel der Fokus auf die koopertative Entwick-

lung gerichtet. Die formatunabh¨

angige Darstellung der Materialien ist in gr¨

oßeren verteil-

ten Projekten eine wichtige Voraussetzung f¨

ur die Entwicklung von E-Learning-Inhalten.

Hierbei k¨

onnen Materialien an verschiedenen Standorten und von unterschiedlichen Ent-

wicklern und Entwicklerinnen konstruiert, ausgetauscht und zusammengeschn¨

urt werden.

Genau diese M¨

oglichkeit bieten die in Kapitel 2 vorgestellten Systeme nicht an. Mit ihnen

lassen sich lediglich spezialisierte Kursunterlagen erzeugen, bei denen das Format und Lay-

out fest verankert ist. Dabei wird zwangsl¨

aufig der vom Entwickler bzw. von der Entwick-

lerin pr¨

aferierte Einsatzkontext festgelegt. Diese Kurse lassen sich aufgrund der fehlenden

Orthogonalit¨

at und Granularit¨

at nicht ohne weiteres aggregieren, von den unterschiedli-

chen Pr¨

asentationsformaten abgesehen. Aus diesem Grund ist es sinnvoll, Kursunterlagen

mit dem in diesem Kapitel vorgestellten Modell zu beschreiben, damit Materialien nicht

nur formatunabh¨

angig definiert werden, sondern sich auch durch unterschiedliche Anwen-

der bzw. Anwenderinnen wiederverwenden lassen. Gerade im universit¨

aren Umfeld bewirkt

die Wiederverwendung bereits erstellter Materialien eine erhebliche Kostenreduktion bei

der Entwicklung neuer Inhalte.

Es ist keineswegs sinnvoll, Kurse per E-Mail zu verschicken und an anderen Standorten

weiter zu bearbeiten. Das Problem ist, die Schwierigkeit zwischen Original und Kopie zu

unterscheiden. F¨

ur einen solchen kooperativen Entwicklungsprozess ist es wesentlich effi-

zienter, die Kurse und Bausteine dezentral zu verwalten und ein Entwicklungsrepository

zur konsistenten Datenhaltung zu verwenden. In Relation zu dem in diesem Kapitel vor-

gestellten Baukastenprinzip entspricht das Repository dem Baukasten.

110

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Layout

Master

Page

Body

Header

Footer

Wurzelknoten des Layouts

Spzifiziert die grundlegende Struktur

Definiert eine Seite

Legt den Inhalt einer Seite fest

Spezifiziert die Kopfzeile

Spezifiziert die Fußzeile

0..*

Styles

Style

Property

Container für die Styles

Spezifiziert einen Style

Definiert eine Eigenschaft eines Styles

1..*

0..*

Verbindet die Eingenschaften mit

dem Transformator

Legt eine Zuordnung fest

Map

Reference

Abbildung 5.25: Spezifikation des Layouts

5.6.1 Der kooperative Entwicklungsprozess

In Kapitel 5.1.3 wurde bereits der Entwicklungsprozess f¨

ur die Erstellung formatierba-

rer Kurse vorgestellt. An dieser Stelle soll dieser Prozess wieder aufgegriffen werden und

unter besonderer Ber¨

ucksichtigung des Aspekts Kooperation untersucht werden. Deshalb

werden die Rollen Bausteinentwickler/-in,Kurszusammensteller/-in und Umsetzer/-in zu

der Rolle Autor/-in vergr¨

obert. Sie ist zwingend notwendig, weil in diesem Abschnitt aus-

schließlich das Zusammenspiel mehrerer Autoren von Interesse ist. Die anderen Rollen

werden soweit beibehalten.

An einem kooperativen Entwicklungsprozess sind mindestens zwei Autoren bzw. Auto-

rinnen beteiligt. Sie verf¨

ugen ¨

uber ein Autorensystem, das formatierbare Bausteine, nach

dem in Kapitel 5.2 vorgestellten Modell, aggregieren und transformieren kann. Hierbei

findet der Erstellungsprozess der formatierbaren Bausteine dezentral mit jedem Autoren-

system statt. Erst nachdem ein Baustein oder ein kompletter Kurs fertig gestellt ist, kann

dieser anderen Autoren und Autorinnen angeboten werden. Arbeiten zwei Personen an

5.6. KOOPERATION 111

einem Kurs oder teilen sich bei der Kurserstellung bestimmte Bereiche, k¨

onnen sie per

Dateisystem oder via E-Mail verschickt werden. Arbeiten hingegen mehrere Entwickler

und Entwicklerinnen an einem Kurs, wird der Entwicklungsprozess schnell un¨

ubersichtlich

und es kann zu Inkonsistenzen und Datenverlusten kommen, weil Kurs bzw. Bausteine

von mehreren Personen gleichzeitig modifiziert werden. F¨

ur diesen Fall bietet sich die Ver-

waltung auf einem zentralen Server an, auf den die am Entwicklungsprozess beteiligten

Parteien gleichermaßen zugreifen k¨

onnen. Abbildung 5.26 verdeutlicht diesen Zusammen-

hang. Bei einer Kooperation von mTeams existieren nAutorensysteme, die mit mehreren

der jRepositories verbunden sein k¨

onnen. Entsprechend dem Baukastenprinzip werden

die Repositories metaphorisch als Baukasten bezeichnet, wodurch sich der Begriff Con-

struktion Kit Server CKS ableitet. Jedes Autorenwerkzeug ist in der Lage, die von ihm

erstellten Bausteine und Kurse auf einem CKS abzulegen und sie dadurch anderen an-

zubieten. Als Beispiel kann das erste Team einen Online-Kurs f¨

ur das Anwendungsfach

Technische Informatik erstellen. Zwei studentische Mitarbeiter entwickeln hierf¨

ur einen

Kurs, der sp¨

ater studienbegleitend eingesetzt werden soll. Jeder der Studenten setzt sein

eigenes Autorensystem ein, welches jeweils mit dem ersten CKS verbunden ist. So ist es

f¨

ur beide m¨

oglich, an demselben, auf dem CKS gespeicherten, Dokument zu arbeiten. Ei-

ner der Autoren verfasst das Thema Wechselstromschaltungen und m¨

ochte einen Exkurs

zum Thema Komplexe Zahlen anbieten. Dieser existiert bereits auf einem anderen CKS,

und wurde von einem anderen Team entwickelt. Team mverwendet jedoch die Komplexen

Zahlen in einem anderen Zusammenhang, n¨

amlich als Skriptum in einer Pr¨

asenzveran-

staltung. Aufgrund des eingef¨

uhrten allgemeinen Modells, ist es ohne großen Aufwand

m¨

oglich, den Kurs von Team min den eigenen Kurs einzubauen und ihn innerhalb der

Online-Pr¨

asentation zu nutzen.

Der CKS wird im Gegensatz zu einem LMS oder einem ¨

offentlichen Respository als

Entwicklungsplattform f¨

ur formatierbare Kurse und Bausteine eingesetzt, die ohne eine

entsprechende Transformation von Studierenden oder Lehrenden nicht genutzt werden

k¨

onnen. Nach der Fertigstellung des Kurses kann er durch eine Transformation f¨

ur das

jeweilige Einsatzgebiet genutzt und mit einem individuellen Layout versehen werden. Der

einfachste Anwendungsfall ist der Einsatz eines Web-Browsers, der HTML oder PDF In-

halte direkt anzeigt. Soll jedoch ein LMS eingesetzt werden, lassen sich Kurse dort direkt,

durch Erzeugung eines IMS Content Package kompatiblen Pakets, importieren. Außerdem

k¨

onnen transformierte Inhalte als Lernobjekte anderen Entwicklern und Entwicklerinnen

in ¨

offentlichen Respositories angeboten werden. Hierdurch zeichnet sich der Vorteil ge-

gen¨

uber allgemeinen Lernobjekte ab, die nicht modular, austauschbar und ver¨

anderbar

sind.

5.6.2 Operationen

Wie bereits in Abschnitt 2.3.2 erl¨

autert wurde, arbeitet das IMS an einer Spezifikati-

on f¨

ur die Konzeption von Lernobjekt-Repositories. Sie spezifizieren den Zugriff und das

Auffinden von Lernobjekten. Im Gegensatz dazu dient der CKS als Entwicklungsplatt-

form, auf dem die Quellen der Bausteine und Kurse abgelegt werden. Aus diesem Grund

112

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

HTML

PDF

Content Package

CKS 1

Tool 2

Authoring

Tool 1

Authoring

FK/FB

System (LMS)

Management

Learning

Webbrowser

Kurserstellung

Team 1

CKS j

Tool n

Team m

Administrator/−in Author/−in Studierende/

Lehrende

Repository

DRI

Z39.50

Content Package

Abbildung 5.26: Der Construction Kit Server

werden f¨

ur den Entwicklungsprozess, neben Suchverfahren, entsprechende Mechanismen

zur kooperativen Arbeit ben¨

otigt. Diese sind das exklusive Schreibrecht auf Dateien, eine

Versionskontrolle sowie Authentifizierungsmechanismen.

Wird ein Baustein von einem Autor bzw. einer Autorin bearbeitet, soll zu diesem Zeit-

punkt keine Ver¨

anderung durch eine andere Person stattfinden. Hierf¨

ur muss das exklusive

Schreibrecht erworben werden, das zwar das ¨

Offnen eines bereits verwendeten Bausteins

erm¨

oglicht, jedoch nicht das Abspeichern. Dieses Verfahren wird bei jedem modernen Be-

triebssystemen eingesetzt und f¨

uhrt auf das Leser-Schreiber-Problem der theoretischen

Informatik zur¨

uck [Valk80,Engesser93]. Es tritt dann auf, wenn mehrere Autoren bzw.

Autorinnen am selben Dokument arbeiten. Ein anderes Verfahren, wie es bei CVS (Con-

curent Version Control) eingesetzt wird, bietet die Arbeit mit Kopien an. Das Original

verbleibt auf einem Server und wird bei jedem Client als Kopie angelegt.

Soll eine bearbeitete Kopie wieder auf dem Server gespeichert werden, muss das Ori-

ginal ersetzt werden. Zuvor muss jedoch ein m¨

oglicher lokaler Konflikt behoben werden,

der genau dann entsteht, wenn zwei Autoren bzw. Autorinnen an derselben Stelle ei-

5.6. KOOPERATION 113

nes Dokuments arbeiten. Um einen m¨

oglichst einfachen Zugriff auf den CKS anzubie-

ten, wird das WebDAV-Protokoll [Goland99] angeboten, mit dem Dateisysteme ¨

uber das

HTTP-Protokoll [Fielding99] eingebunden werden und so einfach ¨

uber einen Webserver

realisiert werden k¨

onnen. WebDAV unterst¨

utzt das exklusive Schreiben und bietet somit

Lock-Operationen auf Dateien an.

Ein weiterer wichtiger Mechanismus ist die Versionskontrolle. Durch sie kann der Ent-

wicklungsprozess ¨

uberwacht und im Bedarfsfall ein in der Vergangenheit liegender Ent-

wicklungszustand wiederhergestellt werden. Eine Funktion, die sich dadurch ergibt, ist

z. B. das Markieren der aktuellen Version, damit sie zu einem sp¨

ateren Zeitpunkt mit

einem fr¨

uheren Entwicklungsstand zusammengef¨

uhrt werden kann.

Die bisherigen Mechanismen kommen jedoch nicht ohne einen Authentifizierungsme-

chanismus aus. Werden Dateien gelockt oder neu erstellt, m¨

ussen individuelle Rechte an

den Anwender bzw. an die Anwenderin vergeben werden. Dieses ist nur dann durchf¨

uhr-

bar, wenn er bzw. sie innerhalb des Systems bekannt ist, denn bei einer Datei, die nur

im Lese-Modus ge¨

offnet werden kann, weil sie zur selben Zeit bereits von einer anderen

Person bearbeitet wird, muss die Person, die das exklusive Schreibrecht besitzt, ermittelt

werden. Im Zusammenhang mit der Versionierung ist es notwendig festzustellen, welcher

Autor bzw. welche Autorin die ¨

Anderung durchgef¨

uhrt hat.

114

KAPITEL 5. EIN MODELL ZUR ENTWICKLUNG KONSISTENTER

LERNMATERIALIEN

Kapitel 6

Umsetzung

Bisher wurde ein Modell zur Konstruktion homogener Kursmaterialien eingef¨

uhrt, wel-

ches gezielt abstrakt formuliert wurde, damit unterschiedliche Technologien, wie z. B.

Datenbanksysteme oder XML-Dokumente, f¨

ur die Realisierung eingesetzt werden k¨

onnen.

In diesem Kapitel wird nachfolgend eine dem Modell zugrunde liegende Referenzimple-

mentierung vorgestellt, die die wesentlichen Eigenschaften des Konzepts verdeutlicht und

dessen Realisierbarkeit nachweist.

6.1 Das Autorenwerkzeug Lyssa

Das in Kapitel 5 vorgestellte Modell ist in dem Autorenwerkzeug Lyssa umgesetzt worden,

das somit als Referenzimplementierung gilt. Der folgende Abschnitt veranschaulicht nun-

mehr, wie das Modell der Formatierbaren Bausteine und Kurse sowie das Kursmodell und

das Transformationspaket in einer gemeinsamen Architektur zusammenspielen. Eine zen-

trale Eigenschaft des Autorenwerkzeugs Lyssa ist die dem Baukastenprinzip (vgl. Kapitel

5.3) entsprechende Erstellung modularer Bausteine. Mit einer grafischen Benutzerschnitt-

stelle (GUI) k¨

onnen Autoren und Autorinnen auf einfache Weise Bausteine erzeugen und

sie mit anderen Bausteinen individuell kombinieren. Diese Komposition ergibt einen Kurs,

der wieder in seine Bestandteile zerlegt werden kann. Hierdurch entsteht ein flexibles Be-

nutzungsmodell, das die Entwicklung interdisziplin¨

arer Lernmaterialien erst erm¨

oglicht.

Das Autorensystem verwendet das Modell der Formatierbaren Bausteine und Kurse, wo-

durch sichergestellt ist, dass Bausteine verschiedener Autoren und Autorinnen kompatibel

zueinander sind und nahtlos zu neuen Kursen zusammengef¨

uhrt werden k¨

onnen.

Das System wurde basierend auf mehreren wissenschaftlichen Arbeiten entwickelt, die

in Tabelle 6.1 aufgef¨

uhrt sind. Die Realisierung der grafischen Benutzerschnittstelle sowie

der Software-API zum Verwalten von Archiven und IMS Content Packages wurde von

Michael Bungenstock durchgef¨

uhrt [Baudry05,Bungenstock03b]. Marc Vollmann hat den

CKS um eine Search Engine auf Schlagwortbasis erweitert, die zwar wegen der Vollst¨

an-

digkeit erw¨

ahnt wird, jedoch in dieser Arbeit nicht weiter vertieft wird.

Die Systemkomponenten, die aus dem in dieser Arbeit entwickelten Modell resultieren,

werden in den nachfolgenden Kapiteln vorgestellt.

115

116 KAPITEL 6. UMSETZUNG

Komponente Verantwortung Kontext Kapitel

File Management Michel Bungenstock Dissertation –

Content Package Engine Michel Bungenstock Dissertation –

Multimedia Environment Michel Bungenstock Dissertation –

Transformation Engine Andreas Baudry Dissertation 6.1.1

Formatierbare Bausteine Andreas Baudry Dissertation 6.1.2

Formatierbare Kurse Andreas Baudry Dissertation 6.1.3

Kursmodell Framework Andreas Baudry Dissertation 6.1.4

DokBook Engine Andreas Baudry Dissertation 6.1.5

Office Engine Andreas Baudry Dissertation 6.1.5

Latex Engine Andreas Baudry Dissertation 6.4

Metadaten Engine Michael Bungenstock Dissertation –

Layout Engine Andreas Baudry Dissertation 6.2

Construktion Kit Server Andreas Baudry Dissertation 6.3

Search Engine Marc Vollmann Diplomarbeit –

Tabelle 6.1: Arbeitsteilung f¨

ur Systemkomponenten

6.1.1 Systembeschreibung

Dieser Abschnitt erl¨

autert die Funktionsweise des Autorensystems Lyssa. Das Benutzungs-

modell ist an die Arbeit mit einem Dateisystem angelehnt. Abbildung 6.1 zeigt das Auto-

rensystem mit einem bereits ge¨

offneten Kurs. Auf der linken Seite befindet sich die Work-

bench, die ¨

ahnlich, wie der Windows Explorer, aus Ordnern und Dateien aufgebaut ist.

Sie erm¨

oglicht das ¨

Offnen und Verschieben von Assets, Bausteinen und Kursen. Innerhalb

des MDI-Bereichs (Multiple Device Interface) werden ge¨

offnete Bausteine und Kurse an-

gezeigt. Abbildung 6.1 veranschaulicht einen ge¨

offneten Kurs, der um neue Kursabschnitte

erweitert werden kann, indem ein neuer Baustein oder ein Kurs von der Workbench direkt

in die Kursstruktur gezogen und dort abgelegt wird. Ebenso l¨

asst sich eine entsprechende

Disaggregation durchf¨

uhren, indem ein Baustein, der Bestandteil des ge¨

offneten Kurses

ist, einfach mit einer Mausbewegung aus einem Kurs heraus auf die Workbench verscho-

ben wird. Neben gew¨

ohnlichen Bausteinen lassen sich in gleicher Weise ganze Kurse in

andere Kurse ziehen. Auch ihnen wird genau ein Thema in der Kursstruktur zugewiesen.

Die Erweiterung von Kursen durch andere Kurse und Bausteine wird technisch durch die

Verschiebung der Archiv-Dateien in das komprimierte Archiv des ¨

ubergeordneten Kurses

realisiert, wodurch beliebig tiefe Verschachtelungsstrukturen entstehen.

Neben Kursen k¨

onnen mit Lyssa auch Bausteine zum Bearbeiten ge¨

offnet werden. All-

erdings enthalten sie selbst keine Bausteine oder Kurse, sondern Assets mit multimedialem

Inhalt, wie z. B. Videos, Flash-Filme oder Abbildungen. Abbildung 6.2 zeigt exemplarisch

einen ge¨

offneten Baustein, der mehrere Assets aggregiert. Zudem wird in jedem Baustein

eine Datei als Einstiegspunkt definiert. Er dient w¨

ahrend des ¨

Ubersetzungsvorgangs zur

Identifikation des Lernmaterials. Andere Assets lassen sich mit frei w¨

ahlbaren Werkzeugen

erstellen und bearbeiten, und werden nicht explizit in Lyssa eingebunden. Abbildungen

6.1. DAS AUTORENWERKZEUG LYSSA 117

Abbildung 6.1: Das Autorenwerkzeug Lyssa

und Grafiken k¨

onnen z. B. mit Gimp oder Photoshop erstellen werden und danach in

einen Baustein gezogen werden. Sind die Assets fertiggestellt und in den Baustein kopiert,

k¨

onnen sie von dem Content-Modell des Bausteins erfasst und referenziert werden.

Ubersetzungsprozess

Derart erzeugte Kurse und Bausteine sind in dieser Form nicht f¨

ur die Lehre nutzbar. Das

liegt an den aggregierten Kursen und Bausteinen, aber auch an der noch Layout freien

Form der Bausteine. Aus diesem Grund bietet das Autorenwerkzeug Lyssa einen ¨

Uber-

setzungsmechanismus an, der es erlaubt, Kurse in verschiedene Zielformate zu ¨

ubersetzen.

Hierzu wird ein erweiterbares Rahmenwerk zum Einbinden neuer Formate angeboten.

Abbildung 6.3 zeigt den Export-Dialog von Lyssa, in dem sich ¨

Ubersetzungsparameter

einstellen lassen. Der ¨

Ubersetzungsprozess ist im Wesentlichen die Umsetzung des in Ka-

pitel 5.5.2 eingef¨

uhrten Transformationspaketes mit den zugeh¨

orenden Prozessoren. Unter

der Rubrik Media Type wird das zu verwendende Transformationspaket ausgew¨

ahlt, wobei

ein Icon das zu erzeugende Zielformat symbolisiert. Der Schalter Uncompress Archive legt

fest, ob das zu generierende Format als komprimiertes Archiv abgelegt werden soll oder

alternativ in das Dateisystem generiert wird. Dies ist vor allem dann relevant, wenn Pakete

118 KAPITEL 6. UMSETZUNG

Abbildung 6.2: Ansicht des Bausteinfensters

nach dem IMS Content Package Standard erzeugt und direkt von einem LMS eingeladen

werden sollen [Bungenstock03a]. Ferner existieren Formate, wie PDF-Dokumente, bei de-

nen dieser Schalter nicht angezeigt wird, weil er eine, f¨

ur dieses Format, irrelevante Option

darstellt. Im mittleren Bereich werden Prozessoren ausgew¨

ahlt, die zus¨

atzliche Funktionen

f¨

ur den ¨

Ubersetzungsprozess anbieten. Um den ¨

Ubersetzungsvorgang zu ¨

uberwachen, l¨

asst

sich ein Ausgabe-Fenster ¨

offnen, das den Vorgang protokolliert.

6.1.2 Formatierbare Bausteine

Abschnitt 3.2 hat bereits gezeigt, dass g¨

angige Modelle zur Beschreibung von Lernmate-

rialien mit der Extendable Markup Language (XML) gesetzt werden. Aufgrund der wohl-

geformten Struktur und der hierarchischen Anordnung der Elemente, kann eine Realisie-

rung des Content-Modells als bijektive Abbildung der Elementstruktur auf XML-Elemente

stattfinden. XML erm¨

oglicht neben der guten Lesbarkeit auch eine einfache und fehlerto-

lerante Verarbeitung durch technische Systeme. Sollen formatierbare Bausteine allerdings

durch ein technisches System konstruiert werden, sind andere Mechanismen notwendig.

Mit dem so genannten OO-Binding wird das den Bausteinen zugrunde liegende Modell

auf eine physikalisch im Speicher liegende dynamische Datenstruktur abgebildet. Im Fol-

genden werden diese beiden Varianten n¨

aher erl¨

autert.

6.1. DAS AUTORENWERKZEUG LYSSA 119

Abbildung 6.3: Der Export-Dialog

BrickML (XML-Binding)

Jeder Baustein besitzt genau eine XML-Datei, die das Content-Modell speichert. Die-

se Datei wird als Start-Datei definiert und vom ¨

Ubersetzungsprozess verarbeitet. Jedes

Element des Modells l¨

asst sich daraufhin in eine entsprechende XML-Form bringen. In

Abbildung 5.5 wurde bereits der syntaktische Aufbau des Wurzelelements lob vorgestellt.

Das korrespondierende XML-Element wird in spitzen Klammern notiert <lob></lob>. Be-

sitzen Elemente Attribute, so werden sie, entsprechend der XML-Spezifikation, hinter den

Namen des Elements geschrieben und deren Werte mit Anf¨

uhrungsstrichen umschlossen

(vgl. hierzu Abschnitt 3.2.1). F¨

ur den Titel des Bausteins ergibt sich die folgende Nota-

tion: <lob title=’Sinusf¨ormige ...’></lob>. Genau wie das lob-Element lassen sich

alle auftretenden Elemente in einer solchen Repr¨

asentation notieren. Tabelle 6.2 zeigt die

Umsetzung der in Kapitel 5.2.1 definierten Strukturelemente in BrickML-Elemente.

Strukturelement XML-Binding (Beispiel) Beschreibung

lob <lob>... </lob>Lernobjekt

highlight <h>... </h>Hervorhebung

italic <i>... <i/>Kursiv

typewriter <t>... </t>Schreibmaschine

br <br/>Zeilenumbruch

link <link target=”any url”/>URL-Verweis

ws <ws/>Leerzeichen

code <code>... </code>Quellcode

anchor <anchor name=”any name”/>Markierung

n¨

achste Seite

120 KAPITEL 6. UMSETZUNG

Strukturelement XML-Binding (Beispiel) Beschreibung

ref <ref name=”anchor name”/>Referenz

table <table border=1 widht=”any size”>...

</table>

Tabelle

cell <cell>... </>Tabellen-Feld

row <row align=”center”>... </row>Tabellen-Zeile

column <column>... </column>Tabellen-Spalte

heading <heading>... </heading>Tabellen-Kopfzeile

itemize <itemize>... </itemize>Nummerierung

enumerate <enumerate>... </enumerate>Aufz¨

ahlung

item <item>... </item>Element einer Aufz¨

ahlung oder

Nummerierung

mmo <mmo type=”applet” width=”any size”

src=”any URL”/>

Multimedia-Element

param <param/>MMO-Parameter

image <image width=”any size” src=”any

URL”/>

Image-Element

quiz <quiz>... </quiz>Leitet ein Quiz ein

text <text>... </text>Quiz-Beschreibung

question <question>... </question>Gruppiert Fragen

answer <answer>... </answer>Definiert eine m¨

ogliche Antwort

shortquiz <shortquiz>... </shortquiz>Leitet ein Quiz mit L¨

osung ein

sqquestion <sqquestion>... </sqquestion>Gruppiert Fragen

sqanswer <sqanswer>... </sqanswer>Definiert eine m¨

ogliche Antwort

solution <solution>... </solution>Definiert die L¨

osung

definition <definition title=”any Text”>... </de-

finition>

Definition

conclusion <conclusion>... </conclusion>Zusmammenfassung

lemma <lemma>... </lemma>Lemma

notice <notice>... </notice>Anmerkung

hint <hint>... </hint>Hinweis

example <example>... </example>Beispiel

Tabelle 6.2: Abbildung Strukturelemente auf XML-Elemente

Das folgende Beispiel zeigt exemplarisch einen Auszug aus einer Lehreinheit, die mit

der Bausteinbeschreibungssprache BrickML formuliert wurde.

Listing 6.1: Ein einfaches BrickML-Beispiel

<?xml version=”1.0” encoding=”ISO−8859−1” ?>

<lob title=”Sinusf¨

ormige Wechselgr¨

oßen” xml:lang=”de”>

6.1. DAS AUTORENWERKZEUG LYSSA 121

<p>Betrachtung einer beliebigen sinusf¨

ormigen Wechselgr¨

oße

<formula inline=”false”>x(t)=\hat{x}\sin(\alpha+\varphi 0)</formula>

<formula inline=”false”>=\hat{x}\sin(\omega t+\varphi 0),</formula>

wobei:

12<row>

<col>Momentan−oder Augenblickswert der Wechselgr¨

oße</col>

15</row>

<row>

18<col>Maximalwert der Wechselgr¨

oße (Scheitel−,Spitzenwert),

(engl.maximum amplitude)</col>

</row>

21</table>

</p>

</lob>

Dieses Beispiel zeigt das Element <p>, das einen Textabschnitt als Absatz deklariert,

mehrere Formeln, die unterschiedliche Formate speichern, sowie eine Tabelle, die aus meh-

reren Zeilen und Spalten besteht.

Die Bestimmung der syntaktischen Struktur ist zwar die Grundvoraussetzung f¨

ur den

Aufbau von Bausteinen, reicht aber bei weitem nicht aus. Neben der syntaktischen Struk-

tur ist der semantische Aufbau ebenso wichtig, weil nur sinnvoll aufgebaute Inhalte eindeu-

tig erkannt und richtig ¨

ubersetzt werden. Hierzu existiert ein XSD-Schema (vgl. Abschnitt

3.2.1), das die eindeutige Vater-Kind-Beziehung zwischen den Elementen definiert. Dar-

uber hinaus werden die erlaubten Attribute spezifiziert, indem ihnen Basistypen, wie z.

B. Integer,String oder Boolean, zugewiesen werden. Elemente lassen sich in einem XSD-

Schema von anderen Element-Definitionen ableiten, indem, ¨

ahnlich wie bei der Objektori-

entierung, die Definition des abzuleitenden Elements in der neuen Definition automatisch

g¨

ultig ist. Ableitbare Elemente werden in der XSD-Definition mit dem Element complexe-

Type versehen. Als Beispiel f¨

ur eine XML-Schema Element-Definition wird das in Listing

6.1 verwendete table-Element vorgestellt. Listing 6.2 zeigt das Konstrukt zur semantisch-

en Definition einer Tabellenstruktur. Demnach besteht eine Tabelle aus einer Sequenz

column-Elementen1, gefolgt von mindestens einer Zeile. Zus¨

atzlich k¨

onnen die optionalen

Attribute border,width,heigt,caption und unit hinzuf¨

ugt werden.

1Die Spalten-Elemente speichern wichtige Merkmale der Tabellen, enthalten jedoch selbst keinen Inhalt.

Der Zelleninhalt wird in cell-Elementen innerhalb des row-Elements gespeichert wird.

122 KAPITEL 6. UMSETZUNG

Listing 6.2: BrickML Tabellen-Definition mit XML-Schema

1<xsd:element name=”table” minOccurs=”0” maxOccurs=”1”

type=”tableType”/>

4<xsd:complexType name=”tableType”>

<xsd:sequence>

<xsd:element name=”column” type=”columnType”

7minOccurs=”0” maxOccurs=”unbounded”/>

<xsd:element name=”row” type=”rowType” minOccurs=”0”

maxOccurs=”unbounded”/>

10</xsd:sequence>

<xsd:attribute name=”border” type=”xsd:boolean” use=”optional”/>

<xsd:attribute name=”width” type=”xsd:integer” use=”optional”/>

13<xsd:attribute name=”height” type=”xsd:integer” use=”optional”/>

<xsd:attribute name=”caption” type=”xsd:string” use=”optional”/>

<xsd:attribute name=”unit” type=”xsd:string” use=”optional”/>

16</xsd:complexType>

OO-Binding

Das bisher beschriebene XML-Binding beg¨

unstigt die einfache Lesbarkeit des Inhalts und

stellt außerdem die kontextfreie Verarbeitung sicher. Damit dieses Modell von einem Pro-

zess verarbeitet werden kann, wird ein Speichermodell ben¨

otigt, das den aus Sicht des Pro-

grammierers praktikablen Umgang gew¨

ahrleistet. Gerade f¨

ur eine derart komplexe Daten-

struktur bieten sich die Mittel der Objektorientierten Programmierung (OOP) an. Jedes

Element wird als selbst¨

andige Klasse definiert und kapselt die relevanten Eigenschaften

eines Modellknotens. F¨

ur jedes Element wird eine korrespondierende Klasse angelegt, de-

ren Membervariablen den Element-Attributen entsprechen und ihre Unterelemente, durch

offentliche Methoden der Klasse, zug¨

anglich sind. Auf diese Weise wird gew¨

ahrleistet, dass

der Zustand der Objektstruktur konsistent ist. Diese Datenstruktur wird nicht nur zum

Navigieren des Modells verwendet, sondern bietet ebenso die M¨

oglichkeit zur Konstruktion

einer Objektstruktur, die zur Erstellung eines kompletten Content-Modells f¨

ur Bausteine

f¨

uhrt. Dieses ist insbesondere bei der automatischen Erzeugung von Bausteinen wichtig

und wird von Lade-Routinen (vgl. Abschnitt 5.4.2) ben¨

otigt. Ein anderes Beispiel ist die

Abbildung einer XML-Datei auf Objektstrukturen. Dokumente werden auf diese Weise in

den Speicher geladen und lassen sich dort dynamisch modifizieren. Dieses Verfahren wird

z. B. vom ¨

Ubersetzungsprozess verwendet, um Elemente zu suchen und deren Zustand ggf.

anzupassen.

F¨

ur die Implementierung des OO-Bindings wurde das Rahmenwerk Java Document

Object Model (JDOM)[JDO05] eingesetzt. G¨

angige XML-Parser, wie z. B. Xerces [Xer05],

konstruieren zwar eine Objektstruktur (Document Object Model DOM), jedoch auf Basis

einer einzigen Element-Klasse. JDOM hingegen implementiert das in Gamma vorgestellte

[Gamma95] Fabrikmuster, mit dem zu jedem eingelesenen XML-Element, anhand seines

6.1. DAS AUTORENWERKZEUG LYSSA 123

ParagraphElement

TextElement FormulaElement

inline

mode

FormulaElement

inline

mode

RowElement

align

RowElement

align

ColElement

align

valign

width

height

colspan

rowspan

unit

ColElement

align

valign

width

height

colspan

rowspan

unit

ColElement

align

valign

width

height

colspan

rowspan

unit

ColElement

align

valign

width

height

colspan

rowspan

unit

TextElement FormulaElement

inline

mode

TextElement

FormulaElement

inline

mode

title

LobElement

TableElement

FormulaElement

inline

mode

border

width

height

caption

unit

Abbildung 6.4: UML-Diagramm f¨

ur ein OO-Binding-Beispiel

Namens, ein Objekt einer spezialisierten Klasse instantiiert wird. Ohne diesen Mechanis-

mus m¨

usste ¨

uber komplizierte und fehleranf¨

allige String-Kommandos der Objekt-Zustand

erfragt werden.

Das im vorigen Abschnitt pr¨

asentierte XML-Listing wird als OO-Binding in Abbil-

dung 6.4 gezeigt. Das Wurzelelement <lob/> wird auf die Klasse LobElement abgebildet.

Des weiteren entspricht das ParagraphElement dem <p/> Element, das ¨

uber eine ent-

sprechende Methode dem LobElement zugeordnet wird. Eine weitere Methode weist dem

LobElement den Titel zu, der als Attribut im XML-Element enthalten ist. Dieser Vorgang

setzt sich fort, bis das gesamte Dokument im Speicher aufgebaut worden ist.

124 KAPITEL 6. UMSETZUNG

6.1.3 Formatierbare Kurse

Als Grundlage f¨

ur Formatierbare Kurse dient das IMS Content Package 2.3.2, das, durch

das in seiner Spezifikation festgelegte XML-Binding, den Aufbau von Kursstrukturen defi-

niert. Von einer Realisierung durch ein Datenbankschema wurde an dieser Stelle abgesehen,

weil Kurse – ¨

ahnlich wie PDF-Dokumente – unabh¨

angig von Datenbanken behandelt wer-

den sollen, damit sie w¨

ahrend des Entwicklungsprozesses von Autoren bzw. Autorinnen

per E-Mail bzw. ¨

uber einen gemeinsamen Dateiserver ausgetauscht werden k¨

onnen. Die

IMS-Kursstruktur besteht im Wesentlichen – wie bereits geschildert – aus einer verschach-

telten Item-Struktur, die mit exakt einer Ressource verkn¨

upft werden k¨

onnen. Ist eine

solche Referenz vorhanden, so enth¨

alt das Resource-Element den Inhalt des Kurskno-

ten. In Abschnitt 5.3 wurde bereits er¨

ortert, dass Item-Elemente Formatierbare Bausteine

oder auch Formatierbare Kurse referenzieren, die selbst Manifeste und Kursstrukturen

enthalten k¨

onnen. Damit sich diese von einem technischen System erkennen und verarbei-

ten lassen, wird ein Mechanismus zur Identifikation ben¨

otigt. Das IMS hat f¨

ur den Fall,

dass type-Attribut f¨

ur Resource-Elemente reserviert, welches im Standardfall auf den

Wert webcontent gesetzt wird, um anzuzeigen, dass es sich um eine Ressource einer Web-

Pr¨

asentation handelt. Im Folgenden werden die f¨

ur Formatierbare Bausteine relevanten

Typen vorgestellt:

•webcontent: Das Attribut webcontent kennzeichnet normale Assets, wie z. B.

HTML, JPEG oder JAR Dateien.

•brickml: Bei dieser Ressource handelt es sich um die XML-Datei, die als Grundlage

der Bausteine dient.

•fb: Anhand des fb-Attributs erkennt der ¨

Ubersetzer, dass es sich um einen forma-

tierbaren Baustein handelt.

•fk: Anhand des fk-Attributs erkennt der ¨

Ubersetzer, dass es sich um einen forma-

tierbaren Kurs handelt.

Listing 6.3 zeigt das einfache Manifest eines Grundlagenkurses der Technischen In-

formatik. Das Manifest besteht aus Organisationen mit verschachtelten Item-Elementen

und zus¨

atzlichen Ressourcen. Der Kursknoten Schaltnetze referenziert die Ressource mit

dem Identifier Resource, die durch das href-Attribut auf einen Unterkurs verweist. Die

anderen Kursknoten, wie der Eintrag Wechselstromschaltungen, sind hingegen einfache

Bausteine. Sie enthalten nur den f¨

ur den jeweiligen Kursknoten relevanten Lerninhalt.

Listing 6.3: Beispiel eins Manifests f¨

ur einen Grundlagenkurs Technische Informatik.

<?xml version=”1.0” encoding=”UTF−8”?>

2<manifest xmlns=”http://www.imsproject.org/xsd/imscp rootv1p1p2”

xmlns:adlcp=”http://www.adlnet.org/xsd/adl cp rootv1p1”

identifier =”Manifest3”>

6.1. DAS AUTORENWERKZEUG LYSSA 125

5<organizations>

<title>Technische Informatik</title>

8<item identifier=”Item3” identifierref =”Resource1>

<title>Schaltnetze</title>

</item>

11<item identifier=”Item8” identifierref =”Resource2”>

<title>Wechselstromschaltungen</title>

14<title>Sinusf¨

ormige Wechselgr¨

oßen</title>

</item>

17<title>Mittelwerte sinusf¨

ormiger Zeitfunktionen</title>

</item>

20<title>Arithmetische Operationen zweier sinusf¨

ormiger

Wechselgr¨

oßen gleicher Frequenz</title>

</item>

23</item>

</organization>

</organizations>

26<resources>

<resource type=”fk” identifier =”Resource1 href=”/actos.cob”

adlcp:scormtype=”sco”><file href=”/actos.cob”/>

29</resource>

<resource type=”fb” identifier =”Resource2” href=”/wechselstrom.lob”

adlcp:scormtype=”sco”> <file href=”/wechselstrom.lob” />

32</resource>

<resource type=”fb” identifier =”Resource3” href=”/wechsel sin.lob”

adlcp:scormtype=”sco”><file href=”/wechsel sin.lob” />

35</resource>

<resource type=”fb” identifier =”Resource4” href=”/wechsel ao.lob”

adlcp:scormtype=”sco”> <file href=”/wechsel ao.lob” />

38</resource>

</resources>

</manifest>

Verarbeitung

Diese Struktur ist jedoch noch nicht f¨

ur Lehrzwecke nutzbar, da die Bausteine und Kurse

erst zu einem einzigen Kurs zusammengesetzt werden m¨

ussen. Hierf¨

ur wird der in Listing

5.1 eingef¨

uhrte Algorithmus implementiert. Zuerst muss der Kurs ge¨

offnet und das enthal-

tene Manifest mit dem in [Bungenstock04] vorgestellten OO-Binding eingelesen werden.

Es unterst¨

utzt die dynamische Verarbeitung und die Aggregation von Kursen.

Entsprechend der Algorithmus-Definition wird der ge¨

offnete Kurs nach Bausteinen

126 KAPITEL 6. UMSETZUNG

und Subkursen durchsucht. Das Zusammenf¨

uhren zweier Kurse ist erst m¨

oglich, wenn der

Subkurs entfernt wird und stattdessen sein Subkurses eingesetzt wird. Zu diesem Zweck

werden Submanifeste verwendet, die in einem zus¨

atzlichen Manifest definiert werden. Sub-

manifeste werden ¨

uber Referenzen von den Kursknoten eingebunden und lassen sich daher

an verschiedenen Stellen der Kursstruktur verankern. Dieses Verfahren l¨

asst sich rekur-

siv fortfahren, bis der komplette Kursbaum aufgebaut ist. Trifft der ¨

Ubersetzer auf einen

Baustein, werden die dort enthaltenen Assets in den zu erzeugenden Kurs kopieren und

als Ressourcen eingetragen.

Die Transformation besteht aus drei Schnitten: Zuerst wird der aggregierte Kurs zu

einem einzigen Kurs zusammengebaut, der lediglich ein Manifest enth¨

alt. In einem zweiten

Schritt wird daraufhin der Inhalt der BrickML-Dateien transformiert. Der letzte Schritt

dient zur Erzeugung des Ausgabeformats, dessen Zeit- und Kostenaufwand abh¨

angig von

seiner Komplexit¨

at variiert.

F¨

ur die Realisierung der drei Verarbeitungsschritte wird das Abstrakte Fabrik-Modell

verwendet [Gamma95]. Anhand einer konkreten Fabrik erm¨

oglicht das Muster einem

Klienten-Objekt die Konstruktion einer speziellen Datenstruktur. Um andere Konstruktio-

nen zu erzeugen, muss lediglich die Instanz der Fabrik ausgetauscht werden. Obwohl jede

Fabrik ihre individuell ausgepr¨

agten Klassen besitzt, sind deren Schnittstellen dennoch

einheitlich, um weitere Kursvarianten zu erzeugen.

F¨

ur den ¨

Ubersetzungsprozess werden die zwei Fabriken CPCSFactory und NaviCSFac-

tory ben¨

otigt. Erstere erzeugt einen Kurs auf Basis einer verschachtelten Bausteinstruk-

tur und die zweite transformiert die Kursstruktur in eine einfache Datenstruktur, aus

der die Navigation generiert wird. Diese wird insoweit ben¨

otigt, um komplexe Manifeste,

bestehend aus vielen verschachtelten Submanifesten, zu einer darstellbaren Struktur zu-

sammenzubinden. Die abstrakte Klasse CSFactory erzeugt entsprechend der IMS-Content

Package Spezification (vgl Kapitel 2.3.2) Objekte der Klasse Course,Item und Resource.

Da diese Klassen abstrakt sind, kann keine von ihnen zur Laufzeit instantiiert werden.

Nur Objekte abgeleiteter Klassen k¨

onnen bei der Content Package-Erzeugung instanziiert

werden, wie z. B. CPCourse,CPItem und CPResource.

Die Klasse CPConverter kann durch die polymorphe Eigenschaft der Verwebung bei-

spielsweise ein Course-Objekt anfordern, erh¨

alt jedoch, ohne dessen konkrete Implemen-

tierung zu kennen, die abgeleitete Klasse CPCourse. Des weiteren lassen sich mit diesem

Muster andere Repr¨

asentationen, wie z. B. verwandte Standards oder eine vereinfache

Textansicht, generieren.

Die Fabrik wird durch die Klasse CPConverter verwendet. Sie implementiert den in

Listing 5.1 vorgestellten Algorithmus und nutzt w¨

ahrend der Abarbeitung die Fabrik, um

einen neuen ¨

ubersetzten Kurs zu konstruieren. Jeder neu entdeckte Baustein zwingt die

Klasse CPConverter, ihn zu ¨

offnen und das dort enthaltene Manifest rekursiv weiter zu

verarbeiten.

6.1. DAS AUTORENWERKZEUG LYSSA 127

CPConverter

NaviCourseCPCourse

CPItem NaviItem

CPResource NaviResource

Resource

Item

Course

setHref

setId

addItem

setTitle

setIdRef

setType

addCourse

addItem

addResource

CPCSFactory

createResource

createItem

createCourse

NaviCSFactory

CSFactory

Abbildung 6.5: UML-Diagramm einer abstrakten Fabrik f¨

ur die Kursumwandlung

6.1.4 Das Kursmodell

In Kapitel 5.3.2 wurde das allgemeine Kursmodell vorgestellt, mit dem die Erzeugung

modularer Kursstrukturen erheblich vereinfacht wird. Dieses ist besonders wichtig, wenn

bestehende Inhalte, wie z. B. Office-Dokumente, f¨

ur die Entwicklung neuer Kurse wieder-

verwendet werden m¨

ussen und sie auf eine modulare formatierbare Kursstruktur abgebil-

det werden sollen. Das Kursmodell bietet Entwicklern und Entwicklerinnen eine abstrak-

te Schnittstelle, anhand derer sich komplett verschachtelte Kurse mit einfachen Mitteln

128 KAPITEL 6. UMSETZUNG

erzeugen lassen. Der Mehrwert folgt aus der Reduktion der Komplexit¨

at, w¨

ahrend der

Entwicklung von Laderoutinen f¨

ur Fremdformate.

OO-Bindung Kursmodell

Nachdem das Kursmodell theoretisch betrachtet wurde, wird in diesem Abschnitt die kon-

krete Umsetzung im Autorenwerkzeug Lyssa vorgestellt. Bedingt durch das realisierte

OO-Binding existiert zu jedem, in Abbildung 5.15 gezeigten Kursknoten genau eine Ob-

jektinstanz.

Ausgehend vom Kursobjekt, k¨

onnen Lektionen bzw. Kapitel dynamisch in die Baum-

struktur eingeordnet werden. Hierbei spielt es keine Rolle, ob eine Lektion zuerst kon-

struiert wird und im Anschluss in die Kursstruktur eingeh¨

angt wird oder ob sie zuerst

in die Kursstruktur eingebunden und dann weiter ausgebaut wird. Diese, auf den ersten

Blick triviale, Forderung f¨

uhrt jedoch bei genauerer Betrachtung zu einigen Hindernissen.

Das Kursmodell sieht vor, dass jede Lektion, festgelegt durch das Attribut CourseObject,

entweder als Baustein realisiert wird oder dem Kursknoten eines ¨

ubergeordneten Kurses

zugeordnet wird. Wird ein Kursobjekt mit diesem Attribut versehen, folgt die Erstellung

eines selbst¨

andigen, im Dateisystem gespeicherten IMS Content Package. Wird der Kurs-

knoten nach seiner Erzeugung in die Kursstruktur eingepflegt, werden alle weiteren Assets

und Subkurse in das Content Package kopiert. Die Lektion l¨

asst sich zwar autark aufbauen,

ihr Inhalt muss jedoch zu einem sp¨

ateren Zeitpunkt in den ¨

ubergeordneten Kurs kopiert

werden. Problematisch ist eine nicht als Kursobjekt gekennzeichnete Lektion. In diesem

Fall muss die Objektinstanz solange im Speicher gehalten werden, bis die Zuordnung zu ei-

ner ¨

uberordneten, als Kursobjekt deklarierten Lektion stattfindet. Inhalte werden, genau

wie Lektionen, dynamisch konstruiert und die Objektinstanzen miteinander verkn¨

upft.

Hierbei ist die Verwendung von Content Packages ebenso bedeutsam, wie bei der Aggre-

gation von Lektionen. Einige Objektinstanzen, unter anderen Videos und Abbildungen,

die im Dateisystem abgelegt werden, m¨

ussen ebenfalls Ressourcen verwalten. Werden die-

se Objekte, denen Dateien zugeordnet sind, vor der Zuordnung zu einer Lektion erzeugt,

fehlt das zugeh¨

orige Content Package, d. h. die Dateien k¨

onnen nicht als Assets in das

Package kopiert und in das Manifest eingetragen werden.

Durch diesen Ansatz werden zwei m¨

ogliche Erzeugungsvarianten f¨

ur die Abbildung

auf das Kursmodell angeboten. Einerseits kann das zu importierende Format eingelesen

werden und das entsprechende Kursmodell top-down aufgebaut werden. Wird mit dem

Kursknoten begonnen, so ist immer ein zugrunde liegendes Content Package vorhanden,

in das weitere Content Packages und Assets kopiert werden k¨

onnen. Auf der anderen Seite

kann das Kursmodell nach dem bottom-up-Verfahren, beginnend mit seinen Bl¨

attern, kon-

struiert werden. Letztere Variante ist dann notwendig, wenn das einzulesende Quellformat

zuerst rekursiv traversiert werden muss, um es komplett einlesen zu k¨

onnen. Zus¨

atzlich

erm¨

oglicht dieser Ansatz eine Granularit¨

atsabsch¨

atzung, die zur Erkennung redundanter

Kursfragmente, also solche, die keinen Inhalt besitzen, eingesetzt werden kann. Diese Frag-

mente werden nicht als Baustein modelliert, sondern lediglich als Kursknoten verankert.

Abbildung 6.6 zeigt die sequenzielle Darstellung einer bottom-up Kurskonstruktion und

6.1. DAS AUTORENWERKZEUG LYSSA 129

image.png

Image

Item

Image

Item

OrderedList

Paragraph

Course

Paragraph

Section

Course Object=true

Course Object=false

Course Object=true

Abbildung 6.6: Sequenzielle Darstellung eines Objekt Diagramms zur Veranschaulichung

einer bottom-up Kurskonstruktion

den Umgang mit Datei-Ressourcen. Im ersten Schritt wird ein Image-Objekt erzeugt, das

einem Item-Objekt zugeordnet wird. An dieser Stelle ¨

uberpr¨

uft das Image-Objekt, ob be-

reits ein ¨

ubergeordnetes Content Package existiert. Ist dies nicht der Fall, so ¨

ubergibt es

die Datei-Information an sein Item-Objekt. Im zweiten Schritt wird der Kurs weiter aufge-

baut und die Datei-Information der Abbildung, wie im ersten Schritt, bis zum Paragraphen

weitergereicht. Der dritte Schritt verdeutlicht die ¨

Ubergabe des Paragraphen an eine Lek-

tion. Der Paragraph ¨

ubergibt die Datei-Ressource nur dann, wenn eine Lektion mit dem

Attribut CourseObject=true in der Liste seiner Vorfahren vorhanden ist. Trifft dies zu,

wird die Datei in das Content Package der Lektion kopiert. In Schritt 4 wird die Lektion

mit dem erzeugten Content Package einem Kursobjekt zugeordnet und als neues Asset in

dessen Content Packages kopiert. Abschließend erfolgt der Eintrag in das Manifest.

Das zugeh¨

orige UML-Klassendiagramm ist in Abbildung 6.10 zu sehen. Die Klasse

CPContainer fungiert als Verwalter f¨

ur IMS Content Packages. Sie ¨

ubernimmt die Erzeu-

gung und Verwaltung der physikalisch vorhandenen Dateien und erm¨

oglicht neben dem

Abspeichern auch das Aggregieren von Lektionen. Der Wurzelknoten des Kursmodells ist

der Kurs selbst, der durch die Klasse Course instantiiert wird. Der Kurs ist abgeleitet von

der Klasse CPContainer und entspricht einem spezialisierten Content Package. Lektionen

sind ebenfalls spezialisierte Content Packages, die sich zu Kompositionen zusammenf¨

uh-

ren lassen. Der bis an dieser Stelle eingef¨

uhrte Aufbau der Kursstruktur entspricht im

130 KAPITEL 6. UMSETZUNG

Paragraph

Table Image OrderedListApplet

RessourceHandler

Course Lesson

CPContainer

Abbildung 6.7: UML-Klassendiagramm des Kursmodells

Wesentlichen dem eines formatierbaren Kurses. Damit das Kursmodell jedoch vollst¨

an-

dig umgesetzt werden kann, m¨

ussen Content-Objekte mit den Objekt-Exemplaren direkt

verbunden werden, um die angestrebte Transparenz des Modells zu erhalten. Aus diesem

Grund lassen sich z. B. Paragraph-Objekte direkt in Lektionen einh¨

angen und die Daten-

struktur, entsprechend der in Kapitel 5.2 eingef¨

uhrten Baustein-Struktur, als vollst¨

andiger

Objektbaum konstruieren. Des weiteren ist die Lesson-Klasse f¨

ur die Anbindung des in

Abschnitt 6.2 vorgestellten OO-Bindings an die Kursstruktur verantwortlich.

Es wurde bereits darauf hingewiesen, dass das Kursmodell mit externen Ressourcen

hantieren muss und sie insbesondere f¨

ur die bottom-up Konstruktion ber¨

ucksichtigen muss.

Der L¨

osungsansatz f¨

ur dieses Problem sieht die Klasse ResourceHandler vor, von der

jede Klasse des Bausteinmodells abgeleitet wird. Die Klasse ResourceHandler kapselt die

Verwaltung der Ressourcen und ¨

ubergibt sie, w¨

ahrend der Verkn¨

upfung zweier Objekte,

an die ¨

Ubergeordnete weiter. Dieser Vorgang wird vor dem Klienten bzw. der Klientin des

Kursmodells verborgen, so dass der bottom-up Ansatz, wie er in Abbildung 6.6 illustriert

wird, trivial anwendbar ist.

6.1.5 Abbildung bestehender Formate

Das Kursmodell dient in erster Linie zur vereinfachten Abbildung bestehender Lernmate-

rialien. Diese Vereinfachung zeichnet sich insbesondere durch die strikte Trennung zwischen

6.1. DAS AUTORENWERKZEUG LYSSA 131

dem konkreten Kursaufbau, mit in sich verschachtelten Bausteinen sowie der Analyse des

Quellformats aus. Letzterer soll in diesem Abschnitt weiter untersucht werden. Um die Lei-

stungsf¨

ahigkeit des Modells zu demonstrieren, werden die Formate OpenOffice,DocBook

und Latex analysiert und die im Prototypen realisierten Abbildungsroutinen vorgestellt.

OpenOffice

OpenOffice hat sich als Open-Source-Variante von dem Office Produkt StarOffice ab-

gespalten und wurde seither st¨

andig weiterentwickelt. Eine wichtige Eigenschaft dieser

Office-Suite ist die Kompatibilit¨

at zu mehreren Betriebssystemen, da, neben der Windows-

Version, ebenfalls Varianten f¨

ur verschiedenen Linux-Derivate existieren. OpenOffice wur-

de in dieser Arbeit als zu analysierendes Office-Produkt untersucht, weil das zugrunde lie-

gende Dateiformat ¨

offentlich zug¨

anglich ist und es zudem die Auszeichnungssprache XML

einsetzt [OOS02]. Außerdem kann es, aufgrund seines großen Fundus an Import-Filtern,

als Mediator f¨

ur andere Formate eingesetzt werden (vgl. Abschnitt 3.1.2).

Damit das Dokument jedoch auf das Kursmodell abgebildet werden kann, muss zu-

n¨

achst seine interne Struktur interpretiert werden. Das OpenOffice.org-XML-File-Format

besteht aus den vier Dateien meta.xml,styles.xml,content.xml und settings.xml,

die zusammen das gesamte Dokument enthalten.

meta.xml enth¨

alt Metadaten ¨

uber das Office Dokument. Hierzu z¨

ahlen z. B. der Name

des Autors und das Erstellungsdatum.

content.xml speichert den Inhalt des Dokuments. Jedes Element besitzt eine Referenz

auf einen Style, der die Darstellung beschreibt. Zus¨

atzlich enth¨

alt die Datei noch

automatic styles. Hierbei handelt es sich um Layouteigenschaften, die w¨

ahrend der

Bearbeitung eines Dokuments Elementen zugeordnet werden.

styles.xml enth¨

alt Style-Definitionen f¨

ur Elemente. Hierzu z¨

ahlen z. B. Farben, Schrift-

typen und Abst¨

ande.

settings.xml speichert applikationsspezifische Einstellungen, wie z. B. Druckerinforma-

tionen oder Fenstergr¨

oßen.

Ein wesentliches Problem bei der Verarbeitung von OpenOffice-Dokumenten ist die

fehlende Dokumentstruktur. Kapitel und Unterkapitel werden ausschließlich linear abge-

speichert und nicht, wie in diesem Ansatz gefordert, hierarchisch. Dieses ergibt sich aus der

Zweckm¨

aßigkeit des Anwendungsmodells. Mit OpenOffice werden Kapitel und Abschnitte

quasi grafisch ¨

uber die Schnittstelle zum Anwender bzw. zur Anwenderin festgelegt. Ein

Abschnitt kann mit einem Mausklick in ein Kapitel umdeklariert werden. OpenOffice kennt

also kein strukturiertes Dokument, das aus Kapiteln und Abschnitten besteht, sondern es

speichert die Pr¨

asentation des Dokuments linear ab. Folglich ist eine Kapitel¨

uberschrift

eine Textzeile mit einem Hinweis, dass es sich um eine ¨

Uberschrift mit einer zugeh¨

origen

Verschachtelungstiefe handelt. Die Konsequenz, die sich hieraus ergibt, ist, dass Elemente,

wie Aufz¨

ahlungen oder Tabellen, keinem Kapitel oder Abschnitt zugeordnet werden. Dies

132 KAPITEL 6. UMSETZUNG

Abbildung 6.8: OpenOffice Screenshot

wirkt sich auf die Komplexit¨

at der Dokumentanalyse aus, denn zu jeder in der Analyse-

phase neu gefundenen ¨

Uberschrift muss das dazugeh¨

orige Kapitel ermittelt werden, um

die Zuordnung f¨

ur das Kursmodell herzustellen.

Abbildung 6.8 zeigt einen Bildschirmausschnitt der OpenOffice-Applikation. Damit

eine Zeile als ¨

Uberschrift erkannt werden kann und entsprechend auf einen Baustein ab-

gebildet wird, muss ein Absatztyp ausgew¨

ahlt werden. In der Abbildung sind einige Stan-

dardtypen aufgelistet, von denen der Typ Heading 1 ausgew¨

ahlt worden ist. Im ¨

Ubrigen

bezeichnet die anstehende Nummer auch gleich die Verschachtelungstiefe des Kapitels. Der

Office-Loader erzeugt aus jeder ¨

Uberschrift einen Baustein und f¨

ugt ihn der Kursstruktur

hinzu. Die Zuordnung zwischen den Office-Elemente und denen die Lyssa anbietet, zeigt

Tabelle 6.3.

DocBook

DocBook ist ein weit verbreiteter Standard zum Austausch digitaler Dokumente. Die Ak-

zeptanz von DocBook w¨

achst stetig und immer mehr Office-Produkte-Anbieter, wie Sta-

rOffice oder KOffice, stellen Export-Filter f¨

ur dieses Format bereit. DocBook eignet sich

6.1. DAS AUTORENWERKZEUG LYSSA 133

OpenOffice Element Kursmodell Element

Image Image

LineBreak Break

ListItem ListItem

OrderedList OrderedList

Paragraph Paragraph

Properties

Span

Style Underline, Italic, Emphasis, Typewriter

Styles

TabStop

TableCell Cell

TableColumn Column

TableColumns -

TableColumnsHeader -

Table Table

TableHeaderRow -

TableRow Row

TableRowGroup

Heading Section

UnorderedList UnorderedList

Tabelle 6.3: Abbildung zwischen OpenOffice-Elementen und denen des Kursmodells

zum Schreiben ganzer Skripte und B¨

ucher. Im Rahmen der Diplomarbeit Entwicklung

einer Software-Komponente zur Integration bestehender Lehr- und Lernmaterialien und

deren Metadaten in das mαth-kit System [S¨

unneli04] wurde die Nutzbarkeit von DocBook

untersucht, und analysiert inwiefern der Dokument-Inhalt auf das in dieser Arbeit vorge-

stellte Kursmodell abgebildet werden kann. Die Analyse ergab zun¨

achst, dass DocBook

mehr als 400 Elemente f¨

ur den Dokumentaufbau vorsieht. Die Verarbeitung des gesam-

ten Wortschatzes von DocBook ist jedoch sehr aufwendig, so dass der reduzierte Wort-

schatz Simplified DocBook [Sim05] ausgew¨

ahlt wurden. DocBook bietet, aufgrund seiner

flexiblen und orthogonalen Struktur, zahlreiche Kombinationsm¨

oglichkeiten f¨

ur seine Ele-

mente an, wodurch die Entwicklung eines Parsers erheblich erschwert wird. Weiterhin

ergab die Analyse, dass Elemente oft in mehreren Varianten vorkommen. So gibt es zu

vielen Elementen ein Element mit dem Pr¨

afix Informal, welches lediglich das Vorhan-

densein eines Titels kennzeichnet. Solche Eigenschaften werden im Kursmodell zumeist

uber Attribute angeboten, wodurch die Abbildung mehrerer DocBook-Elemente auf ein

Element des Kursmodells notwendig ist. Tabelle 6.4 zeigt in Ausschnitten die Abbildung

wichtiger DocBook-Elemente auf jene des Kursmodells.

134 KAPITEL 6. UMSETZUNG

OpenOffice Element Lyssa Element Erkl¨

arung

Article, Book, Set Document Dokumenttypen

Appendix, Article,

Chapter, Dedication,

Index, Part, Preface,

Reference, Sect1 - Sect5,

Section, SimpleSect,

SetIndex

Lesson Strukturierungselemente werden

auf Bausteine abgebildet

FormalPara, Para, SimPa-

Paragraph Abbildung mehrerer Paragra-

phen (DocBook kennt Paragra-

phen mit Titeln und einfache

Paragraphen ohne weitere Block-

elemente)

InformalTable, Table Table Abbildung einer Tabelle mit und

ohne Titel

Figure, Graphic, ImageOb-

ject in MediaObject, Infor-

malFigure

Image Bilder und Grafiken

CalloutList, GlossList, Ite-

mizedList, SegmentedList,

SimpleList, VariableList

UnorderedList Listen

OrderedList OrderedList Aufz¨

ahlungen

Equation, InformalEquati-

Equation Mathematische Gleichungen

Example, InformalExam-

ple

Example Beispiel

ProgramListing Code Zur Quellcode-Beschreibung

Emphasis Emphasis Hervorhebungen

Tabelle 6.4: Abbildung zwischen OpenOffice-Elementen und dem Kursmodell

Latex

In der Universit¨

atslehre sowie in Wissenschaftsbetrieben wird Latex f¨

ur die Gestaltung

von Skripten, ¨

Ubungsaufgaben und Ver¨

offentlichungen eingesetzt. Ein großer Vorteil, den

Latex gegen¨

uber anderen Dokumenterstellungswerkzeugen aufweist, ist die gute Unter-

st¨

utzung mathematischer Formeln. Im Rahmen des Forschungsprojekts mαth-kit ist es

von großem Interesse, bestehende Skripte mit Lyssa einzulesen und bisher verfasste Texte,

Grafiken und ¨

Ubungen, f¨

ur die Anreicherung mit multimedialen Komponenten, wieder zu

verwenden.

Die Implementierung eines Parsers zum Einlesen des Source-Codes und insbesondere

zur Verarbeitung von Makros ist jedoch eine zeitaufw¨

andige und fehleranf¨

allige Aufgabe.

Aus diesem Grund wird der Einsatz eines Konverters, der das Latex-Format in DocBook

6.1. DAS AUTORENWERKZEUG LYSSA 135

umwandelt, als L¨

osungsansatz pr¨

aferiert. Mit dem Latex-Paket tex4ht [Goosen99] k¨

on-

nen aus einem Latex Dokument neben HTML-Seiten auch DocBook-Dateien erstellt wer-

den. Die Verwendung des tex4ht-Konverters und der DocBook-Laderoutine erm¨

oglichen

es nunmehr, bestehende Latex-Dokumente f¨

ur die Weiterverarbeitung umzuwandeln. In

Abbildung 6.9 ist der tex4ht-Konverter zu sehen, der zun¨

achst den Latex-Text bearbeitet.

Hierbei werden bereits wichtige Entscheidungen getroffen, wie z. B. die wahlweise Umko-

dierung der mit Latex gesetzten Formeln in MathML [Gurari00] oder Bitmap-Grafiken.

Das Ergebnis ist eine DocBook-Datei mit den aus Formeln generierten Grafiken sowie die

zu den Latex-Quellen geh¨

orenden Abbildungen. Nun kann der DocBook-Loader die soeben

erzeugten Dateien ¨

offnen und, mit Hilfe der entwickelten DocBook- und Metadaten-API

[S¨

unneli04], die Abbildung auf das Kursmodell vornehmen. Das Ergebnis ist eine Kursda-

tei, die den Inhalt der Latex-Datei als Bausteine enth¨

alt.

Course

Object

(COB)

Loader

DocBook

DocBook−API

Metadaten−API

...

Datenfluss

Benutzt

Latex DocBook

Konverter

Tex4ht

KursmodelI

Abbildung 6.9: Datenfluss eines Latex-Dokuments bei der Konvertierung in einen Forma-

tierbaren Kurs.

6.1.6 Transformation

Nachdem zun¨

achst die technische Realisierung der formatierbaren Bausteine und Kurse

im Autorensystem Lyssa beschrieben wurde sowie die Abbildung bestehender Inhalte auf

die Kursstruktur, soll nachfolgend die Umsetzung der Transformationspakete ausf¨

uhrlich

erl¨

autert werden.

Transformationspakete

Das Transformationspaket ist ein komprimiertes ZIP-Archiv, indem die Datei mani-

fest.xml den konkreten Aufbau des Pakets definiert. W¨

ahrend der Startprozedur des

Autorensystems werden die vorhandenen Transformationspakete eingelesen und durch

einen Pool verwaltet. Wird ein Kurs ¨

ubersetzt, so k¨

onnen die vorhandenen Pakete zur

Auswahl angeboten werden und, je nachdem welches Format erzeugt werden soll, das pr¨

ferierte ausgew¨

ahlt werden. Das bedeutet, dass alle notwendigen Informationen f¨

ur die

Erstellung des Ziel-Formats im Transformationspaket gekapselt sein m¨

ussen. Abbildung

136 KAPITEL 6. UMSETZUNG

6.10 zeigt das UML-Diagramm eines Transformationspaketes. Dieses besitzt mindestens

zwei Transformatoren, einen zur ¨

Ubersetzung der Bausteine und einen f¨

ur die ¨

Uberset-

zung der Kursstruktur. F¨

ur diese beiden Varianten gibt es die vom Transformer abge-

leiteten Klassen NavigationTransformer und ContentTransformer. Zus¨

atzlich existiert

eine allgemeine Transformer-Klasse, die weitere Aufgaben, wie z. B. die Erzeugung eines

HTML-Framesets, ¨

ubernehmen kann. Hierbei handelt es sich lediglich um die Objektre-

pr¨

asentationen der Transformatoren. Sie verwenden intern einen XMLConverter, der auf

verschiedene Arten implementiert werden kann. So ist es m¨

oglich, die Extended Stylesheet

Language XSL einzusetzen oder ¨

Ubersetzungsmechanismen direkt in Java zu implementie-

ren. Eine entsprechende Umsetzung findet in der Klasse JDOMConverter statt. Außerdem

verwendet jeder XMLConverter ein Layout-Objekt, damit die f¨

ur eine ¨

Ubersetzung rele-

vanten Layouteinstellungen ber¨

ucksichtigt werden.

Allerdings legt das vorgestellte Klassenkonzept nicht fest, welche Konverter von den

Transformatoren eingesetzt werden. Transformationspakete sind daher in der Lage, auf

unterschiedliche Techniken w¨

ahrend der ¨

Ubersetzung zur¨

uckzugreifen.

Transformer

setXMLConverter()

setFile()

setName()

Navigation

Transformer Transformer Transformer

Content Default

TransformationPackage

XSLConverter JDOMConverter

Layout

XMLConverter

convertXML()

setParameter()

Abbildung 6.10: UML-Diagramm der Transformation Package Klasse

XSL-Konverter

F¨

ur die Umwandlung der XML-Inhalte verwendet der XSL-Konverter den XSL-Prozessor

Xalan2. Hierf¨

ur wird ein so genanntes XSL-Stylesheet 3.2.1 ben¨

otigt, indem die ¨

Uber-

setzungsregeln aufgef¨

uhrt werden. F¨

ur jedes in der Quelle auftretende Element sollte eine

korrespondierende ¨

Ubersetzungsregel angeboten werden, die in mehreren Dateien abgelegt

2http://xml.apache.org

6.1. DAS AUTORENWERKZEUG LYSSA 137

und dem XSL-Prozessor zur Verarbeitung ¨

ubergeben werden kann. Aus diesem Grund sind

die Stylesheet-Dateien Bestandteil des Transformationspaketes und werden im Manifest

ber¨

ucksichtigt.

Im Folgenden wird nun ein Beispiel f¨

ur eine einfache ¨

Ubersetzungsregel gegeben und

deren Abarbeitung demonstriert. Listing 6.4 zeigt eine Regel f¨

ur das Element Item. Trifft

der ¨

Ubersetzer bei der Traversierung des Quelldokuments auf ein solches Element, so

werden die zwischen einem XSL-Element auftretenden Inhalte, die nicht zum Namensraum

(vgl. Abschnitt 3.2.1) xsl: geh¨

oren, in die Ausgabe umgelenkt. In diesem Beispiel wird

also ein Listenelement von BrickML in eines f¨

ur Formating Objects (FO) umgewandelt 3.

Listing 6.4: ¨

Ubersetzungsregel eines Listenelements mit XSL beschrieben

<xsl:template match=”item”>

2<fo:list −item space−after.optimum=”6pt”>

<fo:list −item−label>

<fo:block start−indent=”5pt”>

5<xsl:if test=”name(..)=’itemize’”>

•

</xsl:if>

8<xsl:if test=”not(name(..)=’itemize’)”>

<xsl:number level=”multiple” format=”1”/>

</xsl:if>

11</fo:block>

</ fo:list −item−label>

<fo:list −item−body start−indent=”25pt”>

14<fo:block>

<xsl:apply−templates />

</fo:block>

17</ fo:list −item−body>

</ fo:list −item>

</xsl:template>

Im ersten Block wird entschieden, ob es sich bei dem Listenelement um eine Aufz¨

ahlung

oder eine Nummerierung handelt und die entsprechende Darstellung f¨

ur eine Aufz¨

ahlung

oder eine Nummerierung in die Ausgabe generiert. Der zweite Block befasst sich mit der

Verarbeitung des Inhalts, der innerhalb eines Elements definiert ist. Es sind entweder an-

dere Elemente des Quelldokuments oder lediglich einfache Texte. An dieser Stelle wird

der Kontrollfluss des XSL-Prozessors rekursiv an eine weitere ¨

Ubersetzungsregel weiterge-

geben. Nach erfolgreicher Verarbeitung des Inhalts, der unter einem Item-Element steht,

kann die Abarbeitung fortgef¨

uhrt werden.

3Formating Objects Elemente verwenden den Namensraum fo:

138 KAPITEL 6. UMSETZUNG

Java-Konverter

Alternativ lassen sich auch andere ¨

Ubersetzungstechniken f¨

ur die Transformation einset-

zen. So ist es m¨

oglich, selbst einen in Java geschriebenen Konverter auf Basis der JDOM-

Bibliothek [JDO05] zu entwickeln. Der Java Konverter traversiert die Baumstruktur, die

durch das Quelldokument aufgespannt wird und produziert zu jedem gefundenen Ele-

mentknoten eine Ausgabe, die in den Ausgabestrom gelenkt wird. Diese Technik ist dann

notwendig, wenn aus den XML-Quellen kein Textformat generiert werden soll, sondern

eine Bin¨

ardatei, wie z. B. ein Flash-Film.

Java Konverter werden durch mehrere Klassen repr¨

asentiert, die wie XSL-Stylesheets

im Transformationspaket gespeichert und im Manifest eingetragen werden.

6.1.7 Framework

Durch den Einsatz von Rahmenwerken wird ein h¨

oherer Grad an Wiederverwendbarkeit

und Erweiterbarkeit bei der Entwicklung von Softwaresystemen erreicht. Genau dieser

Vorteil soll auch beim Einsatz von Transformatoren und Laderoutinen genutzt werden,

da sie individuelle Erg¨

anzungen und Auspr¨

agungen der Standardsoftware sein k¨

onnen.

Anwender bzw. Anwenderinnen sollen das Autorensystem Lyssa durch ihre eigenen Soft-

warekomponenten erweitern k¨

onnen, ohne das gesamte Projekt neu ¨

ubersetzen zu m¨

ussen.

Balzert definiert den Begriff Rahmenwerk wie folgt:

“Ein Rahmenwerk ist ein durch Software-Entwickler anpassbares oder erweiter-

bares System kooperierender Klassen, die einen wiederverwendbaren Entwurf

f¨

ur einen bestimmten Anwendungsbereich implementiert (vgl. [Balzert00] Seite

843).”

Jene Klassen, die entweder von anderen Klassen des Rahmenwerks abgeleitet wur-

den, oder die eine Implementierung einer abstrakten Klasse sind, k¨

onnen in das System

integriert werden. Dieser Mechanismus stellt sicher, dass die erzeugten Klassen mit den

bestehenden Klassen des Rahmenwerks kommunizieren k¨

onnen, wobei jedoch die Logik

der Ablaufsteuerung durch das Rahmenwerk verborgen bleibt. Die hinzugef¨

ugten Klassen

empfangen dann Nachrichten nach dem Hollywood-Prinzip: “Don’t call us, we’ll call you“

[Gamma95].

Im Gegensatz zum Framework sind Klassenbibliotheken Sammlungen von Klassen, die

in ein durch den Anwender erzeugtes System integriert werden. Abbildung 6.11 veran-

schaulicht den Unterschied dieser gegens¨

atzlichen Konzepte.

Rahmenwerke k¨

onnen durch ihre Architektur klassifiziert werden. F¨

ur ein Black-Box-

Rahmenwerk werden spezielle Objekte zur Parametrisierung instantiiert. Diese k¨

onnen

dann durch andere, vom Rahmenwerk zur Verf¨

ugung gestellte Objekte, konfiguriert wer-

den. Bei diesem Architekturdesign werden keine speziellen Kenntnisse der internen Ab-

l¨

aufe ben¨

otigt. Die Anpassungsm¨

oglichkeiten der Anwendung sind bei dieser Architektur

begrenzt, denn die Struktur ist durch das Rahmenwerk vordefiniert.

6.1. DAS AUTORENWERKZEUG LYSSA 139

Bestehende Software

Anwendung spezifischer Software

Klassenbibliothek

− Keine Ablaufsteuerung − Ablaufsteuerung

spezieller Objektinstanzen

− Benutzung durch Erzeugung

Rahmenwerk

− Benutzung durch Erzeugung

spezieller Instanzen, Speziali−

sierungen und Implemen−

tierung abstrakter Klassen

Abbildung 6.11: Framework vs. Klassenbibliothek

Die Verwendung eines White-Box-Rahmenwerks erfordert hingegen die Kenntnis der

internen Abl¨

aufe. Der Entwickler bzw. die Entwicklerin muss die genauen Zusammenh¨

an-

ge kennen, da der entwickelte Code mit dem Rahmenwerk zu einer Anwendung instan-

tiiert wird. Die Erweiterung der Applikation findet durch Unterklassenbildung, bzw. Im-

plementierung vorgefertigter Schnittstellen statt. White-Box-Rahmenwerke bieten durch

ihren erweiterbaren Ansatz eine große Flexibilit¨

at in der Anwendungsentwicklung (vgl.

[Z¨

ullighoven98]).

Eine andere M¨

oglichkeit bietet eine Kombination beider Architekturprinzipien. So ist

es vorstellbar, dass White-Box-Rahmenwerke vordefinierte Standardl¨

osungen enthalten,

die ohne Kenntnis der internen Struktur verwendet werden. Andererseits lassen sich auch

Black-Box Rahmenwerke derart erweitern, dass sie durch White-Box-Mechanismen bear-

beitet werden k¨

onnen.

Das Kurs-Framework

Bei der Entwicklung großer Softwaresysteme treten in der Konzeptionsphase wiederholt

Fragen nach der Erweiterbarkeit und der Wiederverwendbarkeit auf, die bei dem Ent-

wurf ber¨

ucksichtigt werden sollten. Gerade f¨

ur die Implementierung einer Autorenumge-

bung steht zu Beginn der Entwicklung noch nicht fest, welche Formate eingelesen werden

m¨

ussen und in welcher Form Kurse pr¨

asentiert werden sollen. Um an dieser Stelle eine

140 KAPITEL 6. UMSETZUNG

gewisse Unabh¨

angigkeit zu schaffen, wurde das in Abschnitt 6.1.7 vorgestellte Framework-

Konzept umgesetzt. Auf der einen Seite verwendet die Autorenumgebung Lyssa das Kurs-

Framework als Klassenbibliothek, damit das Framework zugleich von anderen Applika-

tionen eingebunden werden kann und andererseits ist sie durch den Einsatz abstrakter

Klassen derart erweiterbar, dass individuell implementierte L¨

osungen dynamisch nachge-

laden werden k¨

onnen, ohne die gesamte Applikation neu ¨

ubersetzen zu m¨

ussen.

CKS Lyssa−DesignerLyssa

Kurs−Framework

HTML 2

HTML 1

PDF

Latex

DocBook

Office

konverter

Fromel−

konverter

Bild−

Laderoutinen Pakete

Transformations− Applikationen

KonverterKursmodell

Abbildung 6.12: Das Framework

Abbildung 6.12 zeigt den modularisierten Aufbau des erweiterbaren Kurs-Frameworks.

Das Framework besteht aus den beiden Komplexen Kursmodellschnittstelle und Konvertie-

rungsschnittstelle. Die hellen Komponenten zeigen die austauschbaren bzw. erweiterbaren

Module, die sich unabh¨

angig von dem Framework entwickeln lassen. Das Kursmodell kann

w¨

ahrend seiner Initialisierung die vorhandenen Laderoutinen einlesen und sie den ¨

uberge-

ordneten Applikationen anbieten. Zudem verf¨

ugt der Konverter ¨

uber eine variable Anzahl

an Transformationspaketen und Applikationen, die den Funktionsumfang der nutzenden

Applikation beliebig erweitern.

6.2 Das Layoutwerkzeug Lyssa-Designer

Bisher wurde lediglich die Erstellung und Bearbeitung von formatierbaren Kursen vorge-

stellt. Im Folgenden wird nun ein weiteres Werkzeug, der Lyssa-Designer, pr¨

asentiert. Er

unterst¨

utzt die Format- und Layoutentwicklung und wurde speziell f¨

ur die in Abschnitt

5.5.4 eingef¨

uhrten Rollen Formatentwickler/-in und Layoutentwickler/-in konzipiert. Mit

dem Designer lassen sich Transformationspakete (TP) ¨

uber eine grafische Benutzerschnitt-

stelle ¨

offnen, bearbeiten und speichern. Das Anwendungsmodell sieht die zwei Modi Kon-

figuration und Entwicklung vor, auf die im Folgenden n¨

aher eingegangen wird.

6.2. DAS LAYOUTWERKZEUG LYSSA-DESIGNER 141

Konfiguration: Dieser Modus erlaubt es ausschließlich Einstellungen an einem TP vor-

zunehmen. Jeder Transformator besteht aus einer Liste assoziierter ¨

Ubersetzungs-

regeln, die detaillierte Informationen f¨

ur die Transformation liefern. Ein Beispiel

f¨

ur eine solche Regel ist die ¨

Ubersetzungsvorschrift f¨

ur eine Tabelle. Zu dieser Ta-

belle kann genau ein Property-Fenster ge¨

offnet werden, welches die einzustellenden

Layout-Merkmale der Tabelle anzeigt.

Development: Bei dem zweiten Modus steht vor allem die Formatentwicklung im Vor-

dergrund. Hierf¨

ur wird in erster Linie das zu erzeugende Datenformat definiert,

indem ¨

Uberstzungsregeln formuliert werden. F¨

ur die Regeln m¨

ussen w¨

ahrend der

Formatdefinition variable Parameter, wie Abst¨

ande, Farbwerte oder Linienst¨

arken,

festgelegt werden. Sie werden derart gekennzeichnet, dass sie vom Konfigurations-

modus als einstellbare Layouteigenschaften erkannt und zur Modifikation angezeigt

werden. Des weiteren werden die f¨

ur ein TP relevanten Transformatoren zugewiesen

und Ressourcen, Prozessoren und Schemata bearbeitet.

Abbildung 6.13 zeigt einen Screenshot des Konfigurationsmodus. Auf der linken Sei-

te werden die im Paket konfigurierten Transformatoren aufgef¨

uhrt. Jeder Transformator

besitzt eine Liste von ¨

Ubersetzungsregeln, die sich bei Bedarf ¨

offnen und schließen las-

sen. Wird eine der Regeln durch Selektion ausgew¨

ahlt, erscheint auf der rechten Seite ein

MDI-Fenster, das die Eigenschaften der ausgew¨

ahlten ¨

Ubersetzungsregeln anzeigt. Dieses

Beispiel zeigt die konfigurierbare Kopfzeile einer HTML-Seite. Die Eigenschaften bestehen

aus einem Bezeichner und einem zugeh¨

origen Wert. Anhand des Typs wird entschieden,

wie der Wert manipuliert werde muss. So ist z. B. die Einstellung eines Farbwertes an

einen Auswahldialog f¨

ur Farben gekoppelt und Zahlenwerte an eine Textbox, in der sie

modifiziert werden k¨

onnen. F¨

ur die Titelzeile lassen sich zuerst zwei Farbwerte einstellen,

gefolgt von dem Logo der Titelzeile, mit weiteren Bildattributen. Das vorliegende Beispiel

zeigt die Titelzeile zur Darstellung eines HTML-Layouts der GET-Arbeitsgruppe.

Der zweite Screenshot (vgl. Abb. 6.14) zeigt hingegen den Entwicklungsmodus des

Lyssa-Designers. Auf der linken Seite werden die Transformatoren in Form von Karteikar-

tenreitern angezeigt, von denen genau einer zur Zeit ausgew¨

ahlt werden kann. In diesem

Beispiel ist der Transformator f¨

ur die Navigation selektiert und wurde der Startdatei navi-

gation.xsl zugeordnet. Mit dieser Zuordnung kann der ¨

Ubersetzer bzw. die ¨

Ubersetzerin

entscheiden, welche Datei f¨

ur die Transformation eingesetzt werden soll. Unter den Trans-

formatoren befinden sich die Dateien, die f¨

ur die ¨

Ubersetzung ben¨

otigt werden. In diesem

Beispiel werden ausschließlich .xsl-Dateien angezeigt, wobei f¨

ur Java-Transformatoren

.class-Dateien ausgew¨

ahlt werden m¨

ussen. Zus¨

atzlich ist ein File System Explorer vor-

handen, der ¨

ahnlich wie der Windows-Explorer die Arbeit mit dem Dateisystem des Ar-

beitsrechners erm¨

oglicht. Hierdurch lassen sich zus¨

atzliche Dateien per Drag and Drop in

den dar¨

uber liegenden Bereich ziehen und stehen so f¨

ur die Transformation zur Verf¨

ugung.

Auf der rechten Seite wird der Entwicklungsbereich der ge¨

offneten Navigation ange-

zeigt. Der obere Abschnitt entspricht der bereits bekannten Darstellung der Konfigurati-

onsansicht. Sie dient zur Verifizierung neuer Einstellungen, die im unteren Bereich durch-

142 KAPITEL 6. UMSETZUNG

Abbildung 6.13: Lyssa Designer – Konfigurationsansicht

gef¨

uhrt werden. In diesem Bereich k¨

onnen die im Layout festgelegten Eigenschaften in die

Ubersetzungsregeln eingebaut werden. Dadurch kann die Rolle Formatentwickler/-in (vgl.

Abb. 5.23), in der Gestaltungsphase die Layout-Eigenschaften variabel einbauen. Hierbei

wird der Grad der Konfigurierbarkeit vom Layoutentwickler bzw. von der Layoutentwick-

lerin festgelegt. Wurde beispielsweise eine neue Eigenschaft in einer ¨

Ubersetzungsregel

verankert, kann durch Bet¨

atigung des Knopfes unterhalb des Entwicklungsbereichs, die

Anderung direkt ¨

ubernommen werden, wobei die Konfigurationsansicht um das gerade er-

stellte Element erweitert wird. Wurde die Eigenschaft jedoch syntaktisch falsch definiert,

weist das Programm auf den Fehler hin. Dieses gew¨

ahrleistet, dass alle Layouteigenschaften

in der Konfigurationsansicht vorhanden sein m¨

ussen.

Des weiteren verf¨

ugt der Lyssa-Designer ¨

uber eine Voransicht des zur Zeit in Bearbei-

tung stehenden Layouts. Dies ist hilfreich bei der Fehlersuche und erm¨

oglicht die Ansicht

der kurz zuvor durchgef¨

uhrten ¨

Anderungen.

Die Einstellungen des Transformationspaketes werden in einer Manifest-Datei gespei-

chert. Die Parameter (vgl. Attribute 1 bis 1.5 in C.1), die nicht direkt den ¨

Ubersetzungs-

prozess konfigurieren, sind Informationen ¨

uber das Paket und werden ¨

uber einen separaten

Konfigurationsdialog angeboten. Abbildung 6.15 zeigt den Dialog zur Konfiguration der

6.2. DAS LAYOUTWERKZEUG LYSSA-DESIGNER 143

Abbildung 6.14: Lyssa Designer – Entwicklungsansicht

Grundeinstellungen eines TPs. Zun¨

achst wird der Name des Pakets und dessen Kursbe-

schreibung eingegeben. Zudem kann ein beliebiges Logo festgelegt werden. Diese Informa-

tionen werden von dem Autorensystem Lyssa ausgewertet und f¨

ur die Pr¨

asentation der

TPs als Auswahlliste pr¨

asentiert. Der mittlere Block kennzeichnet das Ausgabeformat.

Wenn das Ausgabeformat sich aus mehreren Dateien zusammensetzt, muss f¨

ur jede zu

erzeugende Datei ein Dateipr¨

afix hinterlegt werden und die Startdatei ausgew¨

ahlt werden.

Diese Dateisammlung kann optional in einem komprimierten Archiv gespeichert werden.

Dieses ist z. B. beim HTML-Format notwendig, da mehrere HTML-Dateien f¨

ur eine Aus-

gabe ben¨

otigt werden. Soll das Paket jedoch ein PDF-Dokument erzeugen, wird nur eine

Datei angelegt, die nicht als Archiv exportiert werden muss.

6.2.1 Implementierung

F¨

ur die Implementierung des Designers wurde bereits in der Entwurfsphase der Bezug

von den Daten zu dem GUI hergestellt. Jeder Layouttyp wird durch eine eigene Klasse

realisiert, die gemeinsam mit anderen Typen die Klasse AbstractLayoutType als Basis

verwendet. Aufgrund der polymorphen Eigenschaften der abgeleiteten Klassen, k¨

onnen sie

als Objekte der Klasse AbstractLayoutType einheitlich vom LayoutHandler mit Werten,

wie z. B. der Kursbeschreibung oder das Daten-Objekt selbst, versehen werden. Daraus

144 KAPITEL 6. UMSETZUNG

Abbildung 6.15: Lyssa Designer – Grundeinstellung

LayoutData

XSLData JDOMData

LayoutHandler

getTransformer()

getLayout()

Transformation

Package

BooleanType ImageType

IntegerType ChooserType

AbstractLayoutType

JPanel

LayoutType

setDescription()

setValue()

setLayoutData()

setValue()

setLayoutData()

setDescription()

Abbildung 6.16: UML-Diagramm des Designers

resultiert, dass Layouttypen jederzeit ihr Datum ver¨

andern k¨

onnen. Des weiteren erbt

6.3. CONSTRUCTION KIT SERVER 145

jeder Layouttyp von der Klasse JPanel4, so dass jeder Komponententyp seinen eigenen

Konfigurationsdialog anbieten kann. Wird dieser interaktiv manipuliert, kann der modi-

fizierte Wert direkt dem Objekt der LayoutData-Klasse ¨

ubergeben werden. Soll das TP

abgespeichert werden, so m¨

ussen die Werte nicht erst aus dem GUI abgerufen werden,

sondern k¨

onnen unter Verwendung der Datenstruktur gespeichert werden.

6.3 Construction Kit Server

Der Construction Kit Server (CKS) [Baudry04a] ist ein zentrales Repository f¨

ur die Ver-

waltung formatierbarer Lernbausteine und Kurse und erweitert das Autorensystem um

eine kooperative Entwicklungsumgebung. Der im Rahmen des mαth-kit Projekts realisier-

te CKS implementiert die im Modell (vgl. Kaptiel 5.6) geforderten Eigenschaften eines

zentralen Repositories:

Authentifizierung: Benutzer und Benutzerinnen des Autorensystems k¨

onnen sich am

CKS anmelden, um Zugriff auf einen pers¨

onlichen Arbeitsbereich zu erhalten. Au-

ßerdem ist die Authentifizierung notwendig, um den Zugriff auf Bausteine zu regeln.

Exklusive Schreibrechte: Das exklusive Schreibrecht regelt den parallelen Zugriff auf

verteilte Dateisysteme.

Versionierung: Zwischenst¨

ande werden mit Versionsnummern versehen und ggf. zu ei-

nem sp¨

ateren Zeitpunkt abgerufen.

Der CKS wurde als Webapplikation realisiert, weil die geforderten Eigenschaften mit

Hilfe moderner Technologien, wie z. B. dem Jakarta-Tomcat und dem Slide Projekt, leicht

umzusetzen sind. Die Authentifizierung wird durch den Authentifizierungsmechanismus

des Webservers realisiert, so dass die Anmeldemaske als dynamische Website aufgebaut

wird. Nach erfolgreicher Authentifizierung, wird ein Dateibaum, bestehend aus Kursen

und Bausteinen, aufgebaut. Hinter der jeweiligen Datei, stehen die Attribute Gr¨

oße,Er-

stellungsdatum,Benutzer,Revisionsnummer und Bearbeitungszustand. Wird ein Baustein

bzw. ein Kurs selektiert, so werden weitere Daten ¨

uber das Objekt angezeigt. Hierzu geh¨

ort

die Revisionsnummer, die den Zugriff auf eine fr¨

uhere Version erlaubt. Die zwei Schl¨

osser

auf der rechten Seite der Abbildung informieren ¨

uber den aktuellen Zustand der Objekte

und zeigen an, dass sie zur Zeit mit exklusiven Schreibrechten ge¨

offnet wurden.

Abbildung 6.18 zeigt die Administrationsansicht des CKS. Mit diesem ebenfalls web-

basierten Werkzeug, k¨

onnen neue Anwender bzw. Anwenderinnen angelegt oder gel¨

oscht

werden. Hierbei wird jedem Benutzernamen eine feste Gruppe zugeordnet, die, so wie in

einem realen Dateisystem, gruppenweite Rechte festlegt.

4JPanel ist Bestandteil der Java-Swing-Bibliothek und wird f¨

ur die grafische Gestaltung eines Fenster-

bereichs in einem GUI ben¨

otigt.

146 KAPITEL 6. UMSETZUNG

Abbildung 6.17: CKS Browser – Erm¨

oglicht das Navigieren in verteilten Dateisystemen

und die ¨

Uberwachung nebenl¨

aufiger Aktionen

Abbildung 6.18: CKS Administration – Eine Eingabemaske, mit der Benutzer und Benut-

zerinnen angelegt und gel¨

oscht werden.

6.3. CONSTRUCTION KIT SERVER 147

6.3.1 Slide

F¨

ur die Implementierung des CKS wurde das Jakarta-Slide Projekt ausgew¨

ahlt. Hierbei

handelt es sich um ein technisches Rahmenwerk zur Erstellung von im Internet verteilten

Dateiservern. Durch den Einsatz von Struts [Str05] und Java Server Page (JSP) [JSP05]

werden Kommandos angeboten, die einen einfachen Zugriff auf Dateisysteme ¨

uber Websei-

ten erm¨

oglicht. F¨

ur die physikalische Dateiverwaltung werden neben Dateisystemen auch

Datenbanken unterst¨

utzt. Je nach Bedarf k¨

onnen die ¨

uber das WebDAV-Protokoll an-

gebotenen Dateien entweder direkt in das Dateisystem des Servers geschrieben werden

oder in einer Datenbank gespeichert werden. Eigene Applikationen nutzen die von Slide

angebotenen Dienste, um Informationen ¨

uber Dateien zu erhalten. So k¨

onnen z. B. Da-

teigr¨

oße, Autoren, Zugriffsrechte oder Revisionsnummern hierarchisch abgefragt und auf

einer Webseite dargestellt werden.

WebDAV Servlet CKS−Browser

Lyssa APISlide API

Storage

FilesystemDatabase Other

Lyssa

Windows

Explorer Konqueror Client

Server

Webbrowser

Abbildung 6.19: Schichtenmodell des Construction Kit Server

Abbildung 6.19 illustriert die Serverschnittstelle des CKS. Das WebDAV -Servlet er-

laubt den Zugriff auf das Dateisystem ¨

uber das WebDAV-Protokoll. Neben dem Windows-

Explorer unterst¨

utzt auch der KDE-Konqueror den WebDAV-Zugriff auf Repositories.

Zudem kann unter Verwendung eines einfachen HTML-Browsers auf den CKS zugegriffen

werden. Der CKS-Browser setzt, genau wie der Lyssa-Designer, direkt auf dem Kurs-

Framework auf und bietet daher die Generierung einer Voransicht f¨

ur ausgew¨

ahlte Kurse

an.

148 KAPITEL 6. UMSETZUNG

Kapitel 7

Beispiele

Nachdem das grundlegende Modell und dessen Implementierung vorgestellt wurden, sollen

nun konkrete Ergebnisse in Form von Beispielen folgen. Der Kurs, der in den folgenden

Abschnitten konstruiert wird, wurde im Rahmen des mαth-kit Projekts entwickelt, das sich

als hervorragendes Umfeld f¨

ur die Anwendbarkeit des Modells herausgestellt hat. Hierbei

geht es vor allem um die Demonstration der kooperativen und modularen Kurskonstruktion

und der gezielten Adaption individueller Pr¨

asentationsformen.

Zun¨

achst wird die f¨

ur die Grundstudiumsausbildung ausgew¨

ahlte Grundlagenveran-

staltung Technische Informatik analysiert und eine m¨

ogliche Umsetzung in einen E-

Learning-Kurs diskutiert. Hierzu geh¨

ort neben den technischen Rahmenbedingungen auch

didaktische Merkmale, die erheblich zu der Gestaltung des Kurses beitragen. Des wei-

teren werden die ausgew¨

ahlten Lektionen Minimierungsverfahren und Komplexe Zahlen

pr¨

asentiert und deren konkrete Umsetzung durch das Autorensystem erl¨

autert. Damit der

entwickelte Kurs f¨

ur verschiedene Lernszenarien eingesetzt werden kann, wird abschließend

die Regeldefinition f¨

ur Pr¨

asentationsformate veranschaulicht.

7.1 Technische Informatik - Exemplarische Kursentwick-

lung

F¨

ur die Grundstudiumsausbildung im Fach Technische Informatik existiert ein mit Latex

gesetztes Skript [Mertsching02], welches Studierenden der Informatik vorlesungsbegleitend

zur Verf¨

ugung gestellt wird, um den in den Vorlesungen erarbeiteten Stoff zu einem sp¨

teren Zeitpunkt nachbereiten zu k¨

onnen. Ferner dient es zur Vorbereitung auf Klausuren

und ¨

Ubungsgruppen, die den Studierenden zus¨

atzlich angeboten werden. Des weiteren wer-

den ¨

Ubungsaufgaben verteilt, zu denen entsprechende Musterl¨

osungen existieren. Dieses

Kursmaterial wird im Folgenden zur Illustration der Kursentwicklung verwendet.

Erg¨

anzend, zu dem bereits vorhandenen Angebot, soll das Projekt mαth-kit die Aus-

bildung durch den Einsatz von Online-Angeboten derart verbessern, dass Studierende

anhand multimedialer Lernmodule komplexe Inhalte interaktiv bearbeiten k¨

onnen und

theoretische Sachverhalte durch geeignete Abstraktionen selbst ausprobieren und leich-

ter verstehen k¨

onnen. Ebenso wichtig ist die Anreicherung des bestehenden Angebots

149

150 KAPITEL 7. BEISPIELE

durch bewerte Exkurse, die, in Abh¨

angigkeit individueller Voraussetzungen, durchzuar-

beiten sind.

Die n¨

achsten Abschnitte stellen, angefangen bei der Analyse, den Aufbau des On-

linekurses Technische Informatik vor und zeigen, wie Inhalte, die durch Projektpartner

und Projektpartnerinnen entstanden sind, sich nahtlos in den Kurs einflechten lassen. Zur

Veranschaulichung werden die beiden Kapitel Minimierungsverfahren und Wechselstrom-

schaltungen vorgestellt.

7.1.1 Analyse

Zun¨

achst muss der Lehrstoff derart strukturiert werden, dass er aus logisch zusammenh¨

an-

genden Teilen besteht. Hierzu ist, neben dem eigentlich zu vermittelnden Stoff, auch ein

Ubungsbereich vorhanden, in dem Studierende Aufgaben l¨

osen k¨

onnen, sowie ein Explora-

tionsbereich, der, entsprechend dem konstruktivistischen Lernparadigma, die M¨

oglichkeit

zum Lernen durch Erfahren anbietet [Unger04].

7.1.2 Aufbau einer Lerneinheit

Nachdem die grobe Struktur des Lernmoduls festgelegt worden ist, muss der Lehrstoff

entsprechend dem Baukastenprinzip partitioniert werden. Es stellt sich die Frage nach

der Wahl einer sinnvollen Granularit¨

at. Das Baukastenprinzip ¨

uberl¨

asst, im Gegensatz zu

anderen Modellen f¨

ur Lernobjekte, Autoren bzw. Autorinnen freie Hand bei der Erstel-

lung von Bausteinen. Lediglich deren Abgeschlossenheit muss bei der Entwicklung wei-

ter ber¨

ucksichtigt werden. Insbesondere ist darauf zu achten, dass Themenbereiche nicht

zwingend andere voraussetzen. Trifft dieses jedoch zu, sollten solche Bausteine zu gr¨

oße-

ren Bausteinen zusammengesetzt werden. Dabei ist grunds¨

atzlich zu bedenken, dass die

Granularit¨

at von einem einfachen Applet bis hin zu einer vollst¨

andigen Lektion, inklusive

enthaltener ¨

Ubungen und Explorationsbereiche, reicht.

Abbildung 7.1 zeigt auf der rechten Seite das Kapitel Wechselstromschaltungen mit

seinen Unterkapiteln und auf der linken Seite eine Liste eigenst¨

andiger Module. In diesem

Beispiel ist der Abschnitt Analyse von Wechselstromschaltungen in die Unterabschnitte

Komplexe Gr¨

oßen und Zeigerdarstellungen von sinusf¨

ormigen Wechselgr¨

oßen gegliedert.

Der Kurs Komplexe Zahlen ist als Exkurs im Grundstudium zu betrachten, der sich auf-

grund seiner thematischen Unabh¨

angigkeit gut f¨

ur die Umsetzung eines Bausteins eignet.

Entsprechendes gilt f¨

ur das Unterkapitel Zeigerdarstellung von sinusf¨

ormigen Wechselgr¨

ßen, da es das Thema Komplexen Zahlen zwar f¨

ur das Verst¨

andnis voraussetzt, jedoch

nicht als integralen Bestandteil mit einbezieht.

7.1.3 Kurskonstruktion

Im Folgenden werden aus dem Themenbereich Technische Informatik die beiden Abschnit-

te Minimierungsverfahren und Wechselstromschaltungen ausgew¨

ahlt und deren Umset-

zung vorgestellt. Anhand des Themas Minimierungsverfahren soll zun¨

achst der modulare

Aufbau einer Lektion illustriert werden, der durch den oben beschriebenen Kursaufbau

7.1. TECHNISCHE INFORMATIK - EXEMPLARISCHE

KURSENTWICKLUNG 151

Modul1

Modul n

Modul

Komplexe Zahlen

Komplexe Zahlen (TI)

8. Wechselstromschaltungen

8.1 Sinusförmige Wechselgrößen

8.2 Mittelwerte sinusförmiger Zeigerfunktionen

8.3 Arithmetische Operationen zwischen

sinusförmiger Wechselgrößen gleicher Frequenz

8.4 Analyse von Wechselstromschaltungen im Zeitbereich

8.5 Analyse von Wechselstromschaltungen im Frequenzbereich

8.5.1 Komplexe Größen

8.5.2 Zeigerdarstellung von sinusförmigen Wechselgrößen

Abbildung 7.1: Basisformat f¨

ur Kurse

charakterisiert ist. Das zweite Thema verdeutlicht dagegen das Zusammenwirken mehre-

rer Autoren und zeigt, wie, unter Verwendung des in dieser Arbeit vorgestellten Modells,

eine kooperierende Erzeugung fach¨

ubergreifender Lehrinhalte erstmals erm¨

oglicht wird.

Minimierungsverfahren

Das Thema Minimierungsverfahren ist integraler Bestandteil einer Grundlagenveranstal-

tung mit dem Titel Minimierung von Schaltfunktionen, die f¨

ur die Synthese von Schaltwer-

ken notwendig ist. In dieser Lektion werden die Verfahren nach Quine und McCluskey und

die Minimierung mit KV-Diagrammen durch interaktive Lernbausteine konstruiert und

vorgestellt. Zur Veranschaulichung zeigt Abbildung 7.2 eine ausgew¨

ahlte Pr¨

asentationsfo-

lie, die in der Pr¨

asenzveranstaltung eingesetzt wird. Auf der linken Seite ist das Inhalts-

verzeichnis des gesamten Skripts zu sehen, das aus mehreren hundert Folien besteht. Um

Bausteine erstellen zu k¨

onnen, muss eine sinnvolle Granularit¨

at gew¨

ahlt werden. In Anleh-

nung an die in Kapitel 7.1.2 dargelegte Analyse, wird das Kapitel Minimierungsverfahren

nach Quine und McCluskey herausgegriffen und als eigenst¨

andiger Baustein modelliert.

Dieser Baustein soll als Einf¨

uhrung in die Thematik dienen und erf¨

ullt das Kriterium der

Abgeschlossenheit, da keine Verweise auf andere, f¨

ur das Verst¨

andnis wichtige, Abschnitte

vorhanden sind und dessen Gr¨

oße, mit dem aus didaktischer Sicht zumutbaren Umfang,

einhergeht. Abbildung 7.3 zeigt einen mit dem Autorenwerkzeug Lyssa zusammengesetz-

ten Baustein, der aus mehreren Abbildungen besteht, die als PNG-Dateien eingebunden

sind. Zus¨

atzlich ist eine Content-Datei enthalten, die den Inhalt des Lernobjekts anhand

des in Kapitel 6.1.2 vorgestellten XML-Bindings kodiert. Das folgende Listing zeigt einen

Ausschnitt aus dem Content-Modell des Bausteins, wie er in der Quelle vorliegt.

Listing 7.1: Dieses einfache Beispiel stammt aus einem Baustein zur Erl¨

auterung des Mini-

mierungsverfahrens nach Quine-McCluskey und veranschaulicht ein XML-basiertes Lern-

objekt

<?xml version=”1.0” encoding=”ISO−8859−1”?>

152 KAPITEL 7. BEISPIELE

Abbildung 7.2: Kursmaterialien f¨

ur die Pr¨

asenzveranstaltung Technische Informatik in der

Grundstudiumsausbildung

2<lob title=”Minimierungsverfahren nach Quine und McCluskey” xml:lang=”de”>

...

<p>Durch eine Erweiterung von McCluskey kann die Schaltfunktion

5weiter vereinfacht werden.Hierzu wird die Schaltfunktion in der

Primimplikantentafel dargestellt:</p>

8<p>Die Spalten werden mit den Dezimalzahlen der

urspr¨

unglichen Minterme und die Zeilen mit denen der

Primimplikanten bezeichnet:</p>

<p>Es werden die Stellen markiert,f¨

ur die gilt,daß der

Primimplikant in dem jeweiligen Minterm enthalten ist (”x”).</p>

17<p>Nun werden die Eintr¨

age markiert,die allein in einer Spalte

auftreten (hier: eingeklammert).</p>

20<p>Die Primimplikanten der so markierten Zeilen sind wesentlich

(<h>Kernimplikanten</h>)und m¨

ussen in der Schaltfunktion

auftreten,die restlichen Primimplikanten werden gestrichen.</p>

7.1. TECHNISCHE INFORMATIK - EXEMPLARISCHE

KURSENTWICKLUNG 153

<p>Es ergibt sich daher die folgende Vereinfachung:</p>

26<formula inline=”false” mode=”latex”>

y= (b 2 \wedge \bar{b 3} \wedge b 4)\vee (\bar{b 1} \wedge

\bar{b 4})\vee(b 3 \wedge \bar{b 4})

29</formula>

<p>(Minimalform)</p>

</lob>

Abbildung 7.3: Der Baustein Minimierungsverfahren zusammengestellt aus einer Content-

Datei und mehreren Abbildungen

Dieses einfache Beispiel verdeutlicht die Kombination grundlegender Elemente zum

Setzen von Texten, Grafiken und Formeln. Nachdem der Baustein fertig gestellt ist, kann

er in beliebige Grundlagenkurse, deren Thema die Einf¨

uhrungen in Minimierungsverfahren

ist, kontextfrei eingebettet werden.

Eine andere Variante zur Minimierung von Schaltfunktionen ist die Methode mit KV-

Diagrammen. Dieses ebenfalls eigenst¨

andige Gebiet wird in gleicher Weise als separater

Baustein modelliert. Dieser Abschnitt l¨

asst sich jedoch noch weiter unterteilen, so dass

z. B. der Baustein Minimierung bei Don’t-care-Termen als weiterf¨

uhrende Vertiefung an-

geh¨

angt werden kann. Abbildung 7.4 zeigt einen modular aus Bausteinen aufgebauten

Kurs zum Thema Grafische Minimierung. Beide Minimierungsvarianten werden separat

eingef¨

uhrt und k¨

onnen zu jedem Zeitpunkt per Drag’n’Drop aus der Kursansicht heraus

154 KAPITEL 7. BEISPIELE

Abbildung 7.4: Das Autorenwerkzeug Lyssa mit dem ge¨

offneten Kurs Grafische Mini-

mierung

in einen anderen Kurs verschoben werden. Wurde jedoch von einem anderen Autor bzw.

einer anderen Autorin eine weitere Variante implementiert, z. B. ein algebraisches Mini-

mierungsverfahren, so kann dieses nahtlos in den bereits bestehenden Kurs mit aufgenom-

men werden und aufgrund der gemeinsamen Modellbasis, ein konsistenter Kurs entstehen.

Die Umsetzung des soeben diskutierten Kurses ist in Abbildung 7.5 veranschaulicht. F¨

das Zielformat wurde eine auf der GET-Homepage basierende HTML-Variante entwickelt,

die aus den drei Bereichen Navigation,Titelzeile und Baustein besteht. Die Kursnaviga-

tion befindet sich auf der linken Seite und ist aus der Kursstruktur von Lyssa generiert

worden. Die Titelzeile enth¨

alt den Namen des Kurses und auf der rechten Seite ist der in

Listing 7.2 vorgestellte Baustein zu sehen.

Der entwickelte Kurs wurde auf der Grundlage des bereits existierenden Skriptums

erstellt und ist daher f¨

ur Studierende rein informativ. Der Mehrwert, der gerade durch

multimediale Komponenten erzielt wird, ist bisher nicht weiter genutzt worden. Deshalb

soll nun der vorliegende Inhalt – entsprechend dem Resultat aus der in Abschnitt 7.1.1

vorgestellten Analyse – um eine Explorations- und ¨

Ubungsumgebung erweitert werden.

F¨

ur die verschiedenen Verfahren zur grafischen Minimierung von Schaltfunktionen bie-

tet sich die Entwicklung einer interaktiven Umgebung geradezu an, denn die Algorithmen

basieren auf grafischen Verfahren, die sich durch ein Softwaremodell vollst¨

andig realisie-

ren lassen. ¨

Ubungen werden ebenso wie der bereits erzeugte Grundlagenkurs als Bausteine

7.1. TECHNISCHE INFORMATIK - EXEMPLARISCHE

KURSENTWICKLUNG 155

Abbildung 7.5: Der Kurs Grafische Minimierung ¨

ubersetzt mit einem Transformationspa-

ket f¨

ur die Erstellung eines GET-Lab-Kurses.

erstellt. Das Ergebnis sind zwei Aufgabenkomplexe zu je einem Minimierungsverfahren,

wobei jede Aufgabe einen eigenst¨

andigen Baustein darstellt. Die Aufgaben unterscheiden

sich vor allem durch ihre ansteigende Komplexit¨

at sowie durch die Beschaltung unter-

schiedlich vieler Schaltvariablen. Das Ergebnis einer ¨

ubersetzten ¨

Ubungseinheit ist in Ab-

bildung 7.6 zu sehen. Auf der linken Seite befindet sich ein interaktives KV-Diagramm,

welches zur L¨

osung einer Aufgabe benutzt werden kann. Die Aufgabe, die hier gestellt

wird, ist die optimale Minimierung der angegebenen Schaltfunktion zu finden. Durch ge-

schickte Gruppierung von Nullen bzw. von Einsen k¨

onnen redundante Operationen erkannt

und vermieden werden. Die linke Seite zeigt das korrespondierende Schaltnetz mit seinen

UND- und ODER-Gattern. Hierbei k¨

onnen auch nicht optimale L¨

osungen gefunden wer-

den. Unerfahrene Studierende k¨

onnen nach dem behavioristischen Lernparadigma durch

’ausprobieren’ und der Analyse eigener Fehler die Grundprinzipien der grafischen Mini-

mierung einpr¨

agsam erlernen.

Wechselstromschaltungen

Nachdem gezeigt worden ist, wie Kurse strukturiert werden und wie ein Kurs zur Mini-

mierung von Schaltfunktionen realisiert werden kann, soll sich nun die Aufmerksamkeit auf

die kooperative Konstruktion richten. Anhand des Kurses Komplexe Zahlen soll erstmals

gezeigt werden, wie Lernressourcen von mehreren Autoren und Autorinnen erzeugt und

156 KAPITEL 7. BEISPIELE

verwendet werden.

Eine elementare Grundvoraussetzung f¨

ur die Entwicklung solcher Lernmaterialien ist

die Einhaltung der in Abschnitt 7.1.1 beschriebenen Vorgehensweise w¨

ahrend der Kon-

zeptionsphase. Das bedeutet insbesondere, dass bereits bei der Kurskonzeption an die

Wiederverwendung einzelner Subkomponenten gedacht wird. Was auf den ersten Blick

einfach erscheint, ist auf den zweiten Blick jedoch keineswegs trivial. Die Schwierigkeit

liegt vor allem darin, einen Baustein derart zu gestalten, dass er wiederverwendet wer-

den kann. Dies geht nur dann, wenn der Baustein seiteneffektfrei entworfen wird. Bei der

Entwicklung neuer Kurse muss der gesamte Kursaufbau strukturiert werden und nicht

einfach ein großer Baustein erstellt werden. Welche Auswirkungen dies haben kann, wird

im folgenden Kapitel demonstriert.

Nachdem das Paradigma modularer Bausteine diskutiert wurde, soll anhand des Kur-

ses Wechselstromschaltungen gezeigt werden, wie Kurse in verteilten Teams entwickelt

werden k¨

onnen. Der Kursteil, der im Folgenden betrachtet wird, ist die Einf¨

uhrung in das

mathematische Gebiet der Komplexen Zahlen. Naturgem¨

aß stellt sich die Frage: “Warum

ausgerechnet Komplexe Zahlen?”. Die Antwort ist einfach, denn sie bieten sich zur Demon-

stration f¨

ur die Wiederverwendung von Lehrinhalte an. In vielen naturwissenschaftlichen

Grundlagenf¨

achern sind sie Voraussetzung f¨

ur das weitere Verst¨

andnis. Allerdings ist der

Fokus oft domainenspezifisch und Einf¨

uhrungen in das Themengebiet werden an einem

fachverwandten Anwendungsbeispiel verdeutlicht. Wird jedoch nach Gemeinsamkeiten ge-

sucht, so wird schnell ersichtlich, dass eine allgemeine Definition gilt und Rechenoperatio-

nen, wie die Addition oder Multiplikation, in jedem Fach identisch sind.

Abbildung 7.6: Ansicht einer interaktiven ¨

Ubung zur Minimierung mit KV-Diagrammen

7.1. TECHNISCHE INFORMATIK - EXEMPLARISCHE

KURSENTWICKLUNG 157

Das Forschungsprojekt mαth-kit hat sich speziell mit dieser Thematik auseinander ge-

setzt und die Fachrichtungen Mathematik f¨

ur Maschinenbauer,Maschinendynamik und

Technische Informatik multimedial aufbereitet. Es hat sich herausgestellt, dass die Be-

handlung der Komplexen Zahlen in jedem Fach unterschiedlich intensiv erfolgt, was dazu

f¨

uhrt, dass in einem Fach mehr Unterthemen angesprochen werden, als bei einem ande-

ren. Die Unterthemen lassen sich dennoch in markante Bausteine aufteilen, die sich zum

Teil mit den anderen F¨

achern ¨

uberdecken. Tabelle 7.1.3 zeigt eine Gegen¨

uberstellung der

Gliederungen aus den unterschiedlichen Fachgebieten.

Fach Thema Gliederung

Maschinendynamik Harmonische Schwingun-

gen

Einf¨

uhrung, Definition, Gauß, Dar-

stellungsformen

Mathematik f¨

ur Maschi-

nenbauer I

Komplexe Zahlen Einf¨

uhrung, Definition, Eigenschaf-

ten, Darstellungsformen, Beispiel

Harmonische Schwingungen, Funda-

mentalsatz der Algebra

Technische Informatik Analyse von Wechsel-

stromspannungen im

Frequenzbereich

Definition, Eigenschaften, Darstel-

lungsformen

Tabelle 7.1: Integration der Komplexen Zahlen in unterschiedliche Fachrichtungen

Die Gliederung der Kapitel1zeigt die Themen¨

uberschneidung in den Abschnitten De-

finition,Eigenschaften,Darstellungsformen und Eigenschaften. Die jeweiligen Auspr¨

agun-

gen der Abschnitte unterscheiden sich zwar voneinander, warum aber sollten drei verschie-

dene Varianten des gleichen Themas umgesetzt werden und mehrere Personen in einem

Team die gleichen Abschnitte bearbeiten. An diesem Punkt angelangt, kann das Problem

durch den Einsatz von Bausteinen gel¨

ost werden. Jeder der oben genannten Abschnitte

l¨

asst sich als eigenst¨

andiger und unabh¨

angiger Baustein realisieren. Bei der Konstruktion

k¨

onnen die besten Darstellungen und Erl¨

auterungen aus den Bausteinen herausgezogen

werden, und ¨

ahnlich wie beim Refactoring [Fowler99] (vgl. Abschnitt 5.4.3) f¨

ur objektori-

entierte Anwendungen, entweder in ¨

ubergeordnete Bausteine verschoben werden oder in

einen neuen Unterbaustein kopiert werden.

Im Projekt mαth-kit wurden die Gemeinsamkeiten herausgearbeitet und die Abschnit-

te in eigenst¨

andige Bausteine zerlegt, die sich nunmehr in andere Fachkurse integrieren

lassen. Im Folgenden ist der Aufbau des allgemeinen Kurses zu sehen:

•Einf¨

uhrung

•Definition

•Eigenschaften

•Gaußsche Zahlenebene

1Ausz¨

uge aus den Skripten der verschiedenen F¨

acher sind auf der Projekt-Homepage zu finden [Mat05a]

158 KAPITEL 7. BEISPIELE

•Eulersche Formel und Polarkoordinaten

•Rechenregeln

•Potenzen und Wurzeln

–Beispiel 1

–Beispiel 2

•Aufgaben

–Grundrechenarten

–Betragsbildung

–Einheitswurzel

–Darstellungsarten

•Exploration

•History

•Links

Dieser Kurs besteht aus einer allgemeinen Einf¨

uhrung, Grundlagen zu Komplexen Zah-

len, Eigenschaften und Rechenregeln sowie aus Beispielen und Aufgaben. Abgerundet wird

der Kurs durch einen Explorationsbereich zum Lernen durch ’ausprobieren’. Je nachdem

wie ausf¨

uhrlich der Abschnitt zu Komplexen Zahlen f¨

ur die jeweilige Fachdisziplin werden

soll, k¨

onnen Bausteine, wie die Aufgaben, weggelassen werden oder spezialisierte Bausteine

mit aufgenommen werden, wie z. B. die anwendungsorientierte Einf¨

uhrung.

Durch solche Maßnahmen werden die Kosten f¨

ur die Erzeugung von Kursen erheblich

gesenkt, weil sich der Aufwand f¨

ur Neuentwicklungen betr¨

achtlich reduziert, denn nicht

jeder Kurs muss von Grund auf neu geplant und umgesetzt werden. Das schließt die Erstel-

lung von Materialien f¨

ur unterschiedliche Lernformen mit ein, denn sie k¨

onnen als einzelne

Kurse im Netz, mit einem LMS (vgl. Kapitel 3.3) oder f¨

ur den Pr¨

asenzunterricht angeboten

werden2. Außerdem ist es m¨

oglich, Hardcopy-Varianten an Studierende zu verteilen.

In diesem Beispiel sind die an der Kurserzeugung beteiligten Partner projektbedingt

uber mehrere Standorte verteilt, was in der Regel zu Schwierigkeiten in der Absprache w¨

ah-

rend der Entwicklung f¨

uhrt. Es handelt sich n¨

amlich um autonome Arbeitsgruppen, die

in ihren konkreten Implementierungsschritten keiner ¨

ubergeordneten Instanz unterstehen.

Damit jedoch eine gemeinsame Entwicklung m¨

oglich wird, wurde im mathkit-Projekt der

CKS (vgl. Abschnitt 6.3) entwickelt, der kooperative Arbeitsprozesse sinnvoll unterst¨

utzt.

Aufgrund seiner standardkompatiblen Schnittstellen, wurde die Integration in Lyssa um-

gesetzt, die es den kooperierenden Partnern und Partnerinnen erm¨

oglicht, wie gewohnt

2Hierf¨

ur eigenen sich insbesondere die Bausteine zur Exploration, mit denen sich spezielle Verfahren

interaktiv vorstellen lassen

7.1. TECHNISCHE INFORMATIK - EXEMPLARISCHE

KURSENTWICKLUNG 159

Abbildung 7.7: Der Kurs Wechselstromschaltungen mit Zugriff auf den CKS

Bausteine zu ¨

offnen, anzulegen oder zu verschieben, ohne dass der Zugriff ¨

uber das Netz-

werk ¨

uberhaupt bemerkt wird. Lediglich der exklusive Zugriff auf einen im Netz gespei-

cherten Baustein wird durch ein kleines Schloss symbolisiert, welches das ¨

Uberschreiben

des Bausteins durch andere Autoren verhindert.

Das zugrunde liegende Anwendungsmodell sieht zun¨

achst die Speicherung eines neuen

Kurses durch Team A vor. Hierzu werden die Subkurse Definition und Rechenregeln pro-

duziert und im eigenen Arbeitsbereich abgelegt. Daraufhin werden die Bausteine nach der

Bearbeitung in den ¨

offentlichen Bereich kopiert, der auch anderen Personen zug¨

anglich ist.

Diese sind nun in der Lage, diese Bausteine gezielt zu verwenden und ggf. den gesammel-

ten Fundus zu erg¨

anzen. Ebenso k¨

onnen Verbesserungen bereits bestehender Kurse und

Bausteine eingepflegt werden, wobei der Zugriff auf einen fr¨

uheren Datenstand jederzeit

m¨

oglich ist.

Abbildung 7.7 zeigt das Autorenwerkzeug Lyssa mit dem ge¨

offneten Kurs Technische

Informatik. Auf der linken Seite wird ein Ausschnitt des Construction Kit Servers gezeigt,

der aus Bausteinen und Kursen zum Thema Komplexe Zahlen besteht. Der gleiche In-

halt wurde bereits in Abbildung 6.17 gezeigt, jedoch mit dem Unterschied, dass es sich

dort um den Zugang mit einem Web-Browser handelt. Bei der Entwicklung des Kur-

ses Technische Informatik k¨

onnen dadurch Kosten eingespart werden, indem Bausteine

von anderen Autoren wiederverwendet werden. Der Abschnitt Wechselstromschaltungen

setzt bei Studierenden die Kenntnis ¨

uber das Thema Komplexe Zahlen f¨

ur die Analyse

160 KAPITEL 7. BEISPIELE

im Frequenzbereich voraus. Die bereits erzeugten Basisbausteine Einf¨

uhrung,Definition,

Eigenschaften,Rechenregeln und Eulersche Formel lassen sich von dem CKS in den neu

erstellten Kursknoten Komplexe Gr¨

oßen verschieben. Zus¨

atzlich wurde ein weiterer spe-

zialisierter Baustein entwickelt, der fachbezogene Aufgaben enth¨

alt. Durch eine geschickte

Aufteilung der Komplexe Zahlen kann der Kurs Technische Informatik an der bereits

geleisteten Arbeit partizipieren.

7.2 Wiederverwendung bestehender Skriptteile

Die Entwicklung neuer E-Learning-Inhalte erfordert h¨

aufig die Wiederverwendung bereits

bestehender Materialien. Dieses k¨

onnen, neben informativen B¨

uchern, auch digitale Do-

kumente sein, deren Texte und Abbildungen in interaktiven Onlinekursen nicht fehlen

d¨

urfen. Dieser Abschnitt zeigt im Folgenden, wie das digitale Skript mit dem Titel System

Theorie [Mertsching01] vom Prototypen eingelesen und mit Hilfe des Kursmodells in einen

formatierbaren Kurs transformiert wird. Dazu muss in den Latex-Quellen nach Dokument-

strukturen gesucht werden und extrahiert werden, Assets und Metadaten erkannt werden

und aus den Daten Bausteine erstellt werden.

Abbildung 7.8: Pr¨

asentationsfolie Sinusf¨

ormige Signale aus dem Skript Systemtheorie

Zuerst wird das Skript entsprechend der Vorgehensregel aus Abschnitt 6.4 von Latex

nach DocBook konvertiert, damit die Quellen ¨

uber den DocBook-Loader eingelesen wer-

den k¨

onnen. Dieses geschieht mit Hilfe des tex4ht-Konverters, der die Latex-Strukturen

7.2. WIEDERVERWENDUNG BESTEHENDER SKRIPTTEILE 161

untersucht und daraus eine neue DocBook-Struktur aufbaut. Tex4ht setzt bereits bei der

Ubersetzung der Latex-Quellen das Einbinden des tex4ht-Paketes voraus, wodurch Zu-

satzinformationen in die Ausgabe generiert werden. Aus diesem Grund m¨

ussen dem zu

ubersetzenden Latex-Dokument folgende Zeilen hinzugef¨

ugt werden:

\pdfoutput=0

\usepackage[xhtml,docbook]{tex4ht}

\let\pdfoutput\undefined

Nach dem ¨

Ubersetzungsvorgang wird der Prozess t4ht angestoßen, um das endg¨

ultige

DocBook-Dokument zu erhalten. Der tex4ht Konverter hat hierbei die zum Basisdokument

geh¨

orenden Dateien eingelesen und daraus ein einziges – in Anbetracht des STH-Skripts –

großes XML-Dokument erzeugt. Verweise auf externe Dateien werden ¨

ubernommen und in

das DocBook-Dokument eingebunden, so dass zus¨

atzliche Dateien nicht in den Verarbei-

tungsprozess mit einbezogen werden. Formatierungen, soweit diese durch Latex zugelassen

werden, sind ebenfalls entfernt worden, da sie nicht durch das DocBook-Format unterst¨

utzt

werden und außerdem vom Transformationspaket redefiniert werden.

Abbildung 7.9: Die Kursansicht von Lyssa mit dem importierten Systemtheorie-Skript

Nachdem der Konvertierungsprozess abgeschlossen ist, kann die DocBook-Datei mit

dem entsprechendem Loader eingelesen und auf das Kursmodell abgebildet werden. Um

die Bausteine und Kurse zu erzeugen, wird die in Abschnitt 6.1.4 vorgestellte Methode des

OO-Bindings verwendet. Hierbei werden nicht nur Bausteine erstellt, sondern auch vor-

handene Ressourcen in die erstellten Bausteine kopiert. Abbildung 7.12 zeigt das mit Lyssa

eingelesene Skript als modularen Kurs, der nun f¨

ur den n¨

achsten Bearbeitungsschritt bereit

162 KAPITEL 7. BEISPIELE

Abbildung 7.10: Sinusf¨

ormige Signale als Onlinekurs. Bei dieser Pr¨

asentation wurde das

mαth-kit Layout verwendet

steht. Bausteine lassen sich jetzt in andere Kurse ziehen, durch interaktive Komponenten

erweitern oder mit den Nachbearbeitungsmethoden aus Abschnitt 5.4.3 modularisieren.

Das Ergebnis einer beispielhaften Transformation zeigt Abbildung 7.10. Es handelt

sich um einen in HTML gesetzten Kurs ¨

uber das Fachgebiet Systemtheorie, der mit den

Formatierungsregeln des mαth-kit Projekts erzeugt worden ist.

7.3 Exemplarische Entwicklung eines Formats zur Pr¨

asen-

tation

Dieser Abschnitt stellt die Entwicklung eines Pr¨

asentationsformats vor und zeigt, wie

Layout-Attribute festgelegt und sp¨

ater durch den Prototypen einzustellen sind. Das aus-

gew¨

ahlte Format wird f¨

ur die Erstellung studienbegleitender Unterlagen eingesetzt, die

als DIN A4-Skript ben¨

otigt werden. Betrachtungsgegenstand ist erneut das TI-Skript aus

Kapitel 7.1.

7.3.1 Festlegung des Layouts

Das Ziel, das mit der Layout-Vorgabe erreicht werden soll, ist eine strikte Trennung zwi-

schen Einstellungen, die das Aussehen der Pr¨

asentation beeinflussen und denen, die f¨

ur die

7.3. EXEMPLARISCHE ENTWICKLUNG EINES FORMATS ZUR

PR¨

ASENTATION 163

Generierung des Formats notwendig sind. Ferner sollen nur relevante ¨

Anderungsmerkmale,

also jene, die zu einem sp¨

ateren Zeitpunkt durch die Rolle Layoutentwickler/-in angepasst

werden soll, separat definiert werden.

Listing 7.2: Definition eines Layouts

<pub:layout>

2<pub:master unit=”cm”>

<pub:page width=”21” background=”#FFFFFF”/>

<pub:body margintop=”1”>

5...

</pub:master>

<pub:styles>

8<pub:style id=”liststyle ”>

<pub:property id=”prop01” typ=”integer”

desc=”List item space”/>

11<pub:property id=”prop02” typ=”integer”

desc=”Item indent” />

</pub:style>

14...

</pub:styles>

<pub:map>

17<pub:resource ref=”listitemspace” id=”prop01” />

<pub:resource ref=”itemlabelindent” id=”prop02” />

...

20</pub:map>

Das Layout wird zun¨

achst gem¨

aß der Layoutspezifikation (vgl. Abschnitt 5.25) als

XML-Dokument formuliert. Es enth¨

alt die f¨

ur das Seitenformat notwendigen Einstellun-

gen und wird vom ¨

Ubersetzungsprozess zur Laufzeit herangezogen. In diesem Beispiel

betr¨

agt die Breite einer Seite 21 cm und ihre Hintergundfarbe wird auf weiß gesetzt.

Neben diesen globalen Eigenschaften werden f¨

ur die individuelle Gruppierung von Merk-

malen Styles eingesetzt. Zur Verdeutlichung zeigt Listing 7.2 zwei Style-Attribute f¨

ur die

Abstandsformatierung von Aufz¨

ahlungen.

7.3.2 Festlegung des Formats

Nachdem das Layout feststeht, muss das Format erzeugt werden. F¨

ur die Generierung eines

druckbaren DIN A4 Formats bietet sich entweder der Einsatz von Latex oder Formating

Objects an. F¨

ur dieses Beispiel fiele die Wahl auf die Formating Objects, weil es sich hierbei

um ein modernes Verfahren zur Texterzeugung handelt.

Formatierbare Kurse bestehen in der Regel aus Bausteinen oder anderen verschachtel-

ten Kursen (vgl. Abschnitt 5.3). Damit Kurse auf das Ausgabeformat abgebildet werden

k¨

onnen, muss deren interne Struktur, bestehend aus Organisationen und verschachtel-

ten Item-Elementen, rekursiv traversiert werden. Dieses Beispiel stellt einen Transformer

164 KAPITEL 7. BEISPIELE

vor, der auf der Extended Stylesheet Language XSL basiert. F¨

ur den Kurs und den Bau-

stein existieren separate ¨

Ubersetzungsregeln, die im Folgenden genauer er¨

ortert werden.

Der grundlegende Aufbau des Zielformats wird mit dem Auftreten des organization-

Elements in der ersten Zeile ausgef¨

uhrt. Dies hat zur Folge, dass die eingeschlossenen

Elemente mit dem Namensraum fo: in die Ausgabe geschrieben werden. Die Variablen

f¨

ur die Gestaltung des Dokuments werden durch das Layout-Dokument definiert. Der

zweite Teil beschreibt den Aufbau einer Seite und verarbeitet rekursiv die auftretenden

item-Elemente (vgl. Zeile 33).

Listing 7.3: XSL:FO-Dokument f¨

ur einen PDF-Kurs

1<xsl:template match=”organization”>

<fo:root>

<fo:layout−master−set>

4<fo:simple−page−master master−name=”simple”>

<xsl:attribute name=”page−height”>

<xsl:value−of select=”$pageheight” /></xsl:attribute>

7<xsl:attribute name=”page−width”>

<xsl:value−of select=”$pagewidth” /></xsl:attribute>

<xsl:attribute name=”margin−top”>

10<xsl:value−of select=”$margintop” /></xsl:attribute>

...

<fo:region−body margin−top=”1.5cm” margin−bottom=”1.5cm”

13column−count=”2” column−gap=”0.9cm”>

<xsl:attribute name=”background−color”>

<xsl:value−of select=”$background” />

16</xsl:attribute>

</fo:region−body>

<fo:region−before extent=”1.5cm”/>

19<fo:region−after extent=”1.5cm”/>

<fo:region−start/>

<fo:region−end/>

22</fo:simple−page−master>

</fo:layout−master−set>

25<fo:page−sequence master−reference=”simple”>

<fo:static−content flow−name=”xsl−region−before”>

<fo:block text−align=”end” font−size=”8pt”

28font−family=”serif” color=”red”>

Seite <fo:page−number/> </fo:block>

</fo:static−content>

31<fo:flow flow−name=”xsl−region−body”>

<xsl:apply−templates select=”item” />

</fo:flow>

34</fo:page−sequence>

</fo:root>

</xsl:template>

7.3. EXEMPLARISCHE ENTWICKLUNG EINES FORMATS ZUR

PR¨

ASENTATION 165

Bei der Verarbeitung von item-Elementen trifft der ¨

Ubersetzer auf Referenzen, die auf

Dokumente innerhalb der Bausteine verweisen. F¨

ur deren ¨

Ubersetzung wird ein weiterer

Transformer ben¨

otigt, der die Regeln f¨

ur die Dokumentstruktur definiert. Listing 7.4 zeigt

die Regel f¨

ur die ¨

Ubersetzung einer Liste. Auch hier werden wieder die mit fo: gekenn-

zeichneten Elemente in die Ausgabe geschrieben und die mit xsl: definierten Elemente

ausgef¨

uhrt. Zeile drei und vier zeigen die Wertzuweisungen zweier Variablen, die innerhalb

der ¨

Ubersetzungsregel f¨

ur Aufz¨

ahlungen ausgef¨

uhrt werden. Als Vorlage f¨

ur diese Einstel-

lungen dient die Layout-Datei, in der die Bezeichner dieser beiden Variablen referenziert

werden. Hierdurch wird w¨

ahrend der ¨

Ubersetzung die eindeutige Zuordnung hergestellt.

Listing 7.4: XSL:FO-Liste f¨

ur einen PDF-Kurs

<xsl:template match=”item”>

3<xsl:variable name=”listitemspace”>6</xsl:variable>

<xsl:variable name=”itemlabelindent”>5</xsl:variable>

6<fo:list −item>

<xsl:attribute name=”space−after.optimum”>

<xsl:value−of select=”concat($listitemspace,’pt’)”/>

9</xsl:attribute>

<fo:list −item−label>

<fo:block>

12<xsl:attribute name=” start−indent”>

<xsl:value−of select=”concat($itemlabelindent,’pt’)”/>

</xsl:attribute>

15<xsl:if test=”name(..)=’itemize’”>•</xsl:if>

<xsl:if test=”not(name(..)=’itemize’)”>

<xsl:number level=”multiple” format=”1”/>

18</xsl:if>

</fo:block>

</ fo:list −item−label>

21<fo:list −item−body start−indent=”25pt”>

<fo:block><xsl:apply−templates /></fo:block>

</ fo:list −item−body>

24</ fo:list −item>

</xsl:template>

Wird nun der Wert der Layout-Datei mit dem Lyssa-Designer modifiziert, entsteht

eine neue Layout-Vorlage und das Ergebnis wird, entsprechend der vollzogenen ¨

Anderung,

angepasst. Abbildung 7.11 zeigt einen Dialog zum Einstellen der Dokumenteigenschaften,

in der die drei Variablen pageheight,pagewidth und margintop wiederzufinden sind. Das

zweite Einstellungsfenster zeigt variable Regeln f¨

ur die Generierung der Aufz¨

ahlung.

166 KAPITEL 7. BEISPIELE

Mit diesem Verfahren lassen sich jetzt, aus Sicht der Rolle Formatentwickler/-in, ver-

schiedene Formate definieren, die sich unterschiedlich komplex konfigurieren lassen. Durch

das Hinzuf¨

ugen weiterer Variablen k¨

onnen z. B. Grafiken, Abst¨

ande und Farben frei ska-

liert werden.

Abbildung 7.11: Screenshot des Lyssa-Designers

Abbildung 7.12 zeigt das Ergebnis als PDF-Dokument, dass aus dem Formating-

Objects-Dokument generiert wurde. Es handelt sich hierbei um ein zweispaltiges Skript

f¨

ur die Technische Informatik.

7.4 Ausgew¨

ahlte Bausteine

Das letze Beispiel zeigt Bausteine, die im Rahmen des mαth-kit Projekts entwickelt wur-

den und fach¨

ubergreifend in Kursen eingesetzt werden k¨

onnen. Auch der in diesem Kapitel

entwickelte Kurs Technische Informatik (vgl. Abschnitt 7.1.3) kann mit diesen Bausteinen

angereichert werden, um verschiedenen Lernparadigmen (vgl. Abschnitt 2.2.2) gerecht zu

werden [Bauch04a,Bauch04b]. Die hier vorgestellten Bausteine folgen dem behaviouris-

tischem oder konstruktivistischem Lernparadigma, indem sie entweder Aufgaben nach dem

Multiple-Choice-Verfahren abfragen und Lernende durch direktes Feedback die Anzahl ge-

l¨

oster Aufgaben mitteilen oder Aufgaben zur individuellen Konstruktion anbieten, bei dem

Lernende durch Ausprobieren Erfahrungen sammeln und dadurch Verfahren verstehen ler-

nen.

F¨

ur die Explorationsumgebung Technische Informatik wurden zwei Applets im Kon-

text Kodierungsverfahren angefertigt. Das Applet erm¨

oglicht Studierenden, das Verfahren

der Huffman-Kodierung zu erlernen, indem sie zun¨

achst f¨

ur einen frei w¨

ahlbaren Eingabe-

text die Wahrscheinlichkeitstabelle aufstellen m¨

ussen. Das Applet ¨

uberpr¨

uft die Eingabe

7.4. AUSGEW¨

AHLTE BAUSTEINE 167

Abbildung 7.12: Der Kurs Technische Informatik als PDF-Dokument

der Wahrscheinlichkeitswerte und weist auf falsche Werte hin. Die Wahrscheinlichkeitsta-

belle ist in Abbildung 7.13 zu sehen. Wurde die Eingabe optimal durchgef¨

uhrt, gelangt

168 KAPITEL 7. BEISPIELE

Abbildung 7.13: Wahrscheinlichkeitstabelle des Bausteins Kodierungsverfahren nach Huff-

man

Abbildung 7.14: Konstruktionsbreich des Bausteins Kondierungsverfahren nach Huffman

der bzw. die Lernende in den Konstruktionsbereich, in dem der Huffman-Baum individu-

ell aufgebaut werden kann. Freilich l¨

aßt sich nicht immer die optimale L¨

osung finden, das

Applet weist jedoch auf eine solche hin und erm¨

oglicht danach einen neuen Versuch (vgl.

7.4. AUSGEW¨

AHLTE BAUSTEINE 169

Abbildung 7.14). Nachdem der Baum erstellt wurde, findet eine Auswertung statt, bei

der die konstruierte L¨

osung in Relation zu der Eingabe ausgewertet wird (vgl. Abbildung

7.15).

Abbildung 7.15: Auswertungsbereich des Bausteins Kondierungsverfahren nach Huffman

Ein weiterer Baustein erm¨

oglicht die Umwandlung von Zahlen unterschiedlicher Basen.

Studierende denken sich eine Zahl aus, die sie mit den Verfahren Umwandlung ¨

uber Po-

tenztabellen,Divisions-Rest-Verfahren oder dem Horner Schema von einem Zahlensystem

in ein anderes umwandeln k¨

onnen. Abbildung 7.16 zeigt die Umwandlung der Dezimalzahl

123, in das Dualsystem. Es k¨

onnen beliebige Eintr¨

age aus der Potenztabelle ausgew¨

ahlt

werden, die dann von der Zahl im Quellsystem subtrahiert werden.

Eine weitere Interaktionsform f¨

ur eine Explorationsumgebung ist der Baustein Quizzes

f¨

ur Komplexe Zahlen. Studierende k¨

onnen die zuvor erlernten Rechenregeln f¨

ur Komple-

xe Zahlen anhand einer Quiz-Umgebung pr¨

ufen und erkennen, ob sie die Regeln richtig

anwenden k¨

onnen (vgl. Abbildung 7.17).

Zudem existiert der, an der Universit¨

at Paderborn entwickelte, Baustein ¨

Uberlage-

rung zweier harmonischer Schwingungen mit dem Studierende das ¨

Uberlagerungsverhalten

zweier harmonischer Schwingungen mit unterschiedlicher Amplitude experimentell erler-

nen. Abbildung 7.18 zeigt das, auf Geonext [Geo05] basierende Applet, mit dem Studie-

rende interaktiv zwei rotierende Zeiger bewegen k¨

onnen. Die resultierende Schwingung

wird dann in das Applet gezeichnet, wodurch der Zusammenhang beider Schwingungen

verdeutlicht wird.

Abschließend wird ein weiterer Baustein der Explorationsumgebung Komplexe Zahlen

vorgestellt, der ebenfalls an der Universit¨

at Paderborn entstanden ist. Mit dem Baustein

Rechnen mit komplexen Zahlen k¨

onnen zwei komplexe Zahlen definiert werden, die in

170 KAPITEL 7. BEISPIELE

Abbildung 7.16: Baustein zur Zahlenumwandlung

Abbildung 7.17: Baustein Quiz-Umgebung Komplexe Zahlen

7.4. AUSGEW¨

AHLTE BAUSTEINE 171

Abbildung 7.18: ¨

Uberlagerung zweier harmonischer Schwingungen

Abbildung 7.19: Rechnen mit komplexen Zahlen (Kartesische Koordinaten)

172 KAPITEL 7. BEISPIELE

einem kartesischen Koordinatensystem dargestellt werden (vgl. Abbildung 7.19). Studie-

rende k¨

onnen verschiedene Rechenoperationen ausw¨

ahlen, wodurch die resultierende kom-

plexe Zahl in das Applet eingezeichnet wird. Durch interaktives Einwirken k¨

onnen Stu-

dierende die eingezeichneten Werte manipulieren, so dass die anderen sich, entsprechend

der ausgew¨

ahlten Operation, neu positionieren. Mit diesem Baustein erlernen Studierende

konstruktivistisch die Grundlagen f¨

ur das Rechnen mit komplexen Zahlen.

Teil III

Analyse

173

Kapitel 8

Zusammenfassung

Ziel dieser Arbeit war die Entwicklung eines technischen Modells zur Konstruktion modu-

larer und wiederverwendbarer Lerneinheiten, die speziell f¨

ur den interdisziplin¨

aren Einsatz

nutzbar sein sollten. Hierf¨

ur war die Entwicklung eines abstrakten Modells notwendig, das

neben der strukturellen Kopplung von Lerneinheiten auch deren inhaltliche Kompatibilit¨

und Integrit¨

at unterst¨

utzt. Um dieses Ziel zu erreichen, wurden in Kapitel 2 zun¨

achst die

Begriffe Multimediales Lernen und E-Learning definiert, denn diese dienten als Grundlage

f¨

ur die nachfolgenden Abhandlungen. Ebenso war die Darlegung lerntheoretischer Grund-

lagen f¨

ur die Modellierung von Kursmaterialien ¨

außerst wichtig. Hierzu geh¨

ort der Lern-

prozess des Menschen, der chronologisch vom Anf¨

anger mit wenig Erfahrung Schritt f¨

Schritt zum Experten avanciert. Das Fortschreiten zu der n¨

achst h¨

oheren Fertigkeitsstu-

fe wird durch unterschiedliche Methoden, den Lernparadigmen, erreicht. In dieser Arbeit

wurden die Paradigmen Behaviourismus,Kognitivismus und Konstruktivismus eingef¨

uhrt.

Des weiteren wurden wichtige Standardisierungen aus dem E-Learning-Bereich vorgestellt,

deren Prinzipien bei der Entwicklung des Modell ber¨

ucksichtigt wurden. Hierzu geh¨

oren

vor allem die folgenden Standards: ADL-SCORM,IMS Content Packaging,AICC und

LOM. Sie lieferte wichtige Erkenntnisse f¨

ur die Aggregation von Kursen und deren Kom-

patibilit¨

at. Neben diesen technischen Modellen existieren auch theoretische ¨

Uberlegungen,

die versuchen, Lernmaterialien als abstrakte Objekte zu beschreiben und deren Zusam-

menspiel zu analysieren. Es wurde vor allem der metaphorische Vergleich zu anderen Mo-

dellen, wie z. B. dem Atom-Modell, hergestellt, um die aus anderen Bereichen gewonnenen

Erfahrungen auf das E-Learning zu ¨

ubertragen.

In Kaptiel 3 fand die Analyse bereits bestehender Systeme und Verfahren statt, an

denen zurzeit geforscht und entwickelt wird. Dieses sind im industriellen Zweig Learning

Management Systeme (LMS) und Autorenwerkzeuge sowie formale Beschreibungssprachen

und Verfahren zur Wiederverwendung von Materialien im Universit¨

aren Umfeld. Die Ana-

lyse ergab jedoch, dass kein System und kein Verfahren die in dieser Arbeit geforderten

Ziele zufriedenstellend umgesetzt hat.

Als Ergebnis stellt Kapitel 5 das Modell zur Entwicklung konsistenter Lernmaterialien

vor. Bei diesem v¨

ollig neuem Ansatz wird erstmals die L¨

ucke zwischen den bestehenden

technischen Modellen, die im Wesentlichen die strukturierte Datenhaltung spezifizieren,

175

176 KAPITEL 8. ZUSAMMENFASSUNG

und den theoretischen Modellen f¨

ur Lernobjekte geschlossen. Lernobjekte werden nicht nur

in ihrer Struktur, sondern vielmehr durch ihren Inhalt spezifiziert und erm¨

oglichen somit

die echte Aggregation, wie sie durch die Metaphern gefordert wird. Das Ergebnis waren

formatierbare Lernbausteine und Kurse sowie das abstrakte Kursmodell, die eine h¨

ohere

Abstraktionsebene als bisherige Verfahren aufweisen. Diese Abstraktionsebene setzt jedoch

die Separation von Formatierungsregeln voraus. Durch Transformationspakete wurden die

f¨

ur eine spezialisierte Repr¨

asentation ben¨

otigten Regeln genau festgelegt, mit dem Ziel,

ein hohes Maß an Anpassbarkeit und Wiederverwendbarkeit zu erhalten. Diese Kriterien

sinddie grundlegende Voraussetzung f¨

ur den kooperativen Entwicklungsprozess, bei dem

keine spezialisierten Inhalte bearbeitet werden, sondern Kursfragmente auf rein abstrakter

Ebene entwickelt, aggregiert und wiederverwendet werden.

Aufbauend auf den in Kapitel 6 eingef¨

uhrten theoretischen Grundlagen, hat das Kapi-

tel Umsetzung die technische Realisierung vorgestellt. Zun¨

achst wurde das Autorensystem

Lyssa pr¨

asentiert, welches als Referenzimplementierung aus dem Projekt mαth-kit her-

vorgegangen ist. In Relation zu dem Kursmodell wurden die jeweiligen Funktionalit¨

aten

des Systems nacheinander beschrieben und deren Umsetzung diskutiert. Das Augenmerk

hat sich vor allem auf die Kernfunktionalit¨

at, auf die sich das Kursmodell bezieht, gerich-

tet. Aufgrund der verschiedenen Forschungsaspekte und der Funktionsvielfalt des Systems,

wurden lediglich die f¨

ur diese Arbeit relevanten Aspekte beleuchtet. Dieses sind vor al-

lem die formatierbaren Bausteine und Kurse, die Abbildung bestehender Formate sowie

die Kurstransformation in Fremdformate. Dieses Kapitel hat insbesondere die technische

Realisierbarkeit des theoretischen Modells verdeutlicht und hat zudem einen m¨

oglichen

Realisierungsansatz vorgestellt. Zu dem Autorenwerkzeug wurde ein weiteres Werkzeug

konzipiert, mit dem sich Transformationspakete entwickeln und modifizieren lassen. Ex-

perten und Expertinnen wird hierdurch sowohl die Entwicklung neuer Pr¨

asentationsfor-

men als auch die einfache Modifikation vorab definierter Layoutmerkmale erm¨

oglicht. Der

letzte Abschnitt hat die technische Umsetzung des CKS gezeigt, der die Verwaltung von

Lernbausteinen in einem kooperativen Arbeitsumfeld unterst¨

utzt. Dieser Server wurde als

Web-Applikation realisiert und kann wahlweise ¨

uber einen Web-Zugang oder durch die

direkte Einbindung in das Autorensystem eingesetzt werden.

Kapitel 7 hat exemplarisch die Entwicklung eines Kurses zum Thema Technische In-

formatik demonstriert. Ziel war es, die Leitidee des Modells zu vermitteln und dessen

praktische Realisierung zu verdeutlichen. Entwickler und Entwicklerinnen von Online-

kursen sind nun in der Lage, Lernbausteine zu entwickeln und mit anderen Bausteinen

wiederholt zu aggregieren und disaggregieren. Zur Veranschaulichung dieser neuartigen

Entwicklungsphilosophie wurde das Thema Komplexe Zahlen modular aufbereitet und

abstrakt formuliert.

8.1 Evaluation

Ein Teil der wissenschaftlichen Arbeit ist die Evaluation der erzielten Ergebnisse. Gewiss

lassen sich bei der Definition einer neuen Formel oder eines physikalischen Experiments

8.1. EVALUATION 177

die Ergebnisse beweisen bzw. auf ihre Richtigkeit hin untersuchen. In dieser Arbeit soll auf

eine solche Untersuchung nicht verzichtet werden, allerdings sind die Ansatzpunkte nicht

so klar ersichtlich, wie zuvor beschrieben. In dieser Arbeit wurde f¨

ur die L¨

osung eines

Problems ein technisches Modell entwickelt, mit dem es m¨

oglich ist, konsistente Lernma-

terialien zu produzieren. Um zu beweisen, dass das Modell praxistauglich ist, wurde daher

ein Prototyp entwickelt, der das Modell als Referenzimplementierung umsetzt. Die reine

Umsetzung reicht jedoch als Beweis zur L¨

osung des Problems nicht aus. Vielmehr m¨

ussen

Untersuchungen durchgef¨

uhrt werden, wie sich das Modell bei dem Zusammenspiel meh-

rerer Autoren und Autorinnen verh¨

alt, und ob das zugrunde liegende Konzept ¨

uberhaupt

akzeptiert wird, denn es wurde bereits mehrmals darauf hingewiesen, dass modulare Kon-

struktionskonzepte einen h¨

oheren Einarbeitungsaufwand verursachen. Aus diesem Grund

soll nun das Testumfeld erl¨

autert werden.

Der Prototyp Lyssa wurde im Projektverlauf an den vier Standorten Paderborn,

Hamburg, Hagen und Bayreuth ausgiebig getestet. Bei dem Test handelte es sich um

einen Funktionstest, der zum Auffinden von Fehlern diente und zudem die Anwendbar-

keit durch verschiedene Benutzer und Benutzerinnen untersuchen sollte. Durch st¨

andige

Autor-Kritiker-Zyklen [Z¨

ullighoven98] wurden immer wieder von Seiten der Anwender

und Anwenderinnen Verbesserungsvorschl¨

age eingebracht. Ein Beispiel hierf¨

ur ist die Zu-

sammenlegung des ¨

Ubersetzers und des Baukastens in einen Prozessraum, wodurch das

Ubersetzungsrahmenwerk entstanden ist. Des weiteren wurden zahlreiche Anregungen f¨

die Erweiterung des Sprachumfangs von BrickML gegeben, die daraufhin umgesetzt und

aufs Neue getestet wurden. Insgesamt wurde der Prototyp von 19 Personen ausgiebig ge-

testet. Davon waren 5 Personen in Paderborn, 4 in Hagen, 8 in Hamburg und zwei an der

Hochschule in Bayreuth beteiligt. Des weiteren wurde w¨

ahrend des F¨

orderzeitraums eine

Testversion des Prototypen auf der Projekt-Homepage1bereitgestellt, die sich Benutzer

und Benutzerinnen bei n¨

aherem Interesse herunterladen konnten. ¨

Uber einen Registrie-

rungsdialog wurden einhundert Personen registriert, die ebenso Anregungen zur aktuellen

Version zuschickten. Insgesamt wurde das neue Konzept gut angenommen und Lerninhal-

te fach¨

ubergreifend entwickelt. Die Resultate sind ebenfalls auf der Projekt-Homepage zu

finden und zeigen Online-Pr¨

asentationen ¨

ubersetzter formatierbarer Kurse.

1www.math-kit.de/download (29.10.2005)

178 KAPITEL 8. ZUSAMMENFASSUNG

Kapitel 9

Bewertung

Die vorliegende Dissertation schl¨

agt ein technisches Modell vor, anhand dessen sich Auto-

rensysteme entwickeln lassen, die modulare und wiederverwendbare Kurse erzeugen. Der

Stand der Forschung und Technik, der in Kapitel 2 und 3 dargelegt wurde, zeigt, dass

es sowohl theoretische als auch praktische L¨

osungen gibt, die allerdings die eingehende

Fragestellung aus Kapitel 1 nicht umfassend beantworten. Diese Arbeit schl¨

agt erstmals

eine Br¨

ucke zwischen der Theorie von Lernobjekten und deren technische Umsetzung und

stellt L¨

osungen f¨

ur die auftretenden Probleme bez¨

uglich der Granularit¨

at, Modularit¨

und Kompatibilit¨

at vor.

Ein Ziel dieser Arbeit war die Sensibilisierung f¨

ur die Probleme, die bei der techni-

schen Aggregation von Lernobjekten auftreten. Sie wird dadurch erreicht, dass Entwickler

und Entwicklerinnen sich von der Vorstellung einer konkreten technischen Umsetzung di-

stanzieren und technische Lernobjekte vielmehr als ein abstraktes Objekt ansehen, das

auf eben diesem Niveau Operationen und Schnittstellen anbietet. Durch diese Art der ab-

strakten Modellierung und die zugeh¨

orige technische Umsetzung werden, die am Anfang

der Arbeit aufgeworfenen Probleme vollst¨

andig gel¨

ost. Die Entwicklung des Prototypen

und der praktische Einsatz haben gezeigt, dass sich das Konzept in der Praxis bew¨

ahrt,

weil Anwender und Anwenderinnen den Mehrwert erkennen und ihn bei der Modellierung

aufgreifen (vgl. Abschnitt 8.1).

Abschließend findet eine verfeinerte Bewertung der Ergebnisse in Bezug auf die in Ka-

pitel 1 definierte Problembeschreibung statt. Hierzu werden die in Tabelle 2.1 formulierten

Fragestellungen separat aufgegriffen und beantwortet.

Formatierbarkeit: Das Problem der Formatierbarket wurde gel¨

ost, indem sowohl die

Struktur von Kursen als auch deren Inhalt vom Pr¨

asentationsformat getrennt wur-

den. Durch Einsatz von Transformatoren (vgl. Abschnitt 5.5) k¨

onnen abstrakt for-

mulierte Inhalte individuell adaptiert werden und Pr¨

asentationen einfach angepasst

bzw. neu entwickelt werden.

Modularit¨

at: Kompatibilit¨

at zwischen Lernbausteinen wird erreicht, indem der Aufbau

der Lerneinheit, also die Struktur, von dem eigentlichen Inhalt getrennt wird. Der

IMS Content Package Standard (vgl. Abschnitt 2.3.2) bietet hierf¨

ur bereits elegante

179

180 KAPITEL 9. BEWERTUNG

L¨

osungen an, betrachtet jedoch nicht den konkreten Inhalt. Das Modell schl¨

agt als

L¨

osungsansatz Bausteine vor, die formatierungsfrei definiert werden (vgl. Abschnitt

5.2), und dar¨

uber hinaus keine relevanten Informationen f¨

ur die Kursstrukturierung

enthalten. Die Aggregationsf¨

ahigkeit ergibt sich durch die Einhaltung von Regeln,

wie z. B. die Abgeschlossenheit (vgl. Abschnitt 7.1.2).

Granularit¨

at: Das Modell definiert grunds¨

atzlich keine Restriktionen bez¨

uglich der Gra-

nularit¨

at, sondern l¨

asst eine freie Skalierbarkeit von Lernbausteinen zu. Sie ist not-

wendig, da sich der Gesamtumfang einer Lerneinheit zum Zeitpunkt der Entwicklung

nicht absch¨

atzen l¨

asst. Aufgrund der rekursiven Definition von Lernbausteinen k¨

on-

nen sie schlichtweg zu jedem Zeitpunkt aggregiert bzw. dissaggregiert werden.

Interdisziplinarit¨

at: Das Ziel, Lernmodule interdisziplin¨

ar einsetzen zu k¨

onnen, d. h.

uber Fachgrenzen hinaus, ist vor allem durch die thematische N¨

ahe der naturwis-

senschaftlichen F¨

acher innerhalb des mαth-kit Projekts bedingt. Die Fragen nach

Modularit¨

at und Formatierbarkeit sind wichtige Voraussetzungen zur L¨

osung die-

ser Fragestellung und tragen einen erheblichen Anteil dazu bei, denn das technische

Modell bietet erst hiermit die Rahmenbedingungen, um Lerneinheiten aus anderen

Fachdom¨

anen auseinander zu nehmen, relevante Teile aufzugreifen und diese wieder

zu verarbeiten. Im Projekt mαth-kit sind Lernbausteine entwickelt worden, die in

den Disziplinen Mathematik, Informatik, und Maschinenbau wiederverwendet wur-

den (vgl. Abschnitt 7.1.3).

Nachhaltigkeit: Die mit dem Modell erzeugten Lerninhalte lassen sich zu jedem Zeit-

punkt in ein neues Format ¨

uberf¨

uhren. Auf diese Weise kann der langfristige Erhalt

gesichert werden. Ferner lassen sich transformierte Inhalte in ein standardisiertes

Format generieren, so dass die Nachhaltigkeit ebenso gesichert ist (vgl. Abschnitt

2.3).

Integrierbarkeit: Das Problem, digitale Ressourcen f¨

ur die Entwicklung neuer Kurse

wiederzuverwenden, wurde durch das Konzept des abstrakten Kursmodells gel¨

ost.

Dieses entkoppelt funktional die modulare Erzeugung von der Verarbeitung des

Quellformats und erm¨

oglicht daher die einfache Erweiterung durch neue Interpre-

ter 1.

Kooperation: Die Evaluation (vgl. Abschnitt 8.1) hat gezeigt, dass kooperatives Arbei-

ten durch das Modell bzw. durch die Implementierung des CKS umfassend unter-

st¨

utzt wird. Verteilte Teams sind nunmehr in der Lage, gemeinsam mit dem Bauka-

sten und den enthaltenen Bausteinen zu arbeiten.

Mathematik: Mathematische Inhalte zeichnen sich vor allem durch den hohen Anteil an

Formeln und Gleichungen aus. Das Kapitel 2 hat jedoch gezeigt, dass es zur Darstel-

1Eine solche Erweiterung wurde z. B. in der Diplomarbeit Entwicklung einer Software-Komponente zur

Integration bestehender Lehr- und Lernmaterialien und deren Metadaten in das mαth-kit System untersucht

[S¨

unneli04].

181

lung ganz unterschiedliche Verfahren gibt. Hierbei hilft das Konzept der Prozessoren,

die beliebige Formatkonvertierungen durchf¨

uhren k¨

onnen.

Didaktik: Das in dieser Arbeit entwickelte Modell sieht die technische Entwicklung von

Lerneinheiten vor. Hierbei sollen jedoch keine didaktischen Aspekte modelliert wer-

den. Fragen der Didaktik besch¨

aftigen sich mit der Gestaltung, Lehrtechnik und

Vermittlung von Lerneinheiten, die bereits in der Planungsphase beantwortet wer-

den m¨

ussen (vgl. [Pawlowski02,Pawlowski01]). In dieser Phase muss entschieden

werden, welchen Lernparadigmen gefolgt wird, und welche Pr¨

asentation bzw. Ge-

staltung durch eine Transformation erzeugt wird. Das Modell muss jedoch in der

Lage sein, alle Varianten zu bedienen, was durch die Gestaltungsfreiheit bei der Ent-

wicklung von Transformationspaketen und der Verankerung verschiedener Techniken

in die Lerneinheiten zweifellos m¨

oglich ist.

182 KAPITEL 9. BEWERTUNG

Kapitel 10

Ausblick

Das grundlegende Ziel dieser Arbeit war die Entwicklung eines Modells zur orthogonalen

Definition universell einsetzbarer Lernmodule. Da es sich hierbei um einen neuen Ansatz

handelt, der zahlreiche interessante Fragestellungen aufwirft, konnten in der vorliegenden

Dissertation nicht alle Aspekte behandelt und untersucht werden. Dieses Kapitel zeigt An-

satzpunkte f¨

ur weiterf¨

uhrende Forschungsfragen, die das Modell verbessern und erweitern

sollen. Des weiteren werden Vorschl¨

age f¨

ur Weiterentwicklungen des Prototypen Lyssa

formuliert, die insbesondere die Anwendbarkeit des Systems verbessern sollen.

Die Anforderungen an die Auszeichnungssprache BrickML sind aus dem Bedarf des

mαth-kit Projekts entstanden. Die beteiligten Personen haben Vorschl¨

age und W¨

unsche

ge¨

außert, die mit in die Kernentwicklung eingeflossen sind. Dieser Fundus ist keineswegs

vollst¨

andig und kann in Zukunft immer weiter verfeinert werden, um eine m¨

oglichst große

Akzeptanz zu schaffen. Ferner k¨

onnen weitere dom¨

anenspezifische Sprachen abgeleitet wer-

den, die die Erzeugung spezialisierter Inhalte erm¨

oglicht, ohne den Basissatz der Grund-

sprache zu erweitern.

Des weiteren gibt es Ans¨

atze, Lehrinhalte an den Wissensstand von Lernenden

anzupassen. Das kann dadurch erreicht werden, indem Inhalte mit Metadaten ange-

reichert werden, die die Qualifikation bzw. das Grundwissen von Lernenden definie-

ren. Eine solche Vorbedingung erm¨

oglicht die selektive Zuordnung von Lernmodulen

durch eine Lernumgebung. Diese Methode wird im Allgemeinen als Adaptives Lernen

[Brusilovsky98,Brusilovsky01] bezeichnet und wurde bisher nicht in das Modell integriert.

Bei der Abbildung bestehender digitaler Ressourcen auf Kurse kristallisieren sich wei-

tere interessante Fragestellungen heraus. Ein Gedankenanstoß, der in dieser Arbeit be-

gr¨

undet ist, wendet Methoden des Refactorings an, die von dem Paradigma der objekt-

orientierten Programmierung abgeleitet (vgl. Abschnitt 5.4.3) sind. Die hier vorgestellten

L¨

osungen sind jedoch recht allgemein gefasst und l¨

osen die auftretenden Probleme nur im

Ansatz. Ferner kann ¨

uber Prozesse zur Nachbearbeitung nachgedacht werden, die Hinweise

auf inkonsistente Lernbausteine geben und deren ¨

Uberarbeitung anregen.

Ein ebenso interessanter Forschungsansatz bildet die Integration zeitvarianter Inhalte

in das Modell. Hiermit ist insbesondere die zeitliche Ver¨

anderung grafischer Objekte ge-

meint, die z. B. durch den SMIL-Standard [Consortium05] spezifiziert wird. In Abschnitt

183

184 KAPITEL 10. AUSBLICK

3.4 wurde bereits darauf hingewiesen, dass Autorenwerkzeuge in dokumentbasierte und

programmbasierte Systeme aufgeteilt werden. Bisher waren lediglich Komponenten inner-

halb der Bausteine interaktiv steuerbar. Wie s¨

ahe jedoch ein Modell aus, bei dem der

Baustein interaktiv ver¨

andert werden kann und dessen Zustand sich zeitlich ¨

andert? Die-

ses Modell k¨

onnte die bestehende L¨

ucke zwischen programmbestimmten und dokumentbe-

stimmten Werkzeugen schließen und die Kompatibilit¨

at von Inhalten durch entsprechende

Schnittstellen erh¨

ohen.

Als letztes wird das Autorensystem Lyssa betrachtet. Der Prototyp Lyssa verf¨

ugt zur-

zeit ¨

uber eine Bausteinansicht, in der Inhalte direkt in XML gesetzt werden. Unterst¨

utzt

wird dieser Prozess durch einen XML-Editor, der je nach Vorlieben des Anwenders bzw.

der Anwenderin, ausgew¨

ahlt werden kann. Eine sinnvolle Erweiterung des Prototypen

w¨

urde darin bestehen, von der technischen Ansicht zu abstrahieren und einen Editor zu

entwickeln, der kein technisches Grundwissen voraussetzt. Diese Maßnahme w¨

urde die

Benutzbarkeit und damit den Zugang zu dem Prototypen vereinfachen.

Teil IV

Anlagen

185

Anhang A

Abk¨

urzungsverzeichnis

ADL – Advanced Distributed Learning Initiative

AICC – Aviation Industry Computer Based Training Commit-

tee

ANSI – American National Standards Institute

ARIADNE – Aliance of Remote Instructional Authoring and Disti-

bution Networks for Europe

CAM – Content Aggregation Model

CBT – Computer Based Training

CP – Content Package

CKS – Construction Kit Server

CMI – Computer Manage Instruction Systems

DTD – Data Type Definition

GUI – Graphical User Interface

EML – Educational Markup Language

FB – Formatierbarer Baustein

FK – Formatierbarer Kurs

FO – Formating Objects

FOP – Formating Objects Processor

FTP – File Transfer Protocol

HTML – Hypertext Markup Language

HTTP – Hypertext Transfer Protocol

ISO – International Organization for Standardization

IEEE – Institute of Electrical and Electronics Engineers

IMS – Instructional Management System

JDOM – Java Document Object Model

n¨

achste Seite

187

188 ANHANG A. ABK¨

URZUNGSVERZEICHNIS

KPS – Knowlage Pool System

LCMS – Learning Content Management System

LMS – Learning Management System

LO – Learning Object

LOM – Learning Object Metadata

LMML – Learning Material Markup Language

LTSC – Learning Technology Standard Committee

MDI – Multiple Device Interface

MSC – Mupad Computing Server

OOP – Object Oriented Programming

PIF – Package Interchange File

SCO – Sharable Content Object

SCORM – Sharable Content Object Reference Model

SGML – Standard Generalized Markup Language

TP – Transformationspaket

UML – Unified Modelling Language

W3C – World Wide Web Consortium

WBT – Web Based Training

WWW – World Wide Web

XML – Extensabile Markup Language

XSD – extended Stylesheet

XSL – extendable Stylesheet Language

Anhang B

Glossar

ADL: ADL ist eine Initiative des amerikanischen Verteidigungsministerium zur Standar-

disierung von Lerneinheiten.

AICC: Das AICC ist ein internationaler Zusammenschluss von Herstellern computerba-

sierter Lerneinheiten. Ziel ist die Verabschiedung von Standardisierungen im Bereich

Lernobjekte.

ARIADNE: Die Aliance of Remote Instructional Authoring and Distibution Networks

for Europe (ARIADNE) ist ein EU-Projekt mir der Zielsetzung, Werkzeuge und Me-

thoden zur Produktion, Verwaltung und Wiederverwendung von rechnergest¨

utzten

und p¨

adagogischen Lerneinheiten sowie f¨

ur die Erstellung von Curricula zu ent-

wickeln. Hierbei wurde maßgeblich an der Spezifikation des LOM Standards mitge-

wirkt und kulturelle Aspekte eingebracht.

Asset: Asstes, wie z.B. Bilder, Videos oder Applets, sind physikalische Dateien, aus denen

eine Lerneinheit zusammengesetzt ist.

CP: Das Content Package wurde urspr¨

unglich vom IMS Consortium verabschiedet und

ist in den SCORM Standard aufgenommen worden. Es enth¨

alt das Manifest mit den

Metadaten sowie die zugeh¨

origen Assets.

DTD: Die Documenttyp-Definition (DTD) dient zur Definition eines Dokumentenmo-

dells. Mit ihr lassen sich semantische Abh¨

angigkeiten in XML Dokumenten formu-

lieren.

FB: Ein formatierbarer Baustein (FB) besteht aus einem generellen, darstellungsfreien

Dokument beliebiger Granularit¨

at zur strukturierten Speicherung des Inhalts und

wird erst in Verbindung mit einem Regelwerk f¨

ur ein beliebiges Pr¨

asentationsformat

zu einem Lernobjekt. Formatierbare Bausteine besitzen einen definierten Rahmen,

der die Aggregation mit anderen formatierbaren Bausteinen erm¨

oglicht.

FK: Ein formatierbarer Kurs (FK) besteht aus mindestens einem formatierbaren Bau-

stein und einer beliebigen Anzahl Assets und definiert deren Organisation. Erst in

189

190 ANHANG B. GLOSSAR

Verbindung mit einem Regelwerk f¨

ur ein beliebiges Pr¨

asentationsformat entsteht ei-

ne einsetzbare Kurseinheit. Formatierbare Kurse besitzen einen definierten Rahmen,

der die Aggregation mit anderen formatierbaren Kursen erm¨

oglicht.

IEEE-LTSC: Das LTSC (Learning Technology Standard Committee) entwickelt Richt-

linien zur Standardisierung im Bereich webbasierter Lern- und Lehrsysteme.

LT: Anhand des Layout-Typs wird entschieden, wie ein Wert zur Layout-Manipulation

vom Lyssa-Designer angezeigt wird. Die Einstellung eines Farbwerts ist z. B. an einen

Auswahldialog f¨

ur Farben gekoppelt und Zahlenwerte an eine Textbox.

Learning Management System: Unter einer webbasierten Lernplattform ist eine ser-

verseitig installierte Software zu verstehen, die beliebige Lehrinhalte ¨

uber das Inter-

net vermittelt und die Organisation der dabei notwendigen Lernprozesse unterst¨

utzt

([Baumgartner02], Seite 14).

Lernobjekt: Learning Objects bestehen in der Regel aus einer Menge an Informations-

einheiten oder Datenobjekten, wie z.B Text, Videos oder Programmen. Aus ihnen

k¨

onnen durch Aggregation oder Komposition verschiedene Kurse zusammengestellt

werden, die wiederum selbst zu kompletten Lehrg¨

angen kombiniert werden k¨

onnen

( Baumgartner [Baumgartner02], Seite 33).

Manifest: Das Manifest ist Bestandteil des Content Package und b¨

undelt strukturelle

Kursinformationen, wie z.B. Metadaten oder den hierachischen Aufbau der Kapitel.

Metadaten: Metadaten sind Daten ¨

uber andere Daten. Im Fall des SCORM-Standards

und der IMS-Content Package Spezifikation werden sie, nach dem LOM-Standard,

in XML kodiert. Sie helfen beim Auffinden von Kursinhalten in Repositories und

beim Einstellen einer Lerneinheit.

SCO: Ein SCO (Sharable Content Object) ist eine austauschbare Lehreinheit, die in ver-

schiedenen Kontexten integriert werden kann. Damit diese Vorderung eingehalten

wird, d¨

urfen keine Referenzen auf andere Lerneinheiten vorhanden sein.

SGML: SGML ist ein allgemeiner Standard zur Definition von Auszeichnungssprachen

(Markup Sprachen) und ist der Vorl¨

aufer von XML. Mit SGML k¨

onnen Dokumente

unabh¨

angig von ihrer Darstellung strukturell gespeichert werden.

TP: Ein Transformationspaket kapselt die f¨

ur die ¨

Ubersetzung notwendigen Dateien und

stellt somit einen flexiblen und modularen Mechanismus zur Erzeugung unterschied-

licher Ausgabeformate dar. Transformationspakete werden im Zusammenhang mit

formatierbaren Kursen eingesetzt um Lernobjekte zu erzeugen.

Workbench: Der Zugriff auf Dateiressourcen erfolgt bei dem Autorensystem Lyssa ¨

uber

die Workbench. Von dort aus k¨

onnen sie, per Drag’n’Drop, mit Bausteinen oder

Kursfenstern, ausgetauscht werden.

191

XML: die extensabile Markup Language ist der Nachfolger von SGML und wird zur

darstellungsunabh¨

angigen Beschreibung von Dokumenten verwendet. Im Gegensatz

zu SGML wird ein reduzierter Sprachumfang eingesetzt, der die Implementierung

von Parsern vereinfacht.

XML-Schema: Hierbei handelt es sich um ein auf XML basierendes Dokumentenmodell,

welches es ¨

ahnlich wie die DTD erm¨

oglicht, die Grammatik der Sprache zu definieren.

192 ANHANG B. GLOSSAR

Anhang C

Attribute

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

1Manifest Kontainer f¨

ur Transformatoren und

Anwendungen

B Container

1.1 desc Kurszbeschreibung des Transformati-

onspakets

B String

1.2 identifierRef Verweist auf die Icon-Datei B String

1.3 archive Gibt an, ob das Ergebnis in einem kom-

primierten Archiv vorliegt

O Boolean

1.4 ext Gibt das Archivsuffix an O String

1.5 starthref Verweist auf die Start-Datei des ¨

uber-

setzten Kurses

B String

1.6 transformers Kontainer f¨

ur Transformatoren B Container

1.6.2 transformer Kontainer f¨

ur Transformatoren und

Anwendungen

B Container

1.6.2.1 name Name des Transformators B String

1.6.2.2 type Typ des Transformators B String

1.6.2.3 ext Gibt das Suffix f¨

ur die Zieldateiena an B String

1.6.2.4 id Id des Transformators B String

1.6.2.5 identifierRef Verweist auf die Quellen f¨

ur den Tran-

formator

B String

1.6.2.5 srcRef Verweist auf zu transformierende Re-

sourcen

O String

1.6.2.6 prozessor Definiert einen Prozessor f¨

ur einen

Transformator

O Container

1.6.2.6.1 identifierRef Verweist auf die Resourcen des Prozes-

sor

B String

n¨

achste Seite

193

194 ANHANG C. ATTRIBUTE

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

1.6.2.6.2 active Aktiviert den Prozessor B Boolean

1.6.2.6.3 order Bestimmt die Reihenfolge der Prozes-

soren

O Integer

1.7 tasks Kontainer f¨

ur Anwendungen B Container

1.7.1 task Liste aller Anwendung O Container

1.7.1.1 type Definiert den Zeitpunkt, an dem die

Anwendung ausgef¨

uhrt wird

B String

1.7.1.2 lang Programmiersprache B String

1.7.1.3 class Definiert die zu startende Klasse B String

1.7.1.4 identifierRef Referenziert die Resource f¨

ur die aus-

f¨

uhrbare Datei

B String

1.8 sceme Kontainer f¨

u Schema-Dateien O Container

1.8.1 identifierRef Referenziert die Resource der Schema-

Datei

O String

1.9 layout Beschreibt das Layout des Transforma-

tionspakets

B String

1.9.1 identifierRef Referenziert die Resource des Layouts O String

1.10 resources Gibt die Liste der Resourcen an B Container

1.10.1 resource Definiert eine Resourcen an B Container

1.10.1.1 file Definiert eine Datei innerhalb einer Re-

source

B String

1.10.1.2 href Verweis auf die Datei B String

1.10.2 identifier Setzt die Id mit der die Resource an-

gesprochen wird

B String

Tabelle C.1: Attribute und Elemente des Transformationspakets

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

1Course Kontainer f¨

ur Lektionen B Container

1.1 Metadaten LOM Metadaten f¨

ur den Kurs O Container

1.2 Lesson LOM Metadaten f¨

ur den Kurs O Container

1.2.1 courseObject Gibt an, ob es sich um einen Subkurs

handelt

B Booelean

1.2.2 titel Enth¨

alt den Titel einer Lektion B String

1.2.3 Metadaten LOM Metadaten f¨

ur die Lektion O Container

1.2.4 Lesson Unterlektion mit den gleichen Eigen-

schaften aus 1.2

O Container

n¨

achste Seite

195

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

1.2.5 Paragraph Definiert einen Absatz O Container

1.2.6 Table Definiert einen Tabelle O Container

1.2.6.1 border Legt fest, ob eine Tabelle einen Rah-

men hat

O Integer

1.2.6.2 width Legt fest, ob eine Tabelle einen Rah-

men hat

O Decimal

1.2.6.2 Column Konfigurerit die Spalten O Container

...

1.2.8 MMO Gibt ein Mediaobjekt an O Container

1.2.8.1 href Verweist auf die zugeh¨

orige Date O String

...

Tabelle C.2: Attribute und Elemente des Kursmodells

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

1Layout Container f¨

ur Master, Properties und

Map-Elemente

B Container

2 Master Container f¨

ur Dokumentattribute B Container

2.1 Page Container f¨

ur Seitenattribute B Container

2.1.1 width Definiert die Seitenbreite B Dezimal

2.1.2 height Definiert die Seitenh¨

ohe B Dezimal

2.2 Body Container f¨

ur Seitenausrichtung B Container

2.2.1 marginleft Linker Rand B Dezimal

2.2.2 marginright Rechter Rand B Dezimal

2.2.3 margintop Oberer Rand B Dezimal

2.2.4 marginbottum Unterer Rand B Dezimal

2.2.5 columns Anzahl der Spalten B Integer

2.3 Header Container f¨

ur die Kopfzeile O Container

2.3.1 width Breite O Integer

2.3.2 height H¨

ohe O Integer

2.3.3 margintop Abstand zum oberen Rand O Integer

2.4 Footer Container f¨

ur die Fußzeile O Container

2.4.1 width Breite O Integer

2.4.2 height H¨

ohe O Integer

2.4.3 marginbottum Abstand zum unteren Rand O Integer

n¨

achste Seite

196 ANHANG C. ATTRIBUTE

Nummer Name Erkl¨

arung Ben¨

tigt

Typ

3 Styles Container f¨

ur Styles B Container

3.1 Style Definiert einen Style O Container

3.2 identifier Identifizierung O String

3.3 Property Eigenschaften O Container

3.3.1 type Layouttyp O String

3.3.2 identifier Identifizierung O String

3.3.3 desc Beschreibung O String

4 Map Container O Container

4.1 Reference Definiert das Mapping O Container

4.1.1 indentifierRef Referenzierte ID O String

4.1.2 resourceRef Referenzierte Ressource O String

Tabelle C.3: Attribute und Elemente des Layouts

Index

ADL, 19, 20, 53

AICC, 19, 28

Andendung, 101

ANSI, 20

ARIADNE, 19, 30, 189

Asset, 21, 24

Atom, 35

Authorware, 60

Autorenwerkzeuge, 58

Baustein, 72

Behaviorismus, 12, 16

BrickML, 83

CAM, 21

CBT, 11, 28

CMI, 28

Content Aggregation Model, 21

Content Packaging, 21

CP, 25

DazzlerMax, 61

DocBook, 48, 132

DTD, 43, 45, 46, 52

E-Learning, 11

EML, 53

Formatentwickler/-in, 106

Formatierbaren Bausteine, 124

Formatierbarer Baustein, 77, 84, 86–90, 92,

95, 97, 189

Formatierbarer Kurs, 87, 90, 91, 93, 95, 100,

189

Framework, 138

FTP, 27

Grafische Minimierung, 153

Granularit¨

at, 37

Heuristische Lernmodell, 17

HTML, 27, 55, 58

Huffman-Kodierung, 166

IEEE, 31

IEEE LTSC, 19

IMS, 19, 25, 53

IMS Learning Design Information Model, 55

IMS Question and Test, 25

ISO, 31

ITO, 40

Java, 47

JDOM, 47

Kognitivismus, 12, 17

Komplexe Zahlen, 149

Konstruktivismus, 12, 17

KPS, 28

Kurs, 73

Kurs-Framework, 140

Latex, 134

Layout, 105, 107

Layoutentwickler/-in, 106

Layouttyp, 141

Layouttypen, 108

LCMS, 27

Learning Object, 31

LEGO, 35

Lernobjekte, 19

Lernplattformen, 56

LMML, 51, 63

LMS, 19, 21, 56, 58

Loader, 95

197

198 INDEX

LOM, 25, 27

Lyssa, 134

Lyssa-Designer, 140

Mathkit, 3, 5

MathML, 49, 135

Metadaten, 19, 21, 27, 34

Metapher, 34

Multimedia, 10

OMDoc, 49

OpenMath, 49

OpenOffice, 40, 131

PaKMaS, 63

PIF, 22

Prozessor, 101

Rollen, 106

schema, 101

SCO, 24

SCORM, 20

SGML, 43

Simplified DocBook, 133

Slicing-Book-Technologie, 39

staroffice, 131

Task, 101

Technische Informatik, 149, 150

Telemedien, 11

tex4ht, 135

toolbook, 60

Transformationspaket, 101

Transformator, 46, 101–103, 105

W3C, 43

WBT, 11

Wechselstromschaltungen, 155

WWW, 11

Xalan, 136

XML, 42, 43

XML-Schemata, 46

XSD, 46, 52

XSL, 44, 47, 164

Literaturverzeichnis

[ADL04] Sharable Content Object Reference Model (SCORM).

http://www.adlnet.org/ (viewed 27.11.2004), 2004.

[AIC03] Aviation industry computer-based training committee (aicc).

http://www.aicc.org/ (viewed 02.03.2003), 2003.

[Ari05] Alliance of Remote Instructional Authoring and Distribution Net-

works for Europe. http://www.ariadne-eu.org/ (viewed 29.10.2005),

2005.

[Balzert00] Helmut Balzert: Lehrbuch der Software-Technik - 2. Auflage. Spek-

trum Akademischer Verlag, Heidelberg, Berlin, ISBN: 3-8274-0480-0,

2000.

[Bauch03] M. Bauch and L. Unger: Interactive mathematics with math-kit -

distance learning versus face-to-face learning. In: 21st ICDE World

Conference on Open Learning & Distance Education, Hong Kong,

2003.

[Bauch04a] Manfred J. Bauch, S. Hartlieb and Luise Unger: I - You - We: Tea-

ching Linear Algebra the constructivist way. In: Proceedings of ED-

MEDIA 2004–World Conference on Educational Multimedia, Hyper-

media & Telecommunications, Lugano, Switzerland, January 2004.

[Bauch04b] Manfred J. Bauch, Bianca Thiere and Luise Unger: Visualizing ma-

thematics on the web - constructivist approaches in open and distan-

ce education. In: Proceedings of the 21st ICDE World Conference on

Open Learning and Distance Education, Hong Kong, January 2004.

[Baudry02a] Andreas Baudry, Michael Bungenstock and B¨

arbel Mertsching: Ar-

chitecture of an E-Learning System with Embedded Authoring Sup-

port. In: Margaret Driscoli and Thomas C. Reeves (eds.): E-LEARN

2002 - World Conference on Educational in Corporate, World Con-

ference on E-Learning in Corporate, Government, Healthcare, &

Higher Education (E-LEARN 2002), Montreal, Canada, January

2002. pp. 110 – 116.

199

200 LITERATURVERZEICHNIS

[Baudry02b] Andreas Baudry, Michael Bungenstock and B¨

arbel Mertsching: Ein

multimediales Rahmenwerk f¨

ur die Mathematiklehre nach der Bau-

kastenmetapher. In: Klaus P. Jantke, Wolfgang S. Wittig and J¨

org

Herrmann (eds.): Von e-Learning bis e-Payment. Das Internet als

sicherer Marktplatz (LIT ’02). Infix, 2002, pp. 300–307.

[Baudry03] Andreas Baudry, Michael Bungenstock and B¨

arbel Mertsching: Nyx

- A Tool for Generating Standard Compatible E-Learning Cour-

ses with Consistent and Adaptable Presentation. In: The IASTED

International Conference on Computers and Advanced Technology

in Education (CATE 2003), ISBN: 0-88986-361-X, Rhodes, Greece,

June 2003. IASTED, pp. 265 – 269.

[Baudry04a] Andreas Baudry, Michael Bungenstock and B¨

arbel Mertsching: Ad-

ministration and Development of Modular Learning Units with the

Construction Kit Server. In: ED-MEDIA 2004, P.O. Box 3728, Nor-

folk, VA 23514-3728, June 2004. Ass. for the Advancement of Com-

puting in Education, pp. 783 – 790.

[Baudry04b] Andreas Baudry, Michael Bungenstock and B¨

arbel Mertsching: Reu-

sing Document Formats for Modular Course Development. In: IA-

STED International Conference on WEB-BASED EDUCATION

(WBE 2004), ISBN: 0-88986-377-6, Innsbruck, February 2004. AC-

TA Press, pp. 535 – 537.

[Baudry05] A. Baudry, M. Bungenstock and B. Mertsching: An e-learning sy-

stem for standard compatible and uniform course development. In:

International Journal on E-Learning (IJEL) Corporate, Govern-

ment, Healthcare, & Higher Education.

[Baumgartner95] P. Baumgartner: Information und Lernen mit Multimedia, chapter

Didaktische Anforderungen an (multimediale) Lernsoftware. BELTZ

Psychologie Verlags Union, 1995.

[Baumgartner97] P. Baumgartner and S. Payr. Erfinden lernen. Konstruktivismus

und Kognitionswissenschaft. Kulturelle Wurzeln und Ergebnisse. Zu

Ehren Heinz von Foersters, 1997. Wien-New York: Springer.

[Baumgartner99] P. Baumgartner and S. Payr: Lernen mit Software. Studienverlag

GmbH, ISBN: 3706514443, 1999.

[Baumgartner02] Peter Baumgartner, Hartmut H¨

afele and Kornelia Maier-H¨

afele:

E-Learning: Fachbegriffe, didaktische und technische Grundlagen.

Technical report, bm:bwk, 2002. Sonderheft e-Learning.

[Belqamsi02] Youssef Belqamsi: Using XML in Elearning Courses. In: Marga-

ret Driscoli and Thomas C. Reeves (eds.): E-LEARN 2002–World

LITERATURVERZEICHNIS 201

Conference on Educational in Corporate, World Conference on E-

Learning in Corporate, Government, Healthcare, & Higher Educati-

on, 2002, pp. 1183 – 1186.

[Bergstrom01] Bergstrom: CMI Guidelines for Interoperability AICC. Technical

Report Revision 3.5 release 2, Alliance of Remote Instructional Au-

thoring and Distribution Networks for Europe, AICC CMI Subcom-

mittee, 2001.

[Bla03] The Blackboard e-Education. http://www.blackboard.com/ (viewed

23.01.2003), 2003.

[Bohl02] Oliver Bohl, J¨

org Schellhhase and Udo Winand: A Critical Discus-

sion of Standards for Web-based Learning. In: Margaret Driscoli

and Thomas C. Reeves (eds.): E-LEARN 2002–World Conference

on Educational in Corporate, World Conference on E-Learning in

Corporate, Government, Healthcare, & Higher Education, 2002, pp.

850–855.

[Brusilovsky98] P. Brusilovsky, J. Eklund and Schwarz: Web-based education for all:

A tool for developing adaptive courseware. In: Computer Networks

and ISDN Systems, pp. 291–300.

[Brusilovsky01] P. Brusilovsky: adaptive hypermedia. In: User Modeling and User

Adapted Interaction, The Journal of Personalization Research.

[Bungenstock02] Michael Bungenstock, Andreas Baudry and B¨

arbel Mertsching: The

Construction Kit Metaphor for a Software Engineering Design of an

E-Learning System. In: Philip Barker and Samuel Rebelsky (eds.):

Proc. ED-MEDIA 2002 - World Conference on Educational Multi-

media, Hypermedia & Telecommunications, Denver, Colorado, USA,

January 2002. pp. 216–217.

[Bungenstock03a] Michael Bungenstock, Andreas Baudry and B¨

arbel Mertsching: Da-

tenaustausch zwischen Lyssa und Learning Management Systemen.

In: Von e-Learning bis e-Payment. Das Internet als sicherer Markt-

platz (LIT ’03), Leipzig, September 2003.

[Bungenstock03b] Michael Bungenstock, Andreas Baudry and B¨

arbel Mertsching: Lys-

sa - An Authoring System Complying with E-Learning Standards.

In: ED-MEDIA 2003 - World Conference on Educational Multime-

dia, Hypermedia & Telecommunications, Honolulu, Hawaii, USA, Ju-

ne 2003. pp. 502 – 508.

[Bungenstock04] Michael Bungenstock, Andreas Baudry and B¨

arbel Mertsching: De-

sign of a Common API for Learning Objects. In: 7th IASTED In-

ternational Conference on Computers and Advanced Technology in

202 LITERATURVERZEICHNIS

Education (CATE 2004), August 16-18, 2004, Kauai, Hawaii, USA,

ISBN: 0-88986-430-6. IASTED, August 2004, pp. 345 – 350.

[Caprotti02] O. Caprotti, D. P. Carlisle and A. M. Cohen. The OpenMath Stan-

dard, the openmath esprit consortium. http://www.openmath.org/

(viewed 29.10.2005), October 2002. 1.1b.

[Chappell03] David A. Chappell and Tyler Jewell: Java Web Services. O’Reilly,

2003. ISBN: 3897212846.

[Consortium05] World Wide Web Consortium. Synchronized Multimedia.

http://www.w3.org/AudioVideo/ (viewed 29.10.2005), 2005.

[Cuthbert02] Alex Cuthbert and Frances Himes: Creating Learning Objects with

Macromedia Dreamweaver MX. Macromedia white paper, 2002.

[Dahn01] I. Dahn: Slicing book technology - providing online support for text-

books. In: ICDE, 2001.

[Dahn02] Ingo Dahn and Gerhard Schwabe: Personalizing textbooks with sli-

cing technologies - concept, tools, architecture, collaboration use. In:

35th Annual Hawaii International Conference on System Sciences

(HICSS’02), 2002.

[Dahn05] Ingo Dahn, Michael Armbruster, Ulrich Furbach and Gerhard

Schwabe. Slicing Books - The Authors’ Perspective, 2005. http:

//citeseer.ist.psu.edu/487947.html(viewed29.10.2005).

[Daniel98] John Daniel and Russell Edgerton: Mega-Universities and Knowled-

ge Media: Technology Strategies for Higher Education. Kogan Page

Ltd, 1998.

[Downes00] S. Downes. Learning Objects. Leaders in Learning 2000, May 5

2000. University of Alberta.

[Downes04] Stephen Downes. The Learning Marketplace Meaning, Metada-

ta and Content Syndication in the Learning Object Economy.

http://www.downes.ca/, Januar 2004. Moncton, New Brunswick.

[Dreyfus86] H. L. Dreyfus, T. Anthanasiou and S. E. Dreyfus: Mind Over Ma-

chine: The Power of Human Intuition and Expertise in the Era of

the Computer. The Free Press, ISBN: 0743205510, 1986.

[Duval02] E. Duval: Learning Technology Standardization: Too Many? Too

Few? In: Workshop: Standardisierung im eLearning, Universit¨

Frankfurt/Main, April 2002.

LITERATURVERZEICHNIS 203

[Edelmann96] W. Edelmann: Lernpsychologie 5., vollst. ¨

uberarbeitete Auflage.

Beltz Psychologie-Verlags-Union, Weinheim, Basel, 1996.

[Electrical02] Institute of Electrical and Electronics Engineers Inc. Draft standard

for learning object metadata, July 2002.

[Engesser93] Hermann Engesser (ed.): Duden Informatik. Dudenverlag, 1993.

[Farinetti00] L. Farinetti, F. Bota and A. Rarau. An authoring tool for buil-

ding flexible on-line courses using XML, 2000. XML Europe 2000

Conference, Paris.

[Fielding99] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Le-

ach and T. Berners-Lee. Hypertext Transfer Protocol – HTT-

P/1.1. http://www.w3.org/Protocols/rfc2616/rfc2616.html (viewed

12.12.2002), Juni 1999.

[Finsterle02] Lutz Finsterle and Martin Rotard: Mit konventionellen Autorensy-

stemen zum E-Learning Portal. In: Klaus P. Jantke, Wolfgang S.

Wittig and J¨

org Herrmann (eds.): Von e-Learning bis e-Payment.

Das Internet als sicherer Marktplatz (LIT ’02). Infix, 2002, pp. 111–

121.

[Fowler99] Martin Fowler: Refactoring. Addison-Wesley Professional, 1999.

[Freitag02a] Burkhard Freitag, Christian S¨

uß and Claus Dziarstek: Adaptation

und Wiederverwendung von XML-basiertem eLearning-Content. In:

Sigrid E. Schubert, Bernd Reusch and Norbert Jesse (eds.): Infor-

matik bewegt: Informatik 2002 - 32. Jahrestagung der GI, 2002. LNI

19 GI.

[Freitag02b] Burkhard Freitag, Christian S¨

uß and Claus Dziarstek: LMML-Eine

XML-Sprachfamilie f¨

ur eLearning Content. In: Sigrid E. Schubert,

Bernd Reusch and Norbert Jesse (eds.): Informatik bewegt: Informa-

tik 2002 - 32. Jahrestagung der GI, 2002. LNI 19 GI.

[Frerich00] Alwin Frerich and G¨

unter Gerharz: Lernen mit Neuen Medien 2000

Software-Ratgeber f¨

ur die Sekundarstufe I/II. DruckVerlag Kettler

GmbH, Landesinstitut f¨

ur Schule und Weiterbildung, ISBN: 3-8165-

1792-7, 2000.

[F¨

unfst¨

uck00] F. F¨

unfst¨

uck, R. Liskowsky and K. Meißner: Softwarewerkzeuge zur

Entwicklung multimedialer Anwendungen. Eine ¨

Ubersicht. In: In-

formatik Spektrum, 23(1), pp. 11 – 25.

[Gamma95] Erich Gamma et al.: Design Patterns - Elements of Reusable Object-

Oriented Software. Addison Wesley, Reading, Massachusetts, 1995.

204 LITERATURVERZEICHNIS

[Geo05] Geonext - dynamische mathematiksoftware. http://geonext.uni-

bayreuth.de/ (viewed 29.10.2005), 2005.

[Gersdorf02] Ruben Gersdorf, Berit Jungmann and Eric Schoop: Chancen und

Herausfordeungen bei der Abbildung didaktischer Anforderungen

mit XML. In: Klaus P. Jantke, Wolfgang S. Wittig and J¨

org Herr-

mann (eds.): Von e-Learning bis e-Payment. Das Internet als siche-

rer Marktplatz (LIT ’02). Infix, 2002, pp. 339–346.

[Goland99] Y. Goland, E. Whitehead, A. Faizi and D. Jensen: HTTP Extensions

for Distributed Authoring – WEBDAV, RFC 2518. Network Wor-

king Group, http://www.webdav.org/ (viewed 29.10.2005), 1999.

[Goldfarb90] Charles F. Goldfarb: The SGML Handbook. Oxford University Press,

1990.

[Goosen99] Goosen, Rahtz, Gurari, Moore and Sutor: The LaTEX Web Com-

panion. Addison-Wesley, 1999.

[Griffel98] Frank Griffel: Componentware: Konzepte und Techniken eines Soft-

wareparadigmas. dpunkt-Verlag, Heidelberg, 1998.

[Gurari00] E. Gurari and R. Rahtz: From LaTEX to MathML and Back with

TEX4ht and PassiveTEX. In: The first MathML International Con-

ference, Urbana-Champaign, Illinois 2000, pp. 76–82.

[Hansch02] Matthias Hansch, Stefan Kuhlins and Martin Schader: XML-

Schema. In: Informatik Spektrum, 25(5), 2002, pp. 363–366.

[Harold02a] Elliotte Rusty Harold: Processing XML with Java: A Guide to SAX,

DOM, JDOM, JAXP, and TrAX. Addison-Wesley Pub Co, ISBN:

0201771861, 2002.

[Harold02b] Elliotte Rusty Harold: The XML Bible, 2nd Edition. John Wiley &

Sons; 2nd Book and CD-ROM edition, ISBN: 0764547607, 2002.

[Heafele05] Hartmut Heafele. Autorenwerkzeuge f¨

ur Learning Content.

http://virtual-learning.qualifizierung.com/ (viewed 29.10.2005),

2005.

[Heng03] Simon Heng. Learning objects - where next? 3rd Annual CM316

Conference on Multimedia Systems, 2003.

[Hodgins02] Wayne Hodgins: The future of learning objects. In: Proceedings of

the 2002 eTEE Conference, August 2002, pp. 76–82.

[Ignatiadis03] Michael Ignatiadis. Learning Objects - does size matter? 3rd Annual

CM316 Conference on Multimedia Systems, 2003.

LITERATURVERZEICHNIS 205

[ILI04] Integriertes Lern-, Informations- und Arbeitskooperationssystem.

http://www.ilias.uni-koeln.de/ios/index.html (viewed 25.11.2004),

2004.

[IMS03a] IMS Content Packaging Information Model, Version 1.1.3 Final

Specification. http://www.imsglobal.org/ (viewed 29.10.2005), Juni

2003.

[IMS03b] IMS Digital Repositories Interoperability - Core Functions Informa-

tion Model, Version 1.0 Final Specification, 2003.

[IMS03c] IMS Learning Design Information Model Version 1.0 Final

Specification. http://www.imsglobal.org/learningdesign/ (viewed

29.10.2005), 2003.

[IMS03d] IMS Learning Resource Meta-Data Information Model, Version 1.2.1

Final Specification. http://www.imsglobal.org/ (viewed 02.03.2003),

2003.

[IMS05a] IMS Question and Test Interoperability Addendum, Version 1.2.1

Final Specification. http://www.imsglobal.org/ (viewed 29.10.2005),

2005.

[IMS05b] Instructinal Management Systems Project (IMS) Homepage.

http://www.imsglobal.org/ (viewed 29.10.2005), 2005.

[JDO05] JDOM-Project. http://www.jdom.org (viewed 29.10.2005), 2005.

[JSP05] Java server pages, the apache software foundation.

http://jakarta.apache.org/ (viewed 29.10.2005), 2005.

[Kerres98] M. Kerres: Multimediale und telemediale Lernumgebungen - Kon-

zeption und Entwicklung. Oldenbourg Verlag, ISBN: 3-486-24539-2,

1998.

[Klamma03] R. Klamma, M. Spaniol and M. Jarke: Digital media knowledge ma-

nagement with MPEG-7. In: The Twelfth International World Wide

Web Conference (WWW 2003), Budapest, Hungary, May 2003.

[Kohlhase00] Michael Kohlhase: OMDoc: An Infrastructure for OpenMath Con-

tent Dictionary Information. In: Bulletin of the ACM Special Interest

Group for Algorithmic Mathematics SIGSAM, 2000.

[Kohlhase02] Michael Kohlhase: OMDoc: An open Markup Format for Mathema-

tical Documents (Version 1.1). Carnegie Mellon University, January

2002.

206 LITERATURVERZEICHNIS

[Koper01] Rob Koper. Modeling Units of Study from a pedagogical perspec-

tive: the pedagogical meta-model behind EML, June 2001. Open

University of the Netherlands.

[Koper04] Rob Koper and Jocelyn Manderveld: Educational Modelling Lan-

guage: modelling reusable, interoperable, rich and personalised units

of learning. In: British Journal of Educational Technology.

[LON05] The learning online network with capa. http://www.lon-capa.org/

(viewed 29.10.2005), 2005.

[Lytras] Miltiadis D. Lytras and Athanasia Pouloudi. E-Learning: Just a wa-

ste of time. http://citeseer.ist.psu.edu/lytras01elearning.html (view-

ed 29.10.2005).

[Mac05] Macromedia Authorware 6. http://www.macromedia.com (viewed

29.10.2005), 2005.

[Mat05a] Ein multimedialer Baukasten f¨

ur die Mathematik-Ausbildung im

Grundstudium. http://www.math-kit.de (viewed 29.10.2005), 2005.

[Mat05b] W3C’s Math Home Page, World Wide Web Consortium.

http://www.w3.org/Math/ (viewed 29.10.2005), 2005.

[Melis03] Erica Melis, Georgi Goguadze, Paul Libbrecht and Carsten Ullrich:

Wissensmodellierung und -nutzung in ActiveMath. In: KI -

Kuenstliche Intelligenz, 1/03, pp. 12–17. http://www.kuenstliche-

intelligenz.de/Artikel/Wissensmodellierungund-

nutzunginActiveMa.htm (viewed 12.05.2003).

[Mertsching01] B¨

arbel Mertsching. Material zur Vorlesung Systemtheorie. Univer-

sit¨

at Hamburg, Fachbereich Informatik, Arbeitsgruppe IMA, unver-

offentlichtes Skript, 2001.

[Mertsching02] B¨

arbel Mertsching. Material zur Vorlesung Technische Informatik

T1/T2. Universit¨

at Hamburg, Fachbereich Informatik, Arbeitsgrup-

pe IMA, unver¨

offentlichtes Skript, 2002.

[Meyer97] Bertrand Meyer: Object-Oriented Software Construction - SECOND

EDITION. Prentice Hall PTR, Upper Saddle River, ISBN: 0-13-

629155-4, 1997.

[National Defence02] Canadian Department of National Defence. SCORM Dynamic Ap-

pearance Model, White Paper 1.0, 2002.

[Negroponte96] Nicholas Negroponte: Being Digital. Vintage Books USA, 1996.

LITERATURVERZEICHNIS 207

[Net05] TML Language Specification. http://www.ilrt.bris.ac.uk/netquest/

about/lang/ (viewed 29.10.2005), 2005.

[Niegemann03] Helmut M. Niegemann, Silvia Hessel, Dirk Hochscheid-Mauel Kri-

stina Aslanski, Markus Deimann and Gunther Kreuzberger: Kom-

pendium E-Learning. Springer Verlag, 2003.

[OOS02] OpenOffice.org XML File Format, Technical Reference Manual, Sun

Microsystems. http://xml.openoffice.org/xml specification.pdf, De-

cember 2002.

[Pawlowski01] Jan Martin Pawlowski: Das Essener-Lern-Modell (ELM): Ein Vor-

gehensmodell zur Entwicklung computerunterst¨

utzter Lernumgebun-

gen. PhD thesis, Essen, Universit¨

at Essen, Fachbereich Wirtschafts-

wissenschaften (BWL, VWL, Rechtswissenschaft und Wirtschaftsin-

formatik), 2001. http://deposit.ddb.de/cgi-bin/dokserv?idn=

963514113.

[Pawlowski02] Jan M. Pawlowski: Reusable Models of Pedagogical Concepts - a

Framework for Pedagogical and Content Design. In: Proc. of ED-

MEDIA 2002, World Conference on Educational Multimedia, Hyper-

media & Telecommunications. Philip Barker AND Samuel Rebelsky,

2002.

[Pomberger96] Gustav Pomberger and G¨

unther Blaschek: Software Engineering,

vol. 2. Hanser, 1996.

[Ray01] Erik T. Ray: Einf¨

uhrung in XML, vol. 1. Auflage. OReilly, 2001.

[Reglin03] Thomas Reglin and Eckart Severing: eLearning f¨

ur die betriebliche

Praxis. No. 30 in ISBN 3-7639-3112-0. W. Bertelsmann Verlag, 2003.

[Rieser00] Nicole Rieser (ed.): Der Brockhaus von A-Z, vol. 2. Weltbild Verlag

GmbH, ISBN: 3-7653-3642-4, 2000.

[Roisin98] C. Roisin: Authoring Structured Multimedia documents. In: 25th

Conference on Current Trends in Theory and Practice of Informatics

(SOFSEM’98. Springer, 1998, pp. 222 – 239.

[Rumbaugh91] James Rumbaugh: Object-Oriented Modeling and Design. Prentice

Hall, 1991.

[Saddik01a] Abdulmotaleb El Saddik: Interactive Multimedia Learning. Shared

Reusable Visualization-based Modules. Springer-Verlag Berlin Hei-

delberg, ISBN: 3540419306, 2001.

208 LITERATURVERZEICHNIS

[Saddik01b] Abdulmotaleb El Saddik, Stephan Fischer and Ralf Steinmetz: Reu-

sable Multimedia Content in Web-based learning Systems. In: IEEE

Multimedia, July 2001, pp. 30–38.

[Saddik02] Abdulmotaleb El Saddik: E-Learning Standards: The Dawn has

broken. In: Philip Barker and Samuel Rebelsky (eds.): Proc. ED-

MEDIA 2002–World Conference on Educational Multimedia, Hyper-

media & Telecommunications, 2002.

[Schulmeister81] R. Schulmeister: Lerntheorien - Lernprozesse, r8366. Technical re-

port, Interdiszipli¨

ares Zentrum f¨

ur Hochschuldidaktik der Universi-

t¨

at Hamburg, Juni 1981.

[Schulmeister96] R. Schulmeister: Grundlagen hypermedialer Lernsysteme: Theorie -

Didaktik - Design, vol. 1. Addison-Wesley, ISBN: 3-89319-923-3,

1996.

[Schulmeister03] R. Schulmeister: Lernplattformen f¨

ur das virtuelle Lernen. Olden-

bourg Wissenschaftsverlag, 2003.

[Seufert02] Sabine Seufert and Peter Mayr: Fachlexikon e-lerning. Wegwei-

ser durch das e-Vokabular. managerSeminare, ISBN: 3931488640,

http://www.managerseminare.de/msemi/1412896/frontend/ elexi-

kon liste.html?kat=2000 (viewed 29.10.2005), 2002.

[Shen02] Zhongnan Shen, Yuanchun Shi and Guangyou Xu: A Learning Re-

source Metadata Management System Based on LOM Specification.

In: The 7th International Working Group on Computer Supported

Cooperative Work in Design (CSCWD2002), Rio de Janeiro, 2002.

[Sim05] The Simplified DocBook Document Type, Committee Specification

V1.1. http://www.docbook.org/specs/cs-docbook-simple-1.1.html,

(viewed 29.10.2005), 2005.

[Simon02] Bernd Simon: E-Learning an Hochschulen - Gestaltungsr¨

aume und

Erfolgsfaktoren von Wissensmedien. Josef Eul Verlag, 2002.

[Skinner78] B. Skinner: Was ist Behaviorismus? Rohwolt, Reinbek bei Hamburg,

1978.

[Snell02] James Snell, Doug Tidwell and Pavel Kulchenko: Webservice-

Programmierung mit SOAP. O’Reilly, ISBN: 3897211599, 2002.

[Str05] Struts, The Apache Software Foundation. http://struts.apache.org/

(viewed 29.10.2005), 2005.

LITERATURVERZEICHNIS 209

[S¨

uß99] Christian S¨

uß, Burkhard Freitag and Peter Br¨

ossler: Metamodeling

for Web-Based Teachware Managment. In: P.P. Chen, D.W. Embley,

J. Kouloumdijan, S.W. Liddle and J.F. Roddick (eds.): Advances in

Conceptual Modeling. ER’99 Workshop on the World-Wide Web and

Conceptual Modeling, Paris, France, Nov. 1999, vol. 1727 of LNCS,

Berlin, 1999. Springer-Verlag, pp. 360–373.

[S¨

uß00] Christian S¨

uß and Burkhard Freitag: Entwicklung und Nutzung von

Teachware: Das Passauer Knowledge Management System (PaK-

MaS). In: Computerunterst¨

utztes Lernen, 2000. Oldenbourg-Verlag,

M¨

unchen.

[Szillat95] Horst Szillat: SGML Eine Proktische Einf¨

uhrung, vol. 1. Internatio-

nal Thomson Publishing GmbH, ISBN: 3-929821-75-3, 1995.

[Szyperski97] Clemens Szyperski: Component Software - Beyond Object-Oriented

Programming. Addison Wesley, Reading, Massachusetts, 0-201-

17888-5, 1997.

[S¨

unneli04] Yildiz S¨

unneli and Nurdan Turan: Entwicklung einer Software-

Komponente zur Integration bestehender Lehr- und Lernmateria-

lien und deren Metadaten in das math-kit-System. Diplomarbeit,

Universit¨

at Hamburg, Fachbereich Informatik, May 2004.

[Taylor96] David A. Taylor: Objektorientierte Technologien, Ein Leitfaden f¨

Manager. Addison-Wesley, 1996.

[Thissen97] F. Thissen: Das Lernen neu erfinden, Grundlagen einer konstrukti-

vistischen Multimedia-Didaktik. In: U. Beck and W. Sommer (eds.):

LearnTec 97, Europ¨

aischer Kongress f¨

ur Bildungstechnologie und be-

triebliche Bildung, Karlsruhe, 1997. pp. S. 69–79.

[Thissen99a] F. Thissen: Im Informationsreichtum verhungern? In: U. Beck and

W. Sommer (eds.): LearnTec 99, Karlsruhe, 1999. pp. S. 725–730.

[Thissen99b] Frank Thissen: Lerntheorien und ihre Umsetzung in multimedialen

Lernprogrammen - Analyse und Bewertung. In: BIBB Multimedia

Guide Berufsbildung.

[Unger04] L. Unger, M. J. Bauch, A. Baudry, M. Bungenstock, B. Mert-

sching, G. Oevel, K. Padberg and B. Thiere: Ein multimedia-

ler Bauksaten f¨

ur die Mathematikausbildung im Grundstudium.

In: Softwaretechnik-Trends, Gesellschaft f¨

ur Informatik e.V., Band

24(Heft 1), 2004, pp. 62–71.

210 LITERATURVERZEICHNIS

[Valerius01] Marianne Valerius and Anna Simon: Slicing Book Technology

eine neue Technik f¨

ur eine neue Lehre? Technical report, Fach-

berichte Informatik 8/2001, Universitaet Koblenz-Landau, 2001.

http://www.uni-koblenz.de/fb4/publikationen/gelbereihe/RR-8-

2001/ (viewed 29.10.2005).

[Valk80] R¨

udiger Valk: Rechensysteme. Springer, 1980.

[Verbert04] Katrien Verbert and Erik Duval: Towards a Global Component Ar-

chitecture for Learning Objects: A Comparative Analysis of Lear-

ning Object Content Models. In: ED-MEDIA 2004–World Confe-

rence on Educational Multimedia, Hypermedia & Telecommunicati-

ons, P.O. Box 3728, Norfolk, VA 23514-3728, June 2004. Ass. for the

Advancement of Computing in Education, pp. 202 – 208.

[W3C99] W3C. XML Path Language (XPath).

http://www.w3.org/TR/xpath (viewed 29.10.2005), 1999.

[W3C05a] XML Schema. http://www.w3.org/XML/Schema (viewed

29.10.2005), 2005.

[W3C05b] XML Syntax for XQUERY 1.0. http://www.w3.org/TR/xqueryx

(viewed 29.10.2005), 2005.

[W3C05c] XQuery 1.0: An XML Query Language.

http://www.w3.org/TR/xquery/ (viewed 29.10.2005), 2005.

W3C Working Draft 12 November 2003.

[Walsh02] Norman Walsh and Leonard Muellner: DocBook: The Definitive Gui-

de. O’Reilly & Associates, Inc, ISBN: 1-56592-580-7, 2002.

[WEB05] WebCT Campus Edition - Course Management System, WebCT Inc.

http://www.webct.com/ (viewed 29.10.2005), 2005.

[Weitl04] Franz Weitl, Rudolf Kammerl and Monica G¨

ostl: Context Aware

Reuse of Learning Resources. In: ED-MEDIA 2004–World Confe-

rence on Educational Multimedia, Hypermedia & Telecommunicati-

ons, P.O. Box 3728, Norfolk, VA 23514-3728, June 2004. Ass. for the

Advancement of Computing in Education, pp. 202 – 208.

[Wiley99] David Wiley. The Post-LEGO Learning Object.

http://wiley.ed.usu.edu/docs/post-lego.pdf (viewed 29.10.2005),

November 5 1999.

[Wiley00a] D. A. Wiley. Connecting learning objects to instructional design

theory: A definition, a metaphor, and a taxonomy. D. Wiley, The

Instructional Use of Learning Objects, 2000. Bloomington: Associa-

tion for Educational Communications and Technology.

LITERATURVERZEICHNIS 211

[Wiley00b] D. A. Wiley: Learning object design and sequencing theory. PhD

thesis, Brigham Young University, 2000.

[Wiley04] Wiley, Gibbons and Recker. A reformulation of the issue of lear-

ning object granularity and its implications for the design of lear-

ning objects. http://www.reusability.org/granularity.pdf (viewed

29.10.2005), 2004.

[Wilson99] M. Wilson: Standards and Reference Architectures: Their Purpose

and Establishment. In: In Proceedings of the AISB’99 Workshop on

Reference Architectures and Data Standards for NLP, Edinburgh,

1999.

[Wollowski02] Michael Wollowski: XML Based Course Websites. In: Margaret Dris-

coli and Thomas C. Reeves (eds.): E-LEARN 2002–World Confe-

rence on Educational in Corporate, World Conference on E-Learning

in Corporate, Government, Healthcare, & Higher Education, 2002,

pp. 1043–1048.

[Xer05] Xerces, XML - parsers in Java und C++, Apache XML Project.

http://xml.apache.org/xerces2-j/index.html (viewed 29.10.2005),

2005.

[XSL99] XSL Transformations (XSLT) Version 1.0.

http://www.w3.org/TR/xslt (viewed 16.04.2002), 1999.

[Z¨

ullighoven98] Heinz Z¨

ullighoven: Das objektorientierte Konstruktionshandbuch.

dpunkt-Verlag, Heinz Zuellighoven.-Heidelberg : dpunkt-Verl.,

ISBN: 3-932588-05-3, 1998.

212 LITERATURVERZEICHNIS