Материалы модуля «Алгоритмы ЧМВ»

Учитывая, что уровней у такой пирамиды должно быть тоже не больше семи, получаем по меньшей мере 7⁷=823 543 элемента в ее основании. Вполне достаточно... для идеальной системы. К сожалению, такой на свете нет. Однако и неидеальную систему следует разрабатывать с учетом ограниченных возможностей человеческой памяти и восприятия.

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

Более строгое требование к проекту таково: достаточно опытный пользователь должен быть в силах не только просчитать, но и написать с нуля сложный проект (т. е. быть human writeable). Вообще-то с нуля никто сложные проекты не пишет, всегда найдутся какие-то предварительные заготовки, части старых решений и т. п. Но требование это гарантирует, что в проект не надо будет вставлять избыточную или не имеющую отношения к делу информацию. Так, модный нынче язык моделирования чего угодно XML не отвечает требованию human writeable, потому что содержит множество синтаксического шума: диаграмма из прямоугольника, эллипса и кривой Безье со стрелкой на конце в формате утилиты xfig занимает 356 байт и может считаться пригодной для чтения и записи вручную (правда, после преобразования некоторых числовых параметров в строковые), а вот аналогичная диаграмма, изготовленная при помощи утилиты dia, представляет собой 4,7 Кбайт на XML (стоит отметить, что ни тот, ни другой файл, строго говоря, не являются проектами, потому что и dia, и xfig суть визуальные средства разработки).

Принцип персональной ответственности (О). Уже не раз упоминалось, что пользователь проективной системы берет на себя ответственность за качество проекта, а стало быть, и за поведение системы, собранной на основе этого проекта, и за качество получаемого продукта. Деваться ему некуда: всякий раз, создавая решение даже самой немудреной задачи, перед тем как пустить его в ход, он должен сказать самому себе: "Да, это будет работать". То же самое он должен сказать своему начальнику и всем пользователям подвластной ему системы (если он системный администратор) или даже всей сети Internet. Самая элементарная команда работы с системой предполагает, что человек сначала подумал и принял решение. То, что команда может быть плодом невежества, безалаберности или глупости человека, в расчет не берется.

Столь трепетное и уважительное отношение  к мнению человека выливается в достаточно суровое правило "захотел - получил": что бы ни творил пользователь, предполагается, что делает он это сознательно. Хочет удалить все свои файлы - что ж, значит, так надо (команда unix: rm -rf $HOME/*. ВНИМАНИЕ! Эта команда действительно сработает! Не повторять! И кстати сказать, она удаляет не все файлы, см. главу 7). Восстановить удаленные файлы нельзя: вы же их сами удалили. Или надо было воспользоваться каким-нибудь другим, безопасным способом: вместо того, чтобы удалять ненужные файлы, переместить их в специальный каталог. Если пользователь нажал одну клавишу в текстовом редакторе - это команда редактирования, а не случайность, текст меняется. В редакторе, как и в любом инструменте разработки, конечно, есть функция отмены последнего действия: человеку свойственно ошибаться. Однако человеку свойственно и обдумывать решения, поэтому достаточно предусмотреть отмену только последнего действия. Правило "захотел - получил" здорово дисциплинирует, хотя на первых порах выглядит жестоко.

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

Следствие 1. Очевидно, что основным направлением развития проективных систем будет создание все более мощных инструментариев, то есть наборов, позволяющих сравнительно быстро и эффективно строить решения задач в различных прикладных областях. Для программистов, например, это высокоуровневые библиотеки функций, специализированные модули языков программирования высокого уровня и сами эти языки. Разнообразие инструментов не нарушает принцип У: вряд ли программисту придется использовать их все сразу. Скорее всего, он, сообразуясь с профилем решаемых задач и стилем работы, подберет небольшой, но мощный подходящий инструментарий. Для разработки больших проектов, которые должны "уметь все", программист выберет высокоуровневую среду, где ему придется иметь дело с более сложными, но умопостижимыми объектами, при необходимости спускаясь на более низкий уровень. (Обычно в названии таких сред встречается слово toolkit - "инструментарий". Показательно, не правда ли?)

Следствие 2. Велосипедный парк. Некоторое количество (подчас изрядное) готовых решений придется собрать, что называется, своими руками, чтобы потом этими решениями пользоваться. И спустя какое-то время вы убедитесь, что занимались изобретением велосипеда - существуют инструменты более полные и, возможно, более удобные, чем ваш. Тут следует помнить четыре вещи. Во-первых, опыт и знание в проективной системе важнее конкретной поделки, так что ваши усилия не пропадут даром. Во-вторых, если не предвидится задач, которые ваша библиотека не решает, а чужая - решает, лучше оставить все как есть . В-третьих, когда чужая разработка объективно лучше, а задачи все прибывают, следует перейти на нее, если к тому нет формальных препятствий (лицензия, полная несовместимость и пр.). Лучше совместно совершенствовать мотоцикл, чем порознь пыхтеть над велосипедами. И в-четвертых, когда в следующий раз приметесь изобретать велосипед, оглядитесь вокруг в поисках готовых мотоциклов, то есть поищите подходящий для ваших задач инструментарий (например, на www.sourceforge.net или www.freshmeat.org).

Область применения

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

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

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

У принципа информационной открытости компьютерных человеко-машинных систем есть еще одно немаловажное следствие. Основной инструмент такой системы - программа или библиотека. Самый надежный источник информации о нем - исходный текст на языке программирования. Более того, только если программа доступна пользователю в виде исходного текста, он может находить в ней ошибки, исправлять и развивать ее. Такую программу разрабатывает и отлаживает весь мир, точнее, все сообщество квалифицированных пользователей. Только доступ к исходному тексту программы гарантирует отсутствие в ней "вредоносных" частей (см. УК РФ, статья 273 и комментарии к ней).

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

Процедура как суррогат поступка

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

Система в самом общем виде работает так: человек описывает, какой продукт  он хочет получить, а машина рассказывает, какие действия надо для этого  предпринять. Естественно, возможны варианты: часто человек не в состоянии вспомнить все свойства продукта, и машине приходится потихоньку выспрашивать их; так, например, устроен, "мастер подключения к Internet" в Windows 98 и прочие подобные ему "мастера" (wizards). Почти всегда стадия "какие действия предпринимать" этими мастерами и ограничивается: после того, как свойства продукта описаны, задачу уже можно решить, не посвящая пользователя в тонкости решения. Наконец (отличительная особенность процедурных систем!), под типовую пользовательскую задачу, скорее всего, найдется готовый вариант решения, так что пользователю останется только нажать кнопку, скажем, "форматировать текст" и наслаждаться результатом.

Существует  некое предписание, или свод правил, согласно которому человек тянет за те или иные рычаги системы и получает на выходе определенные свойства продукта. Очень часто в роли предписания выступает инструкция по эксплуатации, или так называемый troubleshoot: вещи выходят недостиранными - кладите больше порошка, при работе слышен скрежет, а на вещах заметен известковый осадок - используйте средство против накипи, не гудит и не крутится - проверьте предохранитель, не поможет - включите вилку в другую розетку, если и это не поможет - звоните в службу ремонта. Предписания, составленные по принципу "совокупность признаков - действие", назовем табличными, потому что они обычно оформляются в виде двух колонок. Табличные предписания удобны, но практически всегда недостаточны. Если существует полностью задаваемая табличным предписанием человеко-машинная система, рано или поздно она становится автоматической, потому что выполнять процедуры из таблицы вполне под силу автомату, человек для этого не нужен. Системы кондиционирования, поддерживающие постоянную температуру и влажность в помещении, не нуждаются в человеке, который, глядя на градусник, дергал бы за ручку "холодно-жарко".

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