Хотя постойте… может быть, оттого я и выучил семь языков, что не было у меня в детстве никаких компьютеров и подавно – Amazing Slow Downer? Эх, старость, старость…

Линки на программы, помянутые в «Голубятне» – на домашней странице internettrading.net/guru.

Автор: Александр Петриковский

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

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

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

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

С расширением сферы применения программирования и особенно с развитием графических возможностей компьютеров появилась необходимость работать с большим количеством объектов, которые помимо свойств должны описываться рядом характерных действий. Аналогично набору свойств объекта, объединяемых рамками абстрактного понятия структуры, напрашивалось дальнейшее дополнение этого объединения набором действий – «методов». Это объединение уже представляло собой новую структуру данных – класс. Если структуру объекта можно сравнивать с его чертежом, то класс представляет собой уже некий рабочий механизм с органами управления. Этот подход позволил «конструировать» приложения из множества стандартных узлов, добавляя к ним детали и органы управления. В результате появилось целое направление – объектно-ориентированное программирование (ООП).

Нет смысла описывать все достоинства ООП, но главное достижение этого «изобретения» заключается в том, что оно приблизило представление о программе как о модели некоторого реального процесса реальной части мира!

Таким образом, все нововведения, появившиеся в свое время в технологии программирования, поддерживают одну и ту же стратегическую линию развития – совершенствование понятийного инструментария программирования.

В наши дни все большее распространение находят приложения, которые способны самостоятельно решать многовариантные задачи. Например, многие слышали о спулере[Знаете ли вы, что слово «spooler» образовано от сокращения SPOOL (кроме того, spool по-английски – катушка, шпулька), Simultaneous Peripheral Operations On Line, то есть одновременная оперативная обработка запросов к периферийным устройствам. – Здесь и далее примечания Константина Курбатова] печати – сервисной программе операционной системы, которая получает задание вывести документ на печать. Программе самой приходится опрашивать принтер, выяснять его готовность, отправлять документ на печать, а в случае занятости принтера ставить документ в очередь и т. д. Потребность в таких «умных» приложениях растет. Если раньше текстовый редактор представлял собой одну большую программу, то теперь в нем параллельно работают несколько процессов, каждый из которых выполняет специально отведенную ему роль. Например: форматирование, проверка орфографии, автоматическое сохранение документа.

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

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

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

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

Стратегия управления такими приложениями должна основываться не на четких и конкретных командах операционной системы, а на «инструкциях». Управляя Объектом, мы используем отдельные его части (методы), а Субъекту достаточно указать «номер» инструкции, на основании которой он функционирует. И он уже сам будет управлять своими методами, чтобы достичь результата (рис. 1).

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

То есть (возвращаясь к программированию) становится очевидным, что для эффективной разработки сложных интеллектуальных систем необходимо опираться на элементы, обладающие достаточной самостоятельностью. Как же должен быть устроен Субъект, чтобы реализовать все эти возможности? В первую очередь нужно формализовать на уровне системы существенные особенности такого элемента, а именно:

1. Субъект живет самостоятельной жизнью. Его сердцем является таймер, который как бы «питает» Субъект машинным временем операционной системы.