Моделирование предметной области «Управление персоналом» с помощью UML»

Содержание:

Введение

На сегодняшний день проблема автоматизации производственных и управленческих процессов как средства повышения производительности труда и уменьшения затраченного времени остается довольно актуальной в организациях различного рода деятельности.

Необходимость внедрения и использования информационных технологий в управлении современным учреждением и его звеньями обусловлена облегчением деятельности персонала, сдерживанием роста его численности, уменьшением временных затрат, увеличением объемов производительности.

Прежде чем приступить к реализации автоматизированной системы управления (АСУ), необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой ИС удобно представлять в виде диаграмм использования UML (унифицированный язык моделирования). При разработке данного проекта использовался UML и Rational Rose – мощное CASE - средство, помогающее строить модели систем.

Цель данной работы– спроектировать и разработать информационную систему для управления персоналом. Информационная система должна быть удобной для пользователя, обладать «дружелюбным» интерфейсом.

Для достижения поставленной цели были определены следующие задачи:

• дать характеристику предприятия;
• описать бизнес-процессы;
• обосновать необходимость автоматизации бизнес-процессов;
• разработать предложения по улучшению бизнес-процессов;
• выбрать средства моделирования процессов управления персоналом;
• построить модели бизнес-процессов.

Объект исследования – процессы управления персоналом.

Предмет исследования – процесс моделирования предметной области.

Нормативной базой исследования являются Конституция РФ, федеральные законы и подзаконные нормативные правовые акты по вопросам создания и использования информационных систем.

Методологическая основа исследования. В ходе исследования применялись такие методы познавательной деятельности, как анализ, синтез, дедукция. Для сопоставления различных подходов к рассматриваемым проблемам использовался сравнительный метод. Для построения моделей применялись методы объектно-ориентированного подхода.

Глава 1. Аналитическая часть

1.1. Описание предметной области. Постановка задачи

Рекламная группа «ОНИКС» создана в 1994 году. Сегодня РГ «Оникс» - сетевое агентство комплексных решений‚ располагающее сетью собственных прдставительств в городах: Москва‚ Санкт-Петербург‚ Ростов-на-Дону‚ Екатеринбург‚ Новосибирск‚ Красноярск‚ Владивосток.

Направления деятельности:

• Комплексные рекламные кампании.
• Брэндинг.
• Креатив и дизайн.
• Promotion и PR.
• Размещение рекламы на всех типах медианосителей‚ во всех регионах.
• Медиапланирование.
• Маркетинговые исследования и post-campaign.

Основные экономические показатели деятельности ООО «РГ Оникс» приведены в таблице 1.

Таблица 1

Технико-экономические показатели ООО « РГ Оникс»

№ пп	Наименование показателя	2017 год
	Чистые доходы (расходы), тыс.рублей	399 884
	Прибыль (убыток) до налогообложения, тыс. рублей	104 666
	Прибыль (убыток) за отчетный период, тыс. рублей	54 567
	Количество сотрудников (чел.)	150

Представим систему управления персоналом в виде функциональной модели, построенной с помощью BPWin (рис.1). Данная модель, описывающая процесс деятельности предприятия, состоит из нескольких диаграмм, позволяющих понять, на основании каких функций работают отделы, кто их формирует, а также под чьим руководством, ясно увидеть результат работы. Методология IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности рассматриваемой компании.

Рисунок 1. Контекстная диаграмма

Декомпозиция контекстной диаграммы представлена на рисунке 3.

Рисунок 2. IDEF0 Управление персоналом

Рисунок 3. Организация работы сотрудников

В данном пункте нами были выделены задачи для автоматизации:

прием на работу и уволнение;

повышение квалификации;

оформление отпусков, командировочных и т.д.

На рисунках 4 и 5 детально приведены модели существующих бизнес-процессов приема на работу и увольнения.

Рисунок 4. Модель бизнес-процесса «Прием на работу»

Рисунок 5. Модель бизнес-процесса «Увольнение»

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

1.2. Предлагаемые мероприятия по улучшению технологии решения задачи

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

Для внедрения АС не потребуются дополнительные технические ресурсы, так как на всех рабочих местах имеется компьютерная техника.

Цели, критерии и ограничения создаваемой АС:

• обеспечить достоверной и полной информацией, необходимой для учета кадров;
• обеспечить данными по обучению сотрудников и сдаче экзаменов;
• своевременно оформлять всю первичную документацию;
• повысить надежность и безопасность обработки информации.

Ожидаемые технико-экономические результаты создания АС:

• снижение временных времени на поиск резюме;
• снижение временных затрат на то, чтобы подвести итоги сдачи экзаменов и далее повышать оклад сотрудника;
• повышать точность данных.

Затраты на создание и эксплуатацию АС будут невелики, так как все рабочие места отдела персонала оснащены необходимой техникой.

Глава 2. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

В настоящее время унифицированный язык моделирования UML [5] является визуальным языком моделирования, который позволяет системным архитекторам представить свое видение системы в стандартной и легкой для понимания форме. Кроме того, UML представляет эффективный механизм совместного использования проектных решений и взаимодействия разработчиков друг с другом.

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

• • Диаграмма вариантов или прецедентов использования (use case diagram)
  • Диаграмма классов (class diagram)
  • Диаграммы поведения (behavior diagrams)
  • Диаграмма состояний (statechart diagram)
  • Диаграмма деятельности (activity diagram)
  • Диаграммы взаимодействия (interaction diagrams)
  • Диаграмма последовательности (sequence diagram)
  • Диаграмма кооперации (collaboration diagram)
  • Диаграммы реализации (implementation diagrams)
  • Диаграмма компонентов (component diagram)
  • Диаграмма развертывания (deployment diagram)

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

Также стоит добавить, что не всегда обязательно строить абсолютно все диаграммы, разработчик сам решает - устраивает ли его данный уровень детализации, нужно ли рассмотреть систему или ее часть с «другого вида», достаточно ли подробно рассмотрены самые «сложные и скользкие моменты». Т.е. инструменты, поддерживающие UML и предназначенные для моделирования ПО, позволяют еще на этапе разработки проверить архитектурные решения, полноту модели, ее корректность, для того, чтобы, в том числе, уменьшить риск «провала» проекта. Опишем некоторые из графических диаграмм, построенных при разработке нашей системы.

Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария.

В рамках Rational Rose существуют различные программные инструментарии, отличающиеся между собой диапазоном реализованных возможностей.

То, что пакет позволяет создавать сложные программные системы от замысла до создания исходного кода, привлекает не только проектировщиков, но программистов – разработчиков. В сочетании со средствами документирования он дает полное представление о проекте. Выделим следующие преимущества от применения этого пакета:

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

В виду того, что разрабатываемая система представляет собой создание БД, то не стоят задачи полной разработки автоматизации процесса моделирования, т.е. написание кодов программ при помощи Rational Rose. Решение поставленных задач позволяют не пользоваться этим на данной точке проектирования, но в свою очередь является полезной стартовой площадкой для возможного дальнейшего использования данного разработанного проекта для внедрения в состав какого-либо другого программного продукта. Построенные модели помогают точнее понять задачи, которые должна выполнять система и являются понятным средством общения с заказчиком или в дальнейшей работе с другими разработчиками. Рассмотрим сначала функциональную модель нашей системы. Наша система имеет ряд пользователей, объединенных определенными задачами, что позволяет нам разделить систему на несколько подсистем и описать их по отдельности, не создавая большого объема и избыточности. Рассмотрим некоторые из диаграмм, которые активно помогли мне в определении большинства тех вещей, которые будет выполнять данная информационная система.

Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы
• Сформулировать общие требования к функциональному поведению проектируемой системы.
• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы в таблице 2.

Таблица 2

Условные обозначения диаграммы вариантов использования.

Условное обозначение	Описание условного обозначения
	Actor-актер системы, т.е. любое действующее лицо, которое представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей. В системе актерами являются «Менеджер по поставкам», «Менеджер по продажам», «Начальник транспортного отдела» и «Управляющий».
	Use case -стандартное обозначение варианта (прецедента) использования, описывающий типичное взаимодействие между пользователем и системой
	связь, называемая коммуникацией (communication). Устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования
	связь включения (include) между двумя вариантами использования, которая указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательности поведения другого варианта использования
	связь расширение (extend)отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования

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

Таблица 3

Условные обозначения диаграммы состояний

Условное обозначение	Описание условного обозначения
	начальное состояние, не содержит никаких внутренних действий, в этом состоянии находится объект по умолчанию в начальный момент времени
	конечное состояние, который также не содержит никаких внутренних действий. В этом состоянии будет находиться по умолчанию после завершения работы в конечный момент времени. Оно служит для указания графической области, в которой завершается процесс изменения состояния
	Состояние
	Переходом (transition) называется перемещение объекта из одного состояния в другое
	Рефлекторный переход

На диаграмме состояний может быть одно и только одно начальное состояние. В то же время может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

Выходное действие (exit action) подобно входному. Однако оно осуществляется как составная часть процесса выхода из данного состояния. Выходное действие изображают внутри состояния, его опи­санию предшествуют слово exit (выход) и двоеточие.

Переходом (transition) называется перемещение объекта из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, начинающейся на первоначальном состоянии и заканчивающейся последующим.

Переходы могут быть рефлексивными. Объект может перейти в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Таблица 4

Условные обозначения диаграммы деятельности

Условное обозначение	Описание условного обозначения
	начальное состояние, не содержит никаких внутренних действий, в этом состоянии находится объект по умолчанию в начальный момент времени
	конечное состояние, который также не содержит никаких внутренних действий. В этом состоянии будет находиться по умолчанию после завершения работы в конечный момент времени. Оно служит для указания графической области, в которой завершается процесс изменения состояния
	состояние действий с некоторым входным действием и по крайней мере одним выходящим из состояния перехода. Внутри этой фигурки записывается выражение действий, которое должно быть уникальным в пределах одной диаграммы деятельности
	ветвление, применяемое в случаях, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. В этот ромб может входить только одна стрелка от того состояния, после выполнения которого, поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее условие
	переход, т. е. отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим
	распараллеливание вычислений. Может иметь один входящий переход и несколько выходящих, либо несколько входящих и один выходящий

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

• информационные (informative) – сообщения, снабжающие объект-получатель информацией для обновления его состояния;
• сообщения – запросы (interrogative) – сообщения, запрашивающие выдачу информации об объекте-получателе;
• императивные (imperative) – сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

• последовательности (sequence diagrams);
• кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

В результате использования этих обозначения построена следующая диаграмма вариантов использования для действующих лиц.

Рисунок 6. Диаграмма прецедентов

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

Следует предпочитать небольшие и детализованные варианты использования, поскольку они облегчают составление и реализацию согласованного плана проекта. [7]. Ниже приведены уточненные диаграммы вариантов использования для отдельных категорий пользователей

Рисунок 7. Менеджер по работе с фирмами работодателями

Рисунок 8. Руководитель

Рисунок 9. Менеджер по работе с соискателями

Рисунок 10. Диаграмма состояний вакансии

Рисунок 11. Диаграмма состояний направления на работу

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

• анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимо­сти в поведении системы. Связывание методов и объектов выпол­няется позднее с помощью диаграмм взаимодействия;
• анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения.

Рисунок 13. Диаграмма деятельности «Поиск вакансии для соискателя»

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

Для моделирования этих особенностей используется специальная конструкция, получившая название дорожки (swim lanes). Имеется в виду визуальная аналогия с плавательными дорожками в бассейне.

Все действия делятся на отдельные группы, которые отделяются друг т друга вертикальными линиями. Группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, филиалом) компании.

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

Рисунок 14. Диаграмма активности с дорожками

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Рисунок 15. Диаграмма последовательности поиска соискателя

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

Рисунок 16. Диаграмма кооперации поиска соискателя

Как видно из рисунка, здесь представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее уяснить последовательность событий.

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

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

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

• Для моделирования данных. Анализ предметной области позволяет выявить основные характерные для нее сущности и связи между ними. Это удобно моделируется с помощью диаграмм классов. Эти диаграммы являются основой для построения концептуальной схемы базы данных.
• Для представления архитектуры ПС. Можно выделить архитектурно значимые классы и показать их на диаграммах, описывающих архитектуру ПС.
• Для моделирования навигации экранов. На таких диаграммах показываются пограничные классы и их логическая взаимосвязь. Информационные поля моделируются как атрибуты классов, а управляющие кнопки – как операции и отношения.
• Для моделирования логики программных компонент (будет описано в последующих статьях).
• Для моделирования логики обработки данных.

Диаграмма классов приведена ниже на рис.17.

Рисунок 17. Диаграмма классов

Заключение

Главной целью работы было моделирование деятельности отдела кадров по управлению персоналом. Для разработки данной системы был использован унифицированный язык моделирования UML и Rational Rose - case– средство, помогающее строить модели UML.

Разработанная и реализованная мной информационная система представляет из себя первый этап проекта по автоматизации развивающейся фирмы и отвечает всем основным требованиям.

Реализованная ИС в дальнейшем будет внедрена в рекрутинговое агентство.

К достоинствам данной информационной системы можно отнести выбранные средства проектирования и реализации – проектирование с использованием UML позволило подойти к этапу реализации с четко сформулированными задачами и сократить временные затраты на создание базы данных, сделала систему производительной и удобной с точки зрения использования, модификации и настройки.

Список литературы

1. Бритов Г., Осипова Т. Моделирование бизнес-процессов. - М.:LAP, 2014. – 124 с.
2. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб.:Питер, 2015. – 368 с.
3. Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012. - 400 c.
4. Давыдова Е. М. Базы данных Учеб. пособие для вузов / Е. М. Давыдова, Н. А. Новгородова. - 3-е изд., перераб. и доп. - Томск : В-Спектр, 2012. - 128 с.
5. Данелян Т.Я. Организация и функционирование больших информационных систем. – М.: МЭСИ, 2007
6. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 2012. - 360 c.
7. Илюшечкин В. Основы использования и проектирования баз данных. Учебник. - М.:Юрайт, 2014. - 214с.
8. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
9. Исаев Г. Проектирование информационных систем. Учебное пособие. - М.: Омега-Л, 2015. - 432с.
10. Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013. - 240 c.
11. Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012. - 464 c.
12. Коваленко В. Проектирование информационных систем. - М.: Форум, 2012. - 320с.
13. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
14. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. — Москва-Санкт-Петербург-Киев: Вильямс, 2002.
15. Маклаков С.В. CASE-средства разработки информационных систем. – М.:ДИАЛОГ МИФИ, 2001. – 304 с.
16. Мартин Фаулер и Кендалл Скотт, UML. Основы.- СПб: Символ-Плюс, 2002
17. Розенберг Д, Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.— Москва: ДМК-издательство, 2002.