next up previous contents
Next: 12.2 Autorensysteme Up: 12. Entwicklungsumgebungen Previous: 12. Entwicklungsumgebungen

Unterabschnitte

  
12.1 Programmierumgebungen

Die stetige Leistungssteigerung der Hardware ermöglicht es, daß immer neue Bereiche für multimediale Anwendungen gefunden werden. Die Software für das Abspielen von Musikvideos, Lernsoftware zur Schulung von Mitarbeitern oder die Software zur Realisierung eines Videokonferenzsystems sind nur einige Beispiele. Der Begriff ,,multimediale Anwendungen`` ist dabei gleichbedeutend mit der Verarbeitung, Steuerung und Generierung von Interaktionen und Informationen verschiedener kontinuierlicher Medien. Informationen, die auf multimediale Art und Weise präsentiert werden, können vom Benutzer besser aufgenommen werden. Der Grund dafür ist, daß sich Informationen, die Video-, Audio-, Graphik- und Textausgaben beinhalten, i.a. sehr viel besser vermitteln lassen, als jene, die lediglich in Form von Text dargestellt werden.

Interaktivität und Medienintegration stellen die Schlüsselbegriffe der Multimedia-Technologie dar. Interaktivität ist dann gewährleistet, wenn der Benutzer den Ablauf und das Layout der multimedialen Anwendung über eine Benutzerschnittstelle beeinflussen kann. Unter der Medienintegration ist die Vereinigung unterschiedliche Medientypen wie z.B. Text, Video und Audio in eine multimediale Anwendung zu verstehen. Ermöglicht wurde sie erst durch die fast vollständige Digitalisierung der Medienverarbeitung. Sowohl die Interaktivität als auch die Medienintegration tragen dabei zur Effektivität der Kommunikation zwischen Mensch und Computer bei.

12.1.1 Allgemeine Anforderungen

12.1.1.1 Anforderungen an multimediale Anwendungen

Multimediale Anwendungen sollten folgende Kriterien erfüllen:

12.1.1.2 Anforderungen an die Programmierumgebung

Die Programmierumgebung multimedialer Anwendungen sollte folgende Konzepte bereitstellen bzw. Kriterien erfüllen:

12.1.2 Elementare Begriffe und Konzepte der Multimedia-Programmierung

12.1.2.1 Medientypen

Die Charakterisierung eines Medientyps erfordert eine Differenzierung zwischen Perzeptions- und Repräsentationsmedium. 12.1

Das Perzeptionsmedium beschreibt die Art und Weise der Informationsaufnahme durch den Menschen. Informationen können heutzutage sowohl akustisch als auch visuell vermittelt werden. Beispiele für akustische Medien sind Musik, Geräusch und Sprache. Visuelle Medien sind z.B. Text,Einzelbild und Bewegtbild.

Das Repräsentationsmedium bestimmt die Verarbeitungsstruktur der Information. Es ist bei analoger Datenverarbeitung das verwendete Signalformat. Bei digitaler Datenverarbeitung ist das Repräsentationsmedium die verwendete Datenkodierung.

Ein Medientyp wird durch ein Perzeptionsmedium und ein Repräsentationsmedium beschrieben. Er wird dabei in der Regel nach dem Perzeptionsmedium benannt. Medientypen können diskret (zeitinvariant) oder kontinuierlich (zeitvariant) sein. Ein Medientyp heißt diskreter Medientyp, wenn die Informationen des Perzeptionsmediums zeitunabhängig sind. Diskrete Medientypen sind z.B. Text, Graphik oder Bild. Ein Medientyp heißt kontinuierlicher Medientyp, wenn die Darstellungswerte des Perzeptionsmediums zeitabhängig sind. Beispiele für kontinuierliche Medientypen sind Audio, Video oder Animation. Die Folge der Darstellungswerte einer gespeicherten Information eines konkreten kontinuierlichen Medientyps wird zu einem Datenstrom zusammmengefaßt. Formal definiert bezeichnet ein ,,Datenstrom`` eine Folge von zeitlich aufeinanderfolgenden Informationseinheiten (engl.:Logical Data Unit, LDU), deren Struktur durch das Repräsentationsmedium festgelegt ist. Eine LDU kann somit als zeitlich kleinste Informationseinheit eines Repräsentationsmediums betrachtet werden und ist vom Perzeptionsmedium unabhängig. Sie bestimmt damit die Granularität der Verarbeitung der Daten eines kontinuierlichen Medientyps. Ein Video kann in sehr unterschiedlichen Granularitäten abgespeichert werden. Es kann z.B. als Folge von Pixeln, digitalisierten Bildausschnitten, digitalisierten Einzelbildern oder als Folge von digitalisierten Bildsequenzen verarbeitet werden. Der ,,Datenstrom`` eines diskreten Medientyps besteht im übrigen aus genau einer LDU.

12.1.2.2 Medienobjekte

Multimedia-Daten können von folgenden Komponenten verarbeitet werden:

Eine Quelle (engl.:sources) produziert einen Datenstrom eines konkreten Medientyps. Dies wird oftmals durch die Verarbeitung von Eingangssignalen realisiert. Eine künstliche Generierung eines Datenstromes durch den Computer ist ebenfalls möglich.

Eine Senke (engl.:sinks) empfängt einen Datenstrom und ist in der Lage, diesen über eine Ausgabeeinheit darzustellen.

Ein Filter (engl.:filter) vereint die Eigenschaften von Quelle und Senke. Er ist somit nicht nur fähig, Datenstöme von Quellen und Filtern zu empfangen, sondern auch in der Lage, Datenstöme an Senken und Filter weiterzuleiten. Filter werden meistens dazu benutzt, um Datenstöme zu konvertieren. Zum Beispiel kann zur Verbesserung der Klangqualität eine Konvertierung einer Audio-Ausgabe von einem Mono-Datenstrom in einen Stereo-Datenstrom erfolgen.

Ein Medienobjekt ist entweder eine Quelle, eine Senke oder ein Filter. Eine typische Quelle stellt das Medienobjekt Mikrofon dar. Als typische Senke kann das Medienobjekt Lautsprecher angesehen werden.

Ein Medienkanal legt die Datenflußpfade zwischen Medienobjekten fest. Jedes in Software realisierte Medienobjekt besitzt dabei ein oder mehrere Zugriffspunkte (engl.:ports), die die Ein- und Ausgabeschnittstellen repräsentieren.

Medienobjekte übernehmen die Verantwortung für die zeitlich korrekte Verarbeitung von Datenströmen. Um die zeitlichen Anforderungen zu definieren, werden drei weitere Begriffe eingeführt:

12.1.2.3 Medienkomposition

Die Mechanismen der Medienkomposition ermöglichen die Integration verschiedener Medientypen in eine multimediale Anwendung. Diese realisieren somit die von einer multimedialen Anwendung geforderte Medienunabhängigkeit. Die Komposition legt u.a. die geometrische Struktur, den zeitlichen Verlauf und den Inhalt einer multimedialen Anwendung fest. Es existieren nach Steinmetz drei Arten der Medienkomposition [Ste93c]:

12.1.2.3.1 Räumliche Komposition

Die räumliche Komposition beschreibt die geometrische Struktur multimedialer Benutzerschnitstellen. Die Umsetzung in ein konkretes Layout erfolgt dabei über das verwendete Geometrie-Management. Unter Geometrie-Management versteht man die Beschreibung und Einhaltung von Abhängigkeiten zwischen den geometrischen Attributen der Objekte einer Benutzungsoberfläche. Abhängigkeiten können z.B. über die Größe, Position, Anordnung oder Reihenfolge von Objekten innerhalb eines Fensters spezifiziert werden. Um kontinuierliche Medientypen in das Geometrie-Management zu integrieren, müssen Informationen über ihre räumliche Ausprägung zur Verfügung stehen.

12.1.2.3.2 Konfigurelle Komposition

Die konfigurelle Komposition modelliert Medienkanäle. Sie stellt die Kopplung von Medienobjekten über Zugriffspunkte bereit. Wenn ein Medienobjekt einen Datenstrom nicht verarbeiten kann, so muß eine Typkonvertierung des Datenstroms vorgenommen werden. Das kann explizit durch einen Filter realisiert werden oder implizit durch das jeweilige Medienobjekt selbst.

12.1.2.3.3 Zeitliche Komposition

Die zeitliche (temporale) Komposition dient der Definition zeitlicher Beziehungen in multimedialen Anwendungen. Die Spezifizierung von zeitlichen Beziehungen erfordert eine einheitliche Behandlung von diskreten und kontinuierlichen Medientypen. Dies läßt sich realisieren, indem man den diskreten Medientypen die Zeitdifferenz als Präsentationsdauer zuordnet, die zwischen dem Ausgeben und dem Löschen einer Information vergeht. Damit kann die Dauer von diskreten und kontinuierlichen Ausgaben durch Zeitintervalle (Präsentationsintervalle) beschrieben werden. Präsentationsintervalle sind in der Regel zeitlich begrenzt. Sie können aber durchaus auch von unbestimmter Länge sein, wie sie bei einer Live-Quelle (z.B. Videokamera) vorkommen.

Zwischen zwei Intervallen können nach Allen 13 verschiedene Relationen bestehen. Sie werden auch Intervallrelationen genannt. Sieben davon sind in Abbilding 12.1 zu sehen. Alle anderen Relationen ergeben sich aus den inversen Relationen. Von der Relation ,,equals`` existiert keine Inverse.


  
Abbildung 12.1: Intervallrelationen
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb3_1.ab.eps}\end{center}
\end{figure}

Es sind nur einige Intervallrelationen für die temporale Komposition multimedialer Anwendungen notwendig, da die Relationen ,,before``, ,,during``, ,,finishes`` und ,,overlaps`` nur unscharfe Abhängigkeiten zwischen zwei Intervallen beschreiben. In multimedialen Anwendungen lassen sich die Datenströme im allgemeinen fest positionieren, so daß die Relationen ,,finishes``, ,,meets``, ,,starts`` und ,,equals`` ausreichen. Alle anderen Relationen können durch Einfügen eines Pause-Zeitintervalls simuliert werden.

Es existieren drei verschiedene Ansätze für die zeitliche Komposition von multimedialen Anwendungen:

12.1.2.3.3.1 Komposition auf einer Zeitachse

Bei diesem Ansatz werden die Ausgaben multimedialer Anwendungen relativ zu einer Zeitachse (engl.:timeline) angeordnet, welche die Präsentationszeit darstellt. Es müssen sowohl alle Start- und Endzeitpunkte als auch die Dauer aller Informationseinheiten bekannt sein. Die temporale Komposition auf einer Zeitachse ist eine absolute zeitliche Komposition.


  
Abbildung 12.2: Komposition auf einer Zeitachse
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb3_2.ab.eps} \end{center}
\end{figure}

12.1.2.3.3.2 Hierarchische Komposition

Die hierarchische Komposition modelliert die zeitlichen Beziehungen zwischen Präsentationsintervallen in Form einer Baumstruktur. Die Wurzel und die inneren Knoten bestimmen dabei die zeitliche Anordnung der Präsentationsintervalle untergeordneter Knoten über die Intervallrelationen. Die Blätter repräsentieren diskrete und kontinuierliche Ausgaben. Außerdem können in Blättern und äußeren Knoten Zeitintervalle zur Beschreibung zeitlicher Verzögerungen stehen. Die hierarchische Komposition ist eine relative zeitliche Komposition.


  
Abbildung 12.3: Hierarchische Komposition
\begin{figure}
\begin{center}\epsfxsize=10cm \epsfbox{./zeichnungen/nabb3_3.ab.eps} \end{center}
\end{figure}

12.1.2.3.3.3 Komposition über Referenzpunkte

Die Komposition über Referenzpunkte verwendet zur Definition zeitlicher Beziehungen beliebige Zeitpunkte (Synchronisationspunkte) der Präsentationsintervalle. Dabei wird eine Liste von gleichzeitig zu erreichenden Synchronisationspunkten (Referenzpunkte) der beteiligten Ausgaben definiert. Durch das Gleichsetzen von Referenzpunkten können die entsprechenden Datenströme zueinander in Beziehung gesetzt werden und damit die Intervallrelationen modelliert werden. Zum Beispiel wird durch das Gleichsetzen der Startzeitpunkte von zwei Ausgaben der gleichzeitige Beginn zweier Präsentation beschrieben. Die Komposition über Referenzpunkte stellt eine relative zeitliche Komposition dar.


  
Abbildung: Komposition über Referenzpunkte
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb3_4.ab.eps} \end{center}
\end{figure}

12.1.2.4 Mediensynchronisation

Während die zeitliche Komposition die Abhängigkeiten zeitlicher Beziehungen modelliert, setzt die Mediensynchronisation diese zur Laufzeit um. In multimedialen Anwendungen werden überwiegend sogenannte weiche Synchronisationsanforderungen gestellt. Sie erlauben geringe zeitliche Abweichungen, solange der Eindruck einer exakten Synchronisation erhalten bleibt.

12.1.2.4.1 Diskrete Synchronisation

Die diskrete Synchronisation muß die Verarbeitung einzelner LDU's bewältigen. Es muß gewährleistet werden, daß mit der Verarbeitung der (n+1)-ten LDU's der jeweiligen Datenströme erst dann begonnen werden kann, wenn alle n-ten LDU's bereits synchronisiert worden sind. Diese Anforderung kann entweder durch das Blockieren von Datenströmen oder durch das Überspringen von LDU's realisiert werden.

12.1.2.4.2 Kontinuierliche Synchronisation

Bei der kontinuierlichen Synchronisation werden die zu synchronisierenden Datenströme an die effektive Datenrate angepaßt. Die Anpassung findet in regelmäßigen Zeitabständen statt. Die kontinuierliche Synchronisation ist genau dann gewährleistet, wenn bei allen Datenströmen die effektive und die ideale Datenrate übereinstimmen. Ansonsten wird die Synchronisation entweder durch die Anpassung der zu langsamen Datenrate oder durch Verzögerung der Datenraten der anderen Datenströme garantiert. Die Anpassung einer Datenrate kann genau wie bei der diskreten Synchronisation durch das Überspringen von LDU's oder durch Blockieren realisiert werden.

Die Sychronisationsrate bestimmt, wie oft in der Sekunde die effektiven Datenraten verglichen und evtl. angepaßt werden.

12.1.3 Abstraktionsebenen

Es gibt verschiedene Möglichkeiten, um Medienobjekte in eine multimediale Anwendung zu integrieren. Die Ansätze unterscheiden sich jeweils durch den Abstraktionsgrad. In diesem Kapitel werden die Abstraktionsebenen beschrieben und Repräsentationsmöglichkeiten von Medienobjekten diskutiert. Eine Multimedia-Anwendung kann auf jede Ebene zugreifen. Es existieren die folgenden Abstraktionsebenen:


  
Abbildung 12.5: Abstraktionsebenen
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb4_1.ab.eps} \end{center}
\end{figure}

12.1.3.1 Geräteeinheiten als eigenständige Komponenten

Eine Geräteeinheit (engl.:device) kann als eigenständige Komponente im Rechner existieren. In diesem Fall ist sie nicht Bestandteil des Betriebssystems, sondern von allen Komponenten direkt ansprechbar.

Geräteeinheiten als eigenständige Komponenten weisen eine hohe Hardwareabhängigkeit auf, denn jede Geräteeinheit wird auf ganz individelle Weise angesprochen. Diese Vorgehensweise ist daher nicht zu empfehlen.

12.1.3.2 Abstraktionsebene Bibliotheken

Eine Bibliothek stellt eine medienobjektspezifische Menge von Funktionen (Multimedia-Funktionen) bereit und steuert das entspechende Medienobjekt. Die Funktionen können nicht nur von der Systemsoftwareebene aus, sondern auch aus einer Programmiersprache heraus aufgerufen werden.

Medienobjekte können schnell und einfach mittels Bibliotheken in eine Multimedia-Anwendung eingebunden werden. Medienobjekte mit gleicher Funktionalität weisen jedoch oft sehr unterschiedliche Schnittstellen auf. Damit ist auch dieser Ansatz nicht zu empfehlen. Desweiteren unterscheiden sich Bibliotheken in ihrem Abstraktionsniveau. Einige Bibliotheken kann man als Erweiterung von graphischen Benutzungsoberflächen ansehen, andere wiederum bestehen aus Steuerkommandos, die als Kontrollblöcke an die entsprechenden Treiber übergeben werden.

12.1.3.3 Abstraktionsebene Systemsoftware

Die Einbettung von Gerätetreibern in ein Betriebssystem ermöglicht die Integration von Multimedia-Funktionen in die Systemsoftware. Das bedeutet, daß die Verarbeitung von Datenströmen kontinuierlicher Medien von der Systemsoftware übernommen wird. Microsoft Windows ist ein Beispiel für ein Betriebssystem, welches die Möglichkeit bietet, Multimedia-Daten zu verarbeiten. Die Realisierung erfolgt dabei über das sogenannte Media Control Interface.

Die Einbettung von Multimedia-Funktionen in die Systemsoftware ist ein vielversprechender Ansatz, der eine weitgehende Hardwareunabhängigkeit verspricht. Jedoch existiert das Problem, daß es keinen Standard gibt, der festlegt, welche Multimedia-Funktionen in das Multimedia-Betriebssystem zu integrieren sind.

12.1.3.4 Abstraktionsebene Höhere prozedurale Progammiersprachen

Medienobjekte können innerhalb einer Programmiersprache auf unterschiedliche Weise modelliert werden. Die verschiedenen Ansätze werden nachfolgend untersucht:

12.1.3.4.1 Medien als Datentypen

Diese Betrachtungsweise erfordert eine Definition von Datentypen für Video und Audio. Hierfür müssen Funktionen und Operatoren bereitgestellt werden, die auf LDU's angewendet werden können. Ein wichtiger Aspekt stellt die Wahl der Granularität dar. Die Granularität charakterisiert die Komplexität einer LDU.

Steinmetz gibt folgende Richtlinien zur Wahl von Granularitäten an [Ste93c]:

Text Bei Textausgaben sollte ein einzelnes Zeichen die kleinste adressierbare Einheit darstellen.

Audio Für Audioausgaben gilt, daß ungefähr 75 mal in der Sekunde auf die Audioblöcke zugegriffen werden sollte. Ein Audioblock ist eine Menge von Audioabtastwerten.

Video Bei einer Videoseqenz sollte man minimal auf ein Einzelbild und maximal auf eine Sequenz von zwei Sekunden zurückgreifen können.

12.1.3.4.2 Medien als Dateien

In diesem Ansatz werden die Datenströme der Medienobjekte als Dateien aufgefaßt.

Beispiel:

file_h1 = open (Audio_1, ...)
file_h2 = open (Audio_2, ...)
...
read (file_h1)
read (file_h2)
gemischte_Files = mix (file_h1,file_h2)
activate (gemischte_Files)
...
deactivate(file_h1,file_h2)
...
close (file_h1)
close (file_h2)

Dieses Programm mischt zwei Audio-Datenströme. Jede physikalische Datei erhält einen Bezeichner. Die Funktionen ,,activate`` und ,,deactivate`` realisieren den Start bzw. Stop des Datenflusses. Eine Besonderheit ist, daß sämtliche Lese- und Schreibfunktionen kontinuierliche Daten verarbeiten müssen.

Es sollte zusätzlich eine Such-Funktion bereitgestellt werden, die als Argument eine Positionsangabe eines Datenstromes verlangt und als Resultat auf die entsprechende LDU verweist. Eine solche Such-Funktion wird benötigt, wenn man z.B. eine Videoausgabe nicht von Anfang an sehen möchte.

12.1.3.4.3 Medien als Prozesse

Man kann Datenströme auch als Prozesse auffassen, die für eine gewisse Zeitspanne Medienobjekte auf eine bestimmte Art und Weise miteinander verbinden. Innerhalb eines Prozesses können Multimedia-Funktionen spezifiziert werden. Bei Aufruf eines Prozesses erfolgt dessen Identifikation und die verwendeten physikalischen Geräteinheiten werden reserviert. Da verschiedene Prozesse möglicherweise gleiche Geräte benutzen wollen, müssen diese untereinander kommunizieren können. Dies wird über Prozeßinterkommunikations-Mechanismen realisiert.

12.1.3.4.4 Bewertung

Unter gewissen Voraussetzungen sind höhere prozedurale Programmiersprachen in der Lage, Multimedia-Daten effektiv zu verarbeiten. Sie müssen z.B. die Möglichkeit bieten, Daten parallel zu verarbeiten. Damit die bereitgestellten Multimedia-Funktionen weitgehend treiber- und hardwareunabhängig sind, sollten sie sich auf die von der Systemsoftwareebene bereitgestellten Funktionen abstützen. Da die Entwicklung von Multimedia-Betriebssystemen erst am Anfang steht, bleibt oft nur die Möglichkeit, sich auf Funktionen von Bibliotheken zu beziehen. Aufgrund der Vielfalt der Bibliotheken impliziert auch dieser Ansatz Hardwareabhängigkeit.

12.1.3.5 Abstraktionsebene Objektorientierte Programmierung

Auch in der objektorientierten Abstraktionsebene gibt es unterschiedliche Betrachtungsweisen. Sie unterscheiden sich jeweils im Aufbau der Klassenhierarchie.

12.1.3.5.1 Anwendungsspezifische Klassen

Bei dieser Abstraktionsweise wird für jede Anwendung eine spezielle Klassenhierarchie entwickelt. Daraus resultiert, daß bei der Entwicklung einer Anwendung keine bereits existierenden Klassenhierarchien beachtet werden müssen.

Dieser Ansatz impliziert eine Vielzahl von Klassenhierachien. Gemeinsamkeiten von allgemeinen Anwendungen werden nicht untersucht. Es ist jedoch oft so, daß ähnliche Anwendungen zu ähnlichen Klassenhierachien führen. Der Aspekt der Wiederverwendung wird in diesem Ansatz also völlig vernachlässigt, obwohl die Wiederverwendung von objektorientierten Programmiersprachen durch das Klassenkonzept stark unterstützt wird. Aufgrund dessen sollte dieser Betrachtungsweise nicht weiter Beachtung geschenkt werden.

12.1.3.5.2 Funktionalitätsspezifische Klassen

Dieser Ansatz verfolgt das Ziel, allgemeine Funktionen und Eigenschaften allgemeiner Anwendungen zu finden und in Klassen umzusetzen. In diesen Klassen können z.B. Basisfunktionen implementiert werden, die von jedem Medienobjekt benötigt werden.

Da nur wenige Funktionen (Basisfunktionen) existieren, die auf alle Medienobjekte anwendbar sind, ist dieser Ansatz ungeeignet.

12.1.3.5.3 Geräteklassen

Um physikalische Geräte in einer objektorientierten Programmiersprache zu modellieren, müssen Klassen definiert werden, deren Objekte die Verhaltensweisen und die Schnittstellen von Geräten repräsentieren können. Die bereitgestellten Methoden müssen dabei mit verschiedenen Geräten kommunizieren und sollten geräteunabhängig implementiert sein. Zum Beispiel sollte eine Methode play sowohl für Video- als auch für Audiodaten abgespielt werden können.

Für diese Abstraktion muß eine allgemeingültige Schnittstelle für ähnliche Audio-, Video-, Eingabe- und Ausgabeeinheiten gefunden werden. Die Lösung dieses Problems ist schwierig.

12.1.3.5.4 Komponentenklassen

Die Komponentenklassen differenzieren zwischen reinen Quellen-, reinen Senken- und kombinierten Quellen-Senken-Objekten. Bestimmte Medienobjekte können kontinuierliche Datenströme verarbeiten. Bevor diese miteinander kommunizieren können, muß eine Verbindung hergestellt werden. Dabei werden Ausgänge von Objekten mit Eingängen anderer Objekte verbunden. Dies kann entweder direkt oder über sogenannte Kanalobjekte [Kapitel 12.1.4] realisiert werden.

12.1.3.5.5 Medienklassen

Der Aufbau einer Klassenhierachie kann auch über die Betrachtung von charakteristischen Merkmalen von Medien erfolgen. Dabei kann man z.B. nach akustischen und optischen Medien oder nach kontinuierlichen und diskreten Medien klassifizieren.

12.1.3.5.6 Kommunikationsklassen

Dieser Ansatz wird oftmals auf verteilte Umgebungen angewendet. Die Klassenhierarchie unterscheidet zwischen Informations-, Präsentations- und Transportklassen. Dabei beinhalten Informationsobjekte logischerweise Informationen. Präsentationsobjekte stellen Methoden für die Darstellung der Information zur Verfügung, und Transportobjekte dienen der Übertragung der Information. Die Objekte können in andere Objektarten transformiert werden.

12.1.3.5.7 Bewertung

Durch die Verwendung von objektorientierten Ansätzen stehen Konzepte zur Verfügung, die es erlauben, multimediale Anwendungen effizient zu programmieren. Die multimediale Anwendung kann intern sowohl über Bibliotheken, als auch über die Systemsoftware-Schnittstelle ausgeführt bzw. gesteuert werden. Jedoch tritt bei der Benutzung von Bibliotheksfunktionen wieder das Problem der Hardwareabhängigkeit auf. Desweiteren besteht keine Einigkeit darüber, welche Klassenhierarchie am besten geeignet ist. Steinmetz empfiehlt jedoch eine Kombination von Medien- und Komponentenklassen [Ste93c].

   
12.1.4 Objektorientierte Multimedia-Programmierung

In diesem Kapitel werden die grundlegenden Begriffe der objektorietierten Multimedia-Programmierung erläutert.

12.1.4.1 Multimedia-Objekte

Ein Multimedia-Objekt kann ein konkretes Medium repräsentieren, welches Daten in einer bestimmten Datenrate eines bestimmten Typs produziert und/oder konsumiert. Da ein Multimedia-Objekt aus weiteren Objekten bestehen kann, kann eine multimediale Anwendung aus objektorientierter Sicht als Multimedia-Objekt betrachtet werden. Wenn ein Multimedia-Objekt weitere Objekte enthält, so wird es als kombiniertes Multimedia-Objekt (engl.:Compound Multimedia Objekt, CMO) bezeichnet. Ansonsten handelt es sich dabei um ein Basis-Multimedia-Objekt (Basic Multimedia Object, BMO). BMO's können z.B. Daten von einem Mikrofon, gespeicherte Audiosequenzen aus einer Datei oder auszugebende Daten für einen Lautsprecher sein. BMO's sind Instanzen von Basis-Multimedia-Klassen (engl.:Basic Multimedia Classes, BMC's) und CMOs sind Instanzen kombinierter Multimedia-Klassen (engl.:Compound Multimedia Classes, CMC's). Durch eine CMC wird eine Klassenhierachie beschrieben, die somit mehrere Medienobjekte, inklusive der dazugehörigen Funktionen, repräsentieren kann. Die Abbildung 12.6 zeigt eine CMO, die zwischen Komponenten unterscheidet:


  
Abbildung 12.6: Ein kombiniertes Multimedia-Objekt
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb5_1.ab.eps} \end{center}
\end{figure}

12.1.4.2 Methoden

Jedes BMO verfügt über die von der zugehörigen Klasse bereitgestellten Methoden. Typische Methoden, die auf die meisten BMO's angewendet werden können, sind z.B. play und stop. Sehr spezielle Methoden sind z.B. zoom und focus für eine Videokamera. Multimedia-Objekte, die kontinuierliche Daten verarbeiten, ändern ihren inneren Zustand ständig. Daher müssen Methoden oftmals kontinuierliche Daten verarbeiten. Außerdem müssen Methoden definiert werden, die zeitabhängig sind, wie z.B. ,,Blende Text fünf Sekunden ein``.

12.1.4.3 Ereignisverarbeitung

Eine Ereignisverarbeitung wird vom Objekt benötigt, um andere Objekte über den eigenen Zustand zu informieren. Ein Ereignis kann z.B. das Ende einer Videosequenz signalisieren. In der Ereignisverarbeitung wird die Wechselwirkung zwischen dem Ereignis und dem jeweiligen BMO spezifiziert. Zum Beispiel könnte das Ende einer Video-Sequenz die Versendung einer Nachricht an die Oberklasse bewirken. Die Oberklasse könnte dann den Abbruch des dazugehörigen Tons durch die Versendung einer Nachricht an die entsprechende Unterklasse veranlassen. In jeder BMO ist eine solche Ereignisverarbeitung integriert. Eine mit einem kontinuierlichen Datenstrom verbundene BMO besitzt daher eine eigene Zeitskala und eigene Ereignisse. Außerdem müssen Synchronisationsmethoden in der BMO enthalten sein.

12.1.4.4 Zugriffspunkte

Da ein Datenstrom von mehreren Objekten hintereinander verarbeitet werden kann, müssen die entsprechenden BMO's miteinander verbunden werden können. Aus diesem Grund besitzen BMO's ein oder mehrere Zugriffspunkte. BMO's besitzen alle quellen- und senkenspezifische Informationen, um die Verbindungen aufzubauen. Diese Informationen bestehen aus der Adresse und der verwendeten Datenkodierung.

12.1.4.5 Kanalobjekte

Ein Kanalobjekt steuert den Datenfluß zwischen zwei oder mehreren Objekten untereinander, d.h. es ist in der Lage m-zu-n Verbindungen aufzubauen. Ein Kanalobjekt enthält dabei kommunikationsunterstützende Methoden, wie z.B. Methoden zur Vergabe von Kanal-Zugriffsrechten. Kanalobjekte bieten dabei die Möglichkeit, Verbindungen zwischen Multimedia-Objekten dynamisch zu verändern. Daher werden Methoden wie ,,setze Verbindung`` und ,,löse Verbindung`` bereitgestellt.

  
12.1.5 Das XFantasy-UIT

Während im letzten Kapitel die internen Komponenten einer multimedialen Anwendung angesprochen wurden, beschäftigt sich dieses Kapitel mit der Realisierung von multimedialen Benutzerschnittstellen mittels eines User-Interface-Toolkits.

Das XFantasy-UIT ist ein objektorientiertes User-Interface-Toolkit [Gö94]. Es setzt auf dem X-Window System auf und wurde in C++ implementiert. Es dient der Entwicklung interaktiver, multimedialer Benutzerschnittstellen und unterstützt damit auch die Entwicklung multimedialer Anwendungen. Es besteht aus fünf Komponenten, die in eine Klassenhierarchie integriert sind:


  
Abbildung 12.7: Das XFantasy-UIT
\begin{figure}
\begin{center}\epsfxsize=11cm \epsfbox{./zeichnungen/nabb6_1.ab.eps} \end{center}
\end{figure}

12.1.5.1 Ein- und Ausgabeklassen

Die Eingabeklassen kapseln den Zugriff auf die Geräteeinheiten des Window-Systems und leiten Eingabe-Events an die Eventerkennung weiter. Die Ausgabeklassen sind für die Ausgabe von Daten zuständig, die über die Medienklassen-Schnittstelle gesendet werden. Damit abstrahieren die Ein- und Ausgabeklassen vom zugrundeliegenden Window-Systems und dienen somit der Portabilität des XFantasy-UIT.

12.1.5.2 Klassen für die Erkennung und Propagierung von Events

Ein Event wird durch Benutzereingaben erzeugt. Benutzereingaben können z.B. Mausbewegungen und Tatastureingaben sein. Die Realisierung von Events erfolgt über ereignissensitive Objekte. Sie sind fähig, Events zu erkennen und Interessenten über einen Event-Eintritt zu informieren.

Die objektorientierte Geräteschnittstelle ist für die Erkennung und Propagierung von Events verantwortlich. Sie umfaßt Device-Objekte für die vom Window-System erzeugten Events. Es existieren folgende Device-Objekte:

Die Eventerkennung wird über den Dispatcher gesteuert. Dieser informiert die Device-Objekte über die für sie relevanten Events, die vom Window-System oder von der Applikation geschickt werden. Desweiteren ist ein Scheduler integriert, der die Steuerung des Dialogprozesses und der Ausgabeprozesse übernimmt.

12.1.5.3 Eventbehandlung

Es wird zwischen einfachen und komplexen Events unterschieden. Komplexe Events setzen sich aus mehreren einfachen Events zusammen. Das Verschieben eines Fensters stellt ein Beispiel für ein komplexes Event dar.

Die Klassen der Eventbehandlung unterstützen die Definition und Steuerung des Verhaltens einer Anwendung beim Auftreten von einfachen und komplexen Events.

12.1.5.4 User-Interface-Klassen

User-Interface-Klassen defininieren das Aussehen und das Dialogablaufverhalten vordefinierter Interaktionskomponenten, wie z.B. Buttons, Scrollbars, Menüs oder Dialogboxen.

12.1.5.5 Medienklassen

Mittels der Hierarchie von Medienklassen läßt sich die Verarbeitung diskreter und kontinuierlicher Medientypen, die Medienobjekte (Quellen, Filter, Senken) sowie die zeitliche und konfigurelle Komposition realisieren. Die zeitliche Komposition wird hierarchisch definiert.

12.1.6 Autorensystemsprachen

Eine Autorensystemsprache ist ein Bestandteil eines Autorensystems. Es unterstützt die direkte Implementierung von multimedialen Anwendungen.

12.1.6.1 Hypertalk

Hypertalk ist die Programmiersprache (Skriptsprache) des Autorensystems HyperCard . Es realisiert die Kommunikation mit den HyperCard-Objekten Stapel (engl.:stack), Hintergründe (engl.:background), Karten (engl.:cards), Texteingabefelder (engl.:fields) und Knöpfen (engl.:buttons). Objekte können Nachrichten senden und empfangen. Die Konzepte zur Verwirklichung der Kommunikation werden in diesem Kapitel kurz beschrieben.

12.1.6.1.1 Skripte

Jedem Objekt ist ein sogenanntes Skript (engl.:script) zugeordnet. Das Skript spezifiziert dabei die Art und Weise, wie ein Objekt auf spezielle Nachrichten reagiert. Es besteht aus einer beliebigen Anzahl von Routinen (engl.:handlers), die Hypertalk-Anweisungen beinhalten. Eine Routine eines Objektes wird dann ausgeführt, wenn das Objekt eine Nachricht empfängt [Abbildung 12.8]. Es gibt zwei Arten von Routinen. Nachrichtenroutinen (engl.:message handlers) beschreiben das Verhalten eines Objektes beim Empfang einer Nachricht. Funktionsroutinen (engl.:function handlers) hingegen beinhalten Funktionen, die von anderen Objekten aufgerufen werden können.

Beispiel einer Nachrichtenroutine für das Button-Objekt ,,Nächste Karte``:

on mouseUp
    go to next card
end mouseUp

Wenn sich der Mauszeiger über dem Button ,,Nächste Karte`` befindet und der Mausknopf losgelassen wird, so erfolgt die Ausführung der Anweisung ,,go to next card``.

12.1.6.1.2 Versendung von Nachrichten

Es gibt vier Möglichkeiten, um Nachrichten an HyperCard-Objekte zu übermitteln:

12.1.6.1.3 Objekthierachie

Die HyperCard-Objekte sind in einer Objekt-Hierarchie angeordnet. Sie bestimmt den Nachrichtenverlauf. Nachrichten werden nicht direkt adressiert, sondern durchlaufen die Objekthierarchie. Abbildung 12.8 zeigt neben der Objekthierachie noch die Interaktionsmöglichkeiten mit den HyperCard-Objekten.


  
Abbildung 12.8: Objekthierarchie
\begin{figure}
\begin{center}\epsfxsize=15cm \epsfbox{./zeichnungen/nabb7_1.ab.eps} \end{center}
\end{figure}

12.1.6.2 Lingo

Lingo ist die Programmiersprache des Autorenwerkzeugs MacroMindDirector . Sie ist HyperTalk sehr ähnlich, aber um einige Konzepte erweitert worden.

MacroMindDirector sieht multimediale Präsentationsanwendungen als Filme an. Ein Film besteht aus einer Menge von einfachen Szenen, die sich wiederum aus einer Reihe von Einzelbildern ergeben. Ein oder mehrere Darsteller konstruieren ein Bild. Ein Darsteller ist dabei durch eine individuelle Graphik charakterisiert. Der gesamte Filmverlauf spiegelt sich in einer Gitterstruktur wieder. Jede Zelle repräsentiert dabei einen Darsteller. Sie enthält darüberhinaus noch weitere Informationen, wie z.B. die Position des Darstellers. Eine Spalte stellt ein einzelnes Gesamtbild dar.

12.1.6.2.1 Skripte

In Analogie zu HyperCard spezifizieren Skripte in Lingo, wie sich Objekte auf spezielle Nachrichten verhalten sollen. Es existieren verschiedene Arten von Skripten. Ein Film-Skript definiert das Verhalten, wenn ein Film beginnt, endet oder pausiert. Einer einzelnen Zelle können Regie-Skripte zugewiesen werden. Bei Erreichen der Spalte, in der sich die Zelle befindet, wird das entsprechende Regie-Skript ausgeführt. Desweiteren gibt es Darsteller-Skripte. Ein Darsteller-Skript ist genau einem Darsteller zugeordnet. Es wird evaluiert, sobald sich die Maus über dem Darsteller befindet und zusätzlich die Maustaste betätigt wird. Ereignis-Skripte werden beim Drücken einer Maustaste oder bei Benutzung der Tastatur ausgeführt, sofern die Interaktionen nicht über einen Darsteller stattfinden. Außerdem können Ereignis-Skripte aktiviert werden, wenn eine Zeitspanne überschritten wird, in der keine Benutzerinteraktionen erfolgen.

12.1.6.2.2 Klassen

Klassen, in Lingo Fabriken (engl.:factories) genannt, dienen der Erzeugung von gleichartigen Objekten. Diese Objekte besitzen zwar alle die gleichen Attribute, können sich jedoch völlig unabhängig voneinander verhalten. Eine Fabrik könnte z.B. zur Generierung eines Bienenschwarms benutzt werden, wobei die Bienen verschiedene ,,Flugmanöver`` ausführen können. Eine oder mehrere bestimmte Bienen könnten dabei ein ,,Looping`` fliegen, wenn eine Methode ,,fliege Looping`` existiert. Fabriken stellen ein objektorientiertes Konzept dar. Weitere objektorientierte Konzepte wie Vererbung oder Polymorphie werden von Lingo nicht unterstützt.

12.1.6.3 Apple Media Tool Programming Environment (AMTPE)

AMTPE ist eine Komponente des Apple Media Kits. Es besteht aus der Apple Media Language und dem Apple Media Language Framework. AMTPE stellt eine objektorientierte Programmierumgebung bereit, die von Eiffel und Pascal geprägt ist. Sie generiert maschinenunabhängigen Byte-Code, so daß Applikationen sowohl unter MacOS, als auch unter MS-Windows laufen.

12.1.6.3.1 Grundlagen der Apple Media Language

AMTPE verwendet recht unübliche Bezeichnungen. So werden Oberklassen als Eltern, Unterklassen als Kinder und Instanzvariablen als Felder bezeichnet.

Eine Klasse ist ein Datentyp und ist durch Felder, Methoden und der Beziehung zu ihren Eltern charakterisiert ist. Die Bezeichnung des Datentyps entspricht dem Namen der Klasse. Eine Klasse kann ein Kind von mehreren Eltern sein, d.h. die Mehrfachverbung ist möglich. Es existieren keine Basistypen, aus denen komplexe Typen konstruiert werden können. Alles wird als Objekt aufgefaßt. Zum Beispiel ist ein Zeichen ein CHARACTER-Objekt und eine ganze Zahl ein INTEGER-Objekt. Objekte sind in AMTPE, wie in anderen objektorientierten Programmiersprachen auch, Instanzen von Klassen. Eine Besonderheit stellt jedoch die Möglichkeit dar, für einzelne Objekte weitere Felder und Methoden zu definieren, zusätzlich zu jenen, die bereits von der Klasse bereitgestellt werden. Ein Objekt, wie z.B. ein Feld, kann außerdem andere Objekte enthalten. Außerdem können Methoden und Operatoren im Gegensatz zu Feldern überladen werden.

In AMTPE ist ein Garbage Collector integriert, der die Speicherbereinigung übernimmt. Eine Ausnahmebehandlung wird ebenfalls unterstützt. Hinzu kommt, daß AMTPE einen eigenen Heap-Speicher verwaltet, in dem Objekte gespeichert werden können. Heap-Allokationen sind dabei genauso schnell wie Stack-Allokationen.

12.1.6.3.2 Grundlagen des Apple Media Language Framework

12.1.6.3.2.1 ,,Class Hierachy``

Die ,,Class Hierachy`` stellt Systemklassen für die konkreten Anwendungen bereit.

Basis-Objekte

Das Apple Media Language Framework setzt sich aus folgenden Basisobjekten zusammen:

Medienobjekte

Folgende Medienobjekte werden unterstützt:

12.1.6.3.2.2 ,,Containment Hierachy``

Die ,,Containment Hierachy`` repräsentiert die Basisobjekte in einer Anwendung. Sie ist für die Delegation und Verteilung der Nachrichten zuständig. Jedes Objekt verarbeitet die ihr zugesandte Nachricht und reicht diese dann an das entsprechende Objekt in der ,,Containment Hierachy`` nach unten weiter.


  
Abbildung 12.9: Die Containment-Hierachy
\begin{figure}
\begin{center}\epsfxsize=10cm \epsfbox{./zeichnungen/nabb7_2.ab.eps} \end{center}
\end{figure}

Ziele und Container

Ziele (engl.:target) beschreiben Adressen von Objekten. Dazu besitzt jedes Objekt ein Feld, das auf den Adressaten verweist. Wenn ein Objekt in die Hierachie installiert wird, wird im entsprechenden Container der Absender eingetragen, der für das Senden von Nachrichten verantwortlich ist.

Domänen

Die Klassen der ,,Containment Hierachy`` trennen die Ereignis- und Nachrichtenbehandlung in die vier Bereiche Ereignisse (engl.:events), Zeit (engl.:time), Sichten (engl.:views) und Medien (engl.:media) auf:


next up previous contents
Next: 12.2 Autorensysteme Up: 12. Entwicklungsumgebungen Previous: 12. Entwicklungsumgebungen
Dietrich Boles
1998-12-23