Entwurf und Implementierung eines datenbankgestützten Monitoringsystems für Artificial Life -Szenarien

Transkript

1 Rheinische Friedrich-Wilhelms-Universität Institut für Informatik III Diplomarbeit Entwurf und Implementierung eines datenbankgestützten Monitoringsystems für Artificial Life -Szenarien Bento Philipose 30. September 2008 Erstgutachter: Prof. Dr. Rainer Manthey Zweitgutachter: Prof. Dr. Andreas Weber

2

3

4

5 Inhaltsverzeichnis 1 Einleitung Grundlagen aus dem Anwendungsgebiet Artificial Life Zelluläre Automaten Elementare Bestandteile Klassifikation nach Verhalten Game of Life Monitoring diskreter Prozesse Clustering Mustererkennung Trajektorienbestimmung Kollisionserkennung Grundlagen der verwendeten Technologien Relationaler Datenbankentwurf Konzeptueller Entwurf Logischer Entwurf SQL Standard SQL JET SQL JDBC und SWING JDBC SWING Datenbankentwurf Problemdefinition und Anforderungsanalyse Entity-Relationship-Schema Relationales Schema Architektur und Funktionalität Architektur Funktionalitäten und GUI i

6 6 Ausgewählte Aspekte der Implementierung Game of Life-Umsetzung Evolution Clustering Clusterverbände Mustererkennung Trajektorienbestimmung Kollisionserkennung Zusammenfassung und Ausblick Literaturverzeichnis ii

7 1 Einleitung Seit dem Anbeginn von Raum und Zeit laufen Prozesse im Universum ab. Sie erzeugen Ereignisse, die Zustandsveränderungen beinhalten und als Reaktion im Sinne von Ursache und Wirkung - weitere Ereignisse anstoßen. Aber wie oder zunächst was soll die Ereignisse, welche für sich ein breites Spektrum bilden, registrieren und ferner interpretieren? Nach unserem bisherigen Kenntnisstand, sind wir selbst die Ersten gewesen, die die Erscheinungen der Ereignisse zu deuten versuchten und daraus Schlussfolgerungen zu ziehen. Die Gattung Mensch ist wahrscheinlich das erste Monitoringsystem des Universums, das die Ereignisse systematisch durch Beobachtungen erfasste und auf seine Weise (sei es zeichnerisch, mündlich oder schriftlich) protokollierte. Das Monitoring wurde im Laufe der Zeit mehr und mehr von Hardware- und Softwaresystemen übernommen, wodurch Erfassungsprozesse automatisiert und Menschen von Routineaufgaben entlastet wurden. Man denke hierbei exemplarisch an die Einführung von intelligenten Verkehrsampeln, die anhand des Verkehrsaufkommens variable Ampelschaltungen vornehmen. Das Monitoring bezeichnet die Überwachung eines Prozesses mittels der zu Verfügung stehenden sensorischen Hilfsmittel. Darüber hinaus bedeutet Monitoring, die innerhalb des Prozesses stattfindenden Ereignisse zu bemerken, zu analysieren und falls nötig auf Grundlage der vorliegenden Ergebnisse aktiv einzugreifen. Ereignisse stellen für ein Monitoringsystem Inputdaten dar, die im Rahmen der Verarbeitung auf die notwendigsten Charakteristika gefiltert und validiert werden. Monitoring wird in vielen Bereichen betrieben wie etwa im Finanz-, Gesundheits- oder Sicherheitswesen. Auch in vielen Naturwissenschaften wird Monitoring zur Gewinnung von Daten und Wissen über die zu untersuchenden Sachverhalte durchgeführt, um die aufgestellten Hypothesen zu überprüfen. Eine der praktischen Anwendungen des Monitorings dient zum Beispiel zur Erfassung von Near Earth Objects *Nas08+, also von Himmelskörpern wie Asteroiden, Kometen und größeren Meteoriten, die sich der Erde signifikant nähern und damit ein Impact-Risiko darstellen. Erfasst werden die potenziell gefährlichen Objekte im Rahmen des Spaceguard Survey - Programms im visuellen Bereich anhand umfassender teleskopischer Suche des unmittelbar umgebenden Weltraums. Für jedes dieser Anwendungsgebiete sind die einzusetzenden Monitoringsysteme speziell auf dieses Gebiet auszurichten und erfordern Vorkenntnisse über das Zielgebiet bzw. -system. Meistens besteht ein Monitoringsystem aus mehreren Komponenten, die auf verschiedene Ereignistypen spezialisiert sind. Diese Monitoringkomponenten müssen koordiniert ablaufen, insbesondere wenn eine Komponente auf den Analysedaten der anderen aufbaut. Die Monitoringkomponenten sind auch modular aufzubauen, da nicht jeder Aspekt des zu untersuchenden Sachverhalts gleichzeitig erfasst werden muss, so dass nicht notwendige Komponenten, für eine effiziente Verteilung der Systemressourcen, deaktiviert werden können. Eine adäquate Präsentationsform der resultierenden Ergebnisse ist ein wichtiger Faktor bei der Modellierung des Monitoringsystems. Denn der Zweck des Monitoring ist das Schlussfolgern auf Grundlage der erfassten Daten, welche dann letztendlich für Reaktionsmaßnahmen dem Empfänger oder Betrachter übermittelt werden müssen. Ein Mensch kann zu einem Zeitpunkt nur eine 1

8 begrenzte Menge an Information wahrnehmen und verarbeiten. Diesbezüglich ist es wichtig, je nach zur Verfügung stehender Zeit für die darzustellenden Daten zur besseren Informationsaufnahme verschiedene Abstraktionsniveaus kombiniert mit visuellen Effekten anzubieten, die besonders bei Echtzeitanwendungen von Relevanz sein könnten. Bevor Monitoringsysteme auf kritischer Ebene in einem realen Anwendungsgebiet eingesetzt werden können, müssen die Prototypen auf ihre Korrektheit und Zuverlässigkeit überprüft werden. Insbesondere in der Entwicklungsphase müssen Testdaten als Input zur Verfügung gestellt werden, die die Ereignisse der realen Welt soweit wie möglich approximieren sollen. Dazu sind künstliche Monitoringszenarien mittels eines Simulators zu erzeugen, der innerhalb einer kontrollierbaren Rahmenbedingung die gewünschte Abfolge von Ereignissen liefert. In der realen Umgebung müssen die Daten explizit durch Sensoren erfasst und in die für Monitoringkomponenten bearbeitbare Form transformiert werden. Bei Verwendung eines Simulators liegen die Daten unmittelbar vor, wodurch dessen Konfigurierbarkeit es ermöglicht, die gewünschten Aspekte zu simulieren und sich auf entscheidende Faktoren zu konzentrieren. Ein Simulator kommt besonders für Nachstellungen kritischer Szenarien zum Einsatz, die in der Realität zu gefährlich oder kostenintensiv wären (z.b. Triebwerksausfall oder Notlandungen bei Flugzeugen; Tests von neuen Raumfahrzeugen). In Rahmen dieser Diplomarbeit soll ein datenbankgestütztes Monitoringsystem entworfen und implementiert werden. Das System soll unter dem Namen MONALISA getauft werden, der als Abkürzung für Monitoringsystem for Artificial Life Scenarios dient. Im Mittelpunkt steht der Einsatz von relationaler Datenbanktechnologie, die sowohl bei der Verwirklichung der Monitoringkomponenten als auch des Simulators ihre Anwendung findet. Der zentrale Kommunikationsknotenpunkt des Gesamtsystems MONALISA wird das relationale Datenbankmanagementsystem (DBMS) sein, durch das die Datentransfers zwischen dem Simulator und Monitor vorgenommen werden, die auch letztendlich die Verlagerung der primären Verarbeitungslogik in die Datenbank ermöglichen. Hierbei wird das relationale Datenbankmanagementsystem (DBMS) als Inferenzmaschine zum Herleiten von logischen Ereignissen aus Simulationsdaten genutzt. Als künstliches Szenario wird hierbei die Theorie der zellulären Automaten aus der Forschungsrichtung Artificial Life gewählt, die viele Gemeinsamkeiten mit realen Monitoringanwendungen aufzeigt. Allgemein handelt es sich bei zellulären Automaten um mathematische Modellierungen von realen Systemen, die aus lokalen und interaktiven Teilkomponenten bestehen. Als eine der berühmtesten Varianten unter den zellulären Automaten soll das Game of Life (GoL) *Gar70+ als ereigniserzeugender Simulator verwendet werden. Trotz seiner wenigen Evolutionsregeln, die den Simulatorzustand zu jedem diskreten Zeitpunkt ausgehend vom Vorzustand festlegen, zeigt GoL ein relativ komplexes Innenleben. Wie für reale Systeme üblich, besitzt GoL einen hinreichend hohen Komplexitätsgrad zur Generierung von zufälligen, charakterisierbaren Ereignissen und Raum für unvorhersehbare Entwicklungen. Bei der Modellierung des Simulators müssen Möglichkeiten zur manuellen Konfigurierbarkeit während der Simulationszeit durch den Benutzer berücksichtigt und ebenso umfangreiche Startzustände zur Verfügung gestellt werden, die zu diversen Entwicklungsverläufen führen können. Das primäre Ziel der Diplomarbeit bleibt jedoch der Entwurf vielschichtiger Monitoringkomponenten, die hauptsächlich wie der Simulator mit der deklarativen Sprache SQL zu realisieren sind. SQL wird hierbei als (ausführbarer) Spezifikationssprache für die Monitoringkriterien verwendet. 2

9 Durch das Vorliegen der Simulations- und Monitoringdaten in der Datenbank wird es dem Benutzer ermöglicht, auch ohne die Gegenwart eines GUIs auf die Informationen zuzugreifen, und vielmehr, eigene Analysemethodik mittels SQL (z.b. per Views) zu definieren. Es sind insgesamt fünf Monitoringkonzepte zur Implementierung vorgesehen, die ein breites Spektrum abdecken. Für alle Monitoringkomponenten sind weitgehende Benutzerinteraktivitäten einzuplanen und entsprechende Schnittstellen anzubieten. Bei der ersten Monitoringkomponente Evolution steht der Simulator selbst im Mittelpunkt, wobei hier zu erfassen ist, wie sich der Simulatorzustand vom letzten zum aktuellen Zeitpunkt verändert hat und ebenfalls vorauszusagen ist, wie der Simulator sich im kommenden Zeitschritt entwickeln wird. Diese Monitoringkomponente soll auch die Fähigkeit besitzen autonom den Simulator zu stoppen, wenn der Simulator keine signifikante Zustandsveränderung mehr hervorruft. Die zweite Monitoringkomponente Clustering dient zur Gruppierung von Zellstrukturen nach dem Konzept der Zusammenhangskomponente. Ferner ist eine parametrisierbare Gruppierung der im ersten Schritt erzeugten Cluster zu größeren Verbänden vorgesehen. Mustererkennung als drittes Monitoringwerkzeug soll zu Demonstrationszwecken unterschiedlich komplexe Muster erkennen, wobei es von einem Muster mehrere Varianten geben kann und diese auch einzubeziehen sind. Es sollen zwei verschiedene Erkennungsmethoden zur Anwendung kommen, wobei eine auf der dem System bekanntgemachten strukturellen Anordnung, und die andere auf dem Verhaltensmerkmal eines Mustertyps basiert. Dadurch wird das System befähigt, auch unbekannte Muster zu erkennen. Die vierte Monitoringvariante Trajektorie soll die Flugbahn der mobilen Objekte in der Simulationsumgebung aufzeichnen, wobei mittels verschiedener, zur Verfügung zu stellender Funktionalitäten die Bewegung eines Objekts näher analysiert und visualisiert werden soll. Die letzte zu realisierende Monitoringkomponente stellt die Kollisionserkennung dar, die nicht nur verschiedene Arten von Kollisionsereignissen (zusätzlich Spaltungsereignis) erkennen soll, sondern auch bevorstehende Kollisionen frühzeitig entdecken und dafür eine Wahrscheinlichkeitsprognose abgeben soll. Zu jedem diskreten Zeitpunkt sind der Simulatorzustand und die Monitoringergebnisse adäquat zu visualisieren. Ebenso sind die Justierungsmöglichkeiten für die einzelnen Monitoringkomponenten unter Einhaltung der Prinzipien der Softwareergonomie durch Erstellung einer Benutzeroberfläche (GUI) anzubieten. Das GUI wird zur Ermöglichung der Portabilität in Form eines Applets, unter Verwendung von Java zu realisieren sein. Die Gliederung dieser Arbeit stellt sich folgendermaßen dar: Im kommenden Kapitel 2 werden die theoretischen Grundlagen zum Anwendungsgebiet umfassend erläutert. Hierbei wird zunächst auf die Grundzüge des Artificial Life eingegangen und ebenso die wichtigsten Modellierungsaspekte von künstlichem Leben herausgestellt. Daraufhin folgend werden die zellulären Automaten vorgestellt. Wir werden sehen, dass diese Automaten nach Verhaltensklassen charakterisiert werden können und dabei unterschiedlichen Komplexitätsgrad aufweisen. Im Speziellen wird der zelluläre Automat Game of Life, das als Simulator verwendet werden soll, detaillierter betrachtet. Ebenso werden in dem Kapitel 2 die theoretischen Hintergründe zu den Monitoringkomponenten Clustering, Mustererkennung, Trajektorienbestimmung und Kollisionserkennung erläutert. 3

10 Kapitel 3 behandelt die Grundlagen der eingesetzten Technologien, wie die relationalen Datenbanken und die objektorientierte Programmiersprache Java. Dabei werden zunächst die Schritte des Datenbankentwurfsprozesses betrachtet und anschließend auf die wichtigsten, für diese Arbeit relevanten Aspekte von SQL und Java eingegangen. SQL wird dabei detailierter betrachtet, da es die wesentlichen Funktionalitäten umsetzt, dagegen werden wir uns bei Java auf die Datenbankanbindung über JDBC konzentrieren. In Kapitel 4 beginnen wir mit der Modellierung des Systems MONALISA, dem Datenbankentwurf. Hierbei werden die Anforderungsziele spezifiziert und aufbauend auf diesen der konzeptuelle und logische Entwurf durchgeführt. Im anschließenden Kapitel 5 wird die entworfene Datenbank von MONALISA an das Gesamtsystem angebunden und die Architektur des Systems veranschaulicht, aber auch die angebotenen Funktionalitäten anhand des GUIs näher vorgestellt. In Kapitel 6 werden die wichtigsten Implementierungsaspekte betrachtet, wobei wir uns vorwiegend auf SQL-Umsetzungen konzentrieren werden. Dieses Kapitel umfasst sowohl die Realisierung des Simulators als auch die der Monitoringkomponenten. Im letzten Kapitel erfolgt eine Zusammenfassung der Ergebnisse und Vorschläge für mögliche Erweiterungen. 4

11 2 Grundlagen aus dem Anwendungsgebiet Im Mittelpunkt dieser Arbeit steht der Aufbau eines Monitoringsystems für Artificial Life - Szenarien. Insbesondere wählen wir das Konzept des zellulären Automaten aus dem großen Gebiet des Artificial Life aus, das uns als künstliches Szenario zur Simulation realitätsnaher Prozesse dienen soll. Aus diesem Grund werden wir im folgenden Unterkapitel 2.1 auf die Grundzüge des Artificial Life eingehen und die zwei wichtigen Konzepte bei der Modellierung von künstlichem Leben, die Emergenz und Adaptation, näher betrachten. Im Abschnitt 2.2 werden wir ein- und zweidimensionale zelluläre Automaten definieren und ebenso deren einzelne Komponenten kennenlernen. Wir werden die zellulären Automaten nach ihrem Verhalten klassifizieren und dabei die Entstehung von Komplexität aus einfachen Vorgängen anhand der Emergenz, ähnlich wie im realen Universum, erkennen. Wir werden im Abschnitt 2.3 das künstliche Szenario weiter auf einen speziellen zellulären Automaten einschränken, den wohlbekannten Automaten Game of Life von John Horton Conway, und dabei auf die wichtigsten Aspekte der Entwicklungsregeln und Musterarten eingehen. Nachdem wir die theoretischen Grundlagen des simulierten Monitoringszenarios betrachtet haben, werden wir uns mit den Monitoring-Aufgabengebieten im Abschnitt 2.4 befassen. Dazu gehört das Clustering, um Strukturen in einer gegeben Inputdatenmenge zu bilden, das ebenso als Vorbereitungsschritt für weitere Monitoringaufgaben dient. Eine weitere Monitoringaufgabe ist die Mustererkennung, wo wir uns den Aufbau eines abstrakten Mustererkennungssystems ansehen werden. Im Anschluss darauf gehen wir auf die Trajektorienbestimmung ein, insbesondere auf die Glättung der Trajektorie durch das Konzept der Bézierkurve ein. Am Ende des Abschnitts 2.4 wird eine der anspruchsvollsten Monitoringaufgaben, die Kollisionserkennung, betrachtet. Dabei konzentrieren wir uns auf die durch das Konzept der bounding box ermöglichten Kollisionstests. 2.1 Artificial Life Der Wissenschaftszweig Artificial Life (kurz ALife) wurde im September 1987 unter der Leitung von Christopher G. Langton am Los Alamos National Laboratory in New Mexico, USA (neu-) begründet [Pfe02]. Die Ursprünge von ALife gehen zurück auf John von Neumann [Wik08d]. Von Neumann konstruierte mit seinem selbstreproduzierenden, universell-berechenbaren zellulären Automaten das erste künstliche Leben. Sein Ziel war es, die grundlegenden Eigenschaften von Lebensformen, besonders deren reproduktive Fähigkeiten, und ebenso deren Anpassungsfähigkeit an sich ändernde Umweltbedingungen zu erforschen. Wir werden das Konzept der zellulären Automaten im Abschnitt 2.2 näher betrachten. Die treibende Kraft der Forschung zu ALife war und ist zu beschreiben, ebenso zu verstehen, wie allgemein komplexe Systeme in der Natur funktionieren, z.b. die Evolution von DNA/RNAcodierten Lebensformen und deren Interaktion mit der Umwelt, die Algorithmik des Lernens oder paradigmatisch, wie die verschiedenen Arten von Immunzellen für eine erfolgreiche Immunantwort interagieren. Solche vielschichtigen, natürlichen Systeme lassen sich nicht durch lineare Modelle untersuchen, denn diese basieren auf der Annahme, dass die Summe der Komponenten- 5

12 eigenschaften das Gesamtmodell beschreibt und geringfügige Änderungen der Modellparameter keine großen Variationen im Modellverhalten hervorrufen sollten. Bei den meisten natürlichen Phänomenen trifft aber eine Linearisierung nicht zu: Das Leben als ein Konglomerat der Materie ist nicht mit der Materie selbst gleichzusetzen. Andere Beispiele wären die Musterbildung bei Schmetterlingen oder Fraktale bei Romanesco. Mit Nichtlinearen Modellen lassen sich solche Phänomene wie Chaos wo kleine Änderungen der Inputparameter zu qualitativ unterschiedlichen Ergebnissen führen - und Emergenz (das nichtmodellierte Gesamtverhalten eines Systems ausgehend vom definierten Verhalten der Komponenten) besser ergründen und approximieren. Nichtlinearität liegt ALife zugrunde, die nur durch aufwendige Simulation analysiert werden kann. Bevor wir auf ALife detaillierter eingehen werden, soll das Leben aus Perspektive der Thermodynamik definiert werden [Ada98]: Leben besteht aus einem Konglomerat von Einheiten, die die Fähigkeit besitzen, per physikalische Trägerkomponenten miteinander Informationen auszutauschen und die bei Vorhandensein von Störquellen in ihrer Gesamtheit in der Lage sind, der Entropie für einen längeren Zeitraum hinsichtlich seiner Umgebung relativ niedrig zu halten. Zur Charakterisierung von ALife sei eine Definition von Langton gegeben [Lan89]: Artificial Life is the study of man-made systems that exhibit behaviors characteristic of natural living systems. It complements the traditional biological sciences concerned with the analysis of living organisms by attempting to synthesize life-like behaviors within computers and other artificial media. By extending the empirical foundation upon which biology is based beyond the carbon-chain life that has evolved on Earth, Artificial Life can contribute to theoretical biology by locating life-as-we-know-it within the larger picture of life-as-it-could-be. Die Bereiche Künstliche Intelligenz (AI) und Künstliches Leben sind stark miteinander verflochten, jedoch geht ALife weiter als AI: Ein modelliertes System wird als intelligent bezeichnet, wenn es die ihm zur Verfügung stehende Wissensbasis, die die richtigen Reaktionen für alle Eventualitäten vorschreibt, in gegebenen Situationen auf optimale Weise einsetzt. AI ist dementsprechend wissensbasiert. Ein ALife-Modell muss darüberhinaus im Stande sein, seine Intelligenz so in Aktionen umzusetzen, dass diese insgesamt ein (im Sinne der Anpassung an die Umgebung) Verhaltensmuster darstellen. Es werden nur Verhaltensregeln mitgegeben, die die direkte Interaktion mit der lokalen Umgebung ermöglichen. Die Überlagerung dieser einfachen Regeln führt - aufgrund des Informationsaustausches mit der Umwelt- zu einem Globalverhalten von höherer Mächtigkeit. ALife soll nicht nur - durch Erschaffung von künstlichen Systemen mit einigen Eigenschaften des Lebens - biologische Modelle liefern, sondern soll durch diese auch das generelle Verhalten des Lebens im Einzelnen simulieren und erforschbar machen. Durch ALife erschaffene Modelle (bekannt als Agenten, Animaten oder Individuen) sind verhaltensbasierte Systeme, die im Allgemeinen folgende Merkmale aufweisen [Kin96]: 6

13 Es handelt sich um ein informationsverarbeitendes System, welches Daten aus der Umgebung per dem System zur Verfügung stehenden Sensoren aufnehmen und anschließend nach Analyse eine Reaktion als Output ausgeben kann. Dem System ist eine (variable) Umwelt zugeordnet, mit dem das System interagiert. Dem System wird eine endliche Menge von Verhaltensregeln zugewiesen, welche die Interaktionen determinieren, aber auch ein dynamisches Verhalten des Systems in seiner Umwelt ermöglicht. Die Verhaltensregeln können vorgegeben, aber auch im Rahmen evolutionärer Prozesse in einer Population entwickelt oder durch einzelne Individuen erlernt worden sein. Das Forschungsgebiet ALife konzentriert sich auf drei Schwerpunkte [Pfe02]: biologische Fragestellungen, Verhaltensintelligenz und praktische Anwendbarkeit. Zu den biologischen Fragestellungen gehören beispielsweise die Musterbildung und der Ursprung des Lebens und der Evolution. Das Gebiet Verhaltensintelligenz umfasst Emergenz und Selbstorganisation, die Verhaltensausprägung der Gruppe durch das Interagieren der Einzelnen und autonome Roboter zur Simulation von verhaltensbasierter künstlicher Intelligenz. Heute wird ALife besonders in der Computerspiel-Branche eingesetzt, aber ebenso im Militär insbesondere bei unbemannten Luftfahrzeugen ( Unmanned Aerial Vehicle, UAV) zur autonomen Steuerung *Wik08e+. Während die traditionelle Forschung analytisch orientiert ist und zur Untersuchung eines Sachverhalts eine top-down -Strategie verfolgt, bei dem komplexe Systeme in Basiskomponenten zerlegt werden, liegt ALife einer bottom-up -Erforschungsmethodik zu Grunde, bei der aus vielen elementaren, interaktiven Teilen vielschichtigere Konstrukte erschaffen werden. Eine solche synthetische Approximation basiert auf zwei Konzepten, Emergenz und Adaptation. Die Synthese kann durch drei unterschiedliche Methoden erreicht werden [Bed03]: per Software, bei dem lebensähnliche Verhaltensvariationen durch Progammcode implementiert werden; durch Hardware, indem Individuen durch Roboter mit eigenen Sensoren, Wissensbasis und Reaktionsmotorik imitiert werden (siehe Abb. 2.1); und per Wetware, bei der aus biochemischen Substanzen künstliches Leben synthetisiert wird. Modelle, die die beiden Konzepte implementieren, haben die Fähigkeit zu reproduzieren und ihre Charakteristika und Verhalten über die Zeit hinweg an die Bedingungen anzupassen ( Evolutionary Individual Based Models [BL06]). Abbildung 2.1: Beispiel einer abstrakten Modellierung eines Fisch [Ada98] 7

14 Emergenz Modelle von komplexen Systemen bestehen im Allgemeinen aus vielen interaktiven Komponenten, welche durch mathematische Formeln wie Differentialgleichungen beschrieben werden können, um die Manipulierbarkeit des gesamten Modells durch Zustandsvariablen zu ermöglichen. Eine Modellierung dieser Art liefert zwar eine generelle, aber doch zu abstrakte Analyse vom Verhalten des Systems. Denn häufig werden den Zustandsvariablen Durchschnittswerte zugeführt, die die Vielfalt des zu modellierenden Systems ungenügend widergeben, und eine folgerichtige Begründung für die entstehende Dynamik im System durch einen erhöhten Abstrahierungsgrad des Modells erschwert wird. ALife geht hier (entsprechend dem bottom-up-ansatz) anders vor, indem die Systeme als eine Ansammlung von individuellen Objekten interpretiert werden. Auf Entitäten basierende Modelle können eine avancierte Repräsentation der Individuen verwirklichen und ebenso deren Verhalten viel präziser und realitätsnaher umsetzen. Durch lokale Interaktionen zwischen den Entitäten des Systems treten komplexe Verhaltensmuster hervor, die aus den Eigenschaften der Entitäten alleine nicht unmittelbar abgeleitet werden können (Emergenz). Bei zellulären Automaten (in nachfolgenden Kapitel näher beschrieben) lassen sich solche gruppendynamischen Verhalten des Gesamtsystems, in der eine Gruppe von Individuen in einer gemeinsamen Umwelt operiert, gut beobachten. Jedes dieser Individuen ist dargestellt durch einen Zustandsautomaten, dessen Verhalten durch eine endliche Menge von Regeln definiert ist. Die Gruppe aller Automaten produziert neue komplexere Muster, die ausgehend vom Einzelverhalten der Automaten nicht ersichtlich waren. Abb. 2.2: Boids und deren drei Steuerungsregeln; der Kreis stellt den Nachbarschaftsraum des grünen Boid dar. Die Lokalisierung des zu betrachtenden Boid wird nur von denjenigen blauen Boids beeinflusst, die sich innerhalb des Kreises befinden. Der Nachbarschaftsraum kann neben dem Radius (Sichtweite) auch mittels eines bestimmten Winkels eingeschränkt werden (entsprechend dem maximalen Sichtwinkel eines Vögels) [Rey01]. Als Beispiel für emergentes Verhalten 1 wird nun ein von Craig Reynold im Jahre 1986 entwickeltes individuenbasiertes 2 Simulationsmodell namens Boids vorgestellt, welches mit zellulären Automaten verwandt ist [Rey01]+[BL06]: Boids sind autonom-agierende Geschöpfe, welche das 1 Ein Verhalten ist emergent, wenn es von unkontrollierten und nicht messbaren Variablen abhängt. von *Kin96+, S Individuenbasierte Modelle sind Simulationen, die auf die globale Verhaltensausprägung von lokalen Interaktionen der Individuen innerhalb einer Population verursacht basieren. Solche Modelle werden auch agentenbasierte Simulationen genannt. 8

15 Schwarmverhalten von Vögeln simulieren. Das globale Schwarmverhalten resultiert aus den Interaktionen der Boids, die einfache lokale Regeln befolgen. Boids sind dazu angewiesen folgende drei Regeln des steering behavior in einer virtuellen Umwelt einzuhalten, die beschreibt, wie sich ein Boid in Abhängigkeit von der Entfernung, Flugrichtung und Geschwindigkeit der Nachbar- Boids zu manövrieren hat (siehe Abb. 2.2): Separation: Es soll eine Flugrichtung gewählt werden, die einen Mindestabstand hinsichtlich der anderen Boids in der Nachbarschaft gewährleistet und so einer Häufung von Boids entgegen wirkt; Angleichung: Gleiche eigene Flugparameter mit anderen Boids aus, die der durchschnittlichen Richtung und Geschwindigkeit der Nachbar-Boids entspricht; Zusammenhalt: Positioniere Dich selbst im Raum so neu, dass die durchschnittliche Position der der benachbarten Boids (Zentrum der Nachbarschaft) entspricht. Zusätzlich zu den Grundregeln können je nach Simulationsbedarf weitere Kriterien festgelegt werden, zum Beispiel Hindernisse zu umfliegen oder auch innerhalb eines festgelegten Flugkorridors zu fliegen. Die genannten Regeln gelten gleichermaßen für alle Individuen, in Abhängigkeit der Nachbarschaft der einzelnen Boids, und führen somit zu lokalen Interaktionen und zum Informationsaustausch. Daraus ergibt sich das globale Schwarmverhalten, bei dem die Boids mehrere Zusammenballungen bilden (durch aufeinander gestützte Nachbarschaftsbeziehungen), wobei alle Boids innerhalb einer Anhäufung die gleiche Flugrichtung und Geschwindigkeit aufweisen. Die Annäherung von verschiedenen Clustern im Raum führen teilweise (wenn der kritische Mindestabstand zur Beeinflussung unterschritten wurde) zur Neuorientierung der Boids. Als Beispiele seien folgende Verhalten zu benennen: (a) Verlangsamung einiger Boids führt zur Senkung der Gesamtgeschwindigkeit der Anhäufung; (b) Zerfall eines Clusters in mehrere Teile; (c) neue gemeinsame Flugrichtung durch Verschmelzung. Solche Entstehung eines Verhaltensrepertoires auf globaler Ebene, die durch keine Regel (explizit) definiert ist, sondern nur durch die drei einfachen lokalen Regeln, verdeutlicht das Emergenz-Phänomen. Solches Gesamtverhalten durch globale Regeln zu implementieren ist mit erheblichem Mehraufwand verbunden und eine effiziente Simulation wird wahrscheinlich an der entstehenden Komplexität (z.b. muss dann jedes einzelne Boid die gesamte Population im Raum bei der Neuberechnung seiner Bewegung einbeziehen) scheitern. Zusammenfassend lässt sich sagen, dass die emergenten Eigenschaften eines Systems nicht nur von den Eigenschaften der einzelnen Entitäten, sondern auch von der Art des Zusammenwirkens abhängt, die im Prinzip aus der Nichtlinearität ein unvorhersehbares emergentes Gesamtverhalten des Systems hervorbringt, das ein einzelnes Individuum für sich alleine nicht erbringen vermag. Adaptation Die Fähigkeit, evolutionär-vorteilhafte Merkmale im Laufe der Generationen als Antwort auf verändernde Umweltbedingungen zu entwickeln, ist das zweite wichtige Prinzip der ALife-Modellierung [BL06]. Diese Anpassung auf die ändernden Anforderungen und Gegebenheiten einer Umwelt wird als adaptives Verhalten bezeichnet, welches die Chancen für die Selbsterhaltung maximiert. Nach zeitlichem Aspekt lässt sich die Adaptation in zwei Klassen unterteilen: Lernfä- 9

16 higkeit (im Bereich künstliche Intelligenz einzuordnen) und Evolution. Lernfähigkeit verdeutlicht die Fähigkeit eines Individuums mit der Umwelt zu interagieren, neu Erlerntes auf ähnliche Situationen anzuwenden und im begrenzten Maße (so weit die Robustheit und Flexibilität eines Individuums es zulässt) auf die Umweltbedingungen zu reagieren. Evolution ist im Gegensatz dazu nicht auf Ebene der Individuen definiert, sondern betrifft die ganze Population. Evolutionäre Prozesse wirken auf dem genetischen Code, die der Population die Möglichkeit gibt, sich langfristig an geänderte Umweltbedingungen anzupassen, indem vorteilhafte Merkmale der Individuen, die einen hohen Fitnessfunktionswert 3 aufweisen, an nächste Generationen bevorzugt weitergegeben werden. Neben Emergenz und Adaptation ist Selbstorganisation ein wichtiger Prozess innerhalb des künstlichen Lebens [Bed03], in dem sich spontane Formationen von komplexen Mustern oder Verhalten im Zuge der lokalen Interaktionen zwischen den Individuen (bzw. Zellen), ohne von den Individuen bewusst zu wollen und ohne gerichtete Vorgaben von außen, ergeben. ALife wird heute im wissenschaftlichen Kontext erfolgreich eingesetzt, vor allem bei Problemlösungen, die von natürlichen Leben inspiriert werden: zum Beispiel Prävention vor unbekannten Computerviren durch Verwendung von Heuristiken; bei Entwicklung von neuartigen autonomnavigierenden Flugsystemen oder auch zur Simulation komplexer Sachverhalte mit starken Wechselwirkungen (u.a. langfristige Klimaentwicklungen). Im kommenden Abschnitt beschäftigen wir uns mit dem Urahn des Bereichs Artificial Life, den zellulären Automaten, die vor allem wegen ihrer Anpassungsfähigkeit an einer zu simulierenden Umgebung von hoher Bedeutung für die Erforschung der komplexen Sachverhalte sind. 2.2 Zelluläre Automaten In Greek mythology, the machinery of the universe was the gods themselves. They personally tugged the sun across the sky, delivered rain and thunder, and fed appropriate thoughts into human minds. In more recent conceptions, the universe is created complete with its operating mechanism: once set in motion, it runs by itself. God sits outside of it and take delight in watching it. (von Tommaso Toffoli, [Tof89]). Das Konzept der Zellularautomaten geht auf die Mathematiker von Neumann und Ulam Ende der 1940er Anfang der 1950er Jahre zurück [Wol02]. Neumanns Zellularautomat war eine Kombination von gleichartigen, diskreten Zellen, die selbst reproduzierende Strukturen modellieren sollten [GS95]. Die Motivation war hierbei zu ergründen, ob Maschinen sich ähnlich wie biologisches Leben reproduzieren können. Neumann konnte zeigen, dass solch ein Automat in der Lage war, 3 Eine Fitnessfunktion ordnet jedem Mitglied einer Population einen Fitness-Wert zu, welche besagt, wie gut ein Individuum mit seiner Umwelt zurecht kommt und dementsprechend ist die Erfolgswahrscheinlichkeit, sein Genom weiterzugeben. 10

17 seine Struktur aus sich selbst heraus dynamisch zu replizieren, ohne dass eine von außen vorgeschriebene Anweisung dazu erforderlich ist (im Sinne von Artificial Life). Allgemeiner gesagt, handelt es sich bei zellulären Automaten um eine mathematische Modellierung von natürlichen Systemen, die aus lokalen interaktiven Teilkomponenten bestehen. Dabei kodiert jede Zelle einen bestimmten Zustand der modellierten natürlichen Komponente. Zelluläre Automaten befolgen einfache Regeln, erzeugen aber sehr komplexes, asymptotisches Verhalten, das als ein Kennzeichen belebter Strukturen interpretierbar ist. Im Jahre 1970 stellte John Conway eine der bekanntesten Varianten der zellulären Automaten vor [Mar08], welche wir als künstliches Szenario im Rahmen diskreter Prozesse in dieser Diplomarbeit verwenden (siehe Kapitel 2.3). In den 1980er Jahren untersuchten Wolfram, Fredkin und Packard [Mat02] die theoretischen Grundlagen der zellulären Automaten und spürten die Zusammenhänge u.a. zur Chaosforschung, Nichtlinearität 4, Selbstorganisation 5 und Komplexitätstheorie auf, da sie die typischen Eigenschaften dynamischer Systeme aufweisen. Zelluläre Automaten sind diskrete, dynamische Systeme, deren Verhalten hauptsächlich durch ihre lokale Umgebung spezifiziert ist (jedoch deren Gesamtverhalten nicht auf die zugrundeliegenden Regeln zurückverfolgt werden kann), wie bei einer großen Klasse von kontinuierlich dynamischen Systemen, die durch partielle Differentialgleichungen definiert sind. Zelluläre Automaten liefern verlässliche Modelle bei der Erforschung von Kombinatorik. Sie sind insbesondere die mathematische Approximation von physikalischen Systemen mit lokalen Interaktionen, in denen Zeit und Raum diskret sind und physikalische Größen auf eine endliche Menge von diskreten Werten beruhen. Sie stellen ein allgemeines Modell für parallele Berechnungen dar, im selben Maße wie die Turing-Maschinen für serielle Berechnungen. Die Zeit schreitet bei dem zellulären Automaten in diskreten Schritten voran. Es gibt eine endliche Menge von Entwicklungsregeln, die aus dem Zustand einer Zelle und der Zustände ihrer Umgebung auf einen Zustand der Zelle abbildet, die für alle Zellen des Zellraumes zur selben Zeit angewandt werden. Demnach sind die Regeln des Systems lokal und uniform [Tof89]. Lokal bedeutet, dass, was vor Ort geschieht, wird nur durch den eigenen Zustand und den Zustand der unmittelbaren Nachbarzellen beeinflusst. Uniform besagt, dass die Regeln überall im zellulären Raum gleichwertig und synchron angewandt werden. Ein besonderer Aspekt bei der Betrachtung von zellulären Automaten ist es, dass sich auf der Grundlage einfacher deterministischer Regeln (welche die Art der lokalen Kommunikation bzw. Wechselwirkung zwischen den Zellen festlegt) in einem Gesamtsystem auf höherer Ebene, ein überaus komplexes, geordnetes Gesamtverhalten herausbildet, im Sinne von Emergenz 6. 4 Aus Gesetzen und Verhalten, die für Teilsysteme gelten, lässt sich nicht immer ohne weiteres auf das Verhalten und die Regeln eines Gesamtsystems kumulativ implizieren. Bei dem Zusammenschluss der Komponenten zu einem Netzwerk wachsen diese über sich selbst hinaus und bilden eine höhere Ordnung (z.b. von Atomen zu Molekülen; Entstehung von Gedanken durch Zusammenwirken von Milliarden von Neuronen). 5 Durch Abstimmung des Verhaltens von Teilsystemen untereinander können diese selbst Ordnung und Struktur von komplexer Natur hervorbringen. 6 Als Beispiel: La Ola -Welle in Sportstadien 11

18 Die Grundcharakteristika eines zellulären Automaten können folgendermaßen beschrieben werden ([GS95], S.18f): Die Entwicklung zellulärer Automaten findet in einem diskreten Raum und in diskreten Zeitschritten statt. Der Raum ist eine diskrete Menge von Zellen. Jede Zelle hat nur eine endliche Menge möglicher diskreter Zustände. Die Zustände aller Zellen verändern sich in diskreten Zeitintervallen. Alle Zellen sind identisch und handeln nach den gleichen Entwicklungsregeln. Der nachfolgende Zustand bzw. die Entwicklung einer Zelle hängt von ihrem eigenen Zustand und von dem ihrer lokalen Umgebung ab. Der zelluläre Automat ist dementsprechend eine n-dimensionale Matrix von diskreten, gleichartigen Zellen, die sich in einer endlichen Menge von Zuständen befinden. Nachfolgend seien eigene Definitionen für ein- und zweidimensionale zelluläre Automaten gegeben: Definition 2.1: Ein eindimensionaler zellulärer Automat ist durch ein 6-Tupel ZA = Z, Z, n, δ i, δ, z α gegeben. Dabei ist: Z eine endliche Menge von Zuständen, die jede der gleichartigen Komponentenzellen annehmen kann, n N + die Anzahl der Komponentenzellen des Automaten, Z = def (Z Z) die endliche Zustandsmenge des Automaten, n mal δ i : Z Z, i {0,, n 1}, die Zustandsübergangsfunktion der i-ten Zelle, δ : Z Z die Zustandsfunktion des Gesamtautomaten, induziert durch die Zustandsübergangsfunktionen der einzelnen Zellen: δ z = def (δ 0 z, δ 1 z,, δ n 1 z ), z α Z der Startzustand des Automaten. Definition 2.2: Ein zweidimensionaler zellulärer Automat ist durch ein 6-Tupel ZA = Z, Z, n, δ i,j, δ, z α gegeben. Dabei ist: Z eine endliche Menge von Zuständen, die jede der gleichartigen Komponentenzellen annehmen kann, Für l, m, n N + sei n = m l die Anzahl der Komponentenzellen des Automaten, Z = def (Z l Z l ), Z l = def (Z Z), die endliche Zustandsmenge des Automaten, m mal l mal δ i,j : Z Z, i {0,, l 1}, j {0,, m 1} die Zustandsübergangsfunktion der i, jten Zelle, δ : Z Z die Zustandsfunktion des Gesamtautomaten, induziert durch die Zustandsübergangsfunktionen der einzelnen Zellen: δ z = def (δ 0,0 z, δ 1,0 z,, δ l 1,m 1 z ), z α Z der Startzustand des Automaten. 12

19 2.2.1 Elementare Bestandteile Zellraum Zelluläre Automaten (ZA) stellen unter dem Aspekt der zeitlichen Veränderung einen gewissen Entwicklungsprozess in einem n-dimensionalen Raum dar. Der Raum besteht aus einer Menge von einheitlichen Zellen und hat eine diskrete Struktur, welche ein grundlegendes Charakteristikum aller zellulären Automaten ist. Größe, Dimension und Geometrie legen die Struktur eines Zellraums eindeutig fest. Abb. 2.3 : Verschiedene Zellräume Abb. 2.4: Gitter Für theoretische Betrachtungen kann ein unendlicher Raum in Betracht gezogen werden, jedoch ist es im Rahmen einer praktischen Simulation notwendig, den Raum als endlich zu definieren angesichts der begrenzten Rechen- und Speicherkapazitäten von Rechnern. Die Dimension des Zellraums hat einen nicht unerheblichen Einfluss auf die Komplexität des Automaten. Eindimensionale Automaten werden aufgrund ihrer Verständlichkeit hinsichtlich deren überschaubaren Entwicklungsregeln bevorzugt. Aber trotz ihrer einfachen Struktur, können solche Automaten durchaus ein komplexes Verhalten aufweisen, wie es für Automaten mit höher dimensionalen Zellräumen typisch ist. In einem eindimensionalen Raum ist der Zellraum wie eine Gerade realisiert, bei der die Zellen nacheinander aufgereiht sind. In der 2-Dimensionalität ist der Zellraum durch ein uniformes Gitter repräsentiert (siehe Abb. 2.3). Es beinhaltet Polygonen (z.b. Dreieck, Quadrat, Sechseck) oder bei höher dimensionalen Räumen kann es sich bei Zellen um Hyperwürfeln handeln. Die geometrische Form der einheitlichen Zellen bestimmt die Geometrie des Zellraums. In der Zweidimensionalität wird der Zellraum R als ein l m Gitter definiert (Abb. 2.4), wobei l, m N + sind: R = { i, j : i, j N, 0 i < l, 0 j < m}. Nachbarschaft Jede Zelle besitzt einen zu definierenden umgebenden lokalen Nachbarraum, in der die zur jeweiligen Kernzelle 7 benachbarten Zellen liegen. Für alle Zellen gelten die gleichen Nachbarschaftsstrukturen im Zellraum, d.h. jede einzelne Zelle, außer an den Randgebieten, besitzt die gleiche Anzahl von Nachbarn, die auf der gleichen Weise räumlich miteinander verbunden sind. Die Struktur der Nachbarschaft wird zunächst durch gewählte Gittergeometrie und Dimension festgelegt, 7 Die Kernzelle ist genau die Zelle (x 0, y 0 ), die im Bezug auf die Nachbarschaft betrachtet wird. 13

20 denn diese bestimmt, wie viele Nachbarn an einer Zelle unmittelbar angrenzen. In einem eindimensionalen Zellraum ist die Anzahl der möglichen Nachbarzellen eingeschränkt: jede Zelle besitzt maximal zwei unmittelbare Nachbarn, die sich auf der linken und rechten Seite befinden. An den beiden Randgebieten sind die Anzahl der Nachbarn auf jeweils einen beschränkt. Ein zusätzlicher Ansatzpunkt bei der Nachbarschaftsdefinition (auch in höheren Dimensionen gültig) ist es, einen Radius r (r N) anzugeben, der eventuell weiter entfernte Zellen als Nachbarn berücksichtigt und die Entwicklung der Kernzelle beeinflusst. Die Gesamtsumme der Zellen in der Nachbarschaft 8 (im eindimensionalen Raum) einer Zelle beträgt dann 2r + 1 Zellen, die aus der Kernzelle selbst und 2r Nachbarn besteht. Es sind weitere Geometrien zusätzlich zu der Quadratform denkbar, wie zum Beispiel Dreiecke und Sechsecke, die entsprechend auf die Nachbaranzahl Einfluss nehmen. Eine Zelle in einem Sechseck-Gitter (im zweidimensionalen Zellraum) hat sechs direkte Nachbarn, aber eine dreieckige Zelle nur drei. Dies hängt jedoch wiederum davon ab, ob die Diagonalzellen als direkte Nachbarn miteinbezogen werden sollten oder nicht (siehe Abb. 2.5). Bei der von Neumann- Nachbarschaft gibt es für jede Zelle in einem rechteckigen Gitter nur vier direkt angrenzende Nachbarn. Denn hier werden nur die Zellen als Nachbarn einer gerade zu betrachtenden Zelle (x 0, y 0 ) berücksichtigt, die mindestens eine Kante gemeinsam haben. Diese Abb. 2.5: verschiedene Nachbarschaftsdefinitionen bilden eine diamantförmige Nachbarschaft (bei größerem Radius) um eine Zelle in der zweidimensionalen Ebene. Für x 0, x {0, l 1} und y 0, y {0, m 1} sei die von-neumann-nachbarschaft mit dem Radius r definiert durch [Wei99]: 14 vn N (x0,y 0 ) = {(x, y): x x 0 + y y 0 r}. Die Abb. 2.6 zeigt u.a. die von-neumann-nachbarschaft innerhalb der Radien r = 1 und 2. Die Anzahl der Zellen (Ausnahmen bilden Randgebiete) in der von-neumann-nachbarschaft mit dem Radius r ist eine zentrierte Quadratzahl 9. Dies beträgt inklusive der Kernzelle 2r r Bei der Moore-Nachbarschaft sind es hingegen acht Nachbarn, da hier zusätzlich auch die Diagonalzellen als Nachbarn miteinbezogen werden. Bei einer erweiterten Moore-Nachbarschaft kann eine Zelle, ebenso wie bei der von Neumann, zusätzlich zu der ersten Nachbarschaftsstufe weitere Nachbarzellen des zweiten, dritten Grades (oder mehr) besitzen. Die Moore-Nachbarschaft vom Radius r ist definiert durch [Wei99]: M N (x0,y 0 ) = {( x, y): x x 0 r, y y 0 r}. Die Anzahl der Zellen (Kernzelle miteinbezogen) in der Moore-Nachbarschaft sind im allgemeinen (Randgebiete ausgenommen) die ungeraden Quadratzahlen, abhängig vom Radius r: (2r + 1) 2. 8 Zur Nachbarschaft gehören die Nachbarzellen einer Kernzelle und die Kernzelle selbst. 9 Die zentrierte Quadratzahl ist die Summe von zwei aufeinanderfolgenden Quadratzahlen und ist kongruent zu 1 (mod 4).

21 Für Modelle, bei denen eine wesentlich bessere räumliche Auflösung des zu untersuchenden natürlichen Prozesses bzw. eine deutlich realistischere Beschreibung erforderlich ist, nimmt gerade die Erweiterung der Nachbarschaft mittels größeren Radien in ihr Regelsystem auf. Dies bewirkt eine komplexere Interaktion bzw. Kommunikation zwischen den Zellen, welche auf ein vielschichtigeres Verhalten abbildet. Die Nachbarschaftsstruktur lässt sich auch frei nach Anforderung definieren (z.b. asymmetrisch), solange dies für alle Zellen gleichermaßen gilt. Zur weiteren Vertiefung im Bereich zweidimensionaler zellulärer Automaten sei auf [PW1985] verwiesen. Abb. 2.6: Nachbarschaften mit unterschiedlichen Radien Randbedingungen In der Theorie kann der Zellraum als ein unendlicher Raum für die Entwicklung des zellulären Automaten angenommen werden. Jedoch muss die Größe des Spielfelds auf ein bestimmtes Maß für die praktische Simulation in Rechnern begrenzt werden. Die dadurch entstehenden Randgebiete sind problematisch, denn die Zellen an den Randzonen weisen keine vollständige Umgebung bezüglich der Nachbarschaftsdefinition auf. Bei der Moore-Nachbarschaft in der Zweidimensionalität hat jede innere Zelle vier Nachbarn, am Rand besitzen sie nur drei und an den vier Ecken nur zwei Nachbarn. Diese Tatsache kann bei Entwicklungsregeln mit unterschiedlichen Nachbarschaftsbedingungen zu Anomalien im Verhalten des Automaten führen, die bei einem theoretischen Konzept nicht auftauchen. Der Einfluss auf das Verhalten ist proportional zur Größe des Zellraums von Automaten, denn ein kleinerer Zellraum hat im Verhältnis mehr Randzellen als ein viel größerer Zellraum mit mehr inneren Zellen. Zum Beispiel sind auf einem Zellraum 36% Randzellen, aber bei einem Gitter beträgt der Anteil von Randzellen im Verhältnis zur Gesamtanzahl der Zellen nur noch 0,40%. Automaten, in denen nicht alle Zellen die gleiche Anzahl an Nachbarn haben, heißen an Rändern offen (vgl. Abb. 2.7). Es wird implizit angenommen, dass der Raum außerhalb des Gitters aus inaktiven, toten Zellen besteht, deren Zustand sich niemals ändert. Eine solche Begrenzung lässt sich umgehen, indem bei einem eindimensionalen Raum die beiden Ränder des Bandes miteinander verklebt werden und so aus einem Streifen ein Ring wird. Solche Ränder werden periodisch genannt. Dieses Verfahren lässt sich auch bei einem zwei-dimensionalen Gitter anwenden, welche dann mittels einer toroidalen Verklebung der Ränder zu einer Schlauchform (Torus) überführt wird (siehe Abb. 2.8), so dass keine Randgebiete mehr existieren. Die zweite Möglichkeit bei dem die Ränder vermieden werden, lässt sich durch die Spiegelung der Randzellen erreichen, so dass auch diese Zellen eine vollständige Nachbarschaft wie die inneren Zellen aufweisen. In diesem Fall handelt es sich um einen Automaten mit symmetrischen Randbedingungen. 15

22 Durch die künstliche Erweiterung der Ränder können auch unbeabsichtigte Nebeneffekte auftreten. Zum Beispiel könnte ein Gleiter 10, das in einem unendlichen Raum kontinuierlich in eine Richtung fliegen würde, einen Torus ständig in Zyklen (diagonal versetzt) umrunden. Abb. 2.7 Ränderarten im eindimensionalen Raum Abb. 2.8 : Beseitigung von Randzonen der Ebene [GS95], [Lew92] Zustandsmenge Jede Zelle eines zellulären Automaten kann nur eine endliche Menge von Zuständen im Verlaufe seiner Entwicklung annehmen. Die Zustände der Zellen können abhängig vom Problemfeld durch Zahlen repräsentiert werden. Sind zum Beispiel nur zwei Zustände (Z = {0, 1} oder Z = {tot, lebend}) für jede Zelle definiert, dann handelt es sich um einen binären zellulären Automaten. Obwohl man bei einem binären Automaten kein ausgeprägtes Verhaltensrepertoire erwarten würde, entsteht doch durch die Kombinationsbreite aller Zustände der Zellen im Zellraum eine gewisse unüberschaubare Komplexität. Wenn der Zellraum aus n Zellen besteht, von der jede jeweils zwei Zustände annehmen kann, so gibt es insgesamt 2 n verschiedene Automatenzustände. Zum Beispiel gibt es bei einem relativ kleinen binären Automaten mit der Zellraumgröße 5 5 mehr als 33 Millionen Zustandskombinationen. Ein ternärer Automat kann bei derselben Größe insgesamt 3 25 = verschiedene Zustände hervorbringen. Generell gilt: Auf einem Zellraum mit n Zellen, die jeweils q Zustände annehmen können, gibt es q n verschiedene Automatenzustände. Aber nicht jede Zustandskonfiguration des Automaten wird im Verlaufe der Simulationszeit auch erreicht, denn dies hängt von den Entwicklungsregeln ab, die verhindern, einen bestimmten Zustand bei einer gegebenen Anfangskonfiguration jemals anzunehmen. Die unerreichbaren Zustände werden als Paradies-Konfigurationen bezeichnet. Zustandsentwicklung Die Zustandsentwicklung bzw. der Übergang der einzelnen Zellen in diskreten Zeitschritten hängt von dem aktuellen Zustand der Zelle selbst und den Zuständen der Zellen in der definierten Nachbarschaft ab. Aber wie die Zustände der relevanten Zellen (die Kernzelle und Ihre Nachbarzellen) für den Zustandsübergang vom Zeitpunkt t nach t + 1 interpretiert und auf einen neuen Zustand abgebildet werden sollen, hängt von den durch die Entwicklungsregeln abgeleitete Übergangsfunktion ab. Die Regeln sind die abstrahierten Gesetzmäßigkeiten des zu untersuchenden Sach- 10 Gleiter ist ein diagonal bewegendes Muster in Conway s Game of Life. 16

23 verhalts der Realität, die auch das Kernstück der Modellierung darstellen. Bei jedem Zeitschritt werden die Regeln auf alle Zellen des Zellraums parallel angewandt und die Zustandsautomaten nehmen ihre neuen Zustände an, welche dann in ihrer Gesamtheit den neuen Zustand des zellulären Automaten repräsentieren. Aber die synchronisierte Regelanwendung ist nicht immer erwünscht: manche spezielle Sachverhalte erfordern eine asynchrone, serielle oder auf eine Wahrscheinlichkeitskomponente basierende Aktualisierung der Zustände. Die Anzahl der möglichen definierbaren Regeln hängt von der Anzahl der verschiedenen Zustände ab, aber auch maßgeblich von der Nachbarschaftsgröße. Jede mögliche Zustandskombination der Nachbarschaft (inklusive der Kernzelle) kann auf einen neuen Zustand der Kernzelle abgebildet werden. Als Beispiel möglicher Entwicklungsregeln soll nun ein eindimensionaler binärer Automat betrachtet werden, der den Nachbarschaftradius r = 1 besitzt. Die Nachbarschaft besteht - der Formel 2r + 1 entsprechend - aus drei Zellen und so gibt es genau 2 3 = 8 mögliche Konfigurationen, wie die Zustände 0 und 1 in der Nachbarschaft verteilt werden können. Im nächsten Zeitschritt wird diese binäre Nachbarschaftskonfiguration auf einen Zustand 0 oder 1 der Kernzelle abgebildet. Es gibt insgesamt 2 8 = 256 mögliche Entwicklungsregeln bei einem eindimensionalen binären Automaten mit Nachbarschaftsradius r = 1. Wenn jede Zelle im Zellraum des Automaten q verschiedene Zustände annehmen kann und jeweils s Zellen zu ihrer Nachbarschaft zählen, so gibt es im Ganzen q qs definierbare Regeln für die Zustandsentwicklung. Zum Beispiel gibt es schon bei einem zweidimensionalen Gitter des binären Automaten auf Basis der von-neumann- Nachbarschaft (s = 5) mehr als vier Milliarden denkbare Entwicklungsregeln, und bei der Moore- Nachbarschaftsdefinition (s = 9) sind es sogar Es gibt verschiedene Möglichkeiten die Regeln zu formulieren: Zum einen lässt sich zum Beispiel jede mögliche binäre Gruppe von Zustandswerten der Nachbarschaft auf den Zustandswert der Kernzelle abbilden (siehe Abb. 2.9) oder zum anderen als eine mathematische Funktion darstellen, wobei z i t den Zustand der Zelle i zum Zeitpunkt t bezeichnet: Abb. 2.9: Mögliche Entwicklungsregel [GS95] z i t + 1 = 1, wenn z i 1 t + z i t + z i+1 t = 2 0, sonst. Diese Formulierung lässt sich in die bereits definierte Übergangsfunktion für eindimensionale zelluläre Automaten umformulieren (vgl. Definition 2.1): δ i (z ) = 1, wenn z i 1 + z i + z i+1 = 2 0, sonst. Wir werden die erste Darstellungsform für die Formulierung der Entwicklungsregeln im Folgenden verwenden, um die Zeitkomponente eindeutig einzubinden, besonders im Hinblick auf den von uns verwendeten zellulären Automaten Game of Life (Kapitel 2.3) als ereignis-erzeugenden 17

24 Simulator. Durch die mathematische Formulierung wird klar, dass die Zustandsentwicklung einer Zelle in diesem Fall von der Anzahl der Einsen in der unmittelbaren Umgebung abhängt, ohne deren räumliche Anordnung zu beachten. Solche Regeln werden als totalistisch bezeichnet, weil die Zustandsentwicklung einer Zelle nur von der Gesamtzahl der Zustandswerte ihrer definierten Nachbarschaft abhängt. Es lassen sich grundsätzlich zwei Arten von möglichen Entwicklungsregeln unterscheiden: Deterministische Regeln legen den Simulationsverlauf eines Automaten zu jeder Startkonstellation der Zellen eindeutig fest. Eine Wiederholung der Simulation mit der gleichen Anfangskonfiguration soll jedesmal dasselbe Ergebnis liefern. Stochastische Regeln stützen sich auf eine Zufallskomponente und sie werden in Form von Wahrscheinlichkeitsaussagen formuliert Klassifikation nach Verhalten Seit Anfang der 1980er Jahre beschäftigte sich der britische Physiker und Mathematiker Stephen Wolfram mit dem Wesen und Prinzipien der Komplexität [GS95]. Er fand heraus, dass sich die zellulären Automaten zur Beschreibung und Untersuchung der Komplexität als ein ideales Approximationsmodell erwies. Zunächst galt es zu ermitteln, welche Strukturen zu erzeugen und welchen Grad von Komplexität man mit dem zellulären Automaten überhaupt anzunähern vermag. Da die Anzahl der Zustände der einzelnen Zellen, die Dimension, Größe und geometrische Charakteristika des Zellraums und zusätzlich die Variabilität der Nachbarschaft eine unüberschaubare Menge von Entwicklungsmöglichkeiten und daraus resultierend Strukturen zuließ, beschränkte er sich auf die Untersuchung von eindimensionalen binären Automaten (q = 2) mit deterministischen, totalistischen Regeln und einem Nachbarschaftsradius r = 2. In einem eindimensionalen Automaten sind die Zellen nacheinander gereiht und jede Zelle besitzt auf der linken und rechten Seite Nachbarzellen, deren Anzahl von dem Nachbarschaftsradius abhängt. Jede Zelle, die eine symmetrische Nachbarschaft hat und q verschiedene Zustände annehmen kann, hat infolgedessen q q(2r+1) mögliche Entwicklungsregeln. Da zunächst in der Eindimensionalität kein komplexes Muster zu erwarten ist, soll der räumlich eindimensionale Automat in einer Ebene dargestellt werden, in der Zeit als die zweite Dimension hinzugenommen wird. Daraus lässt sich das Verhalten des eindimensionalen Automaten als ein Muster in Abhängigkeit von Raum und Zeit erkennen. Zur näheren Analyse von raum-zeitlichen Mustern soll jetzt ein binärer eindimensionaler Automat mit folgender Entwicklungsregel betrachtet werden: z i t + 1 = z i 1 t + z i+1 t mod 2 z i (t) beschreibt den Zustand (0 oder 1) der Zelle an der Position i zum Zeitpunkt t. Der nachfolgende Zustand z i t + 1 der i-ten Zelle ergibt sich aus der Summe der jetzigen Werte der linken und rechten Nachbarzelle modulo 2. Hierbei handelt es sich also um einen totalistischen Automa- 18

25 ten mit Nachbarschaftsradius r = 1. Zum besseren Verständnis der Dynamik dieses Automaten lässt sich die obige Entwicklungsregel folgendermaßen äquivalent darstellen: z i t + 1 = 0, wenn z i 1 t + z i+1 t gerade 1, wenn z i 1 t + z i+1 t ungerade. Die Abb zeigt, wie der Automat aus einer einzigen Zelle, die den Zustand 1 hat, im Verlaufe der ersten Zeitabschnitte sich anhand der definierten Regel entwickelt. In einem unendlichen Zellraum würde der Automat unbegrenzt mit dieser Entwicklung fortfahren. Wenn man die Zustände des eindimensionalen Zellraums nach ihrer zeitlichen Abfolge aneinanderreiht, entsteht eine reguläre, komplexe Struktur aus ineinander geschachtelten Dreiecken (siehe Abb. 2.11), welche man aus den Regeln, ohne Berücksichtigung der zeitlichen Dynamik, nicht unmittelbar zu erfassen vermag. Dieses raum-zeitliche Muster weist sogar fraktale Strukturen auf, nämlich die Selbstähnlichkeit: das größte Dreieck (das durch die äußeren schwarzen Ränder gekennzeichnet ist) enthält drei weitere identische Dreiecke und diese wiederrum beinhalten jedesmal rekursiv drei exakte, verkleinerte Kopien. Abb. 2.10: Entwicklung des mod-2- Automaten während der ersten vier Zeitabschnitte Abb. 2.11: Raum-zeitliche Muster des mod-2-automaten Wolfram betrachtete für die Untersuchung des Verhaltens von eindimensionalen Automaten nur die Entwicklungsregeln (zusätzlich zu den oben erwähnten Einschränkungen), sogenannte legale Regeln, bei deren Anwendung auf einem Nullzustand (beim Nullzustand haben alle Zellen den Zustand 0), keine spontane Entwicklung hervorgeht. Er unterteilte die Entwicklungsregeln anhand der Komplexität ihres Verhaltens im Hinblick auf die raumzeitliche Musterbildung in vier Klassen, ausgehend von verschiedenen Anfangskonstellationen. Zelluläre Automaten der Klasse 1 entwickeln sich von fast allen möglichen Startkonstellationen aus zu einem unveränderlichen, homogenen Endzustand, in dem alle Zellen den gleichen Zustandswert besitzen. Jede Information, die ein Startmuster anfangs beinhaltet hat, wird von der Entwicklungsregel im Verlaufe der Simulation vernichtet. Abb zeigt Beispiele zur Entwicklung eines Klasse 1 Automaten mit drei verschiedenen Regeln: 19

26 Abbildung 2.12: Mustererzeugung von Klasse 1 Automaten [GS95] Klasse 2 Automaten bilden im Laufe ihrer Entwicklung periodische Muster aus. Diese räumlichbegrenzten Muster bleiben über der gesamten Simulationszeit konstant. Die Klasse 2 Automaten können als eine Art Filter fungieren, der die Informationen aus bestimmten Zellsequenzen durchlässt. Solche Automaten bilden ausschließlich Blöcke von schwarzen (Zustand 1) oder weißen Zellen (Zustand 0) in einer einheitlichen Umgebung von Zellen der anderen Farbe aus (siehe Abb. 2.13). Abb. 2.13:Drei verschiedene Klasse 2 Automaten [GS95] Zelluläre Automaten der Klasse 3 werden durch ihr chaotisches Verhalten ersichtlich und ihre Muster weisen keine Periodizität auf. Im Gegensatz zu anderen Klassen sind diese einer laufenden Veränderung unterworfen und die Automaten erreichen auch keine stabilen Endformen. Das bedeutet aber nicht, dass sie durchweg irregulär und keine Ordnung besitzen: Einigen Entwicklungsregeln der Klasse 3, ausgehend von verschiedenen Startkonfiguration, zeigen auch bestimmte Muster wie z.b. Dreiecke (bzw. dreieckförmigen Lichtungen der verschiedenen Größenskalen; vgl. Abb.2.14) auf, die eine gewisse Ordnung widerspiegeln. Regeln, die eher irreguläre Muster produzieren, zeigen auch bei unterschiedlichem Input dieselben Charakteristika der Irregularität. Abb. 2.14: Von Klasse 3 Automaten erzeugten Muster mit unterschiedlichen Entwicklungsregeln [GS95] 20

27 Automaten der Klasse 4 (siehe Abb. 2.15) erzeugen räumlich voneinander getrennte Strukturen von komplexer Natur und haben Merkmale der Unvorhersehbarkeit bezüglich des Verhaltens. Es werden je nach Anfangszustand auch unveränderliche Strukturen erzeugt, die sich durch den Raum bewegen können. Die Endzustände dieser Klasse sind nicht durch ein typisches Muster gekennzeichnet und sie neigen zu irregulären Veränderungen bei minimaler Startzustandsvariierung (Unvorhersehbarkeit), während die Muster der ersten drei Klassen gegenüber Abweichungen in den Anfangskonstellationen unempfindlich sind. Bei einigen Anfangskonfigurationen verhält sich der Automat der Klasse 4 wie Klasse 1 und 2: Es kann zu einer Auslöschung von Strukturen im Zellraum kommen, aber ebenso können, lokal unabhängig voneinander, mehrere stationäre oder periodische Muster durch die Entwicklungsregeln resultieren. Um einen Automaten der Klasse 4 eindeutig zu bestimmen, ist es notwendig, mit einer größeren Zahl von Anfangszuständen zu simulieren, und gerade in dieser Klasse sind Kandidaten (durch ihre im Raum und in Zeit ausbreitende Strukturen zum Beispiel siehe Abb Gleiterkanone begründen sie den Inbegriff der Komplexität) für einen universellen Zellularautomaten [NYH1998]zu suchen. Abb. 2.15: Beispiele für Klasse 4 Automaten (die ersten beiden basieren auf denselben Entwicklungsregeln, aber ausgehend von unterschiedlichen Anfangszuständen) [GS95] Die Unterschiede zwischen den vier Klassen sind nicht nur auf ihre entstehenden Musterbildungen beschränkt, sondern auch hinsichtlich der Vorhersagbarkeit ihres Verhaltens. Bei der Klasse 1 ist das Verhalten unabhängig von der Inputkonstellation vorhersagbar (homogene Endzustand). Die räumlich-begrenzten Strukturen, die in der Klasse 2 entstehen, werden nur von Zellen eines begrenzten Bereichs im Anfangszustand beeinflusst, wobei die weiter entfernten Zellen keinen Einfluss haben. Sobald solche Muster in der Startkonstellation vorhanden sind, lässt sich ein entstehendes Endmuster prognostizieren. Im Gegensatz dazu sind bei Automaten der Klasse 3 und 4 keine Voraussagen möglich, denn hier kann jede Zustandsänderung der einzelnen Zellen im Zellraum die gesamte Musterbildung beeinflussen. Auch bei anderen Nachbarschaftsradien r und einer anderen Anzahl der Zustände q (bisher angenommen q = 2 und r = 2) sind qualitativ ähnliche Musterbildungen zu beobachten. Aber unterschiedliche Variationen der beiden Werte haben Einfluss auf die Verteilung der Entwicklungsregeln in den vier Klassen: die meisten Regeln gehö- Abb. 2.16: Gleiterkanone in einem eindimensionale Automaten [GS95] 21

28 ren zur Klasse 3 und die Klasse 4 Automaten sind am wenigsten zu finden (vergleiche Tabelle 1). Für vertiefende Studien sei auf die Literatur [Wol84], [Wol84] und [MOW84] verwiesen. Klasse q = 2 r = 1 q = 2 r = 2 q = 2 r = 3 q = 3 r = 1 1 0, ,09 0,12 2 0,25 0,16 0,11 0,19 3 0,25 0,53 0,73 0, ,06 0,06 0,07 Tabelle 2.1: Verteilung der Automaten bei verschiedenen q und r Werte Die Ergebnisse für eindimensionale Automaten lassen sich auch auf zweidimensionale Automaten übertragen. Hierbei kann die Zeit als die dritte Dimension hinzugenommen werden oder einfachheitshalber kann zur Betrachtung in der Ebene ein Querschnitt des Zellraums (eine Reihe von Zellen) verwendet werden, wobei die Querschnitte, wie bei dem eindimensionalen Fall, chronologisch hintereinander angeordnet werden. Für eingehende Details sei auf [PW85] verwiesen. Als Musterbeispiel sei der Game of Life (GoL) Automat welcher zur Klasse 4 gehört in Abb und 2.18 angegeben, worauf wir im kommenden Kapitel näher eingehen werden. Abb. 2.17: (a) stellt den GoL-Automat zum Zeitpunkt t = 5, (b) zum t = 50, (c) zum t = 200 und (d) zum t = 500 dar. Abbildung 2.18 zeigt den eindimensionalen Schnitt, in dem nur die raum-zeitliche Entwicklung der mittleren horizontalen Zellreihe von Abb abgebildet ist. 22

29 2.3 Game of Life John Horton Conway, ein bekannter Mathematiker an der Universität Cambridge, hat Game of Life (GoL) entworfen, welches im Jahr 1970 von Martin Gardner der Öffentlichkeit vorgestellt wurde [Mar08]. Sein Ziel war es, die Konstruktion des zellulären Automaten zu vereinfachen, indem er sich dabei auf wenige Zustände und einfache Übergangsregeln begrenzte. Im Gegensatz dazu besaß von Neumanns Automat mit fast 30 verschiedenen Zuständen dementsprechend komplexe Entwicklungsregeln. Die Namensvergabe verdeutlicht die Analogie des GoL mit dem Aufstieg, dem Fall und dem Generationswechsel innerhalb einer Gruppe von lebenden Organismen. Damit gehört GoL zur Kategorie von Simulationen des Artificial Life, die die Prozesse des wirklichen Lebens nachahmen. Jede Zelle entspricht einem Exemplar eines Organismus, welche im ständigen Kampf ums Überleben steht. Die Grundidee der Simulation ist es, beginnend mit einer Anfangskonstellation von lebenden Zellen, zu beobachten, wie sich die Zellen anhand der genetischen Gesetze von Conway entwickeln. Einige Zellen werden in die nächste Generation hineingeboren oder überleben, wenn sie eine ideale Umgebung (nach Conway) aufweisen und andere wiederum sterben entweder an Überbevölkerung oder an Einsamkeit. Conway wählte die Regeln nach vielen Experimenten aus, um folgende drei Kriterien zu genügen [Gar70]: 1. Es sollte keine Ausgangspopulation geben, für die ein trivialer Beweis geliefert werden kann, dass die Population im Laufe ihrer Entwicklung unendlich anwachsen kann. 2. Es sollte Inputkonstellationen geben, die scheinbar ohne Limit wachsen und komplexe Strukturen bilden können. 3. Es sollte Anfangszustände geben, die nach einer gewissen Entwicklungszeit, zu einer der drei möglichen Terminierungsarten kommen: a) vollständige Auslöschung infolge von Über- oder Unterbevölkerung, b) Übergang in einen unveränderlich stabilen Zustand, c) Einpendeln in eine endlose, oszillierende Schleife mit zwei oder mehreren Perioden. Durch diese Kriterien wird vermieden, dass das Verhalten bzw. die Populationsentwicklung bei einem gegebenen Anfangsmuster prognostizierbar ist. Der zugrundliegende Zellraum R von GoL ist ein zweidimensionales, rechteckiges l m Gitter (l, m N + ) aus Quadraten der wie folgt definiert ist: R = { i, j : i, j N, 0 i < l, 0 j < m}. Der Nachbarschaftsraum des binären Automaten GoL wird durch die Moore-Nachbarschaft mit dem Nachbarschaftsradius r = 1 definiert. Formal lässt sich die Nachbarschaft für eine Zelle an der Koordinate (i, j) wie folgt angeben: N M (i,j ) = {(x, y) R: x i 1, y j 1}. Die Nachbarschaft jeder inneren Zelle enthält demzufolge neun Zellen, bestehend aus der Kernzelle selbst und den acht Nachbarn. Die Randzonen bilden eine Ausnahme und richten sich an eine beliebig definierbare Randbedingung. Die genetischen Gesetze sind durch drei deterministische Regeln beschrieben [Gar70]: 23

30 1. Die Regel des Überlebens: Jede lebende Zelle zum Zeitpunkt t mit zwei oder drei lebenden Nachbarn besteht den Übergang in den Zeitpunkt t + 1 fort. 2. Die Regel des Todes: Jede lebende Zelle, die vier oder mehr lebende Zellen als Nachbarn besitzt, stirbt an Überbevölkerung und ebenso erlischt während des Übergangs die lebende Zelle mit einem oder keinem lebenden Nachbarn aufgrund von Isolation. 3. Die Regel der Geburt: Eine tote Zelle, die in der aktuellen Generation von genau drei lebenden Zellen umgeben ist, wird in der nächsten Generation wiedergeboren. Wenn man die möglichen Zustände {tot, lebend} durch äquivalente Werte {0, 1} ersetzt, lassen sich die Regeln durch die folgende Formel zusammenfassen, wobei z ij (t) die Zelle an der Koordinate (i, j) im Zellraum zum Zeitpunkt t angibt: 1, wenn z xy t = 3 z ij t + 1 = (x,y) N ij 1, wenn z xy t = 4 und z ij t = 1 (x,y) N ij 0, sonst. Die Regeln werden synchron auf alle Zellen angewandt, so dass alle Zustandsautomaten parallel den nächsten Zustand annehmen. Nur durch die drei Entwicklungsgesetze zeigt der GoL-Automat zur Klasse 4 gehörig schon ein relativ komplexes unvorhersehbares Verhalten, welches auch eine Vielzahl von Mustern mit verschiedenen Eigenschaften hervorbringt. Conway fragte sich diesbezüglich, ob eine Population mit endlich vielen Individuen im GoL über alle Grenzen hinaus wachsen könnte. Er setzte dafür einen Preis von $50 aus, welche schon Ende 1970 an eine Forschergruppe am MIT (Massachusetts Institute of Technology) ging. Diese Gruppe entdeckte eine oszillierende Struktur namens Gleiterkanone (siehe Abb. 2.19), die ab der 72. Generation 11 regelmäßig eine mobile Struktur bestehend aus fünf Zellen 12 (auch als Gleiter genannt) in jedem 30.Zeitschritt ausstößt. Ausgehend von bestimmten Startkonfigurationen soll nun näher auf die erzeugten Muster und Entwicklungen eingegangen werden, die GoL im Verlaufe der Simulationszeit hervorbringt. Abb. 2.19: Gleiterkanone Abb. 2.20: Dreizellige Ausgangspopulationen und deren zwei Entwicklungsschritte. 11 Eine Generation entspricht einem Zeitschritt. 12 Wenn von Zellen gesprochen wird, dann sind diese als lebende Zellen zu interpretieren; andernfalls werden diese eindeutig gekennzeichnet. 24

31 Ein Organismus mit ein oder zwei Zellen, unabhängig von ihrer räumlichen Anordnung, ist im GoL nicht überlebensfähig, da jede Zelle mindestens zwei lebende Nachbarzellen zum Überleben braucht. Auch Strukturen aus drei Zellen überstehen den ersten Übergang in den nächsten Zeitschritt (t + 1) nicht, es sei denn mindestens eine hat aktuell im Zeitpunkt t zwei lebende Nachbarn in ihrer Nachbarschaft. Es gibt aber auch die Möglichkeit, dass die dreizellige Struktur ohne nachbarschaftliche Beziehung überlebt, in dem sie einen Nachkömmling produziert (vergleiche Abb (c)). In Abb seien einige interessante Inputmuster und deren Entwicklung gezeigt: (a) zeigt bereits ein typisches Muster in GoL, bekannt als Blinker. Die mittlere Zelle kann bei dieser Konstellation überleben, allerdings dessen beiden Nachbarn (oben und unten der mittleren Zelle) erlischen aufgrund der Einsamkeit. Gleichzeitig werden zwei Zellen (links und rechts) geboren, da diese Zellen in t = 0 genau drei lebende Nachbarn hatten und so die Bedingung für die Anwendbarkeit der Geburtsregel erfüllt worden ist. In t = 1 hat das Muster also eine horizontale Form angenommen ebenfalls mit drei Zellen und dadurch bekommt man optisch den Eindruck, als ob die Struktur sich um 90 gedreht hat. Das Muster erlangt seine alte Form in t = 2 und hat hierdurch eine Oszillationsperiode von zwei Zeitschritten mit zwei annehmbaren Formen (horizontal und vertikal). Bei (b) würde eine ähnlich längere diagonale Kette im Verlaufe der Zeit ständig die beiden Enden verlieren - wie die Endstücke der Chromosomen (Telomere), die nach jeder Zellteilung sich verkürzen und so eine unendliche Zellteilung unterbunden wird, welche im nachhinein zur Alterung eines Organismus führt und so nach einer gewissen Zeit die Struktur von dem Raum verschwindet. Das letzte Muster (d) vervollständigt sich im ersten Zeitschritt zu einem stabilen Block aus vier Zellen, welcher sie zu ewigem Leben befähigt. Abb. 2.21: Unveränderliche Muster im GoL Mit wachsender Anzahl von Zellen als Input und deren unterschiedlichen räumlichen Anordnungsmöglichkeiten steigt die Quantität möglicher Ausgangspopulationen immens an, die im Verlaufe der Entwicklung weiteren Mustern und Verhaltenskomplexitäten den Weg ebnen. Die Überlebenschance der Ausgangspopulation steigt auch entsprechend an, indem es stationär stabile Muster und/oder periodisch oszillierende Strukturen als Nachkommen produziert. Abb stellt einige stabile Konfigurationen, auch als Stilleben bekannt, dar (es gibt ferner andere räumlichorientierte Varianten derselben Struktur), die ohne Einfluss von außen (zum Beispiel Kollision verursacht durch mobile Objekte) unvergänglich existieren würden. Jede Zelle dieses Musters 25

32 besitzt genau zwei oder drei lebende Nachbarn, um zu überleben, und keine der toten Zellen in der Nähe besitzt drei lebende Zellen, so dass keine neuen Zellen zu dem bestehenden Muster im folgenden Zeitschritt hinzukommen. Einige der vorgestellten Stilleben, wie zum Beispiel Boot, Schiff, Fähre und sinkendes Schiff können durch Verlängern der diagonalen Elemente beliebig vergrößert werden, ohne deren stabile Eigenschaft zu verlieren. Eine weitere häufig anzutreffende Musterart im GoL sind die bereits erwähnten zyklischen bzw. oszillierenden Strukturen mit unterschiedlicher Periodizität, wobei diese selbst in zwei Untertypen, stationär oder mobil, geteilt werden können. Bei Stilleben handelt es sich um einperiodischeoszillierende Muster. Die Anwendung der Regeln bewirkt, dass eine Struktur nach verschiedenen Zwischenformen zu ihrem Ausgangsmuster zurückkehrt und zu einem Zyklus sich vervollständigt. Abb zeigt auszugsweise drei Beispiele zu solchen Mustern (es existieren im allgemeinen Muster von zwei- bis weit über hundertperiodische Zyklen; aber laufend werden neue Muster (- kombinationen) entdeckt): Pentapole besteht stets aus elf Zellen und hat einen zweiperiodischen Zyklus. Es scheint dem Betrachter so, als ob zwischen den zwei dreizelligen Endungen ständig Energieteilchen ausgetauscht werden. Der wesentlich komplexere Pulsar (Analogie besteht zur rhythmischen Aussendung von Synchrotronstrahlung eines Pulsars) nimmt drei verschiedene Formen im Verlaufe seiner Oszillation an und die Fontäne, von der wesentlich komplexere Varianten existieren, kehrt in jedem vierten Zeitschritt zu ihrem Ausgangsmuster zurück. Abb. 2.22: Beispiele für periodische Muster in GoL Die dritte Hauptgruppe bilden die mobilen Strukturen, wobei diese Gruppe als bewegliche Objekte (neben den stationären wie dem Blinker) unter den Oszillatoren eingeordnet werden kann. Denn jedes mobile Objekt nimmt während seiner Reise zyklisch eine endliche Menge von Formen an. Allgemein werden diese Objekte als Raumschiffe bezeichnet, unter denen der kleinste und bekannteste der Gleiter ist. Die Objekte verdanken, wie alle andere Vorgänge im GoL auch, ihre Mobilität grundsätzlich dem evolutionären Prozess auf der Zellebene, der hervorgebracht wird durch die genetischen Gesetze. Die Vorwärtsbewegung eines Musters wird dadurch bewerkstelligt, dass 26

33 hierbei, abstrakt betrachtet, im vorderen Bereich neue Zellen geboren werden und im hinteren Teil eine bestimmte Anzahl von Zellen sterben. Für den Betrachter erscheint dieser Vorgang als eine Bewegung, da das Objekt seine Form (wenn man von den Transitionen zu den einzelnen Zwischenformen absieht) im Prinzip beibehält. Jeder Gleiter besteht aus fünf Zellen und nimmt in seiner Oszillationsperiode insgesamt vier verschiedene Muster an. Abhängig von der räumlichen Orientierung des Ausgangsmusters kann er diagonal in einer der vier verschiedenen Richtungen im Zellraum fliegen: Nordost, Südost, Südwest und Nordwest. Es gibt also insgesamt vier verschiedene Gleiter und sechszehn Zwischenformen, die sich nach der räumlichen Orientierung unterscheiden (siehe Abb. 2.23). Ein rotes X auf der gegenwärtig lebenden Zelle zeigt an, dass diese Zelle beim Übergang im kommenden Zeitschritt nicht überleben wird. Ein weißer Stern auf einer momentan toten Zelle impliziert, dass diese Zelle im nächsten Zeitschritt wiedergeboren wird. Der Gleiter verliert also im hinteren Teil zwei Zellen, aber bekommt gleichzeitig zwei neue Zellen im vorderen Bereich. In vier Schritten (sobald der Gleiter wieder seine Ausgangsform angenommen hat) bewegt sich der Gleiter jeweils eine Zelleinheit 13 auf der x-achse (nach links oder rechts) und der y-achse (nach oben oder unten), welche kombiniert einen Diagonalschritt ergeben. Theoretisch lässt sich auch die Geschwindigkeit eines mobilen Objekts messen: Die Maximalgeschwindigkeit im GoL ist definiert als die Bewegung (diagonal oder orthogonal) um eine Zelle pro Zeitschritt, welche als die Lichtgeschwindigkeit c bezeichnet wird. Zur Berechnung der Geschwindigkeit eines beweglichen, sich selbst reproduzierenden Musters teilt man die Anzahl der Zellen, die es in einem Reproduktionszyklus durchläuft, durch die Anzahl der dafür benötigten Zeitschritte. Der Gleiter benötigt vier Zeitschritte zur Vollendung seines Zyklus und gleichzeitig bewegt er sich diagonal um eine Zelle. Damit fliegt der Gleiter mit einem Viertel der Lichtgeschwindigkeit c 4. Ein weiteres diagonal fliegendes Muster (Abb. 2.24)ist das Raumschiff Enterprise (mit vier Zwischenformen in einem Zyklus), das ebenfalls eine Geschwindigkeit von c 4 erreicht. Abb. 2.23: Die vier verschiedene Gleiter Abb. 2.24: Raumschiff Enterprise 13 Eine Zelleinheit ist die Größe einer Zelle. 27

34 Zu den orthogonal fliegenden Mustern gehört der Fisch (auch bekannt als Lightweight Spaceship ), welcher sich mit halber Lichtgeschwindigkeit c 2 durch den Raum bewegt (siehe Abb. 2.25). Denn er braucht vier Zeitschritte für einen kompletten Zyklus und bewegt sich gleichzeitig orthogonal (abhängig von der Ausgangskonstellation nach Nord, Ost, Süd oder West) zwei Zellen vorwärts, woraus sich 2c 4 ergibt. Abb. 2.25: Eines der schnellsten Flugobjekte im GoL: Fisch Bereits zu den erwähnten drei Typen (Stilleben als Typ I, Oszillatoren als Typ II und Raumschiffe als Typ III) können weitere Musterarten nach ihrer Charakteristika klassifiziert werden. Zur Typ IV - Kategorie gehören diejenigen Muster an, deren Populationsgröße kontinuierlich steigt. Dazu gehören Gleiterkanonen, die als Oszillatoren regelmäßig in jedem Zyklus Raumschiffe emittieren. Puffer sind eine bestimmte Klasse von Raumschiffen, die bei ihrem Flug Stilleben, Oszillatoren und/oder weitere Raumschiffe als Schweif erzeugen. Die dritte Untervariante sind die Brüter- Muster, die es schaffen ihre Population quadratisch oder schneller zu vermehren (z.b. das Muster namens Metacatacryst mit der kleinsten Ausgangspopulation von 52 Zellen mit quadratischem Wachstum). Zuletzt gibt es noch die Typ V-Kategorie der Instabilen, die eine Folge von Zuständen durchleben und niemals zum Ursprung zurückkehren. Diese kleinen Muster entwickeln sich lange chaotisch, bevor sie in eine stabile Endphase übergehen (Methusalem; Beispiel r-pentomino). Meistens lässt sich nicht im Voraus erkennen, wie sich eine Ausgangskonfiguration weiterentwickelt: Wenn anfangs die Zellen zufällig in einem großen Zellraum verteilt werden, lässt sich nur durch aufwendige Berechnung bzw. Simulation erfassen, ob (a) eine Population aussterben wird, (b) durch Ausbildung von stabilen oder oszillierenden Mustern sich verewigt, oder (c) durch Emission von mobilen Objekten in unbekannte Regionen vorstößt. Eines dieser Muster ist das sogenannte r-pentomino (Chaotica), bestehend aus nur fünf zusammenhängenden ( rookwiseconnected ) Zellen, welches schöpferisch verschiedenartige Strukturen wie Blinker, mehrere stabile Muster (Block, Boot, Bienenkorb, Brötchen) und Gleiter während des Zeitverlaufes produziert (siehe Abbildung 2.26). In einem unendlichen Raum würde r-pentomino sich kontinuierlich ausdehnen. Dieses Muster zeigt auch beispielhaft die dynamischen Prozesse, die während der Entwicklung im GoL mit bemerkenswerter Analogie zu realen Abläufen auftreten. Durch Kollisionen bzw. Verschmelzen von zwei oder mehreren unabhängigen Strukturen werden kettenreaktionäre Prozesse angestoßen, die eine stabile 14 Umgebung wieder zum Leben erwecken: zum Beispiel wird der stabile Block oder der oszillierende Blinker durch einen anfliegenden Gleiter reaktiviert bzw. aus seinem Zyklus befreit. Es ist erdenklich, dass gerade eine Kollision die Aufspaltung eines strukturell stabilen Musters in mehrere neue Strukturen veranlasst, oder einer der kollidierenden Objekte vollständig zerfällt, während der Kollisionspartner ohne strukturellen Wandel weiter existiert. Das Ergebnis einer Kollision und die dadurch ausgelöste Varianz in der Entwicklung wird von 14 Eine stabile Umgebung kann neben unveränderlichen Mustern auch räumlich-begrenzte Oszillatoren aufweisen, die global den Zellraum nicht nachhaltig verändern. 28

35 verschiedenen Faktoren beeinflusst. Je nachdem aus welcher Richtung bzw. Winkel die Objekte sich zubewegt haben und abhängig von der strukturellen Form, die sie während der Kollision besaßen, wird über die nachfolgende (lokale und globale) Entwicklung der nächsten Generationen oder ihrer Existenz entschieden. Abbildung 2.26: r-pentomino und dessen Entwicklungsstadien in t = 0, t = 75 und t = 210. Es ist nicht direkt ersichtlich, was die drei einzelnen Regeln in ihrer Einfachheit, aber dennoch in ihrer Gesamtheit zu befähigen vermögen (Nichtlinearität). Die definierte Evolution der Zellen bestimmt letztendlich die Nebeneffekte, wie die Erzeugung von verschiedenen strukturellen Objekten mit Eigenschaften wie Stabilität, Oszillation und Mobilität, die sich unter Umständen erst spät aus einer Ausgangspopulation entwickeln. Die Ausgangspopulation spielt ebenso bei der Entwicklung eine große Rolle und lässt sich folgendermaßen interpretieren: Sie bildet die genetische Ausstattung bzw. Grundlage des zukünftigen Organismus, die über den Überlebenserfolg in einer von den Entwicklungsregeln ( Selektionsdruck ) und der Raumstruktur definierten Umwelt entscheidet. Anfangsmuster, die stabile oder oszillierende Strukturen hervorbringen, sind die Überlebenskünstler im GoL, da diese im abstrakten Sinne eine optimale soziale Struktur mittels Informationsaustausch zum Überleben aufbauen. Die noch besser an die Bedingungen des GoL angepassten und durch deren genetischen Code befähigten Muster erschließen durch ihre Mobilität neue Lebensräume. Conway s GoL erlaubt sogar die Konstruktion eines abstrakten Rechners auf der Grundlage der kleinsten Informationseinheiten, den Bits. Alle Daten können durch eine Abfolge von Nullen (Strom aus) und Einsen (Strom an) kodiert, manipuliert und gespeichert werden. Den abstrakten Stromfluss stellt die bereits vorgestellte Gleiterkanone bereit: Folge von Gleitern, die die Gleiterkanone regelmäßig alle 30 Zeitschritte emittiert, sind im GoL das Ebenbild zu elektrischen Impulsen welche eine konstante Bitfolge (1111 ) bilden. Die Periodenlänge der Gleiterkanone bildet auch die Länge des Arbeitstaktes eines zellulären Rechners. Um Nullen zu erzeugen, müssen einige der Gleiter im Gleiterstrom eliminiert werden, indem man manuell einige Gleiter schickt, so dass diese durch Kollision sich gegenseitig auslöschen (Voraussetzung für die Auslöschung der beiden Gleiter ist ein Aufprallwinkel von 90 ). In derselben Weise lässt sich auch der logische NOT- Operator simulieren: Als Input wird eine bestimmte Folge von Gleitern in bestimmten Abständen eingegeben (wenn an einer Stelle ein Gleiter vorhanden ist, bedeutet es 1, andererseits 0), die 29

36 negiert werden sollen. Diese Gleiter kollidieren dann mit dem Gleiterstrom der Gleiterkanone (vgl. Abb. 2.27). War im Inputstrom an einer bestimmten Position kein Gleiter vorhanden (0), so passiert der von der Gleiterkanone ausgesandte Gleiter ungehindert als Output durch, so dass die 0 vom Input verneint wird und eine 1 als Output (an dieser bestimmten Position) entsteht. Auch die anderen zwei Basisoperatoren bzw. Gatter (UND, ODER) als elementare Grundbausteine von Schaltungsnetzen lassen sich mit Hilfe der Gleiterkanone realisieren. Der UND-Operator lässt sich auch durch die Auslöschungsreaktionen erzeugen (siehe Abb. 2.28): Der Strom einer Gleiterkanone (G) negiert den Input (A), welche dann in verneinte Form auf den Input (B) trifft. Daraus ergeben sich zwei Ströme, wobei eines davon A B ergibt und der andere, nicht benötigte Strom, durch einen Fresser 15 (F) vertilgt wird. Für die Realisierung des ODER-Gatters wird genau dieser unerwünschte Strom benötigt, denn dies stellt genau die Verknüpfung (A B) dar, welche durch eine erneute Auslöschungskollision mit dem Strom einer weiteren Gleiterkanone in die Verknüpfung A B überführt wird. Der erste nicht erforderliche Strom wird von einem Fresser eliminiert. Abb. 2.27: Simulation von NOT-Gatter Abb. 2.28: Realisierung der UND-/ODER-Operator Aufbauend auf den drei Operatoren lassen sich komplexe Schaltnetze aufbauen, z.b. Addierer oder Multiplexer (MUX), aber auch zur Speicherung von Daten durch Flipflops. Zwar sind diese Schritte die ersten und einfacheren Teile der Konstruktion (für weitere Details zur Konstruktion eines Rechners mit Hilfe von GoL sei auf [BCG2003] verwiesen), aber nur mit den Mitteln von GoL lässt sich theoretisch eine universelle Turingmaschine anfertigen. 15 Fresser ist das horizontal gespiegelte Angelhaken-Muster. 30

37 2.4 Monitoring diskreter Prozesse Nachdem wir uns mit dem ereignis-erzeugenden künstlichen Szenario ausführlich beschäftigt haben, wenden wir uns nun den Grundlagen der Monitoringaufgaben zu. Für uns sind die folgenden Ereignisse von Bedeutung: das Auftreten von Zusammenhangskomponenten (Clustern); das Erkennen von bestimmten Mustern; die Flugbahnverfolgung von mobilen Mustern und die Erkennung von bevorstehenden Kollisionen zwischen (durch Clustering gebildeten) Objekten. Für diese Themen wird es nun eine bündige theoretische Einführung gegeben, aber vorher wollen wir auf diskrete Prozesse eingehen. Prozesse lassen sich durch ihre Anfangs- und Endpunkte charakterisieren und ebenso nach der Art der Veränderungen die sie währenddessen vollziehen. So können die Prozesse in kontinuierliche und diskrete Prozesse unterteilt werden (vgl. Abb. 2.29). Kontinuierliche Prozesse beschreiben im Allgemeinen physikalische Vorgänge, bei denen inkrementelle Veränderungen (zum Beispiel die Trajektorienänderung eines bewegenden Objekts) stetig stattfinden. Die kontinuierlichen Prozesse lassen sich weiter klassifizieren in Prozesse mit expliziten Startpunkten (Initiierung), Prozesse mit gegebenen Endpunkten (Stillstand) und Prozesse deren Start- und Endpunkte irrelevant sind (Fortdauer). Diskrete Prozesse stellen dagegen eine Approximation von physikalischen Abläufen dar, bei dem die Veränderungen in einzelnen Zeitschritten geschehen (Ereignisse), getrennt durch Phasen von inaktiven Zuständen [Sow00]. Abb. 2.29: Arten von Prozesse [Sow00] Für die Informationsverarbeitung oder allgemein für die Erforschung von kontinuierlichen Sachverhalten ist eine Diskretisierung unumgänglich: Die Messung der (physikalischen) Größen erfolgt in regelmäßigen Zeitabständen und man gewinnt hierdurch eine endliche Datenmenge aus einer kontinuierlichen Informationsmenge, so dass diese in endlicher Zeit mit beschränkten Ressourcen bearbeitet werden können. Aus der diskreten Datenmenge lässt sich durch Interpolation der fehlenden Werte (entspricht der Abtastung in viel kleineren Zeitintervallen (t 0)) aus dem diskretisierten kontinuierlichen Prozess wieder approximieren. Es sei noch eine formale Definition eines diskreten Prozesses gegeben [Sow00]: 31

38 Definition 2.3: Ein diskreter Prozess DP ist ein azyklischer, gerichteter, bipartiter Graph (Z, E, B), wobei Z eine Menge von Zustandsknoten, E eine Menge von Ereignisknoten und B eine geordnete Tupelmenge, die als Bogen (bzw. Kanten) benannt ist, darstellen. Es gilt: Z E = {} ; x, y B, dann stellt ein Knoten den Zustand, der andere das Ereignis dar und man sagt, dass der Knoten x einen kausalen Einfluss auf den Knoten y hat; der kausale Einfluss ist transitiv: x, y B y, z B (x, z) B; wenn b = z, e, b B, z Z und e E ist, dann ist b die Eingangskante von e und z der Eingangszustand von e; wenn b = e, z, b B, e E und z Z, dann stellt b die Ausgangskante von e und z der Ausgangszustand von e dar; diskrete Prozesse können aus einem einzigen Zustand, aber auch aus einem einzelnen Ereignis bestehen, jedoch nur dann, wenn dieses weder Eingangs- noch Ausgangskanten hat. Nun gilt es die im diskreten Prozess stattfindenden Ereignisse systematisch zu erfassen. Nicht alle auftretenden Ereignisse sind von Bedeutung, sondern nur die, die uns als sinnvoll erscheinen, bemerkt zu werden (z.b. bei gravierender Veränderung des Systemzustands, die unsere Aufmerksamkeit erfordert), für welche wir zur Wahrnehmung Erkennungsalgorithmen definieren. Der Sinn des Monitoring besteht darin, bei Identifizierung eines Ereignisses weitere, eventuell entgegen steuernde Prozesse in Gang zu setzen. Wir werden uns aber auf die Stufe des Monitorings beschränken und für weitergehende Analysen die Ereignisse in der Datenbank protokollieren. Im Folgenden werden die theoretischen Grundlagen zu den einzelnen, für uns interessanten Monitoringaufgaben aufgeführt Clustering Clustering (Clusterbildung/-analyse) ist ein sehr verbreitetes Instrument zur Datenanalyse und stellt für diesen Zweck eine Vielzahl verschiedener Verfahren zur Verfügung. Ziel dieser automatischen Klassifikation ist die Zuordnung einzelner Objekte zu einer eindeutigen Gruppe (Cluster) oder anders ausgedrückt, man zerlegt eine vorgegebene Menge von Objekten in eine endliche Anzahl von Gruppen, so dass Strukturen innerhalb der Menge sichtbar werden. Clustering kann deshalb auch als eine Anwendung des unüberwachten Lernens angesehen werden, bei der es logische Strukturen aus der für ihn noch unbekannten bzw. beliebigen Datenmenge erzeugt (und dadurch erkennt ). Die Objekte, die zu einer Struktur gehören, weisen demnach gemeinsame Eigenschaften auf (Homogenität im Cluster), und auf der makroskopischen Ebene sind die Gruppen ungleichartig zueinander (Heterogenität zwischen den Clustern). Es findet eine Klassifikation der Objekte anhand der definierten Kriterien und Anforderungen des Anwendungsgebietes statt. Die durch Clustering betriebene Klassifizierung bzw. Segmentierung der Objektmenge und die dadurch erreichte Wissensgenerierung wird heute in verschiedenen Anwendungsgebieten verwendet. Im Marketing werden enorme Mengen von Daten bzgl. des Einkaufsverhaltens, zusätzlich zu den persönlichen Informationen der Kunden, über einen zeitlichen Horizont gesammelt und analysiert (OLAP Datawarehouse Prozess) und in verschiedene Kundengruppen eingeteilt. In der 32

39 Evolutionsbiologie wird Clusteranalyse zur Offenlegung von Artenstammbäumen durch Ermittlung des DNA-Abstandes eingesetzt. Als Ergebnis liegt dann eine hierarchische Klassifikation vor, welche dann zu einem Stammbaum assoziiert wird [Har75]. Ein weiteres Einsatzgebiet liegt in der Bildverarbeitung, genauer im Prozess der Mustererkennung. Dabei unterstützen Clusterverfahren in der Lernphase des Erkennungssystems, aus einem großen Pool von Beispiel-Mustern charakteristische Referenzmuster zu erfassen. Dies kommt in der Handschrifterkennung im Bankenbereich zum Einsatz, zum Beispiel für die automatische Auslesung und Weiterverarbeitung der Schriften aus Überweisungs- oder Scheckformularen. Generell lässt sich Clustering unterteilen in die hierarchischen und die partitionierenden Verfahren. Hierarchische Clusterverfahren produzieren Cluster sukzessiv aus vorher erstellten Clustern, d.h. jedes Objekt wird bei Initialisierung des Verfahrens bereits einem Cluster zugeordnet. Ein Distanz- oder Ähnlichkeitsmaß wird benutzt, um eine gegebene Aufteilung von Clustern zu kombinieren oder zu trennen, um so neue Cluster der angestrebten Gruppierungshierarchie zu erreichen. In hierarchischen Clusterverfahren selbst werden zwischen agglomerativen und divisiven Verfahren unterschieden. Agglomerative Verfahren arbeiten nach dem bottom-up -Prinzip, bei der alle n Objekte anfangs selbst einzelne Cluster darstellen. Die ein-elementigen Cluster werden dann nacheinander verschmolzen bis der erwünschte Gruppierungsgrad erreicht wurde. Dagegen arbeiten divisive Verfahren top-down, wobei der anfänglich einzige Cluster (der alle n Objekte beinhaltet) in kleinere Cluster verfeinert wird. Die partitionierenden Verfahren gehen von einer vordefinierten Clusteranzahl k aus, wobei jedes Objekt sukzessiv in die Klasse eingeteilt wird, deren Ähnlichkeit zu eine der k initialen Cluster-Repräsentanten als Schwerpunktzentren (welche im späteren Verlauf optimiert werden) am größten ist (z. B. der k-means-verfahren). [Spä75] Wir konzentrieren uns hier auf graphen-theoretische Methoden zum Clustering basierend auf [Boc74; S.298ff.]. Um die Gleichartigkeit der Objekte zu ermitteln, müssen jedoch die Objekte vergleichbar sein (z.b. auf Basis numerischer Größen). Die Ähnlichkeit der Objekte wird durch das Ähnlichkeits- und Distanzmaß festgelegt. Die Ähnlichkeit zweier Objekte o j, o k wird durch einen Zahlenwert a jk [0,1] ausgedrückt (wobei für Fälle k j die Null keine Ähnlichkeit und die Eins als sehr ähnlich zu interpretieren ist). Für N Objekte lassen sich die Ähnlichkeitsstrukturen durch eine N N Matrix repräsentieren. Die einzelnen Einträge a jk der Ähnlichkeitsmatrix (welche das Ähnlichkeitsmaß a auf der Objektmenge O festlegt) genügen folgenden Bedingungen [Boc74; S.24f.]: a kj = a jk wobei 1 j, k N (Symmetrie) a kj 0 1 j, k N a kj a kk 1 j, k N a kk = 1 1 j, k N Analog ist die Verschiedenheit zweier Objekte o j, o k als Distanz durch eine reelle Zahl d jk darstellbar, vorausgesetzt: d kj = d jk wobei 1 j, k N (Symmetrie) d kj 0 1 j, k N d kk = 0 1 k N 33

40 Die N N Matrix (d kj ) wird als die Distanzmatrix bezeichnet und sie legt auf die Objektmenge O ein Distanzmaß d fest. Aus graphentheoretischer Sicht lassen sich die zu gruppierenden Objekte als eine Punktmenge im euklidischen Raum darstellen. Die Objekte bilden die Knotenmenge V, welche die Kantenmenge E des zu bildenden vollständigen 16 und ungerichteten Graphen G = (V, E) induziert. Die Distanz d(u, v) bzw. die Länge der Kante zwischen zwei Knoten u und v entspricht dem Abstand zwischen den Objekten o u und o v, der einer Distanzfunktion (beispielsweise die Mahalanobis-Distanz [Boc1974, S.40f.] oder dem euklidischen Abstand 17 ) zu Grunde liegt. Das Ziel ist, es aus einem Graphen durch Löschung der Kanten, die eine bestimmte Länge überschreiten, Zusammenhangskomponenten zu finden, die dem gewünschten Gruppierungsgrad entsprechen. Definition 2.4 (Ungerichteter Graph): Ein Graph G = (V, E), bestehend aus der Menge V von Knoten und der Menge E von Kanten, heißt ungerichtet, wenn für die Kantenmenge gilt: (u, v) E mit {u, v} V und u v. [Bai04] Wir gehen auf die Ebene der Objekte zurück: Um eine Objektmenge O zu gruppieren, d.h. zu einem gegeben Objekt o k O ähnliche Objekte zu ermitteln, die dann eine Teilmenge A O bilden, wählen wir eine beliebige, aber feste Distanzschranke d > 0. Zwei Objekte o j, o k sind ähnlich zueinander genau dann, wenn für die Distanz (ausgehend von dem Eintrag in der Distanzmatrix) zwischen beiden Objekten d jk d gilt. Die Menge aller Objekte o j O, deren Distanz kleiner als d ist, bildet die d -Umgebung von o k. Jede so entstehende Teilmenge A O ( Gruppe ) sollte den folgenden Bedingungen genügen: i. A darf nicht leer sein. ii. Mit jedem Objekt o k O soll auch die ganze d-umgebung von o k zu A gehören. Mit A, B O erfüllt jedoch auch die Vereinigung der beiden Mengen die Kriterien i und ii. Aber da wir möglichst kleine und homogene Gruppierungen zu erreichen versuchen, ist zusätzlich die folgende Bedingung notwendig: iii. Keine in A enthaltene Teilmenge B (A B) darf i und ii entsprechen. Eine Teilmenge A O, die die erwähnten drei Kriterien erfüllen, heißt Gruppe der Stufe d. Zur Konstruktion einer Gruppe der Stufe d beginnt man mit einem beliebigen Objekt und nimmt iterativ alle Objekte in seiner d -Umgebung hinzu, ebenso deren d -Umgebung. Eine vollständige Gruppe A der Stufe d ist ermittelt, wenn keine Erweiterung mehr möglich ist. Sind noch weitere Objekte als Restmenge der Gesamtobjektmenge O übrig, lässt sich wieder ausgehend von einem Startobjekt auf ähnliche Weise verfahren, bis alle Objekte der Menge O zu einer Gruppe A zugeordnet werden. Die Menge O zerfällt auf dieser Weise in m (disjunkte) Partitionen P = {A 1,, A m }. Die Adjunktion-Reihenfolge der Objekte hat dabei keinen Einfluss auf das Resultat. 16 Vollständiger Graph: Wenn bei einem Graph G mit V = N alle möglichen Kanten existieren, ist der Graph G vollständig. 17 Der euklidische Abstand zwischen zwei Punkten p 1 = (x 1, y 1 ) und p 2 = (x 2, y 2 ) ist definiert durch (x 1 x 2 ) 2 + (y 1 y 2 ) N 2

41 Ebenso gilt, dass die Distanz zwischen zwei Objekten, die jeweils zu verschiedenen Gruppen A p, A q gehören, stets größer als d beträgt. Eine solche Zerlegung der Menge in Gruppen entspricht auf Ebene der Graphen, einer disjunkten Teilung des vollständigen Graphen in ein oder mehrere Zusammenhangskomponenten: Sei ein vollständiger Graph G mit V = N N + und alle möglichen Kanten N 2 gegeben. Den Kanten werden nun die Einträge der Distanzmatrix als Länge zugeteilt, bei dem die Kante (u, v) E, die die beiden Knoten u, v verbindet, den Wert d uv zugewiesen bekommt und so ein bewerteter Graph entsteht. Bei einer gegebenen Distanzschranke d > 0 werden diejenigen Kanten aus dem Graphen entfernt, deren Länge größer als d ist. Es entsteht dadurch ein Teilgraph G(d) von G (kurz: G), der nur noch Kanten der Länge d enthält (jedoch alle Knoten!) [Boc74]. Durch den Wegfall von Kanten sind nicht alle Knoten von anderen erreichbar. Die Knoten des Graphen zerfallen in disjunkte Klassen A 1,, A m, die als Zusammenhangskomponenten des Graphen bezeichnet werden. Jede Zusammenhangskomponente von G(d) enthält nur die Knoten, die durch einen Weg (eine Abfolge von Kanten) miteinander verbunden sind (z.b. basiert der Single-Linkage Algorithmus hierauf [DHS01; S.566f.]). Definition 2.5 (Teilgraph) 18 : Ein Graph G = (V, E) ist ein Teilgraph von G = V, E, falls für die Knotenmenge V V und die Kantenmenge E E gilt. Ist nun eine Teilmenge V V gegeben, dann ist der durch V induzierte Teilgraph von G der Graph G = (V, E) mit E = u, v E: u, v V. [CLRS07] Definition 2.6 (Zusammenhängend, Zusammenhangskomponente): Sei G = (V, E) ein ungerichteter (Teil-)graph und V V. V ist zusammenhängend, falls je zwei Knoten u, v V voneinander erreichbar sind. V heißt Zusammenhangskomponente von G, falls V eine nichtleere, maximale zusammenhängende Knotenmenge ist. Maximalität heißt, dass V in keiner anderen zusammenhängenden Teilmenge V von V enthalten ist. G heißt zusammenhängend, falls V zusammenhängend ist. [Bai04] Die Gültigkeit der graphentheoretischen Methode zur Gruppierung bzw. zum Clustering wird begründet durch: Satz 2.1: Die Zusammenhangskomponenten des Teilgraphen G(d) von Graph G entsprechen den Gruppen der Stufe d. Durch Variierung der Distanzschranke d lässt sich eine Clustering-Hierarchie erreichen. Sei d 1 > d 2 > 0: Satz 2.2: Eine Gruppierung der Stufe d 2 aus der Gruppierung der Stufe d 1 entsteht dadurch, dass alle Gruppen der Stufe d 1 (ausgenommen der einelementigen Gruppen) in disjunkte Untergruppen zerlegt werden (Verfeinerung). Umgekehrt ergibt sich jede Gruppe der Stufe d 1 durch Vereinigung der verschiedenen Gruppen der Stufe d 2 (Vergröberung). 18 Wichtig: In dieser Arbeit gilt stets V = V, denn jede lebende Zelle muss (sprich Knoten) zu einer Zusammenhangskomponente, also zu einem Cluster zugeordnet werden. Bei der Kantenmenge kann E E gelten. 35

42 Im Rahmen von GoL ist ein bewerteter Graph durch ein Muster, welches sich in dem gesamten Zellraum zu einem gegebenen Zeitpunkt ausbildet, vorgegeben: Die Menge der lebenden Zellen entspricht der Knotenmenge V und zunächst besteht die Kantenmenge aus V 2 Kanten, womit alle Zellen durch imaginäre Kanten miteinander verbunden sind. Wir setzen jedoch die theoretische Distanzschranke d = 1.5 (Zellgröße, um auch die Diagonalzellen innerhalb der Moore- Nachbarzellen zu erfassen (als Basis dient hierbei der euklidische Abstand, jedoch ist dieser bei der DB-Implementierung zu vernachlässigen, da die direkten Nachbarn stets die Distanz eins haben)), so dass nur noch die direkt benachbarten Zellen miteinander durch eine Kante verknüpft sind und daraus sich letztendlich die Zusammenhangskomponenten ergeben. Jetzt soll ein Graph-Traversierungsalgorithmus vorgestellt werden, der als Basis für die Implementierung zur Auffindung von Zusammenhangskomponenten eingesetzt wird. Es handelt sich um die Breitensuche (engl. Breadth-First-Search, kurz BFS), die im Rahmen des eigen-konstruierten Clustering-Algorithmus eingesetzt wird. Ausgangspunkt ist der ungerichtete (jede Kante mit eins bewertete) Teilgraph G = (V, E): BFS (G, s) a farbe [s] GRAU b Q c EINFÜGEN (Q, s) d while Q e do u ENTNEHMEN (Q) f for v Adj[u] g do if farbe v = WEISS h then farbe v GRAU i EINFÜGEN (Q, v) j farbe [u] SCHWARZ k s_zsh s_zsh u CLUSTERING (G) 1 V V 2 i 0 3 ZSH[ V ] 4 for Knoten u V 5 do farbe [u] WEISS 6 while V 7 do wähle_startknoten s V 8 BFS (G, s) 9 ZSH[i] s_zsh 10 V V s_zsh 11 s_zsh 12 i i

43 Die Breitensuche ist ein Durchsuchungsalgorithmus eines Graphen, der auch bei der Berechnung der Zusammenhangskomponenten eines ungerichteten Graphen eingesetzt werden kann. Für einen gegebenen Graph G = (V, E) wird mit CLUSTERING (G) der Algorithmus gestartet. Zur Initialisierung wird (1) die Knotenmenge V auf einer Datenstruktur (z.b. eine Liste) V abgelegt und i auf 0 gesetzt (2). Primär dient i als die Zugriffsvariable für die Arrayfelder des V -großen Arrays 19 ZSH[] (welche in (3) initialisiert wird), aber anderseits gibt der Wert von i nach Abschluss des Algorithmus die Anzahl der gefundenen Zusammenhangskomponenten wieder. In (4)-(5) wird der Variablen farbe bei allen Knoten der Wert WEISS zugewiesen und damit schließt die Hauptinitialisierung ab. Nun wird aus der Knotenmenge der ersten Knoten (bildlich der links-obere Knoten im Graphen) ausgewählt (7) und BFS (G, s)-algorithmus aufgerufen (8). Dieser soll ausgehend vom Startknoten alle von ihm erreichbaren (es existiert ein Pfad) Knoten in Form einer Liste (s_zsh ) zurückliefern, sprich einer Zusammenhangskomponente. G ist der Graph, der durch die in V noch enthaltenen Knoten induziert wird, da die Knotenmenge V im Verlaufe des Algorithmus abgebaut wird. Der Startknoten wird bereits als entdeckt GRAU markiert (a). Die Farbe GRAU stellt die Front zwischen den entdeckten und unentdeckten Knoten dar, denn von einem entdeckten Knoten können noch Kanten ausgehen, die sich mit noch unentdeckten Knoten der Farbe WEISS verbinden. Die Breitensuche verdankt ihren Namen der Tatsache, dass die Front sich gleichmäßig über die gesamte Breite vorwärts bewegt: Der Algorithmus erschließt zunächst diejenigen Knoten, die den Abstand k (Anzahl der Kantenabfolge) vom Startknoten s haben, bevor irgendein Knoten im Abstand k + 1 entdeckt wird. Bei (b) wird eine leere FIFO-Warteschlange Q initialisiert und der Startknoten wird zur Abarbeitung mittels EINFÜGEN (Q, s) in (c) eingereiht. Der Code-Abschnitt (d) (k) stellt den eigentlichen Traversierung-Algorithmus dar, bei dem solange die Warteschlange Q nicht leer ist, fortwährend der erste Knoten u entnommen wird (e) und mittels der Adjazenzliste 20 von u die verbundenen Nachbarknoten besucht werden (f), solange diese noch nicht als entdeckt (g) gelten. Die gerade entdeckten die GRAU gefärbten (h) werden in der Wartschlange hinten eingeordnet (i), um aus diesen wiederrum weitere unentdeckte Knoten zu erfassen. Der abgearbeitete Knoten u wird als SCHWARZ markiert (j) und anschließend in die Liste s_zsh eingefügt (k). Ist ein Knoten u SCHWARZ und gilt (u, v) E, dann ist der Knoten v entweder GRAU oder SCHWARZ gefärbt, d.h. alle benachbarten Knoten von u wurden bereits entdeckt. s_zsh enthält gerade die Knoten nach Abschluss des BFS (G, s)-algorithmus, die von dem Startknoten s erreichbar waren. Diese Knotenmenge bildet eine Zusammenhangskomponente, welche nun (9) im Array ZSH[] an der i-ten Stelle als eine Liste abgelegt wird. Diese Knotenmenge wird von V entfernt (10) und die Liste s_zsh geleert (11). Die while-schleife (6) wird solange ausgeführt, bis jeder Knoten einer Zusammenhangskomponente zugeordnet worden ist. 19 Im schlimmsten Fall bilden alle Knoten jeweils eine eigenständige ( V = N) Zusammenhangskomponente; ansonsten kann zur Speicherplatz-Effizienz eine dynamische Liste verwendet werden. 20 Es gibt V Adjazenzlisten, die für jede einzelne Knoten u alle Knoten v enthält, für die es eine Kante (u, v) E gibt (d.h. alle Knoten, die in G mit u adjazent sind). 37

44 2.4.2 Mustererkennung Wir, als biologische Lebensformen, wenden die Mustererkennung fast in jeder Phase der Interaktion mit der Umgebung an: Sei es die Identifizierung von Personen durch Wiederkennen von Gesichtern, das Lesen von unterschiedlich geschriebenen oder maschinell erstellten Schriften, das Verstehen und Interpretieren von Wörtern in einer Konversation, per Geruch den Qualitätsgrad eines Lebensmittels zu bestimmen oder auch die Erkennung von Gegenständen nur durch ertasten. Diese Art von anspruchsvoller Klassifizierung führen wir fast ohne Mühe nach Millionen von Jahren der Entwicklung durch. Die Komplexität der Mustererkennung ist für uns erst dann ersichtlich, wenn wir versuchen, unsere Perzeption (dazu gehört das Bemerken, Auswerten und Interpretieren) maschinell zu verwirklichen. Mustererkennung ist die Wissenschaft von der maschinellen Umsetzung der Perzeption (die mathematisch-technischen Aspekte der Perzeption), dazu gehört die Erfassung der unmittelbaren Umwelt durch optische, akustische oder druckempfindliche Sensoren, die wichtigen Strukturen vom Hintergrund herauszufiltern und die Muster durch begründbare Entscheidung in eine Kategorie (Klassifikation) zuzuordnen. Es soll nun näher auf den allgemeinen Aufbau (siehe Abb. 2.30) und die Arbeitsweise eines Mustererkennungssystems eingegangen werden, basierend auf dem Buch [DHS01] und parallel dazu die theoretischen Grundlagen nach [Nie83], [Nie03]. Der erste Schritt besteht darin, die Umwelt mittels zur Verfügung stehender Sensoren zu erfassen (Abtastung), die dann als Input des Klassifizierungssystems dienen. Bei Sensoren sind deren Charakteristika und gegebene Einschränkungen zu berücksichtigen (hinsichtlich des Einflusses auf die Erkennungsrate), unter anderem die Bandbreite, das Signal-Rausch-Verhältnis, Latenz, Resolution, Sensitivität oder bei optischen Sensoren, dass diese nur einen kleinen Bereich des elektromagnetischen Spektrums abdecken. Dementsprechend müssen die Störungen aus den Eingangsdaten im Nachhinein beseitigt werden. Aus Effizienzgründen ist es auch notwendig, diese nur auf die relevanten, bearbeitbaren Informationen (Problemkreise) zu beschränken: Definition 2.7: Für Perzeptionszwecke reicht es, die Umwelt als die Gesamtheit der physikalisch messbaren Größen aufzufassen, die formal durch die Menge ρ U = { b x ρ = 1,2, } ρ der Funktionen b x dargestellt wird. Abb. 2.30: Allgemeiner Aufbau eines Mustererkennungssystems (basierend auf [DHS01]) Jedes Objekt lässt sich durch hinreichend viele, geeignet gewählte Funktionen spezifizieren (die ρ Gesamtheit der messbaren Größen der Umwelt) und Funktionswerte von b x geben dabei, z.b. für jeden Punkt im Raum oder jeden Zeitpunkt, eine charakteristische Größe eines Objektes an, z.b. Dichte, elektromagnetische Feldstärke, Temperatur. Da U alle Funktionen enthalten soll, 38

45 muss die Zahl der Komponenten von b und x offen bleiben. Sie kann für jeden Wert von ρ unterschiedlich sein. *Nie03+ Definition 2.8: Ein Problemkreis Ω enthält nur Objekte (Funktionen) eines bestimmten und begrenzten Anwendungsgebietes, die mit erforderlichen Sensoren gesammelt werden. Der Problemkreis ist definiert durch eine Menge ρ Ω = { f x ρ = 1,2, } U ρ von Funktionen f x und bildet eine echte Teilmenge von U. Beispiele für Problemkreise sind die Verifikation von Unterschriften und biometrischen Daten, Spracherkennung oder die Klassifizierung von Routen für mobile Roboter (Hinderniserkennung). Definition 2.9: Die Elemente bzw. die Funktionen der Problemkreismenge Ω heißen Muster. Ein Muster ist definiert durch eine Funktion f x = f1(x1,,xn ) f2(x1,,xn ).. fm (x1,,xn ). Für einen bestimmten Problemkreis ist die Zahl der Komponenten von f und x konstant: Ein Farbbild lässt sich durch die drei Funktionen f r x, y, f g x, y, f b x, y in den drei Spektralbereichen rot, grün und blau darstellen, wobei x, y den Pixel an dieser Koordinate bezeichnet. Für den weiteren Prozess der Erkennung eines Musters gilt es, durch Segmentierung und Merkmalsextraktion wesentliche Informationen von dem Objekt zu extrapolieren (Merkmale), die die Parameter der Klassifizierung darstellen. Die Segmentierung isoliert das abgetastete Objekt vom Hintergrund oder von anderen aneinandergrenzenden bzw. überlappenden Objekten, so dass eine sinnvolle Aufteilung des Inputs stattfindet. Zusätzlich wird das abgetastete Objekt skaliert, um mit den Normobjekt vergleichbar zu sein. Es stellt sich die Frage, wonach ein Objekt überhaupt zu segmentieren ist, bevor dies als ein bestimmtes Muster erkannt worden ist. Hier kommen verschiedene Methoden zum Einsatz, z.b. (wie im Abschnitt vorgestellt) das Clustering oder modellbasierte Verfahren (bei dem ein vorgegebenes Normmodell als Bezugspunkt dient). Das Ziel des Merkmalsextraktors ist es, das zu erkennende Objekt durch Messwerte zu charakterisieren und sich auf wesentliche Merkmale zu konzentrieren (Abstraktion). Jedes Muster besitzt eine endliche Anzahl von Merkmalen, die für seine Zugehörigkeit zu einer Klasse bzw. Kategorie kennzeichnend sind. Ähnliche Werte für Objekte implizieren, dass sie zur selben Kategorie gehören und unähnliche (größeres Distanzmaß) Werte zu verschiedenen Klassen. Wie bei der Segmentierung ist auch die Anwendung der Merkmalsgewinnung an dem Problemund Anwendungsbereich orientiert, welches domainspezifisches Wissen erfordert. Insbesondere ist allgemein die Invarianz der charakterisierenden Merkmale zu fordern, um eine gewisse Erkennungstoleranz gegenüber irrelevanter Transformationen (Translation, Rotation und Skalierung) des Input-Objekts zu gewährleisten (z.b. unterschiedlich deformierte Handschriften). Besonders anspruchsvoll ist es, Objekte im Dreidimensionalen zu erkennen, denn durch Rotation können manche Erkennungsmerkmale verdeckt werden, oder beispielweise kann eine kreisförmige Struktur aus einem bestimmten Winkel als oval oder sogar als eine Gerade erscheinen. In der Spracherkennung wird gefordert, dass die Merkmale zeitinvariant und unempfindlich gegenüber Ampli- 39

46 tuden-veränderungen ist (ein Wort kann unterschiedlich schnell und verschieden betont werden). Grundsätzlich sind die Merkmale oder Kombinationen von denen auszuwählen, die die Muster eindeutig (wünschenswert) in eine Kategorie zuordenbar machen, einfach zu extrahieren sind und widerstandsfähig gegenüber Störeinflüssen sind. Die wichtigste Komponente des Mustererkennungssystems stellt der Klassifikator dar. Er weist anhand des abstrahierten Merkmalsvektors (bzw. -werte) eines Objekts, der vom Merkmalsextraktor bereitgestellt wurde, das Objekt einer Kategorie zu. Die Entscheidung findet durch Vergleich der Merkmale statt, jedoch ist eine perfekte Zuordnung meistens (z.b. durch die bereits erwähnten Störungen) nicht möglich, so dass eher eine Wahrscheinlichkeit berechnet wird, welche jeweils einen stochastischen Wert für jede Kategorie bezüglich des zuzuordnenden Objekts angibt. Der Schwierigkeitsgrad im Prozess des Klassifizierens hängt mit der Variabilität der Merkmalswerte der Objekte innerhalb derselben Kategorie, im Verhältnis zu den Abständen von den Objekten aus unterschiedlichen Kategorien, zusammen. Bevor ein Mustererkennungssystem im Stande ist, unterschiedliche Muster zu identifizieren, ist es notwendig, den Klassifikator anhand von Beispiel-Mustern zu trainieren. Das Lernen hat das Ziel, dem Klassifikator die Bereiche der Klassen bzw. Kategorien bekannt zu machen und das System so zu modifizieren (durch den Lernprozess), dass das System die Erkennungsfehlrate innerhalb der Musterexemplare soweit wie möglich minimiert. Das maschinelle Lernen lässt sich in drei Bereiche unterteilen: Überwachtes Lernen ( Supervised Learning ), Unüberwachtes Lernen ( Unsupervised Learning ) und Bestärkendes Lernen ( Reinforcement Learning ). Beim überwachten Lernen gibt ein externer Lehrer dem System (auf Basis neuronaler Netze [PRD07]) zu jeder Eingabe die korrekte Ausgabe oder die Differenz zwischen dem tatsächlich Erkannten und der vorgegebenen korrekten Ausgabe an. Anhand dieser Differenz wird dann das System über die Lernregeln modifiziert. Im unüberwachten Lernen oder Clustering gibt es keinen Lehrer und deswegen versucht das System ohne Feedback von außen die Eingabemuster in Ähnlichkeitsklassen aufzuteilen. Zu beachten ist, dass verschiedene Clusteringalgorithmen zu verschiedenen Gruppierungen führen können. Beim bestärkenden Lernen wird dem System nur mitgeteilt, ob seine Ausgabe, also die Kategorisierung des Beispiel-Musters, einwandfrei oder inkorrekt war und das System erfährt nicht den exakten Wert des Unterschiedes. Prinzipiell lässt sich ein komplexes System aufbauen, das alle Beispiel-Muster des Trainings eindeutig klassifiziert, aber es ist unwahrscheinlich dass es auch bei neuen, bisher dem System unbekannten, Mustern gelingt. Dieses Phänomen wird als Overfitting bezeichnet. *Bis06+ Zur Verbesserung der Erkennungsrate können nun verschiedene unabhängige Klassifikatoren parallel eingesetzt werden, die auf unterschiedliche Erkennungsmerkmale ausgerichtet sind. Infolgedessen können diese für ein Muster im worst-case verschiedene Kategorien zur Einordnung vorschlagen. Hier entscheidet die Nachbearbeitungskomponente (z.b. anhand einer Gewichtung der Klassifikatoren) letztlich über die endgültige Zuordnung der Muster zu einer Klasse. Nun soll durch eine Definition zur Mustererkennung [Bur06] dieses Unterkapitel abgeschlossen werden: 40

47 Definition 2.10: Mustererkennung ist die Theorie der bestmöglichen Zuordnung eines unbekannten Musters m zu einer Äquivalenzklasse E (Klassifikation). Eine Äquivalenzklasse E besteht aus einer Menge von Mustern {x i } und einer binären Verknüpfung mit den folgenden Eigenschaften: x i ~x i (reflexiv), x i ~x j x j ~x i (symmetrisch), x i ~x j x j ~x k x i ~x k (transitiv) Trajektorienbestimmung Um die Bewegung eines bestimmten Objekts im Raum zu verfolgen, stellt man seine Position in einem Raum (Zustandsraum bzw. Phasenraum) dar. Als Referenzposition des Objekts dient dabei der Schwerpunkt des Objekts (Massenpunkt). Ein Objekt oder ein Teilchen wird Massenpunkt genannt, wenn man seinen Bewegungsverlauf vollständig durch drei, von der Zeit abhängigen Raumkoordinaten r t = (x t ; y t ; z(t)) t beschreiben kann. Dabei stellt r t eine Trajektorie bzw. Flugbahn im dreidimensionalen Raum dar (vgl. Abb. 2.31), die durch den Zeit- Parameter t charakterisiert wird [Hee04]. Abb. 2.31: Eine Trajektorie im dreidimensionalen Raum Wir protokollieren aus Effizienz-Gründen die Positionen des Objekts in diskreten Zeitschritten und stellen diese in einer Ebene dar. Im Zeitverlauf, entsprechend der Bewegung des Objekts, ergibt sich so eine endliche Menge (bis zur letzten Lokalisierung) von Ortskoordinaten (x, y) bzw. Knoten. Die Knoten werden anhand ihrer zeitlichen Abfolge durch Kanten verbunden (ein Knoten im Zeitpunkt t 1 mit dem Knoten im Zeitpunkt t), so dass der entstehende Pfad abstrakt die Dynamik des Objekts darstellt. Der gebildete Baum stellt noch nicht genau den Weg des kontinuierlich bewegenden Objekts dar, sondern es müssen die fehlenden Daten zwischen den zwei Messpunkten nachträglich interpoliert werden. Eine Lösung könnte hier die Anwendung von Bézierkurven darstellen, die für den Betrachter einen unnatürlich-wirkenden (u.a. zackigen) Verlauf des Pfads glättet. Besonders die Wendungen im Weg lassen sich durch Bézierkurven gut approximieren. Eine Bézierkurve stellt die Approximation einer Kurve durch eine Polynomkurve dar, die durch eine endliche Menge von Kontrollpunkten determiniert wird (vgl. Abb. 2.32). Sie wurde 1959 von de Casteljaus entwickelt (ebenso unabhängig von ihm durch Pierre Bézier Anfang 1960er *Hor06+)und ist heute ein wichtiges Tool im Computer Aided Design (CAD). Wir wollen im Folgenden [Sch07] eine lineare, quadratische und kubische Bézierkurve definieren, dabei seien k 0 = x 0, y 0,, k n = x n, y n Kontrollpunkte (bzw. Bézierpunkte) im R 2 und t [0,1] (wenn t aus diesem Intervall stammt, liegt die Bézierkurve in der konvexen Hülle des Kontrollpolygons [Far94]): 41

48 Definition 2.11: Eine lineare Bézierkurve mit zwei Kontrollpunkten k 0 und k 1 ist die geradlinige Strecke B t = 1 t k 0 + t k 1 = 1 t x 0+t x 1 1 t y 0 +t y 1. Definition 2.12: Eine quadratische Bézierkurve mit den Kontrollpunkten k 0, k 1 und k 2 ist die Kurve B t = 1 t 2 k t t k 1 + t 2 k 2 = 1 t 2 x t t x 1 +t 2 x 2 1 t 2 y t t y 1 +t 2 y 2. Das Polygon, welches durch die Kontrollpunkte beschrieben wird, heißt Bézierpolygon oder Kontrollpolygon. Definition 2.13: Eine kubische Bézierkurve wird durch vier Kontrollpunkte (k 0, k 1, k 2 und k 3 ) definiert und stellt folgende Kurve dar: B t = (1 t) 3 k 0 + 3(1 t) 2 t k 1 + 3(1 t)t 2 k 2 + t 3 k 3 = (1 t)3 x 0 +3(1 t) 2 t x 1 +3(1 t)t 2 x 2 +t 3 x 3 (1 t) 3 y 0 +3(1 t) 2 t y 1 +3(1 t)t 2 y 2 +t 3 y 3. Abb. 2.32: Hier zu finden sind die drei definierten Bézierkurven (durchliniert): (a) zeigt die lineare Bézierkurve mit den Kontrollpunkten k 0 = 1, 1 und k 1 = 0, 0 ; (b) stellt die quadratische Bézierkurve dar mit k 0 = 1, 1, k 1 = 0, 0 und k 2 = 1, 1. Die durch die vier Kontrollpunkte k 0 = 1, 1, k 1 = 0, 0, k 2 = 1, 1 und k 1 = 3, 1 definierte kubische Bézierkurve wird in (c) gezeigt. Die gestrichelten Linien stellen das Kontrollpolygon dar. [Sch07]. Ein weiterer interessanter Aspekt bei der Trajektorienverfolgung wäre es, die durchschnittliche Bewegung im Verlauf der Zeit zu ermitteln. Gleitende Durchschnittslinien, die der Finanzwirtschaft einzuordnen sind [Sch02], ergeben sich jeweils als das arithmetische Mittel des Börsenkurses eines Titels der letzten 30, 60 oder 200 Tage, welche die längerfristigen Tendenzen veranschaulichen. Je größer das Zeitintervall, desto größer ist die Verzögerung der Reaktion bei der Linie. Graphisch vorgestellt, bildet Zeit die x-achse und die y-achse den durchschnittlichen Börsenwert der Aktie. In unserem Fall ist jedoch der Wert eine zweikomponentige Ortskoordinate, also muss über die beiden Koordinaten das arithmeti- Abb. 2.33: Die gestrichelte Linie stellt die reale Bewegung dar und die durchlinierte deren Durchschnitt. 42

49 sche Mittel gebildet werden (vgl. Abb. 2.33). Die Chronologie ist hier zu vernachlässigen, weswegen der Mittelwert äquivalent über die Kardinalität der Koordinatendaten bestimmt werden kann. Vielmehr steht die durchschnittliche Bewegung des Objekts im Mittelpunkt: Es lässt sich auch die durchschnittliche horizontale oder vertikale Bewegung extrapolieren, indem über die relevante Achse der Durchschnitt gebildet wird, während die zweite Koordinatenachse den realen Wert (anhand der Flugdaten) durchgängig annimmt Kollisionserkennung Das Ziel eines Kollisionserkennungssystems im Abstrakten ist das Erkennen eines bevorstehenden oder gerade stattfindenden geometrischen Kontakts - Berühren oder Überlappen - zwischen zwei oder mehreren starren oder deformierbaren Objekten. Der Kollisionserkennung folgt die Kollisionsantwort/-behandlung, die die Reaktion des Systems darstellt (z.b. Richtungs- und Geschwindigkeitsänderung der Objekte bei Aufprall). Kollisionserkennung findet heute in vielen Gebieten ihre Anwendung, zum Beispiel in Bereichen wie physikalisch-basierte Simulation und Animation, Robotik (um Hindernissen auszuweichen) oder Haptik ( Fühlende Umgebung ). Starre Körper/Objekte ( rigid bodies ) verändern ihre Form während der Bewegung nicht und alle Punkte im Objekt bleiben untereinander gleich. Ein deformierbares Objekt lässt sich als Partikelsystem diskretisieren, bei dem Partikel durch verallgemeinerte Federn miteinander verbunden sind [Web05]. Bei deformierbaren Objekten ergeben sich auch Selbstkollisionen, (z.b. bei animierten Textilien oder Haaren [Fuh06]) und bei Kollisionen können sich unterschiedliche Kontaktzeiten in einem Simulationsschritt ergeben, die unter anderem den Erkennungsprozess erheblich schwieriger gestalten. In unserem Fall 21 sind Objekte die durch das künstliche Szenario gelieferte Gruppierungen von Zellen, die anhand der Zusammenhangskomponenten zu einzelnen disjunkten Clustern geformt werden. Wie im Abschnitt Game of Life beschrieben, produziert der zelluläre Automat sowohl bewegende als auch stationäre Objekte, die sich im Verlaufe der Zeit annähern und eventuell auch miteinander kollidieren. Zwar nehmen die bewegenden Objekte während der Annäherung verschiedene Formen an (strenggenommen handelt es sich dabei um deformierbare Körper), aber während der Kollision findet jedoch keine Durchdringung wie im Falle von deformierbaren Objekten statt. Es erfolgt höchstens eine Verschmelzung der beteiligten Cluster, jedoch variieren die Zellen - äquivalent zu den Partikeln - durch Aufprall ihre Positionen nicht. Im Game of Life ist die Bewegung von den mobilen Objekten im Vergleich zur Bewegung von den starren Körpern (Translation und Rotation; vgl. Abb. 2.34) von abstrakter Natur, denn die Massen dieser Objekte werden im Zeitverlauf nacheinander von anderen Zellen repräsentiert. Aber auf längere Hinsicht (nach jeder Vollendung des Zyklus - denn dann nimmt das mobil-oszillierende Muster seine ursprüngliche Form wieder an und genügt den Kriterien eines starren Körpers) kann diese Art von Bewegungsprozess durchaus als Translation interpretiert werden. Obwohl eine klare Zuordnung der GoL-Objekte zu einer der Körperarten schwierig ist (abgesehen von den stabilen Mustern die eindeutig als starre Körper klassifiziert werden können), ist es dennoch sinnvoll diese als starre Ob- 21 Es folgt eine Darstellung der eigenen Sichtweise. 43

50 jekte zu bezeichnen. Denn eine Kollisionsantwort im Sinne einer Geschwindigkeitsänderung und Deformierung der betreffenden Objekte ist im GoL irrelevant 22, sondern nur das bevorstehende oder gerade eingetretene Kollisionsereignis (als Produkt von Emergenz) muss registriert werden. Aus diesem Grund gehen wir nur auf die Kollisionserkennung für starre Objekte näher ein. Abb. 2.34: Die Bewegung eines starren Körpers besteht aus Rotation und/oder Translation. [Web05] Theoretisch lässt sich zur Kollisionserkennung ein zweidimensionales aus n Zellen bestehender Cluster aus GoL durch ein Polygonnetz aus n Quadraten darstellen. Der naive Ansatz zur Kollisionserkennung zwischen zwei Objekten, bestehend aus n bzw. m (n, m N + ) Quadraten, wäre es, jedes Teil (jeweils von verschiedenen Objekten) miteinander auf Schnitt zu testen und damit hat es eine Komplexität von Ο(nm) [Web05]. Dies würde bei einer Simulationsumgebung mit vielen potentiellen Kollisionsobjekten viel Zeit in Anspruch nehmen und wäre im Bereich von Echtzeit- Anwendungen inakzeptabel. Eine Lösung wäre es, die Objekte durch einfachere geometrische Figuren Bounding Boxes einzuhüllen, um die Anzahl der kostenintensiven Schnitttests zu minimieren. Eine Kollision findet dann statt, wenn die Hülle zweier Objekte sich schneidet. Eine Bounding Box kann in unserem Fall ein eng anliegendes Polygon darstellen, bei dem die Linien von den äußeren Kanten der Randzellen des Musters bestimmt werden. Noch einfacher wäre es, ein Rechteck oder ein Kreis, der alle Zellen umfasst, zu verwenden. Bei der Wahl des Hüllkörpers muss zwischen der Genauigkeit des Kollisionstests und der Rechenzeit abgewogen werden. Je komplexer das anzulegende Polygon als Bounding Box ist, desto kleiner ist die Fehlerrate bei Prognose der Kollisionswahrscheinlichkeit, aber umso größer ist der Rechenaufwand. Die Fläche einer Bounding Box (Kreis oder Rechteck) im worst case für ein schmales diagonal gestrecktes Muster ist um ein Vielfaches größer als das Muster selbst und muss selbst bei Überlappung der beiden Hüllen keine Kollision implizieren. Dieses Problem lässt sich umgehen, wenn wir eine Bounding Box Hierarchie *KHMSZ98+ definieren (siehe Abb. 2.35), die im Falle eines Schnitts der größeren Hülle, eine weitere Untersuchung der Hülle auf der nächstniedrigeren Stufe einleitet. Grundsätzlich lässt sich diese Idee auf Mehrstufige Tests zurückführen [Web05]: 1) Broad Phase : Teste, ob die Objekte im Raum überhaupt aufeinander treffen können. Hierbei werden die Objekte aussortiert, die auf keinen Fall kollidieren werden. 2) Narrow Phase : Teste, ob die potentiellen Schnittkandidaten tatsächlich überlappen können. 22 Die vermehrten Zellaktivitäten (Geburt/Tod von Zellen) in der Nähe eines Kollisionsgebiets stufen wir hier unter dem Evolutionsprozess der Zellen ein und nicht als direktes Ergebnis einer Kollision. 44

51 Die beiden Schritte können durch die Bounding Box Hierarchie wie oben bereits beschrieben, realisiert werden. Abb. 2.35: Bounding Box Hierarchien per Top-Down Konstruktion (basierend auf [Web05]) Abb. 2.36: Bounding Box - Typen Abb. 2.37: Bounding Box Sphäre [Web05] Hüllkörper können wie oben bereits angedeutet durch verschiedene geometrische Figuren verwirklicht werden, aufgeführt seien hier die einfacheren Varianten (siehe Abb. 2.36): Bounding Spheres, Axis Aligned Bounding Boxes (AABB), und Oriented Bounding Boxes (OBB). Bounding Spheres, kurz Sphäre, werden für schnelle Kollisionsberechnungen eingesetzt. Dabei werden die Objekte (in zweidimensionalen Raum) durch Kreise umschlossen, deren Radien r1 und r2 sind (vgl. Abb. 2.37). Die Kreise überschneiden sich, wenn der Abstand d = M2 M1 kleiner als die Summe der Radien ist: d r1 + r2. Zwar sind Bounding-Sphären sehr effizient zu verarbeiten und invariant gegenüber Rotationen des einzuhüllenden Objekts, aber eine gute Anpassung an dem Objekt findet nicht statt: Wie in der Abbildung zu sehen ist, sind die beiden Muster (M1, M2) trotz der Überschneidung ihrer Hüllen nicht kollidiert. 45

52 Eine leicht bessere Approximation an gegebene Objektstrukturen und demzufolge auch ein genauerer Kollisionstest (ebenso bei guten Laufzeiteffizienz) gestattet die Hülle AABB, bei der die Kanten parallel zu den Achsen des Koordinatensystems verlaufen. Um die kleinstmögliche, passende Rechteck-Hülle zu bestimmen, ermittelt man die minimale und maximale Ausdehnung des Objekts jeweils auf den beiden Koordinatenachsen 23 (vgl. Abb.2.38 (a): Hülle für Objekt R). Abb. 2.38: (a) zeigt den Überlappungsfall zweier Aligned Bounding Boxes (AABB), (b) zwei disjunkte AABBs trotz Schnitt auf der x-achse, (c) Keine Kollision trotz Schnitt der beiden Hülle. Eine mögliche Kollision zwischen den Objekten R und B liegt vor, wenn die folgende Bedingung erfüllt ist (siehe Abb. 2.38(a)) bzw. die beiden Projektionen auf den Koordinatenachsen sich überschneiden: Bx min Rx min Bx max Bx min Rx max Bx max By min Ry min By max By min Ry max By max. Durch Sortieren der Projektionen kann das Feststellen der Überlappungen von vielen AABBs beschleunigt werden, indem die Anzahl der Schnitttests reduziert werden ( Sweep and Prune Algorithmus [LG98]). Zwei AABBs sind disjunkt, wenn es mindestens eine Koordinatenachse gibt, auf der die Projektionen der AABBs sich nicht überlappen. Auch AABB zeigt Schwächen (Abb (c)) bei ungünstigen Objektformen und Neigungswinkeln, da hierbei das AABB deutlich größer als das umhüllte Objekt ist. Ebenso wird bei diesem Verfahren eine Neuberechnung der Hülle bei Rotationen des Objekts erforderlich. Eine gute Annäherung 24 der Objektgröße wird durch die an das Objekt ausgerichtete OBB-Hülle erreicht (gesteigerte Hülleffizienz), bei der bei Rotationen diese nicht erneut aufwendig berechnet werden muss. Der Überlappungstest ist aber nicht so einfach wie beim AABB und Sphären. Es existiert ein schneller Kollisionstest (für OBB), der Separating Axis Test, der besagt (vgl. Abb. 2.39): Wenn sich zwei Objekte nicht berühren, dann existiert eine Achse, auf der die Projektionen der beiden Objekte disjunkt sind. (von *Web05+; für nähere Details sei auf *GLM96+ verwiesen.) Für die Datenbank-Implementierung wählen wir den Mittelweg Axis Aligned Bounding Boxes, welche einen Kompromiss zwischen Laufzeiteffizienz und Berechnungsgenauigkeit darstellt. 23 Hier wird das Java-Koordinatensystem als Grundlage genommen, bei dem der Nullpunkt im Fenster linksoben ist, ebenso die x-achse horizontal nach rechts und die y-achse nach unten verläuft. 24 Es gibt noch bessere Verfahren wie k-dop ( Discrete Oriented Polytopes = diskret orientierte Polyeder mit k Beschränkungsflächen). 46

53 Abb. 2.39: Kollisionserkennnung mit OBB Körpern: Bei (a) und (b) finden keine Überlappungen statt. In (b) stellt die Achse A2 die Projektionsachse dar, welche im Separating Axis Test beim Nicht-Überlappungsfall gefordert wird. Bei (c) lässt sich eine solche Achse nicht finden, so dass eine Kollision vorliegt. 47

54 3 Grundlagen der verwendeten Technologien Das Ziel dieser Arbeit ist die Realisierung eines Monitoringsystems durch Implementierung der Programmlogik auf der Basis eines relationalen Datenbanksystems. Ebenso ist die Protokollierung der Ereignisse eines diskreten Prozesses und deren Auswertung in der Datenbank vorgesehen. Im Abschnitt 3.1 werden daher zunächst die Grundlagen des Datenbankentwurfs eingeführt, die sich vornehmlich an [Man06] und [KE06] orientieren. Wir gehen hier besonders auf die konzeptuelle und logische Entwurfsphase näher ein. Im Abschnitt 3.2 werden die wichtigen Grundzüge der relationalen Anfragesprache SQL ( Structured Query Language ) vorgestellt, die zur Datendefinition und Datenmanipulation in relationalen Datenbanken benutzt werden. In dieser Diplomarbeit wird SQL bei der Umsetzung der primären Verarbeitungslogik des Simulators und der Monitoringaufgaben angewendet. Als Datenbankmanagementsystem für die zu entwerfende relationale Datenbank wird Microsoft Access 2007 eingesetzt. Diesbezüglich wird die von Access verwendete SQL-Variante JET SQL näher betrachtet und Unterschiede zum standardisierten SQL herausgestellt. Zur Frontend-Programmierung wird auf die objektorientierte Programmiersprache JAVA zurückgegriffen. Die Implementierung der grafischen Benutzeroberfläche erfolgt in Form eines Applets per SWING-Klassenbibliotheken, auf die wir im Unterkapitel 3.3 eingehen werden. Ebenso wird in diesem Abschnitt die Datenbankanbindung für Java-Applikationen durch JDBC ( Java Database Connectivity ) behandelt. 3.1 Relationaler Datenbankentwurf Die Systematik des Datenbankentwurfs lässt sich als eine top-down -Konstruktion auffassen (Abb. 3.1), die das Ziel der Schaffung eines guten DB-Schemas im Sinne der Speicher- und Laufzeiteffizienz hat. Dabei orientiert sie sich an der 3-Schema-Architektur (Abb. 3.2), um die logische und physische Datenunabhängigkeit durch Isolierung der Details tieferer Ebenen zu gewährleisten. Durch diese Abstrahierung wird die Implementierung des Entwurfs auf unterschiedlichen Datenbanksystemen ermöglicht und verringert im DB-Einsatz den Wartungsaufwand. Die erste Phase des Entwurfs stellt die Anforderungsanalyse dar, bei der in enger Zusammenarbeit mit dem Auftraggeber und Endbenutzern der Datenbankanwendung die Anforderungen und Datenverarbeitungsvorgänge der realen Welt zu einem Pflichtenheft abstrakt zusammengefasst werden, welches die Anforderungsspezifikation des Anwendungsbereichs enthält. Ausgehend von einem solchen Ergebnis erfolgt der konzeptuelle Entwurf: Die vorliegenden Informationen - Strukturanforderungen und Gesetzmäßigkeiten des Anwendungsgebiets - werden in eine formale Darstellung umgesetzt, unabhängig von dem einzusetzenden Datenbanksystem (DBS). Die formale Darstellung erfolgt meistens durch das Entity-Relationship-Modell in einer für den Entwickler und Anwender verständlichen Form. Auf dieses Datenmodell gehen wir näher im Unterkapitel ein. Im nächsten Schritt, dem logischen Entwurf, wird das ER-Schema in Relationen (logische Datenbankstruktur) umgesetzt, wobei hier das Datenmodell des eingesetzten Datenbankmanagementsystems (DBMS) von Relevanz ist. Mit dem logischen Entwurf (auch als Implementation- 48

55 sentwurf bezeichnet) werden wir uns im Abschnitt beschäftigen. Die letzte Phase des Datenbankentwurfs ist der physische Entwurf, bei dem die Abarbeitungseffizienz (inklusive der Zugriffseffizienz durch Benutzung optimaler Datenstrukturen, wie z.b. die Gruppierung von Blöcken bzw. Seiten) im Vordergrund steht. Dafür ist eingehendes Wissen über das eingesetzte Betriebssystem und Sekundärspeicher notwendig. Für weitergehende Aspekte sei auf [Vos08] hingewiesen. Abb. 3.1: Phasen des Datenbankentwurfs Abb. 3.2: 3-Schema-Architektur [Man06] Konzeptueller Entwurf Wie vorhin bereits bei der Einführung angedeutet, bezieht sich die konzeptuelle Modellierung mehr auf das reale Anwendungsgebiet als auf die implementierungsspezifische Ebene. Wir verwenden das Entity- Relationship-Datenmodell (kurz: ER-Modell), welches von Peter Chen im Jahre 1976 vorgestellt [Che76] wurde. Es stellt eine graphische Notation zur Anwendungsmodellierung dar, die unabhängig von der nachfolgenden Systemimplementierung ist. Abb. 3.3: Beispiel für einen Entity-Typ 49

56 Die Grundkomponenten des Modells stellen die Entities (Gegenstände) und Relationships (Beziehungen) dar. Gegenstände (bzw. Entities) sind wohlunterscheidbare, physisch oder gedanklich existierende Konzepte der zu modellierenden Welt. [KE06]. Die Attributstruktur eines Entities, also die Beschreibung eines Objekts, wird von dessen Entity-Typ (durch ein Rechteck dargestellt) vorgegeben, wobei jedes gleichartige 25, eindeutig charakterisierte Entity eine Instanz von diesem Entity-Typen bildet. Die vollständige Charakterisierung jedes Entities erfolgt durch die Gesamtheit ihrer Attributwerte, wobei die eindeutige Identifizierung mittels ein oder mehrerer Schlüsselattribute (kurz Schlüssel; im ER-Modell unterstrichen) vollzogen wird (siehe Abb. 3.3). Es können unter Umständen mehrere Schlüsselkandidaten vorliegen, von denen einer ausgewählt wird, welchen wir als Primärschlüssel bezeichnen. Der Schlüssel sollte minimal gewählt werden, so dass durch Weglassen eines Attributs aus der Menge der schlüsselbildenden Attribute kein eindeutiges Identifizieren der Entities mehr möglich wäre. Abb. 3.4: Relationship-Typen - Beispiel Die zweite wichtige Komponente stellt die Relationships (vgl. Abb. 3.4) dar. Eine Relationship verbindet Entities miteinander. Ein Entity kann an mehreren Relationships beteiligt sein, d.h. mit verschiedenen Entities auf unterschiedliche Weise verbunden sein. Jede Relationship kann durch die Schlüsselwerte der beteiligten Entities und die eigenen (optionalen) Attribute eindeutig identifiziert werden, besitzt aber keine eigenen Schlüsselattribute. Auch Relationships können zu Relationship-Typen zusammengefasst werden, wenn sie eine identische Attributstruktur und identische Entity-Typen besitzen. Den an einem Relationship-Typ beteiligten Entity-Typen können explizite Rollen zugewiesen werden. Insbesondere ist aber erforderlich (zur syntaktischen Unterscheidung), wenn ein und derselbe Entity-Typ mehrfach an demselben Relationship-Typ teilnimmt. 25 Alle Entities von demselben Entity-Typ haben eine identische Attributstruktur. 50

57 Durch die Angabe von Funktionalitäten lassen sich die Relationship-Typen weiter charakterisieren, indem man die zulässigen Teilnahmekombinationen von Entitäten an einem Beziehungstyp angibt. In binären Beziehungstypen lassen sich vier Arten von Funktionalitäten unterscheiden (vgl. Abb. 3.4): 1:1 Beziehung, falls jede Instanz e 1 ausdes Entity-Typs E 1 maximal 26 mit einer Instanz e 2 des Entity-Typs E 2 in Beziehung steht oder umgekehrt. 1:N Beziehung liegt dann vor, wenn jede Instanz e 1 ausdes Entity-Typs E 1 mit beliebig (N 0) vielen Instanzen des Entity-Typs E 2 verbunden ist. N:1 Beziehung liegt vor, falls jede Instanz e 2 aus des Entity-Typs E 2 mit beliebig (N 0) vielen Instanzen des Entity-Typs E 2 in Beziehung steht. N:M Beziehung, (N, M 0) wenn keine Restriktionen hinsichtlich der Anzahl der beteiligten Entities vorliegen. Abb. 3.5: Generalisierung und Aggregation (nach [KE06], [Man06]) Nun werden noch zwei Erweiterungen des ER-Modells vorgestellt, es handelt sich dabei um die Generalisierung und Aggregation. Die Generalisierung stellt eine Verallgemeinerung bzw. Abstraktion auf der Typebene dar und wird durch ein is_a -Sechseck dargestellt (vgl. Abb. 3.5). Hierbei werden die gemeinsamen Charakteristika (Attribute und Beziehungen) ähnlicher Entity-Typen ermittelt und einem gemeinsamen Obertyp zugewiesen. Diejenigen Eigenschaften ähnlicher Entity-Typen, die keine Gemeinsamkeit besitzen, verbleiben bei diesen Entity-Typen und bilden mit diesen zusammen die Untertypen. Hierbei entsteht eine Typhierarchie, wobei die Untertypen die Attribute und Beziehungen des Obertyps erben. Bei der Aggregation werden unterschiedliche Entity-Typen einander zugeordnet, wenn diese in ihrer Gesamtheit einen strukturierten Obertypen bilden. Eine Instanz des Obertyps setzt sich aus Instanzen der Untertypen zusammen und wird im Modell als is_part_of -Raute abgebildet (Abb. 3.5). 26 Maximal ist hier als keiner oder genau einer zu interpretieren. 51

58 3.1.2 Logischer Entwurf Durch den konzeptuellen Entwurf erhalten wir das ER-Schema der Sachverhalte des Anwendungsgebiets, welches wir nun in eine entsprechende logische Datenstruktur, das relationale Schema, überführen. Es müssen dabei die beiden Strukturierungskonzepte des ER-Modells Entity-Typen und Relationship-Typen auf das Strukturierungskonzept des relationalen Modells, Relationen bzw. Tabellen, abgebildet werden [KE06]. Eine Relation lässt sich über das kartesische Produkt formal definieren [Man06][WHK04]: Definition 3.1 (Kartesisches Produkt): Sei n N +, n 2 und seien D 1,, D n nicht leere Mengen (Domänen), dann heißt die Menge der geordneten n Tupel das kartesische Produkt der Mengen D 1,, D n. 52 D 1 D n = { d 1,, d n : d 1 D 1,, d n D n } Abstrakt gesehen ist eine Tabelle bzw. Relation einer Datenbank als die Teilmenge eines kartesischen Produkts endlicher Mengen zu interpretieren: Definition 3.2: Seien D 1, D 2,, D n beliebige nicht leere, nicht notwendig verschiedene Mengen. Eine n-stellige Relation R über D 1,, D n ist eine Teilmenge von D 1 D n. Demnach besteht eine Relation aus einer endlichen Teilmenge von Tupeln des kartesischen Produkts. Zwar haben wir hier Relationen und Tabellen als Synonyme füreinander verwendet, jedoch sind prinzipielle Unterschiede vorhanden: Die Relation enthält als eine Menge keine duplikaten Tupeln, dagegen sind bei einer Datenbank-Tabelle durchaus redundante Zeilen erlaubt, welche den Tupeln entsprechen. Weiterhin lassen sich Zeilen in einer Tabelle nach Attributen (bzw. Spalten) ordnen, wohingegen eine Menge ungeordnet ist. Wenn man von einer Anordnung absieht und eine Duplikateliminierung einführt, lässt sich eine Tabelle als eine Relation auffassen. Bei der Abbildung vom ER-Modell ins relationale Modell wird jeder Entity-Typ in eine eigene Tabelle transformiert, bei der der Typ als der Tabellenname dient und die Attribute des Entity-Typs die Spalten(-namen) der Tabelle darstellen. Zu beachten ist, dass die Attribute innerhalb einer Tabelle eindeutig sein müssen, aber unterschiedliche Tabellen in derselben Datenbank durchaus die gleichen Attributsnamen vorweisen dürfen. Ein Entity-Typ mit n Attributen entspricht einer Tabelle mit n Spalten, deren Wertebereiche mit den Domänen einer Relation gleichzusetzen sind. Auf ähnliche Weise lassen sich die Relationship-Typen durch Tabellen im relationalen Schema repräsentieren, wobei hier zusätzlich zu den eigenen Attributen stets die Schlüsselattribute der beteiligten Entities enthalten sind. Diese Schlüsselattribute werden als Fremdschlüssel bezeichnet und dienen dazu, die beteiligten Entities innerhalb des Relationships eindeutig zu identifizieren und zuzuordnen. Handelt es sich allerdings um einen 1: 1, 1: N oder N: 1 Relationship-Typ, so kann man auf eine eigene Tabellen-Realisierung verzichten, indem man die Attribute des Relationship-Typs mit in die Entity-Typ-Tabelle einbettet: Bei 1: 1 ist unerheblich, in welche Tabelle der beiden beteiligten Entity-Typen integriert wird; bei einem 1: N oder N: 1 Relationship-Typ ist es ratsam, die eigenen Attribute in die Entity-Typ-Tabelle des mit N markierten Entity-Typs einzubetten. Wie in Abbildung 3.6 zu sehen ist, wurde die Beziehung in Tabelle Vorlesung eingebettet. Hierbei stellt das Attribut gelesenvon (entsprechen den Personalnummer-Werten von Professo-

59 ren) einen Fremdschlüssel auf die Relation Professor dar. Die Personalnummer und Vorlesungsnummer sind Primärschlüssel der jeweiligen Tabellen. Abb. 3.6: Transformation des 1: N- Relationship-Typs in Tabellenform Würde man statt wie die in Abb. 3.6 realisierte Umsetzung des Relationship-Typs versuchen, in die Tabelle Professor die gelesenen Vorlesungen zu integrieren Vorlesungsnummer als Fremdschlüssel in Tabelle Professor einbetten so könnten wegen des schlechten Schemas die Informationen mehrfach in der Tabelle vorkommen: Wenn ein Professor mehrere Vorlesungen abhält, so werden die Daten über den Professor redundant gespeichert (vgl. Abb. 3.7). Wenn nun der Professor mit der Personalnummer 002 seinen Dienstraum wechseln würde, müsste die Änderung zweimal durchgeführt werden, um die Daten konsistent zu halten. Wenn Einträge übersehen werden, die denselben Sachverhalt schildern, kann dies zur sogenannten Modifikationsanomalie (Inkonsistenzen der Daten) führen. Dies bewirkt Leistungseinbußen bei Änderungen (da mehrere Einträge bei einer Änderung aktualisiert werden müssen) und ebenso erhöhten Speicherbedarf durch entstehende Redundanzen. Abb. 3.7: Beispiel für einen schlechten Entwurf Eine weitere Problematik tritt beim Einfügen neuer Datensätze in die Tabelle Professor auf, was als Einfügeanomalie bezeichnet wird: Der Professor 003 wurde neuberufen und hält noch keine Vorlesung. Aber dennoch ist bei der Eintragung in die Professor-Tabelle der Zwang gegeben, in die Spalte VorlNr (äquivalent zu Vorlesungsnummer, aber umbenannt) einen Nullwert einzufügen. Eine Löschanomalie tritt auf, wenn man versucht, die Informationen eines der zwei miteinander vermischten Entity-Typen zu löschen, bei dem der andere Sachverhalt unbeabsichtigt auch verloren geht. 53

60 Der Grund für das Auftreten der dargestellten Anomalien und Redundanzen ist darauf zurückzuführen, dass zwei oder mehrere unabhängige Sachverhalte in einer Tabelle kombiniert werden. Diese Problematik lässt sich aber, im Prozess der Normalisierung, durch Zerlegung der verschiedenen Sachverhalte auf verschiedene Relationen lösen. Dabei wird ein Relationsschema R in die Komponentenschemata R 1,, R n, (n N + ) durch Projektionen aufgespaltet, wobei die Attribute von R vollständig auf die Komponenten teilmengenweise verteilt sind. Die Zerlegung sollte jedoch unter Berücksichtigung folgender zwei Kriterien erfolgen: Eine Zerlegung sollte verlustlos sein, d.h. alle in der unzerlegten Relation enthaltenen Informationen müssen in jedem Datenbankzustand aus den Komponentenrelationen rekonstruierbar sein. Bei der Rekonstruktion (mittels Join) dürfen auch keine zusätzliche Daten entstehen, die in R nicht enthalten waren. Eine Zerlegung sollte abhängigkeitserhaltend sein, so dass alle in R geltenden (funktionalen) Abhängigkeiten durch die in den Komponenten R 1,, R n verbliebenen Abhängigkeiten herleitbar sein müssen. Den Ansatzpunkt für eine sinnvolle Zerlegung und Redundanzvermeidung stellen die funktionalen Abhängigkeiten (siehe Definition 3.3) dar. Aufbauend auf den Abhängigkeiten werden relationale Normalformen definiert, die dazu dienen, Relationsschemata zu bewerten. Wenn ein Relationsschema diese Normalformen nicht erfüllt, lässt es sich durch entsprechende Normalisierungsalgorithmen in Komponenten aufteilen, so dass diese letztlich die erwünschte Normalform erfüllen. Bevor wir auf verschiedene Normalformen zu sprechen kommen, sei eine Definition zur funktionalen Abhängigkeit gegeben, da die Normalisierungstheorie vollständig auf dieser basiert [Man06]: Definition 3.3 (Funktionale Abhängigkeit (FD)): Seien A und B Attribute des Relationsschemas R. B hängt funktional von A ab, dargestellt als A B, wenn in jedem Zustand von R jeder A-Wert stets mit demselben, eindeutig bestimmten B-Wert kombiniert vorkommt. A und B können durchaus Attributmengen sein: Die funktionale Abhängigkeit A 1,, A m B 1,, B n, (m, n N + ) ist in einem Zustand von R erfüllt, wenn gilt (t 1, t 2 seien zwei beliebige Tupel in R): t 1, t 2 R: (t 1. A 1 = t 2. A 1 t 1. A m = t 2. A m ) (t 1. B 1 = t 2. B 1 t 1. B n = t 2. B n ). Es besagt, dass wenn zwei beliebige Tupel in A 1,, A m übereinstimmen, so müssen auch ihre Werte auf B 1,, B n identisch sein. Wenn die linke Seite einer funktionalen Abhängigkeit nicht mehr reduzierbar ist, ohne dessen FD-Eigenschaft zu verlieren, so spricht man von einer vollen funktionalen Abhängigkeit. Jeder minimale Schlüssel(-kandidat) in einer Relation besitzt diese Eigenschaft, denn die ganze Attributmenge der Relation ist durch ihn eindeutig identifizierbar. Eine funktionale Abhängigkeit A B wird als direkt bezeichnet, wenn es keine Attributmenge C gibt, so dass A C und C B ebenfalls funktionale Abhängigkeiten sind und zusätzlich A nicht von C funktional abhängt [Man06]. Nachdem wir nun funktionale Abhängigkeiten und deren Varianten kennengelernt haben, können wir aufbauend auf diese (einige wichtige) Normalformen (NF) definieren [Man06][KE06]: 54

61 Definition 3.4 (1 NF): Ein Relationsschema R liegt in 1. Normalform vor, wenn alle Attribute atomare Wertebereiche (Domänen) haben. Zusammengesetzte, mengenwertige oder relationenwertige Domänen sind nicht zulässig. Definition 3.5 (2 NF): Ein Relationsschema R ist in 2. Normalform, wenn jedes Nicht- Schlüsselattribut von R voll funktional abhängig ist von jedem Schlüsselkandidaten von R. Definition 3.6 (3 NF): Ein Relationsschema R erfüllt die 3. Normalform, wenn jedes Nicht- Schlüsselattribut von R direkt funktional abhängig ist von jedem Schlüsselkandidaten von R. Die Reihenfolge der Normalformen stellt eine Verschärfung dar, wobei eine abhängigkeitsbewahrende und verlustlose Zerlegung für alle vorgestellten Normalformen garantiert ist (vgl. Abb. 3.8). Es gibt weitere Normalformen, auf die wir hier nicht eingehen werden (für weitere Recherchen sei auf [KE06] verwiesen), aber grundsätzlich lässt sich sagen, dass alle das Ziel verfolgen, Sachverhalte bestmöglich zu identifizieren und durch eigene Relationen zu realisieren. 3.2 SQL Abb. 3.8: Beziehungen der Normalformen untereinander. SQL ( Structured Query Language ) ist eine der weit verbreitetesten relationalen Datenbanksprachen. Sie wurde ursprünglich für den relationalen DBMS-Prototypen System R von IBM Anfang der 1970er Jahre entwickelt und wurde damals als SEQUEL (Structured English Query Language) bezeichnet *Man06+. Das American National Standards Institute (ANSI) normierte die Sprache aufgrund ihrer wachsenden Bedeutung im Jahre 1986 unter der Bezeichnung SQL-86 (SQL 1) wurde diese Version revidiert zu SQL-89 und weitere Ergänzungen und Modifikationen führten 1992 zu den neuen, erheblich erweiterten Standard SQL-92 (SQL 2) [KE06]. Der meist eingesetzte Standard (Stand: 2008) ist SQL:1999 (SQL 3), welches objekt-relationale Datenbank-Konzepte eingeführt hat [Vos08] und im SQL:2003 Standard wurde insbesondere die XML-Integration vorgenommen [KE06]. Der neueste Standard stellt SQL:2006 dar, der eine weitergehende XML- Einbindung vorsieht [Wik08a]. Die relativ späte Standardisierung von SQL führte dazu, dass nahezu alle relationalen Systeme darunter DB2 von IBM, Oracle von Oracle Corporation, Access und SQL Server von Microsoft eigene Dialekte von SQL einsetzen. Besonders die Unterschiede zwischen dem von Access 2007 eingesetzten JET 27 - SQL und den Standard werden wir im Unterabschnitt näher betrachten. Im kommenden Abschnitt wird ein kompakter Überblick über die wichtigsten Aspekte des Standards SQL-92 gegeben. 27 Joint Engine Technology [Wik08b] 55

62 3.2.1 Standard SQL SQL besteht aus zwei Teilsprachen, einer Datendefinitionssprache ( Data Definition Language = DDL) und einer Datenmanipulationssprache ( Data Manipulation Language = DML). Mit den von DDL angebotenen Befehlen lassen sich Datenbankschemata definieren und manipulieren. Mit Mitteln von DML kann man Anfragen formulieren und es bietet Änderungsmöglichkeiten von Datenbankzuständen an. Bevor wir die erste Komponente DDL näher betrachten, gehen wir auf die wichtigsten von ANSI festgelegten Datentypen ein [KE06], die bei der Schemadefinition Verwendung finden. Bei relationalen Datenbanken werden drei fundamentale Datentypen als Wertebereiche für Attribute verwendet: Zahlen, Zeichenketten und Datum/Uhrzeit. Zahlen werden durch den allgemeineren Typ NUMERIC (p,s) dargestellt, wobei p die Gesamtspeicherstellen angeben und s die Anzahl der Nachkommastellen. Die Variante INTEGER speichert Ganzzahlen ohne Nachkommastellen. Gleitkommazahlen können mit einfacher Genauigkeit mittels REAL oder mit doppelter Genauigkeit durch FLOAT dargestellt werden [Min07]. Zeichenketten können den Typ CHARACTER (n) oder CHAR VARYING (n) vorweisen (auch bekannt als CHAR bzw. VARCHAR). Im Gegensatz zu VARCHAR werden Zeichenketten beim CHAR stets fest (eventuell auch mit Leerzeichen gefüllt) mit der vorgegebenen Länge n gespeichert. Datum kann durch den Datentyp DATE repräsentiert werden, wobei die verschiedenen DBMS unterschiedliche Varianten anbieten. Mit Hilfe von DDL-Befehlen lässt sich das Schema einer Datenbank definieren und nachträglich ändern [KE06]. Mittels CREATE lassen sich sogenannte Schemaelemente erzeugen. Zu Schemaelementen gehören im Wesentlichen die Table-, View-, Constraint-, Domain- und privilege- Definitionen [Man06]. Nachfolgend ist das Format der (impliziten) Schemadefinition und eine allgemeine Tabellendefinition gegeben, für Beispiele sei auf [Man06] und [Bod07] verwiesen: CREATE SCHEMA ([schema-name] [AUTHORIZATION user-name] [DEFAULT CHARACTER SET character-set] [list-of-schema-elements]) CREATE TABLE table-name (column 1 [column-constraints 1 ] column n [column-constraints n ] [table-constraints]) Eine neue Tabelle wird per CREATE TABLE mit dem zu vergebenden Tabellenname angelegt. In der Klammer folgen die Attribute (bzw. Spalten) mit ihren zugehörigen Wertebereichen (Typ). Ebenso lassen sich Spalten- und Tabellen-Integritätsbedingungen angeben, die in jedem Datenbankzustand erfüllt sein müssen. Mit der Anweisung ALTER lassen sich in bereits definierten Schemata zusätzliche Spalten hinzufügen oder auch der Typ einer Spalte modifizieren. Um Spalten, nicht benötigte Tabellen, Sichten oder auch Integritätsbedingungen zu löschen, wird der Befehl DROP verwendet. Wir kommen zum DML-Teil des SQL, welcher mit seinen Mitteln Formulierungen von Anfragen, Hinzufügen von neuen Daten (Zeilen) oder auch Verändern von Datenbeständen ermöglicht. Als erstes wenden wir uns den Anfragen zu. Es gibt zwei Arten von Anfragen in SQL [Man06], die der Tabellenausdrücke ( table expression ) und die der booleschen Ausdrücke ( conditional expression ). Ein Tabellenausdruck liefert eine abgeleitete Tabelle als Antwort, während der zweite TRUE, 56

63 FALSE oder [Bod07] UNKNOWN ausgibt. Wir konzentrieren uns hier auf Tabellenausdrücke, die durch SELECT-FROM-WHERE-Blöcke (SFW-Blöcke) charakterisiert sind: SELECT <column_names> FROM < table_names > [WHERE <search_condition>] Die für die Berechnung benötigten Inputtabellen sind im FROM-Teil aufgeführt. Der erste Schritt im einfachsten Fall stellt die Produktbildung aller Inputtabellen dar, dessen Ergebnis einem kartesischen Produkt der beteiligten Relationen entspricht. Ausgehend davon werden im optionalen WHERE-Teil die Zeilen ausgewählt, die den vorgegebenen Bedingung genügen. Wenn keine Bedingung vorhanden ist, werden alle Zeilen des Kreuzprodukts ausgewählt. Im SELECT-Teil wird letztlich bestimmt, welche Spalten im Ergebnis aufgenommen werden sollen. Wenn alle Spalten einbezogen werden sollen, kann man abkürzend * anstelle der Spaltennamen angeben. Im WHERE-Teil ist eine Boolean Value Expression erforderlich *Bod07+, bestehend aus Prädikaten und logischen Operatoren (AND, OR, NOT), welche eine der oben genannten Wahrheitswerte zurückliefert. Prädikate lassen sich in zwei Klassen teilen: wertbezogen (z.b. BETWEEN AND, IS NULL, LIKE) und tabellenbezogen (EXISTS, IN, UNIQUE, SOME, ANY). Fundamentale Prädikate (nicht anders ausdrückbar) sind die Vergleichsbedingungen (=, <>, <, <=, >=, >) und Existenzbedingungen. Da in Tabellen, im Gegensatz zu Relationen, Duplikate enthalten sein dürfen, können durchaus im Anfrageergebnis (insbesondere wenn die Ergebnisspalten keine Schlüsselkandidaten sind) redundante Zeilen enthalten sein. Um dies zu unterbinden, lässt sich das (falls gewünscht) durch explizite Angabe von DISTINCT im SELECT-Teil verwirklichen. Man kann außerdem durch Angabe von ORDER BY {ASC DESC} nach WHERE eine Sortierreihenfolge (aufsteigend bzw. absteigend) nach Spalten definieren. Wenn eine explizite Angabe für die Sortierung fehlt, wird implizit ASC verwendet [KE06]. Eine wichtige Rolle spielen die Aggregatfunktionen und Gruppierungen besonders im Bereich Data Warehousing. Sie berechnen einen skalaren Wert aus einer Menge von skalaren Werten ( Aggregat ), die aus einer Spalte einer Tabelle stammen (von Man[06]), es findet also eine Verdichtung der Daten statt. Zu Aggregatfunktionen gehören AVG zur Berechnung des arithmetischen Mittelwerts von einer gegebenen Menge von Zahlen, MAX zur Bestimmung des größten Elements der Spalte im Abfrageergebnis, MIN dagegen zur Bestimmung des kleinsten Werts, SUM zur Bildung der Summe (wobei NULL-Werte ignoriert werden) und COUNT zur Ermittlung der Anzahl der Datensätze in einer Tabelle. Bei COUNT gibt es zwei Varianten: COUNT(*) ermittelt die Anzahl aller Datensätze in einer Tabelle, wobei auch NULL-Werte mit berücksichtigt werden und COUNT(spalte) zählt diejenigen Datensätze der angegebenen Spalte, die inäquivalent zum NULL- WERT sind. Im Zusammenhang mit der Gruppierung GROUP BY sind Aggregatfunktionen besonders nützlich. GROUP BY unterteilt das Ergebnis des SFW-Blocks in Gruppen, die in den Gruppierungsspalten jeweils identische Werte aufweisen. Durch Angabe einer Bedingung im optionalen HAVING-Teil, lassen sich gebildete Gruppen auf bestimmte Gruppen für die Ergebnisausgabe einschränken, die die Bedingung erfüllen. Wir können nun das allgemeine Syntaxformat für ein table expression folgendermaßen darstellen (für die Abarbeitungsreihenfolge siehe Abb. 3.9): 57

64 SELECT [ALL DISTINCT] <column_names> FROM <table_names> [WHERE <search_condition>] [GROUP BY <grouping_specification>] [HAVING <search_condition>] Abb. 3.9 SELECT-FROM-WHERE Abarbeitungsreihenfolge SFW-Blöcke können auf verschiedene Weise verknüpft und geschachtelt werden. Wir haben bereits eine Verknüpfungsart kennengelernt das Kreuzprodukt es gibt weitere Operatoren, wie JOIN-Varianten, um Anfragen über mehrere Tabellen zu realisieren: NATURAL JOIN (hierbei werden Tabellen anhand des Vergleichs identischer Werte in Spalten mit gleichen Namen miteinander verbunden); INNER JOIN; LEFT, RIGHT oder FULL OUTER JOIN [KE06]. Wir betrachten hier den INNER JOIN (auch bekannt als Theta Join ). Mit dem INNER JOIN Operator lassen sich zwei Tabellen miteinander über die in der ON-Bedingung angegebenen JOIN-Spalten verknüpfen. Die Ergebnistabelle enthält diejenigen verbundenen Datensätze aus den zwei Tabellen, die die ON- Bedingung erfüllt haben. Als Beispiel seien das bedingte Kreuzprodukt und die äquivalente Realisierung mit JOIN angegeben [KE06]: 58

65 SELECT * FROM Tabelle 1, Tabelle 2 WHERE Tabelle 1.Spalte_A = Tabelle 2.Spalte_B SELECT * FROM Tabelle 1 INNER JOIN Tabelle 2 ON Tabelle 1.Spalte_A = Tabelle 2.Spalte_B Als Beispiel für geschachtelte Anfragen betrachten wir ein Beispiel mit dem EXISTS-Operator: SELECT T 1.Spalte_A FROM Tabelle 1 AS T 1 WHERE EXISTS (SELECT * FROM Tabelle 2 AS T 2 WHERE T 1.Spalte_A = T 2.Spalte_D AND T 2.Spalte_C > 0 Hier liegt eine korrelierte Unteranfrage vor (die Unteranfrage bezieht sich auf die Spalte_A der äußeren Anfrage); hierbei muss die Unteranfrage für jedes Tupel der äußeren Anfrage neu ausgewertet werden. Liegt keine Korrelation vor, so braucht die Unteranfrage nur einmal berechnet werden, was auf die Effizienz Einfluss hat. Das in der Anfrage vorkommende EXISTS liefert TRUE, wenn die Antworttabelle der Unteranfrage leer ist, ansonsten liefert es FALSE. Der Operator NOT EXISTS verhält sich genau umgekehrt. Wenn eine Unteranfrage einen skalaren Wert liefert, so kann diese Anfrage in die SELECT-Klausel und bei Boolean Value Expressions im WHERE-Teil der äußeren Anfrage integriert werden. In der FROM-Klausel wird eine geschachtelte Unteranfrage verwendet, um eine komplexere Anfrage modular aufzubauen [KE06]. Zu den klassischen Operatoren der Mengenlehre gehört die Vereinigung. In SQL werden zwei Varianten angeboten, bei denen vorausgesetzt wird, dass die Ergebnistypen von den zu vereinigenden Teilanfragen übereinstimmen: UNION, welche eine automatische Duplikateliminierung beinhaltet, und UNION ALL, die Duplikate in der Antworttabelle erlaubt. Ein weiterer Operator von Interesse ist IN, welcher ein Element auf Mengenmitgliedschaft testet, oder auch die Exklusion per NOT IN. (SELECT Spalte_A, Spalte_E FROM Tabelle 1 ) UNION ALL (SELECT Spalte_B, Spalte_C FROM Tabelle 2 ) SELECT Spalte_A FROM Tabelle 1 WHERE Spalte_E IN (SELECT Spalte_B FROM Tabelle 2 ) Die bereits vorgestellten Anfragen lassen sich als benannte Sichten ( Views ) in einer Datenbank deklarieren, wenn diese häufig verwendet werden. Sie stellen virtuelle Relationen dar, d.h. es werden keine neuen Tabellen in der Datenbank angelegt, sondern bei jeder Ausführung neu hergeleitet. Wie Tabellen können auch Sichten in Anfragen (als Zwischenergebnisse) referenziert werden, um komplexere Anfragen einfacher zu formulieren. Sichten modellieren das Konzept der externen Subschemata (vgl. Abb. 3.2), bei dem für einzelne Benutzergruppen nur die Datenmenge zur Verfügung gestellt wird, die sie interessieren oder zu dessen Zugang sie berechtigt sind (mittels CHECK OPTION). Eine Sicht kann folgendermaßen per CREATE VIEW deklariert werden: 59

66 CREATE VIEW Name AS ((SELECT Spalte_A, Spalte_E FROM Tabelle 1 ) UNION (SELECT Spalte_B, Spalte_C FROM Tabelle 2 )) Wir führen noch die Änderungsanweisungen im DML-Teil der SQL-Sprache ein; sie beinhaltet drei Grundoperationen: INSERT zum Einfügen von neuen Datensätzen in Tabellen, UPDATE zum Verändern bestehender Zeilen und DELETE zur Löschung nicht benötigter Zeilen. Bei INSERT gibt es Grundvarianten: Es lassen sich explizit ein oder mehrere Zeilen in eine Tabelle einfügen oder auch indirekt durch Generierung von Datensätzen mittels einer Anfrage. UPDATE führt die Modifikation, die im SET-Teil des UPDATE-Befehls definiert wird, an der angegeben Tabelle durch, wobei eine bedingte Änderung durch Angabe einer WHERE-Klausel realisiert werden kann. Bei der DELE- TE-Anweisung ist der WHERE-Teil auch optional: Wenn keine Bedingung angegeben wird, werden alle Datensätze in der Tabelle gelöscht. Löschung einer einzelnen Zeile kann nur durch eine identifizierende Bedingung (Einbeziehung eines Schlüsselkandidaten) bewerkstelligt werden. Die Syntaxformate der drei Änderungsoperatoren sehen folgendermaßen aus [Man06]: INSERT INTO <table_name> [(<list_of_columns>)] <table-expression> UPDATE <table_name> SET <list_of_assignments> [WHERE <conditional_expression>] DELETE FROM <table_name> [WHERE <conditional_expression>] JET SQL In dieser Arbeit wird Microsoft Access 2007 als DBMS verwendet, welche eine eigene SQL- Variante verwendet, namens JET SQL. JET SQL ist in erster Linie mit ANSI SQL-89 verwandt, unterstützt jedoch teilweise auch den Standard SQL-92. Um SQL-92 zu verwenden, muss dies nachträglich unter Access-Optionen (genauer: im Register Objekt-Designer ) aktiviert werden. Bestimmte ANSI SQL (standardisiertes SQL-92 durch ANSI) Features sind in JET SQL nicht implementiert und umgekehrt sind einige Features von JET SQL nicht in ANSI SQL vorzufinden. Wir werden hier jedoch die Standardeinstellung (SQL-89) verwenden, da die meisten Einschränkungen durch die integrierten Funktionen ausgeglichen werden. Wir befassen uns hier nur mit den wichtigsten Unterschieden [Mic08a] zwischen JET SQL und ANSI SQL, für weitere Recherchen sei auf [Rog03] verwiesen. JET SQL und ANSI SQL haben zum Teil unterschiedlich reservierte Wörter und Datentypen. Im Hinblick auf Platzhalterzeichen verwendet JET SQL das Zeichen % statt * bzw.? statt _ von ANSI SQL. Auch der BETWEEN AND Operator ( Ausdruck [NOT] BETWEEN Wert1 AND Wert2 ) weist Unterschiede auf: ANSI SQL besagt, dass der Wert1 kleiner oder gleich Wert2 sein muss. Im JET SQL kann der Wert1 auch größer als der Wert2 sein. Im JET SQL lassen sich nicht mehrere Zeilen explizit (abgesehen durch einer SELECT-Anweisung) einfügen. Folgende Einfüge-Anweisung würde beispielsweise fehlschlagen: 60

67 INSERT INTO Tabelle 1 (Spalte_A, Spalte_E) VALUES (123, 234), (345, 456) Ebenso kennt Access folgende Operatoren nicht [Man06]: NATURAL JOIN, MINUS, INTERSECT, MATCH, UNIQUE; FULL OUTER JOIN. Weitere ANSI SQL-Feature, die nicht unterstützt werden, sind z.b. DISTINCT-Aggregatfunktionsverweise ( SUM (DISTINCT Name) ) oder auch die CASE- Funktionalität. Aber CASE lässt sich in JET-SQL anhand der Switch-Funktion oder einfacherer Varianten durch die IIF-Funktion nachahmen. Im Hinblick auf ANSI-SQL weist JET SQL beispielsweise folgende zwei Aggregatfunktionen StDev(Ausdruck) und VarP(Ausdruck) auf: Die erste ermittelt die Standardabweichung vom Ausdruck (z.b. ein Spaltenname) bezogen auf eine Stichprobe, und VarP(Ausdruck) berechnet die Varianz von Werten. 3.3 JDBC und SWING Java ist eine objektorientierte Programmiersprache, entwickelt von Sun Microsystems, welcher im Januar 1996 das erste Java Development Kit (JDK 1.0) für Softwareentwicklung bereitgestellt hat [Ull08]. Mittlerweile 28 liegt das JDK, als Teil der Java Plattform-Standard Edition, in Version 6 vor [Wik08c]. Das JDK stellt Entwicklungswerkzeuge für die Implementierung von Java-Anwendungen und-applets zur Verfügung. Es enthält den rechnerplattform-spezifischen Bytecode-Interpreter (die Java Virtual Machine, kurz JVM für Windows, Solaris, Mac, ), welcher ein Java Programm in die Lage versetzt, auf jeder Rechner-Plattform ausführbar zu sein [HMG07]. Für das Montoringsystem wird Java vorwiegend für die Realisierung der Benutzerschnittstelle, in Form eines Applets, eingesetzt. Das Konzept der Applets ermöglicht es dank JVM, ein Applet von einem beliebigen Server zu laden und auf einem beliebigen Client-Rechner auszuführen. Bei der Umsetzung der Applet-Bedienoberfläche wird Swing verwendet. Swing gehört zu den Java Foundation Classes, welche eine Zusammenstellung von Klassenbibliotheken zur Gestaltung der Benutzeroberfläche und Bedienung einer Java-Anwendung darstellt. Wir werden im Abschnitt uns mit Swing näher beschäftigen. Aber im kommenden Unterkapitel werden wir uns die Anbindung zwischen der Datenbank und der Benutzeroberfläche näher ansehen. Hierbei werden wir auf JDBC (Java Database Connectivity) eingehen JDBC JDBC (Java Database Connectivity) [HMG07] stellt die Datenbankschnittstelle der Java-Plattform dar, die eine Spezifikation zum standardisierten Zugriff auf relationale Datenbanken (genauer: Datenbankmanagementsystem, da der DBMS selbst die wichtigen Aufgaben wie u.a. Anfragebearbeitung, Schema- und Transaktionsverwaltung wahrnimmt) unterschiedlicher Hersteller bereits- 28 Stand: September

68 tellt [FB07]. Die JDBC-API 29 ermöglicht es, die Daten aus der Datenbank in für Java handhabbare Objekte umzuwandeln und umgekehrt nach Bearbeitung zurück in die Datenbank zu schreiben. Die JDBC-API setzt sich aus den zwei Paketen 30 java. sql und javax. sql zusammen. Das Paket java. sql wird auch als JDBC Core API bezeichnet, auf das wir uns konzentrieren werden. Das Paket beinhaltet wichtige Interfaces (u.a. Connection, ResultSet, Statement), die durch die entsprechenden JDBC-Treiber implementiert werden. Es stellt die für client-seitige Anwendungen benötigten Funktionalitäten bereit, die unter anderem Folgendes umfassen: den Verbindungsaufbau zu einer Datenbank; das Senden von Abfragen und Updates in Form von SQL-Statements an die Datenbank; die Entgegennahme der Abfrage-Ergebnisse und dabei die Abbildung datenbankspezifischer Datentypen auf Java-kompatible Datentypen [HMG07]. Der Anwendungsentwickler ist von den Implementierungsdetails der Treiber abgeschirmt und arbeitet hauptsächlich mit der JDBC-API. Es gibt vier Arten der Treiberarchitektur für den JDBC- Zugriff. Je nach Treibertyp verläuft der Zugriff auf ein Datenbanksystem unterschiedlich (vgl. Abb. 3.10) [HMG07]: JDBC-ODBC-Bridge (Typ 1): Mit diesem Treibertyp lässt sich eine Verbindung zu denjenigen Datenbankmanagementsystemen aufbauen, für die ein ODBC 31 - Treiber existiert. Es stellt eine Brücke dar, die die Aufrufe von JDBC in ODBC Aufrufe umwandelt, so dass auch auf Datenbanksysteme zugegriffen werden kann, die JDBC nicht direkt unterstützen. Da eine Abfrage mehrere Schichten durchläuft, entstehen Reibungsverluste durch Über- Abb. 3.10: JDBC-Treibertypen [HMG07] setzung einzelner Schichten, die auf die Abarbeitungsgeschwindigkeit Einfluss nehmen [Ull08]. Es ist zu beachten, dass die Datenbank als ODBC-Datenquelle auf dem Client- Rechner registriert sein muss. Native-API Partly Java-Driver (Typ 2): Dieser Treiber benötigt keine ODBC-Schnittstelle, deswegen erfolgt der Zugriff auf die Datenbank etwas schneller [FB07]. Der Treiber selbst ist nur teilweise in JAVA geschrieben und benötigt für den DBMS Zugriff eine Herstellerspezifische Bibliothek, welche auf dem Client-Rechner vorhanden sein muss. 29 API = Application Programming Interface 30 Pakete stellen eine Gruppierung von zusammengehörigen Klassen und Schnittstellen für einen bestimmten Zweck dar. 31 ODBC (Open Database Connectivity) ermöglicht es, über eine genormte Schnittstelle unterschiedliche Datenbanken anzusprechen. 62

69 Net-Protocol All-Java-Driver (Typ 3): Es handelt sich um einen vollständig in Java implementierten Treiber. Der Treiber kommuniziert über einen Applikations-Server mit der Datenbank, welche das netzwerkunabhängige Protokoll in ein DBMS-spezifisches Protokoll umwandelt. Native Protocol All-Java-Driver (Typ 4): Dieser Treiber ermöglicht eine direkte Kommunikation mit der Datenbank über eine Socket-Verbindung. Dazu werden die JDBC-Aufrufe in ein für das DBMS verständliches Netzwerkprotokoll umgesetzt. Zu beachten ist, dass Applets von außen (deren Rechner das angesprochene DBMS nicht beinhaltet) nur per Typ 3- oder 4-Treiber auf das DBMS zugreifen können. Bei der Implementierung des Monitoringsystems wird der Typ 1 Treiber (JDBC-ODBC-Bridge) benutzt, da es sich bei dem eingesetzten Rechner sowohl um einen Client als auch einen Datenbankserver handelt und wegen der Verfügbarkeit des ODBC-Treiber mit Microsoft Access. Wir gehen über zu den Phasen des Zugriffs auf ein DBMS, die beinhalten: die Verbindungsherstellung zu einem DBMS, das Absetzen von SQL-Befehlen per Statement, das Auswerten des Ergebnisses, das Schließen des SQL-Statements und der Verbindung zum DBMS [HMG07]. Diese Schritte werden im Folgenden vorgestellt. Der Verbindungsaufbau zum DBMS erfolgt in zwei Phasen. Als erstes wird ein geeigneter JDBC- Treiber über den Treibermanager in der Anwendung geladen und anschließend wird durch Erstellung eines Connection-Objekts die Verbindung hergestellt. Durch die folgende Methode (es existieren mehrere Möglichkeiten, wobei wir uns hier auf die relevante Variante beschränken) static Class forname(string classname) der Klasse Class wird der JDBC-Treiber mit dem angegebenen Namen (in unserem Fall sun. jdbc. odbc. JdbcOdbcDriver) geladen und dem JDBC-Treiber-Manager bekannt gemacht, um dies bei der Treibersuche im Prozess des Verbindungsaufbaues zu berücksichtigen. Mittels der Methode static Connection getconnection(string url, String user, String password) kann die Verbindung mit der in url verwiesenen Datenbank mit dem korrekten Benutzernamen und Kennwort hergestellt werden. Die URL besteht aus drei Komponenten: jdbc: < subprotokoll >: < subname > Beispiel: jdbc: odbc: MONALISA DB Das Subprotokoll spezifiziert den zu verwendenden DBMS abhängigen Treiber, wobei bei Angabe von odbc die ODBC-Brücke für den Zugriff auf die in subname angegebene Datenbank verwendet wird. Über die hergestellte Datenbankverbindung können nun SQL-Anweisungen ausgeführt werden, wobei JDBC hierfür drei Interfaces zur Verfügung stellt: Statement, PreparedStatement und CallableStatement. Die SQL-Anweisungen (SQL-Statements) werden durch Objekte repräsen- 63

70 tiert, die diese Interfaces implementieren. Die Statement-Objekte 32 werden über das vorhin erzeugte Connection-Objekt, mittels der Methode Statement createstatement() erstellt. Das Interface Statement stellt Methoden für statische 33 SQL-Statements bereit, welche die SQL- Anweisung als String zum DBMS senden. Mit Hilfe des Statement-Objekts lassen sich nun Anfragen über die Methode ResultSet executequery(string sql) und Änderungsoperationen (z.b. INSERT, UPDATE, DELE- TE, CREATE Befehle) über int executeupdate (String sql) durchführen. Durch Sammlung einzelner Statements mittels void addbatc(string sql) zu einem Batch-Job und anschließend einer gebündelten Ausführung durch int executebatc() ergibt sich Performancegewinn im Vergleich zur separaten Ausführung der SQL-Statements. Als Rückgabewert einer Änderungsoperation wird ein int-wert geliefert, welcher die Anzahl der betroffenen Datensätze angibt. Bei Ausführung von executequery() wird eine Ergebnistabelle vom Typ ResultSet als Ergebnis ausgegeben. Die Datensätze können mit Hilfe eines Cursors nacheinander per boolean next() Methode (ermöglicht Vorwärtsbewegung des Cursors) unter dem Einsatz von unterschiedlichen get() Methoden auf die einzelnen Werte spaltenweise (durch Angabe von Spaltenname oder -position) zugreifen. Nach Ende der Ergebnisverarbeitung sollte man das Statement per void close() schließen, ebenso die Datenbankverbindung nach Beendigung der Anwendung (ebenfalls durch void close()) SWING Für eine gute Interaktivitätsmöglichkeit zwischen dem Monitoringsystem und den Benutzern ist eine geeignete grafische Bedienoberfläche unumgänglich. Es soll den Anwendern einen einfachen Zugang zu den angebotenen Funktionalitäten des Monitioringsystems gewährleisten. Das Benutzerinterface wird in Form eines Applets implementiert, um bei der Verwendung ohne lokale Installation auszukommen und mit Hilfe eines Browsers fast auf jeden Rechner laufen zu können. Für die Oberflächenentwicklung bietet Java zwei APIs an: Abstract Window Toolkit (AWT) und Swing [HMG07]. AWT wurde als erstes mit JDK 1.0 eingeführt [FB07]. Sie besitzt nur einen eingeschränkten Satz von Funktionen, wie Ereignisbehandlung und Komponenten (z.b. Button, TextField) zur Gestaltung der Programmoberfläche. Eine Eigenheit von AWT ist, dass sie alle ihre Java - Komponenten auf eine Komponente der darunterliegenden Plattform abbildet und dadurch eine enge Bindung mit dem jeweiligen Betriebssystem vorliegt. Die Komponenten von AWT werden deswegen als schwergewichtige Komponenten bezeichnet. Die Komponenten werden letztlich durch das Betriebssystem gezeichnet. Um aber eine gewisse Unabhängigkeit der Java-Anwendung vom Betriebssystem zu gewährleisten, müssten für jede Plattform sogenannte Peer-Objekte geschrieben werden, welche als eine Art Vermittler zwischen den jeweiligen AWT Komponenten und den zugehörigen grafischen Elementen des Betriebssystems dienen. Dies erklärt die begrenzte Menge der verfügbaren Komponenten, da AWT nur eine Schnittmenge der verschiedenen Komponenten 32 Wir betrachteten hier nur noch das eingesetzte Interface Statement. 33 Durch Einbindung von Java-Hostvariablen in einer SQL-Anweisung (bevor dies als String geschickt wird) lässt sich Dynamik in die statische Struktur einbringen. 64

71 unterschiedlicher Betriebssysteme realisieren konnte. Ein weiterer Nachteil ist, dass durch die Zeichnung der Komponenten in eigenen unabhängigen Bereichen, die Verwaltung der Komponenten aufwendig ist und deswegen negativen Einfluss auf die Laufzeit-Performance hat. Die einzelnen Komponenten lassen sich außerdem schlecht erweitern bzw. anpassen (aufgrund der Bindung über Peer-Objekte auf die Komponenten des Betriebssystems). Swing besitzt im Gegensatz zu AWT leichtgewichtige Komponenten, die vollständig in Java implementiert sind und von der Java Virtual Maschine selbst gezeichnet werden. Aus diesem Grund sind Swing-Komponenten unabhängig von dem verwendeten System und können auf unterschiedlichen Plattformen ein einheitliches Aussehen haben. Jedoch ist AWT bei der Implementierung von Swing-basierten GUIs (Graphical User Interface) nicht wegzudenken, so dass viele Klassen von AWT noch Verwendung finden [HMG07]. Selbst in der Implementierung der Bedienoberfläche des Monitoringsystems werden hauptsächlich Swing-Komponenten eingesetzt, aber für grafische Ausgaben wird die Klasse java. awt. Canvas verwendet. Im Folgenden werden wir zunächst auf das Architekturmuster Model-View-Controller (MVC) eingehen und dieses danach auf Swing übertragen, basierend auf [HMG07]. Unter der Benutzerinteraktivität des Programms (bzw. Systems) sind im Allgemeinen die Entgegennahme der Benutzereingaben und die Ausgabe des Ergebnisses der Verarbeitung zu verstehen. Dementsprechend lässt sich das System in folgende drei Teilsysteme zerlegen: Verarbeitung, Ausgabe und Eingabe. Eine solche Aufteilung entspricht dem Architekturmuster (Designpattern) MVC (siehe Abb. 3.11), insbesondere ist dieses adäquat für Systeme mit einer grafischen Bedienoberfläche. Dabei werden die Verarbeitungslogik des Systems auf ein Model, die Ergebnisausgabe auf ein View, und die Eingabe bzw. die Bedienung auf einen Controller abgebildet. Das Ziel dieses Designs ist die Erweiterbarkeit und bessere Wartbarkeit des Systems, infolge der Zerlegung in unabhängige Teilsysteme. Der Controller (Steuerung) nimmt die Benutzereingaben entgegen, die unter Umständen aus verschiedenen Quellen stammen können (z.b. Schaltflächen, Textfelder; als Eingabegeräte: Maus, Tastatur). Die entgegengenommenen Daten werden vom Controller an das Model weitergeleitet und die Views werden anhand der Eingaben angepasst. Abb. 3.11: Model View Controller (MVC) Das Teilsystem Model stellt die Programmfunktionalitäten (Verarbeitungslogik) bereit, die die Eingabedaten des Benutzers interpretieren und Datenänderungen durchführen. Die Views werden vom Model über die erfolgten Änderungen benachrichtigt, solange die Views als Beobachter bei dem Model registriert sind. Die Aufgabe des Teilsystems View besteht darin, den aktuellen Zustand des Models grafisch für den Benutzer in dem von ihm gewählten Format darzustellen. Dafür muss der View die geänderten Daten vom Model abholen und die Darstellung synchronisieren. Die Architektur der Swing API basiert auf MVC, wobei hier View und Controller aufgrund der großen Abhängigkeit voneinander zu Delegate zusammengefasst werden. Die Trennung wird hier 65

72 aufgehoben, da das Erscheinungsbild und die Bedieneigenschaft einer Swing-Komponente im Sinne der Pluggable Look and Feel zur Laufzeit geändert werden können. Die Architektur von Swing ist in Abbildung 3.12 veranschaulicht. Die Klassen Component und Container bilden die Schnittstelle zum verwendeten Betriebssystem. Die Klasse Container kann viele Objekte (Komponenten) vom Typ Component beinhalten, die die Konstruktion von komplexeren Bedienoberflächen durch Komposition zulassen. Abb. 3.12: Swing Architektur [HMG07] Die Klasse JComponent im Model enthält die Grundfunktionalität von Swing, von der alle konkreten Komponenten (z.b. JButton, JTextArea, JScrollPane, JPanel) abgeleitet werden. Für Details bzgl. der Komponenten sei auf [FB07] und [HMG07] hingewiesen. Die Klasse ComponentUI bildet die Schnittstelle von Delegate. Delegate übernimmt die Zeichnung (View) der Komponenten und die Reaktion (Controller) auf die Benutzereingaben. Für jede Komponente existiert eine Erweiterung der Klasse ComponentUI, die die Komponente im Aussehen und Verhalten charakterisiert bzw. die Aufgaben von Delegate umsetzt. Das Statusmodell verwaltet den Erscheinungsstatus der Komponenten (z.b. Checkbox kann markiert oder nicht markiert sein) und beeinflusst dadurch die Zeichnung einer Komponente durch den View. Infolge von Benutzereingaben (abgefangen durch Listener-Schnittstelle) revidiert der Controller den entsprechenden Status der betreffenden Komponenten im Statusmodell, ebenso das Datenmodell der Komponenten. 66

73 4 Datenbankentwurf Das Ziel dieses Kapitels ist der Entwurf der folgenden zwei Grundaspekte: Die Realisierung des künstlichen Szenarios, Game of Life, und besonders der Aufbau eines avancierten, vielschichtigen Monitoringsystems mit Mitteln eines Datenbanksystems. Es wird angestrebt, dass das einzusetzende Datenbanksystem nicht nur als Datenbasis für das System MONALISA eingesetzt wird, sondern vielmehr soll die primäre Verarbeitungslogik (außer den Steuerungskomponenten) durch das DBMS umgesetzt werden. In diesem Kapitel soll hauptsächlich das Datenmodell, also die Datenbank für das Anwendungsprogramm, entworfen werden: Im Abschnitt 4.1 werden wir die Entwurfsziele der zu entwerfenden Datenbank zusammenfassen. Ausgehend von der Anforderungsspezifikation werden wir im Abschnitt 4.2 zur Modellierung des konzeptuellen Schemas das Entity-Relationship-Modell einsetzen, welche wir dann im letzten Abschnitt 4.3 in das relationale Schema überführen werden. 4.1 Problemdefinition und Anforderungsanalyse Das erste Ziel dieser Diplomarbeit ist die Simulation diskreter Prozesse und künstlicher Ereignisse, auf denen Monitoringaufgaben durchgeführt werden können. Das künstliche Szenario soll die Realwelt ersetzen, um einen kontinuierlichen Fluss (in diskreten Zeitschritten) von Ereignissen zu simulieren. Dieser Schritt ist besonders in der Phase der Entwicklung von Bedeutung, um die Monitoringkomponenten hinsichtlich Korrektheit, Zuverlässigkeit und Effizienz ausgiebig zu erproben. Ein (künstliches) Simulationssystem bietet zudem den Vorteil von Variierbarkeit und Kontrollierbarkeit des Einsatzfelds, je nachdem welcher Aspekt des Monitoringsystems gerade zu analysieren ist. Außerdem liegen die Inputdaten (Ereignisse) innerhalb des Simulationssystems zur Verfügung und müssen nicht per Sensoren explizit dem System zugeführt werden. Bei Wahl eines künstliches Szenarios muss beachtet werden, dass die Simulation so weit wie möglich Prozesse der realen Welt nachahmt oder dass zumindest in den wichtigsten Merkmale vergleichbar mit realen Prozessen ist. Außerdem sollten die Simulationsergebnisse für den realen Einsatz übertragbar sein. Jedoch ist eine Abstraktion für Modellierungszwecke unumgänglich und wünschenswert, um sich auf die wichtigsten, entscheidenden Faktoren zu konzentrieren. Im Rahmen der Diplomarbeit ist wohlüberlegt ein aus der Forschungsrichtung Artificial Life stammender Simulator verwendet worden, denn AL-Szenarien weisen zahlreiche Gemeinsamkeiten mit realen Monitoringanwendungen auf, z.b. Börsenkurs- oder Verkehrsmonitoring. Als ereignis-erzeugender Simulator soll der zelluläre Automat Game of Life (GoL) eingesetzt werden. Es sprechen wichtige Gründe für den Einsatz von GoL: Einerseits ist die relativ unkomplizierte Implementierbarkeit durch die drei Regeln gegeben (vgl. Kapitel 2.3), anderseits besitzt GoL - zur Verhaltensklasse 4 gehörig (siehe Abschnitt 2.2.2) einen hinreichend hohen Komplexitätsgrad, der Raum für unvorhersehbare Entwicklungen und das Auftreten von zufälligen, aber charakterisierbaren Ereignissen erlaubt, wie es für ein reales Einsatzumfeld üblich ist. Durch Veränderungen im Startzustand können verschiedene Rahmenbedingungen simuliert werden, die stets zu einzigartigen Prozessverläufen führen, welche letztendlich unter anderem auf die Art der Ereignisse 67

74 und deren Auftretungswahrscheinlichkeit Einfluss nehmen. Dadurch wird die Forderung nach Variierbarkeit und Kontrollierbarkeit des Simulators selbst erfüllt. Der Simulator soll auch während der Laufzeit Konfigurationsfähigkeit aufweisen, um dem Benutzer die Möglichkeit zu geben, den Simulationsverlauf aktiv zu beeinflussen bzw. in die von ihm gewünschte Richtung zu lenken. Deswegen muss bei der Umsetzung von GoL in der Datenbank darauf geachtet werden, auch vom Benutzer eingeleitete Konfigurationen in der Simulationsumgebung zuzulassen. Jeder Zustand des zellulären Automaten wird durch die Zustände der einzelnen Zellen definiert. Infolgedessen ist es bei der Realisierung von GoL mit einem DBMS notwendig, jede einzelne Zelle, die abstrakt in einem zweidimensionalen Raum liegt und für die Beschreibung des Automatenzustands von Relevanz ist, eindeutig identifizierend, in der Datenbank abzulegen. Den Benutzern sollen auch verschiedene Startkonfigurationen für den Simulator zum Auswählen in der Datenbank angeboten werden, welche einen Eindruck von der Mächtigkeit des Simulators (im Hinblick auf den unterschiedlichen Simulationsverlauf) vermitteln kann. Grundsätzlich sollen sowohl die Startzustände als auch die während des Simulationsverlaufs auftretenden Zustände in der Datenbank abgebildet werden. Dies ist notwendig, da jede Entwicklung des Simulators in den kommenden Zeitschritt von dem in der Datenbank dargestellten aktuellen Zustand ausgehen soll. Jeder erfolgende Entwicklungsschritt des Simulators soll demzufolge die Abbildung eines Datenbankzustands auf den nächsten Zustand der Datenbank darstellen. Das Hauptkonzept des zu realisierenden Systems stellen die Komponenten des Monitoringsystems dar. Die erste, eigens auf das hier verwendete künstliche Szenario GoL ausgerichtete, Monitoringkomponente soll die Evolutionsschritte der Zellen systematisch erfassen. Hier soll keine reine Beobachtung stattfinden, vielmehr soll sie mit Hilfe der Entwicklungsregeln die kommende Änderung des Automatenzustands für den nächsten Zeitschritt vorhersagen können. Die Evolution-Monitoringkomponente soll in der Lage sein, die stattgefundenen Zustandsveränderungen der Zellen während des Übergangs vom letzten Zeitpunkt in den gegenwärtigen Zeitpunkt zu erfassen (Welche Zellen sind geboren worden? Welche sind gestorben?), aber auch die künftig stattfindenden Änderungen der Zellzustände vom jetzigen zum kommenden Zeitpunkt (Welche Zellen werden zum Leben erweckt? Welche werden sterben?). Über den gesamten Zeithorizont eines Simulationslaufs, ausgehend von einer Startkonfiguration bzw. -population, hat das System außerdem zu erkennen, welche maximale Ausbreitung eine Population während des Zeitverlaufs erreicht, oder anders formuliert, welche Lebensräume die Nachkommen einer Startpopulation im Laufe der Evolution besiedelt haben. Eine der wichtigsten Monitoringaufgaben, die es zu realisieren gilt, ist es, zusammenhängende Strukturen in der vom Simulator bereitgestellten Datenmenge durch Gruppierung zu finden. Die Datenmenge entspricht der Gesamtheit der lebenden Zellen im zellulären Automaten, die den Zustand des Automaten definieren. Das Vorkommen bzw. die Verteilung von lebenden Zellen im Zellraum können von unterschiedlichem Ausmaß sein, hierbei gilt es nach dem Konzept von Zusammenhangskomponenten (vgl. Abschnitt 2.4.1) Clustering durchzuführen. Dabei soll ein Cluster nur die lebenden Zellen enthalten dürfen, die unmittelbar benachbart sind. Die vollzogene Zuordnung der Zellen zu einem bestimmten Cluster soll in der Datenbank sichtbar sein, wobei jeder Cluster wohlunterscheidbar sein muss. Jeder ermittelte Cluster (durch Gruppierung) soll einen 68

75 eindeutigen, nur einmal im gesamten Simulationsverlauf vergebbaren ID-Wert zugewiesen bekommen. Die eindeutige Identifizierung über die gesamte Simulationsdauer hinweg ist besonders im Hinblick auf die Protokollierungsfunktion von hoher Bedeutung. Zur Protokollierung soll der Zeitpunkt des ersten Auftretens des Clusters und der Erlöschungszeitpunkt gehören. Ferner soll auf der nächst höheren Ebene, mit parametrisierbarem Einzugsbereich, eine Gruppierung von Clustern zu Clusterverbänden ermöglicht werden. Die Mustererkennung als Teil des Monitoringsystems soll die Fähigkeit besitzen, bestimmte, vordefinierte, d.h. dem System bekanntgemachte Muster fehlerfrei zu erkennen. Es soll Wert auf höchste Erkennungsgenauigkeit gelegt werden, wobei die Laufzeit-Performance in diesem Fall nicht im Vordergrund steht. Das System soll die zu erkennenden Objekte in all seinen annehmbaren Erscheinungsformen identifizieren können (z.b. der Blinker soll bei seinen zwei Formen als dieser erkannt werden, jedoch bildet das relativ komplexe Muster Fisch, im Sinne der Mustererkennung eine Ausnahme, bei der nur die nach Osten fliegende Variante erkannt werden soll, um die Laufzeit-Performance nicht zu verschlechtern). Außer Blinker und Fisch sollen auch Gleiter und Quad erkannt werden, da sie als Repräsentanten oszillierender Strukturen ein Spektrum von einfachen bis hin zu komplexen Mustern im Sinne der Mustererfassung ergeben. Die Objekte, die keine Zwischenformen annehmen und unbeweglich sind (also stabil), müssen vom System als Stilleben erkannt werden. Hierbei soll die Fähigkeit des Systems demonstriert werden, für ihn unbekannte Objekte zu klassifizieren, indem es nur anhand eines Verhaltensmerkmals verfährt. Außerdem gilt es, das Auftauchen eines Musters mit seiner Exemplaranzahl chronologisch in der Datenbank aufzuzeichnen. Mit dem Monitoringkonzept des Systems soll auch, aufbauend auf Clustering, dem Benutzer die Flugbahn-Verfolgung bzw. Trajektorienbestimmung für jeden Cluster ermöglicht werden. Dabei ist ein Massenpunkt des Clusters repräsentativ zu wählen, welcher in jedem diskreten Zeitschritt über die gesamte Lebensdauer des Clusters hinweg aufgezeichnet wird. Die Position eines Clusters soll wie bei einer Zelle im zweidimensionalen Format vorliegen, definiert durch die Werte auf der x- und y-achse. Die anspruchsvollste Monitoringkomponente, die das Monitioringsystem beinhalten soll, ist die Kollisionserkennung zwischen zwei oder mehreren Objekten (Clustern). Es gilt nicht nur das stattgefundene Kollisionsereignis zu registrieren, sondern auch die zukünftigen potenziellen Kollisionskandidaten zu identifizieren. Für jedes Kollisionspaar soll eine Kollisionswahrscheinlichkeit berechnet werden, die auf mehrerer Faktoren beruht (z.b. Eintritt in Gefahrenbereich, Entfernung, Annäherungstendenz). Dem Benutzer sollen Methoden zur Verfügung gestellt werden, die es ermöglichen, die Kollisionsberechnung auf bestimmte Objekte seiner Wahl einzugrenzen. Die berechneten Kollisionswahrscheinlichkeiten zu den einzelnen Kollisionspaaren sind in der Datenbank mit ihren jeweiligen Entfernungen chronologisch zu protokollieren und sollen bei Bedarf zu Analysezwecken eingesehen werden dürfen. Ebenso sollen die Kollisionsereignisse selbst nach ihrer Art (partiell bzw. totale Verschmelzung) in die Datenbank eingetragen werden, ebenso das Ereignis der Spaltung eines Objekts in zwei oder mehrere Teile. Diese Monitoringkomponente soll auch in der Lage sein, aus den vorliegenden Daten die aktuelle räumliche Position zu bestimmen, die Bewegungsrichtung einzelner Objekte zu ermitteln und ebenso die aktuellen Bewegungstendenzen einzelner Kollisionspartner zueinander zu extrapolieren. 69

76 Im folgenden Abschnitt werden wir das Anwendungsgebiet auf konzeptueller Ebene modellieren, wobei wir uns auf die wesentlichen Aspekte konzentrieren werden und die Protokollierungsfunktionalität (welche wir nur als eine zusätzliche Funktionalität betrachten und welche keinen eigenständigen Entity-Typ bei der konzeptuellen Modellierung darstellt) der einzelnen Bereiche weitgehend ausblenden. 4.2 Entity-Relationship-Schema Wir befassen uns zur Erstellung des ER-Schemas zunächst mit dem Simulator GoL selbst. GoL gehört zur Klasse der zweidimensionalen, binären, zellulären Automaten, die aus n Zellen bestehen. Abbildung 4.1 zeigt diesen Aspekt durch die Beziehung enthält. Zur Berechnung der Folgegenerationen in diskreten Zeitschritten werden die Entwicklungsregeln angewandt, bei denen bei den Zuständen einer Zelle zwischen tot und lebend unterschieden werden. Dies kann durch die Generalisierung is_a dargestellt werden, wobei die beiden Untertypen die Attribute X, Y erben. Hierbei bezeichnet X den Wert auf der x-achse und Y den Wert auf der y-achse des Koordinatensystems. In Kombination bilden die beiden Werte einen Schlüssel, welche jede Zelle eindeutig adressiert. Die Nachbarschaftsdefinition von Moore mit dem Radius 1, die für jede Zelle in GoL gleichermaßen gilt, ist durch die Beziehung benachbart_zu dargestellt. Es ist zu berücksichtigen, dass die Zellen an den vier Rändern (sechs Nachbarn pro Zelle) und besonders an den Ecken (jeweils drei Nachbarn) von der Normanzahl der Nachbarn (acht) abweicht. Wie jeder Zustand des Automaten, können auch die unterschiedlichen Startzustände des zellulären Automaten bzw. Simulators durch die Zustände der Zellen dargstellt werden. Die Variabilität der möglichen Startzustände sind durch die Gesamtzahl der Zellen begrenzt. Abb. 4.1: Relationship-Typen im Kontext des Simulators 70

77 Wir haben die Zellen bisher nur in die Untertypen lebend und tot gegliedert, weil wir nur aus dem aktuellen Zeitpunkt (die Gegenwart t) betrachtet haben. Wenn wir den Zeithorizont auf Vergangenheit (t 1) und Zukunft (t + 1), jeweils um einen Zeitschritt erweitern würden, lassen sich für den Entity-Typen Zelle andere Untertypen finden. Dies ist besonders für die erstgenannte Monitoringkomponente Evolution von Relevanz (vgl. Abb. 4.2). Eine Zelle, die in t 1 gelebt und in t den Status tot angenommen hat, wird zum Zeitpunkt t als gestorbene Zelle bezeichnet. Wenn eine Zelle sowohl in t 1 und t den Zustand lebend angenommen hat, dann sagt man, dass diese Zelle überlebt hat. Eine lebende Zelle ist gegenwärtig neugeboren, wenn diese im letzten Zeitschritt den Zustand tot aufwies. Eine momentan tote Zelle wird als Geburtskandidat bezeichnet, wenn es im kommenden Zeitschritt den Zustand lebend annehmen wird. Eine derzeit lebende Zelle gilt als Todeskandidat, wenn es aufgrund der Entwicklungsregeln für den nächsten Zeitschritt nicht überlebensfähig ist. Abb. 4.2: Weitere Untertypen der Zelle nach Erweiterung des Zeithorizonts, angeordnet in der Reihenfolge: Vergangenheit, Gegenwart und Zukunft bzgl. eines Simulationszeitraums. Wenn wir die Zellen über die gesamte Simulationszeit hinweg beobachten würden, so existierten zwei weitere Untertypen: aktive und inaktive Zellen. Eine Zelle ist aktiv, wenn es mindestens einmal im Simulationsverlauf den Zustand lebend angenommen hat. Hat eine Zelle dagegen stets den Zustand tot aufgewiesen, so spricht man von einer inaktiven Zelle. Die Gesamtheit der aktiven Zellen während eines Evolutionszeitraums entspricht dem Lebensraum einer Population. Abb. 4.3 Relationship-Typ zwischen den Entity-Typen Clusterverband, Cluster und lebende Zelle Clustering von Elementen kann durch verschiedene Verfahren durchgeführt werden (vgl. Abschnitt 2.4.1). Bei MONALISA wird auf Grundlage von Zusammenhangskomponenten ein Cluster gebildet. Ein Cluster lässt sich als eine Häufung von lebenden Zellen konkretisieren (siehe Abb. 4.3), wobei die benachbarten, lebenden Zellen (im Sinne der Moore Nachbarschaft) durch Kanten verbunden sind und so jede einzelne Zelle von allen anderen Zellen der Zusammenhangskomponente erreichbar ist. Zu einem diskreten Zeitpunkt lässt sich jede lebende Zelle einem Cluster zu- 71

78 ordnen, dessen Kardinalität mindestens eine lebende Zelle beträgt. Wenn n N + Zellen den Zustand lebend besitzen, so gibt es mindestens 1, aber maximal n Cluster. Analog gilt dies für einen Clusterverband, wobei hier der maximal zulässige Abstand zwischen zwei Clustern für die Zuordnung zu einem Clusterverband zu definieren ist. Die drei Entity-Typen bilden damit durch die is_part_of Beziehung eine Hierarchie. Sowohl Cluster als auch Clusterverband können wie Zellen (ihrerseits durch Raumkoordinaten) durch ihr Schlüsselattribut ID eindeutig identifiziert werden. Ähnlich wie Clusterverband bildet Muster einen Entity-Typen auf der höchsten Hierarchiestufe. Es ist also ein Obertyp, dessen Entity sich aus einer oder mehreren Instanzen des Entity-Typs Cluster zusammensetzt. Ein Muster-Typ kann zwar aus einer oder mehreren Clusterverbänden bestehen, aber mindestens aus einem Cluster. Der Muster-Entity-Typ ist auch im Hinblick auf Generalisierung ein Obertyp, welcher in disjunkte Untertypen unterteilt wird. Disjunkt, weil die Entitymengen der Untertypen paarweise nicht überlappen und so die eindeutige Identifizierung eines bestimmten Musters ermöglichen. Die hier abgebildete Generalisierung ist keine vollständige, denn das Mustererkennungssystem erfasst nur eine kleine Teilmenge der theoretisch unendlichen Menge von Mustertypen (falls wir die Anzahl der Zellen als unendlich annehmen würden). Abb. 4.4: Relationship-Typen und Entity-Typen, die bei der Umsetzung der Mustererkennung berücksichtigt werden müssen. 72

79 Jeder Muster-Untertyp besitzt ein oder mehrere Merkmale, welche für jede Instanz von ihm charakteristisch sind und zur Identifizierung im Rahmen der Musterkennung einbezogen werden können. Die Muster-Untertypen Blinker, Fisch, Gleiter und Quad, die das System u.a. erkennen soll, können durch ihre Form - der charakteristischen Anordnung der lebenden Zellen - spezifiziert werden. Es ist zu beachten, dass alle diese Untertypen wiederrum Untertypen bzw. Untervarianten aufweisen (vgl. Abb. 4.4: Gleiter). Stilleben beschreibt dagegen eine Gruppe von Muster- Instanzen, die die Eigenschaft von Beständigkeit über die Simulationszeit durchweg zeigt. Der Mustererkennung muss diese Eigenschaft indirekt vermittelt werden, ähnlich wie die relativen Anordnungspositionen der lebenden Zellen für die obengenannten Musterformen. Entgegenkommend ist die Eigenschaft von GoL, dass ein stabil gewordenes Muster ohne äußeren Einfluss (durch andere annähernde Objekte) dauerhaft seine Form beibehält. Die bei der Trajektorie-Monitoringkomponente abzubildende Flugbahn eines Cluster-Objekts erfordert die chronologische Aufzeichnung der Positionen des Clusters über die Simulationszeit hinweg. Meistens besitzt ein Cluster mehrere Zellen, die die Fortbewegung ermöglichen und ebenso im Abstrakten seine Existenz über mehrere Zeitschritte lang sichern. Die räumliche Ausdehnung eines Objekts erfordert einen Massenpunkt, der das Objekt hinsichtlich seines Ortes und seiner Masse für die Trajektorienzeichnung vertritt. Jeder Massenpunkt entspricht einer Lokalisierung des Objekts im Raum zu einem bestimmten Zeitpunkt (falls die einzelnen Massenpunkte ihrem Erfassungszeitpunkt zugeordnet wurden), welcher, nacheinander projiziert, die Bewegung des Objekts abbildet. Eine Trajektorie besteht demnach aus einer endlichen 34 Menge von Massenpunkten (vgl. Abb. 4.5), wobei zur Darstellung einer Flugbahn mindestens zwei Massenpunkte verfügbar sein müssen. Eine Trajektorie ist stets einem bestimmten Cluster zugeordnet, so dass der ID Wert einer Trajektorie dem des Clusters entspricht. Ein Massenpunkt kann ebenso durch die ClusterID dem Cluster zugeordnet werden, jedoch ist für die eindeutige Identifizierung das Attribut Zeit notwendig (die Koordinaten (X,Y) reichen mit der ClusterID in Kombination als Schlüssel nicht aus, da derselbe Cluster eventuell an den gleichen Ort zurückkehren kann). Abb. 4.5: Relationship-Typen zwischen dem Entity-Typen Cluster, Trajektorie und Massenpunkt. Als eine der komplexeren Monitoringkomponenten soll die Kollisionserkennung die Wahrscheinlichkeitsprognosen für bevorstehende Kollisionen berechnen und außerdem umfasst es die Aufgabe der Feststellung einer stattgefundenen Kollision und Spaltung. Beide Sachverhalte stellen 34 Endlich, da wir in diskreten Zeitschritten die Massenpunkte erfassen. Bei der Zeichnung einer durchgängigen Flugbahn ergibt sich indirekt durch Interpolation der Zwischenwerte durchaus eine unendliche Menge von Massenpunkten (dies entspricht der Erfassung der Massenpunkte in unendlich kleinen Zeitintervallen), die die kontinuierliche Bewegung eines Objekts aus diskreten Werten abbilden. 73

80 disjunkte Untertypen von Ereignissen dar (jedoch keine vollständige, da Ereignis als ein abstrakter Begriff viele Arten von Veränderungen umfasst). Ein Kollisionereignis lässt sich zudem in partielle und totale Kollision unterteilen. Eine partielle Kollision liegt vor, wenn die beiden beteiligten Cluster 35 nach dem Ereignis eigenständig vorliegen bzw. keine vollständige Verschmelzung erfolgt ist. Dagegen findet bei einer totalen Kollision eine Vereinigung zu einer einzigen Zusammenhangskomponente statt. Bei einem Kollisions- oder Spaltungsereignis können mehr als zwei Cluster beteiligt sein, jedoch ist es einfacher, ein solches Ereignis jeweils auf zwei Beteiligte durch ClusterIDs (paarweise) zu adressieren. Im Falle einer drohenden Kollision (vgl. Abb. 4.6; Relationship-Typ: kann_kollidieren_- mit) ist es wichtig, für jeden Beteiligten auf Grundlage der jeweiligen räumlichen Position, die verbleibende Entfernung, aber auch die kurzfristigen Änderungen in der Annäherungstendenz durch Veränderung der Flugrichtung von Clustern abzuschätzen. Durch Modellierung des Attributs Gefahrenbereich lässt sich die Informationsausgabe (Wahrscheinlichkeit einer stattfindbaren Kollision zwischen zwei Clustern bzw. Objekten) auf kritische Objekte in mehreren Stufen begrenzen. Theoretisch kann man den Gefahrenbereich den einzelnen Clustern zuordnen (durch unterschiedlich skalierte bounding boxes um den Cluster), aber wenn ein Cluster in den Gefahrenbereich eines anderen Clusters eindringt, geschieht dies auch umgekehrt (auf Gegenseitigkeit beruhend). Deswegen ist es ratsam, dem Relationship-Typ (kann_kollidieren_mit) das Attribut Gefahrenbereich einzuordnen (Abb. 4.6). Eine Spaltung nimmt ihren Ausgang von einem einzelnen Cluster, welches aber dann in mindestens zwei Teile (Clustern) zerfällt. Diese Ereigniserkennung stellt nur eine erfolgte Spaltung fest, besitzt jedoch keine vorausschauende Funktionalität. Abb. 4.6: Beziehungstyp zwischen zwei Cluster-Entity-Typen im Rahmen einer bevorstehenden Kollision bzw. Spaltung; Zerlegung des Ereignis-Entity-Typs in die Untertypen Kollision und Spaltung. 35 Die Cluster lassen sich für die Kollisionserkennung als räumlich unabhängige Objekte interpretieren. 74

81 In diesem Abschnitt wurde die Modellierung der Sachverhalte, noch auf das theoretische Anwendungsgebiet bezugnehmend, abstrakt gehalten. Die implementierungspezifischen Überlegungen werden im kommenden Abschnitt eingeführt, wobei sich dabei allgemeine Umbennungen, Änderungen in der Attributstruktur oder auch Einführung von neuen Relationen nicht vermeiden lassen. Es können auch nur die wichtigsten relationalen Schemata angegeben werden, jedoch nicht die Tabellen, die temporäre Daten für die Algorithmik aufnehmen. 4.3 Relationales Schema Im letzten Abschnitt haben wir die Objekte und deren Beziehungen untereinander aus dem Anwendungsgebiet durch die zwei Strukturierungskonzepte Entity-Typ und Relationship-Typ modelliert. Es gilt diese nun in das Strukturierungskonzept des relationalen Modells die Relation zu überführen. Wir beginnen wieder mit der Simulatorkomponente (vgl. Abb. 4.1), also mit der Umsetzung der Entity- und Relationship-Typen von GoL in Relationen. Abb. 4.7: Tabelle FormGleiter Abb. 4.8: Tabelle RelevanteZellenMitAnzahlLNB Eine Instanz vom zellulären Automaten ist GoL selbst, welche wir nicht explizit durch eine Relation in der Datenbank umsetzen müssen. Vielmehr ist es notwendig, jeden Zustand des Automaten in der Datenbank abzubilden, welcher dann den Ausgangszustand für den nächstfolgenden Zustand bildet. Die erste Idee wäre die Gesamtheit der Zellzustände sowohl tot als auch lebend für die Darstellung des Automatenzustands zu verwenden (Relationship-Typ: definiert_durch). Diese Umsetzung wäre erheblich speicherlastig und beansprucht beim Zustandsübergang für Änderungsoperationen viel Zeit. Eine effizientere Lösung stellt die Repräsentation des aktuellen Automatenzustands nur durch Zellen dar, die den Zustand lebend angenommen haben. So lässt sich zum Beispiel ein vordefinierter Startzustand für das Muster Südost-Gleiter durch die Tabelle FormGleiter mit 5 Zeilen, die die 5 lebenden Zellen des Gleiters repräsentieren, exemplarisch darstellen (vgl. Abb. 4.7). Würde man versuchen, auch die toten Zellen bei der Beschreibung der Konfiguration mit einzubeziehen, so sind bei einer Zellraumgröße von (wie im Fall des modellierten Simulators) insgesamt 2400 Datensätze notwendig im Vergleich dazu nur 5 Datensätze in der vorgestellten Form. Ebenso wird eine zusätzliche Spalte zur Unterscheidung zwischen den zwei annehmbaren Zuständen in der ineffizienten Umsetzungsform notwendig. Zx und Zy sind 75

82 äquivalent zu den beiden Koordinatenachsen (X, Y) und adressieren jede lebende Zelle eindeutig, da die beiden Spalten in Kombination einen Schlüssel bilden (Redundante Darstellung der Zellen werden dadurch ausgeschlossen). Da der Zellraum des Automaten begrenzt ist, gelten für die jeweiligen Spalten folgende Integritätsbedingung: {0 [Zx] < 60} bzw. {0 [Zy] < 40}, welche auch für andere Tabellen, die Zellen beinhalten, gültig sind. Analog zum Startzustand lässt sich jeder Zustand des Simulators gemeinsam durch die Spalten Zx und Zy beschreiben. Wir werden jedoch hierfür keine eigenständige Relation einsetzen, sondern im Rahmen von Clustering in die Tabelle Cluster integrieren, wofür wir die Gründe später betrachten werden. In der Tabelle Cluster (Abb. 4.9) wird auch die Zeit, in der ein bestimmter Simulatorzustand vorliegt, eingebunden. Bei der Berechnung des nächsten Zustands sind die toten Zellen jedoch nicht unwesentlich. Es müssen alle Zellen (sowohl tote als auch lebende) einbezogen werden, die im Rahmen des Relationship-Typs benachbart_zu an einer lebenden Zelle angrenzen. Diese Zellen werden als relevant bezeichnet und werden in der Tabelle RelevanteZellenMitAnzahlLNB abgelegt (vgl. Abb. 4.8). Für jede relevante Zelle wird die Anzahl der lebenden Zellen, an denen sie angrenzen, der Spalte AnzahlLNB zugeordnet, wobei es gilt: {1 [AnzahlLNB] 8}. Infolgedessen werden nur die Zellen in die Tabelle aufgenommen, die mindestens eine lebende Zelle als Nachbar besitzen. Dies gilt uneingeschränkt auch für eine gegenwärtig isoliert lebende Zelle, welche nicht in die Tabelle aufgenommen wird. Diese Zelle ist für die Übergangsberechnung insofern irrelevant, dass sie in der nächsten Generation den Zustand tot annimmt. Laut der Moore-Nachbarschaftsdefinition (vgl. Kapitel 2.3) kann eine Zelle maximal 8 Nachbarn besitzen und dementsprechend auch die Anzahl an lebenden Nachbarn. Abb. 4.9: Tabelle Cluster. Aufbauend auf diesen Tabellen (Cluster und RelevanteZellenMitAnzahlLNB) kann auch das Evolution-Monitoring bewerkstelligt werden. Mittels Views lassen sich die künftigen Geburtskandidaten und Todeskandidaten (vgl. Abb. 4.2) aus der Tabelle Cluster herleiten. Die Tabelle Cluster kann für den Blick in die Zukunft verwendet werden, da es den gegenwärtigen Zustand beschreibt, während die Tabelle RelevanteZellenMitAnzahlLNB als eine Rechtfertigung des aktuellen Zustands, in der Vergangenheit liegt. Sie kann zur Bestimmung der aktuell vorliegenden neugeborenen Zellen anhand eines Views genutzt werden. Alle drei Views 36 besitzen Spalten (Zx, Zy) zur Identifizierung der jeweiligen Zellen. 36 Die Implementierungsdetails zu Views werden im Kapitel 6 vorgestellt. 76

83 Beim Übergang von der letzten in die aktuelle Generation werden gestorbene Zellen durch eine gleichnamige Tabelle repräsentiert. Die Vorhersage über die möglichen Todeskandidaten, die durch dem entsprechenden View in der letzten Generation vorlag, wird zeitgleich in die Tabelle GestorbeneZellen (Zx, Zy) abgelegt, der Datensätze dann in der aktuellen Generation als gestorbene Zellen gelten. Überlebte Zellen müssen nicht explizit modelliert werden, denn diese werden durch die bereits durchgeführten Abgrenzungen in die vier erwähnten Zell-Untertypen aus der Menge der aktuell lebenden Zellen sichtbar und liegen in der Tabelle Cluster 37 vor. Im Kontext der Gesamtsimulationszeit verbleibt noch die Unterscheidung zwischen aktiven und inaktiven Zellen im relationalen Schema. Zellen, die über den gesamten Simulationszeitraum hinweg mindestens einmal ihren Zustand geändert haben, werden in die Tabelle AktivierteZellen (Zx, Zy) eingefügt. Weitergehend werden die Zellen, die in der Tabelle Cluster aktuell vorliegen, aber nicht in der Tabelle AktivierteZellen existieren, nachträglich eingefügt, da genau diese Zellen zum ersten Mal innerhalb des Simulationsverlaufs den Zustand lebend angenommen haben. Die inaktiven Zellen ergeben sich aus der Differenz zwischen der Gesamt-Zellmasse des Zellraums und den aktiven Zellen, welche im zu implementierenden System nicht explizit modelliert werden sollen. Wir haben vorhin die lebenden Zellen in Form von (Zx, Zy) innerhalb der Cluster-Tabelle integriert. Beim Clustering wird jede lebende Zelle, die den Zustand des Simulators zum Zeitpunkt t beschreibt, einem bestimmten Cluster zugeordnet. Ein Cluster stellt also eine Agglomeration von (zusammenhängenden) lebenden Zellen dar, welche zu den verschiedenen Zeitpunkten durch verschiedene lebende Zellen repräsentiert werden (ausgenommen sind Cluster stabiler Strukturen). Cluster stellt die Basistabelle in der Datenbank dar, die außer Zx und Zy die Spalte T zur Darstellung der gegenwärtigen Simulationszeit und CID (Synonym für ClusterID des Entity-Typs Cluster), welches über die aktuell vorliegenden Cluster und der zugehörigen Zellen Auskunft gibt, enthält (vgl. Abb. 4.9). Die Tabelle Cluster besitzt außerdem die Spalte ACID (alte ClusterID), die die Zugehörigkeit der einzelnen Zellen zu dem Cluster im Zeitpunkt t 1 wiedergibt. Dies ist im Rahmen der Clustering-Verfahren zur einheitlicheren Fortführung der ClusterIDs für eine bestimmte Zellmasse (lebende Zellen) über die einzelnen Zeitschritte hinweg von erheblicher Bedeutung (Für Details sei auf Kapitel 6 verwiesen). Die Clusterverband-Funktionalität stellt die letzte Berechnungsebene bei der Gruppierung von lebenden Zellen dar und hat innerhalb des Monitoringsystems eher einen visualisierenden Charakter. Entsprechend wird die Tabelle Clusterverband für diesen Zweck modelliert, d.h. es stellt den Ausmaß des zu visualisierenden Rechtecks dar, welches eine bestimmte Zahl von Clustern beinhaltet. Jedes Rechteck bzw. jeder Clusterverband bekommt einen Identifikationswert CVID zugewiesen und außerdem zwei Koordinaten (links-obere: (X1, Y1) und rechts-untere: (X2, Y2)) zum räumlichen Aufspannen des Rechtecks (vgl. Abb. 4.10). Trotzdem ist die Zuordnung der einzelnen Cluster zu einem Clusterverband durch den View ClusterVerbandUndCluster (CVID, CID) in der Datenbank für den Benutzer sichergestellt. Dabei basiert der View auf der Tabelle ClusterVerband und dem View ClusterAusmaß (CID, X1, Y1, X2, Y2, MPx, MPy). Der View ClusterAusmaß bestimmt das kleinstmögliche bounding box -Rechteck für ein Cluster: (X1,Y1) und (X2, Y2) sind die 37 Zwar liegen die überlebten Zellen gemischt mit neugeborenen Zellen in der Tabelle vor, sind aber bei der Visualisierung eindeutig unterscheidbar (da diese Zellen als einzige bei der Auswahl der vier Optionen unmarkiert sind). 77

84 zwei Raumkoordinaten, die zusammen eine Diagonallinie bilden, ähnlich wie beim Clusterverband, zum Definieren des Rechtecks, wobei (MPx, MPy) dessen Mittelpunkt darstellt. Abb. 4.10: Tabelle Clusterverband Abb. 4.11: Tabelle Trajektorie Bei dem Mustererkennungsprozess ist es von Bedeutung, in vorliegenden Daten bekannte Muster anhand eines Merkmals zu erkennen (siehe Abb. 4.4), d.h. mittels Sichten (Views) aus der Tabelle Cluster exemplarisch die Muster Blinker, Fisch, Gleiter und Quad vorzufinden bzw. zu prüfen, ob alle zugehörigen Zellen, die ein bestimmtes Muster ausmachen, als lebende Zellen vorliegen. Die Sichten müssen alle Untertypen der genannten Muster erkennen und ebenso deren Erscheinungsanzahl in dem gegebenen Zustand. Die Sichten weisen allgemein die Form ErkenneMuster (CID, Zx, Zy) auf: Der Koordinatenpunkt (Zx, Zy) liefert für jedes Exemplar des jeweiligen Musters den Anvisierungspunkt und CID gibt den Cluster wieder, in dem die Anvisierungszelle sich befindet. Es ist wichtig zu verstehen, wieso man ein solches Ausgabeformat verwendet: Die Anzahl der abgeleiteten Datensätze gibt die Anzahl der gefundenen Exemplare wieder (für Protokollierung von Bedeutung). Der Anvisierungspunkt (Zx, Zy) wird später für die Visualisierung gebraucht, um alle die zu visualisierenden, musterbildenden Zellen zu finden. Falls jedoch das Muster aus einem Cluster besteht, kann hierbei einfachheitshalber der CID-Wert benutzt werden 38. Das Muster Fisch hat zum Beispiel vier Zwischenformen bzw. Untertypen, wobei zwei aus einem einzigen Cluster und die anderen zwei aus zwei Clustern bestehen. Dementsprechend sind vier View-Varianten erforderlich. Für die Erfassung der Mustergruppe Stilleben wird eine Tabelle Historie (CID, Zx, Zy) benötigt, um die lebenden Zellen der letzten Generation vorliegen zu haben. Aus dieser Tabelle und der Tabelle Cluster (wo die aktuell lebende Zellen aufgeführt sind) wird mittels des Views StillebendeCluster (CID) die Stabilität der lebenden Zellen einzelner Cluster untersucht und falls positiv, wird der CID-Wert als Ergebnis geliefert. Die Stabilitätsermittlung mag auf dem ersten Blick einfach sein, aber seine Natur weist durchaus eine gewisse Komplexität auf, die wir uns im Kapitel 6 näher ansehen werden. Dagegen ist die Modellierung von Trajektorien weniger aufwendig: Eine Trajektorie ist eine zeitliche Verkettung der vorliegenden Massenpunkte des jeweiligen Clusters (vgl. Abb. 4.5). Infolgedessen können die Massenpunkte im Rahmen der is_part_of-beziehung in die Tabelle Trajektorie (CID, Zx, Zy, T) aufgenommen werden (siehe Abb. 4.11). Die Massenpunkte werden durch CID exakt zu einem Cluster zugeordnet und ebenso mit dem Attribut T zeitlich eingebunden. 38 Hier würde die Frage aufkommen, wieso es nicht möglich ist, parallel zum Auffinden eines Musters auch die zu visualisierenden Zellen liefern zu lassen oder bei einem Muster mit mehreren Clustern dessen CID- Werte auszugeben. Dies ist zwar möglich, aber die Anzahl der aufgetauchten Exemplare aus der abgeleiteten Tabelle zu bestimmen, ist dann wiederrum schwieriger. 78

85 Abb. 4.12: Tabelle Kollision Wir kommen nun zum logischen Entwurf der Kollisionserkennung. Ein bevorstehendes Kollisionsereignis lässt sich jeweils auf zwei beteiligte Cluster reduzieren, d.h. wenn ein Cluster_A bzw. CA (repräsentiert durch den CID-Wert des Clusters) mit drei weiteren Cluster_B (CB) in der Beziehung kann_kollidieren_mit steht, kann dieses durch drei Einträge in der Tabelle Kollision abgebildet werden (Abb. 4.12). Die Spalte Gefahrenbereich modelliert anhand von drei unterschiedlich großen bounding boxes (die skalierten Versionen von dem Cluster umhüllenden, kleinst-passenden Rechteck) den gegenseitigen Eintritt der Kollisionskandidaten in die Bereiche fern, mittel und nah. Die Spalte Entfernung stellt die momentan verbleibende Entfernung in Zelleinheiten (Größe eines Zellquadrats) zwischen den zwei potentiellen Kollisionskandidaten bzw. Clustern dar. Um eine Tendenz (dargestellt durch die Spalte Status) zwischen den Kollisionskandidaten (Cluster A und Cluster B) zu berechnen, muss die alte Entfernung verfügbar sein. Dies liegt in der Spalte AEntfernung vor, welche die Entfernung vom Zeitpunkt t 1 zwischen derselben Cluster darstellt. Die Spalte Status stellt letztendlich die Entfernungsveränderung zwischen dem Zeitpunkt t (Gegenwart) und t 1 dar. Wenn die Entfernung zum Zeitpunkt t abgenommen hat, so gilt für die beiden Objekte der Status Zubewegend, wenn aber die Entfernungsmessung zu beiden Zeitpunkten den gleichen Abstand ermittelt hat, so gilt der Status Stabil, und der letzte Fall Wegbewegend tritt auf, falls die Entfernung über die Zeit zugenommen hat. Um eine präzisere Kollisionswahrscheinlichkeitsprognose zu ermöglichen, wird der Status für zwei weitere Zeitschritte jeweils in den Spalten LStatus (letzter Status)und VLStatus (vorletzter Status) archiviert, d.h. der Tendenz-Wert wird in den nachfolgenden Zeitschritten, entsprechend der Namensvergabe der Spalten verlagert. Die drei Statuswerte dienen, gewichtet nach Aktualität, der Anpassung des anfangs berechneten (erste Stufe der Wahrscheinlichkeitsberechnung) Wahrscheinlichkeitswerts, welcher sich nur auf die Entfernung bezogen hat. Die letztendlich prognostizierte Kollisionswahrscheinlichkeit lässt sich in der Spalte Ws wiederfinden. Abb. 4.13: Tabelle ParameterKollision Zur Berechnung der Flugrichtung eines Clusters sind ebenso Daten aus zwei Zeitperioden notwendig: Es wird die letzte und aktuelle Position des Clusters (Mittelpunkt) benötigt, dargestellt jeweils durch die Spalten (AMPx, AMPy) für den alten Mittelpunkt bzw. (MPx, MPy) für den jetzigen Mittelpunkt (Abb. 4.13). Durch Vergleiche der Werte zwischen den entsprechenden Koordinatenachsen lassen sich im zweidimensionalen Raum (vgl. Kapitel 6) acht Flugrichtungen (Nordwest, Nord, Nordost, Ost, Südost, Süd, Südwest, West) ermitteln und zusätzlich Stationär, wenn keine 79

86 Bewegung erfolgt ist. Die Mittelpunkte selbst können durch die Durchschnittsbildung (Aggregatfunktion AVG) der im jeweiligen Cluster enthaltenen lebenden Zellen aus der Tabelle Cluster gebildet werden. Abb. 4.14: Tabelle LogKollisionUndSpaltung. Interpretationsweise: Cluster 4 mit Cluster 1 total kollidiert in T = 6; Cluster 5 vom Cluster 2 abgespalten. Das Ereignis Kollision nachträglich zu erfassen ist nicht trivial: Sowohl die Tabelle Cluster als auch die Tabelle Kollision führt nur die Cluster (CID) auf, die gegenwärtig noch existieren. Bei einer totalen Kollision, bei dem ein Cluster vollständig durch einen anderen Cluster verschlungen wurde, muss die Existenz der nicht mehr vorhandenen Cluster nachträglich für den Zeitpunkt t 1 nachgewiesen und eindeutig die Ursache für das Verschwinden durch Fremdverschuldung festgestellt werden. Die Beweise liefern die Tabelle Trajektorie und die Spalte ACID in der Tabelle Cluster (Zugehörigkeit der lebenden Zellen zum ehemaligen Cluster). Infolgedessen basiert der ereignis-erkennende View KollisionUndSpaltungEreignis (CA, CB, Ereignisart) auf diese zwei Tabellen. Es erkennt sowohl die beiden Kollisionsarten (total und partiell) als auch die vorliegende Spaltung eines Clusters in mehrere Teile. Analoge Beweisführung wie im Fall der totalen Kollision ist für die anderen zwei Ereignisse (partielle Kollision und Spaltung) erforderlich, auf die wir im Kapitel 6 näher eingehen werden. Die erkannten Ereignisse werden mit Angabe von Zeit in die Tabelle LogKollisionUndSpaltung (CA, CB, Ereignisart, T) abgelegt (Abb. 4.14). Im Folgenden seien die in der Datenbank MONALISA-DB enthaltenen Tabellen und Sichten aufgeführt. Einige wichtige wurden schon vorgestellt und andere wiederum dienen zur Zwischenberechnung und Protokollierung. Tabellen: 80 1) AbbauTabCluster (Zx, Zy) 2) AbbauTabClusterVerband (CVID, X1, Y1, X2, Y2) 3) AktivierteZellen (Zx, Zy) 4) CIDKorrektur (TempCID, ACID, ÜberlebendenAnzahl, ThCID) 5) Cluster (CID, Zx, Zy, T, ACID) 6) ClusterVerband (CVID, X1, Y1, X2, Y2) 7) Form (Zx, Zy) //Insgesamt 54 verschiedene Form-Tabellen 8) GestorbeneZellen (Zx, Zy) 9) Historie (CID, Zx, Zy) 10) InkonsistenteCID (TempCID, ÜberlebendenAnzahl, ACID, ThCID) 11) Kollision (CA, CB, Gefahrenbereich, Entfernung, AEntfernung, Status, LStatus, VLStatus, Ws) 12) LogCluster (CID, ErsteErscheinung, Status) 13) LogKollisionsWS (CA, CB, T, Entfernung, WS)

87 14) LogKollisionUndSpaltung (CA, CB, Ereignisart, T) 15) LogMuster (Muster, Anzahl, T) 16) ParameterKollision (CID, MPx, MPy, AMPx, AMPy, Richtung) 17) RelevanteZellenMitAnzahlLNB (Zx, Zy, AnzahlLNB, AssozierteCID) 18) TempKollision (CA, CB, Gefahrenbereich, Entfernung) 19) TempParameterKollision (CID, MPx, MPy) 20) TempTabCluster (Zx, Zy, Bearbeitet) 21) TempTabClusterVerband (CVID, X1, Y1, X2, Y2, Bearbeitet) 22) TempTabErlöschungszeitpunkt (CID, Status) 23) Trajektorie (CID, Zx, Zy, T) Views: 1) AnzahlIDVorkommenInTabTrajektorie (CID, Anzahl) 2) AutoTrajektorie (CID) 3) AutoTrajektorie2 (CID) 4) BoundingBox (Breite, Höhe, MinX, MinY, CID) 5) ClusterAusmaß (CID, X1, Y1, X2, Y2, MPx, MPy) 6) ClusterVerbandUndCLuster (CVID, CID) 7) ErfasseInkonsistenteIDs (TempCID, ÜberlebendenAnzahl, ACID, ThCID) 8) ErkannteMusterUndAnzahl (Muster, Anzahl) 9) ErkenneBlinker (CID, Zx, Zy) 10) ErkenneGleiter (CID, Zx, Zy) 11) ErmitteleMittelpunkt (CID, MPx, MPy) 12) ErmitteleNachbarn (Zx, Zy) 13) ErmitteleTempThCID (TempCID, TempThCID) 14) ErmitteleUnikaleCID (CID, Zx, Zy) 15) ErsteZelle (IDx, IDy) 16) ErweiterteDetailsFürKollision (Cluster, Mittelpunkt, Flugrichtung, Information) 17) Fisch_ (CID, Zx, Zy) //4 Varianten 18) Geburtskandidaten (IDx, IDy) 19) Gleiter_ (CID, Zx, Zy) //16 Varianten 20) KollisionUndSpaltungEreignis (CA, CB, Ereignisart) 21) KollisionsWs (CA, CB, GefahrenBereich, Entfernung) 22) LZundNLZundCID (NLZx, NLZy, CID) 23) MinTempEindeutigeCID (TempCID, ThCID) 24) NeugeboreneZellen (Zx, Zy, AssozierteCID) 25) Quad_ (CID, Zx, Zy) // 2 Varianten 26) RelevanteZellenUndAnzahlLNB (Zx, Zy, AnzahlLNB) 27) RelevanteZellenUndAnzahlLNBMitCID (Zx, Zy, AnzahlLNB, CID) 28) SpaltungsErkennung (NeuEntstandeneCluster, UrsprungsCluster, UrsprungsClusterÜberlebt) 29) StillebendeCluster (CID) 30) TendenzAllerCluster (CA, CB, Tendenz) 81

88 82 31) TendenzAllerKollisionCluster (CA, CB, Tendenz) 32) Todeskandidaten (Zx, Zy, AnzahlLNB) 33) Überlebende (TempCID, ACID, ÜberlebendenAnzahl)

89 5 Architektur und Funktionalität Im letzten Kapitel wurde die Datenbank von MONALISA entworfen, die sowohl Faktenrelationen, als auch die Verarbeitungslogik in Form von Views beinhaltet hat. Wir werden nun die Datenbank im Abschnitt 5.1 an das Gesamtsystem anbinden und dabei die Architektur von MONALISA vorstellen. Im nachfolgenden Abschnitt 5.2 wird auf die Visualisierungskomponente des Systems näher eingegangen. Im Vordergrund stehen die Realisierung des GUIs und die bereitgestellten Funktionalitäten für den Simulator und die Monitoringkomponenten. 5.1 Architektur Die Architektur eines Softwaresystems beschreibt die einzelnen Komponenten, die eine Zerlegung des Gesamtsystems darstellen, und deren Zusammenwirken untereinander. Die im Rahmen der Diplomarbeit zu implementierende MONALISA-Applikation besteht aus vier Komponenten bzw. Modulen, die in der Abb. 5.1 dargestellt werden. Hierbei abstrahieren wir die Teilmenge der Verarbeitungslogik (die sekundären Prozesse, die eine steuerende Rolle haben, sind mittels Java zu verwirklichen), welche sich in der Datenbank befindet und ordnen sie den beiden Bestandteilen des Systems, Simulator und Monitor, zu. In der Architektur repräsentiert die Datenbank die Datenbasis, die einerseits die künstliche Realität zu jedem diskreten Zeitschritt abbildet, aber ebenso die ausgewerteten Monitoringergebnisse protokolliert. Der Simulator und der Monitor werden durch die JDBC-ODBC-Schnittstelle an die Datenbank angebunden, wobei als DBMS Microsoft Access 2007 eingesetzt wird. Abb. 5.1: Architektur von MONALISA. Die gestrichelten Pfeile stellen Benutzeraktionen dar, wohingegen die durchlinierten Pfeile den Datenfluss zwischen den Komponenten verdeutlichen. 83

90 Der Simulator ersetzt den Datenfluss der realen Welt und gibt die diskreten Zeitschritte vor. Die Überlegungen für die Wahl des zellulären Automaten Game of Life wurden bereits im Abschnitt 4.1 verdeutlicht. Die generierte Zustandsbeschreibung der künstlichen Realität, die die Ereignisse beinhaltet, dient als Inputdatenmenge für die Komponente Monitor. Theoretisch lassen sich die von dem Simulator stammenden Eingangsdaten unmittelbar an den Monitor zur Analyse weiterleiten. Eine direkte Kommunikation zwischen Simulator und Monitor ist jedoch hier nicht vorgesehen, vielmehr ist das zentrale Konzept Datenbank der Kommunikationsknotenpunkt. Dieser Schritt ist erwogen worden, um die wesentliche Programmlogik in SQL zu verwirklichen. Abb. 5.2: Lokale Architektur von Simulator Abb. 5.3: Subsysteme von Monitor Die Zustandsbeschreibung wird zu jedem diskreten Zeitpunkt t in der Datenbank aktualisiert, welche für den nächsten Zeitschritt als Inputdatenmenge für die Zustandsberechnung des Simulators selbst dient. Die Zustandsberechnung wird vorwiegend durch SQL durchgeführt (Abb. 5.2), jedoch wird zur Koordination der Bearbeitungsabfolge Java eingesetzt. Die für die Absetzung von SQL- Statements benötigte Datenbankverbindung wird durch das Connection-Objekt hergestellt, wobei hierzu die Java-Klassen java. sql. Connection und java. sql. DriverManager aus der Klassenbibliothek importiert werden. Für die Erstellung eines Statements und zur Entgegennahme der Ergebnisse von SQL-Statements werden außerdem die Klassen java. sql. Statement und java. sql. ResultSet benötigt. Die Konfiguration des Simulators wie die Startzustandsauswahl oder die Bestimmung der Simulationsgeschwindigkeit erfolgt über die in Java definierten Swingkomponenten, die dann als Event über SQL-Befehle an die Datenbank weitergeleitet werden. Eine klare Aufteilung bei der Verwirklichung der Subsysteme (innerhalb z.b. der Simulatorkomponenten) in den beiden Sprachen ist schwierig, da einerseits SQL-Befehle im Java-Code eingebettet und andererseits in SQL-Statements auch Java-Hostvariablen eingesetzt werden. 84

91 Der Monitor (Abb. 5.3) führt seine fünf Aufgaben (Clustering, Evolution, Trajektorie, Kollisionsund Mustererkennung) auf Grundlage der in der Datenbank vorliegenden Input- bzw. Protokolldaten vom Simulator durch, welche zu Analysezwecken über die JDBC-Schnittstelle zur Monitorkomponente transferiert werden. Nach Abschluss der Untersuchung werden die Ergebnisse in die Datenbank ablegt und für eine begrenzte Zeitperiode archiviert. Die fünf Monitoring- Teilkomponenten, die zur Entdeckung konkreter Ereignisse bzw. zur Ableitung zusätzlicher Erkenntnisse dienen, können parallel eingesetzt werden, wobei Clustering für den Einsatz von Trajektorienbestimmung, Kollisions- und Mustererkennung vorausgesetzt werden. Das Evolution- Monitoring kann dagegen eigenständig betrieben werden. Bei Monitoringkomponenten müssen Situationen berücksichtigt werden, bei denen nicht genug Ausgangsdaten für eine eindeutige und erfolgreiche Durchführung der Analyse vorliegen, wobei diese nicht als Fehler zu deklarieren sind, sondern vielmehr solche Fälle abgefangen werden müssen. Zum Beispiel werden bei der Berechnung der Flugrichtung eines Objekts mindestens zwei Positionsangaben benötigt und solange diese nicht existieren, sei es durch die kurzfristige Erscheinung des Objekts oder unter Umständen auftretende Synchronisierungsfehler mehrerer Datenbankverbindungen kann keine eindeutige Bewegungsrichtung festgestellt werden, und in diesem Fall muss als Flugrichtung Unbekannt angegeben werden. Alle Analyseinstrumente der Monitoringkomponenten werden hauptsächlich mit Hilfe von SQL konstruiert, wobei schwerumsetzbare Konzepte (z.b. die Berechnung einer Bézierkurve oder einer gleitenden Durchschnittslinie) auf Java verlagert werden. Im Fall von Bézierkurven stellt die Java- Klassenbibliothek (java. sql. geom) selbst Möglichkeiten bereit, diese zu zeichnen. Die Ablaufsteuerung im Rahmen eines Threads verbleibt auch in der Java-Sprache, ebenso wie die Feinjustierung der Monitoring-Tools über Swing-Komponenten. Wie zwischen den beiden Komponenten Simulator und Monitor, so ist auch ein Informationsaustausch zwischen Subsystemen des Monitors nur über die Datenbank vorgesehen. Dies erlaubt dem Benutzer auch ohne das GUI auf die Auswertungsergebnisse über Tabellen oder den abgeleiteten Sichten in der Datenbank zuzugreifen (dies gilt ebenso für die Daten vom Simulator). Zu berücksichtigen ist jedoch die Effizienzproblematik durch die regelmäßigen bidirektionalen Informationstransfers über die JDBC-ODBC- Brücke, welcher durch verfügbare Methoden entgegengesteuert werden muss. Eine bereits vorgestellte Methode (im Abschnitt 3.3.1) stellt die gebündelte Ausführung der SQL-Statements durch addbatc() und executebatc() dar, außerdem lässt sich durch regelmäßiges Komprimieren der Datenbank und mittels eines exklusiven Zugriffsrecht auf die Datenbank die Leistung weiter optimieren [Mic08b]. Das GUI (Graphical User Interface) stellt die Visualisierungskomponente des Systems dar, welches den künstlichen Systemzustand und die ausgewerteten Monitoringergebnisse in Echtzeit veranschaulicht. Es stellt die notwendigen Schnittstellen zum Konfigurieren des Simulators bereit und bietet erweiterte Einstellungsmöglichkeiten für die durchzuführenden Monitoringaufgaben. Im Abschnitt 5.2 erfolgt eine detaillierte Beschreibung der angebotenen Funktionalitäten für die einzelnen Monitoringbereiche und ebenso der verwendeten Swingkomponenten. Das GUI erlaubt zugleich dem Benutzer, Zugriff auf die Log-Daten der Bereiche Clustering, Kollisions- und Mustererkennung. Abb. 5.1 veranschaulicht im Abstrakten auch das Einsatzgebiet der beiden im Kapitel 3 vorgestellten Technologien, die zur Anwendung kommen werden. Die Visualisierungskomponente wird durch die Java-Klasse GUI.java definiert und das Gerüst für die hauptsächlich in SQL vorlie- 85

92 gende Verarbeitungslogik stellt die Klasse SimMon.java dar. Beide Klassen gehören dem package monalisa an. 5.2 Funktionalitäten und GUI Das GUI erlaubt den Benutzern, Interaktionen mit dem System durchzuführen, indem es Schnittstellen für den Simulator und die Monitoringkomponenten bereitstellt. Es bildet den Zustand der derzeitigen künstlichen Realität ab und visualisiert parallel dazu die Ergebnisse der durchgeführten Monitoringaufgaben. Die grafische Zeichnung erfolgt auf einer AWT-Komponente java. awt. Canvas, die durch die zu überschreibende paint()-methode beliebige grafische Ausgaben ermöglicht. Bei der Umsetzung des GUIs, welches in Form eines Applets vorliegt, wurde darauf geachtet, dass die wichtigsten Informationen adäquat dargestellt werden, indem es in einem für den Benutzer in der Kürze der Zeit erfassbaren Format die relevanten Daten präsentiert. Dabei darf der Benutzer nicht mit der Informationsaufnahme überfordert werden, so dass dies es erforderlich macht, hauptsächlich mit visuellen Mitteln statt textuellem Format zu arbeiten, welches von dem Benutzer eindeutig einem Sachverhalt zugeordnet werden kann (z.b. eine Kollision durch Aufblinken verdeutlichen). Bei Bedarf kann der Benutzer eine detaillierte Version der Ereignisse anfordern, welche dann in Form einer Tabelle geliefert wird. Auf den Grundlagen der Softwareergonomie wurde bei der Verwirklichung der Konfigurationsschnittstellen auf die Selbstbeschreibungsfähigkeit wert gelegt, und es wurden ebenso einheitliche Swing-Komponenten verwendet. Das Applet ist so eingestellt, dass seine Bedienkomponenten sich an dem nativen Betriebssystem anpassen (mittels getsystemlookandfeelclassname() Methode der Klasse UIManager), um dem Benutzer einen schnelleren Einstieg (durch Vertrautheit der Bedienelemente) zu ermöglichen. Die einzelnen Schnittstellen sind nach Aufgabenfeldern gruppiert, und ebenso erfolgt eine klare Trennung zwischen den Simulator- und Monitoringbedienelementen. Die Anordnung der Swingkomponenten erfolgt über die verschiedenen, hier eingesetzten Layout-Manager wie Border-, Flow-, Grid- und GridBagLayout. (Diese sind von java. awt zu importieren; für Details sei auf [Ull08] verwiesen). Wenn eine Funktionalität die andere voraussetzt, wird diese für den Benutzer erst dann verfügbar, falls sie gegeben ist. Voraussetzende Funktionalitäten werden nacheinander freigegeben, so dass sich für den Benutzer selbst eine Bedienungsanleitung ergibt. Einander ausschließende Monitoringfunktionalitäten (sei es aus logischer Sicht oder wenn eine Funktionalität eine bestimmte vordefinierte Einstellung erwartet) werden auch entsprechend wie oben behandelt. Beim Programmstart sind nur die Schnittstellen des Simulators aktiviert und außerdem sind noch die einleitende Monitoringkomponente Clustering und das vom Clustering unabhängige Evolution- Monitoring freigegeben(abb. 5.4). 86

93 Abb. 5.4: GUI des MONALISA-Systems beim Programmstart. Applet liegt im Vista-Look and Feel Design vor. 87

94 Abb. 5.5: Kontrollfeld für Simulator Der verwendete Simulator zellulärer Automat GoL wird durch die zweidimensionale große Matrix dargestellt, welche insgesamt 2400 Zellen enthält, wobei alle beim Start (t = 0) den Zustand tot besitzen (dargestellt durch graue Farbe). Mittels Wähle Muster im Simulator- Kontrollfeld lässt sich unter 54 verschiedenen Startzuständen auswählen, deren Struktur dann unmittelbar durch lebende in gelb dargestellte Zellen visualisiert wird. Wähle Muster ist durch eine JComboBox realisiert (Abb. 5.5), die eine Kombination aus einem Textfeld und einer Liste darstellt. Dementsprechend ist sie außer durch die Maus auch per Tastatur innerhalb der Liste navigierbar. Alternativ zur Auswahl eines vordefinierten Startzustands, lässt sich per Maus (linke Taste) manuell eine eigene Startkonfiguration definieren. Zum Simulationsstart existieren zwei Möglichkeiten: Durch das JButton bzw. Funktionsschaltfläche Next hat der Benutzer die Möglichkeit, sich die nächsten Generationen manuell schrittweise zu berechnen. Mit dem Start -Button übergibt der Benutzer einem Thread den Lauf der Simulation, welcher erst durch betätigen des Stop -Buttons terminiert wird. Der Stop-Button ist dementsprechend nur dann verfügbar, wenn der Benutzer einen Simulationslauf durch das Start- Button eingeleitet hat. Durch den Reset -Button hat man die Möglichkeit, einen Simulationsverlauf abrupt zu beenden und den Simulator auf den Anfangszustand zurückzusetzen (alle Zellen auf den Standardzustand tot und Simulationszeit auf 0 stellen). Die Schnelligkeit des Generationswechsels bzw. die Abfolgegeschwindigkeit der Zeitschritte lässt sich mit der nachfolgenden JComboBox manipulieren und verfügt über die drei Abstufungen (Langsam, Mittel und Schnell), ferner stellt T den aktuellen Zeitschritt dar. Jede einzelne Funktionsschaltfläche erzeugt einen ActionEvent bei Betätigung (des Buttons, Checkbox oder ComboBox), welches an einen Zuhörer versendet wird. Der Zuhörer ist ein ActionListener (es handelt sich um eine erweiterte EventListener-Schnittstelle), welcher mittels der Methode addactionlistener() an die Bedienkomponente angeheftet wird. Es stellt auch eine Methode actionperformed() bereit, die bei Auslösung eines ActionEvents aufgerufen wird, wobei der ActionEvent als Argument dient. Mittels getactioncommand() wird der mit dem ActionEvent verbundene String gelesen (vorher durch setactioncommand() zugeordnet) und mit der innerhalb der actionperformed() liegenden Event-Liste verglichen, so dass im zutreffenden Fall die entsprechende, vordefinierte Aktion eingeleitet wird. Insgesamt wurden für die GUI-Realisierung die Klassenbibliotheken java. awt und javax. swing benötigt. Wir kommen zum Kontrollfeld von Monitoringaufgaben, wobei wir uns zunächst die Evolution-Bedienelemente ansehen werden (Abb. 5.6). Hier sind alle Bedienkomponenten jeweils durch die JCheckBox realisiert, welche durch Grid- und GridBag- Layout angeordnet wird. Checkboxen wer- Abb. 5.6: Schnittstelle für Evolution-Monitoring 88

95 den im Allgemeinen zur Auswahl von Optionen verwendet, wobei die gewählten Optionen durch Häkchen markiert sind. Bei Auswahl einer Checkbox werden die entsprechenden Methoden zur Berechnung des Sachverhalts aktiviert und die Ergebnisse werden zur Visualisierung in der paint() Methode berücksichtigt. Die Option AutoStopmodus ermöglicht die Erkennung einer zum Stillstand gekommenen Entwicklung der Population, in der keine Zustandsänderung mehr stattfindet. Wurde ein Stillstand erkannt, so wird der Simulator automatisch gestoppt, indem der laufende Thread mittels stop() angehalten wird und ein Neustart nur per Reset erfolgen kann. Abb. 5.7 Lebensraum des Musters Gleiterkanone zum Zeitpunkt T = 125 Abb.5.8: Gleiter in T=4 Die CheckBox Lebensraum erlaubt die Visualisierung des Ausbreitungsgebiets (dunkel grau dargestellt) einer Population bis zum derzeitigen Zeitpunkt (Abb. 5.7). Die Zeichnung erfolgt über einem Grapics2D-Objekt durch die Methode fillrect(), welche auf der angegebenen Koordinate ein Rechteck der vorgegeben Größe zeichnet. Zuvor gilt es, dem Objekt mittels setcolor() die gewünschte Farbe zuzuweisen. Die lebenden Zellen selbst werden durch die Methode fill3drect() abgebildet, die die Darstellung eines Rechtecks in 3D ermöglicht. Das Optionsfeld neugeborene Zellen erlaubt die Markierung (durch blaue Punkte mittels filloval()) von Zellen, die in der letzten Generation den Zustand tot hatten und beim Übergang in den aktuellen Zeitpunkt den Zustand lebend angenommen haben. Durch Auswahl von gestorbene Zellen lassen sich dagegen die Zellen durch schwarze Kreuze kennzeichnen, die in t 1 den Zustand lebend besaßen und gegenwärtig in t den Zustand tot besitzen. Aktuell lebende Zellen, die aber im nächsten Zeitschritt den Zustand tot annehmen werden, können mittels der Option Todeskandidaten durch rote X (über drawstring()) markiert werden. Die CheckBox Geburtskandidaten ermöglicht die Identifizierung von denjenigen gegenwärtig toten Zellen, die im kommenden Zeitschritt geboren werden, indem diese durch weiße Sterne kenntlich gemacht werden. In der Abb. 5.8 sind die vier zellbezogenen Optionen für den Gleiter eingestellt, wobei die unmarkierten Zellen die Überlebenden darstellen (sowohl in t 1 als auch in t haben diese Zellen den Zustand lebend ). 89

96 Die Basismonitoringkomponente Clustering (bzw. Cluster) erzeugt im eingeschalteten Modus (Aktivieren durch Button Einschalten ) mit Hilfe von drawrect() ein kleinstmögliches, umhüllendes, farbiges Rechteck um ein oder mehrere Zellen, die eine Zusammenhangskomponente bilden und somit ein Cluster. Die Rechtecke für Cluster werden in den drei Farbvarianten (in Abhängigkeit der IDs der Cluster) rot, blau oder schwarz dargestellt, um eine bessere Erkennung auf dem grauen Hintergrund zu ermöglichen. Die einzelnen Cluster werden einen CID-Wert an die erste Zelle (linksobere) abgebildet, welche zur eindeutigen Identifizierung und Nachverfolgung über die Zeit hinweg dient. Mit Hilfe der Option neue Cluster markieren (Abb. 5.9) lassen sich diejenigen Cluster, die neu aufgetaucht sind, für drei Zeitschritte durch α kennzeichnen (Abb. 5.10). Abb. 5.9: Cluster-Interface Abb. 5.10: Dargestellt sind die Cluster 1, 21, 34 und 35, wobei 21, 34 und 35 zu einem Clusterverband (cv4) zählen. Die Cluster können wiederrum zu Clusterverbänden agglomeriert werden, die innerhalb einer Distanzschranke liegen. Durch Wahl der Option Clusterverband wird ein Rechteck gezeichnet, das alle Cluster umfasst, die zum gekennzeichneten Clusterverband gehören. Die Clusterverbände bekommen auch einen ID-Wert, welcher nicht über die Zeit konstant sein muss. Bei Aktivierung der Clusterverband-Option wird auch die zugehörige JComboBox verfügbar, durch die man eine maximale Distanzschranke von 0 bis 20 Zelleinheiten (bzw. Abb. 5.11: Log-Daten über Clustering Zellgrößen) auswählen kann. Bei Auswahl von 0 werden diejenigen Cluster zu Clusterverbänden vereint, die sich gegenseitig mit ihrer bounding box berühren. In diesem Fall liegt keine Kollision vor, denn eine Überlappung der Rechtecke muss keine Verschmelzung implizieren, da die Zellen der beiden keine Zusammenhangskomponente bilden. Dies wird durch die Existenz von zwei unabhängigen Rechtecken verdeutlicht (Abb. 5.10). Das Clustering besitzt eine Log-Funktionalität, welche den ersten Erscheinungs- und Erlöschungszeitpunkt von Clustern festhält. Der Zugriff auf die Logdaten wird durch das JButton Anzeigen gewährt, welche dann in einem separaten Fenster angezeigt werden (Abb. 5.11). Die Protokolldaten lassen sich auch während der Simulations- 90

97 laufzeit betrachten, jedoch erhält man den Zugriff auf das Hauptfenster erst, wenn das Dialogfenster (JDialog) geschlossen wurde. Abb. 5.12: Beispiele der erkannten Muster. Die Mustererkennungs- (kurz Muster) Benutzerschnittstelle ermöglicht es auf Anforderung durch Auswahl der entsprechenden Checkboxen die Muster Blinker, Fisch, Gleiter, Quad und die Mustermenge Stilleben beim Auftreten zu erkennen. Die zu den Mustern gehörenden lebenden Zellen werden mit den vorgegebenen Farben (durch Kombination von setcolor() und fill3drect()) übermalt (Abb. 5.12). Beachte bei Muster Quad, dass die Cluster 4, 5, 6 und 7 zusammen dieses Muster bilden, analog gilt dies für Muster Fisch (Cluster 3 und 13). Beim Einschalten der Mustererkennung werden die Hintergründe der Checkbox-Komponenten durch die Methode setbackground() auf die äquivalenten Farben gesetzt (Abb. 5.13). Ferner erlaubt das JButton Anzeigen den Zugriff auf die Log-Daten der Mustererkennung, welche in tabellarischer Form aufbereitet sind. Es zeigt an, welche Muster in wievielen Exemplaren zu welchem Zeitpunkt erschienen sind. Abb. 5.13: Muster-Interface Abb. 5.14: Protokolldaten von Mustererkennung Die Schnittstelle Trajektorie bietet verschiedene Funktionalitäten mit unterschiedlichen Einstellungsmöglichkeiten (Abb. 5.15). Die Standardeinstellung sieht vor, dass die volle Trajektorie ausgewählt ist, welche für jeden Cluster eine Flugbahn, äquivalent zu seiner Bewegung, mittels drawpolyline() visualisiert. Die Flugbahn bzw. Trajektorie wird definiert durch die chronologisch aufgezeichneten Massenpunkte, die jeweils den linksoberen Punkt der bounding box darstellen. 91

98 Standardmäßig werden nur die Trajektorien von existierenden Clustern angezeigt. Bei dieser Einstellung ( Trajektorie nur von existierenden Clustern markiert) lassen sich aber die Massenpunkte der kurzlebigen Cluster (die nur in einem Zeitpunkt existieren) nicht anzeigen, da es der Logik widerspricht. Für die Darstellung solcher kurzlebigen Cluster (Abb. 5.17) muss die JCheckBox kurzlebige Cluster berücksichtigen aktiviert werden, die aber nur bei unmarkierten JCheckBox Trajektorie nur von existierenden Clustern zur Verfügung steht. Abb. 5.15: Trajektorie-Interface Abb. 5.16: Trajektorie von Fisch im T= 700. Die zackige ist die natürliche Trajektorie und die durchlinierte stellt den GDL mit AVG(x,y)-Einstellung dar. Bei volle Trajektorie, welche die natürliche Bewegung darstellt (Abb. 5.16), lässt sich für ältere Trajektoriedaten die Flugbahn weniger detailliert darstellen, welche aber dadurch dem Betrachter eine weniger exzentrische Flugbahndarstellung (besonders bei Wendungen) ermöglicht. Hier kommt die Glättung durch das Konzept der Bézierkurve zum Einsatz: Zu einer existierenden Flugbahn bzw. einem existierenden Pfad wird mittels GeneralPat. curveto() ein Kurvensegment bestehend aus drei Koordinatenpunkten hinzugefügt, wobei die ersten beiden Koordinaten Bézier-Kontrollpunkte darstellen und der dritte Koordinatenpunkt der Endpunkt ist. Durch iteratives Einfügen von Bézierkurvensegmenten entsteht so eine geglättete Trajektorie. Bei der Auswahl unbeschränkt in der JComboBox detaillierte Trajektorie bis zu T kommt dieses Glättungsverfahren nicht zum Einsatz, da man die Option offen lassen will, eine vollständig detaillierte Trajektorie für die Darstellung zur Verfügung zu haben. Stellt man diese dagegen auf eine der angebotenen Werte zwischen 10 und 100 ein (diese Intervallgröße schien für die Größe des hier realisierten Zellraums angemessen zu sein), so wird die Trajektorie ab demjenigen Teil geglättet, dessen Massenpunkte aus älterer Zeit stammen als dem angegebenen Wert. Zusätzlich kann man durch Detailstufe des älteren Trajektorieteils bestimmen, mit welcher Genauigkeit die geglättete Trajektorie angezeigt werden soll (Abb. 5.17): Es stehen hierbei fünf verschiedene Stufen bereit, wobei die Trajektorie umso geradliniger wird, je niedriger man die Stufe wählt. Dies beruht daher, dass weniger Massenpunkte (in Intervallen) als Zeichnungsgrundlage gewählt werden: Für sehr hoch wird jeder fünfte Massenpunkt (in der chronologischen Reihenfolge) gewählt, bei hoch jeder zehnte, mittel jeder fünfzehnte, niedrig jeder zwanzigste und bei sehr niedrig nur jeder fünfundzwanzigste. 92

99 Eine andere Funktionalität, die die Trajektorie-Komponente bereitstellt, ist die Darstellung der durchschnittlichen Bewegung eines Objekts im Zeitverlauf, auswählbar durch die JCheckBox gleitende Durchschnittslinie (GDL). Hier kann man zusätzlich bestimmen, auf welcher Koordinatenachse der gleitende Durchschnitt gebildet werden soll: Standardeinstellung bei Aktivierung ist AVG(x,y) (Abb. 5.16) (d.h. auf beiden Achsen); man kann aber auch auf die einzelnen Koordinatenachsen (AVG(x) oder AVG(y)) die Durchschnittsbildung durchführen. Bei der Wahl von gleitende Durchschnittslinie ist die vorhin erwähnte Glättungsoption ausgeschaltet. Denn für die Berechnung der Durchschnittslinie werden alle Massenpunkte des Clusters benötigt, welche aber im Fall der Glättung für die Berechnung nicht zur Verfügung stehen: Bei eingeschaltetem detaillierte Trajektorie bis zu T werden nur die benötigten Massenpunkte für die Visualisierung anhand der Stufeneinstellung ( Detailstufe des älteren Trajektorieteils ) aus der Datenbank gelesen. Abb. 5.17: Muster Fisch im T=150 mit folgender Einstellung: kurzlebige Cluster berücksichtigen dargestellt durch Punkte; detaillierte Trajektorie bis zu T auf 30 und Detailstufe des älteren Trajektorieteils auf niedrig. Eine bereits bei der Aktivierung von Clustering innerhalb der Trajektorie-Gruppe verfügbare Option ist ältere Trajektoriendaten löschen, dessen Standardeinstellung als nicht zulassen definiert ist. Selbst wenn die Trajektorie nicht eingeschaltet ist, werden Daten (Massenpunkte) in die Tabelle Trajektorie abgelegt, welche für das Clustering eine entscheidende Rolle spielt (im Kapitel 6 mehr dazu), aber auch damit, wenn die Trajektorie aktiviert wird, eine vollständige Flugbahn anzeigt werden kann. Die Option erlaubt Trajektoriendaten, die älter als 50 Zeiteinheiten sind, automatisch zu löschen, oder aber auch die Daten, die ein Alter von mehr als 100, 150, 200, 250 oder 300 Zeiteinheiten aufweisen. Die Standardeinstellung ist wohlbedacht auf nicht zulassen gesetzt worden, denn bei Löschung dieser Daten ist eine eindeutige Vergabe der Cluster-IDs auf längere zeitliche Sicht nicht mehr gewährleistet. Diese Option (zur Löschung der älteren Daten) ist aber trotzdem zur Verfügung gestellt worden, da das System bei längerem Einsatz durch anfallende Daten und deren Bearbeitung langsamer wird und so wird dem entgegengesteuert. 93

100 Wir kommen zur letzten Monitoring-Komponente, der Kollisionserkennung (kurz Kollision), deren Schnittstellen in der Abb dargestellt sind. Als Erstes lassen sich die Gefahrenbereiche wählen, anhand derer die Informationsausgabe für die Kollisionswahrscheinlichkeit eingegrenzt wird. In der Standardeinstellung sind alle Bereiche fern, mittel und nah gewählt, wobei diese auch auf die anzuzeigenden bounding boxes Einfluss haben. Hier ist mit bounding box nicht das Rechteck, welches die Zusammenhangskomponente umhüllt, gemeint, sondern die zur Erkennung bevorstehender Kollisionen verwendeten, größer skalierten Rechtecke (Abb. 5.19). Die Visualisierung der bounding boxes lässt sich durch den entsprechenden Button Einblenden bewerkstelligen, welche dann per drawrect() an den vorgegebenen Koordinaten in der definierten Größe gezeichnet werden. Die Rechtecke werden gestrichelt dargestellt: Dies lässt sich erzeugen, indem man die gewünschten Umrisseigenschaften durch setstroke(stroke) (wobei Stroke = new BasicStroke (float width, int cap, int join, float miterlimit, float[] dash, float dash_phase)) auf das Graphics2D-Objekt setzt. Selbst wenn die bounding box aktiviert ist, werden die Rechtecke nur dann gezeichnet, wenn die beiden Kollisionspartner sich aufeinander zubewegen, so dass die äußere bounding box des Einen mit der cluster box (durchliniertes Rechteck) des Anderen in Berührung kommt (Abb. 5.19). Abb. 5.18: Kollisions-Interface bei Standardeinstellung Abb. 5.19: Bounding box und Wahrscheinlichkeitsanzeige Über die JCheckBox Wahrscheinlichkeit anzeigen lässt sich die Visualisierung der Kollisionswahrscheinlichkeit ein- und ausblenden. Jedem Kollisionspaar wird eine Wahrscheinlichkeit zugeordnet (Abb. 5.19), dabei wird für eine schnellere Erfassung durch den Betrachter die Information bündig ausgegeben und ebenso wird der Grad der Kollisionswahrscheinlichkeit (Ws) farblich visualisiert (Ws 50% grün; 51% Ws 85% gelb; 86% Ws 100% rot). Bei aktivierter Checkbox Kollision und Spaltung visualisieren lassen sich gegenwärtig stattgefundene Kollisionsund Spaltungsereignisse visualisieren, wobei eine Kollision durch rote, diagonallinierte Schraffur und kurzes Aufblinken dargestellt wird und ein Spaltungsereignis durch blaue, vertikallinierte Schraffur (Abb. 5.20). Innerhalb der Standardeinstellung ist die automatische Einblendung der Trajektorie vorgesehen, wenn die Cluster untereinander einen kritischen Abstand unterschreiten, aber noch bevor die äußere bounding box des Einen den anderen Cluster berührt. Dies lässt sich auf Wunsch durch Deaktivierung der Option Trajektorie automatisch anzeigen unterbinden. 94

101 Abb. 5.19: Spaltungs- und Kollisionsereignis Abb. 5.20: Angreifer und Ziel im Interaktivmodus Eine der Hauptinteraktivitätsmöglichkeiten im Rahmen der Kollisionserkennung stellt die Wählbarkeit eines Angreifers und eines optionalen Ziels bei eingeschaltetem INTERAKTIVMODUS dar. Wenn nur der Angreifer gewählt wurde, werden Kollisionswahrscheinlichkeiten für alle potenziellen Ziele dieses Angreifers angezeigt, wobei der Angreifer selbst durch einen Pfeil symbolisiert wird. Wird zusätzlich ein Ziel gewählt (ein Angreifer muss davor gewählt werden, um ein Ziel wählen zu können), so wird dieses durch eine Zielscheibe gekennzeichnet. In diesem Fall wird eine Kollisionswahrscheinlichkeit nur für diese beiden Kollisionspartner angegeben. Mit dem Interaktivitätsmodus besitzt der Benutzer die Möglichkeit, die Informationsausgabe auf die für ihn interessanten Elemente einzugrenzen und aktiv während der Simulation mitzugestalten. Auch die Kollisionserkennung führt Protokoll über die für sie erfassbaren Ereignisse und berechneten Analyseergebnisse, auf die man mittels der Funktionsschaltflächen ( Anzeigen ) zugreifen kann. Das erste Log beinhaltet die tabellarische Protokollierung der berechneten Kollisionswahrscheinlichkeiten für die Kollisionspaare (Abb. 5.22). Die zweite Tabelle stellt die raumbezogenen Daten der einzelnen Kollisionskandidaten dar, welche die aktuelle Position, die Flugrichtung der einzelnen Cluster und die Annäherungstendenz der Kollisionspaare untereinander beinhaltet (Abb. 5.21). Die dritte Tabelle führt das durchgeführte Protokoll über die stattgefundenen Kollisions- und Spaltungsereignisse chronologisch auf (Abb. 5.23). Abb. 5.21: Räumliche Daten der Cluster 95

102 Abb. 5.22: Berechnete Kollisionswahrscheinlichkeiten bis zum Zeitpunkt T=7. Abb. 5.23: Kollisions- und Spaltungsereignisse bis zum Zeitpunkt T=33. Nachdem nun die Architektur des Systems mit ihren Komponenten vorgestellt und ein Überblick über die zur Verfügung gestellten Funktionalitäten gegeben wurde, werden wir uns im kommenden Kapitel die wichtigsten Algorithmen in Form von Views näher ansehen, die die Funktionalitäten letztendlich verwirklichen. 96

103 6 Ausgewählte Aspekte der Implementierung In diesem Kapitel gehen wir auf die Umsetzung derjenigen Konzepte ein, die im Kapitel 4 vorgestellt wurden, insbesondere der Implementierungsaspekte. Es ist durchaus eine Herausforderung, die Sachverhalte der realen Welt, die durch eine objektorientierte Programmiersprache wie Java intuitiver angenähert werden können, mittels einer deklarativen Sprache wie SQL zu realisieren. Die Datensätze in relationalen Tabellen lassen sich als Pendants zu Instanzen einer Java-Klasse ansehen, ebenso SQL-Views als Gegenstück zu Java-Methoden. Man soll also durch die Auswertung und Manipulation vorliegender Daten neues bzw. das gewünschte Wissen ableiten, welches uns dem Bestreben nach Verwirklichung eines Sachverhalts näherbringen wird. Dieser Ansatz gilt über die gesamte Implementierungsphase hinweg, was das Potenzial deklarativ logischer Sprachen im Vergleich zu anderen Sprachtypen verdeutlichen wird. Im Folgenden werden die Überlegungen und Implementierungsdetails zu der Realisierung des Simulators und der Monitoringkomponenten vorgestellt. Wir werden uns vorwiegend auf die SQL- Umsetzung der Sachverhalte konzentrieren, aber dort wo Java (SimMon. java) auch eine entscheidende Rolle spielt, wird auf diese näher eingegangen werden. Abschnitt 6.1 behandelt die Konstruktion des zellulären Automaten GoL, insbesondere die Berechnung der Generationen. In den nachfolgenden Unterkapiteln werden die Realisierungen der einzelnen Monitoringkonzepte besprochen, wobei wir uns auf die wichtigsten Aspekte beschränken werden. 6.1 Game of Life-Umsetzung Der primäre Ansatzpunkt bei der Konstruktion von GoL ist die Verwirklichung der drei Regeln (vgl. Kapitel 2.3) mit Hilfe von SQL. Die dafür benötigten Tabellen und Sichten wurden in dem Kapitel 4 im Verlaufe des Datenbankentwurfs vorgestellt, die wir hier wieder aufgreifen werden. Bei jeder der drei Regeln spielt wiederum die Nachbarschaftsstruktur die zentrale Rolle, d.h. zu ermitteln wieviele lebende Zellen eine Zelle als Nachbarn besitzt. Wir haben im Kapitel 4.3 gesehen, dass nur für die relevanten Zellen die Nachbarschaftsermittlung durchgeführt werden muss. Zu den relevanten Zellen zählen die (tote oder lebende) Zellen der aktuellen Generation, welche an einer lebenden Zelle angrenzen. Die aktuell lebenden Zellen gehören nicht implizit zu den relevanten Zellen, sondern nur wenn sie selbst mindestens eine lebende Zelle als Nachbar vorweisen können. Isolierte lebende Zellen oder tote Zellen, die keine lebenden Zellen in ihrer Nähe vorweisen, gehören nicht zu den relevanten Zellen. Die nachfolgende Generationsberechnung wird durch die Methoden detecttealiveneigbours() und generatetenextgeneration() koordiniert, welche auch die Simulationszeit aktualisieren. Es gilt zunächst die relevanten Zellen zu ermitteln, was durch den View RelevanteZellen- UndAnzahlLNB vollzogen werden kann. Die gegenwärtig lebenden Zellen liegen in der Tabelle Cluster vor codiert durch die beiden Spalten Zx und Zy auf die der View basiert. Es wurde Cluster als Basistabelle zur Repräsentation des Simulatorzustands verwendet, da einerseits beim Clustering jede lebende Zelle einem Cluster zugeordnet werden muss und anderseits Clustering eine Grundvoraussetzung für andere Monitoringprozesse darstellt. Der View erfasst die unmittelbaren Nachbarzellen aller aktuell lebenden Zellen und bestimmt parallel dazu die Anzahl der lebenden 97

104 Nachbarn für jede erfasste Zelle. Besitzt eine relevante Zelle mehrere lebende Zellen als Nachbarn, so werden diese mehrfach erfasst, da sich die Nachbarräume der lebenden Zellen in diesem Fall überlappen. Die Erfassungsanzahl einer relevanten Zelle entspricht dabei der Anzahl ihrer lebenden Nachbarzellen (AnzahlLNB). Um die Erfassungsanzahl in SQL zu berechnen, müssen die mehrfach vorliegenden Zellkoordinaten gruppiert werden, und mittels COUNT(*) die Exemplare derselben Zellkoordinate innerhalb ihrer eigenen Gruppe gezählt werden. Die relevanten Zellen selbst werden durch die inneren acht SFW-Blöcke erfasst, welche maximal den acht Nachbarn einer Zelle entsprechen. Dabei muss darauf geachtet werden, dass wenn eine lebende Zelle in einer Randzone liegt, keine vermeintlichen Nachbarn von außerhalb des Zellraums einzubeziehen sind. Dies wird durch die Boolean Value Expression im jeweiligen WHERE-Teil der Unteranfragen unterbunden. Im Folgenden ist der View RelevanteZellenUndAnzahlLNB gegeben (LZ = lebende Zelle; NLZ = Nachbar lebender Zelle): SELECT t.nlzx AS Zx, t.nlzy AS Zy, COUNT(*) AS AnzahlLNB FROM (SELECT Zx-1 AS NLZx, Zy-1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx-1 >= 0 AND Zy-1 >= 0 UNION ALL SELECT Zx AS NLZx, Zy-1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zy-1 >= 0 UNION ALL SELECT Zx+1 AS NLZx, Zy-1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx+1 < 60 AND Zy-1 >= 0 UNION ALL SELECT Zx-1 AS NLZx, Zy AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx-1 >= 0 UNION ALL SELECT Zx+1 AS NLZx, Zy AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx+1 < 60 UNION ALL SELECT Zx-1 AS NLZx, Zy+1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx-1 >= 0 AND Zy+1 < 40 UNION ALL SELECT Zx AS NLZx, Zy+1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zy+1 < 40 UNION ALL SELECT Zx+1 AS NLZx, Zy+1 AS NLZy, Zx AS LZx, Zy AS LZy FROM Cluster WHERE Zx+1 < 60 AND Zy+1 < 40) AS t GROUP BY t.nlzx, t.nlzy; Als Zwischenbemerkung zu erwähnen ist, dass bei dem ersten Entwurf die parallele Berechnung der relevanten Zellen inklusive der Anzahl von lebenden Nachbarn nicht vorgesehen war: Es wur- 98

105 den zunächst nur die relevanten Zellen bestimmt, welche für ein duplikatfreies Vorliegen den zeitintensiven UNION-Operator verwendeten. Nach der Einfügung in eine temporäre Tabelle wurde ein zusätzlicher UPDATE-Befehl benutzt, um die Anzahl der lebenden Nachbarn zu bestimmen. Durch die Verwendung des duplikat-eliminierenden UNION-Operators und des zusätzlichen UP- DATE Operators, benötigte die ehemalige Version vierfach mehr Zeit für eine Generationsberechnung. Das Abfrageergebnis wird in die Tabelle RelevanteZellenMitAnzahlLNB (Zx, Zy, AnzahlLNB, AssoziierteCID), die zur temporären Aufnahme des Ergebnisses (für jeden Zyklus) dient eingefügt, wobei die Spalte AssoziierteCID, falls kein Clustering stattfindet vernachlässigbar ist. Es ist zu beachten, dass in dieser Tabelle eine gegenwärtig lebende Zelle, die keine lebenden Nachbarn besitzt, nicht aufgeführt ist. Dies kann man hinnehmen, da diese Zelle in der nächsten Generation ohnehin nicht mehr existieren wird. Anhand dieser Tabelle wird nun entschieden, ob in der Tabelle Cluster vorhandene einzelne Zellen beim Übergang in die nächste Generation eventuell gelöscht werden müssen (da sie zu wenige oder zu viele lebende Nachbarn aufweisen) oder auch Zellen eingefügt werden sollen, welche noch nicht in der Cluster-Tabelle existieren, also die in der nächsten Generation geboren werden. Die den Übergang überlebenden Zellen bleiben von den Änderungen unberührt und verbleiben in der Tabelle Cluster, d.h. die Regel des Überlebens muss nicht explizit modelliert werden. Gegeben sei zunächst der DELETE-Befehl, welcher die Regel des Todes umsetzt: DELETE FROM Cluster AS l WHERE (EXISTS (SELECT * FROM RelevanteZellenMitAnzahlLNB AS n WHERE ((l.zx = n.zx) AND (l.zy = n.zy)) AND ((n.anzahllnb BETWEEN 0 AND 1) OR (n.anzahllnb BETWEEN 4 AND 8)))) OR (NOT EXISTS (SELECT * FROM RelevanteZellenMitAnzahlLNB AS n WHERE ((l.zx = n.zx) AND (l.zy = n.zy)))); Mittels EXISTS-Abfrage wird überprüft, ob in der Cluster-Tabelle gegenwärtig lebende Zellen enthalten sind, die aufgrund ungünstiger Nachbarschaftsstrukturen (weniger als 2 oder mehr als 3 lebende Nachbarn) nun im Rahmen der stattfindenden Generationsberechnung gelöscht werden müssen. Die NOT EXISTS-Abfrage behandelt genau die vorhin erwähnten isoliert liegenden lebenden Zellen, welche in der Tabelle RelevanteZellenMitAnzahlLNB nicht vorliegen. Existieren nun Zellen, die zwar in der Tabelle Cluster vorkommen aber nicht in der Tabelle RelevanteZellenMitAnzahlLNB, so werden diese Zellen gelöscht. Die neugeborenen Zellen müssen zum Abschluss der Generationsberechnung in die Tabelle Cluster (mittels einer INSERT-Anweisung) eingefügt werden, wobei der View NeugeboreneZellen, die einzufügenden Zellen bereitstellt. Es bestimmt im Sinne der Regel der Geburt zunächst die relevanten Zellen die aktuell genau drei lebende Nachbarn besitzen und außerdem wird ausgeschlossen, dass es sich bei diesen Zellen um künftige Überlebende handelt, und sie damit zurzeit nicht in der Tabelle Cluster enthalten sind: 99

106 SELECT n.zx, n.zy, n.assoziiertecid FROM RelevanteZellenMitAnzahlLNB AS n WHERE ((n.anzahllnb = 3) AND (NOT EXISTS (SELECT * FROM Cluster AS l WHERE ((l.zx = n.zx) AND (l.zy = n.zy))))); Nach der Einfügung der Neugeborenen in die Tabelle Cluster, ist die Generationsberechnung abgeschlossen und in der Tabelle Cluster liegt nun die neue Generation vor. 6.2 Evolution Wir werden hier auf die Implementierungsdetails der Funktionalitäten der ersten Monitoringkomponente Evolution näher eingehen, wobei der Aufwand für die Realisierung dieser Komponente im Vergleich zu Clustering oder Kollisionserkennung relativ unkompliziert war. Aber trotzdem ermöglicht dieses Monitoringsystem interessante Aspekte von GoL visuell zu veranschaulichen. Eine der aufschlussreichsten Funktionalitäten stellt der Lebensraum dar: Ausgehend von einer bestimmten Anfangskonfiguration und beeinflusst durch die drei Regeln von GoL, verläuft die Simulation einzigartig, wobei nur eine gewisse Anzahl von Zellen durch ihre Zustandsänderungen an der Simulation teilnehmen. Für den Betrachter lässt sich diese außerordentliche Strukturbildung durch die aktivierten Zellen über die Zeit hinweg, ohne visuelle Hilfe nicht erkennen. Eine solche Strukturbildung visuell dargestellt lässt viele Interpretationen offen: z.b. lässt sich während längerer Simulationszeit im Muster Gleiterkanone die Bewegung der Gleiter auf eine solche Weise interpretieren als ob sie einem Pfad des Lebens folgen. Dies war eine der Motivationen in der relativen Endphase der Implementierung für die Verwirklichung dieser Funktionalität. Die Umsetzung dieser Funktionalität lässt sich einfach bewerkstelligen: In jedem Simulationszeitschritt wird erfasst, ob neue Zellen in der Tabelle Cluster vorliegen, die bisher in den vergangenen Zeitschritten nicht in dieser Tabelle vorlagen. Um zu wissen, ob es sich um eine neue Zelle handelt, wird eine Aufzeichnung derjenigen Zellen in der Tabelle AktivierteZellen geführt, die mindestens einmal in die Tabelle Cluster eingefügt wurden. Wenn eine Zelle in der Tabelle Cluster vorkommt, aber nicht in der Tabelle AktivierteZellen, so wird diese in die letztgenannte Tabelle eingefügt: INSERT INTO AktivierteZellen (Zx, Zy) SELECT Zx, Zy FROM Cluster AS a WHERE NOT EXISTS (SELECT * FROM AktivierteZellen AS b WHERE b.zx = a.zx AND b.zy = a.zy) Durch die Visualisierung aller vorliegenden Zellen der Tabelle AktivierteZellen ergibt sich die faszinierende Strukturbildung. 100

107 Eine andere Funktionalität, die aber keinen visuellen Charakter hat, ist der AutoStopmodus. Zur Realisierung dieser Funktionalität wurde ein Nebenprodukt der Generationsberechnung verwendet: Zur Ausführung des DELETE- (Umsetzung der Regel des Todes ) und INSERT-Befehls (Durchführung der Regel der Geburt ) wurde die Methode Statement. executeupdate() benutzt, welche als Ausgabe einen int-wert liefert, welcher darüber Auskunft gibt wieviele Datensätze von dem Änderungsbefehl betroffen waren. Wird jedoch eine 0 zurückgeliefert, so wurde keine Änderung durchgeführt, was ferner besagt, dass keine Zustandsänderung im Simulator GoL erfolgt ist. Wurde dies registriert, so wird das Thread durch stop() angehalten. Die Option Geburtskandidaten ermöglicht die Vorausschau auf diejenigen Zellen, die in der nächsten Generation geboren werden. Hierbei kann die Tabelle RelevanteZellenMitAnzahlLNB nicht als Hilfe genommen werden, da sie nicht die gegenwärtige Gegebenheit bzgl. der Nachbarschaft repräsentiert. Die Geburtskandidaten lassen sich aber aus der Tabelle Cluster da es den aktuellen Zustand beschreibt durch den View Geburtskandidaten herleiten: SELECT a.idx, a.idy FROM (SELECT IDx, IDy FROM (SELECT Zx-1 AS IDx, Zy-1 AS IDy FROM Cluster WHERE Zx-1 >= 0 AND Zy-1 >= 0 UNION ALL SELECT Zx AS IDx, Zy-1 AS IDy FROM Cluster WHERE Zy-1 >= 0 UNION ALL SELECT Zx+1 AS IDx, Zy-1 AS IDy FROM Cluster WHERE Zx+1 < 60 AND Zy-1 >= 0 UNION ALL SELECT Zx-1 AS IDx, Zy AS IDy FROM Cluster WHERE Zx-1 >= 0 UNION ALL SELECT Zx+1 AS IDx, Zy AS IDy FROM Cluster WHERE Zx+1 < 60 UNION ALL SELECT Zx-1 AS IDx, Zy+1 AS IDy FROM Cluster WHERE Zx-1 >= 0 AND Zy+1 < 40 UNION ALL SELECT Zx AS IDx, Zy+1 AS IDy FROM Cluster WHERE Zy+1 < 40 UNION ALL SELECT Zx+1 AS IDx, Zy+1 AS IDy FROM Cluster WHERE Zx+1 < 60 AND Zy+1 < 40) GROUP BY IDx, IDy HAVING (COUNT(*)=3)) AS a LEFT JOIN Cluster AS b ON (a.idx=b.zx) AND (a.idy=b.zy) WHERE (b.zx IS Null) AND (b.zy IS Null); Die inneren acht SFW-Blöcke erfassen wieder die relevanten Zellen, welche durch das im nächsten äußeren SELECT durch GROUP BY - HAVING auf die Zellen reduziert werden, die genau drei lebende Nachbarn besitzen. Aber bei diesen Zellen kann es sich auch um die zukünftigen Überlebenden handeln, so dass ausgeschlossen werden muss, dass diese aktuell in der Tabelle Cluster vorzufinden sind. Dies wird bewerkstelligt durch den LEFT JOIN, welcher nur die Zellen der abgeleiteten Tabelle a in der Antworttabelle zulässt, die nicht in dem Cluster vorkommen. Hier wird genau genommen der MINUS bzw. EXCEPT-Operator simuliert, welcher von Access nicht unterstützt 101

108 wird. In einfacheren Fällen lässt sich der MINUS-Operator durch NOT IN simulieren, da aber eine Zelle durch eine eindeutige Kombination von zwei Koordinatenwerten repräsentiert wird, ist hier die vorgestellte Variante angebracht. Für die Identifizierung der neugeborenen Zellen, lässt sich der View NeugeboreneZellen, welche wir für die Generationsberechnung verwendet haben, wiederverwenden, da die Analyse über den derzeitigen Zustand geführt wird. In der Klasse SimMon.java wird dieser View in der Methode zeigeneugeborenezellen() aufgerufen, und die neugeborenen Zellen werden in ein Array transferiert, welche dann durch die paint()-methode auf der Canvas-Komponente gezeichnet wird. Die Todeskandidaten für den nächsten Zeitschritt sind unter den lebenden Zellen vom derzeitigen Zeitpunkt zu suchen, welche in der Tabelle Cluster vorliegen. Dementsprechend leitet der View Todeskandidaten die Informationen aus der Tabelle Cluster ab: SELECT * FROM (SELECT a.zx, a.zy, (COUNT(*)-1) AS AnzahlLNB FROM Cluster AS a, Cluster AS b WHERE b.zx=a.zx AND b.zy=a.zy OR b.zx=a.zx-1 AND b.zy=a.zy-1 OR b.zx=a.zx AND b.zy=a.zy-1 OR b.zx=a.zx+1 AND b.zy=a.zy-1 OR b.zx=a.zx-1 AND b.zy=a.zy OR b.zx=a.zx+1 AND b.zy=a.zy OR b.zx=a.zx-1 AND b.zy=a.zy+1 OR b.zx=a.zx AND b.zy=a.zy+1 OR b.zx=a.zx+1 AND b.zy=a.zy+1 GROUP BY a.zx, a.zy) WHERE (AnzahlLNB BETWEEN 0 AND 1) OR (AnzahlLNB BETWEEN 4 AND 8); Das innere SELECT mit GROUP BY bestimmt für jede lebende Zelle die Anzahl ihrer lebenden Nachbarn (AnzahlLNB) mittels COUNT(*). Die berechnete Anzahl von Datensätzen muss aber um 1 reduziert werden, da die anvisierte Zelle selbst nicht hinzugezählt werden darf. Der äußere SFW-Block selektiert letztendlich durch die im WHERE-Teil angegebene Boolean Value Expression nur die lebenden Zellen, welche aktuell die ungünstige Anzahl (zwischen 0 und 1 oder 4 und 8) an Nachbarn haben. Die Ergebnisse dieses Views werden auch in der Tabelle GestorbeneZellen für die Option gestorbene Zellen eingefügt, die dann im nächsten Zeitpunkt gültig wird. 102

109 6.3 Clustering Das vom System durchgeführte Clustering basiert auf dem Konzept der Zusammenhangskomponente, wobei die lebenden Zellen unmittelbar benachbart sein müssen, um einem bestimmten Cluster anzugehören. Ein Cluster in diesem System besitzt eine Kardinalität von mindestens einer Zelle, aber maximal 2400 Zellen. Nachfolgend ist der eigenkonstruierte Algorithmus zum Clustering aufgeführt, wobei steuernde Elemente wie Schleifen in Java ausgelagert wurden. Die zur Auffindung der Zusammenhangskomponenten zuständige Methode ist clustering() in der Klasse SimMon.java. while (Zellen in der Tabelle AbbauTabCluster noch vorhanden, die noch nicht zu einem Cluster gehören){ wähle eine Startzelle; while (erreichbare Nachbarn noch zu entdecken){ besuche alle unmittelbar erreichbaren Zellen; füge diese Zellen in die aktuell zu bildende Zusammenhangskomponente; lösche diese Zellen aus der Tabelle AbbauTabCluster; } weise für diese Zusammenhangskomponente in der Tabelle Cluster einen ID-Wert zu; } Die zu gruppierenden Zellen befinden sich in der Tabelle Cluster, die aus der derzeitigen Generationsberechnung stammen. Die Spalte CID weist aber bei den überlebenden Zellen noch den alten Cluster-ID-Wert auf (falls im letzten Zeitschritt Clustering durchgeführt wurde), aber die Neugeborenen bekommen beim Einfügen den Standardwert 0 (in CID) zugewiesen. Nun gilt es die Clusterzugehörigkeit neu zu berechnen. Der erste Schritt besteht darin, die in der Tabelle Cluster befindlichen Zellen in die AbbauTabCluster (Zx, Zy)-Tabelle mittels INSERT INTO zu kopieren. Diese Tabelle wird im Laufe der nachfolgenden Iterationen schrittweise abgebaut bis alle Zellen einem Cluster bzw. einer Zusammenhangskomponente zugeordnet wurden. Nicht in jedem Zustand des Simulators sind lebende Zellen vorhanden (manche Startkonfigurationen erlöschen nach einer gewissen Zeit der Entwicklung), infolgedessen muss überprüft werden, ob überhaupt Zellen in die Tabelle AbbauTabCluster zu Anfang eingefügt wurden oder ob während des Verlaufs der Berechnung alle lebenden Zellen schon einem Cluster zugeordnet wurden. Liegen bei dem Test noch Daten in der Tabelle vor, so wird die äußere wile-schleife eingeleitet. Die äußere wile-schleife wird solange ausgeführt, bis die Tabelle AbbauTabCluster keine Datensätze mehr enthält. Die Aufgabe dieser Schleife ist es zunächst eine Startzelle (bzw. Startknoten) für die innere wile-schleife zu finden. Diese Zelle ist der Ansatzpunkt zur Entdeckung einer Zusammenhangskomponente, oder anders ausgedrückt, sollen die Zellen gefunden werden, welche von der ausgewählten Startzelle aus erreichbar sind. Die Startzelle ist die links-obere Zelle im Zellraum, welche noch nicht bereits einem Cluster zugeordnet wurde. Diese Zelle wird durch den View ErsteZelle ermittelt: 103

110 SELECT MIN(Zx) 39 AS IDx, MIN(Zy) AS IDy FROM (SELECT * FROM AbbauTabCluster AS c WHERE (Zx <= ALL (SELECT Zx FROM AbbauTabCluster))); Das mittlere SELECT liefert den kleinsten x-koordinatenwert der in der Tabelle enthalten ist. Aufbauend auf diesem Wert, welcher zu mehreren Zellen gehören kann (da sie sich vertikal auf derselben Ebene befinden können), wird nun in der äußersten SELECT-Anweisung der zugehörige kleinste y-wert ermittelt, welcher in Kombination (Zx, Zy) eindeutig zu der links-oberen Zelle gehört. Da die AbbauTabCluster-Tabelle schrittweise abgebaut wird (d.h. einige Zellen sind schon zu Clustern zugeordnet), verschiebt sich die zu ermittelnde, links-obere Zelle im Verlaufe der Iterationen nach Rechts-unten. Nachdem nun die Startzelle ausgewählt wurde, wird diese für die Ausführung der inneren wile- Schleife in die Tabelle TempTabCluster(Zx, Zy, Bearbeitet) eingefügt. Die innere Schleife dient zum Auffinden der Zusammenhangskomponente, die zu der Startzelle gehört. Bevor die Nachbarn der Startzelle in die Tabelle TempTabCluster eingefügt werden, wird die Startzelle als Bearbeitet = 1 markiert (in späteren Iterationen werden alle in dieser Tabelle befindlichen Zellen, bevor weitere Zellen als Nachbarn eingefügt werden, auch als bearbeitet markiert). Die innere Schleife arbeitet nach dem Prinzip von breadth-first search (BFS, vgl. Kapitel 2.4.1): Zunächst werden die unmittelbaren Nachbarn der Startzelle erfasst, danach in der nächsten Iteration werden die Nachbarn, der vorhin ermittelten Nachbarn erfasst, was sich auf diese Weise fortsetzt. Zu beachten ist, dass die bereits erfassten Nachbarn nicht wiederholt besucht werden dürfen, um zu unterbinden, dass die Schleife in einen unendlichen Zyklus gerät. Aber zunächst gilt es die unmittelbaren Nachbarn der in der Tabelle TempTabCluster befindlichen Zellen (bzw. anfangs die Startzelle) zu ermitteln, wobei hier der View ErmittleNachbarn zu Einsatz kommt: SELECT DISTINCT n.zx, n.zy FROM AbbauTabCluster AS n INNER JOIN TempTabCluster AS o ON (n.zx=o.zx-1 And n.zy=o.zy-1) OR (n.zx=o.zx And n.zy=o.zy-1) OR (n.zx=o.zx+1 And n.zy=o.zy-1) OR (n.zx=o.zx-1 And n.zy=o.zy) OR (n.zx=o.zx+1 And n.zy=o.zy) OR (n.zx=o.zx-1 And n.zy=o.zy+1) OR (n.zx=o.zx And n.zy=o.zy+1) OR (n.zx=o.zx+1 And n.zy=o.zy+1); Der View erfasst alle acht Nachbarn der in der Tabelle TempTabCluster befindlichen Zellen, solange diese (die lebenden Nachbarn) in der Tabelle AbbauTabCluster überhaupt vorhanden sind. Diese besuchten Zellen werden in die Tabelle TempTabCluster als Unbearbeitet = 0 eingefügt, da es von diesen Zellen aus noch weitere Zellen (also deren Nachbarn) zu entdecken gibt. Um nun 39 MIN(Zx) wurde benutzt um eine GROUP BY-Verwendung hier zu umgehen. Ferner ließ sich dadurch die Verwendung vom duplikateliminierendem und zeitintensivem DISTINCT im mittleren SELECT vermeiden. 104

111 die bereits besuchten Zellen im späteren Verlauf nicht erneut anzutreffen, werden alle Zellen die jetzt in der Tabelle TempTabCluster vorkommen, aus der Tabelle AbbauTabCluster gelöscht: DELETE FROM AbbauTabCluster AS t WHERE EXISTS (SELECT * FROM TempTabCluster AS c WHERE (t.zx = c.zx ) AND (t.zy = c.zy)); Nach der Löschung wird getestet, ob in der Tabelle TempTabCluster noch unbearbeitete Zellen vorhanden sind: wenn ja, wird die innere Schleife erneut ausgeführt um weitere Zellen der nächsten Entfernung (Abb. 6.1) zu erfassen oder im Falle von nein, sind alle von der gegebenen Startzelle aus erreichbaren Zellen ermittelt worden, so dass diese eine Zusammenhangskomponente bilden. Die Zellen der gefundenen Zusammenhangskomponente befinden sich in der Tabelle TempTabCluster, für die nun in der Tabelle Cluster eine eindeutige Cluster-ID zugewiesen werden sollen. Die zuzuweisende Cluster-ID wird von Java für jede Zusammenhangskomponente inkrementell generiert und wie folgt zugewiesen: UPDATE Cluster AS c INNER JOIN TempTabCluster AS d ON c.zx = d.zx AND c.zy = d.zy SET c.cid = clusterid 40 Abb. 6.1: Zell- Erfassungsreihenfolge Nun kann es sein, dass noch weitere Zellen in der Tabelle AbbauTabCluster vorhanden sind, welche zu anderen noch zu bildenden Clustern gehören. Wie vorhin wird wieder eine Startzelle in der äußeren wile-schleife gewählt und entsprechend verfahren. Wenn die Tabelle AbbauTabCluster letztendlich leer ist, so bedeutet es, dass alle Zellen zu einem der entsprechenden Cluster zugeordnet wurden, und in der Tabelle Cluster nun eine eindeutige Zuordnung jeder Zelle zu einem Cluster zu finden ist. Abb. 6.2 ID-Wechsel der beiden Gleiter bei Überquerung. Gleiter 2 besaß im ersten Bild einen größeren x-wert als Gleiter 1, welcher sich im zweiten Bild geändert hat. Zwar wurden nun die Zellen Clustern zugeordnet, aber diese Art des Clusterings genügt nicht den auf Clustering basierenden Funktionalitäten wie Kollisionserkennung oder Trajektorie. Denn diese setzen voraus, dass die Cluster über einen Zeitpunkt hinaus, ihren zugewiesenen ID-Wert behal- 40 clusterid ist eine Java-Hostvariable. 105

112 ten: Eine sinnvolle Trajektorie kann nur dann gezeichnet werden, wenn es die eigentliche Bewegung des Clusters abbildet, wie bei einem Gleiter. Das bisher vorgestellte Clusteringverfahren garantiert nur eine fortdauernde eindeutige Cluster-ID-Zuweisung, insofern diese nicht mobil sind: Zum Beispiel wenn zwei Gleiter (G 1 und G 2 ) sich an einem bestimmtem x-koordinatenwert überqueren, tauschen sie ihre CID-Werte gegenseitig aus (Abb. 6.2). Der Grund ist die Reihenfolge bei der Wahl der links-oberen Zelle (Startzelle) zum Finden von Zusammenhangskomponenten im View ErsteZelle. Dieses Problem muss aufwändig gelöst werden, indem die vergebene Cluster-ID von Generation zu Generation mitgenommen wird. Es ist notwendig bereits bei der Generationsberechnung einzugreifen: Einen CID-Wert besitzen nur die Zellen, die in der aktuellen Generation leben, aber zur Berechnung der nächsten Generation müssen auch die toten Zellen, als Teil der relevanten Zellen (als Nachbar von lebenden Zellen) miteinbezogen werden, die keinen CID-Wert besitzen. Bei der Erfassung der relevanten Zellen (dessen Status sie einer oder mehreren lebenden Zellen als Nachbar zu verdanken haben) werden die CID-Werte ihrer lebenden Zellen nun auch diesen zugeteilt. Dies betrifft sowohl die lebenden als auch die toten Nachbarn von lebenden Zellen. Die Zuweisung des CIDs einer lebenden Zelle auf seine lebende Nachbarzelle verfälscht die Clusterzugehörigkeit nicht, da auch diese Zelle zu demselben Cluster gehört (Zusammenhangskomponente). Nun kann es sein, dass ein und dieselbe aktuell tote Zelle - als Nachbar von mehreren lebenden Zellen, die in unterschiedlichen Clustern liegen - unterschiedliche CID-Werte zugewiesen bekommt. Da bei der Clusterbildung der Ansatz gilt, dass eine neugeborene Zelle, deren Geburt von mehreren, in verschiedenen Clustern liegenden Zellen beeinflusst wurde, eine neutrale Rolle spielen soll, so wird dessen Cluster-ID-Wert auf die neutrale ID 0 gesetzt. Verwirklicht werden diese Aspekte durch den View RelevanteZellenUndAnzahlLNBMitCID: SELECT a.zx AS Zx, a.zy AS Zy, a.anzahllnb AS AnzahlLNB, b.id AS CID FROM RelevanteZellenUndAnzahlLNB AS a INNER JOIN (SELECT NLZx, NLZy,MAX(CID) AS ID FROM (SELECT NLZx, NLZy, CID FROM LZundNLZundCID 41 i. GROUP BY NLZx, NLZy, CID) GROUP BY NLZx, NLZy HAVING COUNT(*)=1 UNION ALL SELECT NLZx, NLZy, 0 AS ID FROM (SELECT NLZx, NLZy, CID FROM LZundNLZundCID ii. GROUP BY NLZx, NLZy, CID) GROUP BY NLZx, NLZy HAVING COUNT(*)>1) AS b ON (a.zx=b.nlzx) AND (a.zy=b.nlzy); 41 LZundNLZundCID (NLZx, NLZy, CID) ist der View (in Datenbank vorzufinden), welcher den CID Wert der lebenden Zelle auf seine Nachbarn überträgt. 106

113 In (i.) werden diejenigen relevanten Zellen ermittelt, die nur einen CID-Wert zugewiesen bekommen haben und damit ihren CID-Wert behalten dürfen. Die hier ermittelten relevanten Zellen bestehen aus den künftigen Überlebenden und den Teil der Geburtskandidaten, deren Geburt nur durch die von einem Cluster stammenden Zellen bewirkt wurde. Im Gegensatz dazu wird die Restteilmenge der Geburtskandidaten als relevante Zellen in (ii.) ausgegeben, deren Geburt durch die aus verschiedenen Clustern stammenden Zellen veranlasst wurde. Dementsprechend besitzen diese Zellen unterschiedliche CID-Werte und es muss nun ihr CID-Wert auf 0 gesetzt werden. Das hergeleitete Ergebnis wird im Rahmen der Generationsberechnung in die Tabelle RelevanteZellenMitAnzahlLNB (Zx, Zy, AnzahlLNB, AssoziierteCID) eingefügt, wobei die AssoziierteCID später als ACID (alte Cluster-ID) in der Tabelle Cluster auftaucht. Beachte: Da nur die neugeborenen Zellen in die Tabelle Cluster, mit ihren assoziierten CID-Werten als ACID eingefügt werden, müssen für die Überlebenden, die eigentlich bei der Generationsberechnung in der Tabelle Cluster unverändert bleiben, müssen ihre vorigen CID-Werte nach ACID kopiert werden, mittels eines UPDATE-Befehls. Wir kommen zurück zum Clustering: Mit dem nun verfügbaren ACID-Wert lässt sich die bereits zugewiesene CID korrigieren (die Form der Zusammenhangskomponente bleibt unverändert, d.h. nur die Cluster-ID-Werte werden im Sinne der Kontinuität ausgetauscht). Zunächst soll aus der Tabelle Cluster der aktuell (temporär) eindeutige Cluster-ID-Wert (in CID-Spalte vorzufinden), der alte Cluster-ID-Wert (ACID) der Zellen und ebenso die Anzahl der Zellen mit den Kombinationen [CID, ACID] ermittelt werden und anschließend in die Tabelle CIDKorrektur (TempCID, ACID, ÜberlebendenAnzahl, ThCID) für weitere Änderungsoperationen eingefügt werden: INSERT INTO CIDKorrektur (TempCID, ACID, ThCID, ÜberlebendenAnzahl) SELECT CID AS TempCID, ACID, 0, Count (ACID) AS ÜberlebendenAnzahl FROM Cluster GROUP BY CID, ACID ORDER BY CID; Überlebende Die Tabelle CIDKorrektur kann nun mehrere Datensätze enthalten mit derselben TempCID. Es kann sein, dass neue Zellen zu einem Cluster mit TempCID = 3 hinzugekommen sind, deren ACID 42 dann (nicht notwendigerweise) gleich 0 ist, und bei den anderen (die eigentlichen Überlebenden) ACID = 3 ist (also zweimalige Aufführung). Ein weiteres Beispielszenario wäre wenn zwei Cluster (3, 4) miteinander verschmolzen sind zu einem Cluster mit TempCID = 3, dann hat dieser Cluster Zellen mit ACID = 3 oder 4 (also auch zweimalige Aufführung). Für jede (eindeutige) TempCID wird nun diejenige "Kombination" ausgewählt, dessen ACID > 0 (da die Neugeborenen mit ACID-Wert = 0 keine Rolle bei der Neubestimmung des CIDs spielen dürfen) ist und bei dem ACID 43 die maximalen Überlebenden enthält. Dieses ACID ist nun die ThCID (theoretische Cluster-ID) für alle Datensätze mit derselben TempCID: 42 Um nochmal deutlich herauszustellen: Eine neugeborene Zelle bekommt 0 als ACID-Wert zugewiesen, nur wenn sie den in mehreren Clustern liegenden Zellen ihre Geburt zu verdanken haben. Ansonsten bekommt der Neugeborene den CID-Wert der Zellen als ACID zugewiesen, deren Geburt durch die Zellen die alle in einem Cluster liegen, ausgelöst wurde. 43 Zum Verständnis: Wenn zum Beispiel Cluster 3 und 4 zu einem einzigen Cluster verschmolzen haben, dann bekommt diese neue Cluster den ACID-Wert von denjenigen Cluster als ThCID (theoretische CID) zugewiesen, von dem es die meisten Überlebende gibt. 107

114 UPDATE CIDKorrektur AS a INNER JOIN ErmittleTempThCID AS b ON a.tempcid = b.tempcid SET a.thcid = b.tempthcid Der im UPDATE-Befehl vorkommende ErmittleTempThCID ist ein View, der folgendermaßen definiert ist: SELECT TempCID, ACID AS TempThCID FROM CIDKorrektur AS a WHERE ÜberlebendenAnzahl = (SELECT MAX(ÜberlebendenAnzahl) FROM CIDKorrektur AS b WHERE ACID > 0 AND a.tempcid = b.tempcid) AND ACID > 0; Nicht brauchbare Datensätze werden nun aus der Tabelle CIDKorrektur gelöscht, d.h. diejenigen mit ACID = 0 in Kombination mit ThCID <> 0, da diese später für uns keine Aussagekraft mehr besitzen: DELETE FROM CIDKorrektur WHERE ACID = 0 AND ThCID <> 0; Wenn mehrerer unterschiedlicher Cluster (also mit unterschiedlicher TempCID) derselbe ThCID- Wert zugeteilt worden ist (da diese von einem gemeinsamen Cluster-Vorfahr durch Spaltung abstammen), werden für diese der ThCID-Wert auf 0 zurückgesetzt und später ein eindeutiger ID- Wert zugewiesen. Ein Datensatz mit der TempCID kann seine ThCID gerade dann behalten, wenn es von dem Cluster-Vorfahr die meisten Überlebenden geerbt hat. Wenn es aber jetzt auch noch zwei TempCIDs gibt, mit der gleichen Anzahl an Überlebenden desselben Vorfahr-Clusters, so kann der Erste (der vom TempCID-Wert her kleinere) sein ThCID behalten. Der andere soll später einen neuen ThCID erhalten. Solche inkonsistenten ThCIDs sind nun zu entdecken, mit der Hilfe des Views ErfasseInkonsistenteIDs, welcher den View MinTempEindeutigeCID miteinbezieht. Min- TempEindeutigeCID liefert die TempCID-Werte von gerade denjenigen Clustern, die ihre ThCID behalten kann. Der View ErfasseInkonsistenteIDs liefert die TempCID von Clustern, deren ThCIDs wegen Überlappung (inkonsistent durch identische ThCID-Werte) noch geändert werden müssen. Das hergeleitete Abfrageergebnis wird in die Tabelle InkonsistenteCID (TempCID, ÜberlebendenAnzahl, ACID, ThCID) materialisiert: INSERT INTO InkonsistenteCID (TempCID, ÜberlebendenAnzahl, ACID, ThCID) SELECT DISTINCT a.tempcid, a.überlebendenanzahl, a.acid, a.thcid FROM CIDKorrektur AS a INNER JOIN CIDKorrektur AS b ON (a.thcid=b.thcid) AND (NOT (a.tempcid = b.tempcid)) WHERE a.tempcid NOT IN (SELECT TempCID FROM MinTempEindeutigeCID); ErfasseInkonsistenteIDs 108

115 Hier ist der View MinTempEindeutigeCID: SELECT MIN(a.TempCID) AS TempCID, a.thcid FROM CIDKorrektur AS a INNER JOIN CIDKorrektur AS b ON (a.thcid=b.thcid) AND (NOT (a.tempcid = b.tempcid)) WHERE a.überlebendenanzahl = (SELECT MAX(c.ÜberlebendenAnzahl) FROM CIDKorrektur AS c WHERE c.thcid=a.thcid) GROUP BY a.thcid; Nachdem nun die inkonsistenten theoretischen CIDs (ThCID) in der Tabelle InkonsistenteCID bereitliegen, werden diese zur Bereinigung der Inkonsistenz in der Tabelle CIDKorrektur verwendet, d.h. es werden die Datensätze mit ihren problematischen ThCIDs auf 0 gesetzt: UPDATE CIDKorrektur AS a INNER JOIN InkonsistenteCID AS b ON a.tempcid = b.tempcid SET a.thcid = 0; Jetzt kann für die Datensätze mit ThCID = 0 ein eindeutiger ID-Wert zugewiesen werden. Dazu muss aus der Tabelle Trajektorie der bisher größte im Simulationsverlauf vergebene ID-Wert mittels (SELECT MAX(CID) FROM Trajektorie) ermittelt, und danach inkrementell an diese Datensätze zugewiesen werden: UPDATE CIDKorrektur AS a SET a.thcid = inkrementierter Wert (durch Java) WHERE a.tempcid = Datensätze, die noch die ThCID gleich 0 haben; Nun können letztlich die eindeutigen ThCID-Werte dem CID in der Tabelle Cluster zugewiesen werden: UPDATE Cluster AS a INNER JOIN CIDKorrektur AS b ON a.cid = b.tempcid SET a.cid = b.thcid; Jetzt wurden die CID-Werte für die einzelnen Cluster so ausgetauscht, dass die bereits in den letzten Zeitschritten existierenden Cluster, den gleichen CID-Wert zugewiesen bekommen haben wie in der Vergangenheit und die neu hinzugekommenen Cluster jeweils eine bisher noch nicht vergebene CID erhalten. Damit ist das Clustering der Zellen vollendet. 109

116 6.4 Clusterverbände Wir gehen über zur Gruppierung der Cluster zu Clusterverbänden, die durch die Methode verbandvoncluster() realisiert wird: Hierbei werden die Cluster, begrenzt durch ihr kleinstmöglich passendes Rechteck, nun auf der nächst höheren Ebene zu Ansammlungen von Clustern gruppiert, wie Galaxien zu Galaxienhaufen. Hier ist die Interpretation von Zusammenhangskomponente variabel, d.h. die maximale Distanzschranke kann vom Benutzer selbst entschieden werden und es gilt dass die Rechtecke der Clusterverbände sich nicht überschneiden dürfen (es muss mindestens ein Abstand von einer Zelleinheit zwischen den inneren Rändern der beiden Rechtecke der Clusterverbände aufweisen). Ferner bedeutet dies, dass auch Cluster zu einem Clusterverband gezählt werden, obwohl deren Abstand zu anderen Clustern die vorgegebene Distanzschranke überschreitet. Dies stellt aber eine erweiterte Funktionalität dar, welche im Rahmen des Leitsatzes We choose to do the things, not because they are easy, but because they are hard von John F. Kennedy *Wik08f+, aufgenommen wurde. Im Folgenden wird der Algorithmus zur Bildung der Clusterverbände vorgestellt, wobei die auf Java bezogenen Details hier weitgehend vernachlässigt werden. Die Rechtecke der Cluster, definiert durch die in ihnen beinhalteten lebenden Zellen, besitzen jeweils eine bestimmte Ausdehnung, die durch den View ClusterAusmaß berechnet wird: SELECT CID, MIN(Zx) AS X1, MIN(Zy) AS Y1, ((Max(Zx)-Min(Zx)+1)+Min(Zx)) AS X2, ((Max(Zy)-Min(Zy)+1)+MIN(Zy)) AS Y2 FROM Cluster GROUP BY CID; Der vorgestellte View ermittelt die zwei aufspannenden Raumkoordinaten des Rechtecks, die links-obere (X1, Y1) und rechts-untere (X2, Y2). Das Ergebnis der Abfrage wird zunächst in die Tabelle AbbauTabClusterVerband (CVID, X1, Y1, X2, Y2) als eigenständige Clusterverbände (jedes Cluster ist zunächst ein Clusterverband) eingefügt. Nachfolgend ist eine grobe Übersicht des Algorithmuses gegeben: while (Cluster(-verband) in der Tabelle AbbauTabClusterVerband noch vorhanden){ wähle den erste Cluster und interpretiere ihn als eigenständigen Clusterverband; while (solange überlappende Cluster(-verband) mit dem aktuellen Clusterverband gibt){ erfasse unmittelbar überlappende bzw. berührende Nachbar-Cluster; skaliere das Rechteck des Clusterverbands um alle Nachbar-Cluster zu umfassen; lösche die umfassten Cluster aus der Tabelle AbbauTabClusterVerband; } weise einen eindeutigen ID-Wert dem Clusterverband zu; } beginne die aüßere while-schleife neu, um Überlappungen der konstruierten Clusterverbände zu verhindern und auch Cluster die abhängig von der vom Benutzer eingestellten Entfernung zu einem Clusterverband zu verschmelzen; Es ist wichtig zu Verstehen, dass der Algorithmus in zwei Phasen verläuft: Bei der ersten Phase werden nur diejenigen Cluster (hier sprechen wir verständlichkeitshalber noch von Clustern statt einzelnen Clusterverbänden mit jeweils einem einzigen Cluster) zu Clusterverbänden zusammen- 110

117 gefasst, wenn diese unmittelbar aneinander angrenzen. Angrenzen heißt das die Rechtecke der Cluster sich berühren oder teilweise überlappen, wobei noch keine Kollision 44 vorliegt! In der zweiten Phase wird erfasst, ob die erschaffenen Clusterverbände (repräsentiert durch den CVID- Wert und deren Ausmaß in der jeweiligen Tabelle) sich überscheiden, wenn ja werden diese Clusterverbände wieder zu einem größeren Clusterverband vereint, die die kleineren sich schneidenden Clusterverbände umfasst. Die zweite Phase geht so lange bis keine der erzeugten Rechtecke der Clusterverbände sich überschneiden. Erst in der zweiten Phase wird auch die von dem Benutzer eingestellte Distanzschranke berücksichtigt. Wenn die Tabelle AbbauTabClusterVerband im Verlaufe des Algorithmuses endgültig abgebaut ist (wird in der zweiten Phase immer wieder aufgefüllt), sind alle in ihren Abmessungen richtigen und endgültigen Clusterverbände gefunden. Erste Phase: Zunächst wird bei der äußeren wile-schleife der erste Cluster (der mit dem kleinsten ID-Wert) mittels INSERT INTO in die Tabelle TempTabClusterVerband eingefügt und gleichzeitig per DELETE von der entnommenen Tabelle AbbauTabClusterVerband gelöscht: INSERT INTO TempTabClusterVerband (CVID, X1, Y1, X2, Y2, Bearbeitet) SELECT CVID, X1, Y1, X2, Y2, 0 FROM AbbauTabClusterVerband WHERE CVID = (SELECT MIN(CVID) FROM AbbauTabClusterVerband); DELETE FROM AbbauTabClusterVerband AS t WHERE EXISTS (SELECT FROM TempTabClusterVerband AS c WHERE c.cvid = t.cvid); Die äußere wile-schleife wird so lange ausgeführt bis die Tabelle AbbauTabClusterVerband leer ist, d.h. alle Cluster zu einer der temporären (da wir uns noch in der ersten Phase befinden) Clusterverbände verschmolzen wurden. Ausgehend vom Startcluster, welcher gerade gewählt wurde, wird dieser nun in der inneren wile-schleife auf angrenzende Cluster untersucht und wenn sie sich berühren oder überlappen (entsprechend des Schnittests bei AABB-Hüllkörper, vgl. Abschnitt 2.4.4), werden die berührten Cluster in die Tabelle TempTabClusterVerband eingefügt: INSERT INTO TempTabClusterVerband (CVID, X1, Y1, X2, Y2, Bearbeitet) SELECT a.cvid, a.x1, a.y1, a.x2, a.y2, 0 FROM AbbauTabClusterVerband AS a INNER JOIN TempTabClusterVerband as b ON (((a.x1 BETWEEN b.x1 AND b.x2) OR (a.x2 BETWEEN b.x1 AND b.x2)) AND ((a.y1 BETWEEN b.y1 AND b.y2) OR (a.y2 BETWEEN b.y1 AND b.y2))) OR (((b.x1 BETWEEN a.x1 AND a.x2) OR (b.x2 BETWEEN a.x1 AND a.x2)) AND ((b.y1 BETWEEN a.y1 AND a.y2) OR (b.y2 BETWEEN a.y1 AND a.y2))); Nach der Einfügung in die Tabelle TempTabClusterVerband werden die gleichen Datensätze (Cluster) aus der entnommenen AbbauTabClusterVerband-Tabelle gelöscht. Die in der Tabelle enthaltenen Cluster werden als Bearbeitet = 1 gekennzeichnet, da die bearbeiteten Cluster selbst nach dem folgenden Schritt gelöscht werden. Alle die in der Tabelle TempTabClusterVerband enthalte- 44 Eine Kollision hat erst dann stattgefunden, wenn die Zellmassen der beteiligten Cluster zu einer Zusammenhangskomponente verschmolzen haben. 111

118 nen Cluster grenzen sich nebeneinander an, deswegen werden diese Cluster zu einem Clusterverband verschmolzen, wobei das entstehende Clusterverband-Rechteck alle in der Tabelle enthaltenen Rechtecke der Cluster beinhaltet. (MIN(X1), MIN(Y1)) bestimmt die links-obere Ausdehnung der Cluster-Rechtecke und (MAX(X2), MAX(Y2)) die rechts-untere: INSERT INTO TempTabClusterVerband (CVID, X1, Y1, X2, Y2, Bearbeitet) SELECT 0, MIN(X1), MIN(Y1), MAX(X2), MAX(Y2), 0 FROM TempTabClusterVerband; Jetzt muss wieder untersucht werden, ob das gerade entstandene Clusterverband-Rechteck sich mit dem Rechteck eines anderen Clusters schneidet (dieses Cluster muss selbst nicht mit anderen Clustern berühren), wenn ja wird der gerade erstellte Clusterverband vergrößert, um auch die sich schneidenden Cluster einzuverleiben und dabei werden der kleinere Vorgänger-Clusterverband und die gerade erwähnten Cluster aus der Tabelle TempTabClusterVerband gelöscht. Wenn die innere Schleife zum Stillstand gekommen ist, enthält die Tabelle nur ein Clusterverband(- Rechteck), das ausgehend von dem Startcluster iterativ entstanden ist. Dieses Clusterverband wird nun in die Tabelle ClusterVerband mit einer von Java generierten eindeutigen ID (ClusterverbandID, kurz CVID) eingefügt: INSERT INTO ClusterVerband (CVID, X1, Y1, X2, Y2) SELECT verbandid 45, X1, Y1, X2, Y2 FROM TempTabClusterVerband; Die äußere Schleife wird nun solange ausgeführt, bis alle Cluster zu entsprechenden Clusterverbänden verschmolzen wurden. Damit ist die erste Phase beendet. Beginn der zweiten Phase: In dieser Phase wird die Benutzereinstellung bzgl. der Distanzschranke berücksichtigt und auf dieser Basis wird auch untersucht, ob die bereits erzeugten Clusterverbände sich überschneiden. Diese Phase wird nur eingeleitet, wenn die folgende Anfrage mindestens einen Datensatz zurückliefert, was dann bedeutet, dass mindestens zwei Clusterverband- Rechtecke sich überlappen. Bei dem Überlappungstest muss beachtet werden, nicht die Rechtecke desselben Clusterverbands zu vergleichen (da es stets positiv ausfällt): SELECT * FROM ClusterVerband AS a INNER JOIN ClusterVerband as b ON (((a.x1 BETWEEN b.x1 - bereichinnerhalb AND b.x2 + bereichinnerhalb) OR (a.x2 BETWEEN b.x1 - bereichinnerhalb AND b.x2 + bereichinnerhalb )) AND ((a.y1 BETWEEN b.y1 - bereichinnerhalb AND b.y2 + bereichinnerhalb ) OR (a.y2 BETWEEN b.y1 - bereichinnerhalb AND b.y2 + bereichinnerhalb ))) OR (((b.x1 BETWEEN a.x1 - bereichinnerhalb AND a.x2 + bereichinnerhalb ) OR (b.x2 BETWEEN a.x1 - bereichinnerhalb AND a.x2 + bereichinnerhalb )) AND ((b.y1 BETWEEN a.y1 - bereichinnerhalb AND a.y2 + bereichinnerhalb ) OR (b.y2 BETWEEN a.y1 - bereichinnerhalb AND a.y2 + bereichinnerhalb ))) WHERE a.cvid <> b.cvid; 45 Java-Hostvariable 112

119 Die Java-Hostvariable bereichinnerhalb stellt die vom Benutzer eingegebene Distanzschranke dar, welche in der SQL-Anweisung folgendermaßen zu interpretieren ist: Stellt der Benutzer einen Wert ein, so muss die Bounding Box (AABB) entsprechend angepasst werden. Die zwei Raumkoordinaten, welche die Bounding Box (Rechteck) aufspannen, werden in der diagonale gleichmäßig auseinandergezogen, so dass die Fläche des Rechtecks in allen vier Himmelsrichtungen zunimmt. Wenn die Testanfrage positiv war, werden die Tabellen AbbauTabClusterVerband und TempTabClusterVerband geleert und die vorher erzeugten Clusterverbände, welche noch in der Tabelle ClusterVerband vorzufinden sind, werden nun in die Tabelle AbbauTabClusterVerband eingefügt, als ob sie Cluster wären. So beginnt die äußere Schleife von neuem, wobei ab jetzt in der inneren Schleife die folgende INSERT-Anweisung zum Einfügen der berührten Clusterverbände in die Tabelle TempTabClusterVerband verwendet wird: INSERT INTO TempTabClusterVerband (CVID, X1, Y1, X2, Y2, Bearbeitet) SELECT a.cvid, a.x1, a.y1, a.x2, a.y2, 0 FROM AbbauTabClusterVerband AS a INNER JOIN TempTabClusterVerband as b ON (((a.x1 BETWEEN b.x1 - bereichinnerhalb AND b.x2 + bereichinnerhalb) OR (a.x2 BETWEEN b.x1 - bereichinnerhalb AND b.x2 + bereichinnerhalb)) AND ((a.y1 BETWEEN b.y1 - bereichinnerhalb AND b.y2 + bereichinnerhalb) OR (a.y2 BETWEEN b.y1- bereichinnerhalb AND b.y2 + bereichinnerhalb))) OR ((b.x1 BETWEEN a.x1 - bereichinnerhalb AND a.x2 + bereichinnerhalb) OR (b.x2 BETWEEN a.x1 - bereichinnerhalb AND a.x2 + bereichinnerhalb)) AND ((b.y1 BETWEEN a.y1 - bereichinnerhalb AND a.y2 + bereichinnerhalb) OR (b.y2 BETWEEN a.y1 - bereichinnerhalb AND a.y2 + bereichinnerhalb))); Nach Ende der zweiten Phase ist der Algorithmus endgültig beendet und dann liegen in der Tabelle ClusterVerband (CVID, X1, Y1, X2, Y2) die Clusterverbände vor, eindeutig identifizierend durch ihre Clusterverband ID-Werte (CVID) und ihrer zwei aufspannenden Raumkoordinaten. Um zu wissen, welcher Cluster nun zu welchem Clusterverband gehört, lässt sich mit dem View Cluster- VerbandUndCluster bestimmen: SELECT a.cvid, b.cid FROM ClusterVerband AS a INNER JOIN ClusterAusmaß AS b ON (((a.x1 BETWEEN b.x1 AND b.x2) OR (a.x2 BETWEEN b.x1 AND b.x2)) AND ((a.y1 BETWEEN b.y1 AND b.y2) Or (a.y2 BETWEEN b.y1 AND b.y2))) OR (((b.x1 BETWEEN a.x1 AND a.x2) Or (b.x2 BETWEEN a.x1 AND a.x2)) AND ((b.y1 BETWEEN a.y1 AND a.y2) Or (b.y2 BETWEEN a.y1 AND a.y2))); Hier wird wieder der Überlappungstest (auf den Koordinatenachsen) durchgeführt, zwischen den Rechtecken der Clusterverbände und den der Cluster. Als Ergebnis wird die eindeutige Zuordnung der CID-Werte zu den einzelnen CVID-Werten geliefert. 113

120 6.5 Mustererkennung Das primäre Ziel bei der Mustererkennungskomponente ist es eine gute Erkennungsrate zu erlangen. Die erwartete Fehlertoleranz sollte praktisch bei 0 liegen, so dass alle dem System bekanntgemachten Muster zu erkennen sind. Die ausschließliche Implementierung der Erkennungsroutine in SQL soll auch experimentell verdeutlichen, wie gut sich SQL auch im Bereich der Mustererkennung bewährt. Es wurden zwei Arten der Erkennungsmethodik implementiert, welche nun kurz diskutiert werden sollen. Die Erste ist es mittels einer vorgegebenen Anordnung der lebenden Zellen ein Muster zu erkennen. Hier stellt sich die Frage, ob man ein Muster nur anhand von bestimmten für dieses Muster charakteristischen Strukturen erkennen oder die gesamten strukturellen Eigenschaften zur Identifizierung eines Musters einbezogen werden sollen. Beides hat Vorund Nachteile: Wenn man ein Muster nur anhand bestimmter Ausprägungen (nur auf bestimmte lebende Zellen in der Anordnung untersuchen, ob diese existieren) zu identifizieren versucht, lässt sich der Erkennungsprozess dadurch erheblich beschleunigen. In der Abb. 6.3a ist ein Beispiel für das Muster Fisch angegeben, wobei die blau markierten Zellen den zu deckenden bzw. zu überprüfenden Zellen entsprechen. Je kleiner die Anzahl der zu vergleichenden Zellen, desto schneller wird die anhand einer SQL-Abfrage durchgeführte Erkennung, absolviert. Jedoch ist darauf zu achten, dass (zum Beispiel im Fisch-Beispiel, Abb. 6.3) diese Konstellation von zu überprüfenden Zellen auch in anderen Mustern vorkommen kann, und so fälschlicherweise auch andere Muster identifiziert werden, die sich nur in diesen Eigenschaften entsprechen (Abb. 6.3b). Dies steigert die Fehlerquote des Erkennungssystems. Abb. 6.3: Fisch-Mustererkennung Wenn aber die gesamte Menge der muster-definierenden lebenden Zellen (also alle lebenden Zellen) im Identifizierungsprozess einbezogen wird, so wird die Erkennungsrate um einige Faktoren gesteigert, aber dies zu Lasten der Laufzeiteffizienz. Auch hier ist zu beachten, dass das Muster Fisch (als Beispielinstanz) als ein Teil einer größeren Zusammenhangskomponente vorkommen kann, so dass eine Identifizierung des Musters Fisch als Teil eines größeren Clusters nicht zulässig ist. Ein Muster beinhaltet stets ein oder mehrere vollständige Cluster: das Muster Fisch besteht entweder aus einem einzigen oder zwei Clustern, je nachdem, in welcher seiner vier Zwischenformen das Muster vorliegt. Eine maximale Erkennungsgenauigkeit erhält man, wenn zusätzlich gefordert wird (zuzüglich der Erfassung aller lebenden Zellen des Musters), dass die unmittelbar umgebenden Zellen der muster-definierenden lebenden Zellen den Zustand tot besitzen müssen (siehe Abb. 6.3c: rotes X). 114

121 Auf diese Weise wird ausgeschlossen, dass das zu erkennende Muster nicht als Teil einer größeren Zusammenhangskomponente vorliegt, aber parallel wird auch die Erkennungsschnelligkeit verschlechtert. Da wir Wert auf höchste Erkennungsgenauigkeit gelegt haben, werden wir die letztere Variante für die Implementierung bevorzugen. Diese Erkennungsmethodik kommt außer bei Fisch, noch bei den Mustern Blinker, Gleiter und Quad zum Einsatz, wobei außer für das Fisch- Muster alle Varianten (Zwischenformen und räumliche Ausrichtung) erkannt werden. Für die in Abb. 6.3c vorgestellte Fisch-Muster-Zwischenform wird im Folgenden der muster-erkennende SQL-Code (View FischA) exemplarisch angegeben, welcher den Aufwand des Erkennungsalgorithmuses verdeutlicht: SELECT l.cid, l.zx, l.zy FROM (((((((Cluster AS l INNER JOIN Cluster AS a ON (a.zx = l.zx-3) AND (a.zy = l.zy)) INNER JOIN Cluster AS b ON (b.zx = l.zx-2) AND (b.zy = l.zy)) INNER JOIN Cluster AS c ON (c.zx = l.zx-1) AND (c.zy = l.zy)) INNER JOIN Cluster AS d ON (d.zx = l.zx-4) AND (d.zy = l.zy+1)) INNER JOIN Cluster AS e ON (e.zx = l.zx) AND (e.zy = l.zy+1)) INNER JOIN Cluster AS f ON (f.zx = l.zx) AND (f.zy = l.zy+2)) INNER JOIN Cluster AS g ON (g.zx = l.zx-4) AND (g.zy = l.zy+3)) INNER JOIN Cluster AS h ON (h.zx = l.zx-1) AND (h.zy = l.zy+3) WHERE NOT EXISTS (SELECT * FROM Cluster AS m WHERE (m.zx = l.zx-4 AND m.zy = l.zy-1) OR (m.zx = l.zx-3 AND m.zy = l.zy-1) OR (m.zx = l.zx-2 AND m.zy = l.zy-1) OR (m.zx = l.zx-1 AND m.zy = l.zy-1) OR (m.zx = l.zx AND m.zy = l.zy-1) OR (m.zx = l.zx+1 AND m.zy = l.zy-1) OR (m.zx = l.zx-5 AND m.zy = l.zy) OR (m.zx = l.zx-4 AND m.zy = l.zy) OR (m.zx = l.zx+1 AND m.zy = l.zy) OR (m.zx = l.zx-5 AND m.zy = l.zy+1) OR (m.zx = l.zx-3 AND m.zy = l.zy+1) OR (m.zx = l.zx-5 AND m.zy = l.zy+3) OR (m.zx = l.zx-3 AND m.zy = l.zy+3) OR (m.zx = l.zx-2 AND m.zy = l.zy+3) OR (m.zx = l.zx AND m.zy = l.zy+3) OR (m.zx = l.zx+1 AND m.zy = l.zy+3) OR (m.zx = l.zx-5 AND m.zy = l.zy+4) OR (m.zx = l.zx-4 AND m.zy = l.zy+4) OR (m.zx = l.zx-3 AND m.zy = l.zy+4) OR (m.zx = l.zx-2 AND m.zy = l.zy+4) OR (m.zx = l.zx-1 AND m.zy = l.zy+4) OR (m.zx = l.zx AND m.zy = l.zy+4)); 115

122 Der gegebene SQL-View dient nur zur Erkennung einer einzigen Zwischenform des Musters Fisch, wobei das nach Osten schwimmende Fisch vier Zwischenformen hat. Da der View pro Muster (dieser Variante) einen Datensatz liefert, welche die Anvisierungszelle und den CID-Wert des Clusters in dem sie liegt, enthält. Die Anvisierungszelle ist in Abb. 6.3c durch das A gekennzeichnet. Ausgehend von der Anvisierungszelle wird geschaut, ob die anderen lebenden Zellen in der geforderten Anordnung vorliegen. Im FROM-Teil werden nacheinander durch INNER JOINs die Existenz der acht lebenden Zellen gefordert zusätzlich zu der Anvisierungszelle. Außerdem wird im WHERE-Teil verlangt, dass die durch rote X markierten Zellen (anhand ihrer relativen Lagen) nicht in der Tabelle Cluster vorliegen, d.h. diese den Zustand tot besitzen. Um in dem GUI die entsprechenden musterbildenden lebenden Zellen zu visualisieren, müssen wiederum von der Anvisierungszelle aus alle zu dem Muster zugehörigen lebenden Zellen erfasst werden. (Ax und Ay sind die Koordinatenwerte der Anvisierungszelle): SELECT Zx, Zy FROM Cluster WHERE Zx = Ax AND Zy = Ay OR Zx = Ax - 3 AND Zy = Ay OR Zx = Ax - 2 AND Zy = Ay OR Zx = Ax - 1 AND Zy = Ay OR Zx = Ax - 4 AND Zy = Ay +1 OR Zx = Ax AND Zy = Ay +1 OR Zx = Ax AND Zy = Ay +2 OR Zx = Ax - 4 AND Zy = Ay +3 OR Zx = Ax - 1 AND Zy = Ay +3; Die zweite Art der Erkennungsmethodik ist durch das Verhalten der Struktur eines Muster zu erkennen. Unter dem Verhalten kann man sich hier zum Beispiel die Eigenschaften Mobilität, Stabilität oder Oszillation vorstellen. Als Demonstrationsinstanz wurde bei der Realisierung die Musterart Stilleben gewählt. In GoL erlangt ein Cluster die Stabilität, wenn alle seine lebenden Zellen genau zwei oder drei lebende Nachbarn besitzen und keiner der benachbarten toten Zellen drei lebende Zellen in ihrer Umgebung aufweist. Auf Grundlage dieser Konstellation und der drei Entwicklungsregeln bleibt ein stabil gewordenes Cluster im GoL in den nachfolgenden Zeitschritten beständig, solange kein anderes Cluster durch Annäherung oder Kollision die Stabilität beeinflusst. Um die Stabilität eines Cluster zu überprüfen, werden Daten aus zwei Zeitpunkten benötigt, also von der unmittelbaren Vergangenheit t 1 und der Gegenwart t. Die Daten sind die Koordinaten der lebenden Zellen und deren Zugehörigkeit zu einem Cluster. Dementsprechend lassen sich die Informationen über die Cluster für die Gegenwart in der Tabelle Cluster finden, aber für die vergangenen Clusterdetails wird eine weitere Tabelle benötigt, die die Daten für eine Zeiteinheit aufbewahrt. In der Tabelle Historie (CID, Zx, Zy) werden die Clusterinformationen vom Zeitpunkt t 1 bereitgehalten. Wenn die Option zur Erkennung des Stillebens aktiviert wird, so wird erst ab der übernächsten Generation dieser Mustertyp erkannt, um die vergangenen Daten (in der Tabelle Historie) zur Verfügung zu haben. 116

123 Ein Cluster ist stabil, wenn es zu den beiden Zeitpunkten t 1 und t aus derselben Anzahl an lebenden Zellen besteht und wenn es sich um die gleichen lebenden Zellen handelt (identifizierend durch Zx und Zy), gewiss muss der Cluster auch denselben CID-Wert zu beiden Zeitpunkten aufweisen. Wenn eines der genannten Kriterien für ein Cluster nicht erfüllt ist, so handelt es sich bei diesen Clustern nicht um Stilleben. Wir betrachten dies an einem Beispiel (bzgl. der gleich zu bleibenden Anzahl der Zellen) in dem Muster Gleiterkanone (Abb. 6.4): Der Cluster 2 ist in den Zeitpunkten 12 und 13 ein Stilleben, da es die gleiche Anzahl an identischen Zellen besitzt. Aber zum Zeitpunkt 14 ist der Cluster 3, welcher einen Gleiter darstellt, mit dem ehemaligen Stilleben kollidiert und ist zu dem Cluster 2 verschmolzen, weil dieser Cluster die meisten Überlebenden an dem neuen Clusterverbund stellt. Die sechs identischen Zellen sind auch in diesem neuen Cluster vorhanden (weis markiert, Abb. 6.4c), aber trotzdem hat der Cluster 2 seine Stabilitätseigenschaft verloren, also ist es kein Stilleben mehr. Die Verifizierung dieser Aspekte wird durch den View StillebendeCluster vorgenommen, welcher der CID-Werte von derjenigen Clustern liefert, die die Eigenschaft der Stabilität besitzen: SELECT e.cid FROM (SELECT DISTINCT e.cid FROM Cluster AS e LEFT JOIN (SELECT b.cid FROM Cluster AS a i. RIGHT JOIN Historie AS b ii. ON (a.zx = b.zx) AND (a.zy = b.zy) WHERE (a.zx IS Null And a.zy IS Null)) AS f ON e.cid = f.cid WHERE (f.cid IS Null) AND e.cid IN (SELECT CID FROM Historie)) AS g INNER JOIN (SELECT DISTINCT x.cid FROM Cluster AS x LEFT JOIN (SELECT a.cid FROM Cluster AS a LEFT JOIN iii. iv. Historie AS b ON (a.zy = b.zy) AND (a.zx = b.zx) WHERE (b.zx IS Null And b.zy IS Null)) AS c ON x.cid = c.cid WHERE (c.cid IS Null) AND x.cid IN (SELECT CID FROM Historie)) AS h ON g.cid = h.cid; v. 117

124 Abb. 6.4: Stabilitätsverlust bei Cluster 2. i. Erfasst diejenigen Cluster in der Tabelle Historie (der Cluster muss in der aktuellen Zeit nicht mehr existieren), welche in der aktuellen Generation im Vergleich zum letzten Zeitpunkt an lebenden Zellen verloren haben. Beispielsweise wie bei einem Gleiter während seines Fluges (verliert zwei lebende Zellen, aber parallel kommen dem Muster zwei Neugeborene hinzu) oder nach einer Kollision wie beim Cluster 3 (welcher nicht mehr im T = 14 existiert und damit seine gesamte Zellmasse verloren hat, in Abb. 6.4.) Die hier erfassten Cluster sind somit nicht stabil. ii. Hier findet ein Filterung statt: Es werden nur aktuelle CID-Werte genommen (die gegenwärtig existieren), die nicht im RIGHT JOIN-Ergebnis vorkommen. D.h. es werden an dieser Stelle nur Cluster berücksichtigt, deren Zellmasse nicht geschrumpft ist. So wird hier z.b. noch Cluster 2 (T=14) auftauchen, weil es eher an Masse (an lebenden Zellen) zugenommen hat. iii. Liefert diejenigen CID-Werte von Clustern, die zum aktuellen Zeitpunkt im Vergleich zum letzten Zeitpunkt neue Zellen (also Neugeborene) hinzugewonnen haben. Hat der Cluster parallel einige lebende Zellen verloren, so würde dieser Cluster auch im Ergebnis von (i.) vorkommen. iv. Hier werden nur noch die CID-Werte der aktuell existierenden Cluster herausgegeben, deren Zellmasse nicht zugenommen haben. In dieser Abfrage wird z.b. der Cluster 2 zum Zeitpunkt T = 14 (Abb. 6.3c) nicht auftauchen. v. Anhand der Durchschnittsbildung über INNER JOIN der beiden Ergebnisse aus (ii.) und (iv.) lassen sich genau diejenigen gegenwärtigen Cluster finden, die sowohl in t 1 als auch in t aus derselben Anzahl an identischen lebenden Zellen bestanden haben. Diese Cluster sind stabil, denn sie haben weder lebende Zellen verloren noch neugeborene Zellen hinzubekommen, und gehören damit zum Mustertyp Stilleben. Mittels des gegebenen Views lassen sich alle Cluster als Stilleben identifizieren, die mindestens auf zwei unmittelbar aufeinanderfolgenden diskreten Zeitpunkten stabil waren. Wir haben damit gezeigt, dass man mittels zwei verschiedener Ansätze (1) Anordnung der lebenden Zellen und (2) stabiles Verhalten das auf Grundlage der datenbankbasierten Mustererkennung in der Lage ist, vorgegebene als auch noch unbekannte Muster zu erkennen. 118

125 6.6 Trajektorienbestimmung Bei der Realisierung der Trajektorienzeichnung wird SQL zur Bereitstellung, für die Zeichnung relevanter Massenpunkte eingesetzt, wobei Java die Zeichnungsroutine übernimmt (wird hier nicht näher betrachtet). Bei der Zeichnung der vollen Trajektorie und der gleitenden Durchschnittslinie werden alle Massenpunkte (zur realistischeren Visualisierung wurde der linksobere Punkt jedes Cluster-Rechtecks als Massenpunkt benutzt) des Clusters benötigt, wobei die Option zur Zeichnung aller Cluster oder nur gegenwärtig existierender Cluster zu berücksichtigen bleibt. In der Tabelle Trajektorie sind alle Massenpunkte der gegenwärtigen und der nicht mehr existierenden Cluster vorhanden. Sollen nur Trajektorien existierender Cluster gezeichnet werden, so werden dafür die Cluster-ID-Werte aus der Tabelle Cluster ermittelt, da diese Tabelle den gegenwärtigen Zustand des Simulators darstellt und dementsprechend auch nur die aktuellen Cluster-IDs enthält (dagegen ist die Tabelle Trajektorie auch zum Extrahieren der ehemaligen CID-Werte verwendbar). Anhand der verfügbaren Cluster-IDs kann man für einzelne Cluster die zugehörigen Massenpunkte chronologisch geordnet liefern lassen: SELECT Zx, Zy FROM Trajektorie WHERE CID = clusterid //clusterid (Java-Hostvariable) ist der CID-Wert des ausgewählten Clusters ORDER BY T Beim aktivierten volle Trajektorie -Modus lässt sich auch bestimmen, dass nur der aktuellere Trajektorie-Teil detailliert angezeigt wird, während die älteren Teile vergröbert werden. Zur Zeichnung des älteren Abschnitts werden nur Massenpunkte von gewissen Zeitpunkten notwendig, aber dagegen bei neueren alle Massenpunkte. Bei der Erfassung der Daten des älteren Abschnitts ist zu beachten, dass der Anfangs- und Endmassenpunkt einzubeziehen ist, da diese sonst bei dem eingesetzten MOD-Operator eventuell fallengelassen werden: SELECT Zx, Zy, T FROM Trajektorie WHERE CID = clusterid AND (T MOD detailstufedervergroberung = 0 OR T = (SELECT FIRST(T) FROM Trajektorie WHERE CID = clusterid) OR T = (SELECT LAST(T) FROM Trajektorie WHERE CID = clusterid)) AND T <= (generations - vergroberungabgeneration) ORDER BY T UNION ALL SELECT Zx, Zy, T FROM Trajektorie WHERE CID = clusterid AND T > (generations - vergroberungabgeneration) ORDER BY T i. ii. 119

126 i. Hier werden die für den älteren Trajektorie-Abschnitt benötigten Massenpunkte in vordefinierten Intervallen (anhand MOD = 0) erfasst. Mittels FIRST(T) und LAST(T) wird auch der Anfangs- und Endpunkt für diesen Abschnitt miteinbezogen. Das kursiv Geschriebene stellen Java-Hostvariablen dar, wobei generations die aktuelle Simulationszeit repräsentiert und vergroberungabgeneration den Richtwert angibt, ab welchem Datenalter die Massenpunkte zu dem vergröbernden Trajektorienabschnitt zählen sollen. ii. In diesem SELECT werden diejenigen Massenpunkte für die Trajektorienzeichnung bereitgestellt, die in den detailierten Abschnitt eingehen. Die Cluster, welche nur einen Massenpunkt in dem gesamten Simulationsverlauf aufweisen, werden bei der Trajektorienzeichnung zunächst nicht berücksichtigt (wird von Java aus explizit unterdrückt). Um aber die Massenpunkte der kurzlebigen Cluster explizit zu zeichnen, werden die Daten durch den View ErmittleUnikaleCID vorgelegt: SELECT a.cid, b.zx, b.zy FROM AnzahlIDVorkommenInTabTrajektorie AS a INNER JOIN Trajektorie AS b ON a.cid = b.cid WHERE a.anzahl = 1; SELECT CID, COUNT(CID) AS Anzahl FROM Trajektorie GROUP BY CID; Bei der Standardeinstellung ist die Löschung der Trajektoriendaten nicht vorgesehen, jedoch lässt sich dies mittels der Option ältere Trajektoriedaten löschen revidieren. Hier wird bestimmt, ab welchem Datenalter die Massenpunkte der Cluster zu löschen sind (durch Java-Hostvariable ab repräsentiert). Ausgeführt wird diese Vorgabe durch den folgenden DELETE-Befehl: DELETE FROM Trajektorie AS a WHERE EXISTS (SELECT * FROM Trajektorie AS b WHERE (a.t = b.t AND a.cid = b.cid) AND (generations - b.t > ab); Besser wäre es, die Daten nur in bestimmten Intervallen zu löschen, um den Datenbankzugriff zu minimieren. Jedoch fiel die Entscheidung auf die vorgestellte Version, um bei der Visualisierung den Abbau an dem Trajektorieende fließend zu gestalten, welcher für den Betrachter authentischer erscheint. Zum Beispiel möge sich ein Betrachter (interpretierend) beim Anblick eines fliegendes Gleiters mit gleichmäßig-abbauender Trajektorie an einen Kometen mit Schweif erinnern. 6.7 Kollisionserkennung Wir kommen zu eines der interessantesten Monitoringkonzepte, der Kollisionserkennung. Das System soll aber mehr leisten als nur ein geschehenes Kollisionsereignis zu registrieren. Vielmehr soll es über bevorstehende Kollisionen Auskunft geben, d.h. Kollisionswahrscheinlichkeiten berechnen, aber auch detailierte Informationen zu Kollisionskandidaten bereitstellen. Außerdem wird das System geschehene Kollisionen nach ihren Arten unterscheiden können und in der Lage 120

127 sein Spaltungen von Clustern zu erkennen. Wir werden hier nur auf die wichtigen Aspekte zu sprechen kommen. Das erste Implementierungsziel ist die Identifizierung von Kollisionskandidaten. Normalerweise werden bounding boxes eingesetzt, um zu prüfen, ob zwei Objekte bereits kollidiert sind. Wir setzen jedoch bounding boxes präventiv ein, um bevorstehende Kollisionen zeitlich früher zu erfassen. Dabei werden in drei Größen skalierte bounding boxes in demselben Format des Rechtecks (zur besseren Unterscheidung benannt als cluster box ), das eine Zusammenhangskomponente kleinstmöglich passend Abb. 6.5: cluster box und bounding box umhüllt. Abb. 6.5 zeigt die cluster box und bounding box von zwei Clustern. Die durchlinierte stellt die cluster box und die jeweils drei gestrichelten Rechtecke stellen die drei skalierten bounding boxes dar. Die Fläche zwischen der kleineren bounding box und der cluster box stellt den Gefahrenbereich nah dar; die Fläche der mittleren bounding box abzüglich der Fläche der kleineren bounding box repräsentiert den Gefahrenbereich mittel und analog dazu der Gefahrenbereich fern. Der nah-bereich hat eine Pufferzone von der Breite einer Zelleinheit und die anderen zwei Bereiche jeweils drei Zelleinheiten. Die Größen der bounding boxes wurden unter Berücksichtigung der Fläche des Zellraums und für einen realistischen Einfluss auf die Wahrscheinlichkeitsberechnung nach mehreren Erprobungen ausgewählt. Jetzt gilt es, bounding boxes in der Sprache der Datenbank zu realisieren und damit Kollisionskandidaten zu ermitteln. Zwei Cluster zählen zu einem Kollisionspaar, wenn die bounding box des einen Clusters (CA) sich mit der cluster box des anderen Clusters (CB) überlappt bzw. berührt. Der Überlappungstest erfolgt auf den Koordinatenachsen beruhend auf das AABB-Konzept (vgl. Abschnitt 2.4.4). Je nachdem welche bounding box (von außen nach innen) den letzten Kontakt mit der cluster box hatte, wird dementsprechend ihr Gefahrenbereichswert zugewiesen. Eine erste Entfernungsabschätzung lässt sich per Abschätzung des euklidischen Abstands zwischen den Mittelpunkten der beiden Cluster bewerkstelligen. Mit dem Mittelpunkt eines Clusters ist nicht das Zentrum der cluster box gemeint, sondern der Schwerpunkt der lebenden Zellmasse. Die ermittelten Daten werden in eine temporäre Tabelle zur weiteren Berechnung eingefügt: INSERT INTO TempKollision (CA, CB, GefahrenBereich, Entfernung) SELECT t.ca, t.cb, t.gefahrenbereich, t.entfernung FROM (SELECT a.cid AS CA, b.cid AS CB, SWITCH((((b.X1 BETWEEN a.x1-1 AND a.x2+1) Or (b.x2 BETWEEN a.x1-1 AND a.x2+1)) And ((b.y1 BETWEEN a.y1-1 AND a.y2+1) Or (b.y2 BETWEEN a.y1-1 AND a.y2+1))),'nah', (((b.x1 BETWEEN a.x1-4 AND a.x2+4) Or (b.x2 BETWEEN a.x1-4 AND a.x2+4)) And ((b.y1 BETWEEN a.y1-4 AND a.y2+4) Or (b.y2 BETWEEN a.y1-4 AND a.y2+4))),'mittel', (((b.x1 BETWEEN a.x1-7 AND a.x2+7) Or (b.x2 BETWEEN a.x1-7 AND a.x2+7)) And ((b.y1 BETWEEN a.y1-7 AND a.y2+7) Or (b.y2 BETWEEN a.y1-7 AND a.y2+7))),'fern') AS GefahrenBereich, ROUND(SQR(((a.MPx-b.MPx)^2)+((a.MPy-b.MPy)^2)), 2) AS Entfernung 121

128 FROM ClusterAusmaß AS a INNER JOIN ClusterAusmaß AS b ON (a.cid <> b.cid) AND (a.cid < b.cid) [WHERE (a.cid IN (AngreiferIDString)) OR (b.cid IN (AngreiferIDString))] // (1) [WHERE (a.cid IN (AngreiferIDString) AND (b.cid IN (ZielIDString))) OR (a.cid IN (ZielIDString) AND b.cid IN (AngreiferIDString))] // (2) ORDER BY a.cid, b.cid) AS t WHERE t.gefahrenbereich IS NOT Null; In der JOIN-Bedingung der inneren SELECTs wird darauf geachtet, dass der Überlappungstest zwischen der bounding box und der cluster box, nicht von denselben Cluster stammen. Ebenso ist es nicht notwendig, für ein bereits erfolgten Test zwischen Cluster A (CA) und Cluster B (CB) auch noch einen zwischen CB und CA zu führen (deswegen a.cid < b.cid). Ein Clusterpaar bekommt in der SWITCH-Funktion den Wert Null als Gefahrenbereich zugewiesen, wenn dessen Rechtecke (bounding box und cluster box) sich nicht überlappen, und dementsprechend keine bevorstehende Kollision vorliegt. Deshalb werden in die Tabelle nur Kollisionskandidaten (in einer binären Beziehung) mittels INSERT eingefügt. Im Interaktivmodus werden die Kollisionskandidaten nur auf den (1) gewählten Angreifer und den potenziellen Zielen bzw. (2) nur auf den ausgewählten Angreifer und Ziel explizit reduziert (AngreiferIDString und ZielIDString stellen Java-Variablen dar). Wir beziehen uns im Folgenden nur noch auf den Normalmodus, bei dem alle Kollisionskandidaten berücksichtigt werden. Das nächste Ziel ist die bereits provisorisch erfasste Entfernung zwischen den zwei Clustern des Kollisionspaars zu korrigieren. Die bisherige Entfernungsmessung beläuft sich auf die Distanz zwischen den beiden Mittelpunkten. Eine genauere Entfernung stellt der Abstand zwischen den cluster boxes der beiden Zusammenhangskomponenten dar, die wir im Folgenden berechnen werden. Dafür werden zunächst jeweils die zwei Raumkoordinaten der cluster boxes benötigt und die Koordinate des Massenschwerpunkts von der Zusammenhangskomponente: SELECT CID, MIN(Zx) AS X1, MIN(Zy) AS Y1, ((Max(Zx)-Min(Zx)+1)+Min(Zx)) AS X2, ((Max(Zy)-Min(Zy)+1)+MIN(Zy)) AS Y2, AVG(Zx) AS MPx, AVG(Zy) AS MPy FROM Cluster WHERE CID = clusterid // clusterid jeweils für Cluster A und Cluster B GROUP BY CID; Um die Entfernung zwischen den cluster boxes (Rechtecke) zu ermitteln, soll die folgende Idee umgesetzt werden: Um den richtigen Abstand zu erhalten, müssen die Radien der beiden Rechtecke von der bereits gemessenen Entfernung abgezogen werden. Aber ein Rechteck besitzt in der Regel im Gegensatz zu einem Quadrat zwei Radien, jeweils die Hälfte von der Höhe und der Breite. Welcher dieser zwei Radien eines Rechtecks abzuziehen ist, hängt von dem Schnitt der Abstandslinie (die Linie wird durch die Koordinaten der Schwerpunkte der beiden Cluster definiert) mit einer der vier Kanten des Rechtecks ab. Zwei der Kanten haben die Länge der Breite vom Rechteck und die anderen zwei besitzen eine Länge äquivalent zur Höhe. Wenn die Abstandslinie die untere oder obere Kante (die Breiten-Kanten) des Rechtecks schneidet, so wird die Hälfte der Höhe des Rechtecks von der Abstandslinie reduziert oder falls die Abstandslinie eine der (linke oder rechte) Höhen-Kanten schneidet, wird die Hälfte der Breite abgezogen (Abb. 6.6a, weiß markiert). 122

129 Realisiert wurde die vorgestellte Entfernungskorrektur in Java. Ein Linien-Objekt lässt sich durch den Konstruktor Line2D. Double(double x1, double y1, double x2, double y2) erschaffen, wobei insgesamt neun Objekte benötigt werden: jeweils vier Kanten für die zwei Rechtecke des Kollisionspaars und zusätzlich eine Abstandslinie. Ob ein Schnitt zweier Linien (zwischen Abstandslinie und einer der Kanten des Rechtecks) vorliegt, lässt sich mittels der Methode boolean Line2D. intersectsline(line2d l) überprüfen. Liegt ein Schnitt vor, so wird entsprechend die Hälfte der Höhe oder Breite von der Abstandslinie reduziert. Abb. 6.6: (a) zeigt die eingesetzte Entfernungsmessungsvariante und (b) die plausible, aber nicht eingesetzte Version (Grund: siehe Text) Im Rahmen der Diplomarbeit wurde eine Methode zur genaueren Abstandsberechnung zwischen zwei Rechtecken implementiert, scnittpunktvonlinien(linie1, linie2), die die Raumkoordinate des Schnittpunkts zweier Linien liefert, und mit Kombination von Point2D. distance(point2d pt) letztlich auch die Distanz zwischen zwei Schnittpunkten (Abb. 6.6b). Diese Art der Entfernungsmessung wurde aber bei der Endversion von MONALISA nicht eingesetzt, da es für den Betrachter auf den ersten Blick nicht logisch erscheinen mag. Wir betrachten exemplarisch den Fall Gleiter: Während des Fluges ist zwar seine Zellmasse kontinuierlich in Bewegung, jedoch verlagert sich seine cluster box nur in jedem zweiten Schritt. Bei der Entfernungsmessung (Abb. 6.6b) zwischen dem Gleiter und einem Stillebenmuster, würde sich deshalb die Entfernung nur in jedem zweiten Zeitpunkt verändern, obwohl der Gleiter in jedem Zeitschritt seinen Zellmassen-Schwerpunkt verlagert. Die Schwerpunktverlagerung wird in dem Fall vollkommen unberücksichtigt bleiben, wenn die Abstandslinien aus zwei Zeitschritten, sich vollständig überlagern (also die Schnittpunkte auf den beiden Rechtecken bleiben gleich), obwohl die eine Abstandslinie kürzer ist als die andere. Diese Problematik wird durch die eingesetzte Version gelöst, weil die Schwerpunktverlagerung miteinbezogen wird. Aber, wie in Abb. 6.6a zu sehen ist, liefert auch die eingesetzte Version nicht die exakte Entfernung, da diese stets um die Radien-Hälften reduziert werden, unabhängig von dem Neigungswinkel der Abstandslinie. Aber es wurde trotzdem für diese Variante entschieden, da sie selbst die minimale Bewegungsveränderung der einzelner Cluster zueinander, auf die Entfernungswerte abbildet, welche zur Berechnung der Annäherungstendenz wichtig sind, was letztlich auch auf die Kollisionswahrscheinlichkeitsberechnung erheblichen Einfluss hat. 123

130 Ein Spezialfall in der Entfernungsmessung stellt die Abb. 6.7 dar, wo ein Cluster innerhalb eines anderen vorkommt. Dieser Fall ist besonders problematisch, da die Abstandslinie hier einen Punkt im gemeinsamen Zentrum beider Cluster darstellt und somit einen Schnittpunkttest für beide der oben genannten Methoden scheitern lässt. Solche Fälle werden durch die Methode RectangularSape. intersects(rectangle2d r) ermittelt, und die Entfernung des Kollisionspaars wird auf 0 gesetzt. Die erfolgte Entfernungskorrektur wird auf die Tabelle Temp- Kollision angewandt und das Gesamtergebnis in die Tabelle Kollision verlagert. Nun gilt es in der Tabelle Kollision die Annäherungstendenz (Status) zwischen zwei Kollisionspaaren zu ermitteln, wofür aber Entfernungswerte von zwei Zeitpunkten vorliegen müssen: Abb. 6.7: Cluster in Cluster UPDATE Kollision SET Status = SWITCH ((Entfernung > AEntfernung AND AEntfernung <> -1), 'Wegbewegend', (Entfernung = AEntfernung AND AEntfernung <> -1), 'Stabil', (Entfernung < AEntfernung AND AEntfernung <> -1), 'Zubewegend', (AEntfernung = -1), 'In Beobachtung'); AEntfernung ist der Distanzwert zwischen zwei Clustern zum Zeitpunkt t 1 und Entfernung beinhaltet den Wert der aktuellen Zeit. Wenn zwei Cluster erst zum gegenwärtigen Zeitpunkt als Kollisionskandidaten identifiziert worden, dann liegt für den Zeitpunkt t 1 keine Entfernung vor ( -1 ), dementsprechend wird der Status als In Beobachtung angegeben. Die vergangene Tendenz lässt sich in LStatus und die vorletzte in VLStatus vorfinden, welche bei der Berechnung der Kollisionswahrscheinlichkeit einbezogen werden. Anspruchsvoller ist die Bestimmung einzelner Tendenzen vom Cluster innerhalb eines Kollisionspaars (Cluster A und B). Dazu werden Positionsdaten der beiden Cluster aus dem vergangenen und aktuellen Zeitpunkt benötigt. Die Idee ist, den Cluster B in seiner vergangenen Position (hypothetisch) verharren zu lassen und anhand der Positionsveränderung des Clusters A die entstandene Entfernungsdifferenz (Differenz der euklidischen Abstände) zu ermitteln, ob der Cluster A bzgl. des Clusters B zu-/wegbewegt hat oder eher stabil war. Nun kommen wir zur Wahrscheinlichkeitsberechnung einzelner Kollisionspaare, die in zwei Schritten erfolgt. Im ersten Schritt wird nur anhand der vorliegenden Entfernung eine Wahrscheinlichkeit zugewiesen. Die Zuweisung der Kollisionswahrscheinlichkeit wurde während der Entwicklungsphase mehrmals kalibriert, um die Genauigkeit der Prognose zu verbessern. Für den Gefahrenbereich fern wurde ein Wahrscheinlichkeitsintervall zwischen 15 und 35 Prozent anhand der Entfernungsabstufungen vergeben, analog für mittel zwischen 58% und 78%, ebenso für den Bereich nah Prozentwerte zwischen 89 und 98, wobei alle möglichen Entfernungsintervalle eingebunden werden müssen: 124