Zusi und Stellwerke

Nachricht

Roland Ziegler · #41 Beitrag von **Roland Ziegler** » 12.04.2005 11:23:38

Wie aus Michaels und meinen Beiträgen heraus deutlich geworden sein dürfte, sind wir wir berufsalltagsbedingt große Anhänger formaler Vorgehensweisen

. Allerdings halte ich die Anwendung solcher Methoden auf ein von Enthusiasmus getriebenes Hobby-Projekt für ziemlich motivationstötend, vorsichtig ausgedrückt. Ich will damit nicht der Chaos-Programmierung Tor und Tür öffnen, sondern nur vor formalisiertem Overkill warnen.

Aber unbestritten ist sicherlich, dass man mit den Anwenderanforderungen anfangen sollte. Dies kann z.B. zunächst als Brainstorming geschehen. Was soll das System eigentlich tun? Ganz grob. Ob man dem eine Hülle gibt, z.B. UML Use Cases, ist noch die Frage. Aber jede Menge Anwender-Fachwissen ist hier ganz sicher gefragt.

Klar ist dann ja wohl, da es irgend eine Art Interaktion zwischen Zusi und Stellwerk geben wird. Und das sollte man man in der zweiten Phase einfach mal genauer diskustieren. Wie soll dann eine Rollenverteilung aussehen? Schon sind wir bei der Architektur.

Wenn dieses einigermaßen umrissen ist, sinnvollerweise irgendwie schriftlich, dann kann man sich mal ein paar Gedanken über die Umsetzung machen.

Ich selbst kombiniere durchaus Top-Down und Bottom-Up-Ansätze. Das am grünen Tisch konzipierte muss auf geeignete Weise implementiert werden. Und da spielen Technologien eine Rolle. Man kann das Rad neu erfinden, oder man kann fertige Räder einsetzen und zuschneiden, auf vielen Ebenen.

Zum Bottom-Up-Teil will ich noch ein paar Sätze mehr äußern: In diesem System werden verschiedene Prozesse miteinander sprechen. Es wird also ein Kommunikationsprotokoll zwischen den Prozessen erforderlich werden. Wie komplex wird denn der Informationsaustausch? Weiß man das oder will man sich das offen halten? Reicht ein so simples Protokoll, wie das im derzeitigen TCP/IP-Demonstrator realisiert ist, oder kommen umfangreichere Anforderungen hinzu? Ist der Datenaustausch beschränkt auf einfache asynchrone Messages? Oder dienen asynchrone Messages zur Verpackung einer synchronen Logik? Wer spricht miteienander? Prozesse? Oder doch Objekte? Benötigt man evtl sogar einen Transaktionsmechanismus?

Wenn man überraschenderweise feststellen sollte, dass man auf der Ebene von Objekten miteinander sprechen wird, dann stellt sich direkt die Frage, ob man nicht auf eine fertige Middleware aufsetzen will, um eben nicht das Rad neu zu erfinden. Remote Objects sind nicht immer so kompliziert, wie sie erscheinen. CORBA mag die bekannteste Lösung sein, aber es ist wohl tatsächlich auch eine der komplexesten. Enterprise Java Beans sind eine andere, deutlich einfacher zu nutzende, aber sprachabhängige. DCOM ist überholt. Durch was? Durch .Net Remoting. Und .Net Remoting ist das für den Anwender simpelste, was ich bisher gesehen habe.

Aber Zusi ist in Delphi geschrieben. Ist das noch ein Widerspruch? Hieß es nicht, dass Delphi 2005 die Kombination aus klassisch Win32 und .Net ermöglicht? Wenn dem so ist, dann könnte man dieses nutzen. In C++ geht das schon länger und dort habe ich es mit Erfolg ausprobieren können, wenn auch die bisherige Umsetzung "Managed C++" etwas ätzend war. So könnten fürs Stellwerk die Kommunikationskomponenten auf .Net-Features aufsetzen und damit den Anwendungsentwickler gewaltig entlasten. .Net gilt an vielen Stellen als ausgesprochen durchdacht und elegant, der Kommunikationsteil gehört dazu, auch und gerade in der inneren Struktur.

Just my 2 cents.

Andreas Karg · #42 Beitrag von **Andreas Karg** » 12.04.2005 11:57:27

Ich schlage vor, wir treffen uns einfach mal alle irgendwo im IRC, Entwickler wie Anwender, und brainstormen ein wenig gemeinsam.

Daniel Rüscher aka Merlin · 12.04.2005 18:21:57

Ich würde da einen IRC Chat auch vorschlagen, als digitales Meeting quasi.

Zum schriftlichen Festhalten hatte ich das Forum gedacht.

Einen Gedanken zum Aufbau möchte ich auch noch loswerden, weil der mir grade so im Kopf rumspukt:

Die DB AG (respektive damals noch DB zusammen mit Siemens, AEG und SEL) haben ja schon ein Stellwerk auf EDV Basis entwickelt. Also wäre es doch recht sinnvoll wenn wir uns an deren Strukturen halten und uns daran orientieren.
Ein ESTW ist folgendermaßen aufgebaut. Es gibt 3 Ebenen:

+ Ebene 1: Die Benutzeroberfläche, zuständig für die Anzeige und Aufnahme der Befehle. Für Zusi würde das Quasi heißen das diese Ebene die Bunten Bildchen erzeugt und die Clicks auf die Signale annimmt. Verarbeitet diese und sendet sie an dei Mittelschicht weiter.

+ Ebene 2: Der eigentliche Kern: nimmt die Anforderungen von der ersten Ebene ab, prüft diese auf Plausibelität und ob das drumherum Passt (Verschlüsse, Fahrstraßen etc.). Nach der Prüfung werden die Anfforderungen für weichen Signale und so weiter an die unterste Ebene weitergeleitet. Selbiges soll sie auch bei Zusi tun.

+ Ebene 3: Die Außenanlagen: In der Realwelt werden damit normalerweise die Relais gemeintAlso quasi die Steuerung der Signale direkt in den Verteilern entlang der Strecke. In Zusi könnte man damit die Komunikation mit Zusi vorsehen.

Das ganze funktioniert natürlich Bidirektional, also wenn ne Lampe durchbrennt Meldet das die Unterrste an die Mittlere und die Mittlere an die Oberste Ebene.

Hat den Vorteil das man nich für jede Bauart alles neu programmieren muss. Für ESTW (S und L) und SpDr (Alle Bauarten) muss man bloß die erste Ebene wechseln, für Mech und EMech nur die erste und zweite (Wobei man das mit geschickter Programmiereung auch lösen kann indem man nur die Hilfshandlungen bgenutzt.)

Auf die ganze Architekturgeschichte wird auf http://www.stellwerke.de/formen/seite2_5.html ff noch genauer eingegangen, auch grafisch.

Als Transportprotokoll zwischen den Ebenen würde ich TCP/IP vorschlagen, da das routbar ist, und das konzept der Ortsungebundenheit vereinfacht (Erste ebene kann ganz wo anders sein als die zweite.)

So das war erstmal n kleiner Gedankenansatz von mir

Gruß

Daniel

Andreas Karg · #44 Beitrag von **Andreas Karg** » 12.04.2005 21:21:21

Welchen Sinn macht TCP/IP zwischen erster und zweiter Ebene? Zwischen zwei Einheiten der zweiten Ebene (Vernetzung verschiedener Stellbereiche) macht es Sinn, und zwischen Stellsi und Zusi auch. Aber Darstellung und Simulation der Anlagen fallen für mich in eine Anwendung, oder zumindest auf den selben Rechner. Wir müssen ja nicht das ESTW-Konzept 1:1 übernehmen und in die Systemanforderungen "Großrechner im Keller, TCP/IP-fähig" schreiben.

#45 Beitrag von **Max Senft** » 12.04.2005 21:32:05

Heyho!

Also ich bin mir grad auch nicht so sicher, ob dieses Client/Server Prinzip für ein "Subprogramm" für Zusi nochmal notwendig ist? Irgendwann hat man da noch zig Server aufm Rechner laufen, da wird man ja noch irre (außer man ists schon).
Ich würde dieses Stellsi/Stellclient/Stellgedöns ebend wieder als Client für den Zusi-Sörfah gestallten. Vielleicht bekommt man ja mal ein gescheites Interface auf DLL-Basis hin, das dann für die spätere Darstellung geeignet ist? (DLL-Plugins gibts ja schließlich auch bei anderen Progs [Miranda z.B.]).

Das wäre eher so meine Idee, aber wieso reden wir überhaupt schon über die Programmierarbeit, wenn wir vielleicht erstmal darüber reden müssen, was wir überhaupt wollen? *g*

Aaaaaber (lieber Merrlin): Ich würde auch nicht alles zu stark verkomplizieren, ein einfaches Brainschdorming sollte am Anfang mal genügen? Eben nicht nur Programmierer oder Verwirklichen-Woller, sondern auch Fdls, die da doch etwas mehr Ahnung haben. Außerdem: Ich weiß ja nich wie die Fdl-Ausbildung aussieht, aber man sollte auch Leute haben, die versch. Stellwerkstechniken kennen und wissen worauf es ankommt, nicht dass da am Schluss 10 ESTWler im Chat sitzen...

Auf jeden Fall aber sollten doch die Programmierer auch dabei sein, denn die müssen sich ja auch schonmal Gedanken machen, wie das denn nun umzusetzen wäre, können ja dann ihrer verkorksten literarischen Ader freien Lauf lassen und mitnander in ner anderen Sprache sprechen (oder wie war das? @Michael *fg*)

So viel erstmal dazu...

Bye
Max Senft

Daniel Rüscher aka Merlin · 12.04.2005 21:56:20

Naja: Humoristisch erklärt: Damit der liebe Andi nich schnell nach Traunreut fahren muss weil der liebe Daniel vergessen hat die Ausfahrt zu ziehen weil er grad mit Max in Blieskastel den GWB per Voicekom ausmacht während Heiko in Augsburg quengelt weil er mit seinem IC Richtung Salzburg aus Rosenheim keine Ausfahrt bekommt.

Technisch klingts nüchterner: Es entsteht einfach zwischen Bedienplatz (1. Ebene) und ESTW-Z (2. Ebene) wesentlich weniger Netzlast wie zwischen ESTW-Z und ESTW-A (3. Ebene) und Zusi. Und nebenbei kann man mit TCP/IP auch hergehn und an die Mittelschicht wahlweise ne ESTW oder SpDr Bedienoberfläche anschließen.

Thema Voicekom (hatte ich ja oben schon erwähnt): wir sollten vieleicht nen kleinen Voicechat per Dx9 implementieren um die Telefonkosten der beteiligten nicht in die höhe schnellen zu lassen.

Ich mein das sind ja nur Vorschläge, da wir nochnichtmal wirklich in der Brainstormingphase sind

Daniel

Daniel Rüscher aka Merlin · 12.04.2005 22:04:47

Naja Max, wir sollten das Programm aber auf eine vernünftige Basis stellen. Ich bin einfach mal von ActiF ausgegangen, da werden mehrere Releases angestrebt. Wir können ja hergehen und das erste Release so prograsmmieren das es nix anderes kann als Fahrstraße einstellen und wieder auflösen, mit ESTW Oberfläche. Im 2ten Release kommen dann Rangierstraßen dazu, und nach dem xten Release beherscht das Ding dann ETCS Level 1-3 und die Bahn engfargiert uns alle weil unser System wenigstens funktioniert

Andreas Karg · #48 Beitrag von **Andreas Karg** » 12.04.2005 22:06:24

Naja, Daniel! Verrat mir mal einen Grund, wieso erste und zweite Ebene nicht auf dem selben Rechner laufen sollten! Dass man verschiedene Stellbereiche verknüpfen können sollte ist klar, aber das betrifft alles die zweiten Ebenen untereinander.

#49 Beitrag von **Max Senft** » 12.04.2005 22:27:04

Ich weiß ja nich, was du alles zwischen Stellprog und Zusi (über Zusi-Server) hin und herschicken willst, aber wie gesagt: Wir sollten uns erstmal klar machen, was wir überhaupt wollen, bevor wir uns gegenseitig die Birne einschlagen wie wir das machen...

Und schließlich hat Carsten auch noch ein Wörtchen mitzureden (und vielleicht auch den ein oder anderen programmiertechnischen Tipp oder so...).

Noch was: Ich weiß nicht, ob ich dich vielleicht falsch verstanden hab: Wenn ja, erklärs mir nochmal. *g* Ansonsten: Ich versteh nicht, wieso es mehr Traffic geben sollte, wenn mehrere Stellclients auf einen Zusi-Server verbunden sind, wie wenn mehrere Stellclients erst mit nem Stellserver verbunden sind, der dann wiederrum mit nem Zusi-Server verbunden ist. *wirr*

Buy
Max Senft

Daniel Rüscher aka Merlin · 12.04.2005 23:05:29

Sie können ja auf dem Selben Rechner laufen, hab ich ja nix dagegen gesagt. es geht da Primär um die Netzlast. Mal n kleines Beispiel wie die Kommunikation im fertigen Zustand (dann irgendwann mal) aussehen könnte:

Code: Alles auswählen

Bedienplatz --> Zusi

Click Start
Click Ziel
  |
  |
Empfang                               }
Verarbeitung (Prüfung etc.)
Weiche 1 Stellbefehl
Weiche 2 Stellbefehl
Weiche 3 Stellbefehl                   In den Block wursteln auch noch LZB
Weiche 4 Stellbefehl                   und Co. rein
Signal A Stellung Hp1
Signal P Stellung Hp1            }
  |
  |
Empfang
Verarbeitung
Sendung des Obengenannten an Zusi (samt LZB und so)

Da kommt schon was zusammen zwischen zweiter und dritter Ebene.

Das ganze noch in die Andere Richtung

Code: Alles auswählen

Zusi --> Bedienplatz

Stellung der Signale
Stellung der Weichen
Belegtzustand usw.
  |
  |
Verarbeitung 
  |
  |
Empfang der ganzen Stellungen usw.
Verarbeitung
Senden der Signalstellung und Elementfarbe (respektive Elementzustand; Mit Element ist hier z.B. ne Weiche gemeint)
(Eventuell senden eines "Anzeige ist sicher" Bits)
  |
  |
Anzeige

Man sieht also das zwischen Der ersten und der zweiten Ebene relativ wenig Verkehr herscht was sich natürlich die Laufzeit eines gesamten Stellbefehls (vom Absenden bis zum Empfangen der gesicherten Fahrstraßenausleuchtung) positiv auf die Laufzeit auswirkt.

Dieses Schema erhebt natürlich bei weitem keinen Anspruch auf Vollständigkeit oder Richtigkeit, aber es zeigt wohl doch schon die Richtung auf.

Mit dieser Aufteilung ist man halt sehr flexibel. Man kann als Einmann Bahnunternehmen mit Fahrdienstleiter und Lokführer in Personalunion agieren, ebenso wie auf einer Riesen LAN wo Dutzende Fahrdienstleiter Hunderte Menschliche Züge fahren lassen (sehr theoretisches Beispiel). Ebenso ist es möglich das man streng Trennt genauso wie jeder FDL übernimmt ein Richtungsgleis genauso wie 1 FDL kümmert sich nur um die Störung, und der 2. übernimmt den Stellbereich des ersten mit.
Nebenbei hat man so auch die Möglichkeit die einzelnen Module während der laufenden Simulation zu wechseln.

Ist halt alles nur ein Denkansatz, da is nur n kleiner Gedankenteil an die eigentliche Machbarkeit gerichtet worden.

Nochmal @Max: Hatte das grad beim Beitragschreiben gelesen. Es geht nicht um den Trafic der für die Server entsteht, sondern um den Trafic der über das Netzwerk selbst geht also z.B. Inet.

Ich hoff einfach mal das du mich jetzt n bißchen besser Verstehst.

Daniel Schuhmann · #51 Beitrag von **Daniel Schuhmann** » 12.04.2005 23:36:00

Ich will Dich ja jetzt nicht beunruhigen, aber irgendwie geht das jetzt doch schon ein bissel *zu* sehr ins Detail, dafür dass wir doch erstmal die grundlegenden Dinge besprechen wollten?!

Aber noch bissel was zu Deinen Ausführungen:
Die Frage ist doch auch, ob mit der ganzen Verarbeitungsgeschichte nicht Zusi das Wasser abgegraben wird. Zusi (oder vielmehr die Strecke) kennt die Fahrstraßen und hat seinen eigenen "Verschlußplan". Was das Stellwerk nun meiner Meinung nach nur machen würde, wäre:
Anfrage für Fahrstraße von Adorf Gleis 1 nach Grützendorf Gleis 4 stellen. Zusi sagt dann obs passt oder ob es Gülle war. Da genügen ganz wenige Daten für. Wenns paßt, wird die Geschichte eingestellt: Das Stellwerk weiß ja, wie sowas geht und Zusi auch. Zusi müßte dann bei der schrittweisen Auflösung des Fahrwegs noch ein paar Infos rüberwachsen lassen, ob die dann sofort (ESTW, Spurplan) oder erst ganz zum Schluß (Mechanik) verarbeitet werden, ist dem Stellwerk selbst überlassen.

Was die vielen Prozesse mit ihrer TCP-Verbindung angeht: Genügt nicht ein einfacher Prozess "Stellsi.exe", der sich als Client mit dem TCP-Server verbindet (das können ja auch mehrere sein, für verschiedene Bf halt). Stellsi selbst ist ein "dummes Programm ohne Oberfläche" und hat dann über ein wie auch immer geartetes Plugin-System (DLL, XML-Infodatei, EXE, Whatever) eine Verbindung mit dem grafischen Userinterface, wo dann eben ja nach Epoche Stellhebel, Drehknöpfe, ein Spurplanstelltisch oder eben eine ETST-Anzeige zu sehen sind.

Das waren meine 5,96 Euro...

Edit: Den letzten Satz so ausgeschmückt, daß man auch was versteht, ohne ihn 5 mal zu lesen. Und letzten Endes, wer wollte das bestreiten.

13.04.2005 00:15:04

ich behaupte mal, daß ohne mich die Geschichte sowieso nicht zielgerichtet angegangen werden kann, da man das ganze ja auf die inneren Strukturen des Zusi abstimmen muß und die kenne wohl nucr ich so halbwegs ausreichend.

Die Diskussion fand dich z.T. etwas seltsam. Ich habe zwar keine Ahnung von Pfau-Modellen&Co, aber ich würde im ersten Schritt zunächst mal meine Anforderungen sammeln, ganz grundlegend, welche Info muß von wo nach wo usw., dann das ganze sortieren und dann kann man sich mal langsam Gedanken machen, wie man das Projekt angehen will.

Carsten

#53 Beitrag von **Max Senft** » 13.04.2005 00:18:56

Carsten Hölscher hat geschrieben:Die Diskussion fand dich z.T. etwas seltsam. Ich habe zwar keine Ahnung von Pfau-Modellen&Co, aber ich würde im ersten Schritt zunächst mal meine Anforderungen sammeln, ganz grundlegend, welche Info muß von wo nach wo usw., dann das ganze sortieren und dann kann man sich mal langsam Gedanken machen, wie man das Projekt angehen will.

Rischdiiiiisch... (hab ich das vorhin nich auch schonmal gesagt? *hm*)

Ich habe nur die Erfahrung von eigenen kleinen Projekten, und da war das bisher eigentlich immer so, dass man sich da mal erstmal zusammengesetzt hat (falls das nich ging per mail) und dann hat man mal was testweise und so als Anschauungsobjekt zusammengefrickelt ... dann gings weiter. (Gell?! @Frank Wenzel *hust*)

Und das ganz ohne Zusatzsoftware, nur mit Stift+Zettel+eMailprog(ok, Notepad war auch mal im Einsatz, aber nur weil ich keinen Stift/Zettel zur Hand hatte *pfeif*).

Bye
Max Senft

13.04.2005 00:20:32

doch doch, nur für den Fall daß meine Meinung interessiert habe ich das mal hingeschrieben....(auch eher Zettel+Bleistift-Entwerfer)

Carsten

Daniel Rüscher aka Merlin · 13.04.2005 08:16:54

So ähnlich hatte ich das ja auch gemeint Daniel. Ich hab halt nur schon etwas weiter gedacht. Am Anfang reicht sicherlich eine einfache Geschichte die Nur Fahrstraßenanforderung und Fahrstraßenrücknahme kennt. Das lässt sich dann ja erweitern.

Die Dreiteilung hatte ich nur der Universellität wegen gewählt. Also eine Bedienoberfläche ein Kern und ein Connector, jeweils als eigenes Programm. Wenn man jetzt alleine ist und nur Stellwerken will dann tauscht man einfach den Connector aus (bzw. verbindet). Der eine macht die Kommunikation mit Zusi und der neue generiert dann halt Scheinzüge (vieleicht nach Zusifahrplan?).
Oder ein dritter Connector macht die Steuerung einer Modellbahn möglich, ohne das davon die anderen Programme was mitbekommen, oder das man dadran irgendwas ändern müsste.

Aber wie gesagt, ein Chat bezüglich eines ersten Brainstormings wäre mit Sicherheit mehr als angebracht.
Gibt es diesbezüglich Terminvorschläge? Ich stelle jetzt einfach mal Sonntag Abend um 20 Uhr zur Debatte. (Wobei es bei mir sein kann das ich n bißchen später komm, je nach Verkehr von Chemnitz hier runter)

Bezüglich Informationsaustausch warte ich immernoch auf ein Unterforum, hat nämlich den Vorteil das im Gegensatz zu EMail jeder Beteiligte sofort im Bilde ist und es auch einfach Schöner zum Lesen ist.

Gruß

Daniel

Michael_Poschmann · 13.04.2005 10:05:53

Carsten Hölscher hat geschrieben:... da man das ganze ja auf die inneren Strukturen des Zusi abstimmen muß und die kenne wohl nucr ich so halbwegs ausreichend.

Dem läßt sich durch Dokumentation sicher abhelfen...

Anregung eines nur halb Betroffenen: Vielleicht wäre der Aspekt "Rangieren" eine Überlegung wert. Einzelnes Umstellen von Weichen, keine Fahrstraßen ("DrS2-Modus") Freigabe gewisser Spurlplanbereiche für Rangiertätigkeiten, dabei Sperren gegen das Einstellen von Fahrstraßen, ...

Setzt natürlich eine Gleisbelegungs- bzw. Fahrzeugerkennungsroutine seitens des Simulators voraus und ist daher eher ein Fietscher von Zusi 4 ff. Aber man könnte ja konzeptionell diesen Herzenswunsch schon einmal berücksichtigen.

Michael

Roland Ziegler · #57 Beitrag von **Roland Ziegler** » 13.04.2005 10:36:17

Was inzwischen klar sein sollte: Erst die Anwenderanforderungen sammeln, und hier insbesondere auch die mögliche Ablauflogik vom Prinzip her mit Zusi klären. UML kann hierbei hilfreich sein, ist aber sicher keine Vorbedingung. Und zu diesem Zeitpunkt ist eine mögliche Umsetzung noch ziemlich nebensächlich.

Ich glaube übrigens nicht, dass ein Chat für ein Brainstorming eine geeignete Diskussionsplattform ist. So was malt man auf. Da wird üblicherweise sehr viel skizziert und sehr viel Papier verbraucht.

Erst, wenn die Anwenderanforderungen rund sind, man also alle wichtigen Abläufe und Strukturen durchgesprochen hat, kann man mit der Architektur anfangen. Und dazu gehört dann auch eine Analyse von verfügbaren Technologien.

Im Moment habe ich ein klein wenig die Befürchtung, das Projekt könnte gleichzeitig zu klein und zu groß aufgehängt werden.

Trotzdem noch etwas zum Unterthema Materialsammlung und insbesondere Kommunikationstechniken (für später, nicht für die Anwenderanforderungen):
Microsoft hat schon in den 90ern zu COM-Zeiten eine recht klare Strukur definiert, wie auf OO-Basis in einer Client/Server-Umgebung miteinander gesprochen werden kann:

In-Process Server: Das Server-Objekt lebt in einer DLL, die statisch oder dynamisch dazugebunden wird.
Local Server: Das Server-Objekt lebt in einem eigenen Prozess (in dem auch andere Server-Objekte residieren können) auf der selben Maschine.
Remote Server: Das Server Objekt lebt in einem eigenen Prozess (in dem auch andere Server-Objekte residieren können) auf einer anderen Maschine.

Bei COM gehörte die Vewaltung der verschiedenen Lösungen bereits dazu. .Net folgt derselben Architektur. (Übrigens, einige der erwähnten Techniken benutzen TCP/IP, das ist also kein Widerspruch zu anderen hier aufgegführten Vorstellungen)

#58 Beitrag von **Max Senft** » 13.04.2005 11:21:13

Heyho!

Ich dachte es soll in Zusi 3 auch Rangier"fahrstraßen" geben?! Was ich meine: Wir wissen ja gar nicht, wie es Seitens "Zusi 3" aussieht, vielleicht bietet das ja passable Möglichkeiten an, die vorerst reichen?! Aber wen soll man da fragen, wenn nochnichmal Carsten weiß, was er da programmiert?! *g*

Nee, jetz mal im Ernst. Carsten hätte ja bei Zusi auch zig Programme nehmen können, z.B. Client/Server-Variante, Server berechnet die Strecken und die Umgebung und der Client ist nur ein "Dummes" Anzeigeprogramm mit Eingabemöglichkeit. Wobei das ja noch Sinn macht und schließlich im Bereich 3D-Shooter weit verbreitet ist. Gleichzeitiger Vorteil wäre gewesen, dann auch z.B. Linux/Unix-Derivate des Server zu erstellen, dass man z.B. nen Internetserver aufstellen könnte, aber ich schweife grad etwas zu weit ab...

Naja, aber ich weiß echt nicht. Wäre es denn nicht - wenn wir denn überhaupt mal bis zum Programmieren kommen - mit ner DLL-Pluginvariante getan? Da könnwer ja dann ein Modell Protokoll-DLL <> Stellwerksprogramm <> Interface-DLL machen, wäre ja wohl so ungefähr das, was Merrlin vorgeschlagen hat. Dabei stellt sich mir aber wieder die Frage, wieso man noch ein Modellbahnsteuerungsprogramm erstellen will? *g* Gibts da nich schon genügend?

Man sollte sich erstmal klar machen, was man will, vielleicht bekommt man die verschiedenen Visionen ja doch noch unter einen Hut... das mit dem Chat find ich ... nuja ... naja, letzter Ausweg, aber ich wäre dann doch eher mal für ein Leben im realen Leben. *g*

So denn,
Max Senft

Roland Ziegler · #59 Beitrag von **Roland Ziegler** » 13.04.2005 11:38:52

Max, die Reihenfolge bleibt weiterhin:
1. Welches Problem soll gelöst werden?
2. Wie setzt man das um?
Nicht umgekehrt.

Was ich ausdrücken wollte: Es gibt für Standardaufgaben der Kommunikation Standardlösungen. Und davor warnen will, das Rad neu zu erfinden. Aber: Wer z.B. Client und Server spielt, ist doch im Moment vollkommen unerheblich.

Man muss da schon etwas stärker systemanalytisch ran

. (aber ohne formalen Overkill)

Michael_Poschmann · 13.04.2005 11:58:40

Roland Ziegler hat geschrieben:Ich glaube übrigens nicht, dass ein Chat für ein Brainstorming eine geeignete Diskussionsplattform ist. So was malt man auf. Da wird üblicherweise sehr viel skizziert und sehr viel Papier verbraucht.

Wahlweise auch Whiteboards mit plastischer (mehrschichtiger) Malerei bedeckt.

Roland Ziegler hat geschrieben:... Anwenderanforderungen rund...

Da ist es - das *gebührendpflichtige* Wort! Mit "abrunden", "rund machen" etc. wird man todsicher Sieger im Bullshit-Bingo...

Roland Ziegler hat geschrieben:Max, die Reihenfolge bleibt weiterhin:
1. Welches Problem soll gelöst werden?
2. Wie setzt man das um?

Guter Hinweis, ich hatte mich auch schon ein wenig gewundert, daß hier zahlreiche Lösungen en detail diskutiert wurden, zu denen sich vermutlich bei genauer und intensiver Recherche auch passende Probleme finden ließen.

Roland Ziegler hat geschrieben: Man muss da schon etwas stärker systemanalytisch ran

Hier fehlt der Hinweis auf die anzusetzende Stundenpauschale - oder soll's ein "Freundschafts-Komplettpreis" werden?

Gruß
Michael