Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка программного модуля регистрации документов

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

Проектирование модуля регистрации документов. Анализ предметной области, спецификация требований. Построение диаграммы прецедентов Анализ архитектуры модуля в "OpenText Content Server 16.2". Разработка программы регистрации документов, ее тестирование.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 25.08.2017
Размер файла 1,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Размещено на http://www.allbest.ru/

Введение

программа документ регистрация

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

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

Анализ практического опыта проведения ИТ-проектов по внедрению СЭДО выявил необходимость доработки системы под нужды заказчиков, в частности, заказчики требуют автоматизации процесса проверки документов на соответствие стандартам, настраиваемых в системе, и присваивания дополнительных атрибутов к документам для оптимизации работы с ними. Это обуславливает целесообразность разработки модуля регистрации документов.

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

В качестве объекта исследования изучаемой работы выступает система управления проектно-технической документации на платформе «Open Text Content Server 16.2».

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

Целью работы является - программный модуль регистрации документов для системы управления проектно-технической документации на платформе «Open Text Content Server 16.2». Для достижения цели работы необходимо решить задачи:

· анализ предметной области;

· анализ архитектуры модуля в «Open Text Content Server 16.2»;

· построение диаграммы прецедентов;

· построение диаграмм активностей;

· построение диаграмм последовательностей;

· описание этапов проектирования;

· генерирование и оптимизация схемы классов;

· проектирование веб-страниц запуска маршрута согласования и регистрации исходящих пакетов документов

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

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

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

· тестирование разработанного модуля;

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

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

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

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

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

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

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

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».

· Функция вернула список контрактов.

· Список контрактов выводится на дисплей.

· Пользователь выбирает идентификатор контракта из выпадающего списка.

Альтернативные потоки

· В базе данных не существует ни одного контракта.

· Пользователь нажал кнопку отмены.

Постусловия

· Если прецедент прошёл успешно, то запускается прецедент «Редактировать атрибуты исходящего пакета документов».

Далее по порядку вызова прецедентов запускается вариант использования с названием «Редактировать атрибуты исходящего пакета документов». Сценарий рассматриваемого прецедента описан в таблице 1.9.

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

Таблица 1.9. Прецедент "Редактировать атрибуты исходящего пакета документов"

Краткое описание

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

Актеры

· Пользователь

Предусловия

· Запущен прецедент регистрации исходящего пакета документов.

· Выбран контракт для работы.

Основной поток

· Запускается метод подготовки данных для отображения на веб-странице.

· Осуществляется поиск директории с исходящими пакетами контракта.

· Создаётся новая директория внутри каталога с исходящими пакетами контракта.

· В созданную директорию копируется форма исходящего пакета документов.

· В форму записываются атрибуты первого из выбранных пакетов документов.

· Данные в форме сохраняются.

· Документы из выбранных пакетов документов копируются в созданную директорию.

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

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

Альтернативные потоки

· В базе данных не существует записи об идентификаторе формы исходящих пакетов документов.

· Пользователь нажал кнопку отмены.

· Повторный запуск прецедента.

Постусловия

· Если прецедент прошёл успешно, то запускается прецедент «Редактировать состав пакета документов».

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

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

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

Таблица 1.10. Прецедент "Редактировать состав исходящего пакета документов"

Краткое описание

· Прецедент дает возможность редактировать состав исходящего пакета документов.

Актеры

· Пользователь

Предусловия

· Запущен прецедент регистрации исходящего пакета документов.

· Выбран контракт для работы.

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

· В созданной директории присутствует заполненная форма.

Основной поток

· Запуск метода.

· Считывание атрибутов из категорий выбранных исходящих пакетов документов.

· Считывание атрибутов из формы.

· Запрос в базу данных на идентификатор шаблона сопроводительной ведомости.

· Создание сопроводительной ведомости из шаблона, в формате таблицы.

· Заполнение сопроводительной ведомости согласно считанным ранее атрибутам.

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

· Переименование ведомости и директории в уникальный идентификатор, созданный в предыдущем прецеденте.

· Создание списка документов.

· Генерирование списка документов на веб-странице.

· Отображение кнопки добавления документа.

Альтернативные потоки

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

· Пользователь нажал кнопку отмены.

· Повторный запуск прецедента.

Постусловия

· Если прецедент прошёл успешно, то запускается прецедент «Указать получателей уведомлений».

· Создана и заполнена сопроводительная ведомость.

· Конечная директория переименована в соответствии с идентификатором исходящего пакета документов.

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

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

Таблица 1.11. Прецедент "Указать получателей уведомлений"

Краткое описание

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

Актеры

· Пользователь

Предусловия

· Запущен прецедент регистрации исходящего пакета документов.

· Выбран контракт для работы.

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

· В созданной директории присутствует заполненная форма.

Основной поток

· Запуск метода.

· Формирование списка документов.

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

· Хранимая процедура возвращает записи из базы данных, в соответствии с переданными параметрами.

· Записи конвертируются в формат списка либо числа.

· Создаётся рваный массив из имени пользователя и идентификатора.

· Массив передаётся на выход.

· Генерирование веб-страницы.

Альтернативные потоки

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

Постусловия

· Если прецедент прошёл успешно, то отображается веб-страница со списком документов в исходящем пакете документов и редактируемом списком получателей.

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

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

Таблица 1.12. Прецедент "Отправить пакет документов подрядчику"

Краткое описание

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

Актеры

· Пользователь

Предусловия

· Запущен прецедент регистрации исходящего пакета документов.

· Выбраны документы для отсылки.

· Шаблон уведомления регистрации исходящего пакета документов существует.

Основной поток

· Запуск метода.

· Считывание данных из запроса.

· Определение списка необходимых документов.

· Запрос пути для выгрузки пакета документов.

· Создание директории для выгрузки.

· Выгрузка пакета документов.

· Запрос на идентификатор шаблона.

· Заполнение шаблона уведомления.

· Определение списка получателей.

· Запись сообщений в таблицу агента оповещений.

Альтернативные потоки

· Шаблон не существует.

· Путь выгрузки документов не прописан в записи рассматриваемого контракта.

Постусловия

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

· Браузер открывает страницу поиска документов.

Построение и описание диаграммы прецедентов

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

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

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

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

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

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

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

ii. Анализ архитектуры модуля в «OpenText Content Server 16.2»

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

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

Основным элементом модуля в рассматриваемой платформе является «OSpace». Этот элемент обязателен для функционирования модуля так, как в нём хранятся объекты, методы и свойства, которые составляют функционал модуля.

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

Для установки и конфигурирования модуля вне процесса основной установки системы, существует объект «Configure». Объект наследуется от соответствующего объекта стандартного модуля «WebDspRoot».

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

И последний, неотъемлемый объект любого модуля - это «ini» файл конфигурации. В нём задаются пути установки, зависимости от других модулей и свойства модуля.

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

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

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

Создание диаграмм активности

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

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

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

Первая диаграмма активностей - это диаграмма загрузки пакетов документов. В рамках активности рассматриваются прецедент «Загрузить пакет документов. Диаграмма представлена на рисунке ниже.

Рисунок 1.1 Диаграмма активности "Загрузить пакет документов"

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

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

Далее следует описать диаграмму активности для запуска процесса рассмотрения документов. Диаграмма представлена на рисунке B.1.

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

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

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

На схеме показано взаимодействие между действиями активности. Рассматриваемая диаграмма активности отображает основные этапы работы процесса регистрации исходящих пакетов документов. Активность отображает три основных шага:

· Запуск редактирования атрибутов пакета документов.

· Запуск редактирования состава пакета документов.

· Запуск редактирования списка получателей уведомления о запуске маршрута согласования.

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

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

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

Рисунок 1.2. Диаграмма активности "Редактировать атрибуты исходящего пакета документов"

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

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

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

Рисунок 1.3. Диаграмма активности "Редактировать исходящий пакет документов"

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

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

По завершении активности, пользователь нажимает на кнопку отправки и запускает процесс отправки уведомлений и копирования пакета документов на сервер подрядчика. Диаграмма представлена на рисунке 1.4.

Рисунок 1.4. Диаграмма активности "Редактировать список получателей уведомлений"

Чтобы уменьшить громоздкость описания всех диаграмм активностей, типовые диаграммы стоит убрать в приложение к работе. Остальные диаграммы активности находятся в приложении B.

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

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

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

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

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

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

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

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

Далее рассмотрим процесс запуска маршрута согласования. Диаграмма данного процесса представлена на рисунке C.2.

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

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

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

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

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

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

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

Далее следует описать процесс редактирования атрибутов исходящего пакета документов. Схема последовательности представлена на рисунке C.4.

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

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

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

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

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

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

Рисунок 1.5. Диаграмма последовательности "Редактировать список получателей уведомлений"

Для дальнейшего описания проделанной работы остальные диаграммы последовательности не столь важны. С ними можно ознакомиться в приложении C.

Создание диаграммы классов

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

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

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

Схема классов представлена на рисунке 1.6.

Рисунок 1.6 Диаграмма классов

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

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

Для достижения задачи были выполнены следующие этапы:

1. созданы диаграммы активностей для прецедентов;

2. созданы диаграммы последовательностей по диаграммам активностей;

3. диаграммы последовательностей объединены в общую диаграмму;

4. построена схема классов.

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

1..2 Проектирование веб-интерфейсов и таблиц базы данных

1.2.1 Проектирование таблиц для работы с модулем

Для работы любого веб-модуля на платформе «OpenText Content Server 16.2» необходима база данных. В ней хранятся данные обо всех сущностях системы.

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

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

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

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

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

3. в базе данных должны содержаться таблицы, хранящие и связывающие с контрактами маски валидации.

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

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

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

1.2.2 Проектирование веб-интерфейсов модуля регистрации документов

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

Страница:


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

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2025, ООО «Олбест» Все наилучшее для вас