Re: StateMachine entwickeln mit C#, SoftSPS, B&R oder Beckhoff
Leo Meyer
> ich suche eine Software, in der ich eine StateMachine grafisch
> entwickeln kann.
Wozu w�rde man so etwas brauchen? Antwort: Um Nicht-Programmierern die M�glichkeit zum
"indirekten Programmieren" zu geben.
Und das macht man normalerweise - und vern�nftigerweise - nicht.
Warum? Nehmen wir mal an, Deine Software generiert Dir aus der State Machine den
Quellcode. Der Code wird dann sehr schwer zu lesen und zu debuggen sein, d.h. die
Wartung des Projekts wird f�r Nicht-Programmierer unm�glich, sobald die State Machine
eine gewisse Komplexit�t �bersteigt (und das soll und wird sie irgendwann).
Zudem werden die Anforderungen steigen und eine reine Generierung aus einer State Machine
wird nicht mehr ausreichen. Du wirst Modifikationen machen m�ssen, die nur ein
erfahrener Programmierer sinnvoll (wartbar) machen kann, d.h. Du solltest bei so einem Projekt
von vornherein auf einen solchen zur�ckgreifen.
Wie soetwas - spektakul�r gescheitert - im Endeffekt aussieht, l�sst sich an diesem
Beispiel absehen:
http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx
> Input Event
> -> Case Event AchseOnPos:
> Check State:
> Case InProgress1
> Move yAchse
> default:
> nichts
Na, das ist doch schon mal was.
> Wie entwickelt Ihr das? Tools? Oder nur auf dem Papier? Excel Sheet?
Zum Zeichnen der State Machine nehme ich gerne Visio, obwohl es da jedes gute CAD-
Programm auch tut. Das kann man dann sch�n pr�sentieren und mit Kunden diskutieren.
Wenn ich f�r mich komplexere State Machines entwerfe oder vereinfache, reichen Papier
und Bleistift.
Ausprogrammieren tu ich das dann von Hand. Nat�rlich w�re es mit Visio m�glich, die
Code-Generierung zu automatisieren, mit den oben beschriebenen Folgen.
Finger weg von so einer L�sung!
Falls Du es Dir dennoch antun willst, w�re "ASCET" ein geeigneter Suchbegriff. Wobei
das nicht so aussieht, als ob es ohne weiteres f�r Nicht-Programmierer verwendbar w�re.
F�r eine Machbarkeitsstudie im Studium mag es vielleicht gehen.
f'up: de.sci.informatik.misc
Gru�, Leo
--
Swearwords are dung for the day.
Volker Birk
> Sandra Bauer wrote:
>> ich suche eine Software, in der ich eine StateMachine grafisch
>> entwickeln kann.
> "indirekten Programmieren" zu geben.
> Und das macht man normalerweise - und vernünftigerweise - nicht.
> Warum? Nehmen wir mal an, Deine Software generiert Dir aus der State Machine den
> Quellcode. Der Code wird dann sehr schwer zu lesen und zu debuggen sein, d.h. die
> eine gewisse Komplexität übersteigt (und das soll und wird sie irgendwann).
Da sollte ich vielleicht einhaken:
Eine Statemachine könnte man in UML2 mit BOUML zeichnen, dann nach XMI
exportieren, und mit YSLT einen einfachen Compiler schreiben, der daraus
bestens lesbaren Quellcode macht, und zwar in der Programmiersprache der
Wahl:
Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!
Leo Meyer
> Eine Statemachine k�nnte man in UML2 mit BOUML zeichnen, dann nach XMI
> exportieren, und mit YSLT einen einfachen Compiler schreiben, der
> daraus bestens lesbaren Quellcode macht, und zwar in der
> Programmiersprache der Wahl:
>
> http://fdik.org/yml
Ja, und die Folge davon ist dann, dass Du Dich nicht nur mit den Bugs und Quirks
einer Sprache/Software herumschlagen musst, sondern mit denen von vier ;-)
Ich bin bei sowas eher skeptisch. Von der Wartbarkeit ist es mir am liebsten, wenn
der Code da anf�ngt, wo auch die Musik spielt. Mittlerweile mag ich auch schon
Konfigurationsfiles nicht mehr so gerne; was man da an Flexibilit�t gewinnt, wird
oft durch die entstehende Indirektion und Komplexit�t im Coding wieder zunichte gemacht.
Aber jeder nach seiner Fa�on ;-)
Volker Birk
>> exportieren, und mit YSLT einen einfachen Compiler schreiben, der
>> daraus bestens lesbaren Quellcode macht, und zwar in der
>> Programmiersprache der Wahl:
>> http://fdik.org/yml
> Ja, und die Folge davon ist dann, dass Du Dich nicht nur mit den Bugs und Quirks
> einer Sprache/Software herumschlagen musst, sondern mit denen von vier ;-)
> Ich bin bei sowas eher skeptisch. Von der Wartbarkeit ist es mir am liebsten, wenn
> Konfigurationsfiles nicht mehr so gerne; was man da an Flexibilität gewinnt, wird
> oft durch die entstehende Indirektion und Komplexität im Coding wieder zunichte gemacht.
> Aber jeder nach seiner Façon ;-)
Ich hab grade ziemlich gute Ergebnisse damit. Bei einem Kunden haben wir
95% Rationalisierungpotential in einem Teilprojekt damit rausgeholt.
Projekt gerne per PM skizziert, soweit es die NDA zulässt.
Sandra Bauer
>>Wozu würde man so etwas brauchen? Antwort: Um Nicht-
>>Programmierern die Möglichkeit zum
>>"indirekten Programmieren" zu geben.
ja und für sich selber, um den Überblick zu wahren.
> Eine Statemachine könnte man in UML2 mit BOUML zeichnen, dann nach XMI
> exportieren, und mit YSLT einen einfachen Compiler schreiben, der daraus
> bestens lesbaren Quellcode macht, und zwar in der Programmiersprache der
> Wahl:
>
> http://fdik.org/yml
>
könnte, ok, wie machen es die Experten?
Gibt es irgendwo Musterprojekte?
Danke.
Grüße Sandra
Volker Birk
>> Eine Statemachine könnte man in UML2 mit BOUML zeichnen, dann nach XMI
>> exportieren, und mit YSLT einen einfachen Compiler schreiben, der daraus
>> bestens lesbaren Quellcode macht, und zwar in der Programmiersprache der
>> Wahl:
>> http://fdik.org/yml
> könnte, ok, wie machen es die Experten?
> Gibt es irgendwo Musterprojekte?
Ich würds als DSL machen:
state "blub" {
init "bla" {
on "blub" transfer "blubber";
}
state "blubber" {
on "tschuess" transfer "theEnd";
}
state "theEnd" {
halt;
}
}
und dann da rausgenerieren. Finde ich mindestens so übersichtlich wie
Bildchen malen.
Leo Meyer
> Ich hab grade ziemlich gute Ergebnisse damit. Bei einem Kunden haben
> wir 95% Rationalisierungpotential in einem Teilprojekt damit
Keine Frage, das hat schon seine Berechtigung. Hab solche Sachen auch schon
gemacht, wenn auch nicht ganz so exzessiv.
Stichwort AndroMDA. Hab ich mal evaluiert, aber nie produktiv eingesetzt.
Ich fand es einfach zu kompliziert zu bedienen f�r das, was am Ende rauskommt.
Ein Kumpel von mir schw�rt hingegen auf sowas. Ich warte noch auf den Knall
beim Durchsto�en der "Framework-Schallmauer" ;-)
Kleine Privattheorie dazu: Die Framework-Schallmauer ist eine projektabh�ngige
Konstante, sowas �hnliches wie die Lichtgeschwindigkeit. Sie definiert die mit Hilfe
des Frameworks maximal erreichbare Funktionalit�t. Genauso wie das Beschleunigen
einer Masse bei zunehmender Geschwindigkeit immer mehr Energie ben�tigt, wird es
bei Ann�hern an die Funktionalit�tsgrenze immer aufw�ndiger, zus�tzliche Funktionalit�t
zu erreichen.
Ist die Framework-Schallmauer erreicht und wird dennoch versucht, zus�tzliche Funktionalit�t
einzubauen, muss soviel Energie aufgewendet werden, dass das Projekt im Regelfall
mit einem gro�en Knall zusammenbricht und eingestellt wird ;-)
Die Kunst beim Entwerfen eines Frameworks besteht darin, die Funktionalit�tsgrenze
m�glichst hoch anzusetzen, so dass die "Funktionalit�tskurve" m�glichst lange im
linearen Bereich verl�uft. Ich behaupte mal frech, die mit einem Framework maximal erreichbare
Funktionalit�t steht in umgekehrtem Verh�ltnis zur Anzahl der Grundfunktionen, die
es zur Verf�gung stellt, multipliziert mit der Kompetenz der sie anwendenden Personen
(wobei die Kompetenz als projektabh�ngige Gr��e zu betrachten ist).
Volker Birk
> Stichwort AndroMDA. Hab ich mal evaluiert, aber nie produktiv eingesetzt.
MDA hab ich vorher gemacht, und zwar mit OpenMDX. Das war der Auslöser,
selbst zu entwickeln. MDA ist wohl das Gegenteil von lean.
Ich verwende da kein Framework mehr, auch kein eigenes. Nur noch
(eigene) Tools, die selber lean sind.
Stefan Reuther
> Sandra Bauer <wo...@discardmail.com> wrote:
>>>Eine Statemachine könnte man in UML2 mit BOUML zeichnen, dann nach XMI
>>>exportieren, und mit YSLT einen einfachen Compiler schreiben, der daraus
>>>bestens lesbaren Quellcode macht, und zwar in der Programmiersprache der
>>>Wahl:
>>>http://fdik.org/yml
>>
>>könnte, ok, wie machen es die Experten?
>>Gibt es irgendwo Musterprojekte?
>
> Ich würds als DSL machen:
>
> state "blub" {
> init "bla" {
> on "blub" transfer "blubber";
> }
> state "blubber" {
> on "tschuess" transfer "theEnd";
> }
> state "theEnd" {
> halt;
> }
> }
>
> und dann da rausgenerieren. Finde ich mindestens so übersichtlich wie
> Bildchen malen.
Von da ist es aber nicht mehr weit dazu, das ganze in einer richtigen
Programmiersprache aufzuschreiben. Du willst ja nicht nur nackige
Zustandstransfers, sondern darin auch noch irgendwelche Dinge tun und
Entscheidungen fällen.
Wir haben hier eine zeitlang mit handcodierten Zustandsautomaten in C++
gearbeitet.
// 500 Funktionen dieser Form:
void automat::state_foo(event_t event) {
switch (event) {
case bar_event: switch_to(foo); break;
case baz_event: if (haha) switch_to(fred);
else switch_to(wilma); break;
}
}
// ein bisschen Steuercode dazu
void automat::dispatch(event_t event) {
switch (this->state) {
case foo: state_foo(event); break;
// ...
}
}
void automat::switch_to(state_t state) {
dispatch(leave_event);
this->state = state;
dispatch(enter_event);
}
void automat::run() {
while (1) {
dispatch(acquire_event());
}
}
Ging ganz gut, und wenn man sich an ein paar Regeln hält, kann man da
auch schöne Bildchen rausparsen (BTDT. Mit perl + dot hab ich damals
eine schöne Tapete generiert).
Jetzt haben wir einen mit Tool gemachten zugelieferten Zustands-
automaten, der sich im Wesentlichen dadurch auszeichnet, ohne Tool nicht
lesbar zu sein (wobei ich mir als Workaround aus dem generierten Code
was halbwegs brauchbares rausparse), und an allen möglichen Stellen
Hilfe von außen braucht, weil das Tool trotz zig Spezialzustandstypen
und so weiter einfach nicht ausdrucksstark genug ist, um alle nötige
Logik im Tool auszudrücken.
Beispiel: sieben "im Kreis" angeordnete Objekte, entsprechend sieben
Zuständen. Auf ein Ereignis "X" hin ist zum nächsten verfügbaren Zustand
zu wechseln. Einzige mir bekannte Möglichkeit das zu realisieren: sechs
bedingte Transitionen in jeden Zustand. Die erstellt man in dem Tool,
indem man auf "bedingte Transition" klickt, dann auf "Bedingung ist ein
Vergleich", dann ein Gleichheitszeichen aus der Toolbox holen, und dann
linke und rechte Seite davon per Combobox ausfüllen. Ist mir als
Kommandozeilenfuzzi ehrlich gesagt schleierhaft, wie man damit
_produktiv_ arbeiten kann. Folglicherweise schmeißt das Ding an der
Stelle ein Event in die Runde, was von handgeschriebenem Code empfangen
wird, der dem Zustandsautomaten dann mitteilt, welchen Zustand er nun
einnehmen möge.
Stefan
Volker Birk
> Programmiersprache aufzuschreiben.
Nach meiner Erfahrung sind das Grössenordnungen LOC, die man sich damit
spart, wenn man es generativ aufschreibt. Das kann man, mit
Einschränkungen, auch in C++ mit templates machen. Für Fälle, wo diese
nicht ausreichen, eben auch nicht.
Mit "Grössenordnungen" meine ich in aktuellen Projekten zwischen Faktor
5 und Faktor 100. In etwa dasselbe, was man mit Rails oder einem Klon
gegenüber herkömmlicher ausdrücklicher Webprogrammierung erreicht, nur
eben in anderen Bereichen.
Stefan Reuther
> Stefan Reuther <stefa...@arcor.de> wrote:
>>>Ich würds als DSL machen:
>>
>>Von da ist es aber nicht mehr weit dazu, das ganze in einer richtigen
>>Programmiersprache aufzuschreiben.
>
> Nach meiner Erfahrung sind das Grössenordnungen LOC, die man sich damit
> spart, wenn man es generativ aufschreibt. Das kann man, mit
> Einschränkungen, auch in C++ mit templates machen. Für Fälle, wo diese
> nicht ausreichen, eben auch nicht.
>
> Mit "Grössenordnungen" meine ich in aktuellen Projekten zwischen Faktor
> 5 und Faktor 100.
Das kann ich zumindest für die Zustandsautomaten, die wir damals hatten,
nicht bestätigen. Das, was ich da postete, war fast vollständig; der
"echte" Code hatte nur zusätzlich noch einen Mechanismus zur
Realisierung verschachtelter Zustände, der mit einer Handvoll Zeilen pro
Zustand auskommt (im Wesentlichen: Zustände müssen Auskunft über ihren
Elter geben können).
Natürlich kann man das nicht in so tollen UML-Diagrammen visualisieren,
aber zumindest die UML-Diagramme, aus denen unser aktueller Zustands-
automat besteht, sind ziemlich unübersichtlich und auf Monitoren mit
weniger als 4000x3000 Pixeln eigentlich nicht handhabbar. In Code kann
man wenigstens greppen.
Stefan
Volker Birk
> Natürlich kann man das nicht in so tollen UML-Diagrammen visualisieren,
> aber zumindest die UML-Diagramme, aus denen unser aktueller Zustands-
> automat besteht, sind ziemlich unübersichtlich und auf Monitoren mit
> weniger als 4000x3000 Pixeln eigentlich nicht handhabbar. In Code kann
> man wenigstens greppen.
Ich bin da auch nicht so der Grafikfan. Wobei, XMI zu generieren für
die, die's haben wollen - wenn's schee macht...
Übrigens: hast Du's mal mit DSLs und generieren versucht?
Stefan Reuther
> Stefan Reuther <stefa...@arcor.de> wrote:
>>Natürlich kann man das nicht in so tollen UML-Diagrammen visualisieren,
>>aber zumindest die UML-Diagramme, aus denen unser aktueller Zustands-
>>automat besteht, sind ziemlich unübersichtlich und auf Monitoren mit
>>weniger als 4000x3000 Pixeln eigentlich nicht handhabbar. In Code kann
>>man wenigstens greppen.
>
> Ich bin da auch nicht so der Grafikfan. Wobei, XMI zu generieren für
> die, die's haben wollen - wenn's schee macht...
dot reicht ja auch für eine Übersicht.
> Übrigens: hast Du's mal mit DSLs und generieren versucht?
Als Hobbycompilerbastler bau ich zwar ständig irgendwelche DSLs, aber
für Zustandsautomaten habe ich schlicht bisher kein Einsparpotenzial
gesehen. Der oben erwähnte Automat (den Mechanismus hat ein Kollege
gebaut) war mir schlank genug, und die Automaten, die ich selber pflege,
haben meist recht wüste Ereignisacquise-Schemata, die in ein Framework
zu pressen ziemlich aufwändig (und infolgedessen bloatig) wäre.
Meistens ist mir der andere Weg wichtiger, aus dem Code gewisse
Eigenschaften rauszuparsen und zu beweisen (z.B. Maximallaufzeit in
Funktion 'X' oder sowas).
Stefan