Строитель надежных программ

Бертран Мейер создал свой объектно-ориентированный язык программирования Eiffel в то время, когда эта парадигма только начала завоевывать сообщество разработчиков, а его бестселлер Object-Oriented Software Construction, переведенный в том числе и на русский язык, многими признается «библией ООП». В середине 80-х Мейер основал компанию Eiffel Software и сегодня является ее научным руководителем.

В 2003 году в Высшей политехнической школе в Цюрихе Мейер сменил Никлауса Вирта на посту заведующего кафедрой программной инженерии и сейчас ведет активную преподавательскую работу. Свои идеи в области ООП он распространил на практику его преподавания, о чем ярко написано в книге Touch of class («Почувствуй класс»), недавно изданной на русском языке Национальным открытым университетом ИНТУИТ.

Мейера связывают давние отношения с российским научным сообществом – в молодости он проходил стажировку у Андрея Петровича Ершова в Новосибирске и прекрасно владеет русским языком, а с 2011 года тесно сотрудничает с Санкт-Петербургским государственным университетом ИТ, механики и оптики (ИТМО).

Язык Eiffel существует уже больше 25 лет. Какие наиболее интересные работы в его рамках ведутся сейчас?

Eiffel – это инструмент, которым я пользуюсь, чтобы реализовать свои идеи в программировании и программной инженерии в целом. Eiffel – это и язык, и метод, и среда разработки. Он продолжает развиваться, и одно из важных направлений этого развития – параллельность. Возможность исполнять программы на параллельных компьютерах – одна из ключевых и при этом самых трудных задач современной индустрии разработки. По сути, сегодня никто не знает, как программировать параллельные приложения, и, хотя существует много способов, все они очень сложные. Утверждая, что никто не знает, как разрабатывать параллельные приложения, я имею в виду, что никто не умеет сегодня быстро создавать параллельные программы таким образом, чтобы они были корректными и надежными. Мы знаем, как производить приложения с поддержкой многопоточности на Java, C++ и др., но это очень сложная профессиональная разработка, в результате которой почти всегда остается много ошибок.

Необходимо поднять параллельные программы на тот же уровень простоты, качества и надежности, которым могут обладать традиционные приложения. Это очень сложная задача. Мы разработали модель параллельного программирования SCOOP. Идея состоит в том, что работа может быть трудной для тех, кто создает модель, но должна быть легкой для тех, кто пользуется этими инструментами в разработке параллельных программ. В Высшей политехнической школе в Цюрихе мы только что получили от Евросоюза грант на реализацию пятилетней программы по развитию параллельного программирования на базе SCOOP. Цель программы в глубоком изменении подходов к параллельному программированию, чтобы оно перестало быть чем-то загадочным и непостижимым, а стало таким же нормальным и обыкновенным процессом, как обычное программирование.

В рамках этой программы будет создано универсальное решение, применимое к любой архитектуре, которая требует распараллеливания программ?

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

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

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

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

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

Находит ли все это применение в реальных промышленных разработках?

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

Должно ли, на ваш взгляд, использование этих инструментов охватить весь спектр создаваемых программных продуктов?

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

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

Насколько распространен Eiffel?

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

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

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

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

Что касается надежности, то, помимо успехов в практическом применении формальных доказательств корректности программ, значительного прогресса в течение последних десяти лет нам удалось достигнуть в области тестирования. Уникальная черта среды разработки EiffelStudio – это возможность полностью автоматического тестирования. Это выражение используется многими, но на самом деле действительное автоматическое тестирование требует не только выполнения тестов, но и автоматического приготовления тестовых случаев. Инструменту Autotest просто передается список компонентов программы, которые необходимо тестировать, и в качестве результата выдается список ошибок. Эта возможность реализуется благодаря наличию в программе контрактов (о деталях метода «контрактного программирования» Бертран Мейер рассказывает в своей статье «Построение надежного объектно-ориентированного программного обеспечения: введение в контрактное проектирование», «Открытые системы», № 6, 1998. — Н. Д .).

Получается, что при разработке в EiffelStudio тестировщики не нужны?

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

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

При определении требований описываются структурные и семантические свойства системы. Например, есть понятие «журнал» и понятие «редактор». Примеры структурных свойств: «редактор пишет для журнала», «журнал имеет множество редакторов». Семантическое свойство – это, например, правило, что редактор одного журнала не может писать для другого журнала без разрешения. Для определения требований применяются формальные и неформальные техники. Формальные техники используют математические понятия, иногда с программными нотациями, как контракты в Eiffel. Пример неформальной техники – описание требований на естественном языке. Самая большая проблема с требованиями состоит в том, что формальные техники трудны для понимания, а неформальные дают ясное, но неточное определение требований. Например, у нас в Цюрихе уже около пяти лет проводится курс лекций под названием DOSE (Distributed and Outsource Software Engineering), в рамках которого команды студентов из разных университетов реализуют распределенный проект. Два года назад таким проектом была система администрирования конференций, требования к которой включали следующую фразу: «Событие – это конференция, семинар, учебное занятие или симпозиум». И некоторые студенты – участники проекта понимали это так, что событие – это исключительно одно из перечисленного, а другие считали, что событие может быть и конференцией, и симпозиумом. Такие тонкие свойства системы трудно описать с помощью неточных техник определения требований. С использованием формального метода спецификация с математической точностью идентифицирует либо одну интерпретацию, либо другую.

Трудность требований – описать систему точно и ясно, а контракты дают возможность этого добиться. Если я хочу объяснить, что редактор может писать только для одного журнала, контракт позволяет сделать это очень точно, с помощью простых математических нотаций, и при этом совершенно ясно для понимания. Более того, метод контрактов помогает задать правильные вопросы в процессе определения требований. Описывая требования на естественном языке или на UML, я могу забыть о данном семантическом свойстве, хотя о нем знаю, например — работает ли редактор только для одного журнала. Это значит, что позже программисту придется решать такие тонкие, но важные вопросы. А если пользоваться Eiffel и контрактами, то метод работает так, что практически заставляет задать важные вопросы на этапе определения требований. И, если в системе есть понятие «редактор работает для журнала», невозможно не задать уточняющий вопрос: означает ли это, что для каждого редактора есть один журнал или для каждого редактора есть множество журналов?

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

Вы не очень большой поклонник «скорых» (agile) методов разработки, почему?

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

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

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

Летом 2011 года вы возглавили кафедру в ИТМО. Чем вас привлек этот университет? Какие направления исследований там планируются?

Я уже много лет интересуюсь тем, что происходит в России в академической среде, у меня давние хорошие связи с ИТМО и другими университетами Санкт-Петербурга, особенно с СПбГУ и кафедрой Андрея Николаевича Терехова; я знаю качество подготовки их студентов и ученых. ИТМО – интересное место, потому что у этого университета большие успехи в олимпиадном программировании и он очень серьезно хочет достичь того же уровня качества в исследованиях по информатике, что и западные университеты. Они нашли частное финансирование для создания Лаборатории программной инженерии, которой меня пригласили заведовать. Для меня это очень интересная возможность. Мы строим лабораторию с нуля и хотим привлечь самых умных, талантливых и активных людей. В этом мы, естественно, вступаем в конкуренцию с бизнесом, но благодаря поддержке компании Mail.ru можем платить аспирантам и молодым ученым разумные зарплаты, почти на том же уровне, что они получали бы в бизнесе. Это позволит молодым исследователям заниматься только научной деятельностью, как это сейчас происходит, например, в Высшей политехнической школе бизнеса в Цюрихе.

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

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

Планируете ли вы организовать учебные курсы для студентов ИТМО?

Нет, это исследовательская кафедра. Но мы проводим еженедельный городской семинар по программной инженерии в сотрудничестве с профессорами Владимиром Ицыксоном из Политехнического университета и Андреем Тереховым из СпбГУ. Проводить регулярные учебные курсы в ИТМО я не могу технически, потому что меня часто здесь не бывает. Но есть распределенный курс DOSE, и с этого года команда из ИТМО участвует в нем вместе со студентами Нижегородского госуниверситета. Всего же в курсе задействованы более десяти университетов, в том числе из Италии, Испании, Аргентины, Китая и Дании. Это очень сложный, но интересный международный проект, который позволяет студентам пройти через все возможные ошибки такой распределенной разработки в рамках университетского курса, что гораздо лучше, чем если бы они совершали их, уже работая в компаниях.

Вы много занимаетесь образованием. Как вы оцениваете современную подготовку профессионалов по программной инженерии в мире?

Образование в области информатики находится на довольно высоком уровне, но, по моему мнению, слишком концентрируется на сегодняшних методах и инструментах. Конечно, важно, чтобы студенты знали ключевые средства разработки, широко распространенные на данный момент, но гораздо важнее, чтобы они овладели основными понятиями дисциплины программной инженерии и принципами хорошего построения программ. Нацеленность образовательных программ на краткосрочную перспективу даст выпускникам возможность написать в своих резюме, что они знают Java, C#, Ruby и другие модные техники. Но, к сожалению, это не значит, что через 10-20 лет они останутся на хорошем уровне.

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

Наверное, можно сказать, что 25 лет назад, когда появились языки Eiffel и C++, произошел ключевой «сдвиг парадигмы» – переход от структурного программирования к объектно-ориентированному. В сегодняшней ситуации видите ли вы предпосылки для очередного сдвига – изменений в сфере разработки программного обеспечения, которые будут очень важны для развития отрасли?

Найдутся люди, которые ответят, что agile-методы – это следующий «сдвиг парадигмы». Я так не думаю. Возможно, я ошибаюсь и года через два изменю свое мнение, но мне кажется, что agile – не более чем отражение уже известных техник разработки. К примеру, идею инкрементальной разработки мы применяем давно, и в моей книге Object Success еще в 1995 году объяснялось, что хорошая разработка должна быть инкрементальной. И, как мне кажется, никто не может точно обосновать, какие из agile-идей реально работают, а какие нет, пока же есть только отдельные эмпирические исследования и частные результаты.

Еще один кандидат на звание «сдвига парадигмы» – развитие эмпирической программной инженерии. Это очень интересная область — в последние пять–десять лет впервые появилась возможность изучать программные явления как научный объект, подобно объектам естественных наук. Есть уже некоторые результаты, но они пока очень частные. Я этим тоже занимаюсь, поскольку это единственный способ в конце концов узнать, насколько хороши твои идеи. Очень легко предлагать новые идеи, методы, новые конструкции языка и убеждать окружающих, что они самые важные и лучшие. Но единственное средство дать этому реальное подтверждение – это научно изучать эффект данной идеи, метода или инструмента и обосновывать, что можно делать с их помощью.

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