УДК 681.3
О. В. КОНЮХОВА
O. V. KONYUHOVA
СИНТАКСИС ЯЗЫКА АНАЛИЗА ЗАДАЧ ДЛЯ СПЕЦИФИКАЦИИ ГРАФИЧЕСКОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
ИНТЕРАКТИВНЫХ КОМПЬЮТЕРНЫХ СИСТЕМ
THE TASK ANALYSIS LANGUAGE SYNTAX FOR GRAPHIC USER INTERFACE SPECIFICATION IN INTERACTIVE COMPUTER SYSTEMS
В статье приводится краткое описание методов анализа задач для спецификации графического пользовательского интерфейса интерактивных компьютерных систем, даётся обоснование выбора метода CMN-GOMS для спецификации пользовательского интерфейса с учётом требований пользователей, приводится контекстно-свободная грамматика синтаксиса языка анализа задач.
Ключевые слова: графический пользовательский интерфейс, спецификация пользовательского интерфейса, требования пользователей, анализ задач, методы анализа задач, язык анализа задач, контекстно-свободная грамматика, синтаксис языка анализа задач.
In this paper there is little description of task analysis methods for graphic user interface specification in interactive computer systems. There is justifying the choice of method CMN-GOMS as a most appropriate method to specification user interface with the requirements of users. In addition is considered task analysis language syntax and provides its context-free grammar.
Keywords and Phrases: software graphical user interface, user interface specification, users requirements, task analysis, task analysis methods, task analysis language, context-free grammar, task analysis language syntax.
ВВЕДЕНИЕ
Разработка высококачественных графических пользовательских интерфейсов (ГПИ) современных интерактивных автоматизированных систем является достаточно сложной задачей. Согласно /1/, в понятии качества пользовательского интерфейса (ПИ) выделяют два аспекта: эргономический и функциональный. В последнем случае качество ПИ определяется показателями эффективности, продуктивности и степени субъективной удовлетворенности конечного пользователя ПИ. Таким образом, современный ГПИ должен быть максимально дружественным по отношению к конечному пользователю, т. е., максимально соответствовать (на уровне визуальных компонентов, уровне диалога и уровне функционального ядра) решаемой пользователем задаче и удовлетворять требованиям пользователя. Вследствие этого, возникает необходимость в методе спецификации ГПИ программных систем (по аналогии с методом моделирования процессов предметной области - IDEF0 /2/, применяемым при разработке информационных систем), которая позволила бы разработчикам ГПИ и конечным пользователям «говорить на одном языке». Такая спецификация, с одной стороны, должна быть наглядной, лёгкой в понимании и использовании как разработчиками ГПИ, так и конечными пользователями, а также учитывать требования пользователей и особенности решаемых ими задач. Кроме того, метод спецификации ГПИ должен обеспечивать возможность трансляции (желательно автоматизированным путём) описания ГПИ в другие нотации, более подходящие для спецификации ГПИ на последующих этапах его разработки. Это, в свою очередь, требует проработки и описания языка метода спецификации ГПИ с учётом требований пользователей, используемого на ранних этапах разработки ГПИ автоматизированных систем.
Исходя из сказанного выше, наиболее подходящими для спецификации ГПИ автоматизированных систем являются методы анализа задач /3-5/, краткий аналитический обзор которых приводится ниже. Далее даётся обоснование выбора метода CMN-GOMS для описания ГПИ с учётом требований пользователей. В последней части статьи автором приводится контекстно-свободная грамматика синтаксиса языка анализа задач, используемого в методе CMN-GOMS.
1 МЕТОДЫ АНАЛИЗА ЗАДАЧ
Согласно /3/, анализ задач представляет собой процесс определения и описания алгоритма решения некоторой задачи, а также анализа ресурсов, необходимых для его успешного выполнения.
Существующие на сегодняшний день методы позволяют проанализировать задачу с различных позиций: выполнить декомпозицию задачи с учетом психологических и физиологических особенностей или требований человека, оценить временную и (или) познавательную сложность алгоритма и т. д. В соответствии с /4/, методы анализа задач можно разделить на следующие группы:
1) методы, основанные на построении иерархии целей и задач;
2) лингвистические методы, использующие грамматики;
3) методы, основанные на линейной декомпозиции задачи в терминах простейших операций человека (моторики, восприятия, мышления) с использованием физических устройств ввода-вывода информации.
1) Среди методов первой группы можно выделить: метод иерархического анализа задач (Hierarchical Task Analysis – HTA) /5, 6/, метод анализа задач с построением иерархии целей, методов, операторов и правил выбора (Card, Moran, Newell-Goals, Methods, Operators, Selection rules - CMN-GOMS) /5, 7, 8/ и теорию познавательной сложности (Cognitive Complexity Theory - CCT) /4, 5/.
Данные методы опираются на целезависимое поведение системы (человека, компьютерной системы и т. п.) при решении задачи, содержащее в себе иерархию подцелей (задач), связанных между собой планами (как в HTA), специальными операторами (как в CMN-GOMS) или продукционными правилами (как в CCT). Иерархия целей (задач) может быть представлена в графическом и текстовом видах и отражает, какие цели должны быть достигнуты или какие подзадачи должны быть выполнены для решения задачи и в каком порядке.
В целом иерархия целей (задач) позволяет естественным образом показать особенности задачи, ход ее решения, а также необходимые для этого условия и ресурсы. Каждый из методов имеет свою систему обозначений (нотацию), доступную и понятную, в той или иной степени, для конечных пользователей, которые активно задействуются на этапе изучения и анализа задач. Кроме того, на основе данных нотаций возможна разработка инструментальных средств, позволяющих автоматизировать как процесс построения иерархии целей (задач), так и дальнейшего анализа и оценки полученной декомпозиции.
При анализе задачи с позиции пользователя учитываются знания более опытного пользователя, а не пользователя – новичка, что исследователи относят к недостатку иерархических методов.
2) К лингвистическим методам отнести: метод описания грамматики в форме Бэкуса-Наура (Backus-Nauru Form – BNF) /4, 5/ и грамматику действий задачи (Task Action Grammar– TAG) /4,5/.
Само название методов говорит о том, что их основу составляют формальные грамматики. Отличительной особенностью лингвистических методов является описание алгоритма решения задачи в виде диалога между человеком и компьютерной системой на некотором языке. Структура и логика этого диалога описывается совокупностью грамматических правил, в которых терминальные символы обозначают элементарные действия пользователя (использование физических устройств ввода, действия с графическими интерактивными компонентами на экране), а нетерминальные символы – более сложные действия, состоящие из набора более простых (например, выбрать пункт меню, удалить фай и т. д.). Грамматические правила TAG включают в себя дополнительные параметры: условия, при которых возможно выполнение действия и (или) семантические пояснения выполняемого действия. И хотя изначально грамматики использовались для описания командно-ориентированных диалогов, со временем их возможности были расширены для описания диалогов, ориентированных на использование графики.
При построении диалога с помощью BNF или TAG также учитываются опыт и знания пользователей о порядке решения задачи, что позволяет в некоторой степени понять ее суть. Процесс моделирования и оценки диалога может быть достаточно легко автоматизирован на основе стандартных программных средств языкового анализа (интерпретаторов и компиляторов).
Однако, системы обозначений и BNF, и TAG являются неочевидными, а, следовательно, недостаточно удобными и понятными для конечных пользователей на этапе анализа задачи.
3) Представителем третьей группы методов анализа задач является модель уровня нажатия клавиш (Keystroke Level Model – KLM) – один из методов семейства GOMS /4, 7, 8/.
Метод KLM не предусматривает построение иерархии целей, для описания задачи использует только примитивные операторы: четыре оператора моторики пользователя, оператор мысленной подготовки пользователя к выполнению моторного действия и оператор, соответствующий обратной реакции компьютерной системы в ответ на моторное действие пользователя. За каждым оператором закреплено необходимое для его выполнения время.
Таким образом, анализ задачи заключается в описании алгоритма ее решения в виде линейной совокупности операторов KLM и общей оценке времени, необходимого для его выполнения. Данная нотация является достаточно удобной для конечных пользователей, однако, метод KLM подходит для анализа только небольших задач, решение которых может быть легко сведено к набору простых операторов. Это обстоятельство сильно ограничивает его применение.
Как видно из приведенного выше краткого обзора, каждая группа методов обладает своими характеристиками, имеет свои преимущества и недостатки.
Во введении было указано, что ранняя спецификация интерфейса пользователя, с одной стороны, должна быть максимально привязана к задаче, чтобы разработчики интерфейса могли получить более четкое представление об ее особенностях, а, следовательно, более корректно определить направления диалога для успешного ее решения. Кроме того, должна иметься возможность ее автоматизированного построения и исследования. С другой стороны, данная спецификация должна быть удобна и понятна для конечных пользователей (экспертов предметной области), чтобы они, в свою очередь, могли более адекватно излагать разработчикам свои требования к интерфейсной части компьютерной системы.
Исходя из этого, можно сделать вывод о том, что для построения подобной спецификации наиболее всего подходят методы анализа задач, основанные на построении иерархии целей или задач. Более того, по мнению автора, среди представителей методов анализа задач для этих целей больше всего соответствует метод CMN-GOMS по следующим причинам:
1) В методе HTA выполняется построение иерархии задач, связанных планами их выполнения для решения общей задачи. Однако в этом методе, в отличие от CMN-GOMS, отсутствует объективный критерий прекращения декомпозиции задачи на подзадачи. Решение о том, какую из подзадач считать базовой (не требующей дальнейшего разбиения), а какую нет, возлагается на разработчика ГПИ, т. е., учитывается его субъективная оценка. Также, поскольку нотация HTA применяется для анализа самых разных задач, а не только связанных с использованием интерактивных программных систем, то в ней не выделены операторы – примитивные действия, выполняемые пользователем с помощью физических устройств ввода информации. Это не позволяет на языке HTA наглядно описать выполнение базовых задач в виде действий конечных пользователей.
2) CCT сочетает в себе две параллельные нотации: графическую (как в CPM-GOMS /7, 8/) и текстовую в виде продукционных правил, отражающих порядок и условия достижения целей и выполнения операторов и методов. Подобно CPM-GOMS, CCT ориентирована на оценку сложности ПИ и описание его в виде операторов познания, моторики, ощущения, т. е., затрагивает психологический аспект деятельности пользователей, что не соответствует приведённым выше требованиям.
На основании системы обозначений метода CMN-GOMS автором был сформулирован синтаксис языка анализа задач, который может использоваться для текстового варианта спецификации ГПИ интерактивных программных систем. Ниже приводится контекстно-свободная грамматика языка анализа задач в форме BNF.
2 СИНТАКСИС ЯЗЫКА АНАЛИЗА ЗАДАЧ
Синтаксис конструкций языка анализа задач, представленный ниже, построена основе грамматики языка анализа задач, предложенной автором в работе /9/, но исправленный и дополненный с учётом проведённых более детальный исследований в области применения метода CMN-GOMS для описания ГПИ интерактивных автоматизированных систем. Синтаксис языка анализа задач представлен контекстно-свободной грамматикой в форме BNF /4, 5/. Необязательное присутствие некоторых синтаксических конструкций указано явно с помощью специального символа ε – «пустая строка», чтобы не путать квадратные скобки языка анализа задач со спецсимволами BNF.
Описание задачи на языке анализа задач включает в себя два раздела: раздел описания целей и раздел описания методов, причём второй раздел может отсутствовать, что представлено грамматическими правилами 1-2.
<Описание задачи> ::= <Раздел описания целей> <Раздел описания методов> | (1) |
<Раздел описания методов> ::= ε | (2) |
В свою очередь, раздел описания целей должен состоять, как минимум, из описания одной цели, а в общем случае, может включать в себя описания нескольких целей. Структуру раздела описания целей иллюстрируют грамматические правила 3 и 4.
<Раздел описания целей> ::= <Описание цели><Описания других целей> | (3) |
<Описания других целей> ::= ε | <Описание цели><Описания других целей> | (4) |
Описание цели начинается со служебного слова Цель, за которым после символа двоеточия следует название цели в виде повествовательного предложения (может содержать слова, состоящие из букв русского и латинского алфавитов), которое заканчивается символом точки с запятой. Каждое слово представляет собой идентификатор, который является терминальным символом грамматики и описывается на лексическом уровне в виде регулярного выражения. За названием цели располагается описание достижения данной цели в квадратных скобках, которые являются аналогом операторных скобок в языках программирования и служат для группировки информации. Описания цели завершается ключевыми словами Проверить_результат, за которыми следует символ точки. Структура описания одной цели представлена грамматическими правилами 5-7.
<Описание цели> ::= Цель: <Название цели>; [<Описание достижения цели>] Проверить_результат. | (5) |
<Название цели> ::= Идентификатор <Другие слова> | (6) |
<Другие слова> ::= ε | Идентификатор <Другие слова> | (7) |
Описание достижения цели состоит из описания подцелей или методов (сколько раз и в каком порядке они должны выполняться для достижения данной цели) в виде определений, принятых в языке анализа задач. Каждое определение может включать в себя указание подцели или метода, выбор между подцелями (методами), циклическое выполнение подцелей (методов). Структура описания достижения цели представлена грамматическими правилами 8-10.
<Описание достижения цели> ::= <Определение>;<Список определений> | (8) |
<Список определений> ::= ε | <Определение>;<Список определений> | (9) |
< Определение > ::= <Подцель_Метод> | <Выбор> | <Цикл> | (10) |
Указание подцели или метода начинается с соответствующего ключевого слова Цель или Метод, за которыми после двоеточия следует название цели или метода (их структура совпадает с названием цели из правила 6), что иллюстрируют грамматические правила 11-12.
<Подцель_Метод> ::= Цель: <Название цели> | Метод: <Название метода> | (11) |
<Название метода>::= Идентификатор <Другие слова> | (12) |
Конструкция выбора предполагает выбор одного из альтернативных вариантов (как минимум, из двух) действий при выполнении соответствующего условия. Семантически он похож на оператор выбора в языках программирования, например, case…of… в языке Паскаль. Конструкция выбора начинается с ключевого слова Выбор, за которым после двоеточия в квадратных скобках следует список альтернатив, включающий в себя, по крайней мере, две альтернативы. Альтернативы отделяются друг от друга символом точки с запятой. Каждая альтернатива состоит из условия, за которым после символа двоеточия может следовать либо более сложное действие – подцель или метод либо элементарное действие – операторов терминах языка анализа задач. Условие определяет возможность выбора одной из альтернатив и также может быть простым или сложным. Простое условие записывается в виде повествовательного предложения (по аналогии с названием цели), а сложное условие состоит из нескольких простых (как минимум, из двух), разделённых логическими операторами И или ИЛИ, или представляет собой отрицание условия с использованием логического оператора НЕ. Синтаксис конструкции выбора задаётся правилами 13-24.
<Выбор> ::= Выбор: [ <Альтернатива>; <Альтернатива>; <Остальные альтернативы>] | (13) |
<Остальные альтернативы>::= ε |<Альтернатива>; <Остальные альтернативы> | (14) |
<Альтернатива> ::= <Условие> : <Действие> | (15) |
<Действие> ::= <Подцель_Метод> | <Оператор> | (16) |
<Условие> ::= <Простое условие> | <Сложное условие> | (17) |
<Простое условие> ::= Идентификатор <Другие слова> | (18) |
<Сложное условие> ::= <Унарное условие> | <Бинарное условие> | (19) |
<Унарное условие> ::= НЕ (<Условие>) | (20) |
<Бинарное условие> ::= (<Условие>) <Бинарный оператор> <Правая часть бинарного условия> | (21) |
<Бинарный оператор> ::= И | ИЛИ | (22) |
<Правая часть бинарного условия> ::= (<Условие>) <Продолжение бинарного условия> | (23) |
<Продолжение бинарного условия> ::= ε | <Бинарный оператор><Правая часть бинарного условия> | (24) |
Выбор между подцелями, методами, а также между подметодами и операторами может либо контролироваться компьютерной системой, либо нет. В первом случае истинность условия может быть установлена самой системой. Во втором случае система, предоставляя различные варианты достижения цели или выполнения метода, позволяет пользователю делать выбор на основе собственных знаний, умений, навыков при работе с системой или (и) требований решаемой задачи.
Циклическая конструкция языка анализа задач семантически соответствует циклу с предусловием в языках программирования, например, while…do… в языке Паскаль, т. е., список действий (в терминах языка анализа задач) может повторяться ноль и более раз. Цикл начинается со служебного слова Цикл, за которым после символа двоеточия в квадратных скобках записывается условие выполнения цикла, а после двоеточия список целей или список методов или список операторов. Структура условия в цикле аналогична структуре условия в конструкции выбора (грамматические правила 18-24), как и структура действий (грамматическое правило 16). Действия отделяются друг от друга символом точки с запятой. Синтаксис циклической конструкции описывается грамматическими правилами 25-27.
<Цикл> ::= Цикл: [<Условие> : <Список действий>] | (25) |
<Список действий> ::= <Действие> ; <Остальные действия> | (26) |
<Остальные действия> ::= ε | <Список действий> | (27) |
Циклическое выполнение подцелей, методов и операторов также может либо контролироваться программной системой, либо нет.
Раздел описания методов должен включать в себя, по крайней мере, описание одного метода, а в общем случае – описание нескольких методов, что иллюстрируют грамматические правила 28-29.
<Раздел описания методов> ::= <Описание метода> <Описания других методов> | (28) |
<Описания других методов> ::= ε | <Описание метода><Описания других методов> | (29) |
Описание каждого метода по структуре практически совпадает с писанием цели, только начинается с ключевого слова Метод, как показано в грамматическом правиле 30.
<Описание метода> ::= Метод: <Название метода>; [<Описание выполнения метода>] Проверить_результат. | (30) |
Описание выполнения метода может включать в себя операторы, а также подметоды, конструкции выбора и цикла по аналогии с описанием достижения цели. Операторы отделяются друг от друга символом точки с запятой. Синтаксис описания выполнения метода представлен граммтическими правилами 31-32.
<Описание выполнения метода> ::= <Определение>;<Список определений> | <Оператор>;<Список операторов> | (31) |
<Список операторов> ::= ε | <Оператор>;<Список операторов> | (32) |
Набор операторов зависит от количества устройств ввода информации и класса решаемых задач. Поскольку наиболее часто используемыми устройствами взаимодействия пользователя с интерактивным программным средством являются клавиатура и мышь, то в качестве операторов выбираются действия пользователя, связазанные с использоватнием этих устройств. В операторах, связанных с использованием клавиатуры, может указываться название клавиши, которое соответствует имени кнопки на клавиатуре. Описание позиции курсора также можно представить в виде повествовательного предложения. Синтаксис операторов представлен грамматическими правилами 33-35.
<Оператор>::= Нажать_кнопку_мыши | Отпустить_кнопку_мыши | Нажать_клавишу_клавиатуры [<Название клавиши>] | Отпустить_клавишу_клавиатуры [<Название клавиши>] | Дважды_нажать_кнопку_мыши | Переместить-курсор <Позиция> | (33) |
<Название клавиши> ::= Идентификатор <Другие слова> | (34) |
<Позиция> ::= Идентификатор <Другие слова> | (35) |
При описании целей и методов необходимо учесть следующее: описание достижение цели может содержать или только цели или только методы, а описание выполнения метода – или только методы или только операторы. Это в дальнейшем облегчит описание ГПИ на языках других методов, более подходящих для спецификации ГПИ интерактивных компьютерных систем на последующих стадиях его разработки. Данное требование невозможно учесть на уровне синтаксиса языка анализа задач, однако это возможно на этапе семантического анализа спецификации ГПИ, что выходит за рамки данной статьи.
ЗАКЛЮЧЕНИЕ
Методы анализа задач наиболее удобно использовать на начальных этапах разработки ГПИ интерактивных компьютерных систем вследствие их наглядности и лёгкости в понимании и использовании. Применение метода CMN-GOMS позволяет описать процесс решения задачи с позиции пользователя (с учётом его знаний, умений, навыков) как в графическом, так и в текстовом видах, что даёт разработчику ГПИ достаточно полное представление о решаемой задаче. Это позволяет свести к минимуму ошибки ПИ, которые могут быть обнаружены на стадиях проектирования, реализации и эксплуатации ГПИ. Для контроля за правильностью описания ГПИ на этапе анализа требований к ГПИ, а также для обеспечения возможности трансляции спецификации ГПИ в другие нотации был предложен язык анализа задач, сформированный на основе нотации CMN-GOMS, описан его синтаксис в виде контекстно-свободной грамматики в форме Бэкуса-Наура. На её основе может быть разработан транслятор как составная часть подсистемы анализа требований /9/.
СПИСОК ЛИТЕРАТУРЫ
1. Волченков, Е. Стандартизация пользовательского интерфейса. [Электронный ресурс]. – Режим доступа: http://www. *****/ os/2002/ 04/037.htm.- Систем. требования: P IV; 64 Мб ОЗУ; Windows 98 и выше; SVGA 32768 и более цветов; 640×480; мышь; IE 4.0 и выше.- Загл. с экрана.- Яз. рус.
2. Методология функционального моделирования IDEF0 [Текст].- М.: Госстандарт России, 200с.
3. Task Analysis . [Электронный ресурс]. – Режим доступа: http://tlc. uwater. ca/projects/ Task_Analysis/taNotes. pdf.- Систем. требования: P IV; 64 Мб ОЗУ; Windows 98 и выше; SVGA 32768 и более цветов; 640×480; мышь; IE 4.0 и выше.- Загл. с экрана.- Яз. англ.
4. Cognitive models. [Электронный ресурс]. – Режим доступа: http://www. dis. uniroma1.it/~ catarci/HCIslides/e3-chap-12.pdf.- Систем. требования: P IV; 64 Мб ОЗУ; Windows 98 и выше; SVGA 32768 и более цветов; 640×480; мышь; IE 4.0 и выше.- Загл. с экрана.- Яз. англ.
5. User Interface Languages: a survey of existing methods [Электронный ресурс].- Режим доступа: http://www. /pub/TR-5-89.pdf.- Систем. требования: P IV; 64 Мб ОЗУ; Windows 98 и выше; SVGA 32768 и более цветов; 640×480; мышь; IE 4.0 и выше.- Загл. с экрана.- Яз. англ.
6. Stanton Neville A. Hierarchical Task Analysis: Developments, Applications and Extensions [Электронный ресурс].- Режим доступа: http://www. / pdf /reports/ HTA%Literature%Review. pdf.- Систем. требования: P IV; 64 Мб ОЗУ; Windows 98 и выше; SVGA 32768 и более цветов; 640×480; мышь; IE 4.0 и выше.- Загл. с экрана.- Яз. англ.
7. John Bonnie E., David Kieras E. The GOMS Family of User Interface Analysis Techniques: Comparison and Contrast// ACM Transactions on Computer – Human Interaction, Vol. 3, No. 4, December 1996.- P. 320-351
8. John Bonnie E., David Kieras E. Using GOMS for User Interface Design and Evaluation: Which Technique? , 1996.- P. 11-30
9. Конюхова, пользовательский интерфейс для автоматизированных систем раскроя изделий сложной формы [Текст]: дис. канд. техн. наук 05.13.06: защищена 27.06.206: утв. 13.10.2006/ Конюхова О. В.- Орёл, 200 с.
ФГБОУ ВПО «Государственный университет – учебно-научно-производственный комплекс», г. Орёл
Кандидат технических наук, доцент кафедры «Информационные системы»
Тел. (48
E-mail: *****@***ru
