Такая экспертная система может решительно отличаться от обычных тем, что её база правил, вероятно, должна быть иерархически разбита на модули таким же образом, как соответствующий программный продукт. Поэтому при изменении модульной структуры продукта изменяется также модульная структура базы диагностических правил.
Работа, которую необходимо проделать для создания диагностических правил, в любом случае должна быть проведена при создании набора контрольных примеров для модулей и для системы. Если это делать достаточно общим образом, с единообразной структурой правил и при наличии хорошего генератора выводов, то можно действительно сократить объём работ при генерации контрольных примеров, а также пожизненном сопровождении и тестировании модификаций. Такие же условия мы можем поставить и для других советчиков, используемых для других участников задачи создания программы. Возможно, они будут многочисленны и иногда просты.
На пути ранней реализации полезных экспертных советников для разработчика программы стоит много препятствий. Решающей частью нашего воображаемого сценария является разработка простых способов перехода от задания структуры программы к автоматическому или полуавтоматическому созданию диагностических правил. Ещё более сложной и важной является двойная задача приобретения знаний: найти членораздельно выражающихся и способных к самоанализу экспертов, понимающих, почему они делают то или другое действие, и разработать эффективные методы извлечения их знаний и превращения в базы правил. Чтобы построить экспертную систему, необходимо иметь эксперта.
Наибольшим вкладом экспертных систем, несомненно, будет предоставление неопытному программисту опыта и всех знаний, накопленных лучшими программистами. И это не мало. Разрыв между лучшими и средними приёмами программирования очень велик, возможно, он больше, чем в любой другой инженерной дисциплине. Поэтому средство распространения хороших приёмов было бы очень важным.
«Автоматическое» программирование.Почти 40 лет люди ждут и пишут об «автоматическом программировании» — генерации решающей задачу программы, исходя из формулировки спецификации этой задачи. Некоторые высказываются сегодня так, будто ожидают от этой технологии грядущего переворота. [84]
Парнас предполагает, что термин используется из-за эффектности, а не семантического содержания, утверждая:
Короче, автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем доступный программисту в данный момент. [85]
Он утверждает, в сущности, что в большинстве случаев нужно задать спецификацию не задачи, а метода решения.
Можно отыскать исключения. Метод создания генераторов является очень мощным и повседневно с пользой применяется в программах сортировки. Некоторые системы интегрирования дифференциальных уравнений также позволяли прямую формулировку задачи. Система производила оценку параметров, выбирала из библиотеки методы решения и генерировала программы.
У этих применений есть свойства, благоприятствующие автоматизации:
• Проблемы легко описываются сравнительно небольшим числом параметров.
• Известно много методов решения, что обеспечивает наличие библиотеки альтернатив.
• Тщательный анализ привёл к выработке явных правил выбора методов решения в зависимости от параметров.
Едва ли возможно обобщение таких методов на весь мир обычных программных систем, в котором ситуация с такими приятными свойствами являются исключениями. Трудно даже представить себе, как такой прорыв в обобщении мог бы произойти разумным образом.
Графическое программирование.
Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. [86] Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем.
Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет.
Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы. [87] Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединённых линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ.
Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобы показать целиком и с достаточным разрешением сколько-нибудь подробную схему программы. Так называемая «метафора рабочего стола» становится метафорой «сиденья самолёта». Всякий, кому приходилось листать пачку бумаг, будучи стиснутым двумя корпулентными соседями, почувствует разницу: одновременно можно увидеть очень немного. Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг. Более того, в порыве творчества не один программист или писатель предпочитал рабочему столу более вместительный пол. Аппаратным технологиям нужно сделать очень большой наг, чтобы предоставляемый экранами обзор был достаточным для задач проектирования программ.
Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрёстных ссылок переменных, потоков данных, иерархических структур данных или чего-то ещё, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.
Верификация программ.Много труда в современном программировании тратится на отладку и исправление ошибок. Может быть, мы найдём серебряную пулю, устранив все ошибки в самом начале, на этапе системного проектирования? Можно ли радикально повысить производительность и надёжность продукта, если следовать совершенно иной стратегии — обеспечить корректность проекта, прежде чем тратить огромные усилия на его реализацию и тестирование?
Не думаю, что мы обнаружим здесь чудеса. Верификация программ является очень мощной концепцией, и она очень важна для таких вещей, как создание надёжного ядра операционной системы. Эта технология не обещает, однако, экономии труда. Верификация требует столько работы, что весьма немногие значительные программы вообще были верифицированы.
Верификация программ не означает создания программ, лишённых ошибок. И здесь нет чудес. Математические доказательства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.
Более существенно, что даже самая совершенная верификация программы может лишь определить, что программа отвечает своим спецификациям.