В статье сформулированы некоторые проблемы информационных технологий (ИТ) и рассматривается подход к их решению, который может быть интересен разработчикам архитектур вычислительных систем и языков программирования, а также бизнесу в сфере ИТ. Но все они, исключая некоторых, вряд ли полагают, что тут есть проблемы, по крайней мере в том, о чём повествуется в этой статье, тем более что отрасль развивается более чем. Но, хотя некоторые проблемы и не осознаются, однако решать их «ползучим образом» уже давно и постепенно приходится. А можно бы сэкономить силы и средства, если решать их осознанно сполна и сразу.

Ни экономика, ни социальные коммуникации уже невозможны без использования развитых ИТ. Вот и рассмотрим, почему используемые сейчас технологии далее непригодны и на что их следует заменить. Автор будет признателен за конструктивное квалифицированное обсуждение и надеется узнать полезную информацию о современных решениях затронутых «проблем».

Идеи, определяющие архитектуру компьютеров, практически не изменились со времен фон Неймана. В основе находится алгоритм, в процессе исполнения последовательности команд которого данные подвергаются обработке. Следовательно, главными субъектами являются процессы (Controlflow), которым и предоставляются (согласно приоритетам и иерархии) вычислительные ресурсы под управлением операционной системы (ОС).

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

В используемых технологиях объектного программирования, чем разбираться в действующих алгоритмах методов и структуре данных, часто легче добавить новую надстройку над старыми под новые особенности применения. И так много раз. Нетрудно сообразить, что это тупиковый путь.

Конечно, выходы из тупика ищут и находят. Это и системы модификации БД «на лету», и протоколы обмена сообщениями, и кроссплатформенные магистрали (шины) обмена данными и пр. И все эти технологии и платформы средств программного обеспечения обновляются иногда по несколько раз в месяц. Но если так будет продолжаться и дальше, то выигрыш от очередного развития ИТ станет меньше, чем затраты на это самое развитие. В тупик ИТ нацелились по следующим причинам:

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

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

В те времена всё матобеспечение комплекса ИВЦ (два машзала почти по 200 кв.м) исчерпывалось вшитой программой начального ввода одной перфокарты и запуска содержащегося на ней кода плюс минимум подпрограмм в виде тощей пачки перфокарт. Остальное кто как сможет. Но для спецустройств регистрации телеметрии никакого матобеспечения не было.

Программировать пришлось в машинных кодах и в абсолютных адресах, разрабатывая заодно кучу драйверов для разных устройств ввода/вывода и подпрограмм, начиная с перевода десятичных чисел в двоичные коды и форматирования обратно. Вот мне бы тогда сослаться на «мы этого не проходили», да и махнуть осенью на полгода в Байконур, где развёртывалась аналогичная система – тогда ещё там, даже командированным, выдавали насовсем неплохие куртки дублёнки. А когда потом я всё-таки туда попал, уже такого не было. Девушки-программистки ранее там обучались, но, поскольку они были из спецтреста другого ведомства, им ничего, тем более летом, не полагалось. Кстати, они рассказывали, что тогда там ещё шёл монтаж и пристреливали потолочную арматуру. И вот, когда одна из девушек впервые нажала клавишу «Начальный ввод», одновременно громыхнул первый выстрел монтажного пистолета. И девушку, и стул, унесло на несколько метров от пульта.

Да и отвлекаться от разработки архитектуры всего программного комплекса и этапов обработки телеметрии мне было не с руки, хотя никаким начальником я тогда не был. Вот и пришлось самолично и сверхурочно разработать ассемблер, затем отладчики (для 2-х различных типов ЭВМ, одна из которых была ещё перфокарточная, а другая перфоленточная) в реальном времени с перехватом системных прерываний и выявлением зацикливания. Мне, как выпускнику физтеха (МФТИ), пришлось взять на себя всю эту двоичную заумь, оставив другим понятные расчетные алгоритмы. А взяли меня в эту контору потому, что в соседнем ОКБ (созданном после войны и половину сотрудников которого вначале составляли инженеры и конструкторы с немецких заводов «Юнкерс» и «Мессершмидт», вывезенных в СССР вместе с оборудованием, персоналом и их семьями) я занимался моделированием систем турбореактивных двигателей на аналоговом вычислительном комплексе МПТ-9 (ламповом, фото ниже – лучше картинки не нашлось; шкафы в рост человека, а беленькие прямоугольники — это шкалы вольтметров на 100 вольт) для отладки систем управления двигателем.



Типа АВМ или ЭЦВМ – какая разница? И надо сказать, для выпускника физтеха тех времён действительно почти никакой. На моём факультете учили, однако, отнюдь не этому и, так уж сложилось, впоследствии не востребованному. Принципы работы и аналоговых, и цифровых ЭВМ (полусумматоры, регистры сдвига и всё такое) нам преподавались в своё время на военной кафедре, как например и навыки расчета параметров запуска в цель ракет класса Земля-Земля с точностью до 5-го знака на логарифмической линейке метровой длины. Полагаю сейчас ничего подобного нет. Но когда нашему курсу решили ввести курс программирования, то почти все(!) студенты заявили, что им, как будущим «чисто учёным», этого никогда не понадобится – и бойкотировали лекции. Конечно, это не касалось студентов кафедры выч.техники – им-то за каждую микросекунду, сэкономленную в подпрограммах для БЭСМ-6, давали, по слухам, премию чуть ли не в 20 руб. Это при том, что стипендия на старших курсах была 55р. А нам, забастовщикам, сдачу курсовой по программированию отменили – но потом и я, и многие мои сокурсники, в итоге так или иначе занимались программированием.

Со временем и для нашей ЭВМ (ну это была всё-таки не БЭСМ-6, а попроще и гораздо менее известная) появился транслятор с Алгол-60, но без библиотек подпрограмм – да как-то и нужды в них не было. На ассемблере, да с отладчиком, было легко спрограммировать что угодно. Далее дело дошло до разработки мною взаимозаменяемых магнитно-ленточной и дисковой операционных систем (прозрачных со стороны прикладного ПО и интерфейса оператора – это на предмет возможного выхода из стоя дисков) с управляющими, сейчас бы сказали, Bat-файлами. И, наконец, был разработан супервизор задач, который запускал bat-файлы сценариев для получения затребованных оператором данных. Хотел даже уже разработать полноценную операционную систему, как потом выяснилось Unix-подобную, но в связи с переходом к ЭВМ типа «Ряд», сиё стало не неуместным.

Справедливости ради, скажу, что занимался не только системным матобеспечением. Когда возникла необходимость разработки программы быстрого преобразования Фурье для спектрального анализа, это пришлось быстро-быстро делать мне, тем более, что вразумительного описания алгоритма БПФ тогда найти не удалось. Пришлось изобрести заново. Ну и тому подобные задачи.

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

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

Итак, если нам необходимо построить эволюционирующий живой и привлекательный общественный организм и адекватную ему экономику, то, как полагает автор, целесообразно изменить принципы организации информационных технологий. А именно:

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

Глобальная распределённая БД должна представлять собой конгломерат иерархически организованных БД, построенных по единому принципу.

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

Архитектура и принципы работы такой БД автором разработаны. Некоторые её варианты были внедрены и в течении нескольких лет использовались без нареканий в системе делопроизводства мэрии города с почти миллионным населением.

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

Метаданные служат для указания потенциального существования и обеспечения выбора существующих данных соответственно их смысловому значению. Локальные метаданные должны быть при возможности сопоставлены метаданным в классификаторе БД более высокой иерархии. Некоторый аналог метаданных автором применялся в своё время и в супервизоре задач, и в городской системе выплат пенсий и пособий, архитектура баз данных которой была разработана автором, где он руководил отделом автоматизации как раз в те времена, когда алгоритмы выплат и индексаций пенсий менялись правительством чуть ли не по 3 раза в месяц.

Нельзя сказать, что этой проблемой не занимаются. Во-первых, стандарты XML позволяют характеризовать данные тегами, хоть и в линейных файлах. Есть и более глобальные подходы к проблеме: погуглить, например, «язык описания онтологий OWL». А здесь автором предлагаются предельно радикальные решения, когда данные хранятся в БД без привязки к каким-либо изначальным структурам, а требуемые пользователям структуры формируются в соответствии с описанием их в метаданных.

• Должны выполняться потоковые вычисления по технологии Dataflow, то есть осуществляться управление по данным. Новые данные должны вычисляться в соответствии с заданным для них алгоритмом, как только появятся необходимые для этого исходные данные. Вычисления должны выполняться в сети децентрализованно и параллельно.

Обработка данных должна состоять в том, чтобы записать в БД новые данные, вычисленные согласно сопоставленному им алгоритму по выборке отвечающих условию задания ранее вычисленных или введённых исходных данных. Новые данные будут автоматически получены, как только сформируется необходимая для этого выборка – и так во всей сети распределённых БД. Последовательность действий указывать не надо (т.е. не надо писать программный код управляющей программы), так как при управлении по данным очередные действия выполняются по факту наличия нужных для этого исходных.

_{(Примерно такая же технология вычислений используется в табличной БД «Excel», где очередные данные в ячейках вычисляются по мере их вычисления в ячейках с исходными данными. И там для этого тоже не надо описывать последовательность команд.)}

Всё «программирование» сводится к описанию в метаданных новых данных с их атрибутами (в том числе правами доступа), связями, характеристиками отображения в пользовательском интерфейсе (если надо), указанию условий для атрибутов исходных данных значениями которых определяется их вхождение в выборку, и заданию алгоритма обработки. Алгоритм, более чем в 99% ситуаций, сводится к указанию, что следует выполнить с данными выборки из ряда: просуммировать, вычислить среднее, найти максимум или минимум, вычислить статистические отклонения, определить регрессивную функцию и т.п. по массиву указанной выборки. В общем случае возможны вычисления (сумма произведений и др.) по нескольким выборкам, например, A_N из выборки {N} и B_K из выборки {K}, и т.д., где k, например, в свою очередь выборка параметра K_N из выборки {N}. и т.п. Формулы, которые в примере с «Excel» вписываются в ячейки для вычисления новых данных, могут аналогично составить описание алгоритма в программном модуле для получения новых данных из исходных в технологии Dataflow. И для этого, как и в «Excel», обычно не потребуется привлекать профессиональных программистов. Разве иногда и лишь для конкретной задачи.

Таким образом, за малыми исключениями, весь объём задач информатизации может создаваться специалистами прикладных отраслей без привлечения профессиональных программистов. Данные, с которыми они имеют дело, могут описываться этими же специалистами в метаданных самостоятельно (если там нет аналога) и по содержанию, назначению и образу могут копировать привычные им бумажные документы. Простого дизайнерского конструктора для этого будет достаточно. Любой документ (также отчёт или научная статья) будет не просто текстовым файлом, а объединением сведений из БД, обеспеченными также инструментарием для их представления и работы с ними, указанным в метаданных.

Сейчас для обеспечения таких возможностей постоянно расширяют функционал браузеров, добавляя флэш-проигрыватели, опции на джава-скрипт, вводя новые теги, web-сервисы и т.д. Метаданные позволили бы организовать, локализовать и упорядочить эти процессы.
И всегда можно организовать получение нового произвольного документа (набора данных) без редактирования действующих уже алгоритмов функционирования всей системы, поскольку одни и те же данные распределённой БД, по факту своего существования, могут участвовать во множестве разнообразных алгоритмов получения новых документов по нужным выборкам. Для осуществления интегрального учёта товарооборота при управлении по данным и реализации унифицированной распределённой БД, даже никуда не надо будет отсылать свои отчёты – достаточно просто начать функционировать. Появляющиеся данные будут подхвачены и учтены автоматически.

Разработчики, занимающиеся автоматизацией применительно к бизнес-процессам, могут указать, что все эти возможности уже давно реализованы в специфике BPM-систем. И как раз на примере BPM-систем мы видим, как идеи управления по данным скрытно, т.е. без осознания сути явления, просачиваются в практику – конечно пока ещё под управлением центральной ведущей программы. Но, увы, чтобы BPM-система заработала, как например «крутейшая» «ELMA», в штате компании должен состоять программист хорошо владеющий языком программирования Си-шарп. Автору довелось поучаствовать в администрировании этой системы. А без штатного программиста придётся подгонять свои структуры и бизнес-процедуры под предлагаемые шаблоны. Но такой подход ничем не отличается от обычной практики приобретения прикладных приложений со всеми проблемами их адаптации и интеграции.

Идеи управления по данным чисто математически формализованные в виде ориентированных графов и перемещаемых данных в виде «токенов», на практике оказывались сложно реализуемы. К тому же требующими использования дорогой и энергоёмкой ассоциативной памяти. Поэтому автором предлагается реализация в виде «крупнозернистой» модели, где каждый модуль полностью выполняет обработку исходных в пределах локальной БД. Подобные же модули будут работать в других локальных БД, объединяя результаты в БД более высокого уровня. Когда отработаются все зарегистрировавшиеся источники данных, новые данные получат статус готовых.
При отсутствии данных в локальной БД, запрос пересылается в БД более высокого уровня, и т.д. А уже из неё запрос будет растиражирован по подведомственным локальным БД. Результаты его отработки тоже будут либо интегрированы в БД верхнего уровня, а затем высланы в локальную БД, инициировавшую запрос, либо выше по иерархии, если запрос пришёл сверху. Таким образом, знать электронные адреса всех источников и получателей нет необходимости. Для каждой локальной БД достаточно знать только адрес более высокой по иерархии БД. Этот принцип организации транзакций позволяет осуществить легко масштабируемую и расширяемую систему.
Наиболее просто и наглядно алгоритм вычисления можно отобразить с помощью блок-схем. На них показано, какие данные поступают на вход каждого программного модуля, и куда передаются вычисленные в нём выходные данные. Автором разработан язык DFCS программирования параллельных вычислений в системе управляемой потоками данных, на котором можно описать все связи блок-схем.

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



В блок-схеме точно определено, какие модули с какими связаны, и не нужно ассоциативной памяти, но некоторые меры синхронизации данных должны быть предусмотрены, особенно если применяется распараллеливание «узкого» участка ветви алгоритма. Программные модули (ПМ) в некоем оптимальном сочетании загружаются в вычислительный блок (ВБ). Данные от ПМ к ПМ передаются через порты, которые могут быть представлены виртуально или регистрами физических устройств. При управлении по данным модуль, устройство или порт, файл или запрос к БД, функционально совпадают и взаимозаменяемы. Физические порты используются для обмена данными между ВБ по каналам передачи данных и, возможно, также между ПМ в одном ВБ. Данные временно хранятся только в портах (регистрах) и иногда, возможно, в некоторой очереди. А основные массивы данных должны храниться в БД, которые должны быть выполнены как отдельные специализированные устройства, поскольку интерфейс доступа к данным должен быть одинаков – независимо от структуры и связей конкретных данных.

Данные между устройствами передаются по шине данных вдоль которой может размещаться множество пользующихся ею устройств и модулей. Перед тем как приступить к обмену данными, обменивающиеся устройства должны «захватить» шину, чтобы потом никто не вмешивался. Захват обычно происходит по алгоритму взвешивания адресов устройств на шине и занимает как минимум столько тактов, какова разрядность их адресов.
Однако существует и даже была реализована в «железе» в упомянутом выше НИИ технология захвата шины за 1 — 2 такта устройствами независимо от их числа. Учитывая прогресс технологий, можно для обмена использовать десятки или сотни шин данных, выбирая свободную. Архитектура вычислительного комплекса показана на рисунке ниже. Комплексы могут объединяться в сеть соединением их шин через адаптеры передачи данных.

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

Именно ПДД запускает работу модуля, если входные данные есть в порту. Полученное выходное данное помещается в выходной порт, откуда транспортная программа (или драйвер) переносит его по шине данных во входной порт связанного с первым следующего модуля, а уже там своя программа ПДД запускает его в работу. Если же модули находятся в одном вычислительном блоке, то транспортная программа не используется и т.п. Если модуль отработал, а нового входного данного нет, то ПДД останавливает исполнение этого модуля. Работа модуля возобновится, когда в порту появится данное. Однако, столь, казалось бы очевидные, правила ПДД на практике не способны обеспечить устойчивую работу системы Dataflow. Так что «правильные» алгоритмы ПДД гораздо интереснее, и, имею основания думать, реализуемы.

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

Итак, какие шаги надо предпринять, чтобы внедрить прогрессивные ИТ?

1. Разработать единую унифицированную структуру баз данных, пригодную для хранения любых данных в их взаимосвязи, включая описания метаданных.
   В принципе, это сделано, но нигде не опубликовано (хотя опробовано).
2. Разработать систему иерархической организации БД и технологию транзакций (вверх и вниз) на основе метаданных, для исключения конкретной адресации к источникам и потребителям данных.
3. Разработать и, наконец, внедрить где-нибудь имитацию технологии Dataflow в рамках существующих Web-технологий на Web-серверах используя модель БД унифицированной структуры, реализованную в технологии реляционных баз данных. В данный момент это было бы наиболее эффективным вложением средств.
4. Разработать эффективный и надёжный алгоритм протокола движения данных (ПДД).
   В принципе, это выполнено, но нигде не опубликовано.
5. Разработать язык программирования параллельных вычислений в системе управляемой потоками данных, и компилятор для него.
   Описание языка DFCS опубликовано. Создание компилятора не представляет проблемы.
6. Разработать и начать производить хранилища баз данных с унифицированным интерфейсом согласно п.1, как отдельные электронные устройства.
7. Разработать систему создания библиотечных программных модулей хранимых в БД программного обеспечения в хранилищах данных, систему доступа к ним через метаданные и загрузки в вычислительные блоки.
8. Заменить файловую систему хранилищем БД.
9. Начать производить мультипроцессорные системы с мультишинными магистралями данных и массивами электронных портов обмена данными.
   А это уже давно не проблема.

Ясно, что используя имитацию Dataflow в существующих технологиях Web (см. п.3), автоматизированную систему управления технологическими процессами (АСУТП) построить нельзя. Для этого необходимо реализовать Dataflow «в железе», чем и занимались, вплоть до «перестройки», в упомянутом НИИ с целью использования в мультипроцессорных контроллерах. Но можно легко реализовать все возможности по созданию систем управления предприятием, развития независимых социальных сетей и для управления бизнес-процессами.

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

Но это не значит, что программистам грозит безработица. Наоборот, благодаря унифицированному интерфейсу обмена данными и классификаторам метаданных, разрабатываемые ими сервисы (Software as a Service) смогут получить самое широкое поле применения, а разработчики пропорциональную оплату. Нечто подобное конечно уже делается, но спецсредствами через посреднические преобразования представления данных.

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

Если имитация Dataflow в Web-технологиях пройдёт успешно, появятся основания для осуществления технологии Dataflow в «железе». Технические разработки начать, скорее всего, следует с п.4 и с п.6, т.е. производства баз данных в виде универсальных устройств и, соответственно, отказаться от файловых систем. Гигабайтная память должна использоваться в интерфейсе БД (где ей и место) для размещения массивов по запросам данных. В модулях же основная память нужна лишь для команд (в режиме только чтения), а для данных потребуется лишь, допустим, несколько сотен (или тысяч) регистров (портов). Например, с прерыванием при изменении состояния. И сюда «просится» что-то типа последних разработок IBM Research, вроде бы «позволяющих производить вычисления в ячейках памяти». Плюс кэш для размещения очередей.

Язык программирования, упомянутый в п.5, может понадобиться и для программирования вычислительных блоков, используемых в хранилищах данных (см. п.6). Язык DFCS характеризуется следующими особенностями. В каждом участке сети модулей (и внутри любого модуля) данные фигурируют только в принадлежности ко входам и выходам, называемых портами. То есть достаточно декларировать представление данных в портах модулей. Поскольку порядок исполнения модулей определяется по мере готовности данных, то нет необходимости в предписании определённой последовательности исполнения модулей – нужно описать лишь их коммутации друг с другом – всё равно в каком порядке. То есть язык оказывается декларативным. Поскольку всё сводится к инструкциям с параметрами, разбора каких-либо синтаксических конструкций не требуется. Программа в процессе «компиляции» может непосредственно загружаться в память.

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

В программной части языка DFCS предполагается использовать метки и команды перехода, что как бы противоречит принципам структурного программирования. Однако, исходя из собственного опыта программирования, могу утверждать, что программа с метками и командами перехода обычно более компактна и более понятна, чем с продублированными многократно копиями блоков и набором «флажков» ради исключения команд перехода. Аналогичного мнения придерживаются и некоторые профи.

Краткое описание языка можно скачать с Яндекс-диска.