Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы
Я предвижу, что через десятилетие, когда оценят эффективность Ada, будет признан значительный вклад этого языка, но не благодаря какой-либо отдельной его возможности и даже не благодаря им всем вместе взятым. Не станут причиной успехов и новые среды программирования на Ada. Наибольшим вкладом Ada явится то, что переход на этот язык послужит причиной изучения программистами современных методов проектирования программного обеспечения.
Объектно-ориентированное программирование. Многие, изучающие искусство программирования, связывают с объектно-ориентированным программированием больше надежд, чем с любыми другими современными техническими увлечениями. [3] Я принадлежу к их числу. Марк Шерман (Mark Sherman) из Дартмута замечает, что следует проводить отличие между двумя разными идеями, фигурирующими под этим названием: абстрактных типов данных и иерархических типов, называемых также классами. Понятие абстрактного типа данных состоит в том, что тип объекта определяется именем, множеством допустимых значений и множеством допустимых операций, а не организацией хранения, которая должна быть скрыта. Примерами являются пакеты Ada (с защищенными типами) и модули в языке Modula.
Иерархические типы, такие классы в Simula-67, позволяют определять общие интерфейсы, которые в дальнейшем можно уточнять с помощью подчиненных типов. Эти две концепции ортогональны: могут быть открытые иерархии и скрытие без иерархий. Обе концепции действительно являются достижением в искусстве программирования.
Каждая из них устраняет еще одну второстепенную сложность, позволяя разработчику выразить сущность своего проекта без использования большого количества синтаксического материала, не добавляющего нового информационного содержания. Использование как абстрактных, так и иерархических типов устраняет второстепенные трудности более высокого порядка и позволяет выразить проект на более высоком уровне.
И все же такие достижения могут не более чем устранить второстепенные трудности при выражении проекта. Существенна сложность самого проекта, на что решение таких задач никак не может повлиять. Добиться выигрыша на порядок величин с помощью объектно-ориентированного программирования можно лишь в том случае, если остающаяся сегодня в нашем языке программирования необязательная работа по спецификации типов сама по себе ответственна за 9/10 усилий, затрачиваемых на проектирование программного продукта. В этом я не сомневаюсь.
Искусственный интеллект. Многие ожидают, что успехи в области искусственного интеллекта позволят осуществить революционный переворот, который принесет рост производительности разработки программного обеспечения и его качества на порядки величин. [4] Я этого не жду. Чтобы увидеть, почему, разберем, что понимается под «искусственным интеллектом», а затем посмотрим, какие возможны применения.
Парнас внес ясность в терминологический хаос:
Сегодня в ходу два совершенно разных определения ИИ. ИИ-1: использование компьютеров для решения задач, которые раньше могли быть решены только с помощью человеческого интеллекта. ИИ-2: использование специальных приемов программирования, известных как эвристическое, или основанное на правилах, программирование. При таком подходе изучают действия экспертов, чтобы определить, какими эвристиками и практическим правилами они пользуются при решении задач… Программа корректируется для решения задач так, как, по-видимому, ее решает человек.
У первого определения скользкий смысл… Кое-что укладывается сегодня в определение ИИ-1, но как только мы видим работу программы и понимаем задачу, мы уже не думаем о ней, как о ИИ… К несчастью, я не вижу ядра методов, которые уникальны в этой области… По большей части методы проблемно-ориентированны, и для их переноса требуются известные абстракция и творчество. [5]
Я полностью согласен с этой критикой. Приемы, используемые для распознавания речи, выказывают мало сходства с методами распознавания изображений, при этом в экспертных системах используются методы, отличные от тех и других. Я затрудняюсь сказать, к примеру, какое влияние распознавание изображений может оказать на методы программирования. То же самое справедливо в отношении распознавания речи. При разработке программ трудно решить, что именно сказать, а не собственно сказать. Никакое облегчение выражения не может дать больше, чем незначительные выгоды.
Методы экспертных систем ИИ-2 заслуживают отдельного параграфа.
Экспертные системы. Наиболее развитой и широко применяемой частью искусственного интеллекта являются экспертные системы. Многие ученые в области программирования напряженно трудятся над применением этой технологии в средах разработки программного обеспечения. [5] В чем состоит идея, и каковы перспективы?
Экспертная система — это программа, содержащая обобщенный генератор выводов и базу правил, предназначенную для приема входных данных и допущений и исследования логических следствий через заключения, выводимые из базы правил, предоставляющая заключения и рекомендации и предлагающая пользователю объяснение полученных результатов путем обратного прослеживания своих рассуждений. Помимо чисто детерминированной логики, генератор выводов обычно может работать с нечеткими или вероятностными данными.
Такие системы предоставляют некоторые явные преимущества перед запрограммированными алгоритмами решения тех же задач:
• Технология генератора выводов разрабатывается независимо от применения и используется затем во многих приложениях.
• Изменяемые части специфических для приложения данных единообразно кодируются в базе правил. Обеспечивается инструментарий для разработки, изменения, проверки и документирования базы правил. Этим упорядочивается значительная часть сложности самого приложения.
Эдвард Фейгенбаум (Edward Feigenbaum) считает, что мощь таких систем растет не благодаря совершенствованию механизмов вывода, а скорее, благодаря пополнению базы знаний, все более точно отражающей реальный мир. Я считаю, что самое важное достижение этой технологии состоит в разделении сложности приложения и самой программы.
Как можно использовать экспертные системы при создании программного обеспечения? Различными способами: предложение правил интерфейсов, рекомендации по стратегии отладки, запоминание частоты ошибок каждого типа, подсказки по оптимизации и т.п.
Представим себе, к примеру, некоего советчика по отладке. В самой зачаточной форме диагностическая экспертная система весьма напоминает памятку пилота, по сути, делая предположения относительно возможных причин затруднений. По мере развития базы правил предположения становятся более специфичными, более изощренно учитывая симптомы проблемы. Можно представить такого помощника предлагающим сначала самые общие решения, но, по мере воплощения в базе правил все большей части структуры системы, становящегося все более разборчивым в генерируемых гипотезах и предлагаемых тестах. Такая экспертная система может решительно отличаться от обычных тем, что ее база правил, вероятно, должна быть иерархически разбита на модули таким же образом, как соответствующий программный продукт. Поэтому при изменении модульной структуры продукта изменяется также модульная структура базы диагностических правил.
Работа, которую необходимо проделать для создания диагностических правил, в любом случае должна быть проведена при создании набора контрольных примеров для модулей и для системы. Если это делать достаточно общим образом, с единообразной структурой правил и при наличии хорошего генератора выводов, то можно действительно сократить объем работ при генерации контрольных примеров, а также пожизненном сопровождении и тестировании модификаций. Такие же условия мы можем поставить и для других советчиков, используемых для других участников задачи создания программы. Возможно, они будут многочисленны и иногда просты.
На пути ранней реализации полезных экспертных советников для разработчика программы стоит много препятствий. Решающей частью нашего воображаемого сценария является разработка простых способов перехода от задания структуры программы к автоматическому или полуавтоматическому созданию диагностических правил. Еще более сложной и важной является двойная задача приобретения знаний: найти членораздельно выражающихся и способных к самоанализу экспертов, понимающих, почему они делают то или другое действие, и разработать эффективные методы извлечения их знаний и превращения в базы правил. Чтобы построить экспертную систему, необходимо иметь эксперта.
Наибольшим вкладом экспертных систем, несомненно, будет предоставление неопытному программисту опыта и всех знаний, накопленных лучшими программистами. И это не мало. Разрыв между лучшими и средними приемами программирования очень велик, возможно, он больше, чем в любой другой инженерной дисциплине. Поэтому средство распространения хороших приемов было бы очень важным.
