Kontrollstrukturen in Flow Design

[Daniel]

Liebe Flow Designer,

wie kann man im Flow Design Kontrollstrukturen abbilden? Gemeint sind
hier nicht die if/else oder switch Strukturen innerhalb einer
Funktionseinheit, sondern die im Fluss selbst.

Unser Team hat beim Herbstcampus die Vorträge von Ralf und Stefan
gehört, und wir versuchen ein erstes Projekt zu modellieren. Es
handlet sich hierbei um ein Terminal, bei dem man per RFID sehr
unterschiedliche Aktionen anstoßen kann.

Eine Weiche habe ich in der EBC Notation nicht gefunden. Wie gehe ich
damit um, wenn ich einen Status unterschiedlich behandeln möchte.

Könnt ihr uns hier einen Tipp geben?

Vielen Dank!

[Ralf Westphal]

kannst du bitte etwas konkreter werden.

kontrollstrukturen gibt es in FD nicht. "koordinationsstrukturen" (z.B. join) gibt es.

FD hat aber keinen satz an koordinationsstrukturen. deshalb kannst du auch keine finden.

wenn du eine brauchst, dann baust du dir eine.

mit einem konkreteren szenario könnte ich aber konkreter antworten.

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

[pbedat]

Du könntest entweder einer Kompenente mehrere Ausgänge verpassen oder
vielleicht sowas hier:

o -> listen_to_rfid -> select_and_run_service -> o

wobei select_and_run_service ein Mapping von rfid-code zu Komponente
als direkte Abhängigkeit bekommt ;)

für einfache true/false Abzweigungen benutze ich eine Selbstgebaute
Koordinationsstruktur namens ConditionalGate die Anhand einer
Func<Message,bool> entscheidet ob Output0 oder Output1 angesteuert
wird.

[Daniel]

Vielen Dank schon einmal für die schnellen Antworten auf meine Frage!

Ich versuche ein konkreteres Beispiel zu formulieren und meine Frage
schärfer zu fassen: Ich möchte verstehen, wie ihr einen selektiven
Fluss modelliert.

In der dotnetpro 10/2011 schlägt Ralf auf S.134 einen Adapter für die
Abfrage von Daten aus dem Internet vor. Der Adapter soll verdecken,
mit welcher Art von Webservice kommuniziert wird. Das ist einfach und
klar. Input für den Adapter sind z.B. Konfigurationsdaten: URI und
welches Datenformat, also z.B. ob xml oder JSON. Output ist CSV.

Nehmen wir jetzt an, dass wir in den Adapter reinzoomen.Hier brauche
ich nun eine Selektion aufgrund des Datenformats. Wenn ich JSON
erwarte, rufe ich die JSON Funktionseinheit "Konvertiere JSON zu CSV"
auf, wenn XML die "Konvertiere XML zu CSV". Wie malt ihr das so aufs
Papier das auch klar wird, das die Funktionseinheiten nicht beide
aufgerufen werden. So das es klar ist, dass es sich nicht um eine Fork
handelt, sondern um ein Switch?

Ich mag die Idee von pbedat und werde das ähnlich implementieren. Aber
in der Notation fehlen hierfür doch Elemente die klar hervorheben,
dass bestimmte Output-Pins nur konditional bedient werden, oder? Im
UML Aktivitätsdiagramm wäre das eine Raute und ich werde das einfach
mal so zum Kommunizieren im Team benutzen.

[Ralf Westphal]

Ich versuche das Beispiel nochmal zu konkretisieren:

Es sollen Daten aus einer Konfigurationsdatei gelesen werden. Mal sind das Json Daten, mal CSV. Am Ende kommt aber immer dasselbe heraus, ein Config-Objektgraph.

Input für das Ganze ist eine URI bzw. ein Dateiname.

Output ist der Config-Objektgraph.

-(uri)-> (Konfiguration laden) -(Config)->

Das Laden zerfällt in zwei Schritte: Die Daten in den Speicher holen und die Daten parsen.

Die Schwierigkeit nun: Es gibt zwei Parser. Es muss also einer ausgewählt werden nach dem Laden.

Wie findet die Auswahl statt (aufgrund der URI oder aufgrund des Inhalts)?

Wo findet die Auswahl statt (vor dem Laden oder hinterher)?

Ich mache es mir einfach und sage: Die Auswahl findet aufgrund der Daten statt. Eine Json Daten kann man leicht von CSV Daten unterscheiden.

(Konfiguration laden) {

  (this) -(uri)-> (Daten laden) -(konfigdaten:string)-> (Datenformat erkennen),

  (Datenformat erkennen.Json) -(string)-> (Json nach Config parsen) -(Config)-> (this),

  (Datenformat erkennen.CSV) -(string)-> (CSV nach Config parsen) -(Config)-> (this),

}

Jetzt frage ich mich, ob FD dringend weitere Notationselemente braucht, um das zu verstehen?

Sollten die Output-Pins .Json und .CSV irgendwie speziell gekennzeichnet sein als "alternativ"?

Sollte (Datenformat erkennen) speziell gekennzeichnet sein als "Entscheidungsoperation"?

Hm... ersteres vielleicht.

Aber ich empfinde da keinen Druck. In den vielen Flow-Designs, die ich schon gemalt habe, war die Semantik in dieser Hinsicht kein Problem, das mir im Gedächtnis geblieben ist.

Ich denke, das Geheimnis liegt in der passenden Benennung einer entscheidenden Funktionseinheit.

[chrkon]

Ich habe selber mal einem "Switch" erstellt. Dieser hat bei mir zwei
Eingänge und zwei Ausgänge

Eingang "inPath" definiert die Schalterstellung und
Eingang "inData" nimmt die Daten an.
Die Daten werden einfach an einen der beiden Ausgänge weitergereicht.
Halt abhängig davon, was vorher an den "inPath" Eingang gesendet
wurde.

Bei mir kam die Entscheidung aus der GUI. Bei Dir wird sie vom
Programm getroffen. Es könnte also eine Funktionseinheit geben, die
die gewünschte Schalterstellung setzt. Das hat aber einen kleinen
Nachteil. Die Entscheidungseinheit muss den Switch kennen. Also
entsteht eine Abhängigkeit zwischen den Funktionseinheiten. Das
gefällt mir nicht.

Bei Ralfs Ansatz verschwindet diese Abhängigkeit innerhalb der
Funktionseinheit. Ich denke auch, dass man keine speziellen Strukturen
aufbauen muss. Aus der Namensgebung sollte klar werden, dass entweder
der eine oder der andere Pfad durchlaufen wird.

Viele Grüße,
Christof

[Daniel]

Vielen Dank allen die sich die Zeit für meine Frage genommen haben!

Sicher waren wir zu sehr auf die Notation fixiert. Im Team waren wir
eben bei diesem Punkt verwirrt und wollten es "richtig" machen. Am
Ende zählt, dass man richtig kommuniziert und sich versteht.
Danke auch für die Ansätze bei der Implementierung. Wenn wir an dem
Punkt sind, liefern wir nochmal Feedback.

Schönes Wochenende allerseits!
Daniel