32
2.2.2. Характеристика нормативно-справочной, входной и
оперативной информации
Нормативно-справочную информацию для функционирования системы,
для исключения дублирования информации будем получать через
интеграционный слой из мастер-систем. Основные нормативные документы,
регламентирующие деятельность технической поддержки и права пользователей
описаны во внутренних нормативных документах: ТС-345, ВНД 9005. Входные
данные о пользователях будут заполнены автоматически- источники и типы
интеграции представлены в таблице 3.
Атрибут
Источник
Тип интеграции
Доменная учетная
запись
Каталог Active Directory
Модуль Spring
Security
Почтовая учетная
запись
Каталог Active Directory
Модуль Spring
Security
ФИО
На основе данных учетной записи ,запрос
информации из SAP HR
SAP API
Принадлежность
к структурному
подразделению
На основе данных учетной записи ,запрос
информации из SAP HR
SAP API
Телефон
На основе данных учетной записи ,запрос
информации из SAP HR
SAP API
IP-адрес
Информация из операционной системы
пользователя
Стандартный
протокол
MAC-адрес
Информация из операционной системы
пользователя
Стандартный
протокол
Таблица 3 – источники данных для наполнение данными системы
33
2.2.3. Характеристика результатной информации
На первом этапе над базой будет построен отчет на основе Oracle Apex -
Oracle Application Express (сокращённо именуется как Oracle Apex, APEX) —
проприетарная среда быстрой разработки прикладного программного
обеспечения на основе СУБД Oracle Database, целиком реализованная как веб-
приложение. Все элементы, возникающие в цикле разработки приложения в
данной среде хранятся непосредственно в инфраструктуре Oracle Database.
Oracle Apex позволяет настроить отображение отчётов в любой форме в
несколько кликов.
Будут настроены два типа отчетов:
Отчет «Заявки»
Отчет «Решения по заявкам».
Пример настроенного отчета показан на рис.8
Отчет о заявках в системе рис.8
34
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
На рис. 9 отображено дерево функций модулей, используемых в данной
информационной системе.
Рисунок 9 - Дерево функций информационной системы
Структура сценария диалога в совокупности с деревом функций, которое
отражает состав и иерархию функций системы, дает возможность определить
состав формы диалога, содержание каждой формы и их подчиненности.
Начало работы
Аутентификация
Служебные функции
Выбор подсистемы
Администратор
Проверка
ссылочной
целостност
и БД
Администрирова
ние ролей и прав
Отчеты
Создание заявки
Список заявок
Пользователь
Формирование
отчетности по
заявкам
Форма поиска и
создания заявок
Доступ к списку текущих
заявок
Отчеты
Ввод справочников
Заведение шаблонов заявок
35
Сценарий диалога представлен на рис. 10.
Рисунок 10 – Структура диалога системы
Сценарий взаимодействия пользователя с системой состоит из двух типов меню:
Основные меню предполагают обязательные действия пользователя при
работе с ИС. Основное меню, относится к головному, то есть те экраны
Вход в систему
1. Аутентификация
1.2. Пользователь
2. Форма для поиска шаблона
3. Список текущих заявок
2. Форма поиска шаблона
2.1 Поле ввода для поиска
2.2 Варианты шаблонов
1.Аутентификация
1.1.Администратор
1.2.Пользователь
3. Список текущих заявок
2.2.1 Выбор шаблона
2.1 Форма для заполнения
36
меню, которые видит пользователь, прежде чем приступить к выполнению
основных функций, согласно дереву функций.
Сервисное меню предполагает возможные действия, одно из которых
может являться необязательным к выполнению. Сервисное меню, которое
доступно конечному пользователю после того, как выдана на экран
соответствующая форма документа.
Иерархии функций управления является важным этапом при разработке
программного продукта, а также важно описание и обработка данных.
2.3.2. Характеристика базы данных
ER-модель — модель данных сущность- связь, позволяющая описывать
концептуальные схемы.
Данная модель удобна при проектировании информационных систем, баз
данных, архитектур компьютерных приложений, и других систем (далее,
моделей). С её помощью можно выделить ключевые сущности, присутствующие
в модели, и обозначить отношения, которые могут устанавливаться между этими
сущностями.
ER-модель является одной из самых простых визуальных моделей данных
(графических нотаций). Она позволяет обозначить структуру в общих чертах.
СУБД, используемая в банке – Oracle Database 12c.
Описание таблиц ER-модели представлено в табл. 4 - 7.
Таблица 4. Менеджеры пользователей
Наименование
поля
Идентификатор поля
Тип поля
Длина
поля
Прочее
ID_Пользователя
IDПользователя
число
4
Первичный
ключ –
ключевое поле
(PK)
Наименование
Пользователя
НаименованиеПользователя
строка
0
37
Таблица 5. Менеджеры пользователей
Наименование
поля
Идентификатор поля
Тип поля
Длина
поля
Прочее
ID_Менеджера
IDМенеджера
число
0
Первичный ключ
– ключевое поле
(PK)
ФИО Менеджера
ФИОМенеджера
Строка
30
Аналитическая
информация
АналитическаяИнформация
число
4
Таблица 6. Первичная связь с пользователем по заявке
Наименование
поля
Идентификатор поля
Тип поля
Длин
а
поля
Прочее
ID_Документа
IDДокумента
число
4
Первичный
ключ – ключевое
поле (PK)
Наименование
Заявки
НаименованиеЗаявки
строка
0
Тип Источника
ТипИсточника
Строка
30
Менеджер
пользователя
Менеджер Клиента
Строка
FK1
Таблица 7. Обратная связь пользователя по заявке
Наименование
поля
Идентификатор поля
Тип поля
Длина
поля
Прочее
ID_Документа
IDДокумента
число
4
Первичный ключ –
ключевое поле (PK)
Наименование
Наименование
строка
0
Тип Источника
ТипИсточника
Строка
30
Менеджер
пользователя
Менеджер Клиента
Строка
FK1
2.3.3. Структурная схема пакета
38
Дерево программных модулей отражает структурную схему пакета, содержащего
программные модули различных классов:
модули, выполняющие служебные функции;
управляющие модули, предназначенные для загрузки меню и передачи
управления другому модулю;
модули, связанные с вводом, хранением, обработкой и выдачей информации.
Дерево программных модулей, составляющих структуру основного пакета
представлено на рис. 11.
Рисунок 11 – Структурная схема основного пакета
2.3.4. Описание программных модулей
Алгоритм функционирования системы представлен на рис. 12
Форма аутентификации
Главная форма
Форма пользователя
Подсистема работы
со справочниками
Модуль визуализации
данных
Подсистемы работы
с заявками
Модуль
визуализированных
данных
Подсистема работы с
отчетами
Модуль визуальных
эффектов
Модуль
тестирования БД
Модуль проверки
загружаемой
информации на
ошибки
Начало
Модуль интеграций с
API HP Service manager
Модуль интеграций с
Active Directory, SAP HR
39
Рисунок 12 - Алгоритм функционирования системы
2.4. Контрольный пример реализации проекта и его описание
Для ИС разработаны следующие справочники:
Занесение запроса на
разблокировку
CASE:Выбор
операции
Регистрация запроса
на cброс
Утверждение
заявки на право
разблокировки
Рассмотрение прав
доступа на уровне
объектов
Конец
Определение
приоритета прав
Запуск скрипта
разблокировки
Формирование
отчета
пользователю
Отказ в
выполнении
Разрешено
Запрещено
40
Заявки
Отчеты
Справочники
Пользователи
Специалисты ИБ
В информационной системе были спроектированы и разработаны
следующие документы, регистры и находящиеся в них бизнес-логика для ИС:
Форма «Заявка»
Форма «Решение по заявке»
В ходе разработки прикладного решения были созданы следующие отчеты:
Отчет о заявках;
Отчеты о решениях;
Работа с информационной системой начинается с ввода на уровне базы
шаблонов заявок. Для функционирования системы предусмотрены необходимые
справочники и собственные таблицы для регистрации событий и заявок. Данные
вводит администратор с правами на запись в базу.
Далее приведены несколько Usecase-ов для демонстрации работы системы.
В дальнейшем подразумевается расширение списка интеграций и совместимых
систем, а также расширение шаблонов под них.
1.Use case заявки авторазблокировка:
1. Пользователь через форму поиска находит необходимый шаблон.
2. Система в автоматическом режиме заполняет поля формы:
ФИО
Подразделение
Логин домена
3. Пользователь отправляет форму на обработку.
4. Система формирует запись в базе данных.
5. Запускается скрипт PowerShell на Windows сервере в автоматическом
режиме выполняет разблокировку пользователя на домене.
Листинг-скрипта приведен в приложении
2.Use case заведение дефекта на ПО:
1. Пользователь через форму поиска находит необходимый шаблон с ПО.
41
2. Система в автоматическом режиме заполняет поля формы:
ФИО
Подразделение
Логин домена
Комментарии
3. Пользователь отправляет форму на обработку.
4. Система формирует запись через API HP Service Manager заводит инцидент
на 3 линию поддержки ПО.
Программный код приведен в приложении.