DE69938508T2

DE69938508T2 - System, methode und bauteil eines simulationsgestützten rückkoppelungssystems

Info

Publication number: DE69938508T2
Application number: DE69938508T
Authority: DE
Inventors: Benoit Patrick Brossard BERTRAND; Alexander Middletown ZORBA; Jonathan Christian Worcester CONANT
Original assignee: Accenture Global Services GmbH
Current assignee: Accenture Global Services GmbH
Priority date: 1998-12-22
Filing date: 1999-02-08
Publication date: 2009-05-07
Anticipated expiration: 2019-02-09
Also published as: EP1141927B1; US6658398B1; US6493690B2; AU3288099A; TW473669B; ATE391983T1; DE69938508D1; WO2000038152A1; EP1141927A1; US20020069189A1; US6029158A

Description

Gebiet der Erfindung
Die Erfindung bezieht sich auf ein Verfahren, das ein Computergerät zur Schaffung eines Unterrichtssystems gemäß dem Oberbegriff von Anspruch 1 verwendet, und ein Computergerät zur Schaffung eines Unterrichtssystems gemäß dem Oberbegriff von Anspruch 10.
Hintergrund der Erfindung
Beim Aufbau eines wissenbasierten Systems oder Expertensystems sind zumindest zwei Disziplinen erforderlich, um die Regeln richtig zu konstruieren, welche die Wissensbasis steuern, die Disziplin bzw. das Wissensfach des Wissensingenieurs und das Wissen des Experten. Der Domainexperte hat Wissen über die Domäne oder das Gebiet einer Verwendung des Expertensystems. Beispielsweise kann der Domainexperte eines Experten zum Unterweisen von Schülern in einer Automobilherstellungsfabrik ein Prozesssteueringenieur sein, während der Domainexperte für ein medizinisches Unterweisungssystem ein Arzt oder eine Krankenschwester sein kann. Der Wissensingenieur ist eine Person, welche das Expertensystem versteht und das Expertenwissen verwendet, um eine Anwendung für das System zu schaffen. In vielen Fällen sind der Wissensingenieur und der Domainexperte verschiedene Personen, welche zur Konstruktion des Expertensystems zusammenarbeiten müssen. Typischerweise hat diese Zusammenarbeit die Form, dass der Wissensingenieur den Domainexperten Fragen fragt und die Antworten zu diesen Fragen in das Design bzw. den Entwurf des Systems einbaut. Dieser Ansatz ist arbeitsintensiv, langsam und fehleranfällig. Die Koordination der zwei separaten Disziplinen kann zu Problemen führen. Auch wenn der Wissensingenieur eine Eingabe bzw. Informationen von dem Experten unter Verwendung von Videoband, Audioband, Text und anderen Quellen übertragen kann, muss ein Aufwand von Personen beider Disziplinen aufgewendet werden. Zudem können, falls der Wissensingenieur nicht die richtigen Fragen fragt oder die Fragen auf eine inkorrekte Weise fragt, die zum Design der Wissensbasis verwendeten Informationen inkorrekt sein. Eine Rückmeldung zu dem Wissensingenieur von dem Expertensystem ist bei dem System des Standes der Technik oft nicht verfügbar, bis die Konstruktion abgeschlossen ist. Mit einem konventionellen System gibt es eine zeitraubende Rückmeldungsschleife, welche verschiedenste Prozesse bzw. Vorgänge von Wissenserlangung bis zur Plausibilitätsprüfung zusammenbindet.
Unterrichtssysteme, welche eine Expertensystemkomponente verwenden, leiden of an einem Mangel an Motivationsaspekten, welche zur Folge haben, dass der Benutzer gelangweilt wird oder aufhört, ein Trainingsprogramm zu vervollständigen. Derzeitige Trainingsprogramme verwenden statische, fest programmierte Rückmeldung, wobei etwas lineares Video und Graphik verwendet wird, um visuelle Anziehungskraft hinzuzufügen und Konzepte zu veranschaulichen. Diese Systeme unterstützen typischerweise eine "korrekte" Antwort, und eine Navigation durch das System wird nur durch einen einzigen definierten Pfad unterstützt, welcher eine zweidimensionale gattungsgemäße Interaktion, ohne eine Geschäftsmodellunterstützung, und eine einzige Rückmeldung zu dem Lernenden in Bezug auf korrekt oder inkorrekt auf der Grundlage der ausgewählten Antwort zur Folge hat. Derzeitige Selbstlernsysteme gestalten keine realen Geschäftssimulationen in die Regeln, um einem Benutzer eine kreative Lernumgebung zur Verfügung zu stellen.
Ein gattungsgemäßes Verfahren, das ein Computergerät zur Schaffung eines Unterrichtsystems mit den Merkmalen des Oberbegriffs von Anspruch 1 und ein gattungsgemäßes Computergerät zur Schaffung eines Unterrichtsystems mit den Merkmalen des Oberbegriffs von Anspruch 10 verwendet, sind aus der WO 97 44 766 A bekannt.
US-A-5 778 240 lehrt ein Datenbanksystem mit einer schnellen Schnittstellenprüfung, wenn Daten eingegeben werden.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren gemäß dem Oberbegriff von Anspruch 1 und ein Computergerät gemäß dem Oberbegriff von Anspruch 10 derart weiterzuentwickeln, dass die zentrale Datenbank effektiver verwendet wird.
Gemäß der Erfindung wird diese Aufgabe durch ein Verfahren mit den Merkmalen von Anspruch 1 und ein Computergerät mit den Merkmalen von Anspruch 10 erzielt.
Ein zielbasiertes Lernsystem verwendet ein regelbasiertes Expertentrainingssystem, um eine kognitive Unterrichtserfahrung bereitzustellen. Das System stellt dem Benutzer eine simulierte Umgebung zur Verfügung, welche eine Geschäftschance präsentiert, die optimal zu verstehen und lösen ist. Fehler werden notiert und förderndes Unterrichtsmaterial wird dynamisch präsentiert, um die notwendigen Fertigkeiten aufzubauen, die ein Benutzer zum Erfolg bei dem Geschäftsbemühen braucht. Das System verwendet eine Maschine künstlicher Intelligenz, die individualisierte und dynamische Rückmeldung bzw. Rückkopplung mit synchronisiertem Video und Graphiken steuert, die zur Simulation einer Realweltumgebung und -Interaktionen verwendet werden. Mehrere "korrekte" Antworten werden in das Lernsystem integriert, um individualisierte Lernerfahrungen zu ermöglichen, bei welchen eine Navigation durch das System mit einer durch den Lernenden gesteuerten Geschwindigkeit stattfindet. Ein robustes Geschäftsmodell stellt eine Unterstützung für realistische Aktivitäten bereit und ermöglicht es einem Benutzer, Realweltkonsequenzen für seine Aktionen und Entscheidungen zu erfahren, und ein Selbstlernsystem bzw. Tutorensystem analysiert Schülereingaben, um eine geeignete Rückmeldung zu bestimmen, um neue Fertigkeiten zu lehren.
BESCHREIBUNG DER ZEICHNUNGEN
Die Vorangehenden und andere Aufgaben, Aspekte und Vorteile werden aus der folgenden detaillierten Beschreibung eines bevorzugten Ausführungsbeispiels der Erfindung unter Bezugnahme auf die Zeichnungen besser verstanden. Es zeigen:
1 ein Blockschaltbild einer repräsentativen Hardwareumgebung gemäß einem bevorzugten Ausführungsbeispiel;
2 ein Blockschaltbild einer Systemarchitektur;
3 den zeitlichen Ablauf und relative Quellenerfordernisse für jede Phase einer Entwicklung für eine typische Anwendungsentwicklung;
4 ein kleines Segment eines Domainmodells für Schadensbearbeiter in der Autoversicherungsindustrie;
5 ein Profil zur Tätigung von Versicherungsgeschäften;
6 eine Transformationskomponente;
7 die Verwendung eines Werkzeugbalkens zum Navigieren und zum Zugriff auf Merkmale der Anwendungsebene;
8 eine GBS-Anzeige;
9 eine Rückmeldungsanzeige;
10 eine Journaleintragsimulation bzw. Kassenbucheintragssimulation;
11 einen simulierten Eintrag in ein Bell-Telefonrechnungsjournal;
12 eine Rückmeldungsanzeige;
13 die Schritte des ersten Szenarios;
14 und 15 die Schritte, die mit einem konstruierten Szenario in Zusammenhang stehen;
16 ein Testszenario. Die Testschüler arbeiten durch die Journaleintragaktivität;
17, wie die Werkzeugfolge eine Schüleradministration unterstützt;
18 eine Folge zur Unterstützung einer Schülerinteraktion bzw. -zusammenarbeit;
19 den Förderunterrichtvorgang;
20 die Objekte für die Journaleintragaufgabe;
21 die Abbildung eines Quellenpostens auf einen Zielposten;
22 eine Analyse von Regeln;
23 eine Rückmeldungsauswahl;
24 ein Flussdiagramm der Rückmeldungslogik;
25 ein Blockschaltbild, welches die Architektur eines Simulationsmodells darlegt;
26 die Schritte zur Konfiguration einer Simulation;
27 ein Blockschaltbild, welches die ausführliche Architektur eines Systemdynamikmodells präsentiert;
28 ein Übersichtsschaubild der zur Anfangskonfiguration verwendeten Logik;
29 eine Anzeige von Videoinformationen; und
30 ein ICA-Dienstprogramm.
AUSFÜHRLICHE BESCHREIBUNG
Ein bevorzugtes Ausführungsbeispiel eines Systems gemäß der vorliegenden Erfindung wird vorzugsweise in dem Kontext eines Personalcomputers, wie beispielsweise einem IBM-kompatiblen Personalcomputer, einem Apple-Macintosh-Computer oder einer UNIX-basierten Workstation praktiziert. Eine repräsentative Hardwareumgebung ist in 1 dargestellt, welche eine typische Hardwarekonfiguration einer Workstation gemäß einem bevorzugten Ausführungsbeispiel veranschaulicht, das eine zentrale Verarbeitungseinheit 110, wie beispielsweise einen Mikroprozessor, und eine Anzahl von anderen Einheiten aufweist, die über einen Systembus 112 miteinander verbunden sind. Die in 1 gezeigte Workstation umfasst einen Speicher mit wahlfreiem Zugriff (RAM) 114, einen Nur-Lese-Speicher (ROM) 116, einen Eingabe-/Ausgabe-Adapter 118 zur Verbindung peripherer Vorrichtungen, wie beispielsweise Diskspeichereinheiten 120, mit dem Bus 112, einen Benutzerschnittstellenadapter 122 zur Verbindung einer Tastatur 124, einer Maus 126, eines Lautsprechers 128, eines Mikrophons 132, und/oder andere Benutzerschnittstellenvorrichtungen, wie beispielsweise einen (nicht abgebildeten) Berührungsbildschirm mit dem Bus 112, einen Kommunikationsadapter 134 zur Verbindung der Workstation mit einem Kommunikationsnetzwerk (beispielsweise ein Datenverarbeitungsnetzwerk) und einen Anzeigeadapter 136 zur Verbindung des Busses 112 mit einer Anzeigevorrichtung 138. Auf der Workstation ist ein Betriebssystem eingerichtet, wie beispielsweise Microsoft Windows NT oder das Betriebssystem (OS) Windows/95, das IBM-OS/2-Betriebssystem, das MAC OS, oder das UNIX-Betriebssystem. Fachmänner werden anerkennen, dass die vorliegende Erfindung auch auf anderen Plattformen und Betriebssystemen als den Erwähnten ausgeführt werden kann.
Ein bevorzugtes Ausführungsbeispiel ist unter Verwendung der Sprachen JAVA, C und C++ geschrieben und verwendet objektorientierte Programmierungsmethodologie. Objektorientierte Programmierung (OOP) wurde zunehmend verwendet, um komplexe Anwendungen zu entwickeln. Mit einer Etablierung von OOP für Softwaredesign und -entwicklung erfordern verschiedene Softwarelösungen eine Anpassung, um die Vorteile von OOP zu nutzen. Es existiert ein Bedarf, dass diese Prinzipien von OOP auf eine Datentransferschnittstelle eines elektronischen Datentransfersystems derart angewendet werden, dass eine Gruppe von OOP-Klassen und Objekten für die Datentransferschnittstelle bereitgestellt werden kann. Eine Simulationsmaschine gemäß einem bevorzugten Ausführungsbeispiel basiert auf einer Microsoft Visual Basic Komponente, die entwickelt ist, um Design- und Test-Rückmeldung in Bezug auf eine Microsoft Excel Tabellenkalkulation zu unterstützen. Diese Tabellenkalkulationsmodelle sind, was tatsächliche Geschäftsfunktionen simuliert, und werden eine Aufgabe, die durch einen Schüler durchgeführt wird. Die Simulationsmaschine akzeptiert Simulationseingaben und berechnet verschiedene Ausgaben und teilt dem System den Status der Simulation zu einer gegebenen Zeit mit, um eine geeignete Rückmeldung zu erlangen.
Beziehung von Komponenten
Das Simulationsmodell führt die Geschäftsfunktion aus, die der Schüler lernt, und ist daher der zentrale Punkt der Anwendung. Eine Aktivitäts„schicht” ermöglicht es dem Benutzer, die Simulation visuell zu lenken, indem Eingaben an die Simulationsmaschine weitergegeben und Ausgaben aus dem Simulationsmodell empfangen werden. Falls der Schüler beispielsweise an einer Gewinn- und Verlustrechnungsaktivität arbeitete, werden die Nettoerträge und Kosten von Produktverkaufsberechnungen als Eingaben an das Simulationsmodell weitergegeben und der Nettogewinnwert wird als eine Ausgabe berechnet und wieder gewonnen. Wenn Berechnungen an das Simulationsmodell weitergegeben werden und von ihm wiedergewonnen werden, werden sie auch an den Intelligenten Nachhilfevermittler (ICA = Intelligent Coaching Agent) weitergegeben. Der ICA analysiert die Eingaben in das und Ausgaben aus dem Simulationsmodell und erzeugt Rückmeldungen auf der Grundlage einer Gruppe von Regeln. Diese Rückmeldung wird durch die Visual Basic Architektur empfangen und angezeigt.
2 ist ein Blockschaltbild einer Systemarchitektur. Die Präsentations„schicht” 210 ist von der Aktivitäts„schicht” 220 getrennt, und Kommunikation wird durch eine Gruppe von Meldungen 230 vereinfacht, welche die Anzeige von spezifischen Themeninhalten steuern. Das System ermöglicht Wissensarbeitern 200&201, komplexe Fertigkeiten rapide, zuverlässig und konsistent über eine Organisation zum Liefern von rapider Erlangung von komplexen Fertigkeiten zu erlangen. Dieser Ergebnis wird erzielt, indem Individuen in eine simulierte Geschäftsumgebung platziert werden, die wie echte Arbeit "aussieht und sich anfühlt", und sie herausgefordert werden Entscheidungen zu treffen, welche geschäftsstrategische Aufgaben unterstützen, unter Verwendung einer hocheffizienten Lerntheorie (beispielsweise zielbasiertes Lernen, Lernen durch Selbermachen (learning by doing), misserfolgbasiertes Lernen, etc.) und der neuesten Multimediabenutzerschnittstellen, die mit drei leistungsfähigen, integrierten Softwarekomponenten gekoppelt sind. Die erste dieser Komponenten ist eine Softwarelösungskonstruktionshilfe (SCA) 230, die aus einem mathematischen Modellbildungswerkzeug 234 besteht, welches Geschäftsergebnisse von gesammelten Aktionen eines Individuums über eine Zeitdauer simuliert. Die zweite Komponente ist ein Wissenssystem 250, welches aus einer HTML-Inhaltsschicht besteht, die verpacktes Wissen ganz ähnlich zu einem Onlinetextbuch mit Praxisübungen, Videokriegsgeschichten, und einem Glossar organisiert und präsentiert. Die dritte Komponente ist ein Softwaretutor 270, welcher eine künstliche-Intelligenz-Maschine 240 aufweist, die individualisierte Nachhilfemeldungen auf der Grundlage von durch den Lernenden gemachten Entscheidungen erzeugt.
Die Rückmeldung ist für jedes den Kurs vervollständigende Individuum einzigartig und unterstützt kundenkulturelle Meldungen 242 "gestaltet in" dem Kurs. Eine Geschäftssimulationsmethodologie, welche eine Unterstützung für Inhaltsakquisition, Geschichtenliniendesign, Interaktionsdesign, Rückmeldungs- und Nachhilfelieferung, und Inhaltslieferung umfasst, ist in das System gemäß einem bevorzugten Ausführungsbeispiel eingebaut. Gemäß einem bevorzugten Ausführungsbeispiel sind auch eine große Anzahl von "vorgestalteten" Lerninteraktionen, wie beispielsweise ein Ziehen-und-Ablegen-Zusammenhang von Informationen 238, eine Situationsbewertungs/-aktionsplanung, Interviewen (einer einen, einer mehrere), Präsentieren (für eine Gruppe von Experten/Ausführenden), Dosieren von Arbeitsleistung (jetzt bearbeiten, später bearbeiten), "Zeitspringen" zur Auswirkung von Entscheidungen, Wettbewerbslandschaftsverschiebung (während einem "Zeitspringen", schließen sich Wettbewerber zusammen, werden Kunden akquiriert, etc.) und Videointerviewen mit automatisiertem Notiznehmen umfasst.
Geschäftssimulation liefert Trainingslehrpläne auf eine optimale Weise. Der Grund dafür liegt darin, dass derartige Anwendungen effektives Training bereitstellen, welche eine tatsächliche Arbeitsumgebung eines Schülers spiegeln. Die Anwendung von Fertigkeiten "bei der Arbeit" vereinfacht eine erhöhte Speicherung bzw. Merkfähigkeit und höhere Gesamtarbeitsleistungsfähigkeit. Auch wenn die Ergebnisse derartiger Trainingsanwendungen eindrucksvoll sind, sind Geschäftsanwendungen sehr komplex korrekt zu gestalten und aufzubauen. Diese Simulationen werden durch eine nach außen sehr offene Umgebung charakterisiert, in welcher Schüler abhängig von ihrem Lernstil und vorherigen/m Erfahrungen/Wissen entlang einer beliebigen Anzahl von Wegen durch die Anwendung laufen können.
Eine Kategorie von Lernansätzen, die Lernen durch Selbermachen genannt wird, wird allgemein als eine Lösung zur Unterstützung der ersten Phase (Lernen) des Arbeitskraftleistungsfähigkeitszyklus verwendet. Es kann jedoch auch eine Lösung zur Unterstützung der zweiten Phase (Durchführen) des Zyklus sein, um während einer Arbeitsleistung ein Lernen je nach Bedarf zu ermöglichen. Durch Einsatz des präsentierten Ansatzes werden einige der Vorteile eines technologiebasierten Ansatzes zum Aufbau von Geschäftssimulationslösungen hervorgehoben, welche besser wiederholbare, voraussagbare Projekte schaffen bzw. erzeugen, was einen besser verstandenen und tatsächlichen Benutzerwert zu geringeren Kosten und weniger Zeit zur Folge hat.
Heute sind die meisten Firmentrainingsprogramme fehlgerichtet, da sie es versäumt haben, sich richtig auf den Zweck ihres Trainings zu fokussieren. Diese Programme haben das sich Merken von Fakten mit der Fähigkeit zur Durchführung von Aufgaben; das Wissen über "das" mit dem Wissen über "wie" durcheinander gebracht. Durch Einsatz der Verfahren von traditionellen Schulen lehren Geschäfte eine breite Breite von unverbundenen, aus dem Zusammenhang gerissenen Fakten und Zahlen, wenn sie auf verbesserte Leistungsfähigkeit bzw. Arbeitsleistung fokussiert sein sollten. Wie werden Sie Leistungsfähigkeit lehren, wenn Vorträge, Bücher und Tests inhärent um Fakten und Zahlen gestaltet sind? Werfen Sie die Vorträge, Bücher und Tests über Bord. Der beste Weg zum Erstellen einer hohen Leistungsfähigkeit ist durchzuführen; Erfahrung ist der beste Lehrer! Die meisten Geschäftsführer stimmen zu, dass Mitarbeiter effektiver werden, je mehr Zeit sie in ihrem Beruf verbringen. Der beste Ansatz zum Trainieren von neuen Mitarbeitern wäre daher, sie in ihrem Beruf lernen zu lassen, wodurch sie Fertigkeiten in ihrer tatsächlichen Arbeitsumgebung erwerben. Die Idee eines Lernens durch Selbermachen ist nicht revolutionär, aber in Geschäft und akademischen Kreisen wird noch Widerstand geleistet. Warum ist dies so, wenn allgemein eine höhere Kompetenz gewünscht wird?
Lernende sind zurückhaltend, ein Lernen durch Selbermachen zu einzusetzen, da sie vor einem Scheitern Angst haben. Menschen arbeiten hart, um ein Machen von Fehlern vor anderen zu vermeiden. Geschäftsführer zögern, ein Lernen durch Selbermachen auszuführen, da ein Fehler eines Neulings dramatische Sicherheits-, rechtliche und finanzielle Auswirkungen haben kann. Stellen sie sich einen neuen Piloten vor, der durch Selbermachen lernt, wenn er einen großen Düsenjet eine Startbahn hinunter beschleunigt; Stellen sie sich in ähnlicher Weise einen neuen Finanzanalysten vor, der durch Selbermachen lernt, wenn er eine Finanzanleihe über mehrere Millionen Dollar aufbaut. Wenige Mitarbeiter wollen derartiges Scheitern ertragen, um eine kompetentere Arbeitskraft zu haben.
Der Schlüssel zu einem derartigen Unterstützungssystem ist, dass es nahtlos in das Geschäftssystem integriert wird, welches der Mitarbeiter verwendet, um seine Arbeitsaufgaben auszuführen. Mitarbeiter müssen nicht "offline" gehen oder kryptische Informationen versteckt in Papierhandbüchern und Sammelmappen zur Führung oder zum Finden der Antwort auf Fragen suchen. Alle Unterstützungskomponenten werden durch dieselben Anwendungen, die die Mitarbeiter verwenden, an dem Punkt, bei welchem sie sie brauchen, maßgeschneidert auf das Individuum verfügbar gemacht, um das "wie" und nicht nur das "was" zu zeigen. Ein Lernen würde zu jeder Zeit auftreten, mit wenig Unterschied zwischen Durchführung und Verbesserung der Leistungsfähigkeit. Eine Einrichtung dieses Trainings sollte eher auf Performance bzw. Leistungsfähigkeit (wie) als auf Fakten (was) fokussieren, und eine Erweiterung des Modells zum Lernen, um eine Hilfe lieber während einer Durchführung als nur vor der Durchführung einzubinden, lässt uns noch gefährlich exponiert bzw. ungeschützt beim Erstellen, um in der neuen chaotischen Wirtschaft anzutreten. Wie in der Einleitung dieser Veröffentlichung erwähnt wurde, ist die Änderungsgeschwindigkeit in der Wirtschaft heute pfeilschnell. Es entstehen nicht nur neue Verfahren eines Geschäfteabwickelns alle 18 bis 24 Monate, neue Wettbewerber schließen sich zusammen, dominieren und verschwinden in Zeitdauern, welchen Geschäfte brauchten, um demographische Studien durchzuführen. Nun werden mehr als jemals diejenigen, die sich nicht regelmäßig selbst erfinden, durch die Änderungsgeschwindigkeit versteinert. Ein typisches BusSim-Engagement braucht zum Abschluss zwischen ein und zwei Jahren und erfordert eine Vielzahl von sowohl funktionellen als auch technischen Fertigkeiten. 3 stellt den zeitlichen Verlauf und relative Quellenerfordernisse für jede Entwicklungsphase für eine typische Anwendungsentwicklung dar. Das Diagramm stellt die Beziehung zwischen der großen Anzahl von technischen Quellen klar dar, die für sowohl die Ausführungs- bzw. Aufbau- und Testphase einer Entwicklung erforderlich sind. Der Grund dafür liegt darin, dass der traditionelle Entwicklungsprozess, der zum Aufbau von BusSimlösungen verwendet wird, mehr als eine "eine von vielen" Philosophie reflektiert, bei welcher eine Entwicklung aus einem Kratzen in einer monolithischen Art vorgenommen wird, wobei wenig oder keine Wiederverwendung von einer Anwendung zu der Nächsten stattfindet. Dieser Mangel an Wiederverwendung macht diesen Ansatz für kommende BusSimprojekte wahrscheinlich teuer sowie langwierig.
Die Lösung für dieses Problem ist es, in die Hände von Lehrdesignern bzw. -gestaltern Werkzeuge zu geben, die es ihnen ermöglichen, ihre BusSimdesigns zu schaffen und sie auszuführen, ohne dass der Bedarf nach Programmierern besteht Code zu schreiben. Und um Anwendungsarchitekturen zu geben, die sich mit den Werkzeugen in den Händen von Entwicklern integrieren, so dass sie mit der Fähigkeit zur schnelleren Lieferung von Lösungen für eine Anzahl von verschiedenen Plattformen ausgestattet sind. Die Wiederverwendung kommt dann durch Verwendung der Werkzeuge und Architekturen von einem Engagement bzw. Auftrag zu einem anderen. Sowohl die funktionellen als auch die technischen Quellen tragen das Wissen mit sich, wie die Technologie zu verwenden ist, was auch einen damit zusammenhängenden Vorteil eines Errichtens einer praxisbesten Entwicklungsmethodologie für BusSimengagements hat.
Entwicklungszyklusaktivitäten
In der Designphase werden Lehrdesigner auf den Inhaltsbereich orientiert und beginnen, ein Konzept für einen Lehransatz zu entwickeln. Sie machen sich selbst durch Lesen von Materialien und Interviews mit Themengebietexperten (SMEs) mit dem Themengebiet vertraut. Sie identifizieren auch Lernaufgaben aus Schlüsselkundenkontakten. Es beginnen auch konzeptionelle Designs für Schülerinteraktionen bzw. Schülerzusammenarbeit und Schnittstellenlayouts zusammenzuwachsen. Nachdem die konzeptionellen Designs Form angenommen haben, wird ein Niedriges-Fi-Benutzertesten (a. k. a. Konferenzraumführung) durchgeführt. Schüler arbeiten mit Schnittstellenprototypen zusammen, während Schulungsleiter alle Sachverhalte beobachten und aufzeichnen. Schließlich werden Designs geschaffen, die Gefundenes einbinden. Diese detaillierten Designs werden an das Entwicklungsteam zur Implementierung weitergegeben. Die Designphase steckte traditionell voll mit mehreren Problemen. Im Gegensatz zu einem traditionellen Geschäftssystem sind BusSim-Lösungen nicht in berührbaren Geschäftsprozessen verwurzelt, so dass Erfordernisse schwierig auf konkrete Weise zu identifizieren sind. Dies lässt Designer bzw. Gestalter mit einem "blauer-Himmel"-Designsproblem zurück. Mit wenig geschäftsgesteuerten Grenzen für die Lösung, seichter Fachkenntnis in dem Inhaltsbereich und begrenzten technischen Fertigkeiten haben Lehrdesigner wenig Hilfe beim Beginnen eines Designs. Typischerweise waren nur erfahrene Designer in der Lage, sich Schnittstellen-, Analyse- und Rückmeldungsdesigns ins Gedächtnis zu rufen, welche die Lernaufgaben erfüllen, die noch technisch schwierig auszuführen bleiben. Um das Problem zu verschlimmern, liegt es in der Natur von BusSim-Lösungen, dass sie sehr offen sind. Der Designer muss eine riesige Kombination von Schülerverhalten vorwegnehmen, um eine Rückmeldung zu gestalten, die hilfreich und realistisch ist.
Während der Ausführungs- bzw. Aufbauphase verwendet das Anwendungsentwicklungsteam die detaillierten Designs, um die Anwendung zu codieren. Codieraufgaben umfassen die Schnittstellen und Widgets, mit welchen der Schüler interagiert. Die Schnittstellen können aus Schaltflächen, Gittern, Prüffeldern, oder beliebigen anderen Bildschirmkontrollen hergestellt sein, welche es dem Schüler ermöglichen, seine gelieferten Ergebnisse anzusehen und zu manipulieren. Der Entwickler muss auch Logik codieren, welche die Schülerarbeit analysiert und Rückmeldungsinteraktionen bereitstellt. Diese Interaktionen können die Form von Text und/oder Multimediainteraktionen von simulierten Teammitgliedern, Unterhaltungen mit simulierten Teammitgliedern, oder direkten Manipulationen der Schülerarbeit durch simulierte Teammitglieder annehmen. Parallel zu diesen Codieranstrengungen, werden Graphiken, Videos und Audio zur Verwendung in der Anwendung geschaffen. Eine Verwaltung der Entwicklung dieser Kapitalanlagen hat ihre eigenen Komplikationen. Risiken in der Aufbauphase umfassen Fehlinterpretation der Designs. Falls der Entwickler die Absicht des Designers nicht richtig versteht, wird die Anwendung nicht wie gewünscht funktionieren. Außerdem erfordert ein Codieren dieser Anwendungen Entwickler mit sehr guten Fertigkeiten, da die Logik sehr komplex ist, welche die Schülerarbeit analysiert und eine Rückmeldung zusammensetzt.
Die Testphase ist, wie der Name impliziert, zum Testen der Anwendung. Ein Testen wird durchgeführt, um die Richtigkeit der Anwendung auf drei Wegen zu überprüfen: erstens, dass die Anwendung richtig funktioniert (funktioneller Test), zweitens, dass der Schüler die Schnittstelle versteht und effektiv navigieren kann (Verwendbarkeitstest), und drittens, dass die Lernaufgaben erfüllt sind (kognitiver Test). Funktioneller Test der Anwendung kann durch das Entwicklungsteam oder durch ein ausgewiesenes Testteam ausgeführt werden. Falls die Anwendung nicht richtig funktioniert, wird sie auf Fehler durchsucht, repariert, erneut übersetzt, und erneut getestet, bis ihr Betrieb zufrieden stellend ist. Ein Verwendbarkeitstest und ein kognitiver Test kann nur durch Testschüler ausgeführt werden, die mit der Anwendung nicht vertraut sind. Wenn die Verwendbarkeit nicht zufriedenstellend ist, kann es sein, dass Teile der Schnittstelle und/oder der Rückmeldungslogik erneut gestaltet, erneut codiert und erneut getestet werden muss. Falls die Lernaufgaben nicht erfüllt sind, kann es sein, dass große Teile der Anwendung beseitigt werden müssen und von einer anderen Perspektive vollständig neu entwickelt werden müssen. Die Testphase ist typischerweise die, wo die meisten der Schwierigkeiten in dem BusSim-Entwicklungszyklus angetroffen werden. Der Prozess eines Entdeckens und Reparierens von funktionellen, Verwendbarkeits-, und kognitiven Problemen ist ein schwieriger Prozess und keine exakte Wissenschaft.
Für funktionelles Testen betreiben Tester die Anwendung, indem sie entweder einem Testskript folgen, oder indem sie spontan agieren und ihre Aktionen dokumentieren, wie sie vorgehen. Wenn ein Problem oder ein unerwartetes Problem angetroffen wird, ist auch dies zu dokumentieren. Der für diesen Teil der Anwendung verantwortliche Anwendungsentwickler empfängt dann die Dokumentation und versucht, das Problem durch Wiederholung der Aktion des Testers zu wiederholen. Wenn das Problem wiederholt ist, forscht der Entwickler weiter, um die Ursache zu finden und eine Reparatur auszuführen. Der Entwickler wiederholt noch einmal die Testeraktionen, um zu verifizieren, dass die Reparatur das Problem gelöst hat. Schließlich müssen alle anderen Testskripte erneut laufen gelassen werden, um zu verifizieren, dass die Reparatur keine unbeabsichtigten Konsequenzen irgendwo anders in der Anwendung hat. Die Ausführungsphase bezieht sich auf den Bereitzustandsbetrieb der vervollständigten Anwendung in ihrer Produktionsumgebung. Für einige Kunden umfasst dies Telefonunterstützung für Schüler. Kunden können auch die Möglichkeit wünschen, den Fortschritt des Schülers nachzuverfolgen und seinen Fortschritt durch den Kurs zu kontrollieren. Schließlich können Kunden die Möglichkeit wünschen, Sachverhalte nachzuverfolgen, so dass sie zur Einbindung in Kursinstandhaltungsfreigaben berücksichtigt werden können.
Einer dieser Schlüsselwerte von Onlinekursen ist, dass sie zu einer Zeit, an einem Ort und mit einer Geschwindigkeit genommen werden können, die für den individuellen Schüler bequem ist. Da sich Schüler jedoch nicht zentral an einem Ort befinden, ist eine Unterstützung nicht immer sofort verfügbar. Aus diesem Grund ist es oft wünschenswert, eine Telefonunterstützung für Schüler zu haben. Kunden können auch wünschen, den Fortschritt des Schülers nachzuverfolgen oder sein Weitergehen durch den Kurs zu kontrollieren. Unter dieser Strategie wird ein Schüler, nachdem er einen Abschnitt des Kurses abschließt, seine Fortschrittsdaten entweder elektronisch oder durch physikalisches Versenden einer Disk an ein Verarbeitungszentrum übertragen. Dort kann sie analysiert werden, um zu verifizieren, dass er alle Arbeit zufrieden stellend vervollständigt hat. Eine Schwierigkeit, die allgemein mit Schülernachverfolgen bzw. Schülerüberprüfung im Zusammenhang steht, ist Isolieren der Schülerdaten zur Analyse. Es kann schwer in der Griff zu kriegen sein, alle Kursdaten zu übertragen, so dass es oft zwingend ist, die minimal erforderlichen Daten zu isolieren, um die notwendige Analyse des Schülerfortschritts durchzuführen.
Ein Liefernetzwerk für Geschäftssimulation
Wie zuvor diskutiert, reflektiert der traditionelle Entwicklungsprozess, der zum Aufbau von Bus-Sim-Lösungen Verwendung findet, mehr als eine "eine aus vielen"-Philosophie, bei welcher eine Entwicklung aus einem Kratzen in einer monolithischen Art vorgenommen wird, wobei geringe oder keine Wiederverwendung von einer Anwendung zu der Nächsten stattfindet. Ein besserer Ansatz wäre, sich auf eine Reduktion des Gesamtaufwands zu fokussieren, der zur Entwicklung durch Wiederverwendung erforderlich ist, was wiederum Kosten und Entwicklungszeit vermindern würde. Der erste Schritt bei einer Überlegung einer Wiederverwendung als eine Option ist die Identifikation von allgemeinen Aspekten der verschiedenen BusSim-Anwendungen, welche als in kommenden Anwendungen als nützlich verallgemeinert werden können. Bei einer Prüfung der Elemente, welche diese Anwendungen aufbauen, verschmelzen drei gemeinsame Aspekte als integrale Teile jeder Anwendung: Schnittstelle, Analyse und Interpretation. Jede BusSim-Anwendung muss einen Mechanismus zur Interaktion mit dem Schüler haben. Das Maß einer Komplexität jeder Schnittstelle kann von der hohen Interaktivität einer Echtzeitsimulationsaufgabe mit hoher Wiedergabetreue zu den weniger komplexen Informationsliefererfordernissen einer Geschäftsfallhintergrundinformationsaufgabe variieren. Ungeachtet davon, wie ausgeklügelt die Benutzerschnittstelle (UI) ist, ist sie ein vitales Stück, die zugrunde liegende Simulation und Rückmeldungslogik für den Endbenutzer als brauchbar zu machen.
Jede BusSim-Anwendung führt eine Analyse für die Daten, welche den derzeitigen Zustand der Simulation definieren, viele Male während der Ausführung der Anwendung aus. Diese Analyse wird vorgenommen, um entweder zu bestimmen, was in der Simulation passiert, oder um zusätzliche Berechnungen für die Daten durchzuführen, welche dann in die Simulation zurückgespeist werden. Beispielsweise kann die Analyse die Erkennung beliebiger Aktionen sein, die der Schüler auf Artefakte in der simulierten Umgebung (Notebooks, Zahlenwerte, durchgeführte Interviews, etc.) vorgenommen hat, oder es kann die Berechnung eines ROI auf der Grundlage von Zahlen sein, die der Schüler zugeführt hat. Substantielle, brauchbare Rückmeldung ist ein kritischer Teil einer beliebigen BusSim-Anwendung. Es ist der Hauptmechanismus zu kommunizieren, falls durch den Schüler vorgenommene Aktionen ihnen helfen oder schaden, ihre Arbeitsleitungsaufgaben zu erfüllen. Das Interpretationsstück der Gruppe von vorgeschlagenen Gemeinsamkeiten nimmt die Ergebnisse jeder durchgeführten Analyse und gibt ihnen einen Sinn. Es nimmt die unausgewogene Ansicht der Welt, welche der Analyseabschnitt liefert (d. h. "Bedarf ist bis zu 3%") und stellt einigen bewertenden Kontext um es herum (d. h. "Bedarf ist unter den erwarteten 7%; Sie sind in Schwierigkeiten!", oder "Bedarf hat Hochrechnungen von 1,5% übertroffen; Gute Arbeit!").
Es gibt mehrere Ansätze zum Einfangen von Gemeinsamkeiten zur erneuten Verwendung. Zwei der allgemeineren Ansätze sind netzwerkbasiert und komponentenbasiert. Um die Unterschiede zwischen den zwei Ansätzen veranschaulichen zu helfen, werden wird eine Analogie zwischen Bauen einer Anwendung und Bauen eines Hauses zeichnen. Man kann ein Haus von Null anfangend, unter Verwendung des Rohmaterials, 2x4s, Nägeln, Anstrich, Beton, etc. konstruieren. Man kann auch eine Anwendung von Null anfangend, unter Verwendung des Rohmaterials von neuen Designs und neuem Code konstruieren. Der mit beiden Unternehmungen einhergehende Aufwand kann durch netzwerkbasiertes und/oder komponentenbasierte Neuverwendung reduziert werden. In dem Paradigma von netzwerkbasierter Neuverwendung wird ein gattungsgemäßes Netzwerk oder Architektur konstruiert, welches/welche Gemeinsamkeiten enthält. In der Hausanalogie könnte man ein vorgefertigtes Hausgerüst bestehend aus Böden, Außenwänden, tragenden Wänden und einem Dach kaufen. Das Haus kann durch Hinzufügen von Trennwänden, Tapete, Holzarbeit, Teppichböden, etc. auf den Kunden zugeschnitten werden. In ähnlicher Weise sind vorgefertigte Anwendungsgerüste verfügbar, welche Grundlinienanwendungsstruktur und -funktionalität enthalten. Individuelle Anwendungen werden durch Hinzufügen von spezifischer Funktionalität und auf den Kunden Zuschneiden des Aussehens und Fühlens vervollständigt. Ein Beispiel eines allgemein verwendeten Anwendungsgerüsts ist Microsoft Foundation Classes. Es ist ein Gerüst zur Entwicklung von Windows-Anwendungen unter Verwendung von C++. MFC führt die Grundfunktionalität einer Fensteranwendung zu und der Entwickler vervollständigt die Anwendung durch Hinzufügen von Funktionalität in das Gerüst. Eine gerüstbasierte Neuverwendung ist zum Einfangen von vorlagenähnlichen Merkmalen am besten geeignet, beispielsweise Benutzerschnittstellenmanagement, Verfahrensobjektverhalten, und beliebige andere Merkmale, die eine Spezialisierung erfordern können. Einige Vorteile einer Verwendung eines Gerüsts umfassen:

Extensive Funktionalität kann in ein Gerüst eingebaut werden. In der Hausanalogie kann ich, falls ich weiß, dass ich eine Gesamtumgebung von drei Schlafzimmerbereichen bauen werde, die Verrohrung, Verdrahtung und Trennwände direkt in das Gerüst einbauen, was den für jedes Haus erforderlichen Mehraufwand reduziert. Falls ich weiß, dass ich eine große Anzahl von sehr ähnlichen Anwendungen bauen werde, werden sie mehr Gemeinsamkeiten haben, die in das Gerüst eingebaut werden können, als dass sie individuell gebaut werden müssen.
Anwendungen können die vom Gerüst zugeführte Funktionalität überschreiten, wo immer dies geeignet ist. Falls ein Hausgerüst mit vorgestrichenen Wänden kommt, könnte der Erbauer nur mit bevorzugten Farben über sie streichen. In ähnlicher Weise ermöglich es das objektorientierte Erbschaftsprinzip einem Anwendungsentwickler, das Verhalten des Gerüsts zu überschreiten. In dem Paradigma von komponentenbasierter Neuverwendung ist eine Schlüsselfunktionalität in einer Komponente eingeschlossen. Die Komponente kann dann in mehreren Anwendungen neu verwendet werden. In der Hausanalogie entsprechen Komponenten Geräten, wie beispielsweise Geschirrspülern, Kühlschränken, Mikrowellen, etc. In ähnlicher Weise sind viele Anwendungskomponenten mit vorgepackter Funktionalität von einer Vielzahl von Verkäufern erhältlich. Ein Beispiel einer populären Komponente ist ein Datengitter. Es ist eine Komponente, welche in eine Anwendung integriert werden kann, um die Fähigkeit einer Ansicht von Spaltendaten in einem Tabellenkalkulationsgitter zu liefern. Komponentenbasierte Neuverwendung ist am Besten zum Einfangen von blackboxähnlichen Merkmalen, beispielsweise Textverarbeitung, Datenmanipulation, oder beliebige andere Merkmale geeignet, welche keine Spezialisierung erfordern.
Mehrere Anwendungen auf demselben Computer können eine einzelne Komponente teilen. Dies passt nicht so gut mit der Analogie, aber stellen sie sich vor, dass alle Häuser in der Nachbarschaft denselben Geschirrspüler gleichzeitig teilen sollen. Jedes Haus hätte sein eigenes Geschirr, Spülmittel und Wasser zuzuführen, jedoch könnten sie alle ihr Geschirr parallel spülen. In der Anwendungskomponentenwelt wird dieser Typ eines Teilens leicht erreicht und hat reduzierte Disk- und Speichererfordernisse zur Folge.
Komponenten haben die Neigung, weniger Plattform- und Werkzeugabhängig zu sein. Ein Mikrowelle kann in geradezu jedem Haus verwendet werden, ungeachtet davon, ob sein Gerüst Stahl oder Holz ist, und ungeachtet davon, ob es zum Bauen von Villas oder Bretterbuden auf den Kunden zugeschnitten ist. Man kann eine hochwertige Mikrowelle in ein geringwertiges Haus tun und umgekehrt. Man kann sogar mehrere verschiedene Mikrowellen in seinem Haus haben. Komponententechnologien, wie beispielsweise CORBA, COM, und JAVABeans machen diese Art von Flexibilität bei einer Anwendungsentwicklung alltäglich. Oft ist die beste Antwort auf eine Erzielung einer Neuverwendung durch eine Kombination von gerüstbasierter und komponentenbasierter Technik gegeben. Ein gerüstbasierter Ansatz zum Aufbau von BusSim-Anwendungen ist zur Entwicklung der Benutzerschnittstelle, Handhabung von Benutzer- und Systemevents, Starten und Stoppen der Anwendung, und anderen anwendungsspezifischen und lieferplattformspezifischen Funktionen geeignet. Ein komponentenbasierter Ansatz ist für Blackboxfunktionalität geeignet. Das heißt, Funktionalität kann verwendet werden wie sie ist, ohne dass eine Spezifikation erforderlich ist. Bei einer Schaffung von Architekturen zur Unterstützung einer BusSim-Anwendungsentwicklung ist es zwingend, dass beliebige Vermögenswerte so flexibel und erweiterbar wie möglich bleiben, oder die erneute Verwendbarkeit kann vermindert werden. Daher wählen wir, die einzigartigen Aspekte von BusSim-Anwendungen unter Verwendung von eher einem Komponentenansatz als einem Gerüstansatz auszuführen. Diese Entscheidung wird durch die folgenden Beobachtungen weiter unterstützt.

Liefergerüst für Geschäftssimulation
Komponenten werden mit einem Anwendungsgerüst und einer Anwendungsarchitektur kombiniert, um maximale Neuverwendung und minimalen Kundenentwicklungsaufwand zu erzielen. Die Anwendungsarchitektur wird hinzugefügt, um eine Kommunikationsunterstützung zwischen der Anwendungsschnittstelle und den Komponenten, und zwischen den Komponenten bereitzustellen. Diese Lösung hat die folgenden Merkmale: Die Komponenten (identifiziert durch die Poktogramme) schließen eine Schlüssel-BusSim-Funktionalität ein. Die Anwendungsarchitektur stellt den Klebstoff bereit, welcher eine Anwendung-zu-Komponente- und Komponente-zu Komponente-Kommunikation ermöglicht. Das Anwendungsgerüst stellt Struktur und Grundfunktionalität bereit, die für verschiedene Interaktionsstile auf den Kunden zugeschnitten werden kann. Nur die Anwendungsschnittstelle muss für den Kunden entwickelt werden. Der nächste Abschnitt diskutiert jede dieser Komponenten ausführlicher.
Das Geschäftssimulationswerkzeugset
Wir haben klar definiert, warum ein kombinierter Komponenten-/Gerüstansatz die beste Lösung zur Lieferung von hochqualitativen BusSim-Lösungen mit einem niedrigeren Preis ist. Angenommen, es gibt auf dem Markt bereits eine Anzahl von Drittparteigerüsten, die eine Lieferfähigkeit für eine breite Vielfalt von Plattformen bereitstellen, ist das TEL-Projekt auf Definieren und Entwickeln eines Sets von Komponenten fokussiert, die einzigartige Dienste für die Entwicklung und Lieferung von BusSim-Lösungen bereitstellen. Diese Komponenten sind zusammen mit einem Set von Designs- und Testarbeitsbanken die Werkzeuge, die durch Lehrdesigner verwendet werden, um Aktivitäten in den vier Phasen einer BusSim-Entwicklung zu unterstützen. Wir nennen diese Folge von Werkzeugen das Geschäftssimulationswerkzeugset. Nachfolgend wird eine Beschreibung jeder der Komponenten und Arbeitsbanken des Werkzeugsets gegeben. Eine Komponente kann als eine Blackbox angenommen werden, die das Verhalten und die Daten umschließt, welche zur Unterstützung eines verwandten Sets von Diensten notwendig sind. Es stellt diese Dienste für die Außenwelt durch veröffentlichte Schnittstellen aus. Die veröffentlichte Schnittstelle einer Komponente ermöglicht es zu verstehen, was es durch die Dienste tut, die es anbietet, jedoch nicht, wie sie es tut. Die Komplexität seiner Ausführung ist vor dem Benutzer versteckt. Das Folgende sind die Schlüsselkomponenten des BusSim-Werkzeugsets. Domainkomponente – stellt Dienste zur Modellbildung des Zustands einer Simulation bereit. Profilbildungskomponente – stellt Dienste für regelbasiertes Bewerten des Zustands einer Simulation bereit. Transformationskomponente – stellt Dienste zur Manipulation des Zustands einer Simulation bereit. Förderunterrichtskomponente – stellt Dienste für das regelbasierte Liefern von Rückmeldung an den Schüler bereit. Die Domainmodellkomponente ist die zentrale Komponente der Folge, die eine Kommunikation von Kontextdaten über die Anwendung und die anderen Komponenten vereinfacht. Es ist ein Modellbildungswerkzeug, das eine Industriestandarddatenbank, wie beispielsweise Informix, Oracle, oder Sybase verwenden kann, um seine Daten zu speichern. Ein Domainmodell ist eine Repräsentation der Objekte in einer Simulation. Die Objekte sind derartige pseudoberührbare Dinge, wie ein Hebel, den der Schüler ziehen kann, ein Formular oder ein Merkblatt, das der Schüler ausfüllt, ein Zeichen, mit welchem der Schüler in einem simulierten Treffen interagiert, etc. Sie können auch abstrakte Objekte, wie beispielsweise die ROI für ein besonderes Investment, die Anzahl von Malen, die der Schüler eine bestimmte Frage fragt, etc. sein. Diese Objekte werden Gebilde genannt. Einige Beispielgebilde umfassen: Fahrzeuge, Bedienpersonen und Vorfälle in einer Versicherungsdomain; Journaleinträge, Cashflow-Berichte und Bilanzen in einer Finanzkontodomain, und Verbraucher und Käufe in einer Marketingdomain.
Ein Gebilde kann auch andere Gebilde enthalten. Beispielsweise könnte ein persönliches Bankkontogebilde ein Gebilde enthalten, das ein Sparkonto repräsentiert. Jede Größe hat einen Satz von Eigenschaften, wobei jede Eigenschaft das Gebilde auf eine gewisse Weise beschreibt. Das von einem Gebilde besessene Set von Eigenschaften definiert im Wesentlichen das Gebilde. Einige Beispieleigenschaften umfassen: Ein Vorfallgebilde auf einer Versicherungsanwendung besitzt Eigenschaften, wie beispielsweise "Auftretensdatum", Vorfalltypcode", etc. Ein Journaleintrag besitzt Eigenschaften, wie beispielsweise "Habenkonto", "Sollkonto", und "Betrag"; und ein Kontogebilde eines sich erneuernden Kredits auf eine Hypothekanwendung besitzt Eigenschaften, wie beispielsweise "Aussenstand", "verfügbares Limit", etc. 4 veranschaulicht ein kleines Segment eines Domainmodells für Anspruchsabwickler in der Autoversicherungsindustrie.
Profilbildungskomponente
In den einfachsten Begriffen ist es der Zweck der Profilbildungskomponente, den derzeitigen Zustand einer Domain zu analysieren und bestimmte Dinge zu identifizieren, die über diese Domain wahr sind. Diese Informationen werden dann an die Förderunterrichtskomponente weitergegeben, welche dem Schüler eine Rückmeldung gibt. Die Profilbildungskomponente analysiert die Domain durch Fragen von Fragen über den Domainzustand, ähnlich zu einem Ermittler, der Fragen über einen Fall fragt. Die Fragen, die der Profilbilder fragt, werden Profile genannt. Es sei beispielsweise angenommen, dass es eine Aufgabe zum Bilden eines Lagerfeuers gibt und der Schüler gerade ein Streichholz auf einen Holzstapel geworfen hat, es jedoch nicht anfängt zu brennen. Um dem Schüler eine nützliche Rückmeldung zu geben, müsste ein Tutor Dinge wissen, wie: War das Streichholz angezündet?, War das Holz nass?, War Kleinholz in dem Stapel? etc. Diese Fragen wären unter den Profilen, welche die Profilbildungskomponente verwenden würde, um die Domain zu analysieren. Die Ergebnisse der Analyse würden dann an die Förderunterrichtskomponente abgegeben, welche diese Informationen verwenden würde, um dem Schüler eine bestimmte Rückmeldung bereitzustellen. Insbesondere ist ein Profil ein Set von Kriterien, die mit der Domain abgestimmt bzw. an sie angepasst werden. Der Zweck eines Profils ist es zu prüfen, ob die durch das Profil definierten Kriterien in der Domain erfüllt sind. Unter Verwendung eines visuellen Bearbeitungswerkzeugs schaffen Lehrdesigner Profile zur Identifizierung derartiger Dinge, die für eine gegebene Aufgabe wichtig über die Domain zu wissen sind. Während einer Ausführung einer BusSim-Anwendung bei dem Punkt, dass eine Rückmeldung entweder durch den Schüler oder proaktiv durch die Anwendung angefordert wird, wird das Set von Profilen, die mit der derzeitigen Aufgabe in Zusammenhang stehen, bewertet, um zu bestimmen, welche wahr sind. Beispielprofile umfassen: Gute Produktionsstrategie jedoch falsche Rentabilitätsformel; Guter Fahrbericht und niedrige Schadensgeschichte; und korrekte Cashflowanalyse jedoch dürftige Kapitalrendite (ROI).
Ein Profil ist aus zwei Typen von Strukturen zusammengesetzt: Charakteristika und kollektive Charakteristika. Eine Charakteristik ist eine Bedingung (die falls (=if) Hälfte einer Regel), welche ein Unterset der Domain identifiziert, die zur Bestimmung wichtig ist, welche Rückmeldung dem Schüler zu liefern ist.
Beispielcharakteristika umfassen: Falsches Sollkonto bei Transaktion 1; Perfekte Kostenklassifikation; zumindest ein Alkohol- oder Drogenmissbrauch am Steuer (DUI) in den letzten drei Jahren; mehr als $4000 Schäden in den letzten zwei Jahren; und mehr als zwei verschuldete Unfälle in fünf Jahren. Eine Bedingungscharakteristik verwendet ein oder mehr Atomare als die Operanden, um das Unterset der Domain zu identifizieren, welche die Charakteristik definiert. Ein Atomar nimmt nur Bezug auf eine einzelne Eigenschaft eines einzelnen Gebildes in der Domain; daher der Begriff Atomar. Beispielatomare umfassen: Die Anzahl von Alkohol- oder Drogenmissbrauch am Steuer (DUIs) >= 1; ROI > 10%; und Einkommen zwischen $ 75.000 und $ 110.000. Eine kollektive Charakteristik ist eine Bedingung, welche mehrere Charakteristika und/oder andere kollektive Charakteristika als ihre Operanden verwendet. Kollektive Charakteristika erlauben es Lehrdesignern, reichere Ausdrücke aufzubauen (das heißt, komplexere Fragen zu fragen). Beispiele von kollektiven Charakteristika umfassen: schlechter Haushaltsführungsbericht; gute Kreditwürdigkeit; Grenzkreditwürdigkeit; Probleme mit Geldmitteln für Ausgabentransaktionen; und Probleme mit Quellen und Verwendungen von Geldmitteln. Sobald sie geschaffen sind, sind Designer in der Lage, diese Elemente in mehreren Ausdrücken erneut zu verwenden, was die Last eines Schaffens von zusätzlichen Profilen signifikant vereinfacht. Beim Aufbau eines Profils aus seinen Elementen können Atomare durch mehrere Charakteristika verwendet werden, Charakteristika können durch mehrere kollektive Charakteristika und Profile verwendet werden, und kollektive Charakteristika können durch mehrere kollektive Charakteristika und Profile verwendet werden. 5 veranschaulicht ein Profil zur Tätigung von Versicherungsgeschäften.
Beispielprofile zur Tätigung von Versicherungsgeschäften
Transformationskomponente – Während die Profilbildungskomponente Fragen über die Domain fragt, führt die Transformationskomponente Berechnungen über die Domain aus und speist die Ergebnisse zur weiteren Analyse durch die Profilbildungskomponente zurück. Dies vereinfacht die Modellbildung von komplexen Geschäftssystemen, die andernfalls sehr schwierig als Teil der Anwendung auszuführen wären. In der Analysephase des Schnittstellen/Analyse/Interpretations-Ausführungsflusses agiert die Transformationskomponente tatsächlich auf die Domain, bevor die Profilbildungskomponente ihre Analyse durchführt. Die Transformationskomponente agiert als eine Muschel, die eine oder mehr Datenmodellbildungskomponenten zum Zwecke einer Integration dieser Komponenten in eine BusSim-Anwendung einwickelt. Die Transformationskomponente vereinfacht die Übertragung von bestimmten Daten von der Domain an die Datenmodellbildungskomponente (Eingaben), damit Berechnungen für die Daten durchgeführt werden, sowie die Übertragung der Ergebnisse der Berechnungen von der Datenmodellbildungskomponente zurück an die Domain (Ausgaben). 6 veranschaulicht eine Transformationskomponente. Die Datenmodellbildungskomponenten wären die Drittparteimodellbildungsumgebungen, wie beispielsweise eine tabellenkalkulationsbasierte Modellbildung (beispielsweise Excel, Formula1), oder eine diskrete zeitbasierte Simulationsmodellbildung (beispielsweise PowerSim, VenSim). Die Komponenten könnten auch in C++, VB, Access, oder einem beliebigen Werkzeug auf den Kunden zugeschnitten sein, das ODBC-verträglich ist, um einzigartige Modellbildungsumgebungen bereitzustellen.
Unter Verwendung der Transformationskomponente stellt ein Einwickeln einer Tabellenkalkulationskomponente eines Dritten einen einfachen Weg einer Integration in eine anwendungstabellenkalkulationsbasierte Datenanalyse bereit, die durch derartige Werkzeuge wie Excel geschaffen sind. Die Transformationskomponente stellt eine Muschel für die Tabellenkalkulation bereit, so dass sie in die Domain schauen kann, als Eingaben erforderliche Werte herausziehen kann, ihre Berechnungen durchführt, und Ausgaben zurück an die Domain sendet.
Falls beispielsweise der Geschäftsbericht einer Firma in der Domain gespeichert ist, würde die Domain die Grundliniendaten halten, wie z. B. wie viel Bargeld die Firma hat, was ihre Aktiva und Passiva sind, etc. Die Transformationskomponente wäre in der Lage, die Daten anzuschauen und zusätzliche Werte, wie Cashflowverhältnisse, ROI oder NPV von Investitionen, zu berechnen oder beliebige andere Berechnungen zur quantitativen Analyse der finanziellen Gesundheit der Firma durchführen. Abhängig von ihrer Komplexität könnten diese Berechnungen durch vorher existierende Teballenkalkulationen durchgeführt werden, in die ein Kunde bereits beträchtliche Entwicklungszeit gesteckt hat.
Förderunterrichtkomponente – Die Förderunterrichtkomponente ist ein Expertensystem, welches eine Integration von intelligenter Rückmeldung in BusSim-Anwendungen vereinfacht. Es hat die folgenden Merkmale: Fähigkeit zur Bildung einer hochqualitativen Textrückmeldung; Fähigkeit zur Bildung von Multimediarückmeldung, welche Video und/oder Audio umfasst; Fähigkeit zum Umfassen von Bezugsmaterial in Rückmeldung, wie beispielsweise Urheberwareseiten oder Webseiten und Fähigkeit zur aktiven Manipulation der Benutzerlieferungen, um Benutzerfehler hervorzuheben oder sogar zu beheben. Eine in diesen Rückmeldungskompositionsalgorithmus eingebettete bewährte Förderunterrichttheorie ermöglicht eine Integration von digitalen Aktiva in den Förderunterricht eines Trainings oder einer IPS-Anwendung. Das Förderunterrichtsmodell besteht aus drei primären Objekten: Konzepten; Nachhilfethemen und Nachhilfeposten. Konzepte sind Objekte, welche Realweltkonzepte repräsentieren, welchen der Benutzer in der Schnittstelle gegenüberstehen wird. Konzepte können in Unterkonzepte unterteilt werden, wodurch ein hierarchischer Konzeptbaum geschaffen wird. Dieser Baum kann beliebig tief und breit sein, um eine reiche Konzeptmodellbildung zu unterstützen. Konzepte können auch eine beliebige Anzahl von Nachhilfethemen besitzen. Nachhilfethemen sind Objekte, welche ein Diskussionsthema repräsentieren, das für ein Konzept geeignet sein kann. Nachhilfethemen können eine beliebige Anzahl an Nachhilfepunkten besitzen. Nachhilfeposten sind Posten einer Rückmeldung, welche Text, Audio, Video, URLs, oder Aktualisierungen für das Domainmodell umfassen können. Nachhilfeposten sind Nachhilfethemen zueigen und werden durch den Förderunterrichtskomponentenalgorithmus zusammengesetzt.
Arbeitsbanken – Das BusSim-Werkzeugset umfasst auch ein Set von Arbeitsbanken, welche durch die Lehrdesigner verwendet werden, um BusSim-Anwendungen zu gestalten bzw. zu entwerfen bzw. zu designen und aufzubauen. Eine Arbeitsbank ist ein Werkzeug, welches ein visuelles Bearbeiten oder Testen der Daten vereinfacht, welche die BusSim-Komponenten zur Bestimmung eines Anwendungslaufzeitverhaltens verwenden. Das BusSim-Werkzeugset umfasst die folgenden Arbeitsbanken:
Wissensarbeitsbank – Die Wissensarbeitsbank ist ein Werkzeug zur Schaffung einer Domain, Analyse und Rückmeldung von Daten, welche durch die BusSim-Komponenten verwendet werden. Es hat die folgenden Merkmale: Es ermöglicht, dass der Designer Wissen in einer "Ziehen-und-Ablegen"-Schnittstelle "malt"; Wissen wird zur einfachen Kommunikation unter Designern visuell dargestellt; die Schnittstelle ist intelligent, wodurch es Designern ermöglicht wird, nur gültige Interaktionen zu malen; Aufgabenschaffungen des Designers werden in einer zentralen Ablage gespeichert; die Arbeitsbank unterstützt einchecken/auschecken zur exklusiven Bearbeitung einer Aufgabe; sie unterstützt LAN-basiertes oder ungebundenes Bearbeiten; sie erzeugt automatisch eine Dokumentation der Designs; und sie erzeugt die Datendateien, welche das Verhalten der Komponenten ansteuern können. Simulierter-Schülertest-Arbeitsbank – Die Simulierter-Schülertest-Arbeitsbank ist ein Werkzeug für die Schaffung von Daten, welche Schüleraktionen zum Testen von Verhalten von BusSim-Komponenten simuliert. Es hat die folgenden Merkmale: Die Testbank erzeugt eine simulierte Anwendungsschnittstelle auf der Grundlage des Domainmodells; der Designer manipuliert die Objekte in dem Domainmodell, um eine Schüleraktivität zu simulieren; der Designer kann die Komponenten zur Erfahrung der Interaktionen aufrufen, die der Schüler bei der Produktion erfahren wird; und der Designer kann das Interaktionsverhalten vor einer Entwicklung der Anwendungsschnittstelle voll testen. Regressionstestarbeitsbank – Die Regressionstestarbeitsbank bzw. Rückschritttestarbeitsbank ist ein Werkzeug zum erneut Abspielen und Testen von Schülersitzungen, um beim Fehlerfinden zu helfen. Es hat die folgenden Merkmale: Jede Schülesitzung kann durch di Komponenten individuell erneut abgespielt werden; eine beliebige Anzahl von Schülereinreichungen von derselben Sitzung kann aufeinanderfolgend erneut abgespielt werden; komplette Schülersitzungen können in einem Stapel sofort erneut abgespielt werden; die Interaktionsergebnisse des Schüler werden mit den Ergebnissen des Regressionstest zum Vergleich nebeneinandergestellt.
Entwicklungszyklusaktivitäten
Die Designphase einer BusSim-Anwendung wird durch die Verwendung der Wissensarbeitsbank optimiert. Die Wissensarbeitsbank ist ein visueller Bearbeiter zur Konfiguration der Objekte der Komponentenmaschinen zur Steuerung ihres Laufzeitverhaltens. Die Komponenten basieren auf bewährten Algorithmen, welche beste Praktiken einfangen und ausführen und ein konzeptionelles Gerüst und Methodologie für ein Lehrdesign bereitstellen. Bei einem konzeptionellen Design lässt es die Arbeitsbank zu, dass der Designer ein Model der Hierarchie von Konzepten malt bzw. zeichnet, welche der Schüler bei der Aktivität meistern werden muss. Dies hilft dem Designer, den Inhalt auf eine logische Weise zu organisieren. Die visuelle Darstellung der Konzepte hilft, Ideen an andere Designer zur Durchsicht zu kommunizieren. Das konsistente Aussehen und Gefühl der Arbeitsbank trägt auch zu einem optimierten Qualitätssicherungsprozess bei. Darüber hinaus kann für das gesamte Design eine Standarddokumentation automatisch erzeugt werden. Mit Fortschritt der Designphase fügt der Designer mehr Einzelheiten zu dem Design der Konzepthierarchie durch Zeichnen von Nachhilfethemen hinzu, für die der Schüler eine Rückmeldung brauchen könnte. Der Designer kann mehrere Rückmeldungsthemen mit jedem Konzept in Zusammenhang bringen. Der Designer charakterisiert auch jedes Thema als Loben, Überarbeiten, Fokussieren, Neu Lenken, oder eines von mehreren anderen Typen einer Rückmeldung, die mit einer bewährten Förderunterrichtmethodologie übereinstimmen. Der Designer kann dann jedes Thema mit Text, Videokriegsspielen, Webseitenverknüpfungen, Vefasserwareverknüpfungen, oder beliebigen anderen Medienobjekten füllen, die an den Schüler als Teil des Rückmeldungsthemas geliefert werden können.
Das Werkzeugset reduziert den Aufwand während eines Funktionalitätstestens in großem Maße. Der Schlüsseltreiber der Aufwandreduktion besteht darin, dass die Komponenten automatisch die Aktionen des Testers ohne Bedarf zum Hinzufügen von Codeunterstützung in der Anwendung nachverfolgen können. Wann immer der Tester eine Aktion in der Schnittstelle vornimmt, wird dies an das Domainmodell berichtet. Von dort kann es in einer Datenbank nachverfolgt werden. Tester müssen nicht länger ihre Aktionen zur Verwendung beim Fehlersuchen niederschreiben; sie werden automatisch in eine Disk geschrieben. Es gibt auch ein Merkmal zum Anhängen von Kommentaren zu Aktionen eines Testers. Wenn ein unerwartetes Verhalten angetroffen wird, kann der Tester eine Steuertastenabfolge betätigen, welche einen Dialog aufmacht, um eine Beschreibung des fehlerhaften Verhaltens aufzuzeichnen. Während der Ausführungsphase bzw. Aufbauphase werden die Komponenten auf der Schülerplattform eingesetzt. Sie stellen simulierte Teammitglieder und Rückmeldungsfunktionalität mit einer Antwortzeit im Bereich von weniger als Sekunden und einem fehlerfreien Betrieb dar. Falls es der Kunde wünscht, kann ein Schülernachverfolgungsmechanismus in Echtzeit zur Bewertung und Administration von Schülern zum Einsatz kommen. Dies ermöglicht auch die Isolation von beliebigen Defekten, die es bis zur Produktion gebracht haben könnten.
Szenarios zur Verwendung des Geschäftssimulationswerkzeugsets
Ein guter Weg zur Erzielung eines besseren Anerkenntnis davon, wie das BusSim-Werkzeugset immens den BusSim-Entwicklungsaufwand verbessern kann, ist durch Szenarios darüber zu laufen, wie die Werkzeuge während des Entwicklungslebenszyklus einer bestimmten Aufgabe in einer BusSim-Anwendung verwendet werden würden. Für diesen Zweck sei angenommen, dass es das Ziel des Schülers bei einer bestimmten Aufgabe ist, Rechnungstransaktionen in ein Journal einzutragen, und dass diese Aufgabe in dem breiteren Kontext eines Lernens der Grundlagen einer Finanzbuchhaltung liegt. Eine kursorische Beschreibung der Aufgabe aus der Perspektive des Schülers wird helfen, den Kontext für die Szenarios zu setzen. In der nachfolgenden Beschreibung sind fünf Szenarios, welche verschiedene Aktivitäten bei der Entwicklung dieser Aufgabe beschreiben. Die nachfolgende Figur zeigt eine Bildschirmaufnahme der Aufgabenschnittstelle. 7 veranschaulicht die Verwendung eines Werkzeugbalkens zur Navigation und zum Zugriff auf Anwendungsebenenmerkmale. Ein Schüler verwendet einen Werkzeugbalken zur Navigation und zum Zugriff auf einige Anwendungsebenenmerkmale der Anwendung. Der Werkzeugbalken ist das invertierte L-förmige Objekt über den oberen und linken Teil der Schnittstelle. Der obere Abschnitt des Werkzeugbalkens ermöglicht es dem Benutzer, zu Aufgaben in der derzeitigen Aktivität zu navigieren. Der linke Abschnitt des Werkzeugbalkens ermöglicht es dem Benutzer, auf andere Merkmale der Anwendung einschließlich Rückmeldung, zuzugreifen. Der Schüler kann seine Lieferungen analysiert bekommen und eine Rückmeldung empfangen, indem er auf die Teamschaltfläche klickt.
Bei dieser Aufgabe muss der Schüler 22 Rechnungen und andere Quelldokumente in ein Journal eintragen, um den Fluss von Etatdollars zwischen internen Konten aufzuzeichnen. (Es sei erwähnt: "In ein Journal eintragen" oder "Eintrag in ein Journal" ist der Prozess eines Aufzeichnens von Journaleinträgen in ein allgemeines Kontenblatt aus Rechnungen oder anderen Quelldokumenten während einer Kontierungsperiode. Der Prozess zieht ein Schaffen von Abbuchungs- bzw. Lastschrift- und Bilanzierungsgutschrifteinträgen für jedes Dokument nach sich. Bei der Vollendung dieses Prozesses werden die allgemeinen Kontenblattaufzeichnungen verwendet, um eine Probebilanz und nachfolgende Finanzberichte zu schaffen. Intelligenter-Nachhilfevermittler-Werkzeug (ICAT) wurde entwickelt, um die Schaffung und Lieferung von Rückmeldung in einer hochkomplexen Umgebung mit offenem Ende zu standardisieren und zu vereinfachen. Eine Rückmeldung von einem Coach bzw. Nachhilfevermittler oder Tutor ist beim Führen des Lernenden durch eine Anwendung instrumentell. Darüber hinaus wird durch Diagnose von Problembereichen und Empfehlung von spezifischen Aktionen auf der Grundlage von vorhergesagtem Schülerverstehen der Domain ein Schülerverständnis von Schlüsselkonzepten erhöht. Durch Schreiben von Regeln und Rückmeldung, welche einer bewährten Rückmeldungsstrategie entspricht, wird konsistente Rückmeldung durch die Anwendung hindurch ungeachtet des Interaktionstyps oder des bestimmten Designers/Entwicklers abgeliefert, der die Rückmeldung schafft. Das ICAT ist mit einer benutzerfreundlichen Arbeitsbank verpackt, so dass es erneut verwendet werden kann, um die Produktivität für Projekte zu erhöhen, die eine ähnliche regelbasierte Datenmaschine und Ablage erfordern.
Definition von ICAT gemäß einem bevorzugten Ausführungsbeispiel
Das Intelligenter-Nachhilfevermittler-Werkzeug (ICAT) ist eine Folge von Werkzeugen – eine Datenbank und eine Laufzeitmaschine einer dynamischen Bibliothek (DLL) – die durch Designer verwendet werden, um eine sofortige Rückmeldung von zielbasiertem Training zu schaffen und auszuführen. Designer schreiben Rückmeldung und Regeln in den Entwicklungswerkzeugen. Sobald die Rückmeldung gesetzt ist, überwacht die Laufzeitmaschine Benutzeraktionen, wirft Regeln aus und setzt Rückmeldung zusammen, welche das lieferbare Geschäft beschreibt. Das in dem ICAT verwendete Förderunterrichtsmodell setzt die meiste geeignete Rückmeldung dynamisch zusammen, die an einen Schüler auf der Grundlage von vorherigen Schülerantworten zu liefern ist. Das ICAT-Modell basiert auf einer Theorie von Rückmeldung, welche sich durch Vorergebnisse und informelle Interviews als effektiv bewährt hat. Das Modell wird in dem Objektmodell und Algorithmen des ICAT ausgeführt. Da das Modell in die Werkzeuge eingebaut ist, wird alle Rückmeldung, die mit dem Werkzeug geschaffen ist, mit dem Modell konform sein. ICAT spielt zwei Rollen beim Schülertraining. Erstens ist das ICAT ein Lehrsystem, welches Schülern hilft, Informationen voll zu verstehen und anzuwenden. Zweitens ist ICAT ein Türhüter bzw. Informationsregulator, der sicherstellt, dass jeder Schüler das Material gemeistert hat, bevor er zu zusätzlichen Informationen weitergeht. ICAT ist ein eigenständiges Modul, das von der Anwendung getrennt ist. Ein Trennen des ICAT von der Anwendung ermöglicht es anderen Projekten, das ICAT zu verwenden, und ermöglicht es Designern, Rückmeldung zu testen, bevor die Anwendung vollständig ist. Das ICAT-Modul ist auf sechs Prozesse gebildet, die es einem Schüler ermöglichen, effektiv mit der Schnittstelle zu interagieren, um die geeignete Rückmeldung für Fehler eines Schülers zusammenzusetzen und zu liefern. ICAT-Entwicklungsmethodologie ist eine Methodologie mit sieben Schritten zur Schaffung einer Rückmeldung. Die Methodologie enthält bestimmte Schritte, allgemeine Richtlinien und aus dem Gebiet gelernte Lehren. Eine Verwendung der Methodologie erhöht die Effektivität der Rückmeldung, um die Unterrichtsanforderungen des Kurses zu erfüllen. Die Prozesse enthalten jedes ein Wissensmodell und einige enthalten Algorithmen. Jeder Prozess hat bestimmtes Wissen, das in sein Design bzw. seine Gestaltung hineingebaut ist, um Förderunterricht und Lehrtätigkeit zu verbessern. Es gibt eine Folge von Testwerkzeugen für das ICAT. Diese Werkzeuge ermöglichen es Designern und Entwicklern, alle ihre Rückmeldung und Regeln zu testen. Darüber hinaus lassen die Betriebsmittel Designer Echtzeitaktivitäten von Schülern einfangen, wenn sie durch den Kurs gehen. Die Werkzeuge und die Laufzeitmaschine umfassen Expertenwissen von Förderunterricht. Diese Objekte umfassen Logik, welche eine Schülerarbeit analysiert, um Problembereiche zu identifizieren und fokussierte Rückmeldung abzuliefern. Die Designer müssen nur die Objekte realisieren, um die Werkzeuge zum Arbeiten zu bringen. Ein zum Ausdruck Bringen von Expertenwissen bei den Werkzeugen und der Maschine stellt sicher, dass jeder Abschnitt eines Kurses dieselbe effektive Rückmeldungsstruktur etabliert hat. Eine Dateistruktur stellt eine Standardsystemumgebung für alle Anwendungen bereit. Ein Entwicklungsverzeichnis hält eine Vielzahl von Unterverzeichnissen. Der Inhalt in dem Dokumentationsverzeichnis ist Teil einer separaten Installation von der Architektur. Dies gründet sich auf die Größe des Dokumentationsverzeichnisses. Es erfordert keine Unterstützungsdateien, so dass es auf ein LAN oder auf individuelle Computer gesetzt werden kann. Wenn die Architektur installiert ist, hat das Entwicklungsverzeichnis Entwicklungsverzeichnisse _Bogen, _Werkzeuge, _Betriebsmittel, Dokumentation, QED, und XStandardeinstellung. Jeder Ordner hat seine eigene Verzeichnisstruktur, die mit den anderen Verzeichnissen untereinander verlinkt bzw. verknüpft ist. Diese Struktur muss aufrechterhalten werden, um eine Konsistenz und Kompatibilität zwischen Projekten sicherzustellen, um Projektdifferenzen und Architekturaktualisierungen klarzustellen.
Das Verzeichnis _Bogen speichert viele der meisten gemeinsamen Teile der Systemarchitektur. Diese Dateien ändern sich im Allgemeinen nicht und können in einem beliebigen Bereich des Projekts erneut verwendet werden. Falls es einen allgemeinen Visual Basic Code für Anwendungen gibt, die kontinuierlich in anderen Anwendungen verwendet werden, werden die Dateien in einem Ordner in diesem Verzeichnis untergebracht. Die Unterverzeichnisse in dem Verzeichnis _Bogen sind in bestimmte Objekte des Hauptprojekts unterteilt. Ein Objekt bezieht sich in diesem Fall auf Teile eines Projekts, auf die gemeinsam in dem Projekt Bezug genommen wird. Beispielsweise sind hier Module und Klassen definiert, und das Verzeichnis ist analog zu einer Bibliothek von Funktionen, APIs, etc. ..., die sich nicht ändern. Beispielsweise speichert das Verzeichnis IcaObj Code für den Intelligenten Nachhilfevermittler (ICA). Das Verzeichnis InBoxObj speichert Code für den InBox-Teil des Projekts und so weiter. Die Dateistruktur verwendet einige Primärobjektliteraturnachweise als Dateiverzeichnisse. Beispielsweise ist das Verzeichnis ICAObj eine Komponente, welche Primärobjekte für das ICA, wie beispielsweise funktionelle Formen, Module und Klassen enthält. Das Verzeichnis BrowserObj enthält Module, Klassen und Formen, die sich auf die Browserfunktionalität in der Architektur beziehen. Das Verzeichnis HTML-Glossar enthält Code, der für den HTML-Literaturnachweis und die -Glossarkomponente der Architektur Verwendung findet. Das Verzeichnis IcaObj enthält ICA-Funktionscode, der bei einer Anwendung zu verwenden ist. Dieser Code wird realisiert und verbessert. Das Verzeichnis InBoxObj enthält Code, der die Eingabeboxfunktionalität betrifft, die mit der Architektur verwendet wird. Insbesondere gibt es zwei Hauptkomponenten in diesem Architekturverzeichnis. Es gibt eine neue Steuerung .ocx, die geschaffen wurde, um Funktionalität für eine Eingabebox in der Anwendung zu schaffen. Es gibt auch Code, der Unterstützung für eine Legendeneingabeboxanwendung bereitstellt. Das Verzeichnis PraxisObj enthält Code für die Themenkomponente der Architektur. Die Themenkomponente kann auch mit der HTML-Glossarkomponente ausgeführt werden. Das Verzeichnis QmediaObj enthält die Komponenten, die medienbezogen sind. Ein Beispiel ist die QVIDctrl.cls. Die QVIDctrl ist der Code, der die Verknüpfungen zwischen QVID-Dateien in einer Anwendung und dem System schafft. Das Verzeichnis SimObj enthält die Simulationsmaschine, eine Komponente der Anwendung, die den Tutor über Eingaben und Ausgaben unter Verwendung einer Tabellenkalkulation informiert, um Kommunikation zu vereinfachen. Das Verzeichnis StatObj hält eine beliebige Komponente, welche die Anwendung von dem Rest der Anwendung statisch verwenden wird. Beispielsweise wird die Logineingabemaske in diesem Ordner gehalten und wird als ein statisches Objekt verwendet. Das Verzeichnis SysDybObj enthält den Code, welcher es ermöglicht, dass die Systemdynamikmaschine (Powersim) Werte an die Simulationsmaschine gibt und die Werte an den Tutor zurückgibt. Das Verzeichnis VBObj enthält allgemeine Visual Basic Objekte, die in Anwendungen verwendet werden. Beispielsweise sind in diesem Ordner Was Nun Visual Basic Bezugseingabemasken, und spezifische Mitteilungsboxkomponenten in diesem Ordner gespeichert. Das Verzeichnis _Werkzeuge enthält zwei Hauptverzeichnisse. Sie repräsentieren die zwei am häufigsten verwendeten Werkzeuge. Die zwei Verzeichnisse stellen den Code für die Werkzeuge selbst bereit. Der Grund zur Bereitstellung des Codes für diese Werkzeuge ist, es einem Entwickler zu ermöglichen, bestimmte Teile der Werkzeuge zu verbessern, um ihre Fähigkeit zu erweitern. Dies ist für die derzeitige Projektentwicklung und auch für das Wachstum der Werkzeuge wichtig. Das Verzeichnis Icautils enthält die Verzeichnisse Daten, Datenbank, Standardeinstellungen, Graphiken, Icadoc, und Testdaten. Der Zweck aller dieser Verzeichnisse ist es, ein zweites Arbeitsverzeichnis für einen Entwickler bereitzustellen, um seine Testumgebung von verbesserten Icautils-Anwendungen separat von der Projektanwendung zu halten. Es ist nur als ein Testbett für das Werkzeug gebaut. Es sollte hier keine anwendungsspezifische Arbeit getan werden. Der Zweck für jedes dieser Verzeichnisse wird in größerer Tiefe in dem Projektverzeichnisabschnitt erläutert. Der Testdatenordner ist einzigartig für das Verzeichnis _Werkzeuge/ICAUtils. Es enthält Testdaten für die Regressionsbank unter anderen Komponenten in ICAUtils.
Das Verzeichnis Betriebsmittel hält die verfügbaren Betriebsmittel, die ein Geschäftssimulationsprojekt für optimale Ergebnisse erfordert. Dies ist eine Ablage für Code und ausführbare Betriebsmittel, welche Entwickler und Designer verwenden und verbessern können. Die meisten der Betriebsmittel sind kleine Anwendungen oder Werkzeuge, die bei der Produktion von Simulationen Verwendung finden können, welche eine Ausfuhrmöglichkeit und Code umfassen, um mit ihm für beliebige Verbesserungen oder Änderungen an dem Betriebsmittel vorzugehen. Falls neue Betriebsmittel in einem Projekt geschaffen werden oder existierende Betriebsmittel verbessert werden, ist es wichtig, die Manager oder Entwickler zu informieren, die mit einem Schritt Halten bzw. Nachverfolgen der Geschäftssimulationsaktiva betraut sind. Alle Verbesserungen, Änderungen oder Hinzufügungen zu den Geschäftssimulationstechnologieaktiva sind für zukünftige und existierende Projekte wichtig.

Bei dem ICAT-Modell einer Rückmeldung, gibt es vier Stufen einer Schwere eines Fehlers und vier entsprechende Stufen einer Rückmeldung. Der Tutor geht durch die Schülerarbeit, identifiziert die Schwere des Fehlers und stellt dann die entsprechende Stufe einer Rückmeldung bereit.

Pädagogische Kategorien einer Rückmeldung
FEHLER		RÜCKMELDUNG
Fehlertyp	Beschreibung	Rückkopplungstyp	Beschreibung
keiner	Es gibt keine Fehler. Die Schülerarbeit ist perfekt.	Lob	Bestätigung, dass der Schüler die Aufgabe korrekt vervollständigt hat. Beispiel: Hervorragend. Alle Konten wurden korrekt in das Journal eingetragen. Es freut mich zu sehen, dass Sie erkannt haben, dass wir die meisten unserer Abrechnungen „auf Konto" zahlen.
Syntaktischer	Es können Rechtschreibfehler oder andere syntaktische Fehler vorhanden sein. Als ein Designer sollten sie zuversichtlich sein, dass der Schüler bei diesem Punkt das Material bewältigt haben wird.	Überarbeiten	Teilt dem Schüler die spezifischen Aktionen mit, die er falsch gemacht hat und korrigiert sie möglicherweise für ihn. Beispiel: Es sind ein oder zwei Fehler in ihrer Arbeit. Es sieht so aus, als wenn sie das Kaufen des Fax inkorrekt als einen Barkauf klassifiziert haben, wobei es tatsächlich ein Kauf auf Rechnung ist.
lokaler	Ein Abschnitt einer Arbeit fehlt, oder der Schüler hat eine Anzahl von Fehlern alle in einem Bereich gemacht. Es ist klar, dass der Schüler diesen Bereich nicht versteht.	Fokussieren	Fokussiere den Schüler auf diesen Bereich der Arbeit. Zeige auf, dass er zumindest ein Hauptkonzept nicht versteht. Beispiel: Bei Durchsicht Ihrer Arbeit sehe ich, dass Sie das Konzept von „auf Konto" nicht verstehen. Schauen Sie doch dieses Konzept noch mal an, und sehen Sie ihre Arbeit auf Fehler durch.
globaler	Der Schüler hat über das falsche Thema geschrieben, oder es gibt in der gesamten Schülerarbeit Fehler.	Neulenken	Erneut das Ziel der Aktivität darlegen und dem Schüler mitteilen, dass) er Hauptkonzepte neu durchschauen soll und die Aktivität erneut versuchen soll. „Es gibt viele Fehler in Ihrer gesamten Arbeit. Sie müssen darüber nachdenken, welche Art von Transaktion jedes Quelldokument repräsentiert, bevor sie es in das Journal eintragen."

Eine Rückkehr zu der Analogie, jemanden zu helfen, einen Aufsatz zu schreiben, ist es ein globaler Fehler, der eine neulenkende Rückmeldung erfordert, falls der Schüler über das falsche Thema schreibt. Falls der Schüler mit dem umgeschriebenen Aufsatz zurückkehrt, jedoch mit vielen Fehlern in einem Bereich der Veröffentlichung, ist eine Fokusrückmeldung erforderlich. Wenn alle diese Fehler behoben sind, und es nur Rechtschreibfehler – syntaktische Fehler bzw. Grammatikfehler – gibt, ist eine Überarbeitungsrückmeldung erforderlich. Wenn alle syntaktischen Fehler korrigiert wurden, würde der Tutor lobend zurückkehren und neu darlegen, warum der Schüler den korrekten Ausatz geschrieben hat. Eine Fokussierung auf die Unterrichtskomponenten zur Vervollständigung einer Aufgabe ist nicht genug. Wie jeder Lehrer weiß, wird der Schüler oft seinen Weg durch eine Aufgabe versuchen und schummeln. Es kann sein, dass Schüler keine Arbeit tun und hoffen, der Lehrer merkt es nicht, oder der Schüler kann nur kleine Änderungen machen, in der Hoffnung auf einen Hinweis oder einen Teil der Antwort. Um diese administrativen Funktionen unterzubringen, gibt es drei zusätzliche administrative Kategorien einer Rückmeldung. Die administrative und die Unterrichtskategorie einer Rückmeldung berücksichtigen jeden Teil einer Rückmeldung, die ein Designer schreiben kann und ein Schüler empfangen kann. Um ein besseres Verständnis darüber bereitzustellen, wie die Rückmeldung zusammenarbeitet, ist nachfolgend ein Beispiel gegeben.
8 ist eine GBS-Anzeige. Der obere rechte Bereich des Bildschirms zeigt die Kontenliste. Es gibt vier Typen von Konten: Aktiva, Passiva und Eigenkapital, Einnahmen, und Ausgaben. Der Benutzer klickt auf eine der Tabs, um die Konten des entsprechenden Typs zu zeigen. Der Schüler trägt eine Transaktion durch Ziehen eines Postens bzw. Kontos von der Kontenliste in den Journalseintrag Lastschrift oder Gutschrift in das Journal ein. Der Schüler gibt dann die Dollarbeträge zur Lastschrift oder Gutschrift jedes Kontos in dem Eintrag ein. In der Schnittstelle kann der Schüler, wie im richtigen Leben, vielbeinige Journaleinträge haben (das heißt Lastschrift oder Gutschrift mehrerer Konten). Ein Werkzeugbalken 1200 und die erste Transaktion dieser Aufgabe 1210 erscheinen hervortretend auf der Anzeige. Der Schüler kann sich durch den Transaktionsstapel vorwärts und rückwärts bewegen. Für jede Transaktion muss der Schüler identifizieren, welche Konten abzubuchen bzw. eine Lastschrift vorzunehmen sind und welche gutzuschreiben sind. Wenn der Schüler fertig ist, klickt er auf die Teamschaltfläche. 9 ist eine Rückmeldungsanzeige. Der Schüler kann versuchen, das System durch Eintragung bzw. Abgeben ohne irgendetwas zu tun auszutricksen. Das ICAT-System identifiziert, dass der Schüler keine wesentliche Menge an Arbeit getan hat und gibt die administrative Rückmeldung zurück, die in 9 dargestellt ist. Die Rückmeldung legt dar, dass nichts getan worden ist, jedoch legt sie auch dar, dass falls der Schüler einige Arbeit tut, sich der Tutor auf die ersten paar Journalseinträge konzentrieren wird. 10 veranschaulicht eine Journalseintragsimulation. 11 veranschaulicht einen simulierten Bell-Telefonrechnungseintrag. Der Journalseintrag wird durch Abbuchen von Betriebsmittelsausgaben und Gutschrift für jeweils $700 bewerkstelligt. 12 veranschaulicht eine Rückmeldungsanzeige. Nach einem Versuch, die ersten drei Transaktionen in das Journal einzutragen, gibt der Schüler seine Arbeit ab und empfängt die in 12 dargestellte Rückmeldung. Die Rückmeldung startet durch Fokussieren des Schülers auf den ausgewerteten Arbeitsbereich. Das ICAT legt dar, dass es nur auf die drei ersten Journalseinträge schaut. Die Rückmeldung legt dar, dass die ersten zwei Einträge völlig falsch sind, jedoch der dritte nahe kommt. Falls der Schüler bei jedem der ersten drei Transaktionen große Fehler gemacht hat, dann kann das ICAT eine neulenkende Rückmeldung gegeben haben, da es denkt, dass ein globaler Fehler aufgetreten ist. Der dritte Aufzählungspunkt hebt auch hervor, wie spezifisch die Rückmeldung werden kann, wodurch nahe Verluste identifiziert werden.
Designszenario – Dieses Szenario veranschaulicht, wie die Werkzeuge verwendet werden, um konzeptionelles und detailliertes Design einer BusSim-Anwendung zu unterstützen. 13 veranschaulicht die Schritte des ersten Szenarios. Der Designer hat Erfordernisse gesammelt und bestimmt, dass zur Unterstützung der Kundenlernaufgaben eine Aufgabe erforderlich ist, welche Journaleintragfertigkeiten lehrt. Der Designer beginnt das Design zuerst durch selber Lernen eines Eintrags in ein Journal, und dann durch Verwendung der Wissensarbeitsbank, eine Hierarchie der Konzepte zu skizzieren, die er möchte, dass sie der Schüler lernt. Auf der allgemeinsten Stufe schafft er ein Wurzelkonzept von "Eintrag in ein Journal". Er macht dies feiner durch Definition von Unterkonzepten von "Geld bezogene Transaktionen", "Ausgaben bezogene Transaktionen", und "Ausgaben über Kontotransaktionen". Diese werden jeweils feiner unterteilt, auf welche Tiefenstufe auch immer erforderlich ist, um die Qualität des Lernens und die Verlässlichkeit der Simulation zu unterstützen. Der Designer gestaltet dann die Journaleintragschnittstelle. Da es ein guter Weg ist, durch Selbermachen zu lernen, entscheidet er, dass der Schüler aufgefordert werden sollte, ein Set von Transaktionen in ein Journal einzutragen. Er kommt mit einem Satz von 22 Dokumenten, welche solche verkörpern, mit denen ein Finanzexperte bei der Arbeit konfrontiert sein könnte. Sie umfassen die Skala von Transaktionen Aktiva-, Ausgaben-, Passiva- und Eigenkapital und Einnahmen. Es sind auch einige Dokumente umfasst, von denen nicht angenommen wird, dass sie in das Journal eingetragen werden. Diese "Verwirrobjekte" werden eingegliedert, da in dem realen Leben manchmal fehlgeleitete Dokumente auftreten. Der Designer verwendet dann die Domainmodellmerkmale in der Wissensarbeitsbank, um ein Journal zu zeichnen. In dem Domainmodell wird ein Gebilde geschaffen, um jede Transaktion und jedes Quelldokument zu repräsentieren. Auf der Grundlage der 22 Dokumente, die der Designer wählt, kann er Fehler vorwegnehmen, die der Schüler machen könnte. Für diese Fehler schafft er Rückmeldungsthemen und füllt sie mit Text. Er schafft auch Rückmeldungsthemen, um dem Schüler mitzuteilen, wenn sie Erfolg gehabt haben. Rückmeldungsthemen werden geschaffen, um eine Variation von Situationen zu handhaben, die der Schüler verursachen kann.
Der nächste Schritt ist, Profile zu schaffen, welche die Themen in dem Konzeptbaum triggern (diese Aufgabe ist nicht rechnender Natur, so dass die Transformationskomponente nicht konfiguriert werden muss). Ein Profil ergibt wahr, wenn seine Bedingungen durch die Schülerarbeit erfüllt sind. Jedes Profil, das wahr ergibt, triggert ein Thema. Um einiges vorbereitendes Testen über das Design vorzunehmen, ruft der Designer die Schülersimulatortestarbeitsbank auf. Der Designer kann das Domainmodell manipulieren, als wenn er der Schüler wäre, der in der Schnittstelle arbeitet. Er zieht Konten zu verschiedenen Transaktionen herum, was angibt, wie er sie gerne in das Journal eingetragen haben würde. Er gibt auch die Dollarbeträge ein, die sie jedem Konto gerne zur Last schreiben bzw. abbuchen oder gutschreiben würde. Er gibt seine Aktionen an die Komponentenmaschinen weiter, um die Rückmeldung zu sehen, die der Schüler bekommen würde, falls er die Aktivität auf dieselbe Weise durchgeführt hätte. All dies tritt in der Testbank ohne eine Anwendungsschnittstelle auf. Der letzte Schritt in dieser Phase ist niedriges-fi- Benutzertesten. Ein Testschüler interagiert mit einem Powerpointdia oder -Bitmap der vorgeschlagenen Schnittstelle für die Journaleintragaufgabe. Ein Schulungsleiter mimt seine Aktionen in der Testbank und teilt ihm mit, was die Rückmeldung sein würde. Dies vereinfacht ein niedrig-fi-Benutzertesten und hilft dem Designer, Verwendbarkeitssachverhalte in dem Design eher zu identifizieren, wenn sie viel preisgünstiger zu lösen sind.
14 und 15 veranschaulichen die mit einem gebauten Szenario in Zusammenhang stehenden Schritte. Der Lehrdesigner vervollständigt die Anfangsinteraktion und Schnittstellendesigns, wie bei dem vorhergehenden Szenario gesehen. Nach einem niedriges-fi-Benutzertesten beginnt die Bauphase bzw. Ausführungsphase. Graphikkünstler verwenden die Designs, um die Bitmaps zu schaffen, welche die Schnittstelle aufmachen werden. Diese umfassen Bitmaps für die Schaltflächen, Tabellen, und Transaktionen sowie alle anderen Bildschirmwidgets. Der Entwickler baut die Schnittstelle unter Verwendung der Bitmaps und fügt die Funktionalität hinzu, welche das Domainmodell über Schüleraktionen informiert. Es werden standardeventgesteuerte Programmiertechniken verwendet, um Code zu schaffen, der auf Events bzw. Ereignissen in der Schnittstelle während einer Anwendungsausführung reagieren wird, und zum weitergeben der richtigen bzw. geeigneten Informationen an das Domainmodell. Der Entwickler muss nicht irgendein tiefes Wissen über den Inhalt haben, da er keine Logik zu bauen hat, um eine Analyse der Schüleraktionen oder Rückmeldung zu unterstützen. Der Entwickler codiert auch die Logik zum Neuaufbau der Schnittstelle auf der Grundlage von Änderungen an dem Domainmodell. Typischerweise werden ein paar Durchläufe durch diese Schritte erforderlich sein, um zu erreichen, dass die Anwendung korrekt mit den Komponenten kommuniziert. Die Fehlersuchbetriebsmittel und die Regressionstestarbeitsbank rationalisieren den Prozess. Nachdem die Anwendungsschnittstelle und die Komponentenkommunikation wie gestaltet funktionieren, geht die Aufgabe zum Verwendbarkeitstesten weiter.
Das Testszenario demonstriert den Zyklus, den das Team durchgeht, um die Anwendung zu testen. Es wendet sich insbesondere an ein Verwendbarkeitstesten, jedoch ist es leicht zu sehen, wie die Werkzeuge auch von funktionalem und Verstandestesten profitieren. Erneut wird Journaleintragaufgabe als ein Beispiel verwendet. 16 veranschaulicht ein Testszenario. Der Testschüler arbeitet durch die Journaleintragaktivität. Einer der Schüler hat bereits die Hälfte der Aufgabe geschafft und hat gerade versucht, die sechzehnte Transaktion in das Journal einzutragen. Der Schüler gibt an den Finanznachhilfevermittler ab, jedoch kommt die Rückmeldung leer zurück. Der Schüler informiert den Schulungsleiter mit einem Rechtsklick auf das Gesicht des Finanznachhilfevermittlers in dem Rückmeldungsfenster. Es springt ein Dialog auf, welcher dies bei der 27. Einreichung bzw. Abgabe zeigt, und einige andere Einzelheiten über die Abgabe zeigt. Der Schulungsleiter (oder sogar der Schüler bei kürzlich geschehenen Anstrengungen) gibt eine Textbeschreibung des Problems ein, und füllt einige andere Felder aus, um die Natur und Schwere des Problems anzugeben. Alle Schülerarbeit und die Rückmeldung, die sie für die 27 Abgaben bekommen haben, wird an die Benutzerakzeptanztest-Archivdatenbank (UAT-Archivdatenbank) gesendet. Der Lehrdesigner kann alle Schülerhistorien in der UAT-Datenbank anschauen und die Sitzung wiedergewinnen, in welcher der fragliche Schüler die Journaleintragaufgabe versucht hat. Der Designer schafft dann das Problem neu, indem er 27 Abgaben des Schülers durch die Komponentenmaschinen unter Verwendung der Regressionstestdatenbank erneut abspielt. Der Designer kann dann durch jede Abgabe, die ein Schüler gemacht hat, browsen und die Arbeit, die der Schüler für die Abgabe getan hat, die Rückmeldung, die der Schüler bekommen hat, und die Schulungsleiterkommentare, falls es welche gibt, anschauen. Der Designer kann nun die Fehlersuchwerkzeuge verwenden, um die Quelle des Problems zu bestimmen. In ein paar Minuten ist er in der Lage zu bestimmen, dass zusätzliche Profile und Themen erforderlich sind, um die speziellen Kombinationen von Fehlern zu adressieren, die der Schüler gemacht hat. Er verwendet die Wissensarbeitsbank, um die neuen Profile und Themen zu gestalten. Er fügt auch einen Platzhalter und ein Skript für eine Videokriegsspielgeschichte hinzu, welche das Lernen unter diesen Umständen unterstützt. Der Designer sichert das neue Design der Aufgabe und lässt die Regressionstestarbeitsbank über die Schülersitzung mit dem neuen Aufgabendesign laufen. Nachdem er zufrieden ist, dass die neuen Profile, Themen, und Kriegsgeschichten die gewünschte Verpackung geben, versendet er die neue Aufgabendesigndatei zum Benutzertesten, und sie wird an alle Benutzer ausgeliefert.
Ausführungsszenario: Schüleradministration – 17 veranschaulicht, wie die Werkzeugfolge eine Schüleradministration unterstützt. Wenn ein Schüler zuerst in einen Kurs eintritt, führt er einen Vortest seiner Finanzfertigkeiten durch und füllt ein Informationsblatt über seine Arbeitsstellenrolle, -stufe, etc. aus. Diese Informationen werden dem Domainmodell berichtet. Die Profilbildungskomponente analysiert den Vortest, das Informationsblatt, und beliebige andere Daten, um den speziellen Lernbedarf dieses Schülers zu bestimmen. Für diesen Schüler wird aus der Aufgabenbibliothek ein Lehrplan dynamisch konfiguriert. Die Anwendung konfiguriert ihre Hauptnavigationsschnittstelle (falls die Anwendung eine hat), um anzugeben, dass dieser Schüler, neben anderen Dingen, Eintrag in ein Journal lernen muss. Mit Fortschreiten des Schülers durch den Kurs, zeigt seine Arbeitsleistung an, dass seine Professionalität in einigen Bereichen schneller als in anderen wächst. Auf der Grundlage dieses Ergebnisses wird der Lehrplan geändert, um ihm zusätzliche Aufgaben zu geben, die ihm helfen werden, den Inhalt zu meistern bzw. zu bewältigen, mit dem er Schwierigkeiten hat. Außerdem können Aufgaben entfernt werden, in denen er Professionalität demonstriert hat. Während der Schüler die Arbeit in den Aufgaben durchführt, werden jede Aktion, die er vornimmt, die Rückmeldung, die er bekommt, und alle anderen Anzeichen von Arbeitsleistung in der Schülernachverfolgungsdatenbank nachverfolgt. Von Zeit zu Zeit werden ein Teil oder alle der nachverfolgten Daten an einen zentralen Ort gesendet. Die Daten können verwendet werden, um zu verifizieren, dass der Schüler alle Arbeit vervollständigt hat, und sie kann weiter analysiert werden, um seinen Grad von Meisterung des Inhalts zu analysieren.
Ausführungsszenario: Schülerinteraktion – 18 veranschaulicht eine Folge zur Unterstützung einer Schülerinteraktion. Bei dieser Aufgabe versucht der Schüler, Rechnungen in ein Journal einzutragen. Er sieht ein Diagramm von Konten, eine Rechnung und einen Journaleintrag für jede Rechnung. Er trägt eine Transaktion durch Ziehen und Ablegen eines Kontos von dem Diagramm von Konten auf die Zeil "Lastschrift" oder "Gutschrift" des Journaleintrags und durch Eingabe des Dollarbetrag der Lastschrift oder der Gutschrift in das Journal ein. Er tut dies für jede Transaktion. Wenn der Schüler mit der Schnittstelle interagiert, werden alle Aktionen an das Domainmodell berichtet und in ihm aufgezeichnet. Das Domainmodell hat ein Metamodell, das eine Transaktion, seine Daten, und zusätzlich beschreibt, welche Informationen ein Journaleintrag enthält. Die Aktionen des Schülers bevölkern die Gebilde in dem Domainmodell mit den richtigen Informationen. Wenn der Schüler fertig ist, gibt er die Arbeit an ein simuliertes Teammitglied zur Durchsicht ab. Diese Abgabe triggert den Analyseinterpretationszyklus. Die Transformationskomponente wird aufgerufen und führt zusätzliche Berechnungen für die Daten in dem Domainmodell durch, wobei sie vielleicht bestimmt, dass für einen gegebenen Journaleintrag Lastschriften und Gutschriften unausgeglichen sind. Die Profilbildungskomponente kann dann ein regelbasiertes Musterabstimmen auf dem Domainmodell durchführen, wobei sowohl die Schüleraktionen als auch die Ergebnisse jeder Transformationskomponentenanalyse geprüft werden. Einige der Profile lösen aus, wenn sie die Fehler und korrekten Antworten identifizieren, die der Schüler gegeben hat. Jedes Profile, dass auslöst, aktiviert Themen in der Förderunterrichtskomponente. Nachdem die Profilbildungskomponente vervollständigt ist, wird die Förderunterrichtskomponente aufgerufen. Der Förderunterrichtsalgorithmus sucht die aktiven Themen in dem Konzeptbaum, um das beste abzuliefernde Themenset zu bestimmen. Dieses Set kann Text, Video, Audio, URLs, und sogar Aktionen enthalten, die das Domainmodell manipulieren. Es wird dann in prosaähnliche Absätze aus Text und Medien zusammengesetzt und dem Schüler präsentiert. Die Textrückmeldung hilft dem Schüler, seine Journaleintragfehler zu lokalisieren und zu verstehen, warum sie falsch sind und was benötigt wird, um die Fehler zu korrigieren. Dem Schüler wird die Möglichkeit präsentiert, eine Videokriegsgeschichte über die steuerlichen und rechtlichen Konsequenzen anzuschauen, die aus einem inkorrekten Eintrag in ein Journal entstehen. Im werden auch Links bzw. Verknüpfungen zu den Literaturnachweismaterialen präsentiert, welche die Grundlagen des Eintrags in ein Journal beschreiben. Der Analyseinterpretationszyklus endet, wenn beliebige Nachhilfesachverhalte, die Aktualisierungen des Domainmodells zur Folge haben, versendet worden sind und die Schnittstelle erneut herangezogen wird, um die neuen Domaindaten zu repräsentieren. In diesem Fall wählte der Designer, die Transaktionen mit einem roten Häkchen hervorzuheben, die der Schüler inkorrekt in das Journal eingetragen hat.
Die funktionale Definition des ICAT
Dieser Abschnitt beschreibt die Rückmeldungsprozesse. Für jeden Prozess gibt es eine Definition des Prozesses und eine Beschreibung hohen Niveaus des Wissensmodells. Diese Definition beabsichtigt, dem Leser ein Grundverständnis von einigen der Schlüsselkomponenten/Objekten in dem Modell zu geben, so dass er mit den verbleibenden Anschnitten dieser Veröffentlichung fortsetzen kann. Siehe bei den detaillierten Komponenten des ICAT für eine ausführlichere Beschreibung jeder der Komponenten in jedem Wissensmodell. Zur Erlangung eines allgemeinen Verständnisses sind nur die allgemeinen Beschreibungen zu lesen. Um das ICAT tief zu verstehen, ist dieser Abschnitt und der Abschnitt detaillierte Komponente in Bezug auf Wissensmodelle und Algorithmen zu lesen. Diese Prozesse und Algorithmen führen das Rückmeldungsmodell in dem ICAT aus. Es gibt sechs Hauptprozesse in dem ICAT, die nachfolgend und ausführlicher auf den folgenden Seiten beschrieben sind.
19 veranschaulicht den Förderunterrichtsprozess. Förderunterricht startet, wenn Schüler mit der Anwendungsschnittstelle (Prozess #1) interagieren. Wenn der Schüler versucht, das lieferbare Geschäft zu vervollständigen, sendet die Anwendung Mitteilungen an das ICAT über jede vorgenommene Aktion (Prozess #2). Wenn der Schüler fertig ist und Arbeit zur Durchsicht abgibt, vergleicht das ICAT, wie der Schüler die Aktivität vervollständigt hat damit, wie der Designer dargelegt hat, dass die Aktivität vervollständigt werden sollte (dies wird Domainwissen genannt). Aus diesem Vergleich erlangt das ICAT eine Zählung, wie viele Punkte bzw. Gegenstände richtig, falsch oder irrelevant sind (Prozess #3). Ist die Zählung vollständig, versucht das ICAT alle Regeln auszulösen (Prozess #4). Beliebige Regeln, welche auslösen, aktivieren eine Nachhilfethema (Prozess #5). Der Rückmeldungsalgorithmus wählt Rückmeldungsstücke zum anzeigen aus und setzt sie in kohärente Textabschnitte zusammen (Prozess #6). Schließlich ersetzt das ICAT, als Teil eines Schaffens von Rückmeldungstextabschnitten, alle Variablen in der Rückmeldung mit Besonderheiten aus der Schülerarbeit. Dies gibt der Rückmeldung noch mehr Besonderheit, so dass sie wirklich auf alle Schüleraktionen speziell zugeschnitten ist.
Wissensmodell – Schnittstellenobjekte In jeder GBS-Aufgabe muss der Schüler Steuerungen der Anwendungsschnittstelle manipulieren, um die erforderlichen Ablieferungen zu vervollständigen. 20 veranschaulicht die Objekte für die Journaleintragaufgabe. Die folgenden Kurzfassungsobjekte werden verwendet, um alle verschiedenen Typen von Schnittstelleninteraktionen als Modell zu bilden. Ein QuellenPosten ist ein Objekt, das der Schüler zur Vervollständigung einer Aufgabe verwendet. Bei dem Journaleintragbeispiel macht der Schüler eine Lastschrift und eine Gutschrift für jede Transaktion. Der Schüler hat ein endliches Set von Konten, mit welchen für jede Transaktion zu antworten ist. Jedes Konto, das in der Schnittstelle erscheint, hat ein entsprechendes QuellenPostenobjekt. Mit anderen Worten, die Posten, die der Schüler manipulieren kann, um die Aufgabe (Kontonamen) zu vervollständigen), werden QuellenPostene genannt. Eine Quelle ist ein Objekt, das ein Set von QuellenPostenobjekten zusammen gruppiert. Quellenobjekte haben eine Eins-zu-vielen-Beziehung mit QuellenPostenobjekten. In dem Journaleintragbeispiel gibt es vier Typen von Konten: Aktiva, Passiva und Eigenkapital, Einnahmen und Ausgaben. Jedes Konto ist eins und nur eins von diesen Typen und erscheint daher nur unter dem richtigen Tab. Für jedes der Kontotyptabs gibt es ein entsprechendes Quellenobjekt. Ein Ziel ist ein fixierter Platz, an welchem Schüler Quellenposten platzieren, um eine Aufgabe zu vervollständigen. Bei dem Journaleintragbeispiel platziert der Schüler Konten auf zwei mögliche Ziele: Lastschrift und Gutschrift. Die oberen zwei Zeilen der Journaleintragkotrolle sind Lastschriftziele und die unteren zwei Zeilen sind Gutschriftziele. Diese zwei Ziele sind spezifisch für die zwölfte Transaktion. Eine Zielseite ist ein Objekt, welches ein Set von Zielobjekten zusammen gruppiert. Zielseitenobjekte haben eine Eins-zu-vielen-Beziehung mit Zielobjekten (genau wie die Beziehung zwischen Quelle und Quellenposten). In dem Journaleintragbeispiel gibt es einen Eintrag für jede der 22 Transaktionen. Für jeden Journaleintrag gibt es ein entsprechendes ZielSeitenobjekt, das die Lastschriftziele und Gutschriftziele für diesen Journaleintrag enthält.
Wenn der Schüler die Anwendungsschnittstelle manipuliert, wird jede Aktion an das ICAT berichtet. Um dem ICAT mitzuteilen, welche Aktionen vorgenommen wurden, ruft die Anwendung eine Datenbank auf und fragt nach einer spezifischen Schnittstellensteuer-ID. Wenn die Anwendung die ID (Identifikation) der Zielsteuerung und die QuellenPostensteuerung hat, teilt die Anwendung der ICAT die Abbildung von Ziel auf QuellenPosten mit. Mit anderen Worten, jedes Mal, wenn ein Schüler einen Quellenposten manipuliert und ihn mit einem Ziel in Verbindung bringt (das heißt, Ziehen eines Kontonamens zu einer Lastschriftzeile in dem Journal), wird die Benutzeraktion als eine Abbildung des QuellenPostens auf dem Ziel aufgezeichnet. Diese Abbildung wird ein BenutzerQuellenPostenZiel genannt. 21 veranschaulicht die Abbildung eines QuellenPostens auf einem Zielposten. Wenn der Schüler fertig ist, gibt er seine Arbeit an eins der simulierten Teammitglieder ab, indem er auf die Teammitgliedschaltfläche klickt. Wenn das ICAT die Schülerarbeit empfängt, berechnet es, wie viel der Arbeit per Konzept korrekt ist. Konzepte bei unserer Journaleintragaktivität werden Lastschriften, Gutschriften, Aktivakonten, etc. umfassen. Für jedes dieser Konzepte wird das ICAT alle Schüleraktionen durchsehen und bestimmen, wie viele der Schüleraktionen korrekt waren. Damit das ICAT versteht, welche Ziele auf der Schnittstelle mit jedem Konzept verbunden sind, werden die Ziele in Zielgruppen gebündelt und in einer Hierarchie in Prioritäten aufgelistet. Sobald alle möglichen Nachhilfethemen aktiviert sind, analysiert eine Rückmeldungsauswahl die aktiven Förderunterrichtsteile mit der Konzepthierarchie und wählt die am besten geeignete zur Ablieferung aus. Die ausgewählten Rückmeldungsteile werden dann in einen zusammenhängenden Rückmeldungsabsatz zusammengesetzt und an den Schüler geliefert. 23 veranschaulicht eine Rückmeldungsauswahl. Nachdem das ICAT Nachhilfethemen über Regelauslösungen aktiviert hat, wird der Rückmeldungsauswahlalgorithmus verwendet, um das am besten geeignete Set von Nachhilfeposten bzw. Nachhilfesachverhalten zu bestimmen (spezifische Teile von Rückmeldungstext, der mit einem Nachhilfethema in Zusammenhang steht), das auszuliefern ist. Der Algorithmus führt dies durch Analyse der Konzepthierarchie (Zielgruppenbaum), die aktiven Nachhilfethemen), und die Verwendungsgeschichte der Nachhilfepunkte aus. 24 ist ein Flussdiagramm der Rückmeldungslogik. Es gibt fünf Hauptbereiche zu der Rückmeldungslogik, welche sequentiell wie nachfolgend aufgelistet ausführen. Als erstes schaut der Algorithmus durch die Zielgruppen und schaut nach der obersten Zielgruppe, die in sich ein aktives Nachhilfethema hat. Als zweites schaut der Algorithmus dann nach, ob der oberste Nachhilfeposten Lobrückmeldung ist. Falls es Lobrückmeldung ist, dann hat der Schüler die Geschäftsablieferung korrekt vervollständigt, und das ICAT wird stoppen und den Nachhilfeposten zurückgeben. Als drittes wird das ICAT dann, falls die Rückmeldung kein Lob ist, nachschauen, ob es sich um Neulenkung, Überarbeitung, ein Genie, oder einen unvollständigen Stopp handelt. Falls sie eine beliebige von diesen ist, dann wird der Algorithmus stoppen und diese Rückmeldung an den Schüler zurückgeben. Als viertes schaut der Algorithmus dann, falls die Rückmeldung Fokussieren ist, zu den Nachfolgezielgruppen und Gruppen einer beliebigen aktiven Rückmeldung in diesen Zielgruppen mit dem Fokusgruppendateikopf. Als fünftes wird dann, sobald die Rückmeldung gesammelt wurde, die Substitutionssprache laufen gelassen, welche Substitutionsvariable mit den richtigen Namen ersetzt. Sobald das ICAT die zurückzugebenden Rückmeldungsteile ausgewählt hat, werden die Rückmeldungsteile in einem Absatz zusammengesetzt. Mit dem zusammengesetzten Absatz geht das ICAT durch und ersetzt alle Variablen. Es gibt spezifische Variable für QuellenPosten und Ziele. Variable geben Rückmeldung Besonderheit. Die Rückmeldung kann klarmachen, welche falschen QuellenPosten auf welche Ziele platziert wurden. Es stellt auch Hinweise bereit, indem ein oder zwei QuellenPosten bereitgestellt werden, die mit dem Ziel abgebildet sind.
Die bei Schaffen von Rückmeldung umfassten Schritte gemäß einem bevorzugten Ausführungsbeispiel
Das Ziel von Rückmeldung ist, einem Schüler zu helfen, eine Geschäftsablieferung zu vervollständigen. Der Tutor muss identifizieren, welche Konzepte der Schüler versteht und welche nicht. Der Tutor muss dem Schüler seine Probleme mitteilen und ihm helfen, die Konzepte zu verstehen. Es gibt sieben Hauptschritte, die beim Entwickeln von Rückmeldung für eine Anwendung umfasst sind. Erstens, Schaffen einer Strategie – Der Designer definiert, was der Schüler wissen sollte. Zweitens, Begrenzen von Fehlern durch eine Schnittstelle – Der Designer bestimmt, ob die Schnittstelle einige Fehler niedriger Stufe identifizieren wird. Drittens, Schaffen einer Zielgruppenhierarchie – Der Designer repräsentiert das Wissen in dem Tutor. Viertens, Sequenzbilden der Zielgruppenhierarchie – Der Designer teilt dem Tutor mit, welche Konzepte zuerst diagnostiziert werden sollten. Fünftens, Schreiben von Rückmeldung – Der Designer schreibt Rückmeldung, welche dem Schüler mitteilt, wie er gewesen ist, und was als Nächstes zu tun ist. Sechstens, Schreiben von Stufen von Rückmeldung – Der Designer schreibt verschiedene Stufen von Rückmeldung für den Fall, dass der Schüler denselben Fehler mehr als einmal macht. Siebentes, Schreiben von Regeln – Der Designer definiert Muster, welche die Rückmeldung schießen bzw. auslösen.
Eine Rückmeldungsstrategie ist ein loses Set von Fragen, welche den Designer führen, wenn er Regeln und Rückmeldung schafft bzw. erzeugt. Die Strategie beschreibt, was der Schüler lernen sollte, wie er die Geschäftsablieferung versuchen und schaffen wird, und wie ein Experte die Ablieferung vervollständigt. Für den Schüler sollte das Ziel der Anwendung sein, von dem Neulingsmodell zu dem Expertenmodell überzugehen. Was sollte der Schüler wissen, nachdem er die Anwendung verwendet? Die erste Aufgabe, die ein Designer vervollständigen muss, ist exakt zu definieren, welches Wissen ein Schüler bis zum Ende der Interaktion lernen muss. Sollte der Schüler spezifische Teile von Wissen, wie beispielsweise Formeln, wissen? Oder sollte der Schüler Strategien hoher Stufe und detaillierte Geschäftsprozesse verstehen? Dieses Wissen ist das Fundament der Rückmeldungsstrategie. Der Tutor muss identifizieren, ob der Schüler das Wissen korrekt verwendet hat, oder ob Fehler vorhanden waren. Ein Beispiel ist die Journaleintragaufgabe. Für diese Aktivität müssen Schüler den Zweck der Journaleintragaktivität, die spezifischen Konten für Lastschrift/Gutschrift, und wie viel abzubuchen/gutzuschreiben ist, wissen. Eine Lastschrift/Gutschrift eines Schülers ist nicht korrekt oder inkorrekt bei isolierter Betrachtung, jedoch korrekt und inkorrekt in Verbindung mit den abgebuchten/gutgeschriebenen Dollars. Da es zwei verschiedene Typen von Wissen gibt – Konten zum Abbuchen/Gutschreiben und Beträge zum abbuchen/gutschreiben –, muss die Rückmeldung für beide Typen von Fehlern geeignete Rückmeldung identifizieren und bereitstellen.
Wie wird ein Neuling die Aufgabe versuchen und vervollständigen? Designer sollten damit beginnen zu definieren, wie sie glauben, dass ein Neuling die Aufgabe versuchen und vervollständigen wird. Welche Bereiche für den Schüler schwierig sind und welche leicht sind. Dieser Neulingsblick ist das mentale Modell, das ein Schüler der Aufgabe entgegenbringen wird, und die Rückmeldung sollte dem Schüler helfen, sich zu einem Expertenblick zu bewegen. Designer sollten charakteristischen Fehlern besondere Aufmerksamkeit schenken, die sie denken, die der Schüler machen wird. Designer werden spezifische Rückmeldung für diese Fehler schaffen wollen. Ein Beispiel ist ein Verwechseln von Ausgabenkonten bei der Journaleintragaktivität. Da Schüler einige dieser Konten verwechseln könnten, muss der Designer spezielle Rückmeldung schreiben, um irgendwelche Verwirrung aufzuklären zu helfen.
Wie vervollständigt ein Experte die Aufgabe? Dies ist das Expertenmodell eines Vervollständigens der Aufgabe. Die Rückmeldung sollte Schülern helfen, dass der Schüler zu diesem Verständnis der Domain übergeht. Wenn er Rückmeldung schafft, sollte ein Designer Schlüsselmerkmale des Expertenmodells in die Lobrückmeldung einbauen, die er schreibt. Wenn ein Schüler einen Teil der Aufgabe vervollständigt, sollte positive Unterstützung bereitgestellt werden, welche dem Schüler bestätigt, dass er die Aufgabe richtig macht und denselben Prozess verwenden kann, um die anderen Aufgaben zu vervollständigen. Diese vier Fragen sind kein Überblick zum Schaffen von Rückmeldung, sondern sie definieren, was die Rückmeldung und die gesamte Anwendung ausführen muss. Der Designer sollte sicherstellen, dass die Rückmeldung alles Wissen bewertet, das ein Schüler lernen soll. Darüber hinaus sollte die Rückmeldung in der Lage sein, beliebigen charakteristischen Fehlern mit Förderunterricht zu begegnen, die der Designer spürt, dass sie der Schüler machen wird. Schließlich sollte der Designer Rückmeldung derart gruppieren, dass sie Rückmeldung zurückgibt, als wenn er ein Experte wäre. Wenn diese Komponenten identifiziert sind, ist ein Designer bereit, mit der Schaffung von Zielgruppenhierarchien zu beginnen. Da es positive und negative erneute Auswirkungen gibt, muss der Designer das wann zum Förderunterricht Geben über die Schnittstelle sorgfältig auswählen. Die Kriterien zum Treffen einer Entscheidung sind, ob der Fehler ein Dateneintragfehler niedriger Stufe oder ein intellektueller Fehler hoher Stufe ist. Falls der Fehler ein Fehler niedriger Stufe ist, wie beispielsweise ein Rechtschreibfehler, könnte es passend sein, dass einen Förderunterricht über die Schnittstelle zu geben. Falls der Designer entscheidet, dass die Schnittstelle die Fehler darlegt, sollte es so aussehen, als wenn das System die Meldung erzeugt. Systemerzeugte Meldungen sind mechanische Prüfungen, die keine komplexe Begründung benötigen. Im Gegensatz dazu sollte komplexe Begründung, wie beispielsweise, warum ein Schüler einen bestimmten Kontotyp zum Gutschreiben oder Abbuchen wählt, durch das ICAT mit Förderunterricht versehen werden.
Systemmitteilungen – Es ist sehr wichtig, dass der Schüler weiß, welche Art von Förderunterricht er von jeder Quelle von Information bekommen wird. Schnittstellenbasierter Förderunterricht sollte wie Systemmitteilungen aussehen und sich anfühlen. Sie sollten eine andere Schnittstelle als der ICAT-Förderunterricht verwenden und sollten ein anderes Gefühl vermitteln. In der in dieser gesamten Veröffentlichung beschriebenen Journaleintragaufgabe gibt es eine Systemmitteilung, welche darlegt "Gutschriften sind nicht gleich Lastschriften". Diese Mitteilung wird durch eine andere Schnittstelle abgeliefert, und der unverblümte kurze Satz ist anders als jeder andere Förderunterricht. Die Motivation für das ist, dass Dateneintragfehler niedriger Stufe kein falsches Verständnis zeigen sondern stattdessen nachlässige Arbeit. Fehler aufgrund von nachlässiger Arbeit erfordern keinen großen Aufwand an Begründung darüber, warum sie aufgetreten sind, stattdessen müssen sie einfach identifiziert werden. Begründungsfehler hoher Stufe erfordern jedoch einen großen Aufwand an Begründung darüber, warum sie aufgetreten sind, und das ICAT stellt Werkzeuge, wie beispielsweise Zielgruppen, bereit, um mit einer komplexen Begründung zu helfen. Zielgruppenhierarchien ermöglichen es Designern, Fehler und Konzepte miteinander zu gruppieren und sicherzustellen, dass sie zu der am besten geeigneten Zeit als Förderunterricht gegeben werden (das heißt, harte Konzepte werden vor leichten Konzepten als Förderunterricht gegeben). Zeitsteuerung und andere Typen von menschenähnlichem Förderunterricht machen das ICAT erforderlich; andere Fehler niedriger Stufe, die nicht viel Begründung erfordern, umfassen: Unvollständig – Falls die Aufgabe eine Anzahl von Eingaben erfordert, kann die Schnittstelle prüfen, dass sie alle eingegeben worden sind, bevor dem Schüler erlaubt wird, weiterzugehen. Indem leere Felder früh in dem Prozess bzw. Vorgang herausgefunden werden, kann dem Schüler die Frustration erspart werden, durch jeden Eintrag zu schauen, um den leeren Eintrag zu suchen und zu finden. Leer – Eine einfache Prüfung für das System ist es, nachzuschauen und zu ermitteln, ob alles ausgewählt oder eingegeben ist. Falls nichts ausgewählt wurde, kann es für das System geeignet sein, eine Mitteilung zu erzeugen, die angibt "Vor einer Fortsetzung müssen Sie X vervollständigen". Nicht passende Zahlen – Eine andere schnelle Prüfung ist das Passen bzw. Übereinstimmen von Zahlen. Wie bei der Journaleintragaktivität ist es oft nützlich, eine schnelle Schnittstellenprüfung vorzunehmen, um sicherzustellen, dass Zahlen, die passen müssen, es auch tun. Kleine Dateneintragfehler werden oft besser auf der Schnittstellenstufe als auf der Tutor- oder Nachhilfestufe als Förderunterricht gegeben (wenn sie für die Lernziele des Kurses nicht kritisch sind). Es gibt zwei Hauptsachverhalte, welche in Erinnerung gehalten werden müssen, wenn die Schnittstelle zum Förderunterricht bei Fehlern Verwendung findet. Erstens, sicherstellen, dass die Schnittstelle Förderunterricht bei Dateneintragfehlern niedriger Stufe gibt. Zweitens, sicherstellen, dass die Rückmeldung von der ICAT-Rückmeldung verschieden aussieht und sich verschieden anfühlt. Die Schnittstellenrückmeldung sollte aussehen und sich anfühlen, wie wenn sie von dem System erzeugt wird, während die ICAT-Rückmeldung aussehen muss, als wenn sie von einem intelligenten Nachhilfevermittler erzeugt wurde, der den Schüler bei der Arbeit überwacht.
Schaffen der Zielgruppenhierarchie – Zielgruppen sind Sets von Zielen, welche als eins bewertet werden. Zurückkehrend zu dem Schwereproblem der Rückmeldungstheorie ist es klar, dass der Tutor identifizieren muss, wie viel der Aktivität der Schüler nicht versteht. Ist es ein globales Problem, und versteht der Schüler gar nichts von der Aktivität? Oder ist es ein lokales Problem und ist der Schüler nur in Bezug auf ein Konzept verwirrt? Unter Verwendung des zuvor beschriebenen Rückmeldungsalgorithmus wird der Tutor die höchste Zielgruppe zurückgeben, in der Rückmeldung vorhanden ist. Dieser Algorithmus erfordert, dass der Designer mit großen Zielgruppen startet und Untergruppen bildet, welche Kinder bzw. Nachkommen bzw. Nachfolger der größeren Gruppen sind. Das ICAT ermöglicht es Schülern, Ziele in mehr als einer Kategorie zu gruppieren. Daher kann ein Lastschriftziel für Transaktion dreizehn in einer Zielgruppe zur Transaktion von dreizehn Einträgen sein, sowie in einer Zielgruppe über Lastschriften und in einer Zielgruppe sein, die alle Quelldokumente umfasst. Ziele sollten mit vier Schlüsselideen im Hinterkopf gruppiert werden. Zielgruppen werden gruppiert gemäß: gelehrten Konzepten; Schnittstellengrenzen; Vermeidung von Informationsüberladung und positive Unterstützung.
Der wichtigste Sachverhalt beim Schaffen von Zielgruppen ist es, sie entlang den Konzepten zu schaffen, die Schüler wissen müssen, um das Ziel zu erreichen. Eine Gruppierung von Zielen in Gruppen, welche zu den Konzepten analog sind, die ein Schüler wissen muss, ermöglicht es dem Tutor, die Konzepte erneut anzuschauen und zu sehen, welche Konzepte den Schüler verwirren. Als ein erster Schritt sollte ein Designer auf eine unstrukturierte Weise alle Konzepte in der Domain identifizieren. Dieser erste Schritt wird eine lange Liste sein, welche Konzepte mit einer Vielfalt von Körnungen umfasst, von kleinen spezifischen Konzepten bis zu breiten allgemeinen Konzepten. Diese Konzepte sind am wahrscheinlichsten mit den Lernzielen des Kurses direkt verwandt. Wenn alle Konzepte definiert sind, müssen Designer alle Ziele identifizieren, die in jeder Zielgruppe sind. Einige Ziele werden in mehr als einer Zielgruppe sein. Wenn ein Ziel in mehr als einer Zielgruppe ist, bedeutet dies, dass es eine gewisse Art von Verwandtschaft, wie beispielsweise eine Nachkommenverwandtschaft oder eine Teil-zu-Ganzes-Verwandtschaft gibt. Der Punkt ist es, keine strukturierte Liste von Konzepten, sondern eine verstehbare Liste zu schaffen. Sie in eine Hierarchie zu strukturieren wird der zweite Schritt des Prozesses sein.
Simulationsmaschine
Die Idee für den Designer ist es, die Aufgabe zu modellieren, die er möchte, dass sie ein Schüler unter Verwendung einer Exceltabellenkalkulation ausführt. Dann möchte er einen Algorithmus oder eine Maschine haben, die alle signifikanten Zellen der Tabellenkalkulation liest und dem intelligenten Nachhilfevermittler die geeigneten Informationen (SourceItemID, TargetID und Attribute) mitteilt. Auf diese Weise agiert die Tabellenkalkulation als eine zentrale Ablage für Schülerdaten, enthält die meisten der Berechnungen, die für die Aufgabe erforderlich sind, und handhabt in Verbindung mit der Maschine alle Kommunikation mit dem ICA. Die Aufgabe ist in der Tabellenkalkulation selbst enthalten, so dass die Designer nicht länger eine graphische Benutzerschnittstelle zum funktionellen Test ihrer Designs benötigen (Smart Tabellenkalkulation). Sobald das Modell und Rückmeldung für es vollständig durch Designer getestet sind, können Entwickler die Tabellenkalkulation in einer graphischen Benutzerschnittstelle, beispielsweise Visual Basic, als eine Entwicklungsplattform einbauen. Die Simulationstabellenkalkulation ist üblicherweise unsichtbar und bevölkert unter Verwendung von in der Maschine bereitgestellten Funktionen. Es ist sehr wichtig, dass alle Modifikationen, die das ICA wissen muss, durch die Maschine gehen, da nur die Maschine weiß, wie der ICA aufzurufen ist. Dies reduziert signifikant das von Programmierern geforderte Fertigkeitsniveau, und reduziert in großem Maße die zur Programmierung jeder Aufgabe erforderliche Zeit. Zusätzlich war das Endprodukt weniger fehleranfällig, da das Tutormanagement zentralisiert war. Falls es ein Tutorproblem gibt, hatten wir nur einen Codeabschnitt zu prüfen. Schließlich war die Chance von Dateninkonsistenz zwischen dem Tutor und der Anwendung Null, da die Simulationsmaschine die Daten von einer Tabellenkalkulation geladen hatte.
25 ist ein Blockschaltbild, das die Architektur eines Simulationsmodells dargelegt hat. Das Simulationsobjektmodell besteht aus einem Tabellenkalkulationmodell, einem Tabellenkalkulationsteuerobjekt, einem Simulationsmaschinenobjekt, einer Simulationsdatenbank, Eingabeobjekten, Ausgabeobjekten, Listenobjekten und Pfadobjekten. Das erste Objekt in unserer Diskussion ist das Tabellenkalkulationsobjekt. Die Tabellenkalkulation ist die Unterstützung für alle Simulationsmodelle. Ein Steuerobjekt wird leicht mit dem Entwicklungsbauplan von Visual Basic integriert. Die Steuerung unterstützt Drucken und ist mit Tabellenkalkulationen von Microsoft Excel kompatibel. Mit diesem im Hinterkopf können Designer die Kraft von Excelformularen verwenden, um die Simulation aufzubauen. Die in dem Tabellenkalkulationsmodell enthaltenen verschiedenen Zellen können als Eingaben, Ausgaben oder Listen konfiguriert werden und gehören zu einem Simulationspfad.

Alle Zellen in der Tabellenkalkulation, die durch den Designer oder den Schüler über die GBS-Anwendung manuell eingegeben werden müssen, werden durch Eingabeobjekte repräsentiert. Jede Eingabe hat die folgende Schnittstelle:

Feldname	Datentyp	Beschreibung
InputID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AufgabeID der mit der Eingabe in Zusammenhang stehenden, Aufgabe
PathID	long	PathID bzw. PfadID des mit der Eingabe in Zusammenhang stehenden Pfads
InputName	string*50	Name der Eingabe
InputDesc	string*255	Beschreibung der Eingabe
ReferenceName	string*50	Name der mit der Eingabe verbundenen Tabellenkalkulationszelle
TutorAware	Bool'scher Typ	Ob der ICA beliebige Änderungen der Eingabe mitgeteilt werden sollten
SourceItemID	long	SourceItemID bzw. QuellenPostenID, falls Eingabe eine deutliche bzw. ausgeprägte Eingabe ist; 0, falls Eingabe eine Ziehen&Ablegen-Eingabe ist
TargetID	long	TargetID bzw. ZielID der Eingabe
Reihe	long	Tabellenkalkulationsreihennummer der Eingabe → Geschwindigkeitsoptimierung
Spalte	long	Tabellenkalkulationsspaltennummer der Eingabe → Geschwindigkeitsoptimierung
SheetName	string*50	Name des Blatts, wo sich die Eingabe befindet → Geschwindigkeitsoptimierung

Diese Informationen werden für jede Eingabe in der Eingabetabelle der Simulationsdatenbank (ICASim.mdb) gespeichert. Vergleiche das Nachfolgende Beispiel. Wenn Designer ihr Simulationsmodell konstruieren, müssen sie sich der Tatsache bewusst sein, dass es 2 Typen von Eingaben gibt: Distinct bzw. deutliche Eingabe&Ziehen&Ablegen-Eingabe. Die deutliche Eingabe besteht aus einer einzelnen Tabellenkalkulationszelle, die durch den Designer zur Zeit des Designs oder durch die GBS-Anwendung zur Laufzeit über die Simulationsmaschinenobjektverfahren ausgefüllt werden kann. Der Zweck der Zelle ist, einen Eintragpunkt für das Simulationsmodell bereitzustellen. Dieser Eintragpunkt kann beispielsweise eine Antwort auf eine Frage oder ein Parameter für eine Gleichung sein. Falls die Zelle TutorAware ist (alle Eingaben sind üblicherweise TutorAware), werden dem ICA alle Änderungen für die Zelle mitgeteilt. Wenn dem ICA eine Änderung mitgeteilt wird, werden in der Tat zwei Mitteilungen an die ICA gesendet: Eine Mitteilung ICANotifyDestroy mit den Eingabeinformationen, das heißt SourceItemID, TargetID und Null als Attribut. Diese Mitteilung dient zum Anweisen der ICA, diese Informationen aus ihrem Speicher zu beseitigen. Eine Mitteilung ICANotifyCreate mit den Eingabeinformationen, das heißt SourceItemID, TargetID, Attribut (numerischer Zellenwert). Diese Mitteilung dient zum Anweisen der ICA, diese Informationen in ihrem Speicher hinzuzufügen. Eine deutliche Eingabe erfordert nie, dass ein Benutzer eine mathematische Frage beantwortet.

Dies sind die Schritte, die erforderlich sind, um diese Simulation zu konfigurieren. Definiere einen Namen für Zelle C2 in Excel. Hier haben wir "Distinct Input" definiert. In der ICA, Definiere eine Aufgabe, die der Simulation zugewiesen wird. Ex: Durch die ICA wird eine AusfgabenID von 123 erzeugt. In der ICA, definiere ein Ziel (Target) für die Eingabe. Ex: Durch die ICA wird eine TargetID von 4001 erzeugt. In der ICA, definiere ein SourceItem für die Eingabe. Ex: Durch die ICA wird eine SourceItemID von 1201 erzeugt. Bilde einen Zusammenhang der Eingabe mit einem Pfad (auf Pfadobjektdiskussion Bezug nehmen). Füge die Informationen in die Eingabetabelle der Simulationsmaschinendatenbank hinzu. Eine Aufzeichnung in einer Eingabetabelle ist nachfolgend präsentiert.

InputID:	12345
TaskID.	123
PathID:	1234
InputName:	Frage 1 Eingabe
InputDesc:	Deutliche Eingabe für Frage 1
ReferenceName:	Deutliche Eingabe
TutorAware:	wahr
SourceItemID:	1201
TargetID:	4001
Reihe:	2
Spalte:	3
SheetName:	Blatt1

Die Reihe, Spalte und SheetName werden ausgefüllt, sobald der Benutzer "Eingabe/Ausgabe laufen lassen" klickt. Die Simulationsmaschine decodiert den definierten Namen (ReferenceName bzw. BezugName), den der Designer eingegeben hat, und füllt die Tabelle entsprechend aus.
Dies ist ein wichtiger Schritt. Wir hatten mehrere Gelegenheiten, wenn ein Designer das Layout einer Tabellenkalkulation ändern würde, das heißt einen definierten Namensort bewegt, und dann vergisst, diesen Schritt durchzuführen. Als solche wurden bizarre Daten an den Tutor weitergeleitet; was auch immer für Daten in der alten Reihe und Spalte gelegen waren. Sobald die Konfiguration vollendet ist, kann der Designer nun die ICA-Betriebsmittel verwenden, um die Simulation zu testen.
Die Ziehen-und-Ablegen-Eingabe besteht aus zwei aufeinander folgenden Tabellenkalkulationszellen. Beide von ihnen müssen durch den Designer zu der Zeit des Designs oder durch die GBS-Anwendung bei Laufzeit über die Simulationsmaschinenobjektverfahren gefüllt werden. Diese Art von Eingabe wird üblicherweise verwendet, wenn der Benutzer eine Antwort unter einer Auswahl von möglichen Antworten auswählen muss. Ziehen-und-Ablegen-Eingaben sind immer TutorAware. Die am weitesten links liegende Zelle enthält die SourceItemID der durch den Benutzer herausgenommenen Antwort (jede mögliche Antwort braucht eine SourceItemID) und die am weitesten rechts liegende Zelle kann einen numerischen Wert enthalten, der mit dieser Antwort in Zusammenhang steht. Man muss einen Namen oder einen ReferenceName in der Tabellenkalkulation für die am weitesten rechts liegende Zelle definieren. Dem ICA werden alle Änderungen an einer jeden der Zellen mitgeteilt. Wenn dem ICA eine Änderung mitgeteilt wird, werden in der Tat zwei Mitteilungen an die ICA gesendet: Eine Mitteilung ICANotifyDestroy mit den Eingabeinformationen, das heißt SourceItemID, bevor die Änderung eingetreten ist, TargetID der Eingabe und der Attributwert, bevor die Änderung eingetreten ist. Eine Mitteilung ICANotifyCreate mit den Eingabeinformationen, das heißt SourceItemID, nachdem die Änderung eingetreten ist, TargetID der Eingabe und der Attributwert, nachdem die Änderung eingetreten ist.

Dies sind die Schritte, die zur Konfiguration dieses Abschnitts der Simulation erforderlich sind: Definiere einen Namen für Zelle C11 in Excel. Hier haben wir "DragDrop_Input" definiert; Lass uns die selbe TaskID wie zuvor verwenden, da Frage 2 Teil derselben Simulation wie Frage 1 ist. Ex: TaskID ist 123; In der ICA, Definiere ein Ziel für die Eingabe. Ex: Durch die ICA wird eine TargetID von 4002 erzeugt; In der ICA, definiere ein SourceItem für jede mögliche Antwort auf die Frage. Ex: Durch die ICA werden SourceItemIDs 1202 bis 1205 erzeugt; Stelle einen Zusammenhang zwischen Eingabe und Pfad her (nimm auf Pfadobjektdiskussion Bezug); und Füge die Informationen in die Eingabetabelle der Simulationsmaschinendatenbank ein. Nachfolgend ist eine Aufzeichnung in der Eingabetabelle gemäß einem bevorzugten Ausführungsbeispiel präsentiert.

InputID:	12346
TaskID.	123
PathID:	1234
InputName:	Frage 2 Eingabe
InputDesc:	Ziehen&Ablegen-Eingabe für Frage 2
ReferenceName:	ZiehenAblegen Eingabe
TutorAware:	wahr
SourceItemID:	0 ***
TargetID:	4002
Reihe:	11
Spalte:	3
SheetName:	Blatt1

Das Listeobjekt besteht aus einer Zelle, welche die Liste Identifiziert (Zelle #1), und einer Serie von Platzhalterreihen, die Ziehen&Ablegen-Eingaben ähneln (Zelle #1.1–1.n bis Zellen #n.1–n.n) Die Liste wird üblicherweise verwendet, wenn der Benutzer mehrere Elemente unter einer Auswahl von möglichen Antworten auswählen muss. Zelle #1 muss einen einzigartig definierten Namen haben, der auch der Listename genannt wird. Zelle #1.1 bis #n.1 können die SourceItemID einer möglichen Antwort haben, die durch den Benutzer herausgegriffen ist (jede mögliche Antwort benötigt eine SourceItemID). Der Inhalt dieser Zellen muss diesem Format folgen: ~ListName-SourceItemID. Zellen #1.2 bis #n.2 werden den numerischen Wert (Attribut) halten, der mit der SourceItemID in der Zelle unmittelbar links daneben in Zusammenhang steht. Zellen #1.3–1.n bis #n.3–n.n sind optionale Platzhalter für mit der Antwort in Zusammenhang stehenden Daten. SCHÜSSELANMERKUNG: Wenn ein Listeobjekt ausgeführt wird, muss der Designer alle Zellen unter #n.1 bis #n.n leer lassen, da sich dieser Bereich jedes Mal nach oben verschiebt, wenn ein Posten bzw. Sachverhalt von der Liste gelöscht wird.

Jede Liste hat die folgende Schnittstelle:

Feldname	Datentyp	Beschreibung
ListID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AufgabeID der mit der Liste in Zusammenhang stehenden Aufgabe
PathID	long	PathID bzw. PfadID des mit der Liste in Zusammenhang stehenden Pfads
ListName	string*50	Name der Liste
ListDesc	string*255	Beschreibung der Liste
ReferenceName	string*50	Name der mit der Liste verbundenen Tabellenkalkulationszelle
TutorAware	Bool'scher Typ	Ob der ICA beliebige Änderungen an der Liste mitgeteilt werden sollten
TargetID	long	TargetID bzw. ZielID der Ausgabe
TotalColums	long	Gesamtzahl von Datenspalten
Reihe	long	Tabellenkalkulationsreihennummer der Ausgabe → Geschwindigkeitsoptimierung
Spalte	long	Tabellenkalkulationsspaltennummer der Ausgabe → Geschwindigkeitsoptimierung
SheetName	string*50	Name des Blattes, wo sich die Eingabe befindet → Geschwindigkeitsoptimierung

Die Verwendung einer Liste wird durch Fortsetzung unseres Mathematiktests demonstriert. Die Mathematikfrage bei diesem Beispiel lädt den Benutzer ein, mehrere Elemente auszuwählen, um die Antwort zu konstruieren. Dies sind die Schritte, die erforderlich sind, um diesen Abschnitt der Simulation konfigurieren. 26 veranschaulicht die Schritte zur Konfiguration einer Simulation gemäß einem bevorzugten Ausführungsbeispiel. Definiere einen Namen für Zelle C23 in Excel. Hier haben wir "Die-Liste" definiert. Lass uns dieselbe TaskID wie zuvor verwenden, da Frage 3 ein Teil derselben Simulation wie Frage 1 und 2 ist. Ex: TaskID ist 123. In der ICA, definiere ein Ziel für die Liste. Ex: Durch die ICA wird eine TargetID von 4006 erzeugt. In der ICA, definiere ein SourceItem für jeden Posten bzw. Sachverhalt, der in die Liste platziert werden könnte. Ex: durch die ICA werden die folgenden SourceItemIDs 1209, 1210, 1211, 1212, 1213, 1214 erzeugt.
Setze die Liste mit einem Pfad in Zusammenhang (vgl. Pfadobjektdiskussion). Füge die Informationen zu der Listentabelle der Simulationsmaschinendatenbank hinzu.

Eine Aufzeichnung in der Listentabelle ist in der nachfolgend erscheinenden Tabelle präsentiert.

ListID:	12346
TaskID.	123
PathID:	1234
ListName:	Frage 3 Liste
ListDesc:	Liste für Frage 3
ReferenceName:	Die Liste
TutorAware:	wahr
TargetID:	4006
TotalColumns:	1
Reihe:	23
Spalte:	3
SheetName:	Blatt1

Alle Zellen in der Tabellenkalkulation, die das Ergebnis von Berechnungen sind (sie erfordern keine externe Eingabe), können durch Ausgabeobjekte repräsentiert werden. Jede Ausgabe hat eine Schnittstelle, wie in der nachfolgenden Tabelle umrissen.

Feldname	Datentyp	Beschreibung
OutputID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AusgabeID der mit der Ausgabe in Zusammenhang stehenden Aufgabe
PathID	long	PathID bzw. PfadID des mit der Ausgabe in Zusammenhang stehenden Pfads
OutputName	string*50	Name der Ausgabe
OutputDesc	string*255	Beschreibung der Ausgabe
ReferenceName	string*50	Name der mit der Ausgabe verbundenen Tabellenkalkulationszelle
TutorAware	Bool'scher Typ	Ob der ICA beliebige Änderungen an der Ausgabe mitgeteilt werden sollten
SourceItemID	long	SourceItemID bzw. QuellenPostenID der Ausgabe
TargetID	long	TargetID bzw. ZielID der Ausgabe
Reihe	long	Tabellenkalkulationsreihennummer der Ausgabe → Geschwindigkeitsoptimierung
Spalte	long	Tabellenkalkulationsspaltennummer der Ausgabe → Geschwindigkeitsoptimierung
SheetName	string*50	Name des Blatts, wo sich die Eingabe befindet → Geschwindigkeitsoptimierung

Alle diese Informationen werden für jede Ausgabe in der Ausgabetabelle der Simulationsdatenbank (ICASim.mdb) gespeichert. Wenn Designer ihr Simulationsmodell konstruieren, müssen sie sich der Tatsache bewusst sein, dass es nur eine Art von Ausgaben gibt: die deutliche Ausgabe. Eine deutliche Ausgabe besteht aus einer und nur einer Tabellenkalkulationszelle, welche eine Formel oder ein Ergebnis von Berechnungen enthält. Das Vorhandensein von Ausgabezellen ist der Hauptgrund, dass man ein Simulationsmodell hat. Falls die Zelle TutorAware ist, wird die ICA über beliebige Änderungen an der Zelle informiert, wenn alle Ausgaben verarbeitet sind, ansonsten werden der ICA beliebige Änderungen nicht bewusst sein. Wenn die ICA über eine Änderung informiert wird, werden in der Tat zwei Mitteilungen an die ICA gesendet. Eine Mitteilung ICANotifyDestroy mit den Ausgabeinformationen, das heißt SourceItemID, TargetID und Null als Attribut. Diese Mitteilung dient dazu, die ICA anzuweisen, diese Informationen aus ihrem Speicher zu löschen. Eine Mitteilung ICANotifyCreate mit den Ausgabeinformationen, das heißt SourceItemID, TargetID, Attribut (numerischer Zellenwert). Diese Mitteilung dient dazu, die ICA anzuweisen, diese Informationen zu ihrem Speicher hinzuzufügen. Im Gegensatz zu deutlichen Eingaben und Ziehen&Ablegen-Eingaben, welche die ICA über jede Änderung informieren, werden deutliche Ausgaben im Stapel verarbeitet, bevor die ICA nach einer Rückmeldung gefragt wird. Um die ICA über den Gesamtdollarbetrag der Posten in der Liste zu informieren. Hierfür brauchen wird definitiv eine deutliche Ausgabe. Die Ausgabe wird eine Summenformel enthalten. Definiere einen Namen für Zelle C24 in Excel. Hier haben wir "Deutliche_Ausgabe" definiert. Lass uns dieselbe TaskID wie zuvor verwenden, da Frage 3 ein Teil derselben Simulation wie Frage 1 und 2 ist. Ex: TaskID ist 123. In der ICA, definiere ein Ziel für die Ausgabe. Ex: durch die ICA wird eine TargetID von 4005 erzeugt. In der ICA, definiere ein SourceItem bzw. einen QuellenPosten für die Ausgabe. Ex: durch die ICA wird eine SourceItemID 1215 erzeugt. Setze die Ausgabe mit einem Pfad in Zusammenhang (vgl. Pfadobjektdiskussion).
Füge die Informationen zu der Ausgabentabelle der Simulationsmaschinendatenbank hinzu.

Eine Aufzeichnung in einer Ausgabentabelle ist nachfolgend präsentiert.

OutputID:	12347
TaskID.	123
PathID:	1234
OutputName:	Frage 3 Ausgabe
OutputDesc:	Deutliche Ausgabe für Frage 3
ReferenceName:	Deutliche_Ausgabe
TutorAware:	Wahr
SourceItemID:	1215
TargetID:	4005
Reihe:	24
Spalte:	6
SheetName:	Blatt1

Pfade werden verwendet, um ein Simulationsmodell in Untersimulationen zu unterteilen, was bedeutet, dass man bestimmte Eingaben, Ausgaben und Listen zusammen gruppieren kann, um ein kohärentes Unterset oder einen kohärenten Pfad zu bilden. Jeder Pfad hat die folgende Schnittstelle:

Feldname	Datentyp	Beschreibung
PathID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AufgabenID der mit dem Pfad in Zusammenhang stehenden Aufgabe
PathNo	long	Mit einem Pfad in Zusammenhang stehender numerischer Wert
PathName	String*50	Name des Pfads
PathDesc	String*255	Beschreibung des Pfads

Alle diese Informationen werden für jeden Pfad in der Pfadtabelle der Simulationsdatenbank (ICASim.mdb) gespeichert.

Die Simulationsmaschine ist die Schnittstelle zwischen dem Modell, der Simulationsdatenbank und dem intelligenten Nachhilfevermittler. Die Simulationsmaschine ist für den Designer von Interesse, so dass er die Mechaniken von allem verstehen kann. Es ist jedoch der Entwickler von Anwendungen, der die Maschine verwendet, welcher die Einzelheiten der Schnittstelle (Verfahren&Eigenschaften) wissen sollte, die durch die Maschine und die damit in Zusammenhang stehenden Algorithmen an den Tag gelegt werden. Sobald der Designer das Simulationsmodell (Exceltabellenkalkulation) konstruiert hat und alle Eingaben, Ausgaben&Listen konfiguriert hat, ist er bereit, unter Verwendung der in den ICA-Betriebsmitteln umfassten Testbank zu testen (vgl. die Dokumentation von ICA-Betriebsmitteln). Der Entwickler muss wiederum die Aufrufe an die Simulationsmaschine in der GBS-Anwendung ausführen, die er aufbaut. Die folgende Liste identifiziert die Dateien, die in das Visual Basic Projekt umfasst werden müssen, um die Simulationsarbeitsbank zu verwenden:

wSimEng.cls	Simulationsmaschinenklasse
wSimEng.bas	Simulationsmaschinenmodul (dieses Modul wurde nur zu Geschwindigkeitszwecken eingeführt, da aller Code theoretisch in der Klasse eingekapselt sein sollte)
wConst.bas	Intelligenter-Nachhilfevermittler-Konstantendeklaration
wDeclare.bas	Intelligenter-Nachhilfevermittler-DLL-Schnittstelle
wIca.cls	Intelligenter-Nachhilfevermittler-Klasse
wIca.bas	Intelligenter-Nachhilfevermittler-Modul (dieses Modul wurde nur zu Geschwindigkeitszwecken eingeführt, da aller Code theoretisch in der Klasse eingekapselt sein sollte)

Um eine Arbeitssimulation zu haben, platziert ein Entwickler Code in verschiedenen strategischen Bereichen oder Stufen der Anwendung. Es gibt die Anfangsstufe, welche auftritt, wenn die Form, welche die Simulationsfront enthält, lädt. Dies ist, wenn das Simulationsmodell initialisiert wird. Es gibt die Modifikationsstufen, welche stattfinden, wenn der Benutzer Änderungen an der Front bzw. Vorderansicht macht, die einen Einfluss auf das Simulationsmodell haben. Dies ist, wenn der ICA darüber informiert wird, was geschieht. Es gibt die Rückmeldungsstufe, wenn der Benutzer Informationen über die bis dahin getane Arbeit anfordert. Dies ist der Fall, wenn die Simulation den ICA über alle Ausgabenänderungen informiert. Schließlich gibt es die letzte Stufe, wenn die Simulationsfront heruntergefahren wird. Dies ist, wenn die Simulation auf der Disk gespeichert wird.
Die verschiedenen Stufen von Schaffen einer Simulation, die den involvierten Visual Basic Code umfassen, sind nachfolgend präsentiert. Anfangsstufe; 1. Schaffen des ICA&des Simulationsmaschinenobjekts: Code: Set moSimEngine = New classSimEngine; Set moICA = New classICA; Beschreibung: Der erste Schritt beim Verwenden der Simulationsmaschine ist, ein Beispiel der Klasse classSimMaschine und auch ein Beispiel der Klasse classICA zu schaffen. Es sei erwähnt, dass die Maschine und der ICA die Variablen Modulniveauobjekt "mo" sein sollten. 2. Laden der Simulation; Code: IRet = moSimEngine.OpenSimulation(App.Path&DIR DATA&FILE_SIMULATION, Me.bookSimulation); IRet = moSimEngine.LoadSimulation(mlICATaskID, App.Path&DIR_DATABASE&DB_SIMULATION, 1); Beschreibung: Nach der Objektschaffung müssen die Verfahren OpenSimulation und LoadSimulation des Simulationsmaschinenobjekts aufgerufen werden. Das Verfahren OpenSimulation liest die spezifizierte Excel 5.0 Tabellenkalkulationsdatei in eine Tabellenkalkulationssteuerung. Das Verfahren LoadSimulation öffnet die Simulationsdatenbank und lädt eine Liste von Pfaden, eine Liste von Eingaben, eine Liste von Ausgaben und eine Liste von Listen für die spezifische Aufgabe in einen Speicher. Jedes Verfahren der Simulationsmaschine wird 0 zurückgeben, falls es erfolgreich endet, andernfalls wird eine geeignete Fehlerzahl zurückgegeben. 3. Initialisieren und Laden des Intelligenten Nachhilfevermittlers; Code: IRet = moICA. Initialize (App.Path&"\"&App.EXEName&".ini", App.Path&DIR_DATABASE, App.Path&DIR_ICADOC, App.Path&"\"); IRet = moICA.LoadTask (mlICATaskID, ICAStudentStartNew); Beschreibung: Die Systemmaschine arbeitet nur in Verbindung mit dem ICA. Das Initialisierungsverfahren des ICA-Objekts liest die Anwendungsdatei .ini und setzt die Tutor32.dll geeignet. Das Verfahren LoadTask teilt der ICA mit (Tutor32.dll), das Dokument .tut zu laden, das mit einer spezifischen Aufgabe in dem Speicher in Zusammenhang steht. Von dem Punkt an kann die ICA Mitteilungen bzw. Informationen empfangen. Es sei erwähnt: Das Dokument .tut enthält alle Element- und Rückmeldungsstruktur einer Aufgabe. Ex: SourcePages bzw. QuellSeiten, SourceItem bzw. QuellenPosten, TargetPages bzw. ZielSeiten, Targets bzw. Ziele, etc... 4. Wiederherstellen der Simulation; Code: <<Code zum Rücksetzen der Simulation, wenn durchgestartet wird>>; <<Code zum Laden der Steuerungen der Simulationsvorderansicht>>; IRet = moSimEngine.RunInputs(sPaths, True); IRet = moSimEngine.RunOutputs(sPaths, True); IRet = moSimEngine.RunLists(sPaths, True); Call moICA.Submit(0); Call moICA.SetDirtyFlag(0, False); Beschreibung: Wiederherstellen der Simulation umfasst viele Dinge: Löschen aller Eingaben und Listen, wenn der Benutzer durchstartet; Laden der Schnittstelle mit Daten von dem Simulationsmodell; Aufrufen der Verfahren RunInputs, RunOutputs und RunLists des Simulationsmaschinenobjekts, um die ICA zu ihrem Originalzustand zu bringen; Aufrufen des Verfahrens Submit des ICA-Objekts mit Null als Argument, um alle Regeln zu triggern; Aufrufen der SetDirtyFlag des ICA-Objekts mit 0 und falsch als Argumente, um die Benutzersitzung zurückzusetzen. Ein Laufen Lassen von Eingaben (RunInputs) involviert ein Gehen durch die Liste von TutorAware-Eingaben und Informieren der ICA über den Wert von SourceItemID, TargetID und Attribut jeder Eingabe. Ein Laufen Lassen von Lists (RunLists) umfasst ein Gehen durch die Liste von TutorAware-Lists und Informieren des ICA über den Wert von SourceItemID, TargetID und Attribut jedes Postens in jeder Liste. Die TargetID ist einzigartig für jeden Posten in einer Liste.
Ein Laufen Lassen von Outputs (RunOutputs) umfasst ein Gehen durch die Liste von TutorAware-Ausgaben und Informieren des ICA über den Wert von SourceItemID, TargetID und Attribut jeder Ausgabe. Modifikationsstufe 1. Lesen von Eingaben und Ausgaben; Code: Dim sDataArray(2) as string; Dim vAttribute as variant; Dim ISourceItemID as long; DIM ITargetID as long; IRet = moSimEngine.ReadReference("Distinct_Input", vAttribute, ISourceItemID, ITargetID, sDataArray)
Beschreibung: Verfahren ReadReference des Simulationsobjekts wird den Attributwert der Eingabe oder Ausgabe, auf die durch Name Bezug genommen wird, zurückgeben und die SourceItemID, TargetID und verwandte Daten optional wiedergewinnen. Bei dem derzeitigen Beispiel werden der Attributwert, die SourceItemID, die TargetID und 3 Datenzellen für die Eingabe wiedergewonnen, die mit Distsinct Input bzw. Deutliche Eingabe benannt ist.
Beschreibung: Das Simulationsmaschinenobjekt stellt grundlegende Funktionen zur Manipulation von Listen bereit.
Das Verfahren ListAdd hängt einen Posten (SourceItemID, Attribut, Datenarray) an die Liste an. Lass uns den Algorithmus erklären. Als erstes finden wir den Anfang der Liste unter Verwendung des Listennamens. Dann suchen wir die erste leere Zelle unter der obersten Zelle. Sobald der Zielort bestimmt ist, werden die Daten in die geeigneten Zellen geschrieben, und der ICA wird über die Änderung informiert. Das Verfahren ListCount gibt die Anzahl von Posten in der spezifizierten Liste zurück. Der Algorithmus arbeitet genauso wie das Verfahren ListAdd, jedoch gibt es statt eines Einfügens eines anderen Elements die Gesamtanzahl von Posten zurück. Das Verfahren ListModify ersetzt den spezifizierten Posten mit den bereitgestellten Daten. Lass uns den Algorithmus erklären. Als erstes finden wir den Anfang der Liste unter Verwendung des Listenamens. Als zweites berechnen wir die Zeile, die um die spezifizierte Postennummer versetzt ist. Dann wird die ICA über die Beseitigung des existierenden Postens informiert. Schließlich werden die sich auf den neuen Posten beziehenden Daten in die geeigneten Zellen geschrieben und die ICA wird über die Änderung informiert. Das Verfahren ListDelete beseitigt den spezifizierten Posten. Der Algorithmus arbeitet exakt wie das Verfahren ListModify, jedoch werden keine neuen Daten hinzugefügt und die Zellen (Breite der Liste, die durch "Total Columns" gesetzt ist) werden gelöscht, wobei der Parameter "Zellen Heraufbewegen" auf wahr gesetzt ist. Behalten Sie dies im Hinterkopf, da Designer oft die falsche Zahl von Spalten in den Parameter TotalColumns bzw. Spaltengesamtzahl eintragen. Wenn sie die Spaltengesamtzahl überschätzen, wird ListDelete Teile der benachbarten Liste modifizieren, was zu fehlerhaftem Verhalten führt, wenn diese Liste angezeigt wird.
SYSTEMDYNAMIKEN
Zur Verwendung von Systemdynamikmodellen in der Architektur musste eine Maschine geschaffen werden, die Schülerarbeit in Parameter für diese Modelle übersetzen würde. Nachfolgend wird ein komplexes Systemdynamikmodell zur Interaktion mit einer existierenden Simulationsarchitektur diskutiert. Das Systemdynamikmodell stellt die folgenden Fähigkeiten bereit. Designern wird es ermöglicht, ihre Systemdynamikmodelle und ICA-Rückmeldung aufzubauen und zu testen, bevor die reale Schnittstelle aufgebaut ist. Reduzieren der Programmierkomplexität der Aktivitäten. Zentralisieren der Interaktionen mit den Systemdynamikmodellen. Systemdynamikmaschine Wie bei der Simulationsmaschine modelliert der Designer die Aufgabe, die er/sie möchte, dass sie ein Schüler unter Verwendung einer Microsoft Excel Tabellenkalkulation ausführt. Hier schafft der Designer jedoch auch ein (später beschriebenes) Systemdynamikmodell. Die Systemdynamikmaschine wird alle der signifikanten Zellen in dem Simulationsmodell (Excel) lesen und diese Werte an das Systemdynamikmodell und die ICA weitergeben. Nachdem das Systemdynamikmodell die Informationen laufen lässt, werden die Ausgabewerte durch die Maschine gelesen und dann an das Simulationsmodell und die ICA weitergegeben.
27 ist ein Blockschaltbild, das die detaillierte Architektur eines Systemdynamikmodells präsentiert. Sobald das Simulationsmodell, das Systemdynamikmodell und die Rückmeldung vollständig durch Designer getestet sind, können Entwickler die Tabellenkalkulation in eine graphische Benutzerschnittstelle, beispielsweise Visual Basic als eine Entwicklungsplattform, einbinden. 27 veranschaulicht, dass, wenn ein Schüler eine Aktivität vervollständigt, die Werte an die Systemdynamikmaschine weitergegeben werden, bei welcher die Werte dann (als eine Eingabe) an das Systemdynamikmodell weitergegeben werden, in das Simulationsmodell geschrieben werden, und an den ICA abgegeben werden. Wenn das Systemdynamikmodell abgespielt wird, werden die Ausgaben durch die Maschine gezogen und dann an das Simulationsmodell und den ICA weitergegeben. Es sei erwähnt, dass das Simulationsmodell auch die Ausgabe aus dem Systemdynamikmodell analysieren und die Ergebnisse dieser Analyse an die ICA weitergeben kann. Das Simulationsmodell kann dann für die Ausgabewerte gelesen werden und verwendet werden, um Aktivitätssteuerungen auf dem Bildschirm (wie beispielsweise Graphen oder Berichte) zu aktualisieren. Es ist sehr wichtig, dass alle Modifikationen, über welche die ICA und das Systemdynamikmodell Bescheid wissen muss, durch die Maschine gehen, da nur die Maschine weiß, wie diese Objekte aufzurufen sind. Dies reduziert signifikant das von Programmierer geforderte Fertigkeitsniveau, und reduziert in großem Maße die zum Programmieren jeder Aufgabe erforderliche Zeit. Darüber hinaus ist das Endprodukt weniger fehleranfällig, da das Modell- und Tutormanagement zentralisiert wird. Falls es ein Problem gibt, muss nur ein Codeabschnitt geprüft werden. Schließlich ist die Chance einer Dateninkonsistenz zwischen dem ICA, dem Systemdynamikmodell und der Anwendung insignifikant, da die Maschine die Daten aus der Tabellenkalkulation lädt.

Das Systemdynamikmodell erzeugt Simulationsergebnisse über der Zeit auf der Grundlage von Beziehungen zwischen den in es weitergegebenen Parametern und anderen Variablen in dem System. Ein Systemdynamikobjekt wird zur Integration mit Visual Basic und dem Tabellenkalkulationsobjekt verwendet. Das Objekt umfasst Logik, welche die Zeitdauer sowie Lese- und Schreibparameter in das Systemdynamikmodell steuert. Mit Visual Basic können wir diese Parameter an das und von dem Modell über die Werte in dem Simulationsobjekt weitergeben. Das Systemdynamikobjekt kann auch die Ausführung des Systemdynamikmodells steuern. Dies bedeutet, dass nachdem alle Parametereingaben an das Systemdynamikmodell weitergegeben sind, die Maschine das Modell laufen lassen kann, um die Parameterausgaben zu bekommen. Das Systemdynamikobjekt macht es möglich, dass die Systemdynamikmodelle einen Schritt zu einer Zeit, alle auf einmal, oder eine jede fixierte Anzahl von Zeitdauern ausführen. Wenn das Systemdynamikmodell läuft, wird jeder Schritt der Parametereingabe- und Parameterausgabedaten aus zwei Gründen in ein "Sicherungs"blatt geschrieben. Erstens kann der Bereich von Daten, die mit der Zeit empfangen werden (das Modell spielt mehrere Male ab), Verwendung finden, um Trendgraphiken zu schaffen, oder Verwendung finden, um statistische Werte zu berechnen. Zweitens kann das Systemdynamikmodell neu gestartet werden, und dieser Nachweis bzw. dieses Protokoll von Daten kann bis zu einem spezifischen Zeitpunkt in das Modell übertragen werden. Dies bedeutet, dass die Maschine Verwendung finden kann, um eine Simulation zur rechten Zeit abzuspielen. Wenn ein beliebiges Ereignis in der Systemdynamikmaschine auftritt, wird ein log geschaffen, welcher den Designern mitteilt, welche Werte an das Simulationsmodell, das Systemdynamikmodell und den ICA weitergegeben werden, sowie die derzeitige Zeit und das eingetretene Ereignis mitteilt. Der log wird "SysDyn.log" genannt und wird an demselben Ort wie die die Maschine verwendende Anwendung geschaffen. Wie mit dem Tabellenkalkulationsobjekt ermöglicht es das Systemdynamikobjekt, dass eine große Menge an Berechnungen in dem Systemdynamikmodell und nicht in dem Aktivitätscode auftritt, wodurch den Aktivitätsdesignern erneut mehr Steuerung bzw. Kontrolle verliehen wird. Modellobjekte werden verwendet, um die Systemdynamikmodelle in Hinblick auf die gespielten Zeitdauern zu konfigurieren. Modelle sind, auf was sich die Parametereingaben und Parameterausgaben (was nachfolgend diskutiert wird) beziehen, so dass diese zuerst geschaffen werden müssen. Jedes Modell hat die folgende Anwendungsprogrammierungsschnittstelle:

Feldname	Datentyp	Beschreibung
ModellID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AusgabenID der mit der Aufgabe in Zusammenhang stehenden Aufgabe
ModelName	string*50	Name des Modells (Informationszwecke)
ModelDesc	string*50	Beschreibung des Modells (Informationszwecke)
SysDynModel	string*50	Dateiname des tatsächlichen Systemdynamikmodells
Start	long	Startzeit zum Abspielen des Modells
Stopp	long	Stoppzeit zum Abspielen des Modells
Schritt	long	Intervall, mit welchem ein Modellschritt abzuspielen und Daten aufzuzeichnen sind

Diese Informationen sind in der Modelltabelle der Simulationsdatenbank gespeichert (ICASim.mdb). Alle Werte, die manuell durch den Schüler einzugeben sind, die an das Systemdynamikmodell weitergegeben werden, sind als Parametereingabeobjekte (PInputs-Objekte) konfiguriert.

Jedes PInput hat eine Schnittstelle, wie nachfolgend detailliert.

Feldname	Datentyp	Beschreibung
PInputID	long	Hauptschlüssel für die Tabelle
TaskID	long	TaskID bzw. AufgabenID der mit der Parametereingabe in Zusammenhang stehenden Aufgabe
ModelID	long	ID des mit der Parametereingabe in Zusammenhang stehenden Modells
InputName	String*50	Name der Parametereingabe (Informationszwecke)
InputDesc	String*255	Beschreibung (Informationszwecke)
ReferenceName	String*50	Name der mit der Parametereingabe verbundenen Tabellenkalkulationszelle
SimReferenceName	String*50	Name des zugehörigen Parameters in dem Systemdynamikmodell
TutorAware	Bool'scher Typ	Ob der ICA beliebige Änderungen der Eingabe mitgeteilt werden sollten
SourceItemID	long	SourceItemID bzw. QuellenPostenID der Parametereingabe
TargetID	long	TargetID bzw. ZielID der Parametereingabe
Reihe	long	Tabellenkalkulation-Reihennummer der Parametereingabe
Spalte	long	Tabellenkalkulation-Spaltennummer der Parametereingabe
SheetName	String*50	Name des Blatts, wo sich die Parametereingabe befindet

Alle diese Informationen sind für jede Parametereingabe in der Tabelle PInput der Simulationsdatenbank gespeichert (ICASim.mdb). PInputs bestehen aus einer Tabellenkalkulationszelle, die durch einen Designer zur Zeit des Designs oder durch die GBS-Anwendung bei Laufzeit über die Systemdynamikmaschinenobjektverfahren gefüllt werden kann. Der Zweck der Zelle ist es, für die Simulation und die Systemdynamikmodelle einen Eintragpunkt bereitzustellen. Ein Beispiel eines Eintragpunkts wäre der Zinssatzparameter in dem Zinsberechnungsbeispiel. Der ICA wird über beliebige Änderungen an der Zelle informiert, wenn eine geeignete Aktivität passiert. Wenn der ICA über eine Änderung informiert wird, werden zwei Mitteilungen an die ICA gesendet. Die erste ist eine Mitteilung ICANotifyDestroy mit den Parametereingabeinformationen, das heißt SourceItemID, TargetID und Null als Attribut. Diese Mitteilung dient zur Information des ICA, Informationen aus seinem Speicher zu beseitigen. Die zweite Mitteilung ist eine Mitteilung ICANotifyCreate mit den Parametereingabeinformationen, das heißt SourceItemID, TargetID, Attribut (numerischer Zellenwert). Diese Mitteilung weist die ICA an, diese Informationen in ihren Speicher hinzuzufügen. Nachfolgend ist eine PInput-Tabellenaufzeichnung präsentiert.

PInputID:	12345
TaskID.	123
ModelID:	1
InputName:	Zinssatzeingabe
InputDesc:	Zinssatzeingabe in Zinsberechnungsmodell
ReferenceName:	Zins_Satz
SimReferenceName:	Parameter_Zins_Satz
TutorAware:	Wahr
SourceItemID:	\1201
TargetID:	4001
Reihe:	6
Spalte:	3
SheetName:	Blatt1

Sobald die Konfiguration vervollständigt ist, kann der Designer auch die ICA-Betriebsmittel verwenden, um die Simulation zu testen. Die Werte von Reihe, Spalte und SheetName werden automatisch gefüllt, wenn der Designer die Parameter in der Systemdynamikarbeitsbank in den ICA-Betriebsmitteln laufen lässt. Die folgenden Informationen stellen Einzelheiten bereit, welche die Interaktionskomponenten beschreiben.

Titel	Beschreibung
Verfahrensaufgabe (w/Ziehen und Ablegen)	Aufgaben, welche die Konstruktion einer gewissen Art von Bericht mit Beweis von Ziehen und Ablegen erfordern, um Folgerungen zu begründen
Verfahrensaufgaben (w/o Ziehen und Ablegen)	Neue Aufgabenentwürfe bzw. Aufgabendesigns, die von Natur aus verfahrensmäßig sind, haben eine sehr geringe Verzweigung und, haben immer eine korrekte Antwort.
Dingdong-Aufgabe	Aufgaben, welche den Schüler unterbrechen, während er an etwas anderem arbeitet. Diese Vorlage umfasst Interviewen zur Bestimmung des Problems, und eine einfache Prüfboxeingabemaske zur Entscheidung, wie auf die Situation zu antworten ist.
Aufgabe Analysieren und Entscheiden (ANDIE)	Am meisten allgemein zur statischen Ursachenanalyse, oder Identifikation von Aufgaben verwendet. Entwickelt auf SBPC als ein Ergebnis von 3 Projekten eines Erfahrungsneudesigns für dieselbe Fertigkeit.
Optionen Bewerten (ADVISE)	Verwendet für Aufgaben, die einen Lernenden fordern, zu bewerten, wie verschiedene Optionen dargelegte Ziele oder Anforderungen erfüllen. Entwickelt auf SBPC als ein Ergebnis von 4 Projekten eines Erfahrungsneudesigns für dieselbe Fertigkeit. Lässt kein Ziehen und Ablegen als Beweis zu.
Aufgabe, eine Firma zu führen	Zeitbasierte Simulation, bei welcher der Schüler "das eigene Abenteuer wählt". Jedes Mal wählt der Schüler aus einer vorbestimmten Liste von vorzunehmenden Aktionen. Entwickelt auf SBPC als eine vereinfachte Version der BDM-Managementaufgabe.
Aufgabe, ein Modell zu verwenden	Wenn Benutzer mit einem quantitativen Modell interagieren muss, um eine was wenn Analyse durchzuführen. Kann zur dynamischen Ursachenanalyse verwendet werden – Laufen Lassen von Tests auf einem Teil zur Analyse von Stresspunkten
Aufgabe ICA-Dynamiktreffen	Entwickelt auf BDM, um Interaktionsstile von Nachhilfevermittler und ILS EPA zu simulieren. Unterstützt dynamikregelbasiertes Verzweigen - wird zu Unterstützungsinteraktionen wie EnCORE Verteidigungstreffen und JA skalieren
Managementaufgabe	Zeitbasierte Simulation, bei welcher Schüler ein Management von Quellen durchführt. Management von menschlichen Quellen, Management eines Etats, Management eines FX-Portfolios.
Aufgabe QVID statisches Treffen	Entwickelt auf Sim2, um agendagesteuerte Treffen zu unterstützen, bei welchen dem Benutzer 5 Stufen von Nachfolgefragen präsentiert werden, um eine Fragelinie zu verfolgen. Wenn sie jede Frage fragen, erscheinen ihre Nachfolgefragen.
Flussdiagrammaufgabe	Wird die meisten VISIO-Schaubilder unterstützen. Entwickelt auf Sim2, um einfache Flussdiagrammentscheidungsmodelle zu unterstützen.
QVID Sammeldatenkomponente	Statische flache Liste von zu fragenden Fragen, wenn jemand interviewt wird. Wird nicht verwendet, wenn Interviewfertigkeiten gelehrt werden (verwende Aufgabe QVID statische Treffen). Unterstützt hierarchische Fragen und zeitlich festgelegte Niederschriften
Aufgabe Journaleintrag	Erzeugt zur Unterstützung von einfachen Journaleintragaufgaben mit bis zu zwei Konten pro Lastschrift oder Gutschrift
Neue komplexe Aufgabe	Eine neue Aufgabe, die eine Simulationskomponente erfordert.

Die Systemdynamikmaschine ist die Schnittstelle zwischen dem Simulationsmodell, dem Systemdynamikmodell, der Simulationsdatenbank und dem Intelligenter-Nachhilfevermittler. Die Systemdynamikmaschine interessiert den Designer, so dass er ihre Mechaniken verstehen kann. Sobald der Designer das Simulationsmodell (Exceltabellenkalkulation) konstruiert hat, das Systemdynamikmodell (PowerSim) aufgebaut hat und alle Parametereingaben und Parameterausgaben konfiguriert hat, kann ein Test unter Verwendung der Arbeitsbank durchgeführt werden, die in den ICA-Betriebsmitteln umfasst ist (vgl. die Dokumentation ICA-Betriebsmittel). Die Entwickler müssen wiederum die Aufrufe an die Systemdynamikmaschine in der GBS-Anwendung ausführen, die aufgebaut wird. Die folgende Liste identifiziert die Dateien, die in dem Visual Basic Projekt umfasst sein müssen, um die Systemdynamikmaschine zu verwenden.

WsysDynEng.cls	Systemdynamikmaschinenklasse
wSysDynEng.bas	Systemdynamikmaschinenmodul (dieses Modul wurde nur für Geschwindigkeitszwecke eingeführt, da aller Code theoretisch in der Klasse eingekapselt sein sollte)
wConst.bas	konstante Bezeichnung bzw. Deklaration von Intelligentem Nachhilfevermittler
wDeclare.bas	DLL-Schnittstelle von Intelligentem Nachhilfevermittler
wIca.cls	Klasse von Intelligentem Nachhilfevermittler
wlca.bas	Modul von Intelligentem Nachhilfevermittler (dieses Modul wurde nur für Geschwindigkeitszwecke eingeführt, da aller Code theoretisch in der Klasse eingekapselt sein sollte)

Um die Systemdynamikmaschine vollständig zu verwenden, müssen die Designer Code in verschiedenen strategischen Bereichen oder Stufen der Anwendung platzieren. Anfangszustand – das Laden der Eingabemaske, welche die Simulationsfront bzw. Simulationsvorderansicht enthält. Dies findet statt, wenn das Simulationsmodell und die Systemdynamikmaschine initialisiert werden. Modifikationszustand – Findet statt, wenn der Benutzer Änderungen an der Vorderansicht vornimmt, welche einen Einfluss auf das Simulationsmodell ausüben (PInputs). Dies findet statt, wenn die ICA darüber informiert wird, was stattfindet. Laufzustand – Das Systemdynamikmodell wird laufen gelassen und es werden Parameterausgaben empfangen. Rückmeldungszustand – der Benutzer fordert Rückmeldung für die Arbeit an, die sie durchgeführt haben. Dies findet statt, wenn die Simulation die ICA über alle Ausgabenänderungen informiert. Letzte Stufe – Die Simulationsvorderansicht wird heruntergefahren. Dies findet statt, wenn das Simulationsmodell gespeichert wird. Diese Stufen werden erläutert, indem der involvierte Visual Basic Code sowie eine kurze Beschreibung dieses Codes umfasst wird.
Anfangsstufencode
1. Schaffen des ICA & der Simulationsmaschinenobjekte: Code: Set moSysDynEngine = New classSysDynEngine; Set moICA = New classICA; Beschreibung: Der erste Schritt bei Verwendung der Systemdynamikmaschine ist, ein Beispiel der Klasse classSynDynEngine und auch ein Beispiel der Klasse classICA zu schaffen. Es sei erwähnt, dass die Maschine und die ICA Variablen von Modulniveauobjekt "mo" sein sollen. 2. Laden der Simulation; Code: IRet = moSysDynEngine.OpenSimulation (FILE_SIM, Me.bookSim, True); IRet = moSysDynEngine.LoadSysDyn(mlICA, TaskID, DB_SIMULATION, 1); IRet = moSysDynEngine.LoadModel(MODEL_NAME, mbTaskStarted); Beschreibung: Nach der Objektschaffung müssen die Verfahren OpenSimulation, LoadSimulation und LoadModel des Systemdynamikmaschinenobjekts aufgerufen werden. Das Verfahren OpenSimulation liest die spezifizierte Excel 5.0 Tabellenkalkulationsdatei (FILE_SIM) in eine Tabellenkalkulationssteuerung (bookSim). Das Verfahren LoadSysDyn öffnet die Simulationsdatenbank (DB_SIMULATION) und lädt eine Liste von Parametereingaben und eine Liste von Parameterausgaben in einen Speicher. Das Verfahren LoadModel öffnet ein Systemdynamikmodell (MODELL_NAME). Jedes Verfahren der Systemdynamikmaschine wird 0 zurückgeben, falls es erfolgreich endet, andernfalls wird eine geeignete Fehlerzahl zurückgegeben. 3. Initialisieren und Laden des Intelligenten Nachhilfevermittlers; Code: IRet = moICA.Initialize (App.Path&"\"&App.EXEName&".ini", App.Path&DIR_DATABASE, App.Path&DIR_ICADOC, App.Path&"\"); IRet = molCA.LoadTask (mlICATaskID, ICAStudentStartNew); Beschreibung: Die Systemdynamikmaschine arbeitet nur in Verbindung mit der ICA. Das Initialisierungsverfahren des ICA-Objekts liest die Anwendungsdatei .ini und setzt die Tutor32.dll geeignet. Das Verfahren LoadTask teilt der ICA mit (Tutor32.dll), das Dokument .tut zu laden, das mit einer spezifischen Aufgabe in dem Speicher in Zusammenhang steht. Von dem Punkt an kann die ICA Mitteilungen bzw. Informationen empfangen. Es sei erwähnt: Das Dokument .tut enthält alle Element- und Rückmeldungsstruktur einer Aufgabe. Ex: SourcePages bzw. QuellenSeiten, SourceItem bzw. QuellenPosten, TargetPages bzw. ZielSeiten, Targets bzw. Ziele, etc... 4. Wiederherstellen der Simulation; Code: IRet = moSysDynEngine.RunPInputs(MODEL_NAME, True); IRet = moSysDynEngine.RunPOutputs(MODEL_NAME, True); IRet = moSysDynEngine.PassPInputsAll; Call moICA.Submit(0); Call moICA.SetDirtyFlag(0, False); Beschreibung: Wiederherstellen der Simulation umfasst viele Dinge: Löschen aller Parametereingaben und Ausgaben, wenn der Benutzer durchstartet; Laden der Schnittstelle mit Daten von dem Simulationsmodell; Aufrufen des Verfahrens PassPInputsAll des Systemdynamikmaschinenobjekts, um die ICA in ihren ursprünglichen Zustand zu bringen; Aufrufen der Verfahren RunPInputs und RunPOutputs des Systemdynamikmaschinenobjekts, um das Systemdynamikmodell in seinen Originalzustand zu bringen; Aufrufen des Verfahrens Submit des ICA-Objekts, um den ICA zu triggern, alle Regeln abzuspielen; Aufrufen der SetDirtyFlag des ICA-Objekts, um die Benutzersitzung zurückzusetzen. Ein Laufen Lassen von Parametern umfasst ein Gehen durch die Liste von TutorAware-PInputs und POutputs und Informieren des ICA über den Wert von SourceItemID, TargetID und Attribut jedes einzelnen Modifikationszustands; 1. Lesen von Parametereingaben&-ausgaben: Code: Dim sDataArray(2) as string; Dim vAttribute as variant; Dim ISourceItemID as long; ITargetID as long; IRet = moSysDynEngine.ReadReference("Input_Name", vAttribute, ISourceItemID, ITargetID, sDataArray). Beschreibung: Das Verfahren ReadReference des Systemdynamikobjekts wird den Attributwert der Parametereingabe oder -ausgabe, auf die durch Name Bezug genommen wird, zurückgeben und optional die SourceItemID, TargetID und verwandte Daten wiedergewinnen. Bei dem derzeitigen Beispiel werden der Attributwert, die SourceItemID, die TargetID und 3 Datenzellen für die Parametereingabe wiedergewonnen, die mit Input Name benannt ist. 2. Modifizieren von Parametereingaben Code: Dim vAttribute as variant; Dim ISourceItemID as long; Dim sDataArray(2) as string; vAttribute = 9999; sDataarray(0) = "Data Cell #1"; sDataarray(1) = "Data Cell #2"; sDataarray(2) = "Data Cell #3"; IRet = moSysDynEngine.WriteReference("Input_Name", vAttribute, sDataArray). Beschreibung: Um eine Parametereingabe zu modifizieren, rufe das Verfahren WriteReference des Systemdynamikobjekts auf und gib den PInput-ReferenceName bzw. PInput-Bezugsnamen, den neuen Attributwert und optional ein Datenarray (eine zusätzliche Information zum Speichern des Simulationsmodells) weiter. Die Systemdynamikmaschine informiert den ICA über die Änderung. Laufzustand 1. Abspielen des Systemdynamikmodells; Code: IRet = moSysDynEngine. PlayModel(SYSDYN_PLAYSTEP); IbICurrentTime.Caption = moSysDynEngine.CurrentTime; and IbILastTime.Caption = moSysDynEngine.LastTime; Beschreibung: Ein Abspielen des Systemdynamikmodells wird auch durch die Systemdynamikmaschine gehandhabt. Es gibt drei Wege, wie die Modelle abgespielt werden können, alle auf einmal, ein Schritt zu einer Zeit (wie zuvor gezeigt), oder bis zu einem spezifischen Zeitpunkt. Dies sind die Parameter, die in das Verfahren PlayModel weitergegeben werden. Abspielen des Modells erzeugt die Parameterausgabewerte und gibt die Tutor Aware POutputs bzw. POutputs von Tutor bewusst an das ICAT weiter. Die Maschine verfolgt auch die Zeit, und diese Werte können unter Verwendung der Eigenschaften CurrentTime (= derzeitige Zeit) und der LastTime (= letzte Zeit) gelesen werden. 2. Zurückspringen in einem Systemdynamikmodell Code: IRet = moICA.LoadTask(mlICATaskID, ICAStudentStartNew); IRet = moSysDynEngine. JumpBack(TIME_TO_JUMP_TO). Beschreibung: Da die Systemdynamikmaschine Sicherungskopien der an sie weitergegebenen und von ihr weitergegebenen Parameter schreibt, kann sie durchstarten und diese Werte bis zu einer gegebenen Zeitdauer zurück an das Systemdynamikmodell erneut abgeben. Um dies zu bewerkstelligen, müsste der Code die ICA neu starten und dann die Systemdynamikmaschine aufrufen, zu einer gegebenen Zeit zurückzuspringen. (TIME_TO_JUMP_TO).
Rückmeldungszustand 1. Triggern der ICA-Regelmaschine; Code: IRet = moICA.Submit(ICoachID); Beschreibung: Sobald die Simulation verarbeitet worden ist, muss das Verfahren Submit des ICA-Objekts aufgerufen werden, um alle Regeln zu triggern und die Rückmeldung zu liefern. Diese Rückmeldung wird durch die Tutor32.dll in zwei RTF-formatierte Dateien geschrieben. Eine Datei für die vorhergehende Rückmeldung und eine Datei für die derzeitige Rückmeldung.
ICA-Konfiguration
28 ist ein Übersichtsdiagramm der zur Anfangskonfiguration verwendeten Logik. Da die Struktur der Rückmeldung dieselbe ist, wie andere Onlineaktivitäten, kann die ICA auch auf dieselbe Weise konfiguriert werden. Zur Vereinfachung einer Schaffung und Aufrechterhaltung von ICA-Rückmeldung wird es empfohlen, dass die Rückmeldung derart konstruiert ist, dass nur eine Regel bei einem beliebigen Zeitpunkt abgibt bzw. auslöst. Es sei erwähnt, dass die Organisation des Beispiels einer von vielen Wegen ist, die Rückmeldung zu strukturieren. Schritt 1: Schaffen eines Kennfelds von Fragen und Nachfolgefragen; Bevor Designer eine Konfiguration der ICA starten, sollten sie ein Kennfeld der Fragen, Videos und Nachfolgefragen zeichnen, welche sie bei dem Onlinetreffen verwenden wollen. Dies wird ihnen ein gutes Verständnis der Interaktionen geben, wenn sie die ICA konfigurieren. Schritt 2: Schaffen eines Coachs bzw. Nachhilfevermittlers; Alle Rückmeldung wird durch einen Nachhilfevermittler gegeben. Schaffen eines spezifischen Nachhilfevermittlers für das Onlinetreffen. Schritt 3: Schaffen der SourceItems bzw. Quellenposten und Targets bzw. Ziele.
Jede Frage wird ein QuellenPosten (1) und ein Ziel (2) haben, das mit ihnen in Zusammenhang steht. Diese werden durch die ICA verwendet, um Videos und Nachfolgefragen zu zeigen. Für organisierte Zwecke und Vereinfachung eines Lesens wird es empfohlen, dass jede Quellseite ("0 Intro) alle Nachfolgefragen ("Intro Q1", "Intro Q2", "Intro Q3") enthält. Ziele können jeweils als eins pro Quellenposten (wie hier gezeigt) oder als eins pro viele Quellenposten geschaffen werden. Dies ist nicht sehr wichtig, solange sie deutliche Zusammenhänge zwischen QuellenPosten und Ziel sind. Sobald die QuellenPosten und Ziele geschaffen worden sind, sind sie in Zusammenhang mit Quellenposten Ziele (3) zu stellen und ihnen die Relevanz von einem zu geben. Dies sind die einzigartigen Identifizierer, welche die ICA verwenden wird, um Regeln auszulösen und dem Schüler Rückmeldung zu geben. Schritt 4: Schaffen des Elterndateikopfes bzw. Vorgängerdateikopfes (Videoinformationen). 29 ist eine Anzeige von Videoinformationen. Rückmeldung (NachhilfevermittlerPosten) sind in ZielGruppen (1) organisiert. In 29 hat jede Onlinefrage eine Zielgruppe zur Vereinfachung der Aufrechterhaltung. Jede Zielgruppe muss zumindest ein verwandtes Ziel (4) haben. Diese sind die QuellenPostenZiel-Abbildungen, die bei dem Ende von Schritt 3 gemacht wurden. Als Nächstes werden Regeln (2) geschaffen, um sie zu auszulösen, wenn das QuellenPostenZiel abgebildet wird (eine Frage wird angeklickt). NachhilfevermittlerPosten (3) sind mit einer Regel in Zusammenhang gebracht und repräsentieren die Rückmeldung, welche gezeigt wird, falls die Regel ausgelöst wird. Die ICA-Betriebsmittel umfassen Geschäftssimulationen in einer Multimediaanwendung. Dies bedeutet, dass es nun eine Mittelschicht zwischen der Anwendung und dem ICAT gibt. Diese Betriebsmittel ermöglichen zusammen mit der (später beschriebenen) Simulationsmaschine, dass die Architektur eine Vorderansicht der Simulation ist. Nun müssen beliebige Änderungen an einem Simulationsmodell nicht in Code eingebunden werden. Die ICA-Betriebsmittel und die Simulationsmaschine arbeiten mit Simulationsmodellen, die in Microsoft Excel geschaffen sind. Nachdem das Modell geschaffen ist, verwendet der Designer die Funktion Definierter Name in Excel, um spezifische Zellen zu kennzeichnen, die durch die Anwendung und die ICA-Betriebsmittel gemäß einem bevorzugten Ausführungsbeispiel zu verwenden sind. 30 veranschaulicht ein ICA-Betriebsmittel. Die ICA-Betriebsmittel bestehen aus sechs Betriebsmitteln, die mit dem Intelligenter-Nachhilfevermittler-Werkzeug (ICAT) arbeiten, um Geschäftssimulation in die Multimediaanwendung einzubinden.

Claims

Verfahren, das ein Computergerät zur Schaffung eines Unterrichtssystems verwendet, wobei das Computergerät ein Computerbetriebssystem und eine Anwendungsarchitektur und zumindest zwei durch die Anwendungsarchitektur gesteuerte Komponenten umfasst, wobei das Verfahren die Schritte umfasst (a) Präsentieren von Informationen, die ein Ziel anzeigen, (b) Integrieren von Informationen in das Computergerät, welche eine Erzielung des Zieles motivieren, (c) Empfangen einer Eingabe von einem Schüler, (d) Analysieren von Systemwerkzeugen, welche die Eingabe des Schülers unter Verwendung einer künstliche-Intelligenz-Maschine des Computergeräts verarbeiten, und (e) Bereitstellen einer Rückmeldung zum Assistieren des Schülers beim Verwenden des Unterrichtssystems, um das Ziel zu erreichen, indem Fehler bei einer Eingabe des Schülers zur Kenntnis genommen werden und eine fördernde Unterrichtsrückmeldung auf einer Tutor- oder Repetitorebene dynamisch präsentiert wird, die von einer Datenbank genommen wird, und eine korrekte Eingabe des Schülers integriert wird, so dass die Navigation durch das Unterrichtssystem mit einer durch den Schüler gesteuerten Geschwindigkeit geschieht, dadurch gekennzeichnet, dass die Rückmeldung zudem eine Schnittstellenrückmeldung in der Form einer Systemmitteilung umfasst, die eine äußere Erscheinung hat, die von der von der Datenbank genommenen anderen Rückmeldung verschieden ist, und die durch eine schnelle Schnittstellenprüfung erzeugt wird, die bei einer Anwendungsschnittstelle vorgenommen wird, um auf einer Schnittstellenebene ohne Zugriff auf die Datenbank Förderung bereitzustellen.
Verfahren nach Anspruch 1, wobei die Rückmeldung Videoinformationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung Audioinformationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung elektronische-Mail-Informationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung simulierte Informationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung Informationen umfasst, die von einem Netzwerk erlangt werden.
Verfahren nach Anspruch 1, wobei die Rückmeldung Telefonieinformationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung Videokonferenzinformationen umfasst.
Verfahren nach Anspruch 1, wobei die Rückmeldung Chatrauminformationen umfasst.
Computergerät zur Schaffung eines Unterrichtssystems zur Präsentation auf einer Anzeigevorrichtung, mit (a) einem Prozessor, (b) einem Speicher, der Informationen unter der Steuerung des Prozessors speichert, (c) einem Computerbetriebssystem und einer Anwendungsarchitektur, und (d) zumindest zwei Komponenten, welche durch die Anwendungsarchitektur gesteuert werden, und umfassen 1. Logik, die Informationen präsentiert, die ein Ziel anzeigen, 2. Logik, die Informationen integriert, welche eine Erzielung des Zieles motivieren, und 3. Logik, die eine Eingabe von einem Schüler empfängt, 4. Logik, die Systemwerkzeuge analysiert, welche die Eingabe des Schülers unter Verwendung einer künstliche-Intelligenz-Maschine verarbeiten, und 5. Logik, die eine Rückmeldung zum Assistieren des Schülers beim Verwenden des Unterrichtssystems bereitstellt, um das Ziel zu erreichen, indem Fehler bei einer Eingabe des Schülers zur Kenntnis genommen werden und eine fördernde Unterrichtsrückmeldung auf einer Tutor- oder Repetitorebene dynamisch präsentiert wird, die von einer Datenbank genommen wird, und eine korrekte Eingabe des Schülers integriert wird, so dass die Navigation durch das Multimediaunterrichtssystem mit einer durch den Schüler gesteuerten Geschwindigkeit geschieht, dadurch gekennzeichnet, dass die Logik zur Rückmeldung eine Logik für eine Schnittstellenrückmeldung in der Form einer Systemmitteilung umfasst, die eine äußere Erscheinung hat, die von der von der Datenbank genommenen anderen Rückmeldung verschieden ist, und die durch eine schnelle Schnittstellenprüfung erzeugt wird, die bei einer Anwendungsschnittstelle vorgenommen wird, um auf einer Schnittstellenebene ohne Zugriff auf die Datenbank Förderung bereitzustellen.
Gerät nach Anspruch 10, wobei die Rückmeldung Videoinformationen umfasst.
Gerät nach Anspruch 10, wobei die Rückmeldung Audioinformationen umfasst.
Gerät nach Anspruch 10, wobei die Rückmeldung elektronische-Mail-Informationen umfasst.
Gerät nach Anspruch 10, wobei die Rückmeldung simulierte Informationen umfasst.
Gerät nach Anspruch 10, wobei die Rückmeldung Informationen umfasst, die von einem Netzwerk erlangt werden.
Gerät nach Anspruch 10, wobei die Rückmeldung Telefonieinformationen umfasst.
Gerät nach Anspruch 10, wobei die Rückmeldung Videokonferenzinformationen umfasst.
Gerät nach Anspruch 11, das Logik umfasst, die ein Multimediaunterrichtssystem schafft, wobei die Rückmeldung Chatrauminformationen umfasst.