АИС отдел кадров. АИС отдела кадров. 1. анализ предметной области и разработка требований к информационной системе 4
 Скачать 6.55 Mb.
|
|
В таблице 1.3 обозначены виды операций: 1 – создание; 2 – просмотр; 3 – изменение; 4 – удаление. Над объектом «Штатное расписание» нет операции создание (1) , так как штатное расписание создано заранее и пользователю остаётся только внести в него данные. Операцию удаление (4) производить запрещено. «График отпусков» так же не имеет операции создания, так как уже создан и требует лишь заполнения, либо изменения. Объект «Трудовой договор» создаётся вне АИС, поэтому доступен лишь его просмотр. Результаты анализа полноты выполнения функциональных требований пользователя в модели вариантов использования приведены в таблице 1.4. Все функциональные требования пользователя отражены в основных вариантах использования. Таблица 1.4. Анализ полноты выполнения требований пользователя
2. ПРОЕКТИРОВАНИЕ АИС «ОТДЕЛ КАДРОВ» 2.1. Разработка архитектуры системы Разрабатываемое программное обеспечение является клиент-серверным приложением. В фирме должны быть расположены персональные компьютеры для работы сотрудников (специалисты, начальство) с приложением. Все компьютеры в системе соединены локальной сетью, с сервером базы данных, где будет храниться база данных со всей информацией. На рисунке 2.1 приведена предварительная диаграмма развертывания разрабатываемого приложения – архитектура технических средств системы.  Рис. 2.1. Архитектура технических средств системы 2.2. Разработка модели предметной области В результате анализа (раздел 1) были выделены категории концептуальных классов, представленные в таблице 2.1. Таблица 2.1. Список категорий концептуальных классов
Пользуясь списком категорий и методом анализа словесного описания вариантов использования, составлен список кандидатур на роль концептуальных классов для предметной области. Он соответствует требованиям и принятым упрощениям для всей предметной области. Список концептуальных классов: сотрудник; штатное расписание; приказ; график отпусков; трудовой договор. На основании анализа словесного описания варианта использования, составлен список ассоциаций для предметной области, представленный в таблице 2.2. Таблица 2.2. – Ассоциации для модели предметной области
На основании анализа технического задания и описания вариантов использования выделены атрибуты классов для модели предметной области, представленные в таблице 2.3. Таблица 2.3. – Атрибуты классов для модели предметной области
В результате объединения концептуальных классов, ассоциаций и атрибутов классов концептуальная модель предметной области имеет вид, показанный на рисунке 2.2.  Рисунок 2.2. – Концептуальная модель предметной области 2.3. Разработка алгоритма функционирования системы Для того чтобы предотвратить несанкционированный доступ, вход в систему осуществляется с проверкой имени и пароля. Для этого необходимо разработать разделение одного интерфейса. Алгоритм работы системы в виде диаграммы деятельностей приведен на рисунке 2.3. Алгоритм работы специалиста отдела кадров в виде диаграммы деятельностей представлен на рисунке 2.4. На рисунке 2.5 представлена деятельность специалиста отдела кадров «Работа с личной карточкой». На рисунке 2.6 представлена деятельность специалиста отдела кадров «Создание личной карточки».  Рисунок 2.3. – Алгоритм работы системы  Рисунок 2.4. – Диаграмма деятельностей «Работа специалиста ОК» Рисунок 2.5. – Диаграмма деятельностей «Работа с личной карточкой»  Рисунок 2.6. – Диаграмма деятельностей «Создание личной карточки» Алгоритм выполнения деятельности «Создание личной карточки» разработан на основе сценария, приведенного в разделе 1.3.9. 2.4. Проектирование интерфейса пользователя 2.4.1. Разработка диаграммы состояний интерфейса специалиста отдела кадров На основании алгоритма функционирования и требований к интерфейсу (раздел 1) разработана диаграмма состояний, представленная на рисунке 2.7.  Рисунок 2.7. – Диаграмма состояний интерфейса специалиста отдела кадров После запуска приложения на экране появляется форма специально отведенных полях ввода логина и пароля пользователь заносит свои данные. Если эти данные будут неправильными, система выводит ошибку, предложит ввести повторно. Если введенные пользователем данные будут истинными, закроется окно авторизации и будет открыта главная форма с элементами, которые доступными пользователю. 2.5. Схема базы данных На рисунке 2.8 изображена схема базы данных.  Рисунок 2.8. – Схема базы данных Реляционная модель данных разработана на основе концептуальной модели предметной области. Реляционная модель данных в дальнейшем служит для разработки базы данных. Информация о столбцах таблиц приведена в таблицах 2.4 ,2.5 ,2.6. 2.5.1. Построение диаграмм последовательностей для варианта использования «Создание личной карточки» На основе сценария разработана следующая диаграмма последовательности:  Рисунок 2.9. – Диаграмма последовательностей «Создание личной карточки». На рисунке 2.10. изображена диаграмма «Создание личной карточки».  Рисунок 2.10 – Диаграмма «Создание личной карточки» Построение диаграммы классов Диаграмма классов для варианта использования «Создание личной карточки» представлена на рисунке 2.11.  Рисунок 2.11 – Диаграмма классов «Создание личной карточки» Таблица 2.4. – Атрибуты класса Сотрудник(личная карточка)
Таблица 2.5. – Операции классов
3. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 3.1. Реализация программного обеспечения системы 3.1.1. Разработка диаграммы компонентов Реализация программного обеспечения системы представлена на рисунке 3.1 в виде диаграммы компонентов. Она определяет архитектуру разрабатываемой системы на физическом уровне и представляет зависимости между программными компонентами. 3.1.2. Объекты интерфейса пользователя Приложение включает в себя несколько форм, каждая из которых реализована в своём компоненте на диаграмме компонентов (рис.3.1): main – основная программа, предназначенная для запуска приложения; Form1 – форма авторизации; Form2 – главная форма, предлагает выбор объекта, над которым нужно производить операции ; Form3 – выбор действия, в зависимости от прав пользователя ; Form4 – форма создания личной карточки; Form5– форма редактирования/удаления личной карточки; Form6– форма просмотра личной карточки.  Рис. 3.1. Диаграмма компонентов приложения После запуска приложения на экране появляется форма авторизации. После ввода логина, пароля определяется правильность ввода, если такой пользователь существует, то выводится главная форма. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||