Open Source
English version
 
 
Техническое задание

Техническое задание

на проектирование учетной задачи

Последнее редактирование













Составил:

М.Фисков fiskov@mail.ru

А.Черепанов subskull@mail.ru























г. Красноярск

2002г.

Оглавление

1. Введение 3

1. Описание предметной области 4

1.1. Базовые термины 4

1.2. Классификация документов 4

1.3. Принцип построения учета 4

1.4. Требования к комплексу автоматизации 4

1.4.1. Требования к реализации учета 5

1.4.2. Требования к реализации системы 5

2. Архитектура системы. 6

2.1. SQL – сервер. 6

2.2. Сервер задачи. 6

2.3. Модули конфигурации. 10

2.4. Клиентское приложение. 10

2.5. Комплект программ для администрирования и управления. 10

2.5.1. Инсталяция модулей конфигурации и отчетов. 11

2.6. Сервер задач. 12

2.6.1. Подсистема безопасности. 13

2.6.2. Подсистема ввода-вывода. 15

2.6.3. Подсистема драйверов базы данных. 15

2.6.3.1. Класс таблиц. 16

2.6.3.2. Класс записей таблицы. 16

2.6.3.3. класс списка записей таблицы. 17

2.6.3.4. класс “поле записи” 17

2.6.3.5. Класс транзакций 18

2.6.3.6. Семейство классов “история таблицы” 18

2.6.3.7. “точка актуальности” 19

2.6.3.8. Таблица с периодическими реквизитами 21

2.6.4. Подсистема управления модулями (объектами). 22

2.6.5. Диспетчер форм. 22

2.6.6. Генератор отчетов. 22

2.6.7. Подсистема отладки. 23

2.6.8. Подсистема формирования графических отчетов. 23

    Введение



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

На основании сложившейся ситуации было принято решение разработать собственный комплекс(среду) автоматизации хозяйственной деятельности предприятия, которая бы удовлетворяла следующим требованиям:

  • надежная работа комплекса на любой технике и линиях связи;

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

  • архитектура клиент-сервер с любым уровнем охвата - от Интранет-решений до WWW;

  • использование любой БД для хранения и обработки данных с использованием всех доступных средств СУБД - транзакций, триггеров, хранимых процедур;

  • открытый платформонезависимый протокол связи с сервером, позволяющий работать клиентам как из консоли, так и из специализированных графических приложений, а также обмениваться данными с партнерами в формате XML и SOAP;

  • полноценная и легко настраиваемая система отчетов в любом формате;

  • адаптация документооборота под любые бизнес-процессы организации;

  • экспорт данных из популярных бухгалтерских программ(1С и т.д.);

  • удобные и надежные средства администрирования: простое создание резервных копий, управления пользователями и назначение прав доступа к информации;

  • тесная интеграция с уже используемыми программами анализа и документооборота как внутри организации, так и с системами партнеров и клиентов;

  • наличие серверного и клиентского программного обеспечения под наиболее популярные платформы (Windows, Linux, FreeBSD) с возможностью портирования и под другие платформы, поскольку комплекс должен поставляться в открытых исходных кодах;

  • простота создания и изменения бизнес-логики непрофессиональными пользователями.

    Описание предметной области

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

    Базовые термины

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

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

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

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

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

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

    Классификация документов

В рамках предметной области документы подразделяются на следующие типы:

  • организационно-распорядительные;

  • внутренние;

  • внешние;

  • бухгалтерские;

  • прочие.

    Принцип построения учета

Организация учета на предприятии регламентируется организационно-распорядительными документами и законодательством.

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

    Требования к комплексу автоматизации



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

    Требования к реализации учета

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

  2. должна быть обеспечена единовременная работа нескольких операторов.

  3. должна быть отражена связь между документами для получения истории работы бизнес-процесса.

  4. система должна обеспечивать приемлемое время отклика на действия оператора.

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

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

  7. система должна обеспечивать печать заполненных бланков документов и возможность передачи информации в электронном виде в совместимых форматах.

  8. должна быть обеспечена максимальная надежность хранения и обработки данных

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

    Требования к реализации системы

  1. система должна работать по возможности на любой компьютерной технике и телекоммуникациях.

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

  3. должна быть предусмотрена простое и эффективное изменение логики учета, реализованное в системе, непрофессиональным пользователем.

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

  5. система должна поставляться в открытых исходных кодах как для проверки потенциальных возможностей для взлома, так и адаптации системы на самом низком уровне.

  6. должна быть осуществлена поддержка продукта производителями по установленной договоренности.

  7. система должна иметь приемлемую стоимость приобретения и обслуживания.

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

    Архитектура системы.

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

Система состоит из следующих приложений.

  1. Сервер РСУБД;

  2. Сервер задачи;

  3. Модули конфигурации;

  4. Клиентское приложение;

  5. Комплект программ для администрирования и управления.

Рассмотрим указанные приложения.


    Сервер РСУБД.

Для хранения данных в системе должен быть применен сервер реляционных баз данных от сторонних разработчиков.

Для этого сервера устанавливаются следующие требования:

  1. Поддержка языка SQL для построения запросов.

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

  1. Наличие бесплатной или свободной лицензии на продукт.

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

  1. Поддержка транзакций с блокировкой записей.

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

  1. Наличие триггеров и встраиваемых процедур (функций).

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

  1. Наличие системы поддержания целостности данных.

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

  1. Поддержка вложенных запросов.

Это способ существенно упростить систему формирования отчетов.

  1. Поддержка больших баз данных.

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

  1. Функционирование сервера на популярных платформах.

Сервер баз данных согласно направлению на создание версий системы под популярные платформы (Unix/Linux, Windows) должен быть доступен в версиях под эти платформы.

При рассмотрении указанных требований применительно к известным на сегодняшний день серверам РСУБД был выбран сервер баз данных, используемый в качесве базового: PostgresSQL. Однако это не означает, что будет использован исключительно этот сервер и подключение прочих серверов баз данных неосуществимо – этот выбор означает, что разработчики гарантируют стабильную работу системы с использованием именно этого сервера баз даных. Подключение других серверов возможно только на свой страх и риск и разработчики не несут отвественности за корректную работу системы на этих серверах баз данных.

    Сервер задачи.

Сервер задачи – это собственно и есть главное приложение. В целом его схема представлена на рис. .


Рисунок 1. Схема сервера.




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

  • список доступных баз данных с их названиями и ссылками;

  • метод аутентификации и публичные ключи (при использовании SSL).

При создании сессии происходит наследование процесса (fork), который наследует все данные аутентифицированного пользователя и роли в выбранной базе данных. Созданный таким образом процесс существует все время существования активного соединения клиента и сервера и имеет в своем составе следующие подсистемы:

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

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

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

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

  5. Подсистема межпроцессного взаимодействия. Это, так называемые, горизонтальные связи для осуществления синхронизации данных, отображаемых клиентами и функционирования системы “чат”. Горизонтальные связи образуются при помощи каналов. Каналы в Unix осуществляют взаимодействие только между родителями и детьми, либо между прямыми потомками одного процесса. В этом случае количество открытых каналов должно соответствовать количеству устанавливаемых горизонтальных соединений. Поэтому для нас более подходит вариант установления горизонтальных связей через “родителя”. В этом случае demon создает поток диспетчера каналов. Диспетчер имеет список открытых каналов и перед выполнением fork создает канал, который впоследствии наследуется дочерним процессом. Диспетчер дочерних процессов ведет учет работающих дочерних процессов, созданных им. Он постоянно выполняет проверку наличия данных от дочерних процессов и при получении их рассылает всем активным процессам (за исключением процесса, передавшего данные). В дочернем процессе для осуществления горизонтального взаимодействия создается диспетчер сообщений для отправки и обработчик принимаемых сообщений от demon.

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

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

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

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

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

  • В поступивших данных передается файл. Он просто записывается во временный каталог на диске и клиенту отправляется ответ о завершении операции.

Все созданные потоки при завершении удаляют себя из списка диспетчера потоков и помирают.


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

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

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

    Модули конфигурации.

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

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

    Клиентское приложение.

Клиентское приложение представляет собой специализированный браузер для отображения форм и передачи пользовательских данных в сервер задачи. Клиент и сервер задачи общаются по протоколу HTTP. Языком для общения служит, разработанный для этих целей, UIML.

К клиентскому приложению предъявляются следующие требования:а) портируемость;

приложение должно быть портировано на платформы X11 и Windows. Кроме того должен существовать клиент, исполняемый в качестве модуля WEB-сервера. Возможно создание консольного клиента под Unix/Linux и DOS с ограниченными возможностями, вызванными спецификой платформы.

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

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


    Комплект программ для администрирования и управления.

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

  1. Инсталяция модулей конфигурации и отчетов.

  2. Создание, удаление и модификация таблиц базы данных при смене версий программы и модулей.

  3. Глобальное администрирование системы (настройка конфигурационных файлов).

  4. Резервное архивирование и восстановление базы данных (по времени, и с возможностью репликации базы на резервный сервер баз данных).

  5. Отладку модулей конфигурации, отчетов и форм.

  6. Система автоматического обновления программ, модулей конфигурации и отчетов.

  7. Импорт баз данных и конфигураций из 1С.

  8. А также другие задачи, применение которых связано с полной остановкой задачи.



Рассмотрим подробнее:

    Инсталяция модулей конфигурации и отчетов.

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

Модуль конфигурации содержит описание модуля в формате XML.

Описание модуля конфигурации содержит:

  1. Идентификатор открываемого окна.

  2. Описание классов, включающее: класс, его методы, передаваемый параметр и возвращаемый параметр, список классов, которые он использует, список прав класса со списком прав на зависимые классы по каждому методу. Кроме того, классы (методы), представляющие собой точки входа, имеют дополнительное описание, необходимое для создания меню, панели инструментов и контекстных пунктов правой кнопки мыши: название пункта меню, место его расположения, уровень в иерархии; идентификатор иконки, идентификатор панели, url иконки, место ее расположения в панели; альтернативное описание (подсказка), горячая клавиша, ссылка на контекстную помощь и т.п.

  3. Функции добавляемые к правой кнопки мыши в этом окне: идентификатор объекта (метода); наименование пункта меню правой кнопки; ссылка на иконку; уровень в иерархии.

  4. Описание статичных таблиц базы данных, используемых модулем.

  5. Описание данных статичных таблиц базы данных.

  6. Скрипты, исполняемые перед инсталляцией и после инсталяции.

Собственно модуль содержит:

Конструктор и деструктор модуля.

Модуль может содержать более одного объекта с кучей методов входа и более одной панели панели инструментов.

При инсталляции модуля на основе указанной информации заносится таблица реестра классов в базе данных. При этом проверяется корректность прав на классы.

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

В таблице приведен реестр классов, создаваемый на основе описания модуля.

Таблица “Реестр объектов”

N пп

Назначение

Идентификатор

Примечание

Ключ таблицы

ID


Ссылка на вышестоящий уровень иерархии


Это ссылка на эту же таблицу если имеет место уровень вложенности

Имя модуля (ссылка)


Адресация к модулю

Имя класса (ссылка)


Адресация к классу

Имя метода (ссылка)


Адресация к методу класса

Передаваемый параметр


????

Идентификатор меню


Ключ меню

Идентификатор пункта меню


Ключ пункта меню

Идентификатор панели


Ключ панели

Идентификатор иконки


Ключ иконки

Наименование пункта меню


Для отображения

Пиктограмма


Ссылка на пиктограмму

Горячая клавиша



Контекстная подсказка



Идентификатор помощи



Идентификатор окна


Имя окна, создаваемого для объекта.

Идентификатор пункта меню правой кнопки мыши.



Наименование пункта меню правой кнопки мыши.



Иконка правой кнопки мыши.



Варианты прав доступа к классу


СоздатьОткрыть для ... чтениядобавленияредактированияУдалитьНедоступно (что может быть)

Уровень иерархии



Уровень внутри иерархии



Активнонеактивно


При старте системы ???

Признак “активно всегда”


Для глобальных пунктов меню


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

Соответственно при деинсталляции модуля из таблицы реестра и таблицы прав на объекты удаляются все записи, касающиеся данного модуля, удаляются таблицы, созданные при его инсталляции и удаляются столбцы других таблиц, созданные модулем и удаляются записи в системных таблицах.

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

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

    Сервер задач.

Поскольку сервер задач занимает центральное место в архитектуре всей учетной задачи, есть смысл детально рассмотреть его базовую архитектуру.

Сервер задач в своем составе имеет следующие подсистемы: а) подсистема безопасности (авторизации);

б) подсистема ввода-вывода;

в) подсистема драйверов базы данных;

г) подсистема управления модулями;

д) диспетчер форм;

е) генератор отчетов;

ж) подсистема отладки;

з) подсистема формирования графических отчетов; Сразу оговоримся, что подсистемой будем называть комплекс программ, классов, объектов и их методов, объединенных общей задачей.


Разберем их функциональное назначение:


    Подсистема безопасности.

Подсистема безопасности на самом деле состоит из трех частей:системы авторизации клиента,

системы проверки прав доступа к ресурсам (объектам и записям базы данных),системы администрирования прав доступа.

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

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

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

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

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

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

Права доступа к классам наследуются от прав доступа к соответствующим объектам.


Таблица определения прав доступа

N пп

Назначение

Идентификатор

Примечание

Идентификатор



Идентификатор пользователя


Ссылка на запись реестра пользователей

Идентификатор строки реестра


Ссылка на реестр объектов

Тип прав доступа к классу


СоздатьУдалитьОткрытьНедоступно


Тип прав доступа к объекту класса


Открыть для чтениедобавлениередактирование и т. п.

Права доступа


Что конкретно доступно


При каждом обращении к объекту осуществляется проверка двух типов прав: внутрисистемная система прав и права доступа к базе, поскольку connect с базой данных осуществляется от имени пользователя.

Система администрирования прав доступа:


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

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

В системе создаются группы пользователей, которым назначаются одна или несколько ролей. Совокупные права пользователей на группу определяются объединением прав “ролей” , назначенных этой группе. Права пользователя к классам определяются правами группы, которой он принадлежит.

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

Таблица прав доступа пользователя к таблицам формируется аналогично и прописывается в таблицу прав доступа SQL сервера.

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

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

Пользователю предоставляется право самому переопределять пароль доступа. Соответственно изменяются пароли в таблице Users и в базе данных.

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

При удалении модуля выполняется обратная операция и вновь пересоздаются все соответствующие таблицы.

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


    Подсистема ввода-вывода.

Состоит из системы передачи данных через сокеты (порт) по протоколу HTTP. Системы подготовки данных и системы приема и декодирования данных клиента.

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

Поскольку UIML представляет собой текстовое описание формы, аналогом подсистемы ввода вывода могут служить PerlCGI. (не судите строго). Это набор объектов для автоматизации создания UIML кода. Можно различить две разновидности форм, создание которых может потребоваться: форма целиком описана и создается либо телом сервера задачи, либо модулем скрипта, или текст формы лежит в отдельном файле и содержит “включения на стороне сервера”, другими словами, содержит распознаваемый уникальный код, обрабатываемый модулем конфигурации с передачей параметров последнему, на место которого подставляется генерируемый код. Эти два метода формирования форм не являются противоречивыми и взаимно дополняют друг-друга. Отдельно нужно добавить что эта подсистема умеет пердавать клиенту файлы, оснащая их mime типом, а также импортировать файлы для последующе обработки сервером. Файлами выступают картинки, отчеты и др., отображаемое либо клиентом непосредственно, как броузером, либо предназначенное для отдельного приложения запускаемого на стороне клиента (RTF отчет и т.п.). Кроме того подсистема ввода вывода должна иметь еще одну систему – формирование электронного документа.

Электронный документ – отчет, предназначенный для записи на внешний носитель (отчет в налоговую инспекцию), либо для передачи электронным способом (“Вышлете счет по email”, факс). К электронным документам также нужно отнести специализированные отчеты, предназначенные для дальнейшей автоматической обработкой системой учетной задачи. В этом случае форматом может также выступать UIML, но предназначенный не для обработки клиентом, а для обработки сервером задачи.

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


    Подсистема драйверов базы данных.

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

В состав всех классов драйверов баз данных входит класс транзакций.

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

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

Существуют следующие предопределенные классы: класс таблиц;

  • класс записей таблицы;

  • класс запросов;

  • класс табличных регистров;

  • класс простых регистров;

  • класс истории;


    Класс таблиц.

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

При создании объекта класса создается таблица, в которой существуют неотъемлемые данные: ID; дата-время изменения записи, имя (ссылка) класса объектов, содержащихся в таблице и признак использования записей таблицы при пересчете относительно точки актуальности. А также пользовательские поля, задаваемые параметром в конструкторе при создании класса.

Каждый класс таблицы имеет предопределенные методы: Методы класса

  • создать объект класса;

  • добавить поле в объект класса;

  • удалить поле из объекта класса;

  • создать ключ в объекте класса;

  • удалить ключ в объекте класса;

  • удалить объект класса;

  • получить список объектов класса;

  • получить список полей объекта класса;

  • получить список ключей объекта класса;

  • создать зависимость объекта от другого объекта (зависимые ключи и целостность базы);

  • удалить зависимость;

  • создать историю объекта (история может быть только одна);

  • удалить историю объекта;

  • создать простой регистр объекта;

  • удалить простой регистр объекта;

  • создать таблицу регистров объекта;

  • удалить таблицу регистр объекта;

  • методы управления данными объекта класса:

  • открыть объект класса с правами (чтение, добавление, изменение, удаление);

  • получить ссылку списка объектов типа “запись”, по условию;

  • получить ссылку объекта типа “запись”, по условию;

  • создать (добавить) объект типа “запись”;

  • изменить объект типа “запись”, по условию условию;

  • открыть объект типа “запись” для редактирования;



    Класс записей таблицы.

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

Объект можно открывать в режимах для чтения и для редактирования.

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

У объекта “запись” есть методы:

  • методы управления объекта типа “запись”:

  • получить объект класса.

  • открыть объект класса с правами (чтение, добавление, изменение, удаление);

  • получить ссылку объекта типа “запись”, по условию;

  • создать (добавить) объект типа “запись”;

  • изменить объект типа “запись”;

  • получить ссылку поля объекта класса на зависимый объект;

  • Открыть объект по ссылке(???);

  • получить всю совокупность связанных объектов;

  • создать связанный объект;

  • удалить связанный объект;

  • установить признак “пересчет по точке актуальности”;

  • сбросить признак “пересчет по точке актуальности”;




    класс списка записей таблицы.

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

  • методы управления объекта типа “список записей”:

  • получить объект класса.

  • открыть объект класса с правами (чтение, добавление, изменение, удаление);

  • получить ссылку объекта типа “запись”, по условию;

  • переместить курсор в начало;

  • переместить курсор в конец;

  • переместить курсор на одну позицию вперед;

  • переместить курсор на одну позицию назад;

  • получить всю совокупность связанных объектов списка;

  • получить всю совокупность связанных объектов текущей строки списка;

  • открыть связанный объект поля строки для редактирования;

  • создать связанный объект поля строки;

  • удалить связанный объект поля строки;


    класс “поле записи”


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

  • Методы

  • получить поле объекта запись;

  • изменить поле объекта запись;



    Класс транзакций

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

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

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

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


    Семейство классов “история таблицы”

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

У нас есть возможность добавить поле в таблицу истории, отражающее поле основной таблицы. Оно будет просто копироваться в таблицу истории из основной таблицы при любом изменении.

При изменении или добавлении записи в основной таблице (если время транзакции соответствует точке актуальности), добавляется запись в таблицу истории.

Для работы с таблицей истории у нас есть классы: “класс история записи”, отражающий список изменений выбранной записи и класс, отражающий одно изменение. Через эти классы мы можем добираться до всех операций таблицы. Внимание: при вызове методов через историю, она не должна добавляться а только обновляться. Причем обновляться должны не все поля (допустим при вызове такой операции мы нигде не должны изменять время (????) и значение точки актуальности) . При этом записи в дополнительную таблицу истории не заносятся. Связь истории и таблицы реализуется через триггеры и предопределенные процедуры SQL сервера. Триггеры работают по разному в режимах обычного изменения значений в таблице и в режиме вызова через историю. Пересчет по точке актуальности может производиться только если установлен соответствующий признак в поле. При занесении данных в историю таблицы, поля “точка актуальности” и время операции заполняются соответствующими значениями, установленными методами “начать транзакцию”. Поле “точка актуальности” в сочетании с ID служит для корректного пересчета данных по “точке актуальности”. Следует отметить, что при добавлении операций с измененной “точкой актуальности“ (задним числом) у нас в историю будут добавляться операции с настоящим временем и ненастоящим временем точки актуальности. Таким образом при сортировке таблицы по времени мы получим реальную картину, а при сортировке по точке актуальности в порядке логики базы данных. При занесении в историю всех полей основной таблицы мы имеем возможность выполнять откат любой операции с таблицей на любую глубину.

  • Методы класса “история таблицы”:

  • создать историю таблицы (признак пересчет по точке актуальности устанавливается при создании и наследуется потом всеми полями);

  • добавить отображение поля;

  • получить ссылку на историю таблицы;

  • Методы класса “история записи”:

  • получить список истории записи (в вариантах сортировки: время, точка актуальности или записи, добавленные задним числом);

  • получить список истории записей, начиная с точки актуальности;

  • методы класса “запись истории записи”:

  • получить список ссылок вызывавших объектов в порядке следования (точка актуальности, ID истории);

  • получить список изменений значения поля (в вариантах сортировки: время, обратное время, точка актуальности, обратная точка актуальности, или записи, добавленные задним числом в сортировках по времени, обратном времени и аналогично с точкой актуальности);

  • получить запись для предыдущего значение поля от указанной точки актуальности (найти предыдущую запись истории записи, в которой это поле изменилось и достать оттуда {Если она есть});

  • получить значение поля на точку актуальности (т. е. из истории найти значение поля установленное до точки актуальности);

  • получить дельту поля в порядке следования (для цифровых полей из значения поля предыдущей записи отнять текущее значение);

  • получить “автора” изменения со временем совершения операции, именем класса, его осуществившим и заодно проверить его права;

  • методы класса “список ссылок вызывавших объектов“:

  • создать список ссылок вызывающих объектов ;

  • найти первую запись;

  • найти следующую запись;

  • вызвать метод класса из объекта;


    “точка актуальности”

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

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

Методы изменения базы данных через историю доступны только в классе точки актуальности и работают по принципу “отсюда и до конца” или “отсюда и до сюда”.

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

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

Альтернативой может служить только расширение временного интервала счетчиком событий. Счетчик получается очень хитрый, для того, чтобы у него оставалось как ни можно больше возможностей для вставки операций. Например он может быть строковым: сначала буква a, потом b, ... z; если следующая буква есть, то добавляем букву: aa, ab ... az. Временем в значении “точки актуальности” может служить системное время UNIX. Но следует учесть, что чем меньше будет шаг времени, тем реже будет требоваться исполнение этого сложного алгоритма формирования дополнительного числа (строки). В целях ускорения работы с точкой актуальности все это следует хранить в одном поле.

Класс “точка актуальности” тесно связан с классом “транзакция”.

Класс точка актуальности содержит предопределенную таблицу, в которую заносится ID; значение точки актуальности; ссылка на объект, вызвавший транзакцию; собственно список объектов, по которым выполняется транзакция; время создания и изменения записи.

При выполнении операции удаления транзакции выполняется удаление и записи таблицы точки актуальности.

При одиночном вызове метода транзакции через класс “точка актуальности” происходит только обновление времени.

При групповой операции “пересчитать все”, ничего не делается.

При вызове метода через историю без изменения данных ничего не делается.

Таким образом значения ТА доступны для класса транзакций, а методы транзакций вызываются через ТА.

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


  • Методы класса “точка актуальности”:

  • установить точку актуальности для пересчета на заданное значение;

  • установить точку актуальности на текущее значение времени;

  • переместить точку актуальности на следующее значение;

  • пересчитать все транзакции начиная с точки актуальности до другой точки актуальности;

  • получить текущую транзакцию точки актуальности;

  • пересчитать текущую транзакцию точки актуальности;

  • получить текущее значение (значение ТА и времени);



    Таблица с периодическими реквизитами

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

Соответственно мы имеем и класс записей и прочие классы, присущие обычной таблице.

Основные отличия в работе состоят в том, что мы имеем дополнительные методы, позволяющие получать список изменений записей таблицы при помощи истории, ссылаясь только на запись таблицы. При использовании метода открыть таблицу на дату-время (ТА), мы получаем список записей на эту дату.


  • Методы класса “периодические реквизиты”:

  • открыть таблицу на (ТА);

  • получить запись на (ТА);

  • и т.п. все методы.



2.6.3.9. Семейство классов регистров

Классы регистров

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

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

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

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

Опишем список полей регистра:

поле 1 # для фильтрации

поле 2 # для фильтрации

поле 3 # для фильтрации

поле 4 # для фильтрации

поле 5 # для фильтрации

поле 6 # для фильтрации

сумма числового поля

счетчик количества записей основной таблицы.

текущее значение ТА

следующее значение периода остатка.

Таблица остатков содержит такой же список полей, но дополняется двумя полями:

  • тип записи # запись на начало периода или на конец периода

  • тип отражения #??? пользовательское поле, в котором можно указывать – булево значение. Например, в этом поле можно ставить признак удаления записи.

В поле значения периода остатков в этой таблице задается значение дата-время конца периода, на который сформирован остаток.

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

При переходе через период начальные значения числового значения регистра считаются равными остаткам на начало периода.

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

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

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

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

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

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

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

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



  • Методы таблицы, связанные с классом регистров:

  • получить список регистров таблицы;

  • создать регистр таблицы с периодом;

  • удалить регистр таблицы с регистром;


  • методы класса регистр таблицы:

  • перенести остатки регистра на новый период;

  • получить список полей признаков регистра таблицы;

  • получить список периодов остатков;

  • восстановить значение регистра и остатков (пересчет от начала);



  • методы класса таблица регистра:

  • получить список записей таблицы регистра (с фильтром по признаку полей или без него);

  • получить список записей основной таблицы для регистра (по признаку);

  • получить список остатков регистра на период (по признаку);

  • методы класса запись таблицы регистров:

  • редактировать корректирующую запись остатка на период;


Класс временных регистров.

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

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

Список методов и классов для работы с временными регистрами вцелом повторяет список классов и методов обычных регистров, поэтому не приводится.

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



2.6.3.10. Класс представления таблицы в виде дерева


Класс временных регистров.

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

  • Список методов класса “дерево”:

  • создать дерево;

  • удалить дерево;


  • Список методов класса “записи дерева”:

  • добавить запись уровня;

  • редактировать запись уровня;

  • получить список уровня;

  • получить список вышележащего уровня;

  • получить список нижележащего уровня;

  • переместить веточку;

  • удалить рекурсивно веточку;


Указанные методы изменяют и дополняют наследуемые методы таблицы.

2.6.3.11. Класс сложных (многотабличных) объектов.

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

Данные содержащиеся в реестре сложных объектов:

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

Указанный класс содержит некоторое количество методов, предназначенных для получения внутреннего содержания классов данных и их модификации в процессе исполнения модуля.



2.6.3.12. Класс горизонтального обмена данными

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

Общее правило для использование этих классов таково: если для данного класса определяется метод передачи сообщения, то должен быть определен и метод обработки сигнала получения сообщения!

  • методы горизонтального обмена данными:

  • послать сообщение своим копиям в других процессах;

  • сигнал – получено сообщение от другого процесса;



  • метода авторизации:

  • получить список своих прав в классе;

    Подсистема управления модулями (объектами).

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

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

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

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

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

По этой выборке создается UIML для отображения меню и панели инструментов.

Сформированный UIML отдается клиенту подсистемой ввода вывода. Такая операция производится при создании любого окна.

Клиент, получив UIML сохраняет его у себя и создает из него (или изменяет существовавшие раньше) объекты “меню” и “панель инструментов”. Таким образом объекты “меню” и “панель инструментов” существуют только у клиента. При переключении окон (изменение фокуса окна) клиент выполняет операции изменения этих объектов. Таким образом мы получаем контекстное меню и контекстную панель управления.

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

    Диспетчер форм.

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


    Генератор отчетов.

Генератор отчетов все отчеты формирует в формате xml. После чего они передаются соответствующим фильтрам для создания окончательных выходных форм: pdf, rtf, html. И полученные файлы отдаются клиенту, оснащаясь mime типом.


    Подсистема отладки.

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

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

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

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


    Подсистема формирования графических отчетов.

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

  1. Диаграммы.

  2. Штрих-код.

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


Информационно-справочный ресурс Партнеры сайта: Просто получи клиентов - продвижение сайтов в топ поиска недорого. Отзывы http://sd46.ru . белый каталог статей . Петелька http://petelka.info/foto-o-vjazanii/belyjj-azhurnyjj-kardigan.html - Petelka.info