← Назад в библиотеку

Источник: Воробьёв Л.О. К вопросу о самосинтезируемости программ / Л.О. Воробьёв, А.В. Григорьев . // Материалы VI Международной научно-технической конференции Современные информационные технологии в образовании и научных исследованиях (СИТОНИ-2019) . — Донецк : ДонНТУ , 2019. — С. 256–266.

К вопросу о самосинтезируемости программ

Воробьёв Л.О. , Григорьев А.В.
ГОУ ВПО Донецкий национальный технический университет (г. Донецк)

Авторы в статье излагают современные средства автоматизации процессов разработки программного обеспечения: кодирования, тестирования. Рассмотрены основные этапы автоматизации сборки программного продукта. Объектно-реляционное отображение представлено читателю, как средство автоматического синтеза программ для поддержания базы данных. Упомянуто функциональное программирование, как новый подход к алгоритмизации. Аспектно-ориентированное программирование представлено способом передачи опыта программистов.

Введение

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

В настоящее время появилось большое количество технологий автоматизация процесса программирования, таких как паттерны, шаблоны, фреймворки, системы пользовательского программного интерфейса и т.д.

Однако, современная индустрия разработки программного обеспечения (ПО) продолжает упорно игнорировать достижениям науки прошлого столетия.

К таким важнейшим достижениям недавнего прошлого следует отнести теорию формальных грамматик.

Т. о., актуальным является анализ, насколько новые технологии программирования логически связаны с известными, классическими технологиями программирования, такими как формальные грамматики.

Целью данной работы является:

Цель доклада

Охарактеризовать современное состояние автоматизации процессов разработки программного обеспечения.

Анализ проблемы

Вопрос самопрограммируемости ЭВМ вызывает много споров. Решение прикладных задач на ПК выполняется с помощью программного обеспечения, которое создаётся людьми.

Иными словами, человек обеспечивает машину программами, которые он сам и создаёт с помощью машины. Однако зачем человеку утруждать себя выполнением данной трудозатратной операции, если можно часть работы переложить на машину.

На арену выходит персональный компьютер (ПК) с мощной аппаратной подготовкой. Его призвание: сделать всё, чтобы облегчить программирование и другие задачи, связанные с созданием ПО (табл. 1). По таблице видно, что есть два вида работ по созданию ПО: хорошо автоматизированные и – плохо автоматизированные. Человек научил машину выполнять целый ряд автоматизируемых операций по созданию ПО. Однако большую часть работы приходится на его труд.

Табл. 1 — Классификация работ по созданию ПО
Работа человека (слабая автоматизация) Работа машины (хорошая автоматизация)
кодирование алгоритма компиляция и выполнение
документирование генерация документации
инспектирование статический анализ кода
перепроектирование с целью повышения качества проекта обратное проектирование с целью документирования
составление диаграмм UML генерация кода по диаграмме классов
автоматизация сборки выполнение сборки программы
установка программы автоматическое развёртывание
написание тестов выполнение тестов

Рассмотрим данные работы детальнее.

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

Человек кодирует алгоритмы, а машина их компилирует. Поменяем местами человека и ПК. Теперь машина придумывает алгоритмы, а человек должен их привести в действие. Пока машина диктует инструкции на своем языке, человеку приходится выполнять эти действия. Рано или поздно человеку надоедает выполнять однотипные операции, и у него появляется желание сократить, изменить порядок действий. А машина продолжает диктовать инструкции. Напрашивается вопрос: а зачем они нужны, ведь человек и без машины способен решать, какие действия ему выполнять. А машина, наоборот, нуждается в таком руководстве. Это свойство называется способность волеизъявления, которой у машины нет. Машина выполняет только те действия, которые нужны человеку, и только тогда, когда её заставят их выполнять.

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

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

В настоящее время можно назвать следующие способы автоматизации кодирования алгоритмов:

  1. синтез по графическому образу;
  2. голосовой способ ввода кода программы;
  3. способ автоматического деформирования команды по первым символам;
  4. совершенствование языков программирования в рамках обычных парадигм программирования;
  5. использование новых парадигм программирования, таких как функциональное программирование и т.д.

Рассмотрим названные случаи детальнее.

Использование графических языков программирования, для синтеза кода может выполняться разными путями. Например, язык Scratch использует языковые схемы или шаблоны (заготовки) как инструмент автоматизации формирования кода. В частности, Scratch способен облегчить кодирование алгоритмов при обучении программированию. Процесс кодирования алгоритмов производится путем перетаскивания заготовок готовых блоков кода в окне редактирования. Влияние языка Scratch заметно в проекте по визуальному программированию для языка Java [4].

Можно так же назвать графический язык ДРАКОНа [5], на котором алгоритмы описывают в виде блок-схем, пригодных к выполнению (интерпретации). Однако названный язык имеет ряд недостатков, обусловленных самой парадигмой визуального программирования:

Ввод исходного кода с помощью голоса есть прорыв в области ручного кодирования. На платформе CMU Spinx программа с помощью формальных грамматик дополняла речь диктора и автоматизировала клавиатурный ввод в программировании [6]. Однако, при использовании этого подхода ошибки распознавания неизбежно отражаются на корректности программы.

Технология IntelliSence предоставляет пользователю возможность быстрого ввода кода путём дописывания названия функции по первым буквам. Эту технологию приписывают Microsoft, однако такая возможность реализована в других IDE (интегрированная среда разработки). Так, например, программа ctags выполняет индексацию исходного кода, а среда разработки предлагает выбор идентификатора при вводе первых букв.

Автоматизация кодирования алгоритмов может достигаться за счет совершенствования языков программирования. Это заметно в сравнении JVM ориентированных языков, таких как Java, Scala, Kotlin, Swift. Каждое обновление языка учитывает специфику разрабатываемого на нём (целевого) ПО в момент своего выхода. Новый язык призван упростить те участки кода существующего ПО, которые чересчур запутаны из-за нехватки выразительных средств языка. К примеру, есть в Си т. н. сигналы, которые позволяют программе реагировать на системные прерывания [7]. И для того, чтобы определённое действие выполнялось после завершения работы программы, нужно было создать подпрограмму и передать адрес этой подпрограммы регистратору сигналов. Поскольку название этой подпрограммы нигде больше не употреблялось, новый стандарт 2011 года добавил в язык анонимные функции, которые заметно упростили регистрацию обработчика сигналов.

Поскольку ПО создавалось в разное время, были использованы разные парадигмы и подходы к организации программного кода. Новые концепции ломают сложившиеся стереотипы о кодировании алгоритмов. Например, функциональная парадигма внесла существенные изменения в код, превратив его из описания процедур в описание функций. Функциональный подход сменил тактику написания кода с декомпозиции на детализацию; заменил циклы на рекурсию и вызов подпрограммы на композицию.

Функциональное программирование это, конечно, хорошая практика, но не до такой же степени, как в Haskell. Там оно пытается избавиться от оператора присваивания. В результате чего для каждого результата вычисления создаётся новая переменная и выделяется область в памяти программы.

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

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

Известно, что основными критериями качества ПО являются корректность его работы и отсутствие вязкости программного кода [8]. Последнее необходимо для оперативного внесения изменений в логику обработки информации с целью обеспечения соответствия новым требованиям.

Традиционный подход к установлению корректности программы – это модульное тестирование [9]. Однако при большом количестве строк кода вариантов тестового случая может быть много и написание модульных тестов к такой программе затруднительно. Развитием технологии модульного тестирования, способное упростить автоматизацию этого процесса, является технология фаззинга [10]. В этом случае программа сама генерирует заведомо некорректные тестовые наборы и сообщает о том, какой из них привел к сбою. Для такой процедуры следует только описать структуру входных данных и установить критерии правильной работы программы.

Фаззинг позволяет методом случайной генерации тестовых наборов выявить ошибки в программе, которые при обычном тестировании не будут обнаружены. Для эффективного использования этой технологии также применяется инструментирование для анализа покрытия кода [11].

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

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

Под процессами поддержания проекта подразумевается выполнение определённых операций над исходным кодом [12]. Для того, чтобы автоматизировать этот процесс, используются системы автоматической сборки.

По степени автоматизации системы сборки бывают:

Табл. 2 — Системы сборки проектов
Язык проекта Тип автоматизации
Императивный Декларативный
С, С++, Pascal Make Automake, CMake
Java Ant Maven, Gradle

Пример императивного подхода: файлы для системы Make включают:

Для больших проектов такой подход автоматизации сборки становится слишком утомительным, поэтому мировое сообщество придумало ряд средств, автоматизирующих создания make-файлов: Automake и Cmake [13].

Файл описания проекта для CMake носит название CMakeLists.txt и содержит:

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

Аналогичное соответствие сложилось в системах сборки для Java: Ant преследует императивный подход описания алгоритма сборки, а Maven и Gradle — декларативный подход.

В системе сборки Maven описание проекта содержится в XML файлах. Gradle избавляет от необходимости использования этого избыточного формата, предлагая описывать проект на языке Groovy. Описание проекта для этих систем сборки содержит:

Отличительной особенностью Maven и Gradle является то, что они автоматически загружают и подключают все используемые библиотеки проекта. Кроме того, список исходных файлов для сборки формируется автоматически, поскольку их расположение задано стандартом.

Система сборки проектов автоматизирует не только компиляцию программы, но и её инсталляцию. Так, например для интерпретируемых языков программирования библиотеки поставляются в виде архивов, которые автоматически распаковываются в директорию с библиотеками. Для создания таких архивов с библиотеками, написанными на языке Ruby, используется система Rake. Скрипт автоматизации сборки Rakefile включает:

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

Современные САПР ПО

Ручной ввод текста программы есть обременительная задача для любого человека. Программист давно осознал это, и старается избежать ручной работы путем использования современных САПР ПО – интеллектуальных IDE.

Использование проверенных опытом методов разработки является хорошей практикой в программировании, которая избавляет от множества проблем при создании программ. Передачу опыта и методов разработки следует автоматизировать. Неверно считать, что этим никто не занимается. Вот, к примеру, есть практика регистрации ошибок в системном журнале [12,14]. Всегда с библиотеками для ведения журнала событий подсовывается возможность записи в журнал разных сообщений. Для этого предусмотрена стандартизованная типология записей в журнале, которая позволяет фильтровать записи, попадающие в журнал.

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

Отлично, теперь автоматизирован процесс записи в журнал при обработке исключений. Теперь, ведь, необходимо, чтобы все проекты предусматривали создание файла журнала. Но тут уже самому нужно определить, как будет называться файл журнала, и настроить формат записи в нем.

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

Есть другой способ автоматизации рутинной операции ведения журнала. Вместо того, чтобы для каждой библиотеки логирования создавать отдельный шаблон, разработчик библиотеки логирования может создать по одному шаблону блока исключения для каждой среды разработки. Но теперь проблема в том, что среды разработки существуют не в единственном числе, и не каждый разработчик библиотеки логирования согласится писать шаблоны кода для таких IDE, как vim или emacs. Остается надеяться на энтузиастов, которые разрабатывают плагины vim или правила для Visual Studio.

Для того то и создано аспектно-ориентированное программирование (АОП), которое позволяет выделить логирование в отдельную сущность, наподобие класса. Тогда передача опыта упрощается: аспекты логирования можно без проблем подключить к своему проекту.

Большое количество команд текстового редактора vim запомнить невозможно, поэтому популярностью пользуются также среды разработки с графическим интерфейсом. IntelliJ IDEA и целый ряд подобных ей сред разработки для разных языков программирования от компании JatBrains, вытесняют всех предшественников на рынке IDE. И уже вытеснила все IDE для языка Java. На то есть веские причины, почему разработчики Java предпочитают IDEA вместо аналогичных Eclipse и NetBeans.

CLion — это единственная среда разработки для языков C|C++, которая впервые автоматизировала работу с проектами, которые используют CMake в качестве средства сборки. Эта среда разработки использует файлы CMakeLists.txt для описания проектов, что позволяет полностью автоматизировать рутинные операции добавления новых файлов исходного кода в проект. При добавлении файла исходного кода CLion автоматически обновляет CMakeLists.txt, добавляя в его список новый файл. А при обновлении этого текстового файла автоматически генерируется Makefile для всего проекта.

Кроме того, начиная с третьей версии CMake может сам автоматизировать внесение новых файлов исходного кода в список с помощью команды особенно, при переводе проектов из Visual Studio в CMake формат. Можно автоматически перевести CMake проект в Visual Studio, а наоборот — нет. И действительно, старые проекты Visual Studio имеют весьма скудные возможности по расширению стандартного алгоритма сборки. Вспомните, как мучительно происходит добавление библиотеки в список файлов для компиляции. В CMake это все автоматизировано. Достаточно добавить одну строку, и система сборки сама найдет библиотеку и подключит её к исполняемому файлу при компиляции.

Единственное, чем может похвастаться Visual Strudio – это отладчик. Другие IDE (Atom, Clion, Eclipse CDT) предоставляет графический пользовательский интерфейс для отладки программы, а основную работу возлагают на отладчик gdb с командным интерфейсом.

Поскольку основная рутинная работа программиста в создании однотипных операций, которые единообразно выполняются вне зависимости от специфики задачи, CLion позволяет сгенерировать стандартную реализацию конструктора, методов доступа к полям, а оставшаяся часть класса — на усмотрение пользователя.

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

В C++ явно не хватает рефлексии. Это хорошо прочувствовали разработчики системы объектно-реляционного отображения ODB [15]. При использовании этого средства программист описывает структуру базы данных с помощью директив препроцессора. Система ODB использует эту информацию, чтобы синтезировать процедуры записи обозначенных с их помощью структур в реляционные таблицы.

Недостатком генераторов программного кода являются устаревание стандарта, на котором генерируется код. ODB генерировал код в стандарте 2014 года. Некоторые возможности этого языка объявлены устаревшими в 2017 году. И теперь то, что генерируется системой ODB, не пригодно для использования с новым компилятором языка C++. Кто возьмётся обновить генератор кода, если каждый третий год выходит новый стандарт.

Другой способ автоматической реализации метода состоит в непосредственной генерации нового кода при компиляции. Несмотря на то, что в C++ с помощью метапрограммирования на шаблонах можно строить целые алгоритмы для компилятора [16], в нём никак нельзя программно определить название процедуры, которая выполняется. В языке Java эта проблема решена с помощью аннотаций: реализована библиотека Hibernate, которая позволяет генерировать SQL запросы, зная только название процедуры и её аргументы. Используя аннотации, обозначаются поля структуры, что используется для автоматического управления базой данных.

Выводы

В сфере производства ПО автоматизация идет большими темпами, нежели в других сферах. Объясняется это тем, что для автоматизации программирования не нужно привлекать специалистов из других областей. Сами разработчики желают упростить себе жизнь, и придумывают разные инструменты для удовлетворения своих потребностей. В отличии от, к примеру, САПР самолетов, там привлекаются авиаконструктор, который выдвигает свое видение будущей программы, для САПР ПО сам исполнитель является заказчиком и согласованность требований существенно ускоряет разработку подобных инструментов.

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

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

В общем случае автоматизация программирования достигается путем создания языков программирования, библиотек и шаблонов программного кода. Так, идея концептуального программирования нашла свое воплощение в языке программирования XL [17].

Литература

  1. Григорьев А.В. Анализ специфики задачи проблемной адаптации САПР в современных условиях / А.В. Григорьев . // Наукові праці ДонНТУ . — № 13 (185). — Донецк , 2011. — С. 208–221. — URL: http://ea.donntu.ru:8080/hand... .
  2. Тыугу Э.Х. Концептуальное программирование / Э.Х. Тыугу . — М. : Наука , 1984. — 255 с.
  3. Ильин В.Д. Система порождения программ /В.Д. Ильин / В.Д. Ильин . — М. : Наука , 1989. — 264 с.
  4. Воробьёв Л.О. Разработка интегрированной CASE-системы для обучения студентов программированию / Л.О. Воробьёв, В.А. Полетаев, Д.Д. Моргайлов . // Информатика, управляющие системы, математическое и компьютерное моделирование в рамках II форума Инновационные перспективы Донбасса (ИУСМКМ-2016): VII Международная научно-техническая конференция . — Донецк : ДонНТУ , 2016. — С. 163–168. — URL: http://iuskm.donntu.ru/electr... .
  5. Паронджанов В.Д. Как улучшить работу ума: Алгоритмы без программистов — это очень просто! / В.Д. Паронджанов . — М. : Дело , 2001. — 360 с. — URL: https://drakon.su/_media/bibli... .
  6. Бакаленко В.С. Разработка речевого распознавателя исходного кода программ в инструментальной среде CMU Sphinx. / В.С. Бакаленко . // Информатика и кибернетика . — № 1(11). — Д. : ДонНТУ , 2018. — С. 10–15. — URL: http://infcyb.donntu.ru/A_11... .
  7. Робачевский А.М. Операционная система Unix / А.М. Робачевский . — СПб. : БХВ-Петербург , 2002. — 528 с.
  8. Мартин Р.К. Быстрая разработка программ. Принципы, примеры, практика: Пер. с англ. / Р.К. Мартин, Дж.В. Ньюкирк . — М. : Вильямс , 2004. — 725 с. — URL: http://www.williamspublishing.... .
  9. Степанченко И.В. Методы тестирования программного обеспечения: Учебное пособие / И.В. Степанченко . — Волгоград : ВолгГТУ , 2006. — 74 с. — URL: http://window.edu.ru/resource/... .
  10. Фаззинг, фаззить, фаззер: ищем уязвимости в программах, сетевых сервисах, драйверах [Электронный ресурс]. // Журнал Хакер . — 2010. — URL: https://xakep.ru/2010/07/19/52... .
  11. Руденко О.Г. Методы динамического иструментирования кода / О.Г. Руденко, С.В. Мирошниченко . // Системы обработки информации . — № 6(102). — Харьков : ХНУРЭ , 2012. — С. 134–138. — URL: http://nbuv.gov.ua/UJRN/soi_20... .
  12. Clark M. Pragmatic Project Automation. How to Build, Deploy, and Monitor Java Applications / M. Clark . — The Pragmatic Bookshelf , 2004. — 172 pp. — URL: http://index-of.es/Programming... .
  13. Дубров Д.В. Программирование: система построения проектов CMake. Учебник для магистратуры / Д.В. Дубров . — М. : Издательство Юрайт , 2016. — 422 с. — URL: https://aldebaran.ru/author/vl... .
  14. Солтер Н.А. C++ для профессионалов : Пер. с англ. / Н.А. Солтер, С.Д. Клепер . — М. : ООО И.Д. Вильямс , 2006. — 912 pp.
  15. Code Synthesis Tools. C++ Object Persistence with ODB [Электронный ресурс]. — 2015. — URL: https://www.codesynthesis.com/... .
  16. Вандевурд Д. Шаблоны С++. Справочник разработчика, 2-е изд.: Пер. с англ. / Д. Вандевурд, Н.М. Джонаттис, Д. Грегор . — СПб. : ООО Альфа-книга , 2018. — 848 с. — URL: http://diggerdnepr.ddns.net/wp... .
  17. XL Extensible Language The Art of Turning Ideas into Code [Электронный ресурс]. — 2010. — URL: http://xlr.sourceforge.net/ .
← Назад в библиотеку