Файл: Основы проектирования программ. Этапы создания программного обеспечения (ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБРАСТИ ПРОЕКТИРОВАНИЯ ПРОГРАММЫ).pdf

Альтернативная последовательность (Специалист не взял с собой пропуск):

• Архивариус нажимает на кнопку «Отмена»;
• Возвращает документ Специалисту.

Альтернативная последовательность (База данных недоступна):

• Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
• Перенаправляет на главную страницу платформы.

Альтернативная последовательность (Архивариус выбирает часть листов):

• Архивариус выбирает часть листов для выдачи;
• Подтверждает выбор нажав на кнопку «Далее»;
• Система открывает окно проверки пропуска;
• Специалист прикладывает пропуск к датчику;
• Система считывает данные пропуска;
• Отображает имя специалиста в окне проверки пропуска;
• Специалист нажимает на кнопку «Вернуть»;
• Устанавливает фамилию, кто возвратил документ;
• Устанавливает дату возврата;
• Отмечает листы, которые вернул специалист.

Альтернативная последовательность (Специалист сдает больше 1 документа):

• Архивариус выбирает другой документ в заявке;
• Нажимает на кнопку «Вернуть».

Альтернативная последовательность (У специалиста больше 1 заявки):

• Архивариус нажимает на кнопку «Поиск»;
• Система открывает диалоговое окно поиска активной заявки по обозначению документа;
• Архивариус вводит обозначение документа;
• Нажимает на кнопку «Подтвердить»;
• Система отфильтровывает заявки, в которых выдан документ с введённым обозначением;
• Выделяет первую в списке заявку;
• Загружает список документов по заявке.

Рис. 18. Возврат документов

Рис. 19. Окно поиска заявки по документу

Название прецедента: Регистрация технической документации

Действующее лицо: Оператор

Предусловия: Оператор авторизован и в браузере открыта страница ИС Архив

Краткое описание: Оператор открывает окно регистрации документа, заполняет его данными и подтверждает сохранение данных

Главная последовательность:

• Оператор нажимает на кнопку «+»;
• Система открывает окно регистрации документа;
• Оператор вносит все необходимые данные;
• Нажимает на кнопку «Подтвердить»;
• Система проверяет наличие подобного документа в базе данных;
• Заносит данные в базу данных;
• Открывает сообщение: «Документ зарегистрирован».

Альтернативная последовательность (База данных недоступна):

• Система открывает сообщение: «В данный момент работа в системе производится не может, т.к. база данных недоступна»;
• Перенаправляет на главную страницу платформы.

Альтернативная последовательность (Документ уже есть в базе данных):

• Система открывает сообщение: «Данный документ уже зарегистрирован».

Рис. 20. Регистрация технической документации

Рис. 21. Схема интерфейса техника

Рис. 22. Окно регистрации документа

2.3 База данных

Информационная система разрабатывается с использованием табличного пространства платформы «Базис» (таблицы с приставкой AP_). Включает в себя таблицу с пользователями, группами, ролями, правами доступа, задачами и т.д. Второе табличное пространство принадлежит разрабатываемой ИС Архив (таблицы с приставкой Z_ARCH_). Результирующее табличное пространство было получено путем нормализации таблицы изображенной на рисунке 23. База данных должна содержать информацию о различных технических документах, кто зарегистрировал и изменил запись в БД, кому выдан тот или иной экземпляр (при наличии нескольких экземпляров).

Рис. 23. Первоначальная таблица с данными о документах архива

На первом шаге произведено удаление повторяющихся групп.

Рис. 24. Таблица с данными о документах архива в 1 нормальной форме (НФ)

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

Рис. 25. Таблица с данными о документах архива в 2 НФ

Рис. 26. Таблица с данными о истории изменения записей в таблице с документами в 2 НФ

Рис. 27. Таблица с заявками на получение документов в 2 НФ

Рис. 28. Таблица с документами из заявок в 2 НФ

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

Рис. 29. Таблица с списками в 3 НФ

В ходе нормализации было получено 5 таблиц и 2 таблицы из табличного пространства платформы Базис:

• Таблица AP_USERS – содержит информацию о пользователях платформы;
• Таблица AP_GROUP – содержит информацию об организационном дереве (подразделениях);
• Таблица Z_ARCH_DOC - главная таблица системы, содержит информацию о документах;
• Таблица Z_ARCH_HISTORY - содержит информацию о истории изменений документов в БД;
• Таблица Z_ARCH_REQ - содержит информацию о заявках пользователей на получение документов;
• Таблица Z_ARCH_REQ_DOC - содержит информацию о документах, входящих в состав заявки;
• Таблица Z_ARCH_LISTS - справочник возможных статусов документов, причин для получения документов, статусов заявок, видов документов, процессов, признаков, признаков применяемости.

Итоговый вариант схемы базы данных изображен на рисунке 30.

Рис. 30. Схема базы данных системы в 3 НФ

ГЛАВА 3. РАЗРАБОТКА ИНТЕРФЕЙСА ПРОГРАММЫ

3.1 Интерфейс системы

На основе макетов, был разработан пользовательский интерфейс, представляющий собой jsp файл. Для каждой роли предусмотрен набор блоков, каждый из которых будет загружен в зависимости от роли текущего пользователя, благодаря использованию тегов jstl. Интерфейс главного окна для роли «Техник» представлен на рисунке 31.

Рис. 31. Интерфейс главного окна системы для роли «Техник»

Листинг 1. Отображения блока для роли «Техник»

<c:if test='${role == "Техник"}'><div id="tableDoc"></div><div class="panel-footer">

<input type="button" value="Отметить все" class="btn btn-success btn-sm" onclick="checkAllRows()"><input type="button" value="Снять выделение" class="btn btn-danger btn-sm" onclick="uncheckAllRows()"></div></c:if>

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

Рис. 32. Интерфейс главного окна системы для роли «Архивариус»

Рис. 33. Интерфейс главного окна системы для роли «Специалист»

Рис. 34. Окно поиска документов

Рис. 35.Окно создания заявки

Рис. 36. Окно выбора листов

Рис. 37. Окно проверки пропуска

Рис. 38. Окно просмотра, кому выдан документ

Рис. 39. Окно поиска заявки по обозначению документа

Рис. 40. Окно регистрации документа (Чертежа)

Рис. 41. Окно просмотра истории изменений документа

Рис. 42. Окно просмотра списка должников

Спроектированный и разработанный интерфейс позволяет с легкостью регистрировать и изменять данные о технических документах, создавать и обрабатывать заявки на получение документов, а также отслеживать должников по возврату документов. Серверная часть представляет собой набор классов-сервлетов не связанных друг с другом. Обмен данными с сервлетами происходит по методу запрос-ответ. Каждый класс создаёт своё подключение к БД, выбирает или вносит данные и закрывает подключение, при каждом успешном обращении к нему [приложение 3].

3.2 Тестирование

Работоспособность системы была проверена в браузере FireFox Developer Edition 57 и InternetExplorer 11.

Рис. 43. Отображение основной страницы в браузере FireFox

Рис. 44. Отображение основной страницы в браузере InternetExplorer

Рис. 45. Отображение уведомлений

Рис. 46. Ввод некорректной информации в поле

Функциональное и нагрузочное тестирование было проведено работниками отдела главного технолога (ОГТ) во время опытно-промышленной эксплуатации. Максимальное количество активных пользователей системы в один момент времени не превышает 62 пользователя.

3.3 Опытно-промышленная эксплуатации

По поручению руководства предприятия АО «ОДК-Авиадвигатель» функциональное тестирование было совмещено с опытно-промышленной эксплуатацией (ОПЭ) [приложение 4]. ОПЭ проводилось в ОГТ и в бюро технической документации (БТД) предприятия в период с 23.11.2017 по 12.12.2018, принимали участие 137 сотрудников. За это время было зарегистрировано 232310 документов, 1075 заявок и 1030 документов прикреплены к заявкам.

По результатам ОПЭ был выпущен акт [приложение 5] о завершении ОПЭ программного обеспечения ИС «Архив». В дальнейшем ИС «Архив» будет внедрена в промышленную эксплуатацию.

ЗАКЛЮЧЕНИЕ

В ходе выполнения работы были исследованы процессы выдачи и возврата документации в бюро технической документации (БТД), которые были отражены в idef0 диаграммах. Были проанализированы аналоги, рассмотрена платформа Базис и средства реализации, на основе которых сформулированы требования к разрабатываемой системе. Были спроектированы и разработаны интерфейс пользователя (6 javascript файлов, 1 css, 1 jsp), табличное пространство (5 таблиц) и серверная часть (63 класса-сервлета). В сумме было написано 12176 строк кода.

Разработанная ИС получила название «Архив» и была интегрирована в платформу Базис, благодаря использованию api и табличного пространства платформы.

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

СПИСОК ЛИТЕРАТУРЫ