Темой февральского номера журнала Computer (IEEE Computer Society, Vol. 38, No. 2, February 2006) стала «Управляемая моделями разработка программного обеспечения» (Model-Driven Software Development).

Полноценная тематическая подборка статей предваряется объемной заметкой приглашенного редактора Дугласа Шмидта (Douglas Schmidt), которая озаглавлена «Управляемая моделями инженерия» (Model-Driven Engineering). Последние пятьдесят лет исследователи и разработчики программного обеспечения создают абстракции, помогающие им программировать в терминах целей своего проекта, а не используемой компьютерной среды, и защищающие их от сложностей этой среды. С самого начала эти абстракции включали технологии языков программирования и операционных систем. Ранние языки программирования защищали разработчиков от сложностей программирования в машинных кодах, а ранние операционные системы — от сложностей программирования на уровне аппаратуры. Но, хотя они и повышали уровень абстракции, они явно были «ориентированными на вычисления», обеспечивая абстракции пространства решений (т.е. самих компьютерных технологий), а не абстракции, позволяющие вести разработку в терминах прикладной области.

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

В последние двадцать лет достижения в области языков программирования и платформ привели к повышению уровня абстракций, доступных для разработчиков, смягчив один из недостатков подхода CASE. Сегодня разработчики обычно используют более выразительные объектно-ориентированные языки (в частности, C++, Java и C#), а не Фортран или Си. Повторно используемые библиотеки классов и платформы поддержки приложений минимизируют потребность в изобретении общих и прикладных сервисов — транзакций, отказоустойчивости, оповещения о событиях, безопасности, распределенного управления ресурсами и т.д. Однако проблемы остаются. В центре этих проблем — сложность платформ, которая растет быстрее способности языков общего назначения ее маскировать. Популярные платформы промежуточного слоя J2EE, .Net и CORBA содержат тысячи классов и методов со многими сложными зависимостями и тонкими побочными эффектами, что требует значительных усилий при программировании и тщательной настройки. Более того, поскольку эти платформы быстро развиваются, разработчики тратят много сил на перенос кода приложений. Кроме того, код большинства приложений по-прежнему пишется на языках третьего поколения; значительных усилий требует выполнение интеграционных действий (в том числе развертывание, конфигурирование и поддержка качества системы). Так, на Java или C# трудно написать код, корректно и оптимально развертывающий распределенные системы с сотнями тысяч взаимосвязанных компонентов. Ситуацию не спасает даже использование описаний развертывания на языке XML из-за семантического разрыва между целью разработки и выражением этой цели в тысячах строк вручную произведенного XML-кода, синтаксис которого не имеет отношения ни к семантике прикладной области, ни к цели разработки.

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

Многообещающим подходом, направленным на решение этих проблем, является инженерия, управляемая моделями (Model-Driven Engineering, MDE). При использовании MDE разработка ведется на предметно-ориентированных языках моделирования DSML (Domain-Specific Modeling Language), в системах типов которых формализуется структура, поведения и требования приложения внутри соответствующей предметной области. В используемых метамоделях определяются связи между понятиями предметной области, точно специфицируется основная семантика и ограничения, ассоциируемые с этими понятиями. Разработчики применяют 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). Исторически методологии разработки программного обеспечения фокусируются в большей степени на совершенствовании средств собственно разработки, а не на создании инструментов, помогающих конструировать и интегрировать системы. Компонентное программное обеспечение промежуточного слоя (Enterprise JavaBeans, Microsoft .Net и CORBA Component Model) способствуют повышению уровня повторного использования кода на основе абстракции компонента. Однако при принятии на вооружение этих коммерческих технологий возникает разрыв между такими доступными и совершенными средствами разработки, как компиляторы и отладчики, и средствами, используемыми для компоновки, анализа и тестирования законченной системы. В результате разработчики продолжают выполнять интеграцию с использованием подручных методов. Управляемая моделями разработка (Model-Driven Development, MDD) — это развивающаяся парадигма, решающая многочисленные проблемы композиции и интеграции крупномасштабных систем и опирающаяся при этом на достижения в области технологий разработки (в частности, на компонентное программное обеспечение промежуточного слоя). Популярным вариантом MDD является модельно-управляемая архитектура (Model-Driven Architecture, MDA), предложенная и развиваемая консорциумом Object Management Group. В подходе MDA системы представляются с использованием языка моделирования общего назначения Unified Modeling Language и его конкретных профилей. Эти модели преобразуются в артефакты, выполняемые на разнообразных платформах, в частности, на EJB, .Net и CCM. В отличие от MDA, в другом варианте MDD, называемом модельно-интеграционными вычислениями (Model-Integrated Computing, MIC), для представления элементов системы и их связей используются предметно-ориентированные языки моделирования DSML, а также их преобразования в плаформенно-зависимые артефакты. Технология MIC создана и развивается в университете Вандербилта (www.isis.vanderbilt.edu/research/research.html#MIC). Концепция MIC успешно применена в разработке нескольких наборов инструментальных средств. Авторы статьи концентрируются на двух разработках. Язык платформно-независимого компонентного моделирования PICML (Platform-Independent Component Modeling Language) помогает разрабатывать, конфигурировать и развертывать системы с использованием CCM. Язык встроенных управляющих систем ECSL (Embedded Control Systems Language) поддерживает разработку распределенных встроенных автомобильных приложений. Оба набора инструментов построены с использованием общей среды моделирования GME (Generic Modeling Environment, www.isis.vanderbilt.edu/Projects/gme). GME представляет собой свободно доступную метапрограммируемую среду предметно-ориентированных разработок.

Следующая статья написана Адамом Чайлдсом (Adam Childs), Джессом Гринуолдом (Jesse Greenwald), Джорджем Джангом (Georg Jung), Мэтью Хузэ (Matthew Hoosier) и Джоном Хатклифом (John Hatcliff). Название статьи — «CALM и Cadena: метамоделирование для основанной на компонентах разработки продуктового ряда» (CALM and Cadena: Metamodeling for Component-Based Product-Line Development). Масштабные работы по созданию программного обеспечения все чаще основываются на продуктовых линиях. Разработчики при этом создают сходные семейства продуктов на основе повторно используемой архитектуры и общих прикладных компонентов. В данном подходе особое значение придается систематическому повторному использованию; следование ему может сократить время разработки и внедрения в производство, а также общую стоимость более чем на порядок. Данный подход поддерживается использованием компонентного программного обеспечения промежуточного слоя за счет обеспечения правильно определенных интерфейсов, которые предотвращают излишнюю привязку клиентского кода к низкоуровневым реализациям, и упрощения добавления и изъятия модулей, что способствует повторному использованию и развитию системы. Разработка на основе подхода продуктовых линий с использованием компонентных каркасов успешно зарекомендовала себя в многочисленных прикладных областях: от масштабных распределенных систем реального времени и встроенных систем, систем управления электросетями, систем управления производственными процессами до операционных систем пользовательского уровня и систем интеграции приложений для ПК. Системы, основанные на компонентном программном обеспечении, состоят из интегрирующего слоя, который абстрагирует среду исполнения и реализует сервисы и коммуникационные каналы, и сети взаимодействующих компонентов, выполняемых за счет сервисов промежуточного программного обеспечения и обеспечивающих исполнение бизнес-логики. Явное разделение инфраструктуры и модулей приложения, а также возможность простой компоновки этих модулей позволяет выделить в разработке три роли. Архитектор продуктовой линии формирует архитектуру системы, выбирает инфраструктурные платформы и организует процесс разработки, разработчик компонентов создает модули бизнес-логики, интегратор компонентов собирает компоненты в систему. Достижения в областях языков описания архитектур и сред метамоделирования позволяют скрыть сложности деталей низкоуровневой реализации путем определения структурных абстракций компонентов, интерфейсов, соединителей и компоновки системы, которые могут визуализироваться и анализироваться, а также управлять автоматической генерацией различных видов инфраструктурного кода. Однако эти средства моделирования часто не нацеливаются непосредственно на поддержку подхода продуктовых линий.

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

Статья «Автоматизация эволюции изменений в модельно-управляемой инженерии» (Automating Change Evolution in Model-Driven Engineering) написана Джефом Греем (Jeff Gray), Джейн Лин (Jane Lin) и Джинг Жанг (Jing Zhang). С расширением областей применения моделей программного обеспечения появилась срочная потребность в управлении сложной эволюцией изменений внутри представления моделей. Разработчикам нужна возможность быстрой и простой проверки различных проектных альтернатив среди бесчисленных и разнотипных конфигурационных возможностей. В идеале инструмент должен был бы производить имитационное моделирование каждой новой проектной конфигурации для определения того, каким образом некоторый аспект конфигурации (например, коммуникационный протокол) влияет на наблюдаемое свойство (например, на пропускную способность). Для поддержки такого уровня поддержки эволюции моделей инструмент должен обеспечивать две категории изменений, которые сейчас выполняются разработчиками вручную. Первую категорию составляют изменения, пересекающие иерархию представления модели. Примером является эффект изменения пропускной способности на качество обслуживания компонентов авиационного электронного оборудования, которые должны отображать в реальном времени видеопоток. Чтобы оценить последствия такого изменения, разработчик должен вручную обойти иерархию модели. Этот процесс утомителен и чреват ошибками, поскольку модели систем часто содержат иерархии глубиной в несколько уровней. Вторая категория изменений включает увеличение масштаба частей модели, что доставляет особые беспокойства при разработке масштабных встроенных систем реального времени, содержащих тысячи крупномодульных компонентов. Для этого типа изменения требуется создание нескольких модельных элементов и соединений между ними. Работа с инструментом моделирования для масштабирования базовой модели до модели с тысячами элементов требует поразительно большого числа операций с мышью и клавиатурой. Этот процесс чреват ошибками, например, можно забыть установить соединение между двумя задублированными элементами. Кроме того, ручное масштабирование влияет не только на эффективность моделирования, но и на корректность представления. Обе эти категории эволюции изменений существенно выиграли бы от автоматизации. С этой целью авторы разработали обобщенный процессор трансформаций для манипулирования моделями, названный ими C-Saw (Constraint-Specification Aspect Weaver). C-Saw — это подключаемый модуль для GME (см. выше). Для работы с изменениями, пересекающими иерархию, в C-Saw используется аспектно-ориентированный подход. Комбинация трансформации модели с компоновкой аспектов обеспечивает мощную технологию для быстрого преобразования унаследованных систем на основе высокоуровневых свойств, описываемых моделью. Далее, путем применения аспектно-ориентированных методов и преобразования программ небольшие изменения на модельном уровне могут инициировать очень крупные трансформации на уровне кода.

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

Достижения в областях разработки программ и технологий обработки информации привели к попыткам создания более сложных программных систем. Эти попытки демонстрируют неадекватность абстракций, обеспечиваемых современными языками высокого уровня. Возникает потребность в языках, моделях и технологиях, повышающих уровень абстракции, на котором задумываются, создаются и развиваются. OMG отвечает на это требование подготовкой версии 2.01 языка UML и инициативой MDA. Широкая осведомленность о проблемах ранних версий UML вместе с растущим интересом к MDD породили надежды, что разработчикам UML 2.0 удастся предложить версию языка с существенно сокращенным набором модельных понятий для точного и удобного описания самых разнообразных приложений. Ожидалось также, что в этой версии появится точная семантика, которая могла бы облегчить автоматизацию, требуемую для продвижения MDD за пределы традиционных возможностей CASE-средств. Те, кто не знаком с внутренней кухней стандартизации, находят поразительными размер и сложность стандарта UML 2.0. Действительно, конечные результаты кажутся далекими от посылок, которые мотивировали начало работы по крупному пересмотру языка. Многочисленные модельные понятия, плохо определенная семантика и легковесные механизмы расширений затрудняют изучение языка и его применение в среде MDD. Данные проблемы требуют решения, но не следует удивляться тому, что этот язык моделирования первого поколения далек от совершенства. Как отмечают некоторые разработчики UML, разработка языков моделирования все еще переживает период становления. Защитники UML 2.0 отмечают, что в стандарте отражен лучший производственный опыт применения моделирования. Они говорят про следующие основные усовершенствования. Улучшена поддержка UML как семейства языков за счет использования профилей и точек семантических вариаций, которые помечают части UML, умышленно оставленые без семантики, чтобы можно было нагрузить их семантикой, определяемой пользователями. Улучшена выразительность моделирования, включая моделирование бизнес-процессов, поддержку классификаторов повторного использования моделирования и поддержку архитектур распределенных неоднородных систем. Произведена интеграция семантики действий, которая может использоваться разработчиками для определения семантики моделей во время выполнения и обеспечивает семантическую точность, требуемую для анализа моделей и их трансляции в реализации. По мнению авторов, слишком высокая оценка UML и соответствующих технологий MDD столь же пагубна, как и несправедливая критика. Авторы статьи пытаются развеять облака рекламы, окружающие UML 2.0, и представить обоснованную оценку обеспечиваемой поддержки MDD.

Вне тематической подборки в февральском номере опубликована всего одна статья — «Распределенные встроенные интеллектуальные видеокамеры для приложений электронного наблюдения» (Distributed Embedded Smart Cameras for Surveillance Applications). Авторы статьи: Михаель Брамбергер (Michael Bramberger), Андреас Добландер (Andreas Doblander), Арнольд Майер (Arnold Maier), Бернхард Риннер (Bernhard Rinner) и Гельмут Швабах (Helmut Schwabach).

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

До следующей встречи, Сергей Кузнецов, kuzloc@ispras.ru.