Stellwerk

Hier geht es um die Entwicklung eines zukünftigen Stellwerks mit Zusi-Anschluss.
Nachricht
Autor
Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#21 Beitrag von Christopher Spies »

Hallo!
Frank Wenzel hat geschrieben:dann bedeutet das, dass der Stellwerk-Client Signalstörungen "generieren" können muss, so wie Zusi das bisher auch schon macht.
Das ist sicher keine Funktion, die unbedingt schon in Version 1.0 eingebaut sein müsste.
Frank Wenzel hat geschrieben:Um böswillige Eingriffe zu verhindern, sollte eine Ersatzsignalschaltung nur zugelassen werden, wenn auch eine Störung vorliegt. Über ähnliches sollte auch im Zusammenhang mit Rangierfahrstraßen nachgedacht werden.
Das wäre aber nicht vorbildgerecht!
Rangiert wird ja ohnehin auf Sicht, eine bösartigerweise falsch eingestellte Rangierstraße sollte also nicht betriebsgefährdend sein.
Jannis hat geschrieben:Das kommt ja so etwa auf das was ich hier mal zusammengeschrieben habe raus. Es wird ja wohl nicht wirklich schwer sein, herauszufinden, wer dieser chaos FDL ist [...] man müsste sich nurnoch ein "Bestrafungssystem" ausdenken
Soziale Probleme mit technischen Maßnahmen zu bekämpfen hat meist wenig Erfolg. "Bestrafungssystem" ist das Stichwort, das hat aber mit dem Stellwerk nichts zu tun.

Gruß,
- Christopher
Zuletzt geändert von Christopher Spies am 23.07.2008 16:54:04, insgesamt 1-mal geändert.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#22 Beitrag von Roland Ziegler »

Wenn ich das richtig in Erinnerung habe, ist ein Ersatzsignal von der Fachlogik her lediglich ein Signalbild und damit ein bloßes Attribut, wird also bei Kommunikationsstraegien keiner besonderen Behandlung bedürfen. 8o :]

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Stellwerk

#23 Beitrag von Michael_Poschmann »

Es winkt der Nachfolgebastelauftrag Fahrdienstvorschriften-Simulator. :hat2

Mit regelwerkskonformen Grüßen innerhalb der Stadtgrenzen
Michael

Benutzeravatar
Daniel Rüscher aka Merlin
Beiträge: 2294
Registriert: 23.01.2003 02:25:50
Aktuelle Projekte: Aktuell keine
Wohnort: Traunreut
Kontaktdaten:

Re: Stellwerk

#24 Beitrag von Daniel Rüscher aka Merlin »

Roland Ziegler hat geschrieben:Wenn ich das richtig in Erinnerung habe, ist ein Ersatzsignal von der Fachlogik her lediglich ein Signalbild und damit ein bloßes Attribut, wird also bei Kommunikationsstraegien keiner besonderen Behandlung bedürfen. 8o :]
Einspruch (zumindest ein bißchen): Zs1 läuft auch im realen Stellwerk über seperate Kanäle und unter besonderen Vorzeichen. Man kann also überlegen ob man da nich auch was besonderes macht.
How to waste bits in a My SQL Database?

Like this.....

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#25 Beitrag von Roland Ziegler »

Die COM-Ausprägung der Schnittstelle nebst Delphi-Testanwendung ist nun ebenfalls auf dem aktuellen Stand. Auch wenn die Kopplung stur nach Schema-F geht, man kann da doch eine Menge Fehler machen, was den Betrieb nachhaltig aufhält. Aber jetzt tut es das.

Das Stellwerk soll sich ja bei Zusi direkt und unmittelbar melden können, wenn es etwas will. Mit Hilfe des kleinen Code-Generators EventSinkImp, der COM-Event-Senken so ausbildet, dass man sie ohne COM-Spezialkenntnisse in Delphi nutzen kann, ist verzögerungsfreie Benachrichtigung entsprechend möglich (Push-Mechanismus).

Die von EventSinkImp gewählte Standard-Implementierung der Senke ist zudem tatsächlich so realisiert, dass die Events in die Windows-Message-Loop eingeschleift werden, synchron für den Absender. Der spielt beispielsweise in Thread 17, setzt einen Event auf COM ab, und erwartet während der Event-Behandlung Antworten. Der Event-Handler auf Delphi-Seite verhält sich gemäß des in einem der vorigen Beiträge erwähnten Musters so, dass er das Ereignis an die Windows-Nachrichtenschleife gibt, aber dann wartet, bis das Ereignis abgearbeitet wurde. Die Nachrichtenschleife laufe beispielsweise in Thread 3. Dort kommt dann das Ereignis dann auch an, genau wie ein Maus- oder Tastaturereignis. Aufgrund von COM- und Event-Besonderheiten kann der Empfänger dem Ereignis keine wirklichen Daten als Rückgabe mitliefern. Stattdessen ruft er während der Ereignisbehandlung im COM-Server synchrone Methoden für diese Lieferungen auf (Callback des Event-Hnadlers, eigentlich ein doppelter Callback). Dies geschieht natürlicherweise in Thread 3, während Thread 17 immer noch wartet. Erst danach, mit Abschluss der Ereignisbehandlung, wird Thread 17 wieder freigegeben, und kann die von Thread 3 gelieferten Daten weiterverarbeiten.

Für den Server in Thread 17 ist es hierbei praktisch egal, ob der Callback im selben oder in einem anderen Thread erfolgt, da die Ereignismethode erst dann zurückkommt, wenn sie vom Handler komplett abgearbeitet wurde.

Dass der Mechanismus über COM und das synchrone Ereignismuster über Delphi läuft, spielt hierbei nur eine untergeordnete Rolle. Der gleiche Mechanismus liefe auch in einer .Net-Anwendung dieser Schnittstelle ab. (Allerdings könnte man in einer nativen Umgebung die Schnittstelle einfacher ausbilden.)

Abschreckend an der ganzen Sache ist eigentlich nur der COM-Overhead, der bei einem Outgoing-Interface vonnöten ist. COM ist geprägt durch viele Varianten, und manche Unübersichtlichkeit. Bis zum Schluss konnte es den Ballast, der durch Visual Basic geprägt wurde, nicht überwinden. (Ich hatte es schon mal geschrieben, die COM-Schnittstelle des Stellwerks ist nicht vereinbar mit Visual Basic 6, denn die Stellwerksereignisse werden in COM als IUnknown ausgebildet und erfordern eine Type Library zur Interpretation.) Für uns reduziert sich der Overhead glücklicherweise auf ein Vorgehen nach besagtem Schema-F. Die Einbindung des Event-Handlers ist in der Praxis kaum aufwändiger als die eines Windows-Timers, allerdings nur unter der Voraussetzung, dass man sich sonst nirgendwo in der Kette vertan hat. Wenn doch, gehen schnell ein paar Stunden ins Land. :evil:


Nachtrag:
Der Mechanismus "Active Object" kann hier nachgelesen werden: http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf" target="_blank
Dies ist ein älterer Artikel, noch aus Vor-UML-Zeiten, aber beschreibt trotzdem das selbe Konzept, dass hier auch in Delphi oder .Net (ISynchronizeInvoke) verwendet wird und aus Java und der konventionellen Win32-Windows-Event-Verarbeitung ebenfalls bekannt ist. Die ursprüngliche Win32-Implementierung ist nur deutlich weniger elegant als die in .Net, liegt halt viel Zeit dazwischen.
Zuletzt geändert von Roland Ziegler am 28.07.2008 15:02:23, insgesamt 1-mal geändert.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#26 Beitrag von Christopher Spies »

Hallo allerseits,
Christopher Spies hat geschrieben:Was ist z.B. mit Stellwerken, die keine Fahrstraßen kennen?
das ist übrigens nicht so weit hergeholt, wie manche vielleicht glauben.
Der Bahnhof Brensbach (Odenw.) an der 1964 stillgelegten Strecke des "Odenwälder Lieschens" beispielsweise verfügte über einflüglige Einfahrsignale (aber keine Ausfahrsignale). Im Bahnhofsbereich befand sich ein beschrankter Bahnübergang.
Vor dem Empfangsgebäude stand ein Windenbock, von dem aus die Signale und die Schranken ohne Abhängigkeit voneinander oder von den Weichen bedient werden konnten.

Stellwerke ohne Fahrstraßen sind also nicht ausschließlich eine Erscheinung des vorletzten Jahrhunderts.

Gruß,
- Christopher

Benutzeravatar
Jens Strumberg
Beiträge: 2184
Registriert: 09.04.2003 16:13:19
Wohnort: Bochum

Re: Stellwerk

#27 Beitrag von Jens Strumberg »

Ebenso die Bahnhöfe Büttel, Garding, Tating und St. Peter Süd an den Strecken Husum - Tönning Hafen und Tönning - St. Peter-Ording. Einflüglige Einfahrsignale, an Stelle von Ausfahrsignalen dann Haltetafeln. In den 60ern kam dann der Rückbau auf Trapetztafeln, die Stellwerke wurden aufgegeben, Zugleitbetrieb wurde eingeführt.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#28 Beitrag von Roland Ziegler »

Wuppertal - Radevormwald war auf auf mehreren Bahnhöfen dieselbe Kategorie wie jenes Brensbach. Endete 1971 in Dahlerau tödlich.

Zum Thema selbst sitze ich gerade an der Überarbeitung der "Fassade" auf der Client-Seite. Das ist die Schnittstelle, die ein Stellwerk von der ganzen Kommunikationsgeschichte überhaupt sieht. Diese Schnittstelle ist aufgrund der Überarbeitung des Rückkanals im letzten Jahr jetzt single-threaded.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#29 Beitrag von Christopher Spies »

Hallo Roland,
Roland Ziegler hat geschrieben:Wuppertal - Radevormwald war auf auf mehreren Bahnhöfen dieselbe Kategorie wie jenes Brensbach. Endete 1971 in Dahlerau tödlich.
das lag aber damals an der Nicht-Existenz von Ausfahrsignalen und nicht an der fehlenden Fahrstraßenabhängigkeit!
Ein Stellwerk für einen Bahnhof ohne Ausfahrsignale könnte ja trotzdem Fahrstraßen und Streckenblock haben und die Fahrtstellung der Einfahrsignale von der Stellung der Weichen abhängig machen. Nicht, dass das in Dahlerau etwas genützt hätte...

Das geringere Sicherheitsniveau fahrstraßenloser Stellwerke ist natürlich offensichtlich. Unabhängig davon wollte ich darauf hinweisen, dass es so etwas auch hierzulande mal gab, und dass das weniger lange her ist, als mancher vielleicht glaubt.

Edit: Weiteren Gedanken nachgetragen.

Gruß,
- Christopher
Zuletzt geändert von Christopher Spies am 07.08.2008 13:51:29, insgesamt 1-mal geändert.

Benutzeravatar
Jens Strumberg
Beiträge: 2184
Registriert: 09.04.2003 16:13:19
Wohnort: Bochum

Re: Stellwerk

#30 Beitrag von Jens Strumberg »

Christopher Spies hat geschrieben:Das geringere Sicherheitsniveau fahrstraßenloser Stellwerke ist natürlich offensichtlich. Unabhängig davon wollte ich darauf hinweisen, dass es so etwas auch hierzulande mal gab, und dass das weniger lange her ist, als mancher vielleicht glaubt.
Naja, jetzt ist aber zu bedenken, wie dicht der Verkehr auf besagten Strecken gewesen ist. Garding z.B. hatte maximal zwei sich begegnende Zugfahrten und höchstens irgendwo eine Rangierfahrt.

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#31 Beitrag von Roland Ziegler »

Nachdem die Kommunikation nun aufgeräumt ist, versuche ich mich an systematischer Testumgebung. Die Unit-Technik (hier: NUnit) ist dabei nur ein Aspekt. Gegenüber Michael hatte ich es schon mal angesprochen: Mir schwebt eine einfache Skriptsprache vor, die es ermöglichen soll, in den Stellwerksklassen Funktionen auszulösen, so wie es die spätere Benutzeroberfläche auch machen wird. Das Gegenstück soll ebenfalls existieren, zugbedingte Ereignisse und Nachbarstellwerke sollen mitwirken. Solche Anforderungen ergeben sich fast von selbst, wenn man versucht Unit-Tests aufzustellen.

Meine kleine Skriptsprache soll ziemlich massiv auf Reflection (Generik!) setzen. Kern ist die Formulierung von Statements, die sich zur Laufzeit dank .Net praktisch unmittelbar in Methodenaufrufe instantiierter Objekte umsetzen lassen. Aber irgendwie braucht man ein wenig drumrum, z.B. eine simple Flusssteuerung und vielleicht einige Konstanten oder Variablen. Das führt dann dazu, dass man sich doch mal ein paar Gedanken zu einer formalen Grammatik macht. Nun will ich nicht Lex & Yacc Konkurrenz machen, und meine Sprache wird voraussichtlich nicht einmal arithmetische Ausdrücke beherrschen, aber ganz ohne Systematik geht es nicht. Und das bisschen, was ich brauche, soll dann einigermaßen ordentlich sein. Also bin ich derzeit dabei, meine Grammatik in BNF zu formulieren:

Code: Alles auswählen

<invoke statement> ::= <word> . <word> <param list> ;
<param list> ::= () | ( <arg> ) | ( arg {, <arg>} )
<arg> ::= <literal> | <word> | <enum>
<literal> ::= <number> | <float> | <boolean> | <string>
Daraus kann man dann einen Syntaxbaum konstruieren, und mit Hilfe von diesem dann die eigentliche lexikalische Analyse des Scriptquellcodes laufen lassen. Aus dem Ergebnis lassen sich Befehle ableiten (als Instanzen von Objekten), die der Interpreter aufrufen kann.

So ein Skriptbefehl sieht dann vielleicht so aus:

Code: Alles auswählen

Block.vorblocken ("D-Stadt");
Zuletzt geändert von Roland Ziegler am 15.08.2008 09:24:27, insgesamt 1-mal geändert.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#32 Beitrag von Christopher Spies »

Hallo Roland,
Dr. Roland Ziegler hat geschrieben:Meine kleine Skriptsprache [...] braucht [...] ein wenig drumrum, z.B. eine simple Flusssteuerung und vielleicht einige Konstanten oder Variablen. Das führt dann dazu, dass man sich doch mal ein paar Gedanken zu einer formalen Grammatik macht. [...] [M]eine Sprache wird voraussichtlich nicht einmal arithmetische Ausdrücke beherrschen
wird "Deine kleine Skriptsprache" denn Turing-vollständig sein?
Warum verwendest Du nicht eine existierende Skriptsprache, oder ein passendes Tool Deines Arbeitgebers?
Dr. Roland Ziegler hat geschrieben:Nachdem die Kommunikation nun aufgeräumt ist, versuche ich mich an systematischer Testumgebung. Die Unit-Technik (hier: NUnit) ist dabei nur ein Aspekt. [...] Mir schwebt eine einfache Skriptsprache vor, die es ermöglichen soll [...] Funktionen auszulösen, so wie es die spätere Benutzeroberfläche auch machen wird. [...] Solche Anforderungen ergeben sich fast von selbst, wenn man versucht Unit-Tests aufzustellen.
Also davon habe ich noch nie etwas gehört.
Nun bin ich natürlich im Gegensatz zu Dir nicht hauptberuflicher Softwareentwickler und habe schon gar nicht auf diesem Gebiet promoviert.
In den beiden von mir besuchten Softwaresysteme-Vorlesungen jedenfalls wurden zwar Unit-Tests (mit JUnit) behandelt, aber vom Einsatz von Skriptsprachen war da keine Rede, schon gar nicht von "hausgemachten" Interpretern.

Mein Standpunkt ist eigentlich eher, dass man es soweit nur irgend möglich vermeiden soll, irgendwelche Utilities selbst zu basteln, und stattdessen fertige Lösungen verwenden soll -- daher auch meine Frage nach existierenden Skriptsprachen.
Vor allem ist mir nicht klar, wozu man überhaupt eine Skriptsprache braucht...
Man muss dann die Testfälle in der Skriptsprache schreiben -- soll das schneller sein, als sie z.B. in Delphi zu programmieren? Die Entwicklungszeit für den Interpreter muss ja auch einkalkuliert werden.
Dr. Roland Ziegler hat geschrieben:Solche Anforderungen ergeben sich fast von selbst
Das bezweifle ich ehrlich gesagt, lasse mich aber gern eines Besseren belehren.
Wenn man das wirklich häufig braucht, warum sind solche Skriptsprachen dann nicht Teil des jeweiligen Test-Frameworks?

Nix für ungut,
- Christopher

Benutzeravatar
Roland Ziegler
Beiträge: 5508
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Stellwerk

#33 Beitrag von Roland Ziegler »

Christopher Spies hat geschrieben: wird "Deine kleine Skriptsprache" denn Turing-vollständig sein?
Ist kein Design-Kriterium. Könnte höchstens als Nebeneigenschaft herauskommen, was ich bezweifle.
Warum verwendest Du nicht eine existierende Skriptsprache, oder ein passendes Tool Deines Arbeitgebers?
Viel zu komplex, viel zu viel Overhead, viel zu viel Arbeit, um an meine Bedürfnisse anzupassen.
In den beiden von mir besuchten Softwaresysteme-Vorlesungen jedenfalls wurden zwar Unit-Tests (mit JUnit) behandelt, aber vom Einsatz von Skriptsprachen war da keine Rede, schon gar nicht von "hausgemachten" Interpretern.
Unit-Testen ist ja eigentlich eine Philosophie, keine Testumgebung. Die Testfälle muss man schon noch selber entwickeln. Und die Umgebung, in denen sie ablaufen können, auch. Elementare Tests kann ich mit dem Unit-Mechanismus ganz einfach erstellen (C# ist auch die Sprache der Tests), mit wenigen Zeilen pro Testfall. Aber natürlich gibt es auch komplexere Tests, Abläufe im Zusammenhang testen. Was ist denn die typische Funktionsweise eines Stellwerks? Doch eine geordnete Sequenz von Handlungen. Im Original schwingt man Hebel und betätigt Tasten, auf einer Bedienoberfläche simuliert man dies digital. Aber letztlich ist es ein "Programm". Und es gibt mehrere Programme, für den nächsten Zug ein anderes. Natürlich könnte ich für jedes der zu testenden "Programme" einen Testfall schreiben. Und dann jedesmal den Source-Code meiner Testfälle ändern, wenn ich es etwas anders haben will. Ist aufwändig. Vor allem, weil sich dies durch die gesamte Projektlaufzeit ziehen wird. So ein paar Zielen externer Script-Text erscheinen da deutlich beherrschbarer.
Mein Standpunkt ist eigentlich eher, dass man es soweit nur irgend möglich vermeiden soll, irgendwelche Utilities selbst zu basteln, und stattdessen fertige Lösungen verwenden soll -- daher auch meine Frage nach existierenden Skriptsprachen.
.Net (oder Java) bietet etwas ganz besonderes: Reflection - die Möglichkeit der Analyse des existierendes Codes, und die dynamische Nutzung dieses Codes, zur Laufzeit. Für mein Beispiel oben vielleicht so: "Suche eine Klassendefinition namens Block. Finde dazu eine Methode namens vorblocken, die einen Parameter und diesen vom Typ string erwartet. Instantiiere ein Objekt der Klasse und rufe besagte Methode auf." Wenige Zeilen C#-Code. Man muss aber irgendwie die ganzen Text-Konstanten übergeben. Dazu will ich meine Skriptsprache haben, die auch der Benutzer lesen kann.
Vor allem ist mir nicht klar, wozu man überhaupt eine Skriptsprache braucht...
Vielleicht wurde es klarer. Grammatik ist auch nur deswegen nötig, um eine saubere lexikalische Analyse zu ermöglichen, die ich mit OO effizient umsetzen kann.
Man muss dann die Testfälle in der Skriptsprache schreiben -- soll das schneller sein, als sie z.B. in Delphi zu programmieren?
Die Testfälle bleiben in C#. Sie binden die Skripte mit ein.
Die Entwicklungszeit für den Interpreter muss ja auch einkalkuliert werden.
In der Tat. Und deswegen habe auch eine Weile überlegt und dann erst mal Kernfunktion ausprobiert. Der Aufwand scheint beherrschbar, der OO sei Dank.
Wenn man das wirklich häufig braucht, warum sind solche Skriptsprachen dann nicht Teil des jeweiligen Test-Frameworks?
Gibt es. Diverse. Passen aber nicht zu meinem Problem. Anpassung zu aufwändig. Und ein wenig Spaß soll ja auch noch dabei sein.
Nix für ungut
Fragen nach Motivation und Aufwand sind aus meiner Sicht absolut berechtigt.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Stellwerk

#34 Beitrag von Michael_Poschmann »

Zu bedenken ist, daß Roland den Aufwand treibt, um auch bahntechnisch Halbwissenden, die sich nicht in den Niederungen von Entwicklungsumgebungen auskennen, die Chance zu geben, an den praxisnahen Teststellungen mitzuwirken. Und (ohne Blick in lästige Dokumentation und Handbücher :ausheck) handhabbare Nutzkonzepte zeichnen ja bekanntermaßen die Tools aus dem Hause Ziegler aus...

Gruß
Michael

Benutzeravatar
Michael Springer
Beiträge: 2925
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: Stellwerk

#35 Beitrag von Michael Springer »

handhabbare Nutzkonzepte zeichnen ja bekanntermaßen die Tools aus dem Hause Ziegler aus
Das finde ich auch, dass muss man hier nochmals extra loben :respekt

Ich hätte mir schon lange mal ein ESTW-Sim von T. Bauer angeschafft, aber diese Closed ... Dingsda ... ohne Editor und sonstwas, sind es mir nicht wert. Und für jedes Stellwerk wieder 40-50 EUR abdrücken, hmmm das Konzept stößt mir auf und deshalb unterstütze ich es nicht. Obwohl ich manchmal gerne mal ein paar Minütchen damit simulieren/spielen würde.

Ich finde Roland eine TOP-Bereicherung für unsere Community. Solche Leute gibt es nicht oft in der heutigen Zeit, wo immer nur nach einer Gegenleistung gefragtwird ... und seine Engelsgeduld, Anderen zum 23. Mal zu erklären wie ein Rendervorgang des neuen Zusi3 funktionieren wird ...

Das Stellwerk wird einfach nur geil werden und für alle leicht bedienbar ...

Michael

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Stellwerk

#36 Beitrag von Andreas Karg »

Michael Springer hat geschrieben:wo immer nur nach einer Gegenleistung gefragtwird
Ich kann mich nicht erinnern, dass Roland mal irgendwo erwähnt hätte, dass sein Erzeugnis für lau sein wird. :mua

Benutzeravatar
Michael Springer
Beiträge: 2925
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: Stellwerk

#37 Beitrag von Michael Springer »

Ich habe auch nicht behauptet, dass das Erzeugnis für lau zu haben sein wird ... nur das er sich sehr für die Community einsetzt und mit Rat und Tat zur Seite steht ...

Andreas Karg
Beiträge: 4718
Registriert: 28.04.2002 12:56:00
Kontaktdaten:

Re: Stellwerk

#38 Beitrag von Andreas Karg »

Das war auch eigentlich mehr ein Witz... Oder wenigstens der Versuch eines solchen.

Christopher Spies
Beiträge: 775
Registriert: 26.01.2005 16:10:18
Wohnort: Darmstadt

Re: Stellwerk

#39 Beitrag von Christopher Spies »

Hallo!
Roland Ziegler hat geschrieben:Natürlich könnte ich für jedes der zu testenden "Programme" einen Testfall schreiben. Und dann jedesmal den Source-Code meiner Testfälle ändern, wenn ich es etwas anders haben will. Ist aufwändig. Vor allem, weil sich dies durch die gesamte Projektlaufzeit ziehen wird.
Aber so musst Du den Source-Code der Testskripte ändern, wie spart das Arbeit?
Roland Ziegler hat geschrieben:.Net (oder Java) bietet etwas ganz besonderes: Reflection - die Möglichkeit der Analyse des existierendes Codes, und die dynamische Nutzung dieses Codes, zur Laufzeit. Für mein Beispiel oben vielleicht so: "Suche eine Klassendefinition namens Block. Finde dazu eine Methode namens vorblocken, die einen Parameter und diesen vom Typ string erwartet. Instantiiere ein Objekt der Klasse und rufe besagte Methode auf."
Reflection ist mir bekannt. Mir ist jedoch nicht klar, was im Rahmen des Stellwerk-Projekts der Vorteil davon ist. Die API steht doch fest, oder irre ich mich da?
Roland Ziegler hat geschrieben:Man muss aber irgendwie die ganzen Text-Konstanten übergeben. Dazu will ich meine Skriptsprache haben, die auch der Benutzer lesen kann. [...] Die Testfälle bleiben in C#. Sie binden die Skripte mit ein. [...] ein wenig Spaß soll ja auch noch dabei sein.
Michael_Poschmann hat geschrieben:Zu bedenken ist, daß Roland den Aufwand treibt, um auch bahntechnisch Halbwissenden, die sich nicht in den Niederungen von Entwicklungsumgebungen auskennen, die Chance zu geben, an den praxisnahen Teststellungen mitzuwirken.
Ich rekapituliere:
  • Die Skripte sind also nur Konfigurationsdateien für allgemein gehaltene Testfälle. Früher hätte man so etwas vielleicht als Textdatei im INI-Format realisiert.
  • Roland bastelt sich seine eigene Skriptsprache und zugehörigen Interpreter aus Spaß.
  • Die Skriptsprache muss so simpel sein, dass Nichtprogrammierer als Testsklaven herhalten können.
Habe ich das richtig verstanden?

Gruß,
- Christopher

P.S.: Wen meint Dr. Poschmann mit "bahntechnisch Halbwissenden, die sich nicht in den Niederungen von Entwicklungsumgebungen auskennen"? Sich selbst ja wohl kaum...
Zuletzt geändert von Christopher Spies am 15.08.2008 19:01:27, insgesamt 1-mal geändert.

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Stellwerk

#40 Beitrag von Michael_Poschmann »

Hallo Christopher,

da ich nahezu meine komplette stellwerksbezogene Fachliteratur innerhalb der Stadtgrenzen verliehen habe, reicht es nicht mal mehr für Viertelwissen. :)

Michael

Antworten