Michael Poschmann hat geschrieben:das *gebührendpflichtige* Wort! Mit "abrunden", "rund machen" etc. wird man todsicher Sieger
Nun, es soll ja gerüchteweise durchaus SW-Projekte gegeben haben, an denen mehr als eine Person beteiligt war, und die ihr Ziel trotzdem erreicht haben. "Rund" ist für mich vor allem einmal "in sich schlüssig" und "umsetzbar".
Zusätzlich machen wir selbst einen Teil der Anwenderschaft aus, auch deswegen sollte es wohl gelingen, die Aufgabenstellung einigermaßen umrissen zu bekommen. Da bin ich durchaus optimistisch.
Wahlweise auch Whiteboards mit plastischer (mehrschichtiger) Malerei bedeckt.
Soll ich mal nachfragen, ob's zur Ausstattung gehört?
Naja am Digitalen Whiteboard solls nicht scheitern, es gibt ja auch NetMeeting. Andere Vorschläge können und sollen natürlich auch vorgeschlagen werden
also on-line halte ich das nicht für zweckmäßig. Das kriege ich soweiso nicht gebacken. Die Zusi-seitigen Strukturen sind soweit halbwegs klar. Aber nur mit einer Doku sollte man das Thema nicht angehen.
Ein eigenes Forum halte ich bei einem Umfang von 1 bis 2 Threads bis auf weiteres für überflüssig.
Im ersten Schritt brauchen wir sowieso eher Stellwerker bzw. ihr Wissen.
Naja, irgendwie sollten wir ja ein Brainstorming veranstalten, und Treffen geht da wohl recht schwerlich, also muss es wohl auf eine Andere Weise passieren
Hallo
das heißt ihr benötigt die notwendigen Bedienhandlungen die Notwendig sind um eine Zugfahrt durchzuführen.
Da es unterschiedliche Stellwerksbauarten gibt sind auch unterschiedliche Bedienhandlungen notwendig.Im mechanischen mehr als im elektrischen Stellwerk.
dann wirft sich die Frage auf ist ein Wärterstellwerk vorhanden.
Gleichzeitig zu den Bedienhandlungen müssen die Sicherungskriterien anfangen zu wirken.(Verschlußtafel= Ausschlüsse und Flankenschutz)
Bei der Blockbedienung (Bahnhofsblock wenn Wärterstellwerk vorhanden)
Streckenblock dann beide.Da wäre noch zu berücksichtigen ist die Strecke Eingleisig oder Zweigleisig.
Das sollten erst eimal ein paar Grundgedanken sein,die ich jederzeit noch präzisieren und Ausführlicher erläutern kann.
Mfg
Lutz
Strecken-, Signal- & Fahrzeugbau Elstertal
Der Leithammel ist bei Licht besehen auch nur ein Schaf
so halbwegs weiß ich auch, wie man ein mech. und el-.mech. Stw bedient. (zumindest reicht es für den ersten Schritt des Vorgehens). Spannend dürften zig-tausend Sonderfälle sein, so meine Vermutung. Die Schnittstelle zu Zusi wird so allgmein sein, daß man wohl alles im Stellwerk umsetzen kann, was man umsetzen will, so man sich genug Mühe gibt.
Genau dadrum hätte ich ja die Sicherungstechnik im Stellwerk vorgeschlagen (natürlich für spätere Ausbaustufen), eben wegen den zig Sonderfällen.
Carsten du hast mir den Gedanken wieder gebracht.
Wenn sich so etwas ähnliches mit einer (in etwa) solchen Bedienoberfläche (man kann auch den Hintergrund schwarz darstellen, so wie es heute auf einer EBO aussieht) für Zusi realisieren läßt, dann ist das mehr als ausreichend und für alle Signalsysteme kompatibel, zumindest für das, was derzeit in Zusi möglich ist; die Möglichkeiten, die Zusi 3 dann mehr bietet, lassen sich leicht einbauen.
Das mein ich auch @ Rex... man kann ja trotzdem noch ne Möglichkeit für detailreichere Stws lassen, aber zuerstmal was universelles... Zusi war am Anfang schließlich auch nicht gleich soooo extremst krass genischal wie heut. *schleim*
Bye
Max Senft
Administrator, Programmierer, Ansprechpartner bei Problemen mit dem Board
Man sollte aber grundsätzlich immer im Hinterkopf behalten, dass man möglicherweise später etwaige Features zusätzlich einbauen möchte. Zusi hat derzeit den Nachteil, dass es mit der Zeit gewachsen ist. Ich benutze in solchen Fällen immer den Vergleich mit einem Baum:
Jemand pflanzt einen kleinen Baum. Die Leute finden ihn toll, also pflegt der Gärtner ihn, düngt und gießt ihn und er wächst schnell zu einem schönen Baum heran. Aber die Leute finden immer noch etwas an dem Baum, was sie noch gern hätten, und der Baum bekommt immer mehr Äste, und noch mehr Äste und Zweige. Doch irgendwann treibt der Baum keine eigenen Äste mehr aus. Aber die Leute wollen immernoch mehr. ALso beginnt der Gärtner, selbstgebastelte Äste, die nicht so gut aussehen wie richtige Äste, an den Baum zu nageln. Manchmal muss er dazu sogar einen Ast absägen, um ihn durch einen größeren zu ersetzen. Irgendwann aber ist der Baum voll mit echten und unechten Ästen, und man müsste zusätzliche lebenserhaltende Maßnahmen ergreifen, damit der Baum weitere künstliche Äste verkraften kann.
Hier ist der Punkt angelangt, wo es Zeit wird, einen neuen Baum zu pflanzen, der von vorn herein so beschaffen ist, dass er größer wächst und mehr Äste treiben kann als der alte Baum.
Ich bin der Ansicht, dass man sich bereits am Anfang eines Projekts Gedanken über möglichst viele mögliche Features machen sollte, und wie diese zu implementieren wären, sollten sie denn kommen. Denn wenn man sein Projekt grundsätzlich offener für Erweiterungen anlegt, kann man später leichter Äste dazuwachsen lassen. Carsten hat zum Beispiel bei Zusi 2 nie eingeplant (woraus ihm niemand einen Fehler ankreiden wird), dass irgendwann Leute auf die Idee kommen könnten, selbst in die innere Mechanik des Simulators einzugreifen, oder wenigstens eine Datenschnittstelle nach außen zu wollen. Die Folge ist, dass es natürlich keine PlugIns gibt, und die erst vor nicht allzu langer Zeit eingebaute TCP/IP-Schnittstelle ist ein bisschen aufgesetzt - eben ein künstlich angenagelter Ast. Zusi 2.4 würde ich gar als eine komplett aufgenagelte Baumkrone bezeichnen.
Und Zusi 3 wird dann der neue Baum sein, der schon bei seiner Veröffentlichung an bestimmten Stellen größere oder mehr Äste haben wird als der Vorgänger.
Wenn ich ein Projekt angehe, dann denke ich dabei normalerweise an den Recycling-Faktor. Ein vor nicht allzu langer Zeit diskutiertes Ergebnis davon ist der Parser, den ich zusammen mit Max gebaut habe, um Dateien relativ beliebigen Formats einzulesen. Er ist dermaßen dynamisch aufgebaut, dass man damit unglaublich viele verschiedene Dateiformate einlesen und schreiben könnte - aber ich bezweifle ernsthaft, dass er je für mehr als Lok-, Wag- und Führerstandsdateien zum Einsatz kommen wird. Eventuell auch noch bei Landschaftsdateien, allerdings ist er hier weniger nützlich als bei anderen Formaten. Ich bin zwar ein kleines Bisschen stolz auf das, was ich zusammen mit Max gebaut habe, aber bei größeren Projekten wie unserm Stellsi hier sollten wir zwar offen denken, aber immer im Hinterkopf behalten, dass zum Beispiel mittelfristig ESTWSim noch als die "perfekte" Simulation eines elektronsichen Stellwerks dazukommen soll. (Dazu sei allerdings gesagt, dass ESTWSim aus programmtechnischer Hinsicht eine einzige Katastrophe ist. Daniel hatte mal mit mir zusammen eine ziemlich dicke Liste von (konstruktiven) Verbesserungsvorschlägen im ESTWSim-Forum gepostet, auf die allerdings nur sehr zaghafte Resonanz und keine Programmänderung folgten. Der ESTW-Anteil an der Simulation ist allerdings, soweit ich das beurteilen kann, ein absoluter Oberhammer.)
Andi, was Du implizit ansprichst, nennt man ein "Framework". Und es wäre nicht überraschend, wenn in der Architekturphase nach den Anwenderanforderungen ein solches Framework konzipiert werden würde. Für eine derartige Aufgabenstellung bietet sich ein solcher Lösungsansatz fast automatisch an.
Aber auch ein Framework sollte man zu Beginn nicht überfrachten. Trotzdem erwarte ich von Anfang an mehrere Ebenen mit unterschiedlichem Abstraktionslevel, damit die notwendige Flexibilität überhaupt untergebracht werden kann. Aber auch damit greife ich schon wieder viel zu weit vor. Denn mir schwebt keinerlei konkrete Umsetzung vor Augen, sondern nur ein vager grundsätzlicher Aufbau, wie man ihn auch in anderen vergleichbaren Projekten findet.
Sollten wir uns nicht erst einmal Gedanken darum machen, was das Programm alles können soll, bevor wir uns Gedanken über die Architektur von Frameworks machen?
Da es hier um ein Zusi-Addon gehen soll, sollte sich die Stellwerkslogik eher an die Zusi-interne Logik anlehnen als an ein reales Stellwerk. Carsten muss eben sagen, wie das diesbezügliche Konzept für Zusi 3 aussieht -- was Zusi nicht kennt, muss auch nicht simuliert werden. Im Falle von Zusi 2 bestünde die Stellwerkslogik also lediglich aus Fahrstraßen, Signalen (und fahrstraßenabhängigen Signale, die man aber nicht direkt beeinflussen könnte), Registern und vielleicht noch Weichen als Verzweigungspunkte von Fahrstraßen.
Carsten Hölscher hat geschrieben:Spannend dürften zig-tausend Sonderfälle sein, so meine Vermutung.
Macht es überhaupt Sinn, all die Sonderfälle zu simulieren? Zusi simuliert ja auch nur wenige Sonderfälle des Tf-Alltags -- es gibt keine Motorschäden, keine Stromausfälle, gottseidank keine PU, ... Warum sollte man also in einer Stw-Sim Stromausfälle, Weichenstörungen o.ä. simulieren?
(Ar-) T-Rex hat geschrieben:Warum denn so kompliziert? Das ist doch alles gar nicht notwendig und bringt auch gar nichts!
Dem stimme ich voll zu.
AndiK hat geschrieben:Ich bin der Ansicht, dass man sich bereits am Anfang eines Projekts Gedanken über möglichst viele mögliche Features machen sollte, und wie diese zu implementieren wären, sollten sie denn kommen. Denn wenn man sein Projekt grundsätzlich offener für Erweiterungen anlegt, kann man später leichter Äste dazuwachsen lassen.
Das habe ich früher auch gedacht, stimme aber in diesem Punkt eher dem XP (Xtreme Programming)-Konzept zu: keine Features einbauen, die man nicht sofort braucht -- das kostet nur unnötige Entwicklungszeit. Denn erfahrungsgemäß werden die Features, an die man selbst gedacht hat, später nie benötigt, dafür werden von den Anwendern aber andere Features gefordert, auf die man selbst nie gekommen wäre.
AndiK hat geschrieben:Ich bin der Ansicht, dass man sich bereits am Anfang eines Projekts Gedanken über möglichst viele mögliche Features machen sollte, und wie diese zu implementieren wären, sollten sie denn kommen. Denn wenn man sein Projekt grundsätzlich offener für Erweiterungen anlegt, kann man später leichter Äste dazuwachsen lassen.
Das habe ich früher auch gedacht, stimme aber in diesem Punkt eher dem XP (Xtreme Programming)-Konzept zu: keine Features einbauen, die man nicht sofort braucht -- das kostet nur unnötige Entwicklungszeit. Denn erfahrungsgemäß werden die Features, an die man selbst gedacht hat, später nie benötigt, dafür werden von den Anwendern aber andere Features gefordert, auf die man selbst nie gekommen wäre.
Wie wäre es, eine möglichst strukturierte Liste von Anforderungen zusammenzutragen, dabei meinetwegen auch spezielle Spezialfälle zu berücksichtigen, und anschließend ein "Ranking" der Funktionalitäten durchzuführen, um die Sache überschaubar zu halten. Dabei sollten natürlich auch schon mal grobe Realisierungsentwürfe im Raume stehen.
Von "mal losprogrammieren" halte ich in diesem Fall nicht ganz so viel, auch wenn diees Vorgehen bei Zusi recht weit geführt hat...
Was XP angeht: Meiner Ansicht nach stellt XP verdammt hohe Ansprüche. Es setzt doch praktisch voraus, dass die Entwickler ein Framework bereits im Kopf haben, wenn sie loslegen, auch wenn sie nur wenige Features einbauen und die direkt auch Funktionalität bringen. Ausgearbeitet wird das dann z.B. über Refactoring. Solches aber kann nur gelingen, wenn das Konzept von Anfang an passt.
Michaels Ansatz ist der klassische. Auf so Meetings macht man das z.B. mit Karteikarten, auf die man Anforderungen schreibt. Systematik ist zu diesem Zeitpunkt noch nicht erforderlich.
Aber all das ist nun schon mehrfach von verschiedener Perspektive beleuchtet worden. Ich habe den Eindruck, im Moment drehen wir uns hier wunderbar im Kreis.
Also, wann findet wo welches Stellwerksanforderungsmeeting statt?
Roland Ziegler hat geschrieben:Ich habe den Eindruck, im Moment drehen wir uns hier wunderbar im Kreis.
Ich auch.
Da wäre es wohl vorteilhafter, es übernimmt bald einmal jemand den "Vorsitz" des Zusi-Stellwerks-Konsortiums (ich denke dabei ganz heftig an Dr. Roland); derjenige gibt die Direktiven vor, und so möge es dann sein.
Roland Ziegler hat geschrieben:Auf so Meetings macht man das z.B. mit Karteikarten, auf die man Anforderungen schreibt. Systematik ist zu diesem Zeitpunkt noch nicht erforderlich.
In der Phase bin ich meistens noch in der Mittagspause oder schreibe Forenbeiträge.
Roland Ziegler hat geschrieben:Ich habe den Eindruck, im Moment drehen wir uns hier wunderbar im Kreis.
Also, wann findet wo welches Stellwerksanforderungsmeeting statt?
Wäre doch was: Ein Simulator für Rotationsflügler. Mal was neues nach Ballon, Segler und Co.
intern: Vielleicht findet sich beim lock operating ja doch mal ein Bierdeckel, den man bekritzeln könnte...
Michael_Poschmann hat geschrieben:Vielleicht findet sich beim lock operating ja doch mal ein Bierdeckel, den man bekritzeln könnte...
Wenn Du das mit Deinem Haushaltsvorstand klärst?
Und vielleicht könntest Du zur Vorbereitung jenes Operating Dein eigenes Stellwerksanwenderwissen versuchen zu rekapitulieren?
Würde wohl in diesem Fall nicht mit noch in Mittagspause vereinbar sein - oder doch?
![:]](./images/smilies/pleased.gif "Freude"){kind=small}
*schleim*
