ПЗ (1203263), страница 5

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

Текст из файла (страница 5)

В блоке «Обработка заявки» входными данными являются «Назначенная заявка», механизмы – «Сотрудник тех. поддержки 1 круга» и «Сотрудник тех. поддержки 2 круга», управление – «Перечень ПО» и выходные данные – «Выполненная заявка».

В блоке «Сбор статистики по заявкам» входными данными являются «Выполненная заявка», механизмы – «Сотрудник тех. поддержки 2 круга», управление – «Регламентирующие документы» и выходные данные – «Отчет о выполненных заявках».

Результатом декомпозиции контекстной диаграммы «Регистрация заявки» являются 4 диаграммы:

– добавление открытой заявки в БД;

– проверка соответствия описания заявки её категории;

– определение степени сложности заявки;

– выбор свободного сотрудника технической поддержки.

Рисунок 5 – Декомпозиция блока «Регистрация заявки»

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

В блоке «Проверка соответствия описания заявки её категории» входными данными является «Открытая заявка», механизмы – «Сотрудник тех. поддержки 1 круга», управление – «Регламентирующие документы» и «Правила обращения в техническую поддержку» и выходные данные – «Корректно составленная заявка».

В блоке «Определение степени сложности заявки» входными данными является «Корректно составленная заявка», механизмы – «сотрудник тех. поддержки 1 круга», управление – «Регламентирующие документы» и выходные данные – «Проанализированная заявка».

В блоке «Выбор свободного сотрудника технической поддержки» входными данными является «Проанализированная заявка», механизмы – «Сотрудник тех. поддрежки 1 круга», управление – «Регламентирущие документы» и выходные данные – «Назначенная заявка».

3.2.3 Моделирование представления подсистемы

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

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

Рисунок 6 – Диаграмма вариантов использования

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

Администратор, как и сотрудник СТП имеет возможность:

• создавать заявки;

• выполнять заявки;

• удалять заявки;

• просматривать все заявки по всем статусам;

• добавлять решения к заявкам.

Пользователь имеет возможность:

• создавать заявки;

• просматривать свои заявки по всем статусам.

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

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

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

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

3.3 Создание базы данных

3.3.1 Проектирование базы данных

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

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

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

В результате анализа предметной области учета и обработки заявок от пользователей выявлены следующие сущности:

• пользователь;

• категория;

• подкатегория;

• решение;

• отдел;

• программное обеспечение;

• заявка.

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

Таблица 4 – Сущности и связи

После определения типов связей, выделяются атрибуты сущностей.

Таблица 5 – Атрибуты сущностей и связей

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

Рисунок 8 – Логическая модель базы данных

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

Рисунок 9 – Физическая модель базы данных

3.3.2 Создание таблиц базы данных

В результате проектирования формируются следующие таблицы баз данных:

– Category. Таблица хранит информацию о категории заявок, состоит из полей: название категории, идентификатор категории и идентификатор подкатегории;

Таблица 6 – Структура таблицы Category

– Subcategory. Таблица хранит информацию о подкатегории заявки, состоит из полей: название подкатегории и идентификатор подкатегории;

Таблица 7 – Структура таблицы Subcategory

– Solutions. Таблица хранит информацию о решениях, состоит из полей: описание решения и идентификатор решения;

Таблица 8 – Структура таблицы Solutions

– Departament Таблица хранит информацию об отделах, состоит из полей: название отдела и идентификатор отдела;

Таблица 9 – Структура таблицы Departament

– User. Таблица хранит информацию о пользователе, состоит из полей: ФИО, телефон, должность, логин, пароль, уровень доступа пользователя, и идентификаторы пользователя и отдела;

Таблица 10 – Структура таблицы User

– Software. Таблица хранит информацию о программном обеспечении, состоит из полей: название программного обеспечения, комплект программного обеспечения и идентификатор программного обеспечения;

Характеристики

Список файлов ВКР