Zusi und Stellwerke

[Andreas Karg]

Soweit ich das also verstanden hab sind Use Cases primär als Kommunikationsplattform zwischen "Kunde" und "Designer" gedacht, um damit der Kunde, der keinen Dunst von Softwareentwicklung hat, dem Designer, der keinen Dunst von dem, was der Kunde will, hat, klar machen kann, was er eigentlich will.
Das Problem, das Max, Daniel und ich auch haben ist wohl, dass wir gewissermaßen Kunde und Entwickler in Personalunion sind - wir wissen, was wir wollen und wie es zu funktionieren hat. Einzige Hürde ist also noch, den anderen Entwicklern verständlich zu machen, was uns im Kopf rumschwebt. Das habe ich mit obigem vermeintlichen UseCase versucht dazustellen. Und auch, wenns eigentlich kein UseCase ist sollte ausreichend das Prinzip deutlich sein, oder?

Übrigens, was passiert eigentlich mit dem tollen UML-Anteil am Projekt, wenn keiner einen vernünftigen Editor dafür findet? Ich für meinen Teil werd jedenfalls keine 180 Ocken für ein Programm hinlegen, das ich wahrscheinlich für genau ein Projekt verwenden werde.

[Michael_Poschmann]

Das Problem, das Max, Daniel und ich auch haben ist wohl, dass wir gewissermaßen Kunde und Entwickler in Personalunion sind - wir wissen, was wir wollen und wie es zu funktionieren hat.

Es könnten aber die (in meiner täglichen Praxis durchaus relevanten!) Fälle auftreten:

a) Wissensträger hat nicht sonderlich große Ahnung von Programmierung und Co
b) Programmierer ist zwar kongenial, kennt aber die Anforderungen der rauen Wirklichkeit leider nur völlig unzureichend
c) Wissensträger und Programmierer besitzen jeweils nur Teilwissen, da Materie zu komplex für einen einzelnen Satz Hirnwindungen.

Und hier führt "Schaumermal"-Programmierung mit 100% Sicherheit zu einem "Nochmal von vorn!" nach der ersten Beta. Den Frust sollte man sich ersparen.

Michael

[Roland Ziegler]

@Andi:

Ich kann mehr als nachvollziehen, dass der ganze mit UML verbundene Denkprozesess abschreckend wirkt. Wieviel einfacher erscheint es doch, mal eben ein paar Klassen zu implementieren, und fertig. Die Architektur habt Ihr im Kopf - sofern sie denn die ersten zwei Wochen übersteht.

Abstraktion ist verdammt schwierig, zumindest wenn man so etwas zum allerersten Mal macht. Ich weiß es selbst aus unzähligen Diskussionen, aber ich kenne keinen Entwickler, der nach dem mühsamen Einstieg hinterher nicht sagen würde, dass systematisches OOA&D nicht erhebliche Vorteile gebracht hätten. Trotzdem will ich niemandem hier in irgendeiner Weise ein solches ganz klar professionelles Vorgehen aufdrängen.

Vielleicht schauen sich die Skeptiker einfach mal Ihre eigene bisherigen Software-Projekte an. Wie groß waren die (Wieviele Klassen, oder Lines of Code)? Wieviele Entwickler beteiligt? Welche Projektlaufzeit? Waren das modulare, möglicherweise auch verteilte Systeme?

Es ist halt nicht nur meiner sondern auch Michaels Beruf, sich mit derartigen Thematiken mehr oder minder täglich auseinanderzusetzen, da fällt automatisch ein wenig Erfahrung ab. Und nach unserer Einschätzung handelt es sich hier um ein Projekt, das eine Größenordnung annehmen wird, die ein solches Vorgehen mehr als rechtfertigt.

[Andreas Karg]

Hmmm. Was machen wir eigentlich, wenn es kein funktionables und finanzierbares UML-Programm für uns gibt? Diagramme auf Papier zeichnen, einscannen und ins Netz stellen? Es auf die einfache Tour machen und uns alle mal virtuell hinsetzen und einen konstruktiven Chat abhalten? Vielleicht liegt es an den unterschiedlichen Generationen, dass ich IRC für ein Kommunikationsmedium halte, mit dem sich durchaus kreative Diskussionen führen lassen, bei denen auch was rauskommt. Immerhin hat man hinterher nen komplettes Log davon und kann immer nachgucken, wenn was unklar ist.

Ich bin ja prinzipiell UML nicht grundlegend abgeneigt - vielleicht hat es ja doch noch einen praktischen Wert, der mir mangels Erfahrung einfach bisher verwehrt geblieben ist. Aber sowas wie ein gescheites Tutorial (das, was auf der ArgoUML-Webseite vorhanden ist ist so vollständig wie der Rest des Programms...) wär durchaus nicht schlecht.

[Roland Ziegler]

http://www.uml.org/#Links-Tutorials

Es sollte mich wundern, wenn da nicht was zu finden wäre.

Meine Empfehlung: Langsam an die Sache rangehen.

[Max Senft]

Heyho!

So wie ich das jetzt verstanden hab ist das ganze UML-Gekrams eigentlich nur dazu da, um die Situationen, die dem heimeligen Zusi-FDL das Leben schwer machen könnten, mal auf den Bildschirm zu bringen!? Eine etwaige Realisierung steckt da dann auch dahinter?! Ist das dann also ein aufgemaltes Abstrakt aus dem die Programmierer dann erst wieder was vernünftiges machen müssen? Oder ist es an für sich nur simples abtippen der Graphik und umschreiben in die jeweilige Programmiersprache?

Um ehrlich zu sein, strahl ichs noch nicht so ganz und was ich auch etwas schade finde ist, dass (außer von Lutz und Carsten) sich noch keiner so richtig zu Andis Idee geäußert haben. Laut Carsten ist das wohl ziemlich Zusinah, heißt das aber nun, dass es auch für die Zukunft ist oder ist das alles Humbug und viel zu simpel/komplex?

Sollte es zu simpel sein: Wollten wir nicht ursprünglich eine leicht zu bedienende Oberfläche "für jeden" kreiren? Ach nein, es sollten ja dann doch die "Oberflächen" der einzelnen Typen dargestellt werden. Da aber - zumindest laut Lutz - die aktuellen Stellwerke eigentlich im Grunde immernoch ein halbautomatisiertes Mechstw. sind, sollte man doch da anpacken? Schließlich baut man immer von unten nach oben und nicht umgekehrt, oder? Und die vielen Störungsfälle bei nem defekten Relais/Kabelbruch oder sowas, die braucht man nun auch nicht!?

Aber wie gesagt, vielleicht urteile ich auch zu vorschnell, deswegen möchte ich erstmal sehen was ihr da zusammengeUMLt habt. Aber bitte: Spannt mich (uns) nich so auf die Folter! *g*

BTW: Es gibt doch ein kuhles OpenSource-Programm, das einem auch so Bäumchen simpelst und einfach herzaubert... aber wie heißt das nochmal!? *denk* Wenns mir mal nochmal einfallen sollte werd ichs euch mitteilen.

So long,
Max Senft

[Roland Ziegler]

UML ist wirklich primär zum Nachdenken und Veranschaulichen da. Viele Werkzeuge können aber durchaus Code-Fragmente generieren (statische Anteile) und in verschiedenen Sprachen auch reverse Engineering betreiben, aber das ist nicht primäres Ziel, wenngleich durchaus praktisch. Bei Together war z.B. in früheren Versionen die Zielsprache gleichzeitig das Repository.

Zu Andis Ideen: Ich denke, bevor wir uns mit irgendeiner Art von Umsetzung beschäftigen und dort Konzepte bewerten, sollten wir erst mal Analyse und Design soweit getrieben haben, dass ein belastbares Gerippe entstanden ist. (Ich weiß, dass ich mich endlos wiederhole. )

[Roland Ziegler]

Ein allererster Anfang: Stellwerk-Modell in html

Im Moment gerade mal zwei Diagramme:
Use Case View/Use Case Model: Use Case Fahrstrasse, der wohl bekannteste
Logical Model: Ganz grobe Paketstruktur (eher selbst redend, aber aufgeschrieben hält besser)

[Andreas Karg]

Von dieser ganzen Liste fiele mir jetzt kein Punkt auf, der nicht mit meinem System und ein paar Zeilen Script umgesetzt werden könnte.

[Carsten Hölscher]

nicht gegen das Script, aber es ist halt nicht besonders strukturiert. So ein Stellwerk läßt sich schon etwas besser organisieren. Ich denke, wir sollten einfach etwas warten, bis Roland soweit ist. Es ist ja keine Hektik bei dem Thema angesagt.

Carsten

[Oliver Lamm]

Das war jetzt irgendwie Nonsens mit dem Thumbnail, oder? Das Bild mit Endung _small ist mit 9,1 KB jedenfalls dateimäßig gut doppelt so groß, wie das eigentliche Bild, das mit seinen 610 Pixeln Breite auch locker in ein handelsübliches Forenfenster paßt...

Ist aber Scriptmässig so vorgegeben.

Gruss, Oli

[Oliver Lamm]

BTW: Es gibt doch ein kuhles OpenSource-Programm, das einem auch so Bäumchen simpelst und einfach herzaubert... aber wie heißt das nochmal!? *denk* Wenns mir mal nochmal einfallen sollte werd ichs euch mitteilen.

Mir fällt da noch "dia" ein. Zum malen sollte es reichen. Zu finden auf http://www.sf.net

Oli

[Daniel Rüscher aka Merlin]

Damit ihr nich so lang suchen müsst:

Die Windowsversion gibts hier

[Christopher Spies]

zu der autom. Generierung eines Stw aus den Streckendaten: [...] Bei Stellwerken mit Gleisplan wird es schon schwieriger, da der Editor aus den Koordinaten der Strecke ein etwas abstraktes Bild (wie man es aus dem Spurplan-Stw kennt) erzeugen müßte. Ich denke, das wird auf eine manuelle Geschichte hinauslaufen.

@Andi: ich bezog mich auf das hier von Christopher:

Ein Knopfdruck und der Computer generiert daraus das Script.

Warum sollte das nicht gehen? Prinzipiell sollte es auf jeden Fall möglich sein; ich könnte mir nur 2 Probleme vorstellen:

1. Bei der Anordnung der Elemente auf dem Stelltisch könnte ein Auto-Layouter "seltsame" Entscheidungen treffen -- wie jeder Auto-Layouter.
   Dieses Problem trifft z.B. auch bei UML-Editoren auf -- man beachte in Dr. Zieglers Diagramm die etwas eigenwillige Führung des Pfeils von "User 'Stellwerker B'" nach "Use Case 'Fahrstraße stellen'"!
2. Einige Elemente würden an anderer Stelle dargestellt, als man erwarten würde, da sie logisch an einer anderen Stelle liegen als virtuell.
   In Zusi könnte z.B. die logische Weiche (der Verzweigungspunkt der Vektorketten) an einer anderen Stelle liegen als die virtuelle Weiche (die Weichengraphik in der Streckendatei).

Zu Andis Ideen: Ich denke, bevor wir uns mit irgendeiner Art von Umsetzung beschäftigen und dort Konzepte bewerten, sollten wir erst mal Analyse und Design soweit getrieben haben, dass ein belastbares Gerippe entstanden ist.

Ich stimme zu! Zumindest insofern, dass eine Bewertung von Implementations-Alternativen erst erfolgen sollte, wenn zumindest die Analyse abgeschlossen ist.
Allerdings gibt Zusi gewisse Randbedingungen vor, deshalb sollte man auch mal etwas vorausdenken dürfen -- was nützt ein unimplementierbares Design?

Gibt es übrigens keine Möglichkeit, UML-Diagramme von einem Tool ins andere zu importieren?

Ein allererster Anfang: Stellwerk-Modell in html

"Stellwerker A" und "Stellwerker C" sollte man vielleicht in "Fdl Linksdorf" und "Fdl Rechtsdorf" umbenennen ...so wie in so ziemlich jedem Lehrbeispiel zur Stellwerkstechnik das ich bisher gesehen habe.

Nix für ungut,
- Christopher

Edit: Diagramm verlinkt

[Michael_Poschmann]

"Stellwerker A" und "Stellwerker C" sollte man vielleicht in "Fdl Linksdorf" und "Fdl Rechtsdorf" umbenennen

Dann hätte ich gerne Ehausen, Dstadt und ähnliche wieder im Programm.

Es ist schon ein Kreuz mit der Abstraktion
Michael

[Roland Ziegler]

"Stellwerker A" und "Stellwerker C" sollte man vielleicht in "Fdl Linksdorf" und "Fdl Rechtsdorf" umbenennen muharhar ...so wie in so ziemlich jedem Lehrbeispiel zur Stellwerkstechnik

Ja, das sind so die ganz entscheidenden Fragen.
Ich hatte gestern diesbezüglich ein Telefonat mit einem wohlbekannten Fdl, der dann aus seinem Lehrbuch ABC vorschlug:
A = Anfang, also Vorgänger
B = Besetzt, also wir hier
C = c(k)ommend, also Nachfolger

Hier bleibt nichts dem Zufall überlassen! (gewagte Aussage)

Gibt es übrigens keine Möglichkeit, UML-Diagramme von einem Tool ins andere zu importieren?

Der Standard dazu lautet XMI, ein XML-Format (wen wunderts), aber bislang geht das wohl nur beschränkt, weil der Standard noch in Entwicklung ist.

[Jens Haupert]

Mir fällt da noch "dia" ein. Zum malen sollte es reichen. (...)

Hallo,
kleiner Tip an alle die versuchen mit "dia" Sequenzdiagramme zu erstellen: Ich würde vorher eine Schachtel Valium einwerfen! (besser zwei!!)

Es gib nämlich kein anders freies Modellierungstool, das eine derart umfangreiche UML Unterstützung bietet und dabei so sch..., äh ich meine schlecht, ist!

Ich habe vor anderthalb Jahren damit jede menge Sequenz-, Klassen- und Statusdiagramme erstellt und war dem Wahnsinn noch sie so nahe gewesen.

Geklappt hat's dann letztendlich doch, aber ob der Preis es wert war?

Also wünsche dann viel Spaß!!!

MfG Jens

[Roland Ziegler]

Ich habe mal mit Visio - mit UML-Erweiterung - probiert, weil das bei meinem VisualStudio mit dabei ist. Das kann theretisch sogar Round Trip Engineering. Ich habe sehr schnell wieder aufgegeben. Visio bleibt auch mit UML-Erweiterung ein Zeichenprogramm. Vermutlich ist das mit "dia" so ähnlich.

Trotzdem, besser als garnix. Vielleicht kann "dia" ja XMI importieren?

[Roland Ziegler]

Abarbeitung der Zettelwirtschaft vom Boot vollbracht: Stellwerk-Modell in html, Update

Ich denke, ich habe jetzt alles, was auf dem Bridgewaterkanal zusammengetragen und niedergeschrieben wurde, in UML übertragen.

Dazu gehören auch unsere stichwortartig in den Raum geworfenenen Anwenderanforderungen, die schon mal grob gegliedert sind.

Der Use-Case mit der Fahrstraße ist um das Sequenzdiagramm erweitert worden. Ich hoffe das stimmt auch im Detail einigermaßen so. Unter Register sind die Zusi-Register zu verstehen, bzw deren Inkarnation auf Stellwerksseite.

Für einige unsere Anforderungstichworte ist eine Zuordnung zu dem 1. Use Case gemacht worden - denn Anforderungen, die im leeren Raum stehen, gelten bekanntlich als nicht erfüllt.

Erste Klassen, die sich praktisch automatisch ergeben, sind auch schon mal aufgeschrieben.

Wie soll's weitergehen? Input wird gewünscht:

1. Die Anwenderanforderungsliste ist sicher noch nicht annähernd komplett, und je nach Bereich im Moment auch nicht sehr detailliert.
2. Weitere, neue Anwendungsfälle / Use Cases, mit detalliertem Ablauf, siehe Beispiel
3. Für etliche der bereits erfassten Stichwort-Anforderungen scheinen ebenfalls Use Cases möglich.

Oliver wird demnächst ein CVS-Repository einrichten, dort werde ich die XMI-Files ablegen, so dass dann auch mehrere Leute direkt zugreifen können. Details und genaues Vorgehen müssen natürlich noch abgesprochen werden.

Und ganz wichtig: NICHT ABSCHRECKEN LASSEN!

[Carsten Hölscher]

das heißt, es sind jetzt die Stw-Experten gefordert, alle möglichen Anwendungsfälle zu beschreiben?

Carsten