Классификация средств разработки ПИ

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

8.1. КЛАССИФИКАЦИЯ СРЕДСТВ РАЗРАБОТКИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Технология построения пользовательского интерфейса и инструментальные сред­ства, используемые для ее реализации, образуют единое целое. Очередной шаг в развитии любой из этих составляющих дает толчок к дальнейшему развитию дру­гой. Материальной же основой существования любого пользовательского интер­фейса является перечень устройств ввода/вывода, доступных конечному пользо­вателю. В те далекие времена, когда единственным средством ввода информации в ЭВМ служило устройство чтения с перфокарт, а средством вывода - его брат-близ­нец для вывода на перфокарты, ни один объектно-ориентированный язык програм­мирования не помог бы представить пользователю результаты иначе, как в виде дырочек на перфокарте. Другими словами, тогда проблемы реализации пользова­тельского интерфейса для программистов просто не существовало («нет интерфей­са - нет проблем»).

С появлением алфавитно-цифровых (символьных) устройств ввода/вывода, таких как алфавитно-цифровые дисплеи (АЦД) и алфавитно-цифровые печата­ющие устройства (АЦПУ), в языки программирования были включены соответ­ствующие операторы (либо библиотечные функции), предназначенные для реа­лизации взаимодействия пользователя с этими устройствами. На данном этапе технология программирования компонентов, относящихся к пользовательскому интерфейсу, практически не отличалась от программирования остальных функ­ций приложения, да и сами эти компоненты были как бы «размазаны» по всей программе. Впоследствии такая технология получила наименование «внутреннее управление интерфейсом». Опирается она в основном на процедурные языки про­граммирования, как высокого уровня (Фортран, Паскаль, Си), так и машинно-ориентированные (типа ассемблера). Очевидно, что при таком подходе разработ­ка интерфейса как самостоятельной компоненты программной системы практически невозможна. Хотя упомянутые выше процедурно-ориентированные языки не зря называются универсальными и позволяют реализовать любой тип интерфейса (в том числе и GUI), трудозатраты на практическую реализацию та­кой затеи могут оказаться не по силам подавляющему большинству разработчи­ков. Кроме того, необходимость «ручного» описания огромного числа атрибутов интерактивных компонентов приложения делает невозможной стандартизацию этих компонентов. В определенной степени упростить решение указанной задачи позволило появление проблемно-ориентированных языков программирования, таких как языки моделирования (SIMULA, GPSS, SOL) и языки управления ба­зами данных (Clipper, dBASE, PAL). Особую группу процедурных языков образу­ют так называемые языки диалогового взаимодействия (или командные языки), созданные специально для облегчения работы пользователей в интерактивном режиме. Основу синтаксиса этих языков составляют макрокоманды (или макро-операторы.), реализующие определенную последовательность действий по вводу/ выводу данных. Например, один из языков диалогового взаимодействия - ДИ-ФОЛ - содержит такие операторы:

DISPLAY - вывести информацию на экран;

UPR - создать незащищенное поле ввода;

NUM - создать цифровое поле;

BRO — создать неотображаемое поле;

BR1 — создать поле нормальной яркости;

Рекомендуемые материалы

BR2 — создать поле, отображаемое с повышенной яркостью.

Следует, видимо, вспомнить, что весьма популярный ныне язык BASIC, как и не менее популярный в свое время язык APL, также создавался изначально как диало­говый язык (BASIC - Beginners All-purpose Symbolic Instruction Code). Судя по всему, именно этим объясняется решение фирмы Microsoft использовать BASIC в качестве встроенного языка приложений. Но об этом чуть позже.

Из всех перечисленных групп языков наибольшее влияние на развитие тех­нологии проектирования и разработки пользовательского интерфейса оказали языки управления базами данных. Еще до начала триумфального шествия «по странам и континентам» графической оболочки Windows 3.* и появления тер­мина Data-Centered Design языки СУБД обеспечивали раздельное описание данных и средств работы с ними. В значительной степени это объясняется самой сущностью использования БД: для различных заданий или для различных пользователей требуется обеспечить разное представление одних и тех же дан­ных. Например, в состав ранних версий СУБД Paradox уже входили такие ком­поненты:

Ask — генерация форм запросов;

Report — разработка спецификаций отчетов;

Create - создание структуры новой таблицы;

Forms — разработка спецификаций экранных форм;

Image - установка пользовательских характеристик представления таблицы на экране (в виде формы или графика).

Более того, в составе СУБД Paradox имеется так называемый генератор прило­жения (Personal Programmer), обеспечивающий создание приложений для работы с БД и способный выполнять свои функции даже при отсутствии на ПЭВМ ядра СУБД. При этом как перечисленные выше компоненты, так и генератор приложе­ний ориентированы в первую очередь на непрограммирующих пользователей. С помощью системы меню и функциональных клавиш генератора приложений пользо­ватели могли создавать собственную конфигурацию интерактивных элементов при­ложения, в том числе выпадающие и иерархические меню, окна, а также средства помощи (окна со справочной информацией). Аналогичные возможности имелись практически во всех развитых СУБД.

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

Чрезвычайно большое влияние на все последующее развитие интерактивных систем оказала растровая графика. Ее применение в качестве основы инструментов визуального программирования привело к появлению принципиально нового типа пользовательского интерфейса — графического (основные концепции GUI были рассмотрены в главе 2).

Средства визуальной разработки, обеспечивающие реализацию объектно-ориентированного программирования, позволяют создавать макет пользовательского интерфейса, используя технологию WYSIWYG (What You See Is What You Get - «что вы видите, то и получите», то есть результат выглядит так же, как и прототип во время разработки). Средства визуальной разработки были созданы практически для всех популярных языков программирования, а также для вновь появившихся (например, для Java). Все эти инструменты обладают двумя основными достоинствами: во-первых, существенно повышают производительность труда программиста, и, во вторых, обеспечивают стандартиза­цию пользовательского интерфейса за счет использования однотипных базо­вых элементов. В результате, глядя на готовое приложение, практически невозможно определить, на каком языке и с помощью какого инструмента оно было создано. Например, на рис. 8.1 представлены два первичных окна, одно из которых было получено с помощью Visual C++, а второе - с помощью Visual Smalltalk.

Наиболее удачно реализованные инструменты визуального программирования позволяют не только формировать облик отдельных окон и диалоговых панелей, но и представлять в наглядной форме взаимосвязь между элементами пользовательс­кого интерфейса (рис. 8.2); это обеспечивает решение многих проблем проектиро­вания интерфейса, рассмотренных в главе 2.

Pиc. 8.1. Первичные окна, созданные с помощью Visual C++ и Visual Smalltalk

Pис. 8.2. Макет пользовательского интерфейса, созданный в среде Visual Smalltalk

Аналогичными возможностями обладают сегодня и многие инструментальные средства, созданные на базе проблемно-ориентированных языков. Например, на рис. 8.3 показан внешний вид окна редактора GIJ Г, входящего в состав пакета MATLAB, а рядом - макет окна, созданного с помощью этого редактора.

Pис. 8.3. Окно редактора GUI пакета MATLAB и созданный с его помощью макет интерфейса

Как и до появления средств визуального программирования, особое место сре­ди других проблемно-ориентированных систем разработки занимают СУБД. При­менение в них технологии WYSIWYG позволило им практически сравняться по мощности и эффективности с универсальными инструментами разработки GUI-приложений. И даже более того, наличие в СУБД средств визуального представле­ния инфологической модели данных позволяет во многих случаях создавать более корректную модель пользовательского интерфейса по сравнению с универсальны­ми инструментами. На рис. 8.4. приведен пример инфюлогической модели данных и экранная форма, созданные в СУБД Access.

В силу того, что интерфейс систем реального времени имеет целый ряд существен­ных особенностей (основные из которых были рассмотрены в предыдущей главе), для его построения используются, как правило, специализированные инструментальные средства. Они сформировались в результате слияния SCADA-систем (Supervisory Control And Data Acquisition system - систем сбора данных и оперативного диспетчер­ского управления) и средств визуального программирования «общего назначения» на

Рис. 8.4. Визуальное моделирование интерфейса приложения в СУБД Access

базе одного из универсальных языков (чаще всего - Visual Basic). Такой симбиоз полу­чил название HMI/SCADA-снстем (или MMI/SCADA), где аббревиатуры HMI и MMI соответствуют термину «человеко-машинный интерфейс» (Human Machine Interface или Man Machine Interface). В настоящее время такие инструментальные сред­ства существуют практически для всех платформ, на базе которых разрабатываются системы реального времени. Интерфейс создаваемых с их помощью приложений зави­сит в основном от специфики конкретной области применения и в значительно мень­шей степени - от используемой операционной системы н ее графической оболочки. Например, интерфейс АРМ оператора, который был приведен на рис. 7.2, создан в графической среде Photon microGUI операционной системы QNX, а интерфейс АРМ, показанный на рис. 8.5 - в среде Windows.

Упоминавшийся выше язык Visual Basic (точнее, одна из его спецификаций — Visual Basic Application — VBA) оказал большое влияние на технологию создания приложений, настраиваемых пользователем. Продуманность и логическая завер­шенность решении, предложенных Microsoft, привела к тому, что VBA прочно занял свою собственную «нишу» среди инструментальных средств формирования пользо­вательского интерфейса приложений. Пожалуй, в этом отношении он является даже уникальным инструментом, и не случайно многие фирмы-производители ПО ли­цензировали VBA у Microsoft с целью использования в качестве встроенного языка приложений.

Рис. 8.5. Интерфейс АРМ, созданный с помощью HMI/SCADA-системы

Несмотря на сумные потенциальные возможности систем визуального программирования, они в большинстве своем обладают одним существенным недо­статком - в них (за редким исключением) изначально не предусмотрена поддержка проектирования разработки и сопровождения создаваемых приложений как еди­ного технологического) процесса. Именно это обстоятельство зачастую негативно влияет как на уровень программного продукта в целом, так и на качество его пользо­вательского интерфейса. Осознание этого факта привело к тому, что разработчики инструментов стали дополнять их относительно самостоятельными компонентами, поддерживающими отдельные этапы жизненного цикла программных продуктов. Например, практически все современные инструменты разработки имеют в своем составе компоненту, предназначенную для управления версиями программного про­дукта (в пакете Visual Studio фирмы Microsoft такая компонента называется SurfaceSafe; аналогичные компоненты имеются и для инструментов разработки на Java). Появились также и специализированные инструменты тестирования GUI-приложений. Одним из наиболее мощных из них на сегодняшний день можно счи­тать продукт Rational Performance Suite фирмы Rational Rose. Данное средство обес­печивает автоматическую генерацию тестов, имитирующих работу пользователя, а также регистрацию и анализ результатов тестирования приложения, прежде всего с точки зрения качества пользовательского интерфейса.

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

Указанного недостатка лишены так называемые CASE-системы (CASE - это Computer Aided Software Engineering - компьютерное проектирование программного обеспечения). Понятие CASE является весьма широким и охватывает как соб­ственно технологию, так и средства ее реализации. Обязательным атрибутом CASE-системы является возможность автоматической (или по крайней мере автоматизированной) генерации кода программы на основе ее спецификации. Су­щественной особенностью CASE-систем является также поддержка практически всех основных этапов жизненного цикла создаваемого приложения, в том числе:

• Стратегическое планирование (описание целей, факторов, ресурсов; моделирование стратегии; формирование структуры плана и политики фирмы-разработчика);

• Описание предметной области (описание объектов предметной области и отношений между ними; интеграция различных моделей предметной области);

• Анализ возможностей реализации (анализ существующих проектов);

• Определение требований (моделирование потоков данных; создание и анализ прототипов; контроль полноты и согласованности требований);

• Системное проектирование (декомпозиция и сборка проекта, имитационное моделирование создаваемого приложения);

• Программирование (генерация кода и анализ его метрических характеристик);

• Тестирование (автоматическая генерация контрольных примеров, регистра­ция и анализ результатов тестирования);

• Документирование (создание и сопровождение библиотеки спецификаций);

• Сопровождение и управление проектом.

Как следует из перечисленных особенностей CASE-систем, их применение спо­собствует проектированию и реализации пользовательского интерфейса, обладаю­щего требуемыми свойствами. Более того, некоторые из таких систем имеют в сво­ем составе компоненты, предназначенные специально для разработки пользовательского интерфейса создаваемого приложения. Например, продукт CASE/4/0 фирмы MicroTOOL GmbH содержит так называемый «дизайнер диалогов», обеспечивающий создание и моделирование пользовательского интерфейса. Вместе с тем, сами по себе CASE-системы достаточно сложны в освоении и исполь­зовании, поэтому эффективность их применения прямо пропорциональна сложно­сти создаваемого продукта.

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

Рис. 8.6. Классификация средств разработки пользовательского интерфейса

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

Существенное возрастание количества и многообразия интерактивных при­ложении, а также расширение области их применения обусловили наличие двух тенденций:

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

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

Согласно [9], инструментальные средства создания пользовательского интер­фейса могут быть отнесены к одному из следующих классов:

• Системы управления пользовательским интерфейсом (User Interface Management System — UIMS);

• Инструментальные средства проектирования и разработки интерфейса (Interface Builder — IB);

• Инструментальные средства разработки интерфейса (Tools&Toolkit — Т&Т);

• Средства прототипирования интерфейса (Prototyping Tools — РТ).

Система управления пользовательским интерфейсом (UIMS) - это интегриро­ванный набор средств, помогающих программисту в создании и управлении различны­ми интерфейсами пользователя. Основной концепцией U I DS является идея разделе­ния интерфейса и прикладной программы (точнее, ее функционального наполнения).

Как правило, UIMS состоит из двух частей: одна обеспечивает разработку ин­терфейса, а вторая - управление пользовательским интерфейсом в процессе его работы с приложением. Многие UIMS имеют собственный язык определения ин­терфейса для представления требуемого диалога и генератор, которой автомати­чески создает необходимый код из исходного описания на этом языке. В идеале UIMS должна, с одной стороны, позволять создавать различные интерфейсы для работы с одним и тем же приложением, а с другой - поддерживать один и тот же интерфейс для различных приложений. Список наиболее распространенных UIMS, доступных через Интернет, приведен и приложении 1. Из рассмотренных выше инструментальных средств к данному классу могут быть отнесены, некоторые CASE-средства и наиболее развитые из систем типа HMI/SCADA.

Рекомендуем посмотреть лекцию "28. Аномалии индивидуального развития".

Класс инструментальных средств проектирования иразработки интерфейса (Interface Builder) образуют средства, которые обеспечивают создание интерфейса определенного (стандартизованного) типа для различных приложений, функцио­нирующих в соответствующей операционной среде. Примерами таких средств мо­гут служить Visual C++ и Delphi для MS Windows, Tk/TCL для XWindows или Photon Application Builder (Phab), обеспечивающий создание GUI-приложений в графической среде Photon microGUI операционной системы QNX. Некоторые пред­ставители данного класса поддерживают только этап проектирования пользова­тельского интерфейса и ориентированы на совместное использование с одним из инструментов визуального программирования.

Инструментальные средства разработки интерфейса (Tools&Toolkit) близки по своим характеристикам представителям предыдущего класса, но либо имеют более огра­ниченные функциональные возможности, либо представляют собой набор (библиоте­ку) элементов, на основе которых могут быть реализованы различные варианты GU I.

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

Взаимосвязь двух аспектов классификации инструментов создания пользова­тельского интерфейса показана на рис. 8.7.

Рис. 8.7. Взаимосвязь двух аспектов классификации инструментов создания пользовательского интерфейса

Список характерных представителей перечисленных классов (доступных в Интернете) приведен в Приложении.