1. Параллельное проектирование и пользовательский интерфейс

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

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

Еще один недостаток последовательного проектирования состоит в разобщенности и следующих отсюда различиях в целях у разных групп, участвующих в проекте. Конструкторы, технологи и испытатели часто преследуют взаимоисключающие цели и говорят на разных языках. В указанных, а также многих других недостатках последовательного проектирования таится его значительная медлительность, а их устранение привело бы к впечатляющему ускорению процесса проектирования оборудования. Совершенствование САПР традиционно реализовывало последовательную стратегию, ускоряло выполнение каждого из этапов на отдельном рабочем месте, и в этом были достигнуты значительные успехи.

Но кардинального эффекта удалось достичь лишь при изменении самой стратегии проектирования, обусловленной проектированием параллельным. Так, например, поданным Национального института стандартов и технологии США, объединения Thomas Group Inc. и Института исследования оборонных проблем (IDA) параллельное проектирование уменьшает затраты времени проектирования на 30-70%, снижает объемы устранения конструкционных недостатков на 65-90%, ускоряет время до выхода оборудования на рынок на 90%, повышает его качество на 200-600%.

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

Исходя из того, что два первых направления не входят в поле рассмотрения данного текста, ограничимся лишь указанием на сходство данных изменений на то, чем более двадцати лет занималась в отечественной традиции научная школа Г.П. Щедровицкого. Многие подходы и проблемы параллельного проектирования удивительным образом напоминают метод организационно-деятельностного проектирования. Что же касается программных средств и, в частности, их пользовательского интерфейса, выделим следующее.

1. Поскольку исчезает разделение во времени этапов эскизного проекта и разработки технологии, возникает необходимость почти с самого начала работ воссоздать внешний и внутренний облик проектируемого изделия. Этому способствуют средства компьютерного моделирования и графики.

2. Внешний вид или, другими словами, "виртуальный макет изделия в состоянии отражать большинство его свойств. Кроме того, программное средство может вести продуктивный диалог с заказчиком, конкретизировать и фиксировать его запросы.

3. Тот же виртуальный макет позволяет сократить число неоднозначностей во взаимодействии конструкторов и технологов, быстрее находить и устранять противоречия в их подходах к изделию.

4. Параллельная работа разных специалистов над изделием находит отражение в единых для всей группы базе данных и базе знаний. Создается своего рода общий справочник разработчиков, куда автоматически заносятся все нововведения и выводы, полученные каждым из членов группы в ходе работы. Это создает новый уровень "прозрачности" средств проектирования.

5. Параллельная работа разных специалистов ведет к объединению разных инструментальных программных средств, например, САПР и Средств Автоматизации Экономической Оценки. По данным, уже практически объединены ИС электрического проектирования, проектирования программного обеспечения, заказных экспериментальных средств, проектирования электронных блоков и плат и подготовки технической документации.

6. Проблема пользовательского интерфейса, отображающего данные, активно трансформируется в проблему интерфейса, отображающего знания.

7. Использование общей системы специалистами не только разного профиля, но и разного уровня компьютерной подготовки диктует новые требования к гибкости и адаптивности пользовательского интерфейса. В частности, это касается взаимозаменяемости разных типов представления объекта и режимов ведения диалога с пользователем.

8. Новые требования предъявляются к разнообразию видов помощи пользователю со стороны компьютера, что уже само по себе должно усиливать интеллектуальную составляющую инструментальных средств. Должна варьироваться и активность системы в ведении диалога.

Мы коснемся каждого из выделенных направлений совершенствования ИС, начав с общих перспектив пользовательского интерфейса. Компьютерный пользовательский интерфейс находится в ряду устройств, опосредствующих представление информации человеку. К этому же ряду относятся лицевые панели радиоэлектронного оборудования, мнемосхемы АЭС, разнообразные табло в залах управления технологическими процессами. Все они предоставляют человеку ИНФОРМАЦИОННЫЕ МОДЕЛИ о контролируемых процессах.

Информационная модель (ИМ) есть организованная в соответствии с определенной системой правил совокупность информации о состоянии и функционировании объекта управления и внешней среды.

Имеется ряд общих требований к ИМ, разработанных и успешно применяемых эргономистами:

А. Требование к содержанию - ИМ должны адекватно отображать объекты управления, рабочие процессы, окружающую среду и состояние самой системы управления.

Б. Требование к количеству информации - ИМ должны обеспечивать оптимальный информационный баланс и не приводить к таким нежелательным явлениям, как дефицит или излишек информации.

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

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

Позднее Бен Шнейдерман сформулировал несколько принципов прямого манипулирования при работе современного интерфейса:

1) по его мнению, настало время, когда стоит опосредованное данными представление об объекте проектирования дополнить его постоянным визуальным представлением;

2) сложный синтаксис при ведении диалога следует заменить очевидными физическими действиями, осуществляемыми с помощью курсора, устройства "мышь", джойстика и других периферийных устройств;

3) следует добиваться обратимости действий и очевидности их воздействия на объект;

4) разницу в компьютерной подготовке пользователя можно компенсировать упрощением начальных действий с ИС и постепенным ознакомлением пользователя с более сложными манипуляциями.

Принципы прямого манипулирования оказались весьма ценными и сориентировали разработчиков интерфейсов в направлении предметной представленности компьютерных процессов и средств. Указанные принципы привели к появлению понятия "метафора отображения" или "экранная метафора", фиксирующего появление на экране терминала целостных, логически законченных ситуаций деятельности пользователя. Например, в работе [4] указывается на три наиболее часто встречающихся метафоры: "письменный стол", "рабочий кабинет" и "чертежная доска". Естественно, это далеко не полный перечень метафор. Фактически, почти любая ситуация в деятельности пользователя может быть предметно отражена на экране дисплея. Так, Дж. Новеллино сообщает о пакете программ Viewdac, позволяющем строить метафору, моделирующую панель управления. В виртуальной панели можно модифицировать "клавиатуру", даже не прерывая при этом ход вычислительного процесса.

Все метафоры достаточно предметны, взаимодействие с ними приводит к очевидным последствиям. Кнопки виртуальной панели "нажимаются", как, например, в инструментальном блоке Toolbar [6], а документы перемещаются по рабочему столу, как в интерфейсах фирмы Apple.

Разработчики интерфейсов стремятся к отображению реального мира, а в некоторых случаях предлагают интерфейсы, которые превосходят возможности реальности. Сказанное можно отнести прежде всего к воспроизведению и моделированию процесса во времени. Это как раз тот случай, когда возможности компьютера в моделировании превосходят возможности моделирования реального. Поясним на примере. Компания Internalional/Microcircuits сообщила о создании комплекса ИС (РС-Easy-Gate) для разработки программного обеспечения, позволяющего отображать прямое и обратное сканирование функционирования программ с целью поиска ошибок и просчетов.

Интерфейсы более богатые, чем реальность, появляются и в случае так называемого комплексного представления информации, когда интегрируется компьютерное и видеоизображение, а также производится озвучивание интерфейса. Так, система Super Video Windows воспроизводит изображение с движением и стереозвуком с камеры, кассетного видеоплеера, видеодисков, кабельного телевидения в окне любого размера и в заданной области экрана. Расширились и возможности манипулирования этой информацией. В частности, указанная система позволяет реализовать следующие функции: масштабирование изображения, его обрезку в любом месте, детализацию, панорамирование, фиксацию, графическое и текстовое наложение на экран. Однако, такое богатство функций может не только не понадобиться пользователю, но в некоторых случаях и затруднять его деятельность. Такая мысль вполне традиционна и сопоставима с классическими инженерно-психологическими требованиями к информационным моделям. Отображаться должны лишь те свойства, которые принимают самое непосредственное участие в деятельности пользователя. Здесь нужна мера, ибо абстрактная модель бесплотна, а слишком детальная вводит в заблуждение.

Сказанное нашло отражение в этапах проектирования пользовательского интерфейса, предложенных в:

а) анализ предметной области и построение ее концептуальной модели;

б) выделение из этой модели той части, которая должна быть доступна пользователю, и на ее основе построение модели прикладного интерфейса;

в) для сложных моделей, имеющих фрагменты с регулярной структурой, выбор языка взаимодействия, позволяющего эффективно строить команды-предложения и передавать их в систему;

г) построение объектно-ориентированного интерфейса, включающего описание его поведения, визуализацию и конфигурацию полей и окон.

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

1) графический интерфейс для управления аппаратурой дисплея;

2) инструментальные средства (toolkits) для построения стандартных компонентов интерфейса, которые называют кубиками (widgets);

3) сам набор кубиков;

4) программа интерфейса высокого уровня для процедур с операционной средой.

Ясно, что указанные четыре слоя позволяют пользователю видоизменять интерфейс в широких пределах, менять цвет, шрифт, форматы. Но может ли конечный пользователь при этом отчетливо представлять себе все выгоды и недостатки той или иной конфигурации интерфейса? Кажется, не может. Эта область формализована еще недостаточно. Поэтому пятым слоем архитектуры интерфейса имеет шанс стать экспертная система, разработанная на основе опыта построения пользовательских интерфейсов. Отрадно, что сообщение об экспертной системе такого рода, содержащей пока 200 правил, появилось в отечественной периодике. Есть данные и о создании более ограниченных инструментальных средств, в частности, в области проектирования диалогового режима типа меню.

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

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

2. МИКРОУРОВЕНЬ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

В уже упомянутой книге Р. Уаттса [13] указаны шесть режимов ведения диалога с пользователем:

1) выбор из меню;

2) вопрос-ответ;

3) ответы с указанием и заполнение бланков;

4) язык команд;

5) естественный язык;

6) запрос с позиционным выбором.

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

Если инициативу принимает на себя система, ограничивая синтаксис ответа пользователя, то такой режим "вслед за" можно назвать ЗАПРОСНО-ОТВЕТНЫМ. Его вариантами являются выбор из меню, запрос с позиционным выбором, вопрос-ответ, заполнение бланков и ответы с указанием.

Если инициатива отдается пользователю и он более свободен в построении высказываний на некотором командном языке, то такой режим можно назвать ДИРЕКТИВНЫМ. Примерами директивного режима являются язык команд и диалог на естественном языке.

Естественно, что процесс работы с системой часто бывает неоднородным в том смысле, что задача пользователя может изменяться от начала к концу диалога. Это означает, что инициатива может и должна переходить "из рук в руки". Такой диалог проектируется из частей как запросно-ответного, так и директивного режимов и называется СМЕШАННЫМ.

Многие разработчики программного обеспечения не видят важности правильного выбора режима диалога, ограничиваясь созданием одного режима, чаще всего ВЫБОРА ИЗ МЕНЮ. Именно этот режим часто ассоциируется в их сознании с диалогом. Между тем, задача выбора режима диалога не так элементарна и прямо коррелирует с вероятным объемом тиражирования созданной программы.

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

По уровню сложности встречаются МЕНЮ трех типов: ПРОСТОЕ, МНОГОУРОВНЕВОЕ и СЕТЕВОЕ.

ПРОСТОЕ МЕНЮ - это список пунктов, с каждым из которых связана определенная операция. Попытка использовать простое меню для организации выбора из более чем 5-9 объектов ведет сначала к психологическим сложностям (так как теряется его основное свойство - простота и наглядность), а затем и к переполнению экрана.

Поэтому в диалоговых системах часто используется МНОГОУРОВНЕВОЕ МЕНЮ с древовидной структурой. При этом вершинами "дерева" служат простые меню, а переход к его ветвям реализуется выбором одного из пунктов простого меню. Построение многоуровневых меню прямо связано с проблемой "прозрачности" системы для пользователя. Дело в том, что в многоуровневом меню можно просто "заблудиться". Поэтому наиболее совершенные системы содержат режим подсказки, в котором пользователю демонстрируется полная карта (ДЕНДРОГРАММА) меню и место пользователя на ней в данный момент. В главе 1 мы уже писали об этом подходе, различающем интерфейсы локального и глобального контекстов.

Еще одна проблема состоит в выборе уровня жесткости дендрограммы. Основной вопрос данной проблемы формулируется следующим образом: "Всегда ли, чтобы достичь определенного пункта меню, пользователь должен совершать одинаковую последовательность выборов? И если нет, то не может ли он с помощью какой-нибудь процедуры очутиться сразу в требуемой вершине?" Эта проблема нашла положительное решение посредством дополнительного режима директивного попадания в требуемую вершину многоуровневого меню.

Третий тип МЕНЮ - СЕТЕВОЕ - являет собой развитие многоуровневого меню, когда ветви дерева пересекаются и образуется дендрограмма, позволяющая делать циклический обход меню по разным маршрутам. Сетевая структура меню открывает перед разработчиками интерфейса и пользователями новые возможности. В частности, такое меню позволяет выйти за рамки чисто навигационных задач. С его помощью могут быть реализованы справочные и обучающие системы, построенные на принципах гипертекста. В этом случае каждое простое меню, представленное в виде фрагмента гипертекста, содержит ключевые слова, каждое из которых является выходом в другое простое меню. Это новый уровень предъявления справочного текста, на котором пользователь в зависимости от собственных потребностей и знаний может самостоятельно строить стратегию ознакомления со справочным или учебным материалом. Конечно, при этом возникают и новые проблемы. В частности, по сравнению с обычным постраничным строением справочного текста, пользователю сложнее строить его целостный образ. Однако, эта проблема также может быть решена на основе более развитой дендрограммы гипертекста. На ней должно демонстрироваться не только актуальное положение пользователя на карте меню, но и прочерченная в данном сеансе траектория перемещений. Быть может, необходима также и библиотека всех перемещений пользователя в каждом сеансе работы с системой. Кроме этого, нужна и суммарная карта, демонстрирующая все те вершины и ветви, с которыми пользователь уже ознакомился, и те, где ему еще не удалось побывать. В сетевом меню преодолевается его подчиненная, служебная функция, оно само становится ценным инструментальным средством, выполняющим самостоятельные задачи.

Тем более это касается ситуаций, возникающих в связи с параллельным проектированием. Ведь объединение инструментальных программных средств из разных этапов создания новых изделий объективно ведет к значительному увеличению числа разнообразных режимов, файлов, разделов информационно-поисковой системы. Дендрограмма меню может оказаться очень сложной, если не сказать запутанной - с петлями и тупиками. Очевидно, что она будет нуждаться в дополнении богатыми режимами подсказки и помощи. Просто отображения дендрограммы меню недостаточно. Всегда считалось, что уже сама по себе визуализация процесса может помочь его пониманию. Но вот на основании данных из [16] можно сказать, что схемное описание объекта значительной сложности также начинает не срабатывать, если задача пользователя состоит в том, чтобы определить проблемы, содержащиеся в схеме. Интерфейс сам должен отображать, хотя бы выделять цветом, те части схемы, в которых есть какое-либо отличие от стандартного протекания процесса. Нечто подобное происходит в современных системах упаковки информации на гибких дисках, когда отображается процесс перераспределения файлов, задержек в исполнении процесса, выявления дефектных участков диска. Более сложный вариант отображения такого же типа реализован в инструментальном средстве TeamWork/SIM компании Garde Technologies Inc. В целом данную процедуру можно отнести и к САПР. Одна из ее функций - отображение модели программных процессов на модель тех или иных аппаратных реализаций. Представление пользователю учитывает "состязание" аппаратных ресурсов, что позволяет выявлять, какие части проектируемого оборудования будут функционировать медленнее из-за неудачного выбора аппаратных средств. В дендрограмме меню может, например, демонстрироваться кратчайший путь к тому или иному пункту или те замедления в поиске, которыми грозит уже избранная пользователем стратегия поиска.

Очерченные проблемы режима выбора из меню во многом характерны для всех запросно-ответных диалогов. Новый пласт проблем открывается в тот момент, когда пользователь от задач навигационного типа переходит к выполнению расчетных задач, вводу числовых или каких-либо иных данных. Прежде всего это касается РЕЖИМА ОТВЕТОВ С УКАЗАНИЕМ и ЗАПОЛНЕНИЕМ БЛАНКОВ, а также ЗАПРОСОВ по ОБРАЗЦУ с ПОЗИЦИОННЫМ ВЫБОРОМ. Часто такого рода диалог используется в базах данных или тогда, когда информация может быть отображена в виде таблицы или электронного бланка. Конечно, такой диалог требует от пользователя больше знаний и умений, чем выбор из меню. И инициатива здесь в большей степени распределена между ним и компьютером. Помощь пользователю при работе с бланками и таблицами относится прежде всего к индикации места, куда должна быть введена информация, и мест, где отобразятся последствия от ее введения. В том случае, когда ввод должен быть осуществлен в несколько мест, отображению подлежит также нормативная последовательность введения информации. Размеры современных бланков и таблиц могут быть очень значительными, не входить целиком на экран дисплея. Поэтому важным является также манипулирование масштабом бланка, его сворачивание и растяжение, детализация, а также построение новых бланков. В настоящее время широкое распространение получили так называемые крупноформатные электронные таблицы (КЭТ). Самыми популярными считаются Excel 4.0 - пакет фирмы Microsoft [6] и пакет Lotus 1-2-3 фирмы Lotus Development [18]. Расчеты с помощью этих пакетов помимо числовых значений поддерживаются хорошими визуализациями результатов. Например, Lotus 1-2-3 позволяет получить шесть видов графических изображений результатов расчета: линии; столбцы, расположенные рядом друг с другом; столбцы друг на друге; двухкоординатные графики; круги с заштрихованными и съемными секторами.

При работе с самой КЭТ пакет Lotus 1-2-3 предоставляет ряд новых функций. Прежде всего это:

а) сокращение длины алгоритма ввода; там, где в прежних версиях требовалось несколько шагов, достаточно одного "нажатия" на виртуальной панели управления;

б) пользователю не только показывают место, в котором будет зафиксирован результат вычисления, но он сам может его выбрать с помощью процедуры autosum;

в) реализованы сжатие и растяжка КЭТ, что позволяет их рассматривать с разной степенью детализации;

г) могут быть объединены данные из разных КЭТ.

Отдельную своеобразную сферу диалоговых режимов представляют ЯЗЫК КОМАНД и ДИАЛОГ на ЕСТЕСТВЕННОМ ЯЗЫКЕ. Трудности в развитии этих режимов - по большей части психолингвистического свойства. Можно сказать, что два названных режима представляют собой своего рода полюса шкалы, при движении по которой в направлении естественного языка растет интеллектуальная составляющая пользовательского интерфейса. При этом растет также и доля программно-аппаратных ресурсов, уходящих на поддержку интерфейса. Что растет не очень значительно, так это - эффективность самого диалога. На полюсе диалога на естественном языке интерфейс превращается в своего рода игрушку, "пожирающую" массу ресурсов, но все же дающую пользователю ограниченные преимущества. Те же цели могут достигаться гораздо меньшими ресурсами. Поэтому в последнее время раздаются голоса, негативно оценивающие перспективы широкого распространения диалога на естественном языке. Перспективы же языка команд более многообещающи. На описанной шкале можно определить благоприятный отрезок, внутри которого может быть обеспечена как компактность, легкость и логичность языка команд, так и минимум интеллектуального инструментария, обеспечивающего употребление синонимов и других естественных для пользователя свойств языка диалога.

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