Диаграмма последовательностей

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

“ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ”

Факультет компьютерных наук

Информационная система службы занятости

Отчет по практикуму для курса «Информационные технологии»

Студент __________

Руководитель __________Михайлов Е. М.

Воронеж 2008

Содержание

Постановка задачи………………………………………………………………...3

Анализ требований (Use-Case диаграмма)………………………………………5

Диаграмма классов………………………………………………………………..7

Диаграмма последовательностей………………………………………………...9

Диаграмма коопераций………………………………………………………….10

Диаграмма состояний………………………………………………………........11

Диаграмма активности…………………………………………………………..12

Диаграмма компонентов………………………………………………………...14

Диаграмма развертывания………………………………………………………15
Постановка задачи

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

Служба занимается сбором и хранением информации о вакансиях и резюме, работая с двумя типами клиентов: частными лицами, размещающими в системе свои резюме, и компаниями, оставляющими сведения об их вакантных местах.

Каждое резюме имеет следующие параметры:

· фамилия

· имя

· отчество

· пол

· возраст

· внешние данные

· образование

· специальность

· опыт работы

· размер желаемой заработной платы

· желаемая должность

· желаемый график работы

Данные о вакансии делятся на два типа: данные о компании-работодателе и самой вакансии, а также требования к претенденту.

Данные о компании:

· название организации-работодателя

· название вакансии

· описание обязанностей

· предполагаемая заработная плата

· предполагаемый график работы

Требования к претенденту:

· образование

· специализация

· специальные навыки

· опыт работы

· пол

· возраст

· внешние данные

· и др.

Соискатель может отослать свое резюме службе занятости, позже удалить или поменять его. Соответвенно, то же самое могут в контексте вакансии делать и компании-работодатели, с условием, что резюме от одного клиента может быть только одно, но вакансий от компании несколько. В свою очередь, служба занятости следит за корректностью присылаемых ей данных, а также выдает информацию по произвольному запросу. При этом клиент может отказываться от предлагаемых вакансий не более n раз, иначе он автоматически перестает быть клиентом службы занятости. Аналогичные требования предъявляются и к компаниям-работодателям.

Также служба занятости может организовывать курсы повышения квалификации для безработных. Информация о возможных курсах предоставляется организациями, осуществляющими обучение.

Анализ требований (Use-Case диаграмма)

Очень хорошо анализ требований к системе и ее возможностей виден на следующей Use-Case диаграмме:

Акторы:

· Клиент – физическое лицо, ищущее работу

· Компания – юридическое лицо, размещающее вакансии

· Администратор службы занятости – сотрудник службы занятости, занимающийся ручной проверкой присылаемых данных, а также следящий за корректностью работы системы

Варианты использования:

· Размещение/изменение резюме – размещение (отсылка в службу занятости) либо изменение клиентом собственного резюме. Примечание: клиент может иметь только одно резюме

· Удаление резюме – удаление клиентом-физическим лицом своего резюме

· Размещение/изменение вакансии – размещение либо изменение вакансиии компанией-работодателем. Примечание: одна компания может размещать больше одной вакансии

· Удаление вакансии – удаление компанией-работодателем вакансии

· Организация курсов – организация курсов повышения квалификации службой занятости для клиентов-соискателей

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

· Отсылка предложения – предложение подходящих вакансий/резюме клиенту/компании службой занятости

· Общение клиента и компании – происходит в случае принятия обеими сторонами предложения службы занятости

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

· Удаление данных – удаление администратором некорректных данных после проверки

· Добавление данных в базу – добавление администратором данных в базу службы занятости после проверки

Диаграмма классов

Здесь приводится примерная диаграмма классов будущего приложения, а также пояснения к ней.

Прежде всего, классы по логике делятся на три вида: Model, Controllers и View. Model – логическая часть приложения, классы, отвечающие за данные и их связи, такие как CV, User, Firm. Controllers – классы, отвечающие за различные виды контроля: аутентификация, права доступа, регистрация. View – классы, отвечающие за представление данных.

Описание предполагаемых классов:

· Employeer – клиент, его данные, ссылка на резюме

· CV – класс для описания резюме клиента

· Firm – класс-описание компании-работодателя, ссылки на вакансии

· Vacancy – описание вакансии

· User – класс для описания пользователя системы (логин, пароль, роль)

· Role – класс для описания «роли» пользователя в системе - его права, возможности и т.д.

· DBController – класс, отвечающий за работу с БД (выполнение запросов, коннекты и т.д.)

· Authentification – класс, отвечающий за аутентификацию пользователя

· FrontController – класс-общий контроллер, регулирующий работу со всеми остальными, содержит такие методы, как, например, регистрация, размещение вакансий/резюме и т.д.

· AccessControlList – класс, проверяющий , имеет ли конкретный пользователь право совершать то или иное действие

· Template – класс, отвечающий за визуальное представление данных

Диаграмма последовательностей

Здесь приведена диаграмма последовательностей для ситуации входа пользователя в систему.

Основные используещиеся в системе сообщения:

· LoginRequest – попытка пользователя перейти на страницу с формой для входа в систему

· Login – пользователь отсылает системе свои логин и пароль

· ShowTemplate – запрос контроллера на шаблон определенной страницы

· TryAuth – обращение контроллера к классу аутентификации, чтобы узнать, есть ли в системе пользователь с таким именем и паролем

Диаграмма кооперации

Диаграмма кооперации для того же самого случая входа пользователя в систему будет выглядеть следующим образом:

Т.к. сообщения те же самые, что и в предыдущей диаграмме, они приводиться тут не будут.
Диаграмма состояний

На диаграмме состояний приводится набор состояний того или иного объекта и последовательность переходов от одного состояния к другому.

Диаграмма состояний для клиента службы занятости:

Аналогичная диаграмма для компании-работодателя:

Диаграмма активности

Диаграмма активности является расширением диаграммы состояний:

На нашей диаграмме активности присутствуют 3 части(дорожки): клиент(пользователь), сервер(осуществляет управление) и БД(только выполняет запросы).

Диаграмма компонентов

Приведенная ниже диаграмма компонентов показывает, каким образом взаимодействуют между собой модули системы. В нашем случае у нас реализована модель тонкого клиента, т.е. вся логика реализована на стороне сервера, на стороне клиента только запущен браузер, отсылающий запросы серверу. На сервере же создан экземпляр класса FrontController, которому передано управление всеми остальными контроллерами.

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

Диаграмма развертывания

Диаграмма развертывания показывает, каким образом работает наше приложение в целом, т.е. его топологию (где какие процессы выполняются, как с этим взаимодействуют пользователи). В данном случае предполагается, что существует один сервер, на котором содержатся БД и общее управление. С клиентских машин серверу посылаются запросы, которые он сам обрабатывает и интерпретирует. Со стороны пользователя это выглядит так: пользователь выходит в интернет, заходит на сайт и работает с ним: