1. ALLGEMEINES

Nach langen Überlegungen habe ich mich entschlossen, dieses Kapitel gleich zu Begin anzubringen. Es beschreibt die Bewegründe, warum die einzelnen Programmteile und Konzepte so geworden sind, wie sie sind. Ich mache das nicht, um mich für meine Arbeiten zu rechtfertigen, sondern denke, daß das Verständnis für das Warum auch das Verstehen des Wie fördert. Teilweise will ich auch versuchen, das historische Wachstum des Programms etwas zu durchleuchten.

Das Lesen dieses Kapitels ist nicht zwingend erforderlich. Es wird in den nachfolgenden Kapiteln kein Wissen vorausgesetzt, das hier vermittelt wird. Vielleicht ist es auch interessant, es erst zu lesen oder noch einmal zu lesen, wenn man mit dem System bereits vertraut ist.

Wenn man vor der Entscheidung steht, ob man das MAL-System einsetzen soll, so werden die hier erläuterten Konzepte sicher hilfreich sein, da sie einen guten Überblick über die Möglichkeiten und Grenzen, die Stärken und Schwächen des Systems bieten.

2. ENTSTEHUNGSGESCHICHTE

Die Enstehung der einzelnen Programmteile ist natürlich nicht streng chronologisch zu ordnen. Viele Teile wurden immer wieder überarbeitet. Dennoch mag die Kenntnis der Entstehungsreihenfolge auch hilfreich beim Einarbeiten in das System sein.

Ursprünglich wurde ein befehlsgesteuertes Zeichenprogramm für einen Plotter entwickelt. Das heißt, die Grapik stellt nebst dem Interpreter den ältesten Teil des Systems dar. Für das Skalieren und Vorverarbeiten der Meßdaten waren zumindest einfache mathematische Routinen erforderlich.

Vor der Einbindung statistischer Routinen wurde das noch heute verwendete Datenformat entwickelt, das aufgrund seiner universellen und doch einfachen Struktur ein wesentliches Standbein von MAL darstellt. Zu jener Datenstruktur gehören auch etwa ein Dutzend Befehle zur Handhabung von Datensätzen.

Die erste voll unterstützte Schnittstelle für einen A/D-Wandler war für den Betrieb einer (eigens für die damals noch seltenen Labtop Computer gebauten) Einschubkarte, und wurde als Auftragsarbeit für die Firma LB-Elektronics entwickelt. Dabei entstand das heute noch verwendete Verfahren mit einem Datei-Ringpuffer mit frei definierbaren Triggermöglichkeiten. Bei dieser Gelegenheit wurden auch die ersten Elemente für das Design von Bedienoberflächen eingebaut, nämlich Menüs und Masken. Nebstbei enstand die erste vollständige MAL-Beschreibung.

Im nächsten Schritt wurde ein kleines Datenbanksystem für die Archivierung von Meßdaten eingebaut, das aber mit dem heute verwendeten nur noch das äußere Erscheinungsbild gemeinsam hat.

Nach dem Einbau von Meßroutinen für das A/D-Wandlerboard DT2801 (Data Translation) wurde das System zuerst in der Ganganalyse der Reumasonderkrankenanstalt Baden und später in der Ganganalyse des RZ-Tobelbad installiert.

Dann wurden Befehle und ein Archivierungssystem für die Handhabung von Datensätzen des Systems EMED (Druckverteilungsbilder) eingebaut.

Nach einer längeren Pause wurde dann eine komplette Neuprogrammierung, ausgelöst durch die Anschaffung einer neuen Workstation im RZ-Weißer Hof, begonnen. Bei dieser Gelegenheit wurde das ursprünglich in Pascal implementierte, nur unter MS-DOS lauffähige System in portierfähiger Weise in C++ programmiert.

Als neue Elemente kamen hinzu: das Poolsystem (ein System für die Datenarchivierung), darauf aufbauend die Folder (ein tabellenorientiertes Speicherkonzept) sowie die Metaschnittstelle (eine Schnittstelle für den Datenaustausch zwischen verschiedenen Hardware-Plattformen).

Anschließend wurde ein auf den neuen Speicherungsmöglichkeiten basierendes Meßdatenerfassungs- und -archivierungssystem entwickelt.

In Zuge einer Neuüberarbeitung des bis dahin noch nicht ganz ausgereiften Pool- und Foldersystems wurde eine logbook-basierende Versionsverwaltung, für die Unterstützung der Zusammenarbeit mehrerer Entwickler, eingebaut.

In der Folge habe ich das MAL-System für verschiedenste Projekte außerhalb der Bewegungsanalyse eingesetzt. Für die Bewegungsanalyse sind manche der Entwicklungen aber trotzdem von Bedeutung.

Die stereoskopische 3d-Darstellung und die dazugehörigen Bearbeitungsmöglchkeiten von 3d-Objekten wurden für das Projekt ´Computergestützte Herstellung von Prothesenschäften´ für das Forschungsinstitut für Orthopädietechnik entwickelt. Als Nebenprodukt wurden auch die Animationen auf dreidimensional umgebaut und mit einer vergleichbaren Handhabungsstruktur versehen.

Für das Projekt "Photogrammetric Headshape Digitizer" das in Zusammenarbeit mit der Österreichischen Akademie der Wissenschaften für das Institut für Psychologie der Universität Wien durchgeführt wurde, sind einige fotogrammetrische Funktionen (Kamerakalibrierung, Linsenentzerrung usw.) dazu gekommen, sowie ein System für Computer-Aided-Design von Polyedern.

Die graphische Bedienoberfläche für Windows und die Teile für das Objektorientierte Programmieren sind in einer längeren Projektpause entstanden.

Danach wurden wieder einige bewegungsanalytisch relevante Teile auf der Veterinärmedizinischen Universität entwickelt. Von allgemeinem Interesse sind davon eine objektorientierte Datenbank für die Archivierung von Bewegungsdaten, einige Klassen für die Handhabung von 3d Daten, Schnittstellen für das Einlesen von Daten von Fremdsystemen (Motion-Analysis und Vicon), sowie Treiber für verschiedene A/D-Wandler.

Die klinischen Befunde sowie das Datensammelsystem wurde für das NRZ-Rosenhügel entwickelt.

Schließlich hatte ich Ende 2005 durch einen längerne Krankenstand die Möglichkeit, die in der Zwischenzeit etwas veraltete Graphik auf den neuesten Stand der Technik zu bringen.

3. DIE SPRACHE

Zu der Zeit als ich mit der Entwicklung des ersten MAL-Sprachinterpreters begonnen habe, war ich mit den folgenden Programmiersprachen gut vertraut: Assembler (Siemens AS30), Pascal und Trick (eine Siemens-interne Eigenentwicklung). Weniger vertraut, aber doch von Zeit zu Zeit gezwungen damit zu arbeiten, war ich mit Basic oder Fortran.

Selbstverständlich habe ich versucht, bei der Entwicklung von MAL die Vorzüge der mir bekannten Sprachen zu berücksichtigen. Obwohl ich damals noch nicht mit objektorientierter Programmierung vertraut war (mit C++ habe ich erst bei der letzten Überarbeitung des Systems zu arbeiten begonnen) mögen manche Lösungsansätze durchaus objektorientiert erscheinen. Vom ursprünglichen Konzept her ist MAL jedenfalls eine prozedurale Sprache, die im nachhinein um objektorientierte Teile erweitert wurde.

Den entscheidenden Anstoß für die Entwicklung einer eigenen Programmiersprache gab das Studium eines Buches über die Sprache Forth. Mich hat in erster Linie fasziniert, wie diese Sprache mit ganz wenigen Sprachelementen die in anderen Sprachen üblichen vielfältigen syntaktischen Varianten realisiert. Vereinfachung und Vereinheitlichung ist mir stets ein zentrales Anliegen gewesen.

Gleichzeitig hat Forth den Vorteil, daß es (vor allem aufgrund der einfachen Syntax) besonders leicht ist, einen entsprechenden Interpreter zu entwickeln.

Zufällig hatte ich auch die Gelegenheit das Meßdatenanalyse-System Asyst einige Zeit für Testzwecke zur Verfügung zu haben. Es basiert auch auf der Forth-Syntax und ist in diesem Punkt dem MAL-System verwandt.

3.1. Umgekehrt Polnische Notation

MAL ist eine stackorientierte Sprache. Das bedeutet, der Datenaustausch zwischen den einzelnen Befehlen, Prozeduren usw. erfolgt über einen Stapelspeicher, den Stack.

Das bedingt, daß sich mathematisch Formeln nicht in der gewohnten Weise (zum Beispiel: 3 + 4 = ) schreiben lassen. In MAL muß man zuerst die Operanden anführen, damit sie auf den Stack gelegt werden, und anschließend die Operation aufrufen (zum Beispiel: 3 4 + . ). Diese Notationsweise nennt man die ´Umgekehrt Polnische Notation´.

Ich habe es aufgegeben, Personen, die a priori eine Abneigung gegen diese Notation haben, überzeugen zu wollen. Sie ist kürzer und effektiver aber weniger gewohnt. Es scheint mir aber wichtig darauf hinzuweisen, daß diese Ungewohntheit nur bei der Darstellung von Formeln auftritt, also nur einen Bruchteil des üblichen Programmcodes ausmacht.

Als Beispiel sei folgende Aufgabenstellung angeführt: Man möchte eine Zeitreihe von Meßdaten zuerst glätten, dann begrenzen, dann detrendieren und schließlich den Mittelwert berechnen. In MAL würde das syntaktisch etwa folgendermaßen aussehen:

daten glätten begrenzen detrendieren mittelwert

Man wird mir wohl zustimmen, daß diese Notation übersichtlicher ist als die konventionelle:

mittelwert(detrendieren(begrenzen(glätten(daten))))

3.2. Strukturierung

MAL ist eine sehr streng strukturierte Sprache. Sie hält sich an alle von Nassi und Sneiderman gestellten Forderungen:

• Unterprogramme und Programmblöcke haben jeweils nur einen Eingang und einen Ausgang.
• Es gibt keine Sprunganweisung.

3.3. Objektorientierte Programmierung

Es hat lange Zeit gebraucht, bis ich mich dazu durchgerungen habe, Objektorientierte Programmierung in der Sprache MAL zu ermöglichen. Das hat mehrere Gründe:

• Erstens war ich lange Zeit der Überzeugung, daß das nicht erforderlich ist,
• zweitens habe ich lange Zeit benötigt, bis ich das Konzept der Objektorientierten Programmierung wirklich begriffen habe und
• drittens habe ich lange Zeit keine Möglichkeit gesehen dieses Konzept in den bestehenden MAL-Interpreter zu implementieren.

1. Es ist möglich mehrere Prozeduren mit unterschiedlicher Funktion und gleichem Namen zu deklarieren.
2. Die Deklarationen der Prozeduren stehen mit den Deklarationen der von ihnen hauptsächlich verwendeten Daten in einer gemeinsamen Einheit (der Klasse).

4.2. Portierbarkeit

Die ersten vier Versionen des MAL-Interpreters (die hier besprochene ist die Version 5) waren in Turbo-Pascal unter MS-DOS programmiert. Aus verschiedenen Gründen war es unmöglich unter diesen Bedingungen ein portierbares System mit den geforderten Leistungen zu programmieren.

Das hätte der Sprache MAL fast das Ende bereitet, nachdem ich von der Veterinärmedizinischen Universität zum Forschungsinstitut für Orthopädietechnik gewechselt habe und dort damit konfrontiert wurde, daß der zentrale Rechner im Ganglabor eine VAX Workstation mit VMS-Betriebssystem war. An eine Portierung des bestehenden Systems war nicht zu denken - und alles neu programmieren?

Der Entschluß alles neu zu programmieren kam, als die Anschaffung einer neuen Workstation bevorstand. Bei dieser Gelegenheit habe ich gleich von vornherein tunlichst darauf geachtet ein portierbares System zu entwickeln. Die Programmiersprache C++ war dafür besser geeignet als das in vielerlei Hinsicht doch sehr restriktive Pascal.

Portierbar zu programmieren ist zum Großteil eine Frage der Selbstdisziplin. Man darf einfach nur Funktionen nutzen, von denen man annehmen kann, daß sie auf allen möglichen Betriebssystemen existieren. Die Versuchung ist stets groß, den ständigen Forderungen nach mehr Leistung nachzugeben und die gerade gebotenen Möglichkeiten auszunutzen. Ich habe mir auch einige Kritik eingehandelt, weil ich in diesem Punkt niemals nachgegeben habe.

Die Vorteile, die sich aus einer leichten Portierbarkeit ergeben, sind folgende:

• Das System ist dadurch zukunftssicherer.
• Oftmals werden in einem Labor auch gleichzeitig verschiedene Rechnertypen und/oder Betriebssystemtypen verwendet. Man kann sich auf allen Rechnern und allen Betriebssystemen ein nach außen hin vollkommen identes MAL-System installieren und kann Daten und Programme problemlos austauschen.
• Durch die Übersetzung des MAL-Systems mit verschiedenen Compilern werden immer wieder neue Fehler aufgedeckt. Somit erhöht sich langfristig auch die Zuverlässigkeit des Systems.

4.3. Unabhängigkeit

Ich habe es tunlichst vermieden, irgendwelche Standard Softwarepakete zu verwenden oder genauer gesagt, den Betrieb des MAL-Interpreters von Standard Software abhängig zu machen. Die Computer-Brache ist eine schnellebige Branche und Software-Pakete kommen und gehen. Die Entwicklung eines derart umfangreichen Systems braucht aber Zeit. Um den Aufwand rechtfertigen zu können, muß das Produkt auch eine möglichst lange Lebensdauer haben und darf daher nicht von Modeströmungen abhängig sein.

Selbstverständlich bedingt das zum Teil auch Einschränkungen im Leistungsumfang. Vor allem im äußeren Erscheinungsbild wirkt das MAL-System bescheiden. Als Gegenwert bietet es Zukunftssicherheit (soweit das eben garantierbar ist).

Das MAL-System in der hier vorgestellten Form benötigt für den Betrieb ausschließlich das jeweilige Betriebssystem und den entsprechenden C++-Compiler für das Neuübersetzen bei Erweiterungen oder Veränderungen.

4.4. Das Baukastenprinzip

MAL ist ein Software-Baukasten. Zu einem guten Baukasten-System gehören einerseits brauchbare Bausteine und andererseits eine elegante Methode diese miteinander verbinden zu können.

Die Verbindung zwischen Softwareelementen ist die Datenübergabe, also die Technik mit der Ausgangsdaten des einen Moduls an ein oder mehrere andere weitergegeben werden können. Zu diesem Zweck habe ich eine Datenstruktur entworfen, die verblüffend einfach und dennoch universell anwendbar ist.

Sie beruht auf zwei elementaren Datentypen (Zahlen und Strings) und der Möglichkeit diese zu ´Verbunden´, also Arrays zusammenzufassen. Durch die Möglichkeit verschiedenste Datentypen (auch Verbunde) als Komponenten von Verbunden zu definieren, können mit diesen wenigen Sprachelementen tatsächlich alle in Programmen üblichen Datentypen realisiert werden.

Der einzige Grund, warum ich später noch weitere Datentypen eingeführt habe ist, daß Verbunde in manchen Fällen zu speicherplatzintensiv oder zu langsam in der Handhabung werden. Für alle zusätzlichen Datentypen gibt es aber immer entsprechende Befehle, um sie in Verbunde oder umgekehrt umzuwandeln.

4.5. Namen

Die Wahl der Namen für Funktionen, Befehle oder Prozeduren ist für die Lesbarkeit einer Programmiersprache und somit auch für das Arbeiten damit von entscheidender Bedeutung.

Ich habe mich entschlossen für die Namen von Funktionen, Befehlen und Prozeduren des Kernels englischsprachige Begriffe zu verwenden, da dies so gut wie bei allen gängigen Programmiersprachen üblich ist. Soweit wie möglich decken sich die Bezeichnungen auch mit jenen wie sie zum Beispiel in C, Pascal oder Basic üblich sind. Dazu kommen die vielleicht etwas weniger geläufigen Konventionen aus Forth.

Leider sind mir, da Englisch nicht meine Muttersprache ist, auch immer wieder Fehler unterlaufen, die sich zum Teil so gut wie nicht mehr korrigieren lassen, da einmal vergebene Namen nicht mehr zu widerrufen sind, wenn sie einmal häufig in verschiedenen Programmen und womöglich von verschiedenen Anwendern verwendet werden.

Ein weiteres Problem ergibt sich aus der Erweiterbarkeit der Sprache. Namen die Anfangs kurz und prägnant waren, können später zum Problem werden, wenn sie durch hinzukommende neue Befehle ihre Eindeutigkeit verlieren.

5.2. Der Falteditor

Die Idee des Falteditors habe ich bei einer Vorführung des Betriebssystems Occam, welches speziell für den Betrieb von Transputern entwickelt wurde, gesehen.

Ein Falteditor hat die Möglichkeit, Programmblöcke, die eine logische Gesamteinheit darstellen (also Unterprogramme), komprimiert darzustellen. Das heißt, anstelle des Programmcodes wird der Name des Unterprogramms eingeblendet. Bei Bedarf kann man den Code expandieren, oder man ruft ein eigenes Editorfenster, das nur den Code des gewünschten Unterprogrammes enthält, auf.

Diese Methode erhöht die Übersichtlicht beim Programmieren gewaltig. Man kann sich wahlweise auf den groben Überblick ohne Details beschränken oder auf ein Detail konzentrieren, ohne den Balast des Gesamtprogramms zu sehen.

5.3. Versionskontrolle

Eines meiner Hauptziele bei der Neuprogrammierung des MAL-Systems war die Unterstützung von Kooperation, sowohl innerhalb eines Teams als auch von Teams untereinander.

Bei der Zusammenarbeit mehrerer Programmierer an der Entwicklung eines Programms tauchen zwangsläufig von Zeit zu Zeit Konflikte durch Parallelentwicklungen an gleichen Modulen auf.

Das Problem ist vollkommen identisch mit dem Problem der Zugriffskontrolle bei Multiuser-Datenbanken. Dort kennt man die folgenden beiden Verfahren:

1. Record- oder File-Locking, also das Sperren von Teilen der Daten für weitere Zugriffe.
2. Das Zeitstempel-Verfahren, also eine nachträgliche Bereinigung eventuell aufgetretener Konflikte.

1. Man verhindert das Zusammentreffen von vornherein (entspricht dem Record-Locking-Verfahren).
2. Einer schlägt den anderen tot (entspricht einer nachträglichen Entscheidung, welche Version weiter zu verwenden ist).
3. Sie leben in friedlicher Koexistenz (entspricht dem Nichtlösen des Konfliktfalls und der Beibehaltung verschiedener Versionen).
4. Sie paaren sich und bekommen Nachkommen (entspricht dem Zusammenführen der beiden Versionen zu einer ´Superversion´).

5.4. Die Meta Schnittstelle

Ich war praktisch in jedem bewegungsanalytischen Projekt damit konfrontiert, daß verschiedene Softwareteile auf verschiedenen Hardware-Plattformen liefen. Während der Datenaustausch zwischen den unterschiedlichen Plattformen auf physikalischer Ebene in der Zeit der lokalen Netzwerke kein Problem mehr darstellt, ist er auf logischer Ebene nach wie vor problematisch.

Der Vollständigkeit halber sei erwähnt, daß zum Beispiel die Binärformate von Realzahlen auf unterschiedlichen Maschinen keineswegs ident sind, daher der Datenaustausch in Binärformat in der Regel nicht zum Erfolg führt.

Die weit verbreitete Methode, die Daten zum Transferieren auf ASCII-Format umzuwandeln hat mehrere Nachteile. Zum einen erkauft man sich einen Genauigkeitsverlust durch Rundungsfehler und zum anderen muß man praktisch bei jeder Gelegenheit neue Ausgabe- und Einleseroutinen schreiben, um die jeweils unterschiedlichen Datenstrukturen zu transferieren. Und letztlich ist das ASCII-Format auch nicht immer einheitlich (man denke nur an die verschiedenen Zeilenabschluß-Varianten oder die Frage, ob man führende Nullen vor dem Komma weglassen darf oder nicht). Außerdem wollte ich auch die Möglichkeit auf EBSDIC-Maschinen zu transferieren nicht außer acht lassen.

Es war mir also ein Anliegen, dieses Problem auf elementarer Ebene ein für alle mal zu beseitigen. Und zwar so, daß man nicht immer neue Routinen schreiben muß. Das heißt, die Datenkonvertierung durfte nicht direkt von einer Maschine zur anderen vorgenommen werden, sonst hätte man für jede neu einzubindende Rechnertype in alle bestehenden Systeme neue Konvertierungsroutinen einbauen müssen, wie das folgende Bild zeigt:

6. STANDARDISIERUNG

Eines meiner Hauptanliegen ist, die Kooperation im Bereich der wissenschaftlichen Bewegungsanalyse zu unterstützen.

Um Kooperationen zu ermöglichen sind gewisse Standardisierungen erforderlich. Daten und Programme können nur problemlos ausgetauscht werden, wenn sie gleiche Schnittstellen besitzen. Andererseits sind Standards immer eine Belastung für Entwickler. Nicht zuletzt bewirken zu starke Restriktionen, daß keiner bereit ist sich daran zu halten und womöglich von vornherein eine Kooperation ablehnt.

Ich habe mich daher bemüht, nur an den unbedingt notwendigen Punkten Standards einzuführen. Außerdem sind in vielen Fällen die Standards als Vorschläge zu verstehen, die zwar empfohlen, aber nicht zwingend einzuhalten sind. Dadurch besteht zwar die Gefahr, daß sich vielleicht viele Anwender finden, diese aber trotzdem nicht zusammenarbeiten können, weil jeder seine individuellen Lösungen bevorzugt, aber ich rechne grundsätzlich mit dem guten Willen aller.

Vor allem möchte ich jedem die Möglichkeit anbieten, das System schrittweise kennen zu lernen, ohne sich erst mühsam durch einen Berg von Restriktionen arbeiten zu müssen. Es ist aber vollkommen klar, daß ohne Lernbereitschaft und ohne Willen zur Selbstbeschränkung das beste Softwaresystem nicht helfen kann.

Zum Vergleich möchte ich den Straßenverkehr heranziehen: Das Lernen von Verkehrsregeln macht sicher einen Großteil der Arbeit für eine Führerscheinprüfung aus. Und doch ist jeder bereit, diesen Aufwand auf sich zu nehmen, weil er weiß, daß ein effektiver Straßenverkehr ohne Regeln völlig undenkbar wäre.

7. SPEICHERVERWALTUNG

Ich habe es irgendwann aufgegeben, mich darum zu kümmern, daß reservierte Speicherbereiche stets in umgekehrter Reihenfolge wieder freigegeben werden. Das führt natürlich dazu, daß der Speicher im Laufe einer MAL-Session immer mehr zerstückelt wird, was in weiterer Folge dazu führt, daß immer mehr Speicherbereich benötigt wird.

In der Regel ist das kein großes Problem. In Zeiten wo Speicher ohnehin nurmehr in Megabyte gehandelt wird, und außerdem manche Compiler über eine virtuelle Speicherverwaltung verfügen, stoßt man hier selten an Grenzen. Man muß sich nur darüber im klaren sein, daß die Laufzeit des MAL-Interpreters grundsätzlich begrenzt ist, da ja auch der virtuelle Speicher nur eine endliche Größe besitzt.

8. DIE GRAPHIK

Bis vor Kurzem waren die Softwareteile für die Aufbereitung und Ausgabe von Graphiken die ältetsten Teile des Systems. Der erste MAL-Interpreter war im Prinzip ein befehlsgesteuertes Plotprogramm. Auch heute noch sind die Befehle für die Graphikaufbereitung sozusagen simulierte Plotter-Steuerbefehle. Es mag also für das Verstehen der Funktionen durchaus hilfreich sein, sich einen virtuellen Plotter vorzustellen.

Bei der ersten Überarbeitung wurde allerdings die direkte Ausgabe der Befehle auf die Graphikgeräte durch die Erzeugung eines Graphikdatensatzes ersetzt. Das heißt, die Graphikbefehle erzeugen einen Datensatz, der im Anschluß von einem Graphiktreiber auf das jeweilige Gerät ausgegeben wird. Diese Umstellung ermöglicht es nun, fertige Graphiken zu speichern, neu zu skalieren, zu kombinieren und dergleichen.

Ursprünglich war die Schnittstelle zwischen MAL und den Geräten zur Ausgabe der Graphik auf Linen beschränkt (auch Schriftzeichen sind Polygone), damit die Einbindung neuer Graphikgeräte einfach bleibt. Nun haben sich aber in der Zwischenzeit pixelorientierte Graphiken weiter verbreitet als linienorientierte. Außerdem sind die meisten Geräte RGB-tauglich und schließlich ist das Erscheinungsbild der rein linienorientierten Graphiken heutzutage nicht mehr qualitativ ausreichend.

Ein Redesign wurde also erforderlich, sollte jedoch abwärtskompatibel sein, damit nicht alle bestehenden Graphikprogramme neu überarbeitet werden müssen. Folgende Punkte wollte ich verbessern:

• Qualitativ hochwertige Fonts
• Drehbare Schriften
• Füllbare Polygone
• RGB-Farben
• dreidimensional wirkende Graphiken

9. DREIDIMENSIONALE GRAPHIK

Die 3d-Graphik wurde primär für ein vom Forschungsinstitut für Orthopädietechnik betriebenes Projekt ´Computergestützte Fertigung von Prothesenschäften´ entwickelt. Die Verwendung einer Rot/Grünbrille hat sich als die unkomplizierteste Methode für die räumliche Darstellung der Freiform-Oberflächen angeboten.

Es war naheliegend, die Routinen für die 3d-Darstellung auch gleich für die Animation von Bewegungsdaten zu verwenden.

Für die Handhabung von 3d-Objekten habe ich sogenannte Animations- und Polarobjekte eingeführt. Diese Objekte können leider nicht so wie andere MAL-Datensätze am Stack geholt werden.

Das hat folgenden Grund: Die in MAL verwendete Datenstruktur ist für eine rasche Adressierung schlecht geeignet. Ich war also gezwungen, Datensätze die 3d-Objekte beschreiben vor der Verarbeitung in ein internes Datenformat umzuwandeln. Dieses Datenformat nutzt aber, um den Zugriff auf C++ Ebene einfach zu gestalten, Pointer mit Absolutadressen für die Verknüpfung von dynamisch angelegten Teildatensätzen. Es ist daher nicht möglich, diese Datensätze einfach im Speicher zu verschieben oder zu duplizieren, ohne ihre Verweisstruktur zu zerstören.

Aus diesem Grund habe ich mich zunächst entschlossen, Animations- und Polarobjekte ausschließlich im Vokabular zu speichern, das ist neben dem Stack der zweite dynamische Speicherbereich für die Datenübergabe zwischen Prozeduren. Die Einträge des Vokabulars müssen niemals verschoben oder dupliziert werden. Sie werden aber dem Black-Box-Prinzip entsprechend beim Verlassen eines Programmblocks automatisch gelöscht. Das bringt zwar gewisse Einbußen in der Handlichkeit mit sich, erspart aber dem Programmierer das explizite Löschen von eingerichteten Animations- oder Polarobjekten (was vor allem im Fehlerfall immer schwierig ist) und macht somit die Programme robuster.

Viele Jahre später habe ich die 3d-Darstellung nochmals komplett überarbeitet und Open-GL für die Ausgabe verwendet. Bei dieser Gegenheit habe ich den oben erklärten Mangel auch gleich behoben, indem die Objekte, wenn sie vom Stack geholt werden in das interne Format konvertiert werden und nach der Darstellung/Bearbeitung wieder zurück konvertiert und auf den Stack gelegt werden. Außerdem habe ich dann noch auf MAL-Ebene Klassen für die Handhabung der 3d-Objekte definiert.

Lieder geistern in dem mittlerweile doch sehr umfangreichen MAL-Programm noch ein paar alte Strukturen herum, die das Arbeiten mit 3d-Objekten etwas unübersichtlich machen.

10. DAS POOLSYSTEM

Schon sehr bald im Zuge der Entwicklung eines universellen Meßdaten-Analysesystems ist das Problem der Archivierung von Meßdaten aufgetaucht. Erste Versuche mit verschiedensten datei- oder in der ersten Zeit sogar diskettenorientierten Archivierungsmethoden haben sich immer wieder nach einiger Zeit als unzureichend herausgestellt. Die zentrale Problematik ist, daß sich mit den ständig wechselnden Anforderungen, die Forschungsarbeit nun einmal mit sich bringt, auch die Speicherungsstrukturen ändern müssen.

Auch kommerzielle Datenbanksysteme können dieser Anforderung nicht gerecht werden. Jede Datenbank erfordert zuerst ein Datenbankdesign, das man aber bei Forschungsprojekten immer erst am Ende, wenn man genug Erfahrung gesammelt hat, wirklich erfolgreich durchführen kann. Ja schon die Auswahl der Art des Datenbanksystems, ob hierarchisch, relational oder objektorientiert erfordert, daß man nicht nur über die anfallenden Daten, sondern auch über die voraussichtlich zu machenden Analysen, bescheid weiß.

Ich habe mich daher auf die Suche nach einer, wie ich es für mich genannt habe, ´amorphen Datenbank´ gemacht. Einer Datenbank, deren Speicherstruktur man festlegen kann, nachdem die Daten bereits gespeichert sind. Das Poolsystem ist die Realisierung solch einer ´amorphen Datenbank´. Ein Pool ist sozusagen ein großer Topf, in den man vorerst einmal die anfallenden Daten einwerfen kann. Danach kann man sich über die Strukturierung, also die möglichen Suchwege nach den Einträgen, Gedanken machen. Selbstverständlich wird man in den meisten Fällen die Strukturierung unmittelbar nach dem Schreiben der Daten vornehmen, aber es ist nicht erforderlich. Vor allem kann man eine gewählte Adressierungsstruktur verwerfen und durch eine neue ersetzen oder sogar mehrere Adressierungsstrukturen parallel verwenden. Eine Möglichkeit, die zum Beispiel bei der Adressierung von archivierten MAL-Unterprogrammen genutzt wird.

Die Definition der Archivierungsstrukturen kann vollständig auf MAL-Ebene, also in Form von MAL-Programmen und unter Nutzung der MAL-Datenstrukturen, erfolgen. Für das am häufigsten gebräuchliche Adressierungsmodell, die relationale (=tabellenorientierte) Datenbank, habe ich entsprechende Programme entwickelt. Ich habe für diese Speicherstruktur den Begriff ´Folder´ gewählt, weil ich eine deutliche Unterscheidung von vollständigen relationalen Datenbanken haben will. Folder sind natürlich in ihrer Leistungsfähigkeit, vor allem was die Adressierung von Daten per Query-Language betrifft, nicht mit kommerziell erhältichen Datenbanksystemen zu vergleichen.

Eine weitere Motivation, ein eigenes Archivierungssystem zu entwickeln, war die Zugriffsgeschwindigkeit. Wie bereits angedeutet, wollte ich nicht nur Meßdaten, sondern auch Programmcode oder sonstige Datensätze damit speichern. Ein Sprachinterpreter benötigt aber den Programmcode zur Laufzeit, das bedeutet, daß jedesmal, wenn ein archivierter Programmteil aufgerufen wird, ein Lesezugriff auf das Archiv erforderlich ist. Das Poolsystem ist auf unterster Ebene um ein vielfaches schneller, als ein Datenbanksystem. Es benötigt in der Regel nur einige wenige, oftmals sogar nur einen einzigen, Dateizugriffe, um eine Datensatz zu lesen.

Um das Kapitel des Poolsystems abzuschließen, möchte ich noch die Frage der Datensicherheit und im speziellen des Recovery (der Datenrekonstruktion nach Systemabstürzen) behandeln:

Ich habe bevor ich die Entwicklung des Poolsystems begonnen habe, verschiedene Vorlesungen über Datenbanksysteme auf der TU besucht. Mit Entsetzen habe ich feststellen müssen, daß Recovery ein schier unlösbar komplexes Problem ist. Es wird aber erheblich einfacher, wenn man sich auf die Erfordernisse der Bewegungsanalyse, oder der wissenschaftlichen Meßdatenerfassung im allgemeinen, beschränkt.

Kommerzielle Datenbanksysteme sind primär für das Bankwesen oder Geschäftswesen entwickelt. In diesen Bereichen mag eine halb durchgeführte oder verlorene Transaktion eine Katastrophe sein. Wenn bei einer wissenschaftlichen Messung der Strom ausfällt und die Daten der letzen Messung verloren gehen, so stellt das ein eher marginales Problem dar, solange die Datenbankstruktur nicht Schaden leidet.

11. MESSDATENARCHIVIERUNG

Ein universelles Softwaresystem für die Messung, Archivierung und Analyse von Bewegungsdaten sollte meiner Ansicht nach folgende Eigenschaften haben:

12. NEURONALE NETZE

Die initiale Idee, Algorithmen der Artificial Inteligence für Zwecke der Bewegungsanalyse zu nutzen, geht auf jene Zeit zurück, wo ich noch an der Veterinärmedizinischen Universität beschäftigt war. Dort war das Projektziel, bewegungsanalytische Methoden für die Lahmheitsdiagnose bei Pferden einzusetzen.

Die Erfolge mit den gängigen Methoden der Biomechanik oder Statistik haben mich nicht zufrieden gestellt. Ich bin nach eingehenden Betrachtungen zu dem Schluß gelangt, daß das Wissen, ob eine Lahmheit vorliegt und welche Lahmheit vorliegt, nicht aus den Bewegungsdaten selbst gewonnen werden kann. Schließlich haben wir den Erfolg oder Mißerfolg unserer Messungen immer durch Vergleich mit den Beurteilungen der Tierärzte gemessen. Und mein Vertrauen in deren Urteil war stets größer als das in unsere, damals noch völlig in den Kinderschuhen steckende, meßtechnische Beurteilung.

Ein wesentlicher Gedankenschritt war schließlich die Loslösung von dem Willen, ein objektives Meßsystem zu entwickeln, was gleichbedeutend ist mit: sich von dem Zwang zu befreien, die Berechnung der Resultate logisch begründen zu können.

Unter diesen Hintergründen hat mich dann ein Artikel in einer Computerzeitschrift angesprochen, der sich mit Selbstorganisierenden Systemen von Teuvo Kohonen befaßte. Den vorgestellten Algorithmus habe ich seinerzeit programmiert und getestet. Er war aber für unsere Zwecke wenig geeignet. In der Folge habe ich lange nach Experten auf diesem damals noch sehr wenig bekanntem Fachgebiet gesucht und bin schließlich erst einige Jahre später auf Monika Köhle gestoßen, die mir geraten hat, mit Backpropagation zu arbeiten. Als Ergebnis unserer gemeinsamen Arbeit ist 1993 ein Artikel im Journal of Biomechanics erschienen (Holzreiter S., Köhle M., ´Assessment of Gait Patterns Using Neural Networks´, J. Biomechanics Vol. 20, No.6, pp 645-651, 1993).

Der Anwendung von Mustererkennungsverfahren in der Ganganalyse liegen zum Teil auch philosophische Überlegungen zugrunde. Der Versuch den Menschen als rein mechanisch funktionierendes ´Objekt´ zu sehen ist meiner Ansicht nach von vornherein zum Scheitern verurteilt. Man ignoriert auf diese Weise die Existenz des freien Willens und den Einfluß der menschlichen Psyche. Der Mensch ist kein Objekt sondern ein Subjekt. Daher kann man ihn niemals objektiv, sondern immer nur subjektiv, beurteilen.

Die Anwendung von Mustererkennungsverfahren spiegelt diesen Sachverhalt sehr gut wieder. Sie geben niemals vor objektiv zu sein, da sie ja nur Erfahrungen, die sie anhand von Beispielen gelernt haben, zu extrapolieren versuchen.

Nachdem die Erfolge mit Backpropagation Netzen überraschend gut waren, habe ich jenen Algorithmus, den ich ursprünglich für die Tests verwendet habe etwas flexibler gestaltet und in das MAL-System eingebunden. Man muß bei der Anwendung von Neuralen Netzen mit verschiedensten mathematischen Datenaufbereitungsmethoden experimentieren, wozu der MAL-Interpreter bestens geeignet ist.

13. DIE DOKUMENTATION

Wie bereits erwähnt sind die Help-Pages zu den einzelnen Befehlen die jeweils aktuellste und auch detailierteste Dokumentation. Sie werden praktisch ständig auf dem neuesten Stand gehalten. Das bedeutet aber auch, dass in den Help-Pages manche Teile dokumentiert sind, die nicht fertig entwickelt oder nicht getestet wurden.

Nach verschiedenen Anläufen mit diversen Textverarbeitungsprogrammen, die entweder unpraktisch oder bald veraltet (oder beides) waren, habe ich mich nun entschlossen alles direkt in HTML-Code zu dokumentieren, wobei ich mir einige Hilfsmittel für die Strukturierung und das Editieren direkt in MAL programmiert habe. Das scheint mir eine zukunftssichere Methode zu sein, denn HTML ist nicht mehr auszurotten und ohne MAL ist auch keine MAL-Dokumentation erforderlich.

Eine wesentliche Hilfe bei der Erprobung von Modulen sind die sogenannten ´Environments´. Das sind Aufrufumgebungen, also Aufrufbeispiele, der entsprechenden Module, die bei deren Entwicklung vom Entwickler zum Testen verwendet werden. Environments existieren aber nur zu den in MAL geschriebenen Modulen und nicht zu Befehlen, die im Systemkern, also in C++ realisiert sind.