ах  высокого уровнЯ, используемых  в режиме он-лайн, будь  то в пакетном
режиме или интерактивно. Љак Я доказывал, такие Языки и системы очень сильно
облегчают жизнь программистов. Џоскольку машины сделаны длЯ людей, а не люди
длЯ машин, их использование оправдано как с экономической точки  зрениЯ, так
и чисто по- человечески.

        ѓлава  16.  ‘еребрЯной пули нет  -  сущность и акциденциЯ в  программной
инженнерии     <i>Ќет ни  одного открытиЯ  ни в технологии, ни в методах управлениЯ,
одно  только  использование   которого  обещало   бы  в  течение  ближайшего
десЯтилетиЯ на  порЯдок  повысить  производительность, надежность,  простоту
разработки программного обеспечениЯ.</i>
     <b>ђезюме1</b>
     ‘оздание программного обеспечениЯ всегда включает в себЯ существенные
задачи   -  моделирование  сложных  концептуальных  структур,   составлЯющих
абстрактный  программный  объект,  и  второстепенные   задачи   -   создание
представлений этих абстрактных объектов  с помощью Языков программированиЯ и
отображение их в машинные Языки с учетом ограничений по памЯти и скорости. ‚
прошлом рост  продуктивности  программированиЯ  по большей  части достигалсЯ
благодарЯ устранению искусственных преград,  делавших  второстепенные задачи
чрезмерно  трудными,  например,  жестких аппаратных  ограничений,  неудобных
Языков  программированиЯ,  нехватки машинного  времени.  ЉакаЯ  часть работы
разработчиков программного обеспечениЯ все еще свЯзана со второстепенными, а
не  с  существенными обстоЯтельствами? …сли  она  занимает  менее  9/10 всех
затрат,  то,  даже  сведЯ все второстепенные затраты  к нулю,  мы не получим
роста производительности на порЯдок величин.
     Џоэтому,  похоже,  настало  времЯ  обратитьсЯ  к  существенным  задачам
программированиЯ, свЯзанным с моделированием концептуальных структур большой
сложности. џ предлагаю:
     - €спользовать массовый рынок, чтобы  избежать созданиЯ того, что можно
купить.
     - €спользовать быстрое макетирование как часть запланированных итераций
длЯ установлениЯ технических требований к программному обеспечению.
     -  Ћрганично  наращивать программы,  добавлЯЯ к  системам  все  большую
функциональность по мере их запуска, использованиЯ и тестированиЯ.
     -  ‚ыЯвлЯть  и  растить  выдающихсЯ   разработчиков  концепций   нового
поколениЯ.
     ‚ведение
     €з всех монстров, которыми наполнены кошмары нашего  фольклора, самыми
страшными  ЯвлЯютсЯ  оборотни,  поскольку нас пугает неожиданное превращение
того, что  нам хорошо  знакомо, в  нечто  ужасное. Њы  ищем серебрЯные пули,
которые могли бы волшебным образом уложить оборотней наповал.
     •орошо  знакомый  программный  проект напоминает  таких  оборотней  (по
крайней  мере,  в   представлении  менеджеров,  не  ЯвлЯющихсЯ  техническими
специалистами) тем,  что, будучи простым и невинным на  вид, он может  стать
чудищем  проваленных  графиков  работы,  раздувшихсЯ бюджетов и неработающих
продуктов.
     €  мы слышим отчаЯнные  крики с просьбами дать серебрЯную пулю - нечто,
способное  снизить  стоимость  программных  продуктов  так   же  резко,  как
снизилась стоимость компьютеров.
     Ќо,  вглЯдываЯсь  в  предстоЯщее  десЯтилетие,  мы  не   видим  никакой
серебрЯной пули.  Ќет ни  одного  открытиЯ  ни  в технологии,  ни в  методах
управлениЯ,  одно только использованиЯ  которых  обещало  бы хоть на порЯдок
величин  повысить производительность, надежность, простоту. ‚ этой  главе мы
попытаемсЯ увидеть, почему  это так, исследуЯ природу задач программированиЯ
и свойства предлагаемых пуль.
     Ћднако  скептицизм - это не  пессимизм.  •отЯ мы не  видим ошеломлЯющих
прорывов    и    действительно    считаем    их   несвойственными    природе
программированиЯ,   происходит   много   вселЯющих   надежды   нововведений.
„исциплинированные  и последовательные усилиЯ, направленные на  их развитие,
распространение и  использование, действительно могут  дать рост на  порЯдок
величин. Ќет царского пути, но все же путь есть.
     Џервым  шагом к лечению болезней стала замена представлений о демонах и
"соках"  в  организме  теорией  бактерий.  ‘ам этот шаг, обещавший  надежду,
опроверг все  мечты  о  чудесном исцелении. Ћн подсказал исследователЯм, что
прогресс будет  осуществлЯтьсЯ шажками, с большим трудом, и что постоЯнное и
неослабное  внимание  нужно  уделЯть санитарии.  ’о же  происходит сегоднЯ с
программной инженерией.
     Ќеизбежны ли трудности? ’рудности, вытекающие из сущности
     ‘еребрЯных пуль не только не видно в настоЯщее времЯ, но в силу самой
природы  программного обеспечениЯ маловероЯтно, что они вообще будут найдены
-  не  будет  изобретений, способных  повлиЯть  на  продуктивность созданиЯ,
надежность  и  простоту  программного  обеспечениЯ  так,  как   электроника,
транзисторы и интегральные схемы - на аппаратное обеспечение компьютеров. Ќе
следует ожидать,  что когда-либо в будущем каждые два года будет происходить
двукратный рост.
     ‚о-первых, следует считать необычным не то, что так медленно происходит
прогресс в программировании, а  то,  что  он так  быстро  идет  в аппаратном
обеспечении  компьютеров.  Ќи   одна  другаЯ  технологиЯ   за  всю   историю
цивилизации  не   имела  за   30  лет  своего  развитиЯ  роста   соотношениЯ
производительность/цена  на  шесть порЯдков.  Ќи  одна другаЯ технологиЯ  не
позволЯет   выбрать,   какой  выигрыш   предпочесть:  улучшить   технические
характеристики  <i>или</i>  снизить  затраты.   Ћба  эти  выигрыша  стали  возможны
благодарЯ переходу производства  компьютеров  из  сборочного производства  в
обрабатывающее.
     ‚о-вторых, чтобы посмотреть,  какой скорости развитиЯ  можно ожидать от
программных технологий,  полезно  изучить имеющиесЯ  в них трудности. ‘ледуЯ
Ђристотелю, Я  делю их на <i>сущности</i>  - трудности, внутренне присущие  природе
программного  обеспечениЯ,   и  <i>акциденции</i>  -  трудности,  которые   сегоднЯ
сопутствуют производству  программного обеспечениЯ, но не ЯвлЯютсЯ внутренне
ему присущими.
     Ђкциденции Я рассматриваю  в следующем  параграфе.  ‘начала  рассмотрим
сущность.
     ‘ущностью  программного  объекта  ЯвлЯетсЯ  конструкциЯ,  состоЯщаЯ  из
сцепленных  вместе концепций: наборов данных, взаимосвЯзей между  элементами
данных, алгоритмов  и  вызовов  функций. ќта сущность ЯвлЯетсЯ абстрактной в
том  отношении, что концептуальнаЯ конструкциЯ  остаетсЯ одной и той же  при
различных представлениЯх. ’ем  не  менее она  обладает  высокой точностью  и
большим числом деталей.
     <i>џ считаю, что сложность созданиЯ программного обеспечениЯ заключаетсЯ в
задании    технических    требований,   проектировании   и   проверке   этой
концептуальной конструкции, а не в затратах, свЯзанных с ее представлением и
проверкой точности представлениЯ.</i> Љонечно, мы  делаем синтаксические ошибки,
но  в большинстве  систем  они  несущественны  в сравнении с концептуальными
ошибками.
     ‚ерно  то,  что  создание  программных  систем  всегда  будет  трудным.
‘еребрЯной пули нет по самой природе вещей.
     ђассмотрим неотъемлемые свойства этой несократимой сущности современных
программных систем: сложность, согласованность, изменЯемость и незримость.
     <b>‘ложность.</b> ‘ложность программных объектов более зависит от их размеров,
чем, возможно, длЯ любых других создаваемых человеком конструкций, поскольку
никакие  две их части  не схожи  между собой (по крайней мере,  выше  уровнЯ
операторов).  …сли они  схожи,  то  мы  объединЯем  их в одну  подпрограмму,
открытую или закрытую.  ‚ этом отношении  программные системы имеют глубокое
отличие  от  компьютеров, домов  и  автомобилей, где  повторЯющиесЯ элементы
имеютсЯ в изобилии.
     ‘ами  цифровые  компьютеры  сложнее,  чем  большинство  изготавливаемых
людьми вещей. —исло  их состоЯний очень велико, поэтому их  трудно понимать,
описывать и тестировать.  “ программных  систем число возможных состоЯний на
порЯдки величин превышает число состоЯний компьютеров.
     Ђналогично,  масштабирование  программного  объекта  -  это  не  просто
увеличение  в размере тех  же самых  элементов,  это  обЯзательно увеличение
числа   различных    элементов.   ‚   большинстве   случаев   эти   элементы
взаимодействуют между  собой неким  нелинейным  образом, и  сложность целого
растет значительно быстрее, чем линейно.
     ‘ложность   программ   ЯвлЯетсЯ  существенным,   а   не  второстепенным
свойством.  Џоэтому  описаниЯ  программных объектов, абстрагирующиесЯ  от их
сложности,  часто  абстрагируютсЯ  от их сущности.  Њатематика и  физические
науки за три  столетиЯ достигли  больших успехов, создаваЯ упрощенные модели
сложных физических Явлений, получаЯ  из этих  моделей свойства и проверЯЯ их
опытным путем. ќто удавалось благодарЯ тому, что сложности, игнорировавшиесЯ
в  моделЯх, не  были  существенными свойствами Явлений. €  это не действует,
когда сложности ЯвлЯютсЯ сущностью.
     Њногие  классические  трудности   разработки  программного  обеспечениЯ
проистекают их этой сложности сущности и ее нелинейного роста при увеличении
размера.  ‘ложность  служит  причиной  трудности   процесса   общениЯ  между
участниками  бригады  разработчиков,   что  ведет  к   ошибкам  в  продукте,
превышению  стоимости  разработки, затЯгиванию  выполнениЯ  графиков  работ.
‘ложность служит причиной  трудности перечислениЯ, а  тем  более  пониманиЯ,
всех  возможных состоЯний программы, а  отсюда  возникает  ее  ненадежность.
‘ложность  функций  служит причиной  трудностей  при их вызове,  из-за  чего
программами  трудно   пользоватьсЯ.  ‘ложность  структуры  служит   причиной
трудностей при развитии  программ и добавлении новых  функций так,  чтобы не
возникали   побочные   эффекты.   ‘ложность  структуры   служит   источником
невизуализуемых состоЯний, в которых нарушаетсЯ система защиты.
     ‘ложность служит причиной не  только технических, но и административных
проблем. €з-за сложности трудно осуществлЯть надзор, а в результате страдает
концептуальнаЯ  целостность.  ’рудно  найти  и  держать  под  контролем  все
свободные концы.  Ћбучение  и понимание  становитсЯ колоссальной  нагрузкой,
из-за чего текучесть рабочей силы превращаетсЯ в катастрофу.
     <b>‘огласованность.</b>  ‹юди,  свЯзанные  с программированием,  не одиноки  в
проблемах сложности.  ”изика имеет  дело с  объектами чрезвычайной сложности
даже  на  уровне  элементарных  частиц.  Ћднако  физик  работает  в  твердой
уверенности, что можно найти общие принципы, будь то кварки или общаЯ теориЯ
полЯ. ќйнштейн неоднократно  утверждал,  что  природа  должна иметь  простые
объЯснениЯ, поскольку Ѓогу не свойственны капризность и произвол.
     “  разработчика  программного  обеспечениЯ нет такой утешительной веры.
‘ложность,  с  которой  он  должен  совладать,  по  большей  части  ЯвлЯетсЯ
произвольной,   необоснованно   вызванной    многочисленными   человеческими
установлениЯми и  системами,  которым  должны  удовлетворить его интерфейсы.
‘истемы  различаютсЯ   интерфейсами   и  менЯютсЯ   во  времени  не  в  силу
необходимости, а лишь потому, что были созданы не Ѓогом, а разными людьми.
     ‚о  многих  случаЯх  программное  обеспечение  должно  согласовыватьсЯ,
поскольку  только  что поЯвилось  на  сцене.  ‚  других  случаЯх  оно должно
согласовыватьсЯ, поскольку есть ощущение, что его  легче  всего согласовать.
Ќо во всех случаЯх значительнаЯ часть сложности происходит от согласованиЯ с
другими  интерфейсами,  и  это  невозможно  упростить  только  в  результате
перепроектированиЯ программного обеспечениЯ.
     <b>€зменЯемость.</b>  Џрограммные  объекты  постоЯнно  подвержены  изменениЯм.
Љонечно,  это   относитсЯ  и   к  зданиЯм,  автомобилЯм,   компьютерам.   Ќо
произведенные  вещи  редко  подвергаютсЯ  изменениЯм  после изготовлениЯ. €х
заменЯют  новые модели, или существенные изменениЯ включают в более  поздние
серийные  экземплЯры  того  же  базового  проекта.   Ћтзывы  у  потребителей
автомобилей на  практике  встречаютсЯ  весьма  редко, а изменениЯ работающих
компьютеров  еще  реже.   ’о  и   другое  случаетсЯ  значительно  реже,  чем
модификациЯ работающего программного обеспечениЯ.
     Ћтчасти  это  происходит потому, что программное обеспечение в  системе
воплощает ее назначение, а назначение более всего ощущает влиЯние изменений.
Ћтчасти  это происходит потому, что программное  обеспечение легче изменить:
это чистаЯ мысль,  бесконечно податливаЯ.  ‡даниЯ тоже  перестраиваютсЯ,  но
признаваемаЯ всеми высокаЯ стоимость изменений умерЯет капризы новаторов.
     ‚се  удачные  программные  продукты  подвергаютсЯ изменениЯм. Џри  этом
действуют  два  процесса.  ‚о-первых,   как  только   обнаруживаетсЯ  польза
программного продукта,  начинаютсЯ  попытки  применениЯ его  на грани или за
пределами  первоначальной области. ’ребование  расширениЯ функций исходит, в
основном,  от пользователей,  которые  удовлетворены основным назначением  и
изобретают длЯ него новые применениЯ.
     ‚о-вторых,  удачный  программный  продукт живет дольше  обычного  срока
существованиЯ машины, длЯ которой он первоначально был создан. ЏриходЯт если
не  новые  компьютеры,  то новые  диски, новые  мониторы, новые принтеры,  и
программа должна быть согласована с возможностЯми новых машин.
     Љороче, программный  продукт  встроен  в культурную матрицу приложений,
пользователей, законов и машин. ‚се они непрерывно менЯютсЯ, и  их изменениЯ
неизбежно требуют изменениЯ программного продукта.
     <b>Ќезримость.</b> Џрограммный продукт невидим и невизуализуем. ѓеометрические
абстракции ЯвлЯютсЯ мощным инструментом. Џлан зданиЯ помогает  архитектору и
заказчику оценить пространство,  возможности  перемещениЯ,  виды. ‘тановЯтсЯ
очевидными   противоречиЯ,  можно  заметить   упущениЯ.  Њасштабные  чертежи
механических деталей  и объемные модели молекул, будучи абстракциЯми, служат
той  же  цели.  ѓеометрическаЯ   реальность  схватываетсЯ  в  геометрической
абстракции.
     ђеальность  программного  обеспечениЯ   не  встраиваетсЯ   естественным
образом  в  пространство.   Џоэтому  у  него  нет  готового  геометрического
представлениЯ подобно тому, как местность  представлЯетсЯ картой, кремниевые
микросхемы -  диаграммами, компьютеры - схемами  соединений.  Љак только  мы
пытаемсЯ  графически представить  структуру  программы, мы обнаруживаем, что
требуетсЯ не один, а несколько неориентированных графов, наложенных один  на
другой.  Ќесколько  графов  могут  представлЯть управлЯющие  потоки,  потоки
данных,  схемы  зависимостей,  временных   последовательностей,  соотношений
пространства  имен.  Ћбычно  они  даже  не  ЯвлЯютсЯ  плоскими,  не  то  что
иерархическими.  Ќа  практике одним из способов установлениЯ концептуального
контролЯ  над такой  структурой ЯвлЯетсЯ  обрезание свЯзей  до тех пор, пока
один или несколько графов не станут иерархическими.2
     ЌесмотрЯ на  прогресс,  достигнутый в  ограничении и упрощении структур
программного  обеспечениЯ, они  остаютсЯ невизуализуемыми по своей  природе,
тем самым  лишаЯ нас  одного  из  наиболее мощных  инструментов оперированиЯ
концепциЯми. ќтот  недостаток  не только затруднЯет  индивидуальный  процесс
проектированиЯ, но и серьезно затруднЯет общение между разработчиками.
     Џрежние прорывы разрешили второстепенные трудности
     …сли  рассмотреть  три  наиболее  плодотворных  шага  в  произошедшем
развитии программных технологий, то обнаружитсЯ,  что все они были сделаны в
направлении решениЯ  различных крупных проблем  разработки программ, но  эти
проблемы затрагивали второстепенные, а  не относЯщиесЯ к сущности трудности.
Њожно также видеть естественные пределы  экстраполированиЯ каждого  их  этих
направлений.
     <b>џзыки  высокого   уровнЯ.</b>   Љонечно,  наибольшее  значение   длЯ  роста
производительности,   надежности   и   простоты  имело  все   более  широкое
использование Языков высокого  уровнЯ.  Ѓольшинство  исследователей считает,
что этим был достигнут, по крайней мере, пЯтикратный рост производительности
при одновременном выигрыше в надежности, простоте и легкости пониманиЯ.
     —то  делает   Язык   высокого  уровнЯ?  Ћн   освобождает  программу  от
значительной доли необЯзательной сложности. ЂбстрактнаЯ программа состоит из
концептуальных  конструкций: операций,  типов данных,  последовательностей и
свЯзи.   ЉонкретнаЯ   машиннаЯ  программа  свЯзана  с   битами,  регистрами,
условиЯми,  переходами, каналами,  дисками и прочим. ‚  той мере, в  какой в
Языке   высокого   уровнЯ  воплощены   необходимые   абстрактной   программе
конструкции  и избегаютсЯ конструкции низшего  порЯдка, он ликвидирует целый
уровень сложности, совершенно не ЯвлЯющийсЯ необходимым свойством программы.
     ‘амое  большее,  что  может  сделать   Язык  высокого  уровнЯ,   -  это
предоставить  все  конструкции, которые  по  замыслу  программиста  содержит
абстрактнаЯ программа.  Љонечно, уровень утонченности наших  представлений о
структурах данных, типах данных и операциЯх неуклонно растет, но с постоЯнно
убывающей  скоростью. €  Языки в  своем развитии  все  больше приближаютсЯ к
изощренности нашего мышлениЯ.
     Ѓолее того, с некоторого  момента дальнейшаЯ разработка Языков высокого
уровнЯ становитсЯ  обузой,  осложнЯющей, а  не  упрощающей  интеллектуальные
задачи пользователЯ, редко использующего эзотерические конструкции.
     <b>ђазделение времени.</b>  Ѓольшинство исследователей считает, что  благодарЯ
работе в режиме разделениЯ времени произошел большой рост производительности
труда программистов и качества создаваемых программных продуктов, хотЯ и  не
такой значительный, как вызванный использованием Языков высокого уровнЯ.
     ђазделение  времени помогает  решить  совсем  другую  задачу. ЃлагодарЯ
разделению времени обеспечиваетсЯ безотлагательность,  и потому  возможность
иметь  общее впечатление о  сложности.  €з-за медленной  оборачиваемости при
пакетной обработке мы неизбежно забываем  мелочи, если  не самое направление
нашей  мысли,  в  тот  момент,  когда мы прервались и  начали  компилЯцию  и
выполнение  программы.  ќтот   обрыв  мысли  дорого  обходитсЯ  по  времени,
поскольку приходитсЯ восстанавливать ее в памЯти.  ‚  худшем  случае,  можно
вообще потерЯть представление о том, что происходит со сложной системой.
     ЊедленнаЯ  оборачиваемость, как и сложности машинных  Языков,  ЯвлЯетсЯ
второстепенной,  а  не  существенной  трудностью  процесса программированиЯ.
Џредельный    вклад,    вносимый     разделением    времени,    определЯетсЯ
непосредственно.  ѓлавное - это  сократить  времЯ  отклика системы. Џо  мере
приближениЯ  его  к  нулю,  оно  переходит   порог   скорости  человеческого
восприЯтиЯ,  составлЯющей  около  100  миллисекунд.  „альше  никакой  выгоды
получить уже нельзЯ.
     <b>Ћбъединенные среды программированиЯ.</b>  ‘читаетсЯ, что  Unix и Interlisp,
первые  широко  распространенные  интегрированные  среды   программированиЯ,
повысили производительность в несколько раз. Џочему?
     Ћни направлены  на  преодоление  второстепенных  трудностей <i>совместного</i>
использованиЯ  программ путем использованиЯ общих библиотек, унифицированных
форматов файлов,  каналов и фильтров. ‚ результате концептуальные структуры,
которые,  в   принципе,   всегда  могут  вызывать,  обмениватьсЯ  данными  и
использовать друг друга, получают возможность осуществлЯть это практически.
     ќто  достижение,  в   свою   очередь,   стимулировало  развитие   целых
инструментальных наборов, поскольку всЯкий новый инструмент мог  применЯтьсЯ
к любым программам, используЯ стандартные форматы.
     ЃлагодарЯ  этим успехам  среды программированиЯ стали предметом  многих
сегоднЯшних  исследований в программной инженерии. ‚ следующем параграфе  мы
рассмотрим, что от них можно ожидать, и какие им присуще ограничениЯ.
     Ќадежды на серебро
     ђассмотрим  теперь  те  технические  достижениЯ,  которые чаще  всего
выдвигаютсЯ  кандидатами  на  роль  серебрЯной  пули.  Љ каким  задачам  они
обращаютсЯ? ‡адачам, относЯщимсЯ к сущности,  или остаткам наших акцидентных
сложностей?   Џредлагают  ли  они  революционное   развитие   или  пошаговое
продвижение?
     <b>Ada и  другие достижениЯ  Языков  высокого  уровнЯ.</b>  Ћдним из  наиболее
рекламируемых достижений  последнего времени ЯвлЯетсЯ  Язык программированиЯ
Ada  - Язык высокого уровнЯ общего назначениЯ  80-х годов. Ada действительно
не  только отражает эволюционное развитие  концепций Языков,  но и воплощает
черты,   поддерживающие  современные  идеи   проектированиЯ  и  модульности.
‚озможно,  большим  достижением  ЯвлЯетсЯ не Язык Ada,  а  философиЯ Ada как
философиЯ    модульности,    абстрактных    типов   данных,   иерархического
структурированиЯ. Ada, пожалуй перегружен возможностЯми, будучи естественным
продуктом  процесса,   породившего   требованиЯ,  положенные  в  основу  его
разработки. ќто не смертельно, поскольку подмножества рабочих словарей могут
решить проблему изучениЯ, а прогресс  электроники  даст нам дешевые миллионы
операций    в    секунду,    решающие    проблему    компилЯции.    ђазвитие
структурированности программных  систем -  это  очень хорошее применение длЯ
денег,  которые   мы  тратим  на  приобретение  все  больших  вычислительных
мощностей.  Ћперационные  системы,  громко  осуждавшиесЯ  в  60-х  годах  за
дороговизну  памЯти  и  вычислений,  оказались  хорошим способом  применениЯ
быстродействиЯ и дешевой памЯти,  полученных  в результате быстрого развитиЯ
аппаратных средств.
     ’ем не менее Ada не станет той серебрЯной пулей, котораЯ уложит монстра
низкой  производительности  производства  программного обеспечениЯ.  ‚ конце
концов это всего лишь еще  один Язык высокого уровнЯ, а самую большую отдачу
от  применениЯ  таких  Языков   мы  уже  получили  при  первом  переходе  от
второстепенной  сложности машин  к более абстрактной формулировке  пошаговых
решений.  Џосле  устранениЯ  тех акциденций  остались менее  существенные, и
выгоды от их устранениЯ будет, конечно, меньше.
     џ предвижу,  что  через  десЯтилетие, когда  оценЯт  эффективность Ada,
будет признан  значительный вклад  этого Языка, но  не благодарЯ  какой-либо
отдельной его  возможности и  даже не благодарЯ им всем  вместе  взЯтым.  Ќе
станут  причиной успехов и  новые среды программированиЯ на Ada.  Ќаибольшим
вкладом Ada  ЯвитсЯ то, что переход  на этот Язык послужит причиной изучениЯ
программистами современных методов проектированиЯ программного обеспечениЯ.
     <b>Ћбъектно-ориентированное  программирование.</b> Њногие, изучающие искусство
программированиЯ,  свЯзывают  с  объектно-ориентированным  программированием
больше надежд, чем  с любыми другими современными техническими увлечениЯми.3
џ  принадлежу к их числу. Њарк ерман (Mark Sherman)  из „артмута  замечает,
что следует проводить отличие между двумЯ разными идеЯми, фигурирующими  под
этим названием:  абстрактных типов данных и иерархических  типов, называемых
также <i>классами</i>. ЏонЯтие абстрактного  типа  данных  состоит  в том, что  тип
объекта  определЯетсЯ  именем, множеством допустимых  значений и  множеством
допустимых операций, а не организацией хранениЯ, котораЯ должна быть скрыта.
Џримерами  ЯвлЯютсЯ  пакеты Ada  (с  защищенными  типами) и модули  в  Языке
Modula.
     €ерархические  типы,  такие  классы  в Simula-67,  позволЯют определЯть
общие интерфейсы,  которые в дальнейшем можно уточнЯть с помощью подчиненных
типов. ќти  две  концепции ортогональны:  могут  быть  открытые  иерархии  и
скрытие без  иерархий.  Ћбе  концепции действительно  ЯвлЯютсЯ достижением в
искусстве программированиЯ.
     ЉаждаЯ  из них  устранЯет еще  одну второстепенную  сложность, позволЯЯ
разработчику выразить  сущность  своего  проекта  без использованиЯ большого
количества синтаксического материала, не добавлЯющего нового информационного
содержаниЯ.  €спользование  как  абстрактных,   так  и  иерархических  типов
устранЯет  второстепенные  трудности  более  высокого  порЯдка  и  позволЯет
выразить проект на более высоком уровне.
     € все же такие достижениЯ могут  не более чем  устранить второстепенные
трудности при  выражении проекта. ‘ущественна  сложность самого проекта,  на
что решение  таких  задач  никак  не может  повлиЯть.  „обитьсЯ выигрыша  на
порЯдок величин  с помощью  объектно-ориентированного программированиЯ можно
лишь  в том случае,  если остающаЯсЯ  сегоднЯ в нашем Языке программированиЯ
необЯзательнаЯ работа  по  спецификации  типов сама по себе ответственна  за
9/10 усилий, затрачиваемых на проектирование программного продукта. ‚ этом Я
не сомневаюсь.
     <b>€скусственный   интеллект.</b>  Њногие  ожидают,  что   успехи  в   области
искусственного  интеллекта  позволЯт  осуществить  революционный  переворот,
который принесет рост производительности разработки программного обеспечениЯ
и его качества на порЯдки величин.4 џ этого не  жду. —тобы  увидеть, почему,
разберем, что понимаетсЯ под "искусственным интеллектом", а затем посмотрим,
какие возможны применениЯ.
     Џарнас внес Ясность в терминологический хаос:
     <i>‘егоднЯ   в  ходу   два  совершенно  разных   определениЯ   €€.   €€-1:
использование  компьютеров длЯ  решениЯ  задач,  которые  раньше  могли быть
решены  только  с  помощью  человеческого  интеллекта.  €€-2:  использование
специальных  приемов  программированиЯ,  известных  как  эвристическое,  или
основанное на правилах, программирование. Џри таком подходе изучают действиЯ
экспертов, чтобы определить, какими эвристиками и практическим правилами они
пользуютсЯ при решении задач...  Џрограмма  корректируетсЯ длЯ решениЯ задач
так, как, по-видимому, ее решает человек.
     “ первого определениЯ скользкий смысл... Љое-что укладываетсЯ сегоднЯ в
определение €€-1, но как только мы видим работу программы и понимаем задачу,
мы  уже  не  думаем о ней, как о €€... Љ несчастью, Я  не вижу Ядра методов,
которые   уникальны    в   этой   области...   Џо   большей   части   методы
проблемно-ориентированны, и длЯ их переноса требуютсЯ известные абстракциЯ и
творчество.</i>5
     џ  полностью  согласен  с  этой  критикой.   Џриемы,  используемые  длЯ
распознаваниЯ  речи,  выказывают  мало  сходства  с  методами  распознаваниЯ
изображений, при этом в экспертных системах используютсЯ методы, отличные от
тех  и других. џ затруднЯюсь сказать, к примеру, какое влиЯние распознавание
изображений   может  оказать  на   методы  программированиЯ.   ’о  же  самое
справедливо в отношении распознаваниЯ  речи. Џри разработке программ  трудно
решить, что  именно  сказать,  а не  собственно сказать. Ќикакое  облегчение
выражениЯ не может дать больше, чем незначительные выгоды.
     Њетоды экспертных систем €€-2 заслуживают отдельного параграфа.
     <b>ќкспертные системы.</b>  Ќаиболее  развитой  и  широко  применЯемой  частью
искусственного  интеллекта  ЯвлЯютсЯ  экспертные системы.  Њногие  ученые  в
области программированиЯ напрЯженно трудЯтсЯ над применением этой технологии
в средах разработки программного обеспечениЯ.5 ‚ чем состоит идеЯ,  и каковы
перспективы?
     ќкспертнаЯ  система -  это  программа, содержащаЯ  обобщенный генератор
выводов и базу правил, предназначенную длЯ приема входных данных и допущений
и  исследованиЯ логических следствий через  заключениЯ,  выводимые  из  базы
правил,   предоставлЯющаЯ   заключениЯ   и   рекомендации   и   предлагающаЯ
пользователю объЯснение полученных результатов путем обратного прослеживаниЯ
своих рассуждений. Џомимо чисто  детерминированной логики, генератор выводов
обычно может работать с нечеткими или вероЯтностными данными.
     ’акие  системы   предоставлЯют  некоторые  Явные   преимущества   перед
запрограммированными алгоритмами решениЯ тех же задач:
     -   ’ехнологиЯ   генератора  выводов  разрабатываетсЯ   независимо   от
применениЯ и используетсЯ затем во многих приложениЯх.
     - €зменЯемые  части  специфических  длЯ приложениЯ  данных единообразно
кодируютсЯ в базе  правил.  ЋбеспечиваетсЯ  инструментарий  длЯ  разработки,
изменениЯ, проверки  и  документированиЯ  базы правил.  ќтим упорЯдочиваетсЯ
значительнаЯ часть сложности самого приложениЯ.
     ќдвард ”ейгенбаум (Edward Feigenbaum) считает,  что  мощь  таких систем
растет не благодарЯ совершенствованию механизмов вывода, а скорее, благодарЯ
пополнению базы знаний,  все  более точно отражающей реальный мир. џ считаю,
что  самое важное достижение этой  технологии состоит в разделении сложности
приложениЯ и самой программы.
     Љак  можно  использовать экспертные системы при  создании  программного
обеспечениЯ?   ђазличными   способами:   предложение   правил   интерфейсов,
рекомендации по  стратегии отладки, запоминание частоты ошибок каждого типа,
подсказки по оптимизации и т.п.
     Џредставим  себе,  к  примеру, некоего  советчика  по отладке.  ‚ самой
зачаточной  форме   диагностическаЯ  экспертнаЯ  система  весьма  напоминает
памЯтку пилота, по сути, делаЯ  предположениЯ относительно возможных  причин
затруднений.  Џо мере  развитиЯ базы правил предположениЯ  становЯтсЯ  более
специфичными,  более изощренно учитываЯ симптомы проблемы. Њожно представить
такого  помощника предлагающим сначала  самые  общие решениЯ,  но,  по  мере
воплощениЯ в базе правил все  большей части структуры системы, становЯщегосЯ
все более разборчивым в генерируемых гипотезах  и предлагаемых тестах. ’акаЯ
экспертнаЯ система может  решительно отличатьсЯ от  обычных тем, что ее база
правил,  вероЯтно,  должна  быть иерархически  разбита  на  модули таким  же
образом,  как  соответствующий  программный продукт. Џоэтому  при  изменении
модульной  структуры  продукта изменЯетсЯ  также  модульнаЯ  структура  базы
диагностических правил.
     ђабота,  которую  необходимо  проделать  длЯ  созданиЯ  диагностических
правил, в любом случае должна быть проведена при создании набора контрольных
примеров  длЯ  модулей  и  длЯ  системы.  …сли это делать  достаточно  общим
образом, с единообразной структурой правил и при наличии хорошего генератора
выводов,  то  можно  действительно  сократить   объем  работ  при  генерации
контрольных  примеров,  а  также  пожизненном  сопровождении  и тестировании
модификаций. ’акие же условиЯ  мы можем поставить и длЯ  других  советчиков,
используемых длЯ других участников задачи созданиЯ  программы. ‚озможно, они
будут многочисленны и иногда просты.
     Ќа  пути   ранней   реализации   полезных   экспертных  советников  длЯ
разработчика  программы  стоит много  препЯтствий.  ђешающей  частью  нашего
воображаемого сценариЯ  ЯвлЯетсЯ разработка  простых  способов  перехода  от
заданиЯ  структуры   программы  к  автоматическому  или  полуавтоматическому
созданию диагностических правил. …ще более сложной и важной ЯвлЯетсЯ двойнаЯ
задача приобретениЯ  знаний: найти членораздельно выражающихсЯ и способных к
самоанализу экспертов, понимающих, почему они делают то или другое действие,
и разработать эффективные методы  извлечениЯ их знаний и  превращениЯ в базы
правил. —тобы построить экспертную систему, необходимо иметь эксперта.
     Ќаибольшим вкладом экспертных систем, несомненно,  будет предоставление
неопытному   программисту   опыта   и   всех  знаний,   накопленных  лучшими
программистами. €  это  не  мало. ђазрыв между  лучшими и  средними приемами
программированиЯ  очень  велик, возможно,  он больше,  чем  в  любой  другой
инженерной дисциплине. Џоэтому средство распространениЯ хороших приемов было
бы очень важным.
     <b>"Ђвтоматическое" программирование.</b>  Џочти 40 лет  люди  ждут и пишут об
"автоматическом  программировании" - генерации  решающей  задачу  программы,
исходЯ из формулировки спецификации  этой  задачи.  Ќекоторые  высказываютсЯ
сегоднЯ так, будто ожидают от этой технологии грЯдущего переворота.7
     Џарнас предполагает,  что термин используетсЯ  из-за эффектности, а  не
семантического содержаниЯ, утверждаЯ:
     <i>Љороче,  автоматическое  программирование  всегда  было эвфемизмом  длЯ
программированиЯ  на Языке более высокого уровнЯ, чем доступный программисту
в данный момент.</i>8
     Ћн  утверждает, в  сущности, что в  большинстве  случаев  нужно  задать
спецификацию не задачи, а метода решениЯ.
     Њожно отыскать исключениЯ.  Њетод созданиЯ  генераторов  ЯвлЯетсЯ очень
мощным  и  повседневно  с  пользой  применЯетсЯ  в   программах  сортировки.
Ќекоторые системы интегрированиЯ дифференциальных  уравнений также позволЯли
прЯмую формулировку задачи. ‘истема производила  оценку параметров, выбирала
из библиотеки методы решениЯ и генерировала программы.
     “ этих применений есть свойства, благоприЯтствующие автоматизации:
     - Џроблемы легко описываютсЯ сравнительно небольшим числом параметров.
     -  €звестно много методов решениЯ, что обеспечивает наличие  библиотеки
альтернатив.
     -  ’щательный анализ  привел к  выработке Явных  правил выбора  методов
решениЯ в зависимости от параметров.
     …два  ли  возможно   обобщение  таких  методов  на  весь   мир  обычных
программных  систем,  в  котором  ситуациЯ  с  такими  приЯтными  свойствами
ЯвлЯютсЯ  исключениЯми.  ’рудно  даже  представить себе,  как такой прорыв в
обобщении мог бы произойти разумным образом.
     <b>ѓрафическое программирование.</b> €злюбленной темой докторских  диссертаций
в   программной    инженерии    ЯвлЯетсЯ   графическое,   или    визуальное,
программирование - применение компьютерной графики в разработке программного
обеспечениЯ.9 €ногда перспективы такого  подхода основываютсЯ на  аналогии с
проектированием ‘Ѓ€‘, в котором компьютеры играют такую большую роль. €ногда
такой  подход  обосновываетсЯ,  исходЯ  из  того,  что  блок-схемы  ЯвлЯютсЯ
идеальным  материалом  при проектировании программ. €меютсЯ  мощные средства
длЯ созданиЯ таких блок- схем.
     Ќичего убедительного и удивительного из этих попыток пока не вышло, - и
Я уверен, не выйдет.
     ‚о-первых,  как  Я всюду доказываю,  блок-схема ЯвлЯетсЯ  весьма слабой
абстракцией структуры программы.10  ‹учше всего это видно из попыток Ѓеркса,
фон Ќеймана  и ѓольдстайна  снабдить  свой предполагаемый  компьютер  крайне
необходимым управлЯющим Языком высокого уровнЯ. ‚  том жалком виде -  многие
страницы   соединенных   линиЯми  прЯмоугольников,  -   в  котором   сегоднЯ
разрабатываютсЯ блок-схемы,  они доказали,  в сущности, свою  бесполезность:
программисты рисуют их после, а не до созданиЯ описываемых ими программ.
     ‚о-вторых,  сегоднЯшние  экраны  имеют  слишком  мало  пикселов,  чтобы
показать  целиком и с достаточным разрешением сколько-нибудь подробную схему
программы. ’ак  называемаЯ "метафора рабочего  стола"  становитсЯ  метафорой
"сиденьЯ  самолета". ‚сЯкий,  кому приходилось  листать пачку бумаг,  будучи
стиснутым  двумЯ корпулентными  соседЯми, почувствует  разницу: одновременно
можно  увидеть очень немного. ЌастоЯщий рабочий стол позволЯет  обозревать и
произвольно  выбирать множество бумаг.  Ѓолее того, в порыве  творчества  не
один программист или писатель предпочитал рабочему столу более вместительный
пол.   Ђппаратным   технологиЯм  нужно  сделать  очень  большой  наг,  чтобы
предоставлЯемый  экранами  обзор  был  достаточным длЯ задач  проектированиЯ
программ.
     …сли  обратитьсЯ  к  основам,  программное  обеспечение  очень   трудно
визуализировать,  как  Я  доказывал  это  выше.  ‘оставлЯем   ли  мы   схемы
управлЯющей логики, вложенных областей,  видимости переменных,  перекрестных
ссылок переменных, потоков данных, иерархических структур данных или чего-то
еще,  они отражают лишь одно изменение  взаимодействующих запутанным образом
частей  программной  системы.  …сли  наложить  одна  на  другую  эти  схемы,
отражающие  взглЯд  с  различных  точек  зрениЯ,  трудно  извлечь  из  этого
какую-либо  общую точку зрениЯ.  ЂналогиЯ с интегральными схемами вводит,  в
сущности,   в   заблуждение:   конструкциЯ  микросхемы  представлЯет   собой
многослойный  двумерный  объект,   геометриЯ   которого  отражает  сущность.
ЏрограммнаЯ система не ЯвлЯетсЯ таким объектом.
     <b>‚ерификациЯ  программ.</b>   Њного  труда  в  современном  программировании
тратитсЯ  на  отладку и исправление ошибок. Њожет быть, мы найдем серебрЯную
пулю,   устранив   все  ошибки  в   самом  начале,   на   этапе   системного
проектированиЯ? Њожно ли радикально повысить производительность и надежность
продукта, если следовать совершенно иной стратегии - обеспечить корректность
проекта,  прежде   чем   тратить   огромные  усилиЯ  на   его  реализацию  и
тестирование?
     Ќе думаю, что мы обнаружим здесь чудеса.  ‚ерификациЯ программ ЯвлЯетсЯ
очень  мощной концепцией, и она очень важна  длЯ  таких вещей,  как создание
надежного Ядра  операционной системы.  ќта  технологиЯ не  обещает,  однако,
экономии  труда. ‚ерификациЯ  требует столько  работы,  что  весьма немногие
значительные программы вообще были верифицированы.
     ‚ерификациЯ программ не означает созданиЯ программ,  лишенных ошибок. €
здесь нет  чудес. Њатематические  доказательства тоже могут быть ошибочными.
Џоэтому хотЯ верификациЯ может облегчить тестирование, она не может отменить
его.
     Ѓолее  существенно,  что даже  самаЯ совершеннаЯ  верификациЯ программы
может  лишь  определить,  что программа отвечает своим спецификациЯм.  ‘амаЯ
сложнаЯ   задача  программированиЯ  -  получить  полную  и  непротиворечивую
спецификацию, и сущность  созданиЯ программы на практике во многом состоит в
отладке спецификации.
     <b>‘реды программированиЯ и инструменты.</b> Љакого еще выигрыша можно ожидать
от  стремительно  расширЯющихсЯ  исследований   по  усовершенствованию  сред
программированиЯ?   €нстинктивно   кажетсЯ,  что   задачи,   которые  сулили
наибольшую отдачу, были в числе первых, за которые взЯлись, и их уже решили:
иерархические файловые системы, единообразные форматы  файлов  длЯ получениЯ
единообразных    программных   интерфейсов    и   обобщенных   инструментов.
Ћриентированные на конкретные Языки интеллектуальные редакторы пока не очень
распространены,   но   большее,   на  что  они   способны,  это   устранение
синтаксических ошибок и мелких семантических.
     ‚озможно,  наибольший  выигрыш среда  программированиЯ  сможет дать при
использовании строенных систем баз данных длЯ отслеживаниЯ мириадов деталей,
которые  каждый  программист  должен  точно  вспоминать,  и  которые  должны
хранитьсЯ в текущем состоЯнии в группе работающих над одной системой.
     Ќесомненно, что  это работа заслуживает  вниманиЯ и принесет  некоторые
плоды  как длЯ производительности, так и длЯ надежности. Ќо  ввиду самой  ее
сути отдача должна быть незначительной.
     <b>ђабочие    станции.</b>    Љакой    выигрыш   может   получить    искусство
программированиЯ от  несомненного и быстрого роста мощности  и объема памЯти
отдельной  рабочей  станции?  ‘колько  миллионов  операций  в секунду  можно
плодотворно  использовать?  ‘оставление  и  редактирование  программ  вполне
обеспечиваютсЯ  сегоднЯшними  скоростЯми. ЉомпилЯциЯ может быть ускорена, но
десЯтикратное увеличение скорости  машины, вне сомнениЯ, сделает обдумывание
основным занЯтием программиста в течение рабочего днЯ. Џожалуй, это  так уже
сейчас.
     Љонечно,  мы  приветствуем  увеличение  мощности  рабочих  станций.  Ќо
рассчитывать на свЯзанные с этим чудеса мы не можем.
     Џерспективные подходы к концептуальной сущности
     •отЯ  никакой  прорыв   в  технологии  не   обещает  таких  волшебных
результатов, какие мы  видим в  аппаратной  части компьютеров,  в  настоЯщее
времЯ делаетсЯ  много  полезного,  и  есть  надежды  на  неуклонный, хотЯ  и
неброский прогресс.
     ‚се  технологические  подходы  к акциденциЯм процесса  программированиЯ
принципиально ограничены уравнением продуктивности:

     <img src=mithsoftware_pic16.png>

     …сли, как Я полагаю, концептуальные составлЯющие задачи сейчас отнимают
большую часть  времени,  то  никакаЯ работа над  составными частЯми  задачи,
ЯвлЯющимисЯ просто выражением концепций, не даст большого выигрыша.
     Џоэтому мы должны рассмотреть  те направлениЯ, которые затрагивают саму
сущность    проблемы    программированиЯ   -   формулировку   этих   сложных
концептуальных структур.  Љ  счастью, некоторые из  этих направлений  весьма
многообещающи.
     <b>Џокупать, а  не создавать.</b> Ќаиболее  радикальное возможное решение  при
создании программ - вообще не создавать их.
     ‘  каждым днем это становитсЯ все  легче,  поскольку все большее  число
поставщиков   предлагает  все  более  многочисленные  и  лучшие  программные
продукты    длЯ    немыслимого    разнообразиЯ    приложений.    Џока    мы,
инженеры-программисты,   трудились   над    совершенствованием   методологии
производства, революциЯ, произведеннаЯ  персональными  компьютерами, создала
не один, а много массовых рынков программного обеспечениЯ. ‚ каждом газетном
киоске  выставлены ежемесЯчные журналы, в которых, отсортированные  по типам
машин,   рекламируютсЯ  и   рецензируютсЯ  десЯтки  продуктов  по  ценам  от
нескольких  долларов до  нескольких сотен долларов. Ѓолее специализированные
изданиЯ предлагают очень мощные продукты длЯ рабочих станций и других рынков
Unix.  „аже  инструменты  и среды  программированиЯ  могут  быть  куплены  в
коробочном виде. џ гд