Опубликован: 23.10.2005 | Доступ: свободный | Студентов: 4086 / 201 | Оценка: 4.44 / 4.19 | Длительность: 33:04:00
Специальности: Программист
Лекция 14:

ОО-метод для графических интерактивных приложений

< Лекция 13 || Лекция 14: 12345 || Лекция 15 >
Аннотация: Элегантный интерфейс пользователя стал неотъемлемой частью всякого успешного программного продукта. Достижения в создании новых мониторов, эргономике (изучении человеческого фактора) и в разработке ПО привели к всеобщему распространению интерактивных методов и средств, прокладывающих себе дорогу с семидесятых. Многооконные системы позволяют выполнять одновременно несколько работ, мышь позволяет быстро указывать на требуемый элемент, меню ускоряет возможность выбора, значки представляют важные понятия, рисунки демонстрируют информацию визуально, кнопки выполняют стандартные операции.

Аббревиатура GUI, обозначающая Graphical User Interface (Графический Интерфейс Пользователя), служит общим лозунгом для такого стиля взаимодействия. Связанные с ним модные термины - WYSIWYG (What You See Is What You Get (Что Видите, То и Имеете)), WIMP (Windows, Icons, Menus, Pointing device (Окна, Значки, Меню, Указатели)) и фраза "прямое манипулирование" - характеризуют приложения, у пользователей которых создается впечатление, что они работают непосредственно с объектами, изображенными на экране. Эти впечатляющие средства, ранее доступные только пользователям самых передовых систем, работающих на дорогом оборудовании, сейчас стали стандартными для самых обычных персональных машин. Настолько стандартными и популярными, что разработчика ПО заведомо постигнет неудача, если в его продукте будет использован не графический интерфейс, а строковый или полноэкранный.

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

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

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

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

Недавно Знаменитый Конструктор сконструировал новый автомобиль. У него не было ни прибора с показателем горючего, ни спидометра, ни множества других глупых кнопок и табло, заполонивших современные машины. Вместо этого в нужный момент посреди приборной доски загорался большой "?". "Опытный водитель", - сказала Знаменитость, - "всегда знает, что вышло из строя".

Фольклор Unix'а. (Вместо "Знаменитый Конструктор" использовалось настоящее имя одного из главных создателей ОС Unix.)

Необходимые средства

Какие средства нужны для создания полезных и приятных интерактивных приложений?

Конечные пользователи, разработчики приложений и разработчики инструментальных средств

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

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

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

Графические системы, оконные системы, инструментальные средства

Многие вычислительные платформы предлагают средства для построения графических интерактивных приложений. Для реализации графики имеются соответствующие библиотеки такие, как GKS и PHIGS. Что касается интерфейса пользователя, то базовые оконные системы (такие, как Windows API, Xlib API под Unix'ом и Presentation Manager API под OS/2) имеют чересчур низкий уровень, чтобы ими было удобно пользоваться разработчикам приложений, но они дополняются "инструментариями", например, основанными на протоколе интерфейса пользователя Motif.

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

  • Их трудно использовать. Чтобы освоить инструментальные средства, основанные на протоколе Motif, разработчики должны изучить многотомную документацию, описывающую сотни встроенных функций на Си и структур, носящих такие внушающие благоговейный ужас имена как XmPushButtonCallbackStruct, где в Button буква B большая, а в back - b малая. К трудностям и небезопасности C добавляется сложность инструментария. Использование базового интерфейса программирования приложений API в Windows также утомительно.
  • Хотя предлагаемый инструментарий включает объекты пользовательского интерфейса - кнопки, меню и т. п., - у некоторых из них хромает графика (геометрические фигуры и их преобразования). Для добавления в интерфейс настоящей графики требуются значительные усилия.
  • Различные инструментальные средства несовместимы друг с другом. Графика Motif, Windows и Presentation Manager, основанная на похожих понятиях, имеет множество различий. Некоторые из них существенны. Так, в Windows и PM создаваемый объект интерфейса сразу же выводится на экран, а в Motif сначала строится соответствующая структура, а затем вызов операции "реализовать" ее показывает. Некоторые различия связаны с разными соглашениями (координаты экрана откладываются от верхнего левого угла в PM и от нижнего левого угла у других). Многие соглашения об интерфейсах пользователя также различны. Большинство этих различий доставляет неприятности конечным пользователям, желающим иметь нечто работающее и "приятно выглядящее" и которым неважно, какие углы у окна - острые или слегка закругленные. Эти различия еще больше неприятны разработчикам, которые должны выбирать между потерей части их потенциального рынка и тратой драгоценного времени на усилия по переносу.

Библиотека и конструктор приложений

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

Наборы инструментов содержат много необходимых механизмов и дают хорошую основу. Остается скрыть лишние детали и пополнить их полезными средствами.

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

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

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

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

Применение ОО-подхода

В ОО-подходе ключевым шагом является выбор правильных абстракций данных: типов объектов, характерных для данной проблемной области.

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

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

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

< Лекция 13 || Лекция 14: 12345 || Лекция 15 >