Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

Ознакомительная версия.

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

«Автоматическое» программирование. Почти 40 лет люди ждут и пишут об «автоматическом программировании» — генерации решающей задачу программы, исходя из формулировки спецификации этой задачи. Некоторые высказываются сегодня так, будто ожидают от этой технологии грядущего переворота. [7]

Парнас предполагает, что термин используется из-за эффектности, а не семантического содержания, утверждая:

Короче, автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем доступный программисту в данный момент. [8]

Он утверждает, в сущности, что в большинстве случаев нужно задать спецификацию не задачи, а метода решения.

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

У этих применений есть свойства, благоприятствующие автоматизации:

• Проблемы легко описываются сравнительно небольшим числом параметров.

• Известно много методов решения, что обеспечивает наличие библиотеки альтернатив.

• Тщательный анализ привел к выработке явных правил выбора методов решения в зависимости от параметров.

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

Графическое программирование. Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. [9] Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем.

Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет.

Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы. [10] Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ.

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

Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.

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

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

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

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

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

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

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

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

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

Перспективные подходы к концептуальной сущности

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

Все технологические подходы к акциденциям процесса программирования принципиально ограничены уравнением продуктивности:

Время решения задачи = ^ (Частот)/ х (Длительность)/

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

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

Покупать, а не создавать. Наиболее радикальное возможное решение при создании программ — вообще не создавать их.

Ознакомительная версия.