Компьютер в бухгалтерском учете и аудите 2001'2

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

k-press.ru

asc - концепция построения масштабируемых финансовых приложений на базе компонентной модели

Коротко о проблеме

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

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

Для обеспечения надежности и сокращения сроков разработок можно применять 4GL-языки, CASE и RAD-средства, а также отдельные продукты независимых поставщиков. Но такой подход решает только технические вопросы. Причем, выбирая средства разработки, мы связываем себя с конкретной технологией (например, с файл-серверной или с двухуровневой клиент-сервер). Такой выбор на долгие годы связывает нас с выбранной когда-то технологией и порой, чтобы перейти на новую технологическую платформу, необходимо полностью переписать продукт. Если даже вы недавно выбрали самую новую технологию (например, многоуровневую технологию клиент-сервер), то можно с уверенностью сказать, что через несколько лет появится новая (лучшая технология) и вам (если, конечно, вы захотите на нее перейти) снова придется переписывать ваш продукт.

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

Похоже, проблемы обоих подходов понятны всем без объяснения...

Компонентный подход

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

Как же объединить компоненты разных поставщиков, да еще так, чтобы они функционировали как единое целое, да еще допускали расширение за счет встраивания компонентов независимых поставщиков? А вот как... Все компоненты объединяются общим ядром, обеспечивающим общую модель хранения данных и скрывающим от прикладных программистов низкоуровневые тонкости (такие, как взаимодействие с БД). Такое ядро само по себе должно быть создано по компонентной технологии и, в свою очередь, являться компонентом. От остальных компонентов оно отличается тем, что компоненты ядра образуют так называемый ядерный (или, если кому больше нравится, ядрёный) уровень абстракции.

Всего предполагается три уровня абстракции:

1. Уровень конечного приложения. С ним взаимодействует конечный пользователь. Его можно также называть уровнем компонентной конфигурации, так как он целиком основывается на прикладных компонентах. Прикладные компоненты могут предоставлять другим компонентам этого уровня программные интерфейсы. Также они могут иметь (а могут и не иметь) свой пользовательский интерфейс. Естественно, что компоненты этого уровня могут пользоваться программными интерфейсами других компонентов и ядра. Прикладные компоненты могут быть созданы средствами генерации динамических интерфейсов ядра, или с помощью профессиональных средств разработки (на языках программирования и в средах, выбранных прикладным разработчиком). Есть несколько требований к таким компонентам. Первое - компоненты должны быть выполнены как невизуальные COM(ActiveX)-компоненты для реализации бизнес-логики (выполняемой на сервере), или как элементы управления ActiveX (ActiveX control) для создания пользовательского интерфейса. Второе требование заключается в том, что такие компоненты должны выполнять модификацию общих данных через программный интерфейс ядра. Есть еще несколько требований, но говорить о них сейчас преждевременно. Конфигурация компонентов производится средствами ядерного уровня.

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

3. Уровень низкоуровневых компонентов, обеспечивающих функциональность двух предыдущих уровней. Под этим скрывается ActiveX-контейнер, который обеспечивает динамическую загрузку форм, их настройку и сохранение. Он сам создан как элемент управления ActiveX. Это позволяет включать его в независимые приложения. В качестве хранилища может выступать что угодно – от потока байтов (интерфейс IStream) до файлов или BLOB-полей базы данных. Дизайнер форм и исполняющий механизм разнесены, поэтому run-time-составляющая очень мала и может легко использоваться в любых условиях от загрузки в приложениях до динамической подкачки в Web-страницах. Далее следует компоненты работы с БД. Главными их особенностями являются: обеспечение сетевого доступа (что означает работу в распределенных средах и использование локальных СУБД типа Access), высокая масштабируемость и гибкость настройки (как централизованной – серверной части многоуровневого приложения, так и динамической, вплоть до управления параметрами отдельной колонки в момент ее отрисовки). Сюда же входят гибкие компоненты визуализации (grid, datafield, combobox), отличающиеся мощными средствами расширения и возможностью динамической настройки любого параметра и тесной интеграции с вышеописанными компонентами доступа к БД. Все это необходимо конструктору для динамического создания интерфейса и профессионального представления данных. Подробнее о них см. ascDB - курсоры в многоуровневых приложениях. Следующим звеном в цепи низкоуровневых компонентов является генератор отчетов. Он позволяет создавать и генерировать отчеты прямо на сервере. Генератор отчетов тесно интегрирован с другими низкоуровневыми компонентами. Дизайнер генератора интегрирован в среду конструктора и позволяет редактировать имеющиеся и создавать новые отчеты. Некоторые возможности (такие как поддержка вложенных отчетов неограниченной вложенности, наличие скриптового языка – VBScript, расширяемость на базе элементов управления ActiveX и работа с точностью до сотой доли миллиметра) позволяют легко создавать интегрированные отчеты профессионального качества.

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

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

Рис. 1. Уровни абстракции, на которых можно взаимодействовать с ASC

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

Конструкторы, к которым как вы понимаете, можно отнести это проект, являются чем-то средним между интегрированным CASE-средством и системой RAD-разработки, но они имеют свои ни с чем не сравнимые черты. Скорее всего, в будущем они оформятся в отдельный класс ПО, наподобие RAD-средств, а может быть, и породят новую идеологию создания ПО.

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

При этом основная разработка ведется силами 1С, а построение прикладных систем осуществляется средствами, сравнимыми с макроязыком MS Office. Профессиональный разработчик не может, используя это средство, выбирать языки программирования или средства разработки. С нашей точки зрения, это откровенный идеологический промах. Концепция «один большой ЭС и много мелких фирм под общим названием – франчайзинги» не даёт этому продукту шансов претендовать на звание объединяющей силы. С технологической точки зрения, у 1С нет интеллектуального ядра, работающего на высоком уровне абстракции. Самыми высокоуровневыми примитивами в 1С являются документ и справочник. Для интеграции же высокотехнологичных разработок разных фирм необходим более интеллектуальный стандарт хранения и обработки данных. Иными словами, необходима высокоуровневая объектная модель данных, учитываемых на предприятии. Работа должна идти не на уровне документа, а на уровне бизнес-процессов. Информация, внесенная одним из модулей, должна быть общедоступна, вне зависимости от того, кто разработал тот или иной модуль, и как эта информация представлена во внесшем ее модуле.

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

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

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

Предполагается, что код необходим для расширения объектной модели, будет открыт.

Ниже будет обсуждаться каждый из упоминавшихся аспектов, но более детально.

Низкоуровневые технологические аспекты

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

В качестве базовой технологии нами был выбран COM – компонентная объектная модель (Component Object Model) фирмы Microsoft. В планы этой статьи не входит разбор концепций этой модели или агитация в ее пользу, но кратко на ней остановиться придется, по крайней мере для того, чтобы обосновать свой выбор.

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

Первое, что нам потребовалось, это технология позволяющая создавать отчуждаемые компоненты. «Отчуждаемые» – значит, что компонент должен поддерживать динамическую загрузку и динамическое же связывание. Нельзя (ну или, по крайней мере, очень неудобно) создавать единый продукт силами территориально удаленных организаций, если для его использования необходима полная перекомпиляция и общая сборка. Продукт, состоящий из компонентов (тем более разных поставщиков), может быть очень большим. Если все компоненты будут одновременно загружаться в оперативную память, то требования к оперативной памяти могут превысить разумные пределы. Динамическая загрузка позволит снизить нагрузку на память (загружая только те модули, которые необходимы пользователю в данный момент).

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

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

Модель должна также поддерживать описание объектов и прозрачный доступ к ним из разных (по крайне мере, самых популярных) языков программирования. Этим двум требованиям COM отвечает за счет идеологии интерфейсов и возможности их описания в библиотеках типов. Среди поддерживаемых языков практически все популярные: C++, Pascal, Basic, Java. COM предоставляет технологию динамического вызова методов, базирующуюся на IDispatch-интерфейсе. IDispatch совместно с библиотеками типов дает возможность подключить объекты к скриптовым языкам (например, VBScript или JScript). Библиотеки типов являются прекрасным метаописанием, что немаловажно в компонентной среде.

Далее следует работа в сетевом окружении. DCOM и его расширение, MTS/COM+, обеспечивают полнофункциональную поддержку работы в локальной сети и в Internet. При этом обеспечивается работа быстрого откомпилированного кода на другом компьютере. Легко выполняется отладка, а в случае необходимости удаленный объект может быть загружен в адресное пространство вызывающего процесса (например, для создания однопользовательской версии).

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

Стандарт OLE DB, созданный Microsoft (тоже основанный на COM), позволяет получать унифицированный доступ к разным источникам данных.

Причем COM - это не просто стандарт, а стандарт, подкрепленный добротной эталонной реализацией.

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

Низкоуровневые компоненты (основа основ)

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

По началу мы пытались воспользоваться компонентами чужого производства (Microsoft, Borland и некоторых других производителей), но проблемы, возникающие при их использовании, превышали пользу. Некоторые компоненты, на внутренние проблемы которых можно закрыть глаза, не отвечали одному из условий предъявляемых нами, а именно – были слишком тесно связанны с конкретными средствами разработки. Другие требовали слишком больших лицензионных отчислений при продаже основанных на них продуктов. И почти у всех были проблемы с реализацией многоуровневой модели. Как бы там ни было, но мы приняли нелегкое решение создать свои компоненты.

Мы реализовали три проекта: ascDB — доступ к БД в условиях распределенной среды и визуальные элементы управления, позволяющие вводить и отображать данные, ascContainer – контейнер, позволяющий динамически создавать, сохранять и загружать формы, состоящие из элементов управления ActiveX и скрипта, и ascReport позволяющий настраивать отчеты, организовывать предварительный просмотр и печатать отчеты (причем формирование отчета происходит прямо на сервере).

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

Конкретные цены на эти продукты пока не определены, но одно известно точно – однопользовательская версия будет бесплатна.

Всех заинтересовавшихся приглашаем связаться с нами по адресу e-mail или по тел. +7(499)180-02-01 (Москва). Мы будем благодарны за сообщения об ошибках и недостатках программы, а также за ваши пожелания.

Чистяков В.Ю.

Copyright © 1994-2016 ООО "К-Пресс"