О технологии программирования, ориентированной на минимизацию ошибок Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.43

Доренская Е.А., Семенов Ю.А.

НИЦ «Курчатовский! институт» ФГБУ «ГНЦ РФ ИТЭФ», г. Москва, Россия

О ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ, ОРИЕНТИРОВАННОЙ НА МИНИМИЗАЦИЮ

ОШИБОК

Аннотация

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

Ключевые слова

Язык описания проблемы; минимизация программных ошибок; принцип "many eyes"; компьютерная программа; граф диалога компьютер-программист; банк алгоритмов; метод древовидных графов; граф описания регулярных выражений.

Dorenskaya E.A., Semenov Y.A.

Institute for Theoretical and Experimental Physics, Moscow, Russia

ABOUT THE PROGRAMMING TECHNIQUES, ORIENTED TO MINIMIZE ERRORS

Abstract

The article focuses on the idea of creating a language for the description of the problem, not an algorithm. It talks about how by using it one can minimize software errors and simplify the process of programming. It also talks of the creation of a bank of algorithms. It is proposed a method of program modification, based on input parameters. The method is described by tree graphs as a method of dialogue between the computer and the programmer and given the scheme of the program based on this method.

Keywords

Language for description of problem; minimizing programming errors; principle of "many eyes"; computer program; dialog computer-programmer; bank of algorithms; method of tree graphs; graph of description for regular expressions.

Введение

Сегодня от качества компьютерных программ зависят практически все стороны человеческой жизни, включая здоровье [1]. По этои причине важно минимизировать число программных ошибок. На сегодняшний день хорошим результатом по надежности программного обеспечения считается 0,5 ошибок на 1000 строк кода (это результат использования статических и динамических code-checker^ [2], например, для ядра ОС Микрософт Windows). Но для многих проблем это слишком плохо.

Впервые данную тему мы подняли в 2013г на семинаре ВМК, где обзор по проблемам программных ошибок делал В.П. Иванников.

В даннои статье мы рассматриваем частную задачу оптимизации программирования с целью

минимизации ошибок. Более общая задача уже была рассмотрена в [3,4,5,6,12].

Цель исследования

Нашеи целью является минимизация числа программных ошибок. Проблема в том, что полностью выявить и устранить ошибки невозможно. Не существует даже хороших методов оценки числа имеющихся программных ошибок [7]. Одним из эффективных проверенных способов сокращения числа ошибок является использование программы большим числом пользователей с последовательным выявлением и корректировкой ошибок (принцип "many eyes").

Основная часть

Одним из мотивов программы "open source" является минимизация количества программных

ошибок за счет многократной! проверки для самых разных приложений. Данная работа является продолжением и развитием идеи, изложенных в [8].

Другим подходом, которьш можно совмещать с методикои many eyes, является минимизация участия человека в написании программы.

Оптимальным решением проблемы

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

Судя по всему, для этого потребуется искусственный интеллект. К сожалению, он пока слаб [9], но что хуже, не очевидно, что он позволит получить меньшее число программных ошибок по сравнению с обычным программистом [10].

В процессе формирования исполняемого программного модуля могут использоваться библиотечные программы, макросы, include (программные заготовки и т.д.).

Если раньше задача решалась

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

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

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

Все модули исполняемой программы должны быть написаны на одном и том же алгоритмическом языке.

Следует иметь в виду, что описание проблемы на мета-языке (ML) может также содержать в себе ошибки, могут быть ошибки и в самом макротрансляторе. Все это будет приводить в ошибкам в конечнои программе. Но так как макро-транслятор будет использоваться часто, можно ожидать, что ошибки в трансляторе будут устранены относительно быстро. Ошибки же в описании проблемы должны выявляться в процессе отладки и тестирования программы. Но так как текст описания должен быть относительно коротким, можно предположить, что ошибок там будет мало.

Текст описания проблемы на макроязыке сначала анализируется на предмет выявления области проблемы (граф диалога компьютер-программист). Далее предпринимается попытка разделить проблему на субзадачи. После этого делается попытка найти описание алгоритма, соответствующее каждои из субзадач. Для каждого из наиденных алгоритмов определяются списки входных и выходных параметров. Для каждои из функции, если ее описание не удалось наити в банке описании алгоритмов, создается свои программный модуль или пакет модулеи, выполненных согласно правилам Хольцмана [11].

Стоящая перед нами проблема может быть разделена на несколько уровней:

1. Создание банка алгоритмов, где ошибки минимизируются за счет многократного использования программы большим числом пользователей [8];

2. Для проблем, которые могут быть описаны древовидным графом, текст программы формируется из модулеи, взятых из банка алгоритмов, а также модулеи, написанных самим программистом (возможно помещение этих модулеи в банк алгоритмов);

3. Сложные проблемы, характеризуемые графом с циклическими структурами, программа формируется из стандартных исполнительных модулеи разного уровня.

Если модель языка описания проблемы отличается от описанной выше, то:

а. Для описания проблемы используется естественный язык;

б. Создается специальный язык, а транслятор переводит описание на один из алгоритмических языков высокого уровня, например, на СИ;

• В варианте "а" потребуется привлечение искусственного интеллекта, с неочевидными последствиями для частоты программных ошибок;

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

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

Метод вариации программ на основе входных параметров

Все существующие программы вариативны. В одних обстоятельствах используется один

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

программирования, понижает также и вероятность программных ошибок.

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

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

Далее часть кодов можно ввести внутрь стандартных модулеи, сделав их более универсальными. Эти коды (сходные с макросами, применяемыми в некоторых языках) будут генерироваться программно на основе параметров программы, заданных извне. Туда попадут части программ, адаптирующих данные для работы стандартных модулеи. Это могут быть описания регулярных выражении!. Программы подготовки данных, например, для работы Спир^ и т.д. Для решения этих проблем создаются

специализированные программные

интерпретаторы.

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

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

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

мы сделаем язык описании универсальным).

Для компьютера описание программы может представлять собои список ключевых слов (Wk), которые наилучшим образом характеризуют данньш алгоритм или регулярное выражение, например, Wk=(w1,k, W2,k, Ws.k, ..., wn,k), где k - номер описания алгоритма, n - число ключевых слов, описывающих данныи конкретный алгоритм). Этот список должен составлять человек, желательно автор даннои программы. Число таких ключевых слов для каждого из алгоритмов индивидуально.

Задание делится на части, каждая из которых однородна и решает одну и только одну задачу.

Программа может формироваться на основе входных параметров (параметрическое управление), например, как в случае модификации кода для многовариантнои программы, например, m_gnuplot рис. 1. Программы, созданные в результате диалога, могут быть также помещены в банк алгоритмов.

Описание процедуры может содержать строку:

<input parameter list> <action> <output parameter list>, где оператор <action> должен быть тщательно описан, так чтобы исключить неоднозначность интерпретации. Имени <action> может соответствовать запись в банке алгоритмов. Должно существовать описание на русском и английском языках, а также список ключевых слов, которые могут использоваться при поиске.

В пределах одного типа <action> может быть много субтипов. Для типов и субтипов должны быть определены конкретные операции, например:

A. Вычисления, включая параллельные;

Б. Анализ текста и его преобразование;

B. Статистический анализ;

Г. Диагностика сети;

Д. Мониторинг операции реального времени;

Е. Работа с базами данных;

Ж. Работа со списками;

З. Работа с объектами Интернета вещеи;

И. Компьютерная аналитика (когнитивный компьютинг);

К. Криптографические вычисления и т.д.;

Если проблема может быть решена программным модулем, хранящемся в банке алгоритмов, ищем и используем такои модуль.

Если нет, используем диалоговый язык программирования, где программа задает программисту последовательность вопросов, требующих ответов. Программа предлагает для каждого вопроса возможные варианты ответов, а программист выбирает один или несколько вариантов. По завершении диалога программа формирует текст исполняемого кода. Примером может служить вариант для регулярных выражении (рис. 3). Если выбор хотя бы в однои точке сделан не правильно, будет получена

программы, которая решает не ту проблему, которая имелась в виду.

Среди списка входных и выходных параметров могут быть: переменные (числовые и строковые), массивы переменных, списки, файлы, каталоги, базы данных и даже программные модули, извлекаемые из банка алгоритмов со своими списками входных параметров. Транслятор должен тщательно анализировать входные и выходные параметры и диагностировать допущенные программистом ошибки. Рекурсивных вложении параметров нужно избегать, так как это делает программу непрозрачной и увеличивает вероятность ошибок.

На рис.1 показан пример программы, управляемой входными параметрами. Программа служит для формирования графических распределении с привлечением библиотечных функции gnuplot (библиотека Chart-Graph-3.2, которая содержит в себе несколько модулем). Разные модули Chart-Graph предназначены для получения различных выходных графических форм и требуют разных форматов входных данных.

Если какая-то функция в банке описании отсутствует, то она может быть создана в тексте описания проблемы на стандартном алгоритмическом языке, например, на PERL. Эта техника используется и в других языках, например, в HTML/XML, где делаются вставки текста на JavaScript или PHP.

В начале и в конце такого модуля ставятся метки-разделители, указывающие на

алгоритмический язык вставки. Например:

<perl> (текст программы на языке Perl с учетом рабочеи ОС) </perl>

На первом уровне М1 (рис. 1) на основе входных данных производится выбор варианта 1-6. На следующих уровнях может производиться уточнение варианта.

Программа, написанная на ML, будет строиться из готовых модулеи кода, хранящихся в банках алгоритмов разного уровня (рис. 2,3), а также программных модулеи, написанных специально для решения текущей проблемы.

Чтобы выработать язык описания проблемы,

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

Входные данные

I

1Е| J19

Выходные данные Рис. 1. Схема реализации программы типа m_gnuplot

Эти имена образуют древовидный граф, и

конкретная проблема может быть

идентифицирована в результате диалога пользователь-программа.

Метод древовидных графов

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

Если сама программа может быть создана в диалоговом режиме, то конечный узел, соответствующий имени проблемы, будет корневым узлом диалога создания программы (рис. 2).

Прямоугольники в нижнеи части рис. 2 соответствуют разным типам техники создания программы. Вариант метода deep learning используется для проблем распознавания (SPAM, атаки нулевого дня и пр.).

Извлечение алгоритма из банка Диалогов, формирование программы Решение проблемы методом deep learning Формирование программы с помощью входных данных Написание кода программистом

Рис. 2. Метод графа для описания проблемы в диалоговом режиме

Для каких действий с какими символами Вы ищете регулярное выражение?

Для операций поиска и замены слов и (или) букв

Что должно находиться в регулярном выражении?

Просто буквы (какого-либо алфавита)

На каком языке будет регулярное выражение?

/ На русском На английском

Какого регистра буквы (строчные или прописные)?

Либо слово, либо буква (на выбор, какого-либо алфавита]

На каком языке будет регулярное выражение?

На русском

Где должен располагаться текст для которого Вы выбираете регулярное выражение?:

В начале строки

В конце строки

В любом месте строки

Рис. 3. Граф описания регулярных выражений

Оптимально формирование списка ключевых слов для поиска программного модуля посредством диалога (вопрос-ответ). Диалог при составлении списка ключевых слов для банка алгоритмов и при формировании запроса поиска в банке алгоритмов должен проводиться идентично, что будет гарантировать идентичность списков ключевых слов. В случае регулярного выражения метод древовидного графа успешно работает (рис. 3). Дерево графа определяет число вариантов регулярных выражении, которые могут быть сформированы.

Каждая диалоговая программа ориентирована на создание определенного класса кодов. Число таких программ будет достаточно велико и со временем будет расти.

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

wз,i, wm^), где 1 - номер запроса алгоритма в банк данных, а т - число ключевых слов в списке. Причем, этот список может отличаться как по содержанию, так и по длине от списка, хранящегося в банке описании алгоритмов. Задача может осложняться существованием синонимов для некоторых ключевых слов, а также наличием опечаток. Для исключения опечаток надо обязательно проводить орфографическии контроль. Порядок ключевых слов в запросе и в поле описания банка данных при такои схеме будет практически всегда отличаться.

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

Программа, реализующая алгоритм,

отображенный на рис. 3, может быть также помещена в банк алгоритмов.

Программы диалоговой техники

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

Рассмотрим в качестве примера диалогового метода формирования программ систему для мониторинга и обеспечения безопасности WEB-сервера.

Данная программа должна анализировать журнальные файлы (accessjog, errorjog, secure и

др.), выявлять случаи атак и блокировать доступ к WEB-узлу с соответствующего 1Р-адреса, если число атак превысило пороговый уровень.

Задание порогов атак отдельно для каждого типа, имя базы данных, таблицы (если имеются), имена журнальных файлов для каждого типа атак, требования к формированию графики производится в темном блоке на рис. 4 "Зона обработки результата"). Предполагается, что в банке описании алгоритмов имеются модули, соответствующие субзадачам, названным в вертикальных прямоугольниках рис. 4. Может выбираться один вариант или любая их комбинация.

i о

-а

аз о. н

О I-

са

I

ск с; о

CL

аз п

о. о ю ct о с

1

111

л

3

л

ц.

CD

5

X

X

с; о

|оз ® &

St

J3 1=

о [=

Щ ся

s аЗ ь- > го 2

it < ГО

О сп

СО

С1

о

(I)

=|

9

m

m

и с

о I- о го

о

о

о

с

го

с;

F0

F1 GO G1 НО

Н1

Зона обработки результата

т

Рис. 4. Граф выбора варианта задачи для программы обеспечения безопасности WEB-сервера

Обозначения на рис. 4: C0 - использование методов put или delete. C1 - использование методов post и т.д.. F1 - детектирование в журнальном фаиле access_log случаев "../" , "/../../../../", %2e%2e%2f, ..%c0%af или %2e%2e/ отдельно. G1 - случаи, когда SQL-база на сервере отсутствует. H1 - выявление в запросе потенциально опасных фаилов

После завершения диалога программа формирует из имеющихся модулей программу, решающую данную проблему самостоятельно.

Полученные результаты

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

Заключение

Нами предложены некоторые подходы для минимизации программных ошибок. Эти методы наряду минимизацией числа ошибок посредством использования программы большим числом пользователей с последовательным выявлением и корректировкой неправильного кода (принцип "many eyes") позволят поднять надежность программ.

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

На примере приложения Gnuplot продемонстрирована возможность диалогового метода программирования, с помощью которого программа задает вопросы программисту и сама формирует текст программы.

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

Литература

1. "Экономика в 2016 году и через 10 лет", Семенов Ю.А. Экономические стратегии N1, 2017 стр.126.

2. Handbook of Theoretical Computer Science Methods and logics for Proving Programs, Chapter 15, Patrick Cousot, Elsevier Science Publishers B.V., 1990, p.844.

3. Ильин А. В. Конструирование разрешающих структур на задачных графах системы знании о программируемых задачах / / Информационные технологии и вычислительные системы, 2007. №3, с. 30-36.

4. Ильин В. Д. Система порождения программ. М.: Наука, 1989, 264 с.

5. Тыугу Э. Х. Концептуальное программирование. М.: Наука, 1984, 256 с.

6. Ильин А. В., Ильин В. Д. Систематизация знании о программируемых задачах // Системы и средства информатики, 2014. Том 24, № 3, с. 192-203.

7. Оценка количества ошибок в программе. Модель Миллса // https://habrahabr.ru/post/122912/

8. "Разработка банка алгоритмов и основ языка описания проблем с целью минимизации числа программных ошибок", Ю.А. Семенов, А.П. Овсянников, Т.В. Овсянникова, "Труды НИИСИ РАН том 6, №2", Москва, 2016, с. 96-100.

9. "Когда компьютеры станут умнее человека", Chip 09/14, стр 24-25.

10. Неиросеть DeepCoder учится программировать, заимствуя код у других программ / / https://geektimes.ru/post/286304/

11. Правила Хольцмана, http://book.itep.ru/10/holz_rules.htm.

12. Иванников В. П., Белеванцев А. А., Бородин А., Игнатьев В., Журихин Д., Аветисян А. И., Леонов М. Статический анализатор Svace для поиска дефектов в исходном коде программ // Труды Института системного программирования РАН. 2014. Т. 26. № 1. С. 231-250.

References

1. "Jekonomika v 2016 godu i cherez 10 let", Semenov Ju.A. Jekonomicheskie strategii N1, 2017 str.126.

2. Handbook of Theoretical Computer Science Methods and logics for Proving Programs, Chapter 15, Patrick Cousot, Elsevier Science Publishers B.V., 1990, p.844

3. Il'in A. V. Konstruirovanie razreshajushhih struktur na zadachnyh grafah sistemy znanij o programmiruemyh zadachah // Informacionnye tehnologii i vychislitel'nye sistemy, 2007. №3, str. 30-36.

4. Il'in V. D. Sistema porozhdenija programm. M.: Nauka, 1989, 264 str.

5. Tyugu Je. H. Konceptual'noe programmirovanie. M.: Nauka, 1984, 256 str.

6. Il'in A. V., Il'in V. D. Sistematizacija znanij o programmiruemyh zadachah // Sistemy i sredstva informatiki, 2014. Tom 24, № 3, str. 192-203.

7. Ocenka kolichestva oshibok v programme. Model' Millsa.

8. "Razrabotka banka algoritmov i osnov jazyka opisanija problem s cel'ju minimizacii chisla programmnyh oshibok", Ju.A.Semenov, A.P.Ovsjannikov, T.V.Ovsjannikova, "Trudy NIISI RAN tom 6, №2", Moskva, 2016, str. 96-100.

9. Kogda komp'jutery stanut umnee cheloveka", Chip 09/14, str. 24-25.

10. https://geektimes.ru/post/286304/ Nejroset' DeepCoder uchitsja programmirovat', zaimstvuja kod u drugih program

11. Pravila Holcmana, http://book.itep.ru/10/holz_rules.htm

12. Ivannikov V. P., Belevancev A. A., Borodin A., Ignat'ev V., Zhurihin D., Avetisjan A. I., Leonov M. Staticheskij analizator Svace dlja poiska defektov v ishodnom kode programm // Trudy Instituta sistemnogo programmirovanija RAN. 2014. T. 26. № 1. str. 231-250

Поступила: 15.05.2017

Об авторах:

Доренская Елизавета Александровна, инженер-программист, НИЦ «Курчатовский институт» ФГБУ

«ГНЦ РФ ИТЭФ», dorenskaya@itep.ru: Семёнов Юрий Алексеевич, кандидат физико-математических наук, ведущий научныи сотрудник, НИЦ «Курчатовский институт» ФГБУ «ГНЦ РФ ИТЭФ»; заместитель заведующего кафедрои информатики и вычислительных сетеи Института нано-, био-, информационных, когнитивных и социогуманитарных наук и технологии, Московский физико-технический институт (государственный университет), semenov@itep.ru.

Note on the authors:

Dorenskaya Elizaveta A., software engineer, Institute for Theoretical and Experimental Physics, dorenskaya@itep.ru;

Semenov Yuri A., Candidate of Physical and Mathematical Sciences, Leading Researcher, Institute for Theoretical and Experimental Physics; Deputy Head of the Department of Informatics and Computer Networks, Department of Nano-, Bio-, Information Technology and Cognitive Science, Moscow Institute of Physics and Technology (State University), semenov@itep.ru.