Модели потоков данных

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

Если преобразования представлены в виде отдельных процессов, такую модель иногда называют конвейером или моделью фильтров, следуя терминологии, принятой в системе Unix. Последняя поддерживает конвейеры, которые действуют как хранилища данных, и набор команд, представляющих функциональные преобразования. Здесь используется термин "фильтр", поскольку преобразование "фильтрует" данные во время обработки потока данных.

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

Пример такого типа системной архитектуры показан на рис. 10.10. Здесь организация выписывает счета заказчикам. Раз в неделю платежные квитанции согласуются со счетами. Для оплаченных счетов выдается квитанция. По счетам, не оплаченным в течение установленного срока, выдается соответствующее уведомление.

Рис. 10.10. Модель потоков данных для системы обработки счетов

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

Данная архитектура имеет ряд преимуществ.

1. Возможность повторного использования преобразований.

2. Понятность, поскольку большинство людей также мыслят в терминах обработки входных и выходных данных.

3. Возможность модификации системы путем непосредственного добавления новых преобразований.

4. Простота реализации как последовательной, так и параллельной систем.

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

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