64 Konzepte und Strukturen eines interaktiven Notenmoduls die vertikale Zuordnung der Akkordgruppen erst nach einer Code-Analyse. Diese soll nun im folgenden Abschnitt einer genaueren Betrachtung unterzogen werden. 3.1.1 Der Parser und die interne Notenbildrepräsentation Für die Erkennung der lexikalischen Code-Elemente sowie den Aufbau der mo-dulinternen Notenrepräsentation ist der Parser zuständig. Er liest die einzelnen Zeichen des Eingabecodes ein, setzt sie gemäß vorgegebener Grammatik zu syn-taktischen Einheiten zusammen und generiert daraus schließlich die verschiedenen Notationsobjekte. Diesem Unterprogramm des Notenmoduls kommt besondere Be-deutung zu, da es unmittelbar die Eingaben des menschlichen Bedieners verarbei-tet und zwangsläufig mit syntaktisch und semantisch fehlerhaften Zeichenfolgen rechnen muß. Dem Parser obliegt somit zusätzlich die Aufgabe, diese Fehler zu er-kennen und sie dem Autoren auf Wunsch mitzuteilen. In jedem Fall sollte aber die ungeprüfte Notenbildgenerierung aus einem fehlerhaften Eingabeskript vermieden werden, da dies zu schwer vorhersagbaren Resultaten, im schlimmsten Fall zum Programmabsturz, führen kann. Dank der beiden Programmierwerkzeuge lex und yacc bzw. deren Derivate flex und bison ist es nicht notwendig, den Parser »von Hand« zu programmieren. Es genügt, die Code-Grammatik in der sogenannten Backus-Naur-Form zu beschreiben und jede Regel gemäß gewünschter Semantik mit einem Code-Fragment zu versehen. Der Compiler-Compiler yacc erzeugt dar-aus anschließend den C-Quelltext eines robusten Parsers, welcher nun in das Modul integriert werden kann. Der auf diese Weise relativ gering gehaltene Programmier-aufwand ermöglicht neben der leichten Modifizierbarkeit zusätzlich den Austausch des gesamten Parsers, um etwa andere, Notengraphik beschreibende Eingabecodes verwenden zu können. Was geschieht aber genau, wenn der Parser ein Code-Element erkannt hat? Es wurde bereits erwähnt, daß der Parser die modulinterne Repräsentation des No-tenbildes aufbaut und dazu Notationsobjekte erzeugt. Der experimentelle Noten-generator GIN wurde in C++, einer objektorientierten Programmiersprache, ent-wickelt. Mit ihrer Hilfe ist es durch Vererbung von Eigenschaften und Methoden möglich, eine Hierarchie aus auseinander hervorgehenden Objekten aufzubauen. Bei der Notenschrift bietet sich diese Vorgehensweise geradezu an, da ihre logischen Be-standteile ähnliche Eigenschaften besitzen. Abbildung 3.1 zeigt die Hierarchie der Notationselementklassen, die auf dieser Grundlage realisiert wurde. Die abstrakte Basisklasse GinObject vereinigt diejenigen Parameter, die Bestandteil sämtlicher untergeordneter Klassen sind, wie z.B. Farbe, Position und Größe. Durch einma-lige Ableitung wurden nun die vier Klassentypen Page, System, Staff und Symbol modelliert. Im Rahmen von Lernprogrammen kann im Gegensatz zu Notendrucksy-stemen auf die Verwaltung mehrerer Notenseiten verzichtet werden, da die Graphik in erster Linie zur Bildschirmdarstellung und weniger als Druckvorlage genutzt werden soll. Jede Partitur besteht deshalb aus lediglich einer zusammenhängen-den Seite, welche durch die Klasse Page repräsentiert wird. Sie beschreibt einen rechteckigen Bereich, in dem alle Notationselemente angeordnet werden und des-sen Größe der Modulbenutzer mittels Funktionsparametern festlegen kann. Ist die Seite kleiner als die darauf darzustellende Graphik, verschwinden gegebenenfalls