Содержание
Введение
Глава 1. Проектирование модуля регистрации документов
1.1. Анализ предметной области и спецификация требований. Анализ предметной области
1.1.1. Автоматизация процесса регистрации документов
1.1.2. Спецификация функциональных требований
1.2. Проектирование веб-интерфейсов и таблиц базы данных
1.2.1. Проектирование таблиц для работы с модулем
1.2.2. Проектирование веб-интерфейсов модуля регистрации документов
Глава 2. Разработка модуля регистрации документов
Заключение
Список использованных источников
Введение
Достижение максимальной эффективности в работе персонала компании является одной из основных задач для руководства. На сегодняшний день, существует множество способов оптимизации работы человека в организации. Один из наиболее используемых способов – это внедрение систем электронного документооборота.
Электронный документооборот позволяет упразднить большую часть работы с бумажными документами, что снижает затраты на расходные материалы, движение документов между ответственными лицами, а также снижает временные затраты на обработку документов. Системы ЭДО широко распространены на рынке информационных систем и, в основном, представлены в виде программных платформ, не способных, в полной мере удовлетворить потребности заказчиков.
Анализ практического опыта проведения ИТ-проектов по внедрению СЭДО выявил необходимость доработки системы под нужды заказчиков, в частности, заказчики требуют автоматизации процесса проверки документов на соответствие стандартам, настраиваемых в системе, и присваивания дополнительных атрибутов к документам для оптимизации работы с ними. Это обуславливает целесообразность разработки модуля регистрации документов.
Актуальность проектирования программного решения достигается возникшей необходимостью в автоматизированном средстве регистрации документов в системе управления проектно-технической документации. Необходимость выражается в больших временных затратах на регистрацию документов и устранение возникающих ошибок.
В качестве объекта исследования изучаемой работы выступает система управления проектно-технической документации на платформе «Open Text Content Server 16.2».
Предметом исследования является программный модуль регистрации документов.
Целью работы является – программный модуль регистрации документов для системы управления проектно-технической документации на платформе «Open Text Content Server 16.2». Для достижения цели работы необходимо решить задачи:
- анализ предметной области;
- анализ архитектуры модуля в «Open Text Content Server 16.2»;
- построение диаграммы прецедентов;
- построение диаграмм активностей;
- построение диаграмм последовательностей;
- описание этапов проектирования;
- генерирование и оптимизация схемы классов;
- проектирование веб-страниц запуска маршрута согласования и регистрации исходящих пакетов документов
- разработка программного модуля на платформе «OpenText Content Server2»;
- разработка веб-интерфейсов для программного модуля;
- разработка таблиц и хранимых процедур для базы данных;
- тестирование разработанного модуля;
- доработка программного модуля в соответствии с результатами тестирования.
Для разработки модуля регистрации документов для СУПТД, планируется пройти следующие этапы разработки, описываемые в главах.
В первой главе существует необходимость анализа предметной области и разработка проекта программного модуля, что делается для разработки концептуального и материального видения модуля регистрации документов.
Во второй главе планируется провести разработку модуля регистрации документов при помощи стандартных средств разработки платформы «OpenText Content Server 16.2».
В заключительной главе необходимо провести тестирование и доработку разработанного программного модуля. Результатом данного этапа станут тестовые сценарии, на основе которых, можно будет протестировать программный модуль, а также доработанные версии программного модуля.
Выпускная квалификационная работа направлена на оптимизацию работы СУПТД и пользователей, работающих с ней, посредством использования современных технологий проектирования и разработки.
Глава 1. Проектирование модуля регистрации документов
1.1. Анализ предметной области и спецификация требований. Анализ предметной области
Система управления проектно-технической документацией используется для работы с электронными документами различных организаций. Проектно-техническая документация – это документация, созданная в рамках проекта по выполнению технических работ. Электронными документами для СУПТД является документированная информация, представленная в электронном виде.
СУПТД построена на платформе «OpenText Content Server 16.2». Данная платформа предоставляет функционал, позволяющий заменить потоки бумажных документов, на упорядоченные и формализованные потоки электронных документов. Формализованный поток электронных документов позволяет осуществлять контроль движения и обработки электронных документов. Формализация потоков электронной документации на платформе «OpenText Content Server 16.2», осуществляется при помощи маршрутов движения документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
В системе управления проектно-технической документации создано обобщённое иерархическое строение проектов. Основные уровни иерархии, рассматриваемые в рамках курсовой работы – это уровни: проект и контракт. Проектом, в данной системе, является кооперативная форма деятельности, представленная в виде потоков документов. Понятие контракта включает в себя хранение ключевых для работы в СУПТД свойств договоров с контрагентами организации.
Для установления связи документов с сущностями иерархии проекта, в рассматриваемой системе, необходимо присвоить документам соответствующие атрибуты. Атрибуты документов описываются, настраиваются и собираются в группы, именуемые категориями.
Поскольку заполнение категорий устанавливает связь между документом и сущностями системы, данный процесс называется регистрацией документа в системе и позволяет проводить с ним дальнейшие манипуляции в рамках электронного документооборота в организации.
Процесс регистрации документов, в данном случае, происходит вручную и занимает время, которое необходимо сократить путём автоматизации. Основным инструментом регистрации документов в системе будет являться модуль регистрации документов.
Предполагается, что модуль регистрации документов позволит сократить временные затраты на регистрацию документов, а также снизить время проверки документов и сопроводительных ведомостей.
Помимо регистрации входящих документов, планируется спроектировать процесс регистрации исходящих документов. Резюмируя выше описанное, следует вычленить следующий функционал проектируемого программного модуля и веб-интерфейсов:
- автоматическую валидацию входящих и исходящих пакетов документов;
- автоматическую регистрацию входящих и исходящих пакетов документов в системе;
- автоматическое оповещение ответственных лиц;
- возможность редактирования пакетов документов перед процессом регистрации и во время процесса регистрации;
- запуск маршрутов согласования документов;
- автоматическую загрузку и выгрузку пакетов документов на сервер.
Автоматическая валидация входящих и исходящих пакетов документов необходима для проверки пакетов документов перед их регистрацией в системе управления проектно-технической документации. Данная функция позволит избежать регистрации документов с некорректными данными и избежать ошибок в последующей работе маршрутов документов.
Автоматическое оповещение ответственных лиц даст возможность для шаблонного уведомления лиц, ответственных для работы с каждым конкретным пакетом документов. Шаблонное уведомление позволяет в формализованном виде предоставить получателям всю необходимую информацию, исключая возможность потери документа в множестве серверов и инстанций рассматриваемой системы.
Поскольку маршруты согласования документов имеют те же атрибуты, что и пакеты документов, автоматизация их запуска позволяет упростить данную процедуру и устранить возможные ошибки до запуска маршрута.
1.1.1. Автоматизация процесса регистрации документов
Актуальность автоматизации процесса регистрации пакетов документов в СУПТД обусловлена сокращением временных издержек на регистрацию и валидацию документов, и минимизацией человеческого фактора. Поскольку «OpenText Content Server 16.2» — это корпоративная система электронного документооборота, программные решения, выполняемые для заказчиков закрыты для свободного доступа. Исходя из политики конфиденциальности при работе с заказчиками, возможные решения рассматриваемой задачи могут существовать, но их невозможно найти в открытом доступе.
Автоматизация процесса регистрации пакетов документов в СУПТД возможна при использовании сопроводительных ведомостей в виде таблиц MS Excel. Шаблоны сопроводительных ведомостей загружаются в систему и могут быть определены для каждого контракта. В соответствии с шаблонами, подрядчик должен заполнять сопроводительные ведомости, которые будут хранить атрибуты каждого документа из пакета.
Одним из ключевых процессов регистрации является валидация документов. Для реализации автоматизации процесса валидации необходимо выбрать метод валидации. Валидация атрибутов документов выполняется при помощи поиска соответствующих значений в базе данных. Валидация названия документов не столь однозначна. Так, как каждый документ необходимо нумеровать и привязывать к сущностям проектов, а сущностей в системе может быть большое количество, решено реализовать валидацию названия документов при помощи масок.
Единственным способом хранения масок является, хранение в таблице в базе данных. Данную таблицу стоит связать с таблицей контрактов, для определения соответствия каждой маски с определённым подрядчиком.
Присвоение категорий документам с заполнением атрибутов, можно осуществить автоматически, при помощи загрузки данных из сопроводительной ведомости и выбора подходящей категории и базы данных. Для данной цели необходимо реализовать скрипт, который будет запускать обработчик таблиц MS Excel, доставать из них данные и записывать, непосредственно, в присваемые категории.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Стоит упомянуть, что у каждого заказчика могут быть разные представления об иерархии проектов и разрабатываемое программное решение является демонстрационным, но может быть доработанным в соответствии с пожеланиями заказчиков.
1.1.2. Спецификация функциональных требований
Для спецификации функциональных требований и формализации анализа возможностей проектируемого модуля регистрации документов решено использовать язык моделирования «UML». Для начала, перечисленные выше, функциональные требования необходимо описать в виде сценариев прецедентов (вариантов использования).
В данном параграфе необходимо рассмотреть функциональные требования, отвечающие за загрузку и регистрацию пакетов документов.
В таблице 1.1 формализован процесс загрузки пакетов документов в систему управления проектно-технической документации. Для запуска данного прецедента, пользователь должен быть авторизован, а директория загрузки документов в систему должна быть привязана к контракту. В базе данных в сущность контракта необходимо занести путь для загрузки документов с сервера. Данный способ загрузки документов был выбран из-за простоты разработки и настройки с возможностью дальнейшей модернизации.
Таблица 1.1. Прецедент «Загрузить пакет документов»
После нажатия кнопки загрузки, вызывается метод получения списка доступных для загрузки документов. На вход методу передаётся идентификатор папки загрузки. С помощью идентификатора папки загрузки в методе генерируется запрос в базу данных для получения пути к директории загрузки на сервере. Получив путь к директории с документами на сервере, все вложенные папки записываются в список и посылаются в клиентскую часть для ознакомления пользователем.
Выбрав необходимый пакет документов, пользователь запускает метод загрузки пакета документов, который загружает директорию с документами и инициирует запуск процесса валидации и регистрации.
Если путь для загрузки документов с сервера указан неправильно, то список доступных пакетов документов возвращается пустым.
Следующий сценарий прецедента описан в таблице 1.2 и инициируется прецедентом загрузки пакетов документов. Сценарий прецедента описывает проектируемое поведение процесса регистрации документа в системе. Рассматриваемый прецедент включает в себя прецедент валидации пакета документов и регистрирует документ в системе в зависимости от результата валидации. Так, как прецедент регистрации пакетов документов включается в вариант использования «Загрузка пакетов документов», пользователь будет тем же, кто и запустил процесс загрузки документов.
Таблица 1.2. Прецедент «Зарегистрировать входящий пакет документов»
После загрузки пакета документов, запускается процесс валидации. Прецедент «Пройти валидацию» описан в таблице 1.3. В процессе валидации должна происходить выгрузка данных из сопроводительной ведомости и сравниваться с документами в пакете и сущностями в системной базе данных. Если валидация не выявила ошибок в пакете документов, то начинается процесс регистрации, а именно присвоение соответствующей типу документов категории и её заполнение.
В том случае, если валидация выявила ошибки в пакете документов, то пользователю выводится сообщение о соответствующей ошибке, а пакет перемещается в папку отклонённых документов, для последующего исправления ошибок в пакете.
Таблица 1.3. Пройти валидацию
Далее следует рассмотреть прецеденты, связанные с процессом запуска маршрута согласования документов.
В таблице 1.4 описывается предполагаемый сценарий варианта использования, отображающего процесс запуска маршрута согласования документов. Рассматриваемый прецедент будет выполняться корректно, только, если пакет с документами зарегистрирован в системе.
Для запуска прецедента, пользователь должен будет выбрать при помощи селектора, необходимый пакет документов и нажать на кнопку запуска маршрута согласования. После этого, отправляется запрос на сервер и запускается метод генерирования веб-страницы. Затем, сгенерированная веб-страница отображается пользователю, который выбирает сроки рассмотрения документов и пользователей, на роли согласующих. Дальнейший процесс описан в таблице ниже.
Рассматриваемый прецедент необходим для автоматизации запуска маршрута согласования пакетов документов. Автоматизация запуска маршрута согласования направлена упростить рассматриваемый процесс, что ускорит время запуска и уменьшит количество возможных ошибок.
Сценарий прецедента, в данном случае, расширяется прецедентами «Получить пользователей для рассмотрения пакета документов» и «Установить сроки рассмотрения», описанными в таблицах 1.5 и 1.6 соответственно.
Таблица 1.4. Прецедент «Запустить процесс рассмотрения документов»
Для установления пользователей, ответственных за рассмотрение документов, планируется создать таблицы для хранения идентификаторов пользователей, ролей пользователей и связь с определённым контрактом. Информация из этих таблиц будет изыматься при помощи метода, построенного на основе варианта использования, представленного ниже.
Прецедент необходим для автоматической загрузки пользователей из базы данных. Список загруженных идентификаторов пользователей будет соответствовать списку ответственных лиц согласно контракту. Данный список будет использован для выбора пользователем ответственных за согласование лиц. Решено сконфигурировать рассматриваемый прецедент именно таким образом, для того, чтобы ограничить список, доступных для выбора, пользователей, ведь в системе могут быть зарегистрированы более ста пользователей, и не все могут иметь права на запуск маршрутов согласования.
Таблица 1.5. Прецедент «Получить пользователей для рассмотрения пакета документов»
Сценарий прецедента «Установить сроки рассмотрения» прост так, как в базе данных уже имеется хранимая процедура, генерируемая крайние сроки рассмотрения относительно контракта, статуса рассмотрения и ревизии документов.
Исходя из выше сказанного, можно сказать, что задача, решаемая в прецеденте, это задача отображения и редактирования сроков рассмотрения на веб-странице запуска маршрута согласования. Это необходимо для предоставления возможности редактирования сроков рассмотрения документов.
Таблица 1.6. Прецедент «Установить сроки рассмотрения»
Следующая группа прецедентов отвечает за работу с исходящими документами. Основной вариант использования отвечает за регистрацию исходящих пакетов документов. Сценарий рассматриваемого варианта использования представлен в таблице 1.7. Данный прецедент включает в себя пять подчинённых прецедентов.
Создание прецедента, описывающего проектируемый сценарий процесса регистрации исходящих пакетов документов, позволяет формализовать данный процесс и сократить временные издержки и число возможных ошибок.
Сценарий прецедента описан в таблице 1.7. Планируется, что прецедент будет связывать, включенные в него варианты использования. Подчинённые варианты использования будут вызываться последовательно, а прецеденты редактирования состава пакета документов, атрибутов исходящего пакета документов и задания получателей уведомления.
Таблица 1.7. Прецедент «Зарегистрировать исходящий пакет документов»
Первый вариант использования, который будет запускаться в рамках регистрации исходящего пакета документов называется «Получить список контрактов». Метод получения списка контрактов уже существует, поэтому в сценарии прецедента описан только предполагаемый процесс выбора контракта и запуска следующего варианта использования.
Сценарий рассматриваемого варианта использования описан в таблице 1.8. Целесообразность описанного прецедента выражается в том, что существуют индивидуальные для каждого контракта атрибуты, задействованные в процессе регистрации исходящего пакета документов.
Таблица 1.8. Прецедент «Получить список контрактов»
Далее по порядку вызова прецедентов запускается вариант использования с названием «Редактировать атрибуты исходящего пакета документов». Сценарий рассматриваемого прецедента описан в таблице 1.9.
Для присвоения атрибутов исходящему пакету документов решено использовать такой инструмент «OpenText Content Server 16.2», как форма. Обоснованием выбора является удобство эксплуатации формы для решения задачи хранения и редактирования атрибутов пакетов документов.
Таблица 1.9. Прецедент «Редактировать атрибуты исходящего пакета документов»
Экземпляр формы будет невидим для пользователей, что ужесточает контроль над редактированием атрибутов пакета документов. Для формы также необходимо создать представление, которое позволит изменять интерфейс работы с формой.
Далее следует описание сценария прецедента «Редактировать состав пакета документов». Рассматриваемый вариант использования удовлетворяет потребность в изменении состава пакета документов. Предполагается, что во время выполнения данного прецедента, пользователю представится возможность добавить документы в исходящий пакет документов и удалить добавленные документы.
Добавление документов в исходящий пакет документов позволит пользователю дополнить пакет недостающими документами, для передачи полной информации по выполняемой задаче подрядчику. Сценарий прецедента описан в таблице ниже.
Таблица 1.10. Прецедент «Редактировать состав исходящего пакета документов»
Следующий прецедент отвечает за отображение возможных получателей уведомления о регистрации исходящего пакета документов и отображение выбранных документов. Сценарий прецедента описан в таблице 1.11.
Целесообразность создания данного варианта использования состоит в предоставлении возможности редактирования получателей уведомления.
Таблица 1.11. Прецедент «Указать получателей уведомлений»
Заключительным прецедентом является вариант использования отправляющий собранные документы на сервер подрядчика и рассылающего уведомление о регистрации исходящего пакета документов. Уведомление должно генерироваться из шаблона письма, с добавлением свойств зарегистрированного пакета документов.
Метод, отсылающий пакет документов на сервер подрядчика уже существует, поэтому целесообразно будет дополнить его изменениями, касающимися регистрации исходящего пакета документов. Сценарий, происходящий по этим изменениям описан в таблице ниже.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Таблица 1.12. Прецедент «Отправить пакет документов подрядчику»
Построение и описание диаграммы прецедентов
После перечисления и описания всех сценариев прецедентов необходимо их связать между собой и описать связи и зависимости.
Также, стоит отметить, что на диаграмме прецедентов должен появиться актер, именуемый базой данных. Данный элемент косвенно присутствовал в сценариях описания прецедентов.
После анализа сценариев прецедентов и необходимых связей получилась диаграмма вариантов использования, изображённая на рисунке А.1 в приложении А.
На рисунке видно, что каждый прецедент, запускаемый в системе управления проектно-технической документацией, связан с базой данных системы. Данная связь обусловлена манипуляциями с объектами системы, хранящимися в базе данных, и реализацией дополнительного функционала в базе данных. Дополнительный функционал, обрабатывающий данные для использования в функциях системы, реализуется в базе данных в связи с удобством размещения и обращения к функционалу.
На схеме пользователь ассоциируется только с тремя прецедентами. Данные прецеденты описывают сценарий проектируемого функционала, расширяемого и запускающего подчинённые варианты использования.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Связи расширения и включения, указанные на диаграмме, необходимо для определения зависимости между прецедентами и последовательность сценариев вариантов использования.
На диаграмме вариантов использования также присутствуют актеры, обозначаемые ролями в организации. Планируется, что в рамках проводимого исследования будут задействованы только свойства этих актеров, такие как идентификатор пользовательского аккаунта и адрес электронной почты.
Анализ архитектуры модуля в «OpenText Content Server 16.2»
На данный момент, существует множество платформ программного обеспечения, для которых ведутся разработки. Архитектура каждой из платформ может отличаться от другой и это следует учитывать при проектировании программного решения какой-либо задачи. Несоответствия проекта программного решения архитектуре платформы, для которой будут проводиться разработки, ведут к повторному проектированию, а также временным и материальным затратам.
В платформе «OpenText Content Server 16.2» используется модульное строение системы. Рассматриваемое строение предоставляет следующие преимущества: упрощённый процесс добавления функционала в систему, упрощённый процесс отката изменений в системе, повышение отказоустойчивости системы относительно ошибок в модулях и возможность переопределения интерфейсов стандартных модулей системы без вмешательства в их код.
Основным элементом модуля в рассматриваемой платформе является «OSpace». Этот элемент обязателен для функционирования модуля так, как в нём хранятся объекты, методы и свойства, которые составляют функционал модуля.
Объект, отвечающий за установку и конфигурацию модуля называется «The WebModule». Данный объект должен присутствовать в каждом модуле системы. Объект, обычно, наследуется от соответствующего объекта в ядре системы., во избежание возникновения ошибок и для приведения модулей к единому формату.
Для установки и конфигурирования модуля вне процесса основной установки системы, существует объект «Configure». Объект наследуется от соответствующего объекта стандартного модуля «WebDspRoot».
В каждом модуле, работающим с запросами пользователей, находится объект хранящий информацию об обработчиках запросов «RequestHandlerGroup object». Также, данный объект позволяет регистрировать обработчики событий в подсистеме обработки запросов. Объект наследуется от соответствующего объекта стандартного модуля «WebDspRoot».
И последний, неотъемлемый объект любого модуля – это «ini» файл конфигурации. В нём задаются пути установки, зависимости от других модулей и свойства модуля.
В заключении, необходимо упомянуть об интерфейсах модуля. Интерфейсы представляют собой «HTML» страницы и хранятся в одноимённой папке модуля. Интерфейсы вызываются после выполнения обработчиков событий. Данные, передаваемые обработчиком событий интерфейсам, могут быть обработаны при помощи веб-скриптов, располагаемых в коде интерфейсов.
Таким образом, следует отметить, что в данном параграфе был проведён анализ предметной области, выявлены основные функциональные требования и проанализированы варианты использования проектируемого программного модуля регистрации документов. В качестве результатов главы выступает диаграмма вариантов использования и анализ минимальной архитектуры проектируемого модуля.
Проектирование диаграммы классов
Создание диаграмм активности
Для более детальной спецификации вариантов использования и наглядного изображения процессов, протекающих в них, необходимо декомпозировать прецеденты.
С целью осуществления данной задачи решено воспользоваться диаграммами активностей, которые описывают активность, происходящую внутри прецедентов.
Как и в описании сценариев прецедентов, стоит начать декомпозицию прецедентов с группы вариантов использования, отвечающих за загрузку и регистрацию пакетов документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Первая диаграмма активностей – это диаграмма загрузки пакетов документов. В рамках активности рассматриваются прецедент «Загрузить пакет документов. Диаграмма представлена на рисунке ниже.
На диаграмме активности указана единственная роль, которая будет работать с системой в рамках рассматриваемой активности.
Что касается действий, которые выполняют СУПТД, то видно, что они включают в себя объекты, выполняющие процессы валидации и регистрации пакетов документов. Также на диаграмме присутствует условие, которое создаёт альтернативные пути прохождения действий.
Далее следует описать диаграмму активности для запуска процесса рассмотрения документов. Диаграмма представлена на рисунке B.1.
На рассматриваемой диаграмме появляются действия, связанные с генерированием веб-страниц и работой с картами маршрутов. Получается, что для работы процесса необходимы веб-интерфейсы, отображающие кнопки запуска процессов в директории входящих пакетов документов и веб-страница, отображающая параметры запуска маршрутов согласования, генерирующая переменное содержимое.
Активность построена таким образом для того, чтобы избежать ошибок из-за некорректности пакетов документов во время запуска маршрутов согласования и сделать процесс запуска маршрутов максимально простым для пользователя. Данные о пакете документов будут извлекаться из категорий, привязанных к документам. В соответствии со считанными данными, будет генерироваться и веб-страница.
Завершающая группа диаграмм активностей относится к процессу регистрации исходящего пакета документов. Процессы, включённые в процесс регистрации исходящего пакета документов, также в полной мере включены в рассматриваемую диаграмму, за исключением объёмных и ключевых процессов, которые декомпозированы в отдельные диаграммы активностей. Схема активности регистрации исходящего пакета документов изображена на рисунке B.2.
На схеме показано взаимодействие между действиями активности. Рассматриваемая диаграмма активности отображает основные этапы работы процесса регистрации исходящих пакетов документов. Активность отображает три основных шага:
- Запуск редактирования атрибутов пакета документов.
- Запуск редактирования состава пакета документов.
- Запуск редактирования списка получателей уведомления о запуске маршрута согласования.
Каждый шаг включает в себя множество действий, поэтому решено декомпозировать данные шаги в отдельные диаграммы активностей.
Первый описываемый шаг – это процесс запуска редактирования атрибутов пакета документов. Основной задачей рассматриваемого процесса является присвоение атрибутов пакету документов и предоставление пользователю возможности редактирования данных атрибутов.
В основе рассматриваемой диаграммы лежит процесс присвоения исходящему пакету документов атрибутов. Для выполнения этой задачи, решено присваивать пакету документов атрибуты при помощи добавления формы атрибутов. Редактирование атрибутов происходит при помощи веб-интерфейса: генерируемой веб-страницы с контейнером, в котором запускается стандартная функция редактирования формы. У самой формы будет спроектировано представление, адаптированное для сгенерированной веб-страницы.
Следующая диаграмма активностей описывает процесс редактирования состава пакета документов. Процесс запускается из предыдущего шага. Во время выполнения рассматриваемого процесса, происходит считывание атрибутов каждого документа и формы. После считывания атрибутов, генерируется сопроводительная ведомость и готовятся данные для отображения на веб-странице.
Заключительная диаграмма активности описывает процесс редактирования списка получателей уведомлений о регистрации исходящего пакета документов.
Действие по загрузке записей о получателях уведомлений передано для проектирования в базу данных, как хранимую процедуру. Выбор получателей уведомлений необходимо спроектировать в понятном и интуитивном интерфейсе веб-страницы.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
По завершении активности, пользователь нажимает на кнопку отправки и запускает процесс отправки уведомлений и копирования пакета документов на сервер подрядчика.
Чтобы уменьшить громоздкость описания всех диаграмм активностей, типовые диаграммы стоит убрать в приложение к работе. Остальные диаграммы активности находятся в приложении B.
Создание диаграмм последовательности
В предыдущих пунктах были показаны специфицированные функциональные требования и действия внутри них. Теперь присутствует необходимость отображения процессов в течение времени.
Данное описание необходимо для более чёткого представления общей картины. Так, как в виртуальной реальности действия в различных процессах выполняются последовательно, необходимо описать данную последовательность, чтобы чётко представлять проектируемые объекты.
Как и в прошлом пункте, необходимо представить описание процессов формирования основных диаграмм, когда, как типовые диаграммы будут находиться в приложении к работе.
Для начала, рассмотрим процесс загрузки пакета документов.
За основу диаграммы последовательности берётся соответствующая диаграмма активности. На диаграмме последовательности, в отличие от диаграммы активности, уже представлены все объекты, которые взаимодействуют друг с другом, в однотипном виде. А взаимодействие осуществляется путём отправки сообщений. Диаграмма последовательности процесса загрузки пакета документов представлена на рисунке C.1.
Для отображения процесса в времени, все объекты из диаграммы активности встали в одну линию и осталась необходимость лишь в описании их взаимодействия.
Поскольку в диаграмме активности описано почти всё взаимодействие, перенос данных о взаимодействии оказался не столь затруднительным.
Далее рассмотрим процесс запуска маршрута согласования. Диаграмма данного процесса представлена на рисунке C.2.
Построение данной диаграммы выявило, что появилась необходимость проектирования интерфейса для запуска данного процесса из директории входящих пакетов документов. Также, существует необходимость проектирования веб-интерфейса для задания параметров запуска маршрута согласования документов, которые необходимо завести ответственным пользователем. Среди действий, которые выполняются в рамках данного взаимодействия существуют манипуляции с движением пакета документов, атрибутами документов и экземплярами маршрутов согласования.
Следующий процесс, который нуждается в описании – это процесс регистрации исходящего пакета документов.
Действия на диаграмме представлены в виде последовательности, что позволяет упорядочить этапы выполнения процесса. Также, как и при проектировании диаграмм активности, на схеме последовательности представлены ключевые шаги, которые взаимодействуют с пользователем через веб-интерфейсы.
Построение диаграммы последовательности выявило следующее: существует необходимость проектирования веб-интерфейсов для действий обработки пакета документов, а также проектирование веб-интерфейса запуска рассматриваемого процесса из инструмента поиска документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Получается, что пользователь взаимодействует, в основном, с веб-интерфейсами проектируемого модуля. Но каждый веб-интерфейс должен включать в себя часть веб-интерфейсов стандартного функционала системы.
На диаграмме отображено взаимодействие данных объектов, что позволяет лучше рассмотреть, какие нужны методы и классы для проектируемого личного кабинета.
Спроектированная диаграмма представлена на рисунке C.3.
Далее следует описать процесс редактирования атрибутов исходящего пакета документов. Схема последовательности представлена на рисунке C.4.
В рамках выполнения последовательности редактирования атрибутов исходящего пакета документов выполняются действия по созданию экземпляров формы и формирования исходящего пакета документов. Помимо действий по созданию формы и формированию пакета документов, на диаграмме отображено взаимодействие между пользователем и системой при помощи веб-интерфейса редактирования формы.
Исходя из задач, поставленных в диаграмме последовательности относительно атрибутов исходящего пакета документов, следует упомянуть, что выявлена необходимость в проектировании формы и её представления, выступающего в качестве веб-интерфейса редактирования формы. Проектируемое представление формы следует адаптировать для использования в контейнере основной страницы, сгенерированной в результате выполнения последовательности.
Решение по проектированию главной страницы процесса регистрации исходящего пакета документов, содержащей контейнер, для проведения промежуточных шагов принято в связи с необходимостью возврата к предыдущим шагам последовательности без обновления страницы.
Далее, необходимо рассмотреть процесс редактирования состава исходящего пакета документов. Диаграмма последовательности представлена на рисунке C.5.
Из приведённой диаграммы последовательности следует выделить ключевые действия: создание сопроводительной ведомости и генерирование веб-страницы. Исходя из ключевых действий дополнительными задачами в проектировании являются проектирование шаблона сопроводительной ведомости и веб-интерфейса для добавления дополнительных документов в пакет.
Заключительной диаграммой последовательности является схема последовательности процесса редактирования списка получателей уведомлений. Исходя из спроектированной диаграммы конечный проект требует наличия веб-интерфейса редактирования списка получателей уведомлений.
Для дальнейшего описания проделанной работы остальные диаграммы последовательности не столь важны. С ними можно ознакомиться в приложении C.
Создание диаграммы классов
Целью данной работы является разработка модуля регистрации документов, соответственно, существует потребность в абстрактном представлении классов, в которых будет прописываться поведение модуля регистрации документов. Можно сказать, что все, описанные выше, этапы работы были проведены для построения организованной диаграммы классов.
Этапом, по результатам которого можно построить диаграмму классов, является этап создания диаграмм последовательности. Чтобы построить диаграмму классов, элементы из всех диаграмм последовательности были включены в диаграмму классов и оптимизированы для работы с платформой «OpenText Content Server 16.2». Принято решение самостоятельно составить диаграмму классов, в соответствии с архитектурой системы.
После составления диаграммы, на схеме классов получилось три класса. Помимо классов, на диаграмме присутствуют шесть интерфейсов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Каждый класс содержит примерно равное количество методов. Каждый класс связан с интерфейсом и зависим от него, поскольку через интерфейс передаются данные, введённые пользователем.
Подводя итоги данного параграфа, стоит заметить, что основная задача главы решена и диаграмма классов построена.
Для достижения задачи были выполнены следующие этапы:
- созданы диаграммы активностей для прецедентов;
- созданы диаграммы последовательностей по диаграммам активностей;
- диаграммы последовательностей объединены в общую диаграмму;
- построена схема классов.
Следующим шагом данной работы является проектирование таблиц базы данных и веб-интерфейсов.
1.2. Проектирование веб-интерфейсов и таблиц базы данных
1.2.1. Проектирование таблиц для работы с модулем
Для работы любого веб-модуля на платформе «OpenText Content Server 16.2» необходима база данных. В ней хранятся данные обо всех сущностях системы.
Так, как модуль регистрации документов работает с объектами системы, записанными в базе данных и подразумевает работу с проектируемыми иерархиями сущностей базы данных.
Также присутствует необходимость создания справочника для хранения идентификаторов ключевых объектов в системе: идентификаторов шаблонов и карт маршрутов.
И, исходя из выше сказанного были выдвинуты следующие требования к организации данных для модуля регистрации документов:
- должны присутствовать таблицы, отвечающие за связь пользователей и контрактов;
- необходим справочник для хранения ссылок на объекты системы;
- в базе данных должны содержаться таблицы, хранящие и связывающие с контрактами маски валидации.
Учитывая требования к данным от модуля регистрации документов, были спроектированы следующие таблицы для базы данных (см. рисунок 1.7.): один справочник и пять таблиц.
На схеме представлены спроектированные таблицы для работы с масками валидации и пользовательскими записями ответственных лиц. Также на диаграмме изображена таблица контрактов, с которой связаны все спроектированные таблицы, за исключением справочника, который хранит идентификаторы связанных объектов в системе.
1.2.2. Проектирование веб-интерфейсов модуля регистрации документов
Подходя к концу исследования осталась задача проектирования веб-интерфейсов для модуля регистрации документов. При проектировании веб форм учитываются все предыдущие этапы работы.
Веб-интерфейсы и связи с классами, проектируемые в данной главе, отображены на диаграмме классов. Атрибуты и методы веб-интерфейсов также отображены на диаграмме классов.
Для начала необходимо описать веб-интерфейс запуска методов работы с входящими пакетами документов.
Веб-интерфейс представляет собой доработку для директории входящих документов, отображающую кнопки запуска процессов загрузки пакета документа и запуска процесса согласования документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Следующий веб-интерфейс отвечает за редактирование атрибутов маршрута перед его запуском. При помощи веб-интерфейса возможно лишь редактирование согласующих пользователей и крайних сроков рассмотрения.
После внесения всех данных, пользователь нажимает кнопку «Start»; запускается валидация заполняемых полей и запускается метод запуска маршрута согласования документов.
Следующий прототип веб-интерфейса отображает процесс выбора пакета документов для загрузки в систему.
В качестве проектируемого веб-интерфейса выступает диалоговое окно со списком доступных на сервере пакетов документов. Выбрав, при помощи селектора, необходимый пакет, пользователь нажимает кнопку «Download» и запускает процесс загрузки пакета документов в систему.
Далее следует рассмотреть прототип веб-интерфейса выбора контракта, при регистрации исходящего пакета документов. Как и предыдущий прототип, рассматриваемый прототип веб-интерфейса является диалоговым окном. В качестве селектора идентификатора контракта, в данном случае, выступает выпадающий список. После выбора контракта и нажатия кнопки «OK», запускается метод редактирования атрибутов исходящего пакета документов.
Следующий веб-интерфейс предоставляет пользователю возможность редактирования атрибутов формы исходящего пакета документов. Часть атрибутов формы заполняются автоматически, но доступны для редактирования пользователем. Прототип веб-интерфейса представлен на рисунке 1.12.
Спроектированный веб-интерфейс включает в себя стандартные блоки взаимодействия с пользователем, что упрощает использование системы и стандартизирует представления системы. При нажатии кнопки «Next» запускается метод редактирования состава пакета документов и сохраняется форма.
После прототипа веб-интерфейса редактирования атрибутов исходящего пакета документов, по порядку, идёт прототип веб-интерфейса редактирования состава исходящего пакета документов.
Веб-интерфейс позволяет пользователю добавить документы в исходящий пакет документов и удалять добавленные документы. Нажав кнопку «Next», пользователь запускает процесс редактирования получателей уведомлений.
Заключительный прототип веб-интерфейса отображает проектируемый интерфейс редактирования списка получателей уведомления о регистрации исходящего пакета документов.
Веб-интерфейс предоставляет пользователю возможность редактировать список пользователей, получающих уведомление о регистрации исходящего пакета документов и просматривать список документов, добавленных в данный пакет документов.
Таким образом в первой главе представлены результаты проектирования веб-интерфейсов модуля регистрации документов и таблиц базы данных, связанной с модулем. Веб-интерфейсы иллюстрируют предсказуемое поведение модуля регистрации документов при взаимодействии с пользователем, что даёт возможность более точной разработки алгоритмов работы модуля.
Глава 2. Разработка модуля регистрации документов
Постановка задач для разработки модуля регистрации документов
Постановка задач в рамках разработки программного модуля для системы проектно-технической документации является ключевым моментом в этапе разработки для платформы «OpenText Content Server 16.2».
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Важность данного этапа заключается в специфичности процессов разработки для «OpenText Content Server 16.2». Детализация задач по разработке программного модуля способствует эффективному процессу разработки. Эффективность выражается в сокращении временных издержек на исследование платформы и выбора инструментов разработки.
Задачи, поставленные на данном этапе позволят структурировать процесс анализа возможностей платформы «OpenText Content Server 16.2» и программного обеспечения для дополнительной разработки в рамках разработки программного модуля. Также постановка задач подразумевает чёткое планирование процесса разработки программного модуля, веб-интерфейсов и объектов базы данных.
Исходя из этапа проектирования проводимого исследования, необходимо выделить следующие задачи для завершения этапа разработки программного модуля регистрации документов для СУПТД:
- анализ возможностей и архитектуры платформы «OpenText Content Server2»;
- разработка программного модуля на платформе «OpenText Content Server2»;
- разработка веб-интерфейсов для программного модуля;
- разработка таблиц и хранимых процедур для базы данных.
Анализ возможностей и архитектуры платформы «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 запросов. Данный механизм позволяет вызывать обработчики запросов из веб-интерфейсов и осуществлять взаимодействие и переключение веб-интерфейсов на клиентском уровне работы системы.
Помимо, рассмотренных выше классов, существует механизм программного взаимодействия с объектами системы, находящимися в системе и обрабатываемыми на клиентском уровне.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
В платформе «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» представлена иерархическая структура модулей, входящих в проект.
Следующим шагом в разработке программного модуля является создание модуля. Создание модуля происходит путём выполнения соответствующей команды в контекстном меню проекта на панели «Module Explorer». В результате, создаётся макет модуля и модульное пространство с заданным пользователем названием и версией.
В соответствии с анализом архитектуры модуля, проведённом в первой главе, необходимо создать объект «The WebModule». Объект веб-модуля наследуется от одноимённого объекта модуля «KERNEL».
Неотъемлемой частью модуля является его конфигурация. Для формирования конфигурации модуля, необходимо унаследовать объект «Configure» от модуля «WebAdmin». В созданном объекте задаются свойства программного модуля, позволяющие взаимодействовать с системой.
После проведения приведённых операций и задания свойств для созданных объектов, необходимо зарегистрировать модуль в системе. Процесс регистрации осуществляется путём установки программного модуля в систему. Установка программного модуля подразумевает регистрацию пространства модуля в системе хранения модулей и обработчика административных запросов.
Для установки модуля необходимо запустить веб-сервис и пройти авторизацию в профиле администратора. Далее на странице администратора нужно открыть раздел администрирования модулей и совершить установку модуля путём его выбора из списка доступных для установки модулей и запуска функции установки.
После установки в файл конфигурации системы записываются свойства модуля: путь к пространству модуля, название модуля и его версия. Также, во время установки, все файлы модуля переносятся из проекта в рабочую область системы и формируется иерархия каталогов модуля.
По умолчанию, иерархия каталогов внутри директории модуля содержит следующие каталоги: каталог для хранения веб-интерфейсов «html», каталог хранения пространства модуля «ospace» и каталог хранения изображений и стилей для веб-интерфейсов «img» — а также файл конфигурации в корне директории модуля.
Следующим шагом в разработке модуля является разработка функций валидации загружаемых документов, записи атрибутов в категории документов, а также генерирования исходящей сопроводительной ведомости.
Решено хранить функции в стандартном объекте корня модуля «Utils». Для начала разработки функций следует разработать функцию, проводящую процесс валидации входящего пакета документов.
Весь функционал по валидации, кроме валидации названий документов, происходит либо в теле рассматриваемой функции, либо в хранимых процедурах на сервере базы данных.
Входные параметры для функции передают значение системного идентификатора каталога или пакета, в котором находятся документы, и битового флага, отвечающего за запуск функции копирования атрибутов в категории документов. После передачи параметров, следует инициализация переменных. Среди типов переменных фигурируют следующие типы: объект («Object»), объектная сессия («Dapisession»), строковый («String»), динамический («Dynamic»), объект («DapiNode»), список («List»), иерархическая переменная («Assoc»), объект языка Java («JavaObject»), целочисленный тип («Integer»), рванный массив («RecArray»), логический («Boolean»).
Одна из иерархических переменных создана для хранения различных ошибок, которые могут возникнуть при валидации. Если в данную переменную запишется хоть одно значение, то по завершении выполнения функции, будет вызвано системная веб-страница, с указанными ошибками.
Далее необходимо пройти валидацию наименований документов во входящем пакете. Первым делом запускается хранимая процедура на сервере базы данных, которая возвращает список масок, относительно системного идентификатора. Затем запускается цикл, перебирающий список полученных масок, с вызовом функции валидации названия документов на каждой итерации.
Затем происходит проверка наличия сопроводительной ведомости в пакете документов. При наличии сопроводительной ведомости, начинается процесс синтаксического анализа сопроводительной ведомости путём запуска соответствующей функции на языке «Java». Функция синтаксического анализа разработана ранее. Она возвращает данные считанные по шаблону сопроводительной ведомости, указанному в таблице контрактов в базе данных. Запись контракта вычисляется путём выборки с заданным параметром папки загрузки входящих пакетов документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Пример шаблона сопроводительной ведомости показан на рисунке. Параметры, по которым считываются атрибуты из сопроводительной ведомости указаны в шаблоне и обособлены знаком процента. В соответствии с расположением параметра в ячейке таблицы шаблона, считываются соответствующие значения из сопроводительной ведомости. По завершении синтаксического анализа данные, считанные из сопроводительной ведомости, записываются в иерархическую переменную и отправляются на дальнейшую валидацию.
Далее происходит валидация полученных атрибутов и их присвоение категориям документов, в случае необходимости.
Одним из основных атрибутов документов является ревизия. Валидация ревизий документов происходит при помощи вызова хранимой процедуры. Это позволяет использовать один запрос к базе данных вместо нескольких, упрощая взаимодействие с системой.
В конце функции, при наличии ошибок, реализуется перемещение пакета документов в папку с отказными пакетами документов и уведомление пользователя, запустившего процесс валидации. Для уведомления пользователя, запускается функция уведомления об ошибках валидации. В качестве параметров функции выступают электронный адрес пользователя, ссылки на отказные документы и описание их наименований.
В качестве выходных параметров функции выступают: иерархическая переменная с ошибками и переменные, содержащие идентификаторы сопроводительных ведомостей.
Остальные функции раздела «Utils» также разработаны в соответствии с действиями, проводимыми в спроектированном поведении функции валидации входящего пакета документов. Итог разработки функций, запускаемых в контексте валидации входящего пакета документов изображён на рисунке ниже.
Наиболее важные функции, созданные в объекте «Utils», называются: «CheckMaskAndString», «MapCategory» и «SendEmailAboutVerificationError».
Функция «CheckMaskAndString» занимается проверкой имени документов на соответствие, переданной в качестве параметра, маске. Данный функционал выделен в отдельной функции потому, что его вызов происходит множественное количество раз и программный код теряет наглядность представления.
Метод «MapCategory» предоставляет функционал по присвоению категории передаваемому объекту и за записи в неё атрибутов. Атрибуты также, как и объект системы, передаются в качестве параметров к методу.
Последняя из перечисленных функций выполняет запись сообщения об ошибке в таблицу агента нотификации, высылающего сообщения получателям («SendEmailAboutVerificationError»). Функция генерирует сообщение в зависимости от параметров, получаемых в качестве иерархической переменной, и записывает в таблицу. Каждые пять минут агент нотификации отсылает сообщения из своей таблицы получателям.
Неотъемлемой составляющей программного модуля является обработчики запросов. Обработчики запросов построены в соответствии с разработанным проектом модуля.
Для создания обработчиков событий необходимо создать соответствующие объекты в модуле. Создание обработчиков запросов происходит также, как и создание остальных ключевых объектов модуля, путём наследования стандартного функционала.
Первый шаг в разработке модуля — наследование объекта «RequestHandlerGroup» стандартного модуля «WebDSPRoot». Затем, созданный объект, активируется путём изменения свойства «fEnabled» на значение «True».
Вторым шагом является наследование объекта «LLRequestHandler». Данный объект позволяет принимать запросы, подаваемые из объектов клиентской части веб-сервиса. Объект «LLRequestHandler» наследуется от объекта «RequestHandler» модуля «WebDSPRoot». Окончательный вид структуры программного модуля регистрации документов представлен на рисунке ниже.
Для того, чтобы привести объект «PTDocManager LLRequestHandler» в рабочее состояние, необходимо провести следующие манипуляции: задать положительное значение свойства «fEnabled», создать префикс выполнения функции в запросе и зарегистрировать обработчик в подсистеме распределения запросов.
После присваивания значения «true» для свойства, следует зарегистрировать объект в подсистеме распределения запросов. Это делается путём выполнения скрипта «SetRequestHandlers» объекта «PTDocManager RequestHandlerGroup». Стоит отметить, что для обработчика запросов было задано свойство «fModuleStyleSheetFiles», в котором указаны CSS стили, которые будут использоваться в веб-интерфейсах модуля.
В соответствии с проектом были созданы обработчики запросов. Для них созданы динамические переменные, передающие данные в веб-интерфейсы, и заданы имена файлов веб-интерфейсов.
Стоит пропустить описание разработки типовых обработчиков запросов, ввиду того, что процесс разработки прошёл без трудностей и прошёл в соответствии с проектом модуля. Однако, следует описать трудности, появившиеся при разработке обработчиков запросов «MakeOutgoingPacket» и «StartReview». Данные обработчики событий выполняют функции создания исходящего пакета документов и запуска маршрута согласования, соответственно.
«MakeOutgoingPacket» запускается после выбора составных документов из инструмента «Dashboard» и нажатия соответствующей кнопки. На вход обработчика поступает запрос, в котором хранятся идентификаторы необходимых документов и контракта.
В первую очередь, считываются атрибуты из категорий составных документов. Данный процесс проходит в цикле и записывает атрибуты из групп атрибутов в переменные, для дальнейшего использования в исходящем пакете документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Далее, необходимо собрать параметры формы, для формирования иерархической переменной и передачи данных через неё. Трудностью в использовании формы в программном коде было найти механизм редактирования атрибутов формы.
Затем происходит создание директории исходящего пакета документов, в соответствии с контрактом и проектом. В созданную директорию копируются документы исходящего пакета и экземпляр формы. Также, в директории создаётся сопроводительная ведомость и заполненная атрибутами документов. Стоит отметить, что скопированный экземпляр формы невидим для пользователя, в целях упразднения возможности редактирования.
Данные документов копируются в динамическую переменную и передаются в запускаемый веб-интерфейс.
«StartReview» выполняет функционал запуска маршрута согласования входящих пакетов документов. Основной трудоёмкостью в разработке данного объекта является работа с картами маршрутов согласования.
Перед инициализацией карты маршрута согласования необходимо заполнить атрибуты. Маршруты проектно-технической документации разделяются по критерию количества обработки документов. Для входящих пакетов документов с множественными документами создан маршрут с многозначными атрибутами и шагами их обработки. Это следует учитывать при создании обработчика запросов «StartReview».
Разработанный скрипт включает в себя считывание атрибутов из категорий каждого документа в пакете, переданного функции. После считывания атрибутов, создаётся экземпляр соответствующего маршрута согласования документов. Так, как атрибуты маршрута пронумерованы и нет возможности узнать имена атрибутов в теле функции, то приходится осуществлять заполнение атрибутов по номерам атрибутов без автоматического перебора. Для заполнения атрибутов различных маршрутов приходится разделять заполнение на две различных части кода.
По завершении заполнения атрибутов заполняются свойства маршрута. Затем инициируется экземпляр маршрута согласования и пакет документов переносится в директорию согласуемых пакетов документов. При наличии ошибок, экземпляр маршрута документов удаляется, а на выход функции передаётся соответствующая ошибка.
По завершении разработки всех обработчиков запросов, они регистрируются в подсистеме обработчиков запросов. Также необходимо осуществить сборку модуля путём запуска скрипта «BuildOSpace» в объекте «PTDocManager Globals». В объекте «Globals» хранятся сведения о всех объектах модуля.
Разработка веб-интерфейсов для программного модуля
В рамках разработки программного модуля регистрации документов стоит описать один из важнейших этапов – разработка веб-интерфейсов. Веб-интерфейсы помогут пользователю взаимодействовать с функционалом модуля.
Одним из важнейших критериев разработки веб-интерфейсов для платформы «OpenText Content Server 16.2» является соответствие веб-интерфейсов стилистике платформы и включение элементов веб-сервиса.
Для внедрения функционала платформы в создаваемые веб-интерфейсы, в платформе существует скрипт «web-script». Веб-скрипт позволяет обрабатывать данные передаваемые из методов серверной части. Он выполняется во время генерации веб-страницы на уровне серверной части. Веб-скрипт также позволяет запускать веб-интерфейсы других модулей с различными параметрами.
Строки кода веб-скрипта отличаются от стандартных языков веб-разработки наличием знака точки с запятой вначале строки. В случае наличия ошибок в веб-скрипте, веб-страница не может скомпилироваться и браузер выдаёт пустое окно.
Первым разработанным веб-интерфейсом является интерфейс запуска маршрута согласования документов. Разработанный веб-интерфейс изображён на рисунке на этапе проектирования и не отличается от прототипа веб-страницы.
В рамках разработки использовались следующие инструменты: «WebScript», язык гипертекстовой разметки «HTML», сценарный язык программирования «Javascript» с библиотекой «JQuery» и «CSS» стили.
Во время разработки веб-интерфейса использовано множество стандартных блоков платформы. В их числе объекты веб-страницы, называемые «head» и «footer». В стандартном заголовке веб-страницы находятся вкладки ресурсов системы. Также к числу стандартных блоков относятся рамки, в которых находятся селекторы для выбора значений и кнопки.
При помощи сценарного языка программирования осуществлена возможность добавления новых полей ввода, а также их редактирования. Функционал кнопок тоже реализован при помощи «Javascript».
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Каждое поле ввода включено в форму. При нажатии кнопки старта, происходит валидация данных формы с последующей отправкой. Отправка формы запускает обработчик запросов, имя функции которого указан в поле формы.
Следующий веб-интерфейс, который был разработан – это веб-интерфейс запуска методов работы с входящими пакетами документов. Интерфейс представляет собой веб страницу и используется как объект системы именуемый «Custom View». «Custom View» помогает внедрить дополнительный функционал для различных директорий.
Были разработаны изображения кнопок и взаимодействие кнопок с серверной частью путём выполнения «ajax» запросов. Сценарные действия также, как и в предыдущем интерфейсе, созданы при помощи библиотеки «JQuery».
Далее необходимо рассмотреть разработанный веб-интерфейс редактирования атрибутов исходящего пакета документов.
Основной задачей разработки данного интерфейса является реализация шаговой функциональности в рамках процесса регистрации исходящего пакета документов. Ключевой особенностью данного подхода является переключение между веб-интерфейсами без использования перезагрузки страницы.
Для реализации переключения шагов без перезагрузки веб-страниц был выбран элемент гипертекстовой разметки «frame». Рассматриваемый элемент позволяет запускать веб-страницы внутри блока, без изменений в родительской веб-странице.
Как и во всех остальных веб-интерфейсах, в программный код были включены стандартные блоки заголовков веб-страниц и рамок для блоков. Для передачи данных между страницами внутри фрейма, создана форма, обращаясь к которой из дочернего элемента можно передавать переменные значения.
Интерфейс редактирования атрибутов запускается во время загрузки страницы. Наиболее оптимальным методом редактирования атрибутов пакета является редактирование формы, присвоенной исходящему пакету документов.
Редактирование формы запускается стандартной функцией, открывающей экземпляр формы с возможностью редактирования. Для размещения стандартной веб-страницы внутри блока с фреймом, необходимо разработать представление формы без использования стандартных элементов заголовка и нижнего колонтитула так, как данные элементы уже задействованы в родительской веб-странице и размер рамки фрейма ограничен.
В связи с особенностями необходимого представления, оно было создано без использования веб-скриптов, только лишь с вызовом стандартного функционала через «Ajax» запросы. В результате получилось разработки представления для формы удалось исключить использование стандартных блоков для выполнения функции. После завершения масштабирования веб-интерфейса, удалось получить веб-интерфейс.
Следующий веб-интерфейс, который был разработан – это веб-интерфейс редактирования состава исходящего пакета документов. Основные трудности возникшие в процессе разработки веб-интерфейса были обеспечение возможности добавить документ в пакет документов и возможности изменения свойств элементов родительской веб-страницы.
Веб-интерфейс представляет собой список документов, включённых в пакет документов с возможностью добавлять документы в список и удалять добавленные элементы.
Список генерируется при помощи веб-скрипта, а функционал добавления и удаления документов реализован при помощи библиотеки «JQuery». Добавление документа происходит путём вызова диалогового окна, в котором отображаются директории системы с возможностью выбора документа.
Заключительный веб-интерфейс, разработанный в рамках разработки модуля регистрации документов, выполняет функцию составления списка получателей уведомления о регистрации исходящего пакета документов и обзора конечного состава документов исходящего пакета.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
В данном веб-интерфейсе объединяется функционал остальных веб-интерфейсов, связанных с регистрацией исходящих пакетов документов.
Основной сложностью при разработке рассматриваемого интерфейса является органичное совмещение блоков списка документов и селекторов для выбора получателей уведомлений.
Данные, которые необходимо отобразить, разделены на два блока. Фрейм, внутри которого происходит отображение веб-интерфейса не масштабируем, следовательно, принято решение внедрить динамическое вертикальное масштабирование блоков. Это позволяет вместить множество полей с данными в фиксированном по размеру блоке.
Все данные, передаются в веб-интерфейс с серверной части и генерируются в формате гипертекстовой разметки при помощи веб-скрипта. Выпадающие списки заполняются параметрами из матриц распределения, формируемых в серверной части.
В рамках веб-интерфейса также предусмотрено добавление множества получателей и редактирования данного списка.
Описание этапа разработки оставшихся веб-интерфейсов является не целесообразным так, как оставшиеся веб-интерфейсы типизированы и просты в разработке.
Разработка таблиц и хранимых процедур базы данных
Наиважнейшим этапом разработки является разработка объектов базы данных. К системе управления проектно-технической документации подключён сервер базы данных «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» доступно для данного столбца, потому что оно не является характеристикой маски.
Следующая таблица связывает справочник контрактов со справочником масок. Таблица содержит столбцы идентификаторов контрактов и идентификаторов масок. Также в таблице существует столбец типа маски по наличию ревизии. Наличие ревизии определяется значением столбца «MaskType»: 0 либо 1. В таблице запрещены значения «Null», во избежание возникновения неопределённостей.
Далее следует рассмотреть процесс разработки группы таблиц, хранящих данные о матрицах распределения получателей уведомлений.
В первую очередь, необходимо создать таблицу, хранящую информацию о матрице распределения. В соответствии с заданием, матрицы распределения должны подразделяться по следующим параметрам: номер документа, тип документа и его дисциплина.
Идентификатор матрицы задаётся столбцом «SystemID». Столбец является вычисляемым с начальным значением равным единице и шагом приращения идентификатора также равном единице. Также столбец является первичным ключом таблицы. Тип данных столбца – «Int».
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Параметр «DocumentNumber» задаётся в одноимённом столбце. Столбец имеет тип «nvarchar(64)» с максимальной длиной набора символов в 64 знака. Для столбца разрешено значение «Null» так, как параметр может не использоваться для определения матрицы.
Последний столбец таблицы отвечает за параметр тип документа и его дисциплина. Тип хранения данных ограничивает длину записи в столбце до 10 символов ввиду того, что параметры типа документов и его дисциплин ограничены длиной в два символа. Ограничение в 10 символов позволяет увеличивать размерность типа и дисциплины документа. В данном столбце разрешено значение «Null» по той же причине, что и в предыдущем столбце.
Таблица названа «EDMS_Directory_Matrix». «EDMS» — это название системы, слово «Directory» означает справочник, а слово «Matrix» указывает на разновидность содержимого таблицы.
После создания таблицы хранения матриц распределения, необходимо разработать таблицу, распределяющую роли для данных матриц.
Таблица называется «EDMS_Directory_MatrixRecipients» и хранит идентификаторы и роли пользователей для каждой матрицы распределения.
В таблице запрещены значения «Null», поскольку отсутствуют избыточные столбцы. Первым столбцом является уникальный идентификатор «SystemID. Свойства данного столбца идентичны свойствам одноимённого столбца в выше представленных таблицах.
Следующий столбец называется «MatrixID» и хранит значения идентификаторов матриц распределения. Тип данных столбца «Int».
Пользователи в матрицах распределения делятся на группы, различающиеся по ролям. Для осуществления данного разделения создан столбец «Role». Тип данных столбца «nvarchar(10)», поскольку роли обозначаются символами и значения ролей не превышают десяти символов.
Заключительный столбец рассматриваемой таблицы называется «Recipients». В него записываются значения идентификаторов пользователей с разделительным знаком точка с запятой. Тип данных столбца «nvarchar(MAX)» обуславливается тем, что количество пользователей, принадлежащих одной роли может варьироваться и принимать высокие значения.
Заключительная таблица, которую необходимо разработать – это таблица связи матрицы распределения и контракта.
Таблица названа «EDMS_Directory_Contracts_Matrix». В таблице запрещены значения «Null». В таблице содеражтся следующие столбцы предыдущих таблиц: «SystemID», «ContractID» и «MatrixID».
Уникальным столбцом в данной таблице является столбец «Description». Из названия столбца следует, что в нём хранится краткое описание матрицы распределения. Типом данных столбца является «nchar(10)». Тип данных строго ограничивает описание матрицы распределения десятью символами.
Значительная часть функционала программного модуля реализована на стороне сервера базы данных. Данное решение принято в целях сокращения временных издержек на обработку данных внутри программного модуля.
Функционал на стороне сервера базы данных реализуется в хранимых процедурах.
Первая хранимая процедура, разработанная в рамках разработки программного модуля регистрации документов, вычисляет крайние сроки для выполнения согласования пакета документов.
Входными параметрами процедуры являются: идентификатор контракта, код статуса задания и значение ревизии пакета документов.
Согласно этим параметрам, делается выборка из таблицы со сроками рассмотрения документов для каждой определённой задачи и ревизии документов контракта. Далее создаются переменные с временем рассмотрения задач для каждой роли маршрута согласования.
Для каждой роли выполняются подсчёты крайних сроков рассмотрения путём подсчёта рабочих дней в календаре и определения необходимого времени рассмотрения задач. Выходными данными рассматриваемой хранимой процедуры являются крайние сроки для каждой из роли в маршруте согласования. Далее эти данные передаются в обработчик запросов, предоставляющий данные веб-интерфейсу запуска маршрута согласования документов. Следующая хранимая процедура выполняет функцию выборки идентификаторов пользователей из матриц распределения.
В качестве входных параметров выступают следующие значения: идентификатор контракта, описание матрицы распределения, номер документа, тип документа, дисциплина и роль.
В соответствии с входными параметрами происходит выборка идентификаторов пользователей. Программный код хранимой процедуры изображён на рисунке ниже.
В программном модуле регистрации пакетов документов необходимо соблюдать строгость принадлежности директорий загрузки пакетов документов определённым контрактам. Для проверки соответствия директории загрузки пакетов документов разработана хранимая процедура под именем «EDMS_DEDValidateContract».
Входными параметрами процедуры являются идентификатор контракта и идентификатор директории.
Процедура проверяет принадлежность директории контракту и отправляет выходными параметрами значение 0, 1 или 2. 1 соответствует ошибке отсутствия контракта в базе данных, 2 соответствует ошибке принадлежности директории контракту, а 0 возвращается при отсутствии ошибок.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Следующая хранимая процедура выполняет функцию проверки ревизии документа.
На вход функции поступают параметры: имя документа и ревизия документа. При существовании документа с переданной ревизией, на выход передаётся код ошибки 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» — каталог пакетов документов, не прошедших валидацию.
Следующий этап – заполнения базы данных.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Для заполнения таблиц базы данных необходимо определить список таблиц, которые необходимы для работы программного модуля. Составление списка является трудоёмким процессом, поэтому решено заполнять таблицы в соответствии с функциями, выполняемыми в программном модуле в исходном порядке.
Первая таблица – «EDMS_Config_Module_PTTransmittalExt». Данная таблица использовалась в предыдущей версии системы для одноимённого модуля. Таблица представляет собой справочник со столбцами «key» и «value». В соответствии с программным кодом модуля, в таблицу необходимо добавить значения: идентификатора категории проектно-технической документации «DEDCategoryID», идентификатора маршрута согласования «DEDWorkflowMapID», идентификатора пакетного маршрута согласования «DEDPackageWorkflowMapID», идентификатора представления директории загрузки «DocToProceedCustomView», идентификатора формы исходящего пакета документов «OutgoingPacketForm» и идентификатора шаблона сопроводительной ведомости исходящего пакета документов «OutgoingTemplateID».
Следующая таблица называется «EDMS_Directory_Contracts» и хранит в себе контракты и их свойства. Необходимо добавить тестовый контракт, для осуществления работы программного модуля, в частности, почти всех его функций.
В рамках тестирования функционала программного модуля регистрации документов, создан контракт с идентификатором «TEST 1001-0092-000-00002». Для работы с модулем необходимо задать свойства контракта.
Первые свойства – это идентификаторы каталога загрузки пакетов документов и каталога пакетов документов, не прошедших валидацию в системе.
Для загрузки и выгрузки пакетов документов, прописываются пути к соответствующим директориям на сервере. Также необходимо указать идентификаторы шаблона текста уведомления о регистрации исходящего пакета документов и шаблона сопроводительной ведомости входящего пакета документов. Последними свойствами указываются идентификаторы актива, проекта, времени на рассмотрения и наименований контракта.
Тестирование модуля регистрации документов
В рамках тестирования модуля регистрации документов необходимо выделить этапы тестирования. В соответствии с распределением функционала программного модуля, выделяются два этапа: тестирование программного модуля и тестирование веб-интерфейсов. Проводить тестирование хранимых процедур нет необходимости, ввиду того, что программный код хранимых процедур отлажен на этапе разработки программного модуля.
Основной функцией разработанного модуля является регистрация входящих пакетов документов. Из этого следует, что в первую очередь необходимо протестировать регистрацию входящих пакетов документов. Для тестирования функционала модуля созданы тестовые сценарии работы с пакетами документов.
В соответствии с разработанными тестовыми сценариями, необходимо создать пакеты документов. Пакеты документов созданы по мере прохождения тестовых сценариев.
Далее следует рассмотреть созданные тестовые сценарии и результаты их запусков в системе управления технической документацией.
Первый сценарий описан в таблице 3.1.
Таблица 3.1. Проверка на наличие сопроводительной ведомости
В рамках выполнения данного сценария, отклонения в работе программного модуля выявлено не было.
В соответствии с тестовым сценарием, скрипт валидации входящего пакета документов загрузил пакет документов в директорию входящих документов, но, обнаружив отсутствие сопроводительной ведомости, произошло перемещение пакета документов в каталог отклонённых документов. Пользователь получает окно с описываемой ошибкой и уведомление на электронную почту об ошибке пакета документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Следующий тестовый сценарий также выполняет функцию проверки на наличие сопроводительной ведомости. В данном случае проверяется наличие копии сопроводительной ведомости в формате «pdf». Тестовый сценарий идентичен сценарию проверки табличной ведомости, следовательно, повторное описание сценария является не целесообразным.
После проверки наличия сопроводительной ведомости, необходимо проверить состав пакета документов по данным ведомости.
Проверка наличия документов в пакете документов заключается в синтаксическом анализе сопроводительной ведомости и выявления состава пакета документов.
Тестовый сценарий для проверки валидации состава входящих пакетов документов похож на предыдущие тестовые сценарии, но включает действия по редактированию данных сопроводительной ведомости. Тестовый сценарий проверки данного функционала представлен в таблице 3.2.
Таблица 3.2. Проверка состава пакета документов
Как и в выше рассмотренных тестовых сценариях, пользователь должен получать похожие результаты при прохождении теста, однако сообщение об ошибке будет иное.
В результате проведения рассматриваемого теста, выявлено непредсказуемое поведение разработанного функционала. После запуска тестового пакета документов было выявлена ошибка поведения, при которой тестовый пакет документов проходил валидацию. Функционал программного модуля необходимо исправить на этапе доработки исходного кода.
В завершение тестирования валидации состава входящих пакетов документов создан тестовый сценарий проверки имён документов в соответствии с масками контрактов.
Проверка функционала при помощи тестовых сценариев выявило непредсказуемое поведение в отображении ошибки для пользователя и определения маски контракта для входящего пакета документов. Выявленные в процессе тестирования, ошибки исправлены на этапе доработки. Тестовый сценарий проверки функционала представлен в таблице 3.3.
Таблица 3.3. Проверка документов в пакете на соответствие названий маскам
Далее следует рассмотреть тестовые сценарии поведения программного модуля при валидации входящих пакетов документов по статусу рассмотрения и ревизии. Процесс валидации входящих пакетов документов по статусу рассмотрения и ревизии является важным, поскольку он позволяет избежать возникновения избыточных данных. Это достигается проверкой на существование загружаемых пакетов документов в системе управления проектно-технической документацией.
Таблица, отображающая шаги тестового сценария проверки статуса рассмотрения входящего пакета документов, представлена ниже.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Таблица 3.4. Проверка статуса рассмотрения документа
В ходе проведения тестирования, отклонений от тестового сценария не выявлено. Контрольный пакет документов был обнаружен на этапе проверки атрибутов пакета документов и перемещён в каталог отклонённых пакетов документов.
В комплексе с проверкой статуса пакета документов проходит валидация ревизий документов. Ревизии также проверяются у одноимённых документов, если таковые существуют. Для проведения тестирования валидации ревизий входящих пакетов документов, проведён полный цикл согласования, созданного пакета документов. Созданный пакет прошёл процедуру согласования и каждый документ получил ревизию.
Рассматриваемый пакет документов не был изменён, для того чтобы пройти действия, указанные в тестовом сценарии в таблице 3.5.
В ходе тестирования валидации ревизии документов, не было выявлено непредсказуемого поведения программного модуля.
Таким образом, выявлено, что ошибок, связанных с согласованными документами, в программном коде функций валидации входящих пакетов документов, в ходе первичного тестирования, не найдено. Доработки функций валидации ревизии и статуса документов, в рамках выпускной квалификационной работы, не будет.
Таблица 3.5. Валидация ревизий документов
Заключительным тестовым сценарием проверки функционала по работе с входящими пакетами документов, является сценарий проверки запуска маршрута согласования документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
В рамках рассматриваемого функционала необходимо провести тестирование как серверной части программного модуля, так и клиентской. В ходе тестирования процесса запуска маршрута согласования выявлено следующее: расположение блоков веб-интерфейса не соответствует прототипу, из-за проблемы с отображением данных в веб-интерфейсе, запуск маршрута согласования является невозможным, список документов не соответствует составу пакета документов.
Для проведения теста в системе был зарегистрирован корректный пакет документов. Зарегистрированный пакет документов содержит более одного документа, что позволяет протестировать функции отображения атрибутов нескольких документов и обширного числа самих документов. Также, это позволяет протестировать функционал запуска пакетного маршрута согласования документов и присвоения ему атрибутов из категорий документов.
В соответствии с тестируемым функционалом, создан тестовый сценарий, при помощи которого удалось выявить выше описанные ошибки в работе программного модуля. Тестовый сценарий представлен в таблице 3.6.
Таблица 3.6. Тестирование запуска маршрута согласования
В заключение тестирования функционала обработки входящих пакетов документов, выявлено, что программный модуль регистрации документов нуждается в доработке. Также необходимо доработать разметку и логику сценария веб-интерфейса запуска маршрутов согласования.
Заключительным этапом тестирования является проверка функционала регистрации исходящего пакета документов.
В качестве контрольных пакетов документов для тестирования процесса регистрации исходящих пакетов документов выступают документы, прошедшие процесс согласования на предыдущих этапах тестирования.
Во время тестирования функционала регистрации исходящих пакетов документов, происходит тестирование как веб-интерфейсов, так и программного кода серверной части программного модуля.
Тестирование регистрации исходящих пакетов документов подразделяется на два этапа: тестирование обычного пакета документов и тестирование пакета документов с комментариями согласующих. Описание тестового сценария представлено в таблице 3.7.
Таблица 3.7. Тестирование создания исходящего пакета документов
По завершении тестирования процесса регистрации исходящего пакета документов выявлено следующее: отображение интерфейса редактирования формы не соответствует прототипу, запрограммированные сценарии в веб-интерфейсе редактирования состава документов работают не корректно (документы не добавляются в список, список не масштабируется относительно кол-ва объектов), уведомление о регистрации исходящего пакета документов не отсылается, пакет документов не выгружается на «FTP» сервер.
Исходя из выше перечисленных неисправностей, можно заключить, что основной функционал процесса регистрации исходящего пакета документов работает и необходима доработка лишь косвенных фрагментов программного модуля.
Процесс регистрации исходящего пакета документов с комментариями происходит однотипно, за исключением того, что в состав пакета документов входят комментарии согласующих, и процесс регистрации происходит с учётом параметров исходящего пакета документов с комментариями. Тестовый сценарий представлен в таблице ниже.
Таблица 3.8. Тестирование создания исходящего пакета документов с листом комментариев
В ходе тестирования регистрации исходящего пакета документов с файлом комментариев выявлены те же ошибки, что и без файла с комментарием. Из этого следует, что в доработке процесса регистрации исходящего пакета документов с комментариями нет необходимости.
В завершение тестирования программного модуля необходимо составить таблицу выявленных неисправностей, для последующей доработки. Стоит отметить, что ключевые функции разработанного функционала прошли тестирование без выявления непредсказуемого поведения. Следовательно, можно утверждать, что проект программного модуля разработан достаточно информативно, для реализации разработки для платформы «OpenText Content Server 16.2». Доработки, которые необходимо провести по результатам тестирования перечислены в таблице 3.9.
Таблица 3.9. Результаты тестирования
Таким образом, проведено тестирование функционала программного модуля и выявлены объекты, нуждающиеся в доработке.
Доработка программного модуля регистрации документов
Жизненный цикл дополнительного функционала системы управления проектно-технической документацией проходит по «V-образной» модели жизненного цикла программного обеспечения.
В ходе написания данной работы описываются лишь некоторые пункты жизненного цикла системы управления проектно-технической документацией ввиду узкой определённости цели работы.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Исходя из используемой модели жизненного цикла программного обеспечения каждая доработка программного модуля после тестирования проходит этап по проверке соответствия проекту разрабатываемого программного решения. Далее происходит исправление программного кода и повторное тестирование.
В соответствии с моделью, каждая доработка должна соответствовать новой версии модуля. Иначе, проведение процесса доработки программного модуля является малоэффективным с точки зрения использования временных затрат и управления обновлениями системы.
Доработки программного модуля осуществляются в хронологическом порядке в соответствии с таблицей ошибок, представленной в предыдущем параграфе.
Первая доработка связана с методом «PacketValidation». Для обнаружения ошибки непосредственно в программном коде, проведён повторный запуск тестового сценария в режиме отладки сервиса.
Ошибка в проверке состава входящего пакета документов заключается в специфике именования объектов платформы «OpenText Content Server 16.2». Непредсказуемое поведение было устранено путём изменения подхода к выбору именной части документов.
Изменения программного кода модуля сохранены в новой версии модуля. Новая версия присваивается модулю аналогично процедуре установки модуля, но обновление модуля происходит после соответствующих манипуляций на странице администратора сервиса.
Следующая неисправность касается отображения блоков редактирования атрибутов в веб-интерфейсе запуска маршрута согласования документов.
В ходе отладки метода «SendForReview» неисправностей программного кода не обнаружено. Таким образом следует, что неисправности отображения блоков не зависят от передаваемых веб-интерфейсу данных.
Выяснено, что неправильное отображение блоков редактирования данных зависит от несоответствия стилей веб-интерфейса стилям платформы. Неисправность устранена путём присвоения элементам веб-интерфейса стандартных стилей платформы. Все изменения также были сохранены в новой версии модуля.
Наиболее трудоёмкой доработкой функционала является исправление недоработок веб-интерфейса редактирования формы с атрибутами пакетов документов. Трудоёмкость доработки заключается в диагностике кода разметки и сценария веб-страницы. Диагностика веб-интерфейса не возможна при помощи отладки программного модуля так, как редактирование формы происходит при помощи стандартного функционала.
Неисправности выявлены в скрытии стандартного функционала представления редактирования формы и в вызове стандартного функционала через разработанные элементы представления.
В качестве доработки представления выступает редактирование верхнего колонтитула: убран вызов функции отображения стандартного верхнего колонтитула. Для доработки вызова стандартных функций, изменены алгоритмы генерирования параметров. После повторного тестирования, непредсказуемого поведения не обнаружено.
Следующие две неисправности касаются редактирования состава исходящего пакета документов во время его регистрации. Обе неисправности происходят в одном веб-интерфейсе и заключаются в некорректной работе со списком документов.
Отладка обработчика событий, запускающего веб-страницу, не выявила непредсказуемого поведения функции. Из отладки программного кода сценария веб-страницы выявлены ошибки в вызове стандартных функций выбора документов и в определении стилей списка документов. Неисправности доработаны путём исправления ошибок в алгоритмах добавления документов в список и присваиванием свойств масштабируемости элементам списка документов.
Заключительные доработки, которые необходимо предпринять на данном этапе касаются обработчика событий «ReturnToFtp». Так, как обработчик событий выполняется на серверной части сервиса, то детализация ошибки происходит при помощи запуска соответствующих тестовых сценариев в режиме отладки сервиса.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Последние две ошибки, указанные в таблице 3.9 находятся в одной части обработчика событий, соответственно, присутствует возможность их одновременного исправления.
Для диагностики проблемы с отправкой уведомлений получателю, первым делом, заменён шаблон уведомления о регистрации исходящего пакета документов на упрощённый вариант, включающий в себя лишь адресат, которому отправляется уведомление. Так, как уведомление дошло до адресата, следовательно, причиной возникновения непредсказуемой ситуации является шаблон уведомления. Из шаблона уведомления решено убрать программный код сценария электронного письма, поскольку обработчик писем принимает программный код сценарных языков программирования веб-страниц как атрибуты и параметры, передаваемые при заполнении шаблона.
Неисправность в выгрузке исходящих пакетов документов удалось выявить сразу на этапе отладки соответствующего функционала. Ошибка заключается в формате пути на «SFTP» сервер, передаваемом из базы данных. Для исправления ошибки, было заменено значение в базе данных.
Таким образом, в заключительной главе проведено тестирование программного модуля регистрации документов и исправлены недоработки, выявленные при тестировании. Создано семь версий программного модуля, в соответствии с количеством доработок.
Заключение
В ходе написания выпускной квалификационной работы были приобретены навыки анализа, проектирования и разработки программных модулей платформы «OpenText Content Server 16.2». В частности, приобретены навыки проектирования процессов при помощи языка моделирования UML и разработки на языках программирования «OScript» и «JavaScript».
В основной части выпускной квалификационной работы были решены задачи, представленные во введении.
Проанализирована предметная область и созданы функциональные требования. Функциональные требования в дальнейшем были специализированы при помощи описания сценариев вариантов использования.
Задача построения диаграммы прецедентов была решена на этапе анализа. На основе сценариев прецедентов созданы связи между ними и актерами. Конечная диаграмма прецедентов отобразила концептуальное поведение проектируемого модуля регистрации документов.
Созданы диаграммы активности, являющиеся декомпозицией прецедентов в рамках их поведения. Диаграммы активности помогли смоделировать приблизительное поведение самих прецедентов.
Построены схемы последовательности, с помощью которых определены основные субъекты, отвечающие за работу программного модуля регистрации документов и взаимодействие с пользователем.
При помощи обобщения диаграмм последовательности, была сгенерирована схема классов. Схема классов показывает смоделированное желаемое поведение модуля регистрации документов и его составляющих.
Последним этапом проектирования было проектирование веб-интерфейсов и таблиц базы данных для модуля регистрации документов. На прототипах веб-интерфейсов изображены методы взаимодействия пользователя с модулем регистрации документов.
Разработан программный модуль регистрации документов в соответствии с архитектурой платформы «OpenText Content Server 16.2».
Разработаны хранимые процедуры, распределяющие нагрузки на программный модуль регистрации документов.
Нужна помощь в написании магистерской?
Мы - биржа профессиональных авторов (преподавателей и доцентов вузов). Сдача работы по главам. Уникальность более 70%. Правки вносим бесплатно.
Разработаны веб-интерфейсы, в стандартном стиле, осуществляющие взаимодействие между пользователем и сервисом.
Разработанный программный модуль протестирован и доработан до седьмой версии.
Задача описания процесса разработки программного модуля регистрации документов в ходе написания выпускной квалификационной работы является завершённой.
Данная работа используется на демонстрационном стенде компании ООО «Парма-Телеком» и может быть в дальнейшем использована в различных проектах выше указанной компании.
Список использованных источников
1. M. Isaeva, H. Young Paperless university – how we can make it work? 2016 15th International Conference on Information Technology Based Higher Education and Training (ITHET)
2. Open Text Corporation LiveLinkSdk – LiveLink Module Development Guide. 2008.
3. Open Text Corporation Open Text Content Server User Online Guide. 2010.
4. Алан Купер Психбольница в руках пациентов// М.: Символ-Плюс, -2004, -336с.
5. Алексеев А.П. Введение в Web-дизайн: учебное пособие// М.: СОЛОН-ПРЕСС, -2008, -384с.
6. Вора П. Шаблоны проектирования веб-приложений/ Пер. с англ. Райтман М. А. М.: Эксмо, -2011.
7. Белли Л. Изучаем SQL: Учеб. пособие. СПб: Питер, 2012. – 401с.