Программирование составных условий

Diomidis Spinellis
Факультет менеджмента Науки и техники
Афинский Университет экономики и бизнеса
Patision 76, GR-104 34 Афины. Греция
электронная почта: dds@aueb.gr Сентябрь 2001 года

Абстрактный

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

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

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

Ключевые слова

Визуальное программирование. Компоненты, рефлексия. Инструменты Unix. Архитектура каналов и фильтров. Повторное использование.

Введение

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

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

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

1]. Подходы к визуальному программированию направлены на облегчение кривой обучения программированию или повышение производительности программирования. Их принятие основывалось на ряде предпосылок [2]:

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

Однако эмпирические исследования не обнаружили. Что визуальное программирование по своей сути превосходит текстовые программы; степень . В которой данная нотация подходит для выражения конкретной задачи . Зависит от контекста. В котором используется язык [3,4,5Ранние работы по визуальному программированию. Хотя и многообещающие в применении к `игрушечнымДля решения этой проблемы были использованы два подхода: ряд исследователей применили визуальные языки программирования к ограниченным или предметно-специфичным частям разработки программного обеспечения. Таким как программирование графического интерфейса. Графическое изображение поведения структуры данных или комбинация текстуально запрограммированных блоков для создания новых программ [1Другие предложили разработку визуальных языков программирования на основе формализмов. Используемых существующими стандартными компонентными визуальными инженерными языками. Такими как стандарт MSC ITU-T для диаграмм последовательностей сообщений или стандарт IEC-1131 для языков функциональных блоков [6 ].

В нашем подходе мы извлекаем выгоду из сильных сторон существующих IDE GUI-builder. Создавая стандартные программные компоненты. Которые могут быть использованы в GUI-designer IDE для выполнения визуального программирования. Ориентированного на поток данных. Хотя мы демонстрируем наш метод в контексте конкретной области (визуальная композиция конвейеров потоков данных). Одни и те же основополагающие принципы могут быть применены к различным областям визуального программирования.

Мы определяем программный компонент как единицу композиции с контрактно заданными интерфейсами и только явными контекстными зависимостями; тот. Который может быть развернут независимо и подлежит составлению сторонними разработчиками [7Компоненты. Как и объекты. Инкапсулируют состояние. Обеспечивают доступ к нему через отдельно описанные интерфейсы и поддерживают модульное проектирование. Основанное на разделении задач. Однако компоненты отличаются от объектов несколькими способами: они могут быть реализованы на разных языках. Часто упакованы в двоичные контейнеры. Могут инкапсулировать несколько объектов и. Как правило. Более надежно упакованы. Чем объекты [8Компоненты. Поддерживающие визуальную композицию. Реализуют набор интерфейсов. Определенных средой визуального программирования. Поддерживающей их использование. Эти интерфейсы обеспечивают визуальное размещение компонентов в формах. Обработку событий пользовательского ввода и постоянную спецификацию их свойств во время разработки программы. Двумя широко распространенными семействами визуальных компонентов являются JavaBeans [9] и элементы управления ActiveX [10].

Визуальные компоненты поддерживаются рядом IDE. Типичными примерами являются Visual Basic (VB). Delphi, JBuilder. Latte и Visual Café. Хотя элементы управления ActiveX. JavaBeans и соответствующие им среды продаются как технологии `визуального программированияРяд систем . Таких как Khoros/Cantata [11,12] и LabVIEW [13] поддержка компонентного визуального программирования — также называемого крупнозернистым визуальным программированием-с использованием специализированных компонентов и соответствующей выделенной среды разработки. Теперь наличие сложных IDE GUI-builder и соответствующих фреймворков разработки компонентов предоставляет нам альтернативный подход к реализации крупнозернистого визуального программирования: подход. Основанный на широко развернутых стандартных отраслевых платформах.

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

Широко изучены элементы нашего подхода: визуальное программирование. Компонентная разработка. Графический интерфейс к инструментам Unix. Визуальные языки потока данных. Архитектуры каналов и фильтров. Например, см. ссылки [2,14,1,15,6] (обсуждение визуального программирования и приводятся примеры специальных подходов), [16,17,18,3] (Обсуждение графический для Unix-инструмент передние концы), [19,20,21,7,22] (обсуждение компонентно-ориентированного развития), [17,23,24,25,26,27] (обсуждение визуального потока данных подходов), и [28,29] (обсуждается архитектура труб и фильтров). Основными вкладами этой статьи являются: предложение использовать стандартные графические конструкторы в качестве сред визуального программирования с помощью специально созданных отражающих компонентов. Идея о том. Что графические конструкторы могут использоваться для настройки сложных взаимодействий компонентов и сценариев развертывания. А также демонстрация взаимодействия визуального программирования и графического интерфейса с использованием хорошо известных инструментов обработки текста Unix. Инкапсулированных в виде компонентов ActiveX.

Источник компонента и среда выполнения

Большинство существующих визуальных компонентов (также известных как элементы управления или виджеты) предоставляют элементы графического интерфейса. Типичные примеры включают текстовые поля ввода, кнопки. Списки, сетки. Переключатели. Графики и диалоги выбора файлов. Несколько визуальных компонентов. Которые обеспечивают вычислительно интересную обработку (например. Microsoft Internet Transfer Control. Используемый для выполнения передачи данных HTTP/FTP). Не используют свое визуальное измерение; они. По-видимому. Упакованы как визуальные компоненты. Чтобы предоставить свои свойства для редактирования с помощью стандартных механизмов редактирования свойств IDE. Наши кандидаты на переупаковку в качестве визуальных компонентов должны были обеспечивать нетривиальную вычислительную функциональность. Поддаваться визуальным манипуляциям и быть доступными для повторного использования. Мы решили основывать нашу работу на многочисленных пользовательских и системных программах. Доступных в рамках реализаций операционной системы Unix. Основываясь на философии Unix. Ориентированной на инструменты. Разработчики программного обеспечения создали большую коллекцию программ. Которые предоставляют одну услугу (например. Сравнение двух файлов. Поиск шаблона. Доставка почты). Не требуя взаимодействия с пользователем. Многие из этих программ реализуются с использованием самых современных алгоритмов. Десятилетиями проходят стресс-тестирование во многих различных приложениях и стандартизируют свой интерфейс и работу в рамках таких усилий. Как POSIX [30]. Инструменты в стиле фильтров Unix можно комбинировать с помощью конвейеров-абстракция с очевидными визуальными коннотациями. Кроме того, многие из этих программ свободно доступны в виде исходного кода в рамках инициатив с открытым исходным кодом. Таких как GNU и BSD. Первоначальный выбор элементов управления визуальным программированием основан на нашей предыдущей работе по интеллектуальному анализу компонентов [31,32], где мы определили язык шаблонов для преобразования таких программ в (невизуальные) компоненты.

Визуальный компонент (элемент управления ActiveX или JavaBean) характеризуется свойствами. Событиями и методами. Свойства влияют на внешний вид (например. Цвет фона). Функциональность или состояние элемента управления или компонента. События-это уведомления. Посылаемые элементами управления или компонентами. Чтобы программы. Использующие их, знали. Что произошло определенное действие (например. Щелчок мыши). Методы-это другие функции. Которые могут быть вызваны из программы. В которой размещен элемент управления или компонент. Для выполнения некоторой обработки. Упаковывая инструменты Unix в виде визуальных компонентов. Мы получаем ряд преимуществ:

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

Мы решили упаковать инструменты Unix в виде элементов управления ActiveX. Основываясь на нашем предыдущем опыте упаковки их в виде объектов COM (Component Object Model) и наличии поддержки фреймворка для эффективной реализации элементов управления. Элементы управления ActiveX можно использовать в различных средах на платформах Microsoft-Intel. Таких как VB IDE и Internet Explorer. Хотя реализация на основе JavaBeans могла бы привести к высокой переносимости компонентов. В нашем случае это неприменимо. Поскольку большинство инструментов Unix реализованы на языке C и не выиграют от переносимости Java на двоичном уровне. Однако наш подход не является специфичным для Microsoft; идеи. Которые мы представляем. Могут быть использованы в любой среде. Поддерживающей визуальные компоненты с базовыми рефлексивными возможностями.

Визуальное программирование

Реализованные нами визуальные компоненты Unix-фильтра (VUFC) поддерживают графическую спецификацию конвейеров потоков данных. Взаимное расположение компонентов на холсте проектирования IDE определяет поток данных между ними. Компоненты, представляющие процессы. Могут иметь входные порты. Которые используются для считывания данных. И выходные порты. Через которые выводятся данные. Двумерная природа канвы дизайна позволяет нам создавать сложные нелинейные топологии фильтров. Поток данных между компонентами по умолчанию следует стандартному в западных культурах направлению сверху вниз и слева направо. Порты нумеруются по часовой стрелке от нижнего левого края элемента управления; эта схема нумерации и используемые значения портов по умолчанию (0 для входа, 1 для выхода) приводят к описанному нами направлению потока данных. Когда программисты хотят переопределить направление по умолчанию. Свойства управления позволяют им указать номер порта. Который будет использоваться для каждой функции ввода или вывода (например. Назначить вход порту 3). Мы нашли схему нумерации портов интуитивно понятной и удобной; однако номера портов также можно было бы указать графическим способом. Реализовав редактор пользовательских свойств (средство. Доступное как для элементов управления ActiveX. Так и для JavaBeans). Элементы управления свободно рисуются в произвольных размерах и положениях с помощью средств графического проектирования графического редактора IDE; элементы управления. Которые находятся очень близко друг к другу. Считаются связанными. Помимо установки нестандартных направлений для потока данных. Программисту нужно только указать параметры фильтра (например. Установить фильтр для сортировки в порядке убывания). Они обычно предоставляются как свойства компонентов и поэтому могут быть легко установлены. Опять же без написания кода. Из редактора свойств IDE. Координирующий компонент помещается на холст. Чтобы синхронизировать действия всех визуальных компонентов. Которые он содержит. Этот компонент можно активировать во время разработки. Чтобы визуализировать текущее состояние подключения всех визуальных компонентов с помощью стрелок ввода и вывода. Кроме того, компонент предоставляет метод времени выполнения для запуска работы конвейера. Активации всех его членов и ожидания завершения обработки.

Наш подход основан на трех типах визуальных компонентов:

Фильтр
компоненты инкапсулируют стандартный процесс в стиле фильтра Unix , такой как сортировка, catили wc. Кроме того, универсальный компонент фильтра позволяет реализовать произвольные команды фильтра; однако работа этого фильтра определяется не конкретными свойствами (например, SortOrder), а единственным свойством. Содержащим обычные параметры командной строки в стиле Unix.
Соединитель
компоненты соединяют два компонента из нашего семейства; они реализуются как визуальная инкапсуляция абстракции канала операционной системы.
Клей
компоненты соединяют наши визуальные компоненты с другими элементами графического интерфейса. Такими как поля редактирования и списки.

Способ визуализации компонентов VUFC на холсте дизайна IDE показан на рисунке 1. Компонент T (pipe split) и элементы управления на его левой стороне перемещают данные в направлении справа налево; они являются единственными. Где свойства назначения портов должны были быть заданы вручную.


vufc.gif
Рис. 1: Компоненты VUFC и их соединения.

Инкапсуляция и эксплуатация компонентов


compon.gif
Рисунок 2: Инкапсуляции визуальных компонентов.

Мы создали визуальные компоненты в двухэтапном процессе. Сначала мы добывали и упаковывали инструменты Unix. Соединители и клей как (не визуальные) компоненты COM. Затем мы упаковали компоненты COM как элементы управления ActiveX. Архитектура полученных компонентов проиллюстрирована на рис. 2.

Реализация COM — компонентов с нуля в C++ не является тривиальной. Каждый компонент. В дополнение к своей пользовательской функциональности. Должен поддерживать регистрацию. Интерфейс для создания экземпляров компонента под названием IClassFactory, создание объектов. Подсчет ссылок. Метод QueryInterface и, возможно. Двойные интерфейсы для поддержки его использования с помощью C++ и скриптовых языков автоматизации. К счастью, эти задачи поддерживаются Microsoft Foundation Classes (MFC). Большим монолитным фреймворком приложений для программирования в Microsoft Windows, а также библиотекой активных шаблонов (ATL) более простой набор классов на основе шаблонов. Которые специально нацелены на разработку компонентов COM. Мы реализовали добытые компоненты с использованием ATL. Активно используя шаблоны C++ и множественное наследование. ATL поддерживает разработку COM-компонентов с краткостью и минимальными затратами времени выполнения. Компонент COM на основе ATL может быть реализован менее чем в 100 строках; большинство из них автоматически генерируется инструментом типа `мастерПоэтому мы нашли ATL идеальным для реализации большого количества Unix-майнинговых компонентов и использовали его в качестве основы для автоматизации задачи. Все подробности этой операции описаны в справочнике [32].

Второй шаг реализации визуального компонента включал добавление функциональности визуального компонента для расширения COM-объектов до полноценных элементов управления ActiveX. Первоначально мы пытались обеспечить эту функциональность. Расширяя реализацию каждого компонента на основе ATL. Но быстро были перегружены сложностью задачи. Мы обнаружили. Что добавление одного свойства к элементу управления требует нетривиального кода и добавления данных в ряд C++. IDL (язык определения интерфейса) и заголовочных файлов. Что еще более важно. Более 100 строк непостижимы и недостижимы код был необходим для обеспечения критически важной для наших нужд функциональности перечисления соседних элементов управления. Затем мы экспериментировали со средствами создания элементов управления ActiveX в среде VB IDE и обнаружили. Что эта операция достаточно упрощена и удобна для программиста. Мы сохранили компоненты на основе ATL в качестве основы для нашей работы. Поскольку их реализация была основана на ряде средств системного уровня (таких как потоки, каналы. Неблокирующий ввод-вывод и клонирование дескрипторов). Которые недоступны в среде VB. Таким образом. Наша архитектура визуальных компонентов включает в себя упаковка каждого COM — компонента в визуальный элемент управления ActiveX и еще один координирующий компонент. Реализованный с нуля в VB.

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


visual.gif
Рисунок 3: Визуальная диаграмма классов компонентов.

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

Основой концепции рефлексии является гипотеза рефлексии Смита [33], которая утверждает. Что рефлексивные программы могут получать доступ к своей интерпретации. Рассуждать о ней или изменять ее. В нашем случае элементы управления ActiveX имеют свойства. Доступные как при разработке. Так и во время выполнения. Которые можно использовать для доступа к их местоположению и перечисления других элементов управления. Существующих на том же холсте. Мы используем эту рефлексивную способность. Чтобы связать визуальное представление элементов управления с их эксплуатационным поведением.

Все визуальные компоненты поддерживают ряд общих свойств и методов. А также некоторые специфические свойства компонентов. Как показано на рис .3. Специфические для компонента свойства используются для предоставления подробных сведений о том. Как элемент управления будет выполнять свою обработку (например, MergeOnly, FoldCase. Reverse) и (в исключительных случаях) для указания визуального потока данных (InPort, OutPort). Общие свойства (Height, Left. Width, Right. Enabled, Name. Visible) предоставляются и реализуются VB IDE и необходимы для поддержки визуального измерения и программируемости элементов управления. Эти свойства включают расположение. Размер и видимость каждого элемента управления. Общие методы (Visualize(), Prepare(). Plumb(), Run(). Execution()) формируют интерфейс. Который должны обеспечивать все визуальные компоненты нашей платформы. Они используются координирующим управлением для организации визуализации и взаимосвязи системы визуального управления как сети взаимодействующих процессов. Методы этого интерфейса работают следующим образом:

Визуализировать
вызывается во время проектирования или во время выполнения. Чтобы предоставить программисту представление о потоке данных по всей системе. Сплошные стрелки используются для обозначения потока данных на входном и выходном портах компонентов клея и фильтра. В то время как одна линия стрелки рисуется от входа к выходу во всех компонентах соединителя (трубы). Каждый компонент отвечает за рисование собственного визуального представления. Он делает это. Перечисляя всех своих подключенных соседей. Сортируя их в соответствии с нашим определенным порядком портов и назначая их соответствующим портам. Указанным программистом.
Подготовить
это первая операция. Выполняемая на всех элементах управления перед запуском сконфигурированной системы. Элементы управления отвечают за настройку своего внутреннего состояния таким образом. Чтобы другие элементы управления могли подключаться к ним. Например, элемент управления pipe создает в этой точке два дескриптора pipe. Предоставление отдельного шага. Используемого перед началом выполнения. Устраняет необходимость соединения компонентов на основе их топологического упорядочения и позволяет использовать более гибкие топологии конвейеров.
Отвес
это вторая операция. Выполняемая на всех элементах управления перед запуском системы. На этом этапе каждый элемент управления подключается к своим соседям. Устанавливая, например. Свой стандартный выход на ручку трубы. К которой он подключается.
Бежать
это метод. Который заставляет компоненты начать обработку своих данных. Это ничего не делающая операция для пассивных компонентов. Реализованных в виде абстракций операционной системы (разъемы. Реализованные в виде труб); активных компонентов (фильтры и клей) на этом этапе запускают отдельный процесс или поток. Этот шаг является последней операцией для запуска работающего конвейера.
Проведение
это метод. Который возвращает true, если элемент управления внутренне обрабатывает данные. Чтобы избежать тупиков. Элементы управления filter и glue обрабатывают свои данные асинхронно как независимые потоки или процессы. Координирующий элемент управления ожидает завершения работы конвейера, отслеживая состояние выполнения всех элементов управления на холсте.

Создание Автоматизированного Управления

параметры команды MergeOnly:bool:-m:False:Объединить уже отсортированные файлы. Не сортировать CheckOnly:bool:-c:False:Проверьте, если заданные файлы уже отсортированы. Не сортируйте Месяц:bool:-M:False:Compare (unknown) 

Рисунок 4: Декларативное описание команды сортировки.

Хотя множество доступных инструментов в стиле фильтров дало нам богатый выбор кандидатов для инкапсуляции в качестве визуального контроля. Это заставило нас понять. Что процесс инкапсуляции является трудоемкой и трудоемкой задачей. Следуя более раннему опыту автоматизации упаковки Unix-инструментов в виде COM-объектов [32] мы определили процесс и реализовали инструменты поддержки для автоматизации создания элементов управления VUFC в стиле фильтров. В частности. Для каждого фильтра. Который должен быть преобразован в элемент управления. Необходимо определить синтаксис и семантику параметров командной строки инструмента. Используя небольшой доменный язык [34]. Пример такого описания фильтра сортировки приведен на рис. 4. Для каждого параметра командной строки фильтра (например,- r) указывается:

  • осмысленное имя которое должно использоваться в качестве соответствующего управляющего свойства,
  • тип опции (bool для автономных опций; string, intили double для опций . Принимающих аргументы соответствующего типа),
  • значение параметра по умолчанию,
  • описательный текст. Который появляется в качестве справки для данного свойства в браузерах объектов компонентов и редакторе свойств IDE, а также
  • соответствующий буквенный код. Ожидаемый фильтром в качестве аргумента командной строки.


sortprop.gif
Рисунок 5: Представление свойств сортировки в среде IDE VB.

Небольшой компилятор, реализованный в Perl [35], компилирует декларативное описание интерфейса фильтра в исходный файл определения управления VB, который реализует соответствующий компонент (например, VUFCsort). Код содержит:

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

Компонент также наследует (из-за ограничений VB. Путем повторного использования исходного кода) и предоставляет в качестве свойств общие методы и свойства стандартного интерфейса VUFC. Пример того. Как свойства автоматически созданного компонента VUFCsort отображаются в среде IDE VB. Можно увидеть на рис. 5. Компоненты типа коннектора и клея по-прежнему должны быть написаны вручную, но усилия. Необходимые для их реализации,-это лишь малая часть усилий. Которые потребовались бы для переупаковки большого количества программ в стиле фильтров без автоматизированного процесса.

Примерное Применение


spell.gif
Рисунок 6: Проверка орфографии с графическим интерфейсом.

Чтобы продемонстрировать жизнеспособность нашего подхода. Мы разработали и внедрили простую графическую проверку орфографии на основе конвейера элементов управления ActiveX. На рис. 6 показана диаграмма взаимодействия компонентов UML средства проверки орфографии.