Содержание

• Способность к адаптации — необходимая черта современного программного обеспечения
   
  • Приложение становится платформой
  • Программные интерфейсы, основанные на технологии COM
  • Скриптовые языки — средство интеграции программных объектов
• Microsoft Visual Basic for Applications и VBA SDK
  • VBA как ответ Microsoft на требование адаптируемости
  • VBA SDK: Microsoft предлагает разработчикам использовать VBA для обеспечения адаптируемости приложений
  • Опыт использования VBA SDK
• ActiveX Scripting как возможная альтернатива VBA
  • Возможные причины отказа от VBA
  • Технология ActiveX Scripting
  • Преимущества и недостатки ActiveX Scripting
  • Практическое использование ActiveX Scripting при разработке адаптируемых приложений

Способность к адаптации — необходимая черта современного программного обеспечения

Приложение становится платформой

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

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

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

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

Одной из причин, длительное время затруднявших создание адаптируемых приложений, было отсутствие у разработчиков соглашения о том, в каком виде должны предоставляться программные интерфейсы, требуемые для адаптации. В последние годы широкое распространение технологии COM (Component Object Model) практически сняло эту проблему, по крайней мере, для ОС Windows. Приложения предоставляют свою функциональность для адаптации и повторного использования в виде объектной модели — структурированного множества объектов COM, взаимодействуя с которыми разработчики конечных решений получают доступ к функциональности приложения.

Скриптовые языки — средство интеграции программных объектов

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

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

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

Microsoft Visual Basic for Applications и VBA SDK

VBA как ответ Microsoft на требование адаптируемости

Компания Microsoft предлагает классическое решение проблемы адаптируемости приложений, прекрасно иллюстрирующее приведенные выше принципы. Разумеется, речь идет о Visual Basic for Applications (VBA) — средстве разработки, встроенном в такие известные продукты, как Microsoft Office и Microsoft Visio.

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

В результате Microsoft Office и VBA образовали новую платформу. Множество независимых разработчиков предлагают для нее пользующиеся спросом решения, что является решающим доказательством успеха и перспективности данного подхода.

VBA SDK: Microsoft предлагает разработчикам использовать VBA для обеспечения адаптируемости приложений

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

Таким образом, нет никаких причин, которые мешали бы независимым разработчикам подключать VBA к своим приложениям, обеспечивая тем самым их адаптируемость наравне с приложениями Microsoft Office. На самом деле компания Microsoft заинтересована в подобной практике, поскольку это способствует росту популярности VBA среди разработчиков и делает его фактическим стандартом средств адаптации приложений. Использование VBA дает определенное конкурентное преимущество, и многие крупнейшие поставщики программного обеспечения (Autodesk, Corel, Micrografx и т. д.) лицензировали VBA для использования в своих продуктах.

Чтобы поддержать стремление разработчиков использовать VBA для придания адаптируемости своим приложениям, компания Microsoft выпускает VBA Software Development Kit (VBA SDK), включающий, помимо собственно VBA, документацию, необходимую для использования VBA в приложениях. Распространением и поддержкой VBA занимается компания Summit Software (EN). Там можно бесплатно получить свою копию VBA SDK с испытательной лицензией и проделать всю техническую работу по интеграции VBA в свое приложение до заключения с Microsoft договора о лицензировании.

Опыт использования VBA SDK

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

Итак, как и следовало ожидать, VBA представляет собой иерархически организованное множество COM-объектов, которое в терминах VBA SDK носит название APC — Application Programmability Component. APC реализует ряд интерфейсов, с помощью которых он получает от приложения необходимую ему информацию: корневой элемент объектной модели приложения, сообщения Windows, команды управления пользовательским интерфейсом VBA, поддерживаемое приложением хранилище для внутренних данных VBA и т. д. С другой стороны, приложение само должно соблюдать определенные требования, чтобы быть совместимым с VBA.

Таким образом, общая схема взаимодействия приложения и APC выглядит примерно так:

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

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

Упрощенная часть описывает процесс интеграции VBA в приложения, реализованные на Visual C++ (с использованием библиотеки классов MFC), и Visual Basic (ActiveX EXE). Для проекта на VB предлагается использовать Integration Wizard, который сводит почти всю работу к указанию каталога с проектом и нескольким нажатиям кнопок. Что было бы замечательно, если бы основным инструментом разработки адаптируемых приложений был Microsoft Visual Basic. Описание интеграции VBA в MFC-приложение мало отличается от упомянутого Integration Wizard: вам буквально указывают, в какие места исходных файлов нужно добавить определенные строчки кода, чтобы все работало как надо. При этом довольно трудно составить представление об архитектуре и принципе действия APC в необходимом для разработчика объеме.

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

Полная документация к VBA SDK содержит детальное описание всех сущностей COM (интерфейсов, коклассов и т. д.), реализуемых APC. Она очень подробна и включает множество технических деталей, в результате чего ее объем достигает нескольких десятков мегабайт (в виде .chm-файлов) на CD-ROM. Очевидно, изучить ее целиком едва ли в человеческих силах, так что приходится больше рассчитывать на примеры и технические статьи, предлагаемые Summit Software.

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

Весной 2000 года мы занимались интеграцией VBA в наш программный продукт TOPAZ XXI Graphics, представляющий собой специализированный графический пакет для промышленных приложений, интенсивно использующих графическое представление данных. Пакет реализован на Microsoft Visual C++ с применением библиотек MFC и ATL. В процессе работы по интеграции VBA выявился целый ряд проблем, преимущественно идеологического плана, которые привели нас к решению не использовать VBA в текущей версии продукта. Между тем, не исключен пересмотр этого решения в будущем.

ActiveX Scripting как возможная альтернатива VBA

Возможные причины отказа от VBA

Несмотря на отмеченные выше недостатки VBA SDK, невозможно отрицать, что VBA представляет собой очень мощное и грамотно реализованное средство придания адптируемости приложениям. В сущности, главное, что требует VBA от приложения — предоставлять свою функциональность в форме объектной модели. Тем не менее, может быть достаточно много причин, склоняющих разработчиков приложений (даже вполне осознавших важность адаптируемости) к отказу от использования VBA.

Во-первых, многие приложения не схожи по архитектуре с Microsoft Word или Microsoft Excel. Например, пакет может состоять из двух приложений, одно из которых является средством разработки и порождает некоторые документы. Второе приложение является средой выполнения и только раскрывает некоторую функциональность, заложенную первым. В качестве примера такого пакета можно привести пару Front Page-Internet Explorer. И если интеграция VBA в средство разработки, вероятно, не вызовет проблем, то для среды выполнения VBA не очень подходит — потому что исполняющая система громоздка, отладка и изменение проекта не требуются, модификация документов запрещена, а объектная модель средства разработки не обязательно совпадает с объектной моделью средства выполнения.

Во-вторых, VBA хорошо подходит для «тяжелых» приложений флагманов индустрии, формирующих целые направления в программном обеспечении. Таких как Microsoft Office, AutoCAD, Corel Draw! и тому подобные. Однако существует огромное количество не столь универсальных приложений, разрабатываемых небольшими коллективами из нескольких человек, для которых VBA просто слишком «велик». Хотя бы потому, что включение его в дистрибутив затруднит распространение продукта через интернет вследствие многократного увеличения объема. А ведь эти приложения также испытывают потребность в адаптируемости. То же самое относится к некоторым типам рабочих мест промышленного назначения, аппаратные ресурсы которых слишком ограничены для VBA.

В-третьих, некоторые технические аспекты VBA могут быть достаточно неприятны для использующего его приложения. В частности, для сохранения содержимого проекта и различной дополнительной информации приложение обязано предоставить APC-реализацию интерфейса хранилища (IStorage). Для некоторых приложений это может быть достаточно непростой задачей, ведущей к неестественной архитектуре. Лучше всего, разумеется, если ваше приложение изначально хранит свои документы в структурированных файлах (как это делают приложения Office).

В-четвертых, VBA SDK и Summit Software явно рассчитывают на то, что ваше приложение реализовано либо на Visual C++, либо на Visual Basic. Если же это не так (что весьма вероятно, учитывая популярность Borland Delphi и Borland C++ Builder), то задача интеграции значительно усложняется. Хотя бы потому, что примеры будут на «не родном» языке программирования и/или использовать специфические приемы и библиотеки (MFC и ATL), хорошо известные только программистам, использующим средства разработки от Microsoft.

И, наконец, не всем программистам, способным адаптировать приложения, нравится язык VBA — Visual Basic. В частности, многие программисты с опытом разработки клиентских скриптов для веба предпочли бы что-то похожее на JavaScript.

Суммируя, можно сказать, что чем больше ваше приложение имеет сходства с приложениями Office (во всех отношениях), тем проще и логичнее использовать VBA для его адаптации. И наоборот, различия могут подтолкнуть вас к поиску другого, более адекватного, средства обеспечения адаптируемости.

Технология ActiveX Scripting

Не имея возможности (по тем или иным причинам) использовать VBA в своем приложении, многие разработчики склоняются к использованию технологии, известной как ActiveX Scripting. Сущность этой технологии заключается в том, что приложениям предоставляется возможность запускать программы на скриптовых языках (VBScript, JScript и т. д.).

Для реализации этой возможности приложение использует специальные COM-объекты, называемые Script Engine. Каждый Script Engine должен реализовывать ряд интерфейсов, наиболее характерными из которых являются IActiveScript и IActiveScriptParse. В системе может быть зарегистрировано множество Script Engine, поддерживающих различные скриптовые языки. Таким образом, одно и то же приложение может в одном сеансе работы исполнять скрипты, написанные на разных языках.

Чтобы воспользоваться услугами Script Engine, приложение должно, в свою очередь, предоставить специальный COM-объект (клиентский узел скрипта, Script Site), реализующий интерфейсы IActiveScriptSite, IActiveScriptSiteWindow (и, может быть, еще ряд других). Посредством этой связки (Site-Engine) приложение направляет код скрипта на выполнение в Script Engine, добавляя в пространство имен скрипта элементы своей объектной модели. В результате, код скрипта получает контроль над поведением приложения в той степени, которую допускает объектная модель. Такое приложение называется ActiveX Scripting Host, наиболее известным примером является Microsoft Internet Explorer.

Преимущества и недостатки ActiveX Scripting

Использование ActiveX Scripting имеет ряд существенных преимуществ по сравнению с использованием VBA. Это очень «легкая» технология, которой требуются лишь минимальные системные ресурсы. Кроме того, это очень гибкая технология, за счет высокой степени модульности ее архитектуры. И, наконец, эта технология является, по сути, частью операционной системы Windows. Это следует из того, что первоначальной целью разработки ActiveX Scripting была поддержка выполнения скриптов, внедренных в веб-документы, исполняемые Internet Explorer. Поскольку сейчас Internet Explorer является неотъемлемой частью Windows, все необходимое для работы ActiveX Scripting, включая Script Engine для VBScript и JScript, всегда присутствует в системе.

Говоря о недостатках ActiveX Scripting, справедливо отмечают, что эта технология использует позднее связывание при обращении к методам и свойствам COM-объектов, в противоположность раннему связыванию, поддерживаемому VBA. Позднее связывание действительно ведет к некоторой потере производительности, особенно при обращении к внутрипроцессным объектам, находящимся в .dll-файлах. Однако не стоит забывать, что назначение скриптов — служить «клеем» для объектов, а клеевой шов всегда должен быть тонким. Если скрипт содержит много кода и имеет низкую производительность имеет смысл перенести этот код в отдельный ActiveX компонент, реализованный на C++, Delphi или VB.

Еще одной проблемой, возникающей при использовании скриптов, является то, что только именованные объекты, помещенные в пространство имен скрипта, могут служить источниками событий (т. е. нет аналога декларации WithEvents из VBA). Это действительно серьезная проблема, хотя актуальность ее не так велика для относительно «плоских» объектных моделей, характерных для небольших приложений.

И, наконец, существуют некоторые разновидности методов объектов, допустимые в VBA, которые невозможно использовать из скриптов. Речь идет (в терминах VB) о параметрах процедур, возвращаемых по ссылке, и имеющих тип, отличный от Variant. При попытке вызвать такую процедуру из скрипта возбуждается исключение Type mismatch. К счастью, в реальных объектных моделях такие методы встречаются редко, и модель всегда можно изменить так, чтобы исключить их использование.

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

Чтобы сделать это утверждение более понятным, рассмотрим архитектуру VBA с другой точки зрения. Итак, VBA включает (по крайней мере): исполняющую систему, блок сопряжения с приложением, менеджер проектов, редактор исходных текстов, отладчик, средство просмотра библиотек типов, дизайнер форм. Из этого набора ActiveX Scripting предоставляет, по сути, только исполняющую систему (в форме объектов Script Engine) и некоторые системные сервисы для поддержки отладки (Process Debug Manager). Все остальное разработчики приложения должны реализовать самостоятельно: объекты Script Site с поддержкой отладки, менеджер проектов, редактор исходных текстов, средство просмотра библиотек типов, интерактивный отладчик. Эта задача является особенно сложной для небольших коллективов программистов, поскольку разные ее части требуют разных навыков: от программирования графики до профессионального поиска крох информации в MSDN Online (без чего невозможно реализовать отладчик).

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

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

Вопрос практического использования технологии ActiveX Scripting рассмотрим далее на примере поставляемого нами пакета TOPAZ XXI Graphics.

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

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

Эксплуатация пакета подтвердила правильность подхода к адаптации приложений с использованием ActiveX Scripting. Дополнительно учитывая, что TOPAZ XXI Graphics входит в состав серии продуктов — TOPAZ XXI, в текущей версии было решено разработать отдельный компонент, который смог бы обеспечить адаптируемость и другим приложениям серии, в частности, реализованным с использованием средств разработки от Borland. Решение о реализации компонента принималось, естественно, и с учетом возможности распространения его в виде отдельного SDK.

Полученный в результате компонент получил рабочее название SHIC (Scripting Host Implementation Component). Архитектура SHIC имеет ряд общих черт с рассмотренной выше архитектурой VBA, что обусловлено сходством решаемых задач. И хотя функциональность SHIC является лишь подмножеством функциональности VBA, SHIC выгодно отличается большей простотой в использовании, гибкостью, малым потреблением ресурсов. На наш взгляд, SHIC представляет весьма реальную альтернативу в тех случаях, когда использование VBA не оправдано или же невозможно.

Рассмотрим архитектуру SHIC более подробно, обращая внимание на черты сходства и различия с VBA. SHIC включает следующие основные модули:

• Модуль сопряжения с адаптируемым приложением. Обеспечивает надлежащую инициализацию SHIC при запуске приложения и освобождение ресурсов при его завершении. Предоставляет методы управления элементами пользовательского интерфейса SHIC, уведомляет приложение о различных событиях внутри SHIC. Также предоставляет возможность сохранять и восстанавливать состояние SHIC в виде строки формата XML.
• Менеджер проектов. Проект — совокупность скриптов, объединенных некоторой смысловой общностью. Проект имеет набор атрибутов, которые могут интерпретироваться SHIC или приложением. Каждый скрипт в проекте, также может иметь свои атрибуты. Атрибут представляет собой пару имя-значение, например, атрибут с именем Language может принимать значения VBScript, JScript и т. д. Посредством менеджера проектов приложение может управлять проектами, отдельными скриптами внутри проектов, и атрибутами, в частности, запускать и останавливать скрипты.
• Редактор исходных текстов (совмещенный с отладчиком). Представляет собой текстовый редактор, ориентированный на работу с исходными текстами скриптов. Реализует возможности, характерные для большинства подобных инструментов: синтаксическое выделение, точки останова, пошаговое выполнение, просмотр и изменение текущих значений переменных, вычисление выражений.
• Средство просмотра библиотек типов. По функциональности и пользовательскому интерфейсу данный модуль аналогичен Object Browser из VBA. Наличие этого инструмента значительно увеличивает удобство работы пользователя, поскольку скриптовые языки не допускают использования типизированных переменных.

Рассмотренные выше составные части компонента SHIC являются по сути «двойниками» соответствующих модулей VBA, используя при этом альтернативную исполняющую систему. Отличительным моментом SHIC является отсутствие средств разработки форм. Это продиктовано, в том числе, и желанием сохранить «легкость» решения, поскольку формы требуют бинарного формата хранения, в отличие от строки XML используемой в SHIC. Тем более, что в большинстве случаев создание форм не является для разработчиков серьезной проблемой, поскольку они могут быть реализованы с использованием любых средств разработки, обеспечивающих создание компонентов ActiveX (VB, Delphi, Visual C++ и т. д.). А перемещение кода, обрабатывающего пользовательский ввод, во внешние компоненты, зачастую только улучшает архитектуру решения и облегчает его сопровождение.

Пользовательский интерфейс SHIC

Таким образом, SHIC вполне достойно справляется с задачей преобразования приложения (имеющего объектную модель) в ActiveX Scripting Host. Важнейшим достоинством компонента можно счтитать то, что SHIC сам является в каком-то смысле адаптацией. Он не затрагивает ничего из того, что уже создано и документировано Microsoft. Таким образом, по мере того, как будет развиваться технология ActiveX Scripting, совершенствоваться исполняющая система скриптов и средства отладки, характеристики и возможности SHIC будут только улучшаться.

Увидеть SHIC в действии возможно, загрузив испытательную копию TOPAZ XXI Graphics по адресу www.shkola-info.ru/topaz. Мы планируем и дальше развивать SHIC, поскольку считаем ActiveX Scripting мощной и эффективной технологией создания адаптируемых приложений. Если вы разделяете эту точку зрения, то на нашем сайте найдете самую новую информацию об этом компоненте, полную документацию и примеры кода.