наверх

«Открытые системы» , № 02, 2006 152 прочтения

Обещания и просчеты UML 2.0

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

Сергей Кузнецов

Темой февральского номера журнала 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 представляет собой свободно доступную метапрограммируемую среду предметно-ориентированных разработок.

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

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

Страница 1 2

Комментарии


26/04/2012 №03

Анонс содержания
«Открытые системы»

Подписка:

«Открытые системы»

на месяц

c