---

ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ

на программный комплекс «Нормативные документы»

версия 2.0

Харьков 2006

1Общее описание системы

Система является распределенным приложением и состоит из четырех основных частей: базы данных (Oracle), приложения бизнес-логики (Java), приложения веб-интерфейса (Java) и приложения занесения документов (Delphi). Бизнес-логика по требованию интерфейса выполняет запросы к БД и возвращает данные в виде xml-документов в интерфейс, где они используются для формирования веб-страниц. Для возврата данных из бизнес-логики используются классы дополнительного проекта «communication», который включается на этапе компиляции в приложения бизнес-логики и интерфейса.

Приложение занесения документов не зависит от Java-приложений и выполняет запросы к БД напрямую.

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

2Подкаталоги проекта системы

AddDoc – приложение занесения документов. Его разрабатывал Павел Ус.

DataPorting – утилита перегонки данных из БД «Нормативные документы, версия 1» в БД «Нормативные документы, версия 2»

DB – скрипты создания БД и заполнения ее статическими данными.

DocCirc1 – проект «Нормативные документы, версия 1»

Docs – набор рабочих документов, которые создавались в процессе работы над системой. На те из них, которые могут быть полезными, я буду ссылаться в дальнейшем.
Также содержит схему БД (см. п. 3).

HTML – образец html-дизайна

Java – содержит подкаталоги с Java-приложениями:

business - бизнес-логика

interface - веб-интерфейс

communication – пакет классов для обмена данными между бизнес-логикой и

интерфейсом

Libs – java-библиотеки, дополнительных технологий, используемых в java-приложениях (hibernate, middlegen, xdoclet и stxx). Библиотеки лежат здесь с целью наглядности (там есть документация, примеры и исходные коды). В компиляции java-приложений используются только необходимые jar-архивы, скопированные отсюда в подкаталоги java-приложений.

ParamGen – рабочая утилита, можно не обращать внимания.

3База данных

3.1Общие положения

Схема базы данных в формате PowerDesigner 9.5: Docs/DocCirc_II.PDM.

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

Основные таблицы: DOCUMENTS и USERS.

3.2Нетривиальные моменты, которые хотелось бы осветить

3.2.1Исполнение документов

DOCUMENT_EXEC_INFO. Запись этой таблицы содержит инфу об исполнении части документа. Предполагается, что документ может иметь кучу никак не обозначенных частей (абзацев, пунктов - хез), предназначенных для исполнения. Чтобы хоть как-то привязать инфу об исполнении к соответствующей части документа, она содержит текстовое название части DEI_DOC_CHAPTER:varchar. Например DEI_DOC_CHAPTER = ‘Пункт 1.5’.

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

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

3.2.2Ограничение доступа к документам

Предполагается, что документы могут иметь 4 уровня доступа (DOCUMENTS. DOC_ACCESS_LEVEL):

0 - общедоступный

1 - платный - доступный для служебных и оплативших обычных пользователей

2 - служебный - общедоступный только для сужебных пользователей, недоступен для обычных пользователей

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

Установить уровень доступа в «служебный» и «ограниченный» можно только прямым изменением его поля DOC_ACCESS_LEVEL. Уровень «платный» подразумевает, что в таблице PAID_CATEGORIES должна быть запись, связывающая документ с платной позицией (таблица PAID_CATEGORIES). Кроме того, эта запись может ссылаться не только на документ, но и на категорию документов (таблица DOCUMENT_CATEGORIES) и на издателя документов (таблица DOCUMENT_ORGANS), делая все принадлежащие категории или издателю документы платными.

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

1) общедоступно-платный (0,1) – для документов в этом слое доступа приложение выполняет синхронизацию поля DOCUMENTS. DOC_ACCESS_LEVEL в зависимости от включения/исключения документов/категорий/издателей в платные позиции.

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

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

3.2.3Платные сервисы

Платные сервисы – это записи в таблице PAID_SERVICES, связанные с платными позициями (таблица PAID_CATEGORIES). Сервисы статически привязываются к обработке конкретного struts-экшена в бизнес-логике. Привязка прописывается в [Doccirc2-home]/Java/business/ActionMapping.xml.

3.2.4Оплаты

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

3.2.5История статусов документа

Таблица DOCUMENTS содержит поле DOC_STATUS_ID, содержащее id текущего статуса документа (действующий, недействующий, приостановленный). При добавлении в базу документов, изменяющих статус данного, новый статус добавляется в таблицу истории статусов (DOC_STATUS_MODIFYING). Приложение занесения документов синхронизирует DOCUMENTS .DOC_STATUS_ID с историей статусов при добавлении/удалении записей DOC_STATUS_MODIFYING. Вместе с тем, приложение занесения документов позволяет напрямую менять DOCUMENTS .DOC_STATUS_ID, вводя таким образом десинхронизацию между текущим статусом и историей. Это связано с тем, что изменитель статуса может изменять статус на некоторый период времени. Система не отслеживает окончание такого периода. По окончании периода требуется напрямую изменить статус целевого документа.

3.2.6Связи между документами

Связи задаются таблицей DOCUMENT_LINKS. Бывают трех типов:

1) ссылка на документ

2) оригинальная версия документа

3) изменение документа

Связи «ссылка на документ» представляют простое упоминание документа-таргета в тексте документа-линкера.

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

Все редакции должны иметь ссылку типа 2 на оригинал и ссылки типа 1 на все изменители, формировавшие текст этой и предыдущих редакций. Изменители должны иметь ссылки типа 3 на оригинал. Графически схема ссылок в цепочке редакций показана на рис.1.

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