Оглавление
1.
Задание………………………………………………………………….3
2.
Введение………………………………………………………………..6
3.
Выявление
вариантов использования…………………………………7
4.
Моделирование
видов деятельности………………………………….23
5.
Моделирование
взаимодействий……………………………………...36
6.
Проектирование
статической структуры……………………………..56
7.
Заключение……………………………………………………………..60
8.
Список
использованной литературы………………………………….61
Задание
Требуется разработать модель
программного обеспечения информационной системы сбора, обработки и передачи
информации о рекрутах и вакансиях через Интернет.
Кадровое агентство
осуществляет подбор кадров для различных организаций. Подробности работы
кадрового агентства смотрите в варианте №3 задания к курсовой работе на тему
«Разработка модели программного обеспечения информационной системы автоматизации
деятельности кадрового агентства».
Для обеспечения возможности
оперативного получения информации, а также с целью повышения эффективности
сбора информации и интенсификации информационных обменов между работодателями и
кандидатами на трудоустройство, руководством кадрового агентства было принято
решение о создании информационной Интернет системы. Целью этой системы должно
быть:
• создание представительства в
Интернет (Интернет сайт), с помощью которого становится возможным
информирование клиентов и работодателей о текущих новостях агентства,
размещение объявлений, статей, и другой информации;
• сбор информации о кандидатах
(людях, ищущих работу) и внесение их в базу данных;
• сбор информации о вакансиях
от работодателей с указанием всех
необходимых условий и их
внесение в базу данных.
Обобщенное описание
функциональных особенностей Интернет системы, а также типовые действия
работника агентства выглядят следующим образом.
Интернет система кадрового
агентства состоит из следующих разделов: «О нас», «Контакты», «Вакансии»,
«Резюме», «Услуги», «Статьи». При открытии начальной на экран выводится
содержимое раздела «О нас». В этом разделе представлены сведения о компании
рекламно-ознакомительного характера. На странице должны присутствовать
элементы, посредством которых возможно осуществлять переход к любому, описанному
выше, разделу. В разделе «Контакты» расположена контактная информация об
агентстве с описанием схемы проезда.
Раздел «Вакансии» содержит
информацию о существующих в БД системы открытых вакансиях. При входе в этот
раздел, система считывает данные о десяти первых открытых вакансиях и выводит
их на экран в виде таблицы, содержащей следующие сведения: дата открытия
вакансии, должность, размер заработной платы, количество человек, требования к
кандидатам. Система также должна сформировать ссылки, с помощью которых становится
возможным переход к просмотру оставшихся вакансий, располагающихся также по
десять штук на одной странице.
При переходе в раздел
«Резюме», система формирует и выводит на экран резюме кандидатов по 5 штук на
одной странице с возможностью перехода между страницами. Резюме кандидата,
формируемое на экране, содержит следующую информацию: Номер кандидата, пол,
возраст, желаемая должность, предполагаемая зарплата, опыт работы. Опыт работы,
в свою очередь, состоит из информации об организации, в которой работал кандидат,
его должности, дате приема и увольнения, причине увольнения, должностных обязанностях.
Информацию об опыте работы желательно приводить в виде таблицы, состоящей из
стольких строк, сколько организаций указал кандидат при заполнении анкеты.
При переходе в раздел
«Услуги», формируется информация об услугах агентства и их стоимости. Эти
информация статична, т.е. БД не используется для ее хранения.
В разделе «Статьи» должна
существовать возможность просмотра
опубликованных работниками
агентства статей. При этом на экран с
возможностью постраничного
перехода, выводятся заголовки статей, их авторы и даты опубликования. При
щелчке на заголовке статьи, происходит переход к ее полному тексту. При этом
сначала приводится текст заголовка статьи, затем ее текст, автор и дата
публикации.
Кроме перечисленных разделов,
существуют еще 2 раздела:
«Соискателям» и
«Работодателям». В разделе «Соискателям», возможен ввод личных данных соискателя
(заполнение анкеты). Анкета соискателя содержит целый ряд сведений о кандидате,
поэтому целесообразно организовать ее заполнение в несколько этапов. 1 этап –
ввод информации о фамилии, имени, отчестве соискателя, а также его пол, дата
рождения, телефон домашний и контактный, город, улица, дом, корпус, квартира,
зарплата и текущий статус (работает или уволился). 2 этап – заполнение таблицы
желаемых должностей. В силу того, что таковых может быть несколько, кандидат
имеет возможность составить таблицу. 3 этап – заполнение информации об
образовании кандидата: тип образования (высшее, среднее и т.д.), учебное
заведение, даты поступления и окончания, отделение, факультет и специальность.
4 этап – информация о владении кандидатом персональным компьютером: наименование
компьютерной программы и степень владения ей (пользователь, продвинутый
пользователь, программист). 5 этап – информация о владении кандидатом иностранными
языками: язык и степень владения (начальный, разговорный, технический и т.д.).
6 этап – список предыдущих мест работы соискателя: организация, должность, даты
приема и увольнения, причина увольнения, должностные обязанности. 7 этап –
вывод полной информации о заполненных кандидатом данных и возможность их
сохранения. При заполнении полей на каждом этапе и переходе к следующему,
система проверяет правильность заполнения полей (соответствие форматов данных,
а также заполненность полей данными, некоторые поля должны обязательно
содержать значения) и осуществляет переход к следующему этапу. На последнем –
седьмом этапе, система позволяет сохранить внесенные данные в БД или перейти к
исправлению данных нужного раздела.
В разделе «Работодателям»
система позволяет внести сведения работодателей о наличии вакансий. При этом
заполняются следующие поля: организация, должность, зарплата, дата открытия,
количество мест, требования к соискателю. На главной странице, формируемой
системой, также должны быть расположены разделы: для ввода имени и пароля и
входа в администраторскую часть системы; для отображения пяти последних
вакансий, внесенных в БД, для отображения пяти последних статей, внесенных в
БД. Как уже упоминалось выше, система содержит администраторскую часть,
позволяющую вносить изменения в информацию, размещенную на сайте. Для входа в
этот режим, необходимо ввести имя и пароль. При этом система проверяет наличие
данной комбинации имени и пароля и если таковая существует, доступ разрешается,
в противном случае выводится сообщение об ошибке. С помощью административного
раздела, возможно, просматривать введенные пользователями анкеты, фильтровать
их по должности, фамилии, полу, окладу и коду соискателя, удалять, создавать
резюме (помечать анкету специальным признаком, по которому система производит
отбор данных и формирование резюме, публикуемых на сайте), подготавливать к
передаче в локальную систему кадрового агентства (помечать анкету специальным
признаком). Кроме того, в режиме администрирования существует возможность
просмотра сформированных резюме и их удаления; просмотр, удаление заявок
работодателей и формирование на их основе вакансий. Просмотр и удаление
вакансий работодателей. Просмотр, создание новых и удаление выбранных статей,
публикуемых на сайте.
Введение.
В курсовой работе были рассмотрены
следующие составляющие части разработки модели программного обеспечения
информационной системы сбора, обработки и передачи информации о рекрутах и
вакансиях через Интернет, это выявление вариантов использования (диаграмма
прецедентов и документирование прецедентов), моделирование видов деятельности и
моделирование взаимодействий. Основополагающими факторами создания этой части,
в частности: моделирования видов деятельности, послужило создание, вариантов использования
(прецеденты), взаимосвязь между ними, анализ требований, а также моего личного
мнения. Для моделирования взаимодействий (последовательностей) были
использованы классы-сущности, прецеденты, а также диаграммы видов деятельности.
Также на основе диаграмм последовательности для прецедентов были созданы
диаграммы кооперации. Разница между моделями заключается в акцентах. Модели
последовательностей концентрируются на временных последовательностях событий, а
в моделях кооперации основное внимание уделяется отношениям между объектами.
Выявление
вариантов использования.
Диаграммы вариантов использования (или прецедентов, Use Case Diagram) относятся к статическому виду системы с точки зрения
возможностей ее использования. Это вид диаграмм особенно важен при организации
и моделирования поведения системы. На них представлены прецеденты и актеры (частный
случай классов), а также отношения между ними. Актер – это роль, которую
пользователь играет по отношению к системе.
Вариант использования представляет собой последовательность действий
(транзакций), выполняемых системой в ответ на событие, инициируемое некоторым
внешним объектом (субъектом). Вариант использования описывает типичное
взаимодействие между пользователем и системой, и отражает представление о
поведении системы с точки зрения пользователя. В простейшем случае вариант
использования определяется в процессе обсуждения с пользователем тех функций,
которые он хотел бы реализовать, или целей, которые он преследует по отношению
к разрабатываемой системе.
Хорошим источником для идентификации вариантов
использования служат внешние события. Идентификация событий, на которые необходимо
реагировать, помогает выделить варианты использования.
В процессе рассмотрения выявленных вариантов
использования составляется документ спецификации вариантов использования.
Спецификация подробно документирует процесс взаимодействия субъекта с системой,
реализуемого в рамках варианта использования. Спецификация прецедента рассматривает
краткое описание прецедента, субъектов, участвующих в нем, основной и
альтернативный потоки поток, т.е. нормальный ход и отклонения от него, предусловие
(событие, предшествующие прецеденту) и постусловие (событие, следующие после
завершения прецедента).
На следующем рисунке представлены основные варианты
использования проектируемой системы, выявленные на основании требований к
системе.
Следует отметить, что для уменьшения громоздкости
диаграммы вариантов использования, мы выделили прецедента Пользователь и
прецедентов Администратор, Работодатель, Соискатель, наследующие все атрибуты у
прецедента Пользователь.
В процессе анализа были выявлены три субъекта,
которые взаимодействуют с системой:
Рисунок 1. Субъекты системы.
Кроме того, были выявлены следующие
прецеденты, выполнение которых осуществляют субъекты системы (Администратор,
Работодатель, Соискатель):
Рисунок 2. Прецеденты системы.
Приведем
диаграмму взаимодействия каждого выявленного субъекта с прецедентами.
Рисунок 3. Диаграмма взаимодействия с прецедентами для
работодателя.
Рисунок 4. Диаграмма взаимодействия с прецедентами
для администратора.
Рисунок 5. Диаграмма взаимодействия с прецедентами для
пользователя
Рисунок 6. Диаграмма вариантов использования
Рассмотрим спецификацию каждого прецедента (варианта
использования).
Спецификация прецедента «Вход в систему».
|
1. Краткое описание.
|
Данный
прецедент предполагает вход в систему администратором и работодателем.
|
|
2. Субъекты.
|
Администратор.
Работодатель.
|
|
3. Предусловия.
|
Администратор
и работодатель осуществляют вход в систему с помощью логина и пароля.
|
|
4.1. Основной поток.
|
Администратор
и работодатель на главной странице, для входа в систему вводят логин и
пароль. Система идентифицирует каждого из них, в соответствии с этим
определяет их права.
|
|
4.2. Альтернативный поток.
|
Если
данные (логин и пароль) введены неправильно, то система выводит сообщение об
ошибке и предлагает пользователю новый ввод данных.
|
|
5. Постусловия.
|
В
случае успешно проделанной процедуры пользователь осуществляет вход в
систему.
|
Спецификация прецедента «Заполнение заявки».
|
1.
Краткое описание.
|
Работодатель
осуществляет заполнение заявки.
|
|
2.
Субъекты.
|
Работодатель.
|
|
3.
Предусловия.
|
Обращение
пользователя к системе при появлении необходимости у работодателя поиска работника.
|
|
4.1.
Основной поток.
|
После
регистрации, работодатель осуществляет заполнение заявки. Для этого он
заходит в раздел «Работодателям», при котором система позволяет ему внести
следующие сведения о наличии вакансий. Т. е. на этой странице происходит
заполнение следующих полей: организация, должность, зарплата, дата открытии,
количество мест и требования к соискателю. После заполнения всех полей работодатель
осуществляет сохранение заполненной формы.
|
|
4.2.
Альтернативный поток.
|
При
обнаружении ошибки, т. е. если какое либо поле не заполнено, система
позволяет перейти к заполнению нужного поля.
|
|
5.
Постусловия.
|
Заявка
сохраняется в системе и становится доступной для формирования на её основе
администратором вакансии.
|
Спецификация прецедента «Заполнение анкеты».
|
1.
Краткое описание.
|
Соискатель
осуществляет заполнение анкеты.
|
|
2.
Субъекты.
|
Соискатель.
|
|
3.
Предусловия.
|
Обращение
пользователя к системе при появлении необходимости у соискателя поиска работы.
|
|
4.1.
Основной поток.
|
При
возникновении необходимости у соискателя поиска вакансии, он заходит в раздел
«Соискатели» и осуществляет ввод своих личных данных: фамилия, имя, отчество,
пол, дата рождения, телефон домашний и контактный, город, улица, дом, корпус,
зарплата, текущий статус (работает или уволился), желаемые должности, тип
образования (высшее, среднее и т. д.), специальность, информация о владении
кандидатом персональным компьютером: наименование компьютерной программы и
степень владения ей (пользователь, продвинутый пользователь, программист),
владение кандидатом иностранными языками: язык и степень владения (начальный,
разговорный, технический и т. д.), список предыдущих мест работы соискателя:
организация, должность, даты приёма, увольнения, причина увольнения, должностные
обязанности. После заполнения анкеты система выводит информацию о заполненных
кандидатом данных, с возможностью их сохранения, с помощью которого пользователь
просматривает введённые им личные данные и осуществляет сохранение анкеты.
|
|
4.2.
Альтернативный поток.
|
При
обнаружении незаполненного поля система выдаёт сообщение об ошибке и позволяет
перейти к заполнению нужного поля.
|
|
5.
Постусловия.
|
Анкета
сохраняется в системе и становится доступной для формирования на её основе
администратором, резюме.
|
Спецификация прецедента «Редактирование заявки/анкеты».
|
1. Краткое описание.
|
Администратор
осуществляет редактирование заявки/анкеты, заполненные работодателем/соискателем.
|
|
2. Субъекты.
|
Администратор.
|
|
3. Предусловия.
|
В
системе появляется новая заявка/анкета.
|
|
4.1. Основной поток.
|
После
того как работодатель/соискатель заполнили заявку/анкету, администратору
приходит уведомление о том, что некий пользователь осуществляет регистрацию в
БД путём заполнения заявки/анкеты. Далее администратор просматривает список
новых заявок и анкет, осуществляет проверку каждого заполненного поля. В
случае неправильности заполнения администратор может осуществить
корректировки заполненных данных работодателем и соискателем или же администратор
удаляет неправильно заполненную заявку/анкету, уведомляя об этом работодателя/соискателя.
После чего он сохраняет внесённые изменения.
|
|
4.2. Альтернативный поток.
|
Отсутствует.
|
|
5. Постусловия.
|
После
успешного редактирования администратором заявки/анкеты, происходит их регистрация.
|
Спецификация прецедента «Добавить вакансию».
|
1.
Краткое описание.
|
Прецедент
даёт возможность добавит новую вакансию.
|
|
2.
Субъекты.
|
Работодатель.
Администратор.
|
|
3.
Предусловия.
|
Авторизация
работодателя.
|
|
4.1.
Основной поток.
|
Для
того чтобы добавить вакансию работодатель должен зарегистрироваться. При
добавлении вакансии работодатель выбирает раздел работодателям. Осуществляет
заполнение полей, для добавления новой вакансии и инициирует сохранение.
После чего система заносит вакансию в БД. Администратор также имеет
возможность добавлять вакансию от имени работодателя.
|
|
4.2
Альтернативный поток.
|
Если
администратор или работодатель неправильно заполнили поля, то они не смогут
продолжить заполнение следующих полей.
|
|
5.
Постусловия.
|
При
успешном заполнении полей, вакансия помещается в БД.
|
Спецификация прецедента «Подбор вакансии».
|
1.
Краткое описание.
|
Соискатель
осуществляет подбор вакансии по вводимым критериям.
|
|
2.
Субъекты.
|
Соискатель.
|
|
3.
Предусловия.
|
Обращение
соискателя к разделу «Вакансии» с целью подбора нужной ему должности.
|
|
4.1.
Основной поток.
|
Для
подбора вакансии соискатель открывает раздел «Вакансии». При щелчке мышью по
«Подбор вакансии», система предоставляет ему форму для заполнения, в котором
указаны следующие поля: желаемая должность, размер заработной платы являющиеся
обязательными для заполнения, а также график работы, который можно не
указывать. При заполнении этих полей соискатель нажимает кнопку «Искать».
|
|
4.2
Альтернативный поток.
|
В
случае если соискатель не заполнил поле желаемая должность и/или размер
заработной платы система отображает на экран сообщение об ошибке и просит
ввести пропущенную информацию.
|
|
5.
Постусловия.
|
Если
прецедент был успешным, то система отображает список существующих вакансий.
|
Спецификация прецедента «Удалить вакансию».
|
1. Краткое описание.
|
Данный прецедент
осуществляет удаление ненужной вакансии администратором.
|
|
2. Субъекты.
|
Администратор.
|
|
3. Предусловия.
|
Удаление вакансии.
|
|
4.1. Основной поток.
|
Администратор удаляет
вакансию, в том случае, если работодатель нашёл нужного работника на требуемую
вакансию.
|
|
4.2. Альтернативный поток.
|
Отсутствует.
|
|
5. Постусловия.
|
Если прецедент был
успешным, то вакансия удаляется.
|
Спецификация прецедента «Регистрация работодателя».
|
1. Краткое описание.
|
Работодатель осуществляет
регистрацию, путём ввода имени и пароля.
|
|
2. Субъекты.
|
Работодатель.
|
|
3. Предусловия.
|
Появление необходимости у
работодателя добавления вакансии.
|
|
4.1. Основной поток.
|
Для осуществления
регистрации работодателя, он на главном окне нажимает кнопку «Зарегистрироваться»,
ему открывается форма для заполнения, куда он вносит информацию для
авторизации: организация, логин, пароль, контрольный вопрос, инициируя
процесс сохранения. После этого система формирует уведомление администратора
о новой неподтверждённой регистрации. Администратор, получив это уведомление,
просматривает заполненную форму. После чего он должен связаться с организацией
по указанным контактам и подтвердить факт регистрации. Если организация
подтверждает факт регистрации, то администратор принимает регистрацию.
|
|
4.2. Альтернативный поток.
|
Если факт регистрации не
подтверждается, то администратор отклоняет регистрацию, удаляя полученную
форму.
|
|
5. Постусловия.
|
После успешной регистрации
в системе создаётся новая учётная запись.
|
Спецификация прецедента «Отобразить раздел резюме».
|
1.
Краткое описание.
|
Прецедент
необходим для отображения резюме пользователем без личных данных.
|
|
2.
Субъекты.
|
Пользователь.
|
|
3.
Предусловия.
|
Обращение
в раздел резюме.
|
|
4.1.
Основной поток.
|
Для
просмотра резюме пользователь открывает раздел «Резюме». При открытии этого
раздела система формирует и выводит резюме 5 последних кандидатов на одной
странице. Для формирования резюме система получает данные о резюме, сформированном
администратором на основе анкеты пользователя. Из этого резюме система
выбирает всю информацию, кроме личных данных, т. е. выбранная информация и
публикуется на странице раздела резюме. Соответственно, на этой странице
содержится такая информация как: номер кандидата, пол, дата рождения, возраст
,статус, желаемая должность, образование, степень владения ПК и иностранными
языками, опыт работы, в свою очередь, состоит из информации об организации, в
которой работал кандидат, его должности, дата приёма и увольнения, причина
увольнения, но без личных данных (ФИО, адрес). Также система позволяет переходить
с одной страницы на другую с помощью ссылок, т. е. она отображает на страницах
раздела резюме ссылки для перехода по страницам.
|
|
4.2.
Альтернативный поток.
|
Отсутствует.
|
|
5.
Постусловия.
|
Система
отображает страницу, и пользователь имеет возможность просматривать резюме.
|
Спецификация прецедента «Создать статью».
|
1.
Краткое описание.
|
Создание
администратором статьи.
|
|
2.
Субъекты.
|
Администратор.
|
|
3.
Предусловия.
|
Создание
статьи.
|
|
4.1.
Основной поток.
|
Администратор
открывает раздел статьи и переходит к форме, в которой он осуществляет добавление
статьи. Т. е. в этой форме он открывает ссылку «Добавить статью». Далее он из
этой формы открывает окно выбора файла, то есть указывает путь к файлу. После
проделанной процедуры инициирует сохранение и загружает на сайт.
|
|
4.2.
Альтернативный поток.
|
Отсутствует.
|
|
5.
Постусловия.
|
Созданная
статья загружается на сайт.
|
Спецификация прецедента «Удалить статью».
|
1.
Краткое описание.
|
Удаление
администратором статьи.
|
|
2.
Субъекты.
|
Администратор.
|
|
3.
Предусловия.
|
Удаление
статьи.
|
|
4.1.
Основной поток.
|
Администратор
открывает раздел статьи и переходит к форме, в которой он удаляет устаревшую
статью. Для этого администратор сначала удаляет файл со статьёй, а затем
ссылку на эту статью. После чего, администратор сохраняет проделанные им
процедуры..
|
|
4.2.
Альтернативный поток.
|
Отсутствует.
|
|
5.
Постусловия.
|
Созданная
статья загружается на сайт.
|
Спецификация прецедента «Создать резюме».
|
1.
Краткое описание.
|
Создание
резюме администратором.
|
|
2.
Субъекты.
|
Администратор.
|
|
3.
Предусловия.
|
Войти
в систему
|
|
4.1.
Основной поток.
|
Администратор
при входе в режим создания резюме получает уведомление о новых анкетах. После
этого администратор начинает просмотр всех анкет по очереди. В случае если
анкета удовлетворяет всем условиям, то администратор помечает анкету специальным
признаком и система подготавливает передачу анкеты, удовлетворяющую всем
требованиям на усмотрение администратора в локальную ИС, при котором оно доступно
для просмотра для любого пользователя.
|
|
4.2.
Альтернативный поток.
|
Отсутствует.
|
|
5.
Постусловия.
|
Созданное
резюме сохраняется в системе и передаётся в локальную ИС.
|
Спецификация прецедента «Удалить резюме».
|
1. Краткое описание.
|
Данный прецедент осуществляет
удаление ненужного резюме администратором.
|
|
2. Субъекты.
|
Администратор.
|
|
3. Предусловия.
|
Удаление резюме.
|
|
4.1. Основной поток.
|
Администратор удаляет
резюме, в том случае, если соискатель нашёл работу и не нуждается в услугах
кадрового агентства.
|
|
4.2. Альтернативный поток.
|
Отсутствует.
|
|
5. Постусловия.
|
Если прецедент был
успешным, то резюме удаляется.
|
Спецификация прецедента «Отобразить раздел вакансий».
|
1.
Краткое описание.
|
Прецедент
необходим для отображения вакансии пользователем.
|
|
2.
Субъекты.
|
Пользователь.
|
|
3.
Предусловия.
|
Обращение
в раздел вакансий.
|
|
4.1.
Основной поток.
|
Для
просмотра вакансии пользователь открывает раздел «Вакансии». При открытии
этого раздела система формирует и выводит данные десяти первых вакансиях и
выводит их на экран в виде таблицы, содержащей следующие сведения: дата открытия
вакансии, должность, размер заработной платы, количество человек, требования
к кандидатам. Система также должна сформировать ссылки, с помощью которых
становится возможным переход к просмотру оставшихся вакансий с помощью кнопок
«Далее» и «Назад», располагающихся также по десять штук на одной странице.
|
|
4.2.
Альтернативный поток.
|
Отсутствует.
|
|
5.
Постусловия.
|
Система
отображает страницу, и пользователь имеет возможность просматривать вакансии.
|
Спецификация прецедента «Удалить вакансию»
|
1. Краткое описание.
|
Данный прецедент
осуществляет удаление ненужной вакансии работодателем или администратором.
|
|
2. Субъекты.
|
Администратор.
Работодатель.
|
|
3. Предусловия.
|
Удаление вакансии.
|
|
4.1. Основной поток.
|
Администратор удаляет
вакансию, в том случае, если организация нашла работника на требуемую вакансию
и информирует об этом кадровое агентство, или же работодатель, заходя на сайт
под свою учетную запись в раздел «Работодатели» нажимает кнопку «Удалить
вакансию» и вакансия удаляется.
|
|
4.2. Альтернативный поток.
|
Отсутствует.
|
|
5. Постусловия.
|
Если прецедент был
успешным, то вакансия удаляется.
|
Спецификация прецедента «Восстановить пароль».
|
1.
Краткое описание.
|
Прецедент
необходим для восстановления пароля.
|
|
2.
Субъекты.
|
Работодатель.
|
|
3.
Предусловия.
|
Восстановление
пароля.
|
|
4.1.
Основной поток.
|
Данный
прецедент используется в случае, если уже зарегистрированный работодатель
забыл и в случае если работодатель инициирует новую регистрацию, заполняя поле
«Организация» то система выдаёт сообщение об ошибке, что данная организация
уже была зарегистрирована. Следовательно, система предлагает восстановить
пароль, введя контрольный вопрос, при этом предполагается, что работодатель,
вспоминая о своей регистрации, не забыл логин, который он ранее вводил. После
правильного ввода контрольного вопроса, система предлагает ему новый ввод
пароля.
|
|
4.2.
Альтернативный поток.
|
В
случае если работодатель неправильно ввел контрольный вопрос, система выдает
сообщение об ошибке.
|
|
5.
Постусловия.
|
Если
работодатель правильно ввёл контрольный вопрос, то работодатель может
осуществлять операции, в соответствии со своими правами, т.е. добавлять или
удалять вакансию.
|
Моделирование видов деятельности.
Модели видов деятельности (Activity Diagram)
строятся для описания общей последовательности действий для нескольких объектов
и вариантов использования. На диаграммах этого типа представляются переходы
потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм
относится к динамическим представлениям системы, и является наиболее полезным
при моделировании ее функционирования, так как отражает передачу потока
управления между объектами.
Основным элементом диаграммы видов деятельности
является деятельность. Интерпретация этого термина зависит от той точки зрения,
с которой строится данная диаграмма. На концептуальной диаграмме деятельность –
это некоторая задача, которую необходимо выполнить вручную или автоматизированным
способом. На диаграмме, построенной в аспекте спецификации или реализации,
деятельность представляет собой некоторый метод над классом.
Диаграмма деятельностей предоставляет свободу выбора
порядка выполнения. Другими словами, она только устанавливает основные правила
последовательности, которым необходимо следовать. Такая возможность важна при
моделировании бизнес-процессов. Среди бизнес-процессов нередко встречаются
такие, которые не обязаны выполняться последовательно. В таких ситуациях данный
метод хорошо работает, так как он позволяет реализовывать процессы параллельно.
Диаграммы видов деятельности являются также полезными
при параллельном программировании, поскольку можно графически изобразить все ветви
и определить, когда их необходимо синхронизировать.
Если при описании поведения системы имеются
параллельные деятельности, то их необходимо синхронизировать. Простая линейка
синхронизации показывает, что ее выходная деятельность активизируется только
тогда, когда выполнены обе входные деятельности.
Диаграммы видов деятельности можно применять для
описания потоков событий в вариантах использования. С помощью текстового описания
можно достаточно подробно рассказать о потоке событий, но в сложных и
запутанных потоках с множеством альтернативных ветвей будет трудно понять
логику событий. Диаграммы видов деятельности предоставляют ту же информацию,
что и текстовое описание потока событий, но в наглядной графической форме.
Рассмотрим теперь модели видов деятельности,
построенные для проектируемой системы.
Вход в систему.
Рисунок 7. Диаграмма видов деятельности для прецедента
«Вход в систему»
Вход в систему инициируется работодателем и
администратором. Для осуществления этой процедуры последним, система
отображает форму авторизации, далее система формирует запрос на регистрацию,
т.е. работодатель или администратор хочет осуществить регистрацию, либо просто
вводит свой логин и пароль для входа в систему. При выборе запроса на
регистрацию, необходимо заполнить поля формы, т. е. администратор или
работодатель вводит логин и пароль под которым в дальнейшем пользователь будет
заходить в систему. После чего осуществляется вход в систему и проверяется
логин и пароль на правильность ввода, либо на их повторное существование. В
случае если логин и пароль введены неправильно, формируется сообщение об
ошибке, и пользователь производит новое заполнение формы, если все введено
правильно, то администратор или работодатель авторизуются. Завершающим этапом
является отображение главной страницы. Если администратор или пользователь уже
зарегистрированы, то они формируют запрос на авторизацию, при котором осуществляется
проверка логина и пароля, в случае если всё введено правильно, происходит
отображение главной страницы.
Добавить вакансию.
Рисунок 8. Диаграмма видов деятельности для прецедента
«Добавить вакансию»
Прецедент «Добавить вакансию» осуществляется
работодателем, в случае если он зарегистрирован. Для выполнения данного
прецедента необходимо инициировать вход в систему, после которого система
отобразит форму для входа в систему. На этом окне размещён раскрывающий список,
в котором он выбирает логин «работодатель». После чего выводятся поле для
внесения пароля, в случае если работодатель зарегистрирован. При внесении
пароля в поле для заполнения, система проверяет наличие такого пароля, если такой
пароль не существует, система выводит сообщение об ошибке. Если внесённый пароль
соответствует работодателю, система открывает раздел работодателям, в котором необходимо
заполнить форму, для добавления новой вакансии, после чего выводится результат
заполнений. При неправильном заполнении, какого либо поля или незаполненного
поля система выводит сообщение об ошибке и работодателю предлагается вновь
осуществить заполнение формы. Если данные введены верно, результат введенных
данных о предлагаемой вакансии сохраняется в БД.
Заполнение заявки.
Рисунок 9. Диаграмма видов деятельности для
прецедента «Заполнение заявки»
Данный прецедент инициируется работодателем. Для этого
последний формирует запрос на заполнение заявки, после осуществления
регистрации, работодателем. Далее система отображает форму для заполнения, в
которую он вводит наименование организации, должность ,зарплата, дата открытия,
количество мест и требования к соискателю, формирует запрос на сохранение своей
заявки и система предварительно сохраняет. Предварительно, в этом случае
означает, то, что прежде чем это заявка попадёт в БД для общего просмотра,
администратор проверяет правильность заполнения заявки работодателем. Только
после проверки администратором правильности заполненной заявки, администратор
формирует на ее основе вакансию и размещает её на сайте для общего просмотра.
Заполнение анкеты.
Рисунок 10. Диаграмма видов деятельности для
прецедента «Заполнение анкеты»
Выполнение данного прецедента инициируется
соискателем, для поиска необходимой вакансии. Для этого он отправляет системе
запрос на заполнение анкеты, система отображает форму для заполнения, далее
пользователь вводит данные о себе, после он инициирует запрос на сохранение,
после которого происходит предварительное сохранение, по тому же принципу, как
и в предыдущем примере.
Отобразить раздел вакансий.
Рисунок 11. Диаграмма видов деятельности для
прецедента «Отобразить раздел вакансий»
Отображение раздела вакансий запускается
пользователем, т. е. работодателем, соискателем и администратором. При входе в
этот раздел система отображает десять последних вакансий, далее пользователь
инициирует запуск конкретной для просмотра вакансию.
Отобразить раздел резюме.
Рисунок 12. Диаграмма видов деятельности для
прецедента «Отобразить раздел резюме»
Данный прецедент аналогичен предыдущему, кроме того,
что система выводит пять последних резюме, а не десять вакансий как в предыдущем
виде деятельности для прецедента «Отобразить раздел вакансий».
Подбор вакансии.
Рисунок 13. Диаграмма видов деятельности для
прецедента «Подбор вакансии»
Для осуществления подбора вакансии пользователь
обращается к системе и инициирует поиск вакансии. Система отображает форму
поиска, то есть форму, на которой расположены поля для ввода критериев поиска.
Пользователь заполняет эти поля, то есть вводит параметры поиска (параметрами
могут быть должность, размер заработной платы, график работы и т.д.) и
запускает поиск. Система ищет среди вакансий те, которые соответствуют
введенным пользователем параметрам. Если вакансии, удовлетворяющие запросу
пользователя, найдены, системы отображает их на экране. Если же подходящие вакансии
не найдены, система сообщает об этом пользователю и предлагает осуществить
новый поиск. Пользователь может согласиться либо отказаться. В первом случае
система возвращает пользователя к вводу параметров поиска, иначе окно
закрывается и прецедент завершается.
Регистрация работодателя.
Рисунок 14. Диаграмма видов деятельности для
прецедента «Регистрация работодателя»
Регистрация работодателя осуществляется,
соответственно, работодателем. Основной целью регистрации является получение,
авторизовавшись в системе, получать возможность добавлять вакансии. Для этого работодатель
формирует запрос на регистрацию, система при этом отображает форму для
заполнения, т. е. вводит свой логин и пароль, далее происходит проверка системой
внесённых данных работодателем, в случае если данные заполнены правильно,
администратор проверяет реальность существования работодателя и его реальное
согласие на регистрацию, если всё подтвердилось, данный работодатель сохраняется
в БД, в противном случае, работодатель удаляется администратором. Вернемся к
тому что, если логин и пароль неправильные, в этом случае формируется
сообщение, и система предлагает пользователю заполнить данные повторно.
Редактирование заявки/анкеты.
Рисунок 15. Диаграмма видов деятельности для
прецедента «Редактирование заявки/анкеты»
Данный прецедент выполняется администратором кадрового
агентства. Т. е. прежде чем, данная анкета попадёт в БД, администратором
предварительно проверяются заполненные заявки и анкеты. Для этого
администратором инициируется отображение списка заполненных заявок и анкет.
Далее из списка выбирается конкретная заявка или анкета. В случае если
заявка/анкета заполнены правильно, администратор закрывает и передаёт их в БД.
В противном случае, он осуществляет редактирование заявки/анкеты. После того
как все необходимое сделано для одной заявки/анкеты, администратор возвращается
к просмотру следующей заявки/анкеты.
Создать резюме.
Рисунок 16. Диаграмма видов деятельности для
прецедента «Создать резюме»
Прецедент «Создать резюме» инициируется
администратором. Её создание осуществляется на основе данных анкеты. Для этого
администратор при входе в систему формирует запрос на создание резюме, данный
запрос обрабатывается и администратор просматривает анкету. При просмотре
администратор либо удаляет анкету, при котором он формирует сообщение для
пользователя, о проделанном администратором действии, либо на её основе создаёт
резюме, далее происходит формирование запроса «Создать», после чего система
устанавливает признак необходимости передачи в локальную ИС. На этом деятельность
данного прецедента завершается.
Создать статью.
Рисунок 17. Диаграмма видов деятельности для
прецедента для прецедента «Создать статью»
Данный прецедент также выполняется
администратором. Т. е. для начала последний формирует запрос на создание
статьи, далее отображается форма, в этой форме есть ссылка на выбор, какого
либо файла из компьютера, указываем путь и загружаем на сайт.
Удалить резюме.
Рисунок 18. Диаграмма видов деятельности для
прецедента «Удалить резюме»
Данный
прецедент также выполняется администратором, в случае если соискатель уже нашёл
работу, и не нуждается в услугах кадрового агентства. Для этого необходимо
сформировать запрос на удаление резюме, отображается весь список, далее из
этого списка помечаются удаляемые резюме и администратор инициирует удаление.
Рисунок 19. Диаграмма видов деятельности для
прецедента «Удалить статью»
Данный прецедент также выполняется администратором, в
случае статья устарела или при других обстоятельствах. Для этого необходимо сформировать
запрос на удаление статьи, отображается весь список, далее из этого списка
помечаются удаляемые статьи и администратор инициирует удаление.
Удалить вакансию.
Рисунок 20. Диаграмма видов деятельности для
прецедента «Удалить вакансию»
Данный
прецедент выполняется администратором, в случае, если работодатель уже нашёл
работника, или последний уведомил администратора о его желании удалить вакансию.
Эта
процедура происходит следующим образом: администратор открывает вес раздел
вакансий, выбирает из них те, которые необходимо удалить, инициирует их
удаление, система предварительно выводит сообще7ие для администратора о
подтверждении выбранных вакансий, после чего происходит успешное их удаление.
Моделирование взаимодействий.
Диаграммы взаимодействия (Interaction Diagram)
являются моделями, описывающими поведение взаимодействующих групп объектов. Как
правило, диаграмма взаимодействия описывает поведение объектов в рамках только
одного варианта использования. На такой диаграмме отображается ряд объектов и
те сообщения, которыми они обмениваются между собой.
Обычно рассматривают два частных случая диаграмм
взаимодействий: диаграммы последовательности (Sequence Diagram) и диаграммы кооперации (Collaboration Diagram). Диаграммы последовательности очень просты и наглядны,
в этом заключается их самое большое достоинство. Они существенно помогают
разобраться в процессе поведения системы. Диаграммы кооперации получаются из
диаграмм последовательностей механически.
Модели взаимодействия применяются для описания
поведения нескольких объектов в единственном варианте использования.
Рассмотрим модели взаимодействий для каждого варианта
использования.
При построении диаграмм взаимодействий (помимо ранее
определенных классов - сущностей) нами были выделены следующие объекты системы:
1.
Классы:
·
Анкеты;
·
Заявки;
·
Работодатели;
·
Вакансии;
·
Статьи.
2.
Управляющие классы:
·
Управление анкетами;
·
Управление заявками;
·
Управление работодателями;
·
Управление вакансиями;
·
Управление статьями;
·
Окно подтверждения удаления.
3.
Пограничные классы:
·
Окно Главная страница;
·
Окно анкеты;
·
Окно вакансий;
·
Окно для входа в систему;
·
Окно регистрации;
·
Окно заявки;
·
Окно списка заявок;
·
Окно статей.
Вход в систему
Рисунок 21. Диаграмма последовательности «Вход в
систему»
Рисунок 22. Диаграмма кооперации «Вход в систему»
В процессе моделирования взаимодействий возникла
необходимость в создании ряда объектов классов, которые представлены на диаграмме.
Такие как пограничный класс «Окно для входа в систему»
и «Главная страница», на которую работодатель заходит после авторизации.
Помимо, пограничных классов целесообразным было выделение управляющего класса
Система сайта, которая поверяет учетную запись (логин и пароль), введенных
работодателем. Помимо работодателя Вход в систему осуществляет Администратор,
он заходит в систему таким же образом, поэтому мы не посчитали нужным его изображать.
Работодатель открывает окно для входа в систему, ему
предлагается ввести свой логин и пароль, далее инициируется вход в систему. После
чего система проверяет учётную запись, в случае обнаружения ошибки система выводит
сообщение об ошибке, или же система определяет права пользователя. Это
необходимо, так как у работодателя и администратора разные права, на выполнение
каких либо операций в системе. И завершающим этапом является отображение
главной страницы.
Заполнение заявки.
Рисунок 23. Диаграмма последовательности «Заполнение
заявки»
Рисунок 24. Диаграмма кооперации «Заполнение заявки»
Работодатель открывает окно заявки, формирует запрос
на добавление заявки, далее открывается форма, в котором работодатель
осуществляет заполнение заявки, последняя содержит такие атрибуты как:
наименование организации, должность, заработная плата, дата открытия,
количество мест, требован6ия к соискателю, а также график работы. После этого
система управления заявками проверяет заполненность полей, в случае если
какое-то поле не заполнено, то система сообщает ошибке, в противном случае,
заявка, заполненная работодателем, сохраняется. После этого управляющий класс
Управление заявками создаёт данную вакансию, и происходит ее передача
хранилище заявок. В результате чего, класс Заявка обновляется.
Регистрация работодателя.
Рисунок 25. Диаграмма последовательности «Регистрация
работодателя»
Рисунок 26. Диаграмма кооперации «Регистрация работодателя»
Для регистрации работодателя, он открывает окно
регистрации. И осуществляет заполнение необходимой информацией при этом,
заполнение происходит в два этапа, сначала работодатель вносит сведения об
организации, потом только свой логин, пароль, контрольный вопрос. Суть
заполнения в два этапа заключается в том, что в случае, если работодатель забыл
о своей регистрации и после продолжительного времени хочет вновь зарегистрироваться,
то при внесении сведений об организации, и при инициировании к дальнейшему
этапу заполнения, система выведет уведомление о том, что такая организация уже
была зарегистрирована. После чего система предложит ввести контрольный вопрос,
подробное описание этой операции приведем позже. Итак, если организация
существует система выводит сообщение о уже существующей организации. Иначе,
отображается вторичная форма регистрации, работодатель заполняет данную форму,
инициирует сохранение. После чего управляющий класс проверяет учетную запись на
дублирование в случае ошибки, выводит сообщение. Если ошибок нет, то
управляющий класс инициирует создание нового работодателя, далее этот работодатель
добавляется в хранилище работодателей. В результате чего класс Работодатели обновляется.
Добавить вакансию.
Рисунок 27. Диаграмма последовательности «Добавить
вакансию»
Рисунок 28. Диаграмма кооперации «Добавить вакансию»
Работодатель добавляет вакансию путём открытия окна
Вакансий, далее он формирует запрос на добавление вакансии, т. е. нажимает
кнопку «Добавить вакансию». После чего открывается форма для заполнения,
работодатель заполняет форму, сохраняет. Далее пограничный класс посылает
запрос управляющему классу Управление вакансиями на создание вакансии, далее
создается вакансия, содержащая такую информацию, как: требования к соискателю,
должность, зарплата. Созданная вакансия добавляется в класс Вакансии, результатом
которого будет являться обновление класса Вакансии.
Редактирование заявки.
Рисунок 29. Диаграмма последовательности
«Редактирование заявки»
Рисунок 30. Диаграмма кооперации «Редактирование
заявки»
После
того, как работодатель осуществил заполнение заявки, администратор проверяет
правильность заполнения заявки. Для этого он открывает Окно списка заявок,
далее пограничный класс передаёт сообщение управляющему классу о получении всех
заявок, в свою очередь управляющий класс передаёт сообщение классу Заявки о
получении заявок. Далее заявки отображаются в окне списка заявок, Администратор
выбирает заявку для редактирования, если таковая имеется, данная заявка отображается
в Окне заявки. После чего Администратор редактирует отображённую заявку,
сохраняет ее. Пограничный класс Окно заявки передаёт сообщение управляющему
классу Управление заявками о сохранении. В свою очередь управляющий класс
осуществляет сохранение в классе Заявки, итогом которого будет являться
обновление объекта Заявки.
Создать статью.
Рисунок 31. Диаграмма последовательности «Создать
статью»
Рисунок 32. Диаграмма кооперации «Создать статью»
Создание статьи осуществляет Администратор, для этого
он открывает окно статей, далее формирует запрос на добавление статьи, система
отображает форму для заполнения или добавление статьи, указанием пути к файлу.
Администратор сохраняет статью. После чего пограничный класс Окно статей
создаёт статью через управляющий класс Управление статьями. В результате,
которого происходит добавление статьи в класс Статьи и обновление.ате которго поисходит добавленией добавляетма отображее
Заявкисохраненииильность опрос, подробное описание которого при
Удалить статью.
Рисунок 33. Диаграмма последовательности «Удалить
статью»
Рисунок 34. Диаграмма кооперации «Удалить статью»
Администратор
удаляет статью, в случае если данная статья устарела. Для того чтобы её
удалить, Администратор открывает окно статей. Пограничный класс отправляет
запрос на получение статей классу Статьи, через управляющий класс Управление
статьями, сначала статьи загружаются в класс Управление статьями, в свою
очередь он отображает данные статьи в Окно статей. Далее администратор выбирает
статью для удаления, данная операция отображается в Окне подтверждения,
Администратор подтверждает удаление выбранной им статьи, при этом у каждой
статьи есть свой идентификатор, по которому система узнаёт именно эту статью.
Завершающим этапом является удаление статьи и обновление класса Статьи.
Восстановить пароль.
Рисунок 35. Диаграмма последовательности
«Восстановить пароль»
Рисунок 36. Диаграмма кооперации «Восстановить
пароль»
Восстановление пароля осуществляет работодатель, в
случае если он забыл свой пароль. Для этого работодатель открывает «Окно для
восстановления пароля», далее открывается форма для внесения логина и
контрольного вопроса. В случае если работодатель ввёл неправильный контрольный
вопрос, выдается сообщение об ошибке. Иначе работодатель вводит новый пароль
для восстановления своей регистрации. Результатом будет регистрация работодателя
и обновление хранилища «Работодатели».
Создать резюме.
Рисунок 37. Диаграмма последовательности «Создать
резюме»
Рисунок 38. Диаграмма кооперации «Создать резюме»
Администратор
для создания резюме открывает окно резюме, формирует запрос на формирование
резюме, открывается форма для заполнения. В этой форме для создания резюме
заполняются все данные о соискателе, кроме личных данных. Сообщение о создании
резюме передаётся в управляющий класс «Управление резюме», далее создается
резюме. Созданное резюме добавляется в список резюме. И завершающим этапом является
обновление контейнера списка резюме.
Удалить резюме.
Рисунок 39. Диаграмма последовательности «Удалить резюме»
Рисунок 40. Диаграмма кооперации «Удалить резюме»
Администратор
удаляет резюме, в случае если соискатель уже не нуждается в услугах кадрового
агентства. Для этого администратор открывает окно для удаления. После чего
пограничный класс «Окно резюме» посылает сообщение управляющему классу «Управление
резюме» о получении списка резюме, последний отображает все резюме, администратор
выбирает резюме для удаления, выбранное резюме отображается. Далее администратор
нажимает на кнопку «Удалить», администратор подтверждает удаление, и резюме
успешно удаляется. Завершающей процедурой является обновление списка резюме.
Проектирование
статической структуры ИС.
Диаграмма статической структуры системы – это
конечная диаграмма классов, которая представляет собой взаимосвязь между всеми
классами, выявленными в процессе проектирования системы.
Начальная диаграмма классов была описана нами в главе
«Выявление классов сущностей» и представлена на рисунке 31.
В процессе построения диаграмм взаимодействий
(последовательностей и коопераций) нами было выделено еще несколько
классов-контейнеров и других элементов системы, обладающих своим набором
операций (управляющие классы и пограничные (интерфейсные) классы).
1. Классы:
·
Анкеты;
·
Заявки;
·
Работодатели;
·
Вакансии;
·
Статьи.
2. Управляющие классы:
·
Управление анкетами;
·
Управление заявками;
·
Управление работодателями;
·
Управление вакансиями;
·
Управление статьями;
·
Окно подтверждения удаления.
3. Пограничные классы:
·
Окно Главная страница;
·
Окно анкеты;
·
Окно вакансий;
·
Окно для входа в систему;
·
Окно регистрации;
·
Окно заявки;
·
Окно списка заявок;
·
Окно статей.
Рассмотрим диаграммы статической структуры
проектируемой нами системы, делая акценты на взаимосвязях отдельных видов
классов системы.
Рисунок 41. Диаграмма статической
структуры (Взаимосвязь пограничных классов и классов-сущностей системы)
Рисунок 42. Диаграмма статической
структуры (Взаимосвязь управляющих классов и классов-сущностей системы)
Рисунок 43. Проектирование статической структуры
(Взаимосвязь пограничных (интерфейсных) классов и управляющих классов системы)
Заключение.
В ходе проделанной мной части курсовой работы, были
построены: диаграммы прецедентов, диаграммы видов деятельности, которые
позволяют более детализировано отобразить последовательность действий для
выполнения того или иного прецедента; диаграммы последовательности и
кооперации (взаимодействия) для всех прецедентов, которые наглядно отражают
последовательный процесс взаимодействия. Также в данной работе была
представлена статическая структура нашей информационной системы, служащая
источником информации не только о том, какие классы, помимо сущностей, выявленных
в начале разработки должны существовать в системе, но и показывающая как они
взаимодействуют и связаны друг с другом, а также какими методами они обладают.
В процессе разработки моей части курсового проекта
были выявлены следующие пограничные классы: окно Главная страница, окно анкеты,
окно вакансий, окно для входа в систему, окно регистрации, окно заявки, окно списка
заявок, окно статей. Также были созданы управляющие классы: управление
анкетами, управление заявками, управление работодателями, управление
вакансиями, управление статьями.
Так как, я еще довольно не опытный проектировщик
информационных систем, то в ходе выполнения курсовой работы я сталкивался с определенными
проблемами, но, как правило, они носили субъективный характер.
Следует сказать, что к недостаткам данной части
курсового проекта можно отнести, плохую детализацию небольшого числа диаграмм
курсового проекта, в виду либо невозможности более детального рассмотрения,
либо непонятности нужды рассмотрения прецедента более детально.
Эта часть курсового проекта была выполнена с помощью
программного продукта Rational Rose Enterprise Edition 2003.
СПИСОК
ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
Столбовский Д.Н. Курс лекций по проектированию
информационных систем.