Размещено на http://www.allbest.ru/

Анализ технологичности систем управления интерфейсом пользователя на основе формального описания диалога

Правдин А.Л.

Введение

Система управления интерфейсом пользователя (СУИП) - часть интерактивной программной системы, набор инструментов проектирования, реализации и монопольного управления пользовательским интерфейсом системы [1,3], обладающая двумя отличительными особенностями:

- обеспечением независимости изменений пользовательского интерфейса (ПИ) и кода, реализующего функциональность системы;

- быстрым изменением ПИ системы разработчиком и лёгкой настройкой ПИ пользователем.

В проектировании СУИП, как и в разработке программного обеспечения (ПО) в целом, существует тенденция использования моделей для упорядочивания разработки, увеличения повторного использования кода [2,4]. Такая технология выражается, в частности, в составлении некоторого описания системы и создании генераторов, способных воссоздать систему по данному описанию. Одним из направлений при создании СУИП стало формальное описание диалога, которое является основой для генерации ПИ [3]. интерфейс пользовательский интерактивный

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

Обзор состояния предметной области

СУИП является закономерным этапом в развитии технологии проектирования интерактивных систем, возникшем в ответ на усложнение требований к ним. Функциональная декомпозиция, применённая к интерактивным системам, привела к выделению 5 слоёв метамодели ARCH, на данный момент являющейся эталонной [5]. В технологии изготовления ПО 3 блока модели (Диалог, Представление и Базовый ввод-вывод) были объединены в отдельный класс систем - СУИП или, точнее, СПИП - системы проектирования интерфейса пользователя (исторически понятия употребляются как синонимы). При создании систем данного класса используются специальные технологии из-за специфических требований к ним, таких как реализация и поддержка нескольких интерфейсов, настраиваемость, прототипирование, поддержка оценки эргономичности и другие [1,3].

Общая технология построения интерактивной информационной системы с использование СУИП заключается в следующем. После анализа требований и выработки архитектурного решения на основе СУИП проект разветвляется на два направления: разработку функционального ядра (ФЯ) и разработка ПИ. При разработке ПИ возможно создание собственной СУИП или использование сторонней. В первом случае выбирается стратегия реализации ПИ. Во втором - по соответствующей стратегии, диктуемой используемой СУИП, создаётся базовое описание ПИ.

СУИП подразумевает некоторый каркас, по которому можно воспроизвести ПИ системы. Этим каркасом может быть любая модель, отвечающая определённым правилам, однако исследователи утверждают, что для этого наилучшим образом подходит формальное описание диалога [3, 10, 11]. Вывод явно не следует из модели ARCH, однако диалог является первой детализацией требований к системе, непосредственно касающейся ПИ, ввиду чего его можно взять за основу СУИП. Важным моментом здесь является принципиальная возможность выделения элемента логики диалога: если модель ARCH неприменима к системе в целом, то использование СУИП на основе формального описания диалога требует дополнительного исследования.

Рассмотрим теперь, в чём же состоит формальное описание логики диалога. Описание диалога является формальным, если имеются сформулированные спецификации диалога, выраженные в однозначно интерпретируемой форме. Чтобы описание диалога могло быть основной СУИП дополнительно необходимо, чтобы спецификация диалога была доступна программной системе.

Таким образом, при построении системы возникают две задачи, которые определяют сущность технологии построения СУИП на основе формального описания диалога:

- получение формального описание диалога, исходя из требований пользователя;

- реализация ПИ системы на основе описания диалога.

Анализ технологии на основе формального описания диалога

Процесс создания описания диалога

Первая из поставленных задач решается, например, следующим образом [3]. Сначала строится дерево целей и задач предметной области на основе применения метода анализа задач CMN-GOMS [6]. Описание целей детализируется действиями пользователя на основе нотации UAN [7]. Для реализации этого этапа должна быть сформирована детальная спецификация ПИ, отражающая, каким образом и посредством каких компонентов ввода-вывода (ВВ) пользователь будет взаимодействовать с системой. Далее детализированная модель действий пользователя преобразуется в описание диалога на языке взаимодействующих последовательных процессов CSP [8].

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

- описание логики процесса, как части формализованного обобщения требований групп пользователей;

- создание спецификации ПИ;

- детализацию логики процесса на основе манипуляций этой метафорой посредством некоторой формальной спецификации.

Условием применимости такого разбиения является использование принципа прямого манипулирования [14], подразумевающего, что все элементы предметной области, предназначенные для взаимодействия с ними пользователя, будут отображены в создаваемом ПИ.

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

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

- набор необходимых компонентов/элементов ВВ;

- правила генерации элементов логики диалога для компонентов ВВ;

- интерфейс взаимодействия между компонентами ВВ и подсистемой управления логикой диалога;

- метафоры и идиомы ПИ: абстракции и семантику элементов ПИ.

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

Существуют различные способы спецификации ПИ [7, 11, 13], однако в них не предусмотрено сохранение информации о метафорах и идиомах, что ведёт к рискам нарушения их целостности и дополнительным затратам на их пересмотр при модификациях. Как замечено в [12], абстракция не возникает сама собой, её необходимо явно выделять и поддерживать. Существуют общие способы сохранения абстракции, например, семантические модели данных, средства UML, но они неадекватны для спецификации ПИ. Заметим, что часто спецификацию не составляют вообще, и представление о системе существует только "в голове у проектировщика", что резко повышает затраты на модификацию системы, делает невозможным полноценную реализацию настройки ПИ.

Третья часть процесса получения логики диалога, т.е. детализация процесса на основе спецификации ПИ, поднимает такие вопросы как: модель диалога, выбор языка описания диалога, учёт требований полноты, оптимальности.

Классификация типов и форм диалога довольно обширна [15]. Выделяют такие понятия, как абстрактный и конкретный тип диалога, форма диалога. Современные интерактивные системы, построенные на основе распространённых оконных систем, поддерживают любой из типов и форм диалога. Как правило, более других используется объектно-ориентированная форма диалога и абстрактный тип диалога, подразумевающий введение пользователем фраз на ограниченном естественном языке (из классификации в [15]). Фразы здесь рассматриваются не только как выражения на некотором языке проектирования, но и как взаимосвязанная последовательность манипуляций с использованием ГПИ.

Способы описания диалога так же могут быть различны (продукционные правила, разновидности сетей Петри, различные алгебры процессов, событийные модели). Можно классифицировать подходы по точке зрения: либо внимание сосредотачивается на состояниях, либо на процессах происходящих в системе. Однако процессы можно рассматривать как изменения состояния системы; описание логики с их помощью отличается лаконичностью, но теряет наглядность.

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

Процесс Реализации пользовательского интерфейса

Существует два мнения о решении задачи реализации пользовательского интерфейса на основе описания диалога:

- воспроизведение может быть полностью автоматизировано;

- создание конечного ПИ невозможно без вмешательства человека.

Конечно, автоматическая генерация ПИ возможна. Важными моментами при этом являются типизация и декомпозиция диалога. Так в работе [9] предлагается модель диалога, управляемая данными. В работе указывается, что можно автоматически сгенерировать ПИ по описанию диалога, если ввести некоторую систему типов, структурирующую данные, которыми оперирует диалог. Имея систему типов можно определить отображение данных, которыми оперирует диалог, в компоненты ПИ. Для того, чтобы полученный ПИ не был неупорядоченным множеством необходимых визуальных компонентов, необходима декомпозиция диалога на основе задач, которая сгруппирует связанные рамками одной задачи компоненты. Для этого, однако, необходимо, чтобы описание диалога содержало соответствующую информацию о задачах.

Поднимающиеся исследователями вопросы качества ПИ убеждают, что вмешательство человека на данном этапе необходимо. Ситуация аналогична ситуации при применении разработки, основанной на моделях (MDD, [2]), когда создана PIM - модель, независимая от реализации, и требуется создать и реализовать PSM - частную модель. Воспроизведённый по описанию диалога ПИ так или иначе будет представлять собой исполняемый код (например, для виртуальной машины, входящей в состав СУИП). К этому коду применимы все требования к обычным программам. Как минимум, необходимы механизмы отладки и доводки ПИ. Полученные при этом замечания могут привести к изменениям не только описания диалога, но и более абстрактных описаний. Замечания так же могут быть получены при исполнении ПИ на виртуальной машине в составе СУИП. Таким образом, для обеспечения максимальной эффективности СУИП на основе формального описания диалога должна охватывать все этапы получения ПИ.

Улучшение технологии

Рассмотрим отдельные моменты технологии, улучшения которых могут повысить её эффективность.

Если принято решение о создании собственной СУИП, то необходимо синхронизировать процесс разработки ФЯ и СУИП. Для этого желательно использовать единый процесс конструирования (например, спиральную или инкрементную модель); по результатам каждого этапа/итерации производить совместное тестирование прототипа. В большинстве случаев это может снизить риски и потери времени, однако не является необходимым.

ПИ имеет две основные составляющие: форму (непосредственно доступную пользователю) и логику. Эти составляющие описывают два различных, но связанных уровня абстракции взаимодействия пользователя с системой, которые следует описать одновременно и поддерживать целостность этого описания. Эти уровни нельзя объединить в один или отбросить, о чём предупреждает метамодель ARCH. Если объединить уровни, то пропадёт уровень "представление", что приведёт к жёсткой привязке визуальных компонентов к диалогу и сделает невозможным применение рассматриваемой технологии. Если не рассматривать уровень "диалог", то, помимо невозможности применения технологии, реализация ФЯ сольётся с реализацией диалога ПИ, что сделает модификацию интерактивной системы крайне дорогостоящей. Обобщая сказанное можно заявить, что невозможно применить рассматриваемую технологию к интерактивной системе, если к ней не применима метамодель ARCH.

Технология подразумевает создание более чем двух рассмотренных выше уровней описания системы, прежде чем будет сгенерирован конечный ПИ. Для обеспечения оптимальности здесь необходимо пронести информацию о требованиях к системе через все уровни описания. В реальной ситуации информацию невозможно собрать единовременно на первом уровне описания системы (он может быть для этого просто не предназначен). В этом случае необходимо избежать дублирования информации. Оба требования могут быть реализованы только при условии сохранения всей информации (в том числе семантики описания) в структурированном виде. Имеет смысл создать единое для всех уровней хранение информации. Схематично это, а так же отображение результатов этапов создания ПИ по рассматриваемой в работе схеме на уровни метамодели ARCH, показано на рисунке 1. По сравнению с СУИП, взятой за основу в [3], данная схема позволяет более эффективно использовать информацию с различных этапов создания ПИ и больше подходит для разработки, основанной на моделях MDD.

Рисунок 1 - Схема процесса реализации ПИ

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

В качестве одной из основ декомпозиции можно рассматривать поддержку построения истории действий пользователя на этапе описания диалога. Конкретный вид истории действий зависит от вида диалога, как правило, это дерево элементарных действий пользователя. Задав иерархию действий (т.е. идя от конечных требований), можно выделить уровни описания диалога. Другой основой декомпозиции могут являться уровни взаимодействия интеракторов [16], если рассматривать их создание как отображение детализированной логики диалога. Проводя аналогии с 7-уровневой моделью взаимодействия открытых систем ISO-OSI можно выделить подобные уровни во взаимодействии интеракторов и, как следствие, в порождающей их логике диалога.

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

Заключение

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

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

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

Предложено введение уровней описания логики диалога и два основания вертикальной декомпозиции описания диалога.

Литература

1. Клименко, С. Графические интерфейсы и средства их проектирования [Электронный ресурс] / С. Клименко, В. Уразметов // Способ доступа: URL: http://bolizm.ihep.su/report/UIDS-UIMS/ToC.html, Москва, 1996 г.

2. Tracy Gardner, Explore model-driven development (MDD) and related approaches: A closer look at model-driven development and other industry initiatives [Электронный ресурс] / Tracy Gardner, Larry Yusuf // Способ доступа: URL: http:// www.ibm.com/ developerworks/ library/ mdd1, 2006 г.

3. Конюхова, О.В. Графический пользовательский интерфейс для автоматизированных систем раскроя изделий сложной формы [Текст]: автореф. к.т.н. / О.В. Конюхова. - Орёл, ОрёлГТУ, 2006

4. Stephanie Wilson, User interface design: from work tasks to interactive system designs (tutorial notes) [Текст] / Stephanie Wilson, Peter Johnson // Способ доступа: URL: http://citeseer.ist.psu.edu/164321.html, London, 1994 г.

5. Bass L., A reference model for interactive system construction. / Bass L., Coutaz J., Unger C. // EWHCI'92. - 1992. -, St. Petersburg, P. 23-30.

6. John Bonnie E., The GOMS family of user interface analysis techniques: cjmparsion and contrast / John Bonnie E., David Kieras E. // ACM Transactions on computer - human interaction, vol.3, no.4, december 1996, P.320-351

7. User Action Notation (UAN). [Электронный ресурс]. // Способ доступа: URL: http:// www.it.bton.ac.uk/ staff/teaching /notes/UAN.html

8. Хоар, Ч. Взаимодействующие последовательные процессы [Текст]: [пер. с англ] / Хоар Ч.; М.:Мир, 1989.-264 с., ил. ISBN 5-03-001043-2 (русск.), ISBN 0-13-153271-5 (англ.)

9. Dieter Neumann, Data-oriented Dialogue specification [Текст] / Способ доступа: URL: http://citeseer.ist.psu.edu/103135.html, Germany

10. Wolfram Clauss, Dynamic Dialog Management [Текст] / Wolfram Clauss, Jana Lewerenz, Bernhard Thalheim // Способ доступа: URL: http://osm7.cs.byu.edu/ER97/workshop4/clt.html

11. Scott W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process / John Wiley & Sons, ISBN#: 0471202827

12. Guy Genilloud, On the Abstraction of Objects, Components and Interfaces [Текст] / Способ доступа: URL: http://citeseer.ist.psu.edu/311609.html, Switzerland

13. Кватрани, Т. Визуальное моделирование с помощью Rational Rose 2002 и UML. [Текст] : [пер. с англ.] / Т. Кватрани. - М.: Издательский дом "Вильямс", 2003. - 192 с.: ил. - Парал. тит. англ. ISBN 5-8459-0425-0 (рус).

14. Разработка САПР в 10 кн. Кн. 5. Организация диалога в САПР [Текст]: практ пособие / В.И. Артемьев, В.Ю. Строганов; под ред. А.В. Петрова. - М.: высш. Шк., 1990. - 158 с.: ил. ISBN 5-06-000742-1

15. Гордиенко, А.П. Построение графического пользовательского интерфейса в виде иерархии интеракторов. [Текст] / А.П. Гордиенко / Актуальные вопросы построения информационных систем: Материалы международной научно-технической конференции Информационные технологии в науке, образовании и производстве (ИТНОП). - Орёл: изд-во ОрёлГТУ, 2004, Том 5. - С. 110-116

Размещено на Allbest.ru