Content uploaded by Benjamin Aaron Degenhart
Author content
All content in this area was uploaded by Benjamin Aaron Degenhart on Feb 05, 2016
Content may be subject to copyright.
BACHELORARBEIT
Implementierungskonzepte f¨
ur Agenten in
Personenstromsimulationen
Effiziente Modellierung komplexer Charaktere
Autor: Benjamin Aaron Degenhart
Matrikel-Nr.: 00998412
Betreut durch: Prof. Dr. Gerta K¨
oster
Betreuer bei accu:rate: Florian Sesser
Fakult¨
at: Mathematik und Informatik
Studienrichtung: Scientific Computing
Abgabetermin: 11.1.2016
Zusammenfassung
Diese Arbeit untersucht verschiedene Implementierungskonzepte f¨
ur Agenten in
agentenbasierten Personenstromsimulationen. Der Fokus liegt dabei auf der effi-
zienten Modellierung komplexer Charaktere. Dazu werden vergleichbare Systeme
vorgestellt und auf deren L¨
osungen f¨
ur die Agenten-Implementierung eingegan-
gen. Unter Anderem wird auf die Software VADERE von der Forschungsgruppe
um Prof. K¨
oster eingegangen, besonders im Kontrast zur Software des Startup-
Unternehmens accu:rate. Letztere wird in der Implementierungsphase dieser Ar-
beit zum Hauptgegenstand. Aus Literaturrecherche relevant erscheinende Software
Design Patterns werden untersucht. Ihre Ausgestaltung im Kontext von Personen-
stromsimulationen werden in der Programmiersprache Java oder Scala interpre-
tiert. Diese Interpretationen werden jeweils mit UML-Diagramm und Ausz¨
ugen
des relevanten Codes vorgestellt und mit seinen Vor- und Nachteilen diskutiert.
In der Implementierungsphase werden die verschiedenen Ans¨
atze mit dem Anfor-
derungsprofil von accu:rate abgeglichen, um festzulegen was letztendlich Einzug
in das produktive System finden wird. Abschließend werden die Ergebnisse der
Implementierungsphase vorgestellt und hinsichtlich der Ziele diese Arbeit reflek-
tiert.
Abstract
This thesis is concerned with the investigation of different implementation con-
cepts for agents in agent-based pedestrian flow simulations. The focus is on the
efficient modelling of complex characters. For that purpose similar systems will
be presented with focus on their respective solutions for implementing agents.
Amongst others the software VADERE by the scientific team around Prof. K¨
oster
will be presented. In particular in contrast to the software of the start-up company
accu:rate. The latter will be the main subject in the implementation phase of this
thesis. Relevant software design patterns, suggested by literature, will be inves-
tigated. Their applied form in the context of pedestrian flow simulations will be
interpreted in the programming language Java or Scala. These interpretations will
be presented with UML diagrams and excerpts of relevant code. Their advantages
as well as disadvantages will be discussed. These approaches will be contrasted
with the requirement profile of accu:rate In the implementation phase. This will
determine which approach eventually makes it into their production system. In
conclusion the results of the implementation phase will be presented and reflected
in consideration of the goals of this thesis.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation................................ 1
1.2 Ziel.................................... 4
1.3 StandderTechnik ........................... 6
1.4 AufbaudieserArbeit .......................... 7
2 Methoden 8
2.1 Setup................................... 8
2.2 Vorgehen................................. 9
2.3 Workflow in der Implementierungsphase . . . . . . . . . . . . . . . 9
3 Ergebnisse 10
3.1 Einblick in bestehende Systeme . . . . . . . . . . . . . . . . . . . . 10
3.1.1 VADERE im Vergleich zu accu:rate . . . . . . . . . . . . . . 10
3.1.2 ECJ ............................... 11
3.2 Design Patterns f¨
ur agentenbasierte Personenstromsimulation . . . . 13
3.2.1 Funktionale Anforderungen an einen Ansatz . . . . . . . . . 14
3.2.2 Java ............................... 14
3.2.3 Scala............................... 32
3.3 Implementierung ............................ 38
4 Herausforderungen, Gelerntes und Ausblick 43
4.1 Herausforderungen bei der Implementierung . . . . . . . . . . . . . 44
4.2 Erkenntnisse............................... 44
4.3 Ausblick................................. 46
Literaturverzeichnis
1 Einleitung
1.1 Motivation
Simulation Der Begriff der Simulation hat eine lange kulturhistorische Ge-
schichte. So pr¨
agte bspw. bereits der r¨
omische Philosoph Lukrez im 1. Jahrhundert
v. Chr. den Begriff des „Simulacrums” (Latein f¨
ur Ab-, Spiegel- oder Scheinbild 1)
in seiner Wahrnehmungstheorie2.
Zeitgen¨
ossische Denker wie der 2007 verstorbene franz¨
osische Medientheoretiker
Jean Baudrillard greifen den Begriff auf. Er entwickelt in seinem Werk „Der sym-
bolische Tausch und der Tod” (Baudrillard [1982]) eine Simulationstheorie und
spricht darin von den „drei Ordnungen des Simulacrums”: „Nach dem Zeitalter
der ,Imitation’ und demjenigen der ,Produktion’ leben wir heute im Zeitalter der
,Simulation’ – einem gesellschaftlichen Zustand, in dem Zeichen und Wirklichkeit
zunehmend ununterscheidbar werden.”.
Auch der 1980 verstorbene franz¨
osische Philosoph Roland Barthes greift den Be-
griff in seinen Arbeiten im Bereich der strukturalistischen Semiotik auf:
Das Ziel jeder strukturalistischen T¨
atigkeit [...] besteht darin, ein ‘Objekt’ derart
zu rekonstituieren, daß in dieser Rekonstitution zutage tritt, nach welchen Regeln
es funktioniert (welches seine ‘Funktionen’ sind). Die Struktur ist in Wahrheit also
nur ein simulacrum des Objekts, aber ein gezieltes, ‘interessiertes’ Simulacrum, da
das imitierende Objekt etwas zum Vorschein bringt, das im nat¨
urlichen Objekt
unsichtbar oder, wenn man lieber will, unverst¨
andlich blieb.
Barthes [1966]Seiten 190-196 im ,Kursbuch’ vom 5. Mai 1966
1de.pons.com/%C3%BCbersetzung/latein-deutsch/simulacrum, Stand 9.1.2016.
2de.wikipedia.org/wiki/Lukrez#Philosophie, Stand: 1.1.2016
1
Um den Simulationsbegriff in den Kontext dieser Arbeit zu stellen, ziehe ich Ste-
phan Hartmann von der LMU mit seiner Arbeit „The World as a Process: Simu-
lations in the Natural and Social Sciences” heran:
Major parts of current research in the natural and social sciences can no longer be
imagined without simulations, especially those implemented on a computer, being
a most effective methodological tool. Hartmann [2005]
Hartmann definiert: „A simulation imitates one process by another process” und
schreibt:
One major advantage of simulations is that they allow scientists to explore the
detailed dynamics of a real process. In many cases it is not possible for pragmatic
reasons to extract this information experimentally: the relevant time scale turns
out to be either too large (e.g. for the evolution of galaxies) or too small (e.g. for
nuclear reactions). For this purpose, simulations are often the only appropriate tool
to learn something about a system’s timeevolution. Hartmann [2005]
Personenstromsimulation Heutzutage ist es ¨
ublich computergest¨
utzte Perso-
nenstromsimulationen zu nutzen, um Sicherheitskonzepte f¨
ur ¨
offentliche Geb¨
aude
und Pl¨
atze zu erstellen oder bestehende zu ¨
uberpr¨
ufen. So lassen sich menschliche
Katastrophen, wie sie die Historie etwa mit der Love Parade 2010 in Duisburg
kennt, in Zukunft vermeiden und Risiken besser einsch¨
atzen3. Daher ist es eine
verantwortungsbewusste Maßnahme, den Erstellungsprozess von Sicherheitskon-
zepten mit Ergebnisdaten von Simulationen zu unterf¨
uttern. Dabei k¨
onnen bspw.
Engstellen identifiziert werden und m¨
ogliche Varianten der Menschenflusssteue-
rung durchgespielt werden.
¨
Uber den Anwendungsfall der Entfluchtung hinaus gibt es diverse weitere Ein-
satzm¨
oglichkeiten f¨
ur Personenstromsimulationen. So k¨
onnten Beh¨
orden daran in-
teressiert sein, den Menschenfluss um Sehensw¨
urdigkeiten effektiv zu gestalten
oder Kaufh¨
auser k¨
onnten daran interessiert sein, den Kunden bestimmte Wege
durch das Kaufhaus planerisch subtil nahe zu legen.
Es liegt auf der Hand, dass Personenstromsimulationen nur dann sinnvoll sind,
wenn ihr Realit¨
atsbezug wissenschaftlich fundiert und zu einem gewissen Grad
3Siehe dazu bspw. die Analyse des Love Parade Disasters 2010 in Duisburg von Helbing et al.
Helbing u. Mukerji [2012]
2
intuitiv einleuchtend ist. Wie jede andere Simulation kann sich auch die Personen-
stromsimulation nur an die Realit¨
at ann¨
ahern, sie aber nie vollst¨
andig voraussagen.
Das Thema der Verkehrs- und Personenstromsimulation ist mittlerweile in der in-
ternationalen Forschung gut erfasst und hat sich zu einem wachsenden Gebiet in
der Physik, der Statistik und teilweise auch der Informatik entwickelt. Es finden
bereits regelm¨
aßig Konferenzen, wie etwas die „TGF: Traffic and Granular Flow”
(alle zwei Jahre, die n¨
achste wird 2017 vsl. in Washington, DC, USA stattfinden)
und die „PED: Pedestrian and Evacuation Dynamics” (alle zwei Jahre, die n¨
achste
wird 2016 in Hefei, China stattfinden) statt.
Charaktere Eine wichtige Stellschraube f¨
ur mehr Realismus ist die Abbildung
von Charakteren in den Modell-Agenten der Personenstromsimulation. Unter dem
Begriff Charakter ist in diesem Kontext das Verhalten im Bewegungsszenario zu
verstehen, so wie Eigenschaften wie Radius (ein Kreis mit Durchmesser der Schul-
terbreite) oder die freie Wunschgeschwindigkeit („free flow velocity”), die das Ver-
halten beeinflussen.
Jeder echte menschliche Charakter ist einzigartig. Fokussiert man allerdings auf
das Verhalten in Bewegungsszenarien, ist es plausibel verschiedene Typologien
anzulegen. Man denke bspw. an den langsamen Senioren, den energetischen un-
achtsamen Jugendlichen, den Gesch¨
aftsmann beim Telefonieren, die Schulklasse
oder den Rollstuhlfahrer mit oder ohne Begleitung. Neben diesen pers¨
onlichen
Merkmalen ist auch der Kontext des Bewegungsszenarios relevant. So wird es in
einem idyllischen Stadtpark sicherlich anders zugehen als in der U-Bahn in Beijing
oder einer Verkehrskreuzung in Indien ohne Ampeln. Der kulturelle Situationskon-
text setzen die Grundparameter f¨
ur eine Simulation, darauf aufbauend kommen
individuell parametrisierte Agenten.
Variation der Charaktere Um Variationen der Charaktere einzuf¨
uhren, bedarf
es zun¨
achst eines wissenschaftlich soliden Basismodells. Auf einige Grundeigen-
schaften und deren Modellierung hat sich die Wissenschaft mittlerweile geeinigt.
So wird bspw. von einer normalverteilten freien Wunschgeschwindigkeit um 1.34m
s
3
herum ausgegangen (Weidmann [1992]). Mit der Auswertung von empirischen Da-
ten haben sich u.a. Schadschneider u. Seyfried [2011] und Chattaraj u. a. [2009]
besch¨
aftigt und sog. Fundamentaldiagramme aus den erhobenen Daten erstellt.
Einen guten ¨
Uberblick zum Stand der Technik bez¨
uglich weiterer Grundeigen-
schaften ist bspw. in der Einleitung von von Sivers u. K¨
oster [2015] zu finden. Eine
Minimalvariation, die auf jeden Fall implementiert sein sollte, ist das zuf¨
allige
Ziehen aus der normalverteilten freien Wunschgeschwindigkeit f¨
ur jeden Agenten.
Andernfalls w¨
urden alle Agenten mit der gleichen Geschwindigkeit laufen, was zu
unrealistischen Synchronisierungseffekten f¨
uhren w¨
urde. Dar¨
uber hinaus ist es eine
Frage des simulierten Szenarios welche weiteren subtilen oder gr¨
oßeren Variatio-
nen eingef¨
uhrt werden k¨
onnten bzw. sollten. Ein wichtiger Verhaltenstyp ist die
Zugeh¨
origkeit zu einer Gruppe. Die Implementierungsherausforderung dabei ist,
ein weiteres Element hinzuzuf¨
ugen, das die individuelle Dynamik beinflusst. Es ist
nicht mehr nur „ich und mein Weg zum Ziel”, sondern es gilt „ich in meiner Grup-
pe auf dem Weg zum Ziel”. Je nach Implementierungskonzept kann es durchaus
eine Herausforderung sein, solche Flexibilit¨
atsanforderungen an Agenten im Code
sinnvoll abzubilden.
1.2 Ziel
Im Rahmen dieser Bachelorarbeit untersuche ich verschiedene Implementierungs-
konzepte von Charakteren und setze meine Ergebnisse im Code des Simulators des
Unternehmens accu:rate um. Dazu untersuche und vergleiche ich verschiedene prin-
zipielle Ans¨
atze, inklusive des Ansatzes in VADERE, der von der Forschungsgruppe
um Prof. K¨
oster an der Hochschule M¨
unchen entwickelten Software. Im Anschluss
reflektiere ich die Ans¨
atze vor den im Folgenden definierten Anforderungen, die
accu:rate stellt, treffe eine informierte Entscheidung ¨
uber das beste Konzept und
setze dieses im Simulator von accu:rate um. Dort soll es einen deutlichen Mehr-
wert gegen¨
uber dem aktuellen Stand bringen und das Agenten-Erzeugende System
flexibler im Erstellen von neuen Agenten-Typen und damit zukunftssicherer ma-
chen.
4
Anforderungen von accu:rate
Die von accu:rate definierten Anforderungen an ihren Code, und damit auch f¨
ur
das Untersystem der Agenten-Erzeugung, mit dem ich mich besch¨
aftige, sind Fol-
gende:
•flexibel
•modular
•performant
•typsicher
•simpel, f¨
uhrt zu h¨
oherer Zuverl¨
assigkeit und Agilit¨
at
•Korrektheit, Fehlerquellen minimieren
•Unit-Tests schreiben und bestehende bestehen
Der Punkt modular wird f¨
ur die Agenten-Erzeugung wie folgt n¨
aher spezifiziert.
Die Charaktereigenschaften sollen m¨
oglichst zur Laufzeit rekombinierbar sein. So
soll es bspw. m¨
oglich sein, einen Rollstuhlfahrer mit niedrigerer Wunschgeschwin-
digkeit und h¨
oherem Torso-Radius mitsamt einer Begleitperson einer Gruppe hin-
zuf¨
ugen zu k¨
onnen. Um den Punkt Korrektheit zu verdeutlichen, soll folgendes
Zitat nicht unerw¨
ahnt bleiben:
Debugging is twice as hard as writing the code in the first place. Therefore, if you
write the code as cleverly as possible, you are, by definition, not smart enough to
debug it.4
4Brian W. Kernighan and P. J. Plauger in „The Elements of Programming Style”
5
1.3 Stand der Technik
Es gibt mittlerweile mehrere wissenschaftliche und kommerzielle Softwarepakete
zur Verkehrs- und Personenstromsimulation. Es folgt ein kurzer ¨
Uberblick ¨
uber
die beiden Systeme, die mich in dieser Arbeit besch¨
aftigen werden, und ein weite-
res System.
VADERE ist eine Personenstromsimulationssoftware, die die Forschungs-
gruppe um Prof. K¨
oster an der Hochschule f¨
ur Angewandte Wissenschaften M¨
unchen
entwickelt. Es wurde teilweise im Kontext des MultikOSi Projekt entwickelt, ein
gemeinsames Forschungsprojekt zu urbaner Sicherheit an großen st¨
adtischen Er-
eignissen, das von Bundesministerium f¨
ur Bildung und Forschung finanziert wurde.
Neben der Forschungsarbeit nutzt Prof. K¨
oster die Software auch in ihren Vorlesun-
gen und Seminaren, damit Studierende damit arbeiten k¨
onnen. Beispielsweise hat
sich das Modellierungsseminar unter ihrer Leitung dieses Semester (WS2015/16)
damit besch¨
aftigt, wie die 2D-Ergebnisse von VADERE in 3D dargestellt werden
k¨
onnen.
Dr. Angelika Kneidl von accu:rate hat 2013 eine Doktorarbeit mit dem Titel
„Methoden zur Abbildung menschlichen Navigationsverhaltens bei der Modellie-
rung von Fußg¨
angerstr¨
omen” (Kneidl [2013]) geschrieben. Die darin entwickelte
Software ist zur Grundlage des Startup-Unternehmens accu:rate geworden und ist
im Gegensatz zu VADERE agentenbasiert, wie sich sp¨
ater zeigen wird.
ECJ ist ein „Evolutionary Computation Research System” von Sean Luke et
al., „that supports a variety of evolutionary computation techniques, such as gene-
tic algorithms, evolution strategies, particle swarm optimization [...]”5. Im Kontext
dieser Arbeit ist interessant, dass „it was designed to be highly flexible, with near-
ly all classes (and all of their settings) dynamically determined at runtime by
a user-provided parameter file”6. Ein durchaus interessanter Ansatz um komple-
xe Agenten-Charaktere zu modellieren. In 3.1.2 wird dieser runtime-Mechanismus
genauer diskutiert.
5en.wikipedia.org/wiki/Java_Evolutionary_Computation_Toolkit, Stand 6.1.2016
6ECJ 23 is a Java-based Evolutionary Computation Research System, cs.gmu.edu/˜eclab/
projects/ecj/, Stand 2.1.2016
6
1.4 Aufbau dieser Arbeit
Im folgenden Kapitel Methoden erl¨
autere ich mein Vorgehen und die verwende-
ten Tools und Workflows im Rahmen dieser Bachelorarbeit.
Im Kapitel Ergebnisse stelle ich die Ergebnisse der im Kapitel Methoden geschil-
derten Vorgehensweise vor und zu welchen Implementierungsergebnissen im Code
von accu:rate dies letztendlich gef¨
uhrt hat.
Im Kapitel Herausforderungen, Gelerntes und Ausblick fasse ich zusammen,
was ich in dieser Arbeit erreicht habe. Abschließend ein Ausblick im Sinne von
m¨
oglichen n¨
achsten Schritten.
7
2 Methoden
2.1 Setup
Hardware und Betriebssysteme
Im Rahmen dieser Arbeit habe ich auf meinem station¨
aren Mac mini mit OS
X El Capitan gearbeitet. Auf selbigem ist ein virtuelles Windows 10 Be-
triebssystem installiert. Neben dem station¨
aren Rechner habe ich einen Lenovo
ThinkPad Laptop in Betrieb, ebenfalls mit Windows 10.
Software
Die beiden Windows Betriebssysteme hatte ich in Verwendung, um mit TeX-
nicCenter diese Arbeit zu kompilieren und um mit Microsoft Viso 2013 die
UML-Graphiken f¨
ur Kapitel 3 zu erstellen. Die Code-Beispiele in Kapitel 3 habe
ich in Eclipse in Java 8 und Scala 2.11 entwickelt.
Zum Editieren der .tex und .bib Dateien als auch der Code-Beispiele verwendete
ich gr¨
oßtenteils den Editor Atom. Sowohl die Software von accu:rate als auch VA-
DERE sind vollst¨
andig in Java programmiert und werden mittels der verteilten
Versionskontrollsystems Git verwaltet und versioniert.
8
2.2 Vorgehen
Eine Umstellung der Software-Architektur zur Erzeugung der Agenten kann kom-
plexe und schwer ¨
uberschaubare Implikationen haben. Daher stellte sich als sinn-
vollstes Vorgehen heraus, kleine ¨
uberschaubare Beispiele f¨
ur verschiedene Design
Patterns zu entwickeln. Anhand dieser Beispiele konnten die Implikationen bes-
ser eingesch¨
atzt werden. Welche Design Patterns dabei ausgew¨
ahlt wurden, ergab
sich aus Internetrecherchen, der Lekt¨
ure von Gamma u. a. [1995] und Bloch [2008],
sowie aus Diskussionen mit Florian Sesser. Zu den beispielhaft dargestellten Im-
plementierungskonzepten des jeweiligen Design Patterns im Kontext von agenten-
basierter Personenstromsimulationen stelle ich Vor- und Nachteile zusammen.
2.3 Workflow in der Implementierungsphase
accu:rate verwendet private GitHub-Repositories in Kombination mit einem Team-
City Continuous Integration Server, um ihren Produktions- und Entwicklungscode
zu verwalten. Generall halten sie sich an das „NVie Branching Model”1.
Mir wurde Lese-Zugriff auf das kernel und postvis Repository gew¨
ahrt. Ich habe
in meinem GitHub-Account eine private Kopie des kernel Repository erstellt (fork),
bei der ich Schreibrechte habe. Unser Workflow w¨
ahrend der Implementierungs-
phase bestand darin, dass ich Pull Requests von verschiedenen Feature-Branches
aus an den kernel/develop branch gestellt habe. Florian Sesser hat diese dann
reviewed, u.U. ¨
Anderungen vorgeschlagen und dann bei Zufriedenheit in ihren de-
velop branch integriert (merge).
Ein neuer Pull Request baut auf den Vorherigen auf, um nicht auf das Review-
Feedback und den Merge warten zu m¨
ussen. Um nicht auf das Review-Feedback
und den Merge warten zu m¨
ussen, habe ich meine Pull Requests aufeinander auf-
bauen lassen, d.h. ein neuer baut auf dem u.U. noch nicht gemergeten vorherigen
auf.
1nvie.com/posts/a-successful-git-branching-model/, Stand 6.1.2016
9
3 Ergebnisse
3.1 Einblick in bestehende Systeme
3.1.1 VADERE im Vergleich zu accu:rate
VADERE ist konzipiert als „[framework] for researching pedestrian crowd simu-
lation models” Seitz [2016]. Als solches w¨
are die Entscheidung agentenbasiert zu
modellieren, laut Seitz, ein Einschnitt in die Freiheit der Simulationsmodelle, die
es beherbergen kann:
The imposed structure [of an agent-based software] may impede the implementation
of models that do not naturally fit into the concept of agent-based modelling, such
as models based on ordinary differential equations. Seitz [2016]
Es steht den Simulationsmodellen allerdings frei agentenbasierte Strukturen zu de-
finieren: „Agent-based structures can still be defined, offered, and used within it
but must not be a requirement.” Seitz [2016].
Dementsprechend minimal implementiert ist der Default-Agent der in allen Simu-
lationen vorkommt, er ist lediglich eine „Marionette” auf der Simulationsfl¨
ache,
wenn er nicht mit weiteren Kompetenzen ausgestattet wird. Um ihm im Sinne
einer agentenbasierten Simulation mehr Verantwortung zu ¨
ubertragen, muss er er-
weitert werden. Das ist bspw. im Optimal Steps Model der Fall. Dort erweitert
der PedestrianOSM den default Pedestrian mit Methoden wie updateNextPosi
tion() und makeStep(), also „state-changing”-Methoden, wie sie bewusst nicht
im default Pedestrian vorkommen.
Um den aktiv geschalteten mathematischen Modellen die M¨
oglichkeit zu geben in
10
die Simulation einzugreifen, werden ActiveCallback Aufrufe in jedem Schritt an
jedes aktive Modell gemacht.
Vergleich Die Software von accu:rate ist strikt agentenbasiert aufgebaut und
gibt damit dem einzelnen Agenten die Verantwortung seinen Status in der Simu-
lation selbst zu verwalten und zu ver¨
andern. Der Unterschied zu VADERE wird
deutlich, wenn man sich anschaut, wie der Anwendungsfall Gruppen in beiden
Systemen implementiert ist. In der agentenbasierten Struktur von accu:rate ist
dazu ein Group Objekt n¨
otig, das seine Mitgliedern vom Typ GroupPedestrian
zusammen h¨
alt. Die Simulation l¨
auft durch und gibt in jedem Simulationsschritt
jedem Agenten die M¨
oglichkeit ¨
uber den n¨
achsten Bewegungsschritt „nachzuden-
ken” und diesen auszuf¨
uhren. Im „Nachdenken” kommt der Charakter des Agenten
zum Tragen. Bei VADERE hingegen erf¨
ahrt der Pedestrian keinerlei ¨
Anderung
oder Erweiterung. Statt dessen wird ein mathematisches Modell, eingesetzt um
Anziehungs- und Abstoßungs-„kr¨
afte” (damit sind nicht rein physikalischen Kr¨
afte
gemeint) um ein Gruppenmitglied herum so anzupassen, dass sich in Folge ein
gruppenzugeh¨
origes Verhalten einstellt.
3.1.2 ECJ
ECJ (Evolutionary Computation Research System) ist dem Simulator von ac-
cu:rate und VADERE nicht so ¨
ahnlich, als dass ein direkter Vergleich Sinn ma-
chen w¨
urde. Es soll hier dennoch vorgestellt werden, da es einen f¨
ur diese Arbeit
interessanten Mechanismus hat, Klassen erst zur Runtime zu instantiieren. Dieser
Mechanismus f¨
uhrt zu einer hohen Flexibilit¨
at bei der Kombination von Klassen.
Im Folgenden ein kurzer Einblick in die Architektur von ECJ.
Die zentrale Klasse ist Evolve.java, sie beinhaltet die main Methode, die von
jedem evolutionary computation Szenario aufgerufen wird, das man mit ECJ laufen
lassen kann. Als Argument erwartet diese Methode zumindest den Pfad zu einer
11
.params Datei, die sie importiert und intern als ParameterDatabase vorh¨
alt. Eine
Zeile in einer Parameterdatei sieht typischerweise so aus:
name = value
ParameterDatabase erweitert Java’s native Klasse java.util.Properties mit
Features wie der M¨
oglichkeit Parameter-Dateien voneinander erben zu lassen (da-
bei ¨
uberschreibt die Kind-Datei Parameter mit identischem Namen der Eltern-
Datei). Zudem organisiert sie Parameter in einem „traversable tree”, der ¨
uber
Pfadmarkierungen verf¨
ugt. Diese zeigen an, ob ein Pfad bereits durchsucht wurde.
Die folgenden vier Parameter-Typen sind m¨
oglich:
•Numbers
•Strings (trimmed of whitespace)
•Booleans
•Class Names (full class name including the package)
Nach dem Import werden die Parameter in einem HashTable abgelegt, der in der
Superklasse java.util.Properties bereit steht. ParameterDatabase erweitert
die Parameter dabei mit Markierungen, die anzeigen, ob bereits auf sie zugegriffen
wurde. Die verschiedenen Getter k¨
onnen zum Teil default-Werte zur¨
uckgeben, falls
ein Parameter nicht gefunden wurde und k¨
onnen instantiierte Klassen zur¨
uckgeben
basierend auf einem Klassennamen (runtime instantiation).
Eine weitere Besonderheit der ParameterDatabase sind Namespace Hierachies.
Wenn wir bspw. eine Klasse init in der .params Datei definiert haben...
init = mypackage.MyInitializer
... k¨
onnen wir Parameter setzen, die nur f¨
ur den Namespace dieser Klasse gelten:
init.myboolean = true
init.someSubclass = mypackage.MyInitSubclass
12
setup(...) ist die zentrale Methode, um Klassen zur Runtime zu instantiieren,
basierend auf ihrem Namen und ihren zugeh¨
origen Parametern in der ParameterDa
tabase. Anstatt Konstruktoren zu verwenden, folgt ECJ hier dem Design Pattern
Factory Method, wie es bspw. in Gamma u. a. [1995] dargestellt ist. Dieses Vorgehen
wird von Bloch in Item 1 „Consider static factory methods instead of constructors”
Bloch [2008] ausdr¨
ucklich ermutigt. 1
3.2 Design Patterns f¨
ur agentenbasierte
Personenstromsimulation
Wie in 2.2 erl¨
autert, werden kleine Beispiele f¨
ur verschiedene Design Patterns ent-
wickelt, um die Implikationen einer Umstellung der Agenten Erzeugung besser
einsch¨
atzen zu k¨
onnen. Die Beispiele sind ¨
uberschaubar gehalten, um die jeweilige
Architektur im Fokus zu haben. Sie erheben allerdings keinen Anspruch darauf
die einzig m¨
ogliche Interpretation des jeweiligen Design Patterns im Kontext von
agentenbasierten Personenstromsimulationen zu sein. Hinsichtlich der Program-
miersprachen kommt neben Java noch Scala zur Verwendung. Mehr zu Scala unter
3.2.3.
F¨
ur den n¨
achsten Abschnitt, definiere ich knapp mein Vorgehen. Zun¨
achst scheint
es sinnvoll, die funktionalen Anforderungen an einen Ansatz zu definieren, anschlie-
ßend die Ans¨
atze, die im Rahmen dieser Arbeit untersucht werden vorzustellen.
Jeder Ansatz endet mit einer Diskussion, in der auf dessen Vor- und Nachteile ein-
gegangen wird und wie er abschneidet, hinsichtlich der generellen Anforderungen
von accu:rate wie unter 1.2 gelistet und den im Folgenden definierten funktionalen
Anforderungen.
1Mehr Informationen zum Aufbau von ECJ sind unter Luke [2015] zu finden.
13
3.2.1 Funktionale Anforderungen an einen Ansatz
Wie sich schnell gezeigt hat, muss ein Implementierungskonzept zur flexiblen Charakter-
Erzeugung in agentenbasierten Personenstromsimulationen mindestens folgende
vier konzeptionelle Aufgaben erf¨
ullen k¨
onnen:
1. Einmaliges ¨
Andern von Klassenvariablen bei Initialisierung: ein Fast-
Pedestrian hat eine h¨
ohere freeFlowVelocity als der DefaultPedestrian.
2. ¨
Uberschreiben von Methoden, die jeder Pedestrian hat: der GroupPe-
destrian muss in jedem move() Aufruf schauen, wie es um seine Position
innerhalb seiner Gruppe steht.
3. Hinzuf¨
ugen neuer Methoden: der WheelchairPedestrian braucht Metho-
den wie searchForElevator() die u.U. keinen Sinn machen w¨
urde in das
Basis-Repertoire an Methoden aufzunehmen.
4. Hinzuf¨
ugen neuer Steuerungselemente: alle GroupPedestrian-Mitglieder
einer Gruppe referenzieren das gleiche Group Objekt und werden von diesem
kontrolliert.
5. Als Folge von 3. und 4. ¨
andern sich u.U. die Art der Aufrufe die das ¨
ubergeordnete
System auf dem Agenten-System ausf¨
uhrt: die Hauptsimulationsklasse un-
terscheidet bei der Erzeugung der Pedestrians bspw. ob es sich um GroupPe
destrians handelt oder nicht, diese m¨
ussen n¨
amlich anders erzeugt werden
(u.U. kein eigenes brain, geteiltes group Objekt). Falls solche ¨
Anderungen
(Unterscheidungsf¨
alle) im ¨
ubergeordneten System nicht vermieden werden
k¨
onnen, sollten sie zumindest minimal bleiben.
3.2.2 Java
Einfache Vererbung
Eine der einfachsten Varianten um verschiedene Charaktere in agentenbasierten
Personenstromsimulationen zu realisieren ist die einfache Vererbung.
14
Ein Pedestrian beinhaltet alle Klassenvariablen und Methoden, die jeder Fußg¨
anger-
Typ ben¨
otigt. Um weitere Fußg¨
anger-Typen zu realisieren, wird je eine neue Klasse
geschrieben, die den Basistyp erweitert.
Das folgende UML-Diagramm zeigt neben dem Pedestrian einen WheelchairPe
destrian und einen FastPedestrian. Die darauf folgende Implementierung greift
zwei davon auf.
Pedestrian
-freeFlowVeloc
-radius
+move()
WheelchairPedestrian
+move()
FastPedestrian
+move()
Abb. 3.1: Einfache Vererbung
Pedestrian fastPed = new WheelchairPedestrian();
fastPed.move();
-------------------------------
public class Pedestrian {
protected double freeFlowVeloc = 1.3;
protected double radius = 0.25;
public void move() {
//...
}
}
-------------------------------
public class WheelchairPedestrian extends Pedestrian {
public WheelchairPedestrian(){
freeFlowVeloc = 0.6;
radius = 0.4;
15
}
@Override
public void move() {
//...
}
}
Diskussion Ein Vorteil ist sicherlich die Einfachheit dieses Ansatzes. Als großer
Nachteil ist die mangelnde Kombinierbarkeit von Charaktereigenschaften zu nen-
nen. F¨
ur jeden neuen Agenten-Typ muss eine neue Klasse geschrieben werden, die
den Pedestrian erweitert. Eine Verbesserung w¨
are den Pedestrian abstract und
damit nicht instanziierbar zu machen, dadurch k¨
onnte er Methoden-Signaturen
beinhalten, die Klassen implementieren m¨
ussten, die ihn erweitern. Hinsichtlich
der generellen und funktionalen Anforderungen ist zu sagen, dass Typsicherheit
klar gegeben ist und aufgrund der (maximalen) Einfachheit dieser Ansatz auch
zuverl¨
assig und agil ist. Bei den Punkten Modularit¨
at und Flexiblit¨
at schneidet die
einfache Vererbung dahingegen schlecht ab, da f¨
ur jeden neuen Typ eine eigene
Klasse geschrieben werden muss. Auch Punkt 5der funktionalen Anforderungen
kommt voll zu tragen. Neue Methoden und Steuerungselemente m¨
ussen u.U. ¨
uber
das Agenten-erzeugende System hinaus verankert werden.
Observer Pattern
Das Observer Pattern (Beobachtermuster) geh¨
ort zur Kategorie der Verhaltens-
muster in Gamma u. a. [1995]. Verhaltensmuster „sind Entwurfsmuster, die kom-
plexes Verhalten der Software modellieren. Auf diese Weise wird die Flexibilit¨
at
der Software hinsichtlich ihres Verhaltens erh¨
oht.”2
In unserem Kontext w¨
are die Idee, dass Agenten als Observable (oft auch “Subjekt”
genannt) von Observers beobachtet werden. Jeder dieser Observer ist in unserem
Fall eine Charaktereigenschaft. Beim Erstellen der Observer hat jeder eine Chance
2de.wikipedia.org/wiki/Verhaltensmuster_(Software), Stand 5.1.2016
16
die Klassenvariablen seines Agenten einmalig zu ver¨
andern. Wenn die Simulation
l¨
auft, wird in jedem Simulationsschritt jeder Observer jedes Agenten aufgerufen,
um ihm die Chance zu geben, den Zustand seines Agenten basierend auf seinem
aktuellen Stand zu ver¨
andern. Im folgenden UML-Diagramm wird einem Pedestri
an ein WheelchairObserver und ein FastObserver hinzugef¨
ugt. In der folgenden
Implementierung wird gezeigt, wie der WheelchairObserver die statischen Klassen-
variablen des Pedestrian ver¨
andert und den Zustand reachedStairs ¨
uberwacht.
Tritt dieser ein, wird die Suche nach einem Aufzug aktiviert.
Pedestrian
- freeFlowVeloc: double
- radius: double
- sightradius: double
- reachedSt airs: boolean
+move()
Observable
- obs: Vector
- hasChanged: boolean
+ addObserver(o :Observer)
+ setChanged()
+ notifyObservers(obj :Object)
+ notifyObservers()
...
<<interface>>
Observer
+ update(o :Observable, arg :Object)
FastObserver
+ FastObserver(ped: Pedestrian)
+ update(ped :Observable, arg :Object)
WheelchairObserver
+ WheelchairObserver(ped: Pedestrian)
+ update(ped :Observable, arg :Object)
*
Abb. 3.2: Observer Pattern
Pedestrian ped = new Pedestrian();
ped.addObserver(new WheelchairObserver(ped));
ped.move();
ped.reachedStairs = true;// change in state
-------------------------------
public class Pedestrian extends Observable {
public double freeFlowVeloc = 1.3;
public double radius = 0.25;
17
public boolean reachedStairs = false;
public void move() {
setChanged();
notifyObservers(); // passes [this] to update of Observers, optionally add
Object arg
}
}
-------------------------------
public class WheelchairObserver implements Observer {
public WheelchairObserver(Pedestrian ped){
ped.freeFlowVeloc = 0.6;
ped.radius = 0.4;
}
@Override
public void update(Observable ped, Object arg) {
if(((Pedestrian) ped).reachedStairs) {
// activate search for elevator...
}
}
}
Diskussion Ein Vorteil des Observer Pattern ist, dass es durch die in der Java
Standard Library verf¨
ugbare Observable Klasse gut unterst¨
utzt ist.
Wie sp¨
ater auch das State Pattern in 3.2.2 k¨
onnte es sinnvoller sein, einzelne Ver-
haltensweisen als einzelne Observer abzubilden anstatt ganze Charaktere, dann
w¨
urde es auch seiner Kategorie der Verhaltensmuster gerecht werden. Der Nach-
teil von diesem und ¨
ahnlichen Ans¨
atzen, in denen in jedem move() Schritt in
einer Schleife durch alle registrierten Charakatere bzw. Charaktereigenschaften
gegangen wird, ist m¨
oglicherweise ein hoher Abfrage-Aufwand f¨
ur nur selten zum
Tragen kommende F¨
alle. Gibt es bspw. nur eine Treppe in der Simulation, wird
eine Abfrage wie checkStairsReached() in den allermeisten F¨
allen “umsonst”
aufgerufen. Bez¨
uglich der generellen Anforderungen ist zu sagen, dass dieser
Ansatz die Punkte modular und flexibel erf¨
ullt, jedoch bei performant fragw¨
urdig
18
bleibt. Um gesichterte Aussagen ¨
uber Performance machen zu k¨
onnen, m¨
ussten
vergleichende Messungen gemacht werden, dies ist im Rahmen dieser Arbeit nicht
erfolgt. Zu den funktionalen Anforderungen ist zu sagen, dass eine aufw¨
andige
Verankerung im dar¨
uberliegenden System (Punkt 5) durch abgekapselte interne
Methoden-Aufrufe, die ein Observer vollziehen kann bei einem update() Aufruf
gut verhindert werden kann.
Decorator Pattern
Das Dekorierer Entwurfsmuster geh¨
ort zur Kategorie der Strukturmuster in Gam-
ma u. a. [1995]. Strukturmuster sind „Entwurfsmuster, die durch Herstellen von
Beziehungen zwischen Entit¨
aten den Entwurf der Software erleichtern.”3
Es eignet sich dazu, Klassen mit Funktionalit¨
aten auszustatten (zu „dekorieren”).
Es gibt einen Kern, im Beispiel hier DefaultPedestrian, der ebenso wie alle De-
corator das Pedestrian Interface implementiert. Im Konstruktor jedes Decorators
wird ein das Pedestrian Interface implementierende Objekt abgespeichert, um dar-
auf per super Methoden weiterzureichen. Dadurch ist es bei der Erzeugung eines
Agenten m¨
oglich, beliebig viele Decorator-Schichten um den Kern herum zu “le-
gen”:
Pedestrian decoratedPed =
new VisionImpairedDecorator(new WheelchairDecorator(new DefaultPedestrian()));
Werden sp¨
ater auf decoratedPed die im Interface definierten Methoden aufge-
rufen, kann jede „Decorator-Schicht” intervenieren, bevor sie den Aufruf an die
n¨
achsth¨
ohere Schicht weiterreicht. Bis der Aufruf schließlich im Kern, im Default
Pedestrian landet. Es w¨
are m¨
oglich, jeden Decorator direkt das Pedestrian in-
terface implementieren zu lassen, doch zeigen die Beispiel u.a. in Gamma u. a.
[1995], dass es Sinn macht einen „Chef-Decorator” einzuf¨
uhren, den alle Decorator
erweitern, hier im Beispiel ist das der PedestrianDecorator. Dadurch muss die
u.U. große Zahl an Gettern und Settern zumindest nicht mehr in jedem einzelnen
Decorator implementiert werden.
3de.wikipedia.org/wiki/Strukturmuster, Stand 5.1.2016
19
DefaultPedestrian
- freeFlowVeloc: double
- radius: double
- reachedSt airs: boolean
+ move()
[...] getters a nd setters for class variables
PedestrianDecorator
- pedToBeDe corated: Pedestrian
+ PedestrianDecorator(pedToBeDecorated :Pedestrian)
+ move()
[...] getters and se tters for class variables
FastDecorator
+FastDecorator(pedToBeDecorated: Pedestrian)
+ move()
WheelchairDecorator
+WheelchairDecorator(pedToBeDe corated: Pedestrian)
+ move()
- searchForElevator()
<<Interface>>
Pedestrian
+ move()
[...] getters and setters for class variables
Abb. 3.3: Decorator Pattern
Pedestrian ped = new WheelchairDecorator(new DefaultPedestrian());
ped.move();
ped.setReachedStairs(true); // new situation in environment
ped.move(); // searchForElevator() will be triggered
-------------------------------
public interface Pedestrian {
void move();
// [...] getters and setters for class variables
}
-------------------------------
public class DefaultPedestrian implements Pedestrian {
private double freeFlowVeloc = 1.3;
private double radius = 0.25;
private boolean reachedStairs = false;
20
@Override
public void move() {/* ... */}
// [...] @Override getters and setters for class variables
}
-------------------------------
public abstract class PedestrianDecorator implements Pedestrian {
protected Pedestrian pedToBeDecorated;
public PedestrianDecorator(Pedestrian pedToBeDecorated){
this.pedToBeDecorated = pedToBeDecorated;
}
@Override
public void move() { pedToBeDecorated.move(); }
// [...] @Override getters and setters for class variables
}
-------------------------------
public class WheelchairDecorator extends PedestrianDecorator {
public WheelchairDecorator(Pedestrian pedToBeDecorated) {
super(pedToBeDecorated); super.setFreeFlowVeloc(0.6); super.setRadius(0.4);
}
@Override
public void move() {
if(super.getReachedStairs())
searchForElevator();
super.move();
}
private void searchForElevator() {/* ... */}
}
Diskussion Der Vorteil bei diesem Entwurfsmuster ist, dass dank des schicht-
artigen modularen Aufbaus beliebig Charaktereigenschaften kombiniert werden
k¨
onnen, ohne neue Klassen schreiben zu m¨
ussen. Zudem braucht man keine Schlei-
fe wie es bspw. beim Observer Pattern n¨
otig war, um alle Observer nach “ihrer
Meinung” zu fragen, der Aufruf wird automatisch durchgereicht. Ein Nachteil
21
ist der große Bedarf an Settern und Gettern. Pro Klassenvariable im Default
Pedestrian werden zwei Methoden im Interface ben¨
otigt die dementsprechend
ausimplementiert werden m¨
ussen im DefaultPedestrian und PedestrianDecora
tor. Man k¨
onnte eine einzige Methode setParams anlegen und null verwenden
bei Parametern, die nicht ¨
uberschrieben werden sollen, aber das h¨
atte eine sehr
lange Methodensignatur zur Folge. Beim Observer Pattern kann dieses Problem
umgangen werden, da der Pedestrian in jedem Observer-Konstruktor mitgereicht
werden und dort ver¨
andert werden kann. Im Decorator Pattern ist diese L¨
osung
nicht m¨
oglich, da in den Decorator-Konstruktoren nur das Interface, nicht jedoch
der implementierte Basis-Pedestrian mitgegeben werden kann. Ein Umweg w¨
are
eine getCorePedestrian() Methode, die jeder Decorator-Schicht direkten Zugriff
auf den Basis-Pedestrian gibt und seine Klassenvariablen ohne Setter ver¨
andern
kann. Das l¨
auft allerdings der Idee entgegen nur ¨
uber das Interface das Dekorieren
vorzunehmen. Bez¨
uglich der Anforderungen ist zu sagen, dass auch hier mo-
dular und flexibel gut abschneiden. Beim Punkt Korrektheit ist vorstellbar, dass
die Fehlersuche m¨
uhsam werden k¨
onnte, weil man u.U. den Fehler in den vielen
„Schichten” um den Kern-Pedestrian herum nicht leicht lokalisieren kann. Vom
funktionalen Aspekt aus kann man hier, wie auch bereits beim Observer Pattern,
durch effektive Kapselung zus¨
atzlicher Methoden und Steuerungselemente einen
Komplexit¨
atszuwachs im umliegenden System verhindern. Ein Decorator kann ja
in der Implementierung der move() Methode beliebig interne Methodenaufrufe
t¨
atigen, bevor der Aufruf weitergereicht wird.
State Pattern
Das Zustandsmuster geh¨
ort zur Kategorie der Verhaltensmuster und wird „zur
Kapselung unterschiedlicher, zustandsabh¨
angiger Verhaltensweisen eines Objektes
eingesetzt” Gamma u. a. [1995]. Im UML-Diagramm 3.4 und der folgenden Imple-
mentation wird ein Agent demonstriert, der seinen inneren Zustand aufgrund einer
neuen Situation in seiner Umgebung ¨
andert: er erreicht Treppenstufen und sucht
daraufhin einen Aufzug. Denkbar w¨
are auch in einen gestressten Modus zu wech-
seln, wenn die Fußg¨
angerdichte um einen herum einen Schwellenwert ¨
ubersteigt.
22
Dieser innere Zustandswechsel ist nach außen hin nicht sichtbar („weggekapselt”),
auf dem gleichen Pedestrian wird weiterhin move() aufgerufen.
Pedestrian
- currentState: State
- reachedSt airs: boolean
+ move()
DefaultState
+ move()
<<Interface>>
State
+ move()
ElevatorSearchState
+ move()
Abb. 3.4: State Pattern
Pedestrian ped = new Pedestrian();
ped.move(); // DefaultState is active
ped.reachedStairs = true;// new situation in environment
ped.move(); // ElevatorSearchState is active
-------------------------------
interface State {
void move(Pedestrian ped);
}
-------------------------------
class Pedestrian {
private State currentState;
protected boolean reachedStairs = false;
public Pedestrian() {
currentState = new DefaultState();
}
public void move(){
if(reachedStairs)
currentState = new ElevatorSearchState();
currentState.move(this);
23
}
}
-------------------------------
class DefaultState implements State {
@Override
public void move(Pedestrian ped) {/* ... */}
}
-------------------------------
class ElevatorSearchState implements State {
@Override
public void move(Pedestrian ped) {/* ... */}
}
Das Strategy Pattern4ist eng verwandt mit dem State Patten. Es funktioniert
genauso, mit dem Unterschied, dass die Ver¨
anderung des Zustandes nicht versteckt
im Inneren passiert, sondern von außen ausgef¨
uhrt wird. Es wird ¨
ublicherweise
eingesetzt, um Algorithmen auszutauschen.
Diskussion Im Kontext von agentenbasierter Personenstromsimulation w¨
urde
es nur bedingt Sinn machen, ganze Agenten-Typen als States zu interpretieren, da
ein Agent seinen Typ w¨
ahrend einer Simulation nicht ¨
andert. W¨
urde man das State
Pattern dennoch als Hauptstruktur einf¨
uhren, um verschiedene Agenten-Typen zu
modellieren, m¨
usste ein Mechanismus gefunden werden, um die einmaligen sta-
tischen Ver¨
anderungen am Anfang abzubilden. Ein Array von availableStates
w¨
are denkbar, deren init(Pedestrian ped) Methoden nur einmal am Anfang
aufgerufen werden und die Klassenvariablen des Agenten manipulieren d¨
urfen.
Als Unterbereich jedoch kann das Zustandsmuster sicherlich sinnvoll zum Einsatz
kommen, wenn man bspw. die m¨
oglichen Zust¨
ande definieren m¨
ochte, in denen
ein Agent sich befindet. So w¨
are denkbar, das gezeigte Beispiel um einen Modus
sitzt im Rollstuhl zu erweitern. Nur von diesem aus kann der Zustand Rollstuhlfah-
rer sucht Aufzug erreicht werden. Durch die Einf¨
uhrung von Pfad-Abh¨
angigkeiten
in den Zust¨
anden („nur von A aus ist B zu erreichen”) k¨
onnte eine komplexe
4en.wikipedia.org/wiki/Strategy_pattern, Stand 2.1.2016
24
„Zustands-Sprache” entstehen, die weitreichende Modellierung zulassen w¨
urde -
dies w¨
are ein interessanter Vorteil dieses Entwurfsmuster. Als Nachteil ist al-
lerdings zu nennen, dass eine ¨
Uberschneidung von Zust¨
anden nicht ohne Weiteres
m¨
oglich ist.
Bez¨
uglich der Anforderungen erf¨
ullt das State Pattern den Punkt modular. Die
wachsende Komplexit¨
at durch m¨
oglicherweise pfadabh¨
angige Zust¨
ande verletzt je-
doch den Punkt simpel. Die funktionalen Anforderungen w¨
aren zu erf¨
ullen, da
jeder State, neben den durch das Interface verlangten Methoden, beliebig viele
weitere Methoden haben kann.
Builder Pattern
Das Builder (Erbauer) Pattern geh¨
ort zur Kategorie der Erzeugungsmuster in
Gamma u. a. [1995]. Erzeugungsmuster dienen der Erzeugung von Objekten und
„entkoppeln die Konstruktion eines Objekts von seiner Repr¨
asentation”5.
Als solches ¨
andert es nichts an der Architektur der Pedestrians, sondern stellt eine
Alternative zu deren Erzeugung dar. Die Verwendung dieses Musters im Rahmen
dieser Arbeit wurde inspiriert durch Item 2 in Bloch [2008] mit dem Titel „Con-
sider a builder when faced with many constructor parameters”.
Der Builder sitzt ¨
ublicherweise als statische innere Klasse in der Klasse, die „er-
baut” werden soll. Anstatt einen Pedestrian direkt ¨
uber einen Konstruktor zu
erzeugen, ben¨
utzt man den statischen Pedestrian-Builder. Diesem gibt man alle
Informationen die der Pedestrian haben soll und erwartet dann, dass man mit
Aufruf der build() Methode den richtigen Typ zur¨
uckbekommt. Bez¨
uglich der
¨
Ubergabe der Werte von Builder an Pedestrian, gibt es verschiedene Varianten.
Es ist ¨
ublich, bei der Erzeugung des Pedestrian den den Builder als Argument
mitzugeben. Dieser muss sich dann „selbst setzen”, bspw.:
public static class Builder {
public Pedestrian build(){
return new Pedestrian(this);
}
5de.wikipedia.org/wiki/Erzeugungsmuster, Stand 9.1.2016
25
//...
}
-------------------------------
public Pedestrian(Builder builder){
radius = builder.radius;
//...
}
Im nachfolgenden Beispiel wurde jedoch die Variante gew¨
ahlt, in der der Builder
das Setzen der Pedestrian-Variablen ¨
ubernimmt und einen „fertig konfigurierten”
Pedestrian zur¨
uckgibt. Dadurch bleibt die „Verwaltungsarbeit” im Builder und der
Pedestrian kommt mit einem minimalen Konstruktor aus.
Pedestrian
- freeFlowVeloc: double
- radius: double
- stairsReached: boolean
+move()
Builder
- freeFlowVeloc: double
- radius: double
+ setFreeFlowVeloc(val :double): Builder
+ setRadius(val :double): Builder
+ build(): Pedestrian
Abb. 3.5: Builder Pattern
Builder pedBuilder = new Pedestrian.Builder();
pedBuilder
.setFreeFlowVeloc(0.6)
.setRadius(0.4);
Pedestrian ped = pedBuilder.build();
ped.move();
-------------------------------
public class Pedestrian {
private double freeFlowVeloc;
private double radius;
public void move(){/* ... */}
26
public static class Builder {
private double freeFlowVeloc = 1.3; // default value
private double radius = 0.25; // default value
public Builder setFreeFlowVeloc(double val){
freeFlowVeloc = val;
return this;
}
public Builder setRadius(double val){
radius = val;
return this;
}
public Pedestrian build(){
Pedestrian ped = new Pedestrian();
ped.freeFlowVeloc = freeFlowVeloc;
ped.radius = radius;
return ped;
}
}
}
Diskussion Der wesentliche Vorteil der Verwendung eines Builders ist die zen-
trale Verwaltung der Erzeugungskomplexit¨
at. Als Analogie stelle man sich einen
Handwerker vor, der Inputs bekommt und dann das fertig konfiguierte Produkt
zur¨
uckgibt. Die Sets von Inputs k¨
onnen dabei ganz verschieden sein und der Buil-
der entscheidet basierend auf den verf¨
ugbaren Informationen ¨
uber den Typ des
Produkts. Auch Error-Checking kann komfortabel in der build() Methode durch-
gef¨
uhrt werden, da alle Informationen verf¨
ugbar sind und so auf Vollst¨
andigkeit
und Korrektheit gepr¨
uft werden kann. Damit kann die Erzeugung von fehlerhaf-
ten Pedestrians verhindert werden. Ein weiterer Vorteil ist die sog. fluent API, die
ein Builder erm¨
oglicht. Da jede Setter-Methode den ganzen Builder zur¨
uckgibt,
kann man entweder einzelne Methoden auf dem Builder aufrufen, oder sie anein-
anderh¨
angen („chaining”). Dadurch ist syntaktisch elegantes B¨
undeln m¨
oglich:
27
builder.setVal(1);
builder.setAnotherVal(2);
-------------------------------
// chaining:
builder
.setVal(1)
.setAnotherVal(2);
Als Nachteil mag das mehrmalige Setzen von Variablen erscheinen, das n¨
otig ist.
Jede Variable muss einmal im Builder gesetzt werden, damit dieser sie dann im fer-
tigen Agenten setzen kann. Hinsichtlich der Anforderungen kann ein Builder so
gestaltet werden, dass Punkte wie typsicher,Korrektheit und Unit-Tests bestehen
konsequent umgesetzt sind. Durch die Verschiebung der Erzeugungskomplexit¨
at in
den Builder hinein, erscheint er nach außen flexibel und modular. Die funktiona-
len Anforderungen zu diskutieren macht keinen Sinn, da das Builder Pattern sich
als Erzeugungsmuster nur mit der Erzeugung, nicht aber mit dem Aufbau eines
Pedestrians besch¨
aftigt.
Command Pattern
Das Command (Kommando) Pattern geh¨
ort zur Kategorie der Verhaltensmuster
in Gamma u. a. [1995]. In Ermangelung einer flexiblen Verwaltung von Methoden
im gerade unter 3.2.2 diskutierten Builder Pattern, bot es sich an, das Command
Pattern zu untersuchen hinsichtlich seines Potentials die L¨
ucke der Methodenver-
waltung zu schließen. Im Command Pattern wird pro Methode eine eigene Klasse
erstellt, die ein Method Interface implementiert. Das Interface gibt mindestens eine
Signatur zum Ausf¨
uhren vor, bspw. execute(Pedestrian ped).
28
Pedestrian
- freeFlowVeloc: double
- methods: ArrayList<Method>
- stairsReached: boolean
+move()
<<interface>>
Method
+ execute(ped :Pedestrian)
ElevatorSearch
+ execute(ped: Pedestrian)
Methods
*
Abb. 3.6: Command Pattern
Pedestrian ped = new Pedestrian();
ped.addMethod(new Methods.ElevatorSearch());
ped.move(); // normal behaviour
ped.stairsReached = true;// new situation in environment
ped.move(); // search for elevator will be triggered
-------------------------------
public class Pedestrian {
private double freeFlowVeloc = 1.3;
private ArrayList<Method> methods;
public boolean stairsReached = false;
public void addMethod(Method m){
methods.add(m);
}
public void move(){
for(Method m : methods)
m.execute(this);
}
}
-------------------------------
public interface Method {
public void execute(Pedestrian ped);
29
}
-------------------------------
public class Methods {
public static class ElevatorSearch implements Method {
@Override
public void execute(Pedestrian ped) {
if(ped.stairsReached)
// activate search for elevator...
}
}
//public static class AnotherMethod implements Method { ...
}
Diskussion Vorteil: das Command Pattern eignet sich sehr gut zur Verwaltung
von Methoden. Diese k¨
onnen wie Objekte (Instanzen von Klassen) behandelt wer-
den; so k¨
onnen mehrere gesammelt werden und nacheinander ausgef¨
uhrt werden.
Der Pedestrian muss in dem Fall nicht wissen, welche Methoden-Objekte er mit sich
tr¨
agt, er h¨
alt sie als Liste vor und kann diese durchgehen. Dabei gibt er sich jeweils
selbst als Argument mit, um den Methoden die M¨
oglichkeit zu geben, in seinen
Zustand einzugreifen. Diese Methoden-Liste im Pedestrian kann einfach erweitert
werden und neu hinzugef¨
ugte Methoden sind sofort einsatzbereit. Als Nachteil ist
wie beim Observer und Decorator Pattern anzuf¨
uhren, dass stets alle registrierten
Methoden pro Agent pro Simulationsschritt durchlaufen werden m¨
ussen. Hinsicht-
lich der Anforderungen geht das auf Kosten der performance, allerdings in wohl
vernachl¨
assigbarem Umfang. Die Punkte flexibel und modular sind gegeben und
die funktionale Anforderung der Erweiterbarkeit mit Methoden ist die Grundidee
des Command Pattern. Die Erweiterbarkeit mit Steuerungselementen ist hingegen
nicht ohne Weiteres gegeben.
30
Domain Specific Language
Das folgende Konzept wurde als m¨
oglicher Ausweg aus den Grundproblemen an-
gedacht (siehe 3.2.1), die aus den bisherigen Ans¨
atzen deutlich wurden.
Ein m¨
achtiger Ansatz k¨
onnte die Entwicklung einer dom¨
anenspezifischen Sprache
(DSL: domain-specific language) sein. Kommando-Strings w¨
urden zur Laufzeit ein-
gelesen, um die Agenten zu parametrisieren und mit Verhaltensweisen auszustat-
ten. Ein einfaches Kommando k¨
onnte so aussehen:
"IF (sightrange <= 3 AND stairsreached == true) THEN askForHelp"
Die Konfiguration eines Agenten-Typs besteht aus einer Reihe solcher Kommando-
Strings. Es gibt solche, die nur einmal am Anfang ausgef¨
uhrt werden, um Variablen
zu setzen, und es gibt trigger patterns, die den Zustand der Simulation, den des
Pedestrian und den seiner Umgebung ¨
uberwachen. Bei Eintreten aller definierten
Trigger wird eine definierte Aktion ausf¨
uhrt - diese Aktion kann wiederum als
Trigger in einem anderen Trigger Pattern auftauchen usw. Hier w¨
urde sich das
Composite Pattern aus Gamma u. a. [1995] anbieten, in dem ein Ganzes ein Teil
in einem anderen Ganzen sein kann. Trigger Patterns k¨
onnen Lebenszeiten oder
Feuerungslimits haben, nach deren Ablauf sie sich deaktivieren. Zeitliche Abl¨
aufe
an sich k¨
onnen auch Trigger sein. Es bietet sich an Setter-Kommandos und Trigger
Patterns in Paketen zu b¨
undeln, wie etwa zu einem „DefaultPedestrian” oder ei-
nem „StairsReachedSearchElevator” Programm. Jede Zustandsvariable hat einen
Listener assoziiert, der wiederum von allen Trigger Patterns weiß, die am Zustand
dieser Variable interessiert sind. ¨
Anderungen werden direkt an alle interessierten
Trigger Patterns kommuniziert. Diese merken sich die Zust¨
ande ihrer Trigger und
feuern, sobald alle eingetreten sind (wobei die Definition des Eintretens eines Trig-
gers nat¨
urlich auch das Ausbleiben eines bestimmten Wertes oder das Unterschrei-
ten eines Wertes sein kann, alle Varianten der boolschen Algebra sind m¨
oglich).
So m¨
ussen nicht f¨
ur jedes Trigger Pattern in jedem Schritt alle Trigger abgefragt
werden - es gilt push statt pull. Alle Zust¨
ande, Trigger und Action Patterns sind
in HashMaps organisiert. Dadurch ist das System offen f¨
ur k¨
unftige ¨
Andernungen
und Erweiterungen. Insbesondere zu einem hohen Grad solche Erweiterungen, die
31
man zum Zeitpunkt der Systemkonstruktion noch nicht ber¨
ucksichtigt hat.
Diskussion Dieser Ansatz wird nicht weiter verfolgt, da er zu weitreichende
¨
Anderungen in der Software-Architektur mit sich z¨
oge und damit den Aufgaben-
bereich dieser Arbeit verlassen w¨
urde. Konkret verletzt er die Anforderung simpel
massiv, da er viel Komplexit¨
at verursacht, die sich erst bei v¨
olliger Konsequenz
auszahlt. Der Punkt Korrektheit ist damit aller Wahrscheinlichkeit nach sehr fragil
und es m¨
usste mit Einbußen bei der Performance gerechnet werden. Durch das
geh¨
aufte Parsen von Kommando-Strings und den st¨
andigen Abfragen, ob ein Trig-
ger Pattern feuert oder nicht. Die funktionalen Anforderungen hingegen k¨
onnten
alle erf¨
ullt w¨
urden.
3.2.3 Scala
Scala (von „scalable language”6) im Rahmen der Untersuchung von flexiblen Cha-
raktertypen einzubeziehen liegt auf der Hand. Die Sprache gilt als modern, ist
objekt-orientiert wie Java, hat aber zudem die volle Unterst¨
utzung f¨
ur funktio-
nale Programmierung und hat eine starke statische Typisierung. Sie l¨
asst sich
auch gut daf¨
ur verwenden, eigene Operatoren oder Kontrollstrukturen zu schrei-
ben - dadurch wird der Sprachumfang erweitert, man kann komfortabel eigene
dom¨
anenspezifische Sprachen (DSL) erstellen. Scala kompiliert zu Java Byteco-
de und ist daher lauff¨
ahig in der Java virtual machine. Unter Zuhilfenahme eines
kleinen Build Workflows w¨
are es also machbar, Scala-Code in der java-basierten
accu:rate Software zu integrieren.
Es gibt traits (man beachte die sprachliche N¨
ahe zu „character traits”), die an die
Klassensigatnur (1), oder im Moment der Instantiierung einer Klasse (2) angeh¨
angt
werden k¨
onnen, um Mehrfachvererbung (multiple inheritance) zu erreichen:
class Pedestrian extends VisionimpairedTrait with WheelchairTrait { } // (1)
6de.wikipedia.org/wiki/Scala_(Programmiersprache), Stand 9.1.2016
32
-------------------------------
var ped = new Pedestrian() with VisionimpairedTrait with WheelchairTrait // (2)
Diese Art der Erweiterbarkeit wird mixin class composition genannt.
Ein weiteres Feature sind objects. Ein Scala object ist wie eine Klasse, kann
jedoch nur einmal instantiiert werden - dies entspricht dem Singleton Pattern wie
es etwa in Gamma u. a. [1995] dargestellt wird.
Die folgenden zwei Ans¨
atze Scala im Rahmen dieser Arbeit einzusetzen, sch¨
opfen
sicherlich bei Weitem nicht das ganze Potential dieser m¨
achtigen Programmier-
sprache aus.
Objects
In diesem Ansatz werden Scala Objects (Singletons: nur einmal instantiierbare
Klassen) als Charaktereigenschaften von Agenten verwendet. Es gibt einen Trait
CharacterObject, den alle Charakter-Objekte implementieren m¨
ussen. Hier wird
ein Trait also genau wie ein Interface in Java verwendet. Bei der Instantiierung des
Pedestrian werden alle Charakter-Objekte mitgegeben, wobei in einem einmaligen
Durchgang f¨
ur alle die M¨
oglichkeit besteht ¨
uber die init Methode die Klassenva-
riablen des Pedestrian zu ¨
andern. In Scala gibt es keine Konstruktoren, vielmehr
ist der class body als Ganzes der Konstruktor. Daher wird der for-loop “mitten”
im class body bei Instantiierung ausgef¨
uhrt.
33
Pedestrian
+ characters: Array[CharacterObject]
+ freeFlowVeloc: Double
+ radius: Double
+ sightrange: Double
+ reachedStairs: Boolean
+ Pedestrian(characters: Array[CharacterObject])
+ move()
<<trait>>
CharacterObject
+ init(ped: Pedestrian)
+ update(ped: Pedestrian)
<<object>>
FastObject
+ init(ped: Pedestrian)
+ update(ped: Pedestrian)
<<object>>
VisionimpairedObject
+ init(ped: Pedestrian)
+ update(ped: Pedestrian)
<<object>>
WheelchairObject
+ init(ped: Pedestrian)
+ update(ped: Pedestrian)
* *
Abb. 3.7: Objects in Scala
var ped = new Pedestrian(Array(WheelchairObject))
ped.move()
ped.reachedStairs = true // new situation in environment
ped.move() // search for elevator will be triggered
-------------------------------
trait CharacterObject {
def init(ped: Pedestrian) // called only once
def update(ped: Pedestrian)
}
-------------------------------
class Pedestrian(characters: Array[CharacterObject]) {
var freeFlowVeloc: Double = 1.3
var radius: Double = 0.25
var reachedStairs: Boolean =false
for(c <- characters) { // executed on class instantiation
c.init(this)
}
def move() = {
34
for(c <- characters)
c.update(this)
}
}
-------------------------------
object WheelchairObject extends CharacterObject {
def init(ped: Pedestrian) = {
ped.freeFlowVeloc = 0.6
ped.radius = 0.4
}
def update(ped: Pedestrian) = {
if(ped.reachedStairs)
// activate search for elevator...
}
}
Diskussion Dieser Ansatz kommt dem Observer Pattern (vgl. 3.2.2) recht na-
he. Der entscheidende Unterschied zum Observer Pattern ist, dass es jeweils nur
ein globales Charakter-Objekt (entspricht einem Observer) gibt. Dies kann ein
Vorteil sein, weil dadurch eine globale Verwaltung der Charaktereigenschaften
leicht m¨
oglich ist, es kann aber auch ein Nachteil sein, da Charakter-spezifische
Zwischenwerte im Pedestrian gespeichert werden m¨
ussen. Mit Blick auf die Anfor-
derungen ist ¨
Ahnliches wie beim Observer Pattern festzustellen: modular und fle-
xibel werden erf¨
ullt, wohingegen die Erf¨
ullung von performant wegen der st¨
andigen
Schleife durch alle CharacterObjects fragw¨
urdig ist. Die funktionalen Anforde-
rungen k¨
onnten alle bei einem klugem Aufbau des CharacterObjects erf¨
ullt wer-
den.
Traits
Dieser Ansatz verwendet Traits, um Mehrfachvererbung via mixin class compositi-
on (siehe 3.2.3) zu erreichen. Um die M¨
oglichkeit hierbei ganz auszusch¨
opfen, wird
35
zus¨
atzlich eine abstrakte AbstractPedestrian Klasse eingef¨
uhrt, von der Pedestrian-
Instanzen erben m¨
ussen. Dadurch sieht die Klassensignatur eines beispielhaften
Pedestrian-Typs folgendermaßen aus:
class PedestrianTestType extends AbstractPedestrian with VisionimpairedTrait with
WheelchairTrait { }
Wobei das erste extends eine Klasse oder ein Trait sein kann, k¨
onnen alle weiteren
per with Hinzugef¨
ugten nur Traits sein.
Ein trait hat keinen Konstruktor, er kann Methoden selbst implementieren oder
nur deren Signatur beinhalten. Letzteres zwingt Klassen, die diesen Trait inkludie-
ren, dazu, die Methode zu implementieren. Inkludiert eine Klasse mehrere Traits,
darf keine Methodensignatur im Einzugsbereich der Klasse doppelt vorkommen.
Die Klasse selbst kann allerdings Methoden aus traits ¨
uberschreiben.
AbstractPedestrian
+ freeFlowVeloc: Double
+ radius: Double
+ sightrange: Double
+ reachedStairs: Boolean
+ move()
PedestrianTestType
+ move()
<<trait>>
VisionimpairedTrait
+ VisionimpairedTrait_init(ped: Abstract Pedestrian)
<<trait>>
WheelchairTrait
+ WheelchairTrait_init(ped: AbstractPedestrian)
+ searchForElevator()
Abb. 3.8: Traits in Scala
var ped = new PedestrianTestType()
ped.move()
ped.reachedStairs = true // new situation in environment
ped.move() // search for elevator will be triggered
-------------------------------
abstract class AbstractPedestrian {
36
var freeFlowVeloc: Double = 1.3
var sightrange: Double = -1
var reachedStairs: Boolean =false
def move // force extending classes to implement this method
}
-------------------------------
class PedestrianTestType extends AbstractPedestrian with VisionimpairedTrait with
WheelchairTrait {
VisionimpairedTrait_init(this);
WheelchairTrait_init(this);
def move() = {
if(reachedStairs)
searchForElevator();
//...
}
}
-------------------------------
trait VisionimpairedTrait {
def VisionimpairedTrait_init(ped: RootPedestrian) = {
ped.sightrange = 4
}
}
-------------------------------
trait WheelchairTrait {
def WheelchairTrait_init(ped: AbstractPedestrian) = {
ped.freeFlowVeloc = 0.6
}
def searchForElevator() = {
//...
}
}
Diskussion Die M¨
oglichkeit eine Klasse beliebig viele Traits erben zu lassen,
wirkt zun¨
achst sehr m¨
achtig und wie geschaffen f¨
ur die flexible Modellierung
37
von Agenten-Charakteren. Nachteil: Das Problem ist allerdings, dass Traits kei-
ne Konstruktoren haben und so besteht f¨
ur sie keine M¨
oglichkeit, die initiale
¨
Anderung der Klassenvariablen durchzuf¨
uhren. Ein Workaround dazu ist, init-
Methoden wie WheelchairTrait init in jedem Trait zu definieren und diese dann
im Pedestrian manuell aufzurufen. Damit ist leider jede Eleganz des Ansatzes zu-
nichte gemacht. Ein weiterer Nachteil ist, dass keine Methodensignatur innerhalb
aller Traits die eine Klasse inkludiert, doppelt vorkommen darf. Dabei kommt die
Frage auf, woher der Pedestrian „wissen” soll welche Methoden er hat. Man m¨
usste
wohl die gew¨
unschten mixin class compositions „festzurren” und dementsprechend
manuell die Methodenaufrufe adressieren. Damit w¨
are zwar in der Tat die flexible
Mischbarkeit von Charaktereigenschaften erreicht, die ganze Komplexit¨
at (Unter-
scheidungsf¨
alle) w¨
are jedoch effektiv nur in den Bereich des Systems verschoben
worden, in dem Methoden auf dem Pedestrian aufgerufen werden. In Bezug auf die
Anforderungen erscheint die mixin class composition daher zun¨
achst maximal
flexible und modular, verletzt aber simpel, da die Komplexit¨
at nicht aufgel¨
ost, son-
dern nur verschoben wird. Die funktionalen Anforderungen k¨
onnen erst alle erf¨
ullt
werden, wenn der neu gemischte Agent wie beschrieben „festgezurrt” wird, um ihn
in vollem Umfang adressieren zu k¨
onnen.
Es ist durchaus vorstellbar, dass Scala M¨
oglichkeiten bietet, die beschriebenen
Probleme ganz oder teilweise ¨
uber andere Entwurfsmuster oder class loading Me-
chanismen aufzul¨
osen. In der Recherche dazu konnte keine passenden L¨
osungen
gefunden werden.
3.3 Implementierung
In der Implementierungsphase wurden, in Absprache mit Florian Sesser, verschie-
dene M¨
oglichkeiten direkt im kernel von accu:rate ausprobiert.
Was davon als bleibende ¨
Anderung in den Produktionscode integriert wurde, wird
im folgenden Abschnitt dargestellt. Es kam nicht zu einem fundamentalen Wechsel
38
des Agenten-Konzepts, jedoch zu durchaus sinnvollen ¨
Anderungen und Erweite-
rungen der bestehenden Architektur. Wie es sich vielleicht bereits bei der Lekt¨
ure
der Diskussionen im Anschluss an die Ans¨
atze unter 3.2 durch die l¨
angsten Listen
an Vorteilen und Anforderungs-Erf¨
ullungen abgezeichnet hat, sind das Builder und
Command Pattern die beiden Ans¨
atze die in Kombination den gr¨
oßten Teil der
Anforderungen abdecken. In Folge fanden sie Einzug in den Produktionscode von
accu:rate, wie nun genauer dargelegt wird.
Ergebnisse der Implementierung
Im Folgenden eine kompakte ¨
Ubersicht ¨
uber die Implementierungsergebnisse und
anschließend eine detailliertere ¨
Ubersicht.
•Verwendung des Builder Pattern in der Erzeugung aller Pedestrians
•Einbau der Command Pattern Struktur f¨
ur k¨
unftigen Gebrauch
•stabileres Einlesen von CSV-Dateien zur Erzeugung von Agenten
•Entflechtung der bestehenden GroupPedestrian Klasse in zwei Klassen
•B¨
undelung State-bezogener Variablen und Methoden in einem state Objekt
•diverse refactoring Aufgaben
Builder Pattern Der entscheidende Punkt war das bereits in 3.2.2 erw¨
ahnte
Item 2 von Bloch in Bloch [2008]: „Consider a builder when faced with many
constructor parameters”. Denn genau diese langen „telescoping constructor” wie
er sie nennt, wurden in den Pedestrian Klassen von accu:rate mehrfach eingesetzt.
Mehrfach pro Klasse, weil verschiedene Erzeugungsszenarien durch jeweils einen
Konstruktor abgedeckt wurden. Hier konnte durch die konsequente Verwendung
des Builder Pattern an mehreren Stellen im Code Klarheit und eine Reduzie-
rung der Code-Redundanz geschaffen werden. Durch die vollst¨
andige Verlagerung
der Konstruktionskomplexit¨
at in den Builder entsteht das Gef¨
uhl, die vorhande-
nen Informationen m¨
ussen nur „geliefert” werden und der richtige Agent wird
39
zur¨
uckgegeben. Dieses Vertrauen in einen stets sicheren Builder k¨
onnte durch eine
noch strengere Kontrolle, ob obligatorische Werte gesetzt sind, noch erh¨
oht wer-
den. Der Builder ist schon jetzt nur schwer falsch zu bedienen, es ist aber immer
noch m¨
oglich.
Der Builder sitzt als statische innere Klasse im AbstractPedestrian und wird
dementsprechend wie folgt instantiiert:
Builder pedBuilder = new AbstractPedestrian.Builder();
Command Pattern Dem Ansatz in 3.2.2 folgend wurde auch das Command
Pattern eingebaut, das speziell f¨
ur ¨
uberschaubare Mengen Code und Komplexit¨
at
eine ideale Plattform bietet. Das Konzept erm¨
oglicht bei Agenten einen „Plug-
in” Mechanismus um Methoden zu laden. Allerdings gibt es momentan noch kei-
nen Anwendungsfall daf¨
ur, sprich die ArrayList<Command> commands ist leer und
dementsprechend hat die for-Schleife durch alle commands keinen Durchlauf in der
move() Methode des Pedestrian - dies k¨
onnte sich aber in Zukunft ¨
andern.
Commons CSV Das Einlesen von Pedestrian Parametern aus einer CSV-Datei
ist durch die Verwendung der Library Commons CSV von Apache stabiler gewor-
den. Die Reihenfolge der Spalten ist damit irrelevant geworden. Sind ganze Spalten
nicht vorhanden oder Werte darin nicht gesetzt, wird im Fall einer obligatorischen
Spalte ein Fehler geworfen, bei optionalen Spalten werden Default-Werte verwen-
det. In einer for-Schleife for(CSVRecord record : csvParser) wird f¨
ur jede Zei-
le der Builder mit den Eintr¨
agen der Zeile gespeist, die Parameter f¨
ur einen neuen
Pedestrian darstellen. Kommt es seitens des CSV Parsers oder seitens des Builders
zu einem kritischen Fehler, wird f¨
ur diese Zeile kein Pedestrian erzeugt und eine
entsprechende Fehlermeldung ausgegeben.
GroupPedestrian Der bestehende GroupPedestrian hat bisher zwei verschie-
dene Gruppentypen abgedeckt: Kleingruppen die stets beisammen bleiben, und
Großgruppen, die sich unabh¨
angig bewegen, jedoch an Wartezonen aufeinander
40
warten. Diese zwei Gruppentypen finden nun ihre Repr¨
asentation in einem Group
PedestrianLoose und einem GroupPedestrianTight. Beide erweitern den Group
Pedestrian der Methoden hat, die beide Typen brauchen. Der quantitative Zu-
wachs auf drei Klassen, statt wie bisher einer, ist durch die gr¨
oßere Klarheit in der
Erzeugung der jeweiligen Typen gerechtfertigt.
State Objekt Damit ist nicht das State Pattern gemeint, sondern eine neue
Klasse State, von der jedem Pedestrian eine zugewiesen ist. Sie sammelt Zustands-
variablen ein die bisher lose im AbstractPedestrian lagen. So bspw. ob sich der
Pedestrian gerade auf einer Treppe befindet, wie hoch die Dichte gerade um ihn
herum ist oder seine aktuelle Position. Ein paar Methoden, die haupts¨
achlich die-
se Zustandsvariablen lesen, setzen oder manipulieren, sind nun ebenfalls im State
Objekt. Der Mehraufwand, Variablen innerhalb des State Objekts zu adressieren,
anstatt direkt im Pedestrian, ist durch die erh¨
ohte Klarheit der Code Architektur
gerechtfertigt.
Refactoring In R¨
ucksprache mit Herrn Sesser von accu:rate wurde die Architek-
tur des Pedestrian-Pakets umgestellt. Nach der Entzerrung des Codes wurde er in
Pakete aufgeteilt, umbenant und umsortiert, um Klarheit zu schaffen. Kleinigkei-
ten wurden verbessert, nicht ben¨
otigte Importe entfernt und fehlende @Override
Annotationen gesetzt. Um Betriebsgeheimnisse zu wahren, wird an dieser Stelle
auf Anfrage von Herrn Sesser auf eine detailliertere Betrachtung verzichtet.
Erreichen der Ziele
Alle unter 1.2 formulierten Ziele konnten erreicht werden, wenngleich der Punkt
der h¨
oheren Flexibilit¨
at (Mischen der Charaktereigenschaften eines Agenten) durch
die Einf¨
uhrung des (noch aufgabenlosen) Command Pattern nur im Ansatz vor-
bereitet wurde. Die Implementierungsergebnisse unter 3.3 scheinen ein guter und
sinnvoller Beitrag zum Simulator von accu:rate zu sein. Durch die vorgenomme-
nen ¨
Anderungen und Neuerungen sind die bearbeiteten Teile des Systems robuster,
41
sauberer und zukunftssicherer geworden. Insbesondere der Einbau des Builder Pat-
tern ist ein weitreichender Eingriff, von dem Programmierer profitieren werden, die
k¨
unftig an diesen Untersystemen des Simulators von accu:rate arbeiten und neue
Pedestrian Typen implementieren. Die B¨
undelung der Erzeugungskomplexit¨
at an
dieser einen Stelle wird k¨
unftige Entwicklungen deutlich erleichtern.
Mehr zum Ausblick unter 4.3.
42
4 Herausforderungen, Gelerntes und
Ausblick
Ziel dieser Arbeit war es verschiedene Implementierungskonzepte von Agenten-
Charakteren in agentenbasierten Personenstromsimulationen zu untersuchen. Nach
Reflexion dieser Ans¨
atze hinsichtlich einer m¨
oglichst effizienten Modellierung kom-
plexer Charaktere ging es darum die Ergebnisse in der Software von accu:rate
umzusetzen. Dazu habe ich zun¨
achst vergleichbare Systeme vorgestellt, insbeson-
dere wurde die Software VADERE der Sofware von accu:rate gegen¨
ubergestellt.
Dabei lag der Fokus auf deren L¨
osungen zur Implementierung von Agenten. An-
schließend wurden aus Literaturrecherche relevant erscheinende Software Design
Patterns untersucht und kleine Beispiele in Java und Scala implementiert, die den
jeweiligen Ansatz im Kontext der Agenten-Erzeugung interpretieren. Jeder Ansatz
wurde per UML-Diagramm und mit Ausz¨
ugen seines Codes dargestellt. Dar¨
uber
hinaus wurden die Vor- und Nachteile jedes Ansatzes diskutiert und der Grad
der Erf¨
ullung der generellen und funktionalen Anforderungen wurde reflektiert. In
der Implementierungsphase schließlich wurde nach Abw¨
agung aller Ans¨
atze ent-
schieden, was davon umgesetzt wird und Einzug in die produktive Software von
accu:rate finden soll. Abschließend wurden die Ergebnisse der Implementierungs-
phase vorgestellt und hinsichtlich der Ziele diese Arbeit reflektiert.
43
4.1 Herausforderungen bei der
Implementierung
Die gr¨
oßte Herausforderungen beim experimentellen Implementieren war die enge
Verzahnung des Agenten-Codes mit anderen Bereichen der Software. ¨
Anderungen
des Konzeptes hatten teilweise weitreichende Folgen, die schwer zu ¨
uberschauen
waren, wenn man sie nicht konsequent durchgezogen h¨
atte. Gleichzeitig arbeite-
te accu:rate produktiv mit dem Code. Nat¨
urlich l¨
asst sich das in GitHub ¨
uber
Branches trennen, aber es hatte trotzdem zur Folge das eher inkrementell und
vorsichtig vorgegangen wurde, statt große W¨
urfe zu machen. Insbesondere Pull
Requests an den develop branch sind zeitintensiv, da sie von accu:rate review-
ed werden m¨
ussen, um die Stabilit¨
at und Korrektheit des Produktionscodes zu
garantieren. Eine weitere Herausforderung stellte der Mangel an „inspirierenden”
Anwendungsf¨
allen dar. Wie in den Code-Beispielen im letzten Kapitel sichtbar ist,
wurden immer wieder die Typen FastPedestrian,VisionimpairedPedestrian und
WheelchairPedestrian als Beispiele verwendet. Diese bringen jedoch bei Weitem
nicht so viel zus¨
atzliche Komplexit¨
at wie der bereits bestehende GroupPedestrian.
Ein Anwendungsfall von solchem Kaliber h¨
atte schneller wichtige Fragen aufge-
worfen. M¨
oglicherweise gibt es aber auch keinen ¨
ahnlich gewichtigen Anwendungs-
fall.
4.2 Erkenntnisse
Ich konnte mein Verst¨
andnis von Software Design Patterns allgemein und im Be-
sonderen f¨
ur diejenigen ausbauen, die ich unter 3.2 behandelt habe.
Mir wurde bewusst wie herausfordernd es sein kann, ein Teilsystem eingebettet
in ein gr¨
oßeres Software-System neu zu strukturieren. Bei der Erschaffung eines
Systems werden viele konzeptionelle Entscheidungen getroffen, die oft aufeinander
aufbauen, wodurch es u.U. schwer wird, Teilsysteme isoliert zu betrachten.
Daher nehme ich mit, dass es sich lohnt, sehr gr¨
undliche ¨
Uberlegungen in den erst-
maligen Aufbau von Software Architekturen zu investieren. Je besser dabei Teil-
44
systeme voneinander abgekapselt sind, desto leichter f¨
allt es sp¨
ater konzeptionelle
¨
Anderungen vorzunehmen. Selbstverst¨
andlich kommt es im Alltag eines Program-
mierers st¨
andig vor, bestehende Teilsysteme verbessern zu m¨
ussen und daraus ein
besseres und f¨
ur die Zukunft ger¨
ustetes System zu bauen. Daher ist neben der
F¨
ahigkeit zur gr¨
undlichen Systemarchitektur „from scratch” sicherlich die Ein-
arbeitung und Verbesserung verzahnter Komplexe auch eine essentielle F¨
ahigkeit.
Rich Hikey, der Erfinder der Programmiersprache Clojure sagt dazu: der „elephant
in the room [is] the software we’ve already written”. Um in Hikey’s Metapher zu
bleiben kann man sagen, dass man bei ¨
Anderungen stets den „Elefanten” bewegen
muss. Daher wirkt „er” der Agilit¨
at entgegen, die ein junges Unternehmen wie
accu:rate besonders braucht. Ich habe erst sehr sp¨
at verstanden, dass VADERE
zum einen nicht nur ein Simulationsmodell beherbergt, sondern ein Framework
f¨
ur alle m¨
oglichen Simulationsmodelle sein will und zum anderen keine agentenba-
sierte Architektur hat, sondern den mathematischen Modellen stets die F¨
uhrung
¨
uberl¨
asst. Als Lerneffekt nehme ich daher mit, dass es sich lohnen kann einen
Schritt von der Aufgabenstellung zur¨
uck zu gehen, um zu verstehen, in welchem
konzeptionellen Gesamtschema man sich bewegt. Dies l¨
asst eine fundamental an-
dere Blickrichtung zu als von der Aufgabenstellung aus ausschließlich nach vorne
zu blicken. Pers¨
onlich konnte ich in meinem Arbeitsprozess die Tendenz erkennen,
praktische Beispiele als Orientierung heranzuziehen, um ein Verst¨
andnis aufzubau-
en und meinen Erfindergeist zu stimulieren. Dies ist zum einen wohl eine St¨
arke,
zum anderen strebe ich jedoch auch an, noch mehr Routine im wissenschaftlichen
und theoretischen Arbeiten zu bekommen.
Danksagung
Bedanken m¨
ochte ich mich bei accu:rate, wobei ich Herr Sesser besonders her-
vorheben m¨
ochte. Ich sch¨
atze ihn als hervorragenden Programmierer mit einer
inspirierenden Leidenschaft f¨
ur guten und eleganten Code und habe viel gelernt in
der Zusammenarbeit.
Desweiteren m¨
ochte ich mich bei Herrn Seitz von der VADERE Forschungsgruppe
f¨
ur die Einsichten in deren System bedanken und bei meiner Cousine Dr. Tanja
45
Prokic von der TU Dresden f¨
ur die philosophische Inspiration zum Thema „Simu-
lation” die in die Einleitung Einzug gefunden hat.
Schließlich noch ein Dank an Tanja Prokic und Bettina Stumpfegger f¨
ur das Kor-
rekturlesen meiner Arbeit.
4.3 Ausblick
Auto-Refactoring Idee Neben dem Ansatz der domain specific language 3.2.2
ist mir eine weitere Idee im Kontext dieser Arbeit gekommen, die ich bei Gelegen-
heit weiter verfolgen m¨
ochte. Dabei geht es um einen Algorithmus der automati-
sche refactoring Vorschl¨
age macht. In meiner Vorstellung wird der zu untersuchen-
de Code als Graph abgebildet, wobei die Methoden als Knoten und die Aufrufe
als Kanten abgebildet werden. Unter Verwendung von Werkzeugen der mathe-
matischen Graphen-Analyse werden dann alternative Clusterungen gesucht, bei
denen der mittlere Abstand aller Knoten geringer ist als im momentanen Graph.
Das Ergebnis solcher automatischen Refactoring Vorschl¨
age sei laut Herrn Ses-
ser erfahrungsgem¨
aß wenig n¨
utzlich, da es nicht menschlicher Logik entspr¨
ache.1
Nichtsdestotrotz m¨
ochte ich das Thema bei Gelegenheit weiter verfolgen.
M¨
ogliche weitere Implementierungen in der accu:rate Software Zu fol-
genden Punkten w¨
urde es Sinn machen noch mehr Arbeit zu investieren:
•Den Builder „unbreakable” machen: egal was man ihm gibt, er produziert
entweder einen funktionierenden Pedestrian oder gibt eine detaillierte Fehler-
meldung zur¨
uck, alle fehlerhaften Zwischenzust¨
ande ausl¨
oschen. Ein Ansatz
dazu war eine BuildOrderException, die ich eingebaut habe, aber wieder
entfernt habe, da sie mehr Komplikationen als Nutzen brachte.
•Anwendungsf¨
alle f¨
ur das Command Pattern aktiv suchen. Es gibt bestimmt
bereits bestehende Mechanismen die in ein Command konvertiert werden
k¨
onnten.
1Florian Sesser im pers¨
onlichen Gespr¨
ach, Dezember 2015
46
•M¨
oglicherweise k¨
onnte das casten auf den gew¨
unschten Pedestrian-Type in
der build() Methode noch eleganter gestaltet werden.
•Ein Frontend-Tool, um Populationen von Pedestrians zu kreieren.
•Zusammen mit dem Populations-Tool bietet sich eine Entkopplung der sta-
tistischen Funktionalit¨
at in ein eigenes Paket an.
•Ein ¨
ahnlich „inspirierender” Anwendungsfall (siehe 4.1) wie der GroupPe-
destrian k¨
onnte evtl. der von Sivers in von Sivers u.a. [subm] entwickelte
Helping Pedestrian sein, der eine „shared social identity” mit anderen Agen-
ten eingeht.
•Konsequentere Abkapselung des Agenten-Erzeugenden Systems vom ¨
ubergeordneten
System: wie in Punkt 5von 3.2.1 verdeutlicht wurde, kann es sein, dass neue
Pedestrian Typen, die neue Methoden und Steuerungselemente mitbringen,
¨
Anderungen im ¨
ubergeordneten System erzwingen. Diese „externen Veranke-
rungsmaßnahmen” laufen der Flexibilit¨
at der Charakter-Erzeugung massiv
entgegen. Ein Ausweg k¨
onnte sein, das Pedestrian-erzeugende System weiter
zu konsolidieren und innerhalb des Gesamtsystems konsequenter abzukap-
seln, sodass keinerlei Aufrufe mehr stattfinden, bis auf move() auf jedem
Pedestrian in jedem Simulationsschritt.
47
Literaturverzeichnis
[Barthes 1966] Barthes, Roland: Die strukturalistische T¨
atigkeit. 1966 1.1
[Baudrillard 1982] Baudrillard, Jean: Der symbolische Tausch und der Tod.
Matthes und Seitz, 1982. – ISBN 3882212152 1.1
[Bloch 2008] Bloch, Joshua: Effective Java. second. Pearson Education, 2008
(Java Series). – ISBN 9780132778046 2.2,3.1.2,3.2.2,3.3
[Chattaraj u. a. 2009] Chattaraj, Ujjal ; Seyfried, Armin ; Chakroborty,
Partha: Comparison of Pedestrian Fundamental Diagram Across Cultures. In:
Advances in Complex Systems 12 (2009), Nr. 3, S. 393–405 1.1
[Gamma u. a. 1995] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlis-
sides, John: Design Patterns. Elements of Reusable Object-Oriented Software.
Addison-Wesley, 1995. – ISBN 0–201–63361–2 2.2,3.1.2,3.2.2,3.2.2,3.2.2,3.2.2,
3.2.2,3.2.2,3.2.2,3.2.3
[Hartmann 2005] Hartmann, Stephan: The World as a Process: Simulations in
the Natural and Social Sciences.http://philsci-archive.pitt.edu/2412/.
Version: 2005 1.1
[Helbing u. Mukerji 2012] Helbing, Dirk ; Mukerji, Pratik: Crowd disasters as
systemic failures: analysis of the Love Parade disaster. In: EPJ Data Science 1
(2012), Nr. 7, S. 1–40 3
[Kneidl 2013] Kneidl, Angelika: Methoden zur Abbildung menschlichen Navigati-
onsverhaltens bei der Model lierung von Fußg¨
angerstr¨
omen, Technische Univer-
sit¨
at M¨
unchen, Diss., 2013 1.3
[Luke 2015] Luke, Sean: The ECJ Owner’s Manual, 2015. – https://cs.gmu.
edu/˜eclab/projects/ecj/docs/manual/manual.pdf 1
[Schadschneider u. Seyfried 2011] Schadschneider, Andreas ; Seyfried, Armin:
Empirical results for pedestrian dynamics and their implications for modeling.
In: Networks and Heterogeneous Media 6 (2011), Nr. 3, S. 545–560 1.1
[Seitz 2016] Seitz, Michael, Diss., 2016 3.1.1
[von Sivers u. K¨
oster 2015] Sivers, Isabella von ; K¨
oster, Gerta: Dynamic Stride
Length Adaptation According to Utility And Personal Space. In: Transportation
Research Part B: Methodological 74 (2015), S. 104 – 117 1.1
[von Sivers u.a. subm] Sivers, Isabella von ; Templeton, Anne ; K¨
unzner,
Florian ; K¨
oster, Gerta ; Drury, John ; Philippides, Andrew ; Neckel,
Tobias ; Bungartz, Hans-Joachim: Modelling social identification and helping
in evacuation simulation. In: Safety Science (submitted 2015) 4.3
[Weidmann 1992] Weidmann, Ulrich: Schriftenreihe des IVT. Bd. 90: Transport-
technik der Fussg¨
anger. 2. Z¨
urich : Institut f¨
ur Verkehrsplanung, Transport-
technik, Strassen- und Eisenbahnbau (IVT) ETH, 1992 1.1
Degenhart, Benjamin Aaron
Familienname, Vorname
M¨
unchen, 11.1.2016
Ort, Datum
4.9.1986
Geburtsdatum
IC 7 / WS 2015/16
Studiengruppe / Semester
Eidesstattliche Erkl¨
arung
Hiermit erkl¨
are ich, dass ich die Bachelorarbeit selbst¨
andig verfasst, noch nicht an-
derweitig f¨
ur Pr¨
ufungszwecke vorgelegt, keine anderen als die angegebenen Quellen
oder Hilfsmittel benutzt sowie w¨
ortliche und sinngem¨
aße Zitate als solche gekenn-
zeichnet habe.
Unterschrift
