Источник: http://www.asutp.ru/?p=600212
Сегодня разработчики АСУТП реального времени сталкиваются с обескураживающим количеством предложений при выборе средств для создания графического интерфейса. Однако назначение появившихся на рынке многообразных средств не всегда одинаковое, что требует осторожности в вопросе о том, соответствует ли выбранное средство основным графическим требованиям создаваемого приложения.
В общем случае, любое средство для создания графического интерфейса должно решать две главные задачи: сокращать цикл разработки (обладать производительностью) и обеспечивать защиту инвестиций в проект (минимизировать доработки). Проанализируем две эти задачи:
Хотя всё это кажется достаточно очевидным, здесь таится множество ловушек. Прокомментируем по порядку.
Например, гибкость как аспект производительности только частично зависит от того, предлагает ли средство разработки достаточно богатый набор "стандартных" возможностей. Важен также и ответ на вопрос, может ли разработчик расширить эти возможности, используя устойчивый интерфейс прикладных программ (API), различные сценарные утилиты или собственные процедуры, вызываемые из графики, созданной с использованием данного средства.
Удобство проектирования экранных изображений в общем понимании означает наличие мощных и интуитивно понятных средств рисования. Всё более и более эти средства позволяют редактировать в пределах области рисования несколько экранных изображений, либо разделяющих общие элементы, либо логически взаимосвязанных в результате взаимодействий с пользователем.
Удобство предварительного просмотра поведения экранных изображений имеет большее значение для приложений с высокой степенью использования графики и динамичности (в том смысле, как все эти термины определяются ниже). Так, важно бывает посмотреть, без компоновки со всей прикладной программой, как изменится представление реального агрегата после ввода с помощью редактора каких-либо имитированных данных. Как сказано и в предыдущем комментарии, наблюдается тенденция к возможности предварительного *просмотра поведения не только отдельного экранного изображения, но и нескольких изображений, связанных между собой в результате взаимодействия с пользователем.
Простота переноса на другие платформы означает, по крайней мере то, что графические структуры, созданные на одной платформе, могут использоваться и на платформе другого поставщика без модификации. Более глубокий смысл этого требования предполагает то, что объекты графического управления, такие как "widgets" среды Motiff или "controls" Microsoft автоматически приобретают правильную форму в зависимости от среды, в которой компонуется и выполняется прикладная программа.
Если, как это часто бывает в приложениях АСУТП, разработчик понимает, что разрабатываемый интерфейс должен быть "глубоким" (то есть настоящим графическим, очень динамичным или с большим количеством переходов), то возникает вопрос, следует ли принести простоту использования, в смысле легкости разработки, в жертву требуемой функциональности.
Уже проверено опытом, что после создания плана идеального интерфейса возможности имеющихся средств оказываются недостаточными и необходимо снижать запланированную функциональность. Если недостающая функциональность всё же необходима, разработчику приходится обеспечивать ее трудоёмким ручным кодированием на нижнем уровне. Компенсацией такой уступки является то, что средство разработки интерфейса обычно позволяет реализовать значительную часть необходимой функциональности в виде полностью предконфигурированого "чёрного ящика".
В то же время, опытным программистам часто неудобны такие "черные ящики", поскольку они привыкли к более детализированному управлению при настройке и расширении приложений на субкомпонентном уровне.
Идеальное средство разработки должно предлагать столько функциональности через готовые конфигурированные модули, сколько возможно, но должно также обеспечивать и программные средства для расширения и модификации этих модулей (то есть, с точки зрения разработчиков они не должны быть "чёрными ящиками ").
И снова полезно исследовать простоту использования с точки зрения трех обсуждавшихся выше "измерений".
Простота использования средства разработки графического интерфейса обеспечивается прежде всего графическим редактором или средством рисования, которое позволяет разработчику рисовать графические элементы проектируемой экранной картинки и описывать атрибуты создаваемых объектов, не прибегая к программированию. Оставляя на обсуждение ниже вопрос о динамических атрибутах, основные возможности такого средства рисования должны включать:
оследний пункт заслуживает отдельного комментария. Программы АСУТП испытывают все возрастающую потребность предоставлять операторам средства создания новых экранных схем для изображения новых конфигураций оборудования. В дополнение к изменениям реального оборудования оператор должен добавлять новые схемы для отображения этих изменений. У оператора может возникнуть желание модифицировать конфигурационную базу данных с автоматическим изменением экранных схем или отредактировать графику с автоматическим изменением конфигурационной базы данных. В результате возникает важный аспект простоты использования приложений АСУТП -а именно, насколько легко могут быть созданы такие специализированные редакторы, и насколько просто с помощью такого редактора оператор может решить свои задачи, не прибегая к программированию.