Проблема
Проблема в том, что программисты во всем мире обычно никак не формализуют свою работу, отмечает Анатолий Шалыто. Вы спросите: а как это делать? Ведь код — он и есть код, его пишут, основываясь на опыте и знаниях. К тому же большинство людей, которые не обладают знаниями в IT, совсем не разбираются в этих буквах и знаках, которыми кодируют приложения, так какой смысл каким-то образом это формализовывать?
«В газете „КоммерсантЪ“ была опубликована статья о легитимности используемого на атомных электростанциях программного обеспечения. Там написано, среди прочего, что имеющееся ПО не позволяет понимать, как программа будет себя вести в тех или иных случаях, как именно и какие в нее вносили изменения. Более того, сообщается, что на этот софт нет никакой документации. А вы представьте себе: это атомный реактор, а почти никто, кроме, возможно, разработчика, которого нет на объекте, не понимает, как работает управляющая программа. И такой бардак с ПО творится почти везде в мире. Если аппаратура всегда проектируется, а потом только реализуется, то проектная документация на программы практически никогда не выпускается. Универсальный язык моделирования (UML), на который одно время у многих были большие надежды, используется крайне редко: все куда-то торопятся, у заказчика нет денег на проектную документацию, а у разработчика — людей. Интересно, что бывают случаи, когда сначала предполагается, что для ответственного объекта программное обеспечение нужно разработать за три-четыре года, а потом этот срок увеличивается до 25 лет, и при этом все равно проектную документацию на ПО никто не разрабатывает. Если нужно что-то исправить в ПО, то программисты обычно просто берут код и на языке программирования исправляют эти ошибки так, как им удобно, а потом показывают результат заказчику. И в этой ситуации мне очень жаль тех заказчиков, которые по долгу службы должны согласовать программное обеспечение, так же как они согласовывают документацию на аппаратуру», — обрисовал проблему заведующий кафедрой технологии программирования.
Мало того, даже самому программисту через некоторое время бывает тяжело разобраться в собственном коде, не говоря уже о чужом. Для того, чтобы упростить понимание чужой программы, необходимо понять, как мыслил разработчик, какие схемы были в его голове, какими методиками он пользовался. Для этого нужна не просто программная документация, которая обычно выпускается, а проектная документация на программы, из которой можно узнать, как программа создавалась. Таким образом, станет возможным формализовать и согласовать с заказчиком ТЗ, по которому создается программное обеспечение, что особенно важно для ответственных объектов. Но если мало кто знает, как именно работает программное обеспечение на таких объектах, то может ли идти речь о безопасности?
Решение
Выход из ситуации — это переход от так называемого искусства программирования к программной инженерии. При разработке ПО могут применяться методики создания систем автоматического управления, которые используются в инженерных науках. Этот подход, который Анатолий Шалыто предложил еще в 1991 году, получил название автоматное программирование.
При этом предполагается не только программирование с использованием такой математической абстракции, как автоматы, а технология программирования, с помощью которой можно создавать системы со сложным поведением. Оно основано на новой парадигме программирования, в которой предполагается о программах думать, как об автоматизированных объектах управления, состоящих из систем управления (автоматов) и объектов управления, которые могут быть как реальными, так и виртуальными. При этом поведение этих систем смогут «прочитать» и инженер, и программист, и заказчик, и начальник. Это, в свою очередь, поможет другим программистам быстрее разбираться в чужом коде при необходимости его корректировки.
«До того, как начинать программирование системы, необходимо разобраться с ее поведением. Предлагается не писать программу, а нарисовать „картинки“ — графы переходов, которые позволяют описать поведение будущей программы в терминах состояний и переходов между ними и в действиях, которые выдаются в результате переходов. То есть нужно сначала описать, что должна делать программа, в таком виде, чтобы это было всем понятно. Когда это нарисовано, можно вручную или автоматически написать программу», — пояснил автор метода.
На бумаге автоматное программирование выглядит как процесс создания графов, в которых под влиянием входных воздействий осуществляются переходы между состояниями и формируются выходные воздействия. Для этого сначала создается словесный текст технического задания, в котором указывается, что и за чем должно произойти в соответствии с желанием заказчика. Потом необходимо определиться с условными обозначениями входных и выходных воздействий, а также источников и приемников информации. Так как техническое задание по ГОСТ окончательно оформляет разработчик, то при наличии графов переходов заказчик может понять, что хочет делать программист и внести исправление при необходимости. Согласованное и формализованное техническое задание затем будет отражено в программном коде, которого может не увидеть не только заказчик, но и даже программист, если код строится автоматически. При этом, независимо от того, как реализуются автоматы — вручную по шаблонам или автоматически, программирование функций входных и выходных переменных, которые не обладают сложным поведением, выполняется вручную. По мнению Анатолия Шалыто, качество программ, в основном, обеспечивается не тестированием и верификацией, а тем, что на ранних стадиях создания программы заказчик и разработчик поняли друг друга и согласовали формализованное техническое задание.
Конечно, такой подход также требует от заказчика знаний того, как разбираться в проектной документации на ПО. Однако это все равно в разы понятнее и доступнее, чем программный код. Кроме того, существуют приложения для моделирования автоматных программ, где в интерактивном виде можно проследить все переходы от одного состояния к другому. Кроме того, это проектирование очень напоминает проектирование приборов, которое понятно инженерам.
«Это просто разные способы мышления: у инженера — такое, а у программиста — другое. Сегодня программирование — это не инженерная наука, а прикладная математика. Программистов готовят широкого профиля, они должны знать математику и применять ее. А если бы у них была и инженерная подготовка в области управления дизелями, электроэнергетикой и ракетными комплексами, например, то это было бы уже инженерное программирование. Сейчас программистов сразу учат писать код. Они с детства делают это, а потом к ним на пятом курсе приходит какой-нибудь профессор и говорит, что ПО надо, оказывается, моделировать с помощью UML. Здесь уже что-то исправить в мышлении сложно. Более того, программисты — они ведь очень умные, и применяют автоматы, как и другие математические абстракции, когда считают нужным. А я говорю: всегда его надо применять для описания программ со сложным поведением, в которых имеет место зависимость их поведения от предыстории», — сказал Анатолий Шалыто.
Он рассказал о своем знакомом, который занимается ПО для управления очень ответственным комплексом. Для того, чтобы создать необходимую программу, она сначала была спроектирована. При этом проект состоял из графа переходов из более 300 вершин, хотя их можно было разбить на несколько взаимосвязанных графов. Однако описание поведения программы в виде одного графа позволяет наглядно и точно показать, как будет работать система управления, и при автоматическом построении по ней программы в этой части она будет вести себя так, как была спроектирована. Это удобно и безопасно.
Автоматные программы обладают еще одним важным достоинством — их во многом автоматически можно верифицировать с помощью метода Model Cheсking. Анатолий Шалыто предложил тем, кто заинтересуется автоматным программированием обращаться на сайт и к нему лично по почте shalyto@mail.ifmo.ru.
