В данной статье рассмотрены основные возможности, которые может обеспечить статический анализатор кода, с использованием директив OpenMP[3]  для повышения качества программного кода и скорости разработки. В материале представлены основные тезисы и положения, опираясь на которые можно создать готовый программный продукт.

Введение

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

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

Выявление логических ошибок

В тот момент, когда появились первые программы — появились и первые программные ошибки. И если на оси времени с каждым отсчетом уменьшалось множество ошибок случайного характера, связанных с внешними воздействиями на аппаратную составляющую, то ошибки, совершенные программистом при написании программного кода увеличивались наряду с объемами данного кода.  Принято считать, что ошибки классифицируются на два класса: синтаксические и логические. Если с первым типом всё предельно просто, за счет детерминированности грамматик используемых языков программирования, то второй тип становится на первое место, как тип, в результате которого случается большинство сбоев системы. Само собой разумеется, сбой в системе электронной домашней библиотеки на несколько десятков книг несущественен, но что делать, если из-за логической, или, правильней называть «человеческой», ошибки произойдёт сбой на крупном сервере, или, что хуже, на системе, влияющей на жизнь людей.

В данный момент происходит переход на использование параллельных систем. Как следствие, появление новых средств разработки  и новых ошибок, куда же без них. В статье «32 подводных камня OpenMP при программировании на Си++»[1] уже был поднят вопрос о проблеме логических ошибок при использовании данных директив.  Давайте рассмотрим, каким образом работают подобные статические анализаторы кода. Как мы увидим, создать свой инструмент достаточно просто. Так лучше уделить несколько рабочих дней на средство, которое будет помогать впоследствии, и использование которого сэкономит время отладки и тестирования приложения. Более того, навязывается вопрос, почему именно статический анализатор, а не динамический профилировщик?  Конечно же, получить информацию о работе программы необходимо, но на этапе динамического анализа мы получаем, как правило, сведения о скорости работы приложения, а на статическом этапе — представление о качестве кода в момент его написания.

Исходя из анализа, проведем классификацию рассмотренных ошибок, которые допускают программисты, используя OpenMP. Ошибки по степени угрозы можно разделить на два класса:

а) Критические – это ошибки, которые возникают вследствие нарушения программистом спецификации OpenMP. Зачастую подобного рода ошибки могут приводить к программным сбоям во время выполнения приложения. Именно поэтому такие ошибки должны соответствовать уровню критических, поскольку при их возникновении возможно нарушение целостности и работоспособности системы.

б) Предупреждения – это ошибки логического следования программного кода. Ведь точно неизвестна задумка программиста, и даже если на первый взгляд она выглядит абсурдной и нерациональной, вполне возможно, что это часть алгоритма. Поэтому степень опасности такого рода ошибки оценивается ниже критического, но факт ошибки присутствует, и не всегда сбой системы хуже, чем её неправильная работа. Ради примера достаточно вспомнить ошибку округления в процессорах Intel в 1993 году, или более критичную ошибку, которая привела к взрыву ракету Ariane 5 в 1996 году[2].

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

Визуализация параллельного кода

Получение информации в виде текста о возможных ошибках программирования — неотъемлемая часть фундаментального программирования. Однако в современном стремительно развивающемся мире на первые роли выходит наглядный графический материал, графы, автоматы и диаграммы, которые, как известно, воспринимаются человеком намного лучше. Что значит лучше? Значит, что параллельная программа, представленная в виде графа, на котором секции кода, которые будут выполняться в нескольких экземплярах и взаимодействие между ними (обращения к локальным и глобальным переменным, блокировки и т.д.) сразу дает представление о функционировании программы ещё до этапа компиляции. Конечно, это представление не может быть полным, поскольку весь спектр существующих проблем не охватить, однако изучая данным материал, отсеивается сразу большое множество ошибок, на которые впоследствии уже не будет необходимости обращать внимания при проведении динамического анализа.

Автоматизирование процесса создания параллельного кода

Итак, по большому счету все, что было рассмотрено выше, в той или иной мере уже рассматривалось и даже реализовано. Вопросы о том, зачем же тогда было написано столько текста, оставим на заключительную главу.  В этой же главе давайте задумаемся о процессе, несколько обратном тому, что был рассмотрен. Большое количество ресурсов, как человеческих, так и машинных отводится на контроль качества кода. Однако не следует забывать и о скорости разработки, а так же о командном взаимодействии при разработке. В настоящее время для проектирования масштабных приложений используется объектный подход, в нашу жизнь повсеместно входит моделирование с помощью диаграмм UML, по которым впоследствии можно, с помощью специализированного ПО, сгенерировать фактически рабочий костяк кода программы. К чему я подвожу? К тому, что контролировать качество параллельных программ с использованием OpenMP (и речь идёт о качестве применимом именно к OpenMP, а не к утечкам памяти, или ошибкам при написании процедур и т.д.) можно автоматически на этапе задания директив. И правда, зачем проверять на логические ошибки код, если можно не писать вручную, а сгенерировать шаблонный код для выбранных секций, который уже будет исключать логические ошибки. Не правда ли, так намного выгоднее по скорости и качеству? Автоматическая генерация классов и методов есть практически во всех средах разработки, добавим к этому автоматизированное распараллеливание, с проверкой связей, переобъявлений переменных и правильностей конструкций именно на этом этапе. Как результат, мы получим средство, которое повысит скорость разработки и качество кода на порядок, добавим графическое представление кода и получим прирост скорости анализа.

Заключение

Изначальной целью подготовки данного материала была цель обеспечить пищей для размышления тех, кто не хочет переплачивать деньги за существующие коммерческие средства анализа, а так же цель показать, что создание собственного инструмента в помощь не является какой-то заоблачной прерогативой крупных компаний. Данная сфера востребована и не так широко изучена, как хотелось бы, так что маневров для действий предостаточно. Более того, большинство современных сред программирования предоставляют свои SDK для внедрения в них дополнительных возможностей, поэтому о привязки к конкретной среде речи быть не может, кому-то по нраву иметь встроенный анализатор в таком гиганте как MS Visual Studio, а кому-то в GNU/Emacs.

P.S. Это первая моя запись в блоге, и соответсвенно отражает только вектор мысли, а не технические детали.

Список использованных источников

1.  Алексей Колосов, Евгений Рыжков, Андрей Карпов «32 подводных камня OpenMP при программировании на Си++», 20.05.2008, http://www.viva64.com/content/articles/parallel-programming/?f=32_OpenMP_traps_rus.html&lang=ru&content=parallel-programming

2.  «10 худших ошибок в программировании в истории человечества» http://www.libo.ru/libo794.html

3.  «OpenMP Specifications», http://openmp.org/wp/openmp-specifications, 15.05.2010