Прочитал в "Компьютерре" #13 [633] статью Александра Петриковского (e-mail) "Субъектное программирование" - заинтересовало. Предлагаю обсудить данное направление - насколько оно перспективно и вообще правильно ли все это?




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


В наши дни все большее распространение находят приложения, которые способны самостоятельно решать многовариантные задачи. Например, многие слышали о спулере* печати - сервисной программе операционной системы, которая получает задание вывести документ на печать. Программе самой приходится опрашивать принтер, выяснять его готовность, отправлять документ на печать, а в случае занятости принтера ставить документ в очередь и т. д. Потребность в таких «умных» приложениях растет. Если раньше текстовый редактор представлял собой одну большую программу, то теперь в нем параллельно работают несколько процессов, каждый из которых выполняет специально отведенную ему роль. Например: форматирование, проверка орфографии, автоматическое сохранение документа.
Подобные приложения в современной многозадачной операционной системе исчисляются десятками. Поэтому координация их действий с ростом сложности систем превращается в непростую задачу. Здесь просматриваются два пути решения проблемы. Первый — увеличивать интеллектуальные возможности «координатора», чтобы он успевал управлять работой приложений. Второй - заставить «поумнеть» приложения, избавляя «координатора» от управленческой рутины. Первый путь имеет свой логический предел, так как напоминает растущее государство, в котором король лично управляет каждым своим подданным. Поэтому развитие информационных систем в основном идет по второму пути. Однако здесь тоже есть трудности, вызванные несовершенством методологии разработки таких приложений.
Программисту все труднее использовать результаты ранее разработанного программного кода в последующем, а при написании высокоинтеллектуальной программы процесс усложняется еще из-за большого количества программных модулей и достаточно сложных алгоритмов их взаимодействия. Все это неизбежно приводит к удорожанию разработки.
Тут-то и выходит на сцену новая технология - субъектное программирование. С ее помощью можно создать базу для развития более совершенной методологии разработки.
Итак, Субъектом называется приложение, способное в рамках системы самостоятельно реализовывать задачу, имеющую несколько путей решения. В отличие от «неразумного» Объекта, Субъект наделен возможностью выбирать этот путь, то есть он способен сам корректировать последовательности своих действий для достижения поставленной цели (как, например, делается при печати документа в спулере).
Стратегия управления такими приложениями должна основываться не на четких и конкретных командах операционной системы, а на «инструкциях». Управляя Объектом, мы используем отдельные его части (методы), а Субъекту достаточно указать «номер» инструкции, на основании которой он функционирует. И он уже сам будет управлять своими методами, чтобы достичь результата (рис. 1).

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

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

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

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

• свойства - как описание характеристик объекта;
• способности - как описание действий с объектом;
• правила наследования свойств и способностей объекта.

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

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

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

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

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

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

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

----
* Знаете ли вы, что слово «spooler» образовано от сокращения SPOOL (кроме того, spool по-английски катушка, шпулька). Simultaneous Peripheral Operations On Line, то есть одновременная оперативная обработка запросов к периферийным устройствам. - Здесь и далее др." Константина Курбатова.

** В данном случае «свободным» кодом называется не-стандартизированный код, который программист пишет заново для каждого экземпляра объекта.

*** Школа по теории дискретных устройств была организована членом-корреспондентом АН СССР Михаилом Александровичем Гавриловым в конце 1960-х годов.


Это сообщение отредактировал(а) rsm - 10.4.2006, 14:58

Прочитал статью но не нашел смысла выносить это в стандартный синтаксис "роли" (по сути CASE-случаи).
Тем более что такое разделение как он говорит может и оправдано "самостоятельностью" но чаще нужен именно жесткий контроль.
А там где не нужен - и сейчас пишут модуль который читает ну допустим флажок из основного модуля и делает что надо. Это не ново.
Но зачем придумывать название... Позёрство?

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

Ну почему же
Есть case '...' а есть default
Добавлено @ 17:27
В общем мое имхо - там где это надо это уже и так делают не называя красивыми словами

Хороший подход


Это не следствие идеологии ООП, а обычные косяки проектирования. То же касается и внешних воздействий 

По-моему, это описание классической компонентной модели. Возможно, компоненты здесь "утяжелены", но не более того.  

Это сообщение отредактировал(а) Lamer George - 12.5.2006, 08:27

Можно вообще сказать, что это ООП, просто несколько своеобразная оргшанизация  

Сейчас скажу глупость  А что такое класс, как не расширенное понятие "записи"(добавили указатели на свойства и организовали неявную передачу self в качестве параметра), которая в свою очередь представляет собой линейную структуру, до боли похожую на массив(только с именованным доступом к частям)? Выходит, ООП, как "революция" или "нововведение" - это тоже миф?   

Это сообщение отредактировал(а) skyboy - 18.5.2006, 02:19

skyboy, думаю, даже при намеренном упрощении это неверно.
Класс — это расширяемый абстрактный тип данных.
Для объекта (экземпляра класса) определяющим является поведение. А для значения типа записи — содержание.

А вот принципиальные отличия субъекта, как он описывается в статье, от объекта или компонента лично для меня под вопросом. 

Void, пытаюсь увидеть аналогию "сенсоров" с обработкой сообщений в Windows: сообщение пришло, а мы как хотим - так и обрабатываем. Или не обрабатываем. 
Скорее всего, я неправильно понимаю суть, но, имхо, вследствии "параноидального" применения инкапсуляции в ООП, у объекта должны остаться доступными только методы, а поля должны быть скрытыми для обработки(я не против концепции ООП - я имел в виду "крайний случай" применения). Для приведенной концепции, как я понял, наоборот - открыт определённый список полей("сенсоры") и один-единственный метод "Обновить", который выносит решение об применении тех или иных приватных методов ввиду значений "сенсоров". Конечно, объект остался объектом, вне зависимости от количества доступных методов, но концепция проектирования изменится.
Это то, как я это увидел. Достоинств/недостатков в общем виде мне не видать. Возможно, для конкретной задачи(например, взаимодействие параллёльных потоков) этот подход будет лучше, чем работа с методами.   
 

Это сообщение отредактировал(а) skyboy - 18.5.2006, 02:31

Довольно интересное описание несколько подзабытой технологии.

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

BBTech  

Это сообщение отредактировал(а) svg - 18.5.2006, 18:12