Разработка клиентского модуля автоматизированного рабочего места специалиста по работе с персоналом
Анализ программных средств для решения задач по управлению персоналом. Автоматизированные информационные системы и их классификация. Разработка технических требований и архитектуры клиентской части. Характеристика web-технологий. Разработка алгоритмов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 19.01.2017 |
| Размер файла | 3,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Правила CSS пишутся на формальном языке CSS и располагаются в таблицах стилей, то есть таблицы стилей содержат в себе правила CSS. Эти таблицы стилей могут располагаться как в самом веб-документе, внешний вид которого они описывают, так и в отдельных файлах, имеющих формат CSS. (По сути, формат CSS -- это обычный текстовый файл. В файле.css не содержится ничего, кроме перечня правил CSS и комментариев к ним.)
То есть, эти таблицы стилей могут быть подключены, внедрены в описываемый ими веб-документ четырьмя различными способами:
1. когда таблица стилей находится в отдельном файле, она может быть подключена к веб-документу посредством тега <link>, располагающегося в этом документе между тегами <head> и </head>. (Тег <link> будет иметь атрибут href, имеющий значением адрес этой таблицы стилей). Все правила этой таблицы действуют на протяжении всего документа;
2. когда таблица стилей находится в отдельном файле, она может быть подключена к веб-документу посредством директивы @import, располагающейся в этом документе между тегами <style> и </style> (которые, в свою очередь, располагаются в этом документе между тегами <head> и </head>) сразу после тега <style>, которая также указывает (в своих скобках, после слова url) на адрес этой таблицы стилей. Все правила этой таблицы действуют на протяжении всего документа;
3. когда таблица стилей описана в самом документе, она может располагаться в нём между тегами <style> и </style> (которые, в свою очередь, располагаются в этом документе между тегами <head> и </head>). Все правила этой таблицы действуют на протяжении всего документа;
4. когда таблица стилей описана в самом документе, она может располагаться в нём в теле какого-то отдельного тега (посредством его атрибута style) этого документа. Все правила этой таблицы действуют только на содержимое этого тега.
В первых двух случаях говорят, что к документу применены внешние таблицы стилей, а во вторых двух случаях -- внутренние таблицы стилей.
До появления CSS оформление веб-страниц осуществлялось исключительно средствами HTML, непосредственно внутри содержимого документа. Однако с появлением CSS стало возможным принципиальное разделение содержания и представления документа. За счёт этого нововведения стало возможным лёгкое применение единого стиля оформления для массы схожих документов, а также быстрое изменение этого оформления.
Преимущества:
1. несколько дизайнов страницы для разных устройств просмотра. Например, на экране дизайн будет рассчитан на большую ширину, во время печати меню не будет выводиться, а на КПК и сотовом телефоне меню будет следовать за содержимым;
2. уменьшение времени загрузки страниц сайта за счет переноса правил представления данных в отдельный CSS-файл. В этом случае браузер загружает только структуру документа и данные, хранимые на странице, а представление этих данных загружается браузером только один раз и может быть закэшировано;
3. простота последующего изменения дизайна. Не нужно править каждую страницу, а лишь изменить CSS-файл;
4. дополнительные возможности оформления. Например, с помощью CSS-вёрстки можно сделать блок текста, который остальной текст будет обтекать (например, для меню) или сделать так, чтобы меню было всегда видно при прокрутке страницы.
Недостатки:
1. различное отображение вёрстки в различных браузерах (особенно устаревших), которые по-разному интерпретируют одни и те же данные CSS;
2. часто встречающаяся необходимость на практике исправлять не только один CSS-файл, но и теги HTML, которые сложным и ненаглядным способом связаны с селекторами CSS, что иногда сводит на нет простоту применения единых файлов стилей и значительно удлиняет время редактирования и тестирования.
CSS -- одна из широкого спектра технологий, одобренных консорциумом W3C и получивших общее название «стандарты Web». В 1990-х годах стала ясна необходимость стандартизировать Web, создать какие-то единые правила, по которым программисты и веб-дизайнеры проектировали бы сайты. Так появились языки HTML 4.01 и XHTML, и стандарт CSS.
В начале 1990-х различные браузеры имели свои стили для отображения веб страниц. HTML развивался очень быстро и был способен удовлетворить все существовавшие на тот момент потребности по оформлению информации, поэтому CSS не получил тогда широкого признания.
Термин «каскадные таблицы стилей» был предложен Хокон Виум Ли в 1994 году. Совместно с Бертом Босом он стал развивать CSS.
В отличие от многих существовавших на тот момент языков стиля, CSS использует наследование от родителя к потомку, поэтому разработчик может определить разные стили, основываясь на уже определенных ранее стилях.
В середине 1990-х Консорциум Всемирной паутины (W3C) стал проявлять интерес к CSS, и в декабре 1996 года была издана рекомендация CSS1 [22].
Выбор CSS был обусловлен необходимостью настраивать страницы сервиса под единый стиль и поддержкой большинством популярных платформ.
JavaScript:
JavaScript -- прототипно-ориентированный сценарный язык программирования. Является диалектом языка ECMAScript.
JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.
Основные архитектурные черты: динамическая типизация, слабая типизация, автоматическое управление памятью, прототипное программирование, функции как объекты первого класса.
На JavaScript оказали влияние многие языки, при разработке была цель сделать язык похожим на Java, но при этом лёгким для использования непрограммистами. Языком JavaScript не владеет какая-либо компания или организация, что отличает его от ряда языков программирования, используемых в веб-разработке.
Название «JavaScript» является зарегистрированным товарным знаком компании Oracle Corporation.
JavaScript является объектно-ориентированным языком, но используемое в языке прототипирование обуславливает отличия в работе с объектами по сравнению с традиционными класс-ориентированными языками. Кроме того, JavaScript имеет ряд свойств, присущих функциональным языкам -- функции как объекты первого класса, объекты как списки, карринг, анонимные функции, замыкания -- что придаёт языку дополнительную гибкость.
Несмотря на схожий с Си синтаксис, JavaScript по сравнению с языком Си имеет коренные отличия:
1. объекты, с возможностью интроспекции;
2. функции как объекты первого класса;
3. автоматическое приведение типов;
4. автоматическая Сборка мусора;
5. анонимные функции.
5.1. В языке отсутствуют такие полезные вещи, как:
6. модульная система: JavaScript не предоставляет возможности управлять зависимостями и изоляцией областей видимости;
7. стандартная библиотека: в частности, отсутствует интерфейс программирования приложений по работе с файловой системой, управлению потоками ввода-вывода, базовых типов для бинарных данных;
8. стандартные интерфейсы к веб-серверам и базам данных;
9. система управления пакетами, которая бы отслеживала зависимости и автоматически устанавливала их.
Синтаксис языка JavaScript во многом напоминает синтаксис Си и Java, семантически же язык гораздо ближе к Self, Smalltalk или даже Лиспу.
В JavaScript:
1. все идентификаторы регистрозависимы;
2. в названиях переменных можно использовать буквы, подчёркивание, символ доллара, арабские цифры;
3. названия переменных не могут начинаться с цифры;
4. для оформления однострочных комментариев используются //, многострочные и внутристрочные комментарии начинаются с /* и заканчиваются */.
Структурно JavaScript можно представить в виде объединения трёх чётко различимых друг от друга частей:
1. ядро (ECMAScript);
2. объектная модель браузера (Browser Object Model или BOM (en));
3. объектная модель документа (Document Object Model или DOM).
Если рассматривать JavaScript в отличных от браузера окружениях, то объектная модель браузера и объектная модель документа могут не поддерживаться.
Объектную модель документа иногда рассматривают как отдельную от JavaScript сущность, что согласуется с определением DOM как независимого от языка интерфейса документ. В противоположность этому ряд авторов находят BOM и DOM тесно взаимосвязанными.
ECMAScript не является браузерным языком и в нём не определяются методы ввода и вывода информации. Это, скорее, основа для построения скриптовых языков. Спецификация ECMAScript описывает типы данных, инструкции, ключевые и зарезервированные слова, операторы, объекты, регулярные выражения, не ограничивая авторов производных языков в расширении их новыми составляющими.
Объектная модель браузера -- браузер-специфичная часть языка, являющаяся прослойкой между ядром и объектной моделью документа. Основное предназначение объектной модели браузера -- управление окнами браузера и обеспечение их взаимодействия. Каждое из окон браузера представляется объектом window, центральным объектом DOM. Объектная модель браузера на данный момент не стандартизирована, однако спецификация находится в разработке WHATWG и W3C.
Помимо управления окнами, в рамках объектной модели браузера, браузерами обычно обеспечивается поддержка следующих сущностей:
1. управление фреймами;
2. поддержка задержки в исполнении кода и зацикливания с задержкой;
3. системные диалоги;
4. управление адресом открытой страницы;
5. управление информацией о браузере;
6. управление информацией о параметрах монитора;
7. ограниченное управление историей просмотра страниц;
8. поддержка работы с HTTP cookie.
Объектная модель документа -- интерфейс программирования приложений для HTML и XML-документов. Согласно DOM, документ (например, веб-страница) может быть представлен в виде дерева объектов, обладающих рядом свойств, которые позволяют производить с ним различные манипуляции:
1. генерация и добавление узлов;
2. получение узлов;
3. изменение узлов;
4. изменение связей между узлами;
5. удаление узлов.
Существует три способа подключения javascript:
1. расположение внутри страницы. Для добавления JavaScript-кода на страницу, можно использовать теги <script></script>, которые рекомендуется, но не обязательно, помещать внутри контейнера <head>. Контейнеров <script> в одном документе может быть сколько угодно. Атрибут «type='text/javascript'» указывать необязательно, так как по умолчанию стоит javascript;
2. расположение внутри тега. Спецификация HTML описывает набор атрибутов, используемых для задания обработчиков событий;
3. вынесение в отдельный файл. Есть и третья возможность подключения JavaScript -- написать скрипт в отдельном файле, а потом подключить его с помощью специальной конструкции.
Элемент script, широко используемый для подключения к странице JavaScript, имеет несколько атрибутов:
1. обязательный атрибут type для указания MIME-типа содержимого.
В запросе комментариев RFC-4329, определяющем MIME-тип, соответствующий JavaScript, указано:
Известно, что использование «text» в качестве типа верхнего уровня данного типа содержимого проблематично. Поэтому данный документ определяет text/javascript и text/ecmascript, отмечая их «устаревшими». Использование экспериментальных и незарегистрированных медиатипов, таких как перечисленные в части выше, не приветствуется.
Медиатипы:
1. application/javascript;
2. application/ecmascript,
которые также определяются в этом документе, предназначены для практического использования, им следует отдавать предпочтение.
Однако, согласно спецификации HTML 4.01 в качестве значения type должно быть указано устаревшее "text/javascript". Так как JavaScript является языком программирования по умолчанию во всех браузерах, начиная с Netscape 2, Дуглас Крокфорд придерживается мнения о нецелесообразности использования атрибута type, рекомендуя указывать его в XHTML, так как, хотя он, по мнению Крокфорда, и не нужен, но обязателен, и не указывать в HTML.
2. необязательный атрибут «src», принимающий в качестве значения адрес к файлу со скриптом;
3. необязательный атрибут «charset», используемый вместе с src для указания используемой кодировки внешнего файла;
4. необязательный атрибут «defer» указывает, что получение скрипта происходит асинхронно, но выполнение следует отложить до тех пор, пока страница не будет загружена целиком.
5. необязательный атрибут «async» указывает, что получение скрипта происходит асинхронно, а выполнение будет произведено сразу по завершению скачивания. Очередность выполнения скриптов не гарантируется.
При этом атрибут language (language="JavaScript"), несмотря на его активное использование (в 2008 году этот атрибут был наиболее часто используемым у тега <script>), относится к устаревшим (deprecated), отсутствует в DTD, поэтому считается некорректным.
JavaScript используется в клиентской части веб-приложений: клиент-серверных программ, в котором клиентом является браузер, а сервером -- веб-сервер, имеющих распределённую между сервером и клиентом логику. Обмен информацией в веб-приложениях происходит по сети. Одним из преимуществ такого подхода является тот факт, что клиенты не зависят от конкретной операционной системы пользователя, поэтому веб-приложения являются кроссплатформенными сервисами.
Также, JavaScript используется в AjAX, Comet, браузерных операционных системах, букмарклеты, пользовательских скриптах в браузере, серверных приложениях, мобильных приложениях, виджетах, прикладном ПО, манипуляциях объектами приложений, офисных приложениях (например, Microsoft Office, OpenOffice).
JavaScript обладает пропедевтической ценностью, позволяя сочетать при обучении информатике интенсивную практику программирования и широту используемых технологий. Преподавание данного языка в школе позволяет создать базу для изучения веб-программирования, использовать на уроках творческие проекты. Соответствующий курс позволяет обеспечить углубленный уровень изучения информатики и его имеет смысл включать в элективные курсы углубленного уровня подготовки.
JavaScript -- подходящий язык для обучения программированию игр. По сравнению с альтернативами, он функционально достаточен, прост в изучении и в применении, снижает сложность для обучения, мотивирует обучаемых делиться своими играми с другими [23].
Если подвести итоги по проанализированным средствам разработки, то можно выделить следующие причины выбора каждого из средств:
HTML был выбран, как наиболее популярный язык разметки, который поддерживается всеми необходимыми платформами.
Причиной выбора PHP является его удобство в разработке и поддержка всеми необходимыми платформами.
СУБД MySQL была выбрана по причине бесплатного распространения и удобства настройки.
Выбор CSS был обусловлен необходимостью настраивать страницы сервиса под единый стиль и поддержкой большинством популярных платформ.
JavaScript был выбран из-за необходимости взаимодействовать с СУБД, простоты освоения и поддержки большинством популярных платформ.
3. Разработка технических требований и архитектуры клиентской части
3.1 Технические требования клиентской части
Технические требования к системе клиента:
Браузер: Любой, с поддержкой JavaScript, CSS 3;
Операционная система: Windows, Linux, Mac OS, OS X, *nix-системы;
Оперативная память: от 1 GB и выше;
Процессор: Intel Pentium 4 или более новый;
Технические требования к системе сервера:
Операционная система: Linux, Mac OS X, Solaris, Free BSD, Windows;
Оперативная память: от 2 GB;
Процессор: Intel Pentium 4 Core 2 Duo;
Памяти на жёстком диске: от 2 GB;
Дополнительное программное обеспечение: MySQL, Nginx (или любой другой HTTP-сервер с поддержкой MySQL);
3.2 Архитектура клиентской части
Информационная система состоит из 9 модулей, в зависимости от типа пользователя количество доступных модулей может меняться.
1. Модуль «Логин» является общедоступным и отвечает за авторизацию пользователей в системе;
2. модуль «Регистрация» также является общедоступным и отвечает за регистрацию кандидатов в системе. Кандидаты регистрируются в системе самостоятельно, в то время как специалисты регистрируются администратором системы. Также администратор системы может изменять данные пользователей, их права доступа или даже удалять пользователей из системы;
Рисунок 1 - Информационная архитектура клиентской части
3. модуль «Группы» доступен только для специалистов и администратора системы. В данном модуле расположены предустановленные и созданные специалистами группы, в которых размещаются соискатели. Специалист сам определяет, в какую группу поместить кандидата, чтобы с ним было удобно работать в дальнейшем. Также для групп ведено цветовое обозначение, выбираемое пользователем, которое позволит гораздо быстрее выделять нужную группу, если список будет достаточно большим;
4. модуль «Файлы» доступен только для специалистов и администратора системы. В этом модуле хранятся все файлы, загруженные специалистами данного направления. Для удобства работы организована настраиваемая иерархия каталогов. Пользователи, обладающие необходимыми правами, имеет возможность загружать, удалять, перемещать и совершать другие действия с файлами;
5. модуль «Список кандидатов» доступен только специалистам и администратору системы и отображает список кандидатов, у соискателей -- список специалистов. В данном модуле из списка выбирается пользователь, с которым будет проводиться работа: общение в чате, обмен файлами, получение информации и др. Также в данном модуле есть возможность заблокировать пользователю возможность обмениваться сообщениями со специалистами в чате или даже доступ к системе за нарушение культуры общения;
6. модуль «Чат» доступен всем типам пользователей. Он позволяет кандидатам и специалистам обмениваться друг с другом сообщениями и файлами. Файлы должны быть предварительно загружены в систему самими пользователями. Также в чате предусмотрен живой поиск, который позволяет быстро найти нужное сообщение или файл, которые были отправлены ранее;
7. модуль «Информация о кандидате» доступен только специалистам и администратору систему. В данном модуле хранится краткая информация о кандидате, который выбран в текущий момент. Она содержит ФИО кандидата, контактную информацию, сведения об образовании и др;
8. модуль «Файлы кандидата» доступен для всех типов пользователей, но у кандидата его название меняется на «Файлы». В данном модуле хранятся все файлы, которые кандидат загружает в систему. Действия, которые кандидат может совершать со своими файлами, аналогичны действиям специалистов и администраторов системы;
9. модуль «Заметки» доступен только специалистам и администратору системы. В данном модуле размещаются все заметки, которые специалисты оставляют о выбранном кандидате. По одному кандидату может быть создано несколько заметок. Также доступно редактирование заметок, созданных ранее.
4. Формализация бизнес-процессов автоматизированного рабочего места специалиста по работе с персоналом
4.1 Характеристика средств проектирования
4.1.1 CASE-средства
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Современный рынок программных средств насчитывает множество различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
1. мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
2. интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
3. использование специальным образом организованного хранилища проектных метаданных (репозитория);
4. репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
5. графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм, образующих модели ИС;
6. средства конфигурационного управления;
7. средства документирования;
8. средства тестирования;
9. средства управления проектом;
10. средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи, набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
1. применяемым методологиям и моделям систем и БД;
2. степени интегрированности с СУБД;
3. доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
1. средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области;
2. средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций. Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
3. средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer;
4. средства разработки приложений;
5. средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Вспомогательные типы включают:
1. средства планирования и управления;
2. средства конфигурационного управления;
3. средства тестирования;
4. средства документирования.
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; ERwin+BPwin; S-Designor; CASE.Аналитик; ArgoUML и др.[24]
4.1.2 AllFusion ERwin Data Modeler
CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания
ERwin предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.
ERwin позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоемких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных.
Данное решение улучшает коммуникацию в организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.
Ключевые характеристики AllFusion ERwin Data Modeler 7:
1. синхронизация моделей/баз данных;
2. автоматизированное создание структуры базы данных и обратное проектирование;
3. публикация моделей;
4. поддержка нотаций: IDEF1x, IE, Dimensional;
5. возможна совместная работа группы проектировщиков;
6. документирование структур баз данных;
7. перенос структур баз данных (но не самих данных) из одного типа СУБД в другой. [25]
Функциональные возможности ERwin:
Архитектура уровня проектирования. AllFusion ERwin Data Modeler (ERwin) имеет достаточную гибкость для разработки архитектуры связанных моделей данных, полностью удовлетворяющей потребностям организации. Наряду с комбинированной логической/физической моделью поддерживаются раздельные логические и физические модели. Благодаря накоплению знаний об отношениях между компонентами связанных моделей и ведению журнала проектных решений пользователи могут быстро определять влияние изменений одного уровня проектирования на другой.
Технология трансформации:
Физическая структура базы данных редко совпадает с исходной логической структурой. В целях повышения производительности бизнес-приложений часто требуется проводить денормализацию данных на физическом уровне модели. AllFusion ERwin Data Modeler (ERwin) позволяет автоматизировать процесс трансформации модели, сохраняя в целости исходный проект.
Определение стандартов:
Определение и поддержка стандартов обеспечивается с помощью словаря доменов Domain Dictionary, редактора стандартов именования Naming Standards Editor и редактора стандартов типов данных Datatype Standards Editor. Словарь доменов содержит многократно используемые атрибуты и обеспечивает непротиворечивость имен и определений в рамках модели. Редактор стандартов именования позволяет пользователям создавать словари разрешенных терминов, аббревиатур и правил именования, которые могут использоваться повторно в рамках модели. Редактор стандартов типов данных позволяет определять собственные правила соответствия между типами данных разных СУБД.
Поддержка нескольких нотаций моделирования. Для визуального проектирования систем обработки транзакций, витрин и хранилищ данных в единой интегрированной среде ERwin поддерживает три популярные нотации моделирования данных: Integration DEFinition for Information Modeling (IDEF1X), Information Engineering (IE), Dimensional Modeling (DM).
Управление большими моделями:
ERwin облегчает управление большими корпоративными моделями за счет использования предметных областей (Subject Areas) и хранимых отображений (Stored Displays). Предметные области позволяют конкретным проектировщикам фокусировать внимание, разделяя модель на более мелкие, и за счет этого легче управляемые подмодели. Хранимые отображения предоставляют разные варианты графического представления модели или ее предметных областей, облегчая обмен информацией между специализированными группами пользователей.
Полное сравнение/синхронизация (Complete Compare):
Эта мощная технология автоматизирует полную двунаправленную синхронизацию модели, скриптов и баз данных. При синхронизации для выбранных пользователем объектов отображаются отличия, и пользователю предлагается выбрать, какие из обнаруженных отличий и в каком направлении необходимо внести. При этом AllFusion ERwin Data Modeler (ERwin) может автоматически сгенерировать ALTER-скрипт на изменение.
Генерация структуры базы данных:
ERwin позволяет автоматически сгенерировать структуру базы данных из модели. Входящие в продукт оптимизированные шаблоны триггеров ссылочной целостности и богатый макроязык, совместимый с различными типами баз данных, позволяют пользователю настроить триггеры и хранимые процедуры. Настраиваемые шаблоны облегчают генерацию законченной физической структуры базы данных и полных определений (для соответствующей целевой базы данных).
Проектирование хранилищ и витрин данных:
Производительность, удобство в использовании и ценность хранилища данных напрямую зависит от модели, лежащей в его основе. ERwin поддерживает техники моделирования, характерные для проектирования хранилищ данных, такие как многомерное моделирование по схеме "звезда" или "снежинка", которые гарантируют, что хранилище данных оптимизировано как по производительности, так и по аналитическим возможностям. Кроме того, продукт способен собирать и документировать широкий спектр информации о хранилище данных, в том числе об источниках данных, логике трансформации данных и правилах управления данными.
Обратное проектирование:
ERwin позволяет провести автоматическую обратную генерацию структуры базы данных в модель для ее изучения и документирования и/или для последующей миграции на платформу другой СУБД.
Графические объекты:
С помощью графических объектов ERwin обеспечивает наглядное представление бизнес-правил. Графические объекты, например линии, эллипсы и другие, легко редактируются. Разработчики моделей могут также настраивать параметры шрифта и цвета объектов.
Навигатор модели (Model Explorer):
Model 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.
Интеграция с другими продуктами:
AllFusion ERwin Data Modeler интегрирован с широким спектром сред моделирования, такими как Rational Data Architect, Oracle Designer, Sybase Power Designer и др.
ERWin был выбран, так как он предоставляет возможности создания диаграмм баз данных, необходимых при разработке АИС и наличия всех необходимых компонентов для выполнения указанных целей;
Выбор BPWin основан на необходимости определения бизнес-процессов исследуемой области. Данный инструмент предоставляет все нужные возможности и удобен в использовании.
Также оба инструмента достаточно просты в освоении, что позволило выделить больше времени на саму разработку [26].
4.2 Определение бизнес-процессов
Для реализации разрабатываемой АИС необходимо построение функциональной модели для выделения основных выполняемых системой бизнес-процессов.
При построении модели использована методология функционального моделирования IDEF0.
На верхнем уровне представлена система АРМ специалиста по работе с персоналом (рис. 2).
К входным данным относятся:
1. персональные данные соискателя такие, как ФИО, адрес электронной почты и пароль для входа в систему;
2. направление работы, которое отражает желаемую вакансию. От направления зависит, какой специалист будет работать с данным соискателем.
Рисунок 2 - Контекстная диаграмма верхнего уровня бизнес-процессов
К блоку управления относятся:
3. должностная инструкция специалиста отдела кадров и руководителя направления (данный документ также определяет рамки и правила общения с соискателем);
4. условия приёма, на основе которых будет происходить принятие решения о приёме на работу;
5. правила регистрации, которые необходимы для определения полей при регистрации и правил, по которым будут проверяться введённые данные.
Блок механизма состоит из специалистов по работе с персоналом, администратора системы и руководителя направления.
К выходным данным относится только решение о статусе соискателя, то есть будет ли он принят или же нет.
На втором уровне происходит разделение системы на три процесса (рис. 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;
8. group_id -- в это поле хранится уникальный идентификатор типа пользователя. Пользователь может быть одного из трёх типов: специалист, администратор, кандидат;
9. is_active -- поле, показывающее статус регистрации пользователя. «1» -- если пользователь подтвердил регистрацию переходом по ссылке в письме, «0» -- если пользователь не закончил регистрацию, такие пользователи через некоторое время удаляются;
10. last_login -- данное поле показывает, когда пользователь заходил в систему последний раз;
11. failed_login_count -- поле является счётчиком, который регистрирует количество ошибочных вводов логина и/или пароля. Если значение этого поля больше или равно значению поля max_failed_login, то пользователь блокируется до разблокировки администратором. В чате пользователь также помечается заблокированным, чтобы специалист мог быстро среагировать на проблему. Такая схема сделана для защиты аккаунтов пользователей от взлома перебором паролей.
12. is_banned -- поле показывает заблокирован ли пользователь;
13. reg_date -- в этом поле хранится дата регистрации пользователя в системе;
14. reg_token -- после отправки формы регистрации, пользователю будет выведено сообщение, что отправлено письмо на указанную почту со ссылкой подтверждения. Эта ссылка будет включать токен из текущего поля для идентификации записи, которую надо активировать.
В таблице hrw_direction хранятся направления, в которых могут работают специалисты. Таблица состоит из двух полей:
1. id -- в поле хранится уникальный идентификатор направления, по которому можно напрямую обратиться к нужном направлению;
2. title -- данное поле хранит в себе наименование направления;
В таблице hrw_page_group хранятся группы, в которые могут включаться страницы, в зависимости от своего типа. Таблица состоит двух полей:
1. id -- в поле хранится уникальный идентификатор группы, по которому можно напрямую обратиться к необходимой;
2. title -- поле хранит в себе заголовок группы;
В таблице hrw_page_template хранятся шаблоны оформления, которые используются при формировании страницы. Таблица из трёх полей:
1. id -- в поле хранится уникальный идентификатор шаблона, по которому можно напрямую обратиться к нужному;
2. title -- поле хранит заголовок шаблона;
3. filename -- в данном поле находится имя файла, в котором находится шаблон.
В таблице hrw_page_user_connections хранятся права доступа групп пользователей, к определённым группам страниц. Таблица состоит из 3 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. page_group_id -- в данном поле хранится идентификатор группы страниц, к которым имеют доступ пользователи по идентификатору из поля user_group_id;
В таблице hrw_settings хранятся клиент-серверные настройки, которые определяют поведение всего сервиса. Таблица состоит из 4 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. name - поле хранит имена настроек, по которым можно получать или изменять необходимые значения;
3. title -- в данном поле находится заголовки настроек;
4. value -- это поле хранит значения настроек;
В таблице hrw_user_direction_connections хранится информация о том, в каких направлениях может работать специалист. Таблица состоит из 3 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. spec_id -- поле хранит идентификатор пользователя, который является специалистом;
3. direction_id -- в этом поле хранится идентификатор, который определяет, по каким направлениям может работать специалист.
В таблице hrw_user_group хранятся группы, в которые могут включаться пользователи, в зависимости от своей роли. Таблица состоит двух полей:
1. id -- в поле хранится уникальный идентификатор группы, по которому можно напрямую обратиться к необходимой группе;
2. title -- поле хранит в себе заголовок группы;
Таблица hrw_cand_file хранит в себе данные о файлах, которые заливал кандидат и состоит из 5 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. cand_id -- данное поле содержит уникальный идентификатор кандидата, которому принадлежит файл;
3. name -- в этом поле находится имя файла;
4. type -- это поле хранит тип файла, например, текстовый или графический;
5. filename -- в этом поле хранится физическое имя файла, под которым он хранится на жёстком диске.
В таблице hrw_spec_file хранятся записи о файлах, принадлежащих специалистам. Таблица состоит из 6 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. parent_id -- поле хранит идентификатор каталога, которому принадлежит файл;
3. is_dir -- в данном поле хранится информация, которая определяет каталог или файл выбранный объект;
4. name -- в этом поле хранится имя файла;
5. type -- это поле хранит тип загруженного файла, например, текстовый или изображение;
6. filename -- в этом поле хранится физическое имя файла, под которым он хранится на жёстком диске.
В таблице hrw_message хранятся все сообщения, которыми обмениваются специалисты и кандидаты. Таблица состоит из 5 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. sender_id -- поле хранит в себе идентификатор отправителя сообщения;
3. receiver_id -- в этом поле хранится идентификатор получателя;
4. text -- в данном поле находится, непосредственно, текст сообщения;
5. date -- хранит в себе дату и время отправления.
В таблице hrw_user_cgroup_connection хранится информация о том, в какую группу специалиста попадает пользователь при подключении. Таблица состоит из трёх полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. user_id -- поле хранит идентификатор пользователя, который подключается к определённой группе;
3. cgroup_id -- в данном поле хранится идентификатор группы, к которой подключается кандидат при входе в систему.
В таблице hrw_user_info хранится информация о выбранном кандидате. Таблица состоит из 6 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. cand_id -- в данное поле хранится идентификатор кандидата, к которому привязана запись текущей таблицы;
3. age -- поле хранит возраст кандидата;
4. education -- в этом поле хранится информация об образовании кандидата;
5. tel -- в данном поле находится номер телефона кандидата;
6. direction_id -- это поле хранит уникальный идентификатор, который показывает, к какому направлению принадлежит кандидат.
В таблице hrw_user_note хранятся заметки специалистов о кандидатах. Таблица состоит из 6 полей:
1. id -- в поле хранится уникальный идентификатор записи, по которому можно напрямую обратиться к нужной записи;
2. author_id -- в этом поле хранится идентификатор создателя заметки;
3. cand_id -- данное поле хранит идентификатор кандидата, о котором создана заметка;
4. title -- поле хранит заголовок заметки;
5. text -- в это поле хранится содержимое заметки;
6. date -- в данное поле записывается дата создания заметки.
После регистрации соискателю на указанную почту будет прислано сообщение, в котором будет указана ссылка для подтверждения регистрации. После подтверждения пользователь будет окончательно добавлен в таблицу User.
Для специалиста все соискатели отсортированы по группам, таким как новые, отложенные или отработанные. Эти группы созданы по умолчанию, но любой специалист может создать и свою группу, которая будет добавлена в таблицу hrw_cgroup.
Как и специалист, соискатель может добавить в систему необходимые файлы, такие как резюме или же результаты тестового задания. Исключением является только то, что файлы соискателя в отличие от файлов специалиста являются индивидуальными.
Основным способом диалога между специалистом и соискателем является обмен сообщениями. Все сообщения добавляются в таблицу hrw_message.
6. Разработка алгоритмов
АРМ является распределённой клиент-серверной системой, поэтому алгоритм работы построен на обмене данными, путём запроса-ответа (рис. 7).
Рисунок 7 - Взаимодействие модулей системы в общем виде
Также рассмотрим use case разработанной системы.
Рисунок 8 - Диаграмма использования разработанного программного продукта
На рисунках 9 и 10 представлена блок-схема алгоритма работы клиентского модуля. Как со стороны кандидата, так и специалиста кадров первое обращение к АРМ вызовет запрос клиентом страницы у сервера. В начале работы такой страницей станет форма авторизации пользователя в системе. Отдельно для кандидата существует страница с формой регистрации, заполнив которую он получает доступ к системе. Так же после регистрации на указанную почту кандидата придёт письмо с просьбой подтверждения регистрации и лишь после подтверждения кандидат будет окончательно зарегистрирован.
После успешной авторизации пользователю сервером будет выдана страница с основным интерфейсом системы. У кандидата и специалиста эти интерфейсы отличаются.
Любое последующее действие пользователя, кроме нескольких типов, будет вызывать посылку запроса клиентом серверу на получение или изменение данных. Будь то получение списка текущих кандидатов в конкретной группе или отправка сообщения при диалоге.
Рисунок 9, А - Блок-схема алгоритма работы клиентского модуля
Рисунок 9, Б - Блок-схема алгоритма работы клиентского модуля
Рисунок 10 - Блок-схема процесса инициализации
7. Разработка и реализация программных модулей
Опишем работу программы, представив ее формы и основные функции.
7.1 Регистрация в системе
При входе в модуль пользователя системы в браузере откроется страница регистрации и входа (рис. 11), где пользователь может зарегистрироваться для дальнейшего взаимодействия внутри сервиса.
Подобные документы
Анализ деятельности кадровой службы, обоснование выбора средств автоматизации ее работы, классификация используемых информационных методов. Разработка технических требований и архитектуры серверной части. Основные этапы реализации программных модулей.
дипломная работа [1,9 M], добавлен 19.01.2017Анализ технического задания, разработка программных модулей, средств тестирования и руководство пользователя. Масштабируемые средства для построения баз данных. Расчет эффективности программы "Автоматизированное рабочее место специалиста ООО "Бравида".
дипломная работа [1,9 M], добавлен 24.07.2014Обоснование необходимости и основные цели использования вычислительной техники для решения задачи. Используемые классификаторы и системы кодирования. Программное обеспечение разработки автоматизированного рабочего места. Описание программных модулей.
дипломная работа [3,9 M], добавлен 11.08.2015Анализ предметной области. Обоснование проектных решений по разработке автоматизированного рабочего места сотрудника канцелярии банка. Проектирование структуры базы данных и интерфейса системы. Разработка программных модулей и алгоритмов их работы.
дипломная работа [2,1 M], добавлен 18.10.2015Разработка и реализация базы данных информационной системы автоматизации рабочего места инспектора по начислению пенсии. Технология создания модуля для оперирования точной информацией при работе с клиентами организации, упрощение способа расчета пенсии.
дипломная работа [1,2 M], добавлен 09.08.2011Сфера применения автоматизированного рабочего места менеджера системы Клиент-Банк, выполнение финансовых операций и перевод денежных средств между счетами клиента, использование сертифицированных программных средств, их высокая производительность.
курсовая работа [1,1 M], добавлен 28.08.2012Понятие информации, информационных технологий и их виды. Анализ основных положений по автоматизации рабочего места оператора автотранспортного предприятия. Разработка модели автоматизированного рабочего места начальника отдела. Применение модели АРМ.
дипломная работа [4,0 M], добавлен 18.09.2010Автоматизированная выборка данных, упрощение переработки информации при использовании СУБД. Разработка программного обеспечения автоматизированного рабочего места секретаря учебно-методического кабинета. Назначение, проверка, условия применения программ.
контрольная работа [304,6 K], добавлен 28.07.2010Анализ аналогов-ресурсов системы "Бюро регистрации несчастных случаев", критерии выбор задач, подлежащих автоматизации. Проектирование автоматизированного рабочего места сотрудника оперативного учета. Разработка модели базы с использованием CASE-средств.
дипломная работа [7,8 M], добавлен 21.01.2012Создание автоматизированного рабочего места специалиста предприятия, ведущего государственную статистическую отчетность по форме 12-тэк "Отчет о расходе топливно-энергетических ресурсов". Структура информационной ASP.NET-системы. Верификация работы АРМ.
дипломная работа [9,9 M], добавлен 15.10.2011
