Zwei Prozesse abhängig voneinander ausführen
-
Hallo zusammen,
ist es möglich, dass wenn man ein altes Programm erneuern möchte (vor allem die GUI), zwei unterschiedliche Programme erstellt und die dann abhängig voneinander laufen lässt?
Ich meine damit, dass ich das alte Programm lasse wie es ist, nur das die Grafische Implementierung wegfällt. Die neue GUI möchte ich dann mit wxWidgets umsetzen, wobei die GUI ein eigenes Programm darstellen soll. Wenn nun auf ein Button der wxWidgets-Applikation gedrückt wird, soll das andere Programm zum EInsatz kommen und die Parameter der neuen wxWidgets -Application für seine Prozeduren verwenden. Wenn er dann fertig mit dem verarbeiten der Werte ist, sollen diese Werte wieder zurück an die GUI-Applikation gehen und angezeigt werden. Im Moment regel ich es so, dass ich wxWidgets direkt in das alte Programm integrier. Durch diese Herangehensweise wird aber das schon unübersichtliche alte Programm mit dem neuen wxWidgets-Code noch unübersichtlicher.
Nun wäre es schön, wenn man beide Programm einzeln für sich entwickeln könnte, wobei wxWidgets-Code in der wxWidgets-Applikation bleibt und umgekehrt mit dem anderen Programm.
Ist das prinzipiell möglich? Nach welchem Stichwort muss man für so eine Technik suchen? Ist dieses Verfahren schwer umzusetzen?
Schreibt mir einfach mal eure Erfahrungen...
Vielen Dank schon mal im Voraus!
Gruß
-
Das geht mit wxProcess.
Alternativ kannst du auch nachdenken, ob du nicht alles vernünftig neuschreibst, wenn du schon mal dabei bist
-
Hehe... danke schon mal für deine Antwort!
Das Problem ist, das deine Herangehensweise (also das komplette Neuschreiben) auch eine Überlegung ist, wie das Problem gelöst werden soll. Dabei ist die Aufgabenstellung, dass ich verschiedene Ansätze finden soll, um für ein altes Programm (seit 1990 entwickelt) die grafische Oberfläche neu zu entwickeln.
Ein Weg ist ganz klar eine komplette Neuentwicklung (auf Basis von wxWidgets). Dabei ist aber zu beachten, dass das Programm einen riesigen Umfang hat und daUnmassen von Mannjahre Arbeit drin stecken. Die andere Möglichkeit sehe ich, dass man wxWidgets-Code in das alte Programm einplegt und dadruch sukzessive die GUI aufbaut. Ist natürlich auch mit viel Arbeit verbunden, da man viele Einzelheiten beachten muss, damit der Workflow des Programms gleich bleibt.
Ich sehe jetzt noch die Möglichkeit eben mit den zwei Prozessen eine Lösungsvariante zu finden. Auch hier muss viel Arbeit reingesteckt werden, aber das Ergebnis ist vielleicht für die Zukunft eine bessere Ausgangsbasis für weitere Entwicklungen!
Hast du/ihr vielleicht noch Ratschläge oder Anregungen bezüglich neuer Lösungsvarianten?
Vielen Dank!!!
Gruß
-
Ich verstehe nicht so ganz, was bei zwei Prozessen übersichtlicher ist, als wenn man einen Prozess hat?
Meiner Meinung nach, hast du ein Design-Defizit, nämlich die Logik und Daten von der View zu trennen. Du (oder dein Vorgänger) hat sich an dieses Designkonzept nicht gehalten. Gut, das soll jetzt kein Vorwurf sein, da man nicht immer alles richtig macht (menschlich). Aber es ist einfach eine Feststellung, ohne Wertung.
Ich stelle mir das so vor: du hast eine alte GUI-Anwendung, die komplex ist. Du willst sie über eine andere GUI steuern, mit allem Pipapo? Meiner Meinung nach ein irrwitziges Vorhaben!
Warum? Weil man dann gleich die GUI in der alten Anwendung austauschen könnte. Die Arbeit wäre wohl die gleiche.Und was hast du davon, wenn du die zwei Prozesse hast? Die alte Anwendung ist immer noch mit der alten GUI ausgestattet plus der Prozesserweiterung. Plus der neuen GUI. Drei Baustellen machst du auf, wobei eine davon eine alte Baustelle ist, die sich nicht ändert oder bessert. Durch die Anbindung an die neu GUI per Prozess bastelst du sogar noch was dran
die alte wird noch komplexer! 
Ich würde die alte Anwendung mit einer neuen GUI austatten, dadurch macht man keine neue Baustelle auf, sondern man macht endlich mal die Baustelle, die existiert, fertig bzw. zu. Wenn dann gleich richtig machen!
Und dann kann man auch gleich überlegen, ob man nicht ein Model-View-Konzept anwendet. Also die Logik und Daten von der View trennt. Dadurch wird die alte Anwendung nicht noch komplexer, sondern endlich mal übersichtlich.
-
Hi Artchi, da gebe ich dir vollkommen Recht mit dem was du sagst! Das MVC-Konzept habe ich auch schon in meine Betrachtung aufgenommen. Vielleicht sollte ich noch klarstellen, das meine Aufgabe nicht darin besteht, die beste Möglichkeit gleich zu implementieren. Vielmehr soll ich verschiedene Lösungsvarianten, zu denen auch schlechte Lösungen gehören können, in Form einer Machbarkeitsstudie herausfinden. Natürlich wäre es schön, wenn ich dabei eine für uns beste Möglichkeit finde und diese dann auch zur gegebenen Zeit umsetzen kann. Doch pauschal zu sagen, dass man den Weg gehen soll (also den du vorgeschlagen hast) ist hier leider nicht ganz Sinn der Sache! Vermutlich wird es darauf hinauslaufen, dass deine Lösung genau die ist, die auch später dann durchgeführt wird, doch dazu müssen mehr Alternativen aufgezeigt werden, damit man eine fundierte Entscheidung treffen kann. Daher sehe ich auch die Möglichkeit, dass man das Konzept der zwei Prozessen wählt um diese Möglichkeit auch betrachtet zu haben.
Naja...
ich denke auch, dass für das Projekt ein Ansatz gewählt werden sollte, bei dem man eine umfassende Planung über Design-Patterns wählt. Dadruch lassen sich einige Probleme (auch für die Zukunft) besser bewältigen.
Trotzdem danke!
Wenn dir oder jemand anderem noch eine Variante einfällt, wie man ein Redesign einer alten Anwendung umsetzen kann, dann nur her mit den Ideen
Vielen Dank!
Gruß
-
Sehe ich ähnlich wie Artchi. Stück für Stück modernisieren und modularisieren.
Evtl. die GUI in eine eigene DLL packen, bzw. die bisherige Anwendung.
Dann kann man relativ einfach den neuen vom alten Code getrennt halten, und hat dennoch
alles in einer Anwendung.
-
Hallo Skluge,
die gleichen Gedanken mache ich mir auch im Moment. Habe eine relativ große alte VCL Anwendung die über Jahre gewachsen ist. Leider ist halt die GUI nicht wirklich von der Logik getrennt.
Meine Überlegung war nun dass ich die Logik des Programms aufteile in mehrere eigenständige Konsolenprogramme, welche mit mehr oder weniger komplizierten Parametern aufgerufen werden. Diese Programme sind erst einmal übersichtlicher (machen genau eine Aufgabe), kleiner und damit besser wartbar.
Die eigentliche Gui Anwendung (z.B. mit Hilfe von wxWidgets gemacht) würde dann als zentrale Stelle die verschiedenen Konsolenprogramme im Hintergrund aufrufen und wirklich nichts anderes machen als die grafische Bildschirmausgabe.
Das Zauberwort hier heisst dann IPC (Inter Process Communication), weil ja bei diesem Ansatz viel über die Prozesse hinaus kommuniziert werden muss.
Das Ganze von der Idee her wäre halt der typische Unix/Linux Ansatz. Die Frage an die Experten hier im Forum wäre jetzt von meiner Seite, inwiefern dieser Ansatz auch für Windows praktikabel ist. Soviel ich weiss ist dieser Ansatz zumindest nicht üblich für die Windowswelt.
Was würde dafür sprechen und was dagegen?
-
bergvagabund schrieb:
Was würde dafür sprechen und was dagegen?
Dafür spricht:
Du kannst die einzelnen Programme ohne GUI verwenden und unter Umständen leicht portieren.Dagegen spricht:
Du machst dir sehr sehr viel Arbeit. Du musst ja alle informationen, die du deinem Programm übergibst erst serialisieren und wieder deserialisieren. Und das ganze für die Rückrichtung auch. Sowas könnte man relativ leicht mit shared Memory machen, aber ich weis nicht, ob es das unter Windows gibt.Sinnvoller erscheint da, die Funktionalität in Klassen, statt in Programme zu kapseln.