Поточно-ориентированное программирование

Я действительно должен не согласиться с комментарием о FBP, являющемся только что средством реализации FSMs: Я думаю, что FSMs аккуратны, и я полагаю, что у них есть определенная роль в создавании приложений, но базовое понятие FBP имеет несколько процессов компонента, работающих асинхронно , связываясь посредством потоков блоков данных, которые натыкаются на то, что теперь называют ограниченными буферами. Да, определенно FSMs являются одним способом процессов составной части здания, и на самом деле существует целая глава в моей книге по FBP, посвященному этой идее и связанному из PDAs ( 1 ) - http://www.jpaulmorrison.com/fbp/compil.htm - но по-моему FSM реализация нетривиальной сети FBP был бы невозможно сложен. Как пример схема, показанная в , о 1/3 единственная пакетное задание, работающее на мэйнфрейме. Каждые из тех блоков выполняют асинхронно со всем другие. Между прочим, мне очень было бы интересно к слушанию большего количества ответов на вопросы в первом сообщении!

1 : http://en.wikipedia.org/wiki/Pushdown_automaton Автоматы с магазинной памятью

Каждый раз, когда я слышу термин поточно-ориентированное программирование, я думаю о LabView, концептуально. Т.е. процессы компонента, кто планирует, управляются, прежде всего, изменением в его входных данных. Это действительно - программирование lego в том смысле, что labview платформа использовалась для последней обрезки mindstorm продуктов. Однако я не соглашаюсь, что это делает это менее полезной моделью программирования.

Для промышленных систем, которые обычно включают сбор данных, управление и автоматизацию, это соответствует очень хорошо. Какова какая-либо система управления если не данные в преобразованном к данным? Т.е. что компонент в Вашей схеме управления был бы Вы не предпочитать представлять как черный квадрат в большем изображении, если Вы могли бы сделать так. Для достижения того уровня архитектурной ясности с помощью других методологий, Вам, возможно, придется нарисовать диаграмму классов области данных, затем отношения класса среды выполнения проблемной области, тогда к тому же схема варианта использования, и зеркально отразить назад и вперед между ними. С потоком управляемые системы у Вас есть роскошь способности свернуть большую эту информацию вместе достаточно точно, что можно реалистично разработать систему визуально, как только компоненты являются сборкой и определенный.

Один вопрос я никогда не должен был спрашивать, когда рассмотрение приложения, записанного в labview, "Что часть кодового набора это значение?", поскольку это было свойственно и легко проследить назад от данных и также путает как несколько untintended писателей, были невозможны создать по ошибке.

, Если только, который был верен для кода, написанного более обычно процедурным способом!

Я использовал веб-Поток Spring экстенсивно в веб-приложениях Java для моделирования (обычно) процессов приложения, которые имеют тенденцию быть сложными подобными мастеру делами с большой условной логикой относительно который страницы отобразиться. Его невероятно мощный. Новый продукт был добавлен, и мне удалось повторно сократить существующие части в абсолютно новый процесс приложения через час или два (с добавлением нескольких новых представлений/состояний).

я также изучил использование Рабочий процесс ОС для моделирования бизнес-процессов, но что проект стал консервированным по различным причинам.

В мире Microsoft Вы имеете Windows Workflow Foundation ("Всемирный фонд дикой природы"), который становится более популярным, особенно в сочетании с Sharepoint.

FBP является просто средством реализации конечный автомат . Это не ничто нового.

Я понимаю, что это не точно то же самое, но эта модель использовалась в течение многих лет в программировании PLC. ISO называет его Последовательной Блок-схемой, но многие люди называют его Grafcet после популярной реализации. Это предлагает параллельную обработку и определяет переходы между состояниями.

Это - то, для чего Ряд MQ, MSMQ и JMS.

Это - краеугольный камень реализаций Сервисной шины предприятия и веб-сервисов.

продукты как TIBCO и JCAPS Sun в основном основаны на потоке, не используя это конкретное модное словечко.

большая часть работы приложения сделана с маленькими модулями, которые передают сообщения через сеть обработки.

1. Использовали ли вы FBP для реального проекта?

Мы разработали и внедрили DF-сервер для нашего проекта автоматизации (диспетчер, итерфейс компонентов, куча компонентов, DF-язык, DF-компилятор, UI). Он написан на голом C++ и работает на нескольких Unix-подобных системах (Linux x86, MIPS, avr32 и т.д., Mac OSX). Ему не хватает нескольких функций, например, сложного управления потоками, сложного управления потоками (для этого есть только не слишком продвинутый компонент), так что это всего лишь прототип, но даже он работает. Сейчас мы работаем над полнофункциональным сервером. Мы многому научились во время реализации и использования прототипа.

Кроме того, когда-нибудь мы сделаем визуальный редактор.

2. Каково ваше мнение о FBP?

2.1. Прежде всего, программирование потока данных - это абсолютное удовольствие

Когда я познакомился с программированием потока данных, я почувствовал себя как 20 лет назад, когда я впервые познакомился с программированием. Хотя программирование DF отличается от процедурного/ОП программирования, это просто вид программирования. Есть много вещей, которые нужно открыть для себя, даже таких простых! Очень забавно, когда, будучи опытным программистом, вы встречаетесь с проблемой DF, которая является очень-очень базовой, но раньше была вам совершенно неизвестна. Поэтому, если вы начнете программировать DF, вы будете чувствовать себя как программист-новичок, который впервые встретил "цикл" или "условие".

2.2. Его можно использовать только для определенных архитектур

Это просто молоток, которым забивают гвозди. DF не подходит для пользовательских интерфейсов, веб-сервера и т.д.

2.3. Архитектура потока данных оптимальна для некоторых задач

Фреймворк потока данных может делать волшебные вещи. Он может паралеллировать процедуры, которые изначально не предназначены для паралеллирования. Компоненты являются однопоточными, но когда они организованы в граф DF, они становятся многопоточными.

Пример: знаете ли вы, что make - это DF-система? Попробуйте make -j (см. в man, для чего используется -j). Если у вас многоядерная машина, скомпилируйте ваш проект с -j и без него и сравните время.

2.4. Оптимальное разбиение проблемы

Если вы пишете программу, вы часто разбиваете проблему на более мелкие подпроблемы. Для известных подпроблем существуют обычные точки разделения, которые не нужно реализовывать, просто используйте существующие решения, как SQL для БД, или OpenGL для графики/анимации и т.д.

Архитектура DF разделяет вашу проблему очень интересным способом:

• dataflow framework, который предоставляет архитектуру (просто используйте существующую),
• компоненты: программист создает компоненты; компоненты являются простыми, хорошо разделенными единицами - легко создавать компоненты;
• конфигурация: она же программирование потока данных: конфигуратор собирает граф потока данных (программу) вместе, используя компоненты, предоставленные программистом.

Если ваш набор компонентов хорошо продуман, конфигуратор может построить такую систему, которая программисту даже не снилась. Конфигуратор может реализовать новые возможности, не беспокоя программиста. Клиенты счастливы, потому что у них есть индивидуальное решение. Производитель программного обеспечения тоже доволен, потому что ему/ей не нужно поддерживать несколько ветвей программного обеспечения для конкретных клиентов, только конфигурации для конкретных клиентов.

2.5. Скорость

Если система построена на родных компонентах, то программа DF работает быстро. Единственная потеря времени - это диспетчеризация сообщений между компонентами, по сравнению с простой ООП программой, она также минимальна.

3. Есть ли у FBP будущее?

Да, конечно.

Главная причина в том, что он может решить проблемы массовой многопроцессорной обработки без внедрения совершенно новых странных программных архитектур, странных языков. Программирование потока данных легко, и я имею в виду оба направления: программирование компонентов и построение конфигурации потока данных. (Даже написание фреймворка потока данных - это не ракетостроение.)

Кроме того, это очень экономично. Если у вас есть хороший набор компонентов, вам нужно только собрать кирпичики лего вместе. Программу DF легко поддерживать. Для создания конфигурации DF не требуется опытный программист, только системный интегратор.

Я был бы счастлив, если бы распространились родные системы, с открытыми дверями для создания пользовательских компонентов. Также должен быть стандартный язык DF, что означает, что его можно использовать с независимыми от платформы визуальными редакторами и несколькими серверами DF.