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

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

Интерфейс - это, прежде всœего, набор правил. Как любые правила, их можно обобщить, собрать в "кодекс", сгруппировать по общему признаку. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, мы пришли к понятию "вид интерфейса" как объединœение по схожести способов взаимодействия человека и компьютеров. Можно предложить следующую схематическую классификацию различных интерфейсов общения человека и компьютера (рис.1.).

Пакетная технология. Исторически данный вид технологии появился первым. Она существовала уже на релœейных машинах Зюса и Цюзе (Германия, 1937 год). Идея ее проста: на вход компьютера подается последовательность символов, в которых по определœенным правилам указывается последовательность запущенных на выполнение программ. После выполнения очередной программы запускается следующая и т.д. Машина по определœенным правилам находит для себя команды и данные. В качестве этой последовательности может выступать, к примеру, перфолента͵ стопка перфокарт, последовательность нажатия клавиш электрической пишущей машинки (типа CONSUL). Машина также выдает свои сообщения на перфоратор, алфавитно-цифровое печатающее устройство (АЦПУ), ленту пишущей машинки.

Такая машина представляет собой "черный ящик" (точнее "белый шкаф"), в который постоянно подается информация и которая также постоянно "информирует" мир о своем состоянии. Человек здесь имеет малое влияние на работу машины - он может лишь приостановить работу машины, сменить программу и вновь запустить ЭВМ. Впоследствии, когда машины стали помощнее и могли обслуживать сразу нескольких пользователœей, вечное ожидание пользователœей типа: "Я послал данные машинœе. Жду, что она ответит. И ответит ли вообще?" - стало, мягко говоря, нужноедать. К тому же вычислительные центры, вслед за газетами, стали вторым крупным "производителœем" макулатуры. По этой причине с появлением алфавитно-цифровых дисплеев началась эра по-настоящему пользовательской технологии - командной строки.

Командный интерфейс.

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

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

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

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

Обе эти технологии реализуются в виде командного интерфейса - машинœе подаются на вход команды, а она как бы "отвечает" на них.

Преобладающим видом файлов при работе с командным интерфейсом стали текстовые файлы - их и только их можно было создать при помощи клавиатуры. На время наиболее широкого использования интерфейса командной строки приходится появление операционной системы UNIX и появление первых восьмиразрядных персональных компьютеров с многоплатформенной операционной системой CP/M.

WIMP - интерфейс (Window - окно, Image - образ, Menu - меню, Pointer - указатель). Характерной особенностью этого вида интерфейса является то, что диалог с пользователœем ведется не с помощью команд, а с помощью графических образов - меню, окон, других элементов. Хотя и в данном интерфейсе подаются команды машинœе, но это делается "опосредственно", через графические образы. Идея графического интерфейса зародилась в серединœе 70-х годов, когда в исследовательском центре Xerox Palo Alto Research Center (PARC) была разработана концепция визуального интерфейса. Предпосылкой графического интерфейса явилось уменьшение времени реакции компьютера на команду, увеличение объёма оперативной памяти, а также развитие технической базы компьютеров. Аппаратным основанием концепции, конечно же, явилось появление алфавитно-цифровых дисплеев на компьютерах, причем на этих дисплеях уже имелись такие эффекты, как "мерцание" символов, инверсия цвета (смена начертания белых символов на черном фоне обратным, то есть черных символов на белом фоне), подчеркивание символов. Эти эффекты распространились не на весь экран, а только на один или более символов. Следующим шагом явилось создание цветного дисплея, позволяющего выводить, вместе с этими эффектами, символы в 16 цветах на фоне с палитрой (то есть цветовым набором) из 8 цветов. После появления графических дисплеев, с возможностью вывода любых графических изображений в виде множества точек на экране различного цвета͵ фантазии в использовании экрана вообще не стало границ! Первая система с графическим интерфейсом 8010 Star Information System группы PARC, таким образом, появилась за четыре месяца до выхода в свет первого компьютера фирмы IBM в 1981 году. Первоначально визуальный интерфейс использовался только в программах. Постепенно он стал переходить и на операционные системы, используемых сначала на компьютерах Atari и Apple Macintosh, а затем и на IBM -- совместимых компьютерах.

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

Графический интерфейс пользователя за время своего развития прошел две стадии и реализован на двух уровнях технологий: простой графический интерфейс и "чистый" WIMP - интерфейс.

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

Ú При отображении символов допускалось выделœение части символов цветом, инверсным изображением, подчеркиванием и мерцанием. Благодаря этому повысилась выразительность изображения.

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

Ú Нажатие клавиши Enter не всœегда приводит к выполнению команды и переходу к следующей строке. Реакция на нажатие любой клавиши во многом зависит от того, в какой части экрана находился курсор.

Ú Кроме клавиши Enter, на клавиатуре всœе чаще стали использоваться "серые" клавиши управления курсором (см. раздел, посвященный клавиатуре в выпуске 3 данной серии.)

Ú Уже в этой редакции графического интерфейса стали использоваться манипуляторы (типа мыши, трекбола и т.п. - см. рисунок A.4.) Οʜᴎ позволяли быстро выделять нужную часть экрана и перемещать курсор.

Подводя итоги, можно привести следующие отличительные особенности этого интерфейса:

Ú Выделœение областей экрана.

Ú Переопределœение клавиш клавиатуры исходя из контекста.

Ú Использование манипуляторов и серых клавиш клавиатуры для управления курсором.

Ú Широкое использование цветных мониторов.

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

Типичным примером использования этого вида интерфейса является файловая оболочка Nortron Commander и текстовый редактор Multi-Edit. А текстовые редакторы Лексикон, ChiWriter и текстовый процессор Microsoft Word for Dos являются примером, как данный интерфейс превзошел сам себя.

Вторым этапом в развитии графического интерфейса стал "чистый" интерфейс WIMP, Этот подвид интерфейса характеризуется следующими особенностями:

Ú Вся работа с программами, файлами и документами происходит в окнах - определœенных очерченных рамкой частях экрана.

Ú Все программы, файлы, документы, устройства и другие объекты представляются в виде значков - иконок. При открытии иконки превращаются в окна.

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

Ú Широкое использование манипуляторов для указания на объекты. Манипулятор перестает быть просто игрушкой - дополнением к клавиатуре, а становится основным элементом управления. С помощью манипулятора указывают на любую область экрана, окна или пиктограммы, выделяют ее, а уже потом через меню или с использованием других технологий осуществляют управление ими.

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

Ярким примером программ с графическим интерфейсом является операционная система Microsoft Windows.

SILK - интерфейс (Speech - речь, Image - образ, Language - язык, Knowlege - знание). Этот вид интерфейса наиболее приближен к обычной, человеческой форме общения. В рамках этого интерфейса идет обычный "разговор" человека и компьютера. При этом компьютер находит для себя команды, анализируя человеческую речь и находя в ней ключевые фразы. Результат выполнения команд он также преобразует в понятную человеку форму. Этот вид интерфейса наиболее требователœен к аппаратным ресурсам компьютера, и в связи с этим его применяют в основном для военных целœей.

С середины 90-х годов, после появления недорогих звуковых карт и широкого распространения технологий распознавания речи, появился так называемый "речевая технология" SILK - интерфейса. При этой технологии команды подаются голосом путем произнесения специальных зарезервированных слов - команд.

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

"Речевая" технология является простейшей реализацией SILK - интерфейса.

Биометрическая технология ("Мимический интерфейс".)

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

Студент должен знать:

  • Назначение интерфейса.
  • Виды интерфейсов (внешний, внутренний, справочный, управления ввода/вывода, информационные).
  • Элементы графических интерфейсов и функции, которые они реализуют.

Студент должен уметь:

  • Создавать интерфейс windows-приложения.

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

Современными видами интерфейсов являются:

1) Командный интерфейс. Командный интерфейс называется так по тому, что в этом виде интерфейса человек подает "команды" компьютеру, а компьютер их выполняет и выдает результат человеку. Командный интерфейс реализован в виде пакетной технологии и технологии командной строки.

2) WIMP - интерфейс (Window - окно, Image - образ, Menu - меню, Pointer - указатель). Характерной особенностью этого вида интерфейса является то, что диалог с пользователем ведется не с помощью команд, а с помощью графических образов - меню, окон, других элементов. Хотя и в этом интерфейсе подаются команды машине, но это делается "опосредственно", через графические образы. Этот вид интерфейса реализован на двух уровнях технологий: простой графический интерфейс и "чистый" WIMP - интерфейс.

3) SILK - интерфейс (Speech - речь, Image - образ, Language - язык, Knowlege - знание). Этот вид интерфейса наиболее приближен к обычной, человеческой форме общения. В рамках этого интерфейса идет обычный "разговор" человека и компьютера. При этом компьютер находит для себя команды, анализируя человеческую речь и находя в ней ключевые фразы. Результат выполнения команд он также преобразует в понятную человеку форму. Этот вид интерфейса наиболее требователен к аппаратным ресурсам компьютера, и поэтому его применяют в основном для военных целей.

Тема 3. Функциональное и системное наполнение предметно ориентированного программного обеспечения. Входные языки и использование их для программирования в среде выбранного программного обеспечения.

Студент должен знать :

· Назначение методо – ориентированного программного обеспечения;

· Назначение проблемно-ориентированные программного обеспечения;

· Назначение предметно ориентированного программного обеспечения.

· Назначение входных языков программирования.

ППП (Пакет прикладных программ)- это совокупность совместимых программ для решения определенного класса задач.



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

§ Поскольку ППП предназначен для решения определенного класса задач, можно говорить о функциональном назначении пакета.

§ В зависимости от функционального назначения выделяют ППП, расширяющие возможности ОС, например, для построения многопользовательских систем, работы с удаленными абонентами, реализации специальной организации файлов, упрощения работы с ОС и т.п. Примерами таких пакетов служат пакет СРВ, реализующий режим разделения времени в ОС ЕС ЭВМ, пакет Norton Commander для облегчения работы с операционной системой MS DOS.

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

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



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

§ ППП состоит из нескольких программных единиц.. ППП состоит из нескольких программных единиц. Такие программные единицы обычно называют программными модулями. Пакет предназначен для решения задач определенного класса. Этот класс задач обычно называют предметной областью пакета.

§ Тема 4. Интеграция выбранного программного обеспечения с другими программами. Интеграция VBA с MS Office .

Студент должен знать :

· Интеграцию встроенного языка программирования Visual Basic for Application (VBA) c Word.

· Интеграцию встроенного языка программирования Visual Basic for Application (VBA) c Excel.

· Интеграцию встроенного языка программирования Visual Basic for Application (VBA) c Access.

· Интеграцию встроенного языка программирования Visual Basic for Application (VBA) c Power Point.

§ Тема 5. VBA. Элементы Управления, интерфейс редактора VBA, объекты VBA

Студент должен знать :

· Элементы управления VBA.

· интерфейс редактора VBA.

· Объекты, свойства, методы VBA.

Уметь.

· Работать с окнами в редакторе VBA.

· Работать со стандартными математическими функциями VBA.

· Осуществлять ввод/вывод данных.

VBA относится к языкам объектно - ориентированного программирования (ООП). ООП можно описать как методику анализа, проектирования и написания приложений с помощью объектов. Объект – комбинация кода и данных, которая может рассматриваться как единое целое, например элемент управления, форма и компонент приложения. Каждый объект определяется по принадлежности к классу. Все визуальные объекты, такие как рабочий лист (Worksheet), диапазон (Range), диаграмма (Chart), форма (UserForm), являются объектами.

Доступ к данному языку программирования можно осуществлять практически из любого приложения Windows.

§ Тема 6. VBA. Создание собственных диалоговых окон

Студент должен знать :

· Свойства элементов управления VBA.

· Типы данных VBA.

· Типы диалоговых окон.

Уметь.

· Создавать интерфейс приложения.

· Создавать процедуры обработки событий.

По своей сути форма (или пользовательская форма) представляет собой диалоговое окно, в котором можно размещать различные элементы управления. В приложении может быть как одна, так и несколько форм. Новая форма добавляется в проект выбором команды Вставка (Insert) ® UserForm.

В VBA имеется обширный набор встроенных элементов управления. Используя этот набор и редактор форм, нетрудно создать любой пользовательский интерфейс, который будет удовлетворять всем требованиям, предъявляемым к интерфейсу в среде Windows. Элементы управления являются объектами. Как любые объекты, они обладают свойствами, методами и событиями. Элементы управления создаются при помощи Панели элементов.

§ Тема 7. VBA. Алгоритмы и программы разветвляющейся структуры

Студент должен знать :

· Синтаксис алгоритмов разветвляющейся структуры с условным оператором IF.

· Условия применимости алгоритмов разветвляющейся структуры.

Уметь.

· Применять алгоритмы разветвляющейся структуры на практике.

· Работать с объектами Worksheets(), Range().

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

Условный оператор позволяет выбирать и выполнять действия в зависимости от истинности некоторого условия. Имеется два варианта синтаксиса: В первом случае он имеет вид:

IF условие Then [операторы 1]

Всякий раз, включая компьютер, вы имеете дело с пользовательским интерфейсом (User Interface, UI), который кажется простым и очевидным, но, чтобы он стал таким, в индустрии было вложено немало труда. Оглянемся на 1990-е годы, когда настольные компьютеры стали повсеместными, и приведем хронологию развития технологий UI. Рассмотрим также, как развивались средства программирования UI и что они собой представляют сегодня. В табл. 1 приведен перечень основных задач разработки UI, на базе которых проводился анализ различных технологий реализации пользовательских интерфейсов, распределенных по категориям. Каждая из этих категорий включает технологии, решающие одну или более задач примерно одинаковыми способами.

Формы ввода с привязкой к СУБД

Одну из главных категорий средств разработки UI образуют инструментарии, ориентированные на формы ввода данных с привязкой к реляционным СУБД. Суть данного подхода состоит в создании UI для приложений путем построения форм, отображающих значения полей базы в соответствующих элементах управления: текстовых полях, списках, кнопках-флажках, таблицах и т. п. Инструментарий позволяет выполнять навигацию по такой форме и устанавливать прямую связь между элементами управления и данными в базе. Разработчику не нужно заботиться о блокировках, передаче, преобразовании и обновлении данных - когда пользователь, например, переключает номер записи в форме, ее остальные поля обновляются автоматически. Аналогично, если пользователь меняет значение в поле, привязанном к какой-либо записи из базы, это изменение мгновенно в ней сохраняется. Чтобы добиться этого, не нужно специально писать код - достаточно задекларировать привязку элемента управления или всей формы к источнику данных. Таким образом, поддержка привязки к данным в инструментах этой категории - одна из сильных сторон данного метода. Задачи планировки и стилизации UI в таких средах решаются с помощью дизайнеров форм и специализированных объектно-ориентированных API. Для управления поведением UI обычно предлагаются обработчики событий (представляющие собой методы, реализованные на основном языке программирования среды разработки), тогда как для контроля вводимых значений используются выражения (в том числе регулярные). Типичные представители этой многочисленной категории инструментариев - Microsoft Access и Oracle Forms.

Обработчики шаблонов

Технологии построения пользовательских интерфейсов на базе шаблонов, реализованных на языках разметки, начали повсеместно применяться с середины 1990-х. Основные преимущества шаблонов - гибкость и широта возможностей создания динамических пользовательских веб-интерфейсов, особенно с точки зрения разработки структуры и планировки. Вначале в таких инструментариях использовались шаблоны, в которых планировка и структура UI задавались с помощью языка разметки, а привязка к данным осуществлялась с помощью небольших блоков на языке высокого уровня (Java, C#, PHP, Python и т. д.). Последние могли использоваться в комбинации с разметкой; например, путем внедрения тегов разметки в цикл на Java могли создаваться итеративные визуальные элементы наподобие таблиц и списков. Необходимость частой смены синтаксиса внутри веб-страницы затрудняла разработку и коррекцию кода для программистов, поэтому около десяти лет назад начался переход с языков высокого уровня на специализированные библиотеки тегов разметки и языки выражений, созданные для конкретных веб-технологий.

Теги разметки стали использовать для реализации типовых функций веб-приложений, а выражения - для доступа к данным и вызова функций, хранимых в серверных объектах. Типичный представитель этой группы - технология JavaServer Pages (JSP), библиотека тегов которой JSP Standard Tag Library поддерживает такие задачи, как: манипуляция с XML-документами, циклы, условия, опрос СУБД (привязка к данным) и интернационализация (форматирование данных). Язык выражений JSP - EL, служащий средством привязки к данным, предлагает удобную нотацию для работы с объектами и свойствами приложения.

Существует целый ряд похожих на JSP инструментариев веб-разработки: для планировки и задания структуры (в них используются шаблоны), для привязки к данным с помощью языка выражений, а поведение UI задается с помощью обработчиков событий, реализованных средствами языка ECMAScript и интерфейса программирования Document Object Model. Форматирование данных выполняется с помощью специализированных библиотек тегов, для стилизации внешнего вида обычно применяется CSS (Cascading Style Sheets). Популярные представители этой категории инструментов: ASP, PHP, Struts, WebWork, Struts2, Spring MVC, Spyce и Ruby on Rails.

Объектно-ориентированные и событийные инструменты

Значительная доля инструментариев для создания UI базируется на объектно-ориентированной модели. Обычно эти инструментарии предлагают библиотеку готовых элементов UI, и их главными преимуществами являются простота составления многократно используемых блоков из простых компонентов и интуитивно понятный, гибкий процесс программирования поведения и взаимодействия, основанный на обработчиках событий. В этих инструментариях все задачи разработки UI решаются с использованием специализированных объектных API. К данной категории относятся среды: Visual Basic, MFC, AWT, Swing, SWT, Delphi, Google Web Toolkit, Cocoa Touch UIKit, Vaadin и др. Сюда же можно отнести инструментарий Nokia Qt, предлагающий ряд оригинальных концепций. В некоторых инструментариях вся сложность взаимодействия между элементами структуры UI реализуется с помощью обработчиков событий, а в Qt в дополнение к ним есть «сигналы» и «слоты»: сигнал передается компонентом UI всякий раз, когда происходит определенное событие. Слот - это метод, вызываемый в ответ на определенный сигнал, который можно декларативно связать с каким угодно количеством слотов, и наоборот, один слот может получать сколько угодно сигналов. Элемент, передающий сигнал, «не знает», какой слот его получит. Таким образом, элементы пользовательского интерфейса слабо связаны соединениями «сигнал-слот». Данный механизм способствует использованию принципа инкапсуляции и предоставляет возможность декларативно задавать поведение UI.

Гибриды

Гибридные технологии относительно новы в мире разработки UI общего назначения - наряду с шаблонами и языками выражений в подобных инструментариях применяется объектный API. Типичный представитель - JavaServer Faces: библиотеки тегов служат для описания структуры и планировки, а также для форматирования данных; язык выражений - для привязки элементов и событий к серверным объектам и коду приложений; объектный API - для отображения элементов, управления их состоянием, обработки событий и контроля ввода. Другие популярные инструментарии в этой категории: ASP.NET MVC, Apache Wicket, Apache Tapestry, Apache Click и ZK Framework.

Среда Adobe Flex концептуально близка к технологиям этой категории, так как в ней для структурирования и планировки используются шаблоны, а программирование целиком выполняется на языке ActionScript. Подобно Qt, среда Flex предоставляет механизм для решения задач, связанных с программированием поведения и привязкой к данным.

Декларативные инструментарии

Такие инструменты - новейшее направление в области средств разработки UI. Для указания структуры пользовательского интерфейса в них используются языки на основе XML и JSON (JavaScript Object Notation), а для остальных задач разработки UI применяется преимущественно декларативная нотация. В отличие от гибридных подходов, в основном рассчитанных на веб-интерфейсы, декларативные применяются еще в разработке нативных приложений для мобильных и настольных платформ.

API пользовательского интерфейса Android - событийно-зависимый, объектно-ориентированный, но наряду с основным в ОС есть вспомогательный API, базирующийся на XML, который позволяет декларировать структуру и планировку пользовательского интерфейса, а также стилизовать его элементы и управлять их свойствами. Декларативное описание интерфейса нагляднее показывает его структуру и помогает в отладке; позволяет без перекомпиляции менять планировку; помогает адаптироваться к различным платформам, размерам экрана и соотношениям его сторон. При создании более динамических пользовательских интерфейсов указывать и менять структуру элементов можно и программно - с помощью объектных API, но привязка к данным не поддерживается. Существует, правда, Android-Binding - стороннее решение с открытым кодом, позволяющее привязывать элементы пользовательского интерфейса к моделям данных.

Создавать UI для программ Windows и функционально богатых интернет-приложений, основанных, соответственно, на технологиях Windows Platform Foundation и Microsoft Silverlight, можно с использованием другого XML-словаря - eXtensible Application Markup Language (XAML). Он позволяет задавать структуру, планировку и стиль UI, а кроме того, в отличие от языка разметки Android, в нем поддерживается привязка к данным и возможность обработки событий.

В Nokia разработчикам рекомендуют Qt Quick - кросс-платформный инструментарий для настольных, мобильных и встраиваемых ОС, поддерживающий QML (декларативный скриптовый язык на основе синтаксиса JSON). Описание пользовательского интерфейса имеет иерархическую структуру, а поведение программируется на ECMAScript. Здесь, как и в обычном Qt, поддерживается механизм «сигнал-слот». Qt Quick поддерживает возможность привязки свойств элементов UI к модели данных, а также концепцию машины состояний, позволяющую графически моделировать поведение интерфейса.

Еще один пример - Enyo, кросс-платформный инструментарий для создания UI на ECMAScript, в котором структура интерфейса задается декларативно, а поведение регулируется обработчиками событий. События обрабатываются тремя способами: на уровне отдельных компонентов UI, путем передачи от потомка к родителю без прямой привязки, а также за счет шировоковещательной трансляции и подписки на такие сообщения (тоже без прямой привязки). Благодаря слабой связи элементов UI расширяются возможности многократного использования и инкапсуляции больших фрагментов интерфейса. По сути, основное достоинство Enyo - это модель инкапсуляции, благодаря которой UI можно компоновать из многократно используемых самодостаточных строительных блоков с заданными интерфейсами. Данная модель способствует абстрагированию и охватывает все архитектурные уровни UI. Участники проекта Enyo работают над реализацией поддержки привязки к данным.

Eclipse XML Window Toolkit - еще один инструментарий, ориентированный на декларативное описание UI. Первоначальная задача его создания состояла в объединении в Eclipse всех инструментов разработки UI, включая SWT, JFace, Eclipse Forms и другие - все их элементы так или иначе имеют соответствия в XWT. Структура и планировка UI в XWT задаются с помощью языка на основе XML, а для привязки к данным (доступа к Java-объектам приложения) используется язык выражений. Обработка событий программируется на Java, а для стилизации элементов интерфейса используется CSS. Механизм исполнения приложений XWT реализован в виде Java-апплета и элемента ActiveX, то есть может работать практически в любом браузере.

В этой категории существует немало похожих инструментов: в AmpleSDK, например, в качестве языка описания UI используется XUL, функции ECMAScript применяются для программирования динамического поведения, CSS - для стилизации. В Dojo Toolkit интерфейс задается декларативно и предусмотрены широкий выбор готовых элементов, объектное хранилище для доступа к данным и обработчик событий на основе ECMAScript с механизмом публикации-подписки. Инструментарий поддерживает интернационализацию, развитый API для опроса данных, модуляризацию и множественное наследование классов.

Инструментарии на основе моделей

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

Анализируя поколения модельно-ориентированных подходов к разработке UI начиная с 1990-х, можно прийти к выводу , что сегодня имеется общепринятое представление об уровнях абстракции и типах моделей, подходящих для разработки современных пользовательских интерфейсов, однако до сих пор нет единого мнения (стандартов) относительно информации (семантики), которую должны содержать различные модели. Считать базовыми можно модели задач, диалогов и презентации: презентационная модель решает задачи структурирования, планирования и стилизации; модель задач отвечает за привязку к данным - для каждой задачи указываются объекты UI и логики, с которыми предстоит работать; диалоговая модель охватывает поведенческие аспекты. Пример модели задач - Concurrent-TaskTrees (CTT), ее можно использовать совместно с языком MARIA, который реализует остальные модели UI . CTT в сочетании с MARIA представляет собой полноценный модельно-ориентированный инструментарий. Довольно большое семейство средств моделирования UI полагается также на язык UML, модели «сущность-связь» или подобные. Профили UML широко применяются в построении пользовательских интерфейсов бизнес-приложений. Существуют и другие активно используемые инструментарии - например, WebRatio, UMLi, Intellium Virtual Enterprise и SOLoist.

Обобщенные пользовательские интерфейсы

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

Тенденции и сложности

На рисунке представлена хронология появления различных инструментариев разработки UI, распределение их по категориям и основным областям применения, а в табл. 2 указаны способы, которыми каждая из технологий решает различные задачи разработки UI.

Для веб-разработки с целью развития общеупотребительных технологий характерны две противоположные тенденции. После технологий на основе шаблонов появились инструментарии с объектно-ориентированными API, которые чаще всего дополнялись шаблонами (в случае гибридных подходов) либо полностью заменяли их (GWT и Vaadin). В принципе, это вполне логично, учитывая общее превосходство объектно-ориентированных языков над шаблонными (наследование, полиморфизм, инкапсуляция, параметризация, многократное использование и т. д.), потребность в развитых концепциях и механизмах для составления обширных структур UI, а также «историю успеха» объектно-ориентированных API в эпоху настольных ПК.

Примечательно, что по сравнению с императивными и объектно-ориентированными способами формирования UI сегодня стали шире применяться декларативные - например, общеупотребительными становятся HTML, XML, XPath, CSS, JSON и подобные нотации. Большая часть структуры UI, как правило, статична, так что декларативные нотации отлично справляются с задачами структурирования, планировки и привязки к данным. Но поведенческие аспекты UI по-прежнему реализуются по классической событийно-зависимой парадигме, хотя есть исключения - когда применяются декларативные средства.

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

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

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

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

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

Литература

  1. P.P. Da Silva. User Interface Declarative Models and Development Environments: A Survey. Proc. Interactive Systems: Design, Specification, and Verification, Springer, 2000, Р. 207-226.
  2. G. Meixner, F. Paterno, J. Vanderdonckt. Past, Present, and Future of Model-Based User Interface Development // i-com. 2011. vol. 10, N3, Р. 2-11.
  3. G. Mori, F. Paterno, C. Santoro. CTTE: Support for Developing and Analyzing Task Models for Interactive Systems Design // IEEE Trans. Software Eng. 2002, vol. 28, N8, P. 797-813.

Жарко Мияйлович ([email protected]) - старший инженер, Драган Миличев ([email protected]) - доцент, Белградский университет.

Zarko Mijailovic, Dragan Milicev, A Retrospective on User Interface Development Technology, IEEE Software, November/December 2013, IEEE Computer Society. All rights reserved. Reprinted with permission.

Клещев А.С., Грибова В.В. 25.03.2001

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

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

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

В литературе не существует единой общепринятой классификации средств для разработки пользовательского интерфейса. Так, в программное обеспечение для разработки пользовательского интерфейса разделяется на две основные группы – инструментарий для разработки пользовательского интерфейса (toolkits) и высокоуровневые средства разработки интерфейса (higher-level development tools). Инструментарий для разработки пользовательского интерфейса, как правило, включает в себя библиотеку примитивов компонентов интерфейса (меню, кнопки, полосы прокрутки и др.) и предназначен для использования программистами. Высокоуровневые средства разработки интерфейса могут быть использованы непрограммистами и снабжены языком, который позволяет специфицировать функции ввода-вывода, а также определять, используя технику непосредственного манипулирования, интерфейсные элементы. К таким средствам авторы относят построители диалога (interface builders) и СУПИ – системы управления пользовательским интерфейсом (User Interface Management Systems – UIMS). Помимо СУПИ, некоторые авторы используют такие термины, как User Interface Development Systems (UIDS) – системы разработки пользовательского интерфейса, User Interface Design Environment (UIDE) – среда разработки пользовательского интерфейса и др.

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

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

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

Можно выделить несколько основных способов спецификации интерфейса .

1. Языковой, когда применяются специальные языки для задания синтаксиса интерфейса (декларативные, объектно-ориентированные, языки событий и др.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

базисная система сообщений (система понятий предметной области);
система сообщений для пользователя;
система сообщений для прикладной программы;
средства обеспечения удобства и комфорта работы пользователя;
средства интеллектуальной поддержки пользователя;
средства управления взаимодействием пользователя и интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Myers B.A. and Rosson M.B. “Survey on User Interface Programming,” Proceedings SIGCHI’92: Human Factors in Computing Systems. Monterrey, CA, May 3-7, 1992. P. 195-202.

2. Клименко С., Уразметов В. Графические интер- фейсы и средства их разработки // Матер. конф.: Инду- стрия программирования – 96. www.uniyar.ac.ru/network/ atm/forum/koi/if/prg/prg96/73/htm.

3. Puerta, A. R. Supporting User–Centred Design of Adaptive User Interfaces Via Interface Models. First Annual Workshop On Real–Time Intelligent User Interfaces For Decision Support And Information Visualization, San–Francisco, January 1998. 10 p.

4. Brad A. Myers. A Brief History of Human Computer Interaction Technology // ACM interactions. Vol. 5, №. 2. March 1998. P. 44-54.

5. Lowgren J. Knowledge–Based Design Support and Discourse Management in User Interface Management Systems. Linkoping Studies in Science and Technology. Dissertations №239, 1989.

6. Puerta, A.R., and Maulsby, D. Management of Interface Design Knowledge with MOBI–D. IUI97: International Conference on Intelligent User Interfaces, Orlando, January 1997. P. 249–252.

7. Pressman R. S. Software Engineering: Practitioners Approach European 3d Rev. ed. McGraw–Hills Inc., 1994. 802 p.

8. Коутс P., Влейминк И. Интерфейс “человек-компьютер”/ Пер. с англ. – М.: Мир, 1990.- 501 с

9. Bruce A. Wooley Explanation Component of Software Systems. www.acm.org/ crossroads/xrds5–1/explain.html.

10. Бауэр Ф. Л., Гооз Г. Информатика. Вводный курс: В 2 ч. /Пер. с нем. –М.: Мир, 1990. – Ч.1. – 336 с., ил.

11. Грибова В.В., Клещев А.С. Инструментальный комплекс для разработки пользовательского интерфейса в экспертных системах // Программные продукты и системы. – 1999. – №1. – С. 30-34.

12. Puerta, A.R. A Model–Based Interface Development Environment. IEEE Software, 14(4), July/August 1997. Р. 41–47.

13. Черняховская М.Ю. Оценка ЭС медицинской диагностики “Консультант–2″ на архивном материале нескольких клиник. – Владивосток, 1989. – 30 с. (Препр. ИАПУ ДВО РАН).

14. Скопин И.Н. Разработка интерфейсов программных систем // Системная информатика. – 1998. – Вып.6. – С.123–173.

15. Foley, J., Kim, W.C., Kovacevic S., Murray, K., UIDE: An Intelligent User Interface Design Environment, in ACM Press, 1991.

  • ООП

    • В прошедний понедельник мне посчастливилось попасть на собеседование на Senior .Net Developer в одну международную компанию. Во время собеседования мне предложили пройти тест, где ряд вопросов был связан с.Net. В частности в одном из вопросов надо было дать оценку (истина/ложь) ряду утверждений, среди которых было и такое:

    В.Net любой массив элементов, например int, по умолчанию реализует IList, что позволяет использовать его в качестве коллекции в операторе foreach.

    Быстро ответив на этот вопрос отрицательно и отдельно дописав на полях. что для foreach необходима реализация не IList, а IEnumerable, я перешел к следующему вопросу. Однако по дороге домой меня мучал вопрос: реализует ли массив все-таки этот интерфейс или нет?

    Про IList я смутно помнил, что этот интерфейс дает мне IEnumerable, индексатор и свойство Count, содержащее число элементов коллекции, а также еще пару редко используемых свойств, типа IsFixedCollection(). Массив имеет свойство Length для своего размера, а Count в IEnumerable является методом расширения от LINQ, что было бы невозможно, если бы этот метод был реализован в классе. Таким образом, получалось, что массив не мог реализовывать интерфейс IList, однако какое-то смутное чувство не давало мне покоя. Поэтому вечером после интервью я решил провести небольшое исследование.

    Класс System.Array

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

    Var v = new int { 1, 2, 3 }; var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp in i) Console.WriteLine(tp.Name);

    Вот полный список полученных интерфейсов из окна консоли:

    ICloneable IList ICollection IEnumerable IStructuralComparable IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1

    Таким образом, массив в.Net все-таки реализует интерфейс IList и его обобщённый вариант IList<> .

    Чтобы получить более полную информацию я построил диаграмму класса System.Array.

    Мне сразу бросилась в глаза моя ошибка: Count было свойством не IList, а ICollection, еще предыдущего интерфейса в цепочке наследования. Тем не менее, сам массив уже не имел такого свойства, как и многих других свойств интерфейса IList, хотя другие свойства этого интерфейса, IsFixedSize и IsReadOnly были реализованы. Как такое вообще возможно?

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

    Сравнение явной и неявной реализации интерфейсов

    Давайте сравним эти два вида реализации интерфейсов:.
    Критерии
    		 Неявная (implicit) реализация
    		 Явная (explicit) реализация
    Базовый синтаксис
    		 interface ITest { void DoTest(); } public class ImplicitTest: ITest { public void DoTest() { } }
    		interface ITest { void DoTest(); } public class ExplicitTest: ITest { void ITest.DoTest() { } }
    Видимость
    		 Неявная имплементация всегда являелся открытой (public), поэтому к методам и свойствам можно обращаться напрямую.
    var imp = new ImplicitTest(); imp.DoTest();
    		Явная имплементация всегда закрыта (private).
    Чтобы получить доступ к имплементации необходимо кастовать инстанцию класса к интерфейсу (upcast to interface).
    var exp = new ExplicitTest(); ((ITest)exp).DoTest();
    Полиморфия
    		 Неявная имплементация интерфейса может быть виртуальной (virtual), что позволяет переписывать эту имплементацию в классах-потомках.
    		 Явная имплементация всегда статична. Она не может быть переписана (override) или перекрыта (new) в классах-потомках. Прим. 1
    Абстрактный класс и реализация
    		 Неявная реализация может быть абстрактной и реализовываться только в классе-потомке.
    		 Явная реализация не может быть абстрактной, но сам класс может иметь другие абстрактные методы и сам быть абстрактным. Прим. 2

    Примечания:
    Прим. 1 - Как справедливо замечает в комментариях, реализация может быть переопределена при повторной явной имплементации интерфейса в классе-потомке (см. первый комментарий к статье).

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

    Зачем нужна явная реализация интерфейсов

    Явная реализация интерфейса, согласно MSDN , необходима в том случае, когда несколько интерфейсов, реализуемых классом, имеют метод с одинаковой сигнатурой. Эта проблема в общем виде известна в англоязычном мире под леденящим кровь названием «deadly diamond of death» , что переводится на русский как «проблема ромба» . Вот пример такой ситуации:

    /* Listing 1 */ interface IJogger { void Run(); } interface ISkier { void Run(); } public class Athlete: ISkier, IJogger { public void Run() { Console.WriteLine("Am I an Athlete, Skier or Jogger?"); } }

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

    /* Listing 2 */ var sp = new Athlete(); sp.Run(); (sp as ISkier).Run(); (sp as IJogger).Run();

    Результатом исполнения этого кода будет «Am I an Athlete, Skier or Jogger?» , выведенное в консоли три раза.

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

    /* Listing 3 */ public class Sportsman { public virtual void Run() { Console.WriteLine("I am a Sportsman"); } } public class Athlete: Sportsman, ISkier, IJogger { public override void Run() { Console.WriteLine("I am an Athlete"); } void ISkier.Run() { Console.WriteLine("I am a Skier"); } void IJogger.Run() { Console.WriteLine("I am a Jogger"); } }

    В данном случае при исполнении кода из Listing 2 мы увидим в консоли три строчки, «I am an Athlete» , «I am a Skier» и «I am a Jogger» .

    Плюсы и минусы различной реализации интерфейсов

    Видимость реализации и выборочная реализация
    Как уже было показано выше, неявная (implicit) реализация синтаксически не отличается от обычного метода класса (причём если этот метод уже был определен в классе-предке, то в таком синтаксисе метод будет сокрыт (hidden) в потомке и код будет без проблем скомпилирован c compiler warning о сокрытии метода.). Более того, возможна выборочная реализация отдельных методов одного интерфейса как явным, так и неявным образом:

    /* Listing 4 */ public class Code { public void Run() { Console.WriteLine("I am a class method"); } } interface ICommand { void Run(); void Execute(); } public class CodeCommand: Code, ICommand { // implicit interface method implementation // => public implementation // implicit base class method hiding (warning here) public void Run() { base.Run(); } // explicit interface method implementation // => private implementation void ICommand.Execute() {} }

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

    С другой стороны, возможность приватной реализации методов позволяет скрывать ряд методов интерфейса, при этом полностью его имплементируя. Возвращаясь к нашему самому первому примеру с массивами в.Net, можно увидеть, что массив скрывает, например, имплементацию свойства Count интерфейса ICollection, выставляя наружу это свойство под именем Length (вероятно это является попыткой поддержания совместимости с С++ STL и Java). Таким образом, мы можем скрывать отдельные методы реализованного интерфейса и не скрывать (=делать публичными) другие.

    Здесь, правда, возникает такая проблема, что во многих случаях совершенно невозможно догадаться о том, какие интерфейсы реализованы классом «неявно», поскольку ни методы, ни свойства этих интерфейсов не видны в IntelliSense (здесь также показателен пример с System.Array). Единственным способом выявления таких реализаций является использование рефлексии, например при помощи Object Browser в Visual Studio.

    Рефакторинг интерфейсов
    Так как неявная (публичная) имплементация интерфейса не отличается от реализации публичного метода класса, в случае рефакторинга интерфейса и удаления из него какого-либо публичного метода (например при объединении методов Run() и Execute() из вышепредставленного интерфейса ICommand в один метод Run()) во всех неявных реализациях останется метод с открытым доступом, который, очень вероятно, придётся поддерживать даже после рефакторинга, так как у данного публичного метода могут быть уже различные зависимости в других компонентах системы. В результате этого будет нарушаться принцип программирования «против интерфейсов, а не реализаций», так как зависимости будут уже между конкретными (и в разных классах, наверняка, разными) реализациями бывшего интерфейсного метода.

    /* Listing 5 */ interface IFingers { void Thumb(); void IndexFinger(); // an obsolete interface method // void MiddleFinger(); } public class HumanPalm: IFingers { public void Thumb() {} public void IndexFinger() {} // here is a "dangling" public method public void MiddleFinger() {} } public class AntropoidHand: IFingers { void IFingers.Thumb() {} void IFingers.IndexFinger() {} // here the compiler error void IFingers.MiddleFinger() {} }

    В случае приватной реализации интерфейсов все классы с явной реализацией несуществующего более метода просто перестанут компилироваться, однако после удаления ставшей ненужной реализации (или ее рефакторинга в новый метод) у нас не будет «лишнего» публичного метода, не привязанного к какому-либо интерфейсу. Конечно, возможно потребуется рефакторинг зависимостей от самого интерфейса, но здесь, по крайней мере, не будет нарушения принципа «program to interfaces, not implementations».

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

    /* Listing 6 */ interface IProperty { int Amount { get; set; } } public class ClassWithProperty: IProperty { // implicit implementation, public public int Amount { get; set; } public ClassWithProperty() { // internal invocation of the public setter Amount = 1000; } } public class ClassWithExplicitProperty: IProperty { // explicit implementation, private int IProperty.Amount { get; set; } public ClassWithExplicitProperty() { // internal invocation isn"t possible // compiler error here Amount = 1000; } }

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

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

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