Entwurfsunterstützung für die 3D Visualisierung von dynamischen Modellen

Transkript

1 Fakultät für Elektrotechnik, Informatik und Mathematik Arbeitsgruppe Softwaretechnik Warburger Strasse Paderborn Entwurfsunterstützung für die 3D Visualisierung von dynamischen Modellen Bachelorarbeit zur Erlangung des Grades Bachelor of Computer Science für den integrierten Studiengang Informatik von Helmer Krämer Lichtenturmweg Paderborn vorgelegt bei Herrn Dr. Holger Giese und Herrn Prof. Dr. Gerhard Szwillus Paderborn, den 15. März 2003

2 ii

3 Erklärung Ich versichere, dass ich die namentlich kenntlich gemachten Teile der Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertig habe und dass die Arbeit in gleicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Paderborn, den 15. März 2003 Helmer Krämer iii

4

5 Inhaltsverzeichnis 1. Einleitung Motivation Beispiel Simulation Probleme und Ziele Aufbau der Arbeit Grundlagen Visualisierungen Modelltypen Architektur Modell Visualisierung Framework Aufbau Updatemechanismen Betriebsmodi Fujaba PlugIn Spezifikation der Darstellung Codegenerierung Umsetzung Zusammenfassung und Ausblick 29 A. Anwendung am Beispiel A Abbildungsverzeichnis Literaturverzeichnis E G 1

6

7 Kapitel 1. Einleitung 1.1. Motivation Bei der Spezifikation und Modellierung komplexer Systeme wird heute immer häufiger die Unified Modeling Language (UML) [5] eingesetzt. Wenn das modellierte System zusätzlich mit seiner Umwelt interagiert und nur im Kontext dieser Umgebung sinnvoll eingesetzt und verstanden werden kann, liegt es nahe, auch für die Umgebung ein dynamisches UML Modell zu erstellen. Neben der Modellierung des Systems und seiner Umwelt als Software ist für ein Verständnis der Abläufe innerhalb dieser Systeme eine graphische Darstellung der Umwelt hilfreich oder sogar notwendig. In dieser Arbeit soll daher ein Ansatz entwickelt werden, die Erstellung einer solchen Visualisierung zu vereinfachen Beispiel Simulation Um die verschiedenen Techniken und Lösungsansätze zu veranschaulichen, wird in der vorliegenden Arbeit die Simulation eines schienengebundenen Verkehrsmittels als Beispiel verwendet. In dieser Simulation sollen die Bewegungen von Shuttles auf einem Schienennetz berechnet werden. Desweiteren können Shuttles sowohl beladen als auch unbeladen sein. In Abbildung 1.1 ist ein Klassendiagramm abgebildet, welches die wesentlichen Elemente der Beispielsimulation enthält. Das Schienennetz wird aus Track Instanzen gebildet, die jeweils eine Schiene repräsentieren. Das Shuttle selber ist durch die Klasse Shuttle modelliert worden. Um mögliche Aufträge zu erfassen, gibt es die Klasse Order. 3

8 Kapitel 1. Einleitung Abbildung 1.1.: Klassendiagramm der Beispielsimulation Eine mögliche Visualisierung dieser Beispielsimulation ist in Abbildung 1.2 gegeben. Die einzelnen Tracks werden hierbei duch braune Geraden bzw. Kreisbögen visualisiert. Das Shuttle als wesentlicher Bestandteil der Simulation erhält die aufwendigste Darstellung und ist sofort als solches erkennbar. Den Auftrag, der von dem Shuttle momentan abgearbeitet wird, wird durch die blaue Kiste auf der Ladefläche des Shuttles visualisiert Probleme und Ziele In dieser Arbeit soll ein Ansatz entwickelt werden, der die Erstellung einer Visualisierung für ein bereits vorhandenes UML Modell vereinfacht. Hierbei sollen Modell und Visualisierung möglichst unabhängig voneinander sein, so dass Logik und Ablauf des Modells nicht mit der Visualisierung vermischt werden und so zu einem schlecht wartbaren Modell führt. 4

9 1.4. Aufbau der Arbeit Abbildung 1.2.: Visualisierung Weiterhin soll dieser Ansatz es ermöglichen, Visualisierung und Modell zeitlich oder räumlich versetzt auszuführen. Dies ist wünschenswert, damit z.b. Abläufe des Modells protokolliert und auch zu späteren Zeitpunkten noch visualisiert werden können. Dies ermöglicht es, Auswirkungen von Änderungen im Modell visuell nachvollziehen zu können. Die Möglichkeit, das laufende Modell über die Visualisierung nachhaltig zu beeinflussen, soll bei diesem Ansatz nicht gegeben werden. Es wird von einem selbständig laufenden Modell ausgegangen, welches die für die Visualisierung benötigten Daten bereitstellt. Neben den bereits genannten Anforderungen an die Kopplung von Visualisierung und Modell, ist es auch notwendig, die Visualisierung möglichst effizient zu gestalten, damit Abläufe innerhalb des Modells mit einer möglichst kleinen Verzögerung visuell dargestellt werden und somit gut nachvollziehbar sind. Um desweiteren die für die Erstellung einer Visualsierung benötigte Zeit zu kürzen, sollen die benötigten 3D Elemente unabhängig von dem zugrunde liegenden Modell sein, um so einen hohen Wiederverwendungsgrad dieser Elemente zu erhalten Aufbau der Arbeit In Kapitel 2 werden zunächst der Arbeit zugrunde liegende Techniken und Überlegungen erläutert. Der in der vorliegende Arbeit entwickelte Ansatz, UML Modelle generisch zu visualisieren, wird dann in Kapitel 3 erläutert. Die notwendige Unterstützung durch einen Plugin für die Fujaba Umgebung [6] wird dann in Kapitel 4 beschrieben. 5

10

11 Kapitel 2. Grundlagen 2.1. Visualisierungen Visualisierungen lassen sich zunächst einmal daran klassifizieren, ob sie in das zugrunde liegende Modell eingreifen oder nicht. Ein weiteres Kriterium für die Einteilung von Visualisierungen ist die verwendete Art der Darstellung, ob sie zwei- oder dreidimensional gestaltet ist. Bei dreidimensionalen Darstellungen wird üblicherweise immer eine sogenannte Szene dargestellt. Sie besteht aus mehreren Objekten, die unterschiedliche Eigenschaften wie Position, Farbe und Transparenz besitzen. Für die dreidimensionale Visualisierung in Java gibt es zwei Möglichkeiten. Zum einen kann OpenGL [1] verwendet werden. OpenGL ist eine weit verbreitete und in mehreren Programmiersprachen verfügbare API zur Darstellung von 3D Szenen. Um mittels OpenGL eine solche 3D Szene darzustellen, muss der Benutzer der API selbst die Objekte der Szene positionieren und an die Hardware übermitteln. In Java 3D [7] wird dem Benutzer der API ein Grossteil dieser Arbeiten abgenommen. Hier werden alle Bestandteile der darzustellenden 3D Szene in einer Baumstruktur, dem Scenegraphen, verwaltet. Dieser Scenegraph ist nach dem Composite Pattern [2] entworfen worden. Container in dieser Struktur dienen der Anordnung und Positionierung ihrer Kindknoten. Darzustellende Objekte werden in diesen Scenegraph als Blätter eingefügt. Die Bestandteile des Java 3D Scenegraph werden im Folgenden als 3D Elemente bezeichnet. Darüberhinaus bietet Java 3D die Möglichkeit, bestimmte Eigenschaften der 7

12 Kapitel 2. Grundlagen 3D Elemente wie z.b. ihre Position zu interpolieren. In Abbildung 2.1 ist der Scenegraph des Shuttles aus der Beispielvisualisierung dargestellt. Der TransformGroup Container bestimmt die Position des Shuttles in der 3D Szene. Für die drei Bestandteile eines Shuttles gibt es dann jeweils eine Instanz vom Typ Shape3D, welche in Java 3D Form und Aussehen eines Objektes kapselt. Jede dieser Teilobjekte hat dann eine eigene Form (Klasse Geometry) und ein eigenes Aussehen (Klasse Appearance). Abbildung 2.1.: Beispiel eines Java 3D Scenegraphs 2.2. Modelltypen Nach F. Meelamklavil [4] ist ein Modell eine vereinfachte Sicht eines Systems. Diese Systeme lassen sich in zwei Klassen einteilen. Zum einen gibt es diskrete Systeme, also solche, deren Werte und Eigenschaften sich nur in diskreten Schritten verändern. Zum anderen gibt es kontinuierliche Systeme, das sind solche, deren Werte und Eigenschaften sich kontinuierlich verändern. Diese Einteilung in diskrete und kontinuierliche Systeme zeigt sich dann auch bei den Modellen dieser Systeme. So gibt es sowohl diskrete Modelle, bei denen Änderungen als eine Folge einzelner Events angesehen werden, also auch kontinuierliche Modelle, bei denen Änderungen nicht schrittweise, sondern fortlaufend geschehen. 8

13 2.2. Modelltypen Will man nun ein Modell für einen digitalen Rechner erstellen, ist dieses Modell aufgrund der Eigenschaften des verwendeten Rechners grundsätzlich diskret. Will man dennoch ein kontinuerliches Modell erstellen, so ist man gezwungen, dieses zu approximieren, indem z.b. mathematische Darstellungen dieser Änderungen an diskreten Punkten ausgewertet werden. Für diese Arbeit bedeutet dies, dass man annehmen kann, dass Änderungen im Modell als diskrete Folge vorliegen, also auch als solche erfasst werden können. Stellt diese Folge jedoch eine Näherung einer kontinuierlichen Änderung dar, sollte es möglich sein, dies zu berücksichtigen, also z.b. die Möglichkeit zu bieten, in der Visualisierung diese Änderungen durch geeignete Mittel zu approximieren. 9

14

15 Kapitel 3. Architektur In diesem Kapitel wird der in dieser Arbeit entwickelte Ansatz zur generischen Visualisierung eines UML Modells vorgestellt. Wie in Abbildung 3.1 ersichtlich, basiert er darauf, zwischen die Visualisierung und das Modell ein Framework einzufügen, welches im Modell auftretende Events erfasst und an die Visualisierung weitergibt. Da bei dieser Architektur nur zwischen Visualisierung und Framework eine enge Verbindung besteht, ist es somit möglich, Visualisierung und Modell zeitlich und räumlich voneinander zu entkoppeln. Im Folgenden sollen Abbildung 3.1.: Überblick über die Architektur nun zunächst getroffene Annahmen über das Modell erläutert werden. Danach wird dann der Aufbau der Visualisierung dieses Modells und der Aufbau des Frameworks dargelegt Modell Um den Entwurf des Frameworks und der Visualisierung zu vereinfachen, wurden einige Annahmen über das zu visualisierende Modell getroffen. Sie wurden sorgfältig derart gewählt, dass sie in vielen Modellen üblicherweise erfüllt sind. So liegt den weiteren Betrachtungen der Architektur die Annahme zugrunde, dass die für die Visualisierung relevanten Informationen als 11

16 Kapitel 3. Architektur Attribute oder Assoziationen im Modell vorhanden sind. So ist die Position eines Shuttles in der Beispielsimulation beispielsweise als Matrix vorhanden, obwohl dies für die eigentliche Simulation nicht unbedingt notwendig ist. Desweiteren wird davon ausgegangen, dass sich Instanzen des Modells bei ihrer Erstellung bei einer zentralen Komponente an- und bei ihrer Löschung wieder abmelden können. Wie in Abschnitt 4.2 beschrieben, wird dies für den Ersteller des Modells transparent während der Codegenerierung in das Modell eingefügt. Um die Ankopplung des Frameworks möglichst einfach zu gestalten, wird angenommen, dass die Möglichkeit besteht, mittels eines Observer Mechanismus [2] über Änderungen von Attributen und Assoziationen informiert zu werden. Dies wird, wie ebenfalls im Abschnitt 4.2 beschrieben, während der Codegenerierung in das Modell eingefügt. Betrachtet man das Modell nun ausschliesslich über diese Änderungen von Assoziationen und Attributen, so stellt sich seine Laufzeit als Folge diskreter Zustände dar. Jeder dieser Zustände ist definiert durch die Menge der Instanzen, die vorhanden sind, die Werte ihrer Attribute und ihre Assoziationen Visualisierung Wie im vorherigen Abschnitt erläutert, lässt sich das zu visualisierende dynamische Modell zur Laufzeit als Folge diskreter Zustände auffassen. Es liegt daher nahe, auch die Visualisierung als Folge statischer Darstellungen anzusehen, wobei eine solche statische Darstellung einem Zustand des Modells entspricht und Änderungen des Zustandes im Modell eine Änderung der statischen Darstellung nach sich ziehen. Dies entspricht zum Beispiel auch der in Kapitel 2.1 erläuterten Herangehensweise bei aufwendigen 3D Visualisierungen. Um einen solchen Zustand des Modells korrekt darstellen zu können, müssen die in diesem Zustand vorhandenen Instanzen, die Werte ihrer Attribute und die Werte ihrer Assoziationen in der Visualisierung berücksichtigt werden. Um dies zu erreichen, wird jeder Instanz des Modells genau eine graphische Darstellung zugeordnet, welche im Folgenden als Visualisierungselement dieser Instanz bezeichnet wird. 12

17 3.2. Visualisierung Dieses Visualisierungselement wiederum besteht aus einem oder mehreren Elementen des Java 3D Scenegraph, die die eigentliche Darstellung der Instanz ausmachen. Eigenschaften dieser Elemente wie z.b. Farbe, Position oder Transparenz, werden im Folgenden einfach als Eigenschaften des Visualisierungselementes bezeichnet. Desweitern ergibt sich aus den Eigenschaften des Java 3D Scenegraph, dass diese Elemente hierarchisch angeordnet sind, jedes Visualisierungselement also ein Wurzelelmenent hat, welches alle anderen Elemente des Java 3D Scenegraph enthält. Um nun die Attribute einer Instanz darzustellen, wird jedem Attribut der Instanz eine Eigenschaft des Visualisierungselementes dieser Instanz zugeordnet. Da sich der Wert eines Attributes in einem Zustand des Modells nicht verändert, kann ausgehend von dem Wert des Attributes der feste Wert der Eigenschaft des Visualisierungselementes eindeutig bestimmt werden. Für die Darstellung einer Assoziation wiederum wird auf die Visualisierungselemente der an ihr beteiligten Instanzen zurückgegriffen. Da Assoziationen Beziehungen zwischen Instanzen modellieren, werden sie durch die Anordnung der Visualisierungselemente der beteiligten Instanzen dargestellt. Hierfür besitzt jedes Visualisierungselement für jede darzustellende Assoziation einen Slot. Dieser Slot wird dazu benutzt, um die Visualisierungselemente untereinander anzuordnen, indem sie zu diesen Slots hinzugefügt bzw. wieder entfernt werden. Hierfür wird jedem Slot ein Container des Java 3D Scenegraph zugeordnet. Wird nun ein anderes Visualisierungselement zu dem Slot hinzugefügt, wird dessen Wurzelelement zu den Kindern dieses Containers hinzugefügt. Bei diesem Aufbau enthalten die Visualisierungselemente alle Informationen über die Darstellung einer Instanz des Modells. Es ist daher möglich, durch einen Austausch der Visualisierungselemente eine andere Darstellung des Modells zu erhalten, ohne das Modell selber verändern zu müssen. Desweiteren werden die 3D Elemente nie direkt, sondern nur mittels des Visualisierungselementes, welches sie enthält, modifziert. Hierdurch wird es möglich, diese 3D Elemente wiederzuverwenden, da sie keine modellspezifischen Informationen enthalten. Weiterhin wird dadurch die Erstellung der Visualisierung vereinfacht, 13

18 Kapitel 3. Architektur da sie aus einzelnen, in sich geschlossenen Einheiten aufgebaut ist, bei deren Erstellung immer nur eine Klasse des Modells betrachtet werden muss. Um nun Änderungen des Zustandes des Modells verarbeiten zu können, wird eine Verwaltungskomponente für die Visualisierung eingeführt. Diesem VisualisationManager ist bekannt, welches Visualisierungselement welcher Instanz des Modells zugeordnet ist. Er ist daher in der Lage, für eine neue Instanz im Modell das dazugehörige Visualisierungselement zu erzeugen und es beim Löschen der Instanz auch wieder zu entfernen. Desweiteren ist er dadurch in der Lage, bei Änderungen von Assoziationen die Visualisierungselemente derart anzuordnen, dass sie der geänderten Assoziation entsprechen. Einzig die Änderungen von Attributen können nicht von ihm verarbeitet werden, da hierfür eine Kenntnis der Graphikelemente eines Visualisierungselementes notwendig ist, so dass diese von dem jeweiligen Visualisierungselement selber verarbeitet werden müssen. Zur Verdeutlichung sind in Abbildung 3.2 einige Visualisierungselemente der Beispielsimulation schwarz umrandet dargestellt. Es ist gut zu sehen, dass den Klassen der Beispielsimulation, deren Instanzen visualisiert werden sollen, jeweils ein Visualisierungselement zugeordnet wird, welches dann die Elemente des Java 3D Scenegraph enthält, die zur Darstellung notwendig sind. Gut zu sehen ist auch, dass das Visualisierungselement der Order Instanz unter dem Visualisierungselment der Shuttle Instanz angeordnet ist, um so die carries Assoziation dieser beiden Instanzen darzustellen. Abbildung 3.2.: Visualisierungselemente der Beispielsimulation 14

19 3.3. Framework Um den derart erstellten Java 3D Scenegraph dann auf dem Bildschirm ausgeben zu können, wird ein Viewer bereitgestellt. Er bietet dem Benutzer die Möglichkeit, in der 3D Welt zu navigieren Framework Nachdem in den vorherigen beiden Abschnitten zunächst erläutert wurde, welche Annahmen über das zugrunde liegende UML Modell gemacht werden und wie die Visualisierung dieses Modells aufgebaut ist, soll nun darauf eingegangen werden, wie das dazwischenliegende Framework konstruiert ist Aufbau Wie aus den voherigen Abschnitten hervorgeht, muss das Framework in der Lage sein, drei verschiedene Arten von Änderungen an die Visualisierung weiterzureichen. Hierbei müssen Änderungen an der Menge der vorhandenen Instanzen und Änderungen an Assoziationen an den VisualisierungsManager weitergeleitet werden, da sie von ihm verarbeitet werden. Änderungen von Attributen hingegen müssen an ein bestimmtes Visualisierungselement gesendet werden, da sie nur von diesem verarbeitet werden können. Um diesen Anforderungen zu genügen, stellt das Framework, wie in Abbildung 3.3 ersichtlich, zwei Klassen zur Verfügung, den ModelManager und den SmartBuffer. Der SmartBuffer ist hierbei einer Instanz des Modells zugeordnet, erfasst Änderungen der Attribute dieser Instanz und leitet sie an das passende Visualisierungselement weiter. Der ModelManager hingegen ist keiner einzelnen Instanz zugeordnet, sondern erfasst alle im Modell enthaltenen Instanzen, sowie deren Assoziationen und informiert den VisualisationManager über deren Änderungen sowie neu erstellte oder gelöschte Instanzen des Modells. Desweitern wird der ModelManager von den Visualisierungselementen benutzt, um für eine Instanz des Modells einen SmartBuffer zu erzeugen. Wie in Abbildung 3.4 zu sehen, geschieht dies während der Initialisierung eines Visualisierungselementes. Nachdem der VisualisationManager das Visualisierungselement erzeugt hat, weist er es einer Instanz 15

20 Kapitel 3. Architektur Abbildung 3.3.: Detailliertes Architekturdiagramm des Modells zu (Aufruf attach()). Hierbei erstellt das Visualisierungselement einen SmartBuffer für die darzustellende Instanz (Aufruf createbuffer(). Hiernach werden die von dem Visualisierungselement benötigten Attribute der Instanz des Modells an den Smart- Buffer kommuniziert. Sind dem SmartBuffer alle Attribute mitgeteilt worden, wird er als Observer [2] der Instanz des Modells zugeordnet und beginnt mit der Erfassung und Übermittlung von Änderungen der Attribute dieser Instanz. Abbildung 3.4.: Erstellung und Initialisierung eines Visualisierungselementes Stellt ein SmartBuffer eine Änderung der von ihm überwachten Attribute fest, initiiert er eine Anpassung des zugeordneten Visualisierungselementes. Hierfür wird, wie in Abbildung 3.5 dargestellt, zunächst der UpdateManager darüber informiert, dass ein Visualisierungselement an Änderungen im Modell angepasst werden muss (Auf- 16

21 3.3. Framework ruf scheduleupdate ()). Der UpdateManager wiederum veranlasst dann eine Anpassung des Visualisierungselementes, indem die Methode updatevisualisationelement() des SmartBuffers aufgerufen wird. In dieser Methode wiederum teilt der SmartBuffer dem Visualisierungselement die Werte der geänderten Attribute mit (Aufruf attrchange ()), sodass dieses dann die ihm zugeordneten 3D Elemente an die geänderten Attribute anpassen kann. Abbildung 3.5.: Änderung eines Attributes Updatemechanismen Würde man für die Verarbeitung von Attributänderungen einen einfacheren Ansatz als den beschriebenen wählen, also immer direkt das Visualisierungselement benachrichtigen, würde es zu Performance Einbussen kommen. Diese Einbussen würden daher rühren, dass es keine Möglichkeit gäbe, zu kleine und somit gar nicht darstellbare Änderungen zu filtern, somit also viele Änderungen an das Visualisierungselement geleitet werden würden, die von ihm gar nicht sinnvoll verarbeitet werden können. Der in dieser Arbeit gewählte Ansatz bietet dagegen zwei Möglichkeiten, um dies zu verhindern. Bei Änderungen von Attributen im Modell werden zunächst nur die SmartBuffer über diese Änderungen informiert. Eine Anpassung des zugeordneten Visualisierungselementes findet nur statt, wenn sie explizit vom SmartBuffer beim UpdateManager angefordert wird. Dies ermöglicht es, Änderungen von Attributen zu filtern, um somit zu erreichen, dass nur die sinnvoll darstellbaren Änderungen an das Visualisierungselement weitergegeben werden. Dies lässt sich dann dazu benutzen, die Änderungen der Visualisierungselemente und somit ihrer 3D Elemente zu reduzieren, um dadurch die Performance zu steigern. 17

22 Kapitel 3. Architektur Die zweite Möglichkeit, die dieser Ansatz bietet, ist, dass der Smart- Buffer selbst entscheidet, welche Werte der Attribute bei einer Anpassung des Visualisierungselementes an dieses übermittelt werden. Es ist also durchaus möglich, hierbei die von Java 3D angebotenen Möglichkeiten zur Interpolation von Eigenschaften der 3D Elemente zu benutzen Betriebsmodi Bei der hier vorgestellten Architektur des Frameworks wird die Visualisierung nur indirekt mittels des Frameworks über Änderungen im Modell benachrichtigt. Dies bietet gegenüber dem einfacheren Ansatz, Visualisierung und Modell direkt miteinander zu verbinden, den Vorteil, Visualisierung und Modell voneinander entkoppeln zu können, ohne Änderungen an ihnen vornehmen zu müssen. Es ist vielmehr sogar möglich, die gewünschte Entkopplung vollständig zur Laufzeit zu wählen. Je nach gewählter Entkopplung befindet sich das Framework dann in einem von mehreren Betriebsmodi, wobei der konkrete Aufbau des Frameworks je nach Betriebsmodus leicht variieren kann. Diese Betriebsmodi lassen sich grob in drei verschiedene Arten einteilen, deren konkreter Aufbau im Folgenden geschildert wird. Im online synchronen Betriebsmodus ist der Aufbau, wie in Abbildung 3.6 dargestellt, identisch mit der generellen Architektur des Frameworks. In diesem Betriebsmodus werden Änderungen im Modell von SmartBuffer und ModelManager erfasst und direkt an die Visualisierung weitergegeben, sodass keine Entkopplung zwischen Visualisierung und Modell besteht. Das bedeutet, dass Änderungen im Modell verzögerungslos in der Visualisierung dargestellt werden, das Modell aber auch für den Zeitraum der Bearbeitung der Änderungen im Framework und in der Visualisierung blockiert ist. Dieser Modus kommt hauptsächlich zum Einsatz, wenn Visualisierung und Modell auf einem Rechner ausgeführt werden und die auftretende Blockierung im Modell vernachlässigbar ist. Eine leichte Abwandlung des online synchronen Betriebsmodus stellt der online asynchrone dar. In diesem Modus besteht eine zeitliche und möglicherweise eine räumliche Entkopplung von Visualisierung und Modell, sodass Veränderungen im Modell mit einer leichten Verzögerung in der Visualisierung dargestellt werden. Im Gegensatz zum vor- 18

23 3.3. Framework herigen Betriebsmodus ist das Modell aber nicht für die Dauer der Verarbeitung der Änderungen blockiert. Dieser Betriebsmodus kommt z.b. zum Einsatz, wenn die Visualisierung auf einem anderen Rechner als das Modell ausgeführt werden soll, um dadurch die für das Modell vorhandene Rechenkapazität zu erhöhen. Diese Entkopplung wird dadurch erreicht, dass die Änderungen im SmartBuffer und im Model- Manager gepuffert werden, bis sie an die Visualisierung weitergereicht werden. Hierzu besitzen sie einen begrenzten lokalen Datenspeicher, in dem im Modell auftretende Änderungen zunächst abgelegt werden. Die in diesem Speicher abgelegten Änderungen werden dann in der Reihenfolge ihres Auftretens von der Visualisierung verarbeitet. Der im Aufbau am meisten von der generellen Architektur abweichende Betriebsmodus ist der offline Betriebsmodus. Auch hier besteht, wie im online asynchronen Modus, eine zeitliche und räumliche Entkopplung von Visualisierung und Modell. Im Gegensatz dazu werden jedoch Änderungen im Modell nicht zur Laufzeit des Modells verarbeitet, sondern lediglich in einem Protokoll gespeichert. Dieses Protokoll kann dann zu einem beliebigen späteren Zeitpunkt ausgelesen und die darin gespeicherten Änderungen an die Visualisierung übermittelt werden. Um dies zu erreichen, werden die Änderungen, wie in Abbildung 3.7 dargestellt wie in den vorherigen Betriebsmodi vom SmartBuffer und vom ModelManager erfasst. Die erfassten Änderungen werden dann aber direkt in ein Protokoll eingetragen. Wird dann zu einem späteren Zeitpunkt die Visualisierung gestartet, wird dieses Protokoll, wie in Abbildung 3.8 ersichtlich, vom SmartBuffer und vom ModelManager ausgelesen und an die Visualisierung übermittelt. 19

24 Kapitel 3. Architektur Abbildung 3.6.: Framework im online Betriebsmodus Abbildung 3.7.: Modell im offline Betriebsmodus Abbildung 3.8.: Visualisierung im offline Betriebsmodus 20

25 Kapitel 4. Fujaba PlugIn Nachdem im vorherigen Kapitel erläutert wurde, wie die Visualisierung eines dynamischen Modells aufgebaut ist, soll nun in diesem Kapitel dargelegt werden, welche Funktionen der PlugIn für die Fujaba Umgebung bereitstellen muss um die für die Visualisierung benötigten Visualisierungselemente erstellen zu können. Wie in Abschnitt 3.2 erläutert, enthalten die Visualisierungselemente alle Informationen über die Darstellung einzelner Instanzen des Modells. Dies ermöglicht es, mit dem PlugIn diese Visualisierungselemente zu generieren und somit die gewünschte Darstellung zu erhalten. Im ersten Abschnitt dieses Kapitels wird daher geschildert, wie die Darstellung einer Instanz des Modells spezifiziert wird. Im darauffolgenden Abschnitt wird dann erläutert, wie anhand dieser Informationen der notwendige Code generiert wird. Als Abschluss wird die Umsetzung des PlugIns und seine Anbindung an die Fujaba Umgebung erklärt Spezifikation der Darstellung Eine der wichtigsten Funktionen ist die Auswahl der Klassen des Modells, deren Instanzen visualisiert werden sollen. Hierfür wurde, wie in Abbildung 4.1 dargestellt, ein neuer UML Stereotyp Displayable Object definiert. Wird er einer Klasse zugewiesen, wird für sie ein neues Visualisierungselement erzeugt. Um dann den Java 3D Scenegraph dieses Visualisierungselementes definieren zu können, bietet der Plugin die in Abbildung 4.2 dargestellte Oberfläche. Hier ist links der Scenegraph als Baum dargestellt, rechts sind die verfügbaren Eigenschaften des ausgewählten Elementes des Scenegraph aufgelistet. Desweiteren findet man im oberen Bereich eine Palette mit verfügbaren Komponenten, die in den Scenegraph eingefügt werden können. 21

26 Kapitel 4. Fujaba PlugIn Abbildung 4.1.: Stereotyp zur Auswahl von Klassen mit Visualisierungselement Abbildung 4.2.: Erstellung des Scenegraph eines Visualisierungselements 22

27 4.2. Codegenerierung In Abbildung 4.3 ist zu sehen, wie spezifiziert wird, welche Attribute der Instanz durch welche Eigenschaften des Visualisierungselementes dargestellt werden sollen. In der ComboBox auf der linken Seite sind alle Attribute der zugeordneten Instanz enthalten, in der auf der rechten Seite dagegen alle Eigenschaften der Elemente des Scenegraphen. Durch Auswahl von Einträgen dieser beiden ComboBoxen kann nun spezifiziert werden, welches Attribut durch welche Eigenschaft des Scenegraphen dargestellt werden soll. Auf ähnliche Weise arbeitet auch die Oberfläche für die Definition der Slots eines Visualisierungselementes, die in Abbildung 4.4 zu finden ist. Auf der linken Seite findet sich wieder eine ComboBox, die alle Assoziationen enthält, an denen die zugeordnete Instanz beteiligt sein kann, auf der rechten Seite eine, in der alle Container des Java 3D Scenegraph aufgelistet sind. Auch hier kann wieder durch Auswahl der Einträge der beiden ComboBoxen spezifiziert werden, welcher Slot welcher Assoziation entspricht. Abbildung 4.3.: Zuweisung von Instanzattributen zu Eigenschaften 4.2. Codegenerierung Die im Plugin enthaltene Codegenerierung muss sowohl Code für die Visualisierungselemente erzeugen, als auch dafür sorgen, dass die im Abschnitt 3.1 aufgeführten Modellannahmen erfüllt werden. 23

28 Kapitel 4. Fujaba PlugIn Abbildung 4.4.: Zuordnung von Assoziationen zu Java 3D Containern Für jedes der Visualisierungselemente wird hierbei eine eigene Klasse erzeugt, die alle von der Visualisierung und vom Framework benötigten Methoden enthält. Für jede dieser Methoden wiederum wird ein Aktivitätendiagramm generiert, welches dann von dem in Fujaba enthaltenen Subsystem für die Codegenerierung verarbeitet und in Java Code umgewandelt wird. Als Beispiel hierfür ist in Abbildung 4.5 das Aktivitätendiagramm eines Konstruktors gegeben. Er gehört zu dem Visualisierungselement der Curve Klasse des laufenden Beispiels. Wie zu sehen ist, werden zunächst die einzelnen Elemente des Java 3D Scenegraph instanziiert. Daraufhin werden die Eigenschaften dieser Elemente auf die eingestellten Defaultwerte gesetzt und die notwendigen Berechnungen durchgeführt (Aufruf updategeometry()). Um die in Abschnitt 3.1 beschriebene Annahme zu erfüllen, dass Änderungen von Assoziationen und Attributen mittels eines Observer Mechanismus erfasst werden können, wurde der von Michael Kisker in seiner Diplomarbeit [3] erstellte Support für Java Beans an die aktuelle Version von Fujaba angepasst. Hierdurch wird es möglich, über den Stereotyp Java Bean zu spezifizieren, dass eine Klasse ein Observable ist, dass also bei Verändungen ihrer Attribute und Assoziationen entsprechende Benachrichtigungen versendet werden (ebenfalls zu sehen in Abbildung 4.1). Für die notwendige Registrierung von neu erstellten bzw. gelöschten Instanzen schliesslich wird eine eigene Erweiterung für die Fujaba Codegenerierung bereitgestellt. Sie fügt zum Konstruktor und Destruktor von Klassen mit Visualisierungselement die notwendigen Methodenaufrufe hinzu, damit neu erzeugte oder gelöschte Instanzen beim 24

29 4.3. Umsetzung Abbildung 4.5.: Aktivitätendiagramm des Konstruktors eines Visualisierungselementes Framework an- und auch wieder abgemeldet werden Umsetzung In der Fujaba Umgebung [6] besteht die Möglichkeit, PlugIns zu erstellen, die dann beim Start der Umgebung automatisch geladen werden. Dies vereinfacht zum einen eine Erweiterung der Funktionalität der Umgebung selbst, zum anderen wird es dadurch möglich, auf UML Diagramme zuzugreifen, die in der Umgebung selber erstellt und verarbeitet werden können. Im Rahmen dieser Arbeit wurde diese Möglichkeit dann dazu benutzt, um die Entwurfsunterstützung zu implementieren. Um die beschriebene Funktionalität bereitstellen zu können, wird im PlugIn ein Metamodell der einzelnen Visualisierungselemente und ihrer Verbindung zu den Klassen des Modells verwendet. Für die Verbindung des Metamodells des PlugIns zu den Klassen des Modells wird der von Fujaba bereitgestellte Mechanismus zur Erweiterung des Fujaba internen Metamodells benutzt. Dieser Mechanismus besteht 25

30 Kapitel 4. Fujaba PlugIn im wesentlichen aus den in Abbildung 4.6 dargestellten Klassen. Die Klasse ASGElement ist die Superklasse aller Elemente des Fujaba Metamodells. Ihr können mehrere Instanzen vom Typ ASGElementRef zugeordnet werden, wobei diese Instanzen über den Namen ihrer Klasse eineindeutig identifiziert sind. Um nun in einem PlugIn eigene Informationen mit einem Element des Fujaba Metamodells zu verknüpfen, muss eine eigene Klasse von ASGElementRef abgeleitet werden und zu der elementrefs Assoziation hinzugefügt werden. Abbildung 4.6.: Erweiterungsmechanismus des Fujaba Metamodells Über diesen Mechanismus wird dann auch das Metamodell des Plug- Ins mit dem Metamodell von Fujaba verbunden. Wie in Abbildung 4.7 zu sehen, ist die Klasse VisElementList von der Klasse ASGElementRef abgeleitet und kann so mit der Klasse UMLClass des Fujaba Metamodells verbunden werden. Die Klasse VisElementList modelliert somit die Liste der Visualisierungselemente, die einer Klasse des Modells zugeordnet sind. Über die elements Assoziation werden dieser Liste die einzelnen Visualisierungselemente zugeordnet, jeweils dargestellt durch eine Instanz des Typs DesignVisElement. Für die Modellierung des Scenegraph des Visualisierungselementes wird die Klasse DisplayTree benutzt. Sie enthält eine nach dem Composite Pattern designte Struktur, die dem Scenegraph des zu generierenden Visualisierungselementes entspricht. In dieser Struktur werden Komponenten des Scenegraph durch Instanzen vom Typ DisplayTreeComponent und Container durch Instanzen vom Type DisplayTreeContainer modelliert. Die Liste aller von dem Visualisierungselement dargestellten Attribute ist in der Klasse PropertyMappingList enthalten. Die Zuordnung eines einzelnen Attributes der Modellklasse zu einer Eigenschaft eines der 3D Elemente wird in Instanzen vom Typ PropertyMapping gespeichert. Für die Liste aller dargestellten Assoziationen gibt es analog die Klasse SlotList. Sie enthält mehrere Instanzen vom Typ Slot, welche je- 26

31 4.3. Umsetzung weils die Informationen über eine dargestellte Assoziation enthalten. Abbildung 4.7.: Metamodell des Fujaba PlugIns Dieses Metamodell enthält somit alle Informationen, die benötigt werden, um ein entsprechendes Visualisierungselement zu generieren. 27

32

33 Kapitel 5. Zusammenfassung und Ausblick In dieser Arbeit wurde das Problem behandelt, die Erstellung einer 3D Visualisierung für ein bestehendes, dynamisches UML Modell zu vereinfachen. Hierfür wurde zunächst der Aufbau der Visualisierung selber vorgestellt, der es ermöglicht, auf effiziente Weise die 3D Elemente der Darstellung an Änderungen im Modell anzupassen. Zudem ermöglicht es dieser Aufbau, die verwendeten 3D Elemente wiederzuverwenden, da sie keine modellspezifischen Informationen enthalten. Dadurch wiederum wird es möglich, Bibliotheken von 3D Elementen zu erstellen, die dann in verschiedensten Visualisierungen verwendet werden können. Desweiteren ermöglicht der vorgestellte Aufbau die Verwendung von fertigen 3D Modellen, die mittels eines professionellen Modellierungs Tools erstellt wurden. Als nächstes wurde ein Framework für die Ausführung der Visualisierung entwickelt. Dieses Framework bietet die Möglichkeit, Visualisierung und Modell voneinander zu entkoppeln, um z.b. die Visualisierung auf einem anderen Rechner als das Modell ausführen zu können. Die Flexibilität des Frameworks ermöglicht z.b. auch eine Anbindung an Echtzeitsysteme, da durch die vorgestellten Mechanismen die zeitliche Verzögerung, die durch die Visualisierung im Modell entsteht, verringert werden kann. Schliesslich wurde dann der PlugIn für die Fujaba Umgebung vorgestellt, welcher die Möglichkeit bietet, die Verbindung zwischen Modell und Visualisierung graphisch zu spezifizieren und den dafür notwendigen Code generiert. Hierdurch wird es ermöglicht, in einer geschlos- 29

34 Kapitel 5. Zusammenfassung und Ausblick senen Umgebung sowohl das Modell als auch dessen Visualisierung zu erstellen. Bei der vorgestellten Architektur sind lediglich die Visualisierungselemente an das verwendete Toolkit, hier Java 3D, gekoppelt. Dadurch kann das vorgestellte Framework unverändert auch für eine Visualisierung mittels eines anderen Toolkits, z.b. OpenGL, verwendet werden. Da die Visualisierungselemente vollständig durch den PlugIn generiert werden, müsste hierfür die Codegenerierung des PlugIns entsprechend erweitert werden. Desweiteren kann man über den vorgestellten SmartBuffer die eingangs erwähnten Näherungen kontinuierlicher Änderungen im Modell auf die Visualisierung anpassen. So können unterschiedliche Näherungsverfahren implementiert werden, um dadurch die Genauigkeit und Leistungsfähigkeit der Visualisierung weiter zu verbessern. 30

35 Anhang A. Anwendung am Beispiel In diesem Abschnitt soll die Verwendung des PlugIns zur Erstellung einer Visualisierung anhand der in Kapitel 1.2 vorgestellten Beispielsimulation erläutert werden. Hat man mit Fujaba das Klassendiagramm erzeugt, und insbesondere mit Hilfe des Stereotypen festgelegt, welche Klassen des Modells eine graphische Darstellung besitzen, wird, wie in Abbildung A.1 zu sehen, links eine Baumdarstellung dieser Klassen angezeigt. In dieser Darstellung befindet sich desweiteren eine Liste aller Visualisierungselemente einer Klasse, jeweils unter dem element -Knoten angeordnet. Wählt man eines der Visualisierungselemente in der Baumdarstellung aus, so wird rechts, wo sonst die UML Diagramme von Fujaba zu sehen sind, die GUI eingeblendet, die es, wie in Kapitel 4.1 beschrieben, ermöglicht, die graphische Darstellung zu spezifizieren. Die einzelnen Bestandteile können durch die Anwahl des entsprechenden Reiters ausgewählt werden. Um für die spezifizierten Visualisierungselemente Code zu generieren, steht das in Abbildung A.3 aufgeführte Menü zur Verfügung. Wählt man diesen Menüpunkt an, generiert der PlugIn die einzelnen Visualisierungselemente und fügt sie in das Fujaba Metamodell ein. Hierfür werden, wie in Abbildung A.4 zu sehen, alle Visualisierungselemente in ein Klassendiagramm VisualisationClassDiagram eingefügt und können so in Fujaba angezeigt und editiert werden. Desweiteren wird, wie erläutert, während der Codegenerierung ein Aktivitätendiagramm für die einzelnen Methoden eines Visualisierungselementes erstellt. Diese Diagramme werden dann von Fujaba in der Auflistung A

36 Anhang A. Anwendung am Beispiel Abbildung A.1.: Klassendiagramm und Liste aller Visualisierungselemente aller Aktivitätendiagramme mit aufgeführt. Sind nun auf diese Weise alle Visualisierungselemente erzeugt worden, kann man mittels des in Abbildung A.5 dargestellten Menüs das Modell zusammen mit der Visualisierung ausführen. Zunächst wird dazu mittels des Menüpunktes Export All Classes To Java für alle Klassen, die im Fujaba Metamodell enthalten sind, also auch die generierten Visualisierungselemente, Java Sourcecode erzeugt. Hiernach kann dann mit Compile Java Sources und Run Project das Modell zusammen mit der Visualisierung ausgeführt werden. B

37 Abbildung A.2.: Oberfläche des PlugIns Abbildung A.3.: Menü für die Generierung der Visualisierungselemente C

38 Anhang A. Anwendung am Beispiel Abbildung A.4.: Klassendiagramm aller Visualisierungselemente Abbildung A.5.: Menü für die Codegenerierung D

39 Abbildungsverzeichnis 1.1. Klassendiagramm der Beispielsimulation Visualisierung Beispiel eines Java 3D Scenegraphs Überblick über die Architektur Visualisierungselemente der Beispielsimulation Detailliertes Architekturdiagramm Erstellung und Initialisierung eines Visualisierungselementes Änderung eines Attributes Framework im online Betriebsmodus Modell im offline Betriebsmodus Visualisierung im offline Betriebsmodus Stereotyp zur Auswahl von Klassen mit Visualisierungselement Erstellung des Scenegraph eines Visualisierungselements Zuweisung von Instanzattributen zu Eigenschaften Zuordnung von Assoziationen zu Java 3D Containern Aktivitätendiagramm des Konstruktors eines Visualisierungselementes Erweiterungsmechanismus des Fujaba Metamodells Metamodell des Fujaba PlugIns A.1. Klassendiagramm und Liste aller Visualisierungselemente A.2. Oberfläche des PlugIns A.3. Menü für die Generierung der Visualisierungselemente. A.4. Klassendiagramm aller Visualisierungselemente..... A.5. Menü für die Codegenerierung B C C D D E

40

41 Literaturverzeichnis [1] OpenGL: The Industry s Foundation for High Performance Graphics. [2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley, [3] M. Kisker. UML basierte Spezifikation von Benutzerschnittstellen. Master s thesis, University of Paderborn, Department of Mathematics and Computer Science, Paderborn, Germany, October [4] F. Meelamkavil. Computer Simulation and Modelling. John Wiley & Sons, [5] Object Management Group. OMG Unified Modeling Language Specification, Version 1.4, September OMG document ad/ [6] Software Engineering Group, University of Paderborn. Fujaba: From UML to Java and Back again. [7] Sun Microsystems. Java3D API Specification, Version 1.3, June G