Funktionsweise von Amacont

Das Projekt Amacont verfolgt das Ziel der softwaretechnologisch einfachen, komponentenbasierten Entwicklung adaptiver WebSeiten. Um dabei neben benutzerabhängigen Anpassungen ebenso die Präsentationsplattform und das Übertragungssystem unterstützen zu können, besteht die Architektur derzeit aus folgenden, in der obigen Grafik veranschaulichten Komponenten:

Komponenten-Repository

Alle Rohmaterialien sind hier abgelegt. Es umfasst somit den gesamten Kontent.

Speicherung des Nutzerverhaltens

Durch Interaktionen des Nutzers werden permanente individuelle Regeln erstellt und gespeichert.

UserModeling mit Hilfe des CDL4-Algorithmus

Der CDL4-Algorithmus wird zur temporären Benutzermodellierung eingesetzt. Er betrachtet den Besucher jeweils nur während einer Session und kann daher kein genauso detailliertes Model wie bei einer Langzeit-Beobachtung liefern. Um ein Modell zu erstellen, werden Nutzerinteraktionen über Javascript-Einbettungen im clientseitigen Dokument gesammelt und in Form von Instanzen an den in Java implementierten Algorithmus übergeben. Dieser generiert damit Regeln für die zukünftige Darbietung von Inhalten und ermöglicht somit eine Präsentation entsprechend der Vorlieben des Nutzers.

Nutzermodell-Generierung

 

Pipeline-basierende Dokument-Generierung

Der Aufbau dieser Komponente wird in den folgenden Abschnitten unter Zuhilfenahme der durch die Komplexpraktika 2002/03 und 2003/04 erstellten Dokumentationen [Ama03] und [Ama04] näher erläutert.

Die dynamische Generierung eines Dokumentes auf der Basis eines Pipeline-Konzeptes ermöglicht, wie im vorigen Unterkapitel bereits vorgestellt, die schrittweise Transformation von Komponenten zu einem konkreten Ausgabeformat. 

Ablauf der Amacont-Pipeline

Dazu wird am Beginn der Pipeline abhängig von der Client-Anfrage ein Dokument aus dem Komponenten-Repository geladen, welches die abstrakte Beschreibung des zu präsentierenden Web-Inhaltes enthält. Dies sind mögliche Varianten und Ausprägungen des Inhaltes, der Darstellung und der Struktur.  

Über das Nutzermodell, welches eine Voraussetzung ist und zu Beginn einem Standard-Nutzer entspricht, wird das Dokument angepasst. Das Nutzermodell ist ein XML-Dokument und besteht aus Parametern, die benutzer- oder gerätespezifische Eigenschaften wie Endgerät, Bandbreite, Alter, Interesse, u.a. enthalten. Diese werden bei Interaktionen des Nutzers automatisch in einer vorangestellten Pipeline generiert und am Anfang der Pipeline vom Generator mit dem Eingabedokument zusammengeführt.

Darauf folgend wird das Ausgangsmaterial der Nutzerklasse, den Nutzereigenschaften und -präferenzen angepasst. Dies ist ein sehr guter Ansatzpunkt für Caching-Verfahren, da die Anpassung zu Beginn bei mehreren Nutzern identisch sein wird und stufenweise erfolgen kann. Beispielsweise ist anzunehmen, dass mehrere Nutzer dasselbe Endgeräte-Konzept benötigen, welches im Nutzermodell gespeichert ist und exemplarisch ein Handy mit kleinem Bildschirm und geringer Farbtiefe darstellen könnte. Somit würden alle das Endgerät betreffende Änderungen, wie gering aufgelöste Grafiken und fehlende alternative Querverlinkungen, einmalig gecached und somit die Performance entscheidend erhöht werden. Um dies gewährleisten zu können, werden die Anpassungen nach dem Generator schrittweise in mehreren Transformationsschritten im Transformator parametrisiert.

Pro Transformationsschritt werden die jeweilig relevanten Nutzerparameter übergeben, womit die Abarbeitung auf bestimmte Parameter eingeschränkt ist. Beachtung findet dabei das im letzten Schritt übergeben "_end_", durch welches der letzte die Adaption bearbeitende Transformator sie mit dem Entfernen aller adaptiven Eigenschaften sowie des Nutzermodells aus dem Eingabedokument abschließt. 

Nach weiteren Dokumentanpassungen wandelt nun der letzte Transformator mit Hilfe des endgerätespezifischen Stylesheets den Datenstrom in das Ausgabeformat.