: интерфейс будущего для языка из прошлого

Минобороны исключительно серьёзно подошло к проекту нового языка: помимо изначально сформулированных требований к самому языку, помимо международного конкурса, они выработали комплекс требований к программному окружению Ады (так называемые требования APSE - Ada Programming Support Environment), где подробно описали, каковы должны быть компоненты Ада-окружения, включая отладчики, редакторы, профилировщики и прочие инструменты. Причем эти требования прошли длительный этап проектирования, уточнений, дополнений и т. д. Эволюция этих требований - отдельная и довольно интересная история (собственно, как и все, относящееся к истории этого языка).

Если не требования APSE как таковые, то общий дух инициатив вокруг Ады вызвал к жизни достаточно инновационные по тем временам проекты. И одной из таких инициатив стал проект семантического интерфейса Ада-программ: ASIS (Ada Semantic Interface Specification). Из названия понятно, что речь шла о создании унифицированного программного интерфейса для доступа к Ада-про- граммам. Иными словами, ASIS определяет набор функций (там они называются queries, «запросы»), посредством которых можно получать всю необходимую информацию о программе - от её структуры (объявления, операторы, процедуры, пакеты и т. д.) до семантических свойств её составных частей. Запросы покрывают весь язык, как он определен в стандарте.

Вот как описывает[1] назначение ASIS мой коллега и товарищ Сергей Рыбин:

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

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

Спецификация ASIS не определяет, каким образом получить из программы семантическую информацию, необходимую для реализации запросов; механизм её получения считается проблемой реализации. Так откуда эту информацию можно извлечь? Самый очевидный и «наивный» ответ: для этого следует написать некоторый распознаватель, который будет делать синтаксический и семантический разбор Ада-программы и поставлять ASIS’y полученную в процессе разбора информацию. Но такой распознаватель должен быть достаточно мощным и развитым (он должен уметь извлекать всю необходимую информацию), и потому делать такой распознаватель - трудно и долго. Да в этом и нет особого смысла, поскольку фронтальная часть любого Ада-компилятора делает в точности то же самое. Стало быть, можно воспользоваться информацией из внутренних структур какого-нибудь Ада-компилятора и реализовать ASIS-запросы как функции доступа к этим внутренним структурам. И получается, что любая разумная реализация ASIS будет с необходимостью представлять собой пару «Ада-комгшлятор + собственно ASIS-запросы». А раз так, то чтобы реализовать ASIS, нужно иметь компилятор, к внутренним структурам которого можно получить доступ. Очевидно, что коммерческие компиляторы (а их для Ады появилось довольно много) такого доступа не предоставляют - это типичные «чёрные ящики»: они получают на входе текст Ада-программы и выдают сгенерированный для неё объектный код. Никаких дополнительных возможностей, как и абсолютное большинство традиционных компиляторов, они не обеспечивают.

По существу, единственный Ада-инструмент, который можно использовать для реализации ASIS-запросов, - это свободный компилятор GNAT, созданный в рамках проекта gcc. Исходники GNAT’a открыты, их можно использовать свободно, без каких-либо лицензионных отчислений. Поэтому в GNAT можно встроить реализацию ASIS-запросов, которые для получения необходимой информации будут напрямую обращаться к внутренним структурам трансляции. Есть и альтернативный подход - из исходников GNAT’a выделить его фронтальную часть, отбросив генерацию объектного кода, и объединить её с реализацией ASIS-запросов. В любом случае, наиболее перспективный подход - это связка компилятора (или его части) и собственно реализации ASIS. Ну и, стало быть, всё вместе можно назвать ASIS-for-GNAT.

Разработка Ада-компилятора GNAT началась в ныо-йоркском университете по инициативе Минобороны США. К настоящему времени это

один из лучших компиляторов данного языка - если не самый лучший.

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

Очень интересный момент: компилятор изначально задумывался как свободный, с открытыми исходными текстами - и при этом финансировался военным ведомством! Чтобы инструмент, предназначенный для разработки оборонных систем, распространялся свободно по всему миру, да при этом ещё и субсидировался бы самими военными - как хотите, но для тех, кто поработал хотя бы немного в аналогичных советских структурах, такой «ход» представлялся (да и сейчас кажется) чем-то совершенно невероятным... Вообще-то, для непредвзятого наблюдателя логика Минобороны выглядит совершенно разумной, но с точки зрения советских традиций и реалий такое и вправду немыслимо. (Да что там говорить о «советских реалиях», когда вполне современное российское ПО автоматизации подсчёта голосов на выборах засекречено серьёзнее, чем новейшие системы вооружений! - хотя, казалось бы, уж оно-то - если, конечно, целью его создания было обеспечить честный подсчёт голосов - должно бы быть совершенно открытым и доступным для самого придирчивого анализа...)

Сейчас компилятор, оставаясь, в принципе, в таком же «открытом» статусе, что и раньше, развивается фирмой AdaCore (образованной разработчиками компилятора) уже самостоятельно, без поддержки со стороны каких-либо госструктур. Компания эта небольшая, располагается в Нью- Йорке и Париже и наряду с развитием компилятора и других Ада-ориен- тированных инструментов и технологий предоставляет также услуги по их поддержке и сопровождению для фирм - разработчиков ПО. Среди ее клиентов много малых и больших фирм, в том числе крупнейшие мировые гиганты вроде Боинга.

  • [1] Рыбин С. И. Ада-технологии terra incognita для индустрии и образования // Первая международная конференция «Современные информационные технологии и образование». Московский государственный университет, сентябрь 2005.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >