Программируемые приложения нужны всем
Оснащение программ механизмом настройки и средствами расширения - объективная тенденция развития функциональности самых разных приложений. С помощью таких средств конечный пользователь может адаптировать программные продукты к специфике своей конкретной задачи.
Интересно, что в последнее время потребность в программируемых приложениях стали испытывать не только разработчики коммерческих продуктов, но и ИТ-подразделения, которые создают (или заказывают) программы для своих компаний. В последнем случае корпоративные клиенты сталкиваются с трудностями, связанными с поддержкой единых стандартов в разных подразделениях. Попытки же жесткой централизации всех разработок в едином ИТ-отделе обычно заканчиваются шквалом заявок от разных структур корпорации с требованием реализовать ту или иную функцию. Поэтому вопрос о создании приложений, гибко адаптируемых к нуждам конкретных пользователей в различных подразделениях, является весьма актуальным.
Предложения от Microsoft
Примеров программируемых приложений можно привести довольно много, наиболее известным и массовым среди них является пакет MS Office (подробнее см. PC Week/RE, № 44/99, с. 26). Сегодня именно он как бы задает стиль и основные стандарты для создания подобных продуктов, базирующихся на двух ключевых элементах:
- унифицированной иерархической объектной модели на основе OLE Automation и COM;
- едином средстве программирования - языке VBA.
Однако с точки зрения отраслевых стандартов самое важное то, что начиная с версии VBA 5.0, которая входила в состав Office 97, Microsoft продвигает этот программный механизм в качестве стандартного средства управления программируемыми приложениями, создаваемыми независимыми разработчиками. За прошедшие с тех пор три года лицензии на его применение приобрели более 150 фирм. Среди них есть и компании с мировыми именами (Autodesk, Adobe, PeopleSoft, Baan, SAP, Solomon Software и др.), и небольшие организации.
Сначала Microsoft предоставляла лицензии на VBA только разработчикам коммерческих продуктов (ISV, Independent Software Developer). Однако начиная с сентября 1999 г. их могут получить и корпоративные заказчики, создающие приложения для внутреннего использования. А в конце 1999 г. среди пользователей VBA появились первые российские компании.
Какой вариант автоматизации выбрать
Следует подчеркнуть, что VBA не является единственным вариантом механизма программирования в среде приложений. И первым делом разработчик решает вопрос, создавать ли подобный механизм самому или взять готовый со стороны. Оба подхода имеют свои плюсы и минусы.
Так, российские компании (“1С”, R-Style и некоторые другие) пока явно предпочитают создавать собственную инструментальную платформу. Доводы в пользу данного выбора приводятся довольно веские: существенное снижение (по сравнению с использованием MS Office) требований конечных приложений к ресурсам компьютеров (памяти и быстродействию), оперативные и гибкие возможности в модернизации, независимость от внешних поставщиков. Такому решению способствует то, что в России много сильных программистов, готовых делать программы класса инструментов разработки за относительно небольшие деньги.
Вероятно, пока подобный подход вполне оправдан, хотя в перспективе виден ряд проблем, связанных с быстро растущими затратами на поддержку и развитие платформы. Во всяком случае, реализация такого механизма является весьма трудоемким процессом, одолеть который способны лишь очень сильные коллективы. (На Западе даже крупные разработчики предпочитают модель глубокого разделения труда, когда одни компании занимаются созданием платформ, другие - приложениями для конечного пользователя.) И этот путь тем более не под силу корпоративным программистам, создающим внутрифирменные приложения.
Но есть и другие подходы - один из них, например, реализован в продуктах фирмы Golden Software (см. PC Week/ RE, № 29/99, с. 16). Эти продукты поддерживают вариант объектной модели, в целом соответствующий структуре MS Office 97/2000. Однако для создания и исполнения сценариев в самих пакетах применяется автономное приложение Scripter.0, которое фактически представляет собой облегченный вариант Visual Basic, реализованный на базе технологий независимых разработчиков - компаний Sax Software и Polar Engineering and Consulting. (Golden Software все же реализует принцип разделения труда: она пользуется готовыми решениями других поставщиков.)
Компакт-диск VBA 6.0 SDK 6.1
Технология интеграции Microsoft VBA основана на использовании специального набора для разработчиков VBA Software Development Kit (SDK). Его последняя версия, VBA 6.0 SDK 6.1, была представлена в сентябре прошлого года. Набор доступен для изучения на реальных приложениях пользователей, его можно переписать с сервера http://msdn.microsoft.com/vba/ или там же заказать бесплатный компакт-диск. Обратите внимание, что данный пакет является рабочим вариантом - для его практического использования в реальных приложениях достаточно купить лицензию.
Прежде чем начинать работу с VBA SDK, следует ознакомиться с документами из разделов Release Notes и Welcome Guide дистрибутива. По завершении инсталляции запустите программу Vbasetup.exe, чтобы выбрать необходимую вам версию VBA 6.0 - Debug или Release (соответственно для отладки и создания окончательных вариантов программ). Следует иметь в виду, что VBA-компоненты отладочной версии несовместимы с приложениями MS Office 2000 (это означает, что их нельзя устанавливать на один и тот же компьютер).
Компакт-диск содержит набор документации с описанием различных вариантов интеграции VBA в бизнес-приложения. Там же находятся пять примеров приложений, демонстрирующих интеграцию с VBA с использованием инструментария Microsoft Foundation Class (MFS) и Active Template Library (ATL), многопотоковых DLL и специального мастера VB Integration Wizard.
Технология APC
Основная идея технологии интеграции состоит в том, что механизм VBA вместе со своей средой разработки встраивается в хост-приложение как внутрипроцессный (in-process) сервер. В результате некоторое готовое бизнес-приложение получает дополнительные возможности создания макрокоманд, аналогичные тем, что реализованы в офисных приложениях Microsoft.
Физически интеграция VBA в хост-приложение выполняется с помощью ключевого инструмента - Application Programmability Component (APC) корпорации Microsoft, который представляет собой иерархический набор COM-объектов, формирующих промежуточный программный слой для связи с ядром VBA API (рис. 1). Эти объекты содержатся в библиотеке Microsoft APC 6.0 Object Library (Apc60.dll).
Рис. 1. Подключение среды VBA выполняется через систему объектов Application Programmability Component
APC обеспечивает полную поддержку классов, совместимых с ATL и MFC, а также ActiveX-объектов. В состав SDK входит полное руководство Visual Basic APC Reference Manual, описывающее набор объектов из библиотеки APC. Справочник VB Programmer’s Guide демонстрирует, как компонент APC реализует конкретные функции VBA.
Разработчики приложений на основе VB и Delphi должны использовать APC напрямую. При этом для VB-программистов имеется специальный мастер VB Integration Wizard, существенно упрощающий процесс интеграции. Для разработчиков, применяющих C++ и MFC, в составе VBA 6.0 SDK 6.1 имеются специальные программные средства, называемые соответственно APC/C++ и APC/MFC.
Первый взгляд
В ходе изучения VBA 6.0 SDK 6.1 мы создали небольшое, но законченное приложение в среде VB 6.0 (многооконный текстовый редактор с минимальным набором функций), в которое впоследствии с помощью мастера VB Integration Wizard интегрировали VBA. Затем, уже в среде нового приложения со встроенным VBA, мы написали простые макрокоманды, позволяющие изменять цвет фона окна исходного текстового редактора (рис. 2). В ходе работы у нас возник ряд вопросов (разрешить их с помощью документации не удалось), однако сегодня, уже зная все ответы на них, мы могли бы всего за десять минут повторить всю процедуру создания интегрированного приложения и VBA-проекта для него.
Рис. 2. Мы создали текстовый редактор TextEdit6, подключили к нему среду VBA (на заднем плане),
а в ней реализовали VBA-проект с макрокомандой коррекции фона окна редактора
Основное впечатление таково, что стандартный мастер VBA пока может делать не очень много, а чтобы получить даже простое законченное приложение, нужно “работать руками”. Более того, приходится вносить небольшие исправления в код, написанный мастером.
Реализация этого тестового примера позволила лучше понять суть процедуры интеграции VBA в автономное приложение. Фактически у нас в одной программе объединились два компонента - наше бизнес-приложение и среда VBA, - каждый из которых является одновременно и ActiveX-контейнером, и ActiveX-сервером.
Обращаясь из среды текстового редактора к макрокомандам, загружаемым в виде разнообразных автономных VBA-проектов, мы получили в свое распоряжение новые, не существовавшие ранее функции. Более того, такие макрокоманды можно писать непосредственно в процессе выполнения приложения, причем для их реализации доступна вся мощь VBA (работа с базами данных, создание визуального интерфейса, средства отладки, использование внешних ActiveX-компонентов и пр.).
Для обеспечения обратной связи макрокоманд среды VBA с кодом ядра с исходного приложения последнее должно быть представлено в виде соответствующего набора ActiveX-компонентов, создавать который должен сам разработчик.
Первый опыт лицензирования VBA в России
Екатеринбургская компания “СКБ Контур” в сентябре 1999 г. первой в России приобрела лицензию на применение VBA. Одним из направлений деятельности фирмы является создание приложений для комплексной автоматизации бухгалтерского и управленческого учета в архитектуре клиент-сервер.
Новые разработки в этой области ведутся с использованием собственной инструментальной среды, имеющей пока рабочее название “Актив”. Именно для дальнейшей модернизации таких вспомогательных средств и предназначен VBA.
Необходимость оперативного перепрограммирования экономических приложений в нашей стране обусловлена частыми изменениями законодательства и специфическими местными условиями. В этой ситуации, по мнению начальника отдела разработки программ Бориса Добровольского, реализация основных алгоритмов на уровне VBA позволяет настраивать и адаптировать приложение прямо на рабочем месте пользователя.
Такая возможность была заложена в инструментальную среду “Актив” изначально на уровне системы COM-объектов, создаваемых средствами Delphi. Раньше, применяя логику управления приложениями на VBScript, разработчики могли изменять основные алгоритмы без компиляции. Однако в вопросах поддержки процесса разработки и отладки (не говоря уже о функциональности) средства VBScript заметно уступают VBA.
В пользу выбора VBA (изучались и другие варианты) сыграло широкое распространение VB и популярность VBA как составной части MS Office и других приложений, а также техническая и маркетинговая поддержка Microsoft.
Поскольку “Актив” сразу проектировался как объектная COM-модель, никаких переделок для внедрения в него VBA не понадобилось. Основные звенья “Актива” сейчас реализуются на VB, уже созданы первые три компонента - Data service, Business service и User service. Параллельно идет разработка модельной задачи “Учет финансово-расчетных операций”, бизнес-логика которой пишется на VBA.
У специалистов “СКБ-Контур” в целом хорошее мнение о VBA: интеграция прошла достаточно легко, серьезных проблем не возникло. Хотя, конечно, есть пожелание уменьшить требования к аппаратным ресурсам со стороны этого инструмента. Пока же практический эффект от применения VBA состоит в заметном ускорении написания и отладки кода.
Мнение клиентов станет известно в марте на региональной выставке “Информатика-2000”, где будет представлена новая SQL-версия системы “Контур-бухгалтерия Каскад”. Но скорее всего оно будет положительным: VBA обеспечивает высокую оперативность изменения, а значит, и удешевление настройки под специфические требования пользователя.
Пример компании “Росно”
“Росно” - одна из наиболее известных российских страховых компаний. Разработкой и поддержкой ПО (в том числе созданного сторонними организациями) здесь в централизованном порядке занимается Департамент информационных технологий. Возможностью интеграции VBA в свои собственные приложения, в частности в систему учета договоров страхования, специалисты ИТ-подразделения заинтересовались еще осенью 1999 г.
Проблема создания и сопровождения данной системы заключается в том, что сами договора и технологии их обработки очень сильно зависят от вида страхования. Поэтому разработчики вынуждены выбирать один из вариантов создания интерфейса с пользователем: создавать либо разные программы для различных типов договоров, либо универсальное приложение, которое будет уметь делать все.
По мнению руководителя проекта Алексея Копылова, оба варианта имеют недостатки на всех стадиях: разработки, сопровождения и эксплуатации конечным пользователем. Использование же VBA позволяет реализовать третий, компромиссный вариант, когда адаптация приложения выполняется на уровне макрокоманд, т. е. быстрое внесение изменений в программу производится без перекомпиляции ее исходного базового модуля. Одновременно резко сокращаются затраты на тестирование, так как макрокоманды не могут повлиять на работоспособность ядра программы. При этом, как отмечают специалисты “Росно”, включение VBA не влечет за собой сколь-нибудь серьезного повышения требований к ресурсам рабочих станций.
Идея, конечно, перспективная...
В целом идея интеграции VBA в приложения независимых разработчиков представляется очень интересной и перспективной. С ее помощью адаптацию программных продуктов к конкретным задачам клиентов можно делегировать от создателей исходного кода проекта на уровень пользователей. При этом для модернизации и расширения функций существует достаточно хорошо известный и простой механизм VB (а не VC++, Delphi или другие средства, на которых писалось исходное приложение).
Но чтобы сделать эту технологию доступной для широкого круга клиентов, Microsoft должна серьезно поработать над повышением качества документации, особенно в отношении примеров реализации проектов, а также над созданием более эффективных мастеров интеграции.