В порыве отчаяния фанаты метнулись к пиндосским хозяевам. Бинго! Перетёр напрямую завершился победным конструктивом: прошивка готова, наводим последний марафет, не сегодня-завтра — будьте любезны! Победный конструктив головной конторы HP равно понятен, как и «холодное плечо»[Популярное выражение «To Give The Cold Shoulder» пошло от старинной англо-саксонской традиции подавать неуважаемому гостю на ужин тощее крылышко неподогретой индейки] россиянского подотдела: Пиндустан — государство, заточенное под малый и средний бизнес, потому и внимание к Акакиям Акакиевичам из SoHo неподдельное. Это при том, что HP официально заявила о скором сворачивании разработок чистых КПК с последующим переметом в лагерь смартфонов и коммуникаторов.
Три недели фебрильного ожидания — и вот оно долгожданное: в бакунианский оборот забросили не только копии оригинальных дисков с Windows Mobile 2005 для iPAQ 4700, но и облегченный загружаемый вариант (всего 34 Мбайт — операционная система за вычетом нового Outlook’a). И понеслось: бесшабашные первопроходцы без оглядки на последствия ринулись перепрошивать свои наладонники, чтобы уже через час выстроиться в длинную очередь недоумения и отчаяния: ActiveSync 4.1 напрочь отказывается соединяться с КПК, половина привычных программ сторонних разработчиков под WM2005 не запускается, глюки с Wi-Fi при перезагрузке, потеря данных из-за неумения обращаться с принципиально новой типологией памяти (если после изменения настроек в программах наладонник не выключить и затем снова не включить, при последующем софт-ресете все изменения исчезают), а главное — под WM2005 iPAQ 4700 стал тормозить просто до неприличия: запуск программ — от 20 до 45 секунд, закрывание — почти столько же! Единственный, сходу бросающийся в глаза выигрыш после апгрейда: исчезла возмутительная утечка памяти под Windows Mobile 2003 SE, вынуждавшая как минимум раз в день производить софт-ресет наладонника. Утечка эта, кстати, была характерна исключительно для iPAQ 4700 и у конкурентов (Dell, Fujitsu-Siemens) не наблюдалась.
Не скрою, за трагическим развитием событий следил, преисполненный сопереживания, нервного напряжения и… только! Нехотя поймал себя на мысли, что еще год-полтора назад не раздумывая ринулся бы в бой и сам, перепрошил свой КПК, а потом вместе с остальными фениморами выковыривал словленных блох, тихонько матерясь в адрес «форточек, гатуса и мастдай». Но то — год назад. А сегодня — нет! Ни за какие коврижки. При том что с августа прошлого года верил, как Басэй Акутагавы[Кто не читал — прочтите непременно. Это удивительный одностраничный шедевр японского гения — рассказ «Как верил Басэй»], в грядущее обновление операционной системы любимого наладонника, верил вопреки поголовному скепсису, провальным результатам обновления Dell и отказа от такового Fujitsu-Siemens для своего флагмана Pocket Loox 720.
HP слово сдержала, лишний раз продемонстрировав высший класс своих инженеров, и WM 2005 таки выпустила. Реальность, однако, такова, что переход на новую операционную систему выглядит делом затяжным, болезненным, сопряженным со сложностями, выпуском дополнительных патчей, твикингом реестра гениальными народными умельцами-гоблинами (уже началось!). Чего стоит одно многостраничное руководство по ручной перенастройке брандмауэра Windows XP, без которого ActiveSync 4.1 не распознает каждое второе устройство, работающее под WM2005.
Забавно, что Microsoft уже полгода знает о неприемлемом качестве своего синхронизатора (ActiveSync), а воз и ныне там. Хотя что тут забавного? Все как всегда — ничего нового. И по большому, и по малому, скажем так, счету Microsoft ваще не при делах: достаточно взглянуть на продукцию конкурентов (одной Пальмы за глаза хватит на годы вперед: ау, кокосово племя, как поживает ваш заявленный три года назад Кобальт?), чтобы понять: таково сегодняшнее состояние всего софтостроения, состояние как концепции, а не частной феноменологии.
При любом раскладе вопрос «производить апгрейд или не производить?» не стоит даже в принципе, потому как врожденная убогость Windows Mobile 2003 заведомо перевешивает все конфликты ActiveSync 4.1 с брандмауэрами и тормоза WM2005, связанные с неоптимизированными процессами кэширования на iPAQ 4700. Вот я и решил: свой «айпак» апгрейдить буду только после устранения всех шероховатостей и подводных камней! Хватит с меня «кошмаров на улице Винтукей» и прочих гадостей, из-за которых безвозвратно утеряны тонны личной информации, файлов, документов, наработок, не говоря о неисчислимых человеко-часах, бездарно положенных на алтарь технотронной малакии.
Ага, батенька, вот она и явилась не запылилась — Старость со своей консервативно-оберегательной клюкой! Может, и так. Боюсь, только, что дело посерьезнее. Так совпало, что сразу после малодушного устранения от безоглядного перехода на Windows Mobile 2005 довелось выслушать отчет Антонелло о поездке на CeBIT. Даже если отбросить безобидный флёр с шарманцом пожилого огородника («В Ганновере по ранней весне — скукотиииища!» — фу ты, ну ты, прям: «У нас в Париже что-то в последнее время супец подают остывшим!»), то останется еще и объективное свидетельство. Четыре (!) гигабайта умопомрачительных фотографий, отснятых Козловским на германской технологической выставке, которые в своем молчаливо-кричащем великолепии идеально демонстрируют зиму нашей общей тревоги: братцы, а ведь кирдык наступает не частностям, не компаниям, не IT-коммерции (с ней-то как раз все в порядке!), а — самой идее технологической революции, якобы способной вывести человечество на креатив нового уровня, недосягаемого для обитателей доцифровой эпохи.
Гляжу на достижения технологической выставки: еще один «самый большой в мире 105-дюймовый LCD-экран», еще одна «самая крутая матричная технология», еще одна «самая быстрая флэш-память», «сдвоенный видеоускоритель за 2 тысячи долларов», «микровинчестер на 20 гигабайт», «MP3-плейер в форме кулона» и прочая, и прочая, и прочая. А все вместе — жуткое в своей попугайной вычурности красок надгробье на могиле разбитых надежд обывателей на то, что новые технологии принесут с собой не только дополнительные мегабайты и гигагерцы, а качественный прорыв в творчестве и работе. Меж тем с ростом производительности плавающей точки происходит прямо пропорциональное падение эвристики. Создается впечатление, что всякое новое убивает оригинальное. Даже геометрическое увеличение контента, доступного в Интернете, приводит к подмене изучения этого контента его коллекционированием: людям просто некогда читать скачанные книги, слушать скачанные пластинки, просматривать скачанные фильмы.
Как вам такая задачка?
Дано: У Васи десктоп с допотопным процессором Intel DХ486, 16 мегабайтами памяти, 14-дюймым монитором VGA и жестким диском на 100 мегабайт. У Пети ноутбук Sony Vaio за 4 тысячи долларов со всеми вытекающими из цены причиндалами и прибамбасами.
Вопрос: Кто из ребят лучше напишет сочинение на тему «Как бы Лев Николаевич Толстой отнесся к расстрелу Белого Дома осенью 1993 года, если бы был жив?».
Ответ: Сочинение лучше напишет Вася, потому что его папа не только работает учителем литературы в общеобразовательной школе номер 479, но еще и занимается воспитанием сына с раннего детства, тогда как папа Пети всего лишь ворует в должности председателя правления банка, тратя свое свободное время на сауну, ресторан и гольф-клуб.
Иррелевантность технологической составляющей в нашей жизни, ее бессмысленность в креативном отношении, ее беспомощность в культивировании талантов и способностей — вот мысли, печалящие меня в последнее время и лишь усиленные фотоотчетом Козловского о CeBIT. Не потому ли я отказался делать незамедлительный апгрейд на Windows Mobile 2005?
Поскольку «Голубятня» без софта — это аберрация гордыни, венчаю думку презентацией одной из самых ярких находок последнего месяца — Amazing Slow Downer (см. рис.).
Программа делает, казалось бы, невозможное: замедляет темп музыкальной композиции (или любого файла в формате MP3/Wave/Wma/Ogg/FLAC), сохраняя при этом высоту тона! Сколько раз возникало желание замедлить проигрывание музыкальной композиции, чтобы получше разобрать текст на иностранном языке, разучить музыкальную технику, запомнить гитарный аккорд! Попробуйте, однако, проделать этот трюк в звуковом редакторе: любое снижение натурального темпа превращает даже самый нежный девичий голос в натужное мычание недоеной третьи сутки коровы. О мужском вокале вообще нет речи — симфония каменного цветка под дверной скрип того, что некогда было аккордом.
Самое поразительное, что Amazing Slow Downer преобразует звук в реальном времени. При этом вы полностью контролируете ситуацию: собственноручно ускоряете (до 200% от оригинальной) или замедляете (до 20%) скорость проигрывания, повышаете или понижаете тон, смещаете звук по стереоканалам и изменяете общую палитру на встроенном семиполосном эквалайзере. Добавьте сюда функцию караоке (возможность исключать вокал из композиции), ручное определение участка для кругового прослушивания (loop) и управление всеми функциями непосредственно с клавиатуры, и вы получите уникальный инструмент, о котором я и мечтать не мог в детстве, когда часами переставлял иглу проигрывателя с дорожки на дорожку, пытаясь разобрать тексты Pink Floyd и Led Zeppelin и при этом безбожно шкрябая винил!
Хотя постойте… может быть, оттого я и выучил семь языков, что не было у меня в детстве никаких компьютеров и подавно — Amazing Slow Downer? Эх, старость, старость…
Линки на программы, помянутые в «Голубятне» — на домашней странице internettrading.net/guru.
ПРОГРАММАЗМ: Субъектное программирование
Три недели фебрильного ожидания — и вот оно долгожданное: в бакунианский оборот забросили не только копии оригинальных дисков с Windows Mobile 2005 для iPAQ 4700, но и облегченный загружаемый вариант (всего 34 Мбайт — операционная система за вычетом нового Outlook’a). И понеслось: бесшабашные первопроходцы без оглядки на последствия ринулись перепрошивать свои наладонники, чтобы уже через час выстроиться в длинную очередь недоумения и отчаяния: ActiveSync 4.1 напрочь отказывается соединяться с КПК, половина привычных программ сторонних разработчиков под WM2005 не запускается, глюки с Wi-Fi при перезагрузке, потеря данных из-за неумения обращаться с принципиально новой типологией памяти (если после изменения настроек в программах наладонник не выключить и затем снова не включить, при последующем софт-ресете все изменения исчезают), а главное — под WM2005 iPAQ 4700 стал тормозить просто до неприличия: запуск программ — от 20 до 45 секунд, закрывание — почти столько же! Единственный, сходу бросающийся в глаза выигрыш после апгрейда: исчезла возмутительная утечка памяти под Windows Mobile 2003 SE, вынуждавшая как минимум раз в день производить софт-ресет наладонника. Утечка эта, кстати, была характерна исключительно для iPAQ 4700 и у конкурентов (Dell, Fujitsu-Siemens) не наблюдалась.
Не скрою, за трагическим развитием событий следил, преисполненный сопереживания, нервного напряжения и… только! Нехотя поймал себя на мысли, что еще год-полтора назад не раздумывая ринулся бы в бой и сам, перепрошил свой КПК, а потом вместе с остальными фениморами выковыривал словленных блох, тихонько матерясь в адрес «форточек, гатуса и мастдай». Но то — год назад. А сегодня — нет! Ни за какие коврижки. При том что с августа прошлого года верил, как Басэй Акутагавы[Кто не читал — прочтите непременно. Это удивительный одностраничный шедевр японского гения — рассказ «Как верил Басэй»], в грядущее обновление операционной системы любимого наладонника, верил вопреки поголовному скепсису, провальным результатам обновления Dell и отказа от такового Fujitsu-Siemens для своего флагмана Pocket Loox 720.
HP слово сдержала, лишний раз продемонстрировав высший класс своих инженеров, и WM 2005 таки выпустила. Реальность, однако, такова, что переход на новую операционную систему выглядит делом затяжным, болезненным, сопряженным со сложностями, выпуском дополнительных патчей, твикингом реестра гениальными народными умельцами-гоблинами (уже началось!). Чего стоит одно многостраничное руководство по ручной перенастройке брандмауэра Windows XP, без которого ActiveSync 4.1 не распознает каждое второе устройство, работающее под WM2005.
Забавно, что Microsoft уже полгода знает о неприемлемом качестве своего синхронизатора (ActiveSync), а воз и ныне там. Хотя что тут забавного? Все как всегда — ничего нового. И по большому, и по малому, скажем так, счету Microsoft ваще не при делах: достаточно взглянуть на продукцию конкурентов (одной Пальмы за глаза хватит на годы вперед: ау, кокосово племя, как поживает ваш заявленный три года назад Кобальт?), чтобы понять: таково сегодняшнее состояние всего софтостроения, состояние как концепции, а не частной феноменологии.
При любом раскладе вопрос «производить апгрейд или не производить?» не стоит даже в принципе, потому как врожденная убогость Windows Mobile 2003 заведомо перевешивает все конфликты ActiveSync 4.1 с брандмауэрами и тормоза WM2005, связанные с неоптимизированными процессами кэширования на iPAQ 4700. Вот я и решил: свой «айпак» апгрейдить буду только после устранения всех шероховатостей и подводных камней! Хватит с меня «кошмаров на улице Винтукей» и прочих гадостей, из-за которых безвозвратно утеряны тонны личной информации, файлов, документов, наработок, не говоря о неисчислимых человеко-часах, бездарно положенных на алтарь технотронной малакии.
Ага, батенька, вот она и явилась не запылилась — Старость со своей консервативно-оберегательной клюкой! Может, и так. Боюсь, только, что дело посерьезнее. Так совпало, что сразу после малодушного устранения от безоглядного перехода на Windows Mobile 2005 довелось выслушать отчет Антонелло о поездке на CeBIT. Даже если отбросить безобидный флёр с шарманцом пожилого огородника («В Ганновере по ранней весне — скукотиииища!» — фу ты, ну ты, прям: «У нас в Париже что-то в последнее время супец подают остывшим!»), то останется еще и объективное свидетельство. Четыре (!) гигабайта умопомрачительных фотографий, отснятых Козловским на германской технологической выставке, которые в своем молчаливо-кричащем великолепии идеально демонстрируют зиму нашей общей тревоги: братцы, а ведь кирдык наступает не частностям, не компаниям, не IT-коммерции (с ней-то как раз все в порядке!), а — самой идее технологической революции, якобы способной вывести человечество на креатив нового уровня, недосягаемого для обитателей доцифровой эпохи.
Гляжу на достижения технологической выставки: еще один «самый большой в мире 105-дюймовый LCD-экран», еще одна «самая крутая матричная технология», еще одна «самая быстрая флэш-память», «сдвоенный видеоускоритель за 2 тысячи долларов», «микровинчестер на 20 гигабайт», «MP3-плейер в форме кулона» и прочая, и прочая, и прочая. А все вместе — жуткое в своей попугайной вычурности красок надгробье на могиле разбитых надежд обывателей на то, что новые технологии принесут с собой не только дополнительные мегабайты и гигагерцы, а качественный прорыв в творчестве и работе. Меж тем с ростом производительности плавающей точки происходит прямо пропорциональное падение эвристики. Создается впечатление, что всякое новое убивает оригинальное. Даже геометрическое увеличение контента, доступного в Интернете, приводит к подмене изучения этого контента его коллекционированием: людям просто некогда читать скачанные книги, слушать скачанные пластинки, просматривать скачанные фильмы.
Как вам такая задачка?
Дано: У Васи десктоп с допотопным процессором Intel DХ486, 16 мегабайтами памяти, 14-дюймым монитором VGA и жестким диском на 100 мегабайт. У Пети ноутбук Sony Vaio за 4 тысячи долларов со всеми вытекающими из цены причиндалами и прибамбасами.
Вопрос: Кто из ребят лучше напишет сочинение на тему «Как бы Лев Николаевич Толстой отнесся к расстрелу Белого Дома осенью 1993 года, если бы был жив?».
Ответ: Сочинение лучше напишет Вася, потому что его папа не только работает учителем литературы в общеобразовательной школе номер 479, но еще и занимается воспитанием сына с раннего детства, тогда как папа Пети всего лишь ворует в должности председателя правления банка, тратя свое свободное время на сауну, ресторан и гольф-клуб.
Иррелевантность технологической составляющей в нашей жизни, ее бессмысленность в креативном отношении, ее беспомощность в культивировании талантов и способностей — вот мысли, печалящие меня в последнее время и лишь усиленные фотоотчетом Козловского о CeBIT. Не потому ли я отказался делать незамедлительный апгрейд на Windows Mobile 2005?
Поскольку «Голубятня» без софта — это аберрация гордыни, венчаю думку презентацией одной из самых ярких находок последнего месяца — Amazing Slow Downer (см. рис.).
Самое поразительное, что Amazing Slow Downer преобразует звук в реальном времени. При этом вы полностью контролируете ситуацию: собственноручно ускоряете (до 200% от оригинальной) или замедляете (до 20%) скорость проигрывания, повышаете или понижаете тон, смещаете звук по стереоканалам и изменяете общую палитру на встроенном семиполосном эквалайзере. Добавьте сюда функцию караоке (возможность исключать вокал из композиции), ручное определение участка для кругового прослушивания (loop) и управление всеми функциями непосредственно с клавиатуры, и вы получите уникальный инструмент, о котором я и мечтать не мог в детстве, когда часами переставлял иглу проигрывателя с дорожки на дорожку, пытаясь разобрать тексты Pink Floyd и Led Zeppelin и при этом безбожно шкрябая винил!
Хотя постойте… может быть, оттого я и выучил семь языков, что не было у меня в детстве никаких компьютеров и подавно — Amazing Slow Downer? Эх, старость, старость…
Линки на программы, помянутые в «Голубятне» — на домашней странице internettrading.net/guru.
ПРОГРАММАЗМ: Субъектное программирование
Автор: Александр Петриковский
Как известно, технологии программирования прошли в своем развитии несколько этапов (их еще называют парадигмами): классическое, процедурное, модульное, структурное и объектно-ориентированное программирование. Понятно, что на этом прогресс не должен останавливаться. Но какая парадигма будет следующей?
Чаще всего в небольших программах последовательное выполнение команд является самым естественным. Такое программирование носит название классического. Как только задачи усложняются — появляются подпрограммы и модули. Отсюда произросло структурное программирование. Оно позволяет создавать сколь угодно сложные программы и даже целые программные комплексы, разбивая основную задачу на подзадачи, которые называют модулями. Подгружаемые модули можно было отлаживать отдельно и компоновать в библиотеки для многократного использования из других приложений.
Следующей важной вехой в развитии языков программирования стало введение понятия структуры как особого, синтетического типа данных. Для описания свойств какого-либо реального объекта чаще всего требуется некий набор характеристик (структура). Присвоив этому набору имя, мы получаем возможность манипулирования характеристиками, как единым целым.
С расширением сферы применения программирования и особенно с развитием графических возможностей компьютеров появилась необходимость работать с большим количеством объектов, которые помимо свойств должны описываться рядом характерных действий. Аналогично набору свойств объекта, объединяемых рамками абстрактного понятия структуры, напрашивалось дальнейшее дополнение этого объединения набором действий — «методов». Это объединение уже представляло собой новую структуру данных — класс. Если структуру объекта можно сравнивать с его чертежом, то класс представляет собой уже некий рабочий механизм с органами управления. Этот подход позволил «конструировать» приложения из множества стандартных узлов, добавляя к ним детали и органы управления. В результате появилось целое направление — объектно-ориентированное программирование (ООП).
Нет смысла описывать все достоинства ООП, но главное достижение этого «изобретения» заключается в том, что оно приблизило представление о программе как о модели некоторого реального процесса реальной части мира!
Таким образом, все нововведения, появившиеся в свое время в технологии программирования, поддерживают одну и ту же стратегическую линию развития — совершенствование понятийного инструментария программирования.
Подобные приложения в современной многозадачной операционной системе исчисляются десятками. Поэтому координация их действий с ростом сложности систем превращается в непростую задачу. Здесь просматриваются два пути решения проблемы. Первый — увеличивать интеллектуальные возможности «координатора», чтобы он успевал управлять работой приложений. Второй — заставить «поумнеть» приложения, избавляя «координатора» от управленческой рутины. Первый путь имеет свой логический предел, так как напоминает растущее государство, в котором король лично управляет каждым своим подданным. Поэтому развитие информационных систем в основном идет по второму пути. Однако здесь тоже есть трудности, вызванные несовершенством методологии разработки таких приложений.
Программисту все труднее использовать результаты ранее разработанного программного кода в последующем, а при написании высокоинтеллектуальной программы процесс усложняется еще из-за большого количества программных модулей и достаточно сложных алгоритмов их взаимодействия. Все это неизбежно приводит к удорожанию разработки.
Тут-то и выходит на сцену новая технология — субъектное программирование. С ее помощью можно создать базу для развития более совершенной методологии разработки.
Итак, Субъектом называется приложение, способное в рамках системы самостоятельно реализовывать задачу, имеющую несколько путей решения. В отличие от «неразумного» Объекта, Субъект наделен возможностью выбирать этот путь, то есть он способен сам корректировать последовательности своих действий для достижения поставленной цели (как, например, делается при печати документа в спулере).
Стратегия управления такими приложениями должна основываться не на четких и конкретных командах операционной системы, а на «инструкциях». Управляя Объектом, мы используем отдельные его части (методы), а Субъекту достаточно указать «номер» инструкции, на основании которой он функционирует. И он уже сам будет управлять своими методами, чтобы достичь результата (рис. 1).
Слаженность и работоспособность работы системы, управляемой на основе такой стратегии, легко проиллюстрировать на примере отправки грузов железнодорожным транспортом. Допустим, существуют две фирмы, одна из которых занимается поставкой грузов на станцию, другая — формированием вагонов и отправкой грузов потребителям. В системе также есть диспетчер, контролирующий работу станции. Во время ремонта путей (обозначим это состояние системы — «Станция закрыта») диспетчер рассылает уведомление об этом обеим фирмам. Фирма, занимающаяся поставкой грузов, реагирует на ситуацию переходом в режим складирования грузов, а другая начинает заниматься ремонтом вагонов. Здесь важно то, что они не тратят силы на контакты друг с другом до тех пор, пока не изменится ситуация, а диспетчеру не требуется координировать их работу, так как каждый из компонентов системы действует по уже написанной инструкции.
То есть (возвращаясь к программированию) становится очевидным, что для эффективной разработки сложных интеллектуальных систем необходимо опираться на элементы, обладающие достаточной самостоятельностью. Как же должен быть устроен Субъект, чтобы реализовать все эти возможности? В первую очередь нужно формализовать на уровне системы существенные особенности такого элемента, а именно:
1. Субъект живет самостоятельной жизнью. Его сердцем является таймер, который как бы «питает» Субъект машинным временем операционной системы.
2. Субъект имеет органы осязания в виде сенсоров. Сенсоры следят за состоянием внешней и внутренней среды Субъекта. На основании анализа этих состояний Субъект выбирает ту или иную линию поведения.
3. Субъект содержит набор линий поведения. Каждая из них представляет собой роль, которая может быть выражена набором подпрограмм, преследующим определенную цель.
4. С роли на роль Субъект переключается самостоятельно исходя из анализа состояния системы.
На самом деле платформа для этого подхода в архитектуре систем подготавливалась на протяжении последних десяти-пятнадцати лет.
Некий прообраз описания Субъекта мы уже имеем, создавая AciveX (COM+) объекты; они могут загружаться в память системы и работать как вполне самостоятельные модули. Здесь в качестве связей с внешним миром используются интерфейсы, которые фактически являются сенсорами. С другой стороны, «магические» свойства операторов переключателей (case и switch) подвигли постановщиков задач для систем автоматического управления на разработку особой методологии программирования — switch-технологии, или автоматного программирования. Эта методология основывается на выделении состояний объекта, что позволяет приблизиться к формализации описания алгоритма программы. Дальше всех продвинулись в управлении объектами, которые по функциональному исполнению вполне подходят на роль Субъектов, разработчики анимационной графики и компьютерных игр.
Таким образом, на сегодняшний день имеется достаточно предпосылок, чтобы попытаться решить задачу формализации описания программного элемента — Субъекта.
Парадоксально, но факт: совершенствование самоорганизующихся приложений в мире информационных систем повторяет эволюцию живой природы — от простейших одноклеточных к более сложным организмам.
Не случайно первыми объектами, хорошо приспосабливающимися к среде обитания, были компьютерные вирусы, чье поведение очень похоже на поведение их «собратьев» из реальной жизни, а именно:
внедриться в тело программы и использовать для «питания» ее машинное время;
скрытно размножиться;
выполнять деструктивные действия в зараженных системах.
Такие «организмы» прекрасно себя чувствовали даже в однозадачной среде под DOS.
Современные многозадачные операционные системы уже сами собой представляют подобие многоклеточного организма, который пытается поддерживать работоспособность системы в целом, находясь в неком симбиозе с пользовательскими приложениями. Клетками этого организма являются службы ОС, выполняющие достаточно большое количество задач, таких как: контроль целостности данных в оперативной и дисковой памяти, контроль работы периферийных устройств, контроль сетевых устройств, управление правами доступа к данным и т. д. Понятие «оживление» напрашивается, а кое-где оно уже введено в индустрии компьютерных игр. Это относится как к процессу анимирования моделей игровых персонажей, так и к логике их поведения. Еще на этапе создания модели в нее могут включаться скрипты, имитирующие бег, ходьбу, повороты, мимику и другие способы анимации. В результате модель уже содержит набор линий поведения, которые могут использоваться разработчиками игр в соответствии с сюжетом. Создатели игровых сюжетов много внимания уделяют логической составляющей в поведении персонажей. До искусственного интеллекта им, конечно, еще очень далеко, но факт появления шахматных программ гроссмейстерского уровня говорит сам за себя.
Очевидно, что для стандартизации желательно применять такой способ решения задачи описания Субъектов, который был бы уже заложен в основу компилятора языка программирования. В качестве каркаса, на котором формируется структура Субъекта, можно использовать привычную структуру класса, просто введя в нее дополнительные понятия. Как известно, в описании класса в ООП обычно заложены следующие категории:
свойства — как описание характеристик объекта;
способности — как описание действий с объектом;
правила наследования свойств и способностей объекта.
Остается дополнить объект новыми элементами, относящимися к функциональности Субъекта:
активность — как описание частоты активизации объекта с помощью внешнего или внутреннего таймера;
контроль состояния — как описание сенсоров, которые ответственны за перевод Субъекта из одного состояния в другое;
линии поведения — как описания ролей, исполняемых Субъектом.
Обычно линии поведения уже присутствуют в программе, но они не всегда логически выделяются и структурируются разработчиком.
Таким образом, внешние отличия одного и того же приложения, написанного с помощью ООП и субъектно-ориентированного программирования (СОП), сведутся к тому, что весь «свободный» код[В данном случае «свободным» кодом называется нестандартизованный код, который программист пишет заново для каждого экземпляра объекта] в СОП разносится по соответствующим секциям, называемым ролями (рис. 2).
В этом случае необходимо ввести понятие «состояние Субъекта». Состояние Субъекта представляет собой обычную переменную, в которой содержится «кодовое слово», переключающее алгоритм работы приложения с одной линии поведения на другую. Список состояний Субъектов системы должен быть доступен всем приложениям.
Функции, реагирующие на события и принудительно изменяющие состояние Субъекта, относятся к категории сенсоров. Эта категория функций весьма условна и выделена только для того, чтобы можно было контролировать последовательность смены внутренних состояний объекта, например — при отладке приложения. Так как тип рассматриваемых приложений предназначен в первую очередь для работы в режиме реального времени, то рационально использовать наиболее надежный и предсказуемый способ организации выполнения программы — циклический.
Блок формирования состояния может понадобиться тогда, когда логика выбора состояния будет достаточно сложна (либо требуется наличие временных функций — задержек). И здесь самым подходящим языком описания алгоритма формирования состояния может служить язык из стандарта IEC 61131-3, применяемый в некоторых контроллерах. Например, для удобства описания интерфейсов СОМ-объектов был даже создан свой язык — Interface Definition Language. Однако этот момент является только предположением, поэтому говорить о нем пока рано. А вот без создания нового краткого «языка общения» между различными Субъектами, возможно, не обойтись.
Как известно, технологии программирования прошли в своем развитии несколько этапов (их еще называют парадигмами): классическое, процедурное, модульное, структурное и объектно-ориентированное программирование. Понятно, что на этом прогресс не должен останавливаться. Но какая парадигма будет следующей?
Предыстория
Прежде чем подойти к ответу на этот вопрос, необходимо еще раз оглянуться назад. Каждая технология программирования тесно связана с некими абстракциями и каждая появилась не случайно, а была вызвана необходимостью сближения понятий реальной жизни (для которой и пишутся программы) с процессом программирования.Чаще всего в небольших программах последовательное выполнение команд является самым естественным. Такое программирование носит название классического. Как только задачи усложняются — появляются подпрограммы и модули. Отсюда произросло структурное программирование. Оно позволяет создавать сколь угодно сложные программы и даже целые программные комплексы, разбивая основную задачу на подзадачи, которые называют модулями. Подгружаемые модули можно было отлаживать отдельно и компоновать в библиотеки для многократного использования из других приложений.
Следующей важной вехой в развитии языков программирования стало введение понятия структуры как особого, синтетического типа данных. Для описания свойств какого-либо реального объекта чаще всего требуется некий набор характеристик (структура). Присвоив этому набору имя, мы получаем возможность манипулирования характеристиками, как единым целым.
С расширением сферы применения программирования и особенно с развитием графических возможностей компьютеров появилась необходимость работать с большим количеством объектов, которые помимо свойств должны описываться рядом характерных действий. Аналогично набору свойств объекта, объединяемых рамками абстрактного понятия структуры, напрашивалось дальнейшее дополнение этого объединения набором действий — «методов». Это объединение уже представляло собой новую структуру данных — класс. Если структуру объекта можно сравнивать с его чертежом, то класс представляет собой уже некий рабочий механизм с органами управления. Этот подход позволил «конструировать» приложения из множества стандартных узлов, добавляя к ним детали и органы управления. В результате появилось целое направление — объектно-ориентированное программирование (ООП).
Нет смысла описывать все достоинства ООП, но главное достижение этого «изобретения» заключается в том, что оно приблизило представление о программе как о модели некоторого реального процесса реальной части мира!
Таким образом, все нововведения, появившиеся в свое время в технологии программирования, поддерживают одну и ту же стратегическую линию развития — совершенствование понятийного инструментария программирования.
Зачем нам кузнец?
В наши дни все большее распространение находят приложения, которые способны самостоятельно решать многовариантные задачи. Например, многие слышали о спулере[Знаете ли вы, что слово «spooler» образовано от сокращения SPOOL (кроме того, spool по-английски — катушка, шпулька), Simultaneous Peripheral Operations On Line, то есть одновременная оперативная обработка запросов к периферийным устройствам. — Здесь и далее примечания Константина Курбатова] печати — сервисной программе операционной системы, которая получает задание вывести документ на печать. Программе самой приходится опрашивать принтер, выяснять его готовность, отправлять документ на печать, а в случае занятости принтера ставить документ в очередь и т. д. Потребность в таких «умных» приложениях растет. Если раньше текстовый редактор представлял собой одну большую программу, то теперь в нем параллельно работают несколько процессов, каждый из которых выполняет специально отведенную ему роль. Например: форматирование, проверка орфографии, автоматическое сохранение документа.Подобные приложения в современной многозадачной операционной системе исчисляются десятками. Поэтому координация их действий с ростом сложности систем превращается в непростую задачу. Здесь просматриваются два пути решения проблемы. Первый — увеличивать интеллектуальные возможности «координатора», чтобы он успевал управлять работой приложений. Второй — заставить «поумнеть» приложения, избавляя «координатора» от управленческой рутины. Первый путь имеет свой логический предел, так как напоминает растущее государство, в котором король лично управляет каждым своим подданным. Поэтому развитие информационных систем в основном идет по второму пути. Однако здесь тоже есть трудности, вызванные несовершенством методологии разработки таких приложений.
Программисту все труднее использовать результаты ранее разработанного программного кода в последующем, а при написании высокоинтеллектуальной программы процесс усложняется еще из-за большого количества программных модулей и достаточно сложных алгоритмов их взаимодействия. Все это неизбежно приводит к удорожанию разработки.
Тут-то и выходит на сцену новая технология — субъектное программирование. С ее помощью можно создать базу для развития более совершенной методологии разработки.
Итак, Субъектом называется приложение, способное в рамках системы самостоятельно реализовывать задачу, имеющую несколько путей решения. В отличие от «неразумного» Объекта, Субъект наделен возможностью выбирать этот путь, то есть он способен сам корректировать последовательности своих действий для достижения поставленной цели (как, например, делается при печати документа в спулере).
Стратегия управления такими приложениями должна основываться не на четких и конкретных командах операционной системы, а на «инструкциях». Управляя Объектом, мы используем отдельные его части (методы), а Субъекту достаточно указать «номер» инструкции, на основании которой он функционирует. И он уже сам будет управлять своими методами, чтобы достичь результата (рис. 1).
То есть (возвращаясь к программированию) становится очевидным, что для эффективной разработки сложных интеллектуальных систем необходимо опираться на элементы, обладающие достаточной самостоятельностью. Как же должен быть устроен Субъект, чтобы реализовать все эти возможности? В первую очередь нужно формализовать на уровне системы существенные особенности такого элемента, а именно:
1. Субъект живет самостоятельной жизнью. Его сердцем является таймер, который как бы «питает» Субъект машинным временем операционной системы.
2. Субъект имеет органы осязания в виде сенсоров. Сенсоры следят за состоянием внешней и внутренней среды Субъекта. На основании анализа этих состояний Субъект выбирает ту или иную линию поведения.
3. Субъект содержит набор линий поведения. Каждая из них представляет собой роль, которая может быть выражена набором подпрограмм, преследующим определенную цель.
4. С роли на роль Субъект переключается самостоятельно исходя из анализа состояния системы.
На самом деле платформа для этого подхода в архитектуре систем подготавливалась на протяжении последних десяти-пятнадцати лет.
Некий прообраз описания Субъекта мы уже имеем, создавая AciveX (COM+) объекты; они могут загружаться в память системы и работать как вполне самостоятельные модули. Здесь в качестве связей с внешним миром используются интерфейсы, которые фактически являются сенсорами. С другой стороны, «магические» свойства операторов переключателей (case и switch) подвигли постановщиков задач для систем автоматического управления на разработку особой методологии программирования — switch-технологии, или автоматного программирования. Эта методология основывается на выделении состояний объекта, что позволяет приблизиться к формализации описания алгоритма программы. Дальше всех продвинулись в управлении объектами, которые по функциональному исполнению вполне подходят на роль Субъектов, разработчики анимационной графики и компьютерных игр.
Таким образом, на сегодняшний день имеется достаточно предпосылок, чтобы попытаться решить задачу формализации описания программного элемента — Субъекта.
Парадоксально, но факт: совершенствование самоорганизующихся приложений в мире информационных систем повторяет эволюцию живой природы — от простейших одноклеточных к более сложным организмам.
Не случайно первыми объектами, хорошо приспосабливающимися к среде обитания, были компьютерные вирусы, чье поведение очень похоже на поведение их «собратьев» из реальной жизни, а именно:
внедриться в тело программы и использовать для «питания» ее машинное время;
скрытно размножиться;
выполнять деструктивные действия в зараженных системах.
Такие «организмы» прекрасно себя чувствовали даже в однозадачной среде под DOS.
Современные многозадачные операционные системы уже сами собой представляют подобие многоклеточного организма, который пытается поддерживать работоспособность системы в целом, находясь в неком симбиозе с пользовательскими приложениями. Клетками этого организма являются службы ОС, выполняющие достаточно большое количество задач, таких как: контроль целостности данных в оперативной и дисковой памяти, контроль работы периферийных устройств, контроль сетевых устройств, управление правами доступа к данным и т. д. Понятие «оживление» напрашивается, а кое-где оно уже введено в индустрии компьютерных игр. Это относится как к процессу анимирования моделей игровых персонажей, так и к логике их поведения. Еще на этапе создания модели в нее могут включаться скрипты, имитирующие бег, ходьбу, повороты, мимику и другие способы анимации. В результате модель уже содержит набор линий поведения, которые могут использоваться разработчиками игр в соответствии с сюжетом. Создатели игровых сюжетов много внимания уделяют логической составляющей в поведении персонажей. До искусственного интеллекта им, конечно, еще очень далеко, но факт появления шахматных программ гроссмейстерского уровня говорит сам за себя.
Спор хозяйствующих субъектов…
Многим разработчикам приходилось создавать приложения, напоминающие поведением Субъекты. И каждый решал эту задачу по-своему.Очевидно, что для стандартизации желательно применять такой способ решения задачи описания Субъектов, который был бы уже заложен в основу компилятора языка программирования. В качестве каркаса, на котором формируется структура Субъекта, можно использовать привычную структуру класса, просто введя в нее дополнительные понятия. Как известно, в описании класса в ООП обычно заложены следующие категории:
свойства — как описание характеристик объекта;
способности — как описание действий с объектом;
правила наследования свойств и способностей объекта.
Остается дополнить объект новыми элементами, относящимися к функциональности Субъекта:
активность — как описание частоты активизации объекта с помощью внешнего или внутреннего таймера;
контроль состояния — как описание сенсоров, которые ответственны за перевод Субъекта из одного состояния в другое;
линии поведения — как описания ролей, исполняемых Субъектом.
Обычно линии поведения уже присутствуют в программе, но они не всегда логически выделяются и структурируются разработчиком.
Таким образом, внешние отличия одного и того же приложения, написанного с помощью ООП и субъектно-ориентированного программирования (СОП), сведутся к тому, что весь «свободный» код[В данном случае «свободным» кодом называется нестандартизованный код, который программист пишет заново для каждого экземпляра объекта] в СОП разносится по соответствующим секциям, называемым ролями (рис. 2).
Что наша жизнь? Игра…
Следует отметить, что роли могут модифицироваться разработчиком каждого отдельного приложения. Если потребуется сертификация некой линии поведения, то здесь возможно использование уникального ключа (Unique ID, UID). Это позволяет создавать пользовательские «коллекции» ролей, которые потом можно применять и в чужих программных проектах. Дабы обеспечить возможность повторного использования соответствующих ролей в описании Субъекта, формируется специальный раздел, который служит основой для сборки секций ролей в приложении (где можно указывать UID ролей из библиотек). В нем должна находиться информация о том, какому значению состояния соответствует данная роль, а также сведения о задержках переключения алгоритмов.Функции, реагирующие на события и принудительно изменяющие состояние Субъекта, относятся к категории сенсоров. Эта категория функций весьма условна и выделена только для того, чтобы можно было контролировать последовательность смены внутренних состояний объекта, например — при отладке приложения. Так как тип рассматриваемых приложений предназначен в первую очередь для работы в режиме реального времени, то рационально использовать наиболее надежный и предсказуемый способ организации выполнения программы — циклический.
Проснись — и пой!
Активность Субъекта определяется частотой «подключения» таймера к работе. Однако присутствие таймера во внутренней структуре Субъекта совсем не обязательно! Достаточно наличия метода (имеющего определенную структуру) обработки события от таймера. А «оживляться» этот метод может как по событию от внутреннего таймера, так и внешним вызовом.Блок формирования состояния может понадобиться тогда, когда логика выбора состояния будет достаточно сложна (либо требуется наличие временных функций — задержек). И здесь самым подходящим языком описания алгоритма формирования состояния может служить язык из стандарта IEC 61131-3, применяемый в некоторых контроллерах. Например, для удобства описания интерфейсов СОМ-объектов был даже создан свой язык — Interface Definition Language. Однако этот момент является только предположением, поэтому говорить о нем пока рано. А вот без создания нового краткого «языка общения» между различными Субъектами, возможно, не обойтись.