Главная arrow Развитие ПО arrow Дейкстра Эдсгер
Как начинался компьютер
Компьютерная революция
Двоичный код
Разработки военных лет
Интегральные микросхемы
Микрокомпьютер
Персоны
Сеть
Язык компьютера
Развитие ПО
Гибкие системы
Средства разработки
Информатика
Вычислительная наука
Операционные системы
Искусственный интеллект
Предыстория
Поиск
Знания и рассуждения
Логика
Робототехника
 

 
Дейкстра Эдсгер Печать
Эдсгер Дейкстра
Свой плодотворный вклад в теорию программирования Дейкстра сделал в 1968 г. в возрасте 38 лет. В небольшой работе под названием «Заметки по структурному программированию» он доказывал, что большинство программ неоправданно сложны из-за отсутствия в них четкой математической структуры. Состояние дел в области проектирования программного обеспечения вызывало на протяжении ряда лет беспокойство многих специалистов по вычислительной технике. Все чаше работы по созданию новых систем программного обеспечения для правительственных учреждений и промышленности стоимостью в миллионы долларов не уклады вались в заранее установленные сроки, а потом в процессе использования в них обнаруживались тысячи ошибок. Как раз в то время, когда Дейкстра писал свою работу, проходила международная конференция, на которой возникшая ситуация получила название «кризис программного обеспечения».

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

Как остроумно заметил один американский специалист по компьютерам, «если в вашей программе будет много операторов GOTO, то она станет похожа на спагетти».

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

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

Сначала идеи Дейкстры вызвали лишь усмешку среди программистов, не желавших отказываться от операторов GOTO. Однако в начале 70-х годов группа сотрудников фирмы IBM под руководством специалиста по системному программированию Харлана Миллса применила структурное программирование для создания информационного банка данных газеты «Нью-Йорк таймс». Работа над проектом шла на удивление гладко, а законченная программа практически не содержала ошибок.

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

Харлан Миллс заявляет: «Теперь мы можем делать то, что не могли делать 10-15 лет назад. Не думаю, что полеты «космического челнока» стали бы возможны без применения методов структурного программирования».

Важной вехой на пути широкого признания принципов структурного программирования стал 1975 г. В этом году Джон Кемени и Томас Курц, авторы самого демократичного языка программирования, дартмутского BASIC, провели ревизию своего детища. Они ввели в него структурные возможности и, по выражению Кемени и Курца, «выбросили оператор GOTO сразу и без всякого сожаления».

А спустя десять лет они предприняли еще один, более существенный пересмотр языка, связанный с микрокомпьютерами. Случилось так, что вплоть до начала 80-х годов, когда Курц впервые стал работать на персональном компьютере, ни он, ни Кемени не имели ни малейшего понятия о широком коммерческом успехе своего творения. В результате применения BASIC как основного языка для микрокомпьютеров (их ограниченный объем памяти требовал некоторых модификаций исходной версии языка) возникло множество неуклюжих диалектов.

По словам Курца, увиденное привело его в ужас. Поэтому Кемени и Курц в содружестве с Американским институтом национальных стандартов (ANSI) принялись за разработку канонической версии языка для микрокомпьютеров. Эту версию они назвали «истинный Бейсик» (True BASIC).

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

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

Даже когда казалось, что программа полностью отлажена, новые входные данные могли вызвать отказ, или, как говорят программисты, «аварию».

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

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

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