Журнал «Компьютерра» № 13 от 04 апреля 2006 года

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

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

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

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

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

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

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

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

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

2. Субъект имеет органы осязания в виде сенсоров. Сенсоры следят за состоянием внешней и внутренней среды Субъекта. На основании анализа этих состояний Субъект выбирает ту или иную линию поведения.

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

4. С роли на роль Субъект переключается самостоятельно исходя из анализа состояния системы.