Aspekte der konventionellen Unterrichtsplanung können im Computerunterstützten Unterricht verwendet werden mit dem Ziel, den Unterricht durch geeignete Software in einem Tutor-System planen und ausführen zu lassen.
Auf der Basis einer gegebenen Architektur für Tutor-Systeme wird eine Planungskomponente geschaffen, die unter Einbeziehung von Tutorstrategien Unterrichtspläne berechnet und zur Ausführung bringt. Die theoretische Fundierung des Planens ist einerseits in den Methoden der Künstlichen Intelligenz und andererseits in der Graphentechnologie verankert.
Die gegebene Architektur für Tutor-Systeme sowie das Modul zur Planung und Planausführung werden durch eine Graphenrepräsentation realisiert. Mittels einer hierzu entwickelten Beschreibungssprache für die Dokumente eines Tutor-Systems wird eine rudimentäre Laufzeitumgebung für eine computerunterstützte Unterrichtsplanung zur Verfügung gestellt.
Inhaltsverzeichnis
2 Ansätze von Systemen für Computerunterstützten Unterricht
2.1 CAI-Systeme
2.2 Konzepte von ITS
2.3 Der Hypertext basierte Ansatz
2.4 Eine Architektur für Tutor-Systeme
3 Eine Architektur für Tutor-Systeme
3.1 Das Inhaltsmodul
3.1.1 Konzepte
3.1.2 Prozeduren
3.2 Das Lernermodul
3.3 Das Tutormodul
3.4 Das Interaktionsmodul
4 Planen
4.1 Was ist ein Plan?
4.2 Repräsentationen eines Planungssystems
4.2.1 Bestandteile eines Planungssystems
4.2.2 Formale Repräsentation von Plänen
4.2.3 Repräsentation von Plänen durch Graphen
4.3 Lineare Planungsmethoden
4.3.1 Planen als Inferenz
4.3.2 Planen als Suche
4.3.3 Ein Verfahren zum linearen Planen
4.4 Nichtlineare Pläne
4.4.1 Begriff der Nichtlinearität
4.4.2 Teilzielinteraktionen
4.4.3 Ein Verfahren zum nichtlinearen Planen
4.5 Planungsheuristiken und -Strategien
4.5.1 Opportunistisches Planen im CUU
4.5.2 Dynamisches Planen im CUU
4.5.3 Gemischte Planungsstrategien im CUU
5 Unterrichtsplanung in einer Architektur für Tutor-Systeme
5.1 Tutorgraphen und -plane
5.1.1 Tutorgraphen
5.1.2 Tutorpläne
5.2 Tutor-Strategien
5.2.1 Was ist eine Tutor-Strategie?
5.2.2 Repräsentation von Tutor-Strategien
5.2.3 Tutor-Strategien und Kreise in Tutorplänen .
5.3 Generierung von Tutorplänen aus Tutorgraphen
5.3.1 Möglichkeiten zur Berechnung von Tutorplänen
5.3.2 Plangenerierung ohne Verwendung von Tutor-Strategien
5.3.3 Anwendung von Tutor-Strategien bei der Plangenerierung
5.3.4 Plangenerierung und Kreisbehandlung
5.4 Ausführbarkeit von Tutorplänen
5.4.1 Opportunistische Ausführung
5.4.2 Dynamische Planausführung
5.4.3 Planausführung und Kreisbehandlung
6 Schlußbetrachtungen und Ausblick
Anhang
A Syntax der Dokument—Beschreibungssprache TkJßs
A.l TtoBs für Dokumente des Inhaltsmoduls
A.l.l TkrBs für Konzept-Dokumente
A.l.2 Tkfßs für Datenfluß-Dokumente
A.1.3 TXfSs für Pre-Post-Dokumente
A. l.4 TkfBs für Kontrollfluß-Dokumente
A.2 Tkjßs für Dokumente des Lernermoduls
A.3 Ttoßs für Dokumente des Tutormoduls
A.4 TkrBs zur Erzeugung von Tutorgraphen
A.5 Tkrßs zur Spezifikation von Tutor-Strategien
A.6 TtoRs zur Erzeugung von Tutorplänen
A.7 TkJBs zur Ausführung von Tutorplänen
A. 8 T&Bs zur Definition von Strategie-Listen
В Ablaufprotokolle der Algorithmen
B. l Algorithmus 4.1 in Beispiel 4.4
B.2 Algorithmus 4.3 in Beispiel 4.5
B. 2.1 Vorwär t s-Suche
B.2.2 Rückwärtstraversierung
B.3 Algorithmus 5.1 in Beispiel 5.1
В.4 Algorithmus 5.3 in Beispiel 5.4
B.5 Algorithmus 5.4 in Beispiel 5.5
B.5.1 Vorwärts-Suche
B.5.2 Rückwärtstraversierung
B.6 Algorithmus 5.5 in Beispiel 5.6
B.7 Algorithmus 5.7 in Beispiel 5.6
Literatur
Stichwortverzeichnis
Vorwort
Die vorliegende Diplomarbeit entstand im Verlauf eines Projekts Tutor-Systeme am Institut für Software-Technik (IST) der Universität Koblenz-Landau an der Abteilung Koblenz. Ausgangspunkt für diese Arbeit war die Dissertation von Uwe DumslafF, der sich seit einigen Jahren mit Forschungsarbeiten im Bereich der tutoriellen Systeme aus der Sicht des Software Engineering beschäftigt. Bei ihm möchte ich mich für die vorbildliche Betreuung und die konstruktive und vertrauensvolle Zusammenarbeit, die auch über den Rahmen der Diplomarbeit hinausging, bedanken. Seine motivierende Art und seine wertvollen Anregungen und Ratschläge trugen wesentlich zu dieser Arbeit bei
Herrn Prof. Dr. Jürgen Ebert, der mich von Beginn meines Studiums an über zahlreiche Vorlesungen begleitete, danke ich für die Unterstützung und sein Interesse an der Mitbetreuung. Er gab mir die Möglichkeit, über mehr als zwei Jahre hinweg als studentische Hilfskraft erste praktische Erfahrungen in der Teamarbeit und im Umfeld von CASE-Projekten zu machen
Den CASE—Hiwis danke ich für die freundliche und unkomplizierte Aufnahme in ihre Projektgruppe, für die Hilfsbereitschaft und Unterstützung bei etlichen Implementations- und Layout-Fragen und nicht zuletzt für die zuvorkommende Versorgung mit frischem Kaffee
Bei Peter Dahm möchte ich mich herzlich für das mühevolle und zeitintensive Korrekturlesen bedanken
Kurzfassung
Aspekte der konventionellen Unterrichtsplanung können im Computerunterstütztem Unterricht verwendet werden mit dem Ziel, den Unterricht durch eine geeignete Software in einem Tutor-System planen und ausführen zu lassen
Auf der Basis einer gegebenen Architektur für Tutor-Systeme wird eine Planungskomponente geschaffen, die unter Einbeziehung von Tutor-Strategien Unterrichtspläne berechnet und zur Ausführung bringt. Die theoretische Fundierung des Planens ist einerseits in den Methoden der Künstlichen Intelligenz und andererseits in der Graphentechnologie verankert
Die gegebene Architektur für Tutor-Systeme sowie das Modul zur Planung und Planausführung werden durch eine Graphenrepräsentation realisiert. Mittels einer hierzu entwickelten Beschreibungssprache für die Dokumente eines Tutor-Systems wird eine rudimentäre Laufzeitumgebung für eine computerunterstützte Unterrichtsplanung zur Verfügung gestellt
1 Einführung
Ein Zusammenhang zwischen Computerunterstütztem Unterricht und Aspekten des Planens wird für den Leser möglicherweise auf den ersten Blick nicht klar ersichtlich sein. Wenn man sich überlegt, wie ein Lehrer seinen Unterricht vorbereiten könnte, dann wird man erkennen, daß eine seiner Hauptaufgaben darin besteht, den Unterrichtsstoff in geeigneter Art und Weise — also möglichst nach didaktischen Gesichtspunkten — in einer sinnvollen Reihenfolge anzuordnen. Zur Unterstützung der Vorgehensweise im Zuge einer Unterrichtsvorbereitung sind Methoden und Heuristiken der Planung für eine Lehrperson unerläßlich. Eine Unterrichtsvorbereitung stellt unter diesem Blickwinkel betrachtet bereits ein Planungsproblem dar.
Computerunterstützter Unterricht, im folgenden mit CUU abgekürzt, soll einem Ler- ner zur Vermittlung von Inhalten mit Hilfe eines Computers und einer entsprechenden Lernsoftware dienen. Vorherrschend in diesem Bereich sind Systeme, bei denen ein fester Unterrichtsverlauf (Curriculum) vorgegeben ist. Anzustreben ist jedoch ein System, welches sich an jeden einzelnen Lerner sowohl bezüglich seines Wissens als auch seiner Lernfähigkeiten derart anpaßt, daß individuelle Unterrichtspläne abhängig vom Vorwissen des Lerners und den von ihm zu erreichenden Lernziele berechnet werden können. Im vorliegenden Bericht wird versucht, Aspekte der individuellen und automatischen Unterrichtsplanungin den CUU einzubeziehen. Dies geschieht durch die Integration einer Planungskomponente in eine gegebene Architektur für Tutor-Systeme.
Innerhalb des CUU gibt es bislang eine Vielzahl von Ansätzen, welche sich in völlig verschiedene Richtungen entwickelt haben. Das gesamte Spektrum erstreckt sich von Computer Assisted Instruction-Systemen (CAI) und deren Autorensprachen und -Systemen bis hin zu leistungsfähigen Intelligent Tutoring Systeme (ITS), welche insbesondere Mittel und Methoden der Künstlichen Intelligenz (KI) verwenden. CAI-Systeme werden zu den konventionellen Systemen im CUU gerechnet, die ITS zu den wissensbasierten Systemen. Parallel dazu haben sich im Bereich der Inhaltsvermittlung per Computer die hypertextbasierten CUU-Systeme etabliert. In Kapitel 2 wird ein kurzer Überblick zu diesen Ausprägungen gegeben.
Ein primäres Merkmal moderner CUU-Systeme ist deren Modularisierung in einzelne Komponenten hinsichtlich der beteiligten Akteure und Schnittstellen. Eine gebräuchliche Aufteilung ist die Unterscheidung in eine Wissensrepräsentationskomponente, eine
Lernerkomponente sowie in eine Tutorkomponente und eine Interaktionskomponente. Die wichtigsten Merkmale dieser Module werden in Kapitel 2 herausgearbeitet. Als Beispiel für ein nach diesen Komponenten konzipiertes CUU-System wird am Ende des Kapitels eine konkrete Architektur für Tutor-Systeme nach Dumslaff [Dums94] vorgestellt.
Die in Kapitel 3 ausführlicher beschriebene Architektur für Tutor-Systeme wurde anhand einer ITS-Standardstruktur (s. [TePa87, S.321]) entwickelt und mit Hilfe einer Graphenrepräsentation prototypisch implementiert. Eine Autorenschnittstelle dazu steht auf der Ebene einer eindimensionalen Beschreibungs-Sprache zur Verfügung, die es einem Autor ermöglicht, Dokumente des Inhalts-, Lemer- und Tutormoduls zu definieren. Eine Möglichkeit zur Formulierung von Interaktions-Dokumenten ist bisher nicht vorgesehen.
Bei der Erstellung von Unterrichtseinheiten in CUU-Systemen werden Autoren meist durch spezielle Autorensoftware unterstützt, die primär der Eingabe von zu vermittelnden Inhalten und eventuell zu verwendenden Unterrichts-Strategien dient. Im Kontext solcher Tutor-Strategien kommt dem Autor eine gewisse Unterrichts-Vorplanung zu, die je nach gewählter Strategie den gewünschten Unterrichtsstoff in eine didaktisch geeignete Reihenfolge bringt. Diese Unterrichtssequenzen werden dann in der Lernersitzungen zur Ausführung gebracht. Die Erstellung von Unterrichtssequenzen nach einer bestimmten Tutor-Strategie kann somit als ein Planungsproblem betrachtet werden. Mit der Lösung dieses Planungsproblems ist es vorstellbar, eine Unterrichtsplanung nach vorher vom Autor definierten Strategien durch CUU-System selbst durchführen zu lassen. Aufgabe einer Komponente zur Unterrichtsplanung wird somit die Herstellung einer sinnvollen Anordnung von auszuführenden Lehrhandlungen sein, die auf ein vom Lerner zu erreichendes Lehrziel gerichtet ist.
Ziel dieser Arbeit ist es, Aspekte der Planung im Rahmen des CUU zu thematisieren und insbesondere auf eine konkrete Architektur für Tutor-Systeme anzuwenden. Im vorliegenden Bericht wird versucht, Planungsmethoden aus der Künstlichen Intelligenz mit der gegebenen Tutor-System-Architektur so zu kombinieren, daß am Ende ein ausführbares prototypisches Tutor-System mit Planungskompetenz zur Verfügung steht. Die durch eine Planungskomponente generierten Pläne können jedoch nichtlinearen Charakter besitzen. Dies erfordert geeignete Heuristiken zur Linearisierung der Pläne, um zu einer ausführbaren Unterrichtssequenz zu gelangen. In diesem Kontext spielen wiederum Tutor-Strategien eine wesentliche Rolle. Der Begriff des Planens wird in Kapitel 4 unter Einbeziehung von Planungsmethoden und -heuristiken der KI behandelt. Dort werden insbesondere lineare und nichtlineare Planungsverfahren besprochen. Diese Verfahren werden auf der Basis von Graphenalgorithmen vorgestellt..
Mit dem Wissen über Planungsmethoden und über eine konkrete Tutor-System-Architektur werden die beiden Themenkomplexe in Kapitel 5 zusammengeführt. Dort werden zunächst die für eine Unterrichtsplanung notwendigen Strukturen wie Tutor- graphen und -plane definiert. Konkrete Tutor-Strategien werden eingeführt und eine formale Repräsentation für diese vorgeschlagen. Weiter werden verschiedene Möglichkeiten der Plangenerierung und -ausfuhrung diskutiert, insbesondere unter dem Aspekt der Anwendung von Tutor-Strategien.
In Kapitel 6 dieses Berichts erfolgt eine Zusammenfassung der durch diese Arbeit erreichten Ergebnisse und ein Ausblick auf Erweiterungsmöglichkeiten des prototypischen Tutor-Systems mit Planungskompetenz.
Im nun folgenden Kapitel wird ein Überblick über historische und neuere Ansätze verschiedener CUU-Systeme gegeben. Dabei wird sowohl auf die wichtigsten Merkmale von CAI und ITS als auch auf strukturelle Unterschiede bei konventionellen, hypertextbasierten und wissensbasierten CUU-Systemen eingegangen. Anschließend wird das grundlegende Konzept der bereitgestellten Architektur für Tutor-Systeme nach Dumslaff [Dums94] skizziert.
2 Ansätze von Systemen für Computerunterstütz ten Unterricht
Eine häufig verwendete Klassifizierung von CUU-Systemen verwendet die Unterscheidung in konventionelle Computer Assisted Instruction Systeme (CAI-Systeme) und Intelligent Tutoring Systeme (ITS). Im folgenden werden diese beiden Ansätze voneinander abgegrenzt. Dabei wird im besonderen auf die Merkmale von ITS eingegangen, da diese Systeme den Grundstein für die wissensbasierten Strukturen von Tutor-Systemen legen. Anschließend wird der dazu parallel zu betrachtende hypertextbasierte Ansatz von CUU erläutert. Der letzte Abschnitt dieses Kapitels widmet sich einer ersten Charakterisierung der Architektur für Tutor-Systeme nach [Dums94]. Dieser Ansatz wird für die weiteren Überlegungen bezüglich des Planens im CUU zugrundegelegt.
Bevor die verschiedenen Ausprägungen bisher etablierter CUU-Systeme vorgestellt werden, soll eine knappe Definition dafür gegeben werden, was unter Computerunterstütztem Unterricht im engeren Sinne verstanden wird.
Definition 2.1 (Computerunterstützter Unterricht)
“Unter computerunterstütztem Unterricht versteht man zusammenfassend alle Computerdialoganwendungen, die für den Endbenutzer (Adressat“) eine Lehr- oder Lernfunktion beinhalten. Im engeren Sinne werden darunter solche Lehr Strategien verstanden, die der Übung und Prüfung oder dem tutoriellen Lernen dienen. [...]“ [Schn91]
2.1 CAI-Systeme
CAI-Systeme sind den konventionellen CUU-Systeme zuzuordnen[1]. Diese Klasse von Systemen ist sowohl hochgradig framebasiert als auch curriculumorientiert. In sogenannten Frames werden Texte, Fragen, Antworten, Grafiken sowie die notwendigen Informationen an Verzweigungsstellen im Lehrablauf abgelegt. Durch die vom Autor festgelegte Anordnung dieser Frames bzw. der vorgegebenen Instruktionsreihenfolge ist die strenge Orientierung an einem Lehrplan, dem Curriculum, vorgegeben. Dieser einmal festgelegte Unterrichtsablauf eines CAI-Systems ist allerdings hinsichtlich der fehlenden Adaptivität und Flexibilität ein entscheidender Nachteil für den einzelnen Lerner.
Adaptivität und Flexibilität von CUU wird unter dem Gesichtspunkt der Individualisierung betrachtet. Die Begriffe Adaptivität und Flexibilität werden im folgenden bezüglich ihrer Bedeutung im tutori eilen Kontext definiert.
Definition 2.2 (Adaptiver CUU)
“[...] CUU ist adaptiv, wenn er sich an die unterschiedlichen Eingangsbedingungen und die unterschiedlichen Entwicklungen einzelner Lerner anpaßt. Eingangsbedingungen sind die Vorkenntnisse der einzelnen Lerner hinsichtlich der Lehrziele, sowie die unterschiedlichen Lerngewohnheiten und Lernstile. Die Entwicklung eines Lerners umfaßt die Art und Weise, wie er sich den Lernzielen nähert.“ [Dums94, S.36]
Definition 2.3 (Flexibler CUU)
“[...] CUU ist flexibel, wenn das Angebot an Inhalten sowie deren Darstellung und Präsentation sich an den Wünschen und Bedürfnissen eines jeden einzelnen Lerners anpaßt.“ [Dums94, S.35]
Vereint ein CUU-System die Merkmale der Adaptivität und Flexibilität in sich, so spricht man von individualisiertem CUU. Auf die Eigenschaft der Individualisierung von CUU wird im Kontext der in Kapitel 3 vorgestellten Architektur für Tutor-Systeme sowie bei der Einführung von Tutor-Strategien in Kapitel 5 zurückgegriffen.
In CAI-Systemen kann aufgrund der fehlenden oder unterentwickelten Lernermodel- lierung nicht von individualisiertem Unterricht gesprochen werden. Es gibt in diesen Systemen meist weder die Möglichkeit, Lernerfehler zu diagnostizieren noch in irgendeiner Form zu beheben. Die inhaltliche Seite solcher Systeme ist in den meisten
Fällen domänenspezifisch ausgeprägt. Das bedeutet, daß es sich um nicht übertragbare Einzellösungen handelt, die nur für bestimmte Anwendungsfelder vorgesehen sind. Ein Beispiel für eine typische CAI-Lösung ist das von Heines [HeO’85] beschriebene ReGIS[2] -System, welches einen Kurs zur Anwendung von graphischen Operationen an speziellen Graphik-Bildschirmen anbietet. Das Lernermodell dieses Systems läßt lediglich eine stufenweise Variation von einigen Lernerparametern, wie Lerngeschwindigkeit, Lernstil und Kenntnisstand, zu. Auf der Ebene der Inhaltsrepräsentation sind die zu lösenden Aufgaben domänenspezifisch und statisch in einem gerichteten UND/ODER- Graphen[3] angeordnet.
Im Bereich der CAI-Systeme wurden sogenannte Autorensprachen und -Systeme bereits früh entwickelt. Bei der Verwendung von Autorensprachen werden beim Autor Programmierkenntnisse vorausgesetzt, da hier nur mittels vordefinierter Makrobefehle Frames und deren Kontrollstrukturen definiert werden können. Im Gegensatz dazu unterstützen Autorensysteme einen Autor bei der Generierung eines CUU-Systems auf einem vergleichsweise höheren Niveau, z.B. durch Bereitstellung von Masken, die vom Autor nur noch mit Text- oder Graphikelementen gefüllt werden müssen. Als ein Vertreter von Autorensystemen ist das PLATO-System von Bitzer [Bitzer76] zu nennen.
2.2 Konzepte von ITS
Intelligente Tutorielle Systeme werden zu den wissensbasierten CUU-Systemen gezählt. Ein Ziel von ITS ist die Individualisierung von CUU. Diese umfaßt beispielsweise das Angebot von Hilfestellungen für den Lerner zum richtigen Zeitpunkt, ähnlich wie dies bei der Option einer kontextsensitiven Hilfe in modernen Anwendungsprogrammen genutzt werden kann. Zum Aspekt der Individualisierung gehören weiter Möglichkeiten der Behandlung konzeptueller Fehlannahmen des Lerners oder der Lernerdiagnose. Um diese anspruchvolleren Merkmale von ITS in den Griff zu bekommen, wird oft auf Techniken aus der KI zurückgegriffen. Insbesondere bei der Wissensrepräsentation gibt es unterschiedliche Ansätze aus der KI. Dazu sei auf die einschlägige Literatur zur Wissensrepräsentation durch Semantische Netze [Helbig91], durch Produktionssysteme, Mentale Modelle oder auf die Schematheorie [MaFrHr88] in der KI und Wissenspsychologie verwiesen.
Ein wesentliches Unterscheidungsmerkmal von ITS zu CAI-Systemen liegt in deren modularer Architektur (s. [Wenger87], [TePa87]). Es finden sich unterschiedliche Aufteilungen von prinzipiell immer wiederkehrenden Komponenten. Grundsätzlich wird zwischen einer Wissensrepräsentationskomponente, einer Lernermodellierungskompo- nente, einer Tutorkomponente und einer Interaktionskomponente unterschieden. Diese Komponenten werden nun einzeln kurz charakterisiert.
Die Wissensrepräsentationskomponente
Im Unterschied zu den CAI-Systemen wird hier das Wissen explizit[4] und die Beziehungen zwischen den Inhalten zumindest teilweise explizit repräsentiert, so daß auf das Wissen unabhängig vom aktuellen Zustand des Systems Zugriffen werden kann.
Lehrinhalte werden meist in prozedurales und deklaratives Wissen, oft noch in kausales Wissen (s. [Meye89, S.20f]), differenziert. Prozedurales Wissen interna- lisiert bestimmte Vorgehensweisen der Problemlösung bzw. Zielerreichung. Das deklarative Wissen ist unabhängig von einer bestimmten Verwendung eher als Fakten- oder Konzeptwissen zu verstehen. Kausales Wissen repräsentiert die gegenseitigen Abhängigkeiten in Form von qualitativen Modellen der Objekte innerhalb eines Wissensbereichs.
Die Lernermodellierungskomponente
Diese Komponente stellt das Wissen über den einzelnen Lerner zur Verfügung. Dort wird das Vorwissen, das aktuelle Wissen und das Verständnis des Lerners bezüglich des in der Wissensrepräsentationskomponente abgelegten Wissensbereichs abgelegt. Dieses Wissen über den Lerner kann auch von einer Tutorkompo- nente verwendet werden, um eine Individualisierung des Unterrichts zu erreichen.
Das im Verlauf einer Lernersitzung entstehende Lernermodell ist die Summe der Annahmen über das Wissen des Lerners, welches über Tests oder Lernerreak- tionen zu operationalisieren ist. Man geht deshalb von einer Annahme des Ler- nerwissens aus, weil ein Lerner z.B. auch bestimmte Konzepte vergessen haben kann oder bei Multiple-Choice-Fragen nur richtig geraten haben kann. Solche Einzelfälle sind nicht konkret zu fassen, sondern gegebenenfalls über Wahrscheinlichkeitsannahmen im Lernermodell zu repräsentieren.
Die Tutorkomponente
In der Tutorkomponente ist das didaktische und strategische Wissen (z.B. Präsentationsmethoden, Dialogführung) explizit abgelegt. Dieses Wissen kann einem System zum Treffen von Entscheidungen im Lehrablauf und bei der Planung von Unterrichtseinheiten dienen. Durch Explizieren von Tutor-Wissen ergibt sich auch die Möglichkeit, Tutor-Strategien exakt auszuformulieren. Aufgaben der Tutorkomponente können die Auswahl von Lernzielen und Hilfestellungen, das Bestimmen von Unterbrechungs- oder Hilfestellungszeitpunkten sowie die Steuerung von Kommunikation und Interaktion sein.
Für eine Tutorkomponente ist eine leistungsfähige Autorenschnittstelle zur Eingabe von Wissen im Bereich der didaktischen Methoden und Tutor-Strategien vorstellbar. Weiter könnten Beeinflussungsmöglichkeiten durch den Autor in Bezug auf Strategien, auf das Lernermodell und die Interaktionskomponente zur Verfügung stehen (s. [Meye89]).
Die Interaktionskomponente
Diese wird häufig auch als Lerner schnittst eile bezeichnet. Durch sie bekommt der Lerner erst einen Zugang zum CUU-System. Die Interaktionskomponente dient einerseits der Bearbeitung und Weiterleitung von Lernereingaben an die Tutorkomponente und andererseits der Aufbereitung und Präsentation von Lehrinhalten für den Lerner.
Ein in die objekt-orientierte Richtung gehendes Konzept einer ITS-Architektur ist der Bite-Sized-Ansatz von Bonar et al. (s. [BoCuSc86], [Bonar85]), der versucht, die oben erläuterten Komponenten bezüglich einzelner Inhalte zu integrieren. In sogenannten Bites werden Lehrinhalte zusammen mit dem zugehörigen didaktischen Wissen, einer Lemermodellierung und -diagnose und entsprechenden Interaktionselementen verwaltet.
2.3 Der Hypertextbasierte Ansatz
Dieser Ansatz kann parallel zu den zuvor erläuterten konventionellen und wissensbasierten Ansätzen von CUU-Systemen betrachtet werden. Hypertextbasierte Systeme setzen sich aus einer sogenannten Hypertextbasis und einem Hypertext-ManagementSystem zusammen. Der Anteil der Wissensrepräsentationskomponente wird durch die Hypertextbasis ausgefüllt. Diese besteht aus einzelnen Informationseinheiten (z.B. Frames) und aus Verknüpfungen zwischen diesen Einheiten. Das Hypertext-Management-System integriert die Lerner-, Tutor- und Interaktionskomponente.
Ein Lerner wird über seine individuelle Lernerhistorie, welche beispielsweise die Menge der besuchten Informationseinheiten in der Hypertextbasis beinhaltet, und das Ler- nerwissen modelliert, welches durch qualitativ ausgewertete Daten über das FrageAntwort-Verhalten des Lerners oder über erreichte Lernziele und Inhaltsstrukturen ausgedrückt werden kann.
Für den Tutoranteil innerhalb eines Hypertext-Management-Systems sind zwei unterschiedliche Strategien ausschlaggebend: zum einen ist dies die Strategie des freien Entdeckens, bei der die Reihenfolge der zu besuchenden Informationseinheiten durch den Lerner selbst bestimmt wird. Andererseits hat der Autor eines hypertextbasierten CUU-Systems die Möglichkeit, Guided Tours vorzubereiten, die nach didaktisch sinnvollen Aspekten formuliert werden können. Bei den Guided Tours handelt es sich um vorher festgelegte Reihenfolgen von Informationseinheiten, bei denen sequentielle, verzweigte oder bedingte Pfadstrukturen verwendet werden können.
Die Interaktionskomponente eines Hypertext-Management-Systems ist qualitativ mit der in konventionellen bzw. CAI-Systemen vergleichbar. Ein Lerner hat hier die
Möglichkeit, durch die Hypertextbasis zu “wandern“, im Sinne des linearen Navigie- rens, oder bestimmte Informationen durch Suchen oder Stöbern in der Hypertextbasis zu erhalten. Eine nicht zu unterschätzende Gefahr besteht dabei allerdings im Orientierungsverlust für den Lerner. Diesem Problem kann in solchen Systemen jedoch z.B. durch Setzen von “Lesezeichen“ oder Zeitmaxken entgegengewirkt werden. Für einführende Literatur bezüglich Hypertext-Systemem sei auf Kuhlen [Kuhlen91] verwiesen.
2.4 Eine Architektur für Tutor-Systeme
Bei der in [Dums94] konzipierten Architektur für Tutor-Systeme wird analog zur Standardstruktur von ITS (s. [TePa87, S.321]) eine strikte Trennung zwischen den Komponenten
- Inhaltsmodul,
- Lerner modul,
- Tutormodul und
- Interaktionsmodul
vorgenommen. Die Bedeutung der einzelnen Komponenten wird in diesem Abschnitt nur überblicksartig skizziert. Eine ausführliche Beschreibung der Architektur für Tutor-Systeme folgt in Kapitel 3.
Jedem Modul wird ein entsprechender Dokumenttyp zugeordnet. Die einzelnen Dokumenttypen werden durch Methoden beschrieben, die den frühen Phasen des SoftwareEntwurfs zugeordnet werden können. Zur Beschreibung von abstrakten Dokumenttypen dienen in diesem Kontext die von Chen [Chen76] entwickelten Entity-Relationsship- Diagramme, die z.B. von Hohenstein und Gogolla [H0G088] zu sogenannten Extended Entüy-Relationsship-Oiagrammen (EER-Diagramme) erweitert wurden.
Auf der Basis des EER-Paradigmas wird der Bereich der Tutor-Systeme nach Dumslaff [Dums94] in eine Drei-Ebenen-Sicht differenziert. Dieses sind
die Ebene der Architektur von Tutor-Systemen, die EER-Schemata zur Beschreibung von Inhalts-, Lerner-, Tutor- und Interaktionsaspekt bereitstellt. Diese allgemeine Sicht auf eine Architektur für Tutor-Systeme wird hier mit Hilfe abstrakter EER-Schemata und zugehörigen Operationen und Prädikaten beschrieben.
die Ebene der Tutor-Systeme, in der mit Hilfe formaler Sprachen als Ausdrucksmittel Inhalte, Lernerdaten, Tutor- und Interaktionsverhalten beschrieben werden. Tutor-Systeme werden durch exemplarische Dokumentsprachen für die einzelnen Module bzw. Dokumenttypen repräsentiert.
die Ebene der Courseware, die konkrete Daten über Inhalte, Lerner, Tutor-Stra- tegien und Interaktionen beinhaltet. Die Courseware-Ebene wird durch konkrete Dokument-Graphen repräsentiert, die unter Zuhilfenahme einer bereits rudimentär entwickelten, eindimensionalen Dokument-Beschreibungssprache mit der Bezeichnung ^°Bs (s. [MeDu94a]) und dem an der Universität Koblenz entwickelten EMS-Graphenlabor (s. [DaEbLi94]) erzeugt werden können.
Die oben herausgestellten Komponenten Inhalts-, Lerner-, Tutor- und Interaktionsmodul der Architektur für Tutor-Systeme werden nun kurz charakterisiert. Der strukturelle Aufbau der einzelnen Module wird in Kapitel 3 ausführlich behandelt.
Das Inhaltsmodul repräsentiert deklaratives und prozedurales Wissen. Das deklarative Wissen setzt sich aus Konzepten und deren Beziehungen untereinander zusammen. Der zugehörige Dokumenttyp wird als Konzept-Dokument bezeichnet. Im Gegensatz dazu beinhaltet prozedurales Wissen Methoden und Verfahren zur Lösung von Problemen und somit zur Erreichung von Zielen. Hierzu gehörende Prozedur-Dokumente werden unterteilt in Daten- und Kontrollfluß-Dokumente sowie in Dokumente für Vor- und Nachbedingungsspezifikationen.
Im Lernermodul wird ein Modell des Lernerwissens bezüglich des im Inhaltsmodul repräsentierten Wissens sowie der vom Lerner zu erreichenden Lern- und Lehrziele erstellt. Im Lernermodell wird festgehalten, welche Inhalte einem Lerner auf welcher Ebene und auf welchem kognitiven Niveau als Wissen zugeordnet werden können. Dies wird durch Lernerprädikate über sogenannten abstrakten Inhaltselementbeschreibungen ausgedrückt. Inhaltselementbeschreibungen dokumentieren Zusammenhänge und Beziehungen zwischen Inhaltselementen des gleichen Typs. Konkrete Inhaltselemente werden durch die im Inhaltsmodul bereitgestellten Dokumenttypen beschrieben.
Das Tutormodul ist für das Erreichen der Lehrziele durch den Lerner verantwortlich. Dazu dient die Beschreibung von Tutor-Regeln über Tutor-Aktionen, erfüllbaren Vorbedingungen und zu erreichenden Effekten. Tutor-Aktionen sind als Lehrhandlungen zu verstehen, die präsentierenden oder interaktiven Charakter haben können. Zu den Vorbedingungen zählt einerseits das beim Lerner a priori vorhandene Wissen (Vorwissen) sowie das durch ausgeführte Tutor-Aktionen erreichte Lernerwissen, das in diesem Kontext auch als Effekt der Tutor-Aktion bezeichnet wird. Eine Möglichkeit der Unterrichtssteuerung durch den Autor ist die Formulierung von Tutor-Strategien über Tutor-Regeln und Inhaltselementbeschreibungen. Als didaktische Mittel legen Tutor-Strategien fest, wann welche Tutor-Aktionen über welchen konkreten Inhaltselementen ausgeführt werden.
Das Interaktionsmodul spezifiziert konkrete Tutor-Aktionen in ihrer operationalen Ausprägung mit Hilfe zustandsorientierter Interaktionsbeschreibungen. Dies geschieht konkret auf der Basis von Statecharts als zugehörigem Dokumenttyp. Zustände stellen hierbei die erwarteten Eingaben des Lerners und die Ausgaben des Tutor-Systems dar. Zustandsübergänge repräsentieren die durch einen Interactions schritt zu erfüllende Erwartung sowie die davon abhängig neu entstehende Erwartungshaltung.
Zusammenfassung
Die konventionellen curriculumorientierten CAI-Systeme besitzen für einen Lerner wenig Möglichkeiten zur Individualisierung von CUU. Eine festgelegte Reihenfolge des Lehrablaufs kann nur in bestimmten Anwendungsfällen vorteilhaft erscheinen, nämlich dann, wenn genau vorgegebene Arbeitsschritte oder Handlungsabfolgen zu vermitteln sind (z.B. zur Konstruktion komplexer mechanischer Baugruppen). In den übrigen Fähen gehen solche programmierten Unterrichtsverläufe auf Kosten der Flexibilität und Adaptivität dieser Systeme.
Eine weitere Schwäche der CAI-Systeme sind die implizit in einen Framepool hineincodierten Inhalte, so daß der Zugriff auf einzelne Unterrichtsinhalte nur über Inhalte der entsprechenden Frames erfolgen kann. ITS lösen dieses Problem durch die explizite Darstellung von Wissen mit Hilfe verschiedener Ansätze der Wissensrepräsentation aus der Künstlichen Intelligenz. Obwohl bei den ITS der Unterrichtsablauf nicht von vornherein festgelegt ist, wird vorhandenes Wissen in Form von Unterrichts-Strategien oder Interaktionsverhalten in zu geringem Umfang für die Unterrichtsgestaltung ausgenutzt. Allerdings findet man hier einen höheren Grad der Individualisierung durch explizite Modellierung und Auswertung des Lernerwissens. Dieser Aspekt wird zwar auch von hypertextbasierten CUU-Systemen berücksichtigt, wirkt sich jedoch nicht auf den Verlauf des Unterrichts aus: der Lerner ist in hohem Maße auf sich allein gestellt; eine Ausnahme stellen die vom Autor vorbereiteten Guided Tours dar, deren Struktur jedoch qualitativ mit derjenigen in CAI-Systemen vergleichbar ist.
In einem wissensbasierten CUU-System ist sowohl eine klare Trennung von Inhalts-, Lerner-, Tutor- und Interaktionskomponente als auch die explizite und domänenunabhängige Repräsentation von Wissen anzustreben. Im Idealfall ist einem Autor darüber hinaus die Möglichkeit der Einflußnahme auf den Unterrichtsverlauf über eine geeignete Autorenschnittstelle zu gewähren. Dies könnte z.B. durch Definition von UnterrichtsStrategien geschehen, die von einem CUU-System abhängig von den Lernfähigkeiten und dem momentanen Wissensstand eines Lerners ausgewählt werden können.
Im folgenden Kapitel werden Struktur und Dokumenttypen der Architektur für Tu- tor-Systeme ausführlicher erläutert. Weiter werden für jedes Modul die relevanten Elemente der Dokument-Beschreibungssprache zur Erzeugung von konkreten Dokumenten dargestellt.
3 Eine Architektur für Tutor-Systeme
Dieses Kapitel gibt einen tiefergehenden Einblick in die Struktur der Architektur für Tutor-Systeme nach Dumslaff [Dums94]. Die einzelnen Module werden durch Erweiterte Entity-Relationship-Diagramme nach einem von Carstensen et al. [CaEbWi93] entwickelten Dialekt[5] beschrieben, welche sich in Anlehnung an den ER-Modellie- rungsansatz von Chen [Chen76] mit ihrer zweidimensionalen Syntax zur Visualisierung der abstrakten Modulstruktur eignen. Die in diesem Kapitel abgebildeten EER- Diagramme der Architektur für Tutor-Systeme wurden im Original aus [Dums94] übernommen.
Zur Beschreibung von konkreten Dokumenten auf der Courseware-Ebene wird eine eindimensionale Sprache eingeführt. Für jedes Modul wird eine deklarative Syntax für die Elemente dieser Dokument-Beschreibungssprache (<D&Bs ) vorgestellt. Ein Autor hat damit die Möglichkeit, konkrete Inhalts-Dokumente zu erzeugen, durch die Definition von Lernerprädikaten ein Lernermodell zu beschreiben und im Tutor- modul darüber Tutor-Regeln zu formulieren. Eingegebene gültige Sprachelemente der 23Oft werden von einem Scanner und einem Parser verarbeitet und in eine äquivalente Graphenrepräsentation der Gesamtarchitektur übersetzt[6]. Die DokumentBeschreibungssprache rDo$s als ein Ausdrucksmittel auf der Ebene der Tutor-Systeme ist somit Bindeglied zwischen der mittels der EER-Schemata definierten abstrakten Struktur der Architektur für Tutor-Systeme und konkreten Dokumenten auf der Ebene der Courseware.
Die einzelnen Dokumente des Inhalts-, Lerner-, Tutor- und Interaktionsmoduls werden im folgenden vorgestellt.
3.1 Das Inhaltsmodul
Dokumente des Inhaltsmoduls dienen zur Repräsentation von deklarativem und proze- duralem Wissen. Deklaratives Wissen umfaßt Konzepte und deren Beziehungen untereinander. Bei der nachfolgenden Repräsentation durch Graphen wird der Bereich des deklarativen Wissens durch Konzept-Graphen abgedeckt. Der zu Konzept-Graphen gehörige Dokumenttyp wird als Konzept-Dokument bezeichnet.
Die prozedurale Wissenskomponente umfaßt die Beschreibung der Strukturen von Methoden und Verfahren, deren Anwendung zur Erreichung von Zielen und insbesondere zur Lösung von Problemen dienen. In der Graphenrepräsentation werden diese Strukturen durch Datenfluß-, Pre-Post- und Kontrollfluß-Graphen ausgedrückt. Diese Unterteilung wurde vorgenommen, um der datenflußorientierten Sicht, der zielorientierten Sicht und der kontrollfiußorientierten Sicht auf prozedurales Wissen gerecht zu werden. Im folgenden werden Dokumente für prozedural zu repräsentierendes Wissen als Prozedur-Dokumente zusammengefaßt.
Die durch Konzept- und Prozedur-Graphen repräsentierten Inhalts-Dokumente für die Repräsentation deklarativen und prozeduralen Wissens werden durch EER-Schemata strukturell beschrieben. Zur Beschreibung von Inhaltselementen stehen einem Autor Sprachelemente auf der Ebene der Dokumentbeschreibungs-Sprache zur Verfügung. Die zugehörigen Sprachelemente werden jeweils nach der strukturellen Beschreibung der Dokumenttypen des Inhaltsmoduls vorgestellt. Der folgende Abschnitt behandelt die Konzept-Dokumente.
3.1.1 Konzepte
Konzepte und deren Beziehungen untereinander werden in Konzept-Dokumenten deklarativ beschrieben. Konzept-Dokumente werden strukturell durch das in Abbildung 3.1 gezeigte EER-Schema charakterisiert.
Unter einem Konzept versteht man eine Menge von gleichartigen Objekten, Symbolen oder Ereignissen. Konzepten können charakteristische Merkmale, Attribute genannt, zugeordnet werden. Jedes Attribut besitzt einen Wertebereich, der festlegt, welche Werte ein Attribut annehmen kann.
Einem Konzept wird in der Graphenrepräsentation jeweils ein concept-Knoten zugeordnet. Attribute von Konzepten werden durch attribute-Knoten repräsentiert, die durch has Attribut e-Kanten mit den concept-Knoten verbunden sind. Der Wertebereich eines Attributs wird durch den Inhalt eines exprea-siora-Knotens ausgedrückt, der dem Attribut durch eine hasDomain-Kante zugeordnet wird.
Es sind insbesondere auch Aggregationen und Gruppierungen von Konzepten möglich. Eine Aggregation bedeutet in diesem Kontext die Zusammensetzung eines neuen Konzepts aus mehreren Einzelkonzepten, bei der Gruppierung handelt es sich um die Konstruktion eines Konzepts aus Listen von Exemplaren eines anderen Konzepts. Durch Generalisierung können gemeinsame Merkmale verschiedener Konzepte in einem Konzept zusammengefaßt werden. In der Graphenrepräsentation sind für Aggregationen und Gruppierungen jeweils die Knotentypen aggregation und group vorgesehen, welche
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.1: EER-Diagramm zur abstrakten Repräsentation von Konzept-Dokumenten (aus [Dums94, S.72])
Subtypen von Knoten des Typs concept darstellen. Eine Kante vom Typ generalizes drückt die Generalisierungsbeziehung eines Konzepts über einem anderen Konzept aus.
Konzepte können ferner in (binären) Beziehungen zueinander stehen [Dums94, s.S. 68]. Dort können den beteiligten Konzepten Rollen zugeordnet werden. Durch die Angabe von Kardinalitäten kann festgehalten werden, wieviele Konzeptexemplare an einer Beziehung oder an einer Aggregation bezüglich eines anderen gegebenen Konzepts beteiligt sind. Einer Rolle wird in der Graphenrepräsentation ein eigener Knotentyp role mit einer zum entsprechenden concept-Knoten gerichteten hasRole-Kante zugeordnet. Weiter kann eine Kante vom Typ isRoleln von einem role-Knoten zu einem Beziehungs-Knoten vom Typ relationship hinführen. Kardinalitäten von Rollen werden über has Cardinality-Kanten vom role-Knoten hin zum expression-Knoten repräsentiert.
Die bereits beschriebenen Knotentypen aggregation und group stehen ebenfalls mit dem role-Knoten über sich gegenseitig ausschließende aggregatesTo- bzw. groups To-Kanten in Verbindung.
Schließlich sind noch zwei weitere Generalisierungen in Abbildung 3.1 zu erläutern. Der Entity-Typ conceptOrRelationship umfaßt als Obertyp die beiden Typen concept und relationship und der Entity-Typ CRItem ist eine Generalisierung der Typen conceptOrRelationship, role und attribute.
Bevor die Sprachelemente der zur Beschreibung von Konzept-Dokumenten aufgelistet und erläutert werden, werden folgende syntaktischen Konventionen zur Notation vereinbart:
- Alle Worte, die von der Sprache erkannt werden, sind in Typewriter-Font angegeben.
- In spitzen Klammern werden dabei Variablen dargestellt, denen beliebige Namensbezeichner bzw. Expressions zugeordnet werden können. Für die Variablen a, b, c, d, g, i, p, s, si, so, t, r sind dabei beliebige Zeichenketten einsetzbar, die Variablen e sind als Expressions, bestehend aus einem Vergleichsoperator und einer natürlichen Zahl inklusive Null, angebbar.
- Angaben in eckigen Klammern ([,]) sind optional (null oder einmaliges Vorkommen), diejenigen in geschweiften Klammern ({, }) deuten auf eine Iteration hin (null oder mehrmaliges Vorkommen), ein senkrechter Strich weist auf eine Alternative hin.
Für die in diesem Bericht vorgeschlagene Dokument-Beschreibungssprache wird für die eindeutige Identifikation von Entities jeder Bezeichner nur einmal vergeben, d.h. eine Mehrfachverwendung von gleichen Bezeichnern für verschiedene Entities ist nicht vorgesehen. Das Einfügen neuer Beziehungen zwischen bereits existierenden Entities ist dagegen erlaubt.
Dobs für Konzept-Dokumente
Mit Hilfe der nachfolgend aufgeführten “DoBs -Sprachelemente können Konzept-Dokumente beschrieben werden.
<c> is concept
beschreibt ein Konzept mit der Bezeichnung c.
concept <c> is generalization of concept <a>
{ and of concept <b> }
beschreibt eine Generalisierungsbeziehung eines Konzepts c über einem Konzept a. Eine Generalisierung ist auch über mehr als einem Konzept möglich.
<a> is aggregation
of concept <cl> in role <rl> [ with card <el> ]
{ and of concept <c2> in role <r2> [ with card <e2> ] }
beschreibt eine Aggregation mit der Bezeichnung a[7] über einem Konzept cl in der Rolle rl und der Kardinalität el. Die Angabe von Kardinalitäten ist dabei optional. Default-Einstellung ist die Kardinalität n. Kardinalitätsinformationen werden als Expressions ausgedrückt. Die zugehörigen Aggregations-, Rollen- und Kardinalitätsbeziehungen zwischen den beteiligten Entity-Typen werden automatisch hergestellt. Eine Aggregation kann aus mehr als zwei Konzepten bestehen.
<g> is group of concept <c> in role <r>
beschreibt eine Gruppierung mit der Bezeichnung g[8] über einem Konzept c in der Rolle r. Die Beziehung zwischen der Gruppierung g und dem Konzept c wird automatisch hergestellt.
<r> is relationship
between concept <cl> in role <rl> [ with card <el> ] and concept <c2> in role <r2> [ with card <e2> ]
beschreibt eine Beziehung mit der Bezeichnung r zwischen den beiden Konzepten cl und c2, wobei die Konzepte mit den jeweiligen Rollen rl und r2 und Kardinalitäten el und e2 erzeugt werden. Die zugehörigen Rollen- und Kardinalitätsbeziehungen zwischen den beteiligten Entity-Typen werden automatisch hergestellt.
<a> is attribute of relationship <r> with domain <d>
beschreibt ein Attribut mit der Bezeichnung a und dem Wertebereich d für eine Beziehung r.
<a> is attribute of concept <c> with domain <d>
beschreibt analog zum vorhergehenden Sprachelement ein Attribut a mit einem Wertebereich d für ein Konzept c.
Das folgende und die nachfolgenden Beispiele für konkrete Dokumente der einzelnen Graphklassen beziehen sich auf das im Rahmen einer CASE[9] -Studie spezifizierte CAVIAR[10] -System nach Flinn und S0rensen [F1S087]. Die Originalbeschreibung von CAVIAR wurde in der Spezifikationssprache Z> [Spivey89] vorgenommen und stellt das Ergebnis einer Analyse der konventionellen Vorgehensweise bei der Verwaltung von Personen- und Veranstaltungsdaten dar, die bei geschäftlichen Zusammenkünften und Seminaren an größeren Industriestandorten anfallen. Die CAVIAR-Spezifikation sollte dazu verwendet werden, die Durchführbarkeit einer computergestützten Lösung eines solchen Buchungs- und Retrieval-Systems zu untersuchen.
Das folgende Beispiel behandelt die Struktur eines Graphen zur Repräsentation einer Hotel-Room—Kťáiťor-Beziehung {HR-V-Relationship). Diese Beziehung ist als Subsystem des CAVIAR-Systems definiert (s. [F1S087, S.159fi]).
Beispiel 3.1 (Konzept-Graph für HR-V-Relationship)
Abbildung 3.2 zeigt den Graphen für die Konzeptstruktur der Beziehung zwischen zu verbuchenden Hotelzimmern und Gästen bei der Reservierung von Unterkünften im Rahmen von Seminar Veranstaltungen.
Abbildung in dieser Leseprobe nicht enthalten
In einer Яй-F-Beziehung wird jeder Person in einer l:l-Beziehung ein Zimmer zugeordnet. Dabei übernimmt ein Konzept Person die Rolle des Gastes und ein Konzept Room die Rolle des Hotelzimmers. Eine Zimmerreservierung kann nur für einen bestimmten Zeitpunkt erfolgen, der durch das Datum der Buchung festgelegt ist. Der Termin date für die Zimmerreservierung wird als Attribut der HR- V-Beziehung mit dem Datumsformat dd.mm.yyyy behandelt, welcher in das aktuelle Tagesdatum dd, das Monatsformat mm und das Jahresformat yyyy aufgeteilt ist. Der konkrete Wertebereich für die Datumsangabe orientiert sich an den allgemeingültigen Konventionen für zweistellige Tages- und Monatszahlen sowie vierstellige Jahreszahlen.
Das Konzept-Dokument für den in Abbildung 3.2 dargestellten Konzept-Graphen läßt sich mittels der Dokument-Beschreibungssprache rD°ßs wie folgt festhalten[11]:
HR-V-Relationship is relationship
between concept Person in role Visitor with card =1 and concept Room in role Hotel-Room with card =1
date is attribute of relationship SR-V-Relationship with domain dd.mm.yyyy
3.1.2 Prozeduren
Die im folgenden beschriebenen Dokumenttypen Datenfluß-, Pre-Post- und Kontroll- fluß-Dokumente sind zur Beschreibung prozeduralen Wissens geeignet. Sie dienen der strukturellen Beschreibung von Vorgehensweisen und Methoden zur Zielerreichung. Zunächst werden Datenfluß-Dokumente vorgestellt.
Datenfluß-Dokumente
Datenfluß-Dokumente dienen zur Beschreibung prozeduralen Wissens, indem sie die hierarchische Zerlegung einer Methode oder eines Verfahrens, welches durch einen Entity-Typ procedure ausgedrückt wird, in Teilschritte repräsentieren. Abbildung 3.3 zeigt das EER-Schema zur abstrakten Repräsentation von Datenfluß-Dokumenten.
Abbildung in dieser Leseprobe nicht enthalten
Der Entity-Typ DFItem stellt eine Generalisierung der Typen procedure und dem weiter unten erläuterten Typ datastore dar. Prozeduren können mittels weiterer Prozeduren verfeinert werden. Dies wird in der Graphenrepräsentation durch eine isRefinedBy- Beziehung zum Typ procedure ausgedrückt. Einer Prozedur können einerseits durch eine isSpecifiedBy-Kante eine Spezifikation eines Pre-Post-Dokuments (specification) und andererseits über eine ieOperationalizedBy-Kante ihre operationale Beschreibung über ein entsprechendes Kontrollfluß-Dokument (statement) zugeordnet werden. PrePost- und Kontrollfluß-Dokumente werden im einzelnen noch behandelt.
Beziehungen zwischen Ein- und Ausgabedaten können mittels Datenflüssen und Datenspeichern dargestellt werden. Datenspeicher werden durch den Entity-Typ da- tastore, Datenflüsse durch den Entity-Typ dataflow repräsentiert. Kanten vom Typ sink verbinden den Entity-Typ DFItem mit eingehenden Datenflüssen und sourceKanten verbinden diesen Knoten mit ausgehenden Datenflüssen.
Die Strukturen von Ein- und Ausgabedaten werden durch die oben beschriebenen Konzept-Dokumente zur Verfügung gestellt. Der Bezug zu den Konzept-Dokumenten erfolgt durch zu datastore- bzw. dataflow-Knoten gehörige Kanten vom Typ hasDo- main, die auf einen Entity-Typ value gerichtet sind. Dieser valuer-Typ ist wird in Abbildung 3.4 weiter verfeinert in die bereits aus Konzept-Dokumenten bekannten Entity-Typen expression und CRItem (vgl. Abbildung 3.1).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.4: Spezialisierung von value durch expression und CRItem (aus [Dums94, S.83])
DOBs für Datenfluß-Dokumente
Für die Beschreibung von Datenfluß-Dokumenten sind folgende Dcrßs -Elemente vorgesehen: <p> is procedure
beschreibt eine Prozedur mit der Bezeichnung p.
<d> is datastore
beschreibt einen Datenspeicher mit der Bezeichnung d.
procedure <p> is operationalized by statement <s>
beschreibt eine Prozedur p sowie ein Statement s eines Kontrollfluß-Dokuments (s.S.26) und stellt eine isOperationalizedBy-Beziehung zwischen der Prozedur p und deren Operationalisierung s her.
procedure <p> is specified by prePostSpec <s>
beschreibt eine Prozedur p sowie deren Pre-Post-Spezifikation s und stellt eine is Specified!} y-Bezieh.ung zwischen Prozedur p und deren Vor- und Nachbeding- ungs-Spezifikation s her.
procedure <pl> is refined by procedure <p2>
beschreibt zwei Prozeduren pi und p2 und stellt eine isRefinedBy-Beziehung zwischen der durch Prozedur p2 verfeinerten Prozedur pl her.
<d> is dataflow
from [ procedure | datastore ] <so> to [ datastore I procedure ] <si> with domain [ expression I CRItem] <c>
beschreibt einen Datenfluß mit der Bezeichnung d und die source-Beziehung zu Prozeduren oder Datenspeichern mit der Bezeichnung so als Quelle. Uber eine áíraÄ-Beziehung wird der Datenfluß d mit einem Datenspeicher oder einer Prozedur si verbunden[12]. Einem Datenfluß d wird über eine hasDomain-Beziehnng eine Expression oder ein CRItem c aus einem Konzept-Dokument als Wertebereich zugeordnet[13].
Beispiel 3.2 (Datenfluß-Graph zur Prozedur Book-Sotel-Room)
In Abbildung 3.5 ist der Graph für die Datenflußstruktur einer Prozedur Book-Sotel- Room für eine Hotelzimmerbuchung dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Der Eingabe-Datenfluß besteht hierbei aus den mittels eines Eingabegerätes {Input Terminal) abgeschickten Buchungsdaten {ER- V-InData), die der Konzeptstruktur der HR-V-Beziehung genügen müssen (s. Abbildung 3.2, S.18). Die Prozedur Book-Hotel- Room wandelt die Eingabedaten in ein internes Datenformat {ER- V-OutData) um und legt es in einem ER-F-Subsystem ab. Die internen Daten sowie das ER-F-Subsystem genügen dabei ebenfalls der Konzeptstruktur der HR- F-Beziehung.
Der in Abbildung 3.5 gezeigte Datenfluß-Graph zur Prozedur Book-Hotel-Room läßt sich als Datenfluß-Dokument durch die Dcrßs folgendermaßen ausdrücken:
Book-Hotel-Room is procedure
Input-Terminal is datastore
HR-V-Subsystem is datastore
HR-V-InData is dataflow
from datastore Input-Terminal to procedure Book-Hotel-Room with domain CRItem HR-V-Relationship
HR-V-OutData is dataflow
from procedure Book-Hotel-Room to datastore HR-V-Subsystem with domain CRItem HR-V-Relationship
Pre-Post—Dokumente
Pre-Post-Dokumente dienen zur Spezifikation von Ausgangssituationen und Zielsituationen eines Verfahrens oder einer Methode. Die Ausgangssituation einer Prozedur wird in Form einer Vorbedingung, die Zielsituation in Form einer Nachbedingung beschrieben. In Abbildung 3.6 ist die abstrakte Repräsentation eines Pre-Post- Dokuments als EER-Schema dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.6: EER-Diagramm zur abstrakten Repräsentation von Pre-Post- Dokumenten (aus [Dums94, S.84])
Vor- und Nachbedingungen - auch Pre- und Post-Conditions genannt - werden über ein- bzw. ausgehende Daten als Prädikate entweder formal oder natürlichsprachlich spezifiziert. Dazu werden in der Graphenrepräsentation Spezifikationsknoten des Typs prePostSpec über isPreCond- und isPostCond-Kanten mit Knoten des Typs predicate verbunden.
DoBs für P re-Post-Doku mente
Folgende Dcrgs -Elemente werden für die Beschreibung von Pre- Post-Dokumenten zur
Verfügung gestellt:
<p> is predicate with <t>
beschreibt ein Prädikat mit der Bezeichnung p und dessen textueller Beschreibung t.
predicate <p> is preCond of prePostSpec <s>
beschreibt eine Vorbedingungsbeziehung des Prädikats p zur Pre-Post-Spezifikation s. Falls das Prädikat p noch nicht definiert ist, muß es mittels des vorhergehenden Sprachkonstrukts beschrieben werden.
predicate <p> is postCond of prePostSpec <s>
beschreibt analog zum voherigen Sprachelement eine Nachbedingungsbeziehung eines Prädikats p zu einer Pre-Post-Spezifikation s.
Beispiel 3.3 (Pre-Post-Graph zur Prozedur Book-Hotel-Room)
In Abbildung 3.7 ist die Graphstruktur für ein Pre-Post-Dokument der Prozedur Book- Hotel-Room dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.7: Pre-Post-Graph zur Prozedur Book-Hotel-Room
Bevor die Vor- und Nachbedingungen der Pre-Post-Spezifikation für die Buchungsprozedur Book-Hotel-Room angegeben werden, wird eine Funktion tu eingeführt, die die Abhängigkeiten zwischen den Parametern T (Time), R (Resource) und U (User) eines allgemeinen Resource-User-Sy stems bzw. R-U-Systems (s. [F1S087, S.148ff]) wie folgt definiert:
ru : T -> {R «-> U)
Der Parameter T steht dabei für eine Menge von Zeitabschnitten (time slots). R ist die Menge der benutzten Ressourcen, welche im HR-V-Subsystem die Hotelzimmer repräsentieren. Die Menge U entspricht den Nutzern einer zur Verfügung gestellten Ressource. Nutzer sind in diesem Falle die Hotelgäste. Die Funktion ru ordnet somit einem Zeitabschnitt t G T eine Menge von Resource-User-Paaren zu, deren Elemente r € R und u G U in der Relation R *-+ U enthalten sind.
Ein HR- V-Subsystem kann als ein System definiert werden, in dem ein Nutzer и maximal eine unteilbare Ressource r für einen Zeitraum t belegt (vgl. [FIS087, S.156]). Um dies zu gewährleisten, müssen für die Buchungsprozedur Book-Hotel-Room des SR- V-Systems die im folgenden beschriebenen Vor- und Nachbedingungen festgelegt werden. Das folgende Schema in der Spezifikationssprache Z dokumentiert diese Eigenschaften eines solchen ЯД-V-Subsystem als Resource-User-System (vgl. [F1S087, S.149, 154fl]).
Abbildung in dieser Leseprobe nicht enthalten
Mit dem folgenden Z-Schema (s. [F1S087, S.150]) werden die gemeinsamen Eigenschaften eines durch eine beliebige Operation veränderten R-U-Systems beschrieben. Das Schema beinhaltet einen Ausgangszustand R- U-System, der alle oben beschriebenen Eigenschaften besitzt, einen Folgezustand R-U-System', der nach der Operationsanwendung gilt sowie eine Menge von Zeitabschnitten als Eingabe. Als Bedingung wird hier gefordert, daß die Abbildung ru durch Anwendung gültiger Operationen auf einem R-U-System nicht berührt wird, bis auf Elemente des Domains ť?.
Abbildung in dieser Leseprobe nicht enthalten
Eine Buchungsoperation Book-Hotel-Room auf einem R-U-System gestaltet sich dann
unter Angabe der Vor- und Nachbedingungen (PreCond, PostCond) folgendermaßen (vgl. [F1S087, S.154ÍT]):
Abbildung in dieser Leseprobe nicht enthalten
Die Vorbedingung PreCond der zur Buchungsprozedur Book-Hotel-Room gehörenden Pre-Post-Spezifikation stellt sicher, daß für den gewünschten Reservierungszeitraum ť? weder das Hotelzimmer r? noch der Gast u? im Buchungssystem zugeteilt worden ist. Der eingegebene Reservierungszeitraum i? entspricht hierbei einer Instanz hrv des Konzepts HR-V-Relationship (s. Abbildung 3.2) mit ť? = hrv?.date, das Eingabedatum für die Zimmerreservierung entspricht r? = hrv?.Hotel-Room und die Eingabeinformation für den Gast wird durch u? = hrv?. Visitor ausgedrückt.
Das Prädikat der Nachbedingung PostCond sagt aus, daß die neue Zimmerreservierung r? zum gewünschten Zeitraum t? für den Gast u? im aktuellen Buchungsbestand ru'(i) enthalten ist.
Das entsprechende Pre-Post-Dokument zum Pre-Post-Graphen aus Abbildung 3.7 kann durch die wie folgt beschrieben werden:
Abbildung in dieser Leseprobe nicht enthalten
Der Bezug des Pre-Post-Dokuments zum Datenfluß-Dokument der Prozedur Book- Hotel-Room in Beispiel 3.2 wird durch folgendes DoBs -Konstrukt hergestellt: procedure Book-Hotel-Room is specified by prePostSpec ррз_Воок
Kontrollfluß-Dokumente
In Ergänzung zu den Datenfluß- und Pre-Post-Dokumenten bieten Kontrollfluß-Dokumente eine operationale Beschreibung von Prozeduren oder Verfahren. Das EER- Schema zur abstrakten Repräsentation von Kontrollfluß-Dokumenten zeigt Abbildung 3.8.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.8: EER-Diagramm zur abstrakten Repräsentation von Kontrollfluß-Dokumenten (aus [Dums94, S.85])
Verfahren können bezüglich der durchzuführenden Schritte und deren Reihenfolge — auch abhängig von eventuell zu treffenden Entscheidungen — beschrieben werden. Die im folgenden verwendeten elementaren Bausteine von Kontrollfluß-Dokumenten sind die elementare Anweisung, die Sequenz, die Alternative und die Iteration. In der Graphenrepräsentation werden diese Komponenten durch entsprechende Knoten mit den Entity-Typen basic Statement, statements equence, statementAlternation und statementIteration dargestellt. Eine Generalisierung der genannten Knotentypen stellt der Entity-Typ statement dar.
Elementaren Anweisungen können Operationen wie Zuweisungen oder das Ein- und Auslesen von Daten zugeordnet werden. Dies wird durch eine Kante vom Typ op von einem basic Statement-Knoten zu einem operation- Knoten ausgedrückt. Weiter können elementaren Anweisungen Speicherelemente, die durch ¿rora^e-Knoten repräsentiert werden, und Ausdrücke, Konzepte oder Relationen zugeordnet werden, welche durch den bereits aus den Konzept-Dokumenten bekannten Entity-Typ value repräsentiert werden (s. Abbildung 3.4). Die Kantentypen store und val verbinden storage- und value-Knoten jeweils mit einem basicStatement-Knoten.
Kanten vom Typ seq an einem statements equence- Knoten drücken eine Ausführungsreihenfolge von Anweisungen des statement-Typs aus. Eine Alternative ist als Aggregation aus einer Bedingung, einer Anweisung, die im Fall der erfüllten Bedingung ausgeführt wird und einer Anweisung, die bei nicht erfüllter Bedingung ausgeführt wird, dargestellt. Dieser Sachverhalt wird in der Graphenrepräsentation durch eine Kante vom Typ condition zu einem predicate-Knoten und durch jeweils eine truePart- und false Part-Kante zu einem statement- Knoten beschrieben. Die Iteration ist als Aggregation aus einer Bedingung und einem Anweisungsteil modelliert. Die Graphenrepräsentation stellt hierzu eine condition-Kante zu einem predicate-Knoten sowie eine èodÿ-Kante zu einem statement-Knoten zur Verfügung.
Dops für Kontrollfluß-Bokumente
Folgende Sprachelemente der DoBs dienen zur Beschreibung von Kontrollfluß-Doku- menten:
<s> is basic statement with <t>
beschreibt eine elementare Anweisung mit der Bezeichnung s und ordnet dieser die textuelle Beschreibung t zu. Einfache Anweisungen werden hier textuell, z.B. als Wertzuweisung, als Prozeduranweisung oder als natürlichsprachliche Anweisung notiert.[14]
<s> is sequence with statement <sl>
{ and statement <s2> }
beschreibt eine Anweisungssequenz mit der Bezeichnung s bestehend aus den Anweisungen sl und s2. Eine Sequenz darf aus endlich vielen Anweisungen bestehen, deren Anordnung die Ausführungsreihenfolge repräsentiert. Eine Anweisung kann wiederum eine elementare Anweisung, eine Anweisungssequenz, eine Anweisungsaltemative oder eine Iteration sein.
<i> is iteration with
while condition <c> [ with <t> ] do statement <s> od
beschreibt die Iteration einer Anweisung mit der Bezeichnung i. Solange die Bedingung c mit der Beschreibung t erfüllt ist, wird die Anweisung s ausgeführt. Hierbei darf als Bedingung auch ein bereits in einem Pre-Post-Dokument beschriebenes Prädikat verwendet werden.
<a> is alternation with
if condition <c> [ with <t> ] then statement <sl>
C else statement <s2> ] fi beschreibt eine Anweisungsalternative mit der Bezeichnung a. Falls die Bedingung c mit der Beschreibung t erfüllt ist, wird die Anweisung sl ausgeführt, im anderen Falle wird die Anweisung s2 ausgeführt. Als Bedingung darf ein bereits beschriebenes Prädikat verwendet werden. Der e/se-Fall ist hier optional.
Den Komponenten elementare Anweisung, Sequenz, Alternative und Iteration von Kontrollfiuß-Dokumenten werden hier eindeutige Bezeichner zugeordnet, um diese später als “Makros“ ansprechen zu können (s. Έ>°Β$ -Darstellung in Beispiel 3.4).
Beispiel 3.4 (Kontrollfluß-Graph zur Prozedur Book-Hotel-Room)
Abbildung 3.9 zeigt die Graphstruktur für das Kontrollfluß-Dokument der Prozedur Book-Hotel-Room aus Beispiel 3.2.
Abbildung in dieser Leseprobe nicht enthalten
Die Buchungs-Prozedur Book-Hotel-Room besteht aus einer vierteiligen Anweisungssequenz bookSeq. Die ersten drei Anweisungen inputDate, inputRoom und inputPerson dienen dem Einlesen der zu buchenden Termin-, Hotelzimmer- und Personendaten. Diese Eingabedaten genügen den in Beispiel 3.3 eingeführten Instanzen einer HR-V- Beziehung
Abbildung in dieser Leseprobe nicht enthalten
welche sich auf das zugehörige Konzept-Dokument in Abbildung 3.2 auf Seite 18 beziehen. Das vierte Element der Anweisungssequenz ist die Anweisungsalternative book Op. Die òoofc-Anweisung innerhalb der Anweisungsalternative bookOp wird ausgeführt, falls die Bedingung preBook erfüllt ist. Die Bedingung preBook entspricht dem Prädikat PreCond des Pre-Post-Dokuments in Beispiel 3.3. Bedingung für eine korrekte Buchung ist, daß das eingelesene Resource-User-Paar (rl,u1) für das Eingabedatum tl noch nicht in der Resource-User-Relation tu enthalten ist. Falls diese Vorbedingung nicht erfüllt ist, wird keine Buchung vorgenommen und somit die leere Operation NullOp ausgeführt. Die Buchungsoperation book selbst bewirkt für das Eingabedatum t? die Aufnahme des eingegebenen Paares (r?,u?) in die Resource-User-Relation tu.
Das mit Abbildung 3.9 korrespondierende Kontrollfluß-Dokument kann durch die fDo&s beschrieben werden:
Abbildung in dieser Leseprobe nicht enthalten
Der Bezug des Kontrollfluß-Dokuments zu dem Datenfluß-Dokument für die Prozedur Book-Hotel-Room wird durch folgendes D&Bs -Konstrukt hergestellt:
Abbildung in dieser Leseprobe nicht enthalten
Mit Hilfe der oben erläuterten Sprachkonstrukte zur Beschreibung von Konzept-, Datenfluß-, Pre-Post- und Kontrollfluß-Dokumenten können Inhalts elemente spezifiziert werden. Diese stellen die syntaktischen Bestandteile dar, aus denen konkrete Inhalts-Dokumente zusammengesetzt sind. Inhaltselemente werden als Argumente von Lernerprädikaten benötigt, um das Wissen eines Lerners zu modellieren. Die Bedeutung und der strukturelle Aufbau des Lernermoduls wird im folgenden beschrieben.
3.2 Das Lernermodul
Im Lernermodul werden den im Inhaltsmodul beschriebenen Inhalts elementen Informationen über einen Lerner zugeordnet. Dies geschieht durch Lernerprädikate. Sie beziehen sich auf Inhaltselementbeschreibungen zur expliziten Erfassung von inhaltlichen Beziehungen zwischen Inhaltselementen. Das Lernermodul repräsentiert den aktuellen Wissensstand eines Lerners durch erfüllte oder nicht erfüllte Lernerprädikate über Inhaltselementbeschreibungen. Mit Hilfe von Lernerprädikaten, die bezüglich Inhaltselementen als erfüllt repräsentiert sind, ist ferner das Vorwissen eines Lerners modellierbar. Die von einem Lerner zu erreichenden Lehrziele lassen sich durch noch nicht erfüllte Lernerprädikate bezüglich konkreten Inhaltselementen ausdrücken. Eine abstrakte Repräsentation des Lernermodells wird durch das EER-Schema in Abbildung 3.10 dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.10: EER-Diagramm zur abstrakten Repräsentation des Lernermodells (aus [Dums94, S.103])
Lernerprädikate
Lernerprädikate vom Entity-Typ LearnPred sind über einen Bezeichner, ihren Ler- nerprädikatstyp und eine Inhaltselementbeschreibung definierbar. Sie sind in der Graphenrepräsentation daher als eine Aggregation aus Lernerprädikatstypen Lp Type und Inhaltselementbeschreibungen conltems beschrieben[15]. Es wird exemplarisch in zwei Typklassen von Lernerprädikaten unterschieden: Lernerprädikate mit Bezug zu kogni- tiven Zuständen eines Lerners und Lernerprädikate mit Bezug zu Präsentations- und Interaktionsformen von Inhaltselementen. Diese Lernerprädikatstypen werden in der abstrakten Repräsentation jeweils durch die Entity-Typen LPK und LPP dargestellt.
Inhaltselementbeschreibungen
Die Beschreibung von Inhaltselementen fußt auf den strukturellen Eigenschaften von Inhalts-Dokumenten, die über das Bindeglied der Dokument-Beschreibungssprache ^°Bs intern in einer Graphenrepräsentation verwaltet werden. Inhaltselementbeschreibungen können als Teile dieser Graphstruktur durch reguläre Pfadausdrücke spezifiziert werden. Der induktive Aufbau von regulären Pfadausdrücken wird in [EbFr92] beschrieben. Im folgenden wird zwischen direkt und abgeleitet beschriebenen Inhaltselementen unterschieden.
Direkte Inhaltselementbeschreibungen — Diese werden über den jeweiligen Inhaltselementetyp (vgl. SMItem in Abbildung 3.10) beschrieben, z.B. ein Konzept oder eine Prozedur. Eine Menge von direkt beschriebenen Inhaltselementen sind z.B. alle Rollen oder alle Datenspeicher.
Abgeleitete Inhaltselementbeschreibungen — Solche stehen in Beziehung zu anderen Inhaltselementen (vgl. conltems in Abbildung 3.10) und werden über diese Beziehung spezifiziert, z.B. die Rolle, die ein Konzept einnimmt oder die Attribute eines Konzepts. Letzteres Beispiel umschreibt eine Menge von abgeleiteten Inhaltselementen, die alle den gleichen Typ besitzen müssen.
Um das Ergebnis bzw. die Ergebnismenge insbesondere von abgeleiteten Inhaltselementbeschreibungen zu erhalten, werden geeignete Operatoren definiert (s. [Dums94, S.94f]), die ausgehend von einem Referenz-Inhaltselement alle diejenigen Inhaltselemente bestimmen, die über die durch reguläre Pfadausdrücke spezifizierten Pfade erreichbar sind. Das Referenz-Inhaltselement ist hierbei das Argument des zuerst angewendeten Operators in einer geschachtelten Operatorsequenz. Wie die Evaluierung einer geschachtelten Operatorsequenz erfolgt, wird am folgenden Beispiel gezeigt.
[...]
[1] Ein Überblick über die Historie und eine kurze Einführung in CAI-Systeme findet sieb in [Bitzer76].
[2] ReGIS steht für Remote Graphics Instruction Set
[3] In einem UND/ODER-Graphen wird durch UND-Knoten die Konjunktion und durch ODERKnoten die Disjunktion der zur Lösung einer Aufgabe notwendigen Vorkenntnisse (bzw. bereits erfolgreich gelöste Aufgaben) bezeichnet.
[4] In CAI-Systemen ist das Wissen implizit in den Frames abgelegt und der Zugriff darauf kann nur über die Inhalte in den entsprechenden Frames erfolgen.
[5] Die Grundlagen für diesen Dialekt stammen aus [Winter92]
[6] Für eine weiterführende Dokumentation zur Implementation der Architektur für Tutor-Systeme wird auf [MeDu94b] und zur Dokumentation der Dcrgs auf [MeDu94a] verwiesen.
[7] Falls schon ein Konzept mit der Bezeichnung a existiert, wird dieses in eine Aggregation verfeinert bzw. umtypisiert. Eine Aggregation stellt eine Spezialisierung eines Konzepts dar (s. Abbildung 3.1).
[8] Falls schon ein Konzept mit der Bezeichnung g existiert, wird dieses in eine Gruppierung verfeinert bzw. umtypisiert. Eine Gruppierung stellt eine Spezialisierung eines Konzepts dar (s. Abbildung 3.1).
[9] CASE ist eine Abkürzung für Computer Aided Software Engineering
[10] CAVIAR steht für Computer Aided Visitor Information And Retrieval
[11] Entity-Bezeichner, die keine Spracheiemente der 'DoBs sind, werden hier und bei den folgenden Anwendungsbeispielen kursiv notiert.
[12] AIs zusätzliche Invariante ist bei der internen Graphenrepräsentation zu gewährleisten, daß keine zwei Datenspeicherknoten mit source- und sink-Kanten über einen Datenflußknoten verbunden werden.
[13] Invariant ist ebenfalls die Zuordnung desselben Wertebereichs zu zusammengehörigen Datenflüssen und -speichern.
[14] Die op- und sťore-Beziehungen fallen mit den entsprechenden Knotentypen operation und storage (vgl. Abbildung 3.8) in dieser Implementation weg. Dieser Kompromiß muß in der verwendeten Version 2.0 des EMS-Graphenlabors aufgrund der restriktiven Behandlung bezüglich der Anzahl von Knoten- und Kantentypen, realisiert durch jeweils maximal 32 verschiedene Flags, eingegangen werden (vgl. [DaEbLi94, S.68ff]).
[15] Die mit einem Oberstrich versehenen Bezeichner in EER-Diagrammen repräsentieren formale Parameter allgemeiner Beschreibungen. So deutet z.B. der Rollenbezeichner IpArgument in Abbildung 3.10 auf eine Inhaltselementbeschreibung conltems mit einem direktem Inhaltselement SMItem als formaler Parameter eines Lernerprädikate vom Entity-Typ LearnPred hin. Somit findet hier eine Partitionierung des Typs SMItem in formale Parameter und konkrete Inhaltselemente statt (vgl. [Dums94, S.103]).
- Citar trabajo
- Markus Mertesacker (Autor), 1995, Aspekte des Planens im Computerunterstützen Unterricht, Múnich, GRIN Verlag, https://www.grin.com/document/207707
