Определение стандартов:
Определение и поддержка стандартов обеспечивается с помощью словаря доменов Domain Dictionary, редактора стандартов именования Naming Standards Editor и редактора стандартов типов данных Datatype Standards Editor. Словарь доменов содержит многократно используемые атрибуты и обеспечивает непротиворечивость имен и определений в рамках модели. Редактор стандартов именования позволяет пользователям создавать словари разрешенных терминов, аббревиатур и правил именования, которые могут использоваться повторно в рамках модели. Редактор стандартов типов данных позволяет определять собственные правила соответствия между типами данных разных СУБД.
Поддержка нескольких нотаций моделирования. Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM).
Управление большими моделями:облегчает управление большими корпоративными моделями за счет использования предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области позволяют конкретным проектировщикам фокусировать внимание, разделяя модель на более мелкие, и за счет этого легче управляемые подмодели. Хранимые отображения предоставляют разные варианты графического представления модели или ее предметных областей, облегчая обмен информацией между специализированными группами пользователей.
Полное сравнение/синхронизация (Complete Compare):
Эта мощная технология автоматизирует полную двунаправленную синхронизацию модели, скриптов и баз данных. При синхронизации для выбранных пользователем объектов отображаются отличия, и пользователю предлагается выбрать, какие из обнаруженных отличий и в каком направлении необходимо внести. При этом AllFusion ERwin Data Modeler (ERwin) может автоматически сгенерировать ALTER-скрипт на изменение.
Генерация структуры базы данных:позволяет автоматически сгенерировать структуру базы данных из модели. Входящие в продукт оптимизированные шаблоны триггеров ссылочной целостности и богатый макроязык, совместимый с различными типами баз данных, позволяют пользователю настроить триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают генерацию законченной физической структуры базы данных и полных определений (для соответствующей целевой базы данных).
Проектирование хранилищ и витрин данных:
Производительность, удобство в использовании и ценность хранилища данных напрямую зависит от модели, лежащей в его основе. ERwin поддерживает техники моделирования, характерные для проектирования хранилищ данных, такие как многомерное моделирование по схеме "звезда" или "снежинка", которые гарантируют, что хранилище данных оптимизировано как по производительности, так и по аналитическим возможностям. Кроме того, продукт способен собирать и документировать широкий спектр информации о хранилище данных, в том числе об источниках данных, логике трансформации данных и правилах управления данными.
Обратное проектирование:позволяет провести автоматическую обратную генерацию структуры базы данных в модель для ее изучения и документирования и/или для последующей миграции на платформу другой СУБД.
Графические объекты:
С помощью графических объектов ERwin обеспечивает наглядное представление бизнес-правил. Графические объекты, например линии, эллипсы и другие, легко редактируются. Разработчики моделей могут также настраивать параметры шрифта и цвета объектов.
Навигатор модели (Model Explorer):Explorer - это удобный в использовании инструмент, обеспечивающий навигацию по модели, а также выбор объектов для их анализа или редактирования. Помимо традиционного изображения модели в виде диаграммы, Model Explorer обеспечивает компактное упорядоченное представление модели и ее содержимого.
Полный набор возможностей Undo/Redo. AllFusion ERwin Data Modeler (ERwin) предоставляет полный комплект возможностей «отменить/вернуть изменения» в пределах сессии моделирования. Возможности Undo/Redo могут быть применимы ко всем задачам моделирования, включая изменения размещения и создание/обновление/удаление объектов. Отменяя конкретные изменения модели, пользователи могут полностью понимать влияния этих действий.
Создание и печать отчетов:
Ключевым элементом, обеспечивающим коммуникацию и совместную работу пользователей в процессе моделирования, является способность визуализации и публикации данных. ERwin предоставляет гибкие, настраиваемые возможности создания отчетов и печати. Два встроенных построителя шаблонов отчетов: ERwin Data Browser и Report Template Builder - позволяют однократно разработать шаблон отчета, который впоследствии будет доступен для использования в любых моделях для генерации отчетов в любом из форматов: HTML, RTF, TXT, PDF.
Встроенная технология обмена метаданными:
Встроенная передовая технология предоставляет возможность обмена метаданными между ERwin и другими средствами, такими как MS Excel, XSD, XMI, CWM, ведущими ETL/EII-инструментами, многочисленными средствами BI/Reporting, а также с широким спектром сред моделирования такими, как: Rational Data Architect, Oracle Designer, Sybase Power Designer и другими - всего порядка 100 популярных продуктов. Данная технология позволяет сэкономить временные и материальные ресурсы благодаря устранению необходимости перепроектировать модели.
Поддерживаемые СУБД: Oracle; DB2/UDB (включая iSeries); SQL Server; Teradata; ODBC; Sybase; Informix; Ingres; Progress; Access.
Поддерживаемые ОС: Windows 2000; Windows XP; Windows 2003 Server.
Интеграция с другими продуктами:ERwin Data Modeler интегрирован с широким спектром сред моделирования, такими как Rational Data Architect, Oracle Designer, Sybase Power Designer и др.
ERWin был выбран, так как он предоставляет возможности создания диаграмм баз данных, необходимых при разработке АИС и наличия всех необходимых компонентов для выполнения указанных целей;
Выбор BPWin основан на необходимости определения бизнес-процессов исследуемой области. Данный инструмент предоставляет все нужные возможности и удобен в использовании.
Также оба инструмента достаточно просты в
освоении, что позволило выделить больше времени на саму разработку [26].
.2 Определение бизнес-процессов
Для реализации разрабатываемой АИС необходимо построение функциональной модели для выделения основных выполняемых системой бизнес-процессов.
При построении модели использована методология функционального моделирования IDEF0.
На верхнем уровне представлена система АРМ специалиста по работе с персоналом (рис. 2).
К входным данным относятся:
1. персональные данные соискателя такие, как ФИО, адрес электронной почты и пароль для входа в систему;
. направление работы, которое отражает
желаемую вакансию. От направления зависит, какой специалист будет работать с
данным соискателем.
Рисунок 2 - Контекстная
диаграмма верхнего уровня бизнес-процессов
К блоку управления относятся:
3. должностная инструкция специалиста отдела кадров и руководителя направления (данный документ также определяет рамки и правила общения с соискателем);
. условия приёма, на основе которых будет происходить принятие решения о приёме на работу;
. правила регистрации, которые необходимы для определения полей при регистрации и правил, по которым будут проверяться введённые данные.
Блок механизма состоит из специалистов по работе с персоналом, администратора системы и руководителя направления.
К выходным данным относится только решение о статусе соискателя, то есть будет ли он принят или же нет.
На втором уровне происходит разделение системы на три процесса (рис. 3).
Рисунок 3 - Схема декомпозиции
второго уровня бизнес-процессов
Первым процессом в порядке работы системы является регистрация. Он предполагает регистрацию пользователя в системе с последующей отправкой сообщения на почту для подтверждения регистрации, а так же авторизацию пользователя в системе по его данным. Он принимает все входные данные и в качестве управления использует правила регистрации.
Выходными данным для процесса регистрации являются данные соискателя, который прошел авторизацию в системе.
К блоку механизма относится администратор системы, который необходим для регистрации специалистов и других пользователей с расширенными правами.
Вторым процессом является, непосредственно, работа с соискателем по выбранному направлению. Этот процесс управляется должностной инструкцией и как механизм принимает специалиста по работе с персоналом и руководителя направления.
Работа с соискателем представляет собой ведение диалога между обеими сторонами с возможностью обмена файлами для пересылки резюме и отправки тестового задания. Так же через диалог объявляется решение о статусе соискателя и решение о принятии на работу.
Выходными данными для данного процесса являются результаты работы с соискателем либо отказ в приёме на работу, по результатам тестового задания или диалога.
Третьим процессом системы определено принятие решения. Управлением являются условия приёма, а механизмом специалист по работе с персоналом и руководитель отдела. Принятие решения строится на результатах работы с соискателем, по данным резюме, диалога, тестового задания. Специалист сравнивает результаты с правилами приёма, а руководитель отдела выносит решение о приёме на работу или отказе в приёме. После подтверждения кандидатуры начальником направления, специалист извещает соискателя.
Выходными данными является
решение о статусе соискателя.
Рисунок 4 - Схема декомпозиции блока «Регистрация»
Регистрация также разбита на три процесса.
Первым процессом выступает заполнение формы регистрации. Входными данными являются выбранное направление работы и персональные данные соискателя, в роли управления выступают правила регистрации.
Второй процесс является подтверждением регистрации, путём отправки письма-запроса на почту кандидата. К входным данным относится сам запрос подтверждения, выходными данными является ответ на запрос подтверждения регистрации.
Третьим процессом выступает
определение статуса пользователя. Входными данными являются данные из формы
регистрации, которую заполняет пользователь. Если пользователю необходимы
расширенные права - дополнительно подключается блок механизма в виде
администратора системы. В роли выходных данных выступают данные пользователя.
Рисунок 5 - Схема декомпозиции блока «Подтверждение регистрации»
Подтверждение регистрации делится на следующие процессы: Формирование письма-запроса для подтверждения регистрации, подтверждение регистрации пользователем и регистрация пользователя в системе.
Входными данными для первого процесса выступает запрос подтверждения регистрации, выходными - письмо-запрос подтверждения регистрации.
Для процесса «Подтверждение регистрации пользователем» входными данными является письмо-запрос подтверждения регистрации, а выходными - ответ пользователя на запрос о регистрации.
У процесса «Регистрация
пользователя в системе» входными данными выступает ответ на запрос о
регистрации, а выходными данными - подтверждение успешной регистрации
пользователя в системе.
Рисунок 6 - Схема декомпозиции блока «Работа с соискателем»
Процесс «Работа с соискателем» разделён на три процесса «Проверка ответа на тестовое задание», «Проведение интервью с кандидатом», «Просмотр резюме, результатов тестового задания и отзыва руководителя отдела».
У процесса «Проверка ответа на тестовое задание» входными данными являются данные пользователя, в число которых входит ответ на тестовое задание. В роли выходных данных выступают отказ в приёме на работу и результат выполнения тестового задания, а блоком механизма является руководитель отдела.
Процесс «Проведение интервью с кандидатом» имеет в виде входящих данных результат выполнения тестового задания, выходящих - результаты интервью. Блоком управления выступает должностная инструкции специалиста по работе с персоналом, а блоком механизма являются руководитель отдела и специалист по работе с персоналом.
У третьего процесса входящими данными выступают результаты интервью, выходящими данными являются результаты работы с соискателем, а блоком механизма - специалист по работе с персоналом.
5. Разработка модели БД
При проектировании автоматизированной информационной системы построена физическая модель базы данных, представленная на рисунке 7.
Таблица hrw_page отражает основные страницы системы, такие как страница регистрации, авторизации и другие. Данная таблица состоит из 6 полей:
1. id - уникальный идентификатор страницы, для обращения к ней при необходимости;
2. title - поле, хранящее заголовок страницы;
3. alias - поле, в котором хранится псевдоним страницы, отображаемый в адресной строке браузера;
4. template_id - данное поле, определяет по уникальному идентификатору шаблон, который необходимо использовать для формирования страницы;
5. group_id - данное поле определяет к какому типу относится страница;
6. content_filename - в этом поле указывается имя файла, из которого на страницу подгружается содержимое.
В hrw_cgroup хранится информация о группах специалистов. Группы могут быть как предустановленные, так и созданные специалистом. Таблица имеет четыре поля:
1. id - уникальный идентификатор группы, для обращения к ней при необходимости;
2. user_id - в данном поле хранится информация о создателе-владельце группы в виде его уникального идентификатора;
3. title - хранит название группы;
4. color - в этом поле хранится цвет метки, расположенной слева от наименования группы. Цвет может быть предустановленным для системных групп, и может назначаться специалистом для пользовательских групп.
В таблице hrw_user хранятся данные о пользователях, зарегистрированных в системе. В данной таблице 17 полей:
1. id - уникальный идентификатор пользователя, по которому в любой момент можно обратиться конкретно к этому пользователю;
2. login - уникальное имя на латинице, которое пользователь использует для входа в систему;
3. password - данное поле хранит пароль пользователя в зашифрованном виде, шифрование происходит по алгоритму хэш SHA-512. Текущий алгоритм выбран из-за высокой степени защиты, которая дополнительно усиливается использованием модификатора, так называемой, «соли».
4. salt - в этом поле хранится модификатор пароля, который повышает стойкость пароля к дешифровке;
5. email - данное поле хранит адрес электронной почты специалистов и кандидатов;
6. first_name, middle_name, last_name - в этих полях хранятся соответственно имя, фамилия и отчество пользователя;
7. direction_id - поле хранит уникальный идентификатор направления, на которое претендует кандидат, у специалистов в данном поле всегда 0;