В программировании идет очень интересный процесс

Александр Ливеровский, Эдуард Пройдаков

PC Week: Расскажите, пожалуйста, чем занимается возглавляемый вами Институт системного программирования.

В. Иванников: Цель нашего академического института - послевузовское образование. Мы должны готовить топ-дизайнеров, т. е. людей, которые самостоятельно могут разрабатывать проекты по новым технологиям. Придя сюда, они должны повысить уровень своего образования. У нас есть ученый совет, где защищают докторские и кандидатские диссертации. За последние два года в нем было защищено три докторские диссертации. Мы доводим ребят до топ-уровня к 30 - 35 годам. Но тут возникает проблема интенсивной утечки мозгов, и это нас очень беспокоит.

В программировании постепенно, без революций идет очень интересный процесс. Можно сказать, что наряду с практическим программированием (software engineering) всегда существовало еще и теоретическое программирование (theoretical computer science). Между этими двумя видами деятельности имеется большой зазор. Подобный зазор существует и в математике: есть численные методы и есть просто математика. Она тоже начиналась как наука, которая выбирала некоторые артефакты, их классифицировала, и эти артефакты использовались на практике (например, сколько камня пойдет на пирамиды, как рассчитать времена года и т. д.). Теоретическая наука делает некоторые обобщения и строит модели, а есть реальная жизнь, в которой эти модели часто годятся только для “игрушечных” применений. Возьмите, например, метод Рунге - Кутта, так там нет даже обоснования сходимости, а есть эвристика какая-то. Интегрируем с некоторым шагом, затем с половинным и, если разница попадает в эпсилон, то считается, что есть сходимость. Вот это реальная жизнь. Но тем не менее все это - единая наука. Сейчас, как мне кажется, очень бурно развивается теоретическое программирование и сокращается разрыв с практикой, хотя он всегда остается.

Однако не следует считать, что совершается какой-то революционный прорыв. Все происходит очень эволюционно. Первые попытки делались давно. Дейкстра писал о дисциплине программирования. Это были поиски, так сказать, “Всеобщей теории поля”. Сейчас разработано очень много формализмов и в базах данных (например, Data Log), и в базах знаний (вывод фактов из имеющихся некоторых обобщений), а также есть асинхронные модели, формализм Мильнера, формальные методы спецификации и верификации программ и т. д. Не каждый из них может использоваться на практике, но все они позволяют нам глубже понять, с чем же мы имеем дело. Теория объектов, например. Сейчас ею занимается много исследователей.

Все это в некотором роде меняет подход к образованию. Я вижу у ребят тягу к получению фундаментальных знаний. Так, например, в Физтехе читается курс “Теория сложности”, в МГУ есть годичный курс по формальным спецификациям разного рода типа Дидье. Причем это полнопрофильный курс - т. е. лекции, семинары и практикум. Полнопрофильный курс всегда очень продуктивен, потому что, прослушав лекции, обсудив все темы на семинарах, научившись решать задачи, пройдя практикум на конкретных инструментах, слушатели получают прочные знания, остающиеся в памяти. Другой пример - Миеровский Calculus - спецкурс. Этот спецкурс начали читать в прошлом году и будут читать в этом.

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

Давайте перейдем к новым технологиям. Я хотел бы привести один пример. В нашем коллективе было разработано жуткое количество разных компиляторов: с Фортрана, PL/1, Паскаля и т. д. Причем их делали в основном для высокопроизводительных машин. Сейчас для этого появились мощнейшие инструменты, например Coctail. Если раньше разработка оптимизирующего компилятора занимала три-четыре года, то теперь - всего лишь 6 - 9 месяцев. Это - системное программирование. Мы тоже разрабатываем инструменты для разработки инструментов. Этот штрих показывает, что такое новые технологии.

PC Week: Наверное, прежде всего нужны стандарты?

В. И.: В общем, все нетривиально. Дело в том, что у нас, как и в США, существовало две линии требований и стандартов. Одни стандарты были рассчитаны на гражданские применения, а другие - на военные приложения. Мне попадалось много статей и отчетов о том, что недопустимо наличие этих ветвей. Минобороны должно опираться на гражданские стандарты, в том числе использовать языки, применяемые в гражданской области. Принятие стандарта для судьбы языка - не самое главное, потому что языки живут своей собственной жизнью, например Си, на который вначале вовсе не было стандарта. Вспомните судьбу PL/1. Как его насаждала IBM! Сколько было усилий затрачено. И тем не менее он не получил широкого распространения. Язык программирования, как и естественный язык, должен постоянно изменяться.

PC Week: Применяются ли сейчас технологии, которые дают возможность создавать операционные системы, обеспечивающие высокий уровень безопасности?

В. И.: Приблизительно четыре года тому назад мы начали разрабатывать новые технологии. Они гарантировали, что если некоторая система специфицирована формально, то можно автоматически генерировать тесты, для того чтобы проверить соответствие софтвера спецификациям. И здесь существует серьезная проблема. Дело в том, что хотя разные клоны Unix соответствуют спецификациям POSIX, в них есть боковые ходы, и когда начинают пользоваться ими по принципу “что не запрещено, то разрешено”, это опасно, потому что, если используются функции, разрешенные в этой версии, но отсутствующие в стандартах, программа, работающая на одной версии, на следующей - не работает. И найти почему - чрезвычайно трудно. Проблема состоит в том, чтобы протестировать не только разрабатываемую систему, но и системы, которые выходят на этот уровень. Сейчас это делается по формальным спецификациям, в качестве их, в основном, используются некоторые клоны VDM (Vienna Development Method), базирующегося на теории множеств, отношений и логики первого порядка. Все постусловия, инварианты описываются и в результате генерируются тесты. Разработку программ сопровождает куча различных документов. Это - пользовательская документация: тесты, коды, спецификации - и все они должны быть согласованы. Часто даже при покупке бытового прибора пользовательская документация не соответствует самому изделию. Прибор уже усовершенствован, а документация при нем - старая. А в программировании еще больше разного рода документов, которые должны быть между собой согласованы. На основе чего документация может быть согласована? Можно генерировать ее на основе спецификаций, но тогда качество документации будет плохое. С тестами мы разобрались. Тесты можно генерировать. Сейчас ведутся исследовательские работы в области генерации кода по спецификациям, но это - экспериментальные работы.

Оказывается, по спецификациям можно генерировать пользовательскую документацию в форме Unix man page, описывающей исключительные ситуации. Это, в общем, то, что нужно пользователю. Кстати сказать, формальные спецификации - это достаточно большого объема трудночитаемый текст, c которым пользователю тяжело работать. Не говоря уже о том, что когда мы говорим о реальных системах, соотношение числа строк спецификаций и строк кода получается приблизительно один к трем, один к двум. Причем, если мы вводим не на игрушечных примерах асинхронности, то число спецификаций на один-два порядка превышает число строк кодов. К чему я клоню? К тому, что хочешь получить информацию о программе - читай ее текст. Спецификации еще труднее понять, особенно без предварительной подготовки, потому что они написаны не в императивной форме, а в декларативной. Там есть кванторы, и это вполне естественно. Но как описывать, что там, в цикле, делается? Для множества значений на каких-то отношениях квантор у меня определен. Человеку быстро надо прочитать текст, и когда он просматривает Unix man page, он тут же схватывает, что ему надо. Кроме того, получается, что тестирование, спецификации и документация соответствуют друг другу, потому что они вышли из одного источника. Вот эту технологию мы сейчас и разрабатываем. И уже есть интересные результаты. Когда эта работа начиналась, мне она казалась фантастикой. Что касается практического применения, мы проверяли свои результаты на одном иностранном контракте. Имелся работающий телефонный софтвер. В нем было выявлено большое количество логических ошибок. В реальной жизни мы часто имеем дело не с “новьём”, а с legacy - с системами, которые были сделаны в начале 70-х годов и все время развивались. Их объем достигает 20 млн. строк текста. Это - телефонные системы, системы реального времени. Никто не начнет новые разработки, потому что они займут многие годы, пока софт не дорастет до нужного уровня.

Проблема legacy существует. Можно переводить legacy на новые технологии, например объектные. На эту тему написано очень много книг. Но где эти технологии применяются? Это микроядерные операционные системы и GUI - графический интерфейс пользователя. Они очень перспективные, потому что за счет инкапсуляции и наследования можно очень строго описывать интерфейсы и т. д. А legacy-системы нужно уметь трансформировать. Для этого требуются инструменты, которые по исходным текстам, не автоматически, конечно, но помогают разработать спецификации, т. е. осуществить реинжиниринг. От legacy-кода мы можем подняться к более высокому уровню - спецификациям, требованиям. Конечно, это можно сделать, проинспектировав код вручную. Для этого существуют инструменты, которые у нас тоже разработаны и позволяют производить реинжиниринг от исходного текста к некоторым формальным спецификациям. Потом сгенерировать тесты, потом сгенерировать документацию. При этом обеспечивается согласованность огромного числа разных документов, отражающих различные стороны того же самого софтвера. Что выполняется, что проверяется, что читается.

PC Week: Сколько ошибок вы нашли таким образом в телефонном софте?

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

PC Week: Скажите, если не секрет, как вашему институту удается удерживаться на плаву в сложных экономических условиях?

В. И.: У нас три источника финансирования. Это бюджетные ассигнования со стороны Академии наук, контракты с индустриальными западными фирмами и с отечественными. К сожалению, с нашими фирмами контрактов очень мало, так как мы разрабатываем технологии для создания новых технологий, а потребность в них в стране пока мала. Здесь требуется технология для конечного пользователя. Банкам нужны системные интеграторы, которые из имеющегося могут собрать то, что надо. Западным компаниям нужен software production. Наша беда в том, что мы - академический институт и должны обучать специалистов, поэтому нам нужны проекты с серьезной исследовательской частью, дающей возможность разрабатывать новые технологии. Нам нужны работы с большой исследовательской составляющей.

PC Week: Редакция надеется, что ваши работы и специалисты, которых вы готовите, будут востребованы и в России.

С Виктором Петровичем Иванниковым беседовали Эдуард Пройдаков и Александр Ливеровский.

Начало: «Ближайшие несколько лет будут просто критическими»

PC Week/RE, № 30/98
Помещена в музей с разрешения авторов 2 декабря 2016