Главная страница  Цифровые системы 

[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [ 81 ] [82] [83] [84] [85] [86] [87] [88] [89] [90]

Глава 11. Человексимашиини-,

Water Treatment Plant [24] Chemical Precipitation Section


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

14:18:04

105 PROCESS WATER STATE=ON ALARM=NO OVERHEAT=NO 118 WASHWATER STATE=ON ALARM=NO OVERHEAT=NO 127 REACTION VESSEL OUTPUT STATE=ON ALARM=YES OVERHEAT=NO 132 SLUDGE SILO FEED STATE=ON ALARM=NO OVERHEAT=NO SLUDGE SILO OUTPUT STATE=ON ALARM=NO OVERHEAT=YES SLUDGE FINAL OUTPUT STATE=OFF ALARM=NO OVERHEAT=NO 143 VACUUM FILTERING STATE=ON ALARM=NO OVERHEAT=NO 154 LIQUID WASTE STATE=ON ALARM=NO OVERHEAT=NO

LIQUID FILTRATION STATEON ALARM=NO OVERHEAT=NO ALKALI INLET STATE=ON ALARM=NO OVERHEAT==NO NA-SULPHIDE INLET STATE=ON ALARM=NO OVERHEAT=NO 232 POLYMER PROC.A INLET STATE=ON ALARM=NO OVERHEAT=NO 237 POLYMER PROC.B INLET STATE=OFF ALARM=NO OVERHEAT=NO 242 POLYMER PROC.C INLET STATE=ON ALARM=NO OVERHEAT=NO

PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP PUMP

REACTION VESSEL OUTPUT /127/ (m3/h) = 53 SLUDGE SILO FEED /132/ (тЗ/Ь) = 92 SLUDGE SILO OUTPUT /138/ (тЗ/И) = 74 NA-SULPHIDE INLET FLOW /226/ (m3/h) = 68

138 139

166 221 226

Input Command »

Рис. 11.9. Пример плохо структурированного экрана

Water Treatment Plant [24] Chemical Precipitation Section

14:18:04

Main reaction

PUMP 105 PROCESS WATER

PUMP 118 WASHWATER

PUMP 127 REACTION VESSEL OUTPUT

PUMP 132 SLUDGE SILO FEED

reaction

138 SLUDGE SILO OUTPUT

139 SLUDGE FINAL OUTPUT 143 VACUUM FILTERING 154 LIQUID WASTE 166 LIQUID FILTRATION

reaction

221 ALKALI INLET 226 NA-SULPHIDE INLET 232 POLYMER PROG. A INLET 237 POLYMER PROC. В INLET 242 POLYMER PROC. С INLET

Main

PUMP PUMP PUMP PUMP PUMP

Main

PUMP PUMP PUMP PUMP PUMP

Operation

Function

ALARM

Operation

Function

Operation

Function

Overheat

OK OK OK OK

Overheat ALARM

OK OK OK OK

Overheat

OK OK OK OK OK

Flow Rate

53 пЗ/h 92 гпЗ/h

Flow Rate

74 гпЗ/h

Flow Rate

fi8 m3/n


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

менны

,1МИ

Рис. 11.10. Та же информация, что и на рис. 11.9, но в структурированном

задержками первой реакцией может быть сообщение типа: "Новая уставка ""перагУР" составляет 66 °С. Расчетное время достижения уставки - 18 минут Г14-28]."

Иерархический подход к структурированию, аналогичный применяемому для цессов и их потоков информации, возможен и для команд. Нижний уровень - это команды прямого управления исполнительными устройствами, верхний - это команды, инициирующие последовательность операций для выполнения сложных процедур. Последние являются по сути пакетными {batch) или командными файлами (соттяи/г7е).

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

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

В полях, где требуется ввод алфавитно-цифрово1т информации, обычно имеют *ысл лишь несколько комбинаций. "ЗПС" и "ПРАВ" являются такими же буквенными комбинациями, как "ВКЛ" и "ВЫКЛ", но они не воспринимаются бинарным "полнительным механизмом. Возможные способы избежать бессмысленных вход-данных:

показывать правильные значения в качестве фоновой информации; (2) организовать выбор возможных значений из меню;

Выдавать сообщение, если введенные данные не поняты системой.

jht неудобен, если число возможных команд велико; он быстро приво-

* вь!з"°""" экрана избыточной статической информацией. Способ (3) мо-

"•Мал "™ зависящие от частоты ошибок. Решение (2) близко к

"йсаи предпочтительный метод при пользовании оконного интер-

пцРЩя меню. Новую величину можно либо набрать на клавиа-

авле мере, часть знаков, либо выбирать из меню с помощью клавиш

щет, курсором или мыши. Выбор подтверждается клавишей <ENTER>

.1цу"° мыши. Система может предлагать выбор по умолчанию, например

акду "РЗДыдущую, наиболее часто используемую или наиболее безопасную

снит, °лчание может быть принято системой, если пользователь явно не I его.

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



ры излишен. Зачем писать "УСТАНОВИТЬ УСТРОЙСТВО № 2=ВКЛЮ если простейший выключатель выполнит ту же функцию? Если процесс б жен и включает несколько параметров, тогда разумно использовать к "\7гтлигттлт1, \7/-т1зпт/гг"ГР!П \r„o=Rrrnm4FT-m л/ггмтттт иатуру

J рроектирование интерфейса пользователя

УСТАНОВИТЬ УСТРОЙСТВО №2=ВКЛЮЧЕН0, М0ЩН0СТЬ=грп ТАВКА=3224"

Набор команды на клавиатуре требует определенного обдумывания и мож

лнение

X .у -ть сист

[ДА/НЕТ]?" Здесь может возникнуть проблема, поскольку, когда некоторое де"

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

«нем от-

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

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

ствии.

Очень важно иметь способ немедленно остановить управляемую систему в случае аварии. В такой ситуации никто не будет терпеливо набирать на клавиатуре ПР™ санную последовательность команд. Четко обозначенная кнопка аварийного откл чения "ОТКЛ" должна быть установлена в пределах досягаемости «ператора,, правило, такие кнопки раскрашиваются красным на желтом поле. Кнопка обычно выполняется достаточно большой, чтобы можно было работать в сп ных защитных перчатках и не промахнуться. омоши. 0"

Настоятельно рекомендуется применение системы оперативной " „ной. должна вызываться всегда одной и той же клавишей, отчетливо и ясно о Современные системы предлагают проблемно-ориентированную "° g „астоя-познают текущую ситуацию - данные или программы, которые раоо щий момент, - и формируют соответствующие указания.

11.5.6. Меню

соблюдав

Принципы наглядности и последовательности, которые ациимеч*

при разработке экранов и команд, должны применяться и при орг бьС Прежде всего, структура меню должна быть такой, чтобы noj ниеМз мог в ней разобраться. Каждое меню должно идентифицироваться рнЯ. ловком), как правило, совпадающим с текстом пункта меню предыду

которого оно вызвано. тии -"З" xci"

Элементы меню должны иметь один и тот же уровень абстракц „ до.т ции, как "удалить символ", "напечатать файл" и "перегрузить сиСТ .

• пежать к одному меню. Элементы меню должны располагаться не случайно, ,уя некоторому логическому принципу. Принцип упорядочения должен быть

использовать алфавитный порядок.

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

Б идеале, число элементов меню не должно быть слишком велико. При большом де элементов на экране пользователь успевает забыть первые из них, пока он про-матривает список. Если система имеет очень много возможностей, нужно найти оп-" деленный компромисс между средним числом элементов в каждом меню и числом ровней иерархии.

Ана.чогичные функции в различных меню должны быть привязаны к тем же са-им клавишам (последовательность). Команды "ПРЕРВАТЬ" (break) и "НАЗАД" (go back) должны быть доступны из любого меню, возможно, в виде определенной комбинации клавиш. Должна быть предусмотрена возможность в любой момент времени прервать текущую работу и вернуться к меню предыдущего уровня и даже к корневому или главному меню. Должны быть исключены ситуации, когда для того, чтобы просто выйти из меню или диалога, приходится проходить через серию экранов или отвечать на дополнительные вопросы.

11.5.7. Оценка интерфейса пользователя

После реализации интерфейса пользователя необходимо проверить, удовлетворяет ли он установленным требованиям. Одно из них является абсолютно формальным - соответствует ли результат программирования проектной документации. Бо-•ие важно, однако, проверить, что интерфейс в целом - проект и его воплощение -».чогает работе технической системы и, соответственно, удалось ли достичь адек-йтности и уменьшения степени сложности с точки зрения пользователя.

редварительно должны быть сформулированы критерии оценки. Определение

товых задач является сложной, иногда весьма трудоемкой проблемой. Более того, «енбь "" соразмерны целям. Очевидно, что уровень тестирования дол-Риже" различным для очень специфической системы управления, построенной Hln!, бюджетных ограничениях, и для массового продукта с огромным потен-

ьным числом потребителей.

Рои-едчто, поскольку тестирование происходит при участии людей и енокТ суждениях и оценках, результат всегда носит заметный субъективный иекрит ° °дному покажется отличным, может раздражать другого. Следую-*°менпг.„" оценки интерфейса более или менее объективны и могут быть ре-. Дованы в общем случае.

олич Работы. Сколько времени занимает выполнение набора тестовых задач? "Ри вьш ошибок пользователей. Как много и какого сорта ошибки сделаны Суб.[ "олнении набора тестовых задач?

Ремя о(Г"° удовлетворение. Насколько пользователям нравится система? о>сран быстро типичный пользователь осваивает основные команды?

ОнГ" навыков. Насколько хорошо пользователи сохраняют свои знания, Не работают с системой в течение часа, дня или недели?

"ТвоГ"""" РР" скорости работы, количества ошибок и степени 1 ения оценку можно получить сравнительно быстро и, следовательно,



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

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

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

11.6. Графический интерфейс пользователя. Система X Window

Графический интерфейс пользователя {Graphical User Interface - GUI) широко распространен на персональных компьютерах и рабочих станциях. Независимо от не должен платформы принцип всегда один и тот же - пользователь не должен фиксировать свое внимание на действии и соответствующем объекте, как при команде "ВЫПОЛНИТЬ ПРОГРАММУ". Вместо этого действие уже неявно подразумевается объектом, потому что программа не может делать ничего другого, как выполняться, текст может только редактироваться и т. д. Объекты представлены на экране в графическом виде пиктограммами - они выбираются с помощью указательного устройства и активизируются так называемым способом "укажи-и-щелк-ни" {"Point-and-Click").

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

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

Глава 11. Человеко-машинный интерфай, П.б. Графический интерфейс пользователя. Системах Window

торном уровне и уровне правил, упрощают переход от одной программы к другой и освоение новых программ.

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

Наиболее известными типами графических интерфейсов являются User Interface Guidelines (UIG), он же "Apple Macintosh Interface", интерфейс Microsoft Windows и Common User Access (CUA) для IBM Systems Application Architecture (SAA). В сфере промышленных приложений в основном используются Open Look (AT&T), Open Windows (Sun Microsystems Inc.) и OSF/Motif Display Standard (Open Software Foundation Inc.). Последний особенно широко распространен в системах управления и сегодня может рассматриваться как стандарт де-факто для таких приложений. Этот интерфейс сочетает в себе черты, характерные как для персональных компьютеров, так и для мира мейнфреймов, обеспечивая тем самым привычную среду на различных платформах.

При использовании графического интерфейса программист может сосредоточиться на конкретном приложении, поскольку основные средства для организации окон уже включены в систему. Это команды типа "Изменить положение окна", "Изменить размер окна", "Открыть выпадающее меню", "Переместить курсор по меню и выбрать" и т. д. С точки зрения программиста, многие довольно сложные операции интерфейса можно выполнить с помощью обращения к функциям пакета GUI. Безусловно, содержание меню и само приложение пишется программистом, и именно оно есть область реального взаимодействия пользователя, ЭВМ и задачи. Системы организации окон, роде OSF/Motif или Open Look, могут улучшить качество и функциональность хоро-ю продуманных диалогов, но ничего не добавят хаотичной системе.

Работа GUI основана на идее "виртуального терминала" (раздел 9.2.3). Наиболее важным прикладным результатом является, вероятно, система X Window - сетевая оконная система, разработанная в Massachusetts Institute of Technology как метод управления расширенным графическим оконным интерфейсом. Система X Window Реализована для нескольких операционных систем.

Используя систему X Window, пользователь получает стандартный доступ к лю-°и программе, которая выдает результаты в соответствии с протоколом "X", независимо от того, на какой платформе эта программа исполняется. Х-протокол - это пол-ое описание функций, которые поддерживают вывод на экран терминала окон, Рямоугольников, линий, кругов и других объектов, связанных с графикой и текста-

и. Окно на рабочей станции может принадлежать программе, исполняемой на са-

Ои станции или другом узле сети и под другой операционной системой, но при усло-Чи, что она имеет интерфейс X Window, она может посылать информацию д.ля

Вода на экран первой станции. X Window поддерживает устройства ввода - кла-laTypy и мышь.

Собственно, система X Window - это протокол обмена сообщениями между -сервером и Х-клиентом, где сервером является станция пользователя, а клиен-




[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [ 81 ] [82] [83] [84] [85] [86] [87] [88] [89] [90]

0.0227