Разработка пользовательского интерфейса комплексной системы видеомониторинга

ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ЛОГИСТИКА В СТРОИТЕЛЬСТВЕ

УДК 004.5

А.Н. Алфимцев, Д.А. Локтев, А.А. Локтев*

ФГБОУВПО «МГТУ им. Н.Э. Баумана», *ФГБОУВПО «МГСУ»

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

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

Ключевые слова: адаптивный пользовательский интерфейс, онтологический подход, графический интерфейс, окно-контейнер, оценка эргономичности, система видеомониторинга.

Одной из наиболее актуальных задач, которая относится к двум приоритетным направлениям развития науки, технологии и техники в Российской Федерации, определенным Указом Президента Российской Федерации № 899 от 7 июля 2011 г. «В целях модернизации и технологического развития российской экономики и повышения ее конкурентоспособности»: безопасность и противодействие терроризму, информационно-телекоммуникационные системы, — является задача создания системы видеомониторинга и распознавания объектов в режиме реального времени, способная функционировать как в виде локального, так и в виде сетевого программно-аппаратного комплекса. Интеллектуальная комплексная система видеомониторинга должна содержать подсистемы, каждая из которых решает определенные задачи и способствует решению задач другими частями комплекса, для объединения различных приложений, процедур и подпрограмм в единый комплекс необходимо иметь современную многонаправленную систему программно-пользовательских интерфейсов.

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

Для создания пользовательского интерфейса необходимо продумать диалоги и задачи пользователя, WIMP — окно, значок, меню, манипулятор1 — интерфейс, формирование текстов программы, применяемые графические сцены, а также связь разрабатываемого интерфейса с прикладной программой. Характеристики пользователей предлагается использовать в качестве критериев интерфейсной адаптации [2, 3], их условно можно разделить на следующие смысловые группы [3]: демографические показате-

1 Window, Icon, Menu, Pointing device.

ли, индивидуально-психологические особенности, психомоторные качества, когнитивные способности, подготовленность и квалификация, мотивация, характер системного взаимодействия с программными приложениями. Такой подход позволяет добиться высокой производительности действий пользователя через улучшение эргономичности и быстродействия интерфейса [4].

При проектировании пользовательского интерфейса выделяются три основных подхода. Инженерно-технический подход создания графического интерфейса рассматривается на примере методики алгоритмического моделирования GOMS2 [5]. Согласно этой методике для достижения цели задача разбивается на подцели, при этом математически определяются наиболее оптимальные пути решения задачи. Недостатком такого подхода является сложность в анализе умственной деятельности пользователя.

Когнитивный подход к проектированию интерфейса рассматривает субъект труда как центральную фигуру процесса взаимодействия с системой [3]. Рассматривая процессы и закономерности восприятия, переработки информации и принятия решения, когнитивная психология выявила, что на функционирование системы влияет качество предоставления информации с точки зрения возможностей пользователя. Но учет только процессов восприятия и переработки информации оказался недостаточным для проектирования эргономичного интерфейса [4].

Третий подход основан на использовании онтологии для представления используемых при проектировании интерфейса понятий, это позволяет более подробно описать проектируемый пользовательский интерфейс для последующего представления в машинном коде. Для применения такого подхода необходимо сформулировать систему понятий пользователя, которую можно разделить на систему понятий диалога и систему понятий задач пользователя [6]. Система понятий диалога — это система понятий, через которую выражаются входные и выходные данные, осуществляется интеллектуальная поддержка пользователя в процессе его взаимодействия с программным средством. Система понятий задач пользователя описывает задачи, которые он может решить, используя программное средство, при этом отдельная задача может состоять из набора подзадач. Согласно онтологическому подходу каждый элемент WIMP-интерфейса определяется своим типом, множеством параметров, событий и функций [7]. Основными элементами интерфейса, предназначенными для группировки в связанные группы и классы, являются элементы типа «окно-контейнер», элементы для операций ввода/вывода данных и вызова команд (элементы управления), элементы для описания. Каждый параметр элемента интерфейса состоит из имени и типа его возможного значения. С каждым элементом интерфейс связывается множеством его событий, которые определяют реакции элемента интерфейса при его взаимодействии с пользователем. Для описания множества возможных действий над элементом интерфейса используются функции.

Существуют различные виды представления выходной информации: текст, таблицы, графики, диаграммы. Наиболее эффективным средством представления информации являются графические методы ее отображения [8]. Основные характеристики представления информации для ее передачи в виде графических сцен [9], которые включают базовое графическое изображение, простой и составной фрагменты и примитивы. Базовое графическое изображение (база) — произвольный графический рисунок, схема, эскиз и т.д., разбитый на фрагменты и являющийся основой для нанесения на него различных вспомогательных изображений. База имеет следующие атрибуты: имя, образ, точку отсчета, формат времени. Фрагмент задает разбиение базы на компоненты, которые могут быть простыми и составными. Примитив — вспомогательное изображение, которое наносится на базу и может передвигаться по заданному маршруту и изменять свое изображение при наложении на другие примитивы.

2 От англ. «Goals — Operators — Methods — Selection rules» — «Цели — Действия — Методы — Правила выбора».

Любой диалог пользователя с программным средством ведется в соответствии с некоторым сценарием, который зависит от типа пользователей, их требований, функций прикладной программы и является, соответственно, компонентом пользовательского интерфейса. Система понятий, связанная со сценарием диалога, определяет множество возможных состояний диалога и действий, которые выполняются в каждом состоянии. Состояние диалога определяется событием, которое возникает в элементе интерфейса. Действия задают последовательность инструкций, которые выполняются в ходе реакции на событие.

Непосредственное взаимодействие между интерфейсным приложением и кодом прикладной программы происходит с помощью вспомогательных объектов, которые предоставляют им доступ к функциям друг друга. Каждый программный интерфейс описывает модель взаимодействия с программой, а также список функций, предоставляемых данным интерфейсом [10, 11]. Множество моделей взаимодействия, определенное в данной работе, состоит из локальной и распределенной модели взаимодействия.

Рассматриваемый онтологический подход включает в себя построение нескольких моделей онтологий [7].

Модель онтологии системы понятий диалога (ОСПД) описывает структуру терминов системы понятий диалога в виде связей между ними. ОСПД = <ИмяСистемыПонятий, ГруппыТерминов>, где ИмяСистемыПонятий — имя системы понятий диалога, ГруппыТерминов — множество групп терминов, ГруппыТерминов = {ГруппаТерминов;}.

Модель онтологии задач пользователя (ОЗП) описывает задачи, которые он может решить с помощью программного средства: ОЗП = <ИмяОбщейЗадачи, Задачи>, где ИмяОбщейЗадачи - имя общей задачи, Задачи — задачи пользователя, т.ч. Задачи = <ТипМножества, {Задача;}>, где ТипМножества — тип множества, Задача; — задача пользователя.

Модель онтологии WIMP-интерфейсов состоит из двух уровней: метаонтологии, предназначенной для описания структуры интерфейсных элементов и непосредственно онтологии, содержащей описание множества интерфейсных элементов в соответствии со структурой, представленной в метаонтологии.

Модель метаонтологии WIMP-интерфейсов (ОПР) — это множество элементов интерфейса (Controls), которые связаны с событиями (Events^, задающими множество возможных реакций.

При описании графических статических и динамических сцен на плоскости используются следующие типы переменных: Z — множество всех целых чисел; N — множество всех натуральных чисел; R — множество всех действительных чисел; Strings — множество всех строк; Images — множество всех графических рисунков; Colors — множество всех цветов; Coords = {(X, Y): X, YeZ} — множество всех координат; Bool — логический тип; LineTypes — множество всех толщин линий; Figures — множество всех геометрических фигур.

Модель онтологии сценария диалога (ОСД) описывает начальное окно, которое появляется на экране монитора после запуска программного средства, структуру реакций на события, типы конструкций, доступных при описании реакций на события, типы инструкций, доступных при описании реакций на события, а также стандартные функции диалога. ОСД характеризуется парой <StartWindow, States>, где StartWindow — начальное окно, которое появляется на экране после запуска программного средства, StartWindow является элементом интерфейса типа «окно-контейнер».

Модель онтологии связи интерфейса с прикладной программой описывает структуру программных интерфейсов Interfaces, используемых при взаимодействии интерфейса и прикладной программы.

Проектируемая система управления должна состоять из симметричной и несимметричной частей; иметь модульную структуру; возможность настройки отдельных

компонентов и пополнения базы знаний о пользователях. Несимметричная часть настраивается в соответствии с данными о пользователе, которые получены при прохождении тестов при устройстве на работу (скоростью реакции, выбором наиболее удобной части экрана, внимательностью пользователя — для настройки количества одновременно показываемых камер).

Таким образом, интерфейс можно представить в виде (рис. 1).

Компьютеризированная система

Модуль взаимодействия

-♦-

Адаптивный интерфейс

Работа пользователя

-1 %

Генерация выходной информации

Система контроля процессом взаимодействия с пользователем

У Т

Состояние модели пользователя

База знаний о пользователе

Анализ входной информации

Пользователь

Рис. 1. Схема адаптивного интерфейса

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

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

2. Здание в 3D виде. Наружные камеры по фасадам, внутренние—по этажам. Выбрать или указателем, или путем ввода в командную строку номера интересующего участка.

3. Этаж с подсветкой номеров помещений-участков и номеров камер. Здесь же нужно, чтобы был показан уровень доступа в каждое помещение (возможно, подсветка по периметру).

4. Возможна организация картинок с камеры по помещениям и по маршрутам (вход — лифт — туалет, комната охраны — вход и т.д.).

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

ВЕСТНИК

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

7. Когда появляется картинка с одной камеры или с нескольких, то работает режим распознавания. Возможно, несколько режимов: наблюдения, распознавания, анализа (сравнения), когда выводятся различные данные об объектах, в т.ч. и за предыдущие даты.

8. После работы с изображением одиночной камеры появляется возможность работы с БД, тут нужно строгое разграничение, и в базу можно только добавлять.

9. Ведется журнал log-данных всех происшествий, всех перемещений распознанных объектов, а также всех действий оператора-охранника.

10. В случае нераспознавания объекта отдельные кадры съемки сохраняются, объект отмечается и передается от камеры к камере.

11. Отмечаются те участки и те помещения, где нет камер, так как, попадая туда, объект после выхода должен опознаваться заново.

В первом окне (рис. 2) показан вид всей охраняемой территории: здания и окружающей его территории, который разбит на пронумерованные сегменты, причем здание относится к отдельному сегменту. Перейти в другое окно возможно с помощью кнопки «Перейти в другое окно» и дальнейшего ввода номера нужного окна в командную строку и нажатия Enter либо с помощью кнопок «Назад «Вперед

Перейти в другое окно

Режим активного выделения

Вид всей охраняемой территории

1 I 2 I 3

Здание

Строка состояния

Командная строка

Сигнал тревоги

Рис. 2. 1-е окно пользовательского интерфейса

Во втором окне может быть представлен вид здания либо в нормальном режиме, либо в режиме моделирования, либо в режиме прозрачности (рис. 3).

В третьем окне (рис. 4) показан план выбранного ранее этажа здания с камерами. Возможно перейти к просмотру по камерам, комнатам, маршрутам.

После перехода на просмотр отдельной камеры применяется метод распознавания Виола — Джонса с применением примитивов Хаара. Далее возможно 4 варианта развития событий: 1-й вариант — человек распознан как известный

Если человек распознан как уже внесенный в БД (рис. 5), то возможно выбрать любого из известных по номеру (если их несколько) и управлять его доступом к помещениям. 2-й вариант — человек распознан как не внесенный в БД, то возможно выбрать любого из неизвестных по номеру, изменить освещение в комнате для попытки распознать его как известного либо внести в БД. 3-й вариант — на кадре есть входящие

и не входящие в БД лица, в этом случае можно выбрать внесенные и не внесенные в БД объекты по номеру, изменить освещение, посмотреть данные об известном человеке. 4-й вариант: распознавания не происходит, т.е. либо никаких объектов в поле зрения камеры нет, либо невозможно провести распознавание объекта. В этом случае оператору предоставляется возможность изменить освещение и попытаться распознать еще раз либо посмотреть соседние камеры.

Рис. 3. 2-е окно пользовательского интерфейса — режим прозрачности

Перейти в другое окно

Режим активного выделения камеры

План здания с пронумерованными камерами

Il I и

Строка состояния

Ввод номера

Сигнал тревоги

Просмотр по комнатам

Просмотр по маршрутам

Рис. 4. 3-е окно пользовательского интерфейса

Описывая реализованный интерфейс с помощью онтологий можно отметить, что множество Controls состоит из следующих подмножеств, Controls = Base u Window controls u Windows.

Base содержит множество вспомогательных элементов интерфейса. Base= {Элемент WIMP, Параметры шрифта}.

Window controls содержит множество элементов интерфейса, описывающих оконные элементы управления. Window controls = {Кнопка управления, Поле ввода, Статический текст, Панель статуса, Кнопка с раскрывающимся списком}.

ВЕСТНИК

Рис. 5. 5-е окно — человек распознан как известный

Windows содержит множество элементов интерфейса, описывающих окна. Windows = Окно.

Элемент WIMP = <Controltype^ ^Л/Го, Parameters^ ^Л/Го, Events^ ^Л/Го,

J * Элемент WIMP' Элемент WIMP' Элемент WIMP'

Functions^^ WIMP> — элемент интерфейса, описывающий общие для окон и элементов управления свойства.

Параметры шрифта = <Controltype , , Parameters , , Events

1 1 А i ^ 1 параметры шрифта параметры шрифта^ параметры

, , Functions , > — элемент интерфейса, описывающий параметры шрифта.

шрифта параметры шрифта

Панель статуса = <Controltype , Parameters , Events ,

J J L панель статуса7 панель статуса7 панельстатуса7

Functions > — элемент интерфейса, описывающий элементы управления, обеспечи-

панель статуса

вающие вывод информации о текущем состоянии объектов.

Кнопочный элемент=<Controltype

j r i

Functions

кнопочный элемент

, Parameters „ , Events

кнопочный элемент кнопочный элемент кнопочный

> — элемент интерфейса, описывающий свойства, общие

элемент

для элементов управления, служащих для инициирования каких-либо действий или для изменения свойств объектов.

Кнопка управления = <Controltype , Parameters , Events

А 1 кнопка управления7 кнопка управлений кнопка

, Functions > — элемент интерфейса, описывающий свойства, общие

управления кнопка управления

для кнопок, предназначенных для запуска команд или операций.

Кнопка с раскрывающимся списком — <Controltype , Parameters

кнопка со списком кнопка со

, Events , Functions > — элемент интерфейса, описывающий

списком кнопка со списком кнопка со списком

свойства, общие для всех кнопок, предоставляющих возможность выбора вариантов из некоторого множества.

Поле ввода = < Controltype , Parameters , Events , Functions

J г поле ввода' пoлe ввода' поле ввода' поле вво-

да> — элемент интерфейса, описывающий свойства области, в которой пользователь

может вводить или редактировать текст.

Статический текст = <Controltype „ , Parameters „ , Events

статический текст статический текст

статическии

, Functions „ > — элемент интерфейса, описывающий свойства области те-

текст статический текст

ста, используемой только для отображения информации.

Окно = <Controltype , Parameters , Events , Functions > — элемент интерокно окно окно окно

фейса, описывающий свойства области экрана, с помощью которой пользователь имеет возможность получить визуальное представление определённого аспекта решаемой задачи.

Метод GOMS позволяет оценить время выполнения той или иной задачи пользователем и рассчитать быстродействие всего интерфейсного приложения. Для этих

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

M = 1.35 c — время, необходимое пользователю для того, чтобы умственно подготовиться к следующему шагу (ментальная подготовка).

H = 0.4 c — время, необходимое пользователю для перемещения руки с клавиатуры на манипулятор и с манипулятора на клавиатуру.

Pi — время, необходимое пользователю для указания какой-либо позиции на экране монитора (i зависит от расположения полей и кнопок на форме).

K = Ks = 0.28 c — время, необходимое для нажатия клавиши клавиатуры K либо манипулятора Ks. Для опытного (зависит от скорости печати пользователя на компьютере) пользователя значение K может составлять 0,08 с, для обычного пользователя — 0,2 с, для среднего неопытного пользователя — 0,28 с, для начинающего — 1,2 с.

Рассмотрим пример, где человеку, входящему в здание и уже заранее внесенному в базу данных, требуется разрешить доступ к двери 1 комнаты X на этаже N и опишем его действия в каждом окне:

1) в первом окне, быстродействие получается из следующих действий: MH MP1Ks MH MK MK,

1 s '

где MH — перемещение руки к мыши; MP1Ks — перемещение курсора к полю для ввода нужного сектора и его выбор; MH — перемещение руки от мыши к клавиатуре; MK — набор единичного значения; MK — Enter;

2) во втором окне:

MH MP2Ks MH MK MK,

2 s '

где MH — перемещение руки к мыши; MPjKs — перемещение курсора к полю для ввода нужного этажа и его выбор; MH — перемещение руки от мыши к клавиатуре; MK — набор единичного значения; MK — Enter;

3) в третьем окне:

MH MP3Ks MP4Ks MH MK MK,

3 s 4 s '

где MH — перемещение руки к мыши; MP3Ks — перемещение курсора к кнопке «Выбрать комнату» и ее нажатие; MP4Ks — перемещение курсора к полю для ввода номера комнаты и его выбор; MH — перемещение руки от мыши к клавиатуре; MK — набор единичного значения; MK — Enter;

4) в четвертом окне: MH MP5Ks MH MK MK,

5 s '

где MH — перемещение руки к мыши; MP5Ks — перемещение курсора к полю для ввода нужной камеры и его выбор; MH — перемещение руки от мыши к клавиатуре; MK — набор единичного значения; MK — Enter;

5) в пятом окне:

MH MP6K MP7K MH MK MK MH MP8K MP9K MP10K ,

6s7s 8 s 9 s 10 s'

где MH — перемещение руки к мыши; MP6Ks — перемещение курсора к кнопке «Распознанных» и ее нажатие; MP7Ks — перемещение курсора к полю для ввода номера человека и его выбор; MH — перемещение руки от мыши к клавиатуре; MK — набор единичного значения; MK — Enter; MP8Ks — перемещение курсора к кнопке «Управление доступом» и ее нажатие; MP9Ks — перемещение курсора к кнопке «Разрешить» и ее нажатие; MP10Ks — перемещение курсора к кнопке «Дверь 1» и ее нажатие. С помощью закона Фитса [10] можно вычислить значения P;: R

где для одномерного примера S — размер объекта вдоль линии перемещения курсора обозначается; D — дистанция от начальной позиции курсора до объекта.

Для двумерных целей обычно можно получить корректное приближенное значение времени, необходимого для перемещения курсора к объекту, используя в качестве параметра S наименьшее из значений размеров объекта по горизонтали или по вертикали. Константы a и b устанавливаются опытным путем по параметрам производительности человека. Для приближенных вычислений используем следующие значения констант в уравнении закона Фитса (1): a = 50, b = 150. При этом получим:

P = P2= P5 = 50 +150*log2(39/3+1) = 600 мс = 0,6 c;

P3= 50 +150*log2(50/6+1) = 430 мс = 0,43 c; P4=50+150*log2(30/3+1) = 440 мс = 0,44 c;

P6= 50 +150*log2(80/6+1) = 590 мс = 0,59 c; P7= 50+150*log2(15/3+1) = 580 мс = 0,58 c;

P8=50 + 150*log2(55/6+1) = 580 мс = 0,58 c; P9=50 + 150*log2(10/5+1) = 280 мс = 0,28 c;

P10=50 +150*log2(10/5+1)= 280 мс = 0,28 c.

Таким образом, сумма всех действий пользователя во всех окнах будет равна: MH MP,K MH MK MK + MH MP_K MH MK MK + MH MP,K MPK MH MK MK + MH

1 s 2 s 3 s 4 s

MPK MH MK MK + MH MP K MP7K MH MK MK MH MPSK MP0K MP,„K = 55,78 с.

5s 6 s 7 s 8s9s10s

То есть, быстродействие интерфейса в данном примере составляет приблизительно 1 мин.

Таким образом, в ходе проведения исследования были сформулированы основные требования и концепция, проанализированы существующие методологии проектирования пользовательского интерфейса и реализован на основе онтологического подхода человеко-машинный интерфейс, который связывает все программные модули комплексной системы видеомониторинга и распознавания объектов в единый комплекс. Было рассчитано быстродействие спроектированного интерфейса на основе метода GOMS. В ходе проведения тестовых испытаний реализованного интерфейсного комплекса была использована серия изображений, полученных на конференции ИФО МГСУ

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

Библиографический список

1. Данилов О. Альтернативные интерфейсы // Компьютерное обозрение. 1999. Вып. 4. С. 14—17.

2. АлфимцевА.Н., ДевятковВ.В. Интеллектуальные мультимодальные интерфейсы. Калуга : Полиграф-Информ, 2011. 328 с.

3. Костюк В.И., Ходаков В.Е. Системы отображения информации и инженерная психология. К. : Высш. шк., 1977. 192 с.

4. ЗинченкоВ.П., МоргуновЕ.Б. Введение в практическую эргономику. М. : МИРЭА, 1990. 72 с.

5. Артемьева И.Л. Многоуровневые математические модели предметных областей // Искусственный интеллект. 2006. Т. 4. С. 85—94.

6. Грибова В.В., Тарасов A.B. Модель онтологии предметной области «Графический пользовательский интерфейс» // Информатика и системы управления. 2005. № 1(9). С. 80—91.

7. Грибова В.В., Клещев A.C. Концепция разработки пользовательского интерфейса на основе онтологии // Вестник ДВО РАН. 2005. № 6. С. 123—128.

8. Bardram J. Collaboration, Coordination, and Computer Support: an activity theoretical approach to the design of Computer Supported Cooperative Work, Ph.D. thesis, University of Aarhus, 1998. 84 р.

9. Kaptelinin V. "Activity Theory: Implications for Human-Computer Interaction" II "Context and Consciousness: Activity Theory and Human-Computer Interaction". Cambridge (MA), MIT Press, 1996. 76 р.

10. Langley P. User modeling in adaptive interfaces // Proc. of the Seventh Intern.Conf on User Modeling. 1997. P. 357—370.

11. Puerta A.R. Issues in Automatic Generation of User Interfaces in Model-Based Systems. Computer-Aided Design of User Interfaces, ed. by Jean Vanderdonckt. Presses Universitaires de Namur, Namur, Belgium, 1996. P. 323—325.

Поступила в редакцию в сентябре 2012 г.

Об авторах: Алфимцев Александр Николаевич—кандидат технических наук, доцент кафедры информационных систем и телекоммуникаций, ФГБОУ ВПО «Московский государственный технический университет им. Н. Э. Баумана» (ФГБОУ ВПО «МГТУ им. Н. Э. Баумана»), 105005, г. Москва, 2-я Бауманская ул., д. 5, (499) 267-65-37, kaf@iu3.bmstu.ru;

Локтев Даниил Алексеевич — студент факультета информатики и системы управления, ФГБОУ ВПО «Московский государственный технический университет им. Н.Э. Баумана» (ФГБОУ ВПО «МГТУ им. Н.Э. Баумана»), 105005, г. Москва, 2-я Бауманская ул., д. 5, (499) 267-65-37, loktevdan@yandex.ru;

Локтев Алексей Алексеевич — кандидат физико-математических наук, доцент кафедры теоретической механики и аэродинамики, ФГБОУ ВПО «Московский государственный строительный университет» (ФГБОУ ВПО «МГСУ»), 129337, г. Москва, Ярославское шоссе, д. 26, (499) 183-24-01, aaloktev@yandex.ru.

Для цитирования: АлфимцевА.Н., ЛоктевД.А., ЛоктевА.А. Разработка пользовательского интерфейса комплексной системы видеомониторинга // Вестник МГСУ 2012. № 11. С. 242—252.

A.N. Alfimtsev, D.A. Loktev, A.A. Loktev

DEVELOPMENT OF A USER INTERFACE FOR AN INTEGRATED SYSTEM OF VIDEO MONITORING

An important problem in development of an integrated multi-functional system of video monitoring and recognition of objects is the problem of an interface that would provide a link between various programme applications of the system and between applications and users. This interface must be configured with reference to the object that the system of video monitoring will be attached to, and it must be based on data transmission channels, skills and competences of users. The authors specify the basic requirements to the software and the user interface. The concept is implemented as a self-software facility that has successfully passed a test in ergonomics and speed.

In this project, an attempt is made to develop and implement a user interface that assures the best relationship between individual modules of an integrated system and between the system and the user. Therefore, the interface is to meet the following requirements: flexibility, volatility, mobility, and frequency of principal forms and templates.

Design and development of a user interface incorporates development of pattern dialogues, resolution of user problems, WIMP (window, icon, menu, pointing device), applied graphic scenes, as well as connection of the interface to the application. The characteristics of users are employed as the criteria of the interface adaptability; they can be divided into the following semantic groups: demographic indicators, individual psychological features, psychomotor qualities, cognitive abilities, training and qualification, motivation, nature of the system interaction with software applications. This approach assures a high productivity of user actions through improvement of ergonomics and better performance of the interface.

Key words: adaptive user interface, ontological approach, graphical interface, window container, ergonomics, system of video monitoring.

References

1. Danilov O. Al'ternativnye interfeysy [Alternative Interfaces]. Komp'yuternoe obozrenie [Computer Overview]. 1999, no. 4, pp. 14—17.

2. Alfimtsev A.N., Devyatkov V.V. Intellektual'nye mul'timodal'nye interfeysy [Intelligent Multi-modal Interfaces]. Kaluga, Poligraf-Inform publ., 2011, 328 p.

3. Kostyuk V.I., Khodakov V.E. Sistemy otobrazheniya informatsii i inzhenernaya psikhologiya [Systems of Data Display and Engineering Psychology]. Vyssh. shk. publ., 1977, 192 p.

4. Zinchenko V.P., Morgunov E.B. Vvedenie vprakticheskuyu ergonomiku [Introduction into Practical Ergonomics]. Moscow, MIREA Publ., 1990, 72 p.

5. Artem'eva I.L. Mnogourovnevye matematicheskie modeli predmetnykh oblastey [Multilevel Mathematical Models of Subject Areas]. Iskusstvennyy intellect publ., 2006, vol. 4, pp. 85—94.

6. Gribova V.V., Tarasov A.B. Model' ontologii predmetnoy oblasti «Graficheskiy pol'zovatel'skiy interfeys» [Ontology Model of the Subject Area "Graphical User Interface"]. Informatika i sistemy uprav-leniya [Informatics and Control Systems]. 2005, no. 1(9), pp. 80—91.

7. Gribova V.V., Kleshchev A.C. Kontseptsiya razrabotki pol'zovatel'skogo interfeysa na osnove ontologii [Concept of Development of a User Interface on the Basis of the Ontology]. Vestnik DVO RAN [Proceedings of the Far Eastern Section of the Russian Academy of Sciences]. 2005, no. 6, pp. 123—128.

8. Bardram J. Collaboration, Coordination, and Computer Support: an Activity Theoretical Approach to the Design of Computer Supported Cooperative Work. University of Aarhus, 1998, 84 p.

9. Kaptelinin V. "Activity Theory: Implications for Human-Computer Interaction" II "Context and Consciousness: Activity Theory and Human-Computer Interaction". Cambridge (MA), MIT Press, 1996, 76 p.

10. Langley P. User Modeling in Adaptive Interfaces. Proc. of the Seventh Intern. Conf on User Modeling, 1997, pp. 357—370.

11. Puerta A.R. Issues in Automatic Generation of User Interfaces in Model-Based Systems. Computer-Aided Design of User Interfaces, ed. by Jean Vanderdonckt. Presses Universitaires de Namur, Namur, Belgium, 1996, pp. 323—325.

About the authors: Alfimtsev Aleksandr Nikolaevich — Candidate of Technical Sciences, Associate Professor, Department of Information Systems and Telecommunications, Moscow State Technical University named after N.E. Bauman» (MSTU), 5 2nd Baumanskaya st., Moscow, 105005, Russian Federation; kaf@iu3.bmstu.ru; +7 (499) 267-65-37;

Loktev Daniil Alekseevich — student, Faculty of Informatics and Control Systems, Moscow State Technical University named after N.E. Bauman» (MSTU), 5 2nd Baumanskaya st., Moscow, 105005, Russian Federation; loktevdan@yandex.ru; +7 (499) 267-65-37;

Loktev Aleksey Alekseevich — Candidate of Physical and Mathematical Sciences, Associate Professor, Department of Theoretical Mechanics and Aerodynamics, Moscow State University of Civil Engineering (MGSU), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; aaloktev@yan-dex.ru; +7 (499) 183-24-01.

For citation: Alfimtsev A.N., Loktev D.A., Loktev A.A. Razrabotka pol'zovatel'skogo interfeysa kom-pleksnoy sistemy videomonitoringa [Development of a User Interface for an Integrated System of Video Monitoring]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering]. 2012, no. 11, pp. 242—252.