В статье сформулированы проблемы и подходы к их решению, которые могут быть интересны разработчикам архитектур вычислительных систем, разработчикам систем и языков программирования. Но, как правило, они уверены (правду сказать, не все ) в совершенстве используемых ими технологий – а следовательно вряд ли заинтересуются. Но лет эдак через 20-25 жизнь, хотя бы «методом тыка», заставит начать реализовывать нижеизложенное. У прочитавших и запомнивших будет преимущество. А может пойдут другим путём? Вот этого не надо, ибо зря – эволюция Жизни однозначно показывает, какой путь является оптимальным, ведь выбранная ею информационная технология (IT) используется от формирования одноклеточных и до управления поведением сообществ. Поэтому целесообразно позаимствовать эти технологии у Жизни и внедрить их в нашу жизнь и технику. Об этом чуть позже.
Ни экономика, ни социальные коммуникации уже невозможны без использования развитых информационных технологий. Вот и рассмотрим, почему используемые сейчас технологии далее не годны. Идеи, определяющие архитектуру компьютеров, практически не изменились со времен фон Неймана. В основе находится алгоритм, в процессе исполнения последовательности команд которого данные подвергаются обработке. Следовательно, главными субъектами являются процессы (Controlflow), которым и предоставляются (согласно приоритетам и иерархии) вычислительные ресурсы под управлением операционной системы (ОС).
Последовательность и зависимость процессов обработки всех данных в совокупности описываются в центральной (ведущей) программе, и, при создании нового вида данных, необходимо в ведущей программе предусмотреть и запуск алгоритма их своевременной генерации, и организовать моменты и способ их использования («рандеву») с другими программами. Но для этого надо ещё согласовать структуры данных, которые следует выяснить у разработчика (не без коммерческого интереса последнего). А если совокупности данных, ранее обрабатываемых независимыми ведущими процессами, по логике развития интеграции начнут пересекаться, то потребуется разработка нового ведущего процесса, интегрирующего прежде независимые программы.
Вот всё это и происходит непрерывно по мере прогресса и развития цифровых технологий. И соответственно, всё больше сил и средств требуется только для поддержания систем в работоспособном состоянии, которые становятся всё более монопольными и всё менее обозримыми. Даже в масштабах предприятия количество различных классов данных (таблиц или структур, содержащих данные) достигает сотен и тысяч. Вряд ли где есть специалисты, которые в целом представляли бы, что, собственно, в них всех хранится. Бывает, что по мере развития систем обработки в базах данных (БД) накапливается «мусор» из данных в старых структурах, не участвующих уже в новых алгоритмах обработки, но он может быть «подхвачен» при формировании запроса на данные.
В используемых технологиях объектного программирования, чем разбираться в действующих алгоритмах методов и структуре данных, часто легче добавить новую надстройку над старыми под новые особенности применения. И так много раз. Нетрудно сообразить, что это тупиковый путь.
Конечно, выходы из тупика ищут и находят. Это и системы модификации БД «на лету», и протоколы обмена сообщениями, и кроссплатформенные магистрали (шины) обмена данными и пр. И все эти технологии и платформы средств программного обеспечения обновляются иногда по несколько раз в месяц. Но если так будет продолжаться и дальше, то выигрыш от очередного развития ИТ станет меньше, чем затраты на это самое развитие. В тупик ИТ нацелились по следующим причинам:
- во-первых, это принципиальная нелокальность модификаций алгоритмов присущая собственно процессному управлению;
- во-вторых, отсутствие универсальной БД, в которой можно было бы одинаковым образом и без модификаций структуры хранить любые данные при всём их многообразии и многоаспектности взаимосвязей;
- в-третьих, отсутствие онтологического описания данных, (то есть их содержательного смысла и области применения), обеспечивающего их автоматическое включение в процесс обработки;
- и, наконец, ещё и по причине недостаточной наглядности языков программирования. Правда, в программировании бизнес процессов сделан существенный прогресс при переходе к отображению блок-схем.
А сейчас вернёмся к информационным технологиям живого. Ранее была высказана и обоснована гипотеза (см. статью «Идеи правят миром» ), что движение вещественной материи и, естественно, в том числе формирование и движение биоструктур и биоорганизмов, управляется сочетанием, конфигурацией, полей напряжений и деформаций Мирового эфира в пространстве, окружающем вещественный объект. Конфигурации полей, ответственных за формирование и движение биоструктур и биоорганизмов, по устоявшейся традиции назовём эгрегоры.
Эгрегоры можно рассматривать как программные модули обработки данных, представленных организмами и биоструктурами, строение (состав и конфигурация) которых описываются на едином для всех принципе организации согласно генетическому коду. По мере развития и возникновения новых органов подключаются и адекватные эгрегоры, либо начинается эволюционный процесс их создания (изобретения). Роль записи и хранения данных в «памяти компьютера» выполняет вещественное представление (создание и существование) биоформ в реальном мире.
Фактически мы наблюдаем кибернетическую систему обработки с управлением по данным, которая может обойтись без центрального ведущего процесса, требующего раз и навсегда запрограммированного алгоритма. То есть эволюция живого не основывается на исполнении главной центральной программы, которую в этом рассмотрении следовало бы назвать «Богом». Но есть правила формирования эгрегоров приводящие к перегруппировке и интеграции данных (биоструктур и организмов) в реале, а затем пропускающие их через фильтр естественного отбора, определяя тем самым направление и прогресс эволюции живого.
Эти диалектические правила разделения и объединения претендуют называться «божественным замыслом», ибо случайным образом получить работающую конструкцию, например, рибосомы, за время существования нашей вселенной крайне невероятно (см. статью «Вирусы – «враг» необходимый для жизни?»). Тупое настояние на неизбежности самозарождения жизни на Земле по сути ничем не лучше веры в её божественное происхождение и поэтому не научно. По крайней мере пока не будет подтверждено экспериментально в осуществимых в естественной среде условиях.
Единственной на сегодняшний момент научно обоснованной гипотезой о появлении жизни и разума является предположение об их появлении в одной из бесконечного ряда предшествующих вселенных, а затем сознательные действия по организации появления жизни в новой вселенной, каковые только и могут составить цель и смысл существования всякой разумной цивилизации. Причём независимо от наличия или отсутствия возможности самозарождения. И так должно поступать, и видимо поступает, каждое поколение вселенских цивилизаций, чему доказательством служит наше существование. (см. статью «Мир и Разум»). Использование технологий управления по данным в живом доказывается ещё и наблюдениями:
В результате совокупного действия всех факторов при формировании клеточных структур получаем результат, например, как на фото ниже. Наличие нового данного в виде свадебной раскраски предполагает начало нового цикла.
Если нам необходимо построить эволюционирующий живой и привлекательный общественный организм и адекватную ему экономику, что уже невозможно без информационных технологий, то и организовывать их целесообразно аналогично живому. Следовательно:
- Должны быть разработаны единые принципы организации и структурирования данных в базах, что позволит всем хранить данные единообразно и вводить их с помощью единого интерфейса, независимо от специфики прикладных задач.
Данные должны быть организованы и по сетевой, а не только по древовидной структуре, что на практике позволит в каждой отрасли обеспечить наиболее короткий путь доступа к актуальным в ней данным. Глобальная распределённая БД должна представлять собой конгломерат иерархически организованных БД, построенных по единому принципу.
И если человечество когда-нибудь договорится создать международный научный язык, в котором отношения «кто (что), кого (что), принадлежит, входит, нет, когда, было, будет, до, после, сейчас, всегда, где, от … до, если … то, чем, как, зачем и т.п.» были бы явно и однозначно представлены языковыми конструкциями и/или знаками отношений, то научные статьи можно было бы непосредственно загружать в эту базу знаний, причём с возможностью использования смыслового содержания.
Архитектура и принципы работы такой БД разработаны. Некоторые её варианты были внедрены и в течении нескольких лет использовались без нареканий в системе делопроизводства мэрии города с почти миллионным населением.
- Для каждого типа данного должны быть указаны его назначение, связь с другими данными и алгоритм его получения из ранее полученных (или вычисленных) данных. Аналогично, должна быть описана форма их представления в типовом пользовательском интерфейсе и указан сопутствующий инструментарий. Эти характеристики и средства, называемые метаданными, тоже являются обыкновенными данными и, следовательно, должны содержаться в базе данных. По крайней мере в той БД, где они понадобились, если не представлены в БД более высокого уровня.
Метаданные служат для указания потенциального существования и обеспечения выбора существующих данных соответственно их смысловому значению. Локальные метаданные должны быть при возможности сопоставлены метаданным в классификаторе БД более высокой иерархии.
- Должны выполняться потоковые вычисления по технологии Dataflow, то есть осуществляться управление по данным. Новые данные должны вычисляться в соответствии с заданным для них алгоритмом, как только появятся необходимые для этого исходные данные. Вычисления должны выполняться в сети децентрализованно и параллельно.
Обработка данных состоит в том, чтобы записать в БД новые данные, вычисленные согласно сопоставленному им алгоритму по выборке отвечающих условию задания ранее вычисленных или введённых данных. Новые данные будут получены, как только сформируется необходимая для этого выборка – и так по всей сети распределённой БД.
Всё «программирование» сводится к описанию в метаданных новых данных с их атрибутами (в том числе правами доступа), связями, характеристиками отображения в пользовательском интерфейсе (если надо), указанию условий для атрибутов исходных данных, значениями которых определяется их вхождение в выборку, и заданию алгоритма обработки. Алгоритм, более чем в 99% ситуаций, сводится к указанию, что следует выполнить с данными выборки из ряда: просуммировать, вычислить среднее, найти максимум или минимум, определить статистические отклонения, вычислить регрессивную функцию и т.п. по массиву указанной выборки. И для этого обычно не нужно привлекать профессиональных программистов. Разве иногда и лишь для конкретной задачи.
Таким образом, за малыми исключениями, весь объём задач информатизации может создаваться специалистами прикладных отраслей без привлечения профессиональных программистов. Данные, с которыми они имеют дело, описываются этими же специалистами в метаданных самостоятельно (если там нет аналога) и по содержанию, назначению и образу могут копировать привычные им бумажные документы. Простого дизайнерского конструктора будет достаточно. Любой документ будет не просто текстовым файлом, а объединением сведений из БД, обеспеченными также инструментарием для их представления и работы с ними, указанным в метаданных.
Сейчас для обеспечения таких возможностей постоянно расширяют функционал браузеров, добавляя флэш-проигрыватели, опции на джава-скрипт, вводя новые теги, web-сервисы и т.д. Метаданные позволили бы организовать, локализовать и упорядочить эти процессы.
Перечисленных возможностей уже достаточно, чтобы каждый мог самостоятельно создать полноценную систему управления, учёта ресурсов, продукции и клиентуры распределённого предприятия. Практически теми же средствами может быть организована и создана «социальная сеть» в рамках отдела, предприятия и, далее, везде. Но владелец своего узла будет обладать в нём естественными «админскими» правами в части дизайна и регулирования прав доступа.
Для получения новых данных (документов), пользователю достаточно описать их в метаданных, указав параметры для их получения (выборки) из ранее описанных данных, включая условия их получения (ситуации, параметры обстановки, периодичность и пр. – это тоже просто исходные данные). Описание нового данного должно содержать в качестве параметров (т.е. просто данных) указание адресата (инстанцию или ролевую функцию рассмотрения этих данных) и атрибуты обработки (принять, отказать (указать адресат уведомления об отказе), вернуть на доработку (указать адресат кому) или иное и пр., и т.п.) с указанием срока или даты исполнения (указать адресат уведомления о просрочке). Возможно потребуется указать новые значения атрибутов состояния документа в зависимости от результатов рассмотрения. Уничтожение отработанных выборок данных (документов) выполняется по требуемому сочетанию атрибутов состояния документа.
После этого новые данные станут автоматически формироваться во всех подведомственных отделениях распределённой базы данных и своевременно передаваться на указанные инстанции. Последовательность действий указывать не надо (т.е. не надо писать программный код), так как при управлении по данным очередные действия выполняются по факту наличия нужных для этого данных. Например, к главбуху будут приходить от директора документы только с отмеченным атрибутом «Оплатить». Но если потребуется ввести перед оплатой проверку документов, допустим, юристом, то в документ нужно будет добавить параметр «отказать» и параметр «к оплате», в котором галочку ставит директор, благодаря чему документ попадёт к юристу. Галочку в атрибуте «оплатить», либо «отказать», проставит уже юрист.
И всегда можно организовать получение нового произвольного документа (набора данных) без редактирования действующих уже алгоритмов функционирования всей системы, поскольку одни и те же данные распределённой БД, по факту своего существования, могут участвовать во множестве разнообразных алгоритмов получения новых документов по нужным выборкам.
Для осуществления интегрального учёта товарооборота, например, описываемого в статье «“Капитал” Маркса – все тома на 2-х страничках» предприятиям, при управлении по данным и реализации унифицированной распределённой БД, даже никуда не надо будет отсылать свои отчёты – достаточно просто начать функционировать. Появляющиеся данные будут подхвачены и учтены автоматически.
Разработчики, занимающиеся автоматизацией применительно к бизнес-процессам, могут указать, что все эти возможности уже давно реализованы в специфике BPM-систем. Например, в одной из наиболее мощных из них «ELMA». Но, увы, чтобы эта система заработала, в штате компании должен состоять программист хорошо владеющий языком программирования "Си-шарп". Автору довелось поучаствовать в администрировании этой системы. Либо приходится менять свои структуры и бизнес-процедуры под предлагаемые шаблоны. Но такой подход ничем не отличается от обычной практики приобретения прикладных приложений со всеми проблемами их адаптации и интеграции.
Об архитектурах и способах реализации систем управления по данным, о языке программирования параллельной обработки смотрите в следующих публикациях.
