Entwicklung (Abstraktionsschicht 1)

[spirit]

hi ihr,

Wie im Topic zur Grafik besprochen habe ich mal den Grundstein für unser drei Schichten Modell gelegt.

Die neuen Sources habe ich ins CVS Verzeichnis "openevo" hochgeladen, da niemand der "Taufe" widersprochen hat.

Eigentlich wollte ich ja die world Klasse (die im Abstraktions Layer 1 - im folgenden AL 1) mit templates realisieren, aber irgendwie wirft mir Dev-C++ beim Linken dann immer reference errors oder baut Zugriffsfehler die gar nicht existieren sollten. Vielleicht seht ihr euch das mal an, wäre perfekt wenn man der world Klasse bei der Deklaration nur einen beliebigen Nachfahren von basic_life übergibt und schon arbeitet alles mit der abgeleiteten Klasse. hm mal schaun ob das möglich ist.

mfg spirit

[Assimilator]

Hab bir das nun (endlich... ;)) mal angeschaut.

Ich denke das Modell, dass du anpeilst sieht nun so aus:


Spezifische Implementierung: world_specific | life_specific | visual_specific
Basis: world_base | life_base | visual_base


Ich habe das aber so gemeint:


GUI: world_visual | life_visual
Spezifische Implementierung: world_specific | life_specific
Basis: world_base | life_base

Dieses Modell hat den Vorteil, dass in den Grundklassen überhaupt kein GUI Code vorkommt und man sich auf Ebene 1 und 2 vorerst keine Gedanken über die Visualisierung machen muss und man sehr einfach verschiedene Visualisierungen etc. erstellen kann. (Es ist daher auch einfacher vom gleichen Code ein Build mit und ein Build ohne Visualisierung zu erstellen.


Ich ändere aber erst mal nix daran, bis ich net dein feedback habe.. =)


mfG Assimil8or

[spirit]

Aber ich glaube logischer ist mein Modell, denn ein UI brauchen wir auf jeden Fall, und wie ich das ja schon entwickelt habe, ist dieses UI im base halt nur Konsole. Da muss man sich auch ned wirklich drüber Gedanken machen. Vorteil dabei ist die Modularität der Benutzerschnittstelle. Also wenn einer eine graphische Analyse einer Evolution entwickelt kann ich die mit minimalen Änderungen auch für andere spezifische Populationen verwenden.

Vorteil ist auch, dass die Visualisierung unabhängig vom Entwicklungsfortschritt der anderen Objekte ist. Das heißt, dass ich auch für Testzwecke eine base Stufe von LFen zB graphisch darstellen könnte.

Davon abgesehen dachte ich eigentlich an eine Kombination der beiden Modelle:


- Einsatzbereit: world_ready --> life_ready --> visual_ready (die Klassen in dieser Schicht sind auf spezielle
^ (optional) \ Anforderungen zurechtgeschnitten wie Grafik oder Platform)
| \
- Problemspezifisch: world_specific --> life_specific --> visual_graph (stellt grafische Funktionen bereit)
^ / \/
| / /\
- Basis: world_base --> life_base --> visual_base (nur Konsole, überall kompilierbar)

was hältst du davon ?
Will eigentlich erst weitercoden, wenn wir das zu beider Zufriedenheit ausdiskutiert haben.

mfg

[Assimilator]

Ok, wenn das so ist das vielleicht sogar noch besser. Könnten wir dazu noch kurz an einigen Beispielen durchgehen, was jetzt z.B. in welche Klasse kommt. (Damit ich das auch sicher richtig verstanden habe =))

So wie ich das verstanden habe:
world_base: verwaltung und scheduling der verschiedenen Lebensformen
life_base: enthölt den code der lebensform und den grund-interpreter
visual_base: konsolen statusinformation

world_specific: zusätzliche Methoden zur Positionsabfrage
life_specific: position + erweiterte Befehle und Interrupts
visual_graph: Grafische darstellung

world_ready: enthält die selektionsfaktoren für das spezifische problem
life_ready: ?
visual_ready: darstellung die mehr infos über das spezifische problem anzeigt


mfG Assimil8or

[spirit]

Ok meine Zeichnung ist eigentlich nicht optimal, weil visual_xy ja eigentlich eher mit world_xy in Verbindung steht. So schon im einfachstne Fall, wenn nur die Populationsgröße angezeigt wird.

zu deiner Frage:

_base: genau

_specific: Diese Schicht enthält bereits die Selektionsfaktoren, und die Interruptimplementationen bei life_specific, das mact insofern Sinn als ja die Auswahl der Interrupts eng mit den "Selektionsfaktoren" zusammenhängt. (Bsp: Selektionsfaktor: Futtersammeln -> Interrupt: Futter erkennen/aufnehmen)

visual_graph: im Prinzip ja, aber um das Projekt allgemein zu halten will ich noch hinzufügen, dass graphische Darstellung nicht immer heißen muss, dass die LFen auf einem Feld herumrennen, das man hier zeichnet sondern, wenn zB mit openevo einen optimalen numerischen Algorithums finden will, dann kann man hier zB auch visualisieren wie sich die Performance der Algos im Lauf der Evolution verbessert hat oä.

_ready: Diese Schicht ist vielleicht die unverstandenste, mit gutem Grund, habe ich doch noch nie formuliert wozu sie da ist. Also ists an der zeit das zu ändern ;) Ich wollte nur in unserem schönen Schichtenmodell nicht haben, dass wenn zB die Evo steht und funktioniert noch jemand in der _specific Schicht herumpfuscht, nur um etwas an der Populationsanalyse zu ändern. Also hab ich mir gedacht, die Auswertung einer Evolution kommt in diese Schicht. Dazu gehören Dinge, wie die 5 häufigsten (=stärksten?) LFen alle 5 Minuten dumpen oder irgendwelche LOGs über die Futterverteilung am Feld zu führen. Da diese Auswertungsfunktionen aber wolrd_ und life_ betreffen und damit man sie gemäß Schichtenmodell auch richtig darstellen kann auch ein visual_ notwendig ist, hab ich kurzerhand eine dritte und höchste Schicht dafür eingeführt.

mfg

[spirit]

Ich kann im Moment fast keine Zeit für die Weiterentwicklung aufbringen, weil Juni ja bekanntlich Uni-Prüfungsmonat ist, aber ich denke dass dannach hier wieder kräftig was weitergehen wird.

mfg