Analyse, Design & Evolution

Bei strenger Verfolgung des Makro-Prozesses in der Systementwicklung nach Booch ist zu erkennen, daß das entworfene Wissensmodell die Konzeptualisierung und, zusammen mit dem Programmodell, Teile der Analyse und des Designs abgedeckt. Die Evolution, also die Entwicklung der Implementierung des Programms, setzt eine feinere Zergliederung des komplexen Gesamtsystems voraus. Grundsätzlich lassen sich in der Analyse zwei orthogonale Vorgehensweisen unterscheiden, eine algorithmische oder eine objektorientierte Zerlegung. Die Orthogonalität bezieht sich auf die Notwendigkeit beider Ergebnisse, deren Herbeiführung aber nicht gleichzeitig zu bewältigen ist (vgl [BOO] S. 32-34).

Die algorithmische Zerlegung, wie sie in der Strukturierten-Analyse-und-Design Methode, die als Vorläufer der objektorientierten Methoden gilt, zu finden ist, kann hilfreich auf die im Programmodell identifizierten Software-Komponenten angewendet werden. Das fensterorientierte X Window System informiert eine Applikation über Eingaben des Benutzers mit Mausbewegungen oder Tastendruck durch Events. Solche Ereignisse werden ebenfalls bei Veränderungen der Sichtbarkeitsverhältnisse der Fenster der Benutzungsschnittstelle generiert und in einer Warteschlange gespeichert. Die Anwendung selber ist zuständig für die Entgegennahme der Events und die, an die Interpretation anschließende Verarbeitung (vgl. [JON]). Diese ereignisgesteuerte Verarbeitung findet in einer Schleife der Open Inventor Komponentenbibliothek solange statt, bis die Anwendung beendet wird oder sie in den Hintergrund tritt. Von Interesse in der algorithmischen Analyse sind auch jene Ereignisse, die eigentlich keine sind; wenn nämlich in der Warteschlange keine Events bereitstehen und das Hauptfenster der Anwendung weiterhin den Fokus besitzt, der Mauszeiger also innerhalb des Fensterrahmen liegt. Nach Kontrolle der Warteschlange wird das Rendering in drei Schritten der OpenGL gestartet. Im ersten Schritt werden die dreidimensionalen Koordinaten der Objekte den verschiedenen Transformationen, Rotation, Translation, Skalierung und Projektion, die durch Matrizenmultiplikationen repräsentiert werden, unterworfen. Objekte oder Teile der Objekte, die außerhalb des rechteckigen Ausschnitts des Fensters liegen, werden mit Hilfe des sogenannten Clipping im zweiten Schritt entfernt. Abschließend wird in der Viewport-Transformation die Korrespondenz der transformierten Koordinaten und der Bildpunkte des Fensters hergestellt. Dieser Prozeß erfolgt analog der Aufnahme einer Photographie. Der Standpunkt der Kamera und das abzubildende Modell werden zunächst durch die Modelview-Matrize beschrieben, die mathematisch durch Multiplikation der Matrize mit den Koordinaten der Objekte entsteht, dann legt das gewählte Objektiv der Kamera, ebenfalls durch eine Matrizenmultiplikation, die Projektions-Matrize fest. Punkte, die außerhalb des entstandene Volumen liegen, das einem Pyramidenstumpf oder Quader entspricht, werden entfernt und die zweidimensionale Projektion wird in das Koordinatensystem des Fensters umgerechnet (vgl. [NEI] S. 63-69).

Die objektorientierte Zerlegung bestätigt, analog der algorithmischen Analyse, eine hierarchische Struktur, wie sie komplexen Systemen stets eigen ist (vgl. [BOO] S. 27). Der Toolkit Xt Intrinsics basiert als objektorientierte Schicht auf der Softwarebibliothek Xlib, der Programmschnittstelle zum X Window System und dessen Server. Xt stellt Mechanismen, etwas anderes als "intelligentes" Verhalten, bereit, die Benutzungsschnittstelle mit Widgets zu abstrahieren. Widgets sind eine wiederverwendbare, konfigurierbare Kodierung, die, außer über vordefinierte Interaktionen, unabhängig von der Anwendung funktionieren. Ein Xt Widget besitzt ein X Window, mit diesem Fenster können Ereignisse verarbeitet werden, und Funktionen, die das Verhalten kontrollieren. Diese Attribute zeichnen ein Widget als objektorientierte Abstraktion aus, obwohl die Programmierung mit der prozeduralen Sprache C erfolgt. Open Inventor kapselt die Funktionalität der X Schnittstelle in der Klasse SoXt, von der, da sie eine statische Klasse ist, keine Instanzen erzeugt werden. Die Methode SoXt::init initialisiert die Verbindung zum X Server und gibt das Anwendungshauptfenster zurück, SoXt::mainLoop stellt die Ereignisschleife des Hauptprogramms dar. In einer weiteren Klasse der Komponentenbibliothek, SoXtRenderArea, wird das explizite Rendering der OpenGL mit seinem direkten Zugriff auf den Framebuffer, den Speicherbereich, von dem aus die gezeichneten Objekte in das von SoXt erzeugte Fenster kopiert werden, versteckt. (vgl. [WER], K1 S. 5, K16 S. 3). Die Klassen der "Viewer", von SoXtRenderArea abgeleitet, kombinieren das Rendering mit den Interaktionsmöglichkeiten der Benutzungsschnittstelle und steuert insbesondere die Positionierung der Kamera. Sie bestimmt in der Photographieanalogie die Modelview-Matrize, und stellt die, aus der Ereignisschleife aufgerufene Methode SoXtViewer::processEvent bereit. KategoSphär modelliert die Beziehung des Viewers zur Kamera einerseits durch Vererbung von SoXtViewer zur Klasse KSBetrachter, die processEvent überschreibt, andererseits als Teil-von-Beziehung der Klasse KSKamera zu KSBetrachter, um den direkten Zugriff auf diese exklusiv zu halten. Der Inventor Toolkit organisiert die Objekte einer dreidimensionalen Szene in einer hierarchischen Datenbasis, deren Bausteine der Klasse SoNode, bestimmte Information beinhalten, die als Fields, Felder, bezeichnet werden. Es gibt Nodes, Knoten, für die Geometrie und Farben der darzustellenden Objekte des Modells, Knoten, die Transformationen repräsentieren und auch die Attribute von Lichtquellen und Kameras werden als Felder von Knoten gespeichert. Spezielle Nodes, wie SoGroup, gruppieren Objekte und die davon abgeleitete Klasse SoSeparator verhindert die sonst kumulierenden Matrizenmultiplikationen der OpenGL durch zwischenzeitliches Laden der Einheitsmatrize. Die Knoten einer Szene werden als gerichteter Graph verkettet, entlang dessen Kanten das Rendering erfolgt. Solch ein Graph steht als Instanz "SzeneGraph" ebenfalls in einer Teil-von-Beziehung zur Klasse KSBetrachter. Eine graphische Darstellung des Graph als Baum vermittelt die Hierarchie der Objekte besser als die äquivalente durch eine lineare Liste. Die Verarbeitung der ersten zwei Schritte der OpenGL erfolgt von links oben in der Zeichnung, entlang der Äste, nach unten rechts (vgl. [WER]).

Abb. 8 Inventor Graph & Legende

Das Wissensmodell KategoSphär konzipiert eine Kategorie als Raum zwischen Himmel und Planet, in dem navigiert werden kann. Im Programmodell, wo der Benutzer durch die Kamera in der Modellwelt vertreten wird, beschränken zwei konzentrische Kugeln deren Bewegungen. Beide Kugeln, als Klassen KSHimmel und KSPlanet, dienen im Programm als Behälter für die medialen Konzepte. Als Generalisierung beider entsteht die Klasse KSSphaere, die zur Klasse KSKonzept, wie KSKategorie zu KSHimmel und KSPlanet, in einer Teil-von-Beziehung steht. Während die Assoziation zwischen KSSphaere und KSKategorie auf eine physikalische Abhängigkeit hinweist, das heißt, existiert die Kategorie nicht mehr, existieren auch Himmel und Planet nicht mehr, stellt die Beziehung einer Sphäre zu einem Konzept eine Referenz her. Die Klasse KSKonzept besitzt als wesentliches Attribut ihre geometrische Erscheinung, repräsentiert durch die Klasse KSGeometrie. Zusammen mit den Klassen SoShapeKit, Basisklasse für KSGeometrie, SoShape und SoCube ergibt sich ein Ergebnis der Analyse, deren Zweck es ist "die Welt zu modellieren, indem wir Klassen und Objekte identifizieren (sowie ihre Rollen, Verantwortlichkeiten und ihr Zusammenwirken), die das Vokabular des Problembereichs bilden." ([BOO] S. 316). In der Notation nach OOAD (vgl. [BOO] S. 223-226) lassen sich die Beziehungen zwischen den Klassen von Open Inventor und den Schlüsselabstraktionen des Wissensmodell folgermaßen wiedergeben.

Abb. 9 Klassendiagramm Inventor & KategoSphär

Um das gewünschte Verhalten des Gesamtsystems zu modellieren, müssen die Verantwortlichkeiten der einzelnen Elemente konform spezifiziert werden. Am Beispiel der Kamera von KategoSphär werden einige Schwierigkeiten der Integration von bestehenden Softwarebibliotheken und einer darauf aufbauenden Applikation aufgezeigt. Die OpenGL, und so auch Open Inventor, verwenden, wie beschrieben, eine Photographieanalogie mit einer Kamera und deren Objektiv. Um eine Projektion der sichtbaren Objekte in der Bildebene zu erhalten, muß diese dem Brennpunkt vorgelagert sein. Die Klasse SoPerspectiveCamera besitzt als Attribut eben diesen Augpunkt als Kamerastandpunkt, die Bildebene, "NearPlane" genannt, ist um die Länge, "nearDistance", verschoben. In der Abbildung auf den Bildschirm einer Workstation liegt das Fenster in der Bildebene, der Abstand zum Augpunkt entspricht dem des Benutzers zum Bildschirm. KategoSphär trägt diesem Umstand durch die Klasse KSKamera Rechnung, die eine eigene Behandlung der Position neben die, der geerbten Brennpunktposition stellt. Die Entfernung (e) wird durch Angaben der Höhe (h) der "Kamerakiste" und des Öffnungswinkels des Objektivs bei der Instantiierung berechnet und so, die "echte" Position bestimmt. Zusammen mit dem Maximal- bzw. Minimalradius verhindert die Höhenangabe das Schneiden des Bildes mit den Sphären des Himmels bzw. Planeten.

Abb. 10 Kamerakiste des Betrachters

Das Analysemodell ist ausreichend vollständig, um den Designprozeß zu beginnen, dessen Zweck es ist eine Architektur der Implementierung zu erzeugen. "Ein architektonischer Release stellt einen vertikalen Schnitt durch die gesamte Architektur dar (... und ...) sollte ausführbar sein und somit ermöglichen, daß die Architektur eingesetzt, untersucht und ausgewertet werden kann." ([BOO] S. 320). Der Zyklus des Mikro-Prozesses dient mit der Identifizierung der Semantik der Klassen und Objekte dazu, das Verhalten und die Attribute der Abstraktionen festzulegen. Zur Auswertung des Programmodells KategoSphär gehören noch weitere Klassen und Methoden, die das Einfügen neuer und das Löschen und Manipulieren vorhandener Konzepte implementieren. Aus der Klassenbibliothek Open Inventor werden die Klassen SoSelection, mit ihrer Verarbeitung des Picking, als Basisklasse für KSKategorie und die Klasse SoRotateSphericalDragger, mit der optischen Hervorhebung und geometrischen Veränderung des selektierten Objekts, für KSManipulator übernommen. Die Klasse KSKategorie verfügt damit über Operationen, als Behälter, wegen der Vererbungshierarchie bis hinunter zu SoGroup, für Planet und Himmel zu dienen und zur Behandlung von Picking-Events mit sogenannten Callbacks, globale Funktionen, die eine vordefinierte Signatur besitzen und aus der Ereignisschleife aufgerufen werden. Die Klasse KSKonzept erhält den Zugriff auf einen Manipulator durch eine Teil-von-Assoziation zur Klasse KSManipulator und Methoden, diesen mit den Attributen ihrer Geometrie zu instantiieren und zu verknüpfen. Zwei Graphiken in der OOAD-Notation heben die Architektur des soweit entwickelten Programmodells deutlicher hervor.

Das semantische Klassendiagramm zeigt wesentliche Aspekte des Protokolls und der Beziehungen der Klassen und ergänzt die Semantik der Basisklasse von KSGeometrie, SoShapeKit. Diese Aggregation bindet mehrere Knoten, wie die Erscheinung mit Zeichenstil, Textur oder Material und die Transformationen der Objekt- und Weltkoordinaten, als vorgefertigte "parts" zu einem Gegenstand, einem "Nodekit", zusammen, der sich als Objekt übergeordneter Bedeutung auffassen läßt.

Abb. 11 semantisches Klassendiagramm KategoSphär & Inventor

Das Objektdiagramm stellt eine Momentaufnahme des Systems mit seinen Klasseninstanzen und deren Interaktionen bei Eintreten eines Selektionsereignisses dar. Objektdiagramme werden in der Analyse verwendet, “"um die Semantik primärer und sekundärer Szenarios anzugeben, die das Verhalten des Systems nachvollziehen (... und ...) um die Semantik der Mechanismen im logischen Design eines Systems aufzuzeigen." ([BOO] S. 262).

Abb. 12 Objektdiagramm Selektion

Die Numerierung der Pfeile für die Kommuniktionsassoziationen gibt die Reihenfolge der Interaktionssequenz an. Der Callback-Methode der Klasse KSKategorie wird eine Instanz der Klasse SoPath, die einen Graph enthält, dessen Knoten jeweils nur einen Nachfolger haben, übergeben. Nach der Suche der Sphären Himmel und Planet, durch einen Vergleich mit den im Pfad enthaltenen Knoten (2, 3), wird die Verarbeitung im Objekt Planet fortgesetzt, das im Selektionspfad gefunden wurde. Die Methode KSSphaere::selektKonzept weist das selektierte Konzept (5), ebenfalls nach dem Vergleich seiner Konzepte mit dem Pfad (4, 5), der Variablen SelektKonzept zu (6). Unter Verwendung der Operation KSKonzept::selekt (7) instantiiert das ausgewählte Konzept einen Manipulator der Klasse KSManipulator (9) mit den abgefragten Attributen seiner zugehörigen Geometrie (8). Abschließend wird die Rotation der globalen Transformation, die die Koordinaten des gesamten Objekts im Raum verkörpern, der Instanz der Klasse KSGeometrie, mit dem Rotationsfeld des Manipulators verknüpft (10). Die nachfolgenden Selektionssereignisse, bzw. Bewegung des Zeigers bei gedrückter Taste, vermittels der Benutzungsschnittstelle, die das markierte Konzept betreffen, werden als Veränderung der Position seiner Geometrie interpretiert. Aus Sicht des Makro-Prozesses kann vom Design zur Evolutionsphase übergegangen werden, "wenn wir die Architektur mit Hilfe eines Prototyps und einer formalen Überprüfung ausgewertet haben" ([BOO] S. 323). Die Evolution dient dem Zweck, "die Implementierung durch schrittweise Verfeinerung wachsen zu lassen und zu modifizieren" ([BOO] S. 323). Für das Programmodell KategoSphär gilt es, die vorhandene Architektur, die sich auf die Verwaltung der Abstraktion Konzept des Wissensmodells beschränkt, in Richtung der medialen Repräsentation von Begriffen bestimmter Kategorien weiterzuentwickeln. Das Tandem der Klassen KSKonzept und KSGeometrie zeichnet sich als Kandidat zur polymorphen Wiederverwendung mit Hilfe der Vererbung, im objektorientierten Sinne, aus. Die medialen Begriffe des Wissensmodells, Bilder, Texte und Töne, finden durch entsprechende Spezialisierung der Klasse KSKonzept Eingang in das Programmodell, deren visuelle Pendants als Ableitungen der Klasse KSGeometrie. Die Klasse KSBildGeo benutzt die Möglichkeit der Klasse SoShapeKit ein Objekt mit einer Textur zu versehen, die als X Pixmap oder Datei in einem entsprechenden Graphikformat vorliegt. Ein Quader, mit einer geringen Tiefe und einer Breite, die durch das Seitenverhältnis des Bildes bei gegebener Höhe angepaßt wird, läßt diese Art Begriff in der Klasse KSBild als räumliche Leinwand erscheinen. Textuelle Medien werden durch eine spezielle Klasse aus der Hierarchie von SoShape, SoText3, dargestellt, nachdem eine Dateileseprozedur die Zuordnung zu einem gespeicherten Text erledigt hat. In der Klasse KSTon findet in gleicher Weise eine Verknüpfung mit einer Datei, diesmal in einem Format für digitale Klänge, statt und die geerbte Selektionsmethode wird um das Abspielen des Tons erweitert. Die Klasse KSTonGeo gibt das Konzept als Kegel optisch wieder. Das entworfene Wissensmodell sieht, neben einer beliebigen Anzahl an Begriffen in einer Kategorie, die Möglichkeit vor, Konzepte in verschiedenen Kategorien zu organisieren. Die Verbindung einer Sphäre mit der gegensätzlichen einer anderen Kategorie und den Mechanismus, darin einzutauchen, stellt die am stärksten spezialisierte Klasse KSKategoKonzept her. Sie besitzt als Attribut eine Referenz zur Klasse KSKategorie und wacht mit einer Methode darüber, ob sich die Position der Kamera innerhalb ihrer Geometrie, einer Kugel, befindet. Die nächste Version des Prototyps beinhaltet weiter die Führung einer Lichtquelle in Abhängigkeit der Kameraposition und ein modales X Window für einen Dialog zur Verknüpfung der Begriffe in der Modellwelt mit den entsprechenden Dateien. Der Dialog ist auf Ebene der Xtlib realisiert, bestehend aus einem Widget mit Radiobuttons und einem, in der Xt Intrinsics Bibliothek enthaltenem, Widget FileSelectionBox. Das folgende Diagramm faßt den Prototyp des Programmodells mit den letzten Evolutionsphasen in der Notation der OOAD-Methode zusammen.

Abb. 13 Klassendiagramm Prototyp KategoSphär

Zu den Hauptelementen der objektorientierten Modellierung gehören Abstraktion, Kapselung, Modularität und Hierarchie (vgl. [BOO] S. 60-90), die im Prototyp in dieser Evolutionsstufe zu finden sind, hinzu kommen noch die Elemente Typisierung, Nebenläufigkeit und Persistenz, "die Eigenschaft eines Objekts, durch die seine Existenz eine bestimmte Zeit überdauern kann (...) und/oder auch einen bestimmten Speicherplatz" ([BOO] S. 104). Das Programmodell KategoSphär verwendet die von Open Inventor, mit der Datenbasis und deren Dateiformat, realisierte Strategie zur Speicherung der Objekte. Der beschriebene Szenegraph bildet die Datenbasis, in der die Instanzen der Klassen als Knoten während der Programmausführung existieren. Um den Austausch der Daten mit anderen Programmen und deren Bewahrung zwischen den Ausführungen des erzeugenden Prozesses zu ermöglichen, bietet Open Inventor ein spezielles Format der Darstellung an, das als Datei auf ein Festspeichermedium geschrieben oder mit anderen Applikationen geteilt werden kann. Diesen Vorteilen des Dateiformats, es wurde zur Grundlage der Virtual Reality Modeling Language (VRML), stehen die typischen Nachteile einer dateiorientierten Speicherung, Inkonsistenzen und referenzielle Desintegrität, gegenüber. Die Nutzung der Daten, die ein Objekt repräsentieren, setzt Informationen über seine Klassenzugehörigkeit voraus, was in der Inventor Bibliothek durch Implementierung einer Laufzeittypisierung, die von der Programmiersprache C++ nicht unterstützt wird, geleistet wird. Jede Klasse, deren Instanzen im Szenegraph aufgrund ihres Typs gefunden werden sollen, besitzt eine statische Methode initClass, die vor der ersten Instantiierung eines Objekts aufgerufen werden muß, und Konstruktoren, die beim Einlesen einer Datenbasis mit der Klasse SoDB eingesetzt werden. Die hierarchische Baumstruktur des Graphen, eine gerichtete Eltern-Kind-Beziehung, welche für das Rendering der OpenGL gut geeignet ist, wirft, wie in der Suche des selektierten Knoten eines KSKonzept-Objekts, die Nachteile der vollständigen Traversierung des erzeugten Graphen nach der Leseoperation auf, da die Zuordnung der Teile in den Teil-von-Assoziationen erst nach deren Instantiierung erfolgen kann.

Abb. 14 Inventor Graph KategoSphär

Das KategoSphär Programmodell, in dieser Evolutionsphase, überträgt die Aufgabe der Initialisierung der Laufzeitzeittypisierung der Klasse KSBetrachter und stattet die Klassen, die im Szenegraph zu finden sind, mit den nötigen Methoden für die Persistenz aus. Die vorige Darstellung eines Szenegraphs, der zum Szenario des Selektionsereignisses paßt, gibt eine der modellierbaren Welten mit Kategorien und Konzepten in der Notation, die Open Inventor vorsieht, wieder. Die soweit entwickelte Version des Prototypen verwirklicht die Kernanforderungen an das System, wie sie in der Konzeptualisierung entworfen wurden und bietet Möglichkeiten, das Modell zu untersuchen und zu bewerten. Der Makro-Entwicklungsprozeß, der nach der Evolution in die Verwaltung der Implementierung mündet, wird für KategoSphär vor dieser Phase beendet, da eine Auslieferung des Systems nicht Ziel der Entwicklung eines Prototypen ist. "Es muß betont werden, daß alle diese Prototypen letztendlich weggeworfen werden. Prototypen sollten nicht direkt in das Produktionssystem einfließen, es sei denn, es gibt einen vernünftigen Grund dafür. Sie der Bequemlichkeit halber zu verwenden, um den Zeitplan einzuhalten, ist mit Sicherheit kein zwingender Grund" ([BOO] S. 314).

Die entstandenen Prototypen des Wissensmodells KategoSphär als Computer-Programm konnten allerdings und können in weiteren Entwicklungszyklen als Ideenlieferant und Testumgebung wertvolle Dienste leisten. Die im Anhang abgedruckte Version implementiert beispielsweise zusätzlich eine akustische Rückmeldung der Bewegungen der Kamera und des Wechsels von Kategorien.

Schlußbemerkung