Технологические вопросы

Многопользовательский режим

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

Работа в архитектуре клиент—сервер

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

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

Распределенная обработка

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

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

Жизненный цикл прикладной разработки

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

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

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

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

Готовые технологии

Системные технологии

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

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

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

Прикладные решения

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

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

Методическое сопровождение

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

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

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

Не только о достоинствах

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

Фактически ограничения системы «1С:Предприятие» напрямую вытекают из ее преимуществ. Разработка прикладного решения на стандартном языке программирования с непосредственным использованием стандартной СУБД позволяет сделать «что угодно» и «как угодно». При разработке средств конфигурирования «1С:Предприятия» не ставилась задача создания универсального средства разработки или универсальной СУБД. В противном случае мы бы не имели и тех преимуществ, о которых говорилось выше. Таким образом, «1С:Предприятие» как средство разработки — это специализированный инструмент и потому дает преимущества при использовании «по назначению». В связи с этим большинство ограничений, которые «стесняют» свободу разработчика, заложены в систему вполне осознанно.

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

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

Конечно, это не единственный аргумент в пользу принятого нами решения. Включение операторов SQL приводит к необходимости погружения прикладного разработчика в особенности работы с конкретным SQL-сервером (даже работа с MS SQL Server 6.5 и 7.0, хоть и немного, но различается).

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

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

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

ОБ АВТОРЕ

Сергей Нуралиев — руководитель отдела разработки экономических программ фирмы «1С».

О безбумажной технологии

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

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

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

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

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

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

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