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

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

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

Рисунок 1.8. Веб-интерфейс "Запуск методов работы с входящими пакетами документов"

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

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

Рисунок 1.9 Прототип веб-интерфейса "Редактировать атрибуты маршрута согласования"

После внесения всех данных, пользователь нажимает кнопку «Start»; запускается валидация заполняемых полей и запускается метод запуска маршрута согласования документов.

Следующий прототип веб-интерфейса отображает процесс выбора пакета документов для загрузки в систему. Прототип изображён на рисунке 1.10.

Рисунок 1.10 Прототип веб-интерфейса "Выбрать пакет документов для загрузки"

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

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



Рисунок 1.11. Прототип веб-интерфейса "Выбрать контракт"

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

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

Рисунок 1.12. Прототип веб-интерфейса "Редактировать атрибуты исходящего пакета документов"

После прототипа веб-интерфейса редактирования атрибутов исходящего пакета документов, по порядку, идёт прототип веб-интерфейса редактирования состава исходящего пакета документов. Прототип веб-интерфейса изображён на рисунке 1.13.

Рисунок 1.13 Прототип веб-интерфейса "Редактировать состав исходящего пакета документов"

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

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

Рисунок 1.14. Прототип веб-интерфейса "Редактировать список получателей уведомления"

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

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

2.Разработка модуля регистрации документов

Постановка задач для разработки модуля регистрации документов

Постановка задач в рамках разработки программного модуля для системы проектно-технической документации является ключевым моментом в этапе разработки для платформы «OpenText Content Server 16.2».

Важность данного этапа заключается в специфичности процессов разработки для «OpenText Content Server 16.2». Детализация задач по разработке программного модуля способствует эффективному процессу разработки. Эффективность выражается в сокращении временных издержек на исследование платформы и выбора инструментов разработки.

Задачи, поставленные на данном этапе позволят структурировать процесс анализа возможностей платформы «OpenText Content Server 16.2» и программного обеспечения для дополнительной разработки в рамках разработки программного модуля. Также постановка задач подразумевает чёткое планирование процесса разработки программного модуля, веб-интерфейсов и объектов базы данных.

Исходя из этапа проектирования проводимого исследования, необходимо выделить следующие задачи для завершения этапа разработки программного модуля регистрации документов для СУПТД:

· анализ возможностей и архитектуры платформы «OpenText Content Server 16.2»;

· разработка программного модуля на платформе «OpenText Content Server 16.2»;

· разработка веб-интерфейсов для программного модуля;

· разработка таблиц и хранимых процедур для базы данных.

Анализ возможностей и архитектуры платформы «OpenText Content Server 16.2» позволяет определить связи разработанного проекта программного модуля со спецификой разработки в рамках рассматриваемой платформы. Также анализ возможностей и архитектуры способствует ускорению исследования взаимодействия разрабатываемого программного решения со стандартным функционалом СУПТД.

Для реализации дополнительного функционала следует провести обзор сценарных языков программирования веб-интерфейсов. Сценарные языки программирования позволяют программировать расширенные сценарии взаимодействия веб-интерфейсов с пользователем. Обзор сценарных языков программирование позволяет выбрать оптимальный для СУПТД язык программирования.

Анализ возможностей и архитектуры платформы «OpenText Content Server 16.2»

Краткий анализ архитектуры платформы «OpenText Content Server 16.2» представлен в первой главе на этапе анализа. В рассматриваемом разделе необходимо исследовать архитектуру платформы в большей степени, для выделения нюансов реализации программного модуля.

Платформа «OpenText Content Server 16.2» представляет собой веб-сервис, реализуемый при помощи Livelink(ECM). Enterprise Content Management относится к области создания, управления, персонализации и распространения контента. Livelink-это веб-приложение для хранения, обмена и распространения информации.

Как заявлено ранее «OpenText Content Server 16.2» имеет модульную архитектуру. Для платформы был создан язык разработки OScript основанный на языках семейства C, что делает разработки для платформы нативным процессом ввиду схожести с распространёнными на данный момент языками программирования.

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

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

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

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

Осуществление взаимодействия между клиентской и серверной частью сервиса происходит путём вызова функций и передачи параметров при помощи HTTP GET и POST запросов. Данный механизм позволяет вызывать обработчики запросов из веб-интерфейсов и осуществлять взаимодействие и переключение веб-интерфейсов на клиентском уровне работы системы.

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

В платформе «OpenText Content Server 16.2» реализованы различные механизмы хранения объектов и разграничения доступа к ним. Наиболее используемым механизмом хранения является механизм версионного хранения объектов. Версионное хранение используется в разрабатываемом модуле, позволяя оперировать различными версиями объектов, сохраняя при этом оригинальную версию. Разграничение прав на доступ к объектам предоставляет возможность разграничения функционала, предоставляемого пользователям.

Таким образом, описанные в рамках данного параграфа, классы предоставляют чёткую картину возможностей, предоставляемых разработчику для платформы «OpenText Content Server 16.2».

Разработка программного модуля

Разработки для платформы «OpenText Content Server 16.2» осуществляются в среде разработки «Eclipse Java EE IDE for Web Developers». Для разработки на платформе «OpenText Content Server 16.2» в среду разработки установлен плагин, позволяющий работать с программным кодом веб-сервиса. Интерфейс среды разработки достаточно нативный и позволяет осуществлять процесс разработки на интуитивном уровне.

Для начала разработки в рассматриваемой среде программирования, необходимо создать проект, включающий в себя корневую директорию веб-сервиса «OpenText Content Server 16.2». Осуществление редактирования проекта происходит при отключённом веб-сервисе и его запуске в режиме отладки при помощи среды разработки.

Соответственно, первой задачей, в рамках этапа разработки является создание проекта. Созданный проект назван «My_project_server». В панели «OScript Explorer» представлен созданный проект и его неизменяемые стандартные директории. На панели «Module Explorer» представлена иерархическая структура модулей, входящих в проект. Выше перечисленные объекты среды разработка представлены на рисунке 2.1.



Рисунок 2.1. Среда разработки

Следующим шагом в разработке программного модуля является создание модуля. Создание модуля происходит путём выполнения соответствующей команды в контекстном меню проекта на панели «Module Explorer». В результате, создаётся макет модуля и модульное пространство с заданным пользователем названием и версией.

В соответствии с анализом архитектуры модуля, проведённом в первой главе, необходимо создать объект «The WebModule». Объект веб-модуля наследуется от одноимённого объекта модуля «KERNEL».

Неотъемлемой частью модуля является его конфигурация. Для формирования конфигурации модуля, необходимо унаследовать объект «Configure» от модуля «WebAdmin». В созданном объекте задаются свойства программного модуля, позволяющие взаимодействовать с системой.

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

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

Рисунок 2.2. Запуск установки модуля

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

По умолчанию, иерархия каталогов внутри директории модуля содержит следующие каталоги: каталог для хранения веб-интерфейсов «html», каталог хранения пространства модуля «ospace» и каталог хранения изображений и стилей для веб-интерфейсов «img» - а также файл конфигурации в корне директории модуля. Каталог созданного программного модуля представлен на рисунке.

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

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

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

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

Входные параметры для функции передают значение системного идентификатора каталога или пакета, в котором находятся документы, и битового флага, отвечающего за запуск функции копирования атрибутов в категории документов. После передачи параметров, следует инициализация переменных. Среди типов переменных фигурируют следующие типы: объект («Object»), объектная сессия («Dapisession»), строковый («String»), динамический («Dynamic»), объект («DapiNode»), список («List»), иерархическая переменная («Assoc»), объект языка Java («JavaObject»), целочисленный тип («Integer»), рванный массив («RecArray»), логический («Boolean»).

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



Рисунок 2.4. Программный код валидации

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

Затем происходит проверка наличия сопроводительной ведомости в пакете документов. При наличии сопроводительной ведомости, начинается процесс синтаксического анализа сопроводительной ведомости путём запуска соответствующей функции на языке «Java». Функция синтаксического анализа разработана ранее. Она возвращает данные считанные по шаблону сопроводительной ведомости, указанному в таблице контрактов в базе данных. Запись контракта вычисляется путём выборки с заданным параметром папки загрузки входящих пакетов документов.

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

Рисунок 2.5. Шаблон сопроводительной ведомости

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

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

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

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

Остальные функции раздела «Utils» также разработаны в соответствии с действиями, проводимыми в спроектированном поведении функции валидации входящего пакета документов. Итог разработки функций, запускаемых в контексте валидации входящего пакета документов изображён на рисунке ниже.

Рисунок 2.6. Функции раздела «Utils»

Наиболее важные функции, созданные в объекте «Utils», называются: «CheckMaskAndString», «MapCategory» и «SendEmailAboutVerificationError».

Функция «CheckMaskAndString» занимается проверкой имени документов на соответствие, переданной в качестве параметра, маске. Данный функционал выделен в отдельной функции потому, что его вызов происходит множественное количество раз и программный код теряет наглядность представления.

Метод «MapCategory» предоставляет функционал по присвоению категории передаваемому объекту и за записи в неё атрибутов. Атрибуты также, как и объект системы, передаются в качестве параметров к методу.

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

Неотъемлемой составляющей программного модуля является обработчики запросов. Обработчики запросов построены в соответствии с разработанным проектом модуля.

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

Первый шаг в разработке модуля - наследование объекта «RequestHandlerGroup» стандартного модуля «WebDSPRoot». Затем, созданный объект, активируется путём изменения свойства «fEnabled» на значение «True».

Вторым шагом является наследование объекта «LLRequestHandler». Данный объект позволяет принимать запросы, подаваемые из объектов клиентской части веб-сервиса. Объект «LLRequestHandler» наследуется от объекта «RequestHandler» модуля «WebDSPRoot». Окончательный вид структуры программного модуля регистрации документов представлен на рисунке ниже.

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



Рисунок 2.7. Структура разработанного программного модуля

После присваивания значения «true» для свойства, следует зарегистрировать объект в подсистеме распределения запросов. Это делается путём выполнения скрипта «SetRequestHandlers» объекта «PTDocManager RequestHandlerGroup». Стоит отметить, что для обработчика запросов было задано свойство «fModuleStyleSheetFiles», в котором указаны CSS стили, которые будут использоваться в веб-интерфейсах модуля.

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



Рисунок 2.8. Обработчики событий

Стоит пропустить описание разработки типовых обработчиков запросов, ввиду того, что процесс разработки прошёл без трудностей и прошёл в соответствии с проектом модуля. Однако, следует описать трудности, появившиеся при разработке обработчиков запросов «MakeOutgoingPacket» и «StartReview». Данные обработчики событий выполняют функции создания исходящего пакета документов и запуска маршрута согласования, соответственно.

«MakeOutgoingPacket» запускается после выбора составных документов из инструмента «Dashboard» и нажатия соответствующей кнопки. На вход обработчика поступает запрос, в котором хранятся идентификаторы необходимых документов и контракта.

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

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

Рисунок 2.9. Шаблон формы

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

Данные документов копируются в динамическую переменную и передаются в запускаемый веб-интерфейс.

«StartReview» выполняет функционал запуска маршрута согласования входящих пакетов документов. Основной трудоёмкостью в разработке данного объекта является работа с картами маршрутов согласования.

Перед инициализацией карты маршрута согласования необходимо заполнить атрибуты. Маршруты проектно-технической документации разделяются по критерию количества обработки документов. Для входящих пакетов документов с множественными документами создан маршрут с многозначными атрибутами и шагами их обработки. Это следует учитывать при создании обработчика запросов «StartReview». Атрибуты маршрута согласования множественных документов показаны на рисунке 2.10.

Рисунок 2.10. Атрибуты маршрута согласования

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

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

По завершении разработки всех обработчиков запросов, они регистрируются в подсистеме обработчиков запросов. Также необходимо осуществить сборку модуля путём запуска скрипта «BuildOSpace» в объекте «PTDocManager Globals». В объекте «Globals» хранятся сведения о всех объектах модуля.

Разработка веб-интерфейсов для программного модуля

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

Одним из важнейших критериев разработки веб-интерфейсов для платформы «OpenText Content Server 16.2» является соответствие веб-интерфейсов стилистике платформы и включение элементов веб-сервиса.

Для внедрения функционала платформы в создаваемые веб-интерфейсы, в платформе существует скрипт «web-script». Веб-скрипт позволяет обрабатывать данные передаваемые из методов серверной части. Он выполняется во время генерации веб-страницы на уровне серверной части. Веб-скрипт также позволяет запускать веб-интерфейсы других модулей с различными параметрами. Часть веб-скрипта показана на рисунке 2.11.

Рисунок 2.11. Фрагмент кода веб-интерфейса

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

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

В рамках разработки использовались следующие инструменты: «WebScript», язык гипертекстовой разметки «HTML», сценарный язык программирования «Javascript» с библиотекой «JQuery» и «CSS» стили.

Во время разработки веб-интерфейса использовано множество стандартных блоков платформы. В их числе объекты веб-страницы, называемые «head» и «footer». В стандартном заголовке веб-страницы находятся вкладки ресурсов системы. Также к числу стандартных блоков относятся рамки, в которых находятся селекторы для выбора значений и кнопки.

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

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

Следующий веб-интерфейс, который был разработан - это веб-интерфейс запуска методов работы с входящими пакетами документов. Интерфейс представляет собой веб страницу и используется как объект системы именуемый «Custom View». «Custom View» помогает внедрить дополнительный функционал для различных директорий.

Были разработаны изображения кнопок и взаимодействие кнопок с серверной частью путём выполнения «ajax» запросов. Сценарные действия также, как и в предыдущем интерфейсе, созданы при помощи библиотеки «JQuery». Результат разработки представлен на рисунке ниже.

Рисунок 2.12. Веб-интерфейс работы с входящими пакетами документов

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

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

Для реализации переключения шагов без перезагрузки веб-страниц был выбран элемент гипертекстовой разметки «frame». Рассматриваемый элемент позволяет запускать веб-страницы внутри блока, без изменений в родительской веб-странице.

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

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

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

В связи с особенностями необходимого представления, оно было создано без использования веб-скриптов, только лишь с вызовом стандартного функционала через «Ajax» запросы. В результате получилось разработки представления для формы удалось исключить использование стандартных блоков для выполнения функции. После завершения масштабирования веб-интерфейса, удалось получить веб-интерфейс, изображённый на рисунке 2.13.

Рисунок 2.13. Редактирование формы с атрибутами

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

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

Список генерируется при помощи веб-скрипта, а функционал добавления и удаления документов реализован при помощи библиотеки «JQuery». Добавление документа происходит путём вызова диалогового окна, в котором отображаются директории системы с возможностью выбора документа.

Конечный результат разработки представлен на рисунке 2.14.

Рисунок 2.14. Редактирование состава исходящего пакета документов

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

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

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

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

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

В рамках веб-интерфейса также предусмотрено добавление множества получателей и редактирования данного списка. Конечный вариант веб-интерфейса представлен на рисунке 2.15.

Рисунок 2.15. Редактирование получателей уведомлений

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

Разработка таблиц и хранимых процедур базы данных

Наиважнейшим этапом разработки является разработка объектов базы данных. К системе управления проектно-технической документации подключён сервер базы данных «MS SQL Server 2012». Соответственно, все разработки ведутся на языке программирования «Transact SQL».

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

В таблице присутствует поле «System_Id». Это уникальный идентификатор записей в таблице. Тип данных поля - «Int», позволяет записать 2 147 483 647 записей с неотрицательным значением идентификатором. Столбец является вычисляемым с шагом инкремента равным единице.

Следующее поле является идентификатором маски. Идентификатор имеет тип «Smallint», что позволяет записать в таблицу 32767 масок.

Столбец, который следует далее, назван «SeqNum» и хранит информацию о порядковом номере элемента маски. Типом данных столбца в данном случае, также является «Smallint».

Следующий столбец хранит тип элемента маски. Тип хранения данных «nvarchar(100)» позволяет хранить символьные данные с длинной строки 100 символов

Далее следует столбец «ElemеntIndex», хранящий значение индекса начала элемента в маске. Тип столбца «Int».

Затем необходимо создать столбец определения размерности элемента маски. Столбец называется «Size» и имеет тип данных «SmallInt».

Заключительным столбцом в таблице с масками является столбец хранения значения элемента маски. Столбец имеет тип данных «nvarchar(10)». Стоит отметить, что это единственный столбец, который принимает значение «Null». Значение «Null» доступно для данного столбца, потому что оно не является характеристикой маски. Проект таблицы представлен на рисунке 2.16.

Рисунок 2.16. Таблица с масками

Следующая таблица связывает справочник контрактов со справочником масок. Таблица содержит столбцы идентификаторов контрактов и идентификаторов масок. Также в таблице существует столбец типа маски по наличию ревизии. Наличие ревизии определяется значением столбца «MaskType»: 0 либо 1. В таблице запрещены значения «Null», во избежание возникновения неопределённостей.

Проект таблицы изображён на рисунке 2.17.

Рисунок 2.17. Таблица связи контрактов и масок

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

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

Идентификатор матрицы задаётся столбцом «SystemID». Столбец является вычисляемым с начальным значением равным единице и шагом приращения идентификатора также равном единице. Также столбец является первичным ключом таблицы. Тип данных столбца - «Int».

Параметр «DocumentNumber» задаётся в одноимённом столбце. Столбец имеет тип «nvarchar(64)» с максимальной длиной набора символов в 64 знака. Для столбца разрешено значение «Null» так, как параметр может не использоваться для определения матрицы.

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

Таблица названа «EDMS_Directory_Matrix». «EDMS» - это название системы, слово «Directory» означает справочник, а слово «Matrix» указывает на разновидность содержимого таблицы. Проект таблицы представлен на рисунке 2.18.

Рисунок 2.18. Таблица «EDMS_Directory_Matrix»

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

Таблица называется «EDMS_Directory_MatrixRecipients» и хранит идентификаторы и роли пользователей для каждой матрицы распределения.

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

Следующий столбец называется «MatrixID» и хранит значения идентификаторов матриц распределения. Тип данных столбца «Int».

Пользователи в матрицах распределения делятся на группы, различающиеся по ролям. Для осуществления данного разделения создан столбец «Role». Тип данных столбца «nvarchar(10)», поскольку роли обозначаются символами и значения ролей не превышают десяти символов.

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

Проект таблицы «EDMS_Directory_MatrixRecipients» представлен на рисунке 2.19.

Рисунок 2.19. Таблица матрицей получателей

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

Таблица названа «EDMS_Directory_Contracts_Matrix». В таблице запрещены значения «Null». В таблице содеражтся следующие столбцы предыдущих таблиц: «SystemID», «ContractID» и «MatrixID».

Уникальным столбцом в данной таблице является столбец «Description». Из названия столбца следует, что в нём хранится краткое описание матрицы распределения. Типом данных столбца является «nchar(10)». Тип данных строго ограничивает описание матрицы распределения десятью символами.

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

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

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

Рисунок 2.20. Хранимая процедура, вычисляющая крайние сроки согласования

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

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

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

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

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

Рисунок 2.21. Хранимая процедура выборки получателей уведомлений

В программном модуле регистрации пакетов документов необходимо соблюдать строгость принадлежности директорий загрузки пакетов документов определённым контрактам. Для проверки соответствия директории загрузки пакетов документов разработана хранимая процедура под именем «EDMS_DEDValidateContract».

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

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

Рисунок 2.22. Валидация контракта

Следующая хранимая процедура выполняет функцию проверки ревизии документа.

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

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

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

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

Подготовка системы управления проектно-технической документацией

Разработка дополнительного функционала для платформы «OpenText Content Server 16.2» осуществляется в режиме отладке. Соответственно, данный факт подразумевает сокращение числа ошибок в программном коде. Но, несмотря на это, необходимо провести глубокое тестирования разработанного функционала, чтобы в полной мере удовлетворить требования заказчика.

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

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

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

На вершине создаваемой иерархии объектов в системе, находится актив или «Asset». Тестовый актив называется «Perm EDMS». Настройки доступа упразднены ввиду целей тестирования.

Следующий объект - это проект. Активу может принадлежать множество проектов, а родитель у проекта только один. Тестовый проект называется «Design Docs testing».

Основной каталог, с которым будет осуществляться взаимодействие - это тестовый подпроект с названием «Folder 1».

Внутри подпроекта создаются следующие директории: «Documents To Proceed», «Incoming Packets», «Outgoing Packets» и «Rejected Documents».

«Documents To Proceed» - каталог загрузки пакетов документов в систему. «Incoming Packets» - каталог пакетов документов, отправленных на согласование. «Outgoing Packets» - каталог исходящих пакетов документов. «Rejected Documents» - каталог пакетов документов, не прошедших валидацию.

В итоге, после проведения всех манипуляций, получилась иерархия, представленная на рисунке 3.1.

Рисунок 3.1. Иерархия каталогов тестового подпроекта

Следующий этап - заполнения базы данных.

Для заполнения таблиц базы данных необходимо определить список таблиц, которые необходимы для работы программного модуля. Составление списка является трудоёмким процессом, поэтому решено заполнять таблицы в соответствии с функциями, выполняемыми в программном модуле в исходном порядке.

Первая таблица - «EDMS_Config_Module_PTTransmittalExt». Данная таблица использовалась в предыдущей версии системы для одноимённого модуля. Таблица представляет собой справочник со столбцами «key» и «value». В соответствии с программным кодом модуля, в таблицу необходимо добавить значения: идентификатора категории проектно-технической документации «DEDCategoryID», идентификатора маршрута согласования «DEDWorkflowMapID», идентификатора пакетного маршрута согласования «DEDPackageWorkflowMapID», идентификатора представления директории загрузки «DocToProceedCustomView», идентификатора формы исходящего пакета документов «OutgoingPacketForm» и идентификатора шаблона сопроводительной ведомости исходящего пакета документов «OutgoingTemplateID».

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

В рамках тестирования функционала программного модуля регистрации документов, создан контракт с идентификатором «TEST 1001-0092-000-00002». Для работы с модулем необходимо задать свойства контракта.

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

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

Тестирование модуля регистрации документов

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

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

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

Рисунок 3.2. Тестовая сопроводительная ведомость

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

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

Первый сценарий описан в таблице 3.1.

Таблица 3.1. Проверка на наличие сопроводительной ведомости

Шаги сценария:	Ожидаемые результаты:
1. Сформировать пакет без «xls» ведомости. 2. Загрузить пакет в папку «Incoming Packets» на FTP сервере. 3. Нажать «Download from FTP» в папке в дереве каталогов.	1. Получили соответствующую ошибку 2. Пакет удален из папки «Incoming Packets» 3. Пакет присутствует в дереве в папке «Rejected Packets»

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

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

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

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

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

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

Таблица 3.2. Проверка состава пакета документов

Шаги сценария:	Ожидаемые результаты:
1. Сформировать пакет с документами, не соответствующими ведомости. 2. Загрузить пакет в соответствующую папку «Incoming Packets» на «FTP» сервере. 3. Нажать «Download from FTP» в соответствующей папке в дереве каталогов.	1. Получить соответствующую ошибку. 2. Пакет удален из папки «Incoming Packets». 3. Пакет присутствует в дереве в папке «Rejected».

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

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

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

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

Таблица 3.3. Проверка документов в пакете на соответствие названий маскам

Шаги сценария:	Ожидаемые результаты:
1. Сформировать пакет с документами, не соответствующими маске наименования. 2. Загрузить пакет в соответствующую папку «Incoming Packets» на «FTP». 3. Нажать «Download from FTP» в соответствующей папке в дереве каталогов.	1. Получили соответствующую ошибку. 2. Пакет удален из папки «Incoming Packets». 3. Пакет присутствует в дереве в папке «Rejected».

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

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

Таблица 3.4. Проверка статуса рассмотрения документа

Шаги сценария:	Ожидаемые результаты:
1. Провести полный жизненный цикл с корректным пакетом.

Страница:

•  1 
•  2 
•  3 

дипломная работа "Разработка программного модуля регистрации документов" скачать

Подобные документы

• Разработка модуля автоматизированного учета контрактов услуг для предприятия I.S."Radiocomunicatii"

  Новые направления в развитии информационных систем. Концепция ERP, система universal accounting. Разработка первичных документов регистрации контрактов. Интерфейс документов начисления доходов от предоставленных услуг. Общий вид программного кода.
  
  магистерская работа [3,0 M], добавлен 12.11.2013
  

• Разработка и отладка модуля программы 1С: "Поступление и выбытие удобрений"

  Проектирование модуля программы 1С: "Поступление и выбытие удобрений", позволяющего вносить данные о клиентах, складах, контролировать поставки удобрений. Анализ предметной области и построение функциональной модели программы, ее отладка и тестирование.
  
  курсовая работа [1,6 M], добавлен 24.02.2015
  

• Разработка программного модуля

  Структурная диаграмма программного модуля. Разработка схемы программного модуля и пользовательского интерфейса. Реализация программного модуля: код программы; описание использованных операторов и функций. Вид пользовательской формы с заполненной матрицей.
  
  курсовая работа [215,3 K], добавлен 01.09.2010
  

• Разработка программного продукта, автоматизирующего бизнес-процессы бухгалтера-учетчика финансово-расчетных операций

  Анализ требований к программному продукту. Требования к информационной и программной совместимости. Проектирование архитектуры программного продукта. Виды программ и программных документов. Общие сведения о С++. Технология разработки программного модуля.
  
  дипломная работа [1,2 M], добавлен 05.08.2011
  

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

  Разработка структурной диаграммы программного модуля. Представление схемы для основных расчетов выбранного приложения для создания прямоугольной матрицы. Особенности создания пользовательского интерфейса. Тестирование и отладка спроектированного модуля.
  
  курсовая работа [648,4 K], добавлен 27.05.2015
  

• Система регистрации и авторизации пользователей на сайте

  Разработка средствами языка PHP и Фреймворка Yii системы регистрации и аутентификации пользователей на сайте. Проектирование приложения с помощью языка UML, построение диаграммы прецедентов. База данных приложения. Страница регистрации пользователей.
  
  отчет по практике [1,1 M], добавлен 15.09.2014
  

• Разработка приложения "Передачи данных по сети"

  Проектирование программного модуля: сбор исходных материалов; описание входных и выходных данных; выбор программного обеспечения. Описание типов данных и реализация интерфейса программы. Тестирование программного модуля и разработка справочной системы.
  
  курсовая работа [81,7 K], добавлен 18.08.2014
  

• Разработка программного модуля для интеграции данных между системами 1С:Предприятие 8.2 и модулем "Казначейство" КИС ОАО "ММК"

  Постановка задачи для модуля 1С. Бухгалтерия 3.0. Анализ существующих разработок в области интегрирования данных. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Программное и технологическое обеспечение данного модуля.
  
  курсовая работа [1,5 M], добавлен 10.06.2013
  

• Разработка программного модуля на основе понятийно-тезисной модели

  Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
  
  дипломная работа [101,2 K], добавлен 17.06.2011
  

• Автматизация регистрации документов

  Регистрация документов как один из видов документационного обеспечения деятельности организации. Формы автоматизации регистрации документов. Функции систем автоматизации делопроизводства и документооборота.
  
  реферат [23,8 K], добавлен 21.03.2006
  

Другие документы, подобные "Разработка программного модуля регистрации документов"

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