Архитектура "1С:Предприятия" как продукт инженерной мысли

ПЕРЕДОВЫЕ ТЕХНОЛОГИИ

Взгляд на прикладную платформу с другой стороны

Сергей Нуралиев,

руководитель отделения разработки экономических программ "1С"

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

В этой статье мы решили сконцентрироваться не на описании возможностей продукта "1С:Предприятие", а на инновациях, которые в совокупности определили ряд совершенно новых технологий разработки бизнес-приложений и новых качеств самих этих приложений.

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

Небольшое уточнение требуется по самому названию продукта. "1С:Предприятие" - это система программ, включающая платформу и набор построенных на ее основе бизнес-приложений (прикладных решений), предназначенных для множества отраслей и предприятий разного масштаба. В данной статье мы будем говорить в основном о платформе, на которой строятся бизнес-приложения.

За что боремся

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

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

Платформа и бизнес-приложения

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

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

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

Заметим, что понятие платформы и платформенно-ориентированного построения приложений сейчас общепринято и трактуется гораздо шире, чем просто способность работать в определенной операционной системе. Под платформой понимаются среда исполнения и набор технологий, используемые в качестве основы для построения определенного круга приложений. Фактически приложения базируются на нескольких платформах, образующих многослойный пирог. При этом важно, что платформа предоставляет разработчику определенную модель, как правило, изолирующую его от понятий и подробностей более низкоуровневых технологий и платформ. Такова и платформа "1С:Предприятие", позволяющая обращаться к самым разным технологиям более низкого уровня, не меняя кода бизнес-приложений. Например, она предлагает программисту собственную модель работы с данными и изолирует его от особенностей конкретного хранилища данных, а это дает возможность, не изменяя бизнес-приложение, использовать в нем практически любое хранилище. В частности, в качестве БД при решении задач небольшого масштаба может применяться собственный файловый движок, а для работы в масштабе предприятия - MS SQL Server.

Ключевым качеством платформы "1С:Предприятие", пожалуй, является достаточность ее средств для решения задач, стоящих перед бизнес-приложениями. Это обеспечивает очень хорошую согласованность всех технологий и инструментов, которыми пользуется разработчик. Ведь часто именно наличие "швов" между различными технологиями становится причиной самых серьезных проблем. Простейший пример - система типов. В платформе "1С:Предприятие" разработчик использует одну систему типов данных и для взаимодействия с БД, и для реализации бизнес-логики, и для построения интерфейсных решений. Поэтому у него нет проблем, связанных с преобразованием типов при переходах между разными уровнями прикладной системы. Другой очень важный момент - стандартизация. Наличие единой платформы для большого количества прикладных решений способствует формированию общего "культурного слоя", включающего и людей (программистов, аналитиков, пользователей), и методологию (типовые структуры данных, алгоритмы, пользовательские интерфейсы). Опираясь на этот "культурный слой", разработчик тратит минимум усилий на поиск необходимого решения практически в любой ситуации, начиная от включения в проект нового специалиста и кончая реализацией какой-либо подсистемы бизнес-приложения по типовой методологии.

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

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

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

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

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

Метаданные - способ описания бизнес-приложения

В "1С:Предприятии" прикладное решение не пишется в прямом смысле на языке программирования. Язык программирования, конечно, используется, но только там, где это действительно необходимо.

В основе бизнес-приложения лежат метаданные. Они представляют собой структурированное декларативное его описание. Метаданные образуют иерархию объектов, из которых формируются все составные части прикладной системы и которые определяют все аспекты ее поведения. При работе бизнес-приложения платформа "проигрывает" (интерпретирует) метаданные, обеспечивая всю необходимую функциональность.

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

Что дает такой подход к построению бизнес-приложения? Во-первых, при описании метаданных широко применяется визуальное редактирование. Это позволяет свести существенную часть разработки к визуальному проектированию, не требующему кропотливого написания кода. Однако у данного подхода есть и другие не менее важные преимущества. Описывая прикладное решение в терминах метаданных, разработчик "сообщает" платформе много очень полезной информации, которую та может эффективно использовать в самых различных целях. На основе метаданных система автоматически выстраивает большую часть механизмов и объектов, отвечающих за функционирование прикладного решения. Так, описания метаданных платформе достаточно для того, чтобы автоматически сформировать пользовательский интерфейс системы, обеспечивающий ввод и редактирование взаимосвязанной информации. Другой пример - возможность построения даже конечным пользователем, не имеющим навыков программирования, весьма сложных отчетов.

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

Эта идеология (Metadata Driven) сегодня находит все более широкое применение во многих перспективных разработках.

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

В "1С:Предприятии" изначально заложена строгая ориентация на построение прикладного решения на основе определенной модели.

Этот подход весьма перспективен и, по нашей оценке, будет доминирующим в обозримом будущем в современных средствах разработки. Идеи построения бизнес-приложений на основе модели, например, нашли воплощение в архитектуре MDA (Model Driven Architecture) консорциума OMG.

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

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

Очевидным следствием этого подхода является изоляция разработчика бизнес-приложения от деталей технологий хранения информации, организации трехуровневой архитектуры и т. д. Например, как уже отмечалось выше, все прикладные решения, базирующиеся на "1С:Предприятии", без каких-либо изменений работают как с собственным файловым движком БД, так и с сервером БД. При этом необходимые структуры данных создаются и изменяются системой автоматически на основе описания метаданных, и разработчику не приходится вникать в детали форматов хранения конкретных СУБД. Манипулирование данными в приложении также описывается в высокоуровневой модели и автоматически исполняется с учетом особенностей используемого хранилища.

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

Управление данными

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

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

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

Для всех операций модификации данных (создания, изменения и удаления) в "1С:Предприятии" применяется исключительно объектная техника. Это означает, что разработчик взаимодействует с БД не на уровне записей, а с помощью объектов, соответствующих хранимым в БД сущностям. Для изменения хранимых данных ему не нужно писать сложные запросы и преобразовывать результаты их обработки в объекты языка программирования. Достаточно получить объект из базы данных, изменить его свойства и снова сохранить. Разработчик имеет при этом возможность написать обработчики событий, связанных с изменением данных, выполняя с их помощью различные проверки и изменяя при необходимости другие данные. Система обеспечивает эффективную технологическую поддержку объектного подхода, осуществляя, например, кэширование объектов, контроль объектной и ссылочной целостности и т. д. Для чтения данных может использоваться как объектная техника, так и декларативный язык запросов, который основывается на классическом SQL, но имеет ряд существенных расширений. Расширения направлены как на поддержку работы с объектами, хранящимися в базе данных, так и на эффективное решение экономических задач. Ниже мы рассмотрим язык запросов более подробно.

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

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

По нашему мнению, такая смешанная техника в том или ином виде начнет в обозримом будущем достаточно широко использоваться в перспективных разработках экономических систем.

Здесь, немного забегая вперед, следует сказать, что в модели "1С:Предприятия" реализована наиболее современная концепция работы с информацией, сочетающая три способа представления данных: хранение сущностей в базе данных, их представление в языке программирования в виде объектов и отображение в формате XML. Фактически любая информация может в зависимости от текущего режима работы представляться одним из этих трех способов.

Долговременное хранение сущностей (persistence) осуществляется в БД, что обеспечивает надежность и эффективную обработку больших объемов информации. Для внесения изменений данные предварительно преобразуются в объекты встроенного языка. При внутреннем обмене в распределенной БД или взаимодействии с другими информационными системами данные переносятся в формате XML. Заметим, что все три способа представления опираются на единую систему понятий и от разработчика не требуется усилий для трансформации данных из одного способа представления в другой.

Такой подход позволяет органично вписывать "1С:Предприятие" в будущие гетерогенные решения, которые, по нашей оценке (и она совпадает с оценкой многих экспертов), получат со временем самое широкое распространение.

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

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

В результате подобного смыслового разделения сущностей платформа "1С:Предприятие" фактически предлагает разработчику готовую методологию для наиболее естественного решения различных задач манипулирования данными в соответствии с природой этих сущностей.

Работа с объектными сущностями поддерживается представлением сущностей базы данных в виде объектов встроенного языка программирования, а также специальными типами данных, служащими для представления объектных ссылок (ссылок на объекты базы данных). При этом, зная объект, легко получить его ссылку, а зная ссылку - извлечь из БД объект. Такая техника обеспечивает наглядный и естественный способ описания в исходном коде алгоритмов бизнес-логики, манипулирующих объектами, а кроме того, гарантирует логическую целостность данных при любых операциях. Она напоминает написание приложений объектных БД с той лишь разницей, что сохранение данных происходит в таблицах реляционной СУБД. А в модулях, написанных на встроенном языке, может одновременно присутствовать несколько объектов, представляющих одну сущность БД.

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

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

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

Еще одной важной особенностью объектной техники, принятой в платформе "1С:Предприятие", является то, что те же объекты, которые присутствуют в модулях на встроенном языке (как для объектных, так и для необъектных сущностей), используются и для отображения данных в интерфейсе. Элементы управления форм непосредственно связываются с нужными объектами и обеспечивают их отображение и редактирование пользователем без какой-либо помощи со стороны разработчика.

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

Наряду с описанными выше методами манипулирования данными и формирования запросов система предлагает еще один способ доступа к данным - динамические выборки. Этот механизм позволяет обращаться к очень большим объемам данных, обеспечивая считывание информации порциями. При этом разработчик только указывает, какие данные необходимо получать, а система автоматически выполняет обращения к БД с необходимой гранулярностью. Важно, что для решения этой задачи не используются какие-либо специфические средства динамического считывания конкретной СУБД, требующие удержания в памяти открытой выборки, а осуществляется автоматическое формирование запросов, последовательно выбирающих блоки записей.

Еще одним значимым решением в части работы с данными в "1С:Предприятии" является поддержка в полях таблиц составных типов данных. Эта возможность, насколько нам известно, не имеет близких аналогов в других системах. При описании типа поля какого-либо объекта можно выбрать не только один из доступных типов, но и практически любую (с некоторыми ограничениями) их комбинацию. Так, в поле "Плательщик" в документе, отражающем операцию с банком, допускается хранение ссылки на юридическое или физическое лицо в зависимости от конкретной операции. Хотя приведенный пример достаточно прост, в реальных приложениях возможность работы с составными типами позволяет решать такие задачи, как хранение произвольных характеристик товаров, ведение аналитического учета на бухгалтерских счетах по любому составу аналитических разрезов, настраиваемых пользователем, и т. д. Надо отметить, что система не просто предоставляет возможность хранения в одном поле разнородных значений, а делает это прозрачным для разработчика способом. Прежде всего необходимо отметить полную поддержку работы с полями составных типов "движка" базы данных и языка запросов. Для этих полей поддерживается весь набор стандартных операций (сравнение, агрегирование и т. д.). Другим важным моментом является поддержка составных типов в интерфейсных механизмах системы. Например, поле ввода, связанное с данными такого составного типа, предоставляет весь набор функций редактирования (выбор типа; редактирование значений всех типов, входящих в указанное поле; ограничение выбираемых типов).

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

Прежде всего следует отметить поддержку в языке запросов объектов, хранящихся в БД. Все операторы языка запросов обеспечивают работу со ссылочными типами (полями, хранящими ссылки на объекты БД). Например, поддерживается обращение к полям в нотации "через точку" без ограничения количества уровней. Можно указать в запросе выборку такого поля, как "Счет. Товар. Производитель. Страна. Наименование". Для объектов базы данных допускается обращение к вложенным таблицам и как к отдельным таблицам, и как к обычным полям объекта, содержащим коллекции записей.

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

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

Еще одним мощным элементом механизма запросов являются виртуальные таблицы. Они обеспечивают доступ к производным данным, предоставляемым различными прикладными подсистемами, не требуя для этого написания сложных запросов. В частности, можно обратиться к виртуальной таблице для получения распределения остатков и оборотов товаров по складам и номенклатуре, а также по календарным периодам. Следует отметить, что работа с виртуальными таблицами не является аналогом простого хранения типовых запросов (view). При использовании виртуальных таблиц разработчик указывает набор параметров, описывающих необходимую выборку, беря в их качестве не только конкретные значения, но и, например, сложные условия. Разработчик прикладного решения работает с виртуальной таблицей практически так же, как и с обычной, но система формирует запрос к БД таким образом, чтобы обеспечить максимальную эффективность. В частности, при обращении к данным, обрабатываемым учетными механизмами, могут использоваться хранимые ими промежуточные итоги.

Продолжение следует