Да вот наверное так, как этот непонятливый Мыш решает задачу прохождения сложного лабиринта. См. рисунок.
Идея очень простая: по мере того, как, по мере обработки исходных, будут появляться новые данные – должны запускаться программы предназначенные уже для их обработки и т.д., этап за этапом. Причём независимых программ, которые по-разному и с разными целями будут обрабатывать появляющиеся данные, создавая при этом новые, может быть сколько угодно – и вовсе не обязательно, чтобы они все были придуманы одновременно в рамках единого проекта.
Тем самым актом старта процесса обработки очередных исходных данных должен стать сам факт их появления, а отнюдь не запуск процесса подготовки первичных исходных с последующей передачей управления следующему этапу и т.д., так что ВСЕ этапы должны бы быть заранее описаны в основной ведущей программе.
Т.е. этапы обработки данных должны стать полностью децентрализованными и параллельными. Тогда и надобность в процессном упорядочивании последовательности этапов отпадает.
Конечно старт обработки по мере появления данных может быть осуществлён и в процессных технологиях, но там его инициация заложена в ведущей программе.
Таким образом управление всем процессом обработки данных выполняется по мере появления (создания) очередных данных, а не по заранее составленному регламенту. Собственно, тогда и сам этот регламент становится ненужным и вместо управления процессами (controlflow) осуществляется управление по данным (dataflow)
Управление по данным фактически встроено в функциональные языки программирования, поскольку более общие функции становятся вычислимы после получения значений более элементарных. Но процесс распутывания вхождений и последовательности вычислений является весьма сложной задачей для компилятора (да и для программиста).
Наиболее адекватно процесс поэтапной передачи и обработки данных может быть отображён блок-схемой. Если в блоке содержится алгоритм получения массива значимых данных, а не просто результат исполнения машинной команды, то модель называется "крупнозернистой".
На "Западе" разработки языков функционального программирования пригодных для "крупнозернистой" модели Dataflow были давно сделаны. Но широкого развития направления Dataflow не отмечено. А какой бы смысл, если существующий статус-кво пока всех устраивает?
Тем не менее, как же всё-таки, не оглядываясь на "Запад", развивать "цифровизацию"?
1. Разработать модель унифицированной БД в рамках существующих Web-технологий и реляционных баз данных. См. http://proza.ru/2024/10/08/1304
2. Разработать систему иерархической организации БД и технологию транзакций для обеспечения обмена данными и их интеграции.
3. Начать пересохранение своих данных в формат унифицированной БД.
4. Разработать язык программирования параллельных вычислений управляемых потоками данных и компилятор. См. http://proza.ru/2024/10/15/912
5. Разработать технологии создания и хранения библиотечных программных модулей в хранилищах данных, их компиляции и загрузки в вычислительные блоки.
6. Разработать и начать производить электронные устройства хранилищ баз данных с унифицированным интерфейсом согласно п.2.
7. Начать производить мультикомпьютерные системы с мультишинными магистралями данных и электронными портами обмена данными, с хранилищем БД заменяющим также файловую систему. См. http://proza.ru/2024/10/11/770
Пункты 1 и 2 и 3 выполнимы в стандартных Web-технологиях и на данный момент кажутся наиболее эффективным вложением средств в ИТ разработках. Реализация унифицированной БД возможна в любой СУБД реляционных баз данных, хотя технически это наверное не оптимальное решение.
Ожидается, что успешность применения УБД в задачах пользователей будет стимулом к выполнению п.6 по разработке аппаратных хранилищ УБД, но к этому моменту уже должен быть выполнен п.5, которому должно предшествовать выполнение п.4.
Важнейшую роль в программировании играет доступность сведений о всём арсенале средств системных платформ и их использовании в аспектах прикладных применений. Сейчас это достигается трудоёмким изучением немалого объёма знаний и приёмов в каждой отрасли деятельности.
Использование унифицированной БД предоставило бы, благодаря классификаторам, метаданным и содержащимся в них описаниям, возможность компетентного выбора модулей адекватных возникшей потребности.
Наличие технологической поддержки в виде разработанных CASE-средств (графических) позволило бы визуально сконструировать блок-схему программы для решения задачи и её технологическую карту в виде выборок элементов программы из баз данных, включая средства отображения данных и работы с ними.
При запуске программы в работу пользователи временно получали бы специфические средства отображения её данных и управления процессом исполнения – так что никакие предварительные инсталляции ПО на все случаи жизни не потребуются.
Реализация всех вычислительных процессов в системе в виде блоков связанных передачей данных через порты обеспечила бы возможность компиляции и включения новой задачи в состав работающей системы обработки данных без потерь данных и остановки – и даже без перепрограммирования действующей части системы.