Программирование на основе потоков - Википедия - Flow-based programming

Парадигмы программирования

В компьютерное программирование, потоковое программирование (FBP) это парадигма программирования что определяет Приложения как сети «черного ящика» процессы, которые обмениваются данными через предопределенные подключения с помощью передача сообщений, где указаны соединения внешне к процессам. Эти процессы черного ящика можно бесконечно повторно подключать для создания различных приложений без необходимости внутреннего изменения. Таким образом, FBP естественно компонентно-ориентированный.

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

Вступление

Программирование на основе потоков определяет приложения, используя метафору «фабрики данных». Он рассматривает приложение не как отдельный последовательный процесс, который начинается в определенный момент времени, а затем выполняет одно действие за раз, пока не будет завершено, а как сеть асинхронных процессов, взаимодействующих посредством потоки структурных блоков данных, называемых «информационными пакетами» (IP). В этом представлении основное внимание уделяется данным приложения и преобразованиям, применяемым к ним для получения желаемых результатов. Сеть определяется внешне по отношению к процессам в виде списка соединений, который интерпретируется программным обеспечением, обычно называемым «планировщиком».

Процессы общаются посредством соединений с фиксированной пропускной способностью. Соединение присоединяется к процессу с помощью порт, имя которого согласовано между кодом процесса и определением сети. Один и тот же фрагмент кода может выполнять несколько процессов. В любой момент времени данный IP-адрес может принадлежать только одному процессу или находиться в пути между двумя процессами. Порты может быть простым или массивным, например, для входного порта компонента Collate, описанного ниже. Это сочетание портов с асинхронными процессами, которое позволяет поддерживать многие длительные примитивные функции обработки данных, такие как сортировка, слияние, суммирование и т. Д., В виде программного обеспечения. черные ящики.

Поскольку процессы FBP могут продолжать выполняться до тех пор, пока у них есть данные для работы и место для вывода их результатов, приложения FBP обычно работают за меньшее время, чем обычные программы, и оптимально используют все процессоры на машине без специального программирования. для достижения этой цели.[1]

Определение сети обычно схематично и преобразуется в список соединений на каком-либо языке нижнего уровня или в нотации. FBP часто бывает язык визуального программирования на этом уровне. Более сложные определения сетей имеют иерархическую структуру, состоящую из подсетей с «липкими» соединениями. Многие другие потоковые языки / среды выполнения построены на более традиционных языках программирования, наиболее известные из которых:[нужна цитата ] пример RaftLib который использует операторы C ++, подобные iostream, для определения потокового графа.

FBP имеет много общего с Линда[2] язык в том, что это, в Гелернтер и терминология Карриеро, «координационный язык»:[3] он по существу не зависит от языка. Действительно, при наличии планировщика, написанного на достаточно низкоуровневом языке, компоненты, написанные на разных языках, могут быть связаны вместе в единую сеть. Таким образом, FBP поддается концепции предметно-ориентированные языки или «мини-языки».

FBP демонстрирует «привязку данных», описанную в статье о связь как самый слабый вид связи между компонентами. Концепция чего-либо Слабая связь в свою очередь связано с сервис-ориентированные архитектуры, и FBP соответствует ряду критериев такой архитектуры, хотя и на более детальном уровне, чем большинство примеров этой архитектуры.

FBP продвигает высокоуровневый функциональный стиль спецификаций, который упрощает рассуждения о поведении системы. Примером этого является распределенный поток данных модель для конструктивного определения и анализа семантики распределенных многосторонних протоколов.

История

Программирование на основе потоков было изобретено Дж. Полом Моррисоном в начале 1970-х годов и первоначально реализовано в программном обеспечении для канадского банка.[4] FBP с самого начала находился под сильным влиянием некоторых языков моделирования IBM того периода, в частности GPSS, но его корни уходят в Конвей основополагающий документ о том, что он назвал сопрограммы.[5]

За прошедшие годы FBP претерпела ряд изменений названия: исходная реализация называлась AMPS (Advanced Modular Processing System). Одно крупное приложение в Канаде было запущено в 1975 году, а по состоянию на 2013 год оно находилось в непрерывном производственном использовании, работало ежедневно в течение почти 40 лет. Поскольку IBM посчитала идеи, лежащие в основе FBP, «слишком похожими на закон природы», чтобы их можно было запатентовать, они вместо этого поместили основные концепции FBP в общественное достояние с помощью Бюллетень технического раскрытия информации, "Модульная система программирования с чередованием задач, реагирующая на данные",[6] в 1971 г.[4] Статья, описывающая его концепции и опыт использования, была опубликована в 1978 году в IBM Research IBM Systems Journal под названием DSLM.[7] Вторая реализация была осуществлена ​​как совместный проект IBM Canada и IBM Japan под названием «Data Flow Development Manager» (DFDM) и недолго продавалась в Японии в конце 80-х годов под названием «Data Flow Programming Manager».

Обычно в IBM эти концепции назывались «потоком данных», но этот термин считался слишком общим, и в итоге было принято название «программирование на основе потоков».

С начала 80-х по 1993 г. Дж. Пол Моррисон и архитектор IBM Уэйн Стивенс усовершенствовал и продвинул концепции, лежащие в основе FBP. Стивенс написал несколько статей, описывающих и поддерживающих концепцию FBP, и включил материал о ней в несколько своих книг.[8][9][неосновной источник необходим ][10][неосновной источник необходим ]. В 1994 году Моррисон опубликовал книгу, описывающую FBP и предоставляющую эмпирические доказательства того, что FBP приводит к сокращению времени разработки.[11]

Концепции

На следующей диаграмме показаны основные элементы диаграммы FBP (кроме информационных пакетов). Такая диаграмма может быть преобразована непосредственно в список соединений, который затем может быть выполнен соответствующим механизмом (программным или аппаратным).

Простая диаграмма FBP

A, B и C - это процессы, выполняющие компоненты кода. O1, O2 и два IN - это порты, соединяющие соединения M и N с соответствующими процессами. Процессам B и C разрешено выполнять один и тот же код, поэтому каждый процесс должен иметь свой собственный набор рабочей памяти, блоков управления и т. Д. Независимо от того, используют ли они общий код, B и C могут использовать один и тот же порт. имена, поскольку имена портов имеют значение только в компонентах, которые на них ссылаются (и, конечно, на уровне сети).

M и N - это то, что часто называют "ограниченные буферы ", и имеют фиксированную емкость с точки зрения количества IP-адресов, которые они могут удерживать в любой момент времени.

Концепция чего-либо порты Это то, что позволяет использовать один и тот же компонент в более чем одном месте сети. В сочетании с возможностью параметризации, называемой пакетами исходной информации (IIP), порты предоставляют FBP возможность повторного использования компонентов, что делает FBP удобным компонентный архитектура. Таким образом, FBP демонстрирует то, что Рауль де Кампо и Нейт Эдвардс из IBM Research назвали настраиваемая модульность.

Информационные пакеты или IP-адреса выделяются в так называемом «пространстве IP» (точно так же, как кортежи Линды выделяются в «пространстве кортежей») и имеют четко определенный срок жизни до тех пор, пока они не будут удалены и их пространство не будет освобождено - в FBP это должно быть явным действием со стороны процесса-владельца. IP-адреса, перемещающиеся по данному соединению (на самом деле, это их "дескрипторы"), составляют "поток", который генерируется и потребляется асинхронно - таким образом, эта концепция имеет сходство с ленивые минусы концепция, описанная в статье Friedman and Wise 1976 г.[12]

IP-адреса обычно представляют собой структурированные блоки данных - однако некоторые IP-адреса могут не содержать никаких реальных данных, а используются просто как сигналы. Примером этого являются «IP-адреса в скобках», которые можно использовать для группировки IP-адресов данных в последовательные шаблоны в потоке, называемые «субпотоки». Подпотоки, в свою очередь, могут быть вложенными. IP-адреса также могут быть объединены в цепочки для формирования «IP-деревьев», которые перемещаются по сети как отдельные объекты.

Описанная выше система связей и процессов может быть «разветвлена» до любого размера. Во время разработки приложения процессы мониторинга могут быть добавлены между парами процессов, процессы могут быть «разбиты» на подсети или моделирование процессов может быть заменено реальной логикой процесса. Следовательно, FBP поддается быстрое прототипирование.

Это действительно сборочная линия образ обработки данных: IP-адреса, перемещающиеся через сеть процессов, можно рассматривать как виджеты, перемещающиеся от станции к станции на конвейере. «Машины» можно легко переподключить, вывести в ремонт, заменить и так далее. Как ни странно, это изображение очень похоже на изображение единичное записывающее оборудование это использовалось для обработки данных до появления компьютеров, за исключением того, что колоды карт приходилось переносить вручную с одной машины на другую.

Реализации FBP могут быть без вытеснения или вытеснения - более ранние реализации, как правило, были без вытеснения (мэйнфреймы и язык C), тогда как последняя реализация Java (см. Ниже) использует класс Java Thread и является вытесняющей.

Примеры

"Проблема с Telegram"

Компоненты FBP часто образуют дополнительные пары. В этом примере используются две такие пары. Описанная проблема кажется очень простой, если ее описать словами, но на самом деле ее удивительно трудно решить, используя обычную процедурную логику. Задача, названная «Проблема Telegram», первоначально описанная Питер Наур, заключается в написании программы, которая принимает строки текста и генерирует выходные строки, содержащие как можно больше слов, где количество символов в каждой строке не превышает определенной длины. Слова не могут быть разделены, и мы предполагаем, что ни одно слово не длиннее, чем размер строк вывода. Это аналогично проблеме переноса слов в текстовых редакторах.[13]

В традиционной логике программист быстро обнаруживает, что ни входные, ни выходные структуры не могут использоваться для управления иерархией вызовов поток управления. В FBP, с другой стороны, само описание проблемы предлагает решение:

  • "слова" явно упоминаются в описании проблемы, поэтому для разработчика разумно рассматривать слова как информационные пакеты (IP).
  • в FBP нет единой иерархии вызовов, поэтому программист не склонен заставлять подшаблон решения быть верхним уровнем.

Вот наиболее естественное решение в FBP (в FBP нет единого «правильного» решения, но оно кажется естественным):

Питер Наур "проблема Telegram"

где DC и RC обозначают "DeCompose" и "ReCompose" соответственно.

Как упоминалось выше, пакеты исходной информации (IIP) могут использоваться для указания параметрической информации, такой как желаемая длина выходной записи (требуемая двумя крайними правыми компонентами) или имена файлов. IIP - это блоки данных, связанные с портом в определении сети, которые становятся «обычными» IP-адресами, когда для соответствующего порта выдается «получение».

Пакетное обновление

Этот тип программы включает передачу файла «деталей» (изменений, добавлений и удалений) в «главный файл» и создание (по крайней мере) обновленного главного файла и одного или нескольких отчетов. Программы обновления, как правило, довольно сложно кодировать с использованием синхронного процедурного кода, так как два (иногда больше) входных потока должны быть синхронизированы, даже если могут быть мастера без соответствующих деталей, или наоборот.

Каноническая структура "пакетного обновления"

В FBP - компонент многократного использования (Collate), основанный на единичная запись Идея Collator значительно упрощает написание этого типа приложения, поскольку Collate объединяет два потока и вставляет IP-адреса в скобках для обозначения уровней группировки, что значительно упрощает логику нисходящего потока. Предположим, что один поток (в данном случае «мастера») состоит из IP-адресов со значениями ключей 1, 2 и 3, а IP-адреса второго потока («подробности») имеют значения ключей 11, 12, 21, 31, 32, 33. и 41, где первая цифра соответствует значениям главного ключа. Используя символы скобок для представления IP-адресов в скобках, выходной поток с сортировкой будет выглядеть следующим образом:

(m1 d11 d12) (m2 d21) (m3 d31 d32 d33) (d41)

Так как мастера со значением 4 не было, последняя группа состоит из одной детали (плюс скобки).

Структуру указанного потока можно кратко описать с помощью BNF -подобные обозначения, такие как

{([м] д *)} *

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

Процессы мультиплексирования

Программирование на основе потоков естественным образом поддерживает мультиплексирование процессов. Поскольку компоненты доступны только для чтения, любое количество экземпляров данного компонента («процессов») может выполняться асинхронно друг с другом.

Пример мультиплексирования

Когда в компьютерах обычно был один процессор, это было полезно, когда выполнялось много операций ввода-вывода; Теперь, когда машины обычно имеют несколько процессоров, это становится полезным, когда процессы также интенсивно загружают процессор. На схеме в этом разделе показан один процесс «Load Balancer», распределяющий данные между 3 процессами, обозначенными S1, S2 и S3, соответственно, которые являются экземплярами одного компонента, которые, в свою очередь, передаются в один процесс в порядке очереди. первому обслуживающему "основанию".

Простая интерактивная сеть

Схема общего интерактивного приложения

В этой общей схеме запросы (транзакции), поступающие от пользователей, входят в диаграмму в верхнем левом углу, а ответы возвращаются в нижнем левом углу. "Серверные части" (справа) взаимодействуют с системами на других сайтах, например с помощью CORBA, MQSeries и т. д. Перекрестные соединения представляют собой запросы, которые не нужно отправлять на серверы, или запросы, которые должны проходить через сеть более одного раза, прежде чем будут возвращены пользователю.

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

Приведенная выше диаграмма является схематической в ​​том смысле, что окончательное приложение может содержать гораздо больше процессов: процессы могут быть вставлены между другими процессами для управления кешами, отображения трафика соединения, контроля пропускной способности и т. Д. Также блоки на диаграмме могут представлять «подсети» - небольшие сети с одним или несколькими открытыми соединениями.

Сравнение с другими парадигмами и методологиями

Структурированное программирование Джексона (JSP) и разработка систем Джексона (JSD)

Основные статьи: Структурированное программирование Джексона и Разработка системы Джексона

Эта методология предполагает, что программа должна быть структурирована как единая процедурная иерархия подпрограмм. Его отправной точкой является описание приложения как набора «основных строк» ​​на основе структур входных и выходных данных. Затем одна из этих «главных линий» выбирается для управления всей программой, а остальные требуется «инвертировать», чтобы превратить их в подпрограммы (отсюда и название «инверсия Джексона»). Иногда это приводит к так называемому «конфликту», когда требуется разбить программу на несколько программ или сопрограмм. При использовании FBP этот процесс инверсии не требуется, поскольку каждый компонент FBP может рассматриваться как отдельная «основная линия».

FBP и JSP разделяют концепцию обработки программы (или некоторых компонентов) как парсер входного потока.

В более поздних работах Джексона Разработка системы Джексона (JSD) идеи получили дальнейшее развитие.[14][15]

В JSD дизайн сохраняется как дизайн сети до финальной стадии реализации. Затем модель преобразуется в набор последовательных процессов по количеству доступных процессоров. Джексон обсуждает возможность прямого выполнения сетевой модели, существовавшей до этого шага, в разделе 1.3 своей книги (курсив добавлен):

Спецификация, созданная в конце шага System Timing, в принципе может быть выполнена напрямую. Необходимая среда будет содержать процессор для каждого процесса, устройство, эквивалентное неограниченному буферу для каждого потока данных, и некоторые устройства ввода и вывода, через которые система подключена к реальному миру. Такая среда, конечно, может быть обеспечена подходящим программным обеспечением, работающим на достаточно мощной машине. Иногда такое прямое выполнение спецификации возможно и даже может быть разумным выбором.[15]

М. А. Джексон признал FBP подходом, который следует его методу «разложения программы на последовательные процессы, взаимодействующие с помощью механизма, подобного сопрограммам».[16]

Аппликативное программирование

Основная статья: Аппликативный язык программирования

W.B. Акерман определяет прикладной язык как язык, который выполняет всю свою обработку с помощью операторов, применяемых к значениям.[17] Самым ранним известным прикладным языком был LISP.

Компонент FBP можно рассматривать как функцию, преобразующую входной поток (потоки) в выходной поток (потоки). Затем эти функции объединяются для выполнения более сложных преобразований, как показано здесь:

Две функции кормят одну

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

c = G (F (a), F (b));

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

Тогда возникает вопрос, могут ли сами компоненты FBP быть выражены с использованием функциональной нотации. W.H. Бердж показал, как выражения потока могут быть разработаны с использованием рекурсивного, прикладного стиля программирования, но эта работа была в терминах (потоков) атомарных значений.[18] В FBP необходимо иметь возможность описывать и обрабатывать блоки структурированных данных (IP-адреса FBP).

Более того, большинство прикладных систем предполагают, что все данные доступны в памяти одновременно, тогда как приложения FBP должны иметь возможность обрабатывать длительные потоки данных, по-прежнему используя ограниченные ресурсы. Фридман и Уайз предложили способ сделать это, добавив концепцию "ленивые минусы" к работе Берджа. Это устранило требование, чтобы оба аргумента «против» были доступны в один и тот же момент времени. «Lazy cons» фактически не создает поток, пока не будут реализованы оба его аргумента - до этого он просто записывает «обещание» сделать это. Это позволяет динамически реализовывать поток спереди, но с нереализованным сервером. Конец потока остается нереализованным до самого конца процесса, в то время как начало представляет собой постоянно растущую последовательность элементов.

Линда

Основная статья: Линда

Многие концепции FBP, кажется, были независимо открыты в разных системах на протяжении многих лет. Упомянутая выше Линда - одна из таких. Разница между этими двумя методами проиллюстрирована техникой балансировки нагрузки «школы пираний» Линды - в FBP для этого требуется дополнительный компонент «балансировщик нагрузки», который направляет запросы к компоненту в списке, который имеет наименьшее количество IP-адресов, ожидающих быть обработанным. Очевидно, что FBP и Linda тесно связаны, и одно можно легко использовать для имитации другого.

Объектно-ориентированного программирования

Основная статья: Объектно-ориентированного программирования

Объект в ООП можно описать как полуавтономную единицу, включающую как информацию, так и поведение. Объекты общаются посредством «вызовов методов», которые по сути являются вызовами подпрограмм, выполняемыми косвенно через класс, к которому принадлежит принимающий объект. Доступ к внутренним данным объекта можно получить только с помощью вызовов методов, так что это форма скрытие информации или «инкапсуляция». Однако инкапсуляция предшествует ООП - Давид Парнас написал об этом одну из основополагающих статей в начале 70-х[19] - и является основным понятием в вычислениях. Инкапсуляция - это самая суть компонента FBP, который можно рассматривать как черный ящик, выполняя некоторое преобразование входных данных в выходные данные. В FBP часть спецификации компонента - это форматы данных и структуры потоков, которые он может принимать и которые он будет генерировать. Это представляет собой форму дизайн по контракту. Кроме того, данные в IP могут быть доступны напрямую только процессу, владеющему в данный момент. Инкапсуляция также может быть реализована на сетевом уровне, если внешние процессы защищают внутренние.

В статье К. Эллиса и С. Гиббса проводится различие между активные объекты и пассивные объекты.[20] Пассивные объекты содержат информацию и поведение, как указано выше, но они не могут определять время этого поведения. С другой стороны, активные объекты могут это сделать. В своей статье Эллис и Гиббс утверждают, что активные объекты имеют гораздо больший потенциал для развития обслуживаемых систем, чем пассивные объекты. Приложение FBP можно рассматривать как комбинацию этих двух типов объектов, где процессы FBP будут соответствовать активным объектам, а IP-адреса будут соответствовать пассивным объектам.

Актерская модель

Основная статья: Актерская модель

FBP считает Карл Хьюитт Actor как асинхронный процесс с 2 портами: один для входных сообщений и один для сигналов управления. Управляющий сигнал испускается самим субъектом после каждого раунда выполнения. Цель этого сигнала - избежать параллельного выполнения тела актера и, таким образом, разрешить доступ к полям объекта актера без синхронизации.

Смотрите также

Рекомендации

  1. ^ «Программирование на основе потоков».
  2. ^ Карриеро, Николас; Гелернтер, Дэвид (1989). «Линда в контексте». Коммуникации ACM. 32 (4): 444–458. Дои:10.1145/63334.63337.
  3. ^ Гелернтер, Дэвид; Карриеро, Николас (1992). «Координационные языки и их значение». Коммуникации ACM. 35 (2): 97–107. Дои:10.1145/129630.129635.
  4. ^ а б Гейб Штайн (август 2013 г.). «Как тайный метод кодирования из банковского программного обеспечения 1970-х может спасти здравомыслие веб-разработчиков повсюду». Получено 24 января 2016.
  5. ^ Конвей, Мелвин Э. (1963). «Дизайн разделяемого компилятора диаграмм переходов». Коммуникации ACM. 6 (7): 396–408. Дои:10.1145/366663.366704.
  6. ^ Дж. Пол Моррисон, Модульная система реагирования на данные, система программирования с чередованием задач, Бюллетень технического раскрытия информации IBM, Vol. 13, No. 8, 2425-2426, January 1971.
  7. ^ Моррисон, Дж. П. (1978). «Механизм связи потока данных». Журнал IBM Systems. 17 (4): 383–408. Дои:10.1147 / sj.174.0383.
  8. ^ Стивенс, В. П. (1982). «Как поток данных может повысить продуктивность разработки приложений». Журнал IBM Systems. 21 (2): 162–178. Дои:10.1147 / sj.212.0162.
  9. ^ W.P. Стивенс, Использование потока данных для разработки приложений, Байт, июнь 1985 г.
  10. ^ W.P. Стивенс, Дизайн программного обеспечения - концепции и методы, Практическая серия программной инженерии / Под ред. Аллен Макро, Прентис Холл, 1990, ISBN  0-13-820242-7
  11. ^ Джонстон, Уэсли М .; Ханна, Дж. Р. Пол; Миллар, Ричард Дж. (2004). «Достижения в языках программирования потоков данных». Опросы ACM Computing. 36 (1): 1–34. CiteSeerX  10.1.1.99.7265. Дои:10.1145/1013208.1013209.
  12. ^ Д.П. Фридман и Д.С.Вайз, МИНУСЫ не должны оценивать свои аргументы, Автоматы, языки и программирование, Edinburgh University Press, Эдинбург, 1976
  13. ^ «Архивная копия». Архивировано из оригинал на 2014-09-06. Получено 2014-09-06.CS1 maint: заархивированная копия как заголовок (связь)
  14. ^ "Программирование "М. А. Джексон, опубликованный в Труды семинара по программному обеспечению в физике высоких энергий, страницы 1-12, ЦЕРН, Женева, 4–6 октября 1982 г.
  15. ^ а б "Метод разработки системы В архиве 2012-02-06 в Wayback Machine "М. А. Джексон, опубликованный в Инструменты и понятия для построения программ: продвинутый курс, Издательство Кембриджского университета, 1982 г.
  16. ^ "JSP в перспективе "Майкл Джексон; JSP в перспективе; в" Пионеры программного обеспечения: вклад в разработку программного обеспечения "; Манфред Брой, редакторы Эрнста Денерта; Springer, 2002
  17. ^ W.B. Акерман, Языки потока данных, Proceedings National Computer Conference, pp. 1087-1095, 1979.
  18. ^ W.H. Burge, Рекурсивные методы программирования, Эддисон-Уэсли, Ридинг, Массачусетс, 1975
  19. ^ Парнас, Д. Л. (1972). «О критериях, которые будут использоваться при декомпозиции систем на модули». Коммуникации ACM. 15 (12): 1053–1058. Дои:10.1145/361598.361623.
  20. ^ К. Эллис и С. Гиббс, Активные объекты: реальности и возможности, в Объектно-ориентированные концепции, базы данных и приложения, ред. В. Ким и Ф. Х. Лочовски, ACM Press, Addison-Wesley, 1989

внешняя ссылка