Am 05. Mai war das Meeting zwischen Peter, Gregor, Sedat und mir. Da habe ich mich wohl mal wieder übernommen, mit dem Satz: Ich mache mal eben die Java-Referenzimplementierung zu Pile. Das kann noch dauern. Denn ich habe die Pile-Relationsstruktur noch immer nicht vollständig verstanden. Ich bin aber jetzt erst auf die Seite http://www.pileworks.org aufmerksam geworden, nachdem ich Ralf’s “A Journey Into The Pile Universe” etwas genauer im ICE von Bonn nach Hamburg studiert habe.
Okay, was ist bisher passiert? Bisher habe ich das Papier von Ralf studiert, um ein wenig mehr von seiner Referenzimplementierung und über Pile selbst u lernen. Parallel dazu habe ich mir die Referenzimplementierung von Ralf Westphal heruntergeladen.

Dabei habe ich folgende Erkentnisse gewonnen:

  1. Die Referenzimplementierung von Ralf ist nicht reines C# sondern ein C#-Wrapper, um einen PileSpace-Kern, der in C++ geschrieben ist. Puh hier muss ich meine alten C++ Erfahrungen aber wieder auspacken (was war noch gleich ne C-Map? Stimmt die stammt doch aus dem STLs (Standard Template Libraries – Wau ist das lange her, das waren Cyberdynezeiten, so 1998) Baue ich das in einen Java-Vector oder in eine Java-Map um? – mal sehen. Eine STL-Map hat eine .find()-Methode, wenn ich es richtig gesehen habe!
  2. Da ich, wenn schon, denn schon, eine pure 100% Java-Variante bauen möchte, muss ich da noch einiges “umbauen” :-)
  3. Der Pile-Architekur-Stack sieht also wie folgendes aus: C++ Kern, C#-PileSpace-Wrapper, darauf eine Pile-Engine, ein Pile-Agent und darauf ein Pile-Client (!)

Dabei haben die einzelnen Komponenten folgende Funktionen:

  1. PileSpace: Der PileSpace ist die low-level-Komponente des PileSystems. Der PileSpace bildet SpacePoints ab, welches Punkte in einer 2D-Struktur sind um Relationen zu speichern (Hierzu werden eindeutige Handles verwendet die durch Integer abgebildet werden). Details findet man in Ralfs Paper.
  2. PileEngine: Die PileEnginge liegt oberhalb des Pile-Spaces im Architekturmodell. Die Pile-Engine delegiert an den PileSpace-Layer, operiert aber ebenfalls noch mit Terminal-Values und hält Informationen über Child- und Parent-Elemente vor.
  3. PileAgent: Der Pile-Agent liegt im Architekturmodell oberhalb der Pile-Engine und implementiert eine Pileanwendung aus fachlicher (business) Sicht.
  4. PileClient: Die genaue Abgrenzung zwischen PileAgent und PileClient ist mir noch unklar. Vermutlich ist der PileClient einfach eine weitere Abstraktion, stellt vielleicht die Oberfläche einer Pile-Anwendung dar!???

Der Kern der Demo besteht aus folgender Datei:

pilespace.cpp

  1. beinhaltet die Struktur SpacePoint, welche einfach eine 2D-Koordinate abbildet, um eine Pile-Relation zu beschreiben, wie in Ralfs Blog beschrieben. Wahrscheinlich wird dies eine Java-Klasse, was sonst :-) ?. Dies wird durch die Struktur Coordinates coords realisiert. Was mit nicht ganz klar ist, ob es ein Variable gibt, um zu erkennen, in welchem Quadranten der SpacePoint lokalisiert ist. Aus dem Quadranten (siehe Seite 38 in dem PDF-Summary von RalfW) ergibt sich ja auch die Art der Relation (Np, Top) (Top,Top), (Top, Ap), (Np, Ap). Die Crux liegt vermutlich in einer Struktur namens PartnersDictionary deren Ausprägung xPartners und yPartners heissen. Diesses PartnersDictionary ist selbst wieder eine Map aus zwei “unsigned integern”, vermutlich benutzt Ralf diese Struktur, wenn ein SpacePoint selbst als Koordinate von anderen SpacePoints verwendet wird. Die Geschichte mit der Diagonalen indem Koordinatensystem ist mir aber noch nicht ganz klar.
  2. beinhaltet eine Liste bzw. Map von SpacePoints, welche PointsDictionary heisst. vermutlich implementiere ich diese Map als Javaklasse, die ich von einer Java-Map oder einem Vector ableite.
  3. beinhaltet die Struktur PileSpace, welche ich vermutlich ebenfalls als Java-Klasse implementieren werde. Ein PileSpace beinhaltet nichts anderes als eine Map von SpacePoints.
  4. Das PileSpaceDirectory ist wieder eine Map von PileSpaces und verwandelt diese. Ich bin verleitet hier das Factory-Pattern anzuwendenSehr knifflig werden hier die Methoden setValue() und getValue(), da man hier die 2D-Abbildung der Relationen sehr wohl verstanden haben muss. Ich habe gelernt, das man zwischen folgenden Dingen beachten muss:
    • Die Datenatome werden niemals innerhalb der Pilestruktur gespeichert, so wie wir Dinge unserer Umwelt, z.B. das nicht in unser Gehirn rein-tun. Das da draußen bzw. der Buchstabe ‘H’ bleibt draußen. In der Pile-Terminologie wird dies als TerminalValue (Tv) bezeichnet.
    • Natürlich muss es so etwas wie ein “Mapping” geben. Dieses Mapping wird durch die sogenannten Tops realisiert. Eine Tv:Top Beziehung, ist, wie ich es im Moment verstehe immer eine 1:1-Beziehung und bidirektional.
    • Dann gibt es die System Definer (SD). Deren Zweck habe ich noch nicht verstanden, weil ich noch nicht weiss was es genau mit dem normativen Tree unddem assoziativen Tree auf sich hat. Ein SD ist, wenn ich es richtig verstanden habe, immer eine Relation zwischen Tops
    • Weiterhin gibt es normative und assoziative Roots. Normative Roots bilden Relationen zwischen einem normativen Parent und einem Top ab (Np, Top). Assoziative Roots bilden Relationen zwischen einem assoziativen Parent und einem Top ab.last but not least gibt es Relationen zwischen assoziativen Parents und normativen Parents (Np, Ap)

So, die anderen drei Quelltexte, die aus meiner Sicht eine wesentliche Rolle spielen, nehme ich mir das nächste Mal vor: PileSpace.cs, PileEngine.cs, PileAgent.cs.

Au, da fällt mir ein, Ralf wollte noch einen komplexen Graphen, bei der sich meine Modeller-Software die Zähne ausbeisst, wenn Sie nach Zyklen mit einer einfachen Tiefen- und Breitensuche an das Problem rangeht. Wie verhält sich eine PileEngine, wenn man Zyklen in einem komplexen Graphen mit hoher Dichte sucht. Fragen über Fragen. Also Ralf, ich hab’s nicht vergessen. Wochenends ist eben meist Famillybusiness angesagt und das kommende Wochenende ist auch schon wieder in Bonn verplant.