Фредерик П. Брукс
| Вид материала | Документы |
- Французский писатель, журналист и критик Фредерик Бегбедер, 1495.8kb.
- Фредерик Коплстон История философии. XX век Номер страницы указан в конце страницы, 2537.19kb.
- Gold Circle Films представляют фильм компании Integrated Films. О фильме история США, 1307.29kb.
- Брукс Кубик "Тренинг Динозавров. Забытые секреты силы и развития тела", 3174.72kb.
- 2. Во всем мире родоначальником научных основ организации производства признан: ◙ Фредерик, 992.99kb.
- Фредерик Бегбедер, 2049.29kb.
- Фредерик Бегбедер. 99 франков, 2045.96kb.
- Фредерик К. Хэтфилд всестороннее руководство по развитию силы , 4595.97kb.
- Фредерик Бегбедер. 99 Франков, 2399.26kb.
- Практикум по гештальттерапии петербург, 5899.47kb.
Прежние прорывы разрешили второстепенные трудности
Если рассмотреть три наиболее плодотворных шага в произошедшемразвитии программных технологий, то обнаружится, что все они были сделаны внаправлении решения различных крупных проблем разработки программ, но этипроблемы затрагивали второстепенные, а не относящиеся к сущности трудности.Можно также видеть естественные пределы экстраполирования каждого их этихнаправлений.
Языки высокого уровня. Конечно, наибольшее значение для ростапроизводительности, надежности и простоты имело все более широкоеиспользование языков высокого уровня. Большинство исследователей считает,что этим был достигнут, по крайней мере, пятикратный рост производительностипри одновременном выигрыше в надежности, простоте и легкости понимания.
Что делает язык высокого уровня? Он освобождает программу отзначительной доли необязательной сложности. Абстрактная программа состоит изконцептуальных конструкций: операций, типов данных, последовательностей исвязи. Конкретная машинная программа связана с битами, регистрами,условиями, переходами, каналами, дисками и прочим. В той мере, в какой вязыке высокого уровня воплощены необходимые абстрактной программеконструкции и избегаются конструкции низшего порядка, он ликвидирует целыйуровень сложности, совершенно не являющийся необходимым свойством программы.
Самое большее, что может сделать язык высокого уровня, - этопредоставить все конструкции, которые по замыслу программиста содержитабстрактная программа. Конечно, уровень утонченности наших представлений оструктурах данных, типах данных и операциях неуклонно растет, но с постоянноубывающей скоростью. И языки в своем развитии все больше приближаются кизощренности нашего мышления.
Более того, с некоторого момента дальнейшая разработка языков высокогоуровня становится обузой, осложняющей, а не упрощающей интеллектуальныезадачи пользователя, редко использующего эзотерические конструкции.
Разделение времени. Большинство исследователей считает, что благодаряработе в режиме разделения времени произошел большой рост производительноститруда программистов и качества создаваемых программных продуктов, хотя и нетакой значительный, как вызванный использованием языков высокого уровня.
Разделение времени помогает решить совсем другую задачу. Благодаряразделению времени обеспечивается безотлагательность, и потому возможностьиметь общее впечатление о сложности. Из-за медленной оборачиваемости припакетной обработке мы неизбежно забываем мелочи, если не самое направлениенашей мысли, в тот момент, когда мы прервались и начали компиляцию ивыполнение программы. Этот обрыв мысли дорого обходится по времени,поскольку приходится восстанавливать ее в памяти. В худшем случае, можновообще потерять представление о том, что происходит со сложной системой.
Медленная оборачиваемость, как и сложности машинных языков, являетсявторостепенной, а не существенной трудностью процесса программирования.Предельный вклад, вносимый
разделением времени, определяетсянепосредственно. Главное - это сократить время отклика системы. По мереприближения его к нулю, оно переходит порог скорости человеческоговосприятия, составляющей около 100 миллисекунд. Дальше никакой выгодыполучить уже нельзя.
Объединенные среды программирования. Считается, что Unix и Interlisp,первые широко распространенные интегрированные среды программирования,повысили производительность в несколько раз. Почему?
Они направлены на преодоление второстепенных трудностей совместногоиспользования программ путем использования общих библиотек, унифицированныхформатов файлов, каналов и фильтров. В результате концептуальные структуры,которые, в принципе, всегда могут вызывать, обмениваться данными ииспользовать друг друга, получают возможность осуществлять это практически.
Это достижение, в свою очередь, стимулировало развитие целыхинструментальных наборов, поскольку всякий новый инструмент мог применятьсяк любым программам, используя стандартные форматы.
Благодаря этим успехам среды программирования стали предметом многихсегодняшних исследований в программной инженерии. В следующем параграфе мырассмотрим, что от них можно ожидать, и какие им присуще ограничения.
Надежды на серебро
Рассмотрим теперь те технические достижения, которые чаще всеговыдвигаются кандидатами на роль серебряной пули. К каким задачам ониобращаются? Задачам, относящимся к сущности, или остаткам наших акцидентныхсложностей? Предлагают ли они революционное развитие или пошаговоепродвижение?
Ada и другие достижения языков высокого уровня. Одним из наиболеерекламируемых достижений последнего времени является язык программированияAda - язык высокого уровня общего назначения 80-х годов. Ada действительноне только отражает эволюционное развитие концепций языков, но и воплощаетчерты, поддерживающие современные идеи проектирования и модульности.Возможно, большим достижением является не язык Ada, а философия Ada какфилософия модульности, абстрактных типов данных, иерархическогоструктурирования. Ada, пожалуй перегружен возможностями, будучи естественнымпродуктом процесса, породившего требования, положенные в основу егоразработки. Это не смертельно, поскольку подмножества рабочих словарей могутрешить проблему изучения, а прогресс электроники даст нам дешевые миллионыопераций в секунду, решающие проблему компиляции. Развитиеструктурированности программных систем - это очень хорошее применение дляденег, которые мы тратим на приобретение все больших вычислительныхмощностей. Операционные системы, громко осуждавшиеся в 60-х годах задороговизну памяти и вычислений, оказались хорошим способом применениябыстродействия и дешевой памяти, полученных в результате быстрого развитияаппаратных средств.
Тем не менее Ada не станет той серебряной пулей, которая уложит монстранизкой производительности производства программного обеспечения. В концеконцов это всего лишь еще один язык высокого уровня, а самую большую отдачуот применения таких языков мы уже получили при первом переходе отвторостепенной сложности машин к более абстрактной формулировке пошаговыхрешений. После устранения тех акциденций остались менее существенные, ивыгоды от их устранения будет, конечно, меньше.
Я предвижу, что через десятилетие, когда оценят эффективность Ada,будет признан значительный вклад этого языка, но не благодаря какой-либоотдельной его возможности и даже не благодаря им всем вместе взятым. Нестанут причиной успехов и новые среды программирования на Ada. Наибольшимвкладом Ada явится то, что переход на этот язык послужит причиной изученияпрограммистами современных методов проектирования программного обеспечения.
Объектно-ориентированное программирование. Многие, изучающие искусство программирования, связывают с объектно-ориентированным программированиембольше надежд, чем с любыми другими современными техническими увлечениями.3Я принадлежу к их числу. Марк Шерман (Mark Sherman) из Дартмута замечает,что следует проводить отличие между двумя разными идеями, фигурирующими подэтим названием: абстрактных типов данных и иерархических типов, называемыхтакже классами. Понятие абстрактного типа данных состоит в том, что типобъекта определяется именем, множеством допустимых значений и множествомдопустимых операций, а не организацией хранения, которая должна быть скрыта.Примерами являются пакеты Ada (с защищенными типами) и модули в языкеModula.
Иерархические типы, такие классы в Simula-67, позволяют определятьобщие интерфейсы, которые в дальнейшем можно уточнять с помощью подчиненныхтипов. Эти две концепции ортогональны: могут быть открытые иерархии искрытие без иерархий. Обе концепции действительно являются достижением вискусстве программирования.
Каждая из них устраняет еще одну второстепенную сложность, позволяяразработчику выразить сущность своего проекта без использования большогоколичества синтаксического материала, не добавляющего нового информационногосодержания. Использование как абстрактных, так и иерархических типовустраняет второстепенные трудности более высокого порядка и позволяетвыразить проект на более высоком уровне.
И все же такие достижения могут не более чем устранить второстепенныетрудности при выражении проекта. Существенна сложность самого проекта, начто решение таких задач никак не может повлиять. Добиться выигрыша напорядок величин с помощью объектно-ориентированного программирования можнолишь в том случае, если остающаяся сегодня в нашем языке программированиянеобязательная работа по спецификации типов сама по себе ответственна за9/10 усилий, затрачиваемых на проектирование программного продукта. В этом яне сомневаюсь.
Искусственный интеллект. Многие ожидают, что успехи в областиискусственного интеллекта позволят осуществить революционный переворот,который принесет рост производительности разработки программного обеспеченияи его качества на порядки величин.4 Я этого не жду. Чтобы увидеть, почему,разберем, что понимается под "искусственным интеллектом", а затем посмотрим,какие возможны применения.
Парнас внес ясность в терминологический хаос:
Сегодня в ходу два совершенно разных определения ИИ. ИИ-1:использование компьютеров для решения задач, которые раньше могли бытьрешены только с помощью человеческого интеллекта. ИИ-2: использованиеспециальных приемов программирования, известных как эвристическое, илиоснованное на правилах, программирование. При таком подходе изучают действияэкспертов, чтобы определить, какими эвристиками и практическим правилами онипользуются при решении задач... Программа корректируется для решения задачтак, как, по-видимому, ее решает человек.
У первого определения скользкий смысл... Кое-что укладывается сегодня вопределение ИИ-1, но как только мы видим работу программы и понимаем задачу,мы уже не думаем о ней, как о ИИ... К несчастью, я не вижу ядра методов,которые уникальны в этой области... По большей части методыпроблемно-ориентированны, и для их переноса требуются известные абстракция итворчество.5
Я полностью согласен с этой критикой. Приемы, используемые дляраспознавания речи, выказывают мало сходства с методами распознаванияизображений, при этом в экспертных системах используются методы, отличные оттех и других. Я затрудняюсь сказать, к примеру, какое влияние распознаваниеизображений может оказать на методы программирования. То же самоесправедливо в отношении распознавания речи. При разработке программ труднорешить, что именно сказать, а не собственно сказать. Никакое облегчениевыражения не может дать больше, чем незначительные выгоды.
Методы экспертных систем ИИ-2 заслуживают отдельного параграфа.
Экспертные системы. Наиболее развитой и широко применяемой частью искусственного интеллекта являются экспертные системы. Многие ученые вобласти программирования напряженно трудятся над применением этой технологиив средах разработки программного обеспечения.5 В чем состоит идея, и каковыперспективы?
Экспертная система - это программа, содержащая обобщенный генераторвыводов и базу правил, предназначенную для приема входных данных и допущенийи исследования логических следствий через заключения, выводимые из базыправил, предоставляющая заключения и рекомендации и предлагающаяпользователю объяснение полученных результатов путем обратного прослеживаниясвоих рассуждений. Помимо чисто детерминированной логики, генератор выводовобычно может работать с нечеткими или вероятностными данными.
Такие системы предоставляют некоторые явные преимущества передзапрограммированными алгоритмами решения тех же задач:
- Технология генератора выводов разрабатывается независимо отприменения и используется затем во многих приложениях.
- Изменяемые части специфических для приложения данных единообразнокодируются в базе правил. Обеспечивается инструментарий для разработки,изменения, проверки и документирования базы правил. Этим упорядочиваетсязначительная часть сложности самого приложения.
Эдвард Фейгенбаум (Edward Feigenbaum) считает, что мощь таких системрастет не благодаря совершенствованию механизмов вывода, а скорее, благодаряпополнению базы знаний, все более точно отражающей реальный мир. Я считаю,что самое важное достижение этой технологии состоит в разделении сложностиприложения и самой программы.
Как можно использовать экспертные системы при создании программногообеспечения? Различными способами: предложение правил интерфейсов,рекомендации по стратегии отладки, запоминание частоты ошибок каждого типа,подсказки по оптимизации и т.п.
Представим себе, к примеру, некоего советчика по отладке. В самойзачаточной форме диагностическая экспертная система весьма напоминаетпамятку пилота, по сути, делая предположения относительно возможных причинзатруднений. По мере развития базы правил предположения становятся болееспецифичными, более изощренно учитывая симптомы проблемы. Можно представитьтакого помощника предлагающим сначала самые общие решения, но, по меревоплощения в базе правил все большей части структуры системы, становящегосявсе более разборчивым в генерируемых гипотезах и предлагаемых тестах. Такаяэкспертная система может решительно отличаться от обычных тем, что ее базаправил, вероятно, должна быть иерархически разбита на модули таким жеобразом, как соответствующий программный продукт. Поэтому при изменениимодульной структуры продукта изменяется также модульная структура базыдиагностических правил.
Работа, которую необходимо проделать для создания диагностическихправил, в любом случае должна быть проведена при создании набора контрольныхпримеров для модулей и для системы. Если это делать достаточно общимобразом, с единообразной структурой правил и при наличии хорошего генераторавыводов, то можно действительно сократить объем работ при генерацииконтрольных примеров, а также пожизненном сопровождении и тестированиимодификаций. Такие же условия мы можем поставить и для других советчиков,используемых для других участников задачи создания программы. Возможно, онибудут многочисленны и иногда просты.
На пути ранней реализации полезных экспертных советников дляразработчика программы стоит много препятствий. Решающей частью нашеговоображаемого сценария является разработка простых способов перехода отзадания структуры программы к автоматическому или полуавтоматическомусозданию диагностических правил. Еще более сложной и важной является двойнаязадача приобретения знаний: найти членораздельно выражающихся и способных ксамоанализу экспертов, понимающих, почему они делают то или другое действие,и разработать эффективные методы извлечения их знаний и превращения в базыправил. Чтобы построить экспертную систему, необходимо иметь эксперта.
Наибольшим вкладом экспертных систем, несомненно, будет предоставлениенеопытному программисту опыта и всех знаний, накопленных лучшимипрограммистами. И это не мало. Разрыв между лучшими и средними приемамипрограммирования очень велик, возможно, он больше, чем в любой другойинженерной дисциплине. Поэтому средство распространения хороших приемов былобы очень важным.
"Автоматическое" программирование. Почти 40 лет люди ждут и пишут об"автоматическом программировании" - генерации решающей задачу программы,исходя из формулировки спецификации этой задачи. Некоторые высказываютсясегодня так, будто ожидают от этой технологии грядущего переворота.7
Парнас предполагает, что термин используется из-за эффектности, а несемантического содержания, утверждая:
Короче, автоматическое программирование всегда было эвфемизмом дляпрограммирования на языке более высокого уровня, чем доступный программистув данный момент.8
Он утверждает, в сущности, что в большинстве случаев нужно задатьспецификацию не задачи, а метода решения.
Можно отыскать исключения. Метод создания генераторов является оченьмощным и повседневно с пользой применяется в программах сортировки.Некоторые системы интегрирования дифференциальных уравнений также позволялипрямую формулировку задачи. Система производила оценку параметров, выбиралаиз библиотеки методы решения и генерировала программы.
У этих применений есть свойства, благоприятствующие автоматизации:
- Проблемы легко описываются сравнительно небольшим числом параметров.
- Известно много методов решения, что обеспечивает наличие библиотекиальтернатив.
- Тщательный анализ привел к выработке явных правил выбора методоврешения в зависимости от параметров.
Едва ли возможно обобщение таких методов на весь мир обычныхпрограммных систем, в котором ситуация с такими приятными свойствамиявляются исключениями. Трудно даже представить себе, как такой прорыв вобобщении мог бы произойти разумным образом.
Графическое программирование. Излюбленной темой докторских диссертацийв программной инженерии является графическое, или визуальное,программирование - применение компьютерной графики в разработке программногообеспечения.9 Иногда перспективы такого подхода основываются на аналогии спроектированием СБИС, в котором компьютеры играют такую большую роль. Иногдатакой подход обосновывается, исходя из того, что блок-схемы являютсяидеальным материалом при проектировании программ. Имеются мощные средствадля создания таких блок- схем.
Ничего убедительного и удивительного из этих попыток пока не вышло, - ия уверен, не выйдет.
Во-первых, как я всюду доказываю, блок-схема является весьма слабойабстракцией структуры программы.10 Лучше всего это видно из попыток Беркса,фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайненеобходимым управляющим языком высокого уровня. В том жалком виде - многиестраницы соединенных линиями прямоугольников, - в котором сегодняразрабатываются блок-схемы, они доказали, в сущности, свою бесполезность:программисты рисуют их после, а не до создания описываемых ими программ.
Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобыпоказать целиком и с достаточным разрешением сколько-нибудь подробную схемупрограммы. Так называемая "метафора рабочего стола" становится метафорой"сиденья самолета". Всякий, кому приходилось листать пачку бумаг, будучистиснутым двумя корпулентными соседями, почувствует разницу: одновременноможно увидеть очень немного. Настоящий рабочий стол позволяет обозревать ипроизвольно выбирать множество бумаг. Более того, в порыве творчества неодин программист или писатель предпочитал рабочему столу более вместительныйпол. Аппаратным технологиям нужно сделать очень большой наг, чтобыпредоставляемый экранами обзор был достаточным для задач проектированияпрограмм.
Если обратиться к основам, программное обеспечение очень трудновизуализировать, как я доказывал это выше. Составляем ли мы схемыуправляющей логики, вложенных областей, видимости переменных, перекрестныхссылок переменных, потоков данных, иерархических структур данных или чего-тоеще, они отражают лишь одно изменение взаимодействующих запутанным образомчастей программной системы. Если наложить одна на другую эти схемы,отражающие взгляд с различных точек зрения, трудно извлечь из этогокакую-либо общую точку зрения. Аналогия с интегральными схемами вводит, всущности, в заблуждение: конструкция микросхемы представляет собоймногослойный двумерный объект, геометрия которого отражает сущность.Программная система не является таким объектом.
Верификация программ. Много труда в современном программированиитратится на отладку и исправление ошибок. Может быть, мы найдем серебрянуюпулю, устранив все ошибки в самом начале, на этапе системногопроектирования? Можно ли радикально повысить производительность и надежностьпродукта, если следовать совершенно иной стратегии - обеспечить корректностьпроекта, прежде чем тратить огромные усилия на его реализацию итестирование?
Не думаю, что мы обнаружим здесь чудеса. Верификация программ являетсяочень мощной концепцией, и она очень важна для таких вещей, как созданиенадежного ядра операционной системы. Эта технология не обещает, однако,экономии труда. Верификация требует столько работы, что весьма немногиезначительные программы вообще были верифицированы.
Верификация программ не означает создания программ, лишенных ошибок. Издесь нет чудес. Математические доказательства тоже могут быть ошибочными.Поэтому хотя верификация может облегчить тестирование, она не может отменитьего.
Более существенно, что даже самая совершенная верификация программыможет лишь определить, что программа отвечает своим спецификациям. Самаясложная задача программирования - получить полную и непротиворечивуюспецификацию, и сущность создания программы на практике во многом состоит вотладке спецификации.
Среды программирования и инструменты. Какого еще выигрыша можно ожидатьот стремительно расширяющихся исследований по усовершенствованию средпрограммирования? Инстинктивно кажется, что задачи, которые сулилинаибольшую отдачу, были в числе первых, за которые взялись, и их уже решили:иерархические файловые системы, единообразные форматы файлов для полученияединообразных программных интерфейсов и обобщенных инструментов.Ориентированные на конкретные языки интеллектуальные редакторы пока не оченьраспространены, но большее, на что они способны, это устранениесинтаксических ошибок и мелких семантических.
Возможно, наибольший выигрыш среда программирования сможет дать прииспользовании строенных систем баз данных для отслеживания мириадов деталей,которые каждый программист должен точно вспоминать, и которые должныхраниться в текущем состоянии в группе работающих над одной системой.
Несомненно, что это работа заслуживает внимания и принесет некоторыеплоды как для производительности, так и для надежности. Но ввиду самой еесути отдача должна быть незначительной.
Рабочие станции. Какой выигрыш может получить искусствопрограммирования от несомненного и быстрого роста мощности и объема памятиотдельной рабочей станции? Сколько миллионов операций в секунду можноплодотворно использовать? Составление и редактирование программ вполнеобеспечиваются сегодняшними скоростями. Компиляция может быть ускорена, нодесятикратное увеличение скорости машины, вне сомнения, сделает обдумываниеосновным занятием программиста в течение рабочего дня. Пожалуй, это так ужесейчас.
Конечно, мы приветствуем увеличение мощности рабочих станций. Норассчитывать на связанные с этим чудеса мы не можем.