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

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

Проект как прообраз системы.. 2

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

Принципы построения. 4

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

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

Легенда. 9

Принципы построения. 10

Принцип ограниченной осведомленности. 10

Принцип гарантированных навыков. 10

Принцип перекрытия процедур. 10

Принцип делегирования ответственности. 11

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

Информационные потоки и права доступа. 13

Вертикальные информационные потоки. 14

Модель секретности. 14

Модель надежности. 15

Горизонтальные информационные потоки. 16

Субъект-субъектная модель. 18

Субъект-объектная модель. 18

 

Проект как прообраз системы

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

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

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

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

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

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

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

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

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

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

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

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

Принципы построения

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

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

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

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

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

Принцип умопостижимости контекста (У). Для того чтобы задача могла быть решена, необходимо создать пользователю условия, в которых ее удобно решать. В частности, когда идет поиск решения и встает вопрос о выборе инструмента, очень важно отбросить как можно больше ненужных возможностей системы. Необходимо сократить контекст поиска до объема, который пользователь может целиком удерживать в голове. Доказано, что для этого в области выбора должно быть не более семи (максимум - девяти) однотипных частей (назовем это "правилом 7+-2", см. [32]). Поэтому инструментальная область должна поддаваться членению как раз на такие семь функционально различных частей, в каждой из которых тоже имеет смысл проводить семичастное деление, и т. д. вплоть до атомарных действий.

Учитывая, что уровней у такой пирамиды должно быть тоже не больше семи, получаем по меньшей мере 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), а не на действительной его структуре. При этом даже самое незначительное изменение свойств продукта может вылиться в дублирование этих свойств на "внутреннем языке", а тогда о З и говорить не приходится.