Flow Runtime statt EBC

[Ralf Westphal]

Dem einen oder anderen hatte ich es schon persönlich gesagt: aus
meiner Sicht ist die Zeit von EBCs nun vorüber. EBC sind tot - lang
lebe FD und Managed Flow Execution :-)

Die Zukunft der Implementierung von Flow Design Modellen sehe ich in
einer Runtime, die Flows ausführt. Auch wenn das ein bisschen an der
Performance kratzt, überwiegen für mich ganz klar die Vorteile.

Mit einer Runtime müssen Flows nicht mehr in umständlicher Event-
Verdrahtung codiert werden.

Mit einer Runtime ist die Parallelisierung von Operationen viel
einfacher möglich, nämlich deklarativ.

Mit einer Runtime kann Einfluss auf die Ausführung zur Laufzeit
genommen werden.

Eine Flow Runtime (oder Flow Execution Engine) bietet für Flows
ähnliche Vorteile, wie die CLR für 3GL bietet.

Das ist nun endlich nicht länger mehr Theorie. Denn jetzt habe ich
eine erste vorzeigbare Version einer solchen Flow Runtime gebastelt.
Sie heißt NPantaRhei. In meinem englischen Blog habe ich sie mit drei
einführenden Artikeln beschrieben:

Allgemeine Einführung in die Bedienung -
http://geekswithblogs.net/theArchitectsNapkin/archive/2012/04/27/introduction-to-the-flow-execution-engine-npantarhei.aspx

Parallelisieren -
http://geekswithblogs.net/theArchitectsNapkin/archive/2012/05/02/easily-parallelize-operations-in-flows-using-the-flow-execution-engine.aspx

Fehlerbehandlung -
http://geekswithblogs.net/theArchitectsNapkin/archive/2012/05/05/catch-exceptions-in-concurrent-flows-using-causalities.aspx

Natürlich gibt es noch mehr zu sagen, z.B. über Standardoperationen
wie Join oder Operationen mit mehreren Input/Output-Ports oder Tracing
oder Throttling oder geschachtelte Flows.

Bei NPantaRhei ist natürlich nicht alles perfekt - aber ich finde sie
gut genug, um ihr eine Chance zu geben. Einfach mal ausprobieren.

Freue mich auf eine Diskussion darüber hier.

[Ole Bulbuk]

Hallo Ralf und alle,

schoen mal wieder was von Dir zu lesen. :-)

> Dem einen oder anderen hatte ich es schon persönlich gesagt: aus
> meiner Sicht ist die Zeit von EBCs nun vorüber. EBC sind tot - lang
> lebe FD und Managed Flow Execution :-)
>
> Die Zukunft der Implementierung von Flow Design Modellen sehe ich in
> einer Runtime, die Flows ausführt. Auch wenn das ein bisschen an der
> Performance kratzt, überwiegen für mich ganz klar die Vorteile.

Ich bin mir nicht sicher, dass die Vorteile wirklich ueberwiegen.
Ich sehe auf jeden Fall 2 grosse Nachteile:

1. Das Debuggen wird schwer.
Egal, ob ich die Doku von einer Standardoperation nicht richtig
verstanden habe oder einfach einen Fehler in meinem Flow habe oder
gar ein Fehler in der Runtime existiert.
Ich muss (vermutlich; habe ich in diesem Fall noch nicht
verifiziert) durch die Runtime debuggen um den Fehler aufspueren zu
koennen.
Das ist sehr viel Code, den ich vorher noch nie gesehen geschweige
denn geschrieben habe. Die meisten Entwickler geben da nach kurzer
Zeit auf.
2. Die Operationen koennen nicht beliebig klein sein.
Spaetestens, wenn sie die Groesse des Runtime-Overheads erreicht
haben ist Schluss.
Persoenlich bevorzuge ich moeglichst kleine und generische
Operationen.

> Mit einer Runtime müssen Flows nicht mehr in umständlicher Event-
> Verdrahtung codiert werden.

Eine "Standard-DSL" waere eine tolle Sache.
Da arbeite ich sehr gerne mit.
In den naechsten Wochen moechte ich da auch gerne einen Vorschlag
machen.

> Mit einer Runtime ist die Parallelisierung von Operationen viel
> einfacher möglich, nämlich deklarativ.

Das ist ein interessanter Punkt, den ich noch nicht durchdacht
habe. Allerdings vermute ich, dass es auch ohne geht.

> Mit einer Runtime kann Einfluss auf die Ausführung zur Laufzeit
> genommen werden.

Zur Laufzeit Konfiguration oder Code nachladen geht doch auch.

> Allgemeine Einführung in die Bedienung -
>
> http://geekswithblogs.net/theArchitectsNapkin/archive/2012/04/27/introduction-to-the-flow-execution-engine-npantarhei.aspx
>
> Parallelisieren -
>
> http://geekswithblogs.net/theArchitectsNapkin/archive/2012/05/02/easily-parallelize-operations-in-flows-using-the-flow-execution-engine.aspx
>
> Fehlerbehandlung -
>
> http://geekswithblogs.net/theArchitectsNapkin/archive/2012/05/05/catch-exceptions-in-concurrent-flows-using-causalities.aspx

Die Artikel lese ich natuerlich noch genau.
Da werden auf jeden Fall zwei sehr interessante und nicht triviale
Punkte behandelt.
Dann melde ich mich auch noch mit detaillierterem Feedback.

Viele Gruesse

Ole
--
Trettlachstr. 34
91301 Forchheim
Tel.: 09191 / 79 40 838
Handy: 0170 / 241 6339

[Ralf Westphal]

1. Das Debuggen wird schwer.
  Egal, ob ich die Doku von einer Standardoperation nicht richtig
  verstanden habe oder einfach einen Fehler in meinem Flow habe oder
  gar ein Fehler in der Runtime existiert.

Dass du das Thema Debuggen aufwirfst, ist verständlich. Und ich habe dazu auch nicht alle antworten. Deshalb aber gleich so eine Runtime abzutun, finde ich vorschnell. Warum nicht versuchen, die Herausforderungen anzunehmen und Lösungen zu finden?

Zu deinen Punkten:

-Wenn die Runtime einen Fehler hat, dann ist das kein anderes Problem als wenn die CLR einen Fehler hätte. Ich debugge nicht in die CLR oder den .NET Fx. Wäre ja noch schöner. Ich hab andere Sachen zu tun. Solches Zeugs muss korrekt sein. So korrekt zumindest, dass ich mir 99,999% meiner Zeit darüber keine Gedanken machen muss. Und das ist es. Und eine Flow Runtime muss auch das Level erreichen.

-Dasselbe gilt für Standardoperationen. Du musst .NET Fx Klassen verstehen und du musst Flow Standard Ops verstehen. Auch kein Unterschied. Wer sie falsch anwendet, der hat ein Problem. Das taucht dann in deinem Code auf. Deshalb musst du nicht in Standard Ops reindebuggen.

-Also deinen Code debuggen. Ja, das ist irgendwie merkwürdig, wenn du nur noch Operationen schreibst, die über Flows zusammengehängt werden. Es gibt keinen Call Stack mehr. Der Zusammenhang ist irgendwie nicht mehr so gut zu sehen, wenn du auf einen Breakpoint in einer Op läufst.

Was tun? Hinschmeißen? Wieder zurück zu EBC? Ne, die Situation verbessern:

1. Debuggen war noch nicht eine gute Sache. Ich debugge auch nur noch selten. Stattdessen schreibe ich Tests. Und das wird mit FD eben einfacher. Weil da Unit Tests auf Operationen wirkliche Unit Tests sind, ohne Abhängigkeiten. Das Debuggen hat bei FD Implementierungen mit oder ohne Runtime einen anderen Stellenwert.

2. Das Testen von Flows ist natürlich so eine Sache, besonders wenn die nicht mehr in einer 3GL geschrieben werden, sondern als Liste. Da können wir alle noch forschen. Mehr Review ist sicherlich angezeigt. Aber einzelne Flows testen, das geht schon. Dafür darf es gern ein Testwerkzeug geben. Müssen wir mal drüber nachdenken.

3. Wenn ich denn aber nicht umhin komme und in einer Operation auf einem Breakpoint stehe, während sie in einem Flow ausgeführt wird, wie kann ich dann den Kontext sehen, den Weg, den die Daten bis dahin genommen haben? Gute Frage. Wie wäre es mit einem Trace von Nachrichten? Nichts anderes ist ja ein Call Stack. So ein Trace ist leicht aufzusetzen, sogar mit Filtern. Du tracet Nachrichten und schaust darauf, wenn du auf einem Breakpoint in einer Op stehst. (Da darf natürlich ein Tool gern helfen, so einen Trace irgendwie zu visualisieren.)

Also: Ich sehe einen Runtime mit ihren Vorteilen nicht verloren, nur weil das Debugging irgendwie anders ist also sonst. Mit EBC war es auch nicht mehr so flauschig wie früher.

Und wir sollten klar sehen: Wenn wir Strukturen favorisieren, weil sie leicht zu debuggen sind, dann machen wir den Bock zum Gärtner. Ich will Strukturen, die leicht zu evolvieren und zu testen sind. Das halte ich für wichtiger.

 

  Ich muss (vermutlich; habe ich in diesem Fall noch nicht
  verifiziert) durch die Runtime debuggen um den Fehler aufspueren zu
  koennen.
  Das ist sehr viel Code, den ich vorher noch nie gesehen geschweige
  denn geschrieben habe. Die meisten Entwickler geben da nach kurzer
  Zeit auf.

Niemand soll durch die Runtime debuggen. Das ist doch klar. Das tust du mit dem .NET Fx auch nicht.

Man muss einfach ein anderes Vorgehen lernen. Flow ist ein neues Denken - auch beim Debuggen.

 

2. Die Operationen koennen nicht beliebig klein sein.
  Spaetestens, wenn sie die Groesse des Runtime-Overheads erreicht
  haben ist Schluss.
  Persoenlich bevorzuge ich moeglichst kleine und generische
  Operationen.

Ich sag mal: Versuch mach kluch. Nicht spekulieren, sondern ausprobieren. Wenn du gegen eine Performancewand läufst, dann melde dich.

Wir haben heute GC und virtuelle Methoden und deklarative Security usw. Wenn wir mit Funktionsgrößen argumentiert hätten vor 10 oder 20 Jahren, dann wären wir immer noch bei C.

Der Spruch ist ja schon alt: Jedes Problem in der Informatik lässt sich durch eine weitere Indirektion lösen.

Stimmt :-) Deshalb haben wir Compiler, deshalb haben wir Managed Code. Und deshalb lohnt am Ende auch eine Execution Engine für Flows.

 

Eine "Standard-DSL" waere eine tolle Sache.

Da habe ich schon eine konkrete Aufgabe für dich (und alle, die mittun wollen). Ist ganz, ganz einfach :-)

Jeder Flow lässt sich durch eine Liste von Streams ausdrücken:

R:

.in,A

A,B.in

B.out,C

C,.out

Da sind einfach Output- mit Input-Ports verbunden.

Wenn nun z.B. aber B ein Sub-Flow ist, der so aussieht:

B:

.in,S

S,T

T,.out

wie kann dann der ganze Flow aus eine Liste notiert werden?

Das sieht so aus:

.in,R/A

R/A,R/B.in

R/B.out,R/C

R/C,.out

R/B.in,R/B/S

R/B/S,R/B/T

R/B/T,R/B.out

Der Subflow wird expandiert. Alle Operationen werden mit einem Pfad versehen.

Ich wünsche mir nun einen kleinen "Normalisierer", der eine Liste von Flows nimmt und daraus einen Flow bastelt. Das wäre eine gute Grundlage, um darauf einen Designer zu setzen. Denn in dem will ich mit Subflows arbeiten.

Wie später mal eine DSL aussehen kann... das ist eine andere Frage. Die finde ich noch nicht so wichtig.

Viel wäre gewonnen, wenn wir Flows als Listen notieren könnten und Subflows nebeneinander stellen könnten.

 

Das ist ein interessanter Punkt, den ich noch nicht durchdacht
habe. Allerdings vermute ich, dass es auch ohne geht.

Irgendwie gehen tut ja immer alles. Aber wie einfach? EBCs einfach parallelisieren? Ne, das sehe ich nicht.

 

Mit einer Runtime kann Einfluss auf die Ausführung zur Laufzeit
genommen werden.

Zur Laufzeit Konfiguration oder Code nachladen geht doch auch.

Und wie machst du das in einem EBC-System? Wie hältst du da die Ausführung an?

[Patrick Bédat]

> Mit einer Runtime müssen Flows nicht mehr in umständlicher Event-
> Verdrahtung codiert werden.

Mit einem guten Designtool/Compiler/IDE-Integration aber auch nicht.

Momentan bin ich ganz Happy mit meinem Compiler, der mir aus Dia-Files
zunächst eine Art Flow-AST und hernach C#-Code generiert.
Dazu kommt dann noch in diesem Sommer ein kleiner Server, der mir
dabei helfen soll, Änderungen im Diagramm bzw. Code synchron zu halten
bzw. mir Boilerplate-Code Generierung abnimmt.

Beides übrigens Themen meiner Bachelorarbeit, die ich im August abgeben werde ;)

Die Idee, dass die Namen der FUs in einem Flow einfach zu Funcs mappt
wollte ich auch schonmal so umsetzen, aber ich konnte mich selbst
davon noch nicht wirklich überzeugen.
Vielleicht bin ich ja anderer Meinung, wenn ich mir deine Artikel
durchgelesen habe =)

Cheers

[Ralf Westphal]

Am 8. Mai 2012 13:10 schrieb Patrick Bédat <pbe...@googlemail.com>:

> Mit einer Runtime müssen Flows nicht mehr in umständlicher Event-
> Verdrahtung codiert werden.

Mit einem guten Designtool/Compiler/IDE-Integration aber auch nicht.

Momentan bin ich ganz Happy mit meinem Compiler, der mir aus Dia-Files
zunächst eine Art Flow-AST und hernach C#-Code generiert.
Dazu kommt dann noch in diesem Sommer ein kleiner Server, der mir
dabei helfen soll, Änderungen im Diagramm bzw. Code synchron zu halten
bzw. mir Boilerplate-Code Generierung abnimmt.

Machbar ist ja alles. Habe an diesen Ansatz auch lange geglaubt.

Aber auch wenn ein Compiler das machen kann - am Ende ist das Ergebnis einfach weniger flexibel. Allemal zur Laufzeit.

Für mich sieht der bessere Ansatz so aus: Mit einem Designer eine interpretierbare Flow-Repräsentation erzeugen. Derzeit eben eine Liste von Streams. Einfacher kann es kaum gehen.

Noch ein Vorteil: so eine Liste von Streams kann man in ein C#-Projekt einbetten. Die Liste wird zur Laufzeit interpretiert. Aber man kann sie auch überall auslesen und daraus den Flow re-generieren. Code und Diagramm müssen also nicht mehr künstlich synchron gehalten werden, da das Diagramm (in textueller Form) der Code ist.

[Ole Bulbuk]

Dass du das Thema Debuggen aufwirfst, ist verständlich. Und ich habe dazu auch nicht alle antworten. Deshalb aber gleich so eine Runtime abzutun, finde ich vorschnell. Warum nicht versuchen, die Herausforderungen anzunehmen und Lösungen zu finden?

Nein, abtun moechte ich sicher nichts. Das waere in der Tat viel zu schade.

Aber ich moechte es zu bedenken geben. Das hilft vielleicht die Nachteile zu minimieren.

Zu deinen Punkten:

-Wenn die Runtime einen Fehler hat, dann ist das kein anderes Problem als wenn die CLR einen Fehler hätte. Ich debugge nicht in die CLR oder den .NET Fx. Wäre ja noch schöner. Ich hab andere Sachen zu tun. Solches Zeugs muss korrekt sein. So korrekt zumindest, dass ich mir 99,999% meiner Zeit darüber keine Gedanken machen muss. Und das ist es. Und eine Flow Runtime muss auch das Level erreichen.

Das ist natuerlich eine echte Herausforderung. Zumal dann ja auch ein eigener Debugger etc. gebraucht wird.

Das ist am Ende ein ziemlich dickes Brett. Ich hoffe sehr, dass Du das (mit moeglichst viel Unterstuetzung natuerlich) hinbekommst.

-Dasselbe gilt für Standardoperationen. Du musst .NET Fx Klassen verstehen und du musst Flow Standard Ops verstehen. Auch kein Unterschied. Wer sie falsch anwendet, der hat ein Problem. Das taucht dann in deinem Code auf. Deshalb musst du nicht in Standard Ops reindebuggen.

Ich habe viele Java-Standardbibliotheken erst durch debuggen wirklich richtig verstanden.

Ist sicher nicht mein groesstes Hobby und mache ich auch nur noch selten.

Aber am Anfang muss ich da (leider) fast immer einmal durch.

Geht mir auch mit Webframeworks etc. so.

-Also deinen Code debuggen. Ja, das ist irgendwie merkwürdig, wenn du nur noch Operationen schreibst, die über Flows zusammengehängt werden. Es gibt keinen Call Stack mehr. Der Zusammenhang ist irgendwie nicht mehr so gut zu sehen, wenn du auf einen Breakpoint in einer Op läufst.

Da waere jetzt ein eigener Debugger mit eigenem "Call Stack" (oder besser "Flow History"?) perfekt.

Was tun? Hinschmeißen? Wieder zurück zu EBC?

Ich habe noch nicht verstanden, was Du gegen EBC hast.

Mit meiner Java-Implementierung bin ich bis jetzt recht zufrieden.

Ne, die Situation verbessern:

Aufgeben is nich. Gut Einstellung. :-)

1. Debuggen war noch nicht eine gute Sache. Ich debugge auch nur noch selten. Stattdessen schreibe ich Tests. Und das wird mit FD eben einfacher. Weil da Unit Tests auf Operationen wirkliche Unit Tests sind, ohne Abhängigkeiten. Das Debuggen hat bei FD Implementierungen mit oder ohne Runtime einen anderen Stellenwert.

Das mit den Tests finde ich richtig und auch wichtig. Aber manchmal reichen sie mir dann doch nicht.

2. Das Testen von Flows ist natürlich so eine Sache, besonders wenn die nicht mehr in einer 3GL geschrieben werden, sondern als Liste. Da können wir alle noch forschen. Mehr Review ist sicherlich angezeigt. Aber einzelne Flows testen, das geht schon. Dafür darf es gern ein Testwerkzeug geben. Müssen wir mal drüber nachdenken.

In der Java-Welt gibt es da FitNesse: http://fitnesse.org/

 

 

 

Das laesst sich vermutlich auch mit .Net nutzen.

Ist auf jeden Fall ziemlich einfach aufzusetzen. Und funktioniert recht prima.

In dem Wiki kann man dann auch die Flow-DSL unterbringen und schon hat man eine halbe Entwicklungsumgebung (aber natuerlich ohne Debugger).

3. Wenn ich denn aber nicht umhin komme und in einer Operation auf einem Breakpoint stehe, während sie in einem Flow ausgeführt wird, wie kann ich dann den Kontext sehen, den Weg, den die Daten bis dahin genommen haben? Gute Frage. Wie wäre es mit einem Trace von Nachrichten? Nichts anderes ist ja ein Call Stack. So ein Trace ist leicht aufzusetzen, sogar mit Filtern. Du tracet Nachrichten und schaust darauf, wenn du auf einem Breakpoint in einer Op stehst. (Da darf natürlich ein Tool gern helfen, so einen Trace irgendwie zu visualisieren.)

Am Ende also ein eigener Flow-Debugger.

Finde ich auch eine Supersache. Ist mir momentan allerdings zu aufwendig.

Also: Ich sehe einen Runtime mit ihren Vorteilen nicht verloren, nur weil das Debugging irgendwie anders ist also sonst. Mit EBC war es auch nicht mehr so flauschig wie früher.

Bei mir sind die Unterschiede relativ gering:

Durch Basisklassen habe ich einen unschoeneren Call-Stack, weil in der Historie nur die abstrakte Baisklasse und nicht die konkrete Ableitung angezeigt wird. Die findet man nur durch einen weiteren gezielten Klich heraus. Schwer ist das aber nicht.

Und wir sollten klar sehen: Wenn wir Strukturen favorisieren, weil sie leicht zu debuggen sind, dann machen wir den Bock zum Gärtner. Ich will Strukturen, die leicht zu evolvieren und zu testen sind. Das halte ich für wichtiger.

Wenn ich mich entscheiden *muss*: Sicher!

Wenn auch beides geht: Sicher nicht!

(Das ist natuerlich nur meine private Einschaetzung)

Niemand soll durch die Runtime debuggen. Das ist doch klar. Das tust du mit dem .NET Fx auch nicht.

Man muss einfach ein anderes Vorgehen lernen. Flow ist ein neues Denken - auch beim Debuggen.

Das ist ja OK. Aber bei Java, .NET, etc. bekommt man ja auch eine richtige Entwicklungsumgebung mit allem drum und dran.

Davon ist vieles durch eine Runtime stark im Wert gemindert (debuggen, refaktoren, ...).

Dafuer musst dann Ersatz liefern oder einen sehr sehr guten Mehrwert. Das ist schwer.

Deshalb versuche ich (zunaechst) in einer Java-Implementierung darauf zu verzichten.

2. Die Operationen koennen nicht beliebig klein sein.
  Spaetestens, wenn sie die Groesse des Runtime-Overheads erreicht
  haben ist Schluss.
  Persoenlich bevorzuge ich moeglichst kleine und generische
  Operationen.

Ich sag mal: Versuch mach kluch. Nicht spekulieren, sondern ausprobieren. Wenn du gegen eine Performancewand läufst, dann melde dich.

Das ist zumindest meine Beobachtung, wenn ich sehe, wie mit "aehnlichem" wie zum Beispiel Apache Camel und Activiti (http://activiti.org/) gearbeitet wird.

Du machst Da hoffentlich mehr draus!

Wir haben heute GC und virtuelle Methoden und deklarative Security usw. Wenn wir mit Funktionsgrößen argumentiert hätten vor 10 oder 20 Jahren, dann wären wir immer noch bei C.

Da gebe ich Dir recht. Deshalb will ich da ja auch auf keinen Fall etwas totreden.

Mir geht es eher um gegenseitige Anregungen (auch wenn wir andere Designentscheidungen treffen).

Der Spruch ist ja schon alt: Jedes Problem in der Informatik lässt sich durch eine weitere Indirektion lösen.

Stimmt :-) Deshalb haben wir Compiler, deshalb haben wir Managed Code. Und deshalb lohnt am Ende auch eine Execution Engine für Flows.

Eine "Standard-DSL" waere eine tolle Sache.

Da habe ich schon eine konkrete Aufgabe für dich (und alle, die mittun wollen). Ist ganz, ganz einfach :-)

...

Ich wünsche mir nun einen kleinen "Normalisierer", der eine Liste von Flows nimmt und daraus einen Flow bastelt. Das wäre eine gute Grundlage, um darauf einen Designer zu setzen. Denn in dem will ich mit Subflows arbeiten.

Ich bin an diesen Listen bisher nicht interessiert.

Und habe deren Sinn auch noch nicht verstanden.

Sie enthalten fuer mich eh nur einen Bruchteil der benoetigten Informationen.

Ausserdem sind sie nicht sehr menschenfreundlich zu lesen.

Eine DSL ist mir da wesentlich lieber.

Wie später mal eine DSL aussehen kann... das ist eine andere Frage. Die finde ich noch nicht so wichtig.

Viel wäre gewonnen, wenn wir Flows als Listen notieren könnten und Subflows nebeneinander stellen könnten.

Viel waere gewonnen, wenn wir uns auf eine DSL und Standardoperationen einigen koennten.

Dann koennte ein Flow (relativ) leicht von einer Implementation zur anderen migriert werden.

Irgendwie gehen tut ja immer alles. Aber wie einfach? EBCs einfach parallelisieren? Ne, das sehe ich nicht.

Mit einer Runtime kann Einfluss auf die Ausführung zur Laufzeit
genommen werden.

Zur Laufzeit Konfiguration oder Code nachladen geht doch auch.

Und wie machst du das in einem EBC-System? Wie hältst du da die Ausführung an?

Ich tausche den obersten Flow einfach aus. In Java geht das mit volatile-Variablen ganz gut. Dann nimmt die eine Ausfuehrung des Flows noch die alte Implementierung und ab der naechsten wird die neue Implementierung genommen. Dazu braucht jede Implementierung natuerlich auch ihren eigenen ClassLoader. In meinen Tests ging das ganz gut.

[Ralf Westphal]

muss korrekt sein. So korrekt zumindest, dass ich mir 99,999% meiner Zeit darüber keine Gedanken machen muss. Und das ist es. Und eine Flow Runtime muss auch das Level erreichen.

Das ist natuerlich eine echte Herausforderung. Zumal dann ja auch ein eigener Debugger etc. gebraucht wird.

Das ist am Ende ein ziemlich dickes Brett. Ich hoffe sehr, dass Du das (mit moeglichst viel Unterstuetzung natuerlich) hinbekommst.

Um eine Flow Runtime möglichst fehlerfrei hinzukriegen, brauche ich doch keine speziellen Debugger. Die ist ja nichts anderes als jede andere Library auch. Es geht ja nicht um Bootstrapping.

Ich habe viele Java-Standardbibliotheken erst durch debuggen wirklich richtig verstanden.

Ist sicher nicht mein groesstes Hobby und mache ich auch nur noch selten.

Aber am Anfang muss ich da (leider) fast immer einmal durch.

Geht mir auch mit Webframeworks etc. so.

Tut mir leid, wenn das so ist. Ich habe das in 30 Jahren noch nie gebraucht. Mir auch nie gewünscht.

Einmal habe ich in den ADO.NET Quellcode geschaut. Das war interessant - aber nicht wichtig.

Ich glaube daher nicht, dass das notwendig ist. Und der Anspruch von Softwarebibliotheken sollte immer anders sein.

Wer das als Hobby gern macht: wunderbar. Manche nehmen auch ihr Auto auseinander. Aber selbst Rennfahrer haben nie den Motor ihres Boliden analysiert. Die verlassen sich zurecht darauf, dass er tut, was er tun soll.

Insofern sehe hier kein Argument gegen eine Flow Runtime. Und ich glaube auch nicht, dass du durch die CLR oder JVM gestept bist. Du verlässt dich auf sie. Zurecht. Oder wie schaut es mit dem Betriebssystem aus? Musstest du überall durchlaufen? Kaum. Und wenn... Tut mir leid, das zu sagen, bist du die Ausnahme. 99% der anderen Entwickler tun es de facto nicht - und sind deshalb ja hoffentlich keine schlechten Entwickler, oder?

Wenn ich mich hier so äußere, dann nicht, um dir den Spaß zu verderben, sondern das Bild vom Umgang mit einer Flow Runtime realistisch zu halten.

 

-Also deinen Code debuggen. Ja, das ist irgendwie merkwürdig, wenn du nur noch Operationen schreibst, die über Flows zusammengehängt werden. Es gibt keinen Call Stack mehr. Der Zusammenhang ist irgendwie nicht mehr so gut zu sehen, wenn du auf einen Breakpoint in einer Op läufst.

Da waere jetzt ein eigener Debugger mit eigenem "Call Stack" (oder besser "Flow History"?) perfekt.

"Flow History" klingt gut. Die kannst du ja ganz leicht basteln:

using(var fr = new FlowRuntime())

{

  var flowHistory = new List<IMessage>();

  fr.Message += flowHistory.Add;

  ...

}

Fertig. In der Liste steht am Ende jede Nachricht, die an einen Input-Port geschickt wurde.

Wenn du also in einem Breakpoint stehst, dann schau dir flowHistory an. Dann weißt du, wie du dahin gekommen bist.

 

 

Das laesst sich vermutlich auch mit .Net nutzen.

Ist auf jeden Fall ziemlich einfach aufzusetzen. Und funktioniert recht prima.

In dem Wiki kann man dann auch die Flow-DSL unterbringen und schon hat man eine halbe Entwicklungsumgebung (aber natuerlich ohne Debugger).

Inwiefern Fitnesse etwas zum Testen von Flows beitragen kann, wäre mal zu untersuchen.

So ganz allgemein ist es natürlich kein Problem. Eine Klasse, die eine Flow Runtime instanziert, initialisiert und dann anstößt ist auch nur eine Klasse wie jede andere.

Spannend wird es, wenn man für Tests von Flows ganz einfach für einzelne Operationen Attrappen einsetzen will. Dabei sollte ein Testwerkzeug helfen.

Am Ende also ein eigener Flow-Debugger.

Finde ich auch eine Supersache. Ist mir momentan allerdings zu aufwendig.

Und ist auch nicht nötig. So wie ein Designer nicht nötig ist.

Jedenfalls habe ich ihn in 2 Jahren nicht wirklich vermisst.

Aber nett wär er trotzdem.

Hat nur eben keine hohe Prio bei mir.

 

Davon ist vieles durch eine Runtime stark im Wert gemindert (debuggen, refaktoren, ...).

Ein Tool fürs Refactoring von Flows wäre schon gut.

Ist ja aber unabhängig davon, ob die Flows dann managed oder unmanaged ausgeführt werden.

Das Refactoring würde ja nicht auf einer 3GL Impl von Flows laufen, sondern eben auf irgendeiner DSL.

Auch die Stream-Liste, die die Runtime verarbeitet, ist eine DSL.

 

Das ist zumindest meine Beobachtung, wenn ich sehe, wie mit "aehnlichem" wie zum Beispiel Apache Camel und Activiti (http://activiti.org/) gearbeitet wird.

Du machst Da hoffentlich mehr draus!

Nochmal: Niemand muss irgendwas an der Flow Runtime in puncto Performance tun, solange es keinen Beleg gibt, dass da irgendwas besonders hinderlich wäre. Das bedeutet: Erst einsetzen und probieren, dann klagen, dann verbessern.

 

Ich bin an diesen Listen bisher nicht interessiert.

Und habe deren Sinn auch noch nicht verstanden.

Sie enthalten fuer mich eh nur einen Bruchteil der benoetigten Informationen.

Ausserdem sind sie nicht sehr menschenfreundlich zu lesen.

Eine DSL ist mir da wesentlich lieber.

Die Liste ist eine ausführbare DSL. Das (!) ist ihr Sinn.

Und lesbarer ist die Liste auch noch:

A,B

B,C

ist leichter verständlich als

A.Result += B.Process;

B.Result += C.Process;

Und dann lässt sich aus der Liste auch noch das Diagramm für einen Flow relativ einfach re-generieren. Das mach mal mit dem 3GL oder Bytecode.

Niemand behauptet auch, dass du einen Flow in einer einzigen Liste beschreiben sollst. Sie muss auch nicht so "ärmlich" sein.

Ich behaupte nur, dass 1 Liste die einfachste Form der Beschreibung eines Flow ist. Sogar, wenn der hierarchisch ist, reicht 1 Liste. Womit ich wieder bei der Ausführbarkeit bin. Und aus der resultieren dann die Vorteile wie Tracing, Concurrency, Reverse Modelling usw.

Auf diese simpelst mögliche DSL kannst du eine andere textuelle oder eine graphische setzen, wenn du willst. Ich will das grad nicht :-)

Du kannst diese simple Form auch erweitern, z.B.

A,B,int

B,C*,string

C,D,System.IO.FileStream

Hier habe ich den Streams Typen gegeben und C als async auszuführen markiert.

Nur als Beispiel.

Dass du lieber schreiben würdest:

A -(int)> B -(string)> C* -(System.IO.FileStream)> D.

ist mir auch klar. Oder eben ein Diagramm malen.

Bitteschön. Kannste ja machen.

Nur daraus dann EBC-Code zu generieren ist schwieriger als eine Liste von Streams und ein paar Operationsregistrierungen. Oder warum überhaupt die Operationen registrieren? Die kann der FlowOperationContainer eigentlich auch aus einer Liste von Assemblies selbst rauslesen. So würde das Programm zur Laufzeit zusammengewoben. Warum also überhaupt 3GL Code generieren?

Mit einer Runtime haben wir mehr Optionen, denke ich.

 

Wie später mal eine DSL aussehen kann... das ist eine andere Frage. Die finde ich noch nicht so wichtig.

Viel wäre gewonnen, wenn wir Flows als Listen notieren könnten und Subflows nebeneinander stellen könnten.

Viel waere gewonnen, wenn wir uns auf eine DSL und Standardoperationen einigen koennten.

Dann koennte ein Flow (relativ) leicht von einer Implementation zur anderen migriert werden.

Klar. Und wie sieht die einfachste Form einer textuellen Beschreibung hierarchischer Flows aus?

Es ist eine Liste von Streams. Einfacher geht es nicht mehr.

Ich würde jetzt keine Zeit darauf verschwenden, in einem Communityprozess eine DSL zu definieren. Anläufe dazu gab es schon. Ist nix draus geworden. Mit der Runtime ist nun aber ganz einfach Butter bei die Fische gepackt: die einfachste DSL wird dort benutzt. Damit ist mal ein Pflock im Boden. Wer jetzt mehr braucht - und ich meine: wirklich braucht -, der soll von dort losgehen.

[Denis]

Hallo,

ich hab Ralfs Artikel schon vor ein paar Tagen gelesen (und auch gleich in der LinkIn-Gruppe annonciert :-) und sehe in der Runtime den größten Vorteil darin, das Parallelisierung und Asynchronität deklarative spezifiziert werden können. Denn das sind aus meiner Sicht die größten Herausforderungen an neue Programmierparadigmen, um damit Software schreiben zu können, die moderne Multicore-Systemen adäquat auslastet, aber auch von Durchschnittsprogrammierern/-Designern fehlerfrei gehandhabt werden kann. Denn machen wir uns nichts vor, Java, aber auch C#, schleppen and dieser Stelle schon zuviele historische Altlasten mit sich herum, als das sie hier innovativ einen Neuansatz in der Sprache hervorbringen könnten. C# hat es zwar mit den Schlüsselwörtern async/await und den dahinter stehenden Konzepten versucht. Aber ist eben nur ein weiteres Sprach-Feature und insofern nicht ein immanentes Prinzip der Sprache.

Scala ist da mit seiner Actors-Bibliothek sehr viel(-versprechend) weiter und für mich die prädestinierte Sprache um Flow-Designs mit geringst möglichem Aufwand und größtmöglicher Ähnlichkeit zum Flow-Design-Prinzip selbst zu implementieren. Und ich sehe, aus dem Lesen der Artikel zu NPantharei, viele Ähnlichkeiten zwischen der Implementierung von NPantharei und den Prinzipien der Actors-Bibliothek (wer zu Scala-Actors mehr lesen will, der kann hier nach lesen: http://lamp.epfl.ch/%7Ephaller/doc/haller07coord.pdf).

He, wer kann Scala gut genug (ich leider noch nicht), um darin NPantharei nachzuimplementieren? Soweit ich weiss, müssten sich mit solch einer Implementierung auch Java-basierte FEs in Flow-Designs verweben lassen. Das ist das, was ich gerne hätte ...

Ich hatte schon mal angefangen, eine DSL für FD mit XText für Eclipse zu implementieren (https://github.com/kuniss/XTextEBC) - Ziel der Code-Generierung sollte EBC4J sein -, aber leider bin ich aus zeitlichen Gründen nicht über eine partielle Implementierung der DSL und des Editors (der bei Xtext aus der Grammatik generiert wird) hinausgekommen. Die Idee dahinter war, auf Basis des durch die XText-Technologie generierten abstrakten Modells der DSL ein graphischen Editor für FD in Eclipse zu erzeugen. Zumindest hatte ich bei XText ein Tutorial gelesen, das den Eindruck machte, es wäre nicht allzu aufwendig, dies zu bewerkstelligen.

Meine damalige DSL basierte auf einer Diskussion hier in dieser Gruppe. Heute würde ich Ralfs Vorschlag einer Liste von Flows folgen, die der Xtext-Generator dann zu einem Flow normalisiert. Dieser wäre dann Input für eine Flow-Execution-Engine der jeweils benutzten Plattform. Aber da, wie Ralf schon bemerkt hat, diese Liste von Flows auch eine DSL ist, wäre es gut, sich auf eine gemeinsame Notation zu einigen (als wie wird Parallelisierung oder Asynchronität deklarativ spezifiziert, gibt es spezielle Namen für Standard-FEs, wie werden zustandsbehaftete FE's markiert usw.).

Beim Debuggen bin ich Ralf's Meinung. Ich benutze den Debugger äusserts selten, und erst recht nicht, um die Semantik einer Bibliothek zu verstehen. Das ist ein bischen so, als ob Du Dir bei der Benutzung eines Interfaces im Client-Code die dahinterliegende konkrete Implementierung im Debugger anschaust. Das kann sehr trügerisch sein und zu einem falschen Verständnis des Interfaces führen. Im schlimmsten Fall schleichen sich subtile Abhängigkeiten zur debuggten konkreten Implementierungsklasse in den Client-Code ein, der dann mit einer anderen Implementierung des Interface nicht mehr funktioniert.

Ralf, ich habe mir Deinen Code noch nicht angesehen. Ich nehme mal an, das Design ist mit konkreten Flow-Design-Diagrammen dokumentiert. Ich habe festgestellt, dass wie bei anderen Diagrammen auch Flow-Design-Diagramme nicht ohne erläuternde Prosa auskommen. Ich denke, das liegt eher daran, das Namen für FEs immer zu kurz und zu mehrdeutig sind, egal, wie lang man sie wählt, und das dies eher an der Mehrdeutigkeit der natürlichen Sprache selbst liegt. Jetzt meine Frage: Sind die von Dir oben genannten Artikel als Erläuterungen zu den FD-Diagrammen der Implementierung anzusehen, oder gibt es bei den Flow-Diagrammen des NPantharei noch mal zusätzlichen Erläuterungen?

Gruß, Denis

[Ralf Westphal]

Scala ist da mit seiner Actors-Bibliothek sehr viel(-versprechend) weiter und für mich die prädestinierte Sprache um Flow-Designs mit geringst möglichem Aufwand und größtmöglicher Ähnlichkeit zum Flow-Design-Prinzip selbst zu implementieren. Und ich sehe, aus dem Lesen der Artikel zu NPantharei, viele Ähnlichkeiten zwischen der Implementierung von NPantharei und den Prinzipien der Actors-Bibliothek (wer zu Scala-Actors mehr lesen will, der kann hier nach lesen: http://lamp.epfl.ch/%7Ephaller/doc/haller07coord.pdf).

Scala mag es einfach machen, Flows zu implementieren.

Wenn aber eine Runtime in Spiel kommt, dann ist genau das ja eben recht egal. Weil die Runtime den Flow interpretiert und der ihr in irgendeiner DSL mitgeteilt wird. Dann sind die Sprachfeatures einer 3GL einerlei, solange man bei der Runtime Operationen irgendwie registrieren kann. (Funktionszeiger/Delegaten helfen allerdings, eine Runtime mit einem netten API und Operationen zu implementieren.)

 

Meine damalige DSL basierte auf einer Diskussion hier in dieser Gruppe. Heute würde ich Ralfs Vorschlag einer Liste von Flows folgen, die der Xtext-Generator dann zu einem Flow normalisiert.

Dafür braucht es doch aber keinen DSL Werkzeugkasten. Wenn in einer Datei eine Hierarchie von Flows steht, dann kann man mit einem Batchprogramm daraus eine flache Liste von Streams machen.

(Wie die Hierarchie von Flows in die Datei kommt, ist eine andere Frage ;-)

Ralf, ich habe mir Deinen Code noch nicht angesehen. Ich nehme mal an, das Design ist mit konkreten Flow-Design-Diagrammen dokumentiert. Ich habe festgestellt, dass wie bei anderen Diagrammen auch Flow-Design-Diagramme nicht ohne erläuternde Prosa auskommen. Ich denke, das liegt eher daran, das Namen für FEs immer zu kurz und zu mehrdeutig sind, egal, wie lang man sie wählt, und das dies eher an der Mehrdeutigkeit der natürlichen Sprache selbst liegt. Jetzt meine Frage: Sind die von Dir oben genannten Artikel als Erläuterungen zu den FD-Diagrammen der Implementierung anzusehen, oder gibt es bei den Flow-Diagrammen des NPantharei noch mal zusätzlichen Erläuterungen?

NPantaRhei ist natürlich mit FD modelliert und mit EBC implementiert.

Es gibt dazu im Repository auch Diagramme - doch die sind veraltet. Am Ende habe ich gemerkt, dass ich sie einfach nicht brauche. Für einen Einsteiger sind sie aber hilfreich ;-) Ich habe die Flows aus dem EBC-Verdrahtungscode ausgelesen und sie darin direkt verändert während der Arbeit.

 

Gruß, Denis

Am Dienstag, 8. Mai 2012 13:16:41 UTC+2 schrieb Ralf Westphal:

Am 8. Mai 2012 13:10 schrieb Patrick Bédat <pbe...@googlemail.com>:

> Mit einer Runtime müssen Flows nicht mehr in umständlicher Event-
> Verdrahtung codiert werden.

Mit einem guten Designtool/Compiler/IDE-Integration aber auch nicht.

Momentan bin ich ganz Happy mit meinem Compiler, der mir aus Dia-Files
zunächst eine Art Flow-AST und hernach C#-Code generiert.
Dazu kommt dann noch in diesem Sommer ein kleiner Server, der mir
dabei helfen soll, Änderungen im Diagramm bzw. Code synchron zu halten
bzw. mir Boilerplate-Code Generierung abnimmt.

Machbar ist ja alles. Habe an diesen Ansatz auch lange geglaubt.

Aber auch wenn ein Compiler das machen kann - am Ende ist das Ergebnis einfach weniger flexibel. Allemal zur Laufzeit.

Für mich sieht der bessere Ansatz so aus: Mit einem Designer eine interpretierbare Flow-Repräsentation erzeugen. Derzeit eben eine Liste von Streams. Einfacher kann es kaum gehen.

Noch ein Vorteil: so eine Liste von Streams kann man in ein C#-Projekt einbetten. Die Liste wird zur Laufzeit interpretiert. Aber man kann sie auch überall auslesen und daraus den Flow re-generieren. Code und Diagramm müssen also nicht mehr künstlich synchron gehalten werden, da das Diagramm (in textueller Form) der Code ist.

--
Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[Denis]

Scala mag es einfach machen, Flows zu implementieren.

Wenn aber eine Runtime in Spiel kommt, dann ist genau das ja eben recht egal. Weil die Runtime den Flow interpretiert und der ihr in irgendeiner DSL mitgeteilt wird. Dann sind die Sprachfeatures einer 3GL einerlei, solange man bei der Runtime Operationen irgendwie registrieren kann. (Funktionszeiger/Delegaten helfen allerdings, eine Runtime mit einem netten API und Operationen zu implementieren.)

Oh, da hast Du mich missverstanden. Mir ging es nicht um eine zu NPantharei alternative Programmier-Plattform. Vielmehr war meine Idee, NPantharei in Scala zu reimplementieren, um auf der JVM-Plattform eine Flow Execution Egine zu haben. Dafür halte ich jedoch Scala am geeignetsten, weil sie aus meiner Sicht den FD-Prinzipien am nächsten kommt; auf jeden Fall geeigneter als Java. Im Allgemeinen halte ich Scala auch geeigneter als C#.
 

 

Meine damalige DSL basierte auf einer Diskussion hier in dieser Gruppe. Heute würde ich Ralfs Vorschlag einer Liste von Flows folgen, die der Xtext-Generator dann zu einem Flow normalisiert.

Dafür braucht es doch aber keinen DSL Werkzeugkasten. Wenn in einer Datei eine Hierarchie von Flows steht, dann kann man mit einem Batchprogramm daraus eine flache Liste von Streams machen.

(Wie die Hierarchie von Flows in die Datei kommt, ist eine andere Frage ;-)

Ja sicher. Ich wollte damals XText jedoch noch aus anderen Gründen ausprobieren. Und eine DSL für FD bot sich da für mich gerade als gutes Beispiel an.
Generell denke ich, je komplexer und umfangreicher die Projekte, die mit FD realisiert werden wollen, um so eher wird Werkzeugunterstützung notwendig und hilfreich sein. Mit Xtext generierte Eclipse-Editoren könnten da sehr hilfreich sein, da sie von Hause aus Auto-Vervollständigung abieten, auch für Klassen aus anderen Eclipse-Projekten, die potentiell eine Implementierung einer Flow-FE sein könnten.
Vielleicht ist dann ja auch der grafische Editor nicht weit... 
Und dafür wäre es gut Deine kleine DSL der Flow-Listen zu formalisieren und festzulegen.

NPantaRhei ist natürlich mit FD modelliert und mit EBC implementiert.

Es gibt dazu im Repository auch Diagramme - doch die sind veraltet. Am Ende habe ich gemerkt, dass ich sie einfach nicht brauche. Für einen Einsteiger sind sie aber hilfreich ;-) Ich habe die Flows aus dem EBC-Verdrahtungscode ausgelesen und sie darin direkt verändert während der Arbeit.

Da bin ich jetzt aber enttäuscht ;-)
Aber mal im Ernst: Bei vielen Open-Source-Projekten is es ja gerade deswegen so schwer reinzukommen, um z.B. mal eine kleine Erweiterung zu machen, da man sich die Architektur aus dem Code erarbeiten muss. Mit FD sollte doch gerade das anders sein. Aber wenn die FD-Diagramme veraltet oder nicht vorhanden sind, dann ist NPantharei da diesbzgl. nicht anders...

[Ralf Westphal]

Da bin ich jetzt aber enttäuscht ;-)
Aber mal im Ernst: Bei vielen Open-Source-Projekten is es ja gerade deswegen so schwer reinzukommen, um z.B. mal eine kleine Erweiterung zu machen, da man sich die Architektur aus dem Code erarbeiten muss. Mit FD sollte doch gerade das anders sein. Aber wenn die FD-Diagramme veraltet oder nicht vorhanden sind, dann ist NPantharei da diesbzgl. nicht anders...

einerseits ist NPantaRhei derzeit da nicht anders.

andererseits ist es aber anders, weil eben die struktur durch EBC anders ist. es ist ganz klar, wo man reinschauen muss um zu verstehen, wie es funktioniert. man fängt an der schnittstelle IFlowRuntime an und verfolgt den flow zu einem API methode, der einen interessiert.

und dann: ja, weil es nicht anders ist, ist NPantaRhei eben wichtig. weil es auf einer DSL läuft. die kann man leichter in eine grafik "decompilieren" als c# code.

[Christof Konstantinopoulos]

Hallo Ralf,

du hast geschrieben :
 

Es gibt dazu im Repository auch Diagramme - doch die sind veraltet. Am Ende habe ich gemerkt, dass ich sie einfach nicht brauche. Für einen Einsteiger sind sie aber hilfreich ;-) Ich habe die Flows aus dem EBC-Verdrahtungscode ausgelesen und sie darin direkt verändert während der Arbeit.

Genau so geht es mir zur Zeit in dem Projekt, dass ich im Rahmen meiner Masterarbeit erstelle. Wenn ich am Quelltext arbeite, dann bin ich so tief drinn, dass sich das Flow - Diagramm praktisch von alleine in meinem Kopf bildet. Ein Blick auf die EBC Verdrahtung im Quelltext reicht aus.
Aber das birgt eine Gefahr! Wenn man aus dem Projekt herausgerissen wird und zwei Tage lang nicht an dem Projekt arbeiten kann, dann ist der Einstieg nicht mehr so leicht. Dann sind die Namen doch nicht mehr so eindeutig, wie zuerst gedacht. Und die Karte im Kopf ist dann schon ein wenig verblasst.

Bei mir kommt noch hinzu, dass wir zu zweit an der Software arbeiten und der Kollege noch kein "EBC" Profi ist. Ihm fällt es deutlich schwerer die Diagramme im Kopf zu erstellen. Daher ist es aus meiner Sicht wichtig die Flow Diagramme aktuell zu halten.

Und genau da greift ja auch deine Flow Runtime ins System ein. Die Liste mit den Verdrahtungen lässt sich leichter in ein Diagramm umwandeln als die EBC Verdrahtung im Quelltext. Das ist ein großer Schritt!

Ich hatte leider noch keine Zeit näher in die Runtime zu schauen, aber nach dem was ich bisher gelesen habe, könnte Sie mir auch im aktuellen Projekt helfen. Auf jeden Fall bleibe ich am Ball!

Viele Grüße,
Christof

[Ralf Westphal]

Aber das birgt eine Gefahr! Wenn man aus dem Projekt herausgerissen wird und zwei Tage lang nicht an dem Projekt arbeiten kann, dann ist der Einstieg nicht mehr so leicht. Dann sind die Namen doch nicht mehr so eindeutig, wie zuerst gedacht. Und die Karte im Kopf ist dann schon ein wenig verblasst.

Das ist natürlich wahr. Aber darin unterscheidet sich EBC-Code erstmal nicht von anderem :-)

Auch das Problem mit der Benennung geht nicht weg mit FD oder EBC.

 

Bei mir kommt noch hinzu, dass wir zu zweit an der Software arbeiten und der Kollege noch kein "EBC" Profi ist. Ihm fällt es deutlich schwerer die Diagramme im Kopf zu erstellen. Daher ist es aus meiner Sicht wichtig die Flow Diagramme aktuell zu halten.

In jedem Fall wäre es vorteilhaft, Flow Diagramme aus dem Code generieren zu können. Für den Flow soll es nur eine Wahrheit geben: den Code. Und wer den nicht lesen kann, der erzeugt sich dafür dann eine Grafik.

Wichtig ist: Quelle für Grafik und Ausführung sind dasselbe.