Классификация и сравнение языков описания архитектуры ПО (ADL)

Статья «A Classification and Comparison Framework for Software Architecture Description Languages» вышла в январском номере IEEE Transactions on Software Engineering за 2000 год (том 26, №1, стр. 70, 93). Авторы, Недад Медвидович (университет Южной Калифорнии) и Ричард Н. Тейлор (Калифорнийский университет в Ирвайне). К моменту написания в исследовательском сообществе не было согласия ни в том, что такое язык описания архитектуры (ADL, Architecture Description Language), ни в том, какие аспекты архитектуры он обязан моделировать, ни в том, какой из существующих ADL лучше подходит для конкретной задачи. Более того, границу между ADL и смежными видами языков, формальными спецификациями, языками межмодульных связей (MIL), языками симуляции, обычными языками программирования, почти никто не проводил чётко.

Авторы отталкиваются от рабочего определения архитектуры ПО, данного Мэри Шоу и Дэвидом Гарланом: архитектура, это уровень проектирования, который описывает элементы, из которых строится система, взаимодействия между этими элементами, паттерны, направляющие их композицию, и ограничения на эти паттерны. Опираясь на него, авторы формулируют собственное определение ADL: язык является ADL, только если он явно моделирует три вещи, компоненты, коннекторы и конфигурации (топологии их соединения). Без явного моделирования интерфейсов компонентов архитектурное описание вырождается в обычную диаграмму «коробки и стрелочки» без формальной семантики. Дополнительно, хотя и не строго обязательно, полезный ADL должен обеспечивать инструментальную поддержку (тулинг) для разработки и эволюции системы на основе архитектуры.

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

По этой рамке авторы разбирают и сравнивают десять реально существовавших на тот момент ADL: ACME (язык обмена архитектурными описаниями между разными ADL), Aesop (спецификация архитектур в рамках конкретных архитектурных стилей), C2 (архитектуры сильно распределённых, эволюционируемых и динамических систем, на базе которого велась собственная исследовательская платформа авторов), Darwin (сильно распределённые системы со строгой формальной семантикой на базе π-исчисления), MetaH (архитектуры в области навигации и управления, домен guidance/navigation/control), Rapide (моделирование и симуляция динамического поведения архитектуры через частично упорядоченные множества событий), SADL (формальное уточнение архитектур между уровнями детализации, доказательство корректности рефайнмента), UniCon (генерация связующего кода для соединения существующих компонентов через типовые протоколы взаимодействия), Weaves (потоковые архитектуры с высоким объёмом данных и требованиями реального времени) и Wright (моделирование и анализ, в первую очередь поиск взаимоблокировок в параллельных системах, через исчисление CSP). Отдельно авторы показывают, почему широко известные на тот момент нотации, конечно-автоматный формализм Statecharts, «химическая абстрактная машина» (CHAM) и даже UML, формально ADL не являются: они либо не выделяют коннекторы как самостоятельные сущности, либо не моделируют конфигурацию системы явно и отдельно от отдельных компонентов.

Сравнение по компонентам показывает, что все обследованные языки хорошо поддерживают интерфейсы и типы компонентов, но заметно хуже, эволюцию и нефункциональные свойства (производительность, надёжность, безопасность): только Aesop даёт хоть какую-то поддержку по всем шести категориям сразу, а языки C2 и Rapide вовсе не моделируют нефункциональные свойства компонентов. По коннекторам поддержка ещё слабее: Darwin, MetaH и Rapide вообще не считают коннектор самостоятельной («первоклассной») сущностью, связи между компонентами у них задаются «инлайново», без возможности переиспользовать или динамически переконфигурировать коннектор. На уровне конфигураций ни один ADL не удовлетворяет всем критериям сразу, ближе всех к этому подошли Rapide и Weaves.

Авторы приводят примеры промышленного масштаба использования этих языков: Wright применялся для моделирования и анализа Runtime Infrastructure, компонента High-Level Architecture Министерства обороны США для военных симуляций, чья исходная спецификация занимала свыше 100 страниц; SADL обеспечивал согласованность эталонной архитектуры и реализации системы управления электросетью Tokyo Electric Power Company объёмом 200 000 строк кода на Fortran 77; на C2 была построена собственная поддерживающая среда авторов, свыше 100 000 строк кода на Java плюс несколько миллионов строк во внешних компонентах; Weaves использовался в системах обработки телеметрии со спутников объёмом от 100 000 до более чем 1 000 000 строк; на Rapide моделировался и симулировался эталонный стандарт X/Open Distributed Transaction Processing документацией свыше 400 страниц.

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

Ключевые факты

Статья 2000 года (IEEE Transactions on Software Engineering, том 26, №1) авторства Недада Медвидовича и Ричарда Тейлора впервые даёт строгое определение ADL: язык является ADL, только если явно моделирует компоненты, коннекторы и конфигурации их соединения.
По этому определению авторы строят четырёхблочную классификационную рамку (компоненты, коннекторы, конфигурации, инструментальная поддержка) и сравнивают по ней десять существовавших на тот момент языков: ACME, Aesop, C2, Darwin, MetaH, Rapide, SADL, UniCon, Weaves, Wright.
Statecharts, «химическая абстрактная машина» (CHAM) и UML в исходном виде формально не являются ADL по этому определению, они не выделяют коннекторы как самостоятельные сущности или не описывают конфигурацию системы отдельно от компонентов.
Приведены примеры промышленного применения: Wright, для Runtime Infrastructure военных симуляций Минобороны США; SADL, для системы управления электросетью Tokyo Electric Power Company (200 000 строк Fortran 77); C2, собственная среда авторов на 100 000+ строк Java.
Главный итоговый вывод: ни один язык не покрывает рамку целиком, хуже всего у всех обследованных ADL поддержаны эволюция архитектуры, уточнение/прослеживаемость изменений, динамика во время выполнения и нефункциональные свойства.

Почему это важно

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

Кому это важно

В первую очередь, исследователям и инженерам в области программной архитектуры, разработчикам инструментов моделирования и анализа архитектуры, а также командам, проектирующим крупные распределённые, параллельные или системы реального времени, где ошибки на архитектурном уровне обходятся особенно дорого. Статья стала одной из базовых ссылок в области software architecture research: на неё опирались последующие работы по UML-профилям для архитектуры, по языку обмена ACME и по появившимся позже промышленным нотациям вроде AADL.

Как это применить

Практическая ценность статьи, не в конкретном языке, а в самой классификационной рамке и сводных таблицах. Инженер, выбирающий инструмент для архитектурного моделирования, может использовать таблицу «фокус применения» из статьи: ACME годится для обмена архитектурными описаниями между разными ADL, UniCon, для генерации связующего кода между готовыми компонентами, Wright, для анализа взаимоблокировок в параллельных системах, SADL, для формально доказуемого уточнения архитектуры между уровнями детализации, Rapide и Weaves, для симуляции и анализа систем с интенсивным потоком данных. Общий принцип рамки, оценивать язык по шести осям для компонентов и коннекторов (интерфейс, типы, семантика, ограничения, эволюция, нефункциональные свойства) плюс девяти осям для конфигурации, применим и к современным средствам моделирования.

Можно ли доверять

Да: это рецензируемая статья в IEEE Transactions on Software Engineering, одном из самых авторитетных журналов по программной инженерии, авторы которой (Недад Медвидович и Ричард Тейлор), признанные исследователи в области программной архитектуры, а сама статья на протяжении многих лет остаётся одной из наиболее цитируемых работ по классификации ADL. В тексте подробно приведены конкретные примеры промышленного применения каждого из рассмотренных языков со ссылками на первоисточники.

Риски и подводные камни

Материал сугубо академический и датирован 2000 годом: часть разобранных языков (Darwin, MetaH, UniCon, Weaves и другие) с тех пор либо вышли из активного использования, либо заметно изменились, поэтому статью стоит читать как исторический и методологический источник, а не как актуальный гид по выбору инструмента для новых проектов. Сами авторы отмечают ограничение собственной рамки: она показывает, какие признаки поддерживает каждый язык, но не отвечает на вопрос, какие конкретно конструкции необходимы для решения той или иной задачи и какие из них взаимозаменяемы, а какие, взаимодополняемы; по их собственным словам, для этого нужна отдельная, более детальная feature-based классификация.

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

— определение архитектуры ПО по Мэри Шоу и Дэвиду Гарлану, приведённое в статье как рабочее