Кристофер Уильсон, вице-президент SL Corp.

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

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

Основные задачи средств разработки графического интерфейса

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

Производительность

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

Защита инвестиций (минимизация доработок)

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

Хотя всё это кажется достаточно очевидным, здесь таится множество ловушек. Прокомментируем по порядку.

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

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

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

Простота переноса на другие платформы означает, по крайней мере то, что графические структуры, созданные на одной платформе, могут использоваться и на платформе другого поставщика без модификации. Более глубокий смысл этого требования предполагает то, что объекты графического управления, такие как “widgets” среды Motiff или “controls” Microsoft автоматически приобретают правильную форму в зависимости от среды, в которой компонуется и выполняется прикладная программа.

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

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

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

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

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

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

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

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

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

Анализ графической “глубины” проектируемого приложения

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

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

• насколько “графическим” является приложение?
• насколько динамической или удовлетворяющей требованиям реального времени должна быть графическая часть?
• сколько переходов состояний при этом используется и насколько они сложны?

Первый из этих трех вопросов отражает тот факт, что термин “графический пользовательский интерфейс” (GUI – graphical user interface) до сих пор используется на рынке для обозначения интерфейса, который хотя и является графическим по отношению к интерфейсам на основе символьных терминалов, но в действительности не является “истинно” графическим, так как использует в основном текстовые объекты – меню и диалоги – а не изображения реальных управляемых объектов.

Большинство имеющихся на рынке средств может классифицироваться как GUI-конструкторы. Это означает, что они предназначены для создания интерфейсных GUI-средств (меню, диалогов, окон просмотра и т.д.) в конкретной среде, в основном в Х Windows/Motif или Windows NT/95. Говоря в целом, эти средства предоставляют редакторы, которые могут легко создавать объекты среды Motif (widgets) или объекты на базе фундаментальных классов Microsoft (Microsoft Foundation Class-based Controls (ниже MFC-объектов), но не предоставляют общих графических средств для создания представлений реальных объектов управляемого процесса.

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

Зачастую они с запозданием понимают, что такой конструктор предоставляет им только widget-объекты в области рисования или документы в формате Windows, которые должны быть обеспечены “истинно” графическими средствами из других источников, и что заполнение этих пустых окон, даже если на них приходится 20% всего интерфейса, может занимать до 80% времени разработки.

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

Недавно для решения этой проблемы в целом ряде GUI-конструкторов были добавлены общие средства рисования. В некоторых случаях, для отличия от GUI-средств, не содержащих подобной возможности, их обозначают как VGUI-средства (VGUI – very graphical user interface – настоящий графический пользовательский интерфейс). Это свидетельствует о важности оценки планируемого интерфейса с точки зрения первого “измерения”, меняющегося в диапазоне от “ненастоящий графический” (объекты управления только на базе текстов), до “настоящий графический” (требующий много “истинно” графических изображений реальных элементов).

Следующее измерение при анализе требований к графическому интерфейсу – это степень “динамичности” его графики. Лишь в редких случаях для прикладной АСУТП достаточно простого сочетания GUI-объектов и статической графики.

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

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

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

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

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

“Этот жизненный цикл [то есть объект в реальном процессе - комм. К. У.] формализуется через модель состояний: набор состояний и событий. Состояние объекта представляет ситуацию или условие, во время которых применимы определенные физические законы, правила или тактики поведения. Событие представляет некоторое происшествие, которое вызывает переход объекта из одного состояния в другое.” (из книги Шлера и Меллора “Жизненные циклы объектов, моделирование мира через состояния.” – Shiaer and Mellor, Object Lifecycles, Modelling the World in States, Yourdon Press).

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

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

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

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

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

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

Необходимо ли отказываться от функциональности ради простоты использования?

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

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

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

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

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

И снова полезно исследовать простоту использования с точки зрения трех обсуждавшихся выше “измерений”.

Степень использования графики

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

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

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

Динамичность

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

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

Переходы состояний

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

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

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

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

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

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

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

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

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

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

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

Источник: Real-Time Magazin, 4/95