Programowanie Oparte Na Przepływach

1. Czy używałeś FBP do prawdziwego projektu?

Zaprojektowaliśmy i wdrożyliśmy serwer DF dla naszego projektu automatyzacji (dispatcher, component iterface, a bunch of components, DF language, DF compiler, UI). Jest napisany w C++ i działa na kilku systemach uniksopodobnych (Linux x86, MIPS, avr32 itp., Mac OSX). Brakuje mu kilku funkcji, np. wyrafinowanej kontroli przepływu, skomplikowanej kontroli wątku( jest do niej tylko niezbyt zaawansowany komponent), więc jest to po prostu prototyp, nawet działa. Obecnie pracujemy nad w pełni funkcjonalnym serwerem. Wiele nauczyliśmy się podczas wdrażania i użytkowania prototypu.

Pewnego dnia zrobimy edytor wizualny.

2. Jaka jest twoja opinia o FBP?

2.1. Przede wszystkim programowanie dataflow jest najlepsza zabawa

Kiedy poznałem programowanie dataflow, czułem się jak 20 lat temu, kiedy poznałem programowanie po raz pierwszy. Altough, programowanie DF różni się od programowanie proceduralne/OOP, to tylko rodzaj programowania. Jest wiele rzeczy do odkrycia, nawet te proste! To bardzo zabawne, gdy jako doświadczony programista napotkałeś problem DF, który jest bardzo-bardzo podstawową rzeczą, ale wcześniej był dla ciebie zupełnie nieznany. Tak więc, jeśli wskoczysz do programowania DF, poczujesz się jak początkujący programista, który po raz pierwszy spotkał się z" cyklem " lub "warunkiem".

2.2. Może być używany tylko dla określonych architektur

2.3. Architektura przepływu danych jest optymalna dla niektórych problemów

Przykład: Czy wiesz, że make jest systemem DF? Try make-j (patrz man, do czego służy-j). Jeśli masz wielordzeniową maszynę, skompiluj swój projekt z i bez-j i porównaj czasy.

2.4. Optymalny podział problemu

Jeśli piszesz program, często dzielisz problem na mniejsze problemy podrzędne. Istnieją zwykle punkty podziału dla znanych pod-problemów, których nie trzeba implementować, wystarczy użyć istniejących rozwiązań, takich jak SQL dla DB, lub OpenGL dla grafiki / animacji, itp.

DF architecture dzieli twoje problem bardzo ciekawy sposób:

W 2007 roku, po raz pierwszy w historii, dataflow zaprezentował architekturę dataflow Framework, która została zaprojektowana w oparciu o architekturę dataflow Framework.]} Komponenty: programista tworzy komponenty; komponenty są prostymi, dobrze oddzielonymi jednostkami-łatwo je tworzyć; [54]}
• konfiguracja: Alias programowanie dataflow: konfigurator umieszcza Wykres dataflow (program) razem przy użyciu komponentów dostarczonych przez programistę.

Jeśli twój zestaw komponentów jest dobrze zaprojektowany konfigurator potrafi zbudować taki system, o którym programista nawet nie marzył. Konfigurator może zaimplementować nowe funkcje bez przeszkadzania programiście. Klienci są zadowoleni, ponieważ mają spersonalizowane rozwiązanie. Producent oprogramowania jest również zadowolony, ponieważ nie musi utrzymywać kilku specyficznych dla klienta gałęzi oprogramowania, tylko konfiguracje dostosowane do klienta.

2.5. Speed

Jeśli system jest zbudowany na natywnym komponenty, program DF jest szybki. Jedyną stratą czasu jest wysyłanie wiadomości między komponentami w porównaniu do prostego programu OOP, jest to również minimalne.

3. Czy FBP ma przyszłość?

Głównym powodem jest to, że może rozwiązać ogromne problemy wieloprocesorowe bez wprowadzania zupełnie nowych dziwnych architektur oprogramowania, dziwnych języków. Programowanie Dataflow jest łatwe i mam na myśli zarówno programowanie komponentów, jak i konfigurację dataflow budynek. (Nawet dataflow Framework writing nie jest nauką rakietową.)

Byłbym szczęśliwy, gdyby systemy natywne się rozprzestrzeniły, z otwartymi drzwiami do tworzenia niestandardowych komponentów. Również powinien istnieć standardowy język DF, co oznacza, że może być używany z niezależne od platformy edytory wizualne i kilka serwerów DF.

Muszę się nie zgodzić z komentarzem, że FBP jest tylko sposobem implementacji FSMs: myślę, że FSMs są schludne i wierzę, że mają określoną rolę w budowaniu aplikacji, ale podstawowa koncepcja FBP polega na wielu procesach składowych uruchomionych asynchronicznie , komunikujących się za pomocą strumieni fragmentów danych, które przebiegają przez to, co obecnie nazywa się ograniczonymi buforami. Tak, zdecydowanie FSMs są jednym ze sposobów budowania procesów komponentowych, a w rzeczywistości jest cały rozdział w moim książka o FBP poświęcona tej idei, a związana z nią z PDA (1) - http://www.jpaulmorrison.com/fbp/compil.htm - ale moim zdaniem FSM implementujący nietrywialną sieć FBP byłby niemożliwie skomplikowany. Jako przykład przedstawiono diagram w jest to około 1/3 pojedynczego zadania wsadowego działającego na komputerze mainframe. Każdy z tych bloków działa asynchronicznie ze wszystkimi innymi. Nawiasem mówiąc, byłbym bardzo zainteresowany, aby usłyszeć więcej odpowiedzi na pytania w pierwszy post!

1: http://en.wikipedia.org/wiki/Pushdown_automaton automaty Push-down

Ilekroć słyszę termin flow based programming, myślę o LabView, koncepcyjnie. Procesy komponentowe Ie, które są scheduling jest napędzany przede wszystkim przez zmianę jego danych wejściowych. To naprawdę jest programowanie lego w tym sensie, że platforma labview została użyta do najnowszego zbioru produktów mindstorm. Nie zgadzam się jednak z tym, że jest to mniej użyteczny model programowania.

Dla systemów przemysłowych, które zazwyczaj obejmują gromadzenie danych, sterowanie i automatyzację, pasuje bardzo dobrze. Co to jest system kontroli, jeśli nie DANE w przekształcone do danych out? Czyli jaki komponent w twoim schemacie sterowania nie wolałbyś reprezentować jako czarna skrzynka w szerszym ujęciu, gdybyś mógł to zrobić. Aby osiągnąć ten poziom przejrzystości architektonicznej przy użyciu innych metod, być może będziesz musiał narysować diagram klasy data domain, następnie relację klasy run time domain problem, a następnie diagram przypadków użycia i przerzucać między nimi. Dzięki systemom napędzanym przepływem masz luksus bycia w stanie zwijać wiele z tych informacji na tyle dokładnie, że można realistycznie zaprojektować system wizualnie po zbudowaniu i zdefiniowaniu komponentów.

Jedno pytanie, którego nigdy nie musiałem zadawać, patrząc na aplikację napisaną w labview, to " jaki fragment kodu ustawia tę wartość?", ponieważ było to nieodłączne i łatwe do prześledzenia wstecz z danych, a także błędy, takie jak wiele nienadzorowanych pisarzy, były niemożliwe do stworzenia przez pomyłkę.

Gdyby tylko to było prawda o kodzie napisanym w bardziej typowo proceduralny sposób!

1) buduję mały framework FBP dla projektu wykrywania anomalii i okazuje się, że był to świetny pomysł.

Możesz również rzucić okiem na niektóre filmy KNIME , które dają dobre wyobrażenie o tym, jak wygląda Framework oparty na przepływie, gdy Framework jest tworzony przez świetny zespół. Co prawda jest on oparty na partiach i nie jest stworzony do pracy ciągłej.

Zdecydowanie najlepszym przykładem programowania opartego na przepływach jest jednak Unix pipes , który jest jednym z najstarszy, najczęściej pomijany framework FBP. Myślę, że nie muszę mówić o mocy rur nix...

2) FBP jest bardzo potężnym narzędziem dla dużego zestawu problemów. Równoległość wewnętrzna jest wielką zaletą, a każda struktura FBP może być całkowicie przezroczysta w sieci za pomocą modułów adapterów. Inteligentne struktury są również odporne na błędy i mogą dynamicznie przeładowywać uszkodzone moduły w razie potrzeby. Prostota koncepcyjna pozwala także na czystszą komunikację z wszyscy zaangażowani w projekt i dużo czystszy kod.

3) absolutnie! Rury są tutaj, aby pozostać i są jedną z najpotężniejszych cech Uniksa. W przeciwieństwie do programu statycznego moc FBP jest bardzo duża i trywializuje zmiany, do tego stopnia, że niektóre frameworki mogą być ponownie skonfigurowane podczas pracy bez specjalnych środków.

FBP FTW! ;-)

W rozwoju motoryzacji mają język agnostyczny protokół komunikacyjny, który jest częścią najbardziej specyfikacji (Media Oriented Systems Transport), został zaprojektowany do komunikacji między komponentami przez sieć lub w obrębie tego samego urządzenia. Systemy zwykle mają zarówno rzeczywistą, jak i wizualizowaną magistralę komunikatów - dlatego efektywnie masz formę programowania opartego na przepływach.

To właśnie sprawiło, że kilka lat temu żarówka zapaliła się i przywiozła mnie tutaj. To naprawdę jest fantastyczny sposób pracy i dużo więcej zabawy niż konwencjonalne programowanie. Katalog wiadomości stanowi centralną specyfikację i punkt odniesienia. Działa dobrze zarówno dla programistów, jak i kierownictwa. tzn. Kierownictwo jest w stanie przeglądać katalog wiadomości zamiast szukać źródła.

Dzięki zintegrowanemu rejestrowaniu również odwoływanie się do katalogu w celu uzyskania zrozumiałej analizy rzeczy mogą stać się naprawdę produktywne. Mam prawdziwe doświadczenie w opracowywaniu produktów komercyjnych w ten sposób. Jestem zainteresowane pójściem dalej, szczególnie w odniesieniu do narzędzi i IDE. Niestety myślę, że wiele osób z sektora motoryzacyjnego nie dostrzegło tego, jak wspaniałe jest to rozwiązanie i nie udało im się na nim oprzeć. Są teraz rozproszeni przez inne Mody i nie zdali sobie sprawy, że jest znacznie więcej do większość rozwoju niż fizyczny autobus.

Używałem Spring Web Flow szeroko w aplikacjach internetowych Java do modelowania (zazwyczaj) procesów aplikacji, które wydają się być skomplikowanymi sprawami przypominającymi kreatora z dużą ilością logiki warunkowej, które strony mają być wyświetlane. Jest niesamowicie potężny. Nowy produkt został dodany i udało mi się ponownie przekształcić istniejące elementy w zupełnie nowy proces aplikacji w godzinę lub dwie (z dodaniem kilku nowych widoków/Stanów).

Przyjrzałem się również używaniu OS Workflow do modelowania procesów biznesowych, ale ten projekt został z różnych powodów zablokowany.

W świecie Microsoft masz Windows Workflow Foundation ("WWF"), która staje się coraz bardziej popularna, szczególnie w połączeniu z Sharepoint.

FBP jest tylko sposobem implementacji skończonej maszyny stanowej . To nic nowego.

Zdaję sobie sprawę, że to nie do końca to samo, ale ten model jest używany od lat w programowaniu PLC. ISO nazywa to sekwencyjny SCHEMAT BLOKOWY, ale wiele osób nazywa go Grafcet po popularnej implementacji. Oferuje przetwarzanie równoległe i definiuje przejścia między Stanami.

Jest obecnie używany w świecie Business Intelligence do mashup i przetwarzania danych. Etapy przetwarzania danych, takie jak ETL, zapytania, dołączanie i tworzenie raportów, mogą być wykonywane przez użytkownika końcowego. Jestem programistą na otwartym systemie - ComposableAnalytics.com W CA aplikacje oparte na przepływach mogą być współdzielone i uruchamiane za pośrednictwem przeglądarki.

Do tego służą serie MQ, MSMQ i JMS.

Jest to podstawa Web Services i wdrożenia Enterprise Service Bus.

Produkty takie jak TIBCO i Sun JCAPS są w zasadzie oparte na przepływie bez użycia tego szczególnego buzz-word.

Większość pracy aplikacji odbywa się za pomocą małych modułów, które przesyłają wiadomości przez sieć przetwarzania.