Suche Ideen für den Aufbau eines neuen Programms

Hallo Zusammen,

nachdem ich es jetzt geschafft habe meinen Parser für das Projekt fertig zu schreiben und mit LaTeX drucken kann, ist das ja nicht nur zur Deko da.

Aufgabe ist jetzt
1. unser hauseigenes Geräte abfragen (Welches Gerät? Kommunikation habe ich),
_ a. COM-Ports durchsuchen, Kommunikationsart durchsuchen (aus XML),
_ b. Liste Angeschlossener Geräte anzeigen.
2. aus der geladenen XML die zu den Geräten passende Parameter rauszusuchen (Parameter-Filter habe ich),
3. diese Parameter dann auf Knopfdruck vom Gerät abfragen,
4. Entsprechend der Sprachauswahl die Übersetzung aus der XML nehmen und
5. Das in eine .tex-Datei schreiben und drucken.
Extra: Das Programm belegt zwischen 2. und 3. nicht dauerhaft den COM-Port (kein Problem) kann aber System-Befehle empfangen/senden.

Mir schwebt eine State-Machine vor, einfach, es gibt nur einen Rücksprung (Bei Fehler). Damit habe ich schon angefangen,
Irgendwie habe ich aber das Gefühl eine Producer-Consumer könnte vielleicht besser geeignet sein oder gar etwas ganz anderes, wo ich einfach nicht dran gedacht habe.

Deswegen meine Frage, wie würdet Ihr, mit Eurer Erfahrung, so etwas angehen?

Danke, Timo

Hallo Timo,

die Frage kann nicht beantwortet werden. Softwareentwicklung ist ein kreativer Prozess. Alles ist richtig, was zum Ziel führt. Ok, es gibt ein paar Dinge, die sollte man nicht tun, weil sie in eine Sackgasse führen, aber davon abgesehen ist erst einmal alles möglich.

Was verstehst du unter "Producer-Consumer". So ein ganz klassisches Producer-Consumer Design kommt mir immer so vor wie aus den Anfängen von LabVIEW - nichts was ich heute noch machen würde (fand ich auch damals schon seltsam). Die ganz modernen Designs sind ja auch alle ganz nett, aber wenn das Endprodukt validiert werden soll (z.B. im Bereich Medizintechnik oder ähnlich kritische Dinge), dann sind solche Designs eher schwierig, weil die Validierung extrem zeitaufwendig werden könnte. Da sind Abläufe, welche für einen Dritten leichter nachvollziehbar sind, die bessere Wahl. Aber auch das gilt bei weitem nicht immer. So pauschal gibt es nichts, was gut oder was schlecht ist. Ziemlich viel liegt auch an deinen persönlichen Vorlieben, was du kennst, was du kannst, was du dir selbst zutraust, wie viel Zeit dir dafür zur Verfügung steht ...

Viel wichtiger als sich auf irgend ein Standardisiertes Design festzulegen ist es, darauf zu achten, dass du dir möglchst nichts selbst verbaust. Da kommt vielleicht irgendwann eine Anforderung, an du nie zuvor gedacht hast und das sollte sich dann auch noch mit möglichst wenig Aufwand implementieren lassen ohne dass dein Programm zum Spaghettiteller mutiert und jeder aus 50 Meter Entfernung auf deinem Monitor sieht, dass du Unsinn programmiert hast.

Mit einer State-Machine machst du erst einmal nichts komplett falsch - funktioniert irgendwie immer und kann, falls nötig, auch angepasst werden.

Ich gehe jetzt glaub erst mal zum Hühnerforum - da gibts auch so lustige Fragen wie "was soll ich meinen Hühnern füttern" :-)

Hi Timo,

State-Machine und Procuder/Consumer schließen sich ja nicht aus. Du kannst z.B. Consumer erstellen und testen, die dann eben nur LaTex, Messgeräte etc. pp. handhaben und die finale Steuerung dann mit einer State-Maschine realisieren.

Bei den Frameworks würde ich nicht mehr zum QMH von NI greifen, sondern zum DQMH von Delacor. Gerade der Tester ist eine schöne Eigenschaft, die man beim QMH sich schön selber bauen darf.
Schön ist auch, das man sich über den Weg, wie die Daten in das Modul oder aus dem Modul kommen keine Gedanken machen muss. Das ist hier auch geregelt.
Mir ist bewusst, das der diverse Nachteile hat, hat QMH aber auch.

Bei der Dokumentation lohnt es sich einen Blick auf "UML Sequenz Diagramme" zu werfen.

Gruß Max

(16.12.2020 13:29 )Martin.Henz schrieb:  ..die Frage kann nicht beantwortet werden. ..

Meine eigentliche Frage war ja wie IHR / DU das machen würdest. Gut möglich, dass ich noch nie was davon gehört habe oder es für mein Können nicht geeignet ist. Dennnoch lernt man am Besten, wenn man sich Ideen einholt und nicht immer in nur seine eigenen Beispiele sieht.

Zitat:Softwareentwicklung ist ein kreativer Prozess.

Eher ein logischer Prozess, weil kreative bin ich nicht und meine Programme ... öhm .. ok .. ja, doch, kreativer Prozess, hast recht.

(16.12.2020 15:34 )MScz schrieb:  State-Machine und Procuder/Consumer schließen sich ja nicht aus. Du kannst z.B. Consumer erstellen und testen, die dann eben nur LaTex, Messgeräte etc. pp. handhaben und die finale Steuerung dann mit einer State-Maschine realisieren.

Stimmt, das könnte mir tatsächlich gefallen bei der Aufgabe, danke.

Zitat:Bei den Frameworks würde ich nicht mehr zum QMH von NI greifen, sondern zum DQMH von Delacor. Gerade der Tester ist eine schöne Eigenschaft, die man beim QMH sich schön selber bauen darf.
Schön ist auch, das man sich über den Weg, wie die Daten in das Modul oder aus dem Modul kommen keine Gedanken machen muss. Das ist hier auch geregelt.
Mir ist bewusst, das der diverse Nachteile hat, hat QMH aber auch.

Seit dem Projekt arbeite ich auch gerne mit DQMH, finde es aber persönlich doch etwas unübersichtlicher als eine State-Machine, man braucht immer ein vielfaches an Schritten für einen Befehl.

Zitat:Bei der Dokumentation lohnt es sich einen Blick auf "UML Sequenz Diagramme" zu werfen.

Schau ich mir mal an, eine Doku muss ich für diese Programm aber nicht machen, glücklicherweise

Dank Euch
Timo

Zum Mehraufwand:
Kommt auf die Betrachtung an. Wenn du z.B. bei einer QMH immer gerne alles als Typ.Def übergibst und einen Tester haben möchtest, dürfte DQMH da schneller und weniger Aufwand sein. Betrachtet man nur den reinen Programmcode, hast du recht. Der Tester hat mich schon oft gerettet, auch wenn ich es lästig finde ihn zu Pflegen.

Zur Doku:
Ein paar Pfeile und Linien, die dir zeigen wer was macht, sind aber in Zukunft besser zu verstehen und helfen dir auch Probleme/Abläufe zu erkennen.
Das erste mal ist man da recht langsam mit, aber die Zeit holt man sich in Zukunft locker wieder rein.

Gruß Max