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

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

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

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

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

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

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

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

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

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

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

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

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

Следует отметить, что роли могут модифицироваться разработчиком каждого отдельного приложения. Если потребуется сертификация некой линии поведения, то здесь возможно использование уникального ключа (Unique ID, UID). Это позволяет создавать пользовательские «коллекции» ролей, которые потом можно применять и в чужих программных проектах. Дабы обеспечить возможность повторного использования соответствующих ролей в описании Субъекта, формируется специальный раздел, который служит основой для сборки секций ролей в приложении (где можно указывать UID ролей из библиотек). В нем должна находиться информация о том, какому значению состояния соответствует данная роль, а также сведения о задержках переключения алгоритмов.

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

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

Блок формирования состояния может понадобиться тогда, когда логика выбора состояния будет достаточно сложна (либо требуется наличие временных функций — задержек). И здесь самым подходящим языком описания алгоритма формирования состояния может служить язык из стандарта IEC 61131-3, применяемый в некоторых контроллерах. Например, для удобства описания интерфейсов СОМ-объектов был даже создан свой язык — Interface Definition Language. Однако этот момент является только предположением, поэтому говорить о нем пока рано. А вот без создания нового краткого «языка общения» между различными Субъектами, возможно, не обойтись.

Действительно, Субъектам достаточно обмениваться сообщениями о состояниях, а не сериями команд управления, как принято при управлении Объектами.

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

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

в каждом Субъекте должен присутствовать как минимум один «счетчик жизни»;

в каждом Субъекте должны присутствовать роли запуска и завершения работы приложения;

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

алгоритм выполнения той или иной последовательности действий (роли) не должен быть вшит или «размазан» по программному коду, он должен иметь вид отдельной структурной секции программы;

вызов отдельных методов Субъекта извне допускается, но нежелателен;

в каждом Субъекте должен быть предусмотрен интерфейс обмена информацией с другими Субъектами системы;

все роли Субъекта должны быть подробно документированы в секции описания ролей.

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

А для разработки систем, состоящих из множества приложений (от нескольких десятков до тысяч), технология субъектно-ориентированного программирования должна стать основополагающей, и кто знает, может быть, она заложит основу для следующего шага в программировании — создания сложных самоорганизующихся интеллектуальных систем!

Любопытно, что упоминаемая в статье switch-технология предложена российским ученым, представителем Гавриловской школы[ Школа по теории дискретных устройств была организована членом-корреспондентом АН СССР Михаилом Александровичем Гавриловым в конце 1960-х годов] А. А. Шалыто. Она основана на применении в программировании идей теории систем управления. Автор первоначально предложил ее для алгоритмизации и программирования систем логического управления, в которых ввод входных воздействий выполняется по опросу (как, например, в программируемых логических контроллерах и других подобных задачах).