Содержание к диссертации
)
і (
Введение к работе
1 Анализ методов и инструментальных средств разработки графического пользовательского интерфейса для автоматизированных систем раскроя швейных изделий 10
Анализ требований к графическому пользовательскому интерфейсу автоматизированных систем раскроя швейных изделий 10
Методы анализа требований к графическому пользовательскому интерфейсу автоматизированных систем раскроя 22
Языки спецификаций графического пользовательского интерфейса для автоматизированных систем раскроя 30
Унифицированный язык моделирования UML 30
Нотация действий пользователя UAN 3 5
Нотация взаимодействующих последовательных процессов Хоара 3 8
1.4 Анализ систем управления интерфейсом пользователя для автоматизи- I,: рованных систем раскроя 43
1.4.1 Классификация инструментальных средств разработки пользователь ского интерфейса 43
1.4.2 Модели систем управления интерфейсом пользователя 46 | 1.4.2.1 Модели, лежащие в основе пользовательского интерфейса 46
1.4.2.2 Фазы диалога, реализованные системой управления интерфейсом пользователя 50 7' 1.4.2.3 Модель системы управления интерфейсом пользователя, основан ная на знаниях 52
1.4.3 Модель системы управления интерфейсом пользователя для разра ботки пользовательского интерфейса для графических редакторов 54
1.5 Выводы по первой главе -. >j. 2 Система разработки графического пользовательского интерфейса для 1 автоматизированных систем раскроя швейных изделий 58
Требования к инструментальной системе разработки графического пользовательского интерфейса для автоматизированных систем раскроя швейных изделий 58
Оценка качества графического пользовательского интерфейса для автоматизированных систем раскроя швейных изделий 61
Структура системы разработки графического интерфейса пользователя для автоматизированных систем раскроя швейных изделий 63
Система анализа требований 71
2.4.1 Синтаксис языка анализа задач 71 \ 2А2 Семантические правила перехода 76 ) 2.5 Система проектирования графического пользовательского интерфейса 79 ) 2.5.1 Синтаксис языка спецификации графического пользовательского ин терфейса 79
2.5.2 Семантика язык спецификации графического пользовательского ин терфейса 84
Система управления графическим пользовательским интерфейсом 88
Методика проектирования графического пользовательского интерфейса 90
Выводы по второй главе 2
3 Реализация инструментальных средств разработки графического пользо вательского интерфейса 94
3.1 Разработка транслятора с языка анализа задач 94
Лексические конструкции языка анализа задач 95
Синтаксические конструкции языка анализа задач 96
Промежуточное представление 97
3.2 Трансляция с языка действий пользователя на язык взаимодействую щих последовательных процессов Хоара 101
Структура добавляемой в абстрактное синтаксическое дерево информации для получения описания графического пользовательского интерфейса на языке действий пользователя 101
Структуры данных для хранения информации о процессах и событиях 102
3.3 Реализация исполняющей системы (системы времени прогона) 106
Реализация взаимодействующих последовательных процессов в виде функций расширенного лямбда-исчисления 106
Абстрактная SECD-машина 113
3.4 Выводы по третьей главе 11 _
4. Разработка графического пользовательского интерфейса автоматизиро ванной системы раскладки лекал швейных изделий 116
Построение дерева целей для раскладки лекал в автоматизированной системе раскладки лекал "Конструктор" 116
Описание задач на языке действий пользователя 127
4.3 Оценка эффективности разработки графического пользовательского интерфейса 137
Направления дальнейших исследований 143
Выводы по четвертой главе . ..
Основные результаты и выводы
Литература
Приложение А - Регулярные выражения, описывающие лексику языка спецификации требований, для генератора Lex 157
Приложение Б - Контекстно- свободная грамматика, описывающая син таксис языка спецификации требований, для генератора Yacc 158 Приложение В - Документация по внедрению результатов диссертацион ного исследования 168
4 Введение
Жесткая конкуренция на рынке машиностроительной продукции предопределяет необходимость постоянного совершенствования и развития производства любого предприятия, являющегося участником рынка.
Для обеспечения конкурентоспособности промышленные предприятия должны быстро реагировать на постоянно изменяющиеся потребности рынка. Процесс изготовления изделий сложной формы отличается высокой трудоемкостью как на стадии производства, так и на стадии подготовки изделий к раскрою. Внедрение и применение на начальных этапах производственного процесса автоматизированных систем раскроя изделий сложной формы снижает затраты на их производство, уменьшает сроки проектирования изделий, а, следовательно, позволяет быстро адаптировать их под запросы потребителей. Автоматизированная система раскроя охватывает процессы обработки изделия от создания модели до получения кроя.
Наиболее трудоемким в данной системе является процесс укладки лекал, что особенно характерно для лекал сложной конфигурации, определяющих детали изделий сложной формы. Укладка лекал осуществляется автоматизированной системой раскладки (АСР), которая позволяет расположить лекала изделия на материале.
Технологические условия укладки лекал сложной конфигурации в АСР определяются раскладчиком в интерактивном режиме. Успешное применение и функционирование АСР лекал сложной конфигурации во многом зависит от восприятия ее пользователями. Неудобства работы пользователей с АСР, связанные со сбоями в ее поведении в ответ на их действия, а также с различиями в представлениях о выполняемой задаче, делают такую АСР нежизнеспособной.
Одним из важнейших компонентов АСР лекал сложной конфигурации как интерактивной системы является графический интерфейс, качество которого определяет мнение пользователя о системе в целом и влияет на принятие решения об использовании АСР.
5 Автоматизированные системы раскроя в целом, и АСР лекал в частности, носят прикладной характер. Поэтому исследование проблем ГПИ, разработка подходов к проектированию высококачественных ГПИ, обоснование полученных результатов будет показано на примере подготовки к раскрою швейных изделий. Предприятия швейной промышленности тесно связаны с потребностями рынка, а сами швейные изделия являются наглядными представителями изделий сложной формы.
Как отмечается в работах /6, II сложность разработки высококачественных ГПИ заключается в том, что, с одной стороны, ГПИ должен удовлетворять требованиям конечных пользователей (быть простым в изучении и легким в использовании), с другой стороны, ГПИ является сложной многозадачной системой, которую трудно проектировать и отлаживать.
Проведенные исследования в области разработки ПИ позволили установить следующее:
Разработка высококачественного ГПИ является сложной задачей: половина всего затраченного на создание компьютерной системы отводится на разработку ГПИ.
Применение формальных спецификаций позволяет повысить качество ГПИ.
ГПИ должен удовлетворять требованиям конечных пользователей.
Для снижения затрат, связанных с проектированием ГПИ, необходимы специальные инструментальные средства быстрого прототипирования ПИ, использующие язык формальных спецификаций.
Основные концепции по применению инструментальных средств разработки ПИ изложены в работах Б. Майерса /12, 15, 38/, Д. Касика /40/, С. Хадсона /43/, П. Таннера и В. Бакстона /51/, Е. Эдмондса и Е. МакДейда /52/; по применению методов разработки ПИ - в работах Дж. Бонни и Д. Киераса /18,19/, Д. Карра /28/, Александера /31/, АЛ. Гордиенко /7, 20,42, 102/ и других авторов.
На данный момент не существует общепринятых методов и инструментальных средств разработки ГПИ на основе требований пользователей и особенностей предметной области, использующих языки формальных спецификаций, что определяет актуальность темы диссертационного исследования.
Объект исследования - автоматизированная система раскладки (АСР) лекал сложной конфигурации (на примере швейных изделий).
Предмет исследования - методы и инструментальные средства проектирования ГПИ для АСР лекал сложной конфигурации.
Цель диссертационной работы - повышение эффективности использования АСР лекал сложной конфигурации за счет применения инструментальных средств и методики проектирования ГПИ.
Для достижения вышеуказанной цели требуется решить следующие частные задачи:
Исследовать методы и инструментальные средства разработки ГПИ для решения задачи проектирования высококачественного ГПИ для АСР лекал сложной конфигурации.
Разработать методику проектирования ГПИ для АСР лекал сложной конфигурации, позволяющую на основе требований пользователей и особенностей прикладной задачи построить программную модель ГПИ.
Разработать инструментальную систему проектирования ГПИ для АСР лекал сложной конфигурации.
Провести экспериментальные исследования по применению методики и инструментальной системы проектирования ГПИ для АСР лекал сложной конфигурации (на примере АСР лекал швейных изделий).
Научная новизна работы.
1) Разработана комплексная методика проектирования ГПИ для АСР лекал сложной конфигурации, основанная на последовательном применении метода анализа задач CMN-GOMS, нотации действий пользователя, языка взаимодействующих последовательных процессов Хоара, объединяющая их путем трансляции с языка анализа задач на язык действий пользователя и с
7 языка действий пользователя на язык последовательных взаимодействующих последовательных процессов.
На основе созданной автором методики разработана программная модель ГПИ для раскладки лекал швейных изделий, базирующаяся на алгебре взаимодействующих последовательных процессов Хоара, реализующая необходимый набор функций для решения задачи раскладки лекал, независящая от аппаратных и программных средств реализации АСР.
Разработана на базе созданной автором методики инструментальная система проектирования ГПИ для АСР лекал сложной конфигурации, позволяющая сформулировать спецификации ГПИ на языке анализа задач, на языке действий пользователя с последующим получением программной модели, осуществить ее реализацию и отладку (на примере программной модели ГПИ для раскладки лекал швейных изделий).
Предложены язык анализа задач и язык действий пользователя, с разработанными для них синтаксисом и семантикой.
Практическая ценность работы.
Разработанные методика проектирования ГПИ и программная модель ГПИ для раскладки лекал, позволяют строить и формально анализировать логику поведения человеко-машинного взаимодействия.
Инструментальная система проектирования ГПИ АСР позволяет получить спецификацию требований пользователей, реализовать методику проектирования ГПИ, формализованную модель и произвести ее отладку с целью получения высококачественного программного продукта.
Использование результатов диссертационного исследования для раскладки лекал швейных изделий позволило снизить затраты на проектирование моделей изделий на 15-19%, что подтверждается соответствующими актами о внедрении.
Положения, выносимые на защиту.
1) Методика проектирования ГПИ для АСР лекал сложной конфигурации с учетом требований пользователей и особенностей прикладной задачи,
8 включающая три этапа: анализ требований, анализ задач и построение программной модели ГПИ.
Программная модель ГПИ для раскладки лекал швейных изделий, имеющая оптимальный набор задач, достаточный для реализации всех необходимых функций при раскладке лекал, логика диалога которой сводится к формальному описанию на языке алгебры процессов Хоара.
Инструментальная система проектирования ГПИ для АСР лекал сложной конфигурации, реализующая методику проектирования ГПИ и программную модель ГПИ для раскладки лекал (на примере швейных изделий).
Языки анализа задач и действий пользователя с разработанными синтаксисом и семантикой для спецификаций ГПИ.
Апробация работы.
Основные положения и результаты работы были представлены на следующих научных конференциях: Международная научно- техническая конференция «Информационные технологии в науке, образовании и производстве» (ИТНОП), Орел (2004 г.); Межвузовская научно-практическая конференция, посвященная 25-летию Камского государственного политехнического института «ВУЗОВСКАЯ НАУКА -РОССИИ», Набережные Челны (2005 г.); Международная научно-практическая Интернет- конференция «НАУЧЫЕ ИССЛЕДОВАНИЯ И ИХ ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ», Одесса (2005 г.).
Исследование проводилось в рамках гранта Российского Фонда фундаментальных исследований (РФФИ) «Разработка формальных методов проектирования графического пользовательского интерфейса в форме иерархии интеракторов», №05-01-96404.
По результатам исследований опубликовано 8 работ.
Получено авторское свидетельство об официальной регистрации программы для ЭВМ «Подсистема моделирования логики диалога пользовательского интерфейса, использующая язык формальной спецификации взаимодействующих последовательных процессов Хоара».
9 Реализация и внедрение результатов работы.
Результаты диссертационного исследования используются в учебном процессе кафедры «Информационные системы» Орловского государственного технического университета и при проектировании моделей швейных изделий в акционерном обществе «Радуга» г.Орла.
Публикации.
По теме диссертации опубликовано 7 статей.
Структура и объем работы.
Диссертационная работа состоит из введения, четырех глав, заключения, списка использованных источников и изложена на 156 страницах. В рукописи имеется 38 рисунков, 8 таблиц, 22 формулы, список использованных источников, содержащий 121 наименование.
10 1 Анализ методов и инструментальных средств разработки графического пользовательского интерфейса для автоматизированных систем раскроя швейных изделий
1.1 Анализ требований к графическому пользовательскому интерфейсу автоматизированных систем раскроя швейных изделий
Швейная промышленность по своей природе обязана быстро и ровно реагировать на постоянно изменяющийся рынок. Как следствие, лишь немногие производители могут адаптировать свою продукцию и методы ее производства под нужды рынка с достаточной скоростью. За последние годы эта отрасль стала еще более комплексной. Массовое производство переместилось в страны с недорогой рабочей силой, в индустриально развитых странах производятся, в основном, быстросменяемые модели /1/.
Деятельность производителей швейных изделий должна быть нацелена на ускорение создания моделей за счет избавления от ненужных операций и интеграции процессов создания в производственный цикл. Существенный выигрыш в производительности можно получить, используя современные технологии, начиная с самых ранних этапов производственного процесса изготовления швейного изделия.
Таким образом, автоматизация проектирования швейных изделий резко снижает затраты на производство, уменьшает сроки проектирования и число специалистов, занятых с конкретной моделью, а, следовательно, позволяет быстро менять модели и повышает конкурентоспособность предприятия.
Процесс изготовления швейных изделий состоит из следующих основных этапов: создание модели, конструкции и лекал; подготовка ткани к раскрою; раскрой; пошив изделий и отделка.
Подготовка швейных изделий к запуску в производство начинается в экспериментальном цехе и заканчивается в раскройном /2,3/.
Таким образом, автоматизированная система раскроя в швейном производстве охватывает процессы обработки изделия от создания модели и конструкции до получения кроя и состоит из следующих этапов: разработки модели, создания лекал, раскладки лекал, подготовки задания к раскрою.
На этапе разработки модели создается на экране технический эскиз модели с последующим получением ее трехмерного варианта. Благодаря возможности подбора цветов и рисунков ткани на выходе получается точная идея конечного внешнего вида изделия.
На этапе создания лекал формируется конструкция деталей модели на базовый размеророст изделия. После окончания процесса проектирования деталей и размножения чертежи деталей сохраняются и зарисовываются в натуральную величину на графопостроителе.
На этапе раскладки лекал формируются планы укладки лекал изделий на материале с учетом технологических условий.
На последнем этапе формируется задание на раскрой, который может выполняться автоматической системой раскроя по определенному алгоритму или вручную по зарисованным в натуральную величину лекалам раскладки /3/.
Немаловажное значение имеет процесс укладки лекал, осуществляемый автоматизированной системой раскладки (АСР) и характеризующийся временем, необходимым на создание раскладки и величиной межлекальных потерь. Для одних и тех же моделей швейных изделий могут формироваться различные планы укладок лекал в зависимости от параметров материала.
Совершенство АСР лекал позволяет сократить время на формирование раскладки, процент межлекальных выпадов при раскрое и чаще всего связывается с эффективностью прикладных программ. Сокращение выпадов хотя бы на 1- 2 % дает немедленный и явный экономический эффект /4/.
Усложнение конфигурации лекал швейных изделий приводит к тому, что автоматическая раскладка перестает удовлетворять требуемым результатам, которые можно достичь, используя опыт раскладчика и формируя рас-
12 кладку в диалоговом режиме. В этом случае эффективность работы АСР лекал сложной конфигурации будет зависеть не только от совершенства прикладных программ, но и от дружественности (качества) графического пользовательского интерфейса (ГПИ) - подсистемы АСР, через которую осуществляется взаимодействие пользователя с прикладными программами.
Таким образом, стабильность функционирования швейной АСР базируется на способности персонала к началу эффективного использования системы в течение самого короткого периода адаптации. Кроме того, система должна быть очень надежна и проста в использовании. Последние параметры связаны с тем, насколько сильно методы работы с АСР отличаются от базовых принципов конструирования и создания раскладок деталей швейных изделий. Компьютерные аспекты системы должны быть наиболее прозрачными и концентрировать на себе минимальное внимание операторов. Работа компьютера и программного обеспечения должна подчиняться представлениям оператора о выполняемой работе, а не наоборот. Кроме того, операторы не должны испытывать неудобств, связанных со сбоями в поведении АСР в ответ на их действия /1/.
Для определения роли ГПИ при автоматизированной укладке лекал сложной конфигурации рассмотрим технологический процесс укладки лекал в АСР в рамках автоматизированной системы раскроя «Конструктор» 151.
После выбора модели изделия запускается АСР лекал «Конструктор», первое окно которой содержит список раскладок (если они имеются) с параметрами ширины, длины раскладки и коэффициента межлекальных потерь. Кроме того, можно построить новую раскладку, используя для этого соответствующую команду, или сменить модель, для создания раскладки, загрузив требуемый файл.
Например, для модели детского платья первое окно подсистемы раскладки лекал выглядит следующим образом, как представлено на рисунке 1.1. e|J Детское платье. Журнал "Работница" № 3,1998 Модель № 8 jnjxj
Модель Действия Вид Помощь tf D XI !
Раскладки (Всего і 2)
Ширина (м.) Длина (н.) ; Козф.% ІРзскладка № 1
0,977
Раскладка № 2
Рисунок 1.1 - Первое окно АСР «Конструктор» для модели детского платья
Создание новой раскладки или редактирование выбранной из списка имеющейся раскладки (двойным щелчком мыши по названию раскладки) переводит АСР лекал в режим подготовки раскладки к укладке лекал. Если раскладка редактируется, соответствующее окно АСР в режиме подготовки лекал к укладке содержит параметры редактируемой раскладки (название раскладки, желаемый коэффициент межлекальных потерь, ширина материала, зазор между лекалами). Кроме того, можно задать раппорт рисунка (полоска или клетка) с указанием размеров (отступа от края и ширины полосы или отступа от края и размеры клетки); по умолчанию устанавливается вид рисунка- гладь. Ниже располагаются фактические рассчитанные параметры: длина раскладки, реальный коэффициент межлекальных потерь, общее количество лекал и деталей в раскладке, общая площадь лекал раскладки. Далее располагается перечень лекал модели с указанием размера, роста, количества одинаковых лекал и конфигурации лекала.
Например, для модели детского платья при редактировании уже имеющейся раскладки окно подсистемы укладки лекал в режиме подготовки раскладки к укладке лекал выглядит, как показано на рисунке 1
Например, для модели детского платья при редактировании уже имеющейся раскладки окно подсистемы укладки лекал в режиме подготовки раскладки к укладке лекал выглядит, как показано на рисунке 1.2. |ІРаскладка№1 ^jnjxj
Раскладка Лекала ^кладка Печать Вид Помощь
У ъхз ?
Примечание:
Коэффициент межлекальных потерь : 15.0% Ширина материала: 110.0 см.
Зазор между лекалами : 2мм. Вид рисунка: ГЛАДЬ
Получили: коэффициент потерь =36.2%, длину раскладки = 0м.9б см. 2мм.
Участвует в раскладке 6 лекал б деталей. Общая площадь 0.675 кем.
Лекала
РАЗМЕР | РОСТ | Кол. |" Конфигурация
Пегэед левый
Рукав левый Спинка левая Перед правый Рукав правый Спинка правая
Рисунок 1.2 - Окно подсистемы раскладки лекал АСР «Конструктор» в режиме подготовки раскладки к укладке для модели детского платья
В данном режиме оператор может ввести/ изменить выше указанные параметры раскладки, причем в любом порядке; отредактировать выбранное лекало (добавить новое из того же самого комплекта, удалить из раскладки, отредактировать параметры); изменить раскладку/выполнить укладку лекал; вывести на печать (саму раскладку или спецификацию каждого лекала, или информацию о раскладке).
Каждое лекало характеризуется пятью параметрами: размером, ростом, полнотой, количеством и конфигурацией (вариантами расположения на ткани относительно долевой линии). Кроме того, может указываться величина отклонения лекала от долевой (в градусах).
Окно редактирования параметров лекала модели детского платья представлено на рисунке 1.3. 'ІІРаскладкаГЧ?!
ISjxJ
Параметры Вид Помощь
Лекало : Перед левый
РАЗМЕР 72 РОСТ 128
Количество : / Отклонение от долевой : НЕТ Площадь: 0.06776кв.м. Длина: 41.0см. Ширина: 22.7см. Конфигурация : 1/D/E
По долевой
Готов
Рисунок 1.3 - Окно редактирования параметра лекала модели детского платья в АСР «Конструктор»
Для изменения параметров следующего лекала необходимо выйти из режима изменения параметров текущего лекала и выбрать следующее.
После определения параметров всех лекал можно перейти сразу в режим укладки лекал или в режим изменения готовой раскладки.
В режиме укладки лекал поле раскладки условно поделено на две части: сама раскладка и таблица неуложенных лекал. Внешний вид поля раскладки для лекал модели детского платья показан на рисунке 1.4.
Из рисунка видно, что левая часть экрана отведена под раскладку, а правая часть - под таблицу неуложенных лекал. Удаление конкретного лекала в таблицу неуложенных лекал и, наоборот, перемещение лекала из таблицы на раскладку осуществляется через соответствующие пункты меню, прямое перемещение невозможно.
5ІДТАБЛИЦА] Раскладка № 1 ^JOjxJ
Раскладка Параметры Укладка Автомат Цид Помощь
145.6: 0м96см2мм
Поиск :|слева-направо ^| Критерий: |ниже _^J Профиль :|текущий
И X Н-НИ + -
*[ Скорость: 12
Готов
Спимка правая (72/128)
Рисунок 1.4 - Поле раскладки АСР «Конструктор» с лекалами для модели детского платья
Можно изменять профиль выбранного лекала в соответствии с заданной его конфигурацией, выполнять укладку лекала в ручном или автоматическом режиме, изменять профиль, критерий оптимальности, метод поиска свободного места. Автоматическая укладка текущего лекала выполняется с учетом следующих параметров: профилем, направлением поиска свободного места, скоростью поиска, углом отклонения от долевой. Изменение этих параметров может привести к различному расположению лекал на раскладке. Для примера рассмотрим автоматическую укладку лекала левой спинки модели детского платья для двух вариантов значений параметров. В первом варианте поиск свободного места ведется слева направо, критерием оптимальности служит положение лекала относительно края материала и лекало может быть уложено только с текущим профилем независимо от количества профилей в конфигурации. Вариант укладки показан на рисунке 1.5. ?|ДУКЛАДКА] Раскладка № 1 JOjxJ
Раскладка Параметры Укладка Движение Вид Масштаб Помощь
39.2: 1м0см8мм
Поиск:!слева-направо Н Критерий: ниже Н Профиль: текущий jj Скорость: 1 HXHQD^^T
Готов
Спинка левая (72/128)
Рисунок 1.5 - Положение лекала левой спинки при первом варианте значений параметров
Во втором варианте поиск свободного места ведется слева направо, лекало может быть уложено произвольным профилем из конфигурации. Вариант укладки показан на рисунке 1.6. ' !|УКЛАДКА] Раскладка № 1 J5JXJ
Раскладка Параметры У_кладка Движение В_ид Масштаб Помощь
139.2: 1м0см9мм Поиск:!слева-направо Н Критерий: ближе JJ Профиль:|произвольный j[_ Скорость: 1 -Н
У X И Q. '% Ф.
щ
Готов
Спинка левая (72/128)
Рисунок 1.6 - Положение лекала левой спинки при втором варианте значений параметров
Из рисунков 1.5 и 1.6 видно, что изменение положения лекала во втором варианте повлияло на увеличение длины раскладки.
В ручном режиме текущее лекало можно перемещать с помощью мыши или выполнять более точную подгонку используя соответствующие параметры для перемещения.
После укладки всех лекал из таблицы неразложенных лекал она исчезает с экрана. При удалении лекала из поля укладки оно перемещается в таблицу неуложенных лекал, которую надо снова вывести на экран, используя соответствующий пункт меню, то есть автоматически она не появляется рядом с полем укладки. Допускается также работа в режиме переключения между полем укладки лекал и таблицей неразложенных лекал; при этом и поле и таблица занимают весь экран.
Полученную раскладку можно оптимизировать, достигнув еще большего сокращения межлекальных потерь. Для этого необходимо перейти в режим оптимизации раскладки, пометить лекала раскладки и начать оптимизацию. Например, если взять раскладку с рисунка 1.5 с коэффициентом межлекальных потерь 39,2 % и длиной раскладки 1 м 8 мм, то после проведения оптимизации была получена раскладка, представленная на рисунке 1.7, с коэффициентом межлекальных потерь 36,2 % и длиной раскладки 96 см 2 мм.
Процесс оптимизации раскладки требует определенного времени и в любой момент до завершения оптимизации может быть прерван. В этом случае система подсчитывает коэффициент межлекальных потерь и длину раскладки на текущий момент времени.
Из любого режима работы АСР лекал, кроме режима оптимизации раскладки, можно перейти в режим определения готовой раскладки. В этом режиме при редактировании лекал выполняются те же операции, что и при укладке, но допускается перекрытие лекал и выход за границы раскладки. При этом подсистема раскладки лекал переходит в режим укладки лекал. Допускается изменение масштаба раскладки в любом режиме работы подсистемы раскладки лекал.
З | I[УКЛАДКЛ] Раскладка № 1 JSJxJ
Раскладка Параметры Укладка Движение Вид Масштаб Помощь
136.2: 0м96см2мм
Поиск:|слева-направо ^| Критерий: |ниже J Профиль: текущий _»] Скорость: 1 ^j н х и q п з. <$. f
Готов
Рисунок 1.7 - Оптимальный вариант для раскладки с рисунка 1.5
Таким образом, автоматизированный процесс укладки лекал состоит из отдельных взаимосвязанных между собой задач ГПИ (набор зависит от прикладной задачи), которые сводятся к многократному выполнению пользователями элементарных действий с помощью устройств ввода, то есть определяется функциональностью ГПИ.
Улучшение качества функциональности ГПИ для АСР лекал сложной конфигурации позволяет сократить время на формирование раскладки лекал за счет уменьшения количества выполняемых пользователями действий и исключения сбоев в работе АСР.
Как отмечается в работах /6, II сложность разработки высококачественных ГПИ заключается в том, что, с одной стороны, ГПИ должен удовлетворять требованиям конечных пользователей, с другой стороны, ГПИ является сложной многозадачной системой, которую трудно проектировать и отлаживать.
Для получения качественных графических интерфейсов разработчикам ПИ необходимо иметь в наличии метод спецификации, охватывающий весь
20 жизненный цикл этапа проектирования интерактивных систем, позволяющий более точно анализировать и формально описывать параметры ГПИ, а также процесс взаимодействия пользователей и ГПИ. Более того, такая спецификация должна быть легкой в реализации. Используя формальные методы, разработчики ГПИ могут оценивать свойства системы, обнаруживать недостатки интерфейса в частности или системы в целом. Некоторые формальные методы могут использоваться для автоматизации отдельных стадий процесса проектирования интерактивной системы /8/.
Из выше сказанного следует, что процесс разработки ГПИ АСР лекал швейных изделий, по аналогии с жизненным циклом информационных систем /9, 10/, целесообразно начинать с формулировки и анализа требований пользователей к интерфейсу системы.
Применение специальных методов, удобных, наглядных и простых в использовании позволит, с одной стороны, более четко и точно описать требования конечных пользователей к ГПИ АСР, с другой - облегчить взаимодействие разработчиков ГПИ и конечных пользователей при формировании, анализе и согласовании требований последних к ГПИ Обзор таких методов и обоснование выбора наиболее подходящих приводится в разделе 1.2.
Следующий шаг в процессе разработки ГПИ заключается в выборе методов проектирования системы ГПИ с учетом требований пользователей и особенностей прикладной задачи. Описание и анализ таких методов приводится в разделе 1.3.
В соответствии с обобщенной моделью ПИ - метамоделью Arch 111, важной составляющей системы ГПИ является компонента логики диалога, от которой зависит корректность взаимодействия пользователя с системой и работы самой системы.
Использование формальных методов для описания логики диалога позволяет разработчикам ГПИ моделировать логику диалога, обнаруживать недостатки и «узкие места». В разделе 1.3 дается описание формального метода
21 взаимодействующих последовательных процессов Хоара (Communicating Sequential Processes - CSP) /11/ для моделирования логики диалога ГПИ.
Получение удобных в использовании и понятных для конечных пользователей ГПИ приводит к увеличению трудоемкости проектирования и отладки ГПИ /12/. Одним из путей снижения затрат на разработку ГПИ является наличие специальных инструментальных средств, позволяющих на высоком уровне описать ГПИ и далее по спецификации автоматически сгенерировать исполняемый код, с последующей его отладкой. Кроме того, уменьшить затраты на реализацию и отладку ГПИ можно путем прототипирования ГПИ, когда создается «каркас» интерфейса, обладающий необходимой функциональностью, но без деталей реализации /12, 13, 14/. Среди существующих на сегодняшний день инструментальных средств разработки ПИ /12, 15/ особое место занимают системы управления интерфейсом пользователя (СУИП). В разделе 1.4 приводится анализ архитектур СУИП и описание предложенной автором архитектуры СУИП для разработки ПИ графических редакторов.
При проектировании ГПИ необходимо определить набор интерактивных компонент и логических устройств ввода, через которые пользователь будет взаимодействовать с ГПИ компьютерной системы. Для ГПИ АСР лекал сложной конфигурации в качестве интерактивных компонент могут использоваться визуальные компоненты MS Windows и графические примитивы (точки, линии, окружности, кривые и т.д.), из которых формируются чертежи лекал деталей, а в качестве логических устройств ввода (ЛУВ) - логические устройства стандарта GKS (Graphical Kernel System) /16/.
1.2 Методы анализа требований к графическому пользовательскому интерфейсу автоматизированных систем раскроя
После публикации работы "Психология человеко-машинного взаимодействия" /17/ GOMS-анализ стал одним из наиболее широко известных теоретических концепций человеко-машинного взаимодействия.
Метод GOMS (Goals Operators Methods Selection rules) удобно использовать для анализа знаний о том, каким образом решить задачу в терминах целей, операторов, методов и правил выбора.
Цель - это результат, который пользователь хочет достичь при решении конкретной задачи.
Цели часто разбиваются на подцели, и для достижения цели более высокого уровня необходимо, чтобы бы ее подцели достигались в определенном порядке. Цели и подцели часто описываются в виде иерархии, но строгая иерархия не является обязательной.
Если взять в качестве примера редактирование документа в текстовом процессоре Word, то главной целью является Редактировать документ, а подцелями могут быть Вставить слово, Удалить фразу, Переместить текст.
Оператор - это действие, выполняемое для обслуживания цели (познавательные, моторные, операторы ощущения, или их комбинация).
Операторы могут изменять внутренне ментальное состояние пользователя или физически изменять состояние внешнего окружения.
Важным параметром оператора является время его исполнения, которое может аппроксимироваться константой, законом распределения или функцией от некоторого параметра. Например, время, затрачиваемое на ввод слова в документе, может быть аппроксимировано константой (средним временем ввода слова средней длины), статистическим распределением или функцией,
23 включающей количество символов в слове и время ввода одного символа, которое, в свою очередь, может быть также аппроксимировано константой или законом распределения. Точность прогнозирования времени исполнения, получаемая из GOMS-модели, зависит от точности этого предположения и от точности оценок продолжительности.
Например, при редактировании документа можно выделить следующие операторы: Щелкнуть кнопкой мыши, Переместить курсор мыши, Щелкнуть кнопкой мыши с клавишей shift на клавиатуре, Нажать клавишу удаления на клавиатуре.
Метод - это последовательность операторов и связанных с ними подцелей, необходимых для достижения цели.
Если существует иерархия целей, то можно построить соответствующую им иерархию методов. Содержимое методов зависит от набора возможных операторов и от природы представленных задач.
Например, одним из методов для достижения цели Удалить фразу мог бы быть метод:
Метод: Выделить и удалить',
Операторы: Переместить курсор мыши в начало фразы, Щелкнуть кнопкой мыши, Переместить курсор мыши в конец фразы, Щелкнуть кнопкой мыши с клавишей shift на клавиатуре, Нажать клавишу удаления на клавиатуре.
Часто для достижения цели может существовать несколько методов. Например, для цели Удалить фразу, помимо метода, описанного выше, можно использовать еще один метод:
Метод: Удалить посимвольно;
Операторы: Переместить курсор мыши в конец фразы, Щелкнуть кнопкой мыши, Нажать клавишу забоя на клавиатуре несколько раз.
Если для достижения цели существует несколько методов, то правила выбора необходимы для представления знаний пользователя о применении
24 того или иного метода. Обычно такие правила основываются на специфических свойствах конкретной задачи.
Правила выбора могут проявляться в зависимости от умений пользователя работать с элементами с интерфейса программы или от объективных причин, связанных с использованием методов. Например, пользователь может использовать следующее правило при выборе метода удаления фразы: Если фраза содержит более восьми символов, тогда применяется метод Выделить и удалить, иначе применяется метод Удалить посимвольно.
Во избежание недоразумений необходимо определить разницу между целями и операторами, которая проявляется в зависимости от уровня детализации. Различие между целью и оператором в GOMS - анализе заключается в глубине уровня детализации, выбранного аналитиком. Для цели он предлагает метод, который использует операторы более низкого уровня для достижения этой цели. В противоположность цели, операторы не разбиваются на более мелкие элементы. При этом аналитик всегда должен быть уверен, что время исполнения примитивных операторов ограничено константой или константной функцией от некоторого заданного параметра. В подавляющем большинстве GOMS-моделей анализ завершается на уровне команд или нажатия клавиш на клавиатуре.
Не обязательно выполнять анализ всех частей системы на одном и том же уровне примитивных операторов. Для различных пользовательских задач или различных частей системы могут потребоваться различные уровни структурирования. Метод GOMS позволяет выполнить анализ задачи с разной глубиной детализации. Начиная с целей самого высокого уровня, аналитик рассматривает те части иерархии целей, которые необходимы для решения насущных вопросов. Остальные части можно описать позже при возникновении других вопросов.
Таким образом, декомпозиция целей на подцели и примитивные операторы является очень гибким инструментом анализа.
25 На сегодняшний день можно выделить четыре разновидности GOMS-анализа/18,19/: CMN-GOMS (Card, Moran, Newell); KLM-GOMS (Keystroke-Level-Model); NGOMSL (Natural Goal Operator Method Selection rule Language); CPM-GOMS (Cognitive Perceptual Motor). 1) CMN-GOMS (Card, Moran, Newell).
Этот метод, названный по первым буквам фамилий авторов Card, Moran, Newell, позволяет построить строгую иерархию целей, описать методы, операторы и правила выбора, необходимых для достижения целей, не указывая, каким образом исполняются методы. Методы представляются в неформальном виде, могут содержать в себе подметоды, циклы и условия.
Дерево целей и методы их достижения представляются в неформальном виде: последовательностей операторов и (или) подцелей. Для заданной конкретной задачи CMN - GOMS - модель может прогнозировать как последовательность операторов, так и время их исполнения.
Метод CMN - GOMS основывается на двух Процессорах Модели Личности: Принцип рациональности и Принцип пространства состояний задачи.
Согласно принципу пространства состояний задачи, действия пользователя могут характеризоваться как применение последовательности действий, называемых операторами, для преобразования начального состояния в целевое. При распознавании целевой ситуации может вызываться и исполняться последовательность операторов, необходимая для достижения цели (метода).
В соответствии с принципом рациональности, пользователи, будут применять только эффективные методы для заданной структуры окружения задачи.
Таким образом, деятельность пользователей может рассматриваться в виде последовательностей исполняемых методов для достижения целей. По-
26 скольку пользователи стремятся к эффективности, эти методы в большей степени определяются методами проектирования компьютерных систем.
Следовательно, построение GOMS - модели, основанной на анализе задачи и проектировании системы, позволяет прогнозировать полезные свойства человеко - машинного взаимодействия.
Метод CMN-GOMS удобно использовать на ранних этапах процесса разработки программного средства, поскольку он позволяет структурировать задачу.
2) KLM-GOMS (Keystroke-Level-Model).
Представляет собой упрощенный вариант предыдущего метода и называется моделью уровня нажатия клавиш.
Этот метод использует только примитивные операторы (нажатия клавиш клавиатуры, кнопок мыши, перемещения мыши), не содержит иерархи целей, методов и правил выбора. Аналитик просто составляет список нажатий клавиш и перемещения мыши, выполняемых пользователем для завершения всей задачи. Для оценки времени исполнения задачи суммируется время исполнения каждого оператора.
В основе метода KLM - GOMS лежит простая познавательная архитектура: набор этапов обработки информации человеком, в котором одна активность выполняется до тех пор, пока задача не будет завершена. Предполагается, что все активности по обработке информации содержатся в примитивных операторах, включая внутренние ощущения и познавательные действия. KLM-GOMS содержит шесть операторов, за каждым из которых закреплено время, необходимое для исполнения:
К - оператор, обозначающий нажатие кнопки мыши и клавиши на клавиатуре;
Р - оператор, обозначающий указание курсором мыши цели на экране;
Н - оператор, обозначающий помещение рук на клавиатуру или другое устройство; M - оператор, обозначающий мысленную подготовку для выполнения действия или конечной последовательности действий; D - оператор, обозначающий рисование сегмента линии на сетке; R - оператор, использующийся для представления времени реакции системы, в течение которого пользователь ждет.
Для определения расположения оператора М среди других операторов в последовательности, метод KLM - GOMS включает в себя пять эвристических правил.
Дальнейшие исследования направлены на уточнение оценок времени исполнения примитивных операторов определение возможностей использования их не только в командных интерфейсах.
Применение метода KLM - GOMS ограничивается анализом небольших задач, которые могут быть сведены к последовательности операторов.
3) NGOMSL (Natural Goal Operator Method Selection rule Language).
Эта структурированная естественная языковая нотация является более строгим вариантом метода CMN - GOMS и позволяет спрогнозировать не только время исполнения методов, состоящих из набора операторов, но и время, затраченное на изучение методов.
При создании NGOMSL- модели строится иерархия целей, для достижения которых формируются методы. Последние состоят из последовательности шагов, описывающих, какие цели необходимо достичь, какие операторы необходимо выполнить и какую информацию необходимо запомнить пользователю для исполнения методов. Формирование методов продолжается до тех пор, пока они не будут состоять только из примитивных операторов (по аналогии с методом KLM - GOMS).
Основу метода NGOMSL составляет теория познавательной сложности, в соответствии с которой продукционные правила могут изменять содержимое рабочей памяти или выполнять примитивные внешние операторы, такие как нажатие клавиш. Между нотацией NGOMSL и архитектурой тео-
28 рий познавательной сложности существует прямая связь: однозначное соответствие между операторами NGOMSL - модели и и продукционными правилами, записанными в формате теории познавательной сложности. Таким образом, нотация NGOMSL позволяет строить достаточно качественные прогнозы как только для времени исполнения методов (как KLM и CMN), так и для времени, необходимого для изучения их работы.
Хотя NGOMSL - анализ может обеспечить полезное описание задачи на разных уровнях задачи, качественные прогнозы времени исполнения и изучения работы методов возможно тогда, когда методы используют операторы, известные пользователю и обладающие известными свойствами. Кроме того, простая многоэтапная архитектура теории познавательной сложности ограничивает применение нотации NGOMSL для описания иерархии методов, имеющих последовательную структуру, не давая возможности представлять методы, операторы которых могут выполняться в произвольном порядке, прерываться, повторно запускаться.
4) CPM-GOMS (Cognitive Perceptual Motor).
Название метода образуется из двух словосочетаний: уровень операторов познания, ощущения, моторики (Cognitive Perceptual Motor level) и метод критического пути (Critical-Path Method).
Подобно выше перечисленным GOMS- моделям этот метод прогнозирует время, необходимое для выполнения задачи, основываясь на анализе компонентов действий пользователя. Однако он требует специального уровня анализа, где примитивными операторами являются простейшие действия моторики, познания и ощущения, которые могут взаимодействовать друг с другом или выполняться параллельно. Для представления операторов и связей между ними используются диаграммы состояний. Критический путь в диаграмме определяет прогнозируемое общее время, затраченное на решение задачи.
Метод СРМ - GOMS основывается на модели процессора пользователя (Model Human Processor - МНР), которая является основной архитектурой для описания обработки информации человеком.
Человек рассматривается как множество процессоров и состояний систем, в которых сенсорная информация сначала собирается, распознается в рабочей памяти процессора ощущения, а затем познавательный процессор обрабатывает информацию и отдает команду процессору моторики выполнить физические действия. Процессоры запускаются параллельно друг к другу.
Для построения СРМ - модели сначала строится CMN - модель, завершающаяся операторами ощущений или моторики. Каждая цель и метод описываются операторами МНР, после чего формируется диаграмма состояний.
По сравнению с остальными методами GOMS метод СРМ позволяет более подробно анализировать задачи, учитывая помимо всего опыт пользователей.
Для выбора наиболее подходящего варианта из методов семейства GOMS для описания и анализа требований конечных пользователей к ГПИ АСР следует принять во внимание следующее: описание требований должно представлять собой структуру, наглядным и естественным образом отражающую знания и видения пользователей о ходе решения задачи с помощью АСР и не затрагивающую психологический аспект деятельности пользователей (например, какой рукой был введен оператор, сколько времени потребовалось на изучение команды, в какой момент пользователь перевел взгляд на экран и т.д.). Наиболее полно этому критерию удовлетворяет метод CMN -GOMS, позволяющий отобразить точку зрения пользователей на процесс решения задач в виде иерархии целей и методов. Применение метода CMN -GOMS для анализа требований пользователей к ГПИ АСР и их записи на языке анализа задач будет подробно рассмотрено в следующих главах. зо 1.3 Языки спецификаций графического пользовательского интерфейса для автоматизированных систем раскроя
Как отмечено в работе /20/, приступая к проектированию ГПИ, разработчик сталкивается с большим спектром задач: начиная от разработки принципов визуального взаимодействия человека с компьютером и заканчивая реализацией алгоритмов. Первой задачей, возникающей при проектировании ГПИ, является разработка принципов структурирования и поведения визуального компьютерного мира.
В соответствии с метамоделью Arch, подробно описанной в работах II, 12, 21/, архитектура ГПИ состоит из пяти компонент: набора интерактивных компонент, компоненты представления, диалоговой компоненты, функционального ядра и адаптера функционального ядра.
Различные методы спецификации ГПИ /22, 23, 29/ позволяют в той или иной степени описать структуру и функционирование компонент ГПИ, правила взаимодействия между ними, а также определить характеристики, недостатки или продемонстрировать корректность системы ГПИ как до начала проектирования, так и в ходе разработки.
Ниже будет дано описание некоторых языков спецификаций ГПИ и проведен их анализ с позиций унифицированности, формальности, наглядности и простоты использования.
1.3.1 Унифицированный язык моделирования UML
История развития языка UML (Unified Modeling Language) берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch (названный по фамилии автора Гради Буча) и ОМТ (Object Modeling Technique - Метод Моделирования Объектов).
31 Анализ работ /10, 24- 26/ показал, что UML является языком визуального моделирования, разработанным для спецификации, визуализации, проектирования и документирования программных систем. Визуальные модели обеспечивают наглядное представление архитектурных и структурных решений, делая их понятными не только разработчикам, но и заказчикам системы, и обеспечивая необходимый контроль и управление всеми фазами создания программных средств.
Как средство проектирования программных систем язык UML предназначен исключительно для технологии объектно-ориентированного программирования. Однако используемые в нем методы описания систем достаточно универсальны и как средства графического представления моделей могут использоваться достаточно широко.
В UML определены четыре типа сущностей: структурные, поведенческие, группирующие и апнотационные. Сущности являются основными объектно-ориентированными элементами языка, с помощью которых создаются модели.
Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».
Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей: взаимодействие - это поведение, суть которого заключается в обмене сообщениями между объектами в рамках конкретного контекста для достижения определенной цели; автомат - алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят в ответ на различные события.
32 Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.
Пакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и другие группирующие сущности. В отличие от компонентов, которые реально существуют во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только в процессе разработки.
Аннотационные сущности - это пояснительные части модели UML: комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Примечание используют, чтобы снабдить диаграммы комментариями или ограничениями, выраженными в виде неформального или формального текста.
В языке UML определены следующие типы отношений: зависимость, ассоциация, обобщение и реализация. Эти отношения являются основными связующими конструкциями UML и также как сущности применяются для построения моделей.
Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.
Ассоциация (association) - структурное отношение, описывающее совокупность смысловых или логических связей между объектами.
Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent).
Реализация (realization) является семантическим отношением между классификаторами, при котором один классификатор определяет обязатель-
33 ство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях: между интерфейсами и реализующими их классами или компонентами; между прецедентами и реализующими их кооперациями.
Графические изображения моделей системы в UML называются диаграммами. В терминах языка UML определены следующие их виды:
1) Диаграмма вариантов использования или прецедентов (use case diagram). Диаграммы вариантов использования описывают функциональное назначение системы или то, что система должна делать.
Диаграмма классов (class diagram). Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.
Диаграммы поведения (behavior diagrams).
3.1) Диаграмма состояний (statechart diagram). Диаграммы состояний чаще всего используются для описания поведения отдельных объектов, но также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсисте мы, операции и методы.
Диаграмма деятельности (activity diagram). Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности. На диаграмме деятельности отображается логика и последовательность переходов от одной деятельности к другой, а внимание аналитика фокусируется на результатах. Результат деятельности может привести к изменению состояния системы или возвращению некоторого значения.
Диаграмма взаимодействия (interaction diagrams).
3.3.1) Диаграмма последовательности (sequence diagram). Временной аспект поведения может иметь существенное значение при моделировании
34 синхронных процессов, описывающих взаимодействия объектов. Для моделирования взаимодействия объектов во времени в языке UML используются диаграммы последовательности.
3.3.2) Диаграмма кооперации (collaboration diagram). Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.
4) Диаграммы реализации (implementation diagrams). В языке UML для физического представления моделей систем используются диаграммы реализации, которые включают в себя диаграмму компонентов и диаграмму развертывания.
Диаграмма компонентов (component diagram). Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Она позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный и исполняемый код.
Диаграмма развертывания (deployment diagram). Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними.
Нотация UML позволяет описать систему ГПИ с различных позиций и на разных этапах ее разработки. В работе /20/ приведены варианты использования диаграмм UML для спецификации и моделирования ГПИ.
Однако для адекватного понимания базовых конструкций языка UML важно не только владеть некоторыми навыками объектно-ориентированного программирования, но и хорошо представлять себе общую проблематику процесса разработки моделей систем.
35 1.3.2 Нотация действий пользователя UAN
Нотация UAN (User Action Notation) /22, 27, 28/ была разработана в 80-х годах прошлого века в Вирджинии Антонио Сиочи, Рексом Хартсоном и Деборой Хикс. Целью UAN является описание взаимодействия между пользователем и системой в терминах действий пользователя, реакций системы и состояний интерфейса.
Основной организационной единицей в UAN является задача, которая может включать в себя как отдельные действия пользователя (минимальный элемент задачи), например, выбор пиктограммы, так и другие задачи, что позволяет объединять действия пользователей при описании, например, выбор пиктограммы и выбор опции меню. Таким образом, в нотации UAN задачи могут состоять или только из подзадач (верхний уровень абстракции), или из подзадач и действий пользователя (нижний уровень абстракции).
Задачи нижнего уровня абстракции описываются в виде таблицы, состоящей из трех колонок: «Действия пользователя», «Обратная связь» и «Состояние интерфейса», и читается слева- направо сверху - вниз. В первой колонке записываются события в нотации UAN, представляющие собой последовательность действий пользователя с предусловиями или без них. Предусловие, может использовать только переменные, описанные в последней колонке таблицы и должно быть истинным, чтобы могли выполниться действия. При выполнении предусловия и последовательности действий система реагирует на них посредством выполнения действий обратной связи, которые отражаются во второй колонке таблицы. В третьем столбце таблицы записываются выражения с переменными, которые отражают состояние интерфейса и исполняются, когда система реагирует на действия пользователя.
Задачи верхнего уровня абстракции записываются вне таблиц в виде равенств, в левой части которых записаны задачи, а в правой - соединенные операторами UAN подзадачи, необходимые для их выполнения.
Задачи, входящие в состав других задач, могут соединяться операторами, перечень которых приведен в таблице 1.1, где А и В - задачи.
Таблица 1.1 - Операторы UAN для описания взаимодействия задач
Обозначения языка UAN приведены в таблице 1.2.
Таблица 1.2 - Наиболее часто используемые обозначения UAN )tf
37 Нажатие отдельных клавиш клавиатуры будем обозначать следующим образом: К[Название клавиши]. По аналогии с кнопкой мыши, запись Ку[Название клавиши] соответствует надавливанию и удержанию клавиши, а КЛ[Название клавиши] соответствует отпусканию клавиши. Тогда, например, нажатие и отпускание клавиши Delete запишется в виде строки Kv[Delete] КЛ[Delete].
Ввод символов с клавиатуры удобно записывать в виде предусловий с регулярными выражениями в качестве условий: (К = <Регулярное выражение^: (Kv Кл) . Команды, в отличие от набора произвольных символов, вводимых с клавиатуры, будут представляться в виде строки, соответствующей имени команды. Например, ввод команды Delete запишется строкой (К = "Delete"):(Kv КЛ) , а ввод имени файла, состоящего из латинских строч-ных букв и арабских цифр, - (К = [a-z]([a-z] |[0-9])): (Kv КА).
Кроме того, можно применять следующие операции и кванторы: квантор всеобщности (V); квантор существования (3); операторы сравнения: = , Ф ,
При описании графических объектов взаимодействия (заготовок) нотация UAN обладает тремя недостатками. Во-первых, она является не строго формальной. Разработчик может добавлять новые обозначения и новые столбцы таблицы по своему желанию, что затрудняет автоматизированное выполнение анализа процесса проектирования, описанного на UAN. Во-вторых, при описании задач учитываются только корректные действия пользователя, что требует описания реакции системы на неправильные действия пользователя. В-третьих, в UAN отсутствует механизм изменений интерфейса, инициированных самой системой.
Однако UAN обладает богатым и компактным языком для описания действий пользователя, а также позволяет наиболее наглядным и естественным способом описать взаимодействие между пользователем и системой.
Применение нотации UAN для описания ГПИ интерактивных систем описано в работах /22,28, 30/.
38 1.3.3 Нотация взаимодействующих последовательных процессов Хоара
Язык взаимодействующих последовательных процессов (CSP), предложенный Ч. Хоаром /11/, является формальной нотацией и позволяет описывать различные системы в виде выражений поведения, обозначающих процессы, способные принимать участие в событиях. Совокупность событий, в которых может участвовать процесс, называется алфавитом процесса.
Основываясь на работе 111, синтаксис выражений поведения можно определить по индукции следующим образом.
Базовые случаи. exit - процесс, успешно завершивший свою работу. stop - процесс, не способный ни к каким дальнейшим действиям. Общие случаи.
Если є, Єї, Є2, ..., em - события, а Р, Pi, Р2, ...,Pn - процессы, то следующие выражения также процессы: е ; Р - обозначает процесс, который участвует в событии е, а затем ведет себя как процесс Р. Операция ";" называется префиксом; Pi [] ?2 - обозначает процесс выбора;
Рі» Рг — последовательная композиция; Pi || Рг - параллельная композиция;
Р] [> Р2 - отключение (disabling) процесса Pi процессом Р2; Pi Д Р2 - прерывание процесса Pj процессом Р2.
Для задач ПИ язык взаимодействующих последовательных процессов был впервые применен Александером /31/.
Чтобы определить смысл выше перечисленных операторов удобно применить структурную операционную семантику (СОС) Плоткина /32/, как это предложено в работе 111. СОС определяет способ вывода смысла выражений из их синтаксиса. Под системой взаимодействующих процессов, понимается система, включающая в себя ПИ и пользователя. Система выполняет обра-
39 ботку события, когда обе стороны вовлечены в процессы. Процесс Р выполняет действие, когда он и его окружение вместе видят одно и то же событие е в одно и то же время. Это совместное действий называется синхронизацией. Множество событий, которые процесс Р может увидеть (алфавит процесса Р) обозначается через а (Р). Смысл операторов поведения можно определить на основе правил вывода, записанных в форме: где Р - посылки, Q - заключение, С - условие применимости правила. Например, правило для оператора префикса имеет вид, представленный формулой 1.1: [еео(Р)], (1-1) е;Р е»Р' что означает, что процесс е;Р после наступления события е ведет себя как Р'. Для оператора выбора справедливы правила, описанные формулами 1.2 и 1.3:
Р-^Р (1.2) PI1Q -^ QJU Q' (1.3) PIIQ -^ Q'
Первое из них утверждает, что если процесс Р может синхронизироваться по событию е и далее вести себя как процесс Р', то процесс Р [] Q тоже может синхронизироваться по событию е и далее вести себя как Р'. Второе правило описывает выбор по второй альтернативе.
Остальные операторы определяются следующим образом, как показано в формулах 1.4 и 1.5:
Р -^ Р' P»Q -^U- P'»Q (1.4)
40 exit»Q (1.5)
Из формулы 1.4 следует, что если процесс Р может синхронизироваться по событию Є и далее вести себя как процесс Р\ то процесс P»Q может синхронизироваться по событию е и далее вести себя как P'»Q. В соответствии со вторым правилом, процесс exit»Q, при наступлении любого события из его алфавита будет вести себя как Q.
По аналогии, определяются другие правила взаимодействия процессов. е Р —*-Р' Q-^Q' (1.6) PQ —*- F Q' е Р —*-Р'
Р Q -Jl^P' Q [e*o(Q)], (1.7) 9^Q' [.««От]. w Q » PQ'
Р -^ Р (1.9) P[>Q -^*- Р'[>Q exit l> Q exit (1.10) P[>Q -1^ Q' (1.11) exitAP exit (1.12)
РОССИЙСКАЯ
ГОСУДАРСТВЕННАЯ
БИБЛИОТЕКА
Р -*- Р' PAQ -^*~ P'AQ (1.13) Q-^Q' PAQ -^»- Q'»(PAQ) (1.14)
Для сокращения числа скобок в выражениях поведения примем следующий приоритет операций: ; [] || [> А » \. Операторы с одинаковым приоритетом будем считать ассоциативными вправо. Как будет показано позже, набор перечисленных операторов достаточен для описания многопотоковых диалогов произвольной сложности в виде выражений поведения. Но эти выражения имеют один недостаток: в них события представляются атомарными действиями, тогда как в ПИ событие - это блок операций ввода и вывода, выполнение которых можно рассматривать как срабатывание логического устройства ввода. Рассмотрим подробнее структуру событий ПИ 111.
В языке CSP события - это объекты, служащие для синхронизации процессов. Если событие отражает синхронизацию процесса с окружением, то есть с пользователем, то в момент его совершения происходит ввод данных от пользователя к функциональному ядру или вывод на экран данных, хранящихся в функциональном ядре. Если синхронизируются два процесса, то событие одновременно включает в себя передачу данных между процессами, таким образом, обозначение события может быть одновременно и обозначением канала, по которому передаются данные. В этом случае событие записывается парой c.v, где с - название канала, v - значение, передаваемое по каналу (сообщение). Множество всех сообщений, которыми может обмениваться процесс Р по каналу с определяется следующим выражением: ctc(P)={v| c.v єсс(Р)} (1.15)
Если v є ас (Р), то процесс, который сначала передает по каналу с значение v, а затем ведет себя как процесс Р, определяется так: (c!v->P) (1.16)
42 Процесс, который готов получить значение переменной х по каналу с, а затем вести себя как процесс Р(х), определяется в виде: (с?х->Р(х)) (1.17)
Таким образом, событие определяет потоки данных от пользователя к функциональному ядру и в обратном направлении.
Применение нотации CSP для описания логики диалога подробно описано и проанализировано в работе /11/.
Нотация CSP является формальной, ее основные понятия четко определены и не требуют дальнейшего расширения, что позволяет достаточно легко реализовать язык CSP на каком - либо языке программирования. Однако, трудность восприятия языка CSP конечными пользователями делает практически невозможным его применение на ранних стадиях проектирования ГПИ, когда происходит общение разработчиков с пользователями и согласование требований последних к ГПИ.
Как было подчеркнуто в разделе 1.1, применяемая для разработки ГПИ спецификация должна быть наглядной и легкой в использовании, с одной стороны, и, по возможности, формально описывать систему ГПИ. Ни одна из выше перечисленных нотаций не удовлетворяет полностью этому критерию, что позволяет сделать следующий вывод о необходимости создания метода спецификации, отвечающего новым требованиям. Этот метод спецификации должен основываться на нотации UAN, исходя из ее простоты и удобства в использовании, и на нотации CSP, исходя из ее формальности, полноты и удобства реализации на компьютере.
1.4 Анализ систем управления интерфейсом пользователя для автоматизированных систем раскроя
Необходимость повышения качества пользовательских интерфейсов и снижения затрат на их разработку привело к появлению различных инструментальных средств, которые в той или иной степени позволяют решить данные задачи.
1.4.1 Классификация инструментальных средств разработки пользовательского интерфейса
В своих работах Б. Майерс /12, 15/ выделяет следующие уровни программного обеспечения ПИ: оконные системы, инструментарии и высокоуровневые инструменты.
Оконная система (Windowing System ) - программный пакет, обеспечивающий независимость от особенностей используемых аппаратных средств и управление окнами, на которые делит экран дисплея компьютера, предоставляя возможность работать в мультипрограммном режиме. При этом ввод и вывод отделены друг от друга /12, 33/. Первые оконные системы были реализованы как составная часть программы. Например, системы Smalltalk /34/ и DLISP /35/ имели собственные оконные системы. В настоящее время оконные системы являются частью операционных систем (Macintosh, Microsoft Windows, UNIX).
Инструментарий (Toolkit) - библиотека технологических интерактивных средств (заготовок - widgets), позволяющих использовать физические устройства ввода (мышь, клавиатура и др.) для ввода различных значений (например, команд) при наличии обратной связи, отображаемой на экране /12/. Инструментарий содержит набор функций, реализующий компоненты интерфейса нижнего уровня: меню, кнопки, подокна, зоны диалога, зоны прокрутки, а также включает графическую библиотеку вывода (основные
44 примитивы) и обработчики событий. Различные инструментарии могут базироваться на одной оконной системе. Например, для оконной системы X Windows были разработаны инструментарии: XT /36/, Interviews /37/, Garnet /38/,ТК/39/.
И оконные системы, и инструментарии обеспечивают ограниченный набор вариантов взаимодействия конечного пользователя с ПС и требуют от пользователя и разработчика ПИ знаний по программированию.
Наибольшим разнообразием отличаются высокоуровневые инструментальные средства - high-level tools (классификация дана в работе /12/), предоставляющие более совершенные способы решения проблем разработки ПИ и взаимодействия пользователей с ПС. Особое место среди выше перечисленных инструментальных средств разработки ПИ занимают системы управления интерфейсом пользователя - СУИП (user interface management systems - UIMS).
СУИП - это часть интерактивной системы, набор инструментов для спецификации, реализации, прототипирования и управления интерфейсом пользователя, осуществляющая внешнее управление диалогом. Взаимодействие пользователя с приложением выполняется только через СУИП.
Таким образом, СУИП должна обеспечить средства проектирования ПИ, описания диалога, управления диалогом и настройкой ПИ во время работы с интерактивной системой. Впервые понятие СУИП было введено Д. Казиком в 1982 году/40/.
Главной особенностью СУИП является разделение семантики приложения и ПИ. Преимущества такого разделения, которые одновременно являются преимуществами применения СУИП: переносимость (чтобы обеспечить возможность одному и тому же приложению использоваться на различных системах с различными ПИ); многократное использование (разделение увеличивает вероятность многократного использования компонент, что может сократить затраты на проектирование); получение нескольких интерфейсов (для повышения интерактивной гибкости приложения могут разрабатываться различные интерфейсы, выполняющие одинаковые функции); настраиваемое (пользовательский интерфейс может быть изменен как разработчиком ПИ, так и пользователем, для повышения его эффективности, не затрагивая приложения); прототипирование ПИ (возможность создания «скелета» ПИ, выполняющего те же функции, что «оригинальный» ПИ, но без проработки деталей)/41/.
Поскольку приложение и представление разделены между собой, для обеспечения их взаимодействия используется управление диалогом.
Как отмечается в работе /13/, основные требования, предъявляемые к СУИП можно разбить на две группы: разработчики программного обеспечения: возможность проектирования ПИ с использованием графических объектов (заготовок) в интерактивном режиме на основе принципов прямого манипулирования объектами и WYSIWYG; возможность описания логики диалога на формальном языке; возможность применения языка программирования для описания особенностей ПИ; возможность использования различных стилей диалога; возможность прототипирования ПИ; обеспечение простоты изменения интерфейса на этапе его проектирования; обеспечения простоты изучения и использования прикладных программ на этапе реализации и отладки ПИ; возможность проектирования интерфейсов разной сложности; возможность обработки ошибок и отладки ПИ; возможность разработки ПИ для пользователей разного уровня. конечные пользователи: согласованность интерфейса с прикладными программами; возможность настройки ПИ под индивидуальные нужды пользователей; поддержка процесса обучения и тренировки; многоуровневая поддержка сопровождения или функций помощи; возможность расширения прикладных программ; обеспечение безошибочного диалога с приложением.
46 Кроме того, на данном уровне абстракции СУИП должна быть ориентированной на определенную предметную область реального мира. СУИП рассматривают с трех основных позиций /41/: как концептуальную схему (модель) для структуры интерактивной системы, в которой семантика приложения и представление разделены между собой; как методы реализации разделения между приложением и представлением с обеспечением взаимодействия между ними; как средства поддержки управления, реализации и анализа ПИ во время выполнения программы.
Модели СУИП рассматриваются в следующем разделе.
1.4.2 Модели систем управления интерфейсом пользователя
Архитектуру СУИП можно рассматривать с двух позиций: модель, лежащая в основе ПИ; фазы диалога, реализованные СУИП.
В первом случае, внимание концентрируется на блоках, поддерживающих компоненты моделей ПИ, и на средствах взаимодействия между этими блоками.
Во втором случае, основное внимание уделяется структуре элементов, поддерживающих различные фазы ПИ.
1.4.2.1 Модели, лежащие в основе пользовательского интерфейса
1) Лингвистическая модель ПИ
Первым подходом к организации СУИП можно назвать «разговорную» модель ПИ, подробное описание и анализ которой можно найти в работе /42/. В этой модели ПИ состоит из четырех компонент: концептуальной, семантической, синтаксической и лексической. В соответствии с этой моделью рабочей группой по системам управления интерфейсом пользователя в г. Зеехай-
47 ме разработала модель СУИП, которая в дальнейшем получила название зеехаймовской /33,42,43,44/. Ее структура приведена на рисунке 1.8.
Пользователь и л о ж е н и е
Рисунок 1.8 - Структура зеехаймовской модели СУИП
Модуль внешнего представления выполняет лексические функции, обеспечивая адекватное внешнее представление состояния диалога и модели мира пользователя на экране, а также поддерживая необходимый набор логический устройств ввода. Модуль логики диалога определяет синтаксис между пользователем и приложений, преобразуя потоки входных знаков от модуля внешнего представления в структуры, соответствующие комаїїдам и операндам. Прикладной интерфейс можно рассматривать как представление прикладной части системы с позиции ПИ, независимое от реализации. Нижний прямоугольник соответствует семантической обратной связи для передачи модулю внешнего представления реакции приложения на соответствующие команды.
Эта модель показывает, каким образом возможно разделение ПИ и прикладной части системы через механизмы взаимодействия между блоками СУИП.
Выявленные недостатки зеехаймовской модели СУИП (разобщенность синтаксиса, сложность управления изображением) /42/, а также появление новых моделей ПИ потребовали нового подхода к анализу архитектуры СУИП.
48 2) Объектно - ориентированные модели ПИ
Новые модели ПИ основываются на объектно - ориентированном подходе и идее прямого манипулирования объектами.
Разработчики языка Smalltalk-80 /45/ предложили модель ПИ, названную ими MVC (по названию трех компонент: Model (Модель), View (Вид), Controller (Контроллер)) /46, 47/. Все компоненты триады MVC являются объектами, которые могут обмениваться сообщениями. Модель является разделяемой межу контроллерами и соответствующими им видами.
Модель РАС /48, 49/ структурирует ПИ в виде иерархии РАС - триад, которые называются агентами. Название модели РАС, как и модели MVC, дано по названию составляющих ее компонентов: Presentation (Представление), Abstraction (Абстракция), Control (Управление). Каждая триада РАС имеет свою собственную модель, доступ к которой возможен только через ее контроллер, что обеспечивает явное определение между объектами.
Исходя из принципов прямого манипулирования, описанных Б. Шнейдерманом /50/, СУИП должна обеспечивать очень быструю семантическую обратную связь, объединив воедино лексику, синтаксис и семантику. Кроме того, ввод и вывод объединяются для создания иллюзии прямого воздействия на интересующие объекты. На основании выше сказанного можно построить модель СУИП /40/, представленную на рисунке 1.9. п СУИП I
Пользова-тель Ч-
Компонента представления
