Любая компания, работающая на рынке заказного программного обеспечения, неизбежно сталкивается с необходимостью повышения эффективности своих разработок. Обычно речь идет об оптимизации проектного управления и использовании собственных, уникальных технологических решений, которые позволяют создавать качественные программные продукты, соответствующие требованиям заказчиков.
Для создания корпоративных и ведомственных информационных систем в компании «ФОРС — Центр разработки» применяется технология ВЕРО («Ведение единого реестра объектов»). Она представляет собой программное ядро, которое реализует функции, необходимые для большинства информационных систем масштаба организации.
Заказные программные проекты зачастую имеют много общего. Во многих случаях они нацелены на решение информационно-учетных и информационно-аналитических задач, связанных со сбором (загрузкой, вводом) больших объемов данных, их обработкой и анализом. Вне зависимости от предметной области повторяются многие прикладные требования: ведение реестров юридических или физических лиц (клиентов, контрагентов, субъектов регулирования), учет движения товаров и денежных средств и пр. То же можно сказать о технологических задачах: это управление доступом пользователей к функциям и объектам системы, подключение различных информационных источников для загрузки данных, организация обмена данными между узлами распределенной системы и т.д. С ужесточением требований к срокам, стоимости и качеству программных продуктов возникает необходимость в стандартизации решений.
Приведем соображения, в соответствии с которыми формировалась идея ВЕРО.
Во-первых, хотелось воспользоваться преимуществами объектно-ориентированной разработки (уменьшение стоимости создания и поддержки программных систем за счет повторного использования компонентов, повышение качества и управляемости кода), не жертвуя возможностями современных реляционных СУБД. Кроме того, было желание в рамках архитектуры клиент-сервер вести разработку в терминах типов (классов) и экземпляров объектов, наследования, полиморфизма и инкапсуляции, не теряя скорости реляционных вычислений при наличии больших массивов данных и их соединений. Ввиду известного противоречия объектного и реляционного подхода решение такой задачи связано с определенными трудностями. Зачастую разработчики прибегают к помощи схем, которые противоречат самой природе реляционных СУБД и приводят к неудовлетворительным результатам.
В качестве простейшего примера можно указать известное решение со схемой, состоящей из трех таблиц. Атрибуты всех прикладных сущностей содержатся в столбце одной таблицы, а другие две таблицы представляют собой реестры сущностей и атрибутов. С одной стороны, на такую структуру можно наложить произвольную логическую модель данных. С другой — теряется возможность обеспечить стандартными средствами СУБД целостность данных (включая ссылочную) — в этом случае она остается полностью на совести кодировщика. Кроме того, даже простейшие с точки зрения логической схемы SQL-запросы становятся нагромождением соединений таблицы с самой собой. А при наличии существенных объемов данных это приводит к катастрофическим результатам в плане производительности.
Мы старались избегать подобных «нереляционных» решений. При создании инструментальной технологии было нежелательно ограничиться каким-либо урезанным вариантом языка запросов либо создать сложную непрозрачную систему отображения реляционных данных на объектные сущности. Мы ориентировались на СУБД Oracle, но выстраивали решение так, чтобы схема в минимальной степени зависела от особенностей этой платформы (кроме, естественно, языка хранимых процедур).
Во-вторых, для создания клиентских приложений хотелось задействовать проверенные, распространенные RAD-средства, не выстраивая над ними собственного инструментария, который ограничивает возможности разработчика. Мы использовали Borland Delphi, ориентируясь на достаточно мощный механизм визуального наследования, который позволяет выстраивать логику клиентских приложений «след в след» за организацией прикладных типов (классов) на стороне сервера. Результаты реляционных запросов, интерпретируемые как объекты, их списки и иерархии, должны просто и естественно отображаться и обрабатываться пользователем. Этот подход может быть перенесен на другие средства разработки, в том числе средства разработки Web-приложений.
Еще одно ключевое требование — принципиальное сокращение времени разработки системы за счет готовых решений, шаблонов, компонентов и методик.
Использование предлагаемой технологии дает преимущества не только отдельным разработчикам и проектным группам, но и компании в целом. Создание программ удешевляется; сотрудники, включающиеся в проекты на разных стадиях их реализации, уже знакомы с принципами, соглашениями и инфраструктурой, а потому быстрее входят в курс дела; становится возможным гибкое управление соответствующими ресурсами; повышается качество реализации проектов благодаря использованию наработок компании на основе общих архитектурных, методологических и технологических подходов.
Ядро системы
В технологическом ядре информационной системы, построенной на основе ВЕРО, можно условно выделить следующие «слои»: единый реестр объектов (объектное ядро), основные технологические и прикладные компоненты (рис. 1).
|
| Рис. 1. Технологическое ядро системы |
Ключевой элемент логической модели ВЕРО — Единый реестр объектов (ЕР), в котором регистрируются все прикладные объекты системы. Реестр содержит информацию об уникальном идентификаторе объекта, типе, состоянии, правах доступа и др., обеспечивая:
- уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе;
- получение информации о типе объекта во время исполнения;
- возможность введения новых типов без создания реляционных сущностей или с таковым;
- унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
- унифицированное управление правами доступа к объектам;
- общий механизм поддержки расширяемых атрибутов;
- единую систему журналирования событий.
Все типы объектов образуют классическое дерево наследования с общим корнем. Каждый тип объекта ассоциируется с прикладной таблицей, а механизм наследования реализуется в виде идентифицирующей связи между таблицами. Программный интерфейс типа на стороне сервера СУБД представляет собой совокупность методов доступа (представлений, процедур, функций), причем наследование реализуется посредством вызова соответствующих методов родительского типа. Тип объекта сам по себе является прикладным объектом. Это означает, что каждый тип регистрируется в ЕР как объект и подчиняется всем технологическим принципам работы с объектами, включая наследование.
Помимо ЕР и механизма типизации объектов, в ядро системы входит набор компонентов, реализующих базовое поведение прикладных объектов и обеспечивающих возможность увеличения функциональности.
Основные технологические компоненты
Под основными технологическими компонентами мы подразумеваем общие сервисные функции, реализованные на уровне ядра системы.
Расширяемая атрибутика. В процессе жизненного цикла объекта рано или поздно возникает необходимость в увеличении набора информации о нем, иными словами, в расширении его атрибутики. Естественно желание осуществить это без изменения кода приложения, что реализуется в ВЕРО за счет введения отдельного объекта «Дополнительный атрибут», который принадлежит основному объекту. Он имеет свой тип и обрабатывается согласно общей логике приложения. Ограничения на допустимые типы, уникальность и прочие свойства дополнительных атрибутов регулируются типом основного объекта.
Управление состояниями объектов. В течение жизненного цикла прикладного объекта он, как правило, меняет свои состояния по конкретной схеме. Под состоянием подразумевается характеристика объекта, определяющая его поведение, допустимые по отношению к нему действия (в частности, возможность изменения или удаления объекта) и права пользователей. Схема состояний объекта (которая, в соответствии с общим принципом, сама по себе является объектом) содержит набор состояний и набор переходов между ними (действий). Любому типу объектов допускается присвоить схему состояний, после чего каждый объект такого типа может иметь одно из состояний, определяемых этой схемой. Перед сменой состояния и после нее могут автоматически запускаться хранимые процедуры, играющие роль триггеров переходов. В процессе эксплуатации системы схемы состояний прикладных объектов легко настраиваются и изменяются специалистами заказчика без участия разработчиков.
Управление доступом. Предусмотрены два взаимодополняющих механизма управления правами и доступом пользователей: управление функциональным доступом и доступом к конкретным объектам. Первое опирается на стандартные механизмы раздачи прав на представления, хранимые процедуры и функции на стороне сервера. В ЕР регистрируются серверные компоненты (представления, процедуры), а также пользователи, группы пользователей и задачи (наборы компонентов, обслуживающих конкретную прикладную функцию, например «Поиск и просмотр документов»). Обеспечиваются установка привилегий пользователя в терминах прикладных задач и отображение их на права доступа к объектам базы данных. Управление доступом к отдельным экземплярам объектов является частью принципиальной схемы ВЕРО. Этот механизм позволяет определять видимость объекта, изменять и удалять объект, а также выдавать права на конкретный объект конкретному пользователю или группе.
Журналирование событий. Объект «Событие» характеризует наступление в системе определенного прикладного события и может быть связан с объектом, являющимся источником этого события. Например, событие создания нового контрагента связано с новым экземпляром объекта «Контрагент». Процедуры ядра или процедуры, обслуживающие объекты прикладных типов, генерируют события, которые связаны с объектом и снабжены информацией об их происхождении. В рамках механизма оповещений пользователь (или группа пользователей) может быть подписан на любой тип событий и получать уведомления об их наступлении.
Прикладные компоненты
Под прикладными компонентами понимаются готовые шаблоны реализации наиболее часто используемых типов объектов.
На основе ядра ВЕРО построен единый механизм ведения различных справочников. Они представляют собой тип объектов, а позиции справочника являются конкретными экземплярами объектов данного типа. Добавление новых справочников или редактирование существующих не требует написания какого-либо кода и может быть проведено администратором системы.
Задачей информационных систем часто является учет субъектов, занимающихся различной деятельностью (юридические и физические лица, банки и т.п.). Для ее решения реализованы типы объектов «Персона», «Отношения персон», которые могут быть типизированы согласно прикладной логике. При этом каждый субъект может быть связан с произвольным числом других субъектов отношением определенного типа (сетевая модель с типизированными связями). Например, менеджер по продажам связан с клиентом отношением договора. Кроме того, существуют дополнительные типы, такие как «Адрес», «Регистрационный документ» (паспорт, свидетельство, лицензия и т.п.), экземпляры которых связываются с объектом «Персона».
Электронный документ является объектом, который содержит произвольный файл, импортированный в базу данных. Электронный документ может быть связан с любым другим объектом через механизм «объектной ссылки» (например, к объекту «Договор» относится электронный документ, содержащий файл Microsoft Word с текстом договора).
Задания предоставляют механизм их ввода и контроля над ними пользователей системы. Задание, как правило, привязано к некоторому объекту (например, задание на подготовку справки привязано к объекту «Юридическое лицо»); назначаются ответственный, исполнитель и срок выполнения. По состоянию задания можно получать различные уведомления, например об истечении его срока.
Зачастую при анализе больших реестров объектов со сложными связями необходимо иметь возможность сохранения наборов избранных объектов — коллекций объектов, для того чтобы впоследствии не искать их заново. ВЕРО предусматривает объект «Подборка», в который может быть включено любое число объектов разных типов. Подборки создаются пользователями и, по аналогии с папками Windows, могут образовывать иерархии произвольной вложенности.
Дополнительные сервисы
Под прикладными компонентами понимается реализация часто востребованных технологических подсистем.
Обмен данными. В распределенных информационных системах одним из определяющих факторов эффективности является устойчивая работа сервисов обмена данными между различными узлами системы. В предлагаемой технологии такие сервисы реализованы с учетом всей «объектной» специфики. По заданным правилам узлы обмениваются пакетами данных и формируют различные уведомления. К отличительным чертам подсистемы обмена можно отнести транзакционную целостность, асинхронный режим работы (нет необходимости в постоянном канале связи между узлами), использование открытых стандартов и форматов (XML, XSD и др.), возможность интеграции с транспортными системами обмена сообщениями (Oracle AQ, IBM MQSeries, Microsoft Exchange и др.), автоматическое восстановление после сбоев.
Управление процессами. В сложных информационных системах нередко требуется регламентировать выполнение процессов обработки данных (или цепочек таких процессов) и управление ими. Компонент «Диспетчер процессов» позволяет реализовать произвольные политики управления процессами, влиять на их выполнение, осуществлять мониторинг работы процессов, просматривать историю их выполнения.
Подключение и консолидация внешних ресурсов. В корпоративных и ведомственных информационных системах часто возникает задача загрузки и консолидации данных из «внешних» систем. Соответствующая служба предоставляет прикладной программный интерфейс для подключения новых ресурсов. А уникальные настраиваемые средства идентификации юридических и физических лиц, разработанные с учетом российской специфики, позволяют создавать и обслуживать объединенные, свободные от дублирования информации корпоративные и ведомственные реестры клиентов (субъектов).
Пользовательский интерфейс
Какой бы стройной ни казалась внутренняя организация системы, без ясного и логичного пользовательского интерфейса ее ценность «стремится к нулю». К тому же разработка такого интерфейса требует весьма существенных трудозатрат. В предлагаемой технологии логика интерфейса тесно связана с логикой системы. Для каждого типа прикладного объекта существует своя «объектная» форма, представляющая экземпляр объекта. Она позволяет управлять основной и дополнительной атрибутикой объекта, списками связанных объектов и строится на основе готовых базовых форм в зависимости от прикладных требований.
Создание информационной системы
Новый программный проект начинается с готовой шаблонной схемы базы данных (структура данных с обслуживающими ее процедурами, функциями и представлениями) и шаблона клиентского приложения (рис. 2). Далее система расширяется, по большей части путем наследования, за счет новых прикладных объектов и бизнес-функций. Заказчик в короткие сроки получает рабочий макет приложения, причем могут быть реализованы самые замысловатые его пожелания. Действительно, технология не накладывает ограничений на использование возможностей стандартных средств разработки как на стороне сервера СУБД, так и на стороне клиента.
Одним из примеров организации разработки проекта на основе технологии ВЕРО может служить создание в 2004 году Центрального реестра субъектов внешнеэкономической деятельности для Федеральной таможенной службы РФ. Создаваемая система должна была обеспечить сбор, идентификацию и хранение согласованных сведений о юридических лицах, когда-либо вступавших в правоотношения с таможенными органами и упоминаемых как во внутренних информационных ресурсах, так и во внешних, полученных по каналам межведомственного обмена. Реестр необходим, чтобы предоставлять подразделениям таможенных органов объективную разностороннюю информацию о деятельности субъектов ВЭД.
С одной стороны, речь идет о создании базы данных, интегрирующей информацию о юридических лицах, с другой — о совокупности учетных задач ведения реестров лиц, действующих в области таможенного дела (таможенных брокеров, перевозчиков и т.д.). Следует принять во внимание существенный объем данных, необходимость интеграции более десяти разнородных источников и поддержки репликации между узлами распределенной системы, серьезные требования к производительности. Кроме того, проект выполнялся в весьма сжатые сроки (три месяца от согласования технического задания до приемки первой очереди системы), а постановка задачи не всегда была отчетливой.
При разработке системы было решено взять за основу ВЕРО. Проект стартовал с готовых шаблонов схемы базы данных и приложений. Большинство участников проектной команды были знакомы с принципами, соглашениями и инфраструктурой разработки. Реализация прикладных сущностей осуществлялась по большей части путем наследования и модификации готовых компонентов ВЕРО. Был задействован практически весь базовый функционал: управление правами доступа, схемы состояний, дополнительные атрибуты, подсистемы информационного обмена, управления процессами, подключения и консолидации внешних данных. Это обеспечило загрузку и идентификацию информации о юридических лицах из многих источников на основе заданных критериев и позволило разработчикам сосредоточиться преимущественно на исполнении прикладных требований технического задания.
Серебряная пуля
«Серебряной пули нет», — давным-давно сказал Фредерик Брукс1. С тех пор многое изменилось, но, похоже, серебряная пуля не отлита и по сей день. Однако есть технологические решения, хорошо работающие при определенных условиях и предназначенные для определенных классов задач. Сложность проектов постоянно возрастает, как и требования к качеству программного обеспечения, а сроки исполнения, напротив, сокращаются. В этих условиях применение технологий, аналогичных ВЕРО, становится для компаний конкурентным преимуществом — способом достижения высокой эффективности разработок за счет удачного сочетания разных техник и методов.
Александр Барченков, Татьяна Лякишева, Андрей Шаркин (abarchenkov@fors.ru/tlyakish@fors.ru/asharkin@fors.ru) — сотрудники компании «ФОРС — Центр разработки» (Москва).
