Темой февральского номера журнала является "Управляемая моделями разработка программного обеспечения" ("Model-Driven Software Development"). Представлена полноценная тематическая подборка статей с приглашенным редактором, Дугласом Шмидтом (Douglas C. Schmidt, Vanderbilt University).

Объемная вводная заметка редактора называется "Управляемая моделями инженерия" ("Model-Driven Engineering"). Эта заметка кажется мне настолько полезной для введения в тему данного номера журнала, что я позволю себе пересказать ее достаточно подробно.

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

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

Одним из наиболее известных направлений, образовавшихся в 1980-е гг., является инженерия программного обеспечения с компьютерной поддержкой (Computer-Aided Software Engineering, CASE), которая обеспечивает методы и средства разработки программного обеспечения, позволяющие разработчикам выражать свои конструкции с использование графических программных средств общего назначения, различного вида диаграмм. Одной из целей CASE-средств было обеспечение более тщательного анализа графических программ за счет их меньшей сложности, чем у программ, представленных на традиционных языках программирования (например, в графических программах невозможны ошибки, приводящие к повреждению памяти).

Другой целью являлся автоматизированный синтез реализационных артефактов из графических представлений, позволяющий сократить объем ручного труда на кодирование, отладку и перенос программ. Хотя подходу CASE уделялось значительное внимание в исследовательской и профессиональной литературе, он не был широко принят на практике. Одной из проблем было то, что графические средства написания программ, применяемые в CASE-средствах, плохо отображались на реализационные платформы, которые в основном представляли собой изолированные операционные системы (DOS, OS/2 или Windows), не обеспечивающие поддержку отказоустойчивости, безопасности и т.д. Объем и сложность генерируемого кода, требуемого для компенсации ограниченности реализационных платформ, выходили за пределы возможностей существовавших технологий трансляции, что затрудняло разработку, отладку и развитие CASE-средств и приложений, создаваемых с их использованием.

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

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

В последние двадцать лет достижения в области языков программирования и платформ привели к повышению уровня абстракций, доступных для разработчиков, смягчив один из недостатков подхода CASE. Например, сегодня разработчики обычно используют более выразительные объектно-ориентированные языки (в частности, C++, Java и C#), а не Fortran или C. Повторно используемые библиотеки классов и платформы поддержки приложений минимизируют потребность в изобретении общих и прикладных сервисов - транзакций, отказоустойчивости, оповещения о событиях, безопасности, распределенного управления ресурсами и т.д. Все это позволяет разработчикам лучше защититься от сложности, связанной с созданием приложений на основе традиционных технологий.

Несмотря на эти достижения, остается несколько неприятных проблем. В центре этих проблем лежит сложность платформ, которая растет быстрее способности языков общего назначения маскировать ее. Например, популярные платформы промежуточного программного обеспечения J2EE, .NET и CORBA содержат тысячи классов и методов со многими сложными зависимостями и тонкими побочными эффектами, что требует значительных усилий при программировании и тщательной настройки. Более того, поскольку эти платформы быстро развиваются (а также регулярно возникают новые платформы), разработчики тратят много сил на портирование кода приложений на различные платформы или обновленные версии существующих платформ.

Родственная проблема состоит в том, что код большинства приложений и платформ по-прежнему пишется на языках третьего поколения, для чего требуется много времени и усилий, в особенности для выполнения интеграционных действий - развертывание, конфигурирование и поддержка качества системы. Например, на Java или C# трудно написать код, корректно и оптимально развертывающий крупномасштабные распределенные системы с сотнями тысяч взаимосвязанных компонентов.

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

В то же время платформенные технологии нового поколения, например, Web-сервисы и архитектуры продуктовых линий (product-line architecture) становятся настолько сложными, что годами овладевают платформенными API и паттернами использования и при этом часто оказываются знакомыми только с частью возможностей регулярно используемой ими платформы. Более того, при использовании языков третьего поколения разработчики вынуждаются уделять настолько большое внимание тактическим деталям императивного программирования, что они часто не могут концентрироваться на стратегических архитектурных проблемах, таких как корректность системы в целом и ее производительность. Такие фрагментированные представления проекта в целом затрудняют разработчикам понимание того, какие части их приложений являются чувствительными к побочным эффектам, возникающим при изменении требований заказчиков и/или среды разработки. Часто это вынуждает разработчиков производить неоптимальные решения, в которых дублируются части кода, нарушаются ключевые архитектурные принципы, усложняется развитие системы и обеспечение требуемого качества.

Многообещающим подходом, направленным на решение этих проблем, является разработка технологий инженерии, управляемой моделями, (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования (Domain-Specific Modeling Language, DSML), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. DSML описываются с использованием метамоделей, в которых определяются связи между понятиями предметной области и точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют DSML для построения приложений, используя элементы системы типов, зафиксированной в метамодели, и выражают проектный замысел в декларативном, а не императивном стиле.

Важнейшими компонентами MDE являются трансформационные процессоры и генераторы, которые анализируют определенные аспекты моделей и синтезируют разные вида артефактов: исходный код, входные данные для имитационного моделирования, XML-описания развертывания или альтернативные представления моделей. Возможность синтеза артефактов на основе моделей помогает поддерживать согласованность между реализациями приложения и аналитической информацией о требованиях к функциональных возможностям системы и ее качества, зафиксированных в модели. Этот автоматический трансформационный процесс часто называют "правильным по построению" ("correct-by-construction") в отличие от утомительного и чреватого ошибками традиционного процесса разработки программного обеспечения вручную в стиле "построения путем коррекции" ("construct-by-correction").

Первая основная статья тематической подборки называется "Разработка приложений с использованием управляемых моделями сред разработки" ("Developing Applications Using Model-Driven Design Environments"). Авторы статьи - Кришнакумар Баласубраманьян, Анируддха Гокхейл, Габор Карсай, Янош Штипанович и Сандип Нема (Krishnakumar Balasubramanian, Aniruddha Gokhale, Gabor Karsai, Janos Sztipanovits, Sandeep Neema, Vanderbilt University).

Исторически методологии разработки программного обеспечения фокусируются в большей степени на совершенствовании средств разработки систем, а не на создании инструментов, помогающих конструировать и интегрировать системы. Компонентное программное обеспечение промежуточного слоя (Enterprise Java-Beans (EJB), Microsoft .NET и CORBA Component Model (CCM)) способствуют повышению уровня повторного использования программного обеспечения на основе абстракции компонента.

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

Разработка, управляемая моделями (Model-Driven Development, MDD) - это развивающаяся парадигма, решающая многочисленные проблемы композиции и интеграции крупномасштабных систем и опирающаяся при этом на имеющиеся достижения в области технологий разработки программного обеспечения (в частности, на компонентное промежуточное программное обеспечение). MDD позволяет перевести разработку программного обеспечение на более высокий уровень абстракции по сравнению с тем, который возможен при использовании языков третьего поколения. Для представления элементов системы и их связей в подходе MDD используются модели. Модели служат входными и выходными данными на всех стадиях разработки, вплоть генерации законченной системы.

Популярным вариантом MDD является модельно-управляемая архитектура (Model-Driven Architecture, MDA), предложенная и развиваемая консорциумом Object Management Group (OMG). В подходе MDA системы представляются с использованием языка моделирования общего назначения Unified Modeling Language (UML) и его конкретных профилей. Эти модели преобразуются в артефакты, выполняемые на разнообразных платформах, в частности, на EJB, .NET и CCM.

В отличие от MDA, в другом варианте MDD, называемом модельно-интеграционными вычислениями (Model-Integrated Computing, MIC), для представления элементов системы и их связей используются предметно-ориентированные языки моделирования (DSML), а также их преобразования в плаформенно-зависимые артефакты. Технология MIC была создана и развивается в университете Вандербилта.

Концепция MIC была успешно применена на разработки нескольких наборов инструментальных средств. В данной статье авторы концентрируются на двух разработках. Язык платформенно-независимого компонентного моделирования (Platform-Independent Component Modeling Language, PICML) помогает разрабатывать, конфигурировать и развертывать системы с использованием компонентной технологии CCM. Язык встроенных управляющих систем (Embedded Control Systems Language, ECSL) поддерживает разработку распределенных встроенных автомобильных приложений. Оба эти набора инструментов построены с использованием общей среды моделирования (Generic Modeling Environment, GME, см. http://www2.osp.ru/os/2002/01/074.htm и http://www.isis.vanderbilt.edu/Projects/gme).

GME представляет собой свободно доступную метапрограммируемую среду предметно-ориентированных разработок. Разработчики используют эту среду для создания как DSML, так и моделей, соответствующих этим DSML, в одной и той же графической среде.

Следующая статья написана Адамом Чайлдсом, Джессе Гринволдом, Джорджем Джангом, Мэтью Хузэ и Джоном Хэтклифом (Adam Childs, Jesse Greenwald, Georg Jung, Matthew Hoosier, John Hatcliff, Kansas State University). Название статьи - "CALM и Cadena: метамоделирование для основанной на компонентах разработки продуктового ряда" ("CALM and Cadena: Metamodeling for Component-Based Product-Line Development").

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

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

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

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

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

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

Платформа поддержки разработки Cadena совместно с ее основным средством моделирования CALM (Cadena Architecture Language with Metamodeling) позволяет преодолеть этот недостаток на счет обеспечения адаптивной среды моделирования с мощной, гибкой и расширяемой инструментальной поддержкой. CALM - это язык описания архитектур, поддерживающий строго типизированное моделирование платформ, компонентов этих платформ и сборок компонентов конкретных сценариев. Язык также поддерживает основанную на наследовании иерархическую организацию платформ с использованием механизмов аспектов для включения в общие архитектурные описания атрибутов конкретных платформ. Cadena обеспечивает разнообразную поддержку создания, редактирования, запрашивания, просмотра и преобразования CALM-моделей. CALM-модели связываются с каркасами компонентного промежуточного программного обеспечения, а также со средствами генерации кода через подключаемые модули Cadena. Эти подключаемые модули фактически являются интерпретаторами моделей, реализующими семантику CALM-моделей.

Cadena разрабатывается начиная с нуля, и должна стать расширяемой инструментальной платформой, а не одиночным инструментом. Основываясь на свободно доступной интегрированной среде разработки Eclipse, Cadena сама реализуется в виде серии подключаемых модулей Eclipse. В Cadena используются средства автокодирования среды Eclipse Modeling Framework, так что разработчики могут создавать исключительно мощные и эффективные инструментальные средства, обеспечивающие инкрементную проверку типов и распространение модельных изменений.

Статья "Автоматизация эволюции изменений в модельно-управляемой инженерии" ("Automating Change Evolution in Model-Driven Engineering") написана Джефом Греем, Джейн Лин и Джинг Жанг (Jeff Gray, Yuehua ("Jane") Lin, Jing Zhang, University of Alabama at Birmingham).

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

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

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

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

Обе эти категории эволюции изменений существенно выиграли бы от автоматизации. С этой целью авторы разработали обобщенный процессор трансформаций для манипулирования моделями, названный ими C-Saw (Constraint-Specification Aspect Weaver). C-Saw - это подключаемый модуль для GME (см. выше обзор статьи "Разработка приложений с использованием управляемых моделями сред разработки").

Для работы с изменениями, пересекающими иерархию, в C-Saw используется несколько принципов аспектно-ориентированного подхода. Комбинация трансформации модели с компоновкой аспектов обеспечивает мощную технологию для быстрого преобразования унаследованных систем на основе высокоуровневых свойств, описываемых моделью. Далее, путем применения аспектно-ориентированных методов и преобразования программ небольшие изменения на модельном уровне могут инициировать очень крупные трансформации на уровне исходного кода.

У авторов имеется опыт применения C-Saw для моделирования систем из области авиационного электронного оборудования, и этот опыт дает им основания надеяться, что у созданного ими инструмента имеется потенциал для существенного повышения эффективности и уменьшения числа ошибок, свойственных для ручного процесса авторы.

Последнюю статью тематической подборки - "Модельно-ориентированная разработка с использованием UML 2.0: обещания и просчеты" ("Model-Driven Development Using UML 2.0: Promises and Pitfalls") - написали Роберт Франс, Судипто Гош, Трунг Динх-Тронг и Арнор Солберг (Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, Colorado State University, Arnor Solberg, SINTEF).

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

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

OMG (Object Management Group) отвечает на это требование подготовкой версии 2.01 языка UML и инициативой MDA (Model Driven Architecture). Проблемы, на решение которых в начале были нацелены разработчики UML 2.0, включали очевидное распухание ранних версий UML и отсутствие правильно определенной семантики.

В ходе разработки стандарта в число требований была добавлена поддержка модельно-управляемой разработки (MDD), а точнее, подхода MDA к MDD. Широкая осведомленность о проблемах ранних версий UML вместе с растущим интересом к MDD породили надежды на то, что разработчикам UML 2.0 удастся произвести версию языка с существенно сокращенным набором модельных понятий для точного и удобного описаний самых разнообразных приложений.

Ожидалось также, что в этой версии будет иметься точная семантика, которая могла бы облегчить автоматизацию, требуемую для продвижения MDD за пределы традиционных возможностей существующих CASE-средств. Некоторые люди ожидали, что разработчикам UML 2.0 удастся произвести серебряную пулю языков моделирования или, по крайней мере, тесно приблизиться к этому.

Те, кто не знаком с внутренними работами в области проводимой сообществом стандартизации языков, находят поразительными размер и сложность стандарта UML 2.0. Действительно, конечные результаты кажутся далекими от посылок, которые мотивировали начало этой работы по крупному пересмотру языка. С точки зрения очернителя, многочисленные модельные понятия, плохо определенная семантика и легковесные механизмы расширений затрудняют изучение языка и его применение в среде MDD. Эти реальные проблемы требуют решения, но нам не следует удивляться тому, что этот язык моделирования первого поколения далек от совершенства.

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

Защитники UML 2.0 отмечают, что в этом стандарте отражен лучший производственный опыт применения моделирования. Они говорят про следующие основные усовершенствования:

• Улучшена поддержка UML как семейства языков за счет использования профилей и точек семантических вариаций (semantic variation point), которые помечают части UML, которые умышленно оставлены без семантики, чтобы можно было нагрузить их семантикой, определяемой пользователями.
• Улучшена выразительность моделирования, включая моделирование бизнес-процессов, поддержку классификаторов повторного использования моделирования и поддержку архитектур распределенных неоднородных систем.
• Произведена интеграция семантики действий (Action Semantics), которая может использоваться разработчиками для определения семантики моделей во время выполнения и обеспечивает семантическую точность, требуемую для анализа моделей и их трансляции в реализации.

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

Вне тематической подборки в февральском номере опубликована всего одна статья - "Распределенные встроенные интеллектуальные видеокамеры для приложений электронного наблюдения" ("Distributed Embedded Smart Cameras for Surveillance Applications"). Авторы статьи: Михаель Брамбергер, Андреас Добландер, Арнольд Майер, Бернхард Риннер и Хельмут Швабах (Michael Bramberger, Andreas Doblander, Arnold Maier, Bernhard Rinner, Graz University of Technology, Helmut Schwabach, Austrian Research Centers, Seibersdorf).

Современные достижения в областях вычислительной техники, коммуникаций и сенсорной технологии ускоряют разработку многих новых технологий. Эта тенденция особенно заметна в областях повсеместного компьютинга (pervasive computing), сенсорных сетей и встроенных систем. Одним из примеров таких новаций являются интеллектуальные видеокамеры, оборудованные высокопроизводительной встроенной вычислительной и коммуникационной инфраструктурой. В одном встраиваемом устройстве объединяются возможности видео-восприятия, обработки и коммуникаций. Путем обеспечения доступа ко многим точкам обзора за счет взаимодействия отдельных видеокамер сети встроенных камер потенциально могут поддерживать более сложные и проблемные приложений - включая интеллектуальные комнаты, электронное наблюдение, анализ движения, - чем одиночная видеокамера.

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

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

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

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