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

На самом деле платформа для этого подхода в архитектуре систем подготавливалась на протяжении последних десяти-пятнадцати лет.

Некий прообраз описания Субъекта мы уже имеем, создавая AciveX (COM+) объекты; они могут загружаться в память системы и работать как вполне самостоятельные модули. Здесь в качестве связей с внешним миром используются интерфейсы, которые фактически являются сенсорами. С другой стороны, «магические» свойства операторов переключателей (case и switch) подвигли постановщиков задач для систем автоматического управления на разработку особой методологии программирования – switch-технологии, или автоматного программирования. Эта методология основывается на выделении состояний объекта, что позволяет приблизиться к формализации описания алгоритма программы. Дальше всех продвинулись в управлении объектами, которые по функциональному исполнению вполне подходят на роль Субъектов, разработчики анимационной графики и компьютерных игр.

Таким образом, на сегодняшний день имеется достаточно предпосылок, чтобы попытаться решить задачу формализации описания программного элемента – Субъекта.

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

Не случайно первыми объектами, хорошо приспосабливающимися к среде обитания, были компьютерные вирусы, чье поведение очень похоже на поведение их «собратьев» из реальной жизни, а именно:

внедриться в тело программы и использовать для «питания» ее машинное время;

скрытно размножиться;

выполнять деструктивные действия в зараженных системах.

Такие «организмы» прекрасно себя чувствовали даже в однозадачной среде под DOS.

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

Спор хозяйствующих субъектов…

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

Очевидно, что для стандартизации желательно применять такой способ решения задачи описания Субъектов, который был бы уже заложен в основу компилятора языка программирования. В качестве каркаса, на котором формируется структура Субъекта, можно использовать привычную структуру класса, просто введя в нее дополнительные понятия. Как известно, в описании класса в ООП обычно заложены следующие категории:

свойства – как описание характеристик объекта;

способности – как описание действий с объектом;

правила наследования свойств и способностей объекта.

Остается дополнить объект новыми элементами, относящимися к функциональности Субъекта:

активность – как описание частоты активизации объекта с помощью внешнего или внутреннего таймера;

контроль состояния – как описание сенсоров, которые ответственны за перевод Субъекта из одного состояния в другое;

линии поведения – как описания ролей, исполняемых Субъектом.

Обычно линии поведения уже присутствуют в программе, но они не всегда логически выделяются и структурируются разработчиком.

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

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

Что наша жизнь? Игра…