доработка программного модуля в соответствии с результатами тестирования.
Для разработки модуля регистрации документов для СУПТД, планируется пройти следующие этапы разработки, описываемые в главах.
В первой главе существует необходимость анализа предметной области и разработка проекта программного модуля, что делается для разработки концептуального и материального видения модуля регистрации документов.
Во второй главе планируется провести разработку модуля регистрации документов при помощи стандартных средств разработки платформы «OpenText Content Server 16.2».
В заключительной главе необходимо провести тестирование и доработку разработанного программного модуля. Результатом данного этапа станут тестовые сценарии, на основе которых, можно будет протестировать программный модуль, а также доработанные версии программного модуля.
Выпускная квалификационная работа направлена на оптимизацию работы СУПТД и пользователей, работающих с ней, посредством использования современных технологий проектирования и разработки.
1. Проектирование модуля регистрации документов
.1 Анализ предметной области и спецификация требований
Анализ предметной области
Система управления проектно-технической документацией используется для работы с электронными документами различных организаций. Проектно-техническая документация - это документация, созданная в рамках проекта по выполнению технических работ. Электронными документами для СУПТД является документированная информация, представленная в электронном виде.
СУПТД построена на платформе «OpenText Content Server 16.2». Данная платформа предоставляет функционал, позволяющий заменить потоки бумажных документов, на упорядоченные и формализованные потоки электронных документов. Формализованный поток электронных документов позволяет осуществлять контроль движения и обработки электронных документов. Формализация потоков электронной документации на платформе «OpenText Content Server 16.2», осуществляется при помощи маршрутов движения документов.
В системе управления проектно-технической документации создано обобщённое иерархическое строение проектов. Основные уровни иерархии, рассматриваемые в рамках курсовой работы - это уровни: проект и контракт. Проектом, в данной системе, является кооперативная форма деятельности, представленная в виде потоков документов. Понятие контракта включает в себя хранение ключевых для работы в СУПТД свойств договоров с контрагентами организации.
Для установления связи документов с сущностями иерархии проекта, в рассматриваемой системе, необходимо присвоить документам соответствующие атрибуты. Атрибуты документов описываются, настраиваются и собираются в группы, именуемые категориями.
Поскольку заполнение категорий устанавливает связь между документом и сущностями системы, данный процесс называется регистрацией документа в системе и позволяет проводить с ним дальнейшие манипуляции в рамках электронного документооборота в организации.
Процесс регистрации документов, в данном случае, происходит вручную и занимает время, которое необходимо сократить путём автоматизации. Основным инструментом регистрации документов в системе будет являться модуль регистрации документов.
Предполагается, что модуль регистрации документов позволит сократить временные затраты на регистрацию документов, а также снизить время проверки документов и сопроводительных ведомостей.
Помимо регистрации входящих документов, планируется спроектировать процесс регистрации исходящих документов. Резюмируя выше описанное, следует вычленить следующий функционал проектируемого программного модуля и веб-интерфейсов:
·автоматическую валидацию входящих и исходящих пакетов документов;
·автоматическую регистрацию входящих и исходящих пакетов документов в системе;
·автоматическое оповещение ответственных лиц;
·возможность редактирования пакетов документов перед процессом регистрации и во время процесса регистрации;
·запуск маршрутов согласования документов;
·автоматическую загрузку и выгрузку пакетов документов на сервер.
Автоматическая валидация входящих и исходящих пакетов документов необходима для проверки пакетов документов перед их регистрацией в системе управления проектно-технической документации. Данная функция позволит избежать регистрации документов с некорректными данными и избежать ошибок в последующей работе маршрутов документов.
Автоматическое оповещение ответственных лиц даст возможность для шаблонного уведомления лиц, ответственных для работы с каждым конкретным пакетом документов. Шаблонное уведомление позволяет в формализованном виде предоставить получателям всю необходимую информацию, исключая возможность потери документа в множестве серверов и инстанций рассматриваемой системы.
Поскольку маршруты согласования документов имеют те же атрибуты, что и пакеты документов, автоматизация их запуска позволяет упростить данную процедуру и устранить возможные ошибки до запуска маршрута.
1.1.1Автоматизация процесса регистрации документов
Актуальность автоматизации процесса регистрации пакетов документов в СУПТД обусловлена сокращением временных издержек на регистрацию и валидацию документов, и минимизацией человеческого фактора. Поскольку «OpenText Content Server 16.2» - это корпоративная система электронного документооборота, программные решения, выполняемые для заказчиков закрыты для свободного доступа. Исходя из политики конфиденциальности при работе с заказчиками, возможные решения рассматриваемой задачи могут существовать, но их невозможно найти в открытом доступе.
Автоматизация процесса регистрации пакетов документов в СУПТД возможна при использовании сопроводительных ведомостей в виде таблиц MS Excel. Шаблоны сопроводительных ведомостей загружаются в систему и могут быть определены для каждого контракта. В соответствии с шаблонами, подрядчик должен заполнять сопроводительные ведомости, которые будут хранить атрибуты каждого документа из пакета.
Одним из ключевых процессов регистрации является валидация документов. Для реализации автоматизации процесса валидации необходимо выбрать метод валидации. Валидация атрибутов документов выполняется при помощи поиска соответствующих значений в базе данных. Валидация названия документов не столь однозначна. Так, как каждый документ необходимо нумеровать и привязывать к сущностям проектов, а сущностей в системе может быть большое количество, решено реализовать валидацию названия документов при помощи масок.
Единственным способом хранения масок является, хранение в таблице в базе данных. Данную таблицу стоит связать с таблицей контрактов, для определения соответствия каждой маски с определённым подрядчиком.
Присвоение категорий документам с заполнением атрибутов, можно осуществить автоматически, при помощи загрузки данных из сопроводительной ведомости и выбора подходящей категории и базы данных. Для данной цели необходимо реализовать скрипт, который будет запускать обработчик таблиц MS Excel, доставать из них данные и записывать, непосредственно, в присваемые категории.
Стоит упомянуть, что у каждого заказчика могут быть разные представления об иерархии проектов и разрабатываемое программное решение является демонстрационным, но может быть доработанным в соответствии с пожеланиями заказчиков.
i.Спецификация функциональных требований
Для спецификации функциональных требований и формализации анализа возможностей проектируемого модуля регистрации документов решено использовать язык моделирования «UML». Для начала, перечисленные выше, функциональные требования необходимо описать в виде сценариев прецедентов (вариантов использования).
В данном параграфе необходимо рассмотреть функциональные требования, отвечающие за загрузку и регистрацию пакетов документов.
В таблице 1.1 формализован процесс загрузки пакетов документов в систему управления проектно-технической документации. Для запуска данного прецедента, пользователь должен быть авторизован, а директория загрузки документов в систему должна быть привязана к контракту. В базе данных в сущность контракта необходимо занести путь для загрузки документов с сервера. Данный способ загрузки документов был выбран из-за простоты разработки и настройки с возможностью дальнейшей модернизации.
Таблица 1.1. Прецедент "Загрузить пакет документов"
Краткое описание· Прецедент дает возможность пользователю загрузить документ в систему.Актеры· ПользовательПредусловия· Пользователь авторизован · Подрядчик загрузил пакеты документов на сервер · Путь для загрузки документов задан в базе данныхОсновной поток· Пользователь заходит в папку загрузки документов в системе. · Пользователь нажимает на кнопку загрузки. · Пользователь выбирает пакет документов и нажимает кнопку «Загрузить»Альтернативные потоки· На сервере, в заданной директории, нет пакетов с документами, доступными для загрузки. · Директория загрузки документов не настроена.Постусловия· Если прецедент прошёл успешно, то документ загружается в систему. · Инициируется процесс валидации и регистрации.
После нажатия кнопки загрузки, вызывается метод получения списка доступных для загрузки документов. На вход методу передаётся идентификатор папки загрузки. С помощью идентификатора папки загрузки в методе генерируется запрос в базу данных для получения пути к директории загрузки на сервере. Получив путь к директории с документами на сервере, все вложенные папки записываются в список и посылаются в клиентскую часть для ознакомления пользователем.
Выбрав необходимый пакет документов, пользователь запускает метод загрузки пакета документов, который загружает директорию с документами и инициирует запуск процесса валидации и регистрации.
Если путь для загрузки документов с сервера указан неправильно, то список доступных пакетов документов возвращается пустым.
Следующий сценарий прецедента описан в таблице 1.2 и инициируется прецедентом загрузки пакетов документов. Сценарий прецедента описывает проектируемое поведение процесса регистрации документа в системе. Рассматриваемый прецедент включает в себя прецедент валидации пакета документов и регистрирует документ в системе в зависимости от результата валидации. Так, как прецедент регистрации пакетов документов включается в вариант использования «Загрузка пакетов документов», пользователь будет тем же, кто и запустил процесс загрузки документов.
Таблица 1.2. Прецедент "Зарегистрировать входящий пакет документов"
Краткое описание· Прецедент дает возможность пользователю зарегистрировать пакет документов и пройти валидацию.Актеры· ПользовательПредусловия· Пользователь выбрал пакет для загрузки. · Пакет документов загружен в систему. · Пакету документов присвоен уникальный идентификатор в системе. · В пакете документов содержится сопроводительная ведомость.Основной поток· Вызывается метод регистрации. · Вызывается функция валидации пакета документов. · Документам присваивается, заданная в базе данных, категория, соответствующая типу документов. · Категориям присваиваются атрибуты из сопроводительной ведомости. · Пользователя перенаправляют на страницу с загруженными документами.Альтернативные потоки· Пакет документов не прошёл валидацию.Постусловия· Если прецедент прошёл успешно, то пакет документов перемещается в директорию загрузки, иначе пакет документов перемещается в директорию отвергнутых документов.
После загрузки пакета документов, запускается процесс валидации. Прецедент «Пройти валидацию» описан в таблице 1.3. В процессе валидации должна происходить выгрузка данных из сопроводительной ведомости и сравниваться с документами в пакете и сущностями в системной базе данных. Если валидация не выявила ошибок в пакете документов, то начинается процесс регистрации, а именно присвоение соответствующей типу документов категории и её заполнение.
В том случае, если валидация выявила ошибки в пакете документов, то пользователю выводится сообщение о соответствующей ошибке, а пакет перемещается в папку отклонённых документов, для последующего исправления ошибок в пакете.
Таблица 1.3. Пройти валидацию
Краткое описание· Прецедент дает возможность пройти валидацию пакета документов.Актеры· ПользовательПредусловия· Пакету документов присвоен уникальный идентификатор в системе. · В пакете документов содержится сопроводительная ведомость.Основной поток· Проверяется соответствие документов, записанных в сопроводительной ведомости, документам, находящимся в пакете. · Проверяется информация о проекте, с которым необходимо связать пакет документовАльтернативные потоки· Пакет документов не прошёл валидацию.Постусловия· Если прецедент прошёл успешно, то метод валидации не возвращает ошибку.
Далее следует рассмотреть прецеденты, связанные с процессом запуска маршрута согласования документов.
В таблице 1.4 описывается предполагаемый сценарий варианта использования, отображающего процесс запуска маршрута согласования документов. Рассматриваемый прецедент будет выполняться корректно, только, если пакет с документами зарегистрирован в системе.
Для запуска прецедента, пользователь должен будет выбрать при помощи селектора, необходимый пакет документов и нажать на кнопку запуска маршрута согласования. После этого, отправляется запрос на сервер и запускается метод генерирования веб-страницы. Затем, сгенерированная веб-страница отображается пользователю, который выбирает сроки рассмотрения документов и пользователей, на роли согласующих. Дальнейший процесс описан в таблице ниже.
Рассматриваемый прецедент необходим для автоматизации запуска маршрута согласования пакетов документов. Автоматизация запуска маршрута согласования направлена упростить рассматриваемый процесс, что ускорит время запуска и уменьшит количество возможных ошибок.
Сценарий прецедента, в данном случае, расширяется прецедентами «Получить пользователей для рассмотрения пакета документов» и «Установить сроки рассмотрения», описанными в таблицах 1.5 и 1.6 соответственно.
Таблица 1.4. Прецедент "Запустить процесс рассмотрения документов"
Краткое описание· Прецедент дает возможность пользователю запустить маршрут согласования документов.Актеры· ПользовательПредусловия· Пакет с документами зарегистрирован в системе. · Пакет с документами находится в директории входящих документов.Основной поток· Пользователь открывает веб-страницу с директорией входящих пакетов документов. · Пользователь отмечает, через инструмент «checkbox», необходимый ему пакет документов. · Пользователь нажимает на кнопку запуска маршрута согласования. · Запускается валидация. · Валидация возвращает результаты проверки. · Пакет документов перемещается в директорию с рассматриваемыми пакетами документов. · Запускается метод генерирования веб-страницы. · В методе запрашиваются и обрабатываются данные из базы данных. · Происходит генерация веб-страницы. · Веб-страница показывается пользователю. · Пользователь нажимает на кнопку запуска маршрута. · Запускается метод запуска маршрута. · В соответствии с количеством и типом документов выбирается соответствующая карта маршрута согласования. · Инициируется новый экземпляр процесса согласования документов. · Экземпляру присваиваются атрибуты документов, а во вложения копируются экземпляры документов. · Процесс согласования запускается.Альтернативные потоки· Пакет документов не прошёл валидацию. · Присутствуют ошибки в значениях атрибутов · За контрактом не закреплены ответственные лица.Постусловия· Если прецедент прошёл успешно, то пакет документов перемещается в директорию рассматриваемых документов. · Процесс согласования запускается.
Для установления пользователей, ответственных за рассмотрение документов, планируется создать таблицы для хранения идентификаторов пользователей, ролей пользователей и связь с определённым контрактом. Информация из этих таблиц будет изыматься при помощи метода, построенного на основе варианта использования, представленного ниже.
Прецедент необходим для автоматической загрузки пользователей из базы данных. Список загруженных идентификаторов пользователей будет соответствовать списку ответственных лиц согласно контракту. Данный список будет использован для выбора пользователем ответственных за согласование лиц. Решено сконфигурировать рассматриваемый прецедент именно таким образом, для того, чтобы ограничить список, доступных для выбора, пользователей, ведь в системе могут быть зарегистрированы более ста пользователей, и не все могут иметь права на запуск маршрутов согласования.
Таблица 1.5. Прецедент «Получить пользователей для рассмотрения пакета документов»
Краткое описание· Прецедент дает возможность получить список согласующих.Предусловия· Запущен прецедент запуска маршрута согласования. · Согласующие пользователи связаны с контрактом через идентификатор.Основной поток· Функция запускается. · Параметры передаются в запрос к базе данных, запускающий хранимую процедуру. · Хранимая процедура возвращает записи из базы данных, в соответствии с переданными параметрами. · Записи конвертируются в формат списка либо числа. · Создаётся рваный массив из имени пользователя и идентификатора. · Массив передаётся на выход.Альтернативные потоки· Входные параметры указаны не правильно, функция возвращает пустой список.Постусловия· Если прецедент прошёл успешно, то функция возвращает список пользователей либо одного пользователя, в зависимости от роли, передаваемой на входе.
Сценарий прецедента «Установить сроки рассмотрения» прост так, как в базе данных уже имеется хранимая процедура, генерируемая крайние сроки рассмотрения относительно контракта, статуса рассмотрения и ревизии документов.
Исходя из выше сказанного, можно сказать, что задача, решаемая в прецеденте, это задача отображения и редактирования сроков рассмотрения на веб-странице запуска маршрута согласования. Это необходимо для предоставления возможности редактирования сроков рассмотрения документов.
Таблица 1.6. Прецедент "Установить сроки рассмотрения"
Краткое описание· Прецедент дает возможность пользователю установить сроки рассмотрения документов.Актеры· ПользовательПредусловия· Атрибуты документов пакета записаны в массив данных. · Для каждой роли загружены сроки рассмотрения, вычисленные в хранимой процедуре. · Веб-страница запуска маршрута согласования начала генерироваться.Основной поток· На веб-странице загружаются системные скрипты. · Происходит генерация элементов разметки, в соответствии с переданным массивом атрибутов документов. · Для каждого поля ввода сроков рассмотрения прописывается вызов функции календаря.Постусловия· Если прецедент прошёл успешно, то на веб-странице запуска маршрута согласования отображаются поля для редактирования сроков рассмотрения документов с, заданными по умолчанию, датами.
Следующая группа прецедентов отвечает за работу с исходящими документами. Основной вариант использования отвечает за регистрацию исходящих пакетов документов. Сценарий рассматриваемого варианта использования представлен в таблице 1.7. Данный прецедент включает в себя пять подчинённых прецедентов.
Создание прецедента, описывающего проектируемый сценарий процесса регистрации исходящих пакетов документов, позволяет формализовать данный процесс и сократить временные издержки и число возможных ошибок.
Сценарий прецедента описан в таблице 1.7. Планируется, что прецедент будет связывать, включенные в него варианты использования. Подчинённые варианты использования будут вызываться последовательно, а прецеденты редактирования состава пакета документов, атрибутов исходящего пакета документов и задания получателей уведомления.
Таблица 1.7. Прецедент "Зарегистрировать исходящий пакет документов"
Краткое описание· Прецедент дает возможность пользователю зарегистрировать исходящий пакет документов.Актеры· ПользовательПредусловия· Произведён поиск через инструмент «Dashboard».Основной поток· Пользователь отмечает, при помощи селекторов, необходимые ему документы. · Пользователь нажимает на кнопку создания исходящего пакета. · Система загружает список контрактов. · Система отображает список контрактов. · Пользователь выбирает контракт. · Запускается прецедент «Редактировать атрибуты исходящего пакета документов». · Запускается прецедент «Редактировать состав пакета документов». · Запускается прецедент «Указать получателей уведомлений». · Запускается прецедент «Отправить пакет документов подрядчику».Постусловия· Если прецедент прошёл успешно, то исходящий пакет документов считается зарегистрированным, а получатели получат уведомления.
Первый вариант использования, который будет запускаться в рамках регистрации исходящего пакета документов называется «Получить список контрактов». Метод получения списка контрактов уже существует, поэтому в сценарии прецедента описан только предполагаемый процесс выбора контракта и запуска следующего варианта использования.
Сценарий рассматриваемого варианта использования описан в таблице 1.8. Целесообразность описанного прецедента выражается в том, что существуют индивидуальные для каждого контракта атрибуты, задействованные в процессе регистрации исходящего пакета документов.
Таблица 1.8. Прецедент "Получить список контрактов"
Краткое описание· Прецедент дает возможность получить список контрактов.Актеры· ПользовательПредусловия· Запущен прецедент регистрации исходящего пакета документов.Основной поток· Запускается функция «getallcontractnumbers». · Функция вернула список контрактов. · Список контрактов выводится на дисплей. · Пользователь выбирает идентификатор контракта из выпадающего списка.Альтернативные потоки· В базе данных не существует ни одного контракта. ·