«Микропроцессорные средства и системы», # 3 1986,c. 85

вить программу бортовой ЭВМ для автомагической проводки вездехода по этому же маршруту?

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

__________________________________________

“Совершенно естественно говорить об уме более интуитивном, когда зона комбинирования идей находится глубоко, и об уме логическом, если эта зона расположена достаточно поверхностно!"- Ж   Адамар

______________________________________

Один из ярких примеров такого сорта тупиков среди задач профессионального программирования “на заказ” приводит руководитель отдела программирования фирмы ИБМ Дж. Фоке в книге “Программное обеспечение и его разработка”:

“При попытке автоматизировать нефтеочистительные заводы фирмы “Эксон”, расположенные в Эгмонте (Канада) и в Антверпене (Бельгия) фирма ИБМ потеряла более 10 млн. долл. Выполняли работу две сотни моих хьюстонских* сотрудников. Как-то один из разработчиков спросил инженера компании “Эксан”, каким образом он узнает, когда надо включать тот или иной клапан управления потоком в трубопроводе. “Очень просто,— услышал он в ответ.—-Я опускаю палец в струю и пробую”... “Запрограммируйте это !" - саркастически заключает Фокс.

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

Предположим, что бригада занятых на “задаче о вездеходе” программистов вместо того, чтобы продолжать попытки алгоритмизовать неуловимые для непосвященных способы оценки “таежной ситуации”, разработала необходимые базовые средства: драйверы для управления исполнительными устройствами навигационной системы вездехода, связи с датчиками окружающей обстановки и т. д., например, в рамках одного из -популярных языков программирования высокого уровня и пригласила “охотника” за пульт бортовой ЭВМ, чтобы он сам попытался написать программу управления вездеходом, реализующую его собственный (неосознанный пока) “алгоритм проводки” транспортного средства к зимовью.

Предположим также, что “охотник” владеет основами “второй грамотности” н может начать работу за пультом ЭВМ, скажем, в рамках системы Бейсик. Несколько дней или недель для освоения конкретной версии языка с встроенными проблемно-ориентированными функциональными расширениями, и ... начинается процесс создания варианта программы для движения на начальном, простейшем участке трассы, а затем—долгий, изнурительный процесс отладки. Можно, видимо, в самых общих чертах представить себе, как это могло бы происходить.

“Пуск!”— машина продвинулась на несколько метров и провалилась в трясину. Подъем, буксировка вездехода на исходную точку трассы, анализ ситуации. Автор внимательно осматривает местность вокруг гусеничного следа, вплоть до того участка, где чти следы исчезают под водой, долго водит пальцами по листингу программы. “Так ... кажется, ясно. В программу была заложена неполная информация- выбор направления движения с ориентировкой на более сухой мох осуществляется лишь в пределах зоны “талой воды”. В случае, когда недавно прошел дождь, следует дополнительно учитывать также и цвет разводья и ориентироваться в движении на более “рыжие” участки, где обычно грунт оказыва-

ется плотнее”. В текст программы вносятся необходимые изменения, предварительная отладка на машинном макете — “тесткарте” местности, и снова прогрет двигатель, команда “Вперед!” На этот раз машина прошла чуть дальше, и т.д.

Необходимый   инструментарий, оценки эффективности, границы применимости...

Как и всякий чисто умозрительный, иллюстративный пример **  рассматриваемый случай одинаково уязвим со всех сторон.

“Представить себе, чтобы “человек на тайги” мог на время отложить ружье и позабавиться с пакетом игровых программ — это еще куда ни шло... но, чтобы он написал программу реального времени..?” — резонно усомнится один.

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

И, наконец, третий решительно “закроет проблему” роковым вопросом: “А Вы уверены, что управляемая такой программой машина после скажем, двух-трех удачных рейсов пройдет трассу еще хотя бы раз? В другое время суток? При другой погоде?...”

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

__________________

* Желая подчеркнуть, что суть дела не в том, достаточно ли квалификации у программиста, чтобы решать  ту или иную трудноформализуемую задачу, Фокс особо оговаривает, о  ком именно в данном примере идет  речь. Упоминаемые им “две сотни  хьюстонских сотрудников” — сотрудники отделения фирмы ИБМ, работающие по контракту с управлением космических исследований (НАСА) в научном центре Хьюстона. Это, так называемые,          “суперпрограммеры”,  многие из которых до того, как заняться “задачей о нефтеперегонном заводе”, принимали участие в создании наиболее сложных из всех известных за рубежом программистских проектов: программное обеспечение посадки человека на Луну, управление орбитальными космическими лабораториями и др.

** Конкретный пример реализации одного из вариантов технологии автоформармализации профессиональных знаний в рамках практически решаемой задачи автоматизации биотехно-логических исследований рассматривается в упомянутой выше книге: “Национальные информационные ресурсы: проблемы промышленной эксплуатации”, с. 139—143.

«Микропроцессорные средства и системы», # 3 1986,c. 85