Единое информационное пространство и потоковая обработка - решение проблем практики цифровизации
1.Проблемы практики "цифровизации"Современные информационные технологии (ИТ) недоступны для повседневного использования каждым по своей надобности без обращения к специалистам и не обеспечивают интеграции данных в концепции общего информационного пространства. Однако сиё если кого и огорчает, то явно не специалистов ИТ.
А не огорчает их потому, что знание средств и умение преодолевать существующие проблемы в ИТ является специфической сложностью профессиональной деятельности специалистов ИТ и обеспечивает ей высокий статус. К тому же наличие проблем создаёт широкое поле деятельности по разработке средств их преодоления, которые вливаются в объём необходимой компетенции, заставляя специалистов постоянно повышать свой уровень. Сейчас это наиболее востребованный аспект деятельности фирм предлагающих услуги ИТ.
В основе современных информационных технологий (ИТ), как и более полувека назад, лежит стандартная парадигма, по которой, для того чтобы получить результаты вычислений или обработать исходные данных, необходимо запустить на электронной вычислительной машине (ЭВМ) компьютерную программу, которая выполнит ввод исходных данных, обсчитает их, и выдаст результаты на указанное в программе выходное устройство.
Получением доступа к файлам и устройствам, предоставлением и освобождением памяти, управлением очерёдностью и временем исполнения программ - то есть управлением процессами (Controlflow) исполнения задач и распределением затребованных ими ресурсов занимается операционная система (ОС).
Разных моделей ЭВМ (часто секретных) было разработано много, и у каждой свой набор программных кодов. Поэтому озаботились разработкой единого языка высокого уровня. Сначала Фортрана, а потом более продвинутого Алгола. А потом ещё и ещё (сейчас их количество около 30 и увеличивается) - всё более продвинутых, вплоть до языков объектно-ориентированного программирования (ООП), либо и вовсе функциональных.
А в языках ООП важно знать иерархию классов объектов, структуру, свойства и методы объектов - ибо даже одинаковые операторы языка могут работать с объектами по разному. И вот даже зная что надо делать и зная язык - без изучения применяемых в каждой прикладной сфере объектов, вы ничего не сможете.
Тем более, что в разных сферах применения принято использовать разные языки. А для каждой задачи даже в одной отрасли разными разработчиками придумываются разные классы объектов, так что воспользоваться в одной задаче объектами другой, особенно если эти задачи разрабатывались в разных организациях, довольно сложно, ибо требует документированного согласования и может даже совместной разработки средств обмена данными.
Если сравнить программирование с вождением автомобиля, то раньше было везде понятно куда рулить, но в разных автомобилях были разные рычаги и кнопки, хотя на любом можно было ездить в любом городском районе. А теперь в каждом квартале города свои дорожные правила, и в каждом районе надо пересаживаться в другой автомобиль.
Поэтому в области ИТ существует объективная тенденция к монополизации сфер информационной деятельности, где не последнюю роль играют языки, как например 1С, почти безраздельно занявший нишу бухгалтерии. Да и требование установки определённых платформ среды исполнения тоже привязывает к разработчику программного обеспечения (ПО). Если задача губернского или государственного уровня, то применяется и адмресурс, устраняющий независимых разработчиков, хотя сплошь и рядом ПО устанавливаемое "сверху" гораздо хуже.
Как отмечалось, последовательность обработки всех данных задаётся в процессе исполнения главной ведущей программы. При появлении данных нового вида необходимо в ведущей программе обеспечить их создание, условия и способ их использования другими программами.
Даже в масштабах предприятия число классов (таблиц или структур, содержащих данные) бывает до тысяч. Вряд ли там найдутся специалисты, знающие, что, где и как во всех них хранится. Тем более, что на другом предприятии то же самое может быть организовано в других структурах.
В технологиях ООП часто легче добавить новую надстройку над объектами старых классов под новые особенности применения, чем разбираться в алгоритмах методов и структуре данных. И так неоднократно за время эксплуатации ПО. Со временем в базах данных (БД) накапливается «мусор» из забытых уже старых структур, который может быть подхвачен при выполнении запроса.
Конечно технологии развиваются. Разрабатываются системы модификации БД «на лету», протоколы обмена сообщениями, кроссплатформенные магистрали (шины) обмена данными и пр. И все эти средства ПО обновляются по несколько раз за год. В итоге всё больше сил и средств затрачивается только для поддержания систем в работоспособном состоянии, которые становятся всё более монопольными и всё менее обозримыми. По мере прогресса и расширения цифровых технологий все эти проблемы только усугубляются. Вплоть даже до того, что оригинальные исходные коды оказываются погребены под напластованием модернизаций, из-за чего ревизовать и очистить программы от ошибок уже невозможно, ибо слишком дорого. Вот, в частности и об этом, мнение профессионала https://habr.com/ru/post/423889/ Так недалеко и до времени, когда выигрыш от очередного развития ИТ станет меньше, чем затраты на это самое развитие.
В кодировании алгоритма программы проблем нет, особенно если он отображён блок-схемой, а вот с объектами, даже не столько с их придумыванием и созданием, сколько с получением информации об их структуре и свойствах в конкретной прикладной деятельности, о формах их представления - очень серьёзные проблемы, и не всегда "help" поможет. Подытожим вышеуказанные проблемы ИТ.
Решить вышеназванные проблемы можно только пересмотром самой парадигмы ИТ. Подобно тому, как в живой природе существует единая технология оперирования генетическим кодом на основе которого формируются популяции животных (как бы "объектов") различных видов, в информационном пространстве должна существовать единая система структурной организации, позволяющая формировать объекты (документы) самого разнообразного вида.
Любой специалист в своей профессиональной деятельности легко оперирует бумажными документами, а при необходимости заводит новые. Он также может сделать выписки из требуемых сопутствующих документов. Однако в электронном формате для создания новых документов пока необходимо прибегать к услугам программистов или администраторов БД.
Естественно, появились предложения от разработчиков предлагающих пользователям средства лёгкого конструирования БД адекватно своим потребностям и понятиям, что в корне противоречит объективной и насущной общественной необходимости интеграции данных.
Унифицированная БД (УБД) позволит оперировать электронными документами с такой же лёгкостью, как и бумажными, не привлекая ИТ-специалистов. Это возможно потому, что при создании новых документов в УБД не возникает новых сущностных объектов и её структура не изменяется, ибо хранимые в ней данные не распределены по экземплярам документов.
Унификация позволит также на основе локальных УБД создать иерархически организованную глобальную распределённую УБД. Причём для обмена данными между локальными БД не требуется знать их адреса. Достаточно, чтобы каждая локальная БД имела связь только с единственной БД выше неё по иерархии на одну ступеньку. А уже через неё запрос на выборку будет растиражирован в локальных БД, либо отправлен для тиражирования в БД более высокой иерархии и т.д.
В такой унифицированной БД можно было бы хранить произвольного формата любые сведения из энциклопедий и даже актуальные научные статьи, если человечество со временем всё-таки создаст единый научный язык, в котором отношения сведений между собой типа "кто, кого, как, чем, зачем, когда, где, содержит, зависит от, принадлежит к, было, будет, до, после, сейчас, всегда, от … до …, если … то и т.п." были единообразно формализованы в языковых конструкциях или символах отношений, допуская в то же время расширение по мере необходимости спектра учитываемых отношений. Эта УБД могла бы стать актуальной базой знаний, причём она оперативно отражала бы всё богатство взаимных связей и смысловое содержание хранящихся понятий, фактов и данных.
Автором разработаны архитектура и принципы работы такой БД. Некоторые её упрощённые варианты несколько лет эксплуатировалась в системе делопроизводства городской мэрии.
Нельзя сказать, что этой проблемой не занимаются. Во-первых стандарты XML позволяют характеризовать данные тегами, хоть и в линейных файлах. Есть и более глобальные подходы к проблеме, например, "язык описания онтологий OWL".
Но в унифицированной БД принято более кардинальное решение, так что фактические данные "на лету" группируются в форматах тех или иных документов согласно онтологии в метаданных.
Обработка данных, большей частью состоит в том, чтобы в определённый момент выбрать нужные данные из уже существующих документов и создать новый документ, содержащий результаты обработки. Алгоритм обработки, более чем в 99% ситуаций, заключается в суммировании, вычислении среднего, нахождении максимума или минимума, вычислении статистические отклонений, определении регрессивной функции и т.п. по массиву данных в выборке исходных документов.
Момент обработки наступает, когда созданы и получены все исходные данные, нужные для формирования выходного документа с результатами. В состав исходных данных также могут входить срабатывание сигнального датчика, исполнение оговоренного события (например включение компьютера на рабочем месте специалиста), календарная дата, истечение заданного интервала времени и пр.
Тип требуемых исходных данных, как и способ (алгоритм) их использования, специфицированы в метаданных нового создаваемого документа. В большинстве случаев получение данных нового документа из исходных реализуемо выполнением SQL-запросов. И так, выполняя эстафету последовательного получения очередных новых документов, могут быть в итоге получены все нужные расчётные таблицы, отчёты и справки на рабочих местах каждого специалиста.
Нечто подобное вышеизложенному уже выполняется в BPM-системах управления бизнес-процессами и эффективностью, позволяя перейти от служебных инструкций к автоматическому исполнению и контролю процессов. Но в каждой из таких систем создаются свои объекты в БД со своими специфическими структурами, что, повторюсь, "в корне противоречит объективной и насущной общественной необходимости интеграции данных".
И кроме того, эксплуатация и сопровождение, например, "крутейшей" BPM-системы ELMA, которую автору довелось некоторое время администрировать, требует постоянного участия программиста со знанием языка C#.
3.Использование унифицированных БД уже сейчас может быть полезным и выгодным
Процессы обработки данных должны инициироваться самим фактом появления где бы то ни было необходимых исходных данных, и так поэтапно.
Унифицированные БД (УБД) позволят пользователям, в отличие от существующей практики, самостоятельно конструировать типы выходных документов, создавая требуемые SQL запросы на выборку исходных данных с помощью относительно простого конструктора использующего метаданные исходных документов и их атрибутов. Формируя метаданные нового документа пользователи тем самым опишут и получение данных для его создания. Ввиду унификации структуры БД все SQL запросы строятся по готовым шаблонам. Технология работ по сути ничем не будет отличаться от работы с бумажными документами создаваемыми специалистами по мере необходимости, причём точно такого же формата, как если бы они были бумажными.
В процессе эксплуатации сформированный документ будет создаваться уже автоматически, по мере появления исходных данных. Таким образом, логика цели и смысла обработки данных приводит к тому, что готовность исходных данных должна инициировать и получение результатов, т.е должно выполняться управление по данным (Dataflow).
Благодаря метаданным пользователи смогут обмениваться данными интегрируя их простым формированием документа с SQL-запросами данных из массива документов партнёрской организации, а благодаря встроенным средствам связи по системе иерархий БД, это будет возможно даже в случае их нахождения в различных локальных БД. Понятно, что должна быть разработана система контроля доступа к данным.
Вследствие унификации есть основания предполагать, что учётно-финансовую и управленческую деятельность пользователи смогут автоматизировать по мере потребностей самостоятельно. Пользователи, до нужд которых у крупных ИТ фирм "не доходили руки", или те, кому их услуги были "не по карману", смогут легко автоматизировать свои дела.
Кроме того, каждый может создать личный раздел в унифицированной БД на Web-сервере и, предоставляя доступ другим пользователям по их заявкам к некоторым форматам документов, организовать, например, клуб по интересам с возможностью диалогов в чате. Естественно, все участники должны быть клиентами УБД. Кстати, наличие обмена сообщениями считается полезным и в BPM-системах при проведении конференций.
Таким образом в рамках существующих Web-технологий создаётся сегмент интернет-пространства в котором предприниматели смогут вести полноценный учёт ресурсов и продукции, организовать работу с клиентурой и создать систему управления распределённым предприятием без обращения к профессиональным программистам, а все пользователи получают возможность заниматься организацией быта и общением по интересам. Возможно для этого сегмента будет уместным название "Деловой интернет".
Коммерческий интерес разработчика может осуществляться, например, сдачей в аренду пользователям доступа через интернет к унифицированной БД и средствам управления ею, а также к сервисам ПО. А благодаря унифицированному интерфейсу обмена данными и классификаторам метаданных, разрабатываемые в технологии унифицированных БД "свободными" программистами сервисы смогут получить более широкое поле применения, чем это возможно сейчас ввиду узкой специализации и привязки к платформам.
4.Технология и среда потоковой обработки данных - Dataflow
При поэтапной обработке получение очередных данных могут выполняться асинхронно разными серверами и в разных БД. Наиболее наглядно этапы обработки данных отображаются блок-схемой, модули которой обмениваются данными через порты ввода/вывода.
Итак, ранее сделан вывод, что "готовность исходных данных должна инициировать и получение результатов", т.е должно выполняться управление по данным (Dataflow). В начале 80 х годов были эксперименты (на Западе) создания Dataflow машин, в которых поток данных состоял практически из операндов машинных команд. Однако такие архитектуры оказались неэффективными и к тому же использовали дорогую и медленную ассоциативную память для выбора одновременно обрабатываемых операндов. Поэтому перешли к "крупнозернистым" моделям, где каждый модуль обработки данных представлял собой блок операторов.
Излагаемое в данной статье не является описанием мировых трендов в принципах потоковой обработки, а отражает исключительно авторскую концепцию. Наглядно "крупнозернистая" модель отображается блок-схемой алгоритма программы. Понятно, что алгоритм, исполняемый в каждом блоке, тоже может быть представлен блок-схемой из модулей, выполняющих части алгоритма блока. И т.д., вплоть до машинных команд.
Каждый блок (или модуль) программы выполняет некоторую группу связанных операций над входными данными получая содержательный результат, который используется на следующих этапах обработки в других блоках.
Исходные данные поступают на входные порты (изображены кружочками) блока, а результаты помещаются в выходные порты.
Не связанные на приведенном фрагменте блок-схемы, т.е. свободные, порты отмечены жёлтым цветом. Данные, передающиеся из порта n7 блока B1 в порт n6 того же блока через блок B2, возможно участвуют в некоем цикле или управляемом контуре обратной связи. Или это может быть исполняемая в блоке B1 функция обработки данных, которая таким образом вынесена вовне и может быть подключаема та или иная по выбору. Её выбор или параметры могут управляться через порт B4. В функциональных языках подобные возможности, когда функция указывается (или программируется) в аргументах, называются функциями высшего порядка.
Если вся программа размещена в одной ЭВМ, то связанные выходной и входной порты могут быть представлены одним и тем же объектом. Назовём исполняемый модулем алгоритм функцией, а данное, помещаемое ею в объединённый порт, назовём возвращаемым значением функции. В результате получим программу, где функции связаны друг с другом через возвращаемые значения, так что присваивать переменным какие-либо промежуточные значения для временного хранения нет необходимости.
Полагаю, что вышеописанная модель соединения и работы модулей блок-схемы вполне соответствует концепции функциональных языков программирования. Однако в случае блок-схем целесообразно не ограничиться только одним возвращаемым значением.
Поскольку процесс вычисления управляется передачей данных от блока к блоку, то совершенно не играет роли порядок, в котором алгоритмы каждого блока будут описаны. Существенным является только описание связей выходных и входных портов блоков - от какого и какому передаются данные - и тоже не важен порядок перечисления.
Для того, чтобы получить выходной документ, достаточно, как и в случае "Делового интернета" (см гл.3), просто указать его метаданные в унифицированной БД. В них будет содержаться информация об SQL-запросах исходных данных и программа блок-схемы модулей для формирования требуемого документа. Далее будет вызван загрузчик, который в соответствии с программой разместит в вычислительной сети указанные в программе модули. Поскольку структура и типы данных обрабатываемых каждым модулем описаны в метаданных, то сразу будут сформированы входные и выходные порты, установлены их связи и обеспечены средства транспортировки данных между выходными и входными портами.
После получения нового документа и занесения его в БД проводится "уборка мусора" из памяти, т.е. участки памяти зарезервированной для размещения модулей и данных записываются в список свободной памяти, упорядоченный по их адресам. Смежные участки объединяются в один, а список свободной памяти корректируется. Из этого списка по мере надобности снова выбираются участки для размещения данных и программ.
Архитектура мультикомпьютерного комплекса (МКК) выбиралась по критериям простоты и дешевизны. Блоки программы могут быть размещены в различных вычислительных модулях (на рисунке ниже "ВМ" - обведён пунктиром) комплекса и следовательно работать параллельно. Некоторые из ВМ могут иметь специализированные процессоры. Поскольку данные находятся в основном в портах, в том числе портах модулей блок-схем внутри блоков, и иногда в очередях, то особо большой локальной памяти процессорам не потребуется. Несколько сотен ячеек для портов и несколько тысяч для команд (только чтение) и собственно самих данных. Некоторые порты могут быть аппаратными устройствами с прерыванием исполнения программы при изменении состояния. Возможно здесь пригодятся последние разработки IBM Research, позволяющие производить вычисления в ячейках памяти. Желателен кэш для размещения переменных и пр.
Основные же массивы данных должны храниться в унифицированных базах данных. Оптимально, если базы данных будут выполнены как специализированные устройства с идентичным интерфейсом управления и доступом к данным - независимо от структуры и связей конкретных данных. И вот только в этих устройствах, для чтения или записи данных, и для хранения выборок из БД, и нужна многогигабайтная оперативная и многотерабайтная постоянная память.
Даже если программа не занимается обработкой данных из БД, она тем не менее является объектом БД, поскольку именно там должны храниться программы её модулей, инструкции и контекстные подсказки. А по поступившему от пользователя требованию загрузчик разместит её в МКК и запустит в работу.
Кстати, при наличии спецустройства с унифицированной БД, в которой (в метаданных) хранятся также и программы модулей обрабатывающих затребованные данные, отпадает необходимость в использовании привычных файловых систем и привычной же необходимости инсталляции программ.
5.Децентрализованная параллельная потоковая обработка данных
При управлении по данным, работа программных модулей управляется "протоколом движения данных", а не операционной системой, которая совсем не нужна, даже для управления ресурсами.
Очевидно, что если данное отсутствует в каком-либо входном порту, или не взято в обработку следующими блоками из какого-либо выходного порта, то программа в данном блоке не может начать или завершить работу и должна ждать изменения ситуации.
Данное, инициирующее обработку, нумерует очередной кадр потока данных. Если на какой-то вход блока поступает данное из кадра с большим номером, чем обрабатываемый сейчас кадр, то оно помещается в зарезервированную область памяти и его местоположение фиксируется в очереди по порядку номеров кадра. В обработку по ходу алгоритма в блоке забираются данные из очереди только с тем же номером кадра, что и обрабатываемый блоком кадр.
Если в процессе обработки, программе в блоке потребуется обратиться к новому данному, например, обрабатывая документ, понадобиться взять и данные из связанного с ним другого документа, то новое данное связывается с тем же кадром, что и обрабатываемый документ.
Данные между вычислительными модулями передаются по шинам данных. Аппаратные порты используются для обмена данными между ВМ по шинам данных и, возможно иногда, также между программными модулями в одном ВМ. При управлении по данным не важен их источник, так что модуль, устройство или порт, файл или запрос к базе данных, как источники или адресаты данных взаимозаменяемы. Поэтому любая из шин данных может быть "продолжена" любым подходящим устройством связи к другим МКК и иным устройствам.
Перед началом пересылки данных шину следует "захватить", чтобы не было взаимных помех. Обычно захват выполняется методом "взвешивания" адресов устройств, когда право передачи получает тот из претендентов, чей адрес на шине наименьший, но этот процесс занимает как минимум столько тактов, какова разрядность адресов.
Мне довелось заведовать лабораторией системного матобеспечения в филиале Московского специализированного НИИ АН СССР, в котором, до самой "перестройки" приведшей к его ликвидации, разрабатывались алгоритмы параллельных вычислений в децентрализованных мультипроцессорных управляющих системах и сопутствующее "железо". И вот тогда там были разработаны принципы захвата шины за один такт независимо от числа устройств на ней, тем более это можно сделать при современных технологиях. В таком случае, в МКК целесообразно использовать "магистраль" состоящую из множества шин данных и запрос на захват посылать одновременно на все пока как бы свободные в данный момент - какую-нибудь и удастся захватить.
При управлении по данным, работа модулей управляется "протоколом движения данных" (ПДД), а не операционной системой, которая совсем не нужна, даже для управления ресурсами. Все её функции могут исполняются запуском в нужный момент или по ситуации сервисных модулей и посылкой им пакета данных с соответствующими требованиями.
Сервис ПДД запускает программу модуля исполнение, если в его входном порту появилось данное. Результат исполнения программы помещается в его выходной порт и одновременно инициируется работа сервиса ПДД, который по шине данных выставляет "заявку" на передачу в связанный с ним (например, с таким же идентификационным номером) входной порт очередного модуля в другом ВМ. Появление "заявки" инициирует в работу уже местный сервис ПДД, который принимает и размещает в памяти пересылаемый массив данных, а его адрес заносит во входной порт модуля, либо в очередь, если порт занят. Затем в этом ВМ возобновляется исполнение прерванной программы.
Если данные из выходного порта должны передаваться нескольким входным, то в нём должен быть счётчик семафор, который будет сигнализировать, что данный выходной порт занят, пока данные из него не будут переданы всем потребителям. Пример такого порта с именем "n5" на рисунке в гл.4.
В мультипроцессорном комплексе с общей памятью пересылки массива данных не потребовалось бы, но в конечном итоге к каждому его данному было бы выполнено обращение и, быть может, неоднократно. К тому же в схеме с общей памятью одна шина данных, а в МКК их может быть много.
Если оба модуля, отсылающий и принимающий, находятся в одном ВМ, то связанные выходной и входной порты представлены одним объектом, причём передача управления следующему модулю организовывается ещё при их загрузке. Работы сервиса ПДД здесь не требуется.
В принципе, сервис ПДД можно дооснастить сервисом распараллеливания, подгружающим в свободные или малонагруженные ВМ копии программных блоков, во входных портах которых создаются очереди. При оптимальном распараллеливании блоков по ВМ должен получиться конвейер вычислений, когда темп получения кадров результатов на выходе будет успевать за темпом поступления кадров на вход конвейера и очередей не образуется.
6.С чего начать модернизацию цифровизации
Можно, и достаточно легко, занять лидирующую позицию в ИТ, если …
Представлен пошаговый план перехода на прогрессивные технологии потоковой обработки и общего информационного пространства.
Выше описаны не все технологии распределённых вычислений разработанные в вышеупомянутом НИИ и являющиеся тогда секретными, а только самые "очевидные".
Не описан полный алгоритм ПДД и структура унифицированной БД.
Пусть уж взявшиеся за реформацию, которая только и способна вывести ИТ из трясины устоявшихся стереотипов, сами изобретут заново эти технологии и полностью получат все полагающиеся в этом случае "призы". Обнародование всех "Ноу-хау":
во-первых, может дать возможность легко дискредитировать всю идею придравшись, с неких как бы авторитетных позиций, к некоторым не принципиальным недостаткам озвученной конкретной реализации, которые несомненно всегда можно отыскать;
во-вторых, лишить экономических преимуществ и заслуженного профита организацию или фирму, решившихся на разработку "Делового интернета" или мультикомпьютерных комплексов. Опасение такого исхода может снизить их заинтересованность в деле, что не на пользу прогрессу.
Поэтому начинать придётся с разработки унифицированной базы данных. Итак:
Ожидается, что успешность применения УБД в задачах пользователей будет стимулом к выполнению п.8 по разработке аппаратных хранилищ УБД, но к этому моменту уже должен быть выполнен п.7, которому должно предшествовать выполнение пп.5 и 6.
На "Западе" разработки языков функционального программирования пригодных для "крупнозернистой" модели Dataflow были давно сделаны. Но широкого развития направления Dataflow не отмечено. А какой бы смысл, если существующий статус-кво пока всех устраивает?
Можно, и достаточно легко, занять лидирующую позицию в ИТ, если опереться на относительно недорогое "железо" и язык программирования достаточно высокого уровня, чтобы без особых проблем воспроизвести все современные наработки (ОС более не нужна) и навсегда избавиться от информационной зависимости.
7.Как это будет работать
Реализация всех вычислительных процессов в системе в виде блоков связанных передачей данных через порты, обеспечила бы возможность компиляции и включения новой задачи в состав работающей системы обработки данных без потерь данных и заметной остановки - и даже без перепрограммирования действующей части системы.
Важнейшую роль в программировании играет доступность сведений обо всём арсенале средств системных платформ и их использования в аспектах прикладных применений. Сейчас это достигается изучением немалого объёма знаний и приёмов в каждой отрасли деятельности.
Использование унифицированной БД предоставило бы, благодаря классификаторам, метаданным и содержащихся в них описаниям, возможность компетентного выбора модулей адекватных возникшей потребности. Наличие технологической поддержки в виде разработанных CASE-средств позволило бы визуально сконструировать блок-схему программы для решения задачи и её технологическую карту в виде выборок элементов программы из баз данных, включая средства отображения данных и работы с ними.
Вновь созданная программа пополнила бы базу данных средств программирования. А при запуске программы в работу, как и при использовании любой вообще программы, пользователи временно получают специфические средства отображения её данных и управления процессом исполнения. - так что никаких предварительных инсталляций ПО на все случаи жизни не потребуется.
Реализация всех вычислительных процессов в системе в виде блоков связанных передачей данных через порты, обеспечила бы возможность компиляции и включения новой задачи в состав работающей системы обработки данных без потерь данных и заметной остановки - и даже без перепрограммирования действующей части системы. Меняется только схема связей портов. Естественно при наличии у разработчика должных прав. Внесённые изменения в свою очередь должны быть отражены в описаниях (метаданных) действующей обработки.
Кстати, распараллеливание потоков тоже было бы выполнимо "на ходу", без перезагрузки.
А не огорчает их потому, что знание средств и умение преодолевать существующие проблемы в ИТ является специфической сложностью профессиональной деятельности специалистов ИТ и обеспечивает ей высокий статус. К тому же наличие проблем создаёт широкое поле деятельности по разработке средств их преодоления, которые вливаются в объём необходимой компетенции, заставляя специалистов постоянно повышать свой уровень. Сейчас это наиболее востребованный аспект деятельности фирм предлагающих услуги ИТ.
В основе современных информационных технологий (ИТ), как и более полувека назад, лежит стандартная парадигма, по которой, для того чтобы получить результаты вычислений или обработать исходные данных, необходимо запустить на электронной вычислительной машине (ЭВМ) компьютерную программу, которая выполнит ввод исходных данных, обсчитает их, и выдаст результаты на указанное в программе выходное устройство.
Получением доступа к файлам и устройствам, предоставлением и освобождением памяти, управлением очерёдностью и временем исполнения программ - то есть управлением процессами (Controlflow) исполнения задач и распределением затребованных ими ресурсов занимается операционная система (ОС).
Разных моделей ЭВМ (часто секретных) было разработано много, и у каждой свой набор программных кодов. Поэтому озаботились разработкой единого языка высокого уровня. Сначала Фортрана, а потом более продвинутого Алгола. А потом ещё и ещё (сейчас их количество около 30 и увеличивается) - всё более продвинутых, вплоть до языков объектно-ориентированного программирования (ООП), либо и вовсе функциональных.
А в языках ООП важно знать иерархию классов объектов, структуру, свойства и методы объектов - ибо даже одинаковые операторы языка могут работать с объектами по разному. И вот даже зная что надо делать и зная язык - без изучения применяемых в каждой прикладной сфере объектов, вы ничего не сможете.
Тем более, что в разных сферах применения принято использовать разные языки. А для каждой задачи даже в одной отрасли разными разработчиками придумываются разные классы объектов, так что воспользоваться в одной задаче объектами другой, особенно если эти задачи разрабатывались в разных организациях, довольно сложно, ибо требует документированного согласования и может даже совместной разработки средств обмена данными.
Если сравнить программирование с вождением автомобиля, то раньше было везде понятно куда рулить, но в разных автомобилях были разные рычаги и кнопки, хотя на любом можно было ездить в любом городском районе. А теперь в каждом квартале города свои дорожные правила, и в каждом районе надо пересаживаться в другой автомобиль.
Поэтому в области ИТ существует объективная тенденция к монополизации сфер информационной деятельности, где не последнюю роль играют языки, как например 1С, почти безраздельно занявший нишу бухгалтерии. Да и требование установки определённых платформ среды исполнения тоже привязывает к разработчику программного обеспечения (ПО). Если задача губернского или государственного уровня, то применяется и адмресурс, устраняющий независимых разработчиков, хотя сплошь и рядом ПО устанавливаемое "сверху" гораздо хуже.
Как отмечалось, последовательность обработки всех данных задаётся в процессе исполнения главной ведущей программы. При появлении данных нового вида необходимо в ведущей программе обеспечить их создание, условия и способ их использования другими программами.
Даже в масштабах предприятия число классов (таблиц или структур, содержащих данные) бывает до тысяч. Вряд ли там найдутся специалисты, знающие, что, где и как во всех них хранится. Тем более, что на другом предприятии то же самое может быть организовано в других структурах.
В технологиях ООП часто легче добавить новую надстройку над объектами старых классов под новые особенности применения, чем разбираться в алгоритмах методов и структуре данных. И так неоднократно за время эксплуатации ПО. Со временем в базах данных (БД) накапливается «мусор» из забытых уже старых структур, который может быть подхвачен при выполнении запроса.
Конечно технологии развиваются. Разрабатываются системы модификации БД «на лету», протоколы обмена сообщениями, кроссплатформенные магистрали (шины) обмена данными и пр. И все эти средства ПО обновляются по несколько раз за год. В итоге всё больше сил и средств затрачивается только для поддержания систем в работоспособном состоянии, которые становятся всё более монопольными и всё менее обозримыми. По мере прогресса и расширения цифровых технологий все эти проблемы только усугубляются. Вплоть даже до того, что оригинальные исходные коды оказываются погребены под напластованием модернизаций, из-за чего ревизовать и очистить программы от ошибок уже невозможно, ибо слишком дорого. Вот, в частности и об этом, мнение профессионала https://habr.com/ru/post/423889/ Так недалеко и до времени, когда выигрыш от очередного развития ИТ станет меньше, чем затраты на это самое развитие.
В кодировании алгоритма программы проблем нет, особенно если он отображён блок-схемой, а вот с объектами, даже не столько с их придумыванием и созданием, сколько с получением информации об их структуре и свойствах в конкретной прикладной деятельности, о формах их представления - очень серьёзные проблемы, и не всегда "help" поможет. Подытожим вышеуказанные проблемы ИТ.
- Трудоёмкость получения содержательной информации о назначении и атрибутике информационных объектов в предметных отраслях.
- Сложность выполнения обмена данными между прикладными задачами, невозможного без согласований и взаимных действий разработчиков ПО, либо изменений в главной ведущей программе устанавливающей момент и состав обмена.
- Трудоёмкость и рискованность модернизации прикладных задач вследствие наличия в тексте программ описаний и операций с объектами, которые по сути специфичны объектам баз данных и, в принципе, должны бы оперативно редактироваться по мере развития.
- Необходимость, по мере расширения роли автоматизации и усложнения прикладных задач, постоянного изменения главных управляющих программ и модернизации баз данных, для чего требуется постоянное сопровождение продуктов сертифицированными ИТ специалистами.
Причём адекватная новым требованиям кардинальная модернизация структур данных практически невозможна вследствие нереальности изменения запросов в текстах программ прикладных задач у всех пользователей. - Естественная монополизация услуг разработчиками, ибо сторонние и не имеющие сертификата программисты могут не владеть информацией о форматах данных разработчика.
- Разнообразие и увеличение количества языков программирования, что также способствует монополизации своих услуг разработчиками ПО пользующих специфический язык.
- Ненаглядность текстового способа представления алгоритма программы.
Хотя в BPM-системах в программировании бизнес процессов сделан существенный прогресс при переходе к графическому отображению блок-схем обработки документов.
Решить вышеназванные проблемы можно только пересмотром самой парадигмы ИТ. Подобно тому, как в живой природе существует единая технология оперирования генетическим кодом на основе которого формируются популяции животных (как бы "объектов") различных видов, в информационном пространстве должна существовать единая система структурной организации, позволяющая формировать объекты (документы) самого разнообразного вида.
- Должны быть разработаны общеупотребительные единые принципы организации и структурирования данных в базах независимо от специфики прикладных задач.
Любой специалист в своей профессиональной деятельности легко оперирует бумажными документами, а при необходимости заводит новые. Он также может сделать выписки из требуемых сопутствующих документов. Однако в электронном формате для создания новых документов пока необходимо прибегать к услугам программистов или администраторов БД.
Естественно, появились предложения от разработчиков предлагающих пользователям средства лёгкого конструирования БД адекватно своим потребностям и понятиям, что в корне противоречит объективной и насущной общественной необходимости интеграции данных.
Унифицированная БД (УБД) позволит оперировать электронными документами с такой же лёгкостью, как и бумажными, не привлекая ИТ-специалистов. Это возможно потому, что при создании новых документов в УБД не возникает новых сущностных объектов и её структура не изменяется, ибо хранимые в ней данные не распределены по экземплярам документов.
Унификация позволит также на основе локальных УБД создать иерархически организованную глобальную распределённую УБД. Причём для обмена данными между локальными БД не требуется знать их адреса. Достаточно, чтобы каждая локальная БД имела связь только с единственной БД выше неё по иерархии на одну ступеньку. А уже через неё запрос на выборку будет растиражирован в локальных БД, либо отправлен для тиражирования в БД более высокой иерархии и т.д.
В такой унифицированной БД можно было бы хранить произвольного формата любые сведения из энциклопедий и даже актуальные научные статьи, если человечество со временем всё-таки создаст единый научный язык, в котором отношения сведений между собой типа "кто, кого, как, чем, зачем, когда, где, содержит, зависит от, принадлежит к, было, будет, до, после, сейчас, всегда, от … до …, если … то и т.п." были единообразно формализованы в языковых конструкциях или символах отношений, допуская в то же время расширение по мере необходимости спектра учитываемых отношений. Эта УБД могла бы стать актуальной базой знаний, причём она оперативно отражала бы всё богатство взаимных связей и смысловое содержание хранящихся понятий, фактов и данных.
Автором разработаны архитектура и принципы работы такой БД. Некоторые её упрощённые варианты несколько лет эксплуатировалась в системе делопроизводства городской мэрии.
- Для каждого типа данного (вида документа) в УБД должны быть приведены его онтологические характеристики, т.е. назначение и сопутствующее текстовое описание, отношения с другими данными и алгоритм получения нового документа этого типа из данных других документов.
Должна быть описана форма представления типа данного в пользовательском интерфейсе и указан нужный инструментарий.
Нельзя сказать, что этой проблемой не занимаются. Во-первых стандарты XML позволяют характеризовать данные тегами, хоть и в линейных файлах. Есть и более глобальные подходы к проблеме, например, "язык описания онтологий OWL".
Но в унифицированной БД принято более кардинальное решение, так что фактические данные "на лету" группируются в форматах тех или иных документов согласно онтологии в метаданных.
Обработка данных, большей частью состоит в том, чтобы в определённый момент выбрать нужные данные из уже существующих документов и создать новый документ, содержащий результаты обработки. Алгоритм обработки, более чем в 99% ситуаций, заключается в суммировании, вычислении среднего, нахождении максимума или минимума, вычислении статистические отклонений, определении регрессивной функции и т.п. по массиву данных в выборке исходных документов.
Момент обработки наступает, когда созданы и получены все исходные данные, нужные для формирования выходного документа с результатами. В состав исходных данных также могут входить срабатывание сигнального датчика, исполнение оговоренного события (например включение компьютера на рабочем месте специалиста), календарная дата, истечение заданного интервала времени и пр.
Тип требуемых исходных данных, как и способ (алгоритм) их использования, специфицированы в метаданных нового создаваемого документа. В большинстве случаев получение данных нового документа из исходных реализуемо выполнением SQL-запросов. И так, выполняя эстафету последовательного получения очередных новых документов, могут быть в итоге получены все нужные расчётные таблицы, отчёты и справки на рабочих местах каждого специалиста.
Нечто подобное вышеизложенному уже выполняется в BPM-системах управления бизнес-процессами и эффективностью, позволяя перейти от служебных инструкций к автоматическому исполнению и контролю процессов. Но в каждой из таких систем создаются свои объекты в БД со своими специфическими структурами, что, повторюсь, "в корне противоречит объективной и насущной общественной необходимости интеграции данных".
И кроме того, эксплуатация и сопровождение, например, "крутейшей" BPM-системы ELMA, которую автору довелось некоторое время администрировать, требует постоянного участия программиста со знанием языка C#.
3.Использование унифицированных БД уже сейчас может быть полезным и выгодным
Процессы обработки данных должны инициироваться самим фактом появления где бы то ни было необходимых исходных данных, и так поэтапно.
Унифицированные БД (УБД) позволят пользователям, в отличие от существующей практики, самостоятельно конструировать типы выходных документов, создавая требуемые SQL запросы на выборку исходных данных с помощью относительно простого конструктора использующего метаданные исходных документов и их атрибутов. Формируя метаданные нового документа пользователи тем самым опишут и получение данных для его создания. Ввиду унификации структуры БД все SQL запросы строятся по готовым шаблонам. Технология работ по сути ничем не будет отличаться от работы с бумажными документами создаваемыми специалистами по мере необходимости, причём точно такого же формата, как если бы они были бумажными.
В процессе эксплуатации сформированный документ будет создаваться уже автоматически, по мере появления исходных данных. Таким образом, логика цели и смысла обработки данных приводит к тому, что готовность исходных данных должна инициировать и получение результатов, т.е должно выполняться управление по данным (Dataflow).
Благодаря метаданным пользователи смогут обмениваться данными интегрируя их простым формированием документа с SQL-запросами данных из массива документов партнёрской организации, а благодаря встроенным средствам связи по системе иерархий БД, это будет возможно даже в случае их нахождения в различных локальных БД. Понятно, что должна быть разработана система контроля доступа к данным.
Вследствие унификации есть основания предполагать, что учётно-финансовую и управленческую деятельность пользователи смогут автоматизировать по мере потребностей самостоятельно. Пользователи, до нужд которых у крупных ИТ фирм "не доходили руки", или те, кому их услуги были "не по карману", смогут легко автоматизировать свои дела.
Кроме того, каждый может создать личный раздел в унифицированной БД на Web-сервере и, предоставляя доступ другим пользователям по их заявкам к некоторым форматам документов, организовать, например, клуб по интересам с возможностью диалогов в чате. Естественно, все участники должны быть клиентами УБД. Кстати, наличие обмена сообщениями считается полезным и в BPM-системах при проведении конференций.
Таким образом в рамках существующих Web-технологий создаётся сегмент интернет-пространства в котором предприниматели смогут вести полноценный учёт ресурсов и продукции, организовать работу с клиентурой и создать систему управления распределённым предприятием без обращения к профессиональным программистам, а все пользователи получают возможность заниматься организацией быта и общением по интересам. Возможно для этого сегмента будет уместным название "Деловой интернет".
Коммерческий интерес разработчика может осуществляться, например, сдачей в аренду пользователям доступа через интернет к унифицированной БД и средствам управления ею, а также к сервисам ПО. А благодаря унифицированному интерфейсу обмена данными и классификаторам метаданных, разрабатываемые в технологии унифицированных БД "свободными" программистами сервисы смогут получить более широкое поле применения, чем это возможно сейчас ввиду узкой специализации и привязки к платформам.
4.Технология и среда потоковой обработки данных - Dataflow
При поэтапной обработке получение очередных данных могут выполняться асинхронно разными серверами и в разных БД. Наиболее наглядно этапы обработки данных отображаются блок-схемой, модули которой обмениваются данными через порты ввода/вывода.
Итак, ранее сделан вывод, что "готовность исходных данных должна инициировать и получение результатов", т.е должно выполняться управление по данным (Dataflow). В начале 80 х годов были эксперименты (на Западе) создания Dataflow машин, в которых поток данных состоял практически из операндов машинных команд. Однако такие архитектуры оказались неэффективными и к тому же использовали дорогую и медленную ассоциативную память для выбора одновременно обрабатываемых операндов. Поэтому перешли к "крупнозернистым" моделям, где каждый модуль обработки данных представлял собой блок операторов.
Излагаемое в данной статье не является описанием мировых трендов в принципах потоковой обработки, а отражает исключительно авторскую концепцию. Наглядно "крупнозернистая" модель отображается блок-схемой алгоритма программы. Понятно, что алгоритм, исполняемый в каждом блоке, тоже может быть представлен блок-схемой из модулей, выполняющих части алгоритма блока. И т.д., вплоть до машинных команд.
Каждый блок (или модуль) программы выполняет некоторую группу связанных операций над входными данными получая содержательный результат, который используется на следующих этапах обработки в других блоках.
Исходные данные поступают на входные порты (изображены кружочками) блока, а результаты помещаются в выходные порты.
Не связанные на приведенном фрагменте блок-схемы, т.е. свободные, порты отмечены жёлтым цветом. Данные, передающиеся из порта n7 блока B1 в порт n6 того же блока через блок B2, возможно участвуют в некоем цикле или управляемом контуре обратной связи. Или это может быть исполняемая в блоке B1 функция обработки данных, которая таким образом вынесена вовне и может быть подключаема та или иная по выбору. Её выбор или параметры могут управляться через порт B4. В функциональных языках подобные возможности, когда функция указывается (или программируется) в аргументах, называются функциями высшего порядка.
Если вся программа размещена в одной ЭВМ, то связанные выходной и входной порты могут быть представлены одним и тем же объектом. Назовём исполняемый модулем алгоритм функцией, а данное, помещаемое ею в объединённый порт, назовём возвращаемым значением функции. В результате получим программу, где функции связаны друг с другом через возвращаемые значения, так что присваивать переменным какие-либо промежуточные значения для временного хранения нет необходимости.
Полагаю, что вышеописанная модель соединения и работы модулей блок-схемы вполне соответствует концепции функциональных языков программирования. Однако в случае блок-схем целесообразно не ограничиться только одним возвращаемым значением.
Поскольку процесс вычисления управляется передачей данных от блока к блоку, то совершенно не играет роли порядок, в котором алгоритмы каждого блока будут описаны. Существенным является только описание связей выходных и входных портов блоков - от какого и какому передаются данные - и тоже не важен порядок перечисления.
Для того, чтобы получить выходной документ, достаточно, как и в случае "Делового интернета" (см гл.3), просто указать его метаданные в унифицированной БД. В них будет содержаться информация об SQL-запросах исходных данных и программа блок-схемы модулей для формирования требуемого документа. Далее будет вызван загрузчик, который в соответствии с программой разместит в вычислительной сети указанные в программе модули. Поскольку структура и типы данных обрабатываемых каждым модулем описаны в метаданных, то сразу будут сформированы входные и выходные порты, установлены их связи и обеспечены средства транспортировки данных между выходными и входными портами.
После получения нового документа и занесения его в БД проводится "уборка мусора" из памяти, т.е. участки памяти зарезервированной для размещения модулей и данных записываются в список свободной памяти, упорядоченный по их адресам. Смежные участки объединяются в один, а список свободной памяти корректируется. Из этого списка по мере надобности снова выбираются участки для размещения данных и программ.
Архитектура мультикомпьютерного комплекса (МКК) выбиралась по критериям простоты и дешевизны. Блоки программы могут быть размещены в различных вычислительных модулях (на рисунке ниже "ВМ" - обведён пунктиром) комплекса и следовательно работать параллельно. Некоторые из ВМ могут иметь специализированные процессоры. Поскольку данные находятся в основном в портах, в том числе портах модулей блок-схем внутри блоков, и иногда в очередях, то особо большой локальной памяти процессорам не потребуется. Несколько сотен ячеек для портов и несколько тысяч для команд (только чтение) и собственно самих данных. Некоторые порты могут быть аппаратными устройствами с прерыванием исполнения программы при изменении состояния. Возможно здесь пригодятся последние разработки IBM Research, позволяющие производить вычисления в ячейках памяти. Желателен кэш для размещения переменных и пр.
Основные же массивы данных должны храниться в унифицированных базах данных. Оптимально, если базы данных будут выполнены как специализированные устройства с идентичным интерфейсом управления и доступом к данным - независимо от структуры и связей конкретных данных. И вот только в этих устройствах, для чтения или записи данных, и для хранения выборок из БД, и нужна многогигабайтная оперативная и многотерабайтная постоянная память.
Даже если программа не занимается обработкой данных из БД, она тем не менее является объектом БД, поскольку именно там должны храниться программы её модулей, инструкции и контекстные подсказки. А по поступившему от пользователя требованию загрузчик разместит её в МКК и запустит в работу.
Кстати, при наличии спецустройства с унифицированной БД, в которой (в метаданных) хранятся также и программы модулей обрабатывающих затребованные данные, отпадает необходимость в использовании привычных файловых систем и привычной же необходимости инсталляции программ.
5.Децентрализованная параллельная потоковая обработка данных
При управлении по данным, работа программных модулей управляется "протоколом движения данных", а не операционной системой, которая совсем не нужна, даже для управления ресурсами.
Очевидно, что если данное отсутствует в каком-либо входном порту, или не взято в обработку следующими блоками из какого-либо выходного порта, то программа в данном блоке не может начать или завершить работу и должна ждать изменения ситуации.
Данное, инициирующее обработку, нумерует очередной кадр потока данных. Если на какой-то вход блока поступает данное из кадра с большим номером, чем обрабатываемый сейчас кадр, то оно помещается в зарезервированную область памяти и его местоположение фиксируется в очереди по порядку номеров кадра. В обработку по ходу алгоритма в блоке забираются данные из очереди только с тем же номером кадра, что и обрабатываемый блоком кадр.
Если в процессе обработки, программе в блоке потребуется обратиться к новому данному, например, обрабатывая документ, понадобиться взять и данные из связанного с ним другого документа, то новое данное связывается с тем же кадром, что и обрабатываемый документ.
Данные между вычислительными модулями передаются по шинам данных. Аппаратные порты используются для обмена данными между ВМ по шинам данных и, возможно иногда, также между программными модулями в одном ВМ. При управлении по данным не важен их источник, так что модуль, устройство или порт, файл или запрос к базе данных, как источники или адресаты данных взаимозаменяемы. Поэтому любая из шин данных может быть "продолжена" любым подходящим устройством связи к другим МКК и иным устройствам.
Перед началом пересылки данных шину следует "захватить", чтобы не было взаимных помех. Обычно захват выполняется методом "взвешивания" адресов устройств, когда право передачи получает тот из претендентов, чей адрес на шине наименьший, но этот процесс занимает как минимум столько тактов, какова разрядность адресов.
Мне довелось заведовать лабораторией системного матобеспечения в филиале Московского специализированного НИИ АН СССР, в котором, до самой "перестройки" приведшей к его ликвидации, разрабатывались алгоритмы параллельных вычислений в децентрализованных мультипроцессорных управляющих системах и сопутствующее "железо". И вот тогда там были разработаны принципы захвата шины за один такт независимо от числа устройств на ней, тем более это можно сделать при современных технологиях. В таком случае, в МКК целесообразно использовать "магистраль" состоящую из множества шин данных и запрос на захват посылать одновременно на все пока как бы свободные в данный момент - какую-нибудь и удастся захватить.
При управлении по данным, работа модулей управляется "протоколом движения данных" (ПДД), а не операционной системой, которая совсем не нужна, даже для управления ресурсами. Все её функции могут исполняются запуском в нужный момент или по ситуации сервисных модулей и посылкой им пакета данных с соответствующими требованиями.
Сервис ПДД запускает программу модуля исполнение, если в его входном порту появилось данное. Результат исполнения программы помещается в его выходной порт и одновременно инициируется работа сервиса ПДД, который по шине данных выставляет "заявку" на передачу в связанный с ним (например, с таким же идентификационным номером) входной порт очередного модуля в другом ВМ. Появление "заявки" инициирует в работу уже местный сервис ПДД, который принимает и размещает в памяти пересылаемый массив данных, а его адрес заносит во входной порт модуля, либо в очередь, если порт занят. Затем в этом ВМ возобновляется исполнение прерванной программы.
Если данные из выходного порта должны передаваться нескольким входным, то в нём должен быть счётчик семафор, который будет сигнализировать, что данный выходной порт занят, пока данные из него не будут переданы всем потребителям. Пример такого порта с именем "n5" на рисунке в гл.4.
В мультипроцессорном комплексе с общей памятью пересылки массива данных не потребовалось бы, но в конечном итоге к каждому его данному было бы выполнено обращение и, быть может, неоднократно. К тому же в схеме с общей памятью одна шина данных, а в МКК их может быть много.
Если оба модуля, отсылающий и принимающий, находятся в одном ВМ, то связанные выходной и входной порты представлены одним объектом, причём передача управления следующему модулю организовывается ещё при их загрузке. Работы сервиса ПДД здесь не требуется.
В принципе, сервис ПДД можно дооснастить сервисом распараллеливания, подгружающим в свободные или малонагруженные ВМ копии программных блоков, во входных портах которых создаются очереди. При оптимальном распараллеливании блоков по ВМ должен получиться конвейер вычислений, когда темп получения кадров результатов на выходе будет успевать за темпом поступления кадров на вход конвейера и очередей не образуется.
6.С чего начать модернизацию цифровизации
Можно, и достаточно легко, занять лидирующую позицию в ИТ, если …
Представлен пошаговый план перехода на прогрессивные технологии потоковой обработки и общего информационного пространства.
Выше описаны не все технологии распределённых вычислений разработанные в вышеупомянутом НИИ и являющиеся тогда секретными, а только самые "очевидные".
Не описан полный алгоритм ПДД и структура унифицированной БД.
Пусть уж взявшиеся за реформацию, которая только и способна вывести ИТ из трясины устоявшихся стереотипов, сами изобретут заново эти технологии и полностью получат все полагающиеся в этом случае "призы". Обнародование всех "Ноу-хау":
во-первых, может дать возможность легко дискредитировать всю идею придравшись, с неких как бы авторитетных позиций, к некоторым не принципиальным недостаткам озвученной конкретной реализации, которые несомненно всегда можно отыскать;
во-вторых, лишить экономических преимуществ и заслуженного профита организацию или фирму, решившихся на разработку "Делового интернета" или мультикомпьютерных комплексов. Опасение такого исхода может снизить их заинтересованность в деле, что не на пользу прогрессу.
Поэтому начинать придётся с разработки унифицированной базы данных. Итак:
- Разработать единую структуру унифицированной базы данных (УБД), пригодную для хранения любых данных в их взаимосвязи, включая описания метаданных.
- Разработать модель унифицированной БД в рамках существующих Web-технологий и реляционных баз данных.
- Разработать систему иерархической организации БД и технологию транзакций для обеспечения обмена данными и их интеграции.
- Начать пересохранение своих данных в формат унифицированной БД. Сначала это будет делаться в индивидуальном порядке, что откроет каждому перспективы дальнейшего прогресса. Затем появятся и отработанные стандартные технологии перехода. Госструктуры, можно предположить, останутся в аутсайдерах, зато подрядные ИТ фирмы, не исключено, станут использовать унифицированные БД.
- Разработать эффективный алгоритм протокола движения данных (ПДД).
- Разработать язык программирования параллельных вычислений управляемых потоками данных и компилятор.
- Разработать технологии создания и хранения библиотечных программных модулей в хранилищах данных, компиляции и загрузки в вычислительные блоки.
- Разработать и начать производить электронные устройства хранилищ баз данных с унифицированным интерфейсом согласно п.3.
- Начать производить мультикопьютерные системы с мультишинными магистралями данных и электронными портами обмена данными, с хранилищем БД заменяющим также файловую систему.
Ожидается, что успешность применения УБД в задачах пользователей будет стимулом к выполнению п.8 по разработке аппаратных хранилищ УБД, но к этому моменту уже должен быть выполнен п.7, которому должно предшествовать выполнение пп.5 и 6.
На "Западе" разработки языков функционального программирования пригодных для "крупнозернистой" модели Dataflow были давно сделаны. Но широкого развития направления Dataflow не отмечено. А какой бы смысл, если существующий статус-кво пока всех устраивает?
Можно, и достаточно легко, занять лидирующую позицию в ИТ, если опереться на относительно недорогое "железо" и язык программирования достаточно высокого уровня, чтобы без особых проблем воспроизвести все современные наработки (ОС более не нужна) и навсегда избавиться от информационной зависимости.
7.Как это будет работать
Реализация всех вычислительных процессов в системе в виде блоков связанных передачей данных через порты, обеспечила бы возможность компиляции и включения новой задачи в состав работающей системы обработки данных без потерь данных и заметной остановки - и даже без перепрограммирования действующей части системы.
Важнейшую роль в программировании играет доступность сведений обо всём арсенале средств системных платформ и их использования в аспектах прикладных применений. Сейчас это достигается изучением немалого объёма знаний и приёмов в каждой отрасли деятельности.
Использование унифицированной БД предоставило бы, благодаря классификаторам, метаданным и содержащихся в них описаниям, возможность компетентного выбора модулей адекватных возникшей потребности. Наличие технологической поддержки в виде разработанных CASE-средств позволило бы визуально сконструировать блок-схему программы для решения задачи и её технологическую карту в виде выборок элементов программы из баз данных, включая средства отображения данных и работы с ними.
Вновь созданная программа пополнила бы базу данных средств программирования. А при запуске программы в работу, как и при использовании любой вообще программы, пользователи временно получают специфические средства отображения её данных и управления процессом исполнения. - так что никаких предварительных инсталляций ПО на все случаи жизни не потребуется.
Реализация всех вычислительных процессов в системе в виде блоков связанных передачей данных через порты, обеспечила бы возможность компиляции и включения новой задачи в состав работающей системы обработки данных без потерь данных и заметной остановки - и даже без перепрограммирования действующей части системы. Меняется только схема связей портов. Естественно при наличии у разработчика должных прав. Внесённые изменения в свою очередь должны быть отражены в описаниях (метаданных) действующей обработки.
Кстати, распараллеливание потоков тоже было бы выполнимо "на ходу", без перезагрузки.