Материалы модуля Алгоритмы ЧМВ (стр. 1 из 7)

Проективной мы будем называть человеко-машинную систему, в которой для взаимодействия с машиной человек составляет на языке инструментальной области проект, описывающий ее предполагаемое поведение. Типичная проективная система создается, например, на основе утилиты make. Для make объектами прикладной области являются файлы, а проектом - специальный файл по имени Makefile. В нем перечислены исходные объекты, целевые объекты (те, что нужны в результате), и правила изготовления целевых объектов из исходных: некоторые файлы получаются из других в результате компиляции или перекодировки, некоторые представляют собой архивы, некоторые могут просто копироваться, и т. д. По этому проекту утилита make строит дерево зависимости файлов друг от друга и выполняет указанные в проекте действия над исходными объектами, пока не получатся целевые. Если в процессе работы исходный объект изменился, при запуске make будут заново созданы только те промежуточные и целевые объекты, которые в конечном счете от него зависят. Утилита make придумана для сборки больших программных продуктов, но используют ее гораздо чаще - для автоматизации любых сложных действий над группами файлов (формирование документации, Web-страниц; планирование зависимых действий, в этом случае создаваемые файлы играют роль отметок о выполнении).

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

Место пользователя в системе

Самый простой способ взаимодействия с проективной системой - метод проб и ошибок; это просто вырожденный вариант тестирования и отладки. Специфика этого метода применительно к проективной системе в том, что без знания устройства системы, без общего понимания того, как она начнет вести себя на основании сделанного проекта, на сто проб скорее всего придется сто ошибок, и эффективность метода будет нулевой. Посему главная часть проективной системы - полная и грамотная документация. Нет документации - нет системы. Вдумчивое чтение документации может свести количество проб к одной, а количество ошибок - к нулю (звучит невероятно, однако, если пользователь достаточно опытен, часто получается именно так).

Еще один простой способ взаимодействия с системой - создание проекта по примерам. Допустим, нам надо запустить почтовый сервер (сервер - это программа, а не компьютер!), да не просто так, а чтобы он принимал электронную почту только с определенных компьютеров сети. Выбираем для этого из примеров настроек (то есть проектов) почтового сервера тот, в котором заявлена "фильтрация почты". Дальше идет цикл тестирования-отладки. Запускаем сервер. Работает! В самом деле, откуда-то принимает почту, а откуда-то - нет. Заглядываем в проект. Там - порядка дюжины каких-то секций: одна отвечает за способ доставки почты, другая - за то, где и как ее хранить и т. д., все это мы узнаем, бегло глянув в документацию. Находим секцию, отвечающую за фильтрацию почты. Читаем соответствующий раздел документации повнимательнее. Оказывается, существует черный список отправителей и черный список компьютеров. Изменяем, перезапускаем сервер. Нет, нам нужен не черный, а белый список (перечень тех, от кого следует принимать почту). Читаем документацию еще внимательнее. Там есть и белый список, но в примере его нет. Исправляем настроечный файл сообразно документации, а черные списки удаляем и снова перезапускаем сервер. Если в остальном мы были внимательны, теперь он работает как надо.

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

Часто встречаются простые задачи, для решения которых достаточно применить последовательно несколько системных утилит или составить небольшой тривиальный проект, каждая строка которого придает продукту требуемое свойство. Например, для того чтобы среди файлов каталога, содержащих слово "отчет", найти созданный позже всех, надо найти все файлы в каталоге, отобрать те, что содержат слово "отчет", отсортировать полученный список по времени создания файла и выбрать начало отсортированного списка (вот как это можно сделать из командного интерпретатора shell: ls -dt1 `grep -il отчет *` | head -1). Назовем это прямым построением проекта. Прямое построение проекта возможно, только если свойства системы, описываемые проектом, строго соответствуют свойствам получаемого продукта. Фактически мы описываем именно свойства продукта, но на языке инструментальной области. Такие микрорешения микрозадач не нуждаются в проверке и их легко написать сразу, минуя цикл тестирования-отладки. К сожалению, далеко не все задачи решаются таким способом.

Самый распространенный способ работы в проективной системе - анализ поведения существующей версии системы и изменение проекта с учетом прогноза ее поведения в будущем. Это задача весьма непростая, тем более что добиться в результате надо не только безотказной работы системы, но и того, чтобы продукт получался качественный (имея в виду, что первое - необходимое условие второго). Назовем, по аналогии с математическим термином, этот вид взаимодействия человека и машины решением обратной задачи. По описанию того, как система на некоторых входных параметрах получает неудовлетворительный результат, требуется изменить входные параметры так, чтобы результат стал удовлетворительным. Не все обратные задачи можно решить; здесь нам помогает только знание структуры самой системы и понимание принципов ее работы. Более того, в процессе тестирования-отладки это знание как раз углубляется. Безусловно, столкнувшись со сложной задачей, смысл которой не исчерпывается перечислением свойств в проекте, надо тщательно изучать документацию по тем инструментам, которые предполагается использовать в решении.

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

Однако не всегда сведущий пользователь столь добр. Как правило, он в ответ на такую просьбу иногда возмущается (значит, можно было и так догадаться), иногда говорит: "Делай так-то" (читай: вот решение, узнавай сам, почему оно таково) и только в сложных случаях объясняет. Эти отношения с системой именуют иногда satori. Вот так описывается "сатори", т. е. просветление, в философии Чань (Дзен):

"Признаки - нерациональность, постижение свойств изначальной природы, авторитетность без доказательств; позитивный результат - утверждение своего Я, экстаз, экзальтация, мгновенность, внезапность просветления; внешнее выражение - парадоксальные реакции: громоподобное молчание, оглушительные восклицания, безумный смех, сквернословие" [Из лекций проф. Г. Я. Стрельцовой, прочитанных на факультете психологии МГУ в 1996 г.].

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