< Предыдущая
  Оглавление
  Следующая >


4.9. Программа как стадия концептуальной трансдукции

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

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

Каковы этапы разработки программы? В широко известных основах программной инженерии выделяют четыре этапа истории развертывания потенциала программы: 1) проектирование; 2) конструирование; 3) тестирование; 4) сопровождение. Каждый из них, в свою очередь, состоит из многих стадий, которые нет необходимости перечислять. Однако стоит обратить внимание на типичные фазы разработки программы:

1. Формулировка общей идеи программы.

2. Принятие решения о потенциальных пользователях программы.

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

4. Выбор языка программирования.

5. Проектирование структуры программы с помощью определенных инструментов, например псевдокода.

6. Написание программы.

7. Тестирование программы без участия пользователей (альфа-тестирование) и с их участием (бета-тестирование).

8. Исправление ошибок, обнаруженных во время тестирования.

9. Выпуск окончательной версии программы.

Чем отличается программа от алгоритма? Этот вопрос, как справедливо отмечают эксперты, не стал предметом тщательного анализа. Культивируются в основном две точки зрения. Согласно первой из них алгоритм является математической, а программа лингвистической единицей. Однако более популярна позиция, согласно которой алгоритм и программа соотносятся как абстрактное и конкретное. По мнению Р. Тернера и А. Идена вторая точка зрения возрождает платонизм: здесь программа выступает проявлением изначальной сущности, которой является алгоритм1. Такое различение абстрактного и конкретного органично сочетается с концепцией абстракций, на несостоятельность которой неоднократно обращалось внимание ранее. Алгоритмы входят в состав оснований информатики, т.е. той ее области, где речь идет о принципах. В трансдукционном цикле алгоритмы предшествуют программам, которые их реализуют, - этим сказано главное относительно единства и различия алгоритмов и программ. Что же касается отнесения алгоритмов к математике, а программ - к лингвистике, то такая позиция, очевидно, связана с игнорированием самостоятельности информатики в качестве отдельной науки. И алгоритмы, и программы в рамках информатики выражают именно ее специфику.

Чем программа отличается от ее спецификации? Спецификация может проводиться различными средствами. В частности, она во многом определяется избранным языком программирования. В отличие от программы спецификация не дает прямого ответа на вопрос о том, с помощью каких действий можно достичь поставленной цели. Для спецификации актуален вопрос "Что?", для программы - "Как?". К сожалению, вопрос об отличии программы от спецификации крайне редко становится предметом тщательного анализа. Тем не менее Р. Тернер и А. Идеи сочли возможным выделить три актуальные точки зрения.

1. Программы декларативны, а спецификации - дескриптивны, они описывают лишь начальное и конечное состояние процесса вычисления. Такое представление неплохо сочетается с декларативной парадигмой. Но при других парадигмах схема "вход - выход" не обеспечивает полного представления о смысле программ, который определяется многочисленными дефинициями.

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

3. Языки программирования могут быть реализованы в принципе, а языки спецификации - нет. Но в таком случае признается, что спецификации выражают смыслы, посторонние для машины Тьюринга. Тернер и Идеи выражают сомнение в их существовании.

Как программа соотносится с ее осуществлением? На этот счет также существует несколько точек зрения. Часто, не особенно вдаваясь в концептуальные тонкости, осуществление рассматривается как конкретизация программы. Но, как уже отмечалось, переход от абстрактного к конкретному является наследием несостоятельной теории абстракции. Согласно другой точке зрения исполнение трактуется как изоморфное отображение программы. Подобную позицию защищает, например, Д. Чал мерс1. Его главная идея состоит в том, что физическая система выполняет вычисление, если ее причинная структура отображает его формальную структуру. С такой позицией трудно не согласиться, однако целесообразно сделать по крайней мере два уточнения. Во-первых, в информатике нет физических систем: то, что Чалмерс называет "физической системой", в действительности является процессором. Во-вторых, в отношении изоморфизма находятся не только структуры двух единиц, но и вообще все, что к ним относится, - не только связь между конституентами, но и они сами.

Американский исследователь У. Рапапорт полагает, что исполнение программы является ее семантической интерпретацией в качестве абстрактной формальной системы. Осуществление реализуется как тройственное отношение: / (осуществление) является реализацией абстракции А (программы) посредством медиума М (компьютера). Рапапорт рассматривает мозг и компьютер единообразно: оба являются медиумами по реализации мысленных абстракций. Не станем в очередной раз направлять критические стрелы в теорию абстракций. Заметим, что У. Рапапорт вполне правомерно ставит вопрос об интерпретации программы и ее исполнении, но неправомерно связывает программу с синтактикой, а ее осуществление с семантикой. Синтактика и семантика, а также прагматика характерны как для программы, так и для ее исполнения. В каком бы виде ни существовала программа, всегда есть возможность рассмотреть ее объектный, ментальный и языковой уровень, а затем при желании обратиться к синтактике, семантике или прагматике. Что касается семантики, то она характерна для всех языков программирования. От них семантика в модифицированном виде переносится на программы и далее на их исполнение. Таким образом, программа и ее исполнение отличаются друг от друга как две стадии концептуальной трансдукции, между которыми существуют отношения эквивалентности.

Удовлетворяет ли программа научным требованиям? По этому поводу существует две крайних позиции. Согласно одной из них все когнитивные науки, т.е. дисциплины так или иначе связанные с деятельностью мозга, должны ориентироваться на компьютерную парадигму, придавая особенно большой вес осуществлению программ. Эту концепцию предложил философ X. Патнэм и развил психолог Дж. Фодор. Но особенно отчетливое выражение она получила в работах канадского философа и специалиста в области информатики З. Пилишина. Мышление понимается здесь как форма вычислений, закодированная точно так же, как компьютерные образы. Согласно компьютерной теории мышления в научном тестировании нуждаются не программы, а когнитивные дисциплины. Эта принимается теория далеко не всеми, поскольку ее сторонников обвиняют в абсолютизации информатики.

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

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

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

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

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

Теоретическая разработка

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

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

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

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

Исторический экскурс

Изменение политики тестирования со стороны самих программистов представляет значительный интерес. В 1960-е гг. стремились провести тщательное тестирование, учитывая буквально все данные. Такой путь тестирования был признан неэкономным. В следующем десятилетии стремились убедиться в правильности работы программ, руководствуясь, по сути, прагматическим критерием. В этот же период особое внимание уделяли поиску ошибок. В 1980-е гг. с целью предупреждения ошибок загодя проектировали различные тесты. В 1990-е гг. стали стремиться к обеспечению качества программного продукта в целом и всех его модулей. Начиная с 2000-х гг. большое внимание уделяется циклам тестирования, автоматической проверке, подготовке специалистов соответствующего профиля.

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

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

1. Каскадная модель жизненного цикла программы (модель водопада) была предложена в 1970 г. У. Ройсом. Обычно в нее включают не менее шести фаз: 1) планирование; 2) спецификация; 3) анализ и проектирование; 4) конструирование; 5) интеграция и проектирование; 6) эксплуатация и поддержка.

2. Инкрементальная и итеративная модель жизненного цикла программы создана в начале 1990-х гг. Э. Коубёрном. Требование инкременталъности состоит в том, что система создается постепенно, но ее фазы реализуются в произвольной последовательности и в различном темпе. Итеративность состоит в многократном повторении одних и тех же операций. Например, тестирование не обязательно осуществляется лишь на заключительной стадии создания программы.

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

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

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

Выводы

1. Программа является стадией реализации трансдукции информатики как науки.

2. Написание программы - это, по сути, моделирование внутри информатики.

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

4. Исполнение программы - это эксперимент в его информационном виде.

< Предыдущая
  Оглавление
  Следующая >