Das deutsche Python-Forum

Hallo zusammen

Ich stand kürzlich vor folgender Situation: ich musste eine Simulation durchführen und dazu einen Bericht abliefern (Molekül-Dynamik). Das ganze umfasste folgende wesentliche Komponenten:
- Simulation (Python, Fortran)
- Graphen (.dat-files) die mit gnuplot geplottet werden
- Tabellen (.tex files, in denen Tabellen waren)

Ich habe das ganze so gescriptet, dass nach jeder Simulation alle batch-files für gnuplot und alle latex-tabellen bereit waren. Am Schluss der Simulation hat das Skript noch kurz alle files mit gnuplot geplottet, s.d. die .eps-figures bereit standen und dann musste ich nur noch den Latex-Bericht kompilieren, der alle Tabellen und Bilder aufgesaugt und zusammengebastelt hat. Am Schluss war das alles so kompliziert (mit Benennung und so), dass es nicht mehr kompilieren konnte und ich eine vorfertige Version (zum Glück noch in der Mailbox) abgeben musste. Hm... Nun beschäftigts mich länger, wie ich das schlauer hätte machen können und ich glaube, wenn ich bessere Ahnung von DP gehabt hätte, wäre wohl MCV am besten gewesen, allerdings sehe ich noch nicht ganz, wie ich das umzusetzten sollte.

Model: Die Simulation, wurde eigentlich fast fertig geliefert, war vorkompiliertes FORTRAN-Programm, nur paar Parameters abliefern, das wars.

Control: Koordination von Simulation (if simulation done: generate tex and plot files), tex-file generierung, plot-file generierung? Hier wohl auch die Steuerung der Filebenennung. Note: am schluss waren da so gegen zweitausend files in dem Verzeichnis. Für jeden Druck im Intervall [0.3, 3.0] Pa und jede Temperatur in [0.4, 2.5] (in 0.1-Schritten) wurde eine Simulation gestartet, die je etwa zehn Files erzeugte.

View: gnuplot auf allen plot-files aufrufen und dann noch den Latex-compiler um den Bericht zu bauen?


Hinzu kam noch, dass Daten von mehreren Simulationen in das selbe Bild geplottet werden mussten, also wieder Aufgabe von Control? Nehme an, M, C und V sollten als Klasse implementiert werden.

Wäre froh um Hinweise und Ratschläge.

Für solch ein Problem ein Architekturmuster herauszuholen halte ich für sehr überzogen.
Ein relativ kurzes Script müsste für diese Problemstellung genügen, oder gibt es da spezielle Gründe, weshalb nicht?

Ich sehe an dieser Stelle gar nicht die Probleme, mit denen du dich auseinander setzt...

ich sag ja nicht, dass ich darauf bestehe, sondern nur, dass ich dachte, hier wäre eine Anwendung möglich. Zudem, an einem einfacheren Beispiel mal den Umgang damit lernen kann ja nicht schaden, nicht? Doch ich stimme dir zu, auch ein kürzeres Skript hätte gereicht.

Das MVC ist trotzdem nicht passend, da du keine View-Komponente hast.
Das einzige, was in diese Komponente passen würde, wäre eine Anzeige des erzeugten div/pdf Files...
Das ganze Generieren wäre im Bereich Controller.

btw: Deine ganzen Files müsstes du dem Model zuordnen, da im Model die Daten hinterlegt sind.

Da die Verbindung zwischen deinen Daten und der Logik sehr eng ist, lohnt sich meiner Meinung nach aber auch keine Trennung zwischen M und C...

hey danke. ich war bis jetzt davon ausgegangen, der Teil des Programms, der sich mit den gnuplot-Aufrufen beschäftigt, und mir so .eps-figures anlegt, könnte als View-Komponente aufgefasst werden. In diese Komponente hätte ich auch einen abschliessenden Latex-Call gepackt, der das ganze zusammenkompiliert...

"das ganze generieren wäre im Bereich Controller"

Du meinst, der Controller kümmert sich um die Erzeugung der Graphiken? Noch etwas: heisst das also, die Komponenten würde man als Klassen implementieren oder spielt das erstmal hier keine Rolle?

Als View kommt z.B. eine GUI oder HTML-Generierung in einem CGI-Skript in Frage.
Als View werden die Daten lediglich dargestellt und nicht verarbeitet.
Das passiert natürlich beim Plotten, denn du erzeugst neue Daten (==> eps Dateien).

Der Controller erzeugt zuerst alle Daten (am Anfang gibt es noch gar keine) und verarbeitet diese schließlich. Du hast also am Anfang noch gar kein Model.
Ich würde diese ganze Architektursache bei diesem Problem immer noch nicht anwenden.

Zur Implementierung: Wenn die Auswahl, welche *.dat in welchen Plot gehört, nicht zu komplex ist, lässt sich das ganze in ca. 40 - 50 Zeilen lösen, ich würde also mit OOP gar nicht erst anfangen.

Bin immer noch der Meinung du machst aus einer Mücke einen Elefanten...

dass ich einen elefanten mache, will ich gar nicht abstreiten. Es geht mir nur grundsätzlich darum das MCV kennen zu lernen.


Ich habe schon gehört, dass View (typischerweise) für den GUI-part gedacht ist.

"...Als View werden die Daten lediglich dargestellt und nicht verarbeitet..."
Das ist ja genau das, was ich gemeint habe. Die Daten liegen bereit, und View liest sie ein und generiert über gnuplot einen graphischen output.

"..Das passiert natürlich beim Plotten, denn du erzeugst neue Daten (==> eps Dateien)."

Gelten die Graphiken also als neue Daten? Das ist neu für mich, bisher habe ich das so aufgefasst, dass mit "Daten" nur die Daten gemeint sind, die durch die Simulation entstehen.

Ich habe das bisher so gesehen, dass der Controller quasi als "Cockpit" des Programms aufgefasst werden könnte. Von da wird die Simulation gestartet (-> Model). Die Simulation kann ja auf verschiedene Weisen erfolgen (mit 500, 1000 Teilchen, NVT-Ensemble, NH-Ensemble, etc). Nach der Simulation geht callt der Controller noch die View-Componente und startet die Datenverarbeitung.


Bin wahrscheinlich einfach ein bisschen zu fest auf Klassen fixiert...

mzh hat geschrieben:Gelten die Graphiken also als neue Daten? Das ist neu für mich, bisher habe ich das so aufgefasst, dass mit "Daten" nur die Daten gemeint sind, die durch die Simulation entstehen.

Ist natürlich auch Ansichtssache. Da du aber die Grafiken bzw. die Dateinamen im weiteren Verlauf noch verarbeitest (indem du sie in dein Latex-Dokument schreibst), würde ich sie schon wieder als neue Daten betrachten.

Die automatische Generierung von einem Latex-Dokument passt meiner Meinung nach einfach nicht ins MVC, da fehlt einfach der Benutzer-Part, der für das MVC eigentlich notwendig ist. Beim MVC generiert der Controller die Daten für die Anzeige ausgehend von einer Benutzerinteraktion, und diese werden dann im View dargestellt.
Für dein "Cockpit" fehlt einfach der Pilot

aha, ich glaube, jetzt verstehe ich besser, wie MVC gedacht ist. Mir war bisher nicht bewusst, das MVC so stark mit einer Benutzerinteraktion verbunden ist. So sieht die Sache natürlich ganz anders aus.