Sandra Bauer wrote:
> 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_...ly_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.

In de.sci.informatik.misc Leo Meyer <leomeyer*gmx.de> wrote:
> Sandra Bauer wrote:
>> 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).

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:

http://fdik.org/yml

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!

Volker Birk 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

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 ;-)

Gruß, Leo

--
Swearwords are dung for the day.

Leo Meyer <leomeyer*gmx.de> wrote:
> Volker Birk 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
> 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 ;-)

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.

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!

Hallo Volker!

>>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

Sandra Bauer <wolke*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.

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!

Volker Birk wrote:
> 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.

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).

Gruß, Leo

--
Swearwords are dung for the day.

Leo Meyer <leomeyer*gmx.de> wrote:
> 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.

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.

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!

Volker Birk wrote:
> Sandra Bauer <wolke*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

Stefan Reuther <stefan.news*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. In etwa dasselbe, was man mit Rails oder einem Klon
gegenüber herkömmlicher ausdrücklicher Webprogrammierung erreicht, nur
eben in anderen Bereichen.

Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!