Варианты построения интерфейса программ: особенности и эволюция

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

В литературе предложены различные формулировки руководящих принципов проектирования интерфейса.

Как указывалось в общем контексте в ГОСТ Р ИСО/МЭК 9126−93, в настоящее время существует ряд систем комплексных показателей (моделей качества) разной степени завершенности, однако, принятую в стандартах модель качества не нужно абсолютизировать. Цель введения стандартов — стимулировать широкое практическое использование руководящих принципов, а также накопление опыта для их последующего уточнения и развития. Стандартизированная модель отражает, по крайней мере, минимальный набор обязательных (или общепризнанных) принципов.

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

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

Формально стандартизированность пользовательского интерфейса уместно связать с другими инфраструктурными субхарактеристиками качества программного продукта, такими, как соответствие (conformance) (в том числе и соответствие стандартам) и взаимозаменяемость (replaceability) (ГОСТ Р ИСО МЭК 9126−93). Выбор конкретного средства проектирования (языки быстрой разработки приложений, CASE-средства, конструкторы графических интерфейсов) может привести разработчика к необходимости придерживаться стандарта интерфейса, положенного в его основу.

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

Вводимые в ISO 9241−11 меры практичности организация-заказчик может использовать до разработки заказной системы в качестве общих рамок для определения требований по практичности, которым должна соответствовать будущая система и по которым будут проводиться приемочные испытания. Таким образом, создается основа для обеспечения полноты, измеримости и сопоставимости этих требований, что может косвенно оказывать позитивное влияние на качество проектируемого программного изделия.

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

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

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

Инструментарий для разработки интерфейса разделен на три группы, которые определяются следующим образом. В первую группу входит инструментарий для поддержки создания интерфейса написанием кода — UIMS и Toolkits; во вторую — интерактивные инструментальные средства, позволяющие сконструировать интерфейс из «заготовок» (кнопок, меню, полос прокрутки и т. д.), — Interface Builders; третий тип основан на создании интерфейса путем связывания отдельно созданных его компонент — Component Architectures.

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

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

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

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

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

Наряду с передачей сообщений пользователю в интерфейсе необходимо задание атрибутов, которые информацию не передают, но создают ему комфорт и удобство; их можно объединить общим термином дизайн интерфейса. К таким атрибутам относятся: расположение сообщений на экране, их размер, цвет и т. п., а также задание физических устройств ввода (клавиатура, манипуляторы, речевой ввод, машинное зрение и др.) и вывода (монитор, звук, фотографический вывод и др.). Таким образом, составной частью пользовательского интерфейса, неразрывно связанной с передачей сообщений, является определение формы сообщений.

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

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

Таким образом, в состав пользовательского интерфейса входят:

базисная система сообщений (система понятий предметной области);

система сообщений для пользователя;

система сообщений для прикладной программы;

средства обеспечения удобства и комфорта работы пользователя;

средства интеллектуальной поддержки пользователя;

средства управления взаимодействием пользователя и интерфейса.

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

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

В ряде трудов предложено начинать проектирование интерфейса с моделирования задачи и предметной области. Для этого пользователю предлагается на неформальном языке описать постановку задачи, из которой автоматически выделяются понятия предметной области и действия с ними. Следующими этапами является формализация полученной постановки задачи путем отсеивания ненужных элементов, организация классов выделенных элементов, задание области и типов их допустимых значений, действий над ними с целью создания полноценной модели предметной области. В качестве преимуществ подобного способа извлечения задачи авторы указывают на снижение степени непонимания между разработчиком и пользователем, вовлечение пользователя в проект с самого начала его реализации и построение им каркаса модели задачи и модели предметной области. Однако вызывает сомнение возможность использования данного подхода для решения задач со сложной моделью предметной области, имеющей большой объем и сложную структуру системы понятий, необходимую для решения задачи, обеспечения пользователя интеллектуальной поддержкой, поскольку каркас и элементы модели (термины и понятия) выделяются на основе неформального описания задачи пользователем. Опыт проектирования сложных систем, например, экспертной системы «Консультант-2″ и, в частности, ее интерфейса, показал, что процесс формирования системы понятий, бесспорно, должен осуществляться при активном участии высококвалифицированных специалистов предметной области на основе серьезного предшествующего ее анализа с целью последующей формализации. Инструментарий для проектирования интерфейса поэтому должен быть ориентирован скорее на разработчика интерфейса, чем на конечного его пользователя.

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

Следует отметить, что во всех существующих Toolkits отсутствуют специальные средства для проектирования пользовательского интерфейса исходя из его составляющих. Поэтому разработчики интерфейса вынуждены проектировать все его части вместе, явно не отделяя одну составляющую от другой, хотя проектирование различных его составляющих требует использования различных типов понятий и уровней абстракции. Технология разработки интерфейса данными средствами организована таким образом, что разработчик выбирает интерфейсный элемент и «нанизывает» на него содержание интерфейса, а не наоборот, в соответствии со структурой и содержанием (системой понятий) предлагаются формы ее представления (возможно, автоматически формируются). Разрабатывая таким образом интерфейс, его разработчик должен корректировать структуру и содержание исходных данных под формы, предлагаемые в инструментальном средстве.

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

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

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

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

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

Заключение

.

Таким образом, можно сделать следующие выводы.

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

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

Список использованных источников

.

Абхалимова, Р. С. Информационные технологии ХХI века // Экономика и социум. — 2014 г. — № 2−5 (11). ;

С. 234−236.

Алексеенко Е.А., Гавриленко Е. В. Оценка качества пользовательского интерфейса. «Управляющие системы и машины», 2000, № 2.

Багриновский К. А. Хрусталев Е.Ю. Новые информационные технологии. — М.: ЭКО, 2011. — С.

122.

Белладжио Д., Миллиган Т. Разработка программного обеспечения: управление изменениями / Д. Белладжио, Т. Миллиган. — М.: ДМК-Пресс, 2009. — 384с.

Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз информационных данных. Полный курс. — Вильямс, 2010. — С.

125.

Горбенко А. О. Информационные системы в экономике / А. О. Горбенко. — М.: Бином, Лаборатория знаний,. — 2010. — 293с.

Гультяев А.К., Мишин В. А. Проектирование и дизайн пользовательского интерфейса. С.-Пб.: КОРОНА-принт, 2000.

Гусятников В. Н. Стандартизация и разработка программных систем. Учебное пособие / В. Н. Гусятников, А. И. Безруков. — М.: Финансы и статистика, 2010. — 288с. (Электронная библиотечная система «Университетская библиотека онлайн»).

Дейт К., Дарвен Х. Основы будущих систем баз информационных данных. Третий манифест. — Янус-К, 2011. — С.

102.

Дениг В., Эссиг Г., Маас С. Диалоговые системы «человек-ЭВМ». Адаптация к требованиям пользователя. М.: Мир, 1984.

Дунаев В. В. Базы информационных данных. Язык SQL. — СПб.: БХВ-Петербург, 2010. — С.

88.

Жилин Д. М. Теория систем: опыт построения курса. — Ком.

Книга, 2011. — С.

123.

Иванова Г. С. -Основы программирования. — Учебник для вузов. — М.: Изд-во МГТУ им. Н. Э. Баумана, 2010. — С.

156.

Иванова Н. Ю. Системное и прикладное программное обеспечение. Учебное пособие / Н. Ю. Иванова. — М.: Прометей, 2011. — 202 с.

Информатика и информационно-коммуникационные технологии. Базовый курс: И. Г. Семакин, С. В. Русаков, Л. В. Шестакова. — М: БИНОМ, Лаборатория знаний, 2010. — С. 169.

Кренке Д. Теория и практика построения баз информационных данных. — Питер, 2010. — С.

206.

Мандел Тео. Разработка пользовательского интерфейса. М.: ДМК Пресс, 2001.

Мирошниченко Г. Реляционные базы информационных данных. Практические приемы оптимальных решений. — СПб.: БХВ-Петербург, 2011. — С.

199.

Новиков Б., Домбровская Г. Настройка приложений баз информационных данных. — BHV, 2011. — С.

22.

Скотт В. Эмблер, Прамодкумар Дж. Садаладж Рефакторинг баз информационных данных. Эволюционное проектирование. — Вильямс, 2010. — C.

36.