Автоматизация контроля за соблюдением разработчиком формализованных требований к построению графического интерфейса пользователя

Рясков А.С.

АВТОМАТИЗАЦИЯ КОНТРОЛЯ ЗА СОБЛЮДЕНИЕМ РАЗРАБОТЧИКОМ ФОРМАЛИЗОВАННЫХ ТРЕБОВАНИЙ К ПОСТРОЕНИЮ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

Волгоградский государственный технический университет, г. Волгоград

В статье рассматривается автоматизация проверки графического интерфейса пользователя по формализованным требованиям, выдвигаемым в организации (usability guidelines). Обосновывается необходимость следования этим правилам, рассказывается о возникающих при этом проблемах. Описывается разработанный прототип программного средства для автоматизации проверки графического пользовательского интерфейса на соответствие требованиям.

Ключевые слова графический интерфейс пользователя, удобство использования, юзабилити, usability, usability guidelines.

Обеспечение удобства и единообразия пользовательского интерфейса (ПИ) во всех продуктах компании - это важная задача, стоящая перед корпорациями и сообществами энтузиастов по разработке ПО. Наличие единообразия, соблюдения некоторых требований в разработке интерфейса пользователя является важным элементом успеха того или иного проекта. Значимость этой составляющей раскрывается с нескольких сторон. С одной стороны, при соблюдении правил создаётся «лицо» продуктов компании. К примеру, продукты компании Apple стали узнаваемыми в том числе и за счёт активной работы по созданию графических интерфейсов, соответствующих некоторым единым требованиям. С другой стороны - единообразие пользовательского интерфейса - это гарантия хорошего восприятия продукта разных версий конечными пользователями. Если при выпуске новой версии программного продукта разработчики руководствовались теми же правилами построения графического интерфейса пользователя (ГИП), что и в предыдущей версии, то конечный пользователь сможет найти известные ему по предыдущему выпуску функции, прикладывая минимальные усилия.

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

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

* Магистрант кафедры «Программное обеспечение автоматизированных систем».

для достижения конкретных целей с заданной эффективностью, продуктивностью и удовлетворённостью в определённом контексте использования [1].

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

Формализованные требования к ПИ - требования, допускающие автоматизированную проверку. В составе требований могут содержаться сведения о количестве чего-либо, цветах, соотношении элементов между собой и т.п. Типичным примером является общее правило построения ПИ - «Не следует располагать больше 5-7 элементов в одном визуальном контейнере. Более 7 элементов рядом создают значительную умственную нагрузку» [2].

Неформализованные требования к ПИ - требования, которые невозможно проверить без участия человека. Эти требования не автоматизируются. Типичным примером является правило «Иконка на кнопке должна отражать суть действия, вызываемого по нажатию на неё» [2].

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

На данный момент, в ряде известных открытых проектов (Dolphin, Ko-pete, GNOME) соблюдение требований к построению ПИ проверяется старшими участниками сообщества. Каких-либо программ, автоматизирующих проверку не найдено.

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

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

Первый этап работы - создание прототипа программного средства, выполняющего проверку ГИП настольных (desktop) приложений. На данном этапе требовалось создать продукт с расширяемой архитектурой, в контексте которой было бы легко добавлять новые формализованные требования к ГИП.

В качестве библиотеки вспомогательных классов и функций (framework) с модулем ГИП была выбрана библиотека Qt4. Данный выбор был обусловлен кроссплатформенностью данной библиотеки, открытыми исходными кодами, а также широкой распространённостью в мире ПО (Qt используют Autodesk Maya, Skype, Oracle VM VirtualBox, KDE и другие продукты с открытыми и закрытыми исходными кодами).

Был разработан прототип инструмента для проверки графических Qt4-интерфейсов на соответствие требованиям, под названием POAS Usability Tool. Инструмент представляет собой элемент управления (widget), реализованный в виде разделяемой библиотеки, который встраивается в палитру элементов стандартного редактора графических форм библиотеки Qt4. Пользователь переносит этот элемент управления на форму приложения, которое он желает протестировать на соответствие требованиям или рекомендациям. Элемент не влияет на расположение других составляющих формы и является невидимым. Затем разработчик должен прописать вызов функции настройки данного элемента управления для конкретного приложения (одна строка исходного кода на языке С++ в конструкторе главного окна приложения). После компиляции тестируемого приложения в верхней части его окна появляется новое меню «Usability2L», с помощью которого вызывается диалог настроек и запуска проверок ГИП. Окно с результатами проверки тестового ГИП показано на рис. 1.

И Запуск проверок графического интерфейса

La-HH]

Для луч I Этот BQta

Название проверки Описание проверки *

Виджет GroupBox

Ш GroupBox3 Группа не имеет заголовка

[7] GroupBox4 В группе есть элементы, н управляем ые менеджером ком по

Вкладки TabWidget

Ш TabWidgetL На вкладках есть элемент, чеуправляе мый менеджером комг оновки

Метка QLabel

Ш Labell Надпись сделана прописн гми буквам

Е LabeB Надпись сделана шрифтогь с засечкам и (например, Times Nei Roman)

Е LabeW Надпись сделана шрифтогь с засечкам и (например, Times Nei Roman) с кеглем меньше 10

El Label5 Часть надписи не видно =

Менеджеры компоновк

№ Layoutl Элемент не связан ни с одним менеджером компоновки _

Общие проверки -

! Ошибка бб в duration: Элемен А Ошибка 67 в label_2: Виджет н< А Ошибка 68 в label_2: Элемент не свс

э Предупреждение! в duration: Возм<

ж с одним менеджером и в один менеджер с одним менеджером

>еки. Менеджеры компоновки Виджет QGroupBox представля |еджеры компоновки m путём задания префикс

»ботиться on *

Предупреждение2 в periodicType: Для лучшего взаимодействия рекомендуется делать

а редактируемым (при нау

Предупреждение 3 в from_city: Рекомендуется делать так, чтобы т<

е ввода был виден

взаимодействия рекомендуется делать заголовок списка редактируемы тратить время на поиск элемента, а сразу же вводить нужный вариэ! выполнить с помощью QComboBox::setEditable(bool editable].

5 и более элементов). : нажатия Enter о реализация автодополнения), |лендарь можно

Рис. 1. Результаты работы программного модуля

Данный прототип содержит порядка 30 общих проверок (рекомендаций по улучшению) ГИП, извлечённых текстологическим методом из известных книг по юзабилити [3-5].

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

Для добавления новых проверок в POAS Usability Tool требуется скопировать шаблонный файл исходного кода с проверками ГИП и изменить шаблонные проверки на необходимые. На низком уровне проверки пред-

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

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

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

Список литературы:

1. ISO-9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) [Электронный ресурс]. - 2011. - Режим доступа: http://www.it.uu.se/edu/course/homepage/acsd/vt09/ISO9241part11 .pdf.

2. Купер А. Об интерфейсе / А. Купер, Р. Рейман, Д. Кронин. - СПб.: Символ-Плюс, 2010. - 688 с.

3. Купер А. Психбольница в руках пациентов. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие / А. Купер. -М.: Символ-Плюс, 2005. - 336 с.

4. Раскин Дж. Интерфейс: новые направления в проектировании компьютерных систем / Дж. Раскин. - СПб.: Символ-Плюс, 2007. - 272 с.

5. Сеов С.К. Проектируем время. Психология восприятия времени в программном обеспечении / С. Сеов. - СПб.: Символ-Плюс, 2009. - 224 с.

ПРОБЛЕМЫ ПРИМЕНЕНИЯ АВТОМАТИЗИРОВАННЫХ ПРОГРАММНЫХ КОМПЛЕКСОВ УЧЕТА ТЕПЛОВОЙ ЭНЕРГИИ И ПУТИ ИХ РЕШЕНИЯ

Оренбургский государственный университет, г. Оренбург

В статье приведены причины внедрения и использования автоматизированных программных комплексов учета тепловой энергии, выявлены недостатки наиболее обширной АСКУЭ «Энергоресурсы» и намечены пути решения выявленных недостатков.

Ключевые слова автоматизация съема показаний, удаленный доступ, узел учета.

* Магистрант кафедры Промышленной электроники и информационной техники.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Рясков А. С.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Рясков А. С.