Дипломная (вкр): Информационная система отдела кадров

Полное описание вариантов использования

Вариант использования: контроль доступа к системе.

Область действия: используемая программа.

Уровень: цель администратора.

Основное действующее лицо: администратор.

Предусловие: программа должна быть загружена, база данных присоединена к проекту.

Минимальные гарантии: наличие учётной записи администратора в таблице аутентификации.

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

Основной сценарий:

)        администратор входит в систему;

)        использует кнопки для добавления или удаления пользователей;

)        сделав необходимые изменения он завершает работу с системой.

Вариант использования: занести новых сотрудников в базу.

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, база данных присоединена к проекту.

Минимальные гарантии: пользователь знает свой логин и пароль и проходит аутентификацию.

Гарантия успеха: при вводе данных не осталось пустых полей и нажата кнопка добавления данных о новых сотрудниках.

Основной сценарий:

)        пользователь проходит аутентификацию;

)        вносит данные о новом сотруднике;

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

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

Область действия: используемая программа

Уровень: цель пользователя

Основное действующее лицо: пользователь

Предусловие: программа должна быть загружена, база данных присоединена к проекту

Минимальные гарантии: пользователь знает свой логин и пароль или находится в системе

Гарантия успеха: по условиям поиска найден сотрудник, информацию о котором необходимо редактировать.

Основной сценарий:

)        пользователь проходит аутентификацию;

)        открывает поиск и находит необходимого сотрудника;

)        открывает форму сотрудника и вносит изменения;

)        сохраняет результаты работы.

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

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, база данных присоединена к проекту.

Минимальные гарантии: пользователь находится в системе.

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

Основной сценарий:

)        пользователь находится в системе;

)        пользователь определяет условия для поиска сотрудника;

)        пользователь находит сотрудника в базе;

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

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

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: пользователь находится в системе.

Минимальные гарантии: пользователь находится в системе.

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

Основной сценарий:

)        пользователь находится в системе;

)        пользователь выбирает функцию добавления отпускных приказов;

)        пользователь находит необходимого сотрудника

)        пользователь добавляет приказ об отпуске в базу.

Вариант использования: составить график отпусков и контролировать его исполнение.

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, пользователь в системе.

Минимальные гарантии: пользователь находится в системе, данные по отпускным приказам находятся в базе данных.

Гарантия успеха: пользователь без ошибок выполняет запрос на сортировку данных по отпускным приказам сотрудников.

Основной сценарий:

)        пользователь находится в системе;

)        выбирает функцию составления графика отпусков;

)        выбирает период, за который необходимо составить график;

)        по сформированному графику появляется возможность проконтролировать исполнения графика.

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

Область действия: используемая программа.

Уровень: цель пользователя.

Основное действующее лицо: пользователь.

Предусловие: программа должна быть загружена, пользователь в системе.

Минимальные гарантии: пользователь находится в системе, данные по сотрудникам находятся в базе.

Гарантия успеха: пользователь без ошибок выполняет запрос на поиск сотрудников.

Основной сценарий:

)        пользователь находится в системе;

)        пользователь вызывает функцию поиска сотрудников;

)        пользователь задаёт критерии поиска сотрудников;

)        пользователь находит необходимых сотрудников;

)        пользователь выводит в отдельное окно данные по требуемому сотруднику.

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

Рисунок 2.2 - Диаграмма последовательности

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

Рисунок 2.3 - Диаграмма деятельности

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

1.2.3 Модель анализа вариантов использования

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

В реализации варианта использования «Контроль доступа к системе» участвую классы «FromPass» и «TextBox». Объекты класса «TextBox» позволяют заполнить поля для логина и пароля. Объект класса «FormPass» позволяет провести проверку подлинности логина и пароля.

Сама проверка правильности введённого логина и пароля проверяется методом класса «FormPass» - «get_auth()». Модель данного варианта использования представлена на рисунке 2.4.

Рисунок 2.4 - Анализ варианта использования «Контроль доступа к системе»

В реализации варианта использования «Занести новых сотрудников в базу» участвуют классы «MainForm», «Button», «TextBox», «NumericUpDown». Объект класса «Button» позволяtт добавить сотурдника в базу данных. Объекты классов «TextBox» и «NumericUpDown» позволяют вводить информацию о сотруднике. Само же добавление выполняется методом класса «MainForm» - «save_employee()».

Модель данного варианта использования представлена рисунке 2.5.

Рисунок 2.5 - Анализ варианта использования «Занести новых сотрудников в базу»

В реализации варианта использования «редактировать личную информацию о сотруднике» участвуют классы «FormView», «MainForm», «DataGridView», «Button». «FormView» используя класс «DataGridView», выводит сотрудников с общей информацией. «MainForm» выводит подробную информацию о выбранном сотруднике и позволяет её редактировать. Нажатие объекта класса «Button» позволяет сохранить изменения. Изменения сохраняются методом класса «MainForm» - «btnUpdate_Click()».

Модель варианта использования представлена на рисунке 2.6.

Рисунок 2.6 - Анализ варианта использования «редактировать личную информацию о сотруднике»

В реализации варианта использования «Занести и редактировать информацию о командировках сотрудников» участвуют классы «MainForm», «FormView», «DataGridView», «FormHolyTrip», «Button». С помощью класса «MainForm» и класса «Button», происходит вызов формы просмотра сотрудников «FormView», а затем вызов формы добавления командировок «FormTripHoly». Само добавление командировки происходит с помощью метода класса «FormTripHoly» - add_trip().

Модель варианта использования представлена на рисунке 2.7.

Рисунок 2.7 - Анализ варианта использования «Занести и редактировать информацию о командировках сотрудников»

В реализации варианта использования «Занести и редактировать информацию об отпускных приказах» участвуют классы «MainForm», «FormTripsHoly», «DataGridView», «Button», «FormView», «TextBox». С помощью класса «MainForm» и класса «Button», происходит вызов формы просмотра сотрудников «FormView», а затем вызов формы добавления командировок «FormTripHoly». Добавление отпускных приказов происходит с помощью метода класса «FormTripsHoly» - add_holy().

Модель варианта использования представлена на рисунке 2.8.

Рисунок 2.8 - Анализ варианта использования «Занести и редактировать информацию об отпускных приказах»

В реализации варианта использования «Найти и просмотреть необходимую информацию по сотрудникам» участвуют классы «MainForm», «FormView», «Button», «RadioButton», «DateTimePicker», «DataGridView», «TextBox». С помощью класса «MainForm» и класса «Button», происходит вызов формы просмотра сотрудников «FormView», затем с помощью объекта класса «Button», происходит поиск данных в соответствии с критериями поиска. Также класс «MainForm» служит для отображения подробной информации по выбранному сотруднику. С помощью объекта класса «DataGridView» происходит отображение результатов поиска. При помощи объектов классов «TextBox», «RadioButton», «DateTimePicker» происходит определение критериев поиска. Поиск происходит после вызова метода класса «FormView» - view_all().

Модель варианта использования представлена на рисунке 2.9.

Рисунок 2.9 - Анализ варианта использования «Найти и просмотреть необходимую информацию по сотрудникам»

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

1.3 Проектирование

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

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

Стандарт IDEF0 представляет процесс разработки как набор функциональных блоков. Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “получить информацию”, а не “получение информации”). Для каждого блока существует правило стороны:

–  стрелка входа приходит всегда в левую кромку активности;

–       стрелка управления - в верхнюю кромку;

–       стрелка механизма - нижняя кромка;

–       стрелка выхода - правая кромка.

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Блок выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку.

Функциональное моделирование процесса разработки ПО представлено в нотации IDEF0 на рисунках 3.1 - 3.2.

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

Рисунок 3.2 - Диаграмма декомпозиции процесса «Разработать дипломный проект» в нотации IDEF0

1.3.2 Проектирование пользовательского интерфейса

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

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