*1

_____

*1 Продолжение. Начало см в PC Week/RE, N 46/2004, с. 40.

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

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

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

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

Стандартные прототипы прикладных объектов

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

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

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

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

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

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

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

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

Прикладные объекты и механизмы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Высокоуровневая модель интерфейса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Окончание следует