|
|||
|
1С:Совместимо Справочник внедренных решений Монитор внедрений Самые масштабные проекты Корпоративные внедрения |
|||
| Интеграция |
 |
 |
|
|||||||||
|
Поэтому у него нет проблем, связанных с преобразованием типов при переходах между разными уровнями прикладной системы. Другим очень важным моментом является стандартизация. Наличие единой платформы для большого количества прикладных решений способствует формированию общего "культурного слоя", включающего и людей (программистов, аналитиков, пользователей) и методологию (типовые структуры данных, алгоритмы, пользовательские интерфейсы). Опираясь на этот "культурный слой", разработчик тратит минимум усилий на поиск необходимого решения, практически, в любой ситуации, начиная от включения в проект нового специалиста и кончая реализацией какой-либо подсистемы бизнес-приложения по типовой методологии. Одним из существенных преимуществ четкого разграничения между платформой и бизнес-приложением является высокий уровень адаптируемости решений под требования клиента. Следует заметить, что именно для экономических задач особо важна возможность эффективного изменения готового решения разработчиком, не участвовавшим в его создании. В индустрии разработки бизнес-приложений, в отличие от многих других областей, существенная часть разработчиков не создает программы "с чистого листа", а дорабатывает и развивает типовые решения. Это обстоятельство определяет особые требования к обеспечению наглядности и простоте понимания разработчиком существующих решений и максимально учитывается во всех механизмах платформы. Инструментальные средства "1С:Предприятия" представляют собой не некий дополнительный "toolkit", а являются неотъемлемой составляющей платформы. Они ориентированы в равной степени, как на разработку решений, так и на их адаптацию при внедрении на конкретном предприятии. Эти средства поставляются с каждым комплектом 1С:Предприятия и применяются как для внесения небольших изменений, например, в макет печатной формы, так и для существенной доработки прикладного решения включая структуры данных и бизнес логику. Возможности эффективного внесения изменений в приложение при его внедрении заложены в самих этих инструментах , а, кроме того, этому способствует и архитектура построения прикладного решения. В следующих разделах статьи мы постараемся проиллюстрировать данный тезис.
Выделение бизнес-приложения как самостоятельного элемента, фактически, позволило нам сформировать целую индустрию создания, распространения и поддержки разнообразных прикладных систем, концентрирующую свои усилия на специфике этого класса задач и не требующую глубокого понимания большей части технологических деталей и подробностей. Например, для фирмы, имеющей специалистов, опыт и репутацию в конкретной отрасли, стало вполне реальным в короткие сроки выйти на рынок бизнес-приложений с собственным продуктом, не тратя несколько лет на создание технологической базы.
|
В качестве примеров существующих подходов можно привести описания в терминах реляционных таблиц, классов объектного языка программирования, сохраняемых сущностей (Entity Persistent) и т.д. В модели разработки "1С:Предприятия" используется подход, которому мы не нашли явного аналога в других системах. Здесь все прикладное решение описывается метаданными в виде совокупности прикладных объектов, выбираемых из жестко определенного набора прототипов (классов). Можно было бы назвать создаваемые объекты бизнес-компонентами, а их прототипы шаблонами (patterns). Каждый такой прототип отвечает за отражение вприкладном решении определенной совокупности объектов или процессов предметной области, имеющих схожие поведенческие характеристики и сходную роль в общей картине решения. Примерами таких прототипов в "1С:Предприятии" являются "Справочники", "Документы", "Регистры накопления". Каждый прототип имеет некоторую базовую реализацию, которая определяет особенности функционирования, создаваемых на основе данного прототипа объектов: структуру хранимых сущностей вместе с некоторыми предопределенными полями, набор типов языка программирования, методы, свойства и события, а также типовые для решаемой задачи операции, способы отображения и редактирования, методы регулирования прав доступа и т.д. |
Если в ходе разработки необходимо создать объект, отражающий особенности предметной области, программист выбирает подходящий прототип и создает на его основе объект метаданных. Далее он может задать различные свойства, определяющие особенности поведения объекта, основанного на этом прототипе, дополнить при необходимости структуру данных объекта, реализовать необходимый набор методов, определить обработчики событий, уточнить способы отображения объекта в интерфейсе и т.д.
Для простых объектов такое доопределение может не потребоваться совсем, и вся процедура создания объекта будет сведена к указанию его имени в свойствах метаданных. В более сложных случаях разработчик имеет возможность достаточно подробно определять и структуры данных, и алгоритмы бизнес-логики, но при этом стандартная функциональностьреализуется автоматически без каких-либо усилий с его стороны.
Важно, что количество таких прототипов в платформе не велико, около двух десятков: их легко изучить, с тем, чтобы впоследствии эффективно применять для решения любых задач предметной области.
Таким образом, структура метаданных "1С:Предприятия" является не просто набором описаний объектов в определенных унифицированных терминах. Все прикладное решение, фактически, состоит из объектов, четко разделенных по тем ролям, которые они играют в бизнес-приложении. Такой подход существенно усиливает эффект и от описания системы в терминах метаданных, и от построения приложения на основе модели.
Наличие у объектов, описанных метаданными, стандартной функциональности и предопределенной роли позволяет системе автоматически решать гораздо более широкий круг задач, возлагаемых как непосредственно на эти объекты, так и на общие механизмы, работающие с ними. Фактически, зная о назначении (роли в прикладном решении) того или иного объекта, платформа сама, без какого-либо участия программиста, обеспечивает для него в любой ситуации соответствующий "индивидуальный подход". Например, механизм форм "знает", как лучше редактировать те или иные данные, а стандартный механизм отчетов может автоматически "подстроиться" с тем, чтобы проводить анализ информации наиболее эффективно.
Использование предопределенных прототипов обеспечивает стандартизацию модели построения прикладных решений. Такая стандартизация, возможно, не очень существенна для одного отдельно взятого бизнес-приложения, но она имеет огромное значение при создании индустрии разработки и поддержки множества прикладных решений. Стандартизация позволяет существенно упростить задачи проектирования и в несколько раз снижает сложность и трудоемкость сопровождения. Например, если необходимо подключить к проекту еще одного специалиста или передать другому сотруднику поддержку и развитие решения, новый разработчик может после беглого просмотра структуры метаданных буквально за несколько минут составить общее представление о строении и основной функциональности прикладного решения, так как в структуре метаданных все прикладные объекты сгруппированы по принятым в модели "1С:Предприятия" функциональным ролям. В дальнейшем он сможет также быстро разбираться в устройстве и бизнес-логике отдельных подсистем. По опыту эти показатели существенно отличаются от тех, которые достигаются при использовании других подходов к описанию приложения.
Прикладные объекты и механизмы Выше мы описали только принцип построения прикладного решения, основанный на использовании стандартных прототипов прикладных объектов.
Разумеется, здесь не место для подробного описания всех имеющиеся прототипов. Но ниже, чтобы продемонстрировать те идеи, которые заложены в имеющуюся модель построения бизнес-приложения, мы дадим краткий обзор прототипов и предоставляемых ими возможностей.
Сначала мы приведем примеры достаточно простых прототипов - справочников и документов. Справочники описывают каталоги, содержимое которых более или менее постоянно. Это может быть перечень выпускаемой продукции, список клиентов компании, перечень валют и т.д. Справочники обеспечивают поддержку иерархических структур, позволяют относить данные к к отдельным объектам и их группам, предоставляют ряд других сервисных возможностей.
Документы отражают в системе события, происходящие в жизни предприятия: поступление материалов, перечисление денег через банк, прием сотрудника на работу и т.д. Этот прототип обеспечивает их отражение в различных учетных механизмах, поддерживает контроль последовательности обработки событий, реализует сквозную нумерацию объектов разного типа и т.д.
Остановимся немного подробнее на некоторых возможностях этих двух прототипов.
Известно, что классическая реляционная модель не имеет готовых средств для поддержки иерархии данных и ее реализация всегда требует кропотливой работы. Справочники (а также некоторые другие прототипы прикладных объектов "1С:Предприятия"), поддерживают многоуровневую иерархию изначально. Включается этот механизм простой активизацией соответствующего свойства в метаданных. При этом поддержка иерархии распространяется сразу на все аспекты использования прикладного объекта. Например, прототип обеспечивает поддержку необходимых свойств и методов в объектной модели манипулирования данными (определение уровня объекта, контроль зацикливания иерархии и т.д.). В интерфейсных механизмах реализуется представление данных в виде иерархического списка или дерева с навигацией по уровням и интерактивным изменением иерархии. В механизмах отчетов обеспечивается формирование иерархических документов такого рода и получение многоуровневой иерархии итогов в любых отчетах, в которых объекты этого типа, выступают, в качестве параметров для группировки.
Другим примером штатных возможностей прототипов является поддержка механизма проведения документов. Этот механизм предлагает разработчику стандартную модель организации связи между информацией о событиях, происходящих на предприятии, и различными учетными механизмами. Любая вводимая пользователем в виде документов информация может отражаться в любых учетных механизмах (планировании, управленческом учете, бухгалтерском учете и т.д.). Разработчик должен только указать в свойствах метаданных связь между документами и учетными механизмами, а также описать алгоритм проведения документа. Все необходимые действия по проведению и отмене проведения система будет выполнять автоматически. При этом системой предоставляются дополнительные возможности, такие как поддержка отражения событий в реальном времени, поддержка восстановления последовательности отражения событий, происходящих на предприятии, при изменении их задним числом и т.д. В результате предоставляется единая модель связи исходных данных и учетных механизмов, которая не просто облегчает разработку, но и обеспечивает единообразноепредсказуемое поведение всех прикладных решений, что существенно облегчает их освоение и поддержку.
Весьма интересными являются прототипы объектов "1С:Предприятия", применяемые в механизме сложных периодических расчетов. Этот механизм можно рассматривать как универсальный инструмент для решения задач расчета зарплаты любой сложности. На самом деле, расчет зарплаты является наиболее типичным применением данного механизма, но сам механизм не имеет ориентации именно на эту задачу и успешно используется для решения других задач, требующих описания периодических расчетов со сложными взаимосвязями, например, расчета дивидендов, стоимости коммунальных услуг и т.д. Он содержит набор типовых стратегий, примером которых может служить вытеснение одних видов расчетов другими при их пересечении на шкале времени. Применительно к задаче расчета зарплаты эта возможность решает весь комплекс проблем, связанных с пересекающимися по времени начислениями и удержаниями, для которых определены сложные правила взаимного исключения. Другим примером является возможность установки взаимосвязи между различными видами начислений и удержаний по периоду действия. Таким образом, механизм представляет определенную математическую модель, устанавливающую связи между различными видами расчетов и предоставляет разработчику действующие на основе этой модели механизмы обработки информации.
Не углубляясь далее в подробности этого механизма, стоит отметить, что он позволяет полностью описать схему расчета зарплаты на основании предоставляемых прототипов прикладных объектов и заложенных в них возможностей. На примере данного механизма можно достаточно наглядно продемонстрировать эффект от использования предлагаемого подхода. Мы не имеем на данный момент информации о наличии в каком-либо средстве разработки экономического софта подобного механизма. Во всех известных нам случаях модуль расчета зарплаты (Payroll) реализуется ценой достаточно больших затрат и на проектирование и на реализацию. Причем этот модуль приходится существенно или полностью переписывать для каждой страны, так как он сильно привязан к местному законодательству. Применение механизма сложных периодических расчетов в "1С:Предприятии" позволяет перевести разработку такого модуля от проектирования "с чистого листа" к реализации по стандартной схеме. По нашей оценке это сокращает затраты на порядок, но самое главное, существенно упрощается внесение изменений в процессе поддержки системы.
Еще одним характерным примером служит механизм характеристик, предназначенный для решения задач, которые плохо согласуются с классической реляционной моделью базы данных. Одной из таких задач, является построение структуры для отражения разнообразных свойств (характеристик) номенклатуры товаров или изделий. Если создается решение для одной организации с четкой ориентацией на определенную группу товаров, то все необходимые реквизиты можно заложить непосредственно в структуру каталога товаров. Например, для дилерской фирмы по продаже автомобилей ими будут цвет, объем двигателя и т.д. Однако если создается тиражное бизнес-приложение, или решение для организации, занимающейся производством или продажей разнообразной номенклатуры, этот вариант не подходит, так как очевидно, что состав характеристик должен зависеть от конкретной группы номенклатуры и добавление каждой новой группы не должно сопровождаться доработкой прикладного решения. Очевидно, что реализация такого решения плохо ложится в реляционную структуру и требует особого подхода. Реализованный в "1С:Предприятии" механизм характеристик предоставляет разработчику типовое средство решения подобных задач. Специализированный прототип предназначен для организации хранения списка видов характеристик. При этом каждому такому виду приписывается свой тип данных. Например, объем двигателя будет задаваться числом, а цвет выбираться из справочника. Важно, что конкретные виды характеристик могут не только определяться в самом приложении, но и добавляться пользователем в процессе эксплуатации системы без изменения прикладного решения. При этом разработчик может задействовать данный механизм в самых различных ситуациях, например, для хранения логически связанных комбинаций характеристик номенклатуры и расчета себестоимости в разрезе имеющихся комбинаций.
Еще одним интересным решением является механизм бизнес-процессов (work-flow), позволяющий разработчику организовать совместную работу пользователей при выполнении типовых последовательностей деловых операций. Во многих существующих информационных системах для решения задач work-flow используются специализированные продукты, которые приходится интегрировать с приложениями, решающими экономические задачи. В платформе "1С:Предприятие" механизм бизнес-процессов полностью интегрирован в систему таким образом, что ни разработчик ни пользователь не видят "швов" разделяющих этот механизм и другую функциональность. Этот механизм включает средства для описания в прикладном решении схем бизнес-процессов, и их ролевой маршрутизации, для формирования заданий , выполняющихся в каждой точке маршрута, для управления бизнес-процессом и организации его связи с другими функциями прикладного решения.Данный механизм предоставляет разработчику гибкие возможности управления ветвлением процесса и формирования задач. Например, кроме обычного условного ветвления разработчик может визуально описать параллельное прохождение нескольких веток маршрута, и указать точку их слияния. Допускается направление одного задания группе потенциальных исполнителей, например, если выписать счет должен один из менеджеров отдела. И наоборот, в некоторой точке маршрута можно инициировать несколько заданий, например, если финансовые отчеты должны представить все руководители отделов. Ролевая маршрутизация позволяет формировать задачу не только непосредственно конкретному сотруднику, но и распределять задачи по ролям, подразделениям и другим критериям, которые может описать разработчик прикладного решения. При осуществлении ролевой маршрутизации разрешается указывать текущее распределение обязанностей сотрудников с учетом временных замещений, совмещений нескольких должностей и т.д. Важно отметить, что данный механизм предлагает готовую стратегию автоматизации совместной деятельности работников предприятия. Для описания простейших бизнес-процессов достаточно визуального задания схемы маршрута и указания условий ветвления в их узловых точках. Все остальные действия выполняются системой автоматически. При реализации сложных бизнес-процессов усилия разработчика требуются в основном для тесной их увязки с функциями прикладного решения.
На приведенных примерах мы продемонстрировали, что каждый из прототипов прикладных объектов и объединяющих их механизмов закрывает определенную область задач предметной области существенно снижая затраты на разработку и, что очень важно, обеспечивая стандартизацию прикладных решений.
Чтобы дать представление о спектре инструментов предоставляемых разработчику, ниже мы кратко опишем еще несколько механизмов.
Так, для решения задач, связанных с учетом наличия и движения средств (материальных и денежных), предлагается механизм регистров накопления.
Он поддерживает многомерную систему учета с произвольным составом измерений и ресурсов и обеспечивает оптимизацию получения итогов на различные моменты времени, тем самым позволяя эффективно решать задачи материального учета, производственного и финансового планирования, расчета с контрагентами и т.д.
Механизм бухгалтерского учета представляет собой универсальный "движок" для решения задач автоматизации бухгалтерского учета в различных моделях счетоводства.
Он может использоваться в различных странах и имеет большой запас гибкости для дополнительной настройки. В его основе лежит принцип двойной записи, причем допускается работа с финансовыми транзакциями (операциями), включающими как простые корреспонденции (один дебет и один кредит), принятые в российском учете и в моделях учета некоторых других стран, так и сложные, применяемые в большинстве западных стран (несколько дебетов и несколько кредитов).
Механизм поддерживает многомерную систему учета с произвольным составом измерений и ресурсов. Уникальным его свойством является возможность настройки состава дополнительных измерений независимо для каждого счета. При этом допускается формирование состава измерений как разработчиком при создании прикладного решения, так и пользователем в процессе работы с системой. Многоуровневые и многомерные итоги в разрезе периодов, перекрестных корреспонденций и т.д. генерируются автоматически.
Механизм сведений предназначен для решения задач, связанных с хранением разнообразной информации об объектах в различных разрезах.
Например, данные о ценах на товары могут храниться в разрезе их номенклатуры, категорий клиентов и т.д. При необходимости может поддерживаться хранение истории внесенных изменений, что позволяет получать наряду с актуальными данными, еще и их значения на любой прошедший момент времени. Механизм обеспечивает всю логику работы с хранимыми сведениями, начиная от манипулирования данными до их автоматического контекстного отображения в пользовательском интерфейсе.
Еще раз подчеркнем, что в модели "1С:Предприятия" прикладные механизмы и лежащие в их основе прототипы - это не просто набор шаблонов, которые разработчик может использовать "по мере надобности". Всё прикладное решение с необходимостью основывается на использовании предлагаемого набора прототипов.
Этого, достаточно компактного, набора вполне хватает, чтобы закрыть все потребности предметной области. Имеющимся набором прототипов система фактически навязывает разработчику стандартную модель проектирования, и это позволяет, по нашей оценке, существенно снизить затраты на построение и поддержку прикладных решений .
Высокоуровневая модель интерфейса Очевидно, что для бизнес-приложения вопрос организации пользовательского интерфейса имеет особое значение. Во-первых, потому, что для существенной части пользователей эти приложения являются основным инструментом, и такие пользователи работают с ним большую часть дня, не являясь зачастую профессиональными пользователями компьютера. Во-вторых, интерфейс бизнес-приложений обычно очень "объемный". В отличие от многих других классов систем бизнес-приложения, как правило, содержат от нескольких сотен, до нескольких тысяч форм. Кроме того, эти формы могут периодически меняться, например, в ходе развития системы или при необходимости изменения бизнес-логики. Соответственно, затраты на разработку интерфейса прикладного решения весьма высоки. Именно поэтому в платформу "1С:Предприятие" включен целый ряд механизмов, ориентированных на быструю разработку эргономичного пользовательского интерфейса. В них реализована собственная оконная модель, система форм, набор элементов управления и т.д.
Основной идеей построения интерфейса, реализованной в "1С:Предприятии", является максимальное использование информации из метаданных, а также объектов манипулирования данными с тем, чтобы вся конструкция не требовала детальной настройки со стороны разработчика и функционировала по большей части автоматически . Мы уже говорили выше, что объекты встроенного языка, используемые для манипулирования данными , применяются и для их отображения в интерфейсе. Разработчику достаточно связать такой объект с элементом управления и механизм интерфейса полностью возьмет на себя организацию просмотра и модификации данных. Однако, наибольший эффект достигается за счет установления связи между объектом манипулирования данных и самой формой, а не с отдельными элементами управления. В таком случае вся функциональность формы, относящаяся к просмотру и редактированию данных, а также ее связь с другими формами, обеспечивается системой автоматически . Для этого в "1С:Предприятии" реализован механизм расширений форм и расширений элементов управления. Расширения автоматически "включаются в работу" с учетом типа данных, с которыми связан элемент управления или форма.
Например, поле ввода обеспечивает все необходимые действия по редактированию ссылочных значений (выбор из специальных форм, множественный подбор, очистку, подсветку и автоматический выбор незаполненных значений, переход к формам редактирования выбранных объектови т.д.). Очень эффективен так называемый ввод по строке, который позволяет в несколько раз ускорить массовый ввод информации, исключая необходимость выбора значений из форм списков . Для его реализации в свойствах метаданных задается перечень полей, по которым пользователи могут быстро находить нужные объекты, например, код, артикул, наименование. При наборе в поле ввода нескольких символов система автоматически подставляет то значение, одно из указанных в метаданных полей которого начинается с тех же символов. Если таких значений найдено несколько, пользователю предлагается осуществить выбориз списка. От разработчика при этом не требуется никаких усилий, так как интерфейсный механизм опирается на свойства метаданных.
Другим интересным примером является табличное поле. Этот элемент управления представляет собой мощный механизм визуализации и редактирования данных, предоставляющий пользователю возможность просмотра и редактирования больших списков, за счет динамического считывания. Мы уже говорили выше о механизме динамического считывания, как одном из средств манипулирования данными. В механизме интерфейса "1С:Предприятия" он позволяет просматривать массивы данных практически неограниченного размера без считывания их в память целиком. При этом с точки зрения пользователя навигация по списку практически не отличается от просмотра данных, находящихся в памяти компьютера. Данный механизм поддерживает гибкие возможности поиска и фильтрации, просмотра иерархических структур, редактирование данных в списке и в отдельных формах, настройку состава колонок и их сортировки, печать списков и их экспорт в различные форматы и т.д.
Для форм, списков и других элементов система автоматически формирует командный интерфейс (кнопки, меню и целые панели управления), обеспечивающий все действия по просмотру и редактированию, а также связи с другими формами и сервисные функции.
Описав объект метаданных в прикладном решении, разработчик может вообще не строить для него форму, все необходимые формы будут создаваться автоматически в процессе работы системы. Если же он создает форму, чтобы задать ей специфические свойства, то конструктор генерирует стандартную форму, которая не содержит изначально никакого кода на встроенном языке., так как расширения элементов управления и формы обеспечивают всю необходимую функциональность. Разумеется, разработчик может и без конструктора вставить в любую форму элементы управления, связать их с данными и получить полностью работающую конструкцию, не написав ни строчки кода. Дописывать что-то ему придется лишь тогда, когда он захочет переопределить или расширить стандартную функциональность.
Важно что, интерфейс "1С:Предприятия" обеспечивает работу не просто отдельных форм и элементов управления. Штатная механика управления формами прикладных объектов обеспечивает различные варианты связей между форами используемые при выборе значений, множественном подборе, детализации информации и т.д. Фактически, платформа "1С:Предприятия" предлагает разработчику готовую стратегию организации всего интерфейса бизнес-приложения имеющую способы реализации практически всех необходимых сценариев работы пользователей.
За счет использования хранящихся в метаданных знаний о связях между различными объектами, поддерживается автоматическая генерация команд перехода между логически связанными формами. Так пользователь, работая с некоторым документом, может без каких-либо усилий со стороны программиста получить доступ к записям, отражающим этот документ в различных учетных механизмах. Кроме связей определяемых в метаданных бизнес-логикой прикладного решения, разработчик может определить (в виде критериев отбора) и дополнительные связи для перехода между объектами, которые так же автоматически будут представляться в командном интерфейсе форм.
Другим стандартным интерфейсным решением является так называемый механизм "ввода на основании". Он позволяет при вводе данных по одному объекту, заполнять автоматически целый ряд полей, извлекая их значения из из данных других объектов. Например, выписав счет, пользователь может нажатием одной кнопки сформировать на основании этого счета накладную: для этого достаточно установить в метаданных связь между упомянутыми объектами и описать правила заполнения полей.
Разработчик прикладного решения предоставляется стандартное средство реализации "сменного" командного интерфейса. В прикладных решениях, имеющих большой объем функциональности, это дает пользователю возможность переключаться на другой режим работы с полной или частичной сменой командного интерфейса, не выходя из системы.
Механизм форм обеспечивает стратегию смысловой идентификации форм, позволяющую не открывать повторно уже открытые формы, а активизировать отрытые ранее формы при обращении пользователя к той или иной информации.
Таким образом, с помощью расширений форм и других механизмов автоматически поддерживается целостная стратегия пользовательского интерфейса, включающая различные варианты взаимодействия между формами, автоматическое формирование командного интерфейса для навигации по различным режимам и функциям системы, а так же всевозможные сервисные режимы, обеспечивающие комфортную работу пользователя.
Мы уже отмечали, что в интерфейсе "1С:Предприятия" реализовано много специальных элементов, не использующих стандартные средства операционной системы. Это сделано для того, чтобы можно было строить интерфейс, максимально отвечающий специфике деловых приложений.
В частности, в "1С:Предприятии" реализована собственная модель оконной системы, ориентированная . на работу с большим количеством разнородной информации. Например, максимизация окна управляется пользователем для каждой формы отдельно, а не как единый режим для всего приложения (как это принято в стандартных MDI приложениях). Кроме традиционных видов окон, в ней используются прикрепленные и прячущиеся окна. В интерфейсе "1С:Предприятия" из модального окна разрешается вызов немодальных окон, благодаря чему, фактически, образуется несколько слоев многооконного интерфейса. Разработчик может открывать модально любые формы, не изменяя логики их работы.
Поддерживается автоматический режим корректировки размеров элементов управления при изменении размера формы и при перемещении разделителей внутри нее. Таким образом, пользователь может установить желаемыйе размеры для каждой формы и отдельных ее частей, а формы автоматически используют все предоставленное пространство для эффективного отображения информации. Важно, что этот механизм не требует какой-либо настройки со стороны разработчика, но допускает, разумеется, и более тонкий тюнинг.
Формы и элементы управления имеют дизайн, ориентированный с одной стороны на отображение максимального количества информации, а с другой стороны на снижение утомляемости при длительной работе пользователя. Для этого используется "плоский" дизайн интерфейса приближенный к Web-дизайну. Для управления дизайном интерфейса предусмотрен механизм стилей, позволяющий централизовано изменять общий вид прикладного решения. Практически каждый элемент управления "оснащен" функциональностью, ориентированной на специфику экономических задач. Кроме того, предусмотрен ряд элементов управления непосредственно нацеленных на аналитические задачи, например, это диаграмма, диаграмма Ганта и т.д.
В интерфейсных механизмах "1С:Предприятия" имеется еще много интересных элементов, выше мы перечислили только некоторые решения. Важно, что весь набор интерфейсных механизмов предоставлен разработчику в достаточно высокоуровневых понятиях. Как уже говорилось, важным качеством концепции разработки в "1С:Предприятии" является изолирование прикладного решения от различного рода технических деталей. Например, разработчик не имеет доступа к управлению движениями мыши или детальной отрисовке элементов управления. Даже достаточно сложные механизмы предоставляются разработчику в таком виде, чтобы с одной стороны они могли бы функционировать вообще без какой-либо настройки, а с другой стороны - обеспечивали бы возможность настройки в простых высокоуровневых категориях, не требующих специальных знаний. Благодаря этому в прикладных решениях поддерживается современный полнофункциональный интерфейс, и в то же время, только незначительная доля исходного кода относится к его визуальной части а большая часть реализует собственно бизнес-логику интерфейса прикладного решения.
Следует упомянуть и о Web-расширении - механизме, позволяющем реализовывать Web-интерфейс к прикладным решениям "1С:Предприятия". Мы не будем рассказывать о деталях технологического устройстве этого механизма. Наиболее интересным в его реализации, на наш взгляд является то, что он также как и основной (rich) интерфейс максимально использует для автоматического формирования Web-форм информацию из метаданных, а также знания о назначении и устройстве прототипов прикладных объектов. Форма для редактирования любого объекта или просмотра списка объектов создается Web-расширением автоматически или может быть определена разработчиком вручную в проекте. Если разработчик описывает форму самостоятельно, то в его распоряжении специализированные элементы управления, которые не только позволяют организовать связь с теми или иными данными, но и предоставляют всю необходимую функциональность по просмотру и редактированию. Например, в полях ввода поддерживается выбор из форм-списков и подбор по первым буквам, в списках поддерживается иерархический просмотр, настройка пользователем фильтрации и сортировки. Система предоставляет большой набор стандартных действий по "обслуживанию" данных и самостоятельно организует связь между формами приложения. Таким образом обеспечивается единообразие двух вариантов пользовательского интерфейса (разумеется, с поправкой на особенности среды Web), а также максимальная автоматизация их разработки, основанная на использовании информации из метаданных.
Одним из наиболее важных, на наш взгляд, следствий построения пользовательского интерфейса на основе стандартных средств предоставляемых платформой является то, что интерфейс всех прикладных решений "1С:Предприятия" построен единообразно. Это позволяет пользователям максимально применять накопленный ранее опыт. Освоив приемы работы с интерфейсом одного бизнес-приложения, пользователь легко начнет работать с любым другим прикладным решением "1С:Предприятия".
Интеллектуальные механизмы подготовки отчетов В любом бизнес-приложении имеются два основных механизма, обеспечивающих взаимодействие пользователя с системой. Это интерфейс, предназначенный для ввода информации, и средства подготовки отчетов. Поскольку механизмы получения отчетов отвечают, прежде всего, за представление пользователю информации, необходимой для принятия управленческих решений, естественно, что в "1С:Предприятии" им уделено особое внимание.
Технология подготовки отчетов, примененная в "1С:Предприятии", содержит, по нашему мнению, целый ряд уникальных решений, не имеющих прямых аналогов в других продуктах. Прежде всего, следует отметить, что в платформе "1С:Предприятие" нет традиционного для большинства систем отдельного средства "генератор отчетов". Для подготовки отчетов разработчику предлагается целый ряд механизмов, которые могут использоваться в различных комбинациях и в сочетании с другими механизмами. Благодаря этому в "1С:Предприятии" отчеты органично вписываются в общий интерфейс приложения. Фактически, пользователь в процессе работы не видит грани между общим интерфейсом и механизмом отчетности. По нашему мнению, в современной экономической прикладной системе и не должно быть иначе: ведь аналитическая информация может использоваться во всех режимах и формах, а отчеты формируются по большей части уже не для вывода их на печать, а для интерактивного анализа. Поэтому в "1С:Предприятии" средства подготовки отчетности тесно интегрированы с другими механизмами и имеют мощные возможности для интерактивной работы.
Одним из наиболее интересных механизмов такого рода, предоставляемых платформой, является построитель отчетов, предоставляющий возможность с минимальными усилиями получить отчет с развитой функциональностью.
Нам хотелось добиться того, чтобы разработчик или пользователь кратко описывал, какую информацию необходимо проанализировать, а все остальное для получения полнофункционального управляемого отчета построитель делал бы самостоятельно.
Выборка исходной информации осуществляется на основе описаний, выполненных с помощью языка запросов "1С:Предприятия". Поскольку при этом активно используются готовые виртуальные таблицы учетных механизмов, текст запроса для достаточно сложного отчета будет занимать всего несколько строчек. Его вовсе не обязательно писать вручную. В большинстве случаев запрос формируется средствами визуального конструктора и зачастую вся процедура сводится к выбору источника данных и указанию полей итогов. Данный инструмент позволяет визуально формировать логические конструкции практически неограниченной сложности, включая объединения запросов и вложенные запросы, а также способен "поднимать" для редактирования текст запроса, расположенный в любом месте модуля.
На основании всестороннего анализа текста запроса построитель самостоятельно формирует всю инфраструктуру необходимую не только для генерации отчета, но и для тонкой его настройки пользователем, а также для навигации между отчетами. В результате создается форма, содержащая как собственно отчет, так и разнообразные средства для управления им - выбора включаемых в отчет полей, фильтрации информации по сложным критериям, группировки по строкам и колонкам, настройки упорядочивания данных и т.д. Отображаться отчет может в виде таблицы с многоуровневой иерархией строк и колонок, диаграммы, сводной диаграммы или сводной таблицы.
Заметим, что интерактивная настройка фильтрации обеспечивает такие возможности, как установка отбора по полям связанных таблиц (полученных "через точку"), указание в качестве критерия отбора множества значений или групп объектов, в иерархии которых нужно отбирать информацию. Например, пользователь может настроить отчет по закупкам товаров таким образом, чтобы в него вошли только накладные, содержащие товары, производители которых относятся к группам "Отечественные" и "Зарубежные". При этом построитель позволяет сохранять текущие пользовательские настройки отчета для последующей работы.
Кроме того, построитель автоматически включает в сформированный отчет всю информацию, необходимую для расшифровки отдельных ячеек отчета (drill-down). Эта расшифровка выполняется в интерактивном режиме- буквально одним щелчком мыши по выбранной ячейке отчета может быть автоматически сформирован более детальный отчет на основании данных этой ячейки и информации, содержащейся в исходном отчете:
Очень важно, что все эти возможности, представляемые разработчику в готовом виде, могут использоваться им в различных комбинациях. В результате он может гибко определять для каждого создаваемого отчета, какие "степени свободы" предоставить пользователю, указывая это в тексте запроса. Так, например, можно указать, по каким полям пользователь может устанавливать фильтрацию, упорядочивание, группировки и т.д. Сами элементы управления отчетом включаются в форму также по усмотрению разработчика. Поскольку все составляющие данного механизма могут использоваться независимо, разработчик может применять построитель не только для подготовки отчетов, но и для решения многих других задач. Например, он может создать процедуру группового изменения данных, в которой для управления выборкой данных будут задействованы все механизмы построителя, но затем полученная выборка будет не отображена в отчете, а пройдет заданную обработку, например, для выбранной группы товаров будут скорректированы цены.
Так же весьма важным эффектом использования этого механизма мы считаем то, что на его основе в прикладных решениях "1С:Предприятия" реализуются инструменты, в которых "продвинутые" пользователи действительно могут самостоятельно создавать достаточно сложные отчеты. На основе этого механизма построена специальная консоль отчетов, используемая в большинстве прикладных решений и предоставляющая пользователю возможность проектировать собственные отчеты, тут же их формировать, настраивать и даже создавать систему связанных, детализирующих друг друга отчетов.
Не были забыты и вопросы эффективности изобразительных средств. В "1С:Предприятии" для визуализации и печати отчетов используется прежде всего метафора табличного документа (без средств вычислений). Основной идеей данного решения является использование модели электронной таблицы (spreadsheet) в качестве средства оформления отчетных документов, без использования ее как средства вычисления.
В отличие от большинства электронных таблиц табличный документ "1С:Предприятия" может содержать таблицы, имеющие очень большие размеры, как по вертикали, так и по горизонтали. У него богатый набор изобразительных возможностей, позволяющий с одной стороны создавать хорошо оформленные аналитические отчеты, а с другой - подготавливать регламентированные бланки с точной привязкой содержащихся в них объектов к локальным координатам. В отличие от стандартных электронных таблиц здесь разрешается описывать строки с различными настройками ширины колонок. Это необходимо для создания сложных отчетов включающих несколько разноформатных таблиц.
В большинстве случаев заполнение отчета выполняется на основании макета. Для этого в табличном документе предусмотрена гибкая система именования областей и описания параметров. Разработчик визуально проектирует макет, определяющий внешний вида отчета, выделяя в нем различные области, которые должны заполняться данными, и описывая их параметры. При формировании отчета происходит совмещение областей с данными и таким образом содержательная часть отчета объединяется с его внешним оформлением. Следует заметить, что макет отчета может как формироваться построителем автоматически, так и создаваться разработчиком. . Допускается использование готовых стилей оформления отчетов и проектирование собственных.
Важно, что средство генерации табличных документов служит не только для получения статических печатных форм. В нем имеется мощный интерактивный механизм для управления многоуровневыми группировками, расшифровки ячеек отчета(drill-down), автонастройки ширины колонок и т.д. Допускается сохранение отчета в различных форматах (html, xls, txt). Кроме того, для интерактивного анализа многомерной информации в табличном документе может использоваться сводная таблица, которая позволяет непосредственно управлять группировкой информации и составом отображаемых данных, не обновляя отчета.
Чрезвычайно важным качеством табличного документа является возможность использования его в качестве полнофункционального механизма ввода и редактирования информации. Такой документ может содержать любые элементы управления, используемые в формах "1С:Предприятия", как в самих ячейках и рисунках, так и поверх ячеек. Это особенно полезно в тех случаях, когда одна и та же форма должна представлять собой и отчет, и инструмент для редактирования информации. Примером может служить отчет о плановых показателях, которые разрешается корректировать.
Для визуального представления аналитической информации разработчику предлагается набор различного вида диаграмм, а также диаграмма Ганта, сводная диаграмма и дендрограмма. Причем эти элементы могут включаться как в формы, наравне с другими элементами управления, так и в табличные документы для получения комплексных аналитических отчетов.
Весьма полезен также механизм интеллектуального анализа данных (data mining), с помощью которого прикладное решение можно с минимальными затратами оснастить такими аналитическими инструментами, как кластерный анализ, дерево решений и т.д.
Важная особенность платформы "1С:Предприятие" состоит в том, что для формирования отчетов любой сложности разработчику не придется подключать дополнительные внешние механизмы. При этом все внутренние инструменты хорошо интегрированы, базируются на единой системе понятий и максимально используют возможности друг друга. Например, сводная таблица, располагаемая в табличном документе, для того чтобы автоматически модифицировать запрос к базе данных по мере того, как пользователь визуально указывает новые уровни группировки, обращается к функциям построителя отчетов. Разумеется, в системе присутствует и конструктор отчетов, который позволяет проектировать их интерактивно , однако важно, что конструктор только "собирает" отчет из имеющихся механизмов ("кубиков"), применяемых и для решения множества других задач. Как показала практика, при таком подходе на разработку достаточно сложного отчета уходит не более нескольких минут.
Построение распределенных и интегрированных информационных систем Еще одной "козырной картой" платформы "1С:Предприятие" являются механизмы обмена данными.
Изначально решение о создании механизма обмена данными, предназначенного для территориально распределенных информационных баз и не требующего постоянного соединения, было обусловлено в большей степени отсутствием в распоряжении отечественных предприятий качественных высокоскоростных телекоммуникационных каналов. Однако некоторое время спустя стало очевидно, что разработка таких механизмов лежит в русле одного из наиболее перспективных направлений мировой инженерной мысли.
Сегодня в распоряжении разработчика приложений имеется мощный набор механизмов обмена, способный решать самые разнообразные задачи. Кроме традиционной поддержки территориально распределенных информационных систем, с его помощью осуществляется интеграция с другими прикладными программами, а также строятся сложные гетерогенные информационные системы, включающие наряду с решениями на платформе "1С:Предприятие" еще и внешние приложения.
Использование технологий обмена для решения столь широкого спектра задач объясняется тем, что в распоряжении разработчика не монолитное решение, а набор механизмов, которые могут применяться как по отдельности, так и совместно, в любых сочетаниях. Эти механизмы поддерживают работу с XML документами, XML-сериализацию данных, инфраструктуру сообщений, службу регистрации изменений, планы обмена, управление распределенной информационной базой:
Практически уникальным , по нашему мнению, качеством данного набора механизмов является то, что он обеспечивает очень высокий уровень готовности системы к работе в распределенной среде - организация обмена практически не требует дополнительных затрат на разработку. Нужно просто задать в интерактивном режиме состав данных, участвующих в обмене, а механизм обеспечит формирование сообщений и их загрузку. При этом система автоматически организует обмен только измененной информацией, отслеживает получение сообщений, определяет необходимость повторной отправки данных, разрешает коллизии и проверяет целостность загружаемой информации. Гибкие возможности настройки позволяют сформировать практически любую топологию схемы узлов обмена (звезда, снежинка, схемы без центрального узла). Состав данных, участвующих в обмене, и правила разрешения коллизий могут задаваться произвольно. При этом механизмы обмена с одной стороны минимизируют объем передаваемых данных (пересылаются только измененные данные), а с другой - гарантируют устойчивость к потере сообщений. Иными словами, система способна функционировать как в условиях гарантированной доставки сообщений, так и без таковой.
Наличие в платформе эффективных, не требующих сложной настройки механизмов обмена обязано, прежде всего, общей архитектуре построения прикладных решений, реализованной в платформе "1С:Предприятие". Мы уже говорили, о том, что органичный переход к распределенным и интегрированным системам обеспечивается объектной техникой манипулирования данными, используемой в "1С:Предприятии". Система соответствующих объектов обеспечивает штатные возможности сохранения (persistence) любых прикладных данных в формате XML. Кроме того, благодаря наличию стандартных прототипов прикладных объектов платформа способна автоматически задавать для каждого объекта необходимую гранулярность передачи изменений и стратегию обмена в соответствии с его назначением. Основной проблемой большинства известных систем обмена и репликации является то, что в заложенной в них семантике описания данных не содержится сведений о том, какими порциями выполнять обмен, как разрешать коллизии, как обеспечивать логическую целостность и непротиворечивость данных. Из-за этого разработчику при использовании подобных механизмов обычно приходится детально описывать процедуры обмена для каждого информационного массива.
Механизмы обмена "1С:Предприятия" функционируют на уровне стандартных прототипов прикладных объектов и поэтому имеют в своем распоряжении всю необходимую информацию такого рода изначально. Разработчику необходимо только указать, что в обмене участвуют объекты определенного вида. Далее все действия, по регистрации изменений, формированию сообщений, загрузке данных и разрешению коллизий будут выполняться автоматически. Разработчик, конечно, имеет возможность вручную выполнить "тонкую настройку", но она потребуется только в отдельных случаях.
Другая важная особенность механизмов обмена "1С:Предприятия" - их соответствие передовым мировым концепциям интеграции информационных систем. Мы прекрасно понимаем, что сегодня ни один разработчик экономического софта не может считать себя "царем горы", которому нет необходимости заботиться о тесном взаимодействии с системами других вендоров. В данном контексте взаимодействие - не просто умение вызвать какую-то функцию из другой программы или экспортировать в нее какие-либо данные. Речь идет о построении сложных гетерогенных систем, в которых несколько разнородных прикладных решений образуют слаженно действующий ансамбль. Очевидно, что эта тенденция станет в обозримом будущем одной из доминирующих на рынке экономических систем. Механизмы обмена "1С:Предприятия" имеют высокую готовность к работе в гетерогенных системах сегодняшнего и завтрашнего дня не только за счет того, что весь обмен производится на формате XML, но, что еще более важно, в силу идеологического соответствия реализованных решений указанной тенденции. Уже сегодня механизмы обмена "1С:Предприятия" позволяют осуществлять взаимодействие не только с отдельными приложениями, но и с перспективными интеграционными платформами.
Поставка и обновление прикладных решений Практически все производители прикладных программ предусматривают в них механизмы для обновления версий. Однако для таких систем как "1С:Предприятие" подобные задачи представляют особую сложность. Это объясняется, во-первых, тем, что экономические системы обновляются гораздо чаще, чем другие, а во-вторых, тем, что достаточно часто практикуется изменение прикладных решений "1С:Предприятия" "на местах" с целью адаптации тиражного продукта к потребностям конкретного клиента. Последняя особенность представляет особую сложность, так как при выпуске разработчиком любого обновления прикладного решения возникает необходимость синхронизации сделанных им изменений с теми, что были внесены в процессе внедрения у заказчика.
Для решения этих и множества других задач, связанных с поставкой и обновлением прикладных решений, в "1С:Предприятии" реализован целый комплекс механизмов ориентированных как на разработчиков, так и на пользователей. Они охватывают весь технологический процесс поставки и поддержки: подготовку дистрибутивных файлов, инкрементных обновлений и установочных комплектов поставки, публикацию обновлений в Интернете, автоматический их поиск и выполнение, управление составом поддержки на уровне объектов конфигурации и т.д.:
Одним из наиболее существенных элементов технологии обновления является механизм, обеспечивающий синхронизацию изменений, сделанных поставщиком прикладного решения с изменениями, внесенными при внедрении на конкретном предприятии. Он предоставляет мощные функции сравнения и анализа изменений, а также средства управления их синхронизацией. Администратор или разработчик может детально настроить синхронизацию обновлений вплоть до отдельных объектов, отдельных свойств и отдельных процедур модулей. Например, если специалист, отвечающий за сопровождение прикладного решения на предприятии, отметит объекты, которые намерен поддерживать самостоятельно, они не будут в дальнейшем обновляться при установке очередного обновления от поставщика. Если объекты необходимо объединить, то для упрощения синхронизации изменений можно настроить приоритеты такого объединения.
Механизмы обновления позволяют построить сложную многоуровневую систему сопровождения. Поставщики специализированных вертикальных решений могут находиться на поддержке у разработчиков универсальных приложений, и обеспечивать в свою очередь поддержку собственных клиентов. Пользователь при этом будет эксплуатировать прикладное решение, отдельные части которого сопровождаются разными фирмами.
Поскольку механизм обновления в значительной мере основан на том, что все прикладное решение описывается с помощью метаданных, а бизнес-логика приложения строится на стандартных прототипах прикладных объектов, система способна поддерживать стратегию обновления с учетом специфики архитектуры прикладного решения, контролировать его логическую целостность и предоставлять пользователю информацию об изменениях в наглядной форме.
А также… Допускается реализация всего интерфейса прикладного решения на нескольких языках. Каждый пользователь может работать с одним из заложенных в него языков. При этом не нужно выносить все строки в отдельные файлы. Элементы интерфейса редактируются на нескольких языках "по месту" - в формах, макетах печатных документов, в меню и т.д. Разработчик может в любой момент переключиться и редактировать интерфейс форм на другом языке. Допускается также поочередное редактирование конкретной надписи на всех поддерживаемых языках. Если необходимо расширить языковую базу, можно собрать все текстовые элементы в общий список с тем, чтобы перевод одинаковых надписей отражался сразу во всех компонентах интерфейса. Общая стратегия интернационализации включает также перевод системного интерфейса, хранение всех строк в кодировке UNICODE, форматирование дат и чисел в соответствии с особенностями различных стран и языков, построение правил сортировки с учетом национальных стандартов и т.д.
Выполнение алгоритмов бизнес-логики разработчик может по своему усмотрению переносить на сервер "1С:Предприятия". Это позволяет ему управлять распределением нагрузки между клиентом и сервером. При этом от разработчика не требуется специальных навыков построения трехуровневых архитектур, знания сетевых протоколов и т.д. Все технологические детали система берет на себя и обеспечивает рациональное использование серверных ресурсов за счет поддержки stateless-модели, кэширования и разделения системных ресурсов и т.д.
В системе защиты прав доступа "1С:Предприятия" реализована возможность настройки ограничений на уровне отдельных записей, а также полей таблиц. Это позволяет, например, предоставить пользователю доступ к именам сотрудников только в пределах своего департамента, а к данным по окладу и семейному положению - только для своих непосредственных подчиненных. Настройка таких ограничений требует лишь задания формального условия, после чего система контролирует все действия пользователей автоматически, разработчику не нужно учитывать эти ограничения в явном виде при реализации различных интерфейсных режимов и алгоритмов бизнес-логики.
Обеспечиваются две стратегии проверки прав доступа. В зависимости от решаемой задачи, система контроля прав доступа может как отвергнуть обращение пользователя к закрытым для него данным, так и просто исключить недоступные записи из выборки, предоставив пользователю только доступную информацию.
Одним из мощных инструментов разработчика в "1С:Предприятии" является механизм сравнения и объединения прикладных решений. Мы уже упоминали о нем, когда говорили о возможностях поддержки, однако этот механизм может весьма эффективно использоваться и в процессе разработки. Данный инструмент может использоваться как для анализа различий, так и для переноса части функций из одного приложения в другое. Он обеспечивает удобное визуальное представление различий между прикладными решениями и имеет гибкие возможности настройки логики сравнения. При сравнении родственных конфигураций данный механизм автоматически сопоставляет даже переименованные объекты, используя для этого внутреннюю идентификацию метаданных. Соответствие сравниваемых объектов независимо от совпадения их имен можно настроить и вручную, после чего оно будет учтено и во всех ссылках на такие объекты, имеющихся в других объектах прикладного решения. Кроме того, механизм сравнения содержит средства для визуального представления отличий форм интерфейса и макетов печатных документов. Благодаря использованию структуры метаданных и средств визуального сравнения интерфейсных объектов, с помощью нашей платформы удается решать гораздо больше задач, чем в тех системах, где механизмы сравнения базируются на сопоставлении файлов исходных кодов программ.
В "1С:Предприятии" поддерживается протоколирование действий пользователей в журнале регистрации. Система имеет несколько уровней протоколирования, которые могут функционировать автоматически, не требуя дополнительных усилий со стороны разработчика. Прежде всего, разумеется, фиксируются начало и окончание сеансов работы пользователей, административные операции с информационной базой, а также регистрируемые ошибки. За счет того, что все изменения в БД выполняются исключительно в объектной технике (через объекты, отвечающие за манипулирование данными), система может автоматически регистрировать их в журнале, причем будет делать это независимо от того, как они выполнялись (интерактивно или программно). Разработчик может также реализовать внесение в журнал любых других записей, которые система не способна фиксировать автоматически, например, информацию об отправке факса или формировании отчета. Важно заметить, что журнал регистрации реализован как отдельный системный механизм. Он не использует для хранения информации базу данных "1С:Предприятия", а, следовательно, его ведение не создает существенной дополнительной нагрузки на систему и не замедляет работу пользователей.
Итак… В этой статье мы попытались перечислить наиболее интересные технологические новшества платформы "1С:Предприятие". При этом мы старались показать, что все реализованные в ней решения основаны на использовании единой модели и единой архитектуры.
Важно и то, что все механизмы платформы в той или иной степени используют возможности других механизмов. Например, почти все они опираются на структуру метаданных и наличие системы прототипов прикладных объектов. Таким образом, хотя каждая из возможностей "1С:Предприятия" может быть достаточно ценна сама по себе, наибольший интерес представляет рассмотрение всей их совокупности в рамках целостной модели.
Сформулируем еще раз несколько общих принципов, лежащих в основе модели "1С:Предприятия":
Наличие единой, сквозной высокоуровневой модели и реализующих ее технологий позволяет, по нашей оценке, на порядок сократить затраты на создание и поддержку прикладных решений.
Начиная в 1996 г. работы в этом направлении, и даже выпустив первую версию платформы, мы, конечно, не были абсолютно уверены в правильности выбранного пути. За пошедшее с тех пор время концепция системы успешно развивалась, и сегодня она воплощена в платформе "1С:Предприятие 8". Строго говоря, в мире не так уж много специализированных технологий, ориентированных именно на быстрое создание бизнес-приложений. Однако становится все более очевидным, что данный путь лежит на стратегическом направлении развития бизнес-софта.
По оценкам многих специалистов, с которыми нам приходилось общаться, ситуация в России и в странах бывшего СССР, где сложилась целая индустрия разработки и поддержки бизнес-решений, основанная на специализированной технологической платформе, по мировым меркам является уникальной. По нашим наблюдениям, не существует аналогичной специализированной платформы, на которой различными фирмами создавалось бы такое количество разнообразных массовых бизнес-приложений, покрывающих потребности существенной части рынка какого-либо региона. Соответственно, для многих специалистов наши подходы и решения представляют особый интерес, так как реальный эффект от их реализации хорошо заметен на практике.
Разумеется, все изложенные выше соображения (включая и анализ современных тенденций) являются только нашей позицией и результатом наших исследований. Мы ни в коем случае не претендуем на абсолютную истину, которой в этих вопросах, по-видимому, и не существует. Наверняка, у многих читателей есть своя, отличная от нашей, точка зрения на проблемы, затронутые в статье. Мы будем признательны за отзывы (в том числе критические) по данной статье.
Статья опубликована в газете PC Week/Russian Edition (издается по лицензии международного издательского дома Ziff-Davis Media Inc.), NN 46 , 47 и 48 за 2004 г. Перед публикацией на сайте v8.1c.ru в статью был внесен ряд дополнений, по техническим причинам не вошедших в газетный вариант, а также добавлены иллюстрации.
Фирма «1С» благодарит редакцию PC Week/RE за сотрудничество и помощь при подготовке статьи к публикации.
|
|||||
Типовые
Сначала сделаем небольшое замечание по терминологии. Эта статья не ориентирована исключительно на тех, кто имеет дело с системой программ "1С:Предприятие". Как нам кажется, она может быть интересна многим специалистам, интересующимся развитием технологий экономических и корпоративных приложений, независимо от того с какими продуктами они работают. Поэтому в данной статье мы постараемся лишь в минимальном объеме использовать терминологию, специфическую для "1С:Предприятия". В некоторых случаях мы будем использовать для близких понятий различные термины, приводя их аналоги и необходимые разъяснения. 
Разумеется, любая фирма-разработчик бизнес-софта имеет достаточно мощный инструментарий и набор технологий, с помощью которых строит свои решения. Однако, при разработке "1С:Предприятия" мы изначально ориентировались на создание полнофункциональной, целостной платформы, которая будет использоваться для построения самых разнообразных бизнес-приложений не только самой фирмой "1С", но и множеством других компаний-разработчиков, знакомых со спецификой тех или иных отраслей. Вот почему платформа изначально создавалась как тиражируемый продукт, включающий как все необходимые технологии для эксплуатации бизнес-приложений, так и инструменты для их разработки и модификации. 
Заметим, что понятие платформы и платформенно-ориентированного построения приложений сейчас является общепринятым и трактуется гораздо шире, чем просто способность работать в определенной операционной системе. Под платформой понимается среда исполнения и набор технологий, используемые в качестве основы для построения определенного круга приложений. Фактически, приложения базируются на нескольких платформах, образующих многослойный пирог. При этом важно, что платформа предоставляет разработчику определенную модель, как правило, изолирующую его от понятий и подробностей более низкоуровневых технологий и платформ. Такова и платформа "1С:Предприятие", позволяющая использовать самые разные технологии более низкого уровня, не меняя кода бизнес-приложений.
В основе бизнес-приложения лежат метаданные. Они представляют собой структурированное декларативное его описание. Метаданные образуют иерархию объектов, из которых формируются все составные части прикладной системы и которые определяют все аспекты ее поведения. Фактически, при работе бизнес-приложения платформа "проигрывает" (интерпретирует) метаданные, обеспечивая всю необходимую функциональность.
Если говорить о различиях моделей бизнес-приложений и средств их разработки то, пожалуй, наиболее существенным окажется то, в каких понятиях (можно даже сказать "в какой парадигме") описывается приложение. Разумеется, в каждом средстве разработки может использоваться несколько способов описания, но какой-то один набор понятий всегда является основополагающим.